Ethiopian airliner down in Africa

[KRH270/12]

Hi,

can anyone pls explain to me, why they had an IAS disagree with just an AOA sensor fault.

I thought the pitot/static system is independent...or is there some „mixing of data“ going on in the ADIRUs?

thx

[edmundronald]

Why not just disable MCAS, leave the pilots to trim as usual, and retrain them a bit to deal with the feel of the plane at a high AoA?
Zero software to write, and no new bugs introduced.
Because as they say in the industry, new features always means new bugs.


Edmund

[bsieker]

Originally Posted by ecto1

What I meant is that there is a 《all or nothing》spirit that doesn't quite cut it. Either is a 8 year development with millions of man hours on it ,or a terrific patch that looks like done overnight. No middle ground.

I'm not sure what gave you that idea. There are various levels of criticality for different pieces of software.

However, there are bigger issues at stake. MCAS has the potential, without quick and correct intervention by the crew, to cause a catastrophic outcome ("catastrophic" is not just a fancy term, it is quite well defined in certification specifications.) Therefore software for systems with such severe possible consequences, need to be developed to particularly stringent standards of requirements specification, analysis, coding practices, planning, documentation, verification, etc. That is what some people here mean when they refer to "DAL A" or "Level A": That is the most stringent category for safety-critical software in airborne systems, as defined in DO-178C (or ED-12C in Europe, which is excatly the same standard):

Level A: Software whose anomalous behavior, as shown by the system safety assessment process, would cause or contribute to a failure of system function resulting in a catastrophic failure condition for the aircraft.

As we now know, MCAS is just such a system. So, as others have pointed out repeatedly, at least in hindsight, anything less than Level A is not appropriate.

Objectives that need to be demonstrated include things like

• High-level requirements are accurate and consistent.
• Low-level requirements are verifiable.
• Software architecture is verifiable.
• Source Code is verifiable.
• Source Code is traceable to low-level requirements.
• Source Code is accurate and consistent.
• High-level requirements are accurate and consistent.
• Low-level requirements are traceable to high-level requirements.

And many more. That is "the cheapest fix possible". It's not cheap, but it's doable in significantly less than 8 years for a company which has the procedures in place, which Boeing does.


Bernd

[FlightDetent]

1) CAS is derived from pitots and static using an adjustment for AoA.

2) To disable MCAS: physically workable suggestion but knowingly failing a certification requirement is not an option.

[jimtx]

Originally Posted by edmundronald

Why not just disable MCAS, leave the pilots to trim as usual, and retrain them a bit to deal with the feel of the plane at a high AoA?
Zero software to write, and no new bugs introduced.
Because as they say in the industry, new features always means new bugs.


Edmund

Agreed, waive the Part 25 criteria and show the handling change in the sim. It would be nice to know what that envelope is. I'm surprised 737 pilots, pre the final incident, were happy flying an aircraft where if they were unlucky enough to apply the Emergency AD, they then would be at risk of encountering the envelope without MCAS and Boeing/FAA do not even warn about it in the AD.

[HighWind]

Originally Posted by bsieker

That is possibly the worst suggestion so far.

Assembly code is almost impossible to analyse for correctness in any meaningful way. It is far better (and provably so) to write in a well-specified (i. e. not C) language, prove the source code correct (for which scalable and practical techniques exist today), or define and prove correct a finite state machine and have code generated from it.

I would assume that it is either SCADE, or Simulink.
Both tools generate C code, but with SCADE you don't have to inspect the C once the tool chain have been qualified. (Considered the safest alternative of the two)
SCADE is used by Airbus (Both French products), and Boeing might use Simulink.
But this is irrelevant for this discussion since the fault is in the specification, not the software.

[EDLB]

Originally Posted by .Scott

I think that if Boeing tackles this problem correctly, they could have the planes flying safely in about four months.

My guesimate is more a year if they have already started and they are lucky. Can easily be more. A Level A software piece need to run on a hardware worth that level. Don’t think that they have it in the 737 so they will need an additional box.
So I don’t think that the MAXes in storage will hit the friendly skies anytime soon.

Or does anyone believe that the FAA will stick their neck out and allow the next “quick fix”.

[PiggyBack]

There are a lot of confident and ridiculously detailed statements about the softare use din MCAS even the language used to code it. None of thsi is relevant. It is clear that the root is a system design error compounded by a failure of hazard and failure analysis and the regulatory/certification process.

I can see quick fixes which address the deficiencies in the way MCAS responds to erroneous inputs which from a functional point of view make the behaviour safe. I can't see a quick fix which address the wider hazard/failure analysis and regulatory concerns.

I write safety related software but discussing which language or tools to use to develop SW when the fundamental concept is flawed make no sense. The best solution to a safety hazard is intrinsic - remove the hazard, in this case that means aerodynamic changes and I assume that won't happen but it should have been thought about at the design stage. If intrinisc safety is not possible then a functional safety like MCAS is possible but the consequences of failures must be considered and controlled and any additional hazards by introducing the functional safety sub-system must be considered. I assume this was done, at least in the formal sense but it seems to have been done inexplicably poorly. This was not a case of a complicated combination of unlikely events but an entirely forseeable concsequence of a single failure. IF MCAS is retained it has to be designed and developed appropriately given the impact of it failing and that is not going to happen very quickly.

Ther eis no evidence I am aware of that the software did anything other than what it was intended and specified to do. Even the software specification was not really the eproblem. The problem was the overall system design and the safety analysis behind it. It is actually quite shocking and shoud result in a very deep analysis of both the development and regulatory processes.

[Golf-Sierra]

Originally Posted by bsieker

In hindsight that is probably a shortcoming of the risk and hazard assessment of the ADIRUs of the A330, yes. But the rationale for regarding all air data invalid at indicated air speed below 60 knots is that it was simply not known how the aircraft would behave in that regime.

I think you are either missing the point or perhaps I do not fully understand what you mean. In real life reality an A330 could not be at or below 60 knots kias other than either with the wheels on the ground or during some quite spectacular upset - and even then it would last for maybe a few seconds. I think the only sensible rationale was to reject an indicated airspeed of 60kts for an airliner in cruise many tens of thousands of feet above the ground.


Golf - Sierra

[Water pilot]

The problem looks intractable to me but that is why "A team" engineers exist. I didn't think that they were going to get the tunneling machine that got stuck under Seattle working again, but they did. Whether or not the public ever trusts the plane and whether SouthWest and Boeing survive without a government bailout may be another question.

The overall problem is far more insidious than relying on a single sensor, and I think that is what they are running into. Moving the stabilizer seemed like an elegant solution but there are circumstances where moving it can get it stuck due to aerodynamic forces. This requires heroic efforts from the pilots to unstick it (whether or not that was a factor in either accident is being debated). Low cost airlines can't afford to hire hero pilots, and an alternative plane exists that does not require them (allegedly.)

What I don't understand is how the system met the requirement for a continuous pressure gradient on the stick (I'm probably phrasing that badly.) So you have constant pressure when pulling the jetliner up rapidly to avoid that drone in your path, which is great because you don't get a sudden light stick sensation that lets you pull up too far into stall, but now push down to get back to level flight. This is probably yet another stupid question, but with the stab trimmed down, aren't the stick forces pushing down going to be much lighter than they normally are? I haven't seen anything -- although I could have missed it -- that MCAS trims back up when the AOA decreases, that is supposed to be noticed and handled by the pilot. This may be a reasonable assumption, but remember this is the pilot who couldn't be trusted not to pull the plane into a stall!

[infrequentflyer789]

Originally Posted by KRH270/12

[left]Hi,

can anyone pls explain to me, why they had an IAS disagree with just an AOA sensor fault.

On that point - can you show where it is confirmed that they did have IAS disagree, because as far as I can see it isn't mentioned at all in the report.

IAS is divergent (expected as ADIRU does use AOA to correct it, and AOA is massively diverged), but IAS DISAGREE isn't confirmed. I am pretty certain it should have happened, particularly given that it did with LionAir with AOA far less divergent, however there are several oddities in the narrative and traces that I can't get my head round at all.

[Avionista]

EDLB:

Or does anyone believe that the FAA will stick their neck out and allow the next “quick fix”.

The FAA stuck their neck out already when they nodded through the original MCAS bodge and look at the mess that has got them into. I don't think they will approve any B737 MAX fix without first getting the agreement of other important regulating authorities such as EASA, Canadian CAA, Chinese CAA, etc. If a further catastrophe were to occur the FAA will want to be able to say that the 'fix' was also approved by other regulators. Also, for the commercial success of the MAX it has to be approved for operations in Canadian, European and Chinese airspace.

[bsieker]

Originally Posted by Golf-Sierra

In real life reality an A330 could not be at or below 60 knots kias other than either with the wheels on the ground or during some quite spectacular upset - and even then it would last for maybe a few seconds.

Golf - Sierra

Well, that assumption turned out to be false for the A330. It was in this spectacular upset, with indicated airspeed < 60 kts, for almost 3 minutes with only short interruptions. During almost the entire time (again, with only brief interruptions), computed airspeed values alternate between 400, 45, 0, 45, 400, etc. where both 0 and 400 are recording artifacts, and the 45 possibly more or less accurate. During periods where the values were valid again, computed airspeed rose to 150, 120 and 100 knots, respectively, before returning to the invalid values.

Bernd

[ATC Watcher]

Originally Posted by EDLB

My guesimate is more a year if they have already started and they are lucky. Can easily be more. A Level A software piece need to run on a hardware worth that level. Don’t think that they have it in the 737 so they will need an additional box.
So I don’t think that the MAXes in storage will hit the friendly skies anytime soon.
Or does anyone believe that the FAA will stick their neck out and allow the next “quick fix”.

As mentioned already , maybe the FAA, but not the Canadians and EASA to name only two, Then the Max will be restricted to domestic US , which is maybe what will happen in the end., as in previous cases, and then possibly a new " Super 737" or even 797 will roll out with some new features , @ la MD-11.
I know of 2 European airlines now that have taken out their stored Max from their Summer schedule altogether, and one is using this as a marketing thing to get their pax back during the Summer.
I am not sure about Air Canada , but I am going to OSH at the end of July and one domestic leg was on a Max, and I was two weeks ago rescheduled on a different flight at a very different time on an A321. So it would seem that also Canada is not expecting to get them flying soon. .

[Water pilot]

Originally Posted by spornrad

Thanks for your explanations. Since it would be another lottery win the thumb switch going south at that exact instance (besides why less, not no stab movement): Is there any remote possibility that software reduces the thumb switch authority on the left, not right, in those conditions (AOA disagree/MCAS activation) ?

Not particularly remote since it was the left side that the shaker was active on. We don't really know how the thumb switches operate, at first I thought that they were just switches to a solenoid but it seems more likely that they are just inputs to the fancy two computer/four processor 'black box' that is part of the flight control system. At that point, anything is possible since it is software.

[gums]

Salute!

Thanks, bernd

Guess many were not there for the megathon AF447 discussion about the stall warning relationship to the Aoa when speed was under 60 knots.
On that night, the plane proved it was very stable in a deeply stalled part of the envelope, and had only a slight change in heading versus a violent yaw/roll . So smooth that the crew didn't understand that they had actually stalled - no stall warning audio due to the 60 knot criteria and the "you can't stall this plane" mentality of many at the time.

Gums sends...

[Lost in Saigon]

Originally Posted by edmundronald

Why not just disable MCAS, leave the pilots to trim as usual, and retrain them a bit to deal with the feel of the plane at a high AoA?
Zero software to write, and no new bugs introduced.
Because as they say in the industry, new features always means new bugs.


Edmund

It is pretty basic. An aircraft has to fly like an aircraft. If you pull the nose up, and then release back pressure, the nose must return to somewhere near the original attitude and speed. If you disable MCAS, the B737 MAX will not meet the FAA stability requirements of Sec. 25.173 (Static longitudinal stability)

I suspect that without MCAS there would need to be a major aerodynamic redesign to meet the stability requirements.

[RatherBeFlying]

Assembler vs C, C++ etc

I spent a large part of my career deep in mainframe Assembler applications and operating systems. A lot of it was really good and some was absolutely dreadful.

The principal determinant of success was elegance (or lack thereof) in design.

Same applies to C, C++ and all the wonderful new development environments that these days are proliferating faster than I can keep count. You may as well be in the fashion industry as bleeding edge IT.

Likely the A & B folk are sticking to well understood and proven development environments that are behind the times.

[threemiles]

Originally Posted by ATC Watcher

As mentioned already , maybe the FAA, but not the Canadians and EASA to name only two, Then the Max will be restricted to domestic US , which is maybe what will happen in the end., as in previous cases, and then possibly a new " Super 737" or even 797 will roll out with some new features , @ la MD-11.
I know of 2 European airlines now that have taken out their stored Max from their Summer schedule altogether, and one is using this as a marketing thing to get their pax back during the Summer.
I am not sure about Air Canada , but I am going to OSH at the end of July and one domestic leg was on a Max, and I was two weeks ago rescheduled on a different flight at a very different time on an A321. So it would seem that also Canada is not expecting to get them flying soon. .

Re-scheduling has nothing to do with "expectations". You have to keep managing the operations about 180 days in advance, i.e. availability of the right aircraft and crew at the right time, feeding the res systems with the right capacity and classes, and so on. The deadlines are different for each airline but 90 days before take-off everything needs to be fixed.
Doing otherwise is gross negligence and you'd have a good chance to never get to OSH.
That means, if the Max fleet is back before, it is just up to daily operations to fuse it in again.

[yanrair]

Originally Posted by bsieker

Well, that assumption turned out to be false for the A330. It was in this spectacular upset, with indicated airspeed < 60 kts, for almost 3 minutes with only short interruptions. During almost the entire time (again, with only brief interruptions), computed airspeed values alternate between 400, 45, 0, 45, 400, etc. where both 0 and 400 are recording artifacts, and the 45 possibly more or less accurate. During periods where the values were valid again, computed airspeed rose to 150, 120 and 100 knots, respectively, before returning to the invalid values.

Bernd

What was the most accurate speed readout on the plane indicating, during AF447 and the recent two MAX incidents - that being the GPS?? In AF447 it was reading something like 450 kts at the time of losing IAS. It is not going to change unless you do something like change pitch or power. Which is what happened to AF447 of course. You can fly on GPS speed for a long time until you have sorted out the problem. You can fly an immaculate circuit to land using just GPS. Yet in all the posts so far I have not seen much reference to its use in sorting out conflicting IAS/Stick shaker style events. Climbing out at 15deg pitch, 200 kts IAS Full power. GPS will be reading something similar, depending on wind and altitude. All hell breaks lose ( I am ignoring MCAS here which is a separate matter). Indicated speed all over the place. IAS disagree messages. Stick Shaker going off (one side failure) - what to believe?? Your GPS PITCH AND POWER. They are real, they are going to work and are unaffected by the ADIRU which relies among other things such as AOA and Indicated Airspeed.