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

Real-time capability is on everybody's lips. Until recently it was only available as part of specially optimised systems. But as with all things in industrial comms, convergence is starting to happen. The Precision Time Protocol embodied in IEEE1588 provides a solid basis for real time industrial Ethernet which now promises to develop rapidly - and independently of specific operating systems.
By Dirk Mohl

Before tackling this subject in any meaningful way, one must define 'real-time capability'. A system, in relation to an application, can be termed as capable of real-time operation if all timing requirements of the application are met by the system. This dictates clearly defined temporal behaviour under all operating conditions.

If hard real-time is to meet the requirements of motion control applications, the communication system must guarantee deterministic behaviour. Only a few special field buses currently achieve cycle times of less than a millisecond, or jitter values down to a microsecond. Networked automation systems using Ethernet require special measures to achieve comparable or better determinism.

Accepting variance in Ethernet transmission propagation times, one solution to guarantee deterministic system behaviour might be to make available a precise clock in all terminal devices synchronised with all other systems. Actions referenced to such a clock will decouple communication propagation times from the process. This applies particularly to linked systems that must start specific actions simultaneously. An example might be several robots that work together on one task such as the transport of heavy objects. Clearly this can't be done unless the robots are very precisely matched to each other.

The synchronisation process is carried out in two parts. First the time difference between master and slave is corrected - this is the offset measurement. During this offset correction, the master cyclically transmits a synchronisation (SYNC) message containing an estimated value for the exact time the message was transmitted to the related slave at regular intervals. (Left diagram)

In the second part, the delay measurement determines the delay or latency between slave and master. For this purpose the slave sends a so called delay request packet to the master and uses this to calculate precisely how long it takes to transmit the message over a particular network section.(Right diagram)

The new IEEE Standard Precision Time Protocol (PTP) IEEE1588 was originally developed by Agilent for distributed instrumentation and control tasks. The technique is based on the work of John Eidson, who as chairman of the standardisation committee, was also largely responsible for the approval of the standard in November 2002.

Using IEEE1588, it is possible to synchronise to less than a microsecond local clocks in sensors, actuators and other terminal devices using the same network that also transports process data. Existing time synch protocols do not achieve the required accuracy or convergence speed. For instance, NTP or SynUTC from the Technical University in Vienna have been generally shunned by manufacturers.

Like other protocols, PTP is also based on the best possible time matching between transmitted and received data. Unlike SNTP (simple network time protocol) the time when the data is transmitted does not need to be transmitted in the synchronisation packet itself but in a following packet. In this way measurement and transmission can be decoupled. The protocol was designed for small homogeneous and also heterogeneous local networks. The designers paid particular attention to low resource usage so that the protocol can also be used in lowend and low cost terminal devices. No special requirements are placed on memory or CPU performance, and only minimal network bandwidth is needed. The low administration effort for this protocol must also be emphasised. Thus a PTP domain automatically configures itself using the best master clock algorithm and is also fault-tolerant, as redundant masters are also supported.

The important characteristic of the protocol is of course its ability to synchronise the system to within less than a microsecond.

Protocol function

The most precise clock on the network synchronises all other users. A clock with only one network port is termed an ordinary clock. In principle any clock can perform both the master and slave function. The precision of a clock is categorised by the protocol and the best one chosen automatically to provide the timing for everything else.

The precision of the synchronisation depends heavily on the network and its components. For this reason the transition over less deterministic elements such as routers and switches, is also made possible by something called a boundary clock. The administration and configuration of network clocks forms part of the management protocol.

PTP is based on IP multicast communication and is not restricted to Ethernet, but can in principle be used on any bus system that supports multicasting. This type of comms offers the advantage of simplicity; IP address administration does not need to be implemented on the PTP nodes allowing scaling of the network. Every slave port synchronises the local clock for its node to the master clock by exchanging synchronisation messages with the master.

The actual synchronisation 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 (the default is every 2s). This sync message contains an estimated value for the exact time the message was transmitted.

For highly accurate synchronisation a mechanism determines the time of transmission and reception of PTP messages as precisely and as closely as possible to the hardware over the network. This is really a form of self-calibration. This precise time stamp allows temporal fluctuations in the protocol stack - protocol jitter - to be eliminated.

The master measures the exact time of transmission and the slaves measure the exact times of reception. The master then sends in a second message - the follow-up message - the exact time of transmission of the corresponding sync message to the slaves. On reception of first the sync message and the corresponding follow-up message, 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.

The second phase of the synchronisation process - the delay measurement - determines the delay or latency between slave and master. For this purpose the slave sends a so called 'delay request' packet to the master and during this process determines the exact time of transmission of the message. The master generates a time stamp on reception of the packet and sends the time of reception back to the slave in a 'delay response' packet. The slave calculates the delay time between slave and master using these timestamps.

The delay measurement is performed irregularly and at longer time intervals than the offset measurement. In this way the network and particularly the terminal devices are not too heavily loaded.

However, a symmetrical delay between master and slave is crucial for the delay measurement ie, the same value for both directions. Overall the synchronisation process eliminates temporal fluctuations in the PTP elements and the latency time between the master and slave.

Best master clock algorithm

The Precision Time Protocol determines master- slave relationships between communicating PTP synchronisation elements. Their determination is the task of the Best Master Clock (BMC) algorithm that compares the properties - accuracy, layer, drift, variance, - of the communicating clocks and from this information derives the states for all local ports.

The current properties of the master clock are cyclically transmitted to the slaves in synchronisation messages. The advantage here is that the states do not need to be negotiated but are calculated individually on each node. This ensures that the PTP network is automatically configured into a tree structure, starting from the best clock available, the grandmaster.

IEEE1588 also takes into account the need to override selection of clock states if necessary. This is performed using the management protocol such that clock parameters can be configured and read. This protocol makes it possible to exchange information with any other clock or all clocks at the same time. A special packet format using IP multicasts as for all other messages is defined for this management.

The boundary clock

A boundary clock is used on network infrastructure components (switches, routers, etc) to compensate for the jitter introduced by the component. Unlike an ordinary clock, a boundary clock has any number of ports. At each of these ports the component behaves like an ordinary clock for the related segment. Depending on the configuration, the local clock of the boundary clock is synchronised by a grandmaster over a PTP port set in the slave mode. The remaining ports on the BC act as masters and in turn synchronise other PTP synchronisation elements. A boundary clock has a maximum of one slave port and any number of master ports.

The boundary clock is recommended for routers, as these normally have a very large delay jitter. With most commonly available hardware-based routers, the delay jitter is hardly any greater than that of switches.

Significant delay jitter is produced in switches particularly during heavy load or overload conditions: values of up to 1ms are not unusual. Even if only a single long packet arrives in the switch before the synchronisation packet, jitter of up to 120µs may be caused. For this reason adding a boundary clock function to switches in a high precision network is recommended. This guarantees that synchronisation is only ever carried out over a physical connection where transmission jitter is negligible.

Precision of the local clocks

The precision of a quartz crystal is defined by the basic accuracy, typically 50ppm, ageing of 5ppm/year and a temperature dependency of 1ppm/°C. The standard requires a precision (drift) for the local clock of ±0.01% (±100ppm). Furthermore, it must be possible to adjust the local clock by ±0.02%. If only the drift of the local clock is considered and it is assumed that the clocks synchronise every 2s, then with 0.01%, there is an error of 200µs shortly before the next synchronisation, greater than the expected 100 to 200ns. It is thus imperative that each clock corrects its drift such that within a synchronisation interval it does not deviate from the master clock by more than 100ns.

After the correction of the local drift (basic accuracy and current ageing), the only parameter that could change significantly within a synchronisation interval is the temperature. For the stated synchronisation interval, a temperature change of 1°C within this interval results in a time error of 2µs. Thus a quartz crystal with very low temperature dependency must be used in high precision clocks.

A boundary clock is used on network infrastructure to retime jittery components or sections (switches, routers, etc). This increases significantly with loading or overload: values of up to a millisecond are not unusual. Even if only a single long packet arrives in the switch before the synchronisation packet, jitter of up to 120µs may be caused.

Implementation hardware

A key aspect for the implementation is a clear interface definition. The system comprises both hardware and software elements. In the hardware element the high precision time is generated while reading the time stamp on the synchronisation packets in both transmit and receive directions. The message detector analyses incoming and outgoing packets and detects synchronisation packets based on specific values in the packet. For these packets the exact time and the identification of the packet are saved. This can be realised initially using an FPGA, but will in future be integrated into the network components.

Software organisation

The protocol makes a major distinction between the time-critical element implemented in hardware and those parts of the protocol which don't need hard time conditions to work. This benefits the software which can be cleanly structured without ambiguous dependence on the hardware.

The protocol stack is implemented independently of the operating system and can thus be ported to any of them. The access to the hardware driver is provided in the adaptation layer. Tasks, timers, semaphores and socket interfaces must be adapted for each operating system. These functions are however only needed outside the protocol stack implementation.

Hardware drivers are then only required for network access, for reading the time stamp, and reading and setting the clock.

The protocol makes possible a synchronisation to within 100ns with hardware support. A pure software solution is, however, also conceivable for IEEE1588. Here, the internal system clock in the computer is used for the time of day delivers a time stamp via the network driver. A protocol implementation purely in software was investigated using Linux. The time stamp was acquired directly at the socket interface. The exercise demonstrated a precision of better than 100µs may be achieved with this implementation alone given appropriate process prioritisation. By further optimising the drivers it can be assumed that a precision of 10µs and better is achievable.

Conclusion

Segmentation or separation of interfering traffic will always be necessary since real-time behaviour is inconceivable if numerous sources of interfering traffic are bouncing around a system. Whether a time slot technique or time of day synchronisation or perhaps both are necessary depends on the application.

IEEE 1588 makes it possible for clocks in two systems to be very precisely synchronised. Maximum accuracy in the range of 100ns is only possible with hardware support, but even a pure software implementation on standard components provides a precision in the range 10-100µs. Currently several groups are working on real-time solutions for Ethernet eg, PNO, ODVA.

The EPSG is doing further technical development on real-time data transmission over Ethernet. The specification described here lays all the groundwork on relevant aspects. Thus segmentation is performed using a router, the already proven Ethernet Powerlink protocol is used for the time slot technique and the time synchronisation is performed in accordance with the standard IEEE1588. Even the application layer has been considered, CANopen profiles being used. The EPSG is co-operating closely with the established Ethernet associations such as IAONA, and so does not consider itself competition. The objective is to combine optimally established standards to form an overall solution.

Dirk S. Mohl is with Hirschmann Electronics, Automation and Network Solutions, Industrial Ethernet Development