ISO 13849 – 1 Analysis — Part 8: Fault Exclusion

This entry is part of 9 in the series How to do a 13849 – 1 ana­lys­is

Fault Consideration & Fault Exclusion

ISO 13849 – 1, Chapter 7 [1, 7] dis­cusses the need for fault con­sid­er­a­tion and fault exclu­sion. Fault con­sid­er­a­tion is the pro­cess of examin­ing the com­pon­ents and sub-​systems used in the safety-​related part of the con­trol sys­tem (SRP/​CS) and mak­ing a list of all the faults that could occur in each one. This a def­in­itely non-​trivial exer­cise!

Thinking back to some of the earli­er art­icles in this series where I men­tioned the dif­fer­ent types of faults, you may recall that there are detect­able and undetect­able faults, and there are safe and dan­ger­ous faults, lead­ing us to four kinds of fault:

  • Safe undetect­able faults
  • Dangerous undetect­able faults
  • Safe detect­able faults
  • Dangerous undetect­able faults

For sys­tems where no dia­gnostics are used, Category B and 1, faults need to be elim­in­ated using inher­ently safe design tech­niques. Care needs to be taken when clas­si­fy­ing com­pon­ents as “well-​tried” versus using a fault exclu­sion, as com­pon­ents that might nor­mally be con­sidered “well-​tried” might not meet those require­ments in every applic­a­tion.

For sys­tems where dia­gnostics are part of the design, i.e., Category 2, 3, and 4, the fault lists are used to eval­u­ate the dia­gnost­ic cov­er­age (DC) of the test sys­tems. Depending on the archi­tec­ture, cer­tain levels of DC are required to meet the rel­ev­ant PL, see [1, Fig. 5]. The fault lists are start­ing point for the determ­in­a­tion of DC, and are an input into the hard­ware and soft­ware designs. All of the dan­ger­ous detect­able faults must be covered by the dia­gnostics, and the DC must be high enough to meet the PLr. for the safety func­tion.

The fault lists and fault exclu­sions are used in the Validation por­tion of this pro­cess as well. At the start of the Validation pro­cess flow chart [2, Fig. 1], you can see how the fault lists and the cri­ter­ia used for fault exclu­sion are used as inputs to the val­id­a­tion plan.

The diagram shows the first few stages in the ISO 13849-2 Validation process. See ISO 13849-2, Figure 1.
Start of ISO 13849 – 2 Fig. 1

Faults that can be excluded do not need to val­id­ated, sav­ing time and effort dur­ing the sys­tem veri­fic­a­tion and val­id­a­tion (V & V). How is this done?

Fault Consideration

The first step is to devel­op a list of poten­tial faults that could occur, based on the com­pon­ents and sub­sys­tems included in SRP/​CS. ISO 13849 – 2 [2] includes lists of typ­ic­al faults for vari­ous tech­no­lo­gies. For example, [2, Table A.4] is the fault list for mech­an­ic­al com­pon­ents.

Mechanical fault list from ISO 13849-2
Table A.4 — Faults and fault exclu­sions — Mechanical devices, com­pon­ents and ele­ments
(e.g. cam, fol­low­er, chain, clutch, brake, shaft, screw, pin, guide, bear­ing)

[2] con­tains tables sim­il­ar to Table A.4 for:

  • Pressure-​coil springs
  • Directional con­trol valves
  • Stop (shut-​off) valves/​non-​return (check) valves/​quick-​action vent­ing valves/​shuttle valves, etc.
  • Flow valves
  • Pressure valves
  • Pipework
  • Hose assem­blies
  • Connectors
  • Pressure trans­mit­ters and pres­sure medi­um trans­ducers
  • Compressed air treat­ment — Filters
  • Compressed-​air treat­ment — Oilers
  • Compressed air treat­ment — Silencers
  • Accumulators and pres­sure ves­sels
  • Sensors
  • Fluidic Information pro­cessing — Logical ele­ments
  • etc.

As you can see, there are many dif­fer­ent types of faults that need to be con­sidered. Keep in mind that I did not give you all of the dif­fer­ent fault lists – this post would be a mile long if I did that! The point is that you need to devel­op a fault list for your sys­tem, and then con­sider the impact of each fault on the oper­a­tion of the sys­tem. If you have com­pon­ents or sub­sys­tems that are not lis­ted in the tables, then you need to devel­op your own fault lists for those items. Using Failure Modes and Effects Analysis (FMEA) tech­niques are usu­ally the best approach for these com­pon­ents [23], [24].

When con­sid­er­ing the faults to be included in the list there are a few things that should be con­sidered [1, 7.2]:

  • if after the first fault occurs oth­er faults devel­op due to the first fault, then you can group those faults togeth­er as a single fault
  • two or more single faults with a com­mon cause can be con­sidered as a single fault
  • mul­tiple faults with dif­fer­ent causes but occur­ring sim­ul­tan­eously is con­sidered improb­able and does not need to be con­sidered

Examples

A voltage reg­u­lat­or fails in a sys­tem power sup­ply so that the 24 Vdc out­put rises to an unreg­u­lated 36 Vdc (the intern­al power sup­ply bus voltage), and after some time has passed, two sensors fail, then all three fail­ures can be grouped and con­sidered as a single fault.

If a light­ning strike occurs on the power line and the res­ult­ing surge voltage on the 400 V mains causes an inter­pos­ing con­tact­or and the motor drive it con­trols to fail to danger, then these fail­ures may be grouped and con­sidered as one.

A pneu­mat­ic lub­ric­at­or runs out of lub­ric­ant and is not refilled, depriving down­stream pneu­mat­ic com­pon­ents of lub­ric­a­tion. The spool on the sys­tem dump valve sticks open because it is not cycled often enough. Neither of these fail­ures has the same cause, so there is no need to con­sider them as occur­ring sim­ul­tan­eously because the prob­ab­il­ity of both hap­pen­ing con­cur­rently is extremely small. One cau­tion: These two faults MAY have a com­mon cause – poor main­ten­ance. Even if this is true and you decide to con­sider them to be two faults with a com­mon cause, they could then be grouped as a single fault.

Fault Exclusion

Once you have your well-​considered fault lists togeth­er, the next ques­tion is “Can any of the lis­ted faults be excluded?” This is a tricky ques­tion! There are a few points to con­sider:

  • Does the sys­tem archi­tec­ture allow for fault exclu­sion?
  • Is the fault tech­nic­ally improb­able, even if it is pos­sible?
  • Does exper­i­ence show that the fault is unlikely to occur?*
  • Are there tech­nic­al require­ments related to the applic­a­tion and the haz­ard that might sup­port fault exclu­sion?

BE CAREFUL with this one!

Whenever faults are excluded, a detailed jus­ti­fic­a­tion for the exclu­sion needs to be included in the sys­tem design doc­u­ment­a­tion. Simply decid­ing that the fault can be excluded is NOT ENOUGH! Consider the risk a per­son will be exposed to in the event the fault occurs. If the sever­ity is very high, i.e., severe per­man­ent injury or death, you may not want to exclude the fault even if you think you could. Careful con­sid­er­a­tion of the res­ult­ing injury scen­ario is needed.

Basing a fault exclu­sion on per­son­al exper­i­ence is sel­dom con­sidered adequate, which is why I added the aster­isk (*) above. Look for good stat­ist­ic­al data to sup­port any decision to use a fault exclu­sion.

There is much more inform­a­tion avail­able in IEC 61508 – 2 on the sub­ject of fault exclu­sion, and there is good inform­a­tion in some of the books men­tioned below [0.2], [0.3], and [0.4]. If you know of addi­tion­al resources you would like to share, please post the inform­a­tion in the com­ments!

Definitions

3.1.3 fault
state of an item char­ac­ter­ized by the inab­il­ity to per­form a required func­tion, exclud­ing the inab­il­ity dur­ing pre­vent­ive main­ten­ance or oth­er planned actions, or due to lack of extern­al resources
Note 1 to entry: A fault is often the res­ult of a fail­ure of the item itself, but may exist without pri­or fail­ure.
Note 2 to entry: In this part of ISO 13849, “fault” means ran­dom fault. [SOURCE: IEC 60050?191:1990, 05 – 01.]

Book List

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

[0]     B. Main, Risk Assessment: Basics and Benchmarks, 1st ed. Ann Arbor, MI USA: DSE, 2004.

[0.1]  D. Smith and K. Simpson, Safety crit­ic­al sys­tems hand­book. Amsterdam: Elsevier/​Butterworth-​Heinemann, 2011.

[0.2]  Electromagnetic Compatibility for Functional Safety, 1st ed. Stevenage, UK: The Institution of Engineering and Technology, 2008.

[0.3]  Overview of tech­niques and meas­ures related to EMC for Functional Safety, 1st ed. Stevenage, UK: Overview of tech­niques and meas­ures related to EMC for Functional Safety, 2013.

References

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. Included in the last post of the series is the com­plete ref­er­ence list.

[1]     Safety of machinery — Safety-​related parts of con­trol sys­tems — Part 1: General prin­ciples for design. 3rd Edition. ISO Standard 13849 – 1. 2015.

[2]     Safety of machinery – Safety-​related parts of con­trol sys­tems – Part 2: Validation. 2nd Edition. ISO Standard 13849 – 2. 2012.

[3]      Safety of machinery – General prin­ciples for design – Risk assess­ment and risk reduc­tion. ISO Standard 12100. 2010.

[4]     Safeguarding of Machinery. 2nd Edition. CSA Standard Z432. 2004.

[5]     Risk Assessment and Risk Reduction- A Guideline to Estimate, Evaluate and Reduce Risks Associated with Machine Tools. ANSI Technical Report B11.TR3. 2000.

[6]    Safety of machinery – Emergency stop func­tion – Principles for design. ISO Standard 13850. 2015.

[7]     Functional safety of electrical/​electronic/​programmable elec­tron­ic safety-​related sys­tems. 7 parts. IEC Standard 61508. Edition 2. 2010.

[8]     S. Jocelyn, J. Baudoin, Y. Chinniah, and P. Charpentier, “Feasibility 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.

[9]    Guidance on the applic­a­tion of ISO 13849 – 1 and IEC 62061 in the design of safety-​related con­trol sys­tems for machinery. IEC Technical Report TR 62061 – 1. 2010.

[10]     Safety of machinery – Functional safety of safety-​related elec­tric­al, elec­tron­ic and pro­gram­mable elec­tron­ic con­trol sys­tems. IEC Standard 62061. 2005.

[11]    Guidance on the applic­a­tion of ISO 13849 – 1 and IEC 62061 in the design of safety-​related con­trol sys­tems for machinery. IEC Technical Report 62061 – 1. 2010.

[12]    D. S. G. Nix, Y. Chinniah, F. Dosio, M. Fessler, F. Eng, and F. Schrever, “Linking Risk and Reliability — Mapping the out­put of risk assess­ment tools to func­tion­al safety require­ments for safety related con­trol sys­tems,” 2015.

[13]    Safety of machinery. Safety related parts of con­trol sys­tems. General prin­ciples for design. CEN Standard EN 954 – 1. 1996.

[14]   Functional safety of electrical/​electronic/​programmable elec­tron­ic safety-​related sys­tems – Part 2: Requirements for electrical/​electronic/​programmable elec­tron­ic safety-​related sys­tems. IEC Standard 61508 – 2. 2010.

[15]     Reliability Prediction of Electronic Equipment. Military Handbook MIL-​HDBK-​217F. 1991.

[16]     “IFA – Practical aids: Software-​Assistent SISTEMA: Safety Integrity – Software Tool for the Evaluation of Machine Applications”, Dguv​.de, 2017. [Online]. Available: http://​www​.dguv​.de/​i​f​a​/​p​r​a​x​i​s​h​i​l​f​e​n​/​p​r​a​c​t​i​c​a​l​-​s​o​l​u​t​i​o​n​s​-​m​a​c​h​i​n​e​-​s​a​f​e​t​y​/​s​o​f​t​w​a​r​e​-​s​i​s​t​e​m​a​/​i​n​d​e​x​.​jsp. [Accessed: 30- Jan- 2017].

[17]      “fail­ure 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 con­trol sys­tems go wrong and how to pre­vent fail­ure, 2nd ed. Richmond, Surrey, UK: HSE Health and Safety Executive, 2003.

[20]     Safeguarding of Machinery. 3rd Edition. CSA Standard Z432. 2016.

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

[22]     “Field-​programmable gate array”, En​.wiki​pe​dia​.org, 2017. [Online]. Available: https://​en​.wiki​pe​dia​.org/​w​i​k​i​/​F​i​e​l​d​-​p​r​o​g​r​a​m​m​a​b​l​e​_​g​a​t​e​_​a​r​ray. [Accessed: 16-​Jun-​2017].

[23]     Analysis tech­niques for sys­tem reli­ab­il­ity – Procedure for fail­ure mode and effects ana­lys­is (FMEA). 2nd Ed. IEC Standard 60812. 2006.

[24]     “Failure mode and effects ana­lys­is”, En​.wiki​pe​dia​.org, 2017. [Online]. Available: https://​en​.wiki​pe​dia​.org/​w​i​k​i​/​F​a​i​l​u​r​e​_​m​o​d​e​_​a​n​d​_​e​f​f​e​c​t​s​_​a​n​a​l​y​sis. [Accessed: 16-​Jun-​2017].

ISO 13849 – 1 Analysis — Part 7: Safety-​Related Software

This entry is part 7 of 9 in the series How to do a 13849 – 1 ana­lys­is

Safety-​Related Software

Up to this point, I have been dis­cuss­ing the basic pro­cesses used for the design of safety-​related parts of con­trol sys­tems. The under­ly­ing assump­tion is that these tech­niques apply to the design of hard­ware used for safety pur­poses. The remain­ing ques­tion focuses on the design and devel­op­ment of safety-​related soft­ware that runs on that hard­ware. If you have not read the rest of this series and would like to catch up first, you can find it here.

In this dis­cus­sion of safety-​related soft­ware, keep in mind that I am talk­ing about soft­ware that is only inten­ded to reduce risk. Some plat­forms that are not well suited for safety soft­ware, primar­ily com­mon off-​the-​shelf (COTS) oper­at­ing sys­tems like Windows, MacOS and Linux. Generally speak­ing, these oper­at­ing sys­tems are too com­plex and sub­ject to unanti­cip­ated changes to be suit­able for high-​reliability applic­a­tions. There is noth­ing wrong with using these sys­tems for annun­ci­ation and mon­it­or­ing func­tions, but the safety func­tions should run on more pre­dict­able plat­forms.

The meth­od­o­logy dis­cussed in ISO 13849 – 1 is usable up to PLd. At the end of the Scope we find Note 4:

NOTE 4 For safety-​related embed­ded soft­ware for com­pon­ents with PLr = e, see IEC 61508 – 3:1998, Clause 7.

As you can see, for very high-​reliability sys­tems, i.e., PLe/​SIL3 or SIL4, it is neces­sary to move to IEC 61508. The meth­ods dis­cussed here are based on ISO 13849 – 1:2015, Chapter 4.6.

Goals

There are two goals for safety-​related soft­ware devel­op­ment activ­it­ies:

  1. Avoid faults
  2. Generate read­able, under­stand­able, test­able and main­tain­able soft­ware

Avoiding Faults

Fig. 1 [1, Fig. 6] shows the “V-​model” for soft­ware devel­op­ment. This approach to soft­ware design incor­por­ates both val­id­a­tion and veri­fic­a­tion, and when cor­rectly imple­men­ted will res­ult in soft­ware that meets the design spe­cific­a­tions.

If you aren’t sure what the dif­fer­ence is between veri­fic­a­tion and val­id­a­tion, I remem­ber it is this way: Validation means “Are we build­ing the right thing?”, and veri­fic­a­tion means “Did we build the thing right?” The whole pro­cess hinges on the Safety Requirement Specification (SRS), so fail­ing to get that part of the pro­cess right in the begin­ning will neg­at­ively impact both hard­ware and soft­ware design. The SRS is the yard­stick used to decide if you built the right thing. Without that, you are clue­less about what you are build­ing.

Simplified V-model of software safety lifecycle
Figure 1 — Simplified V-​model of soft­ware safety life­cycle

Coming in from the Safety Requirement Specification (also called the safety func­tion spe­cific­a­tion), each step in the pro­cess is shown. The dashed lines illus­trate the veri­fic­a­tion pro­cess at each step. Notice that the actu­al cod­ing step is at the bot­tom of the V-​model. Everything above the cod­ing stage is either plan­ning and design, or qual­ity assur­ance activ­it­ies.

There are oth­er meth­ods that can be used to res­ult in veri­fied and val­id­ated soft­ware, so if you have a QA pro­cess that pro­duces sol­id res­ults, you may not need to change it. I would recom­mend that you review all the stages in the V-​model to ensure that your QA sys­tem has sim­il­ar pro­cesses.

To make set­ting up safety sys­tems sim­pler for design­ers and integ­rat­ors, there are two approaches to soft­ware design that can be used.

Two Approaches to Software Design

There are two approaches to soft­ware design that should be con­sidered:

  • Preconfigured (building-​block style) soft­ware
  • Fully cus­tom­ised soft­ware

Preconfigured Building-​Block Software

The pre­con­figured building-​block approach is typ­ic­ally used for con­fig­ur­ing safety PLCs or pro­gram­mable safety relays or mod­ules. This type of soft­ware is referred to as “safety-​related embed­ded soft­ware (SRESW)” in [1].

Pre-​written func­tion blocks are provided by the device man­u­fac­turer. Each func­tion block has a par­tic­u­lar role: emer­gency stop, safety gate input, zero-​speed detec­tion, and so on. When con­fig­ur­ing a safety PLC or safety mod­ules that use this approach, the design­er selects the appro­pri­ate block and then con­fig­ures the inputs, out­puts, and any oth­er func­tion­al char­ac­ter­ist­ics that are needed. The design­er has no access to the safety-​related code, so apart from con­fig­ur­a­tion errors, no oth­er errors can be intro­duced. The func­tion blocks are veri­fied and val­id­ated (V & V) by the con­trols com­pon­ent man­u­fac­turer, usu­ally with the sup­port of an accred­ited cer­ti­fic­a­tion body. The func­tion blocks will nor­mally have a PL asso­ci­ated with them, and a state­ment like “suit­able for PLe” will be made in the func­tion block descrip­tion.

This approach elim­in­ates the need to do a detailed V & V of the code by the design­ing entity (i.e., the machine build­er). However, the machine build­er is still required to do a V & V on the oper­a­tion of the sys­tem as they have con­figured it. The machine V & V includes all the usu­al fault injec­tion tests and func­tion­al tests to ensure that the sys­tem will behave in as inten­ded in the pres­ence of a demand on the safety func­tion or a fault con­di­tion. The faults that should be tested are those in your Fault List. If you don’t have a fault list or don’t know what a Fault List is, see Part 8 in this series.

Using pre-​configured build­ing blocks achieves the first goal, fault avoid­ance, at least as far as the soft­ware cod­ing is con­cerned. The con­fig­ur­a­tion soft­ware will val­id­ate the func­tion block con­fig­ur­a­tions before com­pil­ing the soft­ware for upload to the safety con­trol­ler so that most con­fig­ur­a­tion errors will be caught at that stage.

This approach also facil­it­ates the second goal, as long as the con­fig­ur­a­tion soft­ware is usable and main­tained by the soft­ware vendor. The con­fig­ur­a­tion soft­ware usu­ally includes the abil­ity to annot­ate the con­fig­ur­a­tions with rel­ev­ant details to assist with the read­ab­il­ity and under­stand­ab­il­ity of the soft­ware.

Fully Customised Software

This approach is used where a fully cus­tom­ised hard­ware plat­form is being used, and the safety soft­ware is designed to run on that plat­form. [1] refers to this type of soft­ware as “Safety-​related applic­a­tion soft­ware (SRASW).” A fully cus­tom­ised soft­ware applic­a­tion is used where a very spe­cial­ised safety sys­tem is con­tem­plated, and FPGAs or oth­er cus­tom­ised hard­ware is being used. These sys­tems are usu­ally pro­grammed using full-​variability lan­guages.

In this case, the full hard­ware and soft­ware V & V approach must be employed. In my opin­ion, ISO 13849 – 1 is prob­ably not the best choice for this approach due to its sim­pli­fic­a­tion, and I would usu­ally recom­mend using IEC 61508 – 3 as the basis for the design, veri­fic­a­tion, and val­id­a­tion of fully cus­tom­ised soft­ware.

Process requirements

Safety-​Related Embedded Software (SRESW)

[1, 4.6.2] provides a laun­dry list of ele­ments that must be incor­por­ated into the V-​model pro­cesses when devel­op­ing SRESW, broken down by PLa through PLd, and then some addi­tion­al require­ments for PLc and PLd.

If you are design­ing SRESW for PLe, [1, 4.6.2] points you dir­ectly to IEC 61508 – 3, clause 7, which cov­ers soft­ware suit­able for SIL3 applic­a­tions.

Safety-​Related Application Software (SRASW)

[1, 4.6.3] provides a list of require­ments that must be met through the v-​model pro­cess for SRASW, and allows that PLa through PLe can be met by code writ­ten in LVL and that PLe applic­a­tions can also be designed using FVL. In cases where soft­ware is developed using  FVL, the soft­ware can be treated as the embed­ded soft­ware products (SRESW) are handled.

A sim­il­ar archi­tec­tur­al mod­el to that used for single-​channel hard­ware devel­op­ment is used, as shown in Fig. 2  [1, Fig 7].

General architecture model of software
Figure 2 — General archi­tec­ture mod­el of soft­ware

The com­plete V-​model must be applied to safety-​related applic­a­tion soft­ware, with all of the addi­tion­al require­ments from [1, 4.6.3] included in the pro­cess mod­el.

Conclusions

There is a lot to safety-​related soft­ware devel­op­ment, cer­tainly much more than could be dis­cussed in a blog post like this or even in a stand­ard like ISO 13849 – 1. If you are con­tem­plat­ing devel­op­ing safety related soft­ware and you are not famil­i­ar with the tech­niques needed to devel­op this kind of high-​reliability soft­ware, I would sug­gest you get help from a qual­i­fied developer. Keep in mind that there can be sig­ni­fic­ant liab­il­ity attached to safety sys­tem fail­ures, includ­ing the deaths of people using your product. If you are devel­op­ing SRASW, I would also recom­mend fol­low­ing IEC 61508 – 3 as the basis for the devel­op­ment and related QA pro­cesses.

 Definitions

3.1.36 applic­a­tion soft­ware
soft­ware spe­cif­ic to the applic­a­tion, imple­men­ted by the machine man­u­fac­turer, and gen­er­ally con­tain­ing logic sequences, lim­its and expres­sions that con­trol the appro­pri­ate inputs, out­puts, cal­cu­la­tions and decisions neces­sary to meet the SRP/​CS require­ments 3.1.37 embed­ded soft­ware firm­ware sys­tem soft­ware soft­ware that is part of the sys­tem sup­plied by the con­trol man­u­fac­turer and which is not access­ible for modi­fic­a­tion by the user of the machinery Note 1 to entry: Embedded soft­ware is usu­ally writ­ten in FVL.
Note 1 to entry: Embedded soft­ware is usu­ally writ­ten in FVL.
3.1.34 lim­ited vari­ab­il­ity lan­guage LVL
type of lan­guage that provides the cap­ab­il­ity of com­bin­ing pre­defined, application-​specific lib­rary func­tions to imple­ment the safety require­ments spe­cific­a­tions
Note 1 to entry: Typical examples of LVL (lad­der logic, func­tion block dia­gram) are giv­en in IEC 61131 – 3.
Note 2 to entry: A typ­ic­al example of a sys­tem using LVL: PLC. [SOURCE: IEC 61511 – 1:2003, 3.2.80.1.2, mod­i­fied.]
3.1.35 full vari­ab­il­ity lan­guage FVL
type of lan­guage that provides the cap­ab­il­ity of imple­ment­ing a wide vari­ety of func­tions and applic­a­tions EXAMPLE C, C++, Assembler.
Note 1 to entry: A typ­ic­al example of sys­tems using FVL: embed­ded sys­tems.
Note 2 to entry: In the field of machinery, FVL is found in embed­ded soft­ware and rarely in applic­a­tion soft­ware. [SOURCE: IEC 61511 – 1:2003, 3.2.80.1.3, mod­i­fied.]
3.1.37 embed­ded soft­ware
firm­ware
sys­tem soft­ware
soft­ware that is part of the sys­tem sup­plied by the con­trol man­u­fac­turer and which is not access­ible for modi­fic­a­tion by the user of the machinery.
Note 1 to entry: Embedded soft­ware is usu­ally writ­ten in FVL.
Field Programmable Gate Array FPGA
A field-​programmable gate array (FPGA) is an integ­rated cir­cuit designed to be con­figured by a cus­tom­er or a design­er after man­u­fac­tur­ing – hence “field-​programmable”. The FPGA con­fig­ur­a­tion is gen­er­ally spe­cified using a hard­ware descrip­tion lan­guage (HDL), sim­il­ar to that used for an application-​specific integ­rated cir­cuit (ASIC). [22]

Book List

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

[0]     B. Main, Risk Assessment: Basics and Benchmarks, 1st ed. Ann Arbor, MI USA: DSE, 2004.

[0.1]  D. Smith and K. Simpson, Safety crit­ic­al sys­tems hand­book. Amsterdam: Elsevier/​Butterworth-​Heinemann, 2011.

[0.2]  Electromagnetic Compatibility for Functional Safety, 1st ed. Stevenage, UK: The Institution of Engineering and Technology, 2008.

[0.3]  Overview of tech­niques and meas­ures related to EMC for Functional Safety, 1st ed. Stevenage, UK: Overview of tech­niques and meas­ures related to EMC for Functional Safety, 2013.

References

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. Included in the last post of the series is the com­plete ref­er­ence list.

[1]     Safety of machinery — Safety-​related parts of con­trol sys­tems — Part 1: General prin­ciples for design. 3rd Edition. ISO Standard 13849 – 1. 2015.

[2]     Safety of machinery – Safety-​related parts of con­trol sys­tems – Part 2: Validation. 2nd Edition. ISO Standard 13849 – 2. 2012.

[3]      Safety of machinery – General prin­ciples for design – Risk assess­ment and risk reduc­tion. ISO Standard 12100. 2010.

[4]     Safeguarding of Machinery. 2nd Edition. CSA Standard Z432. 2004.

[5]     Risk Assessment and Risk Reduction- A Guideline to Estimate, Evaluate and Reduce Risks Associated with Machine Tools. ANSI Technical Report B11.TR3. 2000.

[6]    Safety of machinery – Emergency stop func­tion – Principles for design. ISO Standard 13850. 2015.

[7]     Functional safety of electrical/​electronic/​programmable elec­tron­ic safety-​related sys­tems. 7 parts. IEC Standard 61508. Edition 2. 2010.

[8]     S. Jocelyn, J. Baudoin, Y. Chinniah, and P. Charpentier, “Feasibility 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.

[9]    Guidance on the applic­a­tion of ISO 13849 – 1 and IEC 62061 in the design of safety-​related con­trol sys­tems for machinery. IEC Technical Report TR 62061 – 1. 2010.

[10]     Safety of machinery – Functional safety of safety-​related elec­tric­al, elec­tron­ic and pro­gram­mable elec­tron­ic con­trol sys­tems. IEC Standard 62061. 2005.

[11]    Guidance on the applic­a­tion of ISO 13849 – 1 and IEC 62061 in the design of safety-​related con­trol sys­tems for machinery. IEC Technical Report 62061 – 1. 2010.

[12]    D. S. G. Nix, Y. Chinniah, F. Dosio, M. Fessler, F. Eng, and F. Schrever, “Linking Risk and Reliability — Mapping the out­put of risk assess­ment tools to func­tion­al safety require­ments for safety related con­trol sys­tems,” 2015.

[13]    Safety of machinery. Safety related parts of con­trol sys­tems. General prin­ciples for design. CEN Standard EN 954 – 1. 1996.

[14]   Functional safety of electrical/​electronic/​programmable elec­tron­ic safety-​related sys­tems – Part 2: Requirements for electrical/​electronic/​programmable elec­tron­ic safety-​related sys­tems. IEC Standard 61508 – 2. 2010.

[15]     Reliability Prediction of Electronic Equipment. Military Handbook MIL-​HDBK-​217F. 1991.

[16]     “IFA – Practical aids: Software-​Assistent SISTEMA: Safety Integrity – Software Tool for the Evaluation of Machine Applications”, Dguv​.de, 2017. [Online]. Available: http://​www​.dguv​.de/​i​f​a​/​p​r​a​x​i​s​h​i​l​f​e​n​/​p​r​a​c​t​i​c​a​l​-​s​o​l​u​t​i​o​n​s​-​m​a​c​h​i​n​e​-​s​a​f​e​t​y​/​s​o​f​t​w​a​r​e​-​s​i​s​t​e​m​a​/​i​n​d​e​x​.​jsp. [Accessed: 30- Jan- 2017].

[17]      “fail­ure 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 con­trol sys­tems go wrong and how to pre­vent fail­ure, 2nd ed. Richmond, Surrey, UK: HSE Health and Safety Executive, 2003.

[20]     Safeguarding of Machinery. 3rd Edition. CSA Standard Z432. 2016.

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

[22]     “Field-​programmable gate array”, En​.wiki​pe​dia​.org, 2017. [Online]. Available: https://​en​.wiki​pe​dia​.org/​w​i​k​i​/​F​i​e​l​d​-​p​r​o​g​r​a​m​m​a​b​l​e​_​g​a​t​e​_​a​r​ray. [Accessed: 16-​Jun-​2017].

ISO 13849 – 1 Analysis — Part 4: MTTFD – Mean Time to Dangerous Failure

This entry is part 4 of 9 in the series How to do a 13849 – 1 ana­lys­is

Functional safety is all about the like­li­hood of a safety sys­tem fail­ing to oper­ate when you need it. Understanding Mean Time to Dangerous Failure, or MTTFD, is crit­ic­al. If you have been read­ing about this top­ic at all, you may notice that I am abbre­vi­at­ing Mean Time to Dangerous Failure with all cap­it­al let­ters. Using MTTFD is a recent change that occurred in the third edi­tion of ISO 13849 – 1, pub­lished in 2015. In the first and second edi­tions, the cor­rect abbre­vi­ation was MTTFd. Onward!

If you missed the third instal­ment in this series, you can read it here.

Defining MTTFD

Let’s start by hav­ing a look at some key defin­i­tions. Looking at [1, Cl. 3], you will find:

3.1.1 safety – related part of a con­trol sys­tem (SRP/​CS)—part of a con­trol sys­tem that responds to safety-​related input sig­nals and gen­er­ates safety-​related
out­put sig­nals

Note 1 to entry: The com­bined safety-​related parts of a con­trol sys­tem start at the point where the safety-​related input sig­nals are ini­ti­ated (includ­ing, for example, the actu­at­ing cam and the roller of the pos­i­tion switch) and end at the out­put of the power con­trol ele­ments (includ­ing, for example, the main con­tacts of a con­tact­or)

Note 2 to entry: If mon­it­or­ing sys­tems are used for dia­gnostics, they are also con­sidered as SRP/​CS.

3.1.5 dan­ger­ous fail­ure—fail­ure which has the poten­tial to put the SRP/​CS in a haz­ard­ous or fail-​to-​function state

Note 1 to entry: Whether or not the poten­tial is real­ized can depend on the chan­nel archi­tec­ture of the sys­tem;
in redund­ant sys­tems a dan­ger­ous hard­ware fail­ure is less likely to lead to the over­all dan­ger­ous or fail-​tofunction
state.

Note 2 to entry: [SOURCE: IEC 61508 – 4, 3.6.7, mod­i­fied.]

3.1.25 mean time to dan­ger­ous fail­ure (MTTFD)—expect­a­tion of the mean time to dan­ger­ous fail­ure

Definition 3.1.5 is pretty help­ful, but defin­i­tion 3.1.25 is, well, not much of a defin­i­tion. Let’s look at this anoth­er way.

Failures and Faults

Since everything can and will even­tu­ally fail to per­form the way we expect it to, we know that everything has a fail­ure rate because everything takes some time to fail. Granted that this time may be very short, like the first time the unit is turned on, or it may be very long, some­times hun­dreds of years. Remember that because this is a rate, it is some­thing that occurs over time. It is also import­ant to be clear that we are talk­ing about fail­ures and not faults. Reading from [1]:

3.1.3 fault—state of an item char­ac­ter­ized by the inab­il­ity to per­form a required func­tion, exclud­ing the inab­il­ity dur­ing pre­vent­ive main­ten­ance or oth­er planned actions, or due to lack of extern­al resources

Note 1 to entry: A fault is often the res­ult of a fail­ure of the item itself, but may exist without pri­or fail­ure.

Note 2 to entry: In this part of ISO 13849, “fault” means ran­dom fault.
[SOURCE: IEC 60050?191:1990, 05 – 01.]

3.1.4 fail­ure— ter­min­a­tion of the abil­ity of an item to per­form a required func­tion

Note 1 to entry: After a fail­ure, the item has a fault.

Note 2 to entry: “Failure” is an event, as dis­tin­guished from “fault”, which is a state.

Note 3 to entry: The concept as defined does not apply to items con­sist­ing of soft­ware only.

Note 4 to entry: Failures which only affect the avail­ab­il­ity of the pro­cess under con­trol are out­side of the scope of this part of ISO 13849.
[SOURCE: IEC 60050 – 191:1990, 04 – 01.]

3.1.4 Note 2 is the import­ant one at this point in the dis­cus­sion.

Now, where we have mul­tiples of some­thing, like relays, valves, or safety sys­tems, we now have a pop­u­la­tion of identic­al items, each of which will even­tu­ally fail at some point. We can count those fail­ures as they occur and tally them up, and we can graph how many fail­ures we get in the pop­u­la­tion over time. If this is start­ing to sound sus­pi­ciously like stat­ist­ics to you, that is because it is.

OK, so let’s look at the kinds of fail­ures that occur in that pop­u­la­tion. Some fail­ures will res­ult in a “safe” state, e.g., a relay fail­ing with all poles open, and some will fail in a poten­tially “dan­ger­ous” state, like a nor­mally closed valve devel­op­ing a sig­ni­fic­ant leak. If we tally up all the fail­ures that occur, and then tally the num­ber of “safe” fail­ures and the num­ber of “dan­ger­ous” fail­ures in that pop­u­la­tion, we now have some very use­ful inform­a­tion.

The dif­fer­ent kinds of fail­ures are sig­ni­fied using the lower­case Greek let­ter \lambda (lambda). We can add some sub­scripts to help identi­fy what kinds of fail­ures we are talk­ing about. The com­mon vari­able des­ig­na­tions used are [14]:

\lambda = fail­ures
\lambda_{(t)} = fail­ure rate
\lambda_s = “safe” fail­ures
\lambda_d = “dan­ger­ous” fail­ures
\lambda_{dd} = detect­able “dan­ger­ous” fail­ures
\lambda_{du} = undetect­able “dan­ger­ous” fail­ures

I will be dis­cuss­ing some of these vari­ables in more detail in a later part of the series when I delve into Diagnostic Coverage, so don’t worry about them too much just yet.

Getting to MTTFD

Since we can now start to deal with the fail­ure rate data math­em­at­ic­ally, we can start to do some cal­cu­la­tions about expec­ted life­time of a com­pon­ent or a sys­tem. That expec­ted, or prob­able, life­time is what defin­i­tion 3.1.25 was on about, and is what we call MTTFD.

MTTFD is the time in years over which the prob­ab­il­ity of fail­ure is rel­at­ively con­stant. If you look at a typ­ic­al fail­ure rate curve, called a “bathtub curve” due to its resemb­lance to the pro­file of a nice soak­er tub, the MTTFD is the flat­ter por­tion of the curve between the end of the infant mor­tal­ity peri­od and the wear-​out peri­od at the end of life. This part of the curve is the por­tion assumed to be included in the “mis­sion time” for the product. ISO 13849 – 1 assumes the mis­sion time for all machinery is 20 years [1, 4.5.4] and [1, Cl. 10].

Diagram of a standardized bathtub-shaped failure rate curve.
Figure 1 – Typical Bathtub Curve [15]
ISO 13849 – 1 provides us with guid­ance on how MTTFD relates to the determ­in­a­tion of the PL in [1, Cl. 4.5.2]. MTTFD is fur­ther grouped into three bands as shown in [1, Table 4].
Table showing the bands of Mean time to dangerous failure of each channel (MTTFD)

The notes for this table are import­ant as well. Since you can’t read the notes par­tic­u­larly well in the table above, I’ve repro­duced them here:

NOTE 1 The choice of the MTTFD ranges of each chan­nel is based on fail­ure rates found in the field as state-​of-​the-​art, form­ing a kind of log­ar­ithmic scale fit­ting to the log­ar­ithmic PL scale. An MTTFD value of each chan­nel less than three years is not expec­ted to be found for real SRP/​CS since this would mean that after one year about 30 % of all sys­tems on the mar­ket will fail and will need to be replaced. An MTTFD value of each chan­nel great­er than 100 years is not accept­able because SRP/​CS for high risks should not depend on the reli­ab­il­ity of com­pon­ents alone. To rein­force the SRP/​CS against sys­tem­at­ic and ran­dom fail­ure, addi­tion­al means such as redund­ancy and test­ing should be required. To be prac­tic­able, the num­ber of ranges was restric­ted to three. The lim­it­a­tion of MTTFD of each chan­nel val­ues to a max­im­um of 100 years refers to the single chan­nel of the SRP/​CS which car­ries out the safety func­tion. Higher MTTFD val­ues can be used for single com­pon­ents (see Table D.1).

NOTE 2 The indic­ated bor­ders of this table are assumed with­in an accur­acy of 5%.

The stand­ard then tells us to select the MTTFD using a simple hier­archy [1, 4.5.2]:

For the estim­a­tion ofMTTFD of a com­pon­ent, the hier­arch­ic­al pro­ced­ure for find­ing data shall be, in the order giv­en:

a) use manufacturer’s data;
b) use meth­ods in Annex C and Annex D;
c) choose 10 years.

Why ten years? Ten years is half of the assumed mis­sion life­time of 20 years. More on mis­sion life­time in a later post.

Looking at [1, Annex C.2], you will find the “Good Engineering Practices” meth­od for estim­at­ing MTTFD, pre­sum­ing the man­u­fac­turer has not provided you with that inform­a­tion. ISO 13849 – 2 [2] has some ref­er­ence tables that provide some gen­er­al MTTFD val­ues for some kinds of com­pon­ents, but not every part that exists can be lis­ted. How can we deal with parts not lis­ted? [1, Annex C.4] provides us with a cal­cu­la­tion meth­od for estim­at­ing MTTFD for pneu­mat­ic, mech­an­ic­al and elec­tromech­an­ic­al com­pon­ents.

Calculating MTTFD for pneumatic, mechanical and electromechanical components

I need to intro­duce you to a few more vari­ables before we look at how to cal­cu­late MTTFD for a com­pon­ent.

Variables
Variable Description
B10 Number of cycles until 10% of the com­pon­ents fail (for pneu­mat­ic and elec­tromech­an­ic­al com­pon­ents)
B10D Number of cycles until 10% of the com­pon­ents fail dan­ger­ously (for pneu­mat­ic and elec­tromech­an­ic­al com­pon­ents)
T life­time of the com­pon­ent
T10D the mean time until 10% of the com­pon­ents fail dan­ger­ously
hop is the mean oper­a­tion time, in hours per day;
dop is the mean oper­a­tion time, in days per year;
tcycle is the mean oper­a­tion time between the begin­ning of two suc­cess­ive cycles of the com­pon­ent. (e.g., switch­ing of a valve) in seconds per cycle.
s seconds
h hours
a years

Knowing a few details we can cal­cu­late the MTTFD using [1, Eqn C.1]. We need to know the fol­low­ing para­met­ers for the applic­a­tion:

  • B10D
  • hop
  • dop
  • tcycle

Formula for calculating MTTFD - ISO 13849-1, Equation C.1
Calculating MTTFD – [1, Eqn. C.1]
In order to use [1, Eqn. C.1], we need to first cal­cu­late nop, using [1, Eqn. C.2]:

Formula for calculating nop - ISO 13849-1, Equation C.2.
Calculating nop – [1, Eqn. C.2]
We may also need one more cal­cu­la­tion, [1, Eqn. C.4]:
Calculating T10D using ISO 13849-1 Eqn. C.3
Calculating T10D – [1, Eqn. C.4]

Example Calculation [1, C.4.3]

For a pneu­mat­ic valve, a man­u­fac­turer determ­ines a mean value of 60 mil­lion cycles as B10D. The valve is used for two shifts each day on 220 oper­a­tion days a year. The mean time between the begin­ning of two suc­cess­ive switch­ing of the valve is estim­ated as 5 s. This yields the fol­low­ing val­ues:

  • dop of 220 days per year;
  • hop of 16 h per day;
  • tcycle of 5 s per cycle;
  • B10D of 60 mil­lion cycles.

Doing the math, we get:

Example C.4.3 calculations from, ISO 13849-1.
Example C.4.3

So there you have it, at least for a fairly simple case. There are more examples in ISO 13849 – 1, and I would encour­age you to work through them. You can also find a wealth of examples in a report pro­duced by the BGIA in Germany, called the Functional safety of machine con­trols (BGIA Report 2/​2008e) [16]. The down­load for the report is linked from the ref­er­ence list at the end of this art­icle. If you are a SISTEMA user, there are lots of examples in the SISTEMA Cookbooks, and there are example files avail­able so that you can see how to assemble the sys­tems in the soft­ware.

The next part of this series cov­ers Diagnostic Coverage (DC), and the aver­age DC for mul­tiple safety func­tions in a sys­tem, DCavg.

In case you missed the first part of the series, you can read it here.

Book List

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

[0]     B. Main, Risk Assessment: Basics and Benchmarks, 1st ed. Ann Arbor, MI USA: DSE, 2004.

[0.1]  D. Smith and K. Simpson, Safety crit­ic­al sys­tems hand­book. Amsterdam: Elsevier/​Butterworth-​Heinemann, 2011.

[0.2]  Electromagnetic Compatibility for Functional Safety, 1st ed. Stevenage, UK: The Institution of Engineering and Technology, 2008.

[0.3]  Overview of tech­niques and meas­ures related to EMC for Functional Safety, 1st ed. Stevenage, UK: Overview of tech­niques and meas­ures related to EMC for Functional Safety, 2013.

References

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. Included in the last post of the series is the com­plete ref­er­ence list.

[1]     Safety of machinery — Safety-​related parts of con­trol sys­tems — Part 1: General prin­ciples for design. 3rd Edition. ISO Standard 13849 – 1. 2015.

[2]     Safety of machinery – Safety-​related parts of con­trol sys­tems – Part 2: Validation. 2nd Edition. ISO Standard 13849 – 2. 2012.

[7]     Functional safety of electrical/​electronic/​programmable elec­tron­ic safety-​related sys­tems. 7 parts. IEC Standard 61508. Second Edition. 2010.

[14]    Functional safety of electrical/​electronic/​programmable elec­tron­ic safety-​related sys­tems – Part 4: Definitions and abbre­vi­ations. IEC Standard 61508 – 4. Second Edition. 2010.

[15]    “The bathtub curve and product fail­ure beha­vi­or part 1 of 2”, Findchart​.co, 2017. [Online]. Available: http://​find​chart​.co/​d​o​w​n​l​o​a​d​.​p​h​p​?​a​H​R​0​c​D​o​v​L​3​d​3​d​y​5​3​Z​W​l​i​d​W​x​s​L​m​N​v​b​S​9​o​b​3​R​3​a​X​J​l​L​2​l​z​c​3​V​l​M​j​E​v​a​H​Q​y​M​V​8​x​L​m​d​pZg. [Accessed: 03- Jan- 2017].

[16]   “Functional safety of machine con­trols – Application of EN ISO 13849 (BGIA Report 2/​2008e)”, dguv​.de, 2017. [Online]. Available: http://​www​.dguv​.de/​i​f​a​/​p​u​b​l​i​k​a​t​i​o​n​e​n​/​r​e​p​o​r​t​s​-​d​o​w​n​l​o​a​d​/​b​g​i​a​-​r​e​p​o​r​t​s​-​2​0​0​7​-​b​i​s​-​2​0​0​8​/​b​g​i​a​-​r​e​p​o​r​t-2 – 2008/index-2.jsp. [Accessed: 2017-​01-​04].

Digiprove sealCopyright secured by Digiprove © 2017
Acknowledgements: IEC, ISO and oth­ers as cited
Some Rights Reserved