If you have a supervision system that aggregates data from many substations, it’s important to have a philosophy that serves as a guide to the system configuration, maintenance, functioning and expansion. A written document widely available helps people from distinct areas (supervision, protection, automation, maintenance, operation, etc.) understand the hows and whys of the supervisory system.
Here are some guidelines that can be helpful in composing such a document.
Standardization of systems and devices
Standardize all the systems and devices in the substation and control centers. There are many types of devices and systems: RTU, concentrators, protection relays, HMI’s, etc. Multiply that number of devices and systems by the number of substations and control centers then you can see the size of the system to be managed. Each different device and system you have aggregates a big cost of learning to program, maintain and operate it.
It’s very important to try to keep the number of types of devices and systems up to a minimum, this a decisive factor that drives the cost of maintaining and expanding the system as a whole.
Automatization of Configuration
Consider again the number of devices and systems, and that substations have thousands of supervision points. To configure all of them manually is an insane amount of work. It pays back easily all investment in tools to automate the generation of the configuration of any type of devices and systems you have. I’m talking about a systems to manage the configuration, and no, Excel sheets are not systems.
Substation Local System
The local substation automation system composed of RTU and/or data concentrators, protection and control relays, measurement units, etc. must be viewed as a complete and autonomous system, that can do automate and control local processes, and may have many clients like the local operators, the control centers, other agents like transmission, generation and distribution utilities and the ISO. The age of dumb RTU’s is long gone but some legacy of this time is permeated in peoples mind, communication protocols, device and systems capabilities.
Standardization of protocol data types
The communications from the local substation system with the outside world must not use data types (ASDU’s) conceived for the old dumb RTU’s, for instance the IEC 60870-5-101/104 normalized analog value demands that all the outside systems maintain conversion factors to restore the measurement values. The local system must deal with values in engineering units to present to the operator, so why send a value that need to be converted again? There is no reason anymore to do this, floating point types of the chosen protocol must be used, the values must be sent ready to be used. When there is some change, there will be just one place to modify.
It’s rare a system that uses select before operate commands properly, so IEC 60870-5-101/104 command with selection and the double command are generally not justifiable, it’s better not to use them. In almost any case it’s preferable to use the single command, with no select before operate.
Digital state double type it’s another burden, it’s not supported in many protocols and not all systems make good use of it, normal transitions to inconsistent states just pollutes the events list, so it’s better to keep the consistency of state at the RTU/concentrator level. Just send the digital single state to the client systems and invalidate the point value when an inconsistent state is detected.
Digital states must be managed at RTU/concentrator level to represent active functions or alarms by the ON state and inactive functions and absence of alarms by the OFF state. States must never be inverted outside of the substation level, this can cause much confusion when checking states as in this case points can have inversions in many systems at many levels of data acquisition. By the same reasoning, measurement signals of values also must be managed locally in the substation, and not inverted at upper levels.
Unneeded points must not be sent upwards. This is apparently obvious but in practice it happens all the time.
To many people, every substation data appears to be needed in the control center but they are not. Control centers systems appears to have infinite capacity, but they have not. Operators also don’t have infinite capacity of processing events and alarms lists, and adding more operators may not help.
Many points representing communication statuses or devices health can be combined in just one point per substation or at least per bay, when a problem happens the local system can be investigated by technicians that can correct the problem, rarely there is a need to identify the exact problem in what precise device.
Alarm floods must be avoided by all means. A good advice is “an alarm is an event or situation that requires an operator response”. Must be remembered also that a point do not always translate directly to an alarm.
To distinguish what is really useful and what is not it’s very difficult and requires power system operation knowledge, so a good practice is to standardize what types of information (data type dictionary) are to be included in the point database. Point description must not be entered freely, but rather be chosen from a data type dictionary. This standard must be created and maintained by a team of supervision, operators and protection experts. As new types of information appears, the team must discuss if they’ll be included or not in the data type dictionary.