By Tom Erkkinen, The MathWorks

Model-Based Design with automatic code generation is increasingly being applied to the design of embedded flight-control systems. This approach involves the use of block diagrams, statecharts, and data dictionaries to model and simulate control algorithms. The resulting model is then used to automatically generate code that is deployed onto embedded microprocessors. Model-Based Design facilitates the use of prewritten blocks, data objects, and code generation options to substantially reduce development time. This article describes model style guidelines and best practices for automatically generating flight code.

Model Style Guidelines

Before starting to develop software, model style guidelines should be adopted to help simplify the transition from behavioral specification to flight code. Many organizations have developed their own model style guidelines, such as those  shown in Figure 1.

Figure 1. Model style guidelines from the MathWorks Automotive Advisory Board (MAAB).

Design and code standards are required by many certification standards. For example, the RTCA/DO-178B¹ standard is used by the FAA for flight software certification. Section 5.2.2.1a of this standard states: Low-level requirements and software architecture developed during the software design process should conform to the Software Design Standards and be traceable, verifiable, and consistent.

Many resources exist to help create their own standard. For example, the MathWorks Automotive Advisory Board (MAAB) style guidelines² are widely used in the automotive industry.

Model guidelines are particularly important in large and complex projects. As a rule of thumb, a project is considered large and complex if the model is too big for one person to know all the details, has more than 10,000 blocks, or links to over 10 custom libraries. In these projects, a model architecture that properly partitions the model components can substantially reduce the time required for simulation and model updates. The management of multiuser and multilocation modeling environments must also be considered in larger projects.

Model style guidelines for data, which consists of all the nongraphical information used within a model, are needed to ensure that the data is easy to understand, consistent, and properly applied, especially when many diagrams and models act upon particular data throughout the entire application.

Development Process

When company style guidelines are in place, the flight software development process can begin. At some point early in this process, a model moves from advanced research into formal software development. In this transformation, the model becomes an executable specification, and development activities, such as inspections and version control, occur. Flight software models and executable specifications consist of diagrams and data.

Initially, the specification focuses on establishing and assessing system behavior within an ideal environment, such as double-precision floating point desktop simulations. Later, the specification is detailed and constrained so that the generated code performs adequately in an embedded environment, such as a single-precision or fixed-point microcontroller.

A model is a hybrid composition of sensors, actuators, controller (or application), and plant (or environment). Often models build and simulate the system using continuous-time and variable-step solvers. This approach takes advantage of the fact that the sensors, actuators, and plant exist in a nondigital world where input/output relationships operate in a continuous or analog manner as functions of many parameters, such as atmospheric temperate. These relationships are often best modeled using continuous-time blocks and variable-step solvers. However, the embedded controller is the exception because it executes in discrete-time using fixed-step increments.

Converting a controller model to a discrete, fixed-step representation early in the development process, before more blocks and logic are added, saves time and possible rework later on by limiting the scope of the conversion and facilitating development iterations. Simulink® Control Design includes a model discretizer that automates continuous-to-discrete model conversion. Developers must specify the sample rate and transformation method, often through a Tustin-based approach, before using the model discretizer.

Managing Large-Scale Models and Data

Simulink helps engineers manage large-scale models with Model blocks for createing parent models containing blocks that refer to other models. Fundamentally, such a  model-referencing approach lets developers employ a scalable component-based architecture within Model-Based Design. In fact, some large corporations are using model-referencing techniques to create models with more than a half million blocks.

Model blocks can facilitate several additional enterprise modeling issues. They can:

• Improve configuration management, because each model referenced by a Model block is a completely separate file and configuration item from the model that references it
• Improve loading, updating, and simulation speed, because models are referenced, not copied, and loaded into memory only when necessary
• Support incremental code generation by generating code only for the Model block that has changed, which reduces code generation times and minimizes the impact of changes

Figure 2. Model architecture dependency graph example.

The support for incremental code generation helps minimize regression testing during maintenance or delta updates of already validated and certified flight code. Figure 2 shows a model architecture dependency graph for a model built by using model blocks.

MPT Module Packaging Tool (MPT) data objects, shown in Figure 3, are well suited for flight code generation because they offer a rich variety of data-object attributes. For flight code generation, the data object attributes should be completely established to limit the possibilities of misunderstanding and reduce the likelihood of inappropriate cast operations.

Figure 3. Data dictionary with MPT data objects.

Configuration Settings

Embedded code can be generated once the diagrams have been built and  the data dependencies have been resolved. At this point, it is important to review and understand the various code generation options for optimized code for a particular system. Optimization can focus on improving code efficiency or other items, such as traceability. Some settings may involve tradeoffs between efficiency and traceability or readability. For flight code applications, traceability and readability tend to win out over code efficiency optimizations. For example, enabling block reduction reduces code size, but it may also make tracing each block to a diagram more difficult.

A popular modeling style associates multiple configuration sets with a given model. Activation of the appropriate configuration set depends on where the development program is in the Model-Based Design workflow. For example, one may have a single model with the following configuration set options:

• Rapid_Prototyping_Config
• Flight_Code_PowerPC_Config
• Software_In_Loop_Config
• Hardware_In_Loop_Config

In this case, there is one model, using one code generator, with multiple configuration sets, that can be activated for multiple purposes.

One quick way to create an optimized configuration is to use the Configuration Wizard block, shown in Figure 5, from the Real-Time Workshop Embedded Coder block library: Engineers can add a Configuration Wizard block to a model and double click it. An M-file script executes and configures parameters to preset values in the model’s active configuration set without manual intervention. There is also a custom configuration block that can be associated with an example M-file script and be adapted to the flight program’s requirements.

Figure 4. Configuration wizard.

Conclusion

This article introduced model guideline concepts for Model-Based Design with automated flight code generation. Some of the specific tips and techniques presented were based on the experiences of many software organizations in multiple industries, including aerospace and defense. Several published guidelines and commercial tools were referenced, providing additional insight and capabilities. Automatic code generation is a fast-paced technology with many new capabilities and user experiences. As a result, novice and expert users must stay abreast of the latest features and model guidelines as they are introduced.

1. “Software considerations in airborne systems and equipment certification,” RTCA/DO-178B, RTCA Inc., December 1992.

2. “Controller Style Guidelines for Production Intent Using MATLAB®, Simulink® and Stateflow®,” MathWorks Automotive Advisory Board (MAAB), dated April 2001, www.mathworks.com/industries/auto/maab.html.