Safety-Critical Software Development Using Automatic Production Code Generation

Copyright 2007 The MathWorks, Inc. 2007-01-1493 Safety-Critical Software Development Using Automatic Production Code Generation Tom Erkkinen The MathWorks, Inc. Mirko Conrad The MathWorks GmbH ABSTRACT When developing software it is important to consider process, methods, and tools. For safety-critical software, standards such as IEC 61508 are often used to impose additional constraints on the development process and require the production of verification evidence and other artifacts. These constraints and artifacts are needed whether or not the design and code were produced manually or via tool automation. This paper discusses the usage of Production Code Generation for safetycritical software development. INTRODUCTION Model-Based Design provides executable specifications, automatic code generation, and automated verification and validation tools. These technologies are used to produce safety-critical software, but extra consideration is needed to address the development constraints and artifacts imposed by industry standards and guidelines. Thus, it is important to have model and code generation guidelines that restrict the use of blocks and code generation settings if they produce designs and code not suitable for safety-critical systems. It is also necessary to perform rigorous model and generated code analysis and test during the development process and to record the results in the form of reports, logs, and other certification evidence. This paper presents recent applications of Model-Based Design with production code generation technologies that support safety-critical software development processes using Simulink and Real-Time Workshop Embedded Coder from The MathWorks. These safetyrelated technologies are described in the context of popular safety-standards and guidelines including IEC 61508 and MISRA-C. MODEL-BASED DESIGN FOR SAFETY- CRITICAL APPLICATIONS Model-Based Design is becoming the preferred software engineering paradigm for the development of embedded controls in central vehicle subsystems, such as powertrain and chassis. The main advantages of this approach are that software development time is reduced and product innovation is enhanced through the use of executable specifications and automatic production code generation. These advantages also apply for safetycritical applications. In such application contexts, safety standards such as IEC 61508 and commonly accepted guidelines like MISRA-C impose additional constraints and require the creation of additional artifacts. Furthermore, verification, validation and testing activities have to be carried out very thoroughly. These constraints and artifacts are needed whether or not the design and code were produced manually or via tool automation. However, most of the relevant standards and guidelines date back to the era before Model-Based Design and therefore don t directly include technologies used in Model-Based Design such as automatic code generation. Therefore, the standards need to be mapped into processes and tools for Model-Based Design. APPLICABLE STANDARDS AND GUIDELINES The standards and guidelines listed below are frequently considered relevant for the development of softwarebased safety-critical applications in the automotive domain. IEC 61508:1998 Functional safety of electrical/electronic/ programmable electronic safetyrelated systems 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. ISO/WD 26262:2005 Road vehicles - Functional safety The draft for a sector-specific specialization of IEC 61508 for the automotive domain ('automotive 61508') was compiled by the FAKRA working group 16 Functional Safety. It was handed over as a working draft to the ISO in November 2005 with the objective of standardization. Among other issues, ISO/WD 26262 contains parts dealing with software development (ISO/WD 26262-6) and supporting processes such as the qualification of development tools (ISO/WD 26262-8). MISRA-C:2004 Guidelines for the use of the C language in critical systems The Guidelines for the use of the C language in critical systems, compiled by MISRA, describe a subset of the programming language C, which is applicable for the use in safety-critical applications. The MISRA-C guidelines are adopted frequently in order to fulfill safety standard s requirements for a suitable programming language on the code level. MAAB Controller Style Guidelines for Production Intent Development Using MATLAB, Simulink, and Stateflow The MathWorks Automotive Advisory Board (MAAB) 1 compiled a set of modeling style guidelines [5] which can be used to create Simulink and Stateflow models for automotive applications. The MAAB modeling style guidelines together with additional modeling language considerations for safety-critical applications are used to address safety standard s requirements for a suitable language on the modeling level. Due to its draft status it is too early to discuss ISO/WD 26262 in detail. Rather, we will focus on IEC 61508, MISRA-C and the MAAB guidelines DEMONSTRATING COMPLIANCE WITH STANDARDS AND GUIDELINES IEC 61508:1998 A popular way to provide guidance for projects using Model-Based Design that must meet the IEC 61508 objectives is to use annotated versions of the software safety integrity tables given in the standard, see e.g. [7]. Depending on the safety integrity level, IEC 61508-3 1 see www.mathworks.com/industries/auto/maab.html recommends techniques and measures that are supposed to be applied in the individual software development phases. The recommends techniques and measures are summarized by means of associated software safety integrity tables in annexes A and B of IEC 61508-3. Altogether, the software integrity tables list more than 100 techniques / measures. As far as production code generation is concerned, the measures and techniques to be considered include for example: Language subset (see IEC 61508-3 Table A.3) Dynamic analysis and testing (see IEC 61508-3 Tables A.5 and A.9) Within the scope of a safety-critical development project it is necessary to document which measures were implemented and/or which replacement measures were employed. The project-specific accruing effort for this can be reduced effectively if respective generic documents (templates) for typical Model-Based Design projects are made available. These templates are then instantiated project-specifically. Therefore the software safety integrity tables from the standard are extended by an additional column labeled Applicable Tools / Processes for Model-Based Design. The entries in the column describe how the particular measure or technique can be supported by products or solutions for Model-Based Design; see Tables 1 and 2 for exemplary sections of commented IEC61508-3 tables. Table 1: Example of a generic, annotated software safety integrity table (see IEC 61508-3 Table A.3) Technique / Measure SIL1 SIL2 SIL3 SIL4 Applicable Tools / Processes for Model-Based Design 3 Language subset o o ++ ++ The MAAB Style Guides and/or organization specific modeling guidelines can be used to define a subset of the modeling language. The Simulink Block Data Type Support section of the Simulink documentation lists the blocks, which can be used for code generation with Real-Time Workshop Embedded Coder. MISRA-C and/or organization specific coding guidelines can be used to define a subset of the implementation language. Restricted language subsets can be partially enforced by using Simulink Model Advisor Restricted modeling language subsets can be enforced by model reviews based on reports generated by Simulink Report Generator. Restricted implementation language subsets can be enforced by code reviews based on Real-Time Workshop Embedded Coder Code Generation Reports. Third-Party Products such as

PolySpace Desktop can be used to verify MISRA-C: 2004 compliance. Third-Party Products such as PolySpace Desktop can be used to check language subset considerations within the generated code. 5. Application-specific modification/refinement of the remaining annotations in the column Interpretation in this application Table 3 exemplifies the results of the customization process for the table extract in Table 1. Table 3: Example of a derived application-specific table Table 2: Example of a generic, annotated software safety integrity table (see IEC 61508-3 Table A.5) Technique / Measure SIL1 SIL2 SIL3 SIL4 Applicable Tools / Processes for Model-Based Design 2 Dynamic analysis and testing + ++ ++ ++ The simulation capabilities of Simulink and Stateflow can be used to perform dynamic analysis. Simulink and Simulink Verification and Validation support dynamic testing on MIL level. C code generated by Real-Time Workshop Embedded Coder and reintegrated into the Simulink model can be used to perform dynamic testing on SIL level. C code generated by Real-Time Workshop Embedded Coder and reintegrated into the Simulink model together with Link for TASKING can be used to perform dynamic testing on PIL level. The Simulink Legacy Code Tool supports the integration of C Code for simulation within Simulink. SystemTest can be used to automate dynamic testing. Simulink Verification and Validation - Model Coverage can be used to perform model coverage analysis during dynamic testing. Third-party coverage tools for C code can be used to perform code coverage analysis during dynamic testing. The project-specific adaptation of the annotated software safety integrity tables comprises the following steps: 1. Selection of the SIL level for the application under development and removal of the columns for the non-applicable SIL levels. 2. Selection of a set of measures / techniques for the particular application (in case of alternate or equivalent techniques/measures). 3. Renaming of the column Applicable Tools / Processes for Model-Based Design into Interpretation in this application. 4. Labeling of the measures / techniques for the particular application depending on whether they are used, used to a limited degree or not used. If a particular measure / technique is not used, a reason has to be provided and the Applicable Tools / Processes for Model-Based Design belonging to it need to be removed 2. 2 IEC 61508-6 Annex E gives two worked examples of the application of the software safety integrity tables and Technique / SIL3 Interpretation in this application Measure 3 Language subset (See also Table C.1) ++ Used: The MAAB Style Guides are used as subset of the modeling language. MISRA-C:2004 is used as subset of the implementation language. The modeling language subset is as far as possible enforced by using Simulink Model Advisor. All reported deviations and Modeling Language considerations which cannot be checked automatically need to be manually reviewed. PolySpace Desktop is used to verify MISRA-C: 2004 compliance. All reported deviations need to be manually reviewed. Note, that this approach is generic and is also applicable to the upcoming ISO/WD 26262. MISRA-C:2004 and MAAB Guidelines IEC 61508 and other standards recommend the usage of language subsets for the development of safety critical software. As far as Model-Based Design is concerned, language subsets occur on the design level (a.k.a., modeling language subset) as well as on the code level (a.k.a., implementation language subset). Pure subsetting of the modeling and/or the implementation language is inadequate in many cases. Furthermore, compliance to an implementation language subset shouldn t be enforced only after the code has been generated. Instead it is important to have modeling and code generation guidelines that restrict the use of blocks and suggest proper code generation settings. Making recommended patterns and style guides available has also proven useful. According to [6] MISRA-C compliance is an implementation of a coding standard as required by IEC 61508-3. TÜV SÜD accepts MISRA-C if adherence to all MISRA-C rules can be shown (compliance to a subset of the MISRA-C rules will be accepted in well-founded exceptional cases only) and the compliance to the coding guidelines will be verified by a tool supported static code analysis. The OEM Initiative Software (HIS 3 ) also recommends to use the entire set of MISRA-C:2004 guidelines. For well-founded exceptional cases deviations are to be documented following the deviation on the documentation of the selected measures / techniques for a particular project. 3 see www.automotive-his.de

procedure described in section 4.3.2 of the actual MISRA-C document [4]. However, many people acknowledge that coding standards for production code generation and hand coding differ partially. Even MISRA launched an activity in 2005 to address the specifics of using visual modeling languages and automatic code generation for automotive systems. To address MISRA-C compliance, MathWorks maintains a MISRA-C compliance analysis package for Real-Time Workshop Embedded Coder since Release 12.1. This package is based on model inspections, code analysis, and quality engineering product tests suites. The MISRA-C compliance package includes an overview document, a compliance matrix, the presentation of violations and mitigations, Simulink and Stateflow model examples as well as Real-Time Workshop Embedded Coder code examples. Simulink is a general purpose visual modeling language. It can be use to create controller as well as plant models. So not all modeling features and settings provided, are appropriate for modeling automotive control software. The MAAB style guidelines were developed to address this issue. They became a popular source of information for the derivation of company specific modeling language subsets, pattern and guidelines. For safety-critical applications additional patterns and guidelines might be useful. A first group of activities comprise different static analyses and checks on the model level that are integrated into the Simulink Model Advisor. The Model Advisor checks a model or subsystem for conditions and configuration settings that can result in inaccurate or slow simulation, or generation of inefficient code from the model. It produces a report that lists all the suboptimal conditions and settings that it finds, and suggests better model configuration settings where appropriate. Basic Model Checks: Model Advisor provides some basic checks in order to ensure well-formed and efficient models. These basic model checks range from support for updating the model to be compatible with the current Simulink version to identifying unconnected lines and ports to checking the root model interfaces. The left pane lists the checks that the Model Advisor performs. The check boxes in this pane allow engineers to select a subset or all of the checks. After performing the checks, Model Advisor displays the results of the checks in the right pane (Fig. 1). The basic model checks should be performed and reported deviations should be considered, before other quality assurance measures, e.g., reviews, are performed. In summary, the MISRA-C:2004 and MAAB guidelines are means to partially fulfill the IEC 61508-3 requirements on language subsets and coding standards. Adherence to those guidelines can be seen as a subset of the related IEC 61508-3 requirements. To verify standard compliance, powerful verification and validation capabilities are essential. VERIFICATION AND VALIDATION USING MODEL-BASED DESIGN Within the scope of Model-Based Design, it is essential to subject the in-vehicle software and its executable precursory stages (models) to an appropriate set of verification and validation (V&V) measures. Since the executable models can be exploited as comprehensive sources of information for V&V, new possibilities for integrated quality assurance arise in the context of Model-Based Design. Verification and Validation is considered an integrated quality assurance process that is interwoven with Model-Based Design. It includes a combination of complementary activities on model as well as on code level, see e.g. [11]. MODEL-LEVEL V&V ACTIVITIES Model Analyses and Checks Figure 1: Simulink Model Advisor Some of the Basic Model Checks support individual IEC 61508 techniques / measures. Checking root model inport block specifications helps for instance to make sure that there is a fully defined interface (see IEC 61508-3, Table B.9, Technique/Measure 5: Fully defined interface). Simulink Verification and Validation extends the basic checks provided by Model Advisor as described in what follows. Requirements Consistency Checks: If the model is linked with requirements in DOORS, Teamcenter for Systems Engineering, Word or Excel, inconsistent, missing, or changed requirements can be found. Technically speaking, the Model Advisor Requirements Consistency Checks can identify and repair requirements with missing documents and inconsistent requirements descriptions (Fig. 2).

Besides supporting the MAAB guidelines directly, the Modeling Standards Checker provides tool support for the language subset objective of IEC 61508 on model level (see IEC 61508-3, Table A.3, Technique/Measure 3: Language subset). Model Complexity Measurement: Simulink Verification and Validation allows one to measure the complexity of the entire model as well as of individual subsystems. Technically, the cyclomatic model complexity, which is a measure of the structural complexity of a model, will be calculated. It approximates the McCabe complexity measure for code generated from the model. Figure 2: Model Advisor requirements consistency checks These requirements consistency checks can be used to support an IEC 61508 conformant Software safety requirements specification (see IEC 61508-3, Table A.1, Technique/Measure 1: Computer-aided specification tools). Modeling Standards Checks (R2006b): The new Modeling Standards Checker includes checks for many MAAB Style Guidelines Rules. These built-in checks include (Fig 3) for example: Prohibited Simulink standard blocks inside controllers (see MAAB guideline jm_0001) Port names in Simulink and Stateflow (see MAAB guidelines jm_0010 and db_0123) Unconnected signals (see MAAB guideline db_0081) Figure 3: Modeling Standards Checker MAAB Guidelines Checks Furthermore, a Model Advisor API is available which facilitates the development of custom rule checks by developers based on a flexible MATLAB rule syntax. Model complexity measurement helps to achieve a modular approach on model level and especially to maintain an appropriate module size limit (see IEC 61508-3, Table A.4, Technique/Measure 4: Modular approach and Table B.9: Technique/Measure 1: Software module size limit respectively. Reducing complexity is often a key method for achieving structural coverage analysis goals. Testing Capabilities of Model-Based Design Within the scope of Model-Based Design, executable models can be tested and the test information can be reused and applied later for testing of the code. In order to detect errors and produce confidence in the correct functioning of the software to be developed, it is essential to subject the software and its preliminary stages (models) to an appropriate combination of testing techniques. Such test strategies may include combinations of functional and structural testing techniques. The systematic selection of test scenarios from the functional specification and the interface descriptions (requirements-based testing) forms the focal point of a model test strategy. In addition, an adequate structural coverage requirement can be defined on model level and used to evaluate the completeness of the test scenarios. If sufficient model coverage has thus been achieved, the test scenarios can be reused for testing the code generated from the model and then embedded within the electronic control unit (ECU) in the framework of comparative (back-toback) tests. Requirements-Based Testing: Simulink includes tool support for defining test data and validating a model. Signal Builder blocks allow a graphical definition of test stimuli by means of piecewise defined functions. With the help of the Signal & Scope Manager, signals can be injected into the model without blocks having to be added. A library of predefined Model Verification blocks can be used to check assertions during testing (i.e. block outputs should conform to the properties specified within the assertions). Simulink Verification and Validation lets end-users link textual requirements to model elements, test scenarios, and verification blocks (Fig. 4).

automatic logging and reporting of coverage metrics for the model. Decision coverage (DC) examines items that represent decision points in a model, such as the Switch blocks and Stateflow states. For each item, decision coverage determines the percentage of the total number of simulation paths through the item that the simulation actually traversed. Condition coverage (CC) examines blocks that output the logical combination of their inputs, e.g., the Logic block, and Stateflow transitions. A test case achieves full coverage if it causes each input to each instance of a logic block in the model and each condition on a transition to be true at least once during the simulation and false at least once during the simulation. Condition coverage analysis reports for each block in the model whether the test case fully covered the block. Figure 4: Requirements Based Testing Linking DOORS requirements and test stimuli in Signal Builder The requirements linkage is bidirectional and supports links to high level requirement in Telelogic DOORS, Microsoft Word or Excel, or HTML. A published API allows project teams or third parties to produce other integrations. For example, UGS used this API to develop an integration between Simulink and Teamcenter for Systems Engineering [12]. SystemTest provides a flexible software framework for developing tests that exercise Simulink or Stateflow models. It can be used to perform parameter sweeps as well as to run different sets of test data that can for example - be specified using the Signal Builder. A Test Results Viewer helps to interactively access and analyze test result data. The functional testing capabilities of the Simulink product family described above can be used to support an IEC 61508 conformant Software module testing (see IEC 61508-3, Table A.5, Techniques/Measures 2: Dynamic analysis and testing and 4: Functional and black-box testing as well as detailed Tables B.2 and B.3). Model Coverage Analysis: Coverage analyses are well established in imperative programming languages such as C, and Ada, but these types of analysis were not made available at the model level until recently. Simulink Verification and Validation provides a Model Coverage tool that measures the coverage reached with a test suite available with regard to structural coverage and other criteria. It also provides metrics for the evaluation of the model complexity (Fig. 5). Modified condition/decision coverage (MC/DC) examines blocks that output the logical combination of their inputs (e.g., the Logic block) and Stateflow transitions to determine the extent to which the test case tests the independence of logical block inputs and transition conditions. A test case achieves full coverage for a block if, for every input, there is a pair of simulation times when changing that input alone causes a change in the block's output. A test case achieves full coverage for a transition if, for each condition on the transition, there is at least one time when a change in the condition triggers the transition. MC/DC is considered to be the most stringent coverage level necessary to satisfy safety-critical systems. Lookup table (LUT) coverage examines blocks, such as the 1D Look-Up block, that output the result of looking up one or more inputs in a table of inputs and outputs, interpolating between or extrapolating from table entries as necessary. Lookup table coverage records the frequency that table lookups use each interpolation interval. A test case achieves full coverage if it executes each interpolation and extrapolation interval at least once. For each LUT block in the model, the coverage report displays a colored map of the lookup table indicating where each interpolation was performed. Signal Range Coverage returns the maximum and minimum signal values at each block in the model measured during simulation. Decision, Condition, Modified Condition/Decision and Lookup Table and Signal Range Coverage metrics are available with Simulink Verification and Validation, and are conducted based on simulation runs. When done within Simulink, or from SystemTest, this enables the

test environment, or combined with other tools as part of a complete Testing Environment for Model-Based Design. Report Generation and Reviews Since not all quality aspects can be checked automatically, manual reviews still play a vital role in safety-critical software development. But, the modeling environment can ease the workload by providing good reports on demand. Automated report generation tools do this. These tools aid the preparation and execution of requirements and design reviews whether for formal or informal purposes. Figure 5: Model Coverage Analysis Example coverage report The model coverage analysis described in Figure 5 can be extended to include cumulative coverage as shown below (Fig 6). Tool automation helps ensure that reviews are executed quickly and efficiently by having well documented models with high degrees of traceability readily accessible. Recent report generation features allow model documentation files to be generated in a dynamic HTML format, based on scaled vector graphics implementation, such that model reviewers can navigate and step through model hierarchies from a standard browser without requiring the use of Simulink or Stateflow. Scripts and batch processing invoked as part of a configuration management and version control system allow for reports to be automatically produced when a new model version is checked in. This helps projects by ensuring documents, code, and even test results are kept up to date and synchronized with model updates and changes. A number of tools and features of Simulink provide automatic report generation. One example is the Model Coverage Analysis report shown in the preceding section. Other useful model reporting capabilities in Simulink include requirements traceability reports and Model Advisor reports as described in what follows. Figure 6: Model Coverage Analysis Cumulative coverage report An important aspect of performing structural model testing is the definition of appropriate test patterns that exercise all aspects of the model and, equivalently, of the code that is generated from the model. Many of these test patterns are identified interactively during the model development and from requirements. Supplementing test patterns, particularly for coverage objectives that haven t been covered otherwise, can be generated automatically by third party tools. Requirements Traceability Reports: Blocks and subsystems with requirements traced to external tools or documents can be highlighted in the diagram. This makes it easy to ensure all blocks have corresponding higher level requirements as well as to identify blocks with missing requirements. A report can be generated from the Model Explorer that shows the requirements traceability for the model, subsystem, and individual blocks as shown in Figure 7. The structural testing capabilities of the Simulink product family also help to fulfill IEC 61508 conformant Software module testing (see IEC 61508-3, Table A.5, Technique/Measure 2: Dynamic analysis and testing and Tables B.2 Technique/Measure 6: Structure-based testing). The Simulink Verification and Validation components can used stand alone, with an existing in-house model

Figure 7: Requirements traceability report Model Analysis Reports: Another useful report comes from the Model Advisor. This tool examines your model based on default or customized checks (see section on Model Analyses and Checks ) and produces an output that is displayed within the Simulink environment. However, it is also possible to export this output as an HTML report that can be viewed outside of Simulink, either standalone or incorporated within a documentation system. The MATLAB command sequence to export the Model Advisor report to a file name ecu_prj.htm based on your current model is as follows. >>Obj = Simulink.ModelAdvisor.getModelAdvisor(gcs) >>Obj.exportReport('ecu_prj.htm') An example standalone Model Advisor report viewed from a desktop browser is in Figure 8. Model Documentation Reports: The Simulink Report Generator allows engineers to create custom reports containing models, data, and analysis results. It also integrates reports from other products and features including requirements traceability tables. The model documentation reports facilitate reviews and walk-throughs on model level (see IEC 61508-3, Table B.8, Technique/Measure 2: 9 Walk-throughs/design reviews). Figure 8: Exported Model Advisor report Furthermore, the different types of reports can be used to document the individual development and V&V activities as well as to contribute evidence for the safety case. CODE-LEVEL V&V ACTIVITIES Code Analysis and Checks It is useful to employ analysis tools for examining C code deployed on production ECUs. Over the years, automotive organizations have incorporated a wide range of code analysis tools into their verification and validation process including in-house tools, commercial off-the shelf (COTS) tools, or customized version of COTS tools. With automatic code generation, it is straightforward to invoke a code analysis utility. There are documented entry points, or hooks, during the code generation and build process that allow external tools to act on the artifacts (e.g., code), while they are being produced. Recent improvements for the code generation build processes makes it easy for end users to obtain the static files, libraries, and paths that the generated code is dependent on. In one improvement example, a packngo utility provided by Real-Time Workshop Embedded Coder that contains the generated code dependency files in a single zip file that can be packaged, moved, and deployed into a separate environment for code analysis and inspection using Lint or other analysis tools.

MISRA-C Checking: As outlined above, adherence to the MISRA-C guidelines should be enforced by using appropriate tools. An example MISRA-C:2004 rule is provided here. Rule 1.4 (required): The compiler/linker shall be checked to ensure that 31 character significance and case sensitivity are supported for external identifiers. For this rule, it is possible to include a MISRA C code checker or static analysis into the code generation and build process to examine this. A setting also exists in Simulink that limits identifier lengths of generated code, end users can adjust this setting based on their needs. It is important to assess generated code since: Imported legacy code may violate a rule(s) Conscious or accidental changes to built-in code generation setting may occur For these reasons and to check the code generation output, it makes sense to add a code-based checker to your Model-Based Design environment, which can be done by using a variety of tools. One example of this, using Splint, can be found in [8]. Building integration like this is possible using open APIs and hook points within the build process described above. Another option is to use tools which have built integrations with Simulink and the code generation process. One example integration is from Polyspace [13]. Besides supporting the MISRA guidelines directly, MISRA-C checking facilitates the IEC 61508-3 requirements on language subsets and coding standards on model level (see IEC 61508-3, Table A.3, Technique/Measure 3: Language subset and Table A.4, Technique/Measure 5 Design and coding standards). More information about generating code for MISRA-C can be found in Real-Time Workshop Embedded Coder User s Guide [14]. Code Testing Capabilities Requirements-Based Testing: It is possible to have model traceability information and tags appear in the code if the model contains traceability links to high level requirements. Hyperlinks from the code, back to the model, then back to the requirement source, makes it easy to determine if the generated code implements the stated high level requirements. See Figure 9. Figure 9: Tracing requirements in code back to models Tests derived from the requirements, and applied to the model, can be reused on the code. To do this, it is possible export the test cases in the Signal Builder to the MATLAB workspace so that one can add them to a particular code test environment. Another option for test case reuse is to perform Software-in-Loop (SIL) or Processor-in-Loop (PIL) testing using built-in Simulink capabilities. One example of PIL testing is provided by Link for TASKING, see Figure 10. Figure 10 shows that a Simulink model can interact or co-simulate with automatically generated code running in an instruction set simulator (Altium TASKING). The data and execution control exchange is bidirectional and makes for a seamless integration. Developers and test engineers can, in this way, run the same test cases or plant model used on the algorithm model with the actual object code generated and compiled for a particular target. This type of Processor-in-Loop test is a non-realtime test environment. The functional code testing capabilities described above can be used to support an IEC 61508 conformant software module testing (see IEC 61508-3, Table A.5, Techniques/Measures 2: Dynamic analysis and testing and 4: Functional and black-box testing as well as detailed Tables B.2 and B.3). Code Coverage Analysis: Code structural coverage analysis can be reported in several ways. In one example, Link for TASKING can run a PIL test and return the structural code coverage analysis reported by the TASKING toolchain.

Model provides algorithm, tests, plant Code generated, in simulator Code generated, on hardware run run Figure 11: Simulink code generation report. The code generation reports facilitate code reviews and walk-throughs (see IEC 61508-3, Table B.8, Technique/Measure 2: 9 Walk-throughs/design reviews). Overall Project Documentation Reports: The Simulink Report Generator is the foundation for project reporting with Model-Based Design. It allows engineers to create custom reports overarching all activities using Model- Based Design. Reports can contain models, code, data, and analysis results. The Simulink Report Generator also integrates reports from other products and features including requirements traceability tables or generated code reports described above. Figure 10: PIL testing using Link for TASKING In another example, the test cases produced by the Signal Builder can be run on the code on a host compiler/debugger, using gcc from GNU or Visual Studio from Microsoft, and the code s structural coverage can be obtained. The structural code testing capabilities help to fulfill IEC 61508 conformant Software module testing (see IEC 61508-3, Table A.5, Technique/Measure 2: Dynamic analysis and testing and Tables B.2 Technique/Measure 6: Structure-based testing). Developers use Simulink Report Generator to produce complete project documentation. An example report s table of contents is shown in Figure 12. It lists all major activities from requirements through code generation. Important project management information such as tool version information is also included. The key part to this overall project documentation is not only that it was automatically generated, but that the results can include simulations, code generation, and analysis from batch automated scripts. This helps ensure that project documentation is kept up to date and synchronized with other Model-Based Design activities. The different types of reports can be used to document the individual development and V&V activities as well as to provide evidence for the safety case. Report Generation and Reviews Code Generation Reports: The HTML code generation report shown in Figure 9 is just one of several code report options with Simulink. A new option is to directly include code listings and other code details into the reports produced by Simulink Report Generator. An example of a sample code report integrated into Simulink Report Generator is shown in Figure 11.

An appropriate combination of different products from the Simulink product family allows addressing a broad spectrum of the IEC 61508-3 objectives related to software. Modeling and implementation language subsets and guidelines such as MISRA-C and MAAB contribute to fulfill particular IEC 61508-3 requirements. Again, powerful tool support is available with the current MATLAB release 2006b and The MathWorks Connections Program partner products. Model-Based Design allows one to bring forward many V&V activities to the model level and to perform them effectively and efficiently. Furthermore, the integrated solution for Model-Based Design from The MathWorks allows combined model and code level verification and validation activities. Please contact the authors for further discussion. REFERENCES Figure 12: Table of contents for a generated overall project report CONCLUSION Model-Based Design with code generation and automated verification and validation is an increasingly important development approach for automotive software development. Tool support and feature growth is currently very active. It is important for software development engineers to stay current on the technology and understand how it can be used within safety-related environments. This paper provides a current snapshot of these topics. Most of the relevant safety standards and guidelines date back to the era before Model-Based Design and therefore don t directly include technologies for Model- Based Design such as automatic code generation directly. These standards need to be mapped into processes and tools for Model-Based Design. Standard conformant Model-Based Design can be facilitated by using annotated IEC 61508 software integrity tables which map the techniques and measures recommended by the standard to applicable processes and tools for Model-Based Design. 1. IEC 61508-3:1998. International Standard IEC 61508 Functional safety of electrical/electronic/ programmable electronic safety-related systems Part 3: Software requirements. 1 st edition, 1998 2. ISO/WD 26262:2005. Road vehicles - Functional safety: Working Draft, 2005 3. MISRA-C:2004. The Motor Industry Software Reliability Association: Guidelines for the use of the C language in critical systems. 2004 4. HIS Working Group Software Test: Gemeinsames Subset der MISRA C Guidelines. Version 2.0, 2006 5. MathWorks Automotive Advisory Board: Controller Style Guidelines for Production Intent Development Using MATLAB, Simulink, and Stateflow. Version 1.00, 2001 6. Andreas Bärwald: IEC 61508 & MISRA C - The Benefits of Utilising IEC 61508 and MISRA C for Automotive Applications. 1 st IEE Automotive Electronics Conference, London, UK, 2005 7. Mirko Conrad, Heiko Dörr: Deployment of Modelbased Software Development in Safety-related Applications - Challenges and Solutions Scenarios. Proc. Modellierung 2006, Innsbruck, Austria, 2006, LNI Vol P-82, p. 245-254 8. Tom Erkkinen, Damon Hachmeister: Checking Code and Models in Production Environments. MATLAB Digest, July 2003 9. Matthias Findeis, Ilona Pabst: Functional Safety in the Automotive Industry, Process and methods. VDA Winter meeting 2006 10. Ekkehard Pofahl: The application of IEC 61508 in the automotive industry. 2005 11. Jim Tung: Enhanced Test and Verification Capabilities Using Model-Based Design. In: J. R. Pimentel (Ed.): Safety-Critical Automotive Systems, SAE International, 2006 (SAE paper 2006-01-1445)

12. MathWorks Connection Program, Teamcenter for System Engineering, www.mathworks.com/products/connections/product _main.html?prod_id=729 13. MathWorks Connection Program, Polyspace Desktop, www.mathworks.com/products/connections/product _main.html?prod_id=665 14. Real-Time Workshop Embedded Coder User s Guide. The MathWorks Inc, Version 4, 2006 CONTACT Tom Erkkinen, Embedded Applications Manager, The MathWorks, Inc. Tom leads a MathWorks initiative to foster industry adoption of production code generation technologies. Before joining The MathWorks, he worked at Lockheed- Martin and NASA developing a variety of control algorithms and real-time software. Tom holds a B.S. degree in Aerospace Engineering from Boston University and an M.S. degree in Mechanical Engineering from Santa Clara University. tom.erkkinen@mathworks.com University in Berlin, Germany. His publication record includes more than 60 papers on Automotive Software Engineering and Model-Based Design. mirko.conrad@mathworks.de DEFINITIONS, ACRONYMS, ABBREVIATIONS COTS commercial off-the shelf ECU Electronic Control Unit HIS Hersteller-Initiative Software (OEM Initiative Software) IEC International Electrotechnical Commission ISO International Organization for Standardization MAAB MathWorks Automotive Advisory Board MISRA The Motor Industry Software Reliability Association SIL Software-in-Loop PIL Processor-in-Loop V&V verification and validation Mirko Conrad, Team Lead Model Safety Package, The MathWorks GmbH. Mirko leads MathWork s activities to support safetyrelated automotive projects. Before joining The MathWorks, he worked at DaimlerChrysler on method and tool support for different Model-Based Design activities including code generation and testing. Mirko holds a PhD in engineering (Dr.-Ing.) and a M.Sc degree in computer science (Dipl.-Inform.) from Technical *The MathWorks, Inc. retains all copyrights in the figures and excerpts of code provided in this article. These figures and excerpts of code are used with permission from The MathWorks, Inc. All rights reserved. 1994-2007 by The MathWorks, Inc. MATLAB, Simulink, Stateflow, Handle Graphics, Real-Time Workshop, and xpc TargetBox are registered trademarks and SimBiology, SimEvents, and SimHydraulics are trademarks of The MathWorks, Inc. Other product or brand names are trademarks or registered trademarks of their respective holders.