There's a fundamental architectural mismatch at the heart of today's Virtual Power Plants: OEM firmware is designed to manage energy, not to operate as grid infrastructure.
Battery inverters, smart thermostats, EV chargers - these devices have sophisticated onboard software. They handle charging logic, user preferences, backup power transitions, time-of-use optimization. But they were never designed to respond to sub-second dispatch signals, participate in frequency regulation markets, or provide the telemetry granularity required for grid services.
The result? VPPs built on OEM firmware alone hit a performance ceiling. They can schedule capacity - "discharge 5 kW between 4 PM and 7 PM" - but they can't operate assets in real time with the determinism required for grid-grade reliability.
This is why the industry needs an execution layer - infrastructure purpose-built to bridge the gap between OEM devices and grid dispatch requirements.
Scheduling Capacity vs. Operating Assets: The Difference Matters
Scheduling capacity is what OEM firmware does well:
- Set a battery to charge during off-peak hours
- Schedule discharge during peak TOU windows
- Respond to a demand response event with 10-15 minute lead time
- Follow a pre-programmed dispatch curve
Operating assets in real time is what grid services require:
- Respond to a 4-second frequency regulation signal (CAISO Regulation Energy Management)
- Adjust output every 250 milliseconds for fast frequency response (FFR)
- Provide verified, sub-second telemetry to prove performance
- Maintain dispatch even during internet outages or cloud failures
- Coordinate multiple devices behind a single meter to hit a precise aggregate setpoint
OEM firmware wasn't architected for the second category. It's not a criticism - it's a design reality. Battery inverters are optimized for energy arbitrage and backup power, not ancillary services. Thermostats are optimized for comfort and efficiency, not millisecond-level load control.
If you try to use OEM firmware for grid services, you encounter three fundamental limitations:
1. Cloud Dependency = Latency + Reliability Risk
Most OEM platforms dispatch from the cloud. A dispatch signal travels:
- From the grid operator or aggregator → cloud server → device API → local firmware → actual hardware
That round trip takes hundreds of milliseconds to seconds - acceptable for demand response, unacceptable for frequency regulation. Worse, if internet connectivity fails (common during grid events), cloud-based dispatch fails entirely.
2. Firmware Update Cycles ≠ Grid Requirements
OEM firmware is updated on product release cycles - quarterly, annually, sometimes never (for legacy devices). Grid requirements evolve continuously. New market programs, new telemetry standards, new dispatch protocols.
If you're dependent on OEM firmware updates to participate in a new grid program, you're locked into someone else's roadmap. And if the OEM decides a feature isn't worth the engineering effort (because it only benefits grid services, not retail customers), you're stuck.
3. Device Diversity = Integration Nightmare
A typical VPP fleet includes:
- Multiple battery brands (EG4, Tesla, Enphase, LG, BYD, SolarEdge)
- Multiple inverter protocols (Modbus, CAN, proprietary APIs)
- Multiple communication interfaces (Wi-Fi, Ethernet, cellular, Zigbee)
Each OEM has different APIs, different telemetry formats, different dispatch mechanisms. Building a VPP by integrating directly with each OEM's cloud platform means writing and maintaining dozens of custom integrations - and accepting the lowest common denominator in performance.
Enter the Execution Layer: Decoupling Intelligence from Control
The solution is an execution layer that sits between OEM devices and grid dispatch systems. This layer:
- Runs locally (at the site or edge)
- Normalizes device protocols (Modbus, API, OCPP, CAN - doesn't matter)
- Provides real-time, deterministic control (millisecond-level precision)
- Operates autonomously (even during cloud or internet outages)
- Exposes a unified interface to optimization logic and dispatch signals
This is the architecture behind AERA (Adaptive Energy Response Architecture) - Molecule Systems' execution framework.
AERA in Practice: How It Works
-
Edge-First Control MOS 350, Molecule's edge OS, runs on gateways deployed at each site. It communicates directly with DERs over Modbus, API, OCPP, or proprietary protocols. Control decisions execute locally - no cloud round trip, no latency, no internet dependency.
-
Algorithm Injection Optimization logic is injected into the edge OS, not baked into firmware. If you want to switch from a simple TOU strategy to a sophisticated multi-program optimization model, you upload new logic via the cloud. Devices don't need firmware updates. The execution layer is hot-swappable.
-
Protocol Normalization Whether you're controlling a SolarEdge inverter (Modbus), a Tesla Powerwall (API), or an EG4 battery (CAN), MOS 350 normalizes the interface. Your optimization logic sees a unified abstraction: "battery at 80% SOC, 10 kW available capacity." It doesn't care about the underlying protocol.
-
Real-Time Telemetry Sub-second telemetry flows from devices → edge gateway → cloud dashboard. Grid operators, aggregators, and settlement systems get the granular data required for pay-for-performance verification - without depending on utility meter data that's 24 hours delayed.
-
Autonomous Operation If the internet goes down, the edge gateway continues executing the last-known dispatch logic. Batteries keep responding to TOU schedules, backup power transitions happen seamlessly, and grid services continue without interruption. When connectivity returns, telemetry syncs and cloud-based optimization resumes.
Why This Matters: The Structural Advantage
Decoupling intelligence from execution creates structural advantages:
For OEMs: You keep building great hardware. You don't need to become a grid services software company. The execution layer integrates with your devices as they are - Modbus, API, whatever. Your customers get VPP revenue without you rebuilding your firmware stack.
For Aggregators and Utilities: You keep running your optimization models, your forecasting algorithms, your market bidding logic. But you're no longer constrained by OEM firmware limitations. The execution layer ensures your dispatch signals are executed reliably, regardless of device diversity.
For Developers and Fleet Operators: You're no longer locked into a single OEM or a single aggregator platform. Deploy a mixed fleet (EG4 + Tesla + Enphase), run multiple optimization strategies, participate in multiple grid programs simultaneously. The execution layer orchestrates it all.
The Bigger Picture: VPPs as Grid Infrastructure
If we want VPPs to be treated as firm capacity - counted in resource adequacy, dispatched like conventional power plants, financed like infrastructure assets - they need to perform like infrastructure.
That means:
- Deterministic control (not best-effort firmware updates)
- Real-time telemetry (not 24-hour meter data)
- Autonomous operation (not cloud-dependent dispatch)
- Protocol-agnostic integration (not vendor lock-in)
The execution layer makes this possible. It's the missing piece between smart devices and grid-grade performance.
At Molecule Systems, we've built that layer. MOS350 is the edge OS inside AERA. AERA provides the architectural framework. DividendVPP, EMS, and Optimization are the applications that run on top.
Because VPPs don't just need smarter algorithms. They need the infrastructure to execute those algorithms reliably, at scale, in the real world.
Curious how AERA works with your existing devices? Ask our AI about protocol support and integration timelines - or schedule a technical demo to see edge-based execution in action.