Вы находитесь на странице: 1из 145

ISO 26262 TRAINING

Day 3 Hardware Development Software Development

CONTENTS

 
  • 1. Hardware Development

 
  • a. Overview

  • b. Hardware Safety Requirements

  • c. Hardware Design

  • d. Evaluation of Hardware Metrics

  • e. Hardware Tests

  • 2. Software Development

  • a. Overview

  • b. Software Safety Requirements

  • c. Software Architecture and Design

  • d. Software Integration and Tests

ISO 26262 Training - Day 3

© SGS-TÜV Saar GmbH 2017 ALL RIGHTS RESERVED

2

CONTENTS

 
  • 1. Hardware Development

 
  • a. Overview

  • b. Hardware Safety Requirements

  • c. Hardware Design

  • d. Evaluation of Hardware Metrics

  • e. Hardware Tests

  • 2. Software Development

  • a. Overview

  • b. Software Safety Requirements

  • c. Software Architecture and Design

  • d. Software Integration and Tests

ISO 26262 Training - Day 3

© SGS-TÜV Saar GmbH 2017 ALL RIGHTS RESERVED

3

CONSIDERED PARTS ISO 26262 Training - Day 3 © SGS-TÜV Saar GmbH 2017 ALL RIGHTS RESERVED
CONSIDERED PARTS
ISO 26262 Training - Day 3
© SGS-TÜV Saar GmbH 2017 ALL RIGHTS RESERVED
4

RESPONSIBILITIES AND TARGETS

Responsibilities

  • The hardware development phase typically is in the responsibility of the hardware suppliers ( also Chip supplier, IP supplier), who have the knowledge for the implementation of safety mechanisms at hardware level

 
  • Chip and IPs can be either developed as so called Safety Element out of Context (SEooC) or in line with given customer requirements as Safety Element in Context (SEiC)

Targets

  • In the hardware development phase an electronic circuit is designed in accordance with the required safety integrity of safety requirements derived from the system development phase. The evaluation of the achieved safety integrity is done by calculation of probabilistic hardware metrics.

 Functional Safety of hardware is mainly based on the evaluation of probabilistic metrics
Functional Safety of hardware is mainly based on the evaluation of
probabilistic metrics

ISO 26262 Training - Day 3

© SGS-TÜV Saar GmbH 2017 ALL RIGHTS RESERVED

5

GENERAL WORKFLOW DURING THE HARDWARE DEVELOPMENT PHASE

In Context development

Out of context development

System develop. acc. ISO 26262-4 Application assumption document Technical Safety Concept Assumptions for technical safety requirements
System develop. acc. ISO 26262-4
Application assumption document
Technical Safety
Concept
Assumptions for technical
safety requirements and
component design
Input
Initiation of the
Hardware Development
Input
Hardware Safety
Requirements
Specification
Hardware Design
Design Verification
Hardware Tests
ISO 26262 Training - Day 3
© SGS-TÜV Saar GmbH 2017 ALL RIGHTS RESERVED

INITIATION OF HW-DEVELOPMENT

 

Definition of scope of development

 
   
 

Development type

 

Safety Element out of Context Safety Element in Context

 

In case of SEooC

 

Use “Application Assumptions” as input

 

In case of SEiC

 

Use Component Design (TSC) from customer as input

 

Identification of development category

 
 

New, Modification, Reuse

In case of modification or reuse there shall be a delta analysis, which identifies possible impacts on Functional Safety

Only the safety relevant changes have to be considered

Tailoring of activities

ISO 26262 Training - Day 3

© SGS-TÜV Saar GmbH 2017 ALL RIGHTS RESERVED

7

CONTENTS

 
  • 1. Hardware Development

 
  • a. Overview

  • b. Hardware Safety Requirements

  • c. Hardware Design

  • d. Evaluation of Hardware Metrics

  • e. Hardware Tests

  • 2. Software Development

  • a. Overview

  • b. Software Safety Requirements

  • c. Software Architecture and Design

  • d. Software Integration and Tests

ISO 26262 Training - Day 3

© SGS-TÜV Saar GmbH 2017 ALL RIGHTS RESERVED

8

ALLOCATION OF HW REQUIREMENTS

Technical Safety Concept System Element

Recon- cilement of HSI HW specification SW specification The interface between hardware and software has to
Recon-
cilement
of
HSI
HW specification
SW specification
The interface between hardware and software has to be clarified
ISO 26262 Training - Day 3
© SGS-TÜV Saar GmbH 2017 ALL RIGHTS RESERVED
9

DERIVATION OF

HW-SAFETY REQUIREMENTS

DERIVATION OF HW-SAFETY REQUIREMENTS HW-Safety Requirements Circuit level HW-Safety Requirements Block level Refinement Hardware Development 1
HW-Safety Requirements Circuit level
HW-Safety
Requirements
Circuit level
HW-Safety Requirements Block level
HW-Safety
Requirements
Block level
Refinement
Refinement

Hardware Development

   
           
 

1

2

3

   
   

4

 

1

5

2

6

3

   
       

1

 

2

   

3

   

7

 

4

8

5

9

6

 

Part

   

7

4

 

8

5

 

9

6

     

Part

7

 

8

 

9

 
   

Part

   

Block design

VBAT Supply HS Driver Driver INP Input Control Control ENB LS Diagnostics Driver GND IC
VBAT
Supply
HS
Driver
Driver
INP
Input Control
Control
ENB
LS
Diagnostics
Driver
GND
IC

(e.g. IC / IP)

HW-Circuit

HW-Safety Requirements Circuit level HW-Safety Requirements Block level Refinement Hardware Development 1 2 3 4 1
HW-Safety Requirements Circuit level HW-Safety Requirements Block level Refinement Hardware Development 1 2 3 4 1
HW-Safety Requirements Circuit level HW-Safety Requirements Block level Refinement Hardware Development 1 2 3 4 1

Design

Out2

Out1

(or system safety requirements from customer)

Refinement
Refinement

System Assumptions

Component Design

  • Input

HW-Safety Requirements Circuit level HW-Safety Requirements Block level Refinement Hardware Development 1 2 3 4 1

(TSC)

Power

Out

put

© SGS-TÜV Saar GmbH 2017 ALL RIGHTS RESERVED

ISO 26262 Training - Day 3

10
10

HARDWARE SAFETY REQUIREMENTS

EXAMPLE INTRODUCTION

 
  • The refinement of the already

 

allocated component safety

requirements of the training

example is introduced

 
 Input requirements are taken
  • Input requirements are taken

from the TSC

ISO 26262 Training - Day 3

© SGS-TÜV Saar GmbH 2017 ALL RIGHTS RESERVED

11

CONTENTS

 
  • 1. Hardware Development

 
  • a. Overview

  • b. Hardware Safety Requirements

  • c. Hardware Design

  • d. Evaluation of Hardware Metrics

  • e. Hardware Tests

  • 2. Software Development

  • a. Overview

  • b. Software Safety Requirements

  • c. Software Architecture and Design

  • d. Software Integration and Tests

ISO 26262 Training - Day 3

© SGS-TÜV Saar GmbH 2017 ALL RIGHTS RESERVED

12

HARDWARE DESIGN

 Hardware Design is derived from:  Component Design (TSC)  HW safety requirements  Hardware
Hardware Design is derived from:
Component Design (TSC)
HW safety requirements
Hardware Design consists of:
Circuit diagram / circuit design of the particular system element
Assembly diagram(Layout)
Bill Of Material (BOM)
Hardware Design is generated in collaboration with the
Software Design
Hardware safety requirements are a refinement
of component safety requirements
ISO 26262 Training - Day 3
© SGS-TÜV Saar GmbH 2017 ALL RIGHTS RESERVED
13

HW DESIGN PROPERTIES

ACC. TO ISO 26262-5

       
 

ASIL

     
 

Properties

A

B

C

D

1

Hierarchical design

 

+

+

+

+

2

Precisely defined interfaces of safety-related hardware components

++

++

++

++

3

Avoidance of unnecessary complexity of interfaces

 

+

+

+

+

4

Avoidance

of

unnecessary

complexity

of

hardware

       

components

+

+

+

+

5

Maintainability (service)

 

+

+

++

++

6

Testability a

+

+

++

++

a Testability includes testability during development and operation.

 

Source: ISO 26262-5, Table 2

 
 There are no detailed hardware design rules from ISO 26262-5
There are no detailed hardware design rules from ISO 26262-5

ISO 26262 Training - Day 3

 

© SGS-TÜV Saar GmbH 2017 ALL RIGHTS RESERVED

14

HARDWARE DESIGN

EXAMPLE INTRODUCTION

 

Introduction of possible

 
 

hardware design for the

example component

 
 Introduction of possible hardware design for the example component ISO 26262 Training - Day 3

ISO 26262 Training - Day 3

© SGS-TÜV Saar GmbH 2017 ALL RIGHTS RESERVED

15

CONTENTS

 
  • 1. Hardware Development

 
  • a. Overview

  • b. Hardware Safety Requirements

  • c. Hardware Design

  • d. Evaluation of Hardware Metrics

  • e. Hardware Tests

  • 2. Software Development

  • a. Overview

  • b. Software Safety Requirements

  • c. Software Architecture and Design

  • d. Software Integration and Tests

ISO 26262 Training - Day 3

© SGS-TÜV Saar GmbH 2017 ALL RIGHTS RESERVED

16

DEFINITIONS

  • Fault

 
 

abnormal condition that can cause an element or an item to fail

  • Error

 

discrepancy between a computed, observed or measured value or condition and the true, specified, or theoretically correct value or condition

  • Failure

 

termination of the ability of an element or an item to perform a function as required

ISO 26262 Training - Day 3

© SGS-TÜV Saar GmbH 2017 ALL RIGHTS RESERVED

17

DIFFERENCE:

FAULT – ERROR - FAILURE ISO 26262-10, Figure 5 ISO 26262 Training - Day 3 ©
FAULT – ERROR - FAILURE
ISO 26262-10, Figure 5
ISO 26262 Training - Day 3
© SGS-TÜV Saar GmbH 2017 ALL RIGHTS RESERVED
18

MORE DEFINITIONS

 
  • safety related element

 

element which has the potential to contribute to the violation or

 

achievement of a safety goal

 
  • safety mechanism

Function implemented by E/E elements, or by other

 

technologies, to detect faults or control failures in order to

achieve or maintain a safe state

ISO 26262 Training - Day 3

© SGS-TÜV Saar GmbH 2017 ALL RIGHTS RESERVED

19

RANDOM HARDWARE FAULT CATEGORIES ISO 26262-5, Figure B.1  Random hardware faults are categorized acc. to
RANDOM HARDWARE FAULT CATEGORIES
ISO 26262-5, Figure B.1
Random hardware faults are categorized
acc. to their impact on each safety goal
ISO 26262 Training - Day 3
© SGS-TÜV Saar GmbH 2017 ALL RIGHTS RESERVED
20

SAFE FAULT

 
  • Fault, which do not increase the probability of a safety goal violation significant.

 
  • Independent multiple faults with order >2 (e.g. three time faults, four times faults, etc.) are

classified as „safe faults“.

ISO 26262 Training - Day 3

© SGS-TÜV Saar GmbH 2017 ALL RIGHTS RESERVED

21

SINGLE POINT FAULT

 
  • Fault in a HW element, which is not detected by a

 

„safety mechanism“ and therefore leads directly to

a safety goal violation.

  • A „single point fault“ is only permissible in case of

safety goals with ASIL C and D classification, if

it’s probability is low and it’s improbable occurrence is safeguarded by „dedicated“ measures (e.g. a burn in test).

ISO 26262 Training - Day 3

© SGS-TÜV Saar GmbH 2017 ALL RIGHTS RESERVED

22

EXAMPLE „SINGLE POINT FAULT“

Example: Microcontroller with external Watchdog

The microcontroller shall activate the Output, if Input 1 has the state low and Input 2
The microcontroller shall activate the Output, if Input 1 has the state low and Input 2 the state high.
Input 1
IN_1
Failure mode
“stuck-at high” at A3 is a
“single point fault”
Input 2
IN_2
Microcontroller
Input 3
IN_3
A1
A3
Output
SPI
&
A2
External
ok
Window
Safety related
HW elements
Watchdog
Failure mode
Non-safety related
HW elements
“short-circuit” at Output
driver is a “single point
fault”
ISO 26262 Training - Day 3
© SGS-TÜV Saar GmbH 2017 ALL RIGHTS RESERVED
23

RESIDUAL FAULT

 
  • Fault-fraction in a Hardware element, which is not covered by diagnosis (diagnosis slip >0%) and immediately leads to a safety goal violation.

 
  • A diagnostic coverage of less than 90% is only

permissible in case of safety goals with ASIL C

and D classification, if the improbable occurrence of the residual fault is safeguarded by „dedicated“ measures (e.g. a burn in test).

ISO 26262 Training - Day 3

© SGS-TÜV Saar GmbH 2017 ALL RIGHTS RESERVED

24

EXAMPLE „RESIDUAL FAULT“

Example: Microcontroller with external Watchdog

The microcontroller shall activate the Output, if Input 1 has the state low and Input 2
The microcontroller shall activate the Output, if Input 1 has the state low and Input 2 the state high.
“residual faults” are failure modes of µC,
Input 1
IN_1
Input 2
which are only partly covered by
implemented diagnosis measures
(e.g. RAM test, external Watchdog).
IN_2
Microcontroller
Input 3
IN_3
A1
A3
Output
SPI
&
A2
External
ok
Window
Safety related
HW elements
Watchdog
Non-safety related
HW elements
ISO 26262 Training - Day 3
© SGS-TÜV Saar GmbH 2017 ALL RIGHTS RESERVED
25

DUAL POINT FAULT

 
  • Fault, which leads in association with an additional fault to a safety goal.

 
  • A combination of safety goal violating Hardware fault and a Hardware fault, which leads to a

loss/malfunction of the according safety mechanism is classified as „dual point fault“.

ISO 26262 Training - Day 3

© SGS-TÜV Saar GmbH 2017 ALL RIGHTS RESERVED

26

EXAMPLE „DUAL POINT FAULT“

Example: Microcontroller with external Watchdog

The microcontroller shall activate the Output, if Input 1 has the state low and Input 2 the state high.

Stuck-at low: dual point fault Input 1 IN_1 Input 2 AND IN_2 Microcontroller A fault of
Stuck-at low:
dual point fault
Input 1
IN_1
Input 2
AND
IN_2
Microcontroller
A fault of a diagnosis mechanism (Safety
Mechanism) of µC leads in association with
an otherwise diagnosed fault in the µC to a
safety goal violation. It is a “dual point fault”.
Input 3
IN_3
A1
A3
Stuck-at high:
Output
SPI
&
dual point fault
A2
External
ok
Window
Safety related
HW elements
Watchdog
Non-safety related
HW elements
ISO 26262 Training - Day 3
© SGS-TÜV Saar GmbH 2017 ALL RIGHTS RESERVED
27

MULTIPLE POINT FAULT

 
  • The „dual point fault“ is a „multiple point fault“

 
  • „Multiple point faults“ higher order with sufficient independence can be neglected usually(safe fault).

  • If „multiple point faults“ can be identified (e.g. start up test), they are classified as „detected multiple point faults“.

  • If „multiple point faults“ can be detected and controlled by the driver (e.g. defect of the dimmed headlight lamp), They are classified as perceived multiple point faults“.

ISO 26262 Training - Day 3

© SGS-TÜV Saar GmbH 2017 ALL RIGHTS RESERVED

28

EXAMPLE „MULTIPLE POINT FAULT“

Example: Microcontroller with external Watchdog

The microcontroller shall activate the Output, if Input 1 has the state low and Input 2
The microcontroller shall activate the Output, if Input 1 has the state low and Input 2 the state high.
Input 1
IN_1
Input 2
IN_2
Microcontroller
Input 3
IN_3
A1
A3
Output
SPI
&
A2
External
ok
Window
nok
Safety related
HW elements
Watchdog
L1
Non-safety related
HW elements
A fault of the scheduling of the
µC is detected by the
watchdog and the driver is in
formed by L1  detected
multiple point fault
ISO 26262 Training - Day 3
© SGS-TÜV Saar GmbH 2017 ALL RIGHTS RESERVED
29

LATENT FAULT

 
  • A fraction of the “multiple point faults“ is called a

 

„latent fault“, if it can not be detected and is hidden in the system element.

  • A „latent fault“ has the potential to violate a safety

goal (usually the timing is not critically, because it is only relevant in combination with an additional fault, but to analyse for ASIL C and D).

ISO 26262 Training - Day 3

© SGS-TÜV Saar GmbH 2017 ALL RIGHTS RESERVED

30

SUMMARY OF

HW FAULT CATEGORIES

 

Safe fault (l s )

Fault that leads to a safe condition or has no impact on the respective safety goal

Detected multiple point fault (l MPF detected )

Detected multiple fault

No safety goal violation

Perceived multiple point fault (l MPF perc. )

Multiple fault detected by the driver

No safety goal violation

Residual fault (l RF )

Share of undetected single fault due to a non perfect diagnostics

Leads to safety goal violation

Latent multiple point fault (l MPF latent )

Undetected multiple fault or share of undected multiple point fault due to non perfect diagnostics

Leads to safety goal violation

Single point fault (l SPF )

Undetected single fault

Leads to safety goal violation

  • l total

© SGS-TÜV Saar GmbH 2017 ALL RIGHTS RESERVED

ISO 26262 Training - Day 3

31
31

QUANTITATIVE DESIGN VERIFICATION IN

PRACTICE

 

Step 1:

Verification of „Hardware architecture metrics“

 

Step 2a:

Verification of safety goal violating failure rate referring to the Item

 

Step 2b:

Verification of failure classes per Hardware component

Note: Step 2a and 2b are alternatives

ISO 26262 Training - Day 3

© SGS-TÜV Saar GmbH 2017 ALL RIGHTS RESERVED

32

STEP 1 VERIFICATION OF HARDWARE ARCHITECTURE METRICS

  • Verification of robustness of a HW architecture regarding random Hardware failures

ASIL

Calculation of SPFM ?

Calculation of LFM ?

A

no verification required

no verification required

B

recommended

recommended

C

highly recommended

recommended

D

highly recommended

highly recommended

  • Calculation of „Single Point Fault Metric (SPFM)“ and „Latent Fault Metric (LFM)“

  • ASIL depending target values have to be reached

© SGS-TÜV Saar GmbH 2017 ALL RIGHTS RESERVED

ISO 26262 Training - Day 3

33
33

STEP 1 VERIFICATION OF HARDWARE ARCHITECTURE METRICS

 

Calculation of

 
 

Single Point Fault Metric (SPFM)

 
 Calculation of Single Point Fault Metric (SPFM)  Complement of the relative fraction of single

Complement of the relative fraction of single point faults, which violate a safety goal, related to all possible faults in the safety related Hardware elements of an Item

ISO 26262 Training - Day 3

© SGS-TÜV Saar GmbH 2017 ALL RIGHTS RESERVED

34

STEP 1 VERIFICATION OF HARDWARE ARCHITECTURE METRICS

 

Calculation of

 
 

Latent Fault Metric (LFM)

 
 Calculation of Latent Fault Metric (LFM)  Complement of the relative fraction of latent multiple
 

Complement of the relative fraction of latent multiple point faults, which violate a safety goal, related to all possible multiple point faults in the safety related Hardware elements of an Item.

ISO 26262 Training - Day 3

© SGS-TÜV Saar GmbH 2017 ALL RIGHTS RESERVED

35

STEP 1 VERIFICATION OF HARDWARE ARCHITECTURE METRICS

 

ASIL B

ASIL C

ASIL D

Single Point Fault Metric (SPFM)

>= 90%

>= 97%

>=99%

Latent Fault Metric

     

(LFM)

>= 60%

>= 80%

>= 90%

Use of predecessor design (values must not be worse) Expert Judgement (determination by assessors, for example)

Use of target values from tables 4 and 5

  • 3 ways to establish the target values

ISO 26262-5, Table 4 + 5

Typically used
Typically used

© SGS-TÜV Saar GmbH 2017 ALL RIGHTS RESERVED

ISO 26262 Training - Day 3

36
36

DAY 2

EXERCISE 1

 
  • Go back to the TSC from Day 2

 
  • Are the defined target values

for SPFM and LFM correct?

 
 Go back to the TSC from Day 2  Are the defined target values for

ISO 26262 Training - Day 3

© SGS-TÜV Saar GmbH 2017 ALL RIGHTS RESERVED

37

STEP 1 VERIFICATION OF HARDWARE ARCHITECTURE METRICS

Totalling up of the fault rate and calculation of the architecture

Determination of diagnostic coverage for residual faults and

Identification of failure modi and their statistical distribution

Classification of fault categories related to the considered

  • 6 activities to determine the architecture metric

Listing of all HW elements (assembly components) and

Identification if a HW element is safety-relevant or not

determination of the base fault rate per HW element

safety goal (safe fault, residual fault etc.)

metrics according to the formula

multiple point faults

1.1 Quantitative design verification 1.2 1.3 1.4 1.5 1.6
1.1
Quantitative design verification
1.2
1.3
1.4
1.5
1.6

© SGS-TÜV Saar GmbH 2017 ALL RIGHTS RESERVED

ISO 26262 Training - Day 3

38
38

STEP 1.1

DETERMINE THE ARCHITECTURE METRIC

  • Listing of all HW elements (assembly components) and

NPRD95, EN50129 Annex C, EN 62061 Annex D, RAC FMD97 und MIL

IEC 62380, SN29500 , MIL HDBK 217 F notice 2, RAC HDBK 217 Plus,

determination of the base fault rate per HW element

Failure rates from recognised industry sources and/or

 Listing of all HW elements (assembly components) and NPRD95, EN50129 Annex C, EN 62061 Annex

Failure rate under reference conditions

manufacturers’ information:

Current dependency Temperature dependency

Voltage dependency

Procedure:

1.1

   
 

1.2

   
 

1.3

   
 

1.4

   
 

1.5

   

1.6

Quantitative design verification

HDBK 338.

λ ref

p

p

p

T

U

I

© SGS-TÜV Saar GmbH 2017 ALL RIGHTS RESERVED

ISO 26262 Training - Day 3

39
39

DAY 2

EXERCISE 2

 

Base failure rates in the

 

example are taken from

SN29500.

 
What impact has the change of
 

What impact has the change of

the assumed operating

temperature?

ISO 26262 Training - Day 3

© SGS-TÜV Saar GmbH 2017 ALL RIGHTS RESERVED

40

STEP 1.2

DETERMINE THE ARCHITECTURE METRIC

  • Identification if a HW element is safety-relevant or not

Per definition a HW element is safety relevant, if it contributes

to a violation or implementation of a safety goal. In other words: The component is part of a signal path of the

safety goal.

1.1

   
 

1.2

   
 

1.3

   
 

1.4

   
 

1.5

   

1.6

Quantitative design verification

© SGS-TÜV Saar GmbH 2017 ALL RIGHTS RESERVED

ISO 26262 Training - Day 3

41
41

DAY 3

EXERCISE 3

 

Please establish whether or not

 

a Hardware component is

safety-relevant regarding the safety goal 1.

 
Give reasons for your choice.

Give reasons for your choice.

ISO 26262 Training - Day 3

© SGS-TÜV Saar GmbH 2017 ALL RIGHTS RESERVED

42

STEP 1.3

DETERMINE THE ARCHITECTURE METRIC

  • Identification of failure modes and their statistical distribution

Failure mode “Functional” refers to the specified function of the

E.g. for a resistor the failure modi “short, open and drift” must

IEC 62061: 2005, Annex D (IEC 62061: „Safety of machinery – Functional

safety of safety-related electrical, electronic and programmable electronic

A. Birolini: e.g. „Reliability Engineering - Theory and Practice”.

Hardware component (e.g. Filter, amplifier etc.) Possible resources

 Identification of failure modes and their statistical distribution Failure mode “Functional” refers to the specified

Example from Birolini:

control systems”)

be looked at.

1.1

   
 

1.2

   
 

1.3

   
 

1.4

   
 

1.5

   

1.6

Quantitative design verification

© SGS-TÜV Saar GmbH 2017 ALL RIGHTS RESERVED

ISO 26262 Training - Day 3

43
43

DAY 3

EXERCISE 4

 

Complete the missing failure modes in the template.

 
 
Complete the missing failure modes in the template. ISO 26262 Training - Day 3 © SGS-TÜV

ISO 26262 Training - Day 3

© SGS-TÜV Saar GmbH 2017 ALL RIGHTS RESERVED

44

STEP 1.4

DETERMINE THE ARCHITECTURE METRIC

Is there a possibility to detect or identity the slipping „multiple point

Determination of fault effects per safety goal in following

  • Classification of random HW-fault categories

Safety goal violation in combination with a failure, which slips

Is there a possibility of failure detection and control by safety

Direct safety goal violation as single point failure?

through the safety mechanism?

fault” and to control it?

mechanism?

sequence:

1.1

   
 

1.2

   
 

1.3

   
 

1.4

   
 

1.5

   

1.6

Quantitative design verification

© SGS-TÜV Saar GmbH 2017 ALL RIGHTS RESERVED

ISO 26262 Training - Day 3

45
45

DAY 3

EXERCISE 5

 
  • Classify the „Fault categories“

 

regarding the safety goal 1 in

the example project (some examples).

 
 In a first step, check whether
 
  • In a first step, check whether

the considered fault has the

potential to become a single

point fault

 
  • In a second step, check

 

whether the considered fault

has the potential to become a latent fault

ISO 26262 Training - Day 3

© SGS-TÜV Saar GmbH 2017 ALL RIGHTS RESERVED

46

STEP 1.5

DETERMINE THE ARCHITECTURE METRIC

Safety Detects in range failures Sensor Rationality Check D.2.10.3 Medium Low  DC =60% Medium 
Safety
Detects in range failures
Sensor Rationality Check
D.2.10.3
Medium
Low  DC =60%
Medium  DC = 90%
High  DC = 99%
Test pattern
High
mechanism/measure
See overview of
techniques
Typical diagnostic
coverage considered
achievable
Notes
Failure detection by
on-line monitoring
D.2.1.1
Low
Sensor Correlation
Detects shorts to ground or
Low
D.2.10.1
Sensor Valid Range
diagnostic test interval
Only if dataflow changes within
High
D.2.6.5
redundancy)
(1oo2, 2oo3 or better
Input comparison/voting
-
High
D.2.6.1
power and some open circuits
Depends on diagnostic coverage
of failure detection
D.2.10.2
  • Determination of the reachable Diagnostic Coverage in accordance with the safety mechanism, which is defined in the TSC, for Residual Faults and Detected Multiple Point Faults.

Refer also to ISO26262-5, annex D

Example table ISO 26262-5, D.11

1.1

   
 

1.2

   
 

1.3

   
 

1.4

   
 

1.5

   

1.6

Quantitative design verification

© SGS-TÜV Saar GmbH 2017 ALL RIGHTS RESERVED

ISO 26262 Training - Day 3

47
47

DAY 3

EXERCISE 6

 

Which diagnostic coverage

 
 

may be assumed for the used

diagnostic measure (safety mechanism)?

 
 Which diagnostic coverage may be assumed for the used diagnostic measure (safety mechanism)? ISO 26262

ISO 26262 Training - Day 3

© SGS-TÜV Saar GmbH 2017 ALL RIGHTS RESERVED

48

STEP 1.6

DETERMINE THE ARCHITECTURE METRIC

  • Totalling up of the fault rates and metric calculation

Fill in the sums in the formulas for SPFM and LFM.

Comparison with the required target values

If necessary, optimize the HW architecture

Totalling up failure rates per failure mode

1.1

   
 

1.2

   
 

1.3

   
 

1.4

   
 

1.5

   

1.6

Quantitative design verification

© SGS-TÜV Saar GmbH 2017 ALL RIGHTS RESERVED

ISO 26262 Training - Day 3

49
49

DAY 3

EXERCISE 7

 
  • Determine the „SPFM“ and

 

„LFM“ for the example

component (system).

 
 Can the defined target values
 
  • Can the defined target values

be reached?

  • What could be done, if the

target values are not reached?

ISO 26262 Training - Day 3

© SGS-TÜV Saar GmbH 2017 ALL RIGHTS RESERVED

50

STEP 2A VERIFICATION OF SAFETY GOAL VIOLATING FAILURE RATE

  • In a second step the “absolute” safety goal violating failure

  • Determination of the failure rate of an item, which are caused by random Hardware faults and violate a safety goal.

ASIL

When to do?

A

no verification required

B

verification recommended

C

verification highly recommended

D

verification highly recommended

  • rate of an item has to be evaluated
    Determination of PMHF values (Probabilistic Metric of random Hardware Failures).

© SGS-TÜV Saar GmbH 2017 ALL RIGHTS RESERVED

ISO 26262 Training - Day 3

51
51

STEP 2A VERIFICATION OF SAFETY GOAL VIOLATING FAILURE RATE

3 ways to establish the target values

   

Use of predecessor design for orientation (values must not be worse)

Typically used
Typically used

Expert Judgement (determination by assessors, for example)

Use of target values from table 6

 
 ISO 26262 establishes target values for the calculation of PMHF
ISO 26262 establishes target values for the calculation of PMHF

ISO 26262 Training - Day 3

© SGS-TÜV Saar GmbH 2017 ALL RIGHTS RESERVED

52

STEP 2A VERIFICATION OF SAFETY GOAL VIOLATING FAILURE RATE

ASIL

Random hardware failure target values (RHFT)

D

< 10 -8 h -1

C

< 10 -7 h -1

B

< 10 -7 h -1

cumulative safety target-violating fault rate of all HW elements of an item within the respective safety goal meets the stated values in the table

For each safety goal it must be demonstrated that the

  • Target values for verification of PMHF

(compare PFH value acc. to IEC 61508)

ISO 26262-5, table 6

© SGS-TÜV Saar GmbH 2017 ALL RIGHTS RESERVED

ISO 26262 Training - Day 3

53
53

DAY 3

EXERCISE 8

 
  • Go back to the TSC from Day 2

 
  • Why is there a budget given for

 
the PMHF of the example component?

the PMHF of the example component?

ISO 26262 Training - Day 3

© SGS-TÜV Saar GmbH 2017 ALL RIGHTS RESERVED

54

STEP 2A VERIFICATION OF SAFETY GOAL VIOLATING FAILURE RATE

Note: This formula will be deleted in Edition 2 and substituted by more detailled considerations

M PMHF = Sl SPF + Sl RF + 0,5 * Sl m,DPF * Sl sm,DPF,latent * T Lifetime

M PMHF is the „value for the probabilistic metric for random hardware failure (PMHF)“ Simplified formula to calculate PMHF (refer to ISO 26262-10) Partioning of latent faults in faults of „mission block (m)“ and „safety mechanism (sm)“

Safety goal violating failure rate

Single point faults

Residual faults

Latent multiple point

faults

Sl SPF

Sl RF

Sl MPF latent

  • Calculation of PMHF acc. to ISO 26262-10

PMHF SPF RF m,DPF sm,DPF,latent Lifetime M is the „value for the probabilistic metric for

© SGS-TÜV Saar GmbH 2017 ALL RIGHTS RESERVED

ISO 26262 Training - Day 3

55
55

STEP 2A VERIFICATION OF SAFETY GOAL VIOLATING FAILURE RATE

Attention: Above formula represents a rough and usually conservative estimation, which is not shown in ISO 26262. We recommend to use instead mathematical models (e.g. quantitative FTA).

Safety goal violating failure rate

Single point faults

Residual faults

Latent multiple point faults

Sl SPF

Sl RF

Sl MPF latent

Considered „common cause“ fraction (acc. IEC61508), typically set at 10%

PMHF = Sl SPF + Sl RF + β * Sl MPF latent

  • Simplified calculation per rough estimation

Attention : Above formula represents a rough and usually conservative estimation, which is not shown in
Attention : Above formula represents a rough and usually conservative estimation, which is not shown in

© SGS-TÜV Saar GmbH 2017 ALL RIGHTS RESERVED

ISO 26262 Training - Day 3

56
56

STEP 2B VERIFICATION OF FAILURE CLASSES PER HARDWARE COMPONENT

  • Alternative method (called „method 2“ ), instead of PMFH- evaluation

  • Reachable failure classes are depended of ASIL and of kind of failure (SPF, RF, LF)

  • Determination of Failure Rate Class (FRC) per HW part

ASIL

When to do?

A

no verification necessary

B

verification recommended

C

verification highly recommended

D

verification highly recommended

© SGS-TÜV Saar GmbH 2017 ALL RIGHTS RESERVED

ISO 26262 Training - Day 3

57
57

STEP 2B VERIFICATION OF FAILURE CLASSES PER HARDWARE COMPONENT

Process for single point faults (SPF and RF)

and DC with respect to residual fault (table 8) Residual fault? Yes No No No No
and DC with respect to residual fault (table 8) Residual fault? Yes No No No No
and DC with respect to
residual fault (table 8)
Residual fault?
Yes
No
No
No
No
Yes
Residual fault?
residual fault (table 8)
and DC with respect to
Meet failure rate class
No
No
Yes
Residual fault?
residual fault (table 8)
and DC with respect to
Meet failure rate class
Meet failure rate class
Single-point fault (table 7) No No Single-point fault (table 7) End Begin Single-point fault? Yes Meet
Single-point fault (table 7)
No
No
Single-point fault (table 7)
End
Begin
Single-point fault?
Yes
Meet failure rate class
Yes
Begin
Single-point fault?
Yes
Meet failure rate class
with respect to
No
with respect to
No
No
with respect to
Yes
End
No
Meet failure rate class
Yes
Single-point fault?
Begin
End
Yes
Single-point fault (table 7)

ISO 26262-5, Figure 3

for dual-point failures

Evaluation procedure

for dual-point failures

Evaluation procedure

Evaluation procedure

for dual-point failures

to mitigate fault

Add safety mechanism

Add safety mechanism

to mitigate fault

Add safety mechanism

to mitigate fault

Improve safety

Improve safety

Improve safety

mechanism

mechanism

mechanism

Yes

Yes

Yes

© SGS-TÜV Saar GmbH 2017 ALL RIGHTS RESERVED

ISO 26262 Training - Day 3

58
58

STEP 2B VERIFICATION OF FAILURE CLASSES PER HARDWARE COMPONENT

  • Process for multiple point faults (LF)

Potential for point failure? Meet failure rate class and DC with respect to latent fault (table
Potential for
point failure?
Meet failure rate class
and DC with respect to
latent fault (table 9)
No
Yes
End
(see ISO26262-9:— ,
Plausible dual-
No
Yes
Begin
Yes
Yes
Begin
Potential for
No
(see ISO26262-9:— ,
Clause 7)
No
Plausible dual-
point failure?
Meet failure rate class
and DC with respect to
latent fault (table 9)
End
Yes
dependent failures ?
No
Yes
dependent failures ?
Clause 7)
No

ISO 26262-5, Figure 4

Evaluation and resolution

of dependent failures

(see ISO26262-9:,

Clause 7)

Evaluation and resolution

of dependent failures

(see ISO26262-9:,

Clause 7)

Add or improve

safety mechanism

Add or improve

safety mechanism

© SGS-TÜV Saar GmbH 2017 ALL RIGHTS RESERVED

ISO 26262 Training - Day 3

59
59

STEP 2B VERIFICATION OF FAILURE RATE CLASSES PER HARDWARE PART

 Definition of failure rate classes failure rate class target value* (FRC) 1 < 10 -10
Definition of failure rate classes
failure rate
class
target value*
(FRC)
1
< 10 -10 h -1
2
< 10 -9 h -1
The values for failure rate class 1
should be smaller than the value for
ASIL D divided by 100.
3
< 10 -8 h -1
i
< 10 -(11-i) h -1
The values for failure rate class 2
should be smaller than the ten-fold
value for failure rate class 1.
* The reference point is the ASIL D
target value from ISO 26262-5, Table 6
The values for failure rate class 3
should be smaller than the hundred-
fold value for failure rate class 1.
ASIL
(RHFT)
The values for failure rate classes >
3 result accordingly.
D
< 10 -8 h -1
C
< 10 -7 h -1
(B)
< 10 -7 h -1
ISO 26262 Training - Day 3
© SGS-TÜV Saar GmbH 2017 ALL RIGHTS RESERVED
60

STEP 2B VERIFICATION OF FAILURE CLASSES PER HARDWARE COMPONENT

For each “Single Point Fault“ it must be shown that the target values from ISO

 

D

Failure rate class 1 + dedicated measures

 

Failure rate class 2 + dedicated measures

ASIL of

C

Or

the

Safety

Failure rate class 1

   

Goal

 

Failure rate class 2

B

Or

Failure rate class 1

  • Target values for Single Point Faults (SPF)

Dedicated measures: Measures which back up the assumed fault rates, e.g.

Design features such as over-design Initial test of the assembly components used

26262-5, Table 7, are met.

» Dedicated control plan

ISO 26262-5, Table 7

“Burn in“ test

»

»

»

© SGS-TÜV Saar GmbH 2017 ALL RIGHTS RESERVED

ISO 26262 Training - Day 3

61
61

STEP 2B VERIFICATION OF FAILURE CLASSES PER HARDWARE COMPONENT

 

Diagnostic Coverage with respect to residual faults

>= 99,9%

>= 99 %

>= 90 %

< 90 %

   

Failure rate

Failure rate

Failure rate

Failure rate class 1 +

D

class 4

class 3

class 2

dedicated measures

ASIL of the Safety Goal

 

Failure rate

Failure rate

Failure rate

Failure rate class 2 +

C

class 5

class 4

class 3

dedicated measures

 

Failure rate

Failure rate

Failure rate

 

B

class 5

class 4

class 3

Failure rate class 2

For each “Residual Point Fault“ it must be shown that the target values from

  • Target values for Residual Faults (RF)

ISO 26262-5, Table 8, are met

ISO 26262-5, Table 8

© SGS-TÜV Saar GmbH 2017 ALL RIGHTS RESERVED

ISO 26262 Training - Day 3

62
62

STEP 2B VERIFICATION OF FAILURE CLASSES PER HARDWARE COMPONENT

 

Diagnostic Coverage with respect to latent faults

>= 99 %

>= 90 %

< 90 %

 

D

Failure rate class 4

Failure rate class 3

Failure rate class 2

ASIL of Safety Goal

C

Failure rate class 5

Failure rate class 4

Failure rate class 3

For each “Latent Fault“ it must be shown that the target values from ISO

  • Target values for Latent Faults (LF)

26262-5, Table 9, are met.

ISO 26262-5, Table 9

© SGS-TÜV Saar GmbH 2017 ALL RIGHTS RESERVED

ISO 26262 Training - Day 3

63
63

DAY 2

EXERCISE 9

 
  • Results of PMHF and FRC

 

evaluations are shown in the

example

 
 What are the advantages and
 
  • What are the advantages and

disadvantages of each

method?

ISO 26262 Training - Day 3

© SGS-TÜV Saar GmbH 2017 ALL RIGHTS RESERVED

64

CONTENTS

 
  • 1. Hardware Development

 
  • a. Overview

  • b. Hardware Safety Requirements

  • c. Hardware Design

  • d. Evaluation of Hardware Metrics

  • e. Hardware Tests

  • 2. Software Development

  • a. Overview

  • b. Software Safety Requirements

  • c. Software Architecture and Design

  • d. Software Integration and Tests

ISO 26262 Training - Day 3

© SGS-TÜV Saar GmbH 2017 ALL RIGHTS RESERVED

65

DERIVING TEST CASES (1)

     

ASIL

   
 

Methods

A

B

C

D

   

1a

Analysis of requirements

++

++

++

++

1b

Analysis of internal and external interfaces

+

++

++

++

1c

Generation and analysis of equivalence classesa

+

+

++

++

1d

Analysis of boundary valuesb

+

+

++

++

1e

Knowledge or experience based error guessingc

++

++

++

++

 

1f

Analysis of functional dependencies

+

+

++

++

1g

Analysis of common limit conditions, sequences and sources of common cause failures

+

+

++

++

1h

Analysis of environmental conditions and operational use cases

+

++

++

++

 

1i

Standards if existingd

+

+

+

+

 

1j

Analysis of significant variantse

++

++

++

++

a

In order to derive the necessary test cases efficiently, analysis of similarities can be conducted.

 

b

EXAMPLE values approaching and crossing the boundaries between specified values, and out of range values

c

“Error guessing tests” can be based on data collected through a lessons learned process, or expert judgment, or both. It can be supported by FMEA.

d

Existing standards include ISO 16750 and ISO 11452.

 

e

The analysis of significant variants includes worst case analysis.

ISO 26262, Table 10 Methods for deriving test cases for hardware integration testing

 

ISO 26262 Training - Day 3

 

© SGS-TÜV Saar GmbH 2017 ALL RIGHTS RESERVED

66

DERIVING TEST CASES (1)

     

ASIL

   
 

Methods

A

B

C

D

   

1a

Analysis of requirements

++

++

++

++

1b

Analysis of internal and external interfaces

+

++

++

++

1c

Generation and analysis of equivalence classesa

+

+

++

++

1d

Analysis of boundary valuesb

+

+

++

++

1e

Knowledge or experience based error guessingc

++

++

++

++

 

1f

Analysis of functional dependencies

+

+

++

++

1g

Analysis of common limit conditions, sequences and sources of common cause failures

+

+

++

++

1h

Analysis of environmental conditions and operational use cases

+

++

++

++

 

1i

Standards if existingd

+

+

+

+

 

1j

Analysis of significant variantse

++

++

++

++

a

In order to derive the necessary test cases efficiently, analysis of similarities can be conducted.

 

b

EXAMPLE values approaching and crossing the boundaries between specified values, and out of range values

c

“Error guessing tests” can be based on data collected through a lessons learned process, or expert judgment, or both. It can be supported by FMEA.

d

Existing standards include ISO 16750 and ISO 11452.

 

e

The analysis of significant variants includes worst case analysis.

ISO 26262, Table 10 Methods for deriving test cases for hardware integration testing

 

ISO 26262 Training - Day 3

 

© SGS-TÜV Saar GmbH 2017 ALL RIGHTS RESERVED

67

CHOICE OF TEST METHODS (1)

   

ASIL

 
 

Methods

A

B

C

D

1

Functional testinga

++

++

++

++

2

Fault injection testing

+

+

++

++

3

Electrical testing

++

++

++

++

ISO 26262-5, Table 11 Hardware integration tests to verify the completeness and correctness of the safety mechanisms implementation with respect to the hardware safety requirements

© SGS-TÜV Saar GmbH 2017 ALL RIGHTS RESERVED

ISO 26262 Training - Day 3

68
68

CHOICE OF TEST METHODS (2)

 
  • 1 Functional testing: On HW level is only the HW aspect of the item should be considered. Test Cases should

 

demonstrate, that the HW fulfils the specified functions

(„straightforward tests“)

  • 2 Fault injection test: The injection of failure can processed physically (test adapter) or logically.

In case of physically injection SW test functions are used

together with SW basis functions (e.g. driver). Both kind of functions have to be verified sufficiently to fulfil the requirements for the highest ASIL. The test SW communicates the HW failures to the tester. Logically injection based on HW simulation (e.g. Model based development, net list etc.)

ISO 26262 Training - Day 3

© SGS-TÜV Saar GmbH 2017 ALL RIGHTS RESERVED

69

CHOICE OF TEST METHODS (3)

 

3 Electrical testing: Test cases are concentrated on the compliance to all HW safety requirements (not functional) and all electrical properties specified in the HW design.

 

ISO 26262 Training - Day 3

© SGS-TÜV Saar GmbH 2017 ALL RIGHTS RESERVED

70

MORE HW INTEGRATION TESTS

ISO 26262-5, Table 12 Hardware integration tests to verify robustness and operation under external stresses

   

ASIL

 

Methods

A

B

C

D

1a

Environmental testing with basic functional verificationa

++

++

++

++

1b

Expanded functional testingb

o

+

+

++

1c

Statistical testingc

o

o

+

++

1d

Worst case testing d

o

o

o

+

1e

Over limit testing e

+

+

+

+

1f

Mechanical testing

++

++

++

++

1g

Accelerated life test f

+

+

++

++

1h

Mechanical Endurance test g

++

++

++

++

1i

EMC and ESD test h

++

++

++

++

1j

Chemical testing i

++

++

++

++

a During environmental testing with basic functional verification the hardware is put under various environmental conditions during which the hardware requirements are assessed. ISO 16750-4 (Road vehicles -- Environmental conditions and testing for electrical and electronic equipment -- Part 4: Climatic loads) can be applied. b Expanded functional testing checks the functional behaviour of the item in response to input conditions that are expected to occur only rarely (for instance extreme mission profile values), or that are outside the specification of the hardware (for instance an incorrect command). In these situations, the observed behaviour of the hardware element is compared with the specified requirements.

 

c

Statistical tests aim at testing the hardware element with input data selected in accordance with the expected statistical distribution of the real mission profile. The acceptance criteria are defined so that the statistical distribution of the results confirms the required failure rate.

Worst case testing aims at testing cases found during worst case analysis. In such a test, environmental conditions are changed to their highest permissible marginal values defined by the specification. The related responses of the hardware are inspected and compared with the specified requirements. e In over limit testing, the hardware elements are submitted to environmental or functional constraints increasing progressively to values more severe than specified until they stop working or they are destroyed. The purpose of this test is to determine the margin of robustness of the elements under test with respect to the required performance. f Accelerated life test aims at predicting the behaviour evolution of a product in its normal operational conditions by submitting it to stresses higher than those expected during its operational lifetime. Accelerated testing is based on an analytical model of failure mode acceleration. g The aim of these tests is to study the mean time to failure or the maximum number of cycles that the element can withstand. Test can be performed up to failure or by damage evaluation. h ISO 11452-2; ISO 11452-4; ISO 7637-2; ISO 10605 and ISO 7637- 3 can be applied for EMC tests and ISO 16750-2 can be applied for ESD tests.

d

I

For chemical test, ISO 167505 can be applied.

 

© SGS-TÜV Saar GmbH 2017 ALL RIGHTS RESERVED

ISO 26262 Training - Day 3

71
71

HARDWARE TESTS SUMMARY

 Test methods are the same for safety relevant and non- safety relevant requirements  Reference
Test methods are the same for safety relevant and non-
safety relevant requirements
Reference to other well-known industry standards
An analysis of the existing test strategies is required,
whether they are sufficient
Existing hardware test strategies shall be analyzed and extended
if necessary
ISO 26262 Training - Day 3
© SGS-TÜV Saar GmbH 2017 ALL RIGHTS RESERVED
72

SUMMARY OF DAY 3

HARDWARE DEVELOPMENT

  • Functional Safety of hardware is mainly based on the evaluation of probabilistic metrics

 
  • The interface between hardware and software has to be clarified

  • Hardware safety requirements are a refinement of component safety requirements

  • Random hardware faults are categorized acc. to their impact on each safety goal

  • ISO 26262 establishes target values for the calculation of SPFM, LFM, PMHF and FRC

  • Existing hardware test strategies shall be analyzed and extended if necessary

ISO 26262 Training - Day 2

© SGS-TÜV Saar GmbH 2017 ALL RIGHTS RESERVED

73

CONTENTS

 
  • 1. Hardware Development

 
  • a. Overview

  • b. Hardware Safety Requirements

  • c. Hardware Design

  • d. Evaluation of Hardware Metrics

  • e. Hardware Tests

  • 2. Software Development

  • a. Overview

  • b. Software Safety Requirements

  • c. Software Architecture and Design

  • d. Software Integration and Tests

ISO 26262 Training - Day 3

© SGS-TÜV Saar GmbH 2017 ALL RIGHTS RESERVED

74

CONSIDERED PARTS

OF THE SOFTWARE DEVELOPMENT ISO 26262 Training - Day 3 © SGS-TÜV Saar GmbH 2017 ALL
OF THE SOFTWARE DEVELOPMENT
ISO 26262 Training - Day 3
© SGS-TÜV Saar GmbH 2017 ALL RIGHTS RESERVED
75

RESPONSIBILITIES AND TARGETS

Responsibilities

 
  • The software development phase typically is in the responsibility of the software suppliers, who have the knowledge for the implementation of software safety mechanisms at component level

Targets

  • In the software development phase a software is designed in accordance with the required safety integrity of safety requirements derived from the system development phase (TSC)

 Functional Safety in the software development is mainly based on the use of processes, techniques
Functional Safety in the software development is mainly based on the use of
processes, techniques and methods

ISO 26262 Training - Day 3

© SGS-TÜV Saar GmbH 2017 ALL RIGHTS RESERVED

76

SOFTWARE PHASE MODEL

ISO 26262 Training - Day 3 © SGS-TÜV Saar GmbH 2017 ALL RIGHTS RESERVED 77
ISO 26262 Training - Day 3
© SGS-TÜV Saar GmbH 2017 ALL RIGHTS RESERVED
77

INITIATION OF PRODUCT DEVELOPMENT AT

SOFTWARE LEVEL - ACTIVITIES

Activities during this phase:

 

Planning of activities during software development

Definition and documentation of selection criteria for tools and programming languages

Selection of suitable tools , techniques and methods (see also Day 4)

Definition of company-/project-internal tool application guidelines

 Initiation of software development means to plan activities and select tools, techniques and methods along
Initiation of software development means to plan activities and select tools,
techniques and methods along Functional Safety rules of the company

ISO 26262 Training - Day 3

© SGS-TÜV Saar GmbH 2017 ALL RIGHTS RESERVED

78

INTENTION OF SW-GUIDELINES

 

With brackets (Misra-C, rule 14.8):

while ( new_data_available )

while ( new_data_available ) {

Process_data();

Process_data();

Service_watchdog();

Service_watchdog();

}

  • Supporting the developer in designing robust and fault resistent SW-

  • Improve the quality and maintainability of the source code

  • Allow more flexibilty in the development teams

Example Without brackets:

code

© SGS-TÜV Saar GmbH 2017 ALL RIGHTS RESERVED

ISO 26262 Training - Day 3

79
79

CONTENTS

 
  • 1. Hardware Development

 
  • a. Overview

  • b. Hardware Safety Requirements

  • c. Hardware Design

  • d. Evaluation of Hardware Metrics

  • e. Hardware Tests

  • 2. Software Development

  • a. Overview

  • b. Software Safety Requirements

  • c. Software Architecture and Design

  • d. Software Integration and Tests

ISO 26262 Training - Day 3

© SGS-TÜV Saar GmbH 2017 ALL RIGHTS RESERVED

80

SPECIFICATION OF SOFTWARE SAFETY

REQUIREMENTS

ISO 26262 Training - Day 3 © SGS-TÜV Saar GmbH 2017 ALL RIGHTS RESERVED 81
ISO 26262 Training - Day 3