Review of the CIP Safety SafeMotion Profile Functionality
Mark Chaffee
Senior Principal Engineer
Rockwell Automation
John Deinlein
Principal Engineer
Rockwell Automation
Presented at the ODVA2014 ODVA Industry Conference & 16th Annual Meeting
March 11-13, 2014
Phoenix, Arizona, USA
Abstract:
First released in 2005 to solve functional safety applications, CIP Safety has established itself as a key network
technology in achieving sustainability objectives of industry and is available for products implementing DeviceNet,
EtherNet/IP, and SERCOS III. The recently published (fall-2013) Safety Motion Profile further integrates networked
safety functionality into a broad range of drive products to greatly expand the scope of functional safety applications
addressed through CIP Safety. This paper presents a detailed review of the Safety Motion Profile and four new
objects introduced by the Safety Motion Objects SSE supporting motion safety functionality as defined in the IEC
61800-5-2 (Adjustable speed electrical power drive systems - Part 5-2: Safety Requirements - Functional) standard.
Keywords:
Safety Motion Profile, Safety Motion Objects
Introduction:
In the past, many applications deployed safety devices in a standalone, hardwired mode where safety was managed
locally at the device and safety network support was not required. For example, safe drives were equipped withdedicated local safety I/O and supported a limited range of safety functions like safe torque off and safe stopping.
Drive safety configuration was managed locally using web browsers or dedicated software tools.
Today, the current trend is to implement fully programmable, flexible safety solutions using safety controllers(PLCs) with networked safety devices that are fully integrated into the machine process. This safety controller basedarchitecture has distinct advantages over traditional standalone hardwired safety when:
1.
2.
3.
4.
5.
6.
7.

Complex safety logic is required
Multiple safety zones have to be managed
Distributed safety I/O is required
A large area/footprint is to be safe-guarded
Machine modularity and scalability is important
Diagnostic safety information is required
Advanced drive safety control is required

2014 ODVA Industry Conference

1©2014 ODVA, Inc.

Networked safety drives are a critical safety component in the safety controller based architecture. Networked safety
drives can offer basic and advanced safety functions with safety configuration, safety function activation, and safety
status monitoring support via a network safety connection. Modern safety network technology allows safety devices
like safety discrete I/O, safety analog I/O, drives with safety core, and other safety devices with safety support tocoexist with standard control devices on a common network.

Safety Controller Based Architecture

While there are published open CIP Safety profiles for “Safety Discrete I/O” and “Safety Analog I/O” available
today, no open profiles were available for networked “Safety Drives”. This was identified as a critical need at the2012 ODVA Networking Conference. At that time, a Safe Motion Sub-committee was formed to construct SSEs fora new Safety Drive profile and supporting Safe Motion objects targeted for the Fall 2013 ODVA publication of theVolume 5 CIP Safety standard, Edition 2.8.
This paper reports on the fruit of the Safe Motion Sub-committee’s work that includes a new Safety Motion Device
Profile supporting Device Types for both CIP Motion Safety Drives as well as Safety Drives using the SERCOS III
interface, and also includes four new Safe Motion objects.
Drive Safety Functions:
One of the key requirements for the Safety Motion Device Profile was to support a large subset of the drive safetyfunctions defined by the EN61800-5-2 “Adjustable speed electrical power drive systems – Part 5.2 Safety
Requirements - Functional” standard. This standard defines a broad range of drive safety functions as listed below.

2014 ODVA Industry Conference2©2014 ODVA, Inc.

EN61800-5-2 Drive Safety Functions
These 17 safety functions can be categorized into following general groups:• Disable power flow to the motor (i.e. STO)
• Safe brake control (i.e. SBC)
• Safe stop (i.e. SS1)
• Safe speed monitoring (i.e. SLS)
• Safe acceleration monitoring (i.e. SLA)
• Safe torque monitoring (i.e. SLT)• Safe position monitoring (i.e. SLP)
An overview of “typical” functionality associated with a few of the more common drive safety functions is provided
below.

2014 ODVA Industry Conference

3©2014 ODVA, Inc.

Safe Torque-off (STO)
STO is used to disable the torque generating power feed to the motor. A typical implementation includes a safe
torque off request input and stop delay parameter. On occurrence of a STO safe torque off request a STO will be
initiated after the specified Stop Delay. The figure below shows a typical timing diagram for an STO sequence.

Safe Torque Off (STO) Timing Diagram
Safe Stop 1 (SS1)
SS1 is used to decelerate the motor followed by an STO. A typical implementation includes the SS1 stop request
input, stop monitoring delay parameter, stop delay parameter, deceleration tolerance parameter, and standstill speed
parameter. On occurrence of a SS1 safe stop request the deceleration ramp will be monitored after the stopmonitoring delay expires. An STO will be initiated as soon as the motor speed is below the Standstill speed or thestop delay time expires. The figure below shows a timing diagram for a typical SS1 sequence.

Safe Stop 1 (SS1) Timing Diagram
Safe Stop 2 (SS2)
SS2 is used to decelerate the motor followed by safe operational stop (SOS) monitoring. A typical implementation
includes the SS2 stop request input, stop monitoring delay parameter, stop delay parameter, deceleration tolerance
parameter, and standstill speed parameter. On occurrence of a SS2 safe stop request the deceleration ramp will bemonitored after the stop monitoring delay expires. After the motor speed is below the Standstill speed then theposition & velocity of the motor will be monitored to insure no movement (Safe Operational Stop - SOS). Unlike
SS1 the motor torque producing power remains enabled unless a safety fault occurs. The figure below shows atiming diagram for a typical SS2 sequence.

Safe Stop 2 (SS2) Timing Diagram

2014 ODVA Industry Conference

4©2014 ODVA, Inc.

Safe Limited Speed (SLS)SLS is used to insure the speed of the motor does not exceed a minimum value. A typical implementation includes
the SLS monitoring request input, SLS monitoring delay parameter, and safe speed limit parameter. On occurrenceof a SLS monitoring request the motor speed will be monitored after the SLS monitoring delay expires to insure it
does not exceed the safe speed limit value. If the limit is exceeded a SLS fault will occur and an STO is initiated.
The figure below shows a timing diagram for a typical SLS.

Safe Limited Speed (SLS) Timing Diagram
Drives may support a subset of the 61800-5-2 safety functions with STO being a minimum requirement. The drive
includes a Safety Core to manage the safety function operation. The Safety Core is typically designed to meet ENISO 13849-1 PLe and EN61508 SIL 3 levels. An example of a typical drive Safety Core is shown in the figure
below.

Motor
Feedback

Midrange Drive Enclosure

Connector

Control Board

.

KMCL
FPGA
ENET
Port 1Connector

PHY#1

ENET
Port 2Connector

PHY#2

MII
Three
Port
SwitchEncoderInterface

MII

Local Display
Interface

EMIF_A

SharedRAM

ControlCore

Voltage
Regulators

SUP

Power – Control Interface

Dual Core SOC

Power Board
Power Board Interface
Connector

Comms
Core

RMII
DDR2
Memory

NAND
Flash

PWMS
Power
Processor

ANALOG
CURRENT/VOLTAGE

Safety Core
Micro
Controller
CH0

Micro
Controller
CH1
Safety Enable

Typical Drive Safety Core

2014 ODVA Industry Conference

5©2014 ODVA, Inc.

The typical drive Safety Core includes safety network interface, primary and secondary position/velocity feedback,dual redundant processors with gate drive interface to disable torque producing current to the motor, and firmware to
support a range of drive safety functions. Single motor mounted feedback is typically used for SIL 2, PLd while anadditional secondary feedback is required for SIL 3, PLe (typically driven on the load side). The functionality
provided by the drive safety core differs based on the supported drive safety functions, and the safety interface to thedrive.
Drive Safety Architecture Deployment Options:
In the 2012 ODVA Conference paper “CIP Safety for Drives”, four different Drive Safety Architecture Deployment
options were defined. Key factors in differentiating these options are whether the controller or drive, 1) owns thesafety I/O, 2) activates the drive safety functions, 3) configures the drive safety functions, and 4) generates the
motion profile.
Option 1 – Local drive safety I/O activated drive safety functions
Option 2 - Safety controller activated drive safety functions
Option 3 - Safety controller configured and activated drive safety functions
Option 4 - Safety controller executed drive safety functions using drive STO

Safety Architecture Deployment Options
A description of each deployment option is provided below. To illustrate the differences between the four options a“Safe Stop (SS1) with guard gate lock control” safety operation is shown for each option.
Option 1 - Local drive safety I/O activated drive safety functions
With this option the drive safety functions are activated and safety status is monitored using local drive safety I/O.
All safety functions are managed locally within the safety core of the drive. Drive safety function configuration is
managed locally at the drive using a web browser, software utility, or similar. This option does not require a drive
network safety connection.

Option 1 Architecture2014 ODVA Industry Conference

6©2014 ODVA, Inc.

Option 2 - Safety controller activated drive safety functions
With this option the drive safety functions are activated and safety status is monitored by the safety controller using
the drive network safety connection. All safety functions are managed locally within the safety core of the drive.
Drive safety function configuration is managed locally at the drive using a web browser, software utility, or similar.

Option 2 Architecture
Option 3 - Safety controller configured and activated drive safety functions
With this option the drive safety functions are initiated and status is monitored using the drive network safety
connection. All safety functions are managed locally within the safety core of the drive. Drive safety function
configuration is managed at the Safety controller and sent to the drive safety core as runtime parameters along withthe safety function activation request.

Option 3 Architecture2014 ODVA Industry Conference

7©2014 ODVA, Inc.

Option 4 - Safety controller executed drive safety functions using drive STOWith this option only the STO safety function is directly managed in the drive. The drive safety functions are
directly executed in the safety controller using safety instructions (i.e. SS1 instruction) and safety status data fromthe drive safety core via the drive network safety connection. Safety status data includes STO status, safety feedback
data – position, velocity, acceleration. With this approach the safety feedback data for the drive safety core is used in
the Safety Controller safety task to perform the safe speed, safe position monitoring functions.

Option 4 Architecture
The Safe Motion Sub-committee agreed to focus their efforts on providing support for Option 2 and 4. This is thefunctionality that was delivered in the Safety Motion Profile SSE and the companion Safety Motion Objects SSE.
Safety Motion Device Profile:Construction of the Safety Motion Device Profile began with the recognition that there were two distinct types ofdrives we were targeting, CIP Motion Drives and a non-CIP (SERCOS III) Drives. While these drives would share acommon Safety Core interface, the behavior of the drives is quite different. Two separate Device Types were needed
to differentiate these drives, so the Safety Motion Device Profile defined the following:

CIP Motion Safety Drive Device Type: 2Dhex
Safety Drive Device Type: 2Ehex
A CIP Motion Safety Drive device provides all the functionality associated with a CIP Motion Drive device as
described in the CIP Motion Device Profile (see Volume 1, Section 6-41) while also providing a CIP Safety network
connection to a safety controller to exchange safety input and output data associated with the safety functionality of
the CIP Motion Safety Drive.
A Safety Drive device does not support CIP Motion but does provide a CIP Safety network connection to a safetycontroller to exchange safety input and output data associated with the safety functionality of the Safety Drive. This
profile is applicable to non-CIP Motion drives such as those using the SERCOS III interface.

2014 ODVA Industry Conference

8©2014 ODVA, Inc.

The more challenging of the two device types to define was the CIP Motion Safety Drive due to the fact that a CIP
Motion drive already has a rich set of attributes and state behavior that must be merged with the specified behaviorof a CIP Safety device. There was no precedent for this kind of safety device nor was this kind of a device
anticipated when the CIP Safety specification was constructed. (All CIP Safety devices defined thus far in Volume 5
are relatively simple Safety I/O devices.) We have begun to refer to this kind of device, where both a standard CIP
function and CIP safety function must coexist on the network as a single device profile with a single identity state,
as a Hybrid Safety device.
Object Model:
Another distinct characteristic of the CIP Motion Safety Drive is that it supports both standard and safety CIP
connections, specifically a bidirectional CIP Motion connection and the bidirectional CIP Safety connection. The
Object Model for the CIP Motion Safety Drive diagram below shows these two connections and how the objects
from the CIP Motion Drive device profile have been merged with CIP Safety objects.
Same Message Router asshown below

Message
RouterSafetySafetySafety
Limit
+
IOIO
Functions

SafetySafetySafety
Stop
+
IOIO
Functions

Identity
ObjectSafetySafetyDual
SafetyChannel
IOIO
Feedback

SafetyMotionSafety
DeviceIOIO
Axis Object*

Safety Output
Assembly

Safety Input
Assembly

SafetySafetySafetyIOIOFeedback

SafetySupervisor
Time Sync
Object*Message
RouterLink SpecificObjectSafetySafetySafetyIOIO
Validators
QoS
Object*SafetySafetyMotionIO
I/OIO

SafetySafetyExplicit
IOIO
Message

SafetySafetySafetyIO
I/OIO
Connection Manager orConnection Object

optional* Applicable to CIP Motion
Safety Devices

required

CIP Network

Object Model for CIP Motion Safety Drive device
Safety Drive device types would follow the same Object Model but without the CIP Motion connection and all CIP
Motion related objects, marked with an “*” in diagram. Instead of the CIP Motion connection, these drives would
have a non-CIP SERCOS III network connection to operate the drive.
Note that there is an Identity Object and a Safety Supervisor Object represented in the Object Model. Both arerequired. The Identity Object is critical to the standard side operation of the device, while the Safety Supervisor
Object is critical to the safety operation of the device.

2014 ODVA Industry Conference

9©2014 ODVA, Inc.

Device State Mapping:
A CIP Motion compliant drive is governed by the following Motion Device Axis State Model.
Enabled Operation
Transient State

Testing
Terminal State

Starting

Shutdown

Drive Enable
or TestRunning

Drive Disable

Disabled Operation

StandbyMajor Fault

FaultedFault Reset

Stopping

Aborting
Major Fault

Inhibits Present

Start
Inhibited

Fault Reset

StoppedShutdown

Shutdown
Reset

Initialization
Fault

Bus Up!Bus Up
Standby

Pre-ChargeStandbyMajor Fault

Major Fault

Inhibits Cleared
Shutdown

Fault Reset

Major
FaultedInitialization
Complete

Off

Initializing

Self Test

Motion Device Axis Object State Model
The Motion Device Axis Object specification in Volume 1 of the CIP standard defines a relationship between the
Motion Axis Object states of a CIP Motion Drive and the Identity Object states. As with all standard CIP devices,the Identity Object state dictates the Module Status LED behavior for the device.
Axis State
Off
Self-Test
Initialization – Bus not Up
Initialization – Bus Up
Shutdown – Bus not Up
Shutdown – Bus Up
Pre-Charge - Bus not Up
Start Inhibit
StoppedStopping
Starting
Running
Testing
Aborting
Major Faulted
Aborting
Major Faulted

ID Object State
Nonexistent – Power Off
Device Self-Testing

Module Status LED
Off
Flash Red/Green

StandbyFlashing Green

Operational

Solid Green

Major Recoverable Fault

Flashing Red

Major Unrecoverable Fault

Solid Red

Axis State to Identity Object Mapping
2014 ODVA Industry Conference

10©2014 ODVA, Inc.

A CIP Safety compliant Safety I/O device, on the other hand, is governed by the following Safety Supervisor State
Model.

Safety Supervisor State Model
The Safety Supervisor Object specification in Volume 5 of the CIP standard defines the relationship between the
Safety Supervisor states of a CIP Safety I/O device and the Identity Object states. The specification also states that
the Safety Supervisor state determines the behavior of the Module Status LED, superseding the traditional role ofthe Identity Object.

Safety Supervisor State to Identity Object Mapping
It should now be apparent that integrating a CIP Safety compliant Safety Core into a CIP Motion Drive creates asignificant system design issue in that we have only one Identity Object and one Module Status LED to reflect thecondition of the drive, Axis and Safety. With Axis states and Safety states that are almost completely independent ofeach other, it is no longer possible to satisfy both CIP Motion and CIP Safety specifications with respect to the
Identity Object. Note that there is a Module Status LED conflict as well. Identity Object “Standby” states are always
Flashing Green, while some of the "Standby" states of Safety Supervisor, like "Configuring" and "Waiting for
TUNID" are Flashing Red/Green.

2014 ODVA Industry Conference

11©2014 ODVA, Inc.

The key to resolving these design issues was establishing state precedence rules to dictate the overall state of thesafety drive. This is similar to how the Module Status LED behavior was established for a Multi-axis CIP Motion
drive. The object whose state has the highest precedence dictates the overall state of the device. The stateprecedence rules, starting with the highest precedence, are as follows:
1.
2.
3.
4.
5.
6.
7.
8.
9.

Self-Test
Unrecoverable Fault
Recoverable Fault
Safety Configuring
Safety Idle
Axis Standby
Axis Operational
Safety Executing
Safety Waiting for TUNID (Out of Box)

Based on this hierarchy, the object that governs the Identity Object state is shown in the Governing State column inthe table below.
Safety State

Axis State

Governing State

Identity State

Self-Testing
Any State*
Self-Test Exception
Waiting for TUNID
Configuring
Idle

Safety Supervisor
Motion Axis
Safety Supervisor
Safety Supervisor
Safety Supervisor
Motion Axis
Motion Axis

Device Self-Testing
Device Self-Testing
Major Unrecoverable
StandbyStandbyStandbyStandby

Motion Axis

Operational

Solid GreenAny State*

Any State
Self-Test
Any State*
Any State*
Any State*
Any State*
Initializing
Pre-Charge
Shutdown
Start Inhibit
StoppedStopping
Starting
Running
Testing
Aborting

Module Status
LED
Flashing Red/Green
Flashing Red/Green
Solid Red
Flashing Red/Green
Flashing Red/Green
Flashing Green
Flashing Green

Motion Axis

Any State*

Major Faulted

Motion Axis

Abort
Critical Fault

Any State*
Any State*

Safety Supervisor
Safety Supervisor

Major Recoverable or
Major Unrecoverable
Major Recoverable or
Major Unrecoverable
Major Recoverable
Major Unrecoverable

Flashing Red or
Solid Red
Flashing Red or
Solid Red
Flashing Red
Solid Red

Waiting for TUNID
with TorquePermitted,
Executing,Executing with
Torque Permitted* "Any State" = any state that with lower precedence.
The Governing Object in the above table not only determines the Identity Object state, but also determines the
Module Status LED behavior. If the Safety Supervisor is the governing object, then the Module Status LED follows
the rules specified by the Safety Supervisor Object specification. If the Motion Device Axis is the governing object,then the Module Status LED follows the rules of the Identity Object specification.
New Safety States for Commissioning and Maintenance:
CIP Motion Safety Drives, unlike Safety I/O devices, must be allowed to operate with the safety function disabled.
This allows the user to perform commissioning and major maintenance operations on drives associated with various
motion components of the machine without interference from the safety function. The ability to operate the drive

2014 ODVA Industry Conference

12©2014 ODVA, Inc.

with the safety function disabled is particularly important during initial commissioning of the drive, and is also
desirable when performing a machine maintenance activity.
Since the Safety Core embedded in the drive functions much like a CIP Safety I/O device, the drive’s safety function
is only operational after a CIP Safety connection has been made to the drive and the Safety Core has been
configured. For Safety I/O devices the CIP Safety connection is the only connection to the device so the device
simply cannot operate until the Safety connection is opened and the device is configured. But Hybrid Safety devices,like the CIP Motion Safety Drive, support multiple connections, Safety and Standard, so device operation via theStandard connection prior to establishing a Safety connection is possible, and desirable for easy commissioning.
To manage the dual safety/standard connection aspect of a CIP Motion Safety Drive, the controller’s device profile
should be designed to select among three different connection configurations, ‘Safety’, ‘Motion’, and ‘Motion and
Safety’. This functionality allows the user to handle the cases where this device profile is applied by separate Safety
and Standard controllers.
To commission a CIP Motion Safety Drive, the user configures the controller’s device profile for a ‘Motion’
Connection. When downloaded, the drive would operate as a standard CIP Motion drive without any connection
being made to the drive’s Safety Core. Since the drive’s Safety Core is still in its “Out of Box” state and not owned
by a Safety Controller, the drive is totally controlled by the standard CIP Motion connection. When commissioning
is complete, the user simply re-configures the drive with the controller’s device profile set for ‘Motion and Safety’
Connection. This transforms the commissioned CIP Motion Drive into a CIP Motion Safety Drive with a fully
operational Safety Core where standard drive functions are controlled by the CIP Motion connection and safetyfunctions are controlled via the CIP Safety connection.
To make this operational Out of Box state clear from a Safety Supervisor state perspective, an additional device
profile specific state was added for CIP Motion Safety Drives, “Waiting for TUNID with Torque Permitted”. The
existing safety state, “Waiting for TUNID”, shall continue to apply to traditional Out of Box behavior where thesafety device is forced to safe state.

New Safety Supervisor States for CIP Motion Safety Drives
2014 ODVA Industry Conference

13©2014 ODVA, Inc.

With an operational Safety Core, safety demands can occur at any time due to safety instruction execution in thesafety controller. These safety demands could potentially disable the drive during a maintenance session. For thisreason, it is desirable to perform maintenance operations with the safety controller in Program Mode (not Run
Mode) were safety program execution is disabled. However, current Safety I/O device behavior forces the device tosafe state when the safety controller is in Program Mode as indicated by the Safety Output connection’s Run/Idle bit
being Idle. In this condition the Safety I/O device is inoperable. A mechanism was therefore needed to allow the CIP
Motion Safety Drives to operate when the safety controller is in Program Mode.
Again, referencing the above Safety Supervisor State diagram, a new state was defined, “Executing with TorquePermitted”, to allow drive operation in Program Mode. To enter this state, an “STO Bypass” is initiated via an
unconnected STO Mode Change service request to the CIP Motion Safety Drive. If the safety controller is in
Program Mode (Safety Output Connection Run/Idle bit is Idle) the STO Mode Change bypasses the drive’s STO
safety function to permit drive operation in the “Executing with Torque Permitted” state. This allows the drive tooperate during the maintenance procedure using the CIP Motion connection as long as the following conditions hold
true:
1.
2.
3.

Drive Safety core is operational without faults / errors.
CIP Safety connection is Open without faults / errors.
CIP Safety Output connection Run/Idle bit remains in Idle.

Normal machine operation is restored by transitioning the safety controller from Program Mode to Run Mode. This
sets the Run/Idle bit to Run, automatically transitioning the Safety Supervisor State from “Executing with TorquePermitted” to “Executing”, restoring STO safety function operation.
Safety Motion Device Assemblies:
The Safety Motion Device Profile defines a set of Safety Input and Safety Output Assemblies to support a wide
range of drive safety functions ranging from simple Safe Torque Off only implementation to full feature Safety Stopand Safety Limit Monitoring implementations. These assemblies are defined with or without Safety Feedback dataand support for one or two Axis instances.
Here is a summary of the Safety Output Assemblies defined in the Safety Motion Device Profile showing the
progression of drive safety function support starting with a simple STO only assembly.
Table 6-8.10 Safety Output Data with STO (1 Axis Instance)
Instance

Byte

Bit7

Bit6

Bit5

Bit4

Bit3

Bit2

Bit1

Bit0

180hex0

Reset
RequestReserved

Reserved

Reserved

Reserved

Reserved

Reserved

STO
OutputTable 6-8.11 Safety Output Data with STO and Safe Brake Control (1 Axis Instance)
Instance

Byte

Bit7

Bit6

Bit5

Bit4

Bit3

Bit2

Bit1

Bit0

181hex0

Reset
RequestReserved

Reserved

Reserved

Reserved

Reserved

SBC
OutputSTO
OutputTable 6-8.12 Safety Output Data with Safe Stop Functions (1 Axis Instance)
Instance

Byte

Bit7

Bit6

Bit5

Bit4

Bit3

Bit2

Bit1

Bit0

182hex0

Reset
RequestReserved

SMT
RequestSOS
Request

SS2
Request

SS1
RequestSBC
OutputSTO
OutputTable 6-8.13 Safety Output Data with Safe Stop/Limit Functions (1 Axis Instance)
Instance

Byte

Bit7

Bit6

Bit5

Bit4

Bit3

Bit2

Bit1

Bit0

183hex0

Reset

Reserved

SMT

SOS

SS2

SS1

SBC

STO

2014 ODVA Industry Conference

14©2014 ODVA, Inc.

Request
1

Reserved

Reserved

RequestRequestRequestRequest

OutputOutputSDI–
RequestSDI+
RequestReserved

SLA
RequestSLS
RequestSSM
RequestTable 6-8.14 Safety Output Data with Safe Stop and Safe Limit Groups (1 Axis Instance)
Instance

Byte

Bit7

Bit6

Bit5

Bit4

Bit3

Bit2

Bit1

Bit0

184hex0

Reset
RequestReserved

SMT
RequestSOS
Request

SS2
Request

SS1
RequestSBC
OutputSTO
Output1

Reserved

Reserved

Reserved

Reserved

Group SelectSafety Input assemblies follow the same bit pattern as the Safety Output assemblies, with safety function request bitsin the Safety Output assemblies aligning generally with safety function status bits in the Safety Input assemblies.
Table 6-8.20 Safety Input Data with STO (1 Axis Instance)
Instance

Byte

Bit7

Bit6

Bit5

Bit4

Bit3

Bit2

Bit1

Bit0

1A0hex0

Reset
Required

SafetyFault

Reserved

Reserved

Reserved

Reserved

Reserved

TorqueDisabled

Table 6-8.21 Safety Input Data with STO and Safe Brake Control (1 Axis Instance)
Instance

Byte

Bit7

Bit6

Bit5

Bit4

Bit3

Bit2

Bit1

Bit0

1A1hex0

Reset
Required

SafetyFault

Reserved

Reserved

Reserved

Reserved

Brake
EngagedTorqueDisabled

Table 6-8.22 Safety Input Data with Safe Stop Functions (1 Axis Instance)
Instance

Byte

Bit7

Bit6

Bit5

Bit4

Bit3

Bit2

Bit1

Bit0

1A2hex0

Reset
Required

SafetyFault

Safe Motor
Temp

Safe
Standstill

SS2
ActiveSS1
ActiveBrakeEngagedTorqueDisabled

Table 6-8.23 Safety Input Data with Safe Stop/Limit Functions (1 Axis Instance)
Instance

Byte

Bit7

Bit6

Bit5

Bit4

Bit3

Bit2

Bit1

Bit0

1A3hex0

Reset
Required

SafetyFault

Safe Motor
Temp

Safe
Standstill

SS2
ActiveSS1
ActiveBrakeEngagedTorqueDisabled

1

Reserved

Reserved

MotionNegative

MotionPositive

SDI
ActiveSLA
ActiveSLS
ActiveSafe
Speed

Table 6-8.24 Safety Input Data with Safe Stop and Safe Limit Groups (1 Axis Instance)
Instance

Byte

Bit7

Bit6

Bit5

Bit4

Bit3

Bit2

Bit1

Bit0

1A4hex0

Reset
Required

SafetyFault

Safe Motor
Temp

Safe
Standstill

SS2
ActiveSS1
ActiveBrakeEngagedTorqueDisabled

1

Reserved

Reserved

Reserved

Reserved

Group Active

When safety function monitoring is performed by the safety controller rather than the drive, the drive must passsafety feedback data back to the safety controller via the Safety Input connection. To support this architecture(Deployment Option 4), the above Safety Input assemblies are augmented with Safety Feedback Data. Below is an
example of the STO Only assembly with Safety Feedback data.

2014 ODVA Industry Conference

15©2014 ODVA, Inc.

Table 6-8.30 Safety Input Data with STO and Feedback Data (1 Axis Instance)
Instance

Byte

1C0hex

0
1
2
3
4
5
6
7
8
9
10
11
12

Bit7

Bit6

Bit5

Bit4

Bit3

Bit2

Bit1

Bit0

Reserved

Reserved

TorqueDisabled

Feedback Position (DINT)

Feedback Velocity (DINT)

Feedback Acceleration (DINT)

Reset
Required

SafetyFault

Reserved

Reserved

Reserved

For each of the above single axis instance assemblies, the Safety Motion Device Profile also defines assemblies that
support data for 2-axis instances. Below is an example of a 2-axis instance Safety Input assembly that includes
Feedback Data.
Table 6-8.38 Safety Input Data with Safe Stop/Limit Functions and Feedback Data (2 Axis
Instances)
Instance

Byte

1CBhex

0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

Bit7

Bit6

Bit5

Bit4

Bit3

Bit2

Bit1

Bit0

Feedback Position 1 (DINT)

Feedback Velocity 1 (DINT)

Feedback Acceleration 1 (DINT)

Feedback Position 2 (DINT)

Feedback Velocity 2 (DINT)

Feedback Acceleration 2 (DINT)

Reset
Required 1

SafetyFault 1

Safe Motor
Temp 1

Safe
Standstill 1

SS2
Active 1

SS1
Active 1

Brake
Engaged 1

TorqueDisabled 1

25

Reserved

Reserved

MotionNegative 1

MotionPositive 1

SDI
Active 1

SLA
Active 1

SLS
Active 1

Safe
Speed 126

Reset
Required 2

SafetyFault 2

Safe Motor
Temp 2

Safe
Standstill 2

SS2
Active 2

SS1
Active 2

Brake
Engaged 2

TorqueDisabled 2

27

Reserved

Reserved

MotionNegative 2

MotionPositive 2

SDI
Active 2

SLA
Active 2

SLS
Active 2

Safe
Speed 2

2014 ODVA Industry Conference

16©2014 ODVA, Inc.

Safe Motion Object Overview:
The Safety Stop Functions Object encapsulates drive safety functions focused on stopping the motor. Safetyfunctions in this object include Safe Torque Off, Safe Brake Control, Safe Stop 1, and Safe Stop 2. One instance of
the Safety Stop Functions Object is required for each Motion Device Axis Object instance supplying power to a
motor.
The Safety Limit Functions Object encapsulates drive safety functions related to monitoring the dynamics of the
motor against configured safe limits. Safety functions in this object include Safe Limited Speed, Safe Limited
Acceleration, Safe Limited Torque, Safe Direction, and Safe Speed Monitor. At least one instance of the Safe Limit
Functions is required per Motion Device Axis Object instance supplying power to a motor. More instances can be
implemented if the drive supports multiple limits per safety function.
The Safety Feedback Object encapsulates Safe Position, Safe Velocity, and Safe Acceleration data associated with asafety feedback device such as safety capable encoder. One instance of the Safety Feedback Object is required per
safety feedback device.
The Safety Dual Channel Feedback Object encapsulates the feedback discrepancy checking function used to achieve
SIL 3, PLe safety certification level using two feedback devices. One instance of the Safety Dual Channel Feedback
Object is required per pair of safety feedback device.
The Safety Stop Functions Object and Safety Limit Functions Object are intended to be used in systems where the“Safe State” in the case of a fault is the Safe Torque Off function in Torque Disabled state and, if implemented, theSafe Brake Control in Brake Engaged state.
Safety Feedback Objects
To promote consistency in definition of safety objects; the “design pattern” for the Safety Feedback Object (Class
Code: 58hex) was the Safety Analog Input Point Object (49hex)
Configuration attributes for feedback devices are based on the Feedback Configuration Attributes defined for the
Motion Device Axis Object (42hex).
The design pattern for the Safety Dual Channel Feedback Object (Class Code: 59hex) is the Safety Dual Channel
Analog Input Object (4Bhex).
Important Note: Speed Feedback Object definition requires that diagnostic tests appropriate to the defined Safety
Integrity Level and the configured Feedback Type must be performed. Details of the diagnostic tests to meet therequirements are Vendor Specific.
Reset and Restart
Fault Reset behavior is significantly different for the Safe Motion Objects when compared to previously definedsafety objects.
For objects such as Safety Discrete Point, Output Point, and Analog Input Point; the object is reset from its “fault
state” when the cause of the fault is corrected and a configurable “Latch Error Time” has expired.
The possible fault cases for the Safety Motion Object are complex and in many cases it is not possible to define
when a fault has “cleared”. For instance, over-speed of Safety feedback is a fault because aliasing of the feedback
signals means a high speed may be indistinguishable from low speed. Therefore a fault reset always requires
correcting the cause of that fault followed by a 0 to 1 transition of the Function Reset attribute.
The Function Reset attribute may also be configured as a manual Restart. Note the terminology; a “Reset” enables
the transition out of a “Fault” state while a “Restart” enables transition out of a “Stopped” state. Restart behavior isconfigurable. For example: If Restart Type = Manual (default), the transition of STO Status from Disable Torque2014 ODVA Industry Conference

17©2014 ODVA, Inc.

to Permit Torque requires STO Output set to Permit Torque AND a 0 to 1 transition of Function Reset. If RestartType = Automatic, STO Status is simply the inverse of STO Output.
Safe Motion Object Example:
In the figure below a Safety Feedback Object instance processes encoder input to determine motor velocity. A
second Safety Feedback object instance and a Safety Dual Channel Feedback Object instance enable discrepancy
testing to achieve a high SIL rating.
Safety Stop Functions

Safety Limit Functions
Safety Limit Active

Safely-Limited Speed

Safe Stop 1

SS1 Complete

Output Assembly
Reset RequestSLS Request
SS1 Request
STO Output
SBC Output
Enc.
Enc.

Feedback Velocity

SafetyFeedback
SafetyFeedback

STO

Safe Torque Off

STO Status

Safe Brake Control

Brake

Input Assembly

Safety Dual
ChannelFeedback

SLS Active
SS1 Active
Torque Disabled
Brake Engaged
Safety Fault

Drive
Stop
Drive
EnableSafety Function Object Interaction
A Safely-Limited Speed function in the Safety Limit Functions Object instance is enabled by SLS Request in an
Assembly Object instance from a Safety Controller. If the measured motor speed exceeds the configured speed limit
this example is configured to initiate Safe Stop 1.
The drive control monitors SS1 Active and sets its internal state to stop. The SS1 function monitors deceleration tostop then sets SS1 Complete. SS1 Complete commands the Safe Torque Off function to set the drive’s STO circuits
to Torque Disabled. The drive control monitors Torque Disabled and sets its internal state to disabled.
NOTE: SS1 could also be initiated at any time by SS1 Request in the Output Assembly.
The above example system includes a Safe Brake Control function configured to engage a motor brake when STO is
active. A slight time delay for the brake to engage before torque is disabled is configured. The safety control
functions are reset by 0→1 edge on Reset Request.
The timing diagram below illustrates the configurable delay from Engage Brake to Torque Disabled. The signed
configurable delay also supports the case where there is a delay between Disable Torque to Brake Engaged.

2014 ODVA Industry Conference

18©2014 ODVA, Inc.

Monitor Speed
SLS Request

RequestSLS Active

ActiveMonitor Stop

Engage Brake & Disable Torque

ResartSLS Limit Active
SS1 Activation
SS1 Active

0x00

0x01

0x00

ActiveSS1 Complete
STO Activation
STO Status
Torque Disabled

0x00

0x02

0x00

Permit Torque Disable Torque
Torque Permitted Torque Disabled

SBC Activation

0x00

0x02

SBC Status

Release Brake Engage Brake

Brake Engaged

Brake Released Brake Engaged

0x00

Function Reset

Safe Limited Speed Timing Diagram
Safety Limit Functions Setpoints
For the Safety Limit Functions typically have a “setpoint” that establishes the “limit”. For example: For Safely
Limited Speed, the limit value is set by SLS Active Limit or by SLS Default Limit.
In cases where the limit value may be a configuration parameter: The value is stored in SLS Default Limit (Set andNV) and copied to SLS Active Limit (Set and V) for the actual speed comparison.
It is also possible to define an Output Assembly to drive SLS Active Limit. If that Assembly is selected, the Safetycontroller can dynamically change the limit setpoint.
It is also possible to implement an instance of Safety Limit Functions instance and then the limit function “Mode”
attributes to always enable selected functions. This is intended for the case where exceeding some maximum
setpoint should always be checked.
For example: Many safety controllers provide a Safely-Limited Speed that is activated only when a input is active
and a “maximum” Safely-Limited Speed that should always be in effect.
Safety Limit Functions Group SelectUnderstanding selection of Safety Limit Functions using Group Select needs some explanation of the background.
It is anticipated that for certain applications of safety to machines, there would be cases where the machine has
certain “machine states” or “modes of operation.” Each state or mode might need activation of a different selectionof Limit Functions and/or different limit setpoints for each.

2014 ODVA Industry Conference

19©2014 ODVA, Inc.

Group Active
Group Select01

4 to 16
Decoder

Function Select(22)

Instance 1

Select SLA
Select SLS
Select SDI Pos
Select SDI Neg
Select SSM

SLA RequestSLS Request
SDI Positive Request
SDI Negitive Request
SSM Request

2-15

Instances 2-15

Instance Byte Bit7

Bit6

Bit5

Bit4

Bit3

184hexReserved

SMT
RequestReserved

SOS
RequestReserved

SS2
SS1
RequestRequestGroup Select

0
1

Reset
RequestReserved

Reserved

Bit2

Bit1

Bit0

SBC
OutputSTO
OutputGroup Safety Limit Function Selection
To use Group Select, an Output Assembly that includes Group Select is selected. Each value 1 through 15, selects a
Safety Limit Functions instance and then the Function Select attribute in that instance selects which safety functions
are active. (For Group Select = 0, all functions are disabled.)
Since each of the Safety Limit Functions instances has its own setpoint configuration attributes (Set and NV), thismechanism can be used to select from up to 15 different setpoints for each Limit Function as well as allowing apattern of which functions are active.
New Motion Device Axis Object Attributes:
During normal operation the Motion Device Axis Object and the various Safety Functions Objects operate
independent of each other. However, when safety demands occur, it is important that there be coordination between
the drive safety functions and the motion controller. For example, when a Safe Stop 1 safety function is activated,the motion controller must decelerate the motor to a stop. To initiate the deceleration, the motion control system
must have an awareness of the Safe Stop 1 activation.

Safe Stop 1 (SS1) Timing Diagram
There are at least three different ways for the motion controller to recognize that Safe Stop 1 has been activated by
the safety controller as illustrated in the diagram below.
Option 1 is where the safety controller sends the SS1 Request bit to the motion controller via a Produced-Consumed
controller connection. This option would require a separate connection resource, connection configuration, andprogramming.

2014 ODVA Industry Conference

20©2014 ODVA, Inc.

Option 2 is where the motion controller polls the drive’s Safety Core for the SS1 Active bit using a Get Attributeservice. Polling the drive for safety status information would be a very inefficient use of network resources andwould also require programming to initiate the Get Attribute service.
Option 3 is by far the best option. The Safety Core in this case would pass the safety status information to theassociated Motion Device Axis Object instance managed by the Host CPU. This safety status data would then betransmitted to the corresponding Motion Control Axis Object of the motion controller through the regular CIP
Motion D2C connection update. No additional connections are required, and no addition programming is needed toaccess the safety status data. Note that the safety status data of the drive’s Safety Core is automatically associatedwith the correct Axis instance in the motion controller using this Safety Status Pass Thru mechanism.

SS1 Execution by Standard Controller:
Standard Controller user task detects SS1 Active Status bit is set.
Rung logic executes Motion Axis Stop instruction on associated axis.

SS1 Execution by Safety Controller:
Safety Controller reads Safe Stop Input and applies to SS1 Instruction.
Safety Controller sets SS1 Request in Safety Output Assembly

SafetyControllerStandard
Controller

OPTION 1: Produced Consumed Connection
Safety Controller sends SS1 Active bit to Standard Controller over
Produced Consumed connection. Requires setup of a Produced
Consumed connection. Additional work for the User and allocationof additional connection resources.

Produced Consumed Tag

MotionControl Axis
Object

ty

tA

fe

pu

ut

io
ct
ne
on
C

O

io
ot
M

y

bl

em

C

y

ss

bl

tA

em

pu

ss

In

IP

Sa

u

Attrib

2C

ty

IP

Get

sage

Mes

D

fe

Sa

C

licit

xp
te E

n

IP

C

OPTION 2: Explicit Messaging
Standard Controller polls current Safety Status
attribute containing SS1 Active bit from Safety Drive(or Safety Controller) by executing a MSG instruction
in a Periodic Task. The MSG instructions sends a Get
Attribute service to the drive to get the Safety Statusdata. Requires additional programming andfamiliarity with complex MSG instruction.

n

Safety Program

Safety Connection Status
Safety Supervisor – Device Status
SafetyMonitor(Safety Core)

Safety Stop Status
Safety Stop Faults

MotionDevice Axis
Object(Host CPU)

Safety Limit Status

OPTION 3: Safety Status Pass Thru
Safety Status data in Motion Device Axis Object
containing the SS1 Active bit is passed to theassociated Motion Control Axis Object in theStandard Controller via the existing CIP Motion
D2C connection. Does not require any additional
configuration. Safety Status data in the Safety
Controller is automatically mapped by the system
to the associated Axis tag of the Standard
Controller. No additional programming is required
to map the Safety Status data to the appropriate
axis in the Standard Controller.

Safety Limit Faults

Drive Axis
Safety Core Passes Safety Status data to Motion Device Axis Object

Accessing Safety Status Data
To support coordination between the various safety functions and the motion control functions, three new Motion
Device Axis Object attributes were defined as part of Edition 3.15 of Volume 1 coincident with the release of
Edition 2.8 of Volume 5 supporting CIP Motion Safety Drives.
1.
2.
3.

Axis Safety State – passes the current Safety Supervisor State
Axis Safety Status – passes the current status of each drive safety function
Axis Safety Faults – passes any active safety fault conditions

2014 ODVA Industry Conference

21©2014 ODVA, Inc.

Conclusion:
Drives with network safety connection support are a key component in emerging safety controller based safetyarchitectures. While there are published CIP Safety profiles for “Safety Discrete I/O” and “Safety Analog I/O”
available today, a critical need was identified at the last ODVA conference for a networked “Safety Drive” profile.
This paper describes the recently published Safety Motion Device Profile that directly addresses that need. The
paper began with a review of the EN 61800-5-2 safety functions and different drive safety architecture deployment
options. Two new safety drive device types were defined, one serving CIP Motion drives and one for non-CIP(SERCOS III) drives. Merging existing CIP Motion behavior with CIP Safety behavior created significant design
challenges with respect to state behavior, commissioning, and maintenance. The paper described how these design
issues were resolved, setting a pattern for Hybrid Safety devices to come. Safety Motion Device Profile assemblies
and Safety Motion Objects were the reviewed. Finally, mechanisms to coordinate motion control functions withdrive safety functions were discussed, introducing the concept of Safety Status Pass Thru.
References:
EN61800-5-2 “Adjustable speed electrical power drive systems – Part 5.2 Safety Requirements - Functional”
Volume 1: Common Industrial Protocol, Edition 3.15
Volume 5: CIP Safety, Edition 2.8**************************************************************************************The ideas, opinions, and recommendations expressed herein are intended to describe concepts of the author(s) for the possible use of CIP
Networks and do not reflect the ideas, opinions, and recommendation of ODVA per se. Because CIP Networks may be applied in many diverse
situations and in conjunction with products and systems from multiple vendors, the reader and those responsible for specifying CIP
Networks must determine for themselves the suitability and the suitability of ideas, opinions, and recommendations expressed herein for intended
use. Copyright ©2014 ODVA, Inc. All rights reserved. For permission to reproduce excerpts of this material, with appropriate attribution to theauthor(s), please contact ODVA on: TEL +1 734-975-8840 FAX +1 734-922-0027 EMAIL odva@odva.org WEB www.odva.org.
CIP, Common Industrial Protocol, CIP Energy, CIP Motion, CIP Safety, CIP Sync, CompoNet, ControlNet, DeviceNet, and EtherNet/IP aretrademarks of ODVA, Inc. All other trademarks are property of their respective owners.

2014 ODVA Industry Conference

22©2014 ODVA, Inc.