Skip to content

Designing a Traffic Model

Managing a Traffic Model

One of the more time-consuming tasks in transport modeling is managing variants of the transport network. Different options for road network infrastructure and traffic control systems are tested in conjunction with different demand options such as land use and transit routes and schedules. There is a combinatorial explosion in the number of variants of the transport model and consequently a management problem in maintaining consistency across them.

The management problem is compounded when the modeling task focusses on a subarea of a wider transport model and a cordoned area is to be studied. Returning the changes made in the subarea as a result of that modeling exercise to the wide area model, and all the variants of that wide area model is a time-consuming and potentially error-prone task.

Many modeling tasks are also undertaken with different software packages used at different modeling levels with a macroscopic assignment package used in a wide area model, a transit assignment package to model the train and bus use, and a microsimulation package to model smaller areas or used where it is necessary to simulate the detailed interactions between vehicles to accurately reproduce on street conditions. The data interchange between these different modeling systems complicates the model management problem even more.

Finally there are many variables which describe how a transport model functions. These range from car following algorithms to route choice method and are critical in how a model is calibrated. Changes in these variables to calibrate a model must be replicated in all the scenarios tested by the model and once again, with multiple models, using multiple software packages, achieving consistency requires robust management.

Traffic Model Inputs

There are two mandatory input components of a traffic model. These are the base network topology and the travel demand:

  • The base network is the traffic network topology and the various modes of transport; the core of the modeling project. It holds the sections and nodes of the base road network and the fundamental objects such as Vehicle types, Trip Purposes and User Classes that describe the vehicles in the network.

  • A Traffic Demand object describes the trips made by the vehicles traveling in the traffic network. This is either a set of Traffic States which move vehicles in the network to match observed flows or OD Matrices which provide the number of trips between centroids broken down by time of day and User Class. A Centroid Configuration is required for OD matrix based demand and the Aimsun document can contain multiple Centroid Configurations to manage different OD demands. For example, one development option to be tested by the model might include new residential and industrial zones; these, and the traffic demand they generate, are represented by centroids which are only required when this option is tested and the corresponding Traffic Demand included in the scenario.

The optional input components which add important features to the base network are:

  • Master Control Plans specify the control parameters applied to signalized junctions. A Master Control Plan is collection of multiple control plans for different areas of the model and different times of day and a project might contain several Master Control Plans. A scenario, or an experiment in a scenario, will have a Master Control Plan assigned to it to provide the signal control options to be included in the model. Extending the example of different Geometry Configurations above, a scenario with different options of junction improvements can now be tested in different experiments using a different Control Plan in each experiment ranging from fixed time plans to Transit priority and active signal control plans.

  • a Transit Plan is a collection of consistent routes and schedules and a project can hold multiple Transit Plans. A Plan is then selected to be included in a scenario to include that combination of transit services in the model.

The optional components which create variations of the network topology or model parameters are:

  • a set of Attribute Overrides used to change model attributes and allow changes to be made without changing the layout of the network. This allows the scenario to modify parameters such as speed limits, lane restrictions, and reaction times on sections; capacity and bus behavior at transit stops; and turn speeds and yellow box behavior at nodes. Any attribute of any of the network objects can be overridden but the list of objects remains the same.

  • Geometry Configurations contain the geometric differences between the base network and the network to be tested in a scenario and extend what can be adjusted using Attribute Overrides by changing the list of objects. For example, a base network might model a small town, the project might also include a set of Geometry Configurations based on this network; one might add a bypass to that model, others might include junction improvements to existing roads, one junction per configuration. Scenarios can then be created that model the town, the town with different sets of junction improvements, or the town with a bypass. In each case, the core network remains the same, only the differences or, with multiple Geometry Configurations, combinations of differences, are applied in each scenario.

Modeling Subnetworks

Aimsun Next has two mechanisms for simulating sub-areas in a traffic network. A subarea can be small area where microsimulation is used in a hybrid meso-micro model to model vehicle interactions while the rest of the simulation is run with mesoscopic simulation, or mesosimulation is used in a hybrid macro–meso model or a subarea can be cordoned out of a larger traffic network and scenarios generated to run within that subarea only.

A Hybrid simulation area is created by defining a polygon, or selecting road sections and marking them as a simulation area. Which areas are then to be considered in a simulation is selected in the hybrid experiment.

A cordoned subarea is created by converting a polygon shape into a sub-area. See the Sub Network Editing section. The subarea must have its own Centroid Configuration and Demand Plans but can share Transit Plans, Master Control Plans, Geometry Configurations and Attribute Overrides with the main network. Scenarios generated within the subarea are run using the traffic network within that area only and hence run much faster than the larger model.

Traffic demand in sub-areas can be created automatically using a Static Traversal or a Dynamic Traversal method which generates a new centroid configuration for the subarea and a set of OD matrices calculated using either a static assignment experiment or a replication from a dynamic simulation based on the demand in the whole model area