Safety Parameter Data
Kevin Colloton
Technology Manager - Safety
Rockwell Automation
Presented at the ODVA2017 Industry Conference & 18th Annual Meeting
February 21-23, 2017
Palm Harbor, Florida, USAAbstract
A functional gap in CIP Safety is being able to change parametric data in a safety I/O class device (or getdata from a safety device) on-demand (when the need arises) based on safety program execution.
Today, parametric data can only be sent when the device CIP Safety connection is opened, or byembedding parametric data as part of a safety output data assembly. Sending parametric data in theForward_Open configuration block is not suitable for program driven parametric data exchange with asafety device. In fact, for a safety device, the configuration block of the Safety Open is part of the Safety
Signature and cannot be modified programmatically without violating the devices safety signature.
Using the Output Assembly for on-demand parameter data transfer is both wasteful and a misuse of I/Oconnection’s intent, not to mention that the number and complexity of the resulting assembly structures
would explode.
With no effective mechanism for on-demand programmatic data exchange, CIP Safety systems limit theflexibility customers have for advanced safety applications, especially for motion safety related functions,and looking forward for high availability (SIS) safety systems.

2017 ODVA Industry Conference

1©2017 ODVA, Inc.

This document identifies a functional gap in CIP Safety, being able to change parametric data in a safety
I/O class device (servos, drives, etc), or get safety data from the device on-demand (when the needarises) based on program execution.
Today CIP Safety is limited to two types of data exchange between the owner (safety controller) and thetarget safety device. Parametric data can only be sent when the device connection is opened, or byembedding parametric data as part of the output data assembly. Sending parametric data in theForward_Open configuration block is not suitable for program driven parametric data exchange with thedevice. In fact, for a safety device, the configuration block of the Safety Open is part of the Safety
Signature and cannot be modified programmatically without violating the signature. Using the Output
Assembly for on-demand parameter data transfer is both wasteful and a misuse of I/O Connection’sintent, not to mention that the number and complexity of the resulting assembly structures would explode.
With no effective mechanism for on-demand programmatic data exchange, the user must resort tomessage instructions for standard I/O class devices, but is left with no solution for safety I/O classdevices. (safety messaging, including explicit safety messaging,is not supported), so we have no CIP
Safety capable message other than I/O connections (class 1), which doesn’t provide a solution for thisproblem. Clearly, there is a need for a new on-demand SIL 3 capable data transfer mechanism. Thispaper highlights the problem, and suggests requirements to be considered for future solutions.

1.2 Objectives
Identify a method that allows CIP Safety I/O device safety related parameters to be changed or read
during runtime by the safety application.

1.3 References[2]

The CIP Networks Library Volume 5, CIP Safety Edition 2.11 April 2015

2. Use cases
For use in this document, parametric data that can be changed by the controller during runtime is referred
to as Class 3 Parameters. Device data that can be read by the controller during runtime is referred to as“C3D”, i.e. Class 3 Data.

2017 ODVA Industry Conference2©2017 ODVA, Inc.

2.1. Motion Safety Functions
Motion Safety Functions can execute in the controllers safetytask as safety instructions, in the target motion device, or inboth (safety task + target device).
We will use the SS1 (Safe Stop 1) function executing in thedrive as an example for this use case, but consider that there
are other motion safety functions (instructions) that are typicalin customer applications. Also consider that a device may havemultiple instructions that the user implements (pointing out thatone device does not always equal one instruction).
In the illustration, the primary SS1 safety parameters are:
1. Monitor Delay Time
2. Max Stop Time
3. Decel Ref Speed
4. Decel Tolerance
5. Stand Still Speed
6. Speed Tolerance
7. Discrepancy Time
Although the need to change any of these parameters duringruntime exists (based on user application requirements), themost likely needing to change are:
1. Monitor Delay Time
2. Max Stop Time
3. Decel Ref Speed
When the user safety application determines a C3P change is needed, typically it’s related to machine
speed, product/production variables, maintenance requirements (speed, inertia, activity, etc.). With thatstated, a typical C3P change could be anytime, daily, weekly, or monthly. The point is we really don’tknow, however we do know that sending C3D data as part of the output assembly is clearly anunworkable solution.
Generally, the C3P data that is sent does not have the time criticality of periodic I/O connection data.
In evaluating mechanisms to pass C3D, it is unacceptable to break the I/O connection (which for safety
effectively initiates a safety demand, which will result in a safe state condition - machine off). Technicallythis is a loss of availability (it’s not an actual safety demand), which typically results in major customer
dissatisfaction.

2017 ODVA Industry Conference

3©2017 ODVA, Inc.

2.2 C3P tags are defined by the safety device profile
It is the responsibility of safety device designers
to identify parameters that have runtime
variability (read or read / write). Being anoptional feature, it’s up to the device vendor toidentify which, if any, parameters can bemodified during runtime.

2.3 C3P tags can be read only, or read/ write
Parameter tags can be read only or read / write.
Device developers determine which tags areread only, and which tags are read / write for
their specific devices.

2.4. Writing C3P tag values
It is required that multiple parameter tag
members in a device can be changed in a single
update event initiated by the application
program.
Where multiple devices are part of an application, each device is handled individually (user applicationresponsibility). It’s up to the application developer to properly manage when messaging is performed.

3.1. Process Safety Systems
The initial development and use of CIP Safety has primarily been in machine safety applications IEC61508, IEC 62061 (high demand systems). Although the safety ratings and functionality of CIP Safety
allows its use in process safety applications IEC 61508 and IEC 61151 (low demand systems), CIP
Safety based systems in process has been restricted due to a lack of system availability (redundancy foravailability).
Process safety applications typically have significant high availability requirements due to nuisance /spurious trip avoidance. The ability to change safety parameters during runtime would be a high value
feature for CIP Safety use in process safety applications as CIP Safety adoption expands.
******************************************************************************************************************************************************The ideas, opinions, and recommendations expressed herein are intended to describe concepts of the author(s) for the possible useof ODVA technologies and do not reflect the ideas, opinions, and recommendation of ODVA per se. Because ODVA technologies
may be applied in many diverse situations and in conjunction with products and systems from multiple vendors, the reader andthose responsible for specifying ODVA networks must determine for themselves the suitability and the suitability of ideas, opinions,and recommendations expressed herein for intended use. Copyright ©2017 ODVA, Inc. All rights reserved. For permission toreproduce excerpts of this material, with appropriate attribution to the author(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, CIP Security, CompoNet, ControlNet, DeviceNet, and EtherNet/IP are trademarks of ODVA, Inc. All othertrademarks are property of their respective owners.

2017 ODVA Industry Conference4©2017 ODVA, Inc.