简介IEC60870-5-104IEC104是电力自动化系统中主站与子站间实时通信的核心规约广泛应用于微电网能量管理、变电站综合自动化等场景。它基于TCP/IP传输通过APDU封装遥信、遥测、遥控、遥调数据解决了多设备异构协议的互联互通问题。在实际工程中实现一个稳定高效的IEC104主站客户端不仅需要深入理解报文结构与状态机还需妥善处理多线程Socket通信的粘包拆包、心跳保活与断线重连以及高并发场景下的数据库写入优化。本文结合Java技术栈的实战经验分享协议解析、线程模型、批量入库等关键技术并总结现场调试中的典型踩坑案例为电力监控系统开发者提供可借鉴的工程实践参考。 做电力自动化方向的开发绕不开IEC104这个协议。我这两年一直在做微电网管理系统的上位机部分核心就是把分散在光伏逆变器、储能变流器、并网柜、环境监测仪上的数据统一采回来再根据调度策略往下发遥控遥调命令。这套基于Java实现的主站客户端最核心的工作就是完整实现了IEC104协议栈的通信交互同时配合多线程Socket通信和高并发数据库操作把数据采集、实时解析、命令下发和持久化存储串成了一条流畅的生产链路。如果你也在做电力监控系统、微电网能量管理、变电站综合自动化这类项目或者正准备入门电力通信协议开发这篇文章里关于协议解析、线程模型、数据库写优化和各种实测踩坑的内容应该能帮你少走不少弯路。1. 项目整体架构与设计思路1.1 微电网监控系统为什么需要IEC104微电网和传统大电网有个明显的区别设备种类杂、通信方式杂、数据点多而且刷新速度快。一个典型的园区微电网可能同时有十几台光伏逆变器、两三套储能PCS、并离网切换柜、柴油发电机、环境监测仪这些设备来自不同厂家支持的协议千奇百怪Modbus、104、61850都有可能。如果每接一种设备就写一套定制协议后期维护就是灾难。IEC104是这个场景下最合适的一个通用语言。它是IEC 60870-5-104标准的简称本质上是把IEC 101的报文封装到TCP/IP网络里传输专门用于电力系统的主站和子站RTU、测控装置之间的实时通信。绝大部分电力自动化设备都会预留104接口尤其是电网侧和微电网侧的新设备基本都支持。这套主站客户端就是站在主站角度去主动连接各个子站设备周期采集遥信遥测数据实时处理设备的变位、越限告警同时向上层调度系统提供遥控遥调的指令通道。相比那些动辄几十万的商业化SCADA平台自己写一套主站客户端的最大优势是轻量、可控、可以根据现场需求快速定制而且源码在手出问题能定位到底层。1.2 主站客户端程序的核心模块划分整个程序从功能上我分成四大块各模块职责边界非常清晰通信层负责TCP连接的建立、维护和断开包括多线程Socket通信、粘包拆包处理、心跳保活、断线重连逻辑。这是所有数据流动的物理通道。协议层负责IEC104报文的编解码包括APCI报头处理、ASDU解析、遥信遥测报文重组、遥控遥调命令的组帧和发送确认。业务层负责数据缓存、实时告警判断、控制逻辑校验、下发命令的时序管理。业务层把协议层的数据转成业务对象上层界面或调度引擎直接用这些对象。持久层负责将采集数据写入数据库包括实时数据缓存、历史数据分批入库、告警记录存储、操作记录存档。之所以这样分是因为每一层的变更频率完全不同。协议层可能因为对接新设备需要调整解析逻辑持久层可能因为数据量增长要换存储方案通信层要适配不同网络环境调整超时参数。如果揉在一起改牵一发动全身。我在实际开发中深刻体会到这种分层结构虽然前期设计时多花点时间但后期调试和扩展时节省的时间是翻倍的。2. IEC104协议核心机制与Java实现要点2.1 先把报文结构彻底啃透IEC104协议说起来复杂但真正写代码时只需要盯住一个核心APDU。所有的交互数据都封装在APDU应用协议数据单元里它由APCI应用协议控制信息和ASDU应用服务数据单元两部分组成结构可以简单理解成信封加信纸的关系。APCI部分占用6个字节固定以0x68开头第2个字节是APDU长度后面4个字节是控制域。控制域分三种类型I帧编号的信息帧用于传输数据、S帧编号的监视帧用于确认、U帧未编号的控制帧用于启停和测试。其中U帧的三个功能必须优先支持STARTDT激活0x07、STOPDT停止0x13、TESTFR测试帧0x43。ASDU部分才是真正的数据内容核心字段包括类型标识一个字节决定了后面数据的含义。比如0x01是单点遥信0x03是双点遥信0x09是归一化遥测0x2D是带时标的单点遥信0x64是总召唤命令。可变结构限定词VSQ一个字节最高位表示是否连续寻址低7位表示本条报文中信息体的个数。传送原因COT两个字节比如0x06表示激活0x07表示激活确认0x08表示停止激活0x14表示响应总召唤0x03表示突发。公共地址两个字节用于区分不同子站设备一般每个站分配一个地址。信息体信息体地址一般3个字节 信息体数据。遥信是1个字节的开关状态遥测是归一代数值或短浮点。当时我刚上手时踩了个坑以为只要拿到ASDU就能直接解析数据忽略了APCI的控制域编号校验。结果在弱网环境下重发的I帧导致数据重复入库一条遥测被记了两遍。后来老老实实把I帧收发序号N(S)和N(R)的校验逻辑加上才算真正把这个问题根治。2.2 遥信遥测的解析流程怎么设计最稳妥遥信状态量和遥测模拟量的解析是整个主站客户端最基础也是最频繁的操作。以遥测为例一个正常的周期采集流程是这样的主站启动后先发总召唤命令类型标识0x64子站收到后把全部遥信遥测上送一遍之后子站按设定周期主动上送变化数据。我实现的解析流程大概分五步循环读取Socket输入流的字节拼装成完整的APDU帧。校验APCI固定帧头0x68、长度字段、控制域类型。解析ASDU公共部分类型标识、VSQ、传送原因、公共地址。根据类型标识分派走遥信解析器、遥测解析器还是其他类型处理器。信息体逐个拆解按VSQ里的个数循环读取换算成实际工程值。这里有个关键算法遥测工程值的换算。IEC104的归一化遥测传输的是-1到1之间的标幺值实际工程量 原始值 × 系数 偏移量。这个系数和偏移量需要从子站的点表里配置通常存在数据库配置表里程序解析时根据信息体地址去查系数。比如逆变器有功功率的量程是-100kW到100kW系数就按量程除以32767来算。我在解析器里用了策略模式用一个Map把类型标识映射到对应的解析器对象private static final MapInteger, DataParser PARSER_MAP new HashMap(); static { PARSER_MAP.put(0x01, new SinglePointParser()); // 单点遥信 PARSER_MAP.put(0x03, new DoublePointParser()); // 双点遥信 PARSER_MAP.put(0x09, new NormalizedMeasureParser()); // 归一化遥测 PARSER_MAP.put(0x0B, new ScaledMeasureParser()); // 标度化遥测 PARSER_MAP.put(0x0D, new ShortFloatParser()); // 短浮点遥测 }这样做的好处是遇到新设备用的类型标识不同只需要新增一个Parser类注册进去不动原有逻辑。后期扩展很顺手。2.3 遥控遥调命令下发的完整闭环遥控开关型控制和遥调设定型调节是主站向子站下发指令的功能。遥调和遥控的帧结构不同但都需要走选择-执行-确认的闭环流程。比如控制一个断路器分闸完整流程是主站发选择命令类型标识0x2E遥控选择先让子站准备好不实际动作。子站回选择确认传送原因0x07。主站发执行命令类型标识0x2E遥控执行子站收到后真正动作。子站回执行确认传送原因0x07同时上送一个新的遥信状态变位报文。有些设备支持直接执行不带选择步骤但正规站点的二次防护要求里都会要求走选择执行流程防止误操作。我在程序里单独写了一个CommandDispatcher维护每个控制点位的状态机只有状态流转正确才允许下一步配合操作日志记录方便事故追溯。遥调命令相对简单一些直接下发设定值。但要注意注入参数的格式比如短浮点类型的遥调值4个字节的字节序是低字节在前换算成十六进制字符串发送。我当时调试储能PCS有功功率遥调时发现下发100kW设备收到的是负数后来一查是字节序反了把低字节序的规范理解反了实际交换高低位后一切正常。3. 多线程Socket通信架构设计与实战3.1 线程模型设计从单线程到线程池的演进IEC104主站通常会同时连接多个子站每个子站一台设备甚至一个子站有多条链路。一开始我用的是最简单的一个连接一个线程模型主线程accept每来一个连接就new一个线程去处理。当时测试环境接两个设备没问题但项目上线前压测时发现设备数超过10个以后线程数暴涨每个线程都阻塞在Socket读上CPU上下文切换频繁程序性能急剧下降。后来重构为线程池模型所有子站的连接管理由单独的管理器负责每个连接的数据读取用独立的读线程但共享一个业务处理线程池。读线程只负责字节流接收和帧拼装拼装成完整APDU后丢给业务线程池去解析入库。这样IO线程和业务线程解耦IO线程的阻塞不会拖慢数据处理。整个程序的线程分布大概是这样的1个主线程维护连接管理器监听新连接和断线重连扫描。N个读线程每个子站连接对应一个负责读Socket数据、拆包、拼帧。1个心跳线程定时向所有子站发送TESTFR测试帧同时检查连接超时。1个数据库写线程通过BlockingQueue接收业务线程解析好的数据批量入库。1个命令下发线程处理来自上层界面的遥控遥调指令保证指令串行执行。3.2 Socket粘包拆包处理只要用TCP传输协议数据就绕不开粘包拆包问题。刚开始测试时数据量小没注意后来数据量大了之后经常出现解析异常一帧报文里混了两个APDU的数据。原因很典型TCP是流式协议底层会把多个Application包合并发送或者一个包被拆成多个TCP段。IEC104的APDU有个天然优势每帧都有固定的帧头0x68和第2字节的长度字段拆包比很多自定义协议简单。我的拆包逻辑写在读线程的ByteBuffer里private ByteBuffer buffer ByteBuffer.allocate(65536); public void handle(byte[] data) { buffer.put(data); buffer.flip(); while (buffer.remaining() 0) { // 查找帧头0x68 if (buffer.get(buffer.position()) ! (byte) 0x68) { buffer.get(); // 跳过无效字节 continue; } // 第二个字节是APDU长度 if (buffer.remaining() 2) break; int len buffer.get(buffer.position() 1) 0xFF; int totalLen len 2; // 帧头 长度字节占2字节 if (buffer.remaining() totalLen) break; // 等待剩余数据到达 byte[] frame new byte[totalLen]; buffer.get(frame); // 完整APDU交给协议层 onApdu(frame); } buffer.compact(); }这套逻辑的关键是长度不够就等数据多就继续拆用position和remaining判断是否凑够一帧不凑够就break等下一批Socket数据到达后继续处理。3.3 心跳保活与断线重连电力设备的通信信道不可控因素多网线松动、交换机死机、子站重启任何一个环节出问题都会导致链路断开。如果程序没有心跳机制主站根本不知道链路断了还在傻等数据这就是事故隐患。我实现的方案是三层保障应用层心跳心跳线程每隔5秒可配置向子站发送TESTFR帧子站收到后回TESTFR确认。如果连续3次没有收到确认判定连接断开。TCP层KeepAlive在Socket上开启TCP保活参数虽然默认周期较长但作为兜底也加上。断线重连连接断开后按1秒、2秒、4秒、8秒的指数退避策略重连最大间隔30秒重连成功后重新执行STARTDT激活和总召唤保证数据连续性。这里有个细节容易被忽略重连成功之后子站不会主动把全量数据重新上送必须主站重新发一次总召唤命令否则只有变化数据上送会有数据空洞。所以我的重连逻辑里在STARTDT激活确认后会紧接着发一次总召唤请求。4. 高并发数据库操作的优化4.1 数据采集写入的瓶颈到底在哪微电网系统的数据量看似不大但精细化监控下很可观。假设一个站点有2000个遥测点、3000个遥信点遥测5秒刷新一次遥信变位随时上报高峰期每秒大约有几百条甚至上千条数据要入库。如果每条数据都走一次JDBC insert数据库连接创建销毁的开销、SQL解析的开销加起来程序很快就会被数据库拖垮。我实测过不做任何优化的情况下单条insert的TPS大约只有几百远跟不上采集速度。瓶颈主要在三处连接频繁开关、单条提交的事务开销、以及索引维护的代价。4.2 批量提交与连接池配置解决思路是三个字批量化。我在数据库写线程里维护了一个批量缓冲队列业务线程解析完数据后不直接写库而是放到队列里写线程每攒够一定数量比如500条或者达到固定时间窗口比如2秒统一生成一条批量insert SQL一次提交。StringBuilder sb new StringBuilder(); sb.append(INSERT INTO ts_measurement (point_id, value, ts) VALUES ); for (Measurement m : batch) { sb.append(() .append(m.getPointId()).append(,) .append(m.getValue()).append(,) .append(m.getTs()).append(),); } sb.deleteCharAt(sb.length() - 1); sb.append( ON DUPLICATE KEY UPDATE value VALUES(value));这样单次批量insert的TPS能提升几十倍实测2000条一批插入MySQL耗时大约在100毫秒左右。连接池用的是HikariCP核心参数我调成这样maximumPoolSize 10并发不高10个连接足够连接太多反而浪费资源。minimumIdle 2保底2个空闲连接防止突发流量时建连等待。connectionTimeout 30003秒内拿不到连接直接抛错快速失败比无限等待好。maxLifetime 1800000避免数据库端主动断开后连接池还持有失效连接。4.3 历史数据归档策略实时数据表如果无限增长查询性能会越来越差。且不说索引膨胀单是表扫描就让人头疼。我采用按天分区表每天一张历史表或者用MySQL的RANGE分区按天分。数据保留策略是实时表只保留最近7天数据历史表按季度归档超过一年的数据迁移到冷存储。写入分流也更合理实时数据先写内存缓存同时以较粗粒度比如每分钟平均值写历史表细粒度原始数据写入专门的高频流水表定期清理。这样既能满足实时监控的秒级刷新需求又不至于把数据库撑爆。还有个细节是时间字段的索引。IEC104报文里带时标应以设备时标为数据时间不要用数据库当前时间否则断网重连期间的延迟上报数据会导致时序错乱查询曲线时出现跳变。5. 实战中的典型坑与排查实录5.1 信息体地址的字节序问题IEC104明文规定信息体地址是3个字节低字节在前。但有次对接一个国产厂家的微网控制器报上来的遥测数据信息体地址明显是反的导致所有数据都串位了。排查半天最后抓包对比才发现是设备实现了高字节序。这个问题没有好的自动判断办法我在配置表里给每个子站增加了一个字节序字段允许按站配置。虽然不符合规范但现场设备不按规范来也得能兼容软件做灵活一点更省事。5.2 遥信变位丢失导致告警漏报某次升级后现场反馈断路器跳闸的软告警没有推送到监控大屏。查日志发现子站上送的遥信变位报文偶尔会被丢弃。原因是读线程拆帧时发现了无效字节直接跳过但跳过的逻辑有bug把下一个合法帧的帧头也跳过了。修复方法是每次丢弃字节不能超过1个同时增加状态检查如果在寻找帧头阶段连续跳过多个字节仍然没有找到0x68就要考虑是不是链路异常发送主动复位请求而不是无限跳下去。5.3 线程池饱和与内存溢出高并发场景下如果数据处理速度跟不上接收速度业务线程池的队列就会积压。有次我测试时没注意BlockingQueue无界队列无限增长直接OOM了。后来我把线程池的队列改成有界队列比如容量10000并设置了拒绝策略为CallerRunsPolicy当队列满了新任务由主线程直接执行相当于天然背压。这样虽然主线程会阻塞但至少不会内存溢出而且可以通过监控队列长度来判断是否需要扩容。5.4 数据库连接泄漏排查过一个诡异问题程序运行一天后数据库连接数暴涨最后数据库拒绝连接。查了半天是代码里有个分支在业务异常时提前return了没有执行finally块里的connection.close。这就是典型的连接泄漏。我总结的经验是所有数据库操作统一封装在工具类里要么try-with-resources自动关闭要么用finally确保释放绝对禁止在业务代码里手动管理连接。连接池的泄漏检测也开着HikariCP的leakDetectionThreshold一旦发现泄漏日志里会直接打印堆栈定位很快。另外还有一个常见问题多线程环境下SimpleDateFormat是非线程安全的我用的是DateTimeFormatterJava 8线程安全可以放心用静态实例。6. 这段开发经历带来的实用建议整个项目从协议调研到稳定运行花了大概两个月时间。如果让我重新做一遍我会在几个地方做得更好协议解析单元测试前置编写用抓包工具录制的真实报文做回归测试数据这样每次改动后跑一遍就知道有没有破坏原有解析逻辑控制命令状态机设计得更严格一些把各种异常分支超时未确认、重复选择、执行中收到新指令都考虑进去数据库写入的监控指标也提前暴露出来队列积压、入库延迟、批量失败数这些都应该有实时监控告警。另外我觉得特别值得推荐的是在调试阶段用WireShark抓包对比程序解析结果。WireShark自带IEC104协议解析器能直接把ASDU里的内容翻译成可读格式。程序解析结果和WireShark解析结果逐个字段比对问题马上现形。这个办法帮我定位了好几个隐蔽的字节序和位域解析问题。最后也是最实用的一条IEC104设备的点表信息一定要做成可配置的不要硬编码。现场设备的点位含义、量程系数、关联告警阈值经常要调整如果能通过后台页面或者Excel导入的方式维护点表后期运维工作量会小很多。这算是这次项目经验里最值钱的一条总结。本文还有配套的精品资源点击获取