Staying on Track with QNX: Simulators Prepare Train Drivers to Cross the Chunnel

Philippe Rose, EBIM S.A.

When the Channel Tunnel becomes fully operational, it will be best described by just one word--busy. At peak periods, trains will enter this 31-mile link as often as every 2 1/2 minutes, traveling at speeds of up to 100 miles per hour. These trains include:

Le Shuttle

to transport cars, trucks, and buses; operated by Eurotunnel, the company that controls the tunnel

Eurostar

to carry passengers between London, Paris, and Brussels; operated by the national railways of Britain (BR), France (SNCF), and Belgium (SNCB)

Class 92 locomotive (C92)

to haul freight between regional centers in the UK and continental Europe; operated by BR and SNCF

Although various control systems and special technologies help coordinate and protect tunnel traffic, the tunnel still places remarkable demands on the person behind the wheel. Every tunnel-train driver must learn to:

• feel comfortable driving for half an hour through a tunnel that lies as much as 330 feet below the sea bed
• execute a variety of special emergency procedures in case of fire, breakdown, or accident in midtunnel
• work equally well in English and French

And there's more. For example, to drive the Eurostar, which travels between Britain and Europe without a crew change, a driver must also learn the different signaling systems and operating procedures used in England, France, Belgium, and the tunnel. Clearly, intensive training is de rigueur for the tunnel-train driver. But how do you present every driver with all the possible situations he must learn to handle? Not by using the tunnel itself, since it will be open for business 24 hours a day. In any case, using actual trains to teach driving techniques and special procedures is prohibitively expensive. For these reasons, BR, SNCF, and Eurotunnel all decided to use simulators as a key component in their driver-training programs.

Taking advantage of QNX's networking and fast response times, EBIM re-creates the experience of driving high-tech Chunnel trains.

After holding international competitions in 1991, these companies chose our firm, EBIM, to provide simulators for the Eurostar, C92, and Le Shuttle. Since then, SNCF has also asked us to provide a simulator for the TGV Reseau, a train that connects Paris and Brussels. So far, we've installed train simulators in:

• London (for the Eurostar and C92)
• Lille, France (for the Eurostar, C92, and TGV Reseau)
• Folkestone, UK, and Coquelles, France (for Le Shuttle)

These simulators are used from 6 am to 9 pm daily, and are all based on QNX

A modular architecture

Founded in 1962, EBIM has long been active in developing aircraft and submarine simulators for the military as well as simulators for nuclear installations. Our simulation department includes an R&D team of about thirty engineers and technicians whose specialties run the gamut from mechanical engineering to electronics, CAD, engineering instrumentation, and realtime computing.

When we create a train simulator, the train itself is normally still under development. And even if the train is already in use, equipment and operating procedures may continue to evolve. As a result, we've adopted a modular architecture that lets us support any changes simply by updating or replacing discrete pieces of hardware or software. This approach also lets us develop new simulators very quickly.

QNX has not only helped us achieve this modularity but has also provided the realtime performance required for realistic simulations--our train simulators can immediately generate appropriate sounds, images, and movements in response to any action a trainee might perform.

The simulator architecture includes the following major components:

• cab (with optional motion system)
• driver's control desk
• sound system
• visual system
• instructor and trainee stations

Cab To reproduce the physical sensations of driving an actual train, we mount the simulator cab on a three-axis motion system. This system can make the cab feel as if it's accelerating, decelerating, shunting, or veering around corners. The cabs in Lille for the Eurostar and the C92 both use this system.

Driver's control desk Inside the cab, everything looks and works as in a real locomotive. All instruments are controlled by computer to produce realistic responses to the driver's actions. For example, let's say the cab's signaling system indicates a reduced speed limit on an upcoming section of rail. In real life, if the driver fails to slow down quickly enough, the emergency brake would activate. In the simulator, the driver experiences all the sensations the emergency brake would create--abrupt cab movements, changes to display instruments, and the roar of escaping air.

Sound system To emulate the sounds of braking as well as any other sounds a driver may hear (e.g. engine noise, passenger alarms), we use samples recorded on board actual trains. In the simulator, a computer synthesizes the sounds, then mixes, filters, and regenerates them to achieve audio quality comparable to commercial digital recordings.

Visual system To reproduce what the driver would see on the line ahead--signals, stations, landmarks, and so on--we use a synthetic image generator. Images created by this device are based on computer-generated diagrams as well as recordings made from a helicopter flying low over the train lines.

With this technology, we can reconstruct entire journeys from, say, Paris to London. Furthermore, we can easily present situations that would be impossible to recreate with traditional video recordings. For example, we can emulate day or night conditions with various degrees of visibility. And at any point during a simulation, we can introduce signal changes, vehicles crossing the line ahead, and so on. The images are so convincing that people sometimes "feel" the cab moving even when no motion system has been installed!

Instructor and trainee stations In a room next to the simulator cab are two stations--one for additional trainees, the other for the instructor. The trainees' station has three screens. The first screen displays a video image of the cab's interior so everyone can observe the driver's actions. The second screen displays the track images generated by the visual system. The third screen reproduces the main driving instruments--these indicate speed limit, actual speed, brake-pipe pressure, voltage, and so on. 

The instructor's station has four screens. The first three are similar to those in the trainees' station, except the screen that reproduces driving instruments also displays a graphical animation of the train moving on the track, along with the signals and events the train will encounter. The fourth screen, a touchscreen, lets the instructor control the exercise. 

With the touchscreen, the instructor can choose the itinerary as well as introduce various events during the simulation (e.g. signal changes, brake failures, alarms set off by passengers, mechanical problems requiring that a car be uncoupled). The instructor can even place obstacles on the track or create fog. By holding radio conversations with the student in the cab, the instructor can also play the role of crew member. For each session, we record the instructor's actions in a file and record what happens in the cab on video tape.

While the simulation is in progress, each trainee can flag points of interest by pressing a button on his desk. Later, when the instructor plays back parts of the simulation, these flags will show up on his screen, letting him stop at points that trainees wish to discuss.

Track database

The information for each itinerary (e.g. Paris to Brussels) is stored in a track database. This database is built in an off-line phase during which geographical information is extracted from the image-generator database, then merged with logical information. Logical information can include switching points, radio channels, landmarks (e.g. tunnels, stations), and so on. We have about 4000 items in each itinerary's database.

For example, in building a database, we could merge this geographical information:

• "signal C103 is located at km point 13.302 on track 2N on the way to London" with this logical information:
• "signal C103 can show red, two reds, yellow, flashing yellow, green, flashing green"
• "speed limit is 60kph"
• "the security system must trigger if the train passes the signal when the signal shows 2 reds"

When a simulation begins, the track database is loaded into a shared memory segment. This segment is then accessed by processes that manage the database, the instructor"s screens, and the trainees" screens.

The PC advantage

We chose PCs as the hardware base for our simulators because they not only cost much less than conventional workstations but also free us from being tied to a particular hardware vendor. And since each new generation of X86 processors maintains backwards compatibility, we can upgrade to faster hardware as it becomes available without having to make changes to software.

OS choice made easy

We chose QNX because it was the only PC-based realtime OS that came ready with all the facilities--windowing tools, realtime functions, networking--that would allow us to achieve our design goals.

Our first major goal was to make the simulator easy to operate. Because most instructors aren't familiar with computers, we wanted to provide an intuitive GUI interface, preferably one that used a touchscreen.

We also wanted to develop software that could evolve easily as specifications are updated. When we first started working on the simulators, none of the trains existed. What's more, safety procedures and characteristics of rail lines were still changing.

Finally, we wanted to achieve the fastest response times possible so that simulations would be realistic. When a trainee pulls the horn, it must sound without delay. Pressure indications and cabin movements must change immediately when he brakes. The synthetic images used by the visual system also require a high refresh rate--a new train position must be provided every 40 milliseconds (i.e. 25 images per second).

QNX let us achieve these goals easily. First of all, creating interface prototypes with the Interface Editor took very little time, even though we had no previous experience with windowing systems. And the software architecture we created not only adapts easily to evolving specifications but even helps us make the most of QNX's fast response times. For example, during the integration phase of a simulator we sometimes boost performance by adjusting the initial distribution of processes. Doing this is easy since QNX processes are inherently network distributed--whether two processes exchange messages on the same node or across the network, the code is exactly the same.

Great expectations

Government, industry, and the traveling public all expect a lot of the Channel Tunnel, with its promise of delivering goods, services, and people between England and France faster than had ever been thought possible. To live up to this promise, the tunnel will be in operation 24 hours a day and handle up to 24 trains per hour, in each direction. Without simulators, the rail companies using the tunnel simply couldn't mobilize enough drivers to operate all those trains. And without QNX, we would have been hard-pressed to achieve the realtime performance and modular architecture that help our simulators keep pace with advances in train technology.