A Design Approach for the Development and Deployment of an Accessible Pedestrian System

A Design Approach for the Development and Deployment of an Accessible Pedestrian System

Cody Browne

Electrical Engineering Graduate Student

Department of Electrical and Computer Engineering

University of Idaho

PO 441023

Moscow, ID 83843-1023

Zane Sapp

Electrical Engineer

Campbell Company

450 W. McGregor Dr.

Boise, ID 83705

Word count:5187

Number of figures:4 (1000 words)

Number of tables:0 (0 words)

Total word count:6187

Submitted for presentation at the 92nd Annual Meeting of the Transportation Research Board, January 13th-17th, 2013 and for publication in Transportation Research Record, the Journal of the Transportation Research Board.

Abstract: This paper describes the design approach to developing an accessible pedestrian system that is flexible and easily customized to meet specific user requirements for a wide range of signalized intersection configurations. Traffic control schemes and street designs become more complex to meet modern transportation demands. Signalized traffic intersections impose challenges for both vehicle operators and pedestrians who must share the common right-of-way. The challenges for pedestrians are further acerbated for those who have vision and physical limitations. Customization of accessible pedestrian systems is accomplished in two different periods during the design deployment. A scalability aspect must be considered when designing the base system capability to allow new sensor devices to be incorporated quickly and economically through hardware and software. During deployment, a robust design accommodates a wide range of settings that allow systems to be finely tuned to maximize accessibility and safety.

A computer based system allows most of the design activity to be concentrated in software which is far more scalable than hardware. Many of the accessible pedestrian systems have features that are selectively enabled and/or have a variable component that must be set. Internet capable computer-based automation accommodates pedestrian systems capable of self-diagnostics and remote failure reporting. The use of a web interface hosted by the accessible pedestrian system reduces the amount of application specific software that must be developed and maintained. Human factors engineering dictates how best to present the information on the system configuration web page to make installations unambiguous and logical.

INTRODUCTION

Regardless of physical capability, pedestrians are finding it more challenging to cross safely at signalized intersections. Traffic timing schemes are now tailored to accommodate the needs for efficient vehicle movements. Unconventional intersection geometries and roundabouts are becoming more common. Pedestrians with low vision now face a daunting task of learning and remembering the peculiarities of numerous intersections.

The 2009 MUTCD Section 1A.13 defines an accessible pedestrian signal as being a device that communicates information about pedestrian signal timing in a non-visual format such as audible tones, speech messages, and/or vibrating surfaces [1]. An accessible pedestrian signal (APS) detector is defined as a device designated to assist the pedestrian with vision limitations or physical disabilities in activating the pedestrian phase. The modern pedestrian station is where an individual generates an action or places his or her self in a position to be detected. The pedestrian station is also responsible for relaying the calls to the traffic controller as well as providing information concerning the state of the pedestrian signals.

The timing of the audible messages provided at each pedestrian station at the intersection must be coordinated with the traffic signal lights. There are two conventional practices for controlling pedestrian movements. The Barnes dancepedestrian control scheme provides for an exclusive pedestrian phase when all vehicles are stopped and pedestrians are permitted to cross from any corner to any other corner of the intersection[2]. The more common scheme is to coordinate pedestrian movements with parallel traffic movements. Some coordinated control schemes use a leading pedestrian phase, which displays the walk signal a few seconds before right or left vehicle turns are permitted. Other coordinated schemes will not display walk signals during protected left turn phases. It is common practice to platoon pedestrians by displaying the walk sign for only a portion of the parallel traffic movement. The practices used for pedestrian control vary widely from one intersection to the next.The need for an APS at intersections using fixed time controls are sometimes overlooked because a walk phase is always included in the traffic control scheme. However, pedestrians who have vision limitation still must rely on the audible and vibrotactile indications to assist them in safely crossing at signalized intersections.[3]

The research on accessible pedestrian systems (APS) started in 2005. Over the past seven years, we have learned to appreciate the need for rapid prototype deployment and a diverse range of controls to accommodate customer requirements for customization. This paper describes a design approach for a software-based distributed control APS that has been field tested and is now being commercially manufactured and distributed in the United States.

BACKGROUND

Initially, pedestrian buttons consisted of a normally open electrical push contact. Pedestrians placed the call by pressing the button, causing a circuit to be completed allowing electrical current to flow. This current flow was detected by the traffic controller indicating that a pedestrian desired to cross at the intersection. The Americans with Disabilities Act (ADA) of 1990 established access requirements for pedestrians whose mobility is otherwise constrained. The disability that has the most significant impact on pedestrians is low visual acuity.

The 1990 ADA made it imperative that information concerning the state of the traffic signals be communicated by multiple human sensory modes. The alternative modes are mechanical in nature (auditory and vibra-tactile). The result is that the complexity of pedestrians call systems radically increased. The practice of using chirps and cuckoo audible tones to indicate that the walk signals is active has recently fallen out of favor [4]. The limited information provided by the two tones was easy to misinterpret due to non-uniform intersection geometries. The audio signals are also subject to distortion from surrounding mechanical barriers such as buildings, landscaping, vehicles at the intersection, and even wildlife. More recent APS systems provide verbal messages that are more descriptive and less ambiguous to indicate the state of the signal controls as well as the corresponding direction.

Bidirectional communications between the traffic controller and the pedestrian call button is now needed to make the state of the pedestrian walk and wait signal available to be sensed by human touch or hearing. The degree to which this complexity has extended will be made apparent in subsequent sections of this paper. It is curious to note that the development of the pedestrian controls took on a life of its own after the 1990 ADA that resulted in control equipment separated and distinct from the traffic controller electronics in many traffic signal control cabinets currently in use.

The Smart Signals concept was first investigated in 2004 with the object of generating computer based architecture of an enabling technology to support advanced capability for traffic signals based on distributed control concepts [5]. Starting in 2005, based upon the recommendations of traffic professionals, we turned our research focus on accessible pedestrian controls [6].

AN ADVANCED ACCESSIBLE PEDESTRIAN SYSTEM

From a human perspective, the pedestrian’s input to request service at a signalized intersection is easily understood: press the button and wait for notification. The notification is provided by feedback by both the traffic controller and the pedestrian systems. The two independent control systems must be coordinated through sensors and controls to provide consistent information to the pedestrian. The traffic controller is responsible for controlling the visual signals for both vehicles and pedestrians. The pedestrian control system provides feedback to the pedestrian based upon the traffic controller signal status. The pedestrian control system also provides feedback based upon the type of pedestrian notification [7]. The feedback from the pedestrian controller is critical for individuals who cannot obtain the needed information from the visual pedestrian signals.

Figure 1 provides a concept diagram for implementing the advanced accessible pedestrian control system (AAPS). The AAPS has three major components: the advanced pedestrian controller (APC) that provides an interface in the traffic controller cabinet, the advance pedestrian button (ABP) at each crosswalk, and the network communications that links the APBs with the APC. The diagram illustrates how the human is in the control loop by generating a signal used for system inputs and reacting to the system outputs. There are multiple control loops in operation depending upon the pedestrian’s ability to receive and process the feedback from the pedestrian and traffic control electronics.

Figure 1. Data flow diagram for the Advanced Accessible Control System

The communications between the APC and multiple APBs needed for the real-time control uses Broadband over Power Line (BPL) technology to minimize the number of electrical conductors needed by the system. Up to gigabits of data per second can be communicated over power conductors [8, 9]. The BPL technology supports star configuration where all electrical runs originate at the traffic controller cabinet. This technology also supports daisy-chain configurations that connect the pedestrian stations like a string of Christmas lights. In reality, most installations use a combination of both star and daisy-chain configurations. The AAPS has additional internet communications not illustrated in Figure 1 to facilitate installation and maintenance through a connection between the APC and a service computer using a local or remote network connection. The service computer is used to change the operational settings of the APC and each individual APB. The service PC has no direct access to the network connecting the APC with the system APBs. All changes to APB settings are relayed from the APC after being qualified as being valid.

It is obvious from Figure 1 that the AAPS signals have evolved from the simple push-button into a highly complex spatially distributed real-time control system. The specialized audible, visual and tactile feedback must be coordinated with traffic signals and communicated to humans in a manner that is unambiguous and quickly understood. The Human Factors Model stresses that all parts of the system (human, task, technology, environment, organization) should work together and if any connection fails, the entire system fails. This means that even though the AAPS may send and receive signals flawlessly, if the human is confused on how to operate the system, it is a failure. Developing systems that are similar yet appropriate for a given intersection is crucial in reducing the user’s cognitive load while keeping pedestrians safe.

Although applying computer intelligence and internet connectivity to the pedestrian control systems adds complexity and cost, there is a reliability benefit. When the simple contact pedestrian button was used, the failure mode is only detectible by human operation and notification relied on driver or pedestrian complaint. Constant communications between the APC and every APB multiple times per second make failure detection immediate and the network connection provides a means for remote notification.

As intersections become larger and more complex to accommodate increased traffic volumes, irregular intersection geometries, and coordinated traffic plans, the system to operate and control the intersection is also becoming more complex. An improved system, where the controls can be adapted to the environment, is ideal to ensure a good fit between all parts in the human factors model. This system should build upon the basic controls that all humans in the system (pedestrians, traffic controllers, etc.) are accustomed but allow for adjustments when the intersection demands them. A system of this type would keep the cognitive load of all users low while providing them with enough additional information to ensure the intersection is safe. The subsequent sections of this paper described the design methodologies needed to achieve the design objectives for this complex control.

ENGINEERING DESIGN CONSIDERATIONS AND CONSTRATINTS

As our research on AAPS continues to evolve, we are finding that traffic agencies are requiring a higher degree of capability to tune the pedestrian systems for each individual intersection to better serve safety and accessibility. Even as traffic timing plans change based upon the time of day, so is the need to change the audible messages and or volume levels. There must be a means to quickly and economically integrate new orientation and travel assistance concepts. The AAPS hardware and software architecture is specifically designed to be adaptable and easily reconfigured to accommodate a wide range of traffic situations and pedestrian needs.

The choices for the implementation of resources to support AAPS functionality specifically relate to carrying out the processes defined by the spiral design methodology. Every new capability or feature was developed in an independently testable environment allowing complete validation and performance evaluation prior to integration into the overall system.Function modularity that allows new capability to be added economically and quickly is essential to address present and future requirements for APS systems.

The Development Model and Tools

During the development phase of the AAPS project, the need to address changes in functional and operating requirements came from three sources: new APS requirements as specified by the MUTCD 2009 edition, requests from traffic agency engineers and technicians, and our own innovations. We used the spiral design model to guide the development process for the AAPS. The spiral design model is particularly applicable to new developments that require a significant prototyping effort and risk assessment. This software spiral design model introduced by Boehm in 1986 design originally targeted software based projects that required completion is less than two years [10]. System features and capabilities are added to the final product in successive layers that involve a system review that initiates the requirements definition phase, a prototyping phase, the verification and validation phase, and the release phase.

Some of the design tools and design methods used during the development cycle to keep the AAPS flexible are: use of component based design, distributed control that utilizes network based communication, and flexible hardware reconfiguration through software. These same tools reduce the effort and time required to complete the arduous task of verifying that the changes have no negative effects on overall system performance. The ability to simulate a system outside its installed environment is beneficial during synthesis, modification, and verifications design phases.

Component-Based Software Design

The concept of component-based design (CBD) is not new. It is one of the ideas behind integrated circuits (building blocks for hardware systems). CBD is also heavily used in software and conforms to the spiral design methodologies. A component is defined as an independently deliverable set of reusable services [11].The first part of this definition states that a component is capable of being developed without developing other components. The second part says that the component is reusable. The service provided by a component fulfills a role in the overall system. A component may include the functionality of a processorsystem thus somewhat blurring the distinction between hardware and software [12].A component has an interface, which is a specification of how another component accesses the service provided by the component. One or more components are brought together or integrated to form a system.

Components allow software to be written in smaller, independent pieces than if the components were all written as a single piece of software. This is a benefit in that, even in a system with many components, it can lower the development effort over the same code written as a single program [13].The time savings of CBD is illustrated with the following example be shown by applying the software cost estimation model (COCOMO) expressed in intermediate COCOMO formula expressed equation (1) that was originally proposed by Boehm in 1981 [14]. Effort is measured in person-months, variables “ab” and “bb” relate to the type of application, KLOC is thousand lines of source code, and EAF is the effort adjustment factor based upon worker capability and experience.