Introductie: Waar gaat dit over?

Dit handboek geeft een kort overzicht van de milieuschade veroorzaakt door software, en hoe het Blauwe Engel-ecolabel—het officiële milieulabel van de Duitse overheid—een maatstaf vormt voor duurzaam softwareontwerp.

De Blue Angel wordt toegekend aan een reeks producten en diensten, van huishoudelijke schoonmaakmiddelen tot kleine huishoudelijke apparaten en bouwproducten. In 2020 heeft het Duitse Milieuagentschap de criteria voor de toekenning uitgebreid met softwareproducten. Het was de eerste milieucertificering ter wereld die transparantie en gebruikersautonomie—twee pijlers van Free & Open Source Software (FOSS) – koppelde aan duurzaamheid.

U vraagt zich nu misschien af: wat heeft duurzaamheid nu eigenlijk met software te maken? Hoe kan iets dat zo immaterieel lijkt als software een ecologische voetafdruk hebben? In dit handboek bekijken we een aantal manieren waarop software bijdraagt ​​aan de klimaatcrisis en hoe het voldoen aan de criteria van de Blue Angel Award voor software-ecocertificering hierbij kan helpen.

Het boek is opgedeeld in drie delen:

• Deel I: De milieu-impact van software
• Deel II: Eco-certificering van bureaubladsoftware
• Deel III: Voldoen aan de criteria voor de Blue Angel Award

Deel I onderzoekt het waarom en deel II het wat van software-ecocertificering. In deel III wordt het hoe besproken door uit te leggen wat u moet weten om het energieverbruik van uw software te meten en het Blue Angel-ecolabel aan te vragen. In dit deel geven we een stapsgewijze handleiding voor het voldoen aan de ABC's van de criteria: (A) Resource- & Energie-efficiëntie, (B) Potentiële levensduur van de hardware en (C) Gebruikersautonomie.

Deel I: De milieu-impact van software

In 2021 publiceerde de Association of Computing Machinery (ACM), de oudste wetenschappelijke en educatieve computervereniging ter wereld, een rapport van de Technology Policy Council getiteld “Computing And Climate Change”. Het rapport onderzoekt onder andere de exponentiële toename van het energie- en grondstoffenverbruik van kunstmatige intelligentie en internetgekoppelde apparaten, zowel in productie als in gebruik. De schattingen in het rapport zijn verbijsterend. Alleen al in 2021 zal de informatie- en communicatietechnologiesector (ICT) naar schatting tussen de 1,8 en 3,9% van de wereldwijde koolstofemissies bijdragen. Ter vergelijking: dit is vergelijkbaar met de wereldwijde luchtvaartindustrie, die naar schatting 2,5% van alle emissies voor haar rekening neemt. Het rapport waarschuwt dat als er niets verandert, de koolstofemissies die aan de ICT-sector kunnen worden toegeschreven in 2050 zullen oplopen tot meer dan 30% van alle wereldwijde emissies.

![Twee grafieken die (links) de broeikasgasemissies van de luchtvaartindustrie in blauw vergelijken met die van de ICT-sector in groen, en (rechts) de verwachte emissies van de ICT-sector in 2050 als er niets verandert. De gegevens zijn afkomstig uit het rapport van de Technology Policy Council van ACM uit 2021.] (Afbeelding van KDE gepubliceerd onder een CC-BY-SA-4.0 licentie. Vliegtuig icoon van Simon Child en IT icoon van Sari Braga, gelicentieerd onder een CC-BY licentie. Ontwerp door Lana Lutz.)](images/sec1_acm-report.png)

In hun conclusies erkennen de auteurs een inherente tegenstrijdigheid van digitalisering: digitale technologie “kan helpen de klimaatverandering te beperken”, maar “moet eerst ophouden eraan bij te dragen” (p. 1). ICT heeft een revolutie teweeggebracht in hoe we leven en wordt vaak geprezen voor het gemak en de efficiëntie die het in ons dagelijks leven brengt. Bedrijven hebben digitale technologie ingezet voor de efficiënte distributie van allerlei consumptiegoederen en de dematerialisatie van alledaagse producten. Voertuigen zoals auto's, scooters en fietsen zijn gemakkelijk te huur via smartphone-apps, waardoor het niet meer nodig is om ze te bezitten om ze te kunnen gebruiken. De wijdverspreide mogelijkheden van videostreaming betekenen dat het niet langer nodig is om dvd's en Blu-ray-schijven te produceren of te vervoeren om een ​​film te kijken, en dat het brandstof verbruiken om naar de videotheek te rijden om er een op te halen op zaterdagavond tot het verleden behoort. E-readers hebben hele boekenkasten vervangen. Nu de wereldwijde SARS-CoV-2-pandemie de integratie van digitalisering in elk aspect van het dagelijks leven versnelt, vervangen videoconferenties evenementen die voorheen (bijna) uitsluitend fysiek plaatsvonden, waaronder kantoorvergaderingen, internationale academische conferenties, lokale pianorecitals en zelfs eerste dates... allemaal mogelijk vanuit het comfort van uw eigen huis met een apparaat met internetverbinding.

Ondanks alle manieren waarop technologische ontwikkelingen ons leven ogenschijnlijk minder materieel en minder verspillend hebben gemaakt, en daardoor gemakkelijker en efficiënter, lijkt het erop dat het snelle tempo van digitalisering meer voordelen dan nadelen oplevert als het gaat om het bereiken van duurzaamheidsdoelen.

Maar is dat wel echt zo?

Het internet en de apparaten die we gebruiken om er verbinding mee te maken, vereisen infrastructuur—echte, fysieke hardware die energie vraagt ​​en grondstoffen verbruikt. Vaak worden de milieueffecten over het hoofd gezien van bijvoorbeeld de fabrieken die deze apparaten produceren of de continentomspannende infrastructuur die wereldwijde communicatie mogelijk maakt. Dit alles vereist energie in het dagelijks gebruik. Bovendien belandt hardware die niet meer wordt gebruikt ofwel in afvalverwerkingscentra voor verwerking aan het einde van de levensduur (wat nog meer energie vereist), of als elektronisch afval dat zowel giftig is voor mens als milieu. Nieuwe apparaten worden vervolgens geproduceerd en vervoerd, in veel gevallen onnodig.

“Een feit dat nog minder vaak wordt erkend, is dat de sleutel tot het verhogen van de energie-efficiëntie en het beschermen van natuurlijke hulpbronnen niet ligt in de hardware, maar vooral in de software.” — Criteria voor de Blauwe Engel-prijs: Hulpbronnen- en energiezuinige softwareproducten (p. 5)

Binnen dit bredere kader wordt de cruciale rol die software speelt bij het bijdragen aan milieuschade wellicht over het hoofd gezien. In veel gevallen is het immers de software die het energieverbruik en de levensduur van digitale infrastructuur bepaalt. Dit handboek gaat dieper in op een aantal manieren waarop digitale technologie bijdraagt ​​aan milieuschade en de klimaatcrisis. Voor alle duidelijkheid: dit handboek is niet anti-technologie — digitalisering heeft ongetwijfeld het leven van talloze mensen op talloze manieren verbeterd. Maar de ecologische impact van digitale technologie vereist dat we dieper nadenken over hoe we deze gebruiken en hoe we deze efficiënter kunnen inzetten. Het goede nieuws is dat ontwikkelaars via softwareontwerp een directe en aanzienlijke invloed kunnen uitoefenen op veel van de hier besproken problemen.

In de rest van de tekst, en met name in latere hoofdstukken, zal het Blauwe Engel-ecolabel voor bureaubladsoftware dienen als maatstaf voor duurzaam softwareontwerp. Maar wat betekent "Blauwe Engel" eigenlijk?

Het Blauwe Engel-ecolabel (Duits: Blauer Engel Umweltzeichen) is het officiële milieulabel van de Duitse overheid. In 2020 publiceerde het Duitse Milieuagentschap (Duits: Umweltbundesamt, of UBA) de criteria voor de toekenning van het label aan bureaubladsoftwareproducten. Dit was de eerste milieucertificering ter wereld die transparantie en gebruikersautonomie koppelde aan duurzaamheid. Vrije en open source software, of FOSS, heeft hier een duidelijk voordeel. We hopen dat u aan het einde van deze handleiding beter begrijpt hoe.

Maar om een ​​probleem effectief aan te pakken, moeten we eerst vaststellen wat het probleem is. Laten we daarom eerst begrijpen wat er wordt bedoeld met de digitale CO2-voetafdruk en hoe de software die we dagelijks gebruiken hierbij betrokken is.

Materiële voetafdruk van digitale technologie

Digitale technologie wordt vaak (en ten onrechte) geassocieerd met iets immaterieels. Wanneer we een e-mail versturen of gegevens uploaden naar de cloud, is het gemakkelijk voor te stellen dat onze berichten in het niets verdwijnen. Maar digitalisering heeft een zeer reëel, materieel aspect, dat niet alleen onze fysieke apparaten zoals smartphones en laptops omvat, maar ook de verwerkingsinstallaties voor gedolven metalen die nodig zijn om ze te laten werken, containerschepen die massaal geproduceerde hardware vervoeren, en kabels en datacenters die ze verbinden met wereldwijde netwerken. Het rapport uit 2018 “Lean ICT: Towards Digital Sobriety” beschrijft het probleem als volgt:

De materiële voetafdruk van digitale technologie wordt grotendeels onderschat door de gebruikers, gezien de miniaturisatie van apparatuur en de ‘onzichtbaarheid’ van de gebruikte infrastructuren. Dit fenomeen wordt versterkt door de wijdverspreide beschikbaarheid van diensten in de ‘cloud’, waardoor de fysieke realiteit van het gebruik nog onmerkbaarder wordt en de directe milieueffecten van digitale technologie worden onderschat. (p. 10)

Zoals een artikel in de New York Times [https://www.nytimes.com/interactive/2019/03/10/technology/internet-cables-oceans.html] geestig opmerkte: “Mensen denken dat data in de cloud staat, maar dat is niet zo. Het staat in de oceaan”, verwijzend naar de onderzeese communicatiekabels die de hele wereld omspannen. Om de tastbare realiteit van de “cloud” naar de aarde en onder de oceaan te brengen, moeten we ons perspectief veranderen naar de verborgen infrastructuur die de basis vormt voor ons digitale leven. Datanetwerken liggen dan wel grotendeels onder water, maar de CO2-uitstoot zal ernstige gevolgen hebben voor alle natuurlijke omgevingen. Tijdens COP27 in november 2022 onderstreepte secretaris-generaal António Guterres van de Verenigde Naties de urgentie van de situatie toen hij verklaarde: "We bevinden ons op een snelweg naar de klimaathel met ons voet op het gaspedaal".

Digitale technologie kan helpen de klimaatverandering te beperken, maar moet eerst stoppen met eraan bij te dragen.

Wat draagt ​​binnen de ICT-sector bij aan de stijging van de CO₂-concentratie in de atmosfeer?

Tussen 2012 en 2018 is de energiebehoefte van kunstmatige intelligentie (AI) 300.000 keer zo groot geworden, en momenteel verdubbelt deze elke paar maanden. Er wordt geschat dat het trainen van een enkel AI-model (zoals die gebruikt worden voor machinale vertaling of taalmodellering) evenveel energie kan kosten als een retourvlucht van New York naar San Francisco … 300 keer (dat is ongeveer 280.000 kilo CO₂)! Blockchain-technologie draagt ​​ook notoir bij aan de explosieve groei van het energieverbruik — met name proof-of-work-systemen zoals Bitcoin, die volgens Harvard Business Review rapporten evenveel energie verbruiken als hele landen zoals Zweden of Maleisië.

At the same time, we use more digital devices than ever before. The number of internet-connected devices, including laptops and smartphones, but also smart TVs, home assistants, and other IoT devices, is rapidly growing, and expected to surpass 75 billion by 2025. That’s just about 10 devices for every person on earth (though the global distribution of these devices is far from even). Globally, smartphone adoption has increased rapidly, as well as the demands on resources needed to manufacture new and increasingly powerful devices. The production of these devices, including mining for the rare earth metals necessary to make them work, and their transportation, use, and eventual disposal all consume copious amounts of energy.

Het is echter cruciaal om hier te benadrukken dat energieverbruik niet hetzelfde is als koolstofemissies. Koolstofemissies zijn afhankelijk van de specifieke mix van brandstoffen die worden gebruikt voor de opwekking van elektriciteit, ook wel de [elektriciteits- of energiemix](https://www.planete-energies.com/en/medias/close/what-power-generation-mix](https://www.bpb.de/nachschlagen/zahlen-und-fakten/europa/75140/themengrafik-energiemix-nach-staaten) genoemd. Zo bestond de energiemix van de Europese Unie in 2016 uit 32,9% olie, 23,9% gas, 14,9% kolen, 13,7% kernenergie en 14,5% hernieuwbare energie. Door de energiecrisis van 2022 is de energiemix in de EU veranderd — in sommige gevallen ten goede op de lange termijn, in andere gevallen ten kwade op de korte termijn. De relatieve CO2-uitstoot zal afhangen van deze mix: energieverbruik uit 100% CO2-neutrale bronnen draagt ​​bijvoorbeeld niet direct bij aan de CO₂-uitstoot.

Relatieve schade — ofwel: wanneer minder niet meer is

Digitalisering wordt vaak geassocieerd met 'dematerialisatie': het afdrukken van concert- of reistickets op papier is niet langer nodig, omdat ze kunnen worden gedownload en getoond op een smartphone; foto's worden niet langer bewaard in overvolle schoenendozen, maar op een kleine tablet of harde schijf; duizenden films en tv-series worden gestreamd op laptops, waardoor filmcollecties tot het verleden behoren. In veel gevallen wordt één apparaat, een smartphone, gebruikt voor al het bovenstaande — en nog veel, veel meer.

Al die materiële objecten maakten ooit een belangrijk deel uit van ons dagelijks leven … maar tegenwoordig zijn ze gewoonweg niet meer nodig. Dat is vast beter voor de aarde, toch?

Hoewel digitale apparaten bepaalde vormen van afval kunnen verminderen, vereist het schatten van de werkelijke milieu-impact van digitale technologieën dat rekening wordt gehouden met de volledige levenscyclus van een product. Dit omvat de kosten van de productie en het transport van digitale apparaten (van en naar de winkel, en naar de stortplaats), of de kosten van het saneren van milieuschade veroorzaakt door elektronisch afval. Dit is vooral belangrijk wanneer we de collectieve CO2-voetafdruk van onze digitale technologieën in ogenschouw nemen, aangezien in sommige gevallen de productie van apparaten, samen met het transport en de verwerking aan het einde van hun levensduur, meer broeikasgasemissies veroorzaken dan het gebruik van de apparaten gedurende hun volledige levensduur. Om dit te illustreren, neem het Milieuverantwoordelijkheidsrapport van Apple uit 2019, waarin wordt geschat dat Apple in 2018 25,2 miljoen ton CO₂ heeft uitgestoten (p. 9). Het grootste deel hiervan — maar liefst tachtig procent (!!!) — komt van productie (74%), transport (5%) en afvalverwerking (<1%). Slechts 19% komt van het daadwerkelijke gebruik van de apparaten.

Wanneer zijn de productiekosten van een digitaal apparaat ter vervanging van al die analoge objecten het dan waard? Het boek “Smarte Grüne Welt” (Engels: Smart Green World) van Steffen Lange en Tilman Santarius (2018) onderzoekt de moeilijkheid om rekening te houden met de relatieve milieuschade bij het beantwoorden van dergelijke vragen. Neem bijvoorbeeld dit fragment, waarin de auteurs de milieu-impact van het drukken van papieren boeken versus de productie van e-readers onderzoeken (pp. 29-31; vertaald uit het Duits):

Het maken van elektronische apparaten is uiteraard energie-intensiever en grondstofintensiever dan het drukken van een enkel boek. De productie van een e-reader, die meestal minder dan 200 gram weegt, vereist bijvoorbeeld ongeveer 15 kilogram aan verschillende materialen (vooral niet-hernieuwbare metalen en zeldzame aardmetalen), 300 liter water en 170 kilogram van het broeikasgas koolstofdioxide. Het zijn echter niet alleen de hoeveelheden input- en outputmaterialen die bepalend zijn, maar ook hun impact op het milieu. Er zijn grote verschillen tussen e-readers en boeken, met name wat betreft de toxiciteit van materialen en productieprocessen. Het is waar dat de papierindustrie in veel landen (nog steeds) zeer negatieve gevolgen voor het milieu heeft, bijvoorbeeld wanneer chloor of zuren het lokale water vergiftigen. De milieueffecten van de elektronica-industrie zijn echter soms verwoestend: e-readers en andere IT-producten bevatten gebromeerde brandvertragers, ftalaten, beryllium en talloze andere chemische stoffen die zeer schadelijk zijn voor de gezondheid en het milieu. Om nog maar te zwijgen van de sociale gevolgen, zoals de soms erbarmelijke arbeidsomstandigheden waaronder kobalt, palladium, tantaal en andere grondstoffen voor digitale apparaten worden gewonnen in dictaturen zoals de Republiek Congo of andere landen in het mondiale Zuiden, en vervolgens aan het einde van hun levensduur daar worden gedumpt als milieuschadelijk elektronisch afval.

Ondanks dit alles is de e-reader misschien wel beter dan het boek. Dit hangt uiteindelijk af van twee factoren: hoeveel boeken worden er op de e-reader gelezen gedurende de levensduur? En hoeveel mensen delen het analoge boek? Om de hoge milieukosten van de productie van de e-reader ecologisch te compenseren, moet er een bepaald aantal boeken op gelezen worden. Dit is het geval na 30 tot 60 boeken – afhankelijk van de dikte van het boek en afhankelijk van de milieu-indicator. Als je minder dan dit aantal boeken op een e-reader leest, is het beter om voor de papieren versie te kiezen. Als je meer dan dit aantal leest, is elk volgend boek op de e-reader ecologisch beter dan zijn analoge tegenhanger. Bovendien is de manier waarop objecten worden gebruikt cruciaal […]: Als we ervan uitgaan dat iemand een boek koopt en het aan niemand anders laat lezen, dan is een bestand op de e-reader ongeveer vijf keer energiezuiniger dan een boek. Dit voordeel verdwijnt echter wanneer meerdere mensen een boek delen.

Leidt het vervangen van fysieke objecten door digitale technologie tot een verminderde milieubelasting? Dat hangt ervan af. Als je bijvoorbeeld een e-reader koopt, lees je dan 30 tot 60 boeken voordat je het apparaat weggooit? Uit een Gallup-enquête bleek dat in 2021 57% van de Amerikanen minder dan 5 boeken per jaar las, en 15% tussen de 6 en 10 boeken. Dit betekent dat voor meer dan twee derde van de Amerikaanse bevolking een e-reader vijf tot tien jaar gebruikt zou moeten worden om de meest milieuvriendelijke keuze te zijn. Maar hoeveel consumenten upgraden al veel eerder naar het volgende, glimmende nieuwe apparaat?

Het is ook de moeite waard om te vragen of een apparaat door een bedrijf ondersteund blijft gedurende de tijd die nodig is om de minst schadelijke keuze te zijn. Eind 2022 bevatte de Wikipedia-lijst van uitgefaseerde e-readers eenenzeventig apparaten. Volgens de lijst was de gemiddelde levensduur, van introductiejaar tot eindjaar, 1,5 jaar – aanzienlijk korter dan een minimale gebruiksperiode van vijf jaar, laat staan ​​een decennium! Hoeveel van die e-readers functioneerden nog wel, maar belandden uiteindelijk op een vuilstortplaats vanwege stopgezette softwareondersteuning? Dit soort hardwareveroudering draagt ​​in belangrijke mate bij aan milieuschade, of het nu gaat om elektronisch afval of de CO2-uitstoot die gepaard gaat met de productie van het apparaat. Zoals Lange en Santarius schrijven: “het is de vraag of alle verkochte e-readers, voordat ze kapotgaan of technisch weer verouderd raken, gemiddeld zo intensief worden gebruikt dat er een algeheel ecologisch voordeel wordt behaald” (p. 31; vertaald uit het Duits).

Een “tsunami van elektronisch afval”

Met een hoogte van zeven meter is de "WEEE Man" een reus. De naam is afgeleid van de Wetgeving inzake afval van elektrische en elektronische apparatuur (WEEE) uit 2003, die doelstellingen vaststelt voor de inzameling, recycling en terugwinning van elektronisch afval in de EU.¹ Het beeld is gemaakt van 3,3 ton elektrisch afval, ofwel de gemiddelde hoeveelheid elektronisch afval die een Brit in zijn of haar leven produceert.

Elektronisch afval wordt beschouwd als de snelstgroeiende afvalstroom ter wereld, met 44,7 miljoen ton in 2016 — gelijk aan 4.500 Eiffeltorens, die, wanneer ze op elkaar gestapeld worden, 17 keer hoger zijn dan de Mount Everest. In 2018 werd er naar schatting 50 miljoen ton elektronisch afval gerapporteerd, wat de VN ertoe aanzette te spreken van een "tsunami van elektronisch afval die over de hele wereld rolt". De aantallen blijven stijgen: in 2021 werd er wereldwijd naar schatting 57 miljoen ton elektronisch afval gegenereerd. Minder dan 20 procent wordt ingezameld en gerecycled, en hoewel het slechts 2% van het afval op stortplaatsen uitmaakt, is het verantwoordelijk voor bijna 70% van het giftige afval dat daar wordt aangetroffen.

De milieueffecten van elektronisch afval zijn enorm. Onderdelen van elektronisch afval, zoals CPU's, bevatten potentieel schadelijke materialen zoals lood, cadmium, beryllium of gebromeerde vlamvertragers. De verwerking van elektronisch afval aan het einde van de levensduur kan ook een aanzienlijk risico vormen voor de gezondheid van werknemers en hun omgeving. Afvalverzamelaars riskeren hun gezondheid voor de afgedankte edelmetalen in laptops en smartphones “vervuild met lood, kwik of andere giftige stoffen”. Het proces van demonteren en verwijderen van elektronisch afval heeft geleid tot een aantal milieueffecten in ontwikkelingslanden. Vloeibare en atmosferische emissies komen terecht in waterlichamen, grondwater, bodem en lucht – en daardoor ook in land- en zeedieren, in gewassen die door zowel dieren als mensen worden gegeten, en in drinkwater. Deze vervuiling is een cruciaal aspect van de milieuschade die digitale technologie veroorzaakt.Deze vervuiling is een cruciaal aspect van de milieuschade die digitale technologie veroorzaakt.

Kijk naar de software

Wat is de oorzaak van al dit elektronisch afval, en waarom belanden digitale apparaten die nog werken op de vuilstort? Software-engineering speelt een belangrijke, maar vaak onzichtbare rol in onze digitale consumptiepatronen. Fabrikanten moedigen consumenten regelmatig aan om nieuwe apparaten te kopen, vaak onnodig; sterker nog, ze kunnen dit zelfs afdwingen via het softwareontwerp. Vanwege licentiebeperkingen op softwaregebruik en afhankelijkheid van leveranciers kunnen eindgebruikers hier weinig aan doen. Kortom, dit zijn grotendeels economische – en geen technologische – redenen waarom functionerende hardware elektronisch afval wordt.

Software-lock-out en geprogrammeerde veroudering leiden tot onbruikbare hardware. Abandonware die is uitgebracht onder een bedrijfseigen licentie kan gebruikers in het beste geval kwetsbaar maken voor virussen en andere malware, en in het slechtste geval gewoon stoppen met werken, zonder alternatief. De onderliggende infrastructuur waar mensen van afhankelijk kunnen zijn om een toepassing uit te voeren – zoals softwarelicentieservers die door softwareleveranciers worden gebruikt voor toegangscontrole – kan offline gaan, soms permanent. Gebruikers kunnen mogelijk geen gebruik meer maken van verouderde hardware, zelfs als ze dat zouden willen.

Feature creep en andere vormen van software bloat kunnen minder krachtige hardware verouderd maken, zelfs als klanten nooit om de extra functionaliteiten hebben gevraagd of ze zouden willen verwijderen als ze dat konden. Overweeg het volgende:

“Processing power has doubled about every two years since 1970. This means that functions are processed twice as fast and thus less energy is required for the same functions. A similar improvement in efficiency cannot be observed in the field of software. […] The availability of more and more powerful hardware has resulted in software becoming more and more bloated from version to version so that more resources are required for only minimal or even no enhancement of the functionality.” — Blue Angel Award Criteria: Resource and Energy-Efficient Software Products (p. 5)

In deze gevallen betekenen afhankelijkheid van leveranciers en gebruikersbeperkingen als gevolg van softwareontwerp en licenties dat nog functionerende apparaten worden weggegooid, terwijl er meer middelen nodig zijn om nieuwe apparaten te produceren en te transporteren.

Wanneer softwareontwerp, dat licentieservers vereist, last heeft van een wildgroei aan functionaliteiten, enzovoort, de hardware niet overbodig maakt, leidt dit ook tot een hoger energieverbruik tijdens het gebruik van de software. Zo toonde een studie gepubliceerd door het Duitse Milieuagentschap en een gerelateerd artikel aan dat twee applicaties die hetzelfde doen en hetzelfde resultaat bereiken, drastisch verschillende energieprofielen kunnen hebben.

De gegevens uit het onderzoek omvatten een vergelijking van twee tekstverwerkingsprogramma's: Tekstverwerker 1 wordt aangeduid als open-source, terwijl Tekstverwerker 2 wordt aangeduid als een bedrijfseigen softwareproduct. Beide computerprogramma's voerden dezelfde reeks opdrachten uit via een standaardgebruiksscenario (SUS)-script, dat overeenkomt met "het meest representatieve gebruik van de betreffende software gedurende een bepaalde periode" (p. 23). We komen in deel III van dit handboek terug op het scripten van gebruiksscenario's. Wat nu belangrijk is om te benadrukken, is het enorme verschil in energieverbruik. Tekstverwerker 2 verbruikte vier keer zoveel energie als Tekstverwerker 1 – en dit kan niet genoeg benadrukt worden – om dezelfde taak uit te voeren!

Als we het stroomverbruik van de twee tekstverwerkers in de loop van de tijd nader bekijken, wordt duidelijk hoe de twee programma's zich behoorlijk verschillend gedragen... en misschien wel in tegenspraak met wat u zou verwachten. Bekijk de onderstaande grafiek, waarin het stroomverbruik wordt weergegeven tijdens het uitvoeren van de reeks opdrachten van het gebruiksscenario. Rond de 440 seconden geeft het script beide tekstverwerkers de opdracht om het document op te slaan en stopt vervolgens met het vragen om verdere actie. Zoals u kunt zien, gaat tekstverwerker 1 inactief (zoals je zou verwachten). Tekstverwerker 2 daarentegen blijft doorwerken en verbruikt stroom, ook al is het script beëindigd.

Het is de moeite waard om te vragen waar de extra activiteiten tussen 440 en 600 seconden voor dienen: zijn de acties van Tekstverwerker 2 noodzakelijk voor de functionaliteit van de software? Verzamelt en verzendt de tekstverwerker gebruikersgegevens? Zo ja, kunnen gebruikers zich afmelden voor dit soort analyses? Gebruikersautonomie, zoals de mogelijkheid om ongewenst gegevensgebruik uit te schakelen, kan een groot verschil maken voor het energieverbruik van een softwareproduct. Datamining, tracking door derden, gepersonaliseerde algoritmes voor maximale betrokkenheid en advertenties zijn belangrijke bronnen van energieverbruik. Het verzamelen en analyseren van gebruikersgegevens en het trainen van algoritmes daarop vereist rekenkracht en infrastructuur.

Researchers in the EU have estimated the environmental costs of tracking and advertisements that users cannot opt out of, referred to as “unwanted data use” in the 2021 report “Carbon footprint of unwanted data-use by smartphones: An analysis for the EU”. The carbon footprint of this smartphone tracking—between 3 and 8 million metric tons a year in the EU alone—is “equal to the carbon footprint of between 370 and 950 thousand EU citizens” (at its worst, roughly the annual footprint of a city like Turin or Lisbon). The report points out that about 60% of European smartphone users say they would opt out of tracking and block advertisements when possible. That’s an awful lot of energy consumption for something most users don’t want in the first place!

“Het tegendeel is de waarheid”: Jevons’ paradox

Een toename in software-efficiëntie alleen leidt niet noodzakelijkerwijs tot een kleinere ecologische voetafdruk. Het 'rebound-effect' (ook wel 'terugslag-effect' genoemd) beschrijft bijvoorbeeld hoe efficiëntieverbeteringen kunnen leiden tot veranderingen in gebruik die de oorspronkelijke winst tenietdoen of zelfs volledig tenietdoen.

Stel u voor dat een softwarewijziging resulteert in een verbetering van 5% in energie-efficiëntie. Door deze toegenomen energiebesparing gaat men de software echter mogelijk meer gebruiken, waardoor de totale energiebesparing uiteindelijk afneemt. Laten we zeggen dat door uw toegenomen gebruik het totale energieverbruik van de software slechts met 1% daalt. In dit geval is het rebound-effect 80% ((5-1)/5): met andere woorden, de oorspronkelijke efficiëntiewinst is met 80% afgenomen, waardoor de besparingen van de verbeteringen praktisch teniet worden gedaan!

Als het rebound-effect boven de 100% uitkomt, wat betekent dat er uiteindelijk meer energie wordt verbruikt dan voorheen, spreekt men van de paradox van Jevons, ofwel een 'terugslag'. Het concept is afkomstig van de Engelse econoom William Stanley Jevons, die in 1865 vaststelde dat technologische verbeteringen in het gebruik van steenkool de steenkoolconsumptie in alle industrieën juist deden toenemen. Jevons concludeerde dat:

“Het is een misvatting om te veronderstellen dat zuinig brandstofgebruik gelijkstaat aan een verminderd verbruik. Het tegendeel is waar.” [accentuering toegevoegd]

Een praktische interpretatie van deze paradox is dat efficiëntiewinsten gecombineerd moeten worden met energiebesparingsmaatregelen om een ​​zinvol effect te sorteren, anders consumeert men uiteindelijk meer dan voorheen. Het ACM-rapport aan het begin van deze sectie maakt een soortgelijk punt: "Door computertechnologie mogelijk gemaakte efficiëntie moet gekoppeld worden aan een drastisch verlaagde energievraag om de CO2-uitstoot van de ICT-sector te verminderen" (p. 1). Met andere woorden, zowel software-engineering als gebruikersgedrag zijn cruciale elementen om te overwegen bij het bestrijden van de milieuschade die door software wordt veroorzaakt.

Is dit alles het waard?

Als we naar het grotere plaatje kijken, lijken de milieuschade en de wereldwijde uitstoot van broeikasgassen door software wellicht minder significant dan in andere industrieën. Daarom lijkt het terecht om te vragen: is het de moeite waard om aandacht te besteden aan de milieueffecten van software, een probleem dat in het grote geheel relatief klein lijkt?

Er zijn een paar dingen die we hier kunnen overwegen. Ten eerste de afwijzing van de drogreden "Niet zo erg als" (https://rationalwiki.org/wiki/Not_as_bad_as), ook wel bekend als "beroep op ergere problemen". Het algemene argument luidt als volgt: de bijdrage van software aan de wereldwijde CO₂-uitstoot is misschien niet zo erg als die van een andere industrie, en daarom is het niet de moeite waard om er aandacht aan te besteden. Wat er mis is met dit argument, is dat hoewel een andere industrie misschien erger is, dit niet ontkent dat softwareontwikkeling verantwoordelijk is voor ernstige milieuschade. Bovendien suggereert de drogreden "Niet zo erg als" een valse keuze tussen het aanpakken van het ene of het andere probleem, terwijl ecologisch verantwoord softwareontwerp slechts een onderdeel is van een groter geheel.

Laten we niet net als XKCD een withoedbeleid voeren en grotere problemen aanhalen als excuus om niets te doen!

Second, focusing only on fixing the “biggest problem” is not necessarily the most effective strategy. It’s also important to weigh the likelihood of success when addressing an issue, as well as the time and resources required to do so. Free & Open Source Software, with its focus on user autonomy and transparency, provides unique opportunities for users, communities, and organizations to directly address intertwined social and ecological issues. FOSS can be adapted, updated, and maintained at lower cost and without vendor dependencies or artificial restrictions.

Ten derde is het hopelijk inmiddels duidelijk dat software wel degelijk een aanzienlijke impact heeft op het energieverbruik en de afvalproductie, wat beide gevolgen heeft voor het milieu. Bovendien kunnen minimale aanpassingen in het softwareontwerp, op grote schaal bekeken, leiden tot besparingen die vergelijkbaar zijn met het jaarlijkse energieverbruik van complete steden. Deze bewering is gebaseerd op een voorbeeld van SAP Product Engineer Detlef Thoms, die snelle berekeningen maakt (04:20–06:10) om van een reductie van één CPU-seconde, wat overeenkomt met een besparing van ongeveer 10 wattseconde, naar een besparing van 95.000 megawattuur te gaan door simpelweg op te schalen. Deze besparingen zijn vergelijkbaar met het jaarlijkse energieverbruik van meer dan 30.000 huishoudens van twee personen.

Zoals Detlef Thoms in de video stelt: "Vaak gaat het om een ​​vrij eenvoudige reeks beslissingen die tot aanzienlijke verschillen in energieverbruik leiden."

Ten slotte is het, om uitspraken te kunnen doen over relatieve schade, noodzakelijk om eerst schattingen te hebben van de daadwerkelijke effecten. Omdat onderzoek op het gebied van energie- en grondstoffenverbruik van software nog vrij nieuw is, beschikken we vaak niet over gegevens om op data gebaseerde beweringen te doen. Met dit handboek, en met het Blauwe Engel-ecolabel als leidraad, hoopt KDE daar verandering in te brengen.

Het veranderen van onze software lijkt misschien een kleine stap in de aanpak van een complex probleem als klimaatverandering. Het is ook duidelijk dat het simpelweg veranderen van onze individuele consumptiepatronen op zich niet voldoende is (erger nog, bewijs suggereert dat grote veroorzakers van de wereldwijde uitstoot van broeikasgassen – zoals ExxonMobil – een retoriek van individuele consumentenverantwoordelijkheid hebben omarmd om hun eigen rol in de crisis te verbergen). Het is waar: een toekomst zonder emissies vereist fundamentele veranderingen in onze manier van leven, en die verantwoordelijkheid kan niet op individueel niveau worden afgehandeld. Maar denk eens aan wat antropologe Margaret Mead ooit opmerkte:

“Twijfel er nooit aan dat een kleine groep bedachtzame, betrokken burgers de wereld kan veranderen; sterker nog, het is het enige dat de wereld ooit heeft veranderd.”

Structurele verandering vindt plaats wanneer toegewijde, gepassioneerde mensen zich organiseren om dringende maatschappelijke problemen aan te pakken. Met decennialange ervaring in het succesvol samenbrengen van wereldwijde gemeenschappen om te werken aan gemeenschappelijke doelen, kan vrije en open-source software een krachtige kracht zijn in de strijd tegen de milieu-impact van digitalisering. We weten hoe we ons moeten organiseren – nu is het een kwestie van plannen omzetten in praktijk, doelen in realiteit. Laten we ons verenigen om door software veroorzaakte milieuschade te bestrijden. Laten we een cultuur van digitale duurzaamheid in onze softwaregemeenschappen bevorderen. Laten we samen energie- en grondstofefficiënte software bouwen!

Een toelichting op de bronnen

Een deel van het materiaal in deze sectie is rechtstreeks gebaseerd op tekst uit twee Wikipedia-artikelen: (i) “Richtlijn inzake afval van elektrische en elektronische apparatuur” en (ii) “Elektronisch afval”. Beide teksten zijn vrijgegeven onder de Creative Commons Attribution-Share-Alike License 3.0.

Deel II: Eco-certificering van bureaubladsoftware

Wat hebben bouwproducten, toiletpapier en software met elkaar gemeen?

Elk van deze producten kan een milieucertificaat ontvangen van het Blauwe Engel-keurmerk, het officiële milieukeurmerk van de Duitse overheid!

Het Blauwe Engel-ecolabel wordt toegekend aan een reeks producten en diensten, van papierproducten en bouwmaterialen tot printers, en certificeert dat het product voldoet aan een lijst van strenge eisen voor milieuvriendelijkheid gedurende de gehele levenscyclus. In 2020 heeft het Duitse Milieuagentschap de criteria voor de toekenning uitgebreid met softwareproducten, de eerste milieucertificering die transparantie en gebruikersautonomie koppelt aan duurzaamheid.

Concreet vereisen de criteria voor ecocertificering transparantie over het energieverbruik van de software tijdens gebruik, en garanderen ze tevens dat de software ook op oudere hardware kan draaien. Bovendien omvatten de criteria een lijst met eisen met betrekking tot gebruikersautonomie, wat de milieubelasting van de software kan verminderen.

Deze sectie geeft een breed overzicht van de Blauwe Engel en de ABC's van de criteria voor de toekenning van het Blue Angel-keurmerk aan bureaubladsoftware. Het laat ook zien hoe het voldoen aan de criteria de milieuschade kan verminderen. In het bijzonder gaan we hier dieper in op de details van de eisen met betrekking tot gebruikersautonomie in de criteria van het Blue Angel-keurmerk, waar we in DEEL III op terugkomen. Maar eerst een korte introductie van de Blauwe Engel en het KDE Eco-initiatief.

De Blauwe Engel voor bureaubladsoftware

De Blauwe Engel, geïntroduceerd in 1978, is het eerste milieukeurmerk ter wereld en het officiële milieukeurmerk dat door de Duitse overheid wordt toegekend. Het keurmerk wordt beheerd door het Duitse federale ministerie voor Milieu, Natuurbehoud, Kernveiligheid en Consumentenbescherming (Duits: Bundesministerium für Umwelt, Naturschutz, nukleare Sicherheit und Verbraucherschutz, of BMUV). Het Blauwe Engel-keurmerk is ook lid van het Global Ecolabelling Network (GEN), een internationaal netwerk van Type I-milieukeurmerken dat op het moment van schrijven 37 leden telt in bijna 60 landen.

De Blauwe Engel was niet het eerste Type I-ecolabel voor software – de Hong Kong Green Council, ook lid van het Global Ecolabelling Network, publiceerde criteria in 2010 voor groene IT-software. Maar de criteria van het Blauwe Engel-ecolabel zijn de eerste die een proces beschrijven voor het meten van het energieverbruik van software en die manieren specificeren waarop gebruikersonafhankelijkheid de milieuschade vermindert.

U vraagt ​​zich misschien af: Wat is een Type I milieulabel? Bij deze ecolabels wordt de volledige levenscyclus van het product in aanmerking genomen. Bovendien wordt de naleving van de toekenningscriteria beoordeeld door een derde partij. (Bij Type II milieulabels daarentegen is de naleving zelf verklaard en is geen audit door een derde partij vereist.)

Het Blauwe Engel-ecolabel is toegekend aan ongeveer 100 productgroepen en diensten in diverse sectoren, waaronder papier en bouwproducten, meubelen, kleding, was- en reinigingsmiddelen, schoonmaakdiensten, huishoudelijke chemicaliën, verpakkingen, voertuigen, energie en verwarming, en elektrische huishoudelijke apparaten. Sinds 2022, met de ecocertificering van KDE's PDF- en universele documentlezer Okular, omvat die lijst ook bureaubladsoftware.

De criteria voor de certificering worden op transparante wijze ontwikkeld door het Duitse Milieuagentschap. Het proces omvat de jury voor het milieulabel, een orgaan bestaande uit leveranciers, maatschappelijke organisaties en onderzoeksinstellingen. De onafhankelijke derde partij RAL gGmbH beoordeelt de naleving van de criteria en kent het keurmerk toe. Belangrijk is dat de Blauwe Engel niet garandeert dat een product volledig onschadelijk is. Gecertificeerde producten vertegenwoordigen een "minder kwaad" met betrekking tot milieuschade – dit kan worden samengevat met het motto zo min mogelijk, zo veel als nodig. In plaats van verschillende producten met elkaar te vergelijken, geeft het Blauwe Engel-ecolabel aan dat een product voldoet aan een lijst met eisen voor een specifieke categorie.

De ABC's van de beoordelingscriteria

De criteria voor de toekenning van de Blauwe Engel voor “Hulpbronnen- en energiezuinige softwareproducten” werden in januari 2020 gepubliceerd. De Blauwe Engel voor software heeft twee hoofddoelen: (i) het belonen van software met lagere prestatie-eisen, zodat “een langere levensduur van de hardware mogelijk is”; en (ii) het erkennen van producten die “zich onderscheiden door hun hoge mate van transparantie en gebruikers meer vrijheid geven in het gebruik van de software” (p. 6). Om dit te bereiken, zijn er drie hoofdcategorieën, hier aangeduid als de ABC's van de toekenningscriteria: (A) Hulpbronnen- en energie-efficiëntie, (B) Potentiële levensduur van de hardware, (C) Gebruikersautonomie.

De criteria in categorie (A) vereisen dat het energieverbruik van een softwareproduct wordt gemeten en gerapporteerd, en stellen dat het energieverbruik van de applicatie niet met meer dan 10% mag toenemen vanaf het moment van certificering. De gegevens over het energieverbruik worden gemeten met een externe energiemeter en houden rekening met andere hardwareprestatiegegevens, zoals CPU-gebruik of netwerkverkeer, terwijl de software op een representatieve manier wordt uitgevoerd. We komen hier in DEEL III op terug.

De criteria in categorie (B) garanderen dat de software voldoende lage prestatie-eisen heeft om te draaien op oudere, minder krachtige hardware die minstens vijf jaar oud is. Naleving vereist een verklaring van achterwaartse compatibiliteit, met details over de hardware waarop de software draait en de vereiste softwarestapel.

Tot slot zorgen de criteria in categorie (C) ervoor dat gebruikers invloed hebben op het energieverbruik en het gebruik van hulpbronnen door hun software. Er zijn acht categorieën voor de autonomiecriteria.

1. Gegevensformaten — Interoperabiliteit om gebruikers keuzevrijheid te geven

   Leveranciers mogen geen gebruik maken van gegevensformaten om gebruikers te dwingen een specifiek computerprogramma te gebruiken, noch mogen ze hoge overstapkosten opleggen. Interoperabele gegevensformaten voorkomen dat gebruikers vastzitten aan een programma dat veel energie verbruikt, terwijl een efficiënter programma dezelfde resultaten kan behalen met minder hardwarevereisten. Gebruikers moeten gemakkelijk van programma kunnen wisselen en toch toegang hebben tot al hun gegevens.

2. Transparantie — Gebruikersafhankelijkheden verwijderen voor langdurig gebruik

   Transparantie in softwarecode en applicatie-interfaces betekent het wegnemen van alle afhankelijkheden van een bepaald bedrijf of organisatie. Het betekent ook het wegnemen van beperkingen op het gebruik van de software en daarmee de hardware op de korte en lange termijn. Wanneer ontwikkelaars besluiten de ondersteuning voor hun software te beëindigen, moeten ofwel beveiligingsupdates blijven worden geleverd (zie hieronder) of moet de broncode openbaar beschikbaar worden gesteld, zodat derden de software kunnen blijven ondersteunen. Bovendien mag het verbeteren van de functionaliteit van de software niet worden beperkt door restrictieve of ongedocumenteerde applicatie-interfaces (API's).

3. Continue ondersteuning — Beveiligingsupdates ter voorkoming van elektronisch afval

   Depending on suppliers for essential updates should not result in abandoned software products that cannot be used without presenting serious disadvantages for the users, such as vulnerabilities to malware. Security updates should be provided for up to five years after software development is discontinued. Moreover, security updates should be separable from feature updates so that users are not coerced into adopting unwanted functionalities, e.g., feature creep and other forms of bloat. Such abandonware and software bloat leave hardware unusable and produce unnecessary e-waste.

4. Verwijderbaarheid — Ongewenste software verwijderen om de efficiëntie te verhogen

   De mogelijkheid om onnodige software volledig te verwijderen heeft ecologische voordelen. Overbodige software, steeds meer nieuwe functionaliteiten en ongewenste softwarecomponenten kunnen inefficiënties veroorzaken door geheugen in beslag te nemen, verwerkingstijd te verspillen, schijfgebruik te verhogen, opslagruimte te verbruiken en vertragingen te veroorzaken bij het opstarten en afsluiten van het systeem. Wanneer een gebruiker een computerprogramma niet langer wil gebruiken, moet het mogelijk zijn om het volledig van het systeem te verwijderen, met behoud van alle door de gebruiker gegenereerde gegevens.

5. Offline functionaliteit — Om afhankelijkheden te vermijden en het energieverbruik te verlagen

   Het gebruik van de software moet mogelijk zijn zonder internetverbinding — tenzij een netwerkverbinding natuurlijk noodzakelijk is voor de beoogde functionaliteit van de software. Licentieservers en andere vormen van toegangscontrole beperken het gebruik van een applicatie op manieren die niet nodig zijn voor de beoogde functionaliteit van de software. Wanneer een server uitvalt of er een internetstoring is, verhindert dergelijke toegangscontrole dat mensen hun software kunnen gebruiken, mogelijk permanent. Bovendien vereisen dergelijke afhankelijkheden netwerkverkeer en verbruiken ze dus meer energie dan nodig is voor het beoogde doel van de software.

6. Modulariteit — Om het geheugen- en energieverbruik te verminderen

   Gebruikers moeten alleen kunnen installeren wat ze nodig hebben. Niet-essentiële functies verhogen het geheugen- en energieverbruik, waardoor de software minder efficiënt wordt en mogelijk niet meer op oudere hardware kan draaien. Mensen moeten de mogelijkheid hebben om het aantal softwarefuncties te beperken tot die functies die ze willen of nodig hebben.

7. Vrijheid van reclame — Afmelden om energieverbruik te verminderen

   Het ongewenst gebruik van gegevens in de Europese Unie alleen al is ongeveer gelijk aan het jaarlijkse energieverbruik van een stad als Lissabon of Turijn; zie DEEL I. Door gebruikers de mogelijkheid te bieden zich af te melden voor advertenties, wordt de energie- en hulpbronbehoefte van eindgebruikersapparaten en de servers waarop de advertenties worden weergegeven, verminderd. Afmelden vermindert ook het verzonden datavolume en daarmee het energieverbruik voor netwerkverkeer.

8. Documentatie — Ter ondersteuning van hulpbronbesparend, continu gebruik van software … en dus ook hardware

   Documentatie is een voorwaarde voor de levensvatbaarheid van een softwareproduct op de lange termijn. Documentatie moet ook aantonen dat de software hulpbronnen kan besparen. Door de hierboven genoemde criteria te documenteren, kunnen gebruikers de software — en daarmee de hardware — op een duurzame manier blijven gebruiken, terwijl ontwikkelaars de software kunnen onderhouden zonder afhankelijkheden of beperkingen van leveranciers.

Softwareontwerp dat voldoet aan de criteria voor de prijs, zal minder snel last hebben van diverse vormen van inefficiëntie. Dit kan op zijn beurt helpen het probleem van elektronisch afval te verminderen: met software die niet leidt tot vroegtijdige hardwareveroudering, hoeven er minder apparaten te worden geproduceerd en verzonden. Dit betekent dat er minder waardevolle metalen hoeven te worden gedolven en verwerkt, wat op zijn beurt leidt tot een vermindering van water- en bodemvervuiling. Door gebruikersautonomie te garanderen, kunnen ontwikkelaars ervoor zorgen dat hun software de milieuschade op meer dan één manier vermindert – ofwel door apparaten langer te gebruiken, ofwel door het energie- en grondstoffenverbruik van de software tijdens gebruik te verminderen.

Met de focus op transparantie in resource- en energie-efficiëntie, de levensduur van hardware en gebruikersautonomie, bieden de criteria van de Blue Angel-award voor software een uitgebreid kader om een ​​discussie over softwareduurzaamheid op gang te brengen. In FOSS-gemeenschappen nemen we gebruikersautonomie en transparantie en de bijbehorende voordelen vaak voor lief. Hoewel het geen vereiste is om Vrije & Open-source Software te zijn om het Blue Angel-ecolabel te verkrijgen, is het juist in deze categorie dat FOSS echt uitblinkt. Op zoveel manieren lopen we al voorop in het ontwerpen van duurzame software!

Okular, het eerste ecologisch gecertificeerde computerprogramma.

In 2022 was Okular, de populaire multiplatform PDF-lezer en universele documentviewer van KDE, het eerste softwareproduct dat officieel werd erkend voor duurzaam softwareontwerp, zoals blijkt uit de criteria van de Blue Angel Award. Okular is tevens het eerste ecologisch gecertificeerde computerprogramma binnen het Global Ecolabelling Network.

Okular is slechts één softwareproduct dat wordt onderhouden door KDE, een wereldwijde gemeenschap van softwareontwikkelaars, kunstenaars, schrijvers, vertalers en makers die zich inzetten voor de ontwikkeling van vrije software. KDE onderhoudt tal van FOSS-producten, waaronder de Plasma-bureaubladomgeving; de ontwerp-toepassing voor schilders en grafische vormgevers, Krita; de GCompris-suite met educatieve activiteiten voor kinderen; Kdenlive, een professioneel videobewerkingsprogramma; en natuurlijk Okular, een documentviewer voor pdf's, strips, wetenschappelijke en academische artikelen en technische tekeningen.

Met de aloude missie en leidende visie van KDE sinds de oprichting in 1996, en het talent en de capaciteiten van de leden van de gemeenschap, is KDE een pionier in het bevorderen van duurzame software. In 2021 startte KDE KDE Eco, een project met als doel KDE en vrije software in de voorhoede van duurzaam softwareontwerp te plaatsen. Duurzaamheid is niet nieuw voor vrije en open source software (FOSS) – de vier vrijheden hebben vrije software altijd al duurzaam gemaakt. Maar nu krijgen de twee pijlers van FOSS – transparantie en gebruikersautonomie – bredere erkenning voor hun impact op duurzaamheid en zijn ze opgenomen in de duurzaamheidscriteria van het Duitse Milieuagentschap via het Blauwe Engel-ecolabel.

Met het allereerste eco-gecertificeerde softwareproduct ooit, de KDE-gemeenschap vierde de prestatie samen met de wider Vrije software gemeenschap, als evenals met de afdeling computerwetenschappen op Umwelt Campus Birkenfeld, waar onderzoekers het resource- en energieverbruik van Okular en andere KDE-software hebben gemeten.

De criteria voor de Blauwe Engel-onderscheiding weerspiegelen naadloos de waarden van KDE en die van de bredere FOSS-beweging. Vrije en open source software garandeert transparantie en geeft gebruikers de controle, in plaats van hen te verplichten met bepaalde leveranciers of serviceproviders samen te werken. Hierdoor kunnen gebruikers zelf bepalen wat ze van de software verwachten en daardoor ook beslissingen nemen over de hardware die ze gebruiken. Gebruikers kunnen het energieverbruik van hun programma's verminderen met weinig of geen verlies aan functionaliteit, door alleen te installeren wat ze nodig hebben, niet meer en niet minder; ze kunnen ook opdringerige reclame of datamining-opties vermijden die processen op de achtergrond uitvoeren en zo extra resources op het apparaat en in het netwerk verbruiken. FOSS-ontwikkelaars blijven doorgaans hardware ondersteunen die de industrie graag zou willen afschrijven, waardoor gebruikers beschikken over actuele en veilige software voor apparaten die anders als elektronisch afval zouden worden weggegooid en op stortplaatsen zouden belanden.

Okular is uitgebracht onder de GPLv2+-licentie, is FOSS en voldoet daarom al aan veel van de criteria voor gebruikersautonomie die nodig zijn om het Blue Angel-keurmerk te verkrijgen. Er is verder gewerkt om Okular volledig te laten voldoen aan de criteria voor de onderscheiding door functies voor gebruikersautonomie te documenteren, transparantie te bieden in energie- en grondstoffenverbruik en de potentiële verlenging van de levensduur van de hardware van apparaten te ondersteunen.

Okular stelt u in staat om digitale handtekeningen te controleren en zelf documenten te ondertekenen, en ook om geannoteerde tekst en opmerkingen direct in het document in te sluiten. Okular werkt op Linux, Windows, Android en Plasma Mobile en is beschikbaar om te downloaden voor alle GNU/Linux-distributies, als een zelfstandig pakket via Flathub en de Snap Store, via de KDE F-Droid release repository voor Android, en via de Microsoft Store. De broncode is ook direct beschikbaar op Okular's GitLab repository zodat iedereen deze kan gebruiken, bestuderen, delen, verbeteren en vooral van kan genieten.

KDE en de Vrije Software gemeenschap willen graag een hartelijk dank u zenden naar de ontwikkelaars van Okular voor het maken van omgevingsvriendelijke software voor ons allen!

In DEEL III van dit handboek bekijken we de stappen die u moet voltooien om uw vrije softwareproject ook te laten erkennen voor het duurzame softwareontwerp. Maar eerst, wat zijn precies de voordelen van het verkrijgen van de Blauwe Engel?

Voordelen van Blauwe Engel

Steffi Lemke, federaal minister van Milieu, Natuurbehoud, Kernveiligheid en Consumentenbescherming (BMUV), heeft het volgende gezegd over de reputatie van de Blauwe Engel:

Steeds meer mensen letten bij de aanschaf van producten op duurzaamheid en milieuvriendelijkheid. Precies daarvoor staat de Blauwe Engel (Blue Angel). Dit milieukeurmerk vormt al 40 jaar op onafhankelijke en geloofwaardige wijze een garantie voor hoge standaarden op het gebied van milieu- en gezondheidsbescherming.

In hun informatiebrochure ter gelegenheid van het 40-jarig jubileum, “Blue Angel &ndashh; 40 years. Good for me. Good for the environment”, heeft het Duitse milieuagentschap (UBA) de geschiedenis, de huidige status en de toekomst van het ecolabel in kaart gebracht. In de brochure worden enkele algemene criteria genoemd die worden gehanteerd bij de milieucertificering van een product, zoals:

• verminderde uitstoot van schadelijke stoffen in de bodem, de lucht, het water en binnenshuis;
• duurzame productie van hulpbronnen;
• levensduur, de mogelijkheid om het product te repareren en te recyclen; en
• efficiënt gebruik, bijv. energiebesparende producten.

Nu u aan het einde van dit gedeelte bent gekomen, hopen we dat duidelijk is hoe naleving van de criteria voor het 'Blauwe Engel'-keurmerk voor bureaubladsoftware onder meer bijdraagt ​​aan de bovengenoemde milieuvoordelen.

Milieukeurmerken kunnen een instrument zijn om markten in de richting van duurzame producten te bewegen. Zoals op de website van de Blauwe Engel (Blue Angel) staat: "Het doel van het milieukeurmerk is om particuliere klanten, grote institutionele afnemers en overheidsinstellingen betrouwbare richtlijnen te bieden voor milieubewuste inkoop."

Wat zegt de markt dus?

Uit een onderzoek blijkt dat 92% van de Duitsers het ecolabel herkent en dat het label bij 37% van hen van invloed is op de aankoopbeslissing. Het ecolabel is ook buiten Duitsland herkenbaar; tot wel 15% van de bedrijven die het 'Blauwe Engel'-keurmerk (Blue Angel) voeren, is buiten Duitsland gevestigd. Een reden hiervoor is dat de 'Blauwe Engel' – in tegenstelling tot sommige andere ecolabels – geen eisen stelt aan de regio waar een product op de markt mag worden gebracht. Bovendien geniet het 'Blauwe Engel'-keurmerk internationaal aanzien als teken van hoge kwaliteit; de toekenningscriteria worden beschouwd als een graadmeter voor de koers van de EU-markt en dienen soms zelfs als richtlijn bij het optimaliseren van producten.

Het verkrijgen van het Blue Angel-keurmerk kan de zichtbaarheid van uw product vergroten, niet alleen bij particulieren maar ook bij grote organisaties. Initiatieven voor groene overheidsinkopen (GPP) – die "beogen de inkoop door de overheid te bevorderen van goederen, diensten en werken met een verminderde milieu-impact gedurende de gehele levenscyclus" (Europese Commissie) – beïnvloeden de inkoopbeslissingen in zowel de publieke als de private sector. Door uw softwareproduct te laten certificeren met het Blue Angel-milieukeurmerk toont u uw inzet voor digitale duurzaamheid op de lange termijn en vergroot u de zichtbaarheid van uw product, zowel in Duitsland als daarbuiten.

Een toelichting op de bronnen

Een deel van de inhoud in deze sectie is rechtstreeks gebaseerd op tekst uit twee Wikipedia-artikelen: (i) “Blue Angel (certificering)” en (ii) “Software bloat”. Beide teksten zijn vrijgegeven onder de Creative Commons Attribution-Share-Alike License 3.0. Daarnaast is een deel van de inhoud in deze sectie rechtstreeks gebaseerd op de KDE Eco-blogpost “First Ever Eco-Certified Computer Program: KDE’s Popular PDF Reader Okular”, die is vrijgegeven onder de Creative Commons Attribution-ShareAlike 4.0 International License.

Deel III: Voldoen aan de criteria voor de Blue Angel Award

De drie hoofdcategorieën van de criteria voor het Blue Angel-keurmerk voor desktopsoftware zijn:

• (A) hulpbron- & Energie-efficiëntie
• (B) Potentiële werkzame leeftijd van hardware
• (C) Gebruikersautonomie

In dit gedeelte bieden we een praktische handleiding voor het voldoen aan de verschillende sets criteria. Het voldoen aan de basiscriteria voor de onderscheiding levert tal van voordelen op. Door het energieverbruik van uw software inzichtelijk te maken en te voldoen aan de criteria inzake de levensduur van de hardware en de autonomie van de gebruiker, profiteert u van de volgende voordelen:

• Eco-certificering: vraag het milieukeurmerk 'Blauwe Engel' (Blue Angel) aan om aan gebruikers, bedrijven en overheidsinstanties te laten zien dat uw software duurzaam is ontworpen.
• Datagestuurde ontwikkeling: Spoor inefficiënties op het gebied van energie- en hardwareverbruik op en neem gegevensgestuurde beslissingen voor uw softwareontwikkeling.
• Duurzaam ontwerp: houd bij het plannen van het softwareontwerp rekening met de criteria voor gebruikersautonomie, met het oog op duurzaam gebruik van software – en daarmee hardware – op de lange termijn.
• Informatie voor eindgebruikers: wijs uw gebruikers op de manieren waarop uw software al duurzaam is ontworpen, door de criteria van de 'Blauwe Engel' (Blue Angel) als maatstaf te gebruiken.

(A) Hoe uw software te meten

De laboratoriumopstelling bestaat uit een vermogensmeter, een computer voor het verzamelen en analyseren van de meetgegevens, en een bureaubladcomputer waarop het te testen systeem draait en gebruikersgedrag wordt nagebootst. De hier beschreven opstelling voldoet aan de specificaties van de “Blue Angel Basic Award Criteria for Resource and Energy-Efficient Software Products”.

De terminologie is deels afkomstig van Kern et al. (2018): “Sustainable software products — Towards assessment criteria for resource and energy efficiency”.

Zie ook de volgende bronnen van de Umwelt Campus Birkenfeld:

• Seiwert & Zaczyk (2021): “Projektbericht: Ressourceneffiziente Softwaresysteem ben Beispiel van KDE-Software” (alleen Duits)
• Mei (2021): “Vergleichende Analyse und Bewertung von Betriebssystemen hinsichtlich ihrer Energieeffizienz” (alleen Duits)
• “OSCAR Manual” (alleen Duits)

Overzicht van de laboratoriumopstelling

De laboratoriumopstelling vereist 1 vermogensmeter en ten minste 2 computers:

• Energiemeter

  Een van de apparaten die door de Blauwe Engel (Blue Angel) worden aanbevolen, is de Gude Expert Power Control 1202-serie (handleiding). Het apparaat biedt aansluitingen voor de stroomvoorziening van de computer en meet de stroom tijdens het gebruik. Het kan worden aangestuurd en uitgelezen via een bedrade Ethernet-verbinding. Er is een webgebaseerde gebruikersinterface en een REST API beschikbaar, en het apparaat ondersteunt diverse protocollen zoals SNMP of syslog.

• Computer 1: Data-aggregator & evaluator

  De computer zal worden gebruikt voor het verzamelen en evalueren van de resultaten van de vermogensmeter.

  Een Python-script om de gegevens van de Gude Expert Power Control 1202-serie uit te lezen, is beschikbaar in de FEEP-repository.

  Het wordt aanbevolen om de voortgang live te volgen met de tweede computer, om er zeker van te zijn dat alles soepel verloopt. Dit kan bijvoorbeeld met KDE's Labplot; lees hier meer over hier.

  Voor andere vermogensmeters is mogelijk niet-vrije software vereist, zoals Janitza's GridVis Power Grid Monitoring Software.

• Computer 2: Systeem onder test

  Het referentiesysteem is de hardware die wordt gebruikt om het energieverbruik van het "te testen systeem" (SUT) te meten. Het SUT omvat het besturingssysteem en de software die zijn geïnstalleerd voor (i) het testen van het softwareproduct, (ii) het emuleren van het standaardgebruiksscenario² en (iii) het verzamelen van de resultaten met betrekking tot de hardwareprestaties.

Let op het volgende:

• Voor GNU/Linux-systemen vereisen de Blue Angel-criteria (sectie 1.1) een van de diverse Fujitsu-computers als referentiesysteem.
• Voor het simuleren van activiteit in het standaardgebruiksscenario kunnen tools voor taakautomatisering uit de wereld van vrije software worden gebruikt, zoals xdotool, KDE Eco Tester (in ontwikkeling) of Actiona (GPLv3).
• Voor het verzamelen van hardwareprestatiegegevens (bijv. processor- en RAM-gebruik, hardeschijfactiviteit, netwerkverkeer) is de vrije-softwaretool Collectl (GPLv2/Artistic License) beschikbaar.
• Het is ook mogelijk om goedkope schakelbare stopcontacten om te bouwen tot meetapparatuur; zie sectie “Alternatief: Gosund SP111-configuratie” voor instructies over de installatie.

Systeem onder test (SUT)

De Fujitsu Esprimo P920 Desktop-PC proGreen-selectie (Intel Core i5-4570 3,6 GHz, 4 GB RAM, 500 GB HDD) is bijvoorbeeld een van de aanbevolen referentiesystemen; zie bijlage D bij de gunningscriteria voor andere aanbevolen Fujitsu-systemen.

Op het referentiesysteem moet u het SUT (System Under Test) inrichten, oftewel het systeem waarop u de software gaat testen. Het SUT moet een minimaal, niet-relevant energieverbruik hebben en over een gestandaardiseerde configuratie beschikken. Het volgende wordt aanbevolen:

• Overschrijf de volledige harde schijf van de machine met een gestandaardiseerd besturingssysteem.
• Schakel alle mogelijke achtergrondprocessen uit (automatische updates, back-ups, indexering, enz.).
• Installeer de benodigde software, d.w.z. de te meten applicatie, evenals de software voor gebruikers-emulatie (bijv. xdotool) en voor hardware-prestatiegegevens (bijv. Collectl).
• Wanneer de scenarioscripts worden uitgevoerd, moet de cache worden geleegd en nieuwe bestanden dienen verwijderd te worden vóór de nieuwe meting.

Voorbereiden van het standaard scenario's voor gebruik (SUS)

Het voorbereiden van de SUS vereist:

• Het identificeren van de taken die gebruikers bij normaal gebruik uitvoeren.
• Het herkennen van functionaliteiten die leiden tot veel energie- of systeembronnenverbruik.
• Op basis van het bovenstaande wordt een stroomschema van acties opgesteld en worden deze acties nagebootst met een tool voor taaktautomatisering.
• Het is aanbevolen om een wacht-periode van 60 seconden in te plannen vooraf aan het starten van de metingen.
• De SUS voor ten minste 5 minuten uitvoeren.

Een hulpmiddel voor automatisering is nodig om de scenario's uit te voeren zodat menselijke interactie niet nodig is. Zo kan het script herhaaldelijk worden uitgevoerd op duidelijke wijze om betrouwbare resultaten te krijgen.

Voorbeeldtaken en functies getest in de SUS voor KMail KMail omvatten het zoeken naar een e-mail, het schrijven van een mail, het doorsturen van een mail, een bijlage opslaan, een map verwijderen, etc. Zie de Actiona scripts gebruikt om Krita en Okular te testen, voor extra voorbeelden.

Belangrijk: Als het emulatiehulpmiddel pixelcoördinaten gebruikt om de positie van de geautomatiseerde klikken op te slaan (bijvoorbeeld Actiona) en bovendien de schermresolutie van de computer die bij de voorbereiding is gebruikt, afwijkt van die van de laboratoriumcomputer, moeten alle pixelcoördinaten opnieuw worden ingesteld voor de laboratoriumomgeving.

Meer emulatiehulpmiddelen

Behalve xdotool, KDE Eco Tester (in ontwikkeling), of Actiona, er zijn andere hulpmiddelen die mogelijk voldoen aan de vereisten. Zie een lijst van KDE bijdrager David Hurka in de presentatie “Visual Workflow Automation Tools”. De meeste hulpmiddelen gebruiken X11-specifieke functies, en werken niet op Wayland-systemen. Er zijn een paar mogelijke aanpakken in dit geval:

• Selenium Webdriver AT-SPI worden gebruikt (wordt getest voor Season of KDE 2023)
• Het XDG RemoteDesktop portaal
• Diverse Wayland-protocollen (de ondersteuning verschilt per compositor):
  • https://github.com/swaywm/wlr-protocols/blob/master/unstable/wlr-virtual-pointer-unstable-v1.xml
  • https://api.kde.org/frameworks/kwayland/html/classKWayland_1_1Client_1_1FakeInput.html
• libinput gebruikersapparaten

Meetproces

Het meetproces is gedefinieerd in Appendix A van de Basic Award Criteria. Het vereist het opnemen en loggen van energiegegevens en prestatie-indicatoren met een resolutie van 1 seconde opdat ze kunnen worden verwerkt en gemiddelden kunnen worden berekent.

Enige algemene opmerkingen:

• Tijden tussen de PM en DAE moeten gesynchroniseerd worden.
• Wanneer Collectl wordt gebruikt om systeemlading te verzamelen, controleer dat het in de console wordt uitgevoerd van de SUT; controleer ook dat de benodigde CSV-bestand correct is gegenereerd vóór het testen.
• Gezien iedere uitvoering tot veranderingen leidt in het systeem, wordt het aanbevolen om de cache te ledigen tussen uitvoeringen.
• Uitvoeringen (Baseline, Passieve modus, Standaard Scenario) moeten voor dezelfde tijd zijn, gebaseerd op de benodigde tijd voor het uitvoeren van de scenario's.
• Op de DAE wilt u wellicht controleren of het gewenste stopcontact correct wordt weergegeven vóór en/of tijdens het testen (bijvoorbeeld met een realtime grafiek met behulp van LabPlot).

Tijdens de energiemetingen wordt Collectl gebruikt om een set aan prestatie-indicatoren op te nemen: CPU-gebruik, RAM-gebruik, activiteit van opslag en netwerkverkeer. Gebruik de volgende opdracht om de prestatiegegevens te verkrijgen:

$ collectl -s cdmn -i1 -P --sep 59 -f ~/<BESTANDSNAAM>.csv

De opties zijn:

• -s cdmn

  verzamelen van CPU, Schrijf, geheugen, and netwerk gegevens

• -i1

  meetinterval van 1 seconde

• -P

  uitvoer in grafiekformaat (gescheiden gegevens bestaande uit een header met een regel per meetinterval

• --sep 59

  scheidingsteken: puntkomma

• -f </PAD/NAAR/BESTAND>.csv

  sla het bestand op op het gespecificeerde pad

Het meten van de uitgangswaarde, de ruststand en standaardgebruiksscenario’s

• Uitganswaarde scenario: Besturingssysteem (OS)

  Om een uitgangswaarde te bereiken, wordt een scenario gemeten waarin het OS draait, maar waarin niets gebeurt.

• Rustmodus scenario: OS + programma terwijl het passief is

  Om het energieverbruik en de prestatiegegevens van de hardware te bepalen, terwijl het programma in staat van rust is, wordt een scenario gemeten waarin het programma wordt geopend, maar geen handeling wordt ondernomen.

  Belangrijk: de basislijn- en rustmodus moeten even lang worden uitgevoerd als de tijd die nodig is om het standaardgebruiksscenario uit te voeren. Aangezien het stroomverbruik voor de basislijn- en rustmodus relatief constant is, worden tien herhalingen voor elk scenario als voldoende beschouwd om een representatieve steekproef te verkrijgen (Seiwert & Zaczyk 2021).

• Standaard scenario's voor gebruik: OS + toepassing in gebruik

  Om het energieverbruik en de hardwareprestaties van de actieve toepassing te meten, moet het standaardgebruiksscenario worden uitgevoerd; zie de opmerkingen over de voorbereiding van het SUS hierboven. De meting van het standaardgebruiksscenario moet 30 keer worden herhaald, wat enkele uren in beslag zal nemen. Het grotere aantal herhalingen is nodig om een representatieve steekproef te verkrijgen, aangezien het energieverbruik en de prestatiegegevens per meting kunnen variëren.

Uitvoer controleren met Labplot

KDE's LabPlot kan gebruikt worden om de uitvoer te controleren terwijl de gegevens binnenkomen:

• Leidt de uitvoer van de vermogensmeter naar een CSV-bestand.
• In Labplot, importeer het CSV-bestand door Bestand->Nieuw toevoegen-> Actieve gegevensbron…
• Selecteer onder ‘Filter’ de optie ‘Aangepast’. Stel onder ‘Gegevensindeling’ het te gebruiken scheidingsteken in (bijvoorbeeld komma, puntkomma, spatie).
• U kunt onder het tabblad ‘Voorbeeld’ controleren of de uitvoer correct is.
• Als alles er goed uitziet, klik dan op Oké.
• Klik ten slotte met de rechtermuisknop op het dataframe-venster en selecteer Gegevens weergeven > xy-curve.

Analyse van de resultaten met OSCAR

De Umwelt Campus Birkenfeld biedt een handig hulpmiddel voor het genereren van rapporten voor wanneer je de resultaten hebt, genaamd OSCAR (Open source Software Consumption Analysis and Reporting (Analyse en rapportage van het gebruik van open-bron-software))

• Broncode
• Draaiende instatntie

Zie ook de OSCAR handleiding met uitgebreide instructies, inclusief schermopnamen over hoe OSCAR moet worden gebruikt.

CSV-bestanden

Analyse met OSCAR vereist het uploaden van de volgende bestanden naar de OSCAR website:

• (i) een logbestand van de ondernomen acties,
• (ii) de energieverbruiksgegevens
• (iii) de prestatiegegevens van de hardware

Alle bestanden moeten CSV-bestanden zijn. Voorverwerking van de ruwe gegevens zou nodig kunnen zijn (bijv. prestatiegegevens gemeten met Collectl; zie hieronder)

Belangrijk: OSCAR is erg kieskeurig wat betreft de indeling van dataframes, inclusief kolomnamen en celwaarden. De hier gegeven tabellen geven voorbeelden waarvan zeker is dat ze werken. Als u problemen ondervindt met het genereren van het rapport, controleer dan dat uw CSV-bestanden zo veel mogelijk lijken op deze voorbeelden.

Als u alleen maar OSCAR wilt testen, dan kunt u gegevens van Okular downloaden in dit ZIP-archief. Het is bevestigd dat de gegevens succesvol een rapport genereren met behulp van OSCAR v0.190404. Het gegenereerde rapport kan worden gedownload van de FEEP-repository.

Logbestand met acties

Het logbestand met acties moet het volgende formaat hebben. Merk op dat de kolommen zijn gescheiden door een puntkomma. En bovendien, de kolommen hebben geen namen (er staat geen koptekst in het CSV-bestand). Let erop dat het begin en het einde van elke iteratie in de tweede kolom moeten worden aangeduid met ‘startTestrun’ en ‘stopTestrun’, terwijl de acties onder elke gewenste naam kunnen worden vermeld.

Een voorbeeld logbestand voor de acties voor het meten van KDE's tekst en code bewerker Kate. De (i) tijd en datum en de (ii) start en stop tijden en de (iii) staan op een rij in drie kolommen.

Energiegebruiksgegevens

De energieverbruikdata heeft de volgende indeling: de eerste kolom is het kolommen zoals hier beneden geschreven ("Zeit" en "Wert 1-avg[W]") (ii) de datum en tijd als karakterreeksen, gescheiden met een komma en (iii) er wordt geen teken als scheiregelnummer, de tweede kolom is de datum en de tijd in toenames van een second en de derde kolom is de meting uitvoer in watts. Let op dat het volgende bevestigd is om te werken met OSCAR: (i) de namen van de tweede en derde scheidingsteken gebruikt in het CSV-bestand.

Wanneer de Gude Power Meter wordt gebruikt met het Python script beschikbaar op de FEEP

De ruwe gegevens kunnen worden voorbewerkt in R: nanoseconden in Epoch-tijd kunnen worden omgezet naar datum-tijd met het commando as.POSIXct(<NANOSECONDEN>/1000000, origin = '1970-01-01', tz = 'Europe/Berlin'). De nanoseconden in rij 1 van de ruwe uitvoer zijn na conversie bijvoorbeeld “2022-08-27 16:52:03 CEST”.

Voor gebruik met OSCAR, moet deze datum en tijd worden omgevormd naar een tekenreeks met de datum als: DD.MM.YY gevolgd door een komma. Dit kan allemaal bereikt worden met een opdracht: (deze bewerking kan over de gehele kolom in het dataframe worden gevectoriseerd); vervang de YYYY-MM-DD datum door de datum van uw metingen:

stringr::str_replace(as.character(as.POSIXct(1661611923019071/1000000, origin = '1970-01-01', tz = 'Europe/Berlin')), '2022-08-27', '27.08.22,')

Er moet een gemiddelde per seconde worden genomen van de uitvoer in watt. Dezezelfde gegevens zijn weergeven na het verwerken met R; let op dat de bovenstaande 7 waarden het gemiddelde per seconde zijn, resulterend in twee rijen.

Om het CSV-bestand op te slaan met een puntkomma scheidingsteken, moet de eerste kolom met rijnamen, beginnend bij nummer 1, zonder scheidingsteken, de volgende R opdracht gebruiken:

write.csv2(<DATAFRAME>, file = <PATH/TO/FILE.csv>, row.names = TRUE, quote = FALSE)

Het resultaat zou er zo uit moeten zien:

Prestatiegegevens (ruw)

Wanneer Collectl voor prestatiegegevens van de hardware wordt gebruikt, is het nodig om het volgende te doen alvorens de data te uploaden naar OSCAR.³

• Verwijder alle informatie boven de koptekstrij.
• Verwijder alle # karakters van het bestand.
• In de eerste kolom mag er geen scheidingsteken tussen de datum en de tijd staan ( anders worden de datum en de tijd als twee afzonderlijke kolommen geïnterpreteerd).
• De datum moet ook een teken hebben tussen YYYYMMDD, bijv.: MM.DD.YYYYY zoals hierboven. Welk teken wordt gebruikt, moet gespecificeerd worden in OSCAR.
• Kolomnamen kunnen alles zijn wat je wilt gezien die gespecificeerd worden in OSCAR.
• Het bestand moet in CSV-formaat worden opgeslagen.

Bovendien bevat de hardwareprestatie-uitvoer van Collectl veel kolommen die niet nodig zijn voor de analyse. De enige metingen die moeten worden gespecificeerd, zijn de volgende kolommen:

• [CPU]Totl = Processor
• [MEM]Used = Main memory - used kilobytes
• [NET]RxKBTot = Network - Kilobytes received/s
• [NET]TxKBTot = Network - Kilobytes transmitted/s
• [DSK]ReadKBTot = Disk - Kilobytes read/s
• [DSK]WriteKBTot = Disk - kilobytes written/s.

Hieronder is een voorbeeld van de voorbewerkte resultaten van de metingen van Collectl die de prestatiegegevens meet van Kate. De tijdstempel loopt op in één seconde stappen.

Gegevens uploaden

Wanneer de CSV bestanden klaar zijn, dan kunt u de analyse in OSCAR uitvoeren, hetgeen een samenvattingsrapport zal genereren die u kunt gebruiken voor de eco-certificering of voor eigen data-gestuurde doelen. In de OSCAR interface, let op het volgende:

• De interface-taal is momenteel alleen Duits; zie hieronder voor vertalingen.
• De duur van de metingen in seconden moet gespecificeerd worden.
• Een puntkomma scheidingsteken is gebruikt.
• De correcte opmaak van de tijdstempel moet gespecificeerd worden voor ieder van de geüploade bestanden, bijv. %Y-%m-%d %H:%M:%OS.

Stap 1: Meetdata verzamelen

De startpagina van de website (beneden) geeft aan dat de eerste stap is om het verzamelen van de meetgegevens (Duits: Erfassung Messdaten). Als u op dit punt bent in het proces, dan zou u uw software al doorgemeten moeten hebben en de CSV-bestanden hebben voorbereid.

Al deze voorbeelden zijn gebaseerd op de Okular gegevens in dit ZIP-archief.

Stap 2: Upload de meetgegevens

Zodra u de CSV-bestanden voor de basislijn, de ruststand en de standaardgebruiks-scenario-metingen bij de hand heeft, klikt u op (2) Upload Messdaten > Upload.

De meetgegevens (Duits: Messdaten) bevatten het logbestand van de handelingen (Duits: Aktionen), energieverbruik (Duits: Elektrische Leistung) en hardwareprestatiegegevens (Duits: Hardware-Auslastung)

• Onder Messungen, upload ofwel de rustmodus- of de standaard gebruiksscenario meetgegevens.

  Voor Art der Messung (type metingen) rechtsonder in de UX, selecteer Leerlauf (rustmodus) of Nutzungsszenario (gebruiksscenario), afhankelijk van welk rapport u wilt genereren.

• Onder Baselines upload de basislijnmeetwaarden (uitgangswaarden).

• Geef de duur van de meetscenario's aan in seconden (Duits: Dauer der Einzelmessungen (s)).

Merk op dat de uitgangsmetingen altijd geüpload worden samen met of de rustmodus of standaardgebruiksscenariometingen.

Zie onderstaand voor hoe een voltooide upload voor de Nutzungsszenario er uit ziet.

Tijdstempels    Zodra de gegevens zijn geüpload, moet u OSCAR vertellen hoe de gegevens moeten worden gelezen.

Laten we beginnen met het tijdstempelformaat (Duits: Formatierung Zeitstempel*). Dit is een aspect van het proces dat problemen kan veroorzaken als het niet correct wordt uitgevoerd. Dit word gedaan onder (2) Upload Messdaten > Formatierung Zeitstempel.

Neem bijvoorbeeld de Okular gegevens:

• Voor het logbestand van de handelingen, is de tijdstempel gecodeerd als YYYY-MM-DD HH:MM:SS (bijv. "2022-10-04 12:32:43.656" in "okularActions.csv").

  In OSCAR is dit gespecificeerd als "%Y-%m-%d %H:%M:%OS" (zie onderstaande schermafbeelding). OSCAR zorgt voor de fracties van seconden.

• Voor de energieverbruiksgegevens, de datum en tijd zijn gecodeerd als DD.MM.YY, HH:MM:SS (e.g., "04.10.22, 12:32:43" in “okular_baseline_eletrLeistung.csv”). Let op de punt in de datum en de komma die datum van tijd scheidt, net zoals dat er maar twee cijfers zijn voor het jaar.

  In OSCAR is dit gespecificeerd als "%d.%m.%y, %H:%M:%OS" (zie onderstaande schermafdruk), waarin de (in kleine letters) “%y” aangeeft dat het om een jaar met twee cijfers gaat.

• Voor de hardwareprestatiegegevens, zijn de tijd en datum gecodeerd als DD.MM.YYYY HH:MM:SS (bijv. "04.10.2022 12:31:43" in "baseline_hardware_formatiert.csv"). Let op de punt in de datum en het viercijferige jaar.

  In OSCAR, is dit gespecificeerd als "%d.%m.%Y %H:%M:%OS" (zie onderstaand schermafdruk), waarin de in grote letters "%Y" aangeeft dat het om een viercijferig jaar gaat.

Specificeren van het formaat van de tijdstempels (Duits: Formatierung Zeitstempel).

Meetgegevens    Nadat de tijdstempels correct gespecificeerd zijn, kunnen we de opmaak van de meetgegevens (Duits: Formatierung Messdaten) ontdekken in OSCAR.

Kijk eerst in de logbestanden van de acties (Duits: Aktionen). Dit gebeurt onder (2) Upload Messdaten > Formatierung Messdaten > Aktionen.

Hier moet u voor het geüploade CSV-bestand het scheidingsteken (Duits: Trennzeichen), het teken dat tekstgroepen afbakent (Duits: Textqualifizierer) en het decimaalteken (Duits: Dezimaltrennzeichen) opgeven.

Voor de Okular gegevens, wordt dit gespecificeerd als een puntkomma als scheidingsteken, aanhalingstekens als omsluiting van en tekenreek en een punt of een komma als decimaalteken (zie onderstaande schermopname).

Bovendien moet u het volgende opgeven:

• of de eerste regel kopteksten bevat (Duits: Erste Zeile enthält Überschriften);
• het aantal regels om over te slaan (Duits: Anzahl zu überspringender Zeilen); en
• de tekencodering (Duits: Zeichensatz (Encoding)).

Voor de Okular gegevens, wordt dit in de onderstaande schermafbeelding als volgt gedefinieerd: “first line contains headings” is niet aangevinkt, 0 regels zijn overgeslagen en de tekencodering is UTF-8.

Wanneer alles correct is gedefinieerd, wordt er een voorvertoning van het werkblad weergeven.

Ten tweede, bekijk het energieverbruiksgegevens (Duits: Elektrische Leistung). Dit gebeurt onder (2) Upload Messdaten > Formatierung Messdaten > Elektrische Leistung.

De benodigde invoer is hetzelfde als voor het logbestand van acties, gezien in de volgende schermopname.

Voor de Okular gegevens, is dit een puntkomma scheidingsteken, dubbele aanhalingstekens als scheidingsteken en UTF-8 als tekencodering. Echter wordt er nu een komma opgegeven als decimaalteken en een vinkje geeft aan dat de eerste regel kopteksten bevat. Tenslotte wordt de eerste regel overgeslagen.

Wanneer alles correct is gedefinieerd, wordt er een voorvertoning van het werkblad weergeven.

Kijk tenslotte naar de hardwareprestatiegegevens (Duits: Hardware-Auslastung). Dit gebeurt onder (2) Upload Messdaten > Formatierung Messdaten > Hardware Auslastung.

De benodigde invoer is hetzelfde. De invoer in dit voorbeeld is een puntkomma als scheidingsteken, een aanhalingsteken als de omsluiting van een tekenreeks en een punt of komma als decimaalteken. Er is een vinkje dat de eerste regel kopteksten bevat, 0 regels worden overgeslagen en de tekencodering is UTF-8.

Echter is er nu de toegevoegde eis dat de kolommen gespecificeerd moeten worden (Duits: Spalten).

Voor de specificatie van de kolommen moet het volgende worden aangegeven: selecteer NA voor ongebruikte kolommen, bijvoorbeeld „Auslastung Auslagerungsdatei” in dit geval.

• Tijdstempel: Datum en tijd (d.w.z. ‘Date-Time’)
• CPU-Auslastung: CPU-gebruik (d.w.z. 'X.CPU.Totl')
• RAM-Auslastung: Werkgeheugen gebruik (d.w.z. 'X.MEM.Used')
• Über Netzwerk gesendet: via netwerk verzonden (d.w.z. ‘X.NET.TxKBTot’)
• Über Netzwerk empfangen: via netwerk ontvangen (d.w.z. ‘X.NET.RxKBTot’)
• Von Festplatte gelesen: van schijf gelezen (d.w.z. 'X.DSK.ReadKBTot')
• Auf Festplatte geschrieben: naar schijf geschreven (d.w.z. ‘X.DSK.WriteKBTot’)
• Auslastung Auslagerungsdatei: Wisselgeheugen (hier, ‘N/A’)

Vertalingen

Hier is een overzicht te vinden van wat Duitse terminologie gebruikt in OSCAR en de Nederlandse vertalingen:

• Messungen: Metingen (d.w.z. passieve modus of SUS)
• Aktionen: Acties (d.w.z. logbestand van uitgevoerde acties)
• Elektrische Leistung: ‘Elektrisch vermogen’ (d.w.z. energieverbruiksmetingen)
• Hardware-Auslastung: ‘hardwarebenutting’ (d.w.z hardwareprestatiemetingen)
• Dauer der Einzelmessungen (s): ‘Duur van de afzonderlijke metingen (s)’ (d.w.z. specificeren hoe lang elke iteratie duurde in seconden)
• Art der Messung: ‘Het soort meting’
  • Leerlauf: ‘Passief (d.w.z. passieve modus)’
  • Nutzungsszenario: ‘Gebruiksscenario’ (d.w.z. SUS)
• Formatierung Messdaten: ‘Opmaak van de meetgegevens’
• Formatierung Zeitstempel: ‘Opmaak tijdstempel’
• Trennzeichen: ‘Scheidingsteken’
• Textqualifizierer ‘Tekenreeks als scheidingsteken’
• Dezimaltrennzeichen: ‘Decimaalteken’
• Erste Zeile enthält Überschriften: ‘De eerste regel bevat kopteksten’
• Anzahl zu überspringender Zeilen: ‘Aantal over te slaan regels’
• Zeichensatz (Encoding): ‘Tekenset (codering)’
• Spalten: ‘Kolommen’
  • Zeitstempel: ‘Datum en tijd’
  • CPU-Auslastung: ‘CPU gebruik’
  • RAM-Auslastung: ‘Gebruik van het werkgeheugen’
  • Über Netzwerk gesendet: ‘Over het netwerk verzonden’
  • Über Netzwerk empfangen: ‘Ontvangen via het netwerk’
  • Von Festplatte gelesen: ‘Gelezen van schijf’
  • Auf Festplatte geschrieben: ‘Geschreven naar schijf’
  • Auslastung Auslagerungsdatei: ‘Gebruik van het wisselbestand’

Stap 3: De rapporten genereren (Passief, SUS)

Nadat het bovenstaande is afgerond, kan het rapport gegenereerd en gedownload worden. U moet dit proces tweemaal uitvoeren, een keer voor (i) de passieve modus en (ii) voor de standaardgebruiksscenariometingen, resulterend in twee documenten.

Voor de Blue Angel-milieucertificering, worden de twee rapporten opgestuurd voor beoordeling door RAL.

Voor voorbeelden van het bovenstaande voor Okular, zie het [Blue Angel toepassingen] archief van KDE (https://invent.kde.org/teams/eco/blue-angel-application):

• OSCAR rapport: passieve mode
• OSCAR rapport: SUS

De documentatie voorbereiden voor Blue Angel

Het is nodig om verschillende formulieren in te vullen naast de twee rapporten van OSCAR voor de Blue Angel-milieucertificering.

Informatie die bijgeleverd moet worden in de formulieren is het volgende:

• Details over de software (naam, versie) en het meetproces (waar en wanneer de metingen gedaan zijn, etc.).
• Technische gegevens over de vermogensmeter (apparaat, bemonsteringsfrequentie, duur van het scenario, steekproefomvang).
• Technische gegevens over het referentiemodel (jaar, model, processor, kernen, etc.).
• Softwarebundel gebruikt voor de metingen (xdotool, Collectl, etc.).
• Minimale systeemvereisten (processorarchitectuur, lokaal werkgeheugen, etc.).
• Energieverbruiksresultaten, gevonden in de OSCAR rapporten of equivalenten.
• Resultaten van het hardwaregebruik, welke het volgende omvatten (gebruik voor ‘IDLE’ de passieve modus metingen en gebruik voor SUS de standaardgebruiksscenariometingen):

  • Volledige belasting: „Wat rekenkracht betreft, is de volledige belasting 100%; voor het werkgeheugen is dit de som van de geïnstalleerde RAM-capaciteiten; voor de netwerkbandbreedte is dit de maximale overdrachtssnelheid, enz.“ (Criteria voor de Blue Angel-onderscheiding: blz. 23).

  • Basis belasting: Gemiddelde lading voor het referentiesysteem in basislijn metingen.

  • Passief/SUS-belasting: Gemiddelde belasting voor het referentiesysteem voor passief/SUS-metingen.

    Vanuit de bovenstaande metingen, zijn de volgende berekeningen gedaan voor hardwaregebruik (gebruik voor IDLE de passieve mode metingen en gebruik voor SUS de standaardgebruiksscenariometingen):

    • Nettobelasting: Belasting in ruststand/SUS - Basisbelasting
    • Toewijzingsfactor: Nettobelasting/(Volledige belasting - Basisbelasting)
    • Effectieve belasting: nettobelasting + toewijzingsfactor * basisbelasting
    • Hardwaregebruik (alleen SUS): effectieve belasting * tijd (seconden)

Voor de Blue Angel-milieucertificering, moet de bovenstaande informatie worden toegevoegd aan twee documenten genaamd “Annex 1” en “Annex 2”.

Voor voorbeelden van het bovenstaande voor Okular, zie het [Blue Angel toepassingen] archief van KDE (https://invent.kde.org/teams/eco/blue-angel-application):

• Annex 1
• Annex 2

Alternatief: Gosund SP111 instellen

Wilt u beginnen met het meten van uw software, maar heeft u beperkte (financiële) middelen? Wilt u het proces proberen zonder een speciaal laboratorium op te bouwen? Probeer deze tip eens om een goedkope stekker om te bouwen tot een stroommeter, met dank aan Volker Krause, die het hier beschreven proces ook heeft gedocumenteerd. U kunt er meer over lezen in de volgende berichten op Volkers blog:

• “Cheap Electric Power Measurement”
• “KDE Eco Sprint July 2022”

Onderstaande is een gids voor het instellen van een Gosund SP111 stekker die reeds geflashed is met Tasmota firmware in 10 stappen.

Hoewel de gegevens van de goedkope vermogensmeter waarschijnlijk niet geaccepteerd zullen worden voor de Blue Angel-milieucertificering, is het hoe dan ook mogelijk om voorlopige gegevens te verzamelen met dit hulpmiddel.

• (0) Voorwaarde

  De stekker moet reeds zijn geflashed met een voldoende recente versie van Tasmota.

• (1) Firmware herstellen

  Als het apparaat eerder is verbonden met een ander Wifi-netwerk, dan kan het nodig zijn om een volledig fabrieksherstel uit te voeren voordat het met een nieuw netwerk kan worden verbonden.

  Als het apparaat een Wifi-toeganspunt heeft geopend genaamd “tasmote-XXXXX”, dan kunt u direct door naar (2).

  Houd de knop ingedrukt voor 40 seconden.

  Het apparaat zal opnieuw opstarten en u moet door kunnen gaan bij (2).

• (2) Wifi instellen

  Het apparaat opent een Wifi-toegangspunt genaamd “tasmota-XXXXX”—verbind daarmee.

  Open http://192.168.4.1 in een webbrowser.

  Het apparaat vraagt u dan om de naam en het wachtwoord van het wifi-netwerk waarmee u verbinding wilt maken. Nadat u deze heeft ingevoerd, maakt het apparaat opnieuw verbinding met dat wifi-netwerk en schakelt het zijn eigen toegangspunt uit.

  Terwijl dat gebeurd, zou het u zijn nieuwe adres moeten laten zien in de browser— noteer dit.

  Als dat niet gebeurde, controleer dan uw Wifirouter voor het adres van het apparaat.

• (3) Tasmota instellen

  Open het adres van stap (2) in een webbrowser.

  U zou de Tasmota webinterface moeten zien (een grote “ON/OFF” tekst, een paar blauwe en een rode knop).

  Selecteer “Configuration”.

  Selecteer “Configure Other”.

  Kopieer

       {"NAME":"Gosund SP111 2","GPIO":
       [56,0,57,0,132,134,0,0,131,17,0,21,0],"FLAG":0,
       "BASE":18}
  

  in het invoerveld van het sjabloon.

  Vink het selectievakje “Activate” aan.

  Selecteer “Save”

  Het apparaat zal herstarten, verbind er opnieuw mee.

  De gebruikersinterface zal nu ook tekstvelden bevatten die elektrische eigenschappen bevatten en de “Toggle” knop zou het nu daadwerkelijk moeten doen.

• (4) Kalibratie

  Open het adres van stap (2) in een webbrowser.

  Sluit een puur ohmse belasting aan met een bekend vermogen, zoals een gewone gloeilamp (geen led- of spaarlamp).

  Schakel de stroom in door op “Toggle” te klikken indien nodig.

  Verifieer dat de “Power Factor” waarde gelijk is aan of dicht bij 1 is; als het lager is, dan is de stroombelasting niet geschikt voor kalibratie.

  Selecteer “Console”

  Voer de volgende opdrachten één voor één in en druk op Enter:

     AmpRes 3  
     VoltRes 3  
     EnergyRes 3  
     WattRes 3  
     FreqRes 3  
     SetOption21 1
     VoltageSet 230
  

  Voer de opdracht PowerSet XXX in, waarbij u XXX vervangt door het vermogen dat is opgegeven voor de testbelasting (bijvoorbeeld „40” voor een gloeilamp van 40 W).

  Selecteer “Main Menu“

  Op de hoofdpagina zouden nu de juiste vermogenswaarden moeten worden weergegeven, met een nauwkeurigheid van meerdere decimalen.

• (5) MQTT-broker instellen

  Op dit moment is polling via MQTT de enige bekende manier om automatische uitlezingen met hoge frequentie te realiseren. Dit is helaas niet ideaal en vereist extra instellingen.

  Als u toevallig al een MQTT-broker tot uw beschikking heeft, ga dan direct door naar stap (6); anders moet u er een instellen. In het onderstaande scenario wordt ervan uitgegaan dat Mosquitto als pakket beschikbaar is voor uw GNU/Linux-distributie (en dus geen beveiligingsinstellingen heeft), dus voer dit alleen uit binnen uw eigen vertrouwde netwerk en schakel het uit wanneer het niet nodig is.

  • installeer het mosquitto pakket

  • maak een bestand /etc/mosquitto/conf.d/listen.conf aan met de volgende inhoud:

     listener 1883  
     allow_anonymous true
    

  • start Mosquitto met systemctl start mosquitto.service

• (6) MQTT Tasmota instellen

  Verbind met het Tasmota apparaat via een webbrowser en open de MQTT configuratiepagina via Configuration > Configure MQTT.

  Vul het IP-adres van de MQTT-broker in in het “Host” veld.

  Noteer de waarde die rechts van het label „Topic“ tussen haakjes staat (meestal iets als „tasmota_xxxxxx“). Deze heeft u later nodig om het apparaat via MQTT aan te spreken. U kunt de standaardwaarde ook wijzigen in iets dat makkelijker te onthouden is, maar deze moet uniek zijn als u meerdere apparaten heeft.

  Selecteer “Save”

  Het apparaat zal herstarten en wanneer het opgestart is dan zou u uitvoer moeten zien in zijn Console voorafgegaan door „MQT”.

• (7) MQTT-communicatie verifiëren

  Hierbij wordt ervan uitgegaan dat u de Mosquitto-clienttools heeft geïnstalleerd, die meestal beschikbaar zijn als distributiepakketten.

  U zult twee terminals nodig hebben om te verifiëren dat MQTT-communicatie werkt zoals bedoeld.

  • Voer mosquitto_sub -t 'stat/<topic>/STATUS10' uit in terminal 1.
  • Voer mosquitto_pub -t 'cmnd/<topic>/STATUS' -m '10' uit in terminal 2.

  Vervang <topic> met de waarde die genoteerd is in stap (6).

  Iedere keer dat u de tweede opdracht uitvoert, zou u een set van waardes afgedrukt moeten zien worden in de eerste terminal.

• (8) Constante vermogenmetingen

  Zie deze scripts.

• (9) Wifi-netwerken wisselen

  Om veiligheidsredenen staat Tasmota, zodra u verbinding heeft gemaakt met een wifi-netwerk, standaard niet toe dat u teruggaat naar stap (2) zonder het apparaat volledig te resetten (40 seconden lang de knop ingedrukt houden). Een harde reset verwijdert echter ook alle instellingen en de kalibratie. Als u naar een ander netwerk moet overschakelen, zijn er minder ingrijpende opties beschikbaar, maar deze wijzigingen kunnen alleen worden doorgevoerd binnen het netwerk waarmee u oorspronkelijk verbinding had gemaakt:

  Onder Configuratie > WiFi configureren kunt u de gegevens voor een tweede WiFi-toegangspunt invoeren. Deze worden standaard afwisselend met de eerste configuratie geprobeerd. Dit heeft geen invloed op de beveiliging, maar u moet wel de gegevens weten van het netwerk waarmee je verbinding wilt maken.

  U kunt Tasmota zo instellen dat het na het opstarten standaard ongeveer een minuut lang een toegangspunt opent, zoals in stap (2), en daarna probeert verbinding te maken met de bekende configuraties. Dit vertraagt het opstarten in bekende netwerken en biedt de mogelijkheid om het apparaat te kapen, maar het kan handig zijn bij het overschakelen naar onbekende netwerken. Deze modus kan in de console worden ingeschakeld met het commando WifiConfig 2 en uitgeschakeld met het commando WifiConfig 4.

  Bij Tasmota-versie 11 kan het apparaat na een reset door 40 seconden lang op de knop te drukken in een toestand terechtkomen waarin het niet meer opstart, terwijl het resetten via de console met Reset 1 dat probleem niet heeft, maar ook moet worden uitgevoerd voordat de verbinding met het bekende wifi-netwerk wordt verbroken.

• (10) Niet opstartende apparaten herstellen

  Allereerst: SLUIT HET APPARAAT NIET AAN OP HET STROOMNET! Dat zou levensgevaarlijk zijn. Het gehele flashproces wordt uitsluitend gevoed door de 3,3 V die door de seriële adapter wordt geleverd. Voer geen van deze handelingen uit zonder eerst deze startgids te hebben gelezen.

  Met Tasmota 11 kunt u in een toestand terechtkomen waarin het apparaat niet meer opstart, simpelweg door het apparaat te resetten door de knop 40 seconden ingedrukt te houden. Dit veroorzaakt geen blijvende schade aan het apparaat en kan worden verholpen door het opnieuw te flashen via een seriële adapter.

  Het basisproces wordt beschreven in de bovenstaande gids. De printplaatindeling van de Gosund SP 111 kan hier worden gevonden.

  Om dit te laten werken, moet u GPIO0 (de tweede pin linksonder in de bovenstaande afbeelding) vóór het inschakelen (d.w.z. vóór het aansluiten via USB) verbinden met GND. De LED's van het apparaat (rood en blauw) geven aan of u in de juiste opstartmodus bent terechtgekomen: de rode LED moet branden en mag niet snel knipperen, en de blauwe en rode LED mogen niet tegelijkertijd branden. Zodra het apparaat zich in die toestand bevindt, kunt u de verbinding verbreken (bijvoorbeeld door een jumperkabel aan de pin vast te houden) en blijft het in de juiste modus totdat het opnieuw wordt opgestart.

  Opnieuw: VERBIND HET APPARAAT NIET MET HET STROOMNET gezien dit levensgevaarlijk is.

(B) Werkzame leeftijd van hardware

De criteria in categorie (B) zorgen ervoor dat de software voldoende lage prestatie-eisen stelt om te kunnen draaien op oudere, minder krachtige hardware die minstens vijf jaar oud is.

Veel FOSS-toepassingen draaien op hardware die al veel ouder is dan vijf jaar. Leden van de KDE-gemeenschap hebben zelfs opgemerkt dat de KDE-desktopomgeving Plasma zelfs op hardware uit 2005 draait!

Aan deze categorie is bij de Blue Angel-aanvraag relatief eenvoudig te voldoen. Om aan de eisen te voldoen, moet een verklaring van achterwaartse compatibiliteit worden afgegeven, inclusief details over de hardware waarop de software draait en de vereiste softwarestack. Om aan te tonen dat aan de eisen wordt voldaan, dient u de volgende informatie vast te leggen in twee documenten, genaamd „Annex 1” en „Annex 2”:

• Referentiesysteem jaar — bijv., 2015
• Type — bijv., Fujitsu Esprimo 920
• Processor — bijv., Intel Core i5-4570
• Kernen — bijv., 4
• Kloksnelheid — bijv., 3,6 GHz
• Werkgeheugen — bijv., 4 GB
• Opslag (SSD/HDD) — bijv., 500 GB
• Videokaart — bijv., Intel Ivybridge Desktop
• Netwerk — bijv., Realtek Ethernet
• Cache — bijv., 6144 KB
• Moederbord — bijv., Fujitsu D3171-A1
• Besturingssysteem — bijv., Ubuntu 18.04

Opnieuw zijn er voorbeelden voor Okular te vinden via de volgende links:

• Annex 1
• Annex 2

(C) Gebruikersautonomie

Zoals besproken in DEEL II, omvatten de criteria voor gebruikersautonomie van Blue Angel acht algemene gebieden:

1. Gegevensformaten
2. Transparantie
3. Continuïteit van ondersteuning
4. Verwijderbaarheid
5. Offline mogelijkheden
6. Modulariteit
7. Vrijheid van advertenties
8. Documentatie

Veel FOSS-projecten gaan er wellicht van uit dat vrije software de autonomie van de gebruiker respecteert, maar in sommige gevallen ontbreekt informatie uit de bovenstaande lijst op websites, in handleidingen, op wiki’s, enzovoort. Het kan hierbij gaan om documentatie over ondersteuning van open standaarden, de mogelijkheid om het programma te verwijderen, de continuïteit van de ondersteuning, enzovoort.

Deze gegevens documenteren is belangrijk, zowel voor het voldoen aan de Blue Angel-onderscheiding als om gebruikers informatie te verstrekken over het duurzame gebruik van hun software en hardware op de lange termijn.

Dit is geen volledige uiteenzetting van iedere van de bovenstaande categorieën van de Blue Angel-eisen. Eerder is dit een gids die zich richt op de aspecten van de eisen die KDE/FOSS-projecten makkelijk kunnen documenteren en leveren (wat al het grootste deel van het werk is). Voor de volledige lijst aan eisen, zie Sectie 3.1.3 in de basic award criteria.

2.1 Gegevensformaten

De voornaamste gegevens om bij te sluiten in de documentatie:

• Welke (open) gegevensformaten ondersteund zijn—met links naar specificaties, bijv. PDF?
• Ook interessant: Zijn er andere voorbeelden van softwareproducten die deze gegevensformaten verwerken?

Bezoek de Okular website voor een voorbeeld van de online documentatie van de ondersteunde formaten van Okular.

Een voorbeeld van documentatie voor de Blue Angel kan worden gevonden in Annex 4.

2.2 Transparantie van het softwareproduct

Wanneer ontbrekend, voeg links toe van de documentatie van de API, de broncode en de softwarelicentie. Bijvoorbeeld voor KMail:

• KDE PIM API documentatie
• Broncode
• Licentie

Een voorbeeld voor documentatie voor Blue Angel kan worden gevonden in Annex 5.

2.3 Continuïteit van ondersteuning

Details over continuïteit van ondersteuning om te documenteren omvatten:

• Informatie over hoelang de software al ondersteund is (met links naar uitgave aankondigingen).
• Uitgave planning en details (bijv. wie de software onderhoudt).
• Verklaring dat updates gratis zijn.
• Verklaring over hoe licenties voor vrije en open-bron-software continue ondersteuning oneindig lang mogelijk maken.
• Informatie over of en hoe functionele en beveiligingsupdates onafhankelijk geïnstalleerd mogen worden.

Een voorbeeld van Okular's continuïteit van de ondersteuningsdocumentatie voor Blue Angel kan worden gevonden in Sectie 3.1.3.3 van Annex 6.

2.4 Verwijderbaarheid

Hoe kunnen gebruikers de software volledig verwijderen? Relevante gegevens kunnen omvatten:

• Verwijderingsinstructies die afhangen van hoe de software geïnstalleerd was (broncode of binair bestand).
• Voorbeelden van verwijderingsinstructies (broncode of pakketbeheerders, met relevante links naar de documentatie).
• Informatie over of door gebruikers gegenereerde gegevens ook worden verwijderd bij het verwijderen van een programma.

Een voorbeeld van Okular's verwijderingsdocumentatie voor Blue Angel kan worden gevonden in Sectie 3.1.3.4 van Annex 6.

2.5 Offline vaardigheden

Vereist de software externe verbindingen als een licentieserver om te draaien? Zo niet, en geen netwerkverbinding is benodigd gezien de software offline kan worden gebruikt, dan zou dit niet gedocumenteerd moeten worden.

Een voorbeeld van Okular's documentatie over offline-functionaliteit voor Blue Angel kan worden gevonden in sectie 3.1.3.5 van Annex 6.

2.6 Modulariteit

Informatie om bij te sluiten omvat:

• Welke aspecten van de software zijn modulair en kunnen uitgeschakeld worden tijdens installatie?
• Kunnen de handleidingen of de vertalingen van de software apart worden geïnstalleerd?
• Zijn er modules die niet irrelevant zijn voor de kernfunctionaliteit meegeleverd met de installatie, zoals trackingmodules of integratie met de cloud? Zo niet, documenteer het!

Een voorbeeld van Okular's modulariteitsdocumentatie voor de Blue Angel kan gevonden worden in sectie 3.1.3.6 van Annex 6.

2.7 Vrij van reclame

Als de software geen reclames weergeeft, maak dit dan expliciet duidelijk in de handleidingen en wiki's en verklaar dit in het aanvraagformulier voor de Blue Angel

2.8 Documentatie

Dit omvat het volgende:

• Het algemene proces voor het installeren/verwijderen van de software? Dit kan algemene instructies omvatten of handleidingen voor een specifieke bureaubladomgeving of pakketbeheerder.
• Data importeer/exporteer proces?
• Wat kan de gebruiker doen om het systeembronnengebruik te verminderen (bijv. configuraties om prestaties te verbeteren)?
• Heeft de software enige functies die veel systeembronnen vereisten die niet nodig zijn voor de kernfunctionaliteit? Zo niet, geweldig! Laten we het de gebruikers vertellen!
• Licentievoorwaarden gerelateerd aan verdere ontwikkeling van de softwareproducten, welke leiden tot broncode en licentie?
• Wie ondersteunt de ontwikkeling van de software?
• Verzamelt de software persoonlijke gegevens? Komt het overeen met bestaande gegevensbeschermingswetten? Zo ja, documenteer het!
• Wat is de privacyverklaring? Is er telemetrie? Zo ja, hoe gaat de software om met gegevensveiligheid, gegevensverzameling en gegevensuitwisseling? Zijn er bovendien advertenties of trackingfuncties in de software ingebouwd? Zo niet, geweldig— zorg er dan voor dat je het verder vertelt!

Een voorbeeld van Okular's productdocumentatie voor Blue Angelcertificering kan gevonden worden in sectie 3.1.3.8 van Annex 6.

Indienen bij RAL

Voor voorbeelden van alle bovenstaande documentatie, zie de Blue Angel Applications opslagruimte van KDE.

Wanneer u alle documentatie hebt voorbereid, dient u het op te gegeven voor beoordeling bij RAL gGmbH (indien u het herinnert, RAL is de bevoegde instantie die beoordeelt of aan de toekenningscriteria wordt voldaan). Het portaal voor het opgeven van Blue Angelapplicaties kan hier (https://portal.ral-umwelt.de/) worden gevonden.

Als u hulp nodig heeft met de online interface, biedt RAL documentatie aan.

Voorbeelden van in te dienen documenten

Hieronder vindt u voorbeelden van Blue Angel-documentatie voor Okular.

• Annex 1: Formulier
• Annex 2: Werkblad
• Annex 3: OSCAR rapport voor rustmodus
• Annex 3: OSCAR rapport voor SUS
• Annex 4: Gegevensformaten
• Annex 5: Open standaarden
• Annex 6: Product informatie
• Annex 7: Gegevensformaat voor het doorgeven van productinformatie over systeembronnen-en energie-efficiëntie

Opmerkelijke initiatieven op het gebied van duurzame software

Er zijn veel initiatieven die werken aan hulpmiddelen voor het meten van het energieverbruik van software. We willen er vijf in het bijzonder opnoemen die met het KDE Eco initiatief hebben samengewerkt.

• The Green Software Engineering werkgroep at the Environmental Campus Birkenfeld (German: Umwelt Campus Birkenfeld)

  Sinds 2008, heeft de Green Software Engineering werkgroep gewerkt aan onderzoeksprojecten met een focus op duurzame software. Hun onderzoek biedt de basis voor het werk hier en hun team heeft hulpmiddelen als OSCAR ontwikkelt en heeft verscheidene KDE-programma's doorgemeten, zoals Okular.

• Öko-Institut e.V.

  Het Öko-Institut is een van de toonaangevende onafhankelijke onderzoeks- en adviesorganisaties in Europa die zich inzetten voor een duurzame toekomst. De onderzoeksgroep Duurzame Producten & Materiaalstromen werkt aan verschillende meetmethoden. In deze blogpost (in het Duits) presenteren onderzoekers een techniek voor zelfmeting met behulp van een eenvoudig Python-script.

• Green Coding Berlin

  Green Coding Berlin is gefocust op onderzoek naar de energieconsumptie van software en diens infrastructuur, waarmee open bron meethulpmiddelen worden gemaakt en op het maken van een gemeenschap en ecosysteem rondom groene software.

• Het SoftAWERE project van de Sustainable Digital Infrastructure Alliance

  De stuurgroep SoftAWERE houdt toezicht op de ontwikkeling van hulpmiddelen en keurmerken voor energie-efficiënte softwaretoepassingen en bepaalt de koers daarvan.

• Green Web Foundation

  De Green Web Foundation volgt en versnelt de transitie naar een internet zonder fossiele brandstoffen.

Info over

Auteurs

De KDE Eco-tools en -documentatie worden verzorgd door leden van de gemeenschap die zich vrijwillig hebben ingezet voor dit project, ten behoeve van iedereen. Tot de belangrijkste bijdragers behoren (in alfabetische volgorde op voornaam): Arne Tarara, Cornelius Schumacher, Emmanuel Charruau, Karanjot Singh, Nicolas Fella, en Volker Krause. Hartelijk bedankt— jullie bijdragen hebben dit handboek mogelijk gemaakt.

De tekst van deze versie van het handboek is geschreven en/of samengesteld op basis van de bovengenoemde documentatie door Joseph P. De Veaugh-Geiss. Olea Morris heeft de tekst bewerkt. Lana Lutz en Arwin Neil Baichoo hebben gezorgd voor het prachtige ontwerp van het boek en de website, evenals voor de afbeeldingen daarin. Paul Brown heeft aanzienlijke verbeteringen aangebracht aan de Okular-blogpost die is aangepast voor „Okular, het eerste eco-gecertificeerde computerprogramma” in deel II. Wikipedia was een bron voor verschillende teksten die hier in aangepaste vorm zijn opgenomen. Dank aan de gemeenschap van Wikipedia-schrijvers en -redacteuren voor het creëren van zo’n prachtige bron voor ons allemaal. Zie het einde van elke paragraaf voor aanvullende informatie over bronnen.

Erkenningen

Bedankt voor de vele bijdragers van het KDE Eco initiatief in het algemeen (gerangschikt in alfabetische volgorde op voornaam): Achim Guldner, Adriaan de Groot, Aleix Pol, Alexander Semke, André Pönitz, Björn Balazs, Carl Schwan, Chris Adams, Christopher Stumpf, David Hurka, Fabian, Felix Behrens, Franziska Mai, Harald Sitter, Jens Gröger, Johnny Jazeix, Jonathan Esk-Riddell, Kira Obergöker, Lydia Pintscher, Marina Köhn, Mathias Bornschein, Max Schulze, Phu Nguyen, Sami Shalayel, Stefan Naumann, Sven Köhler, en Tobias Fella. Jullie bijdragen worden ten zeerste op prijs gesteld.

Mensen die willen bijdragen aan KDE Eco worden aangemoedigd om zich aan te melden voor de mailinglijst of de Matrix-room. Bijdragers worden ook uitgenodigd om deel te nemen aan een van de KDE Eco-sprints en fysieke of online bijeenkomsten. Meer informatie is te vinden op onze website.

Het KDE Eco-initiatief heeft veel gehad aan de vele verhelderende discussies die plaatsvonden tijdens de volgende conferenties en workshops: Akademy 2022, Linux App Summit 2022, FOSDEM 2023, rC3: NOWHERE 2021, SFSCon 2021/2022, Grazer Linuxtage 2022, Qt World Summit 2022, QtDevCon 2022, Fedora Nest 2022, Green Coding Berlin-bijeenkomsten, de hackathon van de Sustainable Digital Infrastructure Alliance, EnviroInfo 2022 en Bits & Bäume 2022. Hartelijk dank!

Licentie

Tenzij anders aangegeven, valt alle inhoud onder de Creative Commons Attribution-ShareAlike 4.0 International (CC-BY-SA-4.0) licentie. Voor meer informatie over licenties bij KDE, zie het licentiebeleid van KDE.

Financieringsopmerking

Het project Blauer Engel Für FOSS werd gefinancierd door het Duitse federale milieuagentschap (UBA) en het federale ministerie voor milieu, natuurbehoud, nucleaire veiligheid en consumentenbescherming (BMUV). De financiering werd beschikbaar gesteld door een besluit van de Duitse Bondsdag.

De uitgever is verantwoordelijk voor de inhoud van deze publicatie.