Hockham Road Level Crossing: Example of Accident Investigation

This was just one of the accident/near-miss investigations I read from the RAIB site, thanks to Mike D sending me the link.  It’s an excellent example (so were others, but this one had colored images enough to really “feel” the whole accident and its precursors on both the train side and the signallers’ side.)    Here’s the link again to that particular accident investigation report–dive in if you want, but I’m going to make a shorter outline of the accident and what I consider the most critical elements (similar but not identical to the investigators.)

https://assets.publishing.service.gov.uk/media/58e4f1d440f0b606e30000c3/R042017_170314_Hockham_Road.pdf

The accident occurred in April of 2016, on a stretch known as the “Thetford Line”.    Access to most of the 43 level crossings of this line (for pedestrians, cars, trucks, tractors with and without trailers, and livestock)  is supposed to be controlled by “signallers” in a separate facility, using computer displays to determine if it’s safe to allow the individual to cross.   Users (those doing the crossing) at many (if not most) of the crossings are expected to open and close safety gates on each side of the railway themselves, use the provided phone to call in to the signallers and obey instructions.  Traffic on the roads leading to crossings is highly variable, both by crossing and by time of day and time of year.

For instance, a safety assessment carried out in June 2014 found that “66 trains/day passed over the crossing, which was used by 24 vehicles and 8 pedestrians /
cyclists daily. During the harvest period (June to September) the vehicle traffic increased to 100-120 per day.”  And that’s for only one level crossing of the 43.  The Hockham Road crossing involved a road intended to be limited access, for use by the farm and farm employees of a particular farm in accessing fields on both sides of the railway, but sometimes used by paintball players as a shorter access to a paintball recreation center.  No information was given about its variation in use during one day (busy periods, slack periods.)

As a result of the overall traffic on, and across, the tracks, Signallers would experience multiple phone calls requesting clearance to cross within a short length of time on most days, and always during the harvest period, and in multiple locations on the line.  Trains had a speed limit of 90mph;  and passenger trains would usually run within 5 mph of that maximum for passengers’ sake.   Thus even a small error by a signaller could result in a collision, as a train running 90mph would cover 1.5 miles in one minute, and 132 feet or 44 yards in one second.

This accident involved a tractor pulling a trailer of feed and an auger.  The driver had been given clearance to cross the tracks, did not see the train (curve),  and pulled out in front of the train too close for the train to stop.  The train was traveling at 87 mph.   The driver did not hear the train’s warning horn from around a curve, because the tractor cab was soundproofed.   The tractor was totalled, with serious injuries to the driver and considerable damage to the train, from the initial collision, the auger punching holes in the sides of cars, and a wheel assembly of the tractor that came off and got under the locomotive.  Several passengers and the driver had minor injuries.

At first glance, this looks like it was entirely the Signaller’s fault.  On closer examination, which the RAIB certainly gave, the accident resulted from multiple failures by different entities at different levels…it’s a system failure to deal with human factors (training, scheduling, suitability for the job, failure to grasp the range of user behaviors, failure to prioritize the right things when commissioning software, etc.)  Humans, as well as machines, have performance limits, break down in various ways, and most of those ways are predictable *if looked for*.

First glance at the Signaller involved:  1) Due to his diagnosis of diabetes in the recent past, he’d been demoted to a lower managerial position that made him responsible for just the Thetford Line’s Signallers, and required him to “cover” for those who were not available, including (on the shift he was on) the others’ mealtimes.  2) He had been in his higher position when the new computer system was installed, and had expressed a dislike of it, and of the computer monitor displays.  (Looking at them, they’re “noisy” with information that distracts from what Signallers really need to know to make sound decisions on safety at level crossings.) 3) He had worked several successive night shifts the previous week, ending on Saturday morning, and accepted an overtime day shift on Sunday with insufficient sleep on Saturday.  4) He regularly worked overtime shifts as the unit was understaffed, and also had family responsibilities that cut into his sleep schedule (the family responsibilities are not described, but I wondered if his eagerness for overtime work resulted from a cut in pay in his new position and extra expenses relating to those responsibilities (new baby, sick baby, wife, child, or other family member.)  6) Although Signaller supervisors were expected to do annual training on every position they might have to fill,  with an expectation it would take place during a full shift of work,  he had not done that, and instead counted his random short “break period” stints as retraining.  7) On the day of the accident, he had come in at 6 am, and then at the lunch break for others, covered one position after another in succession, snacking at the desk.  8)  He admitted that he had “lost track” of the train involved in the accident, while trying to determine if a train on the other line was a threat (it was 10 minutes away.)  In the 15 seconds he spent on the phone with the user, the train involved covered 1.45 miles/minute, 127.6 feet/second…and thus in 15 seconds,  over a third of a mile.

But there’s a lot more to it.   Understaffing of the Thetford Line signalling crew meant that *all* the current active employees were taking considerable overtime–it was the “normal culture” to ignore the recommendations for adequate rest and just be there when needed.   The Signaller involved wasn’t doing anything they all didn’t do, and his boss expected it of them all…they weren’t funded to replace signallers leaving the system at a higher level.  This was certainly known to the hiring entity involves; they chose to depend on tired workers.  Constant fatigue becomes the new normal and most people (students, writers, everyone) are often unaware of how their performance is impaired by lack of sufficient sleep and recovery time.   Multiple complaints about both the computers and the other safety equipment were ignored.  In fact, additional safety equipment had very recently been removed from the Hockham level crossing (automatic train sensing equipment that gave users a red or green light depending on whether a train was imminent or not)  because its manufacturer had not completed a safety form desired by the railroad so that users were deprived of a system they’d been using to augment the signallers.    The Thetford station was not supplied with the number of display screens recommended by the system designer (only 3 instead of 4).

Worst–and definitely the responsibility of those who ordered the software system, not the signallers themselves–is in “Report 04/2017
Hockham Road UWC42March 2017 :  The information displayed to a signaller is not designed to help them judge when it is safe to allow a user to cross at a UWC.”   (My emphasis.)  In other words, from the beginning, a system intended for signallers to use *was not designed to help them do their  job: that of preventing collisions between trains and cross-traffic.*  Giving signallers the information they really needed–not the information someone else thought they should have or it would be nifty to have–should have been a top priority for the computer displays they used. Signallers were placed at risk of making fatal errors, not just from confusing, crowded, busy screen displays, but from not having the information they really needed to give quick, accurate responses to the calls they received.   The graphics on the screen–because of using section data referring to how the tracks were wired to the system–did not give the exact location of trains at any given moment, and there was a variable distance between “axle-counting” units where the trains were “located.” 

Given the number of trains, level crossings, and users, and the insufficient staffing that led to chronically tired workers, it was inevitable that signallers would make mistakes leading to near-misses and collisions.  Their job required them to make fast mental calculations based on variable train speeds, over variable distances, to decide when a train would pass a level crossing…and to trust that users’ estimate of how long it would take them to cross the tracks was accurate.  No one, apparently, had ever fact-checked the latter, and signallers (busy with multiple crossings and phone calls) didn’t have the time or ability to fact-check their mental calculations except when they were wrong.

The technology of computer monitors is adequate to support moving graphics that are easily understandable.  But for them to work well, the software must be tested *by potential users* not just software designers/programmers, and the project aimed at giving those users what they need.  (And I say this from my own experience creating software for a very large system–long ago, but the principles of making a system the *users* find helpful are still relevant, though languages, processors, etc. change.)  Unfortunately, too many people in the computer business assume that any user can learn quickly to use any software if you, the person introducing it, talks fast enough.   That is not true.  If you want users to use visual modalities, images that mean something other than “there’s a cat/dog/pony/person,” then you need someone who really understands what makes a screen of data easily used, or difficult to use.  (Edward Tufte is an international expert in this, not the only one, but I’ve read his books and gone to one of his one-day seminars.  Strongly recommended for anyone who wants to make data into easily understood graphical form.)    What a signaller needs to know is where a train is, and when it will be at the next crossing, and the interval between where it is and the next crossing requires a distance/velocity calculation a computer can do faster than most humans.  Therefore the screen should show that: “UP Train 177, 1 mile  to Hoxham Road, 0 minutes, 41.3793 seconds, NO CROSSING”.    Or even more simply “WAIT, TRAIN TOO CLOSE.”  Next train to cross, “DOWN Train 1K70 10 miles, check again after Train 177 passes”.   The signaller should be able to input the crossing desired, and both see a simplified graphic to scale (one train, one distance)  with clear text below.  (There are other options but that would work much better than what you see on the screen now.)  The signaller would only have to pick the right crossing from a list, something that can be done much quicker and more easily than trying to remember 143 different level crossings.   Sidebar the list, tap the chosen crossing, get the display of train number, track, and time to crossing.

From the POV of users, the safety gates should both be operable from either side of the tracks with one button push…no one should be required to walk across the tracks to open the opposite gate and again to shut the gate on the far side after crossing…that exposes the user to more danger.   Users need instruction on the information to give to the signaller about the vehicle type they’re going to cross in (large tractor, can’t hear train horns, trailer with feed & augur) as user estimates of time to cross the tracks hasn’t been validated.  Some vehicles (and ridden horses) should always be given a 2 minute safety margin.  (The day I ride across tracks,  Hell will be at a pleasantly cool temperature and all the demons will have vanished forever.  When I have to drive across a level crossing, I’m hyper, even if there are gates and they’re up. )  Was once surprised at a level crossing north of Leander TX: gates up, no lights flashing, but when I crossed, a loco was parked just out of sight (nighttime) with its light blazing in my driver-side window.   Why it was there, and “live” at that time of night I don’t know but I was still breathing too fast a mile down the road.

Anyway: I was disappointed that the RAIB did not identify the software design as the most basic of the problems here (perhaps knowing that it would not be replaced no matter what…but I’d fight for that, if I were in their shoes.)   They mention it, but not with the emphasis I place on it.  Yes, the Signaller Involved made multiple errors and so did his supervisor, and so did whoever decided that it was OK to work signallers into exhaustion, shift them around the clock on shifts, etc.  Yes, the system of uneven distances for sections of track adds to the confusion.   Yes, other elements of the track safety system leave holes big enough for tractors to drive through (the gates, the off/on addition/subtraction of other safety equipment.)  But the actual interface between user and signaller, and signaller and necessary data, involves a chunk of computer software that badly (dangerously) needs revision.   And someone authorized its development and payment for it.

Argue with me.  This is a fascinating case, and we can all get something from it.  I’m sure I haven’t learned everything it has to teach, yet.

 

 

 

5 thoughts on “Hockham Road Level Crossing: Example of Accident Investigation

  1. I’m not going to argue with you, I am going to say that the underfunding of the railways in the UK has caused a lot of problems like this. The separation of the train operators and track operator has not made the railways safer because they are not “pulling together”. The chosen solution to this sort of “accident” is an attempt to do way with level crossings entirely, but given the length of track, the number of level crossings and the money available for building bridges or underpasses hell will indeed have become temperate before this solution is fully implemented. As for the signaller, in Europe we have very strict laws about how long the driver of a heavy goods vehicle can drive for, about how often and how long breaks must be, and about the length of time between shifts, but not it would seem about how long and how often signallers can work.

    Part of the reason I’m not going to argue is that my husband is a public transport analyst, I regularly recieve rants about this sort of “accident”. Although less often about the railways since he stoppped his subscription to Modern Railways, because it was just too depressing to him. He does use the railway to get to work, but at the moment still works from home the vast majority of his time, and I do get rants about the line he uses. Mostly I now get rants about the local bus industry or the tram. Very informed rants, I find them interesting, but also frustrating as he has so little power to change obvious idiocy.

    1. Underfunding Amtrak (and urban transport–light railways, commuter rail, etc, is also underfunded) causes problems here, too. We have highways that have cut off local roads…including right here, where the bypass highway on one side of town truncated the last street running E/w out into the country…the way to a small church. That connected to a larger (still rural) road “out there”. Now the people who live across the bypass have to take a circuitous route to get to town, instead of going straight. The bypass comes off a hill, is on ground level, rises to overpass the town’s main street and stays up until it merges with the “old highway” through town and swallows it. They *could* have just continued the elevation of the hill all the way to the overpass over Main and not interrupted that street…the exit to town wouldn’t have blocked anything because that soggy field had never been built on. But instead they cut the road in two and made it inconvenient. I think crossings should not be eliminated but either the train goes up on stilts or the roads do. Should be easier with trains, as you don’t have people turning onto the rails and exiting off them in their cars.

      But here, everything subordinates to cars and trucks, and has for decades. A highway is considered more important than housing, schools, stores, etc. Streets can always be widened and two-lane roads turned into divided four or six lanes, because the Almighty Car Rules All. Roads are never destroyed to restore housing, businesses, agriculture, wild lands.

  2. Hi – Ever since the first rails were laid down, the matter of roads vs rail has existed. As a former railroader, in my dim past, I am acutely aware of the inherent dangers involved – and the train always wins – no car, truck, or other vehicle can withstand the sheer weight of a train. And there are praises and riches awaiting the person who can successfully come up with a foolproof way of preventing crossing accidents that both work and and relatively inexpensive.

    Stay safe and sane and enjoy the horses.

    1. Yeah, absolutely the train wins, but it is also sometimes damaged and passengers & crew may be hurt. I met a former Amtrak crew member on one trip, who had been badly injured in a collision with a concrete mixer (mixer truck’s driver thought it could win a race to the crossing…out in the desert in…Nevada? Somewhere in the desert, anyway. Saw train coming, thought it might win. A concrete mixer is a heavy vehicle, esp. if full of concrete.

  3. As Jazzlet says above, our railways are chronically underfunded. However, the vast majority of our level crossings are automatic, and safe, and our trains do run to relatively predictable timetables. It is the manual ones for pedestrians and, especially, farm vehicles that can be so dangerous. And, of course, those times when there is a signal failure and people decide to risk crossing…. or the boy racers who decide that there is time to get through before the gates come down.

Leave a Reply to Annabel Smyth Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.