Changes between Version 6 and Version 7 of TrafficModelATMSOverview
- Timestamp:
- 01/06/2018 05:05:02 AM (8 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
TrafficModelATMSOverview
v6 v7 1 = FIRST DRAFT =2 = THIS DOCUMENT IS NOT FINISHED AND HAS NOT BEEN REVISED =3 4 1 = Traffic Model / FEP / ATMS Overview Document = 5 2 … … 55 52 Reference the [wiki:TrafficModelClassDiagram Traffic Model Class Diagram] while reading this section. 56 53 57 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 H Ighways 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.54 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. 58 55 59 The Traffic Model Manager also loads Traffic Events from a batch file into a Queue, the eventsQueue, when instantiated. The Traffic Eventbatch 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.56 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. 60 57 61 58 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. 62 59 63 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 , asthey 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.60 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 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. The next section "FEP Simulator" will give a better understanding of FEPLines. 64 61 65 62 === FEP Simulator === … … 71 68 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. 72 69 70 The FEP Simulator runs persistently on the Linux Virtual Machine on the TMC network and awaits messages. 71 73 72 === ATMS === 74 73 75 The ATMS is a complete d, pre-existing,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.74 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. 76 75 77 76 == Protocols == … … 81 80 The Traffic Model communicates with the FEP Simulator by sending the traffic conditions message over a socket connection. 82 81 83 ==== Traffic Conditions Message Format ==== 82 The traffic conditions message is produced by the Highways class method "toCondensedFormat(false)". 84 83 85 TODO: document traffic conditions message 84 ==== Example Traffic Conditions Message ==== 86 85 86 Example traffic conditions message (toCondensedFormat(false)) output: 87 {{{ 88 43 // "number of lines" 89 32 0 13 // "line id" "count num" "number of stations" 90 1210831 1 5 S 0.9 8 // "station id" "drop num" "route num" "direction" "postmile" "number of loops" 91 1210832 0.0 0 ML_1 // "loop id" "occ" "vol" "loop_description" 92 1210833 0.0 0 ML_2 // .. 93 1210834 0.0 0 ML_3 // .. 94 1210835 0.0 0 ML_4 // .. 95 1210836 0.0 0 PASSAGE // .. 96 1210837 0.0 0 DEMAND // .. 97 1210838 0.0 0 QUEUE // .. 98 1210839 0.0 0 RAMP_OFF // .. 99 ... 100 }}} 87 101 === FEP Simulator to ATMS === 88 102 89 The FEP Simulator communicates with the ATMS via RPC. It sends fep_reply structs which contain traffic condition data. 103 The FEP Simulator communicates with the ATMS via RPC. It sends fep_reply structs which contain traffic condition data. Each 90 104 91 105 ==== fep_reply struct ==== 106 {{{ 107 #!div style="font-size: 80%" 108 {{{#!c 109 struct fep_reply { 110 int reply; 111 int schedule; 112 int lineinfo; 113 polltype kind; 114 replykind flag; 115 int schedule_sequence; 116 int global_sequence; 117 long schedule_time; 118 int user_info1; 119 int user_info2; 120 int system_key; 121 struct fep_answer_list answers; 122 }; 123 typedef struct fep_reply fep_reply; 124 }}} 125 }}} 92 126 93 TODO: document fep_reply struct 127 ==== fep_answer_list struct ==== 94 128 129 {{{ 130 #!div style="font-size: 80%" 131 {{{#!c 132 struct fep_answer_list { 133 int size; 134 union { 135 fep_shortanswer_list shortp; 136 fep_longanswer_list longp; 137 } fep_answer_list_u; 138 }; 139 typedef struct fep_answer_list fep_answer_list; 140 }}} 141 }}} 142 ==== fep_shortanswer_list ==== 143 {{{ 144 #!div style="font-size: 80%" 145 {{{#!c 146 struct fep_shortanswer_list { 147 int count; 148 fep_shortanswer answers[MAXSHORTPOLLS]; 149 }; 150 typedef struct fep_shortanswer_list fep_shortanswer_list; 151 }}} 152 }}} 153 154 ==== fep_shortanswer ==== 155 156 {{{ 157 #!div style="font-size: 80%" 158 {{{#!c 159 struct fep_shortanswer { 160 fep_answer_info info; 161 fep_answer_short_msg msg; 162 }; 163 typedef struct fep_shortanswer fep_shortanswer; 164 }}} 165 }}} 166 167 ==== fep_answer_short_msg ==== 168 {{{ 169 #!div style="font-size: 80%" 170 {{{#!c 171 struct fep_answer_short_msg { 172 int message_len; 173 char message[MAXSHORTREPLYLEN]; 174 }; 175 }}} 176 }}}
