Just got an email from a colleague of mine who is a software configuration specialist, sorry for the long post.
"Excerpt from Flight Safety Information Daily and book by Captain Shem Malmquist – interesting reading. In these overlapping critical systems is DAL A enough? Will ARP compliance become the pre-requisite for the implementation of new avionics suites on older, in-service aircraft?
A NEW APPROACH TO FLIGHT AUTOMATION
By Captain Shem Malmquist
Every new jet relies heavily on state of the art computerized systems. Automation has been the "name of the game" for several decades now as designers layer on new software and hardware. Pilots are now accustomed to operating aircraft that contain flight automation that manages nearly every aspect of flight. This has led to well known phrases such as "the children of the magenta line," referring to pilots who are focused on just following the automation, and more technical terms such as "automation dependency" and similar concepts. We all know what these terms mean but are they accurate?
Are pilots handicapped by a lack of basic stick and rudder skills or is something else afoot? Certainly, nobody would argue that stick and rudder skills do not become weaker as automation ramps up, but is that really the problem that is leading "automation dependent" pilots to loss of control events?
As a training pilot and accident investigator I do not see pilots that are unable to fly the airplane. What I do see is pilots that keep messing with the automation in an attempt to "fix it" until it does what they want (hopefully). It could be that they realize they grabbed the wrong knob, for example, the airspeed instead of the heading, in response to an ATC clearance, or, for whatever reason, the autopilot was not intercepting an altitude that was set. In the process they get distracted, lose focus and end up in unexpected scenarios. The key here is really ensuring strict discipline. The pilot-flying must focus on flying the airplane. The pilot-monitoring must ensure the pilot-flying is doing what they are supposed to do. The pilot-monitoring is, literally, the "control" (to use system theory parlance) for the pilot-flying. My suggestion would be to teach both pilots to focus only on the aircraft path during any dynamic situation. Any changes to configuration, turns, initial climb and descents, altitude capture, etc., should involve both pilots focusing on flight instruments. Further, if something is not going as expected, immediately degrade the automation to a point where both pilots know with certainty what it will be doing next. That may involve turning off all automation.
That brings us to the second problem no one is talking about. As we've learned from the two Boeing 737 Max accidents, pilots must have a fundamental idea of what computers are really doing, and what they are not doing. We tend to think of computers integrated into our aircraft as another hardware component. Either it does the job, or it has failed. Unlike an analog braking system or an altimeter, computers are fundamentally different
Attempts to personalize computers with such terms as "machine intelligence" misses the point. Computers are not living, but they do interact with the world around them as they were designed to do. They are hooked up to sensors to "sense" the factors that the people who designed them deemed important and react the way the designers enabled and designed them to do. The computer might, therefore, be missing vital information critical to an alarming scenario simply because beyond the designer's imagination.
Assuming that the data is all being collected as designed, it flows into the computer which uses a "process model" to decide what actions to take. The programmer has attached the computer output to various systems the computer is, literally, controlling. Unlike a living organism, a computer is totally unable to deviate from its programming. It cannot come up with a new or novel solution, it just simply follows its instructions. "I know xyz" and based on values of xyz I perform abc and that is all. There is no nuance here. Depending on the challenge at hand this can be useful or it can create new problems.
One way problems can begin is when the data is accurate but the computer process model is flawed. This can be analogous to a person being trained to do the wrong thing. An example might be a person who is not following a checklist because they had an instructor insist that they followed that instructor's "technique" instead.
Problems can also begin when the data coming in is flawed. Here the computer does exactly what it was programmed to do, no more, no less. If the designer anticipated the exact data problem the computer should do something rational. For instance, it might stop all further actions and alert the pilot that it cannot do its assigned job. However, if the designer did not anticipate a problem then there is no way for the pilot, in real time, to be certain of what the computer might now do. Yes, any person with software knowledge could look at the code and the data and tell you what it might do in that scenario. That doesn't help when an new scenario is suddenly discovered mid-flight.
Now recall the data inputs on an aircraft system, say a flight control computer. It needs airspeed, angle of attack, flight control positions, flap positions, it might need CG, g-loading (Nz), mach numbers and more. It takes that information in, and then, based on what commands are given to it by the pilot (inputs), runs it through a process model and then out to the control surfaces, engines and other items it might managing. These can include elevators, ailerons, spoilers, rudders, flaps, slats, trim, etc. The output is dependent on the input coupled with the programming, which becomes the process model. OK, hold that thought for a moment.
What is your procedure if something happens on takeoff that is not in the books? No QRH, or at least, no immediate action items. Let's say a sensor failure, a loss of angle of attack, a loss of the g-force or even the inability of the computer to read a flight control position. You have some sort of fault indication (maybe) right after V1, what would you do? Most training programs would have you to continue the takeoff, positive rate, gear up, get to a safe altitude, clean it up, then troubleshoot (maybe), or perhaps just continue to the destination.
All nice, except for one little problem. Remember that computer process model? The computer's process model is now flawed due to bad data. The computer is unable to "know" the correct actions. Changing any aspect might result in an unexpected outcome as the computer mixes the new details of your changes with bad data. All that goes into the software for a new "decision" on what output to perform. This is, in a nutshell, what occurred on the Max accidents. Pilots retracted the flaps and BANG, MCAS was activated. A change was coupled with a bad input in a scenario not anticipated in the design. The rest is now aviation history.
MCAS is not the only "gremlin" out there like this. There are others lurking. For example, something as seemingly innocuous as the pilot giving the computer commands in a way that was not anticipated by the designer can yield unexpected outcomes. So what can a pilot do? One suggestion is to consider the way computers work. If the airplane is flying ok, maybe it is worth considering not changing anything. No change to the configuration, no change to anything that is within the pilot control. Just keep it flying, and when any changes are made, be prepared for an unexpected outcome.
In a traditional legacy airplane this was no problem. Changing the flaps or the landing gear would be unlikely to entirely change the way the airplane handled. Changing the flaps would not suddenly trigger secondary systems in unexpected ways. That is no longer true. There is simply no way to train pilots to understand all the possible ways that every system might react to every circumstance. Arguably (and based on what we have seen) even the designers might not have considered all these possibilities. So I would argue that our procedures are not keeping up with the changes to our aircraft architecture. Until they get caught up, pilots need to have a much better understanding of how computers work and how they interact with the world around them."
The ARP reference is to ARP-4754A which is a guiding process that validates all technical requirement definitions of the aircraft components through testing, design analysis, and/or demonstration. The requirement validation exercise then becomes the basis for stating the DO-178 (Software)/DO-254 (Hardware) DAL (Design Assurance Level) are valid and consistent with the System Safety Analysis that now has hard data to back it up (rather than purely statistical data). It makes the agencies happy also and certification gets done way more quickly.