COMPONENT INTEGRATOR’S CHALLENGES FOR ISO26262 COMPLIANCE · PDF fileINTEGRATOR’S...

© 2015 Renesas Electronics Corporation. All rights reserved.

COMPONENT INTEGRATOR’S CHALLENGES FOR ISO26262 COMPLIANCE

20/Jan/2016 Rev:1.0 Riccardo Vincelli Manager, Functional Safety Competence Centre, Engineering Group, Renesas Electronics Corporation


RICCARDO VINCELLI

• Joined Renesas in 2000 (at that time still Hitachi)

• Manager of the Functional Safety Competence Centre in Renesas

• Cross-European team with locations in Germany and UK

• Responsible for safety analysis and technical safety assessments

• Covering HW (MCUs, SoC and MSIG) and SW products

• Acting as corporate advisor

• Including corporate education (e.g. e-learning)

• Active in ISO-TC22-SC23-WG08 since 2005

• Contributed to ISO26262 1st edition and now 2nd edition as well as ISO PAS 19451


RENESAS CONTRIBUTION TO SAFETY STANDARDISATION

Page 4

Very active within Standardisation Bodies being Member of: ISO, SAE, JSAE

Strong Participation and contribution to Key Standards (ISO26262, ISO PAS 19451, SAEJ2980)

Active in all following Groups related to Semiconductor aspects:

Basic Failure Rate Suitable FIT sources

Distribution of FIT

HW qualification “Complexity” issue

Applicability of ISO26262-8,13

Dependant Failure Analysis Applicability to digital elements

Applicability to analog elements

Analog How to perform safety analysis on

analog elements

Multicore How to cope with multiple cores

including ASIL decomposition

Fail Operational Limitations in ISO26262 to cope

with fail operational

requirements?

IPs Issues related to Intellectual

Properties and Programmable

Logic Devices

Fault injection Applicability to digital elements

Applicability to analog elements


ISO26262 OPTIONS FOR HW COMPONENTS SELECTION

Page 5

Can I use a COTS not necessarily developed for Automotive Applications?

Is the Component Functionality simple enough?

If so I can use through a “Safety Qualification”

Can I re-use a Component from one of my previous Projects?

Do I have a Component meeting same Functional Requirements?

If so I can use it if I have enough Field Data to claim PIU

Can I use a Component developed for Generic Automotive Applications?

This is related to development out of Context (i.e. SEooC)

Supplier is responsible for Capabilities of Component. Integrator is responsible for Suitability*

Can I develop or request from my Component Supplier a Component based on my exact Spec?

This is a development “in-context”. Integrator has the main responsibility in terms of Safety Requirements*

COTS: Commercial Off The Shelf

SEooC: Safety Element out of Context

PIU: Proven In Use

* DIA shall be referred to in term of Responsibility


KEY OPTIONS OF IN AND OUT OF CONTEXT DEVELOPMENTS

Page 6

OEM

Tier 1

Supplier x

Re

qu

ire

me

nts

R

eq

uire

me

nts

Item S

yste

m

Co

mp

on

en

t x

In-Context

OEM

Tier 1

Supplier x

Re

qu

ire

me

nts

Item

Syste

m

Co

mp

on

en

t x

Partially in-Context

OEM

Tier 1

Supplier x

Item

Syste

m

Co

mp

on

en

t x

Fully out-of-Context

Other

suppliers

Other

suppliers

Other

suppliers

OEM

Tier 1

Supplier x

Item

Syste

m

Co

mp

on

en

t x

Partially in-Context

Other

suppliers

Re

qu

ire

me

nts


FOCUS ON SEOOC – COMPONENT SUPPLIER’S TASKS

Page 7

• Selection of ISO26262 Process Requirements adopted for the Development

of the HW Component

• Analysis of Component Safety Capabilities vs Safety Concept

• Including Dependency Failure Analysis

• Perform applicable Verification Reviews, Confirmation Reviews, Safety Audit

and Assessment (out of Context)

• Definition (Assumption) of Safety Requirements for the Development of the

HW Component (including co-existence aspects, etc)

• Compute Hardware Architecture Metrics (SPFM, LFM), PMHF/cut-set

based on the defined Safety Concept Metrics Computation

Lifecycle

Safety Concepts

Safety Analysis

Verification Reviews and

Confirmation Measures SPFM: Single Point Fault Metrics, LFM: Latent Fault Metrics, PMHF: Probabilistic Metric of HW Failures

Safety

Concepts

Item Integration

& testing

ASIL

Safety Goal

Safety

ConceptsSafety

Concepts

System Tech. Safety

Requirements & Concept

Item safety validation

Safety assessmentImpact analysis and

Hazard and Risk Assessment

Item definition

HW safety requirement

Specification and HSI

HW Design

Safety Analysis

HW VerificationSW Design SW Verification

Production and Release

System Integration

& testing

System (safety)

verification

System design specification

(including HSI)

HW design specification

HW production

Supporting processes

Safety managementPart 2

Part 8Part 3

Part 3

Part 3

Part 4

Part 4

Part 5

Part 5

Part 5Part 6 Part 5 Part 6

Part 5, 6

Part 4

Part 4

Part 4

Part 4

Part 4

Part 4, 7

Analysis Part 9


FOCUS ON SEOOC – COMPONENT INTEGRATOR’S TASKS

Page 8

• Address Gaps in ISO26262 Process Requirements

• Judge Impact of difference in Safety Concept on the Safety Analysis

• Take required Actions to bring Work Products received “in context”

• Understand Gaps in Safety Requirements and take required Actions

• Compute Hardware Architecture Metrics (SPFM, LFM), PMHF/cut-set

based on the actual Safety Concept Metrics Computation

Lifecycle

Safety Concepts

Safety Analysis

Verification Reviews and

Confirmation Measures SPFM: Single Point Fault Metrics, LFM: Latent Fault Metrics, PMHF: Probabilistic Metric of HW Failures

Safety

Concepts

Item Integration

& testing

ASIL

Safety Goal

Safety

ConceptsSafety

Concepts

System Tech. Safety

Requirements & Concept

Item safety validation

Safety assessmentImpact analysis and

Hazard and Risk Assessment

Item definition

HW safety requirement

Specification and HSI

HW Design

Safety Analysis

HW VerificationSW Design SW Verification

Production and Release

System Integration

& testing

System (safety)

verification

System design specification

(including HSI)

HW design specification

HW production

Supporting processes

Safety managementPart 2

Part 8Part 3

Part 3

Part 3

Part 4

Part 4

Part 5

Part 5

Part 5Part 6 Part 5 Part 6

Part 5, 6

Part 4

Part 4

Part 4

Part 4

Part 4

Part 4, 7

Analysis Part 9


CHALLENGES IN TERM OF METRICS COMPUTATION 1/5

Page 9

Just looking at the Architectural Metrics Computation several Challenges exist

Integrator has to “Customize” several Parameters based on the required “Context”

Raw FIT rate

Elements related to the Safety Concept

Impact of Fault/Failures

Safety Mechanisms



Page 10

Raw FIT rate (Independent from Safety Goal)

Raw FIT used by the Component Supplier must be adjusted based on

Specific strategy adopted for the overall System/Item

Several options allowed by ISO26262

FIT provided by Component Supplier may reflect a different Strategy

Expected Mission profile

Parameters such as Temperature Cycles, on/off Period, etc influence FIT Value

FIT provided by Component Supplier will most likely not consider a Real Profile



Page 11

Selection of SR Elements (required for each Safety Goal)

A Component includes several Elements

Application Independent

Expected to be used in all Applications (representing the Core of the Component)

For these Elements Results could be re-used straight (but not always)

Application Dependent

Elements whose usage depends on the Particular Application

Integrator ought to compute Metrics based on the correct Elements used

This includes also the definitions of pins used

➩ Mandatory as part of the Verification Reviews in ISO26262-5, 8 and 9



Page 12

Adapt Impact of each Fault/Failures (required for each Safety Goal)

Each Fault can be classified into 3 categories:

Directly Violating the specified Safety Goal

Violating the specified Safety Goal only in combination with one or other Faults/Failures

Never violating the specified Safety Goal

Analysis provided by the Component Supplier is based on the Assumed Safety Concept

Depending on the Strategy a Conservative Approach may be adopted to ensure Wide Usage

When considering the same Fault/Failures in the Context of the Final System Impact may differ

Correct Classification is required as affecting Metrics and Safety Mechanism Strategy

Resid

ual o

n m

issio

n

or a

ctiv

e d

iag

no

stic

Detected D

ual point

mission

Detected D

ual point

diagnostic

Perceived Dual pointmission

Perceived Dual pointDiagnostic

Latent Dual point

mission

Latent Dual point

diagnostic

Safe

Mu

lti P

oin

t w

ith

n>

2

Sin

gle

Poin

t Fault



Page 13

Refine Safety Mechanisms (required for each Safety Goal)

Safety Analysis must reflect the Actual Configurations adopted for the Safety Mechanisms

Safety Mechanisms included in the Component Safety Concept can be

On-chip Safety Mechanisms (HW)

Configurability by Integrator possible in some cases

SW Safety Mechanisms

SW provided by the Component Supplier: Configurability by Integrator possible

SW not in responsibility scope of Component Supplier: Analysis provided may require significant Adaptations to reflect Reality

System Safety Mechanisms

Analysis provided may require significant Adaptations to reflect Reality

Refinement may also be related to timing as well as coverage


RELIANCE ON FAULT INJECTION RESULTS

Page 14

Fault Injection allows to perform several Checks required to support Safety Claims

Systematic Faults

Verify Correct Implementation of Safety Requirements (e.g. Safety Mechanisms)

Random HW Faults

Check Impact of Faults

Check Fault Coverage

…

Fault Injection should not be considered as “the Solution” to all Problems

An Educated Strategy is required

When Fault Injection is used Implications/Risks must be clearly Understood

In many cases Fault Injection is not possible with the Current Status of EDA Tools due to lacking of suitable

Fault Models


“EDUCATED STRATEGY” FOR FAULT COVERAGE VERIFICATION & RISKS

Page 15

Most suitable Approach to verify Coverage depends on a

number of Steps

Approach used should be justified and documented

Risks must be considered Independently of the Approach used

Especially when running simulations “out of Context” there is a

risk that Results are not always Representative of an “in

Context” Situation

Component Suppliers should clarify in their Work Products if

Coverages provided represent

A Reference Value – to be adjusted based on Final

Application Details

A Precise Value – to be used as is

Safety Mechanism

Required to meet safety

concept?

Coverageor Timing to be

verified?

Define the Factors influencing

Coverage or Timing

Identify the inputs required to verify

Coverage or Timing

Are all the inputs

available?

Select appropriate Verification Method

InspectionTests and

Simulations on silicon Chip

Fault Injection Modelling analysis

Define an actionto take to mitigate

the risks

Give a rationale of why

SM out of scope

No

Yes

No

No

Yes

Yes


CONCLUSION

Page 16

Functional Safety Compliance is a relatively new Challenge that the Automotive Community has to

face

Strategy to select Components and re-usability of Work Products is not trivial and must be

carefully considered

Building up an Item Safety Case is not just a simple matter of adding up together all Evidences

received

Proper “Customization” of results is required

When using Simulation Results to quantify Architectural Metrics special considerations are

required to judge dependency on the particular “Context” of Interest

COMPONENT INTEGRATOR’S CHALLENGES FOR ISO26262 COMPLIANCE · PDF fileINTEGRATOR’S...

Documents

Transcript of COMPONENT INTEGRATOR’S CHALLENGES FOR ISO26262 COMPLIANCE · PDF fileINTEGRATOR’S...