Modeling of the TGV (Train a Grande Vitesse) System and Simulation throughout its entire European network.

Transcription

1 CpE Modeling & Simulation: Modeling of the TGV (Train a Grande Vitesse) System and Simulation throughout its entire European network. (Lance Nanek, Fred Rassam, Brian Creswick, Michael Peterman)

2 Introduction: Quite possibly the most popular train in the world is the French invented TGV (Train A Grande Vitesse). In English, this translates to high speed train which may appear as an understatement to some as the TGV is the fastest train in the world holding the world speed record of km/h (320.3 mph) set on May 18 th Nevertheless, it is important to consider that the TGV s maximum operating speed is 300km/h (186 mph) due to the desire to maintain acceptable maintenance costs. Our project consisted of modeling the entire European, although mostly French, TGV network which is composed of no less than 91 major stations and 100 tracks. Our model involves real world data which was transcribed from an official map found on the TGV s website ( Thus the location of stations, the distances between stations and the operating speeds are all genuine and depict an accurate representation of a tried and tested scenario. One particularity of high speed train systems is that they must run on compliant tracks in order to operate at full speed (the tracks can only be slightly curved). This is clearly seen on the map of the TGV network where only a fraction of the network, emerging from Paris, is certified for use at 300 km/h. The remaining tracks, due to their curves, do not allow operation over the standard speed of 160 km/h. In addition to the high speed tracks and standard tracks, we have also modeled the marginal intermediate network which operates between km/h (we used 210 as a value). Concerning the simulation itself, it is a synchronous distributed event-based simulation. The simulator first proceeds by reading the dataset we created for this purpose. After it has interpreted all 91 stations and 100 tracks, it will begin by assigning 50 trains to a variety of randomly selected stations. From thereon, the simulator will route the trains in accordance with the behaviors we have modeled. The question we are trying to answer with our simulation is which behavior is most effective?. The first behavior (method 1) could be considered the simple behavior; only one train is allowed on the track at one time. This simplistic behavior makes it impossible for a crash to occur. However, with this behavior, a lot of trains will have to wait at the station before the track is freed for their use. The second behavior (method 2) is known as the realistic behavior as we have done research to find out how such routing is actually done. Essentially, multiple trains are send at will on the same track as the driver will make sure crashes do not occur (more detail on this is available in the appendix). Finally, the third behavior (method 3) is referred to as the alternate behavior. This behavior follows the logic of the first one where only one train is allowed per track, however, the remaining trains will seek out an alternate path to destination rather than wait their turn at the station. Once again, we have decided to program this simulation using Java as it led to quicker development due to extensive internal libraries that simplified the task for the programmers. Initially, we had appreciated Java s random number generation features yet its distinct characteristic that drove us to success was its RMI (Remote Method Invocation) feature. This feature was critical in our ability to perform distributed computing, albeit synchronous, simulation. On a final note, this event-based simulation had a cutoff time after 200 minutes. The cutoff time and number of trains was chosen so that the simulations could be completed relatively fast, but still provide valuable comparisons and statistics for each routing behavior.

3 Analysis: The three simulations we ran all follow the same basic format. A routing behavior for all the trains to follow is first selected. Then station and track locations are read in by the program, the set number of trains generated, and the simulation is run. In the output all decisions taking place at the same time are grouped together. The simulation ends when the time count reaches or exceeds 200 minutes, but this can be set for longer or shorter as needed. All events that occur earlier than this time are simulated with the processing loop jumping whatever amount of time in between events is needed. At the end of each of the log files is a total of each train s idle time, the total running time and idle time for all trains, and the fraction of time spent idling overall. In all three behaviors the trains calculate the shortest paths to take to their destinations. Each behavior handles that track being busy in different ways, however. In the first and most naive behavior, if the track providing the shortest route has another train on it, the new train that needs it will idle until that train finishes and check again. This causes some high idle times and large potential waste of fuel (or electricity in our case). For example, one can analyze Train #45 s progress in the first simulation. The lines from the log shown below illustrate Train #45 looking ahead toward its destination and seeing that the track is occupied by Train #48. It decides to idle 32 minutes which is the expected eta for train #48 to finish: Train #45 is in transit, arrived at ST.DIE. Train #45 sees track from 53.3,12.1 to 56.0,13.8 as value 7. ***Train #45 sees train #48 on track and waits, eta: 32. After those 32 minutes pass, Train #45 then checks the track again, this time noticing that it is open, as Train #45 has reached the station and no new train is on the track: Train #45 is in transit, arrived at ST.DIE. Train #45 sees track from 53.3,12.1 to 56.0,13.8 as value 7. Train #45 takes track from 53.3,12.1 to 56.0,13.8, eta: 32. This is an example of the high idle times caused by this routing method. A trip segment that should have taken 32 minutes now takes more than twice that amount. The total time Train #45 spends idling in the simulation is 172 minutes; almost three hours total are spent waiting for other trains to reach the next station. On average, trains in this simulation idled 47.6% of the time. Trains using the second routing method move if the track is open or if all trains on the track are going the same direction. This simulates the zoning system used in modern train systems that lets trains going the same direction use the same track but avoid collision. This results in much lower idle time than in the first method. The code sections below from the beginning of the simulation show an example of how this method reduces idle times: Train #50 is in transit, arrived at BRUXELLES. Train #50 sees track from 43.4,3.5 to 46.2,2.8 as value 1. Train #50 sees track from 46.2,2.8 to 46.4,0.8 as value 100. Train #50 sees track from 46.2,2.8 to 42.3,1.0 as value 100. Train #50 sees track from 46.2,2.8 to 50.3,3.3 as value 100.

4 Train #50 takes track from 43.4,3.5 to 46.2,2.8, eta: 17. Train #43 is in transit, arrived at BRUXELLES. Train #43 sees track from 43.4,3.5 to 46.2,2.8 as value 3. Train #43 sees track from 46.2,2.8 to 46.4,0.8 as value 100. Train #43 sees track from 46.2,2.8 to 42.3,1.0 as value 100. Train #43 sees track from 46.2,2.8 to 50.3,3.3 as value 100. ***Train #43 takes track from 43.4,3.5 to 46.2,2.8 along with train #50, eta: 17. Using method 1, Train #43 would have to idle until train #50 completed it s trip and then check again to see if the track was clear. With this method, however, Train #43 can take the track at the same time as Train #50 provided they are going the same direction and it therefore achieves a lower travel time. There is still some waiting needed, however, as seen here: Train #34 is in transit, arrived at LILLE. Train #34 sees track from 37.8,1.8 to 43.4,3.5 as value 100. Train #34 sees track from 43.4,3.5 to 46.2,2.8 as value 3. Train #34 sees track from 43.4,3.5 to 48.3,4.3 as value 100. Train #34 sees track from 43.4,3.5 to 40.8,2.0 as value 100. Train #34 sees track from 43.4,3.5 to 41.8,4.4 as value 6. Train #34 sees track from 43.4,3.5 to 42.1,5.0 as value 6. ***Train #34 sees train #50 on track coming opposite direction and waits, eta: 17. Train #34 must wait, since Train #50 is now traveling in the opposite direction. If Train #34 were to move now, it would collide with train #34. Overall this method results in an average of only 13.3% of time spent idling. The third behavior analyzed involves finding of alternate routes. If the track a train would follow to its destination is occupied, the train checks an alternate route to its destination (the next shortest one). If both these tracks are occupied or there is no alternate route then the train waits the shortest time needed for one of the tracks to clear. This causes similar results as the first method as seen in the example below: Train #28 is in transit, arrived at ST.BRIEUC. Train #28 sees track from 28.5,14.9 to 25.6,13.3 as value 11. Train #28 sees track from 25.6,13.3 to 20.4,12.5 as value 100. ***Train #28 sees preferred track busy and alternate track busy/non-existant and waits, eta: 33. This method does help reduce idle time and simulation shows it results in an idle time between the other two methods. However, In a network like the one we are dealing with, alternate routes tend to add large distance penalty. Behavior 3 might be more effective in a more crowded, but also more closely spaced system like subways. The third method has an idle time of about 21%. Comparing the three routing behaviors, it is clear that the second behavior is the best. Its idle time was lower than the idle times of either of the other two behaviors and much more so than the base case. Method 3 s improvements over method 1 were not as considerable. Nonetheless, running the simulation on other train networks might reveal some interesting changes due to the distinct geometry of each network. Considering the current results, it is possible that an

5 improvement could be seen by combining behaviors 2 and 3. If a train s route is blocked by another train traveling in the opposite direction, it could then search for an alternate route when it would be waiting no matter what anyway. This could reduce idle time even further and only pay the distance penalty when needed. For the system modeled, however, method 3 s effects will likely be minimal. This is because the log file from behavior two illustrates that in a majority of cases there is no train traveling in the opposite direction and waiting due to this is already minimal (but might change with more trains in the system, for example, like during rush hour). Conclusion: This project is, without a doubt, the most applicable and comprehensive study that we have ever participated in. It is clear that this project is an colossal success as we were, not only able to realistically model the entire TGV network and simulate its behavior, but we were able to perform this task using synchronous distributed simulation and prove that the current routing system is in fact the most effective. Needless to say, the level of detail put into this and the pinpoint accuracy of our results can certainly intimidate a professional who does this for a living. Our simulator is easily configurable and can be adapted to a variety of scenarios; different networks can be used, different traffic/frequency and, as previously shown, different behaviors. Concerning our actual results, the general trend has been proven; the archaic yet improved routing algorithm is still very efficient. Naturally, one could complain that there are a lot of realworld characteristics that we did not model such as waiting time per station, acceleration/deceleration of the trains and random assignments versus compliance with the official schedule. First of all, it is clear that there are so many factors that taking them all into account would make our simulation too complex and, therefore, would skew our results for analysis. Concerning compliance with the already established schedule; it is irrelevant as the focus of our study to was compare different behaviors and not to try to analyze imperfections in the current system which are few are far between. Finally, one could conclude that idle time is a fairly insignificant factor for an electric train operating in a country that relies primarily on nuclear energy for its power (80%). Nevertheless, it goes without saying that idle time cannot really be a good thing both for technical and business purposes. Moreover, while we have not proven whether the alternate behavior actually saves the passengers some time, we are sure that they would rather ride alongside of the French countryside instead of having to wait at the station. On a final note, we can say that while synchronous distributed simulation was successful, we could have benefitted more from a asynchronous distributed simulation despite having computers of roughly the same processing power. In this case, runtime was not a detriment to analysis using the parameters we did. However, if results were needed in real time or more details were added into the simulation then the distributed computation capability would have been more valuable. Future versions could incorporate asynchronous simulation methods relatively easily as well. Trains are only affected by track conditions and nearby trains in close proximity and distant trains could be routed asynchronously from each other.

6 Appendix: Details on Realistic Routing Behaviors: Based on our research, it appears that the MTA, the Paris subway (the metro) and virtually all train systems in the world used the same behavior for routing their trains. This behavior in question heavily relies on signaling to know how close the other train is. For example the New York City subway system uses signals that are physically located at the side of the tracks. Lights are used and the tracks are divided into blocks or track sections to electrically detect if a train is present. The train s wheels and axles short circuit the two rails to show they are present in a block. Each block is either occupied or vacant. If it is occupied the signal is forced to be red. This enforces the separation between trains. A clear signal is green which means there are no trains in the block. All of the current subway track are signaled this way and have basically not changed since The signaling of high speed trains differ. Despite having similar departure frequency, as TGVs can depart within three minutes of another, high-speed trains require a different approach than conventional trains. The speeds of the trains are too high to rely on a driver to read the signals placed at the side of tracks. It would be too difficult and dangerous a task during poor weather and long periods of time. The TGV system uses cab signaling. This system transmits signaling information through the rails as electrical signals which are picked up by antennas which are placed under the train. The information is then processed by computers and displayed to the driver in the cab. This type of cab signal or track to transmission still leaves the driver in charge of driving the train. Programming of Cab Signaling System : As computer engineers, it is important that we understand the intricacies of such devices and not just their basic underlying principles of operation. The latest iteration of the signaling device that the TGV system uses is known as the TVM 430. This device actually has the capability of signaling trains traveling at 360 km/h. This provides some groundwork for the Next Generation TGV. What is most interesting about the TVM 430 is the manner in which they are programmed. Due to the very high regard to reliability in such situations, the TVM 430s are programmed in ADA running on Motorola class processors. The choice of using a very high level language such as ADA was strategic as ADA is often used in safety critical systems due to its intrinsic nature of supporting a variety of checksums which protect against access to unallocated memory, buffer overflow errors and off-by-one errors. In case the of the TVM 430, the device returns a 27-bit digital word to the train providing the driver with the necssary information. One last thing I would like to add is that ADA was invented in the 1970s by Jean Ichbiah of Honeywell / Bull, who happens to be the brother of the architect who built my apartment building in Paris, that man is also a friend of the family.

7 Maps & Pictures: This is the most important map as it is the map we used as a model to implement the TGV network in our simulation. Four stations listed were omitted for the sake of simplicity. They are the following: BOULOGNE, TOURS, LA BAULE, BAYONNE, TARBES

8 This map is quite interesting as it colorcodes the distance (in hours) to locations from Paris. From here, one can estimate where the high speed lines are located. Note M arseille (southeast) is in the 3-hour section. This map color-codes the High-Speed lines referring to the year they were installed.

9 Picture of TGVs (orange ones are 1 st generation) during maintenance. Picture of TGV waiting at the station in Zurich, Switzerland.

10 Two pictures of the Eurostar; the TGV that goes to London.

11 The latest generation of the TGV; the double-decker. TGV traveling past the French countryside. TGV.com - Official Website ( TGVweb - TGV Basics ( TGVweb - The TGV Signaling System ( TGVweb - The TGV Photo Gallery( TGVweb - The TGV World Speed Record ( Ada Programming Language - Wikipedia Encyclopedia - ( Adrita Bhor,"NYC Subway", University of California, Irvine ( Bibliography:

12 (DATASET MANUALLY TRANSCRIBED FROM MAP) EUROPE TGV NETWORK crica 2003 syntax: station1name station2name station1_x station1_y station2_x station2_x distance speed speed: 1 = 300kph, 2 = 210kph, 3 = 160kph Distance: 3.5 = 100km, 7 = 200 km... Thus, multiply distance by to get values in km. Note: X,y and distance are acctually in mm; I figured the result would be the same (as in pixels) since it is all proportional LONDON CALAIS CALAIS LILLE LILLE BRUXELLES BRUXELLES ANTWERPEN BRUXELLES OOSTENDE BRUXELLES LIEGE LIEGE KOLN KOLN DUSSELDORF LILLE NAMUR LILLE DUNKERQUE LILLE LENS LENS ARRAS ARRAS DOUAI DOUAI CAMBRAI DOUAI VALENCIENNES LILLE ARRAS HAUTE PICARDIE ARRAS HAUTE PICARDIE PARIS PARIS ROUEN ROUEN LE HAVRE PARIS VENDOME PARIS LE MANS LE MANS RENNES RENNES ST.BRIEUC ST.BRIEUC BREST QUIMPER LORIENT LORIENT VANNES VANNES RENNES VANNES LE CROISIC LE CROISIC NANTES NANTES ANGERS ANGERS SABLE SABLE LE MANS VENDOME ST.PIERRE-DES-CORPS ANGERS ST.PIERRE-DES-CORPS

13 ST.PIERRE-DES-CORPS POITIERS POTIERS ANGOULEME ANGOULEME LIBOURNE LIBOURNE BORDEAUX POITERS NIORT NOIRT LA ROCHELLE BORDEAUX ARCACHON ARCACHON DAX DAX HENDAYE DAX PAU PAU LOURDES BORDEAUX AGEN AGEN MONTAUBAN MONTAUBAN TOULOUSE TOULOUSE CARCASSONNE CARCASSONNE NARBONNE NARBONNE PERPIGNAN NARBONNE BEZIERS BEZIERS MONTPELLIER MONTPELLIER NIMES NIMES AVIGNON AVIGNON AIX-EN-PROVENCE AVIGNON MARSEILLE MARSEILLE TOULON TOULON LES ARCS-DRAGUIGNAN LES ARCS-DRAGUIGNAN ST.RAPHAEL ST.RAPHAEL CANNES CANNES ANTIBES ANTIBES NICE NICE VENTIMIGLIA AVIGNON VALENCE VALENCE GRENOBLE GRENOBLE MONTMELIAN MONTMELIAN MODANE MODANE TORINO TORINO MILANO MONTMELIAN CHAMBERY CHAMBERY ANNECY CHAMBERY GENEVE ANNECY GENEVE GENEVE MACON MACON LYON-SATOLAS LYON-SATOLAS GRENOBLE LYON-SATOLAS ST.ETIENNE LYON-SATOLAS VALENCE

14 MACON LE CREUSOT LE CREUSOT PARIS PARIS DIJON DIJON CHALON-SUR-SAONE CHALON-SUR-SAONE MACON DIJON BESANCON DIJON LAUSANNE LAUSANNE BRIG DIJON BERN BERN ZURICH DIJON NANCY NANCY METZ METZ LUXEMBOURG METZ SAARBRUCKEN METZ STRASBOURG NANCY EPINAL EPINAL REMIREMONT NANCY ST.DIE NANCY STRASBOURG STATIONS ON MAP OMITTED: BOULOGNE,TOURS,LA BAULE,BAYONNE,TARBES