Changes between Version 14 and Version 15 of TrafficModelATMSOverview


Ignore:
Timestamp:
02/14/2019 09:08:50 PM (7 years ago)
Author:
jdalbey
Comment:

try to attach diagram

Legend:

Unmodified
Added
Removed
Modified

  • TrafficModelATMSOverview

    v14 v15  
    11= Traffic Model / FEP / ATMS Overview Document = 
    2  
    32== Table of Contents == 
    4  
    5 1. [#terminology Terminology] 
    6 1. [#purpose Purpose] 
    7 1. [#architecture System Architecture] 
    8 1. [#overview Overview of System] 
    9  1. [#trafficmodeloverview Traffic Model] 
    10  1. [#fepsimoverview FEP Simulator] 
    11  1. [#atmsoverview ATMS] 
    12  1. [#systembehavior System Behavior] 
    13  1. [#whyfep Why do we need FEP Sim?] 
    14 1. [#detailedcomponentoverviews Detailed Component Overviews] 
    15  1. [#trafficmodeldetail Traffic Model] 
    16   1. [#trafficmodelbehavior Behavior] 
    17   1. [#trafficmodelclasses Traffic Model Classes] 
    18   1. [#differentabstractions Different Abstractions. FEP Line vs Highway] 
    19  1. [#fepsimdetail FEP Simulator] 
    20   1. [#realfep The Real FEP] 
    21   1. [#ourfep Our FEP Simulator] 
    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] 
     3 1. [#terminology Terminology] 
     4 1. [#purpose Purpose] 
     5 1. [#architecture System Architecture] 
     6 1. [#overview Overview of System] 
     7   1. [#trafficmodeloverview Traffic Model] 
     8   1. [#fepsimoverview FEP Simulator] 
     9   1. [#atmsoverview ATMS] 
     10   1. [#systembehavior System Behavior] 
     11   1. [#whyfep Why do we need FEP Sim?] 
     12 1. [#detailedcomponentoverviews Detailed Component Overviews] 
     13   1. [#trafficmodeldetail Traffic Model] 
     14     1. [#trafficmodelbehavior Behavior] 
     15     1. [#trafficmodelclasses Traffic Model Classes] 
     16     1. [#differentabstractions Different Abstractions. FEP Line vs Highway] 
     17   1. [#fepsimdetail FEP Simulator] 
     18     1. [#realfep The Real FEP] 
     19     1. [#ourfep Our FEP Simulator] 
     20   1. [#atmsdetail ATMS] 
     21 1. [#protocols Protocols] 
     22   1. [#traffictofep Traffic Model to FEP Simulator] 
     23     1. [#exampletraffic Example Traffic Conditions Message] 
     24   1. [#feptoatms FEP Simulator to ATMS] 
     25     1. [#fepreply fep_reply structs] 
     26     1. [#trafficmessage Traffic Conditions Message Structure] 
    2927 
    3028== Terminology == #terminology 
    31  
    32 - FEP = Front End Processor 
    33 - ATMS = Advanced Traffic Management Server 
    34 - TMC = Traffic Management Control 
    35 - RPC = Remote Procedural Calls 
     29 * FEP = Front End Processor 
     30 * ATMS = Advanced Traffic Management Server 
     31 * TMC = Traffic Management Control 
     32 * RPC = Remote Procedural Calls 
    3633 
    3734== Purpose == #purpose 
    38  
    39 An important function of the TMC simulator is to simulate the traffic flow that results from a simulated traffic incident.  The traffic flow is shown to the Cal Trans dispatcher as a road map with sensor locations displayed in different colors that correspond to stopped, slowed, or free flowing traffic.  In the real world, data from sensors embedded in highways is transmitted in real time to a computer called the ATMS which then determines the flow of traffic along a network of highways.  For the TMC Simulator there is no actual sensor data so this must be simulated with a traffic model.  In previous versions of the TMC Simulator the traffic model used was a commercial product called Paramics.  For a variety of technical, legal, and economic reasons the use of Paramics became infeasible and we choose to abandon it and develop our own solution.   
     35An important function of the TMC simulator is to simulate the traffic flow that results from a simulated traffic incident.  The traffic flow is shown to the Cal Trans dispatcher as a road map with sensor locations displayed in different colors that correspond to stopped, slowed, or free flowing traffic.  In the real world, data from sensors embedded in highways is transmitted in real time to a computer called the ATMS which then determines the flow of traffic along a network of highways.  For the TMC Simulator there is no actual sensor data so this must be simulated with a traffic model.  In previous versions of the TMC Simulator the traffic model used was a commercial product called Paramics.  For a variety of technical, legal, and economic reasons the use of Paramics became infeasible and we choose to abandon it and develop our own solution. 
    4036 
    4137This 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. 
    4238 
    4339== System Architecture == #architecture 
    44  
    45 The [wiki:DeploymentDiagram System (Traffic Model / FEP / ATMS) Deployment/Component Diagram] is a UML Deployment / Component diagram which helps to describe the system architecture.  
     40The [wiki:DeploymentDiagram System (Traffic Model / FEP / ATMS) Deployment/Component Diagram] is a UML Deployment / Component diagram which helps to describe the system architecture. 
    4641 
    4742== Overview of System == #overview 
    48  
    4943=== What is the Traffic Model? === #trafficmodeloverview 
    50  
    5144The Traffic Model is a loose term that describes the components of the Java CAD Server that model the simulated traffic conditions of the highways during the simulation. It consists of the Traffic Model Manager and the Highways model. 
    5245 
    5346=== What is the FEP Simulator? === #fepsimoverview 
    54  
    55 The FEP Simulator simulates the actual FEP that is used in production systems at Cal Trans. The actual FEP gathers the real time highway sensor data and transmits it to the ATMS. The FEP Simulator will gather simulated highway sensor data from the traffic model and transmit it to the ATMS. It acts as a mediator between the Traffic Model and the ATMS. Its purpose is to receive the traffic condition data over a socket from the Traffic Model, parse and reformat this received data into fep_reply structs, and send the fep_reply structs to the ATMS via RPC. The FEP Simulator is a C++ program that runs on a Linux VM on the TMC network.  
     47The FEP Simulator simulates the actual FEP that is used in production systems at Cal Trans. The actual FEP gathers the real time highway sensor data and transmits it to the ATMS. The FEP Simulator will gather simulated highway sensor data from the traffic model and transmit it to the ATMS. It acts as a mediator between the Traffic Model and the ATMS. Its purpose is to receive the traffic condition data over a socket from the Traffic Model, parse and reformat this received data into fep_reply structs, and send the fep_reply structs to the ATMS via RPC. The FEP Simulator is a C++ program that runs on a Linux VM on the TMC network. 
    5648 
    5749=== What is the ATMS? === #atmsoverview 
    58  
    5950The 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. 
    6051 
    6152=== System Behavior / How do these components work together? === #systembehavior 
    62  
    6353Reference the [wiki:TrafficFEPATMSActivityDiagram Traffic Model / FEP / ATMS Activity Diagram] while reading this section. It helps to describe system behavior. 
    6454 
    … …  
    7060 
    7161=== Why do we need the FEP Simulator? === #whyfep 
    72  
    7362Why do we need the FEP Simulator as a mediator? Can't we just send the fep_replys directly to the ATMS via RPC? The short answer to this question is no. Java does not support RPC natively, whereas C and C++ do. It is possible to use RPCs with Java, but to do so it would require a great deal of work or money. Read more about this decision in the [wiki:LessonsLearned Lessons Learned Document]. 
    7463 
    7564== Detailed Component Overviews == #detailedcomponentoverviews 
    76  
    7765This section will describe each component individually in more detail, to give a better understanding of how they work. 
    7866 
    7967=== Traffic Model === #trafficmodeldetail 
    80  
    8168Reference the [wiki:TrafficModelClassDiagram Traffic Model Class Diagram] while reading this section. 
    8269 
    8370==== Behavior ==== #trafficmodelbehavior 
    84  
    8571As 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. 
    8672 
    … …  
    8874 
    8975==== Traffic Model Classes ==== #trafficmodelclasses 
    90  
    91 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. 
    92  
    93 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. 
     76The 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.  Diagram: [attachment:PeMS_data_sources.png PeMS data souces]. 
     77 
     78The 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. 
    9479 
    9580==== Different Abstractions. FEP Line vs Highway ==== #differentabstractions 
    96  
    97 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.  
     81It 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. 
    9882 
    9983The next section "FEP Simulator" will give a better understanding of FEPLines and why their representation is necessary in the simulation system. 
    10084 
    10185=== FEP Simulator === #fepsimdetail 
    102  
    10386Reference 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. 
    10487 
    10588==== The Real FEP ==== #realfep 
    106  
    107 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.  
     89To 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. 
    10890 
    10991==== Our FEP Simulator ==== #ourfep 
    110  
    11192In 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. 
    11293 
    … …  
    11697 
    11798=== ATMS === #atmsdetail 
    118  
    11999The ATMS is a complete production server purchased from CalTrans. We were unable to find detailed documentation about ATMS features other than its ability to receive fep_reply structs via RPC and feed the received data to the ATMS Client interactive map GUI. 
    120100 
    121101== Protocols == #protocols 
    122  
    123102=== Traffic Model to FEP Simulator === #traffictofep 
    124  
    125103The Traffic Model communicates with the FEP Simulator by sending the traffic conditions message over a socket connection. 
    126104 
    … …  
    128106 
    129107==== Example Traffic Conditions Message ==== #exampletraffic 
    130  
    131108Example traffic conditions message (toCondensedFormat(false)) output: 
     109 
    132110{{{ 
    13311143 // "number of lines" 
    … …  
    145123}}} 
    146124=== FEP Simulator to ATMS === #feptoatms 
    147  
    148125The FEP Simulator communicates with the ATMS via RPC. It sends fep_reply structs which contain traffic condition data messages. Each fep_reply struct corresponds to a single FEPLine. 
    149126 
    150127The FEP Simulator includes the generated rpc files: "fep.h", "fep_clnt.c", and "fep_xdr.c". These files need to be included to utilize RPC. 
    151128 
    152 The method used to transfer the fep_replys, from the included rpc files, is named fep_reply_xfer_32(fep_reply *reply, CLIENT *clnt).  
     129The method used to transfer the fep_replys, from the included rpc files, is named fep_reply_xfer_32(fep_reply *reply, CLIENT *clnt). 
    153130 
    154131fep_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: 
    … …  
    173150}; 
    174151typedef struct fep_reply fep_reply; 
    175   }}} 
     152}}} 
    176153}}} 
    177154 
    178155==== fep_answer_list struct ==== 
    179  
    180156{{{ 
    181157#!div style="font-size: 80%" 
    … …  
    189165}; 
    190166typedef struct fep_answer_list fep_answer_list; 
    191   }}} 
    192 }}} 
     167}}} 
     168}}} 
     169 
    193170==== fep_shortanswer_list ==== 
    194171{{{ 
    … …  
    200177}; 
    201178typedef struct fep_shortanswer_list fep_shortanswer_list; 
    202   }}} 
     179}}} 
    203180}}} 
    204181 
    205182==== fep_shortanswer ==== 
    206  
    207183{{{ 
    208184#!div style="font-size: 80%" 
    … …  
    213189}; 
    214190typedef struct fep_shortanswer fep_shortanswer; 
    215   }}} 
     191}}} 
    216192}}} 
    217193 
    … …  
    224200        char message[MAXSHORTREPLYLEN]; 
    225201}; 
    226   }}} 
     202}}} 
    227203}}} 
    228204 
    229205==== Traffic Conditions Message Structure ==== #trafficmessage 
    230  
    231206As 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. 
    232207 
    … …  
    248223|| 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. || 
    249224|| Last Byte || VARIES || check sum value || 
    250  
    251