Train doors & control theory


Passenger doors (Image Source: RailCorp)

What happens when lawyers do design…

I recently re-read the recommendations of the Waterfall inquiry, and got to the section of the report that detailed the Commissioner’s recommendations that passengers should be able to self evacuate from a train if train crew are unable to provide assistance.

Here are the three recommendations in relation to train doors:

Recommendation 90. All passenger trains must be fitted with an internal passenger emergency door release.

Recommendation 92. The internal passenger emergency door release should be fitted with a facility which prevents it from operating unless the train is stationary.

Recommendation 93.The operation of the train doors should have an override facility whereby the train driver or the guard can override an internal passenger emergency door release system if the door release is interfered with when there is no emergency. There should be an alarm, together with an intercom, in the train guard’s compartment so that, if a passenger attempts to initiate an emergency door release, there is an appropriate delay during which time an alarm sounds in the train guard’s compartment and the guard can then, after first attempting to speak via the intercom to the person concerned, if necessary, override the door release, and make an appropriate announcement over the intercom system in the train.

Now I’m a systems engineer, so I look at these recommendations in the first instance as requirements. Or to put it another way, how good are they as an input to the design process? R90 and R92 are straightforward functional requirements that require the provision of a safety function and an interlock for tha requirement respectively. The third requirement, R93, is much more interesting. This requires a complex time sequence of interactions between passenger, crew, the internal door release system as well as the train internal communications system. The purported reason for this is to allow the crew to override the passenger’s use of the emergency door release.

The first question that should be asked is whether this requirement is actually valid? If we consider the scenario that a crew have sufficient control over the train to be able to approve use of the emergency door release function why wouldn’t they simply open the train doors using normal (remote or locally located) crew actuated train door controls? Similarly if the crew don’t wish to let passengers open the doors then why have any interaction at all? Finally if the crew were incapacitated then all this complex interactions is simply irrelevant and control should devolve to the passengers.

There are other problems with R93 such as the insertion of a delay into the interaction (how do we update passengers on what’s going on during the delay), not to mention the statement of the requirement in the singular, when multiple door release usage could reasonably be expected in a real emergency.

The complexity of this requirement comes about because of the overlapping control modes (passenger and crew) of the door release function. Where you have such shared control you then have the potential for contention, which generated the need for a contention management scheme and this is ultimately why R93 is the longest and most complex of the recommendations. A better scheme would have been to separate the control modes (either crew are in control or passengers but not both) and eliminate the necessity to manage contention.

As to why this error of specification has come about, your guess is as good as mine. But in my experience a primary reason for these sort of errors is the specifier conflating a number of solutions that they are aware of into a single requirement. In this case the mixing together of the functions performed by an emergency intercom with that of emergency escape.

A good thing we got the lawyers to design the human machine interface isn’t it. 🙂