Following previous blogposts where EXIGENCE metrics for energy consumption, energy efficiency and carbon footprint have been discussed (Development of EXIGENCE Energy Consumption Efficiency and Carbon Footprint Metrics , Development of EXIGENCE Metrics for Energy Consumption, Energy Efficiency and Carbon Footprint #2), as well as methods for their realisation (Development of EXIGENCE Methods for Energy Consumption Metering), this blogpost presents implementation aspects of the methods and introduces certain prototypes that have been evaluated and some of them already integrated into EXIGENCE testbeds.
Methods and their implementations follow the idea of energy consumption metering at the most granular level, i.e., targeting the smallest software (SW) and hardware (HW) components where measurement is feasible, while avoiding estimations as much as possible. Additionally, methods and their implementations also enable exchange of metering data, and other eco-data, across all domains involved in service provisioning.
Energy Metering and Data Observability in Inter-Domain (or Cross-Domain) Environment
In order to understand the role and position of the metering and data observability methods within EXIGENCE, the figure below depicts high-level EXIGENCE architecture (first presented in Draft Functional Architecture proposed by EXIGENCE) with particular focus on energy consumption metering and data observability methods. Corresponding “metering”, “data collection”, and “data exchange” architectural blocks are embedded into the high-level architecture indicating their relation to other architectural blocks responsible for service delivery and performing other EXIGENCE-related functions such as those involved in “domain orchestrator” block.
Implementation of Methods for Energy Consumption Metering
Energy consumption metering across the end-to-end service delivery chain requires the integration of several complementary metering tools. The ultimate goal of EXIGENCE is to enable service-level energy consumption metering in an inter-domain environment, achieved through energy metering within each participating domain and supported by a data collection and observability layer that ensures transparent and secure exchange of measurement data.
Within the EXIGENCE, software-based tools such as Scaphandre, Kepler, Alumet, and PowerAPI are used for fine-grained energy monitoring at the application and virtualisation levels. In parallel, external power meters such as Shelly, Netion, Eaton, and APC NetShelter provide physical power measurements of network elements, compute nodes, and user terminals. Additionally, certain infrastructure components such as servers, radio units, and other appliances, have already in-built energy or power consumption metering functionalities which can be accessed through interfaces such as SNMP, API, or IPMI and Redfish API as its alternative/replacement.
In general, metering tools/applications mentioned above can be utilised within any domain and are therefore not domain specific. However – given state-of-the-art – even within a single domain multiple tools/applications are necessary to cover all aspects of per-service and per-user energy consumption metering as proposed by EXIGENCE.
Implementation of Methods for Carbon Footprint Calculation
To calculate carbon footprint, simplified approaches such as those proposed by the Software Carbon Intensity (SCI) Specification can be applied. However, EXIGENCE aims to enable the highest possible level of data granularity, with the goal of calculating emissions based on measured energy consumption rather than relying on coarse estimations. As observed in our previous blog on energy consumption metrics (Development of EXIGENCE Metrics for Energy Consumption, Energy Efficiency and Carbon Footprint #2), each carbon-footprint-related metric is mapped to corresponding energy consumption or energy efficiency metrics, which can be used to derive the parameters required by the SCI formula(s). When applying the SCI methodology, the EXIGENCE therefore aims to ensure the highest possible granularity of input data in order to produce highly granular emissions-intensity estimates that are as accurate and reliable as possible.
The implementation for exposing the data required for carbon footprint calculation, e.g., carbon intensity and energy mix at the site or service level, relies on the Prometheus monitoring toolkit and its capability to collect and expose metrics from the monitored system. Considering the calculation of operational carbon emissions, the main challenge is to ensure that the information about the profile of the energy mix provided by different energy sources is known and available at the right level of granularity. The energy mix at each site is usually related to a Power Purchase Agreement (PPA) with a Distribution Service Operator (DSO) and therefore it usually cannot be obtained directly, thus, an estimation needs to be carried out based on three scenarios:
(i) energy supplied over a standard contract with DSO where carbon intensity varies through the daytime (an average carbon intensity value per hour is available via API request to https://api.co2signal.com/ and https://www.ree.es/en/datos/apidata),
(ii) consumed energy is mix of locally generated renewable energy (zero emissions) and energy supplied by DSO (carbon intensity of the latter is evaluate as in case (i)),
(iii) energy supply is guaranteed to be from a specific set of energy sources via a contract with the DSO, thus a specific carbon intensity profile for each energy source is used.
In addition to operational carbon emissions, embodied carbon emissions need to be considered as well. These are derived from static information configured at the site level, based on data obtained from life cycle assessments (LCA) of individual hardware components and from datasets provided by the SCI framework. To technically support the acquisition and exposure of this information, a site energy profile exporter is being developed within the EXIGENCE. The exporter will calculate and export the following metrics: Power Usage Effectiveness (PUE) factor, Carbon intensity for each site in g CO₂ eq, Site’s Total embodied emissions in kg CO₂ eq, Site’s expected hardware lifespan in months, Site’s total resources in CPUs, RAM, GB. By retrieving relevant data from public APIs (e.g., ENTSOE, Electricity Maps, or national APIs such as REE for Spain, and even weather forecast data), the exporter will calculate these metrics and expose them in a Prometheus-compatible format.
Implementation of Data Observability Methods
Building upon the metering and calculation methodologies, the implementation of robust data observability methods is another important EXIGENCE goal. Observability, in this context, extends beyond simple data visualisation; it refers to the end-to-end framework for trusted collection, aggregation, verification, and auditable presentation of all energy and carbon-related data. The implementation draws inspiration from standards-based, multi-domain data sharing architectures, adapting concepts of data post-verification and real-time auditability to the EXIGENCE ecosystem.
To manage the complexity of data originating from diverse measurement tools (e.g., Alumet, Scaphandre, Kepler, PowerAPI, and hardware meters like Shelly plugs), a four-stage observability pipeline is defined:
- Measurement plane: consists of primary data sources, capturing raw energy data at the process, container, VM, and hardware levels,
- Collection and Aggregation Layer: this layer functions as the initial data processing stage, it consists of deployed agents and exporters (e.g., Prometheus exporters) that scrape or receive telemetry from the Measurement Plane,
- Trust and Verification Layer: this layer receives normalized data from the Collection Layer and performs post-verification before any data is committed to the time-series database or Knowledge Graph; its primary objective is to ensure that untrusted, inconsistent, or anomalous data is identified and quarantined,
- Observability and Export Plane: consists of the storage backends and visualization tools that consume the verified data from the Trust Layer, this includes the Prometheus time-series database, Grafana dashboards for real-time auditability, and the inputs for the Knowledge Graph Population process.
EXIGENCE implementation of end-to-end data observability is therefore designed to provide a trusted, holistic view of energy consumption and carbon footprint for ICT services. Modern services are often delivered as a chain, traversing multiple administrative domains (e.g., user domain, access network, transport, data center). Consequently, a centralized collection model is insufficient. EXIGENCE therefore references the related work of ETSI ISG PDL.
The architecture implements a federated model, defining functional components and interfaces for both within a domain (intra-domain) and between domains (inter-domain). The implementation is architecturally divided into two core functional areas:
Intra-Domain Functional Architecture:
Defines the components responsible for measuring, attributing, and aggregating energy data within a single administrative domain, this “vertical” process involves several key functional components including Resource Energy Measurement Function (low-level measurements utilising tools such as Alumet, Scaphandre, Shelly), Service Directory Function (maintaining a registry of all active services running in the domain), Resource Allocation Function (understanding the topology and state of the domain’s resources), and Service Energy Information Function (core “attribution” engine of the domain),
Inter-Domain Data Federation:
Defines the mechanisms for how independent domains securely exchange and aggregate service-level ecodata to build a complete end-to-end view; the solution relies on Distributed Ledger Enabler – Peer (DLE-Peer) deployed at each domain and acting as the trusted anchor point for sharing ecodata with other domains; further, cross-domain interfaces support standardized and interoperable ecodata exchange across domains, i.e., EXIGENCE defines PN-1, PN-2, PN-3, PN-4, Neif, and Ndle interfaces.
EXIGENCE end-to-end data observability implementation further includes post-verification and trust mechanisms based on Multi-Tool Attestation framework (the policy implemented dictates that critical energy metrics should be cross-validated by at least two independent toolchains) and Verification Block Generation (after successfully passing multi-tool attestation, data is packaged into an immutable, structured “Verification Block”, i.e., this is what gets transmitted to the definitive storage layer; thus, this process ensures data provenance, context, and integrity).
Finally, implementation includes knowledge graph interfaces, defined by the ontology serving as a common semantic interface between domain-specific agents operating within different domains. Rather than requiring direct communication between different domain systems with potentially incompatible data formats and representations, each domain agent extract raw energy and carbon measurement data from their respective infrastructure and transform it into the unified ontology that all domains’ shares. The EXIGENCE solution relies on GraphDB knowledge graph implementation.
More details on methods implementation, as proposed by EXIGENCE, can be found in deliverable D2.3, while methods themselves are elaborated in deliverable D2.2
References
Read EXIGENCE D2.1 – Metrics for Energy Consumption and Efficiency Metering: HERE
Author
Internet Institute Ltd
Rudolf Susnik, manages research and innovation-oriented projects at Internet Institute, focusing on 5G/6G, IoT, edge-cloud continuum, sustainability in ICT and ICT for sustainability. He has over 15 years of experiences from ICT industry, working for network operators and vendors. As well, he also has research and teaching experiences from academia, i.e., University of Ljubljana, where he received his PhD in 2007. In his free time, he actively serves as a volunteer firefighter, contributing to community safety and emergency response.