Upload
millicent-shaw
View
216
Download
1
Tags:
Embed Size (px)
Citation preview
IEC 61508:UNDERSTANDING THE STANDARD
AND ITS PLACE INSAFETY ENGINEERING AND
MANAGEMENT
Felix RedmillRedmill Consultancy, London
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
(c) Felix Redmill, 2011 3CERN, May '11
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
(c) Felix Redmill, 2011 4CERN, May '11
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”
(c) Felix Redmill, 2011 5CERN, May '11
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
(c) Felix Redmill, 2011 6CERN, May '11
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
(c) Felix Redmill, 2011 8CERN, May '11
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
(c) Felix Redmill, 2011 11CERN, May '11
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)
(c) Felix Redmill, 2011 12CERN, May '11
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
(c) Felix Redmill, 2011 13CERN, May '11
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)
(c) Felix Redmill, 2011 14CERN, May '11
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
(c) Felix Redmill, 2011 15CERN, May '11
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
(c) Felix Redmill, 2011 16CERN, May '11
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
(c) Felix Redmill, 2011 17CERN, May '11
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)]
(c) Felix Redmill, 2011 19CERN, May '11
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
(c) Felix Redmill, 2011 22CERN, May '11
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?
(c) Felix Redmill, 2011 24CERN, May '11
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
(c) Felix Redmill, 2011 27CERN, May '11
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'
(c) Felix Redmill, 2011 28CERN, May '11
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
(c) Felix Redmill, 2011 29CERN, May '11
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
(c) Felix Redmill, 2011 30CERN, May '11
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?
(c) Felix Redmill, 2011 31CERN, May '11
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
(c) Felix Redmill, 2011 32CERN, May '11
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
(c) Felix Redmill, 2011 33CERN, May '11
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
(c) Felix Redmill, 2011 34CERN, May '11
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
(c) Felix Redmill, 2011 35CERN, May '11
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.)
(c) Felix Redmill, 2011 36CERN, May '11
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
(c) Felix Redmill, 2011 37CERN, May '11
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
(c) Felix Redmill, 2011 38CERN, May '11
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 39CERN, May '11
(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]
(c) Felix Redmill, 2011 41CERN, May '11
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
(c) Felix Redmill, 2011 42CERN, May '11
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)
(c) Felix Redmill, 2011 43CERN, May '11
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
(c) Felix Redmill, 2011 44CERN, May '11
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)
(c) Felix Redmill, 2011 45CERN, May '11
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
(c) Felix Redmill, 2011 46CERN, May '11
‘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]
(c) Felix Redmill, 2011 47CERN, May '11
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]
(c) Felix Redmill, 2011 48CERN, May '11
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
(c) Felix Redmill, 2011 49CERN, May '11
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
(c) Felix Redmill, 2011 50CERN, May '11
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
(c) Felix Redmill, 2011 51CERN, May '11
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
(c) Felix Redmill, 2011 52CERN, May '11
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
(c) Felix Redmill, 2011 53CERN, May '11
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
(c) Felix Redmill, 2011 54CERN, May '11
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
(c) Felix Redmill, 2011 55CERN, May '11
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)
(c) Felix Redmill, 2011 56CERN, May '11
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
(c) Felix Redmill, 2011 58CERN, May '11
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
(c) Felix Redmill, 2011 59CERN, May '11
(c) Felix Redmill, 2011 60
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
(c) Felix Redmill, 2011 61
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
(c) Felix Redmill, 2011 62CERN, May '11
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
(c) Felix Redmill, 2011 63CERN, May '11
(c) Felix Redmill, 2011 64
SIL IN TERMS OF RISK REDUCTION (IEC 61508)
EUCrisk
Increasing risk
Necessary risk reduction
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
(c) Felix Redmill, 2011 65
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
(c) Felix Redmill, 2011 66CERN, May '11
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
(c) Felix Redmill, 2011 67CERN, May '11
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
(c) Felix Redmill, 2011 68CERN, May '11
EACH HAZARD CARRIES A RISK
Increasing risk
Tolerable risk
(c) Felix Redmill, 2011 69CERN, May '11
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
(c) Felix Redmill, 2011 71CERN, May '11
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
(c) Felix Redmill, 2011 72CERN, May '11
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
(c) Felix Redmill, 2011 73CERN, May '11
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
(c) Felix Redmill, 2011 74CERN, May '11
(c) Felix Redmill, 2011 75
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
(c) Felix Redmill, 2011 76CERN, May '11
Table A.5 — Software design and development: software module testing and
integration(from Annex A, Part 3)
(c) Felix Redmill, 2011 77CERN, May '11
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
(c) Felix Redmill, 2011 78CERN, May '11
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
(c) Felix Redmill, 2011 79CERN, May '11
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
(c) Felix Redmill, 2011 80CERN, May '11
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
(c) Felix Redmill, 2011 81CERN, May '11
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
(c) Felix Redmill, 2011
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]
(c) Felix Redmill, 2011 83CERN, May '11
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
(c) Felix Redmill, 2011
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
(c) Felix Redmill, 2011 85CERN, May '11
COMBINED MEANS OF RISK REDUCTION
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
(c) Felix Redmill, 2011 86CERN, May '11
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]
(c) Felix Redmill, 2011 87CERN, May '11
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
(c) Felix Redmill, 2011 89CERN, May '11
(c) Felix Redmill, 2011 90
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
(c) Felix Redmill, 2011 92CERN, May '11
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
(c) Felix Redmill, 2011 93CERN, May '11
DOCUMENTATIONWhat 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
(c) Felix Redmill, 2011 94CERN, May '11
DOCUMENTATIONWhat 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]
(c) Felix Redmill, 2011 95CERN, May '11
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
(c) Felix Redmill, 2011 96CERN, May '11
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]
(c) Felix Redmill, 2011 97CERN, May '11
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]
(c) Felix Redmill, 2011 98CERN, May '11
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
(c) Felix Redmill, 2011 99CERN, May '11
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
(c) Felix Redmill, 2011 100CERN, May '11
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
(c) Felix Redmill, 2011 101CERN, May '11
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
(c) Felix Redmill, 2011 102CERN, May '11
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
(c) Felix Redmill, 2011 103CERN, May '11
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
(c) Felix Redmill, 2011 104CERN, May '11
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
(c) Felix Redmill, 2011 105CERN, May '11
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
(c) Felix Redmill, 2011 106CERN, May '11
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
(c) Felix Redmill, 2011
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
(c) Felix Redmill, 2011 108CERN, May '11
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
(c) Felix Redmill, 2011 109CERN, May '11
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
(c) Felix Redmill, 2011
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
(c) Felix Redmill, 2011
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]
(c) Felix Redmill, 2011 114CERN, May '11
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
(c) Felix Redmill, 2011 115CERN, May '11
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
(c) Felix Redmill, 2011 116CERN, May '11
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
(c) Felix Redmill, 2011 117CERN, May '11
INDEPENDENCE IN ASSESSMENTOverall lifecycle phases 9 and 10 (and 11)
(c) Felix Redmill, 2011 118CERN, May '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)
(c) Felix Redmill, 2011 119CERN, May '11
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
(c) Felix Redmill, 2011 120CERN, May '11
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
(c) Felix Redmill, 2011 121CERN, May '11
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
(c) Felix Redmill, 2011 122CERN, May '11
THOUGHTS ON USING STANDARDS
CERN, May '11 124
Defining what should
be done
Fundamental principles
Specific application
Context
(c) Felix Redmill, 2011
CERN, May '11 125
BUT WE SEEK FORMULAE
Whatwe want
Standards
Tools
Rules
(c) Felix Redmill, 2011
CERN, May '11 126
STANDARDS
Making what is done consistent and repeatable
The roles of standards
Defining what is to be done
(c) Felix Redmill, 2011
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
(c) Felix Redmill, 2011
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)
(c) Felix Redmill, 2011