Day4 English 2017 0509

ISO 26262 TRAINING
Day 4 – Confidence in the use of SW-tools – Wrap up

CONTENTS
1. Confidence in the use of SW-tools

a. Introduction
b. Classification of SW-tools
c. Qualification of SW-tools
d. Training exercise
2. SW Component Qualification
3. Software Configuration
4. Hardware-Software Interface Specification
5. Wrap up
a. Training Summary
b. Comments, Questions and Discussion
ISO 26262 Training - Day 4 © SGS-TÜV Saar GmbH 2017 ALL RIGHTS RESERVED 2
CONTENTS

a. Introduction
5. Wrap up
a. Training Summary
INTRODUCTION
(ISO 26262-8, Chapter 11)

 SW Tools used in safety-related development,
requires confidence in their intended usage.
 A SW Tool is confident, if it fulfils the qualification
requirements at the dedicated “Tool Confidence
Level (TCL)”.
 Aims:
 Provision of criteria to determine the
required degree of confidence in the
software tool.
 Provision of measures to qualify software
tools in order to generate confidence in the
tool so that it fits the activities and tasks
required by ISO 26262.
 Considerations about the used tools are part of the safety plan
CONFIDENCE IN THE USE OF
SOFTWARE TOOLS - ACTIVITIES
Activities:
 Planning and utilization of the software tools, including
 Identification and version
 Configuration
 Use cases
 Ambient conditions in which the software tool will be used
 Pre-determined maximum ASIL
 Methods selection
 Analysis of the software tool, including
 Intended purpose
 Input and expected output
 Limitations
 Classification of the tool with a Tool Confidence Level (TCL)
CONTENTS

a. Introduction
5. Wrap up
a. Training Summary
SOFTWARE TOOLS – TCL
ASSIGNEMENT
Tool Impact (TI)
 TI1: Tool has no impact on safety-relevant functions
 TI2: Otherwise
Tool Error Detection (TD)
 TD1: High confidence that measures to avoid and control faults are
effective, i.e. faults, which are introduced in the product by the tool, will be
detected.
 TD2: Medium confidence that measures to avoid and control faults are
effective
TD1 TD2 TD3
 TD3: Otherwise
TI1 TCL1 TCL1 TCL1
 Tools with TCL1 requires
no qualification. TI2 TCL1 TCL2 TCL3
 The confidence is defined by two parameters,

Tool Impact (TI) and Tool error Detection (TD)
EXAMPLE
 Example: Editor “Notepad“

 Step 1: Documentation:
 Official name: “Microsoft Editor“,
 Used Version: 5.1
(Build 2600.xpsp_sp3_qfe.120504-1617: Service Pack 3)
 Use Case: Editing of text file, which is used for documentation of
development.
 Used during “unit development“ phase
 Configuration: Standard configuration (Tool and environment) is used (refer
to IT-document 123.456).
 Step 2: Classification:
 Impact on safety-related product: wrong documentation could lead to wrong
implementation, therefore TI2
 Error detection: High confidence, because two different kind of reviews
processed (refer to process description xyz), therefore TD1
 Result: TCL1 no further qualification is needed.
CONTENTS

a. Introduction
5. Wrap up
a. Training Summary
PART 8, CLAUSE 11
SOFTWARE TOOLS – QUALIFICATION
 Conditions for qualification at TCL2 and TCL3:

TCL 2 TCL3
ASIL ASIL
Method
A B C D A B C D
1a Increased confidence from use ++ ++ ++ + ++ ++ + +
1b Evaluation of the tool development process ++ ++ ++ + ++ ++ + +
1c Validation of the software tool + + + ++ + + ++ ++
1d Development in accordance with a safety standard + + + ++ + + ++ ++
Reference: ISO 26262-8, §11.4.6.1 Tables 4 & 5
 Qualification measures only needed, if TCL1 cannot be ensured

by error protection and detection activities in the project flow
 1a Increased confidence from use of the SW tool

 Documentation of the use in different projects
 Documentation of the time span, where the tool is used in
the same version
 Available support by the tool supplier (e.g. bug fixing,
hotline)
 Only feasible up to ASIL C (TCL2) or even only ASIL B
(TCL3)
 Typically used for commercial SW-tools
 Problem: Quick changes of versions (e.g. compiler)
 1b Evaluation of tool development processes

 The development of the SW-tool has to follow a planned
development process, which ensures QM
 Typically used from SW-tool suppliers, who have a
certified QM
 Only feasible up to ASIL C (TCL2) or even only ASIL B
(TCL3)
 Problem: Typically does not work with company internal
tools (e.g. self written macros)
 1c Validation of the software tool

 Confidence by testing  needs a detailed specification
and corresponding test plan
 Typically used for company internal developed SW-tool
(e.g. Excel sheets with macros)
 Feasible up to ASIL D
 Problem: Big effort, not typically feasible for commercial
SW-tools
 1d Developed in accordance with a

safety standard
 Means to be developed acc. ISO 26262-6 or
IEC 61508-3 or DO178B or others
 Typically used for commercial tools, which
are certified acc. to the relevant safety
standard
 Feasible up to ASIL D
 Problem: Big effort, only feasible for
commercial tool providers
 In many cases the best solution is to combine qualification of the SW tool
and error detection capability in the development flow
CONTENTS

a. Introduction
5. Wrap up
a. Training Summary
DAY 4
EXERCISE
 Form groups with 3-5

participants
 Describe one of your typically
used SW-tools
 Classify one of your tools with
Tool Confidence Level (TCL)
 Is it always necessary to
qualify the tool?
 Document your results and
explain it to the other groups
SUMMARY OF DAY 4
CONFIDENCE IN THE USE OF SW-
TOOLS
 Considerations about used software tools are part of the

safety plan
 The confidence is defined by two parameters, Tool Impact (TI)
and Tool error Detection (TD)
 Qualification measures only needed, if TCL1 cannot be
ensured by error protection and detection activities in the
project flow
 In many cases the best solution is to combine qualification of
the SW tool and error detection capabilities in the development
flow
CONTENTS

a. Introduction
5. Wrap up
a. Training Summary
PART 8, CLAUSE 12
QUALIFICATION OF SOFTWARE
COMPONENTS
 Provide evidence for the suitability of software components for

re-use in items developed in compliance with ISO 26262
 Re-use of qualified software components avoids re-

development for software components with similar or identical
functionality
PART 8, CLAUSE 12
QUALIFICATION OF SOFTWARE
COMPONENTS
 Detailed specification of the SW component

 Source code, models, libraries from third-party suppliers, etc.
 Proof of verification
 Requirements coverage according to
ISO 26262-6
 Normal operation and behavior in case of errors
 Analysis of failures (e.g. runtime errors)
 Valid only with an implementation without modifications
 Additional requirements for ASIL D
 Proof of “structural coverage” according to ISO 26262
 May require additional tests which demonstrate the structural
coverage
 Often used SW-components are typically qualified by validation tests

CONTENTS

a. Introduction
5. Wrap up
a. Training Summary
PARAMETRIZED SOFTWARE (PART 6,
ANNEX C)
Configurable software enables the development of application specific software

using configuration and calibration data
Parametrization of the
software build process
uses configuration data.
Parametrization after the

software is built uses
calibration data.
ANNEX C)
26262 definitions: configuration / calibration
--- NON INTUITIVE ---
Configuration data
Data that is assigned during software build and that controls the software build
process
EXAMPLE Pre-processor instructions; software build scripts (e.g. XML configuration files).
Calibration data
Data that will be applied after the software build in the development process
EXAMPLE Parameters (e.g. value for low idle speed, engine characteristic diagrams); vehicle specific
parameters (adaptation values) (e.g. limit stop for throttle valve); variant coding (e.g. country code, left-
hand/right-hand steering).
ANNEX C)
Minimized effort for similar projects (simplified software safety lifecycle)
First application Subsequent

specific application
development: All Part 6
specific
configuration
Extra effort for and calibration:
developing
configurable Reduced effort
software by not having
to repeat the
complete life
Alternative cycle
ANNEX C)
Mechanisms for the detection of unintended changes of data
• Apply mechanisms for the detection of unintended changes of data as listed in

Table C.1 to detect unintended changes of safety-related calibration data:
• The ASIL of the calibration data shall equal the highest ASIL of the software safety
requirements it can violate.
CONTENTS

a. Introduction
5. Wrap up
a. Training Summary
PART 4, CLAUSE 7.4.6
HARDWARE-SOFTWARE INTERFACE
SPECIFICATION (HSI)
 HSI shall specify the
hardware and software
interaction and be
consistent with the
technical safety concept
 HSI shall include

component's hardware
devices that are
controlled by software
and hardware resources
that support the
execution of software
 HSI acts as the linkage

between the different
phases of development
 Getting agreements on
topics relevant to ISO 26262-4: Annex B, Figure B.1
hardware and software
PART 4, CLAUSE 7.4.6
SPECIFICATION (HSI)
HSI should consider the following Characteristics of hardware-software
hardware-software interface elements: interface:
a) memory: a) interrupts;
1) volatile memory (e.g. RAM);
b) timing consistency;
2) non-volatile memory (e.g. NvRAM);
c) data integrity;
b) bus interfaces [e.g. controller area network
(CAN), local interconnect network (LIN), internal d) initialization:
high-speed serial link (HSSL)]; 1) memory and registers;
2) boot management;
c) converter:
1) A/D converter; e) message transfer:
2) D/A converter; 1) send message;
3) pulse-width modulation (PWM); 2) receive message;
d) multiplexer; f) network modes:
1) sleeping;
e) electrical I/O;
2) awakening;
f) watchdog:
g) memory management:
1) internal;
2) external.
h) real-time counter
SPECIFICATION (HSI)
 The HSI Specification shall be refined sufficiently to:

 Allow for the correct control and usage of the hardware by
the software, and
 Describe each safety-related dependency between hardware
and software.
 The persons responsible for hardware and software
development shall be jointly responsible for the verification
of the adequacy of the refined HSI specification coverage
External Internal/ External
Accelerator Pedal Sensor Source
Powertrain Controller Sink
ISO 26262 Training - Day 1

J5 Board Designator
APP Informal Designator Name
APP1_IN Signal Name (Unique Reference)
3 Pin
Input Direction (Input/ Output)
Signal Type
Analog
Y
Safety Related?
Brief
Description
Pedal Sensor
Input Voltage 1
from Accelerator Signal Range
0-4
4-10
-10-0
V
V
V
Signal Unit
1% Signal Tolerance (+/- %)
1%
1%
SPECIFICATION (HSI)
Low
High
Interpreted Condition/ State

Out of
Out of
Range
Range
Norma
l range
4
0
Interpreted Range
0-4
V
V
V
Interpreted Unit
Y
Y
Y
Detectable Fault?
Notes/ Comments
© SGS-TÜV Saar GmbH 2017 ALL RIGHTS RESERVED
30
CONTENTS

a. Introduction
5. Wrap up
a. Training Summary
THE BUILDING STONES
OF FUNCTIONAL SAFETY
CONTENTS

a. Introduction
5. Wrap up
a. Training Summary
CONTACT GCC FS
Munich, Germany (Headquarters)

SGS-TÜV Saar GmbH
Functional Safety
Hofmannstrasse 50, Phone +49 89 787475-280
D-81379 Munich fs@sgs.com
Dortmund, Germany (Branch Office)

SGS-TÜV Saar GmbH
Joseph-von-Fraunhofer-Str. 13, Phone +49 231 9742-7323
D-44227 Dortmund de.do.fs@sgs.com
Japan
SGS Japan Inc.
2-2-1, Minatomirai, Nishi-ku
The Landmark Tower Yokohama 38F Phone +81 45 330 5040
220-8138 Yokohama jp.fs@sgs.com
CONTACT KVA
Greenville, SC (Headquarters) Royal Oak, MI

1708-C Augusta Street, Suite 3 108 S. Main Street, Unit C
Greenville, SC 29605 Royal Oak, MI 48067
Jody Nelson Lauren Frost

Managing Partner, kVA lauren.frost@kvausa.com
jody.nelson@kvausa.com
Phone +1.786.999.8264
Bill Taylor
Managing Partner, kVA
bill.taylor@kvausa.com
Phone +1.864.633.9554
AFSP Seminar – Module K2 © SGS-TÜV Saar GmbH 2017 ALL RIGHTS RESERVED 35

Day4 English 2017 0509

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

Day4 English 2017 0509

Uploaded by

Copyright:

Available Formats

ISO 26262 TRAINING

Day 4 – Confidence in the use of SW-tools – Wrap up

1. Confidence in the use of SW-tools

1. Confidence in the use of SW-tools

(ISO 26262-8, Chapter 11)

1. Confidence in the use of SW-tools

 The confidence is defined by two parameters,

 Example: Editor “Notepad“

1. Confidence in the use of SW-tools

 Conditions for qualification at TCL2 and TCL3:

1a Increased confidence from use ++ ++ ++ + ++ ++ + +

1b Evaluation of the tool development process ++ ++ ++ + ++ ++ + +

1c Validation of the software tool + + + ++ + + ++ ++

1d Development in accordance with a safety standard + + + ++ + + ++ ++

Reference: ISO 26262-8, §11.4.6.1 Tables 4 & 5

 Qualification measures only needed, if TCL1 cannot be ensured

 1a Increased confidence from use of the SW tool

 1b Evaluation of tool development processes

 1c Validation of the software tool

 1d Developed in accordance with a

1. Confidence in the use of SW-tools

 Form groups with 3-5

 Considerations about used software tools are part of the

1. Confidence in the use of SW-tools

 Provide evidence for the suitability of software components for

 Re-use of qualified software components avoids re-

 Detailed specification of the SW component

 Often used SW-components are typically qualified by validation tests

1. Confidence in the use of SW-tools

Configurable software enables the development of application specific software

Parametrization after the

First application Subsequent

Mechanisms for the detection of unintended changes of data

• Apply mechanisms for the detection of unintended changes of data as listed in

1. Confidence in the use of SW-tools

 HSI shall include

 HSI acts as the linkage

 The HSI Specification shall be refined sufficiently to:

Accelerator Pedal Sensor Source

Powertrain Controller Sink

ISO 26262 Training - Day 1

APP Informal Designator Name

APP1_IN Signal Name (Unique Reference)

Input Direction (Input/ Output)

Interpreted Condition/ State

1. Confidence in the use of SW-tools

1. Confidence in the use of SW-tools

Munich, Germany (Headquarters)

Dortmund, Germany (Branch Office)

Greenville, SC (Headquarters) Royal Oak, MI

Jody Nelson Lauren Frost

You might also like