renehsz

Exactly! Don't lock yourself in to a single provider, especially for email where it's fairly easy to avoid by using your own domain.

This take is so ignorant and provably false. I can't tell if you're trying to ragebait or if you actually believe this.

The autopilot does not do "almost all critical work", not even close. It only does some of the routine work (definitely not all of it). But the real critical work is when stuff goes wrong, dealing with emergencies.

The inherent complexity of aviation means that there are so many different failure modes and combinations thereof that no traditional system could ever handle all possibilities and edge cases.

I'm not going to claim that an AI could never do it. But as of right now, with current technology, well-trained pilots are absolutely critical to safety in even the most advanced airliners.

Also, the survivorship bias argument runs against you. Most events where pilots save the day are completely invisible. Like catching an incorrect clearance, a misconfigured approach, dealing with a technical malfunction, etc.

And even when disasters happen, it is very rare that simply engaging the autopilot would have saved the day. In fact, there are plenty of examples where the opposite is the case, and dropping to a lower level of automation would, in hindsight, have been better.

Guys, let's not turn everything into a trains vs cars debate. Obviously, trains are much safer.

But the argument that the relative risk of trains is far lower is, unfortunately, often used as an excuse to not take safety in absolute terms seriously. It's almost like saying: "Because trains are already so much safer than cars, the few crashes that still happen are just bound to happen, they're a fact of life we have to accept, and not worth doing anything about." (I am exaggerating, of course.)

But many of these accidents are in fact easy to prevent, even without huge investment in new infrastructure. So we should prioritize that and make our voices heard that we care about railway safety! And no, this is not a psyop to make people drive their cars more, that would be ridiculous.

Let's not jump to conclusions. Funding rail infrastructure is important, but it's not clear at all whether that would have helped prevent this accident. Malfunctions can happen even in the most advanced newly-built systems. Often the overall safety level depends more on how you deal with degraded states than how the system performs in its fully functional state.

LZB does cab-signalling and continuously supervises speed and braking curves. Combined with AFB it can accelerate and brake automatically to LZB targets. So regular operations are already partly automated (and have been for a long time). The system already doesn't rely on perfect driver attentiveness for safety. The driver should still watch the track ahead, but trains usually can't stop within line of sight anyway, so for separation we have to rely on the signalling system.

Drivers are absolutely still needed for other parts of the operation though, like working stations, shunting, and perhaps most importantly handling irregularities. Faults can happen and you don't want the train to be stuck out on the track for hours. Instead, it makes so much more sense to either fall back to lineside signals (often accompanied with a point-based train protection system) or driving within line of sight.

FBI open up

There is no doubt whatsoever that trains are far safer than cars. But often that fact is used as an excuse to not invest in safety. "We don't need to do anything to make thing X safer, because look at that other thing Y that people do which is way more dangerous." (I assume you didn't mean it that way, but some people really do make this argument.)

Human lives matter in absolute numbers, and we should strive to increase safety wherever possible with reasonable effort. Railways in some countries still have some very low-hanging fruit!

The aviation industry has shown that safety as the number one priority does not have to be prohibitively expensive. Layers of redundancy, excellent training, and very good investigations and changes based on their recommendations are what keeps the flying public safe.

Accidents still happen in aviation, but we're at a point of diminishing returns where increasing safety is getting quite difficult. When an aircrew encounters a problem, they can't just stop the plane mid-air to figure things out. The plane has to land, no matter what. That is inherently more risky.

Contrast that with a train, which can more or less just stop wherever it is when something goes wrong. This allows for building a lot of fail-safe/passively safe systems. When there's a problem, just halt operations and take your time to figure things out. Good procedures and adherence to them are still absolutely necessary, but at least there's usually no actual time pressure (only perceived) and malfunctions rarely pose an actual risk if handled correctly.

What aviation has also shown us is that accident investigations need to be 100% honest about underlying causes. "This guy made a mistake, too bad" is never ever an acceptable reason. We have to dig deeper.

People will always make mistakes. But how was such a simple mistake allowed to have such dire consequences? Were there not enough layers of redundancy? Was the training inadequate? Were the rules and procedures inadequate, underspecified, or unclear? Was there a company culture of bending the rules to get the job done? Was there a general lack of safety culture and incident management? Etc.pp.

> All the rules you spoke of by the way were already in-place

I had guessed that was the case, but didn't want to state it definitively, as I'm not familiar with the rules in Spain specifically. But that then raises the question of why the rules weren't followed.

> the rail operator instructed to continue at normal speed. When the train driver asked 'at normal speed?' the operator confirmed

As I explained earlier, "there's been a misunderstanding" is not good enough, I'm sure the report will dig deep to find the underlying causes and will issue plenty of recommendations to prevent this in the future.

I will refrain from speculating on what those causes are though, as there are far too many possibilities. But it's almost certainly a combination of multiple unfortunate factors that led to this horrible accident.

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

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.

Cab-signalling train protection systems like LZB (and more modern alternatives like ETCS) are generally considered to be sufficient to ensure safe separation. The interlocking only allows setting a route if all its sections are detected vacant, conflicting routes are locked out, and flanks are protected. Meanwhile, the train protection system prevents trains from exceeding their movement authority. These systems can even largely monitor themselves and are designed to be fail-safe (often by putting all signals on danger and letting the operators figure it out).

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

Tell that to the dozens of families who lost loved ones today! At least 68 people (and still counting) lost their lives. Ambitious, loving, caring human beings, who died completely unnecessarily! No excuse is good enough to justify that.

This type of accident is particularly unacceptable because it's so preventable! I'm not going to speculate on the causes before the official report is out. But a collision between two trains is not that hard to prevent with a train protection system. And if that system (or a component of it) crashes (or malfunctions in a fail-safe way), but operations should still continue, then there need to be safe fallback protocols in place that everyone is trained to follow.

One such rule might be, for instance, that following an electronic interlocking failure causing axle counter sections to be reset, meaning track vacancy cannot be proven, track sections must be swept by trains that may only run on sight at ~40km/h max.

"Someone made a mistake" is never an acceptable excuse. That's what we had to learn in aviation a long time ago. Nobody goes to work wanting to cause a fatal accident. The train dispatcher(s), driver(s), and whoever else might have been involved in this, (most likely) did not intend to cause this. But it is almost always a combination of bad procedures, normalization of deviance, lack of safety culture, bad training, lack of regulatory oversight, and of course inadequate technical equipment and safety systems, that together lead to fatal accidents.

Accidents like this one are fully preventable, there's no excuse, but that doesn't mean we should blame a particular person. Instead, it is the entire system, which is supposed to have multiple redundant layers of safety, that failed us. Investigators are going to come up with many recommendations to prevent similar accidents in the future. Let's hope (and make our voices heard) that these recommendations actually get implemented as well.

The security industry has a vested interest in spreading fear and panic. That's how they make money. But, to be fair, some of it may be necessary to motivate people to patch their stuff, so there could be good intentions behind it also.

In this specific situation, a lot of misery could have been prevented had the embargo not been broken. That's the crux of the issue: Chainguard's and Calif's incompetence and irresponsibility. Had the patch been out at disclosure, people could have updated quickly and wouldn't have had to choose between downtime and an unspecified risk of getting pwned.

There are only two types of people: Those who are security engineers, and those who pretend to be.