Introduction

UCI-ITS is developing new algorithms for ATMIS applications and testing them through microscopic simulation models. Currently UCI-ITS utilizes Paramics as a base model for the analyses.

We have developed a library of plug-in modules to enhance and customize Paramics using a Functional Interface or Application Programming Interface (API). Various ATMIS applications are incorporated and tested as in field operation.

• ParaDyn (Path-based routing for ATIS evaluation)
• Full-actuated and Adapative Signal Control
• Time-based Ramp Metering
• Variable Message Sign Controller
• Loop Data Aggregator
• MySQL Database
• CORBA Interface
• Performance Measure
• Paratransit Routing

Overall Framework

The Paramics' capabilities are enhanced with additional routines added though the application programming interface (API). Since various control strategies are tested and evaluated in the UCI ATMIS testbed, flexibility and data interface are essential part of the simulation model. In addition to the main Paramics module, the hybrid simulation framework consists of five additional modules: (1) Monitoring, (2) Adaptive Traffic Control, (3) Data Communication, (4) Route Information, and (5) Route Decision. Each module consists of one or multiple APIs. The individual APIs have their own functions interfacing with other modules within the simulation framework. The flexible nature of the model framework allows easy incorporation of new technologies and algorithms into the model framework.

Monitoring and Adaptive Traffic Control

We have developed for ATMIS are travel time estimation or prediction, O/D estimation, incident detection, etc. The monitoring routines are also needed by the adaptive traffic control routines such as for traffic signal control and ramp metering. Individual control devices are modeled independently with APIs for devices such as Type-170 controllers, interfacing with the monitoring module. APIs for statistics are supplementary tools to measure emission and fuel consumption, travel time statistics for individual vehicles, etc.

Data Communication

The objective of this task is to create a simplified network to be used in route information and decision modules, but consistent with the original one coded for running Paramics. In addition, the process also requires the construction of a lookup table for communication between the two networks, of information related to network level variables like level of service, and also detailed information on individual vehicle positions, speeds, route decisions, etc.

The equivalent abstracted network is made taking into account the following possible simplification. In terms of link characteristics, we aggregate across those Paramics links, whose end nodes represent only a change in geometry or capacity than a real decision node such as an intersection or an interchange. Calculation of link cost in our abstract network is consistent with the Paramics link cost calculation, which includes link costs themselves, and turn movement costs. Look-up tables are used to identify the original links that corresponds to the abstracted network links and to aggregate travel times on them.

Route Information and Decision

The importance of path-based routing arises from the drivers' route selection behavior comparing the routes in their mind with the routes suggested by ATIS. In our framework, the path dynamics features of DYNASMART are incorporated into the hybrid scheme via the Paramics API capability.

The route information module has two folders. The first one is initial route selection mechanism. Initial routes are assigned to individual vehicles from a list of k-shortest paths based on their levels of network familiarity that is assigned along with other characteristics when the vehicle is generated. The vehicle's characteristics and initial route are basis of route decision behavior. The second folder is generation of route guidance. Main source of the route guidance/information could be either path-processing procedure or external algorithms. The route guidance/information can be generated in various ways depending on their capability of network monitoring and/or their objectives or algorithms. Allowing various guidance types, the path processing/route information routine is capable of using historic data as well as real-time data, though basic path processing relies on k-shortest paths from real-time data. Further, any dynamic route guidance generation algorithm such as DynaMIT (4) or DYNASMART-X (5) can be incorporated via API in the route information module and externally processed paths can be also directly fed, while the data for the information generation are provided from the monitoring module. Besides this route guidance that are applied only to equipped vehicles, variable message signs (VMS) provide unequipped drivers with route guidance/information. An algorithm to generate VMS is also modeled via API within this route information module. This feature allows Paramics to be a test-bed for the evaluation of various route guidance systems.

Path-based Routing -- ParaDyn

The hybrid simulation approach integrates the PARAMICS microscopic simulation with the routing and behavior response simulation schemes as in DYNASMART, so that the integrated simulator can evaluate information/routing schemes with route choice behavior models. This approach is based on integrating networks of two different levels of abstraction and communication of vehicle positions between the detailed network (as in PARAMICS) to the more abstract network (as in DYNASMART). The vehicle route decisions processed at abstract network are then transmitted to the detailed network simulation that controls vehicle movement at the microscopic level. The integrated simulation program allows realistic evaluation of a variety of technologies in ATMIS.

Full-actuated Signal Control

Fixed-time signal control is provided by PARAMICS. PARAMICS also provides a plan/phase language in MODELLER to make actuated signal. However, it is difficult to use it for emulating the complex control logic of Model 170 or 2070 type controller, which are widely used in California.

This controller (eight-phase, dual-ring, concurrent controller logic) has been implemented in this API. Each of eight phases accommodates one of the through or left turning movements. The right turns are omitted and assumed to proceed with the through movements. In full-actuated signal control, all phases at an intersection are actuated, then the length of each phase, and consequently the cycle length, will vary with each cycle. Some phases may be skipped if there is no vehicle actuation. To simulate the real controller better, the order and sequence of phases can also be altered.

The data input to this API is the signal timing plan, the geometry and detector information of each intersection. Interface functions have provided by this API for external modules to acquire and change the default timing plan.

Based on the API module of full actuated signal control, the signal coordination logic is also implemented, with additional force-off logic to maintain the background cycle length and form green band for a particular phase (sync phase). This is used for emulating the signal coordination of Controller 2070.

Time-based Ramp metering

A time-of-day basis ramp control on either a one-car-per-green basis or a n-cars-per-green basis (with n > 1) is implemented. There are two operation modes, fixed-time control and vehicle-actuated fixed-time control.

The data input is a time-of-day ramp control plan. Any an external module, such as a coordinated ramp metering algorithm, can communicate with this API, i.e. getting the current ramp rate or setting a new ramp rate to any a specific ramp meter, through interface functions defined by this API.

Variable Message Sign Controller

This API module interacts ATMIS applications with VMS signs. Through interface functions provided by this API, various ATMIS applications can dynamically update VMS information and then affect driver's behavior timely.

Loop Data Aggregator

PARAMICS can output two types of loop detector data for analysis:
· Point loop data, including flow, speed, headway, occupancy, and acceleration of a vehicle, and
· Link loop data, including flow, average speed, density, lane use, and lane changing on a link.
Point data is gathered at every time step when an individual vehicle passes over the loop; link data analyses the traffic data over a link, where loops locate, at a user-defined time period. However, many ATMIS applications demand point traffic data, but in an aggregated manner over user-defined time intervals, e.g. 30 seconds.

Loop data aggregator emulates the outputs of real-world data collection from induction loops, through gathering point loop data at each time step of simulation and then aggregating at any time interval specified by users. The gathered data can be raw data or smoothed data in term of user's choice. Aggregated loop data (including volume, occupancy, speed) can be output to text files or MYSQL database, and can be also accessed by interface functions defined in this API.

MySQL Database

A series of interface functions has been developed using MYSQL API functions for the purpose of connecting PARAMICS simulation environment with MYSQL database. This will fit to the need of storing large volume of data during the simulation process.

CORBA Interface

The API implements and generates a set of server objects for the relevant objects in the loaded simulation based on CORBA naming service. In this way, PARAMICS could be connected to other field device objects, or other ATMIS modules.

Performance Measure

PARAMICS provides a variety of measures of effectiveness (MOE) such as vehicle flow, delay, loop count, occupancy, turning counts, etc. The function of this API plugin is to provide more user-preferable measures and some measures that cannot be provided by PARAMICS directly.

Due to the randomness of micro-simulation, a measure of the system performance for the whole network should be provided All vehicles, including those having finished their journey and those currently simulated, are all considered in this measure.

Other measures in this API include:

• Average on-ramp waiting time, which is a measure evaluating the effect of ramp control to the traffic flow on entrance ramps.
• Average OD travel time, which considers the average travel time for vehicles between a specific OD pairs. Note that we use this measure to evaluate the effect of control on vehicles from an entrance ramp to the downstream end of the freeway.
• Intersection delay, which can report the delay information, including average stop delay, control delay, queue length of each approach, average travel time of a movement of an intersection at a certain aggregation level.
  

Paratransit Routing

Based on the ParaDyn's path-based routing capability, this API enables a dynamic paratransit simulation. While the transit routing decision is made via a real-time point-to-point shortest path algorithm, the transit in the simulation model moves along the simulation network. The optimal routing decision is made based on individual vehicle's position, passenger calls, and real-time traffic condition. Passenger demand generation and performance measure are embeded in the simulation framework.

<Click the figure to enlarge>