API til beregning af CO2-emission

Hver eneste betonstøbning, stålleverance og gravemaskinetime på et infrastrukturprojekt har en målbar CO2-værdi. Et carbon emissions API stiller disse værdier til rådighed som strukturerede data, som ingeniør- og projekteringssoftware kan forespørge direkte på efter behov. Når mængderne ændrer sig, følger tallene automatisk med. NEXATEK opbygger denne form for CO2-datainfrastruktur for anlægsorganisationer, typisk som led i et bredere program for digital transformation. Dermed integreres emissionsdata direkte i de værktøjer, ingeniørerne allerede anvender.

Et carbon emissions API konverterer projektmængder til strukturerede klimadata, som ingeniørteams kan anvende på tværs af deres systemer.

Et carbon emissions API er en softwaregrænseflade, der modtager projektmængder og returnerer beregnede emissionsværdier. En applikation sender en forespørgsel med specifikationer for et materiale eller en aktivitet, for eksempel 450 m³ beton af styrkeklasse C30/37. Tjenesten matcher dataene med en database over emissionsfaktorer og returnerer et resultat angivet i kilo CO2-ækvivalenter (kgCO2e). Ingen regneark behøver at blive åbnet i processen.

Grænsefladen samler beregningslogikken for hele organisationens CO2-opgørelser. Alle projekter, der kalder servicen, modtager identiske faktorer og ensartede enhedskonverteringer. Klienterne spænder fra BIM-plugins til indkøbssystemer. Når en faktor opdateres, slår ændringen igennem i samtlige tilkoblede systemer på én gang. Anvendt på denne måde fungerer et CO2-aftryks-API som enhver anden fælles ingeniørtjeneste: én beregningsmetode, mange tilkoblede brugersystemer.

Et motorvejskryds involverer tusindvis af CO2-relevante poster: betonrecepter, armeringsstål, jordarbejder og vognmandskontrakter. Hver enkelt post har sin egen emissionsfaktor, og mange af disse faktorer ændrer sig i løbet af projektperioden. Manuel overvågning af så dynamiske datasæt kan ikke skaleres.

To leverancer af den samme betonkvalitet kan have markant forskelligt CO2-aftryk. Recepturen, cementkilden, transportafstanden og værket påvirker alle det endelige resultat. Ganger man denne variation med hundredvis af materialer og adskillige byggefaser, bliver datamængdens omfang tydeligt.

Infrastrukturprojekter strækker sig ofte over flere år. En emissionsfaktor, der var gældende i udbudsfasen, kan være forældet, når den pågældende fagentreprise skal kontraheres. Projektændringer skaber yderligere forskydninger: Et skifte fra præfabrikerede brodragere til pladsstøbt beton ændrer både materialemængder og transportafstande samtidigt.

Emissionsværdier ændrer sig løbende i takt med skiftende materialer, leverandører, transportruter og projektfaser.

Regneark fungerer fint til et enkeltstående estimat, men mister hurtigt overblikket i takt med projektets vækst. Hyppige fejlkilder er overskrevne formler og emissionsfaktorer, der ukritisk kopieres fra ældre projekter. En simpel enhedsfejl – eksempelvis tons indtastet, hvor formlen forudsætter kilo – forstørrer resultatet med en faktor 1.000 og kan overleve flere faglige gennemgange uden at blive opdaget.

Versionsstyring er en anden svaghed. Hvis fem rådgivere sidder med hver sin kopi af beregningsfilen, er det umuligt at fastslå, hvilket tal der er det gældende. Ved at flytte beregningen over i en central tjeneste elimineres denne usikkerhed, hvilket er grunden til, at CO2-sporing ofte implementeres som led i en bredere procesoptimering.

Et centralt API minimerer risici ved versionsstyring ved at forankre beregningsmetoden ét samlet sted.

Emissionsdata inden for bygge og anlæg falder i distinkte kategorier med forskellige kilder og opdateringsintervaller. Et carbon emissions API til byggeriet skal kunne håndtere samtlige kategorier for at levere en samlet projektstatus. Fire kategorier dækker langt de fleste projekter.

API'et skal kunne håndtere data for materialer, transport, byggepladsaktiviteter og det samlede projekt under ét.

Byggematerialer udgør hovedparten af det indlejrede CO2-aftryk (embodied carbon) i de fleste anlægskonstruktioner, med beton og stål i spidsen. Den primære datakilde er miljøvaredeklarationer (EPD'er) – leverandørpublicerede dokumenter, der dokumenterer emissionerne for fremstillingen af en bestemt enhed af produktet. Når EPD-værdier struktureres pr. leverandør og materialekvalitet, bliver en sammenligning mellem to stålleverandører i indkøbsfasen til en hurtig dataforespørgsel.

Vejtransport af 30 tons tilslagsmaterialer over 120 km har et væsentligt anderledes klimaaftryk end samme transport udført med godstog. Transportemissioner afhænger af lastens vægt, transportdistance, transportform og brændstoftype. Da ruter og speditører ofte ændres undervejs i udførelsen, udgør transportdata en af de mest dynamiske parametre i projektets miljøregnskab.

Brændstofforbrug i entreprenørmateriel og midlertidig strømforsyning tegner sig for hovedparten af emissionerne på selve byggepladsen. Relevante inputparametre er maskindriftstimer og brændstofmængder, som byggeledelsen kan registrere via mobile dataindsamlingsværktøjer eller telemetriløsninger. Omregnet pr. arbejdsgang viser disse registreringer præcist, hvilke faser der driver pladsens klimabelastning.

Ledelsen har behov for det konsoliderede overblik. Det indebærer samlede infrastrukturdata opgjort pr. delprojekt eller rapporteringsperiode. En pålidelig aggregering forudsætter, at samtlige underliggende registreringer deler den samme datastruktur – hvilket stiller krav til såvel databasedesign som beregningslogik. NEXATEK kombinerer typisk API'et med skræddersyet databaseudvikling, så aggregerede nøgletal hviler på de samme detaljerede registreringer, som ingeniørerne genererer på pladsen.

Dataflowet gennem tjenesten er lineært: Ingeniørsystemer sender mængder ind, og strukturerede emissionsværdier returneres. Hos NEXATEK indledes integrationsarbejdet altid med to konkrete spørgsmål: Hvilke systemer leverer rådata, og hvilke platforme skal aftage resultaterne?

Ingeniørsystemer overfører strukturerede input til API'et og modtager konsistente kgCO2e-resultater retur.

Inputdata hentes direkte fra de registreringer, rådgivere og entreprenører allerede foretager. Tilbudslister og mængdefortegnelser leverer materialetyper og volumener – ofte udtrukket direkte fra en BIM-model – mens indkøbssystemer tilfører leverandøroplysninger, og pladssystemer bidrager med brændstoflogfiler. Hvert API-kald indeholder fire standardfelter: varekode, mængde, enhed og projektreference. Forespørgsler med manglende enheder afvises automatisk i grænsefladen frem for at basere sig på upålidelige standardantagelser.

Første trin er datamatching. Tjenesten identificerer den korrekte emissionsfaktor ud fra varekoden og prioriterer leverandørspecifikke EPD-værdier over generiske regionale gennemsnit. Dernæst følger datanormalisering: Hvis én leverandør opgiver beton i kubikmeter og en anden i tons, sikrer en densitetsfaktor, at begge bringes på samme beregningsgrundlag. Outputværdierne returneres altid i kgCO2e, hvilket gør resultaterne direkte sammenlignelige på tværs af projekter og leverandører.

Resultaterne leveres i et maskinlæsbart format, typisk JSON. Ethvert tilkoblet system kan dermed placere CO2-data direkte ved siden af sine egne nøgletal: Et økonomidashboard viser emissioner side om side med omkostninger, og tidsstyringsværktøjet kobler dem til tidsplanen. Gemt i en central database forbliver dataene tilgængelige for analyser efter projektets aflevering, hvilket styrker den samlede porteføljerapportering.

De to metoder adskiller sig markant i deres evne til at håndtere ændringer. På et aktivt anlægsprojekt er forandringer et grundvilkår, og forskellen mærkes i den daglige drift.

En statisk rapport afspejler udelukkende projektets tilstand på den dag, den blev forfattet. Projektændringer og leverandørskift, der indtræffer efter denne dato, registreres ikke. Skal tallene ajourføres, kræver det en gentagelse af hele beregningsarbejdet. Hvis en ingeniør ønsker at teste en CO2-optimeret løsning for et brodæk, må vedkommende ofte afvente næste rapporteringscyklus for at se effekten. Revisionssporet svækkes tilsvarende, da koblingen mellem rådata og slutresultat ofte kun eksisterer i ét lokalt regneark.

API-baserede løsninger genberegner emissionsdata i samme øjeblik, inputdataene ændrer sig. En revideret mængdefortegnelse resulterer i opdaterede tal samme dag i stedet for ved næste rapporteringsmilepæl. Den centraliserede og versionsstyrede beregningslogik giver desuden fuld sporbarhed: En auditor kan spore ethvert publiceret tal direkte tilbage til den specifikke faktor og de mængder, der ligger til grund for beregningen. De samme strukturerede data understøtter både projekteringsgranskninger og virksomhedens bæredygtighedsrapportering uden behov for gentagen dataindtastning.

Statiske rapporter viser et fastfrosset øjebliksbillede, mens API-baserede data opdateres dynamisk i takt med projektets udvikling.

Byggeriets parter efterspørger CO2-data ud fra vidt forskellige behov. Én fælles servicegrænseflade kan understøtte alle nedenstående roller via målrettede integrationer.

En betonelementproducent råder over de mest præcise data om sine egne produkter. Ved at udstille disse data via et API kan kunder hente aktuelle CO2-værdier på produktniveau direkte ind i deres projekteringsværktøjer. Mange producenter stiller denne adgang til rådighed via en kundeportal, hvor rådgivere og entreprenører kan tilgå tekniske specifikationer og miljødata samlet.

Entreprenører anvender API'et til løbende at sammenholde faktiske emissioner med det oprindelige udbudsestimat under udførelsen. Maskinernes brændstofforbrug og følgesedler fra leverancer indføres dagligt i systemet. Eventuelle afvigelser opdages i tide til, at der kan reageres, og underentreprenørers data indberettes via de samme strukturerede grænseflader frem for via spredte regneark i indbakken.

Entreprenører kan løbende sammenholde brændstoflogfiler og leverancedata med det oprindelige CO2-estimat under udførelsen.

Rådgivende ingeniører udfører de mest beregningstunge forespørgsler i den tidlige designfase under valg af koncept og konstruktionsprincipper. To brodæksudformninger med sammenlignelige anlægsøkonomier kan have vidt forskelligt indlejret CO2-aftryk. En API-forespørgsel kvantificerer denne forskel på få minutter. NEXATEK integrerer disse beregningstjenester direkte med de beregnings- og modelleringsværktøjer, rådgiverne anvender i det daglige arbejde.