IEC 61508: UNDERSTANDING THE STANDARD AND ITS PLACE IN SAFETY ENGINEERING AND MANAGEMENT Felix...

IEC 61508:UNDERSTANDING THE STANDARD

AND ITS PLACE INSAFETY ENGINEERING AND

MANAGEMENT

Felix RedmillRedmill Consultancy, London

[email protected]

TOPICS COVERED

• Background to the standard• What the standard is and what its aims are• Structure of the standard• Vocabulary and definitions• The safety lifecycle• Hazard and risk analysis• Safety integrity levels (SILs)• Safety requirements• Safety planning• The standard's requirements for

documentation• Claiming conformance to the standard• The standard's requirements on

management• Independent safety assessment• Benefits and limitations

(c) Felix Redmill, 2011 2CERN, May '11

RANDOM AND SYSTEMATIC FAILURES

• Random hardware failure [4: 3.6.5]

Failure, occurring at a random time, that results from one or more of the possible degradation mechanisms in the hardware

• Systematic failure [4: 3.6.6]

Failure, related in a deterministic way to a certain cause, that can only be eliminated by a modification of the design or of the manufacturing process, operational procedures, documentation or other relevant factors


BACKGROUND TO IEC 61508

• Middle-to-late 1980s: Work on safety-related systems in the International Electrotechnical Committee, SC 65A WG9 (Software) and WG10 (Systems)

• November 1991: Publication of ‘Software for Computers in the Application of Industrial Safety-related Systems’IEC SC 65A WG9 Draft Document

• January 1992: Publication of ‘Functional Safety of Electrical/Electronic/Programmable Electronic Systems; General Aspects: Part 1, General Requirements’IEC SC 65A WG10 Draft Document


BACKGROUND TO IEC 61508 – Contd.

• June 1995: Publication of ‘IEC 1508 — Functional Safety: safety-related systems’ in 7 partsPrepared by Working Groups 9 and 10 of SC 65A’

• December 1997: Publication of 'IEC 61508: Functional safety of electrical/electronic/programmable electronic safety-related systems'Prepared by sub-committee 65A: System aspects

• 1998 - 2000: All seven parts voted to status of standard

• 2010: Publication of Edition 2, after several years of “maintenance”


THE 7 PARTS OF THE STANDARD

1 General requirements (Normative, except Annexes)

2 Requirements for electrical/electronic/programmable electronic safety-related systems (Normative)

3 Software requirements (Normative)

4 Definitions and abbreviations (Normative)

5 Examples of methods for the determination of safety integrity levels (Informative)

6 Guidelines on the application of Parts 2 and 3 (Informative)

7 Overview of techniques and measures (Informative)

• In total, more than 400 pages


WHAT LIES BEHIND THE STANDARD

• We require confidence of safety in advance, not retrospectively

• We must not only achieve safety but also demonstrate it

• Absolute safety (zero risk) cannot be achieved

– So, we must make decisions on what risk is tolerable

• Dispel the belief that ‘if we do it well it will be safe’

• Correct functionality safety

• Therefore: see next slide(c) Felix Redmill, 2011 7CERN, May '11

WHAT LIES BEHIND THE STANDARD - 2

We must:

• Understand the risks posed by our systems (plant, processes and products)

• Reduce risks that are not tolerable

• Specify safety requirements as well as (and independently of) functional requirements

• Implement the safety requirements, and be confident that residual risks are tolerable

• Employ independent safety assessment


APPLICATION OF IEC 61508

EUC

Control system

Protection system

Safety functionsSafety functions

Utility + risks

• There is equipment under control (EUC) which, with its control system, poses risks to its surroundings

• The risks will be reduced to tolerable levels by safety functions

• Safety functions are performed by E/E/PE systems(c) Felix Redmill, 2011 9CERN, May '11

SCOPE OF IEC 61508

• The EUC and its control system have

– Functional requirements, concerning what they must do

– Non-functional requirements, such as power consumption

– Safety requirements, to reduce risk

• IEC 61508 addresses the safety requirements

– In all lifecycle stages, from concept to decommissioning

– Their provision in E/E/PE systems(c) Felix Redmill, 2011 10CERN, May '11

MEETING THE INTENT1 — Understanding the Risk

The standard requires• Identification and analysis of the risks posed by the

EUC• Decisions on what levels of risk are tolerable• Decisions on which risks should be reduced, and by

how much

Tolerable risk

EUCrisk

Increasing riskNecessary risk reduction


MEETING THE INTENT2 — Safety-related systems

Residual risk

Tolerable risk

EUCrisk

Increasing risk

Necessary risk reduction

Actual risk reduction

Part of risk covered by other tech.

systems

Part of risk covered by

E/E/PE systems

Part of risk covered by external facilities

• Risk reduction may be achieved by various means

• This standard gives guidance on E/E/PE systems

(There may be numerous hazards)


MANY RISKS

Tolerable level of risk 1

Risk1

Increasing riskNecessary reduction of risk 1

Actual reduction of risk 1

Residualrisk 1

Tolerable level of risk 2

Risk 2


MEETING THE INTENT3 — Principles Involved

• The safety lifecycle is a model for identifying the activities appropriate to safety-related systems, and it facilitates safety planning

• A risk-based approach means not merely following a procedure and assuming that safety will result, but:

– Identifying the risks and reducing them appropriately

• Safety integrity levels (SILs) provide targets for risk reduction

• The safety requirements specification defines the safety requirements necessary for risk reduction (for all EUC risks)


MEETING THE INTENT3 — Principles Involved (Contd.)

• Carrying out safety planning is essential to a methodical and auditable approach

• Safety assessment checks for appropriateness and adequacy at all stages

• Safety management is essential throughout the entire life of a system

• The safety case is not mentioned in the standard


VOCABULARY AND DEFINITIONS — 1

• Harm [4: 3.1.1]: Physical injury or damage to the health of people or damage to property or the environment

• Risk [4: 3.1.6]: combination of the probability of occurrence of harm and the severity of that harm

• Hazard [4: 3.1.2]: potential source of harm

• Hazardous event [3.1.4]: Event that may result in harm

• Safety [4: 3.1.11]: freedom from unacceptable risk

• Tolerable risk [4: 3.1.7]: risk which is accepted in a given context based on the current values of society

• Equipment under control (EUC) [4: 3.2.1] equipment, machinery, apparatus or plant used for manufacturing, process, transportation, medical or other activities


VOCABULARY AND DEFINITIONS — 2

• Safety-related system [4: 3.4.1]: designated system that:–Implements the required safety functions necessary to achieve or maintain a safe state for the EUC; and–Is intended to achieve, on its own or with other safety-related systems and other risk reduction facilities, the necessary safety integrity for the required safety functions

• Safety function [4: 3.5.1]: function ... intended to achieve or maintain a safe state for the EUC, in respect of a specific hazardous event

• Safety integrity [4: 3.5.4]: probability of a safety-related system satisfactorily performing the specified safety functions under all the stated conditions within a stated period of time


STRUCTURE OF PARTS 1, 2 AND 3

Clause 1Scope - individual to each of the 3 partsClause 2Normative ReferencesClause 3Definitions and Abbreviations - all refer to Part 4Clause 4Conformance to this Standard - 2 and 3 refer to 1Clause 5Documentation - 2 and 3 refer to 1Clause 6Management of Functional Safety

Part 1: Contains the requirementsParts 2 and 3 refers to Part 1 and Part 3

adds ‘software configuration management’

Clause 7Safety Lifecycle RequirementsPart 1: OverallPart 2: E/E/PE systemsPart 3: Software

Clause 8Functional Safety Assessment - 2 and 3 refer to 1(c) Felix Redmill, 2011 18CERN, May '11

Technical requirements

PART 1: 7.1 to 7.5Development of overall

safety requirements for all safety-related systems,

and facilities

PART 1: 7.6Allocation of safety

requirements to safety-related systems and facilities

PART 2Realisation of E/E/PE

safety-related

systems

PART 3Realisation of safety-

related

PART 1: 7.13 & 7.14Installation and

commissioning and safety validation of E/E/PE

safety-related systems

PART 1: 7.15 to 7.17Operation & maintenance, modification & retrofit,

decommissioning & disposal of E/E/PE safety-

related systems

PART 5Informative guidance on

safety integrity requirements development

PART 7Overview of techniques

and measures

PART 6Guidelines for the

application of Parts 2 and 3

Other requirements

PART 4Definitions and abbreviations

PART 1:5 & Annex ADocumentation

PART 1: 6Management of

functional safety

PART 1: 8Functional safety

assessment

STRUCTURE OF IEC 61508[Figure 1 (Overall framework)]


TECHNICAL PRINCIPLES

CERN, May '11 21

MAIN TECHNICAL PRINCIPLES OF IEC 61508

• The safety lifecycle: a model for structuring safety management activities throughout the life cycle of safety-related systems

• A risk-based approach: basing safety-management activities on an understanding of the risks involved

• Safety integrity levels (SILs): provide targets for risk reduction

• Safety requirements: specified independently of functional requirements

• Safety planning: ensures a methodical and auditable approach

• Safety assessment: independent (third-party) check of safety (but the standard does not address the safety case)

(c) Felix Redmill, 2011

Overallmodificationand retrofit

1 Concept

2Overall scope

definition

3Hazard and risk

analysis

Overall safety requirements

Safety requirements allocation

4

5

6O & M

7Safety

validation

8Installation & commissioning

Overall planning of:

9Safety-related E/E/PES

10Other tech.

safety-related systems

11External

risk reduction facilities

Realisation of:

12Overall installation and commissioning

13Overall safety

validation

14Overall operation,

maintenance & repair

16Decommissioning or

disposal

15

OVERALL SAFETY LIFECYCLE


THE SAFETY LIFECYCLE

• Necessary activities involved in the implementation of safety-related systems, occurring during a period of time that starts at the concept phase of a project and finishes when all of the E/E/PE safety-related systems and other risk reduction measures are no longer available for use [4: 3.7.1]

• Models the whole life of a safety-related system, from conception to decommissioning

• Recognises that the safety features are seldom met by a single design in a single technology

• Addresses only the safety activities• In parallel with ‘functional’ development or system

lifecycle models in use(c) Felix Redmill, 2011 23CERN, May '11

LIFECYCLE PHASES

1 ConceptTo understand the equipment under control (EUC) and its environment (physical, social, political, legislative, etc.) sufficient for performing the other safety life cycle activities

Examples of questions to be asked:• What are the system-level hazards?• What legislation applies?• Is the system subject to political controversy?• What is public perception of the likely risks?• Is location affected by the risks?


LIFECYCLE PHASES

2 Overall scope definitionTo determine the boundary of the EUC and its control system and the scope of the hazard and risk analyses to be carried out

Examples of questions to be asked:• What are the physical and logical boundaries of

the EUC?• Is manual operation involved in control?• What policy and management decisions will affect

operation and control?• Who and what are, or might be, affected by the

risks posed?(c) Felix Redmill, 2011 25CERN, May '11

LIFECYCLE PHASES

3 Hazard and risk analysisTo identify the hazards of the EUC in all modes of operation, the event sequences leading to the hazards, and the EUC risks associated with the hazards (continuous through system life)[Hazard ID Hazard analysis Risk assessment]

Examples of questions to be asked:• What hazards does the system pose?• What are their possible causes and consequences?• What is the likelihood of their occurrence?• What are the risks associated with each of the

hazards?• Which risks should be reduced, and by how much?(c) Felix Redmill, 2011 26CERN, May '11

THE LIFECYCLE PHASES

4 Overall safety requirements

To develop the overall safety requirements specification

• What risks are to be reduced?

• Specify requirements for risk reduction

• Perhaps specify safety functions for specific risk reduction

• Define safety integrity levels as well as functional reqs.

• Requirements may specified in stages, with ‘high-level’ (e.g. “this risk must be reduced”) reqs. first and safety functions being defined later



5 Safety requirements allocation

To carry out a safety design in which it is determined how each of the safety requirements is to be met. (A combination of E/E/PE

systems and other risk-reduction measures may be employed.)

This phase ends in an overall design, which is then interpreted, in Phases 9, 10 and 11, into detailed designs for development

Example tasks:

• Design safety functions to satisfy safety requirements

• Derive the safety integrity level of each safety function

• Allocate safety functions to safety-related systems

• Derive the safety integrity levels of the proposed systems

• Iterate until high-level safety requirement allocation is 'optimum'



6 Overall operation and maintenance planning

To develop an operation and maintenance plan to ensure that the functional safety of the system is maintained during the operational phase

• Implementation may depend on the adequacy of an organisation’s Safety Management System



7 Overall validation planning

To develop a safety validation specification which defines how all the requirements in the safety requirements specification are to be validated

• IEC 61508 defines this as being for E/E/PE safety-related systems only

– But this is ‘overall’ validation planning, so the same principles should apply to all means of implementation of risk-reduction measures



8 Overall installation and commissioning planning

To plan how the safety features will be installed

and how their commissioning (including

acceptance testing) will be carried out

• What competences will be required?

• What evidence will be required for safety

assessment, and for inclusion in the safety case?



9, 10, 11 Realisation

To carry out the development of the defined safety functions

• The safety requirements are not necessarily met in a single technology

• Means other than E/E/PE are not, formally, the subject of IEC 61508

• For E/E/PE systems:– Part 2 gives guidance on system realisation– Part 3 gives guidance on software realisation– Part 6 gives guidance on applying Parts 2 and 3


9.1 E/E/PE system safety requirements specification

9.1.1Safety functions reqs.

specification9.1.2

Safety integrity reqs. specification

9.3E/E/PE system design

and development

9.4E/E/PE system

integration

9.6E/E/PE system

safety validation

9.2E/E/PE Sys. safety validation planning

9.5E/E/PE system O & M

procedures

E/E/PE SYSTEM REALISATION

To ‘overall O&M and repair’ in Overall Safety

Lifecycle


9.1 Software safety requirements specification

9.1.1Safety functions reqs.

specification9.1.2

Safety integrity reqs. specification

9.3Software designand development

9.4PE integration

(hardware/software)

9.6Software safety

validation

9.2Software safety

validation planning

9.5Software O & M

procedures

SOFTWARE REALISATION

To ‘overall O&M and repair’ in Overall Safety

Lifecycle



12 Overall installation and commissioning

To install the total combination of systems and external risk reduction facilities – as integrated parts of the total system

13 Overall safety validation

To validate, in accordance with the safety validation plans, that the safety requirements have all been correctly met



14 Overall operation and maintenance

To operate and maintain the total combination of systems and external risk reduction facilities in a manner such as to achieve and maintain the functional safety for which the total system was planned and designed

• Employ the safety management system (responsibility, authority, approvals, etc.)



15 Overall modification and retrofit

To ensure that functional safety is appropriate and adequate during, and subsequent to, changes to the system

• Hazard and risk analysis should be carried out prior to change



16 Decommissioning and disposal

To ensure that safety is maintained during the decommissioning process

• Hazard and risk analysis should be carried out prior to decommissioning and disposal

• Disposal can be dangerous (e.g. nuclear waste)

• Careful planning and management are required


SAFETY LIFECYCLE SUMMARY

Understand the functional goals and design

Identify the hazards

Analyse the hazards

Determine and assess the risks posed by the hazards

Specify the risk reduction measures and their SILs

Define the required safety functions (and their SILs)

Carry out safety validation

Operate, maintain, change, decommission, dispose safely


(c) Felix Redmill, 2011 40

RISKS DURING DECOMMISSIONING AND DISPOSAL

• 1984 dumping of X-ray machine in Mexico

• Cobalt 60 contamination

• 13000 tons of steel reinforcing bars

• Hundreds of houses in which the bars were used had to be demolished

CERN, May '11

NOTES ON THE MODEL

• The model is an overview and omits activities that are common to all lifecycle phases, for example:

– Management

– Documentation

– Verification

– Quality assurance

– Safety assessment

• There is a change of focus after Phase 3

• Each phase of the overall safety lifecycle shall be divided into elementary activities [1:7.1.4.4]


THE SAFETY LIFECYCLE AND THE STANDARD

• Forms the standard’s spine, and is used in the standard as the basis of safety planning

• Is used in the standard as the basis for specifying requirements

• The standard requires it to be used as the basis for demonstrating compliance to the standard


HAZARD AND RISK ANALYSIS - 1

• Hazard identification

– Define hazards and hazardous events of EUC and its control system for all reasonably foreseeable circumstances

Fault conditions

Reasonably foreseeable misuse

Human factors

(not sufficient to confirm that normal operation is safe)


HAZARD AND RISK ANALYSIS - 2

• Hazard analysis

– Determine the event sequences leading to each hazardous event (but note too: hazards from interactions)

– Identify the causes of hazards and assess the consequences of hazardous events

– Determine the risks associated with the hazardous events

• Risk assessment

– Assess the risks against tolerability criteria


HAZARD IDENTIFICATION

• The hazards, hazardous events and hazardous situations of the EUC and the EUC control system shall be determined under all reasonably foreseeable circumstances [1: 7.4.2.3]

• The basis of safety analysis

• Requires a managed team effort

• Techniques are used to facilitate (e.g. HAZOP, FMEA, FTA)


HAZARD IDENTIFICATION

• Although hazard identification is formally

identified as taking place in Phase 3 of the safety

lifecycle, it should be continuous - hazards

identified in audits, by clients, in reports, via

incidents, should all be recorded and analysed


‘The claim that a hazard was not foreseen

is not available to one who did not use

foresight appropriate to his enterprise’

[Mr Justice Jackson, USA, 1953]


HAZARD ANALYSIS

• All identified hazards should be analysed to determine the risks that they pose

• The event sequences leading to the hazardous events shall be determined [1: 7.4.2.4]

• The likelihood of the hazardous events shall be evaluated [1: 7.4.2.5]

• The likelihood of a specific hazardous event may be expressed quantitatively or qualitatively [1: note to 7.4.2.5]

• The [potential] consequences associated with the hazardous events shall be determined [1: 7.4.2.6]


EVENT SEQUENCES

• In some cases the event sequence is short and directe.g. in this simple chemical plant:If valve V1 does not close Too much of A in mixture in C Explosive mixture

• But in general the progression from the most basic cause to the risk of the system-level hazardous event (accident) is one of many stages of cause and effect– and almost invariably results from a combination of

circumstances

V1 V2

A C B


A BOTTOM-UP VIEW

Bowsun asleep in his cabin when ship is due to depart

Bow doors not closed

Ship puts to sea with bow doors open

Water enters car deck

As ship rolls, water rushes to one side

Ship capsizes

Lives lost


A TOP-DOWN VIEW

Ship puts to sea with bow doors open

Bosun did not close doors

Bosun not availableto close doors

Problem with doors& bosun can’t close them

Bosun noton ship

Door or hinge problem

Problem with closing

mechanism

Problem with power supply

Bosun on board but not at station

Bosun asleepin cabin

Bosun in bar


HAZARD AND RISK ANALYSIS

• Normative requirements:

– The EUC risk shall be evaluated, or estimated, for each determined hazardous event [1: 7.4.2.7]

– Either qualitative or quantitative hazard and risk analysis techniques may be used [1: 7.4.2.8]

– The information and results that constitute the hazard and risk analysis shall be documented [1: 7.4.2.11] and maintained throughout the lifecycle [1: 7.4.2.12]

• There is (informative) guidance in Part 5 on:

– The underlying concepts of risk and its analysis

– Some risk-based methods of determining SILs

• Choice of method is the responsibility of the user


RISK ASSESSMENT

• To assess (evaluate) the risks against predetermined tolerability criteria

• To determine risk management plans for dealing with risks (reduction, avoidance, acceptance with emergency plans, etc.)

• To prioritise risk management plans, if necessary


THE ALARP PRINCIPLE(The UK Regulator’s Guidance)

Intolerable region

The ALARP or tolerability region

Broadly acceptable region

Risk cannot be justified except in extraordinary circumstances

Risk is tolerable only if further reduction is impracticable or if its cost is grossly disproportionate to the improvement gained

It is necessary to maintain assurance that risk remains at this level


RISK TOLERABILTY

• IEC 61508 definition: risk which is accepted in a given context based on the current values of society

• Not trivial to determine

• Differs across industry sectors

• May change with time

• Depends on perception

• Should be determined by discussion among parties, including

– Regulators

– Those posing the risks

– Those to be exposed to the risks


NOTES

• Two aspects of a hazard interest us: likelihood and consequence

• The standard is based on reducing likelihood (consequence is usually closely related to goals)


SAFETY INTEGRITY LEVELS AND

SAFETY REQUIREMENTS

RISK-BASED ACTION

• The risks posed by the EUC and its control system are identified and analysed

• Some may be tolerable as they are, some must be mitigated

• The need for risk reduction gives rise to safety requirements

• Countermeasures and their costs are justified by their appropriateness to the risks

• Countermeasures are provided as safety functions

• Systems which realise safety functions are ‘safety-related’

• To provide the required risk reduction, safety-related functions and systems must themselves be reliable

• Safety integrity levels are used in the standard to provide a link between risk and mitigating action


SAFETY INTEGRITY LEVELS

• To provide the required risk reduction, the safety-related functions and systems must themselves be reliable

• Safety integrity: Probability of a safety-related system satisfactorily performing the required safety functions under all the stated conditions within a stated period of time [4: 3.5.4]

– Safety integrity is “reliability-based”

• Safety integrity level: Discrete level (one out of a possible four) corresponding to a range of safety integrity values, where SIL 4 has the highest level of safety integrity and SIL 1 has the lowest [4: 3.5.8]

– The SIL allocated to a system or function is based on the associated risks, but is not a measure of risk



SAFETY INTEGRITY IS A RELIABILITY-“TYPE” TARGET

• The requirement is for a tolerable rate, not of all failures, but of dangerous failures

• Example: S should not fail dangerously more than once in 7 years of continuous operation

• Example: A maximum of 1 in 1000 demands should result in a dangerous failure

• If the rate of dangerous failures of the safety function can be measured accurately, achievement of the defined safety integrity may be claimed

CERN, May '11


IEC 61508 SIL VALUES (IEC 61508)

SafetyIntegrity

Level

Low Demand Mode ofOperation

(Pr. of failure to perform itssafety functions on demand)

Continuous/High-demand Modeof Operation

(Pr. of dangerous failure perhour)

4 >= 10-5 to 10-4 >= 10-9 to 10-8

3 >= 10-4 to 10-3 >= 10-8 to 10-7

2 >= 10-3 to 10-2 >= 10-7 to 10-6

1 >= 10-2 to 10-1 >= 10-6 to 10-5

CERN, May '11

RELATIONSHIP BETWEENLOW-DEMAND AND CONTINUOUS

MODES

• Low-demand mode:

‘Frequency of demands ... no greater than one per

year’

• 1 year = approx. 104 hours (8760)

• Continuous and low-demand figures related by factor

of 104


PROCESS OF SIL DERIVATION

• Hazard identification• Hazard analysis• Risk assessment• Determination of necessary risk reduction• Safety requirements specification

– functional requirements– safety integrity requirements

• Allocation of safety requirements to functions– functions to be performed– safety integrity requirements

• Allocation of safety functions to safety-related systems– system requirements– safety integrity requirements



SIL IN TERMS OF RISK REDUCTION (IEC 61508)

EUCrisk

Increasing risk


Tolerable risk

• The necessary risk reduction effected by a safety function

• Its functional requirements define what it should do• Its safety integrity requirements define its tolerable

rate of dangerous failure

CERN, May '11


THE IEC 61508 MODEL OF RISK REDUCTION

EUC

Control system

Protection system

Safety functionsSafety functions

Utility + risks

CERN, May '11

THE SIL OF A SYSTEM

• Functions within a system may have different SILs

• The SIL of hardware is that of the safety function with the highest SIL

• For a safety-related system that implements safety functions of different SILs, the hardware and software shall be of the highest SIL unless it can be shown that the implementation of the safety functions of the different SILs is sufficiently independent

• Where software is to implement safety functions of different SILs, all the software shall be of the highest SIL, unless the different safety functions can be shown to be independent


SAFETY AND NON-SAFETY FUNCTIONS

Where a safety-related system is to implement both safety and non-safety functions, then all the hardware and software shall be treated as safety-related unless it can be shown that the implementation of the safety and non-safety functions is sufficiently independent (i.e. that the failure of any non-safety-related functions does not affect the safety-related functions). Wherever practicable, the safety-related functions should be separated from the non-safety-related functions


ASSUMED RELATIONSHIPBETWEEN EVENT FREQUENCY

AND SAFETY FUNCTION RELIABILITY

Event frequency

10-9

EUCdangerous failure

frequency

10-2

Safety Functionrate of dangerous

failure

10-7

AND

• Requires strong argument for independence between EUC and safety function failure rates


EACH HAZARD CARRIES A RISK

Increasing risk

Tolerable risk


SIL - ACHIEVED OR TARGET RELIABILITY ?

• Starts off as target reliability

• If:– Simple design– Simple hardware components– Known fault histories in same or similar

applications– Random failures dominate

There may be confidence that actual = target rate of dangerous failures

• But for software and complex hardware, where systematic failures dominate– No confidence that product reliability equals

target reliability

• Then, the standard relies on the development process(c) Felix Redmill, 2011 70CERN, May '11

THE DERIVATION AND APPLICATION OF SILS

(The ‘Bowtie’ Diagram)

Riskassessment

SIL

Development process


NOTES ON SILs

• SIL is based on risk but is not a measure of risk

– It is the probability of dangerous failure of a system or function within a defined time

• SILs provide means of relating the target reliability of a system or function to the risk reduction it is expected to achieve

• The allocated SIL influences the processes used in the development of safety-related systems or functions, e.g.:

– The rigour of their design, testing, assessment …

– The methods and techniques used

• Their requirement for rigour in safety management is intended to permit a reasonable claim about the likelihood or frequency of dangerous failures of a system or function


SILs AND SAFETY

• The processes implied by a SIL cannot guarantee achievement of the desired likelihood or frequency of dangerous failure

– The link between process and product is not definitive

– The choice of processes is judgemental

– It is difficult, and often impossible, to prove very low failure rates, particularly of software

• Beware of believing that achieving the SIL implies that the system is safe

– Safety depends on the right safety requirements being derived as well as on those that are specified being met

• Meeting the requirements of a SIL offers confidence, not proof


AN EXAMPLE OF SIL BASED ON CONSEQUENCEMotor Industry

• In the Motor Industry Software Reliability Association (MISRA) guidelines, the allocation of a SIL is determined by ‘the ability of the vehicle occupants, not necessarily the driver, to control the situation following a failure’

• Main steps in determining an integrity level:

a) List all hazards that result from all the failures of the system

b) Assess each failure mode to determine its controllability category

c) The failure mode with the highest associated controllability category determines the integrity level of the system



MOTOR INDUSTRY EXAMPLE

Controllability category

Acceptable failure rate Integrity level

Uncontrollable Extremely improbable 4

Difficult to control

Very remote 3

Debilitating Remote 2

Distracting Unlikely 1

Nuisance only Reasonably possible 0

CERN, May '11

TOLERABLE RISK LEVELS

• Interpretations of the acceptable failure rates also need to be defined within an industry sector

– 10-6 per hour may be extremely improbable for a single system but very frequent if there are sales of 1,000,000 systems


Table A.5 — Software design and development: software module testing and

integration(from Annex A, Part 3)


Table B.2 — Dynamic analysis and testing

(from Part 3, Annex B)

Technique / Measure Ref. SIL 1 SIL 2 SIL 3 SIL 4

1. Test case execution from boundary value analysis

C.5.4 R HR HR HR

2. Test case execution from error guessing

C.5.5 R R R R

3. Test case execution from error seeding

C.5.6 — R R R

4. Performance modelling C.5.20 R R R HR5. Equivalence classes and input partition testing

C.5.7 R R R HR

6. Structure-based testing C.5.8 R R HR HR


DERIVATION OF SAFETY REQUIREMENTS

Identify the hazards

Analyse the hazards

Determine the risks posed by the hazards

Specify the risk reduction measuresand their SILs

Determine the required safety functions

Derive their SILs


SAFETY REQUIREMENTS

• Measures against the risks posed by the identified hazards

• A set of all necessary overall safety functions shall be developed based on the hazardous events derived from the hazard and risk analysis. This shall constitute the specification for the overall safety function requirements [1: 7.5.2.1]

• For each overall safety function, a target safety integrity requirement shall be determined that will result in the tolerable risk being met [1: 7.5.2.2]

• A requirement has 2 elements

– Functional

– Safety integrity


ADVANTAGES OFA SAFETY REQUIREMENTS

SPECIFICATION

• Traceability from risk to requirement to design to

safety function to safety-related system is not

made complex by functional requirements

• Separate validation

• Safety case is more easily prepared

• Independent safety assessment is facilitated


CERN, May '11 82

SAFETY REQUIREMENTSSEPARATION VS. INTEGRATION

• Safety must be built into a system from the start

• Yet safety requirements are specified separately from functional requirements

– To achieve many advantages

• But safety functions must be designed to complement the total system and be integrated into it

• ‘The system’ = utility functions + safety functions


SECURITY CONSIDERATIONS

• If security threats have been identified then a

vulnerability analysis should be undertaken in

order to specify security requirements [1: 7.5.2.2]


CERN, May '11 84

SAFETY REQUIREMENTS

• Effectiveness throughout the lifecycle depends on specifying the correct safety requirements

• In software eng., getting and keeping the reqs. correct are– The most difficult issues– Costly (but not as costly as later corrections - 10/1 rule)

• Will the safety context ensure correct requirements?• Safety requirements depend on risk analysis• The foundation of risk analysis is hazard identification• Hazard identification can be time-consuming and expensive

– It is often the subject of management cuts– The wrong people are often involved in it

• Will we have well developed but ineffective safety functions


SAFETY REQUIREMENTS ALLOCATION

• Define solution safety functions (i.e. carry out design)

– Is there a need for partitioning between them ?

– Is there a need for separate safety-related systems ?

– Their target SILs are defined by their requirements

• Allocate functions appropriately to E/E/PE systems, other technology systems, and external risk reduction facilities

– Consider available skills, competences and resources (simpler technology solutions may be advantageous)

• Define SILs for systems,based on the SILs of the functions allocated to them

§ Processes, techniques, etc., used in the development of systems should then be in accordance with their SILs


COMBINED MEANS OF RISK REDUCTION

Residual risk

Tolerable risk

EUCrisk

Increasing risk


Actual risk reduction

Part of risk covered by other tech.

systems

Part of risk covered by

E/E/PE systems

Part of risk covered by external facilities


SAFETY-RELATED SYSTEMS - 1 • Systems designated as safety-related are subject to

the requirements of the standard

Where an E/E/PE safety-related system is to implement both safety and non-safety functions, then all the hardware and software shall be treated as safety-related unless it can be shown that the implementation of the safety and non-safety functions is sufficiently independent (i.e. that the failure of any non-safety-related functions does not cause a dangerous failure of the safety-related functions). [2: 7.4.2.3]


SAFETY-RELATED SYSTEMS - 2

Where failures of the EUC control system place a demand on one or more E/E/PE safety-related systems and/or other risk reduction measures, and where the intention is not to designate the EUC control system as a safety-related system, the following requirements shall apply [1: 7.5.2.6]:

a) The rate of dangerous failure claimed for the EUC control system shall be supported by data acquired through one of the following:– actual operating experience of the EUC control

system in a similar application (‘proven in use’)– a reliability analysis carried out to a recognised

procedure– an industry database of reliability of generic

equipment(c) Felix Redmill, 2011 88CERN, May '11

SAFETY-RELATED SYSTEMS – 2 – Contd.

Where failures of the EUC control system place a demand on one or more E/E/PE safety-related systems … and where the intention is not to designate the EUC control system as a safety-related system …

b)The rate of dangerous failure that can be claimed for the EUC control system shall be no lower than 10-5 dangerous failures per hour (SIL 1)

c) All reasonably foreseeable dangerous failure modes of the EUC control system shall be taken into account in developing the specification for the overall safety requirements

d)The EUC control system shall be independent from the E/E/PE safety-related systems and other risk reduction measures



WHY NOT SIMPLY IMPROVE THE BASIC SYSTEM?

• IEC 61508 bases safety on the addition of safety functions

• This assumes that EUC + control system are fixed

• Why not reduce risk by making EUC & control system safer?

• This is an iterative process

– Then, if all risks are tolerable no safety functions required

– But (according to IEC 61508) claim cannot be lower than 10-5 dangerous failures/hour (SIL 1)

• If there comes a time when we can't (technological) or won't (cost) improve further

– We must add safety functions if all risks are not tolerable

• We are then back to the standard as it is

CERN, May '11

MANAGEMENT ISSUES

DOCUMENTATIONObjective of the Requirements

• Stated objective [1: 5.1]: To specify the necessary information to be documented for the effective performance of:

– All phases of the safety lifecycle

– Safety management

– Verification

– Safety assessment

• Note 1 [1:5.1]: The documentation requirements are concerned with information rather than physical documents [and] need not be contained in physical documents unless this is explicitly declared in the relevant sub-clause


DOCUMENTATIONWhat is Called For - 1

• Documentation shall contain sufficient

information [1:5.2]

– For each phase of the lifecycle, necessary for

effective performance of subsequent phases

and verification activities

– For the management of functional safety

– For the implementation of a functional safety

assessment, together with the information and

results derived from any functional safety

assessment



• The availability of documentation shall be sufficient for the duties to be performed in respect of the clauses of this standard [1:525]

• The documentation shall [1:5.2.6]:– Be accurate and concise– Be easy to understand by those persons having

to make use of it– Suit the purpose for which it is intended– Be accessible and maintainable

• There are also briefly-stated requirements on titles, indexing, structure



• All relevant documents shall be revised, amended, reviewed and approved under an appropriate document control scheme [1:2.11]

• All activities need to be documented:Most clauses contain short documentation sub-clauses, e.g.:– The information and results of the safety

requirements allocation ... shall be documented [1: 7.6.2.13]

– The results of the software module testing shall be documented [3: 7.4.7.3]


DOCUMENTATIONManagement is responsible

• The stated requirements are briefly stated and goal-based: it is, therefore, management’s responsibility to define the document infrastructure, considering the needs of performance of activities, verification, assessment, maintenance, the safety case, later needs for proof, decommissioning, etc.

Remember that safety must be demonstrated as well as achieved, and that demonstration – both in advance and retrospectively – is evidenced by documentation


CONFORMANCE TO THE STANDARDWhat the Standard Demands

• To conform to this standard it shall be demonstrated that the requirements have been satisfied to the required criteria specified (for example safety integrity level) and therefore, for each clause or sub-clause, all the objectives have been met [1: 4.1]


CONFORMANCE TO THE STANDARDUse of Another Lifecycle Model

• The overall safety lifecycle should be used as a basis for claiming conformance to this standard, but a different overall safety lifecycle can be used, providing the objectives and requirements of each clause of this standard are met [1: 7.1.1.1]

• Safety planning requires a definition of the activities to be carried out. The standard provides a framework for definition, but:

If another overall safety lifecycle is used, it shall be specified during the functional safety planning, and all the objectives and requirements in each clause or sub-clause in this standard shall be met [1: 7.1.4.1]


CONFORMANCE TO THE STANDARDUse of Another Lifecycle Model

• Need to demonstrate how the specified lifecycle's phases match the standard's clauses

• Demonstrating that the objectives and requirements of the clauses in the standard have been met requires demonstration that the activities defined in the clauses of the standard are matched by the activities specified within the specified lifecycle


ALLOWANCE FOR NON-CONFORMANCE

• This standard specifies the requirements for E/E/PE safety-related systems and has been developed to meet the full range of complexity associated with such systems. However, for low-complexity systems, where dependable field experience exists that provides the necessary confidence that the required safety integrity can be achieved, the following options are available [1: 4.2]:

– ... certain of the requirements may be unnecessary and exemption from compliance with them is acceptable providing this is justified

In the main, only simple electromechanical systems could meet this criterion


ALLOWANCE FOR NON-CONFORMANCE

• ‘certain requirements’ - requirements will vary with application

• ‘providing this is justified’ - the user must decide what constitutes justification and how to demonstrate it

• Management must make decisions based on credible evidence and document both the decisions and the supporting evidence


SUGGESTIONS ON CLAIMING CONFORMANCE

• Create conformance infrastructure at the start– Define the safety lifecycle to be used– Plan documentation of the lifecycle processes– Plan signing-off of each process, including

authorisation• Agree safety lifecycle with assessor, if possible• Define unnecessary requirements and document

the reasons• Agree exemptions with assessor, if possible• Document all major decisions, with evidence and

justification• Adhere to compliance infrastructure throughout


CONFORMANCE AND SAFETY

• Conforming to the standard may be accepted as evidence of good practice

• Assessor seeks to be confident of safety

• Conformance will suggest safety but does not prove it

• IEC 61508 (in its definition) is limited to E/E/PE systemsEnsure consistent practice for all safety-related aspects of the total system


MANAGEMENTWhat the Standard Calls For - 1

• An organisation with responsibility for an E/E/PE safety-related system, or for one or more phases of a safety lifecycle, shall appoint one or more persons to take responsibility for [1: 6.2.1]:

– That system and those lifecycle phases

– Coordinating the safety-related activities carried out in those phases

– The interfaces between those phases and other phases carried out by others

– Discharging the management activities defined in the standard


MANAGEMENTWhat the Standard Calls For - 2

• Management is required to develop procedures to create appropriate safety infrastructure and to define what safety activities are to be carried out and how they should be carried out. Examples are:– Setting safety policy– Identifying persons and defining competences– Defining lifecycle phases– Prescribing measures and techniques– Providing procedures for all activities– Defining requirements for audits– Defining and arranging training

• Much of this amounts to safety planning at various levels


SAFETY PLANNING

• A safety lifecycle for the development of software shall be selected and specified during safety planning [3: 7.1.2.1]

• For software development, ‘it is not possible to give an algorithm for combining the techniques and measures that will be correct for any given application ... the appropriate combination ... is to be stated during safety planning’ [3: Annex A]

• Safety plans must be provided for assessment(they will be available throughout the system's lifecycle)

• Safety planning is the responsibility of management and is likely to be transparent later


CERN, May '11 107

SAFETY PLANNING

• Doing a good job on functionality does not ensure safety– Safety needs to be planned

• Safety planning should be an integral part of all stages of project and operational planning

• Safety planning must include– Designing procedures for each life-cycle phase– Defining safety monitoring and reporting processes

• Safety must be demonstrated in advance– The safety case and safety assessment must be

planned• Safety planning demands that managers understand

their processes, their products – and safety


SAFETY MANAGEMENT

• Management must:– Accept full responsibility for all aspects of safety– Understand the safety implications of the

system and of all activities in all lifecycle phases– Derive evidence to form and support decisions– Decide what safety measures to take and how to

take them– Put a safety infrastructure in place (people,

plans, procedures, etc.)

• Management must provide leadership in safety matters


SAFETY MANAGEMENT SYSTEM

• Responsibilities amount to the need for a safety

management system (SMS) - and management must

put this in place

• An SMS points the way to achieving safety

- But it is the safety culture of people which

achieves it

• Management must develop and maintain a safety

culture


CERN, May '11 110

MANAGEMENT AND CULTURE

• Safety is not achieved only by technical efficiency• It depends on a safety perspective in all management,

e.g.:- Selection and competence of staff- Definition and policing of procedures - Definition of responsibility and allocation of

authority - Defining and maintaining a documentation system- Accumulating and structuring evidence- Assessment processes and relationships with

assessors• Systems facilitate the achievement of safety

– But people achieve it• All management must demonstrate safety in leadership

– And inculcate a consistent safety culture(c) Felix Redmill, 2011

CERN, May '11 111

SAFETY MANAGEMENT AT SENIOR LEVEL

• Safety policy

• Defining major risks and the use of risk analysis

• Strategic safety planning

• Safety organisation and procedures

• Co-ordination and communication procedures

• Delegation of responsibility for system safety to an individual

Note that senior management has been cited in almost every major accident inquiry

– The days are gone when the final trigger event is readily accepted as the “cause” of an accident


CERN, May '11 112

EXTRACT FROM REPORT OF HERALD OF FREE ENTERPRISE COURT

HEARING

• …a full investigation into the circumstances of the disaster leads inexorably to the conclusion that the underlying or cardinal faults lay higher up in the Company. The Board of Directors did not appreciate their responsibility for the safe management of their ships. They did not apply their minds to the question: What orders should be given for the safety or our ships?

• The directors did not have any proper comprehension of what their duties were.

• All concerned in management, from the members of the Board of Directors down to the junior superintendents, were guilty of fault in that all must be regarded as sharing responsibility for the failure of management. From top to bottom the body corporate was infected with the disease of sloppiness…(c) Felix Redmill, 2011

CERN, May '11 113

INDIVIDUAL RESPONSIBLE FOR A SYSTEM OR A LIFE-CYCLE PHASE

• Identify roles and responsibilities• Ensure appropriate competence• Plan training• Define communication modes, inter- and intra-

phase • Define documentation system• Plan audits and act on results• Define change-control system• Plan safety-case development• Monitor progress• Plan independent safety assessment


SAFETY ASSESSMENT

• One or more persons shall be appointed to carry out one or more functional safety assessments in order to arrive at a judgement on the adequacy [1:8.2.1] of:

– The functional safety achieved by the E/E/PE safety-related systems, within their particular environment, in respect to the relevant clauses of this standard

– The compliance to the relevant clauses of this standard, achieved in the case of elements/subsystems

• Those carrying out functional safety assessment shall have access to all persons involved in any safety lifecycle activity and all relevant information and equipment [1: 8.2.2]


SAFETY ASSESSMENT

• Assessment shall be applied to all lifecycle phases and should include documentation, verification and safety management [1: 8.2.3]

• Those carrying out the assessment shall consider the activities carried out and the outputs obtained during each phase of the lifecycle, and judge whether adequate functional safety has been achieved [1: 8.2.4]

• Prior to an assessment, the assessment plans shall be approved by those carrying it out and by those responsible for safety management [1: 8.2.11]

• Three levels of independence are defined:– Independent person– Independent department– Independent organisation


INDEPENDENCE IN ASSESSMENTOverall lifecycle phases 1 to 8 and 12 to 16

• Typical consequences (arising from failure of risk-reduction measures):A: minor injury onlyB: serious permanent injury to one or more persons, death to

one personC: death to several peopleD: very many people killed


NOTES ON INDEPENDENCE IN ASSESSMENT

X: The level of independence specified is a minimum for the specified consequence or SIL - If a lower level is adopted, the rationale for using it level should be detailed

Y: The level of independence specified is considered insufficient for the specified consequence or SIL

Either X1 or X2 (but not both) is applicable, and the rationale for choosing X1 or X2 should be detailed.

Factors that would make X2 more appropriate than X1 are:– lack of previous experience with a similar design– greater degree of complexity– greater degree of novelty of design– greater degree of novelty of technology


INDEPENDENCE IN ASSESSMENTOverall lifecycle phases 9 and 10 (and 11)


SOME STRENGTHS OF THE STANDARD

• Combines safety engineering with software engineering

• Emphasises risk-based justification, not ‘I followed the rules’

• It covers the system lifecycle and not merely system development

• Provides a basis for international consistency in system safety

• It is, in principle, goal-based (though it includes a great deal of prescriptive process)


SOME LIMITATIONS OF THE STANDARD - 1

• Wordy, repetitive and not easy to read

• Does not set its context well or explain its purpose

or assumptions

• Its scope is limited to E/E/PE systems

• It refers to ‘hazard and risk analysis’ as a life cycle

phase

– But safety analysis is a continuing process

• The allocation of safety integrity levels is not well

explained


SOME LIMITATIONS OF THE STANDARD - 2

• It does not address human factors

• It does not cover the importance of safety culture

• It does not address risk posed by management

• It calls for safety assessment - but does not define

the evidence to be provided or that assessors

should look for

• It does not cover the safety case

• It relies heavily on process to achieve safety

– But process cannot offer proof of achievement


SOME OTHER OBSERVATIONS

• It requires a good understanding of risk principles

• It introduces several principles that are new to many practitioners, so understanding it requires education and training

• Better as the basis of sector- or project-specific standards than as a standard for direct application

• Application requires editing and:– An expert in the application field– An expert on the standard– A good editor

• The standard is already influential in many industry sectors

• It has been a pioneer in the field of functional safety


THOUGHTS ON USING STANDARDS

CERN, May '11 124

Defining what should

be done

Fundamental principles

Specific application

Context


CERN, May '11 125

BUT WE SEEK FORMULAE

Whatwe want

Standards

Tools

Rules


CERN, May '11 126

STANDARDS

Making what is done consistent and repeatable

The roles of standards

Defining what is to be done


CERN, May '11 127

EXTERNAL STANDARDS REQUIRE TAILORING

• May not represent the organisation’s way of working– Change processes– Tailor standard

• Difficulties of interpretation– Need an expert ‘help desk’

• Contain unnecessary clauses– Management must decide whether to remove

them• May not represent up-to-date practice

– Must define additional clauses


CERN, May '11 128

Introducing a new standard is a projectand should be treated as a project

Use of standards

Preparation (planning, infrastructure)

Discernment (decision-making, fundamentals)


IEC 61508: UNDERSTANDING THE STANDARD AND ITS PLACE IN SAFETY ENGINEERING AND MANAGEMENT Felix...

Documents

Transcript of IEC 61508: UNDERSTANDING THE STANDARD AND ITS PLACE IN SAFETY ENGINEERING AND MANAGEMENT Felix...