Jump to Articles from:   Issue 45       Issue 44       Issue 43       Issue 42       Issue 41       Issue 40       Issue 39       Issue 38       Issue 37       Issue 36       Issue 35       Issue 34       Issue 33       Issue 32       Issue 31       Issue 30       Issue 29       Issue 28       Issue 27       Issue 26       Issue 25       Issue 24       Issue 23       Issue 22       Issue 21       Issue 20       Issue 19       Issue 18       Issue 17       Issue 16       Issue 15       Issue 14       Issue 13       Issue 12       Issue 11       Issue 10       Issue 9       Issue 8       Issue 7       Issue 6       Issue 5       Issue 4       Issue 3       Issue 2       Issue 1

Motion control over Ethernet/IP uses CIP Sync to provide the synchronous timing element for the class of application. Defined in the ODVA Distributed Motion jSIG, CIP Sync enables the accurate real-time synchronisation of devices and controllers which require time stamping, sequence of events recording and distributed motion control when connected over networks. The abbreviated description given here has been taken from paper on CIP Sync written by Ken Harris and Steve Zuponcic

The use of time in a control system is generally applied to two different types of application: time stamping applications and frequency based applications. A power distribution application, for example, may represent a time stamping application. Here, the knowledge of absolute time is important since the timing of specific events often needs to be compared from one event to another. Which event occurred first? Did power grid A go down first, or power grid B? How far apart were the events? In these applications, the events may even occur in different geographical regions that have different time zones. For these reasons, the notion of an absolute value of time is required - and this time reference needs to be correlated to the typical time of day standard that is used by everyone around the world. Here, specific events and alarms are time stamped so that correlation of these events can be accomplished after the events have occurred.

On the other hand, there are also many frequency based applications in a control system. Take for example, the regulation of several drives that need to execute in perfect unison so as not to stretch or damage the fabric between them. In this application, the process is optimised when the drives are synchronised. If each drive samples its feedback and executes its control algorithms at precisely the same time, force is applied in a uniform manner minimising the torque differentiations that might exist between the two and enabling better control of the process that affects the material.

In order to sample and execute at precisely the same time, both drives depend on an accurate metering of time in order to execute their control algorithms. These applications don't necessarily need to have an understanding of hour, day, or year; however, they do need to know that current execution has started at precisely 10ms since the last execution. Here, the oscillators on each drive are synchronised against the other's, and the frequencies of both are correlated so that time is metered consistently between both drives.

In addition to using time to synchronising both drives' regulating loops, this application represents a velocity regulated process where speed is ultimately determined by measuring rotation of the motor over time. If the frequencies of both drives are not synchronised, then the scale by which these drives measure speed is different and each drive will regulate to a different speed - despite the fact that their commanded references are the same! This would certainly have an adverse affect on the outcome of the process.

CIP Sync services allow for both synchronisation of the oscillators (frequency) as well as synchronisation of the absolution notion of time in the system (often correlated to UTC or GPS time.)

Object overview

CIP Sync is based on the IEEE 1588 (IEC 61588) standard - Precision Clock Synchronisation Protocol for Networked Measurement and Control Systems, commonly referred to as the Precision Time Protocol (PTP). The standard is designed for, but not limited to, local area networks like Ethernet. The protocol provides a standard mechanism to synchronise clocks across a network of distributed devices. CIP Sync defines the Time Sync Object. The Time Sync Object provides a CIP interface to the IEEE 1588 Standard.

From the IEEE 1588 specification: "The IEEE 1588 standard specifies a protocol to synchronise independent clocks running on separate nodes of a distributed measurement and control system to a high degree of accuracy and precision. The clocks communicate with each other over a communication network. In its basic form, the protocol is intended to be administration free. The protocol generates a master slave relationship among the clocks in the system. Within a given subnet of a network there will be a single master clock. All clocks ultimately derive their time from a clock known as the grandmaster clock. The communication path between any clock and its grandmaster clock is part of a minimum spanning tree."

Distributed clocks

A PTP system of distributed clocks consists of ordinary clocks and boundary clocks. A boundary clock is a clock with a clock port for each of two or more distinct PTP communication paths. For example, a switch that implements the PTP protocol on each of its ports is a boundary clock.

One clock in the system is selected as the master clock. This selection is made by each of the other clocks by examining information contained in special messages termed Sync messages. A sync message is sent periodically by any port associated with a clock claiming to be the master clock. All ports use the same algorithm, termed the best master clock algorithm. If a port of a master clock receives a Sync message from a better clock then that clock will cease to claim to be a master and the receiving port will assume the status of a slave. Likewise if a clock with a port acting as a slave determines that it would make a better master than the current master clock, it assumes the status of master and begins to send Sync messages. Some nodes may be implemented as slave only and will never assume mastership (e.g. an I/O device).

Any IEEE 1588 PTP subsystem consists of one master clock node and one or more slave clock nodes. Each node contains a high-resolution, tuneable clock. Messages are exchanged between the master and slave clocks to provide sufficient information for the slave node to compensate for frequency and offset errors between the master and slave clock.

CIP Sync uses several mechanisms that allow devices to correlate the "frequency" of the device with the absolute notion of time that allows for time stamping in the system. Consider the following example of a system that uses "System Time" as well as "Local Time." Here each device is a part of a community of devices that shares the same notion of System Time. Despite this common notion of time, each device also has a Local Time value that relates to System Time via an Offset value. This model allows each device to maintain a Local Time while also sharing a common System Time. In this fashion, System Time may be compensated for leap seconds or other adjustments without necessarily making any changes to the base Local Time value of the device.

Offset Clock model

CIP Sync defines an offset clock model to address the requirements for industrial control applications. This model is needed because, even though the 1588 PTP protocol defines a mechanism for distributing and synchronising time, it does not define a mechanism to compensate for step changes in time that may occur at the grandmaster clock source. These changes may occur due to one or more of the following conditions:

• The user adjusts the master clock whose type is "HAND" set. (HAND set is a function where the master clock of the system is not automatically corrected as it would be with sophisticated grandmaster clocks originating from a GPS source or the like. This results in the introduction of step changes that cascade through all the slave clocks that would obtain their references from this localised clock.)

• A master with a more accurate clock becomes available (new grandmaster). This may occur during system startup or after the system has been running for some time.

• The time master is temporarily disconnected from the slave clock and then re-connected. In this situation, given any discrepancy in time between the master and the slave, a step change would be required to re-correlate the two.

CIP Sync defines a mechanism to maintain a consistent set of timestamps in the presence of step changes to System Time. A step change in System Time effectively causes a shift in the time base of the system. Any step changes to the grandmaster clock time must propagate through the system. Since, all nodes in the system will not see the step change at the same time, a timestamp taken on one node may be inconsistent with a timestamp on another node. Or a timestamp taken at one instance in time may be inconsistent with a timestamp taken later in time on the same node. A compensation algorithm is needed to make timestamps consistent with each other before they are used in computations.

QoS or Quality of Service will be used to guarantee that time sync packets and other high priority traffic are given timely delivery through network components. On Ethernet, CIP Sync will use 802. 1Q tagged frame packets which support a three-bit QoS field. The priority of 1588 PTP packets will be specified as QoS priority level 7, the highest priority. Other control functions such as 110 and Motion Control will have recommended priority levels in the QoS structure.

Commentary

PTP offers fundamental services for synchronising multiple clocks in a system. It uses a selection process, referred to as "the best master algorithm," which allows each clock in a subnet to choose a master clock which it will follow. This is done by examining a set of "credentials" that each clock passes to the others it is connected to. Any clock in the subnet that has the best credentials becomes the master for that group. As this selection process occurs, a waterfall of master and slave hierarchies is established, which, when followed to the top, leads to the final system master called the grandmaster clock.

After the alignment and instantiation of all master and slave clocks occurs, PTP makes additional provisions for synchronisation of these clocks. Through a set of sync messages PTP offers tools to compensate for offset and frequency adjustments of the slave clocks relative to the master. These messages are simple in implementation and use a very small level of network resources.

CIP Sync adds some additional capabilities to those offered by the Precision Time Protocol. Aside from the basic synchronising mechanisms, CIP Sync also offers the concepts of System Time, Local Time, and Offset. This model allows for the separation of a common System Time from the individual device's Local Time. These are correlated through the individual device's Offset. In this fashion, changes to System Time may be applied without necessarily affecting the device's Local Time. This is important if a discontinuity in frequency or the linear time scale would be detrimental to that device's ability to control properly. Group Sync is another CIP Sync construct, over and above the PTP layer. The Group Sync function allows a group of devices, at an application layer, to become a part of a given community, while ignoring other devices that are not a part of that community. A given set of drives, for example, might need to be synchronised in order to form a working, functional subsystem. Given this, it is important that all the drives within that community be synchronised prior to starting any part of that subsystem.

CIP Sync offers a simple, unobtrusive method for synchronising multiple clocks in a system. It is flexible enough to manage synchronisation for applications that require time stamping, while, in the same system, servicing devices that depend on synchronised frequency. It's services to do not require a lot of system resources, and once integrated, they do not need a high level of management from the user's perspective. Finally, CIP Sync is robust enough to handle the situations that would normally cause disturbances in time to adversely affect the critical elements of the control system.

Reference

Harris K., Zuponcic S: CIP Sync:Time Synchronization for CIP. ODVA 2006 Networks Conference

Ken Harris and Steve Zuponcic are with Rockwell Automation