IEC Certification Kit: Model-Based Design For ISO 25119:2018
IEC Certification Kit: Model-Based Design For ISO 25119:2018
IEC Certification Kit: Model-Based Design For ISO 25119:2018
R2020b
This documentation provides annotated versions of method tables that appear in the ISO 25119-3:2018
standard.
The annotated tables provide suggestions on how to use Model-Based Design products from MathWorks®
to apply the methods listed in the standard for different Software Requirement Levels (SRLs).
The IEC Certification Kit provides additional support when using Model-Based Design for ISO 25119
applications, including reference workflows for verifying and validating models and generated code.
The tables in this document use these ratings to specify whether the technique/measure is recommended
based on the SRL:
• “+” ― Technique or measure shall be used for this SRL, unless there is reason not to, in which case that
reason shall be documented during the planning phase.
• “o” ― There is no recommendation for or against the use of technique or measure for this SRL.
• “x” ― Technique or measure is not suitable for to meet this SRL.
2.1 Software
Table 1 — Software safety requirements specification
4a Inspection of software safety + + + + Simulink Requirements Inspection of the requirements authored using
requirements a Simulink
Simulink Requirements can be supported using
traceability, implementation status, and report
Stateflow generation features of the tool.
System Composer Inspection of the requirements authored with
Simulink® Report Simulink, Stateflow, and System Composer can be
Generator™ − Web View, facilitated using a System Composer spotlight
view, a generated Web View, or an SDD report.
System Design
Description (SDD) report
a) Appropriate techniques/measures shall be selected according to the SRL. Alternative or equivalent techniques/measures are indicated
by a letter following the number. Only one of the techniques/measures needs be satisfied.
b) In case of model-based development with code generation, the methods and measures for software architectural design have to be
applied to the functional model, which will serve as the basis for code generation.7.2.4.1.1
Simulink Requirements
a) Appropriate techniques/measures shall be selected according to the SRL. Alternative or equivalent techniques/measures are indicated
by a letter following the number. Only one of the techniques/measures needs to be satisfied.
Table 3 — Software design and development - Support tools and programming language
1.1 Suitable programming + + + + Embedded Coder® C or C++ programming languages with subset and
language coding standard is a common industry practice for
Simulink® Coder™
embedded systems development.
MATLAB® Coder™
MATLAB Coder, Simulink Coder, and Embedded
Coder can generate C or C++ code. Language
subsets, coding standards, and static analysis
tools are discussed elsewhere in this document.
1.2 Strongly typed programming O + + + Simulink, Simulink – Simulink and Stateflow can be configured to
language Configuration facilitate strong typing at the model level.
Stateflow Type compatibility constraints can be embedded
in the math operator or logical blocks at the
model level.
Simulink® Check™ – IEC IEC 61508 and custom checks in Model Advisor
61508 Model Advisor can be used to check typing considerations within
checks the model.
1.4 Tools and translators: O + + + MATLAB® and Simulink MATLAB and Simulink product family have a
increased confidence from use product family broad user base. The products are subjected to
extensive in-house testing.
Bug reports can be accessed by on the
MathWorks website.
1.5 Use of trusted/verified O O + + Simulink – Block library, Model blocks (model referencing) facilitate the
software components (if Model block creation and re-use of trusted / verified software
available) System Composer elements by the user.
Blocks from this standard library can be
preconfigured, verified, and grouped into custom
libraries to facilitate creation and re-use of
trusted/verified software elements by the user.
System Composer enables decomposition and
reuse of component within the same model, as
well as across architecture models.
2 Design methods
2.1a Informal methods a + + X X Simulink – Model Info Referenced blocks can be used to integrate
and DocBlock blocks informal textual descriptions into a design model.
Simulink®
Requirements™ – System
Requirements block
2.1b Semi-formal methods + + + + System Composer System Composer, Simulink, and Stateflow
provide semiformal notation for software design.
Simulink
Stateflow
2.1c Formal methods + + + + Simulink – Model Model Verification blocks can be used to
Verification block library formalize properties of in Simulink design models,
which can be formally proven with Simulink
Simulink Design Verifier
Design Verifier.
2.3 Structured programming O + + + System Composer System Composer enables definition of software
architecture through hierarchical decomposition
of components and definition of control and data
flow.
2.4.1 Software component size limit O + + + System Composer Software components can be structured
Simulink hierarchically to limit component size.
Embedded Coder
Embedded Coder − Code The code metrics report provides the amount of
metrics report memory used by the generated code.
Polyspace Bug Finder Polyspace Bug Finder and Polyspace Bug Finder
and Polyspace Bug Server support the generation of size metrics for
Finder Server – Code source code.
metrics
2.4.2 Software complexity control O O O + Simulink Check – Simulink Check provides the ability to measure a
Cyclomatic Complexity model.
Metric, IEC 61508 checks IEC 61508 Model Advisor check “Display model
metrics and complexity report” provides
information on the complexity of models and
subsystems.
Polyspace Bug Finder Polyspace Bug Finder and Polyspace Bug Finder
and Polyspace Bug Server –support the generation of size and
Finder Server – Code complexity metrics for source code.
metrics
2.4.3 Information O O + + Simulink – Model block, Model blocks (model referencing), subsystems,
hiding/encapsulation Ports & Subsystems libraries, and Stateflow charts can support
block library information encapsulation and hiding.
Stateflow System Composer enables definition of
architecture through hierarchical decomposition
System Composer
of components supporting encapsulation and
hiding.
Polyspace Bug Finder Polyspace Bug Finder and Polyspace Bug Finder
and Polyspace Bug Server can assess compliance with MISRA C rules
Finder Server − MISRA C for subroutines and functions.
checker
Polyspace Bug Finder Polyspace Bug Finder and Polyspace Bug Finder
and Polyspace Bug Server support the generation of return points
Finder Server – metrics for source code.
Code metrics
2.4.5 Fully defined interface O + + + System Composer System Composer can be used to define
interfaces for architecture models and produce
Simulink – Model blocks
interface control documents for architecture
models.
The usage of model blocks facilitates fully defined
interface specifications at model block
boundaries.
Simulink Check – IEC IEC 61508 Model Advisor check “Check for fully
61508 checks defined interface” identifies root model Inport
blocks that do not have fully defined attributes.
2.5 Library of trusted/verified + + + + Simulink – Block library, Model blocks (model referencing) facilitate the
software components Model block creation and re-use of trusted / verified software
elements by the user.
System Composer
Blocks from this standard library can be
preconfigured, verified, and grouped into custom
libraries to facilitate creation and re-use of
trusted/verified software elements by the user.
System Composer enables decomposition and
reuse of component within the same model as
well as across architecture models.
3.1 Use of coding standard O + + + Simulink − Modeling The Modeling Guidelines for High-Integrity
Guidelines Systems and MAB provide guidelines at the model
level.
Polyspace Bug Finder Polyspace Bug Finder and Polyspace Bug Finder
and Polyspace Bug Server MISRA C checker can be used to check
Finder Server – MISRA C MISRA AC AGC compliance considerations at the
checker source code level.
3.2a No dynamic variables or O O O + Embedded Coder – Embedded Coder can be configured to generate C
objects Configuration code that does not include dynamic
objects/variables.
Polyspace Bug Finder Polyspace Bug Finder and Polyspace Bug Finder
and Polyspace Bug Server can assess compliance with MISRA C rules
Finder Server – MISRA C for dynamic objects.
checker
3.3 Limited use of interrupts O O O + Embedded Coder – Embedded Coder can be configured to not insert
Configuration interrupts into step function code.
3.4 Defined use of pointers O O O + Embedded Coder – Embedded Coder may generate pointer
Configuration 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.
Polyspace Bug Finder Polyspace Bug Finder and Polyspace Bug Finder
and Polyspace Bug Server can assess compliance with MISRA C:2004
Finder Server – MISRA C rules 11.1 to 11.5 and 17.3 to 17.5 and MISRA
checker C:2012 rules 11.1 to 11.8 and 18.3 to 18.5, which
restrict use of pointers.
Polyspace Bug Finder and Polyspace Bug Finder
Server can check whether pointers refer to valid
objects. Violations are reported as IDP checks.
3.5 Limited use of recursion O O O + Simulink – Modeling Adherence can be facilitated by applying
Guidelines 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 of >
5.
Polyspace Bug Finder Polyspace Bug Finder and Polyspace Bug Finder
and Polyspace Bug Server support the generation of recursions and
Finder Server – Code direct recursions metrics for source code.
metrics
a) Appropriate techniques/measures shall be selected according to the SRL. Alternative or equivalent techniques/measures are indicated
by a letter following the number. Only one of the techniques/measures needs to be satisfied.
1.1 Boundary value analysis + + + + Simulink Design Verifier − The Simulink Design Verifier automatic test case
Test case generation generation feature in combination with Test
Objective blocks can be used to generate test cases
and test sequences for given boundary values.
1.3 Control flow analysis O O + + Coverage – Model Model coverage analysis can help to identify
coverage analysis unreachable portions of a model.
Simulink Coverage – Code During SIL and PIL execution, Simulink Coverage
coverage analysis can identify unreachable parts of the generated
code.
Polyspace Code Prover Polyspace Code Prover and Polyspace Code Prover
and Polyspace Code Server can partially extract control flow
Prover Server – Call tree information from C code and can create the
computation, unreachable application call tree. Gray checks detect
code analysis unreachable code.
1.4 Data flow analysis O O + + Simulink – Diagnostics Data Store Memory block diagnostics and Stateflow
diagnostics can be configured to identify data flow
Stateflow – Diagnostics
issues.
Polyspace Code Prover Polyspace Code Prover and Polyspace Code Prover
and Polyspace Code Server support static verification of dynamic
Prover Server – Code properties of generated code. This verification
verification technique is based on data flow analysis.
2.1 Test case execution from O O O + Simulink Design Verifier − The Simulink Design Verifier automatic test case
boundary value analysis Test case generation generation feature in combination with Test
Objective blocks can be used to generate test cases
Simulink Test
and test sequences for given boundary values.
Simulink
Simulink Test can be used to execute generated
Stateflow tests using Simulink and Stateflow as a modeling
platform.
2.2a Structure test coverage O O + X Simulink Coverage − During model testing, Simulink Coverage can collect
(entry points) Model coverage analysis execution coverage at the model level, which
addresses entry point coverage metric.
2.2b Structure test coverage O O + + Simulink Coverage − During model testing, Simulink Coverage can collect
(statements) Model coverage analysis execution coverage at the model level, which
addresses the statement coverage metric.
Simulink Coverage − Code During SIL and PIL execution, Simulink Coverage
coverage analysis can measure the statement coverage of the
generated code.
2.2c Structural test coverage O O + + Simulink Coverage − During model testing, Simulink Coverage can collect
(branches) Model coverage analysis decision coverage (also known as branch coverage)
at the model level.
Simulink Coverage − Code During SIL and PIL execution, Simulink Coverage
coverage analysis can measure the decision coverage of the
generated code.
Simulink Design Verifier − Simulink Design Verifier can generate test cases
Test case generation that satisfy decision coverage at the model level.
3 Unit testing
3.1 Equivalence classes and input O O + + Simulink Design Verifier – The Simulink Design Verifier automatic test case
partition testing Test case generation generation feature in combination with Test
Objective blocks can be used to generate test cases
Simulink Test
and test sequences for given equivalence classes
Simulink and inputs partitions.
Stateflow The analysis of equivalence classes can be based on
the interfaces of the model.
Simulink Test can be used to execute generated
tests for equivalence classes and input partitioning
using Simulink and Stateflow as a modeling
platform.
3.2 Boundary value analysis O O + + Simulink Design Verifier − The Simulink Design Verifier automatic test case
Test case generation generation feature in combination with Test
Objective blocks can be used to generate test cases
Simulink Test
and test sequences for given boundary values.
Simulink
Simulink Test can be used to execute generated
Stateflow tests using Simulink and Stateflow as a modeling
platform.
3.3 Test case execution from O O O + Simulink Design Verifier − Simulink Design Verifier can be used to auto-
model-based test case Test case generation generate tests for models to satisfy coverage and
generation test objective criteria.
Simulink Test
Simulink Test can be used for authoring tests and
Simulink
execution of manually created and auto-generated
Stateflow tests using Simulink and Stateflow as a modeling
platform.
4 Performance testing
4.1 Response timings and O + + + Embedded Coder − The execution profiling feature of Embedded Coder
memory constraints execution profiling and can be used to analyze execution timing of code
code metrics report components. The code metrics report provides the
amount of memory used by the generated code.
4.3 Avalanche/stress testing O O O + Simulink Test Simulink Test can be used to develop and execute
performance tests for components using Simulink
Simulink
and Stateflow as a modeling platform.
Stateflow
5 Interface testing O O O + Simulink Design Verifier – The Simulink Design Verifier automatic test case
Test case generation generation feature in combination with Test
Objective blocks can be used to generate interface
Simulink Test
tests.
Simulink
Simulink Test can be used to execute generated
Stateflow tests for equivalence classes and input partitioning
using Simulink and Stateflow as a modeling
platform.
a) Appropriate techniques/measures shall be selected according to the SRL. Alternative or equivalent techniques/measures are indicated by a
letter following the number. Only one of the techniques/measures needs to be satisfied.
2 Equivalence classes and input O O + + Simulink Design Verifier The Simulink Design Verifier automatic test case
partition testing – Test case generation generation feature in combination with Test
Objective blocks can be used to generate test
Simulink Test
cases and test sequences for given equivalence
Simulink classes, boundary values, and inputs partitions.
Stateflow The analysis of equivalence classes can be based
on the interfaces of the model.
Simulink Test can be used to execute generated
tests for equivalence classes and input
partitioning using Simulink and Stateflow as a
modeling platform.
3 Performance testing
3.1b Response timings and memory O + + + Embedded Coder − The execution profiling feature of Embedded
constraints execution profiling and Coder can be used to analyze execution timing of
code metrics report code sections. The code metrics report provides
the amount of memory used by the generated
code.
3.2 Performance requirements O O + + Simulink Test Simulink Test can be used to develop and execute
testing performance integration tests using Simulink and
Simulink
Stateflow as a modeling platform.
Stateflow
3.3 Avalanche/stress testing O O O + Simulink Test Simulink Test can be used to develop and execute
avalanche and stress integration tests using
Simulink
Simulink and Stateflow as a modeling platform.
Stateflow
a) Appropriate techniques/measures shall be selected according to the SRL. Alternative or equivalent techniques/measures are indicated
by a letter following the number. Only one of the techniques/measures needs to be satisfied.
1.1b Hardware-in-the-loop tests O + + + Simulink Real-Time Simulink Real-Time or Simulink Desktop Real-Time
can be used to create real-time applications from
Simulink Desktop Real-
Simulink models and run them on dedicated
Time target hardware connected to your physical
system for hardware-in-the-loop (HIL) testing.
a) Appropriate techniques/measures shall be selected according to the SRL. Alternative or equivalent techniques/measures are indicated
by a letter following the number. Only one of the techniques/measures needs to be satisfied.