Project Management Institute

Simulation of Eurotunnel terminal facilities

Concerns of Project Managers

Issue Focus

John D. Salt, CACI Products Division, Camberley, Surrey, United Kingdom

John D. Salt, a simulation software engineer now working for CACI, has been a simulation engineer with Eurotunnel. Before that he worked for Hunting Engineering Limited of Ampthill, Bedfordshire, producing simulations for the (British) Ministry of Defence. He holds a B.A. (Honors) in Russian and French from the University of Exeter, and an M. SC. in computing science from the University of Newcastle-Upon-Tyne, England. His interest in simulation extends outside working life, as he devotes most of his leisure time to the hobby of wargaming.

Later this year, for the first time in recorded history, England will again be linked to the European Continent via a land route—the English Channel Tunnel. Actually, two running tunnels and a service tunnel will have been completed by TML (TransManche-Link), the consortium of construction companies building the Channel tunnel and terminals. Eurotunnel, the company responsible for operating the tunnel, will commence a regular shuttle service between Folkestone in the U.K. and Coquelles on the outskirts of Calais in France. The total journey is 50 kilometers (over 30 miles) of which some 35 km are under water, making this the longest undersea tunnel ever built. It is also the biggest privately financed engineering project in history.

Two running tunnels will carry two distinct types of rail traffic. The British, French and Belgian railway authorities (British Rail, SNCF and SNCB) will provide a high-speed passenger service from London to Paris and other major European cities. Eurotunnel will run the shuttle trains on which cars and other vehicles will be transported between Folkestone and Coquelles. Drivers will pass through immigration, customs and security procedures at the terminal of departure before boarding the shuttles and will be able to drive straight off with no further formalities on arrival.


A simulation program to be implemented in MODSIM II was an overall model of the vehicular traffic in the Folkestone terminal. The aim of this model was to find out whether the planned provision of overflow car-parks would be sufficient and to estimate typical queue lengths and throughput times under different circumstances.

It has been my job to assist the Operations Department of Eurotunnel by producing simulation programs that will optimize the day-to-day running of the terminals. Looking forward to 1993, we have to have the clearest possible idea of how the terminal will handle predicted demand; the construction of a “model terminal” by means of simulation is a valuable way for managers to study the many variables that will ultimately affect operational performance.

When I arrived at Eurotunnel, I was in the enviable position of having an almost totally free hand in my choice of hardware and software. My first item of business, therefore, was the selection and installation of appropriate tools to tackle the simulation task. Priorities were quick development times, compatibility with existing and proposed company standards, and, most of all, the ability to put the finished program in the hands of managers for direct use in exploring “what-if” scenarios.

Clearly, a specialist simulation language was required, and I had experience with each of the “big three” simulation languages—Simula, SIMSCRIPT II.5 and GPSS. My personal preference had always been for Simula, the first of the object-oriented languages. I find the object-oriented approach to be extremely powerful and elegant and so had chosen to write my master's degree project in Simula. Still, the requirement to put simulations directly in the hands of managers put a premium on in-built graphical capabilities, and for this reason, an excellent SIMGRAPHICS package made SIMSCRIPT 11.5 a very strong contender.

However, in late 1989, the “big three” in simulation had become the “big four” with the release of MODSIM II. As I would expect from any modern high-level language, it embodies the concepts of block-structuring, strong typing and modularity. It is also an object-oriented language and provides full support for process-based simulation. This makes MODSIM II a language comparable to Simula in capability. In my opinion, there are four significant differences between the two languages. First, Simula permits an object to be performing only one action at a time; in MODSIM II, an object can have any number of methods active simultaneously. Second, Simula supports single inheritance; MODSIM II supports multiple inheritance, whereby an object can be immediately descended from more than one ancestor. Third, I found that the smart compiler made MODSIM II much easier to modularize than Simula. The fourth difference, and much the most important, was that MODSIM II had SIMGRAPHICS II, a complete integrated graphics package. It seemed that this might offer the ideal combination of object-oriented rigor and easy-to-use graphics. Nigel MacNamara, of CACI‘s Richmond office here in the UK, was happy to provide a complete set of the language documentation. At his suggestion,my boss Peter Hill and I went to see MODSIM II being used by Chris Carrigan of Royal Ordinance Factories (Future Systems) in Shrivenham. Chris, it turned out, was also a Simula fan and shared a lot of my views on simulation matters. The demonstration of MODSIM II‘s capabilities convinced both Peter and me that we need look no further. In due course, MODSIM II was installed on a shiny new DECstation 5000 and I was in business.

The first simulation program to be implemented in MODSIM II was an overall model of the vehicular traffic in the Folkestone terminal. The aim of this model was to find out whether the planned provision of overflow car-parks would be sufficient and to estimate typical queue lengths and throughput times under different circumstances. All vehicles arriving at the terminal have to go through the following stages before boarding their shuttle: (1) pay toll; (2) pass British customs and immigration; (3) pass Eurotunnel security; (4) pass French customs and immigration; (5) enter the pre-ordering area of allocation to a shuttle; (6) wait in a reservoir area for loading to commence. A proportion of customers may also decide to pay a visit to an amenities building between stages 1 and 2.

There are two main types of customers catered to at the terminal, and these are categorized as “tourist” or “HGV” (heavy goods vehicle). Toll booths, security, loading and other arrangements are separate for each of these categories, and they travel on different types of shuttle trains. The “tourist” category is further subdivided. Most vehicles will be able to be loaded onto double-deck shuttle wagons, but any vehicle towing a trailer or caravan or which exceeds 1.85 meters in height must be loaded onto a single-deck wagon. If spare space is available, double-deck passengers can travel on single-deck wagons but not vice-versa.

The first code on the next page will provide some examples of how the model was developed. The fragment shown directly below is from the vehicle object implementation module. The vehicle object is, of course, the general object from which the vehicles which are carried by the trains are derived. The fragment shown below is used to define the various procedures followed by vehicles after they arrive at the terminal. The first step is calling the pay toll method which, as mentioned above, was derived from the general resource object in the MODSIM II library. While the pay toll method is defined for a generic vehicle and thus applies to all vehicles, this method is implemented with certain differences in the definition of particular vehicles such as cars, heavy trucks, buses, etc. If the driver is hungry, the vehicle parks and removes itself from the line so the driver can enter the amenities stand. The next step is passing through the security controls. If security rejects the vehicle it has to leave. Otherwise, the vehicle goes into the queue for the loading process.

The second code fragment defines the toll paying method for the general vehicle object. First, the tourist polls the toll booth resource and waits for the resource to give it one unit. Behind the scenes, this resource is automatically storing statistics, such as the average wait time for the resource. Once the resource is given, the vehicle proceeds to the toll booth, waits the period of time required to pay the toll which is defined elsewhere, then asks the toll booth to take back one unit of resource which frees the booth for another vehicle. The next fragment defines the amenity using method. First, an object is added to the tourist amenities group, defined elsewhere, which is keeping statistics on the number of people using the amenities station at any given time. The wait duration was initially set here at a nominal period of 30 minutes, although a distribution was later inserted. At the end of this period, one unit is removed from the tourist amenities group. Upon leaving the amenities station, the person must pass through security again. Tourist security is a resource just like the toll booth which is based on the resource object definition in the library. The security check determines whether a more extensive search is required. The time required for the search will be defined as an exponential distribution based on the fact that most searches are very brief while a few take a very long period of time.




     WAIT FOR SELF TO PayToll;

     END WAIT;

     If TollReject

         INC (Toll Rejects[Column]);



     {Have a burger here if so desired}

         IF hungry

             WAIT FOR SELF TO Use Amenities;

             END WAIT;

        END IF;

     {If emergency mode is in force, emergency park}

     {instead of proceeding)

          WAIT FOR SELF TO PassControls;

          END WAIT

          If SecReject

              INC (SecRejects[Column]);




          END IF; {rejected by security}

     END IF; {rejected at tools}

The third fragment shows the definition of the toll resource object. As mentioned earlier, this object is based on the standard resource object contained in the library. However, several capabilities are added in the definition. One additional capability makes it possible to reject a vehicle at the toll booth, and the other is used to collect the toll.




     WAIT FOR TouristToll TO Give (Self, 1 )


     WAIT DURATION TollTime;

          ASK TouristToll TO TakeBack (SELF, 1 );

     END WAIT;

END METHOD; {UseAmenities}

TELL METHOD PassControls;



     Searched : BOOLEAN;



     WAIT FOR TouristSecurity TO Give (SELF, 1)

     END WAIT;

     ASK TouristSecurity TO TakeBack(SELF, 1 )


{Note that the security resource is released before time}

{is elapsed for the search, as this is done out of the}

{traffic flow and will not delay following traffic.}


      Searched: = ASK TouristSecurity If Searched;

      IF Searched

          WAIT DURATION SearchTime;

          END WAIT;

   {Should also claim security men}


          Security Reject: = FALSE;

      END IF;


END METHOD; {Pass Controls}




     FROM ResMod IMPORT ResourceObj;

     FROM vehicle IMPORT Vehicle Obj;




         Toll Obj =

         OBJECT (Resource Obj);


             ASK METHOD If Rejected (IN

             Customer: Vehicle Obj):


             ASK METHOD CollectToll (IN

             Customer: Vehicle Obj);


                    ASK METHOD Obj Init;

             END OBJECT;


Note that these code fragments were taken from the model before graphics were added. It is hard to overstate the importance of graphics in a project such as this. Animated output and presentation graphics made the logic and results of the simulation much more comprehensible to the non-computing manager. MODSIM also makes it easy to construct secure interfaces, including menus and dialog boxes. These capabilities can also bean advantage to the developer—I find it very pleasant to be able to make test runs of the model via a properly-constructed interface. Graphics can also highlight programming errors that would otherwise be very hard to spot.

Published with permission of OR/MS Today, a joint publication of the Operations Research Society of America (ORSA – (410) 528–4146) and The Institute of Management Sciences (TIMS – (401) 274–2525). OR/MS Today is available by subscription to non-members of ORSA or TIMS.

Development has continued on this model, and a variant was written for the French terminal. This was a fairly straightforward task, because the essential logic of the terminal's operation remains the same. The input screens were rewritten with French text, and the physical layout of the terminal as it appears on the screen was changed to match the configuration at Coquelles. Both of these tasks were achieved using the SIMDRAW graphics editor, so reprogramming was not necessary.

Managers have been given access to the simulation from their own desks via a PC configured as an X-terminal The DECstation incorporated into Eurotunnel's network makes it possible to print off simulation-generated presentation graphics, such as graphs on a PostScript laser printer using the SimPost utility. The fact that MODSIM II had such utilities, and that it adhered to the Unix, X-windows and PostScript standards that Eurotunnel had already adopted, were further advantages justifying its selection. img

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI.




Related Content