SmartLVGrid Platform—Convergence of Legacy Low-Voltage Circuits toward the Smart Grid Paradigm

: The current electrical system is transitioning towards a new technological model called the smart grid. The transition duration between the traditional Electric Power System (EPS) and the full smart grid depends on well-designed strategic plans, implementing transition models that are as close to smart grids as possible, based on the processes and technological resources available at the time, but always considering their economic feasibility, without which no solution thrives. In this article, we present a method for convergence of the traditional power distribution grid to the smart grid paradigm by retroﬁtting the legacy circuits that compose this grid. Our results indicate that the application of such a method, through a distributed system platform with integrated technological resources added to the legacy infrastructure, converts these passive grids into intelligent circuits capable of supporting the implementation of a smart grid with a broad scope of functionalities. Based on a novel retroﬁtting strategy, the solution is free from the cost of replacing or signiﬁcantly modifying the legacy infrastructure, as veriﬁed in deploying other currently available solutions.


Introduction
The Electric Power System (EPS) is the largest globally implanted industrial complex ever recorded in human history. In existence for less than two centuries, EPS has a basic structure and operation that has remained practically unchanged since its inception. However, this scenery has been changing, and a new type of EPS is emerging, called smart grid-it is the evolution and the expected substitute of the EPS. It acts as a convergence platform of several technologies, aggregating and applying to the EPS-communication resources, electronic control, automation and distributed computational processing-to achieve excellence in its application purpose. Given the size and value of the assets of the system still in use, it is unlikely that its transformation can take place via a drastic overhaul. It is more likely to change gradually through strategic implants of distributed control and monitoring systems within and adjacent to the existing electricity grid, with the aim that this organic growth will allow electric utilities to follow an evolutionary trajectory, shifting more of the old grid load and functions onto the new grid, thus enhancing their critical services [1].
Technology, like science in general, is established from paradigms, so scientific and technological advances only happen as a result of these breaking down, and paradigm shifts. These advances can happen intentionally, i.e., through prior planning (design) or in an unintentional way, at the 2. The adaptation of traditional power grid to establish transition systems as close as possible to a SG.
Among these options, the second one has a higher degree of compatibility with the economic reality of developing countries such as Brazil (the host country of this study); however, this strategy was also used in the developed countries when, in the first decades of its introduction in this new model of an electrical system-Smart Grid. Two technological platforms are highlighted in this context, SCADA (Supervisory Control and Data Acquisition) and AMI (Advanced Metering Infrastructure) systems. The first is adapted to the electrical system from the manufacturing and transformation industries and the second resulting of the evolution of the first consumer telemetry systems implanted since the 1980s. Over time, both SCADA and AMI have gone from being rigid and closed models to becoming flexible and generic (open) platforms in the context of their application domain. Currently, any application that obtains operational data on a system to control and optimize this system can be designated as a SCADA system.
The first SCADA systems have been developed for more than 50 years [3], initially aimed at the implementation of centralized monitoring and control systems of industrial plants in confined space (delimited), but evolved to serve geographically distributed plants as well. The generic architecture of a SCADA system comprises controller units, network interfaces, input/output devices, communication equipment, and supervisory software. Due to the systemic robustness of its architecture, the SCADA platform is currently a standard used in the implementation of monitoring systems and control of critical processes, which are common in power generation plants, substations (of transmission and distribution), and transmission and distribution grids (of Medium Voltage). Designed exclusively to support the EPS consumers billing, AMR (Automatic Meter Reading) and MDM (Meter Data Management) technologies are precursors to the AMI system. This one, in turn, extends your function, based on bidirectional communication, also to the control and monitoring of End Users (EUs) of EPS remotely, who can be both simple consumers and prosumers as well [4].
The SCADA and AMI platforms follow opposing but complementary directions as regarding their applications in traditional EPS (See Figure 1). The first was used initially in the generation plants and, over time, it advanced penetration into the transmission grids and generation unit interconnection bus, reaching the substation automation and the supervisory control of MV grids. The second one, basically applied to end-user management support (consumers and prosumers), initially aimed at LV grids and subsequently also serving medium MV grids. The smart meters-core device of AMI architecture-is customized to the performance of the functions necessary to the management of EUs [5]. In turn, the PLC (Programmable Logic Controller)-primary device of the SCADA architecture-is a device designed for the functions necessary to the automation and supervision of critical processes, so that could hardly one replace another in its services specific. As shown in Figure 1, neither the SCADA nor the AMI standard encompasses in their respective architectures all the segments and elements that make up the LV grid (the "shaded area" painted in gray in the figure). In this way, the solutions developed based on these models end up neglecting the systemic characteristics of these grids and limiting the scope of SG functionalities that they can implement in such systems. The LV grid is the most extreme segment of the traditional EPS and most significant DS contact region. The MV grid also corresponds to an interface zone with the DS; however, it is in the LV grid that most of the EUs of the electrical system (typically 80 to 95%) are connected, which demand together something around 40 to 70% of all energy generated and delivered to the distribution system. Over time, the EUs has left the status of mere consumers it had a few decades ago, and some have now their own installed generation capacity, whose surplus can be supplied to the system (This type of EU is called Prosumer). As a result, there is currently an expansion of Energy Resources (REs) in the DS, based on a matrix composed of clean, renewable and intermittent micro-sources (photovoltaic, wind, among others of lesser expression) distributed mainly among residences and small commercial units of the LV grid. Besides, the architecture and the operational and structural characteristics of an LV grid is peculiar and very different from those observed in MV grids; so, the approach used in one system hardly applies to the other concerning the development and implementation of SG solutions. In this paper, we propose a novel platform dedicated to the implementation of SG functionalities in LV circuits, whose architecture is positioned in the gap established between SCADA and AMI platforms, for SG applications in these grids. The following are the combined aspects that characterize the scientific contribution and originality of this proposal.
1. Defines a non-proprietary method for retrofitting legacy LV grids, aiming to convert them into intelligent circuits, establishing the transition model to the SG paradigm (SG convergence) of these grids; 2. Based on the SoS (System of Systems) approach, it establishes a model that implements advanced metering properties combined with supervisory control and autonomous specifically in distribution power grids (outdoor type). However, the model is flexible enough to support deployments also in indoor type electrical grids (generalizable), whether of industrial, commercial, or residential buildings; 3. Presents a generic platform to support the implementation of an open scope of multi-functionalities of intelligent networks in systems adapted according to the method that proposes.

Initial Definitions
Initially proposed by the same author in [6], the SmartLVGrid platform is a model that describes a strategy (method), a structure (components and system architecture) and a set of protocols applied to the convergence of LV distribution grids toward SG paradigm, from the retrofitting of the legacy circuits that compose it (the tool used by the method). Thus, the retrofitting method is, in fact, an integral part of this platform and corresponds to the strategy proposed by it, such that its description already includes the method description. However, the following we present a synthesis of the SG convergence method propose in this paper, which involves the following steps and procedures: 1. Points of Interface (PoIs) Definition on the Legacy Layer-This step corresponds to the process aiming to identify Coupling Points (CPs), in each of the three domains of the legacy plant (LV circuit), for the installation of electronic units (defined in the Middleware Layer) capable of carried out network communication, automatic control and monitoring of variables and processes of interest to the implementation of SG functionalities; 2. Middleware Layer Implementation-This step corresponds to the process of specifying the hardware and firmware resources of the devices (electronic units) to be installed in the legacy plant, in order to provide externally, whenever requested, the Domain Retrofitting Functions (DRFs) execution in their associated CPs (according defined in step 1); 3. Implementation of the Interoperability Layer-This complements the previous step by scaling the software and hardware resources required to support the implementation of the protocols and all the necessary logical infrastructure for the interconnection of the DRF Servers provided by the Middleware Layer and the client applications dedicated to the implementation of SG functionalities, such as the Automatic Detection/Correction of Phase Unbalances.
Below is the detailed description of the proposed platform. Based on a layered representation, Figure 2 illustrates the SmartLVGrid stack within the LV distribution system. The illustration covers all the layers provided in model, including the Coupling Points in the Local Level (LL), i.e., the LV circuit-Legacy Layer-and the interaction interface with the Center Level (CL), i.e., the power utility's Supervision and Control Center (SCC)-Supervisory Layer. Given the geographical separation scale between CL and LL, the model recommends the use of medias and Metropolitan Area Network Interfaces (MANI) to ensure the connection and communication between these sites. The type of media, protocol or communication technology used in the implementation of this Metropolitan Area Network (MAN) is transparent to the model since any particular specific recommendation would imply at an application scope restriction and correlating its life cycle with the specified technologies life cycles, typically very short. Thus, the model abstracts this level of specification, and such definition is left to the criterion of convenience and technological availability existing in the particular context of the application. In other words, the model is so compatible with implementations in which the connection between LL and CL is given through fiber optic links, as it is for the use of Power Line Communication or any radio link technology such as WiMax, GPRS/GSM (2.5G, 3G, 4G, etc.), LoRaWAN TM , in addition, others that may arise in the future.
As Figure 1 shows, the core of the SmartLVGrid platform is comprised only of the Interoperability and Middleware layers. The first has interfaces with the CL-Supervisory Layer-via a MAN connection, and the second has an interface with the Legacy Layer-the LV circuit-through of Coupling and Interaction Nodes (CINs) connected on the point of Interfaces (PoIs), also named a Coupling Point (CP). These PoIs are carefully chosen in each domain that makes up the LV circuits, aiming to perform micro-processes (operational primitives) classified as Domain Retrofitting Functions (DRFs), according to those listed in Table 1. These Operational Primitives (OPs) are processes that in the legacy mode of operation, are typically performed manually by a field operator; however, with the retrofitting implemented through the CIN, begin to be executed by automatic control; hence they are classified as DRFs.

Synchronization.
It allows the control of the start and ends time of the participants' tasks in the execution of a process.
The interaction between the two layers that make up the core of the SmartLVGrid platform-Middleware and Interoperability-occurs through Service Nodes (SN). These are logical units (virtual sockets) that play an essential role in performing supportive and complementary functions to the running of DRFs. Table 1 lists the Classes and their OPs, respectively, as well as the description of the purpose of each one. The execution of a Computational Support Function (CSF) is always restricted to a domain and internal to the layers of Middleware or Interoperability, and can be requested or triggered within an automatic routine. It handles data received or required from the execution of the other OPs. An Inter-Domain Support Function (ISF) differs from a CSF because its execution has an external repercussion (extrapolate layers) and not restricted to a domain. Throughout this section, we will see that through the coordinated and combined use of these eight OPs, it is possible to implement a broad scope of macro-processes compatible with the SG paradigm, i.e., SG functionalities.
The typical configuration of a legacy distribution system encompasses only one Operation Center of the Distribution (OCD) at the utility and the physical plant in the field (LV grid). In this context, the Distribution Operation (DO) is typically performed by field operators (manually) with little or no automation capability available, under the asynchronous coordination of OCD. The DO (or only Operation) corresponds to the set of processes performed in the LV grids to guarantee efficiency levels, QoS and functional compliance of the distribution system, in addition to billing accuracy. These processes are based on the execution of primary functions equivalent to those listed in Table 1. The primary purpose of the SmartLVGrid platform is to establish a model (metamodel) applied to the conversion of a passive system (i.e., legacy LV circuit) to one endowed with communication and automation capabilities. Thus, it allows for both the remote control and supervision of the distribution plant by the OCD, besides of the local and automatic operation (autonomous) of the same. Figure 3 illustrates the vision concerning the composition (association) of the SmartLVGrid architecture with the LV distribution system. Notice that the model imposes no structural change in the Legacy Layer, and likewise for the Supervisory Layer (in the OCD), indicates only one front-end application dedicated to the supervision and control support of the installation adapted. In fact, these two layers are not typical of the model, which effectively is formed only by the two intermediate layers, i.e., the Interoperability and Middleware layers, as previously mentioned. Through the processes implemented in these two layers in interaction with the other two natives layers of the distribution system (Supervisory and Legacy), the operation receives the automation support necessary for the total execution (or of most) of the functions demanded to the field teams. It is worth noting that the MAN connection between the LL and CL enables the SCC performs the supervisory control of the LV distribution plant remotely. In this context, the SmartLVGrid platform corresponds to a type of SCADA system. However, from the point of view that the LV circuit is only a load of the MV grid, the SmartLVGrid platform is considered to be an advanced metering implementation and therefore a type of AMI system. In the traditional system, OCD concentrates all the Business Intelligence (BI) of the distribution, reporting it to the field operators. This condition is justified in the context of an entirely passive grid (poor or devoid of automation resources) and, therefore, with a closed and limited scope of operation. However, from the retrofitting of the LV circuits (i.e., legacy infrastructure based on the traditional type of EPS.), according to the SmartLVGrid model, it is possible to decentralize the BI, sharing it with the retrofitted LV circuits, given the processing capacity and autonomous automation of these systems that enables the implementation of a broad and open scope of locally controlled functionalities. The need for autonomous operation becomes evident when we consider the limitations of the fully centralized supervision and control of tens of thousands or hundreds of thousands of LV circuits geographically scattered in one region. In the SmartLVGrid model, while Smart Circuits can control and execute their operation autonomously and locally, it can also be subordinate to the SCC. Thus, in some processes, it can cooperatively act with the other smart circuits in a manner compatible with the configuration of a multi-agent system.

The SmartLVGrid Stack
This subsection is dedicated to describing the structure, composition elements, and purpose of each of the layers that make up the SmartLVGrid stack, referring only to the LL.

The Legacy Layer
As mentioned previously, the Legacy Layer is not effectively part of the SmartLVGrid metasystem. However, its mention as a layer in the composition of the stack of this model is for definition of its interface with the Middleware Layer and implementing of the retrofitting strategy used by the model, through the establishment of a hybrid transition system, aiming to the convergence of the power grid towards the paradigm smart grid. Under this strategy, the model provides the identification of PoIs where retrofitting modules can be installed, with the aim of the execution of DRFs (See Table 1) without requiring any changes in the existing infrastructure (legacy).This is one of the main novelty of this proposal since the currently available smart grid solutions typically advocate the establishment of a new power grid infrastructure. For example, in the implementation of advanced metering solutions such as AMR and AMI, the primary criterion is the installation of smart meters replacing installed meters [7,8]. Figure 4 provides a representation of the Legacy Layer, i.e., the LV distribution grid, from the perspective of a SmartLVGrid model. In (a), the left-hand side of the figure, a typical single line diagram is presented and, in (b), the right-hand side of the figure, a less rigorous representation, but with the addition of graphics detailing the structural characteristics of the grid. Notice that the legacy LV grid is subdivided into three domains, which are indicated in part (a) of the figure: Transformation Post (TP), the entrance feeder point in the LV circuit (LVC); the Secondary Powerline (SP), which is the means of connection; the EU, which corresponds to the load or eventually, an auxiliary source in the Prosumer case. A fundamental premise of this work is that the SmartLVGrid platform applies to the convergence of traditional LV circuits to the smart grid paradigm without requiring (significant) changes in the legacy plant, to provide a lower-cost technological transition, as well as the systematization of this process. Thus, it employs a strategy based on retrofitting at specific and carefully chosen points of this grid. Table 2 lists such points in each domain, and their analysis provides a glimpse into how relevant the decomposition of the legacy grid into domains is, as established by the model, for the definition of PoIs (or CPs) appropriate to the process in question.  It is possible that in addition to these, other PoIs can be indicated or identified, depending on the specific functionality that needs to be implemented. However, these were chosen based on recognized demand processes (ex.: detection of interruptions), and also, in the operations typically performed by the field operators (ex.: the meter reading or switching of the connection phase of a single-phase consumer unit). If in a specific circumstance, there is a need to control the connection/disconnection of the entire secondary circuit (either by automatic local process or by remote control), it would be necessary to attribute to TOC, also DRF number 3 (DRF-3). However, this is not a typical process, and for this reason, the intercept of the TOC line with the DRF-3 column in the Table 2, it is not marked with 'x'.

The Middleware Layer
As previously mentioned, the SmartLVGrid stack has two exclusive layers, Middleware and Interoperability, since the Legacy Layer, as its name suggests, refers to the existing electrical infrastructure at the LL, i.e., the legacy LV circuit. On the other hand, the supervisory layer refers to the front-end implementation (supervisory system) installed in the Management System of the Operation (MSO) used by OCD in the center level (CL), i.e., the electric power utility. Middleware is the layer that operates at the lowest level of the platform, directly interfacing with the electrical infrastructure (Legacy Layer) through CPs (or PoIs). The SmartLVGrid model describes the Middleware Layer as a distributed composition of CIN that, installed in the Legacy Layer (Coupling), they implement DRFs (Interaction); that is, the Middleware Layer transforms processes executed by field operators, typically in a manual way, into automation variables to the external control that can be either a supervisory system or an autonomous application (See Figure 5). It is worth mentioning that CIN, as well as the Middleware Layer itself, is an abstraction; in other words, it is a model of part or all a particular physical implementation. In this case, microprocessor units (hardware), loaded with compatible firmware, perform the CIN function (i.e., physically implement the model) at the level of the interface between the Middleware and Legacy Layers, through sensor devices and actuators suitably installed on the CP. In another paper [6], this same author named this microprocessor unit as ACU (Automation and Communication Unit), due to its composition and functional characteristics. According to the Middleware Layer (given in the SmartLVGrid model), CINs perform DRFs on the PoIs, and ACUs implement CINs (CIN is an abstract entity, and the ACU corresponds to the reference model for the physical implementation of the CIN). Compared to SG technologies applied to the distribution system and widely diffused in the state of the art, the ACU is for the SmartLVGrid platform, in the same way that the PLC is for the SCADA standard and the Smart Meter for the AMI systems.
The composition and resource specification of ACUs (internal components) depends on the domain of their respective associations, and the Middleware Layer reflects this by specifying distinct types of ACUs for each of the Legacy Layer domains. Just as the word 'accelerate', when used for both a car or a bicycle, means very different implementations between the two cases, so do the DRFs concerning the domains of implementation. Figure 6 presents a block diagram representation of the generic ACU model (structure and composition). The definition of the number and characteristic of the ports, In/Out, Get, and Run, as well as the processing and storage capacity of an ACU (internal components) depends not only on its association domain and control/monitoring of the desirable level but also on the role assigned to it in the Interoperability Layer (described in the following subsection).
Hereafter, the ACUs are given the following designations, according to the site of their installation: ACU-TP for ACUs installed in the TP domain; ACU-SP for ACUs installed in the SP domain, and ACU-EU for ACUs installed in the EU domain. By definition of the model, the Middleware Layer gives the specification of the number and technical characteristics of two port types that connect directly to the CPs, the 'Get' and 'Run' ports, that are, hereafter referred to as Port-G and Port-R, respectively. This specification includes associated hardware and firmware, according to the domain, quantity, and type of variables to monitor and control. Through G-type (Port-G) ports, variables are measured, and their values quantified, as well as the occurrence of operational limits violations or any non-conforming events (sensing) can be detected. In turn, through R-type ports (Port-R) it is possible to command drive operations. Based on the definition of PoIs given in Table 2, a total of four Port-Gs and only one Port-R were specified for the ACU-TP. Port-G can measure electrical quantities in the TOC (current, voltage, energy, power, etc.) and thermal variables such as the temperature of the transformer body. In addition, it can monitor the Drop Out Fuse Cutout (DOFC) status (active or non-active), ground conductor status (present or absent), the occurrence of short circuits in the transformer secondary output, power interruptions, and so on. In turn, Port-R, in this case, is applied to the DOFC drive control, if this is controllable. By the same criterion as that described above, since the SP domain of the Legacy Layer has only one PoI (i.e., the Powerline Secondary Bus-PSB), an ACU-SP with only one Port-G and one Port-R was shown to couple to and interact with this PoI. Through the Port-G, this ACU monitors electrical variables of the PSB branches (measuring and sensing), as in the previous case (ACU-TP). In turn, through the Port-R, it can implement automatic disconnection and reclosing (run) processes of branch circuits of the PSB.
In the EU domain, such as in the SP, only one PoI (i.e., the Service Entrance Panel) was identified. Then, under the same criteria as those used in the previous cases, the ACU-EU is designed with only one Port-G and one Port-R. However, there is a particularity in this case that needs to be emphasized. According to the retrofitting strategy given by the SmartLVGrid model, the ACU-EU coupling on the Service Entrance Panel (SEP) should aim to achieve retrofitting of the electric power meter in order to equip it with the same functionalities as those of a smart meter. Therefore, the Port-G of this ACU must interact with the installed meter to collect its measurement data. In turn, through its Port-R, the ACU must be able to perform automatic disconnection/reclosing processes of the user's circuit and, in the case of single-phase users, change the connection phase of their feeder branches. The internal dimensioning of the ACU (processing capacity and memory) is given based on the specifications established by the Middleware Layer in its interface with the Legacy Layer and the Interoperability Layer, respectively, i.e., according to the demands of firmware and hardware required to execute DRFs in the PoIs through the G and R ports, as well as, the external communication, enabling the ACU acts as a service provider in a distributed system.

The Interoperability Layer
By specifying the Middleware Layer, ACUs are devices configured to operate as DRF Servers; however, it is worth remembering that the locations of these units are scattered throughout the LV circuit. The Interoperability Layer defines the rules, criteria, and infrastructure necessary to connect and organize these distributed objects in a hierarchical network that promotes access to such services (functional features), as well as coordinated and cooperative interactions between these units. Furthermore, the Interoperability Layer specifies a distributed computing system, using these devices, for providing back-end support to the top logical level of the system, the level of the application running the BI, either as a front-end solution in the MSO or autonomous processes running locally (LL).
As specified by the Middleware Layer, ACUs differ from each other according to the LVC domain of their respective installation. An intrinsic hierarchy, perceived when considering the repercussion and comprehensiveness of the processes performed by each of these ACUs, justifies such a definition. Consider, for example, the execution of the DRF-3 (On/Off-switching via Port-R) by the respective ACUs: while ACU-EU can disconnect a user's circuit, ACU-SP can disconnect a multi-user branch, and ACU-TP can open the LV circuit and disconnect all the users from this circuit. In another example, consider the implementation of the DRF-2 (measuring through Port-G) in each of the ACUs: while ACU-EU measures the energy consumed by only one user, ACU-SP measures the energy consumed in a branch with multiple users, and ACU-TP measures the energy consumed by the entire LV circuit. Notice that the coverage of the ACU-TP encompasses all the others, followed by the ACU-SP and the ACU-EU, whose comprehensiveness is the most restricted (limited) of all.
Consistent with the above remarks, the Interoperability Layer defines a new classification and nomenclature applied to the ACUs, assigning specific operational functions to each of them within a hierarchical composition. In the case, the ACU-TP is now called Coordinator (Cd), the ACU-SP, Sub-Coordinator (SCd) and the ACU-EU, Operator (Op). Thus, the model establishes a type of network that is formed by Operators and their respective Sub-Coordinator. The nature of this network type is purely operational; therefore, it is called the Slave Net. The central Coordinator forms another network together with the Sub-Coordinators. This network has a coordination-type profile; therefore, it is called the Master Net. As the names suggest the Slave Net is a hierarchical level below the Master Net, and subordinate to it. Figure 7 effectively illustrates the above statements. Internally, in the SC, the connection between the ACUs is through Local Area Networks (LANs), in this case, the Slavers and Master networks. These additional roles assigned to ACUs, as established by the Interoperability Layer, imply the need to incorporate additional resources into such devices, in addition to those already indicated in the Middleware Layer. Therefore, to meet these requirements, we verified that an ACU of the type Operator requires a communication module (transceiver) with a single LAN port for access to the Net Slave. ACUs of the type Sub-Coordinator require two LAN ports, one for access to Slave Net and the other for connection to Master Net. The ACU of the Central Coordinator type requires two different types of transceivers, one which is MAN type, with one port, for access to the Intercommunication Bus (see Figure 8) and another of LAN type, also with a port, for connection to the Master Net. Notice that in this way, the Central Coordinator naturally takes on an additional role, that of a gateway.  Figure 8 illustrates how the SmartLVGrid platform fits into the structure of the operation given by the traditional distribution system. In this case, the operation is performed on two levels interconnected by Interconmunication Bus: Centre Level (CL) that houses the Control Center (CC), also called the Center of Supervision and Control (SCC); and the LL that spans the retrofitted circuits (smart circuits). In addition, this same paragraph introduces the multilevel hierarchical architecture of that model, shown in Figure 7. In turn, Figure 9 shows a detailed view of this architecture, established based on a distributed configuration of the operation, in which two sub-levels make up the LL (i.e., the retrofitted circuit): Sub-Level 2 (SL-2) and Sub-Level 3 (SL-3); and to keep a description uniformity, we give to CL the nomenclature of Sub-Level 1 (SL-1).
A peculiar and noteworthy feature of this architecture is that the SL-3 is internal to SL-2, and both are contained by SL-1. The Middleware Layer specifies the SL-2 and SL-3, corresponding to the internal structure of an SC and which we now describe. Each SC has a Central Coordinator (Cd), which coordinates hierarchically smaller-circuits or µCircuits (µCs), belonging to the SC. In the SL-3, each µC has a single Sub-Coordinator (SCd), which coordinates the Operators under its coverage hierarchical. Remembering that, each Operator is associated with an EU respective and this can either be a typical Consumer or a Prosumer. Notice that this composition is analogous to that of an onion (i.e., layer within a layer), and if we persist in this approach, we enter the internal grid of the Customer Domain (CD), corresponding to Sub-Level 4 (SL-4), which is not in the descriptive scope of this work.

Test and Validation of Solution
This section is dedicated to the description of the test procedures and presentation of the analysis results obtained in the execution of these experimental tests, to establish an empirical basis for the validation of the solution proposed in this paper. As a test strategy, the assays were performed in a computational environment using the MATLAB/SIMULINK tool in the implementation of a reduced and simplified model of the SmartLVGrid platform installed in a low-voltage circuit. As shown in Figure 10, the model simulated covers a total of four ACUs, one ACU-TP, and the other ACU-EUs. The ACU-TP is a Coordinator-type device that, coupled to the SP entrance/PBS (See Table 2), monitors the voltage (V-RMS), and the apparent power (VA), through its GET port, in the secondary output of the distribution transformer installed in the TP, running the DRF-1 and DRF-2. In turn, the ACUs-EU are Operators-Type devices that, installed respectively in the three single-phase EUs, monitor the consumption (VA), through its GET port), as well as control the connection to the power grid of each of these consumer units (EUs), through its RUN port (In this case, the whole of the four DRFs are performed).
The simulated model, although simplified, is sufficient for the validation of the functional properties of the SmartLVGrid architecture. The experiment was divided into four stages that correspond to four events (T1, T2, T3, and T4), through which the four primary SG functionalities, listed in Table 3, are tested for validation. Figure 11 shows the graphs, respectively, of the voltage (V-RMS)-at the top-and apparent power (VA)-at the bottom-measured in the SP concerning to the complete simulation cycle (T1 to T4). In turn, Figure 12 shows the signal of the apparent power (VA) taken at the meter output (with the load) also during the complete simulation cycle (T1 to T4). This experiment aims to perform the experimental demonstration of the structural and systemic capacity of the SmartLVGrid platform for the implementation of SG functionalities. The process is done through the OPs execution test listed in Table 1 concerning compliance to the basic requirement of the Middleware Layer-establishing that an ACU should function as a top-layer 'DRF server'-. Besides, it was verified the effectiveness of the protocols established by the Interoperability Layer to support hierarchical interactions among ACUs, data via exchanges of data messages, and service requests.

Simulation Report
This subsection reports the procedures performed for the testing and validation of each of the four SG functionalities listed in Table 3, which are directly correlated with events generated in discrete intervals throughout the simulation (simulation step), as indicated in Figure 11. Thus, in each sub-topic below, the flow of the test procedures, the data obtained through the visualization of a system operating status indicator panel (Supervisory Panel), with colored flags, and the validation results verified, are presented.

Assay of the Telemetry Functionality
Telemetry is a standard functionality of the SG paradigm and typical of the supervisory mode. In this assay, the simulated implementation routine of this functionality is summarized in the flow diagram given in Figure 13 (the light-colored boxes represent processes that were not performed in this experiment). The test event of this functionality, according to the model given to the SmartLVGrid platform in question, occurs in the T1 interval. In it, the simulation establishes the compliance condition in the power supply that can be verified, through the level of the voltage and apparent power signals in the TP and EU. To validate this functionality, the Supervisory Panel given in Figure 14 emulates the screen of a supervisory system installed in the SCC, properly signaling the operating status of the electrical system.
The status signaling observed in the Supervisory Panel validates the execution of the Telemetry functionality performed by the model. Please note that the colored indicator of the Coordinator (to the left of the panel) is painted light blue, signaling the existence of compliance in the power supply. In turn, on the Operator side, signaling indicates that both EU-1 and EU-3 are connected in Phase A, while EU-2 is connected in Phase B (not having any load in the C-Phase). The accuracy of these data is confirmed by inspecting the voltage and power graphs showed in Figure 11.

Assay of the Outage Detection Functionality
Outage Detection is also a standard functionality of the SG paradigm and typical of the supervisory mode. In this assay, the simulated experimental routine of this functionality is summarized in the flow diagram in Figure 15, which also includes the Restore Detection Process. The experimental test of this functionality occurs in the T2 event, according to the model given to the SmartLVGrid platform in question. In it, the simulation establishes the occurrence of an outage interval that can be verified, through the inspection of the level of the voltage and apparent power measured in the TP and EU, as shown in Figure 11. For validating this functionality, we implement a Supervisory Panel (See Figure 16) that emulates the outage management screen of a supervisory system in the SCC. Since the colored indicator of the Coordinator is painted red, signaling the occurrence of an outage, we can conclude that the execution of the Outage Detection functionality performed by the model is validated (demonstrated experimentally). The signaling given on the Operator side is only to indicate the EUs active connections (circles painted light blue), i.e., it shows that the EUs connection status among the three phases of the SP bus remains the same as before the outage event.

Assay Loading Control Functionality
Unlike the previous two cases, the Loading Control is a standard functionality of the SG paradigm and typical of the autonomous mode. This assay concerns the T3 event and the simulated implementation routine of this functionality is included in the flow diagram in Figure 15, together with the Outage and Restore Detection Process. Notice that after the Outage occurrence detection, follows the execution of the DRF-3 that performs the OFF-Switching (disconnection of all the EUs) and this is indicated on Supervisory Panel given in Figure 17. The Loading Control, i.e., the EUs connection control on the SP bus, is a critical protection feature for the current distribution transformer during the restore process, since it can mitigate typical Inrush current effects in these events. In turn, for a restore detection, the DRF-3 performs an ON-Switching, but with a delay-the status of the Supervisory Panel changes only the restore indication, showing the EUs connection status unchanged-(See Figure 18).

Assay of the Phase Unbalance Correction Functionality
The Phase Unbalance Correction is a functionality that can be performed in autonomous mode (see Table 3), using only the internal processes of a SC, i.e., the Interoperability Layer specifications applied to ACUs (DRFs-Servers), with the Coordinator and Operators definitions. Figure 19 shows the flow diagram with the implementation routine of this functionality simulated in this assay (it concerns the T4 event). Notice that the whole process occurs locally with no demand for interaction with the SCC, which well-characterizes the autonomous mode.
In this experiment, the algorithm running in the Coordinator is not sophisticated, but is a simple procedure for proof-of-concept given through a forced unbalance simulation case, with EU-1 and EU-3 connected in phase A, EU-2 in the phase B and no load in phase C (see Figure 14). Figure 20 shows the result after completion of this operation.  In practice, the load-balancing occurs under the command of the algorithm and pre-configuration established in Coordinator. This ACU monitors the secondary output continuously and verifies, at the sweep, if the imbalance among the three phases has exceeded a preset threshold. When this level is exceeded and remains so for a specific time, the Coordinator sends broadcast messages to all subordinate Operators, requesting that they inform in which phase of SP their respective EUs are connected (i.e., send the connection-phase indicator), as well as their average loading during a preset time interval. Based on this data and the historical behavior of the load, the Coordinator runs the algorithm to calculate a new connection arrangement of these single-phase circuits among the three phases of Secondary Bus (SB), and thus return to within the tolerance range (maximum deviation established).

Analysis of Results and Discussion
We recall that by prior definition, the execution of all the assays occurred in a reduced but complete model of the SmartLVGrid platform. It is also worth noting that the test base already includes the implementation of retrofitting procedures, according to the proposed method, applied to the simplified model of an LV circuit. In other words, the ACUs used in the experiment were defined and installed according to the specifications given in the SmartLVGrid metasystem. Thus, the conformity of the results with the predicted by the model is evidence that supports its validation. Notice that in all the tests performed, the 'DRF Server' role, given to the ACUs (Middleware Layer specification), is evident. Similarly, the validation of the operation according to the protocol established by the Interoperability Layer was also demonstrated in the execution of the inter-network processes, through the OPs ISF-1 and ISF-2, under the hierarchy of ACUs, according to the predefined roles of Coordinator and Operator in this protocol.
The telemetry, the remote control connection of users to the power grid and Outages Detection are functionalities of recognized importance for any supervisory system applied to power grids and are considered to be typical smart grid functionalities [9,10]. The first two were implemented in the first versions of smart grid systems, evolving from the solutions in the AMR model to the present ones based on AMI model. The results indicate a complete adaptation of the SmartLVGrid platform to the execution of this type of functionality, with the advantage of the Coordinator acts as a gateway that provides the interface among the Operators and the SCC, requiring only a MAN link for this. The Operator is a module that retrofits the installed power meter, adding 'smart' features without the need to replace it. These two aspects establish a substantial difference concerning the AMI solution based on the installation of smart meters that replace the already installed power meters and operate by establishing individual links with the SCC. In this way, the communication network complexity, costs of implementation and operation of the AMI are notoriously higher when compared to the cost proposed by the SmartLVGrid model.
Remember that the AMI architecture is vertically hierarchical (centralized) composed of two levels-the user level (demand side) and the Control level (management side)-. Thus, it requires a star configuration communication network, where each US has, via smart meter, a point-to-point link directly with the SCC, although newer versions of the model support the use of gateways. The SmartLVGrid platform, on the other hand, has a multilevel architecture that enables the formation of operationally autonomous clusters on the demand side, i.e., management on the demand side effectively.
Although load balancing has been discussed for decades in several studies, as seen in [11,12], the approach based on the dynamic switching of single-phase loads between the three phases of the SP is still under-explored, possibly due to the absence of an automation infrastructure suitable for the implementation of such a process. The SC model provides this infrastructure, offering support for the execution of algorithms as proposed in works given in the bibliographic reference [13,14]. On the other hand, works like [15], provide evidence of the necessity of an automation infrastructure endowed with particular functional characteristics to support the implementation of dynamic load balancing in a low-voltage circuit. Notice that the architecture of this system is effectively aligned with that specified in the SmartLVGrid platform, which showed the validity of the solution proposed here in the implementation of this functionality-type as well.
The only viable way to realize an extensive smart grid is to develop a vision for the ultimate design of a smart grid and then make short-term decisions that gradually transform existing distribution systems into this future vision. Current smart grid reference models, such as AMI and SCADA have, for some time, provided supervisory operations (i.e., conducted under the supervision of a Center of Operation that concentrates the BI) in the traditional electrical system. However, these solutions typically present prohibitive costs at the application in LV distribution grids. On the other hand, numerous works contribute to the state of the art with specific implementations (unifunctional solutions) of type-supervisory (centralized BI) or autonomous implementations (decentralized BI), proposing radical changes to the existing infrastructures and specific adaptations to their solutions.
The method that forms the SmartLVGrid platform does not impose changes to the legacy infrastructure of LV circuits and, in a customized, optimized and scalable way, transforms these grids into SC. In the object orientation (OO) view, we can define a SC as an instance of the SmartLVGrid Metamodel, i.e., this structure is the Class that generates the SC Object. In turn, composing an SC, we have instances of Classes: Coordinator, Sub-Coordinator, and Operator. These instances (Objects) are devices designed with the Attributes and Methods of these respective Classes. Then, just as the use of OO programming facilitates the continuous development of new applications in computer systems, new smart grid functionalities can be implemented in SCs.

Conclusions
Although it is necessary to deepen the research, through the experimental analysis based on the implementation of physical prototypes, whether for laboratory (bench) or field tests, from the results obtained in this work, we can conclude that SmartLVGrid is a platform potentially: • Flexible and scalable, due to its modular and clustered multilayer architecture, where each LVC domain is equipped with a specific ACU that performs the function of DRF server (domain retrofitting) and also allows the formation of capable clusters to implement SG functionalities, through inter-domain interaction among ACUs (systemic retrofitting); • An open model and design pattern capable of conducting the transformation of legacy LV circuits into intelligent circuits, through a retrofitting process that does not impose critical changes or the legacy infrastructure, giving them the resources to implement an open scope of smart grid functionalities. Thus, the SmartLVGrid platform has an optimal cost/benefit ratio when compared to the reference models such as SCADA and AMI and closed-scope (unifunctional) solutions available in the state of the art since it does not impose replacement costs or radical changes in the legacy infrastructure (ex.: replacement of energy meters) for its implementation; • A reference model (metamodel) applied to the implementation of SG functionalities, both supervisory and autonomous. Its functional and structural features are sufficient to implement not only the functionalities tested in this work but also new ones to be developed in future works. Funding: This research received no external funding.