简介电力行业广泛使用的远动通信协议IEC104这套Java实现的主站客户端程序专为微电网管理系统设计面向需要掌握协议底层交互与工程代码的开发者。程序基于TCP/IP实现应答式数据传输覆盖遥信、遥测上行与遥控、遥调下行链路并整理了IEC104帧格式、APCI与ASDU结构以及U帧、S帧、I帧三种报文格式的说明。资源包共105个文件包含23个Java源码、30个class编译产物、9个jar依赖库及10个json配置文件另有22张png图辅助说明报文流程与工程结构整套源码压缩后仅3.59MB轻量易读。目前已有734人学习下载。通过工程可快速搭建主站原型理解ASDU数据处理、客户端会话管理、启动/停止/测试帧交互等核心机制同时源码中预留了数字化量、模拟量等数据访问接口适合作为微电网或配电自动化项目的参考实现与二次开发基础。 干微电网项目的朋友应该都有这种经历现场的光伏逆变器、储能PCS、柴发控制器、并网柜测控装置各家用的通信协议五花八门Modbus、Profinet、私有TCP轮着来。但只要设备想进区域集控或者微电网作为一个整体要接受电网调度IEC104就是绕不开的那个口子。我们这套microgrid项目的IEC104主站客户端程序正是在这个背景下做出来的它属于微电网管理系统的一部分以主站身份主动连接各个从站设备完成遥测、遥信、遥控、遥调以及总召唤、时钟同步这些标准交互。下面的内容就是我在开发这套程序过程中的完整复盘包括协议要点、模块设计、开发顺序和联调踩坑适合既要懂业务又要写代码的微电网工程师参考。1. 为什么微电网管理系统要自研IEC104主站客户端1.1 微电网场景里IEC104到底承担什么角色微电网这个概念落到工程上本质就是分布式光伏、储能电池、柴油发电机、可控负荷再加一个本地控制器或者能量管理系统EMS把小范围内的源、网、荷、储协调起来。内部设备之间倒是好办不少厂家自己的后台和采集器用Modbus就能撑起来但一旦涉及和外部系统打交道局面就完全不同了。这里的“外部系统”一般分两类一类是上级调度或区域集控中心它作为更上一层的控制端需要知道微电网整体的有功、无功、并网状态也要能下发功率指令另一类是微电网本地EMS需要去采集的终端设备比如关口电度表、并网柜测控装置、部分支持IEC104的PCS网关。无论哪一类IEC104都是国内电力自动化领域事实上的标准通信方式TCP端口2404主站作为客户端主动发起连接从站作为服务端监听等待。我们这套程序的角色就是前者——主站客户端。它运行在微电网管理系统侧去连接那些以从站方式工作的设备。项目里之所以要单独拉这么一个模块而不是让EMS主程序直接去写协议是为了把通信能力独立出来上层只需要关心点号和数值至于TCP重连、帧序号、心跳这些脏活累活全部收敛在IEC104主站客户端内部。1.2 为什么不用现成平台非要自己写很多人第一反应是市面上商业SCADA不是自带IEC104主站吗买一套不就完了这话对大型集控中心成立但放在微电网项目里往往行不通。首先是成本问题微电网项目体量小、利润薄一套商业SCADA的授权费可能比整个控制器的硬件成本还高。其次是集成问题微电网EMS里往往有策略控制、告警联动、负荷管理这些业务逻辑商业平台的协议栈和内部实时库封闭想做点深度定制非常费劲。更现实的场景是嵌入式部署。我们有一部分边缘终端用的是ARM平台比如瑞芯微RK3506这类小体型处理器资源有限、内核裁剪过商业平台根本塞不进去。自己写一个精简的IEC104主站客户端可以针对性地把用不到的功能裁掉编译出来就一个二进制文件部署和升级都省事。当然自研的前提是团队里有人真正吃透协议不是照着网上demo抄一遍能发数据就算完。2. 先把协议骨架啃下来APCI、ASDU与连接参数2.1 APCI帧格式I帧、S帧、U帧怎么区分IEC104的报文结构说白了就是APDU APCI ASDUAPCI负责传输控制ASDU负责承载数据和命令。抓包看第一个字节大概率都是0x68这是启动符第二个字节是APDU长度注意这个长度是从APCI控制域开始算的不包括0x68和长度字节本身。连接刚建立的时候主站和从站之间交互的不是业务数据而是U帧。U帧控制域只有两个字节负责建立和维持会话我把常用的动作和十六进制对照放在下面调试时一眼就能认出来功能激活报文确认报文STARTDT开始数据传输0x07 0x000x0B 0x00STOPDT停止数据传输0x13 0x000x23 0x00TESTFR测试帧/心跳0x43 0x000x83 0x00STARTDT是重连之后必须走的一道门双方握手成功之前从站不会上送任何业务数据。TESTFR就是应用层的心跳很多设备在网络上长时间没有报文时靠这个来判断链路还活不活着。真正的数据传输走I帧和S帧。I帧控制域四个字节里面携带发送序号N(S)和接收序号N(R)每次发送序号加2接收序号加2。S帧只有接收序号N(R)只用来应答不携带ASDU。这套序号机制的作用和TCP的SEQ/ACK很像I帧发出去要等对方应答序号对不上就说明中间丢了报文重传逻辑就得跟进。2.2 ASDU结构与几个绕不开的类型标识ASDU是业务数据的载体固定部分包括类型标识、可变结构限定词、传输原因、公共地址后面跟着一个或多个信息对象每个信息对象有信息对象地址IOA和数据体。类型标识决定了后面的数据怎么解析微电网项目里翻来覆去用到的其实就那几个类型标识名称方向用途1M_SP_NA_1 单点遥信从站→主站开关分合、设备状态13M_ME_NC_1 短浮点遥测从站→主站功率、电压、电流、频率30M_SP_TB_1 带时标遥信从站→主站SOE事件顺序记录45C_SC_NA_1 单点遥控主站→从站分闸、合闸命令50C_SE_NC_1 设值遥调主站→从站有功/无功功率目标值100C_IC_NA_1 总召唤主站→从站上电后全量数据采集103C_CS_NA_1 时钟同步主站→从站对时传输原因COT是两个字节最常见的几个值要烂熟于心6是激活7是激活确认8是激活终止20是总召唤响应3是突发主动上送1是周期上送。总召唤的完整流程是主站发COT6的召唤从站先回一个COT7的确认然后把所有当前值以COT20的报文发过来最后发一个COT8表示数据发完了。很多新手只等着收数据不看COT8就认为召唤没完成这是不对的。2.3 t0/t1/t2/t3和k、w这些参数的意义IEC104的参数看似简单但配置不当会在现场出各种诡异问题。t1是发送或测试帧的应答超时默认15秒t2是接收端的确认超时默认10秒要求必须小于t1t3是链路空闲时发送TESTFR的周期默认20秒。另外还有两个窗口参数k是未确认I帧的最大数量默认12w是收到多少帧后必须回一个S帧确认默认8。TCP层已经有一套可靠机制了协议栈还要在应用层再做一套原因就是电力自动化的通信链路要确保不丢数据而且TCP断链的感知太慢应用层心跳才是探测链路状态的主力。我习惯在配置里把这几个参数做成可调的因为不同厂家从站对超时的容忍度差别很大有的设备t3到了30秒就主动断开有的却能撑很久。3. 主站程序的模块划分以及通信状态机怎么设计3.1 连接管理与STARTDT流程主站客户端永远要主动去连从站所以第一步是把连接管理做成一个独立模块内部维护一个状态机DISCONNECTED、CONNECTING、STARTING、RUNNING、STOPPING。TCP建立成功后立刻进入STARTING状态发STARTDT激活等到对端确认后转RUNNING这时候才算真正开始业务交互。RUNNING状态下主站要周期性地检查链路健康度做法就是发TESTFR。收到确认说明从站的应用层还活着如果连续几次没有回应就应该主动断开TCP重连。有的设备从站实现得比较严格如果主站不发TESTFR它自己链路空闲超时后也会断开。所以心跳这个功能不是可选项而是必须项而且t3参数要和从站侧的配置对上。3.2 收发线程模型与数据缓冲IEC104既有周期性上送又有突发上送还有总召唤时的一大批历史数据报文到达速率并不均匀。我建议接收线程只负责从socket读字节流、按帧切包、解析APCI和ASDU然后把解析结果丢进一个无锁队列由业务处理线程去消费。千万不要在接收线程里做数据库写入或者告警判断否则某台从站突发几百个遥信变位时整个接收会被拖死。发送侧用一个带优先级的发送队列总召唤、遥控这类控制命令要高于周期数据。发送线程负责维护I帧的发送序号并处理重传和窗口滑动。协议栈的内部通信我最初用互斥锁包了一整套收发接口后来高并发下出现锁竞争导致心跳延迟干脆改成单生产者单消费者的环形缓冲逻辑简单了问题也没了。这类时序问题用静态分析看不出毛病必须压测才暴露得出来。3.3 点表设计IOA怎么映射到业务量IEC104报文里只有信息对象地址IOA没有我们业务上用的“PCS_A相有功功率”这种名字。点表就是把IOA翻译成业务量的唯一桥梁这一层设计不好后面每一步都痛苦。我们工程里的做法是维护一张离线表格每一行包含从站地址、类型标识、IOA、量测Tag名、缩放系数、单位、越限值程序启动时加载到内存收到报文后先查表再更新实时库。这里有一个坑不同从站的IOA编排习惯完全不同A厂可能把遥测从0x160400开始排B厂却把遥信用同一个IOA空间。所以点表必须按从站维度分开配置程序里解析时不能假设IOA全局唯一要统一用“从站地址IOA”作为key。点名规范化也值得提前定好我们用的是“设备ID_物理量_属性”这样的命名比如“PCS1_ACTIVE_POWER_MEAS”后期做告警联动和界面绑定都能省事。4. 功能开发的先后顺序怎么排才不返工4.1 第一步一定先把连接和心跳做扎实不要一上来就写总召唤、写遥控先把TCP连接、重连、STARTDT握手、TESTFR心跳、STOPDT退出这一套跑稳。这个阶段你手里只需要一个能打印原始报文的调试工具就能验证链路是否正常。连接和断线重连都稳了后面的业务功能才有地方挂。我在这一步习惯把整个状态机的日志打完整包括状态跳转、收发原始报文、定时器触发因为后续所有问题排查都依赖于这套日志。日志格式不用花哨时间戳、方向、帧类型、关键字段打出来就行但一定要落盘不能只在终端打印现场设备没人守着看屏幕。4.2 总召唤和时钟同步要成对做连接建立后第一个业务动作就是总召唤把从站当前所有遥测遥信全量拉一遍这个流程能同时验证点表配置、协议解析、COT处理是否正确。调试时我会准备一组已知的测试数据让从站返回比如把某个IOA对应的遥测值固定为50.25如果主站侧解析出来是50.25说明类型标识、字节序、缩放系数全对可以继续往下走。时钟同步命令紧随总召唤用C_CS_NA_1把主站时间发给从站。微电网系统里的SOE时序、功率曲线都依赖统一时钟不同步的话后续分析故障顺序时会非常痛苦。需要注意的是时钟同步命令发出后有的从站会回COT7的确认有的会直接执行不确认这两种行为都是合理的程序里都要兼容。4.3 遥测遥信的解析和质量位处理遥测、遥信打通后如果不考虑质量位那只能算完成了一半。IEC104每个遥测点都带一个质量描述字节里面包含IV无效、NT非当前值、SB被替代、BL被封锁这些标志位。现场经常出现某个遥测通道故障设备就把IV位置1如果程序不管三七二十一直接把这个值更新到实时库很可能会触发错误的功率闭环或者告警。质量位的处理策略应当和微电网控制策略挂钩用于显示的量测质量位置IV的可以标灰但不影响界面用于闭环控制的量测质量位置IV时必须走无效逻辑策略模块要能识别出来并冻结输出。这个设计要提前想好否则策略联调阶段会天天和通信组扯皮。4.4 遥控遥调的选择/执行机制遥控遥调是主站程序的最后一块拼图也是最需要谨慎对待的功能。标准流程是两步先发选择命令从站确认后再发执行命令从站执行完成后返回确认。程序内部必须实现完整的命令队列和超时管理选择命令发出后如果在规定时间内没收到确认要自动撤销这次操作绝不能卡住队列里的后续指令。安全逻辑也要在应用层兜底。我在命令处理模块里加了一个简单的互锁机制比如并网开关的合闸命令如果当前微电网的并网状态遥信不是“分位”程序直接拒绝下发。这些互锁不一定符合所有工程的需要但一定要设计成可配置的规则而不是写死在代码里。5. 联调阶段踩过的坑和对应解法5.1 序号窗口不同步导致的丢帧第一次和某厂PCS网关联调时数据上送总是莫名其妙中断日志显示从站不断重发同一组遥测。后来定位发现是序号管理的问题从站发送序号和主站接收序号之间出现了K12的窗口溢出主站没有及时回S帧确认从站认为报文没被收到就一直重发旧帧主站却以为收到了新数据。这个问题的根因是我早期的实现里S帧确认是攒够w8帧才统一发一次但处理线程偶发阻塞时接收缓冲里的帧数会越过窗口上限。解法是把S帧确认的触发条件改成“收到帧数达到w”和“收到I帧后超过t2时间没有可发送的I帧”两者任一满足就立即发送这样既能减少无效确认又能保证窗口不溢出。5.2 重连后必须重新走STARTDT有一次现场反馈从站重启后主站程序不自动恢复数据。日志里TCP明明已经重连成功了但就是收不到任何业务报文。原因是在重连处理里只重新发了一次总召唤没有先发STARTDT。IEC104规定TCP连接建立后数据传输是被禁止的必须通过STARTDT激活从站才会开始上送数据。协议栈虽然重连了但会话状态是“停止”的总召唤报文发过去也从站根本不会处理。修正后的重连流程是TCP连接成功 → 发STARTDT激活 → 等确认 → 发总召唤 → 时钟同步 → 恢复运行。这个顺序是铁律任何一步跳过都会出问题。5.3 遥控命令和总召唤的并发冲突项目后期加策略控制功能时发现策略下发功率指令偶尔会不生效。排查下来是这么回事主站在执行功率闭环时每个周期都可能发一次C_SE遥调如果这时候恰好又来了一次总召唤两条I帧在发送队列里背靠背发出去从站处理能力弱把总召唤的激活终止响应丢了主站等待COT8超时后把整条链路标记为异常后续的遥调命令全部被阻塞。解法是在发送模块里给不同类型的命令设置优先级和互斥规则总召唤发送期间不阻塞遥控遥调命令但命令超时时间要单独计算反过来遥控遥调期间的总召唤响应丢失不应该影响命令通道。最终我在业务处理里把这几种操作的超时和异常恢复策略分开管理才彻底解决。5.4 用自建模拟器替代来路不明的工具联调阶段最大问题是手里没有从站设备现场设备又不敢乱试。网上流传的那些所谓模拟器资源很多带捆绑和病毒隐患正规厂家协议的模拟器也未必支持自己设备的点表特征我劝你别折腾。整套开发过程中我直接用Python写了一个从站模拟器几百行代码监听2404端口按配置的规则响应总召唤、周期上送遥测、接受遥控命令还能主动触发遥信变位。测试完IEC104主站的各类功能这个模拟器还能用来模拟故障场景比如故意不回S帧确认、乱发序号、延时响应把主站程序的容错能力测了个遍。这个成本很低但收益远超预期强烈建议有条件的团队都维护一个这样的内部测试工具。6. 往RK3506这类嵌入式平台迁移时的调整6.1 资源约束下的工程取舍这套程序最初是在x86服务器上开发的依赖的是标准库和线程模型后来要部署到瑞芯微RK3506这类ARM平台时做了不少减法。首先是内存嵌入式平台堆内存有限帧解析和ASDU组包必须避免大块动态分配我们直接把收发缓冲改成固定大小的环形数组一条报文最长就255字节根本不需要临时拼大buffer。其次是线程数量原来为了解耦启动了五六个线程在嵌入式平台上精简成三个接收线程、发送线程、业务处理线程靠事件标志位协作。还有一个容易被忽视的点是字节对齐和大小端。ARM平台和x86默认大小端一致都是小端但如果代码里直接用结构体指针强转来解析报文很容易踩到编译器对齐的坑。我最终把所有帧解析都改成按字节流逐字段读取的写法虽然代码啰嗦一点但在任何平台上行为都一致排查问题也好定位。6.2 编译部署与运行保障的细节交叉编译时我建议把依赖库数量压到最低能不用第三方库就不用。IEC104主站客户端本质上只需要socket、线程、定时器这三样能力POSIX接口在嵌入式Linux上都能直接支持没必要为了省事引入重量级框架。点表配置从启动参数改成外部配置文件加载这样现场改点表不用重新编译发布。运行保障上两个东西必须有一个看门狗一个状态上报。看门狗既用硬件看门狗也要用软件看门狗主站程序要是卡死在某个等待里系统能自动重启并把链路恢复起来。状态上报是把本程序和从站之间的链路状态、最近一次通信时间、数据完整率这些信息定期汇报给EMS主程序这样上层监控才能发现通信异常而不是等值班人员看到数据不动了才来问。最后分享一个经验IEC104主站客户端这种通信基础模块最怕的不是协议复杂而是现场情况多样。每接一个从站协议行为都可能有一点差异所以在设计初期就把日志、参数配置、容错策略做成开放可扩展的远比追求一次写成“完美协议栈”更实际。我们后续计划在程序里加入断点续传和数据缓存功能把断链期间的历史数据补传能力补上这对微电网的功率分析相当有用。本文还有配套的精品资源点击获取