Do we have time to fix the time?

Author: Galina Antonova, ABB Power Grids, Canada

what incorrect time can lead to and what can we do to receive time reliably

Power systems’ event analysis and reporting requires that disturbance fault recorders (DFRs) and sequence of events (SOE) data be captured with correct date and time information. NERC PRC-002-2 Requirement 10 stipulates “synchronized device clock accuracy within ± 2 milliseconds of UTC.” Many of deployed Remedial Action Schemes (RAS) use synchrophasor measurements with UTC timestamps accurate to microseconds.
Protection schemes, such as line current differential and those using IEC 61850-9-2 sampled values require microseconds accuracy for samples synchronization. To receive time reliably proper design, operation and maintenance of time synchronization are required.
IEEE 2030.101-2018 standard provides detailed guidance on design, installation and monitoring of time synchronization in power utility substations. It covers time sources such as Global Positioning System (GPS) and time distribution technologies, such as Inter-Range Instrumentation Group-B (IRIG-B), Network Time Protocol (NTP), Simple Network Time Protocol (SNTP), and Precision Time Protocol (PTP) profiles for power system applications: IEEE C37.238-2011, IEC/IEEE 61850-9-3:2016 and IEEE C37.238-2017.

A basic time synchronization system from IEEE 2030.101 is shown on Figure 2.
Possible time synchronization sources for intelligent electronic devices (IEDs), such as phasor measurement units (PMUs), DFRs, protective relays and merging units (MUs) are shown on Figure 3.
IED’s time synchronization interfaces commonly include GPS and IRIG-B. IRIG-B and some GPS interfaces can be replaced by using Ethernet-based time distribution. This simplifies time synchronization design, eliminates IRIG-B and GPS cabling and antenna, thus reduces cost and maintenance.

What can happen and why time is incorrect?
Fine time synchronization implies that year and date information is correct. Absence of correct year, date and time challenges event analysis and could cause NERC PRC-002-2 compliance issues. Also, enormous time and effort will be spent on sorting time mis-aligned event records within a utility, and even more so across multiple utilities in a region. It was noted that records’ time alignment takes the most time when analyzing events. 
IEDs installed today in the field mostly use IRIG-B synchronization. The main reason for not receiving correct year and date information is simply not using IEEE 1344 extensions. While the original IRIG-B format allocated control bits, it did not specify their functions. Transmission of the year, local time offset, leap seconds, daylight-saving and time quality in IRIG-B control bits were later specified by IEEE 1344 and IEEE C37.118 standards.
If IEEE 1344 extensions are not provided or interpreted properly, year and date at the IED will not be correct. It was found while working in the field that it is very easy to think that IEEE 1344 extensions were used when they are not. Often the year at the IEDs can simply be set by the factory to the year of manufacturing, that would be correct initially but will not change at the yearend. A full verification of clocks issuing IEEE 1344 extensions and IEDs receiving and interpreting them correctly is necessary. The simplest way to verify this is to set the year at the IED to future or past and note if it will change to the correct year in a second.
The year information is also needed to get a correct date, as IRIG-B format provides day of the year count (001 to 366). With IEEE 1344 extensions disabled, one could change the year (e.g. to a leap year) and observe a date change. 

Time difference in hours could be caused by incorrect interpretation of local time offset transmitted in IEEE 1344 extensions. There was a change in how local time offset is sent and interpreted between IEEE 1344-1995 and IEEE C37.118-2005 standards. Further, IEEE C37.118-2005 standard includes the same specification as IEEE 1344 standard, except it changes the requirement from adding to subtracting the offset to make it consistent with common practice. However, there was a wording inconsistency in the IEEE C37.118-2005 standard that caused confusion; it was clarified in the IEEE C37.118-2011 version. This confusion led to time difference of 2 times the local offset hours in some cases.

Time difference in an hour could occur if daylight-saving information was not interpreted correctly. As the use of daylight-saving time is changing for some states and countries, the most current information needs to be used. 

Time difference in seconds can be caused by not interpreting current leap seconds correctly. As the UTC timescale with standardized second duration does not precisely reflect the actual Earth rotation, leap seconds were introduced by the International Earth Rotation and Reference System Service (IERS) to align the UTC timescale with the Earth movement. Leap seconds can occur on the last day of June and the last day of December at midnight UTC. There are currently 37 leap seconds, all of which were additions. Leap second subtraction is also possible and could be more challenging. As it has not yet occurred, it is unknown how existing clocks will handle it.

A single second time difference can occur if the most recent leap second was not properly announced and acted upon.
During an incorrectly processed leap second transition, data timestamps differ from the correct value by one second, and measurements or analog data samples taken at the same time will appear as taken one second apart. This can lead to serious consequences if time synchronized data is used for RAS, automatic controls and other critical system applications, leading to compromised reliability and system stability.
In one example an incorrect leap second transition resulted in halting operation of a utility server and data concentrator after it discarded 5 seconds of received data due to incorrect timestamps.
Another example occurred during line protection end-to-end testing. As a test set at one line terminal failed to register a leap second that occurred a month earlier, fault records were not aligned, and significantly longer time and much more effort were invested into testing than would otherwise be needed.

Relion advanced protection & control.
Protecting your electrical assets? today and tomorrow