How Advanced is System Design for Aerospace Applications?

Some vertical domains - like mobile and consumer applications - have a Christmas-driven heartbeat - if you miss it, your company may be at serious risk of not making it. They have adopted some seriously advanced commercial best practices for electronics design. Terms like "Shift Left," "First Time Right Silicon," and "Emulate Before you Fabricate" are debated heavily. Our customers in the Aerospace/Defense domain often refer to these commercial best practices, wondering how to apply them to design cycles that are often taking longer than planned and require several actual prototypes to deal with issues that seem avoidable. It feels like "Fly-Fix-Fly" and not "First Time Right."

When looking in more detail, in some areas of system design, the Aerospace/Defense vertical application domain is exceptionally advanced. For instance, software development and automation starting from very high levels of abstraction using Model-Based Design - using technologies like UML, SysML, and The Mathworks M and Simulink - seems to be much more common here than in Christmas-driven application domains. 

And that is true for quite some now. I remember that over a decade ago, at the Design Automation Conference 2008, Jack Little Jack, co-founder of The MathWorks, gave a related keynote. It was titled "Idea to Implementation: A Difference Perspective on System Design," and discussed the use of Model-Based Design to "solve the growing challenges of electronic systems and embedded software development."

Jack's passion was all about engineering math as the universal language used across various industries, professions, and applications. There are many more examples now, but at the time, Jack illustrated the problems with current development flows using the case of Flight 501 of Ariane 5, which impressively failed because the control of the nozzle control failed due to mapping the original floating-point data to 16bit integer and causing an arithmetic overflow.

Model-Based Design with automatic code generation is a solution to that problem. It has been for at least two decades, and The Mathworks defines it as follows.

"Model-Based Design [enables] a hierarchical design process in which the entire design is initially defined at a conceptual level, and detail is added as necessary to deliver the needed functionality. The model is used to define specifications, evaluate design and system performance, automatically generate code, perform hardware-in-the-loop testing, and create a software-based test harness for testing production hardware. This approach can substantially reduce development time by rapidly leading to complete and functional proof-of-concept designs and enabling rapid design iterations and parameter optimization through a unified design, simulation, and test environment."

The results presented in Jack Little's keynote at the time were quite impressive. He showed how models are used to automatically generate 1,000,000 lines of code by Honeywell for airplane flight control systems, as well as how Toyota and Visteon automatically generate code, which is more compact than hand-coded software in automotive applications. Equally important, because of the coding phase going away, Toyota Denso was able to significantly shorten time to market, expecting even further improvements because of the impact of Model-Based Design on verification. 

Beyond The Mathworks, I fondly remember my conversations with Allan Kennedy at that time. Allan is a pioneer of executable UML products, UML being another language for Model-Based Design. We had many discussions about how hardware and software development are related and compare. We did conclude at one point, that one vital property of the hardware flow - its seamlessness that connects the output of each transformation phase directly to the next - was barely entering mainstream adoption for the world of software at the time. Allan identified three significant areas of UML usage. First, the use-model of "sketches" for graphically outlining the intent of functionality. Second, the "blueprint" use model to describe the actual software architecture, with its implementation still unknown. And thirdly, the "executable" use model in which an action semantic is added to UML and with model generators the xUML entry directly maps into target implementations. It is this third use model, which directly links the output of the xUML specification phase into executable software implementations, for which I am still very optimistic about significant market growths beyond the current markets. Once directly tied into the implementation flow, model investment at that level becomes safe and re-usable.

Today, more than a decade later, technology has progressed even further, and Model-Based Design becomes more and more critical for project success. Math is the foundation of it all. And the industry is very actively working towards bringing the different domains of electrical and mechanical closer together. We are getting closer to "full simulations" of systems as complex as planes.

Exciting times for simulation, math, and computational software.

Images Sources: Bigstockphoto.com, Frank Schirrmeister