The File - Sep 1, 2008 - (Page 4)

In Focus | Board-level Test Get the low down on IEEE 1588 clock synchronisation By John Eidson Agilent Technologies IEEE 1588 is based on work begun around 1990 in the central research laboratories of the Hewlett-Packard Company, and continued at Agilent Technologies after the split from Hewlett-Packard in 1999. The technology was originally intended for use in instrumentation systems using network communication for control and data transport. Early public presentations of this technology attracted considerable interest from the industrial automation community, and by the fall of 2000 it was clear that there was sufficient interest in the technology to warrant a standardisation effort. IEEE 1588 was developed under the rules of the IEEE Standards Association. Formal work on the standard began in the spring of 2001, and concluded with the publication of the standard in November 2002. The IEEE sponsoring organisation is the TC-9 Technical Committee on Sensor Technology of the IEEE Instrumentation and Measurement Society. The standard has also been approved by the IEC as IEC 61588. The standard committee’s objectives are found in Clauses 1.1 and 1.2 of the standard, and form the context needed to appreciate why certain specifications appear in the standard. These objectives are as follows: 1. The protocol must enable real-time clocks in the components of a distributed network measurement and control system to be synchronised to sub-microsecond accuracy. A real-time clock in this context is one with a time scale approximately commensurate with the international second. Clocks synchronised using IEEE 1588 will have the same epoch, or time scale origin, to sub-microsecond accuracy. It was not an objective of the standard to synchronise these clocks to UTC, although this can easily be done. 2. The protocol must operate over LANs that support multicast communications. Ethernet, as realised in IEEE 802.3, is the obvious target network for many applications of this standard. However, the intent of the standard is to also allow implementation on network technologies other than Ethernet. 3. The protocol is designed to operate on relatively localised network systems typically found in test and measurement or industrial automation environments at the bench or work-cell level. Such environments are usually contained within tens or, at most, a few hundred meters spatially, and with few network components such as switches or routers present. The protocol was not designed to operate over the Internet or wide area networks. 4. The protocol must accommodate clocks with a variety of accuracy, resolution, and stability specifications. The target applications almost always involve a mixture of high- and low-accuracy devices. For example, it is inappropriate to require a thermocouple to support the same clock accuracy as a high-speed digitiser. 5 The protocol is designed to be administration-free, at least in the default mode of operation. The motivation for this objective is understandable in the context of test and measurement or industrial automation. The protocol is much more attractive if simply attaching a device to the network results in the automatic synchronisation of its clock, without recourse to configuring address tables or other parameters. The multicast communication requirement on target networks is the enabler for this feature. 6. Finally, the protocol is designed with minimal resource requirements both in terms of network bandwidth, and computational and memory capability in the devices. In both test and measurement and industrial automation applications, there will be many devices that require a synchronised clock but have cost constraints that must be respected. Protocol operation The precision time protocol (PTP) defined in IEEE 1588 is designed to synchronise clocks in devices in a distributed system. PTP is a distributed protocol. Every device in the system that implements IEEE 1588 executes exactly the same protocol. There is no central authority governing any aspect of the protocol, nor is there any need to configure nodes prior to operation, assuming that the default values of various parameters are instantiated in all IEEE 1588enabled devices. The entire operation of the protocol is implemented using only information obtainable from the exchange of PTPdefined messages between these clocks. There are five operational features of the protocol that together allow the synchronisation of clocks in a system, and provide sufficient management. These features include: • Establishing boundaries and communications for the system to be synchronised; • Establishing a master-slave synchronisation hierarchy; continued on page 0 Typical system of network devices, boundary clocks and ordinary clocks. 4 EE Times-India | September 1-15, 2008 | www.eetindia.com http://www.eetindia.co.in/SEARCH/SUMMARY/technical-articles/LAN.HTM?ClickFromNewsletter_080901 http://www.eetindia.co.in/SEARCH/SUMMARY/technical-articles/LAN.HTM?ClickFromNewsletter_080816 http://www.eetindia.co.in/SEARCH/SUMMARY/technical-articles/Ethernet.HTM?ClickFromNewsletter_080901 http://www.eetindia.com/STATIC/REDIRECT/Newsletter_080901_EETI02.htm?ClickFromNewsletter_080901

Table of Contents for the Digital Edition of The File - Sep 1, 2008

EETimes India - September 1-15, 2008
Contents
National Semiconductor
Get the Low Down on IEEE 1588 Clock Synchronisation
Tech Insights
DigiKey
Combine Techniques to Reduce ICT Cost, Complexity
Microchip Technology
National Instruments
SME, Educational Programmers Show How NI�Cares
Texas Instruments

The File - Sep 1, 2008