A Real-Time Simulation Environment for Evaluating Traffic Signal Systems1 2
3
Darcy Bullock and Alison Catarella
Keywords Traffic Signal System, Simulation, CORSIM, Traffic Controller, System Evaluation
Abstract Features and operating modes of the current generation of actuated controllers have evolved to the point where there is a significant difference between the configuration parameters associated with an actuated controller and the information obtained from traffic signal system optimization packages such as Transyt 7F and Passer II. As a result, Transyt 7F and Passer II give no guidance on the impact or sensitivity of many actuated control parameters on a traffic signal system’s performance. To evaluate the impact and sensitivity of these actuated controller parameters on system performance, a microscopic simulation program such as CORSIM can be used to obtain quantitative measurements (for example travel time or delay) for several different alternative controller parameter values. However, the CORSIM environment has a limited pre-programmed actuated controller model that can not simulate every feature provided by every controller vendor. Consequently, it is impossible to use the standard CORSIM package to evaluate the impact particular features, such as cycle transition algorithms or return from preemption algorithms, have on overall system performance. To address this need, this paper describes an enhancement made to the CORSIM package that allows physical controllers to be connected to CORSIM. In this arrangement, CORSIM provides the microscopic simulation and tabulation of measures of effectiveness (MOEs).
However, instead of
CORSIM emulating controller features, CORSIM sends detector information to the physical controllers and reads back phase indications. This type of simulation is often referred to as hardware-in-the-loop. Since CORSIM tabulates performance MOEs, qualitative before/after measurements can be obtained for any hardware conforming to the NEMA TS1 electrical standard for phase outputs and detector inputs. To validate the performance of this hardware-in-the-loop approach, this paper presents an evaluation showing there is no evidence of a significant statistical difference in MOEs between the internal control algorithm and the hardware-in-the-loop control algorithm for both a fixed time and actuated controller.
1
1998 Annual Meeting Preprint # 980837 Associate Professor, School of Civil Engineering, Purdue University, West Lafayette, IN, 47907; 765/494-2204; FAX 765/496-1105;
[email protected]. 3 Student, Civil and Environmental Engineering Department, Louisiana State University, Baton Rouge, LA 70803. 2
Bullock and Catarella
1
November 20, 1997
Introduction The traffic signal system community is lacking two major tools necessary for planning and operating state of the art traffic signal systems.
First, there needs to be a rational
procedure for quantifying the benefits associated with various traffic signal system improvements. Often times during the planning stage of a new signal system upgrade, many of the anticipated benefits are based upon percentage reduction in travel time, emissions, or delays observed in other systems [FHWA 1995]. However, rarely are the systems so similar that these percentage reduction in measures of effectiveness (MOEs) are transferable. Furthermore, if a rational engineering economic based decision model is followed, system costs and anticipated benefits should be tabulated to compute the net present value of (benefitscosts) for a variety of alternatives such as 1) status quo, 2) coordinated fixed time system, 3) coordinated actuated control system, 4) proprietary closed loop system, and perhaps 5) a new adaptive control model. Life cycle system costs are relatively simple to estimate. However, estimating the benefits can be quite difficult. Packages such as CORSIM permit engineers to deterministically quantify benefits associated with cases 1, 2, and 3 for a particular study area. However, due to the large number of traffic signal system vendors, it is impossible to imagine CORSIM software developers ever implementing all the features necessary to model all the possible systems associated with cases 4 and 5 [Seymour 96]. Therefore, there is a need for a systematic procedure to evaluate the benefits of control algorithms that are not available in the CORSIM environment. Second, there needs to be a mechanism for tuning a new signal system off line before it is deployed in the field. Modern traffic signal controllers have hundreds of different parameters that can be adjusted to improve system performance for a particular deployment. However, since traffic demand is stochastic and varies from day to day, there is no way to deterministically evaluate the performance gains (or losses) associated with parameter changes.
Furthermore, the political impact of making a mistake during an “on-line” tuning
process leads to a situation where most modern closed loop systems are deployed without many of their sophisticated traffic responsive features operational.
This is because traffic
engineers can not be certain how many of the adaptive features of closed loop systems will perform and are unwilling to take the risk of attempting to make them functional. Based upon these observations, it is clear that a systematic evaluation procedure must be developed for evaluating and tuning traffic signal controllers before they are deployed on the street. It is currently possible to set up a complete closed loop system in a laboratory (or a signal shop) environment with switch boxes connected to each controller (Figure 1). This type
Bullock and Catarella
2
November 20, 1997
of test environment would allow engineers to verify that desired controller features are operating as expected. However, to actually simulate all the discrete detector actuations that would be associated with a small three intersection arterial, like the one shown in Figure 1, would be impossible for even small volumes, much less corridors with more signals or high volumes. Furthermore, it would be impossible to quantify the performance of such a simulation in terms of vehicle travel time or delay. Alternatively, if we could set up a testing environment where a computer operated the switch boxes and kept track of vehicle movements throughout a system, quantitative performance measurements could be obtained. The following section describes such an environment.
Simulation Environment The CORSIM package is a microscopic simulation environment that contains both the algorithms to track vehicles through a prescribed highway network and the algorithms necessary for implementing a coordinated actuated signal system.
In an ideal world, the
CORSIM package would have all algorithms and parameters that are used by all the different traffic controller vendors. However, the reality is that CORSIM models only the most common features available in actuated control systems. The spirit of specifications such as NEMA TS1 and TS2 is that the detector inputs and phase outputs are standardized and vendors compete by adding software features [NEMA, 1992]. This has resulted in numerous control parameters and algorithms being available to the traffic engineer that can not be modeled in CORSIM. Since software development is extremely costly, it is unlikely CORSIM software engineers will ever reach the point where CORSIM has the capability of simulating all these features. In control systems engineering terminology both the controller (CORSIM signal algorithms) and the plant (CORSIM microscopic simulation environment) are running on the same computer. The interface (phase indications and detector actuations) between the plant and the controller correspond exactly to the interface between a NEMA controller (plugs A, B, and C) and the cabinet, therefore it would be convenient to unplug the CORSIM signal control algorithms and replace them with the control algorithms in the controller. Since the CORSIM package is designed to run in a personal computer environment and the various traffic signal controllers run on a variety of single board computers, the most convenient standard mechanism for interfacing the CORSIM simulation environment to an external controller is to use the 24 volt logic interface specified in NEMA TS-2 (Sections 3.3.5.1.3 and 3.3.5.1.4) [NEMA, 1992]. This type of interface would require CORSIM to send an electrical pulse to the corresponding controller detector input every time a vehicle crosses a vehicle detector (assuming pulse mode) and to monitor the phase indication outputs of the controller to
Bullock and Catarella
3
November 20, 1997
determine which movements are permitted to move during each simulation interval. CORSIM is set up to run in one second time steps, therefore the CORSIM environment must be clocked to run at exactly one Hz. Replacing the CORSIM controller with a physical NEMA controller is referred to as hardware-in-the-loop testing. This concept of hardware-in-the-loop testing is fairly common in the petro-chemical control industry. However, in order to provide this capability for traffic signal systems it is necessary to develop an I/O subsystem that can easily interface to CORSIM. Since it is desirable to have a portable and scaleable system, a serial based input/output (I/O) subsystem was selected because it could be run on an ordinary notebook computer with an RS232 port without having to plug in specialized interface boards. The schematic shown in Figure 2 shows the basic configuration of the hardware-in-the-loop simulation. On the left side of Figure 2 are three NEMA controllers corresponding to three intersections.
Each of these
controllers are networked together and connected back to a notebook computer running the vendor’s closed loop signal system software.
In the middle of the page (Figure 2), the
simulation interface network is shown. This simulation interface network has the I/O modules that allow CORSIM to send the detector information out to the individual controllers and read back phase indications. The notebook below the I/O modules is the computer responsible for running the CORSIM network simulation.
The CORSIM environment interfaces to the
simulation interface network by a simple RS-232 connection. The first simulation interface box converts that RS-232 signal into an RS-422 signal so that several simulation interface boxes can be multidropped from the same serial link.
Each of the simulation interface boxes is
assigned a unique numeric identifier corresponding to the number assigned to the intersection node in CORSIM.
A photograph of a NEMA controller connected to a single simulation
interface box is shown in Figure 3. Using the arrangement shown in Figure 2, CORSIM can be used to model most any signalized arterial and/or urban grid. Instead of using the internal control algorithms, CORSIM sends detector actuations out to the NEMA controllers every one second and reads back the corresponding phase indications. The existing microscopic simulation continues to function unchanged. This allows engineers to collect and tabulate the various MOEs that CORSIM produces. To provide this hardware-in-the-loop interface to CORSIM, a windows dynamic link library (DLL) was created that will run with Release 4 (June 1997) of CORSIM. In release 4, a toggle on one of the CORSIM TSIS menus allow the user to turn off CORSIM’s internal control algorithm and make a function call to the DLL every one second. As a result, the software for the simulation environment shown in Figure 2 is the standard CORSIM environment with one additional DLL that provides the interface to the simulation interface modules. The simulation Bullock and Catarella
4
November 20, 1997
interface modules were fabricated using OPTO 22 SNAP I/O modules. The cost of the I/O modules, connectors and cables used to interface with each controller is approximately $2000 about the cost of a traditional switch based test box.
Simulation Experiments Once the simulation interface hardware (shown on right side of Figure 2) was constructed, it was essential to determine if the serial communication introduced any significant systematic errors in the simulation. Since there was a small delay between when the detector states were sent out to the actuated controller and when the signal states were read back into the simulation program, it was necessary to develop a series of simulation experiments to determine if this delay introduced systematic errors. Two different simulation scenarios were selected - fixed time control and actuated control. The fixed time control simulation allowed us to verify that there were not any time shift errors introduced. To run the fixed time experiments, the actuated controller was configured with the detectors set to operate under MAX 2 with the detectors in recall. The MAX 2 timings used for the experiment are shown in Table 1. The design of the actuated control simulation experiments was slightly more complex. Since there are endless variations in the features that vendors provide in actuated controllers, a decision had to be made regarding which features would be used in the comparison simulations. We elected to conduct the comparison using only the most basic actuated control features - extension of the green up to the MAX 1 value. The values of the various controller parameters are shown in Table 1. Since the coordination features of an actuated controller (force off and yield points) essentially constrain a controller to behave similar to a fixed time system, none of these coordination features were used because they might mask any time delay problems. Instead, we allowed the actuated controller to run free - only constrained by the MAX 1 times shown in Table 1. Both the fixed time control simulation and the actuated control simulation were run for an intersection loosely modeled on the intersection of Airline Highway and Greenwell Street in Baton Rouge, Louisiana. This intersection was selected because it contains left and right turn pockets and utilizes all eight phases. The geometrics, timing, and volume information was readily available from recent plans. A schematic of the geometric layout of the intersection including the placement of presence detectors is shown in Figure 4. Demand volumes for the intersection are also shown in Figure 4. After the models were constructed, five simulation runs were made for each of the following scenarios: 1) CORSIM using a simulated internal fixed time controller; 2) CORSIM using an external controller operating as a fixed time controller; 3) CORISM using a simulated
Bullock and Catarella
5
November 20, 1997
internal actuated controller; and 4) CORSIM using an external controller operating as an actuated controller. The five simulation runs for each scenario were generated using different random number seeds. The MOEs tabulated for this evaluation were flow (vph) and delay (vehmin). Since CORSIM generates the vehicles, the flow rates were expected to have very little variation, but their comparison provided a check on the process in case a random number seed caused an unusual set of volumes. Delay values provided a more robust comparison between the software simulation and the hardware-in-the-loop simulation.
MOEs comparing the
simulated internal CORSIM fixed time control algorithm (Case 1) with the external controller operating as a fixed time controller (Case 2) are tabulated in Table 2. MOEs comparing the simulated internal CORSIM actuated control algorithm (Case 3) with the external controller operating as an actuated controller (Case 4) are tabulated in Table 3. The values in both Table 2 and Table 3 are averages obtained from five simulation runs.
Simulation Results To compare the performance of the CORSIM internal control algorithm with the hardware-in-the-loop simulation, the standard deviation of the difference in the means [May 90] was calculated using:
s12 s 22 + n1 n2
sˆ =
where s1 is the standard deviation of MOEs for five simulation runs using CORSIM’s internal control algorithms and s2 is the standard deviation of MOEs for five hardware-in-the-loop simulation runs. To determine if there was statistical evidence to suggest the means of the MOEs were different, the following test statistic was calculated:
z=
µ1 − µ 2 sˆ
where µ1 and µ2 are the mean values for the CORSIM simulated internal control algorithm (left two columns of Tables 2 and 3) and the hardware-in-the-loop MOEs (right two columns in Tables 2 and 3), respectively. The test statistics for the various observed MOEs are tabulated in Table 4. The maximum test statistics for the fixed time control algorithm evaluation was 1.32. The maximum test statistic for the actuated control algorithm evaluation was -1.12. The null hypothesis is
H0 : u1 = u2 Assuming a two tail 95% confidence interval and a normal distribution, the null hypothesis can not be rejected for the fixed time or the actuated control algorithm [Canavos 84].
Bullock and Catarella
6
November 20, 1997
Conclusion and Future Work The statistics in Table 4 suggest that for fixed time and actuated control the software simulation and the hardware-in-the-loop simulation are not statistically different. This indicates that the hardware-in-the-loop simulation environment does not introduce any statistically significant differences in the average MOEs tabulated in Tables 2 and 3. Based upon these results, we believe hardware-in-the-loop simulation can be used to reliably evaluate the performance gains (or losses) associated with special features of the various traffic controllers. Future work will use the hardware-in-the-loop simulation environment to compare the performance of vendor specific algorithms, for example, the effectiveness of different cycle transition algorithms.
In addition, this type of hardware-in-the-loop simulation will permit
controlled and reproducible experiments comparing, for example, a new RT-TRAC algorithm with a commercially available closed loop system. Based upon the MOEs obtained from the experiments, dollar values can be assigned to the improved travel time, delay or emission figures and a formal engineering economic based selection process can be followed.
Acknowledgments The work documented in this paper was supported by DTFH61-95-C-00049 subcontract P60972 from Kaman Sciences Corporation. The views expressed by the authors do not necessarily reflect the views or policies of the sponsor.
References Canavos, G.C., “Applied Probability and Statistical Methods,” Little, Brown, and Company, 1984. Federal Highway Administration, “Assessment of ITS Benefits Early Results,” August 1995. Federal Highway Administration, ”CORSIM User Manual,” November 1996. May, A.D., “Traffic Flow Fundamentals,” Prentice Hall, 1990. National Electrical Manufacturers Association, Washington D.C., “NEMA Standards Publication No. TS 2 Traffic Controller Assemblies,” 1992. Robert, G. et. al, “Traffic Control Systems Handbook,” FHWA-SA-95-032, February 1996. Seymour, Edward J. “Development of A Multi-Vendor Environment for Traffic Controllers,” Texas Transportation Institute, FHWA/TX-97/1389-1F, November 1996.
Bullock and Catarella
7
November 20, 1997
Figures Switch Box Testers
Real World Model
RS-232 from Closed Loop Software to System Master
Closed Loop Communication Interconnect Cable
Closed Loop Network
Closed Loop Management Software
Figure 1: Current method of evaluating corridor timing plans.
Bullock and Catarella
8
November 20, 1997
Simulation Interface Network
Real World Model
RS-232 from CORSIM to Simulation Interface Network
RS-232 from Closed Loop Software to System Master
RS-422 Simulation Interface Network
Closed Loop Communication Interconnect Cable
Closed Loop Network
Closed Loop Management Software
CORSIM Network Simulation
Figure 2: Proposed method for evaluating corridor timing plans.
Bullock and Catarella
9
November 20, 1997
Figure 3: Photograph of controller connected to computer simulation interface box.
575 6
37
$LUOLQH +Z\
*UHHQZHOO 6W
54 54 42
23 64 20
48
62 580
Figure 4: Geometric layout and demand volumes (vph) for modeled intersection.
Bullock and Catarella
10
November 20, 1997
Tables
PHASE MIN GREEN GAP, EXT. MAX 1 GREEN MAX 2 GREEN YELLOW RED
1 3 2.0 30 12 5.0 2.0
2 15 2.0 99 41 5.0 2.0
3 3 2.0 30 6 5.0 2.0
INTERVAL TIMES 4 5 5 3 2.0 2.0 40 30 27 10 5.0 5.0 2.0 2.0
6 15 2.0 99 43 5.0 2.0
7 3 2.0 30 25 5.0 2.0
8 5 2.0 40 8 5.0 2.0
Table 1: Phase table entries used by control algorithms.
NB Approach
SB Approach
EB Approach
WB Approach
Left Through Right Left Through Right Left Through Right Left Through Right
CORSIM Simulated Controller Delay Flow (veh-min) (vph) 12.48 18.2 87.17 214.2 2.13 20.2 11.34 14.6 88.02 207.4 0.42 3.2 5.76 8.2 18.28 22.6 1.69 7.4 11.82 20.6 9.96 18.8 4.14 15.2
External NEMA Controller Delay Flow (veh-min) (vph) 13.25 20.8 87.82 212.8 1.85 19.4 10.32 14.6 89.20 207.8 0.40 3.2 6.64 8 19.47 21.8 2.41 8.4 10.68 19.4 9.41 18.8 3.35 16.4
Table 2: MOE mean values for CORSIM algorithm vs. hardware implemented fixed time control algorithm.
Bullock and Catarella
11
November 20, 1997
NB Approach
SB Approach
EB Approach
WB Approach
Left Through Right Left Through Right Left Through Right Left Through Right
CORSIM Simulated Controller Delay Flow (veh-min) (vph) 7.82 18.4 42.92 214 2.27 16.8 5.62 12.8 46.52 211.8 0.44 3.2 3.16 8.0 8.52 22.2 1.11 9.4 9.56 20.2 5.81 17.8 2.30 16.4
External NEMA Controller Delay Flow (veh-min) (vph) 8.23 18.2 45.25 214.2 2.15 21.8 6.40 12.6 50.52 213.4 0.35 3 4.22 8 8.89 21.8 1.33 9.6 10.18 20.6 5.67 17.6 2.29 15.8
Table 3: MOE mean values for CORSIM algorithm vs. hardware implemented actuated control algorithm.
NB Approach
SB Approach
EB Approach
WB Approach
Left Through Right Left Through Right Left Through Right Left Through Right
Test Statistic Fixed Time Control Actuated Control Delay Flow Delay Flow -0.29 -0.82 -0.30 0.07 -0.22 0.28 -0.65 -0.03 1.01 0.30 0.23 -1.08 0.43 0.00 -0.72 0.14 -0.33 -0.18 -1.11 -0.96 0.09 0.00 0.45 0.14 -0.45 0.12 -1.12 0.00 -0.69 0.57 -0.78 0.35 -1.08 -0.64 -0.93 -0.11 0.47 0.40 -0.85 -0.18 0.26 0.00 0.12 0.10 1.32 -0.65 0.04 0.40
Table 4: Test statistics comparing MOE mean values for both fixed time and actuated control.
Bullock and Catarella
12
November 20, 1997
