Using Model-Based Design to Test and Verify Automotive Embedded Software

However, the rapid growth in complexity of embedded software and electronics coupled with the difficulty of testing and verifying these systems has been associated with a rise in quality issues and recalls. According to IBM Corporation, automakers spend two to three billion dollars a year to fix software problems and 32 percent of auto warranty claims in the United States are for software- or electronics-related issues.

Model-Based Design has become the preferred approach for developing automotive embedded software because it improves the specification, design, and implementation phases. Now, new tools and capabilities are available for Model-Based Design that help address test and verification challenges, improving embedded software quality and shortening the test and verification cycle.

Model-based design for test and verification

Automotive engineers typically use models when developing functions that will run on an electronic control unit (ECU). The models in this Model-Based Design are used in multiple ways: to provide executable specifications, to analyze the system's dynamic behavior, to simulate system components and environmental conditions that reduce or eliminate the need for costly physical prototypes, and to design the algorithms. Furthermore, automatic code generation from these models has become an accepted way to implement production ECU software. In the coming years, it is expected to become the primary approach for implementing embedded control software in many automotive companies.

From a quality perspective, automatic code generation already helps by optimizing the design through analysis and simulation, as well as by the repeatable quality of automatically generated code. In addition, code can be generated from system-component and environmental models to generate hardware-in-the-loop tests.

Now, new and enhanced approaches can leverage these same models in more diverse and powerful ways – including requirements-based testing, coverage analysis, and test generation – to accelerate and improve the test and verification activities for today's complex embedded systems, including both embedded software and electronic components.

Tracing and checking requirements

Most software or process standards, such as CMM-I, require bidirectional traceability of the design to the requirements throughout development. The implementation code must also be traceable to the design, so that it may be reviewed and verified. Tools for Model-Based Design can link the textual requirements, captured in Excel, Word, or a requirement-management tool, to the model (the design). Any requirement that isn't satisfied in the design can be flagged, as can any design element that doesn't match to a requirement. If a requirement (or design) is changed, the tools indicate which corresponding design elements (or requirements) might be affected. In addition, the automatic code generator can insert HTML links into the generated C code so that the implementation can be traced back to the model, which is especially important for safety-critical systems. Together, these capabilities provide a complete traceability path from the code to the requirements (Figure 1).

1. An implementation of requirements tracing.

In addition to linking requirements to the design, tools for Model-Based Design offer capabilities for confirming that the design satisfies certain requirements. These requirements are inserted in the design model as properties (or assertions), and formal-method algorithms determine mathematically whether the properties are satisfied for all valid situations. If a scenario exists that would violate the property, the formal-method tool generates a counterexample, which the engineer can use in simulations and add to the test plan.

Model style checking

During the design phase, an initial high-level model is transformed into a model suitable for implementation purposes, including characteristics that are needed for implementation, such as fixed-point details, and removing portions that will not be implemented. In the same way that software engineers establish source-code style guidelines to make the code easier to read, test, and implement, engineers working with Model-Based Design establish model style guidelines to ensure that the model can be implemented and to facilitate understanding and testing of the model.

Depending on the desired workflow and whether a design represents a new feature or a modification to an existing feature, there are two approaches: limit the options available from the beginning to the designer, or apply checks later to the design as it is being transformed.

In the first approach, frequently used in safety-critical systems or designs that are small modifications of an existing implementation, the constraints are applied at the outset. Typically, this strategy is based on defining a constrained subset of model components (blocks or state machines), modeling constructs (how blocks are connected), and other settings (e.g., fixed-point aspects) that do not need to be checked manually in each design, because they can be checked systemically by the tools.

In the second approach, the model is checked against guidelines sometime later in the development process. This deferred checking enables the designer to start with an unfettered design, then gradually constrain and transform the design into a robust and testable implementation. Ideally, this model-checking is done in the modeling environment so that the developer can quickly flag issues and edit the design in an efficient and iterative manner.

Recently tools have been introduced that enable an engineering team to define and customize a set of model-checking rules, apply it to models, and address the exceptions immediately.