A global approach to functional safety - GETRAG€¦ · A global approach to functional safety Dr.-Ing. M. Leibbrandt, Getrag Ford Transmissions GmbH

A global approach to functional safety Dr.-Ing. M. Leibbrandt, Getrag Ford Transmissions GmbH

Agenda

June 24, 2014 © GETRAG, 14th International VDI Congress, Drivetrain for Vehicles, Friedrichshafen June 2014, Dr. Martin Leibbrandt 2

1. Finding all hazards

2. Determination of safety goals

3. Definition of safety functions

Local safety architecture

Global safety architecture

4. Hardware architectural metrics

5. Bus communication

Finding all hazards

System boundary diagram


Oil Flow

Legend :

Boundary Transmission Mechanical Interface Oil Signals Housing Connection

BUS Signals ( CAN / LIN )

Engine System

Starter

Parksystem

TCMA L 1 & L 2 SW

Oilcooler

Housing

Oil Pan / Suction Filter

Breather

Pressurefilter

Nested Clutch

Damper

Gears / Shafts / Bearings

Synchronizer

Differential

Hydraulic Controls

Internal Controls

Oil Pump

Rear Roll Restrictor

Shaft Drives

External Controls

LHS Engine Mount

Shipping Plugs

SHS

TMC

DSL

ASL

MSL

GSL SIC GSM

Physical interface diagram


Oil Flow

Legend :

Boundary Transmission Mechanical Interface Oil Signals Housing Connection

BUS Signals ( CAN / LIN )

Engine System

Parksystem

TCMA L 1 & L 2 SW

Nested Clutch

Damper

Gears / Shafts / Bearings

Synchronizer

Hydraulic Controls

Internal Controls

Oil Pump

Shaft Drives

External Controls

Transfer torque

Faults (e.g. HAZOP):

No torque

Too much torque

Too less torque

Intermittent torque

Negative torque

…

Safety Goals

Safety Goals – Hazard And Risk Analysis


Safety Goals – Example Definition


System Fault:

Transmission blocks drive shaft. On a double clutch transmission this can happen

if both clutches are engaged at the same time (clutch tie-up)

Rating:

Depending on vehicle architecture, vehicle state and drive situation between ASIL

QM and ASIL D

Safety goal (front driven vehicle):

If absolute vehicle speed is above a defined threshold, the system shall prevent

with a safety integrity of ASIL C that the transmission output is blocked due to

both clutches engaged.

Safe State:

To establish the Safe State the difference of the added torques of both clutches

and the engine torque shall be below a defined total torque.

Process safety time: 300 ms

Safety Function and Function Architecture

Local Safety Architecture


Sourc

e:

Speech „

Erf

ahru

ngen i

n d

er

Sic

hers

tellu

ng

der

Funktionale

n S

icherh

eit

in d

er

Lenkungsentw

icklu

ng“,

Dr.

-Ing.

Fra

nk S

chöttle

r, V

olk

sw

agen,

3rd

IS

O 2

6262 a

nnual confe

rence

Paradigm: Each single function of the system is monitored for

compliance with the safety goals.

Local Safety Architecture


Advantages:

One single architecture, safety software (Level 2) mirrors function software

(Level 1)

Small, well-defined monitor modules

Good testability at subsystem level

Disadvantages:

No diversity – both on hardware level and on software level

Complex function software leads to complex safety software

Safety goals are fragmented over different safety functions

Difficult proof of completeness on system level

Changes in function architecture must be followed in the safety architecture

Complex interfaces between function software and safety software

Global Safety Architecture


Level 2

Paradigm: Each safety goal is monitored on vehicle level

Level 1

Level 2

Level 1



1:1 mapping of Safety

Goals on Safety

Functions

global

fault reaction



Advantages:

Completely divers by using different algorithms

Completely independent from function software

No need for changes if function software evolves

Good testability on system level

1:1 relationship between safety goal and safety function

Process safety time does not need to be allocated to different functions

Explicit allocation of ASIL rating to components possible

Few interfaces between function software and safety software

In most cases low level output drivers are not safety relevant

Disadvantages:

No correlation between function software and safety software

In general safety functions are more complex (but fewer)

Hardware Architectural Metrics

Hardware Architectural Metrics


By using a global safety architecture the hardware architectural metrics

change. In case of the clutch tie-up:

For the local safety architecture the clutch actuation is the only relevant output.

Critical elements are the clutch pressure sensor, engine torque and actuation

of the pressure regulator. But many other elements influence the desired clutch

pressure and need to be assessed and monitored whether they become safety

relevant.

The global safety architecture uses the shift fork positions, the clutch pressure,

the back-measured regulator current and the vehicle speed instead. Engine

torque is not needed. A fault in the actuation does not violate the safety goal

any more.

Disadvantage: The global architecture generally has more safety relevant

elements

Advantage: The safety function can be modified easily and the fault tree is

less complex.

Hardware Architectural Metrics: Influence on the

Safety Function

June 24, 2014 © GETRAG, 14th International VDI Congress, Drivetrain for Vehicles, Friedrichshafen June 2014, Martin Leibbrandt 17

Safety Goal: Avoid clutch overspeed (ASIL C).

Safety Function: De-energize actuators if a shift fork moves in direction of a

lower gear at speeds above a defined threshold and the input shaft is

accelerated excessively.

Hardware Architectural Metrics: An Example


Problem: SPFM of the safety function only 94,5%

Analysis of the influences: SPFM of the input shaft speed information only

44% (digital Hall sensor)

Analysis of fault models: All faults for which the signal input stays constant

can not be diagnosed, as they can not be distinguished from zero speed.

Hardware Architectural Metrics: An Example


Solution: Rate input shaft condition as fulfilled if input shaft speed is zero and

shift system is actuated.

SPFM of input shaft speed information is increased to 88%

Total SPFM is increased to 97,6%

shift fork actuation

energized

Bus Communication

Bus Communication


In most vehicles several independent electronic control units are connected by

a bus system and exchange potentially safety relevant information (e.g. vehicle

speed or engine torque). Two possible approaches for a safety analysis exist:

Local safety architecture: The signals received from other vehicle

subsystems are treated locally the same way as the other sensor inputs. Local

hardware is developed according to part 5 annex C and D.8, software OSI

layers 5 to 7 developed according to the ASIL rating of the safety function(s)

using the signal with methods according to part 6 annex D.2.4

Global safety architecture: All connected vehicle subsystems are treated as

whole. The bus is analyzed according to part 9 clause 6 and a global safety

architecture is defined.

Bus Communication: Local Safety Architecture


Depending on the ASIL rating of the consuming function, the signals need to

be secured on the bus:

ASIL A: no special mechanisms necessary according to part 5

ASIL B: recommended to have the SPFM >90% CRC of CAN bus is given

as an example of good enough diagnostics (part 5 D 2.7.6 b example 4).

ASIL C/D: strongly recommended to have a SPFM>97(99)% a combination

of information redundancy, frame counter and timeout monitoring is

recommended (part 5 table D.8)

Conclusion:

If the software is developed according to the required ASIL rating, no additional

effort necessary up to ASIL B, for ASIL C and D a frame counter and timeout

monitoring is recommended.

Bus Communication: Global Safety Architecture


The CAN bus is a CSMA/CR multi master bus. Each participant is connected

to a common line:

ECU ECU ECU ECU

… …

… …

If two ECUs send messages with different IDs at the same time, the one with the

lower ID “wins”. If ECUs send messages with the same ID at the same time, a

collision is detected in the data field and the transfer is aborted (and repeated at

a later time).

ID1 IDX IDY … … IDZ … ID1 IDX IDY … … IDZ …

Sampling of CAN mailbox for ID1:

Messages have a unique ID identifying their content and are often sent out and

received at fixed intervals (but timing is not guaranteed).



However, if two ECUs send messages with the same ID at different times,

without an additional detection method the ECU sending the information latest

“wins”:

ID1 IDX IDY … ID1 IDZ … ID1 IDX IDY … ID1 IDZ …

Sampling of CAN mailbox for ID1:

ID1 ID1 Message from ECU 1 Message from ECU 2

Without additional measures to detect this behavior, the criteria for coexistence

(part 9 clause 6) requires that all ECUs connected with the bus are developed

according to the highest ASIL rating assigned to the bus signals, as it can not

be guaranteed that this behavior is discovered during development (it can be

caused by a hidden software fault of a ECU with no ASIL or ASIL QM

assigned).



One possible measure to ensure the coexistence criteria is to apply the

measures of the local safety architecture for ASIL C/D signals to ASIL A and

ASIL B signals, also.

In this case, the wrong signal would be detected by a missing or wrong frame

counter. This method is sufficient, if all safety relevant ECUs have the same

ASIL rating assigned. If not, a checksum calculated with a ECU specific

algorithm should be included to avoid the situation that the wrong message

includes a valid frame counter.

One big benefit if such additional measure is incorporated is that the CAN

software stack can be developed according ASIL QM, as a message corruption

within the software could be detected within the safety software partition.

Thank you for your attention

Documents

A global approach to functional safety - GETRAG€¦ · A global approach to functional safety Dr.-Ing. M. Leibbrandt, Getrag Ford Transmissions GmbH