NOT FINISHED AND NOT REVISED *

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 the component of the Java CAD Server that models 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?

When the CAD Server starts, the Traffic Model Manager and the Highways model are instantiated. The Traffic Model Manager creates 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 in more detail, to give a better understanding of how the simulation works.

Traffic Model

Traffic Model is a loose term that describes the Traffic Model Manager and the Highways class. The Traffic Model Manager contains an instance of the Highways class, and applies Traffic Events to the instance of Highways to update the traffic conditions.

FEP Simulator

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, 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 station, the FEP then reformats the data into an fep_reply struct and sends it to the ATMS via RPC.

In contrast, the FEP Simulator acts as a socket server which reads traffic condition data from the Traffic Model over a socket. Upon receipt of this data, the FEP Simulator also reformats the data into fep_reply structs and sends them to the ATMS via RPC.