CIP Safety: Network-Independent Safety for Automation

Executive Summary

Communication networks have changed the look of today’s automation systems by distributing processing, sensors, and actuators to where they are required. CIP Safety™ networks are providing the same benefits to safety systems. CIP Safety extends the industry standard CIP™ network base services by adding CIP Safety services to transport data for CIP-based networks such as EtherNet/IP™ networks with high integrity. This paper presents this scalable, network-independent approach to safety networking, where the safety services are described in a well-defined layer, allowing the underlying network services to be changed. This approach enables the seamless routing of safety data, allowing the user to create end-to-end safety chains across multiple links.

Introduction

The same motivations for greater distances, increased flexibility, reduced cost, and improved maintainability, which originally moved communication networks into the industrial environment, are also driving the development of industrial safety networks, along with the realization of the limitations of traditional hardwired safety solutions. Hardwired safety systems employ relays, which are interconnected to provide a safety function. Hardwired systems are difficult to develop and maintain for all but the most basic applications. Furthermore, these systems place significant restrictions on the distance between devices. As safety system developers progressed beyond basic E-stop functions, they found themselves forced to fall back to hardwired logic techniques, which have been out of widespread use for control functions since the 1970s. Even when they were successful in developing a significant size safety system, these were often costly and difficult to maintain. Because of these issues, and a growing need for process data and flexibility, it is desirable to provide safety services on standard communication networks. The key to these developments was not to create a network that couldn’t fail but to create a system where failures in the network would cause safety devices to go to a known safe state. If the user knew to which state the system would go, they could make their application safe. But this meant that significantly more checking and redundant coding information would be required. Fortunately, communication networks have become pervasive in automated systems and electronics capable of advanced diagnostics are widely available. The foundation of functional safety is the well-established standard, IEC 61508. Following the guidance of that standard, additional safety standards specific to industries, products, and technologies have been developed, such as IEC 62061, ISO 13849-1, and IEC 61784-3. To avoid the complexity and maintenance of designing a dedicated safety-rated network, IEC 61508 and IEC 61784-3 emphasize another option called “the black channel.” The black channel assumes that network is completely unreliable, so diagnostics must exist outside of the network infrastructure. This concept stipulates that if a safety communication protocol has enough error detection built into the protocol, it can be transmitted independently across different network types without degrading the integrity of the safety data. This can include traversing multiple network links and network segmentation techniques. Building a safety communication protocol with the black channel principle can be problematic if the corresponding standard communication protocol is heavily dependent on non-standard network hardware. Fortunately, CIP Safety is based on the Common Industrial Protocol (CIP) which allows network-independent routing of data. These base services were extended to allow high-integrity safety services by the addition of the CIP Safety protocol. This paper presents a solution for a scalable, routable, network-independent safety layer, thus removing the requirement for dedicated safety gateways. Since all safety devices execute the same protocol, independent of which media on which they reside, the user approach is consistent and independent of media or network used.

CIP Safety: Safety Services Built on the Common Industrial Protocol

The Common Industrial Protocol (CIP) is designed to allow different networks to be used with a common protocol. Since it is designed to be media and datalink independent, it allows for expansion to other networks and to grow as Ethernet grows. CIP Safety is an extension to the standard capabilities of CIP, and it has been certified by TÜV Rheinland for use in functional safety applications. It extends the model by adding CIP Safety application layer functionality, as shown in Figure 1.

Because the safety application layer extensions do not rely on the integrity of the underlying standard CIP services and datalink layers, single-channel (non-redundant) hardware can be used for the datalink communication interface. This same partitioning of functionality allows standard routers to be used to route safety data across networks as long as the underlying safety data is not modified, as shown in Figure 2, and between different layers of complex networks, as shown in Figure 3. The routing of safety messages is possible because the end device is responsible for confirming the integrity of the data. If an error occurs in the transmission of data or in the intermediate router, the end device will detect the failure and take an appropriate action.

Only the safety data that is needed is routed to the required cell, which reduces the individual bandwidth requirements. The combination of fast-responding local safety cells and the inter-cell routing of safety data allows users to create significantly larger and more complex safety applications with fast response times.

Implementing Safety

The CIP Safety application layer is specified using a safety validator object. This object is responsible for managing the CIP Safety connections and serves as the interface between the safety application objects and the link layer connections, as shown in Figure 4. The Safety Validator confirms the integrity of the safety data transfers.

[Note: SP = safety producer, P = producer, C = consumer, SC = safety consumer]

Safety Validators Help Ensure Integrity

CIP Safety does not prevent communication errors from occurring, but it ensures transmission integrity by detecting errors and allowing devices to take appropriate actions. The Safety Validator is responsible for detecting these communication errors. The nine communication errors, which must be detected, are shown in Table 1 along with the five measures CIP Safety uses to detect these errors.

Time Expectation via Time Stamp

All CIP Safety data is produced with a time stamp, which allows safety consumers to determine the age of the produced data. This detection measure is superior to more conventional reception timers and watchdog timers. Reception timers can tell how much time has elapsed since a message was last received, but they do not convey any information about the actual age of the data. A time stamp allows transmission, media access/arbitration, queuing, retry, and routing delays to be detected. Time is coordinated between producers and consumers using ping requests and ping responses, as shown in Figure 5. After a connection is established, the producer will produce a ping request, which causes the consumer to respond with its consumer time. The producer will note the time difference between the ping production and the ping response and store this as an offset value to its producer time for all subsequent data transmissions. This value is transmitted as the time stamp. When the consumer receives a data message, it subtracts its internal clock from the time stamp to determine the data age. If the data age is less than the maximum age allowed, the data is applied. If the age of the data is beyond the age limit, the data is discarded so that only recent data is used. Typically, configurable settings allow the user to determine how many missed, late, or lost packets should be allowed before going to the safe state. Once in the safe state, the device application is notified so that the connection safe state can be appropriately reflected.

Time Stamps Provide Availability

A safety network is only useful for production if it is available. False trips reduce availability and limit the useful applications of a network. CIP Safety provides tolerance to minor disturbances by allowing retransmissions. As long as the retransmission is received before the expected time interval expires, the network connection can continue to operate.

Production Identifier (PID)

A Production Identifier is encoded in each safety packet produced to confirm that each received message arrives at the correct consumer. The PID is derived from an electronic key, the device serial number, and the CIP connection serial number. Any device inadvertently receiving a message with the incorrect PID will go to a safe state. Any device that does not receive a message within the expected time interval with the correct PID will also go to a safe state. This measure confirms that messages are routed correctly in multilink applications.

Safety CRC (Cyclic Redundancy Code)

All safety transfers on CIP Safety use Safety Cyclic Redundancy Codes (CRCs) to confirm the integrity of the transfer of information. The Safety CRCs serve as the primary reassurance to detect possible corruption of the transmitted data. They provide detection up to a Hamming distance of 4 for each data transfer section, though the overall Hamming distance coverage is greater for the complete transfer due to the redundancy of the protocol. The Safety CRCs are generated in the safety producers and checked in the safety consumers. Intermediate routing devices do not examine the Safety CRCs. Thus, by employing end-to-end Safety CRCs, the individual datalink CRCs are not part of the safety function. This eliminates the certification requirements for intermediate devices and ensures that the safety protocol is independent of the network technology and it is core to the black channel principle. The Safety CRC also provides a strong protection mechanism which allows underlying datalink errors such as bit stuffing or fragmentation errors to be detected. The individual link CRCs are not relied on for safety, but they are still enabled. This provides an additional level of protection and noise immunity, by allowing data retransmission for transient errors at the local link.

Redundancy and Cross Check

Data and CRC redundancy with cross-checking provides an additional measure of protection by detecting possible corruption of transmitted data. They effectively increase the Hamming distance of the protocol. These measures allow long safety data packets, up to 250 bytes, to be sent with high integrity. For short packets of 2 bytes or less, data redundancy is not required; however, redundant CRCs are cross-checked to confirm integrity.

Diverse Measures for Safety and Standard

The CIP Safety protocol is present only in safety devices; this prevents standard devices from masquerading as a safety device.

Safety Connections

Safety data uses unidirectional and bidirectional safety connections. Safety devices may consume and produce safety data packets. Since each safety connection has an associated PID and timestamp, connectionless communication is not required. Thus, additional noise immunity is provided since connectionless communication is susceptible to packet loss. A Safety Consumer may receive data from multiple producers.

[Note: SVC = Safety Validator Client, SVS = Safety Validator Server, DN = datalink/network, SP = safety producer, SC = safety consumer, P = producer, C = consumer]

[Note: SP = safety producer, SC = safety consumer, P = producer, C = consumer]

Message Packet Sections

Data Section:

• • Short Data Size: Provides high integrity transmission for up to 2 bytes of safety data. It includes an instance of the safety data, the time stamp, and a 24-bit Safety CRC for the entire message; the 3 bytes of the Safety CRC are not contiguous.

1. • Long Data Size: Provides high integrity transmission for up to 250 bytes of safety data. In the long data size, the original safety data is sent along with a 16-bit Safety CRC, an inverted copy of safety data, the time stamp, and a 24-bit Safety CRC to cover the complemented data and time stamp. Like the short data section, the 3 bytes of the 24-bit Safety CRC are not contiguous.

Time Stamp Section: The time stamp section of the protocol is used to mark the production time of all safety productions.

Time Correction Section: The time correction section is used only for multicast messages. It is used to adjust for an individual consumer’s time count for multicast connections. This section is not needed in unicast messages because each producer is only associated with one consumer.

The data section and time stamp section are combined into a single packet, while the time coordination section and time correction section are each sent in their own packet.

Connection Establishment

The EtherNet/IP protocol provides a connection establishment mechanism using a Forward_Open service, which allows producer to consumer connections to be established locally or across multiple links via intermediate routers. An extension of the Forward_Open, called the Safety_Open service, has been created to allow the same multi-link connections for safety.

There are two types of Safety_Open requests:

• Type 1: With configuration: Configuration and connections are established simultaneously. This allows rapid configuration of a device with simple and relatively small configuration data.
• Type 2: Without configuration: The safety device must first be configured, and the Safety_Open service then establishes a safety connection. This separation of configuration and connection establishment allows the configuration of devices with large and complex configuration data.

In both cases, the Safety_Open service establishes all underlying link layer connections across the local link as well as any intermediate links and routers.

Configuration

Before safety devices can be used in a safety system, they must first be configured, and connections must be established. The process of configuration requires configuration data from a configuration tool to be placed in a safety device. There are two possible sequences for configuration:

• Configuration tool connected directly to device: The configuration tool writes directly to the devices to be configured. The connection establishment must be a Type 2 Safety_Open.
• Via an intermediate device: The tool first writes to an originator. For modestly sized configurations, the Type 1 Safety_Open can be used to configure the device at the same time as the connection establishment. For very large configurations, a separate configuration download and Type 2 Safety_Open can be used for connection establishment.

Configuration Implementation

CIP Safety provides the following protection measures to ensure the integrity of configuration:

• Safety Network Number (SNN): Provides a unique network identifier for each network in the safety system. The SNN combined with the local device address allows any device in the safety system to be uniquely addressed.
• Password Protection: Optional password mechanism provides an additional protection measure, prohibiting the reconfiguration of a device without the correct password.
• Configuration Ownership: The owner of a CIP Safety device can be specified and enforced. Each safety device can specify that its configuration is configured by a selected originator or that the configuration is only configured by a configuration tool.
• Configuration Locking: Provides the user with a mechanism to confirm that all devices have been verified and tested before being used in a safety application.

Safety Devices

The relationship of the objects within a safety device is shown in Figure 14. Note that CIP Safety extends the CIP common object model with the addition of Safety I/O assemblies, Safety Validator, and Safety Supervisor objects.

Safety Supervisor

Provides a common configuration interface for safety devices. It centralizes and coordinates application object state behavior and related status information, exception status indications (alarms and warnings), and defines a behavior model, which is assumed by objects identified as belonging to safety devices.

Summary

Communication networks have changed how today’s automation systems operate by distributing processing, sensors, and actuators where they are needed. The CIP Safety protocol provides these same benefits to safety systems by providing a scalable, routable network-independent safety protocol. Functions such as multicast messaging provide a strong foundation that enables users to create fast-responding local cells that improve safety distances, while advanced functions such as multilink routing permit the seamless interconnection to remote cells to meet the expansion needs of the future.

David A. Vasko & Oliver C. Haya  • Rockwell Automation

Contact us for quotation and support

[formidable id=”1″]

Contact Information

Thanks for visiting our website. For more information, please contact:

Servo Dynamics Engineering Co., Ltd

Tel: +84 28 3740 2128
Email: sales@servodynamics.com.vn
Website: www.servodynamics.com.vn
Official Account Zalo: Servo Dynamics Engineering

Saigon

4/1B Luong Dinh Cua Str., An Khanh Ward, Thu Duc City, HCMC, Vietnam
Tel: (84-28) 3740 2128
Fax: (84-28) 3740 2129

Da Nang

120 Xo Viet Nghe Tinh, Hoa Cuong Nam Ward, Hai Chau District, Da Nang, Vietnam
Tel: (84-23) 6361 1128

Ha Noi

Unit 05, 15th Floor, Han Viet Tower, 203 Minh Khai Street, Hanoi, Vietnam
Tel: (84-24) 3632 1617
Fax: (84-24) 3632 1618