Small changes, big impact: green software engineering in embedded systems

Did you know that on a mobile phone, an application sending data over 3G uses 1.7 times the energy of completing the same task over Wi-Fi, while using 4G is 1.3 times the power consumption of 3G?

In the development of technology, the resources that tech uses in production and operation are coming under increasing scrutiny. Whether it is a heating system, an electric bike, a drone, or an insulin pump: consumption and sustainability are issues that embedded device manufacturers and embedded software engineers need to face.

Sustainability pressure

Globally, many companies are looking to improve the sustainability of their operations across a range of factors that support ideas of corporate responsibility. This is happening in a context with pressure from a multitude of groups such as governments, regulators, and consumers. And some companies are choosing to be a part of initiatives like the United Nations’ Global Compact or supporting the UN’s Sustainable Development Goals. There’s also increasing pressure from investors  for businesses to pursue ways to be more sustainable.

“Right to repair” movements in the US, Europe and Australia, which includes legislation, have also placed pressure on companies to consider this aspect of sustainability as well. Right to repair legal battles are more than just about people being able to fix their iPhones, it includes products aimed at industry such as farm machinery.

And while software might seem like an unlikely contender to help with sustainability, it can have a marked impact on the environmental operations of businesses and consumers. From climate change to scarce natural resources: choices made in software engineering can mount up and have wide reaching consequences.

Green software engineering, done right, is a means to help with the environmental impact of technology.

What is green software engineering?

Typically, green software engineering is seen as just a way to help with energy use. In one paper on attitudes to green software engineering, it was described as:

“[The] process of helping practitioners (architects, developers, testers, managers, etc.) write more energy efficient applications.”

But when you consider what makes up embedded systems, from the rare earth materials that are used to make hardware to how software runs on an embedded system: there’s more than just the opportunity to affect energy efficiency. Though energy efficiency still has the biggest role to play in embedded software.

Where are the opportunities to make embedded software greener?

There are a host of areas where small changes in software can add up to decreasing the environmental impact of a product. Here is a list (not exhaustive) of where software can make a difference:

Energy and carbon footprint

Decisions in requirements for connectivity (to use Ethernet, Wi-Fi or 4G), how run time uses energy, how and what information about the device is displayed, how the product handles crashing and the overall user experience (UX): all have a role to play in energy efficiency. In the case of connectivity, as stated at the start of this blog, there are huge energy use differences between different wireless protocols, whereas wired ones use less energy. This all adds up—we might be making decision across 100,000 devices where 1 watt on one device grows to a 100 kilowatt difference.

For the actual product, the following aspects can be affected by programming to reduce energy use and the overall carbon footprint of a device:

• Run time energy efficiency
  • Using low power modes
  • Real energy-saving screen savers
  • Managing processor performance
  • Optimising motor control
  • Balancing the approach to encryption and security
  • Avoiding superfluous code
• Wireless v wired
• Power management and battery management
  • Efficiency of charging and discharging
  • Preserving battery life
• Footprint of product usage
  • Diagnostics to user about waste, for example giving read outs for energy and other aspects of usage—like chemical dosing on a pump system.
• UX (considering the impact of design choices on human behaviour)
  • Features
  • Better defaults, for example defaults of 50% brightness on displays, power save modes entered into after two minutes of inactivity.
  • Diagnostics, for example human readable alerts for software or hardware faults. This helps people to understand when they do not need to replace a whole device—like a mobile phone when the SD card is faulty rather than the phone being at fault. Or a bearing that’s worn out in a washing machine and having a readout that says that.
• Reliability
  • Crashes cause energy waste—both direct and indirect. For example, if a crash leaves the device on, but not functioning as intended, it is still using energy.

Material usage and waste

The actual materials used to make embedded systems include a whole host of rare metals and other materials, that all cost energy and water to extract, process and eventually manufacture. Being mindful of hardware choices and their interaction with software can again help companies to ensure greener software and hardware.

Here are some of those interactions where waste and materials savings can be made with software:

• Future proofing processor performance
  • Abstraction layers, Real-Time Operating Systems (RTOSs) v custom optimised solutions—often, a custom optimised solution is what allows for much better usage of the underlying hardware.
• Rare metals—making sure a machine lasts as long as possible.
• Maintainability—how easy is it repair and maintain.
  • Diagnostics for repair and maintenance
  • Moving away from programmed obsolescence
• Wear on physical parts
  • For example, good brushless motor software optimisation ensures a motor lasts by reducing vibrations that increase wear.
• File and data size—more memory is more materials and more energy.
  • Code size
  • Data

The tensions of pursuing greener software

While any of the areas in our list can be impacted by software, there are areas where product and software development need to strike a balance with environmental needs.

Here are areas where this balance creates tension:

Binary v text—energy v habitability

Habitability of software is important for ease of software development, testing and debugging. But ensuring software is easy to work in can increase the computational load of a system, increasing the energy needed by it.

In the case of system logs, for instance, outputting as JSON (JavaScript Object Notation) is human readable, but unlike binary it takes up more space and storage plus it takes longer to transmit. So, while human readable, it uses more power and needs more memory available, compared to BSON (Binary JSON).

Security v energy

Securing devices uses energy, at least securing at the code level does. The calculations necessary to enable cryptography are energy intensive. Obviously, security is necessary in many embedded systems, and so the code here needs to be optimised as much as possible. But we also need to think about the bit size of the encryption keys used. If you don’t need to go as far as 256 bits, you can save computational power and therefore energy (link goes to PDF) by choosing a smaller key standard.

RTOSs—increased load on processor v better power management

RTOSs (Real-Time Operating Systems) are big and represent lots more code to run, and often require bigger processors or more memory. Despite this, they are a good way to utilise power saving features of the hardware. It needs to be a good quality operating system, tailored for the target hardware and it needs to be configured properly, in order to make the most of its energy saving features.

How do you start to enable greener software that has a positive environmental impact?

Being aware of what can impact the energy use by a system and its overall sustainability is a good first step.

Here are some ways where you can start to have a practical environmental impact in creating green software:

Environmental champion

Have someone on the team who comes to meetings, such as Three Amigos meetings, and is an environmental champion. They don’t have to come up with solutions, they just need to point out when features and requirements need to be considered for their environmental impact.

Taking the time to assess environmental impact

Features and requirements need to be considered in light of what they mean to the overall environmental impact of a product. If you need connectivity—does it need to be wireless? If you need a display, does it need to be on all the time?

Good UX practices

Spend time carrying out UX research so that you end up with the kinds of feedback systems and default settings that work with how the user works. Many users never switch from default settings and so it’s a good opportunity to ensure that energy saving is happening as a part of that default. You also need to observe how the software design then goes on to impact human behaviour. Like, what happens with short screen saver times—do users end up disabling a default feature? (This is where UX research can really help.)

Make energy usage visible to the user

For consumer level products this might not be so in-depth, just a simple readout offering feedback that informs them enough to help them to change their behaviours. For industry this can help businesses have actionable data that they can use to help plan further sustainability efforts across their whole business.

Review non-functional requirements every sprint

Environmental elements of software like energy efficiency or data size can be asked for as metrics. And these metrics can be removed at the end of each sprint or stage of software development.

If your product team has concluded that battery life is an important aspect of your product, then it’s something that you can have your software team include as a metric. Software release reports can include data on this metric to see how the software is performing on it.

Visual environmental metrics on your information radiator

To help stakeholders see how software is impacting on various environmental elements, it’s also worth creating an information radiator of your metrics. (Just don’t leave them running on screens overnight when nobody is going to look at them.)

Less bloat: Test-Driven Development (TDD)/refactoring, code reviewing

Software in embedded systems doesn’t exactly have room for bloat (and the less bloated it is the less resources it uses, the smaller the processor it needs). But bloat can happen over the course of development and then in future updates, especially if habitability is poor.

TDD can help encourage refactoring. It’s important to give software engineers time to refactor code so that it is as efficient as it can be and removes technical debt. Code reviews will help spot these issues and ensure inefficiencies are identified.

Good product ownership practices, including ruthless feature selection

When there is a mountain of power-hungry features that could be included in a product, product owners need to be “Ruthless”. This comes from the idea of being DRIVEN:

• Decisive
• Ruthless
• Informed
• Versatile
• Empowering
• Negotiable

Being ruthless means ditching superfluous features and challenging decisions like “do we need wireless?”.

Small changes, big impact

No one of the changes suggested in this blog post can hugely impact the sustainability of a product. Instead, what’s important to remember is that doing many of these, even a small amount, can add up and make a difference.

The idea here is “marginal gains”, where small changes have an effect in aggregate over the long term. In embedded systems, this can mean that every watt saved can make a real difference when we’re talking thousands, hundreds of thousands or even millions of devices.