När du anpassar plats eller tidpunkt anpassar du efterfrågan till energiutbudet, men det kan också göras tvärtom. Du kan välja att anpassa efterfrågan till kolintensiteten (utbudet). På så sätt ökar du efterfrågan genom att utföra fler aktiviteter när kolintensiteten är låg, medan du utför färre aktiviteter när kolintensiteten är hög.

Ecomodus, som är känt från tillämpningar som bilar och tvättmaskiner, kan aktiveras när kolintensiteten är hög. Då offrar du en del prestanda för att använda färre resurser. Till exempel, om bandbredden är fullt utnyttjad, kanske besökaren på din webbplats inte kan se vissa bilder.

Ett annat exempel från vardagen är den automatiska anpassningen av streamingkvalitet i videokonferensprogramvara. Istället för att konstant strömma på högsta möjliga kvalitet (upplösning) anpassar programvaran videokvaliteten och prioriterar ljudet. Detta sker när bandbredden är låg på grund av intensivt användande av internet av många personer samtidigt.

Att sträva efter enkelhet

Demand shaping är kopplat till ett bredare hållbarhetsbegrepp, nämligen att minska konsumtionen. Även om vi kan uppnå mycket genom att vara mer medvetna om energiresurserna, har vi också ansvar att faktiskt använda mindre.

Det är också viktigt att dämpa slutanvändarnas förväntningar. Är en instruktionsvideo verkligen nödvändig på din webbplats, eller skulle en skriftlig eller talad instruktion med mindre CO₂-avtryck vara tillräcklig? Behöver varje webbsida innehålla en högupplöst bild, eller skulle en lättare bild, eller till och med ingen bild alls, vara tillräcklig? I den sista bloggserien av den här Grön IT-serien kommer vi att fördjupa oss mer i dessa användardilemman.

Användning av så ren kod som möjligt

Strävan efter enkelhet gäller särskilt för mjukvarukod. Programvaru­programmering har genom åren förändrats avsevärt på grund av ökad processorhastighet och tillgång till mer minne, vilket nästan har eliminerat begränsningar för programutvecklare.⁽⁷⁾

Detta står i kontrast till datorprogram för kanske tio till tjugo år sedan, där programmerare var tvungna att vara mycket medvetna om sin kod för att undvika att programvaran blev för tung och därigenom försämrade användarupplevelsen (långsam reaktion, långsam laddning osv.). Även om dessa begränsningar ibland var utmanande, tvingade de programmerare att koda mycket noggrant, vilket resulterade i energieffektivare kod.

Nu när möjligheterna att programmera mjukvara är oändliga, märker vi att det ibland programmeras “slarvigare”. Detta beror också på hastigheten med vilken programvara utvecklas. Om mer tid togs för mer noggrann programmering skulle det leda till lägre energiförbrukning. Det är inte heller nödvändigt längre att känna till ett specifikt programmeringsspråk. Detta leder ofta till att den använda koden är “förorenad” med onödiga element, vilket resulterar i högre energiförbrukning än nödvändigt.

An Archive of Awesome and Dark Tactics

Från mjukvarugemenskapen har flera initiativ startats för att utveckla och dela grön kod. Forskare vid Vrije Universiteit Amsterdam har till exempel lanserat Archive of Awesome and Dark Tactics, ett onlinearkiv för hållbar mjukvaruutveckling. Detta arkiv är fritt tillgängligt för alla och bygger på principer för öppen källkod. Det syftar till att informera, inspirera och dela bästa praxis med alla som är involverade i övergången till digital hållbarhet.⁽⁸⁾

Också Green Software Foundation har en katalog på sin webbplats med mjukvarukoder som hjälper till att begränsa utsläppen från mjukvara (specifikt med en länk till artificiell intelligens).⁽⁹⁾

Ett annat värdefullt initiativ finns på Green Web Foundations webbplats. De har utvecklat verktyg för att mäta utsläppen från mjukvara, inklusive CO2.js, ett skript som låter dig uppskatta utsläppen från appar, webbplatser och mjukvara med hjälp av en JavaScript-bibliotek. Dessutom erbjuder de Grid Intensity CLI som låter dig mäta hur kolintensiv mjukvarukoden är som körs.⁽¹⁰⁾

Ett energimärke för mjukvara?

När du läser detta verkar det logiskt att det skulle finnas ett energimärke för mjukvaruprodukter. Då kan du som användare välja den mest energieffektiva produkten. Tyvärr är detta inte genomförbart inom mjukvarubranschen. Det finns helt enkelt för många variabler annat än själva koden som påverkar energiförbrukningen av mjukvara. Detta berättar Bernard van Gastel, universitetslektor i hållbar digitalisering vid Radboud Universitet, i ett webinarium från yrkesorganisationen KNVI.⁽¹⁰⁾

Energiförbrukningen av mjukvara beror för mycket på användningen, och inte alla använder sin dator på samma sätt. Bernard van Gastel säger att han inte skulle veta hur man skapar ett energimärke för Word eller Excel. Även för kylskåp finns det redan sju olika märken, eftersom energiförbrukningen för ett amerikanskt kylskåp är väldigt annorlunda jämfört med ett bordskylskåp.

Mjukvara är så generisk jämfört med kylskåp att det blir omöjligt att tilldela ett märke. Om du skulle vilja göra det måste du specifikt titta på hur användaren använder mjukvaran (ibland utvecklas programvaran med ett visst syfte i åtanke men används av användare för ett helt annat ändamål), hur intensivt den används och med vilken hårdvara mjukvaran körs. Du måste därför alltid titta specifikt på din situation för att minska energiförbrukningen från din mjukvara.

Slutsats

I den här bloggen har vi sett att minskningen av CO₂-utsläpp är nära relaterad till en noggrann bedömning av elutbudet. Om det finns mer grå energi än grön energi tillgänglig kan du välja att flytta din efterfrågan (demand shifting). Detta kan göras genom att flytta din arbetsbelastning till en annan geografisk plats eller utföra den vid en annan tidpunkt.

Ett annat alternativ är att anpassa efterfrågan efter utbudet av grön energi vid den specifika tiden. Detta kallas “demand shaping”. Till exempel, när efterfrågan är hög, kan du minska kvaliteten på din videokonferens för att minska energiförbrukningen, vilket inte skulle ske om efterfrågan var lägre.

Slutligen har vi sett att för en betydande minskning av CO₂-utsläpp måste du specifikt granska mjukvarukoden för att se till att det inte används onödig kod som ökar energiförbrukningen. Tyvärr kan detta inte åstadkommas genom att tilldela energimärken till mjukvara, utan du måste alltid titta specifikt på situationen för att identifiera förbättringsområden.

I nästa blogg kommer vi att undersöka det fjärde principen för grön mjukvara: hårdvarueffektivitet.