PTP reference architecture, or how to build a PTP synchronization element
As previously mentioned, what is so special about the architecture is the separation of the time-critical part which is implemented in hardware and the protocol itself and is decoupled from hard real-time conditions - the software part. Thus the protocol is running in a low priority process and/or on a processor with low performance requirements.
The hardware unit consists of a highly precise real-time clock and a time stamp unit (TSU) to generate the time stamp. The software part implements the actual IEEE1588 protocol with the binding to the real-time clock and the HW time stamp unit. Figure 3 illustrates a co-operating of the hard and software component of a IEEE1588 synchronization element.
The intention of the presented architecture supports an almost OS independent modeling of the software component.
In order to reach this, we introduced three layers with different abstraction level. The Protocol Layer implements the operating system independent Precision Time Protocol. The OS Abstraction Layer forms the interface between PTP and the selected operating system. The functions made available by the operating system - tasks/processes, semaphores, timers, sockets, etc. - are merged over the OS Layer. The following figure shows the interaction of the individual layers.
The highest layer implements PTP for the synchronization of clocks in a network and can be used on different communication elements (PC, switch, router, etc..). Here is the actual intelligence located for synchronizing the individual communication elements. Within the Protocol Layer we used only ANSI/ISO C conformal functions, thus you can easily transfer the protocol without deep interference into the functionality on different platforms. The protocol dispatchers ensures the atomic execution of functions during an individual process. Communication between the protocol and the OS Abstraction Layer has been realized by a queue and three well defined interfaces.
The middle layer encases operating system dependent functions, which one must adapt, if necessary.
The Timestamp Interface provides the Precision Time Protocol with the seized time stamps of the Sync and Delay-Request messages. However depending upon the stage of development (precision requirement) either a HW unit (TSU) or the software generates the time stamps. The best way to generate "software time stamps” is in the operating system dependent NIC drivers (RX- ISR, sends process) - as near as possible at the transportation medium.
Over the Clock Interface you read and modify the local clock. You have also to adapt these functions depending upon platform. Realizations, which do not have a hard real-time clock, use the system clock of the operating system or optimized solutions as for example the nano-kernel under UNIX derivatives. Apart from setting the local clock, this interface contains the control algorithms which are responsible for the quality of time synchronization [accuracy, stability, transient behavior, etc.].
The Port Interface is used to dispatch and/or receive PTP messages. The IEEE1588 telegrams use excluding UDP/IP multicast packets and thus make it possible to send and receive them over the socket interface of the IP protocol stack. One may neglect temporal requirements, since the time stamps are generated directly at transport medium. The inputs to the protocol (configuration, diagnosis, PTP packets) run over the PTP API.
This modular software platform made it possible for us to build implementations of this protocol for Linux, Windows and VxWorks. The implementations in Windows and Linux use time stamping in software. But even a pure software implementation reaches a precision of about 100 µs, and it seems to be possible to increase this up to a precision of better than 10 µs.