[–] renehsz 1 day ago
[–] thatfrenchguy 1 day ago
[–] ryathal 1 day ago
[–] HeyLaughingBoy 1 day ago
[–] iggldiggl 15 hours ago
The signalling system has already all the necessary data here, the trains by default none to few of it.
Hence it is usually way more tractable to just improve the reliability and functionality of the signalling system itself and don't bother with complicated technical fallback solutions.
(Things might look differently if you've only got single track lines and no modern signalling system in place – in that case a TCAS-like system might be worth it and not too difficult to implement, especially if you limit its scope to the plain single track line outside of station areas.)
Flying is different – the difference between your positional accuracy and the minimum safe separation between planes is way more favourable, so detection of potential conflicts is much easier.
And – while these days air traffic controllers do usually have computerised aids available to detect impending traffic conflicts, ultimately the system still relies on controllers correctly detecting any conflicts, issuing the correct commands to pilots, and those pilots then correctly executing those commands, too. That's a lot of human in the loop, so the impetus for some fallback safety system (TCAS or whatever) is much stronger.
With trains on the other hand, the default state for any kind of remotely modern signalling (for at least a few decades already, actually) is that the signalling is able to automatically ensure that the route is set correctly, that no conflicting routes are set and that no other trains are occupying the route. Likewise, even without full automated driving it is still possible to ensure that trains are actually following the commands of the signalling.
Hence with railways, the appetite for a completely secondary technical fallback systems to cover outages of the primary signalling system has been much lower, and like I said, it is usally more tractable to try improving the safety and reliability of the primary signalling system. (Though yes, for the fallback case you also need to properly prepare appropriate manual procedures that take into account the increased failure risk of manual operations…)
[–] HeyLaughingBoy 14 hours ago
I worked on a system that sat in the railroad right-of-way and by necessity had to detect an oncoming train from at least half a mile away due to our response time. We were aware that the railroad already had the data on where the trains were, but for RR safety, there was no way that we could get access to that, so we had to place our own sensor next to the track.
You raise an interesting point that if you're near a switching point, you need to know the point's position to determine if there's a potential collision. For my system, it was placed far enough away so that was not an issue: if we detected a train, we knew it was coming our way.
[–] acchow 1 day ago
[–] iggldiggl 15 hours ago
[–] namibj 1 day ago
The automatic coordination system hit a fail condition; they neglected the fallback protocols that had rules for spacing determined to work reliably without the computer keeping real time supervision; they crashed.
This is in the way more like the Washington D.C. helicopter plane mid-air where some normalization of deviance got people to ignore automated protection systems.
If most involved had known the fallback protocols they would have refused to move/continue while the protocols were utterly neglected. At least with a robust safety culture active, ofc.
[–] renehsz 1 day ago
I think that's not quite accurate. Yes, there was a normalization of deviance. But it wasn't primarily that automated protection systems were ignored.
First, the systems on board both aircraft could not have saved them. TCAS resolution advisories are inhibited below 900ft AGL and aural traffic advisories are inhibited below 400ft AGL. The aircraft collided below that altitude. The system wasn't ignored, it just doesn't do much at low altitude. The RJ crew got a TA about 20s prior to the crash, but that's not something that would normally require evasive action (they're trained to act immediately on an RA, not a TA). They were set up for landing. It's hard to find any fault with them.
The RJ wasn't equipped with ADS-B In, and the helo's ADS-B Out was misconfigured since installation. ADS-B In could have alerted both crews almost a minute prior to impact. But it wasn't available.
Second, if you're referring to the tower: Yes, the controller did get an automated conflict alert, but he did not ignore it. He asked PAT-25 whether they had the RJ in sight and told them to pass behind it. This response wasn't good enough, but that's mainly attributed to the controller's high workload and time pressure leading to omissions.
A proper traffic advisory should have included azimuth, distance, direction of travel, and type and altitude of the conflicting aircraft, e.g.:
PAT-25, traffic ten o'clock, one mile, north-west bound, a CRJ descending through four hundred, circling approach to runway 33.
A proper safety alert should also include an action to resolve the situation, e.g.:
Traffic alert, PAT-25, traffic ten o'clock, one mile, a CRJ on final for runway 33. Advise you [descend/turn] immediately.
Either one might have prevented the accident. But when ATC gets busy, the reality of those calls often looks quite different than how they're described in a textbook. Combining local and helicopter control with 12 aircraft on frequency is just too much. Of course, that leads to routine conflict alerts (5 separate events in the 18 minutes leading up to the crash). Sure, nuisance alerts lead to desensitization (and the report discusses that), but here the workload seems to have been the bigger underlying factor.
Of course, this is far from the only contributing factor. The normalization of deviance that the NTSB actually found are that visual separation had become the primary way of separating helicopters from aircraft, helicopter crews reporting "in sight" when they hadn't positively identified the traffic yet, the tower trying to "make it work" rather than forcibly slowing operations down, etc.
That in addition to putting a helicopter route as little as 75ft below the approach path, the helicopter's altimeter being 100ft off (within spec!), the helicopter crew's use of night vision gogggles severely limiting field of view, helicopters and fixed-wing aircraft being on separate frequencies severely limiting the RJ crew's SA.
And perhaps most egregiously, the FAA ignoring the countless warning signs (15 thousand close proximity events over 3 years, are you kidding me?) Failing to fix the helo route, failing to reduce arrival rate (the request from Potomac TRACON wasn't forwarded due to being "too political"), failing to improve the tower's conflict alert software... People did not ignore automation, the regulators ignored lots of growing holes in the slices of Swiss cheese.
But in those cases where the system does crash and reset, how can operations be started again? That's where you need well-specified fallback procedures. One such procedure might be that, in case axle counter sections to lose their counts (because of a crash of the interlocking or the axle count evaluator), causing affected sections to show as disturbed and mandating a manual reset, each section must be swept by a train running on sight (under a caution order in LZB or OS mode in ETCS).