Modular Microgrid Technology with a Single Development Environment per Life Cycle

1. Introduction

Since the early days of civilization, humans have tried to be innovative, to adapt to different climatic conditions [1] and landforms, to facilitate increased comfort and ensure a safe environment [2]. This continuous process of innovation [3] has led to an increase in energy consumption and global industrialization. Thus, the limitations in the field of electricity production to support this technological advance impose new strategic pillars of political-economic-social interest [4].

Interest in traditional energy [5,6,7], brings with it new concepts until the emergence of Energy Communities [8], this path is still booming and enjoying special attention among engineers and authorities, with investment funds and financing schemes [9,10] etc.

With the increased complexity and energy grid stability challenges that arose from the integration of renewable sources, the idea of microgrid provided a solution by joining this green energy with consumers and storage facilities. This way such structures can operate in a decentralized architecture, usually linked to the national grid, but controlled locally [11]. The multiplication of electric microgrid solutions, which integrate into a single common control system several microgrids and can balance between demand and production, imposed a new concept, that of multi-microgrids [12]. An important step forward was the development of SLES (Smart Local Energy System) [13,14,15] by joining thermal sources (such as biogas or heat pumps: water-water, air-water, geothermal, etc.) with the microgrid operation. This way an integrated management of production can be achieved and the use of otherwise wasted sources of heat (from high energy consumers) can help achieve mail grid energy independence.

EU Directive 2018/2001 defines Energy Communities [14] from Renewable Sources ("Renewable Energy Communities"), which propose several classifications to define the different organizational structures, depending on the available resources and actors, such as [15]: Integrated Community Energy Systems, Prosumer Community, Energy Hub, Zero-Energy Communities etc.

Regardless of the integrated energy production-consumption model used, there is clearly a large market for microgrid development technologies, which requires advanced knowledge of each product, of each phase from the life cycle stages.

As an answer to this problem, the authors have developed a platform that integrates six microgrid lifetime stages, supporting engineers and operators in selecting and configuring the proper equipment to address their needs. The article presents and demonstrates a pilot platform which provides step-by-step support for microgrid (MG) development during the entire life cycle. It is divided into 4 modules, developed in a development environment commonly used in the research and development (R&D) activity.

The rest of the paper is structured as follows. Section 2 presents the state of the art in microgrid design as well as main challenges identified in literature. It presents the traditional life cycle of such a system and common development and operation approach, technologies involved and integration solutions. Section 3 presents the case-study of a microgrid that will serve as demonstration for the platform proposed by the authors. Section 4 presents the developed tool, its architecture and functions of each module. Section 5 details platform components and demonstrates a proof-of-concept by passing the selected case-study through each stage, which includes: dimensioning and optimization with automatic reporting of the technical specifications of the microgrid, data acquisition and cleaning, operation screens and predictive maintenance support. The last section concludes this paper.

2. State of the Art for Microgrid Development

2.1. Microgrid Life Cycle Assessment Approaches

Just like any system made up of different components, a microgrid presents a life cycle, similar to that of other products, but with an average duration of minimum 25 years [16].

Existing research of microgrid life cycle [17] highlights the fact that by systematically improving a network significant environmental benefits can be achieved. The National Renewable Energy Laboratory proposed a more traditional version [18], which contributes to reducing the complexity of evaluating the location, considering the intensity of solar radiation, the topography of the land, the angle of inclination and the orientation of the photovoltaic panels, etc.

More recent approaches [19,20] involve merging the stages at end of life with the design stage, where the production of components of the photovoltaic panels is combined with the recycling of the photovoltaic panels to obtain more effective and efficient solutions. This facilitates the reuse of raw materials that may contain secondary chemicals, limiting the negative impact on the environment.

Research such as [21] analyze and discuss the implementation of multi-stage collaborative design technology, by integrating design, manufacturing, operations and maintenance stages. Intelligent data detection technology, data integration and fusion technology are added to the proposed integrated structure. The results of this work [21] were considered as a starting point for the development of the platform described by the authors.

Knowing the stages of life that the microgrid goes through helps to maximize its life span. Figure 1 is a representation of the main microgrid life cycle components, in the vision of the authors.

2.2. Technologies Involved in the Lifetime of a Microgrid

Increasing the microgrid lifespan depends on the possibility of continuous improvement, which includes ensuring its integration with emerging technologies [23].

At the bottom level, microgrid field equipment includes various elements such as sensors for different parameters (like environmental data), surveillance cameras, regulators, transducers, current transformers, and power meters [24]. In addition to this, asset instrumentation can be added to support predictive maintenance [25].

Data acquisition starts at the remote terminal unit (RTU) or Programmable logic controller (PLC) level [26] and involves reading the field instrumentation data and the status of the local equipment which are then communicated to the Supervisory Control And Data Acquisition (SCADA) [27]. Control sequences and strategies are also implemented at this level.

Models and Simulations (MS) have been added to the lifecycle of many processes to improve the production performance, and microgrids were not left behind. While MS is usually based on historical data, current implementations tend to focus more on Digital Twin [28], that identical representation of a physical element using real-time data [29].

Hardware In the Loop (HIL) [30] is used when the microgrid model is validated and reaches a certain prototype maturity, certain processes work without human intervention and the extension of a method must simulate certain scenarios (of failure, overload, etc.). In this case the Digital Twin (DT), having sensors and actuators data from the physical twin, can simulate different diagnostic scenarios [31] and increase performance of a microgrid [32].

The are several tools available on the market to support the microgrid design and performance analysis based on the characteristics of the available devices. Small simulations of photovoltaic parks operation can be performed with open-source software such as DER-CAM, MDT, Reopt, Hymod but also with mode advanced software like HOMER, RETScreen, PVsist, PV *Sol, Bluesol, Helios and Solarius PV. This last category of tools can also generate system architectures and financial and technical analyses, based on a monthly subscription or perpetual license.

For MS integration with real-time data, there are platforms that have a hardware simulator component, as well as development environments with common programming languages (Python, Matlab [22] etc.). This way, there is a great flexibility in implementing strategies proposed at a theoretical level in research literature to the specific requirements of a real application. Most used are Typhoon HIL, OPAL-RT and RTDS, having a rather high cost of the user license, but which enable greater optimizations of the whole process.

More complex tools, like AnyLogic, Siemens MindSphere, ThingWorx, ANSYS, XENDEE or Eathon are Digital Twin software that integrate IoT data. This allows maximum interconnectivity, with many communication drivers, ensuring communication stability and reliability, as well as supporting data backup in case of a fault. They have unique development environments, industry-specific libraries, professional agent-based simulation software, GIS map integration, cloud simulation, data interoperability, extensible and customizable platform for predictive maintenance or real-time data simulation.

Considering all these, the authors noted that designing a strategy for the whole lifecycle of a microgrid requires integrating information from various technologies which can be a very complicated process, as there is no standard or generic input/output format or data structure. This requires a very good knowledge of its characteristics, limitations and integration options, which can help a design engineer determine where upgrades can positively impact the return of investment and overall microgrid operation. As a solution the authors propose a platform in a development environment commonly used in the field of research, Matlab, as a support tool during the entire lifecycle of a microgrid.

3. Architecture of the Proposed System

The authors propose a version of a microgrid life cycle consisting of six stages, each stage being developed in several steps. It starts with MG Equipment Production, then Customer Identification, Detailed Design, Implementation, Operation and Maintenance, and, the last stage, End of Life. In Figure 2, these stages are presented and framed within the proposed platform in 4 modules, thus several stages can be part of a module. One main objective was that these stages can be integrated in the same development environment. The proposed architecture is under the intellectual protection validation process, validating its effectiveness in a real case study.

Table 1 provides a description of the stages proposed by the authors. For each stage, a novelty brought out through the single life cycle development environment.

In the proposed platform, all these six stages are handled by four development modules, as can be seen in Figure 2. The 4 modules are explained in detail as follows.

Module 1: integrates the first stage (1st stage: MG Equipment production) and the last stage (6th stage: End of life). This module includes a user account tool that interacts with stakeholders and supports dialogue, finds answers, learns and shares knowledge. This is made available by the development environment, the authors only contributing to bring the concept of recycling and reuse in the manufacturing phase as close as possible to the users.

Module 2: integrates the second stage (2nd stage: Customer identification) with the third stage (3rd stage: Detailed Design). This module is done by filling in some customizable spaces in the code, without the need for software developer knowledge. Automatic performance reporting is done by clicking on a single button, no coding skills are required.

Module 3: corresponds to the fourth stage (4th stage: Implementation). It is a tool that creates a map of the entire project, where the phases and dependencies can be followed by the project managers and the leaders.

Module 4: corresponds to the OM stage (5th stage: Operation and maintenance). Five windows are displayed, i.e. Microgrid performance and equipment status, Evolution graphs, Interventions planning, Predictive maintenance KPI, Attachments. For these windows, screens, data acquisition, cleaning, interpretation and contextual analysis are necessary.

Section 5 presents the way in which Module 2 and Module 4 are populated considering the real case of a microgrid application. Even if the life-cycle assessment was performed by passing through app stages, Module 1 and Module 3 will not be presented in this paper, as they are mainly facilitating access to tools available in Matlab.

4. Presentation of the Case Study

The case study is represented by a microgrid consisting of a photovoltaic system, of of 126 kWp installed power, serving an office building. It is located in the city of Constanța, from Romania, a city situated few km away from the Black Sea. The building is divided into the ground floor and the 1st floor, composed of two bodies joined by a corridor.

The photovoltaic system is made up of 256 panels grouped on 16 strings that supply power via a DC/DC converter. . Energy storage is carried out in two groups of batteries, of different characteristics, totaling a capacity of about 300 kWh; a third battery is planned for future developments. Both the PV panes and the storage system are interfaced with the AC side via a 120 kVA DC/AC bidirectional converter. Thermal energy is provided by a group of four heat pumps with an installed power of about 200 kWt and 60 kWe.

A S7 Siemens PLC was chosen for the implementation of the sequence and control strategy. The one-line diagram of the installation is shown in the Figure 3.

A relevant input from the office building is the consumption profile. The dataset received from the building owner contains data for 11 consecutive months taken from the existing SCADA application, from March 2022 to January 2023 (Figure 4). The resolution is 5 minutes. The data represents a time series of instantaneous values for the raw consumption.

5. Platform Implementation and Development

This case-study was developed by going through the 4 modules of the developed platform, as a proof-of-concept for the functionality, but the authors decided to detail only Module 2 (2nd stage - Customer identification and 3rd stage - Detailed Design) and Module 4 (5th stage - Operation and maintenance), as they carry the innovative contribution of their work. The predictive maintenance indicators of the microgrid have been defined and integrated, and they will be further expanded within this platform. This paper only provides details on how the technology was developed and can be used. At this stage, the research does not advance with the evaluation in terms of performance indicators and the benefits brought by implementation.

Module 2 includes three tools and a methodology, which will be presented below in detail. The first tool is Microgrid performance sizing, the second tool is Automatic reporting, and the third is Filter and clearance data. These 3 tools were specially created that both contain an easy-to-use script that does not require advanced IT knowledge, the codes being designed to be completed by the user only through free fields. The Data acquisition methodology is a procedure by which the archived data is retrieved from the SCADA application (for the case study in this paper), but the data can also be retrieved through several methods, such as through direct communication via TCP/IP to Matlab.

Module 4 includes one tool and a graphic interface for the operator. The KPI for predictive maintenance with Machine Learning tool is used to calculate in the form of a script several KPIs that reduce accidental shutdowns such as Remaining Useful Life (RUL). The interface with 5 screens represents the image on which, based on the acquired, filtered and analyzed data, they will be displayed in visual form, to facilitate the tracking operations.

5.1. Module 2: Microgrid Performance Sizing Tool

Depending on the status of the investment (microgrid already built or in the concept and plan stage), there is a source code that helps evaluate the existing performance (and propose a new architecture and an optimization algorithm for the control system) or identify optimal scenarios for the technical-financial analysis of the new microgrid.

The main information that is required by the application is the usual number of panels, number of inverters, energy capacity of the battery in kWh, battery efficiency, number of years the equipment is expected to last, etc. Additionally, the authors developed a script for optimization of sizing and operation, which is an innovation over conventional sizing software.

The whole tool represents an innovative dimensioning methodology (technically and financially) of the main components, which meets international design standards for renewable parks, while respecting beneficiary’s requirements and safety in operation.

The microgrid component sizing tool is used in two ways: independently and together with the automatic reporting tool (described below).

5.2. Module 2: Automatic Reporting Tool

The automatic reporting tool offers a framework to automatically create documents from MATLAB with figures, tables, headers and text. To achieve a powerful tool, this tool is used together with the dimensioning script. It has free spaces to fill only with details that do not require software development knowledge (used surface, required area, location latitude and longitude, etc.).

The tool for automatic reporting the microgrid specifications is based on the Microsoft® Component Object Model (COM) which provides a framework for integrating reusable, binary software components into an application, of an out-of-process Microsoft® Word® program server.

The automatic reporting tool is finally a word document, which the client can go through much more easily, having in the 13 pages of the report content about the annual production, installed power, contact details, connection schemes, etc.

Figure 5 is a representation of page 7 from the automatic reporting of the sizing of the microgrid components, where the exported page is shown in the upper right, and in the lower part a part of the Matlab code necessary for the development of the "SYSTEM DESIGN" function. It uses mathematical functions to implement the Calculation mode as a complement to the unification of all losses, which include: losses due to reflections, losses due to shading, mismatching losses, losses due to the effects of temperature variations, direct current (DC) circuit losses, inverter losses and alternating current (AC) circuits losses.

5.3. Module 2: Data Acquisition Methodology

Monitoring, control and limit setting by operators is done through an application developed and run in PcVue SCADA software (Figure 6) in paper use case. The application allows the creation of dedicated archiving and/or communication servers.

The values presented in these screens are collected through the Modbus TCP protocol, by creating a new remote application, independent of the local SCADA application. Being an IP-based protocol, it uses a request/response sequence and the services requested according to the tag address mapping (read, write, read-write).

The data archives are saved in an Office Excel database, where each column represents the data taken from a tag, and each row represents the data extracted with a sequence imposed by the user (seconds, minutes, hours). The main monitored parameters are: status, voltage, current, active and reactive powers, load and discharge limits, methodological data and daily energies calculated in the PLC, values of the instantaneous powers provided by the PV system and internal grid as well as the power from consumers.

5.4. Module 2: Filter and Clearance Data Tool

Data exported from real-time monitored industrial processes may contain various anomalies, which may influence the final results of the data analysis, if they are used as raw data. In the energy field there can be anomalies given by: stability of communication and lack of signal; evaluation of the number of alarms; write or read errors; scaling or calibration; cyber attacks and takeover by hackers, etc. [34].

Thus, in the specialized literature [35] several cleaning and filtering methods have been proposed for more accurate results.

In this work, a cleaning script for Filter and clearance data tool with Matlab was used. Deciles was used to divide an ordered set of data into 10 consecutive subsets of equal sizes. Mean was used in the Matlab code to find out the mathematical averages of the production data, measuring the central tendency of a statistical series. Median was used to find values outside the normal range data sets. Other algorithms used for filtering and cleaning were: ordering, detecting extreme values, deleting non-specific details, thresholds on the entire data set, detecting anomalies, revealing the average, censoring a vulnerable data, the distance of each value of the series from the average of the sample, defining intervals in which find the vast majority of observations, etc.

5.5. Module 4: KPI for Predictive Maintenance with Machine Learning Tool

Forecasting of predictive indicators aims to produce a correct numerical output for a new input, and the authors of this article used the common statistical analysis indicators to analyze the tendency and predict the outcome. The KPIs considered relevant for such applications are variance, standard deviation confidence interval, skewness, kurtosis, scatter diagram, correlation coefficient, and significance level.

In addition to this, a survival analysis using the Kaplan-Meier method was performed. It records the time from the beginning of the operating process with nominal data of the equipment in the microgrid, until the moment it has the first failure. The method was chosen because it has good clarity, although not every failure represents an accidental stop. In Figure 7, the Survival Curve is represented according to the probability of survival. In the complex code analyzed, the condition was introduced so that the operator only sometimes notes the accidental shutdown events in the maintenance log, and some revisions are unknown (it is known with certainty that there were revisions on day 30, on day 50, on the day 51 etc.). It is observed that on the 90th day a new failure is probable.

Other indicators were also calculated within the project, such as

• MTBF (Mean Time Between Failure),
• OEE (Overall Equipment Effectiveness) defined by the multiplication of 3 indicators: Availability, Performance and Quality
• Operating time (in real time)
• Total working time (daily/ monthly/ annual)
• Total down time (daily/ monthly/ annual)

5.6. Module 4: Platform Screen

a)

Interactive environment description

The platform represents a software implemented in a development environment with layout design and code views, called App Designer, being a development tool from the Matlab suite and also provides controls such as gauges, lamps, knobs, and switches that replicate the look and actions of instrumentation panels. It then automatically generates the Object-oriented programming (OOP) and graphical user interface (GUI).

App Designer provides an extensive library of user interface (UI) components that can be dragged and dropped on work windows, to create various interactive features. For the application in this paper the following functions were used:

• Display message
• Create LABEL
• Simple computing
• Lamp for indicate the state of visibility
• Switch statement for a command
• Develop a knob for indicate the maintenance KPI
• Predictive Remaining Useful Life (RUL) with semicircular gauges
• Reading Data from an Excel to Table
• Plotting Data from Table2Array from platform

b)

The 5 screens OM description

Module 4 of the developed platform achieves a synergy between 5 main screens for OM life stage, being an intermediate version of a Technology Readiness Level (TRL) 6 (to receive further improvements and tests to be validated in specific environments and accepted on the market). For reasons of microgrid system security, the displayed data do not represent real data, but synthetic data. The five screens are presented as follows.

Screen 1: Microgrid performance and equipment status

The role of this screen is to allow the operator to check how the String Box Buster (SBB) presents a certain status and to take note of any anomalies or to load historical data (on the right of the screen at the bottom). The parameters visualized by the consumer up to the delivered energy reach essential points in the visual analysis that will allow the operator to make decisions on the spot, or let the algorithm continue to operate automatically. The production screen is made up of 4 sections:

• ‘Parameter Visualization’
• ‘SBB status display’
• ‘Operation Condition’
• ‘History data upload’

In the ‘History data upload’, historical data regarding consumption, production, SBB, invertor and battery can be extracted for being uploaded, displayed and analyzed contextually.

Figure 8. Microgrid performance and equipment status.

Figure 8. Microgrid performance and equipment status.

Screen 2: Evolution graphs

The graphs provide an image that can help to indicate a trend in which production or consumption is at that moment. In this screen, in addition to the real data, graphs with forecasts are also presented. Forecasts help because in the event of an accident, it is possible to identify the possible amounts of energy that will be produced after the anomaly is rectified.

Similarly, the graph for all alarms indicates an increasing trend of alarms, indicating a high degree of technical problems, which burdens the system and can favor accidental, unwanted and high-cost shutdowns.

Screen 3: Equipment specifications

The ‘Equipment specifications’ screen offers technical data and documents for all available equipment. For each piece of equipment, the following sections are available:

• Specifications: equipment technical data;
• Attachments: documents such as operating manuals, installing notes, Computer-aided design (CAD) files, CE (stands for "Conformité Européenne", the French for European conformity) etc.;
• Maintenance history: historic data regarding maintenance, repair work or parts replacements;
• Notes: this section provides additional information left by qualified personnel for the maintenance crew responsible for the next batch of repairs.

Screen 4: Intervention planning

The ‘Inspection screen’ is split into two tables: ‘Centralization of unplanned revisions’ and ‘Revision scheduling’. Both tables share the fields: Equipment, Repair, Date, and Notes.

The equipment column indicates which part of the system or component has undergone inspection/will undergo inspection. The repair column indicates the type of repair the equipment had undergone while the data column indicates when the repair took place. The note column is for any observations the maintenance team had during the repair or for the next.

The table that centralizes unplanned overhauls indicates the station, equipment, type of intervention, date and observations for each unplanned overhaul that took place. Observations are indications for the next repair or calibration of the equipment, depending on the work that has already taken place on that equipment. The maintenance scheduling table contains the same columns as the unplanned maintenance centralization table, but unlike it, it deals with future equipment maintenance and not historical data.

Figure 10. Equipment specifications.

Figure 10. Equipment specifications.

Figure 11. Intervention planning (Screen 4).

Figure 11. Intervention planning (Screen 4).

Screen 5: Maintenance KPIs

The ‘KPI’ screen displays multiple circular indicators for each KPI.

In the KPI screen, the RUL value is displayed, in days on semicircular indicators with limit values set in advance by the technical teams.

The percentage values for availability, performance, quality and OEE will be displayed on gauges in the form of a dial. The MTBF value in hours will be displayed on a linear indicator.

Hourly values for the time the facility has been down, under maintenance or operating will be displayed on circular indicators. Activity and efficiency percentage values are also displayed on circular indicators. All values indicated within the indicators will also be displayed in the box below each indicator.

Figure 12. Maintenance KPIs (Screen 5).

Figure 12. Maintenance KPIs (Screen 5).

6. Conclusions and Future Work

This paper presents an unified platform that supports microgrid development and exploitation during its entire life cycle, from design to exploitation until its end of life. The platform is made up of 4 modules, covering 6 stages of the microgrid life cycle. The platform was developed in Matlab, which provides built-in tools and functions that were either used as such (for modules 1 and 3) or further developed in the available software environment to implement the envisioned functionality of modules 2 and 4. Using a single development environment for all the six life cycle stages brings financial benefits, reduces the pressure on the design engineers, operators and maintenance teams of the microgrid.

The screens shown represent an intermediate form, appropriate for a TRL6 development level. As future work the authors plan to improve both the relevance of the displayed information, as well as the usability of the design. Integration with the alarming module of the SCADA application is also considered, so that the alarms are visible on the Module 4 screen. Graphic borders will be developed by adding units of measure and 24h scaling. In addition, new data cleaning algorithms will be implemented for automatic filtering.

7. Patents

Platform architecture of the microgrid development contains a component of an intellectual property protection plan, through trademark protection, with application ID EFRO202300001478452.