summary introduction

7 downloads 0 Views 49KB Size Report
easily gather, access and manipulate data through a graphical user interface. ... surveillance, freeway control, incident detection and management into one ...
DEVELOPMENT AND IMPLEMENTATION OF A VIRTUAL TRAFFIC MANAGEMENT CENTER

John Hourdakis

Panos G. Michalopoulos

and

Department of Civil Engineering University of Minnesota 500 Pillsbury Dr. SE Minneapolis, MN 55455 Phone: (612) 625-8832, Fax: (612) 626-7750 Email: [email protected]

Department of Civil Engineering University of Minnesota 500 Pillsbury Dr. SE Minneapolis, MN 55455 Phone: (612) 625-1509 Fax: (612) 626-7750 Email: [email protected]

SUMMARY Realizing that it is timely to integrate the best possible combination of technology and architecture currently available into the next generation Traffic Management Center the need for a testing and evaluation facility became evident. This paper presents the development and implementation of a Traffic Management Laboratory (TRAMLAB). The basic idea behind TRAMLAB is to emulate a typical TMC traffic control room and implement, integrate and evaluate existing or new concepts of its operations, in a virtual environment prior to actual deployment. TRAMLAB effectively combines the power of simulation with the facility to easily gather, access and manipulate data through a graphical user interface. In this paper the current state of TRAMLAB along with results from its first implementation in a section of the Twin Cities freeway network are presented.

INTRODUCTION In spite of recent progress in traffic management, existing traffic control rooms are often not taking full advantage of advances in ITS technology. Although various features have been added over the years to improve operations, they have not been integrated and incorporated in a fashion consistent with the ITS architecture. Furthermore, the methodologies adopted for performing the various functions such as surveillance, ramp control, incident detection and management, etc. are not necessarily using state of the art technology and may not be the best for a particular Traffic Management Center (TMC). New facilities are adapting to the National ITS Architecture but in terms of control room operations, they have not deviated from earlier practice. Realizing that it is timely to integrate the best possible combination of technology and architecture currently available, the Minnesota Department of Transportation (MnDOT) decided to evaluate and improve the operations of the Twin Cities Traffic Management Center, deployed in 1972. This required a tool for offline testing of desired alternatives in a user specified and controllable environment that minimizes the decision making time and cost. Such experimentation and analysis reduces the risk of failure involved in the implementation of new ideas, policies and procedures. Furthermore, it provides reasonable confidence that the selected combination of technology and management philosophy will work efficiently when integrated and deployed into the traffic control room of the TMC.

1

With this in mind, the concept of a TRAffic Management LABoratory (TRAMLAB) was developed and implemented. The basic idea behind TRAMLAB is to emulate a typical TMC traffic control room and implement, integrate and evaluate existing or new concepts of its operations, in a virtual environment prior to actual deployment. TRAMLAB effectively combines the power of simulation with the facility to easily gather, access and manipulate data through a graphical user interface. It also combines various functions such as surveillance, freeway control, incident detection and management into one integrated system and allows simple replacement of each function with a new one without recoding the entire system. This allows the user to quickly and efficiently implement, test, and evaluate any combination of methodologies, control policies and management philosophies in an integrated fashion. It also permits on the fly changes of the operator’s user interface as well as progressive improvements or modifications. The initial phase of the development of TRAMLAB completed the integration of surveillance as well as incident detection techniques. In this paper the current status of TRAMLAB development is presented that includes a fully operational ramp and Variable Message Sign (VMS) control module, integration of simulation capabilities and the support of improved user interfaces.

ARCHITECTURE TRAMLAB is a combination of hardware and software components all operating in a special section of the University of Minnesota’s ITS laboratory that closely resembles the traffic control room of a generic TMC. The purpose of this design is to create a virtual TMC were engineers develop and test, under simulated conditions, new traffic management concepts and traffic operators receive their training. The hardware components currently integrated in TRAMLAB are: • • • •

A microwave connection with the Twin Cities TMC providing real time video. A Video wall able to simultaneously display real time video from up to 16 cameras in the field. A network connection with the TMC’s Data Distribution Server (DDS) that provides real time volume and occupancy information from all the 3000+ loop detectors in the field. Two operator workstations each equipped with a personal TV monitor, VCR, and a PC running the TRAMLAB software.

The software components operating in the virtual traffic management center are the following: • • • • •

The TRAMLAB graphical user interface and expert system design environment. A Microscopic traffic simulator. An external Traffic Control module connected with the simulator. A Traffic surveillance module that allows total control over the Video equipment. An Automated Incident Detection (AID) module employing four established incident detection algorithms.

The focal point of the whole design is the TRAMLAB graphical user interface. From the TRAMLAB GUI the operator has full control of all hardware components mentioned earlier

2

and can access any kind of real-time or historical information available in the system. As described in an earlier paper [1] TRAMLAB was originally designed as a prototype system for traffic management; it is the addition of traffic simulation that allowed the creation of an environment serving as a virtual traffic management center. When the GUI is connected with the simulator all external data inputs are replaced with outputs from the simulation. In this way real life is replaced by a fully controllable and customized scenario specially designed to test the various components of the system especially under extreme conditions and incidents. In addition, with the introduction of simulation, the human operators controlling the system can alter their actions in different replications of the same scenario to evaluate the effectiveness of such actions in short time, without risk, and with minimal cost. In the remainder of this section the newly developed modules of TRAMLAB are described. A Diagram of TRAMALB can be found on Figure 1. TRAMLAB GUI Station 1 TRAMLAB Main Module [AID, Surveillance, Traffic Control, Database]

Simulation Module [CPI, Ramp Metering]

TRAMLAB GUI Station 2

Figure 1. TRAMLAB Workstation Diagram

MAIN CONTROL MODULE AND USER INTERFACE Typical TMCs perform a multitude of functions, including local communication handling, database creation and maintenance, and real-time data collection and analysis. However, the components to perform these functions are usually built independently and lack integration. In TRAMLAB real-time traffic management functions are integrated along with training and research capabilities while the operation of the system is not interrupted during modifications. TRAMLAB is developed under the G2 expert system shell provided by the GENSYM Corporation. G2 was selected over other alternative development environments because our objective was rapid prototype building and testing rather than final product development. This allows users to test new ideas and system components, and develop new user interfaces quickly and efficiently in order to prove concept. For example, the user can try different combinations of system components, such as AID algorithms, ramp control strategies, simulators, etc. TRAMLAB is an Object Oriented application. Its object types include physical entities such us detectors, ramp meters, and VMS and conceptual entities such us freeway sections, exit and entrance ramps. Each object encapsulates all the available information. This information can be static i.e. location of a detector, or dynamic i.e. volume over the last 30 sec. TRAMLAB is an Expert System. Its event-driven operation is based on rules and procedures. With the use of Natural Language programming and a powerful inference engine the user

3

needs only to describe the task to be accomplished and the system will collect and update all necessary objects. The system obtains its data in several ways. These can include sensor input, user input, the inference engine, a simulator, and external processes like an ATMS. TRAMLAB is intended for demonstrating new ITS technologies, to test new freeway management functions, and to create a training platform for TMC operators. The flexibility of the system in terms of visualization and the natural language programming interface allow untrained users to easily transform their ideas into reality. Systems created under more traditional development platforms suffer from a long turnaround between design and implementation.

SIMULATION MODULE In the simulation module the well-known microscopic simulator AIMSUN2 [2] is replacing the real life field inputs and outputs of TRAMLAB. AIMSUN2 (Advanced Interactive Microscopic Simulator for Urban and Non-Urban Networks) is a software tool able to reproduce the real traffic conditions of any traffic network on a computer. AIMSUN2 follows a microscopic simulation approach. This means that the behavior of every single vehicle in the network is continuously modeled throughout the simulation period, using several driver behavior models (car following, lane changing, gap acceptance). AIMSUN2 can deal with different traffic networks: urban networks, freeways, freeway corridors, ring roads, arterial and any combination of them. Different types of traffic control may be modeled: traffic signals, junctions without traffic signals (give way or stop signs) and ramp metering. Vehicle behavior models are a function of several parameters that allow modeling of different types of vehicles: cars, buses, trucks, etc. They can be classified into groups, and reserved lanes for given groups can also be taken into account. Due to the detailed modeling of each vehicle in the network, AIMSUN2 can simulate any kind of traffic detector's measure: counts, occupancy, speed, etc. AIMSUN2 has a user-friendly interface through which the user can define the simulation experiment. It also provides a picture of the network and an animated representation of the vehicles in it. The user has an overview of what is happening in the network that aids performance analysis. Through the interface, the user may access any information in the model and define traffic incidents before or during the simulation run. A list of incidents may be stored for use in subsequent simulation runs. The Simulation Module communicates with the rest of the system through the Control Plan Interface (CPI) located in the Traffic Control module.

TRAFFIC CONTROL MODULE The Traffic Control Module of TRAMLAB, in its current state, integrates in one environment an Adaptive Ramp Control algorithm, a user interface for automated and manual VMS control, and all the necessary functions to allow the operator to override any system decision. Currently in this module the Minnesota adaptive ramp-metering algorithm has been implemented. Also a VMS control user interface has been created were the operator is provided with a predetermined library of messages were each of these messages have a predefined, in the simulator, effect on the traffic. The communication between the traffic control module and the rest of the system is assisted by the Control Plan Interface (CPI) [3,4]. The CPI was developed as an interface to integrate AIMSUN2 with any external user defined ramp control logic. It facilitates the exchange of information between the simulator and an external control scheme. This is especially needed for simulating adaptive ramp control strategies that use real time traffic measurements to

4

determine current metering rates. Such measurements might be volume, occupancy, speed on the mainline as well as queue lengths on the ramps. The simulator provides the necessary measurements, which the CPI transfers to the external control logic, in this case the TRAMLAB traffic control module. In its turn, the control logic calculates the new rates and transfers them to the simulator through the CPI. In general, most of the simulators have been designed to include one or more known ramp control schemes. This allows the user to compare the available schemes within a single simulator, but it doesn’t allow comparison with other non-supported schemes. With the CPI, the user has the capability of easily programming any control logic without having to change the core of the simulator. AIMSUN2 by design is capable of communicating with an external application. The CPI enhances this ability by grouping the necessary information specifically needed for ramp control schemes and by adding new functions it allows easier access to the simulator. This makes the job of the end user easier because he has more tools available to accomplish the integration of his control logic with the simulator. Specifically, in the CPI the notion of detector stations was added, as most of the current ramp control strategies require measurements over all lanes of the mainline instead of lane by lane. Additionally, the user is able to define the collection rate of measurements that can now be different from the one specified in the simulator. For example, the simulator may collect lane-by-lane detector data every 30 seconds but the user’s ramp control logic could request and receive 5-minute detector station data. With the original external interface the user’s logic had to be designed specifically for the network under consideration. With the CPI the user may access information at run-time about the road geometry, traffic detection and control devices as well as their mode of operation. This allows the user to design his logic in a more generic way and be able to use it on a variety of different networks. Finally, the implementation allows for customized output to be saved including information specific to the operation, effectiveness and general performance of the control logic.

COMMUNICATION MODULE The most difficult part in the integration of the simulator with the rest of the system was the creation of an efficient communication module. Both the TRAMLAB main module and the simulator are applications that can drain system resources depending on the size of the traffic network implemented. Early in the development it became evident that these two applications will not function in real time if they reside in the same computer. To deal with this reality, the communication module was designed to allow exchange of information between these two modules even if they operate in different computers, as long as these computers are connected to the Internet. The flow of information through the communication module although not by nature linear can be described as follows: On every simulation step the CPI decides if the detector measurements have been accumulated over the user-defined period i.e. 30sec. If this is true then these measurements are transmitted to the communication module, which in turn alerts the main module of the availability of new measurements. The main module uploads the measurements while at the same time transmits the new ramp rates and/or VMS activation. When these data transfers are all completed then the communication module gives the OK to both the simulation module and the main module to proceed with the rest of their tasks. To avoid misunderstanding it is important to note that the detector measurements can have a different update period than the ramp rates, both user defined, while user ramp overrides and VMS activation will be implemented in the next simulation step, usually between 0.5 and 0.75 seconds.

5

IMPLEMENTATION In order to test the new developments and demonstrate TRAMLAB’s practical significance a freeway section was selected and the effects of four alternative management actions during an incident were evaluated. The tests were conducted with the assistance of a real operator. The freeway section selected was a 24-km segment of southbound I-35W in the Twin Cities metro area. This section was specifically chosen as it includes most of the common geometry configurations found in the Twin Cities; it begins at Downtown Minneapolis and ends at the interchange with Highway 13. It includes 20 exit and 22 entrance ramps, which are controlled during PM, peak hour by the Minnesota adaptive ramp control strategy. Four entrances are freeway-to-freeway ramps, carrying very high volumes in the range of 1200 vehicles/hour with long spillback queues. The test site is divided into three zones (as prescribed by the Minnesota ramp control algorithm) and has three bottleneck locations. Traffic is simulated around the peek period during which the ramp metering strategy is in effect (15:00 to 18:00). The implementation described in this paper consisted of four test cases. In all test cases the same lane-blocking incident is included. The incident is generated in a four-lane section just to the south of I-494. The incident is created at 4:00 p.m. and it blocks the three rightmost lanes in the section for a period of 45 minutes and the one rightmost lane for an additional period of 1 hour. The area around the location of the incident is a well-known part of the city with one parallel arterial in close proximity to the freeway. In all the following scenarios a diversion to the arterial is assumed in degrees proportional to the nature of the message displayed on the upstream VMS [5,6]. A sketch of the area around the incident including the alternate route is given in Figure 2. I - 35W Southbound

A

B 76th St.

86th St.

I - 494

90th St.

Penn Avenue Ramp Meter

Incident Location

Alternate route

Figure 2. Incident Area of I-35W with Alternate Route In the fist case the operator was left alone to detect the incident through the TRAMLAB GUI and the included AID module. Following the identification of the incident the operator proceeded in performing the standard incident response actions. As described in the MnDOT’s TMC operations manual these actions are on the discretion of the operator under defined guidelines i.e. there are predefined messages and ramp override rates the operator can choose from. The TMC does not have predefined alternate routes except the obvious like the one used in this study. Initially the operator restricted his action on simply displaying a message in the VMS alerting the motorists of downstream congestion. As time progressed it became evident that the incident was serious and it would be some time before it is cleared.

6

At that time the operator changed the message to suggest the use of alternate routes (all actions are found in Table 1). All of the above actions demanded almost constant supervision of the incident situation and consumed a lot of the operator’s time. Post incident analysis revealed that due to the VMS message the diversion to the alternate route was increased. This in turn resulted on increased demand on the two entrance ramps immediately downstream of the incident location (86th St. & 90th St.) producing abnormally long waiting times. In the second case the same messages were displayed at the same time as before but this time the above two entrance ramps were also overridden to allow free access to the freeway. This resulted in more smooth traffic both in the freeway and the adjacent arterial. For completeness two more test cases were examined. One case where the operator does not suggest the use of alternate routes but overrides the three entrance ramps upstream of the incident to more restrictive rates and the last one were no action is taken to control the traffic. In all cases the simulator produced detailed Measures of Effectiveness (MOE) for all of the sections of the test area. In Table 2 a subset of these MOEs are presented for both the freeway mainline and the adjacent arterial on the area around the incident. From the above table noticeable is the fact that the four test cases don’t have very large differences. This can be accounted on the fact that the adaptive ramp control algorithm was always operating on the background. One of the objectives of the algorithm is to spread congestion over time to avoid breakdowns. Considerable differences can be seen in the number of stops per km, which is a good indicator of the short-term (incident duration) variations of the flow and the quality of the traffic from a safety point of view.

Case

1

2 3 4

Diversion Rate

VMS “Congestion Ahead” 15 Minutes, “Severe Accident South of I494. Use Alternate routes” 30 minutes Same as above None None

86th St. 90th St. I-494 I-494 TH121 Ramp Ramp A Ramp B Ramp Ramp (Veh/h) (Veh/h) (Veh/h) (Veh/h) (Veh/h)

20% Var.

Var.

Var.

Var.

Var.

Var. 192 Var.

Var. 540 Var.

Var. 1026 Var.

Free 648 Var.

Free 540 Var.

50% Same 5% 5%

Table 1. Traffic Control Actions per Test Case Travel Time Travel Time A to B A to B Case Freeway Arterial (sec) (sec) 259 3155 1 216 182 2 314 211 3 327 211 4

Number of Stops Freeway Per vehkm 3.1E-4 1.3E-4 4.0E-4 4.5E-4

Number of Stops Arterial 1.5E-2 9.5E-4 4.3E-3 4.6E-3

Flow B Veh/h 5279 5233 5200 5196

Average Speed Freeway km/h 87 90 82 80

Table 2. Traffic Measures of Effectiveness per Test Case

7

Average Speed Arterial km/h 40 56 60 60

The tests where contacted in real time and the operator used the TRAMLAB GUI for traffic surveillance. What is presented in this testing is the reaction of a specific operator to the stimuli provided by the TRAMLAB system demonstrating how these actions affected operations of the freeway and its ramps. Another operator might have chosen a different course of action. It should be noted that the experiment was conducted for demonstrating the utility of TRAMLAB as a testing, development and training facility rather than attempting to evaluate the performance of the control strategy or the particular operator.

CONCLUSIONS In summary, TRAMLAB is a working, integrated, automated, and flexible freeway traffic management laboratory. Its objective is to serve researchers and practitioners in the development, evaluation, demonstration and refinement of innovative traffic management and control concepts under user defined traffic conditions. The main advantage of TRAMLAB is its ability to allow the user to change any of the TMC functional components without disrupting the systems normal operation. In addition, the integrated microscopic simulator allows the recreation of almost any desired traffic scenario and allows the operator to actually manipulate traffic through the graphical user interface. During this first implementation of TRAMLAB in a Twin Cities freeway the impact the operators actions have in traffic during incident conditions was demonstrated. With the help of TRAMLAB a first quantification of these variations was made possible and presented in this paper. Further analysis of other traffic management strategies will enhance their understanding on the impact they have on traffic. In addition more effort must be devoted on developing new or refining current MOEs to understand their applicability in the evaluation of ATMS systems.

REFERENCES 1. J. Hourdakis and P.G. Michalopoulos. “Towards the Development of Next Generation Traffic Management Centers: The TRAMLAB System”. 6th. World Congress on Intelligent Transport Systems, Toronto, 1999. 2. J. Barceló, J.L. Ferrer and R.Grau, “Microscopic Traffic Simulation for ATT Systems Analysis”. Research Report, Departament d’Estadística i Investigació Operativa, Universitat Politècnica de Catalunya, April 1996. 3. Muralidhar Koka, John Hourdakis, and Panos Michalopoulos. "Computer Aided Testing and Evaluation of Adaptive Ramp Control Strategies". Transportation Research Board, 79th Annual Meeting, Washington, DC, January 2000. 4. Panos Michalopoulos, John Hourdakis. "Simplifying Simulation for ITS Applications". ITS America 10th Annual Meeting and Exposition, Boston, April 2000. 5. A. Polydoropoulou, M. Ben-Akiva, and I. Kaysi. “Influence of Traffic Information on Driver’s Route Choice Behavior”. Transportation Research Record 1453, Washington DC, 1994 6. R. Summer, et. al. “Freeway Management Handbook, Volume 1: Overview”. Report No. FHWA-SA-88-026. FHWA, U.S. Department of Transportation, May 1983

8