Distributed Generation Control Using Ripple Signaling and an Innovative Communication Gateway

1. Introduction

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%, which in practice however is still fluctuating and uncertain, due mainly to the capacity limit of the electricity grid. Therefore, in most of the EU countries and until the grid capacity upgrades are performed, the laws limit access to the grid for RES.

However, apart from the grid capacity upgrade operations, there are still well-known grid power quality indices, which limit the capacity of RES DGs on any medium voltage (MV) grid line such as the thermal capacity of the lines (conductors, overhead lines or underground cables), the lower and the upper limits of the grid’s voltage [1] and the limits of the voltage variation through a complete year of operation [2].

Nowadays, DNO’s existing grid infrastructure supports cross grid lines (interconnected lines) between two or more main lines while in many cases remote-controlled circuit breakers are installed at the interconnected line edges, towards their effort to remotely control parts of the grid in order to minimize the impact of potential blackouts and comply with the SAIDI and SAIFI indices [2] during repair or maintenance works while not keeping significant parts of the grid off-line.

Apart from the theoretical part of the control architecture (e.g. digital twins, DC optimal power flow [3], optimization and prediction algorithms), one basic need of the DNOs in order to be able to perform RTGM operations, is the real-time acquisition of data and measurements, in a central platform per area/microgrid, of all the critical equipment of the grid (e.g. transformers, measuring devices, relays, circuit breakers state On/Off/Trip, output power of a solar plant and voltage at the point of common coupling (PCC), charging power of electric vehicles, etc).

One basic and very common problem in this case is that all the above and already installed equipment, use different communication protocols, and do not support common communication options. In many cases, older equipment does not even support any communication options at all for remote control or data acquisition. Due also to ageing and lack of firmware updates by the owners and manufacturers, even devices of the same vendors appear to have communication incompatibilities between each other. Replacing existing and older equipment with new “smart” devices is not always practically feasible, 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 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 low-cost devices that support real-time measurements and control, could be the optimal solution.

In this paper we present the implementation of a hybrid solution of an Internet of Things (IoT) 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 existing grid’s infrastructure. The SmG is acquiring data via the widely used industrial communication protocols (Modbus, CAN, IEC 61850, IEC 60870-5-103 etc.) and achieves real-time, multidirectional communication between the existing measuring devices, PLC/SCADA systems, sensors (Analog/Digital IO) and the decision centers (i.e. DNOs). Thus, no communication interoperability issue between the devices of the grid appears 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, per group of measuring devices, sensors and equipment.

2. Problem formulation and solution

In order for the DNOs to be able to perform RTGM to ensure the stable operation of the grid and keep the power quality indices inside limits, a reliable and cost-effective real-time communication and control system is needed. In terms of control, the ripple signaling system has proven to be a reliable, secure and cost-effective system used for many years by the DNOs. But it lacks the ability to transfer any form of data back to the DNOs (i.e. feedback of the operations performed, etc.).

In terms of communication, the DNOs must have real-time access to the grid’s existing infrastructure of metering and control devices, which requires vast amounts of data exchange. This data is often acquired by different software and hardware platforms and stored in different locations and/or formats due to communication interoperability issues between the different vendors. This makes it difficult and time consuming to analyze the data, as in order to do so, the data stored in different locations 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 have real-time data analysis for the DNOs to perform the essential RTGM operations.

RTGM operations, involves the need for real-time communication (a form of message exchange) between the metering and control devices (consumers or clients) and a central server (broker) 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 grid), the decision centers (i.e. DNOs) need to communicate in real-time with hundreds of thousands of metering and control devices, overcoming the incompatibilities already mentioned in the communication between the different vendor’s installed equipment and software platforms.

In order to provide real-time communication to the decision center (central server – broker), the SmG (consumer) supports a form of an Advanced Message Queuing Protocol (AMQP), based on the open-source (Mozilla Public License 2.0) Zeromq (ØMQ) communication library [4,5,6]. ØMQ communication library, aims to solve the problem of how to connect hundreds or thousands of pieces by exchanging hundreds of millions of messages per second, in total. It supports transient pubsub, unreliable request-reply, pipeline, and peer-to-peer enterprise communication patterns. ØMQ merges messaging with the network.

The message queue is a form of asynchronous service-to-service communication where the messages are stored on the queue until they are processed by the consumer and the broker. Although several commercial and open-source AMQP implementations are available, most of them are predefined client(consumer)/server(broker) implementations, requiring a central communication node (broker) to process and route the messages. Although these AMQPs make use of the low-level socket networking layer for low latency communication, in many cases, they lack the ability to be multi-platform and multi-architecture implemented, they may support limited message types and in most of the cases they need a central broker (no support for direct peer-to-peer communication between the consumers).

In this paper we present a practical scenario of an operational communication stack for an embedded IoT device, thus the SmG, supporting (Figure 1):

• Input from a ripple control receiver through the digital I/O pin header of the board,
• Data acquisition from electrical devices (e.g., PV Inverters, power quality analyzers, charging stations), sensors and electrical equipment and control of this electrical equipment,
• Asynchronous communication on top of the low-level message transport socket library, providing real-time communication (8M msg/sec, 3μsec latency) between the SmGs, the decision center (broker) and the interconnected devices.

In our case scenario, the embedded IoT board, thus the SmG, is an ARM based Single Board Computer (SBC) running a customized Linux Kernel, supporting a full network stack (IPv4 and IPv6 routing, VLANs, VPN tunnels etc.), encryption protocols, clustering and software upgrade and remote administration mechanisms.

The SmG is able to 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 controller, USB headers and basic network controllers (ethernet, wifi and Bluetooth).

For communication with external devices, in terms of communication software, the SmG supports a big number of industrial communication protocols (Modbus, CAN, IEC 61850, IEC 60870-5-103, KNX etc.). Regarding the SmG’s AMQP based on the ØMQ library and in contrast to other competitive solutions (e.g. the widely used MQTT framework), it is able to support “brokerless” peer-to-peer communication (SmG can talk directly to another SmG) without the need of a central broker for the routing of messages, constituting the system more effective and autonomous and with shorter response time periods and less bandwidth needs (almost half the bandwidth, when no central broker is used). Moreover, in a brokerless implementation, Single-Point-of-Failure will never occur; if the broker “crashes” the whole network becomes unavailable. The architecture is show in Figure 2.

Last but not least, the communication protocol and the ØMQ communication library of the SmG, offers an open SDK that supports various programming languages and frameworks (ANSI C, C++, C#, Objective-C, .NET, Go, Python, Node.js, Perl, 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 (Linux, *BSD, Mac OS, MS Windows), constituting the system expandable without restrictions and propriety licenses.

At the block diagram of Figure 3, the prototype of the IoT embedded Multiprotocol Gateway (SmG) is depicted, together with the communication with the external units (measuring devices, sensors, etc) with OSI model correspondence (Open Systems Interconnection model).

For the development of the SmG, in terms of firmware and in terms of software, the OSI Layers 1, 2 and 3, must be defined as well as their interconnection to the OSI Layer 7, which is essentially the software that implements the communication with all measuring devices and sensors. Especially for OSI Layers 1, 2 and 3, the connection options to external measuring devices as well as to sensors (RS232/RS485/Digital or Analog, serial/ethernet/wifi) have to be supported, as well as to the management units and to the data storage servers (ethernet/wifi, Bluetooth, LoRA, NB-IoT, 3G-4G-5G-LT, etc).

Due to the vast number of protocols and communication and security options that must be supported, it is essential that the SmG must have sufficient CPU power, which the modern ARM based low-cost embedded SBCs provide. Such an implementation with a single Microcontroller Board (i.e. an Arduino board) is not possible, due to the small memory and the low processing power (e.g. it is impossible to implement an IPSEC TLS-2 VPN tunnel using a 16-bit microcontroller).

A typical market SBC is shown in Figure 4.

The CPU (Sunplus SP7021) is shown, 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 under consideration, that for a large-scale implementation, the final redesign of the SmG board, will be a stripped down version of the typical boards of the market, including only the controllers and peripherals needed for communication for the custom implementation and excluding all the unnecessary controllers and peripherals (sound, GPU, HDMI, Micro SD, USB Ports etc.), which will lower even more the cost of the board.

3. Distributed generation 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 regarding the Distributed Generator (DG) impact on the Point of Common Coupling (PCC).

Most of the modern PV inverters integrate control auxiliary contacts through which their state (ON/OFF/Output power) can be altered through a ripple control receiver signal while in many cases, the inverters support to be connected in groups, altering the state of each group (ON/OFF/Output power) by the same ripple control receiver [7,8,9,10].

In the cases where there is a motorized central circuit breaker installed on the production side of the Distributed Generator (DG) unit, the DG’s production state can be altered through the auxiliary contacts of the circuit breaker, connected to the ripple control receiver. This is the optimal way to perform distributed generation control using ripple signaling, affecting only the production side of a PV station, and not the auxiliary side (cameras, electric doors, fire detectors, internet connectivity, etc) (Figure 5). Similar techniques, but in simulation and laboratory scale, are proposed and tested by the authors in laboratory scale [11,12,13].

The results of the ripple signaling control have been well described in simulation scale by the authors in [14,15]. These papers present the methodology and describe the technological requirements for exploiting ripple signaling systems to control DG in the Distribution Network as a method for RTGM. At these papers, a part of the Greek distribution network with increased penetration of PV power plants is simulated, with and without ripple signaling control, for various operational scenarios. The results of the simulation scenarios determine the RTGM operations (ripple control signaling) which on specific PV plants should be applied. These simulation results also highlight the improvement of the voltage profile and of other power quality indices along the feeders during the RTGM operations.

However, when it comes to applying the Distributed generation control and demand response technique in real case scenarios, two main problems arise:

a) Interoperability and compatibility problems with other communication protocols (e.g. missoperation with smart loggers of different inverters etc.) and

b) Feedback to the DNO of the current state of the solar parks (generated power, current state of the Main Circuit Breaker etc.). Performing DG control and demand response through ripple signaling provides no feedback to the decision center (DNO).

4. Ripple signaling and SmGs interconnection

To overcome and solve these two practical but important problems, the SmG is able to communicate with the PV inverters, either directly or through a potential existing smart logger already communicating with the solar plant’s inverters, get the signal(s) by the ripple signaling receiver, reduce the output power of the solar plants in the desired level and also inform the DNO with the required feedback.

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. Although during normal operation, the SmGs are communicating with the broker (DNO) through the AMQP, exchanging messages and controlling the connected devices and equipment without the need of the ripple signaling receiver, in a potential network communication loss 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 won’t be able to get feedback of the current state of the DG from the SmG. (Figure 6) [11,12,13,14,15].

5. Small-scale pilot application

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

The selected PV plant is one out of a total of 169 PV DGs at the region and is also one out of 45 of them with an installed capacity larger than 95 kWp, where the total installed capacity of these 45 DGs reaches 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 [12,13,14,15] by the respective software of the Greek DNO (HEDNO).

The simulation takes under account four scenarios [11,12,13,14,15] as part of RTGM operations due to scheduled maintenance works or due to grid reconfiguration because of a fault or 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 can’t be measured accurately, limiting the RTGM including any load transfer operations, due to thermal capability or to voltage limits of the MV lines.

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

For the small-scale pilot project, an SmG (Raspberry Pi B+ model running NetBSD 9.1) and a Ripple Signal Reciever (FMX 511 0C33) are installed at the Substation of the selected PV plant. The generated output power of the PV Plant will be controlled on demand by the user/broker (DNO). The control can be applied in two separate methods, either by sending pulses through the ripple control receiver or directly through the AMQP over the internet. Regardless of the control procedure used, the SmG will be providing real-time feedback and monitoring data through the AMQP to the broker.

The installation of the needed equipment, thus the Ripple Control Reciever 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 INPUT at state HIGH 3.3V DC), through a NO auxiliary contact (11-14) of a relay. In our case scenario, the SmG has access to the internet through a 4G 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 performed, 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 by the user/broker (DNO) 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 ouput, frequency, Voltage etc.) was sent in real-time to the broker, while also there was real-time feedback to the broker of all the control operations performed (i.e. receive pulse from ripple control receiver, lower generated output etc.), all these through the AMQP.

6. Discussion

During the pilot application, the SmG was real-time monitoring and controlling the DG output power of one PV plant. The next stage of the research is a large-scale implementation (i.e. installation of SmGs and Ripple Control Receiver at the 45 major DG plants at Kastoria region) providing real-time measurements and real-time feedback from the RTGM operations in order to verify the simulation results.

7. Conclusions

The main objective of this paper is to propose a cost-effective solution, utilizing the existing ripple signaling control system, already used by the DNOs, in conjunction with an innovative embedded IoT device that can monitor and control in real-time the DG output power, in order for the DNOs to execute RTGM on the distribution network, with accuracy, based on real-time data of the grid’s parameters, without worrying about violating any reliability indices, both of the consumers and of the producers.