Traffic Model / FEP / ATMS Overview Document

Terminology

• FEP = Front End Processor
• ATMS = Advanced Traffic Management Server
• TMC = Traffic Management Control
• RPC = Remote Procedural Calls

Purpose

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 individual component.

System Deployment / Component Diagram

The System (Traffic Model / FEP / ATMS) Deployment/Component Diagram is a UML Deployment / Component diagram which helps to describe the system architecture.

Overview of System

What is the Traffic Model?

The 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.

What is the FEP Simulator?

The FEP Simulator simulates the actual FEP that is used in production systems at Cal Trans. It is a C++ program that runs on a Linux VM on the TMC network. 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.

What is the ATMS?

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 the 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.

How do these components work together?

Reference the Traffic Model / FEP / ATMS Activity Diagram? while reading this section. It helps to describe system behavior.

When the CAD Server starts, the Traffic Model Manager and the Highways model are instantiated. The Traffic Model Manager spawns a thread, the WriteToFEPThread, which creates a client socket connection with the FEP Simulator. The traffic conditions message is sent over this socket, to the FEP Simulator, on every 30 second interval. To do so, the WriteToFEPThread calls upon the Highways class' writeToFEP() method.

The FEP Simulator acts as a socket server, and awaits the traffic conditions message from the CAD Server's Traffic Model Manager. Upon receipt of this message, the FEP Simulator parses and reconfigures the data into fep_reply structs. 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.

The ATMS receives the fep_reply structs from the FEP Simulator, and then communicates the fep_reply data, which contains the traffic conditions, to the ATMS Client. The end result is the traffic conditions being displayed to trainees on the interactive map GUI.

Why do we need the FEP Simulator?

Why 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 Lessons Learned Document.

Detailed Component Overviews

This section will describe each component individually in more detail, to give a better understanding of how they work.

Traffic Model

Reference the Traffic Model Class Diagram while reading this section.

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.

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.

FEP Simulator

Reference the 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.

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.

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.

The FEP Simulator runs persistently on the Linux Virtual Machine on the TMC network and awaits messages.

ATMS

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.

Protocols

Traffic Model to FEP Simulator

The Traffic Model communicates with the FEP Simulator by sending the traffic conditions message over a socket connection.

The traffic conditions message is produced by the Highways class method "toCondensedFormat(false)".

Example Traffic Conditions Message

Example traffic conditions message (toCondensedFormat(false)) output:

43 // "number of lines"
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"
1210833  0.0 0  ML_2 // ..
1210834  0.0 0  ML_3 // ..
1210835  0.0 0  ML_4 // ..
1210836  0.0 0  PASSAGE // ..
1210837  0.0 0  DEMAND // ..
1210838  0.0 0  QUEUE // ..
1210839  0.0 0  RAMP_OFF // ..
...

FEP Simulator to ATMS

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.

The 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.

The method used to transfer the fep_replys, from the included rpc files, is named fep_reply_xfer_32(fep_reply *reply, CLIENT *clnt).

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:

fep_reply struct

struct fep_reply {
        int reply;
        int schedule;
        int lineinfo;
        polltype kind;
        replykind flag;
        int schedule_sequence;
        int global_sequence;
        long schedule_time;
        int user_info1;
        int user_info2;
        int system_key;
        struct fep_answer_list answers;
};
typedef struct fep_reply fep_reply;

fep_answer_list struct

struct fep_answer_list {
        int size;
        union {
                fep_shortanswer_list shortp;
                fep_longanswer_list longp;
        } fep_answer_list_u;
};
typedef struct fep_answer_list fep_answer_list;

fep_shortanswer_list

struct fep_shortanswer_list {
        int count;
        fep_shortanswer answers[MAXSHORTPOLLS];
};
typedef struct fep_shortanswer_list fep_shortanswer_list;

fep_shortanswer

struct fep_shortanswer {
        fep_answer_info info;
        fep_answer_short_msg msg;
};
typedef struct fep_shortanswer fep_shortanswer;

fep_answer_short_msg

struct fep_answer_short_msg {
        int message_len;
        char message[MAXSHORTREPLYLEN];
};

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.

1/8 7:27AM: NOTE TO SELF. DO I NEED TO CALL DYNAMIC DATAPACK BEFORE STATIC DATA PACK???????

• last byte: checksum