ISO 26262

Mohamed Osama
Safety types

Passive safety : like air bags.

Active safety : like aeb automotive emergency braking
Safety Levels
Safety objective
❏ Before delivery : avoid of faults , avoid systematic faults (we need
process , method , organization) like to prevent c coding issue we flow
misra rules and we use static analyzer to force the developer follow the
rules.

❏ In operation we control (systematic & random) failures.

 What is the ISO 26262?

standard Guidelines to protect road users from injuries cause by fault in vehicle electronics & Software by
implementation method and requirement on hardware & software like : taking control of acceleration car can
cause danger for human life .

First edition was on 2011 for e/e systems installed in passenger cars.

Second edition was on 2018 for all cars except mopeds

Iso 26262 focus on ensuring failure not lead conditions can harm the people.

Quality : good design and testability and simplicity.

ISO 26262 is not process as iso make assumption you work on development process and it add constraints to
your process focussed on safety aspects.
ISO 26262 main goals

The main goals and will be discuss later :

❏ provides an automotive safety lifecycle (management, development, production, operation, service) and supports tailoring
the necessary activities during these lifecycle phases.
❏ Covers functional safety aspects of the entire development process (including such activities as requirements specification.
❏ Provides an automotive-specific risk-based approach for determining risk classes (Automotive Safety Integrity Levels,
ASILs).
❏ Uses ASILs for specifying the item's necessary safety scale
❏ provides requirements for validation and confirmation measures to ensure a sufficient and acceptable level of safety is being
achieved
ISO 26262

ISO 26262 imposes is focussed on ensuring the system meets its safety
requirements.
ISO 26262
Tools:
Tools must ensure the developer must follow the standard .
Techniques:
For each stage iso26262 specifies set of recommended technique , risk higher levels has
more recommended techniques and move from suggested to required.
Methods:
Despite it give set of techniques it does not give any guidance how to apply it.
Artefacts:
Artefacts capture the output of the design process , ISO 26262 calls these work products
Safety aspect:
Input or methodological directly related to system safety
ISO 26262 hierarchy ?
 Part 1: Vocabulary
terms, definitions, and abbreviations for application in all parts of the standard.example definition of fault, error, and failure as these
terms are key to the standard’s definitions of functional safety processes.

Example
Item :
is used to refer to a specific system (or subject development ) to which the ISO 26262 E/Esystems that implements a function (ex air
bag adaptive control ) at the vehicle level. item is the highest identified object in the process and is thereby the starting point for
product-specific safety development under this standard. And define boundary of item .
Information needed:
Purpose and content of item .
Functional requirement of item
environmental
Subject of development item must be defined & boundaries determined
Element
Either a system, a component (consisting of hardware parts and/or software units),

Hazard
Potential source of harm hazard could be risk or could be acceptable depend on severity or probability of harm depend on risk analysis
Part 2: Management of functional safety

-Defined & applied development procedure .

-Train safety manager because he is in charge for managing & planning.
- Safety case why is your system is safe to prevent cheating to prevent mismatch or cheating.

Management on three phases.

Development organization.
Each development project
Post development phase
Part 2: Management of functional safety

Development organization.
- establish quality assurance system.
- Deploy competence management
- Process to identify communication & resolve safety methodically .

- Each development project(project manager )

- Define roles & responsibility .
- Perform impact analysis
- Plain & tailor lifecycle
- Monitor progress
- Building trust preventing project from mismatch ISO 26262 & cheating.
Safety case :
Argumentation that your product is safe .

Evidence that strategy was actually followed

Evidence work products produce during development

Confirmation measure :
Confirmation reviews : like safety plan & safety concepts .
Function safety audit : to check if product implement the necessary &
defined procedures.
Function safety assessment after release : to get evaluation from
independent person of achieved safety .
Post development safety management
❏ Appoint person who responsible on products & field monitoring.
❏ Install field monitoring process for violation of safety .
❏ Manage change to replace hardware if necessary
Impact analysis

At item level show how should adjust safety lifecycle and which safety
activity you determine.

It must be known item is developed & modified.

Part 3: Concept phase
Developed by car maker

❏ define the scope (item) it can be built as a first step within the FTA. To build the top levels of the FTA,
we must understand the core functions of the item
❏ Function safety analysis concepts
❏ Function requirement must be developed
❏ Hazard analysis & risk assessment ( hara): judge the risk to human life ( safety goal) compared to
safety goals ( high level safety requirement )
❏ Analyze multiple hazards and multiple assess the rizk

Safety goal :

Fault avoidance

Fault control

Fault state

Driver warning

Function safety concepts: how to detect the fault & how to react .
ASIL
-Automotive safety integrity level

-ASIL A

-ASIL B

-ASIL C

ASIL D higher level

QM iso 16949

-ASIL depends on

Severity of harm.

Probability of exposue to operation situation.

Contorability to avoid harm

HARA
ASIL

ASIL used to configure the iso 26262 requirements and select techniques at
sub phase and there are three techniques highly recommended ,
recommended , not recommended

The higher ASIL the higher in cost due to more effort and rigour required
Part 4 :System level
❏Suppliers develop technically safety concept .
❏Suppliers developed technically safety requirements.
❏Safety goals are formulated in detail in forum function safety requirements (FSR) on vehicle level
❏System item integration & testing .

❏Technical safety concepts :

❏ Detection , indication & control of faults
❏ Specify which safe state the system has to change if harm is detected
❏ Tolerance times which depends on safety mechanisms & specific application
❏ Requirements must be defined to avoid the errors which lead to violations goal

Safety mechanism are put to implement safety requirements are often interaction between
hardware detects errors , software to determine response hardware that perform the response.
Item integration & testing

Integrate & test on three levels

Hardware & software .

System .

vehicle.
Item integration & testing

❏ specify the integration and test strategy.

❏ specify test cases using methods.
❏ provide evidence of implementation of safety mechanisms
❏ provide evidence that safety requirements are being met.
Safety validation : are the implemented safety

Measure if the vehicles are used for their objective.

❏ Validation at the vehicle level through long terms of vehicles under
real-life conditions.
❏ Provide evidence that safety goals are achieved and that item is
functionality safe
❏ Development results must be systematically integrated and tested in
order to fulfilment of safety requirements and safety goals.
Functional safety requirements are detailed into technical safety
requirements so they can be implemented with system architecture to be
developed in parallel.

Systematic failures and random hardware failures need to be addressed.

Development result must be systematically integrated and tested on several

layers

From software & hardware to vehicle levels in order to fulfilment of safety

requirement
Part 5: software

Software focus more on development of software and microcontroller

There is potential overlap between software allocation design and system

engineering this overlap will need clarification by development organization.

❏ general topics for product development at the software level;

❏ specification of the software safety requirements;
❏ software architectural design;
❏ software unit design and implementation;
❏ software unit verification;
❏ testing of the embedded software
❏ software integration and verification;
Part 6 : hardware

This section addresses product development at the hardware level, including general topics, specifications
for hardware safety, hardware design, the evaluation of the hardware architectural metrics, the evaluation of
safety goal violations due to random hardware failures, and hardware integration and verification Hardware
qualification .

Basic part: For example, Resistors and Diodes

Intermediate parts or components For example, Sensors, Actuators, and ASICs with dedicated functionality.

Complex component:ISO 26262 standard. For example, Microprocessor, Microcontroller, DSP, and accelerator.

Hardware qualification has two main objectives: to show how the part fits into the overall system and to assess failure modes

with standard qualification, but more complex parts require evaluation through ASIL decomposition and testing and intermediate
through testing & analysis. Hardware components are typically qualified by testing the part in a variety of environmental and
operational conditions. The test results are then analyzed with various numerical methods and presented in a qualification report
along with the testing procedure, assumptions, and input criteria.
Part 7: production & operation & installation

The objective of this clause is to ensure that functional safety is achieved during the production phase (after release
for production) including their installation in the vehicle. by the relevant manufacturer or the person or organisation
responsible for the production process of items and elements (vehicle manufacturer, supplier, sub-supplier, etc.).
❏ Field observation Production
❏ identify process failures;
❏ identify potential effects on functional safety resulting from the identified process failures;
❏ implement appropriate measures to ensure that the identified effects are avoided or mitigated.
❏ Examine detective parts
❏ Determine potential deviation from safety concepts

provide field data that can be analysed to detect the presence of functional safety issues;

analyse this field data to detect the presence of functional safety issues

trigger actions to address identified functional safety issues

Examine necessary software update & hardware replacement

Part 8: supporting process
Defines requirements for process that support the functional safety in the development effort of safety-related E/E systems. ,
including change management documentation standard tool qualification, verification and validation . Evaluation of hardware
elements ,Interfacing an application that is out of the scope of ISO 26262 Integration of safety-related systems not developed .

change management: including management of impact of changes on safety requirements, for the
purposes of assurance of removal of detected defects as well as for product change without introduction
of hazards
Planning, control, and reporting of the verification of work products, including review, analysis, and
testing, with regression analysis of detected defects to their source.

Planned identification and management of all documentation (work products) produced through all phases
of the Safety Life Cycle to facilitate continuous management of functional safety and safety assessment.
ISO 26262 Tool Qualification

Any tools used in automotive development need to be qualified. Part 8 provides guidance for tool qualification.suitable to be used to
support the activities and tasks required by ISO 26262.

It requires the following:

● Software tool qualification plan.

● Software tool documentation.
● Software tool classification analysis.
● Software tool qualification report

the criteria to determine the required level of confidence in software tools;

Some tools are easier to qualify than others. For instance, Helix QAC — a C/C++ static code analyzer — comes with certificates of
compliance that make the qualification process easier.
TOOL examples

❏ establishing requirements traceability makes your verification process easier — especially with a
tool like Helix ALM. And it helps you manage risk in the development process.

❏ if you're developing semiconductors for automotive, using a tool like Methodics IPLM will help
you establish verification traceability for your designs. Plus, Methodics IPLM can help you
manage your ISO 26262 functional safety certification.

❏ Storing your code in Helix Core — version control from Perforce — securely manages revision
history for all your digital assets.
Part 9: safety analysis

this part covers decomposition with respect to ASIL tailoring ,analysis of dependent failures, and safety analyses.

as guidelines on the criteria for coexistence of elements. It applies to sub elements in safety-related functions, with either no ASIL or a lower
ASIL.

• Interference is the presence of cascading failures from a sub-element with no ASIL assigned, or a lower ASIL, to a sub-element with a higher
ASIL, leading to the violation of a safety requirement of the element

The possibility of interference requires the system integrator to identify potential threats to the safety concept, due to cascading faults, by either
preventing the occurrence of the threats or revising safety requirements assigned to the sub-elements with the lower ASIL.

The targeted elements of interference on a typical MCU are on-chip memories, peripherals, critical device configuration registers, and computing
logic.

To ensure the coexistence of safety functions on an element, the system integrator is required to prove absence of interference: Coexistence = !
(Interference).

Prevention of interference is achieved either at the source – by preventing the generation of interference at an originating sub-element – or at the
destination, by protecting the target sub-element vulnerable to the generated interference. The C2000 device has the necessary mix of central and
distributed device features to help avoid interference

C2000 devices are a mix of dedicated and shared SRAMs. Shared SRAMs are configurable to achieve control for write, read, and fetch access
from different masters, s
Part 10:Guidelines

Part 10 provides an overview of the ISO 26262 standard with additional explanations.
Part 11 semiconductor

Part 11 provides detailed information to support semiconductor manufacturers and silicon intellectual property
(IP) suppliers develop ISO 26262 compliant IP.

As the automotive industry continues to develop more self-driving technology, automotive electronics will
maintain an integral role in enabling these capability IP plays an important role in all this by supporting essential
communications protocols such as Ethernet, as well as functions that include real-time data, audio and voice
processing, sensor fusion, pattern and voice recognition, sound enhancement and connectivity.

This is the reason why all electronic circuits need to be verified to ensure the correct hardware and software
functionality

in addition, automotive electronic subsystems must simulate each other to ensure that each interconnected
subsystem continues to operate as intended for a long period of time. In fact, exhaustive simulations, failure
analysis, and performance and reliability analyses are critical to avoid catastrophic safety issues and possible
costly withdrawals later down the line.

Another critical aspect of the IP conundrum is how openly companies should share diagnostics coverage
information during verification
FMEA : fault mode & effect analysis

FTA : fault tree analysis

ALARP : As low AS Reasonably practicable

CAGR : compound annual growth rate

FAT : factory acceptance test

ALM : application lifecycle management

HMI : human machine interactive

SEooC :Safety Element out of Context That method within ISO 26262 allows elements like microprocessors to be
developed independently from their usage context ( could be developed to more system in vehicle)

ECSW:embedded control software

PMHF :Probabilistic Metric for Hardware Failure represents a calculated estimate of the rate of hazard occurrence
due to random hardware failures.must be calculated for systems rated at a high Automotive Safety Integrity Level .

SIF Safety Instrumented Function

DC Diagnostic Coverage given element’s faults that can be detected and mitigated using the safety
mechanism.
Safety Instrumented Function

SIF – Safety Instrumented Function – is a set of equipment intended to reduce the risk due to a
specific hazard safety loop. Its purpose is to 1. Automatically take an industrial process to a
safe state when specified conditions are violated; 2. Permit a process to move forward in a
safe manner when specified conditions allow (permissive functions); or 3. Take action to
mitigate the consequences of an industrial hazard.

A SIF is composed of sensor(s), logic solver(s), and final element(s). It includes elements that
detect an accident is imminent, decides to take action, and then carries out the action needed
to bring the process to a safe state.

● On detecting high pressure, prevent tank rupture by opening valve to relief system.
● Stop motor by disconnecting power or activating brake when severe over-speed is detected.
FMEA

Failure Modes and Effects Analysis (FMEA) is a is a step-by-step approach for identifying all possible failures in a design
systematic, proactive method for evaluating a process to identify where and how it might fail and to assess the relative
impact of different failures, in order to identify the parts of the process that are most in need of change.

FM : ways or mode in which something fails.

EA : to study consequences of this failure.

It can be used in design during early stages system sub system component (better ) to
prevent failures and used in process control assembly and manufacturing (for
troubleshooting) before and during operation of process.
FMEA

Enable early test planning .

Early identification of failure point .

Improves quality safety process .

Reduce process development time ,cost .

Documents and track risk reduction activities.

WHEN TO USE FMEA

When a process, product, or service is being designed or redesigned, after quality function deployment (QFD)
When an existing process, product, or service is being applied in a new way
Before developing control plans for a new or modified process

When analyzing failures of an existing process, product, or service

DFMEA

Analyze product before they are released to production.

Focus on potential failure modes of products caused be design

PFMEA

Analyze Manufacturing and assembly process

FMCEA

Result of consequence of failure & frequency of occurrences

FTA

Fault Tree Analysis (FTA) is a method often proposed for calculation of the PMHF in real-world systems. However, FTA is
a very general method, subject to a wide range of techniques depending on the objectives of a given problem.

There is not yet an accurate and well-explained practical guide to the specific techniques appropriate for PMHF
calculation in the automotive industry. For example, large and complex systems, such as those that comprise real-world
automotive products, are often difficult to capture in a FTA in a systematic and repeatable way.

At lower levels of the FTA, specific frameworks for calculating the effect of single-point and dual point faults (including
dual-point latent faults) are necessary to obtain a correct PMHF estimation.the FTA typically begins with a top-level event
representing a major hazardous event, and/or the violation of a safety goal or Functional Safety Requirement.

The analysis is then performed by deducing what conditions or events would lead to the top-level event.

More recently, the method has been applied to automotive systems and suggested for wider use as an analysis
framework. If probabilities of the underlying lower-level events can be estimated, then an estimate of the probability can
be made for the top-level event. The PMHF is just such a quantitative estimation.
FTA
Could use for design or troubleshooting

Systematic , deductive method for defining and determine all possible failure mode

Fta focus on top even

Prefer for non repairable systems

-risk assessment

Avoid the risk , accept the risk , mitigate the risk , transfer risk Complex system analysis

Evaluation of subsystem event on top event

Evaluation of safety requirement and specification evaluation of system reliability, design

defects and safety hazards potential corrective elements
FTA 0.4
0.04

or
and

0.2
0.2
0.2 0.2

0.6

0.8 0.8
RBD
RBD
Quantitative FTA

there are several critical limitations to such methods that must be recognized. While random failures in electronic
hardware may be modeled with probabilistic methods, systematic failures (for example in deterministic software)
cannot be modeled in this way. This may lead the analyst to under-represent or overlook important systematic
failures

There is wide variability in underlying data available for the reliability failure of electronic components, which in
turn leads to calculations with a relatively wide range of uncertainty. There is also evidence of a tendency for the
analyst to believe in the independence of events which are represented independently in the FTA, while objective
observation would find correlation between events

recognizing the primacy of process adherence in preventing and avoiding systematic faults, which are not
generally quantifiable by probabilistic methods.
“prevent missing lamp indication.” This might be appropriate, for example

❏ The system lifetime, for which the PMHF is valid and for
which the components are specified, is assumed to be
9,500 hours
FMEA VS FTA
Safety analysis

inductive deductive

qualitative Can be quantative

Bottom-up (from hardware & software to Top-down (from vehicle level to item or
item or vehicle level) hardware & software)

Known cases Known effects

Identify possible effect (failure modes Identify possible cases

and its effect )

FMEA FTA

Prefer at top level - software error - Parts - different modes for failure
quantitative risk - product is highly
complex
Dependent Failure Analysis

When a failure of two or more elements is due to a single specific event or root cause, it is called common cause failure

failure of one element leads to failure of another. It appears like a cascade of failures

independence when the dependent failures (cascading and common cause failures) do not lead to any safety goal violation.

interference as partially opposite of independence. It is the presence of cascading failure from a non-ASIL or a lower ASIL
component to a higher ASIL component that leads to one or many safety goal violations.

freedom from interference implies absence of cascading failure between elements that leads to safety goal violation.

Dependent Failure Analysis focused on finding the single causes/events that invalidates independence and freedom from
interference. Every element that might cause such failures are taken into consideration while performing this analysis. Part 6, Part 7,
and Part 9 of the ISO 26262 standard document serve as the reference for performing dependent failure analysis.
Dependent Failure Analysis (DFA):

Dependent failure analysis aims at identifying failures that may invalidates the required independence or freedom from interference
between given elements (hardware/ software/ firmware) which may ultimately lead to violation of safety requirement or safety goal.

can be required because of: (a) the application of an ASIL decomposition at the software level; (b) the implementation of software safety
requirements;3 or (c) required coexistence of the software architectural elements [6, Annex E]. Concerning the last point, criteria for
coexistence of elements are given in [8, Clause

Dependent Failure Analysis consists of following 2 parts.

● Validate Freedom from Interference (FFI) between elements.

● Validate Independence between elements
Dependent Failure Analysis (DFA):

Dependent failure types:

Dependent Failures can arise from systematic failures and random hardware failures.
DFA
DFA Part 1: Freedom from Interference (FFI):
Analysis of interactions between software elements:
● The FFI should be analyzed between software elements (determined during software architecture design).
● Since the FFI is based upon analysis of only cascading failure, hence the data exchange between software elements should be analyzed.
● The ASIL level of software elements (source and destination elements) between which data exchange takes should be analyzed.
● In case the data exchange occurs between originating from lower level ASIL element to higher level ASIL element, then such
interactions should be marked for analysis.

Analyze the interaction between software elements for following possible failures.

Timing and Execution:

● blocking of execution.
● deadlocks – several processes blocking mutually by waiting for events that can be triggered by themselves.
● Livelocks – several processes keeping each other in infinite loop.
● incorrect allocation of execution time.
● incorrect synchronization between software elements.
DFA
Memory:
● corruption of content.
● read or write access to memory allocated to another software element.

Exchange of Information:

● repetition of information.
● loss of information.
● delay of information.
● insertion of information.
● masquerade or incorrect addressing of information.
● incorrect sequence of information.
● corruption of information.
DFA Part 2: Independence

Identification of couples:
Based upon above factors architectural units can be identified to form couples to prove independence amongst them.
The couples can be identified based upon following factors.

● Similar and dissimilar redundant elements

● Different functions implemented with identical software or hardware elements
● Functions and their respective safety mechanisms
● Partitions of functions or software elements
● Physical distance between hardware elements, with or without barrier
● Common external resources
 Similar and dissimilar redundant elements

In this example, 2 redundant software functionalities are implemented using different algorithms to provide an output (SO1 - which is Safety related).
SWF1: Multiplication using actual multiplication operator SWF2: Multiplication using repeated addition operator
So, to determine the integrity of this output (SO1), both SWF1 and SWF2 needs to be identified as a couple. These can form a couple since they are
used to provide a single output, which may fail due to following reasons.
SWF1 block failure (like SWF1 function not completely called due to interrupt function call, memory corruption of the code flash area where
SWF1 or any of its variable is stored etc.). Similar in case of SWF2

SWF1 block failure (like SWF1 function not completely called due to interrupt function call, memory corruption of the code flash area where SWF1 or
any of its variable is stored etc.). Similar in case of SWF2.
Different functions implemented with identical software or hardware elements

In this example, 2 different software functionalities (SWF1, SWF2) are using same Firmware functionality (FWF1) algorithms to get the battery
voltage and power source voltage for ECU2 from a common functionality (FWF1).

Both the software functionalities are implemented using a common/identical firmware element i.e. ADC firmware. Hence both these software
elements can be considered as a couple.
Functions and their respective safety mechanisms

In this example, the software functionality (SWF1) controls the Relay control IC (1,2) for live and
neutral. The software functionality (SWF2) is used to detect the feedback from the voltage/current
monitoring IC that monitors the flow of current. Hence once SWF1 controls the relay to stop current
flow. SWF2 acts a safety mechanism for SWF1.
So, both SWF1 and SWF2 can be identified as a couple for analysis to check if there is any
dependency
 FMEDA

(Chapter IV) The initial FMEDA added two additional pieces of information to the FMEA analysis process used in the early stages of systems
development to identify weaknesses

information added in an FMEDA is the quantitative failure data (failure rates and the distribution of failure modes) for all components being analyzed

information added to an FMEDA is the probability of the system or subsystem to detect internal failures via automatic on-line diagnostics.

The method was explained to members of the IEC 61508 committee in the late 90s and included in the standard as a method of determining failure
rate, failure mode and diagnostic coverage for products.

FMEDA techniques have been further refined during the 2000s primarily during IEC 61508 preparation work. The key changes have been: 1. Use of
Functional Failure Modes of parts , sub and elementary parts , failure rates and failure rate distribution safety mechanism and their cd coverage hw
architecture matric like probability of randam hardware failure ; 2. Mechanical Component Usage; 3. Prediction of manual proof test effectiveness;
and 4. Prediction of product useful life. With these changes, the FMEDA technique has matured to become more complete and provide useful
database on failure data about the product .
Also in the early 2000s functional failure mode analysis was added to the FMEDA. In early FMEDA work, component failure modes were mapped
directly to "safe" or "dangerous" categories per IEC 61508. This was relatively easy since everything that was not "dangerous" was "safe." With
multiple failure mode categories now existing, direct assignment became more difficult. In addition, it became clear that the category assignment
might change if a product were used in different applications. With direct failure mode category assignment during the FMEDA, a new FMEDA was
required for each new application or each variation in usage. Under the functional failure mode approach, the actual functional failure modes of the
product are identified during an FMEA. During the detailed FMEDA, each component failure mode is mapped to a functional failure mode. The
functional failure modes are then categorized according to product failure mode in a particular application. This eliminates the need for more detailed
work when a new application is considered.
 FMEDA

It became clear in the early 2000s that many products being used in safety critical applications had mechanical components. An
FMEDA done without considering these mechanical components was incomplete, misleading, and potentially dangerous. The
fundamental problem in using the FMEDA technique was the lack of a mechanical component database that included part failure
rates and failure mode distributions. Using a number of published reference sources, exida began development of a mechanical
component database in 2003.After a few years of research and refinement the database has been published ] This has allowed the
FMEDA to be used on combination electrical / mechanical components and purely mechanical components.

The FMEDA can predict the effectiveness of any defined manual proof test in the same way it can predict automatic diagnostic
coverage. An additional column is added to the FMEDA and probability of detection for each component failure mode is estimated.
The cumulative effectiveness of the proof test is calculated in the same way as automatic diagnostic coverage.
What is proof testing?

Proof testing is defined in IEC 61508 as a ‘Periodic test performed to detect dangerous hidden failures in a safety-related system so that, if necessary, a
repair can restore the system to an “as new” condition or as close as practical to this condition’. In simple terms, a proof test is designed to reveal all
the ‘undetected/unrevealed’ failures which the device may be harbouring unbeknown to anyone.

. Why do we need to do proof testing?

When estimating the PFD Probability of Failure on Demand of a device, the frequency at which a device is proof tested has a significant impact on the
overall PFD Probability of Failure on Demand . Therefore, if the device is not tested at the specified interval, there is a danger that an undetected
failure may be left unrevealed until a demand is placed upon it and your safety function will not work when you need it to!

Are proof testing and functional testing the same thing?

No! A functional test is usually referred to the testing of a SIF to ensure that the specified function is working correctly. However, in redundant
channels, would a functional test reveal all faults? Possibly not; If a subsystem is voted in a 1oo2 configuration, a functional test may detect a
dangerous fault of the sensor architecture but won’t highlight how many faults:
Further refinement of the component database with selective calibration to different operation profiles is needed. In addition,
comparisons of FMEDA results with field failure studies, have shown that human factors, especially maintenance procedures, affect
the failure rates and failure modes of products.

As more data becomes available, the component database can be refined and updated. After a few years of research and refinement,
the database has been published as required by new technology and new knowledge. The success of the FMEDA technique is
supplying needed data in a relatively accurate way has allowed the probabilistic, performance approach to design to work.
Evaluating FMEA, FMECA and FMEDA
From a methodology point of view, failure modes and effects analysis (FMEA); failure modes, effects and criticality analysis
(FMECA) and failure modes, effects and diagnostics analysis (FMEDA) are the same thing. FMEA is a methodology to identify
ways a product, safety device, process or system can fail ).

FMECA is an extension of FMEA. In addition to FMEA, FMECA ranks the identified failure modes in order of
importance, according to calculation of one of two indexes: risk priority number (RPN) or criticality (C).

FMEDA is a systematic, detailed procedure that is an extension of the classic FMEA. Its purpose is to calculate the failure
rates of a target system, which can be a device or group of devices that perform a more complex function. This
methodology was first developed for electronics and recently extended to mechanical and electromechanical devices.
Evaluating FMEA, FMECA and FMEDA

Components, devices and arrangements of devices can be part of the target system for a FMEA, FMECA or FMEDA assessment.

FMEA, FMECA and FMEDA share a common methodology. The common methodology can be applied prior or during the
design, construction or final installation of the target system. The common methodology analyzes and reviews the

The basic steps in the common methodology are to:

1. Define the target system and its structure

2. Establish the analysis scenarios
3. Assess cases from combinations of scenarios
4. Perform the failure modes and effects (FME) study, and
5. Perform the FME assessment.
Evaluating FMEA, FMECA and FMEDA
Evaluating FMEA, FMECA and FMEDA

in general, a FMEA focuses on all the ways a target system can fail. These ways are the failure modes, and one failure mode
can have several failure effects.

FMECA assessment results include the FMEA results and the ranking all FMEs. This ranking is used to identify the
components (or devices) with higher impact on target system reliability, where changes or enhancement are typically
required to improve safety indexes such as average probability of failure on demand (PFDavg), average dangerous
frequency of failure (PFHavg), mean time to failure spuriously (MTTFs) or mean time to failure dangerously (MTTFd).

The FMECA can be developed to provide a qualitative or quantitative assessment, and in both cases, it should provide a
target system criticality matrix to show graphically which components (or devices) have higher and lower impact on the
target system reliability.
FMEDA assessment results include the FMEA results and target system reliability data. This data can be used for target system SIL verification, SIL
certification, or contribution when calculating a SIF’s SIL rating.

The reliability data is provided as the quantification (typically failures per billion hours) of:

● Safe detected failure rate: Failure rate of the target system to move its operation condition from normal to safe state. Safety/control system or operator
can be notified, and the target plant or equipment is protected.
● Safe undetected failure rate: Failure rate of target system to move its operation condition from normal to safe state. Safety/control system or operator
will not be notified, and the target plant or equipment is protected.

● Dangerous detected failure rate: Failure rate of target system where it will remain in normal state when a demand happens,
but the safety/control system or operator can be notified to fix the problem or to apply maintenance. The target plant or
equipment is not protected, but the problem is identified, and there is a chance to fix the failure before a demand occurs.
● Dangerous undetected failure rate: Failure rate of target system where it will remain in normal state when a demand happens, and the safety/control
system or operator will not be notified. The target plant or equipment is not protected, the problem is hidden, and the only chance to identify and to fix
the failure is when a proof test is performed. If required, FMEDA assessment can reveal which portion of dangerous undetected failures can be identified
by proof test—in other words, FMEDA assessment could provide the proof test effectiveness (Et) or proof test coverage (PTC) of the proof test
application on the target system.
● Annunciation failure rate: Failure rate of the target system that will not affect safety performance to move its operating condition from normal to
safe state. For example, a transmitter local display failure.
● No effect failure rate: Any other failure rate of identified failures that will not make the target system fail safely or dangerously.
DC

Diagnostic coverage system ability to detect failure this ratio between the
failure rates for deducted failures controlled by a Safety mechanism to failure
rate of all failures in the system.
ISO 26262 provides a “starting point” for estimating the DC values of a safety mechanism based on their
applicability to a system. They are classified as Low (60%), Medium (90%) and High (99%) diagnostic coverage

The safety mechanisms are classified to these corresponding levels (low, medium, high) depending on factors varying from

● Variations in the source of the fault type detected by the diagnostic

● Technologies implemented in the system
● The execution timing of the safety mechanism, etc.
DC calculation
at do we do when there are multiple safety mechanisms applicable simultaneously to cover against a single failure mode?
How is Diagnostic Coverage estimated in such a real-world scenario?

METHOD A
DC= DC effective

METHOD B

DC= DC1+DC2 *(1-DC1)+ DC3*(1-DC1-DC2)

DC=DC1+[(DC2+DC3)/2 *(1-DC1)]

METHOD C

● In an ideal scenario each safety mechanism would be studied in detail along with their applicability to various failure
modes. The same safety mechanism applicable to different failure modes may have different effectiveness
● One way to evaluate this would be to perform fault injection testing and observe the reactions of the safety
mechanisms and then define their effectiveness
Difference between iso 26262 and iec 61508
Iso 26262 is used for automotive.

Iec 61508 for larger scale , safety critical like chemical plant or nuclear reactors

Embedded systems products are sold as OEM products iso 26262 drop all installation standard from
iec61508

Iso26262 is more prescriptive about documents than iec61508

IEC 61508 :

Target suppliers :

Requirements for suppliers of process control focus on knowledge ,capability and how product is
designed ( proper requirements , test is done successfully , all test logs and evidence are there,

Following the process procedure , quality system in place , have management safety and following that)
investigation must be hard to insure no fails

IEC 61511 for end user for safety review( performance) and safety assessment
how does the standard affect automotive testing?

you go back to the past, once again, there have been times when large changes are made in the way vehicles are
developed. If you think about crash testing and crumple zones, those are things that are just standard today. Now,
with the autonomy and electric vehicles, where you are taking the control out of the human hands, all of a sudden,
a lot of other things become really important.This goes all the way down to the formality of testing of the features
that you are putting in the vehicle which is driving your children around. Also, even providing guidance to the
driver, like a backup camera and all of those things.
What parts of the vehicle are relevant to the standard versus maybe parts that are not?

The standard is written for electronic system and software. So, you can think about any parts of the vehicle that
are electronic or software. Now it is debatable in some cases, whether a battery is electronics or mechanical
system. But the battery controller definitely is. And if the vehicle is moving towards electric,
Notes
Functional safety may be assessed at several different levels, but once you go lower than the top product/system level, it may be necessary
to make assumptions with respect to what risks and risk levels are appropriate. A safety programmable logic controller (PLC) is a good
example. Safety PLC manufacturers often do not know exactly in which environment or what functions the PLC will be responsible for
making, and therefore can’t do a thorough hazard and risk assessment. In these cases, the required safety integrity level (SIL) or
performance level (PL) may need to be assumed.

System integrators should be conducting hazard and risk assessments to determine where it is necessary to design risk reduction into
their system and what safety functions are needed from control systems. This includes the corresponding SIL or PL for those functions.
Once those risks have been reduced to acceptable levels, you should know at that point, for example, that you may need a motor drive with
an integrated safe torque off (STO) function of SIL 2, an E-Stop with SIL 3 function,

Even before you purchase a machine, the manufacturer of that machine should provide you with a safety manual that describes all the
safety considerations, safety functions, PLs, SILs, and perhaps most importantly, the conditions and environment in which that machine
can be used. Review this information before you purchase the machine and make sure everything that the machine provides is compatible
with your overall integration or at least that it is feasible to take additional steps to accommodate those conditions. Once you have decided
to purchase a machine and integrate it within your end equipment, it is essential that you do something called a factory acceptance test
(FAT) to verify the functions performed by the machine before you put it into commission. Some guidance on how to do FAT in particular
for safety applications is provided in the standard IEC 61511.
 Notes
A comprehensive hazard and risk assessment can only be done when the entire equipment (including all systems, subsystems,
components, etc.), its function and its environment are known. In these cases, functional safety is likely not going to be provided
at the top level but by the subsystems, components, etc., that comprise the equipment. Each machine, each step of operation,
etc., can then be assessed separately for those functions and the results and conditions of those assessments are documented
carefully in a safety manual. It is up to the equipment/system integrator to review all of the subsystem/component safety manuals
to help ensure that all potential conditions and concerns have been addressed at the top level

For most safety functions, it is not possible or feasible to assume that detection will be instantaneous. The reaction or response
time of a safety function is certainly one critical parameter that is to be declared and communicated in a safety manual.

Various functional safety standards do offer recommendations on what languages are preferred or not preferred; see IEC 61508,
for example. Not only does the language have to be considered, but also if any language subsets are used. Going back to IEC
61508, it, for example, does not recommend just using the C language by itself but does highly recommend using the C language
with a subset such as MISRA C.
Notes
Software evaluations focus more on the process and techniques used to develop the software rather than on the
resulting code itself, which is mainly only walked through to establish traceability with the documentation. The
first step in UL's process involves a review of the outputs, i.e., documents, of each of the software development
processes, e.g., risk analysis, requirements, architecture, and design specifications, and module, integration, and
validation test specifications/results. The second step involves meeting directly with the software developer and
conducting an audit of the processes and work products to establish traceability. All in all, software evaluation
typically only takes a few days of engineering time.

Documentation (which are outputs from a manufacturer's development process) should be in the format and
language that the manufacturer is most comfortable with. This usually, but not always, means that the documents
should be in the primary language used by the manufacturer to avoid having to repeatedly translate, which could
cause misunderstandings, and in turn, could lead to systematic faults.
reference
● https://www.youtube.com/watch?v=WhPwxUXJGpg&t=2569s
● https://www.youtube.com/watch?v=Nz8P8G9cKgA&t=2449s
● https://
www.youtube.com/watch?v=9wcJuW9E0S8&list=PLO2k6yikLVTlrkQJN8pbzn
ro3G-EhkViG
● https://
www.youtube.com/playlist?list=PLrgsufSkwlpjEYMi1TbWC80LI6eH_rrf3
● https://www.youtube.com/watch?v=4Bi8nptcYv0
● http://
embeddedinembedded.blogspot.com/2017/02/iso-26262-dependent-failure-an
alysis-dfa.html