Changes between Version 9 and Version 10 of TrafficModelATMSOverview

Timestamp:

01/08/2018 10:04:50 AM (8 years ago)

Author:

jtorres

Comment:

--

TrafficModelATMSOverview

@@ -52 +52 @@
 Reference the [wiki:TrafficModelClassDiagram Traffic Model Class Diagram] while reading this section.
 
+==== Behavior ====
 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.
 
 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.
 
+==== Traffic Model's Class Description / Details ====
+
 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.
 
-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.
+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.
+
+==== Different Abstractions (Highway / FEPLine) ====
+
+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. 
+
+The next section "FEP Simulator" will give a better understanding of FEPLines and why their representation is necessary in the simulation system.
 
 === FEP Simulator ===
@@ -64 +73 @@
 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.
 
+==== The Real FEP ====
 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. 
 
+==== Our FEP Simulator ====
 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.
 
@@ -89 +100 @@
 32 0 13 // "line id" "count num" "number of stations"
 1210831 1 5 S 0.9 8 // "station id" "drop num" "route num" "direction" "postmile" "number of loops"
-1210832  0.0 0  ML_1 // "loop id" "occ" "vol" "loop_description"
+1210832  0.0 0  ML_1 // "loop id" "occ" "vol" "loopLocation"
 1210833  0.0 0  ML_2 // ..
 1210834  0.0 0  ML_3 // ..
@@ -184 +195 @@
 ==== Traffic Conditions Message Structure ====
 
-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.
-
-The message contains static, such as station drop numbers, and dynamic data, like volume and occupancy.
-- byte 1: station drop number
-- byte 2: number of loops * 2 + Fixed_Byte_To_Checksum
-- byte 3: lowbyte: # of mainline loops, highbyte: # of opp loops => high | low
-- byte 4: Always 0xA0. UNKNOWN
-- bytes 5-8: lane configuration
-- byte 9: 0 (no metering)
-- byte 10 - 13: lane malfunction flags. We always assume functional and set to 0.
-- byte 14 - 22: ramp metering data. We do not worry about these values. See code for more details.
-- byte 23: ML Total Volume
-- byte 24: OPP Total Volume
-- byte 25: Always 0x03. UNKNOWN.
-- byte 26: Always 0x84. UNKNOWN.
-
-- byte 27 - second to last byte: dynamic data for loop detectors. If there is data for the loop detector, pack volume and occupancy into a two byte data packet using the packVOLOCC(vol, occ) method, insert at the current position, and increase the current position after doing so.
+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.
+
+The message contains static data, such as station drop numbers, and dynamic data, like volume and occupancy.
+
+|| Byte # || Value || Description ||
+|| 1 || VARIES || Station drop number ||
+|| 2 || # of loops * 2 + Fixed_Byte_To_Checksum || Describes number of loops at station ||
+|| 3 || high = # of opp loops, low = # of ml loops, value = high | low || Describes number of ML and OP loops ||
+|| 4 || 0xAO || UNKNOWN ||
+|| 5 to 8 || VARIES || Lane configuration ||
+|| 9 || 0 || 0 = no metering ||
+|| 10 to 13 || 0 || Lane malfunction flags. We assume all are functional and set to 0 ||
+|| 14 to 22 || Values are constants || Although constant, values differ between metering lanes and regular lane types. UNKNOWN? ||
+|| 23 || VARIES || ML Tot Volume ||
+|| 24 || VARIES || OP Tot Volume ||
+|| 25 || 0x03 || UNKNOWN ||
+|| 26 || 0x84 || UNKNOWN ||
+|| 27 to Last Byte - 1 || VARIES || Dynamic data for loop detectors. If there is data for the loop detector, pack volume and occupancy into a two byte data packet using the packVOLOCC(vol, occ) method, insert at the current position, and increase the current position after doing so. ||
+|| Last Byte || VARIES || check sum value ||
 
 1/8 7:27AM: NOTE TO SELF. DO I NEED TO CALL DYNAMIC DATAPACK BEFORE STATIC DATA PACK???????
-- last byte: checksum