Content uploaded by Rami Debouk
Author content
All content in this area was uploaded by Rami Debouk on Jun 02, 2023
Content may be subject to copyright.
Functional safety is of the utmost importance in
the development of safety-critical automotive
systems, especially with the introduction of driver
assist and automated driving systems. ISO 26262:
Functional Safety – Road Vehicles, has been the de
facto standard for functional safety in the automotive
electronics domain since the release of its first edition
in 2011. It is currently available in its second edition,
published in December 2018.
In this paper, we present an overview of the stan-
dard, which applies to all activities during the safety
lifecycle of system development. In the concept phase of
ISO 26262, the hazard and risk assessment process focus-
es on identifying possible hazards caused by malfunction-
ing behavior of electrical/electronic (E/E) safety-related
systems and mitigating them through the identification of
safety goals. The design phase includes system, hardware,
and software development, with requirements developed
from the safety goals. ISO 26262 also prescribes the func-
tional safety management activities to be performed dur-
ing the safety lifecycle and provides requirements for the
supporting processes.
In addition to presenting an overview of the stan-
dard, this paper highlights some major changes intro-
duced in the second edition of ISO 26262.
1. Introduction
Safety-critical systems are systems that have the poten-
tial to create safety-related issues if they do not operate
properly or as designed [Refs. 1 & 2]. These systems
are, in general, analyzed using rigorous and systematic
safety processes that define all safety activities during
the lifecycle development of the system [Ref. 3]. In
the automotive domain, ISO 26262: Functional Safety
– Road Vehicles [Ref. 4] emerged in 2011 as the go-to
standard for functional safety; it was launched as the
adaptation of IEC 61508 [Ref. 5] to comply with needs
specific to the application sector of electrical/electronic
systems within road vehicles.
ISO 26262 applies to all activities during the
safety lifecycle of system development. In the concept
phase, the hazard and risk assessment process focuses
on identifying possible hazards caused by malfunction-
ing behavior of E/E safety-related systems and mitigat-
ing them through the identification of safety goals. The
Overview of the Second Edition of ISO 26262:
Functional Safety— Road Vehicles
by Rami Debouk
Warren, Michigan
design phase includes system, hardware and software
development, with requirements derived from the
safety goals. ISO 26262 also prescribes the functional
safety management activities to be performed during
the safety lifecycle and provides requirements for the
supporting processes.
As is the case with the introduction of any new pro-
cess, lessons have been learned from the application of
the first edition of ISO 26262, and those learnings neces-
sitated the early release of the second edition, which was
published in December 2018 [Ref. 6]. The scope of ap-
plicability has been extended to include all road vehicles
as part of the improvement to the standard. In addition,
channels of communication between functional safety and
cybersecurity have been identified at both the functional
safety management level and product development at the
system level. Requirements on trucks, buses, trailers and
semi-trailers, as well as their supporting processes, have
been introduced in the second edition. A new section, de-
fining motorcycle-specific requirements in the safety life-
cycle, has been added. Guidance on semiconductor devel-
opment has also been described in a new informative part
of the standard. Finally, improvements have been made to
many of the existing definitions and requirements, along
with some restructuring to enhance readability.
This paper is organized as follows: Section 2 de-
scribes the basic definitions used in the standard, as well
as its scope of applicability. Section 3 introduces the
functional safety management, while Section 4 discusses
the approach for hazard analysis and risk assessment.
Section 5 introduces requirements of product develop-
ment at the system, hardware and software levels, in
addition to a brief summary discussing requirements for
production, operation, service and decommissioning. Sec-
tion 6 summarizes required supporting processes and dis-
cusses some safety analyses. Section 7 introduces specific
requirements for motorcycles, while Section 8 introduces
requirements for trucks, buses, trailers and semi-trailers.
Section 9 provides guidance on semiconductor develop-
ment, while Section 10 provides a general summary.
2. Scope of Applicability and Definitions
ISO 26262 is the adaptation of IEC 61508 [Ref. 5] to
comply with needs specific to the application sector
of electrical/electronic systems within road vehicles. It
Journal of System Safety, Spring 2019 13
Unreasonable Risk
Risk judged to be unacceptable in a certain context
according to valid societal, moral concepts
Safety
Absence of unreasonable risk
Risk
Combination of the probability of occurrence of
harm and the severity of that harm
Severity
Estimate of the extent of harm
to one or more individuals
that can occur in a potentially
hazardous situation
Harm
Physical injury or damage
to the health of persons
Exposure
State of being in an operational
situation that can be hazardous
if coincident with the failure mode
under analysis
Controllability
Ability to avoid a specified harm or damage
through the timely reactions of the persons
involved, possibly with support from
external measures
Figure 1 — ISO 26262 Definitions of Safety and Risk.
applies to all activities during the safety lifecycle of sys-
tem development and its scope has been expanded to
include all series production road vehicles. Prior to this
modification, the scope of the first edition limited the
applicability to vehicles with more than four wheels
(carrying passengers or goods) with a maximum vehicle
gross mass of up to 3,500 kilograms.
ISO 26262 defines functional safety as the absence
of unreasonable risk due to any potential source of harm
caused by malfunctioning behavior of electrical and/or
electronic systems. A malfunctioning behavior is not lim-
ited to failures; it also includes unintended behavior (with
respect to design intent).
Figure 1 describes how safety is defined in ISO
26262 as the absence of risk judged to be acceptable
given valid societal and moral concepts. Risk itself is
computed using three factors: severity, exposure and
controllability. It is worth emphasizing here that the
concept of “harm” is defined in the context of injury or
damage to humans.
Figure 2 provides a classification of ISO
26262-specific terminologies, starting with a system or
combination of systems to which the standard applies.
The item itself implements a given function at the ve-
hicle level. The system is a set of components, such as
a sensor, a controller and an actuator. Components are
comprised of hardware parts and software units. The con-
cept of an “element” is introduced, referring to a system,
component, a hardware part and a software unit.
Finally, the following are definitions of a few con-
cepts are introduced or emphasized in ISO 26262:
• Safety Goal — A top-level safety requirement re-
sulting from the hazard analysis and risk assessment,
as described in Section 4
• Safe State — The mode of operation, without an
unreasonable level of risk, of the item following the
occurrence of a failure
• Safety Mechanism — The technical solution to
detect and mitigate (through avoidance or control)
faults and/or failures to maintain intended function-
ality, or achieve or maintain a safe state
• Work Product — Documentation that results from
an ISO 26262 requirement(s)
• Confirmation Review — Confirmation that a work
product provides sufficient and convincing evidence
of the achievement of functional safety
• Safety Case — Documentation to communicate
a clear, comprehensive and defensible argument
(supported by evidence compiled in work prod-
ucts) that a system is acceptably safe to operate in
a particular context
3. Functional Safety Management
Functional safety management involves planning, co-
ordinating and documenting all activities related to
functional safety. In general, it involves the following, as
pictured in Figure 3:
14 Journal of System Safety, Spring 2019
• establishing an internal functional safety process for
the company
• establishing a safety organization that oversees the
institutionalization of a safety culture within the
company, as well as the definition of roles and re-
sponsibilities within that organization
• training and qualifying employees to perform safety
activities
• institutionalizing functional safety confirmation
measures, including reviews, audits and assessments
• managing all corresponding documentation aspects
Part 2 of ISO 26262 discusses implementing a
management plan for all phases of the safety lifecycle,
including:
• the overall safety management
• the project-dependent safety management
• the safety management for production, operation,
service and decommissioning
Overall safety management involves defining re-
quirements for organizations that are responsible for or
perform safety activities in the safety lifecycle. A manage-
ment plan is put forward to incorporate:
• institutionalization of the safety culture
• effective communication channels between func-
tional safety and cybersecurity (a new topic intro-
duced in the Second Edition of ISO 26262)
• organization-specific rules and processes
• processes to resolve safety anomalies
• competence management
• quality management
• project-independent tailoring of the safety lifecycle
Project-dependent safety management involves
defining requirements for safety management during the
concept and development phases of a project, including
roles and responsibilities, as well as performing an impact
analysis at the item level in case of a modified/re-used
item. A management plan is put forward to incorporate:
• roles and responsibilities in safety management
• impact analyses and tailoring of safety activities
• planning and coordinating of safety activities
• progression of the safety lifecycle
• safety case development
• confirmation measures
It is worth mentioning here that the impact analyses
and tailoring of the safety activities have been added to
Sensor
Hardware
Hardware
Components
Hardware
Parts
Software
Software
Components
Software
Units
Controller
Hardware
Hardware
Components
Hardware
Parts
Software
Software
Components
Software
Units
Actuator
Hardware
Hardware
Components
Hardware
Parts
Software
Software
Components
Software
Units
Combinations of
Systems
System ...
E/E
Components Communication Other Technology
Components
Item
Element
Component
Figure 2 — ISO 26262 Terminologies.
Journal of System Safety, Spring 2019 15
the functional safety management of a given project ver-
sus being performed at different phases of development
as required by the First Edition of ISO 26262. Moreover,
the confirmation reviews (part of the confirmation mea-
sures) have been re-defined to provide sufficient and
convincing evidence of the achievement of functional
safety — an objective-oriented approach compared to
the prescriptive definition of meeting requirements in the
First Edition of ISO 26262.
Safety management for production, operation, ser-
vice and decommissioning involves defining responsibili-
ties of persons and organizations in charge of achieving
and maintaining functional safety regarding production,
operation, service and decommissioning. For instance, re-
quirements are established to appoint persons to execute
processes to achieve and maintain the functional safety of
the item regarding field monitoring and collection of data.
4. Hazard Analysis and Risk Assessment
In Part 3 of ISO 26262, potential hazards are identified
following an analysis of the operational situations of
the item. The item may be a vehicle, a vehicle system
or a vehicle function. The identified potential hazards
are then categorized based on the following factors:
severity, probability of exposure and controllability. Fol-
lowing the categorization results, an automotive safety
integrity level, or ASIL, is determined for the potential
hazard. The ASIL is also assigned to the safety goal(s)
formulated to prevent or mitigate the potential hazard
and avoid unreasonable risk. Safety requirements are
then derived from these safety goals and inherit the
corresponding ASIL. The following provides a brief
overview of these activities and the reader is referred to
[Ref. 7] for a detailed account:
Situation Analysis and Hazard Identification —
The potential hazards are determined given the op-
erating modes of the item in which a malfunctioning
behavior may trigger them. These hazards are described
and evaluated, and their consequences are identified
and documented.
Hazard Classification — The identified potential
hazards are classified based on the estimation of severity,
probability of exposure and controllability as defined in
Section 2. Severity (S) has four classes, ranging from S0
(no injuries) to S3 (fatal injuries). Exposure (E) ranges
from an E0 (an extremely unusual situation) to E4 (a
highly likely situation). Finally, controllability (C) ranges
from C0 (simply controllable) to C3 (uncontrollable).
Item Definition
Initiation of the
Safety Lifecycle
3.4
3.5
3.7 Hazard Analysis and
Risk Assessment
3.8 Functional Safety
Concept
7.5 Production
7.6 Operation, Service &
Decommissioning
Product Development
System Level
Release for Production
HW
Level
5SW
Level
6
4
4.11
7.5 Production
Planning
Other
Technologies
Controllability External
Measures
Management of Functional Safety
Supporting Processes
Safety Training
& Qualification
Safety Compliance Audit,
Reviews & Assessment
Safety Organization,
Roles & Responsibilities,
Culture
Safety Plan
Safety Plan
Safety Plan
Safety Plan
Safety Plan
Safety Plan
Safety Activity
Management
Company Internal
Safety Process
Figure 3 — Management of Functional Safety.
16 Journal of System Safety, Spring 2019
ASIL Determination — An
ASIL is to be determined for each
hazardous event using the parameters
S, E and C as shown in Table 1. Four
ASILs are defined, where ASIL A is
the lowest safety integrity level and
ASIL D is the highest. In addition to
these four ASILs, the class QM (qual-
ity management) denotes no require-
ment in accordance with ISO 26262.
Any other requirements such as qual-
ity, reliability, and durability, however,
must be accounted for.
Safety Goal Formulation — A
safety goal is to be determined for
each hazardous event evaluated in
the hazard analysis. Functional safety
requirements needed to avoid an
unreasonable risk for each potential
hazard are derived from these safety
goals which are not expressed in
terms of technological solutions, but
rather in terms of functional objec-
tives. Functional safety requirements
inherit the ASIL of the safety goal
from which they are derived.
The ASIL determined for the
hazardous event is assigned to the
corresponding safety goal. A poten-
tial hazard may have more than one
safety goal and, if similar safety goals
are determined, they can be com-
bined into one safety goal that will
be assigned the highest ASIL of the
similar goals.
5. Product Requirements
at System, Hardware
and Software Levels
Product development at the sys-
tem level starts with developing
the technical safety concept. The
technical safety concept specifies the
technical safety requirements and
their allocation to system elements
(hardware and software). The techni-
cal safety concept defines the system
architectural design as well. The
development of the technical safety
concept is then detailed at both the
hardware and software levels. Once
the hardware and software develop-
ment is complete, all elements are
integrated and tested. Finally, safety
C1 C2 C3
S1 E1 QM QM QM
E2 QM QM QM
E3 QM QM A
E4 QM A B
S2 E1 QM QM QM
E2 QM QM A
E3 QM A B
E4 A B C
S3 E1 QM QM A
E2 QM A B
E3 A B C
E4 B C D
Table 1 — ASIL Determination (Source ISO 26262 2nd Ed.).
Technical Safety Concept
Product Development — Hardware Product Development — Software
System and Item Integration and Verification
Safety Validation
validation is completed at the vehicle
level — that is, evidence is provided
that safety goals have been met. This
is graphically represented in Figure 4
and detailed in the following:
Technical Safety Concept —
The technical safety concept compris-
es all technical safety requirements.
These requirements are the technical
refinement of their corresponding
functional safety requirements: They
specify safety mechanisms to detect
faults, and mitigate or control failures
that may lead to the violation of these
functional safety requirements and
hence, the safety goals. These techni-
cal safety requirements inherit the
ASIL of the functional safety require-
Figure 4 — Product Development at the System Level.
Journal of System Safety, Spring 2019 17
ments they refine. In addition, a system architectural
design that implements the technical safety requirements
is defined as part of the technical safety concept and is
supposed to be suitable to satisfy the safety requirements
according to their respective ASIL.
In defining technical safety requirements, some
of these requirements may come from a cybersecurity
concept as a result of the established channels of com-
munication between functional safety and cybersecurity
discussed in the functional safety management summary.
Moreover, some technical safety requirements are derived
to address safety issues during production, operation,
service and decommissioning.
Product Development at the Hardware Level —
At this level, a hardware implementation of the techni-
cal safety concept is specified, and safety analyses are
performed to find potential faults and their effects on
the violation of safety goals. In addition, any required
coordination with development at the software level is
identified.
The hardware implementation of the technical
safety concept involves identification of hardware require-
ments or, in other words, assignment from technical safety
requirements to hardware elements given the system ar-
chitectural design. The hardware design itself is supposed
to be consistent with the system architectural design
specification and fulfills the hardware safety requirements
while protecting against safety concerns considering the
performed safety analyses. The suitability of the hardware
architectural design (to detect and control random hard-
ware failures) is assessed using two metrics: single-fault
metric and latent-fault metric. Both metrics have target
values depending on the ASIL of the requirements being
implemented. An alternative approach to assess the suit-
ability of the hardware architectural design (to detect and
control random hardware failures) is to evaluate the prob-
ability of safety goals violation. The latter can be com-
pleted using a global probabilistic approach or by analyz-
ing individual cut sets. In both cases, the assessment is also
dependent on the ASIL of the safety goal.
Finally, once all hardware elements are integrated,
a verification of the compliance of the hardware design
with the hardware safety requirements (given their re-
spective ASILs) is expected.
Product Development at the Software Level — At
this level of development software safety, requirements
are derived from technical safety requirements, and a
software architecture that satisfies all software require-
ments is developed. In addition, any required coordina-
tion with development at the hardware level is identi-
fied and/or refined.
Similar to hardware requirements, software safety
requirements are derived from the technical safety con-
cept and the system architectural design specification.
These requirements inherit the ASIL of their respective
technical safety requirements in general. The software
architectural design is required to be suitable to satisfy
the software safety requirements with their respective
ASILs and support the implementation and verification
of the software being developed. The latter includes the
software unit design, implementation and verification;
the software integration and verification; and the testing
of the resulting embedded software.
System and Item Integration and Verification —
The integration steps are defined for all levels of integra-
tion, including integration of hardware and software of an
element, integration of elements resulting in an item, and
integration of the item with other systems at the vehicle
level. Evidence that the integrated system elements fulfill
their safety requirements is also provided. Finally, the
proper implementation of safety mechanisms is verified.
Safety Validation — This final step of the system
product development provides evidence that the safety
goals have been achieved at the vehicle level, and that
the developed safety concepts are appropriate for the
functional safety of the item. Validation of safety goals is
applied to the item integrated at the vehicle level and the
validation plan includes test procedures for each safety
goal with a pass/fail criterion.
As discussed earlier, some technical safety require-
ments address safety concerns related to production,
operation, service and decommissioning. The objective of
these requirements is to ensure that functional safety is
achieved throughout the whole lifecycle of the vehicle.
As part of planning for production, operation, ser-
vice and decommissioning, it is required to develop:
• production processes for safety-related system(s) to
be installed in road vehicles
• all necessary information and documentation re-
garding operation, maintenance and repair, and de-
commissioning to be used by whoever is interfacing
with the safety-related system(s)
In addition to the planning, the production process
needs to be analyzed to uncover any process failures and
their effects on achieving functional safety. Additionally,
the production process must implement and verify the
effectiveness of measures to mitigate or control these
process failures. Related to the information and documen-
tation for operation, maintenance, repair and decommis-
sioning, a field monitoring process needs to be established
to address potential safety-related incidents related to the
system(s), with the objective of collecting field data that
can be analyzed to detect the presence of functional safety
issues and initiate corrective actions for these issues.
18 Journal of System Safety, Spring 2019
Table 2 — ASIL Decomposition Rules
6. Supporting Processes and Safety Analyses
Supporting processes are usually labeled “secondary
processes” that accompany the core processes and con-
tribute indirectly in delivering a product. For functional
safety, ISO 26262 identified a dozen of these processes,
each containing a set of consolidated common require-
ments. Here, we briefly discuss a few of these supporting
processes, referring readers to Part 8 of ISO 26262 for a
more detailed discussion of all supporting processes.
Interfaces Within Distributed Developments —
This defines the interactions and dependencies between
integrators and suppliers for development activities, and
describes corresponding allocation responsibilities. In
addition, it provides a means to evaluate the supplier’s
capability to develop and produce items of comparable
complexity and ASIL, according to ISO 26262. The
Distributed Interface Agreement (DIA) includes, among
many others, requirements on:
• safety managers at the integrator and supplier
• joint tailoring of the safety lifecycle, with identifica-
tion of activities and processes to be performed by
the customer and by the supplier
• information required, work products to be ex-
changed and persons responsible
• ...
Specification and Management of Safety Require-
ments — This process ensures correct specification
of safety requirements with respect to attributes and
characteristics, and supports consistent management
of safety requirements throughout the safety lifecycle.
This is achieved by defining requirements on the nota-
tions used for the specification of safety requirements,
attributes, characteristics and properties of safety re-
quirements, as well as how the safety requirements are
managed.
Confidence in the Use of Software Tools — This
provides criteria to determine the required level of
confidence in a software tool, along with means for the
qualification of that software tool. A tool confidence level
(TCL) is determined based on analysis, the tool impact
ASIL A ASIL B ASIL C ASIL D
ASIL A(A) +
QM(A)
ASIL B(B) +
QM(B)
ASIL A(B) +
ASIL A(B)
ASIL C(C) +
QM(C)
ASIL B(C) +
ASIL A(C)
ASIL D(D) +
QM(D)
ASIL C(D) +
ASIL A(D)
ASIL B(D) +
ASIL B(D)
and the tool error detection. Given the TCL, ISO 26262
describes methods to be applied to qualify the software
tool, given the ASIL of the safety goal(s).
Qualification of Software Components — This
provides evidence for the suitability of the software
components for re-use in items developed per the ISO
26262 standard. ISO 26262 requires information to
treat a software component as qualified (specification
of the software component, evidence that the software
component complies with its requirements and is suit-
able for its intended use, and evidence of an appropri-
ate software development process). It also prescribes
requirements for verification of the qualification of the
software component.
Evaluation of Hardware Elements — This ensures
that the element functional behavior is adequate to meet
its allocated safety requirement(s). This type of evalua-
tion is used for commercial off the shelf (COTS) parts
not developed per ISO 26262 or considered to be safety
related once integrated into an item. In addition, it can
be used as an alternative means of compliance with the
product development requirements at the hardware
level. Different classes are considered, depending on the
difficulty of the verification of the safety-related func-
tionality and the role of the hardware element within the
safety concept. The evaluation is carried through either
testing; testing and analysis; or testing, analysis and argu-
mentation.
Part 9 of ISO 26262 provides an overview of some
types of safety analyses. The following briefly describes
an ISO 26262 specific method for decomposing re-
quirements.
Requirements Decomposition with Respect to
ASIL Tailoring — Known as ASIL decomposition, this
is a method to decompose safety requirements into re-
dundant safety requirements (not necessarily identical)
to allow ASIL tailoring at the next level of detail. The
redundant requirements are allocated to sufficiently in-
dependent design elements. It is worth noting here that,
even though the development of the design elements to
which the redundant requirements are allocated is per-
formed at the decomposed ASIL level, the evaluation of
Journal of System Safety, Spring 2019 19
MSIL ASIL
QM QM
A QM
B A
C B
D C
Table 3 — MSIL to ASIL Mapping
the hardware metrics and the safety goal violations tar-
gets due to random hardware failures remains unchanged
by ASIL decomposition. Table 2 provides the rules for
ASIL decomposition. These rules can be applied itera-
tively, as long as traceability is maintained.
7. Motorcycles
Part 12 is a new addition to ISO 26262 Second Edition,
and gives an overview of the adaptation of the standard
to motorcycles not in the scope of the 1st Edition. All
requirements apply to motorcycles; some tailoring, how-
ever, is required. Therefore, requirements in Part 12 su-
persede the corresponding requirements in all other parts.
The major adaptation of requirements in the case
of motorcycles applies to the development of the hazard
analysis and risk assessment, as well as the determination
of the S, E and C parameters. A motorcycle-specific haz-
ard analysis is performed and accounts for:
• the dynamic behavior of motorcycles, which differs
greatly from other vehicles
• motorcycle rider dependence to achieve controlla-
bility
• operational situations and hazard identification spe-
cific to motorcycles
As part of the hazard analysis and risk assessment, a
Motorcycle Safety Integrity Level (MSIL) is determined
for each hazard from the combination of a motorcycle-
specific S, E and C of the hazardous event. The MSIL
is later mapped to the ASIL, as depicted in Table 3 and
safety goals are assigned to the mapped ASIL. From there
onwards confirmation reviews, vehicle integration and test-
ing, and safety validation are performed, given the ASIL.
8. Trucks, Buses, Trailers and Semi-trailers
Truck, buses, trailers and semi-trailers (T&B for short)
have been added to the scope of the standard in its
Second Edition version. Similar to motorcycles, re-
quirements of Parts 2 through 9 apply to T&B, and any
specific modification or new requirements for T&B are
listed within the parts of the standard wherever they
apply. Additional requirements are listed under:
• functional safety management–supporting processes
• hazard analysis and risk assessment
• system-level validation environment
• production, operation, service and decommissioning
Before discussing T&B-specific requirements, it is
worth noting here that in the context of T&B, a “body
builder” is an organization that adds its own equipment
to a base vehicle, such as machine, body or cargo carrier.
Consequently, the body builder becomes the integrator
in the case of a T&B, while the role of the original equip-
ment manufacturer of the base vehicle is relegated to
that of a supplier.
As part of the functional safety management in
the case of T&B, a tailoring of safety activities is re-
quired when:
• a T&B-related application that is out of scope of
ISO 26262 is being interfaced with a base vehicle
that has been developed in accordance with ISO
26262, or
• a T&B-related system not developed according to
ISO 26262 is to satisfy the required level of func-
tional safety needed for the integration into an item
developed in accordance with ISO 26262.
In these specific situations, some development inter-
face agreement (DIA) requirements do not apply.
Interfacing an Application that is Out of Scope of
ISO 26262 — An application out of scope of ISO 26262
is supposed to not violate the safety goals of the base
vehicle that has been developed in accordance with ISO
26262. In that specific situation, it is required that the
integrator is made aware of the modified systems and the
permitted safety limits/requirements of the modifications
by the manufacturer or supplier. The manufacturer or
supplier is, in fact, responsible for communicating safety
measures required to be applied by the integrator so that
functional safety is maintained.
Integration of Safety-Related Systems not Devel-
oped According to ISO 26262 — A development not
according to ISO 26262 satisfies the required level of
functional safety needed to be integrated into an item
developed according to ISO 26262. In that specific
situation, the integrator is required to define the cri-
teria to argue that the safety-related system that has
been developed to another safety standard meets the
required level of functional safety. Consequently, the
integrator and the supplier are required to agree on
the relevant set of measures to verify that the criteria
are met.
20 Journal of System Safety, Spring 2019
Hazard Analysis and Risk Assessment — In the
context of T&B, variances of T&B vehicle operation
are defined as the use of a T&B vehicle with different
dynamic characteristics influenced by cargo or towing
during the service life of the vehicle. As a consequence,
while performing the hazard analysis and risk assessment,
the following variances are to be considered:
• the type of base vehicle
• the T&B vehicle configuration
• the T&B vehicle operation
These variances will impact the operational situa-
tions, hazardous events, and the S, E and C classifications.
System-Level Validation Environment — Since
the safety goals are validated for the item in a repre-
sentative context at the vehicle level, different base
vehicle types in the case of T&B could be the subject of
a safety validation.
Operation, Service and Decommissioning — The
operation, service and decommissioning of the item is
required to be conducted and documented in accor-
dance with the service plan, instructions for service, and
instructions for decommissioning. Such a requirement is
important for T&B, since elements of T&B can be reman-
ufactured and corresponding plans and instructions can
be modified. Therefore, it is required that all the right
plans and instructions are maintained and documented.
9. Guidance on Semiconductor Development
With the introduction of the First Edition of ISO
26262, semiconductor manufacturers were not well
versed in the area of automotive functional safety. This
resulted in some confusion in the early application of
the standard to semiconductor components. A project
was launched within the working group developing
ISO 26262 to assess and understand the impact of ap-
plying the standard to semiconductors. Two publicly
available specifications were developed to address these
issues [Refs. 8 & 9] and these became the origins of
Part 11 in ISO 26262 Second Edition.
Part 11 of ISO 26262 Second Edition is an informa-
tive section and a necessary extension of the First Edition
of ISO 26262 to provide guidelines for semiconductors
used in automotive applications. This section provides
guidelines on semiconductor components and semicon-
ductor technologies. A semiconductor component can be
developed as:
• Part of the item — In this case, the safety analysis
performed per the product development at the
hardware level applies, or
• A Safety Element out of Context (SEooC) — In
this case, the development is assumed to meet a
given ASIL independent of an item and its safety
goals, and is based on assumptions to be verified at
integration. If these assumptions are indeed veri-
fied, then the SEooC can be integrated into an item
without further safety analyses.
10. Summary
In this paper, we summarized the content of the Second
Edition of the ISO 26262 standard, including its scope
of applicability, definitions, and requirements per its core
and supporting processes, as well as some guidelines pro-
vided for semiconductor development. While presenting
the summary, a few major modifications and additions
were discussed. This summary is intended to be informa-
tive and is not intended to be a substitute for reading the
standard in order to apply it.
References
1. Ericson II, C. A. Hazard Analysis Techniques for System Safety, John Wiley & Sons, New Jersey, 2005.
2. Leveson, N. Safeware: System Safety and Computers, Addison Wesley, Boston, Massachusetts, 2001.
3. Bahr, N. J. System Safety Engineering and Risk Assessment: A Practical Approach. Taylor and Francis, Oxford-
shire, U.K. 1997.
4. ISO TC22/SC3/WG16. “ISO 26262 1st Ed. Road Vehicles: Functional Safety Parts 1-9,” November 2011.
5. IEC 61508. “Functional Safety of Electrical/Electronic/Programmable Electronic Safety Related Systems Parts
1-7,” Switzerland, 1998.
6. ISO TC22/SC32/WG08. “ISO 26262 2nd Ed. Road Vehicles - Functional Safety Parts 1-12,” 2018.
7. Debouk, R., & J. Joyce. “ISO 26262 Hazard and Risk Assessment Methodology,” International System Safety
Conference, 2010.
8. ISO/PAS 19451-1. “Application of ISO 26262:2011-2012 to Semiconductors - Part 1: Application of Concepts,”
2016.
9. ISO/PAS 19451-2. “Application of ISO 26262:2011-2012 to Semiconductors — Part 2: Application of Hard-
ware Qualification,” 2016.
Journal of System Safety, Spring 2019 21
