Microscopic Traffic Flow Simulator VISSIM

Chapter
Part of the International Series in Operations Research & Management Science book series (ISOR, volume 145)

Abstract

After two decades of academic research the microscopic, behavior-based multi-purpose traffic flow simulator VISSIM had been introduced in 1994 to analyze and optimize traffic flows. It offers a wide variety of urban and highway applications, integrating public and private transportation. A large part of this chapter is devoted to modeling principles of VISSIM, core traffic flow models consisting of longitudinal and lateral movements of vehicles on multilane streets, a conflict resolution model at areas with overlapping trajectories, dynamic assignment and the social force model applied to pedestrians. Techniques to calibrate the core traffic flow models are discussed briefly.

Traffic simulation is an indispensable instrument for transport planners and traffic engineers. VISSIM is a microscopic, behavior-based multi-purpose traffic simulation to analyze and optimize traffic flows. It offers a wide variety of urban and highway applications, integrating public and private transportation. Complex traffic conditions are visualized in high level of detail supported by realistic traffic models. This chapter starts with a review of typical applications and is followed by modeling principles presenting the overall architecture of the simulator. The Section 2.3 is devoted to core traffic flow models consisting of longitudinal and lateral movements of vehicles on multi-lane streets, a conflict resolution model at areas with overlapping trajectories and the social force model applied to pedestrians. The routing of vehicles and dynamic assignment will be described thereafter. Section 2.5 will present some techniques to calibrate the core traffic flow models. This chapter closes with remarks of interfacing VISSIM with other tools.

2.1 History and Applications of VISSIM

This section will familiarize you with some typical and some rather extraordinary studies being conducted by applying VISSIM. The examples presented will give you a flavor of the functionality and versatility of this microscopic traffic flow model embedded within a graphical user interface enabling traffic engineers without dedicated computer knowledge to set up microscopic traffic flow models.

VISSIM is a commercial software tool with about 7000 licenses distributed worldwide in the last 15 years. About one-third of the users are within consultancies and industry, one-third within public agencies, and the remaining third is applied at academic institutions for teaching and research. Primarily the software is suited for traffic engineers. However, as transport planning is looking toward a greater level of detail, an increasing number of transport planners use microsimulation as well.

VISSIM has a long lasting history; major steps within the development are presented in Table 2.1.
Table 2.1

Major steps of the development of VISSIM

Wiedemann (1974)

Secondary PhD thesis presenting the psycho-physical car-following model which describes the movement of vehicles on a single lane without exits

1978–1983

Several research projects at the university of Karlsruhe conducting measurements and model developments of particular pieces of vehicular movements. In particular Sparmann (1978) described lane changes on two-lane motorways, Winzer (1980) measured desired speeds on German motorways, Brannolte (1980) looked at traffic flow at gradients, and Busch and Leutzbach (1983) investigated lane-changing maneuvers on three-lane motorways

Hubschneider (1983)

PhD thesis on the development of a simulation environment to model vehicles on multi-lane streets and across signalized and non-signalized intersections. The model being called MISSION was implemented using SIMULA-67 and compiled on mainframe computer UNIVAC 1108

1983–1991

Research projects at the University of Karlsruhe applying MISSION for various studies on capacity and safety. Major applications contain noise (Haas, 1985) and emission (Benz, 1985) calculations, while Wiedemann and Schnittger (1990) looked at the impact of safety regulations on traffic flow. During that time MISSION had been installed under MS-DOS after reimplementation using PASCAL and MODULA-2

1990–1994

Wiedemann and Reiter (Reiter, 1994) recalibrated the original car-following model using an instrumented vehicle to measure the action points

Fellendorf (1994)

First commercial version of VISSIM in German aimed for capacity analysis at signalized intersections with actuated control. Graphical network editing, vehicle animation, and background maps were available from start on. The software was implemented in C running under MS-Windows 3.1

1994–1997

Rapid developments included definition of routes, further public transport modeling, modeling of priority intersections, and interfaces to various signal controller firmware

1998

Additional traffic flow model reducing the complexity of the original traffic flow model, which is better suited to calibrate traffic conditions on dense motorways. Further graphical enhancements like 3D-visualization

2000

Introduction of dynamic assignment as applications become larger and definition of routes are too time consuming

2003

COM interface providing users a standardized application programming interface to develop specific user applications with VISSIM in the background

2004

Interface between the strategic demand model VISUM and VISSIM to generate applications based on the same network geometry and traffic flow data

2006

Introduction of an implementation using multi-processor and distributed PC clusters for parallel processing to decrease computational time for large networks

2007

Anticipated driving at conflict areas

2008

Pedestrian modeling based on Helbing and Molnár (1995) social force model

VISSIM is a microscopic, discrete traffic simulation system modeling motorway traffic as well as urban traffic operations. Based on several mathematical models described in Chapter 3, the position of each vehicle is recalculated every 0.1–1 s. The system can be used to investigate private and public transport as well as in particular pedestrian movements. Traffic engineers and transport planners assemble applications by selecting appropriate objects from a variety of primary building blocks. In order to simulate multi-modal traffic flows, technical features of pedestrians, bicyclists, motorcycles, cars, trucks, buses, trams, light (LRT), and heavy rail are provided with options of customization. Common applications include the following:
  • Corridor studies on heavily utilized motorways to identify system performance, bottlenecks, and potentials of improvement.

  • Advanced motorway studies including control issues like contra-flow systems, variable speed limits, ramp metering, and route guidance.

  • Development and analysis of management strategies on motorways including mainline operation and operational impacts during phases of construction.

  • Corridor studies on arterials with signalized and non-signalized intersections.

  • Analysis of alternative actuated and adaptive signal control strategies in subarea networks. Tools suited for traffic control optimization such as Linsig, P2, Synchro, or Transyt optimize cycle times and green splits for fixed-time control, while signal controllers in many countries are operated in a traffic responsive mode. Microsimulation is widely used for detailed testing of control logics and performance analysis.

  • Signal priority schemes for public transport within multi-modal studies. Traffic circulation, public transport operations, pedestrian crossings, and bicycle facilities are modeled for various layouts of the street network and different options of vehicle detection.

  • Alignment of public transport lines with various types of vehicles such as Light Rail Transit (LRT), trams, and buses with refinements in design and operational strategy. This also includes operation and capacity analysis of tram and bus terminals.

  • Investigations on traffic calming schemes including detailed studies on speeds during maneuvers with limited visibility.

  • Presentation of alternative options of traffic operations on motorways and urban environments for public hearings.

2.2 Model Building Principles

For clarity the following definitions will be made. A microscopic traffic flow simulator such as VISSIM contains the software including the mathematical models to run traffic flow models. The simulator itself does not include any application-specific data or additional tools which are required for additional modeling and data analysis tasks. Additional software tools are sometimes required for data analysis such as statistical packages, proprietary external traffic control software, or post-processing such as emission calculations. These additional tools are not part of the simulator itself. A microscopic traffic modelingapplication contains all data to run a VISSIM model without the simulator itself. In order to operate an application, a modeling system is required. The microscopic modelingsystem comprises the simulator, all additional tools needed to operate an application and the data of a particular application.

The VISSIM software is implemented in C++ considering guidelines of object-oriented programming (OOP). Actually the OOP concept has first been introduced using ship simulation. The academic implementation and predecessor of VISSIM, MISSION of the University of Karlsruhe, was implemented using SIMULA-67 featuring classes of objects, virtual methods, and coroutines. VISSIM provides classes of objects such as vehicles. Within a class the properties of each object are characterized by attribute values and methods describing the functions each object can manage.

2.2.1 System Architecture

In any traffic simulator a mathematical model is needed to represent the transportation supply system simulating the technical and organizational aspects of the physical transportation supply. Second a demand model has to be generated to model the demand of persons and vehicles traveling on the supply system. Unlike macroscopic transport models, traffic control has to be modeled very detailed depending on supply and demand. Therefore the simulator contains three major building blocks plus one additional block generating the results of each simulation exercise.

The road and railway infrastructure including sign posts and parking facilities compose the first block. This block is needed to model the physical roads and tracks. Public transport stops and parking lots are needed as starting (origin) and ending (destination) points of trips. Since these are some physical and stationary network elements, they are also part of the first block. Finally fixed elements such as sign posts and detectors located on the road and railway infrastructure are also considered to be part of the infrastructure block.

The technical features of a vehicle and specifications of traffic flows are made in the second block. Traffic is either defined by origin–destination matrices or by generating traffic at link entries. The assignment model and path flow descriptions are part of this block. Public transport lines are defined within this block as sequence of links and stops.

The traffic control block contains all elements required to control the traffic. Non-grade-separated intersections are controlled by rules to be defined in this block. Definitions for four-way stops, major/minor priority rules with gap acceptance, and control options of traffic signals are made within this block. Although a signal post with signal heads is belonging to the infrastructure block, the signalization itself including definitions about signal settings and actuated control belongs to the traffic control block.

All three blocks depend on each other indicated by arrows in Fig. 2.1. While running a traffic flow simulation vehicles (block 2) may activate detectors (block 1) which will influence vehicle-actuated signal control (block 3); thus during the simulation all three blocks are constantly activated with interdependencies between each block.
Fig. 2.1

Schematic representation of four building blocks

The situation is slightly different with the fourth block, which takes care of all kinds of data output. The evaluation block processes data provided by the first three blocks without a feedback loop. Output may be generated during the simulation either as animated vehicles and states of traffic control or as statistical data on detector calls and vehicle states presented in dialogue boxes. Most measures of performance (MOEs) are generated during the simulation, kept in storage and filed at the end of each simulation.

In the following sections, the classes of each block along with major attributes and features will be listed.

2.2.2 Infrastructure Modeling

The level of detail required for replicating the modeled roadway infrastructure depends on the purpose of a VISSIM application. While a rough outline of the analyzed intersection is sufficient for testing traffic-actuated signal logic, a more detailed model is required for simulation analyses. For the purpose of simulating traffic operations, it is necessary to replicate the modeled infrastructure network to scale. Scaled networks are imported from macroscopic transport planning and GIS software, signal optimization software, or manually traced based on scaled orthorectified aerial photographs and CAD drawings. The road and railway infrastructure is modeled by distinctive elements called classes; the most important ones are described in the following section.

2.2.2.1 Links and Connectors

Roadway networks are usually represented by graphs with nodes located at intersections and links placed on road segments. Nodes are needed if (a) two or more links merge, (b) links cross each other, (c) one link splits into two or more links, and (d) the characteristics of a road segment change. For the purpose of additional flexibility VISSIM does not require an explicit definition of nodes. However, the functionality of merging, crossing, and splitting is modeled by connectors to tie two links. Connectors will always connect pair wise; thus merging from one to three links will require three connectors.

Each link has certain mandatory and some optional properties describing the characteristic of the road or railway. The mandatory properties contain a unique identification, the planar coordinates of its alignment, number of lanes with lane widths, and the type of vehicles suited for the link. Optional properties are required for less standard simulation tasks such as z-coordinates for gradient sections, cost values for tolling sections, and particular driving behavior settings such as mixed traffic or banned lane usage for particular vehicles such as banned overtaking by trucks.

If the properties of a link do not change a link may continue for several road segments. In Fig. 2.2 an entry merges with a three-lane motorway. In order to allow continuous merging from the acceleration lane onto the motorway the three-lane link ends at the merging area and a four-lane link is tied to the previous motorway section and the on-ramp. Behind the merging an off-ramp occurs without an additional deceleration zone. Since the properties of the three-lane motorway do not change, the off-ramp may divert without splitting the modeled motorway at the point of diversion.
Fig. 2.2

Links and connectors modeling merging and diversion of roadways

Connectors tie links based on lanes. Lane allocation and the visibility distance are important mandatory properties of a connector influencing the lane selection of vehicles. In order to fit the alignment of turning movements, the geographical shape of links and connectors can be aligned according to Bezier curves.

2.2.2.2 Other Network Elements

Links and connectors are the basic building block needed to add other infrastructural objects. There are classes of spot objects and others with a spatial extension. The location of each object relates to a particular lane; thus objects relevant to full cross section must be copied for each lane. Spatial objects can only be extended on one link. A spot object does not have a physical length and has to be located at one particular point (coordinate) on a lane. Typical spot objects are as follows:
  • Speed limit sign: As a vehicle passes this sign its desired speed will be adjusted according to the posted speed.

  • Yield and stop signs: These signs identify the position vehicles of minor movements and will wait for major movements to pass.

  • Signal head: A signal head is used to display Green and Red times. In the simulation the signal head is located at the physical stop bar. Vehicles will stop randomly distributed between 0.5 and 1.5 m before the signal stop.

Spatial objects start at a position on a lane and extend for a given length. The most prominent spatial objects describing the infrastructure are as follows:
  • Detectors observe vehicles and people while passing a certain position. The message impulse may be used either for the purpose of statistical evaluation or for transmitting the data to the signal controller to be interpreted by the signal control logic. Detectors may have a length but a zero length is acceptable for push buttons. Detectors contain a type of discriminating pulse, presence, speed, and particular public transport detectors.

  • Stop locations for public transport vehicles: Buses may stop either on the lane itself (curbside stop) or as lay-by turnout. Tram stops are always curbside stops. The length of a stop should be longer than the longest public transport vehicle; otherwise passengers may not board and alight from this vehicle.

  • Parking lots are optional objects needed as origins and destinations if vehicles choose their routes by dynamic assignment. Victious parking lots are required for dynamic assignment but parking lots may also have a physical size if parking space availability will be looked at.

  • Speed areas specify part of a link or connector with different desired speeds of vehicles. Typically speed areas are used for turning movements so that vehicles will turn with a reduced speed and accelerate thereafter to its previous speed.

2.2.3 Traffic Modeling

After the definition of the physical layout of a modeling system the vehicles traveling on the infrastructure have to be specified. While private transport vehicles may search for individual routes, public transport vehicles will follow predetermined routes with stops on their way. Buses on non-regular services such as sightseeing coaches should be modeled as private transport.

2.2.3.1 Private Transport

The class of private transport vehicles is classified in categories like trucks, cars, bikes, and pedestrians. Within each category a particular vehicle model with mandatory technical features like vehicle length, width, acceleration and deceleration rates, and maximum speed is defined. Depending on the purpose of the modeling application data entry of vehicles can be simplified by the specification of distributions of these technical features instead of defining individual vehicle types. The proper distribution of vehicle length reflecting the real vehicle fleet influences the simulation result such as queue length. For most studies vehicle width is irrelevant but modeling-mixed traffic requires the precise definition of the geometric extension of each vehicle type. The vehicle types can be aggregated to a set of vehicles for analysis purpose such as collecting the total travel time of all HOV vehicles. Thus a private transport vehicle is defined by the following attributes:
  • Vehicle category-like modes (mandatory)

  • Vehicle length or distribution of vehicle lengths (mandatory)

  • Distributions of technical and desired acceleration and deceleration rates as a function of speed (mandatory)

  • Maximum speed or distribution of maximum speeds (mandatory)

  • Vehicle width (optional)

  • Color and 3D model or distribution of colors and 3D models (optional)

  • Vehicle weight or distribution of vehicles weights (optional)

  • Emission class or distribution of set of emissions (optional)

  • Variable and fixed cost of vehicle usage (optional)

Vehicles are generated randomly at link entries or at parking lots which may be located in the middle of link segments. Data input flows are defined individually for multiple time periods. As the number of departures in a given time interval [0,t] follows the Poisson distribution with mean = λt, the time gap x between two successive vehicles will follow the exponential distribution with mean 1/λ. λ is measured in vehicles per hour. The probability of a time gap x between two successively generated vehicles can be computed by
$$f(x,\lambda ) = \lambda {\textrm{e}}^{ - \lambda x}$$
(2.1)

If the defined traffic volume exceeds the link capacity the vehicles are stacked outside the network until space is available. It is noted if the stack is not emptied at the end of the simulation time.

2.2.3.2 Public Transport

All technical properties of private vehicles are also relevant for public transport vehicles but additional characteristics are added. A public transport line consists of buses, trams, or light rail vehicles serving a fixed sequence of public transport stops according to a timetable. The stop times are determined by the distribution of dwell times for boarding and alighting or calculations of passenger service times. The timetable describes the departure time at the initial stop. The departure times at the following stops is calculated by
$$\begin{array}{ll} &{\textrm{Simulated arrival at next stop}} + {\hbox{dwell time}} + {\textrm{max }}(0{\textrm{; }}({\hbox{start time}}\\ &\quad +\, {\hbox{departure time offset}} - {\hbox{simulated arrival}} + {\hbox{dwell time}}){\hbox{ Slack time fraction}}) \end{array}$$
(2.2)

The departure time offset is defined by the timetable between two successive stops. The slack time fraction accounts for early starts, if set below 1. If the scheduled departure time is later than the sum of arrival time and dwell time, the public transport vehicle will wait until the scheduled time is reached. If the slack time fraction or the departure time offset is 0, the vehicle will depart according to traffic conditions and dwell time only.

2.2.4 Traffic Control

2.2.4.1 Non-signalized Intersections

The right-of-way for non-signal-protected conflicting movements is modeled with priority rules. This applies to all situations where vehicles on different links or connectors should recognize each other. The priority rules are used to model the following:
  • Uncontrolled intersections where traffic has to give way to traffic on the right

  • Uncontrolled intersections where traffic on the terminating road must give way to traffic on the continuing road

  • Two-way stop-controlled and all-way stop-controlled intersections

  • Roundabouts where vehicles entering the roundabouts have to give way to traffic within the roundabout

  • Merging zones where traffic entering from a ramp has to yield on traffic of the major road

  • Semi-compatible movements (permitted turns) at signalized intersections such as right and left turns conflicting with parallel pedestrian movements or left turns parallel to opposing through movements

  • Buses leaving a lay-by stop have right-of-way if they indicate their movement

Due to the flexibility of the priority rules different national guidelines can be considered. For simplicity the following notes refer to right-hand traffic and may be shifted, if applied to left-hand traffic. VISSIM provides an option that the necessary conversions are made automatically.

The priority rule consists of a stop line indicating a waiting position for vehicles of minor movements (vehicle 2 in Fig. 2.3). At the stop line the minor vehicle will check if a vehicle of the major movement (vehicle 1) is within the headway area. The headway area is defined as a segment starting slightly before both movements merge. The position itself will be set manually. Additionally the minor vehicle checks if a major vehicle will reach the conflict marker within the minimum gap time if traveling with its present speed. Vehicles will only stop at intersections with a yield sign if a major vehicle is either in the headway area or within the gap time zone.
Fig. 2.3

Concept of modeling priority rules

2.2.4.2 Signalized Intersections

While the signal heads are part of the infrastructure the signal displays belong to the traffic control block. Multiple signal heads with identical signal display belong to one signal group. A signal group is the smallest entity to be controlled by a signal control unit. As such the two lanes of the westbound straight through movements in Fig. 2.4 are signaled by group K3 while the right and left turn may have different signal settings. After allocating signal heads to signal groups, clearance times between conflicting movements are defined within an intergreen matrix. If the volumes of each movement are already defined by routes, an optimization routine is available to calculate delay minimizing signal settings for a given cycle time.
Fig. 2.4

Urban signalized intersection with tram tracks

Fig. 2.5

Modeling actuated signal control using vehicle-actuated programming (VAP)

In the Highway Capacity Manual and other national guidelines numerous analytic formulae are available to estimate delay, queue length, and number of stops for fixed-time signal settings (pretimed control). Therefore microsimulation is rather used for actuated and adaptive signal control to account for the stochastic influence of vehicle arrival and the feedback loop between vehicle arrivals and signal settings. VISSIM contains a programming language with a graphical flowcharter to define actuated signal control. It is a structured programming language like C or Pascal added with some functions relevant for traffic engineers. For example, functions are available to receive detector pulses, occupancy rates, and presence. Furthermore the display of signal groups and stages can be accessed. An actuated logic can be defined based on signal groups or based on stages and interstages to reflect national standards of signalization. Since signal control is handled very different in North America an external interface is available for ring-barrier control (Fig. 2.14).

2.2.5 Data Output

Vehicle movements may be animated in 2D or in 3D. This feature allows users to create realistic video clips in AVI format, which can be used communicating a project’s vision. For better representation background mapping capabilities with aerial photographs and CAD drawings should be applied. Additionally building models can be imported from Google Sketchup®. For even more advanced virtual reality visualization, the simulated traffic can be exported to Autodesk® 3DS Max software.

Numerous measures of effectiveness (MOEs) are being reported. Typical MOEs include delay, travel time, stops, queues, speeds, and density. The decision-making process is supported by providing the flexibility to summarize and report the MOEs needed to answer the problem. When, where, and how data are reported from a simulation is defined by the user. Data can be summarized for any time period and interval within that time period; at any point location in the network, at an intersection, along any path, or for the entire network; and aggregated by any combination of mode, or individual vehicle class. Data can also be reported for an individual vehicle. Data are provided in ASCII or database formats and automatically formatted using common software such as Microsoft Access or Excel. Several MOEs can also be exported to the transportation planning software, VISUM, for detailed graphical representations. VISUM provides an extensive graphics library for effectively visualizing transportation modeling results (Fig. 2.6).
Fig. 2.6

3D representation of a simulated urban intersection including trams and cyclists

2.3 Fundamental Core Models

2.3.1 Car Following

Michaelis (1963) introduced a concept that a driver will recognize changes in the apparent size of a leading vehicle as he approaches this vehicle of lower speed. Speed differences are perceived through changes on the visual angle. Minimum changes over time are required to be recognized by drivers. Experiments indicate certain thresholds on relative speed difference and distance for drivers of the lagging vehicle to take an action. These types of car-following models are considered to be psycho-physical car-following models, also referred to as action point models.

Approaching a slower leading vehicle some action points are recognized by the driver while others are being done unconsciously. The action point of conscious reaction depends on the speed difference, relative distance to the leading vehicle, and driver-depended behavior. There are four different stages of following a lead vehicle. Figure 2.7 indicates the oscillating process of this approach. The thresholds are explained in an abbreviated form. Driver-specific abilities to recognize speed differences and individual risk behavior are modeled by adding random values to each of the parameters as shown for ax. For a complete listing of the random values the reader is referred to Wiedemann and Reiter (1992).
Fig. 2.7

Psycho-physical car-following model by Wiedemann

ax:

Desired distance between the fronts of two successive vehicles in a standing queue. ax := VehL + MinGap + rnd1·axmult with rnd1 normally distributed N(0.5, 0.15).

abx:

Desired minimum following distance which is a function of ax, a safety delta distance bx, and the speed with abx := ax + bx·v.

sdv:

Action point where a driver consciously observes that he approaches a slower leading car. sdv increases with increasing speed differences Δv. In the original work of Wiedemann (1974) an additional threshold cldv (closing delta velocity) is applied to model additional deceleration by usage of the brakes with a larger variation than sdv.

opdv:

Action point where the following driver notices that he is slower than the leading vehicle and starts to accelerate again. The variation of opdv is large compared to cldv.

sdx:

Perception threshold to model the maximum following distance which is about 1.5–2.5 times abx.

A following driver reacts to a leading vehicle up to a certain distance which is about 150 m. The minimum acceleration and deceleration rate is set to be 0.2 m/s². Maximum rates of acceleration depend on technical features of vehicles which are usually lower for trucks than the personal desire of its driver. The model includes a rule for exceeding the maximum deceleration rate in case of emergency. This happens if abx is exceeded. The values of the thresholds depend on the present speed of the vehicle as indicated by (v) for all thresholds in Fig. 2.7.

In Fig. 2.8 the impact of different threshold values is presented. Risk averse and less alert drivers do not follow as close as more risky drivers. The alertness is measured by sdv, the safety distance by bx. According to the fundamental diagram in the figure the road capacity of a two-lane motorway will account for about 1950 veh/h/lane, if all driver-vehicle units will drive risk aversely. Road capacity is increased up to 2250 veh/h/lane with thresholds set for more risky drivers. Different threshold values may lower or increase capacity accordingly.
Fig. 2.8

Risk averse (blue) and more alert (orange) vehicle influences road capacity

2.3.2 Lateral Movements

Lateral movement in VISSIM can be structured in lane selection, lane-changing, and continuous lateral movement within one lane.

2.3.2.1 Lane Selection

As long as a driver is not aware of any necessary lane change because he is far away from the next relevant intersection, he chooses the lane with the best interaction situation. Three tests are performed: First the driver decides if he wants to leave the current lane. This is the case whenever the interaction state (i.e., the driving mode in Wiedemann’s car-following model) is different from free. Then he checks the neighboring lanes if there is a better interaction situation, i.e., either free or a higher time-to-collision. If one of the neighboring lanes provides a better situation downstream, the last check is if a lane change is possible considering the vehicles upstream, what is modeled as gap acceptance described below in more detail.

However, lane selection is often governed by mandatory lane changes for desired turns at junctions downstream. In VISSIM’s network coding, each connector has two distances attached: the lane change distance and the emergency stop distance. The lane change distance describes when a driver becomes aware of the upcoming connector; typical values range between 100 and 500 m. From that point on he will consider the connector in his lane selection. The emergency distance is the distance to the connector where a driver will stop when he was not able to reach the necessary lanes to change to the connector. A connector leaving a link is typically attached to only some of the link’s lanes, e.g., a single-lane right turn on a three-lane main road link will be connected only to the rightmost lane of the link. This means a car must be on the rightmost lane to change to the connector.

A driver who follows a defined route knows which connectors he has to take to follow this route. All these connectors have lane change distances, and there might be parts of the route where the driver is in the lane change distance of several connectors at the same time (when the distance between the connectors is less than the lane change distances). The driver takes into account all connectors that he is aware of when selecting a lane. The desired lane is the one that allows him to follow his route through the upcoming connectors with the least number of mandatory lane changes.

In the following example the lane selection is visualized using a turbo roundabout with spiral markings. Drivers intending to make 270° turns should approach at the left lane. This is modeled by lane-changing distances which will extend prior to the approach lanes as shown for the west and south approach in Fig. 2.9 by the amber shading. Connectors are presented in purple and links in light blue.
Fig. 2.9

Visibility of lane-changing distance at a multi-lane roundabout with spiral marking

2.3.2.2 Lane Changing

The actual lane-changing logic in VISSIM is used to decide if it is possible to change to the desired neighbor lane or not. The desired lane is a result of the lane selection process for either free or mandatory lane changes based on gap acceptance: A driver is willing to accept that he forces a lag vehicle on the desired lane to decelerate. The value of this accepted deceleration is a matter of calibration, and for mandatory lane changes it is as well a function of the distance to the emergency stop position of the next connector where the lane change has to be completed, i.e., the driver becomes more aggressive closer to the point of an emergency stop. In a similar way, the driver is willing to accept to decelerate himself in case of a mandatory lane change.

The accepted deceleration values for lag vehicles upstream and for the vehicle itself are parameters of the behavior model and can be defined selectively for pairs of link and vehicle types.

2.3.2.3 Continuous Lateral Movement

The lane-oriented driver behavior described above is complemented by space-oriented movement behavior where the lateral movement is not limited to instantaneous lane-changing maneuvers. Continuous lateral movement is allowed within and between lanes, including overtaking within the same lane sufficient lane width provided. Heterogeneous traffic conditions as found in many developing countries require modeling a mix of different vehicle types and the lack of lane discipline. Lane discipline helps to simplify the behavior models in simulation tools because it allows to structure the behavior in longitudinal behavior handled by the car-following logic and in lateral behavior reduced to lane changing, i.e., the lateral movement is discretized in steps of whole lanes. Typical heterogeneous traffic situations require continuous lateral movements only restricted by the road width. Furthermore the traditional gap acceptance models for lane changing are not suitable since the definition of a gap on the neighboring lane fails in the more space-oriented movement of the heterogeneous vehicles. And finally, the decision for lateral and longitudinal acceleration cannot be considered as independent processes.

Lane width is an optional attribute of links and connectors. By default vehicles are shaped rectangular, but diamond-shaped forms for bicycles allow for a more realistic queuing of two-wheelers at intersections. The driver behavior for lateral movement has to handle two situations not included in traditional car-following and lane-changing models: The drivers must choose a lateral position within the lane and the longitudinal behavior must incorporate more than one leading vehicle on the same lane.

The choice of the lateral position in a lane follows a simple but effective principle: The driver chooses the lateral position where he has the maximum longitudinal time-to-collision. To find this position, the driver divides the available road width in virtual lanes. These virtual lanes are constructed from the right and left sides of the preceding vehicles on the road, including some lateral safety distance. The lateral safety distance that a driver wants to keep while passing another vehicle depends on both vehicle types and on the speed of the overtaking vehicle, i.e., on the maximum of both speeds. A linear relationship of the safety distance from the speed is assumed, the user can define a minimum safety distance at very low speeds and a safety distance at 50 km/h.

To move to the desired position from his current position the driver applies a lateral speed depending on vehicle type and on his longitudinal speed. Under free driving conditions, a preferred lateral position is assigned to each driver being center of the lane, or on the left or on the right, or random. Thus it is possible to model that cars tend to obey to lanes in free traffic but break lane discipline in intersection areas or under congested traffic conditions.

The car-following model takes into account lateral safety distances when deciding which of the preceding vehicles are relevant for the acceleration behavior. Based on the current lateral position, the longitudinal model looks at all vehicles ahead within a user-defined look-ahead distance and determines which vehicles are relevant as leading vehicles. These are all vehicles which the driver cannot pass at the moment with its current speed and lateral position, taking into account the lateral safety distances. Then for each of the relevant vehicles an interaction according to the psycho-physical car-following model is computed. The final longitudinal acceleration applied is the minimum of all accelerations that resulted from the individual interactions.

This lateral behavior model yields a good qualitative representation of the traffic conditions found, for example, on Indian roads. The quantitative calibration of the model is possible as well. Hossain (2004) calibrated the heterogeneous traffic model to match saturation flows measured by video at an intersection in the city of Dhaka, Bangladesh. Other examples of calibration work on this model is the application to bicycle traffic in Germany described in Falkenberg and Vortisch (2003) and on motorcycles in Vietnam. The latter work was presented by Matsuhashi et al. (2005). He measured speed–flow graphs of motorcycles using video analysis and calibrated the lateral safety distances to get a good macroscopic fit of the simulated speed–flow relationships.

2.3.3 Tactical Driving Behavior

Tactical driving behavior is typically defined as the driving behavior that requires some kind of planning ahead with a temporal horizon of more than one time step or a spatial horizon of more than just the direct neighboring vehicles. In order to build a simulation tool usable for practical planning work, the pure, academic car-following and lane-changing models need to be extended for a lot of special situations. In the following subsections, two extensions are described which are clearly in the domain of tactical behavior.

2.3.3.1 Anticipated Driving at Conflict Areas

A conflict area exists in VISSIM by definition wherever two links overlap. Right-of-way conditions can be defined. Individual priority rules are either defined by the user as described above or conflict areas are used where drivers compute a plan to cross the conflict area. A yielding driver observes the approaching vehicles in the main stream and decides when to go. Then he plans an acceleration profile for the next seconds that will allow him to cross the area, taking into account the situation behind the conflict area. If the driver realizes that he has to stop or to slow down due to other vehicles, he will calculate more time to cross the conflict area or decide not to go at all. He anticipates the behavior of the vehicles behind the conflict area, estimating if a car will accelerate or decelerate.

Vehicles in the main stream react to the conflict area as well: If a crossing vehicle could not complete the crossing because of the driver’s overestimation, the vehicle in the main stream will slow down or even stop. If a queue builds up from a signal downstream of the conflict area, the vehicles in the main stream try not to stop on the conflict area in order not to block the crossing stream. This is accomplished by having the drivers make a similar plan to cross the conflict area as the yielding vehicles do.

The extension of the behavior model was generalized in VISSIM so that drivers always have a plan of their acceleration profile for the next seconds which can be accessed by other drivers to model their anticipation of the behavior of observed cars. Of course the planned acceleration profiles cannot always be realized due to unexpected situations.

2.3.3.2 Cooperative Merging

In the chapter about lateral movement the process of selecting and changing a lane in the course of a mandatory lane change was already described. Even the increased aggressiveness toward the emergency position of a connector is not sufficient to model merging situations in dense traffic. To achieve realistic merging capacities it is necessary to include two aspects in the model: an influence of the lane change situation on the longitudinal behavior of the merging car and cooperation of the drivers in the main stream. Obviously this cannot be part of a car-following model alone, because it requires interaction between longitudinal and lateral behavior.

To consider the first aspect a merging driver (or actually any driver that is in a mandatory lane change situation) observes the gap situation on the desired lane. If there is no gap immediately available, he adapts his speed to the average speed level of the desired lane in order to reduce the necessary decelerations after a lane change. If he comes closer to the point where the lane change must be completed, he starts slowing down to reach the next upstream gap in the desired lane.

The second aspect, cooperation, is implemented by giving drivers information about vehicles in a mandatory lane change situation aiming to the lane they are currently using. If a driver sees a merging vehicle on the neighbor lane that could possibly change into his lane in front of him, he applies a user-defined deceleration to keep the gap open or even widen it. The lane-changing vehicle is made aware of the cooperating driver and can take that into account in his lane change decision. In order not to block the mainstream by too much cooperation with a heavy merging stream, a driver will cooperate only once within a definable distance.

In case of congested weaving another situation is treated especially. If speeds are very low and two vehicles want to swap lanes but are driving side by side, then one of the vehicles will slow down to open a gap avoiding a mutual blockage.

2.3.4 Pedestrian Modeling

For cars, motorcycles, and bicycles the lateral movement model described above is appropriate, because these vehicles all have still a dominant longitudinal movement. For pedestrians this is not as clear, since pedestrians can move sideways even without moving longitudinally. Therefore, another movement model is required for pedestrians allowing a more area-based behavior compared to the non-lane-based behavior of vehicles.

The movement of pedestrians is based on the Social Force Model (Helbing and Molnár, 1995). The basic idea is to model the elementary impetus for motion with forces analogously to Newtonian mechanics. From the social, psychological, and physical forces a total force results, which then sums up to the entirely physical parameter acceleration. The forces which influence a pedestrian’s motion are caused by his intention to reach his destination as well as by other pedestrians and obstacles. Thereby other pedestrians can have both an attractive and a repulsive influence.

The driving force to the destination is deduced from a so-called floor field, i.e., is a function of the position (x, y) of the pedestrian that gives the direction of the shortest path to the destination. The repulsive forces from walls and other pedestrians can be modeled in various ways. Several variants of the original social force model have been developed.

In order to incorporate the social force model including recent extensions, the data model of VISSIM and the user interface had to be extended in order to handle the areas on which pedestrians move. Areas can have different types and be associated with different parameter sets for the behavior model. The floor field is implemented in form of a grid with user-defined grid size, typically 10 cm.

An interesting aspect is the interaction of pedestrians and vehicles in the simulation. The interaction can be modeled at intersections in the form of signal-controlled or priority-controlled conflict areas. Pedestrians may not obey the signals but instead look for gaps in the vehicle stream.

The original social force model reproduces the movement of large pedestrian crowds very well. In 2006 it was used to model the movement of pilgrim crowds for the re-planning of the infrastructure in Mecca. For the use in traffic engineering applications, the version implemented in VISSIM had to be calibrated mainly to reproduce capacities, i.e., the maximum possible flow rates at bottlenecks. The necessary field data needed for the calibration can be collected from video observations of real-world situations or from controlled experiments. A detailed explanation of these calibrations is given in (Kretz et al., 2008). Additionally, it was assured that microscopic effects like lane formation in counterflow situations and stripe formation in crossing flow situations are reproduced and that a realistic impression of resulting animations was generated (Fig. 2.10).
Fig. 2.10

Pedestrian bridge between stadium and bus stop 50 min after the finish of a soccer game

2.3.4.1 Path Choice

For any traffic simulation system it is essential to model realistically the volume of generated vehicles and the routes these vehicles will take. The input volumes are described above. This section will present three different ways to define routing.

2.3.5 Fixed Routes

A route is a fixed sequence of links and connectors: A route may have any length – from a turning movement at a single junction to a route that stretches throughout an entire simulation network. A route starts at a routing decision and ends at destination point. Each routing decision point may have multiple destinations resembling a tree with multiple branches. A routing decision affects all or a subset of vehicles types. Vehicles usually travel on one route before entering a new route. However, partial routes are available allowing to distribute vehicles on alternative subsets of routes. Managed lanes for high occupancy traffic are typically modeled with partial routes using a user-definable toll pricing model.

If vehicles travel on fixed or partial routes they are aware of downstream turning movements if the visibility distance (lane selection distance) reaches upstream to the particular point (see Fig. 2.9); thus the combination of visibility distance and predefined routes is a crucial element to model lane selection realistically. Both routing decisions and lane selection distance can be defined for all vehicles or subsets of vehicles. Quite often the set of driver-vehicle units is subdivided in a class of drivers familiar with the area and another class following street signs. This feature is widely used to model complex situations where some drivers tend to select appropriate lanes several intersections ahead, while others are decide and maneuver late.

2.3.6 Dynamic Routing

Predefined routing is not appropriate for applications which require a feedback between traffic volumes and the decision of preferred routes. Any route guidance system considers past, current, or anticipated volumes in order to regulate and manage traffic movements. The programming language VAP is not only used for signal control but can also be applied for setting routes dynamically. Depending on detector values, vehicles movements can be rerouted. A small logic has to be designed describing traffic conditions and rerouting decisions. The rule-based feature of dynamic routing with VAP is applied for routings in small areas (e.g., booth selection at toll plazas) as well as large networks such as route guidance on alternative motorways. Like fixed routes, dynamic rerouting can also be applied on a subset of vehicles.

2.3.7 Dynamic Assignment

General Approach

Traffic assignment is essentially a model of the route choice of the drivers or transport users in general. For such a model it is necessary first to find a set of possible routes to choose from, then to assess the alternatives in some way, and finally to describe how drivers decide based on that assessment. The modeling of this decision is a special case of discrete choice modeling, and a lot of theory behind traffic assignment models originates from the discrete choice theory.

The motivation to include route choice in a simulation model like VISSIM is twofold: With growing network size it becomes impossible to supply the routes from all origins to all destinations manually, even if no alternatives are considered. On the other hand the simulation of the actual route choice behavior is of interest because the impacts of control measures or changes in the road network on route choice are to be assessed.

The dynamic assignment procedure in VISSIM is based on the idea of iterated simulation. That means a modeled network is simulated not only once but repetitively and the drivers choose their routes through the network based on the travel cost they have experienced during the preceding simulations. Formally speaking the process aims at computing dynamic stochastic user equilibrium.

Network Coding for Dynamic Assignment

Assignment-related problems typically refer to a more abstract idea of the road network than a typical detailed network topology with links and connectors suited for microscopic simulation. Usually intersections are nodes and roads between the intersections are edges of an abstract graph. The assignment procedures can operate much more efficiently on this type of graph, and this level of abstraction is more appropriate even for the human understanding of the problem. Therefore an abstract network representation is built for the dynamic assignment and the user defines the parts of the network model that are to be considered as nodes. Normally real-world intersections are defined as abstract nodes. The sequence of links and connectors between two adjacent nodes is defined as an edge. The dynamic assignment is calculated based on the node–edge topology.

Travel demand for dynamic assignment is specified by an origin–destination matrix. To define travel demand using a origin–destination matrix, the area to be simulated is divided in sub-areas called zones and the matrix contains the number of trips that are made from all zones to all zones for a given time interval. To model the points where the vehicles actually appears or leaves the road network, a network element parking lot is used. A parking lot belongs to a certain zone, i.e., trips originating from this zone or ending in this zone can start or end at this parking lot. A zone can have more than one parking lot. The total originating traffic of a zone is distributed to its parking lots according to relative flows. One parking lot can belong to one zone only.

Alternatively it is also possible to supply traffic demand as a set of trip chains. A trip chain describes for a vehicle a series of zones it will drive to and the time it will spend there. In contrast to O–D matrices a trip chain file allows to supply the simulation with more detailed travel plans for individual vehicles; however, the coding effort is much higher.

Route Search, Assessment, and Choice

During a simulation, travel times are measured for each edge in the abstract assignment network. All vehicles that leave the edge report the time they have spent on the edge. All travel times during one evaluation interval are averaged and thus form the resulting travel time for that edge. There is a special treatment of vehicles that spend more than one evaluation period on an edge, e.g., during congestion. They report their dwell time as well, although they have not left the edge. That is necessary to get information about heavily congested links even if there is no vehicle able to leave because of congestion.

Travel times per edge measured during a time interval of one iteration are exponentially smoothed before they are used in the route choice decision:
$$T_a^{n,\kappa } = (1 - \alpha ) \cdot T_a^{n - 1,\kappa } + \alpha \cdot TO_a^{n,\kappa }$$
(2.3)
where
K

= index of the evaluation interval within the simulation period

n

= index of the assignment iteration

a

= index of the edge

\(TO_a^{n,\kappa } \)

= measured travel time on edge a for period k in iteration n

\(T_a^{n,\kappa } \)

= expected travel time on edge a for period k in iteration n

α

= smoothing factor

The route choice decision is based on a general cost function which is a linear combination of travel time, travel distance, and financial cost (e.g., tolls). The weights of the cost components can be defined by the user separately for user-defined vehicle classes. A route is a sequence of edges that describes a path through the network. Routes start and end at parking lots. The general cost for a route is defined as the sum of the general costs of all its edges.

Obviously, one would like to know the set of the n best routes for each origin–destination pair. Unfortunately there is no efficient algorithm to simply compute the n best routes but there are algorithms to find the single best one. To solve this problem a search for the best route for each O–D pair is activated in each iteration of the dynamic assignment. Since the traffic situation and thus travel times change from iteration to iteration (as long as convergence is not reached) different “best” routes will be found in the iterations. All routes found (i.e., all routes that have qualified at least once as a best route) are collected in an archive of routes and are known in all later iterations.

Since in the first iteration no travel time information from preceding simulation runs is available, the cost is evaluated by replacing the travel time with the distance. Thus for the initial route search also link/connector costs are taken into account. For every subsequent iteration the edges in the network that have not been traveled by any vehicle have a default travel time of only 0.1 s, so that it attracts the route search to build routes including unused edges. This may lead to useless routes in the route collection. A route is considered useless if it is an obvious detour, and an obvious detour is defined as a route that can be generated out of an other known route by replacing a sequence of links by a much longer sequence (in terms of distance). How much longer the replacing link sequence must be to qualify as a detour can be defined by the user.

For the distribution of the travel demand of an O–D pair to the known paths, Kirchhoff distribution formula is used:
$$p(R_j ) = \frac{{U_j^k }}{{\sum\limits_i {U_i^k } }}$$
(2.4)
where
Uj

= utility of route j

p(Rj)

= probability of route j to be chosen

k

= sensitivity of the model

Actually the Kirchhoff distribution formula can be expressed as a Logit function, if the utility function is transformed to be logarithmic:
$$p(R_j ) = \displaystyle\frac{{U_j^k }}{{\sum\limits_i {U_i^k } }} = \displaystyle\frac{{{\textrm{e}}^{k \cdot \log U_j } }}{{\sum\limits_i {{\textrm{e}}^{k \cdot \log U_i } } }} = \displaystyle\frac{{{\textrm{e}}^{ - k \cdot \log C_j } }}{{\sum\limits_i {{\textrm{e}}^{ - k\log C_i } } }}$$
(2.5)
where Cj is the general cost of route j.

VISSIM offers an optional extension of the route choice model to correct the biased distribution in case of overlapping routes. It is based on the idea of the commonality factor of the routes (Cascetta et al., 1996) and implements a special case of the C-Logit model, adapted to VISSIM’s Kirchhoff formulation of the route split.

2.4 Calibration and Validation

In the 15 years of VISSIM’s existence lot of calibration efforts have been undertaken to adjust the parameters of the behavior models to the observed driving behavior in different countries in the world. Since microscopic trajectory data is difficult to get, most of these efforts used macroscopic data provided by standard cross-sectional measurement, typically being volume and speed information in short time intervals.

One of the most recent of the more comprehensive efforts to calibrate VISSIM to macroscopic data is reported in (Menneni et al., 2008). In this study calibration was not based on time profiles of speed and volume but on scatter plots of speed–flow-pairs. These diagrams are very useful for calibration because they contain information about a broad range of traffic situations. In particular they show how the traffic flow behaves around capacity. This is the reason why these speed–flow diagrams are often used for comparing simulation results with real-world data.

The calibration procedure applied was using a genetic algorithm to systematically modify the parameters of the behavior model in order to fit the speed–flow diagrams from measurements and simulation. The measurement data came from a section of US Freeway 101 and were provided as a result of the NGSIM research program in the United States (Kovali et al., 2007). For the application of the genetic algorithm, a distance measure for speed–flow diagrams was developed that served as a measure of fitness in the algorithm (Fig. 2.11).
Fig. 2.11

Speed–flow based on calibration results for US 101 NB

The calibration study generated parameter sets that reproduced the real speed–flow diagrams very well. An interesting aspect in this work is that the genetic algorithm provided for some parameter results that were very close to the default parameters in VISSIM, although the start values for the algorithm were quite different. For some other parameters the procedure suggested values different from the defaults provided at the time of the study. The study was therefore extended to look at microscopic trajectory data (Menneni et al., 2009) which were available for the same freeway section from the NGSIM project. As a result, some of the parameters for the driving mode following in Wiedemann’s model could be adjusted to better reflect American driving style on freeways.

2.4.1 Calibration Based on Microscopic Data

Lately Hirschmann and Fellendorf (2009) conducted some calibration based on single-vehicle trajectories. A vehicle fleet was equipped with high-precision GPS. The vehicles were traveling 3 days using a predefined route on an urban signalized arterial with adaptive signal control. Signalization varied heavily on 3 out of the 11 signalized intersections due to extensive bus and tram priority. The vehicle position was recorded at a rate of 20 Hz and was supplemented by travel time measurements based on automatic number plate recognition. Calibration on a microscopic level allows evaluating parameters of single-vehicle movements such as accelerations at each time step. Figure 2.12 shows measured and modeled acceleration rates over speed. It was anticipated that acceleration rates decrease as speed increases. However, the measurements indicate that the maximum acceleration rate can be observed at speeds around 10 km/h within a city center environment. It was obvious that the desired acceleration rates were too high by default and the mean acceleration rate has been lowered for this study. Using the modified acceleration rates the mean simulated trajectories fit well with the mean measured trajectory. Maximum speeds, the duration of maximum speeds and acceleration–deceleration rates compare well, although the simulated trajectory has a rather late start. The mean shown in the Fig. 2.12 was taken using 30 measured driving cycles and selecting 30 simulated trips randomly. It is noteworthy that the vehicles are hardly traveling with constant speed.
Fig. 2.12

Microscopic calibration using acceleration–deceleration rates over speed (left) and mean trajectory data measured with GPS (right)

2.5 Interfaces to External Applications

2.5.1 Application Programming Interface

VISSIM implements Microsofts Component Object Model as a programming interface. The functionality provided by a COM interface can be used by different programming languages; among them popular scripting languages like Visual Basic or Python. If any functionality is provided by a COM interface, all the objects dealt with (like the vehicles in VISSIM, for example) and the operations on these objects must be modeled in the COM object model. Within the object model, the objects are structured in meaningful groups and hierarchies. So links may be found enclosed in a superior object called net. The links themselves contain the lanes and so on. The COM interface provides access to
  • the modeled road network with all its attributes

  • signal control

  • evaluations

  • all vehicles in the simulation and their attributes

  • the simulation control, i.e., the simulation, can be started and stopped, and parameters can be read and set (Fig. 2.13).

Fig. 2.13

Object hierarchy of VISSIM’s COM interface

Fig. 2.14

Interface for ring-barrier controllers, a superset of the American NEMA controller

The COM interface can be used to include VISSIM in other applications, e.g., if a user wants to write his own user interface to a set of special simulations, or to influence the behavior within the simulation. The COM program can run the simulation time step per time step and modify the state of vehicles or any network objects between the steps. For some decision models in VISSIM (e.g., route split, or the pricing model for HOT lanes) callback functions are provided at the COM interface so that the user can supply his own functions to override VISSIM’s built-in models.

The COM interface is also widely used to simplify and document repetitious simulation tasks. Project automation using scripts has also proven to reduce errors for complex simulation task as repetitive tasks are recorded and used later for different scenarios to be modeled.

2.5.2 External Signal Controllers

Testing and analyzing signal control is one of the primary objectives of VISSIM. Therefore a flexible interface is provided for external signal controllers.

There are several ways to model signal control in VISSIM:
  • Fixed-time/pretimed signal plans

  • Actuated (via a ring-barrier graphical user interface)

  • User-definable signal control logic through a macro language logic called VAP

  • Interfaces to signal controller firmware (virtual controllers) such as Econolite ASC/3 TM SIL or D4

  • Interfaces to adaptive algorithms such as Peek’s Spot/Utopia, SCATS and SCOOT

  • Serial communication to external controllers

  • Hardware-in-the-loop connections to VISSIM via NEMA TS2 or TS1 standards, allowing users to connect signal controllers directly to VISSIM

The C-like traffic control macro language, VAP, is supplemented with a flowchart editor for easy data entry, error checking, and debugging. In addition, the ring-barrier controller is used in North America to model actuated signal timings with custom menus to model bus and LRT priority and railroad preemption.

Data provided by the traffic flow model contain detector data which are provided at time steps varying from 0.1 to 1 s. Each detector will provide information of vehicle front end, rear end, vehicle presence, occupancy rate, gap time, vehicle type, and vehicle speed. The controller may utilize only a subset of the detector information. In each controller time step VISSIM contacts all controller units at the end of the current simulation time step. First, the current signalization states and detector data of all signal controllers are passed to the respective tasks implemented as dynamic link library for each controller unit. Second, the tasks are asked to calculate new desired signal states which are subsequently passed back to the traffic simulator. Depending on parameter settings by the controller logic, either these signal states are applied immediately or transition states (e.g., amber) are inserted automatically, as defined in the signal group parameters. In the next simulation time step the vehicles in the traffic simulation will react on the new signalization (Fig. 2.5).

Major signal control manufacturers such as the Netherlands, Haarlem, Peek, Siemens, Swarco, and Thales use this interface to test their controller technology. Besides this universal interface, an additional interface is provided for adaptive controller software. Only one controller task is needed for the adaptive systems SCOOT and SCATS. All detector and signalization data are interfaced with the replication of the central urban traffic control system (UTCS). The UTCS handles the detector and signalization data of all modeled controllers and provides the communication between each individual controller.

The US American market follows the NEMA standard for pretimed, semi-actuated and fully actuated operation. The ring-barrier controller (RBC) interfacing with VISSIM shows fewer limitations than the standard NEMA controller as the number of signal groups is limited to 16 with 32 vehicle detectors, 16 pedestrian detectors, 2 prioritized preempts, and public transport priority options.

2.5.3 External Driver Model

For users who want to implement their own car-following and lane-changing logic, an interface to external driver models is offered. The external model must be compiled as a dynamic link library. In every time step of the simulation VISSIM will provide the current situation for each vehicle controlled by the external model, i.e., essentially the surrounding vehicles and their attributes. The external model then calculates the acceleration and lane change decision for this vehicle and passes them back to VISSIM. The vehicle is then moved accordingly. The normal VISSIM behavior for the external vehicle is computed as well and provided at the interface in case a user wants to modify only parts of the behavior. A similar interface is available for pedestrian simulation. Network and pedestrian information is provided to the external model and positions and speeds are received from the external model for the next time step.

2.5.4 External Emission Modeling

In order to calculate traffic-related emissions a number of modeling options are available. In German-speaking countries calculations are usually based on the HBEFA (Handbook Emissions Factors Road Traffic), which provides emission values for a set of predefined representative driving cycles and vehicle fleets. Also other emission models were developed in the past such as the European COPERT model. Emission measurements and calculations have been supported by the European project ARTEMIS. The COPERT/CORINAIR methodology allows calculating different pollutants based on measured driving cycles matched with average cycle speeds. Based on intensive measurements on engine test beds, Hausberger (2003) described a detailed instantaneous emission model (PHEM – Passenger car and Heavy duty vehicle Emissions Model). A variety of vehicle and engine types has been embedded by specific engine maps. Driving cycles and engine specifications (Car/lorry, EURO 0 to EURO 4, diesel/gasoline, power, cubic capacity, weight, transmission) are required as input data. Based on a driving cycle, respectively, trajectories with speed and location over time, PHEM calculates engine power required as a result of the driving resistance. Losses in the transmission system and road gradient are being considered. The actual engine speed is simulated by transmission ratios and a gear shift model.

VISSIM provides simulated driving cycles as trajectory data for PHEM, which is calculating the emissions as if the driving cycles are taken from a dynamometer. The toolbox is supplemented by adding various traffic responsive signal control strategies. A study is being conducted comparing the impact of different signal control strategies on traffic-related emissions using the adaptive signal control system MOTION (Fig. 2.15).
Fig. 2.15

Toolbox for modeling traffic-related emissions in urban environments

References

  1. Benz Th (1985) Mikroskopische Simulation von Energieverbrauch und Abgasemission im Straßenverkehr. Schriftenreihe des Instituts für Verkehrswesen Heft 32, Universität KarlsruheGoogle Scholar
  2. Brannolte U (1980) Verkehrsablauf auf Steigungsstrecken von Richtungsfahrbahnen. Forschung Straßenbau und Straßenverkehrstechnik, Heft 318, BonnGoogle Scholar
  3. Busch F, Leutzbach W (1983) Spurwechselvorgänge auf dreispurigen BAB-Richtungsfahrbahnen. Auftrag des Bundesministerium für Verkehr, Institut für Verkehrswesen, Universität KarlsruheGoogle Scholar
  4. Cascetta E, Nuzzolo A, Russo F, Vitetta A (1996) A modified logit route choice model overcoming path overlapping problems: specification and some calibration results for interurban networks. In: Lesort JB (ed) Transportation and traffic theory. Proceedings from the thirteenth international symposium on transportation and traffic theory, Lyon, France. Pergamon Press, Oxford, pp 697–711Google Scholar
  5. Falkenberg G, Vortisch P (2003) Bemessung von Radverkehrsanlagen unter verkehrstechnischen Gesichtspunkten. Wirtschaftsverlag N.W. Verlag für Neue Wissenschaft, ISBN-13 978-3897019690; Bremerhafen, Germany, 2003Google Scholar
  6. Fellendorf M (1994) VISSIM: Ein Instrument zur Beurteilung verkehrsabhängiger Steuerungen (VISSIM: a tool to analyse vehicle actuated signal control), In: Verkehrsabhängige Steuerungenam Knotenpunkt edited by the German Research Foundation for transport and roads (FGSV), Kassel, p 31–38Google Scholar
  7. Haas M (1985) LAERM Mikroskopisches Model zur Berechnung des Straßenverkehrslärms. Schriftenreihe des Instituts für Verkehrswesen Heft 29, Universität KarlsruheGoogle Scholar
  8. Helbing D, Molnár P (1995) Social force model for pedestrian dynamics. Phys Rev E 51(5):4282–4286CrossRefGoogle Scholar
  9. Hausberger S (2003) Simulation of real world vehicle exhaust emissions, VKM-THD Mitteilungen, Heft/vol 82, GrazGoogle Scholar
  10. Hirschmann K, Fellendorf M (2009) Emission minimizing traffic control – simulation and measurements. Proceedings of mobil.TUM 2009, International scientific conference on mobility and transport, TU MünchenGoogle Scholar
  11. Hossain MJ (2004) Calibration of the microscopic traffic flow simulation model VISSIM for urban conditions in Dhaka city. Master thesis, University of Karlsruhe, GermanyGoogle Scholar
  12. Hubschneider H (1983) Mikroskopisches Simulations system für Individualverkehr und Öffentlichen Personennahverkehr. Schriftenreihe des Instituts für Verkehrswesen Heft 26, Universität KarlsruheGoogle Scholar
  13. Kovali V, Alexiadis V, Zhang L (2007) Video-based vehicle trajectory data collection. Proceedings of the 86th annual meeting of the TRB, Washington, USA, 2007Google Scholar
  14. Kretz T, Hengst S, Vortisch P (2008) Pedestrian flow at bottlenecks – validation and calibration of Vissim’s social force model of pedestrian traffic and its empirical foundations. International symposium of transport simulation 2008 (ISTS08), Gold Coast, Australia, 2008Google Scholar
  15. Matsuhashi N, Hyodo T, Takahashi Y (2005) Image processing analysis on motorcycle oriented mixed traffic flow in Vietnam. Proceedings of Eastern Asia society for transportation studies (EAST), vol 5, Tokyo, pp 929–944Google Scholar
  16. Menneni S, Sun C, Vortisch P (2008) Microsimulation calibration using speed-flow relationships. Transportation research board, vol 2088. Washington pp 1–9Google Scholar
  17. Menneni S, Sun C, Vortisch P (2009) Integrated microscopic and macroscopic calibration for psychophysical car-following models. TRB 88th annual meeting compendium of papers DVD, Washington, 2009Google Scholar
  18. Michaelis RM (1963) Perceptual Factors in Car Following. Proceedings from the Second International Symposium on Transportation and Traffic Theory, OECD, Paris, 1965Google Scholar
  19. Reiter U (1994) Empirical studies as basis for traffic flow models. In: Akcelik R (ed) Proceedings of the Second International Symposium on Highway Capacity, vol. 2. Sydney, pp 493–502, ISBN 0869106406Google Scholar
  20. Sparmann U (1978) Spurwechselvorgänge auf zweispurigen BAB-Richtungsfahrbahnen. Forschung Straßenbau und Straßenverkehrstechnik, Heft 263, BonnGoogle Scholar
  21. Wiedemann R (1974) Simulation des Strassenverkehrsflusses. Schriftenreihe des Instituts für Verkehrswesen Heft 8, Universität KarlsruheGoogle Scholar
  22. Wiedemann R, Reiter U (1992) Microscopic traffic simulation: the simulation system MISSION, background and actual state. In: CEC project ICARUS (V1052) final report, vol 2, Appendix A. Brussels, CECGoogle Scholar
  23. Wiedemann R, Schnittger St (1990) Einfluß von Sicherheitsanforderungen auf die Leistungsfähigkeit im Straßenverkehr (Richtungsfahrbahnen). Forschung Straßenbau und Straßenverkehrstechnik, Heft 586, BonnGoogle Scholar
  24. Winzer, Th (1980) Messung von Beschleunigungsverteilungen. Forschung Straßenbau und Straßenverkehrstechnik, Heft 319, BonnGoogle Scholar

Copyright information

© Springer Science+Business Media, LLC 2010

Authors and Affiliations

  1. 1.University of Technology GrazGrazAustria
  2. 2.Karlsruhe Institute of Technology, Institute for Transport Studies (IfV)KarlsruheGermany

Personalised recommendations