system level - UTC

Transcription

system level - UTC

ISO/DIS 26262
Global training
MAJ 07/03/2010
Introduction à la norme ISO 26262
1/134
Agenda
Learning objectives
Introduction
I. Normative references
II. History
III. Scope of the standard
IV. Vocabulary – part 1
V. Management of Functional Safety – part 2
VI. Concept phase – part 3
VII. Product development : system level – part 4
VIII.Product development : hardware level – part 5
IX. Product development : software level – part 6
X. Product & operation – part 7
XI. Supporting processes – part 8
XII. ASIL – oriented and safety analysis – part 9
XIII.Guideline – part 10
MAJ 07/03/2010
2/134
General learning objectives
At the end of the session, attendees should be able :
¾ to know the origin of the ISO standard
¾ to understand the application field of the ISO standard
¾ to know the scope of this standard
¾ to acquire the new concepts introduced by the standard
¾ to have an overview of methods allowing to analyse and cope
with the identified risks
MAJ 07/03/2010
3/134
Introduction of the Automotive
Safety Standard
ISO 26262 was prepared by Technical Committee ISO/TC 22, Road
Vehicle, Subcommittee SC3 Electrical and Electronic Equipment.
ISO 26262 consists of the following parts, under the general title « Road
vehicle – functional safety ».
9 Part 1 : Vocabulary
9 Part 2 : Management of functional safety
9 Part 3 : Concept phase
9 Part 4 : Product development system level
9 Part 5 : Product development hardware level
9 Part 6 : Product development software level
9 Part 7 : Production & Operation
9 Part 8 : Supporting process
9 Part 9 : ASIL oriented and safety oriented analyses
9 Part 10 : Guideline
MAJ 07/03/2010
4/134
Safety Standard
MAJ 07/03/2010
5/134
Safety Standard
This Standard is the adaptation of IEC 61508 to comply with needs
specific to the application sector of Electric & Electronic (E/E) systems
within road vehicles
This standard :
¾ provides an automotive safety lifecycle and supports tailoring the
necessary activities during these lifecycle phases
¾ provides an automotive specific risk-based approach for determining
risk classes (Automotive Safety Integrity Level ASIL)
¾ uses ASIL for specifying the item’s necessary safety requirements for
achieving an acceptable residual risk
¾ provides requirements for validation & confirmation measures to
ensure a sufficient and acceptable level of safety being achieved
MAJ 07/03/2010
6/134
I – Normative references
¾ ISO 9001- 2000, Quality management systems – Requirements
¾ ISO 16949 Quality management systems – Particular
requirements for the application of ISO 9001- 2000 for
automotive production and relevant service part organizations
¾ ISO 3779, Road vehicles – Vehicle Identification Number (VIN)
¾ ISO 3883, Road vehicles – Types – Terms and definitions
MAJ 07/03/2010
7/134
II - History
First definition…
Risk
Combination of the probability of occurrence of harm and
the severity of that harm
Functional safety
Absence of unreasonable risk due to hazards caused by
malfunctioning behavior of E/E systems
Safety
Absence of unreasonable risks
MAJ 07/03/2010
8/134
II - History
Objectives of this standard ?
¾ Comparability with existing IEC 61508 shall remain due to product
liability aspects
¾ All normative sections should have a Safety Integrity Level
dependency
¾ Adaptation of the safety lifecycle to typical automotive development
and operation phases is needed
¾ Distinction between management, development and support
processes
MAJ 07/03/2010
9/134
II - History
¾ Standard shall support implementation of development processes
and safety assessments
¾ Standard should refer to milestones and prototypes/samples of
typical automotive development processes
¾ Standard shall include requirements on manufacture/supplier
relation and distributed development processes
MAJ 07/03/2010
10/134
II - History
¾ Hazard analysis and risk assessment shall be adapted for
typical automotive use cases
¾ Emphasis on verification / validation process, including
Application of HIL-tests, LabCars, fleet tests and user oriented
tests during validation shall be considered
¾ Support of probabilistic target values for random hardware
failures
MAJ 07/03/2010
11/134
II - History
Workteam
MAJ 07/03/2010
Convenor:
Secretary:
Ch.Jung,
E. Fritzsche, FAKRA
Germany:
France:
Austria:
GmbH)
Italy:
Japan:
Sweden:
UK:
USA:
Belgium:
Canada:
BMW, Bosch, Continental, Daimler, VW
PSA, Renault, Continental, Valeo
(MagnaSteyr, ARC Seibersdorf Research
Fiat Group, Centro Ricerche Fiat, TRW
Honda, Nissan, Toyota, Denso, Hitachi
Volvo Cars, AB Volvo, Delphi,
Landrover, MIRA
TRW, GM, Delphi
Nissan Europe, Toyota Europe
Critical Systems Labs
12/134
II - History
FAKRA
BNA
MISRA
OEMs
Suppliers
Technical Services
IEC
61508
2002
Initial work
of individual
companies
2003
Initiatives
within
national
standardization
bodies
First drafts
of
requirement
specifications
9.2005
2011
1.2004
other
Safety Standards
Quality Standards
Engineering Standards
MAJ 07/03/2010
ISO
TC22
SC3
WG16
RESPONSE
Automotive SPICE
13/134
II - History
7/07
3/08 6/08
12/08
6/09
12/09
6/10
CD Voting
6/08
decided
CD Voting
12/08
6/09
12/09
12/10
6/11
CD Voting
DIS is approved and can be communicated outside the Working Group
MAJ 07/03/2010
14/134
III – Scope of the standard
This standard is applicable to safety related systems, that include one or
more E/E systems, and that are installed in series production passenger
cars with a max gross weight up to 3,5 t but not in vehicle for drivers
with disabilities
ISO 26262 addresses possible hazards caused by malfunctioning
behaviour of E/E safety-related systems including interaction of these
systems. It does not address hazards as electric shock, fire, smoke, heat,
radiation, toxicity, flammability, reactivity, corrosion, release of energy,
and similar hazards unless directly caused by malfunctioning behaviour
of E/E safety related systems.
Additional requirements for vehicles for the transport
of hazardous goods are not covered by this Standard.
MAJ 07/03/2010
15/134
IV – Vocabulary
MAJ 07/03/2010
Part 1
16/134
IV – Vocabulary
Part 1
Main terms …
Item
System or array of systems or a function to which ISO 26262 is
applied
Safety
Absence of unreasonable risk
Functional safety
Absence of unreasonable risk due to hazards caused by
malfunctioning behaviour of E/E systems
Safety case
Argument that the safety goals for an item are complete and
satisfied by evidence compiled from work products of the safety
activities during development
NOTE Safety case can be extended to cover safety issues beyond
the scope of this standard.
MAJ 07/03/2010
17/134
IV – Vocabulary
Part 1
Main terms …
Exposure
state of being in an operational situation that can be hazardous
if coincident with the failure mode under analysis
Severity
measure of the extent of harm to an individual in a specific
situation
Automotive Safety Integrity Level (ASIL)
one of four levels to specify the item’s or element’s necessary
requirements of ISO 26262 and safety measures for avoiding
an unreasonable residual risk with D representing the most
stringent and A the least stringent level
Safety goal
Top-level safety requirement as a result of the hazard analysis
and risk assessment
MAJ 07/03/2010
18/134
IV – Vocabulary
Part 1
Main terms …
Random hardware fault
Failure that may occur unpredictably during the lifetime of a
hardware element and that follows a probability distribution
NOTE: Random hardware failure rates can be predicted with
reasonable accuracy.
Systematic fault
Failure of an element or item that is caused in a deterministic
way during development, manufacturing, or maintenance
NOTE Systematic failures can be prevented by applying design
measures or production process changes on this element or
item.
MAJ 07/03/2010
19/134
IV – Vocabulary
Part 1
Main terms …
Fault
abnormal condition that can cause an element or an item to fail
Hazard
Potential source of harm
Failure
Termination of the ability of an element or an item to perform a
function as required
ASIL decomposition
Apportioning of safety requirements redundantly to sufficiently
independent elements with the objective of reducing the ASIL
of the elements
MAJ 07/03/2010
20/134
V – Management of
Functional Safety
MAJ 07/03/2010
Part 2
21/134
V – Management of
Functional Safety
Part 2
Objectives
The objective of this clause is to define the requirements on
the organizations that are responsible for the safety lifecycle,
or that perform safety activities in the item’s safety lifecycle.
This clause serves as a prerequisite to all the ISO 26262
activities in the item’s safety lifecycle
MAJ 07/03/2010
22/134
V – Management of
Functional Safety
Part 2
ASIL
cotation
MAJ 07/03/2010
23/134
V – Management of
Functional Safety
MAJ 07/03/2010
Part 2
24/134
V – Management of
Functional Safety
Part 2
Requirements to perform this part (global)
¾ Safety culture needed
¾ Quality management (ISO 9001 / ISO TS 16949)
¾ Training & Qualification (knowledge areas : safety
practices, methodology expertise, functional safety
process…)
¾ Application of safety lifecycle (tailoring of lifecyle :
combining per splitting sub-phases, performing an activity in
an added phase or sub-phase…)
MAJ 07/03/2010
25/134
V – Management of
Functional Safety
Part 2
Requirements during developpement phase…
¾ Safety responsabilities (project manager, appointed, role
& mission, safety manager…)
o The role of the safety manager can be filled by the
project manager
o The tasks of the safety manager can be tailored
according to the size of the project and the ASIL.
o Functional safety management tasks include the timely
and professional delivery of safety activity results
MAJ 07/03/2010
26/134
V – Management of
Functional Safety
Part 2
¾ Planning for all safety management activities.
Safety manager shall plan the activities, shall create a safety plan &
safety planning
The safety plan shall either be:
a) a plan referenced in the overall project plan; or
b) included in the overall project plan, such that the safety activities
are distinguishable.
Each of the activities in the safety plan should be described according to
the following:
o Objective
o Required work products from other activities, such as described in
prerequisites
o Person in charge of safety activities
o Starting point in time and duration
o Documentation of the respective work products
MAJ 07/03/2010
27/134
V – Management of
Functional Safety
Part 2
In developing the safety plan, the specific activities
shall be tailored according to the ASIL and the
constraints of the project
¾ Safety case (compiled progressively during the development
phase)
The safety case shall be comprehensive and complete
with regard to the work products defined in the safety
plan
MAJ 07/03/2010
28/134
V – Management of
Functional Safety
Part 2
¾Confirmation measures for ensuring functional safety
Functional safety audit
Confirmation review
Functional safety
assessment
Subject
Implementation of the processes Work product
required for functional safety
Result
Audit reporta
Confirmation review reporta Assessment report on
functional safety of the
item
Responsibility of
the
Auditor/Reviewer/
Safety Assessor
Adequate evaluation of the
processes against the definition
of the activity, referenced or
listed in the safety plan.
Adequate evaluation of the Adequate evaluation of
the achieved functional
compliance of the work
product with the respective safety level
requirements of ISO°26262
Timing during
lifecycle
During implementation of the
required processes
After completion of the
corresponding safety
activity
Completion before product
release
Progressively during
development, or in a
single block
Completion before
product release
Scope and depth
Determined by the auditor
Planned prior to the
review, in accordance with
the safety plan
Review of processes and
safety measures required
for functional safety
a
MAJ 07/03/2010
Item as described in the
item definition (see
ISO°26262-3, Clause°5)
can be included in a functional safety assessment report
29/134
V – Management of
Functional Safety
Part 2
Confirmation measures
Confirmation review of the hazard analysis & risk
assessment, of the item that is dealt with in accordance
with ISO°26262 (see ISO°26262-3, Clause 7 and if
applicable, ISO 26262-8, Clause 5)
-
The confirmation
measures shall be
performed
according to their
ASIL and
following table.
independent from the developers of the item
Confirmation review of the safety plan (see Clause 6)
- independent from the developers of the item / project
management
Confirmation review of the integration and testing plan
(see ISO°26262-4, Clause 5)
-independent from the developers of the item / project
management
Confirmation review of the validation plan (see
ISO°26262-4, Clause 5)
-independent from the developers of the item / project
management
Confirmation review of the safety analyses (FMEA, FTA):
(see ISO°26262-9, 8.4.8)
Confirmation review of the qualification of software tools
(see ISO°26262-8, Clause 11)
- independent from the person performing the
qualification of the software tool
Confirmation review of the proven in use arguments
(analysis, data and credit), of the candidates. See
ISO°26262-8, Clause 14.
-independent from the supplier of the argument
Confirmation review of the completeness of the safety
case (see 6.4.5)
- independent from authors of safety case
Audit of functional safety processes (see 6.4.6)
- independent from the persons working in accordance
with the processes required for functional safety
Functional safety assessment (see 6.4.6.7)
-independent from the supplier of the safety case
MAJ 07/03/2010
For all ASILs, and including
hazards rated as QM
I3
A
applies to ASIL
B
C
D
-
I1
I2
I3
highest ASIL among safety
goals of the item
I0
I1
I2
I2
goals of the item
I0
I1
I2
I2
goals of the item
I1
I1
I2
I3
goals of the item
-
I0
I1
I1
goals of the item
I0
I1
I2
I3
ASIL of the safety goal or
requirement related to the
considered behaviour, or
function, of the candidate
I0
I1
I2
I3
goals of the item
-
I0
I2
I3
goals of the item
-
I0
I2
I3
goals of the item
of the
30/134
V – Management of
Functional Safety
Part 2
¾ Safety assessment shall consider :
o Confirmation plan
o Recommendations from the functionnal safety assessment,
if available
o Results from the functional safety audits and confirmation
reviews
One or more persons shall be appointed to carry out a functional
safety assessment and shall provide a judgement of functional
safety
MAJ 07/03/2010
31/134
V – Management of
Functional Safety
Part 2
Requirements for compliance
When claiming compliance with ISO 26262, each requirement
shall be complied with, unless one of the following applies:
1) Tailoring in accordance with ISO 26262-2 has been planned
and shows that the requirement does not apply.
2) A rationale is available that the non-compliance is
acceptable and the rationale has been assessed in accordance
with ISO 26262-2.
Information marked as a "NOTE" is only for guidance in
understanding, or for clarification of, the associated
requirement and shall not be interpreted as a requirement itself.
MAJ 07/03/2010
32/134
V – Management of
Functional Safety
Part 2
Interpretation of tables
¾ Tables may be normative or informative depending on their context.
¾The different methods listed in a table contribute to the level of confidence that the
corresponding requirement shall apply.
Each method in a table is either a consecutive entry (marked by a sequence number in the
leftmost column,e.g. 1, 2, 3) or an alternative entry (marked by a number followed by a
letter in leftmost column, e.g., 2a, 2b, 2c).
¾For consecutive entries all methods are recommended in accordance with the ASIL.
¾ For alternative entries an appropriate combination of methods shall be applied in
accordance with the ASIL,independently of whether they are listed in the table or not. If
methods are listed with different degrees of recommendation for an ASIL the higher one
should be preferred.
¾For each method, the degree of recommendation to use the corresponding method
depends on the ASIL and is categorized as follows:
”++” The method is highly recommended for this ASIL.
“+“ The method is recommended for this ASIL.
“o“ The method has no recommendation for or against its usage for this ASIL.
MAJ 07/03/2010
33/134
VI – Concept phase
MAJ 07/03/2010
Part 3
34/134
Part 3
Objectives
¾ The objective of this part is :
o to define & describe the item
o to develop an adequate understanding of item
o to select the applicable safety lifecycle
o to identify and categorize the potentiel hazard of the item
o to formulate the safety goals
o to define the preliminary architecture element
MAJ 07/03/2010
35/134
Part 3
Item definition
¾ Information needed :
o purpose and content of the item
o functional requirements of the item
o futher requirement for the item regarding the environmental
conditions in which the item is used
o boundary of the item
o interfaces with other items
o requirements from other items
o allocation & distribution of functions among the items
involved
MAJ 07/03/2010
36/134
Part 3
Initiation of the safety lifecycle
¾ Determination of the development category
It shall be determined whether the item is a modification of an existing
item or if it is a new development
o In case of a new development, the entire safety lifecycle shall be
applied
o In case of a modification the relevant lifecycle sub-phases and
activities shall be determined
¾ Impact analysis & adapted safety lifecycle
o In case of a modification of the item, an impact analysis shall be
conducted to determine the areas affected by the modification
MAJ 07/03/2010
37/134
Part 3
Hazard risk analysis
¾ The hazard analysis and risk assessment sub-phase comprises three
steps :
a) Situation analysis and hazard identification :The goal of the
situation analysis and hazard identification is to identify the
potential unintended behaviours of the item that could lead to a
hazardous event
b) Hazard classification : The hazard classification schema
comprises the determination of the severity (S), the probability of
Exposure (E) and the Controllability (C) associated with the
considered hazard of the item
c) ASIL determination : Determining the required automotive safety
integrity level
MAJ 07/03/2010
38/134
Part 3
a) Situation analysis & hazard identification
¾ The operational situations and operating modes in which an item's
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 in a foreseeable way.
¾ A list of operational situations to be evaluated shall be prepared
¾The failure modes and hazards shall be detailed
¾The consequences of hazardous events shall be identified for
relevant operational situations and operating modes
MAJ 07/03/2010
39/134
Part 3
a) Situation analysis & hazard identification
The operational situation addresses the limits within which the item is
expected to behave in a safe manner. For example, a normal passenger
road vehicle is not expected to travel cross country at high speed.
Example : Operational situations include visibility, road surface
traction, road surface unevenness, road surface bank angle change,
road surface pitch change, objects in the path of the vehicle, objects
on a trajectory intersecting the path of the vehicle, relative velocity of
the vehicle and the object it is approaching, relative to the distance
(gap).
Only the item without any safety mechanism shall be evaluated during
situation analysis and hazard identification (i.e. safety mechanisms
intended to be implemented or that have already been implemented in
predecessor systems shall not be considered as a means for providing
risk reduction).
MAJ 07/03/2010
40/134
Part 3
b) Hazard classification
¾ Estimation of potential severity
The severity of potential harm shall be estimated. The severity
shall be assigned to one of the severity classes S0, S1, S2 or S3 in
accordance with following table
The severity class can be based on a combination of injuries, and
this can lead to a higher evaluation of S than would result from
just looking at single injuries.
MAJ 07/03/2010
41/134
Part 3
Class
S0
S1
S2
S3
Description
No injuries
light and moderate injuries
Severe injuries, possibly lifethreatening, survival probable
Life-threatening injuries
(survival uncertain) or fatal
injuries
Reference for single injuries
(from AIS scale)
AIS 0
Damage that cannot be classified
safety-related, e.g. bumps with
roadside infrastructure
more than 10% probability of
AIS 1-6 (and not S2 or S3)
AIS 3-6 (and not S3)
AIS 5-6
Informative examples
-Pushing over roadside infrastructure,
e.g. post or fence
Δv <15km/h
15 < Δv <25 km/h
Δv >25 km/h
 v <15km/h
Δ
15< Δv <35 km/h
Δv >35 km/h
Rear/front collision between
two passenger cars
 v < 20km/h
Δ
20< Δv <40 km/h
Δv>40 km/h,
Other collisions
-Scrape collision with little
vehicle to vehicle overlap (<
10%)
-Roof or side collision with
considerable deformation
Under riding a truck
Without deformation of the
passenger cell
With deformation of the
passenger cell
-Light collision
-Light grazing damage
-Damage while entering or leaving a
parking space
ty
i
r
ve
e
s
-Side collision, e.g. crashing
of tion
s
into a tree (impactlto
e isa
p
passenger cell)
15
<
m Δgvo<r25
km/h xa
E withatae
Side collision c
-Leaving the road without collision or
rollover
passenger car (impact to
passenger cell)
Pedestrian/bicycle accident
MAJ 07/03/2010
E.g. during a turning
manoeuvre inside built-up
area
Outside built-up area
42/134
Part 3
AIS : Abbreviated Injury Scale
MAJ 07/03/2010
43/134
Part 3
¾ Estimation of the probability of exposure
The probability of exposure of each operational situations shall be
estimated. The probability of exposure shall be assigned to one of
the probability classes E0,E1, E2, E3 and E4 in accordance with
following table
Class
E0
E1
E2
E3
E4
Description
incredible
Very low
probability
Low probability
Medium
probability
High probability
The number of vehicles equipped with the item shall not be considered
when estimating the probability of exposure
The hazard analysis and risk assessment is performed for individual
vehicles equipped with the item
MAJ 07/03/2010
44/134
Part 3
Illustration
•Class
E1
E2
E3
Description
Very low
probability
Low probability
Medium
probability
High probability
Definition of
duration/
probability of
exposure
Not specified
< 1% of average operating
time
1% - 10% of
average
operating time
> 10% of average
operating time
Highway – lost
cargo/obstacle on
road
Mountain pass –
driving down hill
with the engine off
Jump start
Garage – vehicle
on roller rig
Pulling a trailer
Driving with roof rack
Driving on a mountain pass
with an unsecured steep
slope
Snow and ice
Driving backwards
Fuelling
Overtaking
Car wash
City driving – driving
backwards
City driving – parking
situation
Country road – crossing
Country road – snow and
ice
Country road –
slippery/leaves
Highway – entering
Highway – exit
Highway – approaching end
of congestion
Parking – sleeping person in
the vehicle
Parking – parking with trailer
Garage – diagnosis
Garage – vehicle on auto lift
Tunnels
Hill hold
Night driving on
roads without
streetlights
Wet roads
Congestion
City driving – one
way street
Highway – heavy
traffic/stop and
go
Accelerating
Braking
Steering
Parking
Driving on
highways
Driving on
secondary roads
City driving –
changing lane
City driving –
stopping at traffic
lights
Country road –
free driving
Highway – free
driving
Highway –
changing lane
Parking – parking
lot
reInformative
u
s
examples
f
o
o
p
x
y
f e bilit
o
ity roba
l
i
b
a
/p ving
b
n
o
o
ri
pr rati
d
f
o d u e in s
s
s
n
r
g
Cla rdin posu uatio
a ex
sit
reg
MAJ 07/03/2010
E4
45/134
re
u
s
f
o
o
p
x
y
f e bilit
o
ity roba
l
i
b
p ing
a
/
b
n
pro ratio driv
f
o d u e in s
s
s
r ion
g
E1
t
Cla rdin posu uaClass
a
t
Very low probability
ex Description
si
reg
Definition of frequency Situations that occur
Part 3
Illustration
Informative examples
MAJ 07/03/2010
less often than
once a year for the
great majority of
drivers
Stop at railway
crossing, which
requires the engine
to be restarted
Towing
Jump start
E2
Low probability
Situations that occur
a few times a year
for the great majority
of drivers
E3
Medium probability
Situations that occur
once a month or
more often for an
average driver
E4
High probability
All situations that
occur during almost
every drive on
average
Pulling a trailer,
driving with a roof
rack
Driving on a
mountain pass with
an unsecured steep
slope
Driving situation with
a deviation from the
desired path
Snow and ice
Fuelling
Overtaking
Tunnels
Hill hold
Car wash
Wet roads
Congestion
Starting
Shifting gears
Accelerating
Braking
Steering
Using indicators
Parking
Driving backwards
46/134
Part 3
¾ Estimation of controllability
The controllability by the driver or other traffic participants shall be
estimated. The controllability shall be assigned to one of the
controllability classes C0, C1, C2 and C3 in accordance with following
table.
The evaluation of possibilities of the avoidance of a specific harm, that
is the controllability, is an estimation of the probability that the driver
or other endangered persons are able to gain control of the hazardous
event that is arising and are able to avoid the specific harm.
MAJ 07/03/2010
47/134
Part 3
Illustration
Class
Description
Definition
Informative
examples
C0
Controllable in
general
Controllable in
general
Unexpected
increase in radio
volume
Situations that are
considered
distracting
Unavailability of a
driver assisting
system
le
b
a
oll
r
t
o n y th e
c
bly or b
i
s
os iver s
p
of e dr ual
s
le th ivid
p
am ds by ind
x
E ar
ed
r
z
e
ha a ng
end
MAJ 07/03/2010
C1
Simply controllable
C2
C3
Normally controllable
Difficult to control or
uncontrollable
99% or more of all drivers 90% or more of all drivers or Less than 90% of all
or other traffic participants other traffic participants are drivers or other traffic
are usually able to avoid a usually able to avoid a
participants are usually
specific harm.
specific harm.
able, or barely able, to
avoid a specific harm.
When starting the vehicle Driver can normally avoid
Wrong steering with high
with a locked steering
departing from the lane in
angular speed at medium
column, the car can be
case of a failure of ABS
or high vehicle speed can
brought to stop by almost during emergency braking.
hardly be controlled by the
all drivers early enough to
driver.
avoid a specific harm to
Driver is normally able to
Driver normally cannot
persons nearby.
avoid departing from the
avoid departing from the
Faulty adjustment of seats lane in case of a motor
lane on snow or ice on a
while driving can be
failure at high lateral
bend in case of a failure of
controlled by almost all
acceleration (motorway
ABS during emergency
drivers by bringing the
exit).
braking.
vehicle to a stop.
Driver normally cannot
bring the vehicle to a stop in bring the vehicle to a stop
case of a total lighting
if a total loss of braking
failure at medium or high
performance occurs.
speed on an unlighted
In the case of faulty airbag
country road without
release at high or
departing from the lane in
moderate vehicle speed,
an uncontrolled manner.
the driver usually cannot
prevent vehicle from
avoid hitting an unlit vehicle departing from the lane.
on an unlit country road.
48/134
Part 3
c) ASIL classification
An ASIL shall be determined for each hazardous event using the estimation
parameters severity (S), probability of exposure (E) and controllability (C) in
accordance with following table.
The work product of the ASIL
determination shall include:
the operational situations and
operating modes with severity,
probability of exposure,
controllability and the
resulting ASIL
MAJ 07/03/2010
the lowest
safety level
49/134
Part 3
c) ASIL classification
Scenario 1
Exposure y
Controlability x
Accident z
ASIL A
ASIL = max
(ASIL A,
ASIL B)
Hazard
Exposure v
Controlability u
Accident w
ASIL B
Scenario 2
MAJ 07/03/2010
50/134
ASIL level (A to D)
Probability per hour
(runtime)
Always
Probability of exposition to
driving situation where accident
can potentially happen
Severity of possible accident
Sometimes
Risk Reduction external to
technical system:
e.g. driver controls situation
not acceptable
Rarely
To
l er
ab
le
R
acceptable
Safety
class
(ASIL)
Reliability
of system and
absence of systematic faults
safety class
(ASIL)
isk
Very rarely
Lower than
tolerable risk
Extreme
improbable
Low
MAJ 07/03/2010
Residual
Risk
Important
Hazardous
(Catastrophically)
Severity
51/134
Part 3
Evaluation of exposure in mutually exclusive operational
situations
During hazard analysis and risk assessment, having established the list
of operational situations and having estimated the values of the S, E
and C parameters for each situation, it shall be ensured that the chosen
level of detail of the list of operational situations does not lead to an
inappropriate lowering of the ASIL of the corresponding safety goals.
Applies to ASIL A, B, C and D: A safety goal shall be formulated
for each hazardous event evaluated in the hazard analysis
An ASIL shall be assigned to each safety goal.
A safe state should be assigned to each safety goal
MAJ 07/03/2010
52/134
Part 3
Example 1
Safety goal “do not let valve1 closed when speed is higher than
100 km/h”.
ASIL C
Safe state : valve1 open.
Example 2
Safety goal “No lock of steering during driving”.
MAJ 07/03/2010
ASIL D
53/134
Part 3
Functional Safety Concept
¾ To comply with the safety goals, the functional safety concept
specifies the basic safety mechanisms and safety measures in
the form of functional safety requirements
¾To specify safety mechanisms the functional safety concept
addresses the following:
•Fault detection and failure mitigation;
•Transitioning to a safe state;
•Fault tolerance mechanisms, where a fault does not lead directly to the violation
of the safety goals and which maintains the system in a safe state (with or
without degradation);
•Fault detection and driver warning in order to reduce the risk exposure time to
an acceptable interval(repair request, stop request); and
•Arbitration logic to select the most appropriate control request from multiple
requests generated simultaneously by different functions.
MAJ 07/03/2010
54/134
Part 3
If the functional safety requirements are allocated to elements of
other technologies then the following shall apply:
¾ the functional safety requirements implemented by other
technologies shall be derived and allocated to the corresponding
elements
¾ the functional safety requirements relating to the interfaces with
other technologies shall be specified
¾ the implementation of functional safety requirements by other
technologies shall be ensured through specific measures
MAJ 07/03/2010
55/134
Part 3
Illustration
SW
L
Ö L, SW et Batt = Significant failures
Batt
SW
Batt
MAJ 07/03/2010
Logic
&
L
warning
Ö sensor, logic et warning = monitoring
sensor
56/134
Part 9
ASIL decomposition
Objectives
Su
de b-p
cr com has
iti p es
ca os o
lit iti f A
y a on S
na an IL
l ys d
is
The objective of this clause is to provide rules and guidance for
decomposing safety requirements into redundant safety
requirements to allow ASIL tailoring at the next level of detail.
MAJ 07/03/2010
57/134
Part 9
ASIL decomposition
General
Starting from safety goals, the safety requirements are derived and detailed during the
development phases. The ASIL, as an attribute of the safety goal, is inherited by each
subsequent safety requirement. The functional and technical safety requirements are allocated
to architectural elements, starting with preliminary architectural assumptions and ending with
the hardware and software elements.
The method of ASIL tailoring during the design process given in ISO 26262 is called "ASIL
decomposition". During the allocation process, benefit can be obtained from architectural
decisions and the existence of independent architectural elements. This offers the opportunity:
•to implement safety requirements redundantly by these independent architectural
elements; and
•to assign a potentially lower ASIL to these redundant safety requirements.
If there is no independence between the elements, the ASIL of the safety goal is inherited by
each requirement and element.
MAJ 07/03/2010
58/134
Part 9
Cla
ssifi
deco cation
sc
mpo
sing heme
safe of AS
ty re
I
quir Ls whe
n
eme
nts
ASIL decomposition
MAJ 07/03/2010
59/134
Part 9
ASIL decomposition
Example
DSC control
unit
Vehicle speed
Opening
request
Power
Sliding
Door
Module
Item
perimeter
Vehicle speed
Switch
Command
to
the
door
actuator
Safety goal : Not to open the door while the vehicle speed is higher than 15 km/h :
ASILC.
1:The DSC will send the accurate vehicle speed information to the PSDM ÎASILC.
2:The PSDM will allow the powering of the actuator only if the vehicle speed is below
15 km/h ÎASIL B(C).
3:The switch will be in an open state if the vehicle speed is above 15 km/h ÎASIL
A(C).
MAJ 07/03/2010
60/134
Part 3
ASIL
decomposition
To sum up this part…
Operational
situation(s)
ASIL classification
Scenario(s)
+ S / E / C quotation
→ max (ASIL)
Safety goal
Defined from
safe state
Functional
Safety
Requirement 1
Verification of FSC
MAJ 07/03/2010
…
Functional
Safety
Requirement i
Σ FSR = Functional Safety Concept
61/134
VII – Product development :
system level
MAJ 07/03/2010
Part 4
62/134
system level
Part 4
Objectives
o to develop the technical safety concept
o to design a system that fulfils the functional requirements
o to verify the system design against the technical safety
requirements
o to check the integration and testing
o to provide evidence that the safety related requirements are
appropriate
MAJ 07/03/2010
63/134
system level
Part 4
Where are we
in the STD ?
MAJ 07/03/2010
64/134
system level
Part 4
Specification of technical safety concept
The first objective of this sub-phase is to develop the technical safety
concept. The technical safety requirements specification refines the
functional safety concept considering the functional concept and the
preliminary architectural design
This part gives a list of recommendations :
o The response of the system or elements to stimuli shall be
specified for each technical safety requirement in combination
t with each possible operating mode and system state
c
a
r
t
o The technical safety concept shall specify functional, safetyex
related and/or other relevant dependencies between systems or
elements
MAJ 07/03/2010
65/134
system level
Part 4
Specification of technical safety concept
The ECU in charge of the Adaptive Cruise Control (ACC)
le switches off the ACC functionality when the brake system ECU
p
am
reports that the Vehicle Stability Control functionality is
x
E
unavailable.
We have as well :
o Control of latent faults (Safety mechanisms dedicated to
detect and control latent faults shall be specified)
o Redundancy (If redundancy is used the type of
redundancy used shall be specified)
MAJ 07/03/2010
66/134
system level
Part 4
System design
The first objective of this subphase is to develop the system design
and the technical safety concept that comply with the functional
requirements and the technical safety requirements specification of
the item .
The second objective of this sub-phase is to verify the system design
against the technical safety requirements.
Requirements for architecture
If requirements with different ASIL are allocated to one architectural
element this element shall be developed according to the highest
ASIL.
If a separation between safety-related elements and other elements is
not possible, each element of the item and their interactions shall be
treated as safety-related
MAJ 07/03/2010
67/134
system level
Part 4
System design
¾ Avoidance of systematic faults :
o Measures for avoidance of systematic faults shall be specified
o Deductive and inductive analysis dedicated to causes and
effects of systematic failures shall be applied according to
following table
ASIL
Methods
B
C
D
1
Deductive analysisa
o
+
++
++
2
Inductive analysisb
++
++
++
++
a
b
MAJ 07/03/2010
A
Deductive analysis methods include FTA, reliability block diagrams.
Inductive analysis methods include FMEA, ETA, Markov modelling.
68/134
system level
Part 4
System design
¾ Usage of well-trusted design principles :
a) Re-use of well-trusted safety architecture;
b) Re-use of well-trusted design principles or
designs for elements, hardware and software
components;
c) Re-use of well-trusted mechanisms for the
detection and control of failures;
d) Re-use of well-trusted or standardised interfaces.
MAJ 07/03/2010
69/134
system level
Part 4
System design
¾ Measures for control of random hardware failures during
operation . Applies to ASIL (B,) C and D :
oThe target values for both metrics of part 5 clause 8, shall be
specified for final evaluation at the item level
oOne of the alternative procedures of part 5 clause 9 shall be
chosen and the target values for final validation at item level
shall be specified.
oAppropriate targets for failure rates and diagnostic coverage
should be specified at element level in order to comply with
the target values of the metrics in part 5 clause 8 and the
procedures in part 5 clause 9.
MAJ 07/03/2010
70/134
system level
Part 4
System design
¾ Verification and system design :
ASIL
Methods
A
B
C
D
1a
System design inspectiona
+
++
++
++
1b
System design walkthrougha
++
+
o
o
2a
Simulationb
+
+
++
++
2b
System prototyping and vehicle testsb
+
+
++
++
3
Safety analysesc
see Table 1
a
Methods 1a and 1b serve as check of complete and correct detailing and implementation of the technical safety
requirements into system design.
b
Methods 2a and 2b can be used advantageously as a fault injection technique.
c
For conducting safety analyses, see ISO 26262-9: —, Clause 8.
MAJ 07/03/2010
71/134
system level
Part 4
Item integration & testing
The first objective of the system integration and testing is to integrate
the parts of a system and, if applicable, systems of other technologies
and external measures or systems step by step into the entire system.
The integrated system has to comply with each safety requirement in
accordance with its specification and ASIL classification
The second objective of the system integration and testing is to verify
that the system design is correctly realised by the entire system
MAJ 07/03/2010
72/134
system level
Part 4
¾Table 3- Methods for deriving test cases for item integration testing
ASIL
Methods
MAJ 07/03/2010
A
B
C
D
1a
Analysis of requirements
++
++
++
++
1b
Analysis of external and internal interfaces
+
++
++
++
1c
Generation and analysis of equivalence classes for hardware software
integration
+
+
++
++
1d
Analysis of boundary values
+
+
++
++
1e
Knowledge or experience based error guessing
+
+
++
++
1f
Analysis of functional dependencies
+
+
++
++
1g
Analysis of common limit conditions, sequences, and sources of common
cause
+
+
++
++
1h
Analysis of environmental conditions and operational use cases
+
++
++
++
1i
Analysis of field experience
+
++
++
++
73/134
system level
Part 4
¾Table 4 — Correctness of implementation of system design
specification and technical safety requirements
ASIL
Methods
A
B
C
D
1a
Requirements-based testa
++
++
++
++
1b
Fault injection testb
+
++
++
++
1c
Back-to-back testc
+
+
++
++
A requirements-based test denotes a test against functional and non-functional requirements.
A fault injection test uses special means to introduce faults into the test object during runtime. This can be done within the
software via a special test interface or specially prepared hardware. The method is often used to improve the test coverage of the
safety requirements, because during normal operation safety mechanisms are not invoked.
c
A back-to-back test compares the responses of the test object with the responses of a simulation model to the same stimuli, to
detect differences between the behaviour of the model and its implementation.
a
b
MAJ 07/03/2010
74/134
system level
Part 4
¾Table 5-Correctness of functional performance of safety mechanisms
ASIL
Methods
A
B
C
D
1a
Back-to-back testa
+
+
++
++
1b
Performance testb
+
++
++
++
a
A back-to-back test compares the responses of the test object with the responses of a simulation model to the same stimuli, to
detect differences between the behaviour of the model and its implementation.
b
A performance test can verify the performance concerning e.g. task scheme, timing, power output in the context of the whole test
object, and can verify the ability of the hardware to run with the intended control software.
¾Table 6-Consistency and correctness of implementation of
external and internal interfaces
ASIL
Methods
A
B
C
D
1a
Test of external interfacesa
+
++
++
++
1b
Test of internal interfacesa
+
++
++
++
1c
Interface consistency checka
+
++
++
++
a
Interfaces tests of the test object include tests of analogue and digital inputs and outputs, boundary tests and equivalent-class
tests to completely test the specified interfaces, compatibility, timings and other specified ratings for the test object. Internal interfaces
of an ECU are tested by static tests for the compatibility of software and hardware as well as dynamic tests of SPI- or I2Ccommunications or any other interface between elements of an ECU.
MAJ 07/03/2010
75/134
system level
Part 4
¾Table 7 — Effectiveness of diagnostic coverage of hardware fault
detection mechanisms
ASIL
Methods
A
B
C
D
1a
Fault injection testa
+
+
++
++
1b
Error guessing testb
+
+
++
++
a
A fault injection test uses special means to introduce faults into the test object during runtime. This can be done within the
software via a special test interface or specially prepared hardware. The method is often used to improve the test coverage of
the safety requirements, because during normal operation safety mechanisms are not invoked.
b
An error guessing test uses expert knowledge and data collected through lessons learned to anticipate errors in the test
object. Then a set of tests along with adequate test facilities is designed to check for these errors. Error guessing is an effective
method given a tester who has previous experience with similar test objects.
¾Table 8 — Level of robustness
ASIL
Methods
A
B
C
D
1a
Resource usage testa
+
+
+
++
1b
Stress testb
+
+
+
++
a
A resources usage test can be done statically e.g. by checking for code sizes or analyzing the code regarding interrupt
usage, in order to verify that worst-case scenarios do not run out of resources, or dynamically by runtime monitoring.
b
A stress test verifies the test object for correct operation under high operational loads or high demands from the
environment. Therefore, tests under high loads on the test object, or with exceptional interface loads, or values (bus loads,
electrical shocks etc.), as well as tests with extreme temperatures, humidity or mechanical shocks, can be applied.
MAJ 07/03/2010
76/134
system level
Part 4
¾Table 11 — Consistency and correctness of implementation of
external and internal interfaces
ASIL
Methods
A
B
C
D
1a
Test of external interfacesa
+
++
++
++
1b
Test of internal interfacesa
+
++
++
++
1c
Interface consistency checka
o
+
++
++
1d
Communication testb
++
++
++
++
1e
Test of interaction/communicationb
++
++
++
++
a
An interface test of the system includes tests of analogue and digital inputs and outputs, boundary tests, and equivalent-class tests, to
completely test the specified interfaces, compatibility, timings, and other specified characteristics of the system. Internal interfaces of the
system are tested by static tests, (e.g. match of plug connectors). as well as by dynamic tests concerning bus communications or any other
interface between elements of the system.
b
A communication and interaction test includes tests of the communication between the elements of the system as well as between the
system under test and other vehicle systems during runtime against functional and non-functional requirements.
MAJ 07/03/2010
77/134
system level
Part 4
¾Table 12 — Effectiveness of diagnostic failure coverage of safety
mechanisms at item level
Test methods
ASIL
A
B
C
D
1a
+
+
++
++
1b
Error guessing testb
+
+
++
++
1c
Test derived from field experiencec
o
+
++
++
a
A fault injection test uses special means to introduce faults into the item. This can be done within the item via a special test
interface, specially prepared elements, or communication devices. The method is often used to improve the test coverage of the
safety requirements, because during normal operation safety measures are not invoked.
b
An error guessing test uses expert knowledge and data collected through lessons learned to anticipate errors in the item.
Then a set of tests along with adequate test facilities is designed to check for these errors. Error guessing is an effective method
given a tester who has previous experience with similar items.
c
A test derived from field experience uses the experience and data gathered from the field. Erroneous system behaviour or
newly discovered operational situations are analysed and a set of tests is designed to check the system with respect to the new
findings.
MAJ 07/03/2010
78/134
system level
Part 4
Safety validation
The first objective is to provide evidence of due compliance with
the functional safety goals and that the safety concepts are
appropriate for the functional safety of the item.
The second objective is to provide evidence that the safety goals
are correct, complete and fully achieved at vehicle level.
MAJ 07/03/2010
79/134
system level
Part 4
Safety validation
¾ The following methods and measures shall be used or carried out,
depending on the ASIL level
o reproducible tests with specified test procedures, test cases, and
pass/fail criteria;
o EXAMPLE : positive tests of functions and safety requirements, black
box, simulation, tests under boundary conditions, fault injection,
durability tests, stress tests, highly accelerated life testing (HALT),
simulation of external influences
o analyses (e.g. FMEA, FTA, ETA, simulation);
o long-term tests, such as vehicle driving schedules and captured test
fleets;
o user tests under real-life conditions, panel or blind tests, expert panels;
o reviews.
MAJ 07/03/2010
80/134
system level
Part 4
Functional safety assessment
The objective of the requirements in this Clause is to assess functional
safety, that is achieved by the item
For each step of the safety lifecycle in ISO 26262-2 Figure 2, the
specific topics to be addressed by the functional safety assessment
shall be identified.
The functional safety assessment shall be conducted in accordance
with ISO 26262-2 clause 6.4.6.7
MAJ 07/03/2010
81/134
system level
Part 4
a
d
n
ge of
a
an ent r
f
o sm
fo
e
l
s
y
p
e
t
am n ass l safe
x
E r a na
fo ctio IL D
AS
fun
MAJ 07/03/2010
82/134
system level
Part 4
Release for production
The objective of this clause is to specify the criteria for the release
for production at the completion of the item development. The
release for production confirms that the item complies with the
requirements for functional safety at vehicle level.
The release documentation of functional safety for release for
production shall include the following information:
o the name and signature of the person in charge of release;
o the version/s of the released item;
o the configuration of the released item;
o references to associated documents;
o the release date.
MAJ 07/03/2010
83/134
system level
ASIL
decomposition
ASIL classification
To sum up this part…
Operational
situation(s)
Scenario(s)
+ S / E / C quotation
→ max (ASIL)
Defined from
safe state
Σ TSR = Technical
Safety Concept
Part 4
Safety goal
Functional
Safety
Requirement 1
Technical Safety
Requirement 1
…
…
Functional
Safety
Requirement i
Σ FSR = Functional
Safety Concept
Technical Safety
Requirement i
MAJ 07/03/2010
84/134
VIII – Product development :
hardware level
MAJ 07/03/2010
Part 5
85/134
hardware level
Part 5
Objectives
¾ The objective of the initiation of the product development for
the hardware is to determine and plan the functional safety
activities during the individual sub-phases of hardware
development.
MAJ 07/03/2010
86/134
hardware level
Part 5
Initiation of product
development
ce
n
e
er r
f
e
r
fo
e
v
l
i
e
t
d of a
a
o
m
r
o se m ent tem
f
n
I pha pm d i
lo late
e
v
de ty-re
e
saf
MAJ 07/03/2010
87/134
hardware level
Part 5
Specification of hardware safety requirements
The first objective of this clause is to make available a consistent and
complete hardware specification that will be applied to the hardware
of the item or element under consideration. The requirements of this
specification are hardware safety requirements.
The second objective is to verify that the hardware safety
requirements are consistent with the technical safety concept.
A further objective of this phase is to detail the hardware-software
interface (HSI) requirements
MAJ 07/03/2010
88/134
hardware level
Part 5
¾ The hardware safety requirements specification shall include:
o The hardware safety requirements of safety mechanisms
dedicated to control failures external to the element under
consideration with their relevant attributes
dedicated to control internal failures of the hardware of the item
or element, with their relevant attributes
dedicated to detect and signal internal or external failures
o The hardware safety requirements that describe the
characteristics needed to ensure the effectiveness of the above
safety mechanism
MAJ 07/03/2010
89/134
hardware level
Part 5
This includes for instance the functional behaviour
required for an ECU in case of an external failure, such as
an open-circuit in the input of the ECU
These attributes may be for instance timing and detection
abilities of a watchdog
This includes for instance the allocated time of reaction
for the hardware part of a safety mechanism, so as to be
consistent with the fault-tolerant time
MAJ 07/03/2010
90/134
hardware level
Part 5
¾Verification of the hardware safety requirements
ASIL
Methods
MAJ 07/03/2010
A
B
C
D
1a
Walkthrough of hardware safety requirements
++
+
o
o
1b
Inspection of hardware safety requirements
+
++
++
++
91/134
hardware level
Part 5
Hardware design
The first objective of this clause is to design the hardware with
respect to the system design specification and the hardware
safety requirements
The second objective of this clause is to verify the hardware
design against the system design specification and the hardware
safety requirements.
MAJ 07/03/2010
92/134
hardware level
Part 5
Hardware design
o In order to avoid common design faults, lessons learned, if applicable,
shall be used.
o Non-functional causes for failure of a safety-related hardware part shall
be considered during hardware detailed design, including the following
influences, if applicable: temperature, vibrations, water, dust, EMI,
noise factor, cross-talks originating either from other hardware parts of
the hardware component or from its environment.
o The hardware detailed design shall ensure that hardware parts are used
within their environmental and operational specifications.
MAJ 07/03/2010
93/134
hardware level
Part 5
Hardware design
Safety analysis of architectural design and hardware failures shall
be conducted at appropriate levels: system or component, to identify
new functional or non-functional hazards not already considered
during hazard analysis and risk assessment and to identify the
safety-related hardware elements
For each safety-related hardware element the safety analysis shall
identify:
o Safe faults
o Single point faults or residual faults
o Dual point faults (either perceived, detected or latent)
MAJ 07/03/2010
94/134
hardware level
Part 5
Verification of hardware design
Methods
ASIL
A
B
C
D
1a
Hardware design inspectiona
+
+
++
++
1b
Hardware design walkthrough a
++
++
o
o
2
Safety analyses
3a
Emulation by simulationb
o
+
+
+
3b
Development by prototype hardware
o
+
+
+
See 7.4.3
a
Methods 1a and 1b serve as a check of the complete and correct implementation of the technical safety
requirements in the hardware design
b
Methods 3a and 3b serve as a check of particular points of hardware design for which analytical methods 1 and 2
are not considered sufficient. It can be used among other as a fault injection technique.
MAJ 07/03/2010
95/134
hardware level
Part 5
Hardware architectural metric
Single Point
Failure with safety
mechanism (included
covered rate)
« Safety » failure
MAJ 07/03/2010
+
< N%
ASIL C : N= 3%
ASIL D : N=1%
96/134
hardware level
Part 5
Assessment criteria for probability of violation of safety goals
The objective of the requirements in this clause is to make
available criteria that can be used in a rationale that the residual
risk of safety goal violation, due to random hardware failures of
the item, is sufficiently low.
NOTE ‘Sufficiently low’ means “comparable to accepted risks
on similar items already in use”.
MAJ 07/03/2010
97/134
hardware level
Part 5
Two alternative methods :
¾The first method consists of using a probabilistic metric to evaluate
violation of the considered safety goal (using for instance quantified
FTA) and compares the result of this quantification with a target value.
¾The second method consists of the individual evaluation of each
residual and single point fault and of each dual point failure leading to
the violation of the considered safety goal. This analysis method can
also be considered to be a cut-set analysis.
The scope of this clause is limited to the random hardware failures of
the item. The parts considered in the analyses are the electrical and
electronic parts. For electromechanical parts, only the electrical failure
modes and failure rate are considered.
MAJ 07/03/2010
98/134
hardware level
Part 5
For first alternative method
• Table G.1 — Random hardware failure target values
Random hardware failure target values
ASIL Level
MAJ 07/03/2010
D
< 10-8 h-1
C
< 10-7 h-1
B
< 10-7 h-1
A
< 10-6 h-1
99/134
hardware level
Part 5
For second alternative method
Begin
No
Each single point fault is
evaluated using criteria on
occurrence of the fault. Each
residual fault is evaluated using
criteria combining occurrence
of the fault and efficiency of the
safety mechanism.
Single point fault?
or residual fault?
Redesign
Yes
Meet occurrence target and diagnostic
coverage of safety mechanisms with regard to
single point or residual fault (table 5)
Yes
No
Add or improve
safety mechanisms to mitigate
fault
single point or residual fault (table 5)
No
Yes
End
MAJ 07/03/2010
100/134
hardware level
Part 5
Table 5 — Targets of failure rate class and coverage of
hardware part regarding residual faults
Diagnostic Coverage wrt. residual faults
ASIL of Safety
Goal
a
MAJ 07/03/2010
>= 99 %
>= 90 %
< 90 %
D
Failure rate class 3
++
++
Failure rate class 1 +
dedicated measuresa
++
C
o
++
Failure rate class 2 +
dedicated measuresa
++
B
o
+
+
The note in requirement 9.4.3.4 gives examples of dedicated measures
101/134
hardware level
Part 5
Begin
Independent faults?
(common-cause analysis)
No
Assessment procedure for
single point fault
Yes
No
Redesign
Plausible dual point failure?
Yes
multiple point fault (table 6)
Yes
No
Add or improve safety mechanisms to
eliminate or mitigate latent fault
No
Plausible dual point failure?
Yes
multiple point fault (table 6)
No
Yes
End
MAJ 07/03/2010
Each dual point failure is
first evaluated regarding its
plausibility. A dual point
failure is considered not
plausible if both faults
leading to the failure are
detected or perceived in a
sufficiently short time with
sufficient coverage. If the
dual point failure is
plausible, the faults causing
it are then evaluated using
criteria combining
occurrence of the fault and
coverage of the safety
mechanisms.
102/134
hardware level
Part 5
Table 6 — Targets of failure rate class and coverage of
hardware part regarding dual point faults
Diagnostic Coverage wrt. latent multiple point faults
>= 99 %
>= 90 %
< 90 %
D
o
++
++
C
o
o
++
ASIL of Safety
Goal
MAJ 07/03/2010
103/134
hardware level
Part 5
The failure rate class ranking for a hardware part failure
rate shall be determined as follows:
¾ The failure rate corresponding to failure rate class 1 shall be less
than the target for ASIL D divided by 100;
than ten times the failure rate corresponding to failure rate class
1;
than a hundred times the failure rate corresponding to failure rate
class 1.
MAJ 07/03/2010
104/134
hardware level
Part 5
Evaluation of the diagnostic coverage
D.9 Power Supply
D.2 E/E System
D.11
Sensor
D.3
Con nector
D.11
Sensor
D.3
Con - D.7 Analogue I. Processing Unit
nector
D.3 Relay
D.7 DigitalI.
Con nector
D.4
D.8 Serial bus
interface
D.6
RAM
D.5 ROM
D.7 Digital O.
Con nector
D.7 Analogue O
Con nector
D.12
Actuator
D.12
Actuator
D.12
Actuator
D.10 Clock
Table D.2 — Systems
See overview of
techniques
Maximum diagnostic
coverage considered
achievable
Notes
Failure detection by on-line
monitoring
D.2.1.1
Low
Depends on diagnostic coverage
of failure detection
comparator
D.2.1.2
High
Depends on the quality of the
comparison
Majority voter
D.2.1.3
High
Depends on the quality of the
voting
Dynamic principles
D.2.2.1
Medium
Analogue signal monitoring
in preference to digital on/off
states
D.2.2.2
Low
Self-test by software cross
exchange between two
independent units)
D.2.3.5
Medium
Diagnostic
technique/measure
D.2 E/E System
MAJ 07/03/2010
Generic hardware of
an E/E system
Depends on diagnostic coverage
of failure detection
-
Depends of the quality of the self
test
105/134
hardware level
Part 5
Hardware integration & testing
Objectives of this sub-phase are to ensure the compliance of the
developed hardware with the hardware safety requirements
ASIL
Methods
A
B
C
D
++
++
++
++
1a
Analysis of requirements
1b
Analysis of internal and external interfaces
+
++
++
++
1c
Generation and analysis of equivalence classesa
+
+
++
++
1d
Analysis of boundary valuesb
+
+
++
++
1e
Knowledge or experience based error guessingc
++
++
++
++
1f
Analysis of functional dependencies
+
+
++
++
1g
Analysis of common limit conditions, sequences and sources of common cause
+
+
++
++
1h
Analysis of environmental conditions and operational use cases
+
++
++
++
1i
Standards if existingd
+
+
+
+
1j
Analysis of significant variantse
++
++
++
++
a
b
c
d
e
In order to efficiently derive the necessary test cases, analysis of similarities can be conducted.
EXAMPLE values approaching and crossing the boundaries between specified values and out of range values
“Error guessing tests” should be based on data collected through lesson learned process, or expert judgment, or both. It can be supported by FMEA for example.
Existing standards can be ISO 16750 and ISO 11452.
The analysis of significant variants includes worst case analysis.
MAJ 07/03/2010
106/134
IX – Product development :
software level
MAJ 07/03/2010
Part 6
107/134
software level
Part 6
Objectives
o to provide a consistent software requirement specifications
o to design & analyse the software
o to evaluate the software architecture of the item
o to check the integration and testing
MAJ 07/03/2010
108/134
software level
Part 6
Initiation of product development
MAJ 07/03/2010
109/134
software level
Part 6
Specification of software safety requirements
The technical safety requirements are divided into hardware and
software safety requirements. The specification of the software safety
requirements considers constraints of the hardware and the impact of
these constraints on the software.
¾ The software safety requirements shall address each software-based
function whose failure could lead to a violation of a technical safety requirement
allocated to software.
¾ The persons responsible for the hardware and software development shall
jointly verify the refined hardware software interface specification.
ASIL
Methods
Table 2 —
Methods for the
verification of
requirements
B
C
D
1a
Informal verification by walkthrough
+
+
+
o
o
1b
Informal verification by inspection
+
+
+
+
+
+
+
1c
Semi-formal verificationa
+
+
+
+
+
+
1d
Formal verification
o
+
+
+
a
MAJ 07/03/2010
A
Method 1c can be supported by executable models.
110/134
software level
Part 6
Software architectural design
The software architectural design shall exhibit the following
properties by use of the principles listed in Table 4:
¾modularity;
¾encapsulation and;
¾minimum complexity.
Methods
ASIL
A
B
C
D
1a
Hierarchical structure of software components
++
++
++
++
1b
Restricted size of software componentsa
++
++
++
++
1c
Restricted size of interfacesa
+
+
+
+
1d
High cohesion within each software componentb
+
++
++
++
1e
Restricted coupling between software componentsa, b, c
+
++
++
++
1f
Appropriate scheduling properties
++
++
++
++
1g
Restricted use of interruptsa, d
+
+
+
++
In methods 1b, 1c, 1e and 1g "restricted" means to minimise in balance with other design considerations.
Methods 1d and 1e can, for example, be achieved by separation of concerns which refers to the ability to identify, encapsulate, and
manipulate those parts of software that are relevant to a particular concept, goal, task, or purpose.
c
Method 1e addresses the limitation of the external coupling of software components.
d
Any interrupts used have to be priority-based.
a
b
MAJ 07/03/2010
Table 4 — Principles
for software
architectural design
111/134
software level
Part 6
Software integration and testing
Table 15 — Methods for software integration testing
ASIL
Methods
A
B
C
D
1a
Requirements-based test
++
++
++
++
1b
External interface test
++
++
++
++
1c
+
+
++
++
1d
Resource usage testb, c
+
+
+
++
1e
Back-to-back test between model and code, if applicabled
+
+
++
++
a
This includes injection of arbitrary faults in order to test safety mechanisms (e.g. by corrupting software or hardware
components)
b
To ensure the fulfilment of requirements influenced by the hardware architectural design with sufficient tolerance, properties
such as average and maximum processor performance, minimum or maximum execution times, storage usage (e.g. RAM for stack
and heap, ROM for program and data) and the bandwidth of communication links (e.g. data busses) have to be determined.
c
Some aspects of the resource usage test can only by evaluated properly when the software integration tests are executed on
the target hardware or if the emulator for the target processor supports resource usage tests.
d
This method requires a model that can simulate the functionality of the software components. Here, the model and code are
stimulated in the same way and results compared with each other.
MAJ 07/03/2010
112/134
X – Product & operation
MAJ 07/03/2010
Part 7
113/134
Part 7
Objectives
¾The first objective of the requirements in this Clause is to
develop a production plan for safety-related products.
¾The second objective is to ensure that the required functional
safety is achieved during the production process by the relevant
product manufacturer or the person or organisation in charge of
the process (vehicle manufacturer, supplier, sub-supplier etc.).
MAJ 07/03/2010
114/134
Part 7
Information required
¾ Production planning
¾ Control plan (the tests description and criteria for safety-related
systems, focus on the systematic faults…)
¾ Process failures and their potential effects on functional safety
shall be analysed and the appropriate measures shall be
implemented
¾ The lessons on the capability, learnt from previously released
production plans
¾ Tools and test equipment concerning the safety-related special
characteristics
¾ The competence of the personnel
MAJ 07/03/2010
115/134
Part 7
Operation, service (maintenance and repair), and decommissioning
¾The processes concerning operation, repair and maintenance
shall be planned
¾The user manual shall include relevant usage instructions and
warnings concerning the item
¾The requirements regarding the decommissioning activities
shall be developed
MAJ 07/03/2010
116/134
XI – Supporting processes
MAJ 07/03/2010
Part 8
117/134
Part 8
Objective
The objective of this process is to describe the procedures and allocate
associated responsibilities within distributed developments for items
and elements.
o Interfaces within distributed developments
o Specification and management of safety requirements
o Configuration management
o Change management
o Verification
o Documentation
o Qualification of software tools
o Qualification of software components
o Qualification of hardware components
o Proven in use argument
MAJ 07/03/2010
118/134
Part 8
Interfaces within distributed developments
¾ Supplier selection criteria :
o Verification of the supplier's quality management system
o Consideration of the supplier's experience in developing products
of comparable complexity and ASIL
o The supplier's capability in developing products of comparable
complexity
¾ The customer and the supplier shall specify a Development Interface
Agreement (DIA)
MAJ 07/03/2010
119/134
Part 8
Specification and management of safety requirements
The first objective is to ensure the correct specification of safety
requirements with respect to attributes and characteristics.
The second objective is to ensure consistent management of
safety requirements throughout the entire safety lifecycle.
Safety requirements constitute all requirements aimed at achieving and
ensuring the required degree of functional safety
During the safety lifecycle, safety requirements are specified and
detailed in a hierarchical structure. The structure and dependencies of
safety requirements as used in this International Standard are illustrated
hereinafter
In order to support the management of safety requirements, the use of
suitable tools for requirements management is recommended
MAJ 07/03/2010
120/134
Part 8
Overall management of safety requirements
Structuring of safety requirements
MAJ 07/03/2010
121/134
Part 8
Configuration management
¾ Configuration management is a well established practice
within the automotive industry and is usually applied according
to ISO TS 16949, 4.2.3, ISO 10007:2003.
¾Each work product of ISO 26262 is managed by configuration
management.
¾ Configuration management shall be maintained throughout
the entire safety lifecycle.
MAJ 07/03/2010
122/134
Part 8
Change management
The objective of change management is the analysis and
management of changes to safety-related work products
occurring throughout the safety lifecycle.
¾ The change management process shall be planned and
initiated, before changes are made to work products.
¾ A unique identifier shall be assigned for each change request.
¾ An impact analysis on the existing system and its interfaces
and connected systems shall be carried out for each change
request
MAJ 07/03/2010
123/134
Part 8
Verification
¾ The first objective of verification is to ensure that the work
products are correct, complete and consistent.
¾The second objective of verification is to ensure that the work
products meet the requirements of ISO 26262.
¾ The planning of verification shall be carried out for each phase
and subphase of the safety lifecycle
¾ The specification of verification shall specify and select the
methods to be used for the verification
MAJ 07/03/2010
124/134
Part 8
Documentation
The objective of the documentation 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 documents shall be:
- precise and concise;
- structured in a clear manner;
- easy to understand by their intended audience; and
- maintainable.
MAJ 07/03/2010
125/134
Part 8
Qualification of software tools
The objective of the qualification of software tools is to provide
evidence of software tool suitability for use when developing a safetyrelated item or element, such that confidence can be achieved in the
correct execution of activities and tasks required by ISO 26262.
The relevant software tool use-cases shall be analysed and evaluated to
determine:
¾the possibility that a safety requirement, allocated to the safety-related item
or element is violated if the software tool is malfunctioning or producing
erroneous output, is expressed by the classes of classes of TI (Tool Impact)
¾the probability of preventing or detecting that the software tool is
malfunctioning or producing erroneous output is expressed by the classes of
TD (Tool error Detection)
MAJ 07/03/2010
126/134
Part 8
Qualification of software tools
Based on the values determined to the classes of TI and TD the required software
tool confidence level shall be determined according to the following list:
•TCL1 shall be selected for TI0;
•TCL1 shall be selected for TI1 and TD1;
•TCL2 shall be selected for TI1 and TD2;
•TCL3 shall be selected for TI1 and TD3; and
•TCL4 shall be selected in all other cases
TCL is an abbreviation for “Tool Confidence Level”, with TCL 4 being the
highest level of confidence required and TCL1 being the lowest level of
confidence required
ASIL
Methods
Table 2 — Qualification of software
tools classified TCL4
A
B
C
D
1a
Increased confidence from use
++
++
+
o
1b
Evaluation of the development process
++
++
++
+
1c
Validation of the software tool
+
+
++
++
1d
Development in compliance with a safety standarda
+
+
++
++
No safety standard is fully applicable to the development of software tools. Instead, a relevant subset of
requirements of the safety standard can be selected.
a
MAJ 07/03/2010
127/134
Part 8
Qualification of software components
¾First objective : to enable the re-use of existing software
components as part of items, systems or elements developed in
compliance with ISO 26262 without completely re-engineering the
software components.
¾Second objective : to show their suitability for re-use.
The qualification of a software component shall be documented
including the following information:
•unique identification and configuration of the software component;
•person or organisation who carried out the qualification;
•the environment used for qualification;
•results of the verification measures applied to qualify the software
component; and
•the pre-determined maximum target ASIL of any safety
requirement which might be violated if the software component
performs incorrectly.
MAJ 07/03/2010
128/134
Part 8
Qualification of hardware components
¾First objective : to show the suitability of intermediate level
hardware components and parts for their use as part of items, systems
or elements, developed in compliance with ISO 26262, concerning
their functional behaviour and their operational limitations.
¾Second objective : to provide relevant information regarding their
failure modes and their distribution, and their diagnostic capability
with regard to the safety concept for the item.
MAJ 07/03/2010
129/134
Part 8
Qualification of hardware components
Table 5 — Qualification, integration and test activities to be conducted depending on the level of HW part or component
Intermediate HW part
Basic HW part
No contribution
to a safety
requirement
Contributio
n to a
safety
requiremen
t
(resistors, transistors…)
No
contribution to
a safety
requirement
Contribution
to a safety
requirement
(HS CAN
transceiver)
Intermediate HW
component
No
contribution to
a safety
requirement
Complex HW
component
Contribution
to a safety
requirement
A safety requirement
is fully implemented
by the HW
component
(gray code
decoder)
(fuel
pressure
sensor)
(ECU)
*
*
Standard
qualification
Qualification in
accordance with
ISO26262-8:—,
Clause 13
Integration/test
in accordance
with ISO262625:—
Integration/test
in accordance
with ISO262624:—
* means that the HW element will be integrated in accordance with ISO 26262-4:— , or ISO 26262-5:—, or both ISO 26262-5:— and
ISO 26262-4:— depending on "its level".
MAJ 07/03/2010
130/134
Part 8
Proven in use argument
The objective of this clause is to provide guidance for proven in
use argument. Proven in use argument is an alternate means of
compliance with ISO 26262 requirements that may be used in
case of reuse of existing items or elements when field data is
available.
Targets for demonstration of
compliance with safety goal
ASIL
MAJ 07/03/2010
Per safety
goal
Targets for minimum service
period of candidate
Observable incident rate
D
< 10-9/h
C
<
10-8/h
B
< 10-8/h
A
< 10-7/h
ASIL
Minimum service period without
observable incident
D
1.2 ∙ 109 h
C
1.2 ∙ 108 h
B
1.2 ∙ 108 h
A
1.2 ∙ 107 h
131/134
Part 8
Proven in use argument
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
according to Table 8 with a single sided lower confidence level
of 70%.
Table 8 — Limits for observable incident rate (interim period)
ASIL
D
C
B
A
MAJ 07/03/2010
Observable incident rate
< 3 ∙ 10-9/h
< 3 ∙ 10-8/h
< 3 ∙ 10-8/h
< 3 ∙ 10-7/h
132/134
XII – ASIL oriented and safety
analysis
Part
Part
9 8
Criteria for coexistence of element
General
By default, when an element is composed of several sub-elements,
each of those sub-elements is developed in accordance with the
measures corresponding to the highest ASIL applicable to this
element.
In the case of coexistence in the same element of safety-related subelements with different ASILs, a sub-element shall only be treated
as a lower ASIL sub-element if it is shown that it does not interfere
with any other sub-element assigned a higher ASIL, for each of the
safety requirements allocated to the element.
MAJ 07/03/2010
133/134
e.g. Planning, Qualification, Def. of Responsibilities,
Management Processes
e.g. Configuration Management, Documentation,
Supporting Processes
Implementation of a Automotive
Safety Process
System
Definition
Description of system or function and it’s
boundaries
Collection of
driving situations
Malfunction of
technical system
Hazard Analysis
and
Risk
Classification
Safety Class:
(e.g. ASIL D)
Protection goals
(e.g. no de-stabilization)
Safety
Requirements
Safety integrity requirement
(How good)
- e.g. <10-x dang. failures/h (HW)
Safety function (What)
(e.g. do not send
wrong signal)
Realization
Design and
Implementation
Verification &
Validation
Safety Analysis
FMEA, FTA, Markoff, ...
Safety Case
MAJ 07/03/2010
134/134

system level - UTC

Transcription

Documents pareils

Motorcycle tyres and rims (metric series) — Part 1: Design guides

how can you and your business get the - SGS

Jeux De Casino Xbox 360

1 - Portail de la Qualité

TIP OF THE SPEAR - Professional Soldiers

II. Digital Trust - Portail de la Qualité

Belgian Metalworking Suppliers

ISO/IEC 18000-2

Morocco

CCWS Working paper no. 2011-75 Portraits of Poverty in the USA

20140216-BD-Reprises Perso.indd

Contributions au génie logiciel et au développement et