Introduction to EnerOS
EnerOS is a Power/Energy-Native AgentOS designed for the power and energy domain. It builds the domain knowledge, physical constraints, and operational logic of power systems into the OS kernel, enabling AI Agents to natively understand, safely make decisions, and act autonomously in energy scenarios.
Core Value
EnerOS embeds the domain knowledge, physical constraints, and operational logic of power systems into the OS kernel, giving AI Agents native understanding, safe decision-making, and autonomous action in energy scenarios.
Unlike traditional power software, EnerOS is not an application-layer library but a complete operating system: topology, power flow, constraints, equipment models, and time-series storage are all pushed down into kernel space, accessible by Agents through system calls without redundant modeling.
| Dimension | Traditional Power Software | EnerOS |
|---|---|---|
| Topology Modeling | Application-layer data structure | First-class kernel citizen |
| Constraint Validation | Optional at application layer | Enforced by kernel |
| Equipment Model | Custom per application | Unified model library |
| Time-Series Data | External database | Kernel storage engine |
| Agent Sharing | Manual synchronization | Automatic sharing |
| Security & Compliance | Bolt-on module | Kernel-enforced |
Design Philosophy
EnerOS’s six design philosophies run through the entire system:
Power-Native First
Power-native first. Grid topology, power flow calculation, security constraints, and equipment models are not bolt-on libraries but kernel-native data structures and algorithms. All upper-layer applications share the same grid worldview.
Agent-as-Grid-Node
Agent as grid node. Each Agent is modeled in the kernel as a node in the grid, with a clear jurisdiction, permission boundary, and electrical position, enabling topology-aware collaboration with other nodes.
Constraint as Kernel Law
Constraint as law. Physical constraints (voltage limit violations, branch overloads, frequency deviations, etc.) are not optional validation steps but laws enforced by the kernel. Any operation that violates a constraint is directly rejected in kernel space.
Time-Series Native
Time-series native. All states of a power system are time-series data. EnerOS builds the time-series storage engine into the kernel, providing nanosecond-precision writes and queries without depending on external time-series databases.
Real-Time Determinism
Real-time determinism. EnerOS adopts a dual-execution architecture: the general domain handles non-real-time tasks (planning, analysis, training), while the real-time domain handles hard real-time tasks (protection, control, stability). The real-time domain guarantees microsecond-level response.
Open & Interoperable
Open and interoperable. EnerOS supports power industry standard protocols such as IEC 61970 / 61968 / 61850 and provides four API types — REST / GraphQL / WebSocket / SSE — enabling seamless integration with existing SCADA, EMS, and DMS systems.
System Composition
EnerOS consists of 56 Rust crates, covering the complete stack from kernel to applications:
| Layer | Key Crates | Responsibilities |
|---|---|---|
| Application Layer | DispatchAgent / SelfHealingAgent / TradingAgent, etc. | Dispatch, Ops, Trading, Planning |
| Agent Runtime | eneros-agent / eneros-tool / eneros-reasoning | Agent lifecycle, tools, reasoning |
| Power-Native Kernel | eneros-topology / eneros-powerflow / eneros-constraint / eneros-equipment | Topology, Power Flow, Constraints, Equipment |
| Real-Time Safety Gateway | eneros-gateway / eneros-trust / eneros-ids / eneros-audit | mTLS, CA, IDS, Audit |
| Infrastructure | eneros-os / eneros-timeseries / eneros-multiregion / eneros-tenant | OS, Time-Series, Multi-Region, Multi-Tenant |
Use Cases
EnerOS is suitable for the following typical scenarios:
- Intelligent Dispatch: Economic dispatch and load allocation based on power flow results and load forecasting
- Fault Self-Healing: Fault location, isolation, and service restoration (FDIR)
- Intelligent Operations: Equipment condition monitoring, lifetime prediction, and Ops strategy optimization
- Distribution Network Planning: Distribution network expansion planning and scheme comparison
- Power Trading: Spot market bidding and virtual power plant operation
- Energy Efficiency Optimization: Demand response and energy efficiency management
- Digital Twin: Real-time grid mirroring and simulation inference
- Multi-Agent Collaboration: Cross-region, cross-discipline multi-Agent coordination
Performance Overview
EnerOS performance metrics on a standard test environment (4 cores / 8GB / Ubuntu 22.04):
| Operation | Latency | Throughput |
|---|---|---|
| Topology Analysis (1000 nodes) | < 1ms | - |
| Power Flow Calculation (IEEE 14-bus) | < 12ms | - |
| Constraint Validation (single command) | < 10μs | 100,000/sec |
| Time-Series Write | < 1μs | 1,000,000 points/sec |
| Event Bus Broadcast | < 10μs | - |
| Agent Command Dispatch | < 100μs | - |
| Real-Time Domain Response (protection logic) | < 100μs | - |
Version
EnerOS follows Semantic Versioning, with the current version being 0.47.0.
- Stable Release: One minor version released quarterly
- Preview Release: One patch version released weekly
- LTS Release: One LTS version released annually, providing 3 years of security updates
Getting Help
- GitHub Repository - Source code and Issues
- Documentation Site - Complete documentation
- Example Code - Complete examples
Next Steps
- Prerequisites - Install Rust toolchain and system dependencies
- Installation & Build - Build EnerOS from source
- First Run - Start the API server and run power flow calculation
- First Agent - Create and run your first EnerOS Agent
- Configuration File - Understand eneros.toml configuration options