In one of the implemented projects (where IEC 61850-8-1 in part of GOOSE and MMS communications is used) the following situation has occured: there weren’t enough binary outputs in protection IEDs to transfer signals to stand-alone fault recording IED. This fault recording IED supported GOOSE (as well as protection IEDs, used in the project) and there was a suggestion to transfer signals, which can not be transferred through binary outputs of the protection relays, via GOOSE. Another suggested option was to transfer data using reporting function. Several questions arised:
- How to transfer signals to fault recording device – via GOOSE or via reports? Or to combine two possible ways?
- If to use GOOSE, should operational GOOSE messages (the ones which are transfered by protection IEDs) be used or designated GOOSE-messages with specific datasets have to be created?
- If to use reports, should one use buffered or unbuffered?
- What are the requirements for datasets (number of signals in telegram, availability of timestamp and quality attributes)?
The second question is about evolution of fault recording system in digital substation:
- How the functionality of fault recording system must change in digital substation with station and process bus?
- How the architecture of fault recording system must change?
- How the data acquisition must be performed – given the significant network load, introduced by Sampled Values streams?
Experts from utilities and IED manufacturers answer these questions.
Andrey SchemetovFGC UES (Russian Federation)
Question related to fault recording functions implementation in digital substations are very important. Today we see first fault recording units capable of receiving Sampled Values streams and GOOSE messages. But before thinking about ways of data transmission to fault recording units, I would like to rethink the overall approach to fault recording in substations, which has not changed since the introduction of light beam oscilloscopes.
The task to acquire fault parameters have arised when protection relays have been introduced. This has been required to check if they operated in a correct way. For this purpose and for fault location current pointer indicators have been introduced. But this hasn’t been enough.
First real fault recorders were light beam oscilloscopes, which saved current and voltage parameters on special films. Later on, modifications, which recorded data on photo paper, were introduced. Further upgrades provided industry with fault recorders which recorded data in magnetic drum memory with possibility to print data in paper afterwards. The latter provided possibility to record pre-fault data for some time. All these devices have been created with one purpose – to record fault process, what had previously never been done.
In early nineties first microprocessor-based fault recording units begin to appear. Without any requirements from the customers, there have been introduced different implementations of such units: starting from decentralized systems with remote modules and ending up with centralized units with a great number of inputs. Availability of binary inputs in fault recording units allowed to connect output relays contacts (as well as auxiliary relays) to fault recorders. New devices have been introduced in a great pace: no need to buy photo paper or chemical agents, no need for expensive maintenance. Further – microprocessor-based protection relays with integrated fault recording functions have been introduced – but this has not led to the refusal from autonomous fault recorders as new microprocessor-based relays have not been trusted a lot yet. So now we have projects where stand-alone fault recorders are installed next to microprocessor-based protection relays. Waveform recordings from protection IEDs are studied to analyze operation of the relays and waveform recordings from fault recorders – to verify relay data and its operation.
Debatableness of this solution is obvious. Therefore the aim of creation of fault recording unit (to record a fault, nowhere else recorded) has been disrupted. Nowadays during fault analysis we can use waveform recordings from three IEDs: protection IED, fault recording IED and fault location IED. And they all record the same data. To enable this multiple recording we wire several kilometers of cables. install cubicles, increase power consumption and man-hours on maintenance. But we can identify failure of the single protection IED using waveform recordings from other protection IEDs in the system – so why stand-alone and autonomous fault recording devices are still required in substations?
Let’s think about what fault recording should be in digital substation and which kind of fault recorder is required by the customer. First, it is worth mentioning that in digital substation there is a surplus in information. Currents and voltages are available from redundant sources in digital form, all binary signals are transmitted using GOOSE-messages and signals are stored in memory of IEDs, time synchronization accuracy improved from 1 ms up to several microseconds. Acquisition of signals over binary inputs and generation of signals over binary outputs dramatically reduced (the ones left are: switchgear equipment status signals and controls, mechanical protection devices of oil-filled equipment, on-load tap changer status and control signals). All cable circuits are duplicated. We have IEDs, which can be subscribed to two Sampled Values streams with capability of switching between them. We have GOOSE message generation timestamps available in publisher and GOOSE reception timestamps available in subscribers. Given that today we see trials to create fault recording units for digital substations, which can be subscribed to Sampled Values streams and GOOSE messages, capable of processing and storing gigabytes of information and generating custom waveform recordings. But for the analysis of faults and other contigincies we need the infromation from protection IEDs, which generated control signals.Given that, I see fault recording in digital substation in a following way. This should be a software and hardware complex which performs automatic data (analog measurements and binary signals) download from all protection IEDs in substations and which is capable of generating a custom waveform. Analog measurements of currents and voltages from the same feeder (acquired from several IEDs) must not be duplicated. When downloading data from IEDs, system must identify signals from the same feeders and must perform cross-check to identify any difference. If any difference is detected, it must be indicated. Binary signals in waveforms must be presented with timestamps of GOOSE message generation and GOOSE message reception. Transfer times must be indicated for each GOOSE message. Any failures in operation of protection IEDs must be acquired via reports and also must be indicated.
Fault recording system must become software system which takes data from available primary sources of digital information (NCITs, AMUs, DMUs, protection IEDs and etc.) and generates custom waveforms, relying on data available in SCD file.
It must supervise specific parameters of the system: Sampled Values and GOOSE messages transfer times, validity of SV and GOOSE messages, operation of time synchronization system and network equipment. This system must verify operation of protection IEDs and primary current/voltage sensors.
Mihail SchevaldinBelenergo (The Republic of Belarus)
Fault recording is one of the cornerstones in contemporary protection and automations systems. Some specialists do insist that their is no need in stand-alone and autonomous fault recording devices as all required functions are implemented in protection IEDs, including fault location. Other specialists, especially those who have already encountered with misoperation of protection relays (as a consequence of firmware or hardware failures) insist that stand-alone and autonomous fault recording devices have to be installed.
One example, proving the need for autonomous fault recording units. In one of the CHP stations in Minsk (Belarus) hardware failure of the IED (110 kV line protection IED) of one rather famous manufacturer occurred. IED sensed three-phase short-circuit current in a primary circuit and generated 110 kV circuit breaker trip signal. Trip signal has gone through and circuit breaker even tripped. But due to the hardware failure IED still sensed current in primary circuit and even could generate breaker-failure tripping signal. It was winter and in this CHP there were several dozen of 110 kV lines in operation… It is hard to image what could be the consequences of the IED failure. Thanks to the fact that in most cases in 110 kV in Belarus breaker-failure function is implemented busbar differential protection IED. And false operation has been prevented.
In a few seconds IED stopped sensing three-phase fault current and continued its operation in a normal way. No failures have been discovered in IED afterwards. And if there has been no stand-alone fault recording devices installed in the facility, nobody could prove that protection IED tripped in normal conditions. And this is just one example.
Data, generated by fault recording units, is also used during the analysis of critical failures in facilities to evaluate operation of protection IEDs. Another function, which is usually provided by fault recording IEDs, is fault location.
When speaking about digital substations we need to consider the way analog signal acquistion and processing is performed – either using non-conventional sensors or using stand-alone merging units. In the first case it is not possible to implement autonomous fault recording, as these fault recording units will be connected to the network and will be acquiring all the required data from there in a digital form. This will not be an independent system and it makes no sense to have a stand-alone fault recording device.
In a second case (with SAMUs) it is possible to install fault recording units in the point of the system before SAMUs. In this case, acquisition of the signals may be implemented in a stand-alone device and then recorded data can be transferred to central fault recording unit. But this is a particular case, which in my opinion, will be used for some time in facilities.
But in the far end, we see that arcitecture of the digital substation does not stipulate the use of fully autonomous fault recording units.Yuri IvanovProsoft-Systems (Russian Federation)If the task of the fault recording system is to restore the actual sequence of the events during contingencies, then it is required to use GOOSE messages. That is because using MMS we can only (with the help of precise time stamps) restore logical sequence of events i.e. which signals and at what time have been generated by IEDs. In general, one should understand that signal generation time differs from its appearance time in a network and from actual delivery time to the subscriber (network time delay). So actual sequence of events can only be restored only using GOOSE messages and only at certain conditions. Our researches showed that network time delay when transferring the same GOOSE message to two different subscribers may differ significantly. If this (deterministic delivery times of the same GOOSE message to all subscribers) has not been considered during the design of the system, actual GOOSE reception times at fault recording unit and at protection IED would be different. The conclusion is as follows: during the design of the network it is required to consider determinancy in delivery times of GOOSE-messages to every subscriber.
Fault recording system must rely on GOOSE messages that are sent by protection IEDs to other IEDs of the network – there is no sense to generate special messages for fault recording devices. Otherwise the idea of fault recording makes no sense.
All GOOSE messages must include maximum data (quality and timestamp attributes). Every single data may be useful for analysis of the failures.
Regarding digital substations – we think that functionality of fault recording system must change dramatically. The reason for that is the key component – process bus, which has its own technical characteristics which need to be monitored.
There should exist independent fault recoding system. Its role increases in digital substation.Maxim GribkovMOESK (Russian Federation)
Fault recording must implemented in a stand-alone IED, which receives all the required properly timestamped information. In substations with non-conventional current and voltage sensors, data must be transferred to fault recording IED using GOOSE messages. When stand-alone merging units (SAMU) are applied, fault recording IED must be installed in the same cubicle as SAMU and must be connected to analog circuits in this cubicle.
To provide data consistency it is required use GOOSE messages which are used for operation purposes. And if it is only required so, it is possible to create designated GOOSE messages for fault recording units.
When using GOOSE messages to transfer data to fault recording units, it is obligatory to have timestamp and quality attributes for each signal, included in a telegram.
If to speak about fault recording in digital substations with both station and process bus, functionality of the fault recording units must be improved to provide more information on the process. Fault recording IED must remain a stand-alone device and fully autonomous, which acquires all actual information to provide possibility for anaylsis of operation of primary and secondary equipment. Data recording must be performed over all channels simultaneously and synchronously, independent of the fact, which channel initiated recording.Igor WagnerKEGOC (The Republic of Kazakhstan)
Data can be transferred to fault recording systems both using GOOSE and MMS (reporting) but the following requirements have to be met: availability of time stamps, minimum load on the network during fault conditions. Archiving of events in the single file must be available.
To provide data consistency and reduce load in the network no special (designated) messages have to be generated for fault recording devices.
When using reporting – buffered ones must be applied.
If designated GOOSE messages are used to transfer data to fault recording systems, several signals can be included in one telegram, but for every signal there must be present a time stamp and quality attribute.
If process bus is implemented, functionality of the classical fault recording system must be preserved.
Fault recording system server must be stand-alone and fully autonomous. This will provide automatic acquisition of signals and waveform recordings, their processing with generation of reports as well as remote access to a set number of specialists for diagnostics and configuration.
At fault recording initiation all the signals fed to fault recording system must be recorded – even if there has been no change in their value in a given timeslot.Alexey SchevelevRC Bresler (Russian Federation)
I think that all signals must be transferred to fault recording system using GOOSE messages.
It is better to create designated messages, but, in case, if it is sufficient to use operational messages, they can be used. In general, this is decision of the system engineer.
Regarding requirements on GOOSE dataset – I think that it is obligatory to have timestamp and quality attributes included in a dataset.
Functionality of the fault recording system in digital substation with both IEC 61850-8-1 and IEC 61850-9-2 must not change. But this has to be an IED with high processing power. Some functions, related to digital communications, may be added to general functionality.
Regarding architecture of the fault recording system, this has to be agreed with the customer. In my opinion, it is good to have stand-alone and fully autonomous fault recording device.
Sampled Values streams must be received over designated ports.