Model-Based Design with Production Code Generation for Steer-by-Wire System Developme

Model-Based Design with Production Code Generation for Steer-by-Wire System Development


by Joachim Langenwalter and Tom Erkkinen

Production code technology has become a key component in the evolution of software development because it is practical: you can add details to designs directly on a model and then automatically generate the final code. Production code generation has done well in early adoption; however, further growth requires a supporting software engineering framework that integrates processes, methods, and tools. Model-Based Design provides such a framework. Using a steer-by-wire system example, this article describes the application of production code generation and Model-Based Design to embedded automotive systems development.
Model-Based Design with Production Code Generation

Engineers use Model-Based Design in nearly every industry that requires embedded control systems development. It is particularly well entrenched in development processes for embedded applications such as large-scale automotive electronic control units (ECUs). The high-volume nature of mass-produced ECUs demands low-cost, fixed-point microcontroller units and DSPs, so the final executable code must be extremely compact, fast, and traceable.
Signal processing and communications applications also use this approach, with an emphasis on modeling and prototyping rather than production code generation. Model-Based Design provides control and signal processing systems engineers and software developers with a common environment for graphical specification and analysis. Models serve to specify system data, interfaces, feedback control logic, discrete and state logic, and real-time behavior.
In Model-Based Design, a block diagram or a state diagram model can serve as the system design, software requirements, software design, or even (in some developer's minds) as source code. Model-Based Design emphasizes process iterations, early testing, and code reuse throughout the development process. Production code generation is an automatic translation from detailed design.
To satisfy growing demand, Model-Based Design must address the needs of safety-critical systems such as steer-by-wire systems, which often require additional process rigor. Through simulation and prototyping, this approach supports safety-related system development by providing extensive verification and validation (V&V) prior to a final build. The benefit of early V&V is clear: system integration and testing result in fewer bugs and less rework. Identifying a bug on the desktop is highly preferable to encountering it during a winter test drive in Finland.
The following sections discuss the development activities, key V&V methods, and integration tasks in the development of a steer-by-wire system. These activities and methods are detailed in the paper “High-Integrity Production Code Generation.”
Behavioral Modeling

In Model-Based Design, we use models to specify requirements and design for all aspects of each subsystem (e.g., the steer-by-wire system).
A typical system includes:

• Inputs (for example, steering wheel sensors)
• Controller or signal processing model
• Plant or environment model (DC motor, rack and pinion, wheels, and communications)
• Outputs (change of direction)

We can create a system model to represent the desired behavior using control system block diagrams for feedback control, state machines for discrete events and conditional logic, and signal processing blocks for filters (Figure 1).
Figure 1. Feedback model of a PI controller for steer-by-wire. Click on image to see enlarged view.
Simulation and Analysis

We execute the model and then analyze it to ensure that the requirements are satisfied, using methods such as time- or event-based simulation and frequency domain analysis. For example, a steer-by-wire system must respond to a sensor failure, attenuate a high-frequency response below 3 db, and not lag commanded rate by more than 1.5 m/sec.
Figure 2A. Steer-by-wire system. Click on image to see enlarged view. Figure 2B. Steer-by-wire system with fault-tolerant redundant bus system (FlexRay).
We model and simulate the steer-by-wire system (shown in Figures 2A and 2B) to determine whether the requirements are valid. Simulation, a core validation activity, ensures that a system can be developed to satisfy the requirements.
Rapid Prototyping

Because plant models can be inaccurate and the production processor may not provide sufficient processing power to get a working result, modeling alone does not provide the total solution.
Rapid prototyping overcomes these shortcomings because it replaces the plant model with the physical plant. In the steer-by-wire example the plant might be a car, so an actual car is used. However, because the new ECU system is not yet built, a real-time or embedded platform runs the controller software and interacts with the plant.
There are two forms of rapid prototyping: functional and on-target. Functional prototyping uses a powerful real-time computer such as a multiprocessor floating-point PowerPC or DSP. The goal is to determine whether the system controls the physical car as well as it controlled the modeled car. If so, plant model inaccuracies are considered insignificant and the control strategy is validated.
On-target rapid prototyping executes the software in the same or similar production MCU or DSP, rather than a high-end PowerPC core or other dedicated high-end rapid prototyping hardware. The goal is to download the code into the actual production target for quick testing with the physical plant. If it performs well, the controller is not only deemed valid, but also feasible: it can be realized in production.
Detailed Software Design

Software design activities include fixed-point data specification, real-time tasking, data typing, built-in-test, and diagnostics.
With Model-Based Design, the same model used for algorithm specification and validation is refined and constrained by the software engineers as part of the production code generation process. Automated scaling and data type override help convert floating-point models to fixed point and provide mechanisms to assess a fixed-point design by simulating it in floating point.
Figure 3. Possible faults on the steer-by-wire system.
Model Testing

Testing the model on a desktop is preferable to deploying it on hardware for build and integration. Source-code-based testing has existed for many years, and recent methods enable model testing and structural coverage analysis. Using simulation and coverage, developers can fully stress the controller to verify its design integrity. Failure Mode Effect Analysis ensures the safe operation of the steer-by-wire under fault conditions (Figure 3).
Numerical overflow and dead code are examples of poor design integrity. Stress testing of the model using minimum and maximum numerical values helps ensure that overflow conditions will not occur. Simulation facilitates this method of stress testing, but dead code is not easy to find because detection requires structural coverage analysis. Dead code differs from deactivated code in that the latter is known to the developer and is deactivated for a reason. Actual dead code indicates that details were omitted during requirements, design, or test case development.
Model coverage assesses the cumulative results of a test suite to determine which blocks were not executed or which states were not reached. Certain types of coverage are well established in source code languages (such as C and C++). However, these languages do not posses constructs such as blocks or states, so we need new theory and tools to obtain model coverage.
The FAA considers Modified Condition/Decision Coverage (MC/DC) the most stringent coverage level necessary to satisfy safety-critical system requirements. Model-Based Design enables MC/DC, which is in many cases required for x-by-wire designs.
Figure 5 shows the result of coverage analysis for the power management design shown in Figure 4.
Figure 4. Power management to maintain power level for x-by-wire system. Click on image to see enlarged view. Figure 5. Coverage for the power management design shown in Figure 4. Click on image to see enlarged view.
Distributed Architecture Design

Modern embedded systems contain several distributed ECUs, which communicate in real time with each other over a fault-tolerant communication system such as FlexRay. BMW 's latest Dynamic Stability Control (DSC) contains ABS as one of 15 sub-functionalities. Adding blocks of DECOMSYS network components such as hosts, tasks, signals, and so forth to the individual subsystems enables the embedded functions to be connected and mapped onto an architecture of ECUs. Using the blocks in this way makes it easier to simulate the temporal behavior of task activations of a time-triggered operating system such as OSEKtime/OS. Engineers design and simulate clusters, hosts, tasks, and connections within the model environment.
The distributed network design solution from Vector (DaVinci) then integrates the code generated from models with legacy code from other subsystems and different suppliers and maps the resulting code onto the ECU or system architectures for verification.
Production Code Generation

After the model has been verified and validated, it is time to generate code. As with a standard C compiler, this process is straightforward. Various optimization settings and user configuration options exist. The key is to keep the code efficient, accurate, and integrated with legacy code or other tools. In safety-related software, it is also important for the code to be traceable to the diagram so that it can be reviewed and verified.
In-the-Loop Testing

Once the controller is built, we can perform a series of open- and closed-loop tests with the real-time plant model in the loop. Some tests involve only the software or processor and are known as “software-in-the-loop” or “processor-in-the-loop” testing, respectively. Another test, termed “hardware-in-the-loop,” uses the actual built ECU hardware. In either case, we test the physical controller with the plant model. Through a series of tests, perhaps the same test used during requirements validation, the controller must be proved acceptable to the customer.
Integration Components

Most software standards require traceability of requirements, perhaps originating in other requirements tools, throughout development. Also, Software Configuration Management (SCM) is needed to store, version, and retrieve the various development artifacts. Documentation via report generators ensures that management, customers, and suppliers will see the model. Model-Based Design supports all of these components. Figure 6 shows the SCM interface.
Figure 6. Source Control Interface. Click on image to see enlarged view.
Additional Resources

This article introduces a full software engineering framework that focuses on Model-Based Design with production code generation. The specific methods and tools described here demonstrate the feasibility of this approach to embedded system development. To learn more or to exchange ideas regarding additional methods and use cases, please contact the authors.
For a detailed comparison of traditional software development processes and Model-Based Design, see Measuring Productivity and Quality in Model-Based Design in the August 2004 issue of the MathWorks Aerospace and Defense Digest.
Visit www.ieee.org and RTCA Inc. to learn more about safety-critical standards and requirements.
Aldrich, B. “Using model coverage analysis to improve the controls development process.” AIAA 2002.
RTCA Inc. “Software considerations in airborne systems and equipment certification.” RTCA/DO-178B, Dec. 1992.
von der Beeck, Michael. “SW-Development for Electronic Control Units.” ARTIST Industrial Seminar, Paris, April 23, 2002.
Yih, Paul, Jihan Ryu and J. Christian Gerdes (2003) “Modification of vehicle handling characteristics via steer-by-wire.” Proceedings of the American Control Conference, Denver, CO, pp. 2578–2583.

更多...