solidThinking Aviation Case Study Teaches Embedded System Design

What Are Embedded Systems

Embed software interface for the creation of embedded systems. (Image courtesy of Altair solidThinking.)

During a relocation, my parents begrudgingly left behind their old rotary phone. An often-overlooked aspect of the digital revolution: deployment of embedded digital systems over 30 years have replaced such analog technologies.

Embedded systems are digital computing systems programmed to perform a specific task within a larger mechanical or electrical system.

Typically, these embedded systems perform their duties on limited hardware resources. They sense a real-world condition, do some computations, and then produce an output or state change.

Embedded systems are now ubiquitous and account for the clear majority of CPUs manufactured globally. Take cars, for example: Merrill Lynch recently noted that the automotive semi-conductor market is worth $30 billion. Automotive chip sales have grown at a fairly steady 6.5 percent pace between 2010 and 2015, during which time the average vehicle chip content grow from $300 to $340.

Growth in demand is expected to accelerate with the increased adoption of hybrid and electric vehicles, autonomous navigation and the growing complexity of other transportation vehicles from subways to jet planes.

In fact, the much-ballyhooed Internet of Things (IoT) is basically the interconnection of more embedded systems via the Internet, with the goal of enabling more human-to-machine and machine-to-machine interactions.

How to Design an Embedded System

Living somewhere between mechanical, electrical and software engineering, embedded systems engineering has historically been the domain of real-time software developers. Currently, however, software packages designed for rapid virtual prototyping are allowing for a more diverse set of engineers to develop embedded systems.

Pump control logic block diagram in solidThinking Embed (Image courtesy of Altair solidThinking.)

In so-called “diagram-to-code” or “drag-and-drop”model-based design (MBD) programs, digital system models are constructed by simply sliding blocks into the work area and wiring them together with the appropriate connectors. The models can be built with either physical component or signal component blocks, depending upon the user’s preference.

The software then automatically converts the control diagrams into C-code and compiles the code into an executable ready to be downloaded to the target hardware. No hand-coding is required. Users can easily and intuitively make changes to control diagrams, compile and download modified code to the target hardware for execution in seconds. While the system is operating, users can even interactively update control parameters.

There are four steps to developing and testing a virtual embedded systems prototype:

Functional specifications are converted into block diagram based design models with acceptability regions.
The plant is modeled and the controller is designed, analyzed, and simulated until the control system satisfies all design model acceptability regions.
The controller model auto code is then generated and executed upon a target Microcontroller (MCU) architecture. This is often termed a Processor-in-the-Loop (PiL) simulation wherein instead of reading in the values of physical sensors, values calculated by the simulation tool are used as inputs to the embedded algorithm. Similarly, outputs of the control algorithms executing on the processor are fed back into the simulation to drive the virtual environment.
Finally, Hardware in the Loop (HiL) simulations take the concept one step further by including all system hardware including physical sensors in the simulation.

The cycle of design, programming and firmware/hardware testing in model based embedded MBD system design (Image courtesy of Altair.)

Richard Kolk, chief technical specialist for Math & Systems at Altair, is a leading expert in embedded systems engineering. He described the role of these software packages in the following way:

“Model based system designis a methodology for achieving and verifying required performance using dynamic models, automatic code generation, embedded systems (PiL), and embedded physical components (HiL). It provides engineers the ability to continuously and fully test designs as they evolve.”

Embedded Systems Case Study: AMETEK’s Jet Fighter Cooling System

A recent example of the efficient design process enabled with model based system design of this sort and using Altair’s solidThinking Embed software has been provided by AMETEK. AMETEK is a global manufacturer of electronic instruments and devices and often uses virtual prototyping software in developing its products.

F-35 Lighting II fighters. (Image courtesy of Lockheed Martin.)

In one instance, AMETEK developed a portable, flight suit temperature regulation unit for Lockheed Martin’s Joint Strike Fighter (JSF) program. Lockheed Martin went on to win the JSF program award with an anticipated life cycle cost of $1.1B (though not without controversy) and has now started production of the F-35 Lighting II fighter.

“As failure is catastrophic in aviation, there are very strict guidelines on software that is used in aviation,” said Keshav Sundaresh, global director of business development for Math & Systems at Altair. “For commercial aviation, the standard is DO-178C; for Lockeed Martin, it is SEAL (Safety Evidence Assurance Level). The challenges are to maintain high quality, safety and verification so delivered products meet the specified requirements.”

Figure 1 Process diagram of the personal chiller unit. (Image courtesy of Altair solidThinking.)

In conjunction with a refrigerant cooling vest, the Personal chiller Unit (PCU) maintains the pilot's core temperature below 100.4°F (38°C).

The chiller unit’s control system monitors the cockpit and jacket temperature sensors and internal motor speed.

Based on the data, it controls the compressor, expansion valve, and fan pump, while regulating the temperature to the pilot. Flight suit design temperatures are between 57° F (14° C) to 72° F (22° C.). A simplified process diagram is shown in Figure 1.

AMETEK Principal Engineer Kevin Godfrey, who led the AMETEK design effort, said, “We wanted to work in one environment, for the entire tool chain. [SolidThinking Embed] allowed us to do that.One of the advantages of Embed is that you are not directly coding in C. You are employing a diagram and using the automatic code generator to create the code. Embed allowed us to model the system and be confident about our design before committing to any hardware. The software guided us in the right path to take and speed up development.”

The team created a working model of the combined chiller unit and control system with a block diagram approach. They correlated and refined the plant model using measurements of plant responses in the lab.

Engineers then built a multi-loop PID controller with interlock safety stages that stepped through the start-up and shutdown actions necessary to avoid damage to sensitive device components. Of course, debugging is a necessary evil in this stage of development and SolidThinking Embed’s built-in debugging features were utilized throughout.

Next, the automatically generated ANSI C code from the controller model was compiled and downloaded directly onto the Texas Instruments (TI) C2000 target chip using bi-directional JTAG linking. JTAG technology allows easy interfacing between virtual prototype and firmware, and vice-versa. Engineers tested the new firmware running on the C2000 against the virtual model running in real time by using the Embed target interface block. This is an example of PiL testing.

When engineers were satisfied with the embedded controller’s behavior, they replaced the interactive JTAG input/output by electrically connecting the controller to the virtual prototype and adding digital I/O PC boards to create I/O signals equivalent to the signals from the real plants.

After another round of validation, engineers again generated ANSI C code from the controller model, downloaded it to the TI target and the firmware was run with the actual plant attached. Each subsystem was vigorously tested employing this established design-simulate-validate procedure. This is an example of HiL testing.

“There are requirements to link specification documents to implementation. There are requirements for validation and verification at the software component, or subsystem level. Smaller subsystems, compound blocks in Embed parlance, are validated at a low level, then larger subsystems that contain them are also validated. Validation is performed at both simulation level and on the embedded hardware via HIL,” clarified Sundaresh.

AMETEK was very pleased with the experience gained in virtual embedded systems prototyping, noting that they were able to iterate and optimize their designs and code to be as efficient as possible, which is a critical aspect when working with limited embedded system hardware.

This article is sponsored by Altair solidThinking. All opinions, unless stated elsewise, are mine – Stewart Bible.

About the Author

Stewart Bible is a principal engineer at Resolved Analytics. His interest in computational fluid dynamics began with his undergraduate and graduate research at the University of Kentucky, where he encountered his first commercial CFD code, CFD2000, ironically enough, in the year 1999. His current interests are in the areas of multiphysics and uncertainty quantification, with particular emphasis on medical devices, renewable energy and air pollution control systems.