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

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


Editor's Note: This is the first in an on-going series about the useof IEEE 1588, and the explicit representation of time in the design andoperation of synchronized time-stamped measurement, control, and communication systems.

IEEE 1588 is a relatively new real-time networking synchronization protocol that was originally designed for local systems in instrumentation and industrial applications requiring very high accuracies beyond those attainable using the current network time protocols (NTP), and now finding wider use in communications and wide area networking.

These systems share a common feature in that they interact with devices or processes that themselves operate based on real-world time. Such systems are often termed “hard real-time systems” because their actions must meet time constraints imposed by the application space, rather than by the operation of the measurement or control devices.

Examples of such hard real-time systems abound. In the measurement world, complex test systems composed of many electronic instruments operating in concert are used to verify the performance of even more complex electronic or electromechanical devices such as radar systems, electronic engine controls, power generators, and heart pacemakers.

In the field of control, combinations of computers, controllers, sensors, and actuators collaborate to regulate printing presses, oil refineries, packaging machines, traffic lights, and home heating equipment. Communications systems operate to pass information from source to destination and are governed by the laws of physics, the operation of the communication protocols, and the vagaries of users, all of which result in unpredictable traffic flows.

The use of time in measurement and control is actually very familiar, as our everyday life seems to be governed by the clock. Alarm clocks have been with us for ages. Does there exist a businessman that can function without the ever-present meeting reminder pop-ups on the computer screen? Lawns are watered, coffee is brewed, and favorite television programs are recorded; all based on some sort of mechanical or electronic clock.

In programming these devices, the time at which something is to happen is entered, as well as the time at which the activity is to cease, or in some cases, the duration of the activity. Never is there a list of activities executed based on the speed at which the device operates.

Table1.1. Summary of hard real-time design patterns

The varieties of system temporal specifications
It may come as a surprise to those not familiar with the field that in programming test and measurement and control systems, it is usually difficult or impossible to specify actions based on time. It is true that some systems provide crude schedulers for starting a task based on time. Others are based on timers that may used to provide notification for a fixed time after the timer is set.

However, there are few examples in which detailed specifications of the system behavior as a function of time can he expressed, and even fewer mechanisms for enforcing such behavior, or even recognizing when the specifications have not been met. The reason is that most, modern test, measurement, control, and communication systems are operated by computers based on the latest microprocessors, operating systems, and programming languages.

For example, microprocessors provide little support for real-time specifications. Typically, support is limited to timed interrupts that can be used to form a clock or to implement timers. These interrupts invariably operate based on the oscillator used to drive the local processor, and therefore will be asynchronous to similar devices in other microprocessors in the system. To make matters worse microprocessors implement numerous optimizations that make their operation non-deterministic in time. Examples are memory cache, speculative execution; and interrupt priority.

Given the available support in hardware, even the so-called real-time, operating systems are best-effort systems with only statistical guarantees of temporal behavior. System clocks are typically implemented at the operating system level based on timed interrupts from the supporting hardware.

In most cases, the granularity of these clocks is not sufficient for applications of interest. There are synchronization protocols that enable clocks in one system to agree with other clocks in the system at accuracies useful in business and commerce. The common languages used in programming these systems do not support any form of temporal semantics. These languages are designed for data processing for business and commerce and mathematical manipulations for the scientific community.

There are simply no mechanisms in these languages for specifying actual simultaneity, parallel execution, temporal deadlines, or other time-related concepts. If time must be referenced, then this is always as an operating system call outside of the programming language.

State of the art in Implementing real-time systems
To overcome the lack of support for time-based specification in modern computing environments, a number of techniques have evolved and form the basis for the practice usually referred to as embedded systems programming. “These techniques include:

1) Ignoring high-level languages and operating systems. Program the microprocessors in a low-level or assembly language where more explicit control of the underlying hardware is possible. System-wide timing is often accomplished by means of special purpose hardware support accessible to the control microprocessors, such as the IRIG-B and GPS protocols.

2) Using the time support available in the general computing environment. In general, this tactic requires trial-and-error adjustment of the code to produce the desired temporal behavior. This technique is fragile in that the results are dependent on the speed of execution of code in the microprocessor, which is subject to all manner of abuse from the underlying hardware. If communication between computers or devices is required, then additional time variations will be introduced, making it even harder to hold to tight temporal specifications.

3) Generating a system-wide ordering mechanism for enforcing temporal relationships. These systems are called time- slotted systems. The time-slots may, or may not, be tied to real-world time.

Three real-time design patterns
What has emerged from these options are three distinct design patternsfor enforcing real-time behavior on the components of a distributedsystem.

The first of these design patterns is the message-based system. In thispattern, coordination among components is achieved by message exchange.These messages contain no explicit reference to time, and the usualsemantics is that any implicit time (forexample, the time at which acommand is to be executed ) is based on the time of messagereceipt.

In effect, the message contains two components: the payloadexplicitly representing data or a command, and the relevant timeimplicitly represented by the time of receipt. This is the dominantpattern in general computing. Examples are remote procedure calls,publish-subscribe mechanisms and blackboard systems.

Message-based systems are used almost exclusively in currentmeasurement systems, and in many control systems as well. While amessage-based paradigm works very well for conveying state, it is apoor mechanism for specifying time, due to the fluctuations in thelatencies associated with the network transport layer and operatingsystems. Commercial systems typically have a. global time scaleestablished by the NTP protocol. However, time is invariably used asdata (for example, in timestamping afinancial transaction ) and rarelyfor control.

The second design pattern is the time-slotted system . In thispattern, system-wide operations are broken into a succession oftime-slots. Typically, these time-slots are defined by the time-slotsof a time division multiplexed network transport protocol.

The time-slots may, or may not be uniform, and may or may notbebased on a. global time scale. Instead of using a global time scale thetime-slots may be state-based or using a token passingprotocol, or they may be managed by a central authority- thatnotifiesall participating devices when to move to the next slot. The slots aretypically numbered based either on a time scale or on sequence numbers.This allows ordering of events within the granularity of thetime-slots.<>Slots may be assigned to functions, but usually are assigned todevices.

This design pattern is heavily used in industrial automation.Examples are the SERCOSand Profibusprotocols, and the TTPprotocol of Kopetz. Provided the functions of each participatingdevice are constrainedto complete execution within a time-slot, this technique is very goodat enforcing real-time performance. The time granularity is set by theduration and consistency of the time-slots and is very well matched tosystems with periodic behavior.<>

The final pattern is the time-basedsystem . In this pattern asystem-wide time scale is established, and time-critical system actionsare based on this time scale, rather than on message receipt times orthe boundary of a time-slot. Global time scales are typically providedby local clocksparticipating in a synchronization protocol. Messages passed betweendevices can contain a. timestamp defining the occurrence time of somemeaningful event, allowing the recipient to base action on the receivedtimestamp and the global time scale.

This pattern is relatively rare due to the lack of sufficientlyaccurate system-wide time scales, and the lack of programming toolsupport. However, there are several proprietary time-based systems thathave been used quite successfully in the industrial automationindustry.

A time-based system should be a good match for problems withirregular or episodic time behavior, or systems where a finite numberof events occur within a time too short to permit disambiguation usingtime-slots. These problems occur quite commonly in the test andmeasurement field, and in certain applications in industrialautomation. The characteristics of each of these design patterns aresummarized in Table 1.1 earlier .

IEEE 1588, which will be discussed in detail in later parts in thisseries, provides a way to easily synchronize clocks in a distributedsystem, thereby establishing a system-wide accurate and precise timescale. It is logical to expect this to lead to increased usage of thetime-based design pattern and to more precisely defined time-slottedsystems.

Since it is a rare application that perfectly matches any designparadigm, it is likely that all three of the design patterns willcontinue to be used, but in different proportions and in new andinteresting combinations.

Part 2: An overview of theIEEE 1588 Clock Synchronization standard
Part 3 : IEEE 1588's master-slave hierarchy
Part 4 : Achieving sub-microsecond synchronization
Part 5 : Applying 1588 to telecommunications and networking
Part 6: The future of IEEE 1588

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 MichiganStateUniversity and a Ph.D. from Stanford University, all in electricalengineering.He held a postdoctoral position at Stanford for two years, spent sixyearswith the Central Research Laboratory of Varian Associates, and joinedthe Central Research Laboratories of Hewlett-Packard in 1972. When HPsplit in 1999, he transferred to the Central Research Laboratory of Agilent Technologies. Dr. Eidson washeavily involved in IEEE 1451.2 and IEEE 1451.1 and is the chairpersonof the IEEE 1588 standards committee and a life fellow of the IEEE.

Leave a Reply

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