简介基于IEC104协议的微电网管理系统主站客户端程序专为电力系统自动化与智能电网场景设计面向从事远程监控、数据采集与调度控制的开发及运维人员。程序基于Java语言实现完整覆盖遥信遥测解析、遥控遥调命令下发、多线程Socket通信与高并发数据库操作等核心功能可作为微电网主站系统的参考实现或二次开发基础。压缩包共107个文件约3.62MB包含23个Java源码、30个class编译文件、9个jar依赖包以及properties、xml、json等配置资源另有png示意图辅助理解界面docx/md文档提供配置与使用说明目录结构清晰。已有143人浏览学习适合需要理解IEC104协议落地或搭建轻量化监控客户端的读者。通过阅读源码与工程配置可掌握电力规约解析、多线程数据采集及高并发读写等关键实现思路附带的说明文件也为部署调试提供了指引。1. IEC104主站客户端先卸下“协议难啃”的预期再谈并发和数据调度台上遥信在闪、曲线在跳值班员看似平静地盯着一块大屏——而大屏背后那个实时刷新的监控画面正是微电网管理系统主站的核心一个基于IEC104协议的主站客户端程序负责把远处逆变器、储能PCS、配电柜的电压电流拉回来入库再把遥控遥调命令送下去。很多人一听IEC104就觉得是嵌入式的活、C语言的活实际用Java实现主站侧客户端才是工程上最常见也最舒服的一条路上手快、生态全、并发工具现成。这篇文章沿着“协议帧→Socket多线程→报文解析→命令下发”的链路把关键步骤、参数取舍和现场踩过的坑一次讲透适合想从普通Java开发转向电力监控、SCADA或物联网采集方向的工程师照着落地。2. 读懂IEC104帧结构再写代码从68起始字节到启动时序IEC104本质上是IEC 60870-5-104把工控规约跑在TCP的2404端口上。它比Modbus TCP复杂的地方在于它不是一问一答的简单请求响应而是带序号、带确认、有状态机约束的完整链路规约。连接建立后要激活链路、要总召唤、要周期心跳每一条U帧、S帧、I帧都有严格的时序要求。先把帧结构看懂后面解析、下发、故障排查就都顺了。2.1 把一帧报文拆到纸面上APCI、ASDU 与类型标识的读法IEC104一发完整的数据帧可以切成两部分前6个字节是APCI应用规约控制信息之后的字节是ASDU应用服务数据单元。APCI第1字节固定是0x68第2字节表示后面还有多少个字节第3到第6字节是控制域。控制域决定这帧是I帧带序号的数据帧、S帧确认帧还是U帧控制帧。ASDU内部按顺序排第1字节是类型标识第2字节是可变结构限定词第3、4字节是传送原因第5、6字节是公共地址之后才是信息体。信息体里最常用的是带品质描述符的测量值比如短浮点遥测的类型标识是0x0D单点遥信的标记是0x01总召唤是0x64。看一帧16进制报文时按这个顺序逐字节啃比任何工具都可靠位置内容含义字节10x68固定起始字节字节20x0AAPDU长度不含前两个字节字节3-6控制域I/S/U帧类型、发送/接收序号字节70x0D类型标识短浮点遥测字节80x01可变结构限定词SQ0即单信息体字节9-100x06 0x00传送原因激活字节11-120x01 0x00公共地址字节13信息体地址点位地址现场测点号一个小经验解析IEC104包时不要去数“第几个字段叫什么”而是直接用一个带游标的ByteBuffer边读边移动位置。这样遇到长度未知的信息体也好处理——先读类型标识再根据类型决定信息体结构然后从缓冲区里切对应长度。2.2 U帧不过关后面全是黑匣子STARTDT、总召唤、时钟同步与 TESTFR 心跳TCP一连上就能发总召唤吗不行。IEC104要求主站先发U帧STARTDT act0x68 0x04 0x07 0x00 0x00 0x00激活链路从站回STARTDT con0x68 0x04 0x0B 0x00 0x00 0x00后才允许发I帧。之后主站发总召唤类型标识0x64从站以总召唤结束帧收尾主站才算进入数据同步状态。这个时序很多新手会忽略结果是从站一直不回遥测抓包看报文一片寂静。心跳也靠U帧的TESTFR act实现主站定时发测试帧从站回TESTFR con。如果超过一定时间没收到确认主站应该主动断开重连。心跳周期我习惯设为10到30秒具体和现场通道质量有关光纤通道可以30秒GPRS或无线公网最好5到10秒。启动时序总结下来是这样TCP连接建立端口2404。主站发STARTDT act等待STARTDT con。收到确认后发总召唤等待遥测遥信上送和召唤结束帧。进入正常运行状态定时发TESTFR心跳。每24小时或现场需要时重新总召唤一次用来校准运行数据和处理漏帧。也就是说IEC104主站客户端不是“拨通电话就能说话”它更像两个电台之间的约定握手——少一步都可能让对方拒绝通信。调试阶段我一般先把这几个U帧的状态打日志确认握手通了再去看遥测数据。2.3 状态机别拍脑袋写STOPPED 到 SYNCED 的跳转条件主站侧通信状态至少要分三个未激活STOPPED、链路激活ACTIVE、数据同步SYNCED。每个状态下允许做的事不一样收到帧后也要先判断状态再处理不然容易出现“乱拳打死老师傅”式解析。Java里我习惯用一个简单的枚举维护public enum LinkState { STOPPED, // 未激活TCP已连接但链路未启动 ACTIVE, // 已激活收到STARTDT确认可以发总召唤 SYNCED // 已同步总召唤完成遥测数据正常上送 }收到每一帧时的处理规则很简单只有ACTIVE以上才能发I帧只有SYNCED才把遥测往数据库写如果链路从SYNCED跌回STOPPED要清空发送/接收序号重新握手。这个状态机不复杂但一定要独立放在一个类里别跟报文解析混在一个方法里写否则后面每加一个功能都在这个类上打补丁迟早翻车。3. Java多线程Socket通信连接、队列与批量写库的配合方式IEC104主站的通信压力通常不来自单帧处理而来自持续的批量数据。一个微网站点几百个遥测点每个点每秒或每几秒上送一次再加上遥信变位冲击几路连接叠加后如果收发、解析、入库全挤在一个线程里程序很快会因为数据库I/O阻塞而丢包。这里要做的不是“优化单线程代码”而是把职责拆到不同线程各干各的。3.1 单连接还是多连接主站侧线程模型怎么分活常见的做法是一台从站子站建一条TCP连接主站侧一个连接分配一个接收线程。接收线程只负责从Socket里把完整的APDU读出来放进一个待处理队列就结束绝不在接收线程里做数据库写入。队列另一头由业务线程池消费做ASDU解析、业务逻辑、入库操作。这样读写两边互相独立即使数据库抖动也不会立刻拖垮网络接收。连接和子站的对应关系要提前规划好如果现场有多个从站每条连接单独监听一个端口或目标地址。我在实现时会把连接对象封装成一个Session里面持有Socket、接收线程、链路状态、发送序号等避免多连接共享可变状态时互相打架。线程划分边界具体是这样的接收线程一个连接一个只做Socket读取和APDU拆包。业务线程池解析ASDU、处理遥信遥测、执行遥控逻辑。写库线程池消费批量数据做批量插入或更新。调度线程池心跳、总召唤、重连、数据补召。留意一个原则不要在线程里共享可变字段而不加锁。更简单的做法是让线程间只通过队列传不可变对象状态各自独立这样锁的问题基本消失。3.2 有界阻塞队列生产者消费者模式在这里的落地接收线程是生产者业务线程是消费者。这个模式在Java里直接用BlockingQueue实现最省心。唯一要注意的是队列必须设上限否则从站忽然大批量上送历史数据时业务线程消化不过来队列无限膨胀JVM直接OOM。BlockingQueuebyte[] frameQueue new LinkedBlockingQueue(20000); // 接收线程读到完整APDU后入队 while (running) { byte[] apdu readApduFromSocket(socket); if (apdu ! null) { if (!frameQueue.offer(apdu)) { // 队列满说明消费能力不足记日志丢弃最旧或丢弃当前 log.warn(frame queue is full, drop one frame, size{}, frameQueue.size()); } } } // 业务线程消费并处理 while (running) { byte[] apdu frameQueue.poll(500, TimeUnit.MILLISECONDS); if (apdu ! null) { dispatch(apdu); } }这里用的是offer而不是put因为put在队列满时会一直阻塞接收线程被卡住后Socket读缓冲也堵住可能引起对端重传风暴。用offer加丢弃策略最多丢一帧数据但保住了链路的存活。丢弃后靠周期总召唤或数据补召机制还能把缺的数据找回来这是IEC104体系比普通TCP裸传更稳的地方。队列容量按什么定我一般按“单帧平均耗时 × 每秒帧数 × 容忍秒数”来估算。比如一帧平均处理5毫秒每秒进帧500个容忍积压40秒容量就是20000。压测时把容量设小一倍看日志有没有丢弃用来反推消费瓶颈。3.3 批量插入与连接池配置入库吞吐量的实测依据遥测数据每秒几十条上百条如果用一条SQL插一条数据库连接会频繁获取释放事务开销也大。常见做法是攒批攒到一定条数或一定时间再统一提交。用MyBatis时开批量执行器或者用JDBC的addBatch效果都比循环单插高一到两个数量级。// 攒批每500条或每300毫秒提交一次 int batchSize 0; ListTelemetryRecord buffer new ArrayList(1024); for (TelemetryRecord r : recordQueue.takeAll()) { buffer.add(r); batchSize; if (batchSize 500) { flushBatch(buffer); // 批量写入 buffer.clear(); batchSize 0; } }实际项目里我有一个更稳的做法批量写入放到单独线程用数组列表当缓冲避免每来一条就触发一次同步。数据库连接池参数也不能拍脑袋HikariCP下我常用maximumPoolSize给到CPU核心数加一minimumIdle保持2到4connectionTimeout设5秒。连接数不是越多越好批量插入的场景下太多连接反而容易把数据库锁资源打满。一个现场容易忽略的参数是rewriteBatchedStatementsMySQL连接串里加上它才能让批量insert真正合并成一条多值SQL不加的话JDBC驱动默认逐条提交批量等于白做。PostgreSQL和国产数据库各有对应开关先查驱动文档再上线。3.4 心跳线程与断开重连用 ScheduledExecutorService 还是 Timer心跳和重连不适合用Timer因为Timer是单线程一个任务卡住会影响后续所有定时任务。ScheduledExecutorService每个任务独立线程更可靠。而且心跳要用scheduleWithFixedDelay而不是scheduleAtFixedRate前者是“本次任务结束后再等固定时间”后者是“按固定周期硬调度”。网络抖动时scheduleAtFixedRate容易堆积任务心跳发得越来越密把通道打满。ScheduledExecutorService scheduler Executors.newScheduledThreadPool(2); // 每10秒发一次TESTFR若连续3次无确认则触发重连 scheduler.scheduleWithFixedDelay(() - { if (linkState LinkState.SYNCED) { sendTestFrame(); if (lostTestCount 3) { reconnect(); } } }, 10, 10, TimeUnit.SECONDS);重连要做退避不然通道不稳定时主站会像“打地鼠”一样疯狂建连断开。我用的是1秒、2秒、4秒的指数退避最大30秒成功连接后立即复位。还有一个坑是重连后必须重新走STARTDT和总召唤流程不能只把Socket接上就以为通信恢复了否则从站侧还停留在旧链路上数据完全不来。4. 遥信遥测解析与遥控遥调下发从字节到业务动作帧结构懂了、线程模型架好了剩下的核心就是把ASDU里的信息体翻译成业务数据以及把业务指令封装成命令帧发下去。这一层的细节最多品质描述符决定数据能不能用遥信的变位防抖决定误报率遥控的选择执行流程决定安全性。4.1 遥测品质描述符哪些数据能入库、哪些必须标记每个遥测信息体除了值还带一个字节的品质描述符QDS这是IEC104和普通Modbus最大的区别之一。QDS的低4位各有含义位标志含义bit0IV无效值数值不可信bit1NT非当前值可能是缓存或未刷新bit2SB被替代来自人工置入或替补源bit3BL被闭锁测点被封锁bit4OV溢出解析时不能只看值还要按位判断品质。无效或溢出的数据进库前要打上标记否则事故分析时看到一条电压零值值班员会误判成真正的失压事故。public static boolean isInvalid(byte qds) { return (qds 0x01) ! 0; // IV位 } public static boolean isOverflow(byte qds) { return (qds 0x10) ! 0; // OV位 }现场最坑的情况是某个测点接线松动从站上送的数值跳来跳去但品质标志一直是有效。这说明从站侧的采集模块没有正确设置QDS。主站能做的就是把历史品质信息也一并入库方便事后追溯是主站问题还是现场采集问题。我一般会在遥测表里加一个quality字段每一条都记录原始QDS字节而不是只存个干净数值。4.2 遥信防抖与变位风暴别让一次抖动铺满整张报警表微电网的遥信变位是最容易让主站“报警刷屏”的数据。光伏逆变器启停、并网开关分合、保护动作信号任何一个触点抖动从站都会按变位上送。主站如果不做防抖处理一次真实的分闸伴随几次反弹抖动数据库里会出现同一开关的连续翻转记录。防抖做法有两种按时间窗过滤和按连续确认过滤。我常用的是时间窗也就是收到一个变位事件后短时间内相同点位的重复变位直接忽略或延迟到窗口结束后再判断。窗口长度现场调一般是300到800毫秒特殊抖动严重的点位设到1秒。// 按点位缓存上一次变位时间500毫秒内的重复变位不处理 long now System.currentTimeMillis(); Long last lastChangeTime.get(pointAddr); if (last ! null now - last 500) { return; // 判定为抖动 } lastChangeTime.put(pointAddr, now); processChangeEvent(pointAddr, value);如果现场有大量点位同时变位比如整段母线失压几百个遥信几分钟内陆续上送主站的报警队列会瞬间积压。这时数据库写入要走批量报警处理要异步化不能把每个变位事件都同步推给业务系统。先记流水再异步判断告警条件是这类系统的常规解法。4.3 遥控四步走选择、执行、超时、回读一致性遥控命令下发不是把命令帧发出去就完事。IEC104支持带选择执行的控制流程先发一条带S/E位选择标志的遥控命令从站校验选中对象并把命令返回到“待执行”状态主站收到选择确认后再发一条执行命令从站执行完回确认。整个过程还要带超时和一致性校验。// 发送单点遥控选择命令类型标识0x2DS/E1表示选择 byte[] selectCmd buildC_SC_NA( commonAddr, pointAddr, value, ControlFlag.SELECT, seqNo.getAndIncrement()); sendFrame(selectCmd); // 等待选择确认确认帧的传送原因应为“激活确认”(7) // 收到后再发执行命令S/E0表示执行 byte[] executeCmd buildC_SC_NA( commonAddr, pointAddr, value, ControlFlag.EXECUTE, seqNo.getAndIncrement()); sendFrame(executeCmd);这里最关键的参数是序号控制域的发送序号。IEC104的I帧序号必须严格递增并循环使用从站收到序号不连续的命令帧会直接丢弃主站侧表现为“发出去的命令石沉大海没有确认也没有执行”。我排这类问题时第一步不是抓包看命令内容而是先看本端发送序号是不是跳了十次里有八次是并发下发时序号没加锁导致。遥调设点命令的逻辑类似只是信息体是数值加品质描述符。微电网里常见的遥调是储能有功功率设定、PCS无功功率设定。下发前一定要带上下限检查和命令超时回收避免操作员在界面上输入一个超限值直接穿透到现场设备。5. 踩坑清单粘包、写库死锁与数据乱序的排障记录这一章的每一条都是真金白银换来的。协议解析和线程架构看文档能学会但运行现场的坑往往在文档之外。以下五条按“现象→原因→解决”的顺序记录方便照方抓药。5.1 TCP粘包半包解析模块收到一堆0x68乱码现象程序运行一段时间后日志里出现大量“unknown frame”或者解析出负数电压重启后好一阵子又复发。原因IEC104跑在TCP上TCP是流协议没有消息边界。一帧数据可能在一次read里收到两帧也可能一帧数据被拆成两次read。如果解析代码按“每次read就是一帧”来写必然撞上粘包和半包。解决读取时先读第1字节判断是不是0x68再读第2字节拿到APDU长度然后循环读取凑满这个长度才算一帧完整数据。实际上我的readFrame方法就是按这个逻辑写的先把帧头两字节读完再按长度收满剩余部分。这样无论TCP怎么拆最终都能正确还原消息边界。5.2 多线程写库死锁SQLite 直接抛 database is locked现象换成SQLite做本地历史库后高并发写入一会儿就报“database is locked”程序卡住数据积压越来越严重。原因多线程同时对SQLite连接做写提交SQLite的锁粒度是整库两个写线程互相等待加上连接池里每个连接都开着事务锁冲突被放大。解决这是典型的“不该用多线程写单机库”的场景。要么换MySQL/PostgreSQL这类支持行锁的库要么用单写线程把所有写库请求串行化。本地嵌入式场景我用后者一个写库线程加一个阻塞队列就够了。连接池参数也要注意SQLite的maximumPoolSize设成1连接数大于1没有任何并发收益反而增加锁冲突。5.3 数据错位历史曲线上某几个点和实际对不上现象趋势图上偶尔出现一个离谱的电压值比如10kV线路突然显示1000V但现场仪表正常。而且不是固定点位像幽灵一样随机出现。原因多半是信息体地址解析错了。IEC104的信息体地址在ASDU里是三个字节有些从站用的是站内自定义顺序不是从0开始连续编号。主站侧如果按“第一个点上送的就是地址1”来猜遇到信息体地址跳变或扩展就会把数据填到错误的点位上去。解决认准ASDU里的信息体地址字段不要依赖上送顺序。现场联调阶段让从站侧把每个测点的地址表导出来主站侧按地址表建点位映射。上线后如果发现“错位”的点先抓包比对信息体地址再查映射关系基本都是这两种原因之一。5.4 遥控无确认命令发了设备纹丝不动现象遥控界面能选点、能下发但日志里一直没有执行确认也没有超时回滚。原因检查后发现发送序号没有严格递增。某个并发分支在判断链路状态时出错导致两帧命令用了同一个序号。从站严格校验序号不连续的帧直接丢弃且不回任何错误帧看起来就像“命令被黑洞吸走了”。解决发送序号统一用一个AtomicInteger管理所有下发路径都必须从同一个入口取号禁止各模块自己持有计数。另外U帧和I帧要区分对待只有I帧消耗发送序号。我在代码里把“分配序号”和“实际发送”封装成同一个方法避免跨线程调用时拿到重复序号。5.5 队列积压导致OOM内存曲线像爬楼梯现象站点数量增加后程序内存持续上涨最终OOM进程重启后不久又涨上去。原因接收队列用了无界队列或者有界队列的拒绝策略没有兜底。当数据库写入变慢时消费者消费能力下降生产者还在持续从Socket读帧队列无限堆积JVM堆被塞满。解决BlockingQueue必须设界拒绝策略用“丢弃并记录告警”同时make入实时监控每10秒检查一次队列占用率超过80%就发WARN日志或告警短信。真正能治本的还是把消费端搞快——批量插入、异步处理、必要时水平扩容站点连接。OOM不是问题本身只是你把问题藏到了内存里而已。6. 上线前必做的一次报文回放与压力测试主站程序写出来后最怕的就是“联调时一切正常上线第二天数据断流”。我自己的习惯是上线前花一天时间做三件事抓真实报文、回放验证、并发压测。这套流程救过我好几次值得分享。第一步是从站侧或前置机抓包用tcpdump或Wireshark录下一段真实的通信交互tcpdump -i eth0 -s 0 -w iec104_capture.pcap port 2404录的时间不要选在业务低谷尽量录10分钟以上的完整交互包含启动、总召唤、遥测周期上送、遥信变位甚至一次遥控操作。第二步是把这个pcap文件里的IEC104报文按原时序回放给主站程序用一个简单的Java回放线程读pcap解析出每帧相对时间然后按相同间隔往本地主站端口发送。这样等于把现场的真实数据流搬到了测试环境主站程序解析入库后直接比对数据库记录数。回放通过的下一步是并发压测。我会同时开三路模拟从站每路每秒上送200帧遥测持续10分钟监控主站的内存、CPU、队列入队出队速率和数据库写入吞吐。如果队列积压保持稳定不增长说明消费能力匹配如果队列长度线性上升就回头看消费线程的瓶颈在哪里。压测时重点盯两个指标丢帧率和数据延迟。IEC104本身的补召机制能容忍少量丢帧但只要出现丢帧就要区分是“Socket读慢了”还是“业务处理堵了”。前者加缓冲、调读缓冲大小后者减批量大小、加消费者线程。我的血泪教训是压测时一定把日志级别调到DEBUG回放完成后看有没有“receipt order mismatch”之类的序号告警。很多问题在压力下才会现形等上了生产再去抓包成本和风险完全不一样。这套流程走完再拉闸试一次断线重连大概就能放心开票上线了。希望帮到你。本文还有配套的精品资源点击获取
简介基于IEC104协议的微电网管理系统主站客户端程序专为电力系统自动化与智能电网场景设计面向从事远程监控、数据采集与调度控制的开发及运维人员。程序基于Java语言实现完整覆盖遥信遥测解析、遥控遥调命令下发、多线程Socket通信与高并发数据库操作等核心功能可作为微电网主站系统的参考实现或二次开发基础。压缩包共107个文件约3.62MB包含23个Java源码、30个class编译文件、9个jar依赖包以及properties、xml、json等配置资源另有png示意图辅助理解界面docx/md文档提供配置与使用说明目录结构清晰。已有143人浏览学习适合需要理解IEC104协议落地或搭建轻量化监控客户端的读者。通过阅读源码与工程配置可掌握电力规约解析、多线程数据采集及高并发读写等关键实现思路附带的说明文件也为部署调试提供了指引。1. IEC104主站客户端先卸下“协议难啃”的预期再谈并发和数据调度台上遥信在闪、曲线在跳值班员看似平静地盯着一块大屏——而大屏背后那个实时刷新的监控画面正是微电网管理系统主站的核心一个基于IEC104协议的主站客户端程序负责把远处逆变器、储能PCS、配电柜的电压电流拉回来入库再把遥控遥调命令送下去。很多人一听IEC104就觉得是嵌入式的活、C语言的活实际用Java实现主站侧客户端才是工程上最常见也最舒服的一条路上手快、生态全、并发工具现成。这篇文章沿着“协议帧→Socket多线程→报文解析→命令下发”的链路把关键步骤、参数取舍和现场踩过的坑一次讲透适合想从普通Java开发转向电力监控、SCADA或物联网采集方向的工程师照着落地。2. 读懂IEC104帧结构再写代码从68起始字节到启动时序IEC104本质上是IEC 60870-5-104把工控规约跑在TCP的2404端口上。它比Modbus TCP复杂的地方在于它不是一问一答的简单请求响应而是带序号、带确认、有状态机约束的完整链路规约。连接建立后要激活链路、要总召唤、要周期心跳每一条U帧、S帧、I帧都有严格的时序要求。先把帧结构看懂后面解析、下发、故障排查就都顺了。2.1 把一帧报文拆到纸面上APCI、ASDU 与类型标识的读法IEC104一发完整的数据帧可以切成两部分前6个字节是APCI应用规约控制信息之后的字节是ASDU应用服务数据单元。APCI第1字节固定是0x68第2字节表示后面还有多少个字节第3到第6字节是控制域。控制域决定这帧是I帧带序号的数据帧、S帧确认帧还是U帧控制帧。ASDU内部按顺序排第1字节是类型标识第2字节是可变结构限定词第3、4字节是传送原因第5、6字节是公共地址之后才是信息体。信息体里最常用的是带品质描述符的测量值比如短浮点遥测的类型标识是0x0D单点遥信的标记是0x01总召唤是0x64。看一帧16进制报文时按这个顺序逐字节啃比任何工具都可靠位置内容含义字节10x68固定起始字节字节20x0AAPDU长度不含前两个字节字节3-6控制域I/S/U帧类型、发送/接收序号字节70x0D类型标识短浮点遥测字节80x01可变结构限定词SQ0即单信息体字节9-100x06 0x00传送原因激活字节11-120x01 0x00公共地址字节13信息体地址点位地址现场测点号一个小经验解析IEC104包时不要去数“第几个字段叫什么”而是直接用一个带游标的ByteBuffer边读边移动位置。这样遇到长度未知的信息体也好处理——先读类型标识再根据类型决定信息体结构然后从缓冲区里切对应长度。2.2 U帧不过关后面全是黑匣子STARTDT、总召唤、时钟同步与 TESTFR 心跳TCP一连上就能发总召唤吗不行。IEC104要求主站先发U帧STARTDT act0x68 0x04 0x07 0x00 0x00 0x00激活链路从站回STARTDT con0x68 0x04 0x0B 0x00 0x00 0x00后才允许发I帧。之后主站发总召唤类型标识0x64从站以总召唤结束帧收尾主站才算进入数据同步状态。这个时序很多新手会忽略结果是从站一直不回遥测抓包看报文一片寂静。心跳也靠U帧的TESTFR act实现主站定时发测试帧从站回TESTFR con。如果超过一定时间没收到确认主站应该主动断开重连。心跳周期我习惯设为10到30秒具体和现场通道质量有关光纤通道可以30秒GPRS或无线公网最好5到10秒。启动时序总结下来是这样TCP连接建立端口2404。主站发STARTDT act等待STARTDT con。收到确认后发总召唤等待遥测遥信上送和召唤结束帧。进入正常运行状态定时发TESTFR心跳。每24小时或现场需要时重新总召唤一次用来校准运行数据和处理漏帧。也就是说IEC104主站客户端不是“拨通电话就能说话”它更像两个电台之间的约定握手——少一步都可能让对方拒绝通信。调试阶段我一般先把这几个U帧的状态打日志确认握手通了再去看遥测数据。2.3 状态机别拍脑袋写STOPPED 到 SYNCED 的跳转条件主站侧通信状态至少要分三个未激活STOPPED、链路激活ACTIVE、数据同步SYNCED。每个状态下允许做的事不一样收到帧后也要先判断状态再处理不然容易出现“乱拳打死老师傅”式解析。Java里我习惯用一个简单的枚举维护public enum LinkState { STOPPED, // 未激活TCP已连接但链路未启动 ACTIVE, // 已激活收到STARTDT确认可以发总召唤 SYNCED // 已同步总召唤完成遥测数据正常上送 }收到每一帧时的处理规则很简单只有ACTIVE以上才能发I帧只有SYNCED才把遥测往数据库写如果链路从SYNCED跌回STOPPED要清空发送/接收序号重新握手。这个状态机不复杂但一定要独立放在一个类里别跟报文解析混在一个方法里写否则后面每加一个功能都在这个类上打补丁迟早翻车。3. Java多线程Socket通信连接、队列与批量写库的配合方式IEC104主站的通信压力通常不来自单帧处理而来自持续的批量数据。一个微网站点几百个遥测点每个点每秒或每几秒上送一次再加上遥信变位冲击几路连接叠加后如果收发、解析、入库全挤在一个线程里程序很快会因为数据库I/O阻塞而丢包。这里要做的不是“优化单线程代码”而是把职责拆到不同线程各干各的。3.1 单连接还是多连接主站侧线程模型怎么分活常见的做法是一台从站子站建一条TCP连接主站侧一个连接分配一个接收线程。接收线程只负责从Socket里把完整的APDU读出来放进一个待处理队列就结束绝不在接收线程里做数据库写入。队列另一头由业务线程池消费做ASDU解析、业务逻辑、入库操作。这样读写两边互相独立即使数据库抖动也不会立刻拖垮网络接收。连接和子站的对应关系要提前规划好如果现场有多个从站每条连接单独监听一个端口或目标地址。我在实现时会把连接对象封装成一个Session里面持有Socket、接收线程、链路状态、发送序号等避免多连接共享可变状态时互相打架。线程划分边界具体是这样的接收线程一个连接一个只做Socket读取和APDU拆包。业务线程池解析ASDU、处理遥信遥测、执行遥控逻辑。写库线程池消费批量数据做批量插入或更新。调度线程池心跳、总召唤、重连、数据补召。留意一个原则不要在线程里共享可变字段而不加锁。更简单的做法是让线程间只通过队列传不可变对象状态各自独立这样锁的问题基本消失。3.2 有界阻塞队列生产者消费者模式在这里的落地接收线程是生产者业务线程是消费者。这个模式在Java里直接用BlockingQueue实现最省心。唯一要注意的是队列必须设上限否则从站忽然大批量上送历史数据时业务线程消化不过来队列无限膨胀JVM直接OOM。BlockingQueuebyte[] frameQueue new LinkedBlockingQueue(20000); // 接收线程读到完整APDU后入队 while (running) { byte[] apdu readApduFromSocket(socket); if (apdu ! null) { if (!frameQueue.offer(apdu)) { // 队列满说明消费能力不足记日志丢弃最旧或丢弃当前 log.warn(frame queue is full, drop one frame, size{}, frameQueue.size()); } } } // 业务线程消费并处理 while (running) { byte[] apdu frameQueue.poll(500, TimeUnit.MILLISECONDS); if (apdu ! null) { dispatch(apdu); } }这里用的是offer而不是put因为put在队列满时会一直阻塞接收线程被卡住后Socket读缓冲也堵住可能引起对端重传风暴。用offer加丢弃策略最多丢一帧数据但保住了链路的存活。丢弃后靠周期总召唤或数据补召机制还能把缺的数据找回来这是IEC104体系比普通TCP裸传更稳的地方。队列容量按什么定我一般按“单帧平均耗时 × 每秒帧数 × 容忍秒数”来估算。比如一帧平均处理5毫秒每秒进帧500个容忍积压40秒容量就是20000。压测时把容量设小一倍看日志有没有丢弃用来反推消费瓶颈。3.3 批量插入与连接池配置入库吞吐量的实测依据遥测数据每秒几十条上百条如果用一条SQL插一条数据库连接会频繁获取释放事务开销也大。常见做法是攒批攒到一定条数或一定时间再统一提交。用MyBatis时开批量执行器或者用JDBC的addBatch效果都比循环单插高一到两个数量级。// 攒批每500条或每300毫秒提交一次 int batchSize 0; ListTelemetryRecord buffer new ArrayList(1024); for (TelemetryRecord r : recordQueue.takeAll()) { buffer.add(r); batchSize; if (batchSize 500) { flushBatch(buffer); // 批量写入 buffer.clear(); batchSize 0; } }实际项目里我有一个更稳的做法批量写入放到单独线程用数组列表当缓冲避免每来一条就触发一次同步。数据库连接池参数也不能拍脑袋HikariCP下我常用maximumPoolSize给到CPU核心数加一minimumIdle保持2到4connectionTimeout设5秒。连接数不是越多越好批量插入的场景下太多连接反而容易把数据库锁资源打满。一个现场容易忽略的参数是rewriteBatchedStatementsMySQL连接串里加上它才能让批量insert真正合并成一条多值SQL不加的话JDBC驱动默认逐条提交批量等于白做。PostgreSQL和国产数据库各有对应开关先查驱动文档再上线。3.4 心跳线程与断开重连用 ScheduledExecutorService 还是 Timer心跳和重连不适合用Timer因为Timer是单线程一个任务卡住会影响后续所有定时任务。ScheduledExecutorService每个任务独立线程更可靠。而且心跳要用scheduleWithFixedDelay而不是scheduleAtFixedRate前者是“本次任务结束后再等固定时间”后者是“按固定周期硬调度”。网络抖动时scheduleAtFixedRate容易堆积任务心跳发得越来越密把通道打满。ScheduledExecutorService scheduler Executors.newScheduledThreadPool(2); // 每10秒发一次TESTFR若连续3次无确认则触发重连 scheduler.scheduleWithFixedDelay(() - { if (linkState LinkState.SYNCED) { sendTestFrame(); if (lostTestCount 3) { reconnect(); } } }, 10, 10, TimeUnit.SECONDS);重连要做退避不然通道不稳定时主站会像“打地鼠”一样疯狂建连断开。我用的是1秒、2秒、4秒的指数退避最大30秒成功连接后立即复位。还有一个坑是重连后必须重新走STARTDT和总召唤流程不能只把Socket接上就以为通信恢复了否则从站侧还停留在旧链路上数据完全不来。4. 遥信遥测解析与遥控遥调下发从字节到业务动作帧结构懂了、线程模型架好了剩下的核心就是把ASDU里的信息体翻译成业务数据以及把业务指令封装成命令帧发下去。这一层的细节最多品质描述符决定数据能不能用遥信的变位防抖决定误报率遥控的选择执行流程决定安全性。4.1 遥测品质描述符哪些数据能入库、哪些必须标记每个遥测信息体除了值还带一个字节的品质描述符QDS这是IEC104和普通Modbus最大的区别之一。QDS的低4位各有含义位标志含义bit0IV无效值数值不可信bit1NT非当前值可能是缓存或未刷新bit2SB被替代来自人工置入或替补源bit3BL被闭锁测点被封锁bit4OV溢出解析时不能只看值还要按位判断品质。无效或溢出的数据进库前要打上标记否则事故分析时看到一条电压零值值班员会误判成真正的失压事故。public static boolean isInvalid(byte qds) { return (qds 0x01) ! 0; // IV位 } public static boolean isOverflow(byte qds) { return (qds 0x10) ! 0; // OV位 }现场最坑的情况是某个测点接线松动从站上送的数值跳来跳去但品质标志一直是有效。这说明从站侧的采集模块没有正确设置QDS。主站能做的就是把历史品质信息也一并入库方便事后追溯是主站问题还是现场采集问题。我一般会在遥测表里加一个quality字段每一条都记录原始QDS字节而不是只存个干净数值。4.2 遥信防抖与变位风暴别让一次抖动铺满整张报警表微电网的遥信变位是最容易让主站“报警刷屏”的数据。光伏逆变器启停、并网开关分合、保护动作信号任何一个触点抖动从站都会按变位上送。主站如果不做防抖处理一次真实的分闸伴随几次反弹抖动数据库里会出现同一开关的连续翻转记录。防抖做法有两种按时间窗过滤和按连续确认过滤。我常用的是时间窗也就是收到一个变位事件后短时间内相同点位的重复变位直接忽略或延迟到窗口结束后再判断。窗口长度现场调一般是300到800毫秒特殊抖动严重的点位设到1秒。// 按点位缓存上一次变位时间500毫秒内的重复变位不处理 long now System.currentTimeMillis(); Long last lastChangeTime.get(pointAddr); if (last ! null now - last 500) { return; // 判定为抖动 } lastChangeTime.put(pointAddr, now); processChangeEvent(pointAddr, value);如果现场有大量点位同时变位比如整段母线失压几百个遥信几分钟内陆续上送主站的报警队列会瞬间积压。这时数据库写入要走批量报警处理要异步化不能把每个变位事件都同步推给业务系统。先记流水再异步判断告警条件是这类系统的常规解法。4.3 遥控四步走选择、执行、超时、回读一致性遥控命令下发不是把命令帧发出去就完事。IEC104支持带选择执行的控制流程先发一条带S/E位选择标志的遥控命令从站校验选中对象并把命令返回到“待执行”状态主站收到选择确认后再发一条执行命令从站执行完回确认。整个过程还要带超时和一致性校验。// 发送单点遥控选择命令类型标识0x2DS/E1表示选择 byte[] selectCmd buildC_SC_NA( commonAddr, pointAddr, value, ControlFlag.SELECT, seqNo.getAndIncrement()); sendFrame(selectCmd); // 等待选择确认确认帧的传送原因应为“激活确认”(7) // 收到后再发执行命令S/E0表示执行 byte[] executeCmd buildC_SC_NA( commonAddr, pointAddr, value, ControlFlag.EXECUTE, seqNo.getAndIncrement()); sendFrame(executeCmd);这里最关键的参数是序号控制域的发送序号。IEC104的I帧序号必须严格递增并循环使用从站收到序号不连续的命令帧会直接丢弃主站侧表现为“发出去的命令石沉大海没有确认也没有执行”。我排这类问题时第一步不是抓包看命令内容而是先看本端发送序号是不是跳了十次里有八次是并发下发时序号没加锁导致。遥调设点命令的逻辑类似只是信息体是数值加品质描述符。微电网里常见的遥调是储能有功功率设定、PCS无功功率设定。下发前一定要带上下限检查和命令超时回收避免操作员在界面上输入一个超限值直接穿透到现场设备。5. 踩坑清单粘包、写库死锁与数据乱序的排障记录这一章的每一条都是真金白银换来的。协议解析和线程架构看文档能学会但运行现场的坑往往在文档之外。以下五条按“现象→原因→解决”的顺序记录方便照方抓药。5.1 TCP粘包半包解析模块收到一堆0x68乱码现象程序运行一段时间后日志里出现大量“unknown frame”或者解析出负数电压重启后好一阵子又复发。原因IEC104跑在TCP上TCP是流协议没有消息边界。一帧数据可能在一次read里收到两帧也可能一帧数据被拆成两次read。如果解析代码按“每次read就是一帧”来写必然撞上粘包和半包。解决读取时先读第1字节判断是不是0x68再读第2字节拿到APDU长度然后循环读取凑满这个长度才算一帧完整数据。实际上我的readFrame方法就是按这个逻辑写的先把帧头两字节读完再按长度收满剩余部分。这样无论TCP怎么拆最终都能正确还原消息边界。5.2 多线程写库死锁SQLite 直接抛 database is locked现象换成SQLite做本地历史库后高并发写入一会儿就报“database is locked”程序卡住数据积压越来越严重。原因多线程同时对SQLite连接做写提交SQLite的锁粒度是整库两个写线程互相等待加上连接池里每个连接都开着事务锁冲突被放大。解决这是典型的“不该用多线程写单机库”的场景。要么换MySQL/PostgreSQL这类支持行锁的库要么用单写线程把所有写库请求串行化。本地嵌入式场景我用后者一个写库线程加一个阻塞队列就够了。连接池参数也要注意SQLite的maximumPoolSize设成1连接数大于1没有任何并发收益反而增加锁冲突。5.3 数据错位历史曲线上某几个点和实际对不上现象趋势图上偶尔出现一个离谱的电压值比如10kV线路突然显示1000V但现场仪表正常。而且不是固定点位像幽灵一样随机出现。原因多半是信息体地址解析错了。IEC104的信息体地址在ASDU里是三个字节有些从站用的是站内自定义顺序不是从0开始连续编号。主站侧如果按“第一个点上送的就是地址1”来猜遇到信息体地址跳变或扩展就会把数据填到错误的点位上去。解决认准ASDU里的信息体地址字段不要依赖上送顺序。现场联调阶段让从站侧把每个测点的地址表导出来主站侧按地址表建点位映射。上线后如果发现“错位”的点先抓包比对信息体地址再查映射关系基本都是这两种原因之一。5.4 遥控无确认命令发了设备纹丝不动现象遥控界面能选点、能下发但日志里一直没有执行确认也没有超时回滚。原因检查后发现发送序号没有严格递增。某个并发分支在判断链路状态时出错导致两帧命令用了同一个序号。从站严格校验序号不连续的帧直接丢弃且不回任何错误帧看起来就像“命令被黑洞吸走了”。解决发送序号统一用一个AtomicInteger管理所有下发路径都必须从同一个入口取号禁止各模块自己持有计数。另外U帧和I帧要区分对待只有I帧消耗发送序号。我在代码里把“分配序号”和“实际发送”封装成同一个方法避免跨线程调用时拿到重复序号。5.5 队列积压导致OOM内存曲线像爬楼梯现象站点数量增加后程序内存持续上涨最终OOM进程重启后不久又涨上去。原因接收队列用了无界队列或者有界队列的拒绝策略没有兜底。当数据库写入变慢时消费者消费能力下降生产者还在持续从Socket读帧队列无限堆积JVM堆被塞满。解决BlockingQueue必须设界拒绝策略用“丢弃并记录告警”同时make入实时监控每10秒检查一次队列占用率超过80%就发WARN日志或告警短信。真正能治本的还是把消费端搞快——批量插入、异步处理、必要时水平扩容站点连接。OOM不是问题本身只是你把问题藏到了内存里而已。6. 上线前必做的一次报文回放与压力测试主站程序写出来后最怕的就是“联调时一切正常上线第二天数据断流”。我自己的习惯是上线前花一天时间做三件事抓真实报文、回放验证、并发压测。这套流程救过我好几次值得分享。第一步是从站侧或前置机抓包用tcpdump或Wireshark录下一段真实的通信交互tcpdump -i eth0 -s 0 -w iec104_capture.pcap port 2404录的时间不要选在业务低谷尽量录10分钟以上的完整交互包含启动、总召唤、遥测周期上送、遥信变位甚至一次遥控操作。第二步是把这个pcap文件里的IEC104报文按原时序回放给主站程序用一个简单的Java回放线程读pcap解析出每帧相对时间然后按相同间隔往本地主站端口发送。这样等于把现场的真实数据流搬到了测试环境主站程序解析入库后直接比对数据库记录数。回放通过的下一步是并发压测。我会同时开三路模拟从站每路每秒上送200帧遥测持续10分钟监控主站的内存、CPU、队列入队出队速率和数据库写入吞吐。如果队列积压保持稳定不增长说明消费能力匹配如果队列长度线性上升就回头看消费线程的瓶颈在哪里。压测时重点盯两个指标丢帧率和数据延迟。IEC104本身的补召机制能容忍少量丢帧但只要出现丢帧就要区分是“Socket读慢了”还是“业务处理堵了”。前者加缓冲、调读缓冲大小后者减批量大小、加消费者线程。我的血泪教训是压测时一定把日志级别调到DEBUG回放完成后看有没有“receipt order mismatch”之类的序号告警。很多问题在压力下才会现形等上了生产再去抓包成本和风险完全不一样。这套流程走完再拉闸试一次断线重连大概就能放心开票上线了。希望帮到你。本文还有配套的精品资源点击获取
