Tom Erkkinen

Embedded Real-Time Control via MATLAB, Simulink, and xPC Target

1 The MathWorks, Inc., Simulink Development, 3 Apple Hill Dr., Natick, MA 01760-2098, U.S.A. 2 The MathWorks, Inc., Application Engineering, 39555 Orchard Hill Place, Novi, MI 48375-5374, U.S.A. 3 The MathWorks, Inc., xPC Target Development, 3 Apple Hill Dr., Natick, MA 01760-2098, U.S.A. 4 The MathWorks, Inc., Technical Marketing, 39555 Orchard Hill Place, Novi, MI 48375-5374, U.S.A. 5 The MathWorks, Inc., Application Engineering, 3 Apple Hill Dr., Natick, MA 01760-2098, U.S.A. 6 The MathWorks, Inc., Technical Marketing, 3 Apple Hill Dr., Natick, MA 01760-2098, U.S.A.

Automatic Code Generation - Technology Adoption Lessons Learned from Commercial Vehicle Case Studies

Using Model-Based Design, engineers model complex systems and simulate them on their desktop environment for analysis and design purposes. ModelBased Design supports a wide variety of C/C++ code generation applications that include stand-alone simulation, rapid control prototyping, hardware-in-theloop testing, and production or embedded code deployment. Many of these code generation scenarios impose different requirements on the generated code. Standalone simulations usually need to run fast, for parameter sweep or Monte Carlo studies, but do not need to execute in true hard real-time. Hardware-in-the-loop tests by definition use engine control unit (ECU) component hardware that requires a hard real-time execution environment to protect the physical devices. Code generated for production ECUs must satisfy hard real-time, efficiency, legacy code, and other requirements involving verification and validation efforts. With Model-Based Design, the functional behavior of the model needs to match that of the generated code. As a result the transformation of models into generated code must include necessary deployment and real-time artifacts to ensure that the code executes properly in the final software and hardware environments. For example, in a typical commercial vehicle use case, a diesel engine control algorithm and engine plant model are simulated together as a hybrid system. The plant model is input into the code generator for deployment in a hard real-time HIL lab. Code generation for the engine control algorithm is often done in two, or even three, phases. First, the code is generated for real-time rapid control prototyping for algorithm assessment and refinement. Next, the code may be generated for execution on the actual embedded microprocessor during on-target rapid prototyping for algorithm assessment on the ECU hardware. Finally, the code is generated for production ECUs and several verification steps are employed, including software-in-the-loop (SIL), processor-in-the-loop (PIL), and finally hardware-in-theloop (HIL) testing. Organizations moving from traditional waterfall processes that involve paper documents and hand code to Model-Based Design face challenges familiar to those who have followed other technology migrations, such as drafting tables to CAD systems or Assembly language to C code. These challenges center on how to: • best leverage the technology • reuse existing process • pace the transition • develop necessary skills sets and training This paper describes case studies on how John Deere adopted Model-Based Design for commercial vehicle development and discusses the benefits and lessons learned. INTRODUCTION TO MODEL-BASED DESIGN A model represents a dynamic system whose response at any time is a mathematical function based on its inputs, current state, and current time. Historically, system engineers have used block diagrams as shown in Figure 1 to create models and design algorithms within numerous engineering areas such as Feedback Control and Signal Processing. In recent years, graphical modeling environments consisting of block diagrams and state machines have been used to analyze, simulate, prototype, specify, and deploy software algorithms within a variety embedded systems and applications. ModelBased Design refers to the use of models and modeling environments as the basis for embedded system development. Output Plant Environment Embedded System Input

Fixed-Point ECU Development with Model-Based Design

When developing production software for fixed-point Engine Control Units (ECUs), it is important to consider the transition from floating-point to fixed-point algorithms. Systems engineers frequently design algorithms in floating-point math, usually double precision. This represents the ideal algorithm behavior without much concern for its final realization in production software and hardware. Software engineers and suppliers in mass production environments, however, are concerned with production realities and often need to convert these algorithms to fixed-point math for their integer-only hardware. A key task is to design scale factors that maximize code efficiency by minimizing the bytes used, while also minimizing quantization effects such that the fixed-point algorithms match the floating-point results within an acceptable numerical margin. This floatingto fixed-point conversion task is tedious, labor intensive, error-prone, and often requires multiple iterations between system and software engineers. Model-Based Design simplifies fixed-point development by providing tools and workflows that help the conversion process. System engineers doing on-target rapid prototyping for fixed-point ECUs often benefit from automated scaling and workflow assistance to support their initial fixed-point design. Production software engineers benefit from automated scaling as well, but they also require fine grain control over fixed data specification in their modeling environment to work with accumulator word sizes and target-specific optimizations. In addition to providing automated scaling and fine grain data modeling features, Model-Based Design capabilities for fixed-point verification and validation continue to evolve. One example is bitaccurate, fixed-point simulation with automated comparison to embedded software results using processor-in-the-loop testing. This paper presents Model-Based Design capabilities and tools that support development and verification of fixed-point ECU software used in mass production vehicles. INTRODUCTION Model-Based Design provides executable specifications, automatic code generation, and automated verification and validation tools. These technologies can be used to accelerate software development for any embedded system. Additional engineering effort is needed to produce the optimized designs and efficient code needed to satisfy the resource constraints of embedded microprocessors used in mass production. Thus, it is important to have processes and guidelines that yield optimal fixed-point code. This paper presents recently developed technologies and industry best practices for developing fixed-point code using Model-Based Design. The topics presented are: Developing the system model Preparing model and data for conversion Floatingto fixed-point conversion Generating optimized code Performing verification and validation DEVELOPING THE SYSTEM MODEL A case study based on a well-known fault tolerant fuel system demonstration model (shown in Figure 1) will help illustrate the development and verification of fixedpoint ECU software using Model-Based Design. Because this model has been described in previous literature [1], it will not be detailed here. However an overview is provided to explain the model structure and purpose. Figure 1: System model. The fuel control system model has three main components: a controller model for the ECU, a plant model for the engine gas dynamics, and several sensors. The engine model consists of air-fuel intake dynamics comprising both the throttle body and intake manifold. The engine model has two inputs, engine speed and throttle angle; and three outputs, sensed oxygen, manifold pressure (MAP), and air-fuel ratio. The plant model is developed using continuous time blocks. A 10 millisecond (10 ms) sample rate is required for the fuel rate control system algorithm. A closed-loop simulation can be performed using the plant and controller, plus input stimulus and output scopes. The controller must be tolerant to sensor failure faults. Faults can be inserted using manual switches. By toggling the input signals to nominal or fault values, model developers can examine the effect of the fault on controller performance and assess the controller’s tolerance to faults. The control system consists of a state machine and block diagrams. The state machine detects faults and establishes a fueling mode. Block diagrams model the sensor correction and fault redundancy logic, intake airflow estimation and correction logic, and a fuel rate calculation that concludes with a software limit on the fuel rate output command. The control system model is shown in Figure 2. Figure 2: Control system model. The control logic diagram has three states for each input sensor: warm up, normal, and failure. The criteria for transitioning between states are established via threshold parameters for each sensor. A sensor failure counter is used to track the total number of sensor failures. This counter is then used to determine a fueling mode. A low fueling mode is used if there are no sensor failures; a rich fueling mode is used for one sensor failure; and a disabled mode is used for two or more failures. Figure 3 shows the main portions of the state machine. Figure 3: Control logic state machine. The intake airflow estimation and correction logic shown in Figure 4 includes feedforward and feedback control algorithms. Table lookups provide pumping constants and rates. Figure 4: Closed-loop block diagram. The system model is then simulated and time response results are collected for metered fuel and air/fuel ratio as shown in figure 5. Figure 5: System response. This fuel system model is typical of most models initially developed using Model-Based Design. These models address the behavioral or functional requirements but are not necessarily well suited for implementation on an embedded system for a variety of reasons, such as: Continuous time representation of blocks is used instead of discrete. Simulation results are calculated using double precision real data types instead of integer or fixedpoint types. Interfaces between components such as the controller, plant, and sensors are not well specified or locked down. Some organizations try to address these issues by forcing the system developer to consider implementation aspects during initial algorithm design. In others, system designers are free to explore and optimize behavioral designs using their preferred modeling style. PREPARING MODEL AND DATA FOR CONVERSION After a floating-point behavioral model is developed, it must be prepared for implementation on a fixed-point embedded microcontroller. Some preparation tasks are needed even if the code is to be deployed code on a floating point processor. For example, the embedded system will run in discrete time, so continuous time blocks used for the embedded algorithm should be replaced by discrete blocks. It is possible to automate this process using conversion utilities. Rate transition blocks can also be used to convert the continuous-time signals to discrete-time signals sampled at 10ms, as required by the controller. Note that the effect of sampling on system performance and stability must also be analyzed. Preparing a model for conversion to fixed-point math requires several steps outlined in the following sections. CREATE INITIAL REFERENCE DATA Before beginning any model conversion task, create reference signal data for your floating point, behavioral model. These results can be used later for equivalence comparisons with the fixed-point model and generated code. The results shown in Figure 5, for example, will be used for equivalence testing of the fuel system controller. REPLACE UNSUPPORTED BLOCKS Identify and replace blocks that do not support fixedpoint types. This includes replacing continuous-time with discrete-time blocks. Start by reviewing a list of data types supported by each block, as shown in Figure 6. For models with Embedded MATLAB® functions, choose those that support fixed-point. There are hundreds of functions and blocks that support fixed-point implementation, including all the functions an engineer would typically use in embedded algorithm design. Figure 6: Block data type support table. SET UP SIGNAL LOGGING Logging signals of interest during simulation is important because logged signals are used for analysis and comparison in other tasks. Model inputs and outputs are commonly logged (as was done with the initial reference data) but it may be helpful to log other signals to help with conversion to fixed-point. Engineers no longer need to specifically add blocks or name signals to log data. It is now possible to log unnamed signals or log all data from a selected portion of the model subsystem hierarchy as shown in Figure 7. Figure 7: Logging fixed-point data. SPECIFY TARGET HARDWARE CHARACTERISTICS The model simulation behavior and code generation outputs are determined by target hardware characteristics. Specifying the correct word lengths for char, int, long, and other attributes unique to a particular embedded microprocessor is needed to avoid producing incorrect results during simulation or code generation. CHECK MODEL SUITABILITY FOR PRODUCTION Automated model checks should be used to inspect the model’s suitability for production code deployment as shown in Figure 8. These checks cover a broad range of topics such as model upgrades and library links. Some checks, such as “identify questionable fixed-point operations” and “check hardware implementation”, are crucial for fixed-point development. Additional checks can be run, including checks based on the updated MAAB guidelines [2] or safety related standards such as IEC 61508 [3]. Figure 8: Model checks can determine a model’s suitability for

Verification, Validation, and Test with Model-Based Design

Model-Based Design with automatic code generation has long been employed for rapid prototyping and is increasing being used for mass production deployment. With the focus on production usage, comes the need to implement a comprehensive V&V strategy involving models and resulting code. A main principal of Model-Based Design is that generated code should behave like the simulation model. It should also be possible to verify that the model or design was fully implemented in the code. As a result, the transformation of models into generated code must be done in a way that facilitates traceability between the model and code. Also automated tests should be performed to determine that the code executes properly in its final software and hardware environments. For example in a typical commercial vehicle application, the control algorithm and plant model are simulated together in a system simulation environment. Once the system model satisfies the requirements, the control model is checked to ensure that it has been fully exercised or covered. Once checked, code is then generated for production applications. The code is analyzed, tested, and compared to the original model results. Common model and code verification activities include software-in-the-loop (SIL), processor-in-the-loop (PIL), and hardware-in-the-loop (HIL) testing. In addition to functional results, it is important especially for highintegrity systems, that the model and code have been checked and assessed to known standards. This paper describes recent advances in verification, validation, and test technologies involving Model-Based Design with production code generation. INTRODUCTION TO MODEL-BASED DESIGN A model represents a dynamic system whose response at any time is a mathematical function based on its inputs, current state, and current time. Historically, system engineers have used block diagrams as shown in Figure 1 to create models and design algorithms within numerous engineering areas such as Feedback Control and Signal Processing. In recent years, graphical modeling environments consisting of block diagrams and state machines have been used to analyze, simulate, prototype, specify, and deploy software algorithms within a variety of embedded systems and applications. ModelBased Design refers to the use of models and modeling environments as the basis for embedded system development. Figure 1: Feedback controller model. Systems developed using Model-Based Design include: • Commercial vehicle electronics • Power plant regulators • Digital motor controllers Model-Based Design is used throughout the system development life cycle and provides design flows that include continuous verification and validation of requirements, designs, and implementations. This approach is important for formal software processes such as IEC 61508 [1] and for other projects seeking error prevention and early error detection. The main development activities that occur during Model-Based Design include: • Modeling and simulation • Rapid prototyping • Production code generation and integration Verification and validation (V&V) occurs continuously during Model-Based Design and includes many activities. This article focus on two key activities: model checking and processor-in-the-loop testing. MODEL CHECKING An important group of model V&V activities comprise different static analyses and checking tools. Model advisors check a model for conditions and configuration settings that can result in inaccurate or slow simulation, problematic maintenance, or generation of inefficient production code. Reports are generated that list identified suboptimal conditions and settings. Advice is provided suggesting better modeling approaches and settings. There are several types of checks. Basic Model Checks: Automated model advice is provided using basic checks, requirements consistency checks, and industry model standard checks. Basic checks range from support for updating the model to be compatible with the current product release version, to identifying unconnected lines and ports, to checking the root model interfaces. To invoke the advisor, select the checks and then run them as shown in the leftand right-hand sides of Figure 2, respectively. Figure 2: Model advisor basic checks invocation After performing the checks, results are displayed as shown in Figure 3. Hyperlinks are provided in the report, automating navigating to the dialog or menu where the setting can be adjusted based on the reported advice. The basic model checks should be performed and reported deviations considered before other quality assurance measures such as peer reviews or industry model standard checks are done. Figure 3: Model advisor basic checks results Requirements Consistency Checks: If the model is linked with requirements in third-party requirement management tools or databases, these checks identify inconsistent, missing, or changed requirements. Requirements consistency checks can also identify and repair requirements with missing documents and inconsistent requirements descriptions. See Figure 4. Figure 4: Requirements consistency checks Modeling Standards Checks: Many projects use inhouse or industry specific software and modeling development standards. Model checks have already been developed for some industry standards including: • DO-178B • MAAB • IEC 61508 DO-178B is an aerospace standard that will not be discussed here. MathWorks Automotive Advisory Board (MAAB) checks facilitate designing and troubleshooting models for automotive applications. A new version of MAAB was made available in 2007, MAAB v2.0. MAAB checks include: • Prohibited blocks inside controllers • Port and signal name mismatches • Unconnected signals IEC 61508 is a generic, application-independent standard for electrical / electronic / programmable electronic safety-related systems (E/E/PES) that is supposed to ease the development of sector-specific norms for E/E/PES. It is applied transitionally in the development of E/E/PES in those areas for which a domain-specific norm does not yet exist. IEC 61508-3 is concerned with the requirements for software development. IEC 61508 can be considered as a prescriptive standard, which provides detailed lists of techniques and measures with recommendations. IEC 61508 model checks analyze the model and report on items such as model usage, model metrics, and configuration management information as shown in Figure 5. Figure 5: IEC 61508 checks report Model Complexity Measurement allows one to measure the complexity of the entire model as well as the individual subsystems. Cyclomatic model complexity is a measure of the structural complexity of a model. It is calculated with the IEC 61508 checks and approximates the McCabe complexity measure for code generated from the model. Model complexity measurement helps to achieve a modular approach on the model level and especially to maintain an appropriate module size limit. Finally, if the built-in checks are not sufficient, a model advisor API is available that facilitates the development of custom rule checks by engineers using Model-Based Design. PROCESSOR-IN-THE-LOOP TESTING Simulation of models is an early verification and validation (V&V) technique. Testing models via simulation is a more rigorous approach than the ad-hoc simulation runs used in early algorithm development. Model testing requires a systematic approach to test case creation and execution. Special blocks, such as signal builders and assertions, facilitate this type of rigorous test procedure. New capabilities for V&V on models now exist such as structural coverage analysis and test case generation. In-the-loop testing techniques allow one to reuse the model test cases and test environment for execution with the production application during various stages of integration. Software-in-the-loop (SIL) testing involves executing the production code for the controller within the modeling environment for non-real-time execution with the plant model and interaction with the user. The code executes on the same host platform that is used by the modeling environment. A code wrapper of the generated code provides the interface between the simulation and the generated code. See Figure 6. Figure 6: Software-in-the-loop testing. For hardware-in-the-loop (HIL) testing, the code is generated just for the plant model. It runs on a highly deterministic, real-time computer. Sophisticated signal conditioning and power electronics are needed to properly stimulate the ECU inputs (sensors) and receive the ECU outputs (actuator commands). Whereas rapid prototyping is often a development or design activity, HIL serves as a final lab test phase before final system integration and field tests commence. See Figure 7. Note that an on-target rapid prototyping and production code example using Model-Based Design based on case study by John Deere was presented at the SAE Commercial Vehicle conference in 2007 [2]. Figure 7: Hardware-in-the-loop testing. Processor-in-the-loop (PIL) testing occurs after SIL but before HIL testing. As with SIL, PIL exercises the production code for the controller in non-real-time. However the code executes on the actual embedded processor or an instruction set simulator, using the embedded cross-compiler. Thus, it verifies the embedded object code functional behavior. With PIL, the model does a single calculation iteration. The inputs are calculated and passed to a PIL block. The PIL block serves as a conduit and passes the model inputs to the code running on the embedded microprocessor, or emulated processor if an instruction set simulator is used. Once the target processor receives the model inputs, it executes a single time step and computes the output data. The outputs are then passed back to model using the PIL block. The model then continues to simulate while the target processor waits for new inputs. See Figure 8 for a PIL example using an Instruction Set Simulator (ISS). F