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.

17 INTRODUCTION This chapter summarizes some of the working principles of major ATCSs deployed worldwide. Detailed descriptions of various ATCSs, based on information obtained from the sys- tems’ developer and/or vendors, are provided in Appendix A. Each of the ATCS descriptions primarily follows a format with the following subsections: • Adaptive traffic control logic • Hardware and software requirements • System architecture and communications • Detection requirements • Special features. Detailed descriptions of all ATCSs and their characteris- tics were beyond the scope of this study. This report could not address in detail all of the ATCSs that are currently used around the world. For some of the ATCSs, literature (in Eng- lish) is scarce (e.g., PRODYN, CRONOS, and ITACA). Some other U.S. brands have a limited deployment history in the United States. Sometimes, the adaptiveness of these systems is claimed owing to the adaptive functionalities and features of their local controllers. This study covers only systems that can be recognized as full adaptive traffic control packages, with an identifiable adaptive framework (logic, detection, etc.), that have been deployed in the field. Some of the emerging or international technologies are still not properly described in the literature. Hence, Table 6 shows 10 ATCSs, with their developers and vendors that were found to be the most impor- tant, to be described in this study. Selection of the systems presented in Table 6 is based on several criteria, of which the most important are: • Length of the presence on the market, • Field deployments, • Documented descriptions of the system (available liter- ature), and • Credibility of developer/vendor in ATCS field. SUMMARY OF ADAPTIVE TRAFFIC CONTROL SYSTEMS CHARACTERISTICS Operational Characteristics ATCSs can be categorized in numerous ways. Some are known to operate best on arterial networks (ACS Lite and SCATS), whereas others are known for their adaptive opera- tions in grid networks (e.g., SCOOT and UTOPIA). However, different concepts and operational features that drive these ATCSs do not always result in significantly different field performances. The following paragraphs review the concep- tual differences of the systems described in this study. Each of the ATCSs is somewhat unique. Therefore, com- parison of the specific features of each of the ATCSs is almost impossible. Instead, this study identified and compared several principles that essentially describe various adaptive traffic control logics. Among the potential principles to be considered it was found that the following are of particular interest for the scope of this study: • Detection, • Type of action, • Adjustment method, • Time frame for adjustment, • Hierarchical levels, • Estimation through traffic modeling, • Adjustments to signal timings, • Flexibility to form regions, • Support for vehicle-actuated operations, and • Transit operations. This list does not include at least a half dozen other prin- ciples that are nearly as important. For example, handling pedestrian operations and the ability to provide a framework for sustainable traffic signal operations have now become two of the most important principles in traffic signal operations. However, although some ATCSs are very advanced in this regard (e.g., SCOOT for pedestrian facilities), others simply rely on operations provided by local field controllers whose comparison is beyond the scope of this study. Detection Various ATCSs use different detection layouts to estimate the state of traffic, which is later used to develop strategies that adjust traffic control in a network. There are generally four major detector location types used by most ATCSs: • Stop-line detectors (e.g., as seen in common actuated operations in the United States and SCATS). CHAPTER THREE WORKING PRINCIPLES OF MAJOR ADAPTIVE TRAFFIC CONTROL SYSTEMS

• Near-stop-line detectors located close to the stop-line (10–60 m), which cannot be used (owing to their prox- imity to the stop-line) to easily calculate queue length by balancing inflows and outflows (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). • Upstream (far-side) detectors located at the exit point of the upstream intersection (as used by SCOOT, UTOPIA, ACS Lite, and optionally by RHODES). Each of these detection layouts dictates, to a certain extent, the type of adaptive traffic control logic that is needed to use imperfect measurements of the current traffic state where imperfections are inherently caused by location, number of detectors, and accuracy of detection technology. Type of Action Some ATCSs proactively adjust traffic control to meet esti- mated traffic demand at each intersection before vehicles arrive. Other ATCSs react by providing feedback to the traf- fic measured during the previous interval. These two con- cepts are usually, but not necessarily, related to the location of detectors. If stop-line detectors are used alone, the ATCSs will usually provide feedback and respond with certain delay. Upstream detectors usually allow for a certain degree of pro- activity, although systems that use these detectors rely more on traffic models and the estimation of traffic demand. In spite of the common belief that proactive systems work bet- ter than reactive systems, there is no hard evidence to sup- port such a hypothesis. Some of the major systems combine two concepts for various segments of their operations. For example, SCOOT determines splits and offsets proactively, whereas the cycle length is computed reactively. ACS Lite is similar: splits are determined reactively, whereas the offsets are determined proactively. 18 Adjustment Method There is a widely accepted notion among traffic signal practi- tioners that most ATCSs optimize signal timings. The reality is that some of them perform some kind of optimization, which is usually constrained by its domain or time allowed to con- duct the optimization process. Some of these optimizations use heuristic techniques, whereas others use extensive search tech- niques, to find solutions. Others do not formally optimize (no search process and no objective function); instead, they adjust signal timings by using some heuristic methods and common traffic engineering concepts. Essentially we have three major types of adjustment methods: • Domain-constrained optimization, where an optimiza- tion search domain is very much limited to avoid high fluctuations of signal timings to prevent negative tran- sition effects (e.g., SCOOT—all parameters, ACS Lite— offsets). • Time-constrained optimization, where the optimiza- tion search process is constrained by time and/or struc- tural boundaries set by local controller policies (e.g., RHODES, OPAC, BALANCE, and MOTION). • Rule-based adjustment, which covers any methods used to develop a (simple) functional relationship between parameters that describe change of traffic conditions and resulting signal timings. Time Frame for Implementing New Signal Timings Some ATCSs adjust some of their parameters every few sec- onds. Others adjust parameters every 10 to 15 min, similar to pattern-matching responsive traffic control systems. Some of the ATCSs combine the two approaches. Again, there is no evidence that the systems that respond faster are (always) bet- ter than the less responsive systems, although such a notion can be found in the literature. TABLE 6 ATCS DESCRIBED IN THE STUDY System Developer/Distributor ACS Lite FHWA/Siemens ITS BALANCE University of Hanover, Germany/Gevas Software, Germany InSync Rhythm Engineering LA ATCS Los Angeles DOT/McTrans MOTION Technical Universi ty Munich, Germany/Siemens, Germany OPAC U. of Massachusetts, Lowell/PB Farradyne RHODES U. of Arizona, Tucson /Siemens ITS SCATS Road Transit Authority, Sydney, NSW, Australia/TransCore SCOOT Transport Research Laboratory, UK/Siemens UK UTO PIA MIZAR Automazione, Italy/McCain

19 Hierarchical Levels It is interesting to note that all of the ATCSs considered in this report, in one way or another, operate on two or more hierarchical levels. Although some systems are seen as more hierarchical than others, they all have a component that uses operations of local controllers and also some tactical (or strate- gic) component that oversees the responsiveness of traffic control on a higher level, regardless of whether it is done in a centralized or in a distributive way. For example, SCOOT, which is often considered a major example of centralized (and tactical) ATCS, also uses demand-dependent features of local controllers to skip phases with no demand. Estimation Through Traffic Modeling The word “modeling” here refers to the use of macroscopic, mesoscopic, or microscopic models (by an ATCS) to estimate the current state of traffic, which is further used as an input to adjust signal timings. For example, analytical models that express relationships between measured and derived traffic variables (such as degree of saturation, phase utilization, etc.) do not conform to the definition of modeling as used in this section. SCOOT is famous for its model that estimates queue lengths based on flow-occupancy profiles from upstream detec- tors. SCATS does not use any traffic modeling in its operations. Most of the other ATCSs use models extensively. In general, models help ATCSs perform more proactively, although they also may introduce errors that can be propagated (spatially and temporally) during the course of ATCS actions. An extreme use of modeling is seen in the newly developed ATCS for New York City, where data from traffic detectors are used to populate a microsimulation model that is then run under a vari- ety of traffic control strategies (within a 15-min time frame). In spite of its ultramodern approach of using a microsimulation model to investigate the quality of signal timings, the system requires that a specified traffic control strategy be confirmed manually (Xin et al. 2008). Adjusted Signal Timings Most ATCSs adjust three major types of signal timings: green splits, cycle lengths, and offsets. However, there are a few ATCSs that do not follow this rule either because they are still under development (e.g., ACS Lite) or because their operations are not based on all of these timings (e.g., RHODES, InSync, and some versions of OPAC do not use cycle lengths). Con- versely, only a few ATCSs adjust or optimize phase sequenc- ing in real time (e.g., BALANCE, MOTION, and InSync). This is primarily because frequent alterations in phase sequencing can cause negative impacts on traffic (frequent transitions). Flexibility to Form Regions For some of the ATCSs (e.g., SCOOT, SCATS, and LA ATCS) it is necessary to divide the entire area covered by the ATCS into those regions or subsystems of intersections that usually need to be coordinated. In such a case, a bor- dering intersection in one subsystem may sometimes ben- efit from leaving its current subsystem and joining the neighboring subsystem. If an ATCS supports automatic reconfiguration of the subsystems it is said that the ATCS supports flexible regions. SCATS is well known for its “marriage and divorce” logic, which supports automatic reconfiguration of the subsystems based on predefined cri- teria. Although SCOOT can do something similar, most of the other ATCSs either do not support such operations or information about such a feature is not easily available in the public literature. Support for Actuated Operations By actuated operations it is meant common gap-out opera- tions executed by local controllers. Most of the ATCSs will set lower and upper boundaries for green splits. A lower boundary is usually defined as minimum green for each phase. Upper boundaries are usually defined by dynamic splits that are optimized by ATCS logic for each cycle (or even for shorter intervals). What happens in between defines whether an ATCS supports actuated operations or not. To further clarify this concept a distinction needs to be made between cases where an ATCS takes responsibility to end the green phase in the absence of traffic demand over a detector and where such a responsibility is transferred to a local intersection controller. For example, RHODES does not allow a local controller to make decisions based on local actuation. If RHODES is in its “Online” mode it will issue a force-off command to stop green for a phase. This com- mand is based on RHODES traffic estimation and not on the common gap-out logic of a local controller. The RHODES concept does not transfer responsibility to gap-out opera- tions to a local controller. On the other hand, SCATS, as well as some other ATCSs (e.g., BALANCE, MOTION, and ACS Lite), will allow the local controller to execute its gap-out logic in between the aforementioned lower and upper boundaries. Transit Signal Priority It is interesting to note that most of the ATCSs presented here provide some type of priority for transit vehicles. However, this priority is often provided at the local controller’s level and is not offered as a result of comprehensive optimization where transit travel times (or delays) are integrated into the opti- mization structure that accounts for network-wide vehicular and transit performances. Table 7 shows how each of the ten major ATCSs consid- ered in this study are categorized for each of the ten principles. The information provided here is based on a comprehensive literature review and does not necessarily reflect how vendors

and developers of ATCSs see their systems. One could also note that the categorization provided in Table 7 is based on information that is sometimes derived from limited systems’ descriptions in the literature. A detail discussion of the principles presented in Table 7 is beyond the scope of this study; however, a few interesting observations are: • High similarities of the operations of MOTION and BALANCE reflect the concept that these two systems were developed in a similar environment of local German policies and standards. • RHODES, OPAC, and InSync are systems that do not require local controllers to use their own actuated logic. • SCATS is the only purely reactive system that does not use any traffic models (and yet it is one of the most widely used ATCSs). 20 Software, Hardware, and Communications Table 8 provides examples of communications, software, and hardware requirements for the ten ATCSs described in this study. SUMMARY In summary, this chapter provided an overview of the opera- tional characteristics of ten most-widely used ATCSs. Selected working principles were briefly described and ATCSs were categorized with emphases on their adaptive traffic control logics, systems’ architectures, and detection requirements. The final sections of the chapter summarize, in tabular for- mat, software, hardware, and communication requirements. The next chapter reports on institutional issues confronting most ATCS users, from installation through everyday opera- tions and maintenance of ATCSs. Detection: SL = stop-line; NSL = near-stop-line; MB = mid-block; US = upstream. Action: P = proactive; R = reactive. Adjustment: RA = rule-based adjustment; DCO = domain-constrained optimization; TCO = time-constrained optimization. Level: L = local; C = central. Timings: S = splits; Cl = cycle length; O = offset; PS = phase sequencing. A TC S A CS L ite B A LA N CE In Sy nc LA A TC S M O TI O N O PA C R H O D ES SC A TS SC O O T U TO PI A Detection SL, MB/ US NSL NSL SL & US NSL MB & SL MB & SL SL, NSL, MB US & SL US & SL Action P & R P & R P & R P & R P & R P P R P & R P Adjustment DCO TCO DCO RA, TCO, DCO TCO TCO TCO RA DCO TCO Time Frame 5–10 min 5 min Phase/ Cycle/ 15 min Cycle 5–15 min Phase/ Cycle/ 5 min Sec by sec Cycle Cycle/ 5 min 3 sec — Cycle Level C/L C/L C/L C/L C/L C/L C/L C/L C/L C/L Model No YesYes Yes Yes Yes Yes No YesYes Timings S, O S, Cl, O, PS S, Cl, O, PS S, Cl, O S, Cl, O, PS S, Cl, O S S, Cl, O S, Cl, O, PS S, PS Flexi Region No No YesYes No No Vehicle Actuated No YesYesYes Yes No No No TSP No YesYes Yes Yes Yes Yes Yes Yes Yes Yes Yes YesYesYes Yes TABLE 7 OPERATIONAL CATEGORIZATION OF ATCS

21 RHODES 2070 ATC with NextPhase-Adapt Controller Software McCain 170E with BI-TRAN 233 firmware with ACS Lite support. Peek 3000E with external NTCIP translator. Also run with Econolite ASC/2 with NTCIP firmware w/ACS lite support. BALANCE European controllers GEVAS VTnet/View ISDN dial-up line 2400 bps-modem wireless MOTION SITRAFFIC C8xx,C9xx Controllers Signalbau Huber Actros Controllers Older Siemens controllers PC SITRAFFIC OPAC Model 2070/multiple firmwares Model 170 with 68360 Processor/multiple firmwares NEMA Controllers VME Bus or equivalent PC MIST RHODES Software on OS9/Windows/ Linux field-hardened, single-board computers V34 modem Ethernet Fiber-optic cable … Central control via wireless links using public communication channels such as Internet/GPRS Dedicated central to field connection at 9600 baud or higher Peer-to-Peer possible through Central Supports all communications media Peer-to-Peer over Ethernet; Bandwidth ≥96000 bps. Supports all communications media; preference is fiber optic. LA ATCS Model 170 Controllers/ 172.3 Firmware Type 2070 Controllers/ City of LA Software Dedicated central to field connection 1200 bps using time division multiplexing 4 intersections/communication channel No Peer-to-Peer communication needed Supports multiple communication media InSync Existing Controllers Cabinets require InSync processor to communicate with controller using detector cards Internet access to InSync System through a local computer InSync System PC ATCS/Traf Graph Editor Ethernet communication ACS Lite Siemens NEMA (M50 series) or 2070 (2002 TEES or later) with SEPAC NTCIP 4.01F firmware. ACS Lite software running on field- hardened PC or central server (Windows XP). Comm: Serial or Ethernet. Serial is single channel, where 9600 baud supports up to 8 signals. Faster serial can support more signals. System Controller Software Communications Econolite ASC/2 with Adapt X interface software TABLE 8 SOFTWARE AND HARDWARE SPECIFICATIONS FOR ATCS (continued on next page)

22 SCATS Requires 300 bps link to each controller using two-wire or equivalent. Multidrop system is supported that requires a two-wire line or equivalent to the first intersection in a cluster and then to each intersection in the cluster in a ìdaisy chain ” configuration. SCATS supports various configurations that can utilize TCP/IP, leased line, and conventional telephony services (i.e., dial-up). SCOOT Both SCOOT and ACTRA SEPAC support for 170 can be provided controller from the central— at 9600 baud, 8 controllers can be supported. SCOOT algorithm and ACTRA Supports all communications media; wireless typically not used. UTOPIA Peek’s EuroController with MDSL unit System Controller Software Communications Eagle NEMA Eagle 2070/ PC SCATS require a separate channel toWindows Server 2003 PBS with MS PC-based software Logic is distributed over control units. Model 170 controllers with SCATS conversion kit, which includes a new processor board with embedded software with 2070 or 2070 N controllers with SCATS proprietary controllers. NEMA AWA Delta 3N controllers. There are several RTA type approved SCATS controllers in current use sourced from Australia; i.e., Tyco Eclipse, QTC, Aldridge ATSC/4, Tyco PSC and a myriad of legacy controllers still supported; e.g., Phillips PTF. TABLE 8 (Continued)