Demand

The traffic demand in a network is the number of vehicles traveling along each of the road sections and making turns at the road junctions. Aimsun Next offers two principle means of describing this traffic demand in the network; the first, a Traffic State model, is based on directly modeling the observed flows on the road, the second, is based on origin–destination (OD) matrices which models the trips made by travelers and includes first, their choice of route, then as the scope of the transport model is extended their choice of transport mode, their reaction to advice from ITS and their decision to travel.

Traffic Demand Objects

Every scenario in an Aimsun project or every experiment in a scenario has a Traffic Demand object associated with it.

The traffic levels in a demand object are specified by a set of Traffic States or by OD Matrices - but not a mixture of both. The Traffic Demand object enables traffic demands to be associated consistently with a set of scenarios or a set of experiments within a scenario by providing a single demand object as opposed to editing the demand separately in every individual experiment.

Both count based Traffic States and OD Matrices depend on two basic objects which describe the vehicles in the network:

• Vehicle Type
• Trip Purpose

The Vehicle Type defines the physical behavior and appearance of the vehicle( i.e car,bus, van ...). The Trip Purpose defines the traveler's reason for the trip (i.e. business, commute, leisure...) Together the Vehicle Type and Trip Purpose form a User Class which can be further used in modeling trip and mode choice.

Traffic State

A Traffic State is composed of a set of flows at every input section in the network and a set of turn proportions at every junction for each Vehicle Type and Trip Purpose pair. The data requirement for a model using Traffic States is the observed section flows and turning proportions at each junction which are entered directly to the model. Traffic States are most often used for small area junction design or corridor improvement models where there is comprehensive observed data coverage and the emphasis in the model is on management, optimization, and detailed road design, with no traveler reaction to the traffic conditions other than normal car following behavior.

Traffic State demand cannot model network changes which can cause travelers to change their route in reaction to congestion. However, Traffic States can vary across time intervals to model the changing patterns of flow during the day. For example, one state might control a background level of traffic and place a constant flow of cars on the network while another might run in parallel and place a peak flow of cars on the same network to simulate a "school run". The Traffic Demand object for a scenario can include both Traffic States.

While models based on Traffic State demand might be simple to create, as their input is so closely taken from the observed data, they do have some disadvantages in that individual vehicles do not have a destination, they merely choose each turn based on the turning proportions at the next junction and traverse the network until they find an exit section. Using a model based on Traffic States to investigate the effect of adding a demand for a specific target to study the effect of route choice or to model a network with sparse observed data would not be possible.

OD Matrix Demand

An OD Matrix based Traffic Demand is composed of a set of matrices each describing the number of trips between centroids for each Vehicle Type and Trip Purpose pair in a Time Period. The data requirement for a model using OD matrices is first an estimate of the number of trips between centroids, usually derived from land use and demographics. This estimate can be refined using observed flow and turn count data and here, unlike in the Traffic State mode, the data might be sparse and not available for all turns and sections. OD Matrix based models require an extra stage in generating the model before it can be run; generating the OD matrices.

While models based on OD matrices might require more steps to create as their input has to be derived from the observed data, often using quite sophisticated processes, they are capable of much more investigation into traveler activity than models based on Traffic States. Each vehicle has an origin and a destination and hence a route choice to make which can be varied depending on the congestion in the transport network. In generating the OD matrices, changes in land use and demographics, trip purpose, trip cost, and trip mode choice can be modelled and more investigation into the effect on the transport network of changes in demand as well as changes in the network itself can be undertaken.

An OD Demand based model requires as a minimum the following objects

• A Centroid Configuration which consists of a set of centroids. Each centroid represents a source or a sink of vehicles, either a land use zone or a edge of network connection.
• An OD Matrix corresponding to the Centroid Configuration and containing the number of trips made by a Vehicle Type or a User Class in a Time Period.
• A Vehicle Type and optionally a Trip Purpose where these together form a User Class.
• A set of routes between centroids.

The route choice might be:

• The Initial Calculated Shortest Path (ICSP) This is the best route for the vehicle types in this OD matrix based on the uncongested speed in the road network.
• An OD route, a route edited by the user and allocated to a specific trip in an OD Matrix.

In the simplest OD matrix models, these two choice options will suffice. In more complex models, more sophisticated routing can be used:

• Results from Path Assignment. A Path Assignment is the result of a previous dynamic simulation or a static assignment and contains one or more paths for each trip in an OD matrix.
• A Dynamic Route Choice model where the paths depend on the congestion currently present in the simulation.

In both cases, some vehicles can change path en route as congestion develops or if they receive information from ITS (See the section on Traffic Management.

These route choice calculations can be extended by the choice of Cost Function used to estimate the perceived cost of traversing a link and hence the cost of a route. Cost functions can take into account the travel time for a link, volume of traffic on it and delays at junctions as well as arbitrarily assigned user costs and weights on time, distance, and toll.

Examples

The figure below gives an overview of the main demand oriented classes Note how the centroid configuration holds the OD Matrices and the routes; as these objects are dependent on the layout of the centroids in the model. Other objects, such as Cost Function, Time Period and Traffic State are independent of the Centroid Configuration.

The next figure shows those active in a Traffic State model. A Scenario (or an Experiment in a Scenario) uses a Traffic Demand object which contains one or more Traffic States where each state references a Vehicle Type. The scenario is run with vehicles generated by the combination of Traffic States in the Traffic Demand. Different scenarios can test the response of the network to different combinations of demand.

The next figure shows an OD based demand scenario where a supplied set of routes are used Here the Traffic Demand references a set of OD Matrices which reference a set of routes edited by the user and also a set of shortest path routes generated by Aimsun Next. The matrices all use a common Time Period. Note that not all OD matrices are used here, other scenarios might use a different set of matrices which represent a different demand pattern. The OD matrices do however refer to the same vehicle types as previously used in the Traffic State scenario.

Finally, the next figure shows a similar scenario but this time the OD Matrices use paths generated by a previous scenario and stored in an APA Path Assignment file.

The separation of data and function into different classes enables a high degree of configurability of demand scenarios in Aimsun Next with re-use of common objects in different scenarios.