Presentation On Standard ISO 26262

Dependable
Technologies Hands on the ISO 26262 Standard

For Critical
Systems
Functional Safety in Automotive Electronics
Christian Esposito
2010 Critical Software S.A.
Universit di Napoli Consorzio Interuniversitario per

Federico II lInformatica
Agenda
Generalities
Vocabulary
Management of Functional Safety
Concept Phase
Product Development: System Level
Product Development: Hardware Level
Product Development: Software Level
Production and Operation
Supporting Processes
ASIL-oriented and Safety-oriented Analyses;

Guidelines on ISO 26262
Conclusions
Dependable
Technologies
For Critical
GENERALITIES
Systems
3
::.. ISO 26262 (1/3)
ISO-26262 is an adaptation of IEC 61508

for the automotive industry.
It applies to safety-related road vehicle

E/E systems, and addresses hazards due
to malfunctions, excluding nominal
performances of active and passive
safety systems.
Risk is determined based on customer

risk by identifying the so-called
Automotive Safety Integrity Level (ASIL)
associated with each undesired effects.
It provides ASIL-dependent requirements

for the whole lifecycle of the E/E system
(incl. H/w and S/w components).
::.. ISO 26262 (2/3)
ISO-26262 is based upon a V-Model as a reference process

model for the different phases of product development.
::.. ISO 26262 (3/3)
Let us compare such standard with the DO-178B:

While DO-178B explicitly states its relevance for certification
in the avionics domain, ISO 26262 does not foresee official
certification measures. In both cases, the final safety
assessment is carried out on the artifacts created during the
development process.
Both standards define a software level that is a function of
the seriousness of the consequences of a failure of the item.
ISO 26262 defines 44 processes, while DO-178B only 7.
Both standards require the definition of the software life
cycle. ISO 26262 provides more guidance by proposing a V-
model based approach, while DO-178B describes activities
suggesting a waterfall-like approach.

ISO 26262 is more explicit in requiring coordination with the
hardware development processes. Finally, hardware
component qualification is not present in the DO-178B.
::.. Functional Safety
ISO-26262, as adaptation of IEC 61508, is focused on functional

safety. What is it?
::.. Functional Safety
ISO-26262, as adaptation of IEC 61508, is focused on functional

safety. What is it?
It is the part of the overall safety of a system, or piece of
equipment, that depends on the system or equipment
operating correctly in response to its inputs, including the
safe management of likely operator errors, hardware
failures and environmental changes.
The objective of Functional Safety is freedom from unacceptable

risk of physical injury or of damage to the health of people either
directly or indirectly (through damage to property or to the
environment).
Functional Safety is intrinsically end-to-end in scope in that it

has to treat the function of a component or subsystem as part of
the function of the whole system.
::.. Standard Structure
ISO-26262 is structured into the following parts:

1. Vocabulary;
2. Management of Functional Safety;
3. Concept Phase;
4. Product Development: System Level;
5. Product Development: Hardware Level;
6. Product Development: Software Level;
7. Production and Operation;
8. Supporting Processes;
9. ASIL-oriented and Safety-oriented Analyses;
10. Guidelines on ISO 26262.
Within this presentation we will go through all these different

parts of the standard.
Dependable
Technologies
For Critical
VOCABULARY
Systems
10
::.. Terms (1/8)
1. Anomaly: condition that deviates from expectations based on

requirement specification;
2. Automotive Safety Integrity Level (ASIL): one of the four
levels to specify the items necessary requirements of ISO
26262 and safety measures for avoiding an unreasonable
residual risk, with D representing the most stringent and A
the least one;
3. Availability: capacity of a product to be in a stete to execute
the function required under given conditions, at a certain
time or in a given period, supposing the required external
resources are available;
4. Cascading Failure: failure of an element of an item causing

other elements of the same item to fail;
5. Common Cause Failure (CCF): failure of two or more
elements of an item resulting from a singe specific event;
::.. Terms (2/8)
6. Confirmation Review: confirmation that a product meets the

requirements with the required level of independence;
7. Controllability: avoidance of the specified harm or damage
through the timely reaction of the persons involved;
8. Dedicated Measures: measures to ensure the failure rate
claimed in the evaluation of the probability of violation of
safety goals;
9. Dependent Failures: failures whose probability of
simultaneous occurrence cannot be expressed as the simple
product of the unconditional probabilities of each of them;
10. Degradation: strategy for providing safety by design after the
occurrence of failures;
11. Development Interface Agreement (DIA): agreement between
customer and supplier in which reciprocal responsibilities
are specified;
::.. Terms (3/8)
12. Dual Point Failure: failure resulting from the combination of

two independent faults that leads directly to the violation of a
safety goal;
13. Error: discrepancy between a computed, observed or
measured value or condition and the true, specified, or
theoretically correct value or condition;
14. Exposure: state of being in an operational situation that can
be hazardous if coincident with the failure mode under
analysis;
15. Failure: termination of the ability of an element or an item to
perform a function as required;
16. Failure Mode: manner in which an element or item fails;

17. Failure Rate: density of probability of failure divided by
probability of survival for a hardware element;
18. Fault: abnormal condition that can cause a failure;
::.. Terms (4/8)
19. Fault Model: representation of failure modes resulting from

faults;
20. Fault Reaction Time: time-span to perform the specified
action necessary for a successful transition to a safe state;
21. Fault Tolerant Time Interval: time-span in which the vehicle
function can be stressed with faults before a hazardous
event develops;
22. Freedom to Interference: absence of cascading failures that
could lead to the violation of a safety requirement;
23. Harm: physical injury or damage to the health of people;
24. Hazard: potential source of harm;
25. Hazard Analysis and Risk Assessment: method to identify

and categorize hazardous events of items and to specify
safety goals and ASILs related to the prevention or mitigation
of these hazards in order to avoid unreasonable risk;
::.. Terms (5/8)
26. Independence: absence of dependent failure between two or

more elements that could lead to a safety violation;
27. Independent Failures: failures whose probability of
simultaneous occurrence can be expressed as the simple
product of their unconditional probabilities;
28. Initial ASIL: ASIL resulting from the hazard analysis or the
ASIL resulting from a preceding ASIL decomposition;
29. Item: system or array of systems or a function to which ISO
26262 is applied;
30. Latent Fault: multiple point fault whose presence is not
detected by a safety mechanism nor perceived by the driver
within the multiple point fault detection interval;

31. Multiple Point Failure: failure, resulting from the combination
of several independent faults, which leads to safety
violations;
::.. Terms (6/8)
32. Multiple Point Fault: individual fault that, in combination with

other independent faults, leads to a multiple point failure;
33. Perceived Fault: fault whose presence is deduced by the
driver within a prescribed time interval;
34. Proven in Use Argument: evidence, based on analysis of field
data, that the likehood of any failure that could impair a
safety goal of an item that uses it is low enough according to
the applicable ASIL;
35. Proven in Use Credit: set of safety lifecycle subphases with
corresponding work products that can be substituted by
proven in use argument provided the candidate fulfills the
proven in use criteria;

36. Reasonably Foreseeable Event: event that is technically
possible and has a credible or measurable rate of
occurrence;
::.. Terms (7/8)
37. Regression Strategy: verification strategy to assure that

change of an element or item has not affected existing and
previously verified elements or items;
38. Residual Fault: portion of a fault that leads to the violation of
a safety goal, occurring in a hardware element, where that
portion of the fault is not covered by safety mechanisms;
39. Risk: combination of the probability of occurrence of harm
and the severity of that harm;
40. Safe Fault: fault whose occurrence will not significantly
increase the probability of violation of a safety goal;
41. Safety: absence of unreasonable risk;
42. Safety Goal: top-level safety requirement as a result of the

hazard analysis and risk assessment;
43. Severity: measure of the extent of harm to an individual;
::.. Terms (8/8)
44. Single Point Failure: failure that results from a single point
fault and leads to a safety violation;
45. Single Point Fault: fault in an element that is not covered by a
safety mechanism and that leads directly to a safety
violation;
46. Systematic Failure: failure of an element or item that is
caused in a deterministic way during development phases.
Dependable
Technologies
For Critical
MANAGEMENT OF FUNCTIONAL
Systems SAFETY
19
::.. Safety Lifecycle
The safety lifecycle

encompasses principal
safety activities during
concept, development and
production phases.
Develop a description of the item with

regards to its functions, interfaces, etc.

production phases.
Distinguish between either a new

development or a modification.

production phases.
Determine ASIL of the item by deriving

the safety goal for each hazard.

production phases.
Specify functional safety requirements

to the elements of the item.
production phases.

production phases.
Develop the item from the system
perspective, with respect to a V model.


production phases.
Develop the item from the hardware
perspective, based on the system

design specification.

production phases.
Develop the item from the software
perspective, based on the system

design specification.

production phases.
Plan production and operation, and
specify the associated requirements,

during product development.

production phases.
Provide product sign-off.

production phases.
Take credit from the ability of the driver
to control hazardous situations. Describe
measures outside the item to reduce the

risks resulting from the item. Consider
other technologies that are different from
those covered by ISO 26262.

production phases.
State requirements for the final

phases.

production phases.
State requirements for the final

phases.
::.. Recommendations for the Overall Safety
Management (1/2)
The organization shall establish, execute and maintain,
organization specific rules and processes compliant to ISO
26262, to timely and effectively dispose of functional safety
anomalies, and to ensure that unresolved anomalies are
explicitly communicated.
The organization will provide adequate resources for the

achievement of functional safety, e.g., by instituting a
continuous improvement process, ensuring that the person in
charge of the safety activities is given sufficient authority and
level of skills.
All the involved organizations have a quality management

system compliant with standards such as USO TS 16949 or ISO
9001.
::.. Recommendations for the Overall Safety
Management (2/2)
The safety lifecycle may be tailored in one of the following ways:
1. combining or splitting subphases,
2. performing an activity in a different subphase or even an
added one,
3. iterations within, or of, subphases.
The outcomes of the Overall Safety Management are a set of

organization-specific rules and processes for functional safety,
evidence for the competence and qualification of the persons in
charge of carrying out the activities and evidence of a proper
quality management system.
::.. Recommendations for the Safety Mana-
gement during Item Development (1/6)
Objectives are the definition of safety management roles and
responsibilities, and the definition of the requirements on the
safety management, regarding the development phases.
The inputs are taken from the previous outcomes, plus the
overall project plan, and the dependencies on other activities.
The organization shall determine a Project Manager with the

responsibility to ensure that safety activities are performed and
are compliant to ISO 26262. It has also to verify that enough
resources are provided.
The project Manager has to ensure that a person is appointed as

safety manager, i.e., responsible for the safety management
during item development. s, regarding the development phases.
The item safety lifecycle may be tailored, defined in the safety
plan and a rationale shall be available and documented.
The safety plan shall include the planning of:
1. strategies, and activities for achieving functional safety;
2. DIA, and supporting processes
3. Hazard analysis and risk assessment
4. Development of the safety requirements
5. Analysis of dependent failures, and the safety analysis
6. Verification and validation activities;
7. Confirmation measures for functional safety
8. Inclusion of overall safety activities into project-specific

safety management;
9. Provision of the proven in use arguments;
10. Definition of the tailored safety activities.
The activities described in the safety plan shall include:
1. The objective;
2. Dependences on other activities or information;
3. Required resources;
4. Starting point in time and duration
5. Identification of the respective work product.
If an item has a ASIL (A), B, C or D, the safety case shall:

1. Be developed in accordance with the authorized plan;
2. Progressively compile the work products generated during
the safety lifecycle;

The safety case shall be sufficiently complete. The confirmation
measures shall be planned and performed during item
development, as follows.
-: - no requi-
rement;
I0 - it should be
performed
I1 - it shall be
performed
I2 - It shall be
performed by a
person from a
different team;
I3 it shall be
performed by a
person from a
different depar-
tment or orga-
nization.
The confirmation measures shall be performed as follows:
The confirmation measures shall be accepted by who executes

them, provides the subject to be confirmed and needs the results.
gement after Release for Production
The safety management after release for production has the
objective to define the responsibility of the organizations and
persons responsible for functional safety after release for
production.
The activities for ensuring the functional safety after the item
after release for production shall be planned, and shall be
initiated during system development. The organization shall
institute processes and appoint persons for maintaining the
functional safety of the item in the lifecycle phases after release.
The organization shall execute a field monitoring process with

respect to functional safety. If the item after release for
production, the release for production shall be reissued.
::.. Overview of Functional Safety Mana-
gement
Dependable
Technologies
For Critical
CONCEPT PHASE
Systems
42
::.. Item Definition
The goals of this subphase is to define and describe the item

and support an adequate understanding so that each activity of
the safety lifecycle can be performed.
The functional requirements of the item, as well its

dependencies, shall be available. Already known safety
requirements shall be available.
The outcome of the subphase is the Item Definition.

::.. Initiation of the safety lifecycle
The goals of this subphase is to make the distinction between a

new development and a modification of a previously existing
item. In case of a modification proper safety lifecycle activities
needs to be defined.
An analysis shall be carried out so to identify the intended

modification applied to the item and its environment and to
assess the impact of these modifications. In case of
modifications, the areas affected by the changes shall be
properly identified and described.
The implication of the modification on functional safety shall be

described and safety activities shall be tailored. The outcome of
this subphase is an impact analysis.
::.. Hazard Analysis and Risk Assessment
The goals of this subphase is to identify and categorize the

hazards of the item and formulate the safety goals, and their
assigned ASIL, w.r.t. the prevention and mitigation of these
hazards trough a systematic evaluation of hazardous situations.
The rationale of ASIL determination consists of estimating

severity, probability and controllability of hazards, based on item
functional behaviour provided by the item description.
The outcomes of this subphase are the hazard analysis and risk
assessment, safety goals, and verification review of the previous
outcomes.
::.. Recommendations for the Hazard
Analysis and Risk Assessment (1/3)
The operational situations and operating modes where
malfunctioning behaviour is able to trigger hazards shall be
described, both for cases when the item is correctly used and
when it is incorrectly used.
The hazards of the item shall be systematically determined, with

techniques such as brainstorming, checklists, FMEA and field
studies, in terms of the conditions or events that can be
observed at the vehicle level. The effects of hazards shall be
identified for relevant operational situations.
All identified hazards shall be classified with respect to severity,

probability of exposure or controllability.
The severity scale is the following:
The probability of exposure scale is the following:
The controllability scale is the following:

ASIL shall be determined for each hazardous event using the

proper combination of the previous parameters.
ASIL assignment matrix (QM denotes no requirement):
A safety goal shall be determined for each hazard, and

expressed in terms of functional objectives.
::.. Functional Safety Concept
The goals of this subphase is to derive the functional safety

requirements, from the safety goals, and to allocate them to the
preliminary architectural elements so to ensure required safety.
At least one functional
requirement shall be
specified for each safety
goal, and considering
operating mode, fault
tolerant time interval,
safe states, etc.
The warning and degradation concept shall be specified, and a
safety architecture shall be developed. Within the analysis,

external elements and other technologies shall be considered.
The outcomes are functional safety concept and a review of the
functional safety requirements.
::.. Overview of Concept Phase
Dependable
Technologies
For Critical
PRODUCT DEVELOPMENT:
Systems SYSTEM LEVEL
51
::.. Initiation of Product Development at the
System Level
The objective of this subphase is to determine and plan the
functional safety activities during the subphases of the system
development, included in the safety plan.
System Level
After the initiation of the

product development and
specification of the technical
safety requirements, the system
design is performed.
System Level
The work pro-

ducts are the
technical safety
concept and
system design
specification.
System Level
Depending on the complexity of

the architecture, the

requirements can be derived
iteratively, and integrated after
the H&S implementation.
System Level
At the integration phase,

validation is performed to
provide evidence of functional
safety w.r.t. safety goals.

::.. Specification of the Technical Safety
Requirements (1/3)
The objective of this subphase is to develop the technical safety
requirements, which refine the functional safety concept
considering the preliminary architectural design.
In addition, a second objective is to verify through analysis that
technical safety requirements comply to the functional safety
requirements.
Such subphase is intended to bring item-level functional safety

requirements into system-level technical safety requirements,
down to the allocation to hardware and software elements.
In addition to the Safety goals and Functional safety concepts,

such subphase needs a validation plan and a preliminary
architectural assumptions.
Requirements (2/3)
The response of the system or any of its elements to stimuli,
including failures shall be specified for each technical
requirement, in combination for each possible operating state.
Safety mechanisms shall be described, including measures for

detection and control of faults, how the system achieves a safe
state, implementation of the degradation concept, and
preventing faults to being latent.
Validation criteria shall be indicated, and for each safety

mechanism, there shall be specified:
1. The transition to the safe state;

2. The fault-tolerant time interval;
3. The emergency operation interval;
4. Measures to maintain the safe state.
Requirements (3/3)
If mechanism preventing faults to being latent, the multiple point
fault detection interval shall be indicated, considering the
reliability of hardware components, ASIL rating of the related
safety goal and its corresponding probability of exposure.
Newly identified hazards shall be introduced and evaluated, and

technical safety requirements specification shall be verified
through analysis.
The outcomes of such subphase are the technical safety

requirements specification, a refined version of the validation
plan and the system-level verification report.

::.. System Design (1/5)
The scope of this subphase is to develop the system design and

technical safety concept, in accordance to the functional
requirements and the preliminary architectural assumptions.
Moreover, such two outcomes will be also verified against the
technical safety requirements specification.
In the system design development, the following shall be

considered: 1) the verifiability of the system design, 2) the
effectiveness of the H&S development, and 3) the testability
during system integration.
If requirements with different ASIL are allocated to the same

architectural element, the highest ASIL is considered, unless its
implementation meets the criteria for coexistence, see part 9,
where ASIL decomposition is also described.
Deductive and inductive analysis can be used for identifying

systematic failures:
If such failures cannot be avoided, their effect needs to be well

known and mitigated. Well-trusted design principles should be
applied:
1. Re-use of well-trusted safety architecture;
2. Re-use of well-trusted design for H&S components;
3. Re-use of well-trusted mechanisms for detecting and

controlling failures;
4. Re-use of well-trusted or standardized interfaces.
In case of ASIL D, the decision of not re-use should be justified.
Hierarchical design and the avoidance of unnecessary

complexity is used to achieve an adequate level of granularity.
Measures to deal with random hardware failures shall be
indicated.
Every technical safety requirement shall be allocated to

hardware, software, or even both, either directly or by further
refinement. Partitioning is used to achieve independence.
Hardware software interface specification(HIS) shall be defined

during both hardware and software development, and HIS
requirements shall identify each part of the HIS that is involved

in a technical safety concept, indicating hardware devices
controlled by software and hardware resources that support
software execution.
Appropriate measures to support field monitoring and to collect

data shall be established. The system design should include the
specification of diagnostic features to allow fault identification.
Requirements for production, operation, service and

decommissioning identified are indicated during system design.
System design shall be verified with respect to technical safety

concept, and possible hazards shall be analyzed:
Item integration and testing plan shall be detailed including

specification of integration tests, thus ensuring that open
verification issues are included. Moreover, verification shall
provide evidence of compliance with safety requirements for
each configuration.
The outcomes of this subphase are the Technical safety concept,

System design specification, Requirements for production,
operation, service and decommissioning, refined Item
integration and testing, refined System-level verification report
and HSI.
::.. Item Integration and Testing (1/10)
The scope is to integrate the different parts that compose the

system, included other technologies and/or external entities, and
to test the obtained product to comply with each safety
requirement and to verify that the design has been correctly
implemented.
The integration and testing is carried out in an systematic

manner from software-hardware integration, and going through
integration of systems up to vehicle integration, with specific
tests performed at each integration phase.
The adopted integration and test strategy shall be detailed and

based on the system design specification, functional safety
concept and integration and test plan.
Each functional and technical safety requirements shall be tested

at least once in the complete integration phase. Tests shall be
formulated using a combination of the following methods:
In case of ASIL c and D, the HIS requirements shall be completely

tested or a rationale shall be provided that no issues exist.
To detect systematic faults, the tests during H&S integration

shall consist into a proper combination of well-known methods.
Tests will be used to verify the correct implementation of design

specification and technical safety requirements:
The correct performance of the safety mechanism is tested as:

Correctly of the implementation of interfaces shall be tested as:
While, the effectiveness of hardware fault detection mechanisms:
Last, robustness shall be ensured by applying:

To detect systematic faults, the tests during system integration

shall consist into a proper combination of well-known methods.
The correct implementation of the system design specification,

and the safety requirements shall be proved as follows:
While, the correct functional performance of safety mechanism

as follows:
Correct implementation of interfaces shall be ensured as follows:
The effectiveness of safety mechanisms is proved as follows:

Last, robustness shall be tested with:
The system will be integrated within the vehicle, and proper tests
shall be performed during such integration phase.
Tests will also cover the verification of on-board communication

network and on-board power supply network.
The correct implementation of the functional safety requirements

shall be ensured by applying:
The correct functional performance of the safety mechanisms:

The correctness of interface implementation is proved by:
Effectiveness and coverage of safety mechanisms is tested with:

Last, robustness of the item shall be verified by applying:
The outcome of this subphase is the Integration testing

specification and reports on the Integration testing activity.

::.. Safety Validation (1/2)
The scope is to prove that the safety exhibited by the item is

appropriate for the defined requirements.
The objective of the previous verification activities is to assure

that the results of each activity were compliant with the specific
requirements, while this one aims to provide evidence of the
appropriateness of the realized item, which has been integrated
at the vehicle level.
The validation plan shall include:

1. The configuration of the item;
2. The specification of test cases and acceptance criteria;

3. The required environmental conditions.
::.. Safety Validation (2/2)
The validation activities should provide evidence of the absence

of erroneous activation of safety mechanisms, and of compliance
to the safety goals, by means of the following methods:
Reproducible tests with specific procedure and pass/fail
criteria;
Analysis (e.g., FMEA, FTA, ETA, simulation);
Long-term tests, such as vehicle driving schedules and
captured test fleets;
User tests under real-life conditions;
Reviews.
The outcomes are a refined validation plan and a validation

report.
::.. Functional Safety Assessment
The scope is to evaluate the functional safety achieved by the

item, and for each step of the item lifecycle, a specific
assessment will be identified.
The outcome is a Functional safety assessment report.

::.. Release for Production
The objective is to specify the criteria for the release at the

completion of the development phase, so to confirm that the item
complies with the requirements, and is ready for series-
production and operation.
The documentation to be release, named Release for producion

report, shall include:
1. Name and signature of the person in charge;
2. Versions/s of the released item;
3. Configuration of the released item;
4. References to associated documents;

5. Release date.
::.. Overview (1/2)
::.. Overview (2/2)
Dependable
Technologies
For Critical
Systems HARDWARE LEVEL
81
Hardware Level
The scope is to determine and plan the functional safety
activities during the individual subphases of hardware
development, which is included in the safety plan.
Integration of the following

activities is crucial: Hardware
implementation of the
technical safety concept;
Analysis of potential faults
and their effect; and
Coordination with software

development.
The outcomes are a refined overall project plan and a refined

safety plan.
::.. Specification of Hardware Safety
Requirements (1/2)
The scope is to make available a consistent and complete
hardware specification that will be applied to the hardware of the
item or element under consideration, and to verify that the
hardware safety requirements are consistent with the technical
safety concept. Last, an additional objective is to detail the HIS.
A consistent and complete hardware safety requirements

specification for the hardware of the element under
consideration shall be derived from the technical safety
requirements allocated to hardware, including
How to control internal failures;
How to tolerate external failures;

How to comply with requirements of other elements;
How to detect and signal internal or external failures.
::.. Specification of Hardware Safety
Requirements (2/2)
The hardware safety requirements shall be verified to show:
Consistency with the technical safety concept, the system
design specification and the hardware specification;
Completeness with respect to the technical safety
requirements allocated to the hardware;
Correctness and accuracy.
The person responsible for hardware and software development

shall jointly verify the adequacy of the refined HIS specification.
The outcomes are Hardware safety requirements specification

and verification report, Hardware architectural metrics
requirements, and refined HIS specification.
::.. Hardware Design (1/3)
The objective is to design the hardware with respect to the

system design specification and hardware safety requirements,
and to verify such a design against the system design
specification and hardware safety requirements.
Hardware design includes two distinct activities:

All hardware components and their interactions are
represented;
Hardware detailed design, where interactions between
hardware parts are represented at the level of electrical
schematics.
Each hardware element shall inherit the highest ASIL from

requirements that it implements; if it is composed of sub-
elements with different ASIL, then each will be treated with the
highest one, unless the criteria for coexistence are met.
The traceability between the hardware safety requirements and

their implementation shall be maintained down to hardware
components. Well-trusted hardware components should be
considered for re-use.
Non-functional causes for failure shall be considered during the
design. Detailed design shall ensure that hardware parts are
used within their environmental and operational specifications.
Safety analysis shall determine causes and effects of faults:
Effectiveness of the safety mechanisms to avoid single/multiple

point faults remaining latent shall be proved. If a new hazard is
identified, it is evaluated in the hazard analysis and risk
assessment.
The hardware design shall be verified for compliance and

completeness with regards to the hardware safety requirements:
Instructions for assembly, disassembly, maintaining and

decommissioning of safety-related hardware elements shall be
issued, if these operations can impact the safety concept.
The outcomes are Hardware design specifications, Hardware

safety analysis report, Hardware design verification report and
Requirements for production and operation.
::.. Hardware Architectural Metrics (1/2)
The objective is to evaluate the hardware architecture of the item

against the requirements for fault handling as represented by the
hardware architectural metrics, defined to achieve:
Be objectively assessable;
Support the evaluation of the final design;
Make available ASIL dependent pass/fail criteria;
Reveal if the coverage of safety mechanism is sufficient;
Address single/multiple point or residual faults;
Be robust w.r.t. uncertainty of hardware failure rates;
Be limited to safety-related elements;
Be usable on different elements levels.
The analysis is conducted only for random hardware failures,

and the parts considered in the analysis ate the electric and
electronic parts; while for the electromechanical parts, only the
electrical failure modes and failure are considered.
::.. Hardware Architectural Metrics (2/2)
The considered metrics are:
" !F %
diagnostic coverage: $1! ' (100
# !&
" ( ! + ! ) "( ! + ! )
SPF RF MPF S
single point faults metric: 1! =
"! "!
latent fault metric: 1!

"( ! MPF Latent ) =
" ( !MPF perceived or det ected + !S )
"( ! ! ! SPF ! !RF ) "( ! ! ! SPF ! !RF )
If sufficient evidence of the failure rate cannot be made,

alternative means should be proposed. The outcomes are
Assessment of the effectiveness of the system architecture to
cope with hardware random failures and its review.
::.. Evaluation of Violation of the Safety Goal
due to Random HW Failures (1/7)
The scope is to infer if the residual risk of safety goal violation,
due to random hardware failures of the item, is sufficient low.
The used methods evaluate the residual risk of safety goal

violation due to single point faults, residual faults, and plausible
dual point faults, by also considering coverage of safety
mechanisms and exposure duration in case od a dual point fault:
Use of a probabilistic metric to evaluate the violation (e.g.,
quantifies FTA), and comparison with a target value;
Individual evaluation of each residual and single point fault,
and of each dual point failure.
The parts considered are electrical and electronic ones, while for
electromechanic parts, only electrical failure modes and failure
rate are considered.
Reference target values are derived from:
Quantitative analysis techniques applied on similar well-
trusted designs using well known failure rate databases;
Field data of similar well-trusted designs;
Following table:
A single point fault occurring in a hardware part, shall only be

considered acceptable if dedicated measures are taken to
ensure the accuracy of its estimated failure rate.
A residual fault with a diagnostic coverage lower than 90% shall

be considered as acceptance only if the corresponding hardware
part is dealt with dedicated measures to justify the failure rate
claimed in the analysis.
The estimated failure rates shall be taken from:
A recognized industry source;
Statistics based on field returns or tests;
Expert judgements founded on engineering approach
based on quantitative and qualitative arguments.
Failure rates combined from multiple sources shall be scaled to
be consistent.
In the second method, each single
point fault is evaluated using the
occurrence of the fault, while each
residual one is assessed
combining the occurrence of the
fault and efficiency of the safety
mechanism.
In the case of dual point failures,

each failure is first evaluated
r e g a r d i n g i t s p l a u s i b i l i t y. I f
plausible, the faults causing it are
then evaluated combining the

occurrence of the fault and
efficiency of the safety mechanism.
The failure rate class raking can be determined as follows:
Failure class 1 contains rates less than the target for ASIL
D divided by 100;
Failure class 2 contains rates less than ten times the
failure rates corresponding to class 1;
Failure class 3 contains rates less than a hundred times
the failure rates corresponding to class 1;
In general, the failure class i with i > 3, contains rates less
than 10(i-1) times the failure rates corresponding to class 1.
A single point fault shall only be considered as acceptable, if
the corresponding failure rate is ranked in class 1 and
dedicated measures are taken (for ASIL D)

The failure rate is ranked in class 2 and dedicated
measures are taken, or ranked in class 1 (for ASIL C);
The failure rate is ranked in class 2 or 1 (for ASIL (B)).
A residual fault shall be considered acceptable if its failure rate
ranking and the diagnostic coverage comply with the targets:
In case of failure rate belonging to a class i, with i > 3, a residual

fault shall be considered as acceptable if the diagnostic
coverage is equal to (100% - 10(3-i)).
A dual point failure shall be considered plausible if:
Diagnostic coverage of less than 90% or one of the faults
causing the failure remains latent for a time longer that the
multiple point fault detection interval (w.r.t. ASIL D);
Diagnostic coverage of less than 60% or one of the faults
causing the failure remains latent for a time longer that the
multiple point fault detection interval (w.r.t. ASIL C);
It is not plausible (w.r.t. ASIL C and D);
It is plausible and hardware part complied wit the targets
for the failure rate classes and diagnostic coverage:
The outcomes are Evaluation of random hardware failures,

Specification of dedicated measures and Review report of
evaluation of violation of the safety goal due to random HW
failures.
::.. Hardware Integration and Testing (1/3)
The scope is to ensure the compliance of the developed

hardware with its requirements. Tests shall be planned and
specified w.r.t. the safety plan, and executed w.r.t. the item
integration and testing plan.
Test equipment shall be calibrated w.r.t. international standards
or company standards.
This activity shall verify the completeness and correctness of

the implementation of safety mechanisms w.r.t. hardware safety
requirements.
This activity shall verify the

robustness of hardware
against external stresses.
The outcome is Hardware

integration and verification
report.
::.. Overview (1/2)
::.. Overview (2/2)
Dependable
Technologies
For Critical
Systems SOFTWARE LEVEL
103
Software Level (1/3)
The scope is to plan and initiate the functional safety activities
for the following subphases of the software development.
Specifically, appropriate methods, and relative tools shall be
determine to achieve the requirements of the assigned ASIL.
To support correctness of the design and implementation,
guidelines for the modeling, or programming languages shall
address the following topics:
The criteria to be considered when selecting a suitable modeling
or programming language are:
An unambiguous definition;
Support for embedded real-time software and runtime
error handling;
Support for modularity, abstraction and structured
constructs.
The outcomes are a refined Safety plan, a Software verification

plan, Design and coding guidelines for modeling and
programming languages, and Software tool application
guidelines.
::.. Specification of Software Safety
Requirements (1/2)
The goal is to specify the software safety requirements, derived
from the technical safety concept and system design
specification, to detail the HIS requirements, and to verify that
the software requirements are consistent with the technical
safety concept and the system design specification.
The specification of software safety requirements considers the

constraints imposed by the hardware and their impact on the
software. In addition, it shall address each software-based
function whose failure could lead to a violation of a technical
safety requirement allocated to software.
The HIS specification initiated in the previous part shall be

detailed down to a level allowing the correct control and usage
of hardware, and shall describe each safety-related dependency
between hardware and software.
::.. Specification of Software Safety
Requirements (2/2)
If other functions, in addition to the one safety-related, are
carried out by the embedded software, they shall specified, or a
reference to their specification is indicated.
A verification activity shall be performed to demonstrate that the

software safety requirements are compliant with the technical
safety requirements, the system design and consistent with the
relevant parts of the hardware safety requirements.
The outcomes are Software safety requirements specification, a

refined of the HIS specification, a refined of the Software
verification plans and report.
::.. Software Architectural Design (1/5)
The objective is to develop a software architectural design that

realizes the software safety requirements and to verify the
software architectural design.
The software architectural design represents all software

components and their interactions with one another in a
hierarchical structure. Both static and dynamic aspects need to
be described.
The software architectural design shall exhibit modularity,

encapsulation and minimal complexity by using the following
principles:
The software architectural design shall be developed down to

the level where the software units, treated as indivisible, are
identified, and describe static and dynamic design aspects of
software components.
Safety-related software components that are reused without

modifications or that are COTS products shall be qualified.
The software safety requirements shall be allocated to the

software components, so that each inherits the highest ASIL of
any requirement allocated to it. If software is implemented by
combining several components with different ASILs, then all of
them will be treated w.r.t. the highest ASIL, unless they meet the
criteria for coexistence.
If software partitioning is used to implement freedom from

interference between software components, it shall ensure that:
Shared resources are properly used;
The partitioning is supported by dedicated hardware
features or equivalent means;
The software part that implement the partitioning shall

have the same or higher ASIL of the highest ASIL
associated with the software partitions;
Correct verification is performed.
Safety analysis shall be carried out to identify or confirm safety-

related characteristics of software components, and support
specification of the safety mechanisms.
An analysis of dependent failures shall be carried out if the

implementation relies on freedom from interference. To specify
the needed safety mechanisms, the following mechanism for
error detection and for error handling shall be applied:
If new hazards are identified, they shall be introduced and

analyzed in the hazard analysis and risk assessment.
The software architectural design shall be verified by using the

following software architectural design verification methods:
The outcomes are Software Architectural design Specification,

refined Safety plan, refined Software safety requirements
specification, Safety analysis report, Dependent failures analysis
report and refined Software verification report.
::.. Software Unit Design and Implementation
(1/3)
The goal is to specify the software units in accordance with the
software architectural design and the associated software safety
requirements, to implement the software units as specified and
to verify the design of the software units and their
implementation.
The detailed design is developed as a model or directly as

source code. The detailed design and the implementation are
verified before proceeding to the software unit testing phase.
The design shall be described using the following notations:

(2/3)
The specification shall describe the functional behaviour and
internal design, while the design and implementation shall
achieve: avoidance of unnecessary complexity, testability and
maintainability. In case of manual coding, these properties are
referred to the source code, while in case of model-based
development, to the model. The following properties are needed:
Correct execution order;
Interface consistency;
Correct data/control flow
Simplicity;
Readability and compre-
hensibility;
Robustness;
Change suitability;
Testability
(3/3)
Design and implementation shall be verified to demonstrate:
Compliance with HSI;
Completeness w.r.t.
requirements and
architecture though
traceability;
C o m p l i a n c e w i t h
specification and
guidelines;
Compatibility with
Target hardware.
Outcomes are Software

unit design specification
and implementation and a
refined Software verifi-
cation report.
::.. Software Unit Testing (1/3)
A procedure for testing the software unit against its specification

is established.
The following testing methods can be used for proving

compliance with specification and HIS, correct implementation,
absence of unintended functionality, robustness, and sufficiency
of the resources.
To demonstrate the appropriate specification of test cases, test

cases shall be derived using the following methods:
To evaluate the completeness of test cases and to demonstrate

there is no unintended functionality, the coverage of
requirements shall be determined and measured as follows:
The testing environment should be as far as possible to the

target one, otherwise differences shall be analyzed.
The outcomes are refined Software verification plan, Software

verification specification, and the refined Software verification
report.
::.. Software Integration and Testing (1/3)
The scope is to integrate the software components and

demonstrate that the software architecture is correctly realized.
Integration levels are tested against the architectural design.
The integration test methods shall prove that the software is

compliant with software architectural design, and the
specification of HSI, correct implementation of the
functionalities, robustness and sufficiency of resources.
To demonstrate the appropriate specification of the test cases,

they shall be derived from:
The test coverage shall be measured as follows:

The test environment should be as close as possible to the

target one, otherwise an analysis of the differences is needed.
The outcomes are refined Software verification plan and

specification, Embedded software, Software verification report.
::.. Verification of Software Safety
Requirements
The goal is to demonstrate that the embedded software fulfills
the software safety requirements. Test shall be conducted in the
test environments listed here, and on the target hardware:
The obtained results should be evaluated w.r.t. compliance with

the expected results, coverage of the software safety
requirements and a pass/fail criteria.
Outcomes are refined Software verification plan, specification

and report.
::.. Overview (1/2)
::.. Overview (2/2)
Dependable
Technologies
For Critical
PRODUCTION AND OPERATION
Systems
126
::.. Production
The objective is to develop a production plan for safety-related

products, and also to guarantee that functional safety is achieved
during the production process.
It is well known that certain characteristics of the products are

safety-related, and this phase aims at defining requirements and
recommendations w.r.t. these characteristics.
A production plan will be formalized with the series of methods

of the production steps required to achieve functional safety of
the item. Moreover, the correct embedded software and
associated calibrated data shall be assured to be loaded in the
ECU. Last, process failures shall be foreseen and proper

methods to monitor and deal with them will be adopted and
described in a Production control plan and Documentation of
performed control measures.
::.. Operation, Service (Maintenance and
Repair), and Decommissioning
The objective is to define the scope of the customer support
instructions regarding the safety-related products so to maintain
the required functional safety during the vehicle operation, and
to provide requirements for activities before disassembly.
A user manual shall include relevant instructions on how to use

the item in the intended way, warning concept and required user
reaction, maintenance activities and warning signals, known
hazards due to interactions with third party products.
Instructions shall be included for measures to be taken before

disassembling the vehicle.
The outcomes are the refined Maintenance plan, Repair

Instructions, User manual, Instructions regarding field
observations and for decommissioning.
::.. Overview
Dependable
Technologies
For Critical
SUPPORTING PROCESSES
Systems
130
::.. Interfaces with Distributed Developments
(1/3)
The objective is to describe procedures and allocate
responsibilities within distributed developments for items and
elements. Just as the customers safety-related specifications
concerning planning, execution and documentation for in-house
development projects, similar procedures have to be agreed for
co-operation with the supplier on distributed developments.
Supplier selection criteria shall include an evaluation of the

suppliers capacity to develop and produce items of comparable
complexity and ASIL.
The RFQ from the customer to the supplier candidates shall

include a formal request, item definition or its functional
specification, and the safety goals and safety requirements.
(2/3)
The customer and supplier shall agree upon a DIA, including:
The appointment of a safety manager at both sides;
The joint tailoring of the safety lifecycle;
Activities and processes to be performed by the customer
and activities to be performed by the supplier;
Information required and work products of these activities
to be exchanged;
Persons responsible for these activities;
Communication of the target values;
Supporting processes and tools.
In the case the supplier conducts the hazard analysis and risk
assessment, the customer shall be able to read it.
The functional safety requirements shall be agreed between
customer and supplier.
(3/3)
The supplier shall notify the customer of increasing risk of not
conforming to any provisions of the DIA, and report each safety-
related event occurring within its area of responsibility.
The supplier shall determine if any safety requirement that

cannot be complied with; the relative safety concept shall be
checked and modified to yield safety requirements. Any change
shall be promptly communicated to the other party.
The outcomes are Supplier selection report, DIA, Suppliers

project and safety plan, Safety assessment report and Supply
agreement.
::.. Specification and Management of Safety
Requirements (1/2)
The scope is to provide the correct specification of safety
requirements, and a consistent management. During the safety
lifecycle, safety requirements are specified in a hierarchical
manner, with no duplication of information within any level.
To s u p p o r t t h e
management of safety
requirements, the use
of suitable tools is
recommended.
::.. Specification and Management of Safety
Requirements (2/2)
Safety requirements shall be specified by an appropriate
combination of natural language and the following methods:
Safety requirements shall be allocated to an item or element of

the system under development. They should also be un-
ambiguous, comprehensible, atomic, internally consistent,
feasible and verifiable.
A safety requirement sgould have a unique identifier that remain

unchanged during the product lifecycle, a status, and a ASIL.
The outcome is a refined Safety plan.

::.. Configuration Management
The goal is to ensure that the work products can be uniquely

identified and reproduced at any time, and the differences
between different versions can be traced. Configuration
Management is a common practice in the automotive industry
and regulated by the ISO TS 16949 and ISO 10007:2003.
Each work of ISO 26262 is managed by it, and maintained

throughout the entire safety lifecycle.
The outcome is a Configuration management plan.

::.. Change Management
The goal is to analyze and manage changes to safety-related

work products occurring throughout the safety lifecycle, by
ensuring the systematic planning, controlling, monitoring,
implementing and documenting of changes, while maintaining
the consistency of each work product.
The change management shall be defined and initiated before

bringing any change, and products subject to changes should be
identified.
An impact analysis shall be carried out for each change request.

A decision on the request should be taken by authorized
persons; in addition a responsible for the change and when to do

it shall be identified.
The outcomes are Change management plan, Change request,

Impact analysis and Change report.
::.. Verification
The goal is to ensure that the work products are correct,

complete and consistent, applicable to the following phases:
In the concept phase;
In the development phase for verifying:
The products of the design phase;
The products of the test phase;
In the production and operation phase for verifying:
The transformation of safety requirements into
production processes, user manuals or maintenance
instructions;
The meeting of safety-related properties of the item.
The specification of verification shall specify and select the

methods to be used, such as reviews or analysis checklists,
simulation scenarios or test cases and data.
The outcomes are Verification plan, specification and report.
::.. Documentation
The goal is to develop a documentation management strategy, so

that every phase of the entire safety lifecycle can be worked
through effectively and can be reproduced.
The documentation can take various forms and structures, and

tools can be used to generate documents automatically.
Duplication of information within a document or between
different document should be avoided to aid maintainability.
The outcomes are Documentation Management plan and

Documentation requirements.
::.. Qualification of Software Tools (1/4)
The goal is to provide evidence of software tolls suitability for

use when developing a safety-related item or element.
To determine the required level of confidence in a software tool,

an analysis needs to be carried out to evaluate if its erroneous
output or malfunctioning behaviour can violate any safety
requirement (expressed as TI), and the probability of preventing
or deleting such errors in output (expressed as TD).
The required confidence level (expressed as TCL) together with

the ASIL of the safety-related item or element to be developed
using the software tool allows selecting the appropriate

qualification methods.
There are two classes of TI: TI0 shall be chosen when there is an
argument that it is not possible to have a safety violation, TI1 in
other cases.
There are four classes for TD: TD1 indicated there is an high
confidence for preventing or deleting the error, TD2 is chosen in
case of a medium confidence, TD3 is chosen in case of a low
confidence, and TD$ in all other cases.
The level of TCL is chosen based on TI and TD:

TCL1 shall be selected for TI0;
TCL1 shall be selected for TI1 and TD1;

TCL4 shall be selected in all other cases.
A tool classified as TCL1 needs no qualification measures, while

in other cases the methods to be used as the follows:
TCL2
TCL3
TCL4
The tool qualification needs to be properly documented, and also

the development of the software tool shall comply with an
appropriate standard.
The validation of a software tool shall demonstrate that it fulfills

its specified requirements with the determined coverage of
requirements, analyze malfunctions or erroneous outputs,
investigate the reaction of the tool to anomalous operating
conditions, and examine the tool robustness.
The outcomes are Software tool classification analysis, Software

tool qualification plan, Software tool documentation and

Software tool qualification report.
::.. Qualification of Software Components
The scope is to enable the re-use of existing software

components without completely re-engineering the software
components, and to show their suitability for re-use.
To show that the software components complies with its

requirements, normal behaviour and behaviour in case of failure
shall be studied, and the mapping between provided behaviour
and requested one is defined.
The outcomes are the Software component documentation,

Software component qualification report, and a refined Safety
Plan.
::.. Qualification of Hardware Components
(1/2)
The scope is to show the suitability of intermediate level
hardware components and parts of their use as part of items or
elements, concerning their functional behaviour and their
operational limitations; and to provide relevant information
regarding their failure modes and their distribution, and their
diagnostic capability.
If the component does not contribute to any safety requirement

by itself, qualification is sufficient; otherwise, in addition to the
qualification, testing and integration will be carried out as in any
other item developed during the safety lifecycle.
Usually qualification can be applied to components or parts

whose failure modes or malfunctions are known and which are
adequately testable regarding their possible defects.
::.. Qualification of Hardware Components
(2/2)
Qualification can be carried out using two different methods:
testing or analysis, to be used individually or in combination:
When testing, the hardware component is exposed to the
same environmental and operational conditions it is
intended for, and compliance with its functional
requirements ought to be assessed;
When analyzing, a hardware component is studied based
on the rationale for the analytical methods and
assumptions used.
Directions present in ISO 16750 are useful for defining the
qualification tests. The qualification report shall state whether
the hardware component has passed or failed the qualification.
The outcomes are the Qualification plan, Hardware component

testing plan and Qualification report.
::.. Proven in Use Argument (1/2)
The scope is to provide guidance for proven in use argument,

which is an alternate means of compliance with ISO 26262
requirements to be used in case of reuse of existing items or
elements when field data is available.
It can be applied to any type of product whose definition and

conditions of use are identical to or have a very high degree of
commonality with a product that is already release and in
operation.
The proven in use argument is substantiated by appropriate

documentation on the candidate, configuration management and

change control records, and field data regarding safety-related
incidents.
::.. Proven in Use Argument (2/2)
For a prove in use status to be obtained by the candidate, its

service period shall demonstrate compliance with the safety
goals as follows with single sider lower confidence level of 70%:
For the application of the proven in use credit to be anticipated,

before a proven in use status is obtained, the candidate service
period shall demonstrate compliance with the safety goal as
follows with single sider lower confidence level of 70%:
The oucomes are Proven in use credit, Definition of candidate for

prove in use argument and Proven in use analysis reports.
::.. Overview (1/2)
::.. Overview (2/2)
Dependable
Technologies
For Critical
ASIL-ORIENTED AND SAFETY-
Systems ORIENTED ANALYSES
151
::.. Requirements Decomposition with
Respect to ASIL Tailoring (1/3)
The objective is to provide rules for decomposing safety
requirements with ASIL tailoring, which allows implementing
safety requirements redundantly by independent architectural
elements and potentially assigning lower ASILs to these
redundant safety requirements.
Such techniques can be used during Functional safety concept,

System design, Hardware design and/or Software design. If it is
applied at the software level, appropriate measures shall be
taken at system and hardware level for sufficient independence.
If ASIL decomposition is applied by apportioning a given

functionality and its related safety mechanism, then the last one
should be assigned the highest decomposed ASIL, and the
functionality shall become a safety requirement and implemented
using its decomposed ASIL.
If the obtained decomposed functions do not result in a safe
state by switching them off, sufficient availability of the item shall
be shown. Decomposition is applied as follows:
The integration of the decomposed elements shall be applied at
the ASIL before decomposition.
The outcomes of this activity are Update of architectural

information, and Update of ASIL as attribute of safety
requirements and elements.
::.. Criteria for coexistence of elements (1/2)
The scope is to provide guidelines for the coexistence within the

same element of safety-related sub-elements with non-safety-
related ones and sub-elements with different ASILs.
By default, in case a composition, each of the sub-elements is

developed w.r.t. the highest ASIL; however, there are cases
where is preferable to avoid raising the ASIL for some sub-
elements to the ASIL of the parent element. The driving idea is to
determine the degree of interference of the given sub-element
with the rest of its parent element.
This operation is applicable during System design, Hardware

design or Software design.
::.. Criteria for coexistence of elements (2/2)
A non-safety-related sub-element coexisting with safety-related

sub-element(s) shall be treated as QM if there is no functional
dependency, and there is no interference with any other safety-
related sub-elements. Otherwise, it will receive the highest ASIL
of the coexisting safety-related elements with which there may be
interference.
A safety-related sub-element shall receive the lower ASIL if it

does not interfere with any other element with higher ASIL, for
each safety requirement allocated to the element. Otherwise, it
will have the highest ASIL.
The outcome is the Results of application of coexistence criteria.

::.. Analysis of Dependent Failures (1/2)
The objective is to identify any event that could bypass the

independence from interference between elements a load to
several dependent failures.
The analysis will focus on:

1. Similar and dissimilar redundant elements;
2. Functions implemented with identical H&S elements;
3. Functions and their relative safety mechanisms;
4. Partitions of functions or software elements;
5. Physical distance between hardware elements.
Find cause for dependent failures by considering hardware

failures; development, manufacturing, installation, and repair
faults; environmental factors, failures of common external
resources and stress cases.
::.. Analysis of Dependent Failures (2/2)
If causes are found, then resolution measures shall be indicated,

and change requests shall be send back to subphases for which
analysis of dependent failures is applied.
The outcomes are Results of analyses of dependent failures and

Change requests for confirmed dependent failures.
::.. Safety Analyses (1/2)
The objective is to examine the consequences of faults and

failures on items considering their functions, behaviour and
design. It also provides information on conditions and causes
that could bring violations to a safety goals or requirement. Last,
it could indicate new hazards not found during the hazard
analysis and risk assessment.
Quantitative analysis methods are used to predict the frequency

of failures while qualitative analysis methods identify failures,
both based on the knowledge of fault types and fault modes.
FMEA;
FTA;
FMEA
Qualitative Quantitative ETA;
FTA
Methods Methods Markov models;
ETA
Reliability block
Diagrams.
::.. Safety Analyses (2/2)
Another possible classification of applicable methods is based

on the way they are conducted:
Inductive safety analysis methods starting from known
causes to find unknown effects;
deductive safety analysis methods starting from known
effects to forecast unknown causes.
If the analysis ended that a safety goal or requirements is not

complaint with, such results should be used for deriving
prevention or mitigation measures for the causes of the violation.
::.. Example of ASIL decomposition (1/3)
Let us consider a powered sliding door, which can be activated

by the user with a switch inside the car or remotely.
The considered failure is a

requested or unrequested
opening of the door, while
driving at high speed. It
would be hazardous above
a speed of 15 Km/h, which
might lead to an E4
classification.
A passenger may fall out of the vehicle, which might lead to an

S3 classification.
Harm can be avoided by putting the safety belt on, implying a
controllability of 90%, which can lead to a C2 classification.
The associated safety goal is to not open the door while the
vehicle speed is higher than 15 Km/h: ASILC.
Functional safety concept:

Requirement B1: DSC will send an accurate speed information
to PSDM => ASIL C;
Requirement B2: PSDM will allow the powering of the activator
only if the vehicle speed is below 15 Km/h => ASIL x;
Requirement B3: DSC will send the accurate speed
information to the switch => ASIL C;
Requirement B4: The switch will be in an open state if the

speed is above 15 Km/h => ASIL y;
Requirement B5: the door actuator will only open the door
when powered by PSDM and the switch is closed => ASIL C.
To enable ASIL decomposition, the developers can add an

independency requirement:
Requirement B6: PSDM and switch will be independently
implemented => ASIL C.
Therefore, requirements B2 and B4 implement redundantly the

fulfillment of the safety goal, and an ASIL decomposition can be
applied.
::.. Overview
Dependable
Technologies
For Critical
GUIDELINE ON ISO 26262
Systems
165
::.. IEC 61408 vs ISO 26262 (1/2)
IEC 61508 has been designed as a generic standard and intended

to be used as a base standard from which derive specific
standard for the different industry sectors. However, it cannot be
directly applied to the automotive domain:
1. IEC 61508 is based on the distinction between the control
system and the controlled industrial plant; however, there
is no such distinction in automotive systems;
2. IEC 61508 aims one-off or low volume systems, while ISO
26262 addresses also requirements for productions;
3. IEC 61508 assume that one organization is in charge of
design and development, while automotive systems are
generally produced by one or more suppliers of the
customer. Therefore, ISO 26262 includes requirements for

managing development across multiple organizations;
4. ISO 26262 contains an automotive scheme for hazard
classification, not present in IEC 61508.
::.. IEC 61408 vs ISO 26262 (2/2)
The hazard classification recognizes that a hazard in an

automotive system does not necessary lead to an accident, but
the outcome depends on the exposure in the driving situation.
5. IEC 61508 contains measures that are not

commonly used in the automotive
industry, while ISO 61508 contains

measures based on automotive practices;
6. SIL is stated in probabilistic terms, on the
contrary to ASIL.
::.. Fault, Error and Failure (1/7)
Progression of faults to errors to failures from three different

types of causes:
In general, only the combination of two faults are considered,

unless differently motivated in the functional or technical safety
concept. Therefore, in most cases, a fault can be classified as:
1. Single Point Fault;
2. Residual Fault;
3. Detected Dual Point Fault;
4. Perceived Dual Point Fault;
5. Latent Dual Point Fault;
6. Safe Fault.
Controllability is defined as the avoidance of a specified harm or

damage through timely reactions of the persons involved.
Moreover, it is the ability of the driver to gain control of the
hazardous event and avoid an harm.
A hazardous event is the combination of a hazard and an

operational situation, and each of such events is investigated in
the hazard analysis and risk analysis.
A hazard analysis and risk assessment is performed to identify

risks and define safety goals for them. Specific requirements are
derived to satisfy safety goals by defining the safety mechanisms
and other measures to be used for the item.
A technical safety concept is derived for specifying how

functional safety requirements will be implemented, by indicating
the partitioning of the elements between hardware and software.

System design will be developed w.r.t to such safety
requirements, and H&S requirements will be provided to comply
with the technical safety requirements and system design.
::.. Confirmation Measures
Confirmation measures are used to ensure the proper execution

of system safety process, and provide an evaluation of the
system safety activities and work products as a whole.
By contract, verification activities are intended to ensure that a

given product development activity fulfills the technical
requirements.
Three types of confirmation measures are defined:

Functional safety audit;
Functional safety assessment;
Confirmation reviews.
Each of the confirmation measures will call for the participation

from experience individuals, and it is ensured that these
evaluations are conducted in an objective manner.
::.. Understanding Safety Cases (1/2)
Safety case communicates a clear, comprehensive and

defensible argument (supported by evidence) that a system is
acceptably safe to operate in a particular context.
There are three principal elements of a safety

case: the requirements, the argument and the
evidence. With the argument communicating
the relationship between the evidence and the
objectives.
The role of the safety case report is to summarize the safety

argument and then the external reports capturing the supporting
safety evidence. Safety arguments has been most typically
communicate tough narrative text, but it is becoming
increasingly popular to use graphical notation.
::.. Understanding Safety Cases (2/2)
Safety case development cannot be left as an activity to be

performed towards the end of the safety lifecycle, but it has to be
treated as an incremental activity, integrated with the rest of the
design and safety lifecycle.
Throughout the operational life of any system, the corresponding

safety case might be challenged by additional safety evidence
arising from operation, changes and updates to a design, and a
shifting regulatory context.
Typically, one department is responsible for preparing the safety

case, and al least one other department, or organization, will be
responsible for reviewing and accepting the safety case.
Assessing a safety case will consider the relevance, coverage

and integrity of presented arguments and evidence.
::.. Safety Element out of Context
A Safety Element out of Context

(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 validated during item
development.
Dependable
Technologies
For Critical
THATS ALL FOLKS!!
Systems QUESTIONS?
179
::.. Acknowledgement
This work has been partially supported by the project CRITICAL

Software Technology for an Evolutionary Partnership (CRITICAL-
STEP), Marie Curie Industry-Academia Partnerships and Pathways
(IAPP) number 230672, within the context of the EU Seventh
Framework Programme (FP7).
http://www.criticalstep.eu
Contacts
Christian Esposito, Seconded Researcher

christian.esposito@unina.it
Coimbra, Lisbon, Oporto San Jose Southampton Bucharest Sao Paulo

www.criticalsoftware.com www.criticalsoftware.com www.critical-software.co.uk www.criticalsoftware.ro www.criticalsoftware.com.br
181

Presentation On Standard ISO 26262

Uploaded by

Copyright:

Available Formats

You might also like

Presentation On Standard ISO 26262

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Presentation On Standard ISO 26262

Uploaded by

Copyright:

Available Formats

Dependable

Technologies Hands on the ISO 26262 Standard

Universit di Napoli Consorzio Interuniversitario per

ASIL-oriented and Safety-oriented Analyses;

ISO-26262 is an adaptation of IEC 61508

It applies to safety-related road vehicle

Risk is determined based on customer

It provides ASIL-dependent requirements

ISO-26262 is based upon a V-Model as a reference process

Let us compare such standard with the DO-178B:

suggesting a waterfall-like approach.

ISO-26262, as adaptation of IEC 61508, is focused on functional

ISO-26262, as adaptation of IEC 61508, is focused on functional

The objective of Functional Safety is freedom from unacceptable

Functional Safety is intrinsically end-to-end in scope in that it

ISO-26262 is structured into the following parts:

10. Guidelines on ISO 26262.

Within this presentation we will go through all these different

1. Anomaly: condition that deviates from expectations based on

4. Cascading Failure: failure of an element of an item causing

6. Confirmation Review: confirmation that a product meets the

12. Dual Point Failure: failure resulting from the combination of

16. Failure Mode: manner in which an element or item fails;

19. Fault Model: representation of failure modes resulting from

25. Hazard Analysis and Risk Assessment: method to identify

26. Independence: absence of dependent failure between two or

within the multiple point fault detection interval;

32. Multiple Point Fault: individual fault that, in combination with

proven in use criteria;

37. Regression Strategy: verification strategy to assure that

42. Safety Goal: top-level safety requirement as a result of the

The safety lifecycle

Develop a description of the item with

The safety lifecycle

Distinguish between either a new

The safety lifecycle

Determine ASIL of the item by deriving

The safety lifecycle

Specify functional safety requirements

The safety lifecycle

perspective, with respect to a V model.

The safety lifecycle

perspective, based on the system

The safety lifecycle

perspective, based on the system

The safety lifecycle

specify the associated requirements,

The safety lifecycle

The safety lifecycle

measures outside the item to reduce the

The safety lifecycle

State requirements for the final

The safety lifecycle

State requirements for the final

The organization will provide adequate resources for the

All the involved organizations have a quality management

The outcomes of the Overall Safety Management are a set of

The organization shall determine a Project Manager with the