© pixelnest, 123RF

Energie-effiziente Hardware ist seit vielen Jahren im Handel, im Bereich der Software steht die Forschung hingegen noch am Anfang. Eine neue, im Auftrag des Umweltbundesamtes erstellte Studie, will das ändern. Das Linux-Magazin wirft einen Blick auf Methoden und Ergebnisse.

Schonender Umgang mit den endlichen Ressourcen – das ist in vielen Bereichen des Wirtschaftskreislaufs bereits eine anerkannte Forderung, auch im ITK-Sektor. Er betrifft sowohl die Herstellung als auch den Lebenszyklus von Produkten inklusive der Entsorgung.

Bei der Software aber fehlen belastbare Überlegungen, welche Ressourcen sie beanspruchen darf und wie sie sich umweltfreundlicher entwickeln und nutzen lässt. Das will das deutsche Umweltbundesamt ändern. Eine neue Methodik soll dabei helfen, Software zu bewerten.

Software frisst Hardware

Bereits seit vielen Jahren erforschen zahlreiche nationale wie multinationale Organisationen die Ressourceneffizienz von ITK-Infrastrukturen. Die unter dem Stichwort Green IT zusammengeführten Aktivitäten widmen sich bislang aber überwiegend Hardware-spezifischen Problemstellungen. Mit Kennzeichnungen wie dem Energy Star, dem Blauen Engel oder dem EPEAT-Ökolabel weisen sich entsprechende Geräte als besonders ressourcenschonend aus.

Wie sich Software auf den Energieverbrauch auswirkt, vernachlässigen diese Betrachtungen aber in der Regel. Die vorherrschende Meinung in der Fachwelt ist jedoch, dass Software einen entscheidenden Einfluss auf die gesamte Energiebilanz ausübt. Das tut sie nicht nur im direkten Einsatz, sondern auch indirekt. Ihr stetig wachsender Ressourcenverbrauch erfordert zyklische Neuanschaffungen von Hardware.

Weil geeignete Methoden und daraus resultierende Standards fehlen, steht die Forschung zur Ressourceneffizienz von Software noch ganz am Anfang. Das Umweltbundesamt befasst sich seit 2011 mit dem Problem. 2014 gab es im Rahmen eines Fachgesprächs eine erste Diskussion. An einem 2015 ins Leben gerufenen Forschungsprojekt beteiligen sich unter Leitung des Öko-Instituts die Hochschule Trier und die Universität Zürich. Dieses Projekt hat bis zum Jahr 2018 Grundlagenforschung für ressourceneffiziente Software betrieben.

Mit der Studie “Entwicklung und Anwendung von Bewertungsgrundlagen für ressourceneffiziente Software unter Berücksichtigung bestehender Methodik” fanden diese Arbeiten im Herbst 2018 einen vorläufigen Abschluss [1]. Langfristiges Ziel der Forscher ist, die Bewertungsgrundlagen zu standardisieren und eine Zertifizierung ähnlich der des Blauen Engels für Software zu entwickeln.

Vorgehensweise

Für die Studie entwickelten die Projektpartner der drei Institutionen insgesamt acht Arbeitspakete. Die wurden jeweils von einem der Partner bearbeitet. Während die Universität Zürich einen methodischen Ansatz entwickelte, beschäftigte sich die Hochschule Trier primär damit, Fallbeispiele, ein Erfassungswerkzeug sowie eine Auswertungssoftware zu entwickeln, die Hardware-Auslastung und Energieverbrauch misst.

Das Öko-Institut entwarf einen Leitfaden, der sich mit der Beschaffung von Software und Handlungsempfehlungen für die Schaffung eines Umweltzeichens ähnlich dem Blauen Engel beschäftigte. Das in Freiburg ansässige Institut leitete das Projekt zudem und definierte ein Referenzsystem für den Einsatz von Standardsoftware.

Als solches schlug es für das zu vergebende Umweltzeichen den so genannten Baden-Württemberg-Personal-Computer (BW-PC) ab dem Baujahr 2010 vor. Diesen PC spezifiziert die Universität Freiburg seit dem Jahr 2007, er kommt per Rahmenvertrag an den Hochschulen Baden-Württembergs zum Einsatz.

Kriterien

Der Kriterienkatalog für die Forschungsarbeiten legt den Fokus auf Standard-Applikationen, die im Büroalltag auf Arbeitsplatzrechnern laufen. Im Zentrum steht die Nutzungsphase der Software. Die Studie stützt sich dabei auf ein Modell des Ressourcenflusses. Das nimmt einerseits einen Hardwarefluss an, der von der Beschaffung neuer Hardware bis zu deren Ausmusterung und Entsorgung reicht. Andererseits geht sie von einem Energiefluss aus, der parallel dazu während des Einsatzes der Software entsteht.

Dank eines längeren Betrachtungszeitraums berücksichtigt die Studie auch Software-Updates, die möglicherweise die Obsoleszenz der Hardware beeinflussen. Ebenso bezieht sie das Nutzerverhalten mit ein, von dem die Inanspruchnahme der Hardware und somit auch der Energiebedarf abhängen.

Die Aspekte, um den Ressourcenbedarf zu ermitteln, schränkt die Studie dabei ein. Die benötigten Ressourcen von externen Systemen, etwa der von Servern oder der Netzinfrastruktur in einer Client-Server-Umgebung, nimmt sie mit in die Perspektive auf. Dies tut sie aber nur, sofern diese in unmittelbarem Kontext zum Büroarbeitsplatz und der darauf ausgeführten Software stehen. Firmware oder Ressourcen, die Peripheriegeräte beanspruchen, fallen daher aus der Betrachtung heraus.

Auch die beim Entwickeln einer Software benötigten Kapazitäten berücksichtigt die Studie mangels Quantifizierbarkeit nicht. Die Verfasser weisen zudem darauf hin, dass sie keine messbaren Einsparpotenziale quantifizieren und auch nur grobe Kriterien für die Standardisierung eines Umweltzeichens entwickeln. Die kann der Auftraggeber bei Bedarf entsprechend erweitern. Um Messungen und Ergebnisse besser nachvollziehbar zu machen, steht der direkte Energieverbrauch eines Systems im Fokus, wobei allein Referenzhardware zum Einsatz kommt.

Um die Software vor dem Hintergrund der Erhebungskriterien zum Ressourcenbedarf aussagekräftig zu bewerten, musste die Studie auch diese selbst klassifizieren. Dem tragen die Autoren Rechnung, indem sie die zu betrachtenden Softwareprodukte in vier Klassen einteilen: Neben lokal auf einem Arbeitsplatzsystem installierter Software berücksichtigt sie auch Serversysteme und solche mit entfernter Datenhaltung und entfernter Datenverarbeitung.

Je nachdem, wo der Dienst läuft und die Daten verarbeitet oder speichert, verschieben sich die Lastgewichte und der Ressourcenbedarf. Sie wandern vom lokalen Client über die Netzwerkinfrastruktur zur Datenübertragung hin auf das Serversystem.

Um den Ressourcenbedarf zu messen, haben die Projektpartner Standardnutzungsszenarien definiert. Die basieren auf dem Kriterienkatalog und einer Auswertung der entsprechenden Fachliteratur. Sie simulieren dabei in jeder Produktgruppe eine möglichst praxisnahe Nutzung. Dabei wickelt die Software standardisierte Aufgaben ab, während die Tester Energiebedarf und Inanspruchnahme der Hardware messen. Sie prüfen die Software ohne Plugins oder Erweiterungen und setzen das Referenzsystem nach jedem Durchgang wieder auf den ursprünglichen Zustand zurück.

Für die einzelnen Nutzungsszenarien (siehe Tabelle 1) absolvierten die Projektpartner dabei 30 Messdurchläufe je Szenario. Die von den Projektpartnern entwickelte Mess-Software gewährleistet dabei mit Hilfe von Zeitstempeln, dass die Messergebnisse synchron bleiben. Zugleich landen die Zeitstempel für die einzelnen Mess-Schritte in einer Logdatei, um diese später einzelnen Aktionen zuzuordnen.

Testablauf

Für die Studie wählten die Forscher vier Softwaregruppen, die die Anwendungsszenarien widerspiegeln: Neben zwei Textverarbeitungsprogrammen untersuchten sie drei Webbrowser und drei Datenbanken sowie drei Content-Management-Systeme (CMS). Während sie Textverarbeitungen und Webbrowser lokal einsetzten, fielen die CMS und ihre Datenbanksysteme in die Kategorie der Server-basierten Anwendungen.

Auf der jeweiligen Client- und Server-Hardware, den so genannten Systems Under Test (SUT), installierten die Forscher zunächst ein Betriebssystem-Image, dem alle die Messergebnisse verfälschenden Prozesse wie Virenscanner, Backup- oder Indizierungsroutinen fehlten.

Im nächsten Schritt ermittelten sie die Grundauslastung der Systeme, wozu Arbeitsspeicherbedarf, Massenspeichernutzung, CPU-Auslastung und die Belastung der Netzinfrastruktur zählten. Sie installierten die jeweilige Anwendungssoftware auf dem System Under Test und starteten sie. Dann zeichneten sie den Ressourcenbedarf im Leerlauf für jedes einzelne Programm auf. Dabei setzten sie unter Linux auf »collectl« [2], das in der Regel in den Paketquellen der gängigen Distributionen steckt.

Die einzelnen Teilschritte der Standardnutzungsszenarien fassten sie in einem so genannten Lasttreiber zusammen. Der simuliert typische Anwendungsabläufe bei der Nutzung der Software durch einen menschlichen Anwender.

Den Ressourcenbedarf der SUT-Rechner maßen und zeichneten sie während des Einsatzes des Lasttreibers auf, wobei sie zugleich die einzelnen Hardwarekomponenten im Auge behielten. Die Rohdaten wanderten in eine speziell entwickelte quelloffene Auswertungssoftware namens Oscar (Open Source Software Consumption Analysis in R, [3]), die die Daten automatisiert auswertete.

Daneben entwickelten die Projektpartner ein Werkzeug unter anderem für die Calc-Tabellenkalkulation. Letztere speichert die Indikatoren eines reduzierten Kriterienkatalogs und erlaubt den Im- und Export von Daten im XML-Format. Das Werkzeug dient der Analyse und Bewertung der Energie-Effizienz von Software (Abbildung 1).

Abbildung 1: Der Testaufbau: Der Lasttreiber (links unten) simuliert den Nutzer der Anwendung, die lokal oder auf dem Server des SUT (System Under Test) läuft. Quelle: Hochschule Trier

Ergebnisse

Nachdem sie die Grundauslastung der SUT-Rechner erfasst hatten, maßen die Forscher den Ressourcenbedarf der installierten Anwendungen im Leerlauf ohne simulierte User-Interaktionen. Dabei bemerkten sie teils markante Unterschiede im Ressourcenverbrauch.

So zeigte eine der beiden getesteten Textverarbeitungen nach dem Start eine mehr als doppelt so hohe CPU-Auslastung (rund 4 Prozent) als das quelloffene Konkurrenzprodukt (rund 2 Prozent). Auch bei der RAM-Auslastung zeigte die proprietäre Textverarbeitung einen höheren Ressourcenbedarf als das freie Konkurrenzprodukt (Abbildung 2).

Abbildung 2: Bei der Hardware-Auslastung zeigen die beiden Textverarbeitungen Differenzen: Links ist die proprietäre zu sehen, rechts die quelloffene. Quelle: Hochschule Trier

Bei den untersuchten Webbrowsern fiel das Ergebnis noch deutlicher aus: Während hier die beiden freien Softwareprodukte im Vergleich zur Grundauslastung eine jeweils um knapp 1 Prozent höhere CPU-Belastung verursachten, zeigte das proprietäre Produkt eine um 12,3 Prozent höhere Auslastung der CPU.

Die drei quelloffenen CMS-Applikationen wiesen praktisch keine zusätzliche CPU-Belastung im Vergleich zur Grundauslastung auf. Größere Unterschiede ergaben sich aber beim Arbeitsspeicherbedarf. Die CMS zeigten zudem signifikante Unterschiede bei der Auslastung der Massenspeicher und der übertragenen Datenmengen. Hier fiel eines der Produkte auf, weil es sowohl den Massenspeicher auf Server und Client intensiv auslastete und größere Datenmengen über die Netzinfrastruktur verschob. Wie sich herausstellte, verkleinerte das CMS seine Bilder nicht auf die Anzeigegröße im Webbrowser des Clients, sondern lud diese vom Server in voller Größe und Auflösung.

Einstellungssache

Die Forscherteams verglichen außerdem den jeweiligen Energieverbrauch der SUTs unter Last mit ihrem Grundverbrauch. Dabei stellten sie zum Beispiel bei den Browsern fest, dass die Grundauslastung zwischen etwa 80 und 91 Prozent des gesamten Energiebedarfs ausmachte (Abbildung 3). Der Energiebedarf eines Softwareprodukts teilt sich dabei zu jeweils annähernd gleichen Anteilen zwischen der lokalen CPU-Auslastung, der Belastung der Netzinfrastruktur sowie lokalen oder entfernten Massenspeicherkapazitäten auf.

Abbildung 3: Die Grundauslastung bestreitet bei den Browsern einen Großteil der Gesamtauslastung. Quelle: Hochschule Trier

Ein weiteres wichtiges Kriterium bestand darin, zu prüfen, inwieweit die Anwendungen automatisch Einstellungen zu benötigten Hardwarekapazitäten modifizieren oder Dialoge zur manuellen Anpassung bereitstellen. Dabei zeigte sich, dass keines der Produkte eine automatische Minimierung des Ressourcenbedarfs vorschlägt. Textverarbeitungen und Webbrowser bieten immerhin Einstelloptionen, über die Anwender den Energiebedarf teilweise steuern.

Besonders die Webbrowser können durch das Abschalten aufwändiger Startseiten, die bei jedem Programmstart oder dem Öffnen neuer Tabs erscheinen, ressourcenschonender arbeiten. Bei Datenbanksystemen lässt sich durch das Ausschalten diverser Indizierungsroutinen der Energiebedarf senken. Nur bei den CMS-Systemen konnten die Forscher keine Module ausmachen, deren Deaktivierung die Energie-Effizienz erhöhen würde.

Weiter wurde erforscht, inwieweit die betrachteten Softwareprodukte einen zeitgesteuerten Energiesparmodus unterstützen und ihn automatisch anwenden. Dabei standen naturgemäß die lokal installierten Produkte im Fokus. Ergebnis: Diese schalten durchgängig nach einer definierten Zeitspanne der Untätigkeit automatisch in einen Energiesparmodus.

Transparenz

Für die Energie-Effizienz eines Produkts betrachtete die Studie als weiteres Kriterium die Abwärtskompatibilität der Softwarepakete abhängig vom verwendeten Betriebssystem. Dieses Kriterium musste die Studie höchst unterschiedlich bewerten: Während viele Linux-Programme keine festen Mindestanforderungen an das Alter des Betriebssystems stellen, gibt es unter Windows meist solche Angaben. Einige Windows-Anwendungen liefen noch auf einem 15 Jahre alten OS als Plattform. Unter Linux kamen laut den Messungen maximal zehn Jahre alte Betriebssystemversionen als potenzielle Plattformen in Frage.

Auch die Transparenz der Software hinsichtlich ihre Lizenzierung und Möglichkeiten der Weiterentwicklung durch den Nutzer nahmen die Forscher unter die Lupe. Hier spielten die quelloffenen und einer freien Lizenz unterliegenden Softwarepakete ihre Überlegenheit wenig überraschend voll aus. Zugleich machten die Forscher aber klar, dass sich eine Auswirkung des offenen Quellcodes auf den Energiebedarf nicht als “generelle Regel” beurteilen lasse, sondern als Indikator “stark kontextabhängig” sei.

Zur Transparenz zählen auch der Umgang mit Sicherheitslücken durch Hersteller und Entwickler sowie die Anzahl gefundener Sicherheitslücken anhand der CVE-Datenerhebungen [4]. Hier punktete die freie Software, sie lässt sich länger gefahrlos einsetzen.

In einem weiteren Arbeitsgang erforschten die Projektteams, inwieweit eine rückstandsfreie Deinstallation der jeweiligen Software möglich ist, was unter “Nutzungsautonomie” fällt. Hier blieben bei allen Probanden auf den lokalen SUTs noch Rückstände. Bei den Server-seitigen Applikationen mussten die Nutzer die Daten durchgängig manuell entfernen, da automatische Routinen fehlten. Beim Wiederherstellen von Daten boten die lokalen Applikationen durch die Autosave-Optionen mehr Flexibilität als die Server-seitig genutzten.

Umweltzeichen

Die Autoren der Studie plädieren am Ende dafür, ein Umweltzeichen für ressourceneffiziente Software einzuführen. Ihre Studie beweise, dass diese messbare Unterschiede aufweist. Die Effizienz beim Ressourcenverbrauch lasse sich anhand standardisierter Kriterien und Indikatoren für jedes Softwarepaket messen.

Die Autoren betonen auch, dass die Untersuchungsergebnisse der Studie nur ein erster Schritt zur Messung der Ressourceneffizienz sein können. Sie halten weitere Forschungen für nötig, um den Kriterienkatalog zu verbessern und zu vervollständigen. Zudem seien weitere Standardnutzungsszenarien nötig, um diese auf Referenzsystemen zu testen, was mit noch größerem Forschungsaufwand verbunden sei.

Fazit

Die Projektteams unter Leitung des Öko-Instituts haben Standardkriterien definiert, um die Ressourceneffizienz von Software festzulegen. Dazu gehören ebenfalls typische Nutzungsszenarien, die den Zertifizierungsprozess für ein Umweltzeichen erheblich vereinfachen.

Dabei erheben die Autoren nicht den Anspruch, anhand der Messergebnisse ein Urteil zu den getesteten Software-Applikationen zu fällen: Die Studie hat als Proof of Concept ihre Berechtigung, kann jedoch aufgrund der schmalen Datenbasis mit nur jeweils einem Testsystem keine Aussage zur generellen Energie-Effizienz der geprüften Softwarepakete treffen. Um aussagekräftigere Verbrauchswerte zu erhalten, müssten die Forscher mehrere Referenzsysteme mit aktuellerer Technik einsetzen, wie sie moderne Software nutzt.

Ein Kritikpunkt betrifft den generellen Versuchsaufbau: Zwar erwähnt die Studie, dass auf dem Arbeitsplatzsystem auch Ubuntu Linux 16.04.1 LTS zum Einsatz kommt. Für das freie Betriebssystem liefert sie jedoch keine Messwerte.

Auf Nachfrage des Linux-Magazins teilte der betreuende Fachrichtungsleiter mit, dass die in der Studie genannten Messergebnisse auf dem Client-SUT tatsächlich nur unter Windows 7 Pro 64 Bit SP1 entstanden seien. Als Voraussetzung für die Zertifizierung mit einem Umweltzeichen soll jedoch die Interoperabilität von Softwarepaketen Gegenstand des Kriterienkatalogs sein. Künftig müssen die Forscher die entsprechenden Produkte daher unter allen relevanten verfügbaren Betriebssystemen testen, um hierbei sicher Unterschiede zu bemerken.

Nicht zuletzt wäre es im Sinne der Nachvollziehbarkeit zu begrüßen, wenn die getesteten Produkte klar beim Namen genannt würden. Der Schritt würde Mutmaßungen und Verschwörungstheorien von vornherein den Wind aus den Segeln nehmen.