Evolving from simply an IT network, Ethernet has become the dominant network technology linking controllers with SCADA (Supervisory Control And Data Acquisition) and plant-wide information systems. Now, Ethernet is poised to make its impact felt on the plant floor. It’s considered the leading technology choice to replace a plethora of fieldbus technologies.
For product developers, the proliferation of different fieldbus technologies has forced multiple, ever-changing variants of their core products. Needless to say, it’s driven up the cost of development and made it difficult to offer complete solutions for their breadth of customers. Fieldbus also has been a dilemma for users trying to manage cost and choose best-in-class control products.
Yet the telecom and IT industries have standardized and cost-optimized Ethernet technology, which promises a common technology choice with only firmware variants. This reduces the cost of development, and more importantly, cuts the cost of industrialization and lifecycle management. Suppliers have seen cost reductions of up to 30% per year on Ethernet technology due to high volumes in the office and telecomm markets.
But can Ethernet be applied to real-time control? First, it’s important to explain what is meant by real time and determinism. Real time is a relative term—real time in telecom and real time in plant-floor control are two different things.
For plant-floor control, we assume real time is the performance required for traditional fieldbus (I/O and intelligent devices) applications. When we refer to performance, we mean application throughput. Application throughput is the reaction time for an input signal to be processed by a controller, which in turn triggers an output event.
For a typical process control application, this might translate to the time between when an "add ingredient" signal is triggered and the valve moves to permit the flow of material. For a typical diverter conveyor application, this would mean the time from an input signal indicating a product on the conveyor until the time an arm needs to move to divert the product to the correct downstream conveyor.
This differs between process and discrete control, but one can assume that most process control applications expect a process change to occur between 100 ms and 1 sec., while most discrete control applications require changes to occur between 30 and 50 ms (see the table). For motion control, where multiple axes of motion are coordinated to make a smooth, angular, or circular motion, throughput could require updates as fast as 250 ms.
To achieve these throughput levels, the device update over the network must be approximately 10 times faster than the application throughput requirement. In process control, device update times of less than 100 ms are adequate for most applications. For discrete control, device update times of less than 10 ms are common. With more demanding discrete control applications, customers are asking for device update times approaching 1 ms. When using a fieldbus for coordinated motion control, update times of less than 100 ms are necessary.
So, first we categorize real time in process-, discrete-, and motion-control categories. Of course, actual applications might vary from these figures, but this represents the vast majority of applications. Because the volume of applications requiring coordinated motion-control applications is relatively small, it can be assumed that more than 90% of applications are able to be served with devices achieving device update times of 1 ms.
With respect to industrial automation, determinism is defined as the "probability" that an event will happen within a specified period of time, not faster or slower. Sometimes, an event that occurs too quickly can be as problematic as an event occurring too slowly, though most designers are concerned with events that are too slow.
In technical terms, Ethernet is a non-deterministic network. In certain architectures, it’s possible for communications to be held up due to collisions or traffic overload conditions. But using modern Ethernet switch technology, which means employing full duplex communications along with twisted-pair topology, and separating control architectures from plant-wide and office networks (either physically or via network routers), virtually ensures determinism.
If commercial off-the-shelf (COTS) technologies, hardware chips, real-time operating systems (RTOSs), stacks, and other technologies are used, device update times of 1 ms are very achievable. This suits Ethernet for virtually all discrete-control applications.
When applying Ethernet to coordinated motion control, the determinism using pure COTS Ethernet solutions probably is inadequate. Special protocols like the IEEE 1588 precision time protocol, or even custom-designed stacks, might be necessary.
Applying special protocols likely will permit the use of COTS hardware, but it will limit the availability of protocol sources. Device developers will have to buy those custom stacks from controls suppliers or design them in-house—an expensive proposition for all but the largest control product suppliers.
For device designers, the more critical aspect in using Ethernet is how its communications interface interacts with the control side of the device or controller. While COTS Ethernet hardware, RTOS, and stacks can provide enough performance, optimal performance might not be achieved if the designer doesn’t take proper care to manage the resources and hardware design.
Designers need to find a balance between serving the needs of the communications network and the device’s own decisions. Capable design architects will make conscious decisions between single or co-processor architectures to achieve the required performance versus product cost tradeoffs.
So, can Ethernet be applied to meet the needs of real-time control? For most process- or discrete-control applications, the answer is yes. Control-system designers, however, must understand a product’s full performance characteristics and how it will behave in a system architecture.
Understanding a device’s network response time, its application throughput, and the controller’s reaction time through the hardware interface and control program all are elements necessary to properly design an Ethernet-based control system. Of course, proper network architecture design using full duplex switches, twisted-pair topology, and routers to separate office and control networks are all key elements to ensuring optimal performance.
It might seem obvious, but it’s worth repeating that an Ethernet-based control system’s performance can be affected by interaction with Voice over Internet Potocol (VoIP), print queue, e-mail, file server, and video streaming networks.