I.
INTRODUCTION
Functional Safety addresses
possible hazards caused by malfunctioning behavior of E/E safety-related
systems, including interaction of these systems.
It does not address hazards
related to electric shock, fire, smoke, heat, radiation, toxicity,
flammability, reactivity, corrosion, release of energy and similar hazards,
unless directly caused by malfunctioning behavior of E/E safety-related
systems.
ISO 26262 is the adaptation of IEC 61508 to comply with
needs specific to the application sector of electrical and/or electronic (E/E)
systems within road vehicles.
It includes an automotive safety life cycle,
automotive-specific risk analysis, and verification and validation (or V &
V) so that systems achieve an acceptable level of safety.
II.
Automotive Functional Safety
Overview of ISO26262
ISO 26262 is intended to be
applied to safety-related systems that include one or more electrical and/or electronic
(E/E) systems and that are installed in series production passenger cars with a
maximum gross vehicle mass up to 3 500 kg. ISO 26262 does not address unique
E/E systems in special purpose vehicles such as vehicles designed for drivers
with disabilities.
Within the figure, the specific
clauses of each part of ISO 26262 are indicated in the following manner: “m-n”,
where “m” represents the number of the part and “n” indicates the number of the
clause, e.g. “3-6” represents Clause 6 of
ISO 26262-3.
ISO26262 standard consists of 10
parts. These are as follows:
·
Vocabulary
·
Management of functional safety
·
Concept phase
·
Product development at the system Level
·
development at the hardware level
·
Product development at the software level
·
Production and operation 8.Supporting processes
·
Automotive Safety Integrity Level
(ASIL)-oriented and safety-oriented analyses
·
Guideline on ISO 26262.
Figure 1 shows the overall
structure of this edition of ISO 26262.
ISO 26262 is based upon a V-model
as a reference process model for the different phases of product development.
Within the figure, the shaded “V”s represent the interconnection between ISO
26262-3, ISO 26262-4, ISO 26262-5, ISO 26262-6 and ISO 26262-7.
Figure 1: Overview of
ISO26262
Chapter 1: Vocabulary
This part of ISO 26262 specifies
the terms, definitions and abbreviated terms for application in all parts of
ISO 26262.
Example: Item : system (1.129) or array of systems to implement a function
at the vehicle level, to which ISO 26262 is applied.
System: set of elements (1.32) that relates at least a sensor, a
controller and an actuator with one another.
Element: system (1.129) or part of a system including components
(1.15), hardware, software, hardware parts (1.55),
and software units (1.125).
There are total 142 terms and
definition.
Chapter 2: Management
of Functional Safety
This part of ISO 26262 specifies
the requirements for functional safety management for automotive applications,
including the following:
·
project-independent requirements with regard to
the organizations involved (overall safety management), and
·
project-specific requirements with regard to the
management activities in the safety lifecycle (i.e. management during the
concept phase and product development, and after the release for production).
The ISO 26262 safety lifecycle (see Figure 2) encompasses
the principal safety activities during the concept phase, product development,
production, operation, service and decommissioning.
Planning, coordinating and documenting the safety
activities of all phases of the safety lifecycle are key management tasks.
Figure 2 represents the reference safety lifecycle model.
Tailoring of the safety lifecycle, including iterations ofsubphases, is
allowed.
Figure 2: Safety
Cycle
5.1 section of part 2 define the clause of requirements for
the organizations that are responsible for the safety lifecycle, or that
perform safety activities in the safety lifecycle.
This clause serves as a prerequisite to the activities in
the ISO 26262 safety lifecycle.
Safety plan :
Plan to manage and guide the
execution of the safety activities of a project including dates, milestones, tasks, deliverables,
responsibilities and resources.
Functional safety assessment plan:
Plan when to have functional safety
assessment and who will be the assessor.
Confirmation measure reports:
Plans who will be the reviewer.
And defines the objective of reviews
Safety Case:
The compilation of all documents
and data that explains the product is functionally safe. It can be derived from
the work products of the development phases. The safety plan forms the basis
for the safety case.
The safety case is the key
requirement for the release for production.
Work products from part 2 of
ISO26262 standard are as follows:
·
Organization-specific rules and processes for
functional safety.
·
Evidence of competence.
·
Evidence of quality management.
·
Safety plan
·
Project plan (refined).
·
Safety case.
·
Functional safety assessment plan.
·
Confirmation measure reports
·
Evidence of field monitoring.
Chapter 3: Concept Phase
This part of ISO 26262 specifies
the requirements for the concept phase for automotive applications, including
the following:
·
item definition,
·
initiation of the safety lifecycle,
·
hazard analysis and risk assessment, and
·
functional safety concept.
Item definition:
The first objective is to define
and describe the item, its dependencies on and interaction with the environment
and other items.
The second objective is to
support an adequate understanding of the item so that the activities in
subsequent phases can be performed.
Initiation of the safety lifecycle:
The objective of the initiation
of the safety lifecycle is to make the distinction between a new item
development and a modification to a existing item.
hazard analysis and risk assessment :
The objective of the hazard
analysis and risk assessment is to identify and to categories the hazards that
malfunctions in the item can trigger and to formulate the safety goals related
to the prevention or mitigation of the hazardous events, in order to avoid
unreasonable risk.
functional safety concept :
The objective of the functional
safety concept is to derive the functional safety requirements, from the safety goals, and to allocate them to
the preliminary architectural elements of the item, or to external measures.
Safety goals:
Top-level safety requirement as a
result of the hazard analysis and risk assessment.
Figure 3 illustrates the
hierarchical approach by which the safety goals are determined as a result of
the hazard analysis and risk assessment. The functional safety requirements are
then derived from the safety goals.
The structure and distribution of
the safety requirements within the corresponding Parts of ISO 26262 are
illustrated in Figure 4. The functional safety requirements are allocated to
the elements of the preliminary architecture.
Figure 3: Hierarchy
of safety goals and functional safety requirements
Figure 4: Structure
of the safety requirements
Determination of ASIL and safety goals:
An ASIL shall be determined for each
hazardous event using the parameters "severity", "probability of
exposure" and "controllability" in accordance with Table 1.
NOTE 1 Four ASILs are defined:
ASIL A, ASIL B, ASIL C and ASIL D, where ASIL A is the lowest safety integrity
level and ASIL D the highest one.
NOTE 2 In addition to these four
ASILs, the class QM (quality management) denotes no requirement to comply with
ISO 26262.
Table 1: ASIL
Determination
Severity:
The severity of potential harm
shall be estimated based on a defined rationale for each hazardous event. The
severity shall be assigned to one of the severity classes S0, S1, S2 or S3 in accordance
with Table 2.
Table 2: Classes of
severity
Exposure/Probability:
The probability of exposure of
each operational situation shall be estimated based on a defined rationale for
each hazardous event. The probability of exposure shall be assigned to one of
the probability classes, E0, E1, E2, E3 and E4, in accordance with Table 3.
Table 3: Classes of
probability of exposure regarding operational situations
Controllability: The
controllability of each hazardous event, by the driver or other persons
potentially at risk, shall be estimated based on a defined rationale for each
hazardous event. The controllability shall be assigned to one of the
controllability classes C0, C1, C2 and C3 in accordance with Table 4.
Work products from part 3 of
ISO26262 standard are as follows:
·
Item definition
·
Impact analysis
·
Safety plan (refined)
·
Hazard analysis and risk assessment
·
Safety goals
·
Verification review report of the hazard
analysis and risk assessment and the safety goals
·
Functional safety concept
·
Verification report of the functional safety
concept
Chapter 4: Product
Development: System Level
This part of ISO 26262 specifies
the requirements for product development at the system level for automotive
applications, including the following:
·
requirements for the initiation of product
development at the system level,
·
specification of the technical safety
requirements,
·
the technical safety concept,
·
system design,
·
item integration and testing,
·
safety validation,
·
functional safety assessment, and
·
product release.
System design:
The first objective of this
subphase is to develop the system design and the technical safety concept that
comply with the functional requirements and the technical safety requirements
specification of the item.
The second objective of this
subphase is to verify that the system design and the technical safety concept
comply with the technical safety requirements specification.
Item integration and testing:
The first objective of the
integration process is to test compliance with each safety requirement in
accordance with its specification and ASIL classification.
The second objective is to verify
that the “System design” covering the safety requirements are correctly
implemented by the entire item.
Safety validation:
The first objective is to provide
evidence of compliance with the safety goals and that the functional safety
concepts are appropriate for the functional safety of the item.
The second objective is to
provide evidence that the safety goals are correct, complete and fully achieved
at the vehicle level.
Functional safety assessment:
The objective of the requirements
in this clause is to assess the functional safety that is achieved by the item.
Assessment is done by 3rd
party. Assessment shall not be done with the team.
The necessary activities during
the development of a system are given in Figure 5.
After system design technical
safety requirements are been framed.
These requirements are developed
as per ISO26262 either by hardware development (ISO26262-5) or by software
development (ISO26262-6).
Figure
5: Reference phase model for the development of a safety-related item
Figure 6 is an
example of a system with multiple levels of integration, illustrating the
application of this part of ISO 26262, ISO 26262-5 and ISO 26262-6.
Figure 6: Example of a product development at the system
level
The first objective of this
subphase is to specify the technical safety requirements. The technical safety
requirements specification refines the functional safety concept, considering
both the functional concept and
the preliminary architectural
assumptions.
The second objective is to verify
through analysis that the technical safety requirements comply with the
functional safety requirements.
The technical safety requirements
shall be specified in accordance with the functional safety concept, the
preliminary architectural assumptions of the item and the following system
properties:
·
the external interfaces, such as communication
and user interfaces, if applicable.
·
the constraints, e.g. environmental conditions
or functional constraints; and
·
the system configuration requirements.
The technical safety requirements
shall specify safety-related dependencies between systems or item elements and
between the item and other systems.
The technical safety requirements
shall specify the necessary safety mechanisms including:
·
the measures relating to the detection,
indication and control of faults in the system itself.
·
the measures relating to the detection,
indication and control of faults in external devices that interact with the
system.
·
the measures that enable the system to achieve
or maintain a safe state
·
the measures to detail and implement the warning
and degradation concept and
·
the measures which prevent faults from being
latent
Work products from part 4 of
ISO26262 standard are as follows:
·
Project plan (refined)
·
Safety plan (refined)
·
Item integration and testing plan(s)
·
Validation plan
·
Functional safety assessment plan (refined)
·
Technical safety requirements specification
·
System verification report
·
Technical safety concept
·
System design specification
·
Hardware-software interface specification (HSI)
·
Specification of requirements for production,
operation, service and decommissioning
·
Safety analysis reports resulting from
requirement.
·
Item integration and testing plan (refined)
·
Integration testing specification(s)
·
Integration testing report(s)
·
Functional safety assessment report resulting
from requirements
·
Release for production report resulting from
requirements
Chapter 5: Product
Development: Hardware Level
This part of ISO 26262 specifies the requirements for
product development at the hardware level for automotive applications,
including the following:
·
requirements for the initiation of product
development at the hardware level,
·
specification of the hardware safety
requirements,
·
hardware design,
·
hardware architectural metrics, and
·
evaluation of violation of the safety goal due
to random hardware failures and hardware integration and testing.
·
The requirements of this part of ISO 26262 for
hardware elements are applicable both to non-programmable and programmable
elements, such as ASIC, FPGA and PLD.
Initiation of product development at the hardware level:
The objective of the initiation
of the product development for the hardware is to determine and plan the functional
safety activities during the individual subphases of hardware development.
This planning of
hardware-specific safety activities is included in the safety plan
The necessary activities and
processes needed to develop hardware that meets the safety requirements are
planned. Figure 7 illustrates the hardware level product development process
steps in order to comply with the requirements of this part of ISO 26262, and
the integration of these steps within the ISO 26262 framework.
The necessary activities and
processes for the product development at the hardware level include:
the hardware implementation of
the technical safety concept;
the analysis of potential
hardware faults and their effects; and
the coordination with software
development.
By contrast to the software development subphases, this part of ISO
26262 contains two clauses describing quantitative evaluations of the overall
hardware architecture of the item.
Clause 8 describes two metrics to
evaluate the effectiveness of the hardware architecture of the item and the
implemented safety mechanisms to cope with random hardware failures.
As a complement to Clause 8,
Clause 9 describes two alternatives to evaluate whether the residual risk of
safety goal violations is sufficiently low, either by using a global
probabilistic approach or by using a cut-set analysis to study the impact of
each identified fault of a hardware element upon the violation of the safety
goals.
Figure 7: Reference
phase model for the product development at the hardware level
Specification
of hardware safety requirements :
The first
objective of this clause is to specify the hardware safety requirements. They
are derived from the technical safety concept and system design specification.
The second
objective is to verify that the hardware safety requirements are consistent
with the technical safety concept and the system design specification.
A further objective of this phase
is to detail the hardware-software interface (HSI) specification
Hardware design :
The first objective of this clause is to
design the hardware in accordance with the system design specification and the
hardware safety requirements.
The second objective of this clause is
to verify the hardware design against the system design specification and the
hardware safety requirements.
Evaluation of
the hardware architectural metrics:
The objective of this clause is to
evaluate the hardware architecture of the item against the requirements for
fault handling as represented by the hardware architectural metrics.
Evaluation of
safety goal violations due to random hardware failures:
The objective of the requirements in
this clause is to make available criteria that can be used in a rationale that
the residual risk of a safety goal violation, due to random hardware failures
of the item, is sufficiently low.
Work products from part 5 of
ISO26262 standard are as follows:
·
Safety
plan (refined)
·
Hardware
safety requirements specification
·
Hardware-software
interface specification (refined)
·
Hardware
safety requirements verification report
·
Hardware
design specification
·
Hardware
safety analysis report
·
Hardware
design verification report
·
Specification
of requirements related to production, operation, service and decommissioning
·
Analysis
of the effectiveness of the architecture of the item to cope with the random
hardware failures
·
Review
report of evaluation of the effectiveness of the architecture of the item to
cope with the random hardware failures
·
Analysis
of safety goal violations due to random hardware failures
·
Specification
of dedicated measures for hardware, if needed, including the rationale
regarding the effectiveness of the dedicated measures
·
Review
report of evaluation of safety goal violations due to random hardware failures
·
Hardware
integration and testing report
Chapter 6: Product
Development Software Level
This part of ISO 26262 specifies
the requirements for product development at the software level for automotive
applications, including the following:
·
requirements for initiation of product
development at the software level,
·
specification of the software safety
requirements,
·
software architectural design,
·
software unit design and implementation,
·
software unit testing,
·
software integration and testing, and
·
verification of software safety requirements.
For each method, the degree of
recommendation to use the corresponding method depends on the ASIL and
is categorized as follows:
·
“++” indicates that the method is highly
recommended for the identified ASIL;
·
“+” indicates that the method is recommended for
the identified ASIL;
·
“o” indicates that the method has no
recommendation for or against its usage for the identified ASIL.
Initiation of product development at the software level:
The objective of this sub-phase is
to plan and initiate the functional safety activities for the sub-phases of the
software development.
Specification of software safety requirements:
The first objective of this
sub-phase is to specify the software safety requirements. They are derived from
the
technical safety concept and the
system design specification.
The second objective is to detail
the hardware-software interface requirements
Software architectural design:
The first objective of this
sub-phase is to develop a software architectural design that realizes the
software
safety requirements.
The second objective of this
sub-phase is to verify the software architectural design.
Software unit design and implementation:
The first objective of this
sub-phase is to specify the software units in accordance with the software
architectural design and the associated software safety requirements.
The second objective of this
sub-phase is to implement the software units as specified.
The third objective of this
sub-phase is the static verification of the design of the software units and
their
implementation.
Design principles for software
unit design and implementation at the source code level as listed in
Figure 8 shall be applied to
achieve the following properties:
·
correct order of execution of subprograms and
functions within the software units, based on the software architectural design
·
consistency of the interfaces between the
software units
·
correctness of data flow and control flow
between and within the software units.
·
Simplicity
·
readability and comprehensibility
·
robustness
·
suitability for software modification and
·
testability.
Figure 8 : Design principles for software
unit design and implementation
The
software unit design and implementation shall be verified by applying the verification
methods listed in Figure 9, to demonstrate:
Figure 9: Methods for
the verification of software unit design and implementation
Software unit testing:
The objective of this sub-phase
is to demonstrate that the software units fulfil the software unit design
specifications and do not contain
undesired functionality.
Software integration and testing:
The first objective of this
sub-phase is to integrate the software elements.
The second objective of this
sub-phase is to demonstrate that the software architectural design is realized
by
the embedded software.
Verification of software safety requirements:
The objective of this sub-phase
is to demonstrate that the embedded software fulfils the software safety
requirements.
Work products from part 6 of
ISO26262 standard are as follows:
·
Safety plan (refined)
·
Software verification plan
·
Design and coding guidelines for modelling and
programming languages
·
Tool application guidelines Software safety
requirements specification
·
Hardware-software interface specification
(refined)
·
Software verification plan (refined)
·
Software verification report
·
Software architectural design specification
·
Safety plan (refined)
·
Software safety requirements specification
(refined)
·
Safety analysis report
·
Dependent failures analysis report
·
Software verification report(refined)
·
Software unit design specification
·
Software unit implementation
·
Software verification report (refined)
·
Software verification specification
Chapter 7: Production
and Operation
This part of ISO 26262 specifies the requirements for
production, operation, service and decommissioning.
Production:
The first objective of this
clause is to develop and maintain a production process for safety-related
elements or items that are intended to be installed in road vehicles.
The second objective is to
achieve functional safety during the production process by the relevant
manufacturer or the person or organisation responsible for the process (vehicle
manufacturer, supplier, subsupplier, etc.).
Operation, service (maintenance and repair), and decommissioning:
The objective of this clause is
to specify the customer information, maintenance and repair instructions, as
well as disassembly instructions
regarding the item, system or element, in order to maintain the functional
safety over the lifecycle of the
vehicle.
Chapter8 : Supporting
Processes
This part of ISO 26262 specifies
the requirements for supporting processes, including the following:
·
interfaces within distributed developments,
·
overall management of safety requirements,
·
configuration management,
·
change management,
·
verification,
·
documentation,
·
confidence in the use of software tools,
·
qualification of software components,
·
qualification of hardware components, and
·
proven in use argument.
Interfaces within distributed developments:
The objective of this clause is
to describe the procedures and to allocate associated responsibilities within
distributed developments for items and elements.
Configuration management:
The first objective is to ensure
that the work products, and the principles and general conditions of their
creation, can be uniquely identified and reproduced in a controlled manner at
any time.
The second objective is to ensure
that the relations and differences between earlier and current versions can be
traced.
Change management:
The objective of change
management is to analyse and control changes to safety-related work products
throughout the safety lifecycle.
Verification:
The objective of verification is
to ensure that the work products comply with their requirements.
Documentation:
The primary objective is to
develop a documentation management strategy for the entire safety lifecycle in
order to facilitate an effective and repeatable documentation management
process.
Confidence in the use of software tools:
The first objective of this
clause is to provide criteria to determine the required level of confidence in
a software tool when applicable.
The second objective of this
clause is to provide means for the qualification of the software tool when
applicable, in order to create evidence that the software tool is suitable to
be used to tailor the activities or tasks required by ISO 26262 (i.e. the user
can rely on the correct functioning of a software tool for those activities or
tasks required by ISO 26262).
Qualification of software components:
The objective of the
qualification of software components is to provide evidence for their
suitability for re-use in items developed in compliance with ISO 26262.
Qualification of hardware
components:
The first objective of the
qualification of hardware components is to provide evidence of the suitability
of intermediate level hardware components and parts for their use as part of
items, systems or elements,
developed in compliance with ISO
26262, concerning their functional behaviour and their operational limitations
for the purposes of the safety concept.
The second objective of the
qualification of hardware components is to provide relevant information
regarding:
their failure modes,
their failure mode distribution,
and
their diagnostic capability with
respect to the safety concept for the item.
Proven in use argument:
This clause provides guidance for
a proven in use argument. A proven in use argument is an alternate means
of compliance with ISO 26262 that
may be used in the case of reuse of existing items or elements when field
data is available.
Chapter 9: ASIL
oriented and safety oriented analyses
This part of ISO 26262 specifies
the requirements for Automotive Safety Integrity Level (ASIL)-oriented and
safety-oriented analyses,
including the following:
·
requirements decomposition with respect to ASIL
tailoring,
·
criteria for coexistence of elements,
·
analysis of dependent failures, and
·
safety analyses.
Requirements decomposition with respect to ASIL tailoring:
This clause provides rules and
guidance for decomposing safety requirements into redundant safety
requirements to allow ASIL
tailoring at the next level of detail.
Criteria for coexistence of elements:
This clause provides criteria for
the coexistence within the same element of:
·
safety-related sub-elements with sub-elements
that have no ASIL assigned; and
·
safety-related sub-elements that have different
ASILs assigned
If safety-related sub-elements
with different ASILs, including QM(x) , coexist in the same element, then a
sub-element shall only be treated as a sub-element with a lower ASIL assigned
if evidence is made available that, for each safety requirement allocated to
the element, it cannot interfere with any sub-element with a higher ASIL
assigned. Otherwise, this sub-element shall be assigned the highest ASIL
of the coexisting safety-related
sub-elements for which evidence of freedom from interference is not made
available.
Analysis of dependent failures:
The analysis of dependent
failures aims to identify the single events or single causes that could bypass
or invalidate a required independence or freedom from interference between
given elements and violate a safety requirement or a safety goal.
Safety analyses:
The objective of safety analyses
is to examine the consequences of faults
and failures on the functions, behaviour and design of items and elements.
Safety analyses also provide information on conditions and causes that could
lead to the violation of a safety goal or safety requirement.
Additionally, the safety analyses
also contribute to the identification of new functional or non-functional
hazards not previously identified during the hazard analysis and risk
assessment.
Safety analyses are performed at
the appropriate level of abstraction during the concept and product development
phases. Quantitative analysis methods predict the frequency of failures while
qualitative analysis methods identify failures but do not predict the frequency
of failures. Both types of analysis methods depend upon knowledge of the
relevant fault types and fault models.
The results of the safety
analyses shall indicate if the respective safety goals or safety requirements
are complied with or not
If a safety goal or a safety
requirement is not complied with, the results of the safety analyses shall be
used for deriving prevention, or detection, or effect mitigation measures
regarding the faults or failures causing the violation
The measures derived from the
safety analyses shall be implemented as part of the product development at the
system level, or at the hardware level, or at the software level, respectively
in accordance with ISO 26262-4, or ISO 26262-5, or ISO 26262-6.
Work products from part 9 of
ISO26262 standard are as follows:
·
Update of architectural information
·
Update of ASIL as attribute of safety
requirements and elements
·
Update of ASIL as attribute of sub-elements of
elements
·
Analysis of dependent failures
·
Safety analyses
Chapter 10: Guideline
on ISO 26262
This part of ISO 26262 provides an overview of ISO 26262,
as well as giving additional explanations, and is intended to enhance the
understanding of the other parts of ISO 26262.
It has an informative character
only and describes the general concepts of ISO 26262 in order to facilitate
comprehension. The explanation expands from general concepts to specific
contents.
ISO 26262 uses the concept of safety goals and a safety concept as
follows:
·
a hazard analysis and risk assessment identifies
hazards and hazardous events that need to be prevented, mitigated or
controlled;
·
a safety goal is formulated for each hazardous
event;
·
an Automotive Safety Integrity Level (ASIL) is
associated with each safety goal;
·
the functional safety concept is a statement of
the functionality to achieve the safety goal(s);
·
the technical safety concept is a statement of
how this functionality is implemented on the system level by hardware and
software; and
·
software safety requirements and hardware safety
requirements state the specific safety requirements which will be implemented
as part of the software and hardware design.
Example
·
The airbag system: one of the hazards is
unintended deployment.
·
An associated safety goal is that the airbag
does not deploy unless a crash occurs that requires the deployment.
·
The functional safety concept can specify a
redundant function to detect whether the vehicle is in a collision.
·
The technical safety concept can specify the
implementation of two independent accelerometers with different axial
orientations and two independent firing circuits. The squib deploys if both are
closed.
Safety Element out of Context(SEooC):
·
SEooC development is required when OEM has asked
for a part of item not for complete item/system.
·
A SEooC is a safety element for which an item
does not exist at the time of development.
·
Requirements at the higher level remain as
“assumed” and confirmed when it is used.
·
The correct implementation is verified during
SEooC development and it is
validated in item delopment.
A SEooC can be a system, an array
of systems, a subsystem, a software component, a hardware component or a part.
Examples of SEooCs include system controllers, ECUs, microcontrollers, software
implementing a communication protocol or an AUTOSAR software component
The different steps of the application of the SEooC
concept to a new medium/low level software component. The process flow is given
in Figure 10.
Following notes shall be considered while development of
SEooC:
NOTE 1 : Some additional tailoring of the requirements can
be necessary depending on the exact nature of the SEooC.
NOTE 2 : Depending on the exact nature of the SEooC, some
requirements of part 6 are not applicable, and therefore only partial
consideration is made.
NOTE 3 : Although all the clauses of ISO 26262 are not
shown, this does not imply that they are not applicable.
Figure 10: SEooC
software component development
Work product
A work product is the result of
meeting the corresponding requirements of ISO 26262.
Therefore, a documented work
product can provide evidence of compliance with these safety requirements.
