简介：IEC60870-5-104（IEC104）是电力自动化系统中主站与子站间实时通信的核心规约，广泛应用于微电网能量管理、变电站综合自动化等场景。它基于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 Map<Integer, 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 = 3000：3秒内拿不到连接直接抛错，快速失败比无限等待好。
- 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是非线程安全的，我用的是DateTimeFormatter（Java 8+），线程安全，可以放心用静态实例。
6. 这段开发经历带来的实用建议
整个项目从协议调研到稳定运行，花了大概两个月时间。如果让我重新做一遍，我会在几个地方做得更好：协议解析单元测试前置编写，用抓包工具录制的真实报文做回归测试数据，这样每次改动后跑一遍就知道有没有破坏原有解析逻辑；控制命令状态机设计得更严格一些，把各种异常分支（超时未确认、重复选择、执行中收到新指令）都考虑进去；数据库写入的监控指标也提前暴露出来，队列积压、入库延迟、批量失败数这些都应该有实时监控告警。
另外我觉得特别值得推荐的是，在调试阶段用WireShark抓包对比程序解析结果。WireShark自带IEC104协议解析器，能直接把ASDU里的内容翻译成可读格式。程序解析结果和WireShark解析结果逐个字段比对，问题马上现形。这个办法帮我定位了好几个隐蔽的字节序和位域解析问题。
最后，也是最实用的一条：IEC104设备的点表信息一定要做成可配置的，不要硬编码。现场设备的点位含义、量程系数、关联告警阈值经常要调整，如果能通过后台页面或者Excel导入的方式维护点表，后期运维工作量会小很多。这算是这次项目经验里最值钱的一条总结。
本文还有配套的精品资源，点击获取
