The kinds of issues that Boeing is encountering with implementation of new technologies are, in a sense, universal. Most consumer technology companies have to deal with this kind of stuff when designing new products. What is different here is that, because of the nature of Boeing’s business, these issues can lead to life-and-death situations, especially when mistakes are made.
Software is playing a bigger role in the implementation of the logic for decision making in the working of products everywhere. In the case of the Boeing 737 MAX 8 (and most likely the other MAX variants), a particular aspect of the software implementation became a key element in establishing the “stability” of the product, i.e., the aircraft, during a certain mode of operation. The software implementation turned out to be flawed in its implementation. Rather than depend on human beings to control the aircraft during a particularly unstable period of flight of the aircraft, the design had the software take over the flying of the plane during that period of time. The logic of the overall system design was shown to be faulty in one of the planes that crashed (and the authorities will probably conclude that something similar led to the second crash). In their rush to get the product out, Boeing failed to account adequately for all the possible ways in which things could go wrong, especially when control is wrested away from the human beings flying the plane.
How did Boeing end up with this kind of a design? The basic design of the 737 is quite old (from the 1960s) and not the best suited for upgrading to the latest technologies, including newer engines that are more efficient. Boeing was trying to match the performance of their newest products to the latest version of the newer (from the 1980s) Airbus A320 line of aircraft without having to design a new aircraft from the ground up, a process that would have supposedly cost more money and time. The solution approach that Boeing ended up with turned out to be something that was not ideal – an aircraft that was known to be unstable under certain conditions. The solution that they came up with to handle the instability was to use software to control the system so that it could at least be “meta-stable”. (Some military aircraft are designed this way.) The idea was to implement this “feature” without modifying how pilots who were used to flying the 737s would fly this new plane. Basically, they wanted to introduce the product in a way that the unstable nature of the design was not obvious to the pilots, so that their experience of flying a new plane would match that of flying an existing design. Instead of talking about the differences in the design and familiarizing pilots with how they should handle these differences, they deliberately tried to make things appear to be simpler than they actually were by addressing the problem with software control. What the heck! Boeing trusted the software more than instincts of the pilots?!
I am not a software engineer, but the small number of people who have been following my blogs know by now that I like to rail against the scourge of bad software. I feel I have a right to do so based on my experiences with such software. But the problem these days seems to go beyond that of “bad software” – it also seems to lie in the way the software logic is integrated into the whole system. And at the same time, whole systems are becoming more and more dependent on this kind of software. Our two hybrid cars, the Honda Civic from 2008 and the Prius from 2015, are two completely different beasts when it comes to integrating the operations of the electric motor, the gasoline engine, and the battery, into one coherent system to supply torque to the wheels. This whole process is dependent on decisions made using logic implemented in software. The logic, and the practical results from the implementations, are completely different for the two cars. Who knows how they came up with the logic, and how many software bugs there are in the control systems! When I complained about the Honda when I had problems, they were quite reluctant to give me any technical information. The good thing is that nothing seems to have been compromised when it comes to safety.
I used to work in an industry where the pressures of succeeding quickly with the introduction of new products was a primary driver in the decision making process. (This is probably a truism for most industries.) Thank goodness we were manufacturing products that did not deal with life-and-death issues. Failure in our systems could not, for the most part, kill you. Safety of the product was ensured by following regulations in this regard. But when these kinds of market forces impact a multi-billion dollar aircraft industry, a situation where the lives of millions of regular folks who are flying is involved, you have the potential for very significant problems. If you try to cut corners hoping that there is nothing fatal that lies out of sight, you are asking for trouble. The regulators are supposed to be the final arbitrator for safety issues, but what can they really understand about complicated systems like the ones we are building today. Ultimately, the onus lies on the one building the product, and this is true for any kind of product.
Boeing will survive their current problems, but their reputation is tarnished, at least for the short term. They really came out of this looking small and insincere, trying to hide behind the FAA. They could have gained more trust from the public by being proactive, and even responding more forcefully after the first crash.
Truth of the matter is that situations like these have happened in the past for both of the big aircraft manufacturers that remain today – Airbus and Boeing. When Airbus first introduced fly-by-wire technologies, there was even a crash at an airshow.
It is true that fatal flaws in aircraft are not limited to those of the software kind. Planes have been crashing due to hardware failures since man began to fly. It is only that fatal flaws of the software kind are completely predictable. They should be easier to find and test for from the design and implementation perspective. The software should be able to respond to all the known hardware issues (which are unfortunately unavoidable) in some way, and the software should not be buggy. And you cannot have the software introducing new failure modes, especially when safety is involved. That should be unacceptable.
In general, flying commercial aircraft is probably much safer today than it has ever been. The problem (as I see it) seems to be that companies are willing to play with people’s lives in their approach for introducing new technology and making money, and this is preventing the system from being as safe as it really can be when new products are introduced. Some companies seem to be too willing to take a risk of losing human lives in the process of learning more about their new products. And then they are slow to take responsibility. There has to be some kind of social liability associated with this approach.
Splattered Brains 