Innovative Multi-Layered Architecture for Heterogeneous Automation and Monitoring Systems: Application Case of a Photovoltaic Smart Microgrid

Intelligent energy facilities, e.g., smart grids and microgrids are the evolution of traditional energy grids through digital transformation. These modern paradigms are expected to foster the utilization of renewable energies, sustainable development, and resilience of the power grid. A barrier found when deploying experimental smart grids and microgrids consists of handling the heterogeneity of the required hardware and software components as well as the available commercial equipment. Despite the fact that there is various architecture proposed in previous literature, it commonly lacks experimental validation, specification of involved equipment concerning industrial/proprietary or open-source nature, and concretization of communication protocols. To overcome such drawbacks, this paper proposes an innovative multi-layered architecture to deploy heterogeneous automation and monitoring systems for microgrids. The architecture is structured into six functional layers to organize the hardware and software equipment in an integrated manner. The open protocol Modbus TCP is chosen to harmonize communications, enabling the interconnection of equipment from industrial and energy scopes, indeed of open-source nature. An experimental photovoltaic-based smart microgrid is reported as the application case to demonstrate the suitability and validity of the proposal.


Introduction
The digital transformation of the energy industry is leading to the intelligent power grids, i.e., smart grids [1]. Microgrids also belong to this paradigm, comprising a set of distributed energy resources (renewable and/or nonrenewable), loads, energy storage means [2] as well as advanced automation and monitoring systems interconnected around a communication network [3]. Among the advantages that microgrids bring are the integration of renewable energies, environmental-friendly operation, stability, and improved performance [2]. In fact, smart microgrids are expected to significantly contribute to a more sustainable electricity delivery in future, decentralized paradigm of power systems [4]. Related modern concepts are the so-called Energy Internet [5], Energy Digitalization [5], the Internet of Energy (IoE) [6], and the Energy 4.0 [7], pivoting all of them around the interconnection of a variety of hardware and software nodes through communication networks for energy monitoring and management.
The path towards such frameworks requires the establishment of data communications among all actors, being able to work together seamlessly in an interoperable manner [8]. Regarding microgrids, reliable and secure communication networks are considered one of their main features [9] and an essential component to ensure a stable operation [10]. Therefore, the design of the communication network is a crucial topic for their development,

Literature Review
Conceptual architecture or frameworks are critical in distributed systems and networks to facilitate the understanding of roles, locations, and levels of abstraction of different hardware, software, and networking components [22]. As indicated in [23], a growth of research publications on automation architectures discussing the involved actors, functionalities, and their interconnections can be witnessed. In the energy context, layered architecture is needed to evolve from the traditional grid to the intelligent grid and to handle interoperability [18].
A starting point is the automation pyramid, defined by the International Society of Automation (ISA) in the ISA-95 standard [24], which establishes five levels for the vertical and hierarchical integration of enterprise and control systems. Another proposal oriented towards automation systems is found in ref 13, where four-layered architecture based on the standard Open Platform Communications (OPC) is validated through facilities in energy, industry, and education scopes. Regarding the Internet of Things (IoT), layered architecture has been proposed over the last years, but there is no consensus on a single IoT architecture [16]. A common approach consists of three-layered architecture comprising perception, network, and application layers [25]. A different scheme is found in the work of ref [22], which developed the so-called IoTecture, conceiving five layers to orchestrate software, hardware, and communication technologies. Likewise, there are a multitude of conceptual frameworks focused on the IoT applied in the industrial environment, such as Industrial IoT [26]. In the Big Data scope, there is also a five-layered architecture proposal for microgrids reported in [27]. For the concept of block-chains, there are also proposals of layered architecture, for instance decomposed into six layers [28].
For energy automation and monitoring, a number of layered frameworks are found. In fact, a lot of research has been conducted in the area of microgrids [23]. A four-tier architecture for microgrids control is reported in [29]. Srinivasan et al. [30] consider eight layers to divide the functionalities for smart grids, covering the path from local control (lowest level) to global optimization (highest level). For renewable energy-based microgrids, three layers are considered in the communication architecture proposed in [10]. Organized in three levels, layered architecture to promote interoperability in the smart grid context is proposed in [18]. A conceptual organizational scheme for microgrids is defined in [4], considering four functional layers. To deploy advanced metering infrastructure in smart grids, three-layered architecture is reported in [31]. For PV plant monitoring, architecture based on three layers is described in [32]. A layer-based architecture comprising four interrelated levels is proposed in [33] for energy management in smart grids, including edge and fog computing IoT devices. The work in [34] establishes a two-layered scheme for communications in multi-microgrid systems. Considering four layers, an IoT-based architecture for monitoring distributed solar farms is presented in [35]. Based on IoT concept, researchers have designed a four-layer hierarchical control scheme to automate microgridenabled buildings [36]. Marzal et al. [6] implemented a four-layered scheme for microgrids management framed in the IoE paradigm. In [37], agent-based architecture for demand side management in the context of microgrids and smart grids is proposed, considering six layers to implement the required functionalities. Focusing on microgrids, hierarchical control architecture is proposed in [38], consisting of four control layers. Cagnano et al. [11] implemented a control system for microgrids with a hierarchical structure arranged in five layers. With the same number of layers, an IoT-enabled framework for energy automation is proposed in [5].
The Smart Grid Architecture Model (SGAM) [39] was created in 2012 by the CEN (Comité Européen de Normalisation), CENELEC (European Committee for Electrotechnical Standardization), and ETSI (European Telecommunications Standards Institute) as a conceptual framework for smart grid design and deployment. It comprises five layers for the so-called Interoperability Dimension within a three-dimensional representation. An example of architecture in terms of SGAM is reported in [23], a methodology for interoperability testing in smart grids according to the SGAM approach is provided in [8], and of a microgrid studied as an alternative source to strengthen the station blackout power supply in nuclear power plants.
On the view of previous literature, the relevance and research interest of layered architecture for smart grids and microgrids has been clearly demonstrated. Nevertheless, research is still needed to bridge the gap between reference and use-case specific architectures [50]. Abstract reference architecture is technology-neutral, and there are a lack of concrete realization strategies and details [50].
In this respect, previous architecture is interesting and makes valuable contributions to advancements for energy digitalization, but presents certain limitations. Namely, three main boundaries have been detected: lack of experimental validation, no specification of the involved equipment concerning industrial/proprietary or open-source nature, and no concretization of communication protocols. Regarding this latter aspect, some frameworks rely on protocols that are not massively supported by industrial and commercial equipment, mainly MQTT. In other cases, two different protocols are considered, which hinder the handling of heterogeneity. Table 1 summarizes these features in the previously surveyed works. As can be observed, the architecture developed in this work is a novelty in the literature and overcomes the identified limitations. In other words, the present proposal contributes to addressing the gap between conceptual approaches and experimental facilities as well as to provide concrete strategies and details to deploy heterogeneous automation and monitoring systems for microgrids.

Materials and Methods
In this section, the main equipment concerning both hardware and software is described. Furthermore, the photovoltaic-based smart microgrid used as the application case is also expounded.

Photovoltaic Smart Microgrid
A smart microgrid hybridizing renewable energy and the energy carrier hydrogen acts as the application case of the proposal of the paper. This facility is a Direct Current (DC) microgrid for off-grid and environmentally-sustainable operation by means of PV-generated hydrogen, i.e., green hydrogen. Namely, a PV generator composed of 6 monocrystalline modules of 185 W and 24 V of nominal voltage (LDK Solar, Jiangxi, China) constitutes the renewable energy source. For hydrogen production, a Polymer Electrolyte Membrane (PEM) electrolyser, manufactured by Hydrogen Works (Madrid, Spain), provides up to 750 Ncm 3 /min of hydrogen flow. Hydrogen is accumulated by using metal-hydride canisters. For the contrary process, a PEM fuel cell uses the hydrogen to generate electricity by means of an air-cooled stack of 500 W manufactured by Horizon Fuel Cell Technologies (Singapore, Singapore). Short-term electricity storage is achieved through a lithium-ion modular battery of 5.12 kWh model B-Box, manufactured by BYD (Shenzhen, China). This device materializes the low voltage DC bus around which the rest of components are interconnected. Additionally, an electronic programmable load model 32,612 manufactured by Prodigit Electronics (New Taipei City, Taiwan) is supplied by the DC bus according to custom-designed load profiles. Figure 1 depicts the block diagram of the described components.
as a web application which the user accesses online from devices such as personal computers (PCs), tablets, or smartphones.  MariaDB is an open-source database management system (DBMS) for relational databases. It is used for data storage due to its lightweight, stable, and open features.  Totally Integrated Automation (TIA) Portal is the software engineering framework of Siemens for industrial automation systems. In this research, it is used for programming the algorithm, managing I/Os, and configuring communications of PLC and DPS.

Photovoltaic Smart Microgrid
A smart microgrid hybridizing renewable energy and the energy carrier hydrogen acts as the application case of the proposal of the paper. This facility is a Direct Current (DC) microgrid for off-grid and environmentally-sustainable operation by means of PV-generated hydrogen, i.e., green hydrogen. Namely, a PV generator composed of 6 monocrystalline modules of 185 W and 24 V of nominal voltage (LDK Solar, Jiangxi, China) constitutes the renewable energy source. For hydrogen production, a Polymer Electrolyte Membrane (PEM) electrolyser, manufactured by Hydrogen Works (Madrid, Spain), provides up to 750 Ncm 3 /min of hydrogen flow. Hydrogen is accumulated by using metal-hydride canisters. For the contrary process, a PEM fuel cell uses the hydrogen to generate electricity by means of an air-cooled stack of 500 W manufactured by Horizon Fuel Cell Technologies (Singapore, Singapore). Short-term electricity storage is achieved through a lithium-ion modular battery of 5.12 kWh model B-Box, manufactured by BYD (Shenzhen, China). This device materializes the low voltage DC bus around which the rest of components are interconnected. Additionally, an electronic programmable load model 32,612 manufactured by Prodigit Electronics (New Taipei City, Taiwan) is supplied by the DC bus according to custom-designed load profiles. Figure 1 depicts the block diagram of the described components. Concerning automatic operation of the microgrid, an industrial PLC is responsible for managing the energy flows between the aforementioned components. For this purpose, a Concerning automatic operation of the microgrid, an industrial PLC is responsible for managing the energy flows between the aforementioned components. For this purpose, a number of sensors measure the main magnitudes of the microgrid, and an energy dispatching algorithm is implemented by the PLC in order to power the connected load using the PV energy. The flowchart depicted in Figure 2 illustrates the decision sequence. If the battery is fully charged and there is a PV energy excess, the electrolyser (EL) is switched on to produce hydrogen. On the opposite situation, if the battery has a very low state of charge, e.g., it is discharged, the fuel cell (FC) is activated and converts hydrogen into electricity, supplying the demand of the load. This way, the generation of hydrogen from a PV source and its consumption enables autonomous behavior.
is fully charged and there is a PV energy excess, the electrolyser (EL) is sw duce hydrogen. On the opposite situation, if the battery has a very low sta it is discharged, the fuel cell (FC) is activated and converts hydrogen into plying the demand of the load. This way, the generation of hydrogen from its consumption enables autonomous behavior.

Proposed Multi-Layered Architecture
An innovative multi-layered architecture for energy automation and t microgrids is presented. A functional layout is defined to organize the sof and communication technologies in a coordinated, versatile, and interoper proposal is structured in six layers, as shown in Figure 3.
The so-called Supervisory Monitoring and Interaction layer provid functionalities through graphical data representation, alarm manageme rect interaction with the user. They must be informed in real-time of the the microgrid, as well as of previous operation, by means of numerical a displayed on a graphical user interface (GUI). The main data for this laye about the status of sensors and actuators physically placed in the micr sponding I/O signals are exchanged through the conceived layers. The m tion can be accessed in local and/or remote manner, depending on the c chosen software. For example, Siemens WinCC allows local connection middleware would be required to enable remote desktop connections f Other commonly used software for plants involving renewable energ which is generally applied for local monitoring [52]. In the case of open-so commonly include remote connection through web interfaces. ScadaBR examples of this type of options. In fact, given the widespread connecti network, remote monitoring is a requirement for modern digitized energ

Proposed Multi-Layered Architecture
An innovative multi-layered architecture for energy automation and the monitoring of microgrids is presented. A functional layout is defined to organize the software, hardware, and communication technologies in a coordinated, versatile, and interoperable manner. The proposal is structured in six layers, as shown in Figure 3.  The Data Record & Storage layer is responsible for accumulating the exchanged information. This function can be implemented by means of in-house or cloud-hosted databases, or even a combination in order to avoid data losses. In traditional monitoring systems, such data storage was commonly performed by the supervisory/monitoring system. However, in modern infrastructure, the volume of sensed magnitudes and exchanged information to be stored imposes an accessible and structured accumulation system. Databases allow data logging and storage in time-series or relational forms. In fact, traditional monitoring and supervisory software are moving towards Structured Query Language (SQL) databases [15], and open-source packages include in-built connectivity with such types of databases. The recorded information can be used for real-time monitoring, but The so-called Supervisory Monitoring and Interaction layer provides visualization functionalities through graphical data representation, alarm management, as well as direct interaction with the user. They must be informed in real-time of the current status of the microgrid, as well as of previous operation, by means of numerical and trend graphs, displayed on a graphical user interface (GUI). The main data for this layer are information about the status of sensors and actuators physically placed in the microgrid; the corresponding I/O signals are exchanged through the conceived layers. The monitoring function can be accessed in local and/or remote manner, depending on the capabilities of the chosen software. For example, Siemens WinCC allows local connection, whereas some middleware would be required to enable remote desktop connections for online access. Other commonly used software for plants involving renewable energies is LabVIEW, which is generally applied for local monitoring [52]. In the case of open-source suites, they commonly include remote connection through web interfaces. ScadaBR and Grafana are examples of this type of options. In fact, given the widespread connectivity through the network, remote monitoring is a requirement for modern digitized energy facilities [3].
The Data Record & Storage layer is responsible for accumulating the exchanged information. This function can be implemented by means of in-house or cloud-hosted databases, or even a combination in order to avoid data losses. In traditional monitoring systems, such data storage was commonly performed by the supervisory/monitoring system. However, in modern infrastructure, the volume of sensed magnitudes and exchanged information to be stored imposes an accessible and structured accumulation system. Databases allow data logging and storage in time-series or relational forms. In fact, traditional monitoring and supervisory software are moving towards Structured Query Language (SQL) databases [15], and open-source packages include in-built connectivity with such types of databases. The recorded information can be used for real-time monitoring, but also for further treatment towards forecasting or performance analyses using sophisticated algorithms.
The fourth level is called the Network Integration layer and harmonizes communications around the Modbus TCP protocol. As indicated in the Introduction, Modbus is the open protocol most commonly applied in the industrial environment. Particularly, Modbus TCP is the backbone of the communication network in order to establish an open and reliable transmission of information among the whole infrastructure system. Modbus TCP is a client/server protocol and uses the standard port 502. The client entity initiates the communication by sending a request to the server to transfer data. Once a connection is established, the server provides the client with the queried information until the client finishes the connection. Each involved device can play the role of client or server, depending on the information flow. Using this protocol, devices, either client or server, talk to each other via the IP addresses [34]. Moreover, the same device can develop both roles facing different equipment. Client and server do not know the physical/hardware or software nature of the counterpart; they are abstract from the manufacturer, model, or features. Only the protocol is used to enable the transmission of data messages.
An Ethernet network materializes the Network Integration layer, whereas the Modbus TCP protocol corresponds to the Application level of the well-known Open Systems Interconnection (OSI) model for networked communications. Using an Ethernet network facilitates the replacement or addition of devices [53], especially given the fact that this kind of network is the prevalent trend for Information Technology (IT), IoT-enabled equipment, and modern automation systems [54]. Both wired and wireless communications are considered in the proposal. Nonetheless, wired networks are preferred because of reliability and security reasons [4].
Indeed The Automation & DAQ layer groups equipment for automation and control such as PLC and PC-based controllers, as well as peripheral devices for remote I/O data acquisition purposes such as DAQ, DPS, HMI panels, etc. Communication between devices inside this layer can take place through the Network Integration layer or by means of the Distributed Protocols level. In this sense, data flows can take place in vertical and/or in horizontal directions. Horizontal data flow takes place in the same layer, concretely; it is enabled between devices of the Automation & DAQ layer by means of the communication provided by the Network Integration level. For example, information allocated in a PLC can be shared with another device placed in the same layer as a DAQ. In the vertical direction, a monitoring interface is able to gather data from a PLC through the Modbus TCP linkage.
The layer named Distributed Protocols is envisioned to host digital communications materialized by industrial fieldbuses different from Modbus TCP (PROFINET, PROFIBUS, EtherCAT, etc.) and by modern protocols such as MQTT or OPC UA. This way, master nodes can retrieve data from slave nodes, commonly featured by minor processing capabilities. For example, a PROFINET linkage between a PLC and a DPS belongs to this layer.
The bottom level, the Sensors & Actuators layer, groups all those sensors, actuators and other instruments needed for automation and monitoring of the physical facility. Examples of devices within this layer are temperature probes, pyrometers, current sensors, relays, contactors, electro-valves, and so on.
As indicated in the Section 2, there are a lack of concrete realization strategies and details concerning layered architecture [50]. To overcome this limitation, the present proposal relies on a specific communication protocol (Modbus TCP) for the Network Integration layer. Interoperability issues are solved, facilitating the systematic design and deployment of the communication network. Indeed, with a practical view, in the market it is easy to find power meters, power electronic devices, data loggers and gateways with embedded Modbus TCP interface. Therefore, the selection and acquisition of equipment is facilitated due to the widespread integration of Modbus TCP in available commercial and open-source equipment.
The proposal is appropriate for modern devices, as well as for legacy automation equipment. The ability to interconnect older-type equipment is an important benefit because it reduces investments by reutilizing already existent devices, for instance PLC a with remaining lifespan. As asserted in [47], the adoption of Modbus protocol provides a wide range of implementation options without replacing the existing sensor and actuator devices.
As has been highlighted, both proprietary and open-source technologies can coexist, interconnected under the proposed architecture. In this sense, the integration of proprietary industrial and open-source equipment brings diverse benefits and empowers the development of innovative scenarios such as microgrids [1].
Furthermore, despite the fact that the presented framework is oriented towards microgrids, it is also applicable for facilities in industrial environments involving heterogeneous equipment for automation and monitoring. In this regard, in order to take into account the decentralization trend of modern systems (IoT, Industry 4.0), this proposal is not a rigid hierarchical layout. It is suitable for both centralized and decentralized control schemes.

Experimental Validation
The validation of the proposed architecture was carried out over an experimental PV microgrid which involved equipment of both proprietary and open-source nature. Figure 4 depicts the application of the multi-layered architecture to the microgrid described in Section 3.2. Particularly, equipment devoted to automating and monitoring the PVbattery subsystem is orchestrated and deployed according to the layers defined in such architecture.
The validation of the proposed architecture was carried out over an experimental PV microgrid which involved equipment of both proprietary and open-source nature. Figure  4 depicts the application of the multi-layered architecture to the microgrid described in Section 2.3. Particularly, equipment devoted to automating and monitoring the PV-battery subsystem is orchestrated and deployed according to the layers defined in such architecture. A number of sensors and actuators were accommodated in the Sensors & Actuators layer. For instance, this level included devices to measure solar irradiance in the inclined plane of the PV modules, voltage and current sensors, Pt-100 probes, as well as actuators such as relays. It must be noted that weather measurements were carried out by a Pt-100 probe devoted to sense ambient temperature and an anemometer. Both magnitudes affect the temperature of the PV modules and contribute to analyzing their situation and performance. Table 2 lists the magnitudes and the corresponding sensors. The Automation & DAQ layer was composed of devices devoted to gathering data and operating the energy equipment. Concretely, a PLC is the main controller of the microgrid, making control decisions to manage the energy flows, generation, and consumption. A DPS was placed in the roof close to the PV generator to collect data from the modules. Other appliances within this layer were a MPPT solar charger and a BMU for lithiumion batteries. Both were connected to exchange data with a controller, the so-called CCGX, for their harmonized operation. Open-source hardware was also incorporated in this layer, namely the microcomputer RPi and the microcontroller Arduino. The latter retrieved information from a set of digital temperature sensors, feeding it to the RPi, which stored it jointly with other relevant data shared through the Network Integration layer. A number of sensors and actuators were accommodated in the Sensors & Actuators layer. For instance, this level included devices to measure solar irradiance in the inclined plane of the PV modules, voltage and current sensors, Pt-100 probes, as well as actuators such as relays. It must be noted that weather measurements were carried out by a Pt-100 probe devoted to sense ambient temperature and an anemometer. Both magnitudes affect the temperature of the PV modules and contribute to analyzing their situation and performance. Table 2 lists the magnitudes and the corresponding sensors. The Automation & DAQ layer was composed of devices devoted to gathering data and operating the energy equipment. Concretely, a PLC is the main controller of the microgrid, making control decisions to manage the energy flows, generation, and consumption. A DPS was placed in the roof close to the PV generator to collect data from the modules. Other appliances within this layer were a MPPT solar charger and a BMU for lithium-ion batteries. Both were connected to exchange data with a controller, the so-called CCGX, for their harmonized operation. Open-source hardware was also incorporated in this layer, namely the microcomputer RPi and the microcontroller Arduino. The latter retrieved information from a set of digital temperature sensors, feeding it to the RPi, which stored it jointly with other relevant data shared through the Network Integration layer.
In this sense, Modbus TCP over an Ethernet network served as a physical means to implement the Network Integration layer. Above all, information was shared through this layer between three devices which belonged to the Automation & DAQ layer. Namely, the RPi acted as client of the PLC and of the CCGX; consequently, these latter devices played the role of Modbus servers.
As can be observed in Figure 4, the Distributed Protocols layer hosted four different communication protocols. RPi and Arduino shared information by means of a TCP/IP linkage. The well-known industrial bus PROFINET was used for the exchange of I/O signals between the DPS and the PLC. A Controller Area Network (CAN) bus was used to interconnect the BMU with the CCGX. The MPPT charger was linked to the CCGX through a proprietary bus, the so-called VE.Direct. This device has not been included in the previous figure for a clearer depiction.
Concerning the Data Record & Storage layer, MariaDB was the DBMS responsible for storing operational data. This entity was hosted by the RPi, thus implementing an in-house local cloud. This configuration provided a reduction in delays in recording measurements received from the data collecting equipment. Another advantage consisted of eliminating dependencies on external web hosting services.
The open-source Grafana suite implemented the Supervisory Monitoring and Interaction layer. Grafana played the role of a web-based monitoring interface, feeding the operator with the gathered information in the form of time-series charts in a user-friendly manner. The database was accessed by the Grafana dashboards to query the information of the graphical and numerical elements displayed. The linkage between the RPi, the database, and the Grafana GUI is represented in Figure 4, with a dotted line representing a logical connection within the RPi by means of SQL.
Some papers mention the utilization of Modbus TCP, but with scarce details about the experimental implementation and application. Therefore, in order to facilitate the deployment of the proposed architecture, insights on the configuration of the main actors are provided in next Sections, namely the CCGX, the RPi, and the PLC.

Configuration of Modbus Communication in CCGX
As described above in Section 3.1, this proprietary device acts as gateway enabling the exchange of information from the solar charger and BMU with equipment of different manufacturers. This device includes an Ethernet port, so it is easily integrated in the network where both the RPi and PLC are connected. A fixed IP address is also configured to establish a reliable and stable communication.
In order to share data, the CCGX can be configured to use MQTT or Modbus TCP protocols, with the latter selected to adopt the proposed architecture. To this purpose, it is required to activate this communication service within the Services option. Figure 5 shows this detail of the screen displayed by the CCGX. layer between three devices which belonged to the Automation & DAQ layer. Namely the RPi acted as client of the PLC and of the CCGX; consequently, these latter device played the role of Modbus servers.
As can be observed in Figure 4, the Distributed Protocols layer hosted four differen communication protocols. RPi and Arduino shared information by means of a TCP/I linkage. The well-known industrial bus PROFINET was used for the exchange of I/O sig nals between the DPS and the PLC. A Controller Area Network (CAN) bus was used t interconnect the BMU with the CCGX. The MPPT charger was linked to the CCG through a proprietary bus, the so-called VE.Direct. This device has not been included i the previous figure for a clearer depiction.
Concerning the Data Record & Storage layer, MariaDB was the DBMS responsibl for storing operational data. This entity was hosted by the RPi, thus implementing an in house local cloud. This configuration provided a reduction in delays in recording meas urements received from the data collecting equipment. Another advantage consisted o eliminating dependencies on external web hosting services.
The open-source Grafana suite implemented the Supervisory Monitoring and Inter action layer. Grafana played the role of a web-based monitoring interface, feeding th operator with the gathered information in the form of time-series charts in a user-friendl manner. The database was accessed by the Grafana dashboards to query the informatio of the graphical and numerical elements displayed. The linkage between the RPi, the da tabase, and the Grafana GUI is represented in Figure 4, with a dotted line representing logical connection within the RPi by means of SQL.
Some papers mention the utilization of Modbus TCP, but with scarce details abou the experimental implementation and application. Therefore, in order to facilitate the de ployment of the proposed architecture, insights on the configuration of the main actor are provided in next Sections, namely the CCGX, the RPi, and the PLC.

Configuration of Modbus Communication in CCGX
As described above in Section 2.1, this proprietary device acts as gateway enablin the exchange of information from the solar charger and BMU with equipment of differen manufacturers. This device includes an Ethernet port, so it is easily integrated in the ne work where both the RPi and PLC are connected. A fixed IP address is also configured t establish a reliable and stable communication.
In order to share data, the CCGX can be configured to use MQTT or Modbus TC protocols, with the latter selected to adopt the proposed architecture. To this purpose, is required to activate this communication service within the Services option. Figure  shows this detail of the screen displayed by the CCGX.

Configuration of Modbus Communication in RPi through Python
The RPi acts as the Modbus client of both the PLC and the CCGX. Namely, on the one hand, the microcomputer shares data with the PLC concerning the sensors directly connected to it or through the DPS. On the other hand, measurements related to the battery and to the PV generator are also logged from the CCGX.
To exchange data via Modbus, the library Pymodbus is applied to share data over Modbus TCP using Python language. Firstly, a connection to the destination host through the default port is established. After that, the values of a certain number of registries from an address of the unit are read. Each host can include different units with information, being identified by a number; for instance, the CCGX uses the number 247 for the data from the solar charger and 225 for the BMU. The next step consists of sending the information to the database. For this aim, a connection is established with the device where the database is hosted, after which an SQL command inserts the data in the corresponding table. Figure 6 contains a flowchart to illustrate the described steps.

Configuration of Modbus Communication in RPi through Python
The RPi acts as the Modbus client of both the PLC and the CCGX. Namely, on the one hand, the microcomputer shares data with the PLC concerning the sensors directly connected to it or through the DPS. On the other hand, measurements related to the battery and to the PV generator are also logged from the CCGX.
To exchange data via Modbus, the library Pymodbus is applied to share data over Modbus TCP using Python language. Firstly, a connection to the destination host through the default port is established. After that, the values of a certain number of registries from an address of the unit are read. Each host can include different units with information, being identified by a number; for instance, the CCGX uses the number 247 for the data from the solar charger and 225 for the BMU. The next step consists of sending the information to the database. For this aim, a connection is established with the device where the database is hosted, after which an SQL command inserts the data in the corresponding table. Figure 6 contains a flowchart to illustrate the described steps. To exemplify these sequential stages, the main code of Python is described hereafter. To begin with, the libraries for Modbus communication (ModbusTcpClient) and for connection to the database (mysql.connector) are imported. Later, an instance ModbusClient is created for the CCGX, indicating its IP address and the default port for Modbus. After that, the connection is established; the magnitudes of interest within the memory of the Modbus server are read by means of the instruction client.read_holding_registers. For example, one register (16 bits) starting at address 266 of the unit 255 (BMU) is read and stored in the variable batstategx_r in order to retrieve the state of charge (SoC) of the battery. After reading all data, the connection with the destination host, e.g., the CCGX, is closed.
The same procedure is performed to gather data from the PLC. A ModbusClient instance is created indicating the IP address and the port, after which the communication is established. Magnitudes of interest are shared in the same way. To exemplify these sequential stages, the main code of Python is described in Algorithm 1. To begin with, the libraries for Modbus communication (ModbusTcpClient) and for connection to the database (mysql.connector) are imported. Later, an instance ModbusClient is created for the CCGX, indicating its IP address and the default port for Modbus. After that, the connection is established; the magnitudes of interest within the memory of the Modbus server are read by means of the instruction client.read_holding_registers. For example, one register (16 bits) starting at address 266 of the unit 255 (BMU) is read and stored in the variable batstategx_r in order to retrieve the state of charge (SoC) of the battery. After reading all data, the connection with the destination host, e.g., the CCGX, is closed. The same procedure is performed to gather data from the PLC. A ModbusClient instance is created indicating the IP address and the port, after which the communication is established. Magnitudes of interest are shared in the same way.

Configuration of Modbus Communication in PLC
TIA Portal includes configuration modules to establish Modbus TCP connections, both for client and server roles: MB_Client and MB_Server, respectively. The PLC acts as server so the RPi can read the memory position shared via Modbus, i.e., the RPi plays the role of Modbus client.
A flowchart of the PLC sequential operations is shown in Figure 7. Firstly, local and remote I/O signals are collected, after which the corresponding data processing is carried out, e.g., scaling and normalizing for analogue measurements. Later, the accumulation of these data is performed in a data block of the local memory. Once the data block is completed, the information is shared through Modbus by calling the MB_Server block. This way, the client (RPi in this case) is able to read the stored signals, establishing a Modbus TCP network communication. After this step, the PLC executes the rest of operations required to manage the microgrid behavior.

Configuration of Modbus Communication in PLC
TIA Portal includes configuration modules to establish Modbus TCP connections, both for client and server roles: MB_Client and MB_Server, respectively. The PLC acts as server so the RPi can read the memory position shared via Modbus, i.e., the RPi plays the role of Modbus client.
A flowchart of the PLC sequential operations is shown in Figure 7. Firstly, local and remote I/O signals are collected, after which the corresponding data processing is carried out, e.g., scaling and normalizing for analogue measurements. Later, the accumulation of these data is performed in a data block of the local memory. Once the data block is completed, the information is shared through Modbus by calling the MB_Server block. This way, the client (RPi in this case) is able to read the stored signals, establishing a Modbus TCP network communication. After this step, the PLC executes the rest of operations required to manage the microgrid behavior.  For the Modbus server role, the memory positions to be shared must be assigned to the input MB_HOLD_REG of the block MB_Server (Figure 8a). Thus, those positions are made accessible to the Modbus client. Additionally, in the input named as CONNECT, it is required to specify a data block named as MB Config, where a set of parameters are defined to establish the communication (Figure 8b). The most representative parameters are now briefly commented. To begin with, a value of 11 is assigned to ConnectionType for TCP linkage. The IP address of the device which acts as the Modbus client is specified by means of an array of four bytes, ADDR. As can be observed, for illustrative purposes, "0" has been introduced for each byte of the address, so any client is allowed to start this communication. Finally, the default port for Modbus, 502, is kept. Further details about the involved communication parameters can be found in the manufacturer documentation. For the Modbus server role, the memory positions to be shared must be assigned to the input MB_HOLD_REG of the block MB_Server (Figure 8a). Thus, those positions are made accessible to the Modbus client. Additionally, in the input named as CONNECT, it is required to specify a data block named as MB Config, where a set of parameters are defined to establish the communication (Figure 8b). The most representative parameters are now briefly commented. To begin with, a value of 11 is assigned to ConnectionType for TCP linkage. The IP address of the device which acts as the Modbus client is specified by means of an array of four bytes, ADDR. As can be observed, for illustrative purposes, "0" has been introduced for each byte of the address, so any client is allowed to start this communication. Finally, the default port for Modbus, 502, is kept. Further details about the involved communication parameters can be found in the manufacturer documentation.

Results and Discussion
In this section, the most illustrative experimental results are reported as a proof of the validity of the proposed architecture. To begin with, the physical implementation of the equipment in laboratory and roof are expounded. Later, the data sharing through the proposed multi-layered architecture is proved by means of the monitoring system Grafana. Finally, the achieved results are discussed in Section 6.2. Figure 9 shows the experimental setup in the laboratory. As can be observed, the Ethernet switch, the MPPT charger, the RPi, the PLC and the CCGX were placed on the same metal sheet panel.

Results and Discussion
In this section, the most illustrative experimental results are reported as a proof of the validity of the proposed architecture. To begin with, the physical implementation of the equipment in laboratory and roof are expounded. Later, the data sharing through the proposed multi-layered architecture is proved by means of the monitoring system Grafana. Finally, the achieved results are discussed in Section 6.2. Figure 9 shows the experimental setup in the laboratory. As can be observed, the Ethernet switch, the MPPT charger, the RPi, the PLC and the CCGX were placed on the same metal sheet panel.

Results
The sensors placed in the roof to measure the PV generator main magnitudes are seen in Figures 10 and 11. The mounting angle of the irradiance sensor was the same as that of the photovoltaic modules, in such a way that the direct irradiance actually received by these modules was measured. Concerning temperatures, sensors are adhered to the back plane of the PV modules. Two DS18B20digital temperature sensors were placed in the diagonal of the modules, whereas a Pt-100 temperature probe was located in the center area. The sensors placed in the roof to measure the PV generator main magnitudes are seen in Figures 10 and 11. The mounting angle of the irradiance sensor was the same as that of the photovoltaic modules, in such a way that the direct irradiance actually received by these modules was measured. Concerning temperatures, sensors are adhered to the back plane of the PV modules. Two DS18B20digital temperature sensors were placed in the diagonal of the modules, whereas a Pt-100 temperature probe was located in the center area.   The sensors placed in the roof to measure the PV generator main magnitudes are seen in Figures 10 and 11. The mounting angle of the irradiance sensor was the same as that of the photovoltaic modules, in such a way that the direct irradiance actually received by these modules was measured. Concerning temperatures, sensors are adhered to the back plane of the PV modules. Two DS18B20digital temperature sensors were placed in the diagonal of the modules, whereas a Pt-100 temperature probe was located in the center area.  Diverse dashboards have been built using Grafana to provide an intuitive interaction with the user through the GUI. Among them, one was devoted to take advantage of the synergy of process signals provided by the multi-layered architecture. In other words, complementary magnitudes are shown together for a proper tracking of the smart microgrid behavior. The user/operator can see at a glance the magnitudes shared via Modbus in real-time; indeed, the data source is indicated between parentheses in the legend of each magnitude. They are also able to select previous time intervals because the corresponding data are stored in the DB; thus, it is rapidly displayed. Figure 12 shows the GUI composed of numerical data and time series so the user/operator can see at a glance the situation of the microgrid. Diverse dashboards have been built using Grafana to provide an intuitive interaction with the user through the GUI. Among them, one was devoted to take advantage of the synergy of process signals provided by the multi-layered architecture. In other words, complementary magnitudes are shown together for a proper tracking of the smart microgrid behavior. The user/operator can see at a glance the magnitudes shared via Modbus in real-time; indeed, the data source is indicated between parentheses in the legend of each magnitude. They are also able to select previous time intervals because the corresponding data are stored in the DB; thus, it is rapidly displayed. Figure 12 shows the GUI composed of numerical data and time series so the user/operator can see at a glance the situation of the microgrid. The days December 30 and 31, 2020, have been chosen to illustrate the behavior of the PV generator and the battery during sunny and cloudy days, respectively. Incident irradiance (yellow curve) and the current of the battery (blue color), together with the SoC (red color) evolution are displayed in Figure 13a. On the sunny day, the energy stored in the battery increased, as shown by its SoC, which grew from 61% up to 89% due to the PV generation. Note that SoC/10 is the SoC divided by 10, in order for it to be represented within the same graphic.  Diverse dashboards have been built using Grafana to provide an intuitive int with the user through the GUI. Among them, one was devoted to take advantag synergy of process signals provided by the multi-layered architecture. In other complementary magnitudes are shown together for a proper tracking of the sm crogrid behavior. The user/operator can see at a glance the magnitudes shared via M in real-time; indeed, the data source is indicated between parentheses in the le each magnitude. They are also able to select previous time intervals beca corresponding data are stored in the DB; thus, it is rapidly displayed. Figure 12 sh GUI composed of numerical data and time series so the user/operator can see at the situation of the microgrid. The days December 30 and 31, 2020, have been chosen to illustrate the beh the PV generator and the battery during sunny and cloudy days, respectively. irradiance (yellow curve) and the current of the battery (blue color), together with (red color) evolution are displayed in Figure 13a. On the sunny day, the energy s the battery increased, as shown by its SoC, which grew from 61% up to 89% due to generation. Note that SoC/10 is the SoC divided by 10, in order for it to be repr within the same graphic. The days 30 and 31 December 2020, have been chosen to illustrate the behavior of the PV generator and the battery during sunny and cloudy days, respectively. Incident irradiance (yellow curve) and the current of the battery (blue color), together with the SoC (red color) evolution are displayed in Figure 13a. On the sunny day, the energy stored in the battery increased, as shown by its SoC, which grew from 61% up to 89% due to the PV generation. Note that SoC/10 is the SoC divided by 10, in order for it to be represented within the same graphic. generated by the PV modules (green curve), demanded by the load (black color) and corresponding to the battery (blue color). The trend and interactions were the same as those observed for the currents depicted in Figure 13b. The CCGX already provided measurements of the power generated by the PV modules, whereas the power of the battery and the power delivered to the load were calculated from the measurements gathered by the PLC. The evolution of the temperatures of a single PV module can be observed together with the incident irradiance in another chart ( Figure 14). The purple color corresponds to analogue measurement of the Pt100 linked to the PLC, whereas the signal provided by digital sensors are represented in orange. There is a difference between both curves of The SoC of the battery increased at the same time that the load consumed the certain current. Figure 13b depicts the currents of the load, of the battery and the output of the MPPT charger during both days. As can be visualized, the current generated by the PV modules (burgundy curve), once adapted by the solar charger, was devoted to fullfil the demand of the load and to charge the battery. In fact, the current demanded by the load changed according to a custom-designed profile (black color in Figure 13b). Moreover, it can be observed that the battery delivers the current required during a transient short interval, until the MPPT charger adapts the power of the PV modules to the new demand, or when the existing irradiance is not enough to cover the load demand solely with the PV-generated current.
As can be seen, on the sunny day at 12:00, the current load increased, so the current received by the battery decreased. This was due to the fact that the PV modules were providing the maximum possible current, but it was not enough to fully satisfy the demand of both the battery and the load. Thus, the charge of battery was slowed. At 16:00, the situation was the opposite; the load current was reduced and, consequently, the current delivered to the battery increased.
In order to visualize power flows, Figure 13c shows the evolution of the power generated by the PV modules (green curve), demanded by the load (black color) and corresponding to the battery (blue color). The trend and interactions were the same as those observed for the currents depicted in Figure 13b. The CCGX already provided measurements of the power generated by the PV modules, whereas the power of the battery and the power delivered to the load were calculated from the measurements gathered by the PLC.
The evolution of the temperatures of a single PV module can be observed together with the incident irradiance in another chart ( Figure 14). The purple color corresponds to analogue measurement of the Pt100 linked to the PLC, whereas the signal provided by digital sensors are represented in orange. There is a difference between both curves of around 1 • C, which is coherent with the different position of the sensors. Both temperature values vary with the same trend, according to the irradiance curve for the sunny and the cloudy days. Note that in the figure, Inclined Irradiance/200 is the solar irradiance in the inclined plane, divided by 200, in order to be represented in the same chart.
Sustainability 2021, 13, x FOR PEER REVIEW 2 Figure 14. Evolution of temperature measurements for one PV module and irradiance in Gra GUI.
As can be seen in Figure 15, the sum of the currents corresponding to each str PV modules (brown color) is equal to the current provided by the CCGX (green), wi latter oe named as Current before MPPT (CCGX) in the chart. Additionally, cu delivered by each pair of PV modules is observed (clear blue, pink and orange colo must be noted that the CCGX gathers the current produced by the whole PV gene As can be seen in Figure 15, the sum of the currents corresponding to each string of PV modules (brown color) is equal to the current provided by the CCGX (green), with the latter oe named as Current before MPPT (CCGX) in the chart. Additionally, currents delivered by each pair of PV modules is observed (clear blue, pink and orange colors). It must be noted that the CCGX gathers the current produced by the whole PV generator from the MPPT charger, and does not considers the electrical interconnection of the modules. In the viewed days, data of current generated by a string of modules were zero (orange color) due to the fact that it had been disconnected. This way, differences or malfunctions of the modules could be detected through analyses and comparison of the Modbus-shared measurements. Figure 14. Evolution of temperature measurements for one PV module and irradiance in GUI.
As can be seen in Figure 15, the sum of the currents corresponding to each PV modules (brown color) is equal to the current provided by the CCGX (green) latter oe named as Current before MPPT (CCGX) in the chart. Additionally delivered by each pair of PV modules is observed (clear blue, pink and orange must be noted that the CCGX gathers the current produced by the whole PV from the MPPT charger, and does not considers the electrical interconnecti modules. In the viewed days, data of current generated by a string of modules (orange color) due to the fact that it had been disconnected. This way, diffe malfunctions of the modules could be detected through analyses and comparis Modbus-shared measurements.

Discussion
The presented architecture is general and scalable; it does not rely on manufacturers, operative systems, hardware or software, with the exception of communication protocol Modbus TCP. Specifically, for a high level of concretio plicability, Modbus TCP implements the integration of communications, allow tegrated and effective data exchange between the involved equipment.

Discussion
The presented architecture is general and scalable; it does not rely on particular manufacturers, operative systems, hardware or software, with the exception of the open communication protocol Modbus TCP. Specifically, for a high level of concretion and applicability, Modbus TCP implements the integration of communications, allowing an integrated and effective data exchange between the involved equipment.
The reported experimental results validate the proposal. Namely, the monitoring and automation equipment of a PV-based microgrid are successfully orchestrated and integrated following the architecture.
A notable remark when developing layered frameworks is that, depending on the designers' viewpoint, the number of layers should be between two and eight, as has been commented in the literature review. In this sense, from the humble perspective of the authors, a compromise between scarce layers and an excessive number of them must be found. A low number of layers could imply scarce separation of functionalities, so the division makes no sense. On the contrary, a large number of layers could lead to an excessive atomization of tasks. The presented multi-layered architecture was conceived, refined, and deployed, evolving from a simpler initial version of four levels up to the final configuration expounded in the paper. Namely, six layers fully satisfied the functions that must be performed within energy automation and monitoring.
The present work reports a fully functional application of the architecture using hardware and software equipment which correspond to real facilities. Industrial equipment has been used to implement the microgrid, both for energy generation/consumption and automation, apart from the open-source equipment. In addition, improvements in open-source equipment, as well as new proprietary devices, can be included in automation and monitoring systems deployed following this framework.
Among the benefits of the proposal, the capability to seamlessly interconnect heterogeneous proprietary and open-source equipment is highlighted. Indeed, the monitoring system Grafana enables visualization of the the gathered information in an user-friendly manner. This suite has been chosen for its easy configuration, versatility and increasing application in research works [16].
From an economical point of view, the presented architecture allows investment reduction thanks to the convergence of proprietary and open-source technologies. In fact, in the experimental microgrid, a severe cost decrease was achieved by using the free software Grafana and MariaDB instead of commercial supervisory suites with licensing expenses.
Despite the reported results, the present work has some limitations, which are now expounded. If required, protocol converters can be adopted in order to integrate devices with different communication protocols into the Network Integration Layer. This option must be studied carefully to avoid potential bottlenecks when a large amount of data are to be transferred [11]. Still related to data transmission, obtaining performance and error metrics of the deployed network would be interesting. Cyber-security measures have not been implemented in the proposal so far; nonetheless, measures in this regard for vulnerabilities of the Modbus TCP network should be taken into account [55]. The developed system has been operating continuously for a whole year; however, performance over long time periods should be evaluated, especially concerning open-source equipment [1].

Final Remarks
The digital transformation of energy infrastructure is mainly promoted by the deployment of smart grids and microgrids. Their effective implementation overcomes challenges, among which research efforts towards the standardization of communication protocols and networks are found.
To this aim, in this paper, innovative multi-layered architecture has been proposed and validated. Establishing a functional division into six layers, such architecture is devoted to organizing the heterogeneous elements for energy automation and monitoring in microgrids. Around the Modbus TCP network, interoperability is appropriately handled, and data transmission successfully performed. Signals from sensors, controllers, and software environments are properly shared by means of the multi-layered architecture.
It must be remarked that this proposal is a novelty in the existing literature, and overcomes limitations identified in previous works such as a lack of concretization about communication technologies, proprietary/industrial or open-source equipment, and experimental validation. In other words, this work contributes to addressing the gap between conceptual approaches and experimental facilities, providing concrete strategies and details. The developed architecture is envisioned to empower the real deployment of microgrids and, consequently, foster the digital transformation of the power grids.
The target groups are scientists, engineers, and practitioners in the fields of energy automation and monitoring. The selection of devices, software suites and communication protocols will be assisted by the reported theory and experimentation. Moreover, maintenance, modifications, and expansions will be facilitated, given the advantages that this architecture provides. Therefore, the paper is expected to act as a useful resource in the design and deployment of this type of systems, both for R&D activities and implementation in real facilities.
Further works around the implemented architecture include the addition of controllers and sensors for the rest of the microgrid components. Analyses about energy efficiency of the involved components will be carried out, taking advantage of the accumulated measurements. The creation of digital replicas of the components using information provided by the Data Record & Storage layer is also being approached. Funding: This project was co-financed by European Regional Development Funds FEDER and by the Junta de Extremadura (IB18041).
Institutional Review Board Statement: Not applicable.

Informed Consent Statement: Not applicable.
Data Availability Statement: Not applicable.

Conflicts of Interest:
The authors declare no conflict of interest.

Abbreviations
The following abbreviations are used in this manuscript: