Machinery Safety 101

ISO 13849 – 1 Analysis — Part 6: CCF — Common Cause Failures

This entry is part 6 of 9 in the series How to do a 13849 – 1 analysis

Post updated 2019-07-24. Ed.

What is a “Common Cause Failure”?

There are two sim­il­ar-sound­ing terms that people often get con­fused: Com­mon Cause Fail­ure (CCF) and Com­mon Mode Fail­ure. While these two types of fail­ures sound sim­il­ar, they are dif­fer­ent. A Com­mon Cause Fail­ure is a fail­ure in a sys­tem where two or more por­tions of the sys­tem fail at the same time from a single com­mon cause. An example could be a light­ning strike that causes a con­tact­or to weld and sim­ul­tan­eously takes out the safety relay pro­cessor that con­trols the con­tact­or. Com­mon cause fail­ures are there­fore two dif­fer­ent man­ners of fail­ure in two dif­fer­ent com­pon­ents, but with a single cause.

Com­mon Mode Fail­ure is where two com­pon­ents or por­tions of a sys­tem fail in the same way, at the same time. For example, two inter­pos­ing relays both fail with wel­ded con­tacts at the same time. The fail­ures could be caused by the same cause or from dif­fer­ent causes, but the way the com­pon­ents fail is the same.

Com­mon-cause fail­ure includes com­mon mode fail­ure, since a com­mon cause can res­ult in a com­mon man­ner of fail­ure in identic­al devices used in a system.

Here are the form­al defin­i­tions of these terms:

3.1.6 com­mon cause fail­ure CCF

fail­ures of dif­fer­ent items, res­ult­ing from a single event, where these fail­ures are not con­sequences of each other

Note 1 to entry: Com­mon cause fail­ures should not be con­fused with com­mon mode fail­ures (see ISO 12100:2010, 3.36). [SOURCE: IEC 60050?191-am1:1999, 04 – 23.] [1]

3.36 com­mon mode failures

fail­ures of items char­ac­ter­ized by the same fault mode

NOTE Com­mon mode fail­ures should not be con­fused with com­mon cause fail­ures, as the com­mon mode fail­ures can res­ult from dif­fer­ent causes. [lEV 191 – 04-24] [3]

The “com­mon mode” fail­ure defin­i­tion uses the phrase “fault mode”, so let’s look at that as well:

fail­ure mode
DEPRECATED: fault mode
man­ner in which fail­ure occurs

Note 1 to entry: A fail­ure mode may be defined by the func­tion lost or oth­er state trans­ition that occurred. [IEV 192 – 03-17] [17]

As you can see, “fault mode” is no longer used, in favour of the more com­mon “fail­ure mode”, so it is pos­sible to re-write the com­mon-mode fail­ure defin­i­tion to read, “fail­ures of items char­ac­ter­ised by the same man­ner of failure.”

Random, Systematic and Common Cause Failures

Why do we need to care about this? There are three man­ners in which fail­ures occur: ran­dom fail­ures, sys­tem­at­ic fail­ures, and com­mon cause fail­ures. When devel­op­ing safety related con­trols, we need to con­sider all three and mit­ig­ate them as much as possible.

Ran­dom fail­ures do not fol­low any pat­tern, occur­ring ran­domly over time, and are often brought on by over-stress­ing the com­pon­ent, or from man­u­fac­tur­ing flaws. Ran­dom fail­ures can increase due to envir­on­ment­al or pro­cess-related stresses, like cor­ro­sion, EMI, nor­mal wear-and-tear, or oth­er over-stress­ing of the com­pon­ent or sub­sys­tem. Ran­dom fail­ures are often mit­ig­ated through selec­tion of high-reli­ab­il­ity com­pon­ents [18].

Sys­tem­at­ic fail­ures include com­mon-cause fail­ures, and occur because some human beha­viour occurred that was not caught by pro­ced­ur­al means. These fail­ures are due to design, spe­cific­a­tion, oper­at­ing, main­ten­ance, and install­a­tion errors. When we look at sys­tem­at­ic errors, we are look­ing for things like train­ing of the sys­tem design­ers, or qual­ity assur­ance pro­ced­ures used to val­id­ate the way the sys­tem oper­ates. Sys­tem­at­ic fail­ures are non-ran­dom and com­plex, mak­ing them dif­fi­cult to ana­lyse stat­ist­ic­ally. Sys­tem­at­ic errors are a sig­ni­fic­ant source of com­mon-cause fail­ures because they can affect redund­ant devices, and because they are often determ­in­ist­ic, occur­ring whenev­er a set of cir­cum­stances exist.

Sys­tem­at­ic fail­ures include many types of errors, such as:

  • Man­u­fac­tur­ing defects, e.g., soft­ware and hard­ware errors built into the device by the manufacturer.
  • Spe­cific­a­tion mis­takes, e.g. incor­rect design basis and inac­cur­ate soft­ware specification.
  • Imple­ment­a­tion errors, e.g., improp­er install­a­tion, incor­rect pro­gram­ming, inter­face prob­lems, and not fol­low­ing the safety manu­al for the devices used to real­ise the safety function.
  • Oper­a­tion and main­ten­ance, e.g., poor inspec­tion, incom­plete test­ing and improp­er bypassing [18].

Diverse redund­ancy is com­monly used to mit­ig­ate sys­tem­at­ic fail­ures, since dif­fer­ences in com­pon­ent or sub­sys­tem design tend to cre­ate non-over­lap­ping sys­tem­at­ic fail­ures, redu­cing the like­li­hood of a com­mon error cre­at­ing a com­mon-mode fail­ure. Errors in spe­cific­a­tion, imple­ment­a­tion, oper­a­tion and main­ten­ance are not affected by diversity.

Fig 1 below shows the res­ults of a small study done by the UK’s Health and Safety Exec­ut­ive in 1994 [19] that sup­ports the idea that sys­tem­at­ic fail­ures are a sig­ni­fic­ant con­trib­ut­or to safety sys­tem fail­ures. The study included only 34 sys­tems (n=34), so the res­ults can­not be con­sidered con­clus­ive. How­ever, there were some start­ling res­ults. As you can see, errors in the spe­cific­a­tion of the safety func­tions (Safety Require­ment Spe­cific­a­tion) res­ul­ted in about 44% of the sys­tem fail­ures in the study. Based on this small sample, sys­tem­at­ic fail­ures appear to be a sig­ni­fic­ate source of failures.

Pie chart illustrating the proportion of failures in each phase of the life cycle of a machine, based on data taken from HSE Report HSG238.
Fig­ure 1 – HSG 238 Primary Causes of Fail­ure by Life Cycle Stage

Handling CCF in ISO 13849 – 1

Now that we under­stand WHAT Com­mon-Cause Fail­ure is, and WHY it’s import­ant, we can talk about HOW it is handled in ISO 13849 – 1. Since ISO 13849 – 1 is inten­ded to be a sim­pli­fied func­tion­al safety stand­ard, CCF ana­lys­is is lim­ited to a check­list in Annex F, Table F.1. Note that Annex F is inform­at­ive, mean­ing that it is guid­ance mater­i­al to help you apply the stand­ard. Since this is the case, you could use any oth­er means suit­able for assess­ing CCF mit­ig­a­tion, like those in IEC 61508, or in oth­er standards.

Table F.1 is set up with a series of mit­ig­a­tion meas­ures which are grouped togeth­er in related cat­egor­ies. Each group is provided with a score that can be claimed if you have imple­men­ted the mit­ig­a­tion in that group. The meas­ures lis­ted in each group are examples of meas­ures that could be used to claim the points for that cat­egory. You can use oth­er meth­ods that will achieve the same res­ults as the examples giv­en in the table.

Here’s an excerpt:

A portion of ISO 13849-1 Table F.1.
Excerpt from ISO 13849 – 1:2015, Table F.1

In order to claim the 15 points avail­able for the use of sep­ar­a­tion or segreg­a­tion in the sys­tem design, there must be a sep­ar­a­tion between the sig­nal paths. Sev­er­al examples of this are giv­en for clarity.

Table F.1 lists six groups of mit­ig­a­tion meas­ures. In order to claim adequate CCF mit­ig­a­tion, a min­im­um score of 65 points must be achieved. Only Cat­egory 2, 3 and 4 archi­tec­tures are required to meet the CCF require­ments in order to claim the PL, but without meet­ing the CCF require­ment you can­not claim the PL, regard­less of wheth­er the design meets the oth­er cri­ter­ia or not.

One final note on CCF: If you are try­ing to review an exist­ing con­trol sys­tem, say in an exist­ing machine, or in a machine designed by a third party where you have no way to determ­ine the exper­i­ence and train­ing of the design­ers or the cap­ab­il­ity of the com­pany’s change man­age­ment pro­cess, then you can­not adequately assess CCF [8]. This fact is recog­nised in CSA Z432-16 [20], chapter 8. [20] allows the review­er to simply veri­fy that the archi­tec­tur­al require­ments, exclus­ive of any prob­ab­il­ist­ic require­ments, have been met. This is par­tic­u­larly use­ful for engin­eers review­ing machinery under Ontari­o’s Pre-Start Health and Safety require­ments [21], who are fre­quently work­ing with less-than-com­plete design documentation.

In case you missed the first part of the series, you can read it here. In the next art­icle in this series, I’m going to review the pro­cess flow for sys­tem ana­lys­is as cur­rently out­lined in ISO 13849 – 1. Watch for it!

Book List

Here are some books that I think you may find help­ful on this journey:

[0]     B. Main, Risk Assess­ment: Basics and Bench­marks, 1st ed. Ann Arbor, MI USA: DSE, 2004.

[0.1]  D. Smith and K. Simpson, Safety crit­ic­al sys­tems hand­book. Ams­ter­dam: Elsevi­er­/But­ter­worth-Heine­mann, 2011.

[0.2]  Elec­tro­mag­net­ic Com­pat­ib­il­ity for Func­tion­al Safety, 1st ed. Steven­age, UK: The Insti­tu­tion of Engin­eer­ing and Tech­no­logy, 2008.

[0.3] Over­view of tech­niques and meas­ures related to EMC for Func­tion­al Safety, 1st ed. Steven­age, UK: Over­view of tech­niques and meas­ures related to EMC for Func­tion­al Safety, 2013.

[0.4] “Code of prac­tice for elec­tro­mag­net­ic resi­li­ence, 1st ed. Steven­age, UK: IET Stand­ards TC4.3 EMC, 2017.

[0.5] “Code of Prac­tice: Com­pet­ence for Safety Related Sys­tems Prac­ti­tion­ers, 1st ed. Steven­age, UK: The Insti­tu­tion of Engin­eer­ing and Tech­no­logy, 2016.


Note: This ref­er­ence list starts in Part 1 of the series, so “miss­ing” ref­er­ences may show in oth­er parts of the series. The com­plete ref­er­ence list is included in the last post of the series.

[1]     Safety of machinery — Safety-related parts of con­trol sys­tems — Part 1: Gen­er­al prin­ciples for design. 3rd Edi­tion. ISO Stand­ard 13849 – 1. 2015.

[2]     Safety of machinery – Safety-related parts of con­trol sys­tems – Part 2: Val­id­a­tion. 2nd Edi­tion. ISO Stand­ard 13849 – 2. 2012.

[3]      Safety of machinery – Gen­er­al prin­ciples for design – Risk assess­ment and risk reduc­tion. ISO Stand­ard 12100. 2010.

[8]     S. Jocelyn, J. Bau­doin, Y. Chin­ni­ah, and P. Char­pen­ti­er, “Feas­ib­il­ity study and uncer­tain­ties in the val­id­a­tion of an exist­ing safety-related con­trol cir­cuit with the ISO 13849 – 1:2006 design stand­ard,” Reliab. Eng. Syst. Saf., vol. 121, pp. 104 – 112, Jan. 2014.

[17]      “fail­ure mode”, 192 – 03-17, Inter­na­tion­al Elec­tro­tech­nic­al Vocab­u­lary. IEC Inter­na­tion­al Elec­tro­tech­nic­al Com­mis­sion, Geneva, 2015.

[18]      M. Gen­tile and A. E. Sum­mers, “Com­mon Cause Fail­ure: How Do You Man­age Them?,” Pro­cess Saf. Prog., vol. 25, no. 4, pp. 331 – 338, 2006.

[19]     Out of Con­trol — Why con­trol sys­tems go wrong and how to pre­vent fail­ure, 2nd ed. Rich­mond, Sur­rey, UK: HSE Health and Safety Exec­ut­ive, 2003.

[20]     Safe­guard­ing of Machinery. 3rd Edi­tion. CSA Stand­ard Z432. 2016.

[21]     O. Reg. 851, INDUSTRIAL ESTABLISHMENTS. Ontario, Canada, 1990.

Series Nav­ig­a­tionISO 13849 – 1 Ana­lys­is — Part 5: Dia­gnost­ic Cov­er­age (DC)”>ISO 13849 – 1 Ana­lys­is — Part 5: Dia­gnost­ic Cov­er­age (DC)ISO 13849 – 1 Ana­lys­is — Part 7: Safety-Related Soft­ware”>ISO 13849 – 1 Ana­lys­is — Part 7: Safety-Related Software

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.