Support for Multi Network Projects

Building a model with Aimsun Next can be a significant task as models often cover large areas with many road sections, junctions, signals, transit stops, transit lines, and annotations. A large model also requires an often complex demand zone scheme and its corresponding centroid configuration and connections. Building the model in a reasonable time frame will often require input from multiple modelers and their individual contributions must be efficiently managed and merged with each other.

Similarly, once a model is built and calibrated, it will be probably be used for multiple sets of option tests where designs for new road layouts, changes to signal controls, changes to the demand in the network, or tests to evaluate traffic management strategies are carried out. In each of these cases, a committed development will be agreed upon and this will need to be merged into the base model to be included in subsequent option tests. Often, a model will be used to undertake more than one set of tests at the same time, requiring a working copy of the model for each set of tests but with the ability at the end to integrate the final design into the base model.

Managing the workflow processes when more than one modeler needs access to the model as it is built or more than one assessment task is in progress using a completed model is a complex task. This task is eased by the use of Revisions in Aimsun Next which enable a modeling project manager to employ multiple modelers on a single project, or to simultaneously use a single base model on multiple projects and to efficiently manage the task of merging changes into a core base model.

Revisions

A Revision is a link to a base model which only stores those elements that have been changed. Initially, a revision is link to an existing model and contains no objects itself. When a modeler works on a revision, objects that are edited in the revision are marked as changed, stored in the revision model file and are use in preference to those which are unchanged and stored in the base model file. This process is invisible to the modeler, apart from the condition that the base model file must be available to the modeler's computer across the network. If the base document is not available, it will not be possible to edit the revision until the link is remade either by restoring the network connection or relinking to a relocated base document.

At appropriate times, the project manager can choose to integrate the changes from the revision model into the base model at which point the changes from that revision will be available in all other revisions linked to the base model.

Creating and Consolidating Revisions

New Revision

To create a revision based on a current traffic network (the base document) select Project/New Revision.... The following dialog will be shown:

where,

• Base Document: Base network name
• Revision Name: The suffix for the revision network name
• New Initial ID: The starting object ID for the new revision. By default, Aimsun Next will calculate the value based on the objects in the base network , but it is strongly advised to increase it so future modifications in the base document will not duplicate object IDs in the revised document. For example, in the figure above, 300000 should be a reasonable value.
• Revision Document: The revision file name. By default this is base file name and the suffix.

Click the OK button and the base network is closed automatically and the new revision opened. This revision document can be edited in the same way as any other Aimsun document with the condition that the base document must be available to it across the network.

The ID number should be managed across multiple revisions to ensure object IDs will not be duplicated in different revisions. In the example above, setting a start point for different revisions at 300000, 400000 is probably safe but setting the start points at 301000, 302000, would only allow 1000 new objects per revision before clashes occurred which is probably unsafe.

Consolidating Revisions

First, it is recommended that while work is being undertaken in revisions, then the base model is kept unchanged until the revisions are consolidated.

The objects added, changed or deleted in a Revision can be reviewed from the Project Context menu Revision Info

When required by the workflow, it is possible to transform a revision into a full network by joining the base and the revision information in the same file. This can be done from Project/Consolidate Revision where:

• Consolidate Revision in Base: Copies the revisions into the base which in turn will affect any other revisions based on this base model. This also updates object IDs in the base revision.
• Detach Revision from Base: Copies the base into the revised model and keeps the base and revision as two independent documents.
• Revert Selection to Base: Considering the base document, it reverts any changes of the selected objects that were added or changed (not the affected objects from a deletion action) in this revision.

The Consolidate in Base option would be used to include the changes made in a revision into the base model to continue development of the base during model build or to include changes made in an option test and make them available to all other revisions from the base. The base document will be then updated with all actions made in that revision.

A backup document of the old base is saved in: PROJECT_FOLDER\Model\Resources\Backup\old_base_datetime.ang

and a backup of any revision document is saved in: PROJECT_FOLDER\Revisions\RevisionName\Model\Resources\Backup\RevisionName_datetime.ang

The Detach Revision from Base option would be used to set a revision free from the base model either to be worked on in future in isolation or to create an archive copy, for example at the end of an option test.

The Revert Selection to Base option would be used to revert the desired changes of a revision in case there are conflicts between revisions. An object that has been saved in a revision can be reverted back to the same state as it is in the base and the revision changes discarded. Select the object, or multiple objects in the 2D view and select the Revert Selection to Base option in the Project menu.The revision will be saved and closed, then, on re-opening it, those objects will have been removed from the revision, will be read from the base Aimsun document and therefore will be unchanged in the revision. Since it is an experimental option, be sure that you keep a backup of the document before perform any action.

Managing Revisions

A revised network contains objects which overwrite those in the base network and only those modified objects. This requires that the base network must be present when loading a revised network and if it cannot be found, its location will be requested.

As objects which have been changed in the revision network overwrite the base network objects, any subsequent changes to the base network for those objects will not be included in the revised network. For example:

1. A Base Network is opened and a Revision created from it
2. The Revised Network is edited, In the example here a section of a two lane road is widened to a three lane road
3. The Base Network is modified, the nearside lane of the two lane road is restricted to Transit Vehicles only
4. The Revised Network is re-opened. The revised section has not been modified, but the sections in the Revision which are unchanged from the Base Network do receive the modification.

Managing revisions becomes more complex when objects in a model are interlinked For example:

• A control plan holds the signal groups and signal timings for a set of junctions. If two modelers edit the same control plan for different junctions, each in a separate revision, then when the revisions are consolidated in the base, the changes from the first revision to be consolidated will be included in the base model for the signal groups as a part of the junction and for the signal timings as a part of the control plan. Subsequently, when the second revision is re-opened, as the control plan is marked as changed in the revision, the updates to the timings in the base will not be visible in the revision. However, the updates to the signal groups in the changed junctions now included in the base will be visible as these junctions will not have not been changed in the revision.

• Consider a transit line which crosses two geographic areas being edited in separate revisions and where some of the sections or turns in the route have been edited in a revision. When that revision is consolidated in the base and the second revision re-opened, the updates to the sections and turns are now visible in that revision, but as the transit line has been updated in both revisions and is already marked as changed in this second revision, the changes made to the line in the first revision will not be visible in the second.

• If modelers using separate revisions add, edit, or remove traffic management actions or strategies and these actions are assigned to the same scenario, then, when one set of revisions is consolidated into the base, the same scenario in the other revision is not updated. This is because in the second revision, the scenario is marked as changed and consequently not updated from the base The workflow example expands on this point.

In cases like these, one workaround is to use a script to split an object prior to creating the revisions and another script to recombine it when the revisions have been consolidated in the base model. In the figures below it is assumed that in each revision, a modeler has been allocated a geographic area to work on separate from the areas being worked on in other revisions.

In this example, a base model is marked with two distinct areas with a small overlap (2 nodes per section) between them. In the simple case, two revisions are created and two modelers edit them independently. Revision A is first consolidated into the base and at this point the changes made in A are now visible in revision B. Revision B is then consolidated into the base to update it with the changes from both revisions. Any changes which access objects edited in both revisions A and B are made in the base after both revisions have been consolidated.

In the more complex case, both modelers will be working on (for example) control plans and, in this case, the signal timings entered in revision A will update the base but because the same plan has also been updated in revision B, these changes will not be consolidated. In this case, the control plan is split into two using the same areas that were allocated to each revision using a script and, after consolidating both revisions into the base, a script is used to merge the two control plans back into a single plan.

An example of such a script is available, appropriate to control plans

The key actions for the model manager, responsible for controlling revisions is first to identify functionally and/or geographically separate areas and delegate these to the modelers working in individual revisions The second action is to identify those objects which will be indirectly modified and either delay their update until all revisions have been consolidated, or to use a script to split them before allocating revisions and another to merge them after revisions have been consolidated.

Suggested Workflow

The key to efficiently editing large models with multiple modelers undertaking a variety of tasks is to plan the workflow to make best use of the revisions capability. The examples presented here cover possible workflow patterns for:

• Building a model.
• Developing areas within a model.
• Using a model for multiple option tests.

In these examples (LM) is the Lead Modeler or Project Manager, (MA), (MB), (MC)... are modelers working on revisions.

Building a Model

In this example, a new model is to be created starting from an OpenStreetMap import and with transit and signals, etc. imported from external data sources.

1. Edit the model template to define the model infrastructure such as road types, vehicle types, etc. (LM)
2. Import the base network from OSM. (LM)
3. Define the areas of the network each revision will work in by drawing polygons. Ideally there should be a small overlap in the areas with liaison between modelers working in the overlapped area. (LM)
4. Create a set of revisions and allocate modelers to each area to adjust the base network. (MA,MB...).
5. Consolidate all revisions – this can be a repeated task as the work proceeds. (LM)
6. Create a new set of revisions and allocate modeling tasks by function to individual modelers. (LM)
7. In one revision, edit the signal controls. (MA)
8. In another revision, edit the transit. (MB)
9. In another revision, edit the traffic demand. (MC)
10. etc.
11. Consolidate all revisions. (LM)
12. Proceed to calibrate and validate the model. (LM)

Note that in stage 4, it is essential that individual modelers do not edit the common template objects as this will have an effect on all revisions during the merge. In general, the template objects can be added to during this edit stage, but it would require strong justification to adjust them from the standard defaults used by that company or client.

Developing Areas within a Model

In this example, the model is to be refined by adding signals (or transit, or ITS devices ...) and, to expedite delivery of the update, multiple modelers will work on the same function but in different areas of the model. The start point is an existing model

1. Define the areas of the network each revision will work with by drawing polygons. Ideally there should be a small overlap in the areas with liaison between modelers working in the overlapped area. (LM)
2. Use a script to create subdivisions of the objects that will be edited by all revisions - i.e. the control plan which is common to all revisions. (LM)
3. Create a set of revisions and allocate modelers to each area. (MA,MB...)
4. Consolidate the revisions (LM)
5. Use a script to re-merge the previously split objects (LM)

In the case of control plans or transit, there might be many shared objects (i.e. transit routes) or a small number of complex objects (i.e. signal control plans) and the scripting option is the best to adopt. In other cases the shared objects might be both simple to edit and few in number and in this case it would be easier to delay that stage until after the revisions have been consolidated.

Using a Model for Multiple Option Tests

In this example, a calibrated base model is to be used for two individual sets of road network improvement option tests in areas that do not overlap. Time constraints mean both must be undertaken at the same time and, at the end, the chosen option in each case must be available in the base model as a "committed development" and available for inclusion in subsequent modeling exercises.

This example makes extensive use of Geometry Configurations.

1. Create two revisions and allocate a modeler to each one. (LM)
2. Each modeler makes the changes required in the road layout using geometry configurations to manage the multiple possible layouts. (MA,MB)
3. The models proceed through assessment and a change to the network is decided for each option test.
4. After archive copies have been made, the modeler deletes all the discarded tests leaving a single geometry configuration representing the committed development. (MA or MB)
5. The revision is consolidated with the base model which now has the new geometry configuration included in it which can be selected in subsequent scenarios. (LM)

Traffic Management

Using Traffic Management actions provides a further example of managing revisions. In this case, revisions derived from the base model are created and assigned to different modelers, both modelers create a set of traffic actions and add them to a scenario, the same scenario in both revisions.

After consolidating revision A in the base, revision B is re-opened. In this revision, the actions created in revision A are now visible in the base model to revision B but are not assigned to the scenario as that object has also been changed in revision B. If B is then consolidated into the base, then the actions assigned to the scenario in B are assigned in the base but those from A, while they exist in the newly consolidated base, are not assigned to the scenario

The work-around is to identify the scenario as an object changed in both sets of revisions and in this case, refrain from adding the actions to the scenario until the full set of actions from revisions are consolidated, at which time, they can be linked to the scenario.