Att mäta är att veta, särskilt när det gäller CO₂-utsläpp. Sedan slutet av 1990-talet har organisationer strävat efter en enhetlig metod för att kartlägga deras fotavtryck. Detta gör data jämförbara och uppmuntrar till att vidta konkreta åtgärder för förbättring.

När det gäller grön mjukvara är det viktigt att förstå hur din organisations insatser bidrar till att minska energiförbrukningen och de tillhörande CO₂-utsläppen. De två sista principerna för grön mjukvara fokuserar därför på att mäta prestanda och fastställa mål för dessa prestanda. Målet är inte bara att mäta för att veta, utan också att mäta för att förbättra.

Princip 5 – Mäta ’Det du inte kan mäta, kan du inte förbättra’

Det mest kända sättet att rapportera CO₂-utsläpp är via Greenhouse Gas Protocol. Det är grunden för hur de flesta företag världen över mäter och presenterar sin CO₂-redovisning⁽¹⁾. För att verkligen implementera grön mjukvara och göra framsteg mot förbättringar är det viktigt att förstå vad protokollet innebär och säkerställa att din mjukvara är i linje med industristandarder.

Greenhouse Gas Protocol

Greenhouse Gas Protocol är resultatet av ett gemensamt initiativ från World Resources Institute (WRI) och World Business Council for Sustainable Development (WBSCD). Bakgrunden var den växande efterfrågan på en internationell standard för att mäta och presentera organisationers CO₂-fotavtryck.

Greenhouse Gas Protocol delar upp utsläpp av växthusgaser (emissioner) i tre grupper eller scopes⁽²⁾:

• Scope 1: Direkta utsläpp från den egna organisationen (t.ex. företagsfordon).
• Scope 2: Indirekta utsläpp från produktion av inköpt energi, såsom värme och elektricitet.
• Scope 3: Alla andra indirekta utsläpp, inklusive utsläpp från inköpta varor och tjänster, affärsresor, avfallshantering, investeringar, tillstånd etc. IT-utrustning och tjänster faller också inom denna scope. Specifikt för kultursektorn inkluderar detta även fysiska besök på läsesalar eller museer, liksom energiförbrukningen av webbplatsbesökare. Denna sista kategori är ofta svårast att beräkna för många organisationer, eftersom informationen behöver samlas in från många olika parter.

Om alla organisationer och människor världen över skulle hålla koll på sina utsläpp på detta sätt, skulle de totala utsläppen i scope 1 teoretiskt sett motsvara den globala utsläppen.

Greenhouse Gas Protocol har utvecklats vidare till specifika standarder för företag och regeringar, men också för att mäta policyer och handlingsplaner, projekt, produkter och städer. En av dessa är Corporate Standard som används av de flesta (stora) företag för att mäta växthusgasutsläpp.

Hur tillämpar du denna mätmetod på mjukvara?

För att beräkna den totala utsläppen från mjukvara behövs detaljerad information om energiförbrukning, CO₂-intensitet (sammansättningen av energimixen) och den använda hårdvaran. Det kan vara en utmaning att få denna information, särskilt för öppen källkodsprogramvara. Vem bär ansvaret för vilken del av utsläppen?

Noggrann mätning med mjukvarans CO₂-intensitetsspecifikation

Rapporteringen baserad på Greenhouse Gas Protocol ger värdefulla insikter i sammansättningen av dina utsläpp. Det är dock svårt att göra dina insatser för att göra din mjukvara grön mätbara med detta. För att hantera detta bättre har Green Software Foundation utvecklat en egen metod för att mäta mjukvarans utsläpp: Software Carbon Intensity Specification (SCI).

Syftet med SCI är att mäta mjukvarans hållbarhet. Baserat på resultatet kan en organisation vidta åtgärder för att minska mjukvarans utsläpp. Det är också möjligt att mäta effekten av förbättringar som har genomförts i mjukvaran, vilket uppmuntrar organisationer att fortsätta förbättra.

SCI ersätter inte GHG Protocol, utan fungerar som en kompletterande mätning. Jämförelsen som Green Software Foundation gör är träffande: SCI är som att mäta bränsleeffektiviteten per körd kilometer, medan GHG Protocol anger den totala CO₂-fotavtrycket för en biltillverkare och alla deras tillverkade bilar under ett år. SCI är alltså en mer specifik kugge i det större maskineriet.

SCI följer inte indelningen av scopes 1 – 3 för CO₂-utsläpp, utan grupperar dem i operationella utsläpp (de utsläpp som orsakas av att mjukvaran körs) och inbäddade utsläpp (de utsläpp från hårdvaran som behövs för att mjukvaran ska fungera).

I tidigare bloggar om grön mjukvara har vi sett att förbättring av både energieffektivitet och hårdvarueffektivitet samt CO₂-medvetenhet i din applikation har en positiv effekt. Detta återspeglas också i din SCI-poäng, som går ner. Detta är också det enda sättet att sänka poängen. Du måste verkligen agera. SCI kan inte manipuleras genom att köpa CO₂-utsläpp. Om en organisation inte gör konkreta ansträngningar för att minska utsläppen, kommer den inte att få en bra SCI-poäng.

För de matematiska detaljerna i denna metod hänvisas gärna till Green Software Foundations webbplats, där metoden förklaras i detalj, inklusive riktlinjerna för hur projekt ska avgränsas och hur du redovisar.

Princip 6 – Klimatåtaganden ’Att minska CO₂-utsläpp är inte detsamma som att kompensera’

Vi har kommit till den sista principen för grön mjukvara: din organisations klimatmål. Slutligen ska insatserna inom grön mjukvara bidra till att minska dina CO₂-utsläpp. Hur ambitiös du är i detta beror på ditt företags val. Vissa organisationer strävar efter ’net zero’, medan andra går för ’CO₂-neutral’ eller till och med ’CO₂-negativ’. Men vad betyder dessa termer egentligen?

Olika sätt att minska utsläppen

Science Based Targets (SBT) är mål baserade på vetenskapliga insikter. Genom att arbeta med dessa mål vet du om dina mål (med tanke på din organisations natur och omfattning) är tillräckliga för att uppnå Parisavtalet. Dessa mål delas in i tre kategorier:

• CO₂-reduktion – det mest effektiva sättet att bekämpa klimatförändringarna.
• CO₂-undvikelse – användning av förnybara energikällor, livsstilsförändringar, återvinning och trädplantering.
• CO₂-borttagning – att ta bort och permanent lagra koldioxid från atmosfären för att neutralisera effekten av CO₂-utsläpp.

Organisationer kan sträva efter olika mål, till exempel:

• CO₂-neutral: de totala utsläppen är lika med den totala mängden v-kompensationer genom reduktionsprojekt.
• Netto noll: en organisation fokuserar på att eliminera CO₂-utsläpp så mycket som möjligt och kompenserar endast för de kvarvarande utsläppen som inte kan elimineras.

Europeiska kommissionen har satt som mål att vara ’net zero’ till 2050. Alla åtgärder som vidtas av EU medlemsländer måste därför slutligen leda till detta mål. Vi som organisationer etablerade i EU måste också bidra till detta!

Sätt igång

Oavsett vilket mål du väljer kan grön mjukvaruutveckling spela en viktig roll. Grön mjukvara strävar alltid efter maximal minskning av utsläpp, med energieffektivitet, hårdvarueffektivitet och CO₂-medvetenhet som kärnprinciper. I denna bloggserie har du fått praktiska verktyg för att börja arbeta med dessa ämnen.

Om du själv inte är mjukvaruingenjör, här är de frågor sammanfattade som du kan använda för att inleda samtal med utvecklare eller leverantörer:

• Hur kan den använda utrustningen belastas så effektivt som möjligt (energieffektivitet)?
• Hur kan statisk strömförbrukning undvikas så mycket som möjligt?
• Vad är förhållandet mellan grön och grå el i vår energimix? (CO₂-intensitet)
• Hur kan vi minska CO₂-intensiteten? Vilka möjligheter finns för att flytta efterfrågan (annan plats, annan tid) eller anpassa den till utbudet?
• Hur kan livslängden på den använda hårdvaran förlängas?

Genom att ta hänsyn till dessa frågor kan du minska CO₂-utsläppen relaterade till mjukvara. Vill du mäta effekten av dina insatser, beräkna då SCI-poängen.