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.