ISO/DIS 26262 Global training - UTCMAJ 07/03/2010. Introduction à la norme ISO 26262 27/134. V –...
Transcript of ISO/DIS 26262 Global training - UTCMAJ 07/03/2010. Introduction à la norme ISO 26262 27/134. V –...
Introduction à la norme ISO 26262MAJ 07/03/2010 1/134
ISO/DIS 26262ISO/DIS 26262 Global trainingGlobal training
Introduction à la norme ISO 26262MAJ 07/03/2010 2/134
AgendaAgenda
Learning objectivesIntroductionI. Normative referencesII. HistoryIII. Scope of the standardIV. Vocabulary – part 1V. Management of Functional Safety – part 2VI. Concept phase – part 3VII. Product development : system level – part 4VIII.Product development : hardware level – part 5IX. Product development : software level – part 6X. Product & operation – part 7XI. Supporting processes – part 8XII. ASIL – oriented and safety analysis – part 9XIII.Guideline – part 10
Introduction à la norme ISO 26262MAJ 07/03/2010 3/134
General General learninglearning objectivesobjectives
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 copewith the identified risks
At the end of the session, attendees should be able :
Introduction à la norme ISO 26262MAJ 07/03/2010 4/134
Introduction of the Introduction of the AutomotiveAutomotive Safety Standard 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 ».
Part 1 : VocabularyPart 2 : Management of functional safetyPart 3 : Concept phasePart 4 : Product development system levelPart 5 : Product development hardware levelPart 6 : Product development software levelPart 7 : Production & OperationPart 8 : Supporting processPart 9 : ASIL oriented and safety oriented analysesPart 10 : Guideline
Introduction à la norme ISO 26262MAJ 07/03/2010 5/134
Introduction of the Introduction of the AutomotiveAutomotive Safety Standard Safety Standard
Introduction à la norme ISO 26262MAJ 07/03/2010 6/134
Introduction of the Introduction of the AutomotiveAutomotive Safety Standard 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 determiningrisk 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
Introduction à la norme ISO 26262MAJ 07/03/2010 7/134
I I –– Normative Normative referencesreferences
ISO 9001- 2000, Quality management systems – Requirements
ISO 16949 Quality management systems – Particularrequirements for the application of ISO 9001- 2000 forautomotive production and relevant service part organizations
ISO 3779, Road vehicles – Vehicle Identification Number (VIN)
ISO 3883, Road vehicles – Types – Terms and definitions
Introduction à la norme ISO 26262MAJ 07/03/2010 8/134
RiskCombination of the probability of occurrence of harm and the severity of that harm
Functional safetyAbsence of unreasonable risk due to hazards caused by malfunctioning behavior of E/E systems
SafetyAbsence of unreasonable risks
II II -- HistoryHistory
First definition…
Introduction à la norme ISO 26262MAJ 07/03/2010 9/134
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 supportprocesses
II II -- HistoryHistory
Introduction à la norme ISO 26262MAJ 07/03/2010 10/134
Objectives of this standard ?
Standard shall support implementation of development processesand 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
II II -- HistoryHistory
Introduction à la norme ISO 26262MAJ 07/03/2010 11/134
Objectives of this standard ?
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
II II -- HistoryHistory
Introduction à la norme ISO 26262MAJ 07/03/2010 12/134
Convenor: Ch.Jung, Secretary: E. Fritzsche, FAKRA
Germany: BMW, Bosch, Continental, Daimler, VWFrance: PSA, Renault, Continental, ValeoAustria: (MagnaSteyr, ARC Seibersdorf Research GmbH) Italy: Fiat Group, Centro Ricerche Fiat, TRWJapan: Honda, Nissan, Toyota, Denso, Hitachi Sweden: Volvo Cars, AB Volvo, Delphi, UK: Landrover, MIRA USA: TRW, GM, Delphi Belgium: Nissan Europe, Toyota EuropeCanada: Critical Systems Labs
Workteam
II II -- HistoryHistory
Introduction à la norme ISO 26262MAJ 07/03/2010 13/134
IEC 61508
other Safety StandardsQuality Standards
Engineering Standards
Initial work of individual companies
Initiatives within
national standardization
bodies
ISOTC22 SC3
WG16
First drafts of
requirementspecifications
RESPONSEAutomotive SPICE
FAKRABNAMISRA
OEMsSuppliers
Technical Services
9.20051.2004
2002 2003
2011
II II -- HistoryHistory
Introduction à la norme ISO 26262MAJ 07/03/2010 14/134
CD Voting
CD Voting
7/07 3/08 6/08 12/08 6/09 12/09 6/10
CD Voting
12/086/08 12/09 12/10 6/116/09
decided
II II -- HistoryHistory
DIS is approved and can be communicated outside the Working Group
Introduction à la norme ISO 26262MAJ 07/03/2010 15/134
III III –– Scope of the standardScope 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 disabilitiesISO 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.
Introduction à la norme ISO 26262MAJ 07/03/2010 16/134
IV IV –– VocabularyVocabulary Part 1
Introduction à la norme ISO 26262MAJ 07/03/2010 17/134
IV IV –– VocabularyVocabularyMain terms …
Part 1
ItemSystem or array of systems or a function to which ISO 26262 is appliedSafetyAbsence of unreasonable riskFunctional safetyAbsence of unreasonable risk due to hazards caused by malfunctioning behaviour of E/E systemsSafety caseArgument that the safety goals for an item are complete and satisfied by evidence compiled from work products of the safety activities during developmentNOTE Safety case can be extended to cover safety issues beyond the scope of this standard.
Introduction à la norme ISO 26262MAJ 07/03/2010 18/134
Exposurestate of being in an operational situation that can be hazardous if coincident with the failure mode under analysis
Severitymeasure of the extent of harm to an individual in a specific situationAutomotive 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 levelSafety goalTop-level safety requirement as a result of the hazard analysis and risk assessment
Part 1IV IV –– VocabularyVocabulary
Main terms …
Introduction à la norme ISO 26262MAJ 07/03/2010 19/134
Part 1IV IV –– VocabularyVocabulary
Main terms …
Random hardware faultFailure that may occur unpredictably during the lifetime of a hardware element and that follows a probability distributionNOTE: Random hardware failure rates can be predicted with reasonable accuracy.Systematic faultFailure of an element or item that is caused in a deterministic way during development, manufacturing, or maintenanceNOTE Systematic failures can be prevented by applying design measures or production process changes on this element or item.
Introduction à la norme ISO 26262MAJ 07/03/2010 20/134
IV IV –– VocabularyVocabulary Part 1
Main terms …Faultabnormal condition that can cause an element or an item to fail
HazardPotential source of harm
FailureTermination of the ability of an element or an item to perform a function as required
ASIL decompositionApportioning of safety requirements redundantly to sufficiently independent elements with the objective of reducing the ASIL of the elements
Introduction à la norme ISO 26262MAJ 07/03/2010 21/134
V V –– Management ofManagement ofFunctional SafetyFunctional Safety
Part 2
Introduction à la norme ISO 26262MAJ 07/03/2010 22/134
V V –– Management ofManagement ofFunctional SafetyFunctional Safety
Part 2
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
Objectives
Introduction à la norme ISO 26262MAJ 07/03/2010 23/134
V V –– Management ofManagement ofFunctional SafetyFunctional Safety
Part 2
ASILcotation
Introduction à la norme ISO 26262MAJ 07/03/2010 24/134
Part 2V V –– Management ofManagement ofFunctional SafetyFunctional Safety
Introduction à la norme ISO 26262MAJ 07/03/2010 25/134
Part 2V V –– Management ofManagement ofFunctional SafetyFunctional Safety
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…)
Introduction à la norme ISO 26262MAJ 07/03/2010 26/134
Part 2V V –– Management ofManagement ofFunctional SafetyFunctional Safety
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 managero 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
Introduction à la norme ISO 26262MAJ 07/03/2010 27/134
Part 2V V –– Management ofManagement ofFunctional SafetyFunctional Safety
Planning for all safety management activities.Safety manager shall plan the activities, shall create a safety plan & safety planningThe safety plan shall either be:
a) a plan referenced in the overall project plan; orb) 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 Objectiveo Required work products from other activities, such as described in prerequisiteso Person in charge of safety activitieso Starting point in time and durationo Documentation of the respective work products
Requirements during developpement phase…
Introduction à la norme ISO 26262MAJ 07/03/2010 28/134
Requirements during developpement phase…
In developing the safety plan, the specific activities shall be tailored according to the ASIL and the constraints of the project
Part 2V V –– Management ofManagement ofFunctional SafetyFunctional Safety
Safety case (compiled progressively during the developmentphase)
The safety case shall be comprehensive and complete with regard to the work products defined in the safety plan
Introduction à la norme ISO 26262MAJ 07/03/2010 29/134
Part 2V V –– Management ofManagement ofFunctional SafetyFunctional Safety
Requirements during developpement phase…Confirmation measures for ensuring functional safety
Functional safety audit Confirmation review Functional safety assessment
Subject Implementation of the processes required for functional safety
Work product Item as described in the item definition (see ISO°26262-3, Clause°5)
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 compliance of the work product with the respective requirements of ISO°26262
Adequate evaluation of the achieved functional safety level
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 can be included in a functional safety assessment report
Introduction à la norme ISO 26262MAJ 07/03/2010 30/134
The confirmation measures shall be performed according to their ASIL and following table.
Part 2V V –– Management ofManagement ofFunctional SafetyFunctional Safety
Requirements during developpement phase…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)
- independent from the developers of the item
I3 For all ASILs, and including hazards rated as QM
applies to ASIL of the A B C D Confirmation review of the safety plan (see Clause 6) - independent from the developers of the item / project management
- I1 I2 I3 highest ASIL among safety goals of the item
Confirmation review of the integration and testing plan (see ISO°26262-4, Clause 5) -independent from the developers of the item / project management
I0 I1 I2 I2 highest ASIL among safety goals of the item
Confirmation review of the validation plan (see ISO°26262-4, Clause 5) -independent from the developers of the item / project management
I0 I1 I2 I2 highest ASIL among safety goals of the item
Confirmation review of the safety analyses (FMEA, FTA): (see ISO°26262-9, 8.4.8) I1 I1 I2 I3 highest ASIL among safety
goals of the item 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
- I0 I1 I1 highest ASIL among safety goals of the item
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
I0 I1 I2 I3
ASIL of the safety goal or requirement related to the considered behaviour, or function, of the candidate
Confirmation review of the completeness of the safety case (see 6.4.5) - independent from authors of safety case
I0 I1 I2 I3 highest ASIL among safety goals of the item
Audit of functional safety processes (see 6.4.6) - independent from the persons working in accordance with the processes required for functional safety
- I0 I2 I3 highest ASIL among safety goals of the item
Functional safety assessment (see 6.4.6.7) -independent from the supplier of the safety case - I0 I2 I3 highest ASIL among safety
goals of the item
Introduction à la norme ISO 26262MAJ 07/03/2010 31/134
Part 2V V –– Management ofManagement ofFunctional SafetyFunctional Safety
Requirements during developpement phase…
Safety assessment shall consider :o Confirmation plano Recommendations from the functionnal safety assessment, if availableo 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
Introduction à la norme ISO 26262MAJ 07/03/2010 32/134
Part 2V V –– Management ofManagement ofFunctional SafetyFunctional Safety
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.
Introduction à la norme ISO 26262MAJ 07/03/2010 33/134
Part 2V V –– Management ofManagement ofFunctional SafetyFunctional Safety
Interpretation of tablesTables 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.
Introduction à la norme ISO 26262MAJ 07/03/2010 34/134
Part 3VI VI –– Concept phaseConcept phase
Introduction à la norme ISO 26262MAJ 07/03/2010 35/134
Part 3VI VI –– Concept phaseConcept phase
The objective of this part is :o to define & describe the item o to develop an adequate understanding of itemo to select the applicable safety lifecycleo to identify and categorize the potentiel hazard of the itemo to formulate the safety goalso to define the preliminary architecture element
Objectives
Introduction à la norme ISO 26262MAJ 07/03/2010 36/134
Part 3VI VI –– Concept phaseConcept phase
Item definition
Information needed :o purpose and content of the itemo functional requirements of the itemo futher requirement for the item regarding the environmental conditions in which the item is usedo boundary of the itemo interfaces with other items o requirements from other itemso allocation & distribution of functions among the items involved
Introduction à la norme ISO 26262MAJ 07/03/2010 37/134
Part 3VI VI –– Concept phaseConcept phase
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 appliedo In case of a modification the relevant lifecycle sub-phases and activities shall be determined
Impact analysis & adapted safety lifecycleo In case of a modification of the item, an impact analysis shall be conducted to determine the areas affected by the modification
Introduction à la norme ISO 26262MAJ 07/03/2010 38/134
Part 3VI VI –– Concept phaseConcept phase
Hazard risk analysis
The hazard analysis and risk assessment sub-phase comprises threesteps :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
Introduction à la norme ISO 26262MAJ 07/03/2010 39/134
Part 3VI VI –– Concept phaseConcept phase
a) Situation analysis & hazard identification
The operational situations and operating modes in which an item'smalfunctioning behaviour is able to trigger hazards shall be described; both for cases when the item is correctly used and when it isincorrectly used in a foreseeable way.
A list of operational situations to be evaluated shall be preparedThe failure modes and hazards shall be detailedThe consequences of hazardous events shall be identified for
relevant operational situations and operating modes
Introduction à la norme ISO 26262MAJ 07/03/2010 40/134
Part 3VI VI –– Concept phaseConcept phase
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).
Introduction à la norme ISO 26262MAJ 07/03/2010 41/134
Part 3VI VI –– Concept phaseConcept phase
b) Hazard classification
Estimation of potential severityThe 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.
Introduction à la norme ISO 26262MAJ 07/03/2010 42/134
Part 3VI VI –– Concept phaseConcept phase
Examples of severity
categorisation
Class S0 S1 S2 S3
Description No injuries light and moderate injuries Severe injuries, possibly life-
threatening, survival probableLife-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)
more than 10% probability of AIS 3-6 (and not S3)
more than 10% probability of AIS 5-6
Informative examples -Pushing over roadside infrastructure, e.g. post or fence
-Light collision
-Light grazing damage
-Damage while entering or leaving a parking space
-Leaving the road without collision or rollover
-Side collision, e.g. crashing into a tree (impact to passenger cell) 15 < Δv
< 25 km/h
Δv
<15km/h 15 < Δv
<25 km/h Δv
>25 km/h
Side collision with a passenger car (impact to passenger cell)
Δ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
Pedestrian/bicycle accident E.g. during a turning manoeuvre inside built-up area
Outside built-up area
Introduction à la norme ISO 26262MAJ 07/03/2010 43/134
Part 3VI VI –– Concept phaseConcept phase
AIS : Abbreviated Injury Scale
Introduction à la norme ISO 26262MAJ 07/03/2010 44/134
Estimation of the probability of exposureThe 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
b) Hazard classification
Part 3VI VI –– Concept phaseConcept phase
The number of vehicles equipped with the item shall not be considered when estimating the probability of exposureThe hazard analysis and risk assessment is performed for individual vehicles equipped with the item
Class E0 E1 E2 E3 E4
Description incredible Very low probability
Low probability Medium probability
High probability
Introduction à la norme ISO 26262MAJ 07/03/2010 45/134
Part 3VI VI –– Concept phaseConcept phase
Class of probability
of exposure
regarding duration/probabilityof
exposure in driving
situations
Illustration •Class E1 E2 E3 E4
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
Informative examples
Highway –
lost cargo/obstacle on roadMountain pass –
driving down hill with the engine offJump startGarage –
vehicle on roller rig
Pulling a trailerDriving with roof rackDriving on a mountain pass with an unsecured steep slopeSnow and iceDriving backwardsFuellingOvertakingCar washCity driving –
driving
backwardsCity driving –
parking situationCountry road –
crossingCountry road –
snow and iceCountry road –
slippery/leavesHighway –
enteringHighway –
exitHighway –
approaching end of congestionParking –
sleeping person in the vehicleParking –
parking
with trailerGarage –
diagnosisGarage –
vehicle on auto lift
TunnelsHill holdNight driving on roads without streetlightsWet roadsCongestionCity driving –
one way streetHighway –
heavy traffic/stop and go
AcceleratingBrakingSteeringParkingDriving on highwaysDriving on secondary roadsCity driving –
changing laneCity driving –
stopping at traffic lightsCountry road –
free drivingHighway –
free drivingHighway –
changing laneParking –
parking
lot
Introduction à la norme ISO 26262MAJ 07/03/2010 46/134
Part 3VI VI –– Concept phaseConcept phase
Class of probability
of exposure
regarding duration/probabilityof
exposure in driving
situations
Illustration
Class E1 E2 E3 E4 Description Very low probability Low probability Medium probability High probability Definition of frequency Situations that occur
less often than once a year for the great majority of drivers
Situations that occur a few times a year for the great majority of drivers
Situations that occur once a month or more often for an average driver
All situations that occur during almost every drive on average
Informative examples Stop at railway crossing, which requires the engine to be restarted Towing Jump start
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
Introduction à la norme ISO 26262MAJ 07/03/2010 47/134
Part 3VI VI –– Concept phaseConcept phase
b) Hazard classification
Estimation of controllabilityThe 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.
Introduction à la norme ISO 26262MAJ 07/03/2010 48/134
Part 3VI VI –– Concept phaseConcept phase
Illustration
Examples of possibly controllable
hazards by the driver or by the
endangered individuals
Class C0 C1 C2 C3 Description Controllable in
general Simply controllable Normally controllable Difficult to control or
uncontrollable Definition Controllable in
general 99% or more of all drivers or other traffic participants are usually able to avoid a specific harm.
90% or more of all drivers or other traffic participants are usually able to avoid a specific harm.
Less than 90% of all drivers or other traffic participants are usually able, or barely able, to avoid a specific harm.
Informative examples
Unexpected increase in radio volume Situations that are considered distracting Unavailability of a driver assisting system
When starting the vehicle with a locked steering column, the car can be brought to stop by almost all drivers early enough to avoid a specific harm to persons nearby. Faulty adjustment of seats while driving can be controlled by almost all drivers by bringing the vehicle to a stop.
Driver can normally avoid departing from the lane in case of a failure of ABS during emergency braking. Driver is normally able to avoid departing from the lane in case of a motor failure at high lateral acceleration (motorway exit). Driver is normally able to bring the vehicle to a stop in case of a total lighting failure at medium or high speed on an unlighted country road without departing from the lane in an uncontrolled manner. Driver is normally able to avoid hitting an unlit vehicle on an unlit country road.
Wrong steering with high angular speed at medium or high vehicle speed can hardly be controlled by the driver. Driver normally cannot avoid departing from the lane on snow or ice on a bend in case of a failure of ABS during emergency braking. Driver normally cannot bring the vehicle to a stop if a total loss of braking performance occurs. In the case of faulty airbag release at high or moderate vehicle speed, the driver usually cannot prevent vehicle from departing from the lane.
Introduction à la norme ISO 26262MAJ 07/03/2010 49/134
c) ASIL classification
Part 3VI VI –– Concept phaseConcept phase
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 lowest safety level
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
Introduction à la norme ISO 26262MAJ 07/03/2010 50/134
Part 3VI VI –– Concept phaseConcept phase
c) ASIL classification
Accident z
Hazard
Controlability xExposure y
Accident wControlability uExposure v
Scenario 1
Scenario 2
ASIL A
ASIL B
ASIL = max (ASIL A, ASIL B)
Introduction à la norme ISO 26262MAJ 07/03/2010 51/134
acceptable
not acceptableRisk Reduction external to technical system: e.g. driver controls situation
Probability of exposition to driving situation where accident can potentially happen
Tolerable Risk
Reliability of system and
absence of systematic faultssafety class
(ASIL)
Lower than tolerable risk
ResidualRisk
Severity of possible accident
Probability per hour (runtime)
Extremeimprobable
Sometimes
Rarely
Very rarely
Always
Safetyclass
(ASIL)
Low (Catastrophically)Important Hazardous
ASIL level (A to D)
Severity
Introduction à la norme ISO 26262MAJ 07/03/2010 52/134
Evaluation of exposure in mutually exclusive operational situations
Part 3VI VI –– Concept phaseConcept phase
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
Introduction à la norme ISO 26262MAJ 07/03/2010 53/134
Part 3VI VI –– Concept phaseConcept phase
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”. ASIL D
Example 1
Introduction à la norme ISO 26262MAJ 07/03/2010 54/134
Part 3VI VI –– Concept phaseConcept phaseFunctional 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 requirementsTo 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.
Introduction à la norme ISO 26262MAJ 07/03/2010 55/134
Part 3VI VI –– Concept phaseConcept phase
Functional Safety Concept
If the functional safety requirements are allocated to elements of other technologies then the following shall apply:
the functional safety requirements implemented by othertechnologies shall be derived and allocated to the correspondingelements
the functional safety requirements relating to the interfaces withother technologies shall be specified
the implementation of functional safety requirements by othertechnologies shall be ensured through specific measures
Introduction à la norme ISO 26262MAJ 07/03/2010 56/134
SWBatt
LL, SW et Batt = Significant failures
Batt
SW L sensor, logic et warning = monitoring&
warning
sensor
Logic
Part 3VI VI –– Concept phaseConcept phase
Functional Safety Concept
Illustration
Introduction à la norme ISO 26262MAJ 07/03/2010 57/134
Part 9
Objectives
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.
Sub-phase
s of A
SIL
deco
mposit
ionan
d
critic
ality
analy
sis
ASIL ASIL decompositiondecompositionVI VI –– Concept phaseConcept phase
Introduction à la norme ISO 26262MAJ 07/03/2010 58/134
Part 9
GeneralStarting 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.
ASIL ASIL decompositiondecompositionVI VI –– Concept phaseConcept phase
Introduction à la norme ISO 26262MAJ 07/03/2010 59/134
Clas
sific
atio
n sc
hem
e of A
SILs
when
deco
mpo
sing
safe
ty re
quire
men
ts
ASIL ASIL decompositiondecompositionVI VI –– Concept phaseConcept phase Part 9
Introduction à la norme ISO 26262MAJ 07/03/2010 60/134
Part 9
ExampleASIL ASIL decompositiondecomposition
VI VI –– Concept phaseConcept phase
Item perimeter
Command to the door actuator
Opening request
Vehicle speed Vehicle speed
DSC control unit
Power Sliding Door Module Switch
Item perimeter
Command to the door actuator
Opening request
Vehicle speed Vehicle speed
DSC control unit
Power Sliding Door Module Switch
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).
Introduction à la norme ISO 26262MAJ 07/03/2010 61/134
Operational situation(s)
Scenario(s)+ S / E / C quotation → max (ASIL)
ASIL classification
Safety goal
Part 3VI VI –– Concept phaseConcept phase
Functional Safety
Requirement 1
Functional Safety
Requirement i…
Σ
FSR = Functional Safety Concept
To sum up this part…
Defined from safe state
ASIL decomposition
Verification of FSC
Introduction à la norme ISO 26262MAJ 07/03/2010 62/134
Part 4VII VII –– Product development : Product development : system system levellevel
Introduction à la norme ISO 26262MAJ 07/03/2010 63/134
Part 4VII VII –– Product development : Product development : system system levellevel
The objective of this part is :o to develop the technical safety concepto to design a system that fulfils the functional requirementso to verify the system design against the technical safety requirementso to check the integration and testingo to provide evidence that the safety related requirements are appropriate
Objectives
Introduction à la norme ISO 26262MAJ 07/03/2010 64/134
Part 4VII VII –– Product development : Product development : system system levellevel
Where are we in the STD ?
Introduction à la norme ISO 26262MAJ 07/03/2010 65/134
Part 4VII VII –– Product development : Product development : system system levellevel
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 with each possible operating mode and system stateo The technical safety concept shall specify functional, safety- related and/or other relevant dependencies between systems or elements
extract
Introduction à la norme ISO 26262MAJ 07/03/2010 66/134
Part 4VII VII –– Product development : Product development : system system levellevel
The ECU in charge of the Adaptive Cruise Control (ACC) switches off the ACC functionality when the brake system ECU reports that the Vehicle Stability Control functionality is unavailable.
Specification of technical safety concept
Example
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)
Introduction à la norme ISO 26262MAJ 07/03/2010 67/134
Part 4VII VII –– Product development : Product development : system system levellevel
System designThe 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
Introduction à la norme ISO 26262MAJ 07/03/2010 68/134
System design
Part 4VII VII –– Product development : Product development : system system levellevel
Avoidance of systematic faults : o Measures for avoidance of systematic faults shall be specifiedo Deductive and inductive analysis dedicated to causes and effects of systematic failures shall be applied according to following table
MethodsASIL
A B C D
1 Deductive analysisa o + ++ ++
2 Inductive analysisb ++ ++ ++ ++
a
Deductive analysis methods include FTA, reliability block diagrams.b
Inductive analysis methods include FMEA, ETA, Markov modelling.
Introduction à la norme ISO 26262MAJ 07/03/2010 69/134
Part 4VII VII –– Product development : Product development : system system levellevel
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.
Introduction à la norme ISO 26262MAJ 07/03/2010 70/134
Part 4VII VII –– Product development : Product development : system system levellevel
System design
Measures for control of random hardware failures duringoperation . 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.
Introduction à la norme ISO 26262MAJ 07/03/2010 71/134
Part 4VII VII –– Product development : Product development : system system levellevel
System design
Verification and system design :
MethodsASIL
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.
Introduction à la norme ISO 26262MAJ 07/03/2010 72/134
Part 4VII VII –– Product development : Product development : system system levellevel
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
Introduction à la norme ISO 26262MAJ 07/03/2010 73/134
Part 4VII VII –– Product development : Product development : system system levellevel
Item integration & testing
Table 3- Methods for deriving test cases for item integration testing
MethodsASIL
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 + ++ ++ ++
Introduction à la norme ISO 26262MAJ 07/03/2010 74/134
Part 4VII VII –– Product development : Product development : system system levellevel
Item integration & testing
Table 4 — Correctness of implementation of system design specification and technical safety requirements
MethodsASIL
A B C D
1a Requirements-based testa ++ ++ ++ ++
1b Fault injection testb + ++ ++ ++
1c Back-to-back testc + + ++ ++
a
A requirements-based test denotes a test against functional and non-functional requirements.b
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.
Introduction à la norme ISO 26262MAJ 07/03/2010 75/134
Part 4VII VII –– Product development : Product development : system system levellevel
Item integration & testing
Table 5-Correctness of functional performance of safety mechanisms
MethodsASIL
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.
MethodsASIL
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 I2C-
communications or any other interface between elements of an ECU.
Table 6-Consistency and correctness of implementation of external and internal interfaces
Introduction à la norme ISO 26262MAJ 07/03/2010 76/134
Part 4VII VII –– Product development : Product development : system system levellevel
Item integration & testing
Table 7 — Effectiveness of diagnostic coverage of hardware fault detection mechanisms
MethodsASIL
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.
MethodsASIL
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.
Table 8 — Level of robustness
Introduction à la norme ISO 26262MAJ 07/03/2010 77/134
Part 4VII VII –– Product development : Product development : system system levellevel
Item integration & testing
Table 11 — Consistency and correctness of implementation of external and internal interfaces
MethodsASIL
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.
Introduction à la norme ISO 26262MAJ 07/03/2010 78/134
Part 4VII VII –– Product development : Product development : system system levellevel
Item integration & testing
Table 12 — Effectiveness of diagnostic failure coverage of safety mechanisms at item level
Test methods ASIL
A B C D
1a Fault injection testa + + ++ ++
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.
Introduction à la norme ISO 26262MAJ 07/03/2010 79/134
Part 4VII VII –– Product development : Product development : system system levellevel
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.
Introduction à la norme ISO 26262MAJ 07/03/2010 80/134
Part 4VII VII –– Product development : Product development : system system levellevel
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 influenceso 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.
Safety validation
Introduction à la norme ISO 26262MAJ 07/03/2010 81/134
Part 4VII VII –– Product development : Product development : system system levellevel
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
Introduction à la norme ISO 26262MAJ 07/03/2010 82/134
Part 4VII VII –– Product development : Product development : system system levellevel
Example of an agenda
for an assessment of
functional safety for
ASIL D
Introduction à la norme ISO 26262MAJ 07/03/2010 83/134
Part 4VII VII –– Product development : Product development : system system levellevel
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.
Introduction à la norme ISO 26262MAJ 07/03/2010 84/134
Operational situation(s)
Scenario(s)+ S / E / C quotation → max (ASIL)
ASIL classification
Safety goal
Functional Safety
Requirement 1
Functional Safety
Requirement i…
Σ
FSR = Functional Safety Concept
To sum up this part…
Technical SafetyRequirement 1
Technical SafetyRequirement i
…Σ
TSR = Technical Safety Concept
Defined from safe state
ASIL decomposition
Part 4VII VII –– Product development : Product development : system system levellevel
Introduction à la norme ISO 26262MAJ 07/03/2010 85/134
Part 5VIII VIII –– Product development : Product development : hardware hardware levellevel
Introduction à la norme ISO 26262MAJ 07/03/2010 86/134
Part 5VIII VIII –– Product development : Product development : hardware hardware levellevel
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.
Objectives
Introduction à la norme ISO 26262MAJ 07/03/2010 87/134
Part 5VIII VIII –– Product development : Product development : hardware hardware levellevel
Initiation of product development
Informative reference
phase model for
development of a
safety-related item
Introduction à la norme ISO 26262MAJ 07/03/2010 88/134
Part 5VIII VIII –– Product development : Product development : hardware hardware levellevel
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
Introduction à la norme ISO 26262MAJ 07/03/2010 89/134
Part 5VIII VIII –– Product development : Product development : hardware hardware levellevel
Specification of hardware safety requirements
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
o The hardware safety requirements of safety mechanisms dedicated to control internal failures of the hardware of the item or element, with their relevant attributes
o The hardware safety requirements of safety mechanisms 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
Introduction à la norme ISO 26262MAJ 07/03/2010 90/134
Part 5VIII VIII –– Product development : Product development : hardware hardware levellevel
Specification of hardware safety requirements
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
Introduction à la norme ISO 26262MAJ 07/03/2010 91/134
Part 5VIII VIII –– Product development : Product development : hardware hardware levellevel
Specification of hardware safety requirements
Verification of the hardware safety requirements
MethodsASIL
A B C D
1a Walkthrough of hardware safety requirements ++ + o o
1b Inspection of hardware safety requirements + ++ ++ ++
Introduction à la norme ISO 26262MAJ 07/03/2010 92/134
Part 5VIII VIII –– Product development : Product development : hardware hardware levellevel
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.
Introduction à la norme ISO 26262MAJ 07/03/2010 93/134
Part 5VIII VIII –– Product development : Product development : hardware hardware levellevel
Hardware designo 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.
Introduction à la norme ISO 26262MAJ 07/03/2010 94/134
Part 5VIII VIII –– Product development : Product development : hardware hardware levellevel
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 faultso Single point faults or residual faultso Dual point faults (either perceived, detected or latent)
Introduction à la norme ISO 26262MAJ 07/03/2010 95/134
Part 5VIII VIII –– Product development : Product development : hardware hardware levellevel
Verification of hardware design
ASIL Methods
A B C D
1a Hardware design inspectiona + + ++ ++
1b Hardware design walkthrough a ++ ++ o o
2 Safety analyses See 7.4.3
3a Emulation by simulationb o + + +
3b Development by prototype hardware o + + + 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.
Introduction à la norme ISO 26262MAJ 07/03/2010 96/134
Part 5VIII VIII –– Product development : Product development : hardware hardware levellevel
Hardware architectural metric
Single Point
«
Safety
»
failure
Failure
with
safety mechanism
(included
covered
rate)
+< N%
ASIL C : N= 3%ASIL D : N=1%
Introduction à la norme ISO 26262MAJ 07/03/2010 97/134
Part 5VIII VIII –– Product development : Product development : hardware hardware levellevel
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”.
Introduction à la norme ISO 26262MAJ 07/03/2010 98/134
Part 5VIII VIII –– Product development : Product development : hardware hardware levellevel
Assessment criteria for probability of violation of safety goalsTwo 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.
Introduction à la norme ISO 26262MAJ 07/03/2010 99/134
Part 5VIII VIII –– Product development : Product development : hardware hardware levellevel
For first alternative method
• Table G.1 — Random hardware failure target values
ASIL LevelRandom hardware failure target values
D < 10-8 h-1
C < 10-7 h-1
B < 10-7 h-1
A < 10-6 h-1
Introduction à la norme ISO 26262MAJ 07/03/2010 100/134
Part 5VIII VIII –– Product development : Product development : hardware hardware levellevel
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.
Assessment criteria for probability of violation of safety goals
For second alternative method
Single point fault?or residual fault?
Meet occurrence target and diagnostic coverage of safety mechanisms with regard to
single point or residual fault (table 5)
Meet occurrence target and diagnostic coverage of safety mechanisms with regard to
single point or residual fault (table 5)
Add or improve safety mechanisms to mitigate
fault
Redesign
Begin
Yes
YesNo
Yes
End
No
NoSingle point fault?or residual fault?
Meet occurrence target and diagnostic coverage of safety mechanisms with regard to
single point or residual fault (table 5)
Meet occurrence target and diagnostic coverage of safety mechanisms with regard to
single point or residual fault (table 5)
Add or improve safety mechanisms to mitigate
fault
Redesign
Begin
Yes
YesNo
Yes
End
No
No
Introduction à la norme ISO 26262MAJ 07/03/2010 101/134
Part 5VIII VIII –– Product development : Product development : hardware hardware levellevel
Assessment criteria for probability of violation of safety goals
Table 5 — Targets of failure rate class and coverage of hardware part regarding residual faults
Diagnostic Coverage wrt. residual faults
>= 99
% >= 90
% < 90
%
ASIL of Safety Goal
D Failure rate class 3++
Failure rate class 2++
Failure rate class 1 + dedicated measuresa
++
C o Failure rate class 3++
Failure rate class 2 + dedicated measuresa
++
B o Failure rate class 3+
Failure rate class 2+
a The note in requirement 9.4.3.4 gives examples of dedicated measures
Introduction à la norme ISO 26262MAJ 07/03/2010 102/134
Part 5VIII VIII –– Product development : Product development : hardware hardware levellevel
Assessment criteria for probability of violation of safety goalsEach 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.
Independent faults?(common-cause analysis)
Plausible dual point failure?
Meet occurrence target and diagnostic coverage of safety mechanisms with regard to
multiple point fault (table 6)
Plausible dual point failure?
Meet occurrence target and diagnostic coverage of safety mechanisms with regard to
multiple point fault (table 6)
Add or improve safety mechanisms to eliminate or mitigate latent fault
Assessment procedure for single point fault
Redesign
Begin
Yes
Yes
Yes
Yes
Yes
No
No
No
No
End
No
No
Independent faults?(common-cause analysis)
Plausible dual point failure?
Meet occurrence target and diagnostic coverage of safety mechanisms with regard to
multiple point fault (table 6)
Plausible dual point failure?
Meet occurrence target and diagnostic coverage of safety mechanisms with regard to
multiple point fault (table 6)
Add or improve safety mechanisms to eliminate or mitigate latent fault
Assessment procedure for single point fault
Redesign
Begin
Yes
Yes
Yes
Yes
Yes
No
No
No
No
End
No
Independent faults?(common-cause analysis)
Plausible dual point failure?
Meet occurrence target and diagnostic coverage of safety mechanisms with regard to
multiple point fault (table 6)
Plausible dual point failure?
Meet occurrence target and diagnostic coverage of safety mechanisms with regard to
multiple point fault (table 6)
Add or improve safety mechanisms to eliminate or mitigate latent fault
Assessment procedure for single point fault
Redesign
Begin
Yes
Yes
Yes
Yes
Yes
No
No
No
No
End
No
No
Introduction à la norme ISO 26262MAJ 07/03/2010 103/134
Part 5VIII VIII –– Product development : Product development : hardware hardware levellevel
Assessment criteria for probability of violation of safety goals
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
%
ASIL of Safety Goal
D o Failure rate class 3++
Failure rate class 2++
C o o Failure rate class 3++
Introduction à la norme ISO 26262MAJ 07/03/2010 104/134
Part 5VIII VIII –– Product development : Product development : hardware hardware levellevel
Assessment criteria for probability of violation of safety goals
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;The failure rate corresponding to failure rate class 2 shall be less than ten times the failure rate corresponding to failure rate class 1;The failure rate corresponding to failure rate class 3 shall be less than a hundred times the failure rate corresponding to failure rate class 1.
Introduction à la norme ISO 26262MAJ 07/03/2010 105/134
Part 5VIII VIII –– Product development : Product development : hardware hardware levellevel
Evaluation of the diagnostic coverage
Generic hardware of an E/E systemSensor
Sensor
D.11
D.11
D.2 E/E System
D.2 E/E System
D.4Processing Unit
D.7 DigitalI.
D.7 Analogue I.
D.6 RAM
D.5 ROM
D.8 Serialbusinterface
D.10 Clock
D.9 Power Supply
D.3 Relay
D.7 Analogue OD.12
Actuator
D.12ActuatorD.7 Digital O.
D.12Actuator
Con -D.3
nector
D.3Con -nector
Con -nector
Con -nector
Con -nector
Diagnostic technique/measure
See overview of techniques
Maximum diagnostic coverage considered
achievableNotes
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 Depends on diagnostic coverage
of failure detection
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 Depends of the quality of the self test
Table D.2 — Systems
Introduction à la norme ISO 26262MAJ 07/03/2010 106/134
Hardware integration & testing
Part 5VIII VIII –– Product development : Product development : hardware hardware levellevel
Objectives of this sub-phase are to ensure the compliance of the developed hardware with the hardware safety requirements
MethodsASIL
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
In order to efficiently derive the necessary test cases, analysis of similarities can be conducted.b
EXAMPLE values approaching and crossing the boundaries between specified values and out of range valuesc
“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.d
Existing standards can be ISO 16750 and ISO 11452.e
The analysis of significant variants includes worst case analysis.
Introduction à la norme ISO 26262MAJ 07/03/2010 107/134
Part 6IX IX –– Product development : Product development : software software levellevel
Introduction à la norme ISO 26262MAJ 07/03/2010 108/134
Part 6IX IX –– Product development : Product development : software software levellevel
The objective of this part is :o to provide a consistent software requirement specificationso to design & analyse the software o to evaluate the software architecture of the itemo to check the integration and testing
Objectives
Introduction à la norme ISO 26262MAJ 07/03/2010 109/134
Part 6IX IX –– Product development : Product development : software software levellevel
Initiation of product development
Introduction à la norme ISO 26262MAJ 07/03/2010 110/134
Part 6IX IX –– Product development : Product development : software software levellevel
Specification of software safety requirementsThe 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.
MethodsASIL
A B C D
1a Informal verification by walkthrough +
++ o o
1b Informal verification by inspection + +
++
++
+
1c Semi-formal verificationa + + +
++
+
1d Formal verification o + + +
a
Method 1c can be supported by executable models.
Table 2 — Methods for the verification of requirements
Introduction à la norme ISO 26262MAJ 07/03/2010 111/134
Part 6IX IX –– Product development : Product development : software software levellevel
Software architectural designThe software architectural design shall exhibit the following
properties by use of the principles listed in Table 4:modularity;encapsulation and;minimum complexity.
Table 4 — Principles for software architectural design
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 + + + ++
a
In methods 1b, 1c, 1e and 1g "restricted" means to minimise in balance with other design considerations.b
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.
Introduction à la norme ISO 26262MAJ 07/03/2010 112/134
Part 6IX IX –– Product development : Product development : software software levellevel
Software integration and testing
Table 15 — Methods for software integration testing
MethodsASIL
A B C D
1a Requirements-based test ++ ++ ++ ++
1b External interface test ++ ++ ++ ++
1c Fault injection testa + + ++ ++
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.
Introduction à la norme ISO 26262MAJ 07/03/2010 113/134
Part 7X X –– Product & Product & operationoperation
Introduction à la norme ISO 26262MAJ 07/03/2010 114/134
Part 7X X –– Product & Product & operationoperation
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 relevantproduct manufacturer or the person or organisation in charge of the process (vehicle manufacturer, supplier, sub-supplier etc.).
Introduction à la norme ISO 26262MAJ 07/03/2010 115/134
Part 7X X –– Product & Product & operationoperation
Information required
Production planningControl plan (the tests description and criteria for safety-relatedsystems, focus on the systematic faults…)Process failures and their potential effects on functional safety
shall be analysed and the appropriate measures shall beimplementedThe lessons on the capability, learnt from previously released
production plansTools and test equipment concerning the safety-related special characteristicsThe competence of the personnel
Introduction à la norme ISO 26262MAJ 07/03/2010 116/134
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
Part 7X X –– Product & Product & operationoperation
Introduction à la norme ISO 26262MAJ 07/03/2010 117/134
Part 8XI XI –– SupportingSupporting processesprocesses
Introduction à la norme ISO 26262MAJ 07/03/2010 118/134
Part 8XI XI –– SupportingSupporting processesprocesses
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 developmentso Specification and management of safety requirementso Configuration managemento Change managemento Verificationo Documentationo Qualification of software toolso Qualification of software componentso Qualification of hardware componentso Proven in use argument
Introduction à la norme ISO 26262MAJ 07/03/2010 119/134
Part 8XI XI –– SupportingSupporting processesprocesses
Interfaces within distributed developments
Supplier selection criteria :o Verification of the supplier's quality management systemo Consideration of the supplier's experience in developing products of comparable complexity and ASILo The supplier's capability in developing products of comparable complexity
The customer and the supplier shall specify a Development Interface Agreement (DIA)
Introduction à la norme ISO 26262MAJ 07/03/2010 120/134
Part 8XI XI –– SupportingSupporting processesprocesses
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 safetyDuring 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 hereinafterIn order to support the management of safety requirements, the use of suitable tools for requirements management is recommended
Introduction à la norme ISO 26262MAJ 07/03/2010 121/134
Part 8XI XI –– SupportingSupporting processesprocesses
Overall management of safety requirements
Structuring of safety requirements
Introduction à la norme ISO 26262MAJ 07/03/2010 122/134
Part 8XI XI –– SupportingSupporting processesprocesses
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.
Introduction à la norme ISO 26262MAJ 07/03/2010 123/134
Part 8XI XI –– SupportingSupporting processesprocesses
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
Introduction à la norme ISO 26262MAJ 07/03/2010 124/134
Part 8XI XI –– SupportingSupporting processesprocesses
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 phaseand subphase of the safety lifecycle
The specification of verification shall specify and select the methods to be used for the verification
Introduction à la norme ISO 26262MAJ 07/03/2010 125/134
Part 8XI XI –– SupportingSupporting processesprocesses
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.
Introduction à la norme ISO 26262MAJ 07/03/2010 126/134
Part 8XI XI –– SupportingSupporting processesprocessesQualification of software tools
The objective of the qualification of software tools is to provide evidence of software tool suitability for use when developing a safety- related 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)
Introduction à la norme ISO 26262MAJ 07/03/2010 127/134
Part 8XI XI –– SupportingSupporting processesprocessesQualification 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
Table 2 — Qualification of software tools classified TCL4
MethodsASIL
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 + + ++ ++
a
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.
Introduction à la norme ISO 26262MAJ 07/03/2010 128/134
Part 8XI XI –– SupportingSupporting processesprocessesQualification of software componentsFirst 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.
Introduction à la norme ISO 26262MAJ 07/03/2010 129/134
Part 8XI XI –– SupportingSupporting processesprocesses
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.
Introduction à la norme ISO 26262MAJ 07/03/2010 130/134
Part 8XI XI –– SupportingSupporting processesprocessesQualification of hardware components
Table 5 — Qualification, integration and test activities to be conducted depending on the level of HW part or component
Basic HW partIntermediate HW part Intermediate HW
componentComplex HW component
No contribution to a safety
requirement
Contributio
n to a safety
requiremen
t
No contribution to
a safety requirement
Contribution to a safety
requirement
No contribution to
a safety requirement
Contribution to a safety
requirement
A safety requirement is fully implemented
by the HW component
(resistors, transistors…) (HS CAN transceiver)
(gray code decoder)
(fuel pressure sensor)
(ECU)
Standard qualification
Qualification in accordance with ISO26262-8:—, Clause 13
Integration/test in accordance with ISO26262-
5:—* *
Integration/test in accordance with ISO26262-
4:—
* 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".
Introduction à la norme ISO 26262MAJ 07/03/2010 131/134
Part 8XI XI –– SupportingSupporting processesprocesses
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
Targets for minimum service period of candidate
Per safety goal
ASIL Observable incident rate
D < 10-9/h
C < 10-8/h
B < 10-8/h
A < 10-7/h
ASILMinimum 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
Introduction à la norme ISO 26262MAJ 07/03/2010 132/134
Part 8XI XI –– SupportingSupporting processesprocesses
Proven in use argumentFor 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 Observable incident rate
D < 3 ∙
10-9/h
C < 3 ∙
10-8/h
B < 3 ∙
10-8/h
A < 3 ∙
10-7/h
Introduction à la norme ISO 26262MAJ 07/03/2010 133/134
Part 9
General
Part 8XII XII –– ASIL ASIL orientedoriented and and safetysafety analysisanalysis
CriteriaCriteria for coexistence of for coexistence of elementelement
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 sub- elements 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.
Introduction à la norme ISO 26262MAJ 07/03/2010 134/134
Description of system or function and it’s boundaries
System Definition
Implementation of a Automotive Implementation of a Automotive Safety ProcessSafety Process
Man
agem
ent P
roce
sses
e.g.
Pla
nnin
g, Q
ualif
icat
ion,
Def
. of R
espo
nsib
ilitie
s,
Supp
ortin
g Pr
oces
ses
e.g.
Con
figur
atio
n M
anag
emen
t, D
ocum
enta
tion,
Collection of driving situations
Safety Class:(e.g. ASIL D)
Protection goals(e.g. no de-stabilization)
Malfunction of technical system
Hazard Analysis and Risk
Classification
Safety function (What)(e.g. do not send
wrong signal)
Safety integrity requirement (How good)
- e.g. <10-x dang. failures/h (HW)Safety
Requirements
Verification &Validation
Safety AnalysisFMEA, FTA, Markoff, ...
Design and ImplementationRealization
Safety Case