LELAND TESCHLER
Executive Editor
According to ODVA, General Motors announced its road map for standardization on EtherNet/IP for the industrial Ethernet network access across its global vehiclemanufacturingoperations. This decision will affect more than 60 GM factories located in Africa, Europe, Latin America, North America, and the Middle East. |
Among the activities run by the ODVA organization in support of EtherNet/IP is the EtherNet/IP Implementors' PlugFest. Here vendors make sure their EtherNet/IP equipment actually does interoperate with gear from other suppliers according to published specs. If problems arise at these workshops, participants get a clear understanding of the issues involved. |
How do you design an emergency stop for an industrial workcell? There have been few options for approaching such tasks. Nearly all of them have involved hardwiring: The usual method is to just wire pushbuttons directly into the controller to handle emergency situations that could be life threatening.
But hardwiring may soon be only one way of building in can't-afford-to-fail functions. Computer networks are starting to follow international standards for safety which will make them reliable enough to manage even super critical machine operations.
One example of the trend is the effort underway by an organization called ODVA (Open DeviceNet Vendor Association) which is defining safety extensions for the Common Industrial Protocol (CIP). CIP is an upper-layer networking protocol shared by DeviceNet and Ether-Net/IP. Dubbed CIP Safety, the new extensions will let both control and safety devices operate on the same open network. It also will let safety devices from multiple vendors talk across CIP-based networks to other safety devices with no extra programming. (CIP networks currently include ControlNet, DeviceNet, and EtherNet/IP.)
CIP Safety is being designed for use in safety applications up to Safety Integrity Level (SIL) 3 according to the IEC 61508 (Safety Standard for Safety Instrumented Systems International) standards. What's noteworthy about 61508 in this context is that it “really doesn't talk much about networks specifically,” says Dave Vasko, CIP Safety jSIG (joint special interest group) chairperson and manager of architecture development at Rockwell Automation. The special interest group that Vasko chairs is now defining the safety extensions for CIP.
“What we are really doing is following the principles outlined in 61508 and applying them to CIP networks,” he says. For example, the IEC standard doesn't specifically define a method for determining a probability of failure on demand for networks. But jSIG members worked with the German certification agency TUV Rheinland to come up with methodology for making such determinations and for deciding to what level of safety different techniques correspond. The methods that come out of the CIP Safety jSIG then get mapped back to quantitative and qualitative measures that 61508 does spell out, says Vasko.
Interestingly, someone using a CIP Safety network would never know it. “The safety aspect would be transparent to the operation of the network,” says Vasko. “Network operations would just have a higher integrity, high enough for fail-safe applications.”
The first implementation of CIP Safety will be over DeviceNet. Called DeviceNet Safety, it will provide failsafe communication between nodes such as safety input/output blocks, safety interlock switches, safety light curtains, and safety PLCs.
“Traditionally safety typically gets accomplished with hardwired safety relays,” says Vasko. “Components on a DeviceNet safety network comprise a natural stepping stone to replace those hardwired systems.”
The specifications for CIP Safety and DeviceNet Safety should be out before the end of 2004. ODVA expects production quantities of DeviceNet Safety products to become available sometime next year.
Next on ODVA the safety agenda is an EtherNet/IP safety version of the standard. “Once you have safety-oriented DeviceNet cells, it makes sense to interconnect them with certified safety versions of EtherNet/IP to create wider areas of safety control,” says Vasko. Though these standards will follow, there is no set timetable for their adoption.
SYNC SPECS
Also underway at ODVA is an effort to define a set of synchronization services over CIP. The organization's Distributed Motion jSIG plans to define a common-data structure which will let peer motion controllers follow each other for such applications as electronic line-shafting and camming. Their effort, labeled CIP Sync, will link the CIP object model to the IEEE 1588 standard for synchronizing clocks across a distributed network. The jSIG will also define a CIP-to-Sercos gateway function-that lets Sercos drives be configured and monitored from a CIP network.
“CIP Sync will provide a mechanism to synchronize clocks across a distributed network. This will let companies replace custom network interface components with off-the-shelf components,” says Steve Zuponcic, Distributed Motion jSIG chairperson and program manager at Rockwell Automation.
CIP Sync will let distributed-control components share a common time reference. Their clocks will be synchronized to within 100's of nanoseconds of each other. This capability is useful in motion applications where position, velocity and time are inextricably related.
The jSIG's work toward defining a common data structure supports coordination across multiple axes for operations such as camming. Historically, this type of controller-to-controller coordination took place through hardwired encoder feedback across all controllers. Some control vendors have used proprietary networks or other means to handle these feedback signals. But the common data structure envisioned by ODVA will let devices from various vendors work in coordination to effect synchronized machine control.
Finally, the CIP-to-Sercos gateway function will give access to Sercos configuration identification numbers from a CIP network. This will let PCs with configuration software reside on a CIP network such as EtherNet/IP, while configuring or viewing drive parameters on a remote Sercos network.
ETHERNET/IP FOR DUMMIES
The Common Industrial Protocol, or CIP, refers to network technologies that currently include DeviceNet, EtherNet/IP (for Ethernet Industrial Protocol), and the newly released CIP Safety. CIP is considered an open standard. An organization called ODVA, for Open DeviceNet Vendor Association, supports CIP networks by assisting CIP users and working with manufacturers that make CIP devices. ODVA also does conformance testing to make sure CIP products from various manufacturers all can talk to each other.
CIP works on a media-independent platform. One of its big accomplishments is providing a way to put application-layer protocols for ControlNet and DeviceNet over Ethernet. The resulting Ether-Net/IP standard makes it possible for equipment such as I/O and controls from multiple vendors to communicate over a network running an Ethernet protocol. This contrasts with proprietary approaches where controllers running Ethernet protocols from a specific vendor can work only with that vendor's Ethernet I/O.
EtherNet/IP arose because Ethernet by itself doesn't guarantee interoperability between devices from different vendors. The reason is Ethernet only defines a physical media, a scheme for sharing the physical media, and a simple frame format and addressing method for moving data packets across a network. So-called upper-layer protocols not spelled out by Ethernet determine network functions and how devices talk to each other on the network. Upper-layer protocols must run on top of Ethernet. It is in the upper-layer protocols that EtherNet/IP lays out standards useful for industrial settings. These standards are most easily understood by first examining the upper layers of ordinary Ethernet.
One of the upper layers in ordinary Ethernet is TCP/IP, Transmission Control Protocol/Internet Protocol. This layer provides services that let devices transfer messages to each other. However, TCP/IP does not guarantee that the devices know what to do with the messages they receive.
It is an application-layer protocol that lets connected devices understand received messages. Among the most widely used application-layer protocols are HTTP for the World Wide Web and SNMP for e-mail. Industrial devices, however, don't have such well-recognized protocols at the application level. Only in the last few years have standard industrial-application layers become available.
EtherNet/IP defines one of the few such layers. First published in 2000, EtherNet/IP has become widely accepted as a way of letting ControlNet and DeviceNet devices work over Ethernet.
EtherNet/IP uses an approach called TCP/IP encapsulation to let messages for these protocols pass over an Ethernet. For example, a device running DeviceNet would encapsulate a DeviceNet message as the data portion of an Ethernet message. The message gets handled by a chip running the data link layer of Ethernet.
EtherNet/IP networks also employ what's called UDP/IP (User Datagram Protocol/IP) to make possible multicasting via implicit messaging. Multicasting is typified by a source sending a message to a group of destinations (as compared to unicasting: sending a different message to each destination). Implicit messaging puts only real-time I/O information in a data field of the Ethernet message, but no protocol information. The point of multicasting is to minimize network traffic, and the point of implicit messaging is to minimize the time needed to process the message at the node receiving it. The benefit is that such messages can be short, involve little processing overhead, and promote time-critical performance needed for control.
Use of message encapsulation and other techniques lets a message originating on one CIP network such as DeviceNet pass to another CIP network such as EtherNet/IP, without using application-layer protocols. This scheme also lets network bridging devices forward the contents of messages between network ports without acting on the contents of the message.
INSIDE CIP SYNC
The CIP Sync effort will implement synchronization methods described in a standard called IEEE-1588-2002, Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems. It spells out a master-slave relationship among clocks communicating via a subnet. The term subnet refers to a network that doesn't contain routing hardware such as network switches or repeaters.
One can gain a feel for how a CIP Sync network would function by reviewing some of the sync methods described in 1588. An example is the technique outlined for network sync with a hardware assist. Here, one clock on the network is selected as a master clock based on its inherent accuracy and related measures. Other devices on the network slave themselves to this master by exchanging messages with it.
The message exchange is according to the following procedure: Periodically the master broadcasts a sync message to its slaves. The message contains a time estimate of when the sync message hits the network. In the most accurate implementations of 1588 the master will also contain a mechanism for detecting and time stamping when the sync message actually goes on the network. Network devices that use a hardware-assist for synchronization attach the time stamp using a chip that is part of their physical network interface. Use of a chip operating at the physical layer of the Ethernet protocol thereby avoids the time fluctuations inherent to the upper portions of the protocol stack.
Masters that are so equipped follow up the sync message with a second message dubbed the followup-message. The follow-up message actually contains the measured time stamp. Slaves equipped with a sync chip detect and time stamp the arrival of this message, also avoiding the vagaries of higherlevel protocols. Slaves use the sync time stamp and follow-up message to correct their own clocks.
Periodically, the slaves send messages back to the master. This process yields information about delays in the forward and reverse paths that's used to compute the path latency. Slaves use the measured latency to compute the correction to their local clock, thus eliminating time fluctuations in the end devices and latency in the communication path.
The time-stamp technique accounts for variations in simple networks. But some network elements add fluctuations that can't be accounted for with time stamping. Specifically, routers can introduce large delays the size of which can be hard to predict. So IEEE-1588 spells out a mechanism called a boundary clock for logically eliminating routers from the sync communication path. The boundary clock looks like an ordinary 1588 clock in an end device. But it uses a single local clock to serve as a master in either all or all but one of the subnets being synchronized. If there are multiple routers on the network, there is a hierarchy of the boundary clocks so only one serves as a primary source of time for the rest.
Finally, time fluctuations caused by network switches and repeaters tend to be less of a problem. They are cancelled out using techniques analogous to those for simple devices on subnets.