Originally Posted by
bsieker
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.
It did not need loss of an aircraft to decide MCAS should be Level A, any software that has direct control of a piece of equipment, which if erroneously controlled could lead to a fatality, IMO must be Level A. So, MCAS should have been Level A from its original conception, if nothing else, in order to reduce the risk that the software will get “stuck in a loop” and just drive the stabiliser straight to its physical limit as fast as it will go! And I’m not too keen on the idea of putting non-Level A software in the same box as Level A software (assuming that the rest of the FCC software is Level A). Proving isolation and non-interference is very difficult.
Originally Posted by
bsieker
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
Boeing must realise that if there is another software “event” involving a 737 MAX, even if it has nothing to do the AoA, they will lose the public’s confidence completely. They really need to do an over-the-top job here, MCAS (and possibly other systems) need to be upgraded to A+. This should include (at least):-
a) fully independent (i.e. not another department of Boeing) verification of the items in the “objectives” list.
b) verification of robustness of code, preferably using tools to check for such things as poorly defined end condition of loops, depth of subroutine calling to prevent stack corruption, full timing analysis to prove there is no “timing overloaded” path etc., etc.
c) asking “what ifs” involving pilots, hardware team and experienced assessors, e.g. what information would pilots need to know to deal with a fault, what hardware idiosyncrasies need to be considered, what else could go wrong.
d) ensuring that every input is either from another Level A system, or validated by the new MCAS software
e) storing important status (e.g. flaps up) as a code and its complement, not as a single bit.
f) making MCAS an integral part of FCC i.e runs in both channels, if the outputs disagree the controller (could be the pilot, which would be a bit radical!) decides what to do
g) upgrading other systems to make them more robust e.g. ADIRU.
Redoing MCAS as Level A ready for submitting to the certification process should be relatively straight forward, I'd estimate 1 to 2 years; how long to ensure that supporting systems are brought up to an appropriate level (ADIRU to Level A?), 2 to 4 years perhaps. Achieving global certification, no idea.