Advanced Communication and Control Methods for Future Smart Grid

Abstract

The reliability of intelligent electronic device (IED) function that ensures a particular disturbance will disconnect as fast enough from the healthy network to mitigate the effect of the fault is directly related to the reliability of the electrical system. This work aims to test the performance and comparison between the developed Light weight IED and different commercial IEDs from different vendor. The developed light weight IEDs are implemented on a microcontroller as well as on an FPGA. The test set-up is implemented by the Hardware-In-the-Loop platform. The simulation platform is OPAL-RT’s eMEGASIM. The results shows the performance of the FPGA to be better than microcontroller and other commercial IEDs when comparing results.

1. Introduction

The electrical grid systems have grown rapidly and rise complicity. This growing mainly based on the increasing of the decentralized renewable energy sources connection and communication between their different components. Numerous studies have been conducted to identify how these components are communicate to support power grid monitoring control and protection functions, based on its real-time operation [1]. In this context, some studies focus on the standardization of the power grid communication systems based on the IEC 61850 standard and its communication protocols implementation.

The latter brings new challenges in determining the reliability and the performance of the IEDs when having to consider both power system and communication phenomena within the multivendor environment [2]. The reliability of IED protection function that ensures a particular disturbance will disconnect as fast enough from the healthy network to mitigate the effect of the fault is directly related to the reliability of the power grid. Thus due to the vital role IED play to achieve assigned requirements and reduce the financial losses, the risk for malfunctioning should be minimized. It is therefore, performance testing, verifying and validating for the monitoring, control and protection functions settings within the assigned requirements is important. Since IEC 61850 standard has been distributed the protection, functions in different logical node (LN) that may located in different logical devices (LD) or even in different IED. The assigned LNs need to communicate and operate successfully in order to execute the relay protection functions reliably. Traditionally, manufacturer engineers make use of standalone relay performance testing. While also it is always necessary to certify its proper functioning during commissioning, and after a certain time of service. These testing make the relay to interface to different voltages and currents sources subjected to different electrical system circumstances.

During normal electrical network operation, protection relays are naturally inactive. Relays malfunction can only detected when the electrical network in faulted condition. With the advent of digital simulators the productivity of the expert engineers are increased and can save more time. Allowing them to execute the electrical system model in real time with different circumstances and faulted conditions, meanwhile protection relay interfaced to the digital simulator as hardware-in-the-loop (HIL) to evaluate their performance. In addition, GOOSE possibilities for transmission of different kind of data offers new opportunities for upgrading relay protection functions themselves and their testing. However utilization of the IEC 61850 protocols (GOOSE, SV, MMS) add more challenges and extra requirements for protection relay confirmation about the IEC 61850 capabilities.

IEC 61850 is the enabler for the SAS automation that offers different popular SAS protocols, GOOSE, SV for intra-substation within the first version and R-GOOSE, R-SV for inter-substations within the second version over the communication medium. SAS monitoring control and protection parameters parameter can be modelled, configured and automated using the IEC 61850 Logical nodes LNs that might located in to different logical devices LDs within different IEDs. On the other hand, In [3, 4, 5, 6, 7, 8] recent works raise the concept that although IEC 61850 offer many benefits for the SAS but the configuration and implementation of the IEC 61850 standard is the major challenges facing the configuration and implementation engineers according to the existing configuration tools (IED, System) within a multivendor environment.

Moreover, manufacturers support is always needed along with the commission of the multivendor IEDs project based on system support knowledge and tools. At this point, working in such multivendor project can be consider as much costly and time-consuming. However, in terms of accelerating and relaxing the standard configuration and implementations along with the rapidly IEC 61850 standard developments, a Light-Weight version can be used. These IEC 61850 Light-Weight version according to different open source libraries offer various solutions based C and Java etc. The offered solutions are worked based on low-level machine code required for the IEC 61850 implementation are automatically generated. The solutions can be implemented within different operating systems environments such as Linux, Windows, and macOS. Doing so will accelerate the development of the industrial instrument product line. Since the IEC standards are developed rapidly and usually the new/updated standards will cover/support new aspects related to the smart digital systems operation based monitoring control and protection functions. In this regard, developments industrial product lines usually took long time to support the developed new features defined based on the new/updated standards. Whereas, the Light-weight defined solution defined here helping to reduce the overhead standard complex information, limit ambiguity and accelerates the developments and testing tasks by supporting the new/updated aspects that defined based on the new/updated versions of the IEC standards. In [9, 10, 11] development and implementation of the new IEC 61850–90-5 R-GOOSE and R-SV protocols and their security standards IEC 62351 had been analyzed by using different developed source codes and tools. On other hand, the development of the smart grid controller based a commercial controller e.g. CompactRIO systems. However it provides a high-performance processing capabilities, sensor-specific conditioned I/O, and a closely integrated software toolchain that make them ideal for Industrial, monitoring, and control applications, but the user will be limited with the predefined control blocks afford with the initiated library, and with the supported interfaces/protocols by the controller. Whereas, the designed Light-Weight controller is more flexible and expandable in a way that able to support any state-of-the-art protocols/technologies and new/update monitoring, control and protection functions that might be defined along with the new/updating IEC standards. In [12, 13, 14] Controller development based on the Light-Weight designed controller for monitoring and managing of the reactive power flow between DSO and TSO networks was analyzed and tested, comprising between different controller that had been utilized in different boards was made.

In this work, embedded (Linux) environment is used based on microcontroller and SoC FPGA kit, since they are considering as a cost effective and flexible configuration.

In this work, different protection IEDs based Light-weight IEC 61850 are designed and demonstrated applying FPGA and microcontroller through the available of different open source software libraries. Performance testing for the designed Light-weight IEDs and the different conventional protection IEDs such as (Vamp52, ABB REF615) are validated by the RT-HIL laboratory setup as illustrated in Figure 1. Round-trip IEC 61850 GOOSE message latency measurements are made for those different IEDs. For RT-HIL testing, the test case study is modeled in MATLAB/Simulink and executed in real-time using Opal-RT’s eMEGAsim software and running in to the Opal real-time simulator. Finally, the performance of both Light-weight and different protection IEDs based GOOSE round tripping latencies are compared and evaluated.

Figure 1.

Block diagram for the HIL relay testing based on IEC 61850 round trip GOSSE.

2. Standardization of the communication system brought by IEC 61850

IEC 61850 standard was published in 2003 to cover the inter-substation communication and since that the standard has expanded and evolved. Nowadays it consist of around 35 parts covering many area of power system protection an automation. The later development has expanded its use intr-substations covering wider area in the grid including distributed generation and reaching up to the control center. IEC61850 cover all various aspects, which are common and related to the substation site e.g. SCD files that specify communication protocols, SAS configuration and conformity over the channel. While, grouping and organizing SAS parameters in applications level by means of syntax and semantics in IEDs they left for the software design engineers.

IEC 61850 developed based on the associated architectural construct “abstracting” data object definition and its services. The data structures (data objects along with the associated services) are abstracted in a way that severely independent from communication links. The data structure support all the aspect of the SAS based on the monitoring, controlling and protection functions along with their associated services in order to execute and facilitate the energy system operation. Therefore, data object can be mapping over any IEC 61850 defined protocol that can meet the best requirements need.

At this point, the major focusing of the IEC 61850 specification can be organized into three main issues;

Firstly, (data object model), SAS data object that associated with the available measurements, SAS functions (functional model) and IEDs name should be standardized in a way that provides to the IEDs a shared vocabulary that support the intended semantic meaning.

Secondly, abstract communication services interface (ACSI), accessing scheme to the available data can be defined as a services that specified in different standardizing ways over the assigned communication protocols.

Lastly, eXtendable Markup Language (XML) is selected to describe all the SAS data (data object models, configuration information and communication protocol) and organized in different SAS IEC 61850 extensions files. These files can be shared among all the SAS IEDs, networks and power system.

The scope of the first version of the IEC 61850 standard is composed of 10 major parts that together define the various aspects and the entire requirement that has to be fulfilled by SAS. The main drive is to achieve interoperability among the IEDs within the SAS. Where, the positive impact of the IEC 61850 standard in SAS operation cost it is clearly known in terms of increasing the power quality and reducing the outage response [12]. However, this goal requires paying attentions on how to implement the IEC 61850 standard in order to build, integrate and operate the SAS. While, rapidly transforming of the energy systems from analog to digital environment, which need huge amounts of real-time data to be shared based on their efficient operation. Therefore, IEC 61850 standard along with its uniqueness properties, that originated in hierarchy principle from the bottom to up which are dependent from the underlying operating technology. This will allow the Standard to operate over the stat-of-the-art technologies. The standard will cover all the electrical system aspects as well as the standard will provide a novel set of functionalities, which are not, exists within the legacy SAS operation. At this point and from the IEC 61850 implementation point view, the standard will be an enabler to upgrade and utilize the fullest functionality, where their operation and implementation are depend on sharing information among different LNs located on the same LD within an IED or different LDs located on different IEDs. Therefore, numerous of benefits will be achieved that included but not limited [13].

1. Open system based standard representation for whole energy system aspects and the underlying communication protocols for monitoring protection and control to eliminate the procurement ambiguity.

2. The standard will allow different IEDs from divergent vendor within the energy system to operate smoothly (Interoperability) based on the standardization of the whole energy system objects. This standardization will provide the ability to exchange the predefined system configuration files with the available system configuration tools independently from the on-site manufacturer support.

3. Different secure techniques that dependable from the overall system by means of separating the accessing to system into different levels depend on the user privilege that allows flexible information transfers.

4. Standardization will allow to decrease the overall operation system costs and maintenance.

5. Flexibility and scalability on functions design, by means of self-description in a standardized manner, as well as led to easy adaptation.

3. DERs LNs standardizations brought by IEC 61850-7-420

The global incoming booming of the DERs that need to be integrate to the energy grid, and the concept of bidirectional power flow raising challenges. Growing need for intra-substation to limit, overcome these challenges and integrate various DER in smart grid network. As a result, an extension for the IEC 61850 standard had been announced in 2009 as IEC 61850–7-420 to address these issues. IEC 61850–7-420 define and specify different LNs that support different aspect required and applicable for various DERs. The defined LNs are used to facilitate sharing the information signals among all participant nodes in the smart grid. This sharing information based utilizing the IEC 61850–7-420 in smart grid provide a great benefits in terms of reliability and availability.

From the above mentioned the consideration has been raised that the recently newer IEC 91850–7-420 standard will address the aspect that cover the modelling for different energy system DERs, since, within the first version IEC 61850 whole energy system aspects such as the services modeling, assigned system configuration language (SCL) and the mapping schemes are defined. These DERs information modeling defined by IEC 61850–7-420 standard involve not only for the local communication among the local DERs and the local management service systems, however, they may support the sharing information with the main grids operators or aggregators who manage the electrical grid operation. The defined DERs LNs based on IEC 61850–7-420 have been grouped into four groups upon their operation characteristic (node classes and common data classes (CDC)). These DERs LNs groups are logical nodes for DER management systems, logical nodes for DER generation systems, logical nodes for specific types of DER and logical nodes for auxiliary systems. These defined DERs LNs represents all the DERs operation aspects parameters such as for instance, connecting status, availability status, economic dispatch parameters, start/stop time, operating mode etc. however, in this paper based on the defined Islanding detection scenario, number of the IEC 61850–7-420 DER LNs have been selected in which are the DPST and the DRCS LNs. The real-time ECPs status and measurements is presented by DPST LN (the ECPs are usually associated with each DER, load, lines Buses etc. that need to connect to the local power system, group of DERs that need to interconnect to the Utility energy system etc.). While, single DER or number of the same type of the DERs that may controlled within the same controller able to be presented by DRCS LN.

4. IEC 61850–90-x

IEC 61850 is extended for inter-substations and has been accepted wildly from the both point views vendors and Utilities. Wide area application in smart grid based on state-of-the-art communication technologies are highly integrated in to the Automation systems. Therefore, IEC 61850 standard had been extended to cover these issues in series of IEC/TR 61850–90-x standard.

IEC/TR 61850–90-1:2010 specifies the inter-SASs communication that allows sharing real-time data among various power system nodes over different communication protocols and networks. While using all the previous comprehensive issues that covered within the first version of the IEC 61850 standard. Moreover, IEC/TR 61850–90-1 defines interfaces (IF2, IF11) to exchange data between substations upon protection, automation and control distributed functions.

IEC 61850–90-2 report considering the communication between the substations and the control centers which is under preparation.

IEC 61850–90-3:2013 communication networks and systems for power utility automation is considered by means of IEC 61850 for condition monitoring diagnosis and analysis.

IEC/TR 61850–90-4:2013 considering the local area network based SAS as well as provides the engineering guide line for communication and the limited requirements of IEC 61850.

IEC/TR 61850–90-5:2012 considering the wide area network based monitoring protection and control (WAMPAC), as well as provides the ability to sharing digital data (digital status, synchronous phasor measurements) among different energy system nodes. IEEE C37.118 is defined the synchronous phasor measurements data packet and its content, while the exchanging concept is complaint with the IEC 61850 definitions.

IEC 61850–90-5 supports the synchro-phasors real-time exchange of measurements technical requirements that had been defined within the IEEE C37.118 standard by implementing the previously defined IEC 61850 protocols (GOOSE, SV). While, IEC 61850–90-5, R-GOOSE routable GOOSE and R-SV routable SV, new routable mechanism through the new routable control block for the GOOSE and SV is defined. These R-GOOSE and R-SV data are mapped along with the control blocks that encapsulated in a session protocol data unit (SPDU). This SPDU might include number of data sets that contain deferent information other than just the synchro-phasors measurements. At this point since the data is routed among power system unites that my located in to deferent communication networks, multicast UDP/IP protocols are used. Differential Service Control Protocol (DSCP) also used to improve the delivery priority The DSCP limits the probability of delivery packets lost upon the router congestion, by adding the priority tagging to the delivered packets. Consequently, ac-cording to the IEC 61850–90-5 specifications, Internet Group Management Protocol Version 3 (IGMPv3) provides the “source filtering” option by means of enabling the subscriber hosts to register on a router and assign which group they want to receive multicast traffic from. As a result, the router does not need to copy the stream and assigned it to all the available paths. However, based on the subscriber’s defined table within the router it determines the appropriate dedicated paths in which that relax the communication network and improve the multicast delivery mechanism. Whereas, security aspects within IEC/TR 61850–90-5 is considered based on the “perfect forward” by means of exchanging the predefined encrypted key between the publisher and the subscriber. The publisher host will announced beforehand about the next key to the subscriber host as well as the subscriber needs to detect the synchronization status with the current key.

IEC 61850–90-12 2015, considers the inter substation communications upon the existing standards and protocols for the WAN communication [11], as well as the definitions, guidelines and recommendations. It, defined the inter substations and the substation-to-control center, as well as specified different issues related to these links such as energy system topology, redundancy, jitter and QoS, in order to facilitates understanding the state-of-the-art technologies, and integrating of different selected components through the conduct testing.

5. Light-weight IEC 61850 implementation of the developed control algorithm based hardware-in-the-loop

In order to test the developed light-weight IEDs based on the HIL simulations, the Substation Configuration Description (SCD) file was developed and further adapted into two different hardware, namely to the BeagleBone Black (BBB) and the Field Programmable Gate Array (FPGA). The flow steps of the developed C code start with the designed IEC 61850 IEDs based on the defined data attributes, data objects, LNs, LDs as well as it includes the operating functions, and the underlying communication protocols.

A “lightweight” IED need to implement the IEC 61850–8-1 (mapping the IED data to GOOSE) for the horizontal communication by using the open source library “libiec61850”. Furthermore, the designed IEDs generated by this process will compliance with the IEC 61850 detention and agree the interoperability concept that offered by the IEC 61850 standard. As well as the IED is flexible, scalable and can be updated based on the valid SCD file. Within the open source library “libiec61850” the overall C code project files can be generated automatically based on define internal data model. This approach will reduce the research and development runtime and maximize the performance and facilitates the use of relatively low-cost embedded devices and FPGA.

Figure 2 depicts the instruction designing procedure for the “lightweight” IEDs that presented in this study. Within the first step SCD (.icd) file need to be designed based on the defined energy system aspects that includes the data attributes (DA) types, data object (DO), logical node (LN), logical devices LDs as well as communication instances of the model.

Figure 2.

The developed DMS internal processing.

At the second step, and from the predesigned SCD file that include all the IEC 61850 data, a C code is automatically generated by the “libiec61850 model generator”. This generated code is the representation of the model and their communication instances that tailored to the designed model. At this point the “model generator” attempts to convert and mapped each type of IEC 61850 data model into a C data structure. From this process a hierarchy C data structure file will achieved and collected into the project folder.

The third step was to define the parameters that are needed to be subscribed. Then to compile the design project file (or application file) to generate the execution file for running the project in the hardware under test.

The fourth step was about extracting the defined parameters (in this case the status of the main supply) from the subscribing GOOSE message from the model. Next step describes the execution of the control algorithm in the hardware and based on the result, the new status value need to be send over the communication network from the controller via IEC 61850 GOOSE protocol. On the other side the target were the simulation model is running is able to subscribe to the GOOSE message and extract the useful data to be used within the running model in real-time.

Lastly the designed project need to be tested. For cost reduction and simplicity advanced reduced instruction set computer (RISC) Machines (ARM) processor-based microcontroller BeagleBoneBlack (BBB) as well as by the ARM processor-based SoC FPGA are used. Both are compatible with C and C++ compilers.

6. Data object modeling based on IEC 61850–7-420 LNs

Data object modeling based IEC 61850–7-420 LNs need to be virtualized. Figure 1 illustrate the round trip GOOSE messages between the publisher-subscriber-publisher which are modeled and need to be tested in real-time running in Opal-rt simulator. The round trip test setup consists from different IEDs. IEDs are configured to subscribe to the Opal real-time GOOSE messages and published back to the real-time simulator another GOOSE messages. Distributed IEDs are scattered over the communication system network through different distributed data points. These distributed IEDs are used for monitoring, control and protection function purposes.

LNs DPST and DRCS are selected to present the ECPs status and the DERs operation status respectively. LoM protection function based on its operation need to gather the information signals from the deined above LNs. LNs data structure is illustrated in Figure 3 in which that listed and structured in tree manner down to data objects.

Figure 3.

Native IEC 61850 IED including the DPST and DRCS IEC 61850–7-420 LNs.

LoM protection function based on its operation, data object DPST.ECPConn included in to the DPST LN hierarchy is modeled for reflecting and indicating the ECP connection status. If the status of the data object DPST.ECPConn is “True” it indicates that DER is connected to the electrical grid through the ECP, and if it is “False” it indicate that the DER is not connected to the electrical grid through the ECP.

DRCS LN is include the DRCS.ECPConn and DRCS.ModOnConn data objects from the list of data objects defined in to the standard. DRCS.ECPConn data object present the electrically connected status of the ECP of the DER. Therefore, if the status of this data object is “True” the DER is connected to the electrical grid through a specific ECP, and vice versa. DRCS.ModOnConn data object present the status of the DER. If it is “True” it indicate that the DER is in operation mode “ON” and electrically connected. Whereas if it set “False” it indicate that the DER is electrically connected and not in the operation mode.

Opal real-time simulator is configured as un IED that include LNs DPST and DRCS LNs data objects in its ICD file. According to this ICD file Opal real-time simulator has the ability to publish GOOSE message over the communication system network. Different IEDs are configured to subscribe to the Opal real-time simulator GOOSE message based LoM protection function. Control decision status can be extracted from subscribing to the Opal real-time simulator GOOSE message.

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 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}}_{RTT}={\overline{t}}_{\begin{array}{c}\mathit{out},\\ \mathit{Target}\end{array}}+{\overline{t}}_{net}+{\overline{t}}_{\begin{array}{c}\mathit{in},\\ DUT\end{array}}+{\overline{t}}_{\mathit{app}}+{\overline{t}}_{\begin{array}{c}\mathit{out},\\ DUT\end{array}}+{\overline{t}}_{net}+{\overline{t}}_{\begin{array}{c}\mathit{in},\\ \mathit{Target}\end{array}}$$E1

where

${\overline{t}}_{RTT}$: round trip time average,

${\overline{t}}_{\mathit{out},\mathit{Target}}:$out from the target time average,

${\overline{t}}_{net}$: communication network time average,

${\overline{t}}_{\mathit{in},DUT}$: DUT time average,

${\overline{t}}_{\mathit{app}}$: DUT internal application average time,

${\overline{t}}_{\mathit{out},DUT}$: DUT, out time average,

${\overline{t}}_{\mathit{out},\mathit{Target}}$: 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 round-trip 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.

9. Case study

For easy understanding of the smart LoM protection based GOOSE simple electrical system with simple Ethernet communication system network has been defined (modeling of the electrical system within the real time simulator is not focusing of this work) as in Figure 1. A laboratory setup for the electrical communication system network that includes Opal-rt simulator, different Light-weight and commercial IEDs, 1000Mbit/sec Ethernet link and Ethernet switch has been established. IEDs light-weight IEC 61850 based FPGA and microcontroller is designed and modeled according to the IEC 61850–7-420 DERs LNs. GOOSE publisher block is continuously publishing the status of the main supply and the ECP through the 146 bytes GOOSE message from the real time simulator. Light-weight native IEC 61850 IEDs based FPGA and microcontroller are designed and modeled based on IEC 61850–7-420 DERs LNs, whereas others IEDs are a normal commercial feeder protection relay, Vamp 52, and ABB 615. Different IEDs are configured as subscriber to the Opal-rt GOOSE messages. The subscriber IEDs use the extracting parameter from the Opal-rt GOOSE for proper implementation of the proposed LoM protection function. Two scenarios based LoM protection function had been specified. Testing for these tow scenarios had been carried out based on the above laboratory setup. The first scenario for the LoM protection function is by changing the DPST.ECPConn data object of the main supply status from “true” to “false” in Opal-rt. This changing of the main supply DPST.ECPConn data object from “true” to “false” indicates that the main supply is not electrically connected to the electrical grid. Now here is regardless to the main supply operation mode. While scenario two, is by changing the main supply operation status by the DRCS.ModOnConn data object from “true” to “false”. This changing of the main supply DRCS.ModOnConn data object from “true” to “false” indicates that the main supply is electrically connected however it is not within the operation mode. In practice this means that the circuit breaker is closed but there is no power supply available (e.g. due to main transformer failure). The changing statuses in scenario one and two are published within Opal-rt GOOSE massage. Both scenarios present two cases of the LoM that need to be predicted and detected within the DUT and publish dispatching GOOSE messages based on the new detected status. In our case study the LoM prediction and detection tasks are implemented through the exchanging of the GOOSE messages over the communication system network. Moreover, main and standard deviation of the GOOSE messages round trip latencies had been measured and calculated in next section.

10. GOOSE round trip latencies results and discussion

GOOSE latencies was measured for the round trip GOOSE based LoM laboratory setup and results are presented. The status of the main supply DPST.ECPConn or the DRCS.ModOnConn data objects was monitored. If one from the above mentioned data object indicate or show “False” indication it signify the disconnection of the main supply from the electrical grid or the main supply is electrically connected to the grid but the connection is not in operation, respectively. In both cases there is LoM a situation and DERs must be disconnected or changed to the island operation mode. By publishing the main supply status within the multicast GOOSE message it is eventually distributed to all the subscribers and LoM situation is properly handled even with high penetration of DERs. According to the test scenarios 100 trials of DPST.ECPConn and DRCS.ModOnConn status changes had been made and published within GOOSE messages from the Opal-rt simulator. Different IEDs are subscribing to Opal-rt GOOSE messages and monitoring the status of the main supply. While, another GOOSE message are published from the subscriber IEDs upon receiving and processing the Opal-rt GOOSE. All the GOOSE messages are recorded with the IEDScout for the round trip analyzing purposes.

Different subscriber IEDs are inherently able to monitor other data objects from other LNs that may include in to the designed ICD file. These data object status may be used to observe and response to all the different changes in the main supply status, which enables also some advanced operational scenarios. From the above tested scenarios, LoM protection function and may other functionalities have been proven to be possible both with the newly introduced light-weight IEC 61850 FPGA and embedded microcontroller. According to the achieving, results different round trip times for the communication channel had slightly vary depending on the communication channel and receiving end IED. The results also behave according to normal distribution model, which was expected. Since there was no other traffic within the communication channel in this test, and GOOSE messages with high priority (4) and short packet length were used the Ethernet communication system turned out to have very high reliability. Using the normal distribution probability density function the mean of the round trip latency of the GOOSE messages latencies had been calculated as illustrated in Table 1.

GOOSE round trip
	BBB	Vamp52	ABB	FPGA
Mean val. ms	11.2	18.8	3.6	4.2

Table 1.

IEDs latency in millisecond.

From (1) round trip latency was for BBB 11.2 ms and FPGA 4.2 ms. Based on the results, it is clear that the FPGA is a more promising instrument with less round trip latency (4.2 ms) that could better be used for the smart grid or microgrid central controller. In addition, the round trip latency for the FPGA is less than the other IEDs in which that was expected. Since the FPGA has Dual-Core ARM Cortex™-A9 (925 MHz) processor as well as 10/100/1000 Mbps Ethernet with the high-speed bus to exchange data between the hard processor system (HPS) and FPGA whereas the BBB has AM335x 1GHz ARM® Cortex-A8, and 10/100 Mbps Ethernet.

Lastly, we recommend that it is the time indeed for the researcher to really start looking/implementing these developed light weight IEDs, standards and testing them, in a way that we can see where the system/standards vulnerabilities might lay/practically do real-time measuring/evaluating in order to evaluate the IEDs development and fall the standards knowledge gaps. Also, measure and improve the energy system resiliency [17].

11. Conclusion

In this chapter, the monitoring, control and protection solutions and their relevant communication system have been designed based on IEC 61850 and implemented on hardware platforms, FPGA, BeagleBoneBlack and commercial IEDs. The development process and performance of LoM monitoring and control scheme on a light weighted intelligent electronic device has been investigated. The performance of the IEDs has been evaluated through hardware-in-the-loop test in terms of communication latency, processing time, and finally the performance of control action. The FPGA has performed better compared to BeagleBonBlack and is more suitable for micro-grid central controller. It is worth to mention that such an open-source flexible light-weighted IED based on IEC 61850 can provide a base to advance research in the direction of (Micro)-grid automation and control.

Abbreviations

IED	intelligent electronic device
FPGA	field programmable gate array
LN	Logical node
LD	Logical device
GOOSE	Generic Object Oriented Substation Event
R-GOOSE	Routable Generic Object Oriented Substation Event
SAS	Substation automation system
SV	Sample Value
R-SV	Routable-Sample Value
MMS	Manufacturing Message Specification
SoC	System on Chip
ACSI	abstract communication services interface
XML	eXtendable Markup Language
DER	Distributed energy resources
SCL	system configuration language
SCD	Substation Configuration Description
ICD	IED configuration description
WAN	Wide area network
QoS	Quality of services
DUT	Device under test