101/104规约调试利器：报文解析与模拟主站实战指南

简介国网101和104测试软件是面向电力系统通信规约测试的专业工具包覆盖IEC 60870-5-101/104规约的报文解析与模拟主站场景适用于配网自动化设备调试、运维及厂商研发验证。压缩包共169个文件约21.62MB主要包含65组dat/cfg采集配置文件、12个msg报文样例、10个dll动态库、2个exe主程序以及xml/xlsx/txt等辅助文档另附h/lib/pdb便于二次开发与调试追溯。软件功能覆盖单点遥信、双点遥信、远程升级、文件读取、定值设置等典型业务严格遵循《配电自动化系统应用 DL/T634.5104-2009 实施细则》可辅助工程师快速校验主站与子站间的通信行为和协议一致性。已有779人学习使用。借助内置解析报文与模拟主站工具可提升规约联调效率为设备入网测试、故障排查及培训教学提供直接可用的操作平台。 做电力自动化调试的人手里要是没有一套顺手的101/104测试软件那基本等于上战场不带枪。我入行前几年全靠串口助手加纸笔一条条对报文后来被各种终端折腾怕了才开始认真用带报文解析的模拟主站工具。今天聊的这套工具就是专门干这个的它把IEC 60870-5-101和IEC 60870-5-104两条规约的报文解析、模拟主站测试打包到了一起平时调终端、跑出厂检验、复现通信异常基本一打开就能干活。1. 为什么101/104调试一定要配一套组合工具1.1 现场调试最常见的三件烦心事先说透一件事说“101/104”其实指的是两类规约。101是串口远动规约走RS-232/RS-485链路简单、抗干扰强很多配网终端、老站房到现在还在用104是101的网络版跑在TCP/IP上端口固定2404新上的设备基本都是104。但不管是哪条规约调试的时候绕不开三个共同的问题。第一原始报文看不懂。无论串口抓的还是网络抓包拿到的全是一堆十六进制68、10、16开头的字节串没经验的人对着规约文档翻半天也对不出个人信息体。第二没有真实主站。现场联调往往是从站设备先到货主站还没上线或者主站远在调度中心根本约不到时间配合。想验证设备能不能正确响应总召唤、能不能主动上送遥信变位只能干瞪眼。第三问题难复现。偶发性的通信中断、某个遥测点偶尔跳变靠人肉盯根本盯不住。具体到应用场景这套工具能覆盖的面很广配网自动化终端DTU/FTU/TTU、变电站测控装置、电能采集终端甚至充电桩、光伏并网逆变器这些新型并网设备只要是通过101/104规约上网关的调试的时候都能派上用场。1.2 解析和模拟主站为什么必须成对出现这套工具把报文解析和模拟主站做在一起并不是拍脑袋的拼凑而是调试逻辑决定的。解析工具解决的是“看懂”的问题模拟主站解决的是“驱动”的问题两个缺一不可。举个例子。你在模拟主站里发起一次总召唤终端回了一帧数据单看这帧数据你只知道“有几个字节、里面一堆数字”事情并没有结束。把这帧数据粘贴到解析工具里类型标识、传送原因、公共地址、信息体地址、数值全部列出来你才能确认这个终端的总召唤响应到底对不对。反过来也一样光会解析不会模拟主站那解析谁等终端主动上送吗那不叫调试叫碰运气。所以真正干活的时候正确姿势是模拟主站主动发请求解析工具盯着响应两边一配合问题基本当场就能定位。我选这类工具时最看重的也就是它把两个功能放在同一个界面里省去切换软件的麻烦。市面上也有单独的抓包工具或者解析库但调试效率远不如这种组合式方案。2. 报文解析工具怎么把十六进制“翻译”成人话2.1 101规约先分清固定帧长和可变帧长101规约的帧结构分两种固定帧长和可变帧长。固定帧长以10H开头一共6个字节格式是10H控制域地址域校验和16H这种帧多用于链路控制像召唤一级数据、确认帧、应答帧。可变帧长以68H开头后面的长度字节表示从控制域到校验和之间有多少个字节这种帧用来传业务数据遥测、遥信、遥控都走它。我拿一个最常见的固定帧长报文举例10 49 01 4A 16这是主站召唤从站一级数据的典型帧。10H是启动字符49H是控制域01H是地址域4AH是校验和16H是结束字符。校验和算法很简单控制域和地址域相加49H01H4AH正好等于校验和说明这帧报文校验没问题。这种手工验算用解析工具一点就出来但对规约不熟的人光这个校验和就能卡半天。101的调试里还有个容易忽略的点链路地址域。很多人以为地址域填的是终端地址其实在101里它还承担着区分主站和从站方向的作用。用解析工具的时候工具会直接标出方向但你自己看原始报文时一定要知道同样是地址域01H主站发给从站和从站发给主站的含义不完全一样。2.2 104规约一条总召唤报文逐字节拆给你看104规约没有串口帧那一套起止字符它的最小单位是APDU格式固定启动字符68HAPDU长度控制域4字节ASDU。控制域决定帧类型I帧传输业务数据S帧做确认U帧做启停控制。ASDU里面才是真正的业务内容。我拿一条标准的总召唤报文来做逐字节拆解68 0E 02 00 00 00 64 01 06 00 01 00 00 00 00 1468H启动字符0EHAPDU长度14个字节从控制域到ASDU结尾正好14字节02 00 00 00控制域I帧发送序号1、接收序号064H类型标识100总召唤01H可变结构限定词1个信息体06H传送原因6激活00 01公共地址1注意这里低位在前00 00 00 00信息体地址14H召唤限定词20表示总召唤这套逐字节拆解的方法用解析工具做就是点一下的事但自己会拆一遍对学习104规约帮助很大。工具给你的结果你可能记不住但自己拆过一遍之后再看到68 0E开头的报文下意识就知道这是总召唤还是带数据的I帧。2.3 用解析工具时的三个实操习惯我实际用这类工具的时候有几个习惯分享出来。第一不要在一大堆报文里翻找。先连上设备抓一条关心的报文单独复制到解析窗口里。总召唤的响应可能上千字节全堆在一起根本没法看先按控制域把I帧分出来再按类型标识筛选效率高很多。第二注意字节序。104里公共地址和信息体地址都是低位在前很多人第一次看会看反。总以为高位在前结果按地址对点表怎么都对不上。解析工具一般会自动处理字节序但自己要心里有数尤其当工具显示结果和终端点表对不上时先检查是不是字节序理解错了。第三善用报文模板。工具里一般都有常用报文模板像总召唤、时钟同步、单点遥控、设点命令直接套模板改地址就行不用手敲十六进制。这样能少犯很多低级错误我见过有人手写总召唤帧把长度字节写错了连发三次终端都没反应还以为是设备问题。3. 模拟主站从连接到遥控的完整操作流程3.1 连接前先调对这几项参数模拟主站模块的用法核心就三步配置参数、建立连接、跑测试流程。先看参数配置。104模式要填终端的IP地址和端口号端口默认2404这个几乎不用改还要填公共地址这个必须跟终端里烧录的地址一致否则链路虽然通了ASDU也会被终端直接丢弃。K窗口和W窗口参数一般保持默认除非终端厂家特别强调过否则不要乱动。101模式就简单一些串口号、波特率、数据位、校验位、从站地址这几项对上就行。连接建立这块104和普通TCP直连还不完全一样。TCP三次握手成功之后还要走一遍104的应用层握手主站发STARTDT激活就是U帧68 04 07 00 00 00从站回68 04 0B 00 00 00然后主站才能开始发I帧业务数据。我见过太多人TCP都通了但忘了发STARTDT结果终端那边一点反应都没有还以为是终端坏了。这个坑在解析工具里看得很清楚连接状态一直显示“未激活”但很多人压根不看状态栏。3.2 从总召唤到遥控的标准测试流程连接建立之后我会按一套固定的流程测设备这是这几年跑出厂检验攒下来的习惯总召唤。主站发总召唤终端应该把全部遥测、遥信上送一遍验证数据完整性。时钟同步。发103类型标识的时钟同步报文然后读终端时间确认时间有没有跟上对不上就是时标处理有问题。遥信变位。让现场人员或测试线模拟一个开关变位主站应该收到单点或双点遥信的主动上送传送原因是3突发。遥控。先发选择命令看终端返校再发执行命令看出口有没有动作。设点。如果设备支持遥调发设点命令看终端的定值有没有改过来。这套流程跑完终端的主要功能基本就验得差不多了。每一次操作工具都会在日志里留下原始报文和解析结果后面出问题翻日志就行。我特别建议每一个测试步骤之间稍微停几秒让终端把该上送的报文都送完不要点得太快否则容易把几帧响应混在一起增加分析难度。3.3 遥控两步走别在这上面翻车遥控这块单独拎出来说因为这是最容易翻车的地方。104遥控不是一帧搞定的事而是“选择执行”两步走先发类型标识45的选择命令终端收到后会返校返校内容带选择确认状态确认收到返校后再发类型标识46的执行命令终端执行完再返校一次。每一步都有超时判断好用的工具会直接显示“选择确认”“执行确认”状态简陋一点的只能自己看报文。我在现场踩过的坑是某终端遥控返校总是超时查了半天没发现问题最后才发现是选择报文里信息体地址写错了。终端地址表里那个遥控点从1开始我按习惯写了0终端压根不认这个点。所以填遥控点的时候一定先跟厂家要一份点表核对信息体地址到底是1起始还是0起始。不同厂家的习惯不一样这个坑十个人里至少有三个人会踩。另外遥控测试时最好把终端侧的执行机构断开或者用模拟负载代替。我就见过有人直接在真实开关上做遥控测试结果执行命令一下去开关真动了差点出安全事故。测试软件只是工具现场安全永远要放在第一位。4. 调试高频问题排查与报文分析心得4.1 高频问题排查速查表这几类问题我在多个项目里反复遇到过整理成一张表方便现场出问题时对照。现象可能原因处理方式104 TCP连接不上IP、端口不对或防火墙拦截核对终端IP和2404端口检查网络白名单连接正常但没有数据没发STARTDT激活先发68 04 07 00 00 00确认收到0B后再发业务帧总召唤无响应公共地址不匹配或终端未进入运行状态核对公共地址检查终端运行模式总召唤响应乱码解析窗口字节序设置错误检查工具里公共地址、信息体地址是否按低位在前解析遥信变位不上送终端未开主动上送或变位未被捕获检查终端参数确认突发传送原因3是否使能遥控执行失败选择步骤未确认或信息体地址错误走“选择→返校→执行→返校”完整链路核对点表101链路时断时续串口参数不一致或地址域冲突核对波特率、校验位、从站地址检查总线终端电阻这张表看着简单但每一条背后都是实打实的排障经历。尤其是“连接正常但没有数据”这条我至少帮人远程看过四五次全是STARTDT的问题终端厂商的技术支持一听到“TCP通了但没数据”第一反应也是问这个。4.2 报文分析的三条经验最后聊几条报文分析的心得。第一条先看帧头再看类型标识最后看信息体。不管是101还是104帧头能告诉你这条帧是链路控制还是业务数据类型标识能告诉你它干的是什么业务信息体才是要找的最终数据。按这个顺序看几千字节的报文也能理出头绪。第二条不要只盯着业务数据控制域的收发序号也很关键。104是带确认机制的传输发送序号和接收序号对不上就会出现报文丢失、重复表现形式就是链路时断时续。出这种问题先看序号是否连续再看确认帧有没有按时回来。第三条现场抓到的异常报文一定要保存原始十六进制不要只留解析结果。解析结果是给人看的原始报文才是证据。很多时候厂家远程支持要的就是原始报文你只有解析截图人家也不一定认。这套工具一般都能导出完整日志我习惯每次调试结束把日志按日期和项目名归档后面再出问题直接翻。我在实际调试中养成一个习惯不管问题看起来多简单都让工具把原始报文和解析结果一起存下来。刚开始觉得麻烦后来有次项目验收甲方质疑某个遥测点精度不达标我直接调出当时的报文记录一帧一帧对给人家看问题当场就澄清了。这大概就是一套顺手的101/104测试软件给我最大的感受——它不只是省时间更是让调试过程变得可追溯、可证明。工具再顺手也别忘了把现场数据留存好关键时候能救命。本文还有配套的精品资源点击获取