Software Life Cycle Assessment – ​​Why an Electricity Meter Is Not Enough

[suchona.kani.z]

Anyone who looks into the environmental impact of digital solutions quickly comes across frightening statistics on how much CO2 emissions they indirectly cause. Estimates range up to a share of 6% of global CO2 emissions, although the realistic range is more likely to be in the range of 2 to 4%. In some publications, one also reads estimates that these emissions due to digital infrastructure will rise to 23% of global emissions by 2030. "Estimates" is unfortunately the key word here. Neither CO2 emissions nor the power consumption of all IT worldwide can actually be measured. Despite historically high levels of networking and automation, reliable data is often lacking to back up estimates with facts. In this blog post, we look at why such estimates are difficult and what is already possible today to measure the CO2 emissions of digital solutions.

How does software life cycle assessment work?
There is currently no uniform standard for measuring the environmental impact of software. Common practice in companies is to assign a factor to IT expenditure and extrapolate it to CO2 emissions. Similar methods macedonia consumer email list can be seen in mobile phone apps, for example, where private individuals can calculate their personal footprint based on their expenditure. Even if the weaknesses of this approach are obvious, it is impressive because it is easy to implement.

More advanced techniques include the use of electricity meters on the main consumers in the system - as required by the Blue Angel - or the measurement of CPU time, as in this example from the Öko-Institut. Measuring the utilization of the central processing unit (CPU) is considered a good guideline for the electrical power consumption of software.

The decisive factor in measurement is always testing under real conditions. Calling up a single website once does not represent a realistic usage scenario. In order to obtain reliable data, one or more standard usage scenarios must therefore always be defined that generate a representative load on the system being tested while it is being measured.