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.

51 ACS LITE FHWA initiated development of Adaptive Control Software Lite (ACS Lite), prescribing a lower cost and more easily managed sys- tem, to surmount the major deployment impediments and bring this rarely used state-of-the art technology to the mainstream state of practice (Curtis et al. 2009). ACS Lite offers significant cost sav- ings relative to earlier FHWA-sponsored adaptive systems by bet- ter leveraging existing infrastructure; evaluations based on both field trials and simulation studies have shown significant benefits, such as delay reductions of up to 35% (Shelby et al. 2008). The following discussion provides a more detailed description of the ACS Lite system architecture, adaptive logic, and evaluation results to date. Project History The research and development of ACS Lite has been done by Siemens, with collaboration from other partners including major signal controller manufacturers Eagle (now Siemens), Econolite, McCain, and Peek, who accepted an invitation from FHWA to par- ticipate in the project (Ghaman 2006). The project began in 2002, and the last of four field evaluations (one with each of the four con- troller vendors) was completed in 2007. A concise summary of the ACS Lite project and findings can be found in Shelby et al. (2008). As of 2009, ACS Lite was in the midst of a secondary research effort by FHWA to incorporate cycle time adjustment. Currently, cycle length settings are changed according to a time-of-day schedule. Despite this limitation, ACS Lite has been able to pro- duce substantial benefits based on its adaptive split and offset capabilities (e.g., 35% delay reduction in Houston). That being the case, ACS Lite is currently being marketed and deployed as is by the aforementioned controller vendors who participated in the original project. ACS Lite Architecture An ACS Lite system is composed of the following hardware: • An ACS Lite system computer, • The traffic signal controllers, • Communications between ACS Lite and the controllers, and • Vehicle detectors. In the four field tests—one with each participating controller manufacturer—the exact nature of the system architecture varied somewhat, depending on the manufacturer, as illustrated in Fig- ure A1. More detail is available in Shelby (2008). Each of the four system components is briefly discussed in the following paragraphs. ACS Lite System Computer In the interest of the widest possible applicability, FHWA envi- sioned ACS Lite as being capable of governing traffic signals in either of the following scenarios (Crenshaw 2000): • ACS Lite could be operated from a traffic management center—such as a traditional central system, or • ACS Lite could be operated in on-street manner—such as a traditional field master. In either case, the adaptive control software was to be encapsu- lated in a single computer, to avoid the expense associated with distributed adaptive systems sponsored by FHWA in the 1980s and 1990s (Luyanda et al. 2003). These earlier non-Lite ACS systems had required that each intersection be equipped with a dedicated processor (aside from that of the traffic controller itself) in order to host adaptive optimization algorithms at each intersection. These prior systems used the 2070 controller, specifically to utilize its unique Virtual Machine Environment (VME) expansion slot, which accommodates the installation of such add-on processors. Intersection Controllers FHWA, focused on cost minimization, intended ACS Lite to be compatible with National Electrical Manufacturers of America (NEMA) model controllers, which have historically been less expensive than 2070 controllers, although McCain opted to inte- grate with its 170 controller (which is generally less expensive). This compatibility enabled deployment of ACS Lite without the need (or expense) for controller upgrades in most of the four field trials. However, in each case, a firmware (controller software) upgrade was required to accommodate support for additional ACS Lite status messages. Another “intangible” and often overlooked cost saving ben- efit comes from the capability to retain familiar controller firmware—the core of which is largely unchanged by the commu- nications upgrade. The time and effort that would otherwise be necessary for staff to learn to use and maintain completely new controller firmware could be significant. Communications FHWA required that ACS Lite be designed to use National Trans- portation Communications for ITS Protocol (NTCIP) as its com- munications protocol, given the desire to encourage adoption of this national standard. It was also specified that ACS Lite be able to communicate over low-speed serial communications, which constitutes the existing infrastructure to most signal controllers at this time. To achieve this goal, custom NTCIP-compatible status messages were developed for ACS Lite to substantially reduce required bandwidth, such that ACS Lite was able to com- municate during field trials with eight to ten signals using 9600 baud communications. Higher data rates are necessary to sup- port more controllers. In each of the four field trials, ACS Lite was deployed leveraging existing twisted-pair communications. Modem upgrades were required in some cases; however, this expense compares favorably with the costs associated with installation and maintenance of fiber optic, peer-to-peer com- munications as has been used in deployment of non-Lite ACS systems previously developed by FHWA. At the time of this APPENDIX A Vendors’ Descriptions of Major Adaptive Traffic Control Systems References cited in this appendix can be found in Appendix C.

52 writing, ACS Lite supports 16 controllers in a single system. ACS Lite also supports Internet Protocol (IP)-based (Ethernet) communications. ACS Lite monitors traffic signals by polling each controller on a per-minute basis for time-stamped state changes. If a poll request fails, the status report is still available from the local controller until the end of the minute, so the system has ample opportunity to poll again. This affords a measure of insulation from occasional com- munication errors, which can compromise systems that require per-second communications. In such per-second systems, a missed poll generally means a hole in the data that cannot be recovered once the 1-s polling window has passed. This appears to be partic- ularly relevant in the context of wireless communications. Vehicle Detectors The detection scheme required by ACS Lite is compatible with typical layouts used for intersections under fully actuated control. This reduces the total cost to instrument a typical arte- rial as required for adaptive control. ACS Lite also incorpo- rates detector processing in such a way as to be relatively flexible with respect to the size, location, and capability of detectors. This capability often reduces the need to resize or relocate existing loop detectors that are in the right location, but are not of ideal dimension. The demand measurement scheme also aims to address concerns that have been raised about the sensitivity of adaptive control performance with respect to pre- cise detector count accuracy. (a) ACS Lite Local ControllersNTCIP protocol (b) ACS Lite Econolite protocol (solid lines) ASC/2M Field Master NTCIP protocol (c) ACS Lite BI Tran protocol 2070 Field Master NTCIP protocol (d) Peek protocol ACS Lite NTCIP protocol NTCIP Translators Local Controllers FIGURE A1 ACS Lite as deployed with (a) Siemens, (b) Econolite, (c) McCain, and (d) Peek.

53 To adjust splits, ACS Lite requires stop-line detectors for each phase or movement, preferably separated out for individual lane-by-lane monitoring, although lanes serving the same phase or movement may be tied together if necessary. Stop line detec- tors monitor volume and occupancy on green, and the process- ing logic accounts or adjusts for the detector length and maxi- mum vehicle speed. Detectors sized from 4 to 70 ft long have shown good results (although 70 ft is generally too long in many scenarios). On approaches where progression is desired (generally the arterial approaches), advance loops (typically 6 ft × 6 ft) are used to monitor cyclic flow profile, to identify the arrival of pla- toons, and use these data for adjustment of offsets to improve progression. Detector processing has been designed to reduce sensitivity to the accuracy of count data. Count accuracy may deteriorate sub- stantially if a loop begins counting axles instead of cars or if video detection cannot precisely separate out two vehicles traveling closely together, owing to the angle of the camera. As examples of “sensitivity reduction,” consider that green-occupancy flow measures are less sensitive to errors than pure volume-based flow measures. However, the technique is somewhat more involved than measuring only green-occupancy. Accurate turning probabilities and saturation flow rates are generally a source of sensitivity (to error) for signal timing opti- mization. These values are certainly subject to change through- out the day, according to daily travel patterns, and are also influ- enced by unexpected weather. However, ACS Lite does not require calibration or configuration of these parameters and is designed to gauge traffic demand well over a wide range of con- ditions (Shelby et al. 2008). Aside from basic verification that a detector indeed works, there is no need for field studies or elabo- rate detector calibration in ACS Lite. Configuration is limited to known facts, such as the location and dimensions of a detector. Adaptive Traffic Control Logic ACS Lite operates by monitoring traffic signals that are run- ning normal, coordinated timing plans and then making incre- mental adjustments to split and offset parameters as often as every 5 to 10 min. Thus, ACS Lite does not take over second- by-second control of the sequence or duration of each phase, but rather the normal actuated logic allows skipped phases, gap-out, max-out, and/or force-off in a normal manner. Cycle length is cur- rently not adjusted by ACS Lite, although future enhancements are planned. The cycle length is currently dictated by the “under- lying” or “baseline” timing plan, which is selected according to the time-of-day schedule (Luyanda et al. 2003). Split adjustments are based on measures of the “utilization” of each phase (Luyanda et al. 2003). Detector volume and occu- pancy data are processed, primarily during green intervals, to gauge the amount of time that traffic is flowing across the stop- line. ACS Lite estimates the degree of saturation of each phase. The adjustment logic reallocates split time to balance (with optional biasing) the degree of saturation across all phases, subject to configured minimum green times, pedestrian interval requirements (optionally), and maximum green times (when they are not inhibited during coordination). Thus, time is reallocated from a phase with an excessively long (i.e., underutilized) split time to provide more split time for an oversaturated phase. The split adjustment logic provides an optional “progression bias- ing” mechanism that distributes “extra” or “slack” green time in the cycle (if it is available) in greater proportion to designated progression phases, which are typically arterial through phases. This option is almost always used, as it has been shown very effective in exploiting the availability of “slack” time to pro- vide a wider green band for improved progression (Shelby et al. 2008). Figure A2 provides a screen-capture of the ACS Lite’s web- based user interface, which provides a color-coded bar chart indi- FIGURE A2 Monitoring degree of saturation in ACS Lite.

54 cating the degree of saturation for each phase. These measures are overlaid, in the enlarged view in Figure A3, on a ring diagram, to portray the trade-offs of adjusting split time between phases. This particular screenshot illustrates that phase 3 (a cross-street, left- turn phase using typical NEMA phase numbering) is 100% satu- rated, whereas all of the main-street phases (1, 2, 5, and 6) are less than 60% saturated. The figure also illustrates that phase 3 cur- rently has a 13-s split, which could be reduced to a minimum of 10 s, or a maximum of 20 s (which allows up to 3 s of room to reduce split time or 7 s of room to increase time). Oversaturation poses a daily challenge to some intersections. If oversaturation afflicts one phase (or more, but not all phases), then splits will be relocated to alleviate the situation if possible. However, in some cases, oversaturation on one phase (or more) cannot be alleviated with any amount of split reallocation. As this situation develops, ACS Lite will “defend” or “protect” the traffic engineer’s original split timing as follows. Suppose the phase 3 oversaturation in the prior scenario (see ring diagram in Figure A2) cannot be alleviated, despite a substantial realloca- tion of split time from other phases. This traffic flow scenario has been observed most predictably at shopping center access signals during late November and December. If ACS Lite were to attempt to balance saturation across all phases, then all phases would become saturated and arterial progression would be com- promised. To counteract that result, ACS Lite manages phase splits such that no phase is allowed to experience more than 95% saturation with less than the traffic engineer’s original split allo- cation. For example, if phase 4 was originally allocated 30 s, then ACS Lite might be willing to reallocate some of that time to phase 3, reducing phase 4 to 20 s, so long as phase 4 remains no more than 95% saturated. If traffic flow picks up again on phase 4, such that it exceeds 95% saturation, then ACS Lite will return some or all of its original split time to bring maximum sat- uration just below 95%, despite phase 3 being oversaturated. The traffic engineer’s original split time allocation for desig- nated “progression bias” phases (generally arterial through phases) will be “defended” at a lower saturation threshold of 90%. Thus, despite oversaturation on a cross street phase, the main street progression phases will not surrender split time to the extent that it approaches oversaturation. This policy has proven effec- tive in alleviating surges in traffic on a particular approach to a reasonable extent, while also protecting arterial progression to a reasonable extent. At intersections that experience oversatura- tion on a daily basis (often predictably during peak flow), this policy results in splits gravitating back to the traffic engineers original settings, such that the traffic engineer can still dictate behavior in this scenario, and drivers can expect reasonably pre- dictable similar day-to-day service during these periods, which could provide the most reasonably consistent and predictable commute times during these periods. ACS Lite offset adjustment decisions are based on monitor- ing advance detectors (and phases) on each approach and aver- aging data over successive cycles to form cyclic flow profiles (and green phase profiles), which also reveal early-return-to- green behavior. Figure A3 shows a screen shot from ACS Lite, illustrating the cycle flow profiles (blue bars) and green time pro- files for all inbound and outbound arterial links of an intersection. ACS Lite adjusts the offset of each intersection in turn, by con- sidering three offset options—keep it the same, adjust a few sec- onds earlier, or adjust a few seconds later—and selecting the option that maximizes the percentage of arrivals on green for all designated inbound and outbound links. BALANCE The traffic-adaptive network control BALANCE started in two research projects supported by the European Union (Munich Comfort and TABASCO). Beginning in 1992, BALANCE was developed at Technische Universität München and later also at the companies GEVAS software and TRANSVER. Since 2002, GEVAS software has been responsible for maintenance and fur- ther development of BALANCE. The system has been imple- mented in several cities including Remscheid, Hamburg, and Ingolstadt. Adaptive Traffic Control Logic BALANCE belongs to the generation of the newest German traffic signal control systems. Therefore, it is not relevant whether the existing traffic signals are controlled in fixed- time, traffic-actuated, or with public transport prioritization. BALANCE can deal with any kind of existing control, as long as these can be accessed and controlled by the traffic computer. The data packages provided by BALANCE are small and are transmitted only every 5 min. BALANCE’s use of traffic modeling allows for minimal use of traffic detectors. BALANCE will develop optimal signal timings for the existing detection in the field and does not require that every intersection be equipped with detectors. The basic system architecture of the BALANCE system (shown in Figure A4) divides the functionality for traffic signal control hierarchically on two levels (Braun et al. 2008): • On the local or operational level for single intersections, the local actuated control reacts on short-term changes in the current traffic demand (every second); and • On the tactical level of a traffic signal network, the BALANCE algorithm works as a macroscopic system and covers the middle-term and long-term area (5 to 15 min) of the traffic-actuated control. Minimization of transition times, caused by traffic-actuated signal coordination (offset optimization, green wave), and rough adjustment of release times of the signal groups are done cen- trally on the network level. Precise adjustment of release times, on the other hand, takes place inside the traffic controller. BALANCE influences traffic light signals in the network by two types of traffic control commands: • Framework signal plans—for every interstage, the earliest and the latest points at which the interstage could start are defined. The interval between the two points is available to the local, traffic-actuated control for its own local deci- sions. Apart from these local decisions, the framework sig- nal plan defines the greens at the single signal groups and the coordination of the signal devices. • Signal program—BALANCE selects the program with the best cycle time for the current traffic situation from a pre- arranged set of signal programs. The signal program index serves as output date. The selection is done at the same time for all traffic signals of one control group. A control group is defined as a subset of traffic signals in the network (e.g., a group of signals in close proximity).

FIGURE A3 Cyclic flows (blue) and green times for two-directional arterial link.

56 Traffic Control Optimization The optimization model of BALANCE network control deter- mines the length of release times (split) and the offsets accord- ing to a common cycle length. The optimization is done by Genetic Algorithm, which imitates the process of natural evolu- tion. Interaction between optimization process and field imple- mentation is shown in Figure A5. The final signal timings are achieved over several generations in the constrained time win- dow of 5 min. Although the solution space for the appropriate signal timings is very complex, the Genetic Algorithms have proven that a solution close to the theoretical optimum can be reached (Braun et al. 2008). The result of optimization is a framework signal plan created for every intersection in the network. A framework signal plan determines fixed or variable signal timings for all traffic signals in a coordinated group of signals. Within given framework plans, local intersection controllers can execute traffic-actuated opera- tions based on the local traffic demand. Priority for public trans- port is also executed locally. Detection Requirements BALANCE can use the data from any type of detectors, regardless of their placement in regard to the intersection. Detection data could be provided in as a disaggregated form as possible so that BALANCE can reconstruct (approximate) the raw detection inputs before the data are further processed. However, transmis- sion of raw detection data requires higher communication capacity than if the data were preprocessed and then sent to a central com- puter. This need for high-capacity communication media may cause problems for certain communication networks. In such a case, BALANCE can operate with aggregated data, but at mini- mum traffic volumes and detector’s occupancy needs to be pro- vided. It is important that the length of an aggregation interval does not exceed 2 min. In Germany, traffic detectors are traditionally placed at a short distance (10 to 50 m) upstream of the intersection stop-lines. This type of detector allows good vehicle-actuation operations; how- ever, it cannot be used to estimate input flows and queues in the same way as (far) upstream detectors, or for estimation of satu- ration flow rates, in the same way as stop-line detectors. To get a good estimation of current traffic conditions a new cycle-based queue length estimation method was developed. This method allows estimating back-up lengths of distances five or ten times greater than the distance between detector and stop-line. The heart of the estimation method uses fill-up time. Time needed to fill-up, with cars, an area between the intersection stop-line and the end of the detector. For that approach, this time is measured from the beginning of the red phase until the detector is continuously FIGURE A4 Fundamental system architecture in BALANCE. FIGURE A5 Genetic Algorithm (GA) optimization process in BALANCE.

57 occupied. From the length of this time can be estimated the speed of the vehicles approaching the traffic signal at the end of the green time. A self-calibrating method was developed to estimate queue length based on the fill-up time. This estimation method is a standard way to use detector data for both German ATCSs: BALANCE and MOTION. Operations The BALANCE traffic model creates an internal spatiotemporal representation of the current traffic conditions based on the detected traffic loads. The traffic model has two modules: macro- scopic and mesoscopic: 1. The macroscopic traffic model estimates the origin– destination matrix between each pair of entries and exits in the network. The origin–destination matrix is based on a predefined weight function matrix and traffic inflows and outflows measured at the borders of the network. 2. The mesoscopic traffic model iteratively takes into con- sideration current traffic signal status, link travel times, and platoon dispersion factors to develop traffic flow pro- files for all links in the network. A forecasting module of BALANCE estimates impacts of vari- ous traffic control strategies for the following time period by calculating performance measures such as delays, stops, and queue lengths for all intersection approaches. The performance measures are computed with the assistance of both mesoscopic and macroscopic BALANCE models. The mesoscopic model estimates queues at intersection approaches and other deterministic performance measures. Stochastic fluc- tuations in traffic and origin are estimated through the macro- scopic model. The delays from both models are integrated into the calculation of the Performance Index (PI). The GEVAS software program VTnet/view is used as a visu- alization interface for BALANCE. VTnet/view displays all traffic parameters computed by BALANCE, such as traffic volumes, link traffic densities, and link level-of-service. Road works and messages posted on variable message signs also can be visualized. Diagrams and journals can be created directly from the visual- ization interface and can be aggregated for any time period. Two-dimensional display of the network geometry (shown in Fig- ure A6) allows visual control of the supplied detector loops and signal groups during operation. FIGURE A6 VTnet view of traffic load in BALANCE.

58 Network geometry for traffic visualization in VTnet/view can be taken from all common network formats (e.g., ESRI shape files). Some network elements, such as type and location of turn- ing lanes, detectors, and stop-lines, need to be entered separately. For turning lanes, signal location plans can be displayed as a back- ground image. Detectors and stop-lines can be read from German standard exchange format for signal engineering (e.g., OCIT-I- VD), and then they need to be placed properly on the map. Phases, phase transitions, and signal groups are as well read from standard exchange formats. Follow-up supply of the special parameters required for BALANCE can be done directly in the traffic engi- neer’s workstation CROSSIG. INSYNC InSync is an adaptive traffic signal system developed by Rhythm Engineering (Lenexa, Kansas) that uses innovative sensor tech- nology, image processing, and artificial intelligence. These ele- ments are integrated into a system that automatically optimizes local traffic signals and coordinates signals along roadway arteri- als according to real-time traffic demand. The use of InSync elim- inates the need for static signal coordination plans. Adaptive Traffic Control Logic There are two aspects to InSync’s signal optimization that deal with the conflicting objectives of providing the progression of platoons of vehicles along a main arterial and the clearance of vehicles involved with secondary traffic movements within the grid: the global and the local. InSync operates and optimizes signals within the minimum/maximum parameters that users have input into the initial configuration settings of the system. The Global Element: Time Tunnels and Adjustable Periods for Optimizing Progression Users need to determine the main directions within the grid, but can also redefine and automatically toggle between arterials by (Time-of-Day) TOD/DOW (Day-of-Week). Special parameters can be set in for intersecting main arterials that provide effective coordination within the grid. Time Tunnels Green waves/time tunnels are guaranteed by suc- cessively turning each light green at the expected arrival time of vehicles from upstream intersections. This can be illustrated using speed lines as shown in Figure A7. Speed lines are con- figured starting with a chosen facilitator intersection. By default, the speed lines for the main two directions of travel intersect at this facilitator intersection. Time tunnels are made to occur at this intersection by requiring the simultaneous initialization of green lights for both directions. The facilitator intersection decides a time at which it will serve a green band for the coordinated tun- nel phases and communicates that time with the adjacent inter- sections. Each adjacent intersection uses the expected vehicle travel time between it and the intersection it received the tunnel message from to decide when it needs to turn the tunnel phases green for both its downstream tunnel phase from the facilitator intersection and its upstream tunnel phase to the facilitator inter- section. Start times for downstream tunnel phases to the facilita- tor (or upstream from the facilitator) at the adjacent intersection FIGURE A7 Concept of “Time Tunnels” in InSync.

59 are adjusted by (− travel_time) so that vehicles are released from the upstream intersection in time to reach the facilitator intersection when it initiates its tunnel time. Start times for down- stream tunnel phases from the facilitator (or upstream to the facil- itator) at the adjacent intersection are adjusted by (+ travel_time) so that vehicles are released from the downstream intersection as they arrive from the facilitator intersection. Using the travel times between each adjacent intersection these tunnel times are calculated by each intersection as it receives the dynamic tunnel phase timing messages from each adjacent intersection along the artery. Visually, the speeds lines for an artery with two main directions of north bound and south bound with four “listener” intersections and one facilitator inter- section in the middle would look like this: Expected travel times between intersections are listed on the x-axis, and elapsed time is the y-axis. The slope of a speed line is always 1, because the expected travel time between intersections has a 1 to 1 relationship with wall time (or time on a clock). Tunnel start times at each intersection for the north and south phases are relative to the tunnel start times at the facilitator. If we say that the north and south tunnel phases start at t = 0 at the facilitator intersection, then tcN (the time of the start of the north bound downstream tunnel phase at Intersection C) = 0 + travel_time_to_facilitator = 0 + 10 = +10. This says that Inter- section C needs to force a green light for the north bound phase 10 s after the facilitator intersection does. tcS (the time of the start of the south bound upstream tunnel phase at Intersection C) = 0 − travel_time_to_facilitator = 0 − 10 = −10. This says that Inter- section C needs to force a green light for the south bound phase, 10 s before the facilitator intersection does. To complete the example, the other start times at Intersections A, B, and D are: tdN: +35 tdS: −35 tbS: +30 tbN: −30 taS: +50 taN: −50 Additionally, the speed lines are not actually required to intersect at the facilitator or even intersect at an intersection. The tunnels can be offset to allow any arrangement of speed lines as desired. This flexibility can provide for more efficient progression. Also, travel times for both directions between adjacent intersections do not have to be the same. The south bound direction may take 5 s longer to travel than the north bound direction between two inter- sections. The minimum tunnel bandwidth (or guaranteed green time for a tunnel phase) is configurable. Vehicles traveling along the main arterial that arrive at an intersection at the beginning of the time tunnel ideally progress unstopped all the way through the coordinated arterial. InSync automatically extends green lights beyond the set parameter if it observes that the moving platoon has not sufficiently gapped out at a user changeable percentage of occupancy (calculated every second by InSync) or set gap time. InSync may, if permitted by the user, provide a green light along the main street before the light is guaranteed to be green. Real-time traffic data are contin- ually passed to downstream processors by their upstream part- ners that can also be factored into the optimizing process. Intelligently Adjustable Periods Through its global interactive communications with the intelligent processors at each inter- section (also see the next section: The Local Element) the facili- tator will, if necessary and as soon as possible, expand or contract the time between tunnels to provide the optimal period lengths to serve each phase along the arterial. At the end of every period, each local processor is “polled” by the facilitator and “reports in” if it needs more time, the same time, or less time to clear its local phases. These period length adjustments serve to efficiently progress vehicles and clear out queues, both globally and locally. The Local Element: Logic and Features of the Optimization Algorithm Beyond the constraints communicated by the facilitator as “tun- nel messages” that guarantee coordinated green lights for the main arterial, the signals operate in “intelligent fully-actuated” mode. The time between tunnels is called a period. If a period is 90 s in duration and a green light is guaranteed for the main direc- tions at each intersection for 10 s, then 80 s are available for the local optimizer to schedule states (phase pairs) at each inter- section according to its intelligent scheduling. The local opti- mizer embodies the dominant logic and algorithm of the adaptive capacities of the system. Scheduling of States There are three main factors the opti- mizer considers in its scheduling logic: 1. If it is close to the initiation of a new tunnel, it will sched- ule a main street sequence of states. This sequence of main states is only allowed to be scheduled such that after it completes there is sufficient time to schedule a sequence of cross street states. If the main direction requires a lead- ing left turn, its clearance time is also included in the cal- culation for time needed on the cross street. 2. If a tunnel has recently ended, it will schedule a cross street sequence as its priority. The amount of time needed for the cross street is based on a balance between the actual amount of clearance time needed and anticipated time needed. If there are no cross street queues it will schedule a miscellaneous main state. 3. A miscellaneous main state is scheduled for phases with queues that have been waiting the longest. Wait times being equal, the phase with the largest queue is scheduled. Any available miscellaneous time is used to schedule any phase with real-time demand including protective permis- sive left turns on the main directions. Empty Queues In the calculation of a state sequence every vehi- cle phase is assumed to have a queue of 1 vehicle, if no queue exists. These phases typically find their way into the states sched- uled toward the end of the state sequence. This way, if vehicles do arrive on these previously empty phases, they can be served. In this sense, those states act as place holders for vehicles that may arrive. If a phase remains empty when it becomes time to serve that state, that state is either removed or modified to contain phases that do contain a queue of vehicles. Duration of States After an initial sequence of states is sched- uled, the durations of each state are continually modified to con- tain enough clearance time to serve vehicles that may have arrived after the state was initially scheduled. As each previous state in the sequence reaches extension time, all states scheduled after adjust

60 their initial durations for newly arrived vehicles. Adjusted dura- tions and extensions are limited by the amount of time left to serve vehicles on pending phases. For a state with two phases, ph1 and ph2, if ph1 clears out, a phase concurrent with ph2 that has a queue can be put in place of ph1, assuming there is enough time remaining in the scheduled state to fulfill the new phase’s mini- mum green time, amber time, and red time. Termination of States States being served are ended or dynam- ically modified as phases are terminated. Termination of a phase occurs in one of two ways. Both of these methods employ a model of linear change with time, such that a phase will termi- nate at a higher percentage of capacity as time increases or the phase’s gap time will decrease to a point at which, once presence for a detection zone is lost, the phase will terminate as time increases. Calculating a Sequence The optimizer gathers the data for the calculation: current queues, pending pedestrian calls, and any upcoming plans for tunnels. These requirements are converted into restrictions on the beginning and ending times of green lights for phases. A queue is converted into a minimum clearance time: the ending time minus the beginning time for the phase must be at least equal to the time to clear the queue plus the change time required for that light to turn green; similarly for a pedestrian call, except that the clearance time is the time required for pedestrians to walk across the intersection. A plan for a tunnel is converted into restrictions on the beginning and ending times for the phase: the beginning time must be less than or equal to the beginning time of the tunnel minus the change time, and the ending time must be greater than or equal to the ending time of the tunnel. The optimizer considers each permitted sequence as a sequence of transition times at which phases begin and end, with the restric- tions transformed into inequalities in these transition times. For each sequence, a minimum-total-time solution satisfying these restrictions and the total waiting time for queues are calculated. The sequence with the least total waiting time is chosen. If no solution satisfying the restrictions exists for any permitted sequence, then the lowest priority of the restrictions are relaxed until a solution is possible: first, queues on permissive left turns are transferred to their adjacent through movements, then the queues with the least waiting times have their clearance times reduced, then, finally, only the plans for tunnels are considered. Once a solution is obtained, the times are translated into a sched- ule of states and the first state of the schedule is initiated. Early Release Sometimes, it is useful to prevent cars from leaving an intersection too early and collecting at a downstream intersection, either because there is a limited amount of space available for cars to queue or to absolutely ensure that the down- stream light is green when they arrive. This is sometimes called metering. To handle these situations, the optimizer has the con- figuration option of restricting early release of a tunnel phase at an intersection. Period Length Evaluation During local optimization, the inter- section continually analyzes its queue lengths and percentage of occupancy for each phase. If the intersection determines that it has not been given enough overall time to adequately clear out its queues (drop the percentage of occupancy to a desired threshold), the intersection reports this to the facilitator (see the previous sec- tion: The Global Element). This method of adjusting the period is reactionary. To be more proactive, each intersection constantly analyzes the flow rate of vehicles in each phase. If the current flow rates over the past 15-min durations are comparable to the histor- ically logged flow rate, then it is assumed that the current pattern of traffic can be served using a period that was adequate enough to serve the historical pattern of traffic. This process is known as period prediction and is communicated to the facilitator inter- section along with the real-time load analysis of the local inter- section. The facilitator intersection uses all of this information to determine if/how it will adjust the current period. Digital Signal Control Concepts—Finite Number of Signal States (No Transition) InSync does away with set cycle lengths, set splits, and offsets to a fixed point in the cycle that have traditionally been considered essential for signal coordination. These concepts are germane to a linear/analog approach to signal coordination. InSync is an artifi- cially intelligent/digitally based finite-state changing machine. By its method of externally influencing a controller it causes any con- troller to effectively function digitally. This digitization does not refer to the nature of the component parts of the controller, but rather a “digital methodology” of how traffic signal phases are chosen. In relation to traffic movements, there is a maximum of 16 possible sequences of phase pairs (states) at any quad inter- section. Because it knows the real-time traffic demand, InSync is able to instantaneously select and input to the controller any user- permitted phase pair associated with these 16 sequences that it deems optimal. InSync needs to decide: (1) optimal sequence, (2) when to initiate a state (phase pair), and (3) duration of that state. It is not limited in its choices or their duration times by a set cycle length, split, or offset. Except for minimums and maxi- mums and 1 s passage times, all typical volume density inputs to the controller are disabled so that it runs in free mode. This per- mits the controller to quickly react to and change the traffic sig- nal according to the optimized calls coming through InSync. Another important advantage of this “state-changing” architec- ture and methodology of signal optimization is that the traffic flow disruption caused by the transition from one static timing plan to the next, or by preemptions, is eliminated. Hardware and Software Requirements Hardware Overview—Cameras, Processor, Detector Cards, Ethernet Communications InSync uses high-end IP digital cameras in weatherproof enclo- sures that are normally mounted on mast arms with standard brackets. The cameras are connected to an InSync processor installed within each local traffic cabinet through a CAT-5 Eth- ernet cable and a 24-volt electrical wire that provides power. The InSync processor is placed in the local traffic cabinet and inter- faces with the local signal controller using detector cards that are plugged into existing detector card racks. Other system hard- ware includes a 110/24-volt transformer, surge protectors, an un- managed Ethernet switch, and a pigtail cable for red/green returns to be fed back into the processor from the controller’s leads. Except for an I/O board within the processor and the associated detector cards that are each required to communicate with the various pro- prietary controllers, the system uses off-the-shelf components. For arterial coordination to take place, Ethernet communica- tions need to exist between the networked intersections. Because InSync uses distributed network architecture, an unlimited num- ber of signalized intersections may be coordinated.

61 Configuration Procedures—Standard Web Interface InSync is both Ethernet and web-centric in its functionalities. Each processor and every camera has an IP address. These com- ponents can be accessed directly by means of the network without any proprietary software. All the necessary configurations of and any software upgrades to the system software can be accom- plished remotely over the Ethernet network. The onsite cameras are properly aimed, zoomed, focused, and tightened to effec- tively view vehicles arriving at and progressing through a traffic signal. A web page associated with the InSync system is accessed through a standard Internet browser (Internet Explorer or Firefox) that leads a user through the process of drawing all the necessary detection, count, and contrast zones that quantify the traffic data generated by approaching vehicles. It also provides a dropdown menu page for all the adaptive system parameters. Interface Methodology—Determination of Inputs Optimized Calls to Signal Controllers InSync is a plug-in technology that interfaces with all existing traffic signal controller and cabinet architectures. It controls traf- fic signals by submitting calls to the traffic controller through detector cards, just as inductive loops do. However, InSync only allows one phase pair at a time to be input to the controller by fil- tering, prioritizing, and suppressing the demands generated by the detection of vehicles that are approaching an intersection in real time. Pedestrian calls are also filtered by InSync and are permit- ted at the times deemed optimal by InSync’s real-time coordi- nation. InSync’s calls are passive in that InSync will yield to any higher priority calls that are directly communicated by users’ choice into the controllers; that is, preemptions or central system software priorities. In these cases, InSync will continue to serve as a detection device and then revert to its optimization mode when the controller begins to respond to its calls again. It can also be configured to toggle automatically between detection mode and optimization mode by TOD/DOW if users desire to use pre- determined timing plans. Detector Requirements The video/data collection sensors (the IP cameras) capture and communicate real-time images of vehicles approaching an inter- section to the InSync processors. The processor reads and inter- prets these images for its optimization processes. This kind of image tracking provides a sufficient estimation of real-time queue lengths and the percentage of occupancy of each lane and approach for optimization purposes. Advanced detection is not essential to create an effective traffic-adaptive dynamic, although it can be incorporated seamlessly into the system. These data are updated by the processor every second. (Similar traffic data could also be input using other kinds of sensors.) Failure Mitigation When a sensor is placed in emergency/fog mode, InSync will access 4 weeks of historic green split data for specific TOD/ DOW at that particular approach. These data are normalized into a split time to put in to the controller until the sensor is function- ing again. A call is issued for every phase for at least a minimum split time, which happens in the following cases: • A camera fails to talk to a video processing detector subsystem. • The video processor determines the view is not sufficiently clear. • The processor does not hear from a particular detector subsystem. A text alert is seen on the video image when a sensor is in emergency/fog mode. Calls on all phases are automatically input when: • InSync determines that the detected traffic is significantly lower than historical averages, which indicates a sensor failure. • The I/O board fails to hear from the processor for 2 s. • A detector card fails to hear from the I/O board for 2 s. If communications between networked intersections fail, indi- vidual processors will continue to perform local optimization functions. LA ADAPTIVE TRAFFIC CONTROL SYSTEM The Adaptive Traffic Control System (ATCS), developed by Los Angeles Department of Transportation (LA DOT), was first deployed as a part of the Automated Traffic Surveillance and Control (ATSAC) Center in 1984 for the Los Angeles Olympic Games. Prior to the implementation of the ATCS, the heart of the system was a group of mainframe computers that communicated with both the control center operators and traffic signal equipment in the field. The software used by the mainframe computer was the Urban Traffic Control Software (UTCS) on an OS/9 real-time operating system. Funding for the system was provided by the city of Los Angeles, Los Angeles County Metropolitan Transportation Authority (LACMTA), and FHWA (Hu 2000). Adaptive Traffic Control Logic One of the primary goals of the LA ATCS development team was to develop an open system that can be used to test various control algorithms. The basic principle of ATCS adaptive operations is to adjust signal timings on a cycle-by-cycle basis by changing cycle length, splits, and offset. Optimizers for splits and offsets are called in ATCS “Critical Intersection Control” and “Critical Link Control,” respectively. Each optimizer can function indepen- dently of others. The system allows for maximum flexibility when individual intersections are assigned to various sections (groups of signals). ATCS is a very responsive system that can respond to spikes in traffic demand. On the other hand, the system has some attenuating features that help the system avoid overreacting to short-term variations. LA ATCS does not perform any optimiza- tion when adjusting basic signal timings; however, it applies heuristic formulas based on extensive operational experience. Critical link and critical intersection approaches are used to calculate intersection splits and offsets. ATCS configuration parameters can be easily adjusted to adapt to different street con- figurations. The adaptive adjustment of signal timings is based on changes in volumes and occupancies, which are collected every second but utilized every cycle. The system allows for limitation in variation of cycle lengths by providing its upper and lower lim- its. When splits are adjusted minimum phase green times are con- sidered. LA ATCS does not alternate phase sequence, which is fixed all the time, but phases can be omitted based on the existing traffic demand. Figure A8 shows a Dynamic Map functionality in

62 LA ATCS, where operational characteristics of an intersection can be monitored in real time. Hardware and Software Requirements The ATCS system, which was fully implemented in 2003, replaced the Concurrent Computer Corporation mainframe with an Intel/Windows NT-based server. The four terminals were replaced by a single Intel/Windows 2000 personal computer (PC) workstation connected to the server through the Ethernet network. Operators control and command the network using the ATCS Client on each PC Workstation. Network and traffic signal information is displayed through graphics in the ATCS Client. Information between the PC workstation and the server is carried by the Ethernet network. The ATCS Kernel is the heart of the system. It is the ATCS Kernel that provides, on a second-by- second basis, for the ability to issue timing change commands, the computation of automated timing adjustments, and the capa- bility of the system to send information to the operator. The data flow between the Kernel and the field is managed by the Data Server (DS), which is the next critical piece of software running on the server (Adaptive Traffic Control System 2006). Besides switching to commodity equipment, ATCS was writ- ten using commercial grade C++. All elements of the software, except for the Kernel, were written to be Object Oriented. This allows for easier changes to be made to the software, thus giv- ing it the unique ability to change over time. The server also pro- vides information to a central ‘supervisor’ machine that uses the data to update the Softgraph graphics display. The supervisor machine also provides the external time source to all other machines to maintain synchronicity. Time data are also received by means of a radio from the WWV transmitter in Colorado Springs, Colorado. LA ATCS central software can be interfaced either with Type 170 controllers, in which case BI Tran Systems 172.3 software is used, or with Type 2070 controllers, which utilize city of Los Angeles Traffic Signal Control software. In any case, central hardware is a rack-mounted server with a backup PC. Work- stations have two 21-in. monitors and multi-port PCI serial cards (Peripheral Computer Interconnect). The system runs on an Ethernet network. System Architecture In LA ATSC’s system architecture (shown in Figure A9), the centralized area computer (PC server) communicates to local controllers. The communications between elements in architecture use multi-port serial cards that are connected to communication FIGURE A8 Dynamic Map shows intersection details in LA DOT ATCS.

63 lines. All area computers and workstations are interfaced though a Client Graphical User Interface (GUI). The architecture rep- resents a distributed client–server system, which can handle up to 400 intersections and 6,400 detectors per system. Currently, LA ATCS operates approximately 4,300 signalized intersections with approximately 3,000 of them running adaptive control logic (Hu 2000). One of the most significant recent improvements in ATCS is the development of the Area Server. Instead of a large main- frame with terminal servers, which were originally deployed, the core function of the control system is now handled by a commercial-grade computer with off-the-shelf client worksta- tions hooked up to it. Significant reduction in deployment cost is realized with this design along with an expanded base of knowl- edge for maintenance. Detector Requirements LA ATCS requires at least one detector per lane for each phase. Detectors are usually located 200 to 300 ft upstream of the inter- section, which allows the system to collect a set of useful traffic metrics such as volume, occupancy, speed, stops, queue, and delay. ATCS has features that enable the system to identify and screen out bad detectors. Traffic demand at the detectors is smoothed before being used to project new cycle lengths. If detec- tor data are not available, phase splits are prorated based on fixed- timing plans stored in the ATCS databases. Communications LA ATCS uses dedicated communication paths between host and local controllers. Time division multiplexing is used in the com- munication between elements in the network. Local controllers are polled once per second at 1200 bps. In this way four inter- sections can be handled per communication line. Multiple com- munication protocols are allowed. Download and upload features between the central system and local controllers are supported. Communication from the field 170 and 2070 Traffic Signal Controller is accomplished by the way of a 1200 baud twisted pair to a local area hub, terminating in a GDC Corporation multiplexer. From the multiplexer, the information is sent through a fiber optic SONET loop to the server in the ATSAC Control Center. Detector data from the field are processed on a second-by- second basis. Timing plans are created and maintained as ASCII files, which are compiled into binary format and used by the server to change timing plans. Force Off commands are used by the server to cause the controller to move into the next timing interval. Special Features LA ATCS applies a set of logics to handle oversaturated traffic conditions in its network. For isolated intersections this logic usu- ally means an increase in cycle length, which is triggered by high- FIGURE A9 LA DOT ATCS system architecture.

64 occupancy data. Green splits are adjusted based on phase demands. For major arterials the logic for oversaturated conditions iden- tifies critical link(s) and provides progression for the congested approaches to reduce oversaturation both temporally and spatially. For minor intersections the system runs double-cycled operations to reduce unnecessary delays. LA ATCS uses loop-transponder technology to detect buses and provide transit priority. The system checks bus schedules in the central database and if the bus is late it provides green extension/red truncation for the late bus. LA ATCS is capable of calculating bus arrival time, which is used to determine the exten- sion time and minimize adverse impact on cross streets traffic. MOTION MOTION represents one of the systems developed in Germany as a response to permanently increasing traffic loads in German cities, something that previous traffic-actuated control was not able to cope with. In a way, MOTION (along with BALANCE, another German ATCS) represents a “German ATCS,” where an ATCS is developed to accommodate use of the existing infra- structure. As such, MOTION is developed to work around inher- ited problems such as a limited number of detectors that are not placed optimally to gather necessary microscopic data to catch changes in cyclical patterns of traffic flows. Instead, existing detectors are used to estimate performance measures that are used to estimate state of the traffic in the entire region. With an increase in traffic flows, MOTION will detect the change through the esti- mated state of the traffic and will suggest change of the signal timings to accommodate the change in traffic flows. The entire feedback mechanism works in a 5- to 15-min framework, which allows utilization of existing communications without the need to install fiber optics or other high-tech and expensive communi- cation media. Local controllers continually take care of traffic at individual intersections buy applying common traffic-actuated logic (Mueck 2005). Adaptive Traffic Control Logic Within MOTION cycle time, split and stage selection is calculated to achieve favorable and balanced saturation levels for all inter- section approaches. In this way, excessively low utilization (with high delays for concurrent movements) and excessively high utilizations (that can lead to oversaturation and congestion) are avoided. Selected links in the network can be assigned higher pri- ority through specific weighting parameters; for example, main corridors or roads used by trams and buses. Coordination is opti- mized afterwards by using models of delay and a number of stops for all flows, applying an objective function that allows individual link weightings. Additional specifications on the priority of the flow and offset times can also be manually fixed in order for example to consider ancillary operational conditions of closely adjacent signal systems. First experiences with adaptive network control in Germany resulted in the awareness that additional operational functionali- ties could be integrated in ATCSs. ATCSs would be able to react to severe incidents by special far-reaching measures; for example, to dissolve congestion caused by serious accidents. MOTION has an internal strategy management that allows for an extensive reaction to special operational situations. Those situations can be either automatically identified by internal sets of conditions or by input from the traffic management center. This strategy management allows for individual configuration of all impor- tant optimization parameters, such as signal timing plans, min- imum and maximum green times, stage sequences, and all sorts of weightings. The main difference between MOTION and conventional ATCSs (such as SCOOT, UTOPIA, SCATS) is that the opera- tional second-by-second control of the signal groups is sepa- rated from the adaptive control level. Instead, controllers are in charge of the operational decisions, whereas the adaptive logic (on the network level) updates controllers every 5 to 15 min with new framework plans (Mueck 2008). This approach brings the following benefits to the concept of adaptive traffic control: • There is no need for traffic state estimation on a second- by-second basis. State estimation algorithms can be based on the data aggregated per minute or per cycle. • Missing detector measurements can be replaced by meth- ods using averaged values without the need to model them in on a second-by-second basis. • There is enough time for central processing units to run extended algorithms for the optimization for a network- wide coordination. System Architecture and Communications MOTION is positioned as a tactical component in the overall management of traffic signals. MOTION receives data from the detectors and traffic information from an existing city-wide traffic management system and returns adapted signal timing plans to the local controllers every 5 to 15 min (as shown in Fig- ure A10). Because MOTION is aware of what is going on in the entire region and not only at the intersection whose signal tim- ings are being modified, it improves the quality of the signal timings and consequently improves traffic performance on the roads (Mueck 2008). Network state information can be provided to the local con- trollers. For example, queue lengths and delay times estimated by the network optimization module can be used to determine local transit priority strategies to better synchronize private vehicles and public transit. The internal traffic model allows for area-wide optimization (theoretically), reaching a system-wide optimum. Optimization can be configured according to specific demands such as mini- mum environmental impact or maximized journey speeds. Unde- sirable dynamical effects are avoided, because they can occur when optimization is done on a step-by-step procedure from con- troller to controller. Internal forecasting algorithms allow for the optimization of cycle time, split, and offset under consideration of upcom- ing queuing back phenomena, as well as blocking and gating mechanisms. The cycle time, offset, and split optimization algorithms are highly configurable. It is easily possible to correspond to regional traditional design patterns and planning standards. Sophisticated configuration patterns and models allow for responding to local geometrical or operational requirements and restrictions.

65 A fast and efficient internal strategy module allows for a quick and network-wide response to traffic incidents. It increases the effectiveness of the network control in areas around trade fairs, airports, and shopping centers, which characteristically have fast-changing traffic conditions and a high risk of incidents. The strategy management is an adequate interface to highway or parking systems and can be integrated with city-wide traffic management centers. Local real-time adaptive behavior is handled by the local controller. The local second-by-second actuated-traffic control of each intersection is still monitored by traffic engineers and carried out autonomously by the individual controllers. As a result of the use of local detectors a fast reaction to micro- scopic traffic changes by traffic-actuated stage length regula- tion is guaranteed. This works even in the case of communication failure and maintains local flexibility to the most possible extent. Local public transport priority and any other controller- specific features are also maintained during communication failures. MOTION’s hierarchical approach can use all kinds of local controllers, with no or very moderate adaptations. The internal optimization models allow for the use of any kind of local con- trollers, including ramp metering devices. Local controllers can be included by using signal program selection without the need for adaptation or new interfaces. In this way a control over the network can be migrated from local controllers to MOTION in an efficient low-cost way. The MOTION’s hierarchical approach uses low-bandwidth communication channels. No high-speed, real-time communi- cation system is necessary. The communication can be restricted to update rates of 5 min, which keeps costs low and allows for implementation even under disadvantageous infrastructure con- ditions or with wireless connections. Detector Requirements Figure A11 shows typical detector configurations that are used by MOTION. Any detection technology can be used; however, the best operations are achieved with traditional induction loops. MOTION uses information from the detectors to estimate state of the traffic in the network under its control. One of the perfor- mance measures that is widely used for the traffic state esti- mation is queue length at intersection approaches. However, German intersections traditionally use local detectors that are installed near the stop-lines. These locations are perfect neither for measuring input flows and queue lengths nor for calculating output flows. The main purpose of most detectors in Germany, which are 10 to 60 m upstream of the stop-line, is the application of vehicle actuation methods. To use the existing detectors to compute queue lengths a new cycle-based queue length estima- tion method was developed. This method allows for the estima- tion of queue lengths that are up to 5 to 10 times longer than the distance between detector and stop-line. Based on these esti- mated queue lengths, MOTION is able to compute consequent delays and travel times (Mueck 2008). FIGURE A10 Overview of MOTION operations. FIGURE A11 Detector placement in MOTION.

66 In real-world conditions, missing or faulty detector data are a phenomenon that cannot be avoided. If ATCSs’ operations require second-by-second data, missing or faulty values can lead to a drastic reduction in the quality of the optimization, poor sig- nal timings, and poor traffic performance on the streets. To avoid these problems, MOTION by its models only requires aggregated values and developers integrated an algorithm for the replacement of faulty or missing aggregated detector data. The algorithm provides substitution of the aggregated detector values when such values are not available from real detectors. The method guaranteed robust and reliable operations even with a significant proportion of faulty detectors. The method is not based on historic data patterns of the faulty detectors; however, it takes into account recent measurements of neighbouring detectors. The basic principle of this method is shown in Fig- ure A11 (Mueck 2008). For each of the detectors used by MOTION the measure- ments are collected in histograms showing the frequency of each measurement value relative to the frequency of all other values measured on the respective detector. In the case of a mea- surement failure the histograms of the failed detector and its neighbouring detectors are accumulated to sum curves, stan- dardized by 100% (shown in the Figure A12). The recent flow values measured on the neighbouring detectors are reflected by their individual sum curves, producing specific percentage values (right side of the figure). The percentages lead to an aver- age value, which is finally applied to the sum curve of the fail- ing detector. The resulted flow value can be used as substitution for missing measurements. The method was tested on a net- work with 200 detectors and the results showed that the esti- mation error is less than 100 veh/hour in more than 90% of the estimated values. Special Features Public transport (PT) priority plays an important role in Germany. The dissemination of local PT priority has reached certain sat- uration levels in the German market. Because of the costly investments, the installed modern controllers and control designs cannot be simply replaced by shifting PT optimization to a network-wide level. There is concern that adaptive traffic con- trol, which is operated at traffic control centers, could possibly jeopardize achieved quality standards of prioritization at local controllers (Mueck 2008). Because priority for single PT vehicles cannot be provided by adjustments at a central level with its updating cycle of 5 to 15 min, MOTION has introduced a concept of automatically calculated frame signal plans. These frame signal plans are cal- culated individually for all controllers based on the results of network-wide optimization. Frame signal plans include all parameters that are used to configure the local traffic-actuated operations and also all parameters that determine priority for locally detected PT vehicles. This concept provides MOTION with full flexibility to calcu- late cycle times, splits, stage sequences, and offsets and at the same time to preserve intended quality of PT priority at each controller in the traffic network. This method provides MOTION with the full capacity to coordinate traffic without restrictions imposed by PT priority settings at local controllers. OPAC The Optimized Policies for Adaptive Control (OPAC) strategy is a real-time signal timing optimization algorithm, which was orig- inally developed at the University of Massachusetts, Lowell (Gartner et al. 2002). OPAC is a distributed control strategy fea- turing a dynamic optimization algorithm that calculates signal timings to minimize a performance function of total intersection delay and stops. The algorithm uses measured as well as modeled demand to determine phase durations that are constrained only by minimum and maximum green times and, if running in a coordi- nated mode, by a virtual cycle length and offset that are updated based on real-time data. Originally, OPAC was developed as a distributed strategy featuring a dynamic optimization algorithm for traffic signal control without requiring a fixed cycle time. Signal timings are calculated to directly minimize performance measures, such as vehicle delays and stops, and are only constrained by minimum and maximum phase lengths. OPAC development progressed through four versions, which are briefly outlined here (Gartner et al. 2002). • OPAC-1—Applied Dynamic Programming (DP) to solve the traffic control problem. Although this procedure ensures globally optimal solutions, it requires complete knowledge of arrivals over the entire control period, which makes it unsuitable for real-time implementation owing to the amount of processing involved as well as the lack of available real- time information. • OPAC-2—Represented simplification of the OPAC-1 and it served as an intermediate phase for the development of a distributed on-line strategy. The control period was divided into stages, and each stage was divided into intervals. The program computed optimal switching times for the stages so that the overall delays to vehicles are minimized. Valid switching times are constrained by minimum and maxi- mum phase durations. • OPAC-3—Represented further simplification of OPAC-2, whose main problem was that it needed knowledge of arrivals over the entire stage length (1 to 2 min), which was difficult to obtain in practice. To use only readily available flow data without degrading the performance of the opti- mization procedure, a “rolling horizon” concept was intro- duced. The stage, which consists of n intervals, is called the Projection Horizon (or simply Horizon), because it is the period over which traffic patterns are projected and opti- mum phase change information is calculated. From detec- tors placed upstream of each approach actual arrival, data for k intervals can be obtained for the beginning, or head, portion of the horizon. For the remaining n – k intervals, the tail of the horizon, flow data may be obtained from a model. A simple model consists of a moving average of all previous arrivals on the approach. An optimal switching policy is calculated for the whole horizon; however, only those changes that occur within the head portion are actually being imple- mented. Therefore, there is a chance for dynamically revis- ing the decisions when more recent (i.e., more accurate) real-time data are obtained. • OPAC-4—As part of FHWA’s Real-Time Traffic-Adaptive Signal Control System (RT-TRACS) project, OPAC control logic was expanded to include a coordination (synchronization) strategy suitable for implementation in

FIGURE A12 MOTION method of data substitute for faulty detectors.

68 arterials and networks. This version is referred to as Virtual- Fixed-Cycle OPAC (VFC-OPAC) because from cycle to cycle the yield point, or local cycle reference point, is allowed to range about the fixed yield points dictated by the virtual cycle length and the offset. This allows for the synchronization phases to terminate early or extend later to better manage dynamic traffic conditions. VFC-OPAC consists of a three-layer control architecture. Layer 1, the Local Control Layer, implements the OPAC rolling hori- zon procedure: it continuously calculates optimal switch- ing sequences for the Projection Horizon, subject to the VFC constraint communicated from Layer 3. Layer 2, the Coordination Layer, optimizes the offsets at each intersection (once per cycle). Layer 3, the Synchronization Layer, calculates the network-wide virtual-fixed-cycle (once every few minutes: as specified by the user). The cycle length can be calculated separately for groups of intersections, as desired. Over time the flexible cycle length and offsets are updated as the system adapts to changing traffic conditions. Adaptive Traffic Control Logic VFC-OPAC allows, from cycle to cycle, the yield point or local cycle reference point to range about the fixed yield points dictated by the cycle length and offset. This allows the synchronization phases to terminate early or stay later to better manage dynamic traffic conditions. Over time, the cycle length and offset are also updated as the system adapts to changing traffic conditions. At the end of each cycle the OPAC logic determines whether to adjust the offset and what the upper and lower bounds are for the next yield point. The cycle length is calculated periodically by the cen- tral software, which can consider conditions at groups of inter- sections for which coordination is desired (e.g., an arterial). With these enhancements, the coordinated OPAC now provides a true adaptive control algorithm with many features including (Gartner et al. 2002): • Full intersection simulation with platoon identification and modeling algorithm—Data from detectors upstream of the intersection are used to develop expected arrival patterns for all phases. The signal timing and these arrival patterns are used to estimate delay and stops. Depending on the veracity of the detector data, the patterns may be uniform, random, or in platoon. • Split optimization for up to eight phases in a dual ring con- figuration—The phases whose splits are to be optimized is configurable. Minor phases, for example, can be left to the default control, whereas only major phases are optimized. Phases with no detectors can also be left out of the opti- mization because it would be based on unreliable estimates of demand. • Configurable performance function of total intersection delay and/or stops—The performance function is a weighted function of total intersection delay and stops. The weights are configurable to eliminate delays or stops, or set their relative importance. Emphasizing delay causes OPAC to equalize delay among phases, which generally will lead to shorter cycles. Emphasizing stops causes OPAC to equalize stops among phases, which tends to mean longer cycles. • Optional cycle length optimization—The central system optimizes the cycle length for each section or group of inter- sections. A “critical intersection” is determined periodically and the cycle length calculated based on data from the criti- cal intersection. The goal of cycle length optimization is to meet phase switching timing determined by local conditions, while maintaining a capability for coordination with adjacent intersections. However, the algorithm uses a cycle length constraint, which means that the cycle length can start or terminate only within a prescribed range. As a result, all VFC-OPAC-controlled intersections can “oscillate” with a common frequency. • Optional offset optimization is performed in the field com- puter using peer-to-peer data from adjacent intersections. Offset adjustments may be made as often as once per cycle. Options for offset adjustments are: leave the current offset (zero change), increase the offset for 2 s, or decrease the offset for 2 s. • Free and explicit coordinated modes—OPAC may operate “free” where there are no cycle or offset constraints. Split optimization is constrained only by phase-specific mini- mum and maximum green. In “coordinated” mode split optimization is also constrained by dynamic cycle and off- set values. • Phase skipping in the absence of demand—OPAC may skip the user-selected phases when there are no demands • Automatic response to changes in phase sequence—It is sometimes advantageous to have phase sequence change by TOD. For example, with lead/lag left turns, the leading phase can be changed between the morning and evening peak peri- ods. OPAC automatically detects when these changes have been made and responds accordingly, although it does not itself determine or optimize phase sequence. Hardware and Software Requirements OPAC is designed to work with a variety of traffic signal con- trollers and firmware, including NEMA (TS-2), 170-ACT, 2070, and 2070-Lite controllers. With NEMA controllers OPAC uses Single Board Computers (SBC), whereas with ATC controllers OPAC uses a VME card (e.g., 68060). BI Tran systems software is used for 2070 signal controllers. At a central location OPAC requires multiple PCs for Operator Interface, a server, a database, device drivers, and a communication server (all shown in Fig- ure A13). This configuration can usually control up to 250 inter- sections with no additional hardware upgrade. Usually OPAC comes integrated within MIST—an Advanced Transportation Management System developed and supported by Telvent Farra- dyne (Pooran 1998). System Architecture and Communications Figure A13 shows a typical OPAC system configuration with a two-level distributed system. The local level consists of Type 2070 controllers, which host the OPAC real-time adaptive con- trol strategy. The adaptive strategy resides on a separate central processing unit card (68040) within the VME chassis of the con- troller. MIST provides the central system functionality, includ- ing operator interface, server, database, and communications between the central system and field controllers, as well as communications between adjacent controllers. Upstream loop detectors, installed on all through approach lanes to the inter- section, are used to provide real-time traffic data (count and occupancy) to OPAC. For isolated intersection control OPAC architecture is fully distributed, whereas for coordinated inter- sections there are few tasks that are performed on a central level.

69 For example, cycle length is defined at central level and com- municated periodically to the intersection controller. Also, if adjacent intersection controllers are not physically connected then peer-to-peer information is communicated through the cen- tral level (Pooran 1998). For proper operations OPAC needs a dedicated central to field connection, at 9600 baud or higher. OPAC architecture can use phone lines, fiber optics, or wireless communication media, but the reliability of communication is crucial for the proper operations of the system. If communication between cen- tral level and local controllers fails OPAC will run autonomously. In this mode OPAC still runs its adaptive logic, but the coor- dination between intersections may be degraded. There are four communication levels within typical OPAC architecture. The following list provides the response rate for each of them (Pooran 2000): • Central level—OPAC: OPAC status is polled once per 30 s. • Central level—Controller firmware: once per second or once per 30 s. • Controller firmware—OPAC: once per second. • Peer-to-peer communications: once per 30 s. Detector Requirements OPAC can work with loop, radar, video, and any other detection technology that can provide the required data [volume, occu- pancy, and speed (measured or calculated)]. Ideal detector loca- tion is about 10 s upstream of the stop-line (at free flow speed) or upstream of the worst queue on each lane of all through phases. OPAC also requires one count detector in each lane of left-turn pockets as far upstream as possible. Special Features OPAC has special features to support traffic operations in over- saturated conditions. For isolated intersections, OPAC provides maximum green to the affected phase(s) if occupancy on the OPAC detectors exceeds a user-specified threshold. For coordi- nated intersection control, oversaturated conditions are handled through provision of maximum green to congested phases, sub- ject to the current length, and adjustment of cycle length in response to increasing congestion. RHODES RHODES (Real-Time Hierarchical Optimized Distributed Effec- tive System) is a real-time traffic adaptive signal control strategy that seeks to optimize the real-time performance of a corridor or network of intersections. To provide “optimal” control of traffic through a network, the system: • Takes real-time input from vehicle detectors, • Predicts the future traffic streams throughout the network, and • Outputs “optimal” signal control settings based on these predictions. The basic concept behind the RHODES strategy and algo- rithms is to set signal phasing that proactively responds to stochastic variations in traffic flow. This requires (1) the identifi- cation of various traffic objects at different levels of aggregation— individual vehicles, platoons of vehicles, and overall traffic flow in terms of vehicles per minute; (2) the identification of their natural dynamics and responsiveness to signal control; and (3) setting phase durations to allow these traffic objects to move according to their objective. DIGIBOARD Modem Modem Remote OI and Maintenance Access IBM 8235 DIALS Box Modem Remote Workstation RT-TRACS Operator Interface/ ServerComm Server Database Server Stop-bar Loop Detector Signal Controller Upstream Loop Detecotr Existing Hardware & Communications Link Ethernet Modem FIGURE A13 OPAC system architecture.

70 Perhaps the biggest difference between RHODES and “tradi- tional” traffic control is that RHODES sets phase durations explicitly rather than timing parameters such as splits, cycle lengths, and offsets, as is done with traffic-responsive systems. This difference is what allows RHODES to “proactively respond” to the stochasticity of traffic, rather than forcing traffic to move in a cyclical fashion. Adaptive Traffic Control Logic Rather than reacting to changes in traffic conditions, RHODES uses peer-to-peer communications and predictive algorithms to identify upcoming changes and prepare accordingly. With RHODES, there is no explicit coordination; that is, there are no offsets and no fixed cycle lengths. The cycle length will vary from cycle to cycle, depending on current conditions and demand. Instead, the peer-to-peer communication and data exchange between intersections is able to provide “implicit” coordination that varies based on demand within the network. Working in tandem with the signal controller, RHODES expands the controller’s existing feature set by adding adaptive control capability. This allows for the use of RHODES on an as- needed basis; for example, during special events or as part of reg- ular TOD operation during select periods. The RHODES system is comprised of two separate software modules, RHODES and PREDICT. RHODES is responsible for the real-time control of an intersection’s traffic signal control. Using information pro- vided by presence detectors at the stop-bar of each approach and passage detectors located upstream of each approach, RHODES determines the optimal phase sequence and green times that will minimize the delay incurred by vehicles passing through the intersection. The second module, PREDICT, provides estimates of departures that are heading toward neighboring, or peer, inter- sections, in effect extending the upstream detection capability of those intersections receiving information from PREDICT. In this manner, information about vehicles’ movements are passed from intersection to intersection, providing a method for implicit coordination of traffic signals along a corridor, as opposed to the explicit coordination imposed by traditional coordinated sig- nal control. Essentially, RHODES acts as a very intelligent high-level con- troller, similar to a coordinator, to monitor the operation of the traffic signal and adjust the phasing to meet a desired objective, typically a reduction in vehicle delay. By operating in this man- ner, the basic infrastructure of the signal control environment is unchanged, which serves to isolate RHODES from the rest of the cabinet, providing a measure of protection, while also insulating RHODES from the specifics of the hardware interface. RHODES operates in two distinct modes, Standby and Online. In Standby, RHODES is in a “passive” mode, receiving and processing data from the traffic controller once each second. In Online, RHODES continues to receive and process data once each second, but is now “active” and performs the additional step of issuing holds, force-offs, and omits to the traffic controller to effect optimal phase timing. Typically, RHODES changes mode; for example, from Standby to Online or vice versa, in response to a request sent by the traffic controller, usually in conjunction with a plan change. In this way, RHODES can be configured to run as an alternative mode of operation during specific times by setting up an “Adaptive” plan within the controller, much as a Free or Coordinated plan would be used. In addition, RHODES may take itself out of Online mode, returning to Standby if there is a loss of data that would affect its ability to provide proper traffic control operation. Note that even though RHODES appears to control the signal operation while in Online mode, the traffic controller is only act- ing as RHODES’ proxy, placing the phase requests on its behalf. As a result, the safeguards in place within the controller and cabinet environment are still in force. This means that, should RHODES request an improper action; for example, terminating a phase before its minimum green time has been satisfied or serving conflicting phases, the request will be ignored, with the controller operating as expected; for example, continuing to serve the current phase until the minimum green has been satisfied. There- fore, all minimum green times, clearance intervals, and similar parameters programmed within the traffic controller will be hon- ored at all times, regardless of the mode RHODES is in. If these parameters differ in value with those programmed into RHODES, the values in effect on the controller are those that will actually be used. Thus, data inconsistency between the two will only result in performance degradation rather than a potential safety issue. Even in the unlikely event that the RHODES system becomes unre- sponsive or fails, the controller will revert to its own traffic con- trol method; for example, Coordinated or Free operation, so that proper traffic operation may continue. Hardware Requirements and Configurations Currently, the processing and memory requirements of RHODES are such that the native processors on existing traffic controllers are incapable of supporting its operation. As a result, a field- hardened single board computer is used as the hardware platform for RHODES. In addition to OS9, RHODES is also capable of running under both Windows and the Linux operating systems for added flexibility when considering how to integrate RHODES within an existing traffic control system. Currently, RHODES has operated under three different traffic controller hardware configurations. 1. RHODES with 2070 Advanced Traffic Controller (ATC)— The preferred RHODES configuration is one that uses the 2070 ATC as the controller platform, running the NextPhase software package. The 2070 ATC is used to interface with the cabinet hardware and supports a variety of cabinet environments through the use of different field input/output modules. 2. RHODES with Econolite ASC/2S—Although the 2070 ATC is becoming common in the transportation commu- nity, other controllers have been available for much longer and have well-established client bases. One of the most common is the Econolite ASC/2S series of controllers, which come in a variety of configurations to support dif- ferent cabinet environments. To provide an option to the standard 2070 configuration, an “Adaptive” ASC/2S was initially developed that added an adaptive interface com- ponent to the base ASC/2S functionality. In this configura- tion, the ASC controller software was modified to incorpo- rate communications with the AdaptEx interface module to provide support for RHODES. Later, these ASC controller

71 software changes were made part of the standard build, so that an off-the-shelf ASC/2S could be used, eliminating the need for the specially modified “Adaptive” ASC/2S and requiring only a serial cable connection with the external RHODES processor. 3. RHODES with RHODES Adaptive Control Unit (RACU)— Although RHODES is capable of communicating with traf- fic controllers by means of the Adapt and AdaptEx interface modules, not all traffic controller software is capable of running these interfaces. In addition, unlike with the ASC/2S, modifying the controller software may not be an option. Faced with these problems, a hardware solution was developed that allows RHODES to control a standard NEMA controller through the use of a RACU, which is essentially a stripped-down 2070 ATC. Although this is not the “preferred” hardware configuration for RHODES and is no longer in use, it demonstrates that RHODES may be interfaced with various types of traffic control hardware to realize an adaptive control system. As discussed, RHODES does not interact directly with its envi- ronment, instead relying on the traffic controller and controller software to provide data about signal status, detector calls, etc. For this reason, RHODES is independent of the actual traffic cabinet environment. It has been deployed in TS1, TS2 Type 1 and Type 2, and 170-style cabinets and could also be deployed in an Intelligent Transportation System (ITS) cabinet environment. As long as the traffic controller software supports RHODES, the cab- inet environment has no direct impact. Currently, RHODES sup- port is only provided through two software products, Adapt and AdaptEx, both developed by Siemens ITS. Adapt is an adaptive control module that provides an interface between RHODES and the NextPhase traffic control software used on the 2070 ATC. AdaptEx provides similar functionality in an external module that interfaces with the ASC controller software. System Architecture Figure A14 shows a typical RHODES system architecture at each traffic signal intersection. Communications RHODES requires a communications network that is capable of providing reliable transmission of data between peer intersections on a second-by-second basis. RHODES relies on peer-to-peer communications; that is, data exchanged between adjacent intersections to make accurate predictions about future demand and therefore provide proactive, rather than reactive, traffic control. The component that provides this peer-to-peer data is the PREDICT module, which is responsible for calculating the number of vehicles that depart the local intersection en route to each peer intersection. Instead of a proprietary protocol, the IP is used, with each intersection assigned a set of unique IP addresses to identify it among its peers. To manage this communication, some networking configuration is required to support proper rout- ing and identification between peers. Detector Requirements RHODES requires the installation of a number of detectors to properly model the flow of vehicles into and out of an intersec- tion while it is in operation. Figure A15 shows the placement of detectors in a typical installation. “Stop-bar,” or presence, detec- tors are required at each approach and are used to identify the presence (or absence) of queues. In RHODES, queues are asso- ciated with individual movements on an approach; that is, left, through, and right, rather than individual lanes, so multilane movements need only a single detector spanning these lanes. Typically, these loops are 6 ft wide and extend a distance of 20 to 70 ft from the stop-bar, depending on the type of detection sys- tem used and the agency’s policy. Because these detectors are used by RHODES to identify the presence of a queue, the length would be large enough to prevent a queue from “dropping out” as it discharges, as this will be incorrectly interpreted as an empty queue. Although presence detectors are associated with movements, upstream passage detectors, on the other hand, are used to pro- vide counts of incoming vehicles and therefore need to be sepa- rated out by lane to ensure that vehicles are not missed. For this purpose, 6 ft × 6 ft loops, or their equivalent (e.g., in radar or image detection systems), are typically used. To provide accu- rate counts of incoming vehicles, it is important that these pas- sage detectors be placed behind the farthest queue that typically forms to ensure that spillback over the detector does not take place. Mid-block placement is strongly recommended for this reason, but closer installation can be accommodated, albeit with a reduction in performance. Typically, these detectors are placed a minimum of 250 ft to 400 ft behind the stop-bar. In addition to these baseline requirements, placement of addi- tional detectors can improve the performance of RHODES and should be considered. Long-turn bays that experience a high vol- ume at times are good candidates for additional passage detection near their entrances. These detectors will ensure that RHODES has an accurate count of the number of vehicles in the turn movement queue. Otherwise, RHODES relies on the current turn proportion parameters in use to decide how many incoming vehicles will be assigned to the turn movements, which can vary throughout the day. Note that this is for both left- and right-turn movements, as shown in Figure A15. The PREDICT component of RHODES provides advanced notice of arriving vehicles to peer intersections and can also benefit from additional detection. In this case, placement of “far-side” passage detectors can be used to provide actual counts, rather than estimated counts, of departing vehicles heading toward a peer intersection. Locations with high vol- umes and highly variable turn proportions at the upstream peer intersections are good candidates for installation of far- side detectors because they are not affected by these fluctua- tions and will provide improved count accuracy for the down- stream peer intersection. Controller CPU Field-hardened CPU Adapt/AdaptEx RHODES PREDICT PREDICT Network Hub FIGURE A14 RHODES system architecture.

72 The performance of RHODES is highly dependent on the accuracy and quality of the detection system, but is not depen- dent on a particular type of detection technology. Therefore, proper maintenance and monitoring of the detection system is a requirement for any RHODES installation. To this end, future revisions of RHODES will incorporate algorithms to recognize detector failures so that an alarm can be set for notification. In addition, the extent of the failure upon RHODES will be assessed so that the system can either continue operating or be taken off line, as appropriate. SCATS The Sydney Coordinated Adaptive Traffic System (SCATS) (current version 6.7) is an Area Traffic Control (ATC) or Urban Traffic Control (UTC) system consisting of hardware, software, and a unique traffic control philosophy that operates in real time; adjusting signal timings in response to variations in traffic demand and system capacity as they occur. Rather than changing individual intersections in isolation, SCATS manages groups of intersections that are called “subsystems,” the basic unit of the system. Each subsystem will consist of a number of intersections, usually between one and ten. One of those intersections is des- ignated as the controlling or “critical” intersection. SCATS adapts and coordinates the intersections within each subsystem and is able to coordinate adjacent subsystems. This coordination aims to divide the traffic on major roads into “pla- toons” (groups of vehicles) and to allow just enough time for each platoon of vehicles to progress through the system while allowing the green time required for competing flows. This maximizes the network capacity for the benefit of all users. Adaptive Traffic Control Logic Strategic and Tactical Control In SCATS traffic control is affected at two levels, strategic and tactical. Strategic control is managed by the regional computers and is known as the Masterlink mode of operation. Using flow and occupancy data collected at the intersection from loop detec- tors in the road pavement the computers determine, on an area basis, the optimum cycle time, phase splits, and offsets to suit the prevailing traffic conditions as they occur. The strategic and tac- tical control methods operate together to provide a powerful but flexible operation. Strategic control provides overall system con- trol of cycle time, phase split, and offset. Tactical control provides significant local flexibility within the constraints of the strategic control parameters. FIGURE A15 RHODES detection requirements.

73 Tactical control is undertaken at the intersection by the local traffic signal controller (local controller) and meets the cyclic variation in demand. Tactical control primarily allows for green phases to be terminated early when the demand is low and for phases to be omitted entirely from the sequence if there is no demand. The local controller bases its tactical decisions on infor- mation from vehicle detector loops at the intersection, some of which may also be strategic detectors. Masterlink This is the real-time adaptive mode of operation. In Masterlink mode the regional computer determines the phase sequence, the maximum phase duration, and the duration of the pedestrian green signal displays. The local controller may terminate any phase under the control of the local vehicle actuation timers or skip phases without a demand, unless prohibited by instructions from the regional computer. The regional computer controls the phase transition points in the local controller, but subject to the local controller safety inter- val times being satisfied (e.g., minimum green, intergreen, and pedestrian clearance). On completion of the transition to a new phase, the local controller times the minimum green and mini- mum pedestrian green intervals, and then waits for a phase termi- nation command from the regional computer. On receipt of the command to move to the next phase, the local controller then independently times the necessary clearance intervals (e.g., inter- green) for the phase termination. Subsystems The subsystem is the basic unit of SCATS strate- gic control. One subsystem is configured for each critical inter- section, which are intersections that require accurate and vari- able phase splits owing to their operational characteristics. The intersections in a subsystem form a discrete group, which are always coordinated together. They share a common cycle time, with an inter-related phase split and offset. Phase splits for all other intersections in the subsystem are by definition non- critical, and are therefore either non-variable, or are allocated phase splits that are compatible with the splits in operation at the critical intersection. To provide coordination over larger groups of signals, subsystems can be configured to link with other subsystems to form larger systems, all operating on a com- mon cycle time as determined by the links at the time. These links may be permanent or may link and unlink adaptively to suit the prevailing traffic patterns. A SCATS regional computer has a maximum of 250 subsystems. Degree of Saturation SCATS strategic control bases its deci- sions on a measure of traffic demand known within SCATS as Degree of Saturation. In the SCATS context, Degree of Saturation is an empirical measure that is defined as the ratio of effectively used green time to the total available green time. Using loop detectors at the critical intersections, the local controller collects flow and occupancy data during the respective green phase. These data are sent to the regional computer, which calculates the DS. The DS is used as a basis for determining whether an increase or decrease in both cycle time and phase split is required. Phase Sequencing The signal cycle is divided into phases, and up to seven primary phases are available. Each primary phase may additionally have several optional sub-phases, subject to certain criteria. The primary phases (A, B, C, etc.) can be introduced in any defined sequence. Any phase can be skipped if there is no demand for that phase. The sub-phases have no direct SCATS specification or control; however, they are normally labeled with a numerical suffix (e.g., B1, B2). The sub-phases effectively extend the flexibility of signal control within the bounds of the primary phase (e.g., left overlap phases). Cycle Time Cycle time is increased or decreased to maintain the DS at a user-definable value (90% is typical) on the lane with the highest value. Cycle time can range between 20 s and 240 s and the actual lower and upper limits used are configurable on a sub- system basis. Cycle time can vary by up to 21 s per cycle; however, this upper limit is resisted unless a strong trend is recognized. Phase Split Phase splits are specified as a percentage of the cycle time or as a fixed time in seconds. For critical inter- sections, phase splits in percentage are varied by a small amount for each cycle in such a way as to maintain equal DS on com- peting approaches. The minimum split that can be allocated to a phase can be configured, but is limited by a value determined from the local controller’s minimum phase length. The current cycle time and the minimum requirements of the other phases limit the maximum split that can be allocated to a particular phase. Offset A number of offsets are configured for each intersection within each subsystem and also between the subsystems that can link together. Offsets are selected on the basis of traffic flow for each subsystem. The higher traffic flow links select the offsets that provide good progression for that link. Optimal offsets on the higher flow links tend to minimize the total number of stops in the system, reducing fuel consumption and increasing the capac- ity of the network overall. Other SCATS Operating Modes Besides the real-time adaptive traffic control mode (Masterlink), SCATS can run a variety of other “auxiliary” traffic control modes. Table A1 identifies these modes accompanied by short descriptions. Other important SCATS features are: • Hurry Call—the local controller invokes a pre-programmed mode usually associated with an emergency phase or local pre-emption such as a railway-level crossing phase. • Schedule—SCATS allows for system operation to be scheduled. Scheduling can operate with any mode of SCATS operation and can be used to switch between modes. Almost any function that can be executed manually can also be configured to occur at specified times on speci- fied days. • Special Routines—a range of special routines is available in SCATS, which allows the user to vary operations to suit special conditions. Special Routines generally provide an extension to the default adaptive behavior of the Master- link mode. It is features of this type that enable every detail of signal operation to be tailored to meet the oper- ational needs of each individual intersection. Hardware and Software Requirements The SCATS regional traffic control software has a maximum capacity of 250 intersections per region. With a maximum of 64 regions, the total capacity is 16,000 intersections.

74 Regional Computers The regional traffic control function uses standard PCs operat- ing under the Microsoft Windows® operating system. A range of intersection communication methods is provided and includes network (TCP/IP), serial, dial-out, and dial-in. Central Management Computer The Central Management Computer is a PC operating under the Microsoft Windows® operating system. Communications with regional computers and workstations is through TCP/IP. Software SCATS comes with the Central Management Computer soft- ware that allows other software packages including SCATS sup- port software to be used as part of the traffic management package. All SCATS software modules (i.e., regional, central, picture developer, alarming and monitoring, and simulation) use a PC platform and are compatible with the Microsoft Windows© operating system. SCATS provides the end user with a modern GUI with a full capability in monitoring and controlling SCATS and traffic signal functions. System Architecture and Communications Architecture SCATS has been designed in a modular configuration to suit the varying needs of small, medium, and large cities. In its simplest form, a single regional computer can control up to 250 intersections. Expansion of the system is achieved by installing additional regional computers on a TCP/IP network. SCATS also has the ability to internally manage several instances of the regional traffic control software on one physical com- puter. This provides flexibility in hardware configuration and for simulation use. All systems have a Central Management Computer to manage global data, access control, graphics data, and data backup. A typical SCATS system is shown in Figure A16. Communications SCATS 6 supports the following communication methods between a region and an intersection: • Serial—for example, dedicated cable, leased line. • Network (TCP/IP)—for example, dial IP or ADSL using TCP/IP. Operating Mode Description Flexilink Intersections are synchronized by local controllerís clock and are therefore coordinated without any connection. Signal timings and phasing sequence (stored at the local controller) are determined according to a time of day schedule. Local tactical control is still operational in this mode, unless prohibited by instruction from Flexilink. Police Off The lamp state at the local controller has been turned off. Police Red All lamps at the intersection have been turned to red. Police Manual The phases at the local controller are being manually introduced. Maintenance Mode This mode provides an indication to an operator that a technician is on site servicing the controller. Flashing Yellow The normal signal display is replaced by flashing yellow displays on all approaches, or flashing yellow and flashing red to competing approaches. TABLE A1 NONADAPTIVE SCATS OPERATING MODES FIGURE A16 Typical SCATS system architecture.

75 • Dial-out—using the SCATS DIDO unit. • Dial-in—using the SCATS DIDO unit. There are messages to and from each intersection controller every second. The minimum requirement is 300 bits per second (baud). The low speed rate required for SCATS communica- tions allows for a high degree of tolerance in the reliability of the communications network. In the event of regional computer failure, loss of communi- cations between the computer and any local controller, failure of all strategic detectors, or certain other local malfunctions, the affected intersections will revert to a user-defined fallback mode of operation. This may be either Flexilink (the usual fallback mode) or Isolated mode. If specified by the user, fallback at one intersection will also cause other intersections in the subsystem to operate their fallback mode and, optionally, intersections in adjacent linked subsystems. In this way, if Flexilink is specified as the fallback mode, a sig- nificant degree of coordination can be maintained between inter- sections affected by the failure during the period of fallback. Detection Requirements Tactical Detectors Tactical detectors are located at the stop-line to enable differen- tiation between the left-turn, straight-through (ahead), and right- turn movements at the intersection, both by knowledge of the lane usage in lanes of exclusive use, and by speed differential in a lane shared by two or more movements. Tactical detectors could be provided on all lanes of an approach (or movement) that would benefit from tactical control. At a minimum, tactical detectors could be provided for minor movements. Strategic Detectors Strategic detectors measure how effectively the green time is used by traffic that is controlled by SCATS. Correspondingly, SCATS uses strategic detectors to accurately determine the required green time for an intersection approach. Stop-line detectors installed for tactical control are used as strategic detec- tors, subject to certain criteria. Strategic detectors can be also located upstream from the stop-line, in which case the cal- culation of DS will be biased and detection of traffic queues becomes possible. At times, stop-line detectors at the upstream intersection are used to control a downstream intersection (it helps to identify queues). It is logical that approaches most requiring strategic detection are those least requiring tactical detection, and vice-versa. However, the installation of detectors at all intersection stop-lines regardless of fundamental need pro- vides a degree of redundancy and increased strategic control flexibility. The length of strategic detectors is critical for accurate cal- culation of DS. Detectors shorter than a critical length tend to perceive traffic as widely spaced in the conditions of slow mov- ing, closely spaced traffic. Conversely, if the detectors are too long they would not measure any spaces when traffic moves freely. Historical research has shown that a suitable detector length is 4.5 m, but acceptable lengths go as low as 3.5 m. All detectors (i.e., including tactical detectors) might be provided at a length suitable for strategic detectors so that strategic detectors can be selected from any of the detectors provided at any time. Special Features Route Preemption Route preemption allows a user to manage the sequential introduction of a green window or green wave through several intersections and is typically used for emergency vehicles or convoys. Time/Distance Display Figure A17 shows a time distance diagram for viewing signal coordination in real time. The relationship of coordinated phases and offsets is displayed dynamically in real time. SCOOT Adaptive Traffic Control Logic In SCOOT optimization of traffic control in the network is achieved using small, regular changes in signal timings designed to avoid major disturbance of traffic flow. Loop detectors are polled by the controller for occupancy every one-quarter second and typically transmitted once per second to the central com- puter, although the latest version of SCOOT relaxes this require- ment. Detector data are processed at central in 1-s intervals. SCOOT uses a hybrid measure of volume and occupancy [also known as Link Profile Units (LPUs)] to express traffic demand at detectors. Approximately 17 LPUs equal 1 vehicle, although this value is variable depending on traffic behavior. The LPUs are then processed through a platoon-dispersion model, similar to the one used by TRANSYT, to create Cyclic Flow Profiles (CFPs). Using CFPs together with the red/green signal status, SCOOT is able to model a traffic demand profile at the stop-line (the queue on the approach). SCOOT’s internal traffic model maintains a detailed, real-time image of the traffic network (similar to TRANSYT-7F or CORSIM). As such, a major part of a SCOOT system installation involves calibrating and validating the net- work model to match network field conditions. Overview of SCOOT operations is shown in Figure A18. SCOOT has three optimization procedures by which it adjusts signal timings—the Split Optimizer, the Offset Optimizer, and the Cycle Optimizer. Each optimizer estimates the effect of a small incremental change in signal timings on the overall performance of the region’s traffic signal network, which is measured through a performance index, a composite measure based on vehicle delays, and stops on each link. Calculated signal timings are trans- mitted to the local controller every second. The Split Optimizer works at every phase change by analyzing the current split timings to determine whether the split time is to be advanced, retarded, or remain the same to achieve the degree of saturation. Split changes are typically in increments of ±1 or 4 s by default, but include the ability for operator-configured val- ues to be used.

76 The Offset Optimizer works once per cycle for each inter- section. It operates by analyzing the current situation at each intersection using the CFP predicted for each of the links with upstream or downstream intersections. It then assesses whether the existing offset time is to be advanced, retarded, or remain the same. Offset changes are also in ±4-s intervals. The Cycle Optimization operates on a region basis once every 5 min, or every two and one-half minutes when cycle times are rapidly changing. It identifies the “critical intersection” within the region (any of the intersections in a system or sub-area can determine the system cycle length), and will attempt to adjust the cycle time to maintain this intersection with 90% link saturation FIGURE A17 Time/distance display in SCATS. FIGURE A18 Overview of SCOOT operations.

77 on each phase. If it calculates that a change in cycle time is required, it can increase or decrease the cycle time in 4-, 8-, or 16-s increments depending on the current cycle time value. SCOOT is not constrained by a “master” intersection in deter- mining system cycle lengths. Hardware and Software Requirements Standard Controller Firmware SCOOT runs with standard Siemens SEPAC firmware, the same firmware used for standard intersection control at 50,000 intersec- tions across the United States. Older SCOOT systems used an EPAC controller firmware upgrade for the existing controllers. SCOOT can also be installed with pre-programmed logic on new EPAC and 2070 controllers. SCOOT Software Platforms The kernel software at the heart of a SCOOT system is standard for all installations. The additional software that links the SCOOT kernel to on-street equipment and that also provides the user interface is supplier-specific. Traditionally, SCOOT kernel has been operating on Alpha DEC computers and Open VMS operating system. Recent ver- sions of SCOOT also operate on a PC platform with a Microsoft Windows operating system. The PC platform provides the fol- lowing benefits: • Use of standard PC components, • Reduced hardware and software costs, • Improved network efficiency, • Ease of use and training for new users, • A customized congestion management tool kit, and • Improved access to data management. System Architecture and Communications Figure A19 shows a typical SCOOT architecture. A SCOOT system can implement a centralized strategic traffic policy, reacting to variations in demand in real time. The centralized system also allows system-wide strategies to be employed. Examples of these strategies are: • Peak hour routes, • Keeping emergency and evacuation routes clear, • Traffic metering (gating) on the outskirts of congested areas, and • Central bus priority. Traditionally, SCOOT has been using dedicated (leased line, copper cable, fiber optic, or combinations) multi-drop transmis- sion lines to outstations. SCOOT requires second-by-second communications between the central computer and outstations. Typically, six to eight intersections can be served by 1200 baud rate. Recently, the PC version of SCOOT was enhanced to enable the use of modern communications technology used by ITS solutions. This approach absorbs inconsistencies and delays in data delivery with less impact on the system. This new approach reduces dependency on traditional leased-line communications techniques and opens up the potential to use a wide range of modern communications technologies previously unavailable to SCOOT systems. Detection Requirements SCOOT uses upstream detection to collect its traffic information. Upstream detectors are usually installed in the vicinity of the pre- Once per sec. Hub Controller 1 Controller n Modem Remote Diagnostics SCOOT/ASTRID/ INGRID Server ACTRA Server SCOOT Detector Local Detector SCOOT Detector Local Detector Once per min. Terminal Server Laser Report Printer Dot-Matrix Log Printer Comm. Servers Modem Dial-in Validation Roving Terminal Validation 10/100 Public Ethernet Private Ethernet Up to 16 drops per channel @ 9600 baud FIGURE A19 Typical SCOOT architecture.

78 vious upstream intersection to reduce communication costs. Ide- ally, SCOOT detection needs to be located at least 7 s of travel time upstream (further is acceptable and often better). Upstream detec- tion provides a view of the traffic approaching an intersection in a TRANSYT type “flow profile.” Utilization of the upstream detec- tors allows SCOOT to: • Be more sensitive to sudden changes in traffic conditions, • Be able to respond more quickly in congested conditions, • Calculate queue lengths more accurately, and • Base its changes on incoming “traffic flows,” rather than latent “traffic demand.” Special Features ASTRID and INGRID Data used by the SCOOT model in the optimization process such as stops, delays, flows, and congestion levels, are available to the user through the ASTRID (Automatic SCOOT Traffic Informa- tion Database) system, which automatically collects, stores, and processes traffic information for display and analysis. When a detector fails and link data cannot be collected in real time, his- torical link data from ASTRID can be used by the SCOOT opti- mizers to maintain a high level of system efficiency. The INGRID (INteGRated Incident Detection) system was developed to automatically detect traffic incidents in urban areas. The system uses information from SCOOT and the ASTRID database to compare current conditions with historic values. Information provided by INGRID includes time of inci- dent, duration, location, area affected, severity, and confidence level. Bus Priority Two approaches to bus priority are available with the SCOOT system: • Local-based priority, and • SCOOT-based priority (only for intersections under SCOOT). Local Priority Siemens ITS controllers provide up to six pre- emption (high-level) and six priority (low-level) routines. When the local equipment (the most common system is 3M’s Opti- com™) detects an approaching bus, it sends a request to the local controller to initiate the appropriate priority routine. This routine determines the current signal phasing, evaluates the direction of travel and whether the priority is for the main street or the minor street, and executes the preprogrammed response. SCOOT-Based Priority SCOOT is able to specially accom- modate buses within its normal optimization routines. Bus pri- ority may be provided by green extensions, stage recalls, or both. An extension is given when a detected bus could be served by an extension of the current green. A recall is implemented when a detected bus is expected to arrive at the stop-line at a red light (i.e., the signal is currently red or a maximum length exten- sion would not be sufficient to serve the bus in the current stage). In this case, the intersection cycles as quickly as possible to return to the bus stage. It can be noted that there is no guarantee of priority to buses at an intersection. With each split decision, SCOOT will still take into account the percent saturation of all approaches, and will still maintain the principle of small but frequent changes. The detection of a bus merely gives a higher priority to that stage. This is in contrast to a full over-riding priority system that is constrained only by maximum and minimum stage lengths. Buses may be detected by either static means (e.g., loop detec- tors or 3M Opticom) or by means of an automatic vehicle loca- tion system. Over-Saturated Conditions SCOOT has several methods with which to handle over-saturated conditions: • Congestion importance factors/congestion offset per link, • Congestion links with congestion importance factors, • Gating, and • Variable-Intersection Based Target Saturation for cycle time optimization. A congestion importance factor is specified for each link. It is used to influence split calculations in favor of the link when congestion is detected. Another factor, congestion offset, is a fixed offset, specified by the traffic engineer, to be used in con- gested conditions. Congestion weighting factor allows the engineer to specify the importance of achieving the congestion offset. Gating, or action at a distance, allows the restriction of the green times of the entry links to the congested area; or, exiting links downstream of a congested area may be granted more green time to allow traffic to clear. A cycle optimizer normally uses 90% as its target satura- tion level (80% when the “Trend Flag” is set, to give more rapid response). Intersection-based target saturation levels may be set by the traffic engineer, whereby a low threshold value will produce an early increase in cycle time and a high threshold value will allow an early drop in cycle time at the end of peak period. UTOPIA MIZAR’s Traffic Light Control and Priority System, UTOPIA, was developed during the 1980s in response to the need for a fully automated system able to increase the fluidity of traffic and transport, and to reduce travel times across a wide-area network. UTOPIA is installed and operates in numerous cities throughout Europe. The basic principle of UTOPIA is to perform a real-time optimization of the signal timings to minimize the total socio- economic cost of the traffic system. These costs are usually expressed as traffic congestion, vehicular emissions, and travel times both for private traffic and for public transit vehicles. Con- trol strategies are computed in real-time taking into account the measured traffic metrics at intersections as well as forecasted private traffic demand at both the intersection and network lev- els, and the predicted arrival times of the public transit vehicles at the intersections.

79 UTOPIA offers a full suite of traffic control strategies including: • Fully Adaptive • Time Based Plan Selection • Traffic Actuated Plan Selection • Traffic Responsive (micro-regulation). These various strategies can be applied simultaneously at dif- ferent zones within the same network. They can also be modi- fied independently at any time of the day. Fully Adaptive Control The highest performance of UTOPIA traffic control is achieved in the fully adaptive mode in which UTOPIA responds in real time to traffic conditions on the network. The system calculates the con- trol strategy using information sent every second from sensors located near each intersection. Traffic control is determined through optimization processes and by the application of the rolling horizon technique at both the central and local levels: • At the central level, the network control strategy is opti- mized over the next 30 to 60 min time horizon (depending on the size of the network controlled) and is updated every 5 min. Each strategy is effective for not more than 5 min, and is then replaced by a new strategy. • At the intersection level, signal timing optimization is per- formed on the time horizon of the next 120 s and is repeated every 3 s. The resulting optimal signal settings are actually in operation only for 3 s. Objective function, which is optimized at the intersection level, consists of terms related to the traffic observed on approaching links to the intersection and also those links to which can be applied one of the following two fundamental interaction principles: 1. A strong interaction principle that accounts for the delay at the downstream intersections experienced by vehicles leaving the intersection under consideration; or 2. A look-ahead principle that accounts for the traffic fore- cast during the entire optimization horizon (120 s) for all incoming links. Implementation of the strong interaction principle requires knowledge of the traffic light status at the downstream intersec- tions. On the other hand, implementation of the look-ahead principle requires knowledge of the traffic light status for the upstream intersections and the availability of traffic informa- tion for the incoming links of the upstream intersections. To achieve stability and robustness at the network level, inter- actions are defined between the local level and the central level. At the central level, the optimal network traffic control problem is developed based on the macroscopic traffic model of the network, and control strategies such as minimum, average, and maximum length of each stage, offsets, and weights for all the elements con- stituting the objective function optimized locally are defined for each intersection. The cost elements of the objective function optimized at the local level are: • Travel time of the vehicles on the incoming links, • Number of stopped vehicles on the incoming links, • Excess queuing on the incoming links (queues that exceed thresholds proportional to the link capacity), • Travel time of the vehicles on the outgoing links, and • Travel time of public transit vehicles. Cost elements are evaluated during the entire horizon taking into account existing signal timings and phasing constraints (e.g., minimum and maximum green times). UTOPIA allows for utilization of various weights for various links and priority rules. Figure A20 describes interaction between UTOPIA’s two funda- mental modules operational at both the local and central levels: the State Observer and the Controller. The distributed architecture of the system derives directly from the method adopted to decompose the area optimal control problem into a set of simpler and strongly interrelated sub- problems. Problem decomposition is performed following a topological rule: first, the area is subdivided into overlapping zones, where each zone is logically centered on an intersection and includes neighboring intersections as well. Then an optimal control problem is defined for each zone, which takes into account traffic data and traffic light control information related to the all the intersections within the zone. The solution of the zone control problem determines the traffic light control to be actuated at the central intersection only but, owing to the over- lap between neighboring zones, is strongly interrelated with the control at all surrounding intersections. Zone-by-zone control optimization is iterated frequently based on a rolling horizon technique to detect demand variations promptly and to react consequently. Because of the strong interaction, the effects of any demand variation in one zone are rapidly propagated to all the surrounding zones. This scheme allows UTOPIA to implement a fully adaptive optimal area con- trol. Also, the control scheme supports the physical organization of the system according to a hierarchical and decentralized archi- tecture, where the SPOT roadside unit performs the zone control functions at the intersection, whereas the central level deter- mines dynamically the criteria and the reference strategies that need to be considered during local optimization. Hardware and Software Requirements Fully compatible with 32-bit and 64-bit architecture, the UTOPIA server(s) provides high performance with minimal require- FIGURE A20 Interaction between modules in UTOPIA.

80 ments. Typical requirements for UTOPA servers are provided in Table A2. Requirements for Utopia Servers UTOPIA uses Browser Based Clients to provide high accessi- bility to the system without requiring any specific workstation configuration. Although essentially independent of the Operat- ing System, the UTOPIA web-based interface works best in common web browsers such as Internet Explorer 7 and Firefox 2. UTOPIA’s interface offers full multi-tasking capabilities and different privileges can be provided for users of different admin- istrative levels. UTOPIA can be interfaced with the new OMNIA platform to facilitate monitoring of the traffic network and ATCS oper- ations. Almost all of the UTOPIA’s user interface functional- ities are directly accessible from the OMNIA Common GUI. Specialized clients of the UTOPIA system need a specialized UTOPIA workstation (the MS Windows XP operating system is recommended). System Architecture UTOPIA has a two-level hierarchical and distributed architec- ture, which is shown in Figure A21. The higher level is responsi- ble for setting the network control strategies, whereas the lower level (SPOT—at local intersection controllers) implements signal timings according to the actual local traffic conditions con- strained by the network control strategy from the higher level. UTOPIA’s architecture is modular, which makes UTOPIA a sys- tem easy to extend and integrate with other ITS applications (e.g., public transport management). The distributed architecture of the system derives directly from the method adopted to decompose the area optimal control problem into a set of simpler and strongly interrelated sub-problems. SPOT SPOT is the software that performs local UTOPIA functions in the intersection controller’s cabinets. SPOT is installed as a sep- arate unit that communicates with intersection controllers. SPOT also exchanges information with: • Neighboring SPOT units to cooperate in the definition of the local control strategy and to implement dynamic coordina- tion suitable for both private traffic and transit priority. • Central system to receive commands, priority requests, and traffic control strategies, and to send traffic parame- ters, a locally actuated traffic control strategy, and diag- nostic information to the central system. UTOPIA Central Functions The UTOPIA central functionalities can be assigned to three major groups, as shown in Figure A22. In the Traffic Network Monitoring group (far right) traffic measures (volumes, speed, classification data, etc.) and parameters (clearance capacities, turning proportions, actuated signal plans, etc.) are gathered and stored in the central system archive together with their statistical profiles. Automatic incident detection and congestion warning Servers Applications Operating system Microsoft Windows Server 2003 Database engine Microsoft SQL server 2000/2005 Web Server Microsoft Internet Information Services (IIS) Map Server Autodesk MapGuide Application framework Visual C++ Microsoft .NET Framework 2.0 TABLE A2 REQUIREMENTS FOR UTOPIA SERVERS SPOT environment FIGURE A21 UTOPIA and SPOT interaction. FIGURE A22 Functional architecture of UTOPIA.

81 functions feed further DB files. All data are made available for on-line, off-line, and export system processes. In the System Diagnostics group (second from right) information on the oper- ational status is collected for all system components and made available to the operator through screen displays and special reports for monitoring and maintenance purposes. Automatic alarms are generated for abnormal situations. Finally, in the Traffic Control and Priority group (left) traffic control strate- gies are developed and delivered for implementation to the intersection level. Transit signal priority is handled in two ways: priority requests can be generated internally through the PT Locator functionality or received from an external fleet management system. In both cases arrival times of the prior- ity vehicles are forecasted and forwarded to the intersections. Also, a backup priority management function is implemented at the local level based on the continuous exchange of infor- mation between the SPOT units. Traffic data and control strate- gies are also exchanged with other mobility management systems through a gateway to allow for cooperative monitoring and con- trol of the area. Detector Requirements When UTOPIA runs fully adaptive control strategies, the traffic state estimation requires traffic detectors located on entry and exit lanes of the intersection approaches (shown in Figure A23): • Entry detectors are needed to measure incoming traffic platoons and model expected queues at stop-lines, and • Exit detectors are used to dynamically estimate parameters such as turning proportions and saturation flow rates. UTOPIA requires detectors only on the intersection approaches with significant traffic volumes and where traffic fluctuates sig- nificantly. One can note that in an urban grid environment exit detectors from upstream intersections can serve as entry detec- tors for the downstream intersections. UTOPIA usually uses queue detectors at the approaches where queues typically are critical. Any detection technology can be used providing that it reports two fundamental detection measures: traffic counts and occupancy time. Communications The communications network provides the communication links within UTOPIA architecture and between UTOPIA and external systems. The communications are based on a flexible WAN archi- tecture, which supports several different media such as fiber optic, dedicated telecommunication lines, VPN based on DSL connec- tions, and private copper cables; wireless technology; and various communication protocols (e.g., standard TCP/IP and proprietary serial protocol). Particularly for fully adaptive operations, UTOPIA requires a robust and reliable communications network between the local SPOT units and between the local level and the central system, with the minimal capacity of 9.6K bauds. Special Features Plan Selection Strategies These traffic control strategies are suitable for networks with pre- dictable TOD and DOW traffic patterns. Once a set of typical sig- nal timing plans is defined (based on the historic traffic data from detectors) and stored in the system library, it can be activated by any of these three methods: • Automatic pattern-matching plan selection—activation is automatically performed whenever a certain “traffic pat- tern” is recognized in the measured traffic data; • Time-based plan selection—activation is based on date, time, and type of day criteria; and • Manual mode—operator activates the signal timing plan manually. The signal timing plan is implemented at the intersection level by the SPOT software. SPOT switches between signal timing plans using a “smooth” transition technique (i.e., the green splits and off- sets are changed gradually to avoid discontinuity or jumps in the phase sequence). Also, if traffic control is executed through the plan selection strategies SPOT takes control of traffic signal prior- ity for public transit, emergency, and VIP vehicles. Traffic Light Priority Management UTOPIA is able to assign absolute, weighted, and selective prior- ity to buses and trams at signalized intersections. This function can also be extended to emergency and VIP vehicles. For public tran- sit vehicles, traffic signal priority is implemented through: • Functional integration with an automatic vehicle loca- tion/automated vehicle maintenance system, • Local detectors (active and passive), • Dedicated detectors managed by the UTOPIA PT Locator central functionality, and • A combination of these methods. In UTOPIA the priority requests are represented by forecasting the arrival time of the priority vehicles at the intersection. In gen- eral, the priority requests are prepared by the central level (auto- mated vehicle maintenance or PT Locator) and forwarded to the local level, where the SPOT control function handles properly. When local detection is implemented, SPOT also generates the priority requests. FIGURE A23 A common intersection detection layout in UTOPIA.

In all cases, the SPOT unit implements a distributed forecast function, which complements the central forecast functionality and consists of the local propagation of the arrival forecasts from SPOT to the downstream intersections along the priority vehicle route. Forecasts are promptly corrected by SPOT when priority vehicles are delayed at the traffic light. To determine the level of priority, “weights” are assigned to specific vehicles (e.g., according to the line, direction, or vehicle adherence to the schedule) locally or centrally. In UTOPIA, pub- lic transit priority is achieved within the intersection optimization process and not as a result of post-processing actions. Opti- mization is carried out every 3 s; therefore, the system can react quickly to any changes in the predicted arrival time. When the vehicle has safely passed the intersection, the priority request is “cleared” by the SPOT unit. In the definition of the intersection state, PT vehicles are con- sidered in the same way as private vehicles; they are represented by equivalent “vehicle platoons,” which appear as probability curves centred on the predicted arrival times. These curves become steeper as the vehicle approaches the intersection and the forecast variations decrease. UTOPIA begins to calculate the control strategy (stage duration, offset, etc.) when the public tran- sit vehicle is approaching the intersection. In this way, it ensures that the traffic signal phases are managed in a way that minimizes the impact on other vehicles. The SPOT control function is also responsible for recovering any disturbances to the local optimization strategy resulting from the priority request. For adaptive mode, the recovery action is based on a fine optimization of the waiting times on all the traffic movements. In the plan selection mode, the system is “re-hooked” gradually to the selected plan to compensate for the effects of the priority provision. The system can provide priority to emergency and VIP vehicles as long as these are equipped with on-board transmitters so that they can be detected. The priority in this case is managed at the local level and is based on vehicle–detector communication. 82