Live data from Hacker News

Delays in Boeing Max Return Began with Near-Crash in Simulator

bloomberg.com

71–80 of 199 posts

Re: Delays in Boeing Max Return Began with Near-Crash in Simulator

#71
post #10

FWIW, the near-crash in the simulator was apparently not directly related to MCAS, but occurred when Boeing "simulated what would happen if gamma rays from space scrambled data in the plane’s flight-control computers." > In one scenario, the plane aggressively dove in a way that mimicked what happened in the crashes on the grounded jetliner, the people said. While such a failure had never occurred in the 737’s histor…

> a simulated edge case involving "gamma rays from space"?

People have nearly died because of exactly this situation. See, for example, Quantas Flight 72 [1], in which a pair of sudden, uncommanded pitch-down manoeuvres that caused severe injuries -- including fractures, lacerations and spinal injuries -- to several of the passengers and crew.

A long and detailed investigation essentially concluded that these events were most likely caused by the CPUs not being sufficiently rad-hardened. The pilot was diagnosed with PTSD, caused in part by being totally out of control, and quit his career [2, 3].

[1] https://en.wikipedia.org/wiki/Qantas_Flight_72 [2] https://www.smh.com.au/lifestyle/the-untold-story-of-qf72-wh... [3] https://www.harpercollins.com.au/9780733339745/no-mans-land-...

Re: Delays in Boeing Max Return Began with Near-Crash in Simulator

#72
post #69
post #12

The can of worms has been officially opened, and this may turn out to be a case study in how bad software and outsourcing your centers of excellence can bankrupt a company. If TFA is to believed, Boeing has embarked on a project to take what is currently a master-slave failover design and jury-rig it into a master-master real-time system. This is based on bad performance in the simulator—not because of MCAS—but while…

>Landing contracts for key systems on the Max cemented a relationship with Boeing that Collins had long cultivated, in part by creating what its chief executive in 2002 called an “enormous sea change in a very long legacy business." For years, the company had been “a technology leader, an innovator,” Clayton Jones, then the chief executive, told Fortune magazine. “Unfortunately, along the way they forgot to hone thei…

not likely the NG didn't add new systems. not saying other cost-cutting won't be exposed but nothing as egregious as MCAS.

the MAX added new engines, which required forward placement on the wings, which changed COG, which necessitated MCAS.

Re: Delays in Boeing Max Return Began with Near-Crash in Simulator

#73
post #39
post #12

The can of worms has been officially opened, and this may turn out to be a case study in how bad software and outsourcing your centers of excellence can bankrupt a company. If TFA is to believed, Boeing has embarked on a project to take what is currently a master-slave failover design and jury-rig it into a master-master real-time system. This is based on bad performance in the simulator—not because of MCAS—but while…

A split brain in a plane is a bit of a nightmare. I'm not sure how they can work around it with just two computers.

my CS201 class 19 years ago taught me this. education just isn't as good these days..

Re: Delays in Boeing Max Return Began with Near-Crash in Simulator

#74
post #64

Earlier quoted context omitted.

Which computer calculates that there's a disagreement, and how can we ensure it's not indicating a false negative?

Either. The alarm must be an OR.

Then, IMO, it should be two independent indicator lights, not 1.

Re: Delays in Boeing Max Return Began with Near-Crash in Simulator

#75

Earlier quoted context omitted.

>>Software does not need to be this complicated. >>Design a damned airframe that's airworthy without needing stabilization hacks. In effect you are stating that you understand better than the hundreds of engineers involved with this project why these design trade-offs were made. Careful with that line of thinking. You're nearly guaranteed to be wrong. There are a host of reasons for the design in place: Efficiency, e…

> In effect you are stating that you understand better than the hundreds of engineers involved with this project why these design trade-offs were made. We don't know that any engineers approved this design. It could have been completely compartmentalized and approved by management only. We'll never know what the engineers said until there's a complete investigation and the engineers are subpoenaed. Here's what we kno…

I think the key thing is how the MCAS added new failure modes that the pilots where not briefed about.

There should be way more strict user interface requirements. Including how humans are supposed to react to failures and whether that makes sense from human psychology point of view

If the MCAS had informed pilots of a potential sensor failure, then there would have been a very good chance that the pilots would have been able to land the planes safely.

Re: Delays in Boeing Max Return Began with Near-Crash in Simulator

#76
post #12

The can of worms has been officially opened, and this may turn out to be a case study in how bad software and outsourcing your centers of excellence can bankrupt a company. If TFA is to believed, Boeing has embarked on a project to take what is currently a master-slave failover design and jury-rig it into a master-master real-time system. This is based on bad performance in the simulator—not because of MCAS—but while…

"Dual-dual" is a thing in this space. There are safety-intent microprocessors which have a couple of cores running a couple of cycles out of sync with a delay and comparison on registers. If they disagree after that delay, the processor concludes it's insane and you can take action based on that hardware-level signal.

It's not my favorite solution for every application, but it's a good tool for a handful of situations. And it's a good way to avoid having to think about picking who to trust with only two sockets. There are other approaches, of course. For example, if your system can afford more than a couple clock cycles of latency (e.g., if you don't believe you can crash a plane with a couple milliseconds of control error) you can do the same thing with well-designed software and a bit of extra hardware. It gives you more freedom since there's more hardware to buy, at the expense of engineering and test effort to prove that your solution does what you want.

Doing this over large physical distances also adds some challenges. There are debates around dedicated signal wires direct between control centers vs data networks. Every situation is a little different, so there aren't really easy answers that you can swoop in and prescribe as best-practices. In general I find that people are more-skeptical of packet-switched solutions (e.g., Ethernet) than I would be. But most folks are also better at reasoning about the failure modes there than they are at thinking about the lower-level issues that Ethernet solves for you. And of course there are tons of different signaling systems - not just Ethernet - to consider.

Consider just a few different possible applications and the constraints that they impose. A car has less severe failure modes (many crashes are nonfatal) but less freedom in time. Your trajectory is simply more cluttered. A passenger plane has dramatically more energy, so failures are typically more severe, but you have a lot more time to deal with them because your trajectory is empty (much of the time, anyway). And if you're sane, you've designed it to be passively aerodynamically stable because twitchy maneuverability isn't critical when you're not a fighter jet. A rocket is a different animal altogether. Those are often rigged with self-destruct explosives, and you don't really get much time to change your mind if you erroneously choose to trigger them. Plus they're typically less stable (performance is more dear, gravity isn't helping you, and purely aerodynamic solutions don't take you outside the atmosphere) and are thus more dependent on their control systems.

Re: Delays in Boeing Max Return Began with Near-Crash in Simulator

#77

Earlier quoted context omitted.

That is incredibly misleading. The Dow is not representative of the entire stock market anymore. The S&P 500, which is only the 500 largest public companies by market cap, has a combined market capitalization of ~$25+ trillion. Boeing has a market cap of ~$200b, so that represent 0.8% of the total. If you include the top 3,000 public companies (i.e., the Russell 3000), the combined market capitalization is over $32 t…

>The idea that regulators at the FAA are going to let them fly a dangerous plane "because of the stock market" is absurd. They already let fly a dangerous plane. Given they have already done so, an explanation like 'stock market pressure' is no longer absurd.

the Icon A5 is also a certified death trap. but i guess it allows the consumer to chose risk with their wallet...

Re: Delays in Boeing Max Return Began with Near-Crash in Simulator

#78
post #21
post #14

Earlier quoted context omitted.

>at least one of the pilots who flew the scenario in a simulator found it difficult to respond And I'm guessing their not using pilots of average skill here...

According to [0] the FAA was looking for numerous candidates to get a good range of experience, so I would think that you might’ve had at least a few average pilots. [0]: https://www.reuters.com/article/us-ethiopia-airplane-faa-boe...

FAA, right. Trump's pick for FAA head was confirmed only because the majority in the senate (you guess which party) decided to look the other way about allegations that while at Delta, he mistreated a whistleblower who raised safety concerns to him. Oh, and he's a lawyer. I wouldn't trust the current administration's FAA on this. Yes, politics does come into it whether we like it or not.

Re: Delays in Boeing Max Return Began with Near-Crash in Simulator

#79
post #70
post #44

Earlier quoted context omitted.

Big "disagree" alarm for the pilots and let them decide to keep either computer or go direct. Airbus has the concept of flight control laws, surfaced and changeable by the wet backups. http://www.airbusdriver.net/airbus_fltlaws.htm

And Boeing will make that disagree alarm an optional extra?

Am optical extra that isn't actually properly functioning as intended in numerous delivered products? Almost as if it wasn't sanity tested in one production unit, let alone some random sample of units?

Re: Delays in Boeing Max Return Began with Near-Crash in Simulator

#80
post #12

The can of worms has been officially opened, and this may turn out to be a case study in how bad software and outsourcing your centers of excellence can bankrupt a company. If TFA is to believed, Boeing has embarked on a project to take what is currently a master-slave failover design and jury-rig it into a master-master real-time system. This is based on bad performance in the simulator—not because of MCAS—but while…

That, or this article missed the boat somehow. I find it hard to believe that a total redesign is happening and that they expect to be done by the end of the year. Either this article is wrong, or something is terribly wrong at Boeing.

I wonder if someone talked to this reporter about a long-term redesign they're doing, and the reporter conflated that with the short term patches they're doing to get the plane flying again. It just doesn't make sense otherwise.

And, 100 scenarios instead of 10? I sure as heck there's more than that on an architecture redesign!

Post reply on HN