Time stamp your communications
Hey, buddy, have you got the time? You can answer “yes,” now that the IEEE 1588 Standard Precision Time Protocol (PTP) is available to industrial automation applications for precise time synchronization (PTS) on Ethernet networks. PTS provides accurate time synchronization for distributed control nodes.
Hey, buddy, have you got the time? You can answer “yes,” now that the IEEE 1588 Standard Precision Time Protocol (PTP) is available to industrial automation applications for precise time synchronization (PTS) on Ethernet networks. PTS provides accurate time synchronization for distributed control nodes. A triple-speed Ethernet medium access control (MAC) is essential for supporting the IEEE 1588 Standard and can be implemented in an FPGA (field programmable gate array).
Time difference between master and slave is corrected, and delay measurement or clock skew correction determines delay between slave and master.
The IEEE 1588 PTP synchronizes an industrial control system to within less than a microsecond. This timing includes synchronizing local clocks in sensors, actuators, and other terminal devices using the same network that also transports process data. This precise timing provides a solid basis for real-time Industrial Ethernet, whereas before, real time capability was only available as part of specially optimized systems. Using the same network used for transporting process data means accurate time can be distributed with no additional network infrastructure.
The IEEE 1588 PTP functions by organizing network clocks in a master-slave hierarchy. PTP identifies the master clock and then arranges for a two-way timing exchange, as shown in “IEEE 1588 synchronization scheme.” In this scheme, the master transmits messages to its slaves to initiate synchronization. Each slave then responds to synchronize itself to the master. This sequence is repeated throughout the specified network.
Incoming and outgoing PTP-packets are time stamped, at the start of frame (SOF) of the corresponding Ethernet packet, at each point in an IEEE 1588-enabled network. The protocol then exchanges this information between master and slaves using five IEEE 1588 message types: SYNC, DELAY_REQUEST, FOLLOW_UP, DELAY_RESPONSE, and MANAGEMENT. Protocol software uses these messages to calculate the offset and network delay between time stamps, then applies filtering and smoothing, and adjusts the slave clock’s phase and frequency as needed.
IEEE 1588 networks are automatically configured and segmented. Each node uses the best master clock algorithm (BMC) to determine the best clock in the segment. In this process, BMC compares the properties of the communicating clocks, which include accuracy, layer, drift, and variance. From this information, the BMC derives states for all local ports. The current properties of the master clock are cyclically transmitted to the slaves in synchronization messages.
IEEE 1588 example shows offset and delay correction to synchronize clocks.
PTP is based on IP multicast communication and isn’t restricted to Ethernet. It can be used on any bus system supporting multicasting. Every slave port synchronizes the local clock for its node to the master clock by exchanging synchronization messages with the master. The actual synchronization process is divided into two phases.
First the time difference between master and slave is corrected. This is the offset measurement. During this correction, the master cyclically transmits a unique sync message to the related slave at defined intervals. This sync message contains an estimated value for the exact time the message was transmitted.
The master measures exact transmission time, while slaves measure exact reception times. The master then sends in a second message—the follow-up message—containing the exact time of transmission of the corresponding sync message to the slaves. When the first sync message and the corresponding follow-up message are received, the slave calculates the correction (offset) in relation to the master, taking into account the reception time stamp of the sync message. The slave clock must then be corrected by this offset.
Second, the delay measurement or clock skew correction determines the delay or latency between slave and master. The time difference between master and slave clocks is a combination of clock offset and message transmission delay. Hence, correcting clock skew is performed in two phases: offset correction and delay correction. The master clock initiates offset correction using sync and follow-up messages, as shown in “Offset and delay correction.”
When the master sends a sync message, the slave uses the local clock to time stamp the arrival and compares it to the actual sync transmission in the master clock’s follow-up message. The difference between the two time stamps represents the offset of the slave plus the message transmission delay. The slave clock then adjusts the local clock by this difference at point A.
To correct for the message transmission delay, the slave uses a second set of sync and follow-up messages with a corrected clock to calculate the master-to-slave delay at point B. The second set of messages is necessary to account for variations in network delays. The slave then time stamps the sending of a delay request message. The master clock time stamps the arrival of the delay request message. A delay response message is then sent with the delay request arrival time stamp at point C.
The difference between time stamps is the slave-to-master delay. The slave averages the two directional delays and adjusts the clock by the delay to synchronize the two clocks. Because the master and slave clocks drift independently, periodically repeating offset correction and delay correction keeps the clocks synchronized.
The delay measurement is performed irregularly and at longer time intervals than the offset measurement. In this manner, network and terminal devices are not heavily overloaded. But a symmetrical delay or same value for both directions between master and slave is crucial for delay measurement. The synchronization process eliminates temporal fluctuations in PTP elements and the latency time between master and slave.
An IEEE 1588 boundary clock is used on network infrastructure components, such as switches and routers, to compensate for the jitter introduced by those components. In a system with a single IEEE 1588 boundary clock, it is at the root of this hierarchy and serves as the master clock for all clocks in each of the subnets. Aside from its synchronization functionality, an IEEE 1588 boundary clock provides for the appropriate re-transmission of 1588 management messages.
Key for implementing the system is a clear interface definition. The IEEE 1588 PTP comprises hardware and software elements. In the hardware element, high-precision time is generated while reading the time stamp on the synchronization packets in both transmit and receive directions. The message detector analyzes incoming and outgoing packets and detects synchronization packets based on specific values in the packet. For these packets, exact time and identification of the packet are saved.
Hardware and software suppliers have contributed IEEE 1588 PTP implementations. A most efficient implementation is believed to be the “MorethanIP 1588 Tri-Speed Ethernet MAC core.” This programmable 10/100/1000 Ethernet MAC with IEEE 1588 support integrates a standard IEEE 802.3 Ethernet MAC with a time stamping module. It supports Ethernet applications requiring precise timing references for incoming and outgoing frames to implement the IEEE 1588 distributed time synchronization protocol. This core is optionally delivered in generic synthesizable HDL code for use with an FPGA or ASIC or in an FPGA encrypted source format.
Michael Samuelian is director for Altera’s Broadbase and Industrial business unit in San Jose, CA,
|Search the online Automation Integrator Guide|
Case Study Database
Get more exposure for your case study by uploading it to the Control Engineering case study database, where end-users can identify relevant solutions and explore what the experts are doing to effectively implement a variety of technology and productivity related projects.
These case studies provide examples of how knowledgeable solution providers have used technology, processes and people to create effective and successful implementations in real-world situations. Case studies can be completed by filling out a simple online form where you can outline the project title, abstract, and full story in 1500 words or less; upload photos, videos and a logo.
Click here to visit the Case Study Database and upload your case study.