Week of 5–9 October 2026
I keep coming back to the same question when reading about the energy transition: how do we actually scale a system as large as the power grid?
The obvious answer is physical. More generation. More batteries. More substations and power lines.
But I think there is another part of the answer that is easy to miss.
In software engineering, we distinguish between horizontal scaling - adding more machines - and vertical scaling - increasing the capacity of existing machines. The power grid is not a cluster of servers, but I find the distinction useful here too.
Horizontally, we need more generation, storage, substations, lines and connections. That means more assets, planning models, engineering tools and organizations that need to work together.
Vertically, we need to make better use of the infrastructure we already have through measurements, forecasting, flexible demand and smarter control. The analogy is not exact: these approaches do not simply upgrade a power line the way we add CPU or RAM to a server. They help the system operate more intelligently within its physical limits.
Both directions create software problems.
This week’s developments gave me several good examples.
Main signal: the grid needs an interoperability layer
On 7 October, the Linux Foundation announced OpenGrid, a new open-source initiative focused on electricity-grid planning.
The motivation is straightforward: planning the grid is becoming more difficult just as we need to build it faster.
According to the IEA’s Electricity 2026 outlook, global electricity consumption is projected to rise from about 28,200 TWh in 2025 to 33,600 TWh in 2030. That is roughly 19% growth in five years. Almost quarter. It is an enormous amount of additional electricity to produce, deliver and manage.
And the bottleneck is already visible. The IEA reports more than 2,500 GW of renewable generation, storage and large-load projects stalled in grid-connection queues worldwide.
The grid is also becoming more distributed. Instead of planning around a relatively small number of large power plants and predictable consumers, engineers increasingly have to consider solar installations, wind farms, batteries, electric vehicles, data centres and flexible industrial loads.
Many more participants. Many more possible operating conditions.
This is where it starts to look like a software architecture problem.
The problem behind the announcement
Imagine an engineer studying what will happen if a region adds a new battery park, several solar installations and a large industrial consumer.
They need network topology, equipment parameters, load and generation forecasts, connection requests, and assumptions about future operating conditions. They may use several modelling tools, each with its own representation of the network.
Now the engineer needs to move a model from one tool into another.
What happens to identifiers, units, equipment definitions, assumptions, or the relationships between network elements?
Can another team reproduce the result? Can a regulator inspect the model? Can someone compare two scenarios without rebuilding everything by hand?
These are familiar questions for software engineers. We have seen them in databases, APIs, distributed systems and data pipelines.
The difficulty is no longer only solving the electrical equations. It is getting the right engineering information into the right tool, preserving its meaning, and being able to trust the result.
That is the problem OpenGrid is trying to address.
The proposed foundation includes shared schemas and standards, programmatic APIs, integrations, and a Data Hub for validated, model-ready datasets. Its first planned application, OpenGrid Translator, is intended to move data and models between commercial and open-source planning tools, with a release targeted for 2027.
The main focus of OpenGrid now is interoperability between grid-planning tools.
And it is not yet a finished platform. The initiative has launched; much of the proposed architecture still has to be built and proven.
Why I find it interesting
There is a pattern here that I recognize from software engineering.
As a system grows, connecting its parts becomes a problem of its own. At first, you can build a custom converter, export a file or agree on an internal format. Eventually there are too many participants and too many combinations.
At that point, shared models and well-defined interfaces stop being conveniences. They become infrastructure.
The power grid cannot be scaled by software alone. We still need copper, steel, transformers and years of physical construction.
But if planning tools cannot exchange and validate the information needed to build that infrastructure, software itself becomes another bottleneck.
I like the idea of applying open-source collaboration and explicit interoperability contracts to that layer of the power system.
The question now is whether OpenGrid can move beyond a good architectural proposal into models, adapters and workflows that engineers actually trust and use.
Around the grid
Getting more out of existing power lines
Building more grid infrastructure is one way to increase capacity. But sometimes the existing infrastructure can be used more intelligently.
On 6 October, Portuguese grid-technology company Enline published a white paper on Dynamic Line Rating at the distribution edge.
A power line has thermal limits. The current flowing through it generates heat, while wind, air temperature and other conditions determine how effectively it cools.
Traditionally, operators often work with ratings based on conservative assumed conditions.
Dynamic Line Rating (DLR) estimates how much current a line can safely carry under the actual or forecast conditions.
If the weather allows better cooling, there may be more thermal headroom. If conditions become worse, the safe rating may decrease.
The interesting part is the software around it:
measurements and weather data → thermal model → calculated rating → operational decision
Yes, the paper is vendor-authored, so I would treat its projected investment savings as claims to investigate rather than settled results.
But anyway, the architectural direction is clear: more data about a physical asset can change how much useful work we can safely get from it.
“More data” …. sounds so familiar 🙂
What if a data centre could become a flexible load?
There is another way to make better use of existing grid capacity: change demand rather than the line.
On 8 October, Reuters examined efforts to make data-centre electricity consumption more flexible.
The idea is to temporarily reduce or shift some computing workloads when the electricity system is under pressure.
Some data centres may be able to reduce peak consumption by around 10–30%, according to the examples discussed in the report. That is not a universal capability. Critical workloads, service commitments, cooling, on-site power systems and the duration of a request all limit what can actually be shifted.
From a software perspective, the question is fascinating.
A scheduler normally decides where and when work runs according to computing resources, deadlines and availability.
What happens when electrical-grid conditions become another scheduling input?
Now the data centre’s workload orchestrator, energy-management system and grid operator may need to coordinate.
It is another kind of scaling: instead of increasing the capacity available at every instant, make parts of demand flexible enough to fit the capacity we have.
Big technology companies are moving closer to the power system
Two announcements this week caught my attention for different reasons.
On 6 October, Google and Constellation Energy announced a long-term collaboration. The agreement supports 890 MW of additional nuclear capacity through upgrades at existing reactors, alongside a separate long-term 2,700 MW supply agreement.
The companies also announced a technology partnership involving Google Cloud and Gemini Enterprise for energy applications, including infrastructure planning, asset optimization and reliability.
These are agreements and plans, not evidence that an AI system is already autonomously controlling the grid.
On 8 October, Anthropic launched its Cyber Mission, including a Critical Infrastructure Defense Program focused on operational technology - the control systems, industrial networks and software used by power grids and other physical infrastructure.
These are not the same kind of investment.
Google is involved because its computing infrastructure needs enormous amounts of reliable electricity. Anthropic is approaching the sector through cybersecurity capabilities and partnerships.
But the direction is worth watching.
The technology industry is no longer only consuming electricity and building software for other software companies. It is becoming more deeply involved in how energy infrastructure is financed, operated, analysed and protected.
That creates opportunities, but also new dependencies worth understanding.
Worth watching: cybersecurity has to catch up with grid software
All the developments above show what more software can do for the grid. But there is another side to this growth that concerns me.
I think cybersecurity is becoming one of the most urgent engineering challenges for modern power infrastructure.
Consider how the IT industry got here. Cloud platforms did not become reasonably good at isolating workloads, controlling identities, deploying updates, monitoring failures and responding to incidents overnight. Those practices evolved over years of building complex systems, defending them against attacks and learning from failures. And even today, cloud providers are far from immune to security problems.
Now look at what is happening in energy.
The industry is connecting more and more equipment to cloud services, remote-management platforms, APIs and software-update systems. Solar inverters, batteries, EV chargers and industrial controllers increasingly behave like nodes in a huge distributed software system.
But much of the physical infrastructure was designed in a different world: long equipment lifetimes, controlled access, limited connectivity and very strict availability requirements.
This does not mean that the energy sector has no cybersecurity experience. OT engineers have worked on network segmentation, secure operations and industrial security for decades. Standards such as IEC 62443 are part of that work.
My concern is more specific: the software architecture is changing faster than the security practices around the whole connected system can mature.
A good example appeared on 7 October, when the Dutch Rijksinspectie Digitale Infrastructuur (RDI) published a position paper about high-power IoT: connected inverters, chargers, home batteries and heat pumps.
One device is not necessarily the problem. The interesting risk appears when thousands of devices depend on the same software platform.
cloud service → authenticated command or software update → device fleet → aggregate electrical load or generation
If a platform is compromised, or a faulty update reaches a large fleet, the consequences may no longer be confined to one customer or one device. A shared software failure could produce a shared physical effect. That is a risk scenario, not a claim that such a grid-wide incident has already happened.
The RDI argues that cybersecurity requirements should take into account how much electrical power can be influenced through remote control. That is a different way to think about the importance of a software system.
And this is where simply borrowing cloud practices is not enough.
A cloud provider can often isolate a service, deploy a fix and roll back a release relatively quickly. A protection relay, inverter or industrial controller may need extensive validation and a carefully planned maintenance window. An update that breaks the software is not just an availability incident; it can affect the physical process.
Still, we need the same underlying engineering discipline: strong identity and authorization, limited privileges, trustworthy updates, observability, containment, incident response and the ability to recover safely.
We are turning power infrastructure into an increasingly complex distributed software system. Its security maturity has to catch up quickly - without forgetting that this system cannot be operated like an ordinary cloud cluster.
That seems to me just as important as connecting more assets or using existing capacity more efficiently.
The thread I see this week
At first, these stories appear to point in different directions.
OpenGrid wants planning tools to exchange models.
Dynamic Line Rating wants to extract more usable capacity from existing lines.
Flexible data centres want to adjust their consumption to grid conditions.
Technology companies are investing in energy and its software.
Cybersecurity regulators are asking what happens when many physical devices depend on shared digital infrastructure.
But I see a common engineering problem: the grid needs to scale not only its hardware, but also the software systems that describe, coordinate and protect that hardware.
Horizontal scaling needs trustworthy models and interoperability.
Making better use of existing capacity - the vertical side of this analogy - needs measurements, forecasting and control.
And both require security that grows with the system’s complexity.
We cannot solve the energy transition by writing better software. But I increasingly doubt we can solve it without better software.
That is the part of modern power infrastructure I want to keep investigating.
See you next week.
- Dmytro
Software in the Grid explores how software actually works inside modern power infrastructure - from protocols and networking to SCADA, cybersecurity, distributed systems and software architecture.
Software in the Grid is an independent publication. The views expressed here are my own.