KLK266 Final Report - University of Idaho€¦ · 13. Type of Report and Period Covered Final Report: September 2008 – June 2014 14. Sponsoring Agency Campbell Company 15. Supplementary

ADVANCED ACCESSIBLE PEDESTRIAN SYSTEM

KLK266 Final Report

University of Idaho

National Institute for Advanced Transportation Technology

Dr. Richard W. Wall

June 2014

1. Report No. 2. Government

Accession No.

3. Recipient’s Catalog No.

4. Title and Subtitle

Advance Accessible Pedestrian Systems

5. Report Date

June 2014

6. Performing Organization

Code

KLK266

7. Author(s)

Wall, Richard W.

8. Performing Organization

Report No.

N14-14

9. Performing Organization Name and Address 10. Work Unit No. (TRAIS)

National Institute for Advanced Transportation Technology

University of Idaho

875 Perimeter Dr. MS0901

Moscow, ID 83844-0901

11. Contract or Grant No.

09069

12. Sponsoring Agency Name and Address

Mr. Phil Tate

Campbell Company

450 W. McGregor Dr.

Boise, ID 83705

13. Type of Report and

Period Covered

Final Report: September

2008 – June 2014

14. Sponsoring Agency

Campbell Company

15. Supplementary Notes:

16. Abstract: A networked based Accessible Pedestrian Systems (APS) was developed over a period of 10

years in conjunction with $1.2M funding through Federal, Idaho State, and private industry grants and

contracts. The system is based on the Smart Signals enabling technology that uses modern distributed

processing concepts to form a spatially dispersed information and control system. The development

process followed the spiral design methodology typically used for innovative and new designs where

complexity and functionality is added in iterative cycles of propose, assess, design, and evaluate

phases. A complete system was designed that is currently being manufactured and distributed by

Campbell Company of Boise, Idaho. The engineering designs for a second generation of Smart Signals

APS have been completed that enhance the capabilities of the first generation while reducing

manufacturing and installation costs. Nine graduate students worked on this project of whom three are

currently working in the traffic control industry. Technical descriptions of the two systems are

provided in report appendices.

17. Key Words: Pedestrian,

Accessible, Traffic Controls,

Distributed Systems,

18. Distribution Statement: Unrestricted; Document is

available to the public through the National

Institute for Advanced Transportation Technology;

Moscow, ID.

19. Security Classif.

(of this report)

Unclassified

20. Security Classif. (of

this page)

Unclassified

21. No. of

Pages

51

22. Price

…

Form DOT F 1700.7 (8-72) Reproduction of completed page authorized

ADVANCED ACCESSIBLE PEDESTRIAN SYSTEMS i

TABLE OF CONTENTS

FIGURES .................................................................................................................................. ii

TABLES .................................................................................................................................. iii

EXECUTIVE SUMMARY ...................................................................................................... 1

ACKNOWLEDGMENTS ........................................................................................................ 3

DESCRIPTION OF PROBLEM............................................................................................... 4

APPROACH AND METHODOLOGY ................................................................................... 6

FINDINGS ................................................................................................................................ 9

PHASE I: ADVANCED ACCESSIBLE PEDESTRIAN SYSTEM DESIGN .................. 9

PHASE II: TECHNOLOGY TRANSFER ....................................................................... 10

PHASE III: ADVANCED ACCESSIBLE PEDESTRIAN SYSTEM REDESIGN ........ 11

CONCLUSIONS..................................................................................................................... 14

RECOMENDATIONS ........................................................................................................... 15

APPENDIX ............................................................................................................................. 16

APPENDIX A - Record of AAPS Funding ...................................................................... 16

APPENDIX B – AAPSI System Specifications ............................................................... 17

APPENDIX C – AAPS I Hardware and Software Reference Manual ............................. 20

General Information .................................................................................................... 20

AAPS I - A Networked Based APS System - Theory of Operation ........................... 21

AAPS I System Architecture ...................................................................................... 22

The Advanced Pedestrian Controller .......................................................................... 23

The Advanced Pedestrian Button ................................................................................ 24

AAPS I Communications ............................................................................................ 25

Network Communications .......................................................................................... 26

AAPS I Hardware Documentation.............................................................................. 35

APPENDIX D - Review of Initial Test Field Installation ................................................ 39

APPENDIX E - AAPS II Technical Description .............................................................. 42

AAPS II Advance Pedestrian Coordinator ................................................................. 42

AAPS II Advanced Pedestrian Button (APB) ............................................................ 47

REFERENCES ....................................................................................................................... 50

ADVANCED ACCESSIBLE PEDESTRIAN SYSTEMS ii

FIGURES

Figure 1. Spiral Design Model .................................................................................................. 7

Figure 2. AAPS I System Block Diagram .............................................................................. 10

Figure 3. AAPS II Block Diagram .......................................................................................... 12

Figure 4. Advanced Accessible Pedestrian System Block Diagram Showing Direct Wire

Interface with NEMA TS1 and TS2 Type 1 Traffic Controllers ............................................ 18

Figure 5. AAPS Block Diagram Showing Direct Wire Interface with NEMA TS2 Traffic

Controllers............................................................................................................................... 19

Figure 6. AAPS I System Block Diagram .............................................................................. 22

Figure 7: Block Diagram of Advanced Pedestrian Coordinator ............................................. 24

Figure 8: Block Diagram of Advanced Pedestrian Button ..................................................... 25

Figure 9. Partial NTCIP Standards Framework ...................................................................... 27

Figure 10. Installation of the AAPS I at 6th and Deakin Streets in Moscow, ID. .................. 35

Figure 11. ATMEL NGW100 with AVR32 Processor and Linux Operating System ........... 36

Figure 12. Picture of APC I PCB Side A ................................................................................ 37

Figure 13. Picture of APB I PCB Side A ................................................................................ 38

Figure 14. Picture of APB PCB Side B .................................................................................. 38

Figure 15. Climate Conditions during the Initial Minnesota Field Installation ...................... 39

Figure 16. Minnesota Installation Activity ............................................................................. 40

Figure 17. AAPS II APC Block Diagram ............................................................................... 43

Figure 18. APC II Communications and Power Supply Module Block Diagram .................. 43

Figure 19. AAPS II Communication Unit Printed Circuit Board ........................................... 44

Figure 20. AAPS II Cabinet Interface Module Block Diagram .............................................. 44

Figure 21. AAPS II Cabinet Interface Unit Parts Layout – Side A Photo .............................. 45

Figure 22. AAPS II Cabinet Interface Unit Parts Layout – Side B Photo .............................. 46

Figure 23. Front Panel Display Used for AAPS I and AAPS II ............................................. 47

Figure 24. AAPS II Accessible Pedestrian Button Block Diagram ........................................ 48

Figure 25. AAPS II ABP Printed Circuit Board - Side A Photo ............................................ 49

Figure 26. AAPS II ABP Printed Circuit Board - Side B Photo............................................. 49

ADVANCED ACCESSIBLE PEDESTRIAN SYSTEMS iii

TABLES

Table 1: Intersection OID Definitions .................................................................................... 32

Table 2: Station Trap OID Definitions ................................................................................... 32

Table 3: Configuration OID Definitions ................................................................................. 33

ADVANCED ACCESSIBLE PEDESTRIAN SYSTEMS 1

EXECUTIVE SUMMARY

Even though there is no age, physical capability, or degree of cognitive ability

limitations, the pedestrian represents the user of signalized intersections who is the most at

risk. The Americans with Disabilities Act (ADA) of 1990 recognizes that people with

physical limitations that require a social infrastructure that allows for independent and low

cost travel. Not until the 2000 edition of the Federal Highways Manual for Uniform Traffic

Devices were the needs of handicapped pedestrian addressed. Traffic industry manufacturers

began to manufacture systems known as Accessible Pedestrian Systems or APS. The first

systems required special interfaces with the pedestrian signals to determine the state of the

WALK and WAIT signals.

In 2004, research at the University of Idaho began that looked at new ways of

operating traffic signals. The new approach is comparable to the way in which we used to use

computers – one large centralized office computer versus many smaller computers

distributed over many desks. The new approach is known as Smart Signals where the traffic

control logic is distributed around to the signals themselves.

The pilot demonstration targeted the APS controls initially because of the perceived

low risk of the research. In 2008, a UI researcher contacted a pedestrian manufacture,

Campbell Company of Boise, Idaho, and they formed a research association to develop a

Smart Signals based APS system. In 2010, the first system was field tested in St. Paul,

Minnesota. Subsequently, over 400 intersections have been equipped with Smart Signal

based APS.

The research project is the culmination of ten years research activity and over $1.2M

funding from Federal, State, and private industry. This report discusses the iterative spiral

design method used to develop the innovative APS. The research was completed in three

phases in which two systems were produced. The second system is an enhanced version of

the first. In the process, nine students received their Masters degrees and over 20

undergraduates participated in the research project.


Information in the appendix of this report documents some of the design details to

provide a sense of the scope of engineering required.


ACKNOWLEDGMENTS

We wish to thank the employees and management of Campbell Company for their

funding support, technical advice, and hosting many of the pedestrian workshops. We are

also thankful for the technical guidance we received from Gary Duncan of Econolite

Controls, Inc. and Scott Evans of Eberle Design, Inc. We also acknowledge the assistance

and office support by the staff with the University of Idaho NIATT center. We wish to also

thank the University of Idaho Department of Electrical and Computer Engineering for the

technical support in the construction of the electronic circuit boards developed under this

research grant. Finally, the principle investigators wish to thank the graduate and

undergraduate students who spent many hours bringing the designs to fruition.


DESCRIPTION OF PROBLEM

Traffic signals are society’s solution to allocation of a shared scarce resource. At most

urban and intercity signalized intersections, vehicles and pedestrians must use a common

surface area known as the traffic intersection. The conflict that results has been long

recognized as demonstrated in this statement in the Federal Highway Signal Timing Manual:

“The amount of time in an hour is fixed, as is the fact that two vehicles (or a vehicle and a

pedestrian) cannot safely occupy the same space at the same time [1].” It is well

acknowledged that the pedestrian is the party at greatest risk in a vehicle-pedestrian crash.

The Center for Disease Control (CDC) reports: “In 2010, 4,280 pedestrians were killed in

traffic crashes in the United States, and another 70,000 pedestrians were injured. This

averages to one crash-related pedestrian death every 2 hours, and a pedestrian injury every 8

minutes. Pedestrians are 1.5 times more likely than passenger vehicle occupants to be killed

in a car crash on each trip [2].” One needs to consider the fact the CDC webpage reports that

the state of Montana reported a higher death rate per 100,000 population higher than Illinois.

If the pedestrian has vision impairment, the crash statics indicate a much higher risk. A

National Cooperative Highway Research Program (NCHRP) report states “In the ACB

survey (of vision impaired pedestrians), 12 of 158 (8%) of respondents had been struck by a

car at an intersection, and 45 (28%) had had their long canes run over [3].”

Why is pedestrian travel so inherently dangerous? One explanation could lie in the

difference in energy possessed by the pedestrian and the vehicle as well as their ability (or

inability) to absorb that energy should they collide. The only viable solution is to avoid

pedestrian-vehicle crashes altogether. Regardless of liability or right-of-way, the pedestrian

who is at the greater risk of injury, is obligated to assume the higher degree of awareness to

avoid crashes. The purpose of accessible pedestrian signals is, in part, to provide information

to the pedestrian in making safe decisions before entering the danger zone known as the

crosswalk. Accessible Pedestrian Systems (APS) are designed to address the legal

requirements of Americans with Disabilities Act of 1990 [4]. The 2009 Manual for Uniform

Traffic Control Devices (MUTCD) Section 1A.13 [5] defines an accessible pedestrian signal

as being a device that communicates information about pedestrian signal timing in non-visual


formats such as audible tones, speech messages, and/or vibrating surfaces. An APS detector

is defined as a device designated to assist the pedestrian who has visual or physical

disabilities in activating the pedestrian phase. The research provided by this contract resulted

in an advanced APS designed to provide all pedestrians regardless of ability or disability with

a safer crossing at signalized intersections.

From the initial concept, the Advanced Accessible Pedestrian System (AAPS) was

focused on producing hardware that would be installed at signalized intersections in

conjunction with traffic controllers. This system has both a customer and a user. The

customer is responsible for purchasing, installing and maintaining the system. The user is the

person who operates the system. The design objectives embraced by this research project

addressed the needs and wishes of both groups: the customer wants a system that is

affordable and easy to maintain while the user wants a system that provides safe access to the

intersection crosswalk.


APPROACH AND METHODOLOGY

The overall goal of this research project was to develop an APS based upon Smart

Signal technology. During the course of this project, numerous technological solutions were

investigated and evaluated on the basis of performance, cost, reliability, and sustainability.

This research project spanned a period of ten years using both government and private

sources to provide the $1.2M funding as detailed in Appendix A. The ten years of

development is divided into three phases: the initial system development, technology

transfer, and system refinement through redesign. Appendix B contains the initial statement

of work that was granted by Campbell Company through June 30, 2014.

Smart Signals is a term used to describe the application of network based distributed

control technology to the control of traffic signals at signalized intersections. Presently,

signalized intersections use a centralized control approach where all of the control actions are

initiated by a single computer-based device located in a traffic equipment cabinet. Dedicated

wires are used to turn signal lights on and off. The Smart Signals paradigm uses

microprocessors located in the signals to distribute the control intelligence. This approach

has the advantage of local control with performance enhancement due to information

obtained through communications with a distributed sensor system. As applied to accessible

pedestrian systems, each pedestrian button is responsible for providing the safest operations

for the pedestrian regardless of connectivity with other elements of the intersection control.

In this paradigm, each pedestrian station is an autonomous master controller with

other pedestrian stations and the coordinator that monitors the status of the traffic signals

serving as smart sensors. Each device performs an element of the pedestrian interface with

the traffic signal controller as well that of a smart sensor hence the nomenclature of “smart

signals.” It will be shown that the resulting design descriptions of the AAPS follow this

distributed control philosophy.

The design approach for the development of the AAPS followed the spiral design

process first proposed by Boehm [6] that is applicable for the development of new products


and systems. This design approach uses an iterative cycle of four activity phases as illustrated

in Figure 1.

Figure 1. Spiral Design Model

This design approach uses risk assessment to guide product capability which is in

contrast to the waterfall design approach that is a single pass development cycle that often

results in time and cost overrun [7]. The spiral design methodology uses the six following

underlying assumptions that were followed in the design of the AAPS:

1. The requirements are known in advance of implementation.

2. The requirements have no unresolved, high-risk implications, such as risks due to cost,

schedule, performance, safety, security, user interfaces, organizational impacts, etc.

3. The nature of the requirements will not change very much during development or evolution.

4. The requirements are compatible with all the key system stakeholders’ expectations,

including users, customers, developers, maintainers, and investors.


5. The right architecture for implementing the requirements is well understood.

6. There is enough calendar time to proceed sequentially.

Functional requirements were established with the aid of manufacturing experience of

Campbell Company using the basic requirements of an APS as set forth in the Chapter 4E of

the 2009 MUTCD. Five workshops were conducted over the course of this project to inform

and solicit input from public users, equipment manufacturers, traffic agency professionals,

and researchers. The feedback from these workshops as well as frequent discussions with

Campbell Company employees, traffic agency engineers, and pedestrian advocate groups

through Transportation Research Board (TRB) meetings resulted in additional requirements

for performance and capability.

The United States Department of Transportation (US DOT) University Transportation

Centers (UTC) research projects, that were the major source of funding for the development

of the AAPS, required annually establishing goals and assessing results. The UTC project

funding cycle fit well into the spiral design model.

Because of previous design experience, the faculty who worked on this project was

responsible for a majority of the system architecture and hardware design. Staff provided

most of the hardware fabrication and assembly. Students were responsible for developing a

majority of the system computer code.

The mission of the University of Idaho is stated as “The University of Idaho is the

state’s land-grant research university. From this distinctive origin and identity comes our

commitment to enhance the scientific, economic, social, legal, and cultural assets of our state,

and to develop solutions for complex problems facing society. … Our teaching and learning

includes undergraduate, graduate, professional, and continuing education offered through

both resident instruction and extended delivery. Our educational programs are enriched by

the knowledge, collaboration, diversity, and creativity of our faculty, students, and staff [8].”

The research funding was used to provide financial assistance to the undergraduate

and graduate students who provided technical services relating to the engineering design of

the AAPS.


FINDINGS

The AAPS designs resulted in proprietary custom hardware and many tens of

thousands of lines of computer code. The system is a true distributed computing platform that

provides processing capability as physically close to the actuators and sensors as possible.

The result being improved service reliability and reduced infrastructure cost for

implementing APS capability at new and existing signalized intersections. The software-

based system is extensible allowing the system capability to be adapted and expanded to suit

future requirements as well as incorporate future pedestrian interfaces. Appendix C and E

provide a more detailed description of the hardware that was developed, fabricated, and

tested as part of this project. Because this is a software based system, the program code is not

reported except in abstraction that describes the system functionality. Proprietary engineering

documentation is also excluded from this document to protect the licensee of this technology.

PHASE I: ADVANCED ACCESSIBLE PEDESTRIAN SYSTEM DESIGN

A block diagram of the AAPS I system is shown in Figure 2. The AAPS I hardware

represented by the yellow rectangles consists of an Advanced Pedestrian Coordinator (APC)

that is installed in the traffic controller cabinet and multiple Advanced Pedestrian Buttons

(APB) installed at each crosswalk entry as specified by the MUTCD.

The APC monitors the 120 VAC outputs to the pedestrian signals to determine their

status. The signal status is communicated to all of the pedestrian stations where the APBs are

located using the communications provided by the low voltage Ethernet over Power line

(EoP) network. Each APB operates independently to determine the outputs to the local LED,

the vibrotactile actuator, and the audible message that is played. When a pedestrian presses a

button at the intersection crosswalk, a message is immediately sent to the APC that in turn

activates one of the PED CALL inputs to the traffic controller. A more detailed description of

the operation is provided in Appendix C.


TS1/TS2 – 170/270/2070

Traffic Controller

Signal Load

Switches

Existing

Traffic and

Pedestrian

Signals

Advanced

Pedestrian

Coordinator

Existing

Pedestrian

Call Inputs

Lo

w V

olta

ge

Po

we

r D

istr

ibu

tio

n

an

d C

om

mu

nic

atio

ns N

etw

ork

APB1

APB2

APBn

APC

Maintenance

Interface

Cabinet

Power

Figure 2. AAPS I System Block Diagram

The AAPS I system development phase was capped with a pilot installation in St.

Paul, Minnesota as described in Appendix D.

PHASE II: TECHNOLOGY TRANSFER

After the test installation in Minnesota, the APB hardware design underwent three

hardware redesigns and the APC underwent two hardware redesigns. University of Idaho

Researchers assisted in the initial production of the AAPS I by providing a circuit board

engineering files, computer software for the APC and APB units, and detailed parts and

supplier list. Tate Engineering of Spokane, Washington was responsible for the initial

hardware production. Graduate students at the University of Idaho worked closely with

Campbell Company engineers to validate the hardware and software components of the

design. Numerous modifications were made to the hardware (see Appendix C) and as well

almost continuous modifications to the software of the APC and ABP computer code. This

phase concluded when two of the research assistants who contributed significantly to the

development were hired as full-time Campbell Company employees.


An element of the technical transfer is the dissemination of information regarding

engineering advances. The University of Idaho Mission Statement clearly identifies the

educational component of research as an essential element of technology transfer. Over the

course of the Smart Signals research, nine Electrical or Computer Engineering students have

completed their Master of Science or Master of Engineering degrees. In addition over 20

undergraduate students worked as graduate assistants – some of whom proceeded on to

complete advanced degrees. Contributing to the technical transfer effort, two scientific

journal papers and technical conference papers have been published. In addition to the

technical papers, there were nine conference presentations, five pedestrian workshops, and

two patent awards in the area of pedestrian signals.

PHASE III: ADVANCED ACCESSIBLE PEDESTRIAN SYSTEM REDESIGN

The hardware was specifically designed to be easily adapted to changing functional

requirements. For example, portioning the pedestrian controller into three modules allows

upgrading one hardware module and reusing the remaining modules. The three custom

circuit boards were thoroughly tested in the course of this phase of the project. The

significant design enhancements are:

1. Enhanced EoP communications allows for a tenfold increase in the number of

pedestrian stations and information exchange.

2. Modular design allows for better packaging and partial hardware upgrading.

3. No-cost software development tools reduce development costs.

4. Using advance semiconductor technologies reduces both system equipment and

installation costs.

The additional hardware capability provides a system platform for investigating

pedestrian assistance through tracking and guidance.

The improvements relating to the three hardware units are discussed in Appendix E.

These circuit boards were designed such that technicians employed at the University of Idaho

were able to populate the circuit board in phases to allow thorough testing. As such, the

fabrication capability at the University of Idaho limit the trace spacing of the circuits and size

of components used on the circuit board.


The spiral design methodology used to achieve objectives of the redesign allowed the

examination of new technologies, review of user and customer requirements, and anticipation

of future needs. Much of the work was an iterative process to test and redesign the hardware

and software and insure the interface circuitry did not fail. Assessment of customization and

recommended practices is an on-going process that involves interactions and feedback from

traffic engineers and technicians.

The overall objective of the research was to establish a hardware platform that is

extensible and useable in a wide range of environments and applications by defining the

system operations, to the extent possible, in software. Figure 3 provides a block diagram of

the AAPS II system. The key element in this design is the Synchronous Data Link Control

(SDLC) interface between the pedestrian controller and the traffic controller. Although the

bus type network is comparable in structure to the first generation AAPS, the hardware that

uses the network is a new design with much higher capability. In this design, the pedestrian

button station can now serve as a communication hub for higher-level functions such as

pedestrian guidance assistance. A detailed description of the hardware associated with the

AAPS II is described in Appendix E.

Traffic

Controller

Signal

Load

Switches

Existing

Signals

Pedestrian

Controller

Power PC

EoP

12-2

4 V

AC

MMUDetectors

SDLC

BUS

EoP APS

APB

EoP APS

APB

EoP APS

APB

EoP APS

APBPED

CALLS

Figure 3. AAPS II Block Diagram


All software and hardware engineering design files associated with both AAPS I and

AAPS II system have been delivered to Campbell Company as of June 1, 2014. AAPS II has

been laboratory tested but there have been no field trials to date.


CONCLUSIONS

The level of funding and the diversity of groups who funded this research indicate

that the devices and products produced as a result of the ten years of research have value to

society. A completed system was produced that is being manufactured and sold by Campbell

Company of Boise, Idaho and is in use at over 400 intersections in the United States. In light

of this success, we are allowed to proclaim as did an ancient Italian circa 46 B.C. “Vene vidi

vici.”

Three graduate students who worked on this project are now employed in traffic

equipment manufacturing industries two of whom are employed by Campbell Company and

are responsible for carrying this research forward.

The success of the Smart Signals application to pedestrian controls indicated that this

technology can be expanded to all traffic control signals to enhance capability and reduce the

expense of signalized intersections.

This is my last year of teaching and research before retiring from academic life. The

Smart Signals research has been my crowning engineering achievement. It is my hope that I

have passed on my enthusiasm for transportation research and the love of the discipline of

engineering.


RECOMENDATIONS

1. Pedestrian tracking is currently receiving a significant amount of interest. The

obvious benefactor is the low vision pedestrian. The interest is mostly due to the

sensor suite provided with the ambitious smart phone. Now that Smart Signals places

capable infrastructure at traffic intersections, research is needed to determine how

best to complete the connection between pedestrian and traffic controller.

2. The transportation industry has become accustomed to having a monitor to verify that

the traffic controller does not put vehicle operators and pedestrians at risk due to an

equipment failure. In the transition from NEMA TS1 controllers to TS2, the conflict

monitor (CM) has evolved into the malfunction management unit (MMU). Both are

based on the concept the monitoring device can observe all of the outputs that the

intersection uses are seen. This is possible only because all of the traffic control

equipment is constrained to the physical space of the traffic controller equipment

cabinet. In the Smart Signals environment, the problem of equipment malfunction

still exists but the solution is quite different since the logic that produces the outputs

are spatially distributed. Before the Smart Signals technology can be reliably

extended to all traffic signals, an inexpensive and reliable monitoring system must be

developed to replace the CM and MMU.


APPENDIX

APPENDIX A - Record of AAPS Funding

Date Source Project Title Amount

June 2004 USDOT Plug and Play (PnP) Smart Sensor Traffic

Signals System

$99,556

August 2005 USDOT Full Scale Implementation of Plug and Play

Smart Traffic Signal and Pedestrian Wait/Walk

Display with PED button

$90,000

August 2006 USDOT Conflict Monitor for Plug and Play Distributed

Smart Signals and Sensors for Traffic

Controllers

$100,000

August 2007 USDOT Street Deployment of Pedestrian Control Smart

Traffic Signals

$97,303

August 2008 Idaho

SBOE

Advanced Interactive Signals for Able-bodied

and Disabled Pedestrians

$75,000

August 2008 USDOT Commercialization and Field Distribution of

Smart Pedestrian Call Signal

$117,357

September

2008

Campbell

Co.

Networked Accessible Pedestrian Signals $60,520

August 2009 USDOT Closed Loop Operation of Network Based

Accessible Pedestrian Signals

$111,723

August 2010 USDOT Smart Signals Countdown Pedestrian Signal $124,633

September

2010

Campbell

Co.

Networked Accessible Pedestrian Signals -

extended

$61,667

August 2011 USDOT Improving Pedestrian Safety at Signalized

Intersections

$120,281

June 2011 Idaho

SBOE

Development of an Independent Fault

Monitoring to Increase Safety and Marketability

of the Advanced Accessible Pedestrian System,

$39,400

August 2012 USDOT Second Generation Accessible Pedestrian

Systems

$59,978

August 2013 USDOT A Framework for Improved Safety and

Accessibility through Pedestrian Guidance and

Navigation

$60,000

Total Project Funding $1,217,418


APPENDIX B – AAPSI System Specifications

1. The primary purpose of Smart Signals Pedestrian Call System is to provide safe and reliable

access for able bodied and disabled pedestrians using an architecture for information

exchanged that is scalable in both scope of control and range of devices used to register a

request for service to signal traffic controllers.

2. Assure that all human interfaces comply with the Manual for Uniform Traffic Controller

Devices (MUTCD) regarding Accessible Pedestrian Stations (APS) and the American with

Disabilities Act (ADA).

3. The system described in Figures 1 through 4 capable of implementing the following features:

a. System operations for placing pedestrian requests for service that are compatible with

existing TS1 and TS2 type traffic controllers.

b. A system that consists of one Pedestrian Management Unit (PMU) and one or more

Pedestrian Activation Unit (PAU).

c. The AAPS will interface with NEMA TS1 and TS2 type 2 traffic controllers as shown

in Figure 4.

d. The AAPS will interface with NEMA TS2 type 1 and type 2 traffic controllers as

shown in Figure 5.

e. A system that uses two wires of gauge and insulation rating consistent with current

traffic system installation practices.

f. A system that meets or exceeds the National Electric Code requirements regarding

power distribution.

g. A system that meets or exceeds ADA and MUTCD requirements for APS pedestrian

stations.

h. A system capable of performing system wide diagnostics, recording events regarding

failures as well as normal operations.

i. A system capable of identifying unique calls, both type and location, for special

service that can change normal traffic controller timing operations.

j. A system capable of providing estimated wait time before the pedestrian Walk sign is

on.

4. One each fully functional prototype unit of the APC and the APB devices

5. All engineering electrical and mechanical drawings, microprocessor source code, code

libraries, compliance and performance test data, and instructions for construction, installation

and maintenance.


#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 4. Advanced Accessible Pedestrian System Block Diagram Showing Direct

Wire Interface with NEMA TS1 and TS2 Type 1 Traffic Controllers


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 5. AAPS Block Diagram Showing Direct Wire Interface with NEMA TS2

Traffic Controllers


APPENDIX C – AAPS I Hardware and Software Reference Manual

This appendix contains the engineering technical details for the fabrication, assembly,

and programming of the AAPS I System. There are two major components to the AAPS: The

Advanced Pedestrian Coordinator (APC) and from 1 to 16 Advanced Pedestrian Buttons

(APB). The APC communicates with all APBs using Ethernet over Power line (EoP)

technology.

General Information

This appendix contains instructions for installation and operations of the advanced

accessible pedestrian signals (AAPS) system.

The AAPS I is designed to facilitate the latest ADA requirements for Accessible

Pedestrian Signals (APS) using low voltage EoP technology.

1. Pedestrian station configuration and diagnostic is completed entirely from the

traffic controller.

2. Periodic communications with all pedestrian stations facilitates rapid failure

detection.

3. Pedestrian communications failures are time-stamped and logged on the

AAPS controller.

4. Pedestrian communications failures cause a red LED to be illuminated of the

AAPS I controller unit.

Existing pedestrian station field wiring can be utilized for connecting the Advanced

Pedestrian Buttons (APB) located in the intersection crosswalks and the Advanced

Pedestrian Coordinator (APC) located in the traffic cabinet.

The AAPS I is powered by 120 VAC in the traffic controller cabinet and distributes

12-18 VAC power to all pedestrian stations.

The AAPS I uses a web based interface eliminating the need for application specific

software. The APC contains no key pads or text display thus reducing both size and

expense.

1. Computers used for system setup and diagnostics need only a standard web

browser.

2. Audio files can be changed in the field for any pedestrian station at the

intersection using the web interface.


3. The AAPS system is completely configured using web based menus and

selection boxes.

4. System pedestrian station operations, pedestrian signals status, and pedestrian

call operations is monitored and displayed on the AAPS system webpage.

5. A real-time clock with battery backup allows time-of-day audio volume

control.

6. Maintenance operations are logged and time-stamped on the APC and can be

downloaded to a computer using the interface webpage.

7. The Ethernet interface facilitates remote connection to the AAPS system for

diagnostics and monitoring of pedestrian calls.

8. Web security was provided by password protection.

The APC monitors the pedestrian signals for all pedestrian stations from inside the

traffic controller cabinet.

The APC interfaces with the traffic control system using direct wiring between the

APC and the 120 VAC outputs to the pedestrian signals and the conventional

pedestrian station inputs.

APB stations are completely self-contained. No field wiring is required between

individual pedestrian signals and pedestrian stations.

AAPS I - A Networked Based APS System - Theory of Operation

Introduction

The AAPS system was designed to address many of the issues noted in the

paragraphs above. The network approach makes use of the fact that microprocessors are

already required to implement the complex control needed to play different audio messages

depending upon pedestrian signal status and the operation of pedestrian buttons. Using

distributed processing technologies allows bidirectional communication of information

relating to operating controls and possible failure modes. Ethernet was chosen for

communications because of its high bandwidth, wide spread use in industrial controls and the

availability of low cost electronic hardware to support this technology.

Although some of the operating features will be described below, the hardware to

support the AAPS is highly scalable in both number of pedestrian buttons and the modes of


operation. The basic hardware and software are the result of research in the application of

distributed systems concepts at the University of Idaho that has been reported on, starting in

2006 [9,10,11].

Using a distributed approach, each pedestrian button is uniquely distinguishable thus

enabling the use of beaconing on one side of an intersection only.

AAPS I System Architecture

Figure 6 shows the system architecture for the AAPS I system. The hardware consists

of an APC and one or more APB connected by a low voltage power conductor and a

common ground or reference conductor. The APC interfaces with the traffic controller

cabinet using existing field wiring terminals. The APC senses the pedestrian signal status by

monitoring the 120 VAC load switch outputs. Pedestrian calls are placed by the APC using

the conventional terminals for pedestrian button inputs. Although not shown in Figure 6, it is

possible to simultaneously operate both conventional APS and AAPS pedestrian stations

provided the two systems use separate conductors for power and communications.

TS1/TS2 – 170/270/2070

Traffic Controller

Signal Load

Switches

Existing

Traffic and

Pedestrian

Signals

Advanced

Pedestrian

Controller

Existing

Pedestrian

Call Inputs

Lo

w V

olta

ge

Po

we

r D

istr

ibu

tio

n

an

d C

om

mu

nic

atio

ns N

etw

ork

APB1

APB2

APBn

APC

Maintenance

Interface

Cabinet

Power

Figure 6. AAPS I System Block Diagram


The AAPS is powered from 120 VAC used to power the traffic controller cabinet.

The 120 VAC is stepped down to 12 to 18 VAC to power the APC and all APB stations. The

communications is implemented using EoP technology over the 12 VAC conductors

distributed to all of the AAPS APBs.

The APC servicing interface is an independent Ethernet connection to a service

computer for installation and maintenance. The function of this interface will be discussed

later in this document.

The Advanced Pedestrian Controller

As shown in Figure 7, the APC consists of a commercial off-the-shelf Linux based

single board computer with a 70 MHz ARM 7 microprocessor and a traffic cabinet interface

board of proprietary design. All interfaces with the traffic controller cabinet use optical

isolation and transient protection components. The system is capable of interfacing with eight

pedestrian signal pairs to sense the 120 VAC WALK (W) and DON’T WALK (DW) load

switch outputs.

An 18 light emitting diode (LED) array is the only local display that indicates AAPS

operating status. All other human-machine interaction (HMI) is achieved via the second

Ethernet port connected to a service computer or laptop computer. The simple HMI on the

APC eliminates the cost and space otherwise needed to support wide temperature range

Liquid Crystal Displays (LCD) displays and key panels. The Ethernet interface will be

described later in this paper. A real-time clock with battery backup is provided to support an

optional time of day operation.

The APC-APB network interface uses a MX5500 EoP modem that supports the 85

Mbps Ethernet using the HomePlug® 1.0 standard [12]. Similar devices are commercially

available that operate on 120 to 220 VAC. Our proprietary design is needed for the AAPS

system to operate on the 12 VAC power used to power the pedestrian stations.


AVR32

Linux Based

Single Board

Computer

AC

Sensor

AC/DC

Switch

Service

Computer

EoP

Modem

Power

Supply12-24

VAC

120VAC

APC

Ethernet

Port #1

Ethernet

Port #2

Clock

LED

Panel

Traffic

Controller

Pedestrian

Button

Inputs

Pedestrian

Signal Load

Switch

Outputs

Figure 7: Block Diagram of Advanced Pedestrian Coordinator

The Advanced Pedestrian Button

The block diagram for the proprietary APB electronics is shown in Figure 8. The

APB uses a NXP LPC2468 processor based upon a 32-bit, 72 MHz ARM 7 processor

architecture. This particular processor was chosen because it supported a media independent

interface (MII) needed to communicate with the EoP modem and the 512 kB flash memory

that is used to store the data files for the audio messages.

Apart from the communications, only 5 of the 208 processor pins are needed for input

and output. Two inputs are used. One input is used for the audio microphone used for

ambient noise compensation. The second is used for the pedestrian button. The three outputs

are used for a call acknowledge LED, the vibrotactile control, and the audio output for the

speech messages. The LED on the pedestrian button that is activated when the button is

pressed is only illuminated when the APC acknowledges to the APB the call has been place

to the traffic controller. The MII interface for the EoP communications requires 18 processor

pins. Additional outputs to control LEDs are used for diagnostics and development.


On the surface, the processor chosen appears to be more than required for this

application. However, the functionality designed into the NXP processor reduced system cost

and physical size of the APB circuit board.

Audio

Speaker

Power

Amplifier

EoP

Modem

INT55MX

Pedestrian

Button

Microphone

Power

Supply

LM4755T

12-18

VAC

RF

Coupler

NX

P L

PC

24

78

Vibro-

tactile

Motor

Zero

Crossing Det

1.8

V

3.3

V

5.0

V

8V

Serial Port

EoP Modem

Call

Placed

LED

LED Array

Preamp

Figure 8: Block Diagram of Advanced Pedestrian Button

AAPS I Communications

Network communications is our approach to address safety concerns raised in the

introduction of this paper. The APC continually sends data messages containing the status of

the pedestrian signals to each individual APB in a round robin fashion. Each APB responds

back to the APC indicating the reception of the data. Any APB not responding in a preset

time is identified on the APC’s front panel LED. The time of the failure is also recorded in

the maintenance log that is viewable via the service webpage. The data in the APB response

message includes the current audio tone or message being played. This is checked against the


status of the signals to verify that there is not a conflict in pedestrian controls as indicated by

a DW signal status. The APB sends an unsolicited message to the APC whenever a

pedestrian has activated its button input. The APC immediately passes the request on to the

traffic controller by activating the appropriate pedestrian input terminal in the cabinet.

Network Communications

Ethernet Layers

A protocol stack is a collection of software functions for managing network

communications. Frequently the functionality of the protocol stack uses a graphical diagram

that represents the flow of data through computer processes to ensure secure and timely

communications. The diagram in Figure 9 is an example of a protocol stack. As the data

travels down the stack, computer processes add routing information to the basic message.

This routing information is removed from the network packet by the receiving

computer as the data travels back up through the protocol stack processes.

Information that is to be sent from one traffic control element to another organizes the

data into objects that indicate how the data is to be decoded as well as the specific

information communicated. The simple network management protocol (SNMP) layer will

pass this information to the user datagram protocol (UDP) layer of the stack. Figure 9 is a

partially modified diagram of the National Transportation Communications for ITS Protocol

(NTCIP) Standards Framework that the AAPS implements. The heavy solid lines represent

the data path for the operational portion of the AAPS. The lighter solid line represents the

data path used for transferring audio speech and tones files from the APC to individual

APBs. Figure 9 is modified in that the EoP is added at the physical layer along with the

twisted pair.


ITS Data

Model

ITS Data

Dictionary

ITS Mesasage

Set

Reference

Model

Files

TFTPFTPCOBRA DATEX

TCP UDP

Data Objects

Dynamic

Objects

STMPSNMP

IP

Ethernet

Twisted

PairEoP

Figure 9. Partial NTCIP Standards Framework

Communications – Service and Maintenance

The maintenance and setup of the system uses web based controls through a webpage

that is hosted by the APC single board computer. The computer used for maintenance and

servicing does not require proprietary software; only a standard web browser such as Internet

Explorer® or Mozilla Firefox

®.

The webpage organizes the data into three types: system operational status,

configuration settings and log files. The top frame of the webpage presents real-time system

status information concerning the pedestrian signals and pedestrian calls waiting to be

serviced. Status information includes the state of APC inputs and outputs as well as the state

of all APBs. This frame is always displayed so that the current operating status is always

viewable.


There are six display options for the contents of the bottom frame of the service page:

System Status, System Configuration, Time Configuration, Station Settings, File Upload, and

View Log Files. Configuration settings are organized into two types: system wide and APB

specific settings. The bottom frame is where data is entered to make changes to the system

functionality. These settings are used to select the operating modes for the APC and those

options that are common to all APB stations.

Audio File Management

Audio files are generated and stored on the service computer. The files are transferred

to the APC one at a time. After receiving each audio file, it is passed on to the specified APB

using the file transfer protocol (FTP). The audio file information is stored in a file system in

the APB processor’s nonvolatile memory space. Each file has a unique name that must match

an entry in a predefined table before the file will be saved one the target APB. These file

names correspond to the message that is being saved. The file names are wait, walk, location,

locator, initiation_beacon tone, and target_beacon tone. In addition, there are preempt and a

custom audio message.

The AAPS uses sound files in an 8bit, 8 kHz pulse-code modulation (PCM) format.

The sampling rate and data word size is chosen as a balance between sound quality and file

size. The human voice contains frequencies that are primarily less than 4 kHz. Therefore, the

8 kHz sampling rate is sufficient to capture human speech according to the Nyquist’s

Theorem [13]. Eight data bits is the smallest word width in the PCM format but supplies

enough dynamic resolution to faithfully reproduce recorded speech. PCM requires little

processing effort by the computer playing the sound files. The only processing required for

playback involves volume control. With 8 bit, 8 kHz PCM audio, it ultimately requires 8kB

of nonvolatile memory on the APB to store one second of recorded audio.

Audio files are transferred from the service computer to the APC using hypertext

markup language (HTML) multipart/form-data. The sound file and other fields of the form

are packaged and sent to the APC web host and processed by a common gateway interface


(CGI) script. There are five fields sent to the APC web host: stationid, fileid, resid, the sound

file, and the submit field.

The stationid field indicates which APB the audio file is to be directed. Fileid is the

number identifying which file is being sent. Resid is a text string used by the Advanced

Accessible Pedestrian Management System (AAPMS) webpage to notify the user of the

status of each file transfer. The submit field is the value of the value of the Submit button that

was pressed. In the multipart-form transfer, each field is separated by a field boundary. The

boundary is specific in the header information of the transfer file and varies depending upon

the browser being used and the content of the file.

When the APC receives the HTML form data transfer, the first step is separating each

field along its boundary and storing the contents of each in the appropriate place in memory.

The AAPMS webpage is then notified about the file transfer. If the audio file was not in the

correct format or the file or station identification numbers are not valid, the webpage notifies

the user. Next, the sound file is processed to prepare the sound files for transmission to the

APBs. The APC strips all of the file information from the file to reduce the memory

requirements. The resulting binary information contains only the PCM binary data. This file

is then sent to the APB specified by stationid as file fileid. At the beginning of the file

transfer, the APB is placed into a silent mode so that no audio files are accessed during a file

upload. Upon a successful transfer, the AAPMS webpage displays a conformation to the

user.

The configuration settings of the AAPS on the AAPMS webpage are submitted using

URL encoded data. When the user submits configuration data via the AAPMS webpage, a

CGI scripts parses the URL encoded data and processes it accordingly. First, the APC parses

the incoming data and saves it to non-volatile memory so that it will be retained during a

power loss or system restart. Then, the configuration data is applied to the different parts of

the AAPS. For APC specific configurations, the appropriate operating system services are

restarted, allowing them to re-read their specific configuration files.


APB configuration options are handled much differently than APC options. First, the

APB’s receiving new configurations are placed into a mode in which the APB operates at the

basic level, i.e.as a common button. This prevents misoperations while the new

configurations are being loaded. Next, the new configuration for that button is sent via

SNMP. Upon a successful reconfiguration of the APB, it is placed back into the mode it was

previously configured.

Communications – System Operations

Since the AAPS is a standalone system and operates on an isolated network, any

network protocol could have been used. In order to allow future integration with NEMA TS2

traffic controllers, we chose to implement the AAPS using NTCIP recommendations. We

recognized that many of the objects we needed are not included in the NTCIP 1202 guide and

hence we developed a specific set of objects which are described below [10]. A significant

portion of the communications protocol used to implement on the AAPS is based upon work

reported on by Devoe, et.al. .

SNMPv2

SNMP was developed in the 1980’s to provide standard extensible management of

local area network based products [14]. Even though SNMP has been updated to version 3,

our use is limited to operation of version 2 since it provides the communication protocol

necessary for the AAPS operations.

The AAPS supports a subset of the SNMP functions for the APC-APB network

system only. The SNMP messages enable the APC to validate this communication with each

APB and that each APB is capable of verifying that a call has been placed to the APC. For

normal operation the APC periodically generates a SetRequest message that updates each

system APB that, in turn, responds back to the APC a GetResponse message. This exchange

of information provides verification to the APC that each APB is operational and has

received the correct information.


When a user has pressed a pedestrian button, the station APB sends a Trap message

to the APC. A Trap is an unsolicited message generated by the APB that the APC does not

respond to. The reception of the Trap is verified on the next periodic SetRequest received. If

the next SetRequest message from the APC does not indicate that a call has been placed, the

APB will generate another Trap.

The program Wireshark [15] was instrumental as a development tool for designing

the application to build the SNMP packet. It displays individual packets in real-time as they

occur on the Ethernet physical layer. In its display it breaks the packets down in user

identifiable layers as well as the actual hexadecimal bytes in the packet.

SNMP OID’s

SNMP protocol data units (PDU) are used to manipulate object values. These values

are identified by Object Identifiers (OID). An OID uniquely identifies the value. NTCIP

1202 [16] describes the OID’s that involve traffic controllers. NTCIP 1202 does not provide

adequate objects to support the operation of the AAPS system hence we generated a custom

set of objects following the NTCIP style. The SNMP OID’s that are needed for operation of

the AAPS system are described in Table 1 through 3 below. The Intersection Node object is

the objects that are sent from the APC to each APB at periodic intervals.


Table 1: Intersection OID Definitions

Node OID Type Description

APB Device Node 1.3.1.4.1.1206.4.2.14 Root node for APBs, 14 on end may change

Intersection Status Node apb.2 Bits

Intersection Status Don't

Walks

apb.2.1 Bits Bits. If set to 1 that phase is in the don't walk

state

Intersection Status Ped

Clears

apb.2.2 Bits

Bits. If set to 1 that phase is in the Ped clear state

Intersection Status Walks apb.2.3 Bits Bits. If set to 1 that phase is in the Walk state

Intersection Status Calls apb.2.4 Bits Bits. If set to 1 that phase has a call pending

Intersection Status APS Calls apb.2.5 Bits Bits. If set to 1 that group has an APS call

pending

Intersection Status Beacon

Source

apb.2.6 Bits

The source of an APS call

Intersection Status Beacon

Destination

apb.2.7 Bits

The destination of an APS call

Intersection Status Block

Object

apb.2.8 OS Octet string containing all of the intersection and

station status objects

Station Status Node apb.3

Station Audio Message Apb.3.1 Int Audio message currently being played

Station State Apb.3.2 Int Button state number

SNMP TRAP

The SNMP trap PDU is required to contain two items: the system up time or time

since its last reboot and the device OID. Any additional information can be added beyond the

required items. The APB will add either an Intersection Status Calls or APS Calls value,

depending on the type of input detected from the user of the button, to the trap message. Each

APB will use its preconfigured Station Phase value in the value field of this Trap PDU.

Table 2 contains the list of objects that can be sent when a SNMP trap is sent from the APB

to the APC.

Table 2: Station Trap OID Definitions


Intersection Status Calls apb.2.4 Bits Bits. If set to 1 that phase has a call pending

Intersection Status APS Calls apb.2.5 Bits

Bits. If set to 1 that phase has an APS call

pending


APB Configuration Objects

The Configuration variables are also set using the SNMP protocol. Unlike the Status

objects, these variables are configured once, therefore these objects are saved to nonvolatile

memory. This allows for the system to recover from a power loss with no loss programming.

Table 3 describes the configuration information for each button. Each APB is initially

programmed with default values for each variable. The default values allow a new button to

be found when added to the network. This means that all buttons are programmed exactly

alike and then configured to be unique in the system, using the maintenance interface.

Table 3: Configuration OID Definitions


APB Device Node 1.3.1.4.1.1206.4.2.14 Root node for APBS, 14 on end may change

Station ID apb.1.1 int

Station ID number. Values 1-16 (0 for not

configured)

Station Night Mode apb.1.2 int 1 If night mode is on

Station Day Locator

Volume apb.1.3 int Values 0-100

Station Day Speech Volume apb.1.4 int Values 0-100

Station Night Locator


Station Night Speech


Station IP Address apb.1.7 OS 4 byte octet string of the stations IP address

Station Mode apb.1.8 int 0-4 AAPS operation mode

Station Identify apb.1.9 int 0 for identify off. 1 for LED blink/vib

Station Phase apb.1.10 bits Bit corresponds to Station's phase

Station Group apb.1.11 bits Bit corresponds to Station's group

Station Beacon Mode apb.1.12 int AAPS Beacon operational mode

Conclusions

The AAPS presented uses a hardware architecture that has the capability to meet the

expanding requirements of APS systems. A system that uniquely identifies each pedestrian

station can now be programmed so that pairs of pedestrian stations can operate in concert to

facilitate beaconing with no additional wiring. Time of day operation can be used to reduce

volume depending upon local requirements.


Using network communications enables observations of operations for a

microprocessor located outside the traffic controller cabinet. Audio files that are played at

each pedestrian station are compared to be consistent with the pedestrian signal status. Each

communications transaction is verified to detect equipment and wiring errors as well as

communication errors. The constant communications allows the system to detect pedestrian

station failures at the traffic controller cabinet even when there is no pedestrian button

activity.

A web interface eliminates the need for application specific PC software for system

maintenance and diagnostics. The system logs maintenance operations and system failures

which can be archived for systems documentation. The web interface allows one person to

view the entire system operations from one location.

WEB Access Security

Systems with operation and service that can be accessed and/or modified by an

internet connection always raise the concern of system security. The potential risk is that

audible messages can be altered such that they can provide incorrect and possible dangerous

information. This is particularly hazardous for blind pedestrians who do not have vision to

verify the validity of the audio information. There are two philosophies used for system

protection: provide security for each device or provide a secure network environment isolated

from easily accessible communications.

The AAPS consists of two isolated network systems that are wire based so that they

require physical connection. The operational network provided by the EoP network directly

manages the information between the APC and the numerous APS sites. This information is

produced and used exclusively by the APC and APB units. The only access to an EoP

network is from inside the traffic controller cabinet or by physically connecting an EoP

modem to the 18VAC wires that connect the APC to the APB units. Security of access to

those facilities are beyond the scope of the AAPS system and are the responsibility of the

traffic agency maintaining the system.


The highest vulnerability for unauthorized access to the AAPS system is through the

webpage interface. The APC can interface to the World Wide Web or outside network only if

the traffic agency provides such a connection. Otherwise, the primary defense against

unauthorized access is the security of the traffic cabinet itself. The webpage is password

protected. This level of access protection is highly dependent on the number and sequence of

characters used in the password. Traffic agencies are expected to have a network security

policy in place to guarantee that the proper level of password obfuscation is used.

AAPS I Hardware Documentation

AAPS I – APC Hardware

Figure 10. Installation of the AAPS I at 6th and Deakin Streets in Moscow, ID.


APC NGW100 Linux Processor

Figure 11. ATMEL NGW100 with AVR32 Processor and Linux Operating System

See: http://www.atmel.com/dyn/resources/prod_documents/doc32062.pdf and

http://www.avrfreaks.net/wiki/index.php/Documentation:NGW/NGW100_Hardware_reference

http://www.atmel.com/dyn/resources/prod_documents/doc32062.pdf

http://www.avrfreaks.net/wiki/index.php/Documentation:NGW/NGW100_Hardware_reference


AAPS I - APC Parts Layout

Figure 12. Picture of APC I PCB Side A


AAPS I - APB Parts Layout

Figure 13. Picture of APB I PCB Side A

Figure 14. Picture of APB PCB Side B


APPENDIX D - Review of Initial Test Field Installation

On February 16, 2010 at a temperature below 10 degrees, the first generation of the

Smart Signals Technology design for Accessible Pedestrian Signals (APS) was installed at a

public intersection in a suburb of St. Paul, Minnesota. Figure 15 and Figure 16 show the

environment as a team of researchers from the University of Idaho that have been involved in

the development of the new system were observed technicians with the Minnesota

Department of Transportation install the systems at two intersections. After the hardware

installation, the students demonstrated how each signal can be customized using a laptop

computer and a conventional web browser. To date, the Advanced Accessible Pedestrian

Signals (AAPS) is “chirping” away. (The “chirp” is the locator tone that helps low vision

pedestrians to locate the pedestrian button.)

Figure 15. Climate Conditions during the Initial Minnesota Field Installation


Figure 16. Minnesota Installation Activity

Smarts Signals is an enabling technology initially conceived by Professor Richard

Wall in 2004 as a means to improve the capability and safety of controlling traffic signals at

intersections using distributed microprocessor based controls that use safety critical network

design methodologies. The focus has been placed on improving access and safety for low

vision and mobility impaired pedestrians. A partnership was developed with Campbell

Company of Boise, Idaho who manufactures the AAPS systems.

AAPS is different from conventional pedestrian buttons in that information is

exchanged between the Advanced Pedestrian Controller (APC) in the traffic controller

cabinet and each individual Advanced Pedestrian Button (APB) at the rate of four times a

second. Power and communication is distributed by APBs by employing Ethernet over

Power Line (EoP) technology on an 18 VAC power system. The Minnesota installation

demonstrated that the AAPS can be easily retrofitted in existing intersection controls using

the preexisting pedestrian button conductors. The internet connectivity allows traffic agency

technicians to view the AAPS system operations remotely to determine the current status of

individual pedestrian buttons. The operational data that is logged by the APC can also be


viewed over the internet. This data includes hardware failures and the number of calls placed

by individual APBs.

Feedback from the Minnesota installation has been very positive and constructive.

Although the installed AAPS is fully functional, ideas for improvement were recorded and

have already integrated with the new design. Many ideas arise from the statement “Since we

have network communications, can we now do …” Without a tight rein on our imaginations

“feature creep” would never allow us to get out of the laboratory. One of the ideas recently

implemented is the ability to update the application program remotely, thus allowing

Campbell Company to update existing systems over the internet. The web interface reduces

hardware costs and physical size by eliminating displays and keypads.

The step of street deployment is important to the future of Smart Signals because it

demonstrates that such systems are extensible by being capable of easily providing advanced

features. The communications with the terminal devices (lights, detectors, pedestrian buttons,

etc.) facilitates early failure detection. Future research will focus on further simplifying the

system installation in order to make the system truly “plug and play”.


APPENDIX E - AAPS II Technical Description

To communicate unambiguously and accurately the state of the visual traffic signals

with minimum distraction, the AAPS II cabinet interface unit was designed. Current versions

of APS systems need to check the current state of pedestrian signals, so they are wired

directly to field terminals within a traffic cabinet that control the pedestrian signals; this

information is communicated to each pedestrian station. However, this method of signal

sensing is complicated to install, and because of the connection to live 120 VAC signals at

the field terminals, it requires special certification in some states within the US. Furthermore,

connecting to 120 VAC signals require that APS systems include transient voltage

protection.

The protection circuitry creates a load in parallel with the load of the signal light.

Additional loading on the load switch outputs of any type is to be avoided whenever possible

to prevent the Malfunction Management Unit (MMU) from sensing a voltage that otherwise

results from an inoperative signal.

AAPS II Advance Pedestrian Coordinator

The block diagram for the second generation APC is shown in Figure 17. It consists

of four functional elements: the system control computer, the Ethernet communications

shown in Figure 18 and Figure 19, interface, the traffic cabinet interface shown in Figure 21

and Figure 22, and a local status display shown in Figure 23. The function of the APC is to

manage the system operation parameters, report the status of the intersection WALK and

DON’T WALK signals, and place pedestrian calls to the traffic controller. Although the APC

communicates pedestrian signal status with each pedestrian button four times a second, a

pedestrian call initiated by a button press is initiated by the pedestrian button station

instantly. The single board computer used in this design is commercially available from

Technologic Systems. Although there are many suitable single board computers that use a

Linux operating system, the special requirements include two Ethernet ports and having

hardware that is compliant with operating at industrial temperatures. The front panel display

is unchanged from the first generation AAPS design.


Linux Single

Board

Computer

WWW System Configuration

Connection

AAPS

Communication

Cabinet

Interface

Cabinet SDLC Bus

Service Ethernet Port

Pedestrian ButtonNetwork

Front Panel

Indication

Cabinet PED Call

Figure 17. AAPS II APC Block Diagram

APC II Communications Module

3 Port

Smart

Router

RJ45

Magnetics

RJ45

Magnetics

HP II EoP

Modem

HP I EoP

Modem

MM

I

RF

Coupler

18VAC

Power

8VDC

3.3VDC

Zero

Crossing

Detector

APC

Power

COMM

Port 1

COMM

Port 2

Eth

ern

et

Figure 18. APC II Communications and Power Supply Module Block Diagram


Figure 19. AAPS II Communication Unit Printed Circuit Board

The block diagram of the circuit board that provides the interface between the APC

and the equipment in the traffic controller cabinet is shown in Figure 20. The Cabinet

Interface Unit is a proprietary circuit to interface with the NEMA TS2 SDLC bus. The

Cabinet Interface Unit has been tested using both simulated SDLC Type 129 messages as

well as actual SDLC Type 129 messages from a NEMA TS2 traffic controller cabinet. The

new SDLC interface uses a low cost complex programmable logic device to decode

messages and allow the data contained within the SDLC Type 129 message to be accessed

over a common I2C network.

AC

Detectors

MachX02

CPLDCabinet PED Call Inputs

Solid State

Relays

SDLC

Drivers

Cabinet SDLCBus

Pedestrian Signal Load

SwitchOutputs

Figure 20. AAPS II Cabinet Interface Module Block Diagram


Figure 21. AAPS II Cabinet Interface Unit Parts Layout – Side A Photo


Figure 22. AAPS II Cabinet Interface Unit Parts Layout – Side B Photo


Figure 23. Front Panel Display Used for AAPS I and AAPS II

AAPS II Advanced Pedestrian Button (APB)

The block diagram of the second generation APB is shown in Figure 25 and shows

the two sides of the PCB for the single board computer is shown in Figure 26 and Figure 26.

Volumetric size restriction dictated that components that extend more than 0.25” above the

surface of the circuit board be mounted on the same side of the circuit board. This size

restriction is imposed by the desirable physical size of the pedestrian button. As one

concludes from Figure 25, we are close to if not actually at the maximum number of

electronic components. As it is, there are components sandwiched under the EoP module that

has the “bel” label as seen in Figure 25 (The “bel” label identifies the manufacturer of the

EoP module, Bel Fuse Corporation of Jersey City, New Jersey). The four-layer circuit board

uses the surface layers as heat sinks dissipate heat produced by electronic components. Using


the circuit board conductors to dissipate component generated heat saves circuit board real

estate and part cost.

Software has been developed to verify that all hardware components are functional.

Software drivers have been developed that allow the various hardware components to be

included in the operations of the button.

LPC1768Processor

UDA1345TSAudio Codec

L3Bus

I2S

Microphone

Speaker 1

Speaker 2

SD Card Mass Memory

SPI

10/100 Ethernet Switch

(KSZ8863RLL)

RM

II

I2C

Ethernet PortTest and Future

Devices

Port 1

Ethernet PHY(KSZ8001SL)

Po

rt 2

MII

Power Supply

RFCoupler

EoPHP AV

Temperature Sensor

(MCP9700T)

3.3V Power

Button LED

Vibrating Motor

Button Input

SPI BUSSP

I

I2C

I2C BUS

Mass MemoryEEPROM

SPI

Future External Devices

Future External Devices

JTAG Debug

Asynchronous Serial Communications Amplifier

12VACSystemPower

AC Zero Crossing

Signal

Remote Control

Figure 24. AAPS II Accessible Pedestrian Button Block Diagram


Figure 25. AAPS II ABP Printed Circuit Board - Side A Photo

Figure 26. AAPS II ABP Printed Circuit Board - Side B Photo


REFERENCES

[1] Traffic Signal Timing Manual, US Department of Transportation Federal Highway

Administration, Publication Number: FHWA-HOP-08-024, June 2008,

http://ops.fhwa.dot.gov/publications/fhwahop08024/fhwa_hop_08_024.pdf.

[2] Injury Prevention & Control: Motor Vehicle Safety,

http://www.cdc.gov/motorvehiclesafety/pedestrian_safety/factsheet.html.

[3] NCHRP Project 3-62 “Accessible Pedestrian Signals – A Guide to Best Practices”

http://www.apsguide.org/appendix_c_research.cfm.

[4] “AMERICANS WITH DISABILITIES ACT OF 1990, AS AMENDED 2009”,

http://www.ada.gov/pubs/adastatute08.htm.

[5] Chapter 4B, Section 4B.01, Manual on Uniform Traffic Control Devices, U.S.

Department of Transportation Federal Highway Administration, 2003 Ed. With Rev. 1 and 2,

December, 2007 http://mutcd.fhwa.dot.gov/ , last viewed on Feb. 8, 2010.

[6] Boehm B, "A Spiral Model of Software Development and Enhancement", ACM

SIGSOFT Software Engineering Notes, ACM, 11(4):14-24, August 1986.

[7] “Waterfall Model”, http://en.wikipedia.org/wiki/Waterfall_model.

[8] “University of Idaho Mission and Role”, 2011-2015 Strategic Plan,

http://www.uidaho.edu/president/leadingidaho/mission.

[9] Wall, R.W., A. Huska, and D. Bullock, “Application of Plug and Play Distributed Signal

Technology to Traffic Signals,” Transportation Research Board 2006 Annual Meeting,

Washington D.C., January 22-26, 2006, Paper No. 06-2728.

[10] Wall, R.W., T. Urbanik, D. Bullock, S. Allen, M. Busby, D. DeVoe, A. Huska, T.

Rallens, “Distributed Traffic Signal Control: Improving Pedestrian Control as A First Step”,

Transportation Research Board 2007 Annual Meeting, Washington D.C. January 21-25,

2007, Paper No. 07-0989.

[11] DeRuwe, G. and R. W. Wall, “Pedestrian Navigation and Integration with Distributed

Smart Signal Traffic Controls”, The 34th Annual Conference of the IEEE Industrial

Electronics Society, Orlando, FL, November 11, 2008, Paper # HD-010979.

[12] HomePlug 1.0 Technology White Paper,

http://www.homeplug.org/tech/whitepapers/HP_1.0_TechnicalWhitePaper_FINAL.pdf.

[13] “Nyquist-Shannon Sampling Theorem”,

http://en.wikipedia.org/wiki/Nyquist%E2%80%93Shannon_sampling_theorem.

http://ops.fhwa.dot.gov/publications/fhwahop08024/fhwa_hop_08_024.pdf

http://www.cdc.gov/injury/

http://www.cdc.gov/motorvehiclesafety/

http://www.cdc.gov/motorvehiclesafety/pedestrian_safety/factsheet.html

http://www.apsguide.org/appendix_c_research.cfm

http://www.ada.gov/pubs/adastatute08.htm

http://mutcd.fhwa.dot.gov/

http://doi.acm.org/10.1145/12944.12948

http://en.wikipedia.org/wiki/Waterfall_model

http://www.uidaho.edu/president/leadingidaho/mission

http://www.homeplug.org/tech/whitepapers/HP_1.0_TechnicalWhitePaper_FINAL.pdf

http://en.wikipedia.org/wiki/Nyquist%E2%80%93Shannon_sampling_theorem


[14] “Simple Network Management Protocol”,

http://en.wikipedia.org/wiki/Simple_Network_Management_Protocol.

[15] “Wireshark”, http://en.wikipedia.org/wiki/Wireshark.

[16] “A Joint Standard of AASHTO, ITE, and NEMA NTCIP 1202 v01.07”, January 2005,

https://www.ntcip.org/library/documents/pdf/1202v0107d.pdf.

http://en.wikipedia.org/wiki/Simple_Network_Management_Protocol

http://en.wikipedia.org/wiki/Wireshark

https://www.ntcip.org/library/documents/pdf/1202v0107d.pdf

KLK266 Final Report - University of Idaho€¦ · 13. Type of Report and Period Covered Final Report: September 2008 – June 2014 14. Sponsoring Agency Campbell Company 15. Supplementary

Documents