Safe Drive Control including STO

Ed. Note: This art­icle was revised 25-​Jul-​17 to include inform­a­tion on safe stand­still.

Safe Drive Control

Variable Frequency Drive for conveyor speed control
Variable Frequency Drive for con­vey­or speed con­trol [1]
Motor drives are every­where. From DC vari­able speed drives and index­ing drives, through AC Variable Frequency drives, servo drives and step­per motor drives, the cap­ab­il­it­ies and the flex­ib­il­ity of these elec­tron­ic sys­tems has giv­en machine design­ers unpre­ced­en­ted cap­ab­il­it­ies when com­pared to basic relay or contactor-​based motor starters. We now have the cap­ab­il­ity to con­trol mech­an­isms using motors in ways that would have been hard to ima­gine at the begin­ning of the indus­tri­al revolu­tion.

Since we are con­trolling machinery, safety is always a con­cern. In the 1990’s when I star­ted design­ing machinery with motor drives, deal­ing with safety con­cerns usu­ally meant adding a suit­ably rated con­tact­or upstream of the drive so that you could inter­rupt power to the drive in case some­thing went wrong. With early servo drives, inter­rupt­ing the sup­ply power often meant los­ing pos­i­tion data or worse, so con­tact­ors were placed between the drive and the motor. This occa­sion­ally caused the drive stage of the servo con­trol­ler to blow up if the switch-​off happened with the motor run­ning and under high load. Motor drive man­u­fac­tur­ers respon­ded by provid­ing con­tact­ors and oth­er com­pon­ents built into their drives, cre­at­ing a fea­ture called Safe Torque Off (STO).

STO describes a state where “The drive is reli­ably torque-​free” [2]. The func­tions dis­cussed in this art­icle are described in detail in IEC 61800−5−2 [3]. The func­tions are also lis­ted 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 safety-​related stop func­tions ini­ti­ated by a safe­guard­ing device.

If you have been a read­er of this blog for a while, you may recall that I have dis­cussed stop cat­egor­ies before. This art­icle expands on those con­cepts in rela­tion to motor drives and their stop­ping func­tions spe­cific­ally. I’ve also talked about Emergency Stop extens­ively. You might be inter­ested in read­ing more about the e-​stop func­tion in the post “Emergency Stop – What’s so con­fus­ing about that?”

Safe Torque Off (STO)

According to Siemens, “The STO func­tion is the most com­mon and basic drive-​integrated safety func­tion. It ensures that no torque-​generating energy can con­tin­ue to act upon a motor and pre­vents unin­ten­tion­al start­ing.” Risk assess­ment of the machinery can identi­fy the need for an STO func­tion. The devices used for this applic­a­tion are described in IEC 60204 – 1 in clause 5.4 [4]. The design fea­tures for pre­ven­tion of unex­pec­ted start­ing are covered in more detail in EN 1037 [5] or ISO 14118 [6]. If you are inter­ested in these stand­ards, ISO 14118 is in the pro­cess 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­res­ents the drive speed/​velocity, V, on the y-​axis, with time, t, on the x-​axis.

Graph showing motor drive output over time when the STO function is activated.
Figure 1 – Safe Torque Off func­tion [1]
At the begin­ning of the stop­ping pro­cess (orange arrow and dot­ted line), the drive gate pulses are imme­di­ately shut off, remov­ing torque from the motor (i.e., zero torque). The speed of the driv­en equip­ment will drop at a rate determ­ined by the sys­tem fric­tion and iner­tia until stand­still is achieved. The zero torque con­di­tion is then main­tained until the safety func­tion per­mits restart­ing (area out­lined with yellow/​black zebra stripe). Note that drive stand­still may occur if the fric­tion and iner­tia of the sys­tem per­mit, but it is pos­sible that the driv­en equip­ment may coast for some time. You may be able to move the driv­en equip­ment by hand or grav­ity with drive in STO.STO is an uncon­trolled stop [4, 3.56]:

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

uncon­trolled stop
stop­ping of machine motion by remov­ing elec­tric­al power to the machine actu­at­ors
NOTE This defin­i­tion does not imply any oth­er state of oth­er (for example, non-​electrical) stop­ping devices, for example, mech­an­ic­al or hydraul­ic brakes that are out­side the scope of this stand­ard.

The defin­i­tion above is import­ant. Uncontrolled 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. It can be achieved in a num­ber of ways, 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 power from machine actu­at­ors.

The concept of an uncon­trolled stop is embod­ied in stop cat­egory 0 [4, 9.2.2]:

stop cat­egory 0 — stop­ping by imme­di­ate remov­al of power to the machine actu­at­ors (i.e., and uncon­trolled stop, see 3.56)

Stop cat­egory 0 is only appro­pri­ate where the machinery has little iner­tia, or where mech­an­ic­al fric­tion is high enough that the stop­ping time is short. It may also be used in cases where the machinery has very high iner­tia, but only for nor­mal stop­ping when coast­ing time is not a factor, not for safety stop­ping func­tions where the time to a no-​motion state is crit­ic­al.

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

  • Safe Stop 1
  • Safe Stop 2
  • Safe Operating Stop
  • Safe Standstill

Let’s explore the dif­fer­ences.

Safe Stop 1 (SS1)

If a defined stop­ping time is needed, 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 dir­ectly related to Stop Category 1 [4, 9.2.2]. As described in [4], Stop Category 1 func­tions as fol­lows:

stop cat­egory 1 — a con­trolled stop (see 3.11) with power avail­able to the machine actu­at­ors to achieve the stop and then remov­al of power 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­tric­al power to the machine actu­at­or main­tained dur­ing the stop­ping pro­cess

Once the con­trolled stop is com­pleted, i.e., machine motion has stopped, the drive may then be placed into STO (or cat­egory 0 stop). The stop­ping pro­cess is shown in Fig. 2 [7].

Graph showing the reduction of drive speed over time following the beginning of a controlled stopping process.
Figure 2 – Safe Stop 1

The stop­ping pro­cess 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 gentle and expo­nen­tial, the act­ive 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 drive 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 meth­od is typ­ic­al of many types of machinery, par­tic­u­larly those with servo driv­en mech­an­isms.

Safe Stop 2 (SS2)

In some cases, the risk assess­ment may show that remov­ing power com­pletely from a mech­an­ism will increase the risk. An example might be a ver­tic­al axis where the motor drive is used to main­tain the pos­i­tion of the tool­ing. Removing power from the drive with the tool raised would res­ult in the tool­ing crash­ing to the bot­tom of the axis in an uncon­trolled way. Definitely NOT the desired way to achieve any kind of stop!

There are a num­ber of ways 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 defin­i­tion [4, 3.11]:

con­trolled stop
stop­ping of machine motion with elec­tric­al power to the machine actu­at­or main­tained dur­ing the stop­ping pro­cess

Wait! This is exactly the same as a stop cat­egory 1, so what is the dif­fer­ence? For that we need to look to [4, 9.2.2]:

stop cat­egory 2 — a con­trolled stop with power left avail­able to the machine actu­at­ors.

The first thing to know about stop cat­egory 2 is that this cat­egory can­not be used for emer­gency stop [4,]. If you have tool­ing where stop cat­egory 2 is the most appro­pri­ate stop under nor­mal con­di­tions, you will have to add an anoth­er means to pre­vent the axis from fall­ing dur­ing the emer­gency stop. This 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 power from the tool­ing. There are many ways to achieve auto­mat­ic load-​holding besides brakes, but remem­ber, whatever you choose it must be effect­ive in power 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 Operating Stop (SOS) [8], not STO. SOS is a stop cat­egory 2 func­tion. Full torque remains avail­able from the motor to hold the tool­ing in pos­i­tion. Safe stand­still is mon­itored by the drive or oth­er means.

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

Depending on the ISO 13849 – 1 PLr, or the IEC 62061 SILr needed for the applic­a­tion, the drive may not have high enough reli­ab­il­ity on its own. In this case, a second chan­nel may be required to ensure that safe stand­still mon­it­or­ing is adequately reli­able. This can be achieved by adding anoth­er means of stand­still detec­tion, like a second encoder, or a stand­still mon­it­or­ing device. An example cir­cuit dia­gram show­ing this type of mon­it­or­ing can be found in Fig. 4 [10, Fig. 8.37], show­ing a safety PLC and drive used to provide 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
Figure 4 — Safely lim­ited speed for inch­ing mode – PLd, Cat. 3 [10]
In Fig. 4, the encoders are labelled G1 and G2. Both encoders are con­nec­ted to the safety PLC to provide two-​channel feed­back required for Category 3 archi­tec­ture. G1 is also con­nec­ted to the motor drive for pos­i­tion and velo­city feed­back as needed for the applic­a­tion. Note that this par­tic­u­lar drive also has a con­tact­or upstream, Q1, to provide one chan­nel of the two required for Category 3. The second chan­nel would be provided by the pulse block­ing input on the drive. For more on how this cir­cuit func­tions and how the func­tion­al safety ana­lys­is is com­pleted, see [10].

Safe Operating Stop (SOS)

During a safe oper­at­ing stop (SOS), the motor is brought to a spe­cif­ic pos­i­tion and held there by the drive. Full torque is avail­able to keep the tool­ing in pos­i­tion. The stop is mon­itored safely by the drive. The func­tion is shown in Figure 4 [9].

A graph showing a drive maintaining position following a stop
Figure 5 — Safe Operating Stop

In Fig. 5, the y-​axis, s, rep­res­ents the pos­i­tion of the tool­ing, NOT the velo­city, while the x-​axis rep­res­ents time, t. The start of the pos­i­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­at­or can place a new work­piece.

There a quite a few addi­tion­al “safe” drive func­tions. For more on these func­tions and how to imple­ment them, see [2] and applic­a­tion data from your favour­ite drive man­u­fac­turer. Reference is also provided in [9, Table 5.2].

Safe Standstill

Safe stand­still is a con­di­tion where motion has stopped and is being mon­itored by a safety-​rated 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 without the use of safety rated con­trol com­pon­ents and design, while safe stand­still requires both suit­able com­pon­ents and design.

There are a num­ber of ways to achieve safe stand­still. Here are three com­mon approaches [12]:

  1. Rotation sensors
    Sensors includ­ing prox­im­ity sensors, resolv­ers, and encoders can be used to mon­it­or the motion of the drive com­pon­ents. A safe stand­still mon­it­or­ing device is used to when stand­still has occurred.  When a machine has an unstable rest pos­i­tion, a prox­im­ity sensor 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­it­or­ing
    Back elec­tro­mot­ive force or Back EMF is the voltage cre­ated in an elec­tric motor due to the rota­tion of the arma­ture in the mag­net­ic field in the motor. This voltage opposes the applied voltage and is approx­im­ately pro­por­tion­al to the rota­tion­al speed of the motor. Back EMF remains after the sup­ply voltage has been removed, allow­ing mon­it­or­ing devices to indir­ectly meas­ure motor speed and stand­still.
  3. Failsafe timer
    Failsafe timers are time delay relays designed for use in safety func­tions. Failsafe timers can be used when the stop­ping per­form­ance of the machinery is con­sist­ent and known.
    Following remov­al of power from the drive motor, the time delay starts. At the end of the time delay, the relay releases the guard lock­ing devices.
    Regular time delay relays can­not be used for this pur­pose, only fail-​safe relays designed to be used in safety func­tions can be used, along with suit­able safety sys­tems design tech­niques like ISO 13849 or IEC 62061.


As you can see, there are sig­ni­fic­ant dif­fer­ences between STO, SS1, SS2, SOS and Safe Standstill. While these func­tions may be used togeth­er to achieve a par­tic­u­lar safety func­tion, some are func­tions of the imple­ment­a­tion of the motor drive, e.g., STO, a func­tion of the design of the motor drive itself, e.g., STO, SS1, SS2, and SOS, or the design of con­trols extern­al to the motor drive, e.g., safe stand­still. The sim­il­ar­it­ies between these vari­ous func­tions can make it easy to con­fuse them. Care needs to be taken to ensure that the cor­rect tech­nic­al approach is used when real­ising the safety func­tion required by the risk assess­ment.


[1]    “Variable Frequency Drives – Industrial Wiki – odesie by Tech Transfer”, Myodesie​.com, 2017. [Online]. Available: https://​www​.myo​desie​.com/​w​i​k​i​/​i​n​d​e​x​/​r​e​t​u​r​n​E​n​t​r​y​/​i​d​/​3​040. [Accessed: 19- Jun- 2017]. 

[2] “Safe Torque Off (STO) – Safety Integrated – Siemens”, Industry​.siemens​.com, 2017. [Online]. Available: http://​www​.industry​.siemens​.com/​t​o​p​i​c​s​/​g​l​o​b​a​l​/​e​n​/​s​a​f​e​t​y​-​i​n​t​e​g​r​a​t​e​d​/​m​a​c​h​i​n​e​-​s​a​f​e​t​y​/​p​r​o​d​u​c​t​-​p​o​r​t​f​o​l​i​o​/​d​r​i​v​e​-​t​e​c​h​n​o​l​o​g​y​/​s​a​f​e​t​y​-​f​u​n​c​t​i​o​n​s​/​p​a​g​e​s​/​s​a​f​e​-​t​o​r​q​u​e​-​o​f​f​.​a​spx. [Accessed: 19- Jun- 2017].

[3]      Adjustable speed elec­tric­al power drive sys­tems – Part 5 – 2: Safety require­ments – Functional. IEC Standard 61800−5−2. 2nd Ed. 2016.

[4]     Safety of machinery — Electrical equip­ment of machines — Part 1: General require­ments. IEC Standard 60204 – 1. 2006.

[5]     Safety of machinery — Prevention of unex­pec­ted start-​up. EN Standard 1037+A1. 2008.

[6]     Safety of machinery — Prevention of unex­pec­ted start-​up. ISO Standard 14118. 2000.

[7]     “Safe Stop 1 (SS1) – Safety Integrated – Siemens”, Industry​.siemens​.com, 2017. [Online]. Available: http://​www​.industry​.siemens​.com/​t​o​p​i​c​s​/​g​l​o​b​a​l​/​e​n​/​s​a​f​e​t​y​-​i​n​t​e​g​r​a​t​e​d​/​m​a​c​h​i​n​e​-​s​a​f​e​t​y​/​p​r​o​d​u​c​t​-​p​o​r​t​f​o​l​i​o​/​d​r​i​v​e​-​t​e​c​h​n​o​l​o​g​y​/​s​a​f​e​t​y​-​f​u​n​c​t​i​o​n​s​/​P​a​g​e​s​/​s​a​f​e​-​s​t​o​p​1​.​a​spx. [Accessed: 19- Jun- 2017].

[8]     “Safe Stop 2 (SS2) – Safety Integrated – Siemens”, Industry​.siemens​.com, 2017. [Online]. Available: http://​www​.industry​.siemens​.com/​t​o​p​i​c​s​/​g​l​o​b​a​l​/​e​n​/​s​a​f​e​t​y​-​i​n​t​e​g​r​a​t​e​d​/​m​a​c​h​i​n​e​-​s​a​f​e​t​y​/​p​r​o​d​u​c​t​-​p​o​r​t​f​o​l​i​o​/​d​r​i​v​e​-​t​e​c​h​n​o​l​o​g​y​/​s​a​f​e​t​y​-​f​u​n​c​t​i​o​n​s​/​P​a​g​e​s​/​s​a​f​e​-​s​t​o​p​2​.​a​spx. [Accessed: 19- Jun- 2017].

[9]     “Safe Operating Stop (SOS) – Safety Integrated – Siemens”, Industry​.siemens​.com, 2017. [Online]. Available: http://​www​.industry​.siemens​.com/​t​o​p​i​c​s​/​g​l​o​b​a​l​/​e​n​/​s​a​f​e​t​y​-​i​n​t​e​g​r​a​t​e​d​/​m​a​c​h​i​n​e​-​s​a​f​e​t​y​/​p​r​o​d​u​c​t​-​p​o​r​t​f​o​l​i​o​/​d​r​i​v​e​-​t​e​c​h​n​o​l​o​g​y​/​s​a​f​e​t​y​-​f​u​n​c​t​i​o​n​s​/​P​a​g​e​s​/​s​a​f​e​-​o​p​e​r​a​t​i​n​g​-​s​t​o​p​.​a​spx. [Accessed: 19- Jun- 2017].

[10]     M. Hauke, M. Schaefer, R. Apfeld, T. Boemer, M. Huelke, T. Borowski, K. Büllesbach, M. Dorra, H. Foermer-​Schaefer, W. Grigulewitsch, K. Heimann, B. Köhler, M. Krauß, W. Kühlem, O. Lohmaier, K. Meffert, J. Pilger, G. Reuß, U. Schuster, T. Seifen and H. Zilligen, “Functional safety of machine con­trols – Application of EN ISO 13849 – Report 2/​2008e”, BGIA – Institute for Occupational Safety and Health of the German Social Accident Insurance, Sankt Augustin, 2017.

[11]     “Glossary”, Schmersalusa​.com, 2017. [Online]. Available: http://​www​.schmersa​lusa​.com/​c​m​s​1​7​/​o​p​e​n​c​m​s​/​h​t​m​l​/​e​n​/​s​e​r​v​i​c​e​/​g​l​o​s​s​a​r​y​.​h​t​m​l#S. [Accessed: 25- Jul- 2017].

[12]     Schmersal Tech Briefs: Safe Speed & Standstill Monitoring. Schmersal USA, 2014.


Special 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­quently. 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 ana­lys­is

Safety-​Related Software

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

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

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

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

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


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

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

Avoiding Faults

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

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

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

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

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

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

Two Approaches to Software Design

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

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

Preconfigured Building-​Block Software

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

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

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

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

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

Fully Customised Software

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

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

Process requirements

Safety-​Related Embedded Software (SRESW)

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

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

Safety-​Related Application Software (SRASW)

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

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

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

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


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


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

Book List

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

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

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

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

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


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

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

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

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

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

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

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

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

[8]     S. Jocelyn, J. Baudoin, Y. Chinniah, and P. Charpentier, “Feasibility study and uncer­tain­ties in the val­id­a­tion of an exist­ing safety-​related con­trol cir­cuit with the ISO 13849 – 1:2006 design stand­ard,” Reliab. Eng. Syst. Saf., vol. 121, pp. 104 – 112, Jan. 2014.

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

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

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

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

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

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

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

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

[17]      “fail­ure mode”, 192−03−17, International Electrotechnical Vocabulary. IEC International Electrotechnical Commission, Geneva, 2015.

[18]      M. Gentile and A. E. Summers, “Common Cause Failure: How Do You Manage Them?,” Process Saf. Prog., vol. 25, no. 4, pp. 331 – 338, 2006.

[19]     Out of Control — Why con­trol sys­tems go wrong and how to pre­vent fail­ure, 2nd ed. Richmond, Surrey, UK: HSE Health and Safety Executive, 2003.

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

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

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

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

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

Developing the Safety Requirement Specification

The Safety Requirement Specification sounds pretty heavy, but actu­ally, it is just a big name for a way to organ­ise the inform­a­tion you need to have to ana­lyse and design the safety sys­tems for your machinery. 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­ment­a­tion after com­plet­ing the design. In either case, the pro­cess is the same, but get­ting the inform­a­tion you need can be much harder after the fact, than before the doing the design work. Doing some aspects in a review mode is impossible, espe­cially if a third party 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, chapter 5 of ISO 13849 – 1 [1] cov­ers safety require­ment spe­cific­a­tions to some degree, but it needs some cla­ri­fic­a­tion I think. First of all, what is a safety func­tion?

Safety func­tions include any func­tion of the machine that has a dir­ect pro­tect­ive effect for the work­er using the machinery. However, using this defin­i­tion, it is pos­sible to ignore some import­ant func­tions. Complementary pro­tect­ive meas­ures, like emer­gency stop, can be missed because they are usu­ally “after the fact”, i.e., the injury occurs, and then the E-​stop is pressed, so you can­not say that it has a “dir­ect pro­tect­ive effect”. If we look at the defin­i­tions in [1], we find:


safety func­tion

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

Linking Risk to Functional Safety

Referring 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­at­ure below a crit­ic­al level or speed at a safe level, is a safety func­tion. For example: if the tem­per­at­ure in a pro­cess rises too high, the pro­cess will explode; or if a shaft speed is too high (or too low) the tool may shat­ter and eject broken pieces at high speed. Therefore, the tem­per­at­ure con­trol func­tion and the speed con­trol func­tion are safety func­tions. These func­tions may also be pro­cess 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 safety func­tions no mat­ter what else they may do.

[1, Table 8] gives you some examples of vari­ous kinds of safety func­tions found on machines. The table is not inclus­ive – mean­ing there are many more safety func­tions out there than are lis­ted in the table. Your job is to fig­ure out which ones live in your machine. It is a bit like Pokemon – ya gotta catch ‘em all!

Basic Safety Requirement Specification

Each safety func­tion must have a Performance Level or a Safety Integrity Level assigned as part of the risk assess­ment. For each safety func­tion, you need to devel­op the fol­low­ing inform­a­tion:

Basic Safety Requirement Specification
Item Description
Safety Function Identification Name or oth­er ref­er­ences, e.g. “Access Gate Interlock” or “Hazard Zone 2.”
Functional Characteristics
  • Intended use or fore­see­able mis­use of the machine rel­ev­ant to the safety func­tion
  • Operating modes rel­ev­ant to the safety func­tion
  • Cycle time of the machine
  • Response time of the safety func­tion
Emergency Operation Is this an emer­gency oper­a­tion func­tion? If yes, what types of emer­gen­cies might be mit­ig­ated by this func­tion?
Interactions What oper­at­ing modes require this func­tion to be oper­a­tion­al? Are there modes where this func­tion requires delib­er­ate bypass? These could include nor­mal work­ing modes (auto­mat­ic, manu­al, set-​up, changeover), and fault-​finding or main­ten­ance modes.
Behaviour How you want the sys­tem to behave when the safety func­tion is triggered, i.e., Power is imme­di­ately removed from the MIG weld­er using an IEC 60204 – 1 Category 0 stop func­tion, and robot motions are stopped using IEC 60204 – 1 Category 1 stop func­tion through the robot safety stop input.


All hori­zont­al pneu­mat­ic motions stop in their cur­rent pos­i­tions. Vertical motions return to the raised or retrac­ted pos­i­tions.

Also to be con­sidered is a power loss con­di­tion. Should the sys­tem behave in the same way as if the safety func­tion was triggered, not react at all, or do some­thing else? Consider ver­tic­al axes that might require hold­ing brakes or oth­er mech­an­isms to pre­vent power loss caus­ing unex­pec­ted motion.

Machine State after trig­ger­ing What is the expec­ted state of the machine after trig­ger­ing the safety func­tion? What is the recov­ery pro­cess?
Frequency of Operation How often do you expect this safety func­tion to be used? A reas­on­able estim­ate is needed. More on this below.
Priority of Operation If sim­ul­tan­eous trig­ger­ing of mul­tiple safety func­tions is pos­sible, which function(s) takes pre­ced­ence? E.g., Emergency Stop always takes pre­ced­ence over everything else. What hap­pens if you have a safe speed func­tion and a guard inter­lock that are asso­ci­ated because the inter­lock is part of a guard­ing func­tion cov­er­ing a shaft, and you need to troubleshoot the safe speed func­tion, so you need access to the shaft where the encoders are moun­ted?
Required Performance Level I sug­gest record­ing the S, F, and P val­ues selec­ted as well as the PLr value selec­ted for later ref­er­ence.

Here’s an example table in MS Word format 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 inform­a­tion on this, read IEC 61508 – 1, 7.10.2.

So, that is the min­im­um. You can add lots more inform­a­tion to the min­im­um require­ments, but this will get you star­ted. If you want more inform­a­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 decisions about sys­tem archi­tec­ture and com­pon­ents. Circuit 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 Assessment: Basics and Benchmarks, 1st ed. Ann Arbor, MI USA: DSE, 2004.

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

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

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


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

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

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

[8]     S. Jocelyn, J. Baudoin, Y. Chinniah, and P. Charpentier, “Feasibility study and uncer­tain­ties in the val­id­a­tion of an exist­ing safety-​related con­trol cir­cuit with the ISO 13849 – 1:2006 design stand­ard,” Reliab. Eng. Syst. Saf., vol. 121, pp. 104 – 112, Jan. 2014.