American media was in full flight, asking "Where did the blackout start?", "How did it spread?" and of course "Whose fault is it?" Looking for answers provides us with a clear lesson on the importance of event recording within a scada system.
Literally thousands of discrete events through multiple scada systems would have preceded this extensive blackout. Reviewing the event records of the scada systems involved should provide the answers to where the problem started and the way in which it spread. The lessons learned from this data will likely have a major impact on the future development and management of the US and Canadian power networks. Of course the commercial and legal importance of these event records may be felt far sooner!
The basic role of a scada system event recording system is to record the nature and time of every discrete event that occurs, both in the real world monitored by the scada system, and in the scada system itself. However, some of the 'detail' is also very important:
* The event record must be complete, capturing all digital changes, analog alarm transitions, all operator actions and all internal system events. A partial record is likely to be a useless record.
* The records must be preserved. For example a process factory with an effluent discharge licence is typically required to maintain event records for several years. While being a legal requirement imposed by local authorities, this information also provides technical information and legal protection for a well-run business.
* The record must be accessible: Fairly obvious, but inadequate event sort, filter and report capabilities could well have caused a few grey hairs amongst some scada system managers in America recently!
* Event time stamps need to be accurate and precise: Cascading failures in a power network happen quickly. Trying to work out the sequence of events is only possible if each event is time stamped to millisecond accuracy.
'Sequence of Events' or 'SOE' capability in a scada system is the provision of highly accurate and precise event records, specifically designed to enable subsequent analysis of the order in which things happened. Having events with millisecond time stamps is a start, but unless the time is correct, the information is possibly more dangerous than no information. There are two more important prerequisites for providing accurate SOEs:
1. Record time locally: The RTU, PLC or other I/O device directly wired to the transducer must attach the time stamp to the events. The event information including this locally applied time-stamp can then be transmitted back to the scada master station. The role of the master station is to merge, display and record the SOEs received from many different I/O devices. Compare this to normal events where the time is 'stamped' onto the event by the scada master station software. The variable time taken to transmit the event data to the master station from different I/O devices completely compromises the accuracy of events that are time-stamped within the master station.
2. 'Synchronise watches': Like good secret agents, the plan only works if everyone is working to the same time. This requires the internal clock in all I/O devices and the scada master station to be regularly and accurately synchronised. The traditional approach was for the master station to send a time-synchronisation message to each I/O device. The difficulty was in compensating for the different time it took to transmit the time broadcast to the many different I/O devices. Nowadays it is practical to use a GPS receiver within each I/O device to synchronise to a common external time based on GMT. This clean solution provides another benefit that will be important in North America right now: If neighbouring scada systems are synchronised to this common external source, they can usefully compare their individually collected sequence of event records.
For more information contact Tony Haresnape, BJS, [email protected], www.i-scada.com
© Technews Publishing (Pty) Ltd | All Rights Reserved
printer friendly version