Changes between Version 1 and Version 2 of LessonsLearned
- Timestamp:
- 01/10/2018 08:46:02 AM (8 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
LessonsLearned
v1 v2 5 5 1. [#purpose Purpose] 6 6 1. [#background Background and Call to Action] 7 1. [#initialplan Initial Plan and Goals] 7 1. [#initialplan Initial Plan] 8 1. [#challenges Challenges] 9 1. [#gatheringresources Gathering Resources and Documentation] 10 1. [#rpccalls RPC Calls and the Birth of the FEP Simulator] 11 1. [#rpcprobs RPC Platform Problems] 12 1. [#greendot The Green Dot] 13 1. [#otherdots Yellow and Red Dots] 14 1. [#fulllist Getting the Full List of Traffic Network Data from ATMS] 15 1. [#highwaysmodel Creating the Highways Model] 16 1. [#lanetypes Discovering Lane Types] 17 1. [#lanecontrol Lane Control] 18 1. [#clientlag ATMS Client Lag] 19 1. [#futurework Future Work] 8 20 9 21 == Purpose == #purpose … … 15 27 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. 16 28 17 == Initial Plan and Goals ==29 == Initial Plan == #initialplan 18 30 19 31 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. 20 32 21 == Gathering Resources and Documentation for Existing System Components == 33 == Challenges == #challenges 34 35 === Gathering Resources and Documentation for Existing System Components === #gatheringresources 22 36 23 37 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. … … 25 39 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. 26 40 27 == RPC Calls and the Birth of the FEP Simulator ==41 === RPC Calls and the Birth of the FEP Simulator === #rpccalls 28 42 29 43 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. … … 38 52 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. 39 53 40 == RPC Platform Problems ==54 === RPC Platform Problems === #rpcprobs 41 55 42 56 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. … … 50 64 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. 51 65 52 == The Green Dot ==66 === The Green Dot === #greendot 53 67 68 One of the biggest challenges in developing this system was setting up the FEP Sim to send a single fep_reply to the ATMS successfully. Initially, we didn't even know to send an fep_reply struct, we only knew to communicate with it via RPC. A single successful fep_reply is resembled by a "green dot" on the ATMS Client. It took weeks of work setting up RPC correctly, reading FEP documentation and picking apart UCI plugin code to achieve this feat. 54 69 70 === The Yellow and Red Dots === #otherdots 55 71 56 == Getting Traffic Network Data from ATMS == 72 After successfully sending an fep_reply and achieving a "green dot", we needed to figure out how to make the dot yellow and red. We knew that the colors were a representation of two values, the volume and occupancy, but did not know what values they needed to be. We tried just about every combination of integers we could think of and all of them resulted in red dots with "call failed" status messages on the ATMS Client. It was later found that the occupancy value was supposed to be a float, not an integer, in the range [0, 1]. After this revelation, it was easy enough to find the values needed for yellow and red dots. 57 73 58 == Creating the Highways Model == 74 === Getting the Full List of Traffic Network Data from ATMS === #fulllist 75 76 When we started the project, we had no traffic network data. We eventually found the initial "triangle" of traffic network data buried on the Paramics plugin PC. We made this data work, but it was not the full list of stations, loop detectors, and lines we had hoped for. 77 78 After some time poking around on the ATMS, we found a SQL dump file of all the data in the network. We wrote a program that configured this data into the format used by our traffic model, and it worked to successfully show data for all stations and loop detectors in the traffic network. 79 80 === Creating the Highways Model === #highwaysmodel 81 82 The ATMS and FEP only see the abstractions of FEPLines, which contain Stations, which contain Loop Detectors. As developers, we needed an abstraction of a highway. Naturally, we thought that a highway would have direction. For example, 5 South and 5 North. The problem here was we did not know the lane types, and some of the Loop Detectors in Stations actually had data for the opposing side of the highway. This made it extremely difficult to make a directed highway abstraction, so we decided to have an undirected highway abstraction. To apply traffic conditions, we simply specify which direction on the highway we want to apply a "dotcolor" and iterate through the stations and apply the color to lanes that are known to be in the specified direction. 83 84 === Discovering Lane Types === #lanetypes 85 86 Finding out what lane types represent is an ongoing battle. Although we now have a better understanding of what certain lane types are, there are still many unknowns. 87 88 This proved to be a very difficult problem. Lane types are represented by a "lane type id" and "lane description". These attributes are not 100% consistent in representing a specific lane type. As an example, an HOV lane can be represented as "SD HOV" or "HV HOV" and that is only for one direction. There is also an immense amount of lane types. Adding to the difficulty is that stations can have "ML" direction lanes and "OP" direction lanes for every lane time and it is not clear how this is represented for many lane types. Also, highways are not uniform by nature. In sum, the nonuniformity of highways, inconsistencies in lane type identification, and complexity of lane types has hindered us in fully understanding individual lane types. 89 90 === Lane Control === #lanecontrol 91 92 Because lane types are hard to discover, having individual lane control has also been a challenge. If we cannot understand a lane type, we cannot control it programmatically so to speak. How can we reasonably control traffic at the lane level if we do not even understand what the lane types are fully? 93 94 The solution to this problem is the TrafficEventsEditor. The TrafficEventsEditor allows the user to create lane level batch scripts in a user-friendly GUI, that will be read by the TrafficModelManager to simulate traffic conditions. The reason the TrafficEventsEditor helps to solve the lane-level control problem is because the user can apply a traffic condition to a specific lane in the model, and then "preview" it on the ATMS Client. This way, if the user is unsure of the lane type, they can easily preview the TrafficLaneEvent on the client and see if it has the desired results. This makes it easy to discover lane types. Another benefit of the TrafficEventsEditor is the ability to quickly produce the TrafficLaneEvent batch script that is read by the TrafficModelManager, as opposed to hard coding the batch script. 95 96 === ATMS Client Lag === #clientlag 97 98 For unknown reasons, the ATMS Client lags when the fep_replys are being sent to the ATMS. This issue needs to be investigated further and solved because it severely impacts the user experience. 99 100 == Future Work == #futurework 101 102 1. ATMS Client Lag problem. 103 2. Implementing TrafficLaneEvents into the TrafficModelManager. 104 3. Improving the TrafficEventsEditor. 105 4. Developing an agent that simulates traffic conditions as opposed to loading traffic conditions from a batch script. 106 5. Daemonize FEP Simulator.
