Wie lässt sich die Umweltwirkung einer Software-Applikation oder eines KI-Modells entlang der gesamten Wertschöpfungskette berechnen? Unsere Methodik führt kumulative Umweltwirkungskonten ein, die graue Emissionen, Betriebsemissionen und indirekte Wirkungen auf Applikationsebene zusammenführen.
## Excerpt
Wie lässt sich die Umweltwirkung einer Software-Applikation oder eines KI-Modells entlang der gesamten Wertschöpfungskette berechnen — vom Rechenzentrumsgebäude über Server-Hardware bis zur einzelnen Workload? Unsere Methodik führt kumulative Umweltwirkungskonten ein, die graue Emissionen, Betriebsemissionen und indirekte Wirkungen auf Applikationsebene zusammenführen und zwischen produktiver und nicht-produktiver Nutzung unterscheiden.
## Content
*Dieser Methodik-Artikel ist Teil unserer Arbeit im [NADIKI-Projekt](https://ided.digital/projekte/nadiki-nachhaltige-und-messbare-ki-systeme).*
### Einleitung
In diesem Artikel zeigen wir ein Ende-zu-Ende-Modell für die Bilanzierung der Umweltwirkung einer Software-Applikation (im Folgenden „Applikation"). Zur Veranschaulichung verwenden wir das Beispiel eines KI-Modells und -Dienstes. Die Grundidee: Eine Applikation führt ein Umweltwirkungskonto — ähnlich einem Bankkonto — auf dem die Umweltwirkungen über den gesamten Lebenszyklus kumuliert werden. Man kann sich diese Umweltwirkungen als eine Art Umweltkosten vorstellen: Jede Entität in der Wertschöpfungskette — vom Rechenzentrumsgebäude über den Server bis zur einzelnen Workload — verursacht Wirkungen, die auf ihrem Konto verbucht und nie wieder abgeschrieben werden können.
Für die Lesbarkeit verwenden wir ein reine präziser Begriffe, die wir in der Übersicht genauer definieren und die zugrundeliegenden Konzepte erklären:
- **Digitale Ressourcen:** Die Kapazität Daten zu verarbeiten (Rechenleistung), zu speichern (Speicher) und zu übertragen (Netzwerkverkehr), die ein Computer-System aus Energie erzeugt.
- **Digitaler Ressourcentyp:** Wenn wir von Typen digitaler Ressourcen sprechen, meinen wir: Rechenkapazität (Compute), Speicher (Storage) und Netzwerkkapazität (Network).
- **Entität:** Die verschiedenen Entitäten in der Wertschöpfungskette der Infrastruktur, die zum Betrieb einer Software-Applikation benötigt wird: Rechenzentrumsgebäude (Facility), Rack (beherbergt Server und Netzwerkausrüstung), Server (IT-Ausrüstung, die Rechen-, Speicher- oder Netzwerkkapazität erzeugt), Client-Gerät (z. B. Laptop oder Smartphone). Netzwerkausrüstung wird vorerst ausgeklammert.
- **Wirkung:** Hiermit ist die entstehende Umweltwirkung gemeint (z.B. THG-Emissionen, Ressourcenextraktion, Verschmutzung, Elektroschrott, etc.).
- **Umweltkonto (Konto):** Ähnlich einem Bankkonto in dem die Umweltwirkungen für eine Entität kumuliert werden.
- Die Umweltwirkungsindikatoren sind für jede Entität identisch und werden am Ende des Dokuments aufgelistet.
- Zur Vereinfachung sprechen wir von operativer Wirkung (Operational), grauen Emissionen (Embodied) und indirekten Wirkungen (Indirect) — siehe Definitionen unten.
- Jede Entität hat zwei Unterkonten: **Produktive Wirkungen** und **Nicht-produktive Wirkungen**. Ziel jeder Entität ist es, die nicht-produktiven Wirkungen zu minimieren und insgesamt den Kontostand nicht ansteigen zu lassen (oder die Kumulation zu verlangsamen).
- Alle Konten in diesem Artikel sind kumulative Jahreskonten. Das bedeutet: Die Grauen Emissionen werden jeder Entität gemäß ihrer Nutzungsdauer zu Jahresbeginn als Anfangsbestand zugewiesen. Die operativen Umweltwirkungen werden über das Jahr kumulativ hinzuaddiert. Am Jahresende (oder einem anderen Zeitraum) kann der Gesamtkontostand abgerufen werden. Die zeitliche Auflösung kann technisch von einer Stunde bis zu zehn Jahren reichen — für diesen Artikel bleiben wir bei der Jahresauflösung, da dies die Beispiele verständlicher macht.
- **Produktive Wirkung:** Entsteht, wenn die Entität nützliche Arbeit leistet — z. B. wenn ein Server Energie für die Berechnung einer Applikation verwendet.
- **Nicht-produktive Wirkung:** Entsteht, wenn eine Entität betriebsbereit ist, aber keine nützliche Arbeit leistet — z. B. ein Server im Leerlauf, der dennoch Energie verbraucht, oder ein halb leeres Rechenzentrum, bei dem die Hälfte der Grauen Emissionen als nicht-produktiv zugeordnet wird.
- **Nützliche Arbeit:** Wir betrachten nützliche Arbeit am Ende der Wertschöpfungskette. Ein Server stellt digitale Ressourcen bereit. Diese sind standardmäßig nicht-produktiv. Der Server verbraucht im laufenden Betrieb Energie. Erst wenn eine Applikation diese bereitgestellten Ressourcen nutzt, werden sie produktiv. Ziel der Server-Provisionierung, Virtualisierung oder Orchestrierung ist es, den Anteil der produktiven Ressourcennutzung zu maximieren.
- **Betriebswirkungen (Operational Impacts):** Umweltwirkungen, die durch den Betrieb der Entität entstehen — beim Rechenzentrum z. B. der Energieverbrauch und die damit verbundenen THG-Emissionen für den Betrieb der Kühlsysteme; beim Server die Energie für den laufenden Betrieb.
- **Graue Emissionen (Embodied Impacts):** Statische Wirkungen, die durch die Herstellung der jeweiligen Entität verursacht werden. Die Grauen Emissionen bilden den Anfangsbestand.
- **Indirekte Wirkungen (Indirect Impacts):** Wirkungen, die durch eine übergeordnete Entität verursacht werden — z. B. wenn ein Rack betrieben wird, erfordert dies ein Rechenzentrumsgebäude. Kann das Gebäude 100 Racks beherbergen, hat jedes Rack eine indirekte Wirkung von einem Hundertstel der direkten Wirkungen des Gebäudes. So kann jede Entität eigenständig bewertet werden, während die indirekten Wirkungen dennoch sichtbar bleiben.
- **Nutzungsdauer:** Jede Entität hat eine Nutzungsdauer, für die wir sinnvolle Standardwerte festlegen. Die Nutzungsdauer wird in Jahren angegeben.
Die Komplexität liegt in der folgenden Berechnungskette:
- Berechnung des Anfangsbestands der Grauen Emissionen für jede Entität
- Genaue Erfassung der Betriebswirkungen für jede Entität
- Anteilige Zuordnung der Wirkungen auf das Konto der Applikation, abhängig von der tatsächlichen Nutzung aller Entitäten durch die Applikation
- Bei der Zuordnung: Berücksichtigung sowohl der Virtualisierung als auch der Verteilung von Applikationen über mehrere Rechenzentren und Server (z. B. mit vielen virtuellen Maschinen oder Kubernetes-Clustern/Pods)
Wir beginnen mit der Berechnung der initialen Kontostände der Umweltwirkungskonten der verschiedenen Entitäten. Dieses Berechnungsmodell erlaubt es, jede Entität eigenständig zu bilanzieren und nur die direkt von ihr verantworteten Wirkungen als direkte Wirkungen zu messen. Die Kontostände aller Entitäten werden letztlich addiert, wenn sie einer Applikation als direkte und indirekte Wirkungen zugeordnet werden. Es ist möglich, dieses Modell auf ein Rechenzentrumsgebäude, ein Rack oder einen Server einzeln anzuwenden. Dies ist wichtig, da viele Akteure der digitalen Infrastruktur entlang der Wertschöpfungskette „aufgeteilt" sind — z. B. betreibt ein Co-Location-Anbieter nur das Gebäude, ein IT-Infrastruktur-Anbieter mietet ein Rack für eigene Server, und ein Kunde nutzt wiederum die Server.
Das Modell beschreibt auch die Abhängigkeiten zwischen den Entitäten — z. B. muss das Rechenzentrum den Emissionsfaktor des Stromnetzes oder der Vor-Ort-Stromerzeugung bereitstellen, um die THG-Emissionen für den Energieverbrauch eines Racks zu berechnen.
### Berechnung des Anfangsbestands jedes Umweltwirkungskontos pro Entität
Wenn wir Elektronen als unseren „roten Faden" durch die Infrastruktur bis zur Applikation verwenden, fließen diese durch folgende Entitäten:
- **Das Rechenzentrumsgebäude (Facility)**
- Elektronen fließen vom Stromnetz oder von Generatoren zur Schaltanlage, zur USV-Batterie und von dort zu den Stromverteilungssystemen (PDUs) der Racks
- Ein Teil der Elektronen wird von Kühlsystemen in thermische Energie umgewandelt (Overhead)
- Ein Teil wird für Hilfssysteme wie Beleuchtung oder Sicherheitssysteme abgezweigt (Overhead)
- **Das Rack**
- Elektronen kommen von den USV-Systemen am Rack an und werden an die Stromverteiler (PDUs) übergeben
- **Der Server**
- Server sind an die PDUs angeschlossen (in der Regel mit zwei oder mehr Steckern für Redundanz)
- Der Server empfängt auch thermische Energie (aus Elektronen gewonnen) vom Gebäude durch kalte Luft, die durch den Boden des Racks gedrückt wird
- **Digitale Ressource**
- Der Server wandelt die Elektronen in Rechenkapazität um, indem er CPU oder GPU sowie Speicherchips (Lesen/Schreiben und Persistenz), Festplatten und eine Netzwerkkarte mit Strom versorgt
- An diesem Punkt werden aus Elektronen Rechen-, Speicher- und Netzwerkkapazität (sowie thermische Energie — Abwärme als Energieverlust), die von einer digitalen Applikation genutzt werden können. Die Applikation kennt keine Elektronen — sie kennt digitale Ressourcen, die sie benötigt und verbraucht.
#### Rechenzentrumsgebäude (Facility)
Als ersten Schritt bestimmen wir den Anfangsbestand des Kontos für das Rechenzentrumsgebäude. Das bedeutet, die Grauen Emissionen des Gebäudes zu ermitteln.
Dafür müssen folgende Komponenten des Gebäudes berücksichtigt werden. Falls diese Daten nicht vom Betreiber erhältlich sind, haben wir eine [Standardannahme](https://notion.leitmotiv.work/A-Default-Data-Center-Life-Cycle-Assessment-LCA-1a8efc5c58538020a7c7fea0a8833055?pvs=4) auf Basis öffentlicher Informationen zusammengestellt.
> Wenn ein Rechenzentrum eine [BREEAM](https://breeam.com/)-Zertifizierung für das Gebäude hat, verfügt es auch über eine Lebenszyklusanalyse (LCA) für das Gebäude, die angefordert werden sollte.
- **Nutzungsdauer: 15 Jahre** (Standardannahme)
- Wenn sich ein Rechenzentrumsbetreiber verpflichtet, das Gebäude 15, 20 oder 25 Jahre zu nutzen, reduziert dies den jährlichen Anfangsbestand und damit die Wirkung pro Jahr (und folglich auch für die Applikation, wie wir später sehen werden). Dies ist gewünscht, da die Verlängerung der Nutzungsdauer aller Entitäten ein primäres Nachhaltigkeitsziel ist.
- **USV-System**
- Für die Batterien oder andere USV-Komponenten wird eine Lebenszyklusanalyse (LCA) oder besser eine Umweltproduktdeklaration (EPD) benötigt. [Beispiel hier.](https://register.pep-ecopassport.org/pep/consult/mbesqrsCBZbWbKJq6-kJ3ivRIBRLa6imH2a4YXgk7xw/mbesqrsCBZbWbKJq6-kJ3lQmBuGvAHsLUfQU9idjOpk)
- **Netzersatzgeneratoren (Diesel, Gas)**
- Bei Ausfall der primären Stromversorgung (meist Stromnetz) verfügen Rechenzentren über Netzersatzanlagen, die einspringen, während die USV-Batterien die Übergangszeit überbrücken.
- Für jeden Generator wird ebenfalls eine LCA oder EPD benötigt. [Beispiel hier.](https://register.pep-ecopassport.org/pep/consult/mbesqrsCBZbWbKJq6-kJ3rxTtdZ8zl09EaEprH5JLgA/mbesqrsCBZbWbKJq6-kJ3lQmBuGvAHsLUfQU9idjOpk)
- **Vor-Ort-Erzeugungsanlagen**
- Das Gebäude kann über eigene Stromerzeugungskapazitäten verfügen, z. B. Solaranlagen oder Wasserstoff-Brennstoffzellen.
- Auch für diese Komponenten wird eine LCA oder EPD benötigt.
- **Gebäude (Hülle, tragende Infrastruktur, Böden, …)**
- Ein Rechenzentrumsgebäude besteht aus Zement, Beton, Stahl und anderen Baumaterialien. Bei einer [BREEAM](https://breeam.com/)-Zertifizierung ist eine Gesamt-LCA des Gebäudes vorgeschrieben.
- Die LCA-Informationen zu den Grauen Emissionen sollten dem Anfangsbestand des Gebäudekontos hinzugefügt werden.
- **Kühlsystem (im Whitespace/Luftbehandler, Transport, z. B. Pumpen, Wärmetauscher, Kältemaschinen, Kühlmittel)**
- Für jede Komponente des Kühlsystems sollte eine LCA oder EPD beschafft werden, [wie in diesem Beispiel](https://register.pep-ecopassport.org/pep/consult/mbesqrsCBZbWbKJq6-kJ3rYjjAkQ2T_GboavpgfEoiQ/mbesqrsCBZbWbKJq6-kJ3lQmBuGvAHsLUfQU9idjOpk).
- Zusätzlich sollten Gesamtmenge und Art der verwendeten Kühlmittel ermittelt werden, um die Grauen Emissionen der Kühlmittel zu berechnen. [Unsere Tabelle hier](https://notion.leitmotiv.work/List-of-common-cooling-fluids-GWPs-used-in-data-centers-1a8efc5c585380fe809feaf57d9dac83?pvs=4) hilft bei der Bewertung.
- **Luftaufbereitungssysteme (Be-/Entfeuchtung)**
- Die meisten Rechenzentren behandeln die Luft im Whitespace (dem Bereich, der die IT-Ausrüstung beherbergt), um hohe oder niedrige Luftfeuchtigkeit zu vermeiden, die die Geräte beschädigen könnte.
- Auch für diese Systeme sollte eine LCA oder EPD vorliegen.
- **Brandlöschsysteme**
- Die meisten Rechenzentren verfügen über gas- oder wasserbasierte Löschsysteme. Auch hierfür ist eine LCA oder EPD zur Bestimmung der Grauen Emissionen erforderlich.
- Es kann nötig sein, die Grauen Emissionen der Löschgase/Chemikalien separat zu bewerten, basierend auf dem in der Anlage eingesetzten Volumen.
Wenn die Daten aller Komponenten gesammelt sind, können sie aufsummiert werden. Das ergibt die **Gesamten Grauen Emissionen des Gebäudes**. Diese werden durch die Nutzungsdauer geteilt, um den jährlichen Anfangsbestand zu erhalten.
**Zusammenfassende Formel — Facility-Anfangsbestand:**
$$EI_{Facility,Jahr} = \frac{EI_{Facility,gesamt}}{T_{Facility}}$$
Wobei:
- $EI_{Facility,gesamt}$ = Summe aller Grauen Emissionen des Gebäudes (aus LCA/EPD aller Komponenten)
- $T_{Facility}$ = Nutzungsdauer des Gebäudes in Jahren
Wenn das Gebäude leer ist (keine IT-Ausrüstung), könnte der Anfangsbestand im ersten Jahr so aussehen:
1. Facility Gesamte Graue Emissionen über Nutzungsdauer: 15.000 Einheiten
2. Facility Umweltwirkungskonto (Jahr 1): 1.000 Einheiten (15.000 / 15 Jahre)
1. Nicht-produktive Wirkung: 1.000 Einheiten
2. Produktive Wirkung: 0 Einheiten
Die Betriebswirkungen werden im weiteren Verlauf hinzugefügt. Der Anfangsbestand existiert unabhängig von der Nutzung des Gebäudes.
#### Rack
Für die Racks durchlaufen wir denselben Prozess wie beim Gebäude. Für jedes Rack müssen folgende Informationen erhoben werden:
- **Nutzungsdauer: 15 Jahre** (Standardannahme)
- Auch hier reduziert eine verlängerte erwartete/zugesicherte Nutzungsdauer den jährlichen Anfangsbestand.
- **PDUs (Stromverteiler)**
- Für jede PDU sollte eine LCA oder EPD vorliegen.
- **USV-Batterie**
- Manche Racks verfügen über eigene, dedizierte USV-Batterien.
- Falls vorhanden, ist eine LCA oder EPD der Batterie erforderlich.
- **Rack-Gestell**
- Racks sind in der Regel Stahlgestelle, für die eine LCA oder EPD beschafft werden sollte.
**Zusammenfassende Formel — Rack-Anfangsbestand:**
$$EI_{Rack,Jahr} = \frac{EI_{Rack,gesamt}}{T_{Rack}}$$
Wenn das Rack leer ist, könnte der Kontostand so aussehen:
1. Rack Gesamte Graue Emissionen über Nutzungsdauer: 1.500 Einheiten
2. Rack Umweltwirkungskonto (Jahr 1): 100 Einheiten (1.500 / 15 Jahre)
1. Nicht-produktive Wirkung: 100 Einheiten
2. Produktive Wirkung: 0 Einheiten
#### Server
Die Server sollten grundsätzlich am einfachsten zu bewerten sein, da sie ein einzelnes Produkt eines einzelnen Herstellers sind. Leider bieten nicht alle Hersteller LCAs oder EPDs für jedes Produkt. Glücklicherweise gibt es zahlreiche APIs, insbesondere die [Boavizta API](https://doc.api.boavizta.org/getting_started/single_server/#retrieve-the-impacts-of-a-custom-server), mit denen eine Schätzung der Grauen Emissionen für jedes Server-Modell generiert werden kann.
Für den Server können wir den Anfangsbestand wie folgt bestimmen:
- **Nutzungsdauer: 5 Jahre**
- Wie bei Rack und Gebäude reduziert eine Verlängerung der Nutzungsdauer den jährlichen Anfangsbestand.
- **Server-Hardware**
- Idealerweise sollte eine LCA oder EPD für das spezifische Server-Modell beschafft werden. Beispiel: [Dell PowerEdge R740](https://sdia.unternehmens.cloud/s/4F3mGP2K6EDPTjK)
- Falls nicht verfügbar, kann mit den Spezifikationen des Servers (CPU-Modell, Arbeitsspeicher, Speicher usw.) über die [Boavizta API](https://doc.api.boavizta.org/getting_started/single_server/#retrieve-the-impacts-of-a-custom-server) oder andere Datenbanken eine Schätzung erzeugt werden.
**Zusammenfassende Formel — Server-Anfangsbestand:**
$$EI_{Server,Jahr} = \frac{EI_{Server,gesamt}}{T_{Server}}$$
Für diese Berechnung nehmen wir an, dass der Server ausgeschaltet ist:
1. Server Gesamte Graue Emissionen über Nutzungsdauer: 1.500 Einheiten
2. Server Umweltwirkungskonto (Jahr 1): 300 Einheiten (1.500 / 5 Jahre)
1. Nicht-produktive Wirkung: 300 Einheiten
2. Produktive Wirkung: 0 Einheiten
#### Digitale Ressourcen
Da digitale Ressourcen physisch nicht existieren — sie entstehen erst, wenn der Server eingeschaltet wird — und ihre Grauen Emissionen gleich denen des Servers sind, setzen wir keinen Anfangsbestand für digitale Ressourcen an.
#### Zusammenfassung der Grauen Emissionen
Unsere Umweltwirkungskonten am 1. Januar, mit einem einzelnen Rack in einem Rechenzentrumsgebäude und einem ausgeschalteten Server, sehen so aus:
1. **Facility Umweltwirkungskonto (Jahr 1):** 1.000 Einheiten (15.000 / 15 Jahre)
1. Nicht-produktive Wirkung: 1.000 Einheiten
2. Produktive Wirkung: 0 Einheiten
2. **Rack Umweltwirkungskonto (Jahr 1):** 100 Einheiten (1.500 / 15 Jahre)
1. Nicht-produktive Wirkung: 100 Einheiten
2. Produktive Wirkung: 0 Einheiten
3. **Server Umweltwirkungskonto (Jahr 1):** 300 Einheiten (1.500 / 5 Jahre)
1. Nicht-produktive Wirkung: 300 Einheiten
2. Produktive Wirkung: 0 Einheiten
**Allgemeine Formel für den Anfangsbestand jeder Entität:**
$$EI_{Entität,Jahr} = \frac{EI_{Entität,gesamt}}{T_{Entität}}$$
### Betriebswirkungen zu den Umweltwirkungskonten hinzufügen
Das war der einfache Teil. Nun fügen wir die Betriebswirkungen jeder Entität zum Kontostand hinzu. Diese sind die Messwerte, die über das Jahr variieren und tatsächlich in jeder Entität gemessen werden müssen — mindestens in stündlicher Auflösung.
Die Herausforderung besteht darin, dass manche Betriebswirkungen den Kontostand positiv oder negativ beeinflussen können. Dies muss für jede Entität mit einer spezifischen Berechnungslogik ermittelt werden. Messen allein reicht nicht — eine Umrechnung und erste Zuordnung zum richtigen Wirkungsindikator ist erforderlich. In unserer Metrik-Liste für jede Entität erklären wir diese Umrechnungen.
#### Rechenzentrumsgebäude (Facility)
Für das Gebäude ist die Berechnung relativ geradlinig und fokussiert auf Energie, Wasser und Abfall. Die Hauptherausforderung liegt in der Differenzierung der verschiedenen Energiequellen — lokale Erzeugung, nahegelegene erneuerbare Erzeugung sowie der Brennstoff lokaler Erzeugung (z. B. wenn die Dieselgeneratoren laufen). Dies ist relevant für die Berechnung des THG-Wirkungsindikators aus dem Energieverbrauch.
- **Betriebswirkung des Rechenzentrums:**
- **Gesamter Nicht-IT-Energieverbrauch** (kWh, gemessen am Ausgang des USV-Systems)
- Erfasst den Stromverbrauch aller Overhead-Aktivitäten: Kühlung, Beleuchtung, Verluste in elektrischen und mechanischen Anlagen
- **Gesamte erneuerbare Energieerzeugung** (kWh), aufgeschlüsselt nach:
- Vor-Ort-Erzeugung erneuerbarer Energie: kWh und Typ (z. B. Solaranlagen)
- Physische Stromlieferverträge (direkte Abnahme der Erzeugung) mit erneuerbaren Quellen im Umkreis von 50 km: kWh und Typ (z. B. Wind)
- Deckt die Gesamtproduktion 100 % des Nicht-IT-Energieverbrauchs, können die THG-Emissionen als 0 betrachtet werden
- **Gesamte nicht-erneuerbare Energieerzeugung** (kWh), aufgeschlüsselt nach:
- Energie aus Vor-Ort-Dieselgeneratoren (kWh und Brennstofftyp)
- Der Brennstofftyp bestimmt den Emissionsfaktor, [unsere Liste ist hier verfügbar](https://notion.leitmotiv.work/Commonly-used-diesel-fuels-blends-and-their-GWP-value-15eefc5c585381578a32f7829b9b3ddc?pvs=4)
- Energie aus dem Stromnetz (kWh)
- Ein Netz-Emissionsfaktor muss aus historischen Daten ([EEA](https://www.eea.europa.eu/en/analysis/indicators/greenhouse-gas-emission-intensity-of-1)) oder über APIs wie die [Electricity Map API](https://portal.electricitymaps.com/docs/getting-started#geolocation) bezogen werden
- **Gesamte entsorgte Abfallmenge**, aufgeschlüsselt nach:
- Abfallkategorien laut Anhang
- Relevante Abfallströme: Verpackung, elektrische Komponenten, Kühlflüssigkeiten, sonstige Flüssigkeiten und chemische Abfälle, mechanische Komponenten und alles, was das Rechenzentrum verlässt
- **Gesamter Frischwasserverbrauch** (m³)
- Gemessen per Wasserzähler oder über Rechnungen des Wasserversorgers. Jeder Frischwasserverbrauch ist zu berücksichtigen — sei es für Verdunstungskühlung oder andere Wassersysteme.
> Batterien können eine Rolle dabei spielen, den Anteil der erneuerbaren Energie zu erhöhen, die das Gebäude aufnehmen und nutzen kann. Wir hoffen, dies in einer zukünftigen Überarbeitung zu berücksichtigen.
**Zusammenfassende Formeln — Facility-Betriebswirkungen:**
$$E_{nicht\text{-}erneuerbar} = E_{gesamt} - E_{erneuerbar}$$
$$THG_{Facility} = E_{nicht\text{-}erneuerbar} \times EF_{Netz}$$
Wobei:
- $E_{gesamt}$ = Gesamter Nicht-IT-Energieverbrauch (kWh)
- $E_{erneuerbar}$ = Erneuerbare Energieerzeugung (kWh)
- $EF_{Netz}$ = Emissionsfaktor des Stromnetzes (kg CO₂-eq/kWh)
Für unser Beispiel nehmen wir an, das Gebäude ist leer, aber die Kühlungs- und Overhead-Systeme laufen und verbrauchen 10.000 kWh über ein Jahr. Während des Jahres erzeugten Vor-Ort-Solaranlagen 3.000 kWh und der Bezug von Windenergie aus einem Windpark im 50-km-Radius steuerte weitere 3.000 kWh bei. Der durchschnittliche Netz-Emissionsfaktor betrug 1 kg CO₂-eq/kWh. Die Dieselgeneratoren waren nicht in Betrieb.
Der Facility-Kontostand sieht nun so aus:
1. **Facility Umweltwirkungskonto (Jahr 1):**
1. Nicht-produktive Wirkung: 1.000 Einheiten
1. Graue Emissionen: 1.000 Einheiten
2. Betriebswirkung:
1. Gesamter Energieverbrauch: 10.000 kWh
2. Nicht-erneuerbarer Energieverbrauch: 4.000 kWh (bei 1 kg CO₂-eq/kWh)
3. Erneuerbarer Energieverbrauch: 6.000 kWh (Emissionsfaktor abhängig von Erzeugungsart)
4. THG-Emissionen: 4.000 kg CO₂-eq
5. Frischwasserverbrauch: 1.000 m³
6. Entsorgte Abfallmenge: 1.000 kg
2. Produktive Wirkung: 0 Einheiten
Die Wirkungen gelten als produktiv, wenn das Rechenzentrum mit Servern bestückt ist. Ist 100 % des verfügbaren Whitespace mit laufenden Servern belegt, sind die Betriebs- und Grauen Emissionen zu 100 % produktiv.
#### Rack
Die Betriebswirkungen des Racks entstehen durch die Energie, die das Rack durchleitet — sowohl thermisch als auch elektrisch. Zudem erbt das Rack indirekte Wirkungen vom Gebäude: Die Betriebs- und Grauen Emissionen des Gebäudes werden gleichmäßig auf alle Racks im Gebäude verteilt. So erhält das Rack Sichtbarkeit (aber nicht per se Verantwortung) über die Wirkungen, die seine Existenz „stromabwärts" in der Wertschöpfungskette verursacht.
> **Wichtig:** Die Betriebsemissionen des Racks müssen nicht gemessen werden, wenn Zugriff auf die Server zur Messung besteht. In diesem Fall kann dieser Schritt übersprungen werden. Rack-Level-Bilanzierung ist nur nötig, wenn die messende Partei keinen Zugriff auf Server-Metriken hat.
- **Rack-Betriebswirkung:**
- **Gesamte Energieeingabe** (kWh) — gemessen am Leistungsmesser: die gesamte elektrische Energie, die den PDUs des Racks zugeführt wird
- **Gesamter Energieverbrauch** (kWh) — gemessen an den PDUs: die gesamte an die Server gelieferte Energie
- **Rack-Auslegungskapazität** (kW) — statischer Wert: maximale Leistung, die das Rack an Server liefern kann
- **Gesamte thermische Energieeingabe** (kWh) — berechnet über Temperatur- und/oder Luftstromsensoren am Boden des Racks
- **Gesamte thermische Abgabe** (kWh) — berechnet über Sensoren am heißesten Punkt der Luftausgabe
- **Effizienz der Strom-zu-Thermik-Umwandlung** (%) — mit welcher Effizienz wandeln Luftbehandler, Wärmetauscher und Kältemaschinen 1 kWh Strom in 1 kWh thermische Energie um
- **Abhängige Metriken der Facility-Entität** (siehe „Metriken, die bereitgestellt werden müssen"):
- Facility — Aktueller Emissionsfaktor (1 kg CO₂-eq/kWh)
- Facility — Gesamte Rack-Kapazität im Gebäude (10)
- Facility — Gesamter Wasserverbrauch (1.000 m³)
- Facility — Gesamte entsorgte Abfallmenge (1.000 kg)
- Facility — Power Usage Effectiveness (PUE, 1,6)
Ein Rack gilt als produktiv, wenn die Rack-Auslegungskapazität und der Gesamte Energieverbrauch nahezu gleich sind — das bedeutet, dass die gelieferte Leistung vollständig genutzt wird.
Für die Berechnung aller Wirkungen (Betrieb, Graue Emissionen und indirekt) des Racks benötigen wir einige Metriken des Rechenzentrums — z. B. um den gesamten Wasserverbrauch des Gebäudes einem einzelnen Rack zuzuordnen. Wir teilen die Gesamtwerte durch die Anzahl der Racks, die das Gebäude aufnehmen kann, und verteilen so die Betriebswirkungen gleichmäßig auf die Racks.
Für die Beispielberechnung nehmen wir an, dass das Gebäude Kapazität für 10 Racks hat und das Rack zu 50 % belegt ist (Rack-Auslegungskapazität / Gesamter Energieverbrauch). Die Rack-Auslegungskapazität beträgt 5 kW.
**Zusammenfassende Formeln — Rack:**
$$E_{Rack} = P_{design} \times U_{Rack} \times h$$
$$f_{Rack} = \frac{1}{N_{Racks}}$$
$$EI_{indirekt,Rack}^{embodied} = EI_{Facility,Jahr} \times f_{Rack}$$
$$E_{Overhead,Rack} = P_{design} \times U_{Rack} \times (PUE - 1) \times h$$
Wobei:
- $P_{design}$ = Rack-Auslegungskapazität (kW)
- $U_{Rack}$ = Auslastung des Racks (0–1)
- $h$ = Stunden pro Jahr (8.760)
- $N_{Racks}$ = Gesamte Rack-Kapazität des Gebäudes
- $PUE$ = Power Usage Effectiveness
Der Rack-Kontostand am Jahresende:
1. **Nicht-produktive Wirkung:**
1. Graue Emissionen: 50 Einheiten (50 % des Rack-Anfangsbestands von 100)
2. Betriebswirkung: 0 Einheiten (das Rack verbraucht die ungenutzten 50 % der Leistung nicht; nur die Grauen Emissionen sind für den ungenutzten Teil „nicht-produktiv")
2. **Produktive Wirkung:**
1. Graue Emissionen: 50 Einheiten (diese Hälfte des Racks wird genutzt)
2. Betriebswirkung:
1. Gesamter Energieverbrauch: 21.900 kWh (5 kW × 50 % × 8.760 Stunden)
2. THG-Emissionen: 21.900 kg CO₂-eq (Emissionsfaktor: 1 kg CO₂-eq/kWh vom Gebäude)
3. **Indirekte Wirkung (vom Gebäude):**
1. Produktiv (50 %):
1. Graue Emissionen: 1.000 Einheiten / 10 Racks = 100 Einheiten pro Rack × 50 % = 50 Einheiten
2. Betriebswirkung:
1. Frischwasserverbrauch: 1.000 m³ / 10 Racks = 100 m³ × 50 % = 50 m³
2. Entsorgter Abfall: 1.000 kg / 10 Racks = 100 kg × 50 % = 50 kg
3. Energieverbrauch (Facility-Overhead): 2,5 kW × (PUE − 1) × 8.760 h = 2,5 × 0,6 × 8.760 = 13.140 kWh × 50 % = 6.570 kWh
4. THG-Emissionen (Facility-Overhead): 6.570 kg CO₂-eq
2. Nicht-produktiv (50 %):
1. Graue Emissionen: 1.000 Einheiten / 10 Racks = 100 Einheiten × 50 % = 50 Einheiten
2. Betriebswirkung:
1. Frischwasserverbrauch: 100 m³ × 50 % = 50 m³
2. Entsorgter Abfall: 100 kg × 50 % = 50 kg
3. Energieverbrauch (Facility-Overhead): 13.140 kWh × 50 % = 6.570 kWh
4. THG-Emissionen (Facility-Overhead): 6.570 kg CO₂-eq
#### Server
Die Betriebswirkung des Servers ergibt sich hauptsächlich aus seinem Energieverbrauch als primärem Input. Der Server benötigt auch Kühlenergie, die wir über den PUE-Wert des Rechenzentrums berücksichtigen. Zudem ordnen wir die indirekten Wirkungen des Gebäudes zu — über den Anteil der Serverleistung an der gesamten verfügbaren IT-Leistung des Gebäudes (siehe unten). Ein Server gilt als produktiv, wenn sein tatsächlicher Stromverbrauch nahe an seiner Nennleistung liegt.
> Der PUE-Wert muss ein nahezu Echtzeit-Wert sein, um Veränderungen der Außenbedingungen des Gebäudes sowie die Auswirkung von Maßnahmen zur Reduzierung der Kühllast des Servers (z. B. durch Abschalten) genau abzubilden. In zukünftigen Überarbeitungen möchten wir stattdessen die thermische Abgabe des Servers berechnen, um die Belastung des Kühlsystems genauer zu erfassen.
> Ein weiterer Verbesserungsbereich betrifft die Produktivitätsannahme des Servers: Die Produktivität sollte wahrscheinlich nicht an der Nennleistung vs. tatsächlichem Verbrauch gemessen werden, sondern an der Menge der bereitgestellten digitalen Ressourcen. Eine neue Metrik dafür wird im [SIEC-Projekt](https://ided.digital/projekte/siec-weiterentwicklung-server-idle-energy-coefficient) entwickelt.
- **Server-Betriebswirkung:**
- **Nennleistung** (kW) — statischer Wert: die vom Hersteller angegebene maximale Leistungsaufnahme (kann auch geschätzt werden, z. B. über die Boavizta API)
- **Gesamter Energieverbrauch** (kWh) — gemessen via IPMI oder approximiert über RAPL oder andere verfügbare Tools (Liste im Anhang)
- **Abhängige Metriken der Facility-Entität:**
- Facility — Aktueller Emissionsfaktor (1 kg CO₂-eq/kWh)
- Facility — Gesamte IT-Leistungskapazität im Gebäude (100 kW)
- Facility — Gesamter Wasserverbrauch (1.000 m³)
- Facility — Gesamte entsorgte Abfallmenge (1.000 kg)
- Facility — Power Usage Effectiveness (PUE, 1,6)
Wenn ein Server ein Jahr lang läuft und seine Nennleistung 1 kW beträgt, wäre sein maximal möglicher Energieverbrauch 8.760 kWh. Wenn er in dieser Zeit nur die Hälfte, also 4.380 kWh, verbraucht hat, betrachten wir diesen Anteil als „nicht-produktiv", da der Server hergestellt wurde, aber nicht voll ausgelastet ist.
Für die indirekten Wirkungen müssen wir einige Werte vom Rechenzentrum erhalten. In unserem Beispiel beträgt die Nennleistung 1 kW und die gesamte IT-Kapazität des Gebäudes 100 kW — der Server belegt also 1 % der Facility-Kapazität, und wir ordnen ihm ein Hundertstel der Betriebswirkungen des Gebäudes als indirekte Wirkung zu.
Für unser Beispiel nehmen wir an, dass der Server zu 50 % produktiv ist.
> Es ist wichtig zu beachten, dass wir annehmen, das Rechenzentrum liefert Kühlenergie proportional zur IT-Kapazität des Servers. Bei 50 kW eingesetzter Server-Leistung werden 50 kW × (PUE − 1) Overhead-Energie verbraucht, unabhängig davon, ob die Server zu 10, 20 oder 50 % ausgelastet sind. Wir verbuchen dies als nicht-produktive Wirkung, verwenden aber stets die Nennleistung für die Berechnung des nicht-produktiven Overhead-Energieverbrauchs. Dies sollte eine dynamischere Berechnung sein und wir streben eine Verbesserung in der nächsten Iteration an.
**Zusammenfassende Formeln — Server:**
$$E_{Server} = P_{Nenn} \times U_{Server} \times h$$
$$THG_{Server} = E_{Server} \times EF$$
$$f_{Server} = \frac{P_{Nenn}}{P_{Facility,IT}}$$
$$EI_{indirekt,Server}^{embodied} = EI_{Facility,Jahr} \times f_{Server}$$
$$E_{Overhead,Server} = E_{Server} \times (PUE - 1)$$
Wobei:
- $P_{Nenn}$ = Nennleistung des Servers (kW)
- $U_{Server}$ = Auslastung des Servers (0–1)
- $P_{Facility,IT}$ = Gesamte IT-Leistungskapazität des Gebäudes (kW)
- $EF$ = Emissionsfaktor (kg CO₂-eq/kWh)
Der Server-Kontostand am Jahresende:
1. **Nicht-produktive Wirkung:**
1. Graue Emissionen: 150 Einheiten (50 % des Server-Anfangsbestands von 300)
2. Betriebswirkung: 0 Einheiten (wir bilanzieren den nicht verbrauchten Strom des Servers nicht)
2. **Produktive Wirkung:**
1. Graue Emissionen: 150 Einheiten (50 % der Grauen Emissionen des Servers werden produktiv genutzt)
2. Betriebswirkung:
1. Gesamter Energieverbrauch: 4.380 kWh (1 kW × 50 % × 8.760 Stunden)
2. THG-Emissionen: 4.380 kg CO₂-eq (Emissionsfaktor: 1 kg CO₂-eq/kWh)
3. **Indirekte Wirkung (vom Gebäude):**
1. Produktiv (50 %):
1. Graue Emissionen: 1.000 Einheiten × 1 % = 10 Einheiten × 50 % = 5 Einheiten (Server belegt 1 kW von 100 kW IT-Kapazität und nutzt 50 % dieser Kapazität produktiv)
2. Betriebswirkung:
1. Frischwasserverbrauch: 1.000 m³ × 1 % = 10 m³ × 50 % = 5 m³
2. Entsorgter Abfall: 1.000 kg × 1 % = 10 kg × 50 % = 5 kg
3. Energieverbrauch (Facility-Overhead): 4.380 kWh × (PUE − 1) = 4.380 × 0,6 = 2.628 kWh
4. THG-Emissionen (Facility-Overhead): 2.628 kg CO₂-eq
2. Nicht-produktiv (50 %):
1. Graue Emissionen: 1.000 Einheiten × 1 % = 10 Einheiten × 50 % = 5 Einheiten
2. Betriebswirkung:
1. Frischwasserverbrauch: 1.000 m³ × 1 % = 10 m³ × 50 % = 5 m³
2. Entsorgter Abfall: 1.000 kg × 1 % = 10 kg × 50 % = 5 kg
3. Energieverbrauch (Facility-Overhead): 4.380 kWh × (PUE − 1) = 4.380 × 0,6 = 2.628 kWh
4. THG-Emissionen (Facility-Overhead): 2.628 kg CO₂-eq
### Zuordnung der Betriebs- und Grauen Emissionen des Servers auf Digitale Ressourcen
Die Zuordnung der Umweltwirkung auf digitale Ressourcen ist ein Ansatz, den wir erstmals in unserem [SoftAWERE-Projekt](https://www.umweltbundesamt.de/themen/digitalisierung/gruene-informationstechnik-green-it/software/energie-ressourceneffiziente-softwareprogrammierung) erprobt haben. Man kann es sich so vorstellen:
Ein Server stellt im laufenden Betrieb digitale Ressourcen für eine Applikation bereit.
Nehmen wir einen realen Server, für den eine LCA verfügbar ist — den Dell PowerEdge R740 ([offizielle LCA hier](https://sdia.unternehmens.cloud/s/4F3mGP2K6EDPTjK)). Dieser Server ist konfiguriert, um folgende digitale Ressourcen zu erzeugen:
- 2 × Intel Xeon Gold 6132 CPUs
- 12 × 32 GB RAM = 384 GB gesamt
- 1 × 400 GB SSD + 8 × 3,84 TB SSD = 31,12 TB SSD
- Dual-Port 10 GbE Netzwerkkarte
- 2 × 1.100 W Netzteile (Nennleistung = 1.100 W)
Mit diesen Informationen können wir sagen: Der Server verwendet 1.100 W, um maximal 100 % CPU-Auslastung auf zwei CPUs (28 Kerne), 384 GB RAM, 31,12 TB Speicherkapazität und 20 Gbit Netzwerkkapazität bereitzustellen. Vereinfacht: Der Server erzeugt digitale Ressourcen mit 1.100 W Eingabeenergie.
Aber wie verteilen wir die 1.100 W auf jeden Typ digitaler Ressource?
> Wenn die Nennleistung des Servers nicht verfügbar ist, kann sie über den TDP-Wert der CPU geschätzt werden. Für die im Dell-Server verwendeten Intel Xeon Chips [listet Intel](https://www.intel.com/content/www/us/en/products/sku/123541/intel-xeon-gold-6132-processor-19-25m-cache-2-60-ghz/specifications.html) einen TDP von 140 W. Mit der Methode von Tom Kennes ([hier](http://arxiv.org/abs/2306.10049)) kann daraus eine Schätzung der gesamten Serverleistung abgeleitet werden.
#### Zuordnung der Betriebswirkungen auf jeden Ressourcentyp
In unserer [früheren Forschung](https://sdiav2.cdn.prismic.io/sdiav2/f27e9d42-9137-4bd8-af69-83aa8d5736e9_Creating+a+digital+environmental+footprint_A+Life+Cycle+Assessment+approach.pdf) haben wir folgende Annahmen definiert, um die Betriebswirkungen auf jeden digitalen Ressourcentyp zu verteilen:
| Ressource | Betriebliche Allokation (%) |
|---|---|
| CPU | 65 % |
| Arbeitsspeicher (Memory) | 20 % |
| Speicher (Storage) | 10 % |
| Netzwerk | 5 % |
#### Zuordnung der Grauen Emissionen auf jeden Ressourcentyp
Für die Grauen Emissionen bietet die Dell-Studie eine nützliche Grafik zur Erstellung eines Zuordnungsverhältnisses. Während bei den Betriebswirkungen die CPU klar dominiert, sind bei den Grauen Emissionen die Festplatten der primäre Faktor.
| Ressource | Allokation Graue Emissionen (%) | Kommentar |
|---|---|---|
| CPU | 7 % | Teil des „Mainboard" — Annahme: Hälfte Arbeitsspeicher, Hälfte CPU |
| Arbeitsspeicher (Memory) | 7 % | Teil des „Mainboard" — Annahme: Hälfte Arbeitsspeicher, Hälfte CPU |
| Speicher (Storage) | 80 % | — |
| Netzwerk | 2 % | Annahme |
| Sonstige (Lüfter, Netzteil, Chassis) | 4 % | Verteilt auf alle Ressourcentypen; in dieser Darstellung separat ausgewiesen |
> Die Zuordnungsverhältnisse der Grauen Emissionen müssen entsprechend der Anzahl von Festplatten, CPUs und Speichermodulen im Server skaliert werden. Die Werte in der Tabelle sind spezifisch für die Konfiguration des Dell PowerEdge R740. In einer späteren Überarbeitung planen wir, ein Berechnungsmodell hinzuzufügen.
#### Aufgeladene Konten für den Dell PowerEdge R740
Mit den Daten aus der LCA können wir die Umweltwirkungskonten für den Server aufsetzen (unter Verwendung der Nutzungsdauer-Annahme von 5 Jahren). Nehmen wir an, der Server ist im Leerlauf — alle Grauen Emissionen werden dem nicht-produktiven Unterkonto zugeordnet. Alle Daten sind kumuliert zum Jahresende.
**Server — Konto Graue Emissionen:**
1. Produktiv: keine
2. Nicht-produktiv:
1. Abiotischer Ressourcenverbrauch [MJ]: 9,66E+04 / 5 Jahre
2. Versauerungspotenzial [kg SO₂-eq]: 3,01E+01 / 5 Jahre
3. Eutrophierungspotenzial [kg Phosphat-eq]: 2,43E+00 / 5 Jahre
4. Ozonabbaupotenzial [kg R11-eq]: 5,74E-08 / 5 Jahre
5. Photochemisches Ozonbildungspotenzial [kg Ethen-eq]: 1,96E+00 / 5 Jahre
6. Treibhauspotenzial 100 Jahre inkl. biogener Kohlenstoff [kg CO₂-eq]: 4.290 kg CO₂-eq / 5 Jahre
**Server — Konto Betriebswirkungen** (bei 100 % Auslastung, Leerlauf):
1. Produktive Wirkung: keine
2. Nicht-produktive Wirkung:
1. Gesamter Energieverbrauch: 9.636 kWh (1,1 kW × 100 % × 8.760 Stunden)
2. THG-Emissionen: 9.636 kg CO₂-eq (Emissionsfaktor: 1 kg CO₂-eq/kWh)
3. Indirekte Wirkung (vom Gebäude):
1. Produktiv: keine
2. Nicht-produktiv:
1. Graue Emissionen: 1.000 Einheiten × 1,1 % = 11 Einheiten (Server belegt 1,1 kW von 100 kW IT-Kapazität)
2. Betriebswirkung:
1. Frischwasserverbrauch: 1.000 m³ × 1,1 % = 11 m³
2. Entsorgter Abfall: 1.000 kg × 1,1 % = 11 kg
3. Energieverbrauch (Facility-Overhead): 9.636 kWh × (PUE − 1) = 9.636 × 0,6 = 5.781,6 kWh
4. THG-Emissionen (Facility-Overhead): 5.781,6 kg CO₂-eq
#### Zuordnung der Wirkungen auf digitale Ressourcen
Mit unserer Logik der Umweltwirkungskonten und den oben definierten Allokationsregeln können wir die Konten für jeden digitalen Ressourcentyp befüllen. Wir nehmen an, der Server ist vollständig im Leerlauf — alle Wirkungen gehen auf das nicht-produktive Konto. Der Server läuft ein Jahr.
%% TODO: Die Verwendung von 25 % für die indirekte Embodied-Allokation auf alle vier Ressourcentypen (gleichmäßig verteilt) sollte hier erklärt werden. Begründung: Da die physische Infrastruktur des Rechenzentrums (Gebäude, Kühlung, USV) allen Ressourcentypen gleichermaßen dient und nicht nach Ressourcentyp differenziert werden kann, verteilen wir die indirekten Grauen Emissionen gleichmäßig mit je 25 %. %%
**Allgemeine Formel — Zuordnung auf digitalen Ressourcentyp $r$:**
$$EI_{r}^{op} = EI_{Server}^{op} \times \alpha_r^{op}$$
$$EI_{r}^{emb} = EI_{Server}^{emb} \times \alpha_r^{emb}$$
$$EI_{r,indirekt}^{op} = EI_{Server,indirekt}^{op} \times \alpha_r^{op}$$
$$EI_{r,indirekt}^{emb} = EI_{Server,indirekt}^{emb} \times 25\%$$
Wobei:
- $\alpha_r^{op}$ = Betriebliche Allokation für Ressourcentyp $r$ (CPU: 65 %, Memory: 20 %, Storage: 10 %, Network: 5 %)
- $\alpha_r^{emb}$ = Embodied-Allokation für Ressourcentyp $r$ (CPU: 7 %, Memory: 7 %, Storage: 80 %, Network: 2 %, Sonstige: 4 %)
- 25 % = Gleichmäßige Verteilung der indirekten Grauen Emissionen auf vier Ressourcentypen
---
**CPU-Nutzung:**
1. Betriebswirkung:
1. Nicht-produktiv: (Server Betriebswirkung − Produktiv) × 65 %
2. Produktiv: keine
2. Graue Emissionen:
1. Nicht-produktiv: (Server Graue Emissionen − Produktiv) × 7 %
2. Produktiv: keine
3. Indirekte Wirkung:
1. Nicht-produktiv:
1. (Server Indirekte Betriebswirkung − Produktiv) × 65 %
2. (Server Indirekte Graue Emissionen − Produktiv) × 25 %
2. Produktiv: keine
**Arbeitsspeicher-Nutzung (Memory):**
1. Betriebswirkung:
1. Nicht-produktiv: (Server Betriebswirkung − Produktiv) × 20 %
2. Produktiv: keine
2. Graue Emissionen:
1. Nicht-produktiv: (Server Graue Emissionen − Produktiv) × 7 %
2. Produktiv: keine
3. Indirekte Wirkung:
1. Nicht-produktiv:
1. (Server Indirekte Betriebswirkung − Produktiv) × 20 %
2. (Server Indirekte Graue Emissionen − Produktiv) × 25 %
2. Produktiv: keine
**Speicher-Nutzung (Storage):**
1. Betriebswirkung:
1. Nicht-produktiv: (Server Betriebswirkung − Produktiv) × 10 %
2. Produktiv: keine
2. Graue Emissionen:
1. Nicht-produktiv: (Server Graue Emissionen − Produktiv) × 80 %
2. Produktiv: keine
3. Indirekte Wirkung:
1. Nicht-produktiv:
1. (Server Indirekte Betriebswirkung − Produktiv) × 10 %
2. (Server Indirekte Graue Emissionen − Produktiv) × 25 %
2. Produktiv: keine
**Netzwerk-Nutzung:**
1. Betriebswirkung:
1. Nicht-produktiv: (Server Betriebswirkung − Produktiv) × 5 %
2. Produktiv: keine
2. Graue Emissionen:
1. Nicht-produktiv: (Server Graue Emissionen − Produktiv) × 2 %
2. Produktiv: keine
3. Indirekte Wirkung:
1. Nicht-produktiv:
1. (Server Indirekte Betriebswirkung − Produktiv) × 5 %
2. (Server Indirekte Graue Emissionen − Produktiv) × 25 %
2. Produktiv: keine
---
Stellt man sich nun vor, dass die Hälfte der CPU vollständig ausgelastet ist, verschiebt sich die Hälfte des nicht-produktiven CPU-Kontos zum produktiven. Wenn eine Applikation auf dem Bare-Metal-Server läuft und die Hälfte der digitalen Ressourcen belegt, kann die gesamte Wirkung der Applikation zugeordnet werden — getrennt nach produktiv und nicht-produktiv und sogar aufgeschlüsselt nach dem Typ der digitalen Ressource, den die Applikation nutzt.
Auf einem einzelnen Bare-Metal-Server ist dies noch nicht besonders hilfreich, da die Wirkungskonten des Servers direkt für das Impact-Reporting genutzt werden können. Aber wir verwenden die Zuordnung auf digitale Ressourcen in einem späteren Schritt.
### Alles zusammenführen — für eine Software-Applikation
Wir haben alle physischen Wirkungskonten aller Maschinen und Gebäude in der Wertschöpfungskette unterhalb der Applikation aufgeladen. Soweit logisch. Jetzt kommt der schwierige Teil: die Verbindung zur tatsächlichen Applikation.
Konzeptionell können wir sagen: Wenn eine Applikation läuft und dabei den Server oder/und seine digitalen Ressourcen nutzt, ist das produktiv. Ob die Applikation etwas Sinnvolles tut, ist nicht Gegenstand dieser Bewertung.
Was **nicht** produktiv ist: Eine Applikation, die eine Reservierung vornimmt — z. B. eine virtuelle Maschine mit 16 GB Arbeitsspeicher und 16 Kernen bucht — von der sie maximal 30 % nutzt. Diese 70 % „reserviert, aber nicht genutzt" sind nicht-produktiv, da sie von einer anderen Applikation genutzt werden könnten.
> Wir ignorieren die Tatsache, dass Hypervisor und Orchestrator viel „Magie" betreiben, um Server zu überbuchen — also Applikationen erlauben, 110–200 % der physisch verfügbaren digitalen Ressourcen zu reservieren, wohlwissend, dass sie diese nicht alle gleichzeitig nutzen werden. Im Prinzip wäre diese Magie nicht nötig, wenn Applikationen ihre Reservierungen kontinuierlich basierend auf der tatsächlichen Nutzung anpassen würden („Right Sizing").
>
> Mit unserem Ansatz erfassen wir den wichtigsten Fakt: Mehr Ressourcen zu reservieren als benötigt, ist nicht produktiv und erzeugt Verschwendung, die gemanagt und vermieden werden sollte.
Mit dieser Definition von produktiv und nicht-produktiv im Hinterkopf, betrachten wir nun die verschiedenen Ansätze zur Zuordnung der Umweltwirkungskonten auf die Applikation. Es ist alles additiv und kumulativ — z. B. wenn eine Applikation zwei physische Server ein Jahr lang zu 100 % ausnutzt, werden die Konten beider Server zusammenaddiert und der Applikation zugeordnet.
Das Ziel: Die Verantwortung für Umweltwirkung der richtigen Entität zuordnen. Wenn eine Applikation unnötige Reservierungen vornimmt, sollte es Aufgabe des Applikationsverantwortlichen sein, dies zu beheben. Ebenso ordnen wir der Applikation die indirekten Wirkungen zu, da der Applikationsverantwortliche die Wahl hat, welches Rechenzentrum, welchen IT- oder Cloud-Infrastrukturanbieter er nutzt. Es sollte seine Verantwortung sein, sich für einen Anbieter mit geringer Wirkung zu entscheiden — was einen Anreiz für diese Anbieter schafft, sich zu verbessern.
#### Ansatz 0: Bare-Metal-Zuordnung
Der einfache Fall. Wenn eine Applikation einen oder mehrere Bare-Metal-Server nutzt, sind die gesamten digitalen Ressourcen des Servers die Reservierung (nicht-produktiv), und die tatsächliche Nutzung der digitalen Ressourcen ist die produktive Nutzung.
Dies kann auf zwei Arten berechnet werden:
1. **Weniger präzise:** Das Wirkungskonto des Servers verwenden und zunächst alles als nicht-produktiv zuordnen. Dann den Prozentsatz der tatsächlich genutzten digitalen Ressourcen berechnen — z. B. wenn ein Server maximal 32 Kerne, 128 GB Arbeitsspeicher, 100 Mio. I/O-Ops/10 Gbit Bandbreite und 100 Mio. Netzwerk-Ops/100 Gbit Bandbreite bietet und die Applikation insgesamt 30 % dieser Kapazität nutzt, können 30 % des Server-Wirkungskontos für die Applikation als „produktiv" verbucht werden.
2. **Präziser:** Die Wirkungskonten auf jeden Typ digitaler Ressource herunterbrechen und direkt über die tatsächliche Nutzung jedes Ressourcentyps durch die Applikation berechnen — z. B. hat Disk-I/O möglicherweise mehr Graue Emissionen als Betriebswirkungen, während die CPU betriebswirkungslastig ist und weniger Graue Emissionen hat.
Für beide Ansätze muss die Nutzung digitaler Ressourcen des Servers mit einem IT-Infrastruktur-Monitoring-Tool überwacht werden.
Wenn eine Applikation über mehrere Server verteilt ist, sollten die Konten pro Server berechnet und dann zum Gesamtwirkungskonto der Applikation addiert werden. Durchschnittswerte sind hier zu vermeiden, da die Server unterschiedliche Auslastungsprofile haben können (z. B. ein Datenbankserver und ein Applikationsserver, die zusammen eine Applikation betreiben).
**Zusammenfassende Formel — Bare-Metal-Zuordnung:**
$$EI_{App}^{prod} = \sum_{s=1}^{S} EI_{Server_s} \times U_{App,s}$$
$$EI_{App}^{nicht\text{-}prod} = \sum_{s=1}^{S} EI_{Server_s} \times (1 - U_{App,s})$$
Wobei:
- $S$ = Anzahl der Server, die die Applikation nutzt
- $U_{App,s}$ = Auslastung der Applikation auf Server $s$ (0–1)
#### Hypervisor und Orchestrator
Im Kontext unseres Ansatzes können Hypervisor und Orchestrator als Reservierungsmanager verstanden werden. Eine ihrer Aufgaben ist es, die Lücke zwischen Reservierungen und Nutzung zu schließen und die Auslastung der zugrunde liegenden Hardware zu maximieren. Sie bieten auch eine Isolationsebene, die Messungen grundsätzlich komplexer macht — aber es gibt viele Tools, die dies umgehen (siehe Anhang).
Das Gute: Diese Systeme haben einen vollständigen Überblick über alle Reservierungen pro virtueller Maschine, Container oder Pod („Bündel digitaler Ressourcen"), die auf einem Server oder innerhalb eines Server-Clusters laufen. Sie verfügen auch über genaue Daten über die digitalen Ressourcen, die jedes Bündel zu jedem Zeitpunkt nutzt. Und sie kennen meist alle Spezifikationen des Host-Systems (z. B. gesamte CPU-, Speicher-, Disk- und I/O-Kapazitäten).
In Ansatz 1 und 2 sollten — wenn zugänglich und möglich — Daten vom Hypervisor oder Orchestrator bevorzugt werden.
#### Ansatz 1: Nutzungsbasiert (Digital-Resource-Monitoring)
Bei diesem Ansatz ignoriert man die nicht-produktiven Wirkungen und konzentriert sich darauf, den Verbrauch digitaler Ressourcen durch die Applikation in Umweltwirkung umzurechnen. Dafür wird z. B. ein IT-Monitoring-System eingesetzt, das die Nutzung digitaler Ressourcen der Applikation überwacht und diese Nutzung mit dem Wirkungskonto für jeden digitalen Ressourcentyp kombiniert (wie unter „Zuordnung der Betriebs- und Grauen Emissionen des Servers auf Digitale Ressourcen" beschrieben).
Dafür benötigt man die Information vom Server über das Wirkungskonto pro erzeugtem digitalen Ressourcentyp.
Als mentales Modell: eine Überweisung. Wenn die Applikation 10 % der CPU des zugrunde liegenden Server-Systems für einen Tag nutzt, muss der Server die Wirkung der CPU-Nutzung für diesen einen Tag auf das (produktive) Applikationskonto „überweisen".
Wenn die Applikation über mehrere Systeme verteilt ist, z. B.:
- 10 Kubernetes-Pods
- 2 Bare-Metal-Server
- 14 Virtuelle Maschinen
... muss die Übertragung für jedes dieser Systeme einzeln erfolgen und zum Applikations-Wirkungskonto addiert werden. Man kann nicht die Nutzung digitaler Ressourcen auf jedem System messen und zuerst Durchschnitte oder Summen bilden — die Wirkung muss für jedes Bündel oder jeden physischen Server basierend auf der tatsächlich dort aufgetretenen Nutzung berechnet werden.
#### Ansatz 2: Reservierungsbasiert (Digital-Resource-Allocation)
Wenn kein IT-Monitoring-System zur Messung des Ressourcenverbrauchs verfügbar ist, aber folgende Informationen vom IT-Infrastruktur-Team vorliegen:
Die Applikation nutzt:
- 3 Virtuelle Maschinen mit je 16 GB Arbeitsspeicher, 16 Kernen und 100 GB Speicher
- 2 Bare-Metal-Server mit je 128 GB Arbeitsspeicher, 96 Kernen und 1,92 TB Speicher
- 10 Pods mit je 512 MB Arbeitsspeicher-Anforderung
Nun können die Wirkungskonten der Server, die die Bündel oder Bare-Metal-Kapazität für jeden digitalen Ressourcentyp bereitstellen, genutzt werden, um das nicht-produktive Wirkungskonto für die Applikation zu berechnen. Dafür multipliziert man die Reservierungen mit dem Konto des jeweiligen Ressourcentyps — z. B. 128 GB Arbeitsspeicher × Betriebs- und Embodied-Wirkungskonto für den Ressourcentyp „Memory" dieses Servers.
Für virtuelle Maschinen (VM) muss zunächst der Anteil berechnet werden, den die VM-Ressourcen an den Gesamtressourcen des zugrunde liegenden Servers ausmachen — z. B. hat der Server 128 GB Arbeitsspeicher und 16 GB entsprechen 12,5 %. Also können 12,5 % des Memory-Wirkungskontos der Applikation zugeordnet werden (als nicht-produktiv).
**Zusammenfassende Formel — Reservierungsbasierte Zuordnung für eine VM:**
$$EI_{App,VM}^{nicht\text{-}prod} = \sum_{r} \left( \frac{Res_{VM,r}}{Res_{Server,r}} \times EI_{Server,r} \right)$$
Wobei:
- $r$ = Ressourcentyp (CPU, Memory, Storage, Network)
- $Res_{VM,r}$ = Reservierte Ressourcen der VM für Typ $r$
- $Res_{Server,r}$ = Gesamte verfügbare Ressourcen des Servers für Typ $r$
#### Ansatz 3: Kombination von Reservierung und Verbrauch für produktive und nicht-produktive Wirkung
Die eigentliche Stärke entfaltet sich in der Kombination beider Ansätze. Denn damit lässt sich die Lücke zwischen produktiver und nicht-produktiver Umweltwirkung schließen. Auch wenn eine Reduktion nicht möglich ist, verringert das Schließen dieser Lücke zumindest die Menge an verschwendeter Energie und ungenutzter, hergestellter Ausrüstung.
Für das Portfolio an Servern, virtuellen Maschinen, Containern und/oder Pods, für die die Applikation verantwortlich ist, berechnet man zunächst das nicht-produktive Konto wie in Ansatz 2 beschrieben. Das ist die Basislinie: 100 % Leerlauf, 100 % nicht-produktiv. Dann fügt man die Messung der Nutzung digitaler Ressourcen hinzu und kann nun kontinuierlich Wirkung zwischen dem produktiven und nicht-produktiven Konto verschieben („überweisen"), abhängig von der tatsächlichen Nutzung.
Die Konten sind kumulativ — es wird zu einem „Optimierungsspiel", das weitere Befüllen des nicht-produktiven Kontos zu vermeiden, indem Auslastung sichergestellt wird.
**Zusammenfassende Formel — Kombinierter Ansatz:**
$$EI_{App}^{prod}(t) = \sum_{s=1}^{S} \sum_{r} EI_{Server_s,r} \times U_{App,s,r}(t)$$
$$EI_{App}^{nicht\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)$$
Wobei:
- $U_{App,s,r}(t)$ = Tatsächliche Nutzung der Applikation von Ressourcentyp $r$ auf Server $s$ zum Zeitpunkt $t$
- $\frac{Res_{App,s,r}}{Res_{Server_s,r}}$ = Reservierungsanteil der Applikation
#### Zusammenfassung
Für die Zuordnung der Umweltwirkung der Infrastruktur auf die Applikation schlagen wir vor, zunächst ein Wirkungskonto für die Reservierung von Ressourcen zu erstellen, die durch das Bündel (virtuelle Maschine, Pod oder anderes) definiert wird. Dieses Konto ist die nicht-produktive Umweltwirkung und wird definiert durch den Anteil der Umweltwirkung des zugrunde liegenden Servers im Verhältnis zur Menge der digitalen Ressourcen, die die Reservierung auf dem Server belegt.
Von dort wird kontinuierlich Umweltwirkung (kumulativ!) auf das produktive Konto verschoben, wenn die reservierten digitalen Ressourcen tatsächlich genutzt werden. So erhält man eine genaue Messung der „Ressourceneffizienz" der Applikation sowie der gesamten Umweltwirkung über den Lebenszyklus der Applikation.
Wenn eine Applikation aus vielen Bündeln besteht (z. B. tausend virtuelle Maschinen), empfehlen wir, ein Wirkungskonto pro Bündel zu führen und die Konten auf Applikationsebene zu aggregieren. Dies erlaubt auch, Entwicklungs- und Staging-Umgebungen in die Berechnung einzubeziehen. Wenn Bündel hinzugefügt oder entfernt werden, werden sie einfach zum kumulativen Konto der Applikation addiert.
Da Umweltwirkung nie umkehrbar ist — Ressourcenverbrauch, CO₂-Emissionen oder verbrauchte Energie können nicht „zurückgegeben" werden — ist es entscheidend, alle Konten kumulativ zu führen. Leider kann eine Reduktion der Infrastruktur einer Applikation von tausend auf hundert virtuelle Maschinen die Vergangenheit nicht ändern. Sie beeinflusst nur die Änderungsrate: Das Wirkungskonto kumuliert langsamer.
### Ausblick
Mit dieser Methodik führen wir einige neue Schlüsselideen ein:
1. **Kumulative Konten** für Umweltwirkungen
2. **Zuordnung** der Umweltwirkungen aus der gesamten Wertschöpfungskette einer Applikation auf die Applikation selbst
3. **Eine ganzheitliche Liste** von Umweltwirkungsindikatoren
### Anhang
#### Liste der Umweltwirkungsindikatoren für Software
- Gesamter Energieverbrauch (kWh)
- Gesamte THG-Emissionen (CO₂-eq)
- Graue CO₂-eq aus Herstellung und Transport von Ausrüstung und Gebäuden
- Betriebliche CO₂-eq aus Energieverbrauch
- Ressourcenverbrauch — Abiotisches Erschöpfungspotenzial (ADP)
- Das abiotische Erschöpfungspotenzial verbindet den Ressourcenverbrauch einer Organisation mit der Seltenheit fossiler Ressourcen. Es verwendet ein dimensionsloses Maß, das die Abbaurate einer Ressource mit der weltweiten Gesamtreserve vergleicht.
- Abfall von Elektro- und Elektronikgeräten (WEEE, Tonnen)
#### Metriken, die von jeder Entität bereitgestellt werden müssen
**Rechenzentrum:**
- Emissionsfaktor der bereitgestellten IT-Energie:
- Vor-Ort nicht-erneuerbare Energieerzeugung: kWh und Typ (z. B. Diesel)
- Je nach Typ variiert der THG-Emissionsfaktor
- Für die Differenz zwischen Gesamtenergieverbrauch und erneuerbarer Energieerzeugung (kWh) sollte der Netz-Emissionsfaktor (z. B. von der Electricity Map API) verwendet werden
- Facility — Aktueller Emissionsfaktor (kg CO₂-eq/kWh)
- Facility — Gesamte Rack-Kapazität im Gebäude
- Facility — Gesamter Wasserverbrauch (m³)
- Facility — Gesamte entsorgte Abfallmenge (kg)
- Facility — Power Usage Effectiveness (PUE)
#### Umrechnungsformeln
> In einer zukünftigen Aktualisierung werden wir Ansätze zur Umrechnung von Messwerten in Umweltwirkungen aufnehmen, z. B. für Energie, sowie unsere Forschungsergebnisse zu nützlichen Standardwerten.
#### Liste der Annahmen für Cloud-Region-Rechenzentren
> Diese Liste wird in einer zukünftigen Aktualisierung ergänzt — die Recherche einer aktuellen Datenbasis läuft noch.
#### Liste der Tools zur Messung des Energieverbrauchs von Servern
> Diese Liste wird in einer zukünftigen Aktualisierung ergänzt — die Recherche einer aktuellen Übersicht läuft noch.
#### Liste der zu berücksichtigenden Abfallströme für das Rechenzentrum
Basierend auf dem [EU LCA-Indikatorenrahmen](https://eplca.jrc.ec.europa.eu/uploads/LCindicators-framework.pdf).
## Related Publications
- [[IDED/Communication/Website/Publikationen/Live/nadiki-methodik-umweltwirkung-berechnung]]
- [[IDED/Communication/Website/Publikationen/Live/nadiki-observer-architektur-umweltwirkung]]
- [[IDED/Communication/Website/Publikationen/Live/nadiki-registrar-implementierung-open-source]]