DESIGN AND ANALYSIS OF FUNCTIONALLY SAFE HARDWARE IN AN EBSThe achievement of functional safety for road vehicles according to ISO 26262 is accompanied by extensive

requirements and effort for development in the form of prescribed hardware safety evaluations and specific

safety case documents. Continental, FZI Research Center for Information Technology and Vector describe

an efficient methodology that supports an iterative design/analysis process and has been integrated into the

model-based PREEvision system engineering tool. In addition to presenting the methodology and tool support

based on ISO 26262, a specific application is explained involving safety evaluations for a newly developed

electronic braking system (EBS).

10

COVER STORY FUNCTIONAL SAFETY

DERIVATION

With the publication of ISO 26262 “Road

vehicles - Functional safety”, the auto-

motive industry, its development pro-

cesses, and resulting products are sub-

ject to explicit safety requirements for

the first time. Manufacturers don’t just

have to evaluate a portion of the system

during the particular development phase

but rather must evaluate the whole sys-

tem throughout its life cycle. The hard-

ware development is accompanied by

extensive requirements and effort in the

form of prescribed hardware safety eval-

uations and specific safety case docu-

ments. The following describes an effi-

cient methodology that supports an itera-

tive design/analysis process and has

been integrated into the model-based

PREEvision system engineering tool. In

addition to presenting the methodology

and tool support based on ISO 26262, a

specific application is explained involv-

ing safety evaluations for a newly devel-

oped electronic braking system (EBS).

FUNCTIONAL SAFETY IN THE HARDWARE CONTEXT

The activities and work products

demanded by ISO 26262 [1] are exten-

sive and, despite the very well-struc-

tured and prepared standard, are often

difficult to introduce into existing pro-

cesses and tool chains [2]. The standard

describes two different design phases for

product development at the hardware

level according to Part 5: The hardware

architectural design consists of hard-

ware components and describes an

abstracted and functional view of a pre-

liminary hardware design. The hard-

ware detailed design, in contrast, is

made up of hardware parts and repre-

sents a refinement of the hardware com-

ponents at the level of electronic sche-

matics. In the following, these will be

referred to simply as hardware designs

and hardware elements.

Required safety evaluations regarding

the analysis of random hardware fail-

ures are based on statistical failure

information and are described in Part 5

Clause 8 for the “Evaluation of the hard-

ware architectural metrics”. In turn, this

evaluation is composed of the “single-

point fault metric” and the “latent-fault

metric” and enables conclusions to be

drawn about the robustness of the hard-

ware design.

This evaluation is complemented by

the “Evaluation of safety goal violations

due to random hardware failures”

described in Clause 9, which represents

probabilistic safety analyses. Two differ-

ent evaluations can be applied here:

“Evaluation of Probabilistic Metric for

random Hardware Failures (PMHF)”,

which requires a global analysis of the

design, and “Evaluation of each cause of

safety goal violation”, frequently referred

to as the FRC method, which represents

an individual classification of single

hardware elements.

PROCEDURE FOR HARDWARE SAFETY EVALUATION

Model-based environments are particu-

larly well-suited for supporting safety

AUTHORS

DIPL.-ING. NICO ADLERworks as Research Scientist in the

Embedded Systems and Sensors

Engineering Department at the

FZI Research Center for Information

Technology in Karlsruhe (Germany).

DR. EDUARD METZKERis Senior Product Management

Engineer for Systems Engineering

Tools at the Vector Informatik GmbH

in Stuttgart (Germany).

DR. ALEXANDER RUDOLPHworks as Safety Manager in

the Business Unit Vehicle Dynamics

Division at the Continental AG

in Frankfurt/Main (Germany).

11 06I2014 Volume 9

evaluations required by ISO 26262 in

iterative and collaborative development

projects. Hardware designs based on

specific libraries are modeled with

deposited failure information. The model

information enables the demanded

safety evaluations to be carried out with

the support of a database and thus with

significantly less effort [3].

A continuously updated display of the

calculated evaluation results supports

the iterative approach for different devel-

opment phases. This simplifies goal-ori-

ented design changes. Automated report

documents enable an overview of the

development progress to be obtained at

any time and decrease the documenta-

tion effort.

FAILURE LIBRARY

Statistical information regarding fail-

ures of hardware elements, such as

failure rates, failure modes and failure

rate distributions among failure modes,

are administered in a failure library.

The failure library is typically popu-

lated from recognised industry sources

such as Siemens Norm SN 29500 and

can be easily expanded to include

empirical knowledge from company-

internal databases. Failure information

that has been added can be reused in

different hardware designs by different

development teams.

INTEGRATED MODELING

At the beginning, safety goals with their

associated automotive safety integrity

level (ASIL) are derived from a hazard

analysis and risk assessment (HARA)

of the complete system and stored at the

requirements level. A refinement is

carried out using functional and techni-

cal safety requirements, which can be

iteratively updated. It is also necessary

to define safety mechanisms with

specific values for the diagnostic cover-

age with respect to residual faults and

latent faults.

For modeling of the hardware design,

the functional and technical safety con-

cepts can be realised in the form of the

hardware architectural design, (a),

and the hardware detailed design, (b).

The hardware elements including failure

information which are deposited in the

library can be dropped directly to the

appropriate diagram (c).

TRACEABILITY AND DESIGN OPTIMISATION

Because the failure information of the

hardware elements is transferred from

the failure library, consistent and tracea-

ble results are guaranteed, (a). The

engineer is relieved of having to main-

tain the data and can focus on the analy-

sis and optimisation of the design in

terms of its functional safety. Thus, the

effects of newly introduced safety mech-

anisms or additional hardware elements

on the evaluations can be analysed.

HARDWARE SAFETY EVALUATIONS

Several editors are available for the

model-based application of safety evalu-

ations. These can be used to provide a

structured and prepared display of the

evaluation results while offering differ-

ent perspectives of the evaluations.

The failure data table according to

ISO 26262 contains the safety goals to

be analysed, the safety-related classifica-

tions as well as the failure information

annotated in the library. Information

regarding a potential direct violation of

the safety goal and a potential violation

Modeling of hardware design

at different abstraction levels

COVER STORY FUNCTIONAL SAFETY

12

in combination with other independent

failures is given. The failure modes can

be classified in the context of the safety

goal directly in the editor or automati-

cally using a qualitative fault tree analy-

sis (FTA).

The “Evaluation of the hardware

architectural metrics” is performed for

one or more safety goals. For the “Evalu-

ation of each cause of safety goal viola-

tion” at the level of the hardware ele-

ment, a ranking into a failure rate class

and a specific diagnostic coverage is con-

sidered. Target values are derived from

the ASIL of the safety goals and their ful-

fillment is highlighted graphically, (b).

The evaluation of a PMHF is supported

by a qualitative and quantitative fault

tree analysis. For this, the calculation of

a probability as a worst-case estimate for

occurrence of the top-level event in the

fault tree, as the violation of the safety

goal to be assessed, is provided. The

determination of average probabilities

(footnote: this corresponds numerically

to the “Conditional failure intensity”,

thus the probability of failure at time T

on condition of freedom from failure at

time T0. As worst-case, the system life-

time can be set as T-T0 = Lifetime.)

from the failure rates is achieved using a

customisable latency time T. Addition-

ally, the qualitative analysis of the fault

tree using minimal cut sets enables the

definition of design constraints.

REPORTS

The effort associated with the documen-

tation requirements of ISO 26262 is not

trivial. The model-based approach

offers significant benefits here as well.

For safety evidence, it is possible to gen-

erate review reports during the design

phase as well as documents for argu-

mentation of the “safety case” after

finalisation of the hardware design.

These can also be used for a possible

certification of the hardware. Auto-

mated creation of the safety case docu-

ments is possible at any time during

development. These documents give an

indication of the current status of the

hardware safety of the system.

EBS AS AN EXAMPLE SCENARIO

This example involves the safety evalua-

tion for a brake-by-wire (BBW) electronic

braking system currently under develop-

ment. For display purposes, the evalua-

tion is limited to the redundant power

supply of the EBS, . Among other

Excerpt of failure data table with results of the “Hardware Architectural Metrics” as well as the FRC method

Evaluation of the power supply

system element from an electronic

braking system

13 06I2014 Volume 9

things, the focus here is on the interfaces

between requirements, architecture,

design and their derivation with deduc-

tive safety analyses.

The safety goal SAF_REQ_1 “The

average probability of loss of BBW auxil-

iary energy shall be less than 3e-09/h”

was derived from the HARA. The func-

tional safety concept provides the power

supply to the adjacent EBS-Actuator sys-

tem element primarily via terminal

KL30_2. In case of need, the ALT selec-

tor switch can be used to switch to the

secondary power supply VP1. This is

used as cold redundancy to increase

availability and is switched on in emer-

gency operation.

Application of the integrated concepts

yielded the fault tree shown in Figure 4a.

The top-level event occurs if “Undetected

loss of VP2”, “Loss of VP2 and loss of

cold standby (VP1 or ALT)” or “Loss of

cold standby (VP1 or ALT) in emergency

operation” occurs. Through the minimal

cut set analysis, the budgets for the

occurrence probabilities of the individual

minimal cut sets were assigned and the

safety requirements (functional and

technical) and design constraints shown

in were derived. For multiple-point

faults (cut set order greater one), the per-

missible budgets of the individual faults

can be determined and the degradation

and emergency operation characteristics

(maximum duration and warning con-

cept) can be specified, (c).

CONCLUSION

All hardware safety evaluations

demanded by ISO 26262 are fully sup-

ported in a single integrated solution.

This eliminates additional work and

error sources caused by inconsistent data

sources, a change of tools and tool

breaks. The library approach unburdens

the engineers to carry out design and

analysis and provides a high level of

reusability. Effects of hardware design

modifications or introduction of safety

mechanisms are instantly observable in

Fault tree and

derived safety require-

ments as well as design

constraints

COVER STORY FUNCTIONAL SAFETY

14

the evaluation results. This shortens the

optimisation cycles drastically. Thanks

to the collaboration support, distributed

teams can jointly drive the design and

analysis and implement changes faster

and more reliably.

The model-based combination of hard-

ware safety evaluations with other work

products of ISO 26262 is possible and

desirable. This enables automated checks

of work products for formal complete-

ness and consistency as well as auto-

mated generation of reports, including

the safety case.

REFERENCES[1] International Organization for Standardization,

ISO 26262 Standard, Road vehicles – Functional

safety (2011)

[2] Adler, N.; Otten, S.; Schwär, M.; Müller-Glaser,

K.: Managing Functional Safety Processes for Auto-

motive E/E Architectures in Integrated Model-Based

Development Environments. In: SAE Int. J. Passeng.

Cars – Electron. Electr. Syst. 7(1), pp. 103 – 114,

doi:10.4271/2014-01-0208 (2014)

[3] Adler, N.; Otten, S.; Cuenot, P.; Müller-Glaser,

K.: Performing Safety Evaluation on Detailed Hard-

ware Level according to ISO 26262. In: SAE Int. J.

Passeng. Cars – Electron. Electr. Syst. 6(1):

pp. 102 - 113, doi:10.4271/2013-01-0182 (2013)

THANKS

Special thanks to Prof. Dr.-Ing. Klaus D. Müller-

Glaser and Stefan Otten, who worked on this

article too. Klaus D. Müller-Glaser is Head of

the Institut für Technik und Informationsverar-

beitung (ITIV) in Karlsruhe (Germany) and

Stephan Otten works as a Research Scientist

in the Embedded Systems and Sensors Engi-

neering Department at FZI Research Center

for Information Technology in Karlsruhe

(Germany).

15 06I2014 Volume 9