There were two independent systems.
You can argue thats not a sufficient third redundancy, I don't have enough context to throw an opinion out there on the safety of this particular infrastructure project.
I am confident that the fallback process was considered and kept in place as the tertiary backup.
Excellent point though. It took me some thinking to put myself back in SRM mindset and what they'd have considered here.
Not really. Triplex redundancy is based on a failure model where failures can produce arbitrary output. Three systems allows majority voting (often, median select) to provide correct output in the presence of a single arbitrary failure. It allows detection of double-fail-silent failures and uncorrelated double failures, but that's not really the point, since continued operation under these conditions is at risk, and failing nonoperational isn't often acceptable for these systems. (You'll also see quadruplex systems that use the same voting mechanism to detect and disable failed channels, allowing handling two arbitrary non-simultaneous failures, for systems that need a longer window of continued operation after failure.)
If you change the failure modes, you change the architecture. These days you often see dual-dual systems where each pair of systems cross-checks and disables itself on mismatch, converting a single arbitrary failure to a single silent failure; which then allows downstream systems to accept inputs from two such fail-silent systems and trust either that is providing output, removing the need for a median select.
What’s a better way? We still don’t have state-regulation/certification for software in safety critical systems, which terrifies me when I think about it.
The pilot no longer had flight controls. He desperately tried to control the airplane using variable thrust, but it just wasn't good enough, and crashed into a mountainside.
The fix was to add automatic valves in the lines so loss of pressure wouldn't bleed out the whole system.
So in reality you didn't have two systems.
otherwise you would have shut down operations until you had another connection live, so you had 2 online connections.
There is a strong difference between an airport going down and ATC causing and accident.
Uptime isn't safety, they have very orthogonal characteristics.
These airplanes are flying all over the world, the inspections need ultrasonic data, and the FAA has to validate that all of them are done. Even identifying this issue required lots of bureaucracy.
Multiply that by the number of airplanes and airplane models and it's easy to see why they move so slowly: when you are putting millions of people in the air each day, enforcing absurdly specific rules with an iron fist requires a monster of a bureaucracy.
In a perfect world, we would move at a steady pace, as to keep up with the world but without rushing, and people would be accountable without a heavy bureaucratic processes.
Unfortunately, that's not how it works in practice, at least not for long, so between the two, we usually favor the slow and bureaucratic process when safety and reliability matter.
I can understand not changing a system for change sake, but the floppy disk has been obsolete for nearly 20 years now. It's been hard to find a floppy disk reader for the last 10 years. Going so slow that you can't respond to that change is far FAR too slow.
As you pointed out, you can't find floppy discs or disc manufacturers any more. I do remember one of the VP's of this company saying as long as they keep teaching Fortran to college engineers, they have no reason to upgrade yet. That got a few raised eyebrows from our team. We relented and upgraded what they were comfortable with - but man oh man it was quite the eye opener for me as a young dev how the thought processes of the people running these companies really are.
As long as those manufacturing systems were air-gapped and working, I can understand being conservative with changes. Of course at some point you're at risk of hardware failures too, for things that are likely NLA.
Yeah, that's really the biggest issue with these systems. Were I one of these manufacturers I'd invest in getting the current software running in a VM specifically to make it easier to transition to new hardware. The last thing they'll want to deal with is that their software was written for Sun Spark and that no longer exists.
That said, hard to go wrong porting over the x86 at this point.
Some of the signal control infrastructure for the Melbourne rail network was ported over to an emulated PDP-11 System for this reason. This was previously discussed on HN here: https://news.ycombinator.com/item?id=42514553
My humbling Claude experience was pointing at a codebase it took me weeks to get to a good 2003 standard, and watch it do the next fifteen years, cleanup, refactoring, feature additions that needed the tech debt solved I never got round to first, in minutes.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
But creating a bureaucracy doesn't mean you've created a rigorous process to ensure safety.
'Move fast and break things' is fine when the result of failure is someone failing to make a billion dollars at their IPO. It's not acceptable in the world where failure means dams break, reactors go supercritical, planes collide, or other similarly apocalyptic scenarios.
Aviation involves constant unpredictable human inputs and physical states. Hundreds of vehicles, not installations designed to have as few moving parts as possible. It is not yet solved, the status quo merely has a societally tolerable death rate. There can be new sensor hardware, more safety redundancies, and info synthesis/notification interfaces that are currently blocked by old hardware bottlenecks. Controller and pilot time and attention is limited, and it can be wasted less.
And inversely... when pilots leave too much to automation, their skills may degrade to the point that by the time you actually need a capable human crew because something has gone terribly wrong, the capability of that crew has degraded too much, and the FAA has warned about this in the past [1].
[1] https://medium.com/faa/the-dangers-of-overreliance-on-automa...
Also, there's a big difference between a small towered airport in a more rural area, and a major international airport with 10x or more the commercial traffic. So there's probably some difference of buildout depending on the facility usage.
Quick edit: looks like there were two fiber cut incidents recently, one at an airport last month, and the TRACON issue that happened 1.5 months ago!
Backhoes can disrupt connections, but so can failures to pay bills.
Systems like the radar in question often cannot work with broadband and satellite links.
Engineering will not save you from incompetent governance.