Embedded Software Verification with Polyspace Products Patrick Munier, R&D, MathWorks
Embedded Software Verification with
Polyspace Products
for IEC 61508 and ISO 26262
Patrick Munier, R&D, MathWorks
Stefan David, Application Engineering, MathWorks
© 2012 The MathWorks, Inc.
1
Today’s Topics
Introduction/Refresh to Polyspace technology
Covering ISO 26262 and Software Quality
Objectives (SQO) requirements with Polyspace
What‘s New in Polyspace R2012a
Q&A and discussion
2
Introduction/Refresh to Polyspace
code verification technology
© 2012 The MathWorks, Inc.
3
Which problem is adressed by Polyspace?
Problem: Tests aren’t exhaustive
“Program testing can be used to show the presence of
bugs, but never to show their absence” (Dijkstra [3])
?
“Given that we cannot really show there are no more
errors in the program, when do we stop testing?”
(Hailpern [4])
“Imagine how much time is used debugging and
reviewing correct software” (Stefan David, MAC 2012)
[4] Dijkstra, “Notes On Structured Programming”, 1972
[5] Hailpern, Santhanam, “Software Debugging, Testing, and Verification”, IBM Systems Journal, 2002
4
Why PROVE THE ABSENCE of run-time errors?
Reduced risk of catastrophic failures
– A significant number of bugs are run-time errors
– For quality-critical, business-critical, or highintegrity environment
– Increased confidence
Reduced time spent on verification and
certification activities
– Shortened debugging cycles
– Changes implemented correctly
– Certification activities streamlined
Ariane 501 European
launcher
5
Formal Method – Semantic Analysis scope
Applicable to both: Code AND Models
Formal verification methods
mathematically prove existence of
certain errors, or their absence.
Green: reliable
safe pointer access
Model:
static void pointer_arithmetic (void) {
int array[100];
int *p = array;
int i;
for (i = 0; i < 100; i++) {
*p = 0;
p++;
}
Code:
Red: faulty
if (get_bus_status() > 0) {
if (get_oil_pressure() > 0) {
*p = 5;
} else {
out of bounds error
i++;
Gray: dead
}
}
unreachable code
i = get_bus_status();
if (i >= 0) {
*(p - i) = 10;
}
Orange: unproven
may be unsafe for some
conditions
}
6
Leverage an integrated tool chain
For Model-Based Design and automatic code generation
• Use traceability back to the model
• Use available context information for inputs and parameters
Available for Embedded Coder, dSPACE TargetLink, and IBM Rhapsody
7
Typical users in your development process
Unit and integration level
– Improve the robustness of models/code
– Support code review
Project Managers
– Check the progress of projects
Safety Managers
Relative cost to fix it
SW/Systems Developers and Testers
– Fulfill standards requirements
Quality Assurance
– Manage improvement
– Audit your supplier’s code
Relative cost to fix defect per phase
found
Source: Return on Investment for Independent Verification & Validation,
NASA, 2004.
8
Summary: What is Polyspace used for?
Static and Semantic code analysis
Certification
“0 defect
vision”
Coding
Standards
Early
Defect
Detection
• Prove the absence
of run-time errors
• Web interface
• IEC 61508
• ISO 26262
• EN 50128
• DO-178B
• JSF++
• MISRA-C
• MISRA-C++
• MISRA AC AGC
• Code metrics
(HIS)
• Productivity
• Find bugs
quickly
99
Covering ISO 26262 and Software
Quality Objectives (SQO)
© 2012 The MathWorks, Inc.
10
Covering ISO 26262
ISO 26262-6 Software unit design and implementation
Methods
A
ASIL
B
C
D
1a
Walk-through
++
+
o
o
1b
Inspection
+
++
++
++
1c
Semi-formal verification
+
+
++
++
1d
Formal verification
o
o
+
+
1e
Control flow analysis
+
+
++
++
1f
Data flow analysis
+
+
++
++
1g
Static code analysis
+
++
++
++
1h
Semantic code analysis
+
+
+
+
Table 9 – Methods for the verification of the software unit design and implementation
*) […] is used for mathematical analysis of source code by use of an abstract representation of possible
values for the variables. For this it is not necessary to translate and execute the source code.
(ISO 26262-6, table 9, Method 1h)
11
It’s state of the art!
ISO 26262-6 Software unit design and implementation
Methods
A
ASIL
B
C
D
1a
Walk-through
++
+
o
o
1b
Inspection
+
++
++
++
1c
Semi-formal verification
+
+
++
++
1d
Formal verification
o
o
+
+
1e
Control flow analysis
+
+
++
++
1f
Data flow analysis
+
+
++
++
1g
Static code analysis
+
++
++
++
1h
Semantic code analysis*)
+
+
+
+
Table 9 – Methods for the verification of the software unit design and implementation
*) […] is used for mathematical analysis of source code by use of an abstract representation of possible
values for the variables. For this it is not necessary to translate and execute the source code.
(ISO 26262-6, table 9, Method 1h)
12
Applicable Tools / Processes
Example: Software unit design and implementation
Methods
1a
1b
1c
1d
A
One entry and one exit ++
point in subprograms
and functions
No dynamic objects or +
variables, or else
online test during their
creation
++
Initialisation of
variables
No multiple use of
variables names
+
Applicable Model-Based Design
Tools / Processes
ASIL
B
C
++
++
D
++
++
++
++
• Embedded Coder - Configuration
• Polyspace – Coding Guidelines
++
++
++
++
++
++
•
•
•
•
• Simulink – Modeling Guidelines
• Polyspace – Coding Guidelines
Simulink – IC block, Diagnostics
Embedded Coder – Configuration
Polyspace – Code Verification
Simulink - Diagnostics
Table 8 – Design principles for software unit design and implementation (1/2)
Note:
Further coverage of methods for table 3, 4, 6, 9
Please contact us for further details and mapping tables!
13
Applicable Tools / Processes
Example: Software unit design and implementation
Methods
D
++
+
++
++
+
++
++
++
• Embedded Coder
• Polyspace – Coding Guidelines, Code
Verification
• Polyspace – Code Verification
+
++
++
++
• Polyspace – Coding Guidelines
++
++
++
++
• Polyspace – Coding Guidelines
+
+
++
++
• Simulink – Modeling Guidelines
• Polyspace – Call Tree
A
1e
Avoid global variables
or else justify their
usage
1f
Limited use of pointers o
1g
No implicit data type
conversions
No hidden data flow or
control flow
No unconditional
jumps
No recursions
1h
1i
1j
Applicable Model-Based Design
Tools / Processes
ASIL
B
C
+
++
+
• Simulink
• Embedded Coder – Configuration
• Polyspace – Code Verification
Table 8 – Design principles for software unit design and implementation (2/2)
Note:
Further coverage of methods for table 3, 4, 6, 9
Please contact us for further details and mapping tables!
14
Applicable Tools / Processes
Confidence in the use of software tools (ISO 26262-8)
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
accordance with 11.4.9
Development in
+
accordance with a
safety standard
B C
++ +
D
+
++ +
+
+
++ ++
+
++ ++
Applicable Model-Based Design Tools /
Processes
• IEC Certification Kit – Pre-qualification of
MathWorks tools, Exemplary test cases and
test procedures
Table 4 – Qualification of software tools classified TCL3
15
Standards and Regulations
IEC Certification Kit (for IEC 61508 and ISO 26262)
Provides certification artifacts, including:
– TÜV SÜD certificates & reports
– Verification and validation workflow
documentation and guidance
– Customizable templates
– Tool use cases and classification
– Test cases/procedures
Support includes the following:
– Polyspace Client / Server for C/C++
– R2008a through R2012a
Includes templates for:
SW Tool Qualification Plan
SW Tool Documentation
SW Tool Classification Analysis
SW Tool Qualification Report
www.mathworks.com/products/iec-61508/
Note: Embedded Coder and Polyspace products for C/C++ were not developed using certified processes.
16
How can you use Polyspace to implement
standard and quality requirements?
Implementation Example:
Software Quality Objectives
for Source Code
Cost
Time
Quality
© 2012 The MathWorks, Inc.
17
The origin of the project
Major automotive
OEM and suppliers
need to agree on
Renault
Elektrobit
PSA
– A quality model
A list of suggested
quality objectives
Continental
Delphi
– A process guide
A practical plan for an
incremental adoption of
tools and process
changes to meet the
objectives
MathWorks
Valeo
The SQO group started in 2007 with OEMs,
and extended to suppliers
18
How Quality Assurance for source code is
defined - examples
1
Investigation
• Find root Causes of
Defects
Post-mortem analysis
2
Audit
• Evaluate delivered
Software Quality
3
Control
• Verify intermediate
software builds
• Definition of a Quality
model
In-product quality
4
Prevention
• Remove defects at
coding time
• Implications at the
process & tools levels
19
ADJUSTABLE QUALITY
MODEL
20
Scope of the metrics - Key Categories
MISRA-2004
Rules
Un-reachable
Branches
Nonterminating
Constructs
Code Metrics
Detailed
Design
Description
Quality
Plan
Run-time
Errors
SQO
Dataflow
Analysis
21
Why are they good quality measures?
It includes market’s best practices
– Code metrics
HIS metrics, cyclomatic number, …
– Coding rules
MISRA-C compliance
– Run-time errors
Overflows,
Divisions by zero,
Out of bound arrays
22
27 Software Quality Requirements
SQR-140
The automotive manufacturer and the supplier shall
choose at the beginning of the project the code
metrics that will be used
SQR-150
For the chosen metrics, the supplier shall demonstrate
that the modules comply with the agreed boundary
limits, or justify the deviations
SQR-160
The supplier shall demonstrate that all the files within
a module are compliant with the “first MISRA rules
subset”. The supplier shall correct or justify all
violations of the rules
SQR-200
The supplier shall demonstrate that for all files within a
module a review of systematic runtime errors has
been performed and that errors which have not been
corrected are justified, for the following categories:
out-of-bound array access, …
23
Adapted to various context
Available for C++ language as well as for C
– MISRA C++:2008 rules on top of MISRA-C:2004 rules
– Specific C++ runtime errors
Applicable to Generated Code
– MISRA AC AGC subset
24
SQO is compliant with ISO 26262
IEC certification process requires to define a quality model and its
application
It’s not an additional task of the certification process
25
HOW TO USE SQO?
A PROCESS GUIDE
Incremental process
26
Quality improvement needs to be gradual
SQO defines 6 different quality levels
– Can be applied on new and on-going projects
Increasing quality requirements
– Quality requirements are increasing along with the software
builds
– Granularity at the module or application level
Benefits
– Limit review efforts to the required quality
– Improve quality incrementally
27
Software Quality Objectives:
Incremental Quality
SQO Step 1
• Quality Plan & Detailed Design
• Code Metrics
• 1st MISRA-2004 rules subset
SQO Step 2
• Systematic run-time errors
• Non terminating constructs
SQO Step 3
• Unreachable branches
SQO Step 4
• 1st subset of potential run-time errors
SQO Step 5
• 2nd MISRA-2004 rules subset
• 2nd subset of potential run-time errors
SQO Step 6
• 3rd subset of potential run-time errors
• Dataflow Analysis
28
Industrial Use of SQO
SQO is integrated in PSA,
Renault (France) and Nissan
(Japan) Quality Requirements
Hyundai Motor (Korea) is using
SQO’s principles for their
suppliers
Suppliers integrated these
requirements in their process
(Delphi, Valeo, Elektrobit, etc.)
29
How to cover SQO with Polyspace?
Define and share a quality
model
– Goals to be achieved
– Metrics to measure these goals
– Thresholds to meet
Have pass-fail criteria
Compare versions
Follow the progression
MATLAB file exchange: “Using Polyspace to implement the “software quality objectives
for source code quality” standard”
30
3 Takeaways
SQO helps to address ISO-26262 requirements for
compliancy
Polyspace provides an efficient framework for SQO and
produce reports for compliancy with ISO-26262
SQO is recognized by TÜV Süd as workflow for using
Polyspace along with ISO-26262
31
What’s New for Polyspace Products
R2012a
© 2012 The MathWorks, Inc.
32
Integrated code rule violations view
Easier to review coding rule violations
New purple color for
code rule violations
Uniform review of runtime errors and coding
rules violations
Powerful filter/navigation
capabilities
33
MISRA-C checker improvements
Support for MISRA AC AGC subset
Easy to setup and
launch
Includes predefined list
of OBLigatory rules
New option -allowedpragmas to configure
new rule 3.4
34
Ease of use and deeper integration with
Simulink
R2011a
Polyspace fully integrated
with Simulink Config Set
R2011a: Polyspace Model Link
use GUIDE interface
R2011b: Model Link SL options
are part of the config set
R2012a: Model Link TL options
have been ported to the config
set
35
Customizable Filters for RTE Details
RTE Filters for report
select which RTE checks will
appear (or not)
Interface to customize
content
Note:
Customization available with a MATLAB report license.
36
A lot more happened in Polyspace R2012a
Results review
–
–
–
–
Enhanced handling of absolute addresses
Suppress red checks consequence of other reds
Data-range workflow improvements
Improve precision on memset(0) and arrays
Polyspace Metrics
– Architecture of projects by “Modules”
Easy Launching
– Critical sections improvement
– Environment templates
37
A lot more happened in Polyspace R2012a
Model Link
–
–
–
–
Deeper integration in Simulink
Enhanced support of ranges in Simulink constructs
More flexibility on model-reference
Support of dSpace blockset 3.1
Coding rules
– MISRA AC-AGC support
– –allowed-pragmas option
Report Generation
– Customization
38
Polyspace
State of the art static and semantic code verification
BE THERE: Wednesday, 18 April, 11:30 @ MAC
Freedom from Run-Time Errors for AUTOSAR-Based ECU Software
Alexander Much and Thomas M. Galla, Elektrobit Automotive GmbH
Thank you!
Learn more, view demos, request trial, …
mathworks.com/products/polyspace
© 2012 The MathWorks, Inc.
39
© Copyright 2024