A Guide for Assessing Greenhouse Gas Emissions Related to Software

The upcoming ICT Sector Guidance document of The Greenhouse Gas Protocol® Product Life Cycle Accounting and Reporting Standard will contain a guide for assessing greenhouse gas emissions of software products. This post gives a short summary of the software related aspects of the current draft.

The guide is available at http://www.ghgprotocol.org/feature/ghg-protocol-product-life-cycle-accounting-and-reporting-standard-ict-sector-guidance.


The second draft of the ICT Sector Guidance of The Greenhouse Gas Protocol Product Life Cycle Accounting and Reporting Standard, available since February 2013, contains in chapter seven a guide for assessing the GHG emissions impact of software products.

The standard is developed by the Greenhouse Gas Protocol initiative, founded in 1998 by the World Business Council for Sustainable Development (WBCSD, head office in Geneva/Switzerland, http://www.wbcsd.org) and the World Resources Institute (WRI, head office in Washington D.C./USA, http://www.wri.org).

The first sub chapters of the ICT Sector Guidance document relate the life cycle phases of life cycle assessment to software products and show how the impacts of the different phases can be assessed in a comprehensive life cycle assessment study. This is part A of the guide.

The following sub chapters form part B. They give a deep insight into methods to measure and calculate the energy consumption of software run on consumer and server devices. These are therefore of high interest for software architects and developers who want to know how changes to their software architecture and implementation impact the GHG emissions of a specific use case during the usage stage of their software product.

Regarding the importance of the emissions from software, the guide ascertains that software accounts for the majority of the energy consumed by ICT. Unfortunately, if the impacts of a software product with high numbers of sold installations is compared to the overall impact of the information system, it turns out that the impacts from software development will not be significant enough to be considered in detail. On the other hand, for software with only a few installations, especially bespoke software, the impacts from development can be significant. In this case it is advisable to determine the necessity for a detailed assessment of the software development phase by a preliminary assessment study.

The chapter closes with a short summary of five case studies and a detailed description of a measurement method.

Part A) Life Cycle Assessment of Software

In part A of the guide, the assessment is done according to the life cycle phases commonly known from life cycle assessment: “material acquisition and pre-processing”, “production”, “distribution and storage”, “use”, and “end of life”.

Software developers usually make use of several software libraries (developed either in-house or by third-parties) to ease development. These libraries usually become an integral part of a software product and should therefore be considered as raw materials, which means that their upstream emissions have to be considered. This is not an easy task because up to now developers usually do not have detailed assessments for foreign libraries. The guide proposes to estimate these figures from other estimates, e.g. person-years development effort or size/lines of code. These aspects relate to the material acquisition and pre-processing phase.

The production phase corresponds to the regular software development and testing process. Here the usual emissions of office work have to be considered, e.g. heating, lighting, air-conditioning, electricity of required ICT systems, stationery, and business travel. Regarding the allocation of these resources, an emissions factor on the basis of person-years can be calculated to get the total emissions regarding the humane-resources actually used during development and testing. Two things should be mentioned here: according to international standards on carbon footprint, the upstream emissions of capital goods (e.g. buildings, IT equipment necessary to write source code, continuous integration servers, source code management systems) and the emissions of commuting employees should not be considered1,2.

The distribution/storage phase comprises efforts for deployment, installation, training, and user acceptance testing as well as the distribution/delivery of the software. The latter one requires to include the IT equipment that is necessary to deliver the software, e.g. download servers, network use and the use of the end-user’s computer for downloading. If the product is also distributed on a data medium, these impacts of this distribution channel are assessed by a usual life cycle assessment study.

The usage phase is covered by part B and is discussed in the next section.
The end of life phase has only impacts, if the software product is distributed on a data medium that has to be recycled or disposed of.

Part B) Energy Consumption of Software Usage

Part B provides methods to assess the first-order impacts (see post Effects of Information and Communication Technology on Sustainable Development) of the usage phase of a software product, which mainly is energy consumption. The emissions from the production of the device where the software under assessment is running on are not considered by the presented methods.

The objective of this chapter is to provide methods to calculate the energy consumption of software that are more accurate as the idle, average and maximum power consumption values usually used in life cycle assessment studies. Therefore, it presents several methods to measure and/or assess operating systems, applications, and virtualized systems.

Regarding operating systems, the guide defines an Idle benchmark to measure the energy consumption of the computer system in idle mode as a baseline. This baseline is used by the other methods to calculate the energy consumption of the software as the difference of the baseline consumption and the consumption when the software is running. A power state benchmark can be used to get the baseline if the system resides in a specific power state. To get the maximum power consumption, assessors should refer to industry standard benchmarks. If benchmarking tests are not available, assessors may use secondary data from the Energy Star product database.

The application measurement method measures tasks that are performed with one or a set of applications. A task usually includes opening and closing the required application programs, except for task where the programs are typically already open when the task is being performed. If a set of applications is measured, it is necessary to record the CPU utilization per application to be able to allocate the energy consumption properly.

The virtualized systems measurement method tries to assign the power consumption of the server to the single running virtual machines according to their CPU utilization. This enables the assessment of tasks running within virtual machines.


Concluding, the ICT Sector Guidance provides some good starting points for life cycle assessments of software development processes and for the assessment of the energy consumption of software. Where the former is of particular interest for bespoke software with only a “few” installations, the latter is of high interest for software that has many installations, and therefore has high greenhouse gas emissions due to the power consumption in total.

Unfortunately, in my opinion, it is questionable whether the measurements presented in part B will significantly improve the usage phase estimations of part A by replacing the power consumption estimation, which rely usually on idle and average power consumption from secondary data sets, with real and precise but costly measurements. The reason for that are the remaining uncertainties regarding the assumed usage profiles (e.g. 8 hours per work-day, for 2 years of operation) and the expected number of sold installations/licenses. Who knows exactly whether the expected sales target will eventually be reached or whether the average user will use the software for the estimated duration?

In my opinion, the real advantage of the measurements is that it enables us developers to build software that performs well on slower or simpler and therefore more energy efficient devices. It seems also to be a good way to remind software developers to produce efficient code, because inefficient code will likely consume more energy. This is also closely related to effects where developers produce inefficient code under pressure but cannot improve it anymore (due to time and budget reasons) and so the inefficient code is left to be solved by next year’s more powerful hardware generation.

Finally, a growing share of corporations adapt and integrate sustainable product design principles in their decision, design, and production processes. Consequently, software developing corporations cannot ignore these developments for the very reason that software has such a huge influence on the energy demand of IT devices.

Further Reading

  1. ISO/DIS 14067.2 [Under development]: Carbon footprint of products -- Requirements and guidelines for quantification and communication. ICS 13.020.40, International Organization for Standardization, 2014-04-15
  2. PAS 2050:2011: Specification for the assessment of the life cycle greenhouse gas emissions of goods and services. ICS 13.310; 91.190, British Standards Institution, 2011. http://shop.bsigroup.com/en/forms/PASs/PAS-2050 [download available at no charge; providing your business contact is mandatory]

NOTE: “GHG Protocol” and “The Greenhouse Gas Protocol” are Registered Trademarks