BOEING 737 MAX

May 11, 2019


The five points given below were taken from an excellent article written by Jacob Beningo and appeared in “Electronics & Test Aerospace”, May 2, 2019.  I have added my own comment relative to those five (5) points.  It appears, from what we know now, there were no mechanical failures causing both aircraft to crash.  The real failures were lack of training and possibly embedded electronic systems effecting on-board systems. 

Recently the news headlines have been dominated by two crashes involving Boeing’s new 737 MAX aircraft. Both of these tragedies occurred under similar circumstances and within six months of each other. The fallout from these disasters may only be starting as aircraft around the world have been grounded, production of the 737 MAX has been decreased and March sales of the aircraft dropped to zero. The damage to Boeing’s reputation as a safety leader has now also come into question as investigations have been opened into how the system at the center of the investigations, MCAS, was developed and certified.

The investigations into the sequence of events that led to the loss of these aircraft with resulting causes will take time to fully discover—maybe even years but certainly months. However, with the information that has currently been released, embedded systems companies and developers can look at the fiasco Boeing is currently going through and learn and be reminded of several general lessons that they can apply to their own industries and products.

Lesson #1 – Don’t compromise your product to save or make money short-term

There is normal pressure on businesses and developers today to increase revenue, reduce costs and ship products as fast as possible. The result is not always quality. It isn’t security. It isn’t user friendly. The objective is maximum short-term growth at any cost as long as the short-term growth is maximized.  The company needed to remain in good standing with Wall Street and their investors.  That seems to be the bottom line.  Boeing appeared to be under significant pressure from customers and shareholders to deliver an aircraft that could compete with the Airbus A319neo.  They may have started to cave to this normative pressure.

Lesson #2 – Identify and mitigate single points of failure

Boeing and the FAA are looking at embedded systems in trying to discover the root cause of both failures and how corrections may be made to eliminate future tragedies.  In any embedded system that is being developed, it’s important to understand the potential failure modes and what effect those failures will have on the system and how they can be mitigated. There are many ways that teams go about doing this, including performing a Design Failure & Effects Analysis (DFMEA) which analyzes design functions, failure modes and their effect on the customer or user. Once such an analysis is done, we can then determine how we can mitigate the effect of a failure.  This is common practice for systems and subsystems of any complexity.

Lesson #3 – Don’t assume your user can handle it

An interesting lesson many engineers can take from the fiasco is that we can’t assume or rely on our users to properly operate our devices, especially if those devices are meant to operate autonomously. Complex systems require more time to analyze and troubleshoot. It seems that Boeing assumed that if an issue arose, the user had enough training and experience, and knew the existing procedures well enough to compensate. Right or wrong, as designers, we may need to use “lowered expectations” and do everything we can to protect the user from himself.

Lesson #4 – Highly tested and certified systems have defects

Edsger Dijkstra wrote that “Program testing can be used to show the presence of bugs, but never to show their absence.” We can’t show that a system doesn’t have bugs which means we have to assume that even our highly-tested and certified systems have defects. This should change the way every developer thinks about how they write software. Instead of trying to expose defects on a case-by-case basis, we should be developing defect strategies that can detect the system is not behaving properly or that something does not seem normal with its inputs. By doing this, we can test as many defects out of our system as possible. But when a new one arises in the field, a generic defect mechanism will hopefully be able to detect that something is amiss and take a corrective action.  

Lesson #5 – Sensors and systems fail

The fact that sensors and systems fail should seem like an obvious statement, but quite a few developers write software as if their microcontroller will never lock-up, encounter a single event upset or have corrupted memory. Sensors will freeze, processors will lock-up, garbage-in will produce garbage-out. Developers need to assume that things will go wrong and write code to handle those cases, rather than if we will always have a system that works as well in the field as it does on out lab benches. If you design your system considering the fact that it will fail, you’ll end up with a robust system that has to do a lot of hard work before it finally finds a way to fail (if it ever does).

I had an opportunity to hear the chief engineering program manager discuss the “Dreamliner” and the complexities of that system.  They were LEGION. Extremely complex.  Very time-consuming to work out all of the “bugs” relative to all of the computer programming necessary for successful AND safe air travel.  Trying to make a system “simple” by making it complex is a daunting task and one that needs to be accomplished, but it is always a “push” to get this done in a timely fashion and satisfy management and Wall Street.

Advertisements

What do you think?

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: