Distributed Generation Control Using Ripple Signaling and a Multiprotocol Communication Embedded Device

Abstract

Remotely performing real-time distributed generation control and a demand response is a basic aspect of the grid ancillary services provided by grid operators, both the transmission grid operators (TSOs) and distribution grid operators (DNOs), in order to ensure that voltage, frequency and power loads of the grid remain within safe limits. The stochastic production of electrical power to the grid from the distributed generators (DGs) from renewable energy sources (RES) in conjunction with the newly appeared stochastic demand consumers (i.e., electric vehicles) hardens the efforts of the DNOs to keep the grid’s operation within safe limits and prevent cascading blackouts while staying in compliance with the SAIDI and SAIFI indices during repair and maintenance operations. Also taking into consideration the aging of the existing grid infrastructure, and making it more prone to failure year by year, it is yet of great significance for the DNOs to have access to real-time feedback from the grid’s infrastructure—which is fast, has low-cost upgrade interventions, is easily deployed on the field and has a fast response potential—in order to be able to perform real-time grid management (RTGM). In this article, we present the development and deployment of a control system for DG units, with the potential to be installed easily to TSO’s and DNO’s substations, RES plants and consumers (i.e., charging stations of electric vehicles). This system supports a hybrid control mechanism, either via ripple signaling or through a network, with the latter providing real-time communication capabilities. The system can be easily installed on the electric components of the grid and can act as a gateway between the different vendors communication protocols of the installed electrical equipment. More specifically, a commercially available, low-cost board (Raspberry Pi) and a ripple control receiver are installed at the substation of a PV plant. The board communicates in real-time with a remote server (decision center) via a 5G modem and with the PV plants inverters via the Modbus protocol, which acquires energy production data and controls the output power of each inverter, while one of its digital inputs can be triggered by the ripple control receiver. The ripple control receiver receives on-demand signals with the HEDNO, triggering the digital input on the board. When the input is triggered, the board performs a predefined control command (i.e., lower the inverter’s power output to 50%). The board can also receive control commands directly from the remote server. The remote server receives real-time feedback of the acquired inverter data, the control signals from the ripple control receiver and the state and outcome of each performed control command.

1. Introduction

The European Union (EU), through its REPowerEU Plan, targets to increase the share of renewable energy sources (RES) so that by 2030, the 27-country EU would commit to sourcing 42.5% of its energy from RES, with a potential top-up to 45%. However, this is still fluctuating and uncertain, mainly due to the capacity limit of the electricity grid (grid congestion) in addition to the insufficient or limited support of national policies and challenges in obtaining permits. Reinforcing and upgrading the existing grid infrastructure will take years to complete, stalling the REPowerEU Plan’s goals. Therefore, in most of the EU countries, and until the grid capacity upgrades are performed, the laws of EU countries generally limit the unconditional access of RES to the grid.

Nevertheless, the high cost of energy still persists, both in the private and public sector. Thus, investments need to be made into RES implementations and energy storage solutions through net-metering, multi-tariff and zero-feed-in policies. Due to the stochastic nature of RES production alongside with an also stochastic demand of power (i.e., electrical vehicle charging stations), the DNOs must monitor this production in real time and demand variations of energy and, depending on the actual grid capacity, perform real-time dynamically adjusted control operations (RTGM). This monitoring, alongside with the real-time predictions of the thermal capacity of the MV lines based on the grid’s upper and lower voltage limits [1] and the yearly voltage variations [2], will prevent any potential power quality indices on the grid’s MV lines due to the penetration of DGs.

Nowadays, the existing grid infrastructure of DNOs supports cross-grid MV lines (interconnected lines) between two or more main lines with remote-controlled MV circuit breakers installed on both line edges. In this way, the DNOs can remotely control parts of the grid in order to minimize the impact of potential blackouts and manage not to keep significant parts of the grid offline.

Therefore, alongside the control policies (e.g., digital twin, DC optimal power flow [3]) and the grid optimization and power prediction algorithms, the basic requirement for the DNOs to perform RTGM operations is the access to real-time acquired data and measurements, via an “accessible” platform, of all the grid’s infrastructure equipment (e.g., transformers, metering devices, state of circuit breakers and relays, DG production, grid lines voltage levels and frequency, charging power demand of electric vehicles, state and available charging capacity of batteries, etc.).

The interoperability of communications remains the most difficult and common problem between the grid’s infrastructure equipment. In most cases, this existing equipment uses vendor specific communication software for data acquisition/storage and control mechanisms. Also, in many cases, older equipment does not even support any communication options for remote control or remote data acquisition. By taking the ageing of the equipment and the lack of firmware updates by the owners and manufacturers into consideration, even devices of the same vendors appear to have communication incompatibilities between each other. Replacing this incompatibility in terms of communication equipment with new “smart” devices is not a feasible solution, mainly due to the fact that this would be a costly and time-consuming operation. Apart from that, although the newly installed “smart” devices should support remote control and remote data acquisition, communication incompatibility might still be present between different vendors or equipment types. The use of the grid’s existing infrastructure (metering and control equipment) combined with the additional installation of the proposed low-cost system devices that support real-time data exchange and control, could be the best possible solution for RTGM.

In this article, we present a small-scale test implementation of a hybrid solution of an Internet of Things (IoT) and smart communication gateway (SmG)-embedded device installation, operating in parallel with the DNO’s ripple control signaling system, in order to perform RTGM operations on the grid. The SmG can acquire data via the widely used industrial communication protocols (IEC 61850 [4], IEC 60870-5-103 [5], Modbus, CAN, KNX, etc.) and can also receive digital and analog signals, supporting real-time, multidirectional communication between the existing electrical equipment (metering devices, DG inverters, PLC and SCADA systems, digital and analog sensors) and the decision center (HEDNO). Thus, the above-mentioned communication interoperability problem between the grid’s infrastructure electrical equipment is solved as the SmG acts as a gateway between the different protocols and signals, and the need for costly equipment upgrades with newer “smart” devices vanishes. The only intervention to the grid’s existing infrastructure is the installation of this low-cost SmG device, in addition with a ripple control receiver, per group of measuring devices, sensors and equipment.

2. Problem Formulation and Solution

For the DNOs to be able to perform RTGM, a reliable and cost-effective real-time communication and control system is needed. RTGM operations require real-time multidirectional communication between the metering and control devices (i.e., the DGs) and a central server responsible for making decisions regarding the system (i.e., the DNO, a RES producer, etc.). In small-scale networks (i.e., individual RES producers), this is often accomplished through the vendor’s equipment software cloud platforms. While the network to be monitored and controlled grows bigger (i.e., the national electricity grid), the decision centers (i.e., DNOs) need to communicate with hundreds of thousands of metering and control devices, obtaining real-time data during this process. This data must be acquired through different software and hardware platforms and is usually stored in different locations and/or formats due to communication interoperability issues between the different vendors. This makes it difficult and time consuming to access and analyze this data: to do so, this data (prior to any analysis) needs to be accessed and reprocessed to a “common” data format. In large-scale networks, such as the national electricity grid, this might be a difficult process due to the amount of stored data needed to be reprocessed, while it makes it almost impossible to complete real-time data analysis for the DNOs to perform the essential RTGM operations.

In summary, in order for DNOs to perform RTGM operations, they must have real-time access to vast amounts of data from the grid’s installed equipment and control this equipment on-demand and in real-time. The acquisition of the data must overcome the different communication incompatibilities between the different vendor’s installed equipment. The control of the equipment must be reliable. Both problems regarding the data acquisition and equipment control must be solved in a cost-efficient way.

Regarding the control of the equipment, the ripple signaling system has proven to be a reliable, secure and cost-effective system used for many years by the DNOs. However, it lacks the ability to transfer any form of data back to the DNOs (i.e., feedback of the operations performed, etc.). However, this feedback can be provided to the DNOs with the real-time communication protocol.

The real-time communication protocol must support the exchange of data between the participants, i.e., the installed equipment (consumers) and the DNOs (broker). This data must consist of measurements and the state of each of the critical equipment must be monitored (i.e., circuit breaker is tripped) along with the control commands (i.e., lower the output power of the inverter to 50%) and the state/outcome of the performed control commands (i.e., pulse received from the ripple control receiver, control command executed to lower the output power of the inverter, the control command performed successfully). This real-time exchange of data is supported by the advanced message queuing protocol (AMQP). AMQP aims to solve the problem of how to connect hundreds of thousands of consumers by exchanging hundreds of millions of messages per second.

The main concept of the AMQP is about storing messages (acquiring data and/or control commands) on a que, applying (if desirable) any quality of service (QoS) rules on the message que (i.e., rearranging high priority messages before low priority messages on the que) and processing the message exchanges between consumers and the broker. There are several open-source and commercial AMQP implementations. These AMQP implementations need a central broker to operate and route the messages between the connected consumers (no support for direct peer-to-peer communication between the consumers).

In the current small-scale experiment, the SmG, which now becomes the consumer, supports a form of an AMQP as it acts as a communication gateway between the broker and the installed equipment, based on the open-source Zeromq (ØMQ) communication library [6,7,8]. ØMQ supports transient enterprise communication patterns by merging real-time messaging with the network. Also, the ØMQ state is distributed; thus, there is no need of a central server (broker) to route the messages between the participants. However, in such an RTGM implementation, there will be several brokers available on the network to perform monitoring and decentralized controlling of the system. This “brokerless” support of the protocol constitutes the system being more autonomous with low latency response times and half the bandwidth needs (when the consumers exchange messages directly with each another, without the need to be routed through the broker). Moreover, in a “brokerless” implementation, the single point of failure event will never occur; thus, if one broker “crashes”, the whole network will still be available (Figure 1).

The cost of such an implementation, by using SmGs to monitor and control the existing infrastructure, compared to an equivalent scale upgrade of the infrastructure with “smart” devices is significantly lower. Moreover, someone should not only consider the purchase cost of a group of new “smart” equipment, compared to the cost of a single SmG capable to communicate with the existing group of “dump” equipment, but also the cost of implementing such a large-scale upgrade. An upgrade solution for “smart” devices includes the need for uninstalling existing and reinstalling new equipment (with a mandatory need of power outages), compared to the much simpler and less time-consuming installation of an SmG board along with a ripple control receiver (see Section 5).

The proposed SmG is an ARM-based single board computer (SBC) which can run a POSIX compliant OS (Linux, *BSD), supports a full network stack (IPv4 and IPv6 routing, VLANs, VPN tunnels, etc.) and encryption protocols and can be further developed to support software upgrades and remote administration mechanisms. At the open systems interconnection model (OSI) block diagram in Figure 2, the SmG-embedded IoT multiprotocol gateway board is presented, alongside with its supported communication capabilities with the external grid’s equipment (metering devices, sensors, etc.).

The ØMQ communication library used supports, via the library’s provided open SDK, various programming languages and frameworks (C++, C#, Objective-C, ANSI C, .NET and MONO framework, Python, Perl, Go, Node.js, etc.) for the development of applications and the extension of the board’s capabilities, various 32-bit and 64-bit architectures (x86, ARM, RISC) and operating systems (FreeBSD, Linux, MacOS, Microsoft Windows). The SmG can support a plethora of communication protocols (GPRS, LTE, Bluetooth, LoRA, LPWAN, etc.) through already embedded-on-the-board controllers or through low-cost expansion modules. For the connection with external devices, in terms of hardware, the SmG provides a pin header supporting digital and analog I/O, serial ports (RS232, RS485), I2C controllers, USB headers and basic network controllers (Ethernet, Wi-Fi and Bluetooth). For communication with external devices, in terms of software, the SmG supports the most used industrial communication protocols (IEC 61850 [4], IEC 60870-5-103 [5], Modbus, CAN, KNX, etc.). All these constitute this remote control system being easily expandable, based on an open platform without any license and propriety restrictions, in contrast with many commercially available “smart” devices with, in many cases, vendor-specific protocols and closed-source architectures.

A typical commercially available SBC is shown in Figure 3.

The following components are shown in Figure 3: the CPU (Sunplus SP7021), the data storage unit eMMC where the OS is kept, the physical interfaces that will be used for the communication to external devices (RS232, RS485, Ethernet, 40 Pin header), the physical interfaces for the communication to management units and administration (Debug Uart) as well as other interfaces to external devices (USB, MicroUSB ports, MIPI CSI). Take into consideration that for a large-scale implementation, the final redesign of the SmG board will be a stripped-down version of such typical boards on the market, and will only include the controllers and peripherals needed for communication for the custom implementation and exclude all the unnecessary controllers and peripherals (sound, GPU, HDMI, Micro SD, USB ports, etc.), which will lower the cost of the board even more.

Thus, with all that in mind—the ease of installation, the plethora of communication possibilities and the support for real-time data acquisition regarding the grid’s state—a large-scale deployment of SmGs would allow the DNOs to be able to perform RTGM (Figure 4):

3. Remote DG Control and Demand Response Using Ripple Signaling: From Simulation to Implementation

With the grid’s existing infrastructure and without adding any additional equipment (i.e., an SmG), the DNO is capable of performing RTGM in relation to the DG (PV plant in our case) impact on the point of common coupling (PCC).

Most of the commercially available PV inverters are supported to receive input signals from their control auxiliary contacts, through which their state (ON/OFF/output power) can be altered through a ripple control receiver signal; however, in many cases, the inverters are supported to be connected in groups, altering the state of each group (ON/OFF/output power) with the same ripple control receiver [9,10,11,12].

In the cases where there is a motorized central circuit breaker installed on the production side of the DG unit, the DG’s production state can be altered through the auxiliary contacts of the circuit breaker, which are connected to the ripple control receiver.

This is yet considered to be the optimal way to perform distributed generation control as part of RTGM operations using ripple signaling. With this method, the DNO can control the production of the DG without interfering at the auxiliary side of the plant (alarm, cameras, network connectivity, etc.) (Figure 5).

The results of the ripple signaling control have been well described in a simulation by the authors in [13,14]. These simulation results present the voltage profile and other power quality indices along the feeders during RTGM operations.

However, when it comes to applying the distributed generation control and demand response technique in a real case scenario, there are two major problems that need to be solved:

(a)

The compatibility and communication problems with the different equipment of vendors and software platforms;

(b)

The lack of feedback to the DNOs of the current state of the solar parks (generated power, current state of the main circuit breaker, etc.). Performing grid control through ripple signaling provides no feedback to the decision center (DNO).

4. Ripple Signaling and SmGs Interconnection—Use Case Scenario

Therefore, to overcome the communication interoperability problem and the lack of real-time feedback, the SmG is able to communicate with the PV station’s inverters, either directly or through a potential existing smart logger already communicating with the solar plant’s inverters by constantly acquiring operational data from the inverters, obtaining the control signal(s) from the DNO through the ripple signaling receiver, dynamically adjusting the output power of the solar plants to the desired level and informing the DNO with the required feedback.

In this way, the advantages of the ripple signaling technique are still present. That is, keeping the cost very low by using the existing infrastructure while providing immunity to cyber security attacks.

The SmGs are communicating with the broker (DNO) through the AMQP during normal operations and exchanging messages and controlling the connected devices and equipment without the need of the ripple signaling receiver. However, in a potential network communication failure between the SmG and the DNO where the DNO will not be able to communicate directly with the SMGs via the AMQP, the DNO will always be capable of controlling the output power of the DG through the ripple control signal, even though it will not be able to obtain feedback of the current state of the DG from the SmG (Figure 6) [13,14].

5. Pilot Installation

A small-scale application of a hybrid solution for RTGM is presented, controlling the generated output power of a 500 kWp solar plant in the Kastoria region.

The selected PV plant is one out of a total of 169 PV DGs in the region and is also one out of 45 of them with an installed capacity larger than 95 kWp, with the total installed capacity of these 45 DGs reaching 15,879 MWp, corresponding to 92% of the total DG installed capacity of the two lines in this region.

In Figure 7, the part of the grid where the DGs are located is shown where the modeling of the two MV lines and the simulation results were obtained [13,14]. This was carried out with the respective software of the Greek DNO (HEDNO).

The simulation takes four scenarios into account [13,14] as part of the RTGM operations due to scheduled maintenance works, due to a grid reconfiguration because of a fault, due to underground cables works or because of adding new MV consumers to the grid. The results of the simulation for RTGM through ripple signaling control are very good, especially at distant nodes from the substations, with the voltage level of every node of the MV network being kept below the limit of 22 kVs.

Even though the results of the simulation of RTGM through ripple signaling control are absolutely encouraging, some parameters of the grid still cannot be measured accurately, limiting the RTGM, including any load transfer operations, due to the thermal capability or to the voltage limits of the MV lines.

A potential installation of SmGs to the DG substations (i.e., to the 45 DGs of the grid—in our scenario), will provide real-time monitoring of these grid parameters and real-time feedback of any control operations, allowing the DNO to perform with the needed accuracy for RTGM operations.

For this small-scale pilot project, an SmG (Raspberry Pi B+ model running NetBSD 9) and a ripple signal receiver (FMX 511 0C33) are installed at the sub-station of the selected PV plant [14]. The generated output power of the PV plant is controlled on demand by the broker (HEDNO). The control can be applied in two separate methods, either by sending pulses through the ripple control receiver or directly, from the broker application, through the AMQP via the Internet. Regardless of the control procedure used, the SmG is providing real-time feedback and monitoring data through the AMQP to the broker. The broker comprises a remote x86 machine running FreeBSD 13.1. Both console applications for the consumer and the broker are written in C++. The AMQP uses the PUB-REQ pattern for message exchange based on the ØMQ communication library.

The installation of the needed equipment, i.e., the ripple control receiver and the SmG, is very simple and cost efficient. The auxiliary contact of the ripple control receiver (18–19) is connected to one of the SmG’s free digital inputs (GPIO14-GPIO27, where GPIO27 is set as the INPUT at a HIGH 3.3V DC) through a NO auxiliary contact (11–14) of a relay. In our case, the SmG has access to the internet through a 5G modem and is connected to the broker through an IPSEC IKEv2 VPN tunnel. The SmG is also connected to the PV plant’s five inverters through an RS485 port and can monitor and control them via the Modbus RTU protocol.

Figure 8, Figure 9 and Figure 10 show the simplicity of the implementation.

During the tests, the SmG managed to receive signals from the ripple signal receiver, which triggered several preprogrammed actions, such as lowering the generated output of all or individual inverters, switching them off and/or on again, etc. Of course, the same preprogrammed actions were performed remotely on demand with the DNO through the broker application, via the AMQP.

During the period of the pilot application run, the SmG was monitoring the connected inverters via the Modbus protocol, and the acquired data (generated output, frequency, voltage, etc.) was sent to the broker in real time, and real-time feedback of all the control operations performed was also provided to the broker (i.e., received pulse from ripple control receiver, lower generated output, etc.), with all of these being performed through the AMQP.

6. Discussion

During the pilot application, the SmG was monitoring and controlling the DG output power of one PV plant on-demand in real time. We have successfully tested that the DNO can control the SmG on-demand through the AMQP and the network link (in our case, through the 5G modem connection of the SmG), even on a potential network loss, via wave signal control through the ripple control receiver.

The next stage of this research is a large-scale implementation (i.e., installation of SmGs and ripple control receivers at the 45 major DG plants in the Kastoria region) of these devices which will be able to provide real-time measurements and real-time feedback from the RTGM operations in order to verify the simulation results.

At such a potential project, control algorithms should be developed, receiving real-time acquired data as their inputs (i.e., voltage level at PCC) and executing predefined control commands (i.e., lower PV inverter power output until voltage reaches a specific value). Various tests should be run, and the results should also be validated against the simulation results. Here is where the whole project becomes interesting. The “brokerless” nature of the ØMQ communication library allows the SmGs to directly exchange information with each other without the need of a central broker (DNO). A group of SmGs monitoring and controlling a group of DGs at the same MV line can exchange information in real time with each other and perform control actions, each one at its corresponding DG unit, in order to keep the grid parameters inside the operational limits. Even in a potential network loss, where all or part of the SmGs will not be able to communicate with each other, the broker (DNO) will be able to perform additional control/correction actions through the ripple control signaling, reassuring that the operation of the grid remains within safe limits.

7. Conclusions

The main objective of this article was to propose a cost-effective and reliable solution to the DNOs for RTGM operations.

As explained earlier in this article, a potential large-scale implementation of SmGs will be more cost-efficient and less time-consuming, compared to a potential upgrade of the existing infrastructure in order to support “smart” network features.

The ripple signaling control makes the system reliable because, under any circumstances (network loss), the DNO will always be able to perform control actions on the grid. The distributed nature of the ØMQ communication library will allow a group of SmGs to exchange real-time data and perform automatic control actions without the need of the central broker, while its low latency communication capabilities will be able to provide real-time data to the broker.

Finally, the SmGs are based on open-source protocols, providing an open platform which can be easily upgraded and adopted by any third party for developing additional tools. Thus, any interoperability issues that arise between the components of the electricity grid and the DG components can be easily resolved.