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.


Safety-Critical Software Development Using Automatic
Production Code Generation
Copyright © 2007 The MathWorks, Inc.
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 safety-
critical 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 safety-
related 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
2007-01-1493
Tom Erkkinen
The MathWorks, Inc.
Mirko Conrad
The MathWorks GmbH
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 safety-
critical 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 software-
based safety-critical applications in the automotive
domain.
IEC 61508:1998 Functional safety of
electrical/electronic/ programmable electronic safety-
related 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 Third-Party Products such as
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 / SIL1 SIL2 SIL3 SIL4 Applicable Tools / Processes for
Measure Model-Based Design
…
… … … … …
The MAAB Style Guides and/or
3 Language o o ++ ++
subset 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.
 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.
… … … … … …
Table 2: Example of a generic, annotated software
safety integrity table (see IEC 61508-3 Table A.5)
Technique / SIL1 SIL2 SIL3 SIL4 Applicable Tools / Processes for
Measure Model-Based Design
… … … … … …
2 Dynamic + ++ ++ ++ The simulation capabilities of
analysis and Simulink and Stateflow® can be used
testing 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 re-
integrated into the Simulink model
can be used to perform dynamic
testing on SIL level.
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.
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 removed2.
2
IEC 61508-6 Annex E gives two worked examples of
the application of the software safety integrity tables and
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
Technique / SIL3 Interpretation in this application
Measure
… … …
3 Language ++ Used:
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
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 (HIS3)
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.

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

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.
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
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-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
end-users link textual requirements to model elements,
test scenarios, and verification blocks (Fig. 4).

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).
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
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.
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.

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).
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.
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
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
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.
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.
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 Code Analysis and Checks
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
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-real-
time 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, run
in simulator
Code generated, run
on hardware
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).
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.
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.
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.

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.
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
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. 1st IEE Automotive
Electronics Conference, London, UK, 2005
7. Mirko Conrad, Heiko Dörr: Deployment of Model-
based 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
Mirko Conrad, Team Lead Model Safety Package, The
MathWorks GmbH.
Mirko leads MathWork’s activities to support safety-
related 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
View publication stats
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
*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.