(From version 7 manual )
Topic List
- Overview
- Details
- Mutual Exclusion
- Un-Timed Traffic Modes
- Dynamically Changing Modes
- Using Several Traffic Controls
- Interaction
- Resetting a Model
- Manipulating Speeds
- Customizing Area Entry Rules
- States
- Properties Pages
Overview
The trafficcontrol is used to control traffic in a given area of a travel network. You build a traffic controlled area by connecting NetworkNodes to the traffic control object. These NetworkNodes then become members of the traffic controlled area. Any path between two nodes that are both members of the same traffic control object is designated as a traffic controlled path, and travelers are only allowed onto that path if given permission by the traffic control object. The traffic control object can be in a mutual exclusion mode, where it only lets a certain number of travelers into the area at any given time, or it can use un-timed traffic modes to only allow travelers onto certain path sections at once.
Details
To connect a NetworkNode to a traffic control, hold down the 'A' key and drag from the traffic control to the node. This will draw a red line between the node and the traffic control. If two NetworkNodes have a path between them, and both NetworkNodes are members of the same traffic control object, then that path is designated as a traffic controlled path, or a member path.
All travelers entering a traffic controlled area must get permission from the traffic control. A traffic control's area consists of all traffic controlled paths as well as the NetworkNode members themselves. What this means is, "entering" a traffic control area is defined as either entering a path that is a member of the traffic controlled area, or arriving at a final destination whose NetworkNode is a member of the traffic control area. However, a traveler is not considered entering the area if it is passing over a NetworkNode that is a member of the traffic controlled area and continuing on a path that is not a member of the traffic controlled area. Travelers will not need permission in this case. A traveler "exits" a traffic controlled area in one of two ways. Either the traveler is coming from a member path to a path that is not a member of the traffic controlled area, or the traveler is coming from an "inactive" state at a member NetworkNode and continuing on to a path that is not a member of the traffic controlled area. Whenever a traveler exits a full area, room is created for other travelers to enter the area. You can also have an inactive traveler exit a traffic controlled area by calling reassignnetnode(), assigning the traveler to a NetworkNode that is not a member of the area. The table below shows the entry/exit definitions.
Coming From | Continuing To | |
---|---|---|
Traffic Control Area Entry/Exit Criteria | ||
Area Entry | Non-member path | 1. Member path OR 2. Member final destination node |
Area Exit | 1. Member path OR 2. Inactive state at member node |
Non-member path |
The traffic control object screens entries into its area using one of two modes: mutual exclusion r un-timed traffic modes.
Mutual Exclusion
When the traffic control is in mutual exclusion mode, it will only allow a certain number of travelers into its area at any given time. Once the area is full, travelers requesting to enter must wait at the edge of the traffic controlled area until another traveler leaves the area and frees up room.
Un-Timed Traffic Modes
When the traffic control is using un-timed traffic modes, it screens entries into the traffic control area based on its table of modes and the entry path of travelers requesting to enter the area. Each row in the mode table represents one mode. Each mode includes a set of entry paths that the traffic control will allow entry for.
The traffic control selects modes based on entry requests. If there are no travelers in the area, then the traffic control simply waits. When the first traveler requests to enter a certain member path of the area, the traffic control searches its table to find a mode that includes that path. If found, the traffic control goes into that mode, allowing the traveler into the area. Once the traffic control is in a certain mode, it will stay in that mode until all travelers have exited the area. Then it will wait for the next "first traveler" request, and will repeat the cycle.
Dynamically Changing Modes
If the traffic control is set to search for the best mode, then it may change modes dynamically without emptying the area first. The traffic control keeps a record of which paths in the current mode have been traveled on. When a traveler enters on a path, the traffic control marks that path as "dirty" or "traveled on" so to say. Even if the traveler leaves the area later on, the dirty record remains. The record is only reset when the traffic control area is totally emptied. When a traveler requests to enter on a path that is not a member of the current mode, the traffic control searches the rest of the table to see if there is another mode that includes all paths that are currently dirty as well as the path that the traveler is requesting. If it finds one then it changes to that mode and allows the traveler into the area. Otherwise the traveler must wait.
Using Several Traffic Controls
Each NetworkNode can be connected to up to 50 traffic control objects simultaneously. The figure below shows a network node connected to two traffic controls.
Notice that the line drawn from the node to the traffic control on the left is orange, whereas the line to the traffic control on the right is red. These colors show the ordering of the traffic controls in the node's member list. The color ordering is done in ROYGBIV fashion (red, orange, yellow, green, blue, indigo, violet). The first traffic control for that network node has a red line drawn to it, the second an orange line, and so forth. This ordering is very important to the functionality of the model, as well as in avoiding gridlock. When a traveler comes to a network node where it must enter more than one traffic control area, it will request entry into the traffic control areas in the order that those areas are listed on the node. It will only request one traffic control at a time. Once a traffic control gives permission to enter, the traveler has technically entered that traffic control area, even though it may still require permission for entry into other traffic control areas. When transferring between two paths, a traveler will first enter all traffic control areas corresponding to the new path before exiting traffic control areas corresponding to the old path.
Note on gridlock when using several traffic controls: Although using several traffic controls in your model can increase the flexibility and capability of your travel networks, it can also very easily cause gridlock. Traffic control gridlock is usually caused by circular wait. Circular wait happens when one traveler is in a traffic control area that is full, waiting to enter another traffic control area, but the other traffic control area is also full and waiting for a second traveler to exit, but the second traveler cannot leave because it must first enter the area that the first traveler is in. This is a simple example of circular wait. Circular wait can span several travelers and traffic controls and is very difficult to debug. Hence, be very careful when using several traffic controls. Experience has shown that it is beneficial to hierarchically order traffic controls, with some traffic controls in charge of large areas, and some traffic controls in charge of smaller areas. Partial intersection of traffic control areas is strongly discouraged. Either a traffic control should be completely contained within a larger traffic control area, or should be the only traffic control for its area. Travelers should request entry into larger areas before requesting entry into smaller areas. Still, even following these guidelines exactly does not guarantee that a model will not experience gridlock. Much of this type of model building is simply trial and error. The figure below shows a very simple model that still causes gridlock. Notice that the green traffic control on the left is full by the fact that the operator holding the flowitem is in its area, waiting to get permission to enter the blue traffic control's area on the right. But the blue traffic control's area is also full because the operator with no flowitem is in the area waiting to get into the green traffic control area on the left.
Interaction
You can do several things to edit traffic control objects in the orthographic/perspective views. Hold down the 'X' button, and repeatedly click on a traffic control object, and all traffic control objects in the model will toggle between hiding their node connections and showing them. If you only want to hide one traffic control's connections, select the traffic control using the shift key, and then 'X' click on the object and it will hide its connections. While running your model, you can hold the 'V' key down and click on the object, holding the mouse button down. Holding the 'V' key down operates the same as described in the keyboard interaction section. This will draw a line to all travelers that are currently requesting entry to the traffic control area, but have not been given permission yet. If the traffic control's color is not white, then it will draw these lines in its color, allowing you to better distinguish between different traffic control area entry requests.
Resetting a Model
Currently traffic controls are not configured to correctly handle travelers that are placed within a traffic control area when the model is reset. You will need to have all travelers reset to a NetworkNode that is not a member of any traffic control areas. Usually this means adding a NetworkNode off to the side of your model, 'A' connecting all TaskExecuters to that NetworkNode, and then having them enter the model at the beginning of each simulation run.
Manipulating Speeds
You can also use Traffic Controls to modify speeds of travelers as an area becomes more crowded. As the traffic control's content increases, entering travelers will modify their speeds based on the Traffic Control's speed table. For example, if you have entered a row in the table that is a 0.6 speed multiple for a content of 3, then as soon as the content of the traffic control's area becomes 3 or greater, all travelers' max speeds will be decreased to 60% of their normal max speed. Note that the speed change does not take effect until the traveler reaches its next node in the network. If you have an area with multiple traffic controls, then the minimum speed multiple of all of the traffic controls will be applied.
Customizing Area Entry Rules
You can also customize the rules by which a traffic control allows/disallows traveler entry into the traffic control area. For more information on this, refer to the command documentation for trafficcontrolinfo().
States
The traffic control does not implement states at this time.
Properties Pages
Traffic Control
Speeds
NetworkNodes
Triggers
Labels
General