Category: Complementary Protective Measures

Com­ple­men­tary pro­tec­tive mea­sures are things like Emer­gency Stop sys­tems. These mea­sures may not pre­vent injury, but can enhance a user’s abil­i­ty to lim­it the harm done.

Safe Drive Control including Safe Torque Off (STO)

This entry is part 12 of 13 in the series Emer­gency Stop

Ed. Note: This arti­cle was revised 25-Jul-17 to include infor­ma­tion on safe stand­still.

Safe Drive Control including STO

Variable Frequency Drive for conveyor speed control
Vari­able Fre­quen­cy Dri­ve for con­vey­or speed con­trol [1]
Motor dri­ves are every­where. From DC vari­able speed dri­ves and index­ing dri­ves, through AC Vari­able Fre­quen­cy dri­ves, ser­vo dri­ves and step­per motor dri­ves, the capa­bil­i­ties and the flex­i­bil­i­ty of these elec­tron­ic sys­tems has giv­en machine design­ers unprece­dent­ed capa­bil­i­ties when com­pared to basic relay or con­tac­tor-based motor starters. We now have the capa­bil­i­ty to con­trol mech­a­nisms using motors in ways that would have been hard to imag­ine at the begin­ning of the indus­tri­al rev­o­lu­tion. Along with these con­trol capa­bil­i­ties come safe­ty-relat­ed func­tions like Safe Torque Off (STO).

Since we are con­trol­ling machin­ery, safe­ty is always a con­cern. In the 1990’s when I start­ed design­ing machin­ery with motor dri­ves, deal­ing with safe­ty con­cerns usu­al­ly meant adding a suit­ably rat­ed con­tac­tor upstream of the dri­ve so that you could inter­rupt pow­er to the dri­ve in case some­thing went wrong. With ear­ly ser­vo dri­ves, inter­rupt­ing the sup­ply pow­er often meant los­ing posi­tion data or worse. Plac­ing con­tac­tors between the dri­ve and the motor solved this prob­lem, but inter­rupt­ing the sup­ply pow­er would some­times cause the dri­ve stage of the ser­vo con­troller to blow up if the switch-off hap­pened with the motor run­ning and under high load. Motor dri­ve man­u­fac­tur­ers respond­ed by pro­vid­ing con­tac­tors and oth­er com­po­nents built into their dri­ves, cre­at­ing a fea­ture called Safe Torque Off (STO).

STO describes a state where “The dri­ve is reli­ably torque-free” [2]. The func­tions dis­cussed in this arti­cle are described in detail in IEC 61800–5-2 [3]. The func­tions are also list­ed in [10, Table 5.2]. Note that only Safe Torque Off and Safe Stop 1 can be used for emer­gency stop func­tions. Safe Torque Off, Safe Stop 1 and Safe Stop 2 can be used for safe­ty-relat­ed stop func­tions ini­ti­at­ed by a safe­guard­ing device. This dis­tinc­tion, between emer­gency stop func­tions and safe­guard­ing func­tions, is an impor­tant one.

If you have been a read­er of this blog for a while, you may recall that I have dis­cussed stop cat­e­gories before. This arti­cle expands on those con­cepts with the focus on motor dri­ves and their stop­ping func­tions specif­i­cal­ly. I’ve also talked about Emer­gency Stop exten­sive­ly. You might be inter­est­ed in read­ing more about the e-stop func­tion, start­ing with the post “Emer­gency Stop – What’s so con­fus­ing about that?”

Safe Torque Off (STO)

Accord­ing to Siemens, “The STO func­tion is the most com­mon and basic dri­ve-inte­grat­ed safe­ty func­tion. It ensures that no torque-gen­er­at­ing ener­gy can con­tin­ue to act upon a motor and pre­vents unin­ten­tion­al start­ing.” Risk assess­ment of the machin­ery can iden­ti­fy the need for an STO func­tion. The devices used for this appli­ca­tion are described in IEC 60204–1 in clause 5.4 [4]. The design fea­tures for pre­ven­tion of unex­pect­ed start­ing are cov­ered in more detail in EN 1037 [5] or ISO 14118 [6]. If you are inter­est­ed in these stan­dards, ISO 14118 is in the process of being revised. A new ver­sion should be avail­able with­in 12–18 months.

The STO func­tion oper­ates as shown in Fig.1. The blue line rep­re­sents the dri­ve speed/velocity, V, on the y-axis, with time, t, on the x-axis. The orange arrow and the dot­ted line show the ini­ti­a­tion of the stop­ping func­tion.

Graph showing motor drive output over time when the STO function is activated.
Fig­ure 1 — Safe Torque Off func­tion [1]
At the begin­ning of the stop­ping process (orange arrow and dot­ted line), the dri­ve gate puls­es are imme­di­ate­ly shut off, remov­ing torque from the motor (i.e., zero torque). The speed of the dri­ven equip­ment will drop at a rate deter­mined by the sys­tem fric­tion and iner­tia until stand­still is achieved. The zero torque con­di­tion is main­tained until the safe­ty func­tion per­mits restart­ing (area out­lined with yellow/black zebra stripe). Note that dri­ve stand­still may occur if the fric­tion and iner­tia of the sys­tem per­mit, but it is pos­si­ble that the dri­ven equip­ment may coast for some time. You may be able to move the dri­ven equip­ment by hand or grav­i­ty with the dri­ve in the STO mode.

STO is an uncon­trolled stop­ping mode [4, 3.56]:

uncon­trolled stop
stop­ping of machine motion by remov­ing elec­tri­cal pow­er to the machine actu­a­tors
NOTE This def­i­n­i­tion does not imply any oth­er state of oth­er (for exam­ple, non-elec­tri­cal) stop­ping devices, for exam­ple, mechan­i­cal or hydraulic brakes that are out­side the scope of this stan­dard.

The def­i­n­i­tion above is impor­tant. Uncon­trolled stops are the most com­mon form of stop­ping used in machines of all types and is required as a basic func­tion for all machines. There are var­i­ous ways of achiev­ing STO, includ­ing the use of a dis­con­nect­ing device, emer­gency stop sys­tems, and gate inter­lock­ing sys­tems that remove pow­er from machine actu­a­tors.

The embod­i­ment of the uncon­trolled stop con­cept is Stop Cat­e­go­ry 0 [4, 9.2.2]:

stop cat­e­go­ry 0 — stop­ping by imme­di­ate removal of pow­er to the machine actu­a­tors (i.e., and uncon­trolled stop, see 3.56)

Stop cat­e­go­ry 0 is only appro­pri­ate where the machin­ery has lit­tle iner­tia, or where mechan­i­cal fric­tion is high enough that the stop­ping time is short. It may also be used in cas­es where the machin­ery has very high iner­tia, but only for nor­mal stop­ping when coast­ing time is not a fac­tor, not for safe­ty stop­ping func­tions where the time to a no-motion state is crit­i­cal.

There are a few oth­er stop­ping modes that are often con­fused with STO:

  • Safe Stop 1
  • Safe Stop 2
  • Safe Oper­at­ing Stop
  • Safe Stand­still

Let’s explore the dif­fer­ences.

Safe Stop 1 (SS1)

If a defined stop­ping time is need­ed, a con­trolled stop­ping func­tion will be required fol­lowed by entry into STO. This stop­ping func­tion is called “Safe Stop 1” (SS1).

SS1 is direct­ly relat­ed to Stop Cat­e­go­ry 1 [4, 9.2.2]. As described in [4], Stop Cat­e­go­ry 1 func­tions as fol­lows:

stop cat­e­go­ry 1 — a con­trolled stop (see 3.11) with pow­er avail­able to the machine actu­a­tors to achieve the stop and then removal of pow­er when the stop is achieved;

A “con­trolled stop” is defined in [4, 3.11]:

con­trolled stop
stop­ping of machine motion with elec­tri­cal pow­er to the machine actu­a­tor main­tained dur­ing the stop­ping process

Once the con­trolled stop is com­plet­ed, i.e., machine motion has stopped, the dri­ve may then be placed into STO (or cat­e­go­ry 0 stop). The stop­ping process is shown in Fig. 2 [7].

Graph showing the reduction of drive speed over time following the beginning of a controlled stopping process.
Fig­ure 2 — Safe Stop 1

The stop­ping process starts where the orange arrow and dot­ted line are shown. As com­pared to Fig. 1 where the decel­er­a­tion curve is gen­tle and expo­nen­tial, the active stop­ping peri­od in Fig. 2 is a lin­ear curve from oper­at­ing speed to zero speed. At the blue dot­ted line, the dri­ve enters and stays in STO. The yellow/black zebra striped area of the curve out­lines the com­plete stop­ping func­tion. This stop­ping method is typ­i­cal of many types of machin­ery, par­tic­u­lar­ly those with ser­vo-dri­ven mech­a­nisms.

Safe Stop 2 (SS2)

In some cas­es, the risk assess­ment may show that remov­ing pow­er com­plete­ly from a mech­a­nism will increase the risk. An exam­ple might be a ver­ti­cal axis where the motor dri­ve is used to main­tain the posi­tion of the tool­ing. Remov­ing pow­er from the dri­ve with the tool raised would result in the tool­ing crash­ing to the bot­tom of the axis in an uncon­trolled way. Not the desired way to achieve any type of stop!

There are var­i­ous to pre­vent this kind of occur­rence, but I’m going to lim­it the dis­cus­sion here to the Safe Stop 2 func­tion.

Let’s start with the def­i­n­i­tion [4, 3.11]:

con­trolled stop
stop­ping of machine motion with elec­tri­cal pow­er to the machine actu­a­tor main­tained dur­ing the stop­ping process

Wait! The def­i­n­i­tion of a con­trolled stop is exact­ly the same as a stop cat­e­go­ry 1, so what is the dif­fer­ence? For that we need to look to [4, 9.2.2]:

stop cat­e­go­ry 2 — a con­trolled stop with pow­er left avail­able to the machine actu­a­tors.

Emer­gency Stop func­tions can­not use Stop Cat­e­go­ry 2 [4, 9.2.5.4.2]. If you have tool­ing where Stop Cat­e­go­ry 2 is the most appro­pri­ate stop­ping func­tion under nor­mal con­di­tions, you will have to add an anoth­er means to pre­vent the axis from falling dur­ing the emer­gency stop. The addi­tion­al means could be a spring-set brake that is held released by the emer­gency stop sys­tem and is applied when the e-stop sys­tem removes pow­er from the tool­ing. There are many ways to achieve auto­mat­ic load-hold­ing besides brakes, but remem­ber, what­ev­er you choose it must be effec­tive in pow­er loss con­di­tions.

As shown in Fig. 3, the oper­a­tion of Safe Stop 2 dif­fers from Safe Stop 1 in that, instead of enter­ing into STO when motion stops, the sys­tem enters Safe Oper­at­ing Stop (SOS) [8], not STO. SOS is a Stop Cat­e­go­ry 2 func­tion. Full torque remains avail­able from the motor to hold the tool­ing in posi­tion. Safe stand­still is mon­i­tored by the dri­ve or oth­er means.

Graph showing speed reduction to zero, followed by entry into stop category 2.
Fig­ure 3 — Safe Stop 2

Depend­ing on the ISO 13849–1 PLr, or the IEC 62061 SILr need­ed for the appli­ca­tion, the dri­ve may not have high enough reli­a­bil­i­ty on its own. In this case, a sec­ond chan­nel may be required to ensure that safe stand­still mon­i­tor­ing is ade­quate­ly reli­able. This can be achieved by adding anoth­er means of stand­still detec­tion, like a sec­ond encoder, or a stand­still mon­i­tor­ing device. An exam­ple cir­cuit dia­gram show­ing this type of mon­i­tor­ing can be found in Fig. 4 [10, Fig. 8.37], show­ing a safe­ty PLC and dri­ve used to pro­vide an “inch­ing” or “jog” func­tion.

Circuit diagram for a safe inching mode using a motor drive. Taken from Fig 8.37 in BGIA Report 2/2008e
Fig­ure 4 — Safe­ly lim­it­ed speed for inch­ing mode — PLd, Cat. 3 [10]
In Fig. 4, the encoders are labelled G1 and G2. Both encoders are con­nect­ed to the safe­ty PLC to pro­vide two-chan­nel feed­back required for Cat­e­go­ry 3 archi­tec­ture. G1 is also con­nect­ed to the motor dri­ve for posi­tion and veloc­i­ty feed­back as need­ed for the appli­ca­tion. Note that this par­tic­u­lar dri­ve also has a con­tac­tor upstream, Q1, to pro­vide one chan­nel of the two required for Cat­e­go­ry 3. The sec­ond chan­nel would be pro­vid­ed by the pulse block­ing input on the dri­ve. For more on how this cir­cuit func­tions and how the func­tion­al safe­ty analy­sis is com­plet­ed, see [10].

Safe Operating Stop (SOS)

Dur­ing a safe oper­at­ing stop (SOS), the motor is brought to a spe­cif­ic posi­tion and held there by the dri­ve. Full torque is avail­able to keep the tool­ing in posi­tion. The stop is mon­i­tored safe­ly by the dri­ve. The func­tion is shown in Fig­ure 4 [9].

A graph showing a drive maintaining position following a stop
Fig­ure 5 — Safe Oper­at­ing Stop

In Fig. 5, the y-axis, s, rep­re­sents the posi­tion of the tool­ing, NOT the veloc­i­ty, while the x-axis rep­re­sents time, t. The start of the posi­tion hold­ing func­tion is shown by the orange arrow and dashed line. The peri­od fol­low­ing the green dashed line is the SOS peri­od.

SOS can­not be used for the emer­gency stop func­tion. Under cer­tain con­di­tions it may be used when guard inter­locks are opened, i.e., the guard door on a CNC lathe is opened so that the oper­a­tor can place a new work­piece.

There a quite a few addi­tion­al “safe” dri­ve func­tions. For more on these func­tions and how to imple­ment them, see [2] and appli­ca­tion data from your favourite dri­ve man­u­fac­tur­er. Ref­er­ence is also pro­vid­ed in [9, Table 5.2].

Safe Standstill

Safe stand­still is a con­di­tion where motion has stopped and is being mon­i­tored by a safe­ty-rat­ed device whose out­put sig­nals are used to con­trol the release of guard lock­ing devices. Safe stand­still is not the same as zero-speed because zero-speed can be achieved with­out the use of safe­ty-rat­ed con­trol com­po­nents and design, while safe stand­still requires both suit­able com­po­nents and design.

There are var­i­ous ways to achieve safe stand­still. Here are three approach­es [12]:

  1. Rota­tion sen­sors
    Sen­sors includ­ing prox­im­i­ty sen­sors, resolvers, and encoders can be used to mon­i­tor the motion of the dri­ve com­po­nents. A safe stand­still mon­i­tor­ing device is used to when stand­still has occurred.  When a machine has an unsta­ble rest posi­tion, a prox­im­i­ty sen­sor should be used to ensure the machine is in a safe con­di­tion before the guard lock­ing devices are released.
  2. Back EMF mon­i­tor­ing
    Back elec­tro­mo­tive force or Back EMF is the volt­age cre­at­ed in an elec­tric motor due to the rota­tion of the arma­ture in the mag­net­ic field in the motor. This volt­age oppos­es the applied volt­age and is approx­i­mate­ly pro­por­tion­al to the rota­tion­al speed of the motor. Back EMF remains after the sup­ply volt­age has been removed, allow­ing mon­i­tor­ing devices to indi­rect­ly mea­sure motor speed and stand­still.
  3. Fail­safe timer
    Fail­safe timers are time delay relays designed for use in safe­ty func­tions. Fail­safe timers can be used when the stop­ping per­for­mance of the machin­ery is con­sis­tent and known.
    Fol­low­ing removal of pow­er from the dri­ve motor, the time delay starts. At the end of the time delay, the relay releas­es the guard lock­ing devices.
    Reg­u­lar time delay relays can­not be used for this pur­pose, only fail-safe relays designed to be used in safe­ty func­tions can be used, along with suit­able safe­ty sys­tems design tech­niques like ISO 13849 or IEC 62061.

Conclusions

As you can see, there are sig­nif­i­cant dif­fer­ences between STO, SS1, SS2, SOS and Safe Stand­still. While these func­tions may be used togeth­er to achieve a par­tic­u­lar safe­ty func­tion, some are func­tions of the imple­men­ta­tion of the motor dri­ve, e.g., STO. Some are a func­tion of the design of the motor dri­ve itself, e.g., STO, SS1, SS2, and SOS, or the design of con­trols exter­nal to the motor dri­ve, e.g., safe stand­still. The sim­i­lar­i­ties between these var­i­ous func­tions can make it easy to con­fuse them. Care needs to be tak­en to ensure that the cor­rect tech­ni­cal approach is used when real­is­ing the safe­ty func­tion required by the risk assess­ment.

Ref­er­ences

[1]    “Vari­able Fre­quen­cy Dri­ves — Indus­tri­al Wiki — ode­sie by Tech Trans­fer”, Myodesie.com, 2017. [Online]. Avail­able: https://www.myodesie.com/wiki/index/returnEntry/id/3040. [Accessed: 19- Jun- 2017].

[2] “Safe Torque Off (STO) — Safe­ty Inte­grat­ed — Siemens”, Industry.siemens.com, 2017. [Online]. Avail­able: http://www.industry.siemens.com/topics/global/en/safety-integrated/machine-safety/product-portfolio/drive-technology/safety-functions/pages/safe-torque-off.aspx. [Accessed: 19- Jun- 2017].

[3]      Adjustable speed elec­tri­cal pow­er dri­ve sys­tems — Part 5–2: Safe­ty require­ments — Func­tion­al. IEC Stan­dard 61800–5-2. 2nd Ed. 2016.

[4]     Safe­ty of machin­ery — Elec­tri­cal equip­ment of machines — Part 1: Gen­er­al require­ments. IEC Stan­dard 60204–1. 2006.

[5]     Safe­ty of machin­ery — Pre­ven­tion of unex­pect­ed start-up. EN Stan­dard 1037+A1. 2008.

[6]     Safe­ty of machin­ery — Pre­ven­tion of unex­pect­ed start-up. ISO Stan­dard 14118. 2000.

[7]     “Safe Stop 1 (SS1) — Safe­ty Inte­grat­ed — Siemens”, Industry.siemens.com, 2017. [Online]. Avail­able: http://www.industry.siemens.com/topics/global/en/safety-integrated/machine-safety/product-portfolio/drive-technology/safety-functions/Pages/safe-stop1.aspx. [Accessed: 19- Jun- 2017].

[8]     “Safe Stop 2 (SS2) — Safe­ty Inte­grat­ed — Siemens”, Industry.siemens.com, 2017. [Online]. Avail­able: http://www.industry.siemens.com/topics/global/en/safety-integrated/machine-safety/product-portfolio/drive-technology/safety-functions/Pages/safe-stop2.aspx. [Accessed: 19- Jun- 2017].

[9]     “Safe Oper­at­ing Stop (SOS) — Safe­ty Inte­grat­ed — Siemens”, Industry.siemens.com, 2017. [Online]. Avail­able: http://www.industry.siemens.com/topics/global/en/safety-integrated/machine-safety/product-portfolio/drive-technology/safety-functions/Pages/safe-operating-stop.aspx. [Accessed: 19- Jun- 2017].

[10]     M. Hauke, M. Schae­fer, R. Apfeld, T. Boe­mer, M. Huelke, T. Borows­ki, K. Bülles­bach, M. Dor­ra, H. Foer­mer-Schae­fer, W. Grigule­witsch, K. Heimann, B. Köh­ler, M. Krauß, W. Küh­lem, O. Lohmaier, K. Mef­fert, J. Pil­ger, G. Reuß, U. Schus­ter, T. Seifen and H. Zil­li­gen, “Func­tion­al safe­ty of machine controls–Application of EN ISO 13849–Report 2/2008e”, BGIA – Insti­tute for Occu­pa­tion­al Safe­ty and Health of the Ger­man Social Acci­dent Insur­ance, Sankt Augustin, 2017.

[11]     “Glos­sary”, Schmersalusa.com, 2017. [Online]. Avail­able: http://www.schmersalusa.com/service/glossary/#c3616. [Accessed: 10- Jan-2018].

[12]     Schm­er­sal Tech Briefs: Safe Speed & Stand­still Mon­i­tor­ing. Schm­er­sal USA, 2017.

Acknowledgements

Spe­cial thanks go out to two of my reg­u­lar read­ers for sug­gest­ing this post: Matt Ernst and con­trols­girl, who com­ments fre­quent­ly. Thanks for the ideas and the ques­tions that sparked this post!

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

ISO 13849–1 Analysis — Part 2: Safety Requirement Specification

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

Developing the Safety Requirement Specification

The Safe­ty Require­ment Spec­i­fi­ca­tion sounds pret­ty heavy, but actu­al­ly, it is just a big name for a way to organ­ise the infor­ma­tion you need to have to analyse and design the safe­ty sys­tems for your machin­ery. Note that I am assum­ing that you are doing this in the “right” order, mean­ing that you are plan­ning the design before­hand, rather than try­ing to back-fill the doc­u­men­ta­tion after com­plet­ing the design. In either case, the process is the same, but get­ting the infor­ma­tion you need can be much hard­er after the fact, than before the doing the design work. Doing some aspects in a review mode is impos­si­ble, espe­cial­ly if a third par­ty to whom you have no access did the design work [8].

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

What goes into a Safety Requirements Specification?

For ref­er­ence, chap­ter 5 of ISO 13849–1 [1] cov­ers safe­ty require­ment spec­i­fi­ca­tions to some degree, but it needs some clar­i­fi­ca­tion I think. First of all, what is a safe­ty func­tion?

Safe­ty func­tions include any func­tion of the machine that has a direct pro­tec­tive effect for the work­er using the machin­ery. How­ev­er, using this def­i­n­i­tion, it is pos­si­ble to ignore some impor­tant func­tions. Com­ple­men­tary pro­tec­tive mea­sures, like emer­gency stop, can be missed because they are usu­al­ly “after the fact”, i.e., the injury occurs, and then the E-stop is pressed, so you can­not say that it has a “direct pro­tec­tive effect”. If we look at the def­i­n­i­tions in [1], we find:

3.1.20

safe­ty func­tion

func­tion of the machine whose fail­ure can result in an imme­di­ate increase of the risk(s)
[SOURCE: ISO 12100:2010, 3.30.]

Linking Risk to Functional Safety

Refer­ring to the risk assess­ment, any risk con­trol that pro­tects work­ers from some aspect of the machine oper­a­tion using a con­trol func­tion like an inter­locked gate, or by main­tain­ing a tem­per­a­ture below a crit­i­cal lev­el or speed at a safe lev­el, is a safe­ty func­tion. For exam­ple: if the tem­per­a­ture in a process ris­es too high, the process will explode; or if a shaft speed is too high (or too low) the tool may shat­ter and eject bro­ken pieces at high speed. There­fore, the tem­per­a­ture con­trol func­tion and the speed con­trol func­tion are safe­ty func­tions. These func­tions may also be process con­trol func­tions, but the poten­tial for an imme­di­ate increase in risk due to a fail­ure is what makes these func­tions safe­ty func­tions no mat­ter what else they may do.

[1, Table 8] gives you some exam­ples of var­i­ous kinds of safe­ty func­tions found on machines. The table is not inclu­sive — mean­ing there are many more safe­ty func­tions out there than are list­ed in the table. Your job is to fig­ure out which ones live in your machine. It is a bit like Poke­mon — ya got­ta catch ‘em all!

Basic Safety Requirement Specification

Each safe­ty func­tion must have a Per­for­mance Lev­el or a Safe­ty Integri­ty Lev­el assigned as part of the risk assess­ment. For each safe­ty func­tion, you need to devel­op the fol­low­ing infor­ma­tion:

Basic Safe­ty Require­ment Spec­i­fi­ca­tion
Item Descrip­tion
Safe­ty Func­tion Iden­ti­fi­ca­tion Name or oth­er ref­er­ences, e.g. “Access Gate Inter­lock” or “Haz­ard Zone 2.”
Func­tion­al Char­ac­ter­is­tics
  • Intend­ed use or fore­see­able mis­use of the machine rel­e­vant to the safe­ty func­tion
  • Oper­at­ing modes rel­e­vant to the safe­ty func­tion
  • Cycle time of the machine
  • Response time of the safe­ty func­tion
Emer­gency Oper­a­tion Is this an emer­gency oper­a­tion func­tion? If yes, what types of emer­gen­cies might be mit­i­gat­ed by this func­tion?
Inter­ac­tions What oper­at­ing modes require this func­tion to be oper­a­tional? Are there modes where this func­tion requires delib­er­ate bypass? These could include nor­mal work­ing modes (auto­mat­ic, man­u­al, set-up, changeover), and fault-find­ing or main­te­nance modes.
Behav­iour How you want the sys­tem to behave when the safe­ty func­tion is trig­gered, i.e., Pow­er is imme­di­ate­ly removed from the MIG welder using an IEC 60204–1 Cat­e­go­ry 0 stop func­tion, and robot motions are stopped using IEC 60204–1 Cate­go­ry 1 stop func­tion through the robot safe­ty stop input.

or

All hor­i­zon­tal pneu­mat­ic motions stop in their cur­rent posi­tions. Ver­ti­cal motions return to the raised or retract­ed posi­tions.

Also to be con­sid­ered is a pow­er loss con­di­tion. Should the sys­tem behave in the same way as if the safe­ty func­tion was trig­gered, not react at all, or do some­thing else? Con­sid­er ver­ti­cal axes that might require hold­ing brakes or oth­er mech­a­nisms to pre­vent pow­er loss caus­ing unex­pect­ed motion.
Machine State after trig­ger­ing What is the expect­ed state of the machine after trig­ger­ing the safe­ty func­tion? What is the recov­ery process?
Fre­quen­cy of Oper­a­tion How often do you expect this safe­ty func­tion to be used? A rea­son­able esti­mate is need­ed. More on this below.
Pri­or­i­ty of Oper­a­tion If simul­ta­ne­ous trig­ger­ing of mul­ti­ple safe­ty func­tions is pos­si­ble, which function(s) takes prece­dence? E.g., Emer­gency Stop always takes prece­dence over every­thing else. What hap­pens if you have a safe speed func­tion and a guard inter­lock that are asso­ci­at­ed because the inter­lock is part of a guard­ing func­tion cov­er­ing a shaft, and you need to trou­bleshoot the safe speed func­tion, so you need access to the shaft where the encoders are mount­ed?
Required Per­for­mance Lev­el I sug­gest record­ing the S, F, and P val­ues select­ed as well as the PLr val­ue select­ed for lat­er ref­er­ence.

Here’s an exam­ple table in MS Word for­mat that you can use as a start­ing point for your SRS doc­u­ments. Note that SRS can be much more detailed than this. If you want more infor­ma­tion on this, read IEC 61508–1, 7.10.2.

So, that is the min­i­mum. You can add lots more infor­ma­tion to the min­i­mum require­ments, but this will get you start­ed. If you want more infor­ma­tion on devel­op­ing the SRS, you will need to get a copy of IEC 61508 [7].

What’s Next?

Next, you need to be able to make some design deci­sions about sys­tem archi­tec­ture and com­po­nents. Cir­cuit archi­tec­tures have been dis­cussed at some length on the MS101 blog in the past, so I am not going to go through them again in this series. Instead, I will show you how to choose an archi­tec­ture based on your design goals in the next instal­ment. 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 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.

[7]     Func­tion­al safe­ty of electrical/electronic/programmable elec­tron­ic safe­ty-relat­ed sys­tems. Sev­en 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.