**7. IEC 61850 GOOSE Based HIL testing**

IEC 61850 GOOSE is one of the enabling communication protocol of the standard. Its concept to replace the legacy interlocking hard-wired signal. According to GOOSE implementation, it publishes number of fast GOOSE messages from the original message in case of event occur to increase the reliability that one copy of these messages reach its destination. GOOSE assigned with the high priority (4). On the other hand, IEDs within the SAS need to be configured based on the publisher GOOSE messages parameters in order to successfully subscriber to the GOOSE messages.

GOOSE supports wide range of possible common data that can be integrated within the GOOSE dataset (binary and analog measured values). IEC 61850–7-1 part defines the GOOSE protocol where several parameters control the publishing process as follows;

DataSet: Contains ObjectReferences that the values of the members shall be transmitted by GOOSE Control Block (GoCB).

GoEna: To remotely enable/disable the publishing of the GOOSE messages.

AppID: Associated in the GOOSE messages to be used as identifier of the LOGICAL-DEVICE and a handler for subscription to different GOOSE messages from different IEDs in the same time.

ConRev: Contains the configuration revision indicate the changing updating in the data set within the GoCB.

T (time stamp): Contains the time when the attribute StNum was incremented.

StNum: State number containing a counter that is incremented each time when data set member value change is detected and the GOOSE message has been published.

SqNum: Sequence number contains counter that each time increments when GOOSE message has been published.

GoRef: The reference for the GOOSE control block.

Test: Indicates the implementing of the values of the message based on TRUE (testing purpose) or FALSE (operation purpose).

NdsCom: Needs commissioning, indicates that the GoCB requires further configuration [15].

As the GOOSE protocol is flexible and reliable based on serving different parameters that support different applications in which that compatible with the different application requirements and different data types [16]. At this point, and based on the IEC 61850 GOOSE high reliability and flexibility it is common natural to pursue *Advanced Communication and Control Methods for Future Smart Grid DOI: http://dx.doi.org/10.5772/intechopen.96596*

smart energy system application based on IEC 61850 communication protocols e.g. LoM smart application. Therefore, along with testing steps for the proposed LoM smart protection application based GOOSE, different IEC 61850 IEDs need to be designed and configured for implementing the publishing and subscription role. At the IED GOOSE different subscribers the execution of the final smart LoM protection decision making functions are done and the new status need to be publish with other GOOSE message back to the real time simulator. More details about the smart LoM protection distributed decision making algorithm was published in our previous work.

### **8. The round trip GOOSE latency**

The flexible GOOSE model is used by all of the state-of-the-art IEC 61850 IEDs and systems. From the GOOSE implementation point view, the publisher write the GOOSE parameter value in the local buffer, while the subscriber read the value from the local buffer. The subscriber local buffer is continuously updated via the communication system, were within the publisher side in order to control the procedure the GSE control class is used.

GOOSE round trip latency is calculated for different designed IEDs in different tests. One of the main objective of this test is to verify the GOOSE performance that the messages was compliant with the IEC 61850 requirement (not exceed 4 ms), as well as, to verify and ensuring the interoperability that the designed IEDs had the ability to operate within the multi-vendor environment.

In order to compare the GOOSE round trip latency for different designed IEDs, as well as for the commercial IEDs instantaneous GOOSE round trip latency is measured. From (1) GOOSE overall round trip latency time includes seven individual times that may affect the connection channel performance. The first individual time is the real-time model running in the target that publish GOOSE messages to the communication network, next is the communication network latency which is the needed time to deliver the message to the DUTs. Then every DUT that subscribe to the GOOSE message need to extract and computes the new status and then periodically publishes a GOOSE message to the communication network back to the real time simulator. This process was monitored by using a network protocol analyzer, Wireshark.

$$
\overline{t}\_{\text{RTT}} = \overline{t}\_{\text{out},} \ + \overline{t}\_{\text{net}} + \overline{t}\_{\text{in},} \ + \overline{t}\_{\text{app}} + \overline{t}\_{\text{out},} \ + \overline{t}\_{\text{net}} + \overline{t}\_{\text{in}}, \tag{1}
$$

where

*RTT t* : round trip time average,

, : *out Target t* out from the target time average,

*net t* : communication network time average,

*in DUT* , *t* : DUT time average,

*app t* : DUT internal application average time,

*out DUT* , *t* : DUT, out time average,

*out Target* , *t* : target out time average.

In our proposed LoM case study GOOSE round-trip time between Opal-rt simulator as a publisher and different IEDs as a subscribers and publishers had been recorded by IEDScout GOOSE recording feature as illustrated in **Figure 4**. Recording file is opened by the Siemens SIGRA fault analyzer tool as illustrated in **Figure 5**. From **Figure 5** GOOSE round trip time can be measured based on the difference between IED1 GOOSE and IED2 and IED3 responses. This GOOSE roundtrip time includes all the seven individual times included in the equations above.


**Figure 4.** *GOOSE recording application.*

**Figure 5.** *Recorded signal in Sigra fault analyzer tool.*

*Advanced Communication and Control Methods for Future Smart Grid DOI: http://dx.doi.org/10.5772/intechopen.96596*
