MCU functionalities change for ISO 26262 safety standard

Functional safety is becoming more and more relevant for electrical
and/or electronic systems (E/E systems) in the automotive domain through
the ever increasing benefits of electronic control. This article
explains how state-of-the-art MCUs support current safety standards.

Safety
aspect are not only relevant for new automotive systems such as
advanced driver assistance systems but also for established systems,
such as power steering, and even seemingly simpler systems, such as
various lighting controls, to name just a few examples. When looking at
such systems it soon becomes evident that a malfunction of such an E/E
system could be a source of harm in the form of physical injury or
damage to the health of persons. In late 2011, the ISO 26262 standard
was released as a sector specific functional safety standard for the
automotive sector intended for -- but not limited to -- E/E systems in
series production passenger cars. The objective of functional safety
according to the ISO 26262 is to circumvent potential harm to persons
that could be caused by malfunctioning E/E systems. In this sense, the
standard defines functional safety as the "absence of unreasonable risk
due to hazards caused by malfunctioning behavior of E/E systems."

The
ISO 26262 standard distinguishes between two main categories of
failures that can lead to malfunctioning behavior of E/E systems. The
one category focuses on systematic failures, which are defined as
“related in a deterministic way to a certain cause that can only be
eliminated by a change of the design or of the manufacturing process,
operational procedures, documentation or other relevant factors.”
Typical examples for systematic failures are failures such as those
caused by SW bugs, manufacturing defects, flawed system design, or
similar. Systematic failures can originate in HW as well as in SW. Due
to their nature, systematic failures will typically be evident across a
broader scope of a mass produced product population. The other category
focuses on random hardware failures, which are defined as occurring
“unpredictably during the lifetime of a hardware element and that
follows a probability distribution.” Typical examples for random
hardware failures are failures such as those caused by alpha particles,
neutrons or similar. Random hardware failures originate in hardware.

Addressing
such systematic failures and random hardware failures involves three
main types of measures: procedural measures that relate to the design
and manufacturing lifecycle of the system, functional measures that
provide dedicated services during run-time and structural measures that
involve the physical layout and partitioning of the system. Table 1 lists typical procedural, functional and structural measures.

The
procedural measures are the main line of attack against both systematic
SW failures and systematic HW failures. The reason for this is simple.
Procedural measures focus on avoidance and are therefore far more
efficient than functional measures that are executed during run-time.
Functional measures typically serve as the main means to address random
HW failures. The same set of measures can also help to address residual
systematic failures that remained undetected by the procedural measures.
The combination of HW processing redundancy combined with SW diversity
and I/O monitoring often yields a preferable balance of
techno-economical constraints that need to be met for commercial
viability. Last but not least, structural measures are important to
address the issue of spatial proximity failures and are often the key to
limit the amount of redundancy needed to address random HW failures.