IEEE Consumer Electronics Magazine - April 2017 - 73

specifies tolerable random hardware failure rate m ASIL for
ASIL-A, ASIL-B, ASIL-C, and ASIL-D as less than 10 -6 h,
10 -7 h, 10 -7 h, and 10 -8 h, respectively. In other words,
ASIL-A, ASIL-B, ASIL-C, and ASIL-D can tolerate 1,000 FIT,
100 FIT, 100 FIT, and 10 FIT, respectively, which are equivalent to SIL2, SIL3, SIL3, and SIL4, respectively.

SOFTWARE FAILURES
Software failures occur due to mistakes in capturing software
requirements or during software development. In contrast to
hardware, software has no random failure modes (see the
"Failure Modes Classification and Assessment" section) or
wear-out phase. Moreover, the software failure probability
does not increase with elapsed time. Instead, the failure probability depends on the probability of occurrence of inputs/
conditions necessary to trigger the failures.
Software integrity of safety-related functions can be ensured
by methods similar to those used to control systematic hardware failures (i.e., methods focusing on design, construction,
and validation of the product). Software errors in safety-critical applications can be minimized by the programming language's and the compiler's adherence to international
standards. In particular, the compiler and programming language for safety-critical applications need to have an unambiguous definition, be strongly typed, support detection of
programming errors, and support limited language subsets as
recommended by automotive software reliability associations.
The Motor Industry Software Reliability Association
(MISRA) [11] is a consortium formed by vehicle OEMs, component suppliers, and engineering consultancies to provide
assistance to the automotive industry in the creation of safe and
reliable software. MISRA has introduced MISRA-C, which is a
subset of the C programming language, for safety-critical applications. MISRA-C has been widely adopted by automotive,
aerospace, medical, and industrial markets. Similarly, MISRA
has introduced MISRA-C++ (in 2008), which is a set of rules
for use of C++ in safety-critical systems and specifies a safe
subset of the C language.

SOFT ERRORS AND SOFT FAILURES
A soft error, also known as a single-event upset (SEU), is
construed as a transient portion of an erroneous machine
state. Because this type of fault does not reflect a device's
permanent error, it is termed as soft or transient. A soft error
in logic manifests when the outcome of a transient fault in
logic reaches a storage element and is latched. A soft error in
a memory element happens when adequate charge is produced to flip the value stored in the memory element. Soft
errors are induced by high-energy particle impacts, such as
neutrons from cosmic rays and alpha particles from the radioactive decay of integrated circuit packages.

assess various failure modes in automotive electronics. This
section discusses failure modes classification and assessment
in automotive systems as stipulated by ISO 26262.

FAILURE CLASSIFICATION
ISO 26262 classifies failures in a functional safety system in
three categories: 1) systematic failures, 2) random failures,
and 3) dependent failures.

SYSTEMATIC FAILURES
Systematic failures represent the failures in an item/function that
are induced in a deterministic way during development, manufacturing, or maintenance. Systematic failures stem from a design or
manufacturing flaw, which is a consequence of ignoring best
practices. The systematic failure rate can be reduced through
improvements in design, analysis, and verification processes.

HARDWARE RANDOM FAILURES
Hardware random failures transpire unpredictably during the
lifetime of a hardware element and emanate from random
defects innate to the process or usage conditions. Hardware
random failures are engendered by permanent faults (e.g.,
stuck-at faults), transient faults (e.g., SEUs or soft errors),
and/or intermittent faults (e.g., time-dependent alternations).
Designers emphasize detection and handling of random failures to avoid hazards due to these failures. In particular, techniques used to avoid random failures include redundancy,
diagnosis, monitoring, and self-tests.

DEPENDENT FAILURES
Dependent failure, also known as common-cause failure, is
defined as the failure of two or more elements of an item emanating from a single root source or a distinct event. Dependent
failures can be systematic or hardware random failures. The
main causes of dependent failures include environmental conditions (e.g., humidity, pressure, temperature, vibration, corrosion), electromagnetic compatibility, stress due to a particular
situation (e.g., aging), and failures of mutual external sources
(e.g., input data and power supply). Dependent failures can be
reduced by supervision of clock, power, temperature, and independent failure signaling.

FAILURE MODES CLASSIFICATION
Failure modes need to be defined for a hardware element to calculate hardware architectural metrics (see the "Failure Assessment via Hardware Architectural Metrics" section). Figure 3
depicts classification of failure modes of a hardware element.
These fault modes are defined next according to ISO 26262.

SAFE FAULT
A safe fault is a fault whose appearance does not considerably
increase the probability of infraction of a safety goal.

FAILURE MODES CLASSIFICATION
AND ASSESSMENT

MULTIPLE-POINT FAULT

Considering the proliferation of computerized control in
modern automotive systems, it is imperative to classify and

A multiple-point fault (MPF) is an individual fault that in conjunction with other independent faults causes a multiple-point
APRIL 2017

IEEE Consumer Electronics Magazine

Table of Contents for the Digital Edition of IEEE Consumer Electronics Magazine - April 2017