Certkitiec MBD Iso26262

IEC Certification Kit
Model-Based Design for ISO 26262

R2015b
How to Contact MathWorks

Latest news:
www.mathworks.com
Sales and services:
www.mathworks.com/sales_and_services
User community:
www.mathworks.com/matlabcentral
Technical support:
www.mathworks.com/support/contact_us
Phone:
508-647-7000
The MathWorks, Inc.

3 Apple Hill Drive
Natick, MA 01760-2098
IEC Certification Kit: Model-Based Design for ISO 26262
COPYRIGHT 20122015 by The MathWorks, Inc.

The software described in this document is furnished under a license agreement. The software may be used or copied only under
the terms of the license agreement. No part of this manual may be photocopied or reproduced in any form without prior written
consent from The MathWorks, Inc.
FEDERAL ACQUISITION: This provision applies to all acquisitions of the Program and Documentation by, for, or through the
federal government of the United States. By accepting delivery of the Program or Documentation, the government hereby agrees
that this software or documentation qualifies as commercial computer software or commercial computer software documentation
as such terms are used or defined in FAR 12.212, DFARS Part 227.72, and DFARS 252.227-7014. Accordingly, the terms and
conditions of this Agreement and only those rights specified in this Agreement, shall pertain to and govern the use, modification,
reproduction, release, performance, display, and disclosure of the Program and Documentation by the federal government (or
other entity acquiring for or through the federal government)and shall supersede any conflicting contractual terms or conditions.
If this License fails to meet the governments needs or is inconsistent in any respect with federal procurement law, the
government agrees to return the Program and Documentation, unused, to The MathWorks, Inc.
Trademarks
MATLAB and Simulink are registered trademarks of The MathWorks, Inc. See www.mathworks.com/trademarks for a
list of additional trademarks. Other product or brand names may be trademarks or registered trademarks of their respective
holders.
Patents
MathWorks products are protected by one or more U.S. patents. Please see www.mathworks.com/patents for more
information.
Revision History
March 2012
September 2012
March 2013
September 2013
March 2014
October 2014
March 2015
September 2015
New for Version 2.1 (Applies to Release 2012a)

Revised for Version 3.0 (Applies to Release 2012b)
Revised for Version 3.1 (Applies to Release 2013a)
Revised for IEC Certification Kit Version 3.6 (Applies to Release 2015b)
Contents
1 Model-Based Design for ISO 26262 ................................................................................................ 1-1
2 ISO 262626: Applicable Model-Based Design Tools and Processes ............................................. 2-1
2.1 Initiation of Product Development at the Software Level ....................................................... 2-2
Table 1 Topics To Be Covered By Modeling and Coding Guidelines ................................. 2-2
2.2 Software Architectural Design ................................................................................................ 2-3
Table 2 Notations for Software Architectural Design .......................................................... 2-3
Table 3 Principles for Software Architectural Design .......................................................... 2-3
Table 4 Mechanisms for Error Detection at the Software Architectural Level .................... 2-5
Table 5 Mechanisms for Error Handling at the Software Architectural Level ..................... 2-5
Table 6 Methods for Verification of Software Architectural Design ................................... 2-6
2.3 Software Unit Design and Implementation ............................................................................. 2-8
Table 7 Notations for Software Unit Design ........................................................................ 2-8
Table 8 Design Principles for Software Unit Design and Implementation........................... 2-9
Table 9 Methods for Verification of Software Unit Design and Implementation .............. 2-12
2.4 Software Unit Testing ........................................................................................................... 2-15
Table 10 Methods for Software Unit Testing ..................................................................... 2-15
Table 11 Methods for Deriving Test Cases for Software Unit Testing .............................. 2-17
Table 12 Structural Coverage Metrics at the Software Unit Level..................................... 2-17
2.5 Software Integration and Testing .......................................................................................... 2-19
Table 13 Methods for Software Integration Testing........................................................... 2-19
Table 14 Methods for Deriving Test Cases for Software Integration Testing .................... 2-21
Table 15 Structural Coverage Metrics at the Software Architectural Level ....................... 2-21
3 ISO 262628: Applicable Model-Based Design Tools and Processes ............................................. 3-1
3.1 Confidence in the Use of Software Tools ................................................................................ 3-2
Table 4 Qualification of Software Tools Classified TCL3 ................................................... 3-2
Table 5 Qualification of Software Tools Classified TCL2 ................................................... 3-3
vi
1 Model-Based Design for ISO

26262
This documentation provides annotated versions of method tables that appear in the ISO 26262
6 and ISO 262628 standards. The annotated tables provide suggestions on how to use ModelBased Design products from MathWorks to apply the methods listed in the standard for
different Automotive Safety Integrity Levels (ASILs).
The IEC Certification Kit provides additional support when using Model-Based Design for ISO
26262 applications, including reference workflows for verifying and validating models and
generated code.
1-2
2 ISO 262626:
Applicable Model-Based Design
Tools and Processes
2.1 Initiation of Product Development at the Software

Level
Table 1 Topics To Be Covered By Modeling and Coding Guidelines
Topics
1a
1b
1c
1d
1e
1f
1g
1h
Enforcement of low
complexity
Use of language subsets
Enforcement of strong
typing
Use of defensive
implementation
techniques
Use of established design
principles
Use of unambiguous
graphical representation
Use of style guides
Use of naming
conventions
ASIL
A
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
+
++
++
++
++
++
++
++
Applicable Model-Based
Design Tools and
Processes
Comments
Simulink Modeling
Guidelines
Polyspace Bug Finder,
Polyspace Code Prover
Coding Rules Checks
The High Integrity System Modeling

Guidelines and the MathWorks
Automotive Advisory Board
Control Algorithm Modeling
Guidelines as well as applicable
coding standards (MISRA C:2004,
MISRA C:2012, MISRA C++, or
JSF++) can be used to address topics
listed in this table. The guideline
subset used for a project should
address a combination of topics
applicable for the ASIL under
consideration.
2-2
2.2 Software Architectural Design

Table 2 Notations for Software Architectural Design
Methods
1a
Informal notations
ASIL
A
++
++
Design Tools and
Processes
Comments
Simulink Model Info and

DocBlock blocks
The blocks can be used to integrate

architectural descriptions into a model.
Simulink Verification and

Validation System
Requirements block
Validation Requirements
Management Interface (RMI)
1b
Semiformal notations
++
++
++
1c
Formal notations
Simulink
Stateflow
The RMI can be used to link Simulink and

Stateflow architectural designs to informal
descriptions in Microsoft Word,
Microsoft Excel, ASCII text, and PDF
files.
Simulink and Stateflow support software
architectural design using semiformal
notations.
Table 3 Principles for Software Architectural Design

Methods
1a
Hierarchical structure
of software
components
ASIL
A
++
++
++
++
Design Tools and
Processes
Comments
Simulink Model block, Ports

& Subsystems block library
Model blocks (model referencing),

subsystems, libraries, and Stateflow charts
support hierarchical decomposition of
models.
When using Model blocks or libraries to
structure a model, the Model Dependency
Viewer can display a graph of models and
libraries referenced by the top model.
Embedded Coder supports modularization
of code at the file level.
Stateflow
Simulink Model Dependency
Viewer
Embedded Coder
2-3
Methods
1b
Restricted size of
software components
ASIL
A
Design Tools and
Processes
++
++
++
++
Simulink
Comments
Software components can be structured

hierarchically to limit component size.
Stateflow
Embedded Coder
Validation ISO 26262 checks
Polyspace Bug Finder

Code metrics
1c
Restricted size of
interfaces

Validation ISO 26262 checks
Polyspace Bug Finder Code

metrics
1d
1e
1f
High cohesion with

software components
Restricted coupling
between software
components
Appropriate
scheduling properties
++
++
++
++
++
++

Code Metric
++
++
++
++
Simulink
Stateflow Scheduler patterns
1g
Restricted use of
interrupts
++
Embedded Coder
Configuration
ISO 26262 Model Advisor check Display

model metrics and complexity report
provides information on the size and
complexity of models and subsystems.
Polyspace Bug Finder Code metrics
supports the generation of size and
complexity metrics for source code.
ISO 26262 Model Advisor check Display
model metrics and complexity report
provides information on the number of
inports and outports of models and
subsystems.
supports the generation of size and
complexity metrics for source code.

supports the generation of Estimated
function coupling metric for source code.
Simulink provides a way to control the rate
of block execution and allows specification
of block-based or port based sample times.
Models can display color coding and
annotations to represent specific sample
times.
Stateflow provides multiple scheduler
patterns for controlling execution of
subsystems.
Embedded Coder can be configured to not
insert interrupts into step function code.
2-4
Table 4 Mechanisms for Error Detection at the Software Architectural Level

Methods
1a
Range checks of input

and output data
ASIL
A
Design Tools and
Processes
++
++
++
++
Simulink
Stateflow
Simulink Design Verifier
1b
Plausibility
++

Code verification
Simulink
1c
Detection of data
errors
Stateflow
Simulink
1d
External monitoring
facility
Control flow
monitoring
Diverse software
design
++
++
++
++
Comments
Simulink and Stateflow can be used to

design range checks for input and output
data..
Simulink Design Verifier and Polyspace
Code Prover can calculate and verify signal
ranges.
design plausibility checks.
detect data errors.
Stateflow
1e
1f
Simulink
Stateflow
Software diversity for algorithmic parts can

be supported by executing floating-point
and fixed-point versions of an algorithm in
parallel and comparing the results.
Fixed-Point Designer
Table 5 Mechanisms for Error Handling at the Software Architectural Level

Methods
ASIL
A
Design Tools and
Processes
1a
Static recovery
mechanism
Simulink
1b
Graceful degradation
++
++
Stateflow
Stateflow
1c
Independent parallel
redundancy
Correcting codes for
data
++
1d
Comments

design fault detection, isolation, and
recovery (FDIR) algorithms.
Stateflow can be used to design graceful
degradation behaviour.
2-5
Table 6 Methods for Verification of Software Architectural Design

Methods
1a
1b
Walkthrough of the
design
Inspection of the
design
ASIL
A
Design Tools and
Processes
++
Simulink
++
Simulink Report Generator

Web View, System Design
Description (SDD) report
Simulink
++
++

Validation Model Advisor
checks
1c
Simulation of dynamic
parts of the design
++
Simulink
Stateflow
Simulink Test
1d
Prototype generation
++
Simulink Coder
Embedded Coder
Simulink 3D Animation
Gauges Blockset
Comments
Architectural design walkthroughs can be

based on the model, a generated Web
View, or an SDD report.
Design inspections can be based on the

model, a generated Web View, or an SDD
report.
Design inspections can be supported by
ISO 26262, MAAB, Requirements
Consistency, and custom Model Advisor
checks. A Model Advisor check
configuration can define a set of checks
required to pass as a prerequisite for
entering a design inspection.
Simulink and Stateflow support simulation
of algorithm and environment models.
During simulation, the Simulation range
checking diagnostic detects when signals
exceed specified ranges.
Simulink Test can be used to create test
cases to verify dynamic parts of the design,
including mechanisms for error detection
and handling at the architecture level as
well as generate reports of results.
Simulink Coder can be used to generate
code for rapid prototyping.
Embedded Coder can be used to generate
code for on-target rapid prototyping.
Software-in-the-loop (SIL) and processorin-the-loop (PIL) simulation can be used to
execute generated code in the context of a
model.
Simulink 3D Animation can be used to
animate 3-dimensional scenes driven by
signals in a model.
Gauges Blockset can be used to add
graphical instrumentation to models.
2-6
Methods
1e
Formal verification
ASIL
A
Design Tools and
Processes
Comments
Simulink Model Verification

block library
Model Verification blocks can be used to

formalize software safety requirements and
other model properties.
Property proving can be used to verify
model properties. Design error detection
can analyze a model to detect design errors
that might occur at run time.
Polyspace Code Prover can analyze C
code to identify software errors that might
occur during run time.
Model coverage analysis can help identify
unreachable portions of a model.
Simulink Design Verifier

Property proving, design error
detection
Polyspace Code Prover Code
verification
1f
Control flow analysis
++
++

Validation Model coverage
analysis
Simulink Design Verifier Test
case generation
Polyspace Code Prover Call
tree computation, Unreachable
code analysis
1g
Data flow analysis
++
++
Simulink Diagnostics
Stateflow Diagnostics
Global variable usage analysis,
Code verification
Automatic test case generation can be used

to detect unreachable model constructs,
which could result in unreachable code.
Polyspace Code Prover can extract control
flow information at the function level from
C code and create an application call tree.
Gray checks detect unreachable code.
Data Store Memory block diagnostics and
Stateflow diagnostics can be configured to
identify data flow issues.
Polyspace Code Prover supports static
verification of dynamic properties of
generated code. This verification technique
is based on data flow analysis.
The variable access pane displays the
following information about each global
variable: number of read and write access
operations, location of read and write
operations, detailed type value ranges for
individual read and write access operations,
whether or not it shared, whether shared
access is protected (critical section).
2-7
2.3 Software Unit Design and Implementation

Table 7 Notations for Software Unit Design
Methods
1a
1b
Natural language
Informal notations
ASIL
A
++
++
++
++
++
++
Design Tools and
Processes
Comments
Simulink Model Info block,

DocBlock block
The blocks can be used to add natural

language or descriptions of a unit design to
a model.

Validation System
Requirements block
Simulink Model Info block,
DocBlock block
Validation System
Requirements block
1c
Semiformal notations
++
++
++
1d
Formal notations
Simulink
Models representing unit designs can be

linked to descriptions in Microsoft Word,
Microsoft Excel, ASCII text, or PDF files.
The blocks can be used to add informal
descriptions of a unit design to a model.
The RMI can be used to link models

representing unit designs to external
informal descriptions in Microsoft Word,
Microsoft Excel, ASCII text, or PDF files.
Simulink and Stateflow support software
unit design, using semiformal notations.
Stateflow
2-8
Table 8 Design Principles for Software Unit Design and Implementation

Methods
1a
One entry and one exit

point in subprograms and
functions
ASIL
A
++
++
++
++
Design Tools and
Processes
Comments
Simulink Modeling
guidelines
Adherence can be facilitated by applying

modeling guidelines in combination with
analyzing generated code. MAAB
guideline jc_0511 provides corresponding
modeling recommendations.
Polyspace Bug Finder can assess
compliance with MISRA C rules for
subprograms and functions and supports
the generation of Return points metric for
source code (one entry and one exit point in
subprograms and functions).
Embedded Coder can be configured to
generate C code that does not include
dynamic objects.
compliance with MISRA C rules for
dynamic objects.
An IC block can specify the initial
condition for a signal.

MISRA C checker
Code Metric
1b
No dynamic objects or
variables, or else online
test during their creation
++
++
++
Embedded Coder
Configuration
MISRA C checker
1c
Initialization of variables
++
++
++
++
Simulink IC block,
diagnostics
Embedded Coder
Configuration
Polyspace Code Prover,

Code verification
Setting the Underspecified initialization

detection diagnostic to
Simplified improves consistency of
simulation results for models that do not
specify initial conditions for conditional
subsystem output ports or have
conditionally executed subsystem output
ports connected to S-functions.
Parameters in the Optimization > Data
initialization section of the Configuration
Parameters dialog box can be used to
control initialization of variables in
generated code.
Polyspace Code Prover and Polyspace Bug
Finder can check the initialization of
variables and pointers in generated code.
Uninitialized variables are reported as NIV,
NON_INIT_VAR and NON_INIT_PTR
checks.
2-9
Methods
1d
No multiple use of
variable names
ASIL
A
Design Tools and
Processes
++
++
++

Code verification
1e
Avoid global variables or

else justify their usage
++
++
Simulink
Embedded Coder
Configuration
Global variable usage
analysis
MISRA C checker
1f
Limited use of pointers
++
Embedded Coder
Configuration

MISRA C checker
Code verification
Comments
Setting the Duplicate data store names

diagnostic to error detects
conditions where a lower-level data store
unexpectedly shadows a higher-level data
store with the same name.
Polyspace Bug Finder can check multiple
use of variable names ("Variable
Shadowing" check).
Usage of Data Store Memory blocks needs
to be reviewed and justified.
Selecting the Enable local block outputs
optimization reduces use of
global variables in generated code.
access is protected (critical section). This
information is also accessible in the
generated reports.
Polyspace Code Prover and Polyspace Bug
Finder can assess compliance with MISRA
C rules for global variables.
Embedded Coder may generate pointer
arithmetic for certain language features
for example, lookup tables or matrix
multiplication. Embedded Coder checks
the data type and range of values to avoid
corruption of address spaces.
compliance with MISRA C rules for the
use of pointers.
Polyspace Code Prover can check whether
pointers refer to valid objects. Violations
are reported as IDP checks.
2-10
Methods
ASIL
A
Design Tools and
Processes
Comments
MISRA C contains rules that facilitate the

use of established design principles.
compliance with MISRA C rules for data
type conversions.
Polyspace Code Prover can detect if
implicit data type conversions will or will
not cause an overflow, reducing the effort
to justify MISRA violations.
compliance with MISRA rules for data and
control flow.
1g
No implicit data type

conversions
++
++
++

MISRA C checker
Code verification
1h
No hidden data flow or

control flow
++
++
++

MISRA C checker
2-11
Methods
ASIL
A
Design Tools and
Processes
Comments

compliance with
MISRA C rules for unconditional jumps.
Adherence can be facilitated by applying
modeling guidelines.
High-integrity guideline hisf_0004
provides corresponding modeling
recommendations. Avoid using n-D
Lookup Table and Interpolation blocks and
Prelookup blocks with dimensions > 5.
Polyspace Bug Finder supports the
generation of recursions and direct
recursions metrics for source code.
Call trees generated using Polyspace Code
Prover can be reviewed to identify
recursive function calls.
1i
No unconditional
jumps
++
++
++
++

MISRA C checker
1j
No recursions
++
++
Simulink Modeling
guidelines

Metric
tree computation
Table 9 Methods for Verification of Software Unit Design and Implementation

Methods
1a
Walkthrough
ASIL
A
Design Tools and
Processes
++
Simulink
Embedded Coder Code
generation report
1b
Inspection
++
++
++
Simulink
Comments
Unit design walkthroughs can be based on

a model, a generated Web View, or an
SDD report.
Code walkthroughs can be based on HTML

code generation reports or code
Generation reports with an integrated Web
View of the model.
Unit design inspections can be based on a
model, a generated Web View, or an SDD
report.
2-12
Methods
ASIL
A
Design Tools and
Processes
Comments

Validation Model Advisor
checks
Unit design inspections can be supported

by ISO 26262, MAAB, Requirements
Consistency, and custom checks in Model
Advisor. A Model Advisor check
configuration can define a set of checks to
pass as a prerequisite for entering model
inspection.
Code walkthroughs can be based on HTML
code generation reports, code
Generation reports with an integrated Web
View of the model, or model-to-code and
code-to-model traceability matrices.
Simulink supports simulation of algorithm
and environment models to verify software
unit design and implementation.
Embedded Coder Code

generation report
1c
Semiformal
verification
++
++

Traceability matrix
Simulink
Simulink Test
1d
Formal verification
Simulink Model Verification

blocks
Simulink Design
Verifier Property proving,
design error detection, test
case generation
verification
1e
Control flow analysis
++
++

analysis
case generation
tree computation, Unreachable
code analysis
Simulink Test can be used to develop test

cases and procedures for simulating and
evaluating models and algorithms, and
reporting simulation results.
Model Verification blocks can be used to
formalize software safety requirements and
other model properties.
Property proving can be used to verify
model properties using formal verification
techniques. Design error detection can
analyze a model to detect design errors that
might occur at run time.
Runtime error detection can analyze C code
to identify software errors that might occur
during run time.
Model coverage analysis can help to
identify unreachable portions of a model.
Automatic test case generation can be used
to detect unreachable model constructs that
could result in unreachable code.
Polyspace Code Prover can extract control
flow information at the function level from
C code and create an application call tree.
Gray checks detect unreachable code.
2-13
Methods
1f
Data flow analysis
ASIL
A
Design Tools and
Processes
++
++
Stateflow Diagnostics
verification
1g
1h
Static code analysis
Semantic code
analysis
++
++
++
Polyspace Bug Finder MISRA

C checker

metrics
verification, Global variable
usage analysis
Comments
Data Store Memory block diagnostics and

Stateflow diagnostics can be configured to
identify data flow issues.
Polyspace Code Prover supports static
verification of dynamic properties of
generated code. This verification technique
is based on data flow analysis.
Polyspace Bug Finder can facilitate static
analysis of C code.
Polyspace Code Prover uses abstract

interpretation to analyze C code.
access is protected (critical section).
Clause
8.4.5
b)
The software unit design and

implementation shall be verified in
accordance with ISO 262628:2011
Clause 9, and by applying the
verification methods listed in Table 9
to demonstrate:
...
the fulfillment of the software safety
requirements as allocated to the
software units (in accordance with
7.4.9) through traceability
...
Model-Based Design Tools and

Processes
Comments
IEC Certification Kit Traceability

matrix
Generated traceability matrices can be

used to document and review existing
links between textual requirements,
models, and generated code.
2-14
2.4 Software Unit Testing

Table 10 Methods for Software Unit Testing
Methods
1a
Requirements-based
test
ASIL
A
++
++
++
++
Design Tools and
Processes
Comments

Validation
Requirements Management
Interface (RMI)
Traceability matrix
RMI can be used to establish bidirectional

links between textual requirements and
models.
Simulink Signal Builder block

Stateflow Dynamic test vector
charts
Validation Component
testing capabilities
Simulink Test
1b
Interface test
++
++
++
++

case generation
Simulink Test Test Harness
capability
1c
Fault injection test
++
Simulink
Stateflow
Generated traceability matrices can be used

to document and review existing links
between textual requirements, models, and
code.
Signal Builder blocks can be used to create
open-loop model tests.
Dynamic test vector charts can be used to
create closed-loop, reactive model tests.
Component testing capabilities can be used
to create model test harnesses. They also
enable a requirements pane in the Signal
Builder that can be used to link tests with
textual requirements.
cases and procedures for SIL and PIL
implementation model testing, evaluate test
results and generate test reports.
Test Manager capability of Simulink Test
can be used to establish bidirectional links
between textual requirements and test
cases.
Automatic test case generation in
combination with Test Objective blocks
can be used to generate interface tests.
Test Harness capability of Simulink Test
can be used to develop interface tests for
the implementation model.
carry out fault injection tests. The tools can
also be used to simulate failure propagation
at the model level. For this purpose, the
2-15
Methods
ASIL
A
Design Tools and
Processes

case generation
capability
1d
Resource usage test
++
Embedded Coder Processorin-the-loop (PIL) testing, code

metrics report
1e
Back-to-back test
between model and
code, if applicable
++
++
Simulink
Comments
system model and a separate failure model

can be used.
can be used to generate fault injection
tests.
can be used to develop fault injection tests.

Validation Component testing
capabilities, model coverage
PIL testing analyzes resource utilization on

a target processor. The code metrics report
provides the amount of memory used by
the generated code.
Simulation capabilities of Simulink and
Stateflow and the component test
capabilities of Simulink Verification and
Validation facilitate dynamic testing of
models. Model coverage capability can be
used to assess the completeness of the
model tests.

case generation
Simulink Design Verifier can generate

missing test cases to achive test coverage.
Simulink Test Test Manager

Capability

can be used to facilitate back-to-back
testing between model and code using
baseline and equivalence test modes.
SIL and PIL testing provide a way to
execute model tests on generated code.
CGV automates selected back-to-back
testing workflows.
Stateflow
Embedded Coder Softwarein-the-loop (SIL) testing,

processor-in-the-loop (PIL)
testing, code generation
verification (CGV)
Simulink Simulation Data
Inspector (SDI)
Capability
SDI can be used to support the comparison

of test results created during back-to-back
testing.
can be used to compare results of models
simulation to SIL and PIL test results.
2-16
Table 11 Methods for Deriving Test Cases for Software Unit Testing
Methods
1a
Analysis of
requirements
ASIL
A
++
++
++
++
Design Tools and
Processes
Comments


Simulink Test
Simulink Test can be used to establish

bidirectional links between textual
requirements and test cases.
The analysis of equivalence classes can be
based on the interfaces of the model.
can be used to generate test cases and test
sequences for given equivalence classes.
The analysis of boundary values can be
sequences for given boundary values.
1b
Generation and
analysis of
equivalence classes
++
++
++

case generation
1c
Analysis of boundary
values
++
++
++

case generation
1d
Error guessing
Table 12 Structural Coverage Metrics at the Software Unit Level

Methods
ASIL
A
Design Tools and
Processes
Comments
During software-in-the-loop (SIL)

simulation, Embedded Coder can collect
statement coverage by using the third-party
tool LDRA Testbed.
During SIL simulation, Embedded Coder
can collect condition/decision coverage
information, which usually subsumes
statement coverage, by using the thirdparty tool BullseyeCoverage.
During model testing, Simulink
Verification and Validation can collect
decision coverage (also known as branch
coverage) at the model level.
1a
Statement coverage
++
++
Embedded Coder Code

coverage collection
1b
Branch coverage
++
++
++

analysis
2-17
Methods
ASIL
A
Design Tools and
Processes
Comments

case generation
Simulink Design Verifier can generate test

cases that satisfy decision coverage at the
model level.
During software-in-the-loop (SIL)
simulation, Embedded Coder can collect
statement coverage by using the third-party
tool LDRA Testbed.
can collect condition and decision
coverage, which usually subsumes
statement coverage, by using the thirdparty tool BullseyeCoverage.
During model testing, Simulink
Verification and Validation verification can
collect MC/DC coverage at the model
level.
Simulink Design Verifier can be used to
generate test cases that satisfy MC/DC
coverage at the model level.
can collect MC/DC coverage by using the
third-party tool LDRA Testbed.
Embedded Coder Code

coverage collection
1c
MC/DC (Modified
Condition/Decision
Coverage)
++

analysis
case generation
Embedded Coder Code
coverage collection
2-18
2.5 Software Integration and Testing

Table 13 Methods for Software Integration Testing
Methods
1a
Requirements-based
test
ASIL
A
++
++
++
++
Design Tools and
Processes
Comments

RMI can be used to establish bidirectional

links between textual requirements and
models.

Traceability matrix
Generated traceability matrices can be used

to document and review existing links
between textual requirements, models, and
code.
The Signal Builder block can be used to
create open-loop model tests.
Simulink Signal Builder block
Stateflow Dynamic test vector

charts
capabilities
Simulink Test
1b
Interface test
++
++
++
++

case generation
capability
1c
Fault infection test
++
++
Simulink
Stateflow
Dynamic test vector charts can be used to

create closed-loop, reactive model tests.
Builder, which can be used to link tests
with textual requirements.
cases and procedures for SIL and PIL
testing, evaluate test results and generate
test reports.
can be used to establish bidirectional links
between textual requirements and test
cases.
can generate fault injection tests.
can be used to develop interface SIL and
PIL tests.
execute fault injection tests. Can also
simulate failure propagation at the model
2-19
Methods
ASIL
A
Design Tools and
Processes

case generation
capability
1d
Resource usage test
++
Embedded Coder Processorin-the-loop (PIL) testing, code

metrics report
1e
Back-to-back test
between model and
code, if applicable
++
++
Simulink
Stateflow

capabilities, model coverage
case generation
Embedded Coder Softwarein-the-loop (SIL) testing,
processor-in-the-loop (PIL)
testing, code generation
verification (CGV)
Simulink Simulation Data
Inspector (SDI)
Capability
Comments
level. For this purpose, a system model

and/or a separate failure model can be used.
can generate fault injection tests.
can be used to develop fault injection SIL
and PIL tests.
PIL testing analyzes resource utilization on
a target processor. The code metrics report
provides information about memory usage
of generated code.
Simulation capabilities of Simulink and
Stateflow and the component test
capabilities of Simulink Verification and
Validation facilitate dynamic model
testing.
Model coverage can assess the
completeness of model tests.
Simulink Design Verifier can generate
missing test cases.
SIL and PIL testing capabilities execute

model tests on generated code. CGV can
automate selected back-to-back testing
workflows.
SDI can be used to support comparison of
test results created during back-to-back
testing.
can be used to:
facilitate back-to-back testing between
model and code using baseline and
equivalence test modes
compare results of model simulation
(MIL) to SIL and PIL test results
2-20
Table 14 Methods for Deriving Test Cases for Software Integration Testing
Methods
1a
Analysis of
requirements
ASIL
A
++
++
++
++
Design Tools and
Processes
Comments


Simulink Test can be used to establish
bidirectional links between textual
requirements and test cases.
The analysis of equivalence classes can be
sequences for given equivalence classes.
The analysis of boundary values can be
sequences for given boundary values.
Simulink Test
1b
Generation and
analysis of
equivalence classes
++
++
++

case generation
1c
Analysis of boundary
values
++
++
++

case generation
1d
Error guessing
Table 15 Structural Coverage Metrics at the Software Architectural Level

Methods
ASIL
A
Design Tools and
Processes
Comments

can collect function coverage information
by using the third-party tool
BullseyeCoverage.
can collect procedure/function call
coverage information by using the thirdparty tool LDRA Testbed.
1a
Function coverage
++
++
Embedded Coder Code

coverage collection
1b
Call coverage
++
++
Embedded Coder Code

coverage collection
2-21
2-22
3 ISO 262628:
Applicable Model-Based Design
Tools and Processes
3.1 Confidence in the Use of Software Tools

Table 4 Qualification of Software Tools Classified TCL3
Methods
1a
1b
1c
1d
ASIL
A
Increased confidence
from use in
accordance with 11.4.7
Evaluation of the tool
development process
in accordance with
11.4.8
Validation of the
software tool in
++
++
++
++
++
++
Development in
accordance with a
safety standard
++
++
Design Tools and
Processes
Comments
IEC Certification Kit - ISO

26262 Tool Qualification Kits
Embedded Coder, Simulink Verification

and Validation, Simulink Design Verifier,
Simulink Test, Polyspace Bug Finder and
Polyspace Code Prover have been
prequalified, using a combination of
methods 1b and 1c. TV SD carried out
an independent tool qualification
assessment.
The IEC Certification Kit provides
Software Tool Criteria Evaluation reports,
Software Tool Qualification reports, and
evidence for the independent assessment.
exemplary test cases and test procedures
for Embedded Coder, Simulink
Verification and Validation, Simulink Test,
Polyspace Bug Finder and Polyspace Code
Prover that can be used to facilitate tool
validation tests for these products.
3-2
Table 5 Qualification of Software Tools Classified TCL2

Methods
1a
1b
1c
1d
ASIL
A
Increased confidence
from use in
Evaluation of the tool
development process
in accordance with
11.4.8
Validation of the
software tool in
++
++
++
++
++
++
++
Development in
accordance with a
safety standard
++
Design Tools and
Processes
Comments
IEC Certification Kit- ISO

26262 Tool Qualification Kits
Embedded Coder, Simulink Verification

and Validation, Simulink Design Verifier,
Simulink Test, Polyspace Bug Finder and
Polyspace Code Prover have been
prequalified, using a combination of
methods 1b and 1c. TV SD carried out
an independent tool qualification
assessment.
Software Tool Criteria Evaluation reports,
Software Tool Qualification reports, and
evidence for the independent assessment.
exemplary test cases and test procedures
for Embedded Coder, Simulink
Verification and Validation, Simulink Test,
Polyspace Bug Finder and Polyspace Code
Prover that can be used to facilitate tool
validation tests for these products.
3-3

Certkitiec MBD Iso26262

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Certkitiec MBD Iso26262

Uploaded by

Copyright:

Available Formats

IEC Certification Kit

Model-Based Design for ISO 26262

How to Contact MathWorks

Sales and services:

The MathWorks, Inc.

COPYRIGHT 20122015 by The MathWorks, Inc.

New for Version 2.1 (Applies to Release 2012a)

1 Model-Based Design for ISO

2.1 Initiation of Product Development at the Software

The High Integrity System Modeling

2.2 Software Architectural Design

Simulink Model Info and

The blocks can be used to integrate

Simulink Verification and

The RMI can be used to link Simulink and

Table 3 Principles for Software Architectural Design

Simulink Model block, Ports

Model blocks (model referencing),

Software components can be structured

Polyspace Bug Finder

Simulink Verification and

Polyspace Bug Finder Code

High cohesion with

Polyspace Bug Finder

Stateflow Scheduler patterns

ISO 26262 Model Advisor check Display

Polyspace Bug Finder Code metrics

Table 4 Mechanisms for Error Detection at the Software Architectural Level

Range checks of input

Polyspace Code Prover

Simulink and Stateflow can be used to

Software diversity for algorithmic parts can

Table 5 Mechanisms for Error Handling at the Software Architectural Level

Simulink and Stateflow can be used to

Table 6 Methods for Verification of Software Architectural Design

Simulink Report Generator

Simulink Verification and

Architectural design walkthroughs can be

Design inspections can be based on the

Simulink Model Verification

Model Verification blocks can be used to

Simulink Design Verifier

Control flow analysis

Simulink Verification and

Data flow analysis

Automatic test case generation can be used

2.3 Software Unit Design and Implementation

Simulink Model Info block,

The blocks can be used to add natural

Simulink Verification and

Models representing unit designs can be

The RMI can be used to link models

Table 8 Design Principles for Software Unit Design and Implementation

One entry and one exit

Adherence can be facilitated by applying

Polyspace Bug Finder

Polyspace Code Prover,

Setting the Underspecified initialization

Polyspace Bug Finder

Avoid global variables or

Limited use of pointers

Polyspace Bug Finder

Setting the Duplicate data store names