confidential and proprietary€¦ · of the invention may invalidate any patent for this invention....

OTT Use Only OTT No: Disclosure Date:

UNIVERSITY OF IDAHO

CONFIDENTIAL INVENTION DISCLOSURE FORM

In addition to their academic and scientific value, many discoveries and inventions developed by researchers at the University of Idaho (―University‖) also may have significant commercial value. University policy requires that compensated or non-compensated employees of the University, non-employees who use University research facilities, and those who receive grant or contract funds through the University must disclose all potentially patentable discoveries and inventions to the University. See Faculty Staff Handbook Sections (FSH) 5300 and 5400.

This Confidential Invention Disclosure Form has been designed to permit inventors to provide timely and effective notification of their inventions to the University through the Office of Technology Transfer (―OTT‖). Each section has text fields that will expand to accommodate your input and check boxes to indicate your choices. Please tab through the document and fill out each of the sections and attachments as completely as possible. Call 885-4550 for assistance or email: [email protected].

This disclosure should be considered confidential and proprietary. Please note that premature publication, dissemination, or public use of this discovery or invention may adversely affect the legal protection of your technology.

NOTE: You must sign the form in Section II and obtain Department Head and Dean/Director signatures in Section III for the OTT to begin to administer your discovery or invention, which includes determining ownership status, seeking legal protection, or exploring licensing and other commercialization opportunities.

Section I. Title of Invention and Primary Contact

1. Title of work:

Advanced Accessible Pedestrian System for Signalized Traffic Intersections

2. Name of contact inventor (who will be speaking and acting on behalf of the inventors listed on page 2):

Richard W, Wall

mailto:[email protected]

University Invention Disclosure Form

SECTION II. Declaration of Ownership, Inventors, Royalty-sharing, and Assignment

For details on University Patent and Copyright Policy, disclosures, royalty sharing, and the process of technology commercialization, please review the applicable policy, FSH 5300: http://www.webs.uidaho.edu/fsh/5300.html.

1. Please check below to indicate how the discovery or invention was developed:

A. Discovery or invention was the result of research or scholarship undertaken using equipment, facilities or funds provided by the University of Idaho or by an outside entity (such as state or federal agency or a for profit company) , or was conceived of or developed in the course of the inventor’s duties at the University of Idaho.

B. Discovery or invention was the result of personal or private research performed independently of any contractual obligations to the University of Idaho and without using equipment, facilities or funds provided by the University of Idaho or an outside agency, or the result of permissible consulting activities.

2. Please list below all inventors of the invention. If there are more than two co-inventors, please list any additional inventors in Attachment 1. Note that failure to list every inventor who contributed to the conception of the invention may invalidate any patent for this invention. However, the question of inventorship is a matter of law, and each person listed below will not necessarily be named as an inventor on any patent that may ultimately be issued for the invention. Under University policy co-inventors share in any income from an invention.

As indicated by their signatures below — and subject to final determination of ownership of the invention under the University’s policy on intellectual property — the following individuals do hereby:

A. Assign their individual rights, title, interest and ownership in this discovery or invention to the University so that the University may, in its sole discretion, administer, protect, license, or otherwise use or exploit this invention for the benefit of the University and the individual inventors; and

B. In accordance with FSH Section 5300, paragraph B-4 (Royalties and Income), the inventor/s agree that their portion of the inventors’ share of net income resulting from any licensing, sale, or other commercialization of the invention is to be divided among themselves according to the percentages shown below; and

C. Acknowledge that the abstract provided with this form in Attachment 2 represents a non-enabling description of the technology and may be released, published, or disseminated by the OTT in order to attract potential licensing candidates or to assess the potential financial return from this discovery, and agree to work with OTT as requested to refine the abstract; and

D. Agree that the individual whose name appears on the first page of this form will be the contact point with the OTT on behalf of all those listed below (this contact inventor may or may not be the first inventor involved in this discovery; however, the contact point should be one of the inventors, and should be listed below as such), and

E. Certify that all information provided in this disclosure is true and accurate to the best of their knowledge.

The following individuals also understand that if Box ―B‖ in Question 1 of this Section is checked, this disclosure will be immediately submitted to the Intellectual Property Committee for determination of ownership status in accordance withFSH Section 5300, paragraph C-4 (Ownership Questions), and that if it is determined that the invention was developed independently of the inventors’ University duties, the University will relinquish all rights in this discovery or invention to the inventors.

http://www.webs.uidaho.edu/fsh/5300.html


Please print or type (if filling out by hand):

1. Name: Phil Tate

Company Name Campbell Company Citizenship: USA

Title President Office Phone: (208) 345-7459

Office Address: 450 McGregor Street Office Fax: (208) 345-7481

Permanent Address: Email: [email protected]

City/State/Zip: Boise, ID 83705 Royalty Share: 50%

Signature:

Date:

2. Name: Richard W. Wall Vandal number:

V00006698

Title/Position: Professor Citizenship: USA

Dept/College: Electrical and Computer Engineering

Office Phone: (208) 885-7556

Office Address: POB 441023 Office Fax: (208) 885-7579

Permanent Address: 2730 Compton Place Email: [email protected]

City/State/Zip: Moscow, ID 83844-1023 Royalty Share: 30%

Signature:

Date:

Note: If there are more than 2 inventors, please use Attachment 1.

SECTION III. Notifications

The following individuals must sign this Invention Disclosure Form before the OTT can formally begin to administer this invention.

Department Chair

To best of my knowledge, the information on how the invention was developed presented in this disclosure, and the ―Declaration of Ownership‖ in Question 1 of Section II above are accurate, subject to the comment below.

Signature: Date:

Name:

Department:

Comment:

Dean/Director

I have received and acknowledge this invention disclosure.

Signature: Date:

Name:

College/Institute:

Comment:

Please return this completed form to: Office of Technology Transfer


University of Idaho Morrill Hall 414 P.O. Box 443003 Moscow, ID 83844-3003

If you have any questions, please call (208) 885-4550 or email: [email protected].


Attachment 2-A University Invention Disclosure Form

Attachment 1 — Additional Inventors

3. Name: Gabriel DeRuwe Vandal number:

Title/Position: Research Assistant Citizenship: USA


Office Phone: (208) 885-6554


Permanent Address: 411 N Almon St 613 Email: [email protected]


Signature:

Date:

4. Name: Craig Craviotto Vandal number:

Title/Position: Research Assistant Citizenship: USA


Office Phone: (208) 885-6554


Permanent Address: 114 N. Grant St Email: [email protected]


Signature:

Date:

5. Name: Vandal number:

Title/Position: Citizenship:

Dept/College: Office Phone:

Office Address: Office Fax:

Permanent Address: Email:

City/State/Zip: Royalty Share:

Signature:

Date:

6. Name: Vandal number:

Title/Position: Citizenship:

Dept/College: Office Phone:

Office Address: Office Fax:

Permanent Address: Email:

City/State/Zip: Royalty Share:

Signature:

Date:

Copy this page and attach as needed for additional inventors.


Attachment 2-B University Invention Disclosure Form

Attachment 2 — Description of Invention

1. Please attach a non-enabling abstract of the work in layperson’s terms, including practical uses for the work. Non-enabling means that a person with ordinary skill in the field should not be able to reproduce the invention based on this abstract.

The Advanced Accessible Pedestrian System (AAPS) is used to replace ADA compliant and non ADA compliant pedestrian stations for signalized traffic intersections using state of the art hardware and computer programs. The AAPS has higher reliability, improved operational performance, lower installation and maintenance costs, and higher flexibility than accessible pedestrian systems in use today. This system is designed to meet or exceed current requirements specified by the Federal Highway Administration (FWHA) Manual for Uniform Traffic Controller Devices (MUTCD). The AAPS can provide different class of service based upon method of activation resulting in improved safe access to pedestrian crosswalks for both those who are able bodied and those who are vision or mobility impaired. The class of service is determined by how the pedestrian call is generated. This includes but is not limited to an extended press of a mechanical or piezoelectric push button and remote activation from radio, inferred, or ultrasonic wireless device that communicates with one or more spatially distributed elements of the AAPS.

The AAPS consists of two major elements: pedestrian manager unit (PMU) located in the traffic controller cabinet and one or more pedestrian activation units (PAUs) located on the appropriate corners of the intersection. Different messages are sent from the PAU to the PMU based upon the type of PAU activation. Each PAU communicates different and distinct messages by using industry standard network technology to the PMU and the standard protocol specified by the National Transportation for Intelligent Transportation Systems Protocol (NTCIP). The PMU applies one or more inputs to the traffic controller in order to modify the traffic timing or operation plan based upon a predetermined action programmed into the traffic controller. The net result is that additional time to cross an intersection is provided for pedestrians who require it.

The PMU is in constant communications with the PAUs instead of just when the pedestrian button is pressed as is the case for APS systems installed at intersections today. This constant communications allows the PMU to detect PAUs that have failed and generate an alarm signal. PAUs that loose communications with the PMU are designed to turn off the APS audio messages to avoid playing an incorrect message to a person depending on the audio message to know when the walk signal is on to cross the street.

The PMU monitors the state of the pedestrian signals that are determined by the traffic controller. This pedestrian signal state is communicated to all PAUs. Audio messages are played by the PAUs depending upon the state of the pedestrian signals for every approach to the intersection. The audio messages are arranged in the PAU using a standard format that is specified by the PMU when the system is installed. Whenever a PAU is broadcasting an audio message, the message identifier is communicated back to the PMU. The PMU verifies that the audio message is compatible with the state of the pedestrian signals. If the PMU determines that there is a conflict between the pedestrian signal state and the audio message being broadcasted, the intersection is placed in a safe-fail state. This is accomplished by asserting a signal to the conflict monitor (CM) or malfunction management unit (MMU) that is part of current traffic controller installations. When the AAPS is connected to the a NEMA TS2 traffic controller and also to the traffic management center using an Ethernet connection, the PMU can send a message directly to the traffic management center.

The AAPS can be installed with NEMA TS1 and TS2 traffic controllers The AAPS can operated in conjunction with existing traffic control and pedestrian system without modification to the existing infrastructure. This allows a phased upgrading program to add the AAPS for a limited number of approaches to an intersection exclusively used by pedestrians needing the advanced capability of the AAPS.

Attachment 2-C University Invention Disclosure Form

2. a. When and where did you first conceive of the invention?

Date: August 2007 Place: Pittsburgh, PA

b. Where and when did you demonstrate that the invention actually does work or could work? If this occurred elsewhere, please explain.

Date: July 25, 2008 Place: GJL 222, Moscow, ID

Comment:

c. If the invention was conceived and reduced to practice elsewhere, was it an outgrowth of your research and scholarship at the University? Please explain.

No

3. Is a laboratory notebook or other documentation available? Yes No

(If no, what other proofs of inventorship can you provide?)

Documentation is in the form of email exchanges and computer generated documents and concept maps.

4. Please provide a complete description of the invention/discovery, including potential industrial applications. Feel free to attach papers, presentations, etc. that describe the technology.

A. Introduction

The Advanced Accessible Pedestrian System (AAPS) is comprised a central interface module with a traffic controller called the pedestrian management unit (PMU) and multiple spatially distributed modules that are activated by pedestrians called the Pedestrian Activation Unit (PAU) used place calls or requests for service. The following description of the APPS is based upon specific hardware used in the course of fabricating a working prototype. The AAPS is not dependent on any specific electronic part identified in in the following disclosure. The art of this invention is in the circuits describing the functionality of the system and the computer processes that operate on the information that is exchanged, generated or used by the specific devices.

The innovations with the AAPS center on the ability for bi-directional information exchange between the traffic controller cabinet and all pedestrian buttons at the intersection. Packets of data are exchanged multiple times a second so the PMU can monitor and display status as to the state of the PAUs regarding types of pedestrian calls if any and status of audio message.

The AAPS uses Ethernet communications with a protocol that is compliant with NTCIP communications standards normally used for communications between traffic controllers and traffic management centers. As such, there are two means for interfacing with traffic controllers based upon the NEMA type. NBPSRS interfaces to NEMA type TS1 traffic controllers by monitoring the 120VAC voltage outputs from the load switched controlled by the traffic controller by the PMU. Pedestrian calls are placed on NEMA Type TS1 controllers by PMU by asserting a low impedance electrical path to ground on the appropriate input to the traffic controller. This represents a hard wired interface between the traffic controller cabinet and the PMU. The advantage of completing the wiring inside the traffic controller cabinet instead of between each pedestrian signal and pedestrian button on the intersection corners is reduced installation cost and higher reliability because of the expense and exposure of outdoor wiring.

The AAPS uses a software interface with NEMA type TS2 traffic controller by means of Ethernet ports on both the TS2 traffic controller and the PMU. The state of pedestrian signals is polled from the traffic controller by placing a ―get‖ request for information of the appropriate Management Information Base (MIB) objects specified by the NTCIP 1202 standards using the Simple Network Management Protocol. Similarly, pedestrian service calls are placed to the traffic controller by using SNMP ―set‖ directive on the appropriate MIB object.

Attachment 2-D University Invention Disclosure Form

The AAPS has the following innovations and advantages of present APS pedestrian stations:

1. PAUs can be programmed for operational mode and audio messages in the field

2. All PAUs are software configurable by using a standard WEB browser and Ethernet interface with the PMU.

3. Since all PAUs are generic before installation, a single spare PAU can serve as a spare for all installations of the NBPSRS

4. Separate pedestrian calls to the traffic controller can be generated from one PAU depending upon the type of PAU activation (standard press, extended press, or remote pedestrian button).

5. Constant monitoring of PAUs by exchanging network information allows defective PAUs to be detected and reported.

6. Monitoring the audio messages generated at the PAUs by the PMU by means of closed loop communications fills in the laps in monitoring of APS messages by the CM or MMU.

7. Coordinated PAU audible signals to enable beaconing when activated by extended press or remote request for service.

8. Generate audible messages pertaining to intersection geometry or other navigational information when requested by user.

9. Direct replacement of existing pedestrian stations using existing wiring.

10. Uses industry standard NTCIP communications.

11. The functionality and capability to be programmed for alternated modes of operation cannot be done using system produced and sold today.

B. Background

The traffic light, also known as traffic signal, stop light, traffic lamp, stop-and-go lights, robot or semaphore, is a signaling device positioned at a road intersection, pedestrian crossing, or other location. Its purpose is to indicate, using a series of colors (Red - Amber - Green), the correct moment to stop, drive, ride or walk, using a universal color code (and a precise sequence or physical position in the cluster of signal lights, for those who are color blind).

In, the first traffic lights were installed outside the British Houses of Parliament in London. They resembled railway signals of the time, with semaphore arms and red and green gas lamps for night use. The gas lantern was turned with a lever at its base so that the appropriate light faced traffic.

As early as 1912, the modern electric traffic light used red-green electric traffic lights. In 1914, the American Traffic Signal Company installed a traffic signal system that had two colors, red and green, and a buzzer to provide a warning for color changes. The first four-way, three-color traffic light was created 1920. In 1923, Garrett Morgan patented a traffic signal device, although it was not a precursor of the modern traffic light.

A pedestrian crossing or crosswalk is a designated point on a road at which some means are employed to assist pedestrians wishing to cross. They are designed to keep pedestrians together where they can be seen by motorists, and where they can cross most safely with the flow of vehicular traffic. Pedestrian crossings are often at intersections, but may also be at other points on busy roads that would otherwise be perilous to attempt to cross.

A pedestrian scramble, or Barnes Dance (named for Henry Barnes), is a special traffic light that stops all vehicular traffic. Pedestrians then have exclusive access to the intersection and can cross the intersection diagonally. Pedestrian scrambles are useful when there is heavy diagonal pedestrian traffic, or heavy pedestrian traffic in general. In intersections with heavy pedestrian traffic, pedestrians have the right-of-way, blocking drivers from turning. There is also a beeping sound to help the pedestrians. A pedestrian scramble gives vehicles exclusive access to the intersection for a period of time as well.

Attachment 2-E University Invention Disclosure Form

C. Definition of Terms

1. MUTCD – Manual for Uniform Traffic Controller Devices

2. A traffic intersection – a location where vehicular traffic going in different directions can proceed in a controlled manner designed to minimize accidents

3. Signalized intersection – A traffic intersection consisting of three or more streets where the vehicular and non vehicular traffic is managed using an automated electronic controller.

4. Traffic controller – a computer based device that uses a program to process inputs generated by electronic timers, in situ instrumentation or manually operated electric switches to generate outputs that control the state of visual and audible signals to control movements of vehicles, people, bicycles, and other human operated devices that move through the intersection under control.

5. Traffic controller cabinet – an equipment cabinet used to contain the traffic controller and other electrical and mechanical devices required to interface the traffic controller with input and output circuits and devices. The traffic controller cabinet is generally physically located in close proximity to the corners of the intersection.

6. Malfunction Management Unit (MMU) – an independent electronic device used with NEMA TS2 traffic controllers that monitors all traffic signal outputs from traffic controller cabinet to detect a malfunction or a conflict in operations.

7. Conflict Monitor (CM) – an independent electronic device used with NEMA TS1 traffic controllers that monitors all traffic signal outputs from traffic controller cabinet to detect a malfunction or a conflict in operations.

8. Accessible Pedestrian Signal (APS) – a device that communicates information about pedestrian timing in nonvisual format such as audible tones, verbal messages, and/or vibrating surfaces as defined by the MUTCD.

9. Pedestrian call – A pedestrian call or request for service is normally placed on current traffic controller installations when button is pressed that is located at one of the corners of the intersection. The pedestrian button completes a circuit that places a low impedance electrical path on the assigned pedestrian input in the traffic controller cabinet.

10. Initiation point – the physical place associated with a signalized intersection where the pedestrian places a call for service.

11. Destination point – the physical place associated with a signalized intersection where the pedestrian intends to travel..

12. Phase – a specific movement of vehicles or pedestrians through a signalized intersection.

13. Walk phase – the interval during which a WALK signal is illuminated for a particular pedestrian crossing.

14. Pedestrian clearance phase – the interval during which a WAIT signal is flashing for a particular pedestrian crossing.

15. Beaconing (also known as target beaconing) – a term used to describe the concept of generating audible navigational cues to help visually impaired pedestrians. This is accomplished by generating distinguishable audible signal at both the initiation and destination points.

16. Protocol stack – a set of network protocol layers that work together. The OSI Reference Model that defines seven protocol layers is often called a stack, as is the set of TCP/IP protocols that define communication over the internet. The term stack also refers to the actual software that processes the protocols.

Attachment 2-F University Invention Disclosure Form

17. SNMP manager – a system, software part of a systems used to control and monitor the activities of network hosts using SNMP.

18. Agents – Agents are software modules that reside in network elements. They collect and store management information such as the number of error packets received by a network element.

19. Managed object – a characteristic of something that can be managed. For example, a list of currently active TCP connection in a particular host computer is a managed object. Managed objects differ from variables, which are particular object instances.

20. A managed device – a network node that contains an SNMP agent and that resides on a managed network. Managed devices collect and store management information and make this information available to NMSs using SNMP. Managed devices, sometimes called network elements, can be any type of device including, but not limited to, routers, access servers, switches, bridges, hubs, IP telephones, computer hosts, and printers.

21. A network management system (NMS) – a collection computer-based network connected devices that executes application software that monitor and control managed devices. NMSs provide the bulk of the processing and memory resources required for network management. One or more NMSs may exist on any managed network.

22. Management information base (MIB) -- a collection of managed objects residing in a virtual information store. Collections of related managed objects are defined in specific MIB modules.

23. GET REQUEST - used to retrieve a piece of management information.

24. GETNEXT REQUEST - used iteratively to retrieve sequences of management information.

25. GET RESPONSE - used by the agent to respond with data to get and set requests from the manager.

26. SET REQUEST - used to initialize and make a change to a value of the network element.

27. TRAP - used to report an alert or other asynchronous event about a managed subsystem. In SNMPv1, asynchronous event reports are called traps while they are called notifications in later versions of SNMP. In SMIv1 MIB modules, traps are defined using the TRAP-TYPE macro; in SMIv2 MIB modules, traps are defined using the NOTIFICATION-TYPE macro.

D. Hardware Description

a. System Hardware Organization

The PMU is located inside the traffic controller cabinet and only one of this type of module is required per AAPS installation. The PAU that is used by the pedestrian whenever he or she wishes to request a walk light to for crossing the specified approach to an intersection. One or more PAU modules are required for each AAPS installation.

Figure 1 and Figure 2 show the configuration of the AAPS system for two types of NEMA traffic controllers. Figure 1 shows the installation for all types of NEMA and CALTRAN traffic controllers. Module defined as element #1 in Figure 1 represents the PMU. The PMU consists of three functional elements each formed by a grouping of electric components and circuits. These three functional elements are the Pedestrian Management Processor (PMP) (#2), the AAPS Power Supply (#5) and the Ethernet over Powerline (#7). The connections between the PMU and the traffic controller cabinet use direct wiring. The outputs to the pedestrian signal (#3) are directly connected to the PMU as well as the appropriate pedestrian signals.

Attachment 2-G University Invention Disclosure Form

(The PMU places a request for service by causing the microprocessor incorporated in the PMU to activate electronics that completes a low impedance electrical path (#4) on the same sets of inputs normally connected to the pedestrian buttons.

The PMU has and Ethernet Port that is connected to the Ethernet port on a service computer (#13). The only requirement for the service computer is that it be capable of running an internet browser program such as Microsoft Internet Explorer or Netscape. The PMU hosts a WEB page that enables the maintenance and installation personnel to configure or perform diagnostic on the AAPS.

AAPS powers supply (#5) is powered by 60 Hz, 120 VAC power used to power the traffic controller cabinet. The AAPS power supply provides 12 VAC power to the PMU and all PMA modules connected in this installation. The PMU connects to the AAPS Ethernet based network using existing Ethernet over Powerline technology (EOP) (#7) The EoP coupler and transceiver allows the high frequency Ethernet communications signal to be combined with the 60 Hz 12 VAC power signal that is distributed (#7) to all PAU (#8) modules. The wire used for power and network communications is conventional two conductor cable used in traffic signals installations.

#3 Switched 120

VAC Pedestrian

Signal Outputs

TS1/TS2 – 170/270/ 2070

Traffic Controller

Cabinet

Power

#5 AAPS

Power supply

Existing Traffic

controller load

switches

#2.

Pedestrian

Management

Processor

Existing pedestrian

inputs to traffic

controller cabinet

#4

In

pu

ts to

Tra

ffic

co

ntr

olle

r

#7 EoP

#12 EoP

#10

Pedestrian

Button

Controller

#11 PAU

Power supply

#9 Pedestrian Activation Unit (PAU)

#13 Ethernet interface for

installation and maintenance

computer

Station 1 of N

#12 EoP

#11 PAU

Power supplyStation N of N

#6 Ethernet interface to

Ethernet over Powerline

modem

Existing 120 VAC

vehicle and pedestrian

traffic signals

Traffic Controller Cabinet

#8

12

VA

C P

ow

er

Dis

trib

utio

n a

nd

Eth

ern

et

Co

mm

un

ica

tio

ns

Ne

two

rk

#1 PMU

#10

Pedestrian

Button

Controller


Figure 1. AAPS System diagram for all types of NEMA traffic controllers

Figure 2 is a diagram of an alternate method for connecting the PMU to the traffic controller. Only NEMA TS2 type traffic controllers that are compliant with NTCIP standards can be used for this configuration. The hard wired interconnections (#3 and #4) shown in Figure 1 are replaced with an Ethernet switch or hub (#14) and an internet connection (#15) to the NEMA TS2 controller as shown in Figure 2. The Ethernet switch or hub (#14) is only required when the service computer (#13) is used, or if the controller is coordinated ( managed by a traffic management center). After installation or maintenance has been completed, the service computer (#13) and the Ethernet switch or hub (#14) can be replaced by using a null modem cable for the Ethernet connection directly between the NEMA TS2 controller and the PMU. If coordinated a router will be required for installation.

Attachment 2-H University Invention Disclosure Form

The PMU is programmed to detect the presence of the Ethernet connection (#15). If the Ethernet connection (#15) is detected, the hardwire inputs (#3) are ignored and the hardwired outputs (#4) are placed in a high impedance state.

TS2

Traffic Controller

Cabinet

Power

#5 AAPS

Power supply

Existing Traffic

controller load

switches

#2.

Pedestrian

Management

Unit (PMU)

Existing pedestrian

inputs to traffic

controller cabinet

#7 EoP

#13 Ethernet interface for

installation and maintenance

computer

#6 Ethernet

interface to Ethernet

over Powerline

modem

Existing 120

VAC vehicle and

pedestrian traffic

signals

Traffic Controller Cabinet

#14

Ethernet

switch or

hub

#15 Ethernet

interface to TS2

Traffic Controller

#8

12

VA

C P

ow

er

Dis

trib

utio

n a

nd

Eth

ern

et

Co

mm

un

ica

tio

ns

Ne

two

rk

#12 EoP

#10

Pedestrian

Button

Controller

#11 PAU

Power supply


Station 1 of N

#12 EoP

#10

Pedestrian

Button

Controller

#11 PAU

Power supply


Station N of N

#1 PMU

Figure 2. AAPS system diagram for NEMA Type TS2 traffic controllers only

b. PMU Hardware Description

A diagram showing additional details of the PMU (#1) are shown in Figure 3. This diagram shows that the connection between the PMP (#2) and the AC sensors (#16) as well as the connection between the PMP and the AC/DC switches (#17) use an industry standard serial communications technology commonly called I

2C (Inter IC communications). Because the PMP

is a separate circuit for the remaining circuits and components needed for the PMU, different processor boards to be used with a common interface circuit board.

Figure 3 also shows a serial connection to a WWVB receiver. This allows time updates to maintain an accurate clock on the PMP regardless of the timing accuracy of the NEMA TS2 traffic controller. The WWVB radio receiver is required when other types of traffic controllers are used and day time / night time operations modes are used by the AAPS.

Attachment 2-I University Invention Disclosure Form

#2

Pe

de

str

ian

Ma

na

ge

me

nt P

roce

sso

r

#16 AC

Sensors

#17 AC/DC

Switch

#4

Pe

de

str

ian

Ca

ll

Inp

uts

to

Tra

ffic

Co

ntr

olle

r

#13

Service

Laptop

#7 EoP

Modem

#5 Power

Supply 12-18 VAC

Power and

Communications

wires

120VAC

#1 Pedestrian Management Unit

(6) Ethernet

connection

#3

Pe

de

str

ian

Sig

na

l O

utp

uts

to

Tra

ffic

co

ntr

olle

r

#18

WWVB

Reveiver

Serial data

connection

I2C

Figure 3. Detailed diagram of the Pedestrian Management Unit (PMU)

A minimal installation requires a pair of Pedestrian Activation Units (#9) in Figures 1 and 2 are installed for every approach where a crosswalk exists. Each PAU (#8) has similar functional elements to those described for the PMU (#1). The Ethernet over Powerline circuit (#12) is identical to the one used in the PMU (#7). The power supply converts the 12VAC to voltages needed Pedestrian Button Controller (#10). All PAUs (#9) installed at an intersection share a common power and communications bus (#8).

Figure 4 is a detailed diagram of the PAU (#8). The prototype PAU uses a Cypress CYC829466 8 bit mixed signal processor (#19). The functionality provided by the audio amplifier and speaker (#21), the microphone (#22), the vibra-tactile motor (#23), the pedestrian button (#24) and the acknowledge light (#25) are features currently implemented on APS systems. These features are needed to comply with MUTCD requirements for APS installations. The Ethernet controller IC, ENC28J60, (#26) is produced by Microchip Corporation. This IC allows virtually any microprocessor to be connected to the internet. The remote pedestrian button communications interface (#27) is used for activation by a remote pedestrian button. The technology for this capability is covered by another University of Idaho provisional patent.

Attachment 2-J University Invention Disclosure Form

#26

Ethernet

ENC28J60

L Audio

Speaker

#21 Audio Power Amplifier

EoP

Modem

INT55MX

#24

Pedestrian

Button

#22

Microphone

#11

Power

Supply

#20

M24M01

128Kx8

EEPROM

(X4)

LM4755T

DP83848

MII

RF

Coupler

#1

9 C

Y8C

29

46

6 M

icro

pro

ce

sso

r

#23

Vibra–

Tactile

Motor

#27

Remote

Ped

Comm

Zero Crossing Det

1.8

V

3.3

V

5.0

V

12

V

SPI

I2C

Analog

Analog

UART

#12 EoP Modem

12 VAC Power

and

Communications

wires #25 Call

Acknowledge

Light

#10 Pedestrian Activation Processor

Figure 4. Detailed diagram of the Pedestrian Activation Unit (PAU)

E. Software Description

a. System Network Communications

The AAPS represent a network management system (NMS) where the PMU and all PAUs constitute managed devices and can function as Simple Network Management Protocol (SNMP) agents (devices that are to be controlled - Figure 6, #28) as well a SNMP managers (devices that make the control decisions - Figure 6, #29). Information between the PMU and one or more PAUs by exchanging Ethernet messages that uses the SNMP to read or modify parameters that are defined by the NTCIP 1202 standard objects or variable identifiers. Since pedestrian controls were not considered in when the NTCIP 1202 standard was developed, we implemented the AAPS uses custom object definitions until such time that the standards group adopts our definitions or the standards group develops a set of objects that meets our requirements. The PMU and each PAU contains software that processes the Ethernet messages using a construct commonly referred to as a protocol stack. The SNMP protocol stack, shown in Figure 5, is used to retrieve and modify the values of variables on agent devices. The software that performs the retrieving and modifying of variables on agents is called a SNMP manager. The PMU contains SNMP manager software and the PAUs contain SNMP agent software.

Attachment 2-K University Invention Disclosure Form

SNMP

IP

UDP

Ethernet

Figure 5 SNMP Protocol Stack

As shown in Figure 6, the SNMP manager (#28) is capable of sending set-request and get-request commands, and the agent responds with set-response and get-response messages respectively. A set-request message is used to modify the value of a variable on the agent and

a get-request message is used to read the value. Agents (#29) are also capable of sending unsolicited messages to agents called traps. A trap is used to alert a manager when the value of a variable has changed on an agent. The names of each variable are stored in a Management Information Base (MIB).

SNMP

Manager (#28)

SNMP

Agent (#29)

Set-request

Get-request

Set-response

Get-response

Trap

Figure 6 SNMP Manager and Agent Relationship

NTCIP specifies a standard set of variables that can be used to observe or modify traffic controller operations. Standard variable objects received from within the phaseStatusGroupEntry MIB, listed in Table 1, provide state information for signal phases and pedestrian service calls. The PMU collects data regarding pedestrian crossing state and walk timer from the traffic control using NTCIP, then rebroadcasts the data to the PAUs. When an Ethernet connection to the traffic controller is not available, the PMU creates the NTCIP variables using the state of the outputs from the traffic controller.

Attachment 2-L University Invention Disclosure Form

Table 1 phaseStatusGroupEntry variables

Variable Description

phaseStatusGroupWalks Pedestrian Walk Symbol Status

phaseStatusGroupDontWalks Pedestrian Don’t Walk Symbol Status

phaseStatusGroupPedClears Pedestrian Flashing Don’t Walk Symbol Status

phaseStatusGroupPedCalls Pedestrian Call Request Status

Table 2 shows additional variables that have been created to support AAPS calls. These variables are only used when there is an AAPS call. The phaseStatusGroupAPSCalls object is used to create and keep track of AAPS calls initiated by the pedestrian. The groupStatusGroupAPSBeaconSource object specifies which specific button in the intersection is the initiation point of an AAPS call. The groupStatusGrouAPSpBeaconDestination object specifies which specific button in the intersection is the destination point of an AAPS user. The APSnightMode object allows the PMU to set all of the PAUs into ―night mode‖ to reduce their audio volume. The buttonStatusAPSAudioMessage object is used to indicate which audio message, listed in Table 3, a specific PAU is currently being played on the audio speaker.

Table 2 Custom MIB objects used by the AAPS

Variable Description

phaseStatusGroupAPSCalls AAPS Call Request Status

groupStatusGroupAPSBeaconSource Origin of AAPS request

groupStatusGroupAPSBeaconDestination Destination of AAPS request

APSnightMode AAPS night mode operation

buttonStatusAPSAudioMessage Current audio message playing

The AAPS uses a standard audio message identifier that is enforced by the PMU setup WEB interface program. Each individual audio message may be any length but subject to the constraint of the memory capacity installed on the PAUs. The content of each audio message for each pedestrian button is programmed from the PMU by the service computer. The PMU configuration software is programmed to identify compatible audio messages with signal states of pedestrian phases. The eighth message in Table 3 is a user definable custom audio message. It can be used in situations where the standard messages are insufficient. For example, the custom audio message may be used to hold an alternate language.

Table 3 Audio Messages

Audio Message

Number

Description

1 Locator Tone

2 Custom Message

3 Chirp

4 Cuckoo

5 Location Message

6 Acknowledgement

Attachment 2-M University Invention Disclosure Form

7 Clearance

8 Custom

The AAPS system is user configured via a website hosted on the PMU. Using the website, the user is able to upload the audio messages and configure several settings including those listed in Table 4. These settings and audio messages are programmed into each PAU individually from the PMU using the TFTP protocol. The audio messages are stored in non-volatile memory on the PAU.

Table 4 AAPS User Configuration Options

Setting Description

Base audio volume Audio message volume before ambient noise compensation

Pedestrian Phase Which pedestrian phase a specific PAU belongs

APS group Used to associate PAUs with each other for AAPS source and destination beaconing

APS hold Amount of time the user must hold the button on the PAU before it is considered an AAPS call

Night mode time Time of day when PAUs should operate in night mode

Figure 7, Figure 8, and Figure 9 show the AAPS communications. Figure 7 shows the PMU (#30) updating the PAUs (#31) with the state of the pedestrian signals. The PMU (#30) broadcasts the state of all pedestrian signals to all of the devices on the network (#31) once every 250ms. Each PAU (#32 and #33) individually responds to the PMU (#30). If a PAU does not reply to the PMU, then it is assumed to be missing or inoperable and the PMU subsequently reports the error and appropriately places the AAPS into a low-risk mode of operation.

#30 PMU

#32 PAU 1

#31 PAU Network

#33 PAU N

Broadcast

Intersection State

Reply from PAU 1

Reply from PAU N

...

Figure 7 Normal Operation Communications

Figure 8 shows the pedestrian call communications. When a request for service is placed on the PAU (#35), it sends a message to the PMU (#34) to request for service. The PMU (#34) then acknowledges the request placed by the PAU (#35).

#34 PMU #35 PAU

Pedestrian Call

Acknowledgement

Figure 8 Pedestrian Call Communications

Attachment 2-N University Invention Disclosure Form

Figure 9 shows the PAU audio message update communications. When the PAU (#37) is playing a permissive audio message, IE ―Walk light is on‖, the PAU notifies the PMU (#36) once per second which audio message it is playing. Otherwise, the PAU notifies the PMU when it changes audio messages.

#36 PMU #37 PAU

Audio Message

Update

Figure 9 Audio Message Update Communications

b. PMU Software Operation

The PMU functions in a real-time multitasking software environment. The three main PMU tasks are operations, maintenance, and diagnostics. The maintenance task runs concurrently with the operations and diagnostics tasks. The diagnostics task is an interruption to the operations tasks.

Attachment 2-O University Invention Disclosure Form

#39 Send PAU

call requests to

Traffic controller

#38 Determine

state of

pedestrian

signals

#40 Broadcast

state of

pedestrian

signals to PAUs

#41 Test for each

PAU response

#43 Initiate

diagnostics tasks

for level 2 error

No

Yes

#45 Validate PAU

audio message

state

#46 Audio

Message

error?

#42 PAU

communications

error?

Yes

No

#47 Initiate

diagnostics tasks

for level 1 error

Initiate operations

process

#44 250 ms

timeout?

No

Yes

Figure 10 shows the PMU software operations task. These tasks are executed once every 250ms. The PMU first reads the state of the pedestrian signals (#38). Depending on the connection to the traffic controller, the state of the pedestrian signals may be polled using the Ethernet interface, or by reading the outputs of the traffic controller. Reading the outputs of the traffic controller is only performed if the Ethernet connection to the traffic controller is not available. If the traffic controller outputs must be read, then the variables in Table 1 are recreated using the state of the traffic controller outputs #16 in Figure 3. Next, pedestrian calls are made to

Attachment 2-P University Invention Disclosure Form

the traffic controller for any phase that has a request that has not been serviced (#39). Similarly to #38, calls are either placed via Ethernet or via physical connection to the traffic controller inputs. The physical connection to the traffic controller inputs, #17 in Figure 3 is only used when the Ethernet connection is not available. After placing the requests, the PMU broadcasts the pedestrian signal data to all of the PAUs (#40). Each PAU response is checked (#41) to ensure that all PAUs are operational. If any of the PAUs fail to respond (#42), then the PMU records the loss of communication (#43) and continues to operate. While waiting until the next time to repeat the sequence of operations, the PMU listens for audio message updates from the PAUs (#45). If any of the PAUs are playing the incorrect audio message, then the PMU processes a level 1 error.

Attachment 2-Q University Invention Disclosure Form

#39 Send PAU

call requests to

Traffic controller

#38 Determine

state of

pedestrian

signals

#40 Broadcast

state of

pedestrian

signals to PAUs

#41 Test for each

PAU response

#43 Initiate

diagnostics tasks

for level 2 error

No

Yes

#45 Validate PAU

audio message

state

#46 Audio

Message

error?

#42 PAU

communications

error?

Yes

No

#47 Initiate

diagnostics tasks

for level 1 error

Initiate operations

process

#44 250 ms

timeout?

No

Yes

Figure 10 Software flow diagram for PMU Operations

The diagnostics task illustrated by the flow diagram in Figure 11 processes all exceptions to normal operations. There are two levels of possible errors. Level 1 error represents potential unsafe condition (#48 and #52). A Level 1 error results in disabling all audible messages (#52) and halts operation (#53) until the AAPS is manually reset. The error message is displayed on

Attachment 2-R University Invention Disclosure Form

the AAPS LCD (#51) and signals are set on the traffic controller and the MMU or CM indicating a serious fault condition (#50). Level 2 errors represent a loss of communications with one or more pedestrian buttons. The operations of the AAPS continue for level 2 errors. A fault message indicating the button(s) failing to communicate on the LCD (#56). If the reason for the initiation of the diagnostics task cannot be identified, a specific error message is displayed on the LCD and the diagnostics task is terminated.

#48 Determine

Error level and

type

#50 Set fault

signal to TC and

MMU/CM

#57 Display

unknown

exception on LCD

Diagnostics Task

#49 Level

1 error?

Yes

No

#51 Send Level 1

fault message to

PAUs

#53 Halt operators

until reset

#54 Level

2 error?

Yes

No

#52 Display

Level 2 error on

LCD

#58 Terminate

diagnostics

#56 Display Level

1 error on LCD

Figure 11. Software flow diagram for diagnostics processor

The maintenance task is responsible for managing the maintenance WEB page hosted by the PMU. This software allows the user to set the parameters listed in Table 4. The maintenance task runs regardless of the operational status of the PAU.

c. PAU Software Operation

The PAU has three operational states: no calls standing, a standard pedestrian call in progress and an APS call in progress. The operations for the state when no pedestrian calls are in progress is defined by the flow diagram shown in Figure 12. If the PAU does not receive a SNMP set-request from the PMU every 250 ms or more frequently (#59), the fault processor is initiated (#60). Otherwise, the set-request message from the PMU is decoded (#61) to determine if the pedestrian call has been set as determined by the PMU set request message (#62). If true, it means that the pedestrian call is active in the traffic controller or in the PMU and was set by another method. The PMU set request message reports that the WALK signal is off (#64), then the call LED on the pedestrian button is turned on (#67), the audio locator tone (#68) continues to play and PAU waits for the next PMU set request message (#59). If the WALK signal is off, then the type of press is determined (#69) and either that APS walk process (#70) or the

Attachment 2-S University Invention Disclosure Form

standard walk process (#71) is initiated. If the local pedestrian button is active, then, a determination as to the type of call is made (#69) and the appropriate task initiated (#71 or #72) If neither the pedestrian call bit is set in the PMU set request message nor the local pedestrian button is active, then the pedestrian call LED is turned off (#65) and PAU waits for the next PMU set request message (#59).

#68 Output audio

locator tone

No Call in

Progress

#59 PMU

set-request

within 250

ms?

Yes

No

#62 PED

Call bit set

in PMU

message?

Yes

No

#60 Initiate fault

processor task

#61 Decode PMU

set-request

#63 Local

PED button

active?

#64 WALK

state?

Yes

No

#67 Set Call in

progress LED on

#65 Set Call in

progress LED off

No

#70 Initiate APS

walk process

#69 APS

cal?

#71 initiate

standard walk

process

Yes

Figure 12. Software flow diagram for quiescent operations of PAU

The software flow diagram for the standard call program is shown in Figure 13. It is called from the quiescent ―no call in progress‖ task described in Figure 12. There are two flags that control the state of the task once it is determined that a standard call has been placed on a particular PAU. The two flags are initially initialized (#74). The standard call task continues to get the PMU set request messages (#75) so it can be detect a loss of communications with the PMU and appropriately process the error. (#76). With neither ―waiting for walk‖ nor ―waiting for wait‖ flags set, the program determines if the pedestrian signal is currently in the WALK phase (#84).

Attachment 2-T University Invention Disclosure Form

Standard Call

Progress

#75 PMU

set-request

within 250

ms?

Yes

No #76 Initiate fault

processor task

#82 Initiate ―no

call in progress‖

task

No

#79 Mute audio

#86 Set ―waiting

for walk‖ flag

Yes

No

#83 Set Call in

progress LED on

#87 play ―WAIT‖

audio message

No

#77

―waiting for

walk‖ flag

set?

Yes

Yes

#80 Set ―waiting

for wait‖ flag

#84 WALK

signal on?

#74 reset ―wait

for wait‖ and ―wait

for walk‖ flags

#81

―waiting for

wait‖ flag

set?

#78 WALK

signal on?

Yes

No

#85 Set ―waiting

for wait‖ and

―waiting for walk‖

flags

#88 Send ―button

pressed‖

message to PMU

#89

Acknowledge

message from

PMU in < ??

sec?

#90 Initiate fault

processor task

Yes No

Figure 13. Software flow diagram for standard call

Attachment 2-U University Invention Disclosure Form

If currently in a WALK phase, both ―waiting for walk‖ and ―waiting for wait‖ flags are set before continuing to poll for a PMU set request message.. If the pedestrian signal is not currently in the WALK phase, only the ―waiting for walk‖ flag is set (#86), the audio message ―WAIT‖ starts to play (#87), and a SNMP trap message is sent to the PMU indicating that the call button has been activated for a standard call (#88). There must be an acknowledge message back from the PMU with in ?? seconds (#89) or a fault processing task (#90) will be initiated. Subsequent iterations on the software will evaluate the ―waiting for walk‖ test (#77) as true and the software will begin testing the ―state of the Walk signal (#78). If the WALK signal is off, the ―waiting for wait‖ flag is tested (#81). The program loop consisting of #75, #77, #78 and #81 will continue to execute until the Walk signal is detected on (#78). If the Walk signal is on, then the audio is muted (#79) and the ―waiting for wait‖ flag is set before repeating the test for PMU set request message. The program loop consisting of #75, #77, #78, #79 and #80 will execute until the WALK signal returns to the off condition. Finally, when the WALK signal is detected in the off condition (#78) and the ―waiting for wait‖ flag is set, the program returns execution of the ―no call in progress‖ task.

Figure 14 shows the process for an APS button activation. It generally follows the same process as the one for a standard button activation described by Figure 13. There are two flags that control the state of the task once it is determined that an APS call has been placed on a particular PAU. The two flags are initially initialized (#91). The standard call task continues to get the PMU set request messages (#92) so it can be detect a loss of communications with the PMU and appropriately process the error. (#93).

With neither ―waiting for walk‖ nor ―waiting for wait‖ flags set, the program plays the audio message describing the physical location of the button in relation to the intersection (#100). If the pedestrian signal is currently in the WALK phase (#101), the ―waiting for walk‖ and the ―waiting for wait‖ flags are set (#102) and the ―call acknowledge‖ LED on the pedestrian button is turned on (#110). The program then continues to wait for a PMU set request update (#92).

If the WALK signal is off (#101), then the ―waiting for walk‖ flag is set, the audio WAIT message plays (#106), and am APS button pressed message is sent to the PMU (#107). If the PAU receives no acknowledge from the PMU (#108), the fault processor is run (#109). Otherwise, the PAU will receive a beaconing position identifier (either none, initiation point or destination point) from the PMU (#111). The program acknowledges the call (#110) and continues to wait for the next PMU set request update (#92).

If after receiving a PMU update (#92) the ―waiting for walk‖ flag is found to be set (#94), the program determines whether the WALK signal is turned on (#95). The program executes a loop of instructions the consists of #92, #94, #95, and #103 until the WALK signal is turned on (#95)

Once the WALK signal is on, then the audio message indicating that the WALK signal is on and the vibrotactile output in activated. The program continues by setting the ―waiting for wait‖ flag (#97) and begins sending a message to the PMU indicating which audio message is being played at a one second rate (#98). Each time this message is send, the program must receive an acknowledge from the PMU within ?? ms (#99) or the fault progress is initiated (#93). If the acknowledge message from the PMU (#99) is received, the program continues by waiting for a PMU set request update (#92).

The program continues in a loop consisting of #92, #94, #95, #96, #97, and #99 until the WALK signal is turned off (#95). At this time, the program will determine that the ―waiting for wait‖ flag has been previously set and the task is completed by returning to the ―no call in progress‖ task (#104).

Attachment 2-V University Invention Disclosure Form

APS Call Progress

#92 PMU

set-request

within 250

ms?

Yes

No #93 Initiate fault

processor task

#104 Initiate ―no

call in progress‖

task

No

#96 play audio

Walk message

and vibrotactile

#105 Set ―waiting

for walk‖ flag

Yes

No

#100 Set Call in

progress LED on

and play location

message once

#106 play ―WAIT‖

audio message

No

#94

―waiting for

walk‖ flag

set?

Yes

Yes

#97 Set ―waiting

for wait‖ flag

#101

WALK

signal on?

#91 reset ―wait

for wait‖ and ―wait

for walk‖ flags

#103

―waiting for

wait‖ flag

set?

#95 WALK

signal on?

Yes

No

#102 Set ―waiting

for wait‖ and

―waiting for walk‖

flags

#107 Send ―APS

button pressed‖

message to PMU

#98 Send number

of audio message

to PMU (1 hz)

#108

Acknowledge

message from

PMU in < ??

sec?

#109 Initiate fault

processor task

#99

Acknowledge

message from

PMU in < ??

sec?

#110 get

beaconing

position from

PMU

No

Yes

Figure 14. Software flow diagram for the APS button pressed task

Attachment 2-W University Invention Disclosure Form

All errors or program exceptions in the PAU software execution are processed by the fault process task. The flow diagram for this task is shown in Figure 15. There are three major error groups: the network communications error (#112), an SNMP acknowledge error (#117) and an APS errors (#121 and #125). Network communications errors result in the termination of playing any audio messages (#114). The system watchdog timer is activated (#115) and the program halts execution (#116). When the watchdog timer time out, the processor is reset and attempts to establish network communication. This action continues until communications is restored or the unit is replaced. APS errors (#121 and #125) are reported to the PMU (#123) and APS operations are discontinued (#126). Unidentified exceptions are reported to the PMU (#126).

#11 Determine

Error level and

type

#114 turn off all

audio messages

#122 Turn off

audio

PAU Fault

Processor task

#113

Network

failure?

Yes

No

#115 Enable

Watchdog timer

#116 Halt

operators until

reset

Yes

No

#118 Resend

SNMP trap based

message

#117

Acknowledge

error?

#119 increment

error counter

#120 Error

counter >

limit?

Yes

#121 Audio

detected

error?

Yes

Yes

No

#123 send APS

error to PMU

#124 Disable APS

operation

No

#125

Vibrotactile

error?

Yes

#126 send

unknown

exception error to

PMU

Figure 15. Software flow diagram for PAU fault process

Attachment 2-X University Invention Disclosure Form

5. Describe why the invention is better or more effective than present state-of-the-art technology. What benefits does it provide? What problems does it solve? (Attach papers/presentations/abstracts that address these questions.)

Currently, pedestrians generate calls to traffic controller systems by closing a contact or activating a device that generates a low impedance electrical path to a ground potential on an input to traffic controller device. Information is constrained to be a binary signal relating to the button being in the pressed state or not and is supplied as an input to the traffic controller. On some pedestrian buttons, a light or LED is illuminated to indicate that a call has been placed to the traffic controller. This indication is generated solely by the pedestrian button and does not directly indicate that the traffic controller has actually received the pedestrian call (request for service).

Accessible Pedestrian Stations (APS) used at many intersections today broadcast audible speech messages based upon the state of pedestrian signals. These types of pedestrian signals are used to satisfy the American with Disabilities Act (ADA) to facilitate intersection crossing by those individuals who are those with visual and cognitive barriers. The state of the signals is monitored in the pedestrian signal display unit associated with the movement of pedestrian traffic. An audible message associated with the state of the pedestrian display is generated and communicated directly with a speaker in the close proximity of the pedestrian button. Examples of audible messages include ―Wait.‖, and ―Walk Main Street, walk light is on to cross, Main Street.‖

Within the traffic controller cabinet is a conflict monitor (CM) for NEMA TS1 type controllers or malfunction manage unit (MMU) for NEMA TS2 type controllers. The purpose of the CM or MMU is to monitor traffic and pedestrian signal outputs to ensure the lights provide for compatible traffic movements. In the event that the outputs generate non-compatible traffic movements, the CM or MMU assumes control of all traffic and pedestrian outputs and places them in the assigned safe-fail state. The philosophy for failure detection is based upon the fact that all decisions for managing traffic movements are made by the traffic controller and that the signal outputs are accessible inside the traffic controller cabinet.

The audio messages generated by the APS have the same degree of control of pedestrian movements for people who are vision impaired as the WALK and WAIT pedestrian signals do for people who have good visual acuity. The audio messages are generated in response to pedestrian signal outputs but are not under the direct control of the traffic controller and are not observable by the CM or the MMU. This generates a safety risk that has not been addressed until now because there was no means to monitor the activity of the processor generating the audio messages.

The AAPS does this by first identifying the user who needs this capability (using assistance activation calls such as extended press or remote calls) and then activating an audible signal the corresponding destination PAU. Although the concept of beaconing is implemented in at least one current design (Campbell Company), it is not a feature of NEMA TS1 or TS2 controllers and hence must be implemented entirely with in the scope of the APS.

Campbell Company currently offers beaconing with the Advisor APS system. This is accomplished by activating both driver boards by connecting the pedestrian buttons at the initiation and destination points through a synchronization wire to bypass a physical press of the button. The target beacon consists of a elevated volume for the pedestrian clearance phase. By providing the target beacon the pedestrian should be (walk display duration x 3.5 feet per second) into the crossing. Hopefully this is at least half way across, the walk phase message ends with the flashing don’t walk and the elevated locator tone begins for the predetermined time which is programmed into the voice chip for up to 30 seconds.

6. List up to ten (10) key words that help describe or that relate to the work.

accessible pedestrian signals, pedestrian signals, networked controls, distributed processing

Attachment 2-Y University Invention Disclosure Form

7. Have products, apparatus, compositions of matter, etc. actually been made? Tested? Is there a prototype? How would you describe the present state of development of the invention?

Most of the functionality of this patent has been constructed and tested. The circuit boards for the PMU and the PAU are under design. The only function to be tested is the WWVB receiver and we anticipate completing that testing by the end of August.

8. Do you know of any companies that might be interested in your discovery or invention? Yes No

If yes, please list the companies, contacts, addresses, and phone numbers:

Campbell Company, Boise, ID

Polara


Attachment 3 — Public Disclosures

1. Has the invention been described or discussed in any journal, abstract, paper, oral presentation, news story, thesis, dissertation or other medium? Yes No

If yes, date: Medium (journal, conference, etc.):

Name of journal, conference, etc.:

Attach copy of abstract, presentation, thesis/ dissertation, etc.

2. Has there been any past public use, sale, or offer for sale of the invention? Yes No

If yes, date:

Describe circumstances, including contact person(s), etc.:

3. Is a publication or other disclosure planned? Yes No

If yes, date: Medium (journal, conference, etc.):

Name of journal, conference, etc.:

Attach copy of abstract, presentation, thesis/ dissertation, etc.

4. Has the invention been disclosed or discussed with industry representatives? Yes No

If yes, date: August 2007

Describe circumstances, including contact person(s), etc.:

Phil Tate, President, Campbell Company, Boise ID

5. Have there been any other disclosures of the invention? If so, please explain:

None


Attachment 4 — Research Funding, Sponsorship, and Support Information

List all of the funding agencies, companies, organizations and sponsors of the research that led to this discovery or invention, including those who supplied materials under a formal Material Transfer Agreement (MTA) prior to invention or reduction to practice. If none, please enter ―none.‖ If more space is required, copy this page or attach additional pages as needed.

Name of sponsor (agency/foundation/company/etc.):

Idaho State Board of Education

Sponsor’s grant/project number:

OSP number: KLK2798

Principal investigator: Richard Wall

Grant/contract/project title: Advanced Interactive Signals for Able-bodied and Disabled Pedestrians

Funding period: 1/22/2008 – 7/25/2009


NIATT / UTC

Sponsor’s grant/project number:

OSP number: KLK710


Grant/contract/project title: Commercialization and Field Distribution of Smart Pedestrian Call Signals

Funding period: 8/31/2007 – 8/31/2008


Campbell Company

Sponsor’s grant/project number: TBD

OSP number: TBD


Grant/contract/project title: TBD

Funding period: TBD

Name of materials provider, if any:

University MTA Number:

Related OSP number, if any:

Related grant/contract/project title, if any:

What University support has this discovery or invention received?

Facilities: Department of Electrical and Computer Engineering, NIATT

Funding:

Services:

Other support (e.g., release time, paid technical assistance, etc):

Are/were there any other sources of support for this discovery or invention? If so, please explain:

Cypress Semiconductor equipment grant

confidential and proprietary€¦ · of the invention may invalidate any patent for this invention....

Documents

Transcript of confidential and proprietary€¦ · of the invention may invalidate any patent for this invention....