Industrial Ethernet for Automation Networks

By : Jim Pinto,
San Diego, CA.
USA

Today automation products must have Ethernet connectivity. The real question is whether to connect directly via Internet protocol, or indirectly via one of the entrenched industrial networks. Ethernet alone does not guarantee that two devices can talk to each other. There must be compatibility at the application layers.

This article was published by:
Check out Automation.com
Automation.com, November 2006

Today automation products must have Ethernet connectivity. The real question is whether to connect directly via Internet protocol, or indirectly via one of the entrenched industrial networks. Ethernet alone does not guarantee that two devices can talk to each other. There must be compatibility at the application layers.

When Ethernet first arrived a couple of decades ago, its use for industrial automation networking was dismissed. But usage has steadily increased in the automation environment and Ethernet-ready products for device-level networks continue to expand. Ethernet is fast becoming a universal networking systems interface.

Ethernet is familiar to IT departments and office environments everywhere. It’s easier to install and maintain and the technology is much, much cheaper and readily available.

In industrial networking applications, the big advantage is the ability to standardize an entire enterprise—from the plant floor to the corporate boardroom—on one network, providing access to data throughout the enterprise, from anywhere around the world.

Over just the past decade, the pull-through advantages have brought many enhancements to Ethernet standards, especially in areas of determinism, speed, and prioritization. There is no longer any reason why Ethernet cannot be used to build deterministic, open and inexpensive automation network solutions.

The traditional industrial automation vendors are clearly on the Ethernet bandwagon. For example, Rockwell Automation, Siemens and others claim that 70-80% of their automation products are Ethernet-enabled.

Speed is no longer an issue

Ethernet now runs over shielded and unshielded twisted pair copper, coaxial, and EMI-resistant fiber-optic cable. Operating speeds across even conventional wire cabling have increased from 10 Mbps to 100 Mbps. Automatic switches that negotiate 10/100 Mbps are common, optimizing speed and service, as well as allowing a mix of 10 Mbps and 100 Mbps devices on the same network. The higher speed reduces the probability of data collisions and lost data and delays are no longer an issue. For most factory automation applications, 100 Mbps Ethernet is deterministic enough.

Today, 1 Gbps is available, and 10 Gbps is near. Gigabit Ethernet is primarily targeted for enterprise-wide backbone networks, and it is showing up in DCS backbones in the process industries. This brings easy “scalability” – when users want to go faster, they simply get a more expensive switch.

The fundamental characteristic of Ethernet networks at any speed is that the average delivery speed degrades in a non-linear way with loading.

Another fundamental problem with standard Ethernet is how to provide for redundancy. Many proprietary solutions have emerged for the commercial world but whether they fully address the industrial problems again depends on the application. An extension, which may eliminate the need for proprietary solutions, is IEEE 802.12. This provides the ability to add redundant links to the network to facilitate automatic recovery of network connectivity when there is a link or repeater failure anywhere in the network path. Undoubtedly there are further considerations for the most exacting requirements - for example safety systems.

Deterministic non-determinism

When first adopted in the mid-1980s as the IEEE 802.3 standard, Ethernet was considered unsuitable for automation purportedly because it was (and it still is) “nondeterministic”. Device response times could not be guaranteed because of data collisions and delays in retransmitting data. Data throughput was considered slow, and the network was subject to electromagnetic interference.

Ethernet’s “nondeterminism” has been vastly reduced by the advanced switching technologies that let multiple devices simultaneously transmit and receive data over multiple network loops. Unlike an Ethernet hub, which bridges all network ports into a common pool, an Ethernet switch lets users divide a network into virtual local area networks (LANs). These segments devices into logical workgroups, helping local data communications stay local. Ethernet switches also typically have a fast internal backbone, which helps eliminate collisions among data packets and, therefore, lost packets. Faster switches can quickly swap network lines, thereby responding very quickly to anomalies such as miscommunications, power failures, and device failures.

By splitting up the network in multiple collision domains using switches (or bridges), the prices of which have dropped dramatically as a result of the Internet revolution, every port on a switch is in its own collision domain and as such no more collisions between devices attached to the switch take place.

Adding some intelligence—namely, software or firmware—to the switch improves quality of service and adds queue management capabilities. By assigning a priority to time-sensitive data, intelligent Ethernet switches can elevate that traffic above lower-priority data. This ensures that high-priority traffic always traverses the network even if the network becomes congested. The switches also have capabilities that can classify, reclassify, police, mark, and even drop incoming data packets as application priorities require.

Protocols

Until recently PLCs communicated with slave machines or I/O using one of several possible open or proprietary protocols, such as Modbus, Profibus, ControlNet/DeviceNet, Foundation Fieldbus and CANopen. Because of its growing usage, there is increasing interest in the use of Ethernet as the link-layer protocol, with one of the above protocols as the application-layer.

TCP/IP is almost universally used on top of Ethernet to provide the network and transport layers to deal with the issues of routing and end- to-end data integrity in the open systems interconnect model. TCP/IP contains and sustains the well-known Internet protocols such as FTP, SMTP and HTTP.

Different controls suppliers use one or more of these protocols, although by themselves cannot provide all the functionality that the process control world needs. The Application Layer Protocols provide definition for the tasks or commands to be executed over the network. This is where the commonality between the differing control networks ends. Without a defined control networking standard, different vendors are providing application protocols bundled on top of TCP to complete their process tasks.

The advancements now in place in Ethernet/IP, based on DeviceNet/ControlNet Control and Information Protocol (CIP), allow consistent access to programmable logic controllers on the factory floor without vendor specific software. Going forward, this consistent access will be applied to the actual devices on the factory floor and in the process control environments.

Several fieldbus manufacturers have more recently recognized the advantages of Ethernet, related primarily to the physical layer, particularly the bandwidth, which can be higher than 100Mb/s rather than up to 12Mb/s for most fieldbusses.

The real challenge in factory automation and embedded machine control is not to choose one network technology, but to select several of them in order to best fit the different requirements of a particular application. If requirements change, being able to reuse an application software investment seems like a good idea. To make this happen, one needs a common data model that allows the porting of application software from one network platform to another.

Anyone who has had to perform “mapping” between dissimilar proprietary devices will welcome the Foundation Fieldbus HSE standard. The task of relating signals and statuses between systems remains tedious, time consuming, prone to errors, and challenging to validate, troubleshoot, and maintain. The elegance of H1, where communication of measurements, signal statuses, engineering units, and alarms is uniform and vendor-independent, is now available at the HSE process control network level.

H1 is a device-level bus technology great for field instrumentation such as transmitters, analyzers, control valve positioners, and signal conditioners. However, the H1 technology is not suitable for the remote-I/O level and control-level networks, and therefore, never found its way into products such as variable speed drives, motor control centers, remote-I/O subsystems, and flow computers. There was always a need to add another bus technology such as DeviceNet or Profibus DP for variable speed drives and remote- I/O, such as for high volumes of discrete I/O. Mixing bus technologies is possible in most control systems. However, it is always more complex to support multiple bus technologies rather than just one.

The growth of IP

The growth of the Internet and the adoption of the Internet Protocol (IP) have cemented IP as the core of the global enterprise network at all levels – both Internets and Intranets.

IP technology and the market forces behind it have shown tremendous ability to adapt to and to exploit new networking and communications technologies as they emerge. The Internet is firm proof of IP networks being capable of scalability, an issue of relevance to the discussion in hand. Also security solutions are now appearing which address a wide range of needs – encryption, authentication, digital signatures etc.

TCP/IP is used on most computer platforms and is currently embedded in every copy of Microsoft's Windows operating systems. Nearly all operating systems – computer and embedded (RTOS) – support a TCP/IP stack.

A major benefit of Ethernet is that through TCP/IP it is the principal network for both Intranet – commercial network within the factory, and Internet – for connection between factories. There is one thing one can say with almost certainty – that a control device must have connectivity to the Ethernet. The real question to be answered is will that device be a node directly on Ethernet or indirectly i.e. via one of the entrenched device networks.

The fundamental point is that TCP/IP on its own does not guarantee that two devices can talk to each other. There needs to be compatibility at the application layers. In the commercial world common services for file transfer (FTP), terminal emulation (Telnet), e-mail (SMTP) and others have been established. We need a similar situation in the Industrial World.

Imagine the situation where several devices are connected to Ethernet but because they are incompatible at the application layer, they cannot converse with each other. It is only by users being fully aware that TCP/IP alone does not guarantee that two devices can communicate that pressure can be applied in order that a IEEE 1451 like solution can emerge with the type of benefits outlined.

Neither will the existing popular field-buses which are now well entrenched disappear in the medium term. Therefore we will have a hybrid situation with Ethernet nodes with both direct I/O connectivity and connectivity via one of the field-buses. However representation of all types of devices, both programmable and fixed functionality must be consistent.

There is absolutely no doubt that Ethernet will continue to play a very significant part in the industrial networking scene. Since the popular field-buses are well entrenched it is sensible to move forward with mixed systems. But clearly more and more companies will be taking the step of an Industrial Ethernet solution with direct connected I/O.

Related links:

Book Choice
Pinto's Points
Pinto's Points
How to win in the
Automation Business

Click to visit Amazon.com
Go shopping - books, electronics, CD/DVD






Selected advertising coming here.
Contact Jim Pinto
for rates.








Return to Index of all JimPinto Writings Return to Index of all JimPinto Writings
Return to Jimpinto.com Homepage Return to JimPinto.com HomePage


If you have ideas or suggestions to improve this site, contact: webmaster@jimpinto.com
Copyright 2006 : Jim Pinto, San Diego, CA, USA