Event protocols

Event protocol - in your own words

If we consider the classroom allegory, which fits well, then cyclic protocols like Modbus, Profibus, Fieldbus are like asking each of the students in sequence. Even if there is no interest in the device (student). Event protocols work differently. There is a request not to each network device (student) in sequence, but to the class as a whole, then information is collected from the device with a changed state (the student who raised his hand). Thus, there is a strong savings in network traffic. Network devices do not accumulate errors when the connection is poor. Considering that the event is delivered with a timestamp, even if there is some delay, the bus master receives information about the events that have occurred on remote objects.

Event protocols are mainly used at electric power facilities, as well as remote control systems of various lock and watershed systems. Such protocols are used where remote dispatching and control of objects that are very remote from each other or in Smart Home systems are needed.

The history of the development and implementation of event protocols in the automation of power 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; it is being developed by the non-profit organization ModBus-IDA. Despite the fact that ModBus belongs to the protocols of the application layer of the OSI network model and regulates the functions of reading and writing registers, the correspondence of registers to measurement types and measurement channels is not regulated. In practice, this leads to incompatibility of protocols for devices of different types, even from the same manufacturer, and the need to support a large number of protocols and their modifications by the built-in software of the USPD (with a two-level polling model - software of the collection server) with limited reuse of the program code. Given the selective adherence to standards by manufacturers (the use of ad hoc algorithms for calculating the checksum, changing the byte order, etc.), the situation is aggravated even more.

Today, 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, is designed to provide, as stated on the official website of the association, "an interoperable environment for structural modeling and data exchange with the controller" . The specification separates the logical model and physical representation of specialized equipment, and also defines the most important concepts (register, profile, schedule, etc.) and operations on them. The main standard is IEC 62056-21, which replaced the second edition of IEC 61107.
Despite a more detailed elaboration of the device representation model and its functioning compared to ModBus, the problem of completeness and "purity" of the implementation of the standard, unfortunately, has remained. In practice, polling a device with declared support for DLMS from one manufacturer by a polling program from another manufacturer is either limited by basic parameters or simply impossible. It should be noted that the DLMS specification, unlike the ModBus protocol, turned out to be extremely unpopular among domestic manufacturers of metering devices, primarily due to the greater complexity of the protocol, as well as additional overhead for establishing a connection and obtaining a device configuration.
The completeness of the support of existing standards by manufacturers of measuring and control equipment is not sufficient to overcome the intra-system information disunity. The support declared by the manufacturer for a particular standardized protocol, as a rule, does not mean its full support and the absence of changes introduced. An example of a complex of foreign standards is the IEC 60870-5 family of standards created by the International Electrotechnical Commission.
Various implementations of IEC 60870-5-102 - a generalizing standard for the transmission of integral parameters in power systems - are presented in devices from a number of foreign manufacturers: Iskraemeco d.d. (Slovenia), Landis&Gyr AG (Switzerland), Circutor SA (Spain), EDMI Ltd (Singapore) and others, but in most cases only as additional ones. Proprietary protocols or variations of DLMS are used as the main data transfer protocols. It is worth noting that IEC 870-5-102 has not yet become widespread due to the fact that some manufacturers of metering devices, including domestic ones, have implemented modified telemechanical protocols in their devices (IEC 60870-5-101, IEC 60870-5 -104), ignoring the given standard.

A similar situation is observed among RPA manufacturers: in the presence of the current IEC 60870-5-103 standard, 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 IEC 60870-5-101 and IEC 60870-5-104 standards can be used if it is necessary to integrate telemechanics and electricity metering systems. In this regard, they are widely used in dispatching systems..
Technical specifications for automation protocols
In modern automation systems, as a result of constant modernization of production, the tasks of building distributed industrial networks using event-based data transfer protocols are increasingly encountered. To organize 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 (IM), communications of the lower and upper levels of automated process control systems.
Protocols are developed taking into account the peculiarities 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 environments, functional capabilities, flexibility in construction, ease of integration and maintenance, and compliance with industry standards are becoming more and more important requirements in APCS systems. 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 IEC 60870-5-101 ASDU into standard TCP/IP networks. Both Ethernet and modem connections are supported using the PPP protocol. Cryptographic data security is formalized in the IEC 62351 standard. Standard TCP port 2404.
This standard defines the use of an open TCP/IP interface for a network containing, for example, a LAN (local area network) for a telecontrol device that transmits an ASDU in accordance with IEC 60870-5-101. Routers including routers for WAN (wide area network) of various types (for example, X.25, relay frame, ISDN, etc.) can be connected through a common TCP/IP-LAN interface.

An example of a general application architecture for IEC 60870-5-104.

The transport layer interface (interface between user and TCP) is a flow-oriented interface that does not define any start-stop mechanisms for ASDU (IEC 60870-5-101). To define the start and end of an ASDU, each APCI header includes the following tokens: a start character, an indication of the length of the ASDU, along with a control field. Either the full APDU or (for management purposes) only the APCI fields may be sent.

IEC 60870-5-104 protocol data packet structure

Wherein:

- APCI - Application Layer Control Information;
- ASDU - Data Block. Served by the Application Layer (Application Data Block);
- APDU - Application Protocol Data Unit.
- START 68 H defines the start point within the data stream.
The APDU length specifies the length of the APDU body, which consists of four bytes of the APCI control field plus the ASDU. The first byte to count is the first byte of the control field, and the last byte to count is the last byte of the ASDU. The maximum ASDU length is limited to 249 bytes. the maximum value of the APDU field length is 253 bytes (APDUmax=255 minus 1 start byte and 1 length byte), and the length of the control field is 4 bytes.
This data transfer protocol, at the moment, is de facto the standard dispatching protocol for enterprises in the electric power sector. The data model in this standard is developed more seriously, however, it does not provide any unified description of the power facility..

Protocol DNP-3

DNP3 (Distributed Network Protocol) is a data transfer protocol used for communication between ICS components. It was designed for easy interaction between various types of devices and control systems. It can be used at various levels of automated process control systems. There is a Secure Authentication extension for DNP3 for secure authentication.
In Russia, this standard is not widely distributed, but some automation devices still support it. For a long time the protocol was not standardized, but now it is approved as an IEEE-1815 standard. DNP3 supports both RS-232/485 serial links and TCP/IP networks. The protocol describes three layers of the OSI model: application, data link, and physical. Its distinguishing feature is the ability to transfer data both from master to slave and between slaves. DNP3 also supports sporadic data transfer from slave devices. The transmission of data is based, as in the case of IEC-101/104, on the principle of transmitting a table of values. At the same time, in order to optimize the use of communication resources, not the entire database is sent, but only its variable part.
An important difference between the DNP3 protocol and those considered earlier is an attempt to describe the object data model and the independence of data objects from 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 ways to retrieve data) and physical (in most cases, RS-232 and RS-485 interfaces are used). Each device has its own unique address for that network, represented as an integer from 1 to 65520. Basic terms:
- Outslation - slave device.
- Master - ведущее устройство.
- Frame (фрэйм) - packets transmitted and received at the link layer. Maximum packet size 292 bytes.
- Static data (fixed data) - data associated with some real value (for example, a discrete or analog signal)
- Event data (event data) - data associated with some significant event (for example, state changes, reaching a threshold value). Provides the ability to attach a timestamp.
- Variation (variation) - determines how the value is interpreted, characterized by an integer.
- Group (group) - defines the type of value, characterized by an integer (for example, a constant analog value belongs to group 30, and an 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 some particular value. The object format depends on the group and 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 data source is on-line, the data source has been reloaded, the connection to the source has been lost, the value writing has been forced, the value is out of range. 

Frame title:

Synchronization - 2 bytes of synchronization, allowing the receiver to identify the beginning of the frame. Length - the number of bytes in the rest of the packet, excluding CRC octets. Connection control - a byte for coordinating the reception of a frame transmission. Destination address - the address of the device to which the transfer is assigned. Source address - the address of the transmitting device. CRC - checksum for header byte. The data section of a DNP3 frame contains (in addition to the data itself) 2 CRC bytes for every 16 bytes of information transmitted. The maximum number of data bytes (not including CRC) for one frame is 250.

Protocol IEC 61850 MMS

MMS (Manufacturing Message Specification) is a data transfer protocol using client-server technology. The IEC 61350 standard does not describe the MMS protocol. The IEC 61850-8-1 chapter only describes how to assign the data services described in IEC 61850 to the MMS protocol described in ISO/IEC 9506. In order to better understand what this means, it is necessary to take a closer look at how the IEC standard 61850 describes abstract communication services and why they are made.
One of the main ideas behind the IEC 61850 standard is its persistence over time. In order to ensure this, the chapters of the standard sequentially describe first the conceptual issues of data transfer within and between power facilities, then the so-called “abstract communication interface” is described, and only at the final stage the assignment of abstract models to data transfer protocols is described.

Thus, conceptual issues and abstract models turn out to be independent of the used data transmission technologies (wire, optical or radio channels), therefore, they will not require revision caused by progress in the field of data transmission technologies.
The abstract communication interface described by IEC 61850-7-2. includes both a description of device models (that is, it standardizes the concepts of “logical device”, “logical node”, “control block”, etc.). and the description of data services. One such service is SendGOOSEMessage. In addition to the specified service, more than 60 services are described that 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 variable values ​​in the form of reports (Report) and others. Data transfer in the listed services is carried out using the "client-server" technology.

For example, in this case, a relay protection device can act as a server, and a SCADA system can act as a client. Information model reading services allow the client to read the complete information model from the device, that is, to recreate a tree from logical devices, logical nodes, data elements and attributes. In this case, the client will receive a complete semantic description of the data and its structure. Services for reading variable values ​​allow you to read the actual values ​​of data attributes, for example, using the method of periodic polling. The reporting service allows you to configure the sending of certain data when certain conditions are met. One variation of such a condition could be a change of some kind associated with one or more elements from the dataset. To implement the described abstract data transfer models, the IEC 61850 standard describes the assignment of abstract models to a specific protocol. For the services under consideration, such a protocol is MMS, described by the ISO/IEC 9506 standard..

MMS defines:
- a set of standard objects on which operations are performed that must exist in the device (for example: reading and writing variables, signaling events, etc.),
- set of standard messages. which are exchanged between the client and the server for the implementation of management operations;
- a set of rules for encoding these messages (that is, how values and parameters are assigned to bits and bytes when sent);
- a set of protocols (message exchange rules 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 should be transmitted over a certain network. MMS uses the TCP/IP stack as the communication protocol.

The general structure of the application of the MMS protocol for the implementation of data services in accordance with IEC 61850 is presented below.

Diagram of data transfer via MMS protocol

Such a rather complex, at first glance, system ultimately allows, on the one hand, to ensure the immutability of abstract models (and, consequently, the immutability 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 assignments, the MMS protocol is relatively slow (eg compared to GOOSE), so it is not practical for real-time applications. The main purpose of the MMS protocol is the implementation of the APCS functions, that is, the collection of telesignaling and telemetry data and the transmission of telecontrol commands.
For information gathering purposes, the MMS protocol provides two main options:
- data collection using periodic polling of the server(s) by the client;
- transmission of data to the client by the server in the form of reports (sporadically).
Both of these methods are in demand during the adjustment and operation of the automated process control system, to determine the areas of their application, we will consider in more detail the mechanisms of operation of each.
At the first stage, a connection is established between the client and server devices (the “Association” service). The connection is initiated by the client by contacting the server at its IP address.

Data transfer mechanism "client-server"

In the next step, the client requests certain data from the server and receives a response from the server with the requested data. For example, after a connection is established, a client can query the server for its information model using the services GetServerDirectory, GetLogicalDeviceDirectory, GetLogicalNodeDiretory. Requests will be processed sequentially:
- after a GetServerDirectory request, the server will return a list of available logical devices.
- after a separate request for GelLogicalDeviceDirectory for each logical device, the server will return a list of logical nodes in each of the logical devices.
- a 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 yet, 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 may be to read the actual values ​​of all data attributes. In this case, either all attributes can be read using the GetAllDataValues ​​service, or only individual attributes using the GetDataValues ​​service. Upon completion of the third stage, the client will completely recreate the information model of the server with all the values ​​of the data attributes. It should be noted that this procedure involves the exchange of sufficiently large amounts of information with a large number of requests and responses, depending on the number of logical units of logical nodes and the number of data objects implemented by the server. This also leads to a rather high load on the hardware of the device. These stages can be carried out at the stage of setting up a SCADA system so that the client, having read the information model, can access the data on the server. However, during further operation of the system, regular reading of the information model is not required. As well as it is inexpedient to constantly read attribute values ​​by a method of regular interrogation. Instead, the Report service can be used. IEC 61850 defines two types of reports - buffered and unbuffered. The main difference between a buffered report and a non-buffered one is that when using the former, the generated information will be delivered to the client even if, at the time the server is ready to issue the report, there is no connection between it and the client (for example, the corresponding communication channel was broken). All generated information is accumulated in the device's memory and its transfer will be performed as soon as the connection between the two devices is restored. The only limitation is the amount of server memory allocated for storing reports. If during the period of time when there was no connection, a lot of events occurred that caused the formation of a large number of reports, the total volume of which exceeded the allowable amount of server memory, then some information may still be lost and new generated reports will “crowd out” previously generated data from the buffer , however, in this case, the server, through a special attribute of the control block, will signal to the client that a buffer overflow has occurred and data may be lost. If there is a connection between the client and the server - both when using a buffered report and when using an unbuffered report - data transfer to the client address can be immediate upon the occurrence of certain events in the system (provided that the time interval for which events are recorded , equals zero). When it comes to reports, it does not imply control of all objects and data attributes of the server information model, 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 controlled data set, but also to transfer only those data objects/attributes with which certain types of events occur within a user-defined time interval.
To do this, in the structure of the control block for the transmission of buffered and non-buffered reports, it is possible to specify the categories of events, the occurrence of which must be controlled and, upon the fact of which, only those data objects / attributes affected by these events will be included in the report. There are the following categories of events:
- data change (dchg). When this option is set, the report will include only those data attributes whose values have changed, or only those data objects whose attribute values have changed..
- quality attribute change (qchg). When this option is set, only those quality attributes whose values have changed, or only those data objects whose quality attributes have changed, will be included in the report..
- data update (dupd). When this option is set, only those data attributes whose values have been updated, or only those data objects whose attribute values have been updated, will be included in the report. An update means, for example, the periodic calculation of one or another harmonic component and the entry of its new value into the corresponding data attribute. However, even if the value has not changed as a result of calculations in the new period, the data object or the corresponding data attribute is included in the report.
You can also configure the report to report the entire monitored dataset. Such a transfer can be performed either at the initiative of the server (the integrity condition), or at the initiative of the client (general-interrogation). If the formation of data according to the integrity condition is entered, then the user also needs to specify the period of data formation by the server. If data generation by the general-interrogation condition is entered. the server will generate a report with all elements of the data set upon receipt of the corresponding command from the client.
The reporting mechanism has important advantages over the periodic polling method: the load on the information network is significantly reduced, the load on the processor of the server device and the client device is reduced, and fast delivery of messages about events occurring in the system is ensured. However, it is important to note that all the advantages of using buffered and non-buffered reports can only be achieved if they are properly configured, which, in turn, requires sufficiently high qualifications and extensive experience from the personnel performing the equipment setup.
In addition to the services described, the MMS protocol also supports equipment control models - the generation and transmission of event logs, as well as file transfer, which allows you to transfer, for example, files of emergency waveforms. These services require separate consideration. The MMS protocol is one of the protocols to which the abstract services described in IEC 61850-7-2 can be assigned. At the same time, the emergence of new protocols will not affect the models described by the standard, thus ensuring that the standard remains unchanged over time. The IEC 61850-8-1 chapter is used to assign models and services to the MMS protocol. The MMS protocol provides various mechanisms for reading data from devices, including reading data on demand and transmitting data in the form of reports from the server to the client. Depending on the task to be solved, the correct data transmission mechanism must be selected and its corresponding configuration must be performed, which will allow the entire set of communication protocols of the IEC 61850 standard to be effectively applied at the power facility.

Protocol IEC 61850 GOOSE

The GOOSE protocol, described in the IEC 61850-8-1 chapter, is one of the most widely known protocols provided for by the IEC 61850 standard. Literally, the abbreviation GOOSE - Generic Object-Oriented Substation Event - can be translated as "general object-oriented substation event". However, in practice, one should not attach much importance to the original name, since it does not give any idea about the protocol itself. It is much more convenient to understand the GOOSE protocol as a service designed to exchange signals between RPA devices in digital form.

Generation of GOOSE messages

The data model of the IEC 61850 standard indicates that the data should be formed into sets - Dataset. Data sets are used to group data that will be sent by the device using the GOOSE message mechanism. Later, in the GOOSE send control block, a link to the created data set is indicated, in which case the device knows which data to send. It should be noted that within one GOOSE message, both one value (for example, an overcurrent start signal) and several values can be sent simultaneously (for example, a start signal and an overcurrent trip signal, etc.). The receiving device, in this case, can extract from the packet only the data that it needs. The transmitted GOOSE message packet contains all the current values of the data attributes entered in the dataset. When any of the attribute values change, the device immediately initiates the sending of a new GOOSE message with updated data.

GOOSE messaging

According to its purpose, the GOOSE message is intended to replace the transmission of discrete signals over the control current network. Consider what requirements are imposed on the data transfer protocol. To develop an alternative to signal transmission circuits between relay protection devices, the properties of information transmitted between relay protection devices by means of discrete signals were analyzed:
- малый объем информации - между терминалами фактически передаются значения «true" and "false" (or logical "zero" and "one");
- high information transfer rate is required - most of the discrete signals transmitted between RPA devices directly or indirectly affect the rate of elimination of the abnormal mode, therefore, the signal transmission must be carried out with a minimum delay;
- a high probability of message delivery is required - to implement critical functions, such as issuing a command to open the circuit breaker from the RPA, exchanging signals between the RPA when performing distributed functions, it is required to ensure guaranteed message delivery both in the normal mode of operation of the digital data transmission network, and in the case of its short-term failures;
- the ability to send messages to several recipients at once - when implementing some distributed relay protection functions, it is required to transfer data from one device to several at once;
- it is necessary to control the integrity of the data transmission channel - the presence of a diagnostic function for the state of the data transmission channel allows you to increase the availability factor during signal transmission, thereby increasing the reliability of the function performed with the transmission of the specified message.
These requirements led to the development of a GOOSE message mechanism that meets all the requirements. In analog signal transmission circuits, the main delay in signal transmission is introduced by the response time of the discrete output of the device and the debounce filtering time at the discrete input of the receiving device. The propagation time of the signal along the conductor is short in comparison.
Similarly, in digital data networks, the main delay is introduced not so much by signal transmission over the physical medium as by its processing within the device. In the theory of data networks, it is customary to segment data services in accordance with the levels of the OSI model, as a rule, descending from the "Applied", that is, the level of application data presentation, to the "Physical", that is, the level of physical interaction of devices. In the classical view, the OSI model has only seven layers: physical, data link, network, transport, session, presentation and application layers. However, the implemented protocols may not have all of the specified levels, i.e. some levels may be skipped.
The mechanism of operation of the OSI model can be visualized using the example of data transfer when viewing WEB pages on the Internet on a personal computer. The transfer of page content to the Internet is carried out using the HTTP (Hypertext Transfer Protocol), which is an application layer protocol. HTTP protocol data transfer is usually carried out by the TCP (Transmission Control Protocol) transport protocol. TCP protocol segments are encapsulated into network protocol packets, which in this case is IP (Internet Protocol). TCP protocol packets make up Ethernet link layer protocol frames, which, depending on the network interface, can be transmitted using a different physical layer. Thus, the data of the viewed page on the Internet goes through at least four levels of transformation when forming a sequence of bits at the physical level, and then the same number of steps of inverse transformation. Such a number of conversions leads to delays both in the formation of a sequence of bits in order to transmit them, and in the reverse conversion in order to receive the transmitted data. Accordingly, to reduce the delay time, the number of conversions should be kept to a minimum. That is why the GOOSE (application layer) protocol data is assigned directly to the link layer - Ethernet, bypassing the other layers.
In general, the IEC 61850-8-1 chapter provides two communication profiles that describe all the data transfer protocols provided for by the standard.:
- MMS Profile;
- "Non-MMS" profile (that is, non-MMS).

Accordingly, data services may be implemented using one of these profiles. The GOOSE protocol (as well as the Sampled Values protocol) belongs to the second profile. Using a "shortened" stack with a minimum number of conversions is an important, but not the only, way to speed up data transfer. Also, the use of data prioritization mechanisms contributes to the acceleration of data transfer via the GOOSE protocol. So, for the GOOSE protocol, a separate Ethernet frame identifier is used - Ethertype, which has a obviously higher priority than other traffic, for example, transmitted using the IP network layer. In addition to the mechanisms discussed, the frame of an Ethernet GOOSE message can also be provided with IEEE 802.1Q protocol priority tags. as well as ISO/IEC 8802-3 VLAN labels. Such labels allow you to increase the priority of frames when they are processed by network switches. These priority escalation mechanisms will be discussed in more detail in subsequent publications.
The use of all the considered methods allows to significantly increase the priority of data transmitted via the GOOSE protocol compared to the rest of the data transmitted over the same network using other protocols, thereby minimizing delays both in the processing of data within the devices of data sources and receivers, and and when processing them by network switches.

Sending information to multiple recipients

To address frames at the link layer, the physical addresses of network devices are used - MAC addresses. At the same time, Ethernet allows the so-called group distribution of messages (Multicast). In this case, the destination MAC address field contains the multicast address. GOOSE multicasts use a specific range of addresses.

Multicast address range for GOOSE messages

Messages that have the value "01" in the first octet of the address are sent to all physical interfaces on the network, so in fact multicast has no fixed destinations, and its MAC address is more of an identifier for the broadcast itself, and does not directly indicate its recipients.

Thus, the MAC address of a GOOSE message can be used, for example, when organizing message filtering on a network switch (MAC filtering), and the specified address can also serve as an identifier to which receiving devices can be configured.
Thus, the transmission of GOOSE messages can be compared to radio broadcasting: the message is broadcast to all devices on the network, but in order to receive and further process the message, the receiving device must be configured to receive this message.

GOOSE messaging scheme

The transmission of messages to several recipients in the Multicast mode, as well as the requirements for a high data transfer rate, do not allow receiving delivery confirmations from recipients when transmitting GOOSE messages. The procedure for sending the data, generating an acknowledgment by the receiving device, receiving and processing it by the sending device, and then resending it in the event of an unsuccessful attempt would take too much time, which could lead to excessively large delays in the transmission of critical signals. Instead, a special mechanism was implemented for GOOSE messages, which provides a high probability of data delivery..

First, in the absence of changes in the transmitted data attributes, packets with GOOSE messages are transmitted cyclically at a user-defined interval. The cyclic transmission of GOOSE messages allows you to constantly diagnose the information network. A device configured to receive a message waits for it to arrive at specified intervals. If the message has not arrived within the waiting time, the receiving device can generate a signal about a malfunction in the information network, thus notifying the dispatcher about the problems that have arisen.
Secondly, when one of the attributes of the transmitted data set changes, regardless of how much time has passed since the previous message was sent, a new packet is formed that contains the updated data. After that, sending this packet is repeated several times with a minimum time delay, then the interval between messages (in the absence of changes in the transmitted data) again increases to the maximum.

Interval between sending GOOSE messages

Thirdly, the GOOSE message packet contains several counter fields, which can also be used to control the integrity of the communication channel. Such counters, for example, include the cyclic counter of parcels (sqNum), the value of which varies from 0 to 4,294,967,295 or until the transmitted data changes. With each change in the data transmitted in the GOOSE message, the sqNum counter will be reset, also increasing by 1 other counter - stNum, also cyclically changing in the range from 0 to 4 294 967 295. Thus, if several packets are lost during transmission, this loss can be tracked by two specified counters.

Finally, fourthly, it is also important to note that in addition to the value of the discrete signal, the GOOSE message may also contain a sign of its quality, which identifies a certain hardware failure of the information source device, the fact that the information source device is in testing mode, and a number of other abnormal modes. Thus, the receiver device, before processing the received data according to the provided algorithms, can check this quality attribute. This can prevent incorrect operation of information receiver 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, if used incorrectly, can lead to a negative effect. So, if the maximum interval between messages is chosen too short, the load on the network increases, although, from the point of view of the availability of the communication channel, the effect of reducing the transmission interval will be extremely insignificant.
When data attributes change, the 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. This mode is the most complex and should be taken as a calculated one when designing an information network. However, it should be understood that the peak load is very short-term 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.
When building relay protection and automation systems based on the GOOSE protocol, the procedures for their adjustment and testing are changed. Now the adjustment stage is to organize the Ethernet network of the power facility. which will include all RPA devices. between which data must be exchanged. To check that the system is configured and enabled in accordance with the requirements of the project, it becomes possible to use a personal computer with special pre-installed software (Wireshak, GOOSE Monitor, etc.) or special test equipment supporting the GOOSE protocol (PETOM 61850. Omicron CMC). It is important to note that all checks can be performed without breaking the pre-established connections between the secondary equipment (relay protection devices, switches, etc.), since data is exchanged via the Ethernet network. When exchanging discrete signals between RPA devices in the traditional way (by applying voltage to the discrete input of the receiver device when the output contact of the device transmitting data is closed), on the contrary, it is often necessary to break the connections between the secondary equipment in order to include them in the test circuit in order to check the correctness of the electrical connections and transmission of the corresponding discrete signals. Thus, the GOOSE protocol provides for a whole range of measures aimed at ensuring the necessary characteristics for speed and reliability in the transmission of critical signals. The use of this protocol in combination with the correct design and parameterization of the information network and RPA devices allows in some cases to abandon the use of copper circuits for signal transmission, while ensuring the required level of reliability and speed.

Download ГОСТ 61850 international standarts you can follow the link

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