Machine Safety: 13 terms to know for compliance with functional safety, ISO 13849-1
Knowing these 13 machine safety terms will help in efforts to comply with the international standard, ISO 13849-1: 2006, Safety of machinery, Safety-related parts of the control system. Many large companies have become early adopters of the new quantitative approach for designing machine control systems.
Since the international community passed ISO 13849-1: 2006, Safety of machinery, Safety-related parts of the control system, many large companies have become early adopters of the new quantitative approach for designing machine control systems. In so doing technical design personnel within these companies have had to learn several new terms required for compliance with the new standard.
ISO 13849-1 enables all safety-related control circuits (electrical, pneumatic, and hydraulic) to be designed for designated safety functions to meet ascertained performance levels for mitigating a hazard level to an acceptable level. To achieve high reliability levels for each safety function, the complete circuit (SRP/CS) must be designed using algorithms. These algorithms account for all components and devices in a safety-related circuit [such as sensors, logic solvers, output devices, etc.] using these variable terms and the look-up charts and graphs included in the standard. The actual process is far more detailed, however, the goal is to derive a Performance Level (PLa, b, c, d or e) that equals or exceeds a PL required (PLr) for each safety function. The required terms are:
1. B10D value: number of switching operations on which 10% of the sample fails – Suppliers provide this value for their components because it’s required to calculate the overall performance level for a safety circuit. B10D only applies to the dangerous failures of the considered component and the value is usually given for a lifetime of 10 years.
2. CCF: Common Cause Failure – A common cause failure is generally when a single failure or condition affects the operation of multiple devices that would otherwise be considered independent.
3. DC: Diagnostic Coverage – This involves the combination of both hardware and software and testing of the related diagnostics. Diagnostic coverage is the ratio of the probability of detected dangerous failures to the probability of all dangerous failures.
4. DCavg: Diagnostic Coverage average – Average diagnostic coverage for the above.
5. SRP/CS: Safety-Related Parts of a Control System – This term refers to all safety-related control elements regardless of the type of technology (electrical, hydraulic, pneumatic, mechanical, etc.), for all kinds of machinery. It does not specify safety functions or performance levels.
6. Designated Architecture: Predetermined structure of an SRP/CS – One of the first steps in designing the SPR/CS is selecting the system architecture to be used for the safety system. ISO 13849-1 leads you through this process for the architecture and determining the PLr (Performance Level required) for each safety function.
7. MTBF: Mean Time Between Failure – This value should be provided by the component supplier and represents the mean time between two failures for that component.
8. MTTFd: Mean Time to Fail dangerous – The same as above except that this value is only concerned with dangerous failures.
9. PFH: Probability of Failure per Hour – This value should be provided by the component supplier and represents the probability of failure per hour for that component to help detect random hardware safety integrity.
10. PFHd: Probability of Failure per Hour dangerous – This value should be provided by the component supplier and represents the probability of failure per hour for that component to help detect random hardware safety integrity.
11. PL: Performance Level – The ability of SRP/CS to operate a safety function and reliably achieve that safety function. Typically a PLa, PLb, PLc, PLd, or PLe.
12. PLr: Performance Level required – The result of determining the designated architecture is to in part determine the performance level required for a safety function. The PLr effectively becomes the goal for designing the actual safety circuit for that safety function.
13. SIL: Safety Integrity Level – This term has historically been used by safety component and device manufacturers and in the process industry sector for several years when designing safety systems and circuits. It is a requirement of IEC 61508.
Safety organizations, automation suppliers, and consultants (to mention a few) can offer courses on the new ISO 13849-1 compliance requirements. Courses are also offered for professional certifications as an FSE (Functional Safety Engineer) or CFSE (Certified Functional Safety Expert). Collectively, I view these evolutionary steps in machine safety as positive advancements for increased safety and potentially increased profits. Having said that, I suggest that we don’t underestimate the related impact of functional safety on all industrial companies: domestic or international and small, medium or large. Advancing from a qualitative system designing safety-related circuits to a quantitative system involving algorithms with multiple terms is not a simple task for all participants across the spectrum.
What are your best practice thoughts, suggestions or recommendations for any company considering evolving to complying with ISO 13849-1 for functional safety?
Has this presented you with any new perspectives? Do you have some specific topic or interest that we could cover in future blog posts? Add your comments or thoughts to the discussion by submitting your ideas, experiences, and challenges in the comments section below.
Contact: http://www.jbtitus.com for “Solutions for Machine Safety”.
|Search the online Automation Integrator Guide|
Case Study Database
Get more exposure for your case study by uploading it to the Control Engineering case study database, where end-users can identify relevant solutions and explore what the experts are doing to effectively implement a variety of technology and productivity related projects.
These case studies provide examples of how knowledgeable solution providers have used technology, processes and people to create effective and successful implementations in real-world situations. Case studies can be completed by filling out a simple online form where you can outline the project title, abstract, and full story in 1500 words or less; upload photos, videos and a logo.
Click here to visit the Case Study Database and upload your case study.