See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/228749528

Safety-Critical Software Development Using Automatic Production Code

Generation

Article · April 2007

DOI: 10.4271/2007-01-1493

CITATIONS READS
15 935

2 authors, including:

Mirko Conrad
samoconsult GmbH
81 PUBLICATIONS   875 CITATIONS   

SEE PROFILE

All content following this page was uploaded by Mirko Conrad on 12 April 2016.

The user has requested enhancement of the downloaded file.

 2007-01-1493

Safety-Critical Software Development Using Automatic

Production Code Generation
Tom Erkkinen
The MathWorks, Inc.

Mirko Conrad
The MathWorks GmbH

Copyright © 2007 The MathWorks, Inc.

ABSTRACT Model-Based Design is becoming the preferred software

engineering paradigm for the development of embedded
When developing software it is important to consider controls in central vehicle subsystems, such as
process, methods, and tools. For safety-critical software, powertrain and chassis. The main advantages of this
standards such as IEC 61508 are often used to impose approach are that software development time is reduced
additional constraints on the development process and and product innovation is enhanced through the use of
require the production of verification evidence and other executable specifications and automatic production code
artifacts. These constraints and artifacts are needed generation. These advantages also apply for safety-
whether or not the design and code were produced critical applications.
manually or via tool automation. This paper discusses
the usage of Production Code Generation for safety- In such application contexts, safety standards such as
critical software development. IEC 61508 and commonly accepted guidelines like
MISRA-C impose additional constraints and require the
INTRODUCTION creation of additional artifacts. Furthermore, verification,
validation and testing activities have to be carried out
Model-Based Design provides executable specifications, very thoroughly. These constraints and artifacts are
automatic code generation, and automated verification needed whether or not the design and code were
and validation tools. These technologies are used to produced manually or via tool automation.
produce safety-critical software, but extra consideration
is needed to address the development constraints and However, most of the relevant standards and guidelines
artifacts imposed by industry standards and guidelines. date back to the era before Model-Based Design and
Thus, it is important to have model and code generation therefore don’t directly include technologies used in
guidelines that restrict the use of blocks and code Model-Based Design such as automatic code
generation settings if they produce designs and code not generation. Therefore, the standards need to be mapped
suitable for safety-critical systems. It is also necessary to into processes and tools for Model-Based Design.
perform rigorous model and generated code analysis
and test during the development process and to record APPLICABLE STANDARDS AND GUIDELINES
the results in the form of reports, logs, and other
certification evidence. The standards and guidelines listed below are frequently
considered relevant for the development of software-
This paper presents recent applications of Model-Based based safety-critical applications in the automotive
Design with production code generation technologies domain.
that support safety-critical software development
processes using Simulink ® and Real-Time Workshop ® IEC 61508:1998 Functional safety of
Embedded Coder from The MathWorks. These safety- electrical/electronic/ programmable electronic safety-
related technologies are described in the context of related systems
popular safety-standards and guidelines including IEC
61508 and MISRA-C. IEC 61508 is a generic, application-independent
standard for electrical / electronic / programmable
MODEL-BASED DESIGN FOR SAFETY- electronic safety-related systems (E/E/PES) that is
CRITICAL APPLICATIONS 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 recommends techniques and measures that are
domain-specific norm does not yet exist. IEC 61508-3 is supposed to be applied in the individual software
concerned with the requirements for software development phases. The recommends techniques and
development. measures are summarized by means of associated
software safety integrity tables in annexes A and B of
IEC 61508 can be considered as a prescriptive IEC 61508-3. Altogether, the software integrity tables list
standard, which provides detailed lists of techniques and more than 100 techniques / measures.
measures with recommendations.
As far as production code generation is concerned, the
ISO/WD 26262:2005 Road vehicles - Functional safety measures and techniques to be considered include for
example:
The draft for a sector-specific specialization of IEC
61508 for the automotive domain ('automotive 61508') • Language subset (see IEC 61508-3 Table A.3)
was compiled by the FAKRA working group 16 • Dynamic analysis and testing (see IEC 61508-3
Functional Safety. It was handed over as a working draft Tables A.5 and A.9)
to the ISO in November 2005 with the objective of
standardization. Among other issues, ISO/WD 26262 Within the scope of a safety-critical development project
contains parts dealing with software development it is necessary to document which measures were
(ISO/WD 26262-6) and supporting processes such as implemented and/or which replacement measures were
the qualification of development tools (ISO/WD 26262- employed. The project-specific accruing effort for this
8). can be reduced effectively if respective generic
documents (templates) for typical Model-Based Design
MISRA-C:2004 Guidelines for the use of the C language projects are made available. These templates are then
in critical systems instantiated project-specifically.

The Guidelines for the use of the C language in critical Therefore the software safety integrity tables from the
systems, compiled by MISRA, describe a subset of the standard are extended by an additional column labeled
programming language C, which is applicable for the ‘Applicable Tools / Processes for Model-Based Design’.
use in safety-critical applications. The MISRA-C The entries in the column describe how the particular
guidelines are adopted frequently in order to fulfill safety measure or technique can be supported by products or
standard’s requirements for a suitable programming solutions for Model-Based Design; see Tables 1 and 2
language on the code level. for exemplary sections of commented IEC61508-3
tables.
MAAB Controller Style Guidelines for Production Intent
Development Using MATLAB®, Simulink®, and Table 1: Example of a generic, annotated software
Stateflow® safety integrity table (see IEC 61508-3 Table A.3)

The MathWorks Automotive Advisory Board (MAAB)1

Technique / SIL1 SIL2 SIL3 SIL4 Applicable Tools / Processes for
compiled a set of modeling style guidelines [5] which can Measure Model-Based Design
be used to create Simulink and Stateflow models for …
… … … … …
automotive applications. The MAAB modeling style The MAAB Style Guides and/or
3 Language o o ++ ++
guidelines together with additional modeling language subset organization specific modeling
considerations for safety-critical applications are used to guidelines can be used to define a
subset of the modeling language.
address safety standard’s requirements for a suitable The Simulink Block Data Type
language on the modeling level. Support section of the Simulink
documentation lists the blocks, which
can be used for code generation with
Due to its draft status it is too early to discuss ISO/WD Real-Time Workshop Embedded
26262 in detail. Rather, we will focus on IEC 61508, Coder.
MISRA-C and the MAAB guidelines MISRA-C and/or organization specific
coding guidelines can be used to
define a subset of the implementation
DEMONSTRATING COMPLIANCE WITH STANDARDS language.
AND GUIDELINES Restricted language subsets can be
partially enforced by using Simulink
Model Advisor
IEC 61508:1998 Restricted modeling language
subsets can be enforced by model
A popular way to provide guidance for projects using reviews based on reports generated
by Simulink Report Generator.
Model-Based Design that must meet the IEC 61508
Restricted implementation language
objectives is to use annotated versions of the software subsets can be enforced by code
safety integrity tables given in the standard, see e.g. [7]. reviews based on Real-Time
Workshop Embedded Coder – Code
Depending on the safety integrity level, IEC 61508-3 Generation Reports.

1 Third-Party Products such as

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

on the documentation of the selected measures /

2
IEC 61508-6 Annex E gives two worked examples of techniques for a particular project.
3
the application of the software safety integrity tables and see www.automotive-his.de
procedure described in section 4.3.2 of the actual A first group of activities comprise different static
MISRA-C document [4]. analyses and checks on the model level that are
integrated into the Simulink Model Advisor. The Model
However, many people acknowledge that coding Advisor checks a model or subsystem for conditions and
standards for production code generation and hand configuration settings that can result in inaccurate or
coding differ partially. Even MISRA launched an activity slow simulation, or generation of inefficient code from
in 2005 to address the specifics of using visual modeling the model. It produces a report that lists all the
languages and automatic code generation for suboptimal conditions and settings that it finds, and
automotive systems. suggests better model configuration settings where
appropriate.
To address MISRA-C compliance, MathWorks maintains
a MISRA-C compliance analysis package for Real-Time Basic Model Checks: Model Advisor provides some
Workshop Embedded Coder since Release 12.1. This basic checks in order to ensure well-formed and efficient
package is based on model inspections, code analysis, models. These basic model checks range from support
and quality engineering product tests suites. The for updating the model to be compatible with the current
MISRA-C compliance package includes an overview Simulink version to identifying unconnected lines and
document, a compliance matrix, the presentation of ports to checking the root model interfaces. The left
violations and mitigations, Simulink and Stateflow model pane lists the checks that the Model Advisor performs.
examples as well as Real-Time Workshop Embedded The check boxes in this pane allow engineers to select a
Coder code examples. subset or all of the checks. After performing the checks,
Model Advisor displays the results of the checks in the
Simulink is a general purpose visual modeling language. right pane (Fig. 1). The basic model checks should be
It can be use to create controller as well as plant performed and reported deviations should be
models. So not all modeling features and settings considered, before other quality assurance measures,
provided, are appropriate for modeling automotive e.g., reviews, are performed.
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.

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.

Figure 1: Simulink® Model Advisor

VERIFICATION AND VALIDATION USING
MODEL-BASED DESIGN
Some of the Basic Model Checks support individual IEC
61508 techniques / measures. Checking root model
Within the scope of Model-Based Design, it is essential
inport block specifications helps for instance to make
to subject the in-vehicle software and its executable
sure that there is a fully defined interface (see
precursory stages (models) to an appropriate set of
IEC 61508-3, Table B.9, Technique/Measure 5: Fully
verification and validation (V&V) measures. Since the
defined interface). Simulink Verification and Validation
executable models can be exploited as comprehensive
extends the basic checks provided by Model Advisor as
sources of information for V&V, new possibilities for
described in what follows.
integrated quality assurance arise in the context of
Model-Based Design. Verification and Validation is
Requirements Consistency Checks: If the model is
considered an integrated quality assurance process that
linked with requirements in DOORS, Teamcenter for
is interwoven with Model-Based Design. It includes a
Systems Engineering, Word or Excel, inconsistent,
combination of complementary activities on model as
missing, or changed requirements can be found.
well as on code level, see e.g. [11].
Technically speaking, the Model Advisor Requirements
Consistency Checks can identify and repair
MODEL-LEVEL V&V ACTIVITIES
requirements with missing documents and inconsistent
requirements descriptions (Fig. 2).
Model Analyses and Checks
 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.

Model complexity measurement helps to achieve a

modular approach on model level and especially to
Figure 2: Model Advisor requirements consistency checks
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:
These requirements consistency checks can be used to
Software module size limit respectively. Reducing
support an IEC 61508 conformant Software safety
complexity is often a key method for achieving structural
requirements specification (see IEC 61508-3, Table A.1,
coverage analysis goals.
Technique/Measure 1: Computer-aided specification
tools).
Testing Capabilities of Model-Based Design
Modeling Standards Checks (R2006b): The new
Modeling Standards Checker includes checks for many Within the scope of Model-Based Design, executable
MAAB Style Guidelines Rules. These built-in checks models can be tested and the test information can be
include (Fig 3) for example: 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
• Prohibited Simulink standard blocks inside
essential to subject the software and its preliminary
controllers (see MAAB guideline jm_0001)
stages (models) to an appropriate combination of testing
• Port names in Simulink and Stateflow (see MAAB techniques. Such test strategies may include
guidelines jm_0010 and db_0123) combinations of functional and structural testing
• Unconnected signals (see MAAB guideline techniques. The systematic selection of test scenarios
db_0081) 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-to-
back) 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
Figure 3: Modeling Standards Checker – MAAB Guidelines Checks end-users link textual requirements to model elements,
test scenarios, and verification blocks (Fig. 4).
Furthermore, a Model Advisor API is available which
facilitates the development of custom rule checks by
developers based on a flexible MATLAB rule syntax.
 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 Modified condition/decision coverage (MC/DC)
examines blocks that output the logical combination of
The requirements linkage is bidirectional and supports their inputs (e.g., the Logic block) and Stateflow
links to high level requirement in Telelogic DOORS, transitions to determine the extent to which the test case
Microsoft Word or Excel, or HTML. A published API tests the independence of logical block inputs and
allows project teams or third parties to produce other transition conditions. A test case achieves full coverage
integrations. For example, UGS used this API to develop for a block if, for every input, there is a pair of simulation
an integration between Simulink and Teamcenter for times when changing that input alone causes a change
Systems Engineering [12]. in the block's output. A test case achieves full coverage
for a transition if, for each condition on the transition,
SystemTest provides a flexible software framework for there is at least one time when a change in the condition
developing tests that exercise Simulink or Stateflow triggers the transition. MC/DC is considered to be the
models. It can be used to perform parameter sweeps as most stringent coverage level necessary to satisfy
well as to run different sets of test data that can – for safety-critical systems.
example - be specified using the Signal Builder. A Test
Results Viewer helps to interactively access and analyze Lookup table (LUT) coverage examines blocks, such as
test result data. the 1D Look-Up block, that output the result of looking
up one or more inputs in a table of inputs and outputs,
The functional testing capabilities of the Simulink interpolating between or extrapolating from table entries
product family described above can be used to support as necessary. Lookup table coverage records the
an IEC 61508 conformant Software module testing (see frequency that table lookups use each interpolation
IEC 61508-3, Table A.5, Techniques/Measures 2: interval. A test case achieves full coverage if it executes
Dynamic analysis and testing and 4: Functional and each interpolation and extrapolation interval at least
black-box testing as well as detailed Tables B.2 and once. For each LUT block in the model, the coverage
B.3). report displays a colored map of the lookup table
indicating where each interpolation was performed.
Model Coverage Analysis: Coverage analyses are well
established in imperative programming languages such Signal Range Coverage returns the maximum and
as C, and Ada, but these types of analysis were not minimum signal values at each block in the model
made available at the model level until recently. Simulink measured during simulation.
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).

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.

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
Figure 5: Model Coverage Analysis – Example coverage report
model documentation files to be generated in a dynamic
HTML format, based on scaled vector graphics
The model coverage analysis described in Figure 5 can implementation, such that model reviewers can navigate
be extended to include cumulative coverage as shown and step through model hierarchies from a standard
below (Fig 6). 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 Requirements Traceability Reports: Blocks and
subsystems with requirements traced to external tools or
An important aspect of performing structural model documents can be highlighted in the diagram. This
testing is the definition of appropriate test patterns that makes it easy to ensure all blocks have corresponding
exercise all aspects of the model and, equivalently, of higher level requirements as well as to identify blocks
the code that is generated from the model. Many of with missing requirements.
these test patterns are identified interactively during the
model development and from requirements. A report can be generated from the Model Explorer that
Supplementing test patterns, particularly for coverage shows the requirements traceability for the model,
objectives that haven’t been covered otherwise, can be subsystem, and individual blocks as shown in Figure 7.
generated automatically by third party tools.

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 Figure 8: Exported Model Advisor report

Model Analysis Reports: Another useful report comes Furthermore, the different types of reports can be used
from the Model Advisor. This tool examines your model to document the individual development and V&V
based on default or customized checks (see section on activities as well as to contribute evidence for the safety
‘Model Analyses and Checks’) and produces an output case.
that is displayed within the Simulink environment.
However, it is also possible to export this output as an CODE-LEVEL V&V ACTIVITIES
HTML report that can be viewed outside of Simulink,
either standalone or incorporated within a Code Analysis and Checks
documentation system.
It is useful to employ analysis tools for examining C code
The MATLAB command sequence to export the Model deployed on production ECUs. Over the years,
Advisor report to a file name ecu_prj.htm based on your automotive organizations have incorporated a wide
current model is as follows. range of code analysis tools into their verification and
validation process including in-house tools, commercial
>>Obj = Simulink.ModelAdvisor.getModelAdvisor(gcs) off-the shelf (COTS) tools, or customized version of
>>Obj.exportReport('ecu_prj.htm') COTS tools.

An example standalone Model Advisor report viewed With automatic code generation, it is straightforward to
from a desktop browser is in Figure 8. invoke a code analysis utility. There are documented
entry points, or “hooks”, during the code generation and
Model Documentation Reports: The Simulink Report build process that allow external tools to act on the
Generator allows engineers to create custom reports artifacts (e.g., code), while they are being produced.
containing models, data, and analysis results. It also
integrates reports from other products and features Recent improvements for the code generation build
including requirements traceability tables. processes makes it easy for end users to obtain the
static files, libraries, and paths that the generated code
The model documentation reports facilitate reviews and is dependent on. In one improvement example, a
walk-throughs on model level (see IEC 61508-3, Table packNGo utility provided by Real-Time Workshop
B.8, Technique/Measure 2: 9 Walk-throughs/design Embedded Coder that contains the generated code
reviews). 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) Figure 9: Tracing requirements in code back to models
• Conscious or accidental changes to built-in code
generation setting may occur Tests derived from the requirements, and applied to the
model, can be reused on the code. To do this, it is
For these reasons and to check the code generation possible export the test cases in the Signal Builder to the
output, it makes sense to add a code-based checker to MATLAB workspace so that one can add them to a
your Model-Based Design environment, which can be particular code test environment.
done by using a variety of tools. One example of this,
using Splint, can be found in [8]. Building integration like Another option for test case reuse is to perform
this is possible using open APIs and hook points within Software-in-Loop (SIL) or Processor-in-Loop (PIL)
the build process described above. testing using built-in Simulink capabilities. One example
of PIL testing is provided by Link for TASKING®, see
Another option is to use tools which have built Figure 10.
integrations with Simulink and the code generation
process. One example integration is from Polyspace Figure 10 shows that a Simulink model can interact or
[13]. co-simulate with automatically generated code running
in an instruction set simulator (Altium TASKING). The
Besides supporting the MISRA guidelines directly, data and execution control exchange is bidirectional and
MISRA-C checking facilitates the IEC 61508-3 makes for a seamless integration. Developers and test
requirements on language subsets and coding engineers can, in this way, run the same test cases or
standards on model level (see IEC 61508-3, Table A.3, plant model used on the algorithm model with the actual
Technique/Measure 3: Language subset and Table A.4, object code generated and compiled for a particular
Technique/Measure 5 Design and coding standards). target. This type of Processor-in-Loop test is a non-real-
time test environment.
More information about generating code for MISRA-C
can be found in Real-Time Workshop Embedded Coder The functional code testing capabilities described above
User’s Guide [14]. can be used to support an IEC 61508 conformant
software module testing (see IEC 61508-3, Table A.5,
Code Testing Capabilities Techniques/Measures 2: Dynamic analysis and testing
and 4: Functional and black-box testing as well as
Requirements-Based Testing: It is possible to have detailed Tables B.2 and B.3).
model traceability information and tags appear in the
code if the model contains traceability links to high level Code Coverage Analysis: Code structural coverage
requirements. Hyperlinks from the code, back to the analysis can be reported in several ways. In one
model, then back to the requirement source, makes it example, Link for TASKING can run a PIL test and
easy to determine if the generated code implements the return the structural code coverage analysis reported by
stated high level requirements. See Figure 9. the TASKING toolchain.
 Model provides algorithm, tests, plant

Code generated, run

in simulator
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-
Code generated, run
Based Design. Reports can contain models, code, data,
on hardware 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.

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
Figure 10: PIL testing using Link for TASKING automatically generated, but that the results can include
simulations, code generation, and analysis from batch
In another example, the test cases produced by the automated scripts. This helps ensure that project
Signal Builder can be run on the code on a host documentation is kept up to date and synchronized with
compiler/debugger, using gcc from GNU or Visual Studio other Model-Based Design activities.
from Microsoft, and the code’s structural coverage can
be obtained. The different types of reports can be used to document
the individual development and V&V activities as well as
The structural code testing capabilities help to fulfill to provide evidence for the safety case.
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).

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

1. IEC 61508-3:1998. International Standard IEC

61508 Functional safety of electrical/electronic/
programmable electronic safety-related systems –
Part 3: Software requirements. 1st 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
Figure 12: Table of contents for a generated overall project report 5. MathWorks Automotive Advisory Board: Controller
Style Guidelines for Production Intent Development
CONCLUSION Using MATLAB, Simulink, and Stateflow. Version
1.00, 2001
Model-Based Design with code generation and 6. Andreas Bärwald: IEC 61508 & MISRA C - The
automated verification and validation is an increasingly Benefits of Utilising IEC 61508 and MISRA C for
important development approach for automotive Automotive Applications. 1st IEE Automotive
software development. Tool support and feature growth Electronics Conference, London, UK, 2005
is currently very active. It is important for software
7. Mirko Conrad, Heiko Dörr: Deployment of Model-
development engineers to stay current on the
based Software Development in Safety-related
technology and understand how it can be used within
Applications - Challenges and Solutions Scenarios.
safety-related environments. This paper provides a
current snapshot of these topics. Proc. Modellierung 2006, Innsbruck, Austria, 2006,
LNI Vol P-82, p. 245-254
Most of the relevant safety standards and guidelines 8. Tom Erkkinen, Damon Hachmeister: Checking Code
date back to the era before Model-Based Design and and Models in Production Environments. MATLAB
therefore don’t directly include technologies for Model- Digest, July 2003
Based Design such as automatic code generation 9. Matthias Findeis, Ilona Pabst: Functional Safety in
directly. These standards need to be mapped into the Automotive Industry, Process and methods. VDA
processes and tools for Model-Based Design. Winter meeting 2006
10. Ekkehard Pofahl: The application of IEC 61508 in
Standard conformant Model-Based Design can be the automotive industry. 2005
facilitated by using annotated IEC 61508 software 11. Jim Tung: Enhanced Test and Verification
integrity tables which map the techniques and measures Capabilities Using Model-Based Design. In: J. R.
recommended by the standard to applicable processes Pimentel (Ed.): Safety-Critical Automotive Systems,
and tools for Model-Based Design. SAE International, 2006 (SAE paper 2006-01-1445)
12. MathWorks Connection Program, Teamcenter for University in Berlin, Germany. His publication record
System Engineering, includes more than 60 papers on Automotive Software
www.mathworks.com/products/connections/product Engineering and Model-Based Design.
_main.html?prod_id=729
13. MathWorks Connection Program, Polyspace [email protected]
Desktop,
www.mathworks.com/products/connections/product
_main.html?prod_id=665 DEFINITIONS, ACRONYMS, ABBREVIATIONS
14. Real-Time Workshop® Embedded Coder User’s
Guide. The MathWorks Inc, Version 4, 2006 COTS … commercial off-the shelf
ECU … Electronic Control Unit
CONTACT
HIS … Hersteller-Initiative Software (OEM
Tom Erkkinen, Embedded Applications Manager, The Initiative Software)
MathWorks, Inc. IEC … International Electrotechnical Commission
Tom leads a MathWorks initiative to foster industry
adoption of production code generation technologies. ISO … International Organization for Standardization
Before joining The MathWorks, he worked at Lockheed- MAAB … MathWorks Automotive Advisory Board
Martin and NASA developing a variety of control
algorithms and real-time software. Tom holds a B.S. MISRA … The Motor Industry Software Reliability
degree in Aerospace Engineering from Boston Association
University and an M.S. degree in Mechanical SIL … Software-in-Loop
Engineering from Santa Clara University.
PIL … Processor-in-Loop
[email protected] V&V … verification and validation

Mirko Conrad, Team Lead Model Safety Package, The *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
MathWorks GmbH. permission from The MathWorks, Inc. All rights reserved.
Mirko leads MathWork’s activities to support safety-
related automotive projects. Before joining The ©1994-2007 by The MathWorks, Inc.
MathWorks, he worked at DaimlerChrysler on method MATLAB, Simulink, Stateflow, Handle Graphics, Real-Time Workshop, and
and tool support for different Model-Based Design xPC TargetBox are registered trademarks and SimBiology, SimEvents, and
activities including code generation and testing. Mirko SimHydraulics are trademarks of The MathWorks, Inc. Other product or brand
holds a PhD in engineering (Dr.-Ing.) and a M.Sc degree names are trademarks or registered trademarks of their respective holders.
in computer science (Dipl.-Inform.) from Technical

View publication stats