Basics of real-time measurement, control, and communication using IEEE 1588: Part 2 -

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 researchlaboratoriesof the Hewlett-Packard Company, and continued at AgilentTechnologies after the split from Hewlett-Packard in 1999. Thetechnology was originally intended for use in instrumentation systemsusing network communication for control and data transport.

Early public presentations of this technology attracted considerableinterest from the industrial automation community, and by the fall of2000 it was clear that there was sufficient interest in the technologyto warrant a standardization effort. IEEE 1588 was developed under therules of the IEEE Standards Association. Formal work on the standardbegan in the spring of 2001, and concluded with the publication of thestandard in November 2002.

The IEEE sponsoring organization is the TC-9 Technical Committee onSensor Technology of the IEEE Instrumentation and Measurement Society.The standard has also been approved by the IEC as IEC61588.

Objectives of IEEE 1588
The standard committee's objectives are found in Clauses 1.1 and 1.2 ofthe standard, and form the context needed to appreciate why certainspecifications appear in the standard. These objectives are as follows:

1) The protocolmust enablereal-time clocks in the components of a distributed network measurementand control system to be synchronized to sub-microsecond accuracy. Areal-time clock in this context is a clock with a time scaleapproximately commensurate with the international second.

Clockssynchronized using IEEE 1588 will have the same epoch, or time scaleorigin, to sub-microsecond accuracy. It was not an objective of thestandard to synchronize these clocks to UTC, although this can easilybe done.

2) The protocolmustoperate over local area networks that support multicast communications.Ethernet, as realized in IEEE 802.3, is theobvious target networkfor many applications of this standard. However, the intent of thestandard is to also allow implementation on network technologies otherthan Ethernet.

3) The protocolis designedto operate on relatively localized network systems typically found intest and measurement or industrial automation environments at the benchor work cell level.

Such environments are usually contained within tensor, at most, a few hundred meters spatially, and with few networkcomponents, such as switches or routers, present. The protocol was notdesigned to operate over the internet or wide area networks.

4) The protocolmustaccommodate clocks with a variety of accuracy, resolution, andstability specifications. The target applications almost always involvea mixture of high- and low-accuracy devices. For example, it isinappropriate to require a thermocouple to support the same clockaccuracy as a high-speed digitizer.

5) The protocolis designedto be administration-free, at least in the default mode of operation.The motivation for this objective is understandable in the context oftest and measurement or industrial automation.

The protocol is muchmore attractive if simply attaching a device to the network results inthe automatic synchronization of its clock, without recourse toconfiguring address tables or other parameters. The multicastcommunication requirement on target networks is the enabler for thisfeature.

6) Finally, theprotocol isdesigned with minimal resource requirements both in terms of networkbandwidth, and computational and memory capability in the devices. Inboth test and measurement and industrial automation applications, therewill be many devices that require a synchronized clock but have costconstraints that must be respected.

Fundamental Operation of theProtocol
The precisiontime protocol (PTP) defined in IEEE 1588 is designed to synchronizeclocksin devices in a distributed system. PTP is a distributed protocol.Every device in the system that implements IEEE 1588 executes exactlythe same protocol.

There is no central authority governing any aspect of the protocol,nor is there any need to configure nodes prior to operation, assumingthat the default values of various parameters are instantiated in allIEEE 1588-enabled devices.

The entire operation of the protocol is implemented using onlyinformation obtainable from the exchange of PTP-defined messagesbetween these clocks. There are five operational features of theprotocol that together allow the synchronization of clocks in a system,and provide sufficient management These features are:

1) Establishing boundariesand communications for the system to be synchronized,
2) Establishing a master-slavesynchronization hierarchy,
3) Establishing orderly startupand reconfiguration of the system,
4) Providing the necessaryinformation to allow slave clocks to correctly synchronize to theirmaster, and
5) Providing system and clockmanagement capability when needed by an application.

Figure3.1. Typical system of network devices, boundary clocks, and ordinaryclocks

System Boundaries and Communications
PTP is designed to operate on packet-based networks that supportmulticast communications. There are five message types defined by PTP:

1) Sync
2) Delay Req
3) Follow Up
4) Delay Resp
5) management

Message types Sync and Delay Req are called “event messages”, sincethey are used as timing events by the PTP protocol. Message typesFollow Up, Delay Resp, and management are called “general messages”.

Follow Up and Delay Resp messages are used to convey timinginformation. Both event and general messages are to be communicatedusing a multicast model of communication to enable the self-configuration objective of the standard to be met.

Management messages are normally communicated using a multicastmodel, but in addition are permitted to use a point-to-point model. Figure 3.1 above illustrates atypical IEEE 1588 system topology that allows independentsynchronization systems to be maintained on the same communicationnetwork. Each system maintains its time scale independently of theothers. These independent synchronization systems are called”subdomains”.

Subdomains are implemented by defining a namespace, so that eachsubdomain is distinguished by a subdomain name. All PTP messagescontain the name of the applicable subdomain. All interactions,communications, and other features of IEEE 1588 occur within a singlesubdomain, and are logically independent of similar operations in othersubdomains.

There may be performance impairments that result from multiplesubdomains sharing a common communication fabric. These impairmentsresult from communication or processor loading on system components.

The boundary of a subdomain is determined by the underlyingcommunication fabric and how it responds to multicast messages. The PTPprotocol will synchronize all clocks in a subdomain that receive andprocess PTP event and general messages.

Therefore, to limit the extent of an IEEE 1588 subdomain, it isnecessary to correctly limit the propagation of multicast messages inthe underlying communication fabric. This may be done physically byisolating the subdomain, or logically by proper configuration ofrouters, switches, and similar network equipment.

A system such as the one shown in Figure3.1 above typically contains several end or terminal devices,and several network devices. An end device is a device with only asingle network connection. End devices containing a PTP clock aretermed “ordinary clocks” in the standard.

Depending on the network technology, a network may also containnonterminal devices such as routers, switches, and repeaters. Thesedevices are called network devices, and may or may not containspecialized IEEE 1588 functionality.

These devices serve to pass a network message received on one portto one, or more of the remaining ports of the device. Routers andswitches make these forwarding decisions based on addressinginformation contained in protocol headers of the messages.

Repeaters simply forward the message to the other ports on thedevice. The standard refers to any end or network device that can issueor receive PTP messages as a node. Strictly speaking, any end ornetwork device performs this function, not only devices that supportIEEE 1588.

Since devices that do not implement the protocol have no directeffect on the protocol, no confusion arises. However, such non IEEE1588 devices may adversely influence the performance of the protocol.

Network devices containing specialized IEEE 1588 functionality arecalled boundary clocks. The PTP protocol uses boundary clocks tologically segment the physical network to create a master-slavesynchronization hierarchy of clocks.

In the general case, a node may be connected to a boundary clock ora network device. The network, depicted by the cloud in Figure 3.1, maycontain a mixture of boundary clocks and network devices, depending onthe complexity of the application and the network technology.

Note that not all potential network technologies have theequivalent of routers and switches. A network in such a technologywould appear to PTP as a set of ordinary clocks communicating directlywith each other in a multicast manner. An example of such a networkwould be a set of nodes that communicate using thecontroller areanetwork (CAN).

To read Part 1, go to “Thevarieties of system temporal specifications.”
Next in Part 3: IEEE 1588'smaster-slave synchronization hierarchy

Used with permission of its publisher, Springer Science andBusiness Media, this series of articles is based on material from “Measurement,Control and Communication Using IEEE 1588,” by John C. Eidson andcan be purchased on line.

John C. Eidson, Ph.D., received a B.S. and an M.S. from MichiganState University and a Ph.D. from Stanford University, all inelectrical engineering. He held a postdoctoral position at Stanford fortwo years, spent six years with the Central Research Laboratory ofVarian Associates, and joined the Central Research Laboratories ofHewlett-Packard in 1972. When HP split in 1999, he transferred to theCentral Research Laboratory of AgilentTechnologies. Dr. Eidson was heavily involved in IEEE 1451.2 andIEEE 1451.1 and is the chairperson of the IEEE 1588 standards committeeand a life fellow of the IEEE.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.