What is an Energy Management System?

An Energy Management System (EMS) is a combination of hardware and software designed to monitor and control the production, storage, and consumption of energy. The goal is to optimize how energy is produced/consumed, stay within grid connection limits, and lower energy bills.

EMS solutions come in two layers: cloud-based and on-site (also called local). In practice, most energy systems use both together.

Cloud EMS vs. local EMS: what is the difference, and how do they work together?

A local EMS sits on-site, between the cloud and the physical equipment. It connects your assets, read and send their data to the cloud EMS, and receives back instructions (e.g. curtail PV, charge battery) to execute.

It also acts as a “protector” running independently its own control loops, to make sure total production or consumption never exceed the contacted or physical grid limits.

A cloud EMS is where the intelligence lives. Based on the data it received from the local EMS and other historical and market data insights, it runs more complex optimization logic. It’s also usually accompanied by an interface on which the users can visualize the data and change the parameters.

What are the functionalities of a local EMS?

Protect the grid connection

This is the most time-sensitive job a local EMS performs. Grid connections have contractual and physical limits. Exceeding those limits — even briefly — can trigger DSO penalties or trip protection equipment.

A local EMS monitors the connection in real time and adjusts asset output before a violation occurs.

• For solar and wind assets, it curtails production when feed-in approaches the limit.
• For battery systems, it modifies charge and discharge setpoints to stay within bounds. Because this logic runs on-site, it acts within milliseconds — fast enough to catch the spikes that a cloud signal would miss.

One important caveat: closed-loop controllers react after measuring a deviation, not before it. For protection against physical limits — circuit breakers, transformer ratings — a reservation-based approach is more reliable. It pre-allocates a fixed power budget per asset so the combined output can never exceed the configured ceiling. In either case, configured limits should sit 10–20% below the actual physical limit, to account for asset ramp rates, measurement delays, and local load dynamics.

Peak shaving

When local consumption is about to exceed the grid limits, a battery connected to a local EMS can discharge to cover the gap. This prevents high-demand peaks from reaching the meter.

When multiple batteries are involved, the local EMS aggregates setpoints and distributes them proportionally based on state of charge — discharging the fuller unit first, charging the emptier one first. The result is a balanced fleet rather than one battery doing all the work while the others sit idle.

Self-consumption optimization (PV + battery)

Excess solar generation that would otherwise be exported can be stored in a battery and used when generation falls. The local EMS runs this logic continuously: charge when production exceeds local demand, discharge when it falls short.

Cloud schedules and state-of-charge schedules take priority over self-consumption logic when active.

Signal prioritization

With the ability to participate in various energy markets (balancing markets such as FCR, aFRR, passive imbalance and congestion markets), assets can receive overlapping control signals.

A local EMS enforces the correct hierarchy: grid protection limits > congestion signals > balancing signals.

Fallback behavior when cloud connectivity is lost

If the connection to the cloud drops, a local EMS does not simply stop. It continues running grid protection loops independently. Once an active schedule’s end time elapses, assets revert to their default mode.

Operations remain stable until connectivity is restored.

Why does it matter to have a local EMS?

Three reasons:

• Speed. Physical protection loops need to respond in under a second. Round-trip latency over the internet is too slow for this. Local control runs in milliseconds.
• Reliability. Cellular and broadband connections fail. A site with only cloud-based control has no fallback when they do. A local EMS keeps running regardless.
• Independence. A local EMS connected via a standardized API means the asset owner is not tied to any single cloud platform. The on-site hardware operates regardless of which trader, aggregator, or EMS software is connected above it.

The Teleport as a local EMS

The Teleport Gateway is Withthegrid’s on-site EMS. It connects solar, wind, battery, and EV charging assets to the cloud, grant control to your trader via a single API, and run local control strategies independently on-site. It supports over 450 asset types across brands and protocols, including legacy wind turbines.

Grid protection loops run locally and remain active even when cloud connectivity is lost.

The Teleport is ISO 27001 certified, NIS2 and RED 3.3 compliant, and holds a certified Real-time Interface endpoint for DSO compliance in the Netherlands — with equivalent standards covered across Europe.

Conclusion

For any organization that owns or operates energy assets, a local EMS is the foundation of reliable control. On its own, it protects your grid connection and keeps your assets running. Paired with a cloud EMS, it becomes part of a complete system — one that can optimize production, reduce energy costs, and respond to market signals.