API voor het berekenen van CO2-uitstoot

Elke betonstort, staallevering en draaiuur van een graafmachine op een infrastructureel project vertegenwoordigt een meetbare hoeveelheid CO2. Een carbon emissions API stelt deze waarden beschikbaar als gestructureerde data die direct kan worden opgevraagd door civieltechnische software. Zodra hoeveelheden wijzigen, veranderen de cijfers automatisch mee. NEXATEK ontwikkelt deze CO2-data-infrastructuur voor organisaties in de civiele techniek, veelal ingebed in een breder programma voor digitale transformatie. Op deze manier worden emissiegegevens direct ontsloten binnen de softwaresystemen die ingenieurs dagelijks gebruiken.

Een carbon emissions API zet projecthoeveelheden om in gestructureerde CO2-data die ingenieursteams integraal kunnen benutten.

Een carbon emissions API is een software-interface die projecthoeveelheden ontvangt en berekende emissiewaarden retourneert. Een applicatie verstuurt een request met de specificaties van een materiaal of handeling, bijvoorbeeld 450 m³ beton van sterkteklasse C30/37. De webservice koppelt deze invoer aan een database met emissiefactoren en retourneert de uitkomst in kilogram CO2-equivalent (kgCO2e). Er hoeft tijdens dit proces geen spreadsheet geopend te worden.

De interface centraliseert de rekenlogica voor emissieberekeningen voor de gehele organisatie. Elk project dat verbinding maakt, hanteert identieke factoren en uniforme eenheidsconversies. De aangesloten systemen variëren van BIM-plug-ins tot inkoopsoftware. Wijzigt er een factor, dan is die aanpassing direct actief voor alle aangesloten applicaties. In deze opzet fungeert een carbon footprint API als elke andere centrale technische voorziening: één centrale rekenmethode voor tal van onderliggende systemen.

Een snelwegknooppunt omvat duizenden emissierelevante posten: betonmengsels, wapeningsstaal, grondverzet en transportovereenkomsten. Elke post heeft zijn eigen emissiefactor, en veel van deze factoren fluctueren tijdens de looptijd van een project. Het handmatig bijhouden van deze dynamische datastroom is simpelweg niet schaalbaar.

Twee leveringen van dezelfde betonsterkteklasse kunnen een volstrekt andere CO2-voetafdruk hebben. Het mengselontwerp, de herkomst van het cement, de transportafstand en de betoncentrale zijn allemaal van invloed op het uiteindelijke cijfer. Vermenigvuldig die variatie met honderden materialen en meerdere uitvoeringsfasen, en de omvang van het dataprobleem wordt duidelijk.

Infrastructuurprojecten lopen bovendien vaak jarenlang door. Een emissiefactor die geldig was tijdens de aanbestedingsfase kan verouderd zijn op het moment dat het betreffende werkpakket definitief wordt ingekocht. Wijzigingen in het ontwerp zorgen voor extra verschuivingen: de overstap van een geprefabriceerd dek naar een in het werk gestort brugdek verandert de materiaalhoeveelheden én de transportafstanden gelijktijdig.

Emissiewaarden veranderen naarmate materialen, leveranciers, transportroutes en projectfasen wijzigen.

Spreadsheets volstaan voor een eenmalige raming, maar schieten tekort naarmate projecten in omvang en complexiteit toenemen. Veelvoorkomende foutbronnen zijn overschreven formules en emissiefactoren die klakkeloos uit eerdere projecten zijn overgenomen. Een eenheidsfout – bijvoorbeeld tonnen invoeren waar de formule uitgaat van kilo's – vertekent het resultaat met een factor 1.000 en blijft bij controles regelmatig onopgemerkt.

Versiebeheer is een tweede kwetsbaarheid. Wanneer vijf engineers elk een eigen kopie van een rekenbestand bijhouden, weet niemand welk getal de actuele status weergeeft. Door de berekening onder te brengen in één gedeelde centrale service verdwijnt deze onzekerheid. Dat is ook de reden dat CO2-monitoring vaak onderdeel uitmaakt van een breder traject voor procesoptimalisatie.

Een centrale API vermindert risico's rond versiebeheer door de rekenmethode op één centrale plek te borgen.

Emissiedata in de bouwsector valt uiteen in specifieke categorieën met verschillende databronnen en actualisatiefrequenties. Een carbon emissions API voor de bouw moet al deze categorieën kunnen verwerken om tot een dekkend totaalbeeld te komen. Vier categorieën omvatten de kern van vrijwel elk project.

De API moet data van materialen, transport, bouwactiviteiten en geaggregeerde projecttotalen gelijktijdig kunnen verwerken.

Bouwmaterialen vertegenwoordigen het overgrote deel van de ingebedde koolstof (embodied carbon) in civiele kunstwerken, met beton en constructiestaal als grootste componenten. De belangrijkste databron is de milieuproductverklaring (EPD / MRPI), een document waarin de fabrikant de emissies per functionele eenheid vastlegt. Door EPD-waarden per leverancier en materiaalkwaliteit gestructureerd op te slaan, wordt een vergelijking tussen twee staalleveranciers tijdens de inkoop gereduceerd tot een eenvoudige databasequery.

Het vervoer van 30 ton toeslagmaterialen over een afstand van 120 km levert via het spoor een heel andere footprint op dan over de weg. Transportemissies zijn afhankelijk van het vrachtgewicht, de af te leggen afstand, de vervoersmodaliteit en het type brandstof. Omdat routes en vervoerders tijdens de bouw geregeld wisselen, vormen transportgegevens een van de meest dynamische variabelen in het project.

Brandstofverbruik door bouwmaterieel en tijdelijke stroomvoorzieningen vormt het leeuwendeel van de uitstoot op de bouwplaats zelf. Relevante invoerdata bestaat uit draaiuren en verbruikte brandstofvolumes. Uitvoerders kunnen deze parameters registreren via mobiele applicaties voor dataverzameling of telemetriekoppelingen. Omgerekend per bouwactiviteit laten deze data exact zien welke uitvoeringsfasen de grootste impact hebben op de lokale CO2-uitstoot.

Het projectmanagement heeft behoefte aan een overkoepelend overzicht: geconsolideerde emissiedata per deelproject of rapportageperiode. Een betrouwbare aggregatie is alleen mogelijk wanneer alle onderliggende registraties dezelfde datastructuur delen. Dit is zowel een database-vraagstuk als een rekenkundige uitdaging. NEXATEK combineert de API dan ook doorgaans met databaseontwikkeling op maat, zodat sturingsinformatie op managementniveau gestoeld is op exact dezelfde fijnmazige invoergegevens die op de bouwplaats worden vastgelegd.

De datastroom door de voorziening is eenduidig: technische systemen voeden de service met hoeveelheden, waarna gestructureerde emissiewaarden worden geretourneerd. Bij NEXATEK start ieder integratietraject met twee fundamentele vragen: welke systemen leveren de invoerdata aan, en welke softwarepakketten moeten de resultaten verwerken?

Ingenieurssystemen leveren gestructureerde data aan de API en ontvangen uniforme kgCO2e-resultaten retour.

De benodigde invoer is afkomstig uit registraties die ingenieurs reeds bijhouden. Het bestek of de meetstaat levert materiaalclassificaties en volumes – veelal geëxporteerd vanuit een BIM-model. Inkoopsystemen vullen dit aan met leveranciersgegevens en uitvoeringssystemen leveren brandstofverbruiken aan. Elk API-verzoek bevat vier kernvelden: een artikelcode, een hoeveelheid, een eenheid en een projectreferentie. Verzoeken waarin een eenheid ontbreekt, worden direct door de interface geweigerd in plaats van aangevuld met aannames.

De webservice zoekt allereerst de juiste emissiefactor bij de artikelcode, waarbij leveranciersspecifieke EPD-waarden voorrang krijgen op generieke sectorgemiddelden. Daarna vindt datanormalisatie plaats: levert de ene producent beton aan in kubieke meters en de andere in tonnen, dan brengt een volumieke massa beide eerst naar dezelfde rekenbasis. De uitkomsten worden te allen tijde berekend in kgCO2e, wat data direct vergelijkbaar maakt over projecten en toeleveranciers heen.

Resultaten worden geretourneerd in een machineleesbaar formaat, standaard JSON. Elk ontvangend systeem kan deze CO2-data direct koppelen aan de eigen informatie: een kostendashboard toont emissies direct naast de uitgaven, een planningsapplicatie koppelt ze aan de mijlpalen. Opgeslagen in een centrale database blijft deze data ook na oplevering van het project doorzoekbaar, wat ten goede komt aan portfoliobrede milieu- en duurzaamheidsrapportages.

Beide benaderingen verschillen wezenlijk in de manier waarop zij omgaan met veranderingen. Op een actieve bouwplaats zijn wijzigingen aan de orde van de dag, en dit verschil openbaart zich dagelijks.

Een statisch rapport toont uitsluitend de stand van zaken op het moment van schrijven. Wijzigingen in het ontwerp of een leverancierswissel na die datum worden niet geregistreerd. Het actualiseren van de cijfers vereist een volledige herberekening. Een ingenieur die een CO2-arm alternatief voor een brugdek onderzoekt, moet dikwijls wachten op de volgende rapportagecyclus om het effect te zien. Ook de audit trail is kwetsbaar, omdat het verband tussen ruwe meetgegevens en de gerapporteerde totalen vaak alleen bestaat binnen één specifiek spreadsheetbestand.

API-gestuurde emissiedata herberekent de impact direct zodra de invoer wijzigt. Een aangepaste meetstaat resulteert nog dezelfde dag in geactualiseerde cijfers in plaats van pas bij het volgende rapportagemoment. De centrale, versiebeheerde rekenlogica biedt bovendien volledige herleidbaarheid: een auditor kan elk gepubliceerd cijfer direct herleiden naar de exacte factor en de specifieke invoer die eraan ten grondslag lagen. Dezelfde gestructureerde duurzaamheidsdata kan zonder herinvoer worden benut voor zowel ontwerpkeuzes als bedrijfsbrede ESG-verslaglegging.

Statische rapporten leggen één specifiek moment vast, terwijl API-data dynamisch meegroeit met veranderende projectdata.

De positie in de bouwketen bepaalt hoe CO2-data primair wordt benut. Eén centrale API-interface kan alle onderstaande rollen ondersteunen via specifieke koppelingen.

Een producent van prefab betonelementen beschikt over de meest accurate gegevens van de eigen producten. Door deze gegevens via een API te ontsluiten, kunnen afnemers actuele emissiewaarden op productniveau rechtstreeks in hun ontwerptools inladen. Veel producenten bieden deze toegang aan via een klantenportaal, waar opdrachtgevers technische specificaties en emissiedata op één centrale plek raadplegen.

Aannemers benutten de interface om tijdens de realisatie de werkelijke uitstoot te vergelijken met de raming uit de tenderfase. Brandstofregistraties en digitale afleverbonnen voeden de API op dagelijkse basis. Afwijkingen komen tijdig aan het licht zodat bijsturing mogelijk is. Gegevens van onderaannemers worden via dezelfde gestructureerde formulieren ingevoerd in plaats van via onsamenhangende Excel-bestanden per e-mail.

Aannemers kunnen materieellogboeken en vrachtbonnen tijdens de bouw direct afzetten tegen de oorspronkelijke CO2-begroting.

Ingenieursbureaus genereren de grootste datavolumes tijdens de variantenstudie en ontwerpfase. Twee alternatieven voor een dekconstructie met nagenoeg dezelfde bouwkosten kunnen een sterk uiteenlopende ingebedde CO2-waarde hebben. Een API-query maakt dat verschil binnen enkele minuten inzichtelijk. NEXATEK integreert deze rekenfuncties naadloos binnen de reken- en modelleersoftware die adviseurs dagelijks inzetten.