Impact framework

Scope

Impact Framework is a way to accurately compute and report software applications’ environmental impacts.

This is an incubation project being run inside the Green Software Foundation. According to their website’s banner (14 May 2024), they don’t recommend using it in any critical use case because the project is experimental (offers no support guarantee, has minimal governance and process, and may be retired at any moment). Nevertheless, it provides useful functionality (more details follow).

Impact Framework can be used to:

  • Take easily observable metrics like CPU utilisation and page views and instal and convert them into environmental impacts such as carbon emissions, water usage, energy consumption, and air quality.
  • Engage an existing library of plugins or create new plugins within Impact Framework based on your assumptions and observations.
  • Uncover the environmental impact of your software changes in real time by examining how your software’s environmental performance changes if your application moves to the cloud or experiences shifts in its runtime.
  • Record your observations, chosen plugins, configurations, and computed environmental impacts in a manifest file. Open the door for others to understand, verify, and challenge the entire process.
  • Empower others to rerun your manifest file, validate your findings, or question your assumptions. They can tweak configurations, select different plugins, and run the analysis themselves.

Summary

How it works

Impact Framework operates by running plugins. In the project context, plugins are code modules that implement simple data conversions. The inputs of such modules are usually service utilisation metrics and characteristics, while the outputs are usually energy consumption information, but other forms of data conversions are also supported (as long as they abide by the framework’s interface). A service may for example be a software application (which we want to be the subject of the energy consumption calculations). The framework clients install plugins as needed and then use a manifest file (essentially a YAML formatted text file) to coordinate some (or all) of their installed plugins to run them later using a command line utility of the Impact Framework. That is, the manifest file declares the sequence of running the plugins, which plugin outputs are supplied to which plugin inputs, etc. In a broader sense, this enables the framework clients (such as power users) to define the whole architecture of the service they provide (or otherwise want to calculate the energy of). Sharing plugins and manifest files between framework clients makes reproducibility of the results possible, enabling anyone to verify energy efficiency claims and potentially suggest architectural improvements.

Plugins

There is already a standard library of plugins and a community one. All the well-known plugins are listed in a comprehensive list in the documentation, including 26 plugins (of which 3 are built-in, 16 official and 7 unofficial). Among those, the plugins most relevant to energy calculations include the following:

  1. The Software Carbon Intensity (SCI) family of plugins (i.e. SCI-E, SCI-M, SCI-O and plain SCI).
  2. E-MEM and E-NET: energy due to main memory and networking respectively.

The official SCI plugins are based on calculations defined in the corresponding SCI specification, which defines a methodology for calculating the rate of carbon emissions for a software system. SCI indicator values can be aggregated by simply adding them together as long as they have the same functional unit. The functional unit is the unit for which the SCI scales (e.g. the number of API calls required, the number of users, or Machine Learning training runs, etc). According to this specification, the formula of the SCI calculation can be summarised as follows:

where the calculations involved in each coloured box are:

  • The red box indicates the total energy the software system consumes for a functional unit of work. This calculation is performed by the SCI-E plugin, which accepts the energy used by the CPU, main memory, and network traffic as inputs (Ec, Em, and En, respectively). These energy inputs are expressed in kWh, and some acquisition methods are briefly listed in the SCI guide.
  • The green box has the operational emissions (which refer to the carbon generated by a component while it is in use). This calculation is performed by the SCI-O plugin. In particular, the letter I is the carbon intensity (measured in gCO2e/kWh). The SCI guide briefly lists two possible methods of acquiring the carbon intensity value (here).
  • The blue indicates the embodied emissions. The SCI-M plugin performs these calculations. “Total embodied emissions (TE)” is the sum of Life Cycle Assessment (LCA) emissions for all hardware components. “Time reserved (TiR)” is the length of time the hardware is reserved for use by the software. “Expected lifespan (EL)” is the anticipated time the equipment will be installed. “Resources reserved (RR)” is the number of resources reserved for use by the software. “Total resources (ToR)” is the total resources available. There is an SCI guide for embodied emissions too.
  • Lastly, in gray, is the final calculation of SCI which is performed by the SCI plugin. The resulting value is measured in gCO2eq per functional unit (R).

The E-MEM and E-NET unofficial plugins can potentially complement the SCI calculation by supplying their outputs to the SCI inputs. Specifically for E-MEM:

  • where Um is the percentage of the total available memory being used in the time period (in the range [0,100]), Cm is the total amount of memory available (in GB), EGm is a coefficient for energy (in kWh per GB), and the resulting Em is the energy in kWh due to memory (as in the SCI calculation above). And for E-NET we have:
  • where Din and Dout are the network’s inbound and outbound traffic, respectively (both in GB), EGn is the coefficient for converting data transferred to energy (in kWh per GB), and the resulting En is the energy in kWh due to network handling (as in the SCI calculation above).

These two plugins are based on some case studies to configure default values for their coefficients (EGm and EGn).

Relevance for EXIGENCE

SCI seems to be relevant for energy metrics and energy measurements. In particular, the formulas it defines may help to mathematically model the energy consumption in an optimisation problem statement, in T2.1. Since SCI seems to be an ISO standard now (reference, blog post), it can be credited with some reliability. On the other hand, finding proper sources for the values to plug into the SCI inputs has the potential to prove tricky in a real-world setting.

The Impact Framework should also be usable without any major license concerns since it is an Open-Source project. For example, we may implement plugins ourselves which will correspond to the outcomes of energy measurement mechanisms stemming from our project. On the other hand, it is also an incubation project (which, according to its contributors themselves, does not offer support guarantees and may retire at any moment) which should mean we need to be extra cautious when relying on it.

Index