Changes between Version 11 and Version 12 of TrafficModelATMSOverview
- Timestamp:
- 01/09/2018 05:41:49 PM (8 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
TrafficModelATMSOverview
v11 v12 14 14 1. [#detailedcomponentoverviews Detailed Component Overviews] 15 15 1. [#trafficmodeldetail Traffic Model] 16 1. [#trafficmodelbehavior Behavior] 17 1. [#trafficmodelclasses Traffic Model Classes] 18 1. [#differentabstractions Different Abstractions. FEP Line vs Highway] 16 19 1. [#fepsimdetail FEP Simulator] 20 1. [#realfep The Real FEP] 21 1. [#ourfep Our FEP Simulator] 17 22 1. [#atmsdetail ATMS] 23 1. [#protocols Protocols] 24 1. [#traffictofep Traffic Model to FEP Simulator] 25 1. [#exampletraffic Example Traffic Conditions Message] 26 1. [#feptoatms FEP Simulator to ATMS] 27 1. [#fepreply fep_reply structs] 28 1. [#trafficmessage Traffic Conditions Message Structure] 18 29 19 30 == Terminology == #terminology … … 26 37 == Purpose == #purpose 27 38 28 This document provides an overview of the Traffic Model, the FEP Simulator, and the ATMS. Each of these components work together in the TMC Simulation System to simulate traffic conditions, and display them to trainees. This document will explain to the reader, at a high level, how the components work together to simulate the traffic conditions, the protocols between each component, and lastly, an overview of each individualcomponent.39 This document provides an overview of the Traffic Model, the FEP Simulator, and the ATMS. Each of these components work together in the TMC Simulation System to simulate traffic conditions, and display them to trainees. This document will explain to the reader, at a high level, the system architecture and how the components work together to simulate the traffic conditions, an overview of each component, and lastly, the protocols between each component. 29 40 30 41 == System Architecture == #architecture … … 44 55 === What is the ATMS? === #atmsoverview 45 56 46 The ATMS is a production server, purchased from Cal Trans, that accepts the fep_reply structs from the FEP Simulator via RPC. The ATMS uses thefep_reply structs, which contain traffic condition data, to feed the ATMS Client. The ATMS Client displays traffic condition data on an interactive map GUI to the trainees.57 The ATMS is a production server, purchased from Cal Trans, that accepts the fep_reply structs from the FEP Simulator via RPC. The ATMS accepts fep_reply structs, which contain traffic condition data, to feed the ATMS Client. The ATMS Client displays traffic condition data on an interactive map GUI to the trainees. 47 58 48 59 === System Behavior / How do these components work together? === #systembehavior … … 68 79 Reference the [wiki:TrafficModelClassDiagram Traffic Model Class Diagram] while reading this section. 69 80 70 ==== Behavior ==== 81 ==== Behavior ==== #trafficmodelbehavior 71 82 72 83 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 spawns 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. … … 74 85 The Traffic Model Manager also loads Traffic Events from a batch file into a queue, the eventsQueue, when instantiated. The Traffic Events 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. 75 86 76 ==== Traffic Model 's Class Description / Details ====87 ==== Traffic Model Classes ==== #trafficmodelclasses 77 88 78 89 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. … … 80 91 The Highways, Highway, and Station classes are all immutable. None of them contain dynamic data. The only class in the Highways model that contains dynamic values is the LoopDetector class. The dynamic values in the LoopDetector class are volume and occupancy. The volume field is an int, and the occupancy field is a float in the [0,1] range. The DOTCOLOR enum (specified in the LoopDetector class) represents the colors shown on the ATMS Client (Green/Yellow/Red). This enum supplies the necessary volume and occupancy values to achieve the desired display color for a Loop Detector. 81 92 82 ==== Different Abstractions (Highway / FEPLine) ====93 ==== Different Abstractions. FEP Line vs Highway ==== #differentabstractions 83 94 84 95 It should be noted that the ATMS has no concept of the Highways and Highway abstraction, only FEPLines, Stations, and Loop Detectors. FEPLines, like the Highway Class, are also composed of Stations but are not a convenient abstraction because 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. As a developer you will work within the Highways, Highway, Station, and LoopDetector abstraction. The Traffic Model communicates with the FEP Simulator / ATMS in the context of the FEPLine, Station, LoopDetector abstraction. … … 90 101 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. 91 102 92 ==== The Real FEP ==== 103 ==== The Real FEP ==== #realfep 104 93 105 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. 94 106 95 ==== Our FEP Simulator ==== 107 ==== Our FEP Simulator ==== #ourfep 108 96 109 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. 97 110 98 The FEP Simulator runs persistently on the Linux Virtual Machine on the TMC network and awaits messages. 111 The FEP Simulator runs persistently on the Linux Virtual Machine on the TMC network.The FEP Simulator acts as a socket server, and awaits the traffic conditions message from the CAD Server's Traffic Model Manager. 112 113 Upon receipt of this message, the FEP Simulator parses and reconfigures the data into fep_reply structs. To do so, it uses the Highways Parser class to parse the message from the Traffic Model into FEP_LINES and STATIONS. Once parsed, it configures the data into fep_reply structs. Part of this configuration is packing data into the Traffic Conditions Message. This message is "packed" or created by using the static packData() method from the DataPacker class. See the protocols section for more information. It then sends the fep_reply structs to the ATMS via RPC. Once this process is finished, the FEP Simulator awaits another traffic conditions message from the CAD Server, and the process repeats. 99 114 100 115 === ATMS === #atmsdetail … … 102 117 The ATMS is a complete production server purchased from CalTrans. We do not know much about it, other than its ability to receive fep_reply structs via RPC and feed the received data to the ATMS Client interactive map GUI. 103 118 104 == Protocols == 105 106 === Traffic Model to FEP Simulator === 119 == Protocols == #protocols 120 121 === Traffic Model to FEP Simulator === #traffictofep 107 122 108 123 The Traffic Model communicates with the FEP Simulator by sending the traffic conditions message over a socket connection. … … 110 125 The traffic conditions message is produced by the Highways class method "toCondensedFormat(false)". 111 126 112 ==== Example Traffic Conditions Message ==== 127 ==== Example Traffic Conditions Message ==== #exampletraffic 113 128 114 129 Example traffic conditions message (toCondensedFormat(false)) output: … … 127 142 ... 128 143 }}} 129 === FEP Simulator to ATMS === 144 === FEP Simulator to ATMS === #feptoatms 130 145 131 146 The FEP Simulator communicates with the ATMS via RPC. It sends fep_reply structs which contain traffic condition data. Each fep_reply struct corresponds to a single FEPLine. … … 137 152 fep_reply structs contain metadata and an fep_answer_list struct. An fep_answer_list struct contains a fep_shortanswer_list struct. An fep_shortanswer_list struct contains an fep_shortanswer struct. An fep_shortanswer struct contains an fep_shortanswer_msg struct. The fep_shortanswer_msg contains a char array, which is the actual message that contains traffic condition data. All of these structs are defined in the "fep.h" file. The struct definitions are as follows: 138 153 139 ==== fep_reply struct ==== 154 ==== fep_reply struct ==== #fepreply 140 155 {{{ 141 156 #!div style="font-size: 80%" … … 210 225 }}} 211 226 212 ==== Traffic Conditions Message Structure ==== 227 ==== Traffic Conditions Message Structure ==== #trafficmessage 213 228 214 229 As seen above in the fep_anser_short_msg struct, the traffic conditions message is a char array. The FEP Simulator uses the static packData(STATION*) method from the `DataPacker` class to pack the traffic condition data into a message.
