ch01：把三份文件翻译成一张架构图——场站业务建模实录

需求评审会开到第三个小时，后端老张终于忍不住了："别念文件了，我们直接开工吧，Modbus 先接起来，边做边改。"

带我们做电气一次设计的顾问陈工慢悠悠地回了一句："你知道 AGC 指令从省调到你 PCS 的链路有多长吗？"老张卡住了。陈工在白板上画了七个框：省调主站、场站 RTU、EMS、功率分配、PCS、升压变、并网点——"这条链路上任何一个环节的时序没想清楚，你写出来的就不是 EMS，是定时炸弹。"

那一页白板，后来成了我们整个项目的起点。这一章讲清楚：我是怎么把业主的三份文件，翻译成一张能指导十二个月开发的架构图的。

一、事故现场：三份文件，三种语言

放在我们面前的需求，是三种完全不同的"语言"写成的：

1. 技术协议：业主与设备厂商的合同附件，语言是"设备清单+通信接口"——64 台 3.125MW 风机、约 700 台华为 SUN2000 组串式逆变器、24 台 2.5MW 储能 PCS 对应 60MW/120MWh 磷酸铁锂电池，外加升压站的保护装置、智能电表、气象站；
2. 两个细则：西北能监局的监管文件，语言是"考核指标"——AGC 的投运率、响应速度、调节精度，AVC 的电压控制合格率，每一条背后都是真金白银的罚则；
3. 现货申报接口规范：省电力交易中心的文件，语言是"报文格式"——96 点功率申报曲线、日前/实时市场的时间窗。

第一周的教训是：把三种语言当成同一种来读，就会漏掉致命的交叉项。比如技术协议里"逆变器支持远程功率调节"这句话，落实到两个细则的语境里，意思是"AGC 指令必须能在一分钟内落到每一台逆变器"——而落实到现货语境里，又变成"96 点申报曲线与实际出力的偏差要收敛在免考核区间内"。同一个功能，三种语境三套验收标准，漏一条就是上线后的罚款单。

二、梳理：先画数据流，再画功能

我做了十五年企业软件，第一反应还是画功能模块图。陈工否了："场站系统先画数据流，数据流对了，功能模块只是数据流上的锚点。"

于是我们画出了这张全场数据流（从下往上）：

1. 设备层：700 台逆变器、24 台 PCS、64 台风机，通过 RS485/以太网挂到通信管理机，跑 Modbus TCP/RTU，逆变器侧秒级上送功率、电压、电流、温度、状态字；
2. 采集层：通信管理机汇聚后经纵向加密装置进入安全 I 区，EMS 的采集服务按通道轮询，写入实时库和时序库；
3. 控制层：EMS 的调度引擎产出 15 分钟尺度的充放电计划；AGC 模块接收省调 104 下发的 1~5 分钟尺度全场有功指令，叠加本地计划后分解到每台设备；
4. 执行层：功率分配模块把全场指令拆解为单机指令下发，PCS 毫秒级闭环、逆变器百毫秒级响应；
5. 市场层：EMS 汇总预测与计划数据，按交易中心接口规范生成 96 点申报曲线，经反向隔离装置送出生产大区。

这张图最大的价值是暴露了两个此前没人提的问题：第一，安全 I 区到管理信息大区之间必须过正向/反向隔离装置，现货申报走反向隔离，意味着申报链路的延迟和协议约束（隔离装置通常只透传纯文本或特定文件）必须在架构上预留；第二，AGC 指令流和调度计划流在控制层汇合，必须定义"谁说了算"的优先级仲裁——这个仲裁逻辑后来成为 ch08 的主角。

三、底层原理：三个时间尺度，就是 EMS 的世界观

陈工在白板上最后写的三行字，我到现在都贴在工位上：

控制环	时间尺度	决策者	典型输入
PCS 闭环	毫秒~百毫秒	PCS 本体	单机电流电压指令
AGC 跟随	秒~分钟	省调+场站 EMS	全场有功/无功指令
调度优化	15 分钟~24 小时	EMS 调度引擎	现货价格、预测曲线、SOC

任何一层的时间尺度错配，都会出事故：拿 15 分钟尺度的调度计划直接去控制 PCS，储能会错过 AGC 指令的秒级响应，两个细则考核直接爆表；反过来拿秒级逻辑去做 24 小时优化，算力爆炸而且毫无意义。EMS 的本质，就是在三个时间尺度之间做翻译和仲裁。

这个世界观直接决定了我们改造 OpenEMS 的施工图：OpenEMS 的调度引擎（Jenetics 遗传算法）原生工作在 15 分钟尺度，这层可以保留骨架、改目标函数；它没有 AGC 秒级仲裁层——必须新写；它有 Modbus 采集层——设备驱动齐全，改寄存器编排就行。业务建模到这里，改造范围已经能画出来了。

四、正确姿势：从需求到测点表的翻译链

架构定了，接下来是把需求落到可开发的粒度。我们的翻译链条是：需求条款 → 控制回路 → 测点表 → OpenEMS 通道。举一个真实的例子，两个细则里"AGC 调节精度"条款的翻译过程：

1. 需求条款：AGC 调节精度不达标要按偏差电量考核；
2. 控制回路：省调指令 → EMS 仲裁 → 功率分配 → PCS 执行 → 并网点电表实测反馈 → EMS 闭环校正；
3. 测点表（节选）：

测点	来源	周期	用途
PCC 有功功率	并网点关口表	1 s	闭环反馈、考核对账
全场 AGC 指令	省调 104 遥测	1 s	仲裁输入
PCS1~24 有功出力	PCS 寄存器	1 s	分配校验
逆变器组串电流	华为逆变器	60 s	发电性能分析

1. OpenEMS 通道：每个测点对应一个 Channel，挂在对应设备的 Nature 实现上——并网点关口表是一个 ElectricityMeter 实例，PCS 是 Ess 实例。OpenEMS 的 Nature 抽象在这里第一次显示出价值：设备千差万别，但"储能"这个 Nature 的通道集合是稳定的，上层调度引擎只面向 Nature 编程，换 PCS 厂商不动上层代码。

这个翻译链后来成了团队的纪律：任何需求，不落到测点表就不许开代码。老张起初嫌烦，第三周联调时他把这句话原样讲给了新来的同事。

五、数据说话：一个场站有多大

按上面的测点表逐设备铺开统计，全场规模如下：

• 测点规模：全场有效测点约 6 万个，其中秒级采集的关键测点约 1.5 万个（功率、电量、状态字），分钟级测点约 4.5 万个（组串电流、温度等趋势量）；
• 数据量：1.5 万个秒级测点每天产生约 13 亿个数据点，原始写入约 26GB/天，经时序库压缩后落盘 2~3GB/天，年增量约 1TB——这是 ch11 选型 IoTDB 的直接输入；
• 控制规模：EMS 峰值需要在一秒内完成"接收 AGC 指令→仲裁→分解到 24 台 PCS+700 台逆变器"的完整链路，单机指令下发的 P99 要求控制在 200ms 内——这决定了功率分配模块不能有任何反序列化和数据库 IO 放在热路径上；
• 申报规模：96 点申报曲线每 15 分钟一个申报点，日前市场 D-1 日 10:00 前申报，实时市场滚动修正——时间窗口本身就是硬约束。

这四个数字，分别决定了时序库选型、控制热路径设计、通信超时预算和调度任务的定时基准。业务建模做到这个粒度，才算"翻译完成"。

六、面试怎么答

"讲讲你在新能源场站 EMS 项目里怎么做需求建模的"——这题的答题框架，就是本章的结构：

1. 先讲输入的多样性：三种语言（设备清单、监管考核、市场交易）指向同一套功能，说明需求建模的第一件事是做交叉映射，我会举"逆变器远程调节"在三种语境下的不同含义；
2. 再讲方法论：场站系统先画数据流再画功能模块，数据流暴露了安全分区和 AGC 仲裁两个隐藏需求；
3. 然后亮世界观：三个时间尺度的控制环，这是 EMS 区别于普通 IoT 平台的本质，也是架构决策的依据；
4. 最后落到工程纪律：需求→控制回路→测点表→领域模型的翻译链，以及它如何在 OpenEMS 的 Nature 抽象上着陆。

面试官追问"为什么不用大模型/低代码快速出原型"，标准答案回到时间尺度上：原型可以糊弄采集和展示，但控制环的时序正确性是建模问题，不是编码速度问题。

七、落地清单

1. 拿到任何场站项目，先列设备清单，再画数据流，最后才画功能模块；
2. 把监管文件（两个细则）和市场文件（现货规则）里的每一条考核指标翻译成"控制回路+测点表"，形成需求追踪矩阵；
3. 明确三个时间尺度的控制环边界，并且确认每个功能只属于一个尺度；
4. 提前确认安全分区对通信链路的约束（正反向隔离装置的协议白名单），它会影响市场申报链路的架构；
5. 下一章（ch02），我们带着这张架构图，拆开 OpenEMS 看它的 Edge/Backend/UI 三层到底长什么样——先看懂别人的房子，再动手砸墙。