| 52 | | Traffic Model is a loose term that describes the Traffic Model Manager and the Highways class. The Traffic Model Manager contains an instance of the Highways class, and applies Traffic Events to the instance of Highways to update the traffic conditions. |
| | 53 | Reference the [wiki:TrafficModelClassDiagram Traffic Model Class Diagram] while reading this section. |
| | 54 | |
| | 55 | As previously stated, the Traffic Model consists of the Traffic Model Manager and the Highways model. The Traffic Model Manager contains an instance of the Highways class. Both the Traffic Model Manager and the HIghways model and instantiated upon CAD Server start up. Once instantiated, the Traffic Model Manager runs an instance of the WriteToFEPThread, which sends the current traffic conditions of the Highways to the FEP Simulator by calling the Highways class' writeToFEP() method, on every 30 second interval. |
| | 56 | |
| | 57 | The Traffic Model Manager also loads Traffic Events from a batch file into a Queue, the eventsQueue, when instantiated. The Traffic Event batch file is specified in the Traffic Model Manager's properties file. A Traffic Event changes the current traffic conditions at a specified location. As the simulation runs, the Traffic Model Manager queries the Coordinator object for the current simulation time, and then checks the queue to see if there are Traffic Events that should be applied to the Highways model at the current simulation time. |
| | 58 | |
| | 59 | The Highways and Highway classes were developed to give developers an abstraction of the traffic network that was feasible to work with. A Highway is undirected, meaning it does not have an associated (N/S/W/E) direction and represents traffic in both directions on the highway. A Highway is an aggregation of all of the Stations on a highway, sorted by postmile value. Stations do have an associated direction. Stations may or may not have Loop Detectors associated with the specified station direction, or the opposite specified direction. Hence, the undirected Highway abstraction. |
| | 60 | |
| | 61 | It should be noted that the ATMS has no concept of the Highways and Highway abstraction, only FEPLines, Stations, and Loop Detectors. FEPLines are also composed of Stations, but are not a convenient abstraction, as they only represent serial communication lines used to communicate with a geographic group of field stations. The FEPLines need to be represented because they contain necessary attributes that must be passed on to the FEP Simulator to populate the fep_reply structs. The next section "FEP Simulator" will give a better understanding of FEPLines. |
| 56 | | To understand how the FEP Simulator works, it helps to understand how the actual FEP works. The actual FEP "polls" field stations, over serial communication lines, for traffic data via RPC. For clarity, "polling" is the act of the FEP requesting traffic data from a field station. When "polled", the field station sends traffic data back to the FEP via RPC. Upon receipt of the traffic data from the field station, the FEP then reformats the data into an fep_reply struct and sends it to the ATMS via RPC. |
| | 65 | Reference the [wiki:FEPSimClassDiagram FEP Simulator Class Diagram] while reading this section. It is not quite as helpful as the Traffic Model Class Diagram, because the FEP Simulator is really just a functional program. |
| | 66 | |
| | 67 | To understand how the FEP Simulator works, it helps to understand how the actual FEP works. The actual FEP "polls" field stations, over serial communication lines (FEPLines), for traffic data via RPC. For clarity, "polling" is the act of the FEP requesting traffic data from a field station. When "polled", the field station sends traffic data back to the FEP via RPC. Upon receipt of the traffic data from the field stations, the FEP then reformats the data into an fep_reply struct and sends it to the ATMS via RPC. |
| | 68 | |
| | 69 | In contrast, our FEP Simulator is not actually "polling" field stations, and instead just reads all traffic data over the socket from the CAD Server's Traffic Model. It is similar, however, in that it reformats traffic condition data into fep_reply structs and sends them to the ATMS via RPC. |
| | 70 | |
| | 71 | === ATMS === |
| | 72 | |
| | 73 | The ATMS is a completed, preexisting, production server from CalTrans. We do not know much about it, other than its ability to recieve fep_reply structs via RPC and feed the received data to the ATMS Client interactive map GUI. |
| | 74 | |
| | 75 | == Protocols == |
| | 76 | |
| | 77 | === Traffic Model to FEPSimulator === |
