Synchronization becomes a necessity when devices working at a distance from each other must also work in conjunction. In such scenarios, a local clock, or Master Clock, synchronizes with the device clocks networked within the same system. Due to this need for synchronization, IEEE 1588 was released as a standard of protocol in 2002.
However, if two clocks are set at the same rate, there is no guarantee that they will stay in synchronization. This is why the process of synchronization is continuous. Several factors can cause two identical clocks to lose synchronization. Causes such as differences in temperature, the age of the clocks themselves, and the rate of frequency can all affect the quality of synchronization. It is because of these factors that a need for clock synchronization arose.
IEEE 1588 provides fault tolerant synchronization for different clocks along the same network. There is very little bandwidth consumption, processing power, and setup. IEEE 1588 accomplishes all of this by using the precision time protocol, or PTP. The time protocol synchronizes all clocks within a network by adjusting clocks to the highest quality clock. IEEE 1588 defines value ranges for the standard set of clock characteristics. The Best Master Clock (BMC) algorithm determines which clock is the highest quality clock within the network. The BMC (grandmaster clock) then synchronizes all other clocks (slave clocks) in the network. If the BMC is removed from the network or is determined by the BMC algorithm to no longer be the highest quality clock, the algorithm then redefines what the new BMC is and adjusts all other clocks accordingly. No administrator input is needed for this readjustment because the algorithm provides a fault tolerant.
Bidirectional Multicast Communication is used by the slave clocks to synchronize to the IEEE 1588 grandmaster clock. A ‘sync’ packet containing a timestamp from the grandmaster clock contains the exact time that the timestamp left the grandmaster clock. A ‘follow up’ packet may also be sent by the grandmaster clock which contains the timestamp of the ‘sync’ packet. This allows an accurate timestamp of the ‘sync’ packet by the grandmaster clock. There are times when the exact transmission time is prevented from being known until the entire packet is sent without and collisions detected. This is because of the collision detection and random back-off mechanism of Ethernet/IP communication. Once the packet is completely sent, it is impossible to alter the packet’s contents.
The sending and receiving process of the synchronization packets allows the slave clocks to accurately measure and offset between the salve's own clock and the master clock. Standard methods of clock adjustment implementation are not outlined by IEEE 1588; it only provides a standard protocol for the exchange of messages between clocks. The benefit of this is that clocks from different manufactures are still able to synchronize with each other.
QUALITY OF SYNCHRONIZATION
There are several factors that can affect the exactness of synchronization between clocks within an IEEE 1588 network. Frequency changes in the a clock’s local timing source, which may occur in between in ‘sync’ packets, can cause a clock to lose synchronization from the other clocks in the same system. In order to counteract any possible lost synchronization, high stability timing sources can be used, as well as shortening the time in between ‘sync’ packets. To further improve the timeline of synchronization, Temperature Controlled Crystal Oscillators (TXCOs) and Oven Controlled Crystal Oscillators (OCXOs) can be used. A clock’s resolution can also affect the preciseness of the timestamps sent in the precision time protocol. The higher the clock’s resolution is, the more accurate the timestamp on the ‘sync’ packets. Jitter from an intermediate networking device, such as hubs and switches, can also affect the system’s accuracy of synchronization.
The quality of the Ethernet based IEEE 1588 system and how it was setup can also affect the quality of synchronization. To setup the best synchronized system, one must trade-off between exactness of synchronization, cost, and distance needs. For low speed events that do not depend on time, a standard NTP synchronization over internet, which allows for millisecond level synchronization, will suffice. IEEE 1588 is still an excellent alternative for systems needing sub-microsecond synchronization in geographically arranged systems.
IEEE 1588 boundary clocks, also known as transparent switches, are an effective way to reduce jitter found in an Ethernet based IEEE 1588 system. A switch, acting as a boundary clock, runs the PTP protocol and is synchronized to the master clock. The boundary clock in turn acts as a master clock to all slaves within the same network. Using this setup, all internal latencies and jitter can be compensated for and does not affect the exactness of the synchronization.
Delay_Resp, Delay_Req, Follow_up, and Sync messages are not passed by boundary clocks. The boundary clock’s port will behave like an ordinary clock in regards to synchronization and the best master clock algorithm within a subnet. Whichever port of the boundary clock identifies the master clock will be selected as the slave port. Within the selected subnet, this port is a slave. This will then cause all other ports of the boundary clock to synchronize to the slave port. A parent-child hierarchy of master-slave clocks is determined by the boundary clocks. If cyclic path occur in the network hierarchy, the best master clock algorithm lowers the logical hierarchy to an acyclic graph.
There is an alternative to boundary clocks, which is the use of transparent switches. A transparent switch does not behave as a PTP node within an IEEE 1588 system. Instead, a transparent switch alters the timing contents of PTP packets to compensate for the delay caused by the switch. A transparent switch then calculates how much time a ‘sync’ packet spends within the switch and modifies the timestamp of the immediate ‘follow up’ packet to make up for the delay. PTP nodes can operate as if they were part of a large LAN segment connected by hubs by using transparent switches.
USES FOR IEEE 1588
Precise synchronization would be valued in these applications:
Sign up for our FREE recurring newsletter to stay up to date on topics such as:
» Networking Technology
» Latest Industry News
RTA, Inc. - The Industrial Networking Home for DeviceNet, EtherNet/IP, LonWorks,
Modbus TCP, Modbus RTU, PROFINET CBA, PROFINET IO, BACnet, IEC 61131-3,
IEEE 1588, AS-Interface, PROFIBUS, EtherCAT, CoDeSys and other networks.
© 2009 Real Time Automation, Inc.