October 09, 2012
In last week's blog, "Designing a time synchronization source," we discussed considerations for the design of a time synchronization source for industrial substations. Today I'd like to alert consulting engineers to the vagaries of assessing vendors' devices that accept time inputs. And next week we'll look at concluding this topic with promising developments in the standards arena.
Among protection devices, sensors, and controls, the market offers a wide range of devices that accept time inputs. And vendors will use terms such as "1 millisecond resolution," "1 millisecond accuracy," and so forth, to characterize them.
The engineer must drill down to assess the precise meaning of those labels and press the vendor for clarity, because between the event and time-stamping in the device's sequential event recorder, a number of opportunities arise for introducing errors, potentially leading to faulty analysis of an event.
Though most vendors ensure that all of the inputs or channels into their particular intelligent electronic device (IED) will be accurate relative to each other, absolute accuracy of events and channels between multiple IEDs is another matter. Few vendors provide specifications that reflect absolute accuracy of the events record that each of their IEDs produces.
Let's look at why this issue is critical to the accurate analysis of events and how this challenge can be met.
One potential error occurs when an IED receives an accurate time signal from a time distribution system. The IED may introduce errors in setting its internal clock due to a variety of process and design factors in the IED. It's not uncommon for five IEDs connected to the same time source to have their clocks off by several milliseconds.
In distribution systems, where 1 millisecond accuracy is typically not required, slight differences in time stamping between IEDs is not critical.
The requirements for 1 millisecond resolution would more likely be found at industrial interconnections to the utility with transmission-voltage levels. This would also be true in the case of a very large facility with multiple connections to the utility-a large petrochemical refinery, a university campus, a military base, or a facility of that nature.
At the microsecond level required for synchrophasors, the problem becomes hugely significant because a few microseconds one way or the other will result in a completely different synchrophasor reading. In the transmission example, a faulty analysis could result. In the case of synchrophasors, such an error affects "situational awareness," what's happening in real time, and that could lead to faulty counter-measures.
The microsecond level of accuracy is going to be needed at facilities injecting large amounts of power into the utility's grid, which might well mean distributed resources like wind farms or solar farms, co-generators of a significant size-in the tens or hundreds of megawatts of output. Below that level, you still can have a problem, but the utility's need for situational awareness of 2 to 3 MW is far less than, say, 200 MW.
Often it becomes critical to correlate events that have taken place across a wide geographical distance in different substations. So between two transmission substations, for example, one owned by the utility and one owned by the industrial customer, there's a need to understand what event has taken place and in what sequence it unfolded. If the time synchronization is different at the two different substations, it may look like the event started at the industrial facility when, in fact, it started at the utility's facility, or vice versa.
Another area of concern: no standard currently exists for how IED vendors decide when an event has taken place. For example, when looking at a current waveform to determine when the current has first reached a significant threshold, vendors may have applied filters and smoothing algorithms that will result in different readings for the same waveform. These factors could cause multiple IEDs to show different times for the same waveform event. (As we'll see, efforts are underway to address the issue.)
The same issue arises with contact closures. In the absence of a standard, vendors with their clocks exactly synchronized still could end up with records of the same event showing up at different times. The difference of an error of, let's say, 10 milliseconds on a transmission-class system could be the difference between an indication that a primary relay operated first and then a secondary or the appearance that a secondary relay operated first and then the primary, which would be a mis-operation. And an investigation into the sequence of events would implicate the wrong IED.
Another instance where errors can be introduced is that the software application in the IED, which actually time-stamps event information may not have the same priorities as other applications. So depending on what activity is taking place within that IED, the sequence-of-events application itself can introduce error. A real challenge arises when the IED is attempting to time-stamp the occurrence of a communication signal. Whether it be a GOOSE message (Generic Object Oriented Substation Event) in IEC 61850: Substation Automation, a control command coming in through the supervisory control and data acquisition (SCADA) port or a transfer trip on a protection system, there are no standards to dictate exactly when that message should be time-stamped as received.
Vendors right now are free to choose when they put a time-stamp on a message. It would actually be within the current technology and accuracy of IEDs for events records to indicate that one IED received a message before the originating device recorded the message being sent.
Utilities face this challenge as well, with the advent of highly accurate, GPS-based clocks. Now, with a GPS system, which can easily set accuracy to ` millisecond, utilities are seeing the challenge arise in the accurate, coordinated distribution of a time standard. So the increased resolution of the clock has revealed the nuances of getting consistent time-stamps.
Sam Sciacca is an active senior member in the IEEE and the International Electrotechnical Commission (IEC) in the area of utility automation. He has more than 25 years of experience in the domestic and international electrical utility industries. Sciacca serves as the chair of two IEEE working groups that focus on cyber security for electric utilities: the Substations Working Group C1 (P1686) and the Power System Relay Committee Working Group H13 (PC37.240). Sciacca also is president of SCS Consulting.