How can the environmental impact of a software application or AI model be calculated across the entire value chain? Our methodology introduces cumulative environmental impact accounts, combining embedded emissions, operational emissions, and indirect impacts at the application level.
## Excerpt
How can the environmental impact of a software application or AI model be calculated across the entire value chain — from the data center building to server hardware down to the individual workload? Our methodology introduces cumulative environmental impact accounts that integrate grey emissions, operational emissions, and indirect effects at the application level, distinguishing between productive and non-productive use.
## Content
*This methodology article is part of our work in the [NADIKI Project](https://ided.digital/projekte/nadiki-nachhaltige-und-messbare-ki-systeme).*
### Introduction
In this article, we present an end-to-end model for accounting for the environmental impact of a software application (hereafter "application"). To illustrate, we use the example of an AI model and service. The basic idea: An application maintains an environmental impact account — akin to a bank account — where environmental impacts are accumulated over the entire lifecycle. One can think of these impacts as a kind of environmental cost: Every entity in the value chain — from the data center building to the server to the individual workload — incurs impacts that are booked to their account and can never be written off.
For readability, we use precise terms, which we define in more detail in the overview, and explain the underlying concepts:
- **Digital Resources:** The capacity to process (computing power), store (storage), and transfer data (network traffic) generated by a computer system from energy.
- **Digital Resource Type:** When we refer to types of digital resources, we mean: computing capacity (Compute), storage (Storage), and network capacity (Network).
- **Entity:** The various entities in the infrastructure value chain required to operate a software application: data center building (Facility), rack (houses servers and network equipment), server (IT equipment that generates computing, storage, or network capacity), client device (e.g., laptop or smartphone). Network equipment is initially excluded.
- **Impact:** This refers to the resulting environmental impact (e.g., GHG emissions, resource extraction, pollution, electronic waste, etc.).
- **Environmental Account (Account):** Similar to a bank account where the environmental impacts for an entity are accumulated.
- The environmental impact indicators are identical for each entity and listed at the end of the document.
- For simplification, we refer to operational impact (Operational), grey emissions (Embodied), and indirect impacts (Indirect) — see definitions below.
- Each entity has two sub-accounts: **Productive Impacts** and **Non-productive Impacts**. The aim of each entity is to minimize non-productive impacts and prevent the account balance from increasing (or slow the accumulation).
- All accounts in this article are cumulative annual accounts. This means: Grey emissions are assigned to each entity as an initial balance at the start of their useful life. Operational environmental impacts are cumulatively added over the year. The total account balance can be retrieved at the end of the year (or another period). The temporal resolution can technically range from one hour to ten years — for this article, we stick to annual resolution as this makes the examples more understandable.
- **Productive Impact:** Occurs when the entity performs useful work — e.g., when a server uses energy to run an application.
- **Non-productive Impact:** Occurs when an entity is operational but not performing useful work — e.g., an idling server still consuming energy, or a half-empty data center, where half of the grey emissions are assigned as non-productive.
- **Useful Work:** We understand useful work at the end of the value chain. A server provides digital resources. These are by default non-productive. The server consumes energy during operation. Only when an application uses these provided resources do they become productive. The goal of server provisioning, virtualization, or orchestration is to maximize the share of productive resource use.
- **Operational Impacts:** Environmental impacts caused by the operation of the entity — e.g., for a data center, the energy consumption and related GHG emissions for operating cooling systems; for a server, the energy for operation.
- **Grey Emissions (Embodied Impacts):** Static impacts caused by the production of the respective entity. The grey emissions form the initial balance.
- **Indirect Impacts:** Impacts caused by a parent entity — e.g., operating a rack requires a data center building. If the building can house 100 racks, each rack has an indirect impact of one-hundredth of the building's direct impacts. Each entity can be assessed independently, while indirect impacts remain visible.
- **Useful Life:** Each entity has a useful life, for which we set meaningful default values. The useful life is given in years.
The complexity lies in the following calculation chain:
- Calculation of the initial balance of grey emissions for each entity
- Accurate capturing of operational impacts for each entity
- Proportional allocation of impacts to the application's account, depending on the actual use of all entities by the application
- During allocation: considering both virtualization and the distribution of applications across multiple data centers and servers (e.g., with many virtual machines or Kubernetes clusters/pods)
We begin with the calculation of the initial balances of the environmental impact accounts of the various entities. This calculation model allows each entity to be accounted for independently and only the impacts directly responsible to be measured as direct effects. The account balances of all entities are ultimately added when they are assigned to an application as direct and indirect impacts. It is possible to apply this model to a data center building, a rack, or a server individually. This is important because many actors of digital infrastructure along the value chain are "divided" — for example, a co-location provider only operates the building, an IT infrastructure provider rents a rack for their own servers, and a customer uses the servers.
The model also describes the dependencies between the entities — e.g., the data center must provide the emission factor of the electricity grid or on-site power generation to calculate the GHG emissions for the energy consumption of a rack.
### Calculation of the Initial Balance of Each Environmental Impact Account per Entity
If we use electrons as our "red thread" through the infrastructure to the application, they flow through the following entities:
- **The Data Center Building (Facility)**
- Electrons flow from the power grid or generators to the switchgear, to the UPS battery, and from there to the racks' power distribution units (PDUs)
- Part of the electrons is converted into thermal energy by cooling systems (overhead)
- Part is diverted for auxiliary systems such as lighting or security systems (overhead)
- **The Rack**
- Electrons reach the rack from the UPS systems and are passed to the power distribution units (PDUs)
- **The Server**
- Servers are connected to PDUs (typically with two or more plugs for redundancy)
- The server also receives thermal energy (derived from electrons) from the building through cold air blown through the bottom of the rack
- **Digital Resource**
- The server converts the electrons into computing capacity by powering the CPU or GPU and memory chips (read/write and persistence), hard drives, and a network card
- At this point, electrons become computing, storage, and network capacity (as well as thermal energy — waste heat as energy loss), which can be used by a digital application. The application knows no electrons — it knows the digital resources it requires and consumes.
#### Data Center Building (Facility)
As a first step, we determine the initial balance of the account for the data center building. This means identifying the grey emissions of the building.
The following components of the building must be considered. If this data is not obtainable from the operator, we have compiled a [default assumption](https://notion.leitmotiv.work/A-Default-Data-Center-Life-Cycle-Assessment-LCA-1a8efc5c58538020a7c7fea0a8833055?pvs=4) based on public information.
> If a data center has a [BREEAM](https://breeam.com/) certification, it also has a lifecycle assessment (LCA) for the building, which should be requested.
- **Useful Life: 15 years** (Default assumption)
- If a data center operator commits to using the building for 15, 20, or 25 years, it reduces the annual initial balance and thus the impact per year (and consequently also for the application, as we will see later). This is desirable, as extending the useful life of all entities is a primary sustainability goal.
- **UPS System**
- A lifecycle assessment (LCA) or better an environmental product declaration (EPD) is needed for the batteries or other UPS components. [Example here.](https://register.pep-ecopassport.org/pep/consult/mbesqrsCBZbWbKJq6-kJ3ivRIBRLa6imH2a4YXgk7xw/mbesqrsCBZbWbKJq6-kJ3lQmBuGvAHsLUfQU9idjOpk)
- **Backup Generators (Diesel, Gas)**
- In case of a primary power supply failure (usually the power grid), data centers have backup systems that take over while UPS batteries bridge the transition period.
- An LCA or EPD is also required for each generator. [Example here.](https://register.pep-ecopassport.org/pep/consult/mbesqrsCBZbWbKJq6-kJ3rxTtdZ8zl09EaEprH5JLgA/mbesqrsCBZbWbKJq6-kJ3lQmBuGvAHsLUfQU9idjOpk)
- **On-site Generation Facilities**
- The building may have its own power generation capacities, e.g., solar panels or hydrogen fuel cells.
- An LCA or EPD is also needed for these components.
- **Building (Shell, Supporting Infrastructure, Floors, …)**
- A data center building consists of cement, concrete, steel, and other building materials. A [BREEAM](https://breeam.com/) certification requires a comprehensive LCA of the building.
- The LCA information on grey emissions should be added to the building's initial account balance.
- **Cooling System (in Whitespace/Air Handler, Transport, e.g., pumps, heat exchangers, chillers, refrigerants)**
- An LCA or EPD should be obtained for each component of the cooling system, [as in this example](https://register.pep-ecopassport.org/pep/consult/mbesqrsCBZbWbKJq6-kJ3rYjjAkQ2T_GboavpgfEoiQ/mbesqrsCBZbWbKJq6-kJ3lQmBuGvAHsLUfQU9idjOpk).
- Additionally, the total amount and type of refrigerants used should be identified to calculate the grey emissions of the refrigerants. [Our table here](https://notion.leitmotiv.work/List-of-common-cooling-fluids-GWPs-used-in-data-centers-1a8efc5c585380fe809feaf57d9dac83?pvs=4) helps with evaluation.
- **Air Conditioning Systems (Humidification/Dehumidification)**
- Most data centers treat the air in the whitespace (the area housing the IT equipment) to avoid high or low humidity that could damage the devices.
- An LCA or EPD should also be available for these systems.
- **Fire Suppression Systems**
- Most data centers have gas or water-based suppression systems. An LCA or EPD is also needed to determine the grey emissions.
- It may be necessary to evaluate the grey emissions of suppression gases/chemicals separately, based on the volume used in the facility.
Once data for all components is collected, it can be summed up. This gives the **Total Grey Emissions of the Building**. Dividing these by the useful life gives the annual initial balance.
**Summary Formula — Facility Initial Balance:**
$$EI_{Facility,Year} = \frac{EI_{Facility,Total}}{T_{Facility}}$$
Where:
- $EI_{Facility,Total}$ = Sum of all building grey emissions (from LCA/EPD of all components)
- $T_{Facility}$ = Useful life of the building in years
If the building is empty (no IT equipment), the initial balance could look like this in the first year:
1. Facility Total Grey Emissions over Useful Life: 15,000 units
2. Facility Environmental Impact Account (Year 1): 1,000 units (15,000 / 15 years)
1. Non-productive Impact: 1,000 units
2. Productive Impact: 0 units
The operational impacts are added subsequently. The initial balance exists independently of the building's use.
#### Rack
For the racks, we undergo the same process as for the building. For each rack, the following information needs to be collected:
- **Useful Life: 15 years** (Default assumption)
- Here, too, an extended expected/committed useful life reduces the annual initial balance.
- **PDUs (Power Distribution Units)**
- An LCA or EPD should be available for each PDU.
- **UPS Battery**
- Some racks have dedicated UPS batteries.
- If available, an LCA or EPD of the battery is required.
- **Rack Frame**
- Racks are typically steel frames, for which an LCA or EPD should be obtained.
**Summary Formula — Rack Initial Balance:**
$$EI_{Rack,Year} = \frac{EI_{Rack,Total}}{T_{Rack}}$$
If the rack is empty, the balance could look like this:
1. Rack Total Grey Emissions over Useful Life: 1,500 units
2. Rack Environmental Impact Account (Year 1): 100 units (1,500 / 15 years)
1. Non-productive Impact: 100 units
2. Productive Impact: 0 units
#### Server
Servers should generally be the easiest to assess as they are a single product from a single manufacturer. Unfortunately, not all manufacturers provide LCAs or EPDs for each product. Fortunately, there are numerous APIs, especially the [Boavizta API](https://doc.api.boavizta.org/getting_started/single_server/#retrieve-the-impacts-of-a-custom-server), that can generate an estimation of the grey emissions for each server model.
For the server, we can determine the initial balance as follows:
- **Useful Life: 5 years**
- Just like with rack and building, extending the useful life reduces the annual initial balance.
- **Server Hardware**
- Ideally, an LCA or EPD for the specific server model should be obtained. Example: [Dell PowerEdge R740](https://sdia.unternehmens.cloud/s/4F3mGP2K6EDPTjK)
- If not available, an estimate can be made using the server specifications (CPU model, RAM, storage, etc.) via the [Boavizta API](https://doc.api.boavizta.org/getting_started/single_server/#retrieve-the-impacts-of-a-custom-server) or other databases.
**Summary Formula — Server Initial Balance:**
$$EI_{Server,Year} = \frac{EI_{Server,Total}}{T_{Server}}$$
For this calculation, we assume the server is off:
1. Server Total Grey Emissions over Useful Life: 1,500 units
2. Server Environmental Impact Account (Year 1): 300 units (1,500 / 5 years)
1. Non-productive Impact: 300 units
2. Productive Impact: 0 units
#### Digital Resources
Since digital resources do not physically exist — they are created only when the server is on — and their grey emissions are the same as those of the server, we do not set an initial balance for digital resources.
#### Summary of Grey Emissions
Our environmental impact accounts on January 1st, with a single rack in a data center building and a switched-off server, look like this:
1. **Facility Environmental Impact Account (Year 1):** 1,000 units (15,000 / 15 years)
1. Non-productive Impact: 1,000 units
2. Productive Impact: 0 units
2. **Rack Environmental Impact Account (Year 1):** 100 units (1,500 / 15 years)
1. Non-productive Impact: 100 units
2. Productive Impact: 0 units
3. **Server Environmental Impact Account (Year 1):** 300 units (1,500 / 5 years)
1. Non-productive Impact: 300 units
2. Productive Impact: 0 units
**General Formula for the Initial Balance of Each Entity:**
$$EI_{Entity,Year} = \frac{EI_{Entity,Total}}{T_{Entity}}$$
### Adding Operational Impacts to the Environmental Impact Accounts
That was the easy part. Now we add the operational impacts of each entity to the account balance. These are the metrics that vary over the year and must be measured in each entity — at least on an hourly basis.
The challenge is that some operational impacts can affect the account balance positively or negatively. This must be determined for each entity with specific calculation logic. Measuring alone is not enough — a conversion and initial allocation to the correct impact indicator are required. In our metric list for each entity, we explain these conversions.
#### Data Center Building (Facility)
For the building, the calculation is relatively straightforward and focuses on energy, water, and waste. The main challenge is differentiating between various energy sources — local generation, nearby renewable generation, and the fuel of local generation (e.g., when diesel generators run). This is relevant for calculating the GHG impact indicator from energy consumption.
- **Operational Impact of the Data Center:**
- **Total Non-IT Energy Consumption** (kWh, measured at the output of the UPS system)
- Captures the electricity consumption of all overhead activities: cooling, lighting, losses in electrical and mechanical systems
- **Total Renewable Energy Generation** (kWh), broken down into:
- On-site renewable energy generation: kWh and type (e.g., solar panels)
- Physical power purchase agreements (direct purchase of generation) with renewable sources within a 50 km radius: kWh and type (e.g., wind)
- If total production covers 100% of the non-IT energy consumption, the GHG emissions can be considered 0
- **Total Non-renewable Energy Generation** (kWh), broken down into:
- Energy from on-site diesel generators (kWh and fuel type)
- The fuel type determines the emission factor, [our list is available here](https://notion.leitmotiv.work/Commonly-used-diesel-fuels-blends-and-their-GWP-value-15eefc5c585381578a32f7829b9b3ddc?pvs=4)
- Energy from the power grid (kWh)
- A grid emission factor must be obtained from historical data ([EEA](https://www.eea.europa.eu/en/analysis/indicators/greenhouse-gas-emission-intensity-of-1)) or through APIs like the [Electricity Map API](https://portal.electricitymaps.com/docs/getting-started#geolocation)
- **Total Disposed Waste,** broken down into:
- Waste categories according to the appendix
- Relevant waste streams: packaging, electronic components, cooling fluids, miscellaneous fluids and chemical waste, mechanical components, and anything leaving the data center
- **Total Freshwater Consumption** (m³)
- Measured via water meters or via water utility bills. Any freshwater consumption should be taken into account — whether for evaporative cooling or other water systems.
> Batteries can play a role in increasing the amount of renewable energy the building can absorb and utilize. We hope to account for this in a future revision.
**Summary Formulas — Facility Operational Impacts:**
$$E_{non\text{-}renewable} = E_{Total} - E_{renewable}$$
$$GHG_{Facility} = E_{non\text{-}renewable} \times EF_{Grid}$$
Where:
- $E_{Total}$ = Total Non-IT Energy Consumption (kWh)
- $E_{renewable}$ = Renewable Energy Generation (kWh)
- $EF_{Grid}$ = Emission Factor of the Grid (kg CO₂-eq/kWh)
For our example, we'll assume the building is empty, but cooling and overhead systems are running, consuming 10,000 kWh over a year. On-site solar panels generated 3,000 kWh during the year, and wind energy sourced from a wind farm within a 50 km radius contributed another 3,000 kWh. The average grid emission factor was 1 kg CO₂-eq/kWh. Diesel generators were not running.
The Facility balance is now as follows:
1. **Facility Environmental Impact Account (Year 1):**
1. Non-productive Impact: 1,000 units
1. Grey Emissions: 1,000 units
2. Operational Impact:
1. Total Energy Consumption: 10,000 kWh
2. Non-renewable Energy Consumption: 4,000 kWh (at 1 kg CO₂-eq/kWh)
3. Renewable Energy Consumption: 6,000 kWh
4. GHG Emissions: 4,000 kg CO₂-eq
5. Freshwater Consumption: 1,000 m³
6. Disposed Waste: 1,000 kg
2. Productive Impact: 0 units
Impacts are considered productive when the data center is fully equipped with running servers. If 100% of the available whitespace is utilized, both the operational and grey emissions are 100% productive.
#### Rack
The operational impacts of the rack arise from the energy the rack transmits — both thermal and electrical. Additionally, the rack inherits indirect impacts from the building: The operational and grey emissions of the building are equally distributed across all racks in the building. Thus, the rack gets visibility (but not responsibility) over the impacts its existence causes "downstream" in the value chain.
> **Important:** Rack operating emissions should not be measured if access to server metrics is available. This step can be skipped if there is access. Rack-level accounting is only necessary if the measuring entity does not have access to server metrics.
- **Rack Operational Impact:**
- **Total Energy Input** (kWh) — measured at the power meter: the total electrical energy supplied to the rack's PDUs
- **Total Energy Consumption** (kWh) — measured at the PDUs: the total energy supplied to the servers
- **Rack Design Capacity** (kW) — static value: the maximum power the rack can supply to servers
- **Total Thermal Energy Input** (kWh) — calculated via temperature and/or airflow sensors at the base of the rack
- **Total Thermal Output** (kWh) — calculated via sensors at the hottest point of the air output
- **Efficiency of Power-to-Thermal Conversion** (%) — efficiency with which air handlers, heat exchangers, and chillers convert 1 kWh of power into 1 kWh of thermal energy
- **Dependent Metrics of the Facility Entity** (see "Metrics to be provided"):
- Facility — Current Emission Factor (1 kg CO₂-eq/kWh)
- Facility — Total Rack Capacity in the Building (10)
- Facility — Total Water Consumption (1,000 m³)
- Facility — Total Disposed Waste (1,000 kg)
- Facility — Power Usage Effectiveness (PUE, 1.6)
A rack is considered productive if the rack design capacity and total energy consumption are nearly equal — meaning that the provided power is fully utilized.
To calculate all impacts (operational, grey emissions, and indirect) of the rack, we need some metrics from the data center — e.g., to attribute the total building's water consumption to a single rack. We divide the total values by the number of racks that the building can accommodate, thereby evenly distributing the operational impacts across the racks.
For the example calculation, we assume the building has a capacity for 10 racks and the rack is 50% utilized (rack design capacity / total energy consumption). The rack design capacity is 5 kW.
**Summary Formulas — Rack:**
$$E_{Rack} = P_{Design} \times U_{Rack} \times h$$
$$f_{Rack} = \frac{1}{N_{Racks}}$$
$$EI_{Indirect,Rack}^{Embodied} = EI_{Facility,Year} \times f_{Rack}$$
$$E_{Overhead,Rack} = P_{Design} \times U_{Rack} \times (PUE - 1) \times h$$
Where:
- $P_{Design}$ = Rack design capacity (kW)
- $U_{Rack}$ = Rack utilization (0–1)
- $h$ = Hours per year (8,760)
- $N_{Racks}$ = Total rack capacity of the building
- $PUE$ = Power Usage Effectiveness
The rack account balance at the end of the year:
1. **Non-productive Impact:**
1. Grey Emissions: 50 units (50% of the rack initial balance of 100)
2. Operational Impact: 0 units (the rack does not consume the unused 50% of the capacity; only grey emissions are "non-productive" for the unused part)
2. **Productive Impact:**
1. Grey Emissions: 50 units (this half of the rack is utilized)
2. Operational Impact:
1. Total Energy Consumption: 21,900 kWh (5 kW × 50% × 8,760 hours)
2. GHG Emissions: 21,900 kg CO₂-eq (1 kg CO₂-eq/kWh emission factor from the building)
3. **Indirect Impact (from the building):**
1. Productive (50%):
1. Grey Emissions: 1,000 units / 10 racks = 100 units per rack × 50% = 50 units
2. Operational Impact:
1. Freshwater Consumption: 1,000 m³ / 10 racks = 100 m³ × 50% = 50 m³
2. Disposed Waste: 1,000 kg / 10 racks = 100 kg × 50% = 50 kg
3. Energy Consumption (Facility Overhead): 2.5 kW × (PUE − 1) × 8,760 h = 2.5 × 0.6 × 8,760 = 13,140 kWh × 50% = 6,570 kWh
4. GHG Emissions (Facility Overhead): 6,570 kg CO₂-eq
2. Non-productive (50%):
1. Grey Emissions: 1,000 units / 10 racks = 100 units × 50% = 50 units
2. Operational Impact:
1. Freshwater Consumption: 100 m³ × 50% = 50 m³
2. Disposed Waste: 100 kg × 50% = 50 kg
3. Energy Consumption (Facility Overhead): 13,140 kWh × 50% = 6,570 kWh
4. GHG Emissions (Facility Overhead): 6,570 kg CO₂-eq
#### Server
The operational impact of the server is mainly derived from its energy consumption as the primary input. The server also requires cooling energy, which we account for using the PUE value of the data center. Additionally, we allocate the indirect impacts of the building — through the share of server power in the total available IT power of the building (see below). A server is considered productive when its actual power consumption is close to its rated power.
> The PUE value must be a near-real-time value to accurately capture changes in the building's external conditions and the effect of server cooling load reduction measures (e.g., by shutting down). In future revisions, we plan to instead calculate the server's thermal output to more accurately capture the load on the cooling system.
> Another area for improvement concerns the server's productivity assumption: Productivity should probably not be measured by rated power vs. actual consumption but by the amount of digital resources provided. A new metric for this is being developed in the [SIEC Project](https://ided.digital/projekte/siec-weiterentwicklung-server-idle-energy-coefficient).
- **Server Operational Impact:**
- **Rated Power** (kW) — static value: the maximum power consumption specified by the manufacturer (can also be estimated, e.g., via the Boavizta API)
- **Total Energy Consumption** (kWh) — measured via IPMI or approximated via RAPL or other available tools (list in appendix)
- **Dependent Metrics of the Facility Entity:**
- Facility — Current Emission Factor (1 kg CO₂-eq/kWh)
- Facility — Total IT Power Capacity in the Building (100 kW)
- Facility — Total Water Consumption (1,000 m³)
- Facility — Total Disposed Waste (1,000 kg)
- Facility — Power Usage Effectiveness (PUE, 1.6)
If a server runs for a year and its rated power is 1 kW, its maximum possible energy consumption would be 8,760 kWh. If it only consumed half of that, 4,380 kWh, we consider this half "non-productive," as the server was manufactured but not fully utilized.
For indirect impacts, we need some values from the data center. In our example, the rated power is 1 kW, and the total IT capacity of the building is 100 kW — meaning the server occupies 1% of the facility capacity, and we assign it one-hundredth of the building's operational impacts as indirect impact.
In our example, let's assume the server is 50% productive.
> It is important to note that we assume the data center provides cooling energy proportional to the IT capacity of the server. With 50 kW deployed server power, 50 kW × (PUE − 1) overhead energy is consumed, regardless of whether the servers are 10, 20, or 50% utilized. We record this as a non-productive impact, but always use the rated power for the calculation of non-productive overhead energy consumption. This should be a more dynamic calculation, and we aim for improvement in the next iteration.
**Summary Formulas — Server:**
$$E_{Server} = P_{Rated} \times U_{Server} \times h$$
$$GHG_{Server} = E_{Server} \times EF$$
$$f_{Server} = \frac{P_{Rated}}{P_{Facility,IT}}$$
$$EI_{Indirect,Server}^{Embodied} = EI_{Facility,Year} \times f_{Server}$$
$$E_{Overhead,Server} = E_{Server} \times (PUE - 1)$$
Where:
- $P_{Rated}$ = Rated power of the server (kW)
- $U_{Server}$ = Utilization of the server (0–1)
- $P_{Facility,IT}$ = Total IT power capacity of the building (kW)
- $EF$ = Emission factor (kg CO₂-eq/kWh)
The server account balance at the end of the year:
1. **Non-productive Impact:**
1. Grey Emissions: 150 units (50% of the server initial balance of 300)
2. Operational Impact: 0 units (we do not account for the server's unconsumed electricity)
2. **Productive Impact:**
1. Grey Emissions: 150 units (50% of the server's grey emissions are used productively)
2. Operational Impact:
1. Total Energy Consumption: 4,380 kWh (1 kW × 50% × 8,760 hours)
2. GHG Emissions: 4,380 kg CO₂-eq (1 kg CO₂-eq/kWh emission factor)
3. **Indirect Impact (from the building):**
1. Productive (50%):
1. Grey Emissions: 1,000 units × 1% = 10 units × 50% = 5 units (server occupies 1 kW of 100 kW IT capacity and uses 50% of this capacity productively)
2. Operational Impact:
1. Freshwater Consumption: 1,000 m³ × 1% = 10 m³ × 50% = 5 m³
2. Disposed Waste: 1,000 kg × 1% = 10 kg × 50% = 5 kg
3. Energy Consumption (Facility Overhead): 4,380 kWh × (PUE − 1) = 4,380 × 0.6 = 2,628 kWh
4. GHG Emissions (Facility Overhead): 2,628 kg CO₂-eq
2. Non-productive (50%):
1. Grey Emissions: 1,000 units × 1% = 10 units × 50% = 5 units
2. Operational Impact:
1. Freshwater Consumption: 1,000 m³ × 1% = 10 m³ × 50% = 5 m³
2. Disposed Waste: 1,000 kg × 1% = 10 kg × 50% = 5 kg
3. Energy Consumption (Facility Overhead): 4,380 kWh × (PUE − 1) = 4,380 × 0.6 = 2,628 kWh
4. GHG Emissions (Facility Overhead): 2,628 kg CO₂-eq
### Allocation of Operational and Grey Emissions of the Server to Digital Resources
The allocation of environmental impact to digital resources is an approach we first tried in our [SoftAWERE Project](https://www.umweltbundesamt.de/themen/digitalisierung/gruene-informationstechnik-green-it/software/energie-ressourceneffiziente-softwareprogrammierung). One might think of it like this:
A server provides digital resources for an application during operation.
Consider a real server for which an LCA is available — the Dell PowerEdge R740 ([official LCA here](https://sdia.unternehmens.cloud/s/4F3mGP2K6EDPTjK)). This server is configured to generate the following digital resources:
- 2 × Intel Xeon Gold 6132 CPUs
- 12 × 32 GB RAM = 384 GB total
- 1 × 400 GB SSD + 8 × 3.84 TB SSD = 31.12 TB SSD
- Dual-Port 10 GbE Network Card
- 2 × 1,100 W Power Supplies (Rated Power = 1,100 W)
With this information, we can say: The server uses 1,100 W to provide a maximum of 100% CPU utilization on two CPUs (28 cores), 384 GB of RAM, 31.12 TB of storage capacity, and 20 Gbit of network capacity. Simply put: The server generates digital resources with 1,100 W of input energy.
But how do we distribute the 1,100 W among each type of digital resource?
> If the rated power of the server is unavailable, it can be estimated over the TDP value of the CPU. For the Intel Xeon chips used in the Dell server, [Intel lists](https://www.intel.com/content/www/us/en/products/sku/123541/intel-xeon-gold-6132-processor-19-25m-cache-2-60-ghz/specifications.html) a TDP of 140 W. From that, Tom Kennes' method ([here](http://arxiv.org/abs/2306.10049)) can be used to derive an estimate of the total server power.
#### Allocation of Operational Impacts to Each Resource Type
In our [previous research](https://sdiav2.cdn.prismic.io/sdiav2/f27e9d42-9137-4bd8-af69-83aa8d5736e9_Creating+a+digital+environmental+footprint_A+Life+Cycle+Assessment+approach.pdf), we defined the following assumptions to distribute operational impacts to each digital resource type:
| Resource | Operational Allocation (%) |
|---|---|
| CPU | 65 % |
| Memory | 20 % |
| Storage | 10 % |
| Network | 5 % |
#### Allocation of Grey Emissions to Each Resource Type
For grey emissions, the Dell study provides a useful graphic for creating an allocation ratio. While CPUs clearly dominate operational impacts, in grey emissions the disks are the primary factor.
| Resource | Grey Emissions Allocation (%) | Comment |
|---|---|---|
| CPU | 7 % | Part of the "Mainboard" — Assumption: half memory, half CPU |
| Memory | 7 % | Part of the "Mainboard" — Assumption: half memory, half CPU |
| Storage | 80 % | — |
| Network | 2 % | Assumption |
| Other (Fans, Power Supply, Chassis) | 4 % | Distributed across all resources; separately stated in this display |
> The allocation ratios for grey emissions must be scaled according to the number of disks, CPUs, and memory modules in the server. The values in the table are specific to the Dell PowerEdge R740 configuration. In a later revision, we plan to add a calculation model.
#### Charged Accounts for the Dell PowerEdge R740
Using the data from the LCA, we can set up the environmental accounts for the server (using a 5-year useful life assumption). Let's assume the server is idling — all grey emissions are allocated to the non-productive sub-account. All data are cumulatively at year's end.
**Server — Grey Emissions Account:**
1. Productive: none
2. Non-productive:
1. Abiotic Resource Depletion [MJ]: 9.66E+04 / 5 years
2. Acidification Potential [kg SO₂-eq]: 3.01E+01 / 5 years
3. Eutrophication Potential [kg Phosphate-eq]: 2.43E+00 / 5 years
4. Ozone Depletion Potential [kg R11-eq]: 5.74E-08 / 5 years
5. Photochemical Ozone Creation Potential [kg Ethylene-eq]: 1.96E+00 / 5 years
6. Global Warming Potential 100 years including biogenic carbon [kg CO₂-eq]: 4,290 kg CO₂-eq / 5 years
**Server — Operational Impacts Account** (at 100% utilization, idling):
1. Productive Impact: none
2. Non-productive Impact:
1. Total Energy Consumption: 9,636 kWh (1.1 kW × 100% × 8,760 hours)
2. GHG Emissions: 9,636 kg CO₂-eq (1 kg CO₂-eq/kWh emission factor)
3. Indirect Impact (from the building):
1. Productive: none
2. Non-productive:
1. Grey Emissions: 1,000 units × 1.1% = 11 units (server occupies 1.1 kW of 100 kW IT capacity)
2. Operational Impact:
1. Freshwater Consumption: 1,000 m³ × 1.1% = 11 m³
2. Disposed Waste: 1,000 kg × 1.1% = 11 kg
3. Energy Consumption (Facility Overhead): 9,636 kWh × (PUE − 1) = 9,636 × 0.6 = 5,781.6 kWh
4. GHG Emissions (Facility Overhead): 5,781.6 kg CO₂-eq
#### Allocation of Impacts to Digital Resources
Using our environmental impact account logic and the allocation rules defined above, we can populate the accounts for each digital resource type. We assume the server is fully idling — all impacts go to the non-productive account. The server runs for one year.
%% TODO: Using 25% for the indirect embodied allocation across all four resource types should be explained here. Rationale: since the physical infrastructure of the data center (building, cooling, UPS) serves all resource types equally and cannot be differentiated by resource type, we distribute the indirect grey emissions evenly with each 25%. %%
**General Formula — Allocation to Digital Resource Type $r$:**
$$EI_{r}^{op} = EI_{Server}^{op} \times \alpha_r^{op}$$
$$EI_{r}^{emb} = EI_{Server}^{emb} \times \alpha_r^{emb}$$
$$EI_{r,Indirect}^{op} = EI_{Server,Indirect}^{op} \times \alpha_r^{op}$$
$$EI_{r,Indirect}^{emb} = EI_{Server,Indirect}^{emb} \times 25\%$$
Where:
- $\alpha_r^{op}$ = Operational allocation for resource type $r$ (CPU: 65%, Memory: 20%, Storage: 10%, Network: 5%)
- $\alpha_r^{emb}$ = Embodied allocation for resource type $r$ (CPU: 7%, Memory: 7%, Storage: 80%, Network: 2%, Miscellaneous: 4%)
- 25% = Equal distribution of the indirect grey emissions across four resource types
---
**CPU Utilization:**
1. Operational Impact:
1. Non-productive: (Server Operational Impact − Productive) × 65%
2. Productive: none
2. Grey Emissions:
1. Non-productive: (Server Grey Emissions − Productive) × 7%
2. Productive: none
3. Indirect Impact:
1. Non-productive:
1. (Server Indirect Operational Impact − Productive) × 65%
2. (Server Indirect Grey Emissions − Productive) × 25%
2. Productive: none
**Memory Utilization:**
1. Operational Impact:
1. Non-productive: (Server Operational Impact − Productive) × 20%
2. Productive: none
2. Grey Emissions:
1. Non-productive: (Server Grey Emissions − Productive) × 7%
2. Productive: none
3. Indirect Impact:
1. Non-productive:
1. (Server Indirect Operational Impact − Productive) × 20%
2. (Server Indirect Grey Emissions − Productive) × 25%
2. Productive: none
**Storage Utilization:**
1. Operational Impact:
1. Non-productive: (Server Operational Impact − Productive) × 10%
2. Productive: none
2. Grey Emissions:
1. Non-productive: (Server Grey Emissions − Productive) × 80%
2. Productive: none
3. Indirect Impact:
1. Non-productive:
1. (Server Indirect Operational Impact − Productive) × 10%
2. (Server Indirect Grey Emissions − Productive) × 25%
2. Productive: none
**Network Utilization:**
1. Operational Impact:
1. Non-productive: (Server Operational Impact − Productive) × 5%
2. Productive: none
2. Grey Emissions:
1. Non-productive: (Server Grey Emissions − Productive) × 2%
2. Productive: none
3. Indirect Impact:
1. Non-productive:
1. (Server Indirect Operational Impact − Productive) × 5%
2. (Server Indirect Grey Emissions − Productive) × 25%
2. Productive: none
---
Now imagine that half of the CPU is fully utilized, shifting half of the non-productive CPU account to the productive one. If an application runs on the bare-metal server and occupies half of the digital resources, the application can be fully credited with the impact — broken down into productive and non-productive, and even by the type of digital resource the application uses.
On a single bare-metal server, this is not particularly useful, as the server's impact accounts can directly be used for impact reporting. But we use the allocation to digital resources in a later step.
### Bringing Everything Together — for a Software Application
We have loaded all physical impact accounts of all machines and buildings in the value chain beneath the application. So far logical. Now the difficult part comes: connecting to the actual application.
Conceptually, we can say: If an application is running and using the server or/and its digital resources, it is productive. Whether the application is doing something meaningful is not the subject of this evaluation.
What is **not** productive: An application that makes a reservation — e.g., books a virtual machine with 16 GB of RAM and 16 cores — from which it uses at maximum 30%. These 70% "reserved but not used" are non-productive, as they could be used by another application.
> We ignore the fact that hypervisors and orchestrators perform a lot of "magic" to overbook servers — allowing applications to reserve 110–200% of physically available digital resources, knowing they will not all be used simultaneously. In principle, this magic wouldn't be needed if applications constantly adjusted their reservations based on actual usage ("Right Sizing").
>
> With our approach, we capture the key fact: reserving more resources than needed is not productive and creates waste that should be managed and avoided.
With this definition of productive and non-productive in mind, we now look at the different approaches to allocating the environmental impact accounts to the application. It's all additive and cumulative — e.g., if an application fully utilizes two physical servers for a year, the accounts of both servers are added together and assigned to the application.
The goal: assign responsibility for environmental impact to the correct entity. If an application makes unnecessary reservations, it should be the responsibility of the application manager to fix it. Likewise, we assign the application indirect impacts because the application manager has the choice of which data center, IT, or cloud infrastructure provider they use. It should be their responsibility to choose a provider with low impact — creating an incentive for these providers to improve.
#### Approach 0: Bare-Metal Allocation
The simple case. If an application uses one or more bare-metal servers, the entire digital resources of the server is the reservation (non-productive), and the actual use of digital resources is the productive use.
This can be calculated in two ways:
1. **Less precise:** Use the server's impact account and initially assign everything as non-productive. Then calculate the percentage of digital resources actually used — e.g., if a server offers a maximum of 32 cores, 128 GB of RAM, 100 million I/O ops/10 Gbit bandwidth, and 100 million network ops/100 Gbit bandwidth, and the application uses a total of 30% of this capacity, 30% of the server impact account can be recorded as "productive" for the application.
2. **More precise:** Break down the impact accounts for each type of digital resource and directly calculate over the actual usage of each resource type by the application — e.g., disk I/O may have more grey emissions than operational impacts, while CPU is operation-impact heavy with fewer grey emissions.
For both approaches, the digital resource usage of the server must be monitored using an IT infrastructure monitoring tool.
If an application is distributed across multiple servers, the accounts should be calculated per server and then added to the application’s total impact account. Averages should be avoided here, as the servers may have different utilization profiles (e.g., a database server and an application server running together).
**Summary Formula — Bare-Metal Allocation:**
$$EI_{App}^{prod} = \sum_{s=1}^{S} EI_{Server_s} \times U_{App,s}$$
$$EI_{App}^{non\text{-}prod} = \sum_{s=1}^{S} EI_{Server_s} \times (1 - U_{App,s})$$
Where:
- $S$ = Number of servers the application uses
- $U_{App,s}$ = Utilization of the application on server $s$ (0–1)
#### Hypervisor and Orchestrator
In the context of our approach, hypervisors and orchestrators can be understood as reservation managers. One of their tasks is to close the gap between reservations and usage and maximize the utilization of the underlying hardware. They also provide an isolation layer that generally makes measurements more complex — but there are many tools to work around this (see appendix).
The good news: these systems have full visibility into all reservations per virtual machine, container, or pod ("bundle of digital resources") running on a server or within a server cluster. They also have accurate data on the digital resources each bundle utilizes at any given time. And they usually know all the specifications of the host system (e.g., total CPU, memory, disk, and I/O capacities).
In Approaches 1 and 2 — if accessible and possible — data from the hypervisor or orchestrator should be preferred.
#### Approach 1: Usage-Based (Digital-Resource-Monitoring)
In this approach, non-productive impacts are ignored and the focus is on converting the consumption of digital resources by the application into environmental impact. For this, an IT monitoring system is used to monitor the application’s use of digital resources and combine this usage with the impact account for each digital resource type (as described under "Allocation of Operational and Grey Emissions of the Server to Digital Resources").
This requires information from the server about the impact account per generated digital resource type.
As a mental model: a transfer. If the application uses 10% of the CPU of the underlying server system for one day, the server must "transfer" the impact of the CPU usage for that one day to the application's (productive) account.
If the application is distributed across multiple systems, e.g.:
- 10 Kubernetes Pods
- 2 Bare-Metal Servers
- 14 Virtual Machines
... the transfer must be done individually for each of these systems and added to the application's impact account. One cannot measure the usage of digital resources on each system and first form averages or sums — the impact must be calculated for each bundle or physical server based on the usage that actually occurred there.
#### Approach 2: Reservation-Based (Digital-Resource-Allocation)
If no IT monitoring system is available to measure resource consumption, but the following information is available from the IT infrastructure team:
The application uses:
- 3 Virtual Machines with 16 GB of RAM, 16 cores, and 100 GB of storage each
- 2 Bare-Metal Servers with 128 GB of RAM, 96 cores, and 1.92 TB of storage each
- 10 Pods with 512 MB of RAM request each
Now, the impact accounts of the servers providing the bundles or bare-metal capacity for each digital resource type can be used to calculate the non-productive impact account for the application. To do this, multiply the reservations with the account of the respective resource type — e.g., 128 GB of RAM × the operational and embodied impact account for the resource type "Memory" of this server.
For virtual machines (VM), first calculate the share that the VM resources make in the total resources of the underlying server — e.g., the server has 128 GB of RAM, and 16 GB correspond to 12.5%. So, 12.5% of the memory impact account can be assigned to the application (as non-productive).
**Summary Formula — Reservation-Based Allocation for a VM:**
$$EI_{App,VM}^{non\text{-}prod} = \sum_{r} \left( \frac{Res_{VM,r}}{Res_{Server,r}} \times EI_{Server,r} \right)$$
Where:
- $r$ = Resource type (CPU, Memory, Storage, Network)
- $Res_{VM,r}$ = Resources reserved by the VM for type $r$
- $Res_{Server,r}$ = Total available resources of the server for type $r$
#### Approach 3: Combined Use of Reservation and Consumption for Productive and Non-productive Impact
The actual strength unfolds in combining both approaches. This closes the gap between productive and non-productive environmental impact. Even if a reduction is not possible, closing this gap at least reduces the amount of wasted energy and unused manufactured equipment.
For the portfolio of servers, virtual machines, containers, and/or pods that the application is responsible for, first calculate the non-productive account as described in Approach 2. This is the baseline: 100% idle, 100% non-productive. Then add the measurement of digital resource usage and can now continuously move impact between the productive and non-productive account ("transfer"), depending on actual usage.
The accounts are cumulative — making it an "optimization game" to avoid further filling the non-productive account by ensuring utilization.
**Summary Formula — Combined Approach:**
$$EI_{App}^{prod}(t) = \sum_{s=1}^{S} \sum_{r} EI_{Server_s,r} \times U_{App,s,r}(t)$$
$$EI_{App}^{non\text{-}prod}(t) = \sum_{s=1}^{S} \sum_{r} EI_{Server_s,r} \times \left(\frac{Res_{App,s,r}}{Res_{Server_s,r}} - U_{App,s,r}(t)\right)$$
Where:
- $U_{App,s,r}(t)$ = Actual usage of resource type $r$ by application on server $s$ at time $t$
- $\frac{Res_{App,s,r}}{Res_{Server_s,r}}$ = Application reservation share
#### Summary
For the allocation of infrastructure environmental impact to the application, we propose first creating an impact account for the reservation of resources defined by the bundle (virtual machine, pod, or other). This account is the non-productive environmental impact and is defined by the share of the underlying server's impact in relation to the amount of digital resources the reservation occupies on the server.
From there, environmental impact (cumulatively!) is continuously transferred to the productive account as the reserved digital resources are actually utilized. This provides an accurate measurement of the "resource efficiency" of the application and the application’s total environmental impact over its lifecycle.
If an application consists of many bundles (e.g., a thousand virtual machines), we recommend maintaining one impact account per bundle and aggregating the accounts at the application level. This also allows development and staging environments to be included in the calculation. If bundles are added or removed, they are simply added to the cumulative application account.
Since environmental impact is irreversible — resource consumption, CO₂ emissions, or consumed energy cannot be "given back" — it is crucial to maintain all accounts cumulatively. Unfortunately, reducing an application's infrastructure from a thousand to one hundred virtual machines cannot change the past. It only affects the rate of change: the impact account accumulates more slowly.
### Outlook
With this methodology, we introduce some new key ideas:
1. **Cumulative Accounts** for environmental impacts
2. **Allocation** of environmental impacts from the entire value chain of an application onto the application itself
3. **A Comprehensive List** of environmental impact indicators
### Appendix
#### List of Environmental Impact Indicators for Software
- Total Energy Consumption (kWh)
- Total GHG Emissions (CO₂-eq)
- Grey CO₂-eq from manufacturing and transportation of equipment and buildings
- Operational CO₂-eq from energy consumption
- Resource Consumption — Abiotic Depletion Potential (ADP)
- The abiotic depletion potential connects an organization’s resource consumption to the rarity of fossil resources. It uses a dimensional measure comparing the resource extraction rate to the total worldwide reserves.
- Waste from Electrical and Electronic Equipment (WEEE, tons)
#### Metrics to be Provided by Each Entity
**Data Center:**
- Emission Factor of Provided IT Energy:
- On-site non-renewable energy generation: kWh and type (e.g., diesel)
- The emission factor varies depending on the type
- For the difference between total energy consumption and renewable energy generation (kWh), the grid emission factor (e.g., from the Electricity Map API) should be used
- Facility — Current Emission Factor (kg CO₂-eq/kWh)
- Facility — Total Rack Capacity in the Building
- Facility — Total Water Consumption (m³)
- Facility — Total Disposed Waste (kg)
- Facility — Power Usage Effectiveness (PUE)
#### Conversion Formulas
> In a future update, we will include approaches to converting measurements into environmental impacts, e.g., for energy, as well as our research findings for useful default values.
#### List of Assumptions for Cloud Region Data Centers
> This list will be added in a future update — research for a current data basis is still ongoing.
#### List of Tools for Measuring Server Energy Consumption
> This list will be added in a future update — research for a current overview is still ongoing.
#### List of Waste Streams to Consider for the Data Center
Based on the [EU LCA Indicator Framework](https://eplca.jrc.ec