API für die CO₂-Emissionsberechnung

Jede Betonage, jede Stahllieferung und jede Baggerschicht auf einer Infrastrukturbaustelle weist einen messbaren CO2-Wert auf. Eine Carbon Emissions API stellt diese Werte als strukturierte Daten bereit, die von bautechnischer Software bei Bedarf direkt abgefragt werden können. Ändern sich die Massen, passen sich die Werte unmittelbar an. NEXATEK implementiert diese CO2-Dateninfrastruktur für Organisationen im Bauingenieurwesen – meist eingebettet in ein umfassendes Programm zur digitalen Transformation. Dadurch stehen die Emissionsdaten direkt in den Systemen zur Verfügung, die Ingenieure täglich nutzen.

Eine Carbon Emissions API wandelt Projektmengen in strukturierte CO2-Daten um, die Ingenieurteams systemübergreifend nutzen können.

Eine Carbon Emissions API ist eine Softwareschnittstelle, die Projektmengen und Massenansätze entgegennimmt und berechnete Emissionswerte zurückgibt. Eine Anwendung sendet eine Anfrage mit Angaben zu einem Material oder einer Bauaktivität – beispielsweise 450 m³ Beton der Festigkeitsklasse C30/37. Der Dienst gleicht die Eingabe mit einer Datenbank hinterlegter Emissionsfaktoren ab und gibt das Ergebnis in Kilogramm CO2-Äquivalent (kgCO2e) aus. Zu keinem Zeitpunkt muss dafür eine Tabellenkalkulation geöffnet werden.

Die Schnittstelle bündelt die Berechnungslogik für Treibhausgasemissionen für eine gesamte Organisation. Jedes angebundene Projekt erhält dieselben Faktoren und einheitliche Einheitenumrechnungen. Die abfragenden Systeme reichen von BIM-Plugins bis hin zu Beschaffungsplattformen. Ändert sich ein Faktor, steht die Aktualisierung sofort allen Nutzern zur Verfügung. Auf diese Weise fungiert eine Carbon Footprint API wie jeder andere zentrale Ingenieurdienst: eine einheitliche Berechnungsmethode für viele nachgelagerte Clientsysteme.

Ein Autobahnkreuz umfasst Tausende emissionsrelevante Positionen: Betonrezepturen, Bewehrungsstahl, Erdbauarbeiten, Transportleistungen. Jede Position besitzt ihren eigenen Emissionsfaktor, und viele dieser Faktoren ändern sich im Projektverlauf. Die manuelle Nachverfolgung solch dynamischer Datensätze ist nicht skalierbar.

Zwei Lieferungen derselben Betongüte können unterschiedliche CO2-Werte aufweisen. Die Rezeptur, das Zementwerk, die Transportdistanz und die Mischanlage beeinflussen das Gesamtergebnis. Multipliziert man diese Variabilität mit hunderten Baumaterialien und mehreren Bauphasen, wird die Dimension der Datenverwaltung deutlich.

Infrastrukturprojekte laufen zudem über Jahre. Ein in der Ausschreibungsphase gültiger Emissionsfaktor kann bereits veraltet sein, wenn das entsprechende Los vergeben wird. Umplanungen verstärken diese Dynamik: Der Wechsel von einem Fertigteilüberbau zu einer Ortbetonbrücke verändert Materialmengen und Transportwege gleichzeitig.

Emissionswerte verändern sich mit wechselnden Materialien, Lieferanten, Transportrouten und Bauphasen.

Tabellenkalkulationen eignen sich für punktuelle Schätzungen, stoßen jedoch bei wachsender Projektgröße schnell an ihre Grenzen. Häufige Fehlerquellen sind überschriebene Formeln oder aus Altprojekten übernommene Faktoren. Ein Einheitenfehler – etwa Tonnen statt der von der Formel erwarteten Kilogramm – verfälscht das Ergebnis um den Faktor 1.000 und bleibt bei Prüfungen nicht selten unbemerkt.

Die Versionskontrolle ist eine weitere Schwachstelle. Wenn fünf Ingenieure jeweils eine eigene Kopie der Berechnungsdatei bearbeiten, lässt sich der aktuelle Stand kaum noch verlässlich bestimmen. Die Verlagerung der Berechnung in einen zentralen Dienst beseitigt diese Unklarheiten. Deshalb ist das Emissions-Tracking häufig Teil einer umfassenderen Prozessoptimierung.

Eine zentrale API minimiert Risiken bei der Versionskontrolle, indem sie die Berechnungsmethode an einer zentralen Stelle vorhält.

Emissionsdaten im Bauwesen unterteilen sich in verschiedene Kategorien mit unterschiedlichen Quellen und Aktualisierungszyklen. Eine Carbon Emissions API für die Bauwirtschaft muss jede dieser Kategorien verarbeiten, um eine lückenlose Projektbilanz zu liefern. Vier Bereiche decken die meisten Vorhaben ab.

Die API muss Material-, Transport-, Baustellen- und Gesamtprojektdaten gemeinsam verarbeiten können.

Baumaterialien machen den Hauptteil der grauen Energie und der gebundenen Emissionen (Embodied Carbon) moderner Infrastrukturbauwerke aus, allen voran Beton und Stahl. Die primäre Datenquelle sind Umweltproduktdeklarationen (EPDs) – herstellerbezogene Dokumente, die die Emissionen pro definierter Produkteinheit ausweisen. Werden EPD-Werte nach Lieferant und Güteklasse erfasst, reduziert sich der ökologische Variantenvergleich zweier Stahllieferanten im Einkauf auf eine kurze Datenbankabfrage.

Der Transport von 30 Tonnen Gesteinskörnung über 120 km verursacht auf der Schiene eine andere CO2-Bilanz als auf der Straße. Transportemissionen hängen von Frachtgewicht, Transportdistanz, Verkehrsträger und Kraftstoffart ab. Da sich Fahrtrouten und Speditionen im Bauablauf ändern, zählen Materialtransportdaten zu den dynamischsten Parametern eines Projekts.

Verbrannte Kraftstoffe in Baumaschinen und temporären Stromerzeugern verursachen den Großteil der direkten Baustellenemissionen. Als Eingangsgrößen dienen Betriebsstunden und Treibstoffmengen, die Baustellenteams über mobile Datenerfassungssysteme oder Telematik-Schnittstellen digital erfassen können. Umgerechnet auf den jeweiligen Arbeitsvorgang machen diese Daten transparent, welche Bauphasen die CO2-Bilanz vor Ort dominieren.

Das Projektmanagement benötigt eine konsolidierte Gesamtsicht: kumulierte Infrastruktur-Emissionsdaten aufgeschlüsselt nach Gesamtprojekt oder Berichtszeitraum. Eine fundierte Aggregation gelingt nur, wenn alle zugrunde liegenden Datensätze einer einheitlichen Datenstruktur folgen – dies ist gleichermaßen eine Frage des Datenbankdesigns wie der Berechnungslogik. NEXATEK kombiniert die API daher üblicherweise mit einer individuellen Datenbankentwicklung, damit übergeordnete Kennzahlen auf exakt denselben granularen Daten basieren, die auf der Baustelle anfallen.

Der Datenfluss erfolgt geradlinig: Bestandssysteme der Ingenieure übergeben Massen und Aktivitäten, und der Dienst gibt strukturierte Emissionswerte zurück. Bei NEXATEK beginnt die Systemintegration mit zwei zentralen Fragen: Welche Systeme liefern die Eingangsdaten und welche Plattformen verarbeiten die Ergebnisse weiter?

Ingenieursysteme übermitteln strukturierte Daten an die API und erhalten einheitliche Werte in kgCO2e zurück.

Als Eingangsgrößen dienen Daten, die Ingenieure ohnehin erfassen: Leistungsverzeichnisse (LV) und Mengenermittlungen liefern Materialarten und Volumina – oft direkt aus dem BIM-Modell exportiert. ERP-Systeme ergänzen Lieferantenangaben, während Baustellenberichte Verbrauchsdaten beisteuern. Jeder API-Aufruf enthält vier Basisparameter: Artikel- oder Materialcode, Menge, Einheit und Projektreferenz. Anfragen mit fehlenden Einheiten werden von der Schnittstelle abgewiesen, statt fehleranfällige Annahmen zu treffen.

Die Schnittstelle ordnet zunächst den passenden Emissionsfaktor zum Materialcode zu – wobei herstellerspezifische EPD-Daten Vorrang vor regionalen Durchschnittswerten haben. Anschließend erfolgt die Datennormalisierung: Gibt ein Lieferant Beton in Kubikmetern und ein anderer in Tonnen an, sorgt ein Dichtefaktor vor der Berechnung für eine einheitliche Bezugsbasis. Die Ausgabe erfolgt standardmäßig in kgCO2e, wodurch Kennzahlen über verschiedene Projekte und Bezugsquellen hinweg vergleichbar werden.

Die Rückmeldung erfolgt in einem maschinenlesbaren Format, meist als JSON. Jedes angebundene System kann die Emissionswerte nahtlos in die eigene Datenstruktur einbinden: Ein Kosten-Dashboard stellt Emissionen neben Ausgaben dar, ein Terminplanungstool verknüpft sie mit dem Bauablauf. In einer zentralen Datenbank abgelegt, bleiben die Ergebnisse auch nach Projektabschluss auswertbar und unterstützen ein unternehmensweites Umwelt- und Nachhaltigkeitsreporting.

Beide Ansätze unterscheiden sich fundamental im Umgang mit Planungsänderungen. Auf einer aktiven Baustelle sind Änderungen der Normalzustand, und dieser Unterschied wirkt sich täglich aus.

Ein statischer Bericht bildet ausschließlich den Planungsstand des jeweiligen Erstellungsdatums ab. Nachträge, Umplanungen oder Lieferantenwechsel nach diesem Stichtag bleiben unberücksichtigt. Eine Aktualisierung erfordert das manuelle Durchrechnen des gesamten Modells. Prüft ein Planer eine CO2-reduzierte Brückenüberbau-Variante, muss er oft bis zum nächsten Berichtszyklus warten, um die Auswirkungen zu quantifizieren. Auch die Prüfpfade leiden, da die Nachvollziehbarkeit vom Rohdatenwert bis zur Kennzahl meist in einer isolierten Tabellendatei verborgen bleibt.

Eine API-basierte Lösung berechnet die Kennzahlen bei jeder Änderung der Eingabedaten neu. Ein modifiziertes Leistungsverzeichnis liefert noch am selben Tag aktualisierte Bilanzen statt erst zum nächsten Meilenstein. Die zentrale, versionierte Berechnungslogik gewährleistet zudem lückenlose Transparenz: Ein Prüfer kann jede Kennzahl direkt auf die zugrunde liegenden Eingabewerte und Faktoren zurückführen. Dieselben strukturierten Nachhaltigkeitsdaten stehen ohne erneute Dateneingabe sowohl für Variantenvergleiche als auch für das ESG-Reporting bereit.

Statische Berichte bilden Momentaufnahmen ab, während API-basierte Emissionsdaten dynamisch mit den Projektdaten wachsen.

Verschiedene Akteure im Bauwesen nutzen Emissionsdaten für unterschiedliche Zwecke. Eine zentrale Schnittstelle bedient über spezifische Integrationen die Anforderungen aller Projektbeteiligten.

Ein Fertigteilwerk verfügt über die präzisesten Daten zu den eigenen Produkten. Durch die Bereitstellung dieser Kennzahlen über eine Schnittstelle können Kunden aktuelle CO2-Werte direkt in ihre CAD- und BIM-Programme laden. Viele Hersteller binden diesen Zugriff in ein Kundenportal ein, über das Auftraggeber bautechnische Werte und CO2-Kennwerte an einem zentralen Ort abrufen können.

Bauunternehmer nutzen die API, um während der Bauphase die tatsächlichen Ist-Emissionen kontinuierlich mit der Kalkulation aus der Angebotsphase abzugleichen. Tägliche Verbrauchsdaten von Maschinen und Lieferscheine fließen direkt in die Schnittstelle ein. Abweichungen werden frühzeitig sichtbar, und Nachunternehmerdaten werden über dieselben strukturierten Schnittstellen integriert, statt unübersichtliche Tabellen per E-Mail auszutauschen.

Bauunternehmen können Baustellendaten und Lieferscheine während der Ausführung direkt mit der ursprünglichen CO2-Kalkulation abgleichen.

Ingenieurbüros führen die umfangreichsten Abfragen in der Vorplanung und Variantenentscheidung durch. Zwei Tragwerksentwürfe mit vergleichbaren Herstellkosten können sich in ihrer CO2-Bilanz erheblich unterscheiden – eine API-Abfrage quantifiziert diesen Unterschied in wenigen Minuten. NEXATEK bindet diese Berechnungsdienste direkt in die Analyse- und Bemessungssoftware ein, mit der Tragwerksplaner arbeiten.