The SMARTEST Micro-Simulation Workshop

2 TSS-Transport Simulation Systems, Tarragona 110-114, 08015Barcelona, Spain

e-mail: info@tss-bcn.com

Abstract

The simulation of Advanced Transport Telematic Applications requires specific modelling features, which have not been usually taken into account in the design of microscopic traffic simulation models. This paper discusses the general requirements of some of these applications, and describes how have they been implemented in the microscopic traffic simulator AIMSUN2.

1. Introduction

Microscopic traffic simulators are simulation tools that emulate realistically the flow of vehicles on a road network. The main modelling components of a microscopic traffic simulation model are: an accurate representation of the road network geometry, a detailed modelling of individual vehicles behaviour, and an explicit reproduction of traffic control plans. The primary attention has been paid usually to the proper modelling and calibration of all these model components, namely the car-following, gap acceptance, lane change, and other internal models which along with other modelling parameters accounting for attributes of the physical system entities, allow the microscopic simulation model reproduce flow, speed, occupancies, travel time, average queue lengths, etc. with enough accuracy to consider the model valid.

The advent of the Advanced Transport Telematic Applications made possible by combining the developments in informatics and telecommunications applied to transportation problems, has created new objectives and requirements for micro-simulation models. Quoting from Deliverable D3 of the SMARTEST Project [1]: "The objective of micro-simulation models is essentially, from the model designers point of view, to quantify the benefits of Intelligent Transportation Systems (ITS), primarily Advanced Traveller Information Systems (ATIS) and Advanced Traffic Management Systems (ATMS). Micro-simulation is used for evaluation prior to or in parallel with on-street operation. This covers many objectives such as the study of dynamic traffic control, incident management schemes, real-time route guidance strategies, adaptive intersection signal controls, ramp and mainline metering, etc. Furthermore some models try to assess the impact and sensitivity of alternative design parameters".

The current trend in the development of Advanced Transport Telematic Applications, either real-time adaptive, or based on other specific approaches, is far from being standardised. It is therefore an exercise of dubious utility to try to integrate them in a fixed way in a microscopic traffic simulator. The relative gain achieved by including any of these, as an in-built function of the microsimulator is limited to simulating, on an easier way, those road networks on which the selected application is operating. However there would be no means of simulating other systems with that microsimulator. This is true whenever we address the problem of simulating adaptive traffic control systems as, for example, SCOOT, SCATS, vehicle actuated, control systems giving priority to public transport, etc., Advanced Traffic Management Systems (using VMS, traffic calming strategies, ramp metering policies, etc), Vehicle Guidance Systems, Public Transport Vehicle Scheduling and Control Systems or applications aimed at estimating the environmental impacts of pollutant emissions, and energy consumes. The main question then is: How can these Advanced Transport Telematic Applications be properly evaluated and tested by simulation?

From a conceptual point of view the operation of these modern systems can be described as follows: for certain applications the road network is suitably equipped with traffic detectors of various technologies (loop detectors, image processing detectors, etc.), with a specific layout depending on the requirements of the control approach. They supply the necessary real-time traffic data (flows, speeds, occupancies, etc) with the required degree of aggregation. These real-time traffic measurements feed the logic of the traffic control or management system which, after suitable processing, makes ad hoc control decisions: e.g. extend the green phase, change to the red phase, apply some traffic calming strategies, etc.. Other applications as, for example vehicle guidance, public transport monitoring systems, or the evaluation of environmental impacts, require the access to vehicle data (position, speed, acceleration, etc.), to emulate the up-link messages in vehicle guidance applications, the vehicle tracking for the public transport monitoring or fleet management systems, or simply to provide the required data for certain fuel consumption or pollutant emissions models. To evaluate and test any of these systems a microsimulator must be capable of incorporating in the model the corresponding traffic devices as objects: i.e. detectors, traffic lights, VMS, etc. It must also emulate their functions: provide the specific traffic measurements at the required time intervals, increase the phase timing in a given amount of time, implement a traffic calming strategy (slow down the speed on a road section, recommend an alternative route, etc). How can such evaluations be done by simulation without explicit in-built modelling of the specific Advanced Telematic Application?

2. The GETRAM/AIMSUN2 Micro-simulator

2.1 GETRAM

GETRAM (Generic Environment for Traffic Analysis and Modelling), [2-3], is a simulation environment comprising a traffic network graphical editor (TEDI), a microscopic traffic simulator (AIMSUN2), a network data base, a module for storing results and an Application Programming Interface to aid interfacing to assignment models and other simulation models, as for example the macroscopic traffic assignment EMME/2 system, [4]. The functional structure of the systems is depicted in figure 1.

2.2 AIMSUN2 microscopic simulator

AIMSUN2 (Advanced Interactive Microscopic Simulator for Urban and Non-Urban Networks), [5], is a microscopic traffic simulator that can deal with different traffic networks: urban networks, freeways, highways, ring roads, arterial and any combination of them. AIMSUN2 simulates traffic flows either based on input traffic flows and turning proportions, or on O-D matrices and route selection models. In the former, vehicles are distributed stochastically around the network, whereas in the latter vehicles are assigned to specific routes from the start of their journey to their destination. Different types of traffic control can be modelled in AIMSUN2: traffic signals, junctions without traffic signals (give way or stop signs) and ramp metering. Vehicle behaviour models (car following, lane change, gap acceptance, etc.) are function of several parameters that allow modelling 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.

Figure 1

The logic of the simulation process in AIMSUN2 is illustrated in the diagram of figure 2. It can be considered as a hybrid simulation process combining and event scheduling approach with an activity scanning. At each time interval (simulation step), the simulation cycle updates the unconditional events scheduling list, that is events like traffic light changes which not depend on the termination of other activities. The "Update Control" box in the flow chart represents this step. After this updating process starts a set of nested loops updating the states of the entities (road sections and junctions) and vehicles in the model. Once the last entity has been updated the simulators performs the remaining operations: input new vehicles, collect new data, etc.

Depending on the type of simulation new vehicles are input into the network according to flow generation procedures (headway distributions for example) at input sections, or using time sliced O-D matrices and explicit route selection, as shown in the diagram. The simulation process includes in this case an initial computation of routes going from every section to every destination according to link cost criteria specified by the user. A shortest route component calculates periodically the new shortest routes according to the new travel times provided by the simulator, and a route selection model assigns the vehicles to these routes during the current time interval. Vehicles hold the assigned route from origins to destinations at least the had been identified as "guided" at generation time, then they can dynamically change the route en route as required for simulating vehicle guidance and vehicle information systems.

The car following model implemented in AIMSUN2 is based on the Gipps model [6], and can be considered as an ad hoc evolution of this empirical model in which the model parameters are not global but determined by the influence of local parameters depending on the "type of driver" (limit speed acceptance of the vehicle), the geometry of the section (speed limit on the section, speed limits on turnings, etc.), the influence of vehicles on adjacent lanes, etc. The lane change model in AIMSUN2 can also be considered as an further evolution of the seminal Gipps lane change model [7]. Lane change is modelled as a decision process analysing the necessity of the lane change (as in the case of turning manoeuvres determined by the route), the desirability of the lane change (as for example to reach the desired speed when the leader vehicle is slower), and the feasibility conditions for the lane change that are also local, depending on the location of the vehicle on the road network.

Figure 2: Logic of the Simulation Process in AIMSUN2

AIMSUN2 can also simulate any kind of measurable traffic detector: counts, occupancy and speed. 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.

2.3 TEDI network editor

TEDI is a graphical editor for traffic networks. It has been designed with the aim of making the process of network data entry and model building user-friendly. Its main function is the construction of traffic models with which to feed traffic simulators like AIMSUN2. To facilitate this task the editor accepts as a background a graphical description of the network area, so sections and nodes can be built subsequently into the foreground. The editor supports both urban and interurban roads, which means that the level of detail covers elements such as side lanes, entrance and exit ramps, intersections, traffic lights and ramp metering. TEDI has an interface to the EMME/2 DATA BANK, providing the means to complement a macroscopic analysis effortlessly with a microscopic one using the same traffic data (i.e. O/D matrices). The user can define a hierarchical tree of views so that a traffic model can be restricted to one of these views. The editor is designed for the level of detail required by regional, intermediate and local areas, with increased modelling detail. A library of high-level, object-based application programming functions, named TDFunctions, assists the development of interactive external applications, and, in general to access any data. The TDFunctions enable objects in the network to be read and manipulated or can restrict the view to a sub-area. Results storage and control plans are also accessed with these functions.

3. GETRAM/AIMSUN2 Extensions

To cope with the requirements of simulating Advanced Transport Telematic Applications specific extensions to GETRAM/AIMSUN2 have been developed. These extensions fall into three categories:

1. Adaptive Traffic Control, Traffic Management Systems and Incident Management Systems
2. Vehicle Guidance, Fuel Consumption and Emissions
3. Public Vehicle Scheduling and Control Systems

The approach taken in GETRAM/AIMSUN2 consists of considering the Advanced Telematics Application to be tested as an EXTERNAL APPLICATION that can communicate with GETRAM/AIMSUN2. An ad hoc version of AIMSUN2 including a set of DLL has been developed for this purpose. This library gives AIMSUN2 the ability to communicate with almost any of the above-mentioned external applications.

Figure 3

Using the TEDI & AIMSUN2 functions the detector, VMS and traffic lights can be modelled and their attributes defined. The process of information exchange between AIMSUN2 and the external application is shown in Figure 3. The AIMSUN2 model of the road network emulates the detection process providing the external application with the required "Simulation Detection Data". The EXTERNAL APPLICATION (user provided) decides which control and/or management actions have to be applied on the road network and sends the corresponding information to the simulation model which then emulates their operation through the corresponding model components such as traffic lights, VMS, etc. Another set of DLL function enables the user to access the information on each vehicle state (position, speed, acceleration, etc.) at each simulation cycle.

3.1 Simulating Management and Control actions

Three main types of actions, as a result of the actuation of EXTERNAL APPLICATION on the simulation, are taken into account:

1. Actuate control of traffic lights and ramp metering
2. Actuate control of ramp metering
3. Supply information to the driver using Variable Message Signs (VMS)

3.1.1 Traffic Control Actions

AIMSUN2 takes into account two types of traffic control: traffic lights and ramp metering. The first is considered for urban type intersection nodes, while the second one is for controlling freeway entrance ramps.

For the intersection control, a phase-based approach is applied in which the cycle of the junction is divided into phases where each one has a particular set of signal groups with right of way (a signal group is considered as one traffic light). During the simulation of a scenario, AIMSUN2 executes a fixed control plan taking into account the phase modelling for each junction. An EXTERNAL APPLICATION can modify this execution by means of different actions. The available actions are to:

1. Change the duration of each phase: The EXTERNAL APPLICATION can increase or decrease the duration, but the control plan structure is not modified.
2. Disable the fixed control plan structure: The EXTERNAL APPLICATION disables the structure of the control plan and completely controls the phase changing.
3. Change the current phase: The EXTERNAL APPLICATION can change the current phase to another. If the fixed control plan (timings) of the junction have not been disabled, AIMSUN2 programmes the next changing of phase taking into account the duration of the phases. Otherwise AIMSUN2 holds the new phase until the EXTERNAL APPLICATION changes it to another.

Examples of functions of the DLL library relative to control junctions are:

• Read Number of junctions: Reads the number of junctions present on the road network.
• Read the Identifier of a junction: Reads the identifier of junction elem-th present on the road network.
• Read the Name of a junction: Reads the name of junction identified by idJunction.
• Read the number of Signal Groups of a junction: Reads the number of signal groups defined in junction identified by idJunction.
• Read the Number of Phases of a junction: Reads the total number of phases of a junction in the current control plan.
• Read Time Duration of a phase of a junction: Reads the maximum, minimum and current duration of a in junction during the current control plan.
• Read the Current Phase of a junction: Reads the current phase of a junction, even when the junction has disabled the fixed control plan.
• Disables the fixed control plan of a junction: Disables the fixed control plan of a junction, so the phase changing is completely controlled by the EXTERNAL APPLICATION (i.e. an adaptive traffic control system).
• Change of Phase: Changes to idPhase in junction identified by idJunction.
• Change the Current Duration of Phase: Changes the duration of idPhase in junction identified by idJunction in the current control plan.
• Change the State of a Signal Group: Changes the state of signal group idSigGr in junction identified by idJunction.

3.1.2 Ramp Metering

AIMSUN2 also incorporates ramp-metering control. This type of control is used to limit the input flow to certain roads or freeways in order to maintain certain smooth traffic conditions. The objective is to ensure that entrance demand never surpasses the capacity of the main road. AIMSUN2 considers three types of ramp metering depending on the implementation and the parameters that characterise it:

• Green time metering, with parameters green time and cycle time. It is modelled as a traffic light.
• Flow metering, with parameters platoon length and flow (veh/h). The meter is automatically regulated in order to permit the entrance of a certain maximum number of vehicles per hour.
• Delay metering, with parameters mean delay time and its standard deviation. It is used to model the stopped vehicles due to some control facility, such as a toll or a customs checkpoint.

The EXTERNAL APPLICATION can modify this modelling by different actions. It can:

• Change the parameters of a metering, the EXTERNAL APPLICATION can dynamically modify the parameters that define a ramp metering.
• Disable the control structure: EXTERNAL APPLICATION disable the structure of the ramp metering and completely controls the state changing.
• Change the state of a metering: The EXTERNAL APPLICATION can change the current state to another. If the metering has not disabled the control, AIMSUN2 programmes the next changing of state taking into account the parameters, which define the control. Otherwise AIMSUN2 holds the new state until the EXTERNAL APPLICATION changes it to another.

Examples of functions of the DLL relative to ramp metering are:

• Read the Section Identifier of a metering: Reads the section identifier that contains the metering elem-th present on the road network.
• Read the Type of metering: Reads the type of metering present in an section. (The type of a metering can be 0: None; 1: GREEN METERING; 2: FLOW METERING; 3: DELAY METERING.)
• Read the Control Parameters of a Green Metering: Reads the parameters of a green metering that are defined in the current control
• Change the Control Parameters of a Green Metering: Changes the parameters of a green metering that are defined in the current control.
• Read the Control Parameters of a Flow Metering: Reads the parameters of a flow metering defined in the current control.
• Change the Control Parameters of a Flow Metering: Changes the parameters of a flow metering that are defined in the current control.
• Read the Control Parameters of a Delay Metering: Reads the parameters of a delay metering that are defined in the current control.
• Change the Control Parameters of a Delay Metering: Changes the parameters of a delay metering that are defined in the current control.
• Disable the fixed control plan of a metering: Disables the fixed control plan of a metering, so the state changing is completely controlled by the EXTERNAL APPLICATION.

3.1.3 Variable Message Signs

Providing information to drivers is a possible action of a Traffic Management System on a road network equipped with Variable Message Sign infrastructure. Messages may inform drivers about the presence of incidents, congestion ahead or suggest alternative routes. AIMSUN2 takes into account the modelling of Variable Message Sign (VMS) as defined in TEDI by means of a dialogue including the VMS name or identification code, its position in the section the activated message, if any, the list of feasible messages for this VMS, and the list of all Actions available for this network associated to the messages.

Messages in a VMS from its message list may be activated in two different ways: directly through the user interface or by an external application through the communication interface. In both cases, it will cause the message to be displayed as Activated Message and the Actions associated with it to be implemented. Each message has a list of Actions associated with it which appear in the list box named ‘Mess Actions’ in the VMS Information Window. The list box named ‘Actions’ contains all actions available for this network. An Action represents the expected impact a message has on driver’s behaviour. Examples of Actions are: modifications of the speed limit, modification of the input flow, modifications of the turning proportions

When simulating with the Route Based option actions can also imply a re-routing, that is the possibility of altering the vehicle’s path. This effect is accomplished by defining the next turn and/or defining a new destination. The re-routing effect is defined by the following for each modality independently:

• Compliance level (d ): This parameter gives the compliance level of the action. If d =1then it causes the re-routing to be followed by all vehicles (i.e. it is obligatory). If d =0 then the re-routing action will be followed depending on the driver behavioural parameter (a local parameter of it), i.e. it is an information only. When 0<d <1, d gives the level of acceptance, e.g. it is advice
• Modify the next turning: Change, which is the next turning that the vehicle must follow. This action is defined taking into account the destination
• Modify destination: When a vehicle enters into a section affected by an action, the simulator changes its destination

Functions relative to VMS of the DLL library are:

• Read the Identifier of a VMS: Reads the section identifier that contains the VMS elem-th present on the road network.
• Read the message of a VMS: Reads the text of a message elem-th in a VMS
• Read the Current Active Message: Reads the current active message in a VMS
• Active a Message in a VMS: Actives in PanelName the Message. AIMSUN2 executes the actions associated in Message

3.1.4 Detector Measurements

Detection output data is produced by AIMSUN2 periodically, provided that there are detectors defined in the network and the Detection Function of the simulator is activated. Currently there are two main types of Detection implemented: Common Detection Model and EXTERNAL APPLICATION type Detection Model.

In the Common Detection Model, the data produced depends on the measuring capabilities of the detectors. There is a data line for each detector, which contains the detector identifier and the list of measures gathered. They may be Count (number of vehicles per interval), Occupancy (percentage of time the vehicle is on the detector), Speed (mean speed for vehicles crossing the detector) and Presence (if a vehicle has been on the detector, it is set to 1). These data are stored in ASCII files.

In the EXTERNAL APPLICATION type Detection Model, the measures are given at every simulation step or aggregated each detection interval. The gathered measures are: Counts (Number of vehicles), Speeds (Mean speed for vehicles crossing the detector), Occupancies (percentage of time the detector is activated), and Presence (whether a vehicle is over the detector or not). The EXTERNAL APPLICATION can undertake the following actions with detectors: retrieve the number of detectors in the network, retrieve the name of each detector, retrieve the detection interval, retrieve the detector measures gathered in each simulation step, retrieve the aggregated detector measures.

3.2 Simulating incidents and incident management

The diagram in figure 4 schematises the methodological procedure proposed for the simulation of incident detection and management based on the EXTERNAL APPLICATIONS. The procedure is based on a microscopic simulation model of a site that emulates traffic conditions on the site, and generates traffic data: flows, occupancies, speeds, (travel times when required), at the sampling rate requested by the external applications (for example 30 seconds is an standard request for most automatic incident detection algorithms, [8]), with the format proper of the technology used at the site. These traffic data feed the Incident Warning, Incident Detection and Traffic Management Modules implementing the corresponding External Applications.

The Incident Warning applications estimate an incident probability [9] that is sent as a warning to the Traffic Management System that may take it into account. The Simulation model dialogues with the Management System, as an external application, in the way described above. Once the Incident Detection Module detects an incident, it generates an incident alarm, which is sent to the Traffic Management System. The management decisions are communicated to the simulation model through the proper dialogue as described above. Simulation of Vehicle Guidance

Figure 4

3.3 Simulation of Vehicle Guidance

Vehicle Guidance can also be modelled as an External Application that can be properly simulated with AIMSUN2 by means of an exchange of information using the suitable DLL functions. Essentially the simulation of a Vehicle Guidance system, [10], consists of an exchange of information between the equipped car and the Traffic Information Centre. The on board equipment collects information on the vehicle’s position, travel time, speed, experienced delay, number of stops, etc. which is sent to the Traffic Information Centre, [11-13], by means of the telecommunication technology on which the system is based, as for example, beacons or GSM, or both.

The vehicle data collection can be modelled as follows: each equipped vehicle sends the information to the system when passing through certain points on the network. In the network description the definition of these Data Collection Points (DCP) have been included working like detectors. Each time the position of a guided vehicle is updated it is checked whether or not it has passed through a DCP. If so, a message to the information centre is sent and the vehicle information is updated. Alternative data collection procedures can be implemented for the simulation, as for example assuming that there are a set of fixed DCP which correspond to the end of each section, or that DCP are variable and their position depends on the behaviour of each guided vehicle, for instance, if it takes more than certain time for a vehicle to cross a section or if it has to stop during a section journey. Examples of floating car data collection sampling procedures, as illustrated in figure 5, are: section based (a vehicle sends a message whenever it reaches the end of any section in the network); time based (a vehicle sends a message every certain time interval whose length can be selected by the user as a simulation input parameter); dual mode sampling (time and section based, if a vehicle takes more than one time interval to travel one section, a message is sent for each time interval); speed and section basis: a vehicle sends a message at the end of each section. Besides, if during the trip along a section the vehicle speed falls below a minimum value (which is set by the user as a simulation input parameter), a message is sent every time interval until the end of section is reached.

Figure 5: Microscopic Simulation of Vehicle Guidance Systems

Guided vehicles, which are a percentage of the total, are identified at generation time and the data collection process is initialised. For each guided vehicle the corresponding DLL functions collect the information on the vehicle data. Additionally, each time a guided vehicle is updated, it is checked wether or not it is time to transmit data. If so, the following information is updated by means of the ad hoc DLL: Number of messages sent, Number of data blocks transmitted, Sections and distance travelled since last message, Time for the next transmission. In a similar way every time a guided vehicle reaches the end of a section, the following information is updated: Number of messages sent, Number of data bolcks transmitted, Distance travelled since last message, Time since last transmission.

The simulation can thus provide the following information [14]: traffic volumes (guided and unguided); mean vehicles speed (km/h); number of stops per vehicle/kilometre; communications overhead in total number of messages between vehicles and information centre, per time unit, and total number of blocks transmitted per time unit; mean time between messages per vehicle; average distance travelled between messages per vehicle and average number of messages per section and vehicle. The first three items estimate the level of network congestion in the simulation experiment. The next two estimate the communications requirements for the system, and the last three are measures about the quality of the overall information received by the centre. To illustrate these simulation results let us summarily describe a typical simulation experiment of a guidance system. The parameters defining the experiment are the following: MNV, mean number of vehicles in the network; MNG, mean number of guided vehicles in the network; NTR, number of trips / hour. Trips from origins to destinations in the modelled network; SPD, mean journey speed in kilometers/hour; NST, number of stops per vehicle per kilometre travelled. The results on communications requirements produced as output by the AIMSUN2 simulation are represented by the following variables: MpS, number of messages (transmissions) per second sent from guided vehicles to the information centre; BpS, number of data blocks transmitted per second. For instance, a trip message is composed by one data block for the header and one data block for each section travelled. Taking into account the type of information of each section of the messages, the typical length of a data block could be considered as 16 bytes. AIMSUN2 output provides also an estimate of the quality of the overall data transmitted from the equipped vehicles to the information centre by means of the following variables: TbT, mean time between transmissions per vehicle, which is a measure of how often the centre has information from a given vehicle; DbT, mean distance travelled between transmissions per vehicle, this measure together with the TbT, gives an idea about the frequency of information updating for each vehicle; CpS, mean number of messages transmitted per section per vehicle. This provides measures of the information quality for each section.

Thus, for example, for a simulation experiment done in the SOCRATES project [12], [14], the traffic conditions where characterised by the following values:

Therefore, the mean number of guided vehicles that the system was controlling was 500 vehicles from a total of 10000 (that is the 5%). The mean speed on the network was 30 km/h and a vehicle had to stop on average about 6 times every kilometre travelled.

The communications requirements obtained in that simulation experiment for the different sampling procedures are summarised in the following table:

The quality of the data received by the traffic information centre can be represented by the following measures:

From this experiment, it appears that the best sampling procedures are those based on dual mode sampling on time basis. For not to fall in communication overheads, a time interval of 60 sec. or more is preferable.

The Traffic Information Centre collects the individual information from the equipped vehicles and, after a suitable processing produces the guidance information which is transmitted to the guided vehicles. The broadcasting of this information and the guided vehicle reactions can be simulated using the DLL in a similar way as the simulation of the VMS, based on the capability of the simulator to dynamically re-route the guided vehicles en-route.

4. The parallelization of AIMSUN2

To conclude this description of improved modelling features in the microscopic simulator AIMSUN2 we will make some comments on what could be expected from the parallelisation of the simulator. A complete description can be found elsewhere, [15-17]. Some reasons to parallelize a microscopic traffic simulator could be the following: the situation of the current practices in traffic management can be summarised saying that, out of a limited traffic control practice, traffic management is currently based on manual procedures, relying on the experience of human operators, and off-line computing practices. There is a main reason for that, numerical algorithms, based either on optimisation or simulation approaches, to deal with time-varying traffic flows in real size traffic networks have very high computing requirements to be processed sequentially on the currently available computing platforms, the resort to parallel computing is a way for achieving the required performance for real-time applications.

The encouraging results obtained with the parallel version of AIMSUN2, reported in [17], based on a standard library of threads available in the current version of SUN Solaris 2.4, and a shared memory computing platform, where average speed ups of up to 3.5 times have been achieved, show that a quasi-real time operation of the systems using microscopic simulation for management purposes is feasible. In the computational experiments only the basic version of AIMSUN2 has been parallelized, certainly the inclusion of routing information and its use in the microsimulation will impose additional computational burden that must be investigated. On the other hand the parallelization studied depends, obviously, on the structure of AIMSUN2 and therefore the results cannot be extrapolated to other microscopic simulator with different internal structures. However, we believe that our results show that the parallelization of the microscopic simulators, on the currently available computer platforms, opens the door to simulation analysis of medium to large networks, and not only small networks as microscopic approaches had been restricted so far, and to the use of simulation as decision support tool in the context of Traffic Management applications

5. Conclusions

The paper has described the requirements to simulate Advanced Transport Applications and the conceptual approaches to implement them in microscopic traffic simulators. The description has been completed showing how these approaches have been implemented in the case of the AIMSUN2 microscopic traffic simulator. These implementations have been mainly done through the participation in projects of the ATT Programme of the European Union. References to these implementations can be found in the already referenced reports of SMARTEST (simulation of VMS, ramp metering, etc.) [1], SOCRATES (Vehicle Guidance) [11-12], CLAIRE SAVE (Adaptive Traffic Control and Environmental impacts) [18], CAPITALS (Traffic Management) [19], IN-RESPONSE (Incident Management) [20], and PETRI, [16].

6. References

1. SMARTEST Project Deliverable D3, August 1997, European Commission, 4th Framework Programme, Transport RTD Programme, Contract Nº: RO-97-SC.1059.

2. R. Grau and J. Barceló. The design of GETRAM: A Generic Environment for Traffic Analysis and Modeling. Research Report DR 93/02. Departamento de Estadística e Investigación Operativa. Universidad Politécnica de Cataluña. (1993).

3. J. Barceló, J.L. Ferrer and R. Grau. AIMSUN2 and the GETRAM Simulation Environment. Technical Report. Departamento de Estadística e Investigación Operativa. Universidad Politécnica de Cataluña (1994).

4. INRO Consultants, EMME/2 User’s Manual. Software Release 8.0 (1996).

5. J. Barceló and J.L. Ferrer. AIMSUN2: Advanced Interactive Microscopic Simulator for Urban Networks. User´s Manual. Departamento de Estadística e Investigación Operativa. Facultad de Informática. Universidad Politécnica de Cataluña (1997).

6. P.G. Gipps, A Behavioural Car-following Model for Computer Simulation, Transpn. Res. 15B, pp 105-111 (1981).

7. P.G. Gipps, A Model for the Structure of Lane-Changing Decisions, Transpn. Res. 20B, pp.403-414 (1986).

8. Y.J. Stephanedes, A.P. Chassiakos and P.G. Michalopoulos, Comparative Performance Evaluation of Incident Detection Algorithms, Transportation Research Record 1360 (1996).

9. I.R. Wilmink and L.H. Immers, Deriving Incident Management Measures using Incident Probability Models and Simulation, TNO Research Report 95/NV/172, The Netherlands (1995).

10. D. Jeffery. Route guidance and In-vehicle Information Systems. In: Information Technology. Applications in Transport, P. Bonsall and M. Bell (eds), VNU Science Press, Utrecht, pp. 319-351 (1987).

11. SOCRATES, 1990, DRIVE I Project V1007, Commission of the European Communities, Report on WP1.2.3, 'Floating Car Data', Prepared by Hoffmann Leiter, Universitat Politécnica de Catalunya, and BASt, responsibles G.Hoffmann and J.Barceló.

12. SOCRATES KERNEL 1992, DRIVE II Project V2013, Commission of the European Communities, Report SCKN/UPC 03.43.92, Equipped Vehicle Fleet Requirements for Monitoring Network Conditions in a Dynamic Route Guidance System Prepared by Universitat Politécnica de Catalunya, responsible J.Barceló.

13. I.Catling, "SOCRATES", in: Advanced Technology for Road Transport, ed. By Ian Catling, Artech House, London (1994).

14. J. Barceló, J.L Ferrer, and R. Martín, Simulation Assisted design and Assessment of Vehicle Guidance Systems, Accepted for publication in International Transactions on Operations Research, (1998).

15. J.Barceló, J.L. Ferrer, D. García, M. Florian and E. Le Saux, The Parallelization of AIMSUN2 Microscopic Simulator for ITS Applications, Proceedings of the 3rd. World Congress on Intelligent Transport Systems, Orlando (1996).

16. J.Barceló, J.Casas, E.Codina, A.Fernández, J.L.Ferrer, D. García and R.Grau, PETRI: A Parallel Environment for a Real-Time Traffic Management and Information System, Proceedings of the 3rd. World Congress on Intelligent Transport Systems, Orlando, (1996).

17. J. Barceló, J.L. Ferrer, D. García, M. Florian and E. Le Saux, "Parallelization of Microscopic Traffic Simulation for ATT Systems Analysis", in: Equilibrium and Advanced Transport Modelling, ed. By P. Marcotte and S. Nguyen, Kluwer (1998).

18. CAPITALS, (1998), "Workpackage 5.2 Evaluation Report", EU DGXIII, Project TR 1007.

19. CLAIRE SAVE, 1996, K. Fox, H. Kirby, G. Scemama and A. Walker, "Avoiding High Fuel Consumption in Congested Cities", Project Final Report, Institute for Transport Studies, University of Leeds.

20. IN-RESPONSE, (1996, 1997) Deliverables 4.3, 5.1 and 5.2, EU DGXIII, Project TR1030.

Enhancement of the DRACULA simulation model

Ronghui Liu

Institute for Transport Studies, University of Leeds, Leeds, LS2 9JT, UK

e-mail: rliu@its.leeds.ac.uk

Abstract

The following five models have been improved within DRACULA as part of the SMARTEST project:

• Roundabouts
• PT Services
• Adaptive Traffic Signals
• PT Priority
• Detectors

and one new model has been added:

• Traffic Calming

Improved validation of the model has also taken place. Improvements in the PT services model include a new bus stop model and the development of guided bus and tram operations. New roundabout and traffic calming models have also be developed, which have been calibrated and validated using data collected in Leeds.

The adaptive traffic signals improvements concentrated on linking DRACULA to a BALANCE UTC system that is due to be installed in Leeds and Sheffield. The installed BALANCE system will use the TCP/IP communications protocol to link up its various components. With this in mind a DRACULA interface that also uses TCP/IP has been developed. The improvements in the detector model in DRACULA concentrated on providing the BALANCE system with the on-street information it required. As well as the usual loop detector data this also included both public transport and emergency vehicle location information

1. Roundabouts

DRACULA makes the following assumptions about each roundabout:

• the roundabout is circular,
• the roundabout is modelled as a continuous link, with a given number of lanes, with entry and exit points at positions along it,
• vehicles attempt to travel at a desired circulation speed when on the roundabout,
• the usual car following rule is used on the roundabout,
• a new lane changing rule is used on the roundabout.

The following inputs are required to define the roundabout geometry:

• The roundabout diameter D (defined as the diameter of the circle round the middle of the roundabout, this is equivalent to (IR+ICR) in Figure 1, where IR is the radius of the central island and ICR is the outer radius of the roundabout).

• The desired circulation speed of vehicles travelling around the roundabout (A default value of 7.5 m/s is suggested). When each vehicle is generated it is given a scale factor to use when calculating its desired speed on a link. This scale factor is based on a random selection from a distribution with a given mean and variance. Each vehicle type has a given mean and variance to use.

• Number of lanes on the roundabout.

• Safe gap time for entering roundabout (a default value of 3.0s is suggested). This is the minimum size of gap which must exist before a vehicle will move on to the roundabout. For each vehicle type this can be modified by a scale factor. As with the desired speed this scale factor is based on a random selection from a distribution with a given mean and variance according to the vehicle type.

• Which lanes on each input arm should be used for each exit from the roundabout.

The roundabout model uses three regimes. Firstly on approaching the roundabout vehicles have to get into an appropriate lane. When vehicles arrive at the roundabout they have to determine whether there is a suitable gap to allow them to enter the roundabout. Finally, when travelling on the roundabout vehicles have to choose an appropriate lane to allow them to leave the roundabout at the desired exit. The rules used for each of these regimes are given below in pseudo code.

Approaching roundabout

• Choose lane appropriate to exit
• Reduce speed as if approaching give way junction

Gap search - to move on to roundabout

loop through vehicles on roundabout approaching from right (UK)

   if vehicle NOT exiting at this exit then

      calculate time to arrival at entrance

      if time to arrival > safe gap time then

         move on to roundabout in exit lane

      end if

   end if

until vehicle found OR distance scanned>50m

Movement on roundabout

• Use usual car following rule

• Use new roundabout lane changing rule

if next exit is desired exit and not in outer lane then

   move to outer lane

end if

if lane ahead blocked by queue from non-desired exit then

   move into non-blocked lane

end if

The main additional output is a graphical representation of the roundabout as the program runs. (See Figure 2)

2. Public Transport Services

2.1 Introduction

The main improvements to the Public Transport service models within DRACULA have been:

• a new public transport service model
• a new public transport stop model
• a new reserved lane model
• guided bus operation

The public transport services in the model are described by their:

• service number;
• vehicle type (bus or guided bus);
• service frequency (veh/hr);
• service route which includes:

• Origin zone number
• Destination zone number
• Number of nodes (excluding the zones) en route
• List of nodes en route
• Number of public transport stops en route
• List of public transport-stop identification numbers for all the stops en-route.

Only the departure time of the service (via a fixed hourly service frequency) is modelled. The bus schedule (in terms of route timing points) is not represented in the current version.

The public transport vehicles enter the network at regular service frequency. They follow the pre-defined fixed route through the network as other traffic except when using reserved public transport lanes where provided, stopping at public transport stops for the service.

2.2 Public transport stops

A public transport stop might be used by all or just some of the public transport services (or routes) that go past it. Therefore a method of defining which services use which stops has been devised.

Two types of public service stops are modelled: ordinary bus stops or bus laybys. An ordinary bus-stop is a single sign on the road side and buses stop alongside the sign on the road to pick up or put down passengers, thereby blocking upstream traffic in that lane. A bus-layby, however, provides a space for the bus to pull into at the bus-stop and thus allows following traffic to pass. A bus-layby in the model is represented as a special type of bus-stop.

Each bus stop is defined by the following data:

• A unique public transport stop identifying number
• Upstream node of the link on which the stop lies
• Downstream node of the link on which the stop lies
• Position of the stop, measured from the entry of the link
• Side of the road where the stop lies, 0=curb side, 1=median side
• Type of the stop, 0=ordinary, 1=layby

• Layby length (metre), 0 for ordinary bus stop
• Average pedestrian flow (ped/hr) to the bus stop

There are two elements required to model public transport vehicle motion in the vicinity of public transport stops. Firstly, when approaching the stop, public transport vehicles need to move into the lane where they can access the stop. The public transport vehicles begin to attempt this manoeuvre in the link before the link with the stop. Secondly, if there are passengers waiting at the stop then the public transport vehicle has to stop at the stop for sufficient time to pick up all the passengers. Pseudo code for both these elements is given below.

PT vehicle motion approaching stop

if next link has a stop on it then

   try to move into lane which leads to lane with stop

   if fails then

      move into link

      look for gaps to move into lane with stop

   end if

end if

PT stop dwell time

if a bus is NOT already waiting at a bus stop then

   if number of passengers > 0 then

      stop time = a N + b

   end if

end if

where

N = number of passengers waiting (passengers arrive at the stop at a fixed rate as given in the input section. The stop time is extended if more passengers arrive during the stop.

a = time taken for 1 passenger to board (4s default).

b = time for doors to open and close (5s default).

2.3 Reserved lanes

The lane reservation in the model is specified by:

• the link identification;
• location on the link (near or offside lane);
• type(s) of vehicles reserved for the lane;
• "set backs" at the beginning and end of the link;
• start and end time of the reservation, measured from the start of the simulation.

The following pseudo code describes the movement of public transport vehicles as they approach and move into a reserved lane.

if a reserved public transport lane is in the next link then

   try to change to the lane in the current link which leads to the reserved lane

   if failed to change lane then

      stay in lane until the next link

   end if

end if

Once in the link with the reserved lane the following logic applies

if there is a reserved public transport lane in the current link then

   try and move into the reserved lane

end if

if the reserved lane permits the public transport vehicle's next turn then

   stay in the reserved lane

else

   move off the reserved lane into a lane that allows the turn, when near the junction

end if

2.4 Guided bus operation

Guided buses are represented in the model as a distinct type of vehicle. The distinction is made both in terms of vehicle characteristics and the traffic regulations governing their movement on the streets.

The guideway is represented as separate links, dedicated to the guided-bus vehicle type. The guideway can only be entered at the start of the link and exited at the end, unlike reserved lanes (see above).

The operational distinction between a guideway and a reserved lane which this implementation incorporates is that a bus may join the guideway only at dedicated points on the route whilst a bus may "drift" into and out of a reserved lane anywhere along its extent. A lane can be specified as reserved for one particular type of vehicle or a combination of vehicle types.

2.5 Outputs

Additional outputs include the public transport service route specified summary statistics, which include the total travel time, distance, average speed, fuel consumption, pollutant emissions for the service route. As the user’s request, each public transport service vehicle’s link-by-link travel times are also output.

3. Adaptive Traffic Signals

It is becoming increasingly common to link micro-simulation models to real urban traffic control (UTC) systems and to then let the two systems interact. The UTC systems can obtain data from the simulated network, such as vehicle detections, and use this information to perform control actions in the simulated network. This approach has considerable merits. It negates the need to produce a model to replicate the effects of the UTC system. It also allows accurate simulations to be performed without the modeller having to know precise details of the how the UTC system works. This can avoid commercially sensitive information having to be revealed to the modeller.

Within the SMARTEST project DRACULA has been linked to the BALANCE UTC system. BALANCE (Friedrich et.al., 1995, Toomey et.al., 1998) is a distributed UTC system which has been developed at the Technical University of Munich. It underwent field trials in Munich within the EC funded DGXIII LLAMD project, and has since been tested in three other European cities, namely London, Glasgow and Belfast. It is due to be used in Leeds and Sheffield in the near future.

Within a BALANCE system, decisions about signal settings at individual junctions are made by Micro-BALANCE outstations at each junction. Strategic control decisions at the network level, which can override or weight decisions at the junction level, are made by a centralised Macro BALANCE computer. BALANCE uses standard TCP/IP communications protocols to communicate with signal controllers on-street and between its system components.

An interface between DRACULA and BALANCE was therefore developed which used the same TCP/IP communication protocols as used by the BALANCE system on-street. The interface was tested by simulating the operation of a single junction, namely the A30/Stanwell Road junction in South West London.

By using a multi-tasking operating system, such as Windows 95/98/NT, it is possible to run all the micro-BALANCE tasks on a single computer, if required, rather than use a separate computer for each one, as would be the case in the real world. A flexible approach was developed in the project to allow the micro and macro BALANCE tasks to be spread across a computer network as available. Similarly it should be possible to treat DRACULA as just another task and run it on any of the PCs in the computer network. In practice this caused problems if DRACULA and all the BALANCE tasks were chosen to run on a single computer. It proved difficult to display the animated graphical outputs of DRACULA simultaneously with the outputs from BALANCE. A further problem was encountered when considering how to link the standard communications routines used by BALANCE into DRACULA. The DRACULA software is currently DOS based and is incompatible with the Windows based communications routines. It therefore proved impossible to link the communications routines with DRACULA directly. This problem was overcome by writing a small Windows program, called SPRUCE, to handle the communications, which was run every simulation step within DRACULA.

The design for linking DRACULA to BALANCE was based around a further INTERFACE task, which sat between DRACULA and the BALANCE tasks. The INTERFACE task acted as a server. It handled communications between all the tasks, ensured all the tasks were synchronised, and translated all the data going between the tasks into the required formats. The INTERFACE task also performed some of the duties normally carried out by on-street signal controllers, such as checking that minimum green periods had elapsed before changing signal phases.

DRACULA required the signal settings to be input every second. This was provided as a list of the current signal aspects (Red, Amber or Green) for all the possible turns at the signalised junction.

The INTERFACE program received detector data from SPRUCE / DRACULA and signal force bits from BALANCE. The force bits simply specify which stage is to be run next.

BALANCE received detector data bits from the INTERFACE program. The detector data was in the format of SCOOT nibbles (see Section 5).

The initial proposal required that DRACULA should communicate with BALANCE via an INTERFACE program. This interface is based on a function that would need to be used by BALANCE to send out signal settings and receive detector data. This function was written using Microsoft Visual C++ and used TCP/IP communications protocols. It was supplied via a DLL called ChatDll.dll and contained the exportable function 'XDataOnTCPIP' which takes four arguments as shown below

int XDataOnTCPIP(char* RemoteIP, int RemotePort, char* Msg2Send, char* Msg2Take);

This function just uses TCP/IP to send and/or receive message strings between two computers on a network. The function was to be called every second, by DRACULA, BALANCE and the INTERFACE program to transfer data between them.

To use the function it required:

i) BALANCE to be adapted to use the interface function

ii) the translation of the data going to (detector bits) and from (force bits) BALANCE into something DRACULA could understand. This was performed by the INTERFACE program.

As mentioned above, it proved impossible to incorporate the XDataOnTCPIP function directly within DRACULA. Instead a simple program called SPRUCE.EXE was written which did incorporate the function. This program was run at each simulation step by DRACULA using the standard system function. At each simulation step, DRACULA would write detector data to a file called network.ddd and read signal settings from a file called network.bbb. The SPRUCE program would then be called and it would read the data in the network.ddd file and transmit it to the INTERFACE program and receive the signal settings back from the INTERFACE program at the same time. SPRUCE would then write the signal settings to the network.bbb file. (see Figure 3)

The INTERFACE program performed the following functions:

• Translation of the BALANCE force bits into appropriate signal settings.
• Translation of the DRACULA detector data into the stream of detector bits required by BALANCE

• Synchronisation of the tasks

BALANCE uses the detector data it receives to optimise the signal settings. The detector bits are received and the signal force bits transmitted using the XDataOnTCPIP function.

Every second, DRACULA produced a list of SCOOT nibbles for all of the detectors in the network.

Every second the INTERFACE program sends detector bits to BALANCE and signal aspects to DRACULA.

Every second BALANCE outputs stage force bits messages, which are full 16-bit UTC control bit patterns, but only using the stage force bits. To cater for the multiple node architecture an item was added to the message to define which controller the following control bits relate to as in the following table:-

A single four arm junction is SW London was used to test the operation of the DRACULA / BALANCE interface.

4. Public Transport Priority

Apart from providing public transport with special reserved lanes, public transport is also given priority at signalised intersections. When a public transport vehicle is detected at time t₀ and predicted to arrive at the stopline at time t_a, one of two actions may be performed:

• Extension, which extends the bus green period in order to allow the bus to exit;

• Recall, which terminates the bus red stage earlier in order to reduce the bus waiting time.

Public transport signal priority requires the modelling of selective vehicle detectors (selected to detect public transport vehicles only) and use of a simulation control parameter to switch the priority scheme on.

Figure 4 shows schematically the signal priority in a space-time diagram. The signals for the bus link are shown on the top, with t_r and t_ra representing the start and end time of the red aspect. ra denotes red/amber. t_ext=t_r+E_max, where E_max is the user specified maximum allowed extension (in second). The distance from the detector to the stopline is d. Three bus trajectories from the detector to the stopline are drawn in dashed lines.

If a bus is predicted to arrive at the stopline just after the start of the red signal (case B in Figure 4), the bus green aspect will be extended by just enough time to allow the bus to exit. The amount extended depends on the predicted bus arrival time, subject to a user-defined maximum (E_max) and to minimum greens for the subsequent stages affected.

If a bus is predicted to arrive during the red, but an extension is not appropriate (i.e. requires more than the maximum permitted extension, case C above), then the duration of the bus red aspect may be reduced by a constant amount of 5 seconds. The length of other stages remains unchanged, so the length of the current cycle is decreased temporarily.

Otherwise the signals will not be changed (case A in Figure 4).

5. Detectors

Detectors in DRACULA have been modified to allow them to output the data produced by SCOOT detectors, which are common in the UK. The data consists of quarter second occupancy bits which are sent out every second as blocks of four bits.

Each detector in the network is defined by the following data:

• A unique integer identifier
• An 8 bit bit-mask to identify which of the eight DRACULA vehicle types the detector can detect
• Upstream node of the link on which the detector lies
• Downstream node of the link on which the detector lies
• Position of the detector on the link
• The lane in which the detector lies

The front and rear ends of a vehicle are compared to the location of a detector in the current lane the vehicle is travelling in, a detection is triggered if a vehicle passed or is stopped on a detector. The exact timing, in quarter second intervals, when the vehicle passed the detector is extrapolated based on the current speed the vehicle. This is because the simulation time increment is one second.

At every simulation time step the program loops through all detectors in the network and outputs all detections. The detector data is in the form of SCOOT nibbles. This is quarter second occupancy data which is sent every second. For each detector four bits of information are sent every second. The information is passed using bytes (i.e. 8 bits), so two detectors worth of data are sent with each byte. The SCOOT nibbles are created left to right, so the leftmost bit is for the first quarter second, the rightmost bit for the last quarter second.

6. Traffic Calming

Traffic calming is represented as a special speed-controlled region in a link.

A traffic calming region is specified by:

• Upstream node of the link the traffic calming region locates
• Downstream node of the link
• Starting position of the region, measured from the link entry
• End position of the region, measured from either the link entry to from the stopline;
• Maximum speed over the region.

When approaching a traffic calming region:

if the current speed is more than the maximum speed of the region, then

   Decelerate at a normal deceleration to the maximum speed of the region

else

   Move at the car-following speed

end if

7. References

Friedrich, B., Sachse, T., Hoops, M., Jendryschik, W. and Reichert, G. (1995) "BALANCE and VARIA Methods for Traffic Adaptive Control", Proceedings of the Second World Congress on Intelligent Transportation Systems, Yokohama, Nov 9th-11th 1995, pp 2356-61.

Toomey, C., Clark, M. and Friedrich, B. (1998) "Tipping the BALANCE: A European Trial of Advanced UTC", Traffic Technology International, Dec 97/Jan 98, pp51-54.

Enhancement of the NEMIS micro-simulation model features

Gianni Canepari and Carlo Di Taranto

Mizar Automazione SpA, Via Vincenzo Monti, Torino, Italy

e-mail: GianniCanepari@miz.it

Abstract

Micro-simulation models are becoming an increasingly important tool for traffic control research and development. They permit the traffic engineer to have a "bird’s eye" view of the traffic in an urban area and an instant feel for current congestion problems and possible solutions. Controversial or new techniques can be tried and tested without any disruption to traffic in the real network.

As more complicated traffic control methods and systems are developed, the problem of testing and calibration becomes more and more acute. On-street evaluation is notoriously difficult for two reasons:

1. the day to day variability of traffic
2. the difficulty and expense of collecting enough data to arrive at a certain result.

NEMIS was designed as a specific solution to the problem of on-street testing. Its ability to model urban networks in microscopic detail (individual vehicles, single intersections or road sections etc.) makes it a valuable tool for testing traffic control strategies or techniques at local and area levels.

NEMIS is a scientific software package and, since its creation, it has been used principally for research and development work and for the technical assessment of traffic control strategies.

NEMIS has been developed for the micro-simulation of urban traffic (private and public) in large scale networks. It is capable of modelling urban networks and vehicle behaviour in considerable detail, and is well structured to meet a variety of application needs. Its usefulness has been demonstrated for the following tasks:

• analysis of the effects of regulation and network modification on traffic mobility
• evaluation of different traffic light control strategies
• testing of traffic assignment techniques
• simulation and evaluation of route guidance strategies and variable message systems.

Other areas where NEMIS may be used include:

• evaluating the effects of improved public transport facilities on inner city traffic flow
• testing the effectiveness of parking management systems
• examination of strategies aimed at reducing fuel consumption/exhaust emission.

1. Development history

The combination of a detailed network topology and the ability to track the progress of each vehicle through the network accounts for the effectiveness of NEMIS as a powerful simulation tool. Its accuracy has been verified through field trials and its application to large-scale projects in traffic control.

Like all useful systems, it has evolved over the years to meet changes in the urban environment and user requirements. The following is provided as a short history of its development:

1974-1976: The NEMIS basic modules were developed by a team of researcher at IENGF (Istituto Elettronico Nazionale "Galileo Ferraris") in Turin. Some of the team became part of the R + D staff at MIZAR Automazione S.p.A. and completed and upgraded the package.

1977: Analysis using NEMIS of the effects on urban traffic of regulation and network modifications in the central area of Turin.

1978: Analysis using NEMIS of the effects on urban traffic of regulation and network modifications in the entire urban network area of Alessandria, Italy.

1978-1980: Feasibility analysis of the "Progetto Torino" system. The latter is an innovative hierarchical and decentralised traffic control system operating in Turin. NEMIS was used to evaluate traffic light control strategies.

1988: The NEMIS package was made portable by transferring it from a UNIVAC mainframe onto IBM PS/2.

1990: Evaluation of a decentralised control strategy to support route guidance. This study required modification of NEMIS in order to simulate beacons and floating-cars.

1990: Evaluation by the Institute of Transport Studies, Leeds, UK of a control strategy to reduce blocking back during oversaturation.

Current research at MIZAR requires the use of NEMIS to evaluate local control strategies.

2. Key Developments within SMARTEST

Within the framework of SMARTEST some important enhancements have been introduced in NEMIS.

The main efforts have been spent to provide NEMIS with an improved and standardised interface suitable for the real time simulation of the following external Transport Telematic Applications:

• Adaptive Traffic Signals
• Public Transport Priority
• Variable Message Signs
• Dynamic Route Guidance

The new interface has been based on a standard TCP/IP communication protocol, which helps to connect the computer where the model runs to the network of computers where the external strategies operate.

Furthermore, two models have been improved:

• Public Transport Services
• Vehicle Detectors

All the enhancements have been implemented taking care of transferability aspects and have been tested onto specific cases gathered in the Torino test site.

In particular:

• Public Transport Services model has been enhanced with the introduction of a lay-by PT stops.
• Vehicle detector improvement concerned performance, error rate and breakdown occurrence.
• The validation of the standard interface concerns mainly operational aspects.

In the following sections attention is paid to the new standard interface solely, which represents the main objective of the developments. Description of the developments is provided making reference to the application that resulted more complex: interfacing of Adaptive Traffic Control and Public Transport Priority strategies to the NEMIS model.

3. The New Interface

The calibration and setting up of UTC system on field can be extremely time-consuming and difficult unless intensive off-line tests are performed in a controlled environment.

The NEMIS software package was designed specifically as a tool for testing urban traffic control strategies prior to or in parallel with on-street testing.

NEMIS already supported an interface with external road-side processors (e.g. SPOT or SCOOT OTU) to test the effectiveness of urban traffic control systems as well as to screen strategies and tune system parameters before field installation.

The old interface communication protocol operates using several serial connection (RS232) between the NEMIS computer, the MS-DOS PC where the interface package runs and the real system. This solution presents the following limits:

• limited communication capabilities (limited speed of serial connections)
• non-standard communication protocol (proprietary protocol "ad hoc" to interface NEMIS with SPOT and SCOOT)
• limited simulation capabilities (dedicated hardware is needed for the intersection controller)

The new interface overcomes these limits using a standard protocol based on TCP/IP in order to connect NEMIS with a LAN/WAN where the intersection controllers implementing external Traffic Control Strategies (e.g. MFOs SPOT) operate.

The new NEMIS interface provides users with a simplified and high efficiency micro-simulator suitable to investigate the impact of Advanced Transport Telematics functions (adaptive and co-ordinated traffic signals, public transport priority, VMS and Dynamic Route Guidance) on big road networks.

The main objective (as shown in Figure 2) was to have a new interface based on standard communication protocol TCP/IP and suitable to directly interface NEMIS with several external control strategies embedded in the UTOPIA SPOT units. In fact, the new interface is able to manage messages written directly in the UTOPIA format.

Anyway, it is also possible to use NEMIS in order to test any "ad-hoc developed" external control strategy. If this is the case, the external control strategy developed needs to exchange appropriated messages with NEMIS using for each message the proposed format.

Starting from the physical approach shown in figure 2 the new interface has been developed following the architecture proposed in figure 3.

The new interface approach developed for NEMIS is based on the following components:

The operation of the new interface can be easily described by means of the following steps:

• The TCP MANAGER receives from the external control functions that reside within SPOT units or within others users developed packages, all the messages containing the elaborated control strategy. The communications between the TCP MANAGER and the external control functions are based on TCP/IP standard protocol.
• When a new message is received by TCP MANAGER, the message itself is processed and then written onto the appropriated file into the Log File System.
• The TCP MANAGER also reads the circular files HIPRY and LOPRY (two command files that belong to the Log File System - see following sections) where NEMIS writes the messages required by the external control functions.
• When a new message is written by NEMIS onto a command file of the Log File System, the TCP MANAGER, processes the message and then send it out towards the appropriated SPOT unit or to the appropriated external control function.

The flow chart in figure 4 shows in schematic way, the operation of the TCP MANAGER two main tasks and the interaction existing between NEMIS, the TCP MANAGER and the whole simulation network.

The messages are written onto the Log File System using the LFS management functions provided together with the interface package. The same LFS management functions have to be used also to read the messages previously written onto the Log File System by NEMIS itself and/or by any other external operating tools.

Comparing the new interface to the old one, we can underline the following advantages:

• it uses a standard communication protocol
• the communication speed is limited only by the communication network features (rates greater then 10Mb/s can be achieved using optical fibre)
• the simulation does not need a dedicated hardware (a standard PC network can be used)

The new interface is described in more details in the following section.

4. Adaptive Traffic Signals and Public Transport Priority

4.1 Introduction

Adaptive control strategies for private traffic and public transport priority services, are surely the basic aspects of the main systems operating in urban traffic control area.

Taking care of the growing interest showed by users for micro-simulator application related to the capabilities to simulate the main telematic functions for traffic management, it comes that new millennium micro-simulators must provide users with all the instruments needed for the simulation of these fundamental aspects.

It also clearly appears that state of the art technology proposed for the implementation of adaptive control and public transport priority strategies, as the control strategies themselves, are far from being standardised.

Hence, together with the need of micro-simulators able to investigate adaptive control and public transport priority strategies performance, grows the necessity to keep externally to the micro-simulator itself all the software module implementing the control strategies.

From this consideration the idea was born to provide users of the NEMIS micro-simulator with a tool able to interface, directly and in a easy way, the external control strategies embedded in the SPOT unit (local multifunctional unit of the UTOPIA UTC system). The approach adopted provides to the micro-simulator NEMIS the capability and the tools necessary to evaluate the impact of particular adaptive control and public transport priority strategies (those implemented by UTOPIA) without prevent the simulation of control strategies ad-hoc developed by the user itself.

In the following a brief introduction to the UTOPIA integrated system and to the adaptive control and public transport priority strategies implemented by the SPOT peripheral units at the intersection level is provided.

4.2 Some notes about the UTOPIA UTC system

UTOPIA (Urban Traffic Optimisation by Integrated Automation) is a specific concept designed to improve urban travel conditions by the application of fully automated control principles. The concept is based on a particular system architecture and particular control strategies. It was originally conceived to provide an innovative response to two fundamental requirements of wide-area traffic control systems:

• significant improvements in private vehicle mobility in all traffic conditions
• the assignment of absolute priority to selected public transport vehicles at traffic light intersections

UTOPIA control strategies aim to reduce significantly the total time lost by private vehicles during their trips within the controlled area, subject to the constraint that public vehicles requiring priority shall not be stopped at intersections with traffic lights.

Field trials have shown that systems based on the UTOPIA concept can meet both the above requirements simultaneously.

The UTOPIA architecture is hierarchical and decentralised: optimal control strategies are determined at the higher level on the basis of area traffic prediction, while traffic light control is actuated at the lower level according to the actual traffic conditions encountered at the intersections.

UTOPIA control strategies overcome the unmanageable complexity of the area optimal control problem by a process of decomposition into several simpler, interrelated sub-problems. Control problem decomposition, the choice of suitable functionals for the resulting sub-problems and the introduction of rules for sub-problem interrelation permit both a hierarchical and decentralised architectural solution to the original control problem and provide control actuation that is really close to optimum. Decomposition is performed by following a topological rule: firstly, the area is subdivided into ‘overlapping’ zones, where each zone is logically centred on a controlled intersection and includes neighbouring intersections. Then an optimal control problem is defined for each zone.

The zone control problem concerns the traffic control to be actuated at the central intersection only, but it provides a consistent interrelation with the control of the neighbouring intersections and takes into account traffic information and traffic control data concerning the whole zone. The functional to be optimised consists of the terms relating to the traffic observed on the incoming link of the central intersection and those which implement the following two fundamental interaction principles:

• a strong interaction principle is implemented by taking into account the time lost at the downstream intersections by vehicles leaving the central one;
• a look-ahead principle is implemented by taking into account traffic forecasts defined on the whole optimisation horizon (120 sec) for all the central intersection’s incoming links.

In order to guarantee stability and robustness at the network level, interactions are provided with a higher level, where an area optimal control problem is defined on the basis of the area traffic macroscopic model.

The final result is a series of problems which can be classified as belonging to two different classes: the ‘intersection level’ and the ‘area level’. At both levels the problem formulation is based on the definition of two fundamental modules: the state observer and the controller.

Control problems are solved by a network of interconnected control units which apply suitable Open Loop Feedback Optimal (OLFO) techniques.

Step back to the new interface approach, it is based onto the following issue:

4.3 Processing

From the point of view of the NEMIS model adaptive control and P.T. priority are external strategies, that is tasks embedded within the local unit SPOT of the UTOPIA System.

In this section a description of the new interface is provided that allows users to implement the information exchange between the external modules where the control strategies reside and the micro simulator NEMIS

This section contains the following four subsections:

• The Circular files
• The exchanged messages and their format
• The Log File System Management Library
• The simulation process

4.5 The circular files

Figure 5 describes the interface between the SPOT units (unit where the software module that implement the external adaptive control and public transport priority strategies resides) and NEMIS.

The communication take place by means of messages logged by the TCP Manager onto a set of circular files: the Log File System. The term circular files is referred to a set of logical structures that allow sequential accesses, in which the first record logically follows the last one. Circular files are used to storage into each record the messages that are exchanged between the various elements of the whole simulation system, that are all the messages produced by NEMIS, by the SPOT units and by possible other running tools of the UTOPIA system (users interface tools).

Within the circular files, records are sorted on the basis of logged messages date and time.

Figure 6: Circular file elements

Within the Log File System, NEMIS and the TCP manager exchange information using the three following circular files:

The exchanged messages and their format

The messages required to implement the simulation of adaptive control and public transport priority strategies are the following:

• MESSAGE 78: PUBLIC TRANSPORT FORECASTS (for P.T. PRIORITY)

• MESSAGE 93: PRIVATE TRAFFIC DETECTORS (for ADAPTIVE TRAFFIC SIGNALS)

• MESSAGE 91: STAGE PLANNED (for ADAPTIVE TRAFFIC SIGNALS / P.T.PRIORITY)

• MESSAGE 111: SYNCHRONISATION MESSAGE (for ADAPTIVE TRAFFIC SIGNALS)

All the messages in UTOPIA format are preceded by a 4 byte header that contains the following information:

Many run-time messages contains, after the header of the message itself, the send time of the message on 3 bytes. This time is expressed in seconds by midnight.

If there are no different indications (message 93) the time bytes are ordered as follows:

LSB - MSB - MSB.

Figure 7 summarises the concept expressed above.

4.6 The Log File System Management Library

The Log File System LIBrary manages the Log File System files.
When a message has to be logged on a file of the Log File System, the function of the LFS LIBrary control the consistency of the recording date and time.

The system date / time variation are also managed by the library in order to avoid Log files corruption.

The main function of the LFS LIBrary are the following:

• LFSOpen
• LFSClose
• LFSLock
• LFSUnLock
• LFSInfo
• LFSRead
• LFSWrite

4.7 The Simulation Process

The flow chart of Figure 8 shows in a schematic way, the operation of the TCP MANAGER two main tasks and the interaction existing between NEMIS, the TCP MANAGER and the whole simulation network.

The communication between the TCP MANAGER and NEMIS, can be summarised through the following steps:

• The TCP MANAGER receives from the external control functions that reside within SPOT units or within others users developed packages, all the messages containing the elaborated control strategy (Message 91).
• The communications between the TCP MANAGER and the external control functions are based on TCP/IP standard protocol.
• When a new message is received by TCP MANAGER, the message itself is processed and then written onto the appropriated file into the Log File System.
• The TCP MANAGER also reads the circular files HIPRY and LOPRY where NEMIS write the messages needed by the external control functions (Messages 78 and 93).
• When a new message is written by NEMIS onto a command file of the Log File System, the TCP MANAGER, processes the message and then send it out towards the appropriated SPOT unit or to the appropriated external control function.

Figure 9 shows a screen-shot of the TCP Manager user interface.

The way in which the simulation process changes when NEMIS is linked with external control strategies can be described as follows:

1. NEMIS simulates the three seconds and then:

• prepares the messages 93 (traffic counts for external adaptive control strategy)
• prepares the messages 78 (P.T. vehicle forecasts for external P.T. priority strategy)

2. NEMIS writes onto the Log File System the messages previously prepared

• all the messages 93 are written onto "LOPRY." file
• all the messages 78 are written onto "HIPRY." file

3. At the end of the simulation period, NEMIS read the circular file "LOGIN." starting from the last message read and looking for messages 91 coming from the SPOT local units and for message 111 coming from the TCP Manager.
4. When a message 91 is detected the SEM6 matrix (containing the traffic light information) is updated with the new planned plan information.
5. When a message 111 is found, the new simulation period (that lasts three seconds) starts and the simulation process returns to the step 2.

Figure 10 shows a flow chart for the simulation process.

The SITRA-B+ Microscopic Traffic Simulation Model - Examples of Use and Future Developments