Snark aside, this also impacts resolution time, because done well, this instantly points out the most critical problem, instead of all the consequences of one big breaking. "Dear operator, don't worry about the hundreds of apps, the database cluster is down".
But like I said, I am not much of a C programmer. The compiler authors feel strongly about pushing past all possible errors and keep doing it so perhaps there is merit to this practice. but it bugs the heck out of me.
A year or two ago Visual Studio added a pop-up that parses such lengthy compiler messages into a clickable tree list. I found it annoying at first, until I discovered I could dock it to the side, ignore it 98% of the time, but still go look at the details when relevant. This is an idea other compilers should copy.
Maybe ships should copy this approach too: issue fewer warnings, but provide a list of warning details for review when necessary.
ECAM messages are recorded by the DFDR/CVR but are not normally transmitted via ACARS. Pilots were not normally aware of ACARS messages (see MH370).
Your point is a fair one though. In the case of AF447 the crew, against their training, made no attempt at all to work their way through the multiple ECAM messages with the appropriate checklist so they died. The final report on QF32 shows what a high workload this can be.
Since AF447 was lost for nearly two years the ACARS messages were all that the investigators had to go on until they found the wreckage and the DFDR and CVR. Incidentally, one problem with those ACARS messages was that they are only timestamped to the minute and may arrive out of order which makes the interpretation of them more difficult.
Boeing there's physical feed back, when one control moves so does the other.
This was not the first time pilots were having conflicting input without noticing.
>https://bea.aero/uploads/tx_elyextendttnews/annexe.01.en.pdf
You can see in the CVR that the stall indicator stopped many times despite them being in a stall the entire time. The pilot (like every other pilot) knew how to recover from a stall on paper. But he had the plane telling him his airspeed was good (frozen tube) and that bringing the pitch down was causing a stall.
It's in the last column in the transcript I linked.
Imo the whole average input issue would have been it's own Boeing MCAS level issue if it happened a decade later, that's more of the root here imo, since one pilot making a mistake is hardly unheard of.
When you’re panicking and the airplane is telling you what you’re doing is starting to cause a stall again, you tend to listen.
As a pretty decent driver, this terrifies me, because I first think, "What am I missing?" But then it hits me - these alarms and chimes are breeding generations of drivers, not just young ones, who are grossly incompetent and should not be driving.
The fact that I cannot control what alarms go off is asinine. And they put a lock on how low you can turn the chime volume. So, basically, you're telling me that I have to harass my neighbors at 5 am when I load the car for work, because you want to chime nonstop when the door is open and I have zero control to turn it off or lower than the locked minimum. Oh, and don't forget the threats of voiding the warrantee if you dig deeper to disable anything. My favorite alarm and warning pops up randomly when you're driving, sometimes blocking the map, and it says something to the effect of, "Remember to stay focused on driving!"
I see this slipping into not just alerts and notifications, but also ads. Waze does not care if they block my directions by blasting an ad on part of my screen, which has absolutely caused me to miss exits since they don't want to tell you the exit ahead of time on longer strips, only, "drive for 45 miles"...
I see this like popups, and if industry can't handle themselves they need to be forced to stop doing this altogether and find a rework, since it's clearly affecting private and public machines that could burnout or kill people.
The ECAM system is what displays issues to the crew. There is a lot of logic there on what to show and what to inhibit. For example some errors aren't shown during takeoff since it's more important to focus on safely starting the climb, they would only be shown once past 400ft altitude.
There is also a priority order based on criticality, they don't just show up in chronological order. Engine fire for example is a red warning and would always come above a yellow caution message. It's designed in a way where the results of the major problem (e.g. engine on fire, and then loosing electric power from that side) are lower priority than the problem itself.
Right. The lingo for this is “cascading alarms”, and there are various mechanisms to suppress consequential alarms if you design well. If an “upstream” alarm results in further alarms/events downstream; these should be suppressed (still recorded, just not alarms), until the root alarm cause is resolved.
I thought this was well understood in the industry, but perhaps not.
There have also been fatal aviation accidents where there's a problem with a common system (a dip in the power supply or hydraulic pressure, or a problem with a critical sensor) and dozens of systems sound alarms at the same time [1].
And for a technology example, a database server disappearing might raise a single alarm, but the applications that rely on that database might raise countless alarms as attempts to connect fail over and over again.
[1] https://en.wikipedia.org/w/index.php?title=Air_France_Flight...