Jump to Articles from:   Issue 45       Issue 44       Issue 43       Issue 42       Issue 41       Issue 40       Issue 39       Issue 38       Issue 37       Issue 36       Issue 35       Issue 34       Issue 33       Issue 32       Issue 31       Issue 30       Issue 29       Issue 28       Issue 27       Issue 26       Issue 25       Issue 24       Issue 23       Issue 22       Issue 21       Issue 20       Issue 19       Issue 18       Issue 17       Issue 16       Issue 15       Issue 14       Issue 13       Issue 12       Issue 11       Issue 10       Issue 9       Issue 8       Issue 7       Issue 6       Issue 5       Issue 4       Issue 3       Issue 2       Issue 1

CIP Safety began its life serving the DeviceNet fieldbus community with a multi-master, multi-vendor, high integrity communication network. This robust and flexible Safety protocol has now been migrated to EtherNet/IP bringing greater throughput and all the other features of an Ethernet-based medium - while permitting EtherNet/IP safety devices and DeviceNet safety devices to be used together.
By David Vasko

Unlike most industrial safety network approaches which require a different profile and protocol for every network type, the CIP Safety protocol was developed to be network-independent. Because of this basic design philosophy, adding support for a new network type such as EtherNet/IP was a relatively simple matter. The CIP Safety concept was first approved by TÜV in September 2002, the specification was published and the conformance test released through ODVA in January of 20051, and within months of the initial release three vendors were offering 16 certified CIP Safety products on DeviceNet.

During the earliest stages of development and concept review at TÜV, all CIP networks were analysed for running the CIP Safety protocol. Because all CIP network types were originally considered from the outset, the specification changes to release CIP Safety on EtherNet/IP are minor.

Fig. 1. CIP Safety was designed as an open protocol which could work on different networks. It mates well with the real-time and seamlessly bridged networks collective to the Common Industrial Protocol (CIP). CIP Safety is a set of highly integrated safety services which leverage the underlying communications stacks of the standard CIP networks to transport data from a source to a destination.

Designed as an open protocol, it mates well with the real-time and seamlessly bridged networks based on the Common Industrial Protocol2. CIP Safety is a set of highly integrated safety services which leverage the underlying communication stacks of the standard CIP stack to transport data from a source to a destination, as shown in Fig. 1.

It was the decision to partition the safety services and build on the underlying standard communication services which gives CIP Safety its network-independence. This means that the same CIP Safety communication stack can work both on DeviceNet and EtherNet/IP3.

The protocol ensures integrity through the use of an extensive set of TÜV-approved protection measures. Of course it cannot prevent communication errors from occurring because all comms networks are by their nature susceptible to noise or disturbances such as cable breakage. The function of a safety protocol is to ensure that communication errors such as message corruption, delay, insertion, loss, repeat are detected. (See table below: What is an industrial safety network?) CIP Safety is unique in that is uses network-independent measures to detect these errors.

For most applications, when an error is detected, the device will go to a known safety mode, typically a de-energised 'failsafe' state. The safety code in each device is responsible for detecting these communication errors and determining how the device will react to them. This safety code is executed in a high integrity section of safety-enabled devices, typically using redundant hardware approved by a certification agency. Since the EtherNet/IP communication stacks are part of the underlying communication network and not part of the safety code, commercial communication stacks can be used.

The safety packets coming from an EtherNet/IP safety device are encapsulated within a standard EtherNet/IP data frame. This exactly corresponds to the manner in which safety packets coming from DeviceNet safety devices are encapsulated within a standard DeviceNet data frame - as shown in Fig. 2 below. Since it is the safety coding and not the underlying communication layers which ensure the integrity of the data, the underlying communication layers can be interchanged.

Relationship to DeviceNet
CIP Safety on EtherNet/IP does not replace CIP Safety on DeviceNet, it complements it. Just as DeviceNet and EtherNet/IP serve different applications, CIP Safety on DeviceNet and EtherNet/IP will serve different applications. When to use EtherNet/IP or DeviceNet for safety depends largely on the same trade-offs in applying standard EtherNet/IP and DeviceNet communications.

Fig. 2. The safety packets coming from an EtherNet/IP Safety node are encapsulated within a standard EtherNet/IP data frame, the same way the safety packets coming from DeviceNet Safety node are encapsulated within a standard DeviceNet data frame as shown. Since the safety coding and not the underlying communication layers ensure the integrity of the data, the underlying communication layers can be interchanged.

Factors such as distance, packet length, response time, device cost and device power requirements will determine which network makes the most sense for a particular application. In an application where large distances, larger safety packet sizes or greater throughput is required, CIP Safety on EtherNet/IP will have advantages over DeviceNet. In applications where DeviceNet bandwidth is sufficient or power via the network is required, DeviceNet may have an advantage over EtherNet/IP.

It seems obvious that using the same safety communication protocol over both media will provide a more consistent user experience during installation, verification, operation and maintenance. This consistency allows easy user-migration between CIP Safety networks.

The secondary benefit of consistent media-independence is that a safety connection can span across multiple subnets. Since it is the safety coding and not the underlying communication layers which ensure the integrity of the data, the underlying communication layers can be interchanged and intermixed even across subnets. Thus a safety connection can start on EtherNet/IP and end on DeviceNet as shown in Fig. 3.

Safety messages are encoded in the safety application layer of the transmitting device and decoded and checked in the safety application layer of the final receiving device. Intermediate devices such as bridges or linking devices have no recognition (or a requirement for knowledge) of the contents of the runtime safety protocol; they are simply a transport mechanism for the encapsulated safety message.

Fig. 3. Since it is the safety coding and not the underlying communication layers which ensure the integrity of the data, a safety connection can start on EtherNet/IP and end on DeviceNet.

All safety protocols must detect the age of the received data to ensure the desired safety time is being achieved. When a safety protocol goes through a complex device with retentive memory such as a bridge or router, the failure mode and effect analysis of the protocol must ensure that delays are detected. Not all delays may be detected through simple watchdog protocols: CIP Safety has a time stamp in the protocol which can directly detect the data age for this reason.

Use with enterprise systems
Prior to the development of seamless bridging, safety system architects had to reduce system size, degrade local performance where there were a large number of nodes on a subnet, or had to hardwire the interlock between subnets. Seamless routing solves these problems by allowing the safety data to remain intact in its transfer between subnets.

The diagram (above) shows an example of an enterprise wide control system with Safety controllers and Safety I/O on DeviceNet and EtherNet/IP, together with a linking device between the DeviceNet and EtherNet/IP subnets. This system implements fast response safety loops on the DeviceNet and EtherNet/IP links. The linking devices also provide a method to bridge seamlessly between subnets for cell-to-cell interlocking. Since the majority of the high speed safety traffic is confined to the local link, the overall performance remains high.

Seamless routing also provides flexibility to solve safety applications. Even in a safety system composed predominantly from DeviceNet safety devices, seamless routing using EtherNet/IP can provide greater distances between devices. In cases where Ethernet covers the long distance paths, the local DeviceNet baud rates may actually be able to be increased to reduce the safety reaction time or increase the number of safety devices on a DeviceNet subnet. The overall benefit is a system with greater flexibility, usability, and consistency, since standard and safety communications can coexist in a multi-vendor environment spanning multiple subnets.

Context for EtherNet/IP
The CIP Safety protocol did not actually alter to work under EtherNet/IP. Such specification changes as there are in the release CIP Safety on EtherNet/IP relate simply to enabling the feature and provide recommendations to ensure performance. CIP Safety uses a Unique Network Identifier (UNID) to ensure the correct device is being configured, and to detect possible addressing errors during communications. This UNID is encoded and checked in all safety connections. CIP Safety on EtherNet/IP will use a combination of a user set Safety Network Number (SNN) and the device's IP address to form this UNID.

What is an Industrial Safety Network? An industrial safety network is a fieldbus system that connects devices on the factory floor. It typically consists of a single cable that allows for quick connect/disconnect of replacement devices, simple integration of new devices, easy configuration and communication between the devices, delivery of diagnostic data and a wealth of other features to help workers maintain a safety system more efficiently. But unlike standard communications networks, safety networks are designed not only to tolerate errors within limits but also to detect when specified error limits have been reached and react by transitioning devices to a predetermined safe state. Most modern industrial safety networks conform to the guidelines specified in IEC 61508, EN 954-1:1996 and GS-ET-26/05.02 Principle Rules for test and certification of bus systems for the transmission of safety relevant messages. These guidelines stipulate that measures must be present to detect disruptions to messages such as: Delay Corruption Insertion Repetition Incorrect sequence Masquerade (a message that originates from the wrong device, but appears to come from a correct device) Combinations of detection measures must be used to detect these disruptions since one measure can't detect all disruptions. These measures include: Running sequence numbers Timestamps Time expectation Reception acknowledgements Identification of sender and receiver Data integrity assurance Redundancy with cross-checking and diversity For example if a timestamped message was delayed during transmission, the receiving device could detect the delay by comparing the timestamp to the expected delivery time. If a message was corrupted during transmission, the corruption could be detected if a data integrity measure such as an error checking code was included in the transmission and checked by the receiving device. Sending a message twice or processing the reception or transmission of the message in redundant hardware allows data to be cross-checked to ensure it is correct.

Setting IP Address
CIP Safety on EtherNet/IP does not restrict how the IP address is set in an EtherNet/IP safety device. All existing methods such as DHCP, BOOTP, or Option 82 can be used. However, the UNID in the device must be set through the Safety Supervisor's Propose/Apply services.

Safety I/O Service (Default recommendation).The recommended default for safety I/O connections is point-to-point. This recommendation was made to simplify a user's network configuration in cases where multicast isn't needed.

Duplicate IP Address Detection. Duplicate address assignments are a disruptive condition that should be avoided. CIP Safety on EtherNet/IP will adopt the final duplication IP address detection scheme developed by the EtherNet/IP System jSIG.

UDP Packet Checksums. UDP packet checksums have been an optional function for EtherNet/IP developers. CIP Safety on EtherNet/IP will require these checksums for all safety packets.

An extensible approach
The Common Industrial Protocol (CIP) was designed to be an extensible protocol, as such additional services such as safety, motion or time-synchronisation could be added to the base CIP Network services without having to start from scratch - distributing processing, sensors, and actuators where they are needed. Its USP is that standard and safety communications can coexist in a multi-vendor environment over multiple networks and can span multiple subnets. The promise of productive networked safety systems is becoming possible.

References
1. Open DeviceNet Vendor Association,Volume 5, The CIP Safety specification
2. The CIP Advantage: http://www.odva.org/
3. Trends in Machine Safety: Distributed Safety and Safety Networking ,D.Vasko, 1st International TÜV
Safety Symposium USA Programmable Electronic Systems in Safety Related Applications June 14th/15th, 2005, Cleveland, Ohio, USA
4. CIP Safety: Safety Networking for the Future, D.Vasko & S. Nair, Open DeviceNet Vendors Association,CAN in Automation, iCC 2003.

David Vasko is chairman, ODVA CIP Safety jSIG, and works Rockwell Automation