How to do a 13849 – 1 analysis: Complete Reference List

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

An old book lying open with round eyeglasses lying on top.As prom­ised in pre­vi­ous posts, here is the com­plete ref­er­ence list for the series “How to do a 13849 – 1 ana­lys­is”! If you have any addi­tion­al resources you think read­ers would find help­ful, please add them in the com­ments.

Book List

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

[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.

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: 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.

[4]     Safe­guard­ing of Machinery. 2nd Edi­tion. CSA Stand­ard Z432. 2004.

[5]     Risk Assess­ment and Risk Reduc­tion- A Guideline to Estim­ate, Eval­u­ate and Reduce Risks Asso­ci­ated with Machine Tools. ANSI Tech­nic­al Report B11.TR3. 2000.

[6]    Safety of machinery – Emer­gency stop func­tion – Prin­ciples for design. ISO Stand­ard 13850. 2015.

[7]     Func­tion­al safety of electrical/electronic/programmable elec­tron­ic safety-related sys­tems. 7 parts. IEC Stand­ard 61508. Edi­tion 2. 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.

[9]    Guid­ance 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 Tech­nic­al Report TR 62061 – 1. 2010.

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

[11]    Guid­ance 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 Tech­nic­al Report 62061 – 1. 2010.

[12]    D. S. G. Nix, Y. Chin­ni­ah, F. Dosio, M. Fessler, F. Eng, and F. Schrever, “Link­ing Risk and Reli­ab­il­ity — Map­ping 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. Gen­er­al prin­ciples for design. CEN Stand­ard EN 954 – 1. 1996.

[14]   Func­tion­al safety of electrical/electronic/programmable elec­tron­ic safety-related sys­tems – Part 2: Require­ments for electrical/electronic/programmable elec­tron­ic safety-related sys­tems. IEC Stand­ard 61508 – 2. 2010.

[15]     Reli­ab­il­ity Pre­dic­tion of Elec­tron­ic Equip­ment. Mil­it­ary Hand­book MIL-HDBK-217F. 1991.

[16]     “IFA – Prac­tic­al aids: Soft­ware-Assist­ent SISTEMA: Safety Integ­rity – Soft­ware Tool for the Eval­u­ation of Machine Applic­a­tions”, Dguv.de, 2017. [Online]. Avail­able: http://www.dguv.de/ifa/praxishilfen/practical-solutions-machine-safety/software-sistema/index.jsp. [Accessed: 30- Jan- 2017].

[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.

[22]     “Field-pro­gram­mable gate array”, En.wikipedia.org, 2017. [Online]. Avail­able: https://en.wikipedia.org/wiki/Field-programmable_gate_array. [Accessed: 16-Jun-2017].

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

[24]     “Fail­ure mode and effects ana­lys­is”, En.wikipedia.org, 2017. [Online]. Avail­able: https://en.wikipedia.org/wiki/Failure_mode_and_effects_analysis. [Accessed: 16-Jun-2017].

ISO 13849 – 1 Analysis — Part 8: Fault Exclusion

This entry is part 9 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-sys­tems 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-trivi­al exer­cise!

Think­ing 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
  • Dan­ger­ous undetect­able faults
  • Safe detect­able faults
  • Dan­ger­ous detect­able faults

For sys­tems where no dia­gnostics are used, Cat­egory 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. [2, Annex A], Val­id­a­tion tools for mech­an­ic­al sys­tems, dis­cusses the con­cepts of “Basic Safety Prin­ciples”, “Well-Tried Safety Prin­ciples”, and “Well-tried com­pon­ents”.  [2, Annex A] also provides examples of faults and rel­ev­ant fault exclu­sion cri­ter­ia. There are sim­il­ar Annexes that cov­er pneu­mat­ic sys­tems [2, Annex B], hydraul­ic sys­tems [2, Annex C], and elec­tric­al sys­tems [2, Annex D].

For sys­tems where dia­gnostics are part of the design, i.e., Cat­egory 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. Depend­ing 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 Val­id­a­tion por­tion of this pro­cess as well. At the start of the Val­id­a­tion 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 — Mech­an­ic­al 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:

  • Pres­sure-coil springs
  • Dir­ec­tion­al con­trol valves
  • Stop (shut-off) valves/non-return (check) valves/quick-action vent­ing valves/shuttle valves, etc.
  • Flow valves
  • Pres­sure valves
  • Pipe­work
  • Hose assem­blies
  • Con­nect­ors
  • Pres­sure trans­mit­ters and pres­sure medi­um trans­ducers
  • Com­pressed air treat­ment — Fil­ters
  • Com­pressed-air treat­ment — Oil­ers
  • Com­pressed air treat­ment — Silen­cers
  • Accu­mu­lat­ors and pres­sure ves­sels
  • Sensors
  • Flu­id­ic Inform­a­tion pro­cessing — Logic­al 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. Fail­ure Modes and Effects Ana­lys­is (FMEA) is usu­ally the best approach for devel­op­ing fault lists 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

#1 – Voltage Regulator

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. All three fail­ures can be grouped and con­sidered as a single fault because they ori­gin­ate in a single fail­ure in the voltage reg­u­lat­or.

#2 – Lightning Strike

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. Again, a single event causes all of the sub­sequent fail­ures.

#3 – Pneumatic System Lubrication

3a – 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.

3b – 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. 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-con­sidered 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!

Whenev­er 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! Con­sider 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. Care­ful 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.1], [0.2], and [0.3]. 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 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.

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: 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.

[4]     Safe­guard­ing of Machinery. 2nd Edi­tion. CSA Stand­ard Z432. 2004.

[5]     Risk Assess­ment and Risk Reduc­tion- A Guideline to Estim­ate, Eval­u­ate and Reduce Risks Asso­ci­ated with Machine Tools. ANSI Tech­nic­al Report B11.TR3. 2000.

[6]    Safety of machinery – Emer­gency stop func­tion – Prin­ciples for design. ISO Stand­ard 13850. 2015.

[7]     Func­tion­al safety of electrical/electronic/programmable elec­tron­ic safety-related sys­tems. 7 parts. IEC Stand­ard 61508. Edi­tion 2. 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.

[9]    Guid­ance 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 Tech­nic­al Report TR 62061 – 1. 2010.

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

[11]    Guid­ance 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 Tech­nic­al Report 62061 – 1. 2010.

[12]    D. S. G. Nix, Y. Chin­ni­ah, F. Dosio, M. Fessler, F. Eng, and F. Schrever, “Link­ing Risk and Reli­ab­il­ity — Map­ping 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. Gen­er­al prin­ciples for design. CEN Stand­ard EN 954 – 1. 1996.

[14]   Func­tion­al safety of electrical/electronic/programmable elec­tron­ic safety-related sys­tems – Part 2: Require­ments for electrical/electronic/programmable elec­tron­ic safety-related sys­tems. IEC Stand­ard 61508 – 2. 2010.

[15]     Reli­ab­il­ity Pre­dic­tion of Elec­tron­ic Equip­ment. Mil­it­ary Hand­book MIL-HDBK-217F. 1991.

[16]     “IFA – Prac­tic­al aids: Soft­ware-Assist­ent SISTEMA: Safety Integ­rity – Soft­ware Tool for the Eval­u­ation of Machine Applic­a­tions”, Dguv.de, 2017. [Online]. Avail­able: http://www.dguv.de/ifa/praxishilfen/practical-solutions-machine-safety/software-sistema/index.jsp. [Accessed: 30- Jan- 2017].

[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.

[22]     “Field-pro­gram­mable gate array”, En.wikipedia.org, 2017. [Online]. Avail­able: https://en.wikipedia.org/wiki/Field-programmable_gate_array. [Accessed: 16-Jun-2017].

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

[24]     “Fail­ure mode and effects ana­lys­is”, En.wikipedia.org, 2017. [Online]. Avail­able: https://en.wikipedia.org/wiki/Failure_mode_and_effects_analysis. [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 Win­dows, MacOS and Linux. Gen­er­ally 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-reli­ab­il­ity 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-reli­ab­il­ity 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. Gen­er­ate read­able, under­stand­able, test­able and main­tain­able soft­ware

Avoiding Faults

Fig. 1 [1, Fig. 6] shows the “V-mod­el” 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: Val­id­a­tion 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 Require­ment Spe­cific­a­tion (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
Fig­ure 1 — Sim­pli­fied V-mod­el of soft­ware safety life­cycle

Com­ing in from the Safety Require­ment Spe­cific­a­tion (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-mod­el. 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-mod­el 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:

  • Pre­con­figured (build­ing-block style) soft­ware
  • Fully cus­tom­ised soft­ware

Preconfigured Building-Block Software

The pre­con­figured build­ing-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-writ­ten 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). How­ever, 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-con­figured 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-vari­ab­il­ity 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-mod­el 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-mod­el 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-chan­nel hard­ware devel­op­ment is used, as shown in Fig. 2  [1, Fig 7].

General architecture model of software
Fig­ure 2 — Gen­er­al archi­tec­ture mod­el of soft­ware

The com­plete V-mod­el 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-reli­ab­il­ity 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: Embed­ded soft­ware is usu­ally writ­ten in FVL.
Note 1 to entry: Embed­ded 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, applic­a­tion-spe­cif­ic lib­rary func­tions to imple­ment the safety require­ments spe­cific­a­tions
Note 1 to entry: Typ­ic­al 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++, Assem­bler.
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: Embed­ded soft­ware is usu­ally writ­ten in FVL.
Field Pro­gram­mable Gate Array FPGA
A field-pro­gram­mable 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-pro­gram­mable”. 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 applic­a­tion-spe­cif­ic 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 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.

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: 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.

[4]     Safe­guard­ing of Machinery. 2nd Edi­tion. CSA Stand­ard Z432. 2004.

[5]     Risk Assess­ment and Risk Reduc­tion- A Guideline to Estim­ate, Eval­u­ate and Reduce Risks Asso­ci­ated with Machine Tools. ANSI Tech­nic­al Report B11.TR3. 2000.

[6]    Safety of machinery – Emer­gency stop func­tion – Prin­ciples for design. ISO Stand­ard 13850. 2015.

[7]     Func­tion­al safety of electrical/electronic/programmable elec­tron­ic safety-related sys­tems. 7 parts. IEC Stand­ard 61508. Edi­tion 2. 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.

[9]    Guid­ance 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 Tech­nic­al Report TR 62061 – 1. 2010.

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

[11]    Guid­ance 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 Tech­nic­al Report 62061 – 1. 2010.

[12]    D. S. G. Nix, Y. Chin­ni­ah, F. Dosio, M. Fessler, F. Eng, and F. Schrever, “Link­ing Risk and Reli­ab­il­ity — Map­ping 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. Gen­er­al prin­ciples for design. CEN Stand­ard EN 954 – 1. 1996.

[14]   Func­tion­al safety of electrical/electronic/programmable elec­tron­ic safety-related sys­tems – Part 2: Require­ments for electrical/electronic/programmable elec­tron­ic safety-related sys­tems. IEC Stand­ard 61508 – 2. 2010.

[15]     Reli­ab­il­ity Pre­dic­tion of Elec­tron­ic Equip­ment. Mil­it­ary Hand­book MIL-HDBK-217F. 1991.

[16]     “IFA – Prac­tic­al aids: Soft­ware-Assist­ent SISTEMA: Safety Integ­rity – Soft­ware Tool for the Eval­u­ation of Machine Applic­a­tions”, Dguv.de, 2017. [Online]. Avail­able: http://www.dguv.de/ifa/praxishilfen/practical-solutions-machine-safety/software-sistema/index.jsp. [Accessed: 30- Jan- 2017].

[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.

[22]     “Field-pro­gram­mable gate array”, En.wikipedia.org, 2017. [Online]. Avail­able: https://en.wikipedia.org/wiki/Field-programmable_gate_array. [Accessed: 16-Jun-2017].