BS EN IEC 62061:2021 – TC
$280.87
Tracked Changes. Safety of machinery. Functional safety of safety-related control systems
Published By | Publication Date | Number of Pages |
BSI | 2021 | 386 |
This International Standard specifies requirements and makes recommendations for the design, integration and validation of safety-related control systems (SCS) for machines. It is applicable to control systems used, either singly or in combination, to carry out safety functions on machines that are not portable by hand while working, including a group of machines working together in a co-ordinated manner. This document is a machinery sector specific standard within the framework of IEC 61508 (all parts). The design of complex programmable electronic subsystems or subsystem elements is not within the scope of this document. This is in the scope of IEC 61508 or standards linked to it; see Figure 1. NOTE 1 Elements such as systems on chip or microcontroller boards are considered complex programmable electronic subsystems. The main body of this sector standard specifies general requirements for the design, and verification of a safety-related control system intended to be used in high/continuous demand mode. This document: – is concerned only with functional safety requirements intended to reduce the risk of hazardous situations; – is restricted to risks arising directly from the hazards of the machine itself or from a group of machines working together in a co-ordinated manner; NOTE 2 Requirements to mitigate risks arising from other hazards are provided in relevant sector standards. For example, where a machine(s) is part of a process activity, additional information is available in IEC 61511. This document does not cover – electrical hazards arising from the electrical control equipment itself (e.g. electric shock – see IEC 60204-1); – other safety requirements necessary at the machine level such as safeguarding; – specific measures for security aspects – see IEC TR 63074. This document is not intended to limit or inhibit technological advancement. Figure 1 illustrates the scope of this document. [Figure 1]
PDF Catalog
PDF Pages | PDF Title |
---|---|
1 | 30447129 |
233 | A-30379166 |
234 | undefined |
240 | Annex ZA(normative)Normative references to international publicationswith their corresponding European publications |
241 | Annex ZZ(informative)Relationship between this European standard and the essential requirements of Directive 2006/42/EC [2006 OJ L 157] aimed to be covered |
243 | English CONTENTS |
249 | FOREWORD |
251 | INTRODUCTION |
252 | 1 Scope |
253 | 2 Normative references Figures Figure 1 – Scope of this document |
254 | 3 Terms, definitions and abbreviations 3.1 Alphabetical list of definitions Tables Table 1 – Terms used in IEC 62061 |
256 | 3.2 Terms and definitions |
269 | 3.3 Abbreviations 4 Design process of an SCS and management of functional safety 4.1 Objective Table 2 – Abbreviations used in IEC 62061 |
270 | 4.2 Design process Figure 2 – Integration within the risk reduction process of ISO 12100 (extract) |
271 | Figure 3 – Iterative process for design of the safety-related control system |
272 | 4.3 Management of functional safety using a functional safety plan Figure 4 – Example of a combination of subsystems as one SCS |
274 | 4.4 Configuration management 4.5 Modification |
275 | 5 Specification of a safety function 5.1 Objective 5.2 Safety requirements specification (SRS) 5.2.1 General 5.2.2 Information to be available |
276 | 5.2.3 Functional requirements specification 5.2.4 Estimation of demand mode of operation |
277 | 5.2.5 Safety integrity requirements specification Figure 5 – By activating a low demand safety function at least onceper year it can be assumed to be high demand Table 3 – SIL and limits of PFH values |
278 | 6 Design of an SCS 6.1 General 6.2 Subsystem architecture based on top down decomposition 6.3 Basic methodology – Use of subsystem 6.3.1 General |
279 | 6.3.2 SCS decomposition |
280 | 6.3.3 Sub-function allocation 6.3.4 Use of a pre-designed subsystem Figure 6 – Examples of typical decomposition of a safetyfunction into sub-functions and its allocation to subsystems |
281 | 6.4 Determination of safety integrity of the SCS 6.4.1 General 6.4.2 PFH Figure 7 – Example of safety integrity of a safety functionbased on allocated subsystems as one SCS Table 4 – Required SIL and PFH of pre-designed subsystem |
282 | 6.5 Requirements for systematic safety integrity of the SCS 6.5.1 Requirements for the avoidance of systematic hardware failures |
283 | 6.5.2 Requirements for the control of systematic faults |
284 | 6.6 Electromagnetic immunity 6.7 Software based manual parameterization 6.7.1 General 6.7.2 Influences on safety-related parameters |
285 | 6.7.3 Requirements for software based manual parameterization |
286 | 6.7.4 Verification of the parameterization tool 6.7.5 Performance of software based manual parameterization 6.8 Security aspects |
287 | 6.9 Aspects of periodic testing 7 Design and development of a subsystem 7.1 General |
288 | 7.2 Subsystem architecture design Table 5 – Relevant information for each subsystem |
289 | 7.3 Requirements for the selection and design of subsystem and subsystem elements 7.3.1 General 7.3.2 Systematic integrity |
292 | 7.3.3 Fault consideration and fault exclusion |
293 | 7.3.4 Failure rate of subsystem element |
296 | 7.4 Architectural constraints of a subsystem 7.4.1 General |
297 | 7.4.2 Estimation of safe failure fraction (SFF) Table 6 – Architectural constraints on a subsystem: maximum SILthat can be claimed for an SCS using the subsystem |
298 | 7.4.3 Behaviour (of the SCS) on detection of a fault in a subsystem |
299 | 7.4.4 Realization of diagnostic functions |
300 | 7.5 Subsystem design architectures 7.5.1 General 7.5.2 Basic subsystem architectures |
301 | Figure 8 – Subsystem A logical representation Figure 9 – Subsystem B logical representation Figure 10 – Subsystem C logical representation |
302 | 7.5.3 Basic requirements Figure 11 – Subsystem D logical representation Table 7 – Overview of basic requirements and interrelationto basic subsystem architectures |
303 | 7.6 PFH of subsystems 7.6.1 General 7.6.2 Methods to estimate the PFH of a subsystem 7.6.3 Simplified approach to estimation of contribution of common cause failure (CCF) 8 Software 8.1 General |
304 | 8.2 Definition of software levels Table 8 – Different levels of application software |
305 | 8.3 Software – Level 1 8.3.1 Software safety lifecycle – SW level 1 Figure 12 – V-model for SW level 1 Figure 13 – V-model for software modules customized by the designer for SW level 1 |
306 | 8.3.2 Software design – SW level 1 |
308 | 8.3.3 Module design – SW level 1 8.3.4 Coding – SW level 1 |
309 | 8.3.5 Module test – SW level 1 8.3.6 Software testing – SW level 1 |
310 | 8.3.7 Documentation – SW level 1 8.3.8 Configuration and modification management process – SW level 1 |
311 | 8.4 Software level 2 8.4.1 Software safety lifecycle – SW level 2 Figure 14 – V-model of software safety lifecycle for SW level 2 |
312 | 8.4.2 Software design – SW level 2 |
314 | 8.4.3 Software system design – SW level 2 8.4.4 Module design – SW level 2 |
315 | 8.4.5 Coding – SW level 2 |
316 | 8.4.6 Module test – SW level 2 8.4.7 Software integration testing SW level 2 8.4.8 Software testing SW level 2 |
317 | 8.4.9 Documentation – SW level 2 |
318 | 8.4.10 Configuration and modification management process – SW level 2 9 Validation 9.1 Validation principles |
320 | Figure 15 – Overview of the validation process |
321 | 9.1.1 Validation plan 9.1.2 Use of generic fault lists 9.1.3 Specific fault lists |
322 | 9.1.4 Information for validation 9.1.5 Validation record |
323 | 9.2 Analysis as part of validation 9.2.1 General 9.2.2 Analysis techniques 9.2.3 Verification of safety requirements specification (SRS) |
324 | 9.3 Testing as part of validation 9.3.1 General 9.3.2 Measurement accuracy |
325 | 9.3.3 More stringent requirements 9.3.4 Test samples 9.4 Validation of the safety function 9.4.1 General |
326 | 9.4.2 Analysis and testing 9.5 Validation of the safety integrity of the SCS 9.5.1 General 9.5.2 Validation of subsystem(s) |
327 | 9.5.3 Validation of measures against systematic failures 9.5.4 Validation of safety-related software |
328 | 9.5.5 Validation of combination of subsystems 10 Documentation 10.1 General 10.2 Technical documentation |
329 | Table 9 – Documentation of an SCS |
330 | 10.3 Information for use of the SCS 10.3.1 General 10.3.2 Information for use given by the manufacturer of subsystems |
331 | 10.3.3 Information for use given by the SCS integrator |
333 | Annex A (informative)Determination of required safety integrity A.1 General A.2 Matrix assignment for the required SIL A.2.1 Hazard identification/indication A.2.2 Risk estimation Figure A.1 – Parameters used in risk estimation |
334 | A.2.3 Severity (Se) A.2.4 Probability of occurrence of harm Table A.1 – Severity (Se) classification |
335 | Table A.2 – Frequency and duration of exposure (Fr) classification |
336 | Table A.3 – Probability (Pr) classification |
337 | A.2.5 Class of probability of harm (Cl) A.2.6 SIL assignment Table A.4 – Probability of avoiding or limiting harm (Av) classification Table A.5 – Parameters used to determine class of probability of harm (Cl) |
338 | Table A.6 – Matrix assignment for determining the required SIL (or PLr)for a safety function |
339 | A.3 Overlapping hazards Figure A.2 – Example proforma for SIL assignment process |
340 | Annex B (informative)Example of SCS design methodology B.1 General B.2 Safety requirements specification B.3 Decomposition of the safety function Table B.1 – Safety requirements specification – example of overview |
341 | B.4 Design of the SCS by using subsystems B.4.1 General B.4.2 Subsystem 1 design – “guard door monitoring” Figure B.1 – Decomposition of the safety function Figure B.2 – Overview of design of the subsystems of the SCS |
343 | B.4.3 Subsystem 2 design – “evaluation logic” |
344 | B.4.4 Subsystem 3 design – “motor control” B.4.5 Evaluation of the SCS |
345 | B.4.6 PFH B.5 Verification B.5.1 General B.5.2 Analysis Table B.2 – Systematic integrity – example of overview |
346 | B.5.3 Tests Table B.3 – Verification by tests |
347 | Annex C (informative)Examples of MTTFD values for single components C.1 General C.2 Good engineering practices method C.3 Hydraulic components |
348 | C.4 MTTFD of pneumatic, mechanical and electromechanical components Table C.1 – Standards references and MTTFD or B10D values for components |
350 | Annex D (informative)Examples for diagnostic coverage (DC) Table D.1 – Estimates for diagnostic coverage (DC) (1 of 2) |
352 | Annex E (informative)Methodology for the estimation of susceptibilityto common cause failures (CCF) E.1 General E.2 Methodology E.2.1 Requirements for CCF E.2.2 Estimation of effect of CCF |
353 | Table E.1 – Criteria for estimation of CCF |
354 | Table E.2 – Criteria for estimation of CCF |
355 | Annex F (informative)Guideline for software level 1 F.1 Software safety requirements Table F.1 – Example of relevant documents related to the simplified V-model |
356 | F.2 Coding guidelines Table F.2 – Examples of coding guidelines |
357 | F.3 Specification of safety functions Figure F.1 – Plant sketch |
358 | F.4 Specification of hardware design Table F.3 – Specified safety functions |
359 | Table F.4 – Relevant list of input and output signals |
360 | F.5 Software system design specification Figure F.2 – Principal module architecture design |
361 | Figure F.3 – Principal design approach of logical evaluation |
362 | F.6 Protocols Figure F.4 – Example of logical representation (program sketch) Table F.5 – Example of simplified cause and effect matrix |
363 | Table F.6 – Verification of software system design specification Table F.7 – Software code review |
364 | Table F.8 – Software validation |
365 | Annex G (informative)Examples of safety functions Table G.1 – Examples of typical safety functions |
366 | Annex H (informative)Simplified approaches to evaluate the PFH value of a subsystem H.1 Table allocation approach |
367 | Table H.1 – Allocation of PFH value of a subsystem |
368 | H.2 Simplified formulas for the estimation of PFH H.2.1 General H.2.2 Basic subsystem architecture A: single channel without a diagnostic function Figure H.1 – Subsystem A logical representation Table H.2 – Relationship between B10D, operations and MTTFD |
369 | H.2.3 Basic subsystem architecture B: dual channel without a diagnostic function H.2.4 Basic subsystem architecture C: single channel with a diagnostic function Figure H.2 – Subsystem B logical representation Figure H.3 – Subsystem C logical representation |
370 | Figure H.4 – Correlation of subsystem C and the pertinent fault handling function Figure H.5 – Subsystem C with external fault handling function |
372 | Figure H.6 – Subsystem C with external fault diagnostics Figure H.7 – Subsystem C with external fault reaction Figure H.8 – Subsystem C with internal fault diagnostics and internal fault reaction |
373 | Table H.3 – Minimum value of 1/λD FH for the applicability of PFH equation (H.4) |
374 | H.2.5 Basic subsystem architecture D: dual channel with a diagnostic function(s) Figure H.9 – Subsystem D logical representation |
375 | H.3 Parts count method |
376 | Annex I (informative)The functional safety plan and design activities I.1 General I.2 Example of a machine design plan including a safety plan I.3 Example of activities, documents and roles Figure I.1 – Example of a machine design plan including a safety plan |
377 | Figure I.2 – Example of activities, documents and roles (1 of 2) |
379 | Annex J (informative)Independence for reviews and testing/verification/validation activities J.1 Software design J.2 Validation Table J.1 – Minimum levels of independence for review,testing and verification activities Table J.2 – Minimum levels of independence for validation activities |
381 | Bibliography |