High-Integrity Code Generation and Verification

High-Integrity Code Generation and Verification


by Tom Erkkinen

Code generation helps software and systems engineers by providing a common framework for adding software details to models for deployment in embedded systems. Details such as data typing, function partitioning, and external code integration can be specified at such a low level that the model can effectively serve as the detailed software application.
High-integrity software development requires the use of specific practices and processes including requirements tracing, configuration management, and verification and validation. This article describes how the code generation technologies of Model-Based Design fit within and enhance this type of formalized software engineering environment.
Software Integrity

High-integrity code often requires certification. For example, airborne systems are certified by government agencies such as the FAA, JAA, DOD, MOD and others. To achieve certification, systems undergo a safety assessment to identify failure conditions and evaluate system response to failures, ranging from catastrophic to no effect.
The software integrity level is determined by its contribution to the failure condition. If the system response to a software-induced failure is catastrophic, or severely impedes safe flight, the software must be developed as high-integrity. Recently, high-integrity software has become more pervasive and complex as new aircraft systems increase their reliance on autonomous embedded control strategies, such as fly-by-wire and integrated avionics.
There are many standards worldwide that help developers create high-integrity software. Standards organizations certify systems based on evidence or artifacts produced by engineers during the development process. Such standards and processes are followed whether the flight code is generated automatically or by hand.
High-integrity software engineering processes fall into the following categories:

• Development and Integration
• Verification and Validation
• Integral Activities

Development and Integration starts with creating system requirements and ends with system integration and acceptance testing. Flight code generation is included in this effort, spanning from detailed software design to software module integration.
Verification and Validation (V&V) is a main focus for high-integrity systems and encompasses the systematic application of reviews, analysis, and testing during each development and integration phase. V&V ensures that the right product is being built in the right way. For high-integrity systems, module testing and code coverage often involve a major effort. Of great importance, and equal in terms of effort, is the need to ensure that the requirements are valid and that the implementation satisfies the requirements (including derived requirements).
Integral activities include basic information management tasks such as configuration management and version control, documentation, and requirements traceability. These tasks are critical for high-integrity software development, as they provide the necessary artifacts to gain certification agency approval.
Automatic code generation must fit within these engineering processes and activities for high-integrity systems. Using the code generation technologies within Model-Based Design can help developers succeed in a certification environment.
Development

In Model-Based Design, a model consists of block diagrams and state machines, each with specific timing and real-time execution characteristics. In industry applications, models can serve at different levels of abstraction:

• System architecture
• System design
• Software requirements
• Software architecture
• Software design
• Source code

In this discussion, source code is regarded as simply the lowest level at which the developer manually describes the software. Earlier, this would have been at the machine or Assembly level. Today, C, C++, or Ada code is often treated as the source, but within the context of this discussion, a detailed model could certainly be considered the source.
System Specification

Using executable specifications during system design enables more effective V&V effort before the final build. Visualizing and interacting with your specification improves understanding and lets you tune its performance more easily. Automated model checkers, such as the Model Advisor in Simulink, apply systematic checks to the model, improving robustness and aiding consistency of the generated code. Ultimately, a more effective V&V effort based on executable specifications lets you catch more bugs earlier, saving costly iterations to fix them.
The components in a typical system model include sensors, actuators, control system, and the plant environment. The overall system model involves a combination of discrete and continuous time dynamics. A typical industry model also contains finite state machines using Stateflow to model mode logic or events. Figure 1 shows a typical Simulink system model.
Figure 1. FADEC system model. Click on image to see enlarged view.
Detailed Software Design

Detailed software design begins once the system design has been specified using models. This is when the systems and controls groups transition their work to the embedded software and integration teams. Unfortunately, this is also the point at which communication weakens and, without code generation, lengthy manual conversion of models to embedded code begins.
Model-Based Design helps ease this transition by providing a framework for performing detailed software design directly on a shared model, without conversion. Detailed software design activities using models include:

• Data type definition
• Storage class specification
• Fixed-point scaling
• Real-time tasking
• Built-in-test and diagnostics
• Initialization and shutdown routines
• Function and file partitioning
• Legacy code inclusion
• Device driver integration

Once the software design is complete, the final code is generated automatically.
With Model-Based Design, the algorithm model is, in effect, constrained by the software design. For example, the algorithm may be developed in double precision for the ideal behavior, after which single-precision or fixed-point data types are added to get the actual behavior on the embedded microcontroller.
Figure 2. Detailed design for FADEC. The dialog box shows where data design information or constraints are entered. Click on image to see enlarged view.
Figure 2 shows a model and parameter dialog box for the Sum block. We change fields in the block’s parameter dialog box to convert the double-precision version of the Sum Block, used during algorithm specification, into a detailed software design. You can also use the Model Explorer in Simulink to develop a data dictionary for specifying signal and parameter attributes (Figure 3).
Figure 3. Using Model Explorer to create a data dictionary. Click on image to see enlarged view.
Using Simulink Fixed Point, you can override the single-precision or fixed-point data type information specified during the software design phase, permitting simulation and code generation using double precision. This makes it easy to go back and forth between requirements and design, which is a problem with manual development methods, especially during maintenance.
High-integrity software requires fine-grain control of the storage classes and qualifiers used for the data definitions. The Model Explorer lets you define and associate storage classes with individual signals and parameters. You can also use the Custom Storage Class Designer to design user-specified data attributes (Figure 4).
Figure 4. Custom Storage Class Designer. Click on image to see enlarged view.
High-integrity software also requires explicit use of data and restricts implicit promotion and conversion of data types during math or other operations. For simulation and code generation, you can set warning and error flags that detect a variety of mistyped operations. This is a great advantage over using C as the source, as C is inherently a weakly typed language.
Code Generation

The FAA Guidelines document RTCA/DO-178B states the following:

"The objective of the software coding process is:
a) Source code is developed that is traceable, verifiable, consistent, and correctly implements low-level requirements."

With a detailed model, emulation on the host or code execution on the target let you verify that the implementation satisfies (or closely approximates) the specification model, after which you can generate the actual embedded code.
As with a C or Ada compiler, code generation is straightforward, with various optimization settings and user configuration options that let you consistently get the code format you want. The code must be efficient, accurate, deterministic, and integrate well with other code or tools. It is also important for the code to be traceable to the diagram, so that it can be reviewed and verified.
Embedded Target Integration

Some development organizations place custom device drivers in the model so that the model can fully specify the entire software system. Other groups keep the application software (AS) separate from the operating system software (OS) to improve modularity and portability. Real-Time Workshop Embedded Coder supports either approach because you can generate ANSI/ISO-C using the Embedded Real-Time (ERT) target, or target a specific microprocessor using a MathWorks Embedded Target product. In either case, you must specify the target word sizes (e.g., the number of bits in an integer) along with other hardware characteristics using the Hardware Implementation pane (Figure 5).
Figure 5. Setting target hardware characteristics. Click on image to see enlarged view.
Tracing and Reviews

Several code generation technologies support code inspections and requirements tracing, which are often essential in high-integrity software development. For example, you can insert block descriptions from the model into the code. HTML code reporting enables hyperlinks from the generated code to the model. When you view the code report file and click on a hyperlink in the code it displays and highlights the corresponding block in the model. (For details see the Real-Time Workshop Embedded Coder User Guide section “Code Generation Options and Optimizations.”)
Verification and Validation

DO-178B provides detailed guidelines on an acceptable verification strategy for high-integrity software, with a focus on requirements-based testing and structural coverage analysis. The highest level of integrity, Level A, requires “Modified Condition/Decision Coverage” (MC/DC). Obtaining 100% MC/DC is often one of the biggest challenges to high-integrity software development.
Simulink Verification and Validation offers automated testing and coverage capabilities that support extensive requirements-based testing, increasing the likelihood of achieving high levels of structural coverage. (Aspects of this approach were discussed at the 2002 AIAA GN&C conference.) Figure 6 shows a series of test sequences specified using a Signal Builder block.
Figure 6. Simulink Verification and Validation. Assertion blocks associated with the test scenario are shown on the right-hand side. If the test case fails, an assertion is raised, letting the engineer know that there was an error, perhaps with the requirement, design, or test case. Click on image to see enlarged view.
Figure 6 also shows the individual requirements associated with each verification block. Test engineers double-click on the requirement inside the signal builder block to open and highlight the requirement source (such as Microsoft Word or Telelogic’s DOORS) (Figure 7).
Figure 7. Tracing requirements using DOORS. Click on image to see enlarged view.
Model coverage can also be generated as part of the test procedure. The coverage reports on state reachability and gives cumulative structural coverages for multiple runs. Current coverages reported include MC/DC and signal range coverage.
With the Real-Time Workshop Embedded Coder and Simulink Verification and Validation, requirement descriptions can also be generated in the code to provide a traceability path from system requirements to the embedded code.
Code generation configuration options provided by Real-Time Workshop include build process hooks, which enable automatic invocation of other tools, such as instruction set simulators and code coverage tools, for further analysis and verification efforts at the code level. (For details see the Real-Time Workshop Embedded Coder User Guide section “Advanced Code Generation Techniques.”)
Configuration Management

Configuration Management (CM) systems help support version control and management of documents, models, software, and builds. Such systems require developers to check out software before making changes and then check in the changed software with revision information. The merging of changes is repeatable and reversible.
CM is a fundamental requirement of any software engineering process. High-integrity systems add additional scrutiny and approvals, typically involving configuration control boards. MATLAB and Simulink offer a source control interface that lets you manage models using Microsoft Common Source Control for Windows and specific CM tools for UNIX. (For details, see the Simulink User Guide, “Managing Model Versions.”)
Documentation

Documentation enables management, customers, and suppliers to comprehend and approve the model at key milestones such as formal design reviews (e.g., PDRs or CDRs). Simulink Report Generator enables automatic generation of reports such as that shown in Figure 8, in which the documents are based on executable models.
Figure 8. Automatically generated report. Click on image to see enlarged view.
Summary

Generating code requires supporting a full range of software engineering activities that are heavily based on the use (and reuse) of models. This article demonstrated how the automatic generation of flight code using Model-Based Design fits within software engineering frameworks for high-integrity systems.

更多...