design and analysis of functionally safe hardware … and analysis of functionally safe hardware in...
TRANSCRIPT
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