Power-Native First

Power-Native First 是 EnerOS 最核心的设计哲学：电力系统的领域知识不是外挂的库或配置文件，而是操作系统内核的原生抽象。这意味着电网拓扑、潮流计算、安全约束、设备模型、时序数据等电力领域的核心概念，与文件系统、进程管理、网络栈等传统操作系统概念一样，享有内核态的一等公民地位。

设计动机

传统电力软件的困境

传统电力软件将电网领域知识置于应用层，导致了一系列长期难以解决的问题：

• 重复建模：每个应用（EMS、DMS、SCADA、配电自动化）都维护自己的电网模型，数据冗余且不一致
• 校验遗漏：物理约束校验散落在各应用中，部署时容易遗漏，事故后才暴露
• Agent 孤岛：智能体无法共享统一的电网世界观，跨应用协作需要复杂的接口对接
• 性能损耗：每次操作都需要在应用层重建电网上下文，无法利用内核态优化
• 演进困难：电网模型变更需要同步修改多个应用，迭代周期长

Power-Native 的解决思路

EnerOS 将电力领域知识下沉到操作系统内核，所有上层应用通过系统调用访问同一份电网抽象：

┌──────────────────────────────────────────────────┐
│              应用层 (Agents)                      │
│  DispatchAgent / SelfHealingAgent / TradingAgent │
├──────────────────────────────────────────────────┤
│              Agent 运行时                         │
│  eneros-agent / eneros-tool / eneros-reasoning   │
├──────────────────────────────────────────────────┤
│         电力原生内核 (Power-Native Core)          │
│  ├─ NetworkGraph      (拓扑图)                    │
│  ├─ PowerFlowSolver   (潮流求解器)                │
│  ├─ ConstraintEngine  (约束引擎)                  │
│  ├─ EquipmentLibrary  (设备模型库)                │
│  ├─ TimeSeriesEngine  (时序存储)                  │
│  └─ TopologyAwareBus  (事件总线)                  │
├──────────────────────────────────────────────────┤
│              基础设施层                           │
│  eneros-os / eneros-trust / eneros-multiregion   │
└──────────────────────────────────────────────────┘

电力原生的四大支柱

1. 电网拓扑一等公民

电网拓扑不再是磁盘上的 CIM/XML 文件或应用内存中的数据结构，而是内核态的图结构。所有 Agent、所有应用共享同一份拓扑视图，并感知其变更。

内核拓扑数据结构

use eneros_topology::{NetworkGraph, Bus, Branch, BusType, Voltage};

// 拓扑图是内核一等公民，进程启动时即加载
let mut network = NetworkGraph::new();

// 添加母线（节点）
network.add_bus(Bus::new(1, BusType::PQ, Voltage::new(1.0, 0.0)))?;
network.add_bus(Bus::new(2, BusType::PV, Voltage::new(1.02, 0.0)))?;
network.add_bus(Bus::new(3, BusType::Slack, Voltage::new(1.05, 0.0)))?;

// 添加支路（边）
network.add_branch(Branch::new(1, 2, BranchParams::line(r=0.01, x=0.05, b=0.02)))?;
network.add_branch(Branch::new(2, 3, BranchParams::transformer(r=0.0, x=0.1, ratio=1.0)))?;

// 内核维护拓扑一致性：增删改自动触发连通性分析
let topology = network.topology();
let islands = topology.find_islands();
let reachable = topology.reachable(bus_id_1, bus_id_2);

// 所有 Agent 共享同一拓扑视图，修改实时广播
let snapshot = network.snapshot(); // CoW 快照，零拷贝读取

拓扑感知的系统调用

// Agent 通过系统调用访问拓扑，无需自己重建
impl Agent for DispatchAgent {
    async fn run(&mut self, ctx: &mut AgentContext) -> AgentResult<()> {
        // 获取所在电气岛
        let island = ctx.syscall(TopologySyscall::GetIsland {
            bus: self.bus_id,
        }).await?;

        // 枚举岛内所有发电机
        let generators = ctx.syscall(TopologySyscall::ListGenerators {
            island_id: island.id,
        }).await?;

        // 执行经济调度
        let dispatch = self.economic_dispatch(&generators, &island.load)?;
        ctx.syscall(TopologySyscall::ApplyDispatch(dispatch)).await?;

        Ok(())
    }
}

2. 物理约束即法律

物理约束（电压越限、支路过载、频率偏差）不是应用层可选的校验步骤，而是内核强制执行的法律。任何违反约束的操作在内核态被直接拒绝，必要时投影到最近可行解。

use eneros_constraint::{ConstraintEngine, Constraint, Violation};

// 约束引擎绑定到内核拓扑，自动校验所有写操作
let constraint_engine = ConstraintEngine::new(&network);

// 注册约束（也可通过配置文件批量加载）
constraint_engine.register(Constraint::voltage()
    .min(0.95).max(1.05)
    .buses(network.all_buses()))?;

constraint_engine.register(Constraint::thermal()
    .branch(branch_id)
    .limit_mva(100.0))?;

constraint_engine.register(Constraint::frequency()
    .min_hz(49.5).max_hz(50.5))?;

// 任何 Agent 命令经过内核时自动校验
let command = Command::SetGeneration { bus: 1, mw: 80.0 };
match constraint_engine.check(&command) {
    CheckResult::Ok => { /* 通过，执行 */ }
    CheckResult::Violated(v) => {
        // 自动投影到最近可行解
        let feasible = constraint_engine.project(&command)?;
        log::warn!("命令被投影: {:?} -> {:?}", command, feasible);
    }
    CheckResult::Rejected(reason) => {
        return Err(EnerOSError::ConstraintRejected(reason));
    }
}

3. 设备模型标准化

EnerOS 内置统一的设备模型库，覆盖电力系统主流设备类型，所有 Agent 共享同一套参数化模型：

use eneros_equipment::{EquipmentLibrary, LineParams, TransformerParams};

let library = EquipmentLibrary::new();

// 标准化设备参数
let line = library.create_line(LineParams {
    r_per_km: 0.08,
    x_per_km: 0.40,
    b_per_km: 2.5e-6,
    length_km: 50.0,
    rating_mva: 100.0,
    nominal_kv: 110.0,
})?;

let transformer = library.create_transformer(TransformerParams {
    sn_mva: 63.0,
    vn_hv_kv: 110.0,
    vn_lv_kv: 10.0,
    uk_percent: 10.5,
    pk_kw: 280.0,
    i0_percent: 0.5,
    p0_kw: 50.0,
})?;

// 设备模型自动注入拓扑
network.add_branch(Branch::from_equipment(line.id(), bus_a, bus_b))?;
network.add_branch(Branch::from_equipment(transformer.id(), bus_c, bus_d))?;

4. 时序数据原生

电力系统的所有运行状态（电压、电流、功率、频率）本质上都是时序数据。EnerOS 将时序存储引擎内建为内核组件，提供纳秒级精度的写入与查询，无需依赖 InfluxDB、TimescaleDB 等外部数据库。

use eneros_timeseries::{TimeSeriesEngine, Measurement, Aggregation, Duration};

// 时序引擎是内核组件，启动即就绪
let ts = TimeSeriesEngine::open("data/eneros.db")?;

// 高吞吐写入（批量接口）
ts.batch_write(&[
    Measurement::new("bus_1_voltage",    1.02,  now!()),
    Measurement::new("bus_1_frequency", 50.00,  now!()),
    Measurement::new("line_1_power",    45.50,  now!()),
    Measurement::new("bus_2_voltage",    0.99,  now!()),
])?;

// 聚合查询 + 降采样一体化
let result = ts.query()
    .point("bus_1_voltage")
    .range(now!() - Duration::hours(24), now!())
    .aggregation(Aggregation::Avg, Duration::minutes(15))
    .downsample(Downsample::LTTB, 1000)
    .execute()?;

// Agent 直接通过系统调用查询
let history = ctx.syscall(TimeSeriesSyscall::Query {
    point: "total_load",
    range: (now!() - Duration::days(7), now!()),
}).await?;

完整对比：传统 vs Power-Native

性能对比

在标准测试环境（4 核 / 8GB / Ubuntu 22.04，IEEE 118-bus 系统）下的对比：

适用场景

Power-Native 架构特别适合以下场景：

• 大型互联电网：跨区域、跨电压等级的统一建模与协同控制
• 新能源高比例接入：风电、光伏的随机性需要实时潮流与约束校验
• 配网智能化：分布式能源、储能、电动汽车的协同管理
• 数字孪生：物理电网与孪生体的实时同步与镜像推演
• 多 Agent 协作：调度、自愈、交易等多智能体共享电网世界观
• 电力市场运营：基于实时拓扑与潮流的市场出清与结算

限制与权衡

Power-Native 架构并非银弹，存在以下权衡：

内核架构层次

Power-Native 内核的层次化设计：

┌─────────────────────────────────────────┐
│  系统调用接口 (Syscall ABI)              │  ← Agent 通过 syscall 访问
├─────────────────────────────────────────┤
│  电力原生服务层                          │
│  ├─ TopologyService   (拓扑读写)         │
│  ├─ PowerFlowService  (潮流计算)         │
│  ├─ ConstraintService (约束校验)         │
│  ├─ EquipmentService  (设备模型)         │
│  └─ TimeSeriesService (时序存储)         │
├─────────────────────────────────────────┤
│  电力领域内核                            │
│  ├─ NetworkGraph      (CIM 图结构)       │
│  ├─ Solver            (牛顿/PQ 分解)     │
│  ├─ ConstraintEngine  (约束投影器)       │
│  ├─ EquipmentLibrary  (设备原型库)       │
│  └─ TimeSeriesEngine  (LSM-WAL 存储)     │
├─────────────────────────────────────────┤
│  通用 OS 抽象层                          │
│  └─ Scheduler / Memory / IPC / Network  │
└─────────────────────────────────────────┘

系统调用示例

Agent 通过系统调用访问内核电力服务，无需自己重建任何领域模型：

use eneros_os::syscall::*;

// 拓扑查询
let bus = ctx.syscall(GetBus { id: bus_id }).await?;
let neighbors = ctx.syscall(GetNeighbors { bus: bus_id }).await?;
let island = ctx.syscall(GetIsland { bus: bus_id }).await?;

// 潮流触发
let result = ctx.syscall(SolvePowerFlow {
    method: PowerFlowMethod::NewtonRaphson,
    max_iter: 20,
    tolerance: 1e-6,
}).await?;

// 约束校验
let check = ctx.syscall(CheckConstraint {
    command: command.clone(),
}).await?;

// 时序查询
let series = ctx.syscall(QueryTimeSeries {
    point: "bus_1_voltage",
    range: (start, end),
    aggregation: Some((Aggregation::Avg, Duration::minutes(5))),
}).await?;

// 设备操作
ctx.syscall(SetTapPosition { transformer_id, position: 5 }).await?;
ctx.syscall(SetGeneratorOutput { bus: 1, mw: 80.0 }).await?;

与传统 OS 对比

下一步

• Agent-as-Grid-Node - Agent 即电网节点，了解 Agent 如何与电气节点绑定
• 约束即法律 - 约束引擎的工作原理与投影算法
• 时序原生 - 时序存储引擎的架构与 API
• 实时确定性 - 双执行域如何保证保护逻辑的微秒级响应