Originally Posted by
Ian W
If the design documentation is good then the impact of changing items is known through forward and backward traceability. I have worked in systems where a line of code could be traced back the a specific functional requirement (or set of functional requirements). There can also be cascade impacts so many regression tests are required - although this should not happen with good loosely coupled designs. This level of design governance is hard but is essential if you are maintaining safety related systems.
I'm certain that's what happened with MCAS. The initial form (0.6 units, AoA + G sensor) went through safety (and required 2 inputs). The later changes didn't get the same scrutiny because the people making the change didn't realize the safety impact and no one that would understand the impact knew of the changes. A few new requirements added for the low speed case, code written. Nothing in the process that says it needs to go back through safety.
And because of that there was never any testing (lab/sim/flight) of the new functionality with that failed AoA input.
Even then, would anyone have thought about the AoA sensor failing to such an extreme AoA? Or would it be assumed that it wouldn't fail with such a misleading reading? FHA/FMECA evaluations all make assumptions about how components/systems fail. Get those wrong and you miss things.
A seeming minor requirement change that probably needs to be reevaluated but wasn't. And when I suggest it should be there's hemming and hawing about costs/schedule. Then it's up to me to prove that it does need to be looked at closer, not the people better equipped to make the determination. I'm an EE and not a pilot. But I have to understand/prove the safety impact of the different control surfaces, FMS functions, engine controls, radios, etc in different phases of flight?
It'd be great if every requirement change at all levels were analyzed for safety impacts. But that's not how it works in the real world.