As promised in previous posts, here is the complete reference list for the series “How to do a 13849 – 1 analysis”! If you have any additional resources you think readers would find helpful, please add them in the comments.
Book List
Here are some books that I think you may find helpful on this journey:
Note: This reference list starts in Part 1 of the series, so “missing” references may show in other parts of the series. Included in the last post of the series is the complete reference list.
[17] “failure mode”, 192−03−17, International Electrotechnical Vocabulary. IEC International Electrotechnical Commission, Geneva, 2015.
[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.
ISO 13849 – 1, Chapter 7 [1, 7] discusses the need for fault consideration and fault exclusion. Fault consideration is the process of examining the components and sub-systems used in the safety-related part of the control system (SRP/CS) and making a list of all the faults that could occur in each one. This a definitely non-trivial exercise!
Thinking back to some of the earlier articles in this series where I mentioned the different types of faults, you may recall that there are detectable and undetectable faults, and there are safe and dangerous faults, leading us to four kinds of fault:
Safe undetectable faults
Dangerous undetectable faults
Safe detectable faults
Dangerous undetectable faults
For systems where no diagnostics are used, Category B and 1, faults need to be eliminated using inherently safe design techniques. Care needs to be taken when classifying components as “well-tried” versus using a fault exclusion, as components that might normally be considered “well-tried” might not meet those requirements in every application.
For systems where diagnostics are part of the design, i.e., Category 2, 3, and 4, the fault lists are used to evaluate the diagnostic coverage (DC) of the test systems. Depending on the architecture, certain levels of DC are required to meet the relevant PL, see [1, Fig. 5]. The fault lists are starting point for the determination of DC, and are an input into the hardware and software designs. All of the dangerous detectable faults must be covered by the diagnostics, and the DC must be high enough to meet the PLr. for the safety function.
The fault lists and fault exclusions are used in the Validation portion of this process as well. At the start of the Validation process flow chart [2, Fig. 1], you can see how the fault lists and the criteria used for fault exclusion are used as inputs to the validation plan.
Start of ISO 13849 – 2 Fig. 1
Faults that can be excluded do not need to validated, saving time and effort during the system verification and validation (V & V). How is this done?
Fault Consideration
The first step is to develop a list of potential faults that could occur, based on the components and subsystems included in SRP/CS. ISO 13849 – 2 [2] includes lists of typical faults for various technologies. For example, [2, Table A.4] is the fault list for mechanical components.
Stop (shut-off) valves/non-return (check) valves/quick-action venting valves/shuttle valves, etc.
Flow valves
Pressure valves
Pipework
Hose assemblies
Connectors
Pressure transmitters and pressure medium transducers
Compressed air treatment — Filters
Compressed-air treatment — Oilers
Compressed air treatment — Silencers
Accumulators and pressure vessels
Sensors
Fluidic Information processing — Logical elements
etc.
As you can see, there are many different types of faults that need to be considered. Keep in mind that I did not give you all of the different fault lists – this post would be a mile long if I did that! The point is that you need to develop a fault list for your system, and then consider the impact of each fault on the operation of the system. If you have components or subsystems that are not listed in the tables, then you need to develop your own fault lists for those items. Using Failure Modes and Effects Analysis (FMEA) techniques are usually the best approach for these components [23], [24].
When considering the faults to be included in the list there are a few things that should be considered [1, 7.2]:
if after the first fault occurs other faults develop due to the first fault, then you can group those faults together as a single fault
two or more single faults with a common cause can be considered as a single fault
multiple faults with different causes but occurring simultaneously is considered improbable and does not need to be considered
Examples
A voltage regulator fails in a system power supply so that the 24 Vdc output rises to an unregulated 36 Vdc (the internal power supply bus voltage), and after some time has passed, two sensors fail, then all three failures can be grouped and considered as a single fault.
If a lightning strike occurs on the power line and the resulting surge voltage on the 400 V mains causes an interposing contactor and the motor drive it controls to fail to danger, then these failures may be grouped and considered as one.
A pneumatic lubricator runs out of lubricant and is not refilled, depriving downstream pneumatic components of lubrication. The spool on the system dump valve sticks open because it is not cycled often enough. Neither of these failures has the same cause, so there is no need to consider them as occurring simultaneously because the probability of both happening concurrently is extremely small. One caution: These two faults MAY have a common cause – poor maintenance. Even if this is true and you decide to consider them to be two faults with a common cause, they could then be grouped as a single fault.
Fault Exclusion
Once you have your well-considered fault lists together, the next question is “Can any of the listed faults be excluded?” This is a tricky question! There are a few points to consider:
Does the system architecture allow for fault exclusion?
Is the fault technically improbable, even if it is possible?
Does experience show that the fault is unlikely to occur?*
Are there technical requirements related to the application and the hazard that might support fault exclusion?
* BECAREFUL with this one!
Whenever faults are excluded, a detailed justification for the exclusion needs to be included in the system design documentation. Simply deciding that the fault can be excluded is NOTENOUGH! Consider the risk a person will be exposed to in the event the fault occurs. If the severity is very high, i.e., severe permanent injury or death, you may not want to exclude the fault even if you think you could. Careful consideration of the resulting injury scenario is needed.
Basing a fault exclusion on personal experience is seldom considered adequate, which is why I added the asterisk (*) above. Look for good statistical data to support any decision to use a fault exclusion.
There is much more information available in IEC 61508 – 2 on the subject of fault exclusion, and there is good information in some of the books mentioned below [0.2], [0.3], and [0.4]. If you know of additional resources you would like to share, please post the information in the comments!
Definitions
3.1.3 fault
state of an item characterized by the inability to perform a required function, excluding the inability during preventive maintenance or other planned actions, or due to lack of external resources
Note 1 to entry: A fault is often the result of a failure of the item itself, but may exist without prior failure.
Note 2 to entry: In this part of ISO 13849, “fault” means random fault. [SOURCE: IEC 60050?191:1990, 05 – 01.]
Book List
Here are some books that I think you may find helpful on this journey:
Note: This reference list starts in Part 1 of the series, so “missing” references may show in other parts of the series. Included in the last post of the series is the complete reference list.
[17] “failure mode”, 192−03−17, International Electrotechnical Vocabulary. IEC International Electrotechnical Commission, Geneva, 2015.
[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.
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:
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.
[17] “failure mode”, 192−03−17, International Electrotechnical Vocabulary. IEC International Electrotechnical Commission, Geneva, 2015.
[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.
As promised in previous posts, here is the complete reference list for the series “How to do a 13849 – 1 analysis”! If you have any additional resources you think readers would find helpful, please add them in the comments.
