System Design of an Online Marketplace Towards the Standardisation of Sustainable Energy Efficiency Investments in Buildings

Abstract

Nowadays, the increase in sustainable investments, especially when it comes to energy efficiency in buildings, has been recognised as an important pillar towards reductions in energy consumption. In this context, there is a need for efficient and user-friendly digital tools that can support decision-making procedures for all involved parties in the energy efficiency value chain. The scope of this paper is to present a high-level architecture and system design of the energy efficiency marketplace developed within the framework of the ENERGATE project, an EU-funded initiative aiming to assist Building Owners, Project Implementors, and Financial Institutions to collaborate and execute energy-efficient building renovations. To this end, structured data through predefined information entries will be collected. This will facilitate the interactions between heterogenous stakeholders and contribute to the standardisation of processes. The paper focuses on the functional description of the system design of the ENERGATE platform by defining the architecture, components, modules, interfaces, and structured data, as well as highlighting the requirements of potential platform users and design principles to meet the necessary requirements while ensuring security, reliability, and effectiveness.

1. Introduction

This paper is an extension of work originally presented in the 2023 14th International Conference on Information, Intelligence, Systems and Applications (IISA) [1]. The building sector’s negative impact on the environment, both globally and specifically within the European Union (EU), is quite significant. According to the International Energy Agency, 30% of global final energy consumption and 26% of global greenhouse gas emissions derive from building operations [2]. As far as the EU is concerned, it is estimated that around 40% of energy used is consumed in buildings, while the building sector is also responsible for over one-third of the total energy-related greenhouse gas emissions [3]. However, there is a significant lack of energy efficiency (EE) projects in buildings that aim to improve the energy performance of the building stock, thus mitigating the environmental impact of the building sector [4].

The EU has established objectives determining that Europe shall be the first carbon-neutral continent by 2050 [5]. To accomplish this, it is necessary to transform and modernise energy services [6]. The importance of focusing on EE towards achieving the energy transition is also demonstrated and supported by relevant EU policies and directives, such as the package “Delivering on the European Green Deal” [7], and, more specifically, the “Energy Efficiency First” principle [8], the updated Energy Efficiency Directive [9], and the Energy Performance of Buildings Directive [3].

To enable broader implementation of retrofitting EE projects in buildings, it has been recognised that increasing investments in this sector is of vital importance [10]. EE investments can result in significant benefits, not only in regard to the energy sector but also regarding economic and sustainable development in general [11]. However, there are still several barriers hindering EE investments. For instance, there are often knowledge and communication gaps between market actors because of their heterogeneity. The stakeholders from the building side, including asset owners and managers, as well as technical experts that can design and execute EE projects, may perceive and understand an EE project differently compared to the financial stakeholders, who not rely only on criteria related to energy efficiency but also finances in order to select the best combination of projects to invest in. This hinders the whole process, even in its early stages [4,12]. The immaturity of the market and the lack of tools and platforms to assist the stakeholders in properly assessing the different aspects of the EE projects further impedes EE investments [13].

Therefore, it becomes apparent that it is essential to effectively leverage new technologies to create platforms that can contribute to the standardisation of the processes of EE projects and investments in buildings, implement well-defined methodologies to support decision-making and accelerate the whole process, spanning from project design to monitoring and verification of project results, facilitate relevant stakeholders, and encourage them to be involved in sustainable building renovation projects. One notable endeavour towards this direction is the ENERGATE project (Energy Efficiency Aggregation platform for Sustainable Investments) [14]. ENERGATE is an initiative co-funded by the EU under the LIFE programme, aiming to mobilise renovation projects’ completion and financing by providing a smart energy marketplace for energy efficiency investments in buildings enabled through an ICT-based platform. The ENERGATE functions in four main stages: the Zero Stage, which is the registration of the users in the platform; the Fetch Stage which is the collection of project-related information; the Process Stage, where projects are rearranged and aggregated to increase their chances of being financed and matched with potential financial stakeholders willing to invest in them; and the Deliver Stage, where feedback and validation of results is provided. The stages are also analysed in Section 2.2.

A few standards and architectures exist which serve the purpose of supporting services relevant to energy digitalisation (see

Table 1. Existing architectures supporting energy digitalisation.

Reference Architecture	Scope	Features	Limitations
BRIDGE	Smart grids, energy storage, and digitalisation	Definition of patterns for data exchange at the European level. Interoperability across domains. Knowledge sharing and policy recommendations.	Limited specific focus on energy-efficient buildings. General framework.
MATRYCS	Energy-efficient buildings, data analytics, and decision-making	Modular microservices architecture. Services for monitoring and improvement in the energy performance of buildings, facilitating the design and development of building infrastructure, supporting policy making and policy impact assessment, derisking investments in EE.	Heavy dependence on high quality data. Lack of support towards financing of energy efficiency projects.
BD4NRG	Smart grid analytics, data exchange, and marketplaces for energy digitalisation stakeholders	Dynamic data access control, traceability tracking, confidentiality guarantees, big data management and processing, data visualisation.	Focused primarily on smart grids and energy data trading; less emphasis on detailed building-level analytics.

). The services are relevant to monitoring and enhancing the energy performance of buildings, facilitating the design and development of building infrastructure, supporting policy making and policy impact assessment, and de-risking energy-related investments. For example, the BRIDGE Reference Architecture is an EU standard that focuses on systems related to smart grids, energy storage, and energy digitalisation. In particular, BRIDGE aims to define patterns to enable data exchanges at the European level, to gather knowledge, experience, feedback, and lessons learned, to create a structured view of cross-cutting issues that are encountered in the demonstration projects to help overcome the barriers to effective innovation, and generate outcomes to enable the interoperability between cross domains like electricity, gas, water, transport, and building-related ICT systems. In this perspective, BRIDGE aims to provide coordinated and coherent recommendations to reinforce the messages and boost their impacts towards policy makers [15]. Another noteworthy example is the MATRYCS architecture. MATRYCS is an EU-funded H2020 project that aims to capitalise and combine existing modern technological breakthroughs in the areas of machine/deep learning and big data to develop a new decision-making and data analytics solution for energy-efficient buildings. The MATRYCS System Architecture is a modular-microservices-oriented architecture comprising three functional layers: MATRYCS GOVERNANCE, providing data services that allow integration, processing, semantic annotation, storage and querying functionalities for the MATRYCS large-scale pilot datasets; MATRYCS PROCESSING, which is responsible for advanced data processing, and machine and deep learning training; and the MATRYCS ANALYTICS Toolbox, exposing the building analytics services to the end users. These services can be clustered into visualisations and reports engines, analytics, building services (services for energy performance, services for supporting the design and the development of building infrastructure, services for policy making and policy impact, and analytics for de-risking investments in energy efficiency) [16]. Moreover, the BD4NRG architecture includes four horizontal and one vertical (cybersecurity) functional layers. In particular, the Data Governance Layer is the middle layer that acts as an intermediary between data users and data providers who may want to decide case by case whether to disclose their data or not. It leverages state-of-the-art solutions to guarantee traceability, provenance tracking and accountability, guaranteeing confidentiality as well. The Scalable Big Data Management and Processing Layer acts as an information broker of the information exposed by the Data Governance Layer. Multiple data sources managed by data management systems and data hubs belong to this layer. The Applications Layer offers two clusters of services: the Open Modular Smart Grid Big Data Analytics Toolbox, which offers a working space for self-service capabilities that give autonomy to the end user by combing data that come from different sources, and the BD4NRG Data Marketplace, which is, in fact, a platform where a variety of assets like data, trained machine learning or deep learning models, and storage resources are exchanged between stakeholders.

It becomes evident that despite the existence of several standards and architectures, there is still a lack of a comprehensive and holistic approach that could support decision-makers in the whole energy efficiency value chain, including the different stages of EE project’s conceptualisation, design, financing, deployment, execution and monitoring. Thus, the scope of this paper is the presentation of the architecture of the ENERGATE platform, which has resulted from a concrete methodology involving examination of existing architectures and standards, collection of input from key market actors to determine the user requirements, and the deployment of techniques, algorithms, and design principles that enable the provision of reliable and effective services. The research at hand investigates a platform system design that has the potential to satisfy unmet needs of the market and assist a variety of user types. A very important aspect of the ENERGATE platform is the standardisation of the whole process, which is achieved through the standardisation of the information defining the EE project and the investment, as well as the standardisation of the activities and interactions between the market actors involved in the conceptualisation, design, implementation, financing, and monitoring of the results of EE interventions. This holistic approach, covering a very wide spectrum of activities in EE financing, has not been addressed by previous marketplaces and platforms, to the authors’ knowledge.

Following this introductory section which has illustrated the current situation of energy efficiency financing, provided an overview of existing architectures supporting energy-related services and described the scope of the research at hand, the paper is structured as follows:

• Section 2. Methodological approach: Demonstrates the methodological steps followed to design the ENERGATE platform architecture, as well as the identified requirements and the workflow of the marketplace.
• Section 3. ENERGATE platform system design and architecture: The different building blocks and components comprising the ENERGATE architecture are presented in the third section.
• Section 4. Discussion: In the fourth section, the results of the research, namely the ENERGATE platform architecture, are evaluated based on the identified requirements, also in correlation with relevant previous research.
• Section 5. Conclusions: Drawn conclusions and potential prospects for further research are presented.

2. Methodological Approach

2.1. Methodological Steps of the Creation of the ENERGATE Platform Design

The system design of the ENERGATE marketplace architecture is based on concrete methodological steps depicted in Figure 1.

Firstly, existing architectures are examined (also described in the introduction) so as to gain insights based on previous approaches and have an overview of potential technical requirements that the ENERGATE marketplace should fulfil. The initial platform workflow is defined. The ENERGATE workflow aims to standardise the whole process of project implementation and financing, starting at the early stages of project conceptualisation and providing support up to the final stages of monitoring project results. Thus, the proposed workflow of the ENERGATE platform, which is also the basis for its design, consists of the following stages: the Zero Stage, the Fetch Stage, the Process Stage, and the Deliver Stage.

The platform workflow must align with user requirements. Therefore, the next step of the methodological approach consists of stakeholder engagement and consultation. More specifically, partners participating in the ENERGATE project and representing various market actors involved in the EE value chain provide feedback on the ENERGATE workflow and specify additional elements, functionalities, and services that the platform could provide. Based on the newly extracted user requirements, the platform workflow is updated. To validate the effectiveness of the workflow in satisfying the needs of the potential users, consultations with stakeholders that do not actively participate in the ENERGATE project also take place. Feedback from external stakeholders is collected through a variety of methods and combination of quantitative and qualitative approaches, such as surveys, semi-structured interviews, bilateral and multilateral meetings, as well as training workshops that take place in the pilot countries of the project where the ENERGATE marketplace will be tested: Greece, Italy, Spain, France, Austria, and Latvia.

Surveys and Semi-Structured Interviews in Bilateral Meetings: The questions from the survey and the semi-structured interviews were divided into key stakeholder groups: Building Owners, Implementors, Financiers, and Public Bodies, corresponding to the target groups and user types of ENERGATE (defined below in Section 2.2). For Building Owners, the focus was on understanding their building types, past and planned retrofitting actions, and their decision-making criteria for energy efficiency projects, including technical, financial, and support considerations. Implementors were surveyed to gauge their areas of expertise, the potential value of a platform that matches them with relevant projects, and the key indicators for such matches, including financial and technical parameters. Financiers provided insights into their financing mechanisms, evaluation criteria, and how a platform could assist in aggregating projects, matching them with suitable funding sources, and streamlining the risk assessment process. Public bodies were asked about their experience with managing public buildings, the process of selecting implementors, and the potential benefits of pre-announcing renovation projects to improve public procurement outcomes and facilitate financing. The responses from all groups contributed valuable data, guiding the design of a platform that aligns with the specific needs and challenges of each stakeholder group, thus enhancing the overall effectiveness of the implementation of energy efficiency projects.

Advisory Board: The ENERGAGE Advisory Board was established, consisting of 7 members with expertise in various areas related to financing energy efficiency. The Advisory Board members shared their experience and provided insights and recommendations to improve the platform, during Advisory Board meetings, and some additional bilateral calls and email exchanges.

Regional Training Workshops: They are tailored to present the developments of the platform, as well as provide a detailed analysis of its functionalities. The trainings offer the possibility for stakeholders to exchange knowledge/experiences and stimulate the overall uptake and interest to the platform. Furthermore, the workshops give the opportunity to capture feedback and key learnings by working in close collaboration with stakeholders and key contacts. A unique training content and material has been prepared for each of the workshops based on the needs of each region. Although the exact contents of the workshops vary depending not only on the region but also on the progress of ENERGATE, the aim of these workshops is to provide an overview of the platforms’ functionalities, barriers, scope, and common issues encountered during the implementation and roll-out of energy efficiency financing in the broadest sense of the word. Participants are included to provide an assessment of the national and regional context-zooming in on the specific region of the host location of the training workshop to provide expert input on the region which will be adopted and if possible and/or needed, incorporated to the ENERGATE platform.

Specifically, 80 responses were collected through the dedicated survey, 211 stakeholders were engaged through email exchanges and meetings, and feedback was gathered from 8 Advisory Board members of the project over 3 meetings. Additionally, around 170 stakeholders participated in the four regional training workshops in Latvia, Spain, Greece and Italy. Figure 2 below illustrates the type of stakeholders that have been involved in the co-creation process of the platform by December 2024.

This consultation process results in a loop of redefinition of user requirements and refinement of the ENERGATE workflow. Therefore, the ENERGATE architecture is designed with the ultimate goal of materialising the ENERGATE workflow and satisfying the identified user requirements in the best way possible.

2.2. ENERGATE Users, Platform Workflow and Requirements

The users of the ENERGATE platform can be divided in two major groups: the users that insert information about the EE project seeking finance, belonging to Group A, whereas Financiers (or in some cases Implementors, for instance when ESCOs are considered) comprise Group B users, meaning that they seek to provide financial support or invest in the EE projects as they have been defined by Group A.

However, the users can be further divided depending on the services they provide and on the types of buildings they own or manage. Therefore, four categories of users are defined: Building Owners (private buildings), Implementors, Financiers, and Public Bodies (public buildings). More specific information is given as follows:

• Building Owners: Users that own or manage an asset (private building) that needs renovation (private owners, asset managers, property managers, building managers, building administrators, real estate developers). The Building Owners can use the ENERGATE platform to insert data relevant to the asset according to predefined information entries, so as to compare their building with other buildings that have been renovated in the past, search for technical experts to execute an EE project, and find sustainable finance actors to invest in the project.
• Implementors: Users that can provide technical support for renovation projects (Energy Service Companies (ESCOs), project developers, engineering companies, architect and design companies, energy consultants, installers, maintenance companies). The Implementors can use the ENERGATE platform to be informed about buildings, both private and public, that are planned to be renovated, prepare offers for the Building Owners, estimate the attractiveness of the project for potential investors, aggregate EE projects, and search for financial support.
• Financiers: Users that aim to support EE projects in buildings financially (financial institutions, investors, financing bodies). The Financiers can use the ENERGATE platform to explore and prioritise EE projects in private buildings and to be informed about EE projects in public buildings.
• Public Bodies: Users that aim to renovate one or multiple public buildings (municipalities, cities, regions, communities). Public Bodies can use the ENERGATE platform to insert data relevant to their buildings according to predefined information entries, so as to compare them with other buildings that have been renovated in the past, explore available EU funding mechanisms that might be suitable for their EE project, inform Implementors and Financiers in the platform about the EE project, and aggregate their buildings to create project bundles.

All of the users mentioned above are summarised in the

Table 2. User types of the proposed marketplace.

User Type	Stakeholders Included	Overview of Possible Actions
Building Owner	Private owners, asset managers, property managers, building managers, building administrators, real estate developers.	Creation of profiles for buildings. Selection of energy efficiency measures to be applied Selection of preferred type of financing. Searching for renovation experts.
Implementor	Energy Service Companies (ESCOs), project developers, engineering companies, architect and design companies, energy consultants, installers, maintenance companies.	Insertion of buildings or matching with buildings that need renovation. Extraction of well-structured offers with project details. Aggregation of project Searching for financial support.
Financiers	Financial institutions, investors, financing bodies.	Declaration of financial and non-financial criteria to be matched with projects. Ranking of projects according to the declared criteria and preferences. Accessing project-related information. Provision of financial support.
Public Bodies	Municipalities, cities, regions, communities.	Pre-announcement of energy efficiency projects. Exploration of available EU funding mechanisms. Notification to platform users interested in providing technical and/or financial support to projects in public buildings.

:

The activities and interactions of the different user types in the platform are described within the ENERGATE workflow, which has been designed, validated and fine-tuned based on stakeholder consultation. The workflow is divided in four stages: the Zero Stage, the Fetch Stage, the Process Stage, and the Deliver Stage. The stages are explained below:

Zero Stage: In the Zero Stage, users register in the platform. Depending on the type of user, a different profile is created. Building Owners, Implementors, Financiers, and Public Bodies initially fill in some basic information, including both personal information (such as name, surname, email to create the account) and information about the company or the organisation they represent. Implementors provide further details about the services they can offer to Building Owners, as well as their geographical coverage and the years of experience. This information defines the users’ accounts.

Fetch Stage: The Fetch Stage is the platform stage where users enter building-related information, along with technical, commercial, and risk-related aspects of the project. The information entries in the Fetch Stage include data relevant to the building’s typology (building location, use, type, ownership status, occupancy level, size, to name but a few), technical information (existing systems for heating, cooling, and ventilation), and energy-related information (energy consumption per sector, energy class and so on). The data are collected in a structured manner, as detailed below:

• Similar buildings from the ENERGATE database can be detected to help Building Owners and Public Bodies identify best practices.
• The private buildings can be matched with Implementors able to execute the project and provide technical support for the necessary EE measures.
• The public buildings can be demonstrated to users interested in submitting relevant proposals following the established procedures of public procurement.

Process Stage: In the Process Stage, the matching between private buildings and Implementors (if necessary, meaning the building does not have a technical team in-house) has already been achieved and, thus, all the details of the project can be declared to create a financeable product. A product can also be a bundle of projects instead of an individual one, since appropriate packaging of investments can lead to increased chances of projects being financed.

The products, aggregated or not, are then presented to the Financiers. To present the products that will be of interest to them, a matchmaking procedure takes place considering specific Key Performance Indicators (KPIs), and projects are prioritised based on a multicriteria approach.

As far as Public Bodies are concerned, in Process Stage, funding mechanisms are proposed for their EE projects based on the information declared in Fetch Stage.

Deliver Stage: The role of the Deliver Stage is to allow users to follow up on realised projects, by documenting project results and providing validation and feedback. This will enhance the flow of “real” information on EE and energy services results, while validation of savings and additional value streams resulting from implemented building renovation projects will increase the traceability and standardisation of the investment projects and foster trust among the platform users.

The above-mentioned ENERGATE platform stages are also summarised in Figure 3:

The ENERGATE platform also supports different scenarios of user interactions, which are defined in the form of use cases. These are summarised in

Table 3. Use cases of the ENERGATE marketplace.

ID	Description of the Use Case
UC1	A Building Owner searches for technical and financial support to execute a renovation project (thus, the Building Owner searches for both an Implementor and a Financier).
UC2	An Implementor searches for financial support to execute the project of an external client (thus, the Implementor searches for a Financier and does not interact with the Building Owners in the platform).
UC3	A Building Owner who has a technical team in-house searches for financial support to execute a project (thus, the Building Owner searches for a Financier and does not interact with Implementors in the platform).
UC4	A Building Owner who has sufficient financial resources to implement an EE project, searches for a technical team to execute it (thus, the Building Owner searches for an Implementor and does not interact with Financiers in the platform).
UC5	A Public Body explores EU level funding options though ENERGATE’s repository of funding sources.
UC6	A Public Body makes the information about an EE project available to Implementors.
UC7	A Public Body makes the information about an EE project available to Implementors and Financiers, that can be matched.

.

As mentioned, the workflow and use cases described above are based on the needs of the potential users of the ENERGATE marketplace which have been defined through consultations with stakeholders that are actively engaged in EE projects’ implementation and financing, to ensure that the services to be offered by the marketplace truly correspond to the needs of the market and facilitate the process for a broad spectrum of user types. Requirements are subsequently extracted, representing basic functionalities that the marketplace should be able to implement to ensure efficiency and reliability. The identified requirements are presented in the following table (

Table 4. Requirements of the ENERGATE marketplace.

ID	The Marketplace Should…
R1	Allow user registration and authentication.
R2	Manage user roles and permissions.
R3	Provide data encryption and role-based access control.
R4	Allow service selection by the user.
R5	Provide an admin panel with user and content management tools.
R6	Provide integration with third party Application Programming Interfaces (APIs).
R7	Automatically save generated data.
R8	Provide privacy restriction mechanisms for uploaded datasets.
R9	Provide anonymisation mechanism for personal data.
R10	Provide a data model for building representation.
R11	Compare newly inserted buildings to already renovated buildings.
R12	Combine existing data and user-uploaded data.
R13	Provide output describing key points of the renovation strategy followed by renovated buildings.
R14	Allow users to create a new project.
R15	Allow users to provide text input.
R16	Enable the upload of files by users.
R17	Allow users to enter and access information.
R18	Match buildings with project implementation partners.
R19	Send notifications to users.
R20	Detect the sub-set of projects which corresponds to users’ preferences.
R21	Allow users to choose from filters so as to aggregate projects.
R22	Detect similarities between projects.
R23	Create clusters consisting of individual projects.
R24	Exclude projects from a group.
R25	Allow users to determine the importance of project selection criteria.
R26	Prioritise projects based on users’ preferences.
R27	Monitor project results.
R28	Provide reports on energy savings, emission reduction, operation and maintenance (O&M) costs.
R29	Visualise energy performance information.
R30	Provide advanced visualisation tools to demonstrate project results.
R31	Demonstrate error messages if false user operation occurs.
R32	Support connections to Graphical User Interfaces (GUIs).
R33	Provide system modularity, providing the independent operation of its modules.
R34	Guarantee system recoverability and fault tolerance.
R35	Store data in an efficient way providing optimal space allocation.
R36	Prevent users from inserting invalid input.
R37	Isolate software errors, preserving its functionality.
R38	Be resilient to simultaneous requests.
R39	Provide data retention policies and backup procedures.
R40	Deploy suitable mechanisms to prevent data loss and corruption.

):

The workflow is summarised in Figure 4:

3. ENERGATE Marketplace System Design and Architecture

The ENERGATE Marketplace System Architecture dictates not only the platform’s functionality, but also its performance and reliability to withstand the growing demands. The architecture is divided into four main stages/ecosystems, corresponding to the stages of the overall workflow of the platform described in Section 2.2, that are responsible for a different functionality of the platform. The Zero Stage is responsible for user management and authentication, the Fetch Stage for data analysis and collection from users, the Process Stage for data processing and the methodologies for the services the platform offers, and lastly, the Deliver Stage for the UI (User Interface) and visualisation of the results. Each of the stages can be seen as a distinct module that can work separately and be reused. The platform also includes separate components to guarantee security from external and internal threats. The modules and the components that comprise the platform are designed to offer reliability and to ensure consistent performance under various loads. The overall architecture is depicted in Figure 5. The ENERGATE entity relationship diagram is demonstrated in Figure 6. The platform consists of the following components:

• Component 1—C1: Authentication/Authorisation mechanism and User Management Module.
• Component 2—C2: Admin Panel.
• Component 3—C3: Project Entry Module.
• Component 4—C4: Project Design Module.
• Component 5—C5: Building–Implementor Matching Module.
• Component 6—C6: Matchmaking Module.
• Component 7—C7: Aggregation Module.
• Component 8—C8: Project Monitoring Module.
• Component 9—C9: Data Lake and Data Access API.

3.1. Zero Stage

This stage focuses on user management and is responsible for safeguarding user information as well as handling user roles and permissions. This stage is deliberately separated to ensure security of user data but to also enable reusability and scalability. The stage comprises three modules, namely the authorisation/authentication mechanism, the user management module (Component 1—C1) and the admin panel (Component 2—C2).

Authorisation/Authentication Mechanism: This mechanism is responsible for organising user access and rights, by assigning user roles and enabling the appropriate permissions. This process is crucial for the platform since each role is connected differently to the rest of the platforms modules, thus making the navigation and functionalities different for each user type. More specifically, after the completion of the registration, Building Owners and Public Bodies are directed to the project entry module. Depending on the use case, Implementors are either directed to the project entry module (UC2) or the project design module (UC1, UC4, UC6, UC7). Financiers are directed to the matchmaking module. The authorisation/authentication mechanism is also responsible for the storage of highly critical user information. In order to enable these functionalities in a secure and efficient way, and further promote integrity and trust, the Keycloak framework is utilised [17].

User Management Module: The user management module on the other hand, interconnects the authorisation/authentication mechanism with the platform. Initially, it is responsible for gathering user information as well as storing supplementary non-critical user data. Additionally, this module manages user sessions and determines the user functionalities based on their roles and permissions. The workflow of the user management module and its interaction with the platform user is demonstrated in Figure 7.

Admin Panel: The platform also offers an admin panel to allow super users to manage and handle data and users. This module’s access is controlled by the User Management Module, and it is mainly used to control users’ roles and permissions and monitor and solve any data-related issues occurring in the platform.

3.2. Fetch Stage

Fetch Stage is the ecosystem that performs data collection, data cleaning, data harmonisation and data storage functionalities. It also contains an API for data management and access across the platform. The individual components included in this stage are detailed further in the following paragraphs:

Project Entry Module: This component (Component 3—C3) enables users belonging in Group A to insert data regarding buildings in the platform. More specifically, it provides the required interface and back-office functions that allow the insertion of data, in order to then be able to be matched and interact with other users. To strike a balance between completeness and user-friendliness, certain fields can be calculated automatically by the platform or given predefined placeholder values, so as to assist the users with the data insertion process. Additionally, some fields are designated as mandatory whereas others are included as optional, to further assist the users. The information entered at this stage is used subsequently by the building–Implementor matching module to find suitable Implementors, or by the aggregation and matchmaking module to find interested Financiers. The module consists of a user-friendly UI and is directly connected with the Data Access API to allow new data to be stored platforming the Data Lake. The UI also enables managing the data inserted and interacting with the decision-making support service (see Section 3.5).

Building–Implementor Matching Module: This component (Component 5—C5) analyses user preferences and building information and matches buildings with suitable Implementors. The module also handles matchmaking processes until a final building–Implementor pair is created. In more detail, this module compares the Implementor’s specified technical background and coverage, with the buildings’ geographical and technical characteristics. This allows the platform to then present Implementors with buildings that will be possible to implement and exclude buildings that had low possibility of being selected. Additionally, when an Implementor becomes interested in a building, they can send a preliminary offer to the owner in order to collaborate. This is carried out through a notification system that enables users to interact with each other, allowing them to find suitable matches. When a public building is considered (UC6, UC7), the Implementors are only informed about the building and cannot create an exclusive mutual match with it. The interaction of this module with platform users is depicted in Figure 8.

Data Lake: The ENERGATE Data Lake is a critical component for the platform, as it is used for storing various information related to users, “pilots” (defined below), and any additional data necessary. It is the main storage system of the platform, and it consists of two storage types: the Relational and the Document Storage. The Relational database contains the homogenised data inserted through the platform, as well as data acquired from the ENERGATE “pilots”. Pilots refer to the pilot organisations that participate in the ENERGATE project. Their role is to test the platform before it becomes available to all users, so as to identify issues and ensure that all the services function properly, to provide feedback on the operations of the marketplace, and to provide data from EE projects that have been implemented in the past to populate the ENERGATE database. The schema of the ENERGATE data lake is crucial since it dictates the data types that can be inserted and thereby presented via the platform, and also how the data are structured (see Figure 6).This schema was designed by taking into account the pilots’ needs and data availability, as well as requirements driven by important functionalities and modules in the platform. Thus, the Relational Storage allows the storing of user accounts, as well as information related to buildings and offers. While the information inserted by the platform is standardised and validated, the data provided by the pilots are given in file format and requires an additional layer of cleaning and homogenisation before being stored. However, this process is performed separately in the back-office via a data integration method, and only the end results are inserted in the Data Lake. As for the Document Storage, it is a schema-less storage used for static data and files uploaded by the users. It is interconnected with the Relational database through the backend of the platform in order to efficiently manage the user files. The data lake can be accessed only through the data access API.

Data Access API: This component acts as the intermediary for communication between all the architectural building blocks of the platform. It is responsible for providing data across all components while also managing the access to different data and functionalities. The API is directly connected with the data lake, and user management module, and can deliver data to the platform according to the specified permissions, ensuring secure data transactions and preventing unauthorised access. It is also connected with all modules that handle data or that require information from the platform’s UI. The data lake and the data access API comprise Component 9—C9.

3.3. Process Stage

The Process Stage contains components for data processing, decision-making, filtering and matchmaking to Group A and Group B users. More specifically, in this stage the projects are finalised by the Group A users and are ready to be presented and matched with Group B users. The following components are included:

Project Design Module: This is the functional centre of the platform where users can interact with all the available modules (Component 4—C4). It provides the platform’s UI for all necessary components, while also connecting them and enabling users to utilise them. It enables users to interact with each other and view the information that has been provided once a match has been established. The details of the EE project are inserted by the Implementor (UC1, UC2, UC4) or the Building Owner (UC3), including financial and energy-related KPIs. Thus, an investment package is created, and an offer is extracted, containing all the necessary information to enable the aggregation and matchmaking processes. The Building Owner (UC1, UC2, UC4) can review the offer to accept it, reject it or negotiate. The module is designed with security and user-friendliness in mind to enhance user experience and enable trust and reliability. It is connected directly with the Data Access API to access and store data, and it provides the UI for the other modules in this stage as well, so that users can interact with them.

Aggregation Module: This module (Component 7—C7) can aggregate buildings based on the user’s preferences and filters, thus creating more attractive bundles/clusters for the Financiers. It enables the users to choose from a set of filters and profile preferences, and afterwards uses this information to divide the buildings in groups according to the similarities, effectively supporting users in the aggregation of projects. The buildings in each cluster will have similarities based of the filters selected, thus leading to a bigger and more attractive, but manageable project.

Matchmaking Module: The Matchmaking Module (Component 6—C6) is responsible for filtering the projects provided from the Group A users and applying the necessary weighing factors in order to present them in a ranked order to the Group B users. More specifically, the module filters the projects and bundles that have been inserted in the platform and seek for a Financier, to detect the sub-set of projects that matches the user’s preferences. The projects and bundles are then prioritised using multicriteria decision-making (MCDM). As a first step, users are requested to rate the importance of each criterion of project prioritisation on a predefined scale, through the platform’s UI. Thus, the weighting factors of the criteria are calculated using the direct weighting method [18]. Subsequently, the TOPSIS (Technique for Order of Preference by Similarity to Ideal Solution [19]) method is applied to bundles of projects stored in the Data Lake in order to rank them. These bundles are then presented to the Financiers through the platform’s UI in a ranked list. The notification system is extended in this component as well, enabling the Group A users to communicate with the Group B users. The interactions of the user with the aggregation and matchmaking modules are demonstrated in Figure 9.

3.4. Deliver Stage

This stage is responsible for the platform’s functionalities after the completion of a project. It consists of the project monitoring module and its UI.

Project Monitoring Module: This component’s (Component 8—C8) main use is to store the results of the finished projects and provide analytics and visualisations to the respective users. Through this module it will also be possible for the users to provide feedback and validation for the results, which will then be stored in the Data Lake. The module will be able to handle different kinds of data, since in certain cases the buildings will be equipped with the necessary metering infrastructure to acquire data of energy consumption on a regular basis, whereas in other cases such data may not be available. If the latter is true, the users can provide less precise and frequent data on energy consumption that are available based on the energy bill, whereas it might also be possible to exploit simulation-based services to enhance the visualisations provided and to assist the users in perceiving the positive effect of the retrofitting measures applied to their building. The workflow of the module is depicted in Figure 10.

3.5. Microservices Cluster

Besides the services enabled by its main architectural building blocks, the ENERGATE marketplace delivers several additional services, so as to further assist the users in designing and deploying renovation roadmaps. These services are enabled by machine learning (ML) and Artificial Intelligence (AI) techniques, while custom data analysis methods are also implemented in the context of these services.

Decision-Making Support Service: This component encompasses ML techniques to assist the users in selecting the most appropriate EE measures for their buildings. The service uses already implemented projects provided by pilots for training and is able to provide predictions regarding energy, CO₂ and cost savings depending on a building’s characteristics and the selected measures. This is carried out by leveraging a LightGBM regression model, trained using characteristics such as the building age, number of floors, floor area size, energy consumption, CO₂ and implemented measures. The outcome enables users to estimate the impact different measures can have on their buildings The component also utilises a Gaussian Mixture Model to detect similar buildings that have already implemented EE measures in the past, to showcase best practices of building renovation projects to the user. The model is used to cluster buildings using the same features, so that users can then receive for each building a list of similar ones followed by the results achieved from the implemented measures. Therefore, the user can estimate the impact of different retrofitting actions and make more informed decisions. Within the same service, aggregated data from previous renovations can also be used for benchmarking. In other words, users will be able to compare specific indicators depending on the characteristics of the project (type of building and EE measure applied), so as to have a better perspective of the typical values for these indicators, thus ensuring realistic metrics. The results are provided through the UI of the project entry module.

AI/ML notebooks: AI/ML-based notebooks that have been developed in previous research [20], will be adjusted so that they can be exploited and incorporated in the ENERGATE marketplace. More specifically, the MATRYCS HORIZON2020 project will provide relevant services and trained models that have been successfully tested and validated, in order to enhance the platform with smart analytics and insights that will assist users. Service 3.3: National and EU Policy Impacts Assessment and Support leverages a data-driven methodology that labels EE investments based on their expected utility in terms of renovation cost and energy savings, and will be integrated in order to assist Financiers in making informed decisions regarding their investment options. Through this service, ML classification methods are deployed and combined through a meta-learning model with the aim of improving overall classification performance and determine the funding that each investment should receive according to its particular characteristics. The ML model evaluates the value of future EE projects in terms of cost and achieved energy savings in a systematic manner. The classification of the investment relies on a specific set of building characteristics and attributes of each project. The output of the baseline classifiers are probabilities expressed through three discrete classes: Class A, B, and C. The results of this service are provided through the UI of the project design module.

MATRYCS Services Integration: The ENERGATE platform has established a synergy with the MATRYCS project [21], since there are analytic services that can exploited [22]. By integrating and reusing the MATRYCS services, the platform is aiming to include new possibilities such as energy forecasting, investment de-risking and data visualisation. More specifically, as mentioned in the introduction of the paper, there are three layers in the MATRYCS architecture that contain components that will be integrated into the ENERGATE marketplace, namely the MATRYCS Governance, the MATRYCS Processing and Analytics, and the MATRYCS Visualisation Engine [16]. The Governance Layer will be used to enhance the security of the user management and authentication system. As for the Processing and Analytics services, the ENERGATE platform will integrate services enabling energy predictions to assist users in monitoring their buildings’ energy consumption, evaluation of potential projects and investments to provide further support with regard to the planning of the buildings’ renovation, and M&V processes to validate project results and incorporate simulations that will enhance the Deliver Stage of the marketplace. The integration of these services will improve the experience of the users and provide them with specialised tools that will aid them with the decision-making process. The Visualisation Engine of MATRYCS will also be used to create advanced visualisations and reports and generate maps for the provided data, with the ultimate goal to help users better monitor their projects and create a user-friendly and interactive UI to showcase statistics and results.

4. Discussion

The ENERGATE architecture provides a robust ICT environment enabling a variety of services assisting stakeholders across the EE value chain. It consists of four ecosystems, also representing the stages of the ENERGATE platform’s methodology (Zero, Fetch, Process, and Deliver Stages). Seven modules, along with additional elements such as microservices, the ENERGATE data lake and the data access API, form the building blocks of the ENERGATE architecture, which is designed in a manner that ensures reliable and effective provision of services while also prioritising user-friendliness and simplification of processes.

The architecture of the ENERGATE marketplace adequately corresponds to the identified requirements (defined in Section 2.2) that reflect the user needs and the necessary conditions to guarantee proper functionality. In particular, the user management module along with the authentication/authorisation mechanism (Component 1—C1) are linked to requirements R1–R4 and R9, since they enable user registration, authentication, permissions, restrictions, access control, and protection of personal data. R5 is also covered through the admin panel (Component 2—C2). The project entry module (Component 3—C3) is aligned with R10 and R13, because it is responsible for the insertion of structured and well-defined information on each building. Furthermore, the decision-making support service as part of the project entry module UI provides the output that R13 dictates. The project design module (Component 4—C4) is connected to R14 and R16, as it is in this module that the offers of the Implementors are created and defined. R18 and R19 are satisfied by the building–Implementor matching module (Component 5—C5), which informs and notifies users that can cooperate to deploy an EE project. R19 is also linked to the matchmaking module (Component 6—C6), since users are also notified when a Financier is interested in investing in an EE project. Other requirements connected to the matchmaking module are R20, R25 and R26, as this module filters and ranks the potential investment options for the users belonging in the Financier category. The aggregation module (Component 7—C7) satisfies R21–R24 by forming the clusters of projects based on the similarities between them and the needs of the user. R27–R30 are relevant to the project monitoring module (Component 8—C8), which enables services of reporting and visualisations after the completion of the project. Data are stored, protected, and processed thanks to the ENERGATE data lake in combination with the data access API (Component 9—C9). Thus, they are linked to R7, R8, R11, R12 and R35. Additional requirements, namely R15, R17, R31–R34, R36–R40, are more general and therefore related to multiple modules. The aforementioned requirements are summarised in

Table 5. Connection of requirements of the marketplace with the ENERGATE architectural components.

R1

R2

R3

R4

R5

R6

R7

R8

R9

R10

R11

R12

R13

R14

R15

R16

R17

R18

R19

R20

R21

R22

R23

R24

R25

R26

R27

R28

R29

R30

R31

R32

R33

R34

R35

R36

R37

R38

R39

R40

C1

√

√

√

√

-

-

-

-

√

-

-

-

-

-

√

√

√

-

-

-

-

-

-

-

-

-

-

-

-

-

√

√

√

√

-

√

√

√

√

√

C2

-

-

-

-

√

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

√

√

√

-

√

√

√

√

√

C3

-

-

-

-

-

-

-

-

-

√

-

-

√

-

√

-

√

-

-

-

-

-

-

-

-

-

-

-

-

-

√

√

√

√

-

√

√

√

√

√

C4

-

-

-

-

-

-

-

-

-

-

-

-

-

√

√

√

√

-

-

-

-

-

-

-

-

-

-

-

-

-

√

√

√

√

-

√

√

√

√

√

C5

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

√

√

-

-

-

-

-

-

-

-

-

-

-

-

√

√

√

-

√

√

√

√

√

C6

-

-

-

-

-

-

-

-

-

-

-

-

-

-

√

√

√

-

√

√

-

-

-

-

√

√

-

-

-

-

√

√

√

√

-

√

√

√

√

√

C7

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

√

-

-

-

√

√

√

√

-

-

-

-

-

-

-

√

√

√

-

√

√

√

√

√

C8

-

-

-

-

-

-

-

-

-

-

-

-

-

-

√

√

√

-

-

-

-

-

-

-

-

-

√

√

√

√

√

√

√

√

-

√

√

√

√

√

C9

-

-

√

-

-

√

√

√

-

-

√

√

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

√

√

√

√

√

√

√

√

√

.

It is noteworthy that the results and the usefulness of the study are aligned with previous studies and can be supported by previous research results. For instance, in [11], the need for innovative tools incorporating decision support methodologies to boost EE investments is recognised. Researchers in [12] and [4] have identified the consequences that the communication gap between stakeholders, as well as the lack of standardised procedures, have in the early stages of EE investments, pointing out the potential of web-based tools to address those barriers. Additionally, in [23], it is highlighted that relying on marketplace architectures is a beneficial approach towards managing processes (in particular when it comes to negotiations between companies), as marketplace-based connections between companies are more efficient compared to point-to-point connections. Furthermore, in [24], it is emphasised that organisational processes tend to become increasingly digitalised, hence the need for effective digitalised services incorporating advanced methods of data analytics emerges, so as to enhance user experience in digital marketplaces.

Moreover, the use of MCDM in evaluating EE investments has been previously proposed and the potential of such methods can be further explored [12,13]. In [13], the TOPSIS method (which is used in the matchmaking module of the ENERGATE architecture) was also proposed as the most suitable method to evaluate EE investments; however, the output of the proposed tool was a classification of the investments, whereas in the ENERGATE marketplace, TOPSIS is used to extract a ranked list of potential investments. This would be very helpful for users belonging to the Financier’s category, as it enables easier comparison between the available options, which has been validated by the stakeholder consultation processes that have taken place in the framework of the ENERGATE project. Other well-known data-related reference architectures in the field of energy, such as MATRYCS [16] and I-NERGY [25], among others, have been studied to generate the ENERGATE architecture. However, the ENERGATE marketplace presents different functionalities, besides management of data and exploitation of ML/AI techniques, shifting the focus towards the financing side and laying emphasis on user-friendliness and effective user interaction.

Additionally, the ENERGATE system design focuses on the standardisation of the processes related to EE implementation and financing. This is achieved through the definition of specific information entries that are common across different projects, describing both the building’s characteristics and the project’s indicators. Furthermore, the steps towards the design of the project and the link to the financing side are implemented through specific, standardised steps, further reinforcing the standardisation aspect of the ENERGATE platform. It is also important to note that the ENERGATE system design differs from exisitig platforms and marketplaces that offer services related to EE financing. The proposed EE marketplace manages not only to standardise but also automate the processes and interactions between the stakeholders, unlike other endeavours such as the eQuad platform, which, on one hand, brings the contractors and financiers in contact, on the other hand this is carried out in a non-automated manner through a due diligence process [26]. Another example is the “Mission Efficiency Marketplace”, which focuses on bringing together project developers and financial stakeholders. However, unlike ENERGATE, it does not involve the Building Owners or managers in the process, since it does not offer an approach specifically tailored to buildings [27]. Another advantage of the ENERGATE system design compared to other platforms is the fact that the processes for the energy renovation of both private and public buildings are standardised, unlike previous endeavours that focus only on one of the two sectors (e.g., Smart Cities Marketplace [28]). Therefore, it becomes apparent that ENERGATE manages to standardise and bring together services that are normally found across different platforms, creating an ecosystem of market actors and offering a holistic approach to decision-making support and standardisation of activities related to EE interventions and investments.

It has to be recognised that the ENERGATE platform’s system design still presents limitations. For instance, the information and data of the platform are primarily user-defined. This means that there is no automated verification mechanism to ensure that all the information provided by the user are accurate and true (although the users always need to comply with the terms and conditions of the platform, that oblige them to provide accurate data). The provision of false data by the users could be prevented by requesting specific documents and information during platform registration, proving the reliability of the company, and allowing for cross-checking. Especially in the case of Implementors, additional information could be requested (e.g., compliance with ISO standards) to ensure the quality of the service providers using the marketplace. Benchmarking mechanisms could also be used in order to ensure that the metrics and indicators describing the EE project are realistic. Furthermore, the compliance with EU taxonomy is not considered. The marketplace could be adapted so as to offer guidance to the users with regard to the compliance with EU taxonomy and the steps that should be followed to be aligned with EU taxonomy.

5. Conclusions

The paper presents the system design of the ENERGATE platform, an online marketplace aiming to standardise sustainable building renovation investments. The proposed methodology and architecture manage to simplify and standardise several processes of an EE investment, including the collection of the necessary data, the identification of the most suitable implementation partners, the support of the decision-making process regarding the renovation strategy, the design of the EE project, the detection of financial support for the EE project, and the monitoring of the results of the project after its completion. This holistic approach addresses several issues, that various market actors face in the context of EE investments. Such issues include the lack of standardisation and the communication gap between different stakeholders, among others.

Each one of the building blocks of the ENERGATE architecture serves a purpose and satisfies one or multiple requirements that the potential users of the marketplace have expressed, or functional requirements that ensure the reliability, efficacy and user-friendliness of the marketplace. The results of the research show that, in a marketplace supporting EE investments, it is important to carefully plan the processes of data collection, storage and processing, while ensuring that safety, privacy preservation, and transparency are top priorities. Moreover, it becomes evident that innovative techniques and novel methodologies exploiting ML, AI, and MCDM, as well as visualisation mechanisms, have great potential, and their possible role in assisting stakeholders involved in EE financing should be further explored.

The results of the study are useful for a variety of stakeholders. On one hand, a solid and robust methodology of the creation of the marketplace is presented. Thus, it can be a reference point for various researchers, as well as software designers and developers, involved in the conceptualisation and materialisation of marketplaces connecting different types of users, providing supporting services and standardising processes, not only related to EE but also to other fields. On the other hand, the ENERGATE marketplace’s target groups (Building Owners, asset managers, real estate developers, ESCOs, project promoters, engineering companies, investors, financing institutions, public bodies, etc.) can find this research useful. Besides being the actual users that will benefit from the ENERGATE marketplace, the stages of the workflow provide an overview of the EE value chain and the process of EE project design, development, and financing.

Future research could focus on incorporation of additional services in the marketplace. For instance, an additional functionality could be the monitoring of the performance of the users in the platform through a service that rewards them and incentivises them to be active in the marketplace. Another additional service could be the provision of a risk assessment methodology for the EE investments accompanied by appropriate suggestions to mitigate the identified risks. Furthermore, the monitoring phase (Deliver Stage) of the workflow could incorporate the evaluation of the project not only based on energy-related and financial results, but also on additional benefits such as social inclusion and increased comfort for the occupants of the building. In addition, services developed by other projects and initiatives could be explored, so as to create an ecosystem of services that provide support on EE implementation and financing as holistically as possible. Finally, further results could be obtained from the testing of the ENERGATE marketplace in the pilot countries of the ENERGATE project, namely Greece, Italy, Spain, France, Austria, and Latvia.