Control Follows Assets: Classifying Microgrids by What They Are Made of

The conversation about microgrid control has run ahead of the conversation about what is being controlled. The IEEE 2030.7 standard specifies the functions of a microgrid controller, and it does so for functions common to all microgrids, regardless of topology, configuration, or jurisdiction. That generality is deliberate and, for interoperability, correct. It also lets the control discussion float free of the hardware, and that is where the practical problem starts.

‍I argue the relationship runs the other way. Control follows assets. The control architecture a microgrid needs is set by the physical assets on the ground, not chosen independently of them. Decide what generation, storage, and nodes a site has, and the control requirement follows. Start from the controller and you are specifying a system before you have said what it is made of.

‍One clause matters as much as the principle. Control follows the asset trajectory, not the asset snapshot. It follows the assets a site will have, not only the assets it has today. That distinction holds most of the engineering judgment, and it is the next section.‍ ‍

The controller is the asset you buy early

‍The principle has an apparent exception, and it is worth meeting directly, because it is the first thing an experienced engineer will raise.

‍You can install a microgrid for a single source today and fit a basic controller sized to it. If the assets then evolve, adding solar, then storage, then more nodes, a controller sized only to the original asset has to be replaced. Replacing a controller is disruptive in a way that adding a battery is not, because the controller is the part everything else coordinates through. So the experienced choice is to specify the controller ahead of the assets, with headroom for capability the site does not yet have. On the surface that looks like control leading assets, the reverse of the principle.

‍It is not the reverse. It is the principle applied to the trajectory rather than the snapshot. The controller still follows the assets. It follows the assets the site is going to have. You specify it to the path, not to the first step on the path. That makes the controller the one component you knowingly over-specify relative to today's hardware, because it is the one component you cannot cheaply sequence later. Everything else you add when the requirement and the capital arrive. The controller you buy early, against the plan.

‍This is why the principle is a statement about time, not only about hardware. It tells you to read the asset roadmap before you size the control, and to treat the controller as the part that has to see the top of the ladder from the start.‍ ‍

What the principle produces: a classification by assets‍ ‍

If you classify microgrids by the assets present rather than by the functions a controller performs, a clear sequence falls out. Each step adds one class of asset to the one before it, and the control requirement rises with it.

‍A single dispatchable source of behind-the-meter (BTM) generation serving a load, with no renewables and no storage, is the simplest case. A gas engine supplying an industrial site, often with nonsynchronized standby diesel generators, sits here. Add renewable generation, typically solar photovoltaic (PV), and there are at least two sources to balance against the load, which is the first real control task. Add battery energy storage (BESS) and the microgrid can move energy across time rather than only matching generation to load in the moment, which is a larger control task again. Extend to multiple nodes with decentralized, distributed control rather than a single central controller, and you have the architecture for a campus or a multi-site estate, where one central controller is both a bottleneck and a single point of failure.

‍I label these basic, simple, complex, and advanced for shorthand. The labels are convenient, not the point. The point is the axis. The defining feature at each step is the asset the previous step did not have: renewable generation, then storage, then distributed nodes and control. Name the step and you have named the asset stack, which is the information a specification actually needs.‍

Capability and operating mode are different questions

‍One distinction keeps these definitions clean. What assets a microgrid has is a separate question from how it relates to the grid at any moment. The first is capability, the axis above. The second is operating mode: grid-connected, islandable, or in island mode.‍ ‍

They are independent. Any capability step can run in any mode. A single-source microgrid can sit in permanent island mode at a remote site with no grid to connect to. A fully built, multi-node microgrid can run grid-connected for most of its life and island only when it has to. Islandable is the capability to disconnect. Island mode is running disconnected. The two are worth not confusing, because a site islanded by design, remote with no utility, is a different engineering problem from a site that islands on an event, grid present but dropped, even though both are in island mode. The second is the data center case: hold availability when the grid fails.‍ ‍

Why this matters for data centers‍ ‍

For a data center the step is not a preference. It is set by what the site has to deliver, and four requirements pull on it, not always in the same direction. Speed to power favors the simplest build, which is why a basic microgrid is often the fastest route to energization when a grid connection cannot be had in time. Reliability is the five nines standard, 99.999 percent availability, roughly five minutes of downtime a year, and holding it through a grid outage is an islanding question as much as a generation one. Decarbonization is delivered by the renewable and storage assets that define the middle steps, so a carbon target pulls a site up the sequence. Grid independence is generation, storage, and control acting together.‍ ‍

The pressure that has changed the calculation is load behavior. AI training does not draw power the way traditional IT load does. Tens of thousands of GPUs work in lockstep, surging to near full power during compute and dropping toward idle during synchronization and checkpointing, so the swings stack instead of averaging out. Synchronized training loads can move tens to hundreds of megawatts within seconds, sometimes within a fraction of a second, fast enough that a utility cannot respond and may disconnect the site unless the swing is buffered. A microgrid sized for a smooth load behaves differently under this one.‍ ‍

That raises the value of the upper-step assets for reasons beyond the obvious. Storage earns its place not only by time-shifting cost but by absorbing fast load swings and smoothing the profile the generation and the connection see, which is now a primary reason a data center reaches the storage step rather than a secondary one. Distributed control earns its place when a campus has multiple halls whose loads move independently and have to be coordinated against shared generation and storage. And because AI load is the fastest-moving and least predictable trajectory in the field, the controller-buys-early logic bites hardest here. A controller specified to first-phase load, with no headroom for the storage and the halls that AI demand will pull in, is the expensive mistake to avoid.‍ ‍

How a microgrid evolves

‍A microgrid is not fixed at the step it starts on, and the controller logic above only makes sense against the way these systems change over time. There are three patterns.‍ ‍

It can be built complete. A greenfield site can be specified at the top step from commissioning, with generation, storage, and distributed control all present on day one. Sometimes that is correct. It front-loads capital for capability the early load does not yet need, which is a real cost, but it removes the retrofit risk.‍ ‍

More often it evolves up the steps. A site starts where its requirements and its capital allow and adds capability as load grows and decarbonization targets tighten, from single source to renewables to storage to multiple nodes. This is the Structured Transition Model at the level of one site. The order in which capability is added is a decision, not an accident, and the controller is specified to the whole order rather than the first move.‍ ‍

And it can move both ways. This is the part a static classification misses, because it has no time axis. The rate of change in load, fuel economics, and grid conditions is now fast enough to outrun the planning cadence a site was designed around. A configuration that was right at commissioning can be re-sequenced or reconfigured before the plan expected: storage added earlier than forecast because AI load arrived faster, a grid connection deferred because it no longer pays, control restructured as the estate grows. This is the Temporal Trilemma in practice. The three corners of the energy trilemma, security, affordability, and sustainability, are familiar. The variable that now dominates is the rate at which the answer has to change, and a microgrid specified to a single moment is specified to a moment that will pass.‍ ‍

The point‍ ‍

Control follows assets, and assets move. Classify a microgrid by what it is made of, specify the control to where the assets are going rather than where they are, and the next decision becomes legible: which step the site is on, which mode it runs in, which requirement is pulling it up, and what the controller has to be ready for. For data center operators facing load that is growing in both size and volatility, that legibility is the difference between a system built for the site as it is and one built for the site as it becomes.

Five Nines and Fast Power

Making better energy decisions in the AI era

Questions and Answers