API för beräkning av CO₂-utsläpp

Varje betonggjutning, stålleverans och maskintimma med grävmaskin på ett infrastrukturprojekt bär på ett mätbart koldioxidvärde. Ett carbon emissions API gör dessa värden tillgängliga som strukturerad data som anläggnings- och projekteringsprogram kan göra anrop mot vid behov. När mängderna ändras uppdateras siffrorna automatiskt. NEXATEK utvecklar denna typ av data-infrastruktur för koldioxiddata åt anläggningsorganisationer, oftast som en integrerad del i ett bredare program för digital transformation. Därigenom integreras utsläppssiffrorna direkt i de programvaror ingenjörerna redan använder i det dagliga arbetet.

Ett carbon emissions API omvandlar projektmängder till strukturerad klimatdata som ingenjörsteam kan använda i alla sina system.

Ett carbon emissions API är ett programvarugränssnitt som tar emot projektmängder och returnerar beräknade utsläppsvärden. En applikation skickar en förfrågan som specificerar ett material eller en aktivitet, till exempel 450 m³ betong av hållfasthetsklass C30/37. Tjänsten matchar indata mot en databas med emissionsfaktorer och returnerar resultatet uttryckt i kilogram koldioxidekvivalenter (kgCO2e). Inget kalkylark behöver öppnas under hela processen.

Gränssnittet centraliserar beräkningslogiken för utsläppskalkyler för hela organisationen. Samtliga projekt som anropar tjänsten får tillgång till identiska faktorer och enhetliga enhetsomvandlingar. Klienterna varierar från BIM-plugins till inköpssystem. När en faktor uppdateras slår förändringen igenom hos alla konsumenter samtidigt. Använt på detta sätt fungerar ett API för klimatavtryck som vilken annan central teknisk stödtjänst som helst: en och samma beräkningsmetod för många anslutna klientsystem.

En motorvägsmot omfattar tusentals utsläppsrelevanta poster: betongrecept, armeringsstål, schaktningsarbeten och transportavtal. Varje enskild post har sin egen emissionsfaktor, och många av dessa faktorer förändras under projektets gång. Att hantera och följa upp en så föränderlig datamängd manuellt är inte skalbart.

Två leveranser av samma betongkvalitet kan ha helt olika koldioxidvärden. Receptutformningen, cementfabriken, transportavståndet och själva betongfabriken påverkar alla slutresultatet. Multipliceras denna variation med hundratals material och ett flertal byggskeden blir dataproblemets omfattning snabbt uppenbar.

Infrastrukturprojekt pågår dessutom under flera år. En emissionsfaktor som gällde under anbudsskedet kan vara inaktuell när det aktuella arbetsmomentet ska upphandlas. Projekteringsändringar skapar ytterligare förskjutningar: att övergå från prefabricerade brobalkar till platsgjuten betong förändrar både materialvolymer och transportavstånd parallellt.

Utsläppsvärden förändras kontinuerligt när material, leverantörer, transportvägar och projektfaser ändras.

Kalkylblad fungerar utmärkt för en enskild överslagsberäkning men förlorar snabbt sin bärkraft när projekten växer. Vanliga felkällor är överskrivna formler och emissionsfaktorer som kopierats från gamla projekt. Ett enhetsfel – till exempel att ton anges där formeln förutsätter kilo – multiplicerar resultatet med en faktor 1 000 och kan passera flera granskningar utan att upptäckas.

Versionshantering är en annan kritisk svaghet. Om fem ingenjörer har varsin lokal kopia av beräkningsfilen är det omöjligt att avgöra vilket resultat som är gällande. Genom att flytta beräkningen till en gemensam central tjänst elimineras denna osäkerhet, vilket är anledningen till att utsläppsuppföljning ofta införs som ett led i en bredare arbetsflödesoptimering.

Ett gemensamt API minimerar riskerna med versionshantering genom att samla beräkningsmetoden på ett och samma ställe.

Utsläppsdata inom byggsektorn kan delas in i tydliga kategorier med olika datakällor och uppdateringsintervall. Ett carbon emissions API för bygg och anläggning måste hantera samtliga kategorier för att ge en heltäckande projektbild. Fyra områden täcker merparten av projekten.

API:et måste hantera data för material, transporter, arbetsplatsaktiviteter och sammanställd projektnivå samtidigt.

Byggmaterial står för huvuddelen av den inbäddade koldioxiden (embodied carbon) i de flesta anläggningskonstruktioner, där betong och konstruktionsstål oftast toppar listan. Den viktigaste datakällan är miljövarudeklarationer (EPD:er) – leverantörsredovisade dokument som anger utsläppen per funktionell enhet av produkten. Genom att strukturera EPD-värden per leverantör och materialkvalitet blir en jämförelse mellan två stålleverantörer under upphandlingen en snabb datafråga.

Att transportera 30 ton ballastmaterial en sträcka på 120 km ger ett helt annat koldioxidavtryck med järnväg jämfört med lastbil. Transportutsläpp beror på lastvikt, körsträcka, transportslag och bränsleslag. Eftersom rutter och transportörer ändras under produktionstiden hör material- och transportdata till projektets mest dynamiska parametrar.

Bränsleförbrukning i arbetsmaskiner och tillfällig elförsörjning står för den största delen av utsläppen på själva byggarbetsplatsen. Relevanta indata är maskindrifttimmar och bränslevolymer, som byggledningen kan samla in via mobila fältverktyg för datainsamling eller telematiksystem i maskinerna. Omräknat per arbetsmoment åskådliggör dessa mätdata vilka produktionsfaser som driver arbetsplatsens utsläpp.

Företags- och projektledningen behöver den aggregerade helhetsbilden: anläggningsspecifik koldioxiddata summerad per delprojekt eller per rapporteringsperiod. En tillförlitlig aggregering förutsätter att samtliga underliggande dataposter delar en och samma struktur – en utmaning som ställer lika höga krav på databasdesign som på beräkningslogik. NEXATEK kombinerar vanligen API:et med skräddarsydd databasutveckling, så att överordnade nyckeltal bygger på exakt samma detaljerade registreringar som platsorganisationen upprättar i fält.

Dataflödet genom tjänsten är enkelriktat: projektprogramvaror skickar in mängder och aktiviteter, och strukturerade utsläppsvärden returneras. Hos NEXATEK inleds integrationsarbetet med två konkreta frågor: vilka system ska leverera indata, och vilka system ska ta emot och presentera resultaten?

Ingenjörssystem skickar strukturerad data till API:et och tar emot enhetliga kgCO2e-resultat i retur.

Indata hämtas ur underlag som ingenjörer redan upprättar. Mängdförteckningar tillhandahåller materialtyper och volymer – ofta exporterade direkt från en BIM-modell. Inköpssystem bidrar med leverantörsidentiteter och produktionssystem med bränsleloggar. Varje anrop innehåller fyra obligatoriska fält: artikel- eller materialkod, mängd, enhet och projektreferens. Anrop där enhet saknas avvisas automatiskt i gränssnittet i stället för att programmet gör osäkra antaganden.

Matchningen sker först. Tjänsten söker upp emissionsfaktorn för den aktuella artikelkoden och prioriterar leverantörsspecifika EPD-värden framför regionala schabloner. Därefter sker datanormalisering: om en leverantör anger betong i kubikmeter och en annan i ton ser en densitetsfaktor till att båda omvandlas till en likvärdig beräkningsgrund. Svaret levereras genomgående i kgCO2e, vilket gör resultaten direkt jämförbara mellan projekt och leverantörer.

Resultaten levereras i ett maskinläsbart format, vanligen JSON. Vilket anslutet system som helst kan placera klimatdata intill sina egna parametrar: en kostnadsöversikt visar utsläpp bredvid kostnader, ett tidplaneringsverktyg intill tidsplanen. Genom att sparas i en central databas förblir informationen sökbar även efter projektets slutbesiktning, vilket stödjer portföljövergripande hållbarhetsrapportering.

De två strategierna skiljer sig fundamentalt i hur de hanterar förändringar. På ett pågående anläggningsprojekt är förändringar ett normalläge, och skillnaden gör sig påmind varje dag.

En statisk rapport beskriver projektets förutsättningar precis som de såg ut det datum den sammanställdes. Ändrade konstruktionslösningar och leverantörsbyten som sker därefter registreras inte. För att uppdatera siffrorna måste hela beräkningskedjan köras om från början. En ingenjör som utvärderar ett brodäcksalternativ med lägre koldioxidavtryck tvingas därför ofta invänta nästa rapporteringscykel för att se resultatet. Spårbarheten försämras också, då kopplingen mellan rådata och det publicerade slutvärdet ofta bara existerar i ett enskilt kalkylark.

API-baserad utsläppsdata beräknas om automatiskt så fort indata förändras. En reviderad mängdförteckning genererar uppdaterade klimatsiffror samma dag i stället för vid nästa formella rapporteringstillfälle. Centraliserad, versionshanterad beräkningslogik ger därtill full transparens: en revisor kan spåra varje publicerad siffra tillbaka till den exakta faktor och de indata som skapade den. Samma strukturerade hållbarhetsdata kan användas för projekteringsgranskningar såväl som hållbarhetsredovisning på koncernnivå utan manuell dubbelregistrering.

Statiska rapporter visar ett ögonblicksläge, medan API-baserad data uppdateras dynamiskt i takt med att projektets förutsättningar ändras.

Placeringen i värdekedjan styr hur koldioxiddata bäst tillvaratas. Ett och samma gränssnitt kan stödja samtliga aktörer nedan via ändamålsenliga integrationer.

En tillverkare av prefabricerade betongelement förfogar över den mest exakta datan om sina egna produkter. Genom att publicera dessa data via ett API kan beställare och projektörer hämta aktuella klimatvärden på produktnivå direkt in i sina CAD- och BIM-verktyg. Många tillverkare erbjuder denna åtkomst via en kundportal där beställare samlat kan hämta tekniska data och miljöprestanda.

För entreprenörer fungerar API:et som ett verktyg för att löpande jämföra faktiska utsläpp mot anbudskalkylen under produktionstiden. Maskinernas bränsleloggar och leverantörernas följesedlar matas in i systemet dagligen. Avvikelser upptäcks tillräckligt tidigt för att korrigerande åtgärder ska kunna vidtas, och underentreprenörernas siffror rapporteras via samma strukturerade formulär snarare än via lösryckta Excel-filer i e-posten.

Entreprenörer kan löpande under byggtiden stämma av arbetsplatsens bränsleloggar och leveranssedlar mot den ursprungliga koldioxidkalkylen.

Konstruktörer och projektörer gör de tyngsta beräkningarna i tidiga skeden vid val av system och stomlösning. Två brobaneutformningar med likvärdig anläggningskostnad kan skilja sig markant vad gäller inbäddad koldioxid, och ett API-anrop kvantifierar den skillnaden på några minuter. NEXATEK kopplar dessa beräkningstjänster direkt till de analys- och beräkningsverktyg konstruktörerna använder dagligen.