简介电网104规约JAVA104协议监听资源包面向电力自动化、变电站远动通信与IEC 60870-5-104协议开发者可解决主站连接、实时监听与104报文解析等典型需求。针对需要快速实现104规约通信的Java工程师提供了基于SpringBoot的可直接运行示例完整覆盖从连接创建、报文监听到数据输出的链路。压缩包共5个文件包括3个Java源码文件主站连接类、监听器类、运行入口类、1个Markdown说明文档和1个所需jar依赖包整体仅105KB结构清晰说明文档中还附带了pom依赖便于集成。资源已将104报文全部解析为常规十进制数据并重写toString()方法将关键监听信息整理成易读格式省去逐字节解析的繁琐同时给出通过POST请求把监听数据转发给客户端处理的参考做法读者可按需注释或改造。目前已有1413人学习下载适合具备一定Java基础、希望快速上手104规约监听开发的工程师。1. 电网104规约JAVA104协议监听拿到这屏TCP流量就等于拿到了变电站的实时数据盘做集控站项目时我第一次打开抓包软件看到满屏68 0E ...开头的报文心里是发怵的。这就是电网104规约的原始样子JAVA104协议监听这件事核心不是写一个 Socket 收数据而是把收到的每帧二进制拆成“这条是总召唤、这条是遥信变位、这条是遥测越限”再把获取监听数据落成结构化点表。听上去像黑匣子其实骨架非常固定一个0x68起始字节、一个长度、四字节控制域、一串 ASDU。搞清这张表的人两天能跑通最小监听模块搞不清的人会在遥测值像随机数、点表对不齐、断链重连上磨一个月。这篇文章按我实际做过的工业采集方案来写面向要接104规约的集控系统、边缘网关和后台开发。你会得到监听必须懂的报文结构、一个用 Java 实现的最小监听服务、数据怎么解析成业务可用以及我踩过的一堆坑。2. 104规约监听前必须搞懂的三张表APDU、类型标识、总召唤时序2.1 APDU那6个头部字节68、len、控制域为什么决定一切104规约跑在TCP之上一帧就是一个APDU应用协议数据单元。开头两个字节固定是0x68 0x0E这样第一个字节是启动字符永远是0x68第二个字节是本帧剩余长度单位是字节注意它不包含0x68和len自己。后面跟四个字节控制域再往后才是ASDU应用服务数据单元。所以一帧的完整布局是字节位置长度含义byte01启动字符 0x68byte11后续长度 lenbyte2~byte54控制域决定帧类型byte6 起len-4ASDUI帧才有控制域前两位的组合决定这帧是什么。这是我解码器里最先判断的东西也是全新手最容易忽略的地方int ctrl frame[2] 0xFF; int frameType ctrl 0x03; // 0 I帧携带ASDU业务数据都在这里 // 1 S帧纯确认帧告诉对端“我收到了” // 3 U帧链路控制帧负责启动/停止/测试链路S帧和U帧没有ASDU长度固定为4。如果监听程序把所有帧都往ASDU解析逻辑里送立刻数组越界或解析出奇怪数据。我习惯把帧分类和业务解析彻底分开I帧才进数据解析S帧只用于确认计数U帧单独走链路状态机。U帧的第二个字节也有讲究比如68 04 07 00 00 00是 STARTDT act请求启动链路68 04 0B 00 00 00是STARTDT con确认启动。很多厂站不上电后不发数据就是因为主站侧没发这个启动帧链路根本没建立。2.2 类型标识决定数据“长什么样”遥信、遥测、SOE一张表说清ASDU第一个字节是类型标识它决定了后面信息体怎么解释。这也是“获取监听数据”真正要落地的地方。我整理了最常遇到的类型标识够覆盖90%的变电站场景类型标识(Hex)含义信息体结构0x01单点遥信IOA(3) 单点信息1字节0x03双点遥信IOA(3) 双点信息1字节0x09测量值短浮点IOA(3) 浮点4字节 品质1字节0x1E带时标单点信息SOEIOA(3) 单点信息 7字节时标0x2D单点遥控命令IOA(3) 遥控命令1字节0x2E双点遥控命令IOA(3) 遥控命令1字节0x64总召唤通常后面带限定词看一眼类型标识就要知道这帧是变位信号还是电压电流以及信息体按几个字节切。ASDU头部是固定的六字节类型标识1字节、可变结构限定词1字节、传输原因2字节、公共地址2字节。信息体从第7个字节开始也就是ASDU的下标6。传输原因同样重要0x06是主站激活命令0x07是激活确认0x0A是激活终止0x1420是响应总召唤。判断数据是“正常周期上送”还是“变位突发”主要看传输原因是不是0x03突发或0x04突发确认。调试排查时传输原因能直接告诉你这帧是怎么来的。2.3 总召唤时序监听工具该在哪个阶段“进场”厂站上电后第一件大事是总召唤。主站会发一条“把全部点送上来”的命令厂站收到后批量上送当前所有遥信遥测然后发一帧总召唤结束。我做的监听服务通常挂在链路建立之后把这段完整时序当基准测试主站 - 厂站68 04 07 00 00 00 STARTDT act请求启动链路 厂站 - 主站68 04 0B 00 00 00 STARTDT con确认启动 主站 - 厂站68 0E 00 00 00 00 64 01 06 00 01 00 00 00 00 14 总召唤激活类型0x64传输原因0x06 厂站 - 主站68 0E 00 00 00 00 64 01 07 00 01 00 00 00 00 14 总召唤确认传输原因0x07 厂站 - 主站多帧I帧类型0x01/0x03/0x09 批量上送遥信遥测 厂站 - 主站68 0E 00 00 00 00 64 01 0A 00 01 00 00 00 00 14 总召唤结束传输原因0x0A我一般用这段时序做三件事第一验证解码器对U帧、I帧的分类是否正确第二验证ASDU解析器是否能把每一类信息体切干净第三拿总召唤结束当“点表对齐”的基准点。总召唤结束之前收到的数据因为遥信可能重复上送直接入库会产生大量覆盖写我会缓存到总召唤结束后再统一落库。这是监听程序“进场”最稳的位置。3. 用JAVA104协议实现监听从一个Netty服务端开始3.1 为什么选Netty而不是普通Socket104链路是长连接一挂就是几个月数据是持续不断的TCP流普通ServerSocket加死循环 read 很快会碰到几个问题粘包拆包要自己写状态机、并发连接要自己管线程池、断线重连要自己维护。Netty把这些基础设施都做完了我只需要专注写解码器这也是JAVA104协议监听最省力的落地方式。104交互还有个特点主站会同时保持多条链路厂站数据上来是突发式的变位时会连续来几十帧。Netty的ChannelPipeline和背压机制能让我把所有业务处理放到业务线程池避免IO线程被数据库写操作卡死。监听程序一旦卡IO导致的直接后果是S帧回慢了厂站重传整个链路数据拥堵。我做监听服务时用的是服务端模式厂站作为TCP客户端连上来我这边监听端口等着。代码骨架如下EventLoopGroup boss new NioEventLoopGroup(1); EventLoopGroup worker new NioEventLoopGroup(4); try { ServerBootstrap b new ServerBootstrap(); b.group(boss, worker) .channel(NioServerSocketChannel.class) .childHandler(new ChannelInitializerSocketChannel() { Override protected void initChannel(SocketChannel ch) { ch.pipeline().addLast(new Iec104Decoder()); ch.pipeline().addLast(new Iec104Handler()); } }); ChannelFuture f b.bind(2404).sync(); f.channel().closeFuture().sync(); } finally { boss.shutdownGracefully(); worker.shutdownGracefully(); }2404是104规约常用端口实际项目里可能被改成其他端口用配置项管理就好。这个骨架有两点值得说childHandler里每来一个TCP连接都new出独立的Decoder和Handler保证多链路互不干扰closeFuture().sync()让主线程阻塞住服务常驻运行。3.2 最小可用的104报文解码器拆粘包、稳帧头104报文靠byte1的长度字段切割Netty自带的LengthFieldBasedFrameDecoder可以直接用但我更推荐自定义ByteToMessageDecoder因为帧类型判断要和控制域配合放一起最顺手public class Iec104Decoder extends ByteToMessageDecoder { Override protected void decode(ChannelHandlerContext ctx, ByteBuf in, ListObject out) { if (in.readableBytes() 2) { return; // 连帧头都不齐等更多字节 } in.markReaderIndex(); byte start in.readByte(); if (start ! (byte) 0x68) { // 不是0x68开头说明之前有脏数据这个字节已被消费继续对齐 return; } int len in.readUnsignedByte(); if (len 4) { // 长度小于4控制域都装不下这条帧异常丢弃 return; } if (in.readableBytes() len) { // 帧没接收完整重置读指针等下一批数据 in.resetReaderIndex(); return; } byte[] frame new byte[2 len]; in.resetReaderIndex(); in.readBytes(frame); out.add(frame); // 产出完整帧交给下一个Handler } }这段代码有四个关键决策点第一个return是为了凑齐两个字节的帧头start不等于0x68时直接消费掉这个字节下一次decode从新位置开始这是TCP流对齐脏数据的标准做法len 4直接弃帧因为控制域至少要4字节最后readableBytes不足len时用resetReaderIndex回滚等更多数据来再拼这是拆粘包拆半包的核心。为了防止一条连接里有人恶意发超长帧拖垮内存我在实际项目中给len加了上限检查超过300字节直接断链。104规约正常帧极少超过255字节这个上限已经非常宽松。3.3 把ASDU分派给不同处理器用类型标识分流把数据取出来解码器产出的是一整帧byte数组接下来Handler要按帧类型分流。I帧才取ASDU再按类型标识分发到具体解析方法public class Iec104Handler extends ChannelInboundHandlerAdapter { Override public void channelRead(ChannelHandlerContext ctx, Object msg) { byte[] frame (byte[]) msg; int frameType frame[2] 0x03; if (frameType 0) { // I帧解析ASDU byte[] asdu Arrays.copyOfRange(frame, 6, frame.length); int typeId asdu[0] 0xFF; switch (typeId) { case 0x01 - processSinglePoint(asdu); case 0x03 - processDoublePoint(asdu); case 0x09 - processFloatMeasure(asdu); case 0x1E - processSinglePointWithTime(asdu); case 0x64 - processGeneralCall(asdu); default - log.warn(未识别类型标识: {}, String.format(%02X, typeId)); } } else if (frameType 1) { // S帧纯确认业务上可忽略但要记录序列号用于丢包判断 } else { // U帧启动/停止/测试链路 handleUFrame(ctx, frame); } } }注意注释里TypeId 0x1E是带时标单点信息SOE在变电站里叫“事故追忆”变位带7字节时标是事后分析的关键数据。switch分流看着简单但它是监听模块的骨架后面每加一种规约扩展只需要增加一个case分支和对应解析方法。解析单个信息对象地址时要读ASDU下标6开始的三个字节做小端拼接。以单点遥信为例private void processSinglePoint(byte[] asdu) { int vsq asdu[1] 0xFF; int count vsq 0x7F; // 低7位是信息对象个数 boolean continuous (vsq 0x80) ! 0; // 高位置1表示连续地址 int cot asdu[3] 0xFF; // 传输原因 int pos 6; int baseIoa 0; for (int i 0; i count; i) { int ioa; if (continuous) { if (i 0) { baseIoa (asdu[pos] 0xFF) | ((asdu[pos 1] 0xFF) 8) | ((asdu[pos 2] 0xFF) 16); pos 3; } else { ioa baseIoa i; // 连续地址后续对象地址递增 } } else { ioa (asdu[pos] 0xFF) | ((asdu[pos 1] 0xFF) 8) | ((asdu[pos 2] 0xFF) 16); pos 3; } int siq asdu[pos] 0xFF; boolean value (siq 0x01) 1; pos 1; log.info(IOA{}, 遥信值{}, 传输原因{}, String.format(%06X, ioa), value, cot); } }可变结构限定词VSQ的坑在于“连续地址”模式高位置1时只有第一个信息对象带完整IOA后面的IOA靠递增推算。如果不处理这一位连续上送的几十个遥信会全部解析到同一个点位上点表错得离谱。这也是我排查现场数据漂移时最先怀疑的地方。4. 获取到的监听数据怎么变成业务可用点表映射、时标解析与回放4.1 信息对象地址与点表映射把IOA翻译成变电站里的设备解析出的IOA是十六进制形式的三字节地址比如0x400001业务上这毫无意义。点表映射是“获取监听数据”的最后一公里把IOA对应到“110kV母线A相电压”“1号主变温度”这类业务点。我在项目里用配置驱动点表不写死在代码里。一台新建变电站的点表几百到上千个点写成Map初始化代码既难维护又会反复编译部署。实际用YAML或JSON配置更顺畅points: - { ioa: 0x400001, name: 110kV母线A相电压, type: measure, unit: kV } - { ioa: 0x400101, name: 1号主变温度, type: measure, unit: ℃ } - { ioa: 0x500001, name: 110kV开关位置, type: di, desc: 双点遥信 }加载后用两个Map双向往复MapInteger, String pointNameMap new HashMap(); MapString, Integer pointIoaMap new HashMap(); // 从配置逐条塞入 pointNameMap.put(point.getIoa(), point.getName()); pointIoaMap.put(point.getName(), point.getIoa());业务侧拿IOA查点表拿点表名获取实时值这样界面只认识设备名不认识0x400001。点表映射这件事看着简单但它在后续排查里价值极大IOA对不上点表说明公共地址或信息体偏移算错IOA映射正确但值错了则要去看数据解析逻辑两个方向快速隔离。4.2 CP56Time2a时标解析SOE和带时标遥信的7字节玄学带时标信息体最后7个字节是CP56Time2a时间标签。它在104规约里是出了名的容易解析错因为每个字段都只占一部分位不是整字节。SOE事故追忆如果时间错了整个告警分析就废了。public static LocalDateTime parseCp56Time2a(byte[] b, int off) { int ms (b[off] 0xFF) | ((b[off 1] 0xFF) 8); int minute b[off 2] 0x3F; // 低6位是分钟 int hour b[off 3] 0x1F; // 低5位是小时 int day b[off 4] 0x1F; // 低5位是日 int month b[off 5] 0x0F; // 低4位是月 int year (b[off 6] 0x7F) 2000; // 低7位是年基准2000 return LocalDateTime.of(year, month, day, hour, minute, ms / 1000, (ms % 1000) * 1_000_000); }这个解析有两个坑。第一bit位掩码必须严格按规范来0x3F少了第6位正好是星期几的位会把星期几挤进分钟值0x1F少了小时会掺入夏令时标志位。第二104规约的时标不含时区厂站设备时间就是本地时间解析出来后直接按服务器时区处理即可不要擅自做时区转换否则会和厂站后台对不上。SOE解析完的时间我会和本机时间做差差值大于5秒就打到告警日志里。这能快速暴露厂站时钟不同步的问题也是调试阶段判断“这条变位是新的还是旧的重传”的有效手段。4.3 原始报文落盘与离线回放先存帧再谈处理监听服务上线初期解析逻辑不可能一步到位。我的习惯是每一帧原始报文都落盘按天滚动日志然后再进解析。这样即使解析代码有bug原始数据还在改完代码还能重放一遍。private void saveFrame(byte[] frame) { StringBuilder sb new StringBuilder(); for (byte b : frame) { sb.append(String.format(%02X , b)); } // 追加写入文件加个时间戳便于和业务时间对齐 String line LocalDateTime.now() sb System.lineSeparator(); try { Files.writeString(filePath, line, StandardOpenOption.CREATE, StandardOpenOption.APPEND); } catch (IOException e) { log.error(落盘失败, e); } }离线回放用Netty的EmbeddedChannel特别适合它能在内存里跑完整的pipeline而不依赖真实网络连接EmbeddedChannel channel new EmbeddedChannel(new Iec104Decoder(), new Iec104Handler()); // 每次从日志里读一行hex转成byte[]后writeInbound channel.writeInbound(hexBytes); // 然后验证业务侧收到的点位数量和值离线回放解决的问题是“这次版本改动是否影响了解析结果”。我发布解析代码前会拿当天真实报文跑一遍回放比对点表快照通过才上生产。这也是我认为监听模块最实用的工程习惯保留原始输入让每一次改动都可以被回溯验证。5. 104监听调试与常见问题排查5个现场坑的记录5.1 挥之不去的“半包”数据一多就解析错乱现象一开始连接遥信遥测正常一旦厂站做全数据上送几百帧连发控制台开始报“解码异常”点位对不齐甚至出现莫名其妙的0x68跳变。 原因TCP是流协议一次read可能到半个帧也可能到好几帧如果按“读一次处理一次”的思路写必然错位。解码器没有等够len字节就开始了ASDU解析。 解决在解码器里严格按“先读两字节帧头→看len→readableBytes不够就resetReaderIndex等待”的流程处理。我给出的Iec104Decoder正是为此设计的注意一定要在不够时重置读指针否则会一直消费错误数据。5.2 S帧U帧当I帧解析类型标识越界的尴尬现象日志里突然出现“未识别类型标识: 0x07”“未识别类型标识: 0x0B”规律出现每次隔几秒。 原因S帧和U帧没有ASDU控制域第一字节的数值被当成了类型标识。比如U帧的0x07看着像某个类型就被送进了ASDU解析逻辑。 解决在channelRead里先执行frame[2] 0x03的帧类型判断只有值等于0才是I帧才允许进入ASDU解析。S帧和U帧单独走自己的处理分支不和业务数据混在一起。这个坑是监听模块最常见的“第一周必踩”问题。5.3 遥测全是大得离谱的数浮点字节序翻车现象母线电压读出来是-1.38E10这种天文数字或者1.7E-39这种极小值偶尔有几个点正常。 原因短浮点遥测4个字节有两种拼接方式。厂站侧如果按小端发送我按大端解析四个字节组合出来的位模式自然是一堆随机数。还有种情况是把品质描述词也拼进了浮点值里数据宽度切错一位。 解决第一抓包软件里先看原始hex和厂站说明书对字节顺序。第二代码里用小端拼接后交给Float.intBitsToFloat转换int bits (b[pos] 0xFF) | ((b[pos 1] 0xFF) 8) | ((b[pos 2] 0xFF) 16) | ((b[pos 3] 0xFF) 24); float value Float.intBitsToFloat(bits);另外记得短浮点信息体结构是IOA加4字节浮点再加1字节品质描述词解析时信息体长度按8字节切漏掉品质位会把下一个信息点的开头吃进去造成连锁错位。5.4 总召唤结束判断错点表少了一半还重复入库现象每次链路重建后点位表要么缺一块要么某些点位被重复更新值班日志里全是重复告警。 原因判断总召唤结束用“这条数据长度是0”或者“某一帧读完了”都不靠谱。总召唤是一段连续的多帧I帧结束标志是一帧类型标识0x64、传输原因0x0A的报文。没识别出这个标志程序就不知道“这轮全数据已经送完”。 解决维护一个链路状态标记。收到0x64加0x06激活时置为“总召唤进行中”收到0x64加0x0A激活终止时置为“总召唤结束”。只有“结束”状态到达后才把缓存区里的数据统一落库。这个状态机能让重复变位只产生一次有效更新。5.5 重连后厂站不推数据链路没激活TCP白通现象厂站TCP连接建立成功Wireshark里能看到TCP握手完成但后面一个104报文都没有干等五分钟也没数据。 原因104链路不是TCP一建立就能传数据的主站必须发STARTDT act激活链路厂站回STARTDT con后才开始执行总召唤和正常上送。很多监听程序只做了TCP accept没做链路激活厂站自然“沉默”。 解决连接建立后主动发68 04 07 00 00 00STARTDT act收到68 04 0B 00 00 00STARTDT con后再进入正常数据处理流程。重连场景下我把这个动作放在channelActive回调里执行确保每次TCP重连都重新激活链路。这个坑也是“为什么我的监听服务偶尔失灵”的高频原因。6. 进阶一记把监听模块做成不丢数据的采集服务6.1 链路状态机与序列号校验监听不只是“看”监听模块跑在机房三个月后我开始给它加上状态机。简单说把链路分为INIT→ACTIVE→RUNNING→RECONNECT四态TCP建连后进INIT发出STARTDT act后进ACTIVE收到STARTDT con后进RUNNING断线自动重连回到INIT。每次收到I帧记录发送序号N(S)如果序号比上次跳变大于1说明丢帧了告警并等待总召唤重新同步。int sendSeq (frame[2] 0xFE) | ((frame[3] 0xFF) 8); // 用前值对比大于1说明中间有帧丢失 if (lastSendSeq 0 sendSeq ! lastSendSeq 1) { log.warn(序列号跳变: {} - {}, lastSendSeq, sendSeq); } lastSendSeq sendSeq;序号校验的价值在于被动监听本身无法请求重传但至少要把丢了帧这件事暴露出来。否则某段时间的变位数据悄悄丢掉要到值班人员手动核对Deviation时才追悔莫及。6.2 数据先落盘后入库IO线程不碰数据库监听服务的吞吐量看似不高但变位突发时峰值不低。我吃过直接把数据库写入放在channelRead里的亏IO线程被慢查询卡住S帧回送延迟厂站侧开始超时重传数据越积越多最终链路被拖死。后来改成队列加批量入库BlockingQueuePointValue queue new LinkedBlockingQueue(100_000); // channelRead里只做 parse offer // 单独一个消费线程每2秒批量取500条交给时序库写入队列满时再落一份本地文件兜底。这样监听线程永远只做解码和入队最坏情况是消费端崩溃数据仍在磁盘上可回放不会直接丢。这个模式也被我复用到其他协议采集模块上收益很明显。这三个月的现场经验告诉我104监听最该敬畏的是链路状态而不是TCP连接。很多问题都是TCP明明通着、104层却没激活或者序号已经错乱。我现在每到一个新厂站第一件事是先抓10分钟真实报文把U帧、S帧、I帧的节奏看明白再写代码比对着文档猜参数高效得多。希望这篇文章能帮你少走这些弯路也希望帮到你。本文还有配套的精品资源点击获取