Print this article

Comment

01 May 2004

In sync

New standard allows clocks to link across distributed network.

By Kendal R. Harris, Anatoly Moldovansky, and Steve Zuponcic

Most often we pay only passing attention to the specifics of time, thinking in terms of hours or half hours and letting seconds or even minutes go by unnoticed.

A computer clock may say 3:38 p.m. at the same moment a watch reads 3:40 p.m., and no one stops to notice. Perhaps this is because synchronizing a computer clock and a wristwatch requires catlike hand-eye coordination.

However, there are a few cases when time truly is of the essence and synchronization is vital. On plant floors, a few microseconds can be the difference between precise motion control and substandard production. For example, if the yellow ink hits the newsprint a fraction of a second too late or too early, newspaper readers will squint at blurry pictures. And in another situation, without accurate time tracking, there is no way to know what happened first in a long chain of events that resulted in a massive interstate power outage. In the cases of the motion control system and power distribution application, time is critical.

Although there is an obvious need for time synchronization in manufacturing, current solutions are inadequate because they rely on proprietary technology to reach the desired end, limiting plant integration and the availability of time-synchronization solutions and products. However, with the recent advent of the IEEE-1588 standard—Precision Clock Synchronization Protocol for Networked Measurement and Control Systems—it is now possible to develop solutions over open networks using commercially available technology.

The new standard provides a mechanism to synchronize the clocks across a distributed network, which will allow companies to replace proprietary solutions with a standard solution and custom network interface components with off-the-shelf components.

These benefits of IEEE-1588 are not far off. In 2003, ODVA, an international association that supports network technologies based on the Common Industrial Protocol (CIP), plans to add time-synchronization services for real-time control applications to its CIP.

With the addition of these services, called CIP Sync, original equipment manufacturers and end users should get expanded application coverage of DeviceNet and EtherNet/IP systems. This includes sequence of events recording, distributed motion control, and other highly distributed applications requiring increased control coordination. Because the IEEE-1588 profile matches CIP-based, producer/consumer networks from ODVA, the time-synchronization standard should work with DeviceNet and EtherNet/IP.

CIP Sync will allow users to base control on true time synchronization rather than the more limited event synchronization model used historically. In addition, CIP Sync will allow EtherNet/IP users to use commercial-off-the-shelf Ethernet hardware and standardize on network architectures fully compatible with TCP/IP and user datagram protocol/Internet protocol (UDP/IP). Using a 100-megabits-per-second switched Ethernet system, advanced testing shows CIP Sync can deliver time-synchronization accuracy of less than 500 nanoseconds between devices, which meets the requirements of the most demanding real-time applications.

Why synchronize?

In the case of distributed motion and drive control, synchronization among multiple drives or axes in a system allows for accurate coordination of distributed motion control in electronic line-shafting or camming applications. For these cases, the use of absolute time—or "clock time"—is not necessarily required; however, synchronized control of the various drive regulators is vital.

In multiaxis applications, the execution of the drive regulators occurs at different times (i.e., asynchronously) unless one implements a mechanism to synchronize the clocks that control execution of these regulators. When the individual drives are not in sync with other drives in the system, the applied force of any drive occurs randomly. This leads to a degradation of control in the process and can compromise the system's ability to produce a product that meets the end user's specifications.

Ideally, as multiaxis control systems undergo implementation, the execution of the digital regulating loops in any axis or drive occurs in synchronization with the others around it in the control system. This phasing of control-loop execution allows the distributed drives and motors to act in unison, providing strict control of the process.

Typically, distributed motion control applications require the jitter between the system clocks to be on around a few microseconds. But higher performance applications are driving this requirement to the submicrosecond range. Current solutions achieve tight synchronization between the nodes in a distributed system using proprietary networks and interface components. Custom application-specific integrated circuits in the interface cards control the distribution and synchronization of clocks throughout the system, as well as timely delivery of control data.

Applying the standards

A prototype distributed motion system tested and demonstrated the benefits of IEEE-1588 and CIP Sync. The prototype motion system consisted of three motion controllers. Each controller connected to one drive over a serial real-time communication system (SERCOS), an international standard for connecting digital drives, through a SERCOS adapter card. All the motion nodes connected via standard Ethernet through an Ethernet adapter card.

A "motion planner" in the controller managed the position information for each drive to control motion jogging, moving, and gearing operations. Each drive was referred to as one axis of motion: One drive acted as the master axis, while two of the drives acted as slave axes.

Each slave axis geared to the master axis in a one-to-one ratio; on a periodic basis the controller connected to the master axis sent position references to each of the controllers connected to the slave axes.

The clocks on all nodes in the system synchronized over Ethernet using the 1588 protocol. Clock synchronization over the backplane occurred using a proprietary protocol that was in place before 1588.

For the Ethernet subnet and for the backplane, one node acted as the subnet time master, and all other nodes were time slaves.

Ethernet clock synchronization occurred on the Ethernet adapter card. The card contained a field programmable gate array (FPGA) hardware assist circuit to time stamp incoming and outgoing 1588 protocol messages. The FPGA contained a 64-bit, 25-nanosecond-per-tick, high-resolution tunable clock.

The 1588 protocol ran on a 50-megahertz PowerPC microprocessor from IBM. The 1588 code interacted with the FPGA as specified by the 1588 protocol to synchronize a time-slave clock to its associated master clock on the subnet. A tuning algorithm adjusted the frequency of the FPGA tunable clock with each 1588 "sync" update cycle.

The Ethernet adapter also contained an interface chip to the backplane. Using a simple algorithm, the clock in the backplane chip synchronized to the 1588 clock, and the backplane interface on the adapter served as the master clock. All other clocks on the backplane synchronized to the master clock on the adapter. The adapter represented a 1588 boundary clock node, with the backplane clock classified as a "foreign" clock.

The basic motion operation required the motion tasks running in each node to synchronize to each other. Transactions between nodes—in the controller-to-drive transactions and the controller-to-controller transactions—were based on a synchronized periodic update cycle.

At the beginning of the cycle for controller-to-drive transactions, the controller sent position updates to each of the drives, which used the position updates to control the closed loop position and velocity of the motor. Each drive returned its actual position to the controller, the controller computed a new position, and then the cycle repeated. This constitutes a position update cycle.

At the beginning of controller-to-controller transactions, the controller of the master axis sent a position reference to each of the controllers of the slave axes. The controllers of each of the slave axes used this position reference to "plan" the motion for the slave axis.

To synchronize all motion in the system, the motion tasks and consequently the position update cycles synchronized to the 1588 clock.

1588 implementation

The 1588 protocol was a C/C++ implementation running on the adapter. Most of the 1588 protocol was implemented including sync, follow-up, delay-request, delay-response, and management messages. The time slaves used the 1588 burst protocol to speed clock synchronization during start-up. A burst of eight sync messages underwent implementation.

The system did not implement the "best" master algorithm. Instead the system used the "preferred" master selection to determine the time master for the subnet.

On start-up the slave clocks listened indefinitely for a master clock. The slaves never assumed mastership; there is no provision for more than one "preferred" master.

Some support was able to monitor the integrity of the time master clock. If a slave clock detected the loss of a master clock, it stopped its backplane clock, causing the SERCOS adaptor to shut down the SERCOS ring and stopping all motion.

Synchronized outputs

In the prototype application, an output could trigger a strobe light to illuminate the precise phase position of all three axes.

To achieve a precise output strobe, officials used a special output module with a clock synchronized to the rest of the clocks in the system.

An output value went to the module by the motion planner in the controller with a time stamp indicating the time it should assert or de-assert the output.

To achieve precise output timing, the output module managed the output "schedule," using the task synchronizing circuit previously described.

The prototype application of 1588 with distributed motion over Ethernet—similar to what will be possible via CIP Sync—proved to be reliable and accurate. The hardware assist circuit provided jitter of less than 200 nanoseconds between the master and slave clocks, which is as much as 10 times more accurate than current solutions.

ODVA is now launching a joint special interest group that will help define the implementation process and project milestones for CIP Sync.

This joint special interest group will initially focus on several deliverables, including defining the necessary CIP objects required to leverage the IEEE-1588 standard on EtherNet/IP and DeviceNet, as well as working with the IEEE-1588 committee to adapt the standard to provide specifics needed for application on DeviceNet.

Once CIP Sync is complete, time synchronization on the scale of nanoseconds will be possible. And, unlike synchronizing wristwatches and laptop clocks, it will not even require superhuman reflexes.

Behind the byline

Kendal R. Harris, principal engineer for architecture and development with Rockwell Automation, has twenty-three years of experience in developing communication and control systems. Anatoly Moldovansky is principal engineer for Rockwell Automation's Logix/NetLinx/ Kinetix business and has more than thirty years of experience in developing communication and control systems. He is a member of the IEEE-1588 standard committee. Steve Zuponcic is a program manager for Rockwell Automation strategic marketing and has more than twenty years of experience in industrial controls.