Comment

13 February 2001

Shoot-out at the Ethernet corral

by Eric Byres

When the fieldbus wars ended with the creation of the International Electrotechnical Commission's eight-headed monster standard a year ago in Ottawa, many users gave up all hope for a real fieldbus standard.

They started looking toward Ethernet as the solution for a unified industrial networking standard. After all, Ethernet had completely taken over the office environment and produced what seemed to be a unified solution there. Couldn't it do the same for the plant floor?

Yes, perhaps it could. Now, much to the chagrin of the users, it seems the fieldbus wars have just moved to a new battlefield located right on top of Ethernet.

Ethernet can't keep peace

Ethernet is a worldwide networking standard, and it can certainly bring some standardization to the plant floor. For example, if the industrial world adopts an all-Ethernet stance, we will be much closer to having a unified cabling and interface card standard.

Users would be able to install a single cable type for communications in their plant and know it would work, regardless of their control vendor.

This is certainly not the situation now. Even buses from the same control systems vendor, such as ControlNet and DeviceNet, can require different cabling schemes.

Unfortunately, the Ethernet standard defines only what network experts call the physical layer and data link layer protocols on a communications system.

The physical layer part of the standard defines the cable types, connectors, and electrical characteristics. The data link layer defines the format for an Ethernet frame, the error checking method, and the physical addressing method.

The data link layer also defines the protocol Ethernet uses to determine when nodes can transmit on the network. The scheme is carrier sense multiple access with collision detection.

While the physical and data link protocols are critical to the operation of a network, they are not enough to make a system operational. For example, Ethernet can't help a message find its way through a complex network such as the Internet.

Nor does it define how to carry out specific tasks on a network, such as transferring a file, sending e-mail, or reading a block of registers in a programmable logic controller (PLC). To accomplish these goals, we need to add additional protocols on top of Ethernet to create a protocol suite.

TCP/IP is almost universally added on top of Ethernet to provide the network and transport layers in the open systems interconnect protocol model and to solve issues of routing and end-to-end data integrity. In fact, Ethernet and TCP/IP appear together so often, many people mistakenly believe they are synonymous rather than separate standards.

But even this is not enough. Every network needs a top layer of protocols called application layer protocols. These protocols provide the definition for the tasks or commands that can be executed over the network, such as a procedure that might request 10 words of data to be transferred between two PLCs.

This layer is the flash point for the pending bus war.

Unmasking the gunmen

It would be easy to blame the proliferation of proposed application layer standards on the major controls equipment vendors' greed and desire for market dominance. However, this is only partly the cause. The fact is, the entire industrial market is divided, and different industries have different needs in a network.

For example, an oil pipeline facility will expect the network to deliver different services than what an automotive assembly plant would need. Vendors that dominate in a particular industry sector will quite reasonably want to champion an application layer solution that best meets their customers' needs.

Just like in the previous round of fieldbus wars, there are four or five big guns in the battle and a score of little guys hoping to sneak in. Look at the strengths and weaknesses of some of the current front-running Ethernet products.

TCP/IP is the Internet

The one sure bet in the battle is the application layer protocols that come bundled with the transport and network layers, TCP/IP. These are the well-known Internet protocols such as file transfer protocol, simple mail transport protocol, and hypertext transfer protocol (HTTP).

In virtually every control system, vendors use one or more of these protocols as part of their Ethernet solution. For example, any device that supports an embedded Web server for diagnostic purposes implicitly supports HTTP.

So why not just use the Internet protocols and stop there? Well, unfortunately, these protocols can't currently provide all the functionality that the process control world needs. The Internet protocols are not suitable for chores involving a pressure transmitter or a PLC.

There are some new possibilities, such as simple object access protocol, that will increase the functionality of this family of protocols.

But there will likely be major gaps for years to come. It is these gaps that the rest of the industrial application layer protocols hope to exploit.

Enjoy industry support

First out of the gate, Schneider Automation bundled the Modbus application protocol on top of TCP to create Modbus/TCP. Released in 1999, the Open Modbus/TCP specification has found wide acceptance in the remote I/O market and with midsized equipment manufacturers that want a simple and universal way to make their products Ethernet ready.

The advantage to the Modbus/TCP solution is that both TCP and Modbus are widely supported throughout industry and are simple to implement. The disadvantage is that Modbus does not support an object-based communications model—something most new network technologies are implementing.

When one reads a Modbus device over a network, one simply gets data without any details about its function or format. If one wants to create a vendor-independent network system, one needs functionality that sees a device as more than a collection of registers. The network must be able to see that device as an object.

This is difficult to do with Modbus.

New motion bus innovation

Recognizing that Modbus/TCP has some serious functional limitations, Schneider Automation announced at ISA EXPO/2000 that it was going to back a second initiative called Interface for Distributed Automation (IDA).

The founding companies in the IDA group were Jetter, Kuka Roboter, Lenze, Phoenix Contact, Real-Time Innovations, and Sick. The addition of Schneider suddenly made IDA a serious contender.

The core of the IDA effort is a publisher/subscriber model using Network Data Delivery Service middleware. Devices that are data sources publish their data on a time- or event-based schedule. Subscriber devices may then use the arrival of that data for internal synchronization purposes.

The advantage of this type of real-time scheduling is that it consumes little network overhead yet provides very tight time synchronization.

IDA uses open Internet protocols, particularly HTTP and extensible markup language (XML). XML defines style sheets and data structures of the basic building blocks that define common objects such as drive controllers.

The target market for IDA is the motion control, robotics, and packaging sectors, where highly synchronized networks are needed. Prior to the addition of Schneider, IDA was doomed to be little more than an interesting sideshow.

Now IDA has the potential to be a serious player, particularly as an Ethernet replacement for the Serial Real-time Communication System bus system. It offers one of the most open solutions and appears well enough designed to meet many of the more demanding requirements of industrial control.

The question for IDA will be: Can it get enough user support to force some of the other major vendors into its camp?

Sophisticated but process only

Late in 1998, the Fieldbus Foundation agreed to use Fast Ethernet as the base protocol for its H2 network. It then set out to map all the Layer 2 technologies from its H1 standard into Ethernet and TCP/IP.

The resulting Foundation fieldbus high-speed Ethernet (HSE) is a sophisticated solution that not only offers a full range of services (scheduling, publisher/subscriber services, and an excellent object model) but is also very efficient regarding the processing load it puts on the field device.

In addition, HSE offers one feature that no other industrial Ethernet offering has been able to match: a redundancy system at both the device level and the network level.

In all, HSE is arguably the most sophisticated industrial Ethernet solution and should have certified products on the market this spring.

It also has a number of major vendors backing it, including Fisher-Rosemount, Foxboro, and Honeywell. Its focus is squarely in the process control market, and it has made few efforts to penetrate discrete parts manufacturing sectors such as automotive. This may harm its long-term viability.

Confuse my name, please

On the discrete manufacturing side of the industry, the dominant entry into the application layer sweepstakes is ControlNet International's EtherNet/IP.

While lambasting the marketing department would not be out of order for their deliberately confusing name (IP in this case stands for industrial protocol and not the common Internet protocol), it is technically a well-designed solution.

EtherNet/IP uses the control and information protocol application layer from ControlNet and DeviceNet and maps that into TCP. Like IDA and HSE, it uses an object-based approach to designing industrial control devices. It also provides a producer/consumer model similar to the HSE and IDA publisher/ subscriber models.

EtherNet/IP offers two styles of communications messages. Implicit messaging is used where there is a regular and repeated transport of a specific set of data items. This is useful in situations where both devices know in advance what data needs to be transferred, such as communications between an I/O block and a PLC.

In contrast, explicit messaging is used for onetime transport of a data item such as a configuration command or diagnostics. In this case, only the originating device knows what data to transfer.

Primarily targeted at the discrete parts manufacturing sectors, EtherNet/IP has backing from a number of the leading industrial manufacturers, including Cutler-Hammer, Omron, and Rockwell Automation.

The Open DeviceNet Vendors Association has also supported this solution. Other than Modbus/TCP, EtherNet/IP was the only mainstream industrial Ethernet solution with actual product on the market at the end of 2000.

Siemens taking a gamble

The mystery dark horse of the shoot-out has been ProfiNet from Profibus International. Hinted at in 1999 and officially announced this past summer, it has so far proved to be more concept than actual substance. The scraps of information that Profibus has released imply ProfiNet will be using Microsoft's distributed component object model (DCOM) protocol over TCP.

This is somewhat suspect, as DCOM is operating system specific (it is supported only on Microsoft Windows platforms) and doesn't provide the services that industrial protocols need, such as publisher/subscriber models.

Worst of all, DCOM has huge processing power and memory needs. Just imagine putting 64 megabytes of RAM and a Pentium II in every pressure transmitter—it seems unlikely.

What Profibus is really up to is anyone's guess. Siemens largely controls the organization, and it seems doubtful a company as big and successful as Siemens would be so foolish as to suggest a DCOM solution for all industrial control needs.

Or are the other vendors missing something and about to be ambushed? Stay tuned. IT

Figures and Graphics

• Is it a truce or a ruse?
• The battleground for industrial Ethernet.
• Two industrial Ethernet frames can exist on the same cable but are not necessarily interoperable.
• What is publisher/subscriber messaging, and why is it important?

Sidebars

• Terminology

Author Information

Eric Byres is a frequent contributor to InTech on the topic of industrial communications. He is a registered P.E. and is presently engaged in Internet research at the British Columbia Institute of Technology in Vancouver.