Precision Time Protocol in Data Acquisition and Testing

In the past several decades, many different timing mechanisms have been established to synchronize devices with each other. One of the first standardized Ethernet-based time sync protocols was the Networked Time Protocol (NTP), which was established in 1982 with a major update in 1994 as NTP version 4 that provided for use of a local or public timing master source.

Based on work going back to 1956, the Inter-Range Instrumentation Group (IRIG) B time codes are another option for synchronizing distributed systems. In this case, satellite-based receivers are often used as the source for precision timing. Here, the timing information is transferred directly as analog or digital signals.

FireWire goes back to 1985 and has been standardized as IEEE1394b in 2002 to offer an easy-to-use, automatic time sync mechanism. This standard has found widespread acceptance in peripherals in both consumer and professional markets. For example, all HBM QuantumX modules offer two FireWire ports.

Even with available standards such as NTP, IRIG B, and IEEE1494b, a clear need arose for the use of the established Ethernet infrastructure in synchronizing distributed systems. Among the requirements, the new approach needed to provide higher flexibility and ease of use at lower cost. From IT infrastructure in industry to private households in the consumer marketplace, Ethernet is the de facto worldwide standard for machine-to-machine or human-to-machine communications. Even mobile devices such as smart phones or even vehicles can be linked to Ethernet-based networks through mobile telecom networks like LTE, EDGE or GSM.

How accurate is time synchronous?

We rely on clocks to help us be on time for meetings and other events. In sports, fractions of a second can determine who wins or loses. For high-speed trading in the stock exchange, mere microseconds’ difference in time can alter buying or selling prices by thousands of dollars. In test and measurement applications, highly accurate time stamped signal inputs representing the same physical process captured in the same moment of time play an important role in qualifying and analysing measurement data in real time or during post processing mode. In each of these examples and elsewhere, the definition of "accuracy" of clocks of course depends on the particular application.

What is the difference between absolute and relative time?

Absolute time is needed when measurement data needs to be mapped to a certain real-life event or when two or more DAQ systems are not on the same network. An example where absolute time might be relevant is when the load influence of a train crossing a bridge needs to be monitored and identification of the train would be required to support any further activities such as overload warning. The absolute time is explicitly available when it is represented by a clock.

An absolute time source can be:

Precision Time Protocol (PTP) Grandmaster Clocks

for lab use from company Meinberg is GPS based

for mobile use from company OMICRON is GPS based

GPS sensors

directly using the Precise Positioning Service (PPS) from the GPS sensor

taking over the protocol based absolute time when starting the DAQ job

Network Time Protocol (NTP) master

publicly available in an internet access by for example NIST (http://tf.nist.gov/tf-cgi/servers.cgi)

distributed locally and based on GPS from companies Hopf or Meinberg

running on a PC and taking the absolute time from the operating system

Terrestrial low frequency transmitted radio signal

example here is DCF-77 (atomic clock) run by the PTB in Germany

Simple Network Time Protocol (SNTP) time servers

Most test and measurement applications or processes can use a relative system time, particularly when a test is reproducible and the relative timing of the signals to each other matters the most. If needed at all, absolute time might be part of the META data or integrated in the file name itself, for example 2015-08-03_RLDA-test_Viper_No12.

Sometimes time accuracy is mixed up with reaction, latency or real-time. Real-time ability can be reached by using for example real-time busses like EtherCAT, ProfiNET, EtherNET/IP or many other proprietary field busses.

What needs to be considered when solving real-time and high-speed analysis with one DAQ solution?

In test and measurement we deal with many different types of applications. One aspect of test and measurement focuses on time synchronous measurement and dataanalysis. Examples include structural load test, vehicle testing and Road Load Data Acquisition (RLDA) or bridge monitoring. Another part of test and measurement deals with dynamic actuator based lab testing focusing on simulation, stimulation, control or in-the-loop. Here, data acquisition for the purpose of analysis does not play the major role. The following list provides some key considerations:

Some applications use data rates up to 100 kS/s per channel and more for the purpose of data analysis. Real-time response is not the main criterion and also not possible with regular real-time busses. It would add complexity and would lower the degree of freedom.

Highly accurate instruments work with 24 Bit Sigma Delta AD converters and filters causing phase shift and time delay. Real-time applications are focusing on determinism in the milliseconds range and need short response times. Modern DAQ solutions such as QuantumX from HBM allow splitting sensor inputs to two signals for different purposes (1st real-time, 2nd high-speed time stamped and filtered data).

Both “analysis” and “control” have a different character, workflow, purpose and often responsibility. Combining both in one single solution can cause conflicts, i.e. driving a dyno test stand or electric load and in parallel acquiring high-speed dynamic data from the system under test, the drivetrain. Therefore splitting responsibility and workflow makes sense when Control and Analysis are required.

At the moment there is no worldwide established high performance real-time bus standard available. All solutions like ProfiNET RT, EtherCAT and many others are driven by global industrial players supporting their own technology in their market and mostly in specific applications. The Time-Sensitive Networking (TSN) Task Group is addressing an IEEE standardized real-time Ethernet bus, part of IEEE802.1AS to offer a global standard. DAQ solutions are open to link into many different real-time busses by using gateways.

Real-time needs a master application running in real-time. Stopping this master for some reconfigurations is not an option.

What does real-time mean and what is time latency?

Real-time means deterministic behaviour – a “decision” or “response” needs to be done within a specific time frame and is mainly used in control or automation tasks (sensor -> control algorithm -> reaction / actuator).

Time latency is an aspect that has to be taken into account when it comes to design control algorithms or a response is needed within a given maximum time. Real-time control applications normally require fixed and very low time latency from sensor to controller. For non-deterministic protocols such as Ethernet TCP/IP, CANbus or any PC-based activity, time latency is variable. Time latency also plays a role when data is streamed to a real-time controller for monitoring purposes in case the time stamp sent with the data value is not or cannot be considered.

What is the Precision Time Protocol - IEEE1588:2008 or PTPv2 and how does it worK?

PTP is an international standard specified in IEEE1588 and revised in 2008 with version 2. The Precision Time Protocol (PTPv2) is a network-based time synchronization communication protocol that can be used to synchronize clocks of different device types, providing time accuracy in the sub-microsecond range. PTPv2 is based on Ethernet. Compared to NTP, PTPv2 is embedded in the physical layer and thus we talk about true hardware-based time stamping for precise time synchronization of all participants in an Ethernet network.

PTPv2 is a relative time sync mechanism. One participant is selected to work as the master clock, which delivers time sync messages to all slaves. The sync process starts with a time sync telegram to the network. All participants (slaves) calculate the time difference (delay) between their local time and the given master clock and adapt step by step to a time difference less than 2 µs. For example, assume that the PTP source sends a PTP message advertising a time of 1:00:00 pm. The problem is that this message will take time to reach its destination. If the PTP packet took 1 second to reach its source, it would be 1:00:01 pm, when the source receives a PTP packet indicating 1:00:00 pm. So the network latency needs to be compensated, which is achieved through a series of messages exchanged between master and slave clocks, as shown in the next Figure.

The master clock sends the Sync message. The time that the Sync message leaves the master is time stamped as t1, which can be embedded in the Sync message itself (one-step operation) or sent in the Follow_Up message (two-step operation).

The slave receives the Sync message; t2 is the time that the slave receives the Sync message.

The slave sends the Delay_Req message, which is time stamped as t3 when it leaves the slave and time stamped as t4 when the master receives it.

The master responds with a Delay_Resp message that contains time-stamp t4.

Example: the master time initially is 100 seconds and the slave time is 80 seconds. This is how time would be adjusted in the slave.

All PTP participants need to be PTP capable; this includes Ethernet switches but not the data sink (that is, the PC running DAQ software). The Clock in a DAQ module is named an Ordinary Clock. A Clock in an Ethernet Switch is named a Boundary Clock. The Master is selected automatically if no Grandmaster Clock delivers absolute time information. This mechanism is called Best Master Clock Algorithm (BMC).

Some DAQ topologies are line- or ring-structured with many switches, and thus Boundary Clocks use their own time control loops. As an alternative, the so called Transparent Clock (TC) allows an End-to-End (E2E) sync control and follow-up messages. The introduction of TCs allows for a far simpler solution to correct for variable switch latency. The basic idea of the TC is to measure the time a PTP event message has spent in the switch (the so-called residence time). The residence time is reported to the receiver by the message itself or by a subsequent Follow_up or Delay_Resp message. For this purpose a new message field has been added, the so-called Correction Field is a type of Time Interval that can be used to accumulate residence time along the path of the message, and may also be used for other kind of corrections. The key benefits are:

No configuration required: Transparent clocks do not have to calculate and do not have to be considered in the calculation of the BMC algorithm, so they do not necessarily have to send or receive management messages.

Quick reconfiguration of the network in case of faults.

Faster setup times: in initialization phase and after change in topology, transparent clocks do not have to re-synchronize to a master clock before they can be considered part of a valid synchronized path.

Perfect for small configurations.

Transparent Clocks using Peer-to-Peer (P2P) scale well with the number of devices attached to the subnet and can recover rapidly to changes in network topology. So this mechanism offers a high scalability and it’s best suited for deeply cascaded topologies (large scale systems using many switches in daisy chain).

What are the advantages of PTPv2?

It allows time synchronization between different device types from different vendors by a standardized protocol

What are the procedures for Parameterization of PTP in the DAQ Software?

As QuantumX supports different time sync mechanism, parameterization is needed the first time you set up the network. The default or AUTO system clock timing mechanism is FireWire. In addition to that you can select the following timing sources or mechanism:

PTPv2

NTP

IRIG-B

EtherCAT

You can use the software catmanEasy, MX Assistant or perception parameterizing PTPv2. Click on the screenshots to enlarge.

What are some recommended Ethernet PTP Switches and Grandmaster Clocks?

The following basic characteristics are necessary in selecting a PTPv2 switch:

Ports: 1 in total, support of Power over Ethernet (PoE) according to IEEE 802.3af with < 2 W.

Your PC can be used as Grandmaster Clock as well

We then recommend using a network adapter with Intel i210 chip.

Is PTPv2 downwards compatible to PTPv1?

PTP Version 1 primarily targeted at test and measurement and industrial automation. It is a multicast protocol for use on a LAN with performance exceeding the capability of NTP.

PTP Version 2 or IEEE-1588-2008 is an enhancement to version 1. The versions are incompatible. Some of the many features of the newer PTPv2 standard include:

Multicast messages

Two-step clock

Peer-to-peer (P2P) or end-to-end (E2E) delay mechanism

Sync Interval: 1, 2, 4, 8, 16, 32, 64 or 128 packets/second

Delay Request Interval: 1, 2, 4, 8 or 16 seconds

Support the Transport protocols: IPv4 and the modern IPv6

What accuracy do I get when using PTPv2?

Time accuracy heavily depends on the type of network and its devices. We recommend setting up a private LAN where all network participants fully support PTPv2. With this configuration time accuracy can go down to 100 nanoseconds device to device and its channels. Still you need to consider that different data rates and filters can introduce timing jitter and phase delays.

What is the difference between hardware and software time stamping?

The main difference is in the synchronization accuracy that is achievable. With software-based time stamping used for example in NTP, you can see slave synchronization accuracies down to 100 microseconds in small networks but typically 1 ms. With hardware time stamping it is possible to achieve time synchronization accuracy down to 100 nanoseconds. However, in order to get this level of accuracy, the network topology such as switches and slave hardware must support hardware time stamping.

Can I also use a standard switch and if so what is the effect?

Using Non PTP capable switches is risky. Transferring PTP messages then depends on traffic and thus it is critical in the overall timing. In case the switch supports QoS, this can be solved by a rule to increase priority of PTP packages. In general we do not recommend using Switches without PTPv2 support. In the worst case, PTP packets can be lost and timing and thus required data would no longer be reliable.