No Slide Title

Transcript No Slide Title

IEC 61508:

UNDERSTANDING THE STANDARD AND ITS PLACE IN SAFETY ENGINEERING AND MANAGEMENT Felix Redmill Redmill 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

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 parts Prepared 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

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 Utility + risks Control system Safety functions Protection system Safety functions

• • •

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

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

MEETING THE INTENT 1 — Understanding the Risk

T olerable risk EUC risk Necessary risk reduction Increasing 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

MEETING THE INTENT 2 — Safety-related systems

• •

Risk reduction may be achieved by various means This standard gives guidance on E/E/PE systems (There may be numerous hazards)

MANY RISKS

Residual risk 1 T olerable level of risk 1 Risk 2 T olerable level of risk 2 Risk 1 Necessary reduction of risk 1 Actual reduction of risk 1 Increasing risk

MEETING THE INTENT 3 — 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 INTENT 3 — 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 1 Clause 2 Clause 3 Clause 4 Clause 5 Clause 6 ‘software Clause 7 Clause 8

Scope - individual to each of the 3 parts Normative References Definitions and Abbreviations - all refer to Part 4 Conformance to this Standard - 2 and 3 refer to 1 Documentation - 2 and 3 refer to 1 Management of Functional Safety Part 1: Contains the requirements Parts 2 and 3 refers to Part 1 and Part 3 adds configuration management’ Safety Lifecycle Requirements Part 1: Overall Part 2: E/E/PE systems Part 3: Software Functional Safety Assessment - 2 and 3 refer to 1

CERN, May '11 18

STRUCTURE OF IEC 61508 [Figure 1 (Overall framework)] PART 1: 7.1 to 7.5

Development of overall safety requirements for all safety-related systems, and facilities Technical requirements PART 5

Informative

guidance on safety integrity requirements development PART 1: 7.6

Allocation of safety requirements to safety related systems and facilities PART 7 Overview of techniques and measures PART 2 Realisation of E/E/PE safety related systems PART 3 Realisation of safety related PART 6 Guidelines for the application of Parts 2 and 3 PART 1: 7.13 & 7.14

Installation and commissioning and safety validation of E/E/PE safety-related systems PART 1: 7.15 to 7.17

Operation & maintenance, modification & retrofit, decommissioning & disposal of E/E/PE safety related systems

CERN, May '11

Other requirements PART 4 Definitions and abbreviations PART 1: 5 & Annex A Documentation PART 1: 6 Management of functional safety PART 1: 8 Functional safety assessment

TECHNICAL PRINCIPLES

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)

OVERALL SAFETY LIFECYCLE 1 Concept 2 3 Overall scope definition Hazard and risk analysis 4 Overall safety requirements 5 Safety requirements allocation 6 O & M Overall planning of: 7 Safety validation Installation & commissioning 12 8 9 Safety related E/E/PES Realisation of: 10 Other tech. safety related systems 11 External risk reduction facilities Overall installation and commissioning

13 Overall safety validation 14 Overall operation, maintenance & repair Decommissioning or 16 disposal

CERN, May '11

15 Overall modification and retrofit

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

LIFECYCLE PHASES

1 Concept To 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 definition To 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?

LIFECYCLE PHASES

3 Hazard and risk analysis To 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?

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

THE LIFECYCLE PHASES

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'

THE LIFECYCLE PHASES

•

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

THE LIFECYCLE PHASES

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

THE LIFECYCLE PHASES

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?

THE LIFECYCLE PHASES

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

E/E/PE SYSTEM REALISATION 9.1

9.1.1

E/E/PE system safety requirements specification Safety functions reqs. specification 9.1.2

Safety integrity reqs. specification 9.2

E/E/PE Sys. safety validation planning 9.3

E/E/PE system design and development 9.4

E/E/PE system integration

9.6

E/E/PE system safety validation

CERN, May '11

9.5

E/E/PE system O & M procedures To ‘overall O&M and repair’ in Overall Safety Lifecycle

SOFTWARE REALISATION 9.1

9.1.1

Software safety requirements specification Safety functions reqs. specification 9.1.2

Safety integrity reqs. specification 9.2

Software safety validation planning 9.3

Software design and development 9.4

PE integration (hardware/software)

9.6

Software safety validation

CERN, May '11

9.5

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

THE LIFECYCLE PHASES

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

THE LIFECYCLE PHASES

•

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.)

THE LIFECYCLE PHASES

•

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

THE LIFECYCLE PHASES

• • •

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

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

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 direct e.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

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 available to close doors Problem with doors & bosun can’t close them Bosun not on ship Bosun on board but not at station Bosun asleep in cabin Bosun in bar Door or hinge problem Problem with power supply Problem with closing mechanism

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)

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

IEC 61508 SIL VALUES (IEC 61508)

Safety Integrity Level 4 3 2 1 Low D emand Mod e of Ope ration (Pr. of f ailu re to pe rform its safe ty fun ctio ns on d emand) >= 10 -5 to 10 -4 >= 10 -4 to 10 -3 >= 10 -3 to 10 -2 >= 10 -2 to 10 -1 Conti nuou s/Hi gh-de mand M od e of O peration (Pr. of dang erous failu re per ho ur) >= 10 -9 to 10 -8 >= 10 -8 to 10 -7 >= 10 -7 to 10 -6 >= 10 -6 to 10 -5

RELATIONSHIP BETWEEN LOW-DEMAND AND CONTINUOUS MODES

•

Low-demand mode: ‘Frequency of demands ... no greater than one per year’

•

1 year = approx. 10 4 hours (8760)

•

Continuous and low-demand figures related by factor of 10 4

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)

• • •

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

THE IEC 61508 MODEL OF RISK REDUCTION EUC Utility + risks Control system Safety functions

Protection system Safety functions

CERN, May '11 65

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 RELATIONSHIP BETWEEN EVENT FREQUENCY AND SAFETY FUNCTION RELIABILITY

Event frequency 10 -9 AND EUC dangerous failure frequency 10 -2 Safety Function rate of dangerous failure 10 -7

•

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

EACH HAZARD CARRIES A 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

THE DERIVATION AND APPLICATION OF SILS (The ‘Bowtie’ Diagram)

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 CONSEQUENCE Motor 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

Uncontrollable Difficult to control Debilitating Distracting Nuisance only

Acceptable failure rate

Extremely improbable Very remote Remote Unlikely Reasonably possible

Integrity level

4 3 2 1 0

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 1 . Test case executi on fr om boundary value analysis 2 . Test case executi on fr om error guessing 3 . Test case executi on fr om error seeding 4 . Performance modelling 5 . Equivalence classes and input partit ion te sti ng 6 . Structur e-based te sti ng

Ref.

C.5 .4

C.5 .5

C.5 .6

C.5 .2 0 C.5 .7

C.5 .8

SIL 1 SIL 2 SIL 3 SIL 4 R HR HR HR R R R R — R R R R R R R R R HR HR 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 measures and 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 OF A 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

SAFETY REQUIREMENTS SEPARATION 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]

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

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

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

MANAGEMENT ISSUES

DOCUMENTATION Objective 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

DOCUMENTATION What 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

DOCUMENTATION What is Called For - 2

• • •

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

DOCUMENTATION What is Called For - 3

• •

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]

DOCUMENTATION Management 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 STANDARD What 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 STANDARD Use 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 STANDARD Use 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 systems Ensure consistent practice for all safety-related aspects of the total system

MANAGEMENT What 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

MANAGEMENT What 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

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

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

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

**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…

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 ASSESSMENT Overall lifecycle phases 1 to 8 and 12 to 16

•

Typical consequences (arising from failure of risk-reduction measures): A: B: minor injury only serious permanent injury to one or more persons, death to C: D: one person death to several people 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 ASSESSMENT Overall 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

Defining what should be done

Fundamental principles Context Specific application

124

BUT WE SEEK FORMULAE

Standards What we want Rules Tools

The roles of standards STANDARDS Making what is done consistent and repeatable Defining what is to be done

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

Introducing a new standard is a project and should be treated as a project Preparation (planning, infrastructure) Use of standards Discernment (decision-making, fundamentals)