TC5 - Safety
SafeMotion as a system independent solution
The introduction of safety approved networks makes the control of drives and motion more and more a software item: hard-wired systems are replaced by software commands over networked systems. This is also pushed by initiatives like Industry 4.0 to create more flexibility preferably at the same quality and price levels. However, the different networks come with different solutions, which create problems at the users especially in production environments with heterogeneous networks. To harmonize this, PLCopen started a working group on SafeMotion, which created a generic proposal to solve the motion control safety aspects over the different networks like ProfiSafe, Safety over Ethercat, CIP Safety over Sercos, OpenSafety, CC-Link IE and Mechatrolink, as well as user area’s as described in OMAC.
The Changing Motion Control environment
The emergence of (fast) digital networks made it possible to link many motors to a controller. In many cases servo technology replaces the large single motor solution, making the functionalities locally available in the machine and also replacing the previously mechanical solutions by software control. This solution is also referred to as “mechatronic solutions”.
Usage of multiple motors changes the safety connections: from a hardwired safety solution to a solution over a safety network with a dedicated safety controller added to the functional controller (PLC).
Figure 2: From hardwired to networked safety functionalities
In order to support these trends, it is necessary to reflect the safety
functionality in the software environment. This paper identifies user
friendly solutions for this.
When we refer
to safe motion in this document, we mean the safety of the operating personnel
in machines with moving parts. This includes the motion of the different motors,
combined with their drives, in the machine in a safe way. In many cases this is
done via Safe Motion Monitoring Functionalities (SMMF) like defined in
The following motion related safety functionalities can be identified:
Mapping to the safe networks
In order to use the safety integrated networks the safety functions have to be mapped. This chapters provides an overview, however this can be incomplete and is not intended for implementations. For this purpose the applicable network standards have to be used. Also note that there is no preference or order applicable here: it just is a small overview.
What is generic in the current status of the safety integrated networks is that there are basically two bytes or words (double bytes) used for communicating the safety commands and status. However there are slight difference in the content and meaning of the words at bit level.
Overview Control Byte
Proposal for Safety Drives
SF_SafetyRequest for activating & monitoring drive function
Description of SF_SafeRequest provides a basic overview of the functionality.
The main inputs and outputs of SF_SafetyRequest shall be linked as follows:
If the input on the top left is FALSE, there is no activation so output top right is FALSE. However if there is a safety request and the input top left is TRUE, the top right output reflects the status of the drive or its exceeding of the monitoring time. The bottom right bit reflects the operation by setting the relevant bit in the control word for safety active, and after acknowledge of this in the safety drive, the bottom left input reflects this change (to TRUE).This SF_SafetyRequest functionality can be used in a broad safety sense, incl. the safe motion functionalities. For instance, in order to use this FB for SLT (Safely Limited Torque) one combines the inputs Axis2SLT_noNeed and Axis2SLT_fdbk to generate the relevant safety outputs Axis2SLT_active and Axis2SLT_ctrl, as depicted in REF _Ref416444894 \r \h REF _Ref463883215 \r \h Figure 7: REF _Ref463883220 \h Extended description of SF_SafetyRequest with reduced set of inputs and outputs, providing the required safety functionality. Multiple instances of SF_SafetyRequest may be used to cover all safety drive functions (IEC61800, profiles, vendor-specific).
In this way most of the safety drive functionalities can be mapped
easily, especially by providing a “guideline” with defined naming
conventions, containing a generic scheme how to name signals related to
the functions supported by a safety drive as described below. Combined
with an I/O or Drive configurator these names can be generated
automatically for the bits in the drive‘s status / control word,
matching the drive‘s profile (symbolic names).
Also for the supplier the certification process gets much simpler, while the user gets a consistent user interface that supports all needed functionalities, and even can group the same functionalities easily to provide a better overview of the safety application program.
The Safety Drive Naming Scheme
In order to have a consistent interface, the following naming scheme is proposed. For every safety drive d and every safety drive function f supported by the drive according to its profile and configuration, the corresponding FB instance and I/O signals shall be given the following names:
d is the name given to the safety drive in the application;
is the acronym for the safety drive function; for standard safety drive
functions the following common acronyms shall be used:
k is the number of the instance of the safety drive function (if the drive is configured to have multiple instances of the same drive instance.
Example: A CIP-safety-on-Sercos drive “MyAxis” has its Safe Motion Monitoring function #1 configured to be the safely limited speed function. Then the SF_SafetyRequest instance monitoring this function on MyAxis shall have the name “MyAxisSLS_Mon”, bit #2 of MyAxis’s status word in the input image shall have the symbolic name “MyAxisSLS_fdbk”, and bit #3 of MyAxis’s control word in the output image shall have the symbolic name “MyAxisSLS_ctrl”.If we map for example the Safe Torque Off functionality, it is the first bit in both the control and status byte. If we use Axis 2 for this example, the mapping of SF_SafetyRequest could look like:
The specification PLCopen Safe Motion is now published as version 0.99
Release for Comments and can be
downloaded here. The deadline for comments is December 5, 2016