My first job in software was at Fluentgrid, building applications for electricity distribution utilities. Distribution management, outage management, SCADA integration — grid topology models, meter data, network segments, and the workflow tools operations engineers used to run all of it.
The mental model in that work was fixed: the substation was hardware you configured. Protection relays and intelligent electronic devices were physical boxes with settings, commissioned by engineers with laptops in cabinets. Our software talked to them, modelled them, reported on them. It did not run them.
That assumption is inverting, and two announcements from this February make it concrete enough to talk about specifically.
What GE Vernova's launch actually signals
In February, GE Vernova launched GridOS for Distribution, described as a unified solution for grid orchestration, built on a governed, federated grid data fabric and unifying ADMS and DERMS with network modelling, field execution and visual intelligence (press release).
Strip the marketing vocabulary and the interesting claim is architectural. Historically these were separate products with separate data models: the ADMS knew the network and ran outage and switching management; the DERMS knew about distributed resources; the GIS held the asset model; the planning tools held yet another version of the network. Every integration between them was a data reconciliation project, and I have watched more than one utility programme where the real deliverable was making three systems agree on what the network looked like.
Putting a governed data fabric at the centre says the model is the product and the applications are consumers of it. That is the right call, and it is the same conclusion the rest of enterprise architecture reached about a decade earlier under different names.
It is also the hardest part, for a reason specific to this domain: the network model is not a static reference. It changes with every switching operation. A feeder reconfigured at 2am means the topology your applications reason about is different from the one in the planning database, and connectivity determines whether a calculation is right or dangerously wrong. Utilities that treat network model management as a data-quality chore rather than an operational system discover this during their first serious storm.
The substation as a COTS server
The second announcement is the one that genuinely surprised me.
Siemens introduced SIPROTEC V at DISTRIBUTECH in February — a software-defined protection and control system that consolidates the functions of up to 60 hardware IEDs onto a single commercial off-the-shelf server running real-time Linux, with claimed capital cost reductions around 25%. GE Vernova is moving in the same direction with GridBeats, a portfolio of software-defined grid automation explicitly aimed at reducing device footprint in substations.
This is not a vendor experiment. There is an industry body — the vPAC Alliance — organised around standards-based, interoperable, software-defined architecture for hosting protection, automation and control in substations.
What makes it possible is a standard I spent time on early in my career without appreciating where it led. IEC 61850, and specifically the 9-2 process bus with merging units, converts analogue current and voltage measurements into digital sample streams on Ethernet. Once the measurements are packets rather than copper, the thing consuming them does not have to be a box bolted next to the switchgear. It can be a process on a server.
Which is exactly the move automotive made: signal-oriented buses to service-oriented networks, functions consolidated from dozens of ECUs onto central compute. The grid is running the same play about a decade later, with higher consequences and a longer asset life.
What does not transfer
Having watched the automotive version up close, the differences matter more than the similarities.
| Software-defined vehicle | Software-defined substation | |
|---|---|---|
| Timing requirement | Milliseconds, mostly soft | Protection must trip in milliseconds, hard |
| Consequence of failure | Serious | Equipment destruction, arc flash, injury |
| Asset life | ~15 years | 20–40 years |
| Update appetite | OTA normalised | Every change is a commissioning event |
| Fallback | Degraded driving mode | There is no degraded protection |
The timing constraint is the one that makes this genuinely hard rather than merely new. Protection is not a control loop you can be late for — a fault has to be cleared before it damages equipment or hurts somebody. Running that on a general-purpose OS means your real-time guarantees now depend on kernel scheduling, on the hypervisor if there is one, and on the assurance that a co-hosted workload cannot steal the CPU cycles the protection function needed.
That is the same freedom-from-interference argument automotive programmes make when they put a safety partition and infotainment on one chip — and it is expensive to demonstrate, and far more expensive to demonstrate late. The difference is that in a substation, the argument has to convince a protection engineer whose professional judgement is on the line, and who has thirty years of evidence that hardware relays work.
I would take that scepticism seriously rather than treat it as resistance to change. The instinct is well earned.
DER orchestration is the actual forcing function
None of this is happening because software people wanted a nicer architecture. It is happening because the physics changed.
The distribution grid I wrote software for was radial and one-directional: power flowed from substation to customer, and the models assumed it. Rooftop solar, batteries, EV charging and controllable load break that assumption. Flow reverses. Voltage rises at the edge. The network's operating envelope now depends on thousands of devices nobody owns.
You cannot manage that with a system whose model updates nightly. It needs near-real-time state, forecasting, and the ability to dispatch or curtail resources at the edge — which is what a DERMS is for, and why the ADMS/DERMS convergence in GridOS is more than product packaging. Once resources at the edge participate in operating the network, keeping their management separate from network operations means two systems making decisions about the same physical thing.
<!-- The unglamorous foundation under all of it: an SCL file describing a
logical device and its data. Substation engineering has always been
configuration-as-code — the industry just called it commissioning.
Virtualisation does not create this discipline; it inherits it, and
makes version control and review non-negotiable rather than optional. -->
<IED name="BAY_01_PROT">
<AccessPoint name="S1">
<LDevice inst="PROT">
<LN lnClass="PTOC" inst="1" lnType="OvercurrentType">
<DOI name="Str"><DAI name="stVal"/></DOI>
</LN>
</LDevice>
</AccessPoint>
</IED>
Security stops being a layer
Consolidating sixty devices onto one server consolidates the attack surface too, and the sector's security framework — IEC 62351 for energy systems, alongside the regulatory regimes utilities operate under — was written when the devices were physically separate and largely unroutable.
Three things follow that anyone building here should plan for from the start:
- Patching becomes an operational process with a safety case. A protection function is not a web service you can restart. Update cadence has to be designed, not assumed.
- Identity and attestation for software components. The server must refuse to run a protection function whose provenance it cannot verify. This is the same hardware-root-of-trust argument I would make for any device fleet, with materially higher stakes.
- Segmentation between co-hosted functions has to be demonstrable, not architectural intent.
What I would tell a utility team
Fix the model before buying the applications. A federated data fabric is only as good as the network model it governs. If your GIS, ADMS and planning systems disagree today, orchestration software will make that disagreement faster rather than resolve it.
Treat substation configuration as code, properly. SCL files are source. They belong in version control, with review and a diff history. Most utilities I encountered kept them in a folder on a share drive, and could not answer what changed between two commissioning visits.
Pilot virtualisation where the consequence is lowest. Not on the transmission protection scheme. Start where a failure is an inconvenience, build the operational muscle, and let the protection engineers set the bar for when they are convinced.
Do not skip the boring integration work to get to the AI. Visual intelligence over grid imagery is genuinely useful — vegetation management and damage assessment are real, expensive problems. But it sits on top of an asset model and an inspection workflow, and those are where the effort actually goes.
I find this the most interesting thing happening in enterprise software right now, and I am aware that is partly sentiment. When your first job is writing software where a mistake means somebody's lights go out, you keep a particular kind of respect for systems that have to work. Watching that domain absorb the architectural ideas I have spent the last decade applying elsewhere — service orientation, data as a product, infrastructure as code — is a good reminder that those ideas were never really about software delivery velocity. They were about managing consequence.