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

flowchart
nfe_microgrid_capability_map_v2.png

TB
 APPS["Applications<br/>NFE Web UI · Installer UI · MicroPowerManager · APIs · AI/Agents"]

  subgraph DOMAIN["Microgrid OS Domain Capabilities"]
    direction LR

    subgraph ER["Energy & Reliability"]
      MEU["Measure Energy Use"]
      OEF["Observe Energy Flows"]
      MEH["Monitor Equipment Health"]
      CE["Control Equipment"]
      DSE["Dispatch Stored Energy"]
      DGO["Detect Grid Outages"]
      FDG["Forecast Demand & Generation"]
      OEU["Optimize Energy Use"]
    end

    subgraph CC["Commercial & Customer"]
      CT["Configure Tariffs"]
      CCH["Calculate Charges"]
      II["Issue Invoices"]
      CP["Collect Payments"]
      VEC["Vend Energy Credit"]
      MCA["Manage Customer Accounts"]
      NCO["Notify Customers & Operators"]
    end

    subgraph FO["Field & Device Operations"]
      RD["Register Devices"]
      PD["Provision Devices"]
      CD["Commission Devices"]
      CFD["Configure Devices"]
      MDC["Monitor Device Connectivity"]
      UDS["Update Device Software"]
      DDF["Diagnose Device Faults"]
    end
  end

  subgraph FUTURE["Extensible / Future Domain Capabilities"]
    CEV["Coordinate EV Charging"]
    SFD["Shift Flexible Demand"]
    SFL["Schedule Flexible Loads"]
    MEC["Manage Energy Communities"]
  end

  KERNEL["Microgrid OS Platform Kernel — powered by Cordis<br/><br/>Load Plugins · Compose Services · Publish/Subscribe Events · Manage Configuration<br/>Manage Identity & Access · Persist Data · Observe Platform Health"]

  PROVIDERS["Providers & Integrations<br/>OpenEMS · MPM · Modbus · DLMS · MQTT · CHINT · SRNE/Victron · STS/OpenPAYGO · MTN/Airtel · WhatsApp"]

  APPS --> DOMAIN
  DOMAIN --> KERNEL
  FUTURE --> KERNEL
  PROVIDERS --> KERNEL

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.

Generation 1

  • Hardware and or software propritary but accessible to small microgrid developers
  • Hardware needs to be sourced from out of country
  • Cost of hardware purchase is high and so is cost of repair
  • Software licenses may be prohibitively expensive for small developers/communities because they are meant to target larger scale buyers

Generation 2

  • Hardware still proprietary but can be locally sourced
  • The software is open source and can be run by small developers or several SaaS providers giving developers options
  • Cost of hardware purchase is comparatively lower than Gen 1 and cost of repair is similar to Gen 1 since hardware is still proprietary

Generation 3

  • Hardware is open, can be assembled in country or locally sourced
  • The software is open source and so is the hardware firmware
  • Cost of purchase and repair of hardware is optimal
Back to top