EARTfelt Greetings, Dear friends of protection and control engineering! In our new and exciting guest contribution, Thomas Schossig brings us closer to the world of IEC 61850 by means of a practical example. We are very happy and pass the word to:
Thomas Schossig!
What a challenge to write "something practical about IEC 61850" for SCHUTZTECHNIK.COM. Although the standard IEC 61850 is no longer new (available since 2005), it does not even have the word "protection" in the title. The standard is called "Communication networks and systems for power utility automation". So we are dealing "only" with a communication standard. Correspondingly, it is the idea of this article to describe the journey of protection information from the protection device to the control center. In this article and in the standard, we no longer call the protection device a "relay" but more general IED. IED means intelligent electronic device. Since the intelligence is not only used for protection devices but also in field controllers and so on, the standard describes the communication for protection and control technology or, in other words, station automation systems.
Our message is to be the general trip of a protection device, that is, what was put on binary output 1 in the good old days to send a message or terminate a test set.
Now, such an IED has not only a message to distribute, modern multifunctional devices offer thousands of information. Therefore, the manufacturer of the IED groups the information of the "data model" in so-called logical devices.
Our manufacturer has grouped his device according to functions. We recognize a control (CTRL), a measurement (MEAS) and protection (PROT) device.
In the search for our general trigger, we go into the LD PROT and see a variety of other elements in the tree - the logical node. The variety of logical nodes of the device is sophisticated, but there are some explanations available. The structure and content of the logical nodes are defined in the standard, only so I reach the interoperability, so that different manufacturers can communicate with each other. And so our general trip is in the world of IEC 61850 and in all IEDs a PTRC - Protection Trip Conditioning. The first letter always designates the main application, so all protection nodes start with P. Our device has 3 different general trips, we are happy with the PTRC1, the first instance of the class PTRC in our IED. To understand this with the classes and instances, a look further down helps. The standard defines a class PDIS for distance protection. The concrete Z1 in our IED with quadrilateral characteristic is called QUAD_PDIS1, the conclusion on Z2 should succeed now.
This creates a large data model with every available information of a device.
If we now open our node for the general tripping and now really want to know whether the IED had triggered, we look into the data object Op (for Operate = trip). The attribute "general" is set to false.
If we trip the IED, the value changes to true as expected. The timestamp indicates the christmas time 2017.
Our IED provides a lot of information, the data model is constantly updated.
Now, not only the singular information will be interesting from such an IED, the control center will certainly want to know all the trips. The standard calls such a collection of information DataSet, the system engineer of this system has summarized all triggers to such one.
This information is transmitted with a service of IEC 61850, the so-called report to control center. For the purposes of IEC 61850, the control system is the client that receives the information from the IED (server). So let's take the trip back and notice that the changed information has been transferred to the control system.
The whole thing again with time stamp and for a good reason. In order to "annoy" the control technology only if something has changed, the client has defined a trigger condition "data change". Only with a change the report is transferred.
Incidentally, this client / server communication takes place as a point-to-point connection between the IED and the control system. This type of service is also used for control and, for example, disturbance recording (file transfer).
If we really want to use this protection information for time-critical tasks such as transfer signals or even tripping a circuit breaker, we can no longer afford the luxury of confirmed client-server communication. Here we need something new and fast. The GOOSE is a Generic Object Oriented Substation Event - something happens in a substation and has to be transferred.
This GOOSE is sent as multicast - thus from one IED to many - unconfirmed. So again we have a DataSet for GOOSE. Our system engineer builds a GOOSE with distance protection information:
This GOOSE is not only transmitted once but constantly. Thus, the IED has already transmitted the status with the Z1 and Z2 trip information 15 times (see sequence number). In the case of changes, the transmission will be quick and more frequent, readers with children may well know the procedure for communicating with the offspring.
Important: Any information with timestamp and quality "good".
With the GOOSE method, interlockings, busbar protection via rear interlock etc. can be realized simply.
What does this mean for the protection test?
The protection test set should therefore be able to receive this GOOSE and treat it like a conventional binary signal. In our case, we map the Z1 trip to the binary input number 1 and perform the protection test as usual.
It makes sense to test the control SCADA communication at the same time:
As you can see in the picture we activated the report and can test it. This also answers another question: How do I explain to my SCADA that this message only occurred during a test and is not regular? IEC 61850 offers different modes for this. The device or a piece of information can be put into a "test" mode (and others). Once we have done this, the control system can discard this information accordingly. On this subject you can make an extra contribution on occasion.
An extra contribution could now also be made on the subject of Sampled Values. In this case, measurement data are transmitted as multicast with the GOOSE mechanism and are therefore available throughout the entire network. This technology is already in use internationally, but still quite new in the German-speaking energy supply companies. Therefore, more on that later.
However, this contribution should not end without a vision of the future. Anyone who has read so far should see that the IEC 61850 also offers completely new possibilities. The data model of an IED can also contain protection parameters. The whole thing is of course voluntary or as the IEC 61850 calls it "optional". Of course, in the IED or the parameterization, the mechanism presented here can be switched off, hidden or blocked. But those who get involved in the game of thought may also be pleased to find parameters in the data model. In the example this is the parameter X1. Incidentally, in IEC 61850 there are only primary values.
Anyone who thinks "Oh, horror, why that" might think about new possibilities. Why not just document the values before and after the test? Why not automatically check the setting during the routine check? There are many opportunities. Switching of parameter sets ("Setting Groups") is possible with IEC 61850. This activates predefined and checked setting sets or even allow the writing of parameters. Adaptive protection concepts become possible. But that too is another topic.
Thanks for reading up to here and have fun with and without IEC 61850.
Thomas Schossig
Schossig, Thomas
His professional career began in 1998 at VA TECH SAT GmbH in Waltershausen, initially as a project engineer for control technology projects, then as a group leader in protection engineering.
Since 2006 he has been working as Product Manager at OMICRON electronics GmbH in Klaus (Austria). In Business Development Power Utility Communication, he deals with test solutions for IEC 61850.
He is the author of various publications in the field of communication in switchgear and protection testing technology and member of standardization groups. His current work is the new edition of the textbook: Netzschutztechnik (see below).
Contact: thomas.schossig@omicronenergy.com
