You can’t argue with Free Stuff! Last week we partnered with Schmersal Canada and Franklin Empire to put on three days of Free Safety Talks. We had full houses in all three locations, Windsor, London and Cambridge, with nearly 60 people participating.
We had two great presenters who helped people understand Pre-Start Health and Safety Reviews (PSRs) [1], CSAZ432-2016 [2], Interlocking Devices [3] and Fault Masking [4].
Mr Vashi at Franklin Empire Cambridge
Franklin Empire provided us with some great facilities and breakfast to keep our minds working. Thanks, Franklin Empire and Ben Reid who organized all of the registrations!
Mr Nix discussing injury rates in machine modes of operation
Reason #2 — Understanding Interlocking Devices
Mr Kartik Vashi, CFSE
Mr Kartik Vashi, CFSE, discussed the ISO Interlocking Device standard, ISO 14119. This standard provides readers with guidance in the selection and application of interlocking devices, including the four types of interlocking devices and the various coding options for each type. Did you know that ISO 14119 is also directly referenced in CSAZ432-16 [2]? That means this standard is applicable to machinery built and used in Canada as of 2016. If you don’t know what I’m talking about, you can contact Mr Vashi to get more information.
ISO 14119 Fig 2 showing some aspects of different types of interlocking devices [3]
Reason #3 — Understanding Fault Masking
Mr Vashi also talked about fault masking, an important and often misunderstood situation that can occur when interlocking devices or other electromechanical devices, like emergency stop buttons, are daisy-chained into a single safety relay or safety input on a safety PLC. Mr Vashi drew from ISO/TR 24119 to help explain this phenomenon. If you don’t understand the impact that daisy-chaining interlocking devices can have on the reliability of your interlocking systems, Mr Vashi can help you get a handle on this topic.
A part of ISO 24119 Fig 2 showing one common method of daisy-chaining interlocking devices [4]
Reason # 4 — Pre-Start Health and Safety Reviews
Mr Doug Nix, C.E.T.
Mr Nix opened his presentation with a discussion of some commonly asked questions about Pre-Start Health and Safety Reviews (PSRs). There are many ways that people become confused about the WHY, WHAT, WHEN, WHERE, WHO and HOW of PSRs, and Mr Nix covered them all. This unique-to-Ontario process requires an employer to have machines, equipment, racking and processes reviewed by a Professional Engineer or another Qualified Person when certain circumstances exist (see O. Reg. 851, Section 7 Table). If you are confused by the PSR requirements, contact Mr Nix for help with your questions.
Reason #5 — Understanding the changes to CSAZ432
CSAZ432 [2] was updated in 2016 with many changes. This much-needed update came after 12 years experience with the 2004 edition and many changes in machinery safety technology. Mr Nix briefly explored the many changes that were brought to Canadian machine builders in the new edition, including the many new references to ISO and IEC standards. These new references will help European machine builders get their products accepted in Canadian markets. Both Mr Vashi and Mr Nix sit on the CSA Technical Committee responsible for CSAZ432.
Reason #6 — Hot Questions
We like to over-deliver, so here’s the bonus reason!
We had some great questions posed by our attendees, two of which we are answering in video posts this week. If you have ever considered using a programmable safety system for lockout, our first video explains why this is not yet a possibility. Mr Nix gets into some of the reliability considerations behind the O.Reg. 851 Sections 75 and 76 and CSAZ460 requirements.
A case in the UK illustrates the dangers of bypassing interlocking systems. A worker was killed by a conveyor system in a pre-cast concrete plant when he was working in an area normally protected by a key-exchange system. Here’s the link to the article on OHSOnline.com. Allowing workers into the danger zone of a machine without other effective risk reduction measures may be a death sentence.
Original content here is published under these license terms:
X
License Type:
Non-commercial, Attribution, Share Alike
License Summary:
You may copy this content, create derivative work from it, and re-publish it for non-commercial purposes, provided you include an overt attribution to the author(s) and the re-publication must itself be under the terms of this license or similar.
There are two similar-sounding terms that people often get confused: Common Cause Failure (CCF) and Common Mode Failure. While these two types of failures sound similar, they are different. A Common Cause Failure is a failure in a system where two or more portions of the system fail at the same time from a single common cause. An example could be a lightning strike that causes a contactor to weld and simultaneously takes out the safety relay processor that controls the contactor. Common cause failures are therefore two different manners of failure in two different components, but with a single cause.
Common Mode Failure is where two components or portions of a system fail in the same way, at the same time. For example, two interposing relays both fail with welded contacts at the same time. The failures could be caused by the same cause or from different causes, but the way the components fail is the same.
Common-cause failure includes common mode failure, since a common cause can result in a common manner of failure in identical devices used in a system.
Here are the formal definitions of these terms:
3.1.6 common cause failure CCF
failures of different items, resulting from a single event, where these failures are not consequences of each other
Note 1 to entry: Common cause failures should not be confused with common mode failures (see ISO 12100:2010, 3.36). [SOURCE: IEC 60050?191-am1:1999, 04–23.] [1]
3.36 common mode failures
failures of items characterized by the same fault mode
NOTE Common mode failures should not be confused with common cause failures, as the common mode failures can result from different causes. [lEV 191–04-24] [3]
The “common mode” failure definition uses the phrase “fault mode”, so let’s look at that as well:
failure mode DEPRECATED: fault mode
manner in which failure occurs
Note 1 to entry: A failure mode may be defined by the function lost or other state transition that occurred. [IEV 192–03-17] [17]
As you can see, “fault mode” is no longer used, in favour of the more common “failure mode”, so it is possible to re-write the common-mode failure definition to read, “failures of items characterised by the same manner of failure.”
Random, Systematic and Common Cause Failures
Why do we need to care about this? There are three manners in which failures occur: random failures, systematic failures, and common cause failures. When developing safety related controls, we need to consider all three and mitigate them as much as possible.
Random failures do not follow any pattern, occurring randomly over time, and are often brought on by over-stressing the component, or from manufacturing flaws. Random failures can increase due to environmental or process-related stresses, like corrosion, EMI, normal wear-and-tear, or other over-stressing of the component or subsystem. Random failures are often mitigated through selection of high-reliability components [18].
Systematic failures include common-cause failures, and occur because some human behaviour occurred that was not caught by procedural means. These failures are due to design, specification, operating, maintenance, and installation errors. When we look at systematic errors, we are looking for things like training of the system designers, or quality assurance procedures used to validate the way the system operates. Systematic failures are non-random and complex, making them difficult to analyse statistically. Systematic errors are a significant source of common-cause failures because they can affect redundant devices, and because they are often deterministic, occurring whenever a set of circumstances exist.
Systematic failures include many types of errors, such as:
Manufacturing defects, e.g., software and hardware errors built into the device by the manufacturer.
Specification mistakes, e.g. incorrect design basis and inaccurate software specification.
Implementation errors, e.g., improper installation, incorrect programming, interface problems, and not following the safety manual for the devices used to realise the safety function.
Operation and maintenance, e.g., poor inspection, incomplete testing and improper bypassing [18].
Diverse redundancy is commonly used to mitigate systematic failures, since differences in component or subsystem design tend to create non-overlapping systematic failures, reducing the likelihood of a common error creating a common-mode failure. Errors in specification, implementation, operation and maintenance are not affected by diversity.
Fig 1 below shows the results of a small study done by the UK’s Health and Safety Executive in 1994 [19] that supports the idea that systematic failures are a significant contributor to safety system failures. The study included only 34 systems (n=34), so the results cannot be considered conclusive. However, there were some startling results. As you can see, errors in the specification of the safety functions (Safety Requirement Specification) resulted in about 44% of the system failures in the study. Based on this small sample, systematic failures appear to be a significate source of failures.
Figure 1 — HSG 238 Primary Causes of Failure by Life Cycle Stage
Handling CCF in ISO 13849–1
Now that we understand WHAT Common-Cause Failure is, and WHY it’s important, we can talk about HOW it is handled in ISO 13849–1. Since ISO 13849–1 is intended to be a simplified functional safety standard, CCF analysis is limited to a checklist in Annex F, Table F.1. Note that Annex F is informative, meaning that it is guidance material to help you apply the standard. Since this is the case, you could use any other means suitable for assessing CCF mitigation, like those in IEC 61508, or in other standards.
Table F.1 is set up with a series of mitigation measures which are grouped together in related categories. Each group is provided with a score that can be claimed if you have implemented the mitigations in that group. ALLOFTHEMEASURES in each group must be fulfilled in order to claim the points for that category. Here’s an example:
ISO 13849–1:2015, Table F.1 Excerpt
In order to claim the 20 points available for the use of separation or segregation in the system design, there must be a separation between the signal paths. Several examples of this are given for clarity.
Table F.1 lists six groups of mitigation measures. In order to claim adequate CCF mitigation, a minimum score of 65 points must be achieved. Only Category 2, 3 and 4 architectures are required to meet the CCF requirements in order to claim the PL, but without meeting the CCF requirement you cannot claim the PL, regardless of whether the design meets the other criteria or not.
One final note on CCF: If you are trying to review an existing control system, say in an existing machine, or in a machine designed by a third party where you have no way to determine the experience and training of the designers or the capability of the company’s change management process, then you cannot adequately assess CCF [8]. This fact is recognised in CSAZ432-16 [20], chapter 8. [20] allows the reviewer to simply verify that the architectural requirements, exclusive of any probabilistic requirements, have been met. This is particularly useful for engineers reviewing machinery under Ontario’s Pre-Start Health and Safety requirements [21], who are frequently working with less-than-complete design documentation.
In case you missed the first part of the series, you can read it here. In the next article in this series, I’m going to review the process flow for system analysis as currently outlined in ISO 13849–1. Watch for it!
Book List
Here are some books that I think you may find helpful on this journey:
[0.2] Electromagnetic Compatibility for Functional Safety, 1st ed. Stevenage, UK: The Institution of Engineering and Technology, 2008.
Note: This reference list starts in Part 1 of the series, so “missing” references may show in other parts of the series. The complete reference list is included in the last post of the series.
[18] M. Gentile and A. E. Summers, “Common Cause Failure: How Do You Manage Them?,” Process Saf. Prog., vol. 25, no. 4, pp. 331–338, 2006.
[19] Out of Control—Why control systems go wrong and how to prevent failure, 2nd ed. Richmond, Surrey, UK: HSE Health and Safety Executive, 2003.
Original content here is published under these license terms:
X
License Type:
Non-commercial, Attribution, Share Alike
License Summary:
You may copy this content, create derivative work from it, and re-publish it for non-commercial purposes, provided you include an overt attribution to the author(s) and the re-publication must itself be under the terms of this license or similar.
All original content on these pages is fingerprinted and certified by Digiprove
This website stores some user agent data. These data are used to provide a more personalized experience and to track your whereabouts around our website in compliance with the European General Data Protection Regulation. If you decide to opt-out of any future tracking, a cookie will be set up in your browser to remember this choice for one year. I Agree, Deny
