Originally Posted by
FCeng84
VicMel - I really appreciate your thoughtful response. I sense that overall you and I are on the same page. Please allow me to provide a few inputs on your points:
C) MCAS is implemented within the FCC within the same software that controls other automatic stabilizer control functions such as offload when A/P is engaged and STS. This code already required to be designed to high standards.
Conclusion a) We may need to rely less on critical crew action, but there must be some base level that can be counted upon. I suggest at least:
- RTO for engine out below V1
- Pull for takeoff somewhere near Vr
- Gear and flap management and coordination with associated speeds throughout flight
- Comply with ATC guidance
- Ability to navigate to destination
- Ability to capture and follow glideslope and localizer to runway and command landing flare
- Recognize unstable approach and execute go-around
- Sorry for the length of this list. My point is that there are many pilot actions we count on to maintain safe operation
Conclusion b) I fully agree and suggest adding that if the inputs are garbage the system should be robust enough to maintain safety.
Thanks for your detailed response with all of your valid comments. As you say, I believe we, and many other posters are “on the same page”.
I fully agree with your comment regarding crew action “there must be some base level that can be counted upon”. The upside of human unpredictability is the ‘magic’ of intuition, i.e. being able to think ‘outside the box’ (literally in aviation terms). This is why a pilot will always be needed on an aircraft with passengers. The point I was trying to get across is I believe aviation authorities must stipulate that if a supplier is using crew actions as part of his probabilistic safety case, then a Human Factors assessment has to be carried out. This would produce a figure for the probability of achieving whatever task the crew are supposed to do. This figure then has to go into the fault tree(s) to show the aircraft meets its acceptable safety criteria.
As software is my specialty, I would like to expand more on the software criticality issue, please pardon me if I am stating the obvious. This issue is in regard to MCAS in particular, but also other systems that are considered to be not safety critical, such as Air Data Systems. You are right to say about MCAS software, “This code already required to be designed to high standards”. However, there is a huge difference between the DO-178C software certification standard Level A (catastrophic failure, potentially loss of aircraft) and Level C (major failure, potentially minor injuries to passengers). I would expect all Level C software to be produced to a high standard, but Level A obviously has to be at a very significantly higher standard. There is a huge cost saving that can be made if the software can be justified as not needing to be at Level A; some estimates suggest Level A is at least 2 to 3 times more expensive to produce than Level C. The main 3 factors leading to this increased cost are:-
a) independence of verification; which needs additional team(s) of engineers
b) quality of process; e.g. using Ada rather than C, code analysis tools and (most importantly) specialist software engineers with lots of wide ranging experience on real time, safety critical systems.
c) complexity of software; there is a saying ‘system safety lies within the software’, meaning software has to be added to basic functionality to ensure the system meets its prescribed safety requirements. For example the hardware engineer may determine that triplex sensors are needed to ensure hardware integrity, but then the system engineer has to determine how the software is to handle the 3 inputs to produce a ‘safe to use’ output. This might be a ‘vote’ or an average or using historical readings to determine best integrity. And if the triplex sensors are vulnerable to ‘common mode failure’, the team might decide a different technology sensor has to be used, or to use other system’s data in order to provide a temporary reversion mode.
Hence my concern:- Because MCAS software was not produced to Level A, it is not assured to be at a high enough standard to allow it to directly control the stabilizer. The risk is that there could be a fault in the software that could cause an erroneous trim condition. The proposed patch may not have any effect on such a software fault.