Timekeeping protocols for control systems: What time is it?
How many different clocks are connected to your control system, and what time do they all say?
Do we care what time it is?
Do you have a control system that has buttons and lights as its only interaction with the operators? Is there no real-time trending, no alarm historian, and no regulatory reporting? There are certainly control systems that have no need of accurate clocks, but they are few and far between. Let us assume you do not have one of those systems, and you need to keep time.
It is always good to have accurate time, but it is more important to have synchronized time. If every clock in the building is 10 minutes slow, then you can still tell which of two events happened first. If your DCS has one time, your database server has another, a PLC has a third, and they all drift independently, you have a problem. Sequence of Events (SOE) operations, time stamped I/O and alarming, and synchronized motion are all applications that mandate synchronized clocks.
Selecting a time source.
If you want nearly perfect time, you can install a GPS or GLONASS receiver that can provide better than 1ms accuracy. An IRIG-B receiver is almost as good. Internet time requests to the National Institute of Standards in Colorado can be fairly accurate, depending on your internet connection. At the other end of the spectrum is a free running oscillator clock that was set by hand several years ago. Whatever your time source, the key to a keeping time within an integrated system is to make sure that the chosen time source propagates throughout the system.
Propagating the time.
Many automations systems have identified the need for time synchronization and have implemented their own systems. The problems occur when you need to synchronize different equipment from different vendors that do not talk to one another. Standards-based time is the way to go if you want an enterprise wide solution. If a particular manufacturer or platform does not support a standard for its own synchronization, it will almost certainly support a standards-based boundary device that connects the enterprise to a proprietary system.
Network Time Protocol (NTP) is the most common standard. If you have Windows servers, you are already synchronizing time using NTP, as this is the default method for Windows domains. NTP works over Ethernet networks, and the traffic requires no special handling by network equipment, so all switches and routers support it. Unfortunately, it is not very accurate. NTP has no way to detect latency in the network it propagates through. Accuracy of synchronization between two points can be up to 100 milliseconds, and deviations within a large network can exceed 2 seconds.
The Inter-Range Instrumentation Group (IRIG) standards define a family of timekeeping protocols that are defined for various distances and transmission media. Synchronization within a facility using IRIG generally requires installing a special time-keeping network dedicated to this purpose, which drives costs up. There are noticeably fewer devices supporting IRIG than NTP. Accuracy is very good, with synchronization between two points under 10 microseconds and overall system variation should be below 10 milliseconds. IRIG is generally the best solution it you need high accuracy over very long distances.
Precision Time Protocol (PTP) is an implementation of the IEEE-1588 standard, and is the newcomer to the scene. Where NTP and IRIG have been in use for more than 30 years, PTP was first introduced in 2003 and updated in 2008. PTP is carried over Ethernet networks, but full functionality is only guaranteed when every switch or router is designed to support it. If there are devices in the network that do not support PTP, the specific implementations of the devices on either side of the divide will determine if the signals can bridge the gap. In a new installation, the price differential is low, but replacing switches specifically to implement time synchronization can be quite expensive. Custom designed switch hardware allows PTP to test latency between every point in the network. Latency knowledge allows for very great accuracy. Synchronization between two points is usually under 100 nanoseconds, and overall system variation is near 100 microseconds.
Decide before you implement.
Like all major system architecture decisions, the selection of a time synchronization solution is best made before a system is designed and installed. Selection a time master device or method can be deferred, but choices regarding the physical wiring and network hardware are best made before the wire is pulled.
If your physical plant is already present, try to work your future timekeeping plan into your upgrade cycle. If you are upgrading switches on a rolling schedule, consider using PTP-capable versions as the replacements.
Some facilities have islands of synchronization based around proprietary vendor systems. Replacing the entire infrastructure may be impractical, but you can frequently install standards-based bridges between the islands. This approach can bring synchronized clocks to the enterprise without the cost of a complete overhaul.
This post was written by Rob Henderson. Rob is a principal engineer at MAVERICK Technologies, a leading automation solutions provider offering industrial automation, strategic manufacturing, and enterprise integration services for the process industries. MAVERICK delivers expertise and consulting in a wide variety of areas including industrial automation controls, distributed control systems, manufacturing execution systems, operational strategy, business process optimization and more.
MAVERICK Technologies is a CSIA member as of 3/20/2015