Really speaking with the advent of PMU (Phasor Monitoring Unit) getting installed in the system for wide-area monitoring with fiber-optics based communication, timing is not the issue (with data in enormous quantity pouring in every millisecond). But the problem is in SCADA system with human-machine interface, it may not be possible to capture the data so fast. Hence to take care of human perception, it may be desirable, as practiced too, to change the data in VDU (Visual Display Unit) in every 10 seconds only. However, computer can go on recording whatever data it receives and so rather trending graphically to catch attention in case of abnormality during supervisory monitoring.

The answers to most non-trivial questions in this space start with: "It Depends".

Most systems are supplied in response to a customer specification. If the customer has a need for short latency (time from something occurring until it is available at the control centre), then this functional requirement is stated in the specification. Typically, short latency costs more than long latency, so this is only specified as a requirement in systems that truly need it.

The lowest RTU to control centre communication update delay capability (for conventional SCADA) that I have seen is around 3mS. To this, the communication system delays are added, which are typically much longer than this. Digital (on/off status) inputs are typically monitored at millisecond or faster rates. Analog measurements (from transducers) are typically only sampled / updated at rates of 1 to 10Hz. Direct digitization of volt & amp inputs occur at higher rates (kiloherz), but the calculation to a derive engineering unit measurements (V, A, W, Var, etc.) from the samples is typically averaged over multiple cycles of the power system frequency, again giving an update rate around 2 to 5 Hz. The monitoring /input sampling / conversion rate for input data also impacts the overall latency from a field input to the data being reported.

However, simple latency this is not usually the problem / functional requirement that SCADA needs to meet. The delay for an operator or automation function at the SCADA control centre to identify, analyse and respond to data is typically significantly longer than the data latency. Subrata mentions a 10 second update rate for an operator display. I have worked with systems with a maximum 1 second refresh / update rate. This is a common range for this functionality. One of the particular needs is for acceptable feedback / confirmation of operator-initiated command actions: When, for example, an operator issues a command to trip a circuit breaker, they expect the HMI status indication for that breaker to change within a few seconds to indicate successful operation of the command.

In most power system SCADA applications, the need is for the field equipment to accurately time stamp events and report a collection of data with correct sequence of operation. This can then be logged to a historian for subsequent analysis (if required). This allows forensic investigation of unusual operational conditions or faults. This kind of data reporting does not require very high speed of communication or short latency, but it does require that the field equipment perform input monitoring at a suitably high frequency and buffers the data until it can be reported (at a lower frequency / speed than the local monitoring). The majority of systems used for power system SCADA include these capabilities (a combination of device capability, protocol choice, communication system capability, etc.). Typical power system SCADA systems have latency of data collection in the range of 100ms to 10 seconds. In some places, regulatory requirements dictate maximum latency limits that must be met: For example, in Australia the maximum latency from field to market operator (substation to utility to market operator) is 4 seconds.

For PMUs, there are a number of different application functions that can use the data. Some of these functions associated with monitoring power system stability and resonance require comparison of data from multiple locations at rates of 10Hz or higher. This suggests that for those specific functions, the data collection and analysis process needs to be significantly faster than this. Some other PMU functions can operate OK at SCADA-level update rates.

It depends what you are doing. If you have determined the particular latency requirement for your application, you need to specify it (and verify it by testing).

A SCADA system needs to interact with devices in real time. In Bowen et al. [7],

SCADA transactions must have a time delay of no more than 0.540 seconds. In Boulay and Reilly [8], the time latency should be less than 0.900 seconds for states and alarms.

So, our proposed architecture for SCADA communication must match the shortest time delay requirement of no more than 0.540 seconds.

Generally, a SCADA communications link operates at low speeds such as 300 to

19,200 baud rate [9]. In the Modbus implementation guide, default baud rate is now 19200, and if that cannot be implemented then the default baud rate is 9600 [10]. Therefore,

we assume a requirement of a 9600 baud rate in this paper.

7. C. L. Bowen, T. K. Buennemeyer, and R. W. Thomas, “Next Generation SCADA Security : Best Practices and Client Puzzles,” in Proceedings of the 2005 IEEE Workshop on Information Assurance and Security United States Military Academy, West Point, NY, 2005.

8. Martin Boulay and Robert O’Reilly, “Implementing Real-Time Statistical Analysis of Power Quality in a Distributed Generating Environment,” CanWEA conference.

9. Andrew K. Wright, John A. Kinast, and Joe McCarty, “Low-Latency Cryptographic Protection for SCADA Communications,” in Proceedings Applied Cryptography and Network Security, 2004.

10. Modbus, “MODBUS over serial line specification and implementation guide V1.02,”

Farhad Yazdi, Andrew West and Subrata Mukhopadhyay

Thank you all for your helpful comments.

To sum up, the update time is highly system dependent and typically varies between 100 ms to 10 sec.

what is the impact of PMU failure on the power system?

It depends entirely what the PMU data is used for and how the system is designed to operate when the PMU data is not available. All good system engineering makes allowance for the failure of sensors or subsystems. Some functions might be unavailable if the PMU data is unavailable.