开篇：中标之后，我为什么决定改造 OpenEMS 而不是自研
去年冬天，我们中标了甘肃一座风光储一体化场站的 EMS（能量管理系统）项目。业主是省内的新能源投资集团，场站规模：200MW 风电、150MW 光伏、配套 60MW/120MWh 电化学储能。中标通知书还没焐热，技术协议谈判桌上业主方就摆出了三份文件：省调的 AGC/AVC 考核要求、《西北区域发电厂并网运行管理实施细则》和《西北区域并网发电厂辅助服务管理实施细则》——业内俗称"两个细则"——以及一份电力现货市场申报接口规范。
项目经理散会后问我：这单接不接？我说接，但 EMS 不能从零自研。这篇开篇，就是把这个决定背后的账，一笔一笔摊开给你看。
一、先说清楚：这座场站的"大脑"要干什么
风光储一体化场站的 EMS，本质上是全场功率的调度中枢。它要同时回答四个问题：
- 设备层怎么管：华为的组串式逆变器、阳光的集中式逆变器、风机的变流器、BMS 和 PCS，每个厂家的通信协议和寄存器表都不一样，EMS 要把它们全部接入并实时控制；
- 电网层怎么答：省调通过 IEC 60870-5-104 规约下发 AGC 有功指令，场站必须在秒级响应，响应速度、精度、可用率都挂钩"两个细则"考核——考核不达标，罚款之外还会影响两个细则的补偿分摊；
- 市场层怎么赚：甘肃是全国首批电力现货市场试点省份之一，现货环境下储能的每一次充放电都要对着日前/实时出清价格做决策，峰谷套利的策略直接决定这个场站的收益模型；
- 安全层怎么守：国家发改委 2014 年第 14 号令《电力监控系统安全防护规定》要求生产控制大区与管理信息大区之间横向隔离、纵向加密认证——EMS 不是想上云就能上云的。
这四层，任何一层都不是"写个 Spring Boot 服务"能糊弄过去的。
二、自研的账，算完人就麻了
团队当时的配置是 4 个 Java 后端、1 个前端、1 个兼职电气工程师。我把自研路线的坑逐项列了出来：
| 模块 | 要做的事 | 估算 |
|---|---|---|
| 设备接入 | Modbus TCP/RTU 栈、华为/阳光寄存器表、风机协议适配 | 6 人月 |
| 电网接口 | IEC 104 规约栈、省调点表、AGC 两级控制逻辑 | 6 人月 |
| 调度引擎 | 功率分配优化算法、现货价格响应、约束求解 | 8 人月 |
| 时序数据 | 百秒级采样的存储压缩、曲线查询、对账报表 | 3 人月 |
| 监控 UI | 全场一次接线图、实时曲线、告警中心 | 6 人月 |
| 工程化 | 安全分区部署、双机热备、现场联调 | 6 人月 |
合计 35 人月。4 个后端就算全押上，光后端侧就要一年多——还不算任何一次返工。而业主要求明年迎峰度冬前投运，工期十二个月，死线砍不动。
更麻烦的是风险分布：35 人月里最贵的是调度引擎那 8 人月，因为优化算法没有"写完就能跑"这一说，它要靠一轮轮仿真和现场数据喂出来。自研等于把最贵、最不确定的部分留在了最后。
三、候选对比：商用、自研、开源改造
我把三条路线摆在一起比：
- 商用 EMS 整套采购：报价能到项目额的一半以上，而且是黑盒——策略改不动、点表要扯皮、后续每个场站都要交授权费。我们做的是长期生意，被卡脖子不可接受；
- 纯自研：就是上面那笔 35 人月的账，工期和算法风险都顶格；
- 开源改造：找一套工业级开源 EMS 做底座，把自研力量全部砸在国内场景的差异化改造上。
第三条路的前提，是那套开源底座必须经得起三个拷问：许可证能不能商用闭源衍生？工业现场验证过没有？架构改起来疼不疼？
四、为什么是 OpenEMS
最后我们选了 OpenEMS——德国 FENECON 公司发起、OpenEMS Association e.V. 运营的开源能量管理系统。选择理由有三个，每个都有硬数据支撑：
第一，规模和成熟度。 我 clone 了仓库逐项统计：233 个 OSGi 模块、5315 个 Java 文件、约 60 万行 Java 代码，从 2016 年迭代至今整十年。它不是实验室项目——FENECON 的家用储能、工商业储能产品线全线跑的就是这套系统（FEMS），德国电价高、峰谷价差大，调度策略是被真金白银验证过的。
第二，模块架构对"改造"极其友好。 OSGi 模块化意味着每个设备驱动、每个协议桥、每个控制算法都是独立模块，我们完全可以只动需要动的部分。协议桥层面 Modbus、IEC 104、MQTT 现成；设备驱动层面华为（io.openems.edge.huawei 模块直接就是华为 SUN2000 逆变器的驱动）、三星、FENECON 一应俱全，接阳光这类 SunSpec 协议设备走 generic 通道即可；时序库层面 InfluxDB 和 Apache IoTDB 都有现成集成——IoTDB 恰好是国产时序数据库，在国内电力行业的合规叙事里这是加分项；甚至功率预测都有 LSTM、相似日等多个 predictor 模块。
第三，许可证干净。 Edge 和 Backend 用 Eclipse Public License 2.0（EPL-2.0），这是 Eclipse 基金会的弱 copyleft 许可：修改源码可以闭源商用，只需保留版权声明；只有 UI 层是 AGPL-3.0。对我们这种"核心代码要进生产控制大区"的场景，EPL-2.0 意味着法务这关能过。
五、改造的三根硬骨头
开源不是银弹。德国场景和甘肃场景的差异，就是我们要啃的三根硬骨头：
- 调度引擎的"世界观"不同。OpenEMS 的遗传算法调度引擎（基于 Jenetics 库）是为德国户用/工商储设计的：15 分钟一个时段、24 小时滚动优化、适应度函数围绕峰谷电价套利。而甘肃现货是分钟级出清，还要叠加"两个细则"的考核惩罚项和 AGC 指令跟随。调度目标函数要从"省钱"改成"收益减罚款"，引擎内核能不能扛住，是整个项目最大的技术悬念；
- 协议栈要"上通省调、下达设备"。Modbus 桥和 IEC 104 桥 OpenEMS 都有，但华为、阳光逆变器的寄存器编排、省调 104 点表的规约化配置、以及"AGC 指令优先于本地优化"的两级控制仲裁，都要我们自己写；
- 14 号令安全分区落地。OpenEMS 天然是 Edge/Backend 分离架构——Edge 面向设备、Backend 面向云端。这跟安全分区的要求几乎是同构的：Edge 瘦身后塞进生产控制大区（安全 I/II 区），Backend 和 UI 留在管理信息大区，中间用正反向隔离装置。架构同构不等于开箱即用，通信链路上每一跳都要按等保和 14 号令重新审一遍。
六、数据说话：复用率这笔账
把改造范围跟 233 个模块一对照，结论比我预想的还乐观：我们真正需要新写或重写的代码，预估 3 万到 5 万行，占总代码量不到 8%。原来 35 人月的自研账，变成了 12 人月的改造账——省下来的不是工作量，是最不可控的调度算法和协议栈那 14 人月。
换句话说：自研路线下我们是一个算法团队，改造路线下我们是一个电气工程团队。前者招人难、周期长，后者我们本来就有。
七、这个系列怎么写
接下来我按改造的实际推进顺序，把这个项目拆成 14 篇：
- ch01 业务建模：把业主那三份文件翻译成软件需求，场站拓扑与数据流建模；
- ch02 架构解剖：拆解 OpenEMS 的 Edge/Backend/UI 三层与 OSGi 模块体系；
- ch03 工程化：fork 仓库、OSGi/bnd 工具链、许可证合规清单、CI 搭建；
- ch04 Modbus 协议栈：华为/阳光逆变器接入，寄存器表与通道编排；
- ch05 IEC 104 上省调：规约栈源码分析、点表配置、AGC 两级控制仲裁；
- ch06 引擎移植：把遗传算法调度引擎从 FENECON 场景剥离出来；
- ch07 适应度改造：峰谷套利 → 甘肃现货收益 + 两个细则惩罚项；
- ch08 AGC 跟随：指令优先级仲裁与调度引擎的实时性改造；
- ch09 功率预测：OpenEMS predictor 模块在西北风光资源下的适配；
- ch10 安全分区：14 号令落地，Edge 瘦身进安全区，隔离装置选型；
- ch11 IoTDB 部署：国产时序库替换 InfluxDB 的迁移实录；
- ch12 仿真验证：用 OpenEMS Simulator 模块做全场联合仿真，用数据证明改造没跑偏；
- ch13 面试 30 题：把整个项目拆成面试官最爱问的 30 个问题。
写作原则先立在这里：涉及业主和场站的敏感信息全部脱敏，所有指标数据来自仿真环境和公开资料；代码全部真实可查，我 fork 的改造仓库会随章节同步推进。
八、落地清单
如果你也在评估"改造开源 EMS"这条路，这篇开篇对应的行动项：
- 把候选开源项目的许可证、模块数、生产验证案例列成对照表——许可证是第一否决项；
- 统计目标仓库的模块数与代码量，估算复用率，低于 70% 就要重新考虑自研；
- 找出"德国场景 vs 本地场景"的真正差异点，差异点在应用层可以改造，在内核层要慎重；
- 下一章（ch01），我们从业主的三份文件开始，把"场站大脑"翻译成一张软件架构图。
系列已开更，欢迎追更。改造 OpenEMS 的每一步，都会留痕在这个系列里。