Efficient software is resilient software. GreenCode reduces what critical systems demand of their power supply and hardens the code that runs them, so they stay up for longer on backup, depleting or intermittent power.
View full sizeSoftware efficiency is usually argued as a cost or a carbon question. In systems that must not stop, it is a survival question. A system that draws less power runs for longer on whatever power is left, and a system that has been properly tested is less likely to be the thing that fails. Both of those are engineering properties of the code, and both are normally left to chance.
The systems that need this are not exotic. Hospitals, aerospace platforms, electric vehicles, traffic control, water and sanitation, utilities, telecommunications and financial infrastructure all depend on software running on power that is constrained, isolated, backed up or simply not guaranteed. In an aircraft or an electric vehicle the energy budget is fixed and carried on board, so every watt the software wastes is range or endurance lost. In a hospital running on emergency generation the fuel is finite and the load is whatever the equipment and the systems behind it demand.
Two pressures are moving in the wrong direction at once. The US Government Accountability Office reported in 2021 that climate change is expected to have far-reaching effects on electricity grid resilience, with more frequent and more severe disruption to generation, transmission and distribution. Separately, reporting in Health Science Reports in 2023 described healthcare providers facing the energy crisis with rising costs and an increased reliance on contingency supply.
The renewable transition adds a third factor that is welcome but real: supply that varies with weather and time of day. A system designed around constant, abundant power behaves differently when the power is intermittent. Efficient software is the cheapest way to widen that margin, because it changes the demand rather than the supply, and it can be deployed to equipment already in the field.
Resilience is not only about energy. The CrowdStrike incident of July 2024, in which a faulty update disabled Windows machines worldwide and disrupted airlines, hospitals and payment systems for days, is the clearest recent illustration of what inadequately validated software costs when it reaches critical infrastructure. It was not a power failure or an attack. It was a change that was not caught.
That failure mode is well understood in the literature. Analysis of four decades of completed software projects shows that compressed delivery schedules introduce defects, and ISO/IEC 25010 treats reliability and maintainability as measurable quality characteristics rather than aspirations. Research on developer choices confirms that the same functionality written differently consumes measurably different amounts of energy on the same server. Quality and energy are two readings from the same underlying property: how well the software was built.
GreenCode's pipeline attacks both halves. It begins with quality baselining, mapping the codebase and generating the unit tests, in-code documentation and external documentation that critical legacy systems are usually missing, so that behaviour is pinned down before anything is altered. Static analysis against recognised quality and security criteria produces a worklist, and a combined measure of quality issues, security flaws and error rate is checked at every pass and must not rise. Improvements that would trade reliability for speed are rejected by the gate, not by a reviewer's judgement.
It then removes the energy hotspots. The application is benchmarked on a reconstruction of its own infrastructure, the code, architecture and configuration responsible for the load are identified, and generative AI refactors them, with the result re-measured until the saving is verified. The project targets a net reduction of more than 15 per cent per software product, delivered as reviewable pull requests so that a human in the loop approves every change to a system that matters. For the operator, the outcome is the same workload on a smaller power envelope, which is more runtime on a generator, more range in a vehicle, and more headroom when the grid is unstable.
The same efficiency enables capability rather than just survival. Software that needs less compute and less memory allows sensing, control and AI workloads to run on edge and IoT hardware in places where the compute and the power are both scarce, and to do more of the work locally instead of shipping it to distant infrastructure. That reduces dependence on the network link, which in a disaster or a conflict is often the first thing to go, and it supports the resilient infrastructure aim of UN Sustainable Development Goal 9. It also keeps the existing hardware viable for longer, which is covered under device lifetimes.
Peak demand matters as much as total energy. In a simple bench illustration, changing only how a sorting routine referred to memory on a microcontroller cut its peak current by about 30% and its energy by more than two thirds. A device whose software draws less at its peak can run from a smaller supply or battery, or keep going for longer on backup power, which is exactly the margin a critical system needs when the supply is constrained.
An operator of critical systems gets three things: a codebase with the tests and documentation its risk profile requires, a measured reduction in what that software demands of its power supply, and evidence of both that can be shown to a regulator or an assurance team. Tooling for exactly this kind of constrained, safety-relevant software is one of the deliverables GreenCode will bring out of the project, and partners are trialling it on aviation, automotive and utility systems.
To discuss a critical-systems use case, get in touch through the contact page.
