30 years of QNX: Chunnel train drivers gear up with QNX-based simulators

It was the early 1990s, and the folks who built the Channel Tunnel (aka the Chunnel) had a problem. To make the Chunnel commercially viable, they had to reach a goal of 1200 train crossings per day. But to do that, they needed lots of train drivers. Which meant they had to train lots of train drivers.

Being a Chunnel-train driver isn’t easy. You have to work equally well in English and French. You have to be ready at a moment’s notice to execute a variety of emergency procedures in case of fire, breakdown, or accident in midtunnel. And you have to embrace the notion of driving 100 miles per hour through a 31-mile tunnel that lies 330 feet below the sea bed. Claustrophobics need not apply.

So how were the folks running the Chunnel going to train enough drivers to handle all that? Not by using the tunnel itself, since it would be open for business 24 hours a day.

The solution was simple: use simulators. After holding international competitions in 1991, the chunnel folks chose a French firm, EBIM, to provide QNX-based simulators for the Eurostar, C92, and Le Shuttle trains.

Here's a photo of a reporter taking the EBIM simulator for a virtual drive, circa 1993. I know it's hard to believe, but photojournalists were still shooting in B&W back then:



What led EBIM to choose QNX? Allow me to quote Philippe Rose, who worked for EBIM at the time:

"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."