Comment

1 November 2006

Ethernet on the Floor

There is a proper time and place for industrial communications deployment.

By Mark Fondl

There is no doubt about it: Ethernet continues to grow from year to year throughout the automation industry. But the real issue is why aren't users adopting it at a more rapid pace?

While manufacturers have a wide assortment of issues as to why they haven't yet taken the Ethernet plunge, the most glaring reasons are: Who owns Ethernet networks, the IT folks or the control group; education of how and where to properly apply Ethernet; and cost justification for the selected application. Proper applications will not only help create true interoperability but will provide information to all the departments that have a stake in the success of the organization.

There is an abundance of network hardware and software packages that support Ethernet, but there is still skepticism regarding its deployment. The confusion arises from the various applications and re-sponse characteristics of automation in general. Similar to the use of a PC or traditional PLC in control, networking applications vary, and traditional fieldbus or Ethernet solve different requirements.

Most industrial automation environments are diverse in their composition with a varied mix of end devices, controllers, HMI devices, motion control, process data, and I/O. Each application contains several different requirements for communication. Com- munications can be continuous and require deterministic responses (coordinated motion, high-speed discrete, or coordinated control) or managerial (program verification, configuration, or parameter adjustments). A single end device such as a discrete I/O could go into applications where responses could vary from a millisecond to a second. The selection of the appropriate network will then work on a balance between the ability to respond in the time required as well as interoperability and cost effectiveness. The trick is deciding what types of information the user requires. The next step is to deploy the correct technology in order to obtain the best return on investment.

Top technologies

When it comes to communications, there are quite a few methods to accomplish data transfer. Three popular types of communications technologies are: serial communications, fieldbuses, and Ethernet.

Serial communications by technical standards are as old as time. Serial data transmission is the most common method of sending data from one device (define) to another. During transmission, the data must pass through a serial interface to exit a computer or other device as serial data. There are many standards contained in the Electrical Industries Alliance (EIA) standards.

The following are the most common interfaces for serial data:

EIA-232—this interface defines three types of connections: electrical, functional, and mechanical. The RS-232 interface is ideal for the data-transmission range of 0–20 kbps/50 ft. (15.2 m) (Actually the spec doesn't restrict the length to 50 ft.; it restricts the maximum capacitance to 2500 pF, which with most modern cables is 200 ft. RS-232 is compatible with these standards: ITU V.24, V.28, and ISO IS2110.

EIA-422—this defines a balanced interface with no accompanying physical connector. You will find RS-422 commonly used in point-to-point communications conducted with a dual-state driver.

RS-485—this interface resembles RS-422. It sees use in multipoint applications where one computer controls many different devices. RS-485 can interconnect with up to 64 devices.

There are two types of serial communication—synchronous and asynchronous. In synchronous transmission, devices initially synchronize themselves to each other and continually send characters to stay in sync. Even when data is not really going out, a constant flow of bits allows each device to know where the other is at any given time.

In asynchronous communication, you do not need synchronization. It does not require sending and receiving idle characters. It does, however, require start and stop bits to signal the beginning and end of transmission. It is slightly slower than synchronous. An idle asynchronous line has a value of 1, and a start bit has a value of 0.

When the line switches from a value of 1 to a value of 0, the receiver gets an alert to expect a data character.

Virtually every device on the factory floor has a serial port (EIA-232). In many cases, these stay unused. A user can obtain valuable data by utilizing these ports for communication. The complexity comes into play when the serial data needs to go in a format in which an open architecture can understand it.

Serial to Ethernet

Companies are offering a method to encapsulate serial data packets onto Ethernet. This is becoming a very popular method for managing the large variety of devices on the plant floor. There are several different ways in which a user can employ serial to Ethernet. The simplest is a pure serial tunnel. In this case, Serial-to-Ethernet devices are at each end, and the information tunnels over to the Ethernet.

In applications where a manufacturer uses a computer (programming panel, HMI, data server), one can utilize a software package to redirect the communications from a physical serial port to being encapsulated in the PC and directed over an Ethernet connection out of the PC. The computer is set up to have up to 32 serial ports, which are then assigned IP addresses. When the software addresses these ports, communications redirect to the assigned IP address. Each Serial-to-Ethernet device has a specific IP address that will match the intended location.

This is a basic capability of Ethernet encapsulation, and a user can accomplish it with virtually any protocol. In data collection applications, OPC servers are very useful.

The use of the simple encapsulation of serial data requires the client device break communication after completing the exchange. If the connection remains, then no other device can have access to the serial port. In order to solve this problem, several Serial-to-Ethernet companies have incorporated a multi-master function. In these devices, the Serial-to-Ethernet de vice contains firmware that understands the protocol. This understanding allows the unit to handle messages from several clients connected to the Ethernet port. The unit manages the serial traffic to the end device, making sure the responses go back to the appropriate device. The Serial-to-Ethernet device looks as if it is one master tied to the serial port, while all clients believe they are communicating separately to the end device.

Fieldbus uses

Fieldbus technology is the next step beyond the use of standard serial communications. A Fieldbus is a communication technology that utilizes not only a specialized protocol but also a unique physical layer to achieve certain speed and determinism objectives. The physical layer requires a unique chipset for each network to handle the unique elements of each protocol and response characteristics. The most commonly discussed are: Profibus, DeviceNet, Foundation Fieldbus, Interbus S, ControlNet, CANopen, and Factory Instrumentation Protocol. All fieldbus types have their own strengths and weaknesses, and their diversity allows them to go in specific facets of automation. The key aspects of these networks are they have been around for over 10 years and work fine.

Making the link

Similar to the technology to encapsulate serial protocols over Ethernet, a linking device will link a fieldbus to an Ethernet network directly. Foundation Fieldbus incorporates a linking device to link the lower level H1 network to High Speed Ethernet (HSE). The function blocks that transport over H1 go in a similar way as serial encapsulation in that it uses layers 1 to 4 of the OSI model (Ethernet and TCP/IP). The decision by the Board of Directors of Fieldbus Foundation in 1998 leaned heavily toward the use of this commercial standard and not trying to create another standard. In the Foundation Fieldbus network, there is a direct transfer of the function block and its associated information.

Linking devices also connect other fieldbuses to an Ethernet network. The linking devices are intelligent embedded computers that provide a method to communicate to the devices on the fieldbus and represent the data as simply as tables or OPC tags/objects. In the situation of Profibus, a product called Profigate takes the information in the Profibus language and translates it in an Ethernet format in order to traverse the network. The linking device acts as a Class II master and creates OPC tags for all data required to transport over Ethernet. These linking devices provide a method to acquire data from a control system without disruption of the controller or operator interface. Linking devices in a fieldbus-to-Ethernet interface not only connect networks but also create an intermediate translation database. This goes out further with OPC-DX.

Linking devices can also provide a useful way to interface dissimilar fieldbus networks to a common network (Ethernet). These solutions are very attractive when an intermediate computer or SCADA system is not present to consolidate the information. This approach is more direct information from the source and can provide a link without further loading a SCADA system or when intermediary databases are not desirable.

Industrial Ethernet

With Ethernet, the application, regardless of its origin, goes in an IEEE 802.3 frame format, whether the protocol is Modbus, Ethernet/IP, or any application layer protocol.

The application data then encapsulates, and UDP/TCP/IP acts as the transport mechanism. The data then goes into a layer two Ethernet frame format for transportation to the final destination.

When Ethernet came about, users had the mindset of "sharing" information in the same geography. It was very simply a common medium with devices connected directly to it with a media attachment unit. It shared a channel of a given frequency. It is a source/destination-based arbitrary method of access to the network. This means every device has a unique address, and as long as it is valid, the device can access the network anytime the channel is free. This leads to a longer packet delivery time, as there are more nodes contending for bandwidth, trying to push messages through a busy network. Shared Ethernet has variable delays as opposed to fixed delays. As more devices and overhead add onto the network, the more unpredictable the delay time. This has been resolved with the implementation of full-duplex, switched 10/100 technologies. All nodes have a dedicated bandwidth and therefore only receive the information designated for them.

TCP/IP is not s single protocol but rather a family of protocols. These protocols regulate and dictate how communication occurs. Protocols group in families, mostly called suites or stacks. No one protocol works alone but requires the assistance of other protocols in its family.

TCP/IP has almost become synonymous with Ethernet in automation. Keep in mind that Ethernet, TCP, and IP are three separate protocols. Ethernet is simply the physical medium; IP is the protocol that deals with addressing and connects networks together; and TCP is a connection-based protocol responsible for setting up connections and checking the data for proper sequencing and integrity. In automation, these protocols work together, allowing all devices the ability to communicate on a common network medium. The devices on the network still need to be able to understand the language encapsulated in the data packets. Simply stated, a device from one vendor will not communicate with another vendor, as the originating application is different. There is not a common application layer open to all devices. TCP/IP is the common transport mechanism for data transfer over Ethernet.

EthernetIP

EthernetIP utilizes the services and features of the TCP/IP protocol to transport implicit and explicit messages over Ethernet. When referring to Ethernet in ControlNet messaging, it is the same standard Ethernet as described in the IEEE 802.3 specification.

It is not a proprietary version. TCP/IP allows a node to encapsulate ControlNet message in the data field of an Ethernet frame and then send the data to an Ethernet chip instead of the ASIC chip used in ControlNet. By utilizing UDP/IP, implicit messaging can occur, as there is no protocol information, only real-time I/O data. The data undergoes definition at connection time. These messages are small, low overhead messages and are critical for the performance needed for real-time control.

Network management

As Ethernet and TCP/IP become more and more prevalent on the factory floor, there is a growing need to maintain devices and their configurations and optimize the network. Network management is becoming more and more critical to automation. Intelligent devices are cropping up at lower levels on the factory floor.

Network management usually involves a distributed database, polling of devices, generating real-time graphical views of network topology changes, and traffic patterns. As companies realize the cost benefits and productivity gains created by network technology, they begin to add networks and expand existing networks almost as rapidly as new network technologies. The problems associated with network expansion affect day-to-day network operation management and strategic network growth planning.

Each new network technology requires specific expertise.

There are different areas of network management. They are: configuration, accounting, fault, security, and performance. Each has its own goals and specifics. Performance management relates to the various aspects of network performance, so users can maintain internetworking performance at an acceptable level. Configuration management involves monitoring and system configuration information, so users can track and manage the operation of various versions of hardware and software elements. Accounting management measures network utilization parameters, so they can properly regulate individual or group uses on the network. Fault management detects, logs, and notifies users of problems. Security management controls access to network information as designated by guidelines. This is done through Simple Network Management Protocol (SNMP).

A network management system contains two elements—a manager and agents. The manager is typically the PC through which the network administrator performs network management functions and is the network manage-ment station (NMS). Agents are the entities that interface to the actual device being managed. Bridges, hubs, routers, or servers are examples of managed devices that contain managed objects. These managed objects might be hardware, configuration parameters, performance statistics, and so on, that directly relate to the current operation of the device in question. These objects go in a virtual database, called a management infor- mation base (MIB). MIBs define the properties of the managed object within the device.

Every managed device keeps a database of values for each of the definitions written in the MIB. It is not the actual database itself; it is implementation dependent.

SNMP protocol

The basis of SNMP comes from the manager/agent model. SNMP is "simple" because the agent requires minimal software. Most of the processing power and data storage reside on the management system, while a complementary subset of those functions resides in the managed system.

To achieve its goal of simplicity, SNMP includes a limited set of management commands and responses. The management system issues Get, GetNext, and Set messages to retrieve single or multiple object variables or to establish the value of a single variable. The managed agent sends a Response message to complete the Get, GetNext, or Set. The managed agent sends an event notification, called a trap, to the management system to identify the occurrence of conditions, such as threshold, that exceeds a predetermined value. In short, there are only five primitive operations:

• Get: Identifies the object
• Get next: Response of the object
• Get: Response (indicative operation)
• Set: Sets new value or reports error
• Trap: Message from device indicating a condition

SNMP allows managers and agents to communicate for the purpose of accessing these objects.

Growth means management

As networks continue to grow almost exponentially, the need for control is critical. It is more evident in an already sensitive industry. The need for control over the applications and process and the sheer amounts of critical data a user must retrieve is greater than ever before. The ability to monitor, maintain, set alarms, visualize, and contact the proper personnel is critical and necessary in efficient network environments. It is not good to have an intricate, technologically sound network without sound network management.

Remote management

Another added benefit is the ability to remotely manage/monitor/configure a network or device. When there is a problem, a plant engineer can connect and view a particular device from a home computer using a Web browser instead of having to go to the plant and manually check it. Inversely, when there is a problem at the factory, you can configure the device through the management platform to contact the responsible person via e-mail or pager.

Not only will Ethernet extend further down to the lower level devices, but the technology behind them will grow also. Many more devices will have more capabilities as the chipsets from the manufacturers are becoming more compact with more features. There are full TCP/IP chipsets with on-board IO points and Web servers available for less than $15. This is a clear indication of where the technology is going.

ABOUT THE AUTHOR

Mark Fondl is president of ICT, a Newbury-port, Mass.-based network integrator.