01 February 2004
Bypass regional standards headaches
General Motors, seeking to develop common global networking architecture, settles on standard.
By Nicholas Sheble
When EtherNet/IP debuted about four years ago, network folks grumbled about the name, because "EtherNet isn't Ethernet, and IP (industrial protocol) isn't IP (Internet protocol). It's some kind of proprietary marketing ploy."
Never mind that talk now. EtherNet/IP is more than an eye-catching product debut designation and name trading on the established cachet of the Ethernet and the Internet.
Late last year the world's largest car company—General Motors—announced that it would standardize its vehicle manufacturing operations on EtherNet/IP technology.
The Open Device Vendors Association (ODVA), which stewards the technology, said that the EtherNet/IP network will provide real-time communication between GM machine controllers, robots, and process control equipment, as well as provide information to higher-level business systems.
Suppliers to more than 60 GM factories located in Africa, Europe, Latin America, North America, and the Middle East have until 1 January 2007 to make their products EtherNet/IP-compatible.
EtherNet/IP sits on commercial-off-the-shelf Ethernet (IEEE 802.3) and the TCP/IP suite. It also leverages standard user datagram protocol/Internet protocol (UDP/IP, part of the TCP/IP suite) transport services, which provide higher performance and multicast functionality for real-time messaging.
Because it leverages both TCP/IP and UDP/IP protocols, GM and other manufacturers can use EtherNet/IP for both information and control applications.
The technology also integrates well with DeviceNet, which is GM's preferred device-level network in North America. EtherNet/IP (EIP) uses the Common Industrial Protocol (CIP) as its upper-layer protocol and object model.
ARC (a manufacturing and supply-chain-consulting group) advisor Dick Slansky provided insight recently.
"EIP extends standard Ethernet and TCP/IP with the Common Industrial Protocol. This is the same application-layer protocol and object model found in DeviceNet and ControlNet."
"CIP allows EIP and DeviceNet product developers, system integrators, and users to apply the same objects and profiles for plug-and-play interoperability among devices from multiple vendors and in multiple subnets.
"Combined, DeviceNet and EIP promote interoperability from sensors to the enterprise tier applications. GM was also attracted to ODVA's strategy of augmenting CIP with CIP sync by adopting existing standards within it, such as ODVA's plan for clock synchronization via the IEEE 1588 standard."
TAKE POWER ON THE NETWORK
DeviceNet is a proven, stable network technology designed to meet the performance and reliability requirements of the industrial environment. DeviceNet uses Controller Area Network (CAN) for its data link layer and CIP for the upper layers of the network.
DeviceNet is an open standard managed by ODVA and accepted by international standards bodies around the world. In addition, users will appreciate the seamless bridging and routing provided by DeviceNet to other CIP-based networks, which include EtherNet/IP and ControlNet.
DeviceNet is a digital, multidrop network that connects and serves as a communication network between industrial controllers and I/O devices. Each device and/or controller is a node on the network.
DeviceNet is a producer-consumer network that supports multiple communication hierarchies and message prioritization. Its systems can operate in a master-slave or distributed control architecture using peer-to-peer communication.
These systems offer a single point of connection for configuration and control by supporting both I/O and explicit messaging. DeviceNet also has power on the network. This allows devices with limited power requirements to use power directly from the network, reducing connection points and physical size.
DeviceNet follows the open systems interconnection model, an International Standards Organization standard for network communications that is hierarchical in nature. Networks that follow this model define all necessary functions from the physical implementation up to the protocol and methodology to communicate control and information data within and across networks.
As to its physical layer, DeviceNet uses a trunk-line/drop-line topology that provides separate twisted pair buses for both signal and power distribution. Thick or thin cables work as either trunk lines or drop lines. End-to-end network length varies with data rate and cable thickness.
DeviceNet supports both isolated and nonisolated physical layer design of devices. An opto-isolated design option allows externally powered devices (e.g., AC drive starters and solenoid valves) to share the same bus cable. The DeviceNet specifications contain additional information concerning component requirements, protection from bad wiring, and examples.
Several different connector types work on DeviceNet. Both sealed and unsealed connectors are available. Large—mini-style—and small—micro-style—sizes of pluggable, sealed connectors are available. For products that do not require sealed connectors, open-style connectors work.
Screw or clamp connections can go directly to the cable if a pluggable connection is not required. Nodes can be removed or inserted from the network without powering down the network. A unique feature of DeviceNet is the ability to add power taps at any point on the network. This makes redundant power supplies possible. The trunk line current rating is 8 amperes.
FOLLOW THE SAME PROFILE
CAN Controller Area Network
CIP Common Industrial Protocol
ISO International Standards Organization
ODVA Open Device Vendors Association
OSI Open systems interconnection, an ISO standard
TCP/IP Transmission control protocol and Internet protocol
UDP User datagram protocol
Two different types of objects take definition in the CIP specification: communication objects and application-specific objects. Product makers can also define specific objects for situations where a product requires functionality that is not in the specification.
For a given device type, a minimum set of common objects operate. The user benefits from interoperability among devices regardless of the manufacturer or the device type.
Because CIP-based networks sit on a common application layer, the application data remains the same regardless of which network hosts the device. The application programmer does not even need to know to which network a device is connected.
CIP also defines device profiles, which identifies the minimum set of objects, configuration options, and the I/O data formats for different types of devices. Devices that follow one of the standard profiles will have the same I/O data and configuration options, will respond to all the same commands, and will have the same behavior as other devices that follow that same profile.
DeviceNet also has standard mechanisms for vendors to incorporate their own features (objects, attributes, and services beyond those defined in the device profile) into their products in addition to the minimum required objects.
However, one must implement these additional features in strict accordance with the DeviceNet specification in the manner prescribed by the specification.
Another important feature that sets CIP-based networks apart from other network architectures is the ability to originate a message on one CIP-based network such as DeviceNet, and then pass it to another CIP-based network such as EtherNet/IP with no presentation at the application layer.
This seamless bridging and routing capability sets DeviceNet apart from other fieldbus networks. It means that a set of objects included in the specification define the mechanisms that a bridging device can use to forward the contents of a message from one network port to another without acting on the contents of that message.
When using bridging devices that support these objects, the user's only responsibility is to describe the path that a message must follow. CIP ensures that the message progresses correctly, independent of the networks involved.
CIP is a producer/consumer-based model, rather than a traditional source/destination model. Producer-consumer networks use networking bandwidth more efficiently. When a message enters the network, its identity comes not from its destination address, but by its connection ID.
Multiple nodes may then consume the data to which this connection ID refers. The result of this dynamic connection approach provides two clear benefits in the efficiency of the network:
- If a node wants to receive data, it only needs to ask for it once to consume the data each time it broadcasts.
- If a second (third, fourth, etc.) node wants the same data, all it needs to know is the connection ID to receive the same data simultaneously with all other nodes.
ECONOMIES OF SCALE FOR LOW END
Concludes ARC's Slansky, "GM has developed a migration plan for the implementation of global network architecture and is executing their plan.
"Their approach, which is based on GM's common controls architecture, manifests universal advantages that would benefit most manufacturers. GM, in keeping with their overall common direction, is looking to accomplish several objectives.
"These include lowering the overall cost of networking infrastructure through high-volume purchasing of common networking infrastructure components.
"Additionally, such network architecture could leverage common engineering practices across global operations, and allow for common, if not identical, solutions for a high percentage of controls applications.
"GM's journey to common network architecture is not without its issues, both technical and regional. While GM's North American operations will use EIP, DeviceNet, and DeviceNet Safety, which play together very well, General Motors Europe operations at the device level sit on Profibus and Profisafe.
"This would indicate that there will be EtherNet/IP to Profibus bridges and gateways required at some point in the future. The interesting thing to speculate about, however, is how fast the market for low-end pure play Ethernet devices will develop to fulfill the vision of replacing device networks.
"It is safe to speculate that the fieldbus at the device tier will be in place for some time due to factors such as installed base, installed cost, integrated power, and economies of scale for low-end devices." IT
Return to Previous Page