Skip to main content

Microgrid Capability Map

The Microgrid OS capability model describes what the platform enables people, devices and software to do. Capabilities are therefore named as behaviours — using verbs or object–verb phrases — rather than as domain nouns such as Assets, Alerts, Payments or Storage.

This keeps capability boundaries stable even as implementations change. For example, Measure Energy Use can be implemented by OpenEMS today and by other metering providers later; Collect Payments can be implemented by MTN MoMo, Airtel Money, bank integrations or manual reconciliation.

Important: the capability map and the Generation 1 / 2 / 3 model describe different things.
The capability map defines what the Microgrid OS does. The generation model describes how open, locally maintainable and community-controlled the current implementation of a capability is.

Capability map

nfe_microgrid_capability_map_v2.png

How this changes the previous map

Previous noun-oriented area Capability-oriented framing
Metering Measure Energy Use
Storage Dispatch Stored Energy, Observe Energy Flows, Monitor Equipment Health
Solar Generation Observe Energy Flows, Forecast Generation, Control Equipment
Billing Configure Tariffs, Calculate Charges, Issue Invoices
Payments Collect Payments, Vend Energy Credit
Customer Relationship Management Manage Customer Accounts, Notify Customers & Operators
Alerts Detect Grid Outages, Diagnose Device Faults, Notify Customers & Operators
Assets Register Devices, Provision Devices, Commission Devices, Configure Devices

Generation model

Generation should be tracked per implementation of a capability, not baked into the capability name itself.

  • Generation 1 — proprietary hardware/software; imported; expensive to acquire and repair; limited community control.
  • Generation 2 — open-source software with locally obtainable but generally proprietary hardware; multiple implementers/SaaS providers are possible.
  • Generation 3 — open hardware, firmware and software; equipment can be assembled and repaired locally; maximum community choice and maintainability.

This lets NFE move a capability from one implementation generation to another without changing the capability contract itself.

Our capabilities are currently evolving across 3 generations. See our roadmap for progress updates.

No comments to display

Back to top