A new approach for distributed deployment of centralized algorithms in smart grid

.


I. INTRODUCTION
Many applications of control and management in historical grids present algorithms that can be easily deployed in a centralized manner. However, along with the development of smart grids, a centralized implementation can show shortcomings, such as high computation and communication costs, low fault tolerance capability, etc. [1]. Besides, with the current development of smart grids infrastructures, computing units are almost dispersed in the network. These available resources can participate in the management of the power system. With the size of this system increasing, the distributed implementation of algorithms becomes a viable alternative to centralized ones. Indeed, it can deal with more resilience issues while ensuring a proper replacement the conventional centralized controls [2].
However, there are still some drawbacks to distributed implementations that restrain their practical deployment. Firstly, there is a lack of programming abstraction [3]. For instance, consensus algorithms [4] (e.g., Metropolis, Finite-time Average Consensus algorithms, Maximum Degree Weight) present a convergence that depends on the network configuration. Secondly, there is a lack of convergence proof when the system scales up as well as a low convergence speed. For instance, the ADMM algorithm can be used for the distributed optimal power flow problem [5] but the convergence speed goes up to several thousand iterations for a small grid. The ALADDIN Algorithm is a possibility to improve the convergence rate of the ADMM method [6], however not proven in the case where the number of nodes increases. The slow convergence speed and the neglected communication delay lead to slow control and management of the power system. In a context where the speed of variation of the electrical quantities increases due to renewable energy integration, some bounds of the system stability could be more frequently violated and the power quality could also decrease. Moreover, the control and the management of smart grids in real-time require to deal immediately with changes in the power system.
For those reasons, in this paper, another approach is considered, that combine the advantages of both the centralized and decentralized implementations. This allows taking advantage of two paradigms while ensuring the response to any change of system, as fast as possible. Most of the imperative languages such as Java or Python support distributed programming in centralized memories. Nevertheless, that is not appropriate for a distributed paradigm in smart grids. Thus, in this paper, we approach the distributed programming with a declarative language, called Smartlog [7].
In [7], each smart device plays the role of a node in the IP network of the smart grids. Each node is a rule-based system with a local database and can operate simultaneously as a client and a server. Based on that architecture, a high-level programming of the data manipulation language Smartlog is developed to support the proposed distributed programming. A methodology, proposed in this paper, helps splitting a centralized program into distributed rules which are executed in multiple nodes of the grid.

A. Network architecture
Smart grids are considered as heterogeneous. It is composed of a lot of smart devices which are in charge of collecting data and establishing communications among them. Each smart device can be in charge of computations and communications at each node of the grid. Fig. 1 presents their typical architecture. There are four main components in the architecture of each node: • The Local database : stores the node's information in the infrastructure of the grid, such as parameters, the measured data which are collected from local sensors or directly from the network. • The Sensor interface: is set up to collect data from sensors, to store these data into the local database and to transfer the output values to the regulator in order to control the active electrical components. • The Rule engine: is the most critical part of the architecture because it supplies an environment to execute the declarative programs. In our implementation, the PostgreSQL trigger is used as a rule engine. • The Communication interface: is in charge of the interaction between nodes over the communication network. Received data, after unpacking, will be stored in the local database. The communication is developed based on the TCP/IP protocol and the transferred data are in the form of a JSON Object. Each participating node in the grid possesses the same architecture. This constructs an IP network in which each node can operate simultaneously as both client and server. That increases the robustness and reduces the damage when there is a single point of failure in the system [8].
The distributed programming is developed based on the available infrastructure of information network such as WiFi, 3G, 4G and is deploy in the test-cases of an isolated microgrid. Thereby, we assume that each node in the network is fully capable of communicating with all others.

B. The Smartlog language
1) The structure of a Smartlog program: The structure of a Smartlog program is presented in Listing 1 [7]: 2) Rule syntax: The Rule is in charge of defining the action which is executed in each node. The syntax of a rule in Smartlog is the same as in other logic programming languages:

Head : Body [terminator]
Where Body = B 1 , ..., B n , the body part of the rule, is a conjunction of terms. Each term in the body part B i can be a relational atom R(r 1 , r 2 , ..., r n ), a condition term or an assignment term.
3) Operators for the head part: The Head part holds the variables with assigned values in the body part and defines the execution of the rule. If all the terms of the body are approved, the execution of the head part (H) is launched.
By default, the execution of the head part is a storing mode, which means that the results will be stored in its local database.
The execution in sending-mode is expressed with: In this case, a destination's address should be marked with the symbol @ in front of the address variable.

C. How Smartlog supports distributed programming
Rules in a Smartlog program are grouped into many modules. Each module defines all actions of the system with the modification of a specific data_type. Measured data can trigger calculations in a local database. Meanwhile, immediate data is used to support data sharing. These data, transferred between nodes, are in the form of data_type. The data reception allows triggering consecutive calculations in other nodes. For example, consider two modules in two programs as follows: When the rule of node i in Listing 2 is executed, an atom named TmpC is sent to j. The module in Listing 3 will continue to perform its actions after receiving TmpC. With this mechanism, Smartlog can support fully distributed programming.

III. RULE DISTRIBUTION METHODOLOGY
In order to perform the same computation as a centralized program, the main problem of distributed programming is to separate rules from the centralized program and allocate them to nodes, when data are distributed on different machines. The methodology of rule distribution (DSLP method) is proposed to tackle this question. The general algorithm of the methodology is summarized in Algorithm 1: Algorithm 1 Distributed programming methodology (DSLP). Describe the data distribution in the network 3: for rule in program do 4: Rewrite the rule according to data fragmentation 5: for rule in the rewritten rules do 6: Evaluate all possibility of data communication 7: Choose the best decision of communication 8: Distribute the rule based on the best decision 9: Generate distributed programs The methodology of distributed programming is not presented in detail in this paper, for a reason of space. Instead, we focus on evaluating its applications. A centralized algorithm for a common issue in smart grid: over-voltage regulation.

A. A centralized algorithm in smart grid
The rise of the percentage of renewable energy penetration, especially Photovoltaic (PV) sources in traditional power grids risks power imbalances as well as quality loss of the energy. One of the most critical issues, when this energy integrated into the grid, is over-voltage. Many solutions have proposed to address this problem, and one of the practical approaches is Adaptive Active Power Capping (AAPC) [9]. The principle of the method is presented in Fig. 2.  [9]. Over-voltages occur in one or more nodes in the grid. The node presenting a voltage value over V c1 is called a critical node (CRI). In the AAPC method, computations are performed based on the critical nodes. We use the linear regression method to predict the upper power limitation (PLI) P j l of each PV source.
with ξ is a linear coefficient (SLOPE) calculated by the ratio of voltage variation (VVAR) and power variation (PVAR): If each PV output power production is below its upper threshold, then the over-voltage in the grid is correclty controlled. P ref j is the generated power threshold (PREF) of the j th PV and P j m (t 2 ) is the maximum PV output power at time t 2 based on the MPPT control. The upper threshold of the j th node is defined as: Each PV node has the same responsibility to participate in maintaining the acceptable grid operation. Thus, the power supplied or curtailed of each PV has to be based on a fair sharing. The power of each PV is then its limited power (PLI) or maximal power (PMA) as follows: with η the power curtailment coefficient (PCUR).

B. Setup and Smartlog implementation
The PREDIS distribution grid [10] is used as a test object in our case. This grid comprises 14 nodes, with five distributed sources, three asynchronous machines and static loads. This grid is simulated in MATLAB/SIMULINK and executed in OPAL/RT Real-time simulation. Each Raspberry Pi plays the role of a local computing unit which is installed near a distributed source (e.g., PV).
The description of the data schemes used in this application is presented in Table I.  An experiment was performed with three implementations of the same model and algorithms: a centralized java programming, a centralized Smartlog programming, and a distributed Smartlog programming.
1) Data distribution: In the distributed implementation, we suppose that each distributed PV source corresponds to a Raspberry Pi which is in charge of a local computing unit. Five Raspberry Pis were used in the experiment and eight data_types. These data_types are fragmented horizontally for each Raspberry.
A centralized Smartlog program and its data distribution are the input of the distributed programming methodology. Five distributed programs (corresponding to five Raspberry Pis) are its output.
2) Data sets: The data sets are generated automatically during the real-time simulation. The corresponding data in the simulated grid will be transferred from OPAL-RT to each Raspberry Pi.
3) Scenario: In the voltage control problem, we only consider the change of power injected at each node. In reality, the produced solar power depends mainly on climate and clouds. In the short time of simulation (the experiment is performed during 10 minutes), we assumed the load to be constant, with changes in the PV power. Fig. 4 shows the behaviors of the AAPC method as well as the response time of the implementation. The 7 th node of the grid is designed to be the one with the highest voltage value during the simulation.

A. The correctness
In Fig. 5, the response of voltage in the 7 th node is shown in the two Smartlog implementations (centralized and distributed). The voltage is controlled to not cross the upper bound (1.058 p.u.). The results being identical, the correctness of DSLP method is confirmed.

B. The performances
We use the response time to evaluate and compare the performance of each implementation. The response time should be considered within a given interval.
At the second minute of the simulation, the active power of the PV increases linearly and causes an over-voltage in the grid for the first time. The AAPC method is activated to restrain the percentage of power production. Continuously, when the grid is in over-voltage, the power curtailment inversely follows the rise of active power. That means the curtailment reduces linearly when the power production increases and exceeds the power upper bound.
In practice, the response time is defined as the interval between two consecutive reactions of the PV's actuator when the grid operates in over-voltage. Based on that, we estimate the response time of each deployment in the experiment, presented in Fig. 6.
We call t i is the average processing time of each rule, t c the average delay time for each communication and N is the number of computing units of the grid. The response time at a node is estimated as T res = T comp + T comm . With R j the  number of executed rules in the j th node, the analysis of the response time in this experiment is shown in Table II.   TABLE II  RESPONSE TIME FOR THE TWO SMARTLOG IMPLEMENTATIONS. Programming Tcomp Tcomm Although the computation load is shared over the network, the response time still depends on the communication time that depends on the characteristic of the grid. If the communication time is significant, then the response time with a distributed programming may be longer than the one of a centralized programming.
In the experiment, the statistic of the average response times for the three implementations are shown in Fig. 7.
The response time of the distributed programming is better than the response time of the centralized programming: max( i∈R2 t i , j∈R3 t j ) + Nt c < j∈N i∈Rj t i . In the real-time platform, the communication time among Raspberry Pis is indeed small. Besides, the query time in a distributed database is faster than in a centralized database. Moreover, the computing units operate in parallel and share the computing load, which apparently reduces the response time.

VI. CONCLUSION
In this paper, we proposed an approach to deploy a distributed implementation for smart grid applications. This approach not only overcomes the limitation of the distributed algorithms such as the lack of programming abstraction and the proof of convergence but also provides a simple implementation and a better response time than a centralized implementation. This is illustrated with an application of over-voltage regulation in a real-time OPAL-RT simulation and a network of Raspberry Pis, with the simple procedure of "programming in centralized manner and executing in a distributed manner". This approach can deal with the scalability of the number of nodes in the network, which validity is the the prospective research of this work.