Basics of real-time measurement, control, and communication using IEEE 1588: Part 2
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 standardization 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 organization 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.
Objectives of IEEE 1588
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 synchronized to sub-microsecond accuracy. A
real-time clock in this context is a clock with a time scale
approximately commensurate with the international second.
Clocks synchronized 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 synchronize these clocks to UTC, although this can easily be done.
2) The protocol must operate over local area networks that support multicast communications. Ethernet, as realized 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 localized 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 digitizer.
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 synchronization 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 synchronized clock but have cost constraints that must be respected.
Loading comments... Write a comment