Changes between Initial Version and Version 1 of LessonsLearned

Timestamp:

01/09/2018 09:00:16 PM (8 years ago)

Author:

jtorres

Comment:

--

LessonsLearned

@@ +1 @@
+= Lessons Learned =
+
+== Table of Contents ==
+
+1. [#purpose Purpose]
+1. [#background Background and Call to Action]
+1. [#initialplan Initial Plan and Goals]
+
+== Purpose == #purpose
+
+The purpose of this document is to describe the problems we were trying to solve in developing the Traffic Model and FEP Simulator and the obstacles we encountered during design and development.
+
+== Background and Call to Action == #background
+
+In previous iterations of the TMC Simulator system, a commerical microscopic traffic modeling software named Paramics was used. UC Irvine wrote plugin code to interface with Paramics. Paramics was causing technical issues as time went on and systems evolved, and was a costly commercial solution. It was decided that the best option was to create our own traffic modeling system, which would meet our systems requirements and give us the benefit of owning and controlling the code for future development.
+
+== Initial Plan and Goals ==
+
+Initially, the idea was to create a self-driving macroscopic traffic model. In other words, a traffic model that simulated incidents without user interaction. Little to none was known about the ATMS at this time, and the FEP Simulator and Traffic Model had not been designed.
+
+== Gathering Resources and Documentation for Existing System Components ==
+
+Gathering resources and documentation for the existing system components, such as the ATMS and FEP, proved to be difficult and took more time than expected. Also, the documentation received had a lot of extra fluff. It took a considerable amount of time to gather the information from developers and CalTrans. The UCI Paramics plugin code's location was unknown. We never received any documentation on the ATMS, which made design and development particularly difficult. Luckily, we were able to get enough information from the FEP documentation, UCI Paramics plugin code, and files on the ATMS to make things work.
+
+Another challenge in documentation for the existing system was that there was a lot of extra fluff. It took a considerable amount of time to find what we needed out of the immense amount of technical documentation for our system. For example, the FEP documentation was the documentation for the production FEP, so it included a lot of information that was not pertinent to our simulation system. We also received about three our four different versions of the FEP documentation, some versions relevant, some not. Deciphering through these docs took a great deal of time and effort.
+
+== RPC Calls and the Birth of the FEP Simulator ==
+
+A challenge that we faced was the use of RPC. RPC is not the most integrable technology around. Unfortunately for us, Java does not support RPC but our entire simulation system was written in Java.
+
+For this problem, we saw three possible solutions:
+1. Write an intermediary program on a linux system in C, which reads data from the Java CAD Server and then interfaces with the ATMS via RPC.
+2. Purchase the ONC library to use RPC with Java.
+3. Write our own Java RPC library using Java Native Interface methods.
+
+We chose to write an intermediary program on a linux system in C, which read data from the Java CAD Server and then interfaced with the ATMS via RPC. This gave us ownership of the code, independence from the external commercial ONC library and its financial expense, less development time than writing our own Java RPC library using JNI, and a more realistic simulation of the FEP.
+
+Interestingly enough, this "intermediary program" became the FEP Simulator. This was not our intent at first, we just wanted something that could communicate with the ATMS via RPC! After developing this program some, we realized that it essentially modeled the FEP. Hence, we named it the FEP Simulator.
+
+== RPC Platform Problems ==
+
+When developing the FEP Simulator, we did so on a Linux operating system which supports RPC natively. We did not realize that putting our program on our production computers, which run a Windows operating system, would not work. RPC is outdated and the current 64 bit versions of windows just did not want to work with our program to make RPC calls.
+
+For this problem, we proposed the solution of running the FEP Simulator on a Linux operating system on the TMC network and communicating with it over the network.
+
+We first thought to run the FEP Simulator on a Raspberry Pi, but later found it a better idea to run it on a Linux Virtual Machine on the TMC network. 
+
+Also, at first, we were writing traffic conditions to a file on the Linux Virtual Machine and having a cronjob run the FEP Simulator at a scheduled interval. We later changed the FEP Simulator to run persistently and await socket messages from the CAD Server, to avoid file system dependency and timing complications.
+
+Although this adds an extra device to the system, our FEP Simulator actually resembles the FEP in that it is a both a separate hardware and software component in the system, and that's sort of cool how that worked out.
+
+== The Green Dot ==
+
+
+
+== Getting Traffic Network Data from ATMS ==
+
+== Creating the Highways Model ==