ENEA PAES: A Web Platform for Supporting Italian Municipalities in Sustainable Energy Action Plan

The Covenant of Mayors promotes the Sustainable Energy Action Plan ( SEAP ), aiming to mitigate greenhouse gas ( GHG ) emissions in line with the European Union’s 2030 and 2050 targets. The Covenant signatories could take enormous advantage from a digital platform that allows SEAP drafting also to no technically skilled users, like majority of them are. The Italian National Agency for New Technologies, Energy and Sustainable Economic Development ( ENEA ) has developed the PAES platform in order to provide digital support to public administrations ( PA ) adhering to the Covenant of Mayors. The platform exploits open data and it is fed by energetic data aggregated on a municipal level. The platform offers appropriate functionalities for baseline CO 2 emissions inventory ( BEI ) filling out and a best practice ( BP ) simulation tool. The latter allows to contextualize each BP and to estimate its effects in terms of the main GHG emission. The BP showing the best estimation results can then be converted into concrete adaptation actions. So, this digital system facilitates local Italian municipalities in the strategic planning and monitoring of adaptation actions taken over time.


INTRODUCTION
The Covenant of Mayors is an agreement established to support local governments in reaching EU targets on clean energy and climate change mitigation.The well-known European '20-20-20' strategy, signed in 2008 1 , which calls for the achievement by 2020 of a 20% reduction in greenhouse gas (GHG), compared to 1990 levels, the generation of 20% of the European Union's energy from renewable sources and a 20% reduction in energy consumption.Covenant members commit to developing a Sustainable Energy Action Plan (SEAP) under the Guidelines established by the Joint Research Centre (JRC) of the European Commission (Joint Research Centre et al. 2010), which monitors and validates its minimum eligibility requirements.In 2015, the Covenant of Mayors focused its new strategy on GHG emissions reduction of 40% by 2030, aiming for a zero emissions economy that benefits from clean, sustainable and affordable energy for everyone by 2050 (European Commission and Directorate-General for Climate Action 2019).Moreover, it included climate change adaptation.Consequently, the new Mayors' Agreement has enhanced the SEAP in Sustainable Energy and Climate Action Plan (SECAP).The SECAP guidelines (Bertoldi et al. 2018a) led to the drafting of an action plan, with particular reference to the compilation of the Baseline Emission Inventory (BEI), the Risk and Vulnerability Assessment (RVA) (Bertoldi et al. 2018b) and the Monitoring Emissions Inventory (MEI) (Bertoldi et al. 2018c).
The ensuing Global Compact of Mayors for Climate & Energy (GCoM 2 ), established in 2016 by merging the original Covenant with the Compact of Mayors, a non-European coalition of mayors, represents the most extensive global movement of governments.The Global Compact is committed to addressing the three sustainable development themes promoted by the United Nations: climate change mitigation, prevention, or minimisation of potential damage from the adverse effects of climate change, and global access to safe, clean, and affordable energy.
The Covenant of Mayors has developed the My Covenant website, a private virtual space, to store, report, and monitor the BEI and MEI data subscribed by signatories. 3In the literature, several articles report analysis and outcomes of SEAP from different use cases (see, for example, Famoso et al. 2015;Santopietro and Scorza 2021), while others compare BEI and MEI results to estimate mitigation policies efficacy (Palermo et al. 2020a;Palermo et al. 2020b).
In this framework, ENEA, the national coordinator of the Covenant of Mayors since 2013, has developed a web platform called PAES 4 to facilitate all Italian signatories 5 to EU Mayors in the digital management of a Sustainable Energy Action Plan (SEAP).The web environment, created within the Energy and Sustainability for Public Administration (ES-PA) 6 project, offers a unique view of several open data, aggregated at municipal level, from Italian PA.Moreover, it enables the digitization SEAP process, generally managed, until now, in the analogical way.
The PAES platform focuses mainly on BEI deployment, which includes an estimation of the primary energy consumption (fuels or other energy sources) and GHG emissions occurring in the municipal area.For this reason, a BEI is a good starting point for local strategic planning of mitigation interventions.
It is worth remarking that the GHG emissions concern many different molecules (Cignini et al. 2020), CO 2 represent the main part, so in the following, when there is GHG it means only the CO 2 .
The BEI processing is, nevertheless, a complex activity that involves knowledge in many fields (engineering, energy management, and policy administration).In particular, the technical staff of small and medium-sized municipalities do not possess specific expertise.Moreover, there is a lack of digital and suitable tools needed for planning and drafting a successful SEAP.To overcome these problems, the above-mentioned activities are frequently outsourced, which may produce in the local governments some critical shortcomings.Indeed, primarily, this leads Cignini et al. Data Science Journal DOI: 10.5334/dsj-2023-037 to an increasing difficulty in improving and strengthening the job skills of the local technical staff.Additionally, outsourcing assigned to different actors involves a likely inconsistency in collecting data at the local level over time.
In this context, the PAES platform provides digital support to municipal operators to draft a BEI, taking advantage even of valuable open data (Mohamed et al. 2020) shared by Italian PA.Particularly, the BEI provides a preliminary estimate of CO 2 emissions divided by sector (residential, transportation, tertiary) and energy carrier.The CO 2 emissions, in the above sectors, represent 53.6% (Rapporto Ispra 2022) of total emissions in 2020, so mitigation measures regarding these areas may significantly impact climate change.BEI indicators are computed by means of a standardised method based on local energy consumption and production data, uploaded directly by the energy manager.Then, the drafting of a BEI over the time allows to follow the CO 2 emissions trend of the specific municipality, providing a kind of monitoring.
The BEI indicators provide quantitative information about the more critical areas requiring timely actions.The sound elaboration of a BEI is, therefore, the first necessary step for efficient planning and calibration of mitigation and adaptation actions to the local context.The platform also provides the user with a collection of BP (that is successful territorial actions of energy policy) and a simulation system in order to estimate its expected local impact in terms of CO 2 emission reduction and energy savings.The likelihood of the simulation is ensured by the ability to take advantage of public administration open data, from heterogeneous sources, regarding energy savings and GHG emissions.In addition, simulation results can be stored and compared at any time.The good practice showing more advantageous findings regarding to the reference context can be then converted into action, namely contextualized to the municipality and characterized according to socioeconomic and time parameters.So BEI data enables to focus even better on future policies tailored to the real context needs leading to the choice of appropriate technologies that guarantee the highest effectiveness of BP.
The gathered experiences within the PAES platform can become among local administrators a sharing knowledge model, as in the open community.The platform facilitates the transfer of acquired know-how by promoting the circulation and exchange of tools, information, and methodologies among local governments.In this sense, it could become a reference model also in non-Italian framework, greatly useful for other countries and government bodies who would like to adapt such platform for their own use.Indeed, modular and interoperability architecture of PAES platform makes possible a certain degree of functionalities customization to the specific users' needs.For these reasons, the PAES platform is itself a best practice, a positive example of a digital tool, able to provide support to PA in the SEAP development.
To the best of our knowledge, no similar systems are widespread.Indeed, except for a few isolated cases (Saad et al. 2021;Sáez et al. 2022), current web environments provide only a repository7,8 of successfully implemented SEAPS, but they do not offer the user any digital drafting support.On the web, some tools are available to lighten certain development tasks, such as a pre-filled Excel template and a GHG emission database (Kona et al. 2020).Still, those phenomena may increase the tendency to neglect monitoring actions, affecting long-term strategies to reach the climate change goal.Indeed, Rivas et al. (2022) report that, at the end of 2020, 72.6% of JRC-approved SEAP submitted by municipalities did not have any updating or monitoring.This concerns particularly the small municipalities that outsource their SEAP to external consultants, although they could take advantage of guidelines (Bertoldi et al. 2018c), tips, 9 and research about monitoring methodologies and tools (Cinocca, Santini, and Cipollone 2018;Delponte, Pittaluga & Schenone 2017).
This paper illustrates the platform's design and implementation in detail (see Section 2).Section 3 explores the sources of data and information that populate the PAES platform.Section 4 presents the interface design and usability test.Finally, Section 5 concludes the work and presents possible further developments.

PLATFORM DESIGN AND IMPLEMENTATION
The PAES platform design is started from an extensive requirements analysis made in collaborator with ENEA energy experts and supported by PA Energy Managers and municipalities operators that are system end users.First of all, the method that EU administrations use to draft a BEI has been analyzed, then state-of-the-art automatic tools were explored, finally, it was discussed whether this process could be automatized.Besides a few virtuous municipalities, the others generally do not have the digital equipment to store, to process, and to analyze energy consumption and CO 2 emissions data.Specifically, they have neither a specific tool for BEI automatic drafting nor a BP simulation.This means that local authorities are not easily able to estimate a BP potential impact in terms of energy savings (kWh) and CO 2 emissions (kg) avoided.Subsequently, they could overestimate or underestimate the BP real effects.

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 • 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 firstpartly 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 2 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 bus10 ) 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.

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 2 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.

DATA MODELING AND OPEN DATA
This section investigates how, in the PAES platform, data are modelled, according to Section 2.1.Then, it explores the open data sources that best suit the platform needs; finally, the last subsection presents how the database is populated by means of a semi-automatically approach.

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.

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 2 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. 11 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 2 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.
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.

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.2and 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.

Data extraction
Open data are downloaded from several heterogeneous PA data sources in the different common structured formats, that is, CSV, XLS, SQL dump.Thus, they are required an ad hoc script (named extractor) to download, transform and import them accordingly with the platform database schema (see Section 3.3.2for details).Other data, instead, are shared in semi-structured and unstructured formats.Based on the input data format and structure and the destination table schema, the extractor accesses the web page hosting the data and downloads the requested ones through web scraping.It transforms and converts raw data to suitable information that can be used to automatically populate the database through insert queries.
However, those data, not in machine-readable format, cannot be directly exchanged by means of API requests.So, now they must be downloaded manually.In the future, this function will be automatised through web scraping.
Only one data source falls into the semi-structured data category.It concerns the current mayor's name and the municipality logo, available (for 90% of municipalities) from an open website. 12In this case, a Python web scraper has been implemented for downloading the data, 12 http://www.comuni-italiani.it/.exploiting the Beautiful Soup13 library.Please notice such data does not come from a gold source, it can be outdated.Indeed, it is suggested to the user in the registration form so that he can modify or validate the values.
The worst case happens when data are available in unstructured formats; those must be extracted by PDF reports.This is the case of energy consumption data due to the railways provided by TERNA; these are manually converted into a suitable format and then automatically imported.These scripts run at first for populating the PAES dataset, thus periodically updating.

Data harmonisation
This section discusses data normalisation and harmonisation.As introduced in section 3.1, data acquired into the platform evolve around the geographical entity's municipality, province, and region.These are referenced and linked through the ISTAT code.Among the open data sources exploited, this code has been used in ISTAT and ENEA datasets only.The other sources identify the geographical locations through the textual name; thus, it leads to location name ambiguity issues, especially due to compound nouns or nouns reported in different languages that hamper mapping the location name with the ISTAT code between two or more sources.
Location can have a compound noun, can be spelt differently, or can contain accents and apostrophes.For example, the municipalities of 'S.Stefano di Cadore' versus 'San Stefano di Cadore', 'Sernaglia D. Battaglia' versus 'Sernaglia della Battaglia', or the provinces of 'Reggio Calabria' versus 'Reggio di Calabria and Reggio Emilia' versus 'Reggio nell'Emilia'.
A rule-based approach in combination with similarity algorithms was applied to match the geographical entity name with a standard code, enriching and standardising the dataset.
Specifically, this work refers to existing approaches for information integration, such as entity resolution or de-duplication, that also aims at finding real-world entities occurring in different forms in multiple data records (Costa et al. 2011).Additional functions can be used to model a textual score, that is, Jaccard or cosine similarity or machine learning approach for crossgazetteer matching (Acheson, Volpi & Purves 2020).
This work applies a similarity function based on q-grams extracted from the municipality name (Montanari and Puglisi 2012).The algorithm exploits a similarity measure comparing q-gram occurrences to evaluate the syntactic similarity of the compared names.
The comparing of the municipal names through the q-gram algorithm is very effective.The municipal names are often different because a part of them (a stop word or a translated version) is missing but q-gram can match it.The q-gram threshold set above 0.9 allows matching the 95% of names, the others are manually validated.Over the years, several Italian territorial authorities are merged, leading to a larger one, so the data related to the new authorities are loaded as the sum of the former ones.
As mentioned, the platform manages data into three categories: transportation, residential and tertiary buildings.For what concerns buildings, ISTAT provides a gold dataset for residential areas that are imported into the system as they are.Tertiary data are calculated as discussed in the next section.For other sources, data are not always at the municipal granularity as needed.This is the case of transport data available at the provincial level only.ACI shares the circulating car fleet by province, and it uses the province name as code.Two steps have been performed to include the ACI data in the platform.
First, data available at the provincial level have been normalised before being included.ACI provides raw data for each year, vehicle category, and EURO homologation, while the fuel type is a column name.This rigid structure would demand more effort when the data are required.Thus, column fields were automatically converted into row values.Still, the ACI data uses the labels 'not classified' and 'not available' for vehicle category and EURO homologation while it uses "other" for alternative fuels.In the first case, the under-represented records (i.e., less than 0.1%) are neglected.The alternative fuels with non-negligible occurrences have been labelled as gasoline vehicles with the worst EURO class, as an underestimation.One objective of the system is to provide data calculated for a different level of aggregation from the source.For example, transport data aggregated at the provincial level through a distribution model can be evaluated at the municipal level.To bring provincial vehicles to municipal granularity, the ENEA experts, as a novelty, argued to use the number of the driving license ratio (licence number divided by available vehicle number) as a reduction coefficient of the current circulating car fleet.
MIT shares, with periodic updates, an extensive dataset (license records table is about 4 GB) with detailed records of driving licenses by municipality name CSV file, one per region, obtained from a SQL dump.The location name ambiguity is faced, as mentioned above.The records details are not needed, so those are only considered in aggregated form, counting the number of driving licenses per municipality.
As a limitation, from the MIT records, the specific licence type has not been distinguished concerning the available vehicle type.Information is available and can be used in the next release of the platform.

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 2 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.
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.
The total CO 2 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).

2,
, 1 ( ) For example, the Catania (Sicily) ASEC is 42.47 kWh/m 2 for the residential building and 117.67 kWh/m 2 for the tertiary ones, respectively.Catania residential surface measures 10,824,546 m 2 , so 459,718,468 kWh is the expected energy consumption.It can be divided by the proportion reported in • 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 2 emissions are evaluated with Equation 4where the (IPCC n ) is the emission factor for each fuel (n).

, ,
, , ) The Figure 3 reports the CO 2 emissions of Bagheria divided by sector in comparison with Province of Palermo (Sicily).
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 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).

INTERFACE DESIGN AND VALIDATION
The PAES platform is developed by the most innovative technologies such as HTML5, CSS3, Bootstrap v3.3.7 library, JavaScript and jQuery library.The web interface has the following features: • responsiveness on different devices; • user friendly; and • accessibility14 (ENEA 2019).
The main system design has been deployed to guarantee reliability, transparency, privacy,15 and security.Its services are monitored over time.
The platform project consists of public and private sections.In order to ensure a good security level, the login, in the private area, is currently made via public digital identity system -SPID 16 or digital identity card -CIE. 17 From the public area, the open consultation of static pages is possible.Notably, the section 'Statistiche,' concerning Italian statistics, temporal data series are shown in filter/search tables or graphs.The user can consult these data interactively using visual analytics (Keim et al. 2008).
The user can toggle off the most used fuel (e.g., natural gas) and immediately see the single contribution of less widespread fuels in Italy as LPG and Diesel (see Figure 5).
Figure 6 shows Italy's CO 2 emissions ('t' for ton) trend from 2015 to 2020, based on the overall consumption.In this graph, there are three data series, one for each sector (residential, tertiary and transport).
All of them can be toggled on/off to display or not the relative data as in Figure 7, where residential and transport data have been toggled off.These functions allow a highlighting of visual trend in a specific sector that is otherwise difficult and cumbersome.Otherwise, in the logged-in area, specific functionalities are implemented by means of the CARD technology (section 2.2), such as: • BEI data entry by interface-driven; • BEI generation and download; • BP consultation; • BP simulation; and • BP conversion into 'action'.Related to BP simulation, the user can choose a BP and try several potential solutions by input of several values of parameters.If the simulation suits the municipality's needs, the best practice can be adopted to prepare a concrete mitigation action and insert it into the SECAP plan.
For example, Figure 8 shows the BP of replacing traditional 20 vehicles (city cars) with electric ones could avoid 18 kg of CO 2 .This simulation requires as input: the car segment to replace, the number of vehicles involved, and the new type of vehicles.The car segment can be: City Cars (A), economic ones (B), sedan or station wagon (C), sports car SUV or other large cars (D).So, depending on which segment the user chooses, it changes the average annual distance (based on national stats) and simulates how much energy and emissions those new cars save by following the equation 4) and by assuming that the replaced ones were the most pollutant (diesel-fuelled, with an average EURO class).
Also, the user can compare the BP impacts with the overall municipality consumption of the specific sector.The 'action' card allows the BP conversion and its implementation into a concrete measure.It can be used for comparison and monitoring.The effect of an 'action' implementation affects next year's BEI.In the logged-in area, the user can monitor through BEI graphs the annual detail of CO 2 emission by sector (Figure 9).
The pie chart is interactive and a specific sector can be toggled on/off.

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, 18 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.8seconds).
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).
18 Ergonomic requirements for office work with visual display terminals -Guidance on usability.

CONCLUSIONS AND FUTURE DIRECTIONS
In this paper, the PAES platform, developed by ENEA, is presented starting from requirements analysis until its interface development, focusing on data modelling.The system could represent a fundamental support to local public administrations in the BEI drafting digitalization.Our system attempts to provide the public authorities with valuable technical support to enable more effective territorial energy planning because it is calibrated on specific indicators related to the local context and derived from multiple open data sources.Indeed, the BEI indices algorithm, despite the simplification in the computation procedure, remains a precious support for a process, until today, poorly performed due to inappropriate tools.
The best practice (BP) repository provides an essential historical memory for subsequent planning by local decision makers.
The usable interface of the platform facilitates user interaction with its functionalities, as shown by usability tests.Specifically, users appreciate the platform ease of use, facilitated navigation of functionalities and interaction with graphics or data.Moreover, they judged positively the added value offered by the platform to their work, especially those affiliated with small and medium municipalities.
Thus, PAES platform constitutes an exemplary case in the European context, characterising itself as a best practice benchmark.
Anyway, there are several directions for platform enhancement, even due to the fact that the climate adaptation measures are not considered.The latter, indeed, have been added as part of the SECAP only in 2018, so this platform will integrate them in the next developments both for the data source and best practices/actions.
The main improvement goal includes the digitalisation of the BEI monitoring process (MEI) and the sending of monitored data through secure and encrypted IT standards, such as XML encrypted coding.The entire process, from data entry to the BEI monitoring, will be automated and remote-supervised without specific user actions.
Moreover, since some production sectors (agriculture, industry, forestry, and fishery) are not being considered, additional data could further enrich the aggregated municipal database; for example, waste treatment, land consumption, urbanisation characteristics, air quality data, water consumption and pollution, agriculture, and industry data, and so on.
However, it should be noted that the system needs continuous updating over time.So, the BP repository could not be exhaustive since the main solutions, commonly adopted, continue evolving in new technological and policy matters.For this reason, an expansion of the BP repository and energy production technologies, in numerical and sectoral terms, would also be an added value to the services offered by the platform.
All the available platform data are currently accessible through the dashboard by search and navigation tabs and presented through tables and graphs.So, a possible enrichment is to enable keyword search over structured data (Cozza 2023) to query and explore the data in an innovative way, such as by natural language.

Figure 1
Figure 1 Main part of the Entity -Relationship schema.

Figure 2
Figure 2 Open data ETL system into PAES database.

Figure 4
Figure 4 Fuel consumption disaggregated by fuel, measured in equivalent GWh.

Figure 5
Figure 5 Fuel consumption disaggregated by fuel, measured in equivalent GWh and with natural gas toggled off.

Figure 6
Figure 6 Example of CO 2 emissions history disaggregated by sector, measured in ton.

Figure 7
Figure 7 Example of CO 2 emissions history disaggregated by sector, measured in ton and with two series toggled off.

Table 2
Open data sources: Key field and granularity.

Table 3
Market share for different fuel/energy carriers in Sicily.
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,150kWh 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 2 /kWh IPCC.So, the Catania municipality emits 15,340 ton of CO 2 , due to LPG consumption.Cignini et al.
(Dore, Adams & Saarinnen 2019)ssion 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: Cignini et al.Concerning BEI functionalities, the platform allows downloading the BEI template in the Microsoft Excel format, as set up by Covenant of Mayors.This file is populated with first-party data and reference municipal data (both open data and enrichment ones).All data are stored in the relational database for future consultation, elaboration, and monitoring.

Table 4
Usability test results.