2.1 Functional requirements

The above requirements analysis allowed us to identify user classes and the system’s main functionalities. The platform is designed for:

• an energy manager (EM), who evaluates the energy need, consumption, and emissions and drafts the BEI
• a citizen as a private entity or individual person, who can read the main results and actions achieved by their own municipality on the public page (no authentication is required)
• a citizen, who can also submit the approving request for a small renewable energy production system as or private wind generator (this requires authentication; function to be implemented)
• a municipal operator, who manages other users (citizens) and approves or declines requested practices submitted by municipal users (to be implemented with the previous item)
• a government decision maker at a regional or provincial level, who monitors and compares results achieved by a specific territory (and between two or more entities); this analysis concerns energy consumption, emission, and actions, is BEI generated, and could plan further policies
• the system administrator, who manages the whole system and enables/disables user access

Core requirements led to deployment the following system functionalities:

• user registration and authentication
• management of energy municipal consumption by EM
• consultation and visualization of open data aggregated at a different geographical level through tables or interactive graphs
• BEI drafting management and download in MS Excel format
• BP management and simulation and conversion to actions

Extra functional requirements concern the following features:

• optimization of graphics and tables rendering
• improvement of data searching time (tables have a search form)
• compliance with the data protection regulation
• authentication enhancement

The platform offers a unique access point for consulting open data aggregated at the municipal level that otherwise would not be easily accessible since they generally are only available in national or provincial aggregated form. Moreover, a BP catalogue, along with their simulations, can be used by each municipality to provide support in choosing suitable energy-saving policies even for those not energy experts.

The platform generates a BEI draft by automatically filling the template based on the first-partly and reference data. So, the user can download the draft in MS Excel format on his device.

Each BP is presented by means of a CARD (see 2.2), including both descriptive and quantitative parameters. Many of these BP come from real case studies, projects presented by the municipality in previous SEAP or other mitigation initiatives. The BP catalogue is not exhaustive of the possible solutions, but it will be enriched based on new technical solutions, tax deductions, financial push measures, and regulations. Currently, it includes the following two categories:

• municipality policy: tax deduction for building energy efficiency and alternative mobility
• technological upgrade: tools for improving buildings and transports energy efficiency (replacement of boiler/cooler; thermal insulation; local fleet replacement; electric mobility; energy production systems)

Moreover, through a suitable simulation system, for each BP is possible to estimate the fuel/energy and CO₂ emission savings resulting from the concrete application of the specific BP, providing the user with its potential impact in the local context. The details of simulation algorithm are described in the Section 3.3.3).

The multiparametric model adopted in the simulations did not allow to estimate the confidence level of the results because of the high uncertainty degree in the input variables (coefficients and emission factors, distance travelled, vehicle type and consumption). However, the system remains useful for comparing different solutions between two or more municipalities (with comparable characteristics in terms of size, degree-days, and climate zone). For example, the technical simulations as PV installation, solar thermal, boiler or fixture replacement, and the majority of technical upgrades are easy to evaluate due to the large availability of nominal specifications, use cases and commercial solutions. The simulation in the policy field or in transportation as public fleet replacement, alternative mobility (e.g., the walking bus¹⁰) is far more difficult to evaluate due to the parameters and average values assumption (type of vehicle replaced, the average distance travelled, the number of children involved in the walking bus and so on). Indeed, the confidence level of technical BP is more reliable than the policy or the transport one.

Therefore, based on these simulation results and other considerations (local policy and territory peculiarity), the user can choose which BP to adopt among those simulated. Then, through an additional functionality made available by the platform, the BP can be transformed into action (see 2.2), and its simulation results can be stored on the user profile server-side and retrieved for future access to the system. So, the effectiveness of the action can be monitored and verified over time.

PAES platform has been deployed exploiting LAMP technologies. Its implementation follows the client-server model, it is composed of a database server, a server hosting the BEI and BP software, for processing client-side requests.

2.2 Methodology

In order to respond exhaustively to technical and functional requirements, the platform’s design has been achieved by means of the two ENEA methodologies: TOGA (Ionita & Gadomski 2023) and VENUS/PLUS2 (Fontana et al. 2020) The TOGA approach, based on the Information Preference Knowledge (I-P-K) paradigm (Gadomski & Fontana 2022), drives the design of the platform’s core functionalities focusing on the user’s preferences (e.g., high performance, low cost, etc.) and adopting a top-down strategy oriented to the final goal. On the other hand, the VENUS/PLUS2 methodology (Bargellini et al. 1996), aimed at achieving a high degree of usability in terms of visual user interfacing and high levels of system performance, has allowed a conceptual representation of the data model, relationships, and properties. The system modelling has been typified by employing the 5W-Plus rule: Who, What, Where, When, Why, How, and Other (Table 1).

Additionally, VENUS/PLUS2 introduces the concept of CARD. Each CARD constitutes a functional service module, a complex object (class) of a visual interface based on graphical objects and libraries (database and queries). The general card includes the minimum data set (MDS) regarding the municipality information (demographic parameters, aggregated results of GHG emissions, etc.). Other technical details CARD concern platform-specific features. In the PAES platform, two main types of functionalities have been identified: management/query and processing/simulation.

Specifically, the platform CARD are:

• General data contains the master data and summary monitoring indexes of a certain municipality.
• User manages users’ registrations and their profiles.
• Consumption/Emissions concerns entry, management, and view of municipal consumptions by sector and municipal data (number of inhabitants, m² of residential and tertiary sector area).
• Best practice allows the simulation of different use cases integrating actual and potential data regarding energy policies or technological upgrades.
• Action implements a BP into a real local context specifying tech upgrades and energy policies to be adopted.

This CARD modelling has made possible the deployment of the functions associated to data visualisation/updating of the BP and action applications. The developed system, based on a modular architecture, is robust, reliable, interoperable, and therefore responsive to the diversified application domains of SEAP.

Then, the transition from the methodological phase to the application one has been carried out in two successive steps. First, the physical data schema Paper-Based Prototype (PBP) has been defined; it consists of tables, associated to the CARD and simple calculation systems containing indices, weighting coefficients and specific consumption. Secondly, implementing the experimental system with the generation of the prototype (called ‘Running’) is needed to improve the web interface and database definition.

Finally, the platform user profiles are system administrator and expert operator. The first manages all profiles, grants access, checks procedures, and inserts and modifies BP. The second one is a municipal technician or EM representing the municipal; he monitors energy data and drafts the BEI.

3.1 Entity-Relationship diagram

The output of project requirement analysis 2.1 leads to the design of the database model by defining a specific Entity-Relationships (E/R) schema and its subsequent transformation into a logical-physical model.

The ‘Municipality’ entity is modelled based on the attributes derived from Italian official demographic and economic statistics provided by Italian National Statistical Institute (ISTAT). This institute publishes several parameters for each municipality, among them the identification code (named ISTAT code) to link, for example, the municipality with its province and region. The only use of the municipality name, indeed, can lead to ambiguities. Indeed, there are municipalities with the same name in two different regions, and at least eight of them have a homonymous; for example, there is a San Teodoro in Sardinia and a San Teodoro in Sicily, or there are two Castro (one in Lombardia and the other in Puglia region). The ISTAT code is a six-digit codification, the first three digits indicate the province; the following three represent the municipality number inside the selected province, so the whole code identifies bi-univocally a municipality. Figure 1 shows the geographical entities Region (‘Regione’), Province (‘Provincia’), Municipality (‘Comune’) linked each one by 1 to N relation, in fact, to each region belongs N provinces, and to each province belongs N municipalities. Those tables use the ISTAT code as the key field. The ISTAT classification allows for efficiently aggregating results for those three government levels. For example, the emission of a province is the sum of all emissions for each municipality belonging to it. In the E/R the entities ‘RipartizioneRiscaldamento’, ‘EmissioniTrasporti’, ‘EmissioniTrasportiProv’, ‘EmissioniResidenzialeTerziario’ represent consumptions and emissions for the following three sectors: residential, tertiary and transport.

The remaining entities concern the open data, and they are grouped highlighting the source. Entities modeling first-party municipal data (used for BEI), BP, action, and personal user information are not detailed in 1 for the sake of brevity.

The overall database has been implemented with the MariaDB/MySql DBMS.

3.2 Data sources

The platform manages these data:

• first-party municipal data
• reference data: open data and enriched open data

The first-party municipal data is populated by local data owned by each municipality. For example, the inhabitants (from the local census office), fuel and electricity consumption of their own buildings and vehicles, public road lighting, municipality fleet, public transport, and local plant (e.g., disposal facilities, energy production, waste treatment and other services). Most of them, such as the electricity cost for public buildings and lighting or from local energy production plants, are derived from the billing and internal municipal reports.

When local data is publicly available, it is automatically retrieved and prompted to the users for validation or updating; examples are the municipalities’ graphical logo, the mayor’s name, and the municipal building’s address.

In line with the strategy and goals of PA (Agenzia per l’Italia Digitale – AGID and Dipartimento per la Trasformazione Digitale 10/2021), the cognitive heritage of public open data was an essential reference for the platform’s design, so they are reported in aggregated form for each municipality to summarise economic and energetic overview. The enriched data includes the elaboration of the open data to enable the evaluation of primary energy consumption (fuel or electricity) and the CO₂ emissions, which are divided by sector and or category. For example, the tertiary building surfaces belong to enriched data, they are evaluated by applying Italian statistics about the housing sector (Cresme Ricerche SpA 2011).

The open data sources used are listed in Table 2, for each has been indicated the granularity (municipal as M, provincial as P and regional as R) and the key used.

In the following, the data used for the project, with their limitations, are reported. The source description is non-exhaustive of the available data and their potentiality. The ISTAT provides for each municipality its altitude, urban and territory characteristics such as solar exposition, climate zone, DD and the mentioned ISTAT code. Specifically, DD is computed as the annual sum of positive differences between the daily average outdoor temperature and the conventional ambient temperature (set to 20°C) (Spinoni et al. 2018). The ISTAT also provides each municipality with the inhabitant number, the residential building surface, the building year of construction, public transport demand per capita and other significant information. The main limitation of this source comes from the year of the update. Several statistics are related to the 2011 national census, while inhabitants are updated yearly with the permanent census.

The ACI provides the number of vehicles (updated annually) per year, province, environmental class (EURO), fuel type and category. Five main categories are defined for the latter: buses, cars, motorcycles, Heavy Commercial Vehicle (HCV) and Light Commercial Vehicle (LCV). The main ACI data limitations concern the missing municipal aggregation level (only provincial) and the province name is the data key. Some other limitations come from the categorisation, classification of vehicle types and their EURO homologation. For example, an electric vehicle misses EURO class or a few categories are collecting ‘single original’ vehicles. These cases cannot be classified into common categories (bus, tractor, car and so on) or a specified EURO class. Moreover, they are mostly negligible compared with diesel or gasoline ones.

The MIT data refers to information about each driver’s license in Italy, about the owner, the releasing municipality, licence type, releasing and expiring time. The limitations come from large records due to the presence of all licences (even the expired or belonged to deceased people). This data management requires high computational costs and memory to evaluate how many licences are available per year in each municipality.

The MISE collects annual data on the Italian natural gas infrastructure, so it provides the gas consumption of each province.¹¹

The Table 3 shows an example of Carrier Market Share (CMS) for each fuel or energy carrier in Sicily Region (source MISE, 2013). It is worth remarking the gas infrastructure does not reach all Italian buildings. The Sardinia and many small islands in the Tyrrhenian and Adriatic seas are not linked to natural gas or the national methane infrastructure as the rest of Italy. Still, those cities (or towns) excluded from national service have sparse populations and/or high distances between buildings, making it uneconomic to have a shared natural gas infrastructure.

TERNA provides annual electricity consumption divided by province and sector (domestic or residential, tertiary, transportation, and industrial). Residential and tertiary data, reduced by the electricity consumed in transport by the national railway lines, allow evaluation of an Average Specific Energy Consumption (ASEC). Total GHG are calculated from the available residential and commercial surfaces multiplied by the municipality’s ASEC. The TERNA data limitations are both the classification of energy consumption that differs slightly from other sources and the consumption of a regional capital includes the railway amount, so it has to be deducted from the municipal energy estimation.

ISPRA gathers environmental data and provides public inventory aggregated at the provincial and national levels, updated to 2019. These data are used as a reference to compare CO₂ emissions with those processed through the PAES platform. Limitations of ISPRA data are due to updating frequency (every four years) of the categorisation of the emission source; for example, the bus and HCV emissions are counted together while the ACI split them.

Finally, ENEA manages several national databases related to national energy data:

• Regional energy balances concerns energy statistics on production plants and consumption as prescribed by Eurostat’s energy balances, established by European Parliament and European Union 2008 and its respective amendments.
• Ecobonus is a national fiscal deduction scheme that helps homeowners fund the cost of their renovation works to improve the building energy rating and reduce the climate impact of building heating and cooling. ENEA designs the submission platform and collects data and documentation about these procedures.
• SIAPE (see Ministero dello Sviluppo Economico et al. 2015) collects the Italian Energy Performance Certificate (EPC).

These data are essential to represent the energy needs of the housing stock and transport consumption to evaluate each municipality’s efficiency performance (and pollutant emissions) (Pagliaro et al. 2021). Finally, it is worth highlighting energy balances are aggregated on a regional base only, unlike the other ones.

3.3 Data extraction, harmonisation, and enrichment

Public administration (PA) shares authoritative open data (Mohamed et al. 2020) by the guidelines proposed for data sharing (AGID 2022; Colpaert et al. 2013). These heterogeneous data are available in different machine-readable formats. In order to manage them, a system capable of extraction, transformation, and loading (ETL) was designed. As shown in Figure 2, this system extracts data from different sources (see section 3.3.1), then it correlates and transforms them (see sections 3.3.2 and 3.3.3), finally, it loads data into the PAES database.

The loaded data are employed differently: some of them (ENEA, ISPRA, and part of ISTAT data) are visualised only for consultation through tables and graphs, while all the others and some of ISTAT data are used for further elaborations, as discussed in section 3.3.2. The data enrichment also requires the TERNA and MISE data to evaluate consumptions and emissions.

3.3.3 Data enrichment

The data enrichment, starting from aggregated open data at the local level to achieve EC and GHG emission evaluation for each sector, category, and type. Several models are applied, one for each sector. For computational efficiency, such data has been pre-computed instead of a real-time user request (SQL query).

The energy consumption EC and the CO₂ emission have been evaluated separately for residential, tertiary and transport sectors. In the following three equations, the x variable means r (residential) or t (tertiary). The equation 1 computes the total building EC in the residential and tertiary sectors by changing the values S_r and S_t, sum of building surfaces of each sector. The Average Specific Energy Consumption (ASEC) of each fuel/energy carrier has been evaluated by using MISE consumption data, which allows assessment of the average energy consumed per unit of surface (square meter) for each building.

(1)

$E{C}_x=\mathrm{ASE}{C}_x\times S_x$

M1 \documentclass[10pt]{article} \usepackage{wasysym} \usepackage[substack]{amsmath} \usepackage{amsfonts} \usepackage{amssymb} \usepackage{amsbsy} \usepackage[mathscr]{eucal} \usepackage{mathrsfs} \usepackage{pmc} \usepackage[Euler]{upgreek} \pagestyle{empty} \oddsidemargin -1.0in \begin{document} \[E{C_x} = ASE{C_x} \times {S_x}\] \end{document}

The result of equation 1 is the energy required to heat and light the respective surfaces. So, it can be broken down between each carrier (electricity, natural gas, common fuels) to achieve the expected Carrier Energy Consumption (CEC) as described in equation 2 by multiplying for fuel market share of each carrier (CMS_n), n is the carrier.

(2)

$\mathrm{CE}{C}_{n,x}=E{C}_x\times \mathrm{CM}{S}_n$

M2 \documentclass[10pt]{article} \usepackage{wasysym} \usepackage[substack]{amsmath} \usepackage{amsfonts} \usepackage{amssymb} \usepackage{amsbsy} \usepackage[mathscr]{eucal} \usepackage{mathrsfs} \usepackage{pmc} \usepackage[Euler]{upgreek} \pagestyle{empty} \oddsidemargin -1.0in \begin{document} \[CE{C_{n,x}} = E{C_x} \times CM{S_n}\] \end{document}

The total CO₂ emission of each sector is computed with equation 3, where IPCC_n is the IPCC emission factor related to each energy carrier (see the attachment 1 of (Neves et al. 2016)), n is the energy carriers (natural gas, gasoline, diesel, LPG, biomass, and electricity).

(3)

$C{O}_{2,x}={\displaystyle \sum _{n=1}^N(\mathrm{CE}{C}_{n,x}\times \mathrm{IPC}{C}_n)}$

M3 \documentclass[10pt]{article} \usepackage{wasysym} \usepackage[substack]{amsmath} \usepackage{amsfonts} \usepackage{amssymb} \usepackage{amsbsy} \usepackage[mathscr]{eucal} \usepackage{mathrsfs} \usepackage{pmc} \usepackage[Euler]{upgreek} \pagestyle{empty} \oddsidemargin -1.0in \begin{document} \[ C{O_{2,x}} = \sum\limits_{n = 1}^N {(CE{C_{n,x}} \times IPC{C_n})} \] \end{document}

For example, the Catania (Sicily) ASEC is 42.47 kWh/m² for the residential building and 117.67 kWh/m² for the tertiary ones, respectively. Catania residential surface measures 10,824,546 m², so 459,718,468 kWh is the expected energy consumption. It can be divided by the proportion reported in Table 3, results are 239,973,040 kWh of Natural Gas, 36,317,759 kWh of Biomass, 67,578,614 kWh of LPG, 110,792,150 kWh of electricity (spent for heating/cooling). Liquid and gaseous fuels can be measured in volume or weight by multiplying them for their specific density. Specifically, the coefficients used in the platform for LPG are: 12.791 kWh/kg lower specific value, 0.565 kg/l density and 0.227 kg CO₂/kWh IPCC. So, the Catania municipality emits 15,340 ton of CO₂, due to LPG consumption.

The energy consumption and emission in the transport sector follow a model based on the COPERT coefficients (Dore, Adams & Saarinnen 2019). So, each municipality knows the exact distribution of the circulating fleet through ACI data. This distribution contains vehicle characteristics divided by:

• category: autobus, cars, HCV, LCV and motorcycles;
• EURO standard: it affects the average emission factor of vehicles; and
• fuel type.

For each above items, it has been hypothesised (based on Italian stats from Logistica (CONFETRA) 2017, Statistiche Unione Nazionale Rappresentanti Autoveicoli Esteri (UNRAE) 2019 and Contaldi, Rizzitiello, and Sestili 2015), the annual distance travelled (D_cat,n,EURO) by each vehicle and their average fuel consumption (FC_cat,n,EURO), measured in litre per km or in case of electric vehicle kWh per km.

The CO₂ emissions are evaluated with Equation 4 where the (IPCC_n) is the emission factor for each fuel (n).

(4)

$C{O}_2={\displaystyle \sum _{n=1}^N(D_{\mathrm{cat},n,\mathrm{EURO}}\times F{C}_{\mathrm{cat},n,\mathrm{EURO}}\times \mathrm{IPC}{C}_n)}$

M4 \documentclass[10pt]{article} \usepackage{wasysym} \usepackage[substack]{amsmath} \usepackage{amsfonts} \usepackage{amssymb} \usepackage{amsbsy} \usepackage[mathscr]{eucal} \usepackage{mathrsfs} \usepackage{pmc} \usepackage[Euler]{upgreek} \pagestyle{empty} \oddsidemargin -1.0in \begin{document} \[ C{O_2} = \sum\limits_{n = 1}^N {({D_{cat,n,EURO}} \times F{C_{cat,n,EURO}} \times IPC{C_n})} \] \end{document}

The Figure 3 reports the CO₂ emissions of Bagheria divided by sector in comparison with Province of Palermo (Sicily).

Figure 3 

Example of CO₂ emissions divided by the sectors residential, transport and tertiary (respectively ‘residenziale,’ ‘trasporto,’ and ‘terziario’) for Bagheria municipality (‘dati comunali’) in comparison with Province of Palermo (Sicily Region).

Those results are compared with Palermo emissions also with a percentage value (called ‘incidenza’). For example, Bagheria emissions represent 4.34%, 2.48%, and 4.34% of Palermo emissions for residential, transport and tertiary sectors respectively. The absence of officially shared data at a municipal level and the topic complexity require simplifying the algorithms to evaluate crucial results such as energy consumption and GHG emissions.

For example, the transport consumption model just described, uses a simplified approach by adopting the annual distance travelled and the average fuel consumption (one for each vehicle category, fuel, and EURO); both parameters come from literature, but they can be evaluated more precisely with experimental campaigns, surveys, or by further analysis of the fleet characteristics (based on additional open data from ACI source as engine displacement, age of the vehicle, preferred road type and so on).

Indeed, these algorithms have inherent uncertainty, several larger than others, which is possibly mitigated through comparison with real experimentation/measuring or real use case deployed (actions of previous SECAP). Still, those algorithms remain very precious for comparison results from different municipalities (or other territories as Province or Region) in the same conditions.

For example, the same action of fleet replacement could impact differently in two municipalities with a comparable number of inhabitants due to different ex-ante fleet (one can be more outdated than the other).

4.1 Usability test

The platform development follows an iterative and recursive model, in which the evaluation of core functionalities through testing activities has assumed a central role in understanding its degree of usability (Nielsen 2000). In this direction, the task analysis is based on direct observation of users involved in performing specific activities and the test feedback is the input for improving the platform design.

Test planning required several preliminary steps that defined:

• objectives;
• type of test;
• metrics;
• users sample features (number, type, etc.); and
• test environment.

The most popular metrics (Russo and Miori 2019), identified as such by the standard ISO 9241-11,¹⁸ focus on the evaluation of the usability based on the following indicators:

• effectiveness: the measure with which a user can achieve the goal of a task correctly and completely;
• efficiency: the number of resources spent to achieve the goal of a task;
• user satisfaction: the pleasantness and positive attitude of the user towards the product;
• learnability: the measure of how fast a user who has never seen the user interface before can accomplish basic tasks. It is estimated based on the analysis of a user’s learning curve from the first use of the software product until the moment of performing the basic tasks well enough; and
• memorability: the degree to which a user remembers the system’s functionalities

For the PAES platform’s usability tests, five EMs (4 male, 1 female) are designed to perform the following tasks:

• Task 1: platform registration
• Task 2: municipal consumption data entry and BEI generating (that is, download of the BEI template file)
• Task 3: viewing, reading, and discussing the municipal data in the platform private area
• Task 4: BP selection, simulation, and saving

The parameters considered for evaluation were:

• number of errors (E) made by the user;
• requests for help (H) of the user;
• tips (T) made by the user to improve the process and the platform functionalities; and
• average time of execution of each task measured in seconds.

Considering the results of the derived parameters H/E (Help/Errors) and T/H (Tips/Errors), it is possible to assert that user satisfaction and the average execution time of each task are acceptable overall. At the same time, users’ number of improvement suggestions was particularly low on average (T_avg = 3.75). Only for task 2, according to the higher complexity of the required task, the average execution time (413 seconds) was well above the average times of the other tasks (task 1 = 134.6 seconds; task 3 = 331 seconds; task 4 = 124.8 seconds). Similarly, there was, for the performance of this task, a significantly higher number of requests for help (H = 16) than the average number of requests (H_avg = 10.75). This places the H/E ratio (=5.3) significantly above the average percentage (H/E_avg = 3.07) (Table 4).