一个嵌入式 Linux 工程师对储能后备管理系统充放电控制链路的完整梳理前言我一直在维护和开发一套储能后备管理系统它运行在基于 D9360 平台的嵌入式 Linux 上交叉编译为 aarch64 产物采用 RAUC A/B 槽 OTA 和 dm-verity 只读挂载。这个系统本质上是储能电站ESS的「大脑」——它要实时采集电池、PCS、电表、光伏等设备的数据经过一套 EMS能量管理系统的决策逻辑算出「现在该充电还是放电、充放多少」然后把控制指令下发给 PCS储能变流器去执行。在整个项目里最核心、最值得深挖的就是这条「充放电控制链路」。它横跨了采样、决策、控制、执行、下发多个环节牵扯到状态机、时段计划管理、功率分配、PID 闭环、以及 TCP 和 CAN 两种物理下发通道。这篇文章我把自己这段时间通读代码、逐函数梳理、以及为新机型做接入时积累的理解系统性地总结下来。全部结论都对应到具体的函数和变量做到有理有据。一、系统全景储能后备管理系统的架构在深入充放电链路之前先交代一下整个系统的骨架否则后面的函数会显得孤立。1.1 双进程模型与三层插件架构系统采用双进程模型syshand守护进程负责 BSP 扩展安装、心跳监控、系统命令代理通过 System V 共享内存 命名信号量与主进程通信。nccu_app主进程真正的业务程序负责所有数据采集、处理、上报和控制。主进程内部是三层插件化架构samplers采集、reporters上报、comm_ports通信都是运行时通过dlopen/dlsym动态加载的.so模块。数据流是设备 → samplers采集→ DPR数据处理含配置/事件/告警/表达式→ reporters上报→ 云平台。1.2 我关心的那几个模块充放电控制链路涉及的关键模块我在这里先列出来后面会反复引用模块文件职责ccuccu/主控CCU侧EMS 决策、功率分配、指令下发batt_samplerbatt_sampler/电池组Pack侧电池状态机、指令产生ESS 采样入口ccu/ess传统 ESS 机型的采样主循环Sample_ESS836 采样入口ccu/power_device_unit/can_comm_main.c机型 CAN 采样CAN_Samples这里先点出一个我后来反复强调的关键认知整个充放电控制本质上是「决策」和「执行」分离的两层。EMS 负责决策「什么时候充放、充放多少」电池状态机负责执行「怎么安全地把这个决策落地成 PCS 动作」。理解了这一点后面的每一个函数就都有了归属。二、充放电控制的四层模型我把整条充放电控制链路抽象成四层模型。这是我通读代码后总结出的骨架也是理解后面所有细节的总纲┌─────────────────────────────────────────────────────────┐ │ 第一层决策层EMS 管理计划 │ │ Ems_Mgmt/ GetCurrentTimeSector │ │ → 决定「充 / 放 / 待机」模式 总功率限值 │ ├─────────────────────────────────────────────────────────┤ │ 第二层控制层功率管理流水线 │ │ Ems_Mgmt_Main里的 12 个函数 │ │ → PID 闭环 滤波 节点映射 排序 功率分配 │ ├─────────────────────────────────────────────────────────┤ │ 第三层执行层电池状态机 │ │ STBATT_STATEMACHINE_STATE 的 6 个状态 │ │ → 结合电池实时状态把决策转成 PCS 控制指令 │ ├─────────────────────────────────────────────────────────┤ │ 第四层下发层物理通道 │ │ Control() nParamId │ │ → 传统机型 TCP / 机型 CAN最终到达 PCS │ └─────────────────────────────────────────────────────────┘这四层之间通过 DPR数据处理的变量节点来「交接」数据而不是直接函数调用。这是这个项目最巧妙的地方之一——各层解耦靠共享的变量节点通信。我会在后面的链路里具体说明这些节点。三、决策层时段计划充放电管理3.1 两个维度的「类型」概念在讲决策之前必须先厘清两个容易混淆的类型它们贯穿整个系统系统类型 SYSTEM_TYPE这是系统级架构区分 风冷、液冷、站级 EMS。它决定了采样函数分发到哪一条路。设备/机型类型emESSDevTypeESS_DEVICE_TYPE这是具体机型/硬件配置区分 液冷一体、液冷STS、液冷备电柜、液冷新型。我在做新机型接入时最关键的一步就是搞清楚 836 到底落在哪个维度——它是LIQUID_COOLING一个机型维度而不是系统类型维度。3.2 时段计划的本质GetCurrentTimeSector时段计划充放电的核心是GetCurrentTimeSector这个函数。它的作用是根据当前时间查时段计划表确定现在处于哪个时段、该充还是该放。这个函数做的事情我归纳为三步取时段索引nTMSector Get_EmsCfgPlan_Setctor(blobEmsCfgPlan, bFromOrg)根据当前时刻在blobEmsCfgPlan.emsLmtSectors[]时段计划表里定位到当前时段。取时段参数把该时段的EMS_LIMIT_SECTOR内容读出来包括emBatt_WorkMode工作模式、nStopSOC停止 SOC、nActvPwrLmt有功功率限值、nBattGrpPwrLmt电池组功率限值。SOC 与状态判断如果 SOC 已经达到停止条件充电时 SOC 已满、放电时 SOC 已空或者系统状态不对就把工作模式强制改成BATT_WORKMODE_IDLE待机。最后它把结果写到pEMS-emBatt_WorkModeReq这就是整个决策层的「输出」——一个枚举值只有三种有效含义BATT_WORKMODE_FIRST_CHRGING// 充电BATT_WORKMODE_FIRST_DISCHRG// 放电BATT_WORKMODE_IDLE// 待机/关机3.3 两个 PlanSectorOrg 与 Now这里有个我在梳理时才彻底弄明白的设计planSectorOrg和planSectorNow两个结构体。planSectorOrg原始计划直接来自数据库/配置的时段计划表是「计划本来的样子」。planSectorNow当前生效计划是经过 SOC 判断、防逆流/防过载自动调整后的「实际要执行的样子」。在正常时段计划下planSectorNow先拷贝自planSectorOrg然后根据实时条件做修正。而在自动充放电防逆流充电、防过载放电触发时会临时改写第 0 段计划让系统「临时」进入充放电状态。3.4 决策总入口Ems_MgmtEms_Mgmt是决策层的总入口。它被Ems_Mgmt_MainESS 主管理和Ems_Mgmt_Main_SSEMS 管理共同调用。它的核心逻辑是REMS 远程控制判断如果启用了 REMS 远程控制且处于远程模式则bCtrlByREMS TRUE直接采用服务端下发的功率跳过本地时段计划。本地自动充放电调度bCtrlByREMS FALSE时NEED_AUTODISC()满足 → 防过载自动放电NEED_AUTOCHRG()满足 →防逆流自动充电产出两个总限值fTotal_PessChgAvaliable总可充电功率和fTotal_PessDischgLmt总可放电功率。这两个限值的计算就是后面Calc_ESS_ChgLmtPower充电限功率防过载和Calc_ESS_DischgLmtPower放电限功率防逆流完成的。它们本质上回答了一个问题在保证不过载、不逆流的前提下系统最多能充多少、放多少。我在梳理这一段时最深的体会是时段计划解决「要不要充放」防逆流/防过载解决「充放的上限是多少」两者叠加才得到最终的决策输出。四、控制层Ems_Mgmt_Main_ESS 的完整功率管理流水线这是整条链路里函数最多、逻辑最密集的部分。Ems_Mgmt_Main_ESS内部串起了一条 12 步的功率管理流水线我把它分成九个阶段来梳理4.1 决策Ems_Mgmt第一步就是上一节讲的决策。它算出了emBatt_WorkModeReq和总功率限值。这是整个流水线的「输入」。4.2 闭环控制Power_ControlPower_Control是 PID 闭环控制环。它的作用是让实际充放电功率精确跟随目标功率而不是简单开环按目标发指令。关键逻辑充电时目标target_power fTotal_PessChgAvaliable放电时target_power -fTotal_PessDischgLmt反馈量是meter_power f_PcabMeter柜内电表实测功率。PID 根据误差调节输出fPidOut/fTotal_PidOut。这里有一个细节如果 PID 未使能bEnablePID FALSE就直接透传目标值不做闭环。PID 的作用是消除「目标功率」和「实际功率」之间的稳态误差让系统在负载波动时也能精准跟随。4.3 平滑滤波RefreshPowerPID 输出可能存在高频抖动Refresh_Power用滑动平均滤波Samp_Filter把它平滑掉得到「剩余可充/可放功率」充电fRemain_Lmt MIN(PID输出, 平均滤波值)放电fRemain_Req MIN(PID输出, 平均滤波值)有一个很重要的设计高灵敏度模式bHiSens_Chrg/Disc会跳过滤波直接用瞬时值。这是为了防逆流/防过载场景下的快速响应——这类场景要的就是「快」不能因为滤波而延迟。4.4 节点参数映射Refresh_NodeParam这是把「系统级」决策落到「每个电池组」的关键一步。我之前在梳理时差点漏掉它后来发现它是整个链路里最关键的一环。它的核心是这一句pCalc_Node-emBatt_WorkModepEMS-emBatt_WorkModeReq;// 总模式 → 每个节点pCalc_Node-nStopSOCReqpPlanSectorNow-nStopSOC;// 停止 SOC 下发同时它计算每个节点的充放电能力fMax_Chrg_PwrAbility/fMax_DisChrg_PwrAbility并做 SOC 判断如果某个节点已经充满nSOC nStopSOCReq就把它充电能力清零、模式改成 IDLE。这一步的意义在于emBatt_WorkModeReq是「系统级」的但 PCS 是按「节点电池组」控制的所以必须把系统级模式映射到每个节点的calc_Node[n].emBatt_WorkMode。4.5 均衡排序Sort_NodeOrderByChrgedEnergySort_NodeOrderByChrgedEnergy按fChrgedEnergy已充能量从小到大排序能量低的排前面。这样充电时优先充能量低的组实现电池组间的均衡。它的实现细节值得注意有 20 分钟节流MAX_S_SORTED_NODE避免每个周期都排序导致频繁抖动只有能量差超过 100KWh 才真正交换顺序。4.6 功率分配MPET Dispatch这是「控制层」的核心输出。分充放电两条对称的路径充电路径MPET_Calc4DispatchChrgMode计算参与充电的节点数nChrg_NodeNum和功率分配率fChrg_PwrRate累加总充电能力fTotalPM_Chrg_PwrAbility。它用fRemain_ACChrgingPwr_Lmt / 总能力得到分配比例并用 [0.7, 1.0] 区间做滞回避免抖动。Dispatch_ESSLmtBattChrg_Power按各节点充电能力比例把剩余可充电功率分到每个组fACDC_Distri_4_BattChrg_Pwr(该组充电能力/总能力)× 剩余可充电功率放电路径MPET_Calc4DispatchDisChrgModeDisPatch_ACLoadReq_DisChrg_Power完全对称方向相反得到fBatt_Distri_4_ACDC_Pwr。4.7 无功分配DisPatch_ReactivePower在充放电的同时把 PCS 的剩余容量额定功率 - 已用有功拿来输出无功fQoutput_Distri4ACDCfACDC_Max_Output_Pwr_Ability-fPCS_Used;// 剩余容量fQoutput_Distri4ACDCMIN(剩余容量,fRemain_QoutputLmt);// 不超总无功限值4.8 恢复顺序Sort_NodeOrderByNodeIdx前面为了均衡按能量排序了这里按nNodeIdx节点索引恢复原始顺序保证后续按节点位置处理时对应关系正确。4.9 滤波输出Filter_Disttribute分配完功率后再做一次滑动平均滤波得到fAvg_ChrgLmtPower/fAvg_DisChrgingLmtPower若平均功率低于最小输出阈值该节点改 IDLE最后汇总clientInfoSum并 push 给上层。这一步是整个控制层的「出口」。它算出的calc_Node[n].emBatt_WorkMode、fAvg_ChrgLmtPower、fAvg_DisChrgingLmtPower、fACDC_Distri_4_BattChrg_Pwr、fBatt_Distri_4_ACDC_Pwr就是要往下传给电池状态机的数据。4.10 流水线小结把这 12 个函数串起来就是一条清晰的「决策 → 控制 → 分配 → 输出」的功率管理流水线阶段函数本质决策Ems_Mgmt要不要充放、上限多少控制Power_ControlPID 闭环精确跟随平滑Refresh_Power滤波消抖映射Refresh_ESS总模式 → 每个组均衡Sort_NodeOrderByChrgedEnergy谁先充放分配MPET Dispatch每个组分多少无功DisPatch_Output顺带发无功恢复Sort_NodeOrderByNodeIdx还原顺序输出Filter_Disttribute平滑 交棒给状态机五、执行层电池状态机5.1 状态机是什么控制层算出「每个组该充放多少」之后谁来执行答案是电池状态机STBATT_STATE。它是每个电池组Pack各自维护的一个表驱动状态机作用是把「决策」安全地落地成「PCS 动作」。它不决定「什么时候充放」那是决策层的事它只负责「怎么安全地充放」判断电池现在能不能充放SOC、电压、电流、告警、BMS 禁止标志、CCU 状态。下发 PCS 指令整流充电 / 逆变放电 / 停机。过程兜底充满停机、放完停机、故障停机、离网防过放、实时调电流。5.2 六个状态STBATT_STATE枚举定义了六个状态每个对应一个On处理函数状态处理函数职责IDLE 空闲OnIdle决策入口判断接下来充/放/离网/故障WAIT_CHARGE 等待充电OnWaitCharge充电启动的确认期PCS 上功率需 30sIN_CHARGING 充电中OnCharging充电过程管理 停止判断 电流调整IN_DISCHARGING 放电中OnDischarging放电过程管理 停止判断 电流调整FAULTED 故障OnFaulted故障停机恢复后回 IDLEOFFGRID 离网OnOffGrid离网逆变运行STS 切离网后5.3 表驱动与主调度状态机是表驱动的stateMachs[]数组把状态和On函数绑定INIT_ST_STATE_MACHINE宏。主调度循环每个采样周期、对每个 Pack 执行emStatepCurrState-pfnAction(pSTBatt_Rough,n);// 调当前状态的 On 函数返回下一状态pLastStatepCurrState;pCurrStatestateMachs[emState];// 切换状态if(pCurrState!pLastState)pCurrState-tm_Enter[n]GetCurrentTime();// 记录进入时间5.4 状态转移逻辑OnIdle是核心决策入口按优先级判断通信失败 / 告警 / CCU 非空闲 → FAULTEDSTS 离网 → OFFGRIDJudge_IfNeedChg_Start()允许→ 发整流启动 → WAIT_CHARGEJudge_IfNeedDisChg_ON()允许→ 发逆变启动 → IN_DISCHARGING电流 2A → IN_CHARGING-2A → IN_DISCHARGING而OnCharging/OnDischarging里最关键的停止条件就是把 EMS 算出来的emBatt_WorkMode拿来判断// 充电中如果 EMS 不再要求充电就停机if(...||calcNodeData[n].emBatt_WorkMode!BATT_WORKMODE_FIRST_CHARGING){Send_Ctrl_CCU(GRP_ACDC_STOP);returnSTBATT_STATE_IDLE;}这就是决策层和执行层的「握手点」决策层把时段计划的结果emBatt_WorkModeReq一路映射成calc_Node[n].emBatt_WorkMode状态机读到这个字段一旦它不再是「充电/放电」就自动停机。时段计划「按时段充放」最终是靠状态机这一句来实现的。六、功率分配与下发功率的区别这是我梳理过程中最想讲清楚的一个点因为它最容易让人困惑。6.1 三个层次的「功率」目标功率分配结果fACDC_Distri_4_BattChrg_Pwr/fBatt_Distri_4_ACDC_Pwr单位 kW是「这个组应该充放多少」。下发控制量fGrpVoltLmtV/fGrpCurrLmtA/fGrpPwrLmtkW是「发给 PCS 的限值指令」。实际功率PCS 实际电流 × 电压是「真跑出来的功率」。6.2 为什么要「转成电流」下发关键在Send_Ctrl_CCU里的转换// 把「分配功率 kW」转成「电流限值 A」fLimitCurrent(fACDC_Distri_4_BattChrg_Pwr*1000)/(fPackTotalVolt2);blobGrpRectCtrl.fCtrlPowerfACDC_Distri_4_BattChrg_Pwr;// 功率blobGrpRectCtrl.fGrpCurrLmtMIN(fLimitCurrent,fAllow_MaxChargeCurr);// 电流限值blobGrpRectCtrl.fGrpVoltLmtMIN(1500,fAllow_LmtChargeVolt);// 电压限值原因是PCSACDC 模块本质是电压源 电流源它按「电压限值 电流限值」控制不直接按功率控制。所以功率目标必须除以电池电压转成电流电流(A) 功率(kW) × 1000 / 电池电压(V)。6.3 为什么要做功率分配因为 EMS 算的是「总功率」但系统有多个电池组必须把总功率按各组能力SOC、额定功率、健康度拆给每个组。功率分配解决「多组之间的功率怎么分」并通过能量排序实现组间均衡。6.4 完整链路从目标功率到 PCS 的完整链路EMS 分配 → calc_Node[n].fACDC_Distri_4_BattChrg_Pwr目标功率 kW → PushAllData → 221n,203 → 状态机 calcNodeData[n] → Send_Ctrl_CCUfGrpCurrLmt 功率×1000/电压转电流 A → Push(200, 232) → Control() nParamId232 → byData 打包组号命令电压×10电流×10功率×10 → DoTCPSessionTCP或 Set235kWPCS_WrokModeCAN→ PCS七、数据下发链路TCP 与 CAN 的异同7.1 上游完全相同充放电指令的产生传统机型和 836 机型走的是同一套电池状态机 → Send_Ctrl_CCU → Push(200, 232) → Control() nParamId232。在 Control 函数里才按emESSDevType分叉。7.2 下游分叉传统机型液冷/风冷— TCP 下发byData[0]0x31nGrp;// 组号byData[1]命令类型;// 0x00停止/0x01整流/0x02调流/0x03逆变/0x04待机byData[2..3]fGrpVoltLmt*10;// 电压限值放大10倍byData[4..5]fGrpCurrLmt*10;// 电流限值放大10倍byData[6..7]fGrpPwrLmt*10;// 功率限值3.04版以上DoTCPSession(pCCU,NL_MSG_UCTL,byData,nSendLen,...);// TCP 下发836 机型 — CAN 直发if(pCCU-emESSDevTypeLIQUID_COOLING_836){t_ACDCControlData ctrlData;ctrlData.u32CtrlVoltfGrpVoltLmt*1000;// 电压放大1000倍定标ctrlData.u32CtrlCurrfGrpCurrLmt*1000;// 电流充电取负ctrlData.u32CtrlPowerfCtrlPower*1000000;// 功率放大1000000倍Set235kWPCS_WrokMode(pCCU,SGNo,ctrlData);// 拆多个 0x24 CAN 帧// SetBattSideOutVolt_0x24 / SetBattSideOutCurr_0x24 / SetActivePower_0x24 / SetOnOff_0x24// → TxCAN3Buff → CAN → N2402 235kW PCS 模块}7.3 对比总结环节传统机型836 机型上游状态机 200,232相同相同控制数据结构A_BLOB_GRP_RECT_AUTOCTRL_CMDfloatt_ACDCControlData整数定标下发函数DoTCPSessionSet235kWPCS_WrokMode物理通道TCP/以太网CAN 总线控制协议内部 TCP 协议6 字节指令0x24 CAN 协议电压/电流/功率/模式多帧定标精度float 直接下发放大 1000/1000000 倍转整数这个差异给了我一个重要启发836 的 CAN 下发链路已经完整实现所以给 836 做时段计划充放电关键不在「下游发送」而在「上游的决策和判断」。八、新型液冷机型接入的实践与思考8.1 新型液冷机型是什么LIQUID_COOLING是一种液冷型储能机它在ESS_DEVICE_TYPE枚举里是一个独立的机型。和传统液冷一体机相比它有两个关键差异采样走 CAN通过CAN_Samplespower_device_unit/can_comm_main.c直接 CAN 采集而不是传统的Sample_ESS。控制走 CAN通过Set235kWPCS_WrokMode直接 CAN 下发而不是 TCP。8.2 我给 新 搭的时段计划判断环节在理解了「决策层」和「执行层」的分工之后我为 836 在Ems_Mgmt_Main_ESS里加了一个判断环节Ems_Mgmt_TimeSector_Plan_836位置放在Ems_Mgmt_Total_Pess_All模式已算好之后、Refresh_NodeParam_ESS映射给状态机之前。这个位置非常关键它是「模式已算好、还没映射给状态机」的中间点最适合做 836 专属的判断。目前它只是读emBatt_WorkModeReq并按充电/放电/待机三分支打印具体判断细节SOC 停止、功率限幅留了 TODO。要让它真正影响状态机需要在里面修改emBatt_WorkModeReq这样Refresh_NodeParam_ESS才会把修改后的模式映射下去。8.3 我的认知迭代做这个接入的过程中我的认知经历了三次迭代最初以为要给功率计算函数里加特殊分支仿照LIQUID_COOLING_BACKUP的柜内防过载。后来理解了无特殊点防逆流/防过载和液冷一体机一样所以不需要加特殊分支重点是确保时段计划 防逆流 防过载这套通用逻辑对他生效。最终搞清楚 CAN 下发链路已经完整关键在「上游决策」所以判断环节应该放在emBatt_WorkModeReq映射到calc_Node之前。这个迭代过程让我深刻体会到在大型嵌入式项目里理解「数据流」比理解「单个函数」更重要。只有搞清楚数据从哪里来、经过哪些转换、最后到哪里去才能找到正确的改动点。九、总结回顾这整条充放电控制链路我最大的收获是建立起了一个清晰的「四层模型」心智框架决策层EMS 管理计划GetCurrentTimeSector按时间定模式Ems_Mgmt_Total_Pess_All叠加防逆流/防过载定上限。控制层功率管理流水线12 个函数串成「决策 → PID → 滤波 → 节点映射 → 排序 → 分配 → 无功 → 恢复 → 输出」的完整流水线。执行层电池状态机6 个状态的表驱动状态机把决策安全落地成 PCS 指令。下发层物理通道传统 TCP / 836 CAN最终到达 PCS。而贯穿这四层的是两条关键的数据流模式流emBatt_WorkModeReq → calc_Node[n].emBatt_WorkMode → calcNodeData[n].emBatt_WorkMode经 221n,203 节点→ 状态机停充/停放判断。功率流fTotal_PessChgAvaliable → fACDC_Distri_4_BattChrg_Pwr → fGrpCurrLmt功率转电流→ byData/ctrlData经 200,232 节点→ PCS。搞清楚了这两条流整个系统的充放电控制就了然于胸了。作为嵌入式 Linux 工程师我在这个项目里体会最深的一点是储能 EMS 的本质是一个「目标导向的实时闭环控制」——先定目标时段计划 防逆流/防过载再闭环执行PID 功率分配 状态机最后精确落地电压/电流限值 → PCS。而支撑这一切的是清晰的数据流设计和层层解耦的模块划分。这套设计思路值得我在以后任何嵌入式控制项目里借鉴。