1. Introduction
Since the early days of civilization, humans have tried to make life easier, to adapt to different climatic conditions [
1] and landforms, to facilitate increased comfort and to ensure a safe environment [
2], through a continuous process of innovation [
3], which in turn has led to an increase in energy consumption and global industrialization. Thus, the limitations in electricity production support this technological advance [
4] through innovation, which in this context refers to new or improved ways of achieving economic, social or environmental goals in rural areas. Interest in traditional energy [
5,
6,
7] brings with it new concepts leading to the emergence of energy communities, where in the paper [
8] the main goal of energy communities is to improve energy efficiency, reduce energy costs and increase energy independence from conventional networks, while also contributing to sustainability goals and reducing carbon emissions. 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 have arisen from the integration of renewable sources, the idea of microgrids provided a solution by joining this green energy with consumers and storage facilities. In this way, such structures can operate in a decentralized architecture, usually linked to the national grid, but controlled locally, where the paper [
11] emphasizes how these systems contribute to the efficiency of energy consumption and to increasing sustainability by integrating digital technologies for monitoring and optimizing energy flows in real time [
11]. The multiplication of electric microgrid solutions, which integrate several microgrids into a single common control system and can balance between demand and production, imposed a new concept—that of multi-microgrids [
12]. An important step forward was the development of the 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. In 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 to achieve microgrid energy independence.
EU Directive 2018/2001 defines energy communities; the paper [
11] presents a multi-disciplinary methodological framework for analyzing the modes of organization and operation of renewable energy communities, addressing aspects related to economics, sociology, technology, legislation and renewable sources (‘Renewable Energy Communities’), which proposes 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.
Various microgrid design tools have been proposed by various companies specializing in microgrids. A Microgrid Design Toolkit, developed by Sandia National Laboratories, is presented in [
16]. The kit is a piece of decision support software for microgrid designers that is publicly available for download [
17]. Intended for use in the early stages of the design process, MDT uses powerful search algorithms to identify and characterize alternative microgrid designs in terms of user-defined inputs and objectives such as cost, performance and reliability. In [
18], the development and requirement specification of a platform for the design and operation of microgrids is described. It is based on Modelon’s web-based modeling and simulation platform and its Modelica library microgrid. A list of the top 10 microgrid-as-a-service (Maas) companies is presented in [
19]. Hardware and software solutions are provided at the industrial level as paid solutions. The development of a common platform for microgrids that provides interoperability between components with different communication standards is presented in [
20].
Regardless of the integrated energy production–consumption model used, there is 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 that provides step-by-step support for microgrid (MG) development during the entire life cycle. It is divided into four modules, developed in a development environment commonly used in 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 the main challenges identified in the 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 a demonstration of the platform proposed by the authors.
Section 4 presents the developed tool, its architecture and the 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
Section 6 concludes this paper.
The innovative element of the platform consists of the integration, in a unique development environment based on MATLAB 2022b, of both the traditional design components and those of operating a microgrid. Although MATLAB is a common tool in engineering, using it in a platform that unifies these two aspects represents a new and effective approach. This integration allows engineers to design, simulate and manage microgrids in a cohesive framework, eliminating the need to switch between multiple specialized software types. By unifying design and operation in a single environment, the platform not only simplifies the workflow but also improves the consistency and accuracy between project stages, thereby reducing integration errors and optimizing the overall microgrid performance.
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 a minimum of 25 years [
21].
Existing research on the microgrid life cycle [
22] 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 [
23], 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 [
24,
25] involve merging the stages at the 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 [
26] analyzes and discusses 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 the work in [
26] 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 [
27].
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 [
28]. In addition to this, asset instrumentation can be added to support predictive maintenance [
29].
Data acquisition starts at the remote terminal unit (RTU) or programmable logic controller (PLC) level [
30] 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) [
31]. Control sequences and strategies are also implemented at this level.
Models and simulations (MSs) have been added to the life cycle of many processes to improve 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 [
32], that identical representation of a physical element using real-time data [
33].
Hardware in the Loop (HIL) [
34] 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 [
35] and increase the performance of a microgrid [
36].
There 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 more 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, some platforms have a hardware simulator component, as well as development environments with common programming languages (Python, MATLAB [
37], etc.). This way, there is great flexibility in implementing strategies proposed at a theoretical level in the research literature to the specific requirements of a real application. The most commonly used are Typhoon HIL, OPAL-RT and RTDS, having a rather high cost of the user license but enabling greater optimizations of the whole process.
More complex tools, like AnyLogic, Siemens MindSphere, ThingWorx, ANSYS, XENDEE or Eathon, are Digital Twin software that integrates 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 and extensible and customizable platforms for predictive maintenance or real-time data simulation.
Considering all of these, the authors noted that designing a strategy for the whole life cycle 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 to determine where upgrades can positively impact the return on 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 life cycle of a microgrid.
The proposed platform brings multiple significant advantages compared to those listed previously. First, it integrates both graphics and sizing functions into a single module and development environment, eliminating the need to navigate between different software or applications, which simplifies and streamlines the microgrid design and management process. Second, it enables the monitoring of operations and maintenance through the same graphical interface, providing a unified and real-time view of system performance, thus facilitating the identification and resolution of problems in a faster and more efficient manner.
Another distinctive advantage of the platform is its ability to integrate utility users, such as microgrid component factories, with microgrid beneficiaries to facilitate recycling and implementation of the circular economy after component disposal. This contributes to long-term sustainability and reduces the environmental impact of microgrids. In addition, the platform is designed to be used by system integrators, developers and end customers, providing personalized and secure access according to the level of rights, which ensures efficient and controlled access management to the platform’s functionalities and data. These innovative features underline the platform’s versatility and full integration, establishing it as an advanced solution for end-to-end microgrid management.
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 four modules; thus, several stages can be part of a module. One main objective was that these stages could be integrated into the same development environment. The proposed architecture is under the intellectual protection validation process, validating its effectiveness in a real case study.
Table 1 describes the stages proposed by the authors. For each stage, a novelty is brought out through the single life cycle development environment.
In the proposed platform, all of these six stages are handled by four development modules, as can be seen in
Figure 2. The four modules are explained in detail as follows.
Module 1 integrates the first stage (first stage: MG equipment production) and the last stage (sixth 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 bringing the concept of recycling and reuse in the manufacturing phase as close as possible to the users.
Module 2 integrates the second stage (second stage: customer identification) with the third stage (third stage: detailed design). This module is enacted by filling in some customizable spaces in the code, without the need for software developer knowledge. Automatic performance reporting is performed by clicking on a single button, and no coding skills are required.
Module 3 corresponds to the fourth stage (fourth 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 (fifth stage: operation and maintenance). Five windows are displayed, i.e., microgrid performance and equipment status, evolution graphs, interventions planning, predictive maintenance KPI and 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.
Another element of novelty and innovation of the platform consists in the development of a modular architecture composed of four interconnected modules, which cyclically integrate all life stages of a microgrid. This architecture not only unifies the process of design, implementation, operation and decommissioning, but it does so in an optimized way, ensuring minimal use of resources and maximizing energy efficiency. Each module of the platform is designed to communicate and adapt in real time to data and conditions from the other modules, thus ensuring continuity and increased efficiency throughout the entire life cycle of the microgrid. This innovative approach makes the platform an essential tool for engineers who want to manage microgrids in a sustainable and efficient way, answering the complex challenges of renewable energy and contributing to the smarter management of energy resources.
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 (second stage—customer identification, and third stage—detailed design) and Module 4 (fifth stage—operation and maintenance), as they carry the innovative contribution of their work. Module 1 and Module 3 are components that can be found in MATLAB and only need to be configured, but Module 2 and Module 4 each represent a cluster of tools developed specifically for the platform. 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 one methodology and three tools:
Tool 1: Microgrid performance sizing.
Tool 2: Automatic reporting.
Tool 3: Filter and clearance data.
These three tools were specially created that 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 are 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 the machine-learning tool is used to calculate in the form of a script several KPIs that reduce accidental shutdowns such as the Remaining Useful Life (RUL). The interface with five screens represents the image on which, based on the acquired, filtered and analyzed data, will be displayed in visual form, to facilitate the tracking operations.
5.1. Module 2—Tool 1: Microgrid Performance Sizing
Depending on the status of the investment (microgrid already built or in the concept and plan stage), there is a source code that helps to 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 the 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 the 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—Tool 2: Automatic Reporting
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—Tool 3: Filter and Clearance Data
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 the 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. [
39].
Thus, in the specialized literature [
40], several cleaning and filtering methods have been proposed for more accurate results.
In this work, a cleaning script for the filter and clearance data tool with MATLAB was used. Deciles were 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 datasets. Other algorithms used for filtering and cleaning were ordering, detecting extreme values, deleting non-specific details, thresholds on the entire dataset, detecting anomalies, revealing the average, censoring vulnerable data, the distance of each value of the series from the average of the sample, defining intervals in which we find the vast majority of observations, etc.
For example, the mean is the most common parameter that measures the central tendency of a statistical series, representing the arithmetic mean of all observations. The results below indicate that the average for one month (December) of PV production is 6.29 kW, being almost 10 times lower than the average consumption media_cons = 53.55 kWh. During this time, instead, the batteries have an average charge of almost 40%.
Although the average is a very suggestive characteristic of the data it represents, the existence of some values on a certain segment (outliners) can seriously disrupt the ability to illustrate the data. Above, we considered a data sequence where only one segment was extracted. We note that the mean average_SOC = 39.01% is higher than the mean on a sample M = 21.7532%. Differences between sufficiently distinct values are observed due to the influence of a sample compared to the entire population of data from December.
5.4. Module 2: Data Acquisition Methodology
Monitoring, control and limit setting by operators is performed through an application developed and run in PcVue SCADA software (
Figure 6) in the 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 and the values of the instantaneous powers provided by the PV system and internal grid, as well as the power from consumers.
Figure 6 illustrates a comparative analysis of SCADA data before and after preprocessing. Initially, the SCADA data are presented in their raw form, which poses significant challenges for interpretation using machine-learning algorithms due to complexity and noise. Following a thorough indexing and cleaning process, the data are subsequently organized into a structured table within MATLAB. The days represented in this refined dataset were selected randomly and are distinct from those analyzed in
Figure 4. This methodological approach highlights the transformation of raw, unstructured data into a format conducive to more accurate and efficient machine-learning analysis, demonstrating the enhanced clarity and interpretability achieved through preprocessing.
5.5. Module 4: KPI for Predictive Maintenance with a Machine-Learning Tool
The 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 the 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. This 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 noted the accidental shutdown events in the maintenance log, and some revisions were unknown (it is known with certainty that there were revisions on day 30, on day 50, on day 51, etc.). It is observed that on the 90th day, a new failure is probable.
Figure 7 shows an innovative selection of fault days extracted from the operator’s logbook, highlighting a sophisticated methodological approach. Unlike the data shown in
Figure 4, which reflect a careful analysis of the pre-filtered and cleaned dataset, the failure days shown in
Figure 7 were randomly chosen from the operator’s log, not included in the previous analysis. This method allows for a complementary evaluation of the model’s performance in unforeseen failure scenarios, providing additional insight into its robustness and generalizability. By introducing these failure data, a critical examination of the system’s response under random perturbation conditions is facilitated, thus emphasizing the model’s ability to handle unexpected situations and contributing to its validation in a more varied and dynamic context.
Other indicators were also calculated within the project, such as the following:
MTBF (mean time between failure).
OEE (overall equipment effectiveness) is defined by the multiplication of three indicators: availability, performance and quality.
Operating time (in real time).
Total working time (daily/monthly/annual).
Total downtime (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 to indicate the state of visibility.
Switch statement for a command.
Develop a knob to indicate the maintenance KPI.
Predict Remaining Useful Life (RUL) with semicircular gauges.
Read data from an Excel sheet to a table.
Plot data from Table to Array from the platform.
- (b)
The five screens’ OM description
Module 4 of the developed platform achieves a synergy between five main screens for the 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 shown in
Figure 8 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 four sections:
In the ‘History data upload,’ historical data regarding consumption, production, SBB, the inverter and the battery can be extracted to be uploaded, displayed and analyzed contextually.
Screen 2: Evolution graphs
The graphs provide an image that can help to indicate a trend in which production or consumption is recorded 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 from
Figure 9 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 (which 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’ from
Figure 10 is split into two tables: ‘Centralization of unplanned revisions’ and ‘Revision scheduling’. Both tables share the fields of 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 has 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 stage.
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 that table, it deals with future equipment maintenance and not historical data.
Screen 5: Maintenance KPIs
The ‘KPI’ screen from
Figure 11 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.
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 the end of its life. The platform is made up of four modules, covering six 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 of the six life cycle stages brings financial benefits and 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. In future work, the authors plan to improve 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 24 h scaling. In addition, new data-cleaning algorithms will be implemented for automatic filtering.
The current implementation of the modules has been successfully applied to a real-world case study, providing valuable insights and demonstrating their practical utility. However, several areas for future enhancement have been identified. Firstly, improvements will be made to the methods for collecting historical archives and data preprocessing to ensure more accurate and comprehensive data integration. Additionally, a new module will be developed to facilitate automatic data integration and near-real-time updates, which will enhance the platform’s responsiveness and efficiency. The graphical user interfaces will also undergo significant modifications to become more intuitive and adaptable, supporting scalability for engineering stations of varying sizes. Furthermore, the graph display screens will be updated to incorporate advanced visualization techniques, aimed at presenting the data in a more insightful and actionable manner. These advancements will not only refine the platform’s functionality but also optimize its usability and analytical capabilities.