Pontifications: “The need for radical fuel improvements will only increase over time.”

Apr 09, 2023

@ claes OK, so this is squarely within my wheelhouse. I keep harping on the importance of competency in managing complexity. That's shorthand for a lot of things, and we could do a whole advanced degree's worth of discussion and writing about this topic. It's huge.

The natural thing for humans to do is to overuse our latest hot new technologies and not use them wisely. There is solid archaeological evidence for this behavior going back at least 9500 years. That we would be doing this with computer chips and software should not be surprising.

Why does it take so long to certify avionics systems (hardware and software combinations – it's NOT just software!!!!! – hear me pounding the table on that point)?

On the defense side of things we have a process called Failure Mode Analysis. The commercial folks like to call the exact same process Failure Mode and Effects Analysis. What you do is go through a process of documenting exactly how something works, and analyze each step and thread of steps to identify everything that can go wrong. This starts with hardware failures which end up either or both just stop working, or feeding bad data into the software.

Circa 1980 your typical least cost chips (we’re talking fab capacity, not chip type) would have up to just short of one million IC components, a little more than 25% of which would be transistors. They were arranged in similar arrays, so even though those are big numbers, it was possible for the average EE doing a design to get a pretty good handle on exactly how a given chip worked. By 1995 this ability had been lost. The number of really good top notch EEs that it took to fully understand a least cost chip was probably three or four, but you could still assemble a team in an aerospace company that could do this. By 2000 assembling such at team had become impossible for three reasons. One was the skyrocketing number of IC components (often referred to as Moore's Law). Another was some of the amazing technologies that were built into some chips such as self healing and the still amazing Field Programmable Gate Array (FPGA). And the third was the rapid drain of top notch talent out of aerospace and into tech companies. And this is just the hardware.

The software was seeing the same thing – explosive complexity, crossing the threshold of comprehensibility by a team that can be assembled, and the talent drain out of aerospace into tech.

So the question that was squarely on the table in the mid-1990s as Condit was leading Boeing into first one really good M&A activity with North American Rockwell, and then a disastrous one with MD, was how do we manage this exploding complexity and declining talent problem in aerospace avionics? How do we even do our designs such that a competent FMA (aka FMEA) is even possible?

There is a way to do this, but it requires mature and insightful engineering leadership that understands the challenge and what needs to be done. And, that engineering leadership needs to be fully supported by the corporate and investment community. In Boeing's case, neither of these happened, so new products didn't work, and people got killed. It's just that simple.

This next part will be a VAST oversimplification. What needs to be done is to use simpler IC fabs, in discrete functional modules, with tightly defined interactions with each other, so that people can isolate and understand what they are supposed to do and identify the risks that need special attention.

What has consistently happened in Boeing and in the mission avionics on the Lockheed fighter programs, is that the ability of the chip fabs to host unimaginably large numbers of functions, and software tools that can take advantage of those large numbers (we’re well into 9 orders of magnitude and more here) have been used without discretion. Thus, the engineering teams are nearly totally blind as to what is going on inside what is supposedly their own designs. And that is without adding generative AI tools into the mix.

The right answer is to work with the tech companies, probably on government funded programs, and develop a radically different set of chips and software development tools for control system applications.

As an aside, the Wikipedia definition of a control system went badly off course a few years back, so you have to be careful with it. It has a lot of good information in it, but the high level definition is just plain wrong. It talks about a relatively narrow case in which feedback loops are a defining part, and that is really only a small but important percentage of the whole topic.