Energy Router Operating System (EROS)

• EROS is a control system that transforms a modular power‐electronics rack into an internet‐like energy router by managing internal DC backplane operations and port policies.
• It implements local policy-driven routing and scheduling, enabling near-real-time energy flow optimization and secure interfacing between microgrids and legacy grids.
• EROS bridges hardware conversion and software orchestration through standardized interfaces, supporting incremental deployment alongside existing grid infrastructures.

Energy Router Operating System (EROS) is the core software component that turns the Energy Router from “just” a modular power‑electronics rack into a true, Internet‑like routing node for electricity. Within the EnergyNet architecture, it is the local control‑plane brain that manages the DC backplane, enforces port logic (A/B/C/D), consumes policies signaled over the Energy Protocol (EP), and exposes the router as a manageable asset to the Energy Network Management System (ENMS). In the architecture described for EnergyNet, EROS is the per-device runtime analogous to the operating system and routing daemons inside an IP router, while EP‑Server provides external coordination and ENMS provides fleet‑level supervision (Birgersson et al., 9 Sep 2025).

1. Architectural definition within EnergyNet

EnergyNet distinguishes a Tier‑1 architectural contribution from Tier‑2 outcomes contingent on adoption. In Tier‑1, the components are the Energy Router, including ports, DC backplane, and Energy Supervisors, together with Freedom Cables and local generation, storage, and loads. The interfaces are EP over IP between routers and ENMS, plus DC/AC ports to devices and the grid. The operating model is based on Energy Local and Wide Area Networks (ELAN/EWAN) implemented as DC microgrids with policy‑based interconnection. The control plane is explicitly defined as EROS plus EP‑Server, orchestrated by ENMS (Birgersson et al., 9 Sep 2025).

Within this decomposition, the data plane is the physical transfer of energy through power electronics and the DC backplane, whereas the control plane is the set of software processes and protocols governing that transfer. EROS sits squarely in the control plane at device level. It configures and drives the “forwarding engine,” here meaning converters and switches rather than packet ASICs; it implements local policies such as priorities, limits, and port roles; and it exposes state and control interfaces to higher‑level management systems. The design therefore treats an energy router as a manageable network node rather than only as a converter assembly (Birgersson et al., 9 Sep 2025).

A central architectural clarification is that EROS belongs to Tier‑1, whereas several desirable system outcomes do not. Local‑first autonomy with global interoperability, near‑real‑time operation with local buffering, removal of EV‑charging bottlenecks, freed grid capacity for data centers and industrial electrification, and a trend toward low, predictable, fixed‑cost clean energy are presented as Tier‑2 results contingent on successful adoption of the architecture. This distinction matters because it separates the defined operating model from claims about deployment-scale consequences (Birgersson et al., 9 Sep 2025).

2. Supervisors, software stack, and managed interfaces

Each Energy Router includes two redundant controller modules called Energy Supervisors. On each supervisor, two main software components run: EROS and EP‑Server. EROS is the internal control OS, while EP‑Server is the external protocol engine that speaks EP to other routers and to operators. ENMS configures and supervises many routers, including their EROS and EP‑Server instances (Birgersson et al., 9 Sep 2025).

Component	Primary role	Networking analogy
EROS	Local control plane for the device	OS + routing daemons inside an IP router
EP‑Server	External coordination plane	BGP/OSPF daemons and control APIs
ENMS	Fleet‑level controller/NMS	NMS or SDN controller

EROS directly interfaces with the internal DC backplane, which is a shared energy bus onto which all ports connect. It decides which ports are sources and sinks at any moment, how much power is exchanged, at what voltage and current levels, and with what priority under what safety constraints. EP‑Server receives EP messages, including offers, requests, pricing, priorities, and policy updates, from peer routers and from ENMS; it translates these into device‑local instructions for EROS. ENMS provisions EROS with firmware or OS version, configuration templates, default priorities, safety thresholds, and policy rules, and it monitors telemetry such as voltages, currents, power flows, backplane utilization, and errors (Birgersson et al., 9 Sep 2025).

The interface structure is layered. EROS talks downward to AC/DC or DC/DC modules, the DC backplane switch matrix, and measurement sensors. It talks laterally to EP‑Server through an internal API, receiving directives such as export limits, priority changes, or topology changes on a C‑port link, and returning measurements and status. It talks upward to ENMS through a management plane supporting configuration push and pull, software and firmware upgrades, performance and event reporting, and security mechanisms including certificates, mTLS, and RBAC. The paper’s formulation is explicit: ENMS is responsible for fleet‑level operations, while EROS is the per‑device runtime that ENMS manages (Birgersson et al., 9 Sep 2025).

3. Backplane orchestration, port logic, and local control

The central hardware abstraction managed by EROS is the internal DC backplane. The router’s ports are logically grouped as Port A for local consumption, Port B for interconnection to the traditional grid (POGS), Port C for interconnection to other Energy Routers, and Port D for local energy resources such as PV, batteries, and EV chargers. All ports are realized by AC/DC or DC/DC converter modules that can send or receive AC or DC, adjust voltage such as 150–800 V DC or up to 1500 V DC, and convert between AC and DC as needed (Birgersson et al., 9 Sep 2025).

EROS configures each port according to its logical role, the type of attached device, the current operating mode, and negotiated policies from EP‑Server. The paper’s illustrative examples emphasize that the realized powerflow topology is software-determined rather than hard‑wired. In one case, P1 and P3 receive 400 VDC, and EROS routes through the backplane to send 800 VAC on P4. In another, P1 receives 400 VDC and P4 receives 400 VAC, while EROS outputs 400 VDC on P3 and 400 VAC on P2. Physically, any port could feed any other; EROS and policy determine allowed flows (Birgersson et al., 9 Sep 2025).

EnergyNet describes this local runtime as near‑real‑time, buffered, and policy‑based rather than as strict instantaneous balancing. EROS implements per‑port priority classes, including critical loads such as routers, emergency lighting, and medical devices; important but deferrable loads such as heat pumps and EVs; and discretionary loads. It also implements local scheduling of energy flows subject to instantaneous power‑electronics limits, storage state of charge, and policy constraints such as maximum import or export, EV throttling, and price-based behavior (Birgersson et al., 9 Sep 2025).

The architectural description interprets this behavior as an optimization at each router over load, generator, and storage sets, with flow variables $P_{i \to j}(t)$ chosen subject to nodal balance, port limits, state-of-charge constraints, Port B limits, and EP policy constraints on Ports C and B. The paper states that EROS is the runtime that enforces a solution to this kind of problem, even if early deployments use rule-based heuristics rather than formal optimization. This is significant because it locates EROS between classical converter control and node-level resource scheduling (Birgersson et al., 9 Sep 2025).

4. Galvanic separation, firewall semantics, and buffered autonomy

A defining architectural principle is software‑controlled galvanic separation. Each Energy Router electrically isolates its local microgrid from the legacy AC grid and from other microgrids; all coupling occurs through power electronics and software. EROS enforces this separation. On the grid side, Port B is a separate domain with no direct synchronous coupling; interaction occurs through a converter with programmable power and voltage or frequency behavior, and EROS only allows power flow when EP‑Server and ENMS policies permit it. On the local side, Ports A and D, together with peer routers on Port C, form ELAN/EWAN domains that can continue operating even if Port B is shut (Birgersson et al., 9 Sep 2025).

The paper repeatedly uses firewall and NAT analogies. LAN addresses remain private and independent from WAN addresses; packets cross the boundary only when rules allow; and the LAN remains functional if the WAN is down. Analogously, ELAN/EWAN can function locally if POGS is down, while EROS “firewalls” frequency and voltage disturbances so that POGS disturbances do not propagate into the local DC microgrid. This is not merely metaphorical language in the architecture: it describes the operational role of the software-defined boundary (Birgersson et al., 9 Sep 2025).

Near‑real‑time operation is paired with local buffering. Batteries and EVs are treated as buffers or caches in the same way that packet networks use storage to absorb burstiness. EROS manages charging and discharging policies to smooth local fluctuations and to decouple local dynamics from the wider network. The principle “some power is better than no power” is implemented by load prioritization: under scarcity or islanded operation, low‑priority loads are shed first, and essential services are preserved. A plausible implication is that EROS operationalizes graceful degradation rather than binary service availability, but the paper presents this as an architectural principle rather than as a formal service-level contract (Birgersson et al., 9 Sep 2025).

The same section of the architecture links these mechanisms to Tier‑2 outcomes. Local‑first autonomy with global interoperability, EV‑charging throttling without feeder overload, and reduced stress on POGS follow from the ability of EROS to schedule flexible loads, cap import on Port B, and maximize use of local PV and storage. The paper notes that performance numbers such as Tamarinden’s 30% energy reduction and 50% peak reduction arise from local management and optimization that, under an EnergyNet deployment, would be codified and automated through EROS, EP‑Server, and ENMS rather than through bespoke project‑specific controllers (Birgersson et al., 9 Sep 2025).

5. Relation to other energy-router architectures and control frameworks

A broader literature uses the language of energy routers without always naming EROS explicitly. In hybrid AC‑DC grids, a partial‑power energy router architecture has been presented as a multi‑port, series‑connected power‑flow controller able to interconnect multiple AC and DC feeders, control active and reactive power on AC feeders, regulate voltages and currents on AC and DC feeders, provide virtual impedance and inertia with ripple mitigation, and optionally exchange power with battery storage. That work states that the power electronic hardware processes only a small fraction of the total line power and reports a comparison in which the partial‑power solution processes about 10% of power, achieves efficiency greater than 99%, and yields a 43% cost reduction together with a 3.1× reliability improvement over a conventional full‑power converter-based solution. It then interprets the resulting control structure in explicitly OS-like terms: local module control corresponds to device drivers, the system-level controller corresponds to an EROS kernel, ports and feeders are like processes or network sockets, and power references are resource-allocation decisions (Asadi et al., 9 Nov 2025).

A different antecedent is the grid energy router literature for active distribution networks. One paper proposes a five-layer hierarchy consisting of routing, forwarding, buffer, user, and multi-carrier energy layers, all connected through a DC link or DC bus. It also formulates a bi-level primary energy dispatching strategy in which a modified MPC performs short-time scheduling of R-layer port powers and B-layer buffer power, while a lower real-time layer uses fuzzy logic control and a distributed fast compensation strategy over a GER graph $G(V,E)$. In the paper’s own OS-thinking vocabulary, MMPC functions as a scheduler for buffer resource allocation, while FLC and distributed sharing constitute a real-time dispatcher (Chen et al., 2020).

These related papers do not collapse into a single implementation, because they are attached to different hardware and control assumptions. The hybrid AC‑DC work centers on an AFE, DAB or MAB converters, series modules, and optional BESS, whereas the GER work centers on a five-layer internal hierarchy and peer-to-peer buffer sharing. Still, they converge on a common abstraction: a router-like node in which local software allocates powerflow setpoints, manages buffer state, enforces device constraints, and mediates distributed coordination. This suggests that EROS can be understood not only as a named component of EnergyNet, but also as a more general software abstraction for node-level orchestration in routed energy systems (Asadi et al., 9 Nov 2025, Chen et al., 2020).

6. Deployment model, demonstrators, and unresolved issues

The EnergyNet paper describes EROS as part of a specific deployment model. Each Energy Router has dual Energy Supervisors, and each supervisor runs EROS plus EP‑Server with active/active or active/passive failover; configurations and states are mirrored in real time for redundancy. The hardware is 19‑inch rack-based, with 50–80 ports per 42U rack using modular converter modules, and EROS is expected to support hot‑swap and dynamic port discovery and configuration. Secure management is via ENMS, including signed software images, mTLS for EP control traffic, RBAC with audit trails, and staged rollouts with rollback capability. EROS is also intended as open‑source, aligned with the open EP specification hosted on GitHub as cited in the paper (Birgersson et al., 9 Sep 2025).

Early municipal demonstrators provide the main implementation context. In Örebro’s Tamarinden and Lund’s Brunnshög/CoAction Lund, Freedom Cable DC links and Energy Routers provide the platform, while EROS is described as the layer that supports direct PV‑to‑neighbor sharing, manages batteries and EV charging, and maintains the firewall to the legacy AC grid. The SWS EnergyNet‑0 (TPoC) in Lund is described as a two-building demonstrator connected by a DC Freedom Cable: the LKF side has 57 kWp PV, a 100 kWh battery, a 420 A/800 VDC Energy Router, and EV charging; the LKP side has 250 kWp PV, a 50 kWh battery, a 420 A/800 VDC Energy Router, and EV charging. In this setup, EROS instances monitor local PV, batteries, and EV loads, negotiate sharing policies via EP‑Server, and ensure safe, prioritized routing through the DC backplane and interconnection cable (Birgersson et al., 9 Sep 2025).

The migration path from POGS is incremental rather than discontinuous. Deployment can start with an Energy Router feeding a building on Port A while importing from POGS on Port B, then add PV and storage on Port D, and finally add links to neighbors on Port C. At each step, EROS enforces galvanic separation and ensures legacy-grid compatibility. This operating model is important because it frames EROS as software for staged coexistence with conventional infrastructure rather than only for greenfield microgrids (Birgersson et al., 9 Sep 2025).

The same paper is explicit that EROS remains an architectural blueprint rather than a full formal specification. The exact local control strategies, including whether they are PID, MPC, rule-based, or optimization-driven, are not fully specified. Open issues include scalability of local control algorithms in very large ELAN/EWAN systems; standardization of EP message schemas, state machines, and error handling; certifiability under evolving grid codes and safety standards for DC microgrids and Freedom Cable infrastructure; cybersecurity hardening beyond mTLS and RBAC, including secure boot, runtime isolation, and formal verification of safety properties; integration with legacy SCADA, ADMS, and DERMS platforms; and the division of autonomy among EROS, ENMS, and end devices such as EV chargers and smart appliances. A common misconception is therefore that EROS is already a complete, standardized operating system stack. The paper instead presents it as the core control component of an open, testable blueprint whose quantitative control models, interoperability mechanisms, and large-scale metrics remain subjects for further pilots and research (Birgersson et al., 9 Sep 2025).