Synchronizing industrial Ethernet networks
Automation engineers can develop architectures that meet the demands of their applications by understanding the differences between distributed clocks and the IEEE 1588 precision time protocol.
Many machine building and manufacturing engineers have gotten used to industrial Ethernet as a way of life. While they're by no means extinct, traditional fieldbuses with custom hardware and cabling are in the rearview mirror for many enterprises. The question today is no longer whether to use industrial Ethernet; the real question is how to take full advantage of industrial Ethernet and how to ensure best practices are in place.
The general benefits of using one of the many industrial Ethernet protocols for machine networking are numerous, such as for I/O, the motion bus, and safety in many cases. But some protocols have the potential not just to greatly increase the speed of cycle times, but also to generate significant improvements in manufacturing precision, accuracy of processes, and system diagnostics.
The importance of synchronization
Synchronization, for example, is an area where the more advanced industrial Ethernet protocols can make an immediate mark. By implementing synchronization, a consistent time base can be created across applications for any number of spatially separated industrial Ethernet-connected devices and machine sections, e.g., for applications with multiple motion axes to achieve a path through space of a robotic arm, or those involving measurement technology for diagnostics of bearing wear. Synchronization is a key element in modern automation systems to ensure that both simple and complex devices are always synchronized to each other, to external applications, and to events in a reliable, repeatable manner. Device-level digital communication systems (fieldbuses) give the developers and end users of devices the opportunity to network these devices together, with industrial Ethernet being the most recent and most widely accepted entry into this market. However, what technologies are available today for synchronizing a network of Ethernet-connected devices, and how can this synchronization be used to the advantage of the automation engineer?
First, how should the term "synchronized system" be defined? Is it simply defined by how deterministically the frames are sent and received? Is it that the devices know what time the frame arrives and is sent? Also, how does one tackle commanding an I/O to turn on, or a motion move to begin at a future time? What about latching in the time of an external event? There are many factors relevant to the internal workings of the end devices that determine how well the device can interact with the environment, such as reacting to a time-valued command, or sensing when an external value has reached some limit. The answers will be different for each user. However, most will be more concerned with the need to ensure the input or output signal to the wire (or when motion begins, or when ∆T parameters are collected) is as controlled as possible, and with the least amount of jitter possible. Jitter is the variation from a perfect synchronization-or as good as it gets. Other concerns may include the complexity involved to implement and manage such a system.
This article examines two different approaches to industrial Ethernet network synchronization (see Figure 1). The first is IEEE 1588, which is used in many different fieldbus protocols, Internet applications, and switched network topologies. The second approach relates to the concept of distributed clocks as used by EtherCAT, an open real-time Ethernet network. These different approaches, with pros and cons, will be covered briefly.
IEEE 1588 precision time protocol (PTP) offers a solution for implementing network-wide synchronization down to sub-microsecond levels across a variety of transmission media, including over Ethernet. This standard has been adopted by several of the industrial Ethernet fieldbus protocol providers as the means of achieving temporal synchronization in their respective technologies (see Figure 2).
The IEEE 1588-PTP standard does not specify some key parameters for devices, such as the type and frequency of device oscillators. Therefore, there can be various qualities of clocks in a given system, some better than others. A slower clock will have less time resolution and, therefore, will be less accurate with its time and timestamping. Because of this, the IEEE 1588 network has to determine the best master clock (BMC) to use in the network, a negotiation algorithm that involves communicating device parameters to each other and determining the best device to use as the reference clock. Obviously, if all the devices have lower-quality clocks, then the overall BMC may still not offer the performance the user desires. If the network becomes larger, spanning through several subnets may be required, and special switches with IEEE clocks built in will be required, each becoming the BMC of each subnet.
After determining the BMC, the time delay between the BMC and the other IEEE 1588 devices must be determined and periodic timing corrections to the BMC must be issued. Because in IEEE 1588 this has to occur in a switched network environment, the routing delays depend highly on the topology, and each additional switch not only adds delay, but additional devices on the network also increase network traffic, which means that traffic becomes more jittery and susceptible to being queued in a network switch, causing a considerable amount of jitter overall.
The actual timestamps that are accessed and read can vary somewhat in an IEEE 1588 system. The so-called asynchronous timestamp reads occur from one of two places: either a specialized Ethernet transceiver chip, or a specialized media access control-both accessed from software on the host microcontroller via an interrupt from either of these devices. Synchronous timestamp reads occur when the timestamp is inserted into the message as it enters the device. This requires additional specialized hardware, as the timestamp addition changes the cyclic redundancy code of the Ethernet frame, which must be recalculated and changed. The advantage here is that the timestamp and data match. Both of these approaches require a microcontroller (as well as software, RAM, etc.) to be designed into every slave device, which may be overkill for simple devices.