Event protocol - in your own words
If we consider the allegory with the classroom, which is well suited, the cyclic protocols like Modbus, Profibus, Fieldbus - are similar to the poll of each of the students consistently. Even if there is no interest in the device (the pupil). Event protocols work differently. There is a request not to each device of the network (student) sequentially, but to the class as a whole, then information is collected from the device with the changed state (the student raising his hand). Thus, there is a strong saving of network traffic. Network devices do not accumulate errors in a poor-quality connection. Given that the delivery of the event occurs with a time stamp, even if there is some delay, the bus master receives information about the events that occurred on the remote objects.
Event protocols are mainly used at power facilities, as well as remote control systems for various gateway and watershed systems. They are used everywhere, where remote dispatching and management of objects that are far from each other is necessary.
History of the development and implementation of event protocols in the automation of energy facilities
An example of one of the first successful attempts to standardize information exchange for industrial controllers is the ModBus protocol developed by Modicon in 1979. Currently, the protocol exists in three versions: ModBus ASCII, ModBus RTU and ModBus TCP; its development is engaged in non-profit organization ModBus-IDA. Despite the fact that ModBus belongs to the application layer protocols of the OSI network model and regulates the functions of reading and writing registers, the correspondence of registers to measurement types and measuring channels is not regulated. In practice, this leads to the incompatibility of protocols of devices of different types, even from one manufacturer, and the need to support a large number of protocols and their modifications with the built-in DRM software (with a two-level polling model-collection server software) with a limited possibility of reusing code. Given the selective adherence to standards by manufacturers (the use of unregulated algorithms for calculating the checksum, changing the order of bytes, etc.), the situation is aggravated even more. To date, the fact that ModBus is not able to solve the problem of protocol separation of measuring and control equipment for power systems is obvious. The DLMS / COSEM (Device Language Message Specification) specification, developed by the DLMS User Association, and developed into the IEC 62056 family of standards, aims to provide, as stated on the association's official website, an "interoperable environment for structural modeling and data exchange with the controller" . The specification separates the logical model and the physical representation of the specialized equipment, and also defines the most important concepts (register, profile, schedule, etc.) and operations on them. The core is the IEC 62056-21 standard, replacing the second revision of IEC 61107.
Despite the more detailed development of the model of the device representation and its functioning in comparison with ModBus, unfortunately the problem of completeness and "purity" of the implementation of the standard has been preserved. In practice, a survey of a device with the claimed DLMS support of one manufacturer by a poll program from another manufacturer is either limited to the main parameters, or simply impossible. It should be noted that the DLMS specification, in contrast to the ModBus protocol, proved to be extremely unpopular among domestic record-keeping device manufacturers, primarily due to the greater complexity of the protocol, as well as additional overhead for connection setup and device configuration.
The completeness of the support of existing standards by manufacturers of measuring and monitoring equipment is insufficient to overcome intrasystem information disconnection. The manufacturer's support for a standardized protocol, as a rule, does not mean its full support and the absence of the introduced changes. An example of a complex of foreign standards is the family of standards IEC 60870-5, created by the International Electrotechnical Commission.
Various implementations of IEC 60870-5-102 - the generalization standard for the transfer of integrated parameters in power systems - are presented in the devices of a number of foreign manufacturers: Iskraemeco d.d. (Slovenia), Landis & Gyr AG (Switzerland), Circutor SA (Spain), EDMI Ltd (Singapore), etc., but in most cases - only as additional. As the main data transfer protocols, proprietary protocols or DLMS variations are used. It should be noted that IES 870-5-102 was not widely used for the reason that some manufacturers of metering devices, including domestic ones, implemented modified telemechanical protocols (IEС 60870-5-101, IEС 60870-5 -104), ignoring this standard.
A similar situation is observed among the manufacturers of RZA: in the presence of the current standard of IEC 60870-5-103, a ModBus-like protocol is often implemented. The prerequisite for this, obviously, was the lack of support for these protocols by most top-level systems. Telemechanical protocols, described in the standards of IEC 60870-5-101 and IEC 60870-5-104, can be used when integrating telemechanics and electricity metering systems. In this regard, they have found wide application in dispatching systems.
Technical specifications of automation protocols
In modern automation systems, as a result of the constant modernization of production, the tasks of constructing distributed industrial networks with the use of event data protocols are increasingly encountered. For the organization of industrial networks of power facilities, many interfaces and data transfer protocols are used, for example, IEC 60870-5-104, IEC 61850 (MMS, GOOSE, SV), etc. They are necessary for data transfer between sensors, controllers and actuators, communication of the lower and upper levels of the process control system.
Protocols are developed taking into account the features of the technological process, providing a reliable connection and high accuracy of data transfer between different devices. Along with the reliability of operation in harsh conditions, more and more important requirements in ACS TP systems are functional capabilities, flexibility in construction, ease of integration and maintenance, compliance with industry standards. Consider the technical features of some of the above protocols.
Protocol IEC 60870-5-104
The IEC 60870-5-104 standard formalizes the encapsulation of the ASDU from the IEC 60870-5-101 document into standard TCP / IP networks. It supports both Ethernet and modem connection using the PPP protocol. Cryptographic data security is formalized in the standard IEC 62351. Standard TCP port 2404.
This standard specifies the use of an open TCP/IP interface for a network containing, for example, a LAN (local area network) for a telemechanics device that transmits the ASDU in accordance with IEC 60870-5-101. Routers that include routers for WAN (wide area network) of various types (for example, X.25, Relay frame, ISDN, etc.) can be connected via a common TCP / IP-LAN interface.
Example of general application architecture IEC 60870-5-104
The transport layer interface (the interface between the user and TCP) is a thread-oriented interface that does not define any start-up mechanisms for ASDU (IEC 60870-5-101). To define the beginning and end of the ASDU, each APCI header includes the following marking elements: a start symbol, an ASDU length indication along with the control field. A full APDU can be transmitted, or (for management purposes) only APCI fields.
The structure of the IEC data packet 60870-5-104
- APCI - Control Information of the Application Level;
- ASDU - Data Block. Serviced by the Application Level (Application Block of the Application Level);
- APDU - Protocol Data Block of the Application Level.
- START 68 H defines the start point inside the data stream.
The length of the APDU determines the length of the APDU body, which consists of four bytes of the APCI control field plus the ASDU. The first byte to be considered is the first byte of the control field, and the last byte considered is the last byte of the ASDU. The maximum length of the ASDU is limited to 249 bytes, because the maximum length of the APDU field is 253 bytes (APDUmax = 255 minus 1 byte of start and 1 byte of length), and the length of the control field is 4 bytes.
This data transfer protocol, at the moment, is de facto the standard scheduling protocol for enterprises in the electricity sector. The data model in this standard is developed more seriously, but it does not provide any unified description of the power object.
DNP3 (Distributed Network Protocol) is a data transfer protocol used for communication between the components of the process control system. It was designed for easy interaction between different types of devices and control systems. Can be applied at various levels of process control systems. There is a Secure Authentication extension for DNP3 for secure authentication.
In Russia, this standard is weak, but some automation devices still support it. For a long time, the protocol was not standardized, but now it is approved as the IEEE-1815 standard. DNP3 supports both serial RS-232/485 communication lines and TCP / IP networks. The protocol describes three levels of the OSI model: application, channel, and physical. Its distinctive feature is the ability to transfer data from both the master to the slave and between the slave devices. DNP3 also supports sporadic data transfer from slave devices. The basis for data transmission is, as in the case of IEC-101/104, the principle of transferring a table of values. At the same time, in order to optimize the use of communication resources, the whole database is not sent, but only its variable part.
An important distinction of the DNP3 protocol from those considered earlier is the attempt to objectively describe the data model and the independence of data objects from the transmitted messages. To describe the data structure in DNP3, an XML description of the information model is used. DNP3 is based on three levels of the OSI network model: application (operates with objects of basic data types), channel (provides several methods of data extraction) and physical (in most cases, RS-232 and RS-485 interfaces are used). Each device has its own unique address for this network, represented as an integer from 1 to 65520.
- Outslation - slave.
- Master is the master.
- Frame (frame) - packets transmitted and received at the link layer. The maximum packet size is 292 bytes.
- Static data - data associated with any real value (for example, a discrete or analog signal)
- Event data - data associated with a significant event (for example, changes in state., Achievement by a threshold value). It is possible to attach a timestamp.
- Variation (variation) - determines how the value is interpreted, is characterized by an integer.
- Group - defines the type of the value, is characterized by an integer (for example, the constant analog value refers to group 30, and the event analog value to group 32). For each group a set of variations is assigned, with the help of which the values of this group are interpreted.
- Object (object) - frame data associated with a particular value. The format of the object depends on the group and the variation.
The list of variations is given below.
Variations for constant data:
Variations for event data:
The flags imply the presence of a special byte with the following information bits: the on-line data source, the data source has been rebooted, the connection to the source has been lost, the value record is forced, the value is outside the allowed limits.
Synchronization - 2 bytes of synchronization, allowing the recipient to identify the beginning of the frame. Length is the number of bytes in the remainder of the packet, not including CRC octets. Connection control - byte to coordinate reception of frame transmission. Destination address is the address of the device to which the transfer is assigned. Source address is the address of the device that is transmitting. CRC is the checksum for the header byte. The data section of the DNP3 frame contains (in addition to the data itself) 2 CRC bytes for every 16 bytes of information transmitted. The maximum number of bytes of data (not including CRC) for a single frame is 250.
Protocol IEC 61850 MMS
MMS (Manufacturing Message Specification) is a protocol for data transmission using client-server technology. The IEC 61350 standard does not describe the MMS protocol. Chapter 6 of IEC 61850-8-1 describes only the procedure for assigning data services described in the IEC 61850 standard to the MMS protocol described in ISO / IEC 9506. In order to better understand what this means, it is necessary to consider in more detail how the IEC standard 61850 describes abstract communication services and for what it is done.
One of the main ideas laid down in IEC 61850 standard is its invariance with time. In order to ensure this, the chapters of the standard consistently describe first the conceptual issues of data transfer within and between power objects, then describes the so-called "abstract communication interface" and only at the final stage describes the purpose of abstract models for data transfer protocols. Thus, the conceptual issues and abstract models are independent of the data transmission technologies used (wired, optical or radio channels), and therefore will not require revision due to progress in data transfer technologies.
The abstract communication interface described in IEC 61850-7-2. includes both a description of device models (that is, it standardizes the concepts of "logical device", "logical node", "control unit", etc.). and the description of data transmission services. One of these services is SendGOOSEMessage. In addition to this service, more than 60 services are described, which standardize the procedure for establishing communication between the client and the server (Associate, Abort, Release), reading the information model (GetServerDirectory, GelLogicalDeviceDirectory, GetLogicalNodeDirectory), reading variable values (GetAllDataValues, GetDataValues, etc.) , transfer of values of variables in the form of reports (Report), and others. Data transfer in the listed services is carried out by technology "client-server".
For example, the server in this case can be a relay protection device, and the client is a SCADA system. Services of reading the information model allow the client to read from the device a complete information model, that is, to recreate the tree from logical devices, logical nodes, elements and data attributes. In this case, the client will receive a complete semantic description of the data and their structure. Services reading the values of variables allow you to read the actual values of the data attributes, for example, the method of periodic polling. Reporting service allows you to configure the sending of certain data when certain conditions are met. One of the variants of such a condition may be a change of one or another kind, associated with one or more elements from the data set. To implement the described abstract models of data transmission, the standard IEC 61850 describes the purpose of abstract models for a specific protocol. For the services under consideration, such a protocol is MMS, as described in the ISO / IEC 9506 standard.
- a set of standard objects over which operations are performed that must exist in the device (for example: reading and writing variables, signaling events, etc.)
- A set of standard messages. which exchanges between the client and the north for the implementation of management operations;
- a set of encoding rules for these messages (that is, how values and parameters are assigned to bits and bytes when forwarded);
- a set of protocols (rules for exchanging messages between devices). Thus, MMS does not define application services, which, as we have already seen, are defined by the IEC 61850 standard. In addition, the MMS protocol itself is not a communication protocol, it only defines messages that must be transmitted over a specific network. As a communication protocol in MMS, the TCP / IP stack is used.
The general structure of the use of the MMS protocol for the implementation of data transmission services in accordance with IEC 61850 is presented below.
Diagram of data transmission by MMS protocol
Such a complex system at first glance, on the face of it, allows us to ensure, on the one hand, the invariability of abstract models (and, consequently, the invariability of the standard and its requirements), on the other hand, to use modern communication technologies based on the IP protocol. However, it should be noted that, due to the large number of destinations, the MMS protocol is relatively slow (for example, compared to GOOSE), so its application for real-time applications is inappropriate. The main purpose of the MMS protocol is the implementation of the ACS TP functions, that is, the collection of telesignal and telemetry data and the transmission of telecontrol commands.
For the purposes of information collection, the MMS protocol provides two main options:
- data collection using periodic interrogation of the server (s) by the client;
- Data transmission to the client by the server in the form of reports (sporadically).
Both of these methods are in demand in the setup and operation of the process control system, in order to determine the areas of their application, we will examine in more detail the working mechanisms of each.
At the first stage, a connection is established between the devices by the client and the server (the "Association" service). The connection is initiated by the client, referring to the server by its IP address.
The mechanism of data transmission "client-server"
The next stage the client requests certain data from the server and receives a response from the server with the requested data. For example, after the connection is established, the client can query the server for its information model using the services GetServerDirectory, GetLogicalDeviceDirectory, GetLogicalNodeDiretory. The requests will be carried out in sequence:
- after a request from GetServerDirectory, the server returns a list of available logical devices.
- after a separate request from GelLogicalDeviceDirectory for each logical device, the server returns a list of logical nodes in each of the logical devices.
- the GetLogicalNodeDirectory query for each individual logical node returns its objects and data attributes.
As a result, the client considers and recreates the complete information model of the server device. In this case, the actual values of the attributes will not be read, that is, the read "tree" will contain only the names of logical devices, logical nodes, data objects and attributes, but without their values. The third step can be to read the actual values of all data attributes. In this case, all attributes can be read using the GetAllDataValues service, or only separate attributes using the GetDataValues service. After the third stage, the client completely recreates the server information model with all data attribute values. It should be noted that this procedure involves the exchange of sufficiently large volumes of information with a large, depending on the number of logical devices logical nodes and the number of data objects implemented by the server, the number of requests and responses. This also leads to a rather high load on the hardware of the device.
These steps can be carried out at the stage of SCADA-system setup in order for the client, considering the information model, to access the data on the server. However, with the further operation of the system, regular reading of the information model is not required. As well as it is inappropriate to constantly read attribute values by the method of regular interrogation. Instead, the Reporting service can be used. IEC 61850 defines two kinds of reports - buffered and unbuffered. The main difference between the buffered report and the unbuffered report is that when using the first one, the generated information will be delivered to the client, even if there is no communication between the server and the client at the time the report is ready (for example, the corresponding communication channel was violated). All the generated information is stored in the device's memory and its transmission will be performed as soon as the communication between the two devices is restored. The only limitation is the amount of server memory allocated for storing reports. If during the time when there was no communication, there were quite a lot of events that caused the formation of a large number of reports, the total volume of which exceeded the permissible amount of server memory, then some information can still be lost and new generated reports will "preempt" the previously generated data from the buffer , but in this case the server, through a special attribute of the control unit, will signal to the client that a buffer overflow occurred and data loss may occur. If the connection between the client and the server is present - whether using a buffered or an unbuffered report - sending data to the client's address can be immediate after the occurrence of certain events in the system (provided that the time interval at which the events are fixed , is equal to zero). When it comes to reports, it means control of not all objects and attributes of the data of the information model of the server, but only those that interest us, combined into so-called "data sets". Using a buffered / unbuffered report, you can configure the server not only to transfer the entire monitored data set, but also to transfer only those data objects / attributes with which certain events occur over a user-defined time interval.
To do this, in the structure of the control unit, the transfer of buffered and unbuffered reports provides the ability to specify the categories of events that need to be monitored and the fact that only the objects / attributes of data that these events have touched will be included in the report. There are the following categories of events:
- change of data (dchg). If you set this parameter, only those data attributes whose values have changed are included in the report, or only those data objects whose attribute values have changed.
- Changing the quality attribute (qchg). If you set this parameter, only those quality attributes whose values have changed are included in the report, or only those data objects whose quality attributes have changed.
- Data update (dupd). If you set this parameter, only those data attributes whose values have been updated will be included in the report, or only those data objects whose attribute values have been updated. Under the update is understood, for example, the periodic calculation of a particular harmonic component and writing the corresponding attribute data of its new value. However, even if the value of the results of calculations in the new period has not changed, the data object or the corresponding data attribute is included in the report.
You can also configure the report to transfer the entire monitored data set. Such transfer can be performed either on the initiative of the server (condition integrity), or at the initiative of the client (general-interrogation). If the formation of data by the condition integrity is entered, then the user also needs to specify the period of data generation by the server. If the formation of data on the general-interrogation condition is entered. the server will generate a report with all elements of the data set upon receipt of the appropriate command from the client.
The reporting mechanism has important advantages over the polling method: the load on the information network is significantly reduced, the load on the server device and the client device is reduced, and rapid reporting of events occurring in the system is provided. However, it is important to note that all the advantages of using buffered and unbuffered reports can be achieved only if they are properly configured, which in turn requires the personnel who perform the equipment setup to have a sufficiently high qualification and extensive experience.
In addition to the described services, the MMS protocol also supports hardware management models-generation and transmission of event logs, as well as file transfer, which allows, for example, to transmit emergency waveform files. These services require separate consideration. The MMS protocol is one of the protocols to which abstract services described in the IEC 61850-7-2 standard can be assigned. At the same time, the appearance of new protocols will not affect the models described by the standard, thus ensuring the standard remains unchanged over time. To assign models and services to the MMS protocol, use chapter IEC 61850-8-1. The MMS protocol provides various mechanisms for reading data from devices, including reading data on demand and sending data as reports from the server to the client. Depending on the problem to be solved, the correct mechanism for data transmission must be selected and its corresponding tuning must be carried out, which will make it possible to effectively apply the entire set of IEC 61850 communication protocols on the power facility.
Protocol IEC 61850 GOOSE
The GOOSE protocol, described in chapter IEC 61850-8-1, is one of the most widely known protocols provided by the IEC 61850 standard. Literally, the GOOSE-Generic Object-Oriented Substation Event abbreviation can be translated as a "general object-oriented event at a substation". However, in practice, one should not attach much importance to the original name, since it does not give any idea of the protocol itself. It is much more convenient to understand the GOOSE protocol as a service intended for the exchange of signals between relay protection devices in digital form.
Generating GOOSE messages
The data model of IEC 61850 specifies that data should be generated in sets - Dataset. Datasets are used to group data that will be sent by the device using the GOOSE message mechanism. In the future, the GOOSE sending control block specifies a reference to the created data set, in which case the device knows which data to send. It should be noted that within one GOOSE message, one value (for example, the start signal of the overcurrent protection) can be sent, as well as several values (for example, the start signal and the trip signal of the overcurrent protection, etc.). The receiving device, at the same time, can extract only the data it needs from the packet. The transmitted GOOSE message packet contains all the current values of the attributes of the data entered in the data set. If you change any of the attribute values, the device instantly initiates sending a new GOOSE message with the updated data.
Sending GOOSE messages
In accordance with its purpose, the GOOSE-message is intended to replace the transmission of discrete signals via the operational current network. Let us consider what requirements are imposed on the data transfer protocol. To develop an alternative to the signal transmission circuits between relay protection devices, the properties of the information transferred between the relay protection devices through discrete signals were analyzed:
- a small amount of information - the values "true" and "false" (or logical "zero" and "one") are actually transmitted between terminals;
- a high data transfer rate is required - most of the discrete signals transmitted between relay protection devices directly or indirectly affect the abnormal mode elimination speed, so the signal transmission should be performed with a minimum delay;
- high probability of message delivery is required - for realization of responsible functions, such as giving a command to disconnect the breaker from relay protection, exchange signals between relay protection and automation devices when performing distributed functions, it is necessary to ensure guaranteed delivery of the message both in the normal operation of the digital data network and in the case of it short-term failures;
- the ability to send messages to several recipients at once - when implementing some distributed functions of the relay protection devices, it is necessary to transfer data from one device to several;
- monitoring of the integrity of the data transmission channel is necessary - the availability of the diagnostics function of the data transmission channel allows to increase the availability factor when transmitting the signal, thereby increasing the reliability of the function performed with the transmission of the indicated message.
The requirements resulted in the development of a GOOSE message mechanism that meets all the requirements. In analogue signal transmission circuits, the main delay in signal transmission is made by the response time of the device's discrete output and the bounce filtering time at the discrete input of the receiving device. The propagation time of the signal along the conductor is small in comparison with this.
Similarly, in digital data transmission networks, the main delay is caused not so much by the signal transmission over the physical medium as by its processing inside the device. In the theory of data transmission networks, it is customary to segment data services in accordance with the OSI model levels, usually descending from the "Applied", that is, the level of application data representation, to the "Physical", that is, the level of physical interaction of the devices. In the classical view, the OSI model has only seven levels: physical, channel, network, transport, session, presentation and applied. However, the implemented protocols may not have all of these levels, that is, some levels can be skipped.
The mechanism of OSI model operation can be visualized on the example of data transmission when viewing WEB-pages on the Internet on a personal computer. The transfer of the contents of the pages to the Internet is carried out via the HTTP (Hypertext Transfer Protocol) protocol, which is an application layer protocol. Transmission of HTTP data is usually carried out by the transport protocol TCP (Transmission Control Protocol). TCP segments are encapsulated in network protocol packets, which in this case is IP (Internet Protocol). TCP packets constitute Ethernet link-layer protocol frames that, depending on the network interface, can be transmitted using a different physical layer. Thus, the data of the page viewed on the Internet passes at least four levels of conversion when forming a sequence of bits on the physical layer, and then as many reverse-conversion steps. Such a number of transformations leads to delays both in the formation of a sequence of bits for the purpose of transmitting them, and in the reverse transformation in order to obtain the transmitted data. Accordingly, to reduce the delay time, the number of transformations must be minimized. That's why data on the GOOSE protocol (application layer) is assigned directly to the data link layer - Ethernet, bypassing other levels.
In general, the head of IEC 61850-8-1 provides two communication profiles, which describe all the data transfer protocols provided by the standard:
- Profile of "MMS";
- "Non-MMS" profile (that is, not-MMS).
Accordingly, data transmission services can be implemented using one of the specified profiles. The GOOSE protocol (as well as the Sampled Values protocol) refers specifically to the second profile. Using a "truncated" stack with a minimum of conversions is an important, but not the only, way to speed up data transfer. The acceleration of data transfer using the GOOSE protocol is facilitated by the use of data prioritization mechanisms. For example, the GOOSE protocol uses a separate Ethernet frame identifier - Ethertype, which has a priori greater priority than the rest of the traffic, for example, transmitted using the IP network layer. In addition to the mechanisms discussed, an Ethernet GOOSE message frame can also be labeled with IEEE 802.1Q priority labels. as well as the labels of virtual LANs of the protocol ISO / IEC 8802-3. Such labels allow to increase the priority of frames when processing them by network switches. More in detail, these mechanisms for increasing the priority will be considered in subsequent publications.
The use of all the methods considered allows us to significantly increase the priority of data transmitted via the GOOSE protocol, compared to other data transmitted on the same network using other protocols, thereby minimizing delays both when processing data inside source devices and data receivers, so and when processing them by network switches.
Sending information to multiple recipients
To address the frames at the link level, physical addresses of network devices - MAC addresses are used. At the same time, Ethernet allows to carry out the so-called multicast messages (Multicast). In this case, the address of the group distribution is specified in the MAC address field of the addressee. For multicast mailings using the GOOSE protocol, a certain range of addresses is used.
Range of multicast addresses for GOOSE messages
Messages that have a value of "01" in the first octet of the address are sent to all the physical interfaces on the network, so in fact, multicast does not have fixed destinations, and its MAC address is more likely the identifier of the mailing itself, and does not point directly to its recipients.
Thus, the MAC address of a GOOSE message can be used, for example, when organizing a message filtering on a network switch (MAC-filtering), and the address can serve as an identifier to which the receiving devices can be configured.
Thus, the transmission of GOOSE messages can be compared to a radio broadcast: the message is broadcast to all devices on the network, but to receive and then process the message, the receiving device must be configured to receive this message.
The GOOSE messaging scheme
The transmission of messages to multiple recipients in the Multicast mode, as well as the requirements for high data transfer speed, do not allow receiving the confirmation of delivery from the recipients when sending GOOSE messages. The procedure for sending data, for the receiving device to receive confirmation, receiving and processing it by the sender, and then re-sending in the event of an unsuccessful attempt would take too long, which could lead to excessive delays in the transmission of critical signals. In the place of this for GOOSE-messages was implemented a special mechanism that provides high probability of data delivery.
First, in the absence of changes in the transmitted attributes of data, packets with GOOSE-messages are transmitted cyclically through a user-defined interval. Cyclic transfer of GOOSE-messages allows you to constantly diagnose the information network. A device configured to receive a message expects it to arrive at specified intervals. In case the message does not arrive during the waiting time, the receiving device can generate a fault signal in the information network, thus informing the dispatcher of the problems that have occurred.
Secondly, if one of the attributes of the transmitted data set is changed, regardless of how long it has been since the previous message was sent, a new packet is created that contains the updated data. After that, the sending of this packet is repeated several times with the minimum time delay, then the interval between messages (in the absence of changes in the transmitted data) again increases to the maximum.
The interval between sending GOOSE messages
Thirdly, in the GOOSE-message package there are several fields-counters, for which the integrity of the communication channel can also be controlled. Such counters, for example, include a cyclic parcel counter (sqNum), whose value changes from 0 to 4,294,967,295 or until the data is changed. With each change in the data transmitted in the GOOSE message, the sqNum counter will be reset, and it will also be incremented by 1 other counter, stNum, also cyclically varying from 0 to 4 294 967 295. Thus, if several packets are lost during transmission, This loss can be traced by the two specified counters.
Finally, fourthly, it is also important to note that in the sending GOOSE, in addition to the value of the discrete signal itself, it can also contain a sign of its quality, which identifies a certain hardware failure of the source device, finding the information source device in the test mode and a number of other non-standard modes. Thus, the receiver device, before processing the received data according to the provided algorithms, can perform a check of this quality characteristic. The specified can prevent the incorrect operation of information-receiving devices (for example, their false operation).
It should be borne in mind that some of the inherent mechanisms for ensuring the reliability of data transmission when they are misused can lead to a negative effect. So, in the case of selecting a very short maximum interval between messages, the load on the network increases, although, from the standpoint of availability of the communication channel, the effect of reducing the transmission interval will be extremely small.
When data attributes are changed, transmission of packets with a minimum time delay causes an increased load on the network ("information storm" mode), which theoretically can lead to delays in data transmission. Such a mode is the most difficult and should be taken for design when designing an information network. However, it should be understood that the peak load is very short-lived and its multiple decrease, according to our experiments in the laboratory for the study of the interoperability of devices operating under the conditions of the IEC 61850 standard, is observed at an interval of 10 ms.
The construction of RPA systems based on the GOOSE protocol changes the procedures for their adjustment and testing. Now the setup phase consists in the organization of the Ethernet network of the power facility. which will include all devices of relay protection and automation devices. between which you need to exchange data. To verify that the system is configured and enabled in accordance with the project requirements, it is possible to use a personal computer with special preinstalled software (Wireshak, GOOSE Monitor, etc.) or special testing equipment supporting the GOOSE protocol (PETOM 61850. Omicron CMC). It is important to note that all checks can be made without disrupting the pre-established connections between the secondary equipment (relay protection devices, switches, etc.), since the data is exchanged over an Ethernet network. When exchanging discrete signals between relay protection devices in the traditional way (by applying voltage to the discrete input of the receiving device when the output contact of the device transmitting the data is closed), on the contrary, it is often necessary to disconnect the connections between the secondary equipment for inclusion in the test circuit circuit in order to check the electrical connections and transmission of the corresponding discrete signals. Thus, the GOOSE protocol provides for a whole range of measures aimed at providing the necessary performance characteristics and reliability in the transmission of critical signals. Application of this protocol in combination with the correct design and parameterization of the information network and relay protection devices allows in some cases to abandon the use of copper circuits for signal transmission, while ensuring the necessary level of reliability and speed.
Testing of Goose Protocol of IEC61850 Standard in Protection IED
Summary of GOOSE Substation Communication
A technique for analysing GOOSE packets when testing relays in an IEC 61850-8-1 environment
A Detailed Analysis of the GOOSE Message Structure in an IEC61850
Standard-Based Substation Automation System
INTERNATIONAL STANDARD 60870-5-104
TECHNICAL REPORT IEC/TR61850-1
TECHNICAL SPECIFICATION IEC TS 61850-2
INTERNATIONAL STANDARD 61850-3
INTERNATIONAL STANDARD 61850-4
INTERNATIONAL STANDARD 61850-5
INTERNATIONAL STANDARD 61850-6
INTERNATIONAL STANDARD 61850-7-1
INTERNATIONAL STANDARD 61850-7-2
INTERNATIONAL STANDARD 61850-7-3
INTERNATIONAL STANDARD 61850-7-4
INTERNATIONAL STANDARD 61850-8-1
INTERNATIONAL STANDARD 61850-9-2
INTERNATIONAL STANDARD 61850-10
Technical Report Description and analysis of IEC 104 Protocol
TECHNICAL REPORTIEC TR 61850-90-6
Author: Timofey Busygin (Moscow Power Engineering Institute)
#MMS, #GOOSE, #SV, #870-104, #event, #protocol, #exchangeRussian version