When it comes to emergency stop devices there is no doubt that the red mushroom-head push button is the most common – they seem to be everywhere. The second most common emergency stop device is the pull-cord, and like the light-curtain in safeguarding, the pull-cord is probably the most misapplied emergency stop device. Continue reading “Emergency Stop Pull-Cords”
Ed. Note: This article was revised 25-Jul-17 to include information on safe standstill.
Safe Drive Control including STOMotor drives are everywhere. From DC variable speed drives and indexing drives, through AC Variable Frequency drives, servo drives and stepper motor drives, the capabilities and the flexibility of these electronic systems has given machine designers unprecedented capabilities when compared to basic relay or contactor-based motor starters. We now have the capability to control mechanisms using motors in ways that would have been hard to imagine at the beginning of the industrial revolution. Along with these control capabilities come safety-related functions like Safe Torque Off (STO).
Since we are controlling machinery, safety is always a concern. In the 1990’s when I started designing machinery with motor drives, dealing with safety concerns usually meant adding a suitably rated contactor upstream of the drive so that you could interrupt power to the drive in case something went wrong. With early servo drives, interrupting the supply power often meant losing position data or worse. Placing contactors between the drive and the motor solved this problem, but interrupting the supply power would sometimes cause the drive stage of the servo controller to blow up if the switch-off happened with the motor running and under high load. Motor drive manufacturers responded by providing contactors and other components built into their drives, creating a feature called Safe Torque Off (STO).
STO describes a state where “The drive is reliably torque-free” . The functions discussed in this article are described in detail in IEC 61800 – 5-2 . The functions are also listed in [10, Table 5.2]. Note that only Safe Torque Off and Safe Stop 1 can be used for emergency stop functions. Safe Torque Off, Safe Stop 1 and Safe Stop 2 can be used for safety-related stop functions initiated by a safeguarding device. This distinction, between emergency stop functions and safeguarding functions, is an important one.
If you have been a reader of this blog for a while, you may recall that I have discussed stop categories before. This article expands on those concepts with the focus on motor drives and their stopping functions specifically. I’ve also talked about Emergency Stop extensively. You might be interested in reading more about the e-stop function, starting with the post “Emergency Stop – What’s so confusing about that?”
Safe Torque Off (STO)
According to Siemens, “The STO function is the most common and basic drive-integrated safety function. It ensures that no torque-generating energy can continue to act upon a motor and prevents unintentional starting.” Risk assessment of the machinery can identify the need for an STO function. The devices used for this application are described in IEC 60204 – 1 in clause 5.4 . The design features for prevention of unexpected starting are covered in more detail in EN 1037  or ISO 14118 . If you are interested in these standards, ISO 14118 is in the process of being revised. A new version should be available within 12 – 18 months.
The STO function operates as shown in Fig.1. The blue line represents the drive speed/velocity, V, on the y-axis, with time, t, on the x-axis. The orange arrow and the dotted line show the initiation of the stopping function.At the beginning of the stopping process (orange arrow and dotted line), the drive gate pulses are immediately shut off, removing torque from the motor (i.e., zero torque). The speed of the driven equipment will drop at a rate determined by the system friction and inertia until standstill is achieved. The zero torque condition is maintained until the safety function permits restarting (area outlined with yellow/black zebra stripe). Note that drive standstill may occur if the friction and inertia of the system permit, but it is possible that the driven equipment may coast for some time. You may be able to move the driven equipment by hand or gravity with the drive in the STO mode.
STO is an uncontrolled stopping mode [4, 3.56]:
- uncontrolled stop
- stopping of machine motion by removing electrical power to the machine actuators
- NOTE This definition does not imply any other state of other (for example, non-electrical) stopping devices, for example, mechanical or hydraulic brakes that are outside the scope of this standard.
The definition above is important. Uncontrolled stops are the most common form of stopping used in machines of all types and is required as a basic function for all machines. There are various ways of achieving STO, including the use of a disconnecting device, emergency stop systems, and gate interlocking systems that remove power from machine actuators.
The embodiment of the uncontrolled stop concept is Stop Category 0 [4, 9.2.2]:
stop category 0 — stopping by immediate removal of power to the machine actuators (i.e., and uncontrolled stop, see 3.56)
Stop category 0 is only appropriate where the machinery has little inertia, or where mechanical friction is high enough that the stopping time is short. It may also be used in cases where the machinery has very high inertia, but only for normal stopping when coasting time is not a factor, not for safety stopping functions where the time to a no-motion state is critical.
There are a few other stopping modes that are often confused with STO:
- Safe Stop 1
- Safe Stop 2
- Safe Operating Stop
- Safe Standstill
Let’s explore the differences.
Safe Stop 1 (SS1)
If a defined stopping time is needed, a controlled stopping function will be required followed by entry into STO. This stopping function is called “Safe Stop 1” (SS1).
SS1 is directly related to Stop Category 1 [4, 9.2.2]. As described in , Stop Category 1 functions as follows:
stop category 1 — a controlled stop (see 3.11) with power available to the machine actuators to achieve the stop and then removal of power when the stop is achieved;
A “controlled stop” is defined in [4, 3.11]:
- controlled stop
- stopping of machine motion with electrical power to the machine actuator maintained during the stopping process
Once the controlled stop is completed, i.e., machine motion has stopped, the drive may then be placed into STO (or category 0 stop). The stopping process is shown in Fig. 2 .
The stopping process starts where the orange arrow and dotted line are shown. As compared to Fig. 1 where the deceleration curve is gentle and exponential, the active stopping period in Fig. 2 is a linear curve from operating speed to zero speed. At the blue dotted line, the drive enters and stays in STO. The yellow/black zebra striped area of the curve outlines the complete stopping function. This stopping method is typical of many types of machinery, particularly those with servo-driven mechanisms.
Safe Stop 2 (SS2)
In some cases, the risk assessment may show that removing power completely from a mechanism will increase the risk. An example might be a vertical axis where the motor drive is used to maintain the position of the tooling. Removing power from the drive with the tool raised would result in the tooling crashing to the bottom of the axis in an uncontrolled way. Not the desired way to achieve any type of stop!
There are various to prevent this kind of occurrence, but I’m going to limit the discussion here to the Safe Stop 2 function.
Let’s start with the definition [4, 3.11]:
- controlled stop
- stopping of machine motion with electrical power to the machine actuator maintained during the stopping process
Wait! The definition of a controlled stop is exactly the same as a stop category 1, so what is the difference? For that we need to look to [4, 9.2.2]:
stop category 2 — a controlled stop with power left available to the machine actuators.
Emergency Stop functions cannot use Stop Category 2 [4, 18.104.22.168.2]. If you have tooling where Stop Category 2 is the most appropriate stopping function under normal conditions, you will have to add an another means to prevent the axis from falling during the emergency stop. The additional means could be a spring-set brake that is held released by the emergency stop system and is applied when the e-stop system removes power from the tooling. There are many ways to achieve automatic load-holding besides brakes, but remember, whatever you choose it must be effective in power loss conditions.
As shown in Fig. 3, the operation of Safe Stop 2 differs from Safe Stop 1 in that, instead of entering into STO when motion stops, the system enters Safe Operating Stop (SOS) , not STO. SOS is a Stop Category 2 function. Full torque remains available from the motor to hold the tooling in position. Safe standstill is monitored by the drive or other means.
Depending on the ISO 13849 – 1 PLr, or the IEC 62061 SILr needed for the application, the drive may not have high enough reliability on its own. In this case, a second channel may be required to ensure that safe standstill monitoring is adequately reliable. This can be achieved by adding another means of standstill detection, like a second encoder, or a standstill monitoring device. An example circuit diagram showing this type of monitoring can be found in Fig. 4 [10, Fig. 8.37], showing a safety PLC and drive used to provide an “inching” or “jog” function.In Fig. 4, the encoders are labelled G1 and G2. Both encoders are connected to the safety PLC to provide two-channel feedback required for Category 3 architecture. G1 is also connected to the motor drive for position and velocity feedback as needed for the application. Note that this particular drive also has a contactor upstream, Q1, to provide one channel of the two required for Category 3. The second channel would be provided by the pulse blocking input on the drive. For more on how this circuit functions and how the functional safety analysis is completed, see .
Safe Operating Stop (SOS)
During a safe operating stop (SOS), the motor is brought to a specific position and held there by the drive. Full torque is available to keep the tooling in position. The stop is monitored safely by the drive. The function is shown in Figure 4 .
In Fig. 5, the y-axis, s, represents the position of the tooling, NOT the velocity, while the x-axis represents time, t. The start of the position holding function is shown by the orange arrow and dashed line. The period following the green dashed line is the SOS period.
SOS cannot be used for the emergency stop function. Under certain conditions it may be used when guard interlocks are opened, i.e., the guard door on a CNC lathe is opened so that the operator can place a new workpiece.
There a quite a few additional “safe” drive functions. For more on these functions and how to implement them, see  and application data from your favourite drive manufacturer. Reference is also provided in [9, Table 5.2].
Safe standstill is a condition where motion has stopped and is being monitored by a safety-rated device whose output signals are used to control the release of guard locking devices. Safe standstill is not the same as zero-speed because zero-speed can be achieved without the use of safety-rated control components and design, while safe standstill requires both suitable components and design.
There are various ways to achieve safe standstill. Here are three approaches :
- Rotation sensors
Sensors including proximity sensors, resolvers, and encoders can be used to monitor the motion of the drive components. A safe standstill monitoring device is used to when standstill has occurred. When a machine has an unstable rest position, a proximity sensor should be used to ensure the machine is in a safe condition before the guard locking devices are released.
- Back EMF monitoring
Back electromotive force or Back EMF is the voltage created in an electric motor due to the rotation of the armature in the magnetic field in the motor. This voltage opposes the applied voltage and is approximately proportional to the rotational speed of the motor. Back EMF remains after the supply voltage has been removed, allowing monitoring devices to indirectly measure motor speed and standstill.
- Failsafe timer
Failsafe timers are time delay relays designed for use in safety functions. Failsafe timers can be used when the stopping performance of the machinery is consistent and known.
Following removal of power from the drive motor, the time delay starts. At the end of the time delay, the relay releases the guard locking devices.
Regular time delay relays cannot be used for this purpose, only fail-safe relays designed to be used in safety functions can be used, along with suitable safety systems design techniques like ISO 13849 or IEC 62061.
As you can see, there are significant differences between STO, SS1, SS2, SOS and Safe Standstill. While these functions may be used together to achieve a particular safety function, some are functions of the implementation of the motor drive, e.g., STO. Some are a function of the design of the motor drive itself, e.g., STO, SS1, SS2, and SOS, or the design of controls external to the motor drive, e.g., safe standstill. The similarities between these various functions can make it easy to confuse them. Care needs to be taken to ensure that the correct technical approach is used when realising the safety function required by the risk assessment.
 “Variable Frequency Drives – Industrial Wiki – odesie by Tech Transfer”, Myodesie.com, 2017. [Online]. Available: https://www.myodesie.com/wiki/index/returnEntry/id/3040. [Accessed: 19- Jun- 2017].
 “Safe Torque Off (STO) – Safety Integrated – Siemens”, Industry.siemens.com, 2017. [Online]. Available: 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].
 “Safe Stop 1 (SS1) – Safety Integrated – Siemens”, Industry.siemens.com, 2017. [Online]. Available: 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].
 “Safe Stop 2 (SS2) – Safety Integrated – Siemens”, Industry.siemens.com, 2017. [Online]. Available: 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].
 “Safe Operating Stop (SOS) – Safety Integrated – Siemens”, Industry.siemens.com, 2017. [Online]. Available: 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].
 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 controls – Application of EN ISO 13849 – Report 2/2008e”, BGIA – Institute for Occupational Safety and Health of the German Social Accident Insurance, Sankt Augustin, 2017.
 “Glossary”, Schmersalusa.com, 2017. [Online]. Available: http://www.schmersalusa.com/service/glossary/#c3616. [Accessed: 10- Jan-2018].
 Schmersal Tech Briefs: Safe Speed & Standstill Monitoring. Schmersal USA, 2017.
Special thanks go out to two of my regular readers for suggesting this post: Matt Ernst and controlsgirl, who comments frequently. Thanks for the ideas and the questions that sparked this post!
Up to this point, I have been discussing the basic processes used for the design of safety-related parts of control systems. The underlying assumption is that these techniques apply to the design of hardware used for safety purposes. The remaining question focuses on the design and development of safety-related software that runs on that hardware. If you have not read the rest of this series and would like to catch up first, you can find it here.
In this discussion of safety-related software, keep in mind that I am talking about software that is only intended to reduce risk. Some platforms that are not well suited for safety software, primarily common off-the-shelf (COTS) operating systems like Windows, MacOS and Linux. Generally speaking, these operating systems are too complex and subject to unanticipated changes to be suitable for high-reliability applications. There is nothing wrong with using these systems for annunciation and monitoring functions, but the safety functions should run on more predictable platforms.
The methodology discussed in ISO 13849 – 1 is usable up to PLd. At the end of the Scope we find Note 4:
NOTE 4 For safety-related embedded software for components with PLr = e, see IEC 61508 – 3:1998, Clause 7.
As you can see, for very high-reliability systems, i.e., PLe/SIL3 or SIL4, it is necessary to move to IEC 61508. The methods discussed here are based on ISO 13849 – 1:2015, Chapter 4.6.
There are two goals for safety-related software development activities:
- Avoid faults
- Generate readable, understandable, testable and maintainable software
Fig. 1 [1, Fig. 6] shows the “V-model” for software development. This approach to software design incorporates both validation and verification, and when correctly implemented will result in software that meets the design specifications.
If you aren’t sure what the difference is between verification and validation, I remember it is this way: Validation means “Are we building the right thing?”, and verification means “Did we build the thing right?” The whole process hinges on the Safety Requirement Specification (SRS), so failing to get that part of the process right in the beginning will negatively impact both hardware and software design. The SRS is the yardstick used to decide if you built the right thing. Without that, you are clueless about what you are building.
Coming in from the Safety Requirement Specification (also called the safety function specification), each step in the process is shown. The dashed lines illustrate the verification process at each step. Notice that the actual coding step is at the bottom of the V-model. Everything above the coding stage is either planning and design, or quality assurance activities.
There are other methods that can be used to result in verified and validated software, so if you have a QA process that produces solid results, you may not need to change it. I would recommend that you review all the stages in the V-model to ensure that your QA system has similar processes.
To make setting up safety systems simpler for designers and integrators, there are two approaches to software design that can be used.
Two Approaches to Software Design
There are two approaches to software design that should be considered:
- Preconfigured (building-block style) software
- Fully customised software
Preconfigured Building-Block Software
The preconfigured building-block approach is typically used for configuring safety PLCs or programmable safety relays or modules. This type of software is referred to as “safety-related embedded software (SRESW)” in .
Pre-written function blocks are provided by the device manufacturer. Each function block has a particular role: emergency stop, safety gate input, zero-speed detection, and so on. When configuring a safety PLC or safety modules that use this approach, the designer selects the appropriate block and then configures the inputs, outputs, and any other functional characteristics that are needed. The designer has no access to the safety-related code, so apart from configuration errors, no other errors can be introduced. The function blocks are verified and validated (V & V) by the controls component manufacturer, usually with the support of an accredited certification body. The function blocks will normally have a PL associated with them, and a statement like “suitable for PLe” will be made in the function block description.
This approach eliminates the need to do a detailed V & V of the code by the designing entity (i.e., the machine builder). However, the machine builder is still required to do a V & V on the operation of the system as they have configured it. The machine V & V includes all the usual fault injection tests and functional tests to ensure that the system will behave in as intended in the presence of a demand on the safety function or a fault condition. 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 building blocks achieves the first goal, fault avoidance, at least as far as the software coding is concerned. The configuration software will validate the function block configurations before compiling the software for upload to the safety controller so that most configuration errors will be caught at that stage.
This approach also facilitates the second goal, as long as the configuration software is usable and maintained by the software vendor. The configuration software usually includes the ability to annotate the configurations with relevant details to assist with the readability and understandability of the software.
Fully Customised Software
This approach is used where a fully customised hardware platform is being used, and the safety software is designed to run on that platform.  refers to this type of software as “Safety-related application software (SRASW).” A fully customised software application is used where a very specialised safety system is contemplated, and FPGAs or other customised hardware is being used. These systems are usually programmed using full-variability languages.
In this case, the full hardware and software V & V approach must be employed. In my opinion, ISO 13849 – 1 is probably not the best choice for this approach due to its simplification, and I would usually recommend using IEC 61508 – 3 as the basis for the design, verification, and validation of fully customised software.
Safety-Related Embedded Software (SRESW)
[1, 4.6.2] provides a laundry list of elements that must be incorporated into the V-model processes when developing SRESW, broken down by PLa through PLd, and then some additional requirements for PLc and PLd.
If you are designing SRESW for PLe, [1, 4.6.2] points you directly to IEC 61508 – 3, clause 7, which covers software suitable for SIL3 applications.
Safety-Related Application Software (SRASW)
[1, 4.6.3] provides a list of requirements that must be met through the v-model process for SRASW, and allows that PLa through PLe can be met by code written in LVL and that PLe applications can also be designed using FVL. In cases where software is developed using FVL, the software can be treated as the embedded software products (SRESW) are handled.
A similar architectural model to that used for single-channel hardware development is used, as shown in Fig. 2 [1, Fig 7].
The complete V-model must be applied to safety-related application software, with all of the additional requirements from [1, 4.6.3] included in the process model.
There is a lot to safety-related software development, certainly much more than could be discussed in a blog post like this or even in a standard like ISO 13849 – 1. If you are contemplating developing safety related software and you are not familiar with the techniques needed to develop this kind of high-reliability software, I would suggest you get help from a qualified developer. Keep in mind that there can be significant liability attached to safety system failures, including the deaths of people using your product. If you are developing SRASW, I would also recommend following IEC 61508 – 3 as the basis for the development and related QA processes.
- 3.1.36 application software
- software specific to the application, implemented by the machine manufacturer, and generally containing logic sequences, limits and expressions that control the appropriate inputs, outputs, calculations and decisions necessary to meet the SRP/CS requirements 3.1.37 embedded software firmware system software software that is part of the system supplied by the control manufacturer and which is not accessible for modification by the user of the machinery Note 1 to entry: Embedded software is usually written in FVL.
- Note 1 to entry: Embedded software is usually written in FVL.
- 3.1.34 limited variability language LVL
- type of language that provides the capability of combining predefined, application-specific library functions to implement the safety requirements specifications
- Note 1 to entry: Typical examples of LVL (ladder logic, function block diagram) are given in IEC 61131 – 3.
- Note 2 to entry: A typical example of a system using LVL: PLC. [SOURCE: IEC 61511 – 1:2003, 22.214.171.124.2, modified.]
- 3.1.35 full variability language FVL
- type of language that provides the capability of implementing a wide variety of functions and applications EXAMPLE C, C++, Assembler.
- Note 1 to entry: A typical example of systems using FVL: embedded systems.
- Note 2 to entry: In the field of machinery, FVL is found in embedded software and rarely in application software. [SOURCE: IEC 61511 – 1:2003, 126.96.36.199.3, modified.]
- 3.1.37 embedded software
- system software
- software that is part of the system supplied by the control manufacturer and which is not accessible for modification by the user of the machinery.
- Note 1 to entry: Embedded software is usually written in FVL.
- Field Programmable Gate Array FPGA
- A field-programmable gate array (FPGA) is an integrated circuit designed to be configured by a customer or a designer after manufacturing – hence “field-programmable”. The FPGA configuration is generally specified using a hardware description language (HDL), similar to that used for an application-specific integrated circuit (ASIC). 
Here are some books that I think you may find helpful on this journey:
[0.2] Electromagnetic Compatibility for Functional Safety, 1st ed. Stevenage, UK: The Institution of Engineering and Technology, 2008.
Note: This reference list starts in Part 1 of the series, so “missing” references may show in other parts of the series. Included in the last post of the series is the complete reference list.
 S. Jocelyn, J. Baudoin, Y. Chinniah, and P. Charpentier, “Feasibility study and uncertainties in the validation of an existing safety-related control circuit with the ISO 13849 – 1:2006 design standard,” Reliab. Eng. Syst. Saf., vol. 121, pp. 104 – 112, Jan. 2014.
 D. S. G. Nix, Y. Chinniah, F. Dosio, M. Fessler, F. Eng, and F. Schrever, “Linking Risk and Reliability — Mapping the output of risk assessment tools to functional safety requirements for safety related control systems,” 2015.
 Functional safety of electrical/electronic/programmable electronic safety-related systems – Part 2: Requirements for electrical/electronic/programmable electronic safety-related systems. IEC Standard 61508 – 2. 2010.
 “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/ifa/praxishilfen/practical-solutions-machine-safety/software-sistema/index.jsp. [Accessed: 30- Jan- 2017].
 “failure mode”, 192 – 03-17, International Electrotechnical Vocabulary. IEC International Electrotechnical Commission, Geneva, 2015.
 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.
 Out of Control — Why control systems go wrong and how to prevent failure, 2nd ed. Richmond, Surrey, UK: HSE Health and Safety Executive, 2003.
 “Field-programmable gate array”, En.wikipedia.org, 2017. [Online]. Available: https://en.wikipedia.org/wiki/Field-programmable_gate_array. [Accessed: 16-Jun-2017].