FMEA- Model based approach

Systemite AB Fürstenbergsgatan 4 Box 5171 SE-402 26 Göteborg Sweden Phone: +46 31 719 93 00


Model Based FMEA

Keeping Complex Systems

Consistent, Correct and Complete


Failure Mode Effects & Analysis

No Item/Function Potential Failure

Mode Potential Effect(s) of Failure

Sev

Class

Potential Cause(s) /Mechanism(s) of Failure

Occur

Current Design Controls Prevention

Current Design Controls Detectuib

Detec

R. P. N.

Recommended Actions

Responsibility and Target Date

Action Results (Status)

•Detection of failures in system/ subsystem/

component/ function

•Analysis of potential effects

•Severity classification (RPN = S * P * D)

•Definition of prevention and detection mechanisms

•Definition of needed actions


Problems today

� Lack of skill� Too few FMEA experts in an organization

� Engineers have lack of practical experience

� ISO 26262 means that need will increase

� Lack of traceability� Has analysis been performed?

� Have decided actions really been performed?

� Are detection and controls mechanisms really implemented?

� Methods often ambiguous

� No support for re-use of analysis

� No support for systematic improvement of predictions


Model Based approach

Project Activities•Concepts & Specifications

•Design

•Test & Verification

FMEA Analysis

System Model

Functions/ Components

FMEA model

Functions/ Components

Fault/ Failures

Effects


Purpose

� Improved integration with Product Development Project� FMEA-related actions traced by change management process -assure that the Recommended Actions really impact development

� FMEA information reused as components are reused

� Base analysis on requirements used in real development

� FMEA information integrated into product model - assure that requirements assumed during analysis are actually used in development, maintained throughout lifecycle

� Base analysis on test cases (detection) used in real development

� Improved formalism� Simple, unambiguous model

� Improved efficiency� Concurrent analysis on system components

� Report generated automatically for the FMEA review


Failure propagation

Normal Operation Failure

PFailure

”Repair”

Higher system service layer� Propagation in

general depends on

location, time and

duration of error and

the momentary

system state

� Errors may be

masked, i.e. never

propagating to

higher level failure:

� Bit-flip in unused

memory

� Stuck-at zero

memory cell,

where the stored

value is also zero

� Example of repair:

� Next transmission

of a state variable

in periodic data

communication.

Lower system service layer

PPropagation

Fault

propagation

Effect

Fault

propagation

Normal Operation Failure

”Repair”

PFailure


System of System Context

Failure

Higher system service

layer

Lower system service layer

P Propagation

Fault

propagation

Effect

Fault

propagation

Failure

<<Block>>

System Under

Analysis

<<Block>>

System Under

Analysis

Note: This is really some kind of simplified Fault Tree Analysis,

performed later in a project, on the “real” architecture, but

without combinatorial logic


Component vs. Failure Mode

<<Block>>

System Under

Analysis

Decomposition1

<<Item>>

(Analyzed Item)

Traceability Reference

* Failure Modes

<<Block>>

Failure Mode

Occurrence: integer

Detectability (potential): integer


Failure Mode vs. Cause and Effect

<<Block>>

Failure Mode

<<Block>>

Failure Effects

Severity: integer

ASIL: enumeration

* Effects of Failure

* Causes of Failure

Occurrence: integer


Failure Mode vs. Prevention

<<Block>>

Failure Mode

Requirement

Test Case

Detectability: enumeration

* Design Controls Detection

* Test Case Requirement

* Standard Design Controls

Prevention

Document

Reference

Design Controls

* Design Controls

Prevention


Failure Modes vs. Issues

<<Block>>

Failure Mode

Issue

Status (standard property)

AssignedTo (standard property)

Target Date : date

Risk Priority : integer

Issue

Item


Failure Mode, total model

<<Block>>

Failure Mode

<<Block>>

Failure Effects

Severity: integer

ASIL: enumeration

* Effects of Failure

Requirement

Test Case


* Standard Design Controls

Prevention

* Design Controls Detection

* Test Case Requirement

Issue

Document

Reference

Design Controls

* Design Controls

Prevention

Status (standard property)

AssignedTo (standard property)

Target Date : date

Risk Priority : integer

Issue

Item

* Causes of Failure

Occurrence: integer

Issue / Change Request


FMEA model vs. Classical template

No . Item/Function Potential Failure


Sev

Class


Occur



Detec

R. P. N.

Recommended Actions



1 1 func1 fm1 ef1 ef4

2 3

root cause 1 1 fm1: Failure preventive requirement root cause 1: Root cause prevention

A failure detection method

3 30

Failure mode prevention action

Jan Söderberg,

W850

Registered

1 2 func1 fm2 ef2 1 2

2 1 func2 fm3 ef3 6

<<Block>>

System Under

Analysis

Decomposition

<<Item>>

(Real Iitem)

Reference

* Failure Modes

<<Block>>

Failure Effects

Severity: integer

ASIL: enumeration

* Causes of Failure

* Effects of

Failure

Requirement Test Case


* Design Controls

Prevention

* Design Controls

Detection

* Test Case RequirementIssue

Occurrence: integer

Detectability (potential): integer

Occurrence:

integer

<<Block>>

Failure Mode


Report layout using the report options for tables ’AutoMerge’ and ’Colour’

No Item/Function Potential Failure


Sev

Class


Occur



Detec

R. P. N.

Recommended Actions



fm1 ef1 ef4

2 3

root cause 1 1 fm1: Failure preventive requirement root cause 1: Root cause prevention

A failure detection method

3 30

Failure mode prevention action

Jan Söderberg,

W850

Registered

1 func1

fm2 ef2 1 2

2 func2 fm3 ef3 6

Automatic Merge based

on cell item/part content

Cell color coded

according to issue

status


Conclusion from use in project

� Used in ~30 analyses for Active Safety systems

� Re-analysis of historic, traditionally performed FMEA has detected around 50% mistake rate

� Quotes from users (original wording and formatting):� “I’d like to remark that it was VERY quick to enter a long FMEA

once you’d enter the first page, and copied the different causes. It was also really fun to see how all the pieces fell into place. It was also easier to see all dependencied, and to understand the connections. Happy days! ☺”

� “I was pleased to see that when I had entered the recommended actions on the first page, all the others fell into place, with some exception. I think this connection could be a way to get people to update their FMEA (especially the causes) when you enter the actions and know more about the problem. In addition you are encouraged to specify more detailed if you can, and it is no longer enough to just write “SW error” if you know more.”


Next Steps

� Migration to ISO 26262

� Development of dedicated tool views

� Support for discrimination of faults with low likelyhood

Documents

FMEA- Model based approach