Adaptive Traffic Control Systems: Domestic and Foreign State of Practice (2010)

Below is the uncorrected machine-read text of this chapter, intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text of each book. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.

28 INTRODUCTION There are many system requirements that define the quality of an ATCS, its deployment, and success. Even the best adaptive traffic control algorithms will not function properly if their operations are not supported by adequate hardware, software, communications, and system integration. This chapter identi- fies those system or operational requirements that are consid- ered critical for ATCS operations. ATCS users were asked to describe their experiences with ATCS requirements. Their descriptions were captured through a set of questions regard- ing detection requirements, hardware, software, integration with legacy systems, and communications. In addition to dis- cussing the agencies’ practices, this chapter reviews some of the implementation problems and some lessons learned in practice. DETECTION Any traffic-responsive control system depends on its ability to detect traffic either for local intersection control or for network-wide adjustment of timing plans. ATCSs rely heavily on the quantity and quality of traffic data available from detec- tors. Poor or improperly installed detectors can affect ATCS performance, which can eventually lead to the removal of ATCS operations. Historically, ATCS predominantly used inductive loops as a detection technology. Over the past several decades video detection has emerged as a cost-efficient and reliable replace- ment for the inductive loops. This trend was also observed in the analysis of the survey conducted for this project. Some of the ATCS agencies almost exclusively use video detection and are quite satisfied with its performance. On the other hand, some ATCS users overseas expressed reservations about the quality and reliability of video detection and exclusively use inductive loops. However, the survey showed that most of the agencies use a mixture of various detection technologies for their ATCS deployments. Although approximately 93% of the agencies use inductive loops, almost half (43%) also use video detection. Approximately 18% of the agencies use radar detection, whereas only 9% use other types of detection not contained in any of these three major technologies. Detection coverage is very important for the success of an ATCS. One of the most significant barriers for widespread deployment of ATCSs is a notion that such a system requires much more detectorization than conventional traffic-actuated signal systems. Responding agencies reported that their ATCSs utilize anywhere from 4 to 24 detectors (8 to 12 detectors on aver- age) to cover a single four-leg intersection with one through lane and two turning bays (left and right) for each leg. Although these results might be viewed with some caution, because var- ious agencies deploy detectors differently for their traffic- actuated operations, the findings do not fully support the notion that ATCSs require much more detection coverage than operations of traffic-actuated signal systems. Various ATCSs use a combination of detection layouts to estimate the current state of traffic, which is later used to adjust traffic control in a network. There are generally four major detector locations used by most ATCSs: • Stop-line detectors (e.g., as seen in common actuated operations in the United States and SCATS). • Upstream detectors located close to the stop-line (10– 15 m), which cannot be used (owing to their proximity to the stop-line) to easily estimate queue length (e.g., as used in Germany by BALANCE and MOTION). • Upstream (mid-block) detectors, which can be used to estimate reasonably long queue lengths (e.g., as seen at some Californian intersections and used by ACS Lite). • Upstream (far-side) detectors located at the exit point of the upstream intersection (as used by SCOOT, UTOPIA, and optionally by RHODES). Detection layout used by an ATCS correlates with the adaptive control logic that is used to adjust signal timings for the prevailing traffic conditions. Sometimes detection layout is established to provide good measures for the adaptive con- trol logic [e.g., in SCOOT—upstream detectors selected to accommodate for Traffic Network Study Tool (TRANSYT) logic]. Other times, adaptive traffic control logic is developed for the existing detection layouts (e.g., SCATS logic for stop- line detectors). When asked which of the four detection types they use, the responding agencies were not able to make a clear distinction between mid-block and upstream detectors on one side and stop-line and near stop-line detection on the other side. Therefore, aggregated results were provided for these two major detection placement categories. Approximately 42% of CHAPTER FIVE SYSTEM REQUIREMENTS

29 interviewed agencies reported that their systems use upstream detection. Distance between these detectors and the down- stream intersection varies anywhere from 10 to almost 300 m (40 to 800 ft). On the other hand, approximately 50% of the respondent’s ATCSs use stop-line detection exclusively. The rest of the respondents (approximately 8%) use various combinations of the upstream and stop-line detection in their ATCS operations. Left-turn detection is handled by 50% of the interviewed agencies at stop-lines. The other 50% of the respondents use upstream detection for left-turn movements, but a wide variety of solutions is applied. Some agencies use common (for the United States) queue detectors located two to three car lengths behind the stop bars, whereas others use combinations of upstream detectors and filter detectors based on the local con- ditions at each left-turn movement. Placement of the upstream left-turn detectors varies from approximately 20 m (50 ft) to the full length of the left-turn bay. Filter detectors are usually not placed in the storage bay of the left-turn movement but in the through exiting lane of the intersection leg that receives left-turn traffic. Depending on the sensitivity of ATCS operations on detec- tion inputs, the system may have more or less significant prob- lems when certain detectors fail. ATCSs that are less sensitive to short-term inputs from detectors tend to be more robust and work better when minor detection failures occur. However, these ATCSs may sometimes be insensitive to the changes in traffic flows. Most of the ATCSs provide some features that allow for replacement of the missing detection data using historic traffic records. Therefore, if a certain detector fails, the system finds and uses data from the respective day and time of day, which will approximate current operations. Such ATCS use of historic traffic data may reduce the impact of the detector malfunction on overall performance of the ATCS. Minor detector failures are relatively frequent events in everyday ATCS operations. Although these minor failures may have a significant impact on ATCS performance (e.g., detectors for a major signal group fail at the critical inter- section), their impact is usually limited. Low impact of minor detection failures on overall operations may not trigger a quick response from the agency and detection repair time might be prolonged. For this reason, it is important to find out how major ATCS users perceive the quality of ATCS opera- tions during the minor (by its scope) detection problems. The results from the survey are shown in Figure 7. Fewer than 20% of interviewed ATCS users reported that their systems perform poorly (or very poorly) during the minor detection problems. Very well; 7; 16% Acceptably; 21; 50% Neutrally; 7; 16% Poorly; 7; 16% Very poorly; 1; 2% FIGURE 7 ATCS operations with minor detection malfunction.

Major detection failures degrade ATCS operational per- formance. Under such conditions, an ATCS may continue to work as if nothing happened, and in the best case sce- nario it will work based on the historic data or as an actuated- coordinated traffic signal system. If the background actuated- traffic operations are designed properly the system may continue to work for hours or days before any operational change is noticed. For this reason it is important that ATCSs have the ability to alert operators about major detection fail- ures. Although most ATCSs have such ability, 16% of ATCS users reported that their system continues to operate as if nothing happened, without notifying the operators about detector malfunction. Approximately 53% of the ATCS users reported that detector malfunction triggers an alarm and noti- fies the operators. When it comes to “safe mode” operations during the major detection failure, 26% of ATCS users indi- cated that their systems switch to off-line TOD operations, whereas approximately 25% answered that their ATCS start using historic traffic profiles. HARDWARE ATCSs are usually installed when agencies are ready to radi- cally change traffic signal operations on arterial networks. Usually such changes include the replacement of existing local intersection hardware (i.e., controllers or controllers and cabinets) that may be reaching the upper end of its anticipated life span. However, installation of the hardware necessary to operate an ATCS usually involves installation of components not familiar to the local agency’s staff. Therefore, the prob- lems that may arise with new hardware have two compo- nents: (1) technical (quality of the hardware components) and (2) institutional (training necessary to master operations of new hardware). If the central hardware and local controllers do not meet ATCS requirements, system performance will suffer. In the past, some of the ATCS deployments in the United States were shut down because of the problems with local traffic controller or central system hardware. Incompatibility of imported local controllers (previously required for operations of some inter- national ATCSs), problems with communication between the controller’s unit and coprocessor card, and uncommon central hardware are only some of the examples of such hardware problems. Table 9 shows which traffic controller types are most commonly used by U.S. agencies. International agen- cies that deploy ATCSs mostly use controllers that run their local controller standards (i.e., Novax controllers in Canada, SCATS controllers in Australia, etc.). 30 Approximately 80% of interviewed agencies reported that they are familiar with the hardware that their ATCSs use. The 20% who reported that they were not completely familiar with the hardware emphasized the following problems: • Special protocol modifications were made to support existing hardware [i.e., Virtual Machine Environment (VME) processor cards, second central processing unit in 2070 controller], • New hardware components (digis, modems, interfaces) were not used before by the agency (“black box” syn- drome), and • Training was necessary for field technicians to learn how to use new controllers and other hardware. SOFTWARE Another key component in operations of an ATCS is the friendliness (interoperability and usability) of the ATCS soft- ware. In a category of questions that addresses this topic, ATCS users were asked to provide information about the operating systems and platforms of their systems, as well as the integration of their systems with Advanced Traffic Man- agement Systems (ATMS). Windows-based operating systems are used at approxi- mately 57% of the interviewed agencies. Ten percent of ATCS users run their systems on Unix-based operating systems. Open VMS, an operating system mostly used as a SCOOT platform, was reported by 14% of the interviewed agen- cies. It is interesting to note that only 14% of ATCS users reported using an Open VMS operating system. Considering that almost 35% of the interviewed agencies use SCOOT sys- tems, which almost unanimously still run on Open VMS (there are only few installations in the world where SCOOT runs on a Windows-based platform), the results indicate that some of the ATCS users are not sufficiently familiar with their ATCS. When asked how user-friendly they consider their ATCS software, only 18% of the interviewed agencies responded that their system’s software is very friendly. Results from this part of the survey are presented in Figure 8 and they show that ATCS software generally keeps up with users’ expectations. However, almost one-half of the ATCS users are not very satisfied with the way their ATCS software works. Software development is a time-consuming and costly process. Unlike common Windows-based applications (e.g., MS Office) ATCS software is developed for (and sold to) a couple of hundred users (at most) around the world. Also, each ATCS deployment is somewhat unique (various hardware and soft- Traffic Controller Type Percent of Agencies NEMA TS-1 30 NEMA TS-2 35 2070 ATC 34 Model 170 1 TABLE 9 TYPES OF TRAFFIC CONTROLLERS USED BY ATCS

31 ware elements need to be integrated), which sometimes requires software customization that is beyond the financial support allocated for ATCS deployment. Under such cir- cumstances it is understandable that ATCS software does not always keep pace with modern software developments and therefore may appear somewhat archaic to ATCS users. With an increase in the size of the base of ATCS users it is expected that the gap between ATCS software and general software trends will decrease. Although ATCSs can independently control traffic signals they are often integrated with an ATMS, which is used to manage the traffic signal system, providing such functions as Graphical User Interface, archived database management, and a graphic display system showing signal status, operating effectiveness, and communications. The ATMS provides inte- grated control of a variety of surface street traffic management functions, including traffic signals, dynamic message signs, closed-circuit television (CCTV) cameras, and vehicle detec- tion. If an agency runs an ATMS and wants to deploy ATCS (or vice versa) it is often important that these two tools are inte- grated or interoperable in order to deliver improvements asso- ciated with both systems. However, such integration can be very difficult to execute, owing to a number of reasons such as costs, intellectual rights, etc., and is rarely performed. How- ever, some of the ATMSs are preprogrammed to offer integra- tion with certain ATCSs, in which case an ATCS runs as a sin- gle option among various traffic control platforms within the ATMS [e.g., ACTRA—SCOOT, Management Information System for Transportation (MIST)—OPAC]. Results from the survey showed that 21% of ATCS users do not have an ATMS. Seventeen percent of those users who do have an ATMS do not have their ATCS and ATMS inter- faced. Those ATMSs that are the most frequently used are ACTRA, MIST, and i2TMS with 10%, 10%, and 7% of ATCS users, respectively. Approximately 48% of interviewed ATCS users utilize other ATMS (T2000C, Aries, Sitraffic, Alcatel ATM, TMIS, etc.). One of the major ATCS software functions is to report malfunctions and other diagnostics of its hardware and soft- ware components. ATCS Graphical User Interfaces usually provide a full range of operator commands and monitoring functions. Some of the typically displayed data for monitor- ing operations at an intersection are: • Lamps on/off/flashing • Current phase demands • Detectors occupied • Current cycle time • Operating mode • Alarms • Current phase • Elapsed phase time. Most of the interviewed ATCS users (95%) reported that their ATCSs are capable of reporting necessary diag- nostics. Figure 9 shows how system alarms are logged, viewed, and managed in SCATS’ Alarm Manager. Equally important parameters that need monitoring are operational Very friendly; 8; 18% Friendly; 15; 34% Neutral; 15; 34% Unfriendly; 6; 14% FIGURE 8 Friendliness of ATCS’ software.

traffic parameters, which help ATCS operators to monitor the quality of the executed signal timing plans and dynami- cal changes in traffic conditions. All of the ATCSs provide tools and functionalities to monitor and track variations of operational traffic parameters. Figure 10 shows a Dynamic Map functionality supported by the LA DOT’s ATCS, where a set of traffic performance measures (such as volume, speed, queue, stops, and delay) are reported dynamically in real time. These and similar traffic performance measures from other ATCSs can be archived in system databases for future use. ATCS users find this functionality, of archiving traffic metrics, very useful. Only 17% of the interviewed ATCS users do not believe that reported traffic performance measures are useful for other traffic engineering purposes. ADAPTIVE TRAFFIC CONTROL SYSTEMS AND MICROSIMULATION TOOLS A major disadvantage of field ATCS evaluations, reported through survey response and in the literature, is that these eval- uations always require an ATCS to be installed and, as such, they represent post-deployment justification studies. Also, as a result of costly field data collections, these evaluations are not practical for the investigation of the long-term benefits of ATCS deployments. To address these issues traffic signal researchers and practitioners have interfaced traffic micro- simulation tools to ATCS software. Studies where micro- simulation, coupled with an ATCS, is used to evaluate the 32 effectiveness of an ATCS before its field installation are very rare. The lack of pre-installation evaluations of ATCSs through microsimulation can be attributed to three major factors: • A lack of confidence in microsimulation results, which is still present among many traffic engineers and decision makers. • The complexity and costs of modeling field conditions in microsimulation and interfacing the microsimulation model to an ATCS software. • The costs and institutional issues (licensing) associated with acquiring ATCS software to be tested and/or eval- uated in microsimulation. In spite of these limiting factors almost all ATCSs have been interfaced with certain microsimulation tools. Discussion of these interfaces and relevant research studies is beyond the scope of this report. A reader is advised to review the bibliography section in Appendix C for further information on the most important studies regarding ATCS modeling in microsimulation. Table 10 shows microsimulation tools that have been coupled with the ATCSs described in this report. COMMUNICATIONS The importance and costs of communications that are neces- sary to provide reliable ATCS operations primarily depend on the way in which signals are interconnected in ATCS network FIGURE 9 Alarm manager in SCATS.

33 system. Consequently, inexpensive communications alter- natives, including wireless alternatives, are viable options. The savings in communications infrastructure usually compensates for the potential higher cost of local controllers. Distributed systems typically cost between $10,000 and $30,000 per inter- section (Malek et al. 1997). Only 9% of interviewed ATCS users find peer-to-peer communications to be the most important type of communi- cations for their systems. Another 9% put peer-to-peer com- munications as second in order of importance. Finally, 44% of ATCS users do not believe that peer-to-peer communications are important for their systems. In centralized systems, a central computer makes control decisions and directs the actions of individual controllers. These systems depend on reliable communications networks. Because real-time control commands are transmitted from the central computer to the local intersection, any interruption in the communications network forces the local controller to operate without that real-time control and revert to its backup plan, which usually is time-based coordination; however, this FIGURE 10 Dynamic map in LA DOT ATCS. ATCS Microsimulation Tool ACS Lite CORSIM, VISSIM BALANCE NONSTOP, VISSIM InSync VISSIM LA ATCS CORSIM (offline post-processing interface) MOTION VISSIM OPAC CORSIM RHODES CORSIM, Q-Paramics SCATS S-Paramics, VISSIM, AimSun SCOOT VISSIM, CORSIM, S-Paramics, AimSun UTOPIA VISSIM, AimSun, S-Paramics TABLE 10 AVAILABLE INTERFACES BETWEEN ATCS AND MICROSIMULATION TOOLS architecture. For distributed systems, in which the intersection controller is responsible for control, communications between hardware elements at the intersections are the most impor- tant. In distributed systems there is no need for a reliable communications network between intersections and a central

still requires a transition from central control to local control. During this transition, signal coordination is usually lost for a short period of time. For this reason, communications net- works for centralized systems most often include some form of fixed communications, with most agencies preferring to own their infrastructure. These communications media include twisted-pair copper wire and fiber-optic cable. The physical media typically provide inherent reliability of 99.995% to 99.99995%, with downtime ranging from a few seconds to a few minutes a year. In real systems, downtime is much higher because of physical intrusion on the infrastructure, though some fiber network approaches even minimize the effects of that danger. Communications networks for centralized systems typically consume at least two-thirds of the cost of a system. Centrally controlled systems usually cost between $40,000 and $80,000 per intersection (Malek et al. 1997). Table 11 shows how interviewed ATCS users perceive criti- cality of communications between their central systems (if any) and field local controllers. Although the users of distributed ATCSs value peer-to- peer and local-to-central communications differently from 34 those users who use centralized ATCSs, all were expected to give equal importance to communications between various elements at the intersection. Results show that communi- cation between various elements at the intersection is con- sistently placed as second in importance, with 50% of users selecting that choice. Eighteen percent of respondents give the highest importance to this type of communication, whereas 32% of the respondents did not report this as being important. Figure 11 shows that approximately 80% of all ATCS agencies use three major types of communication media (twisted pair, telephone lines, and fiber optic cables) to com- municate between the central system and field controllers. These results can be explained by noting that ATCSs that need central-system-to-field-controller communication require very reliable communication for their ATCS operations, which is ensured through the use of physical media between various elements in their ATCS architecture. According to the survey respondents, a similar share of var- ious media types is observed for peer-to-peer communication Criticality of Communications Between Central System and Local Controllers Percent of Agencies Critically important 62 Somewhat important 15 Not important 23 TABLE 11 COMMUNICATIONS BETWEEN CENTRAL AND LOCAL ENTITIES IN ATCS Twisted Pair; 19; 25% Telephone Line; 20; 26% Fiber Optic; 22; 28% Others; 7; 9% Microwave (terrestrial or satellite); 2; 3% Wireless (application protocol or broadband systems); 7; 9% FIGURE 11 Communication media between central system and field controllers.

35 in ATCS operations. Table 12 shows the percentages of vari- ous media types used by interviewed ATCS users for their peer-to-peer communications. Overall, ATCS users do not find that communications for their ATCSs are much more demanding than communications for conventional traffic control systems. The majority of the respondents (72%) find that their communications for ATCSs function similar to other traffic control systems. Sixteen per- cent of the respondents indicated that they have more problems with communications for the ATCS than with communica- tions for their regular systems, whereas 12% of the respon- dents believe that the opposite is the case. SUMMARY This chapter identified system requirements for ATCSs and described how ATCS users perceive those requirements. Detection requirements for ATCSs remain slightly higher than those for conventional traffic-actuated control systems. Most of the ATCS users are satisfied with the way their system han- dles minor detector malfunctions and reports the major detec- tor malfunctions. Early problems with ATCS hardware, which was incompatible for local controllers (primarily for early installations of international ATCSs), are mostly gone. ATCS users still sometimes struggle with handling ATCS-specific hardware primarily owing to a lack of operational knowledge, which in turn indicates a lack of proper training. Although most of the users find their ATCS software to be user-friendly, there is a notion that the friendliness of the software can be significantly improved. Most of the ATCS users do not find that ATCS communications cause more problems than the communications of conventional traffic control systems. Still, communications costs are one of the major operational costs for ATCS users and communications problems may take sig- nificant amounts of their time and resources. The next chapter reports on the implementation costs and benefits of ATCS deployments. Communication Media Percent of Agencies Twisted pair 43 Fiber optic 41 Telephone line 20 Wireless 7 Microwave 2 Other media 5 Does not need any peer- to-peer communications 16 Note: Total percentage exceeds 100 because some of the interviewed agencies deploy multiple types of communication media at various intersections under their jurisdiction. TABLE 12 MEDIA FOR PEER-TO-PEER COMMUNICATION