Time synchronization in industrial automation

[FONT=&quot]In the sensitive field like automation demands a lot of requirements and time synchronization is one of them.[/FONT]

[FONT=&quot]In process automation,there will be a lot of controllers of different brands,protection relays,VFDs,Energy meters,UPS,HMI/SCADA and other Electronic devices.[/FONT]

[FONT=&quot]Process Events occur for each and every second and milli seconds.[/FONT]

[FONT=&quot]Each device has date and time for stamping the events,time can be varied from seconds to minutes and can create confusion to identify the problem correctly in the whole process.[/FONT]

[FONT=&quot]what techniques and methods are usually followed for time synchronization?[/FONT]

Most PLC/DCS brands have their own proprietary sync methods. Some have started to allow more open standards like NTP, as well.

At the application level, it may help to add a timestamp to the event only in one central location. However, I'm sure this only makes sense in a minority of situations.

Usama_maqsod said:

...what techniques and methods are usually followed for time synchronization?

Click to expand...

With so many brands and methods of intercommunication out there, it may be quite hard to say which methods of time synchronization are the most usual. However, by today's standards, CIP (Common Industrial Protocol) is one of the most commonly used standards of communications, if not the most. EtherNet/IP fast becoming the goto CIP standard for small to large automation devices and equipment.

For EtherNet/IP, CIP Sync is used to synchronize time between interconnected devices in potentially less than 100 nanoseconds and can even achieve picosecond resolution within some applications. But sub one microsecond would be typical. CIP Sync uses the IEEE 1588-2008 PTP (Precision Time Protocol) to achieve this, along with hardware level timestamping. PTP is superior to NTP (Network Time Protocol), being typically in the milliseconds range, but NTP is often used for non critical timestamping where millisecond resolution is sufficient.

The Electric Power Industry would be one example sector which often requires the sub one microsecond monitoring capabilities of the latest IEEE 1588 PTP v2 (2008) standard.

Not to focus in on one brand, as the PTP standard is utilized by many manufacturers, but the following document, from Rockwell Automation, does give a very good explanation, within the Overview section, of what it's all about...

Integrated Architecture and CIP Sync Configuration

I believe this method of time synchronization will become a widely used standard as more and more manufacturers lean towards EtherNet/IP for their device communications.

Regards,
George

More and more manufacturers are embracing PTP, precision time protocol, IEEE-1588. I know that both Beckoff and Allen-Bradley have products that use this standard.

This standard continually syncs from a grand master clock, which itself is usually synced to a time standard or GPS. The protocol compensates for propagation delay.

If you are using Ethernet to connect your devices this is by far the best approach. We use IEEE 1588 on all of our controllers on our LAN and their accuracy is generally in the sub millisecond range.

Geospark and Timbert are correct that PTP is more far more precise than NTP, by multiple orders of magnitude. For some applications, like motion control, this can be vital, to guarantee minimum jitter. From what I've read, it was literally developed for systems where NTP wasn't good enough, with strong consideration that Automation/Control/Measurement were jumping to Ethernet.

However, as far as I know, PTP does have two downsides:

• It requires support in your network architecture (switches), not just the devices you are syncing. To get the precise time sync, the protocol measures the latency in every device and cable. This isn't trivial, and requires planning when ordering equipment and often configuration when installing.
• I haven't seen much support for it on the PC side, for SCADA and the like. I'm sure it's there if you look hard enough though.

NTP on the other hand is widely supported on computers (built into Windows). It also doesn't care about the network that it travels through, except that if the traffic is delayed too long then that could affect the result slightly. No special switches or network configuration required.

They also take slightly different approaches to accuracy vs precision. NTP aims for accuracy. NTP allows a device to get times from multiple servers, and use voting to determine if one of the servers is wrong. This allows for a time that is more likely to be "correct". There is an expectation that the servers are themselves synced to GPS sattelites or an atomic clock somewhere. PTP literally has Precision in the name. Itis Master/Slave, and its goal is for every device to have exactly the same time, regardless of whether that matches reality. It is convenient for the PTP master to be "correct" and linked to GPS/atomic, but that doesn't actually matter in many applications.

Ultimately, it really depends what your requirement is. Are you trying to precisely time the messages to two of your drives? PTP (or something like it) is definitely the way to go. Are you trying to sync up a network of mostly PCs? NTP probably makes sense.

I love this forum, learn something new every day.

I think it depends greatly on the granularity you need and if you scada/alarm logging supports that kind of precision too. This is something I haven't dealt much with but my gut feeling is that the alarm management process inside the SCADA servers isn't running that fast to allow 10's of miliseconds.

In my experience, the least troublesome way of getting time sync is through a GPS receiver. This will usually depend on the manufacturers of the individual systems, but having a receiver for each allows less headache in interconnecting systems.

We use the RSLogix5000 Clock Update tool for resetting PLC clocks, and we run it on our Rockwell Transaction Manager server.

Mostly the clock is used for time-based triggers (7am on a Monday morning) to trigger off weekly reports (based on data from a number of sources) and reset production counters, and you have to use something as your base clock, although PLC and PC clocks vary quite widely over time.

For our purposes, it isn't as critical to sync the PLCs and instruments as it is to sync the HMI servers and workstations... that way all timestamps are aligned. We use a GPS receiver from Symmetricom on our network, and a nice piece of code called NetTime http://www.timesynctool.com/ to sync all the machines. We set our network time to run on UTC, so avoiding the DST headaches.