Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Alaska Airlines flight 1282 NTSB preliminary report [pdf]

ntsb.gov

Post reply on HN
Print view View original

141–150 of 285 posts

Re: Alaska Airlines flight 1282 NTSB preliminary report [pdf]

#141

Post by cjbprime »

imoverclocked wrote: post #114
cjbprime wrote: post #102

Earlier quoted context omitted.

I'm not an accident investigator and don't know what exactly would turn out to be useful, but I think changing your intuition for why we study the CVR away from "because there might have been a large pilot error" to "so that we can learn more about how pilots react to emergencies with a goal of seeing if we can come up with process improvements" may help. If there was some aspect of the response that was not perfect,…

That's not what is at stake here though. CVRs are not intended for improving process like a call-center recorded line. "Both recorders are installed to help reconstruct the events leading to an aircraft accident." [ntsb.gov] This creep of intended-use is exactly why many people oppose surveillance in the first place.

I don't understand. You're saying that the purpose of cockpit voice recorders is not to improve aviation safety via allowing a thorough investigation of accidents? If there is any other purpose, I don't know what it would be.

Re: Alaska Airlines flight 1282 NTSB preliminary report [pdf]

#142

Post by wmidwestranger »

toast0 wrote: post #126
cezart wrote: post #117

Earlier quoted context omitted.

At a company I worked in, we had a joke about this: "Good thing we don't build nuclear reactors". In some software projects the level of rush, and the fact that bugs sometimes would leak into production was kinda horrifying. It would've been way more so, if it would've been the kind of project that could kill people in case of failure. Like it happened in Chernobyl with nuclear reactors, or at Boeing with planes. I c…

Quality is always a trade-off. If you're deeply into economics, you wonder about the trade-offs of cost to find defects before shipping, difference in cost of addressing defects before and after shipping including costs of mitigation from consequences of defects, % of defects that will never be found after shipping (and are therefore a real cost savings), and in the long game costs of having a reputation for shipping…

> Mitigation of many software defects is simple, but some aren't; hopefully you know which changes are expensive to fix if wrong, so you can more thoroughly vet those.

This assumes you're fortunate enough to have a defect at the outer edge of the system. Most times, these problems are created in the initial rush of pushing something out and then tax every effort that depends on them, forever, and ever.

Re: Alaska Airlines flight 1282 NTSB preliminary report [pdf]

#143

Post by advisedwang »

stefan_ wrote: post #133
dzdt wrote: post #25

The report seems to mesh with and confirm many details of the anonymous insider account at https://leehamnews.com/2024/01/15/unplanned-removal-installa... . The bolts were not reinstalled following work on the plug rivets/seal. The official system doesn't record that work was done requiring the bolts to be removed.

[flagged]

It's a preliminary report, they deliberately avoid including conclusions that might be reversed later but would do harm by inclusion at this stage.

Re: Alaska Airlines flight 1282 NTSB preliminary report [pdf]

#144

Post by calebpeterson »

ethbr1 wrote: post #135
michael1999 wrote: post #69

Earlier quoted context omitted.

The issue here isn't using google chat, the accusation is that this was Spirit and Boeing conspiring to not record these in the proper work order system under the pretence that this work was being done by Spirit as-if-it-were pre-delivery. Read https://www.airlinepilotforums.com/safety/146074-boeing-inte... And then this from the doc: "The investigation continues to determine what manufacturing documents were used to…

A key point I read somewhere in the accusations is that non-Boeing contractors (e.g. Spirit) by policy cannot have access to CMES. Consequently, you have a system of record that a major party to work doesn't have access to. As we've all seen, this leads to "actual coordination" being instead done in a system all involved parties do have access to (SAT). Which inevitably leads to a desync between CMES (SOR by fiat) an…

SOR - system of record SAT - ? CMES - ?

Re: Alaska Airlines flight 1282 NTSB preliminary report [pdf]

#145

Post by wmidwestranger »

belter wrote: post #46
jbverschoor wrote: post #20

Earlier quoted context omitted.

Just comment out the tests and they pass

Instead of Software Development becoming more like Aeronautical Engineering, every day, Aeronautical Engineering becomes more like Software Development...

Almost every software engineering book:

Halting on an error is often best, as is raising the error after catching it, unless you're certain it should be subdued or aware, expect the issue, and have limited risk.

Every dev project:

Hold up, couldn't this raise an exception? That's bad!

Re: Alaska Airlines flight 1282 NTSB preliminary report [pdf]

#146

Post by renewiltord »

belter wrote: post #46
jbverschoor wrote: post #20

Earlier quoted context omitted.

Just comment out the tests and they pass

Instead of Software Development becoming more like Aeronautical Engineering, every day, Aeronautical Engineering becomes more like Software Development...

Well, to be clear, I don't usually put people in danger. There's a lot these engineers could learn from software engineers: who are really the highest performance at engineering as a craft. One base rule: Above all, kill no one.

Re: Alaska Airlines flight 1282 NTSB preliminary report [pdf]

#147

Post by bigiain »

zer00eyz wrote: post #100
hencq wrote: post #76

Earlier quoted context omitted.

I think there's some validity to the privacy concerns, but it seems those could be addressed with proper access controls and rules. The recordings should only really be listened to in the aftermath of an accident, in which case, as you say, the expectation of privacy should (in my opinion) take a backseat.

On one hand I agree with you. On the other hand, if someone recored my whole work day every day I would not be happy. I don't think you would stay at your job of that was a condition of it. There has to be a better solution to this issue.. extended recordings in an emergency, triggers based on conditions, private keys for pilots... IDFK, cause I try not to get involved in engineering that might KILL someone.

> if someone recored my whole work day every day I would not be happy

I'd be perfectly fine with not voice recording people who's daily work may or may not impact the global delivery of cat pictures.

I think if you choose a job where there are several hundred people's lives on the line relying on you doing your job professionally and correctly, the expectation of privacy argument is somewhat less convincing.

> I don't think you would stay at your job of that was a condition of it.

Some people literally have no choice. Do you think _any_ Amazon delivery driver is "happy" with their on-job surveillance? Do you think _any_ call centre worker is "happy" with "calls are recorded for quality and training purposes"?

Re: Alaska Airlines flight 1282 NTSB preliminary report [pdf]

#148

Post by hinkley »

aftbit wrote: post #13

> The accident airplane was required to be equipped with a CVR that retained, at minimum, the last 2 hours of audio information, including flight crew communications and other sounds inside the cockpit. >The CVR was downloaded successfully; however, it was determined that the audio from the accident flight had been overwritten. The CVR circuit breaker had not been manually deactivated after the airplane landed follow…

The piece of hardware that was chosen for the avionics-adjacent software I was working on was chosen before any software was written, which was 3 years before the plane was 'supposed' to fly, and 5 years before anyone sane expected it to be in service.

Irritatingly, they didn't even pick the top-of-the-line machine from the vendor at that time. They picked a middling one. And then put an LTS OS version on it that didn't fully support the motherboard chipset. I spent way, way too much time an energy trying to get the software to run on the sort of timescales necessary. It took me months to get anyone to let me talk to the vendor in order to sort out the fact that the storage was being run in legacy PATA mode, reducing our IO throughput by an order of magnitude and the application throughput by about a third.

Ten minutes on the phone and I got them to agree to give us a patch that aliased the chipset to one it was backward compatible with, that was actually supported by the OS. But they really wanted us to take the never version of the OS that didn't have this problem.

That's not even the most hard-ware crippled I'd ever been, but it was top three.

Re: Alaska Airlines flight 1282 NTSB preliminary report [pdf]

#149

Post by bombcar »

aftbit wrote: post #19

Depressurization happened around 17:12:33 PST but the aircraft continued to climb until 17:13:41 PST, and the autopilot was configured for 10k ft at 17:13:56 PST. Why did it take the pilots a full minute to begin an emergency descent after the failure? I would expect that the nature of the accident would be clear nearly immediately, at least in the need to descend the aircraft.

You follow the procedure because in an emergency you don't know what is going wrong.

Better to climb for a bit more as you get your oxygen mask on than to try to descend immediately and make some problem worse.

We know it was a door plug blowing out, but in the past it has been entire major sections of the airframe ripping off, in which case sudden extra stresses are not what you want.

Re: Alaska Airlines flight 1282 NTSB preliminary report [pdf]

#150

Post by ethbr1 »

calebpeterson wrote: post #144
ethbr1 wrote: post #135

Earlier quoted context omitted.

A key point I read somewhere in the accusations is that non-Boeing contractors (e.g. Spirit) by policy cannot have access to CMES. Consequently, you have a system of record that a major party to work doesn't have access to. As we've all seen, this leads to "actual coordination" being instead done in a system all involved parties do have access to (SAT). Which inevitably leads to a desync between CMES (SOR by fiat) an…

SOR - system of record SAT - ? CMES - ?

They're described in parent's first link. Boeing systems.
Post reply on HN