Machinery Safety Labels: 3 Top Tools for Effective Warnings

This entry is part 1 of 3 in the series Safe­ty Labels

Machinery Safety Labels

The third lev­el of the Hier­ar­chy of Con­trols is Infor­ma­tion for Use. Safe­ty Labels are a key part of the Infor­ma­tion for Use pro­vid­ed by machine builders to users and are often the only infor­ma­tion that many users get to see. This makes the design and place­ment of the safe­ty labels crit­i­cal to their effec­tive­ness. There is as much risk in the under-use of safe­ty labels as there is in the over-use of safe­ty labels. Often, machine builders and users sim­ply select gener­ic labels that are eas­i­ly avail­able from cat­a­logues, miss­ing the oppor­tu­ni­ty to design labels that are spe­cif­ic to the machine and the haz­ards present.

Product Safety and Liability Limitation

If your com­pa­ny man­u­fac­tures machin­ery that has poten­tial haz­ards asso­ci­at­ed with its trans­porta­tion, instal­la­tion, use, main­te­nance, decom­mis­sion­ing and/or dis­pos­al, you like­ly have a very strong need to cre­ate effec­tive prod­uct safe­ty labels. This task must be done right: prod­uct safe­ty labels play an inte­gral role in your company’s prod­uct safe­ty and lia­bil­i­ty pre­ven­tion efforts. And that means that people’s lives and your company’s finan­cial well-being are on the line. On that note, it’s impor­tant to keep in mind these two fac­tors when it comes to effec­tive safe­ty labels:

  1. If prop­er­ly designed, they can dra­mat­i­cal­ly reduce acci­dents. This not only improves a product’s over­all safe­ty record but adds to a company’s bot­tom line by reduc­ing prod­uct lia­bil­i­ty lit­i­ga­tion and insur­ance costs.
  2. If poor­ly designed, need­ed safe­ty com­mu­ni­ca­tion does not take place and this can lead to acci­dents that cause injuries. With these acci­dents, com­pa­nies face high costs set­tling or fight­ing law­suits because their prod­ucts lacked “ade­quate warn­ings.”

With the rise in prod­uct lia­bil­i­ty lit­i­ga­tion based on “fail­ure to warn” over the past sev­er­al decades, prod­uct safe­ty labels have become a lead­ing focal point in law­suits faced by cap­i­tal equip­ment man­u­fac­tur­ers. Let’s look at three best?practice tools for prod­uct safe­ty label design. These tools can pro­vide insight to help you cre­ate or improve your safe­ty label strat­e­gy in order to bet­ter pro­tect your prod­uct users from harm and your com­pa­ny from lit­i­ga­tion-relat­ed loss­es.

TOOL #1: SAFETY LABEL STANDARDS

As a man­u­fac­tur­er, you know that your legal oblig­a­tion is to meet or exceed the most recent ver­sions of stan­dards relat­ed to your prod­uct at the time it’s sold into the mar­ket­place. Warn­ing label stan­dards are the first place to turn to when it comes to defin­ing your prod­uct safe­ty labels. Up until 1991, there was no over­ar­ch­ing, mul­ti-indus­try stan­dard in the U.S., or in the rest of the world, which gave defin­i­tive guid­ance on the prop­er for­mat­ting and con­tent for on-prod­uct warn­ings. In the U.S., that changed nation­al­ly with the pub­li­ca­tion of the ANSI Z535.4 Stan­dard for Prod­uct Safe­ty Signs and Labels in 1991, and inter­na­tion­al­ly with the pub­li­ca­tion of ISO 3864–2 Design Prin­ci­ples for Prod­uct Safe­ty Labels in 2004.

As of 2017, Cana­da does not have a warn­ing label stan­dard. Since Cana­da imports machin­ery from the U.S. and the EU, it is quite com­mon to see either ANSI Z535 style labels or ISO 3864 style labels on prod­ucts. Under Cana­di­an law, nei­ther is more cor­rect. How­ev­er, Québec has spe­cif­ic require­ments for French lan­guage trans­la­tions, and many CSA stan­dards pre­scribe spe­cif­ic haz­ard warn­ing labels that do not con­form to either ANSI or ISO styles.

Fol­low­ing the design prin­ci­ples in ANSI Z535.4 or ISO 3864–2 will give you a start­ing place for both the con­tent and for­mat choic­es you have to make for your prod­ucts’ safe­ty labels, bear­ing in mind the lan­guage require­ments of your juris­dic­tion. Note that both of these stan­dards are revised reg­u­lar­ly, every five years or so, and it’s impor­tant to be aware of the nuances that would make one for­mat more appro­pri­ate for your prod­uct than anoth­er.

Safety label standard ANSI Z535.4 Product Safety Signs and Labels
The ANSI Z535.4 prod­uct safe­ty label stan­dard
Safety label standard ISO 3864-2 Graphical symbols - Safety colours and safety signs - Part 2: Design principles for product safety labels.
The ISO 3864–2 prod­uct safe­ty label stan­dard

TOOL #2: RISK ASSESSMENT

From an engi­neer­ing per­spec­tive, your job is to iden­ti­fy poten­tial haz­ards and then deter­mine if they need to be designed out, guard­ed, or warned about. From a legal per­spec­tive, your job is to define what haz­ards are “rea­son­ably fore­see­able” and “rea­son­able” ways to mit­i­gate risks asso­ci­at­ed with haz­ards that can­not be designed out. This is where risk assess­ment comes into play.

In today’s world, a prod­uct is expect­ed to be designed with safe­ty in mind. The risk assess­ment process helps you to accom­plish this task. At its most basic lev­el, risk assess­ment involves con­sid­er­ing the prob­a­bil­i­ty and sever­i­ty of out­comes that can result from poten­tial­ly haz­ardous sit­u­a­tions. After iden­ti­fy­ing the poten­tial haz­ards relat­ed to your prod­uct at every point in its life­cy­cle, you then con­sid­er var­i­ous strate­gies to either elim­i­nate or reduce the risk of peo­ple inter­act­ing with these haz­ards.

The best prac­tice risk assess­ment stan­dards that exist today (i.e. ANSI Z10, ANSI B11, CSA Z432, CSA Z1002, ISO 12100, ISO 31000, ISO 31010) give you a process to use to quan­ti­fy and reduce risks. Using these stan­dards as the basis for a for­mal­ized risk assess­ment process will not only help you to devel­op bet­ter safe­ty labels and a safer prod­uct, but it will also pro­vide you with doc­u­men­ta­tion that will help you to show the world that you are a safe­ty-con­scious com­pa­ny who uses the lat­est stan­dards-based tech­nol­o­gy to reduce risks. This will be high­ly impor­tant should you be involved in prod­uct lia­bil­i­ty lit­i­ga­tion down the road.

From an engi­neer­ing per­spec­tive, your job is to iden­ti­fy poten­tial haz­ards and then deter­mine if they need to be designed out, guard­ed, or warned about. From a legal per­spec­tive, your job is to define what haz­ards are “rea­son­ably fore­see­able” and “rea­son­able” ways to mit­i­gate risks asso­ci­at­ed with haz­ards that can­not be designed out. This is where risk assess­ment comes into play.

MIL-STD 882 risk assessment form
A typ­i­cal risk assess­ment scor­ing matrix (based on MIL STD 882 as defined in ANSI B11/ISO 12100 Safe­ty of Machin­ery – Risk Assess­ment Annex D)

TOOL #3: PICTOGRAPHIC  SAFETY LABELS FOR GLOBAL MARKETS

A large num­ber of machin­ery man­u­fac­tur­ers sell their prod­ucts around the globe and when this is the case, com­pli­ance with glob­al stan­dards is a require­ment. The ANSI Z535.4 and ISO 3864–2 prod­uct safe­ty label stan­dards, and the EU machin­ery direc­tive place an empha­sis on using well-designed sym­bols on machin­ery safe­ty labels so infor­ma­tion can be con­veyed across lan­guage bar­ri­ers.

The EU Machin­ery Direc­tive 2006/42/EC requires that all infor­ma­tion for use be pro­vid­ed in the offi­cial lan­guages of the coun­try of use. Infor­ma­tion for use includes haz­ard warn­ing signs and labels that bear mes­sages in text. Adding sym­bols also increas­es your labels’ notice­abil­i­ty. The use of sym­bols to con­vey safe­ty is becom­ing com­mon­place world­wide and not tak­ing advan­tage of this new visu­al lan­guage risks mak­ing your product’s safe­ty labels obso­lete and non-com­pli­ant with local, region­al and inter­na­tion­al codes. In ISO 3864–2’s lat­est, 2016 update, a major change in ISO label for­mats was made: a new “word­less” for­mat that con­veys risk sever­i­ty was added to the stan­dard. This new label for­mat uses what ISO calls a “haz­ard sever­i­ty pan­el” but no sig­nal word. It com­mu­ni­cates the lev­el of risk through colour-cod­ing of the haz­ard sever­i­ty pan­el. This for­mat option elim­i­nates words – mak­ing trans­la­tions unnec­es­sary.

It should be not­ed that some­times sym­bols alone can­not con­vey com­plex safe­ty mes­sages. In these cas­es, text is often still used. When ship­ping to non-Eng­lish speak­ing coun­tries, the trend today is to trans­late the text into the lan­guage of the coun­try in which the machine is sold. Dig­i­tal print tech­nol­o­gy makes this solu­tion much more cost effec­tive and effi­cient than in the past.

Safety label by Clarion Safety Systems on a machine
A typ­i­cal Clar­i­on machine safe­ty label that uses an inter­na­tion­al­ly for­mat­ted graph­i­cal sym­bol and a for­mat that meets both ANSI Z535.4 and ISO 3864–2 design prin­ci­ples (Design ©Clar­i­on Safe­ty Sys­tems. All rights reserved.)

Concluding Thoughts

The safe­ty labels that appear on your prod­ucts are one of its most vis­i­ble com­po­nents. If they don’t meet cur­rent stan­dards, if they aren’t designed as the result of a risk assess­ment, and if they don’t incor­po­rate well-designed graph­i­cal sym­bols, your com­pa­ny risks lit­i­ga­tion and non-con­for­mance with mar­ket require­ments. Most impor­tant­ly, you may be putting those who inter­act with your machin­ery at risk of harm. Mak­ing sure your prod­uct safe­ty labels are up-to-date is an impor­tant task for every engi­neer respon­si­ble for a machine’s design.

For more infor­ma­tion on effec­tive prod­uct safe­ty labelling and resources that you can put to use today, vis­it www.clarionsafety.com. Clar­i­on also offers com­pli­men­ta­ry safe­ty label assess­ments, where we use our expe­ri­ence with the lat­est stan­dards and best prac­tices to assess your labels and ensure that they’re up-to-date in meet­ing today’s require­ments.

Ed. note: Addi­tion­al Cana­di­an mate­r­i­al con­tributed by Doug Nix.

Digiprove sealCopy­right secured by Digiprove © 2017
Acknowl­edge­ments: Derek Evers­dyke, Clar­i­on Safe­ty Sys­tems, LLC
Some Rights Reserved

ISO 13849–1 Analysis — Part 8: Fault Exclusion

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

Fault Consideration & Fault Exclusion

ISO 13849–1, Chap­ter 7 [1, 7] dis­cuss­es the need for fault con­sid­er­a­tion and fault exclu­sion. Fault con­sid­er­a­tion is the process of exam­in­ing the com­po­nents and sub-sys­tems used in the safe­ty-relat­ed 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­i­nite­ly non-triv­ial exer­cise!

Think­ing back to some of the ear­li­er arti­cles in this series where I men­tioned the dif­fer­ent types of faults, you may recall that there are detectable and unde­tectable faults, and there are safe and dan­ger­ous faults, lead­ing us to four kinds of fault:

  • Safe unde­tectable faults
  • Dan­ger­ous unde­tectable faults
  • Safe detectable faults
  • Dan­ger­ous detectable faults

For sys­tems where no diag­nos­tics are used, Cat­e­go­ry B and 1, faults need to be elim­i­nat­ed using inher­ent­ly safe design tech­niques. Care needs to be tak­en when clas­si­fy­ing com­po­nents as “well-tried” ver­sus using a fault exclu­sion, as com­po­nents that might nor­mal­ly be con­sid­ered “well-tried” might not meet those require­ments in every appli­ca­tion. [2, Annex A], Val­i­da­tion tools for mechan­i­cal sys­tems, dis­cuss­es the con­cepts of “Basic Safe­ty Prin­ci­ples”, “Well-Tried Safe­ty Prin­ci­ples”, and “Well-tried com­po­nents”.  [2, Annex A] also pro­vides exam­ples of faults and rel­e­vant fault exclu­sion cri­te­ria. There are sim­i­lar Annex­es that cov­er pneu­mat­ic sys­tems [2, Annex B], hydraulic sys­tems [2, Annex C], and elec­tri­cal sys­tems [2, Annex D].

For sys­tems where diag­nos­tics are part of the design, i.e., Cat­e­go­ry 2, 3, and 4, the fault lists are used to eval­u­ate the diag­nos­tic cov­er­age (DC) of the test sys­tems. Depend­ing on the archi­tec­ture, cer­tain lev­els of DC are required to meet the rel­e­vant PL, see [1, Fig. 5]. The fault lists are start­ing point for the deter­mi­na­tion of DC, and are an input into the hard­ware and soft­ware designs. All of the dan­ger­ous detectable faults must be cov­ered by the diag­nos­tics, and the DC must be high enough to meet the PLr for the safe­ty func­tion.

The fault lists and fault exclu­sions are used in the Val­i­da­tion por­tion of this process as well. At the start of the Val­i­da­tion process flow­chart [2, Fig. 1], you can see how the fault lists and the cri­te­ria used for fault exclu­sion are used as inputs to the val­i­da­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 exclud­ed do not need to val­i­dat­ed, sav­ing time and effort dur­ing the sys­tem ver­i­fi­ca­tion and val­i­da­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­po­nents and sub­sys­tems includ­ed in SRP/CS. ISO 13849–2 [2] includes lists of typ­i­cal faults for var­i­ous tech­nolo­gies. For exam­ple, [2, Table A.4] is the fault list for mechan­i­cal com­po­nents.

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

[2] con­tains tables sim­i­lar to Table A.4 for:

  • Pres­sure-coil springs
  • Direc­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
  • Pipework
  • Hose assem­blies
  • Con­nec­tors
  • Pres­sure trans­mit­ters and pres­sure medi­um trans­duc­ers
  • Com­pressed air treat­ment — Fil­ters
  • Com­pressed-air treat­ment — Oil­ers
  • Com­pressed air treat­ment — Silencers
  • Accu­mu­la­tors and pres­sure ves­sels
  • Sen­sors
  • Flu­idic Infor­ma­tion pro­cess­ing — Log­i­cal ele­ments
  • etc.

As you can see, there are many dif­fer­ent types of faults that need to be con­sid­ered. 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­sid­er the impact of each fault on the oper­a­tion of the sys­tem. If you have com­po­nents or sub­sys­tems that are not list­ed in the tables, then you need to devel­op your own fault lists for those items. Fail­ure Modes and Effects Analy­sis (FMEA) is usu­al­ly the best approach for devel­op­ing fault lists for these com­po­nents [23], [24].

When con­sid­er­ing the faults to be includ­ed in the list there are a few things that should be con­sid­ered [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 sin­gle fault
  • two or more sin­gle faults with a com­mon cause can be con­sid­ered as a sin­gle fault
  • mul­ti­ple faults with dif­fer­ent caus­es but occur­ring simul­ta­ne­ous­ly is con­sid­ered improb­a­ble and does not need to be con­sid­ered

Examples

#1 — Voltage Regulator

A volt­age reg­u­la­tor fails in a sys­tem pow­er sup­ply so that the 24 Vdc out­put ris­es to an unreg­u­lat­ed 36 Vdc (the inter­nal pow­er sup­ply bus volt­age), and after some time has passed, two sen­sors fail. All three fail­ures can be grouped and con­sid­ered as a sin­gle fault because they orig­i­nate in a sin­gle fail­ure in the volt­age reg­u­la­tor.

#2 — Lightning Strike

If a light­ning strike occurs on the pow­er line and the result­ing surge volt­age on the 400 V mains caus­es an inter­pos­ing con­tac­tor and the motor dri­ve it con­trols to fail to dan­ger, then these fail­ures may be grouped and con­sid­ered as one. Again, a sin­gle event caus­es all of the sub­se­quent fail­ures.

#3 — Pneumatic System Lubrication

3a — A pneu­mat­ic lubri­ca­tor runs out of lubri­cant and is not refilled, depriv­ing down­stream pneu­mat­ic com­po­nents of lubri­ca­tion.

3b — The spool on the sys­tem dump valve sticks open because it is not cycled often enough.

Nei­ther of these fail­ures has the same cause, so there is no need to con­sid­er them as occur­ring simul­ta­ne­ous­ly because the prob­a­bil­i­ty of both hap­pen­ing con­cur­rent­ly is extreme­ly small. One cau­tion: These two faults MAY have a com­mon cause — poor main­te­nance. If this is true and you decide to con­sid­er them to be two faults with a com­mon cause, they could then be grouped as a sin­gle fault.

Fault Exclusion

Once you have your well-con­sid­ered fault lists togeth­er, the next ques­tion is “Can any of the list­ed faults be exclud­ed?” This is a tricky ques­tion! There are a few points to con­sid­er:

  • Does the sys­tem archi­tec­ture allow for fault exclu­sion?
  • Is the fault tech­ni­cal­ly improb­a­ble, even if it is pos­si­ble?
  • Does expe­ri­ence show that the fault is unlike­ly to occur?*
  • Are there tech­ni­cal require­ments relat­ed to the appli­ca­tion and the haz­ard that might sup­port fault exclu­sion?

BE CAREFUL with this one!

When­ev­er faults are exclud­ed, a detailed jus­ti­fi­ca­tion for the exclu­sion needs to be includ­ed in the sys­tem design doc­u­men­ta­tion. Sim­ply decid­ing that the fault can be exclud­ed is NOT ENOUGH! Con­sid­er the risk a per­son will be exposed to in the event the fault occurs. If the sever­i­ty is very high, i.e., severe per­ma­nent 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 result­ing injury sce­nario is need­ed.

Bas­ing a fault exclu­sion on per­son­al expe­ri­ence is sel­dom con­sid­ered ade­quate, which is why I added the aster­isk (*) above. Look for good sta­tis­ti­cal data to sup­port any deci­sion to use a fault exclu­sion.

There is much more infor­ma­tion avail­able in IEC 61508–2 on the sub­ject of fault exclu­sion, and there is good infor­ma­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 infor­ma­tion in the com­ments!

Definitions

3.1.3 fault
state of an item char­ac­ter­ized by the inabil­i­ty to per­form a required func­tion, exclud­ing the inabil­i­ty dur­ing pre­ven­tive main­te­nance or oth­er planned actions, or due to lack of exter­nal resources
Note 1 to entry: A fault is often the result of a fail­ure of the item itself, but may exist with­out 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. Simp­son, Safe­ty crit­i­cal sys­tems hand­book. Ams­ter­dam: Else­vier/But­ter­worth-Heine­mann, 2011.

[0.2]  Elec­tro­mag­net­ic Com­pat­i­bil­i­ty for Func­tion­al Safe­ty, 1st ed. Steve­nage, UK: The Insti­tu­tion of Engi­neer­ing and Tech­nol­o­gy, 2008.

[0.3]  Overview of tech­niques and mea­sures relat­ed to EMC for Func­tion­al Safe­ty, 1st ed. Steve­nage, UK: Overview of tech­niques and mea­sures relat­ed to EMC for Func­tion­al Safe­ty, 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. Includ­ed in the last post of the series is the com­plete ref­er­ence list.

[1]     Safe­ty of machin­ery — Safe­ty-relat­ed parts of con­trol sys­tems — Part 1: Gen­er­al prin­ci­ples for design. 3rd Edi­tion. ISO Stan­dard 13849–1. 2015.

[2]     Safe­ty of machin­ery — Safe­ty-relat­ed parts of con­trol sys­tems — Part 2: Val­i­da­tion. 2nd Edi­tion. ISO Stan­dard 13849–2. 2012.

[3]      Safe­ty of machin­ery — Gen­er­al prin­ci­ples for design — Risk assess­ment and risk reduc­tion. ISO Stan­dard 12100. 2010.

[4]     Safe­guard­ing of Machin­ery. 2nd Edi­tion. CSA Stan­dard Z432. 2004.

[5]     Risk Assess­ment and Risk Reduc­tion- A Guide­line to Esti­mate, Eval­u­ate and Reduce Risks Asso­ci­at­ed with Machine Tools. ANSI Tech­ni­cal Report B11.TR3. 2000.

[6]    Safe­ty of machin­ery — Emer­gency stop func­tion — Prin­ci­ples for design. ISO Stan­dard 13850. 2015.

[7]     Func­tion­al safe­ty of electrical/electronic/programmable elec­tron­ic safe­ty-relat­ed sys­tems. 7 parts. IEC Stan­dard 61508. Edi­tion 2. 2010.

[8]     S. Joce­lyn, J. Bau­doin, Y. Chin­ni­ah, and P. Char­p­en­tier, “Fea­si­bil­i­ty study and uncer­tain­ties in the val­i­da­tion of an exist­ing safe­ty-relat­ed con­trol cir­cuit with the ISO 13849–1:2006 design stan­dard,” Reliab. Eng. Syst. Saf., vol. 121, pp. 104–112, Jan. 2014.

[9]    Guid­ance on the appli­ca­tion of ISO 13849–1 and IEC 62061 in the design of safe­ty-relat­ed con­trol sys­tems for machin­ery. IEC Tech­ni­cal Report TR 62061–1. 2010.

[10]     Safe­ty of machin­ery — Func­tion­al safe­ty of safe­ty-relat­ed elec­tri­cal, elec­tron­ic and pro­gram­ma­ble elec­tron­ic con­trol sys­tems. IEC Stan­dard 62061. 2005.

[11]    Guid­ance on the appli­ca­tion of ISO 13849–1 and IEC 62061 in the design of safe­ty-relat­ed con­trol sys­tems for machin­ery. IEC Tech­ni­cal Report 62061–1. 2010.

[12]    D. S. G. Nix, Y. Chin­ni­ah, F. Dosio, M. Fessler, F. Eng, and F. Schr­ev­er, “Link­ing Risk and Reliability—Mapping the out­put of risk assess­ment tools to func­tion­al safe­ty require­ments for safe­ty relat­ed con­trol sys­tems,” 2015.

[13]    Safe­ty of machin­ery. Safe­ty relat­ed parts of con­trol sys­tems. Gen­er­al prin­ci­ples for design. CEN Stan­dard EN 954–1. 1996.

[14]   Func­tion­al safe­ty of electrical/electronic/programmable elec­tron­ic safe­ty-relat­ed sys­tems — Part 2: Require­ments for electrical/electronic/programmable elec­tron­ic safe­ty-relat­ed sys­tems. IEC Stan­dard 61508–2. 2010.

[15]     Reli­a­bil­i­ty Pre­dic­tion of Elec­tron­ic Equip­ment. Mil­i­tary Hand­book MIL-HDBK-217F. 1991.

[16]     “IFA — Prac­ti­cal aids: Soft­ware-Assis­tent SISTEMA: Safe­ty Integri­ty — Soft­ware Tool for the Eval­u­a­tion of Machine Appli­ca­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­trotech­ni­cal Vocab­u­lary. IEC Inter­na­tion­al Elec­trotech­ni­cal Com­mis­sion, Gene­va, 2015.

[18]      M. Gen­tile and A. E. Sum­mers, “Com­mon Cause Fail­ure: How Do You Man­age 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. Rich­mond, Sur­rey, UK: HSE Health and Safe­ty Exec­u­tive, 2003.

[20]     Safe­guard­ing of Machin­ery. 3rd Edi­tion. CSA Stan­dard Z432. 2016.

[21]     O. Reg. 851, INDUSTRIAL ESTABLISHMENTS. Ontario, Cana­da, 1990.

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

[23]     Analy­sis tech­niques for sys­tem reli­a­bil­i­ty – Pro­ce­dure for fail­ure mode and effects analy­sis (FMEA). 2nd Ed. IEC Stan­dard 60812. 2006.

[24]     “Fail­ure mode and effects analy­sis”, 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 analy­sis

Safety-Related Software

Up to this point, I have been dis­cussing the basic process­es used for the design of safe­ty-relat­ed 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 safe­ty pur­pos­es. The remain­ing ques­tion focus­es on the design and devel­op­ment of safe­ty-relat­ed 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 safe­ty-relat­ed soft­ware, keep in mind that I am talk­ing about soft­ware that is only intend­ed to reduce risk. Some plat­forms that are not well suit­ed for safe­ty soft­ware, pri­mar­i­ly com­mon off-the-shelf (COTS) oper­at­ing sys­tems like Win­dows, MacOS and Lin­ux. Gen­er­al­ly speak­ing, these oper­at­ing sys­tems are too com­plex and sub­ject to unan­tic­i­pat­ed changes to be suit­able for high-reli­a­bil­i­ty appli­ca­tions. There is noth­ing wrong with using these sys­tems for annun­ci­a­tion and mon­i­tor­ing func­tions, but the safe­ty func­tions should run on more pre­dictable plat­forms.

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

NOTE 4 For safe­ty-relat­ed embed­ded soft­ware for com­po­nents with PLr = e, see IEC 61508–3:1998, Clause 7.

As you can see, for very high-reli­a­bil­i­ty sys­tems, i.e., PLe/SIL3 or SIL4, it is nec­es­sary to move to IEC 61508. The meth­ods dis­cussed here are based on ISO 13849–1:2015, Chap­ter 4.6.

Goals

There are two goals for safe­ty-relat­ed soft­ware devel­op­ment activ­i­ties:

  1. Avoid faults
  2. Gen­er­ate read­able, under­stand­able, testable 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­po­rates both val­i­da­tion and ver­i­fi­ca­tion, and when cor­rect­ly imple­ment­ed will result in soft­ware that meets the design spec­i­fi­ca­tions.

If you aren’t sure what the dif­fer­ence is between ver­i­fi­ca­tion and val­i­da­tion, I remem­ber it is this way: Val­i­da­tion means “Are we build­ing the right thing?”, and ver­i­fi­ca­tion means “Did we build the thing right?” The whole process hinges on the Safe­ty Require­ment Spec­i­fi­ca­tion (SRS), so fail­ing to get that part of the process right in the begin­ning will neg­a­tive­ly impact both hard­ware and soft­ware design. The SRS is the yard­stick used to decide if you built the right thing. With­out 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 safe­ty life­cy­cle

Com­ing in from the Safe­ty Require­ment Spec­i­fi­ca­tion (also called the safe­ty func­tion spec­i­fi­ca­tion), each step in the process is shown. The dashed lines illus­trate the ver­i­fi­ca­tion process at each step. Notice that the actu­al cod­ing step is at the bot­tom of the V-mod­el. Every­thing above the cod­ing stage is either plan­ning and design, or qual­i­ty assur­ance activ­i­ties.

There are oth­er meth­ods that can be used to result in ver­i­fied and val­i­dat­ed soft­ware, so if you have a QA process that pro­duces sol­id results, you may not need to change it. I would rec­om­mend that you review all the stages in the V-mod­el to ensure that your QA sys­tem has sim­i­lar process­es.

To make set­ting up safe­ty sys­tems sim­pler for design­ers and inte­gra­tors, there are two approach­es to soft­ware design that can be used.

Two Approaches to Software Design

There are two approach­es to soft­ware design that should be con­sid­ered:

  • Pre­con­fig­ured (build­ing-block style) soft­ware
  • Ful­ly cus­tomised soft­ware

Preconfigured Building-Block Software

The pre­con­fig­ured build­ing-block approach is typ­i­cal­ly used for con­fig­ur­ing safe­ty PLCs or pro­gram­ma­ble safe­ty relays or mod­ules. This type of soft­ware is referred to as “safe­ty-relat­ed embed­ded soft­ware (SRESW)” in [1].

Pre-writ­ten func­tion blocks are pro­vid­ed by the device man­u­fac­tur­er. Each func­tion block has a par­tic­u­lar role: emer­gency stop, safe­ty gate input, zero-speed detec­tion, and so on. When con­fig­ur­ing a safe­ty PLC or safe­ty 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­is­tics that are need­ed. The design­er has no access to the safe­ty-relat­ed code, so apart from con­fig­u­ra­tion errors, no oth­er errors can be intro­duced. The func­tion blocks are ver­i­fied and val­i­dat­ed (V & V) by the con­trols com­po­nent man­u­fac­tur­er, usu­al­ly with the sup­port of an accred­it­ed cer­ti­fi­ca­tion body. The func­tion blocks will nor­mal­ly have a PL asso­ci­at­ed with them, and a state­ment like “suit­able for PLe” will be made in the func­tion block descrip­tion.

This approach elim­i­nates the need to do a detailed V & V of the code by the design­ing enti­ty (i.e., the machine builder). How­ev­er, the machine builder is still required to do a V & V on the oper­a­tion of the sys­tem as they have con­fig­ured 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 intend­ed in the pres­ence of a demand on the safe­ty func­tion or a fault con­di­tion. The faults that should be test­ed 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­fig­ured 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­u­ra­tion soft­ware will val­i­date the func­tion block con­fig­u­ra­tions before com­pil­ing the soft­ware for upload to the safe­ty con­troller so that most con­fig­u­ra­tion errors will be caught at that stage.

This approach also facil­i­tates the sec­ond goal, as long as the con­fig­u­ra­tion soft­ware is usable and main­tained by the soft­ware ven­dor. The con­fig­u­ra­tion soft­ware usu­al­ly includes the abil­i­ty to anno­tate the con­fig­u­ra­tions with rel­e­vant details to assist with the read­abil­i­ty and under­stand­abil­i­ty of the soft­ware.

Fully Customised Software

This approach is used where a ful­ly cus­tomised hard­ware plat­form is being used, and the safe­ty soft­ware is designed to run on that plat­form. [1] refers to this type of soft­ware as “Safe­ty-relat­ed appli­ca­tion soft­ware (SRASW).” A ful­ly cus­tomised soft­ware appli­ca­tion is used where a very spe­cialised safe­ty sys­tem is con­tem­plat­ed, and FPGAs or oth­er cus­tomised hard­ware is being used. These sys­tems are usu­al­ly pro­grammed using full-vari­abil­i­ty 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­a­bly not the best choice for this approach due to its sim­pli­fi­ca­tion, and I would usu­al­ly rec­om­mend using IEC 61508–3 as the basis for the design, ver­i­fi­ca­tion, and val­i­da­tion of ful­ly cus­tomised soft­ware.

Process requirements

Safety-Related Embedded Software (SRESW)

[1, 4.6.2] pro­vides a laun­dry list of ele­ments that must be incor­po­rat­ed into the V-mod­el process­es when devel­op­ing SRESW, bro­ken 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 direct­ly to IEC 61508–3, clause 7, which cov­ers soft­ware suit­able for SIL3 appli­ca­tions.

Safety-Related Application Software (SRASW)

[1, 4.6.3] pro­vides a list of require­ments that must be met through the v-mod­el process for SRASW, and allows that PLa through PLe can be met by code writ­ten in LVL and that PLe appli­ca­tions can also be designed using FVL. In cas­es where soft­ware is devel­oped using  FVL, the soft­ware can be treat­ed as the embed­ded soft­ware prod­ucts (SRESW) are han­dled.

A sim­i­lar archi­tec­tur­al mod­el to that used for sin­gle-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 safe­ty-relat­ed appli­ca­tion soft­ware, with all of the addi­tion­al require­ments from [1, 4.6.3] includ­ed in the process mod­el.

Conclusions

There is a lot to safe­ty-relat­ed soft­ware devel­op­ment, cer­tain­ly much more than could be dis­cussed in a blog post like this or even in a stan­dard like ISO 13849–1. If you are con­tem­plat­ing devel­op­ing safe­ty relat­ed soft­ware and you are not famil­iar with the tech­niques need­ed to devel­op this kind of high-reli­a­bil­i­ty soft­ware, I would sug­gest you get help from a qual­i­fied devel­op­er. Keep in mind that there can be sig­nif­i­cant lia­bil­i­ty attached to safe­ty sys­tem fail­ures, includ­ing the deaths of peo­ple using your prod­uct. If you are devel­op­ing SRASW, I would also rec­om­mend fol­low­ing IEC 61508–3 as the basis for the devel­op­ment and relat­ed QA process­es.

 Definitions

3.1.36 appli­ca­tion soft­ware
soft­ware spe­cif­ic to the appli­ca­tion, imple­ment­ed by the machine man­u­fac­tur­er, and gen­er­al­ly con­tain­ing log­ic sequences, lim­its and expres­sions that con­trol the appro­pri­ate inputs, out­puts, cal­cu­la­tions and deci­sions nec­es­sary to meet the SRP/CS require­ments 3.1.37 embed­ded soft­ware firmware sys­tem soft­ware soft­ware that is part of the sys­tem sup­plied by the con­trol man­u­fac­tur­er and which is not acces­si­ble for mod­i­fi­ca­tion by the user of the machin­ery Note 1 to entry: Embed­ded soft­ware is usu­al­ly writ­ten in FVL.
Note 1 to entry: Embed­ded soft­ware is usu­al­ly writ­ten in FVL.
3.1.34 lim­it­ed vari­abil­i­ty lan­guage LVL
type of lan­guage that pro­vides the capa­bil­i­ty of com­bin­ing pre­de­fined, appli­ca­tion-spe­cif­ic library func­tions to imple­ment the safe­ty require­ments spec­i­fi­ca­tions
Note 1 to entry: Typ­i­cal exam­ples of LVL (lad­der log­ic, func­tion block dia­gram) are giv­en in IEC 61131–3.
Note 2 to entry: A typ­i­cal exam­ple 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­abil­i­ty lan­guage FVL
type of lan­guage that pro­vides the capa­bil­i­ty of imple­ment­ing a wide vari­ety of func­tions and appli­ca­tions EXAMPLE C, C++, Assem­bler.
Note 1 to entry: A typ­i­cal exam­ple of sys­tems using FVL: embed­ded sys­tems.
Note 2 to entry: In the field of machin­ery, FVL is found in embed­ded soft­ware and rarely in appli­ca­tion soft­ware. [SOURCE: IEC 61511–1:2003, 3.2.80.1.3, mod­i­fied.]
3.1.37 embed­ded soft­ware
firmware
sys­tem soft­ware
soft­ware that is part of the sys­tem sup­plied by the con­trol man­u­fac­tur­er and which is not acces­si­ble for mod­i­fi­ca­tion by the user of the machin­ery.
Note 1 to entry: Embed­ded soft­ware is usu­al­ly writ­ten in FVL.
Field Pro­gram­ma­ble Gate Array FPGA
A field-pro­gram­ma­ble gate array (FPGA) is an inte­grat­ed cir­cuit designed to be con­fig­ured by a cus­tomer or a design­er after man­u­fac­tur­ing – hence “field-pro­gram­ma­ble”. The FPGA con­fig­u­ra­tion is gen­er­al­ly spec­i­fied using a hard­ware descrip­tion lan­guage (HDL), sim­i­lar to that used for an appli­ca­tion-spe­cif­ic inte­grat­ed 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. Simp­son, Safe­ty crit­i­cal sys­tems hand­book. Ams­ter­dam: Else­vier/But­ter­worth-Heine­mann, 2011.

[0.2]  Elec­tro­mag­net­ic Com­pat­i­bil­i­ty for Func­tion­al Safe­ty, 1st ed. Steve­nage, UK: The Insti­tu­tion of Engi­neer­ing and Tech­nol­o­gy, 2008.

[0.3]  Overview of tech­niques and mea­sures relat­ed to EMC for Func­tion­al Safe­ty, 1st ed. Steve­nage, UK: Overview of tech­niques and mea­sures relat­ed to EMC for Func­tion­al Safe­ty, 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. Includ­ed in the last post of the series is the com­plete ref­er­ence list.

[1]     Safe­ty of machin­ery — Safe­ty-relat­ed parts of con­trol sys­tems — Part 1: Gen­er­al prin­ci­ples for design. 3rd Edi­tion. ISO Stan­dard 13849–1. 2015.

[2]     Safe­ty of machin­ery — Safe­ty-relat­ed parts of con­trol sys­tems — Part 2: Val­i­da­tion. 2nd Edi­tion. ISO Stan­dard 13849–2. 2012.

[3]      Safe­ty of machin­ery — Gen­er­al prin­ci­ples for design — Risk assess­ment and risk reduc­tion. ISO Stan­dard 12100. 2010.

[4]     Safe­guard­ing of Machin­ery. 2nd Edi­tion. CSA Stan­dard Z432. 2004.

[5]     Risk Assess­ment and Risk Reduc­tion- A Guide­line to Esti­mate, Eval­u­ate and Reduce Risks Asso­ci­at­ed with Machine Tools. ANSI Tech­ni­cal Report B11.TR3. 2000.

[6]    Safe­ty of machin­ery — Emer­gency stop func­tion — Prin­ci­ples for design. ISO Stan­dard 13850. 2015.

[7]     Func­tion­al safe­ty of electrical/electronic/programmable elec­tron­ic safe­ty-relat­ed sys­tems. 7 parts. IEC Stan­dard 61508. Edi­tion 2. 2010.

[8]     S. Joce­lyn, J. Bau­doin, Y. Chin­ni­ah, and P. Char­p­en­tier, “Fea­si­bil­i­ty study and uncer­tain­ties in the val­i­da­tion of an exist­ing safe­ty-relat­ed con­trol cir­cuit with the ISO 13849–1:2006 design stan­dard,” Reliab. Eng. Syst. Saf., vol. 121, pp. 104–112, Jan. 2014.

[9]    Guid­ance on the appli­ca­tion of ISO 13849–1 and IEC 62061 in the design of safe­ty-relat­ed con­trol sys­tems for machin­ery. IEC Tech­ni­cal Report TR 62061–1. 2010.

[10]     Safe­ty of machin­ery — Func­tion­al safe­ty of safe­ty-relat­ed elec­tri­cal, elec­tron­ic and pro­gram­ma­ble elec­tron­ic con­trol sys­tems. IEC Stan­dard 62061. 2005.

[11]    Guid­ance on the appli­ca­tion of ISO 13849–1 and IEC 62061 in the design of safe­ty-relat­ed con­trol sys­tems for machin­ery. IEC Tech­ni­cal Report 62061–1. 2010.

[12]    D. S. G. Nix, Y. Chin­ni­ah, F. Dosio, M. Fessler, F. Eng, and F. Schr­ev­er, “Link­ing Risk and Reliability—Mapping the out­put of risk assess­ment tools to func­tion­al safe­ty require­ments for safe­ty relat­ed con­trol sys­tems,” 2015.

[13]    Safe­ty of machin­ery. Safe­ty relat­ed parts of con­trol sys­tems. Gen­er­al prin­ci­ples for design. CEN Stan­dard EN 954–1. 1996.

[14]   Func­tion­al safe­ty of electrical/electronic/programmable elec­tron­ic safe­ty-relat­ed sys­tems — Part 2: Require­ments for electrical/electronic/programmable elec­tron­ic safe­ty-relat­ed sys­tems. IEC Stan­dard 61508–2. 2010.

[15]     Reli­a­bil­i­ty Pre­dic­tion of Elec­tron­ic Equip­ment. Mil­i­tary Hand­book MIL-HDBK-217F. 1991.

[16]     “IFA — Prac­ti­cal aids: Soft­ware-Assis­tent SISTEMA: Safe­ty Integri­ty — Soft­ware Tool for the Eval­u­a­tion of Machine Appli­ca­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­trotech­ni­cal Vocab­u­lary. IEC Inter­na­tion­al Elec­trotech­ni­cal Com­mis­sion, Gene­va, 2015.

[18]      M. Gen­tile and A. E. Sum­mers, “Com­mon Cause Fail­ure: How Do You Man­age 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. Rich­mond, Sur­rey, UK: HSE Health and Safe­ty Exec­u­tive, 2003.

[20]     Safe­guard­ing of Machin­ery. 3rd Edi­tion. CSA Stan­dard Z432. 2016.

[21]     O. Reg. 851, INDUSTRIAL ESTABLISHMENTS. Ontario, Cana­da, 1990.

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