尧图网站建设 
简介一套面向电力自动化与工业通信工程师的 104 主站仿真调试工具集以客户端软件为核心用于模拟主站、验证子站兼容性、收发遥测遥信报文并排查链路异常。资源共 93 个文件压缩包约 4.18MB主要包含可直接运行的主程序、支撑通信界面与日志的动态库、用于保存场景和通道参数的 xml/pol 配置、记录历史收发过程的 pco 报文以及 PDF 软件使用说明能基本搭建完整的 104 协议调试环境。借助包内多种 104、101 报文样本和配置模板读者可对比学习连接建立、总召、时钟同步等典型交互也可在开发阶段对子站做兼容性测试或用于现场异常快速定位。包内目录按程序、库、配置、报文和文档归位便于快速定位所需模块。目前已有 1411 人学习下载适合刚接触 104 协议的初级工程师也可作为电力系统运维、调试人员的随查参考。1. 项目概述与核心需求解析前阵子项目上需要验证一批新的远动从站设备现场调度主站还没到位光看设备说明书和厂商自测报告心里总不踏实。于是顺手搭了一套104主站仿真软件把链路协商、总召唤、遥信变位、遥控下发这些关键流程全部跑了一遍也算是把IEC 60870-5-104规约从“纸上写的”变成了“实际动的”。这篇文章就聊聊这套主站仿真工具怎么选、怎么配、怎么用以及在调试过程中踩过的那些坑。先解释一个基本概念104规约全称是IEC 60870-5-104是电力系统调度自动化里用于主站与厂站端变电站、RTU、保护装置等之间远动通信的标准规约。它把传统的101规约搬到TCP/IP网络上默认端口2404解决了长距离传输和带宽利用的问题。实际工程里104规约基本是变电站接入调度系统的默认选择所以做电力自动化、系统集成、设备调试的朋友几乎天天要和它打交道。主站仿真软件的核心功能就是在一台普通PC上模拟调度主站侧的行为主动发起TCP连接按规约要求的时序跟从站设备交互包括启动链路、总召唤、时钟同步、接收遥信遥测、下发遥控遥调指令等。有了它在没有真实调度主站的情况下就能把从站设备的数据采集、SOE上报、遥控执行这些功能完整验证一遍。这套工具适合谁来用如果你是做远动设备调试的工程师或者在做变电站自动化系统集成、需要验收第三方RTU或保护装置的通信规约又或者是刚入行想搞懂104规约报文细节的学生都可以照着这篇文章的思路搭一套属于自己的主站仿真环境。不需要多高端的硬件一台Windows电脑、一个网口、一根网线就够了。2. 104规约核心机制速览2.1 APDU结构与三大帧类型104规约的报文结构核心单位叫APDU应用协议数据单元它由APCI应用协议控制信息和ASDU应用服务数据单元组成。APCI在最前面负责传输控制ASDU才是真正携带业务数据的地方。很多初学者一上来就对着报文看懵了其实只要抓住APCI里的那几个关键字节后面的ASDU解析就顺理成章。APCI的构成分两种场景。对于I帧信息帧用于传输应用数据格式是“68 长度 控制域1 控制域2 控制域3 控制域4 ASDU”。其中0x68是启动字符第二个字节是后面的总长度包含控制域和ASDU但不包括0x68和长度字节本身注意这个长度经常有人算错后面排查问题时会重点讲。控制域4个字节里第1和第2字节的低位分别表示发送序号和接收序号每两个字节一组位运算规律后面细说。另外还有两种帧S帧监视帧只有6个字节不携带ASDU专门用来确认接收到的I帧U帧也只有6个字节用于链路控制比如STARTDT启动数据传输、STOPDT停止数据传输、TESTFR测试帧。U帧的格式是“68 04 控制域1 0 0 0”控制域的特定bit位来表示不同命令具体的位操作规则在标准里有明确表格实际使用中对照着填就行。2.2 连接建立与总召唤流程104规约的主从交互最核心的就是建立连接后的启动时序。TCP连接一建立并不是马上就能传数据而是要先进行STARTDT激活握手这个细节特别容易踩坑。具体流程是这样的主站发送U帧的STARTDT act激活请求从站收到后返回STARTDT con确认此时数据传输才算正式激活主站才能下发总召唤命令。很多人在仿真调试时TCP连接是通了但报文发过去从站不回一看抓包原来是漏了STARTDT这一手。总召唤命令是C_IC_NA_1类型标识0x64用I帧发送从站收到后会先回一个确认帧然后逐个上送遥信、遥测数据最后再发一个总召唤结束标志激活终止。仿真主站建议严格按照这个流程走才能验证出从站的真实行为。2.3 信息体地址、公共地址与类型标识再往下拆就是ASDU里的核心字段类型标识、传送原因、公共地址、信息体地址。类型标识决定了这条报文是干什么的比如0x01是单点遥信0x0D是浮点遥测0x2D是单点遥控0x64是总召唤命令。传送原因则标识这条报文的性质常见的有0x06激活、0x07激活确认、0x08停止激活、0x0A激活终止、0x14响应总召唤等。公共地址也常叫站地址就是调度侧给这个厂站分配的地址范围1到65535在TCP链路里是全局有效的。信息体地址则是具体到某个遥信点、遥测点或遥控点的地址它是三个字节的小端表示比如地址4001在报文里就是0xA1 0x0F 0x00。搞清楚了这些字段再去对照报文解析思路会清晰很多。3. 主站仿真软件选型与整体设计3.1 自研脚本和现成工具如何取舍主站仿真软件的选型基本上有三条路。第一是用现成的商业测试软件某些电力仪器厂商会配套出规约测试后台功能全面、界面友好但价格高且不一定允许二次开发。第二是用开源或共享的协议模拟器这类工具适合快速验证但碰到特殊需求比如按自定义顺序循环上送遥测往往会受限。第三就是自己动手写一套用高级语言实现104主站的核心功能灵活度最高也最能帮助你深入理解规约。我当时的选择是“现成工具打底 自研脚本补位”。先用现成的104协议模拟器把基本链路跑通确认对端从站没有硬伤再用自己写的Python脚本针对项目里的特殊点表做自定义测试比如模拟连续变位、按分钟级周期拉遥测、做遥控反校延时等。两套手段互为补充效率比单用任何一种都高。3.2 功能模块划分无论选哪种方案一套像样的104主站仿真软件至少要包含下面几个功能模块连接管理TCP客户端配置支持多IP、多端口、自动重连能手动触发STARTDT激活。报文构造与解析支持常见类型标识的组帧、拆帧能实时显示收发报文的十六进制原始字节和解析后的字段。总召唤与数据轮询一键下发总召唤支持周期性的遥信、遥测类召唤类型标识0x64、0x65等。遥控/遥调操作下发单点或双点遥控能处理选择、执行、撤销三个环节并能解析从站的确认信息。日志与点表映射记录完整交互过程能把信息体地址映射成业务点号方便跟实际测点对应。3.3 关键技术选型与参数考量如果自己写主站脚本语言上我建议用Python理由是生态成熟、网络库方便而且处理十六进制报文非常直观。网络层用标准socket就够不需要额外引入重量级框架。收发线程加一个队列做缓冲主线程负责解析和界面输出即可满足大多数仿真场景。端口号默认是2404这个一般不用改。但有一种情况要注意如果从站前面还有前置机或者防火墙做了端口映射那么在仿真主站里配置的IP和端口必须和最终链路实际映射的地址一致否则会出现TCP能连上但规约报文收不到的情况。这类问题比较隐蔽排查起来费时间建议一开始就确认好网络路径。4. 主站仿真软件的实操过程与核心环节实现4.1 从零搭建一个最小化仿真主站下面以自研Python主站为例给大家一个能直接跑的骨架。我自己的代码结构是四个文件主程序、协议栈组帧拆帧、连接管理、测试用例。这里给出核心的链路激活和总召唤代码片段。import socket import struct import time def build_u_frame(cmd): # cmd: 0x07 STARTDT act, 0x0B STARTDT con, 0x13 STOPDT act, 0x83 TESTFR act return bytes([0x68, 0x04, cmd, 0x00, 0x00, 0x00]) def build_i_frame(send_seq, recv_seq, asdu): # send_seq和recv_seq是实际计数值需要左移1位bit0置0 ctrl1 (send_seq 1) 0xFF ctrl2 ((send_seq 1) 8) 0xFF ctrl3 (recv_seq 1) 0xFF ctrl4 ((recv_seq 1) 8) 0xFF length 4 len(asdu) return bytes([0x68, length, ctrl1, ctrl2, ctrl3, ctrl4]) asdu sock socket.socket(socket.AF_INET, socket.SOCK_STREAM) sock.connect((192.168.1.10, 2404)) # 1. 启动数据传输 sock.send(build_u_frame(0x07)) resp sock.recv(255) # 正常应收到 68 04 0B 00 00 00 print(STARTDT con:, resp.hex())这段代码里build_u_frame和build_i_frame是两个最基本的组帧函数。特别注意I帧的序号处理发送序号和接收序号都要左移一位再填充到控制域里因为第0位固定是0这是规约明确规定的。如果你在某一天发现对端一直不回I帧先检查一下序号是不是写错了这个问题在自定义实现里出现概率非常高。4.2 总召唤流程实现细节链路激活完成后紧接着就发总召唤。总召唤的ASDU构造相对固定类型标识0x64传送原因0x06公共地址用2字节小端信息体地址是0x000000三字节。把一个完整的总召唤报文放出来参考68 0E 02 00 00 00 64 01 06 00 01 00 00 00 00 00拆解一下68是启动字符0E十进制14表示后面总共14个字节02 00 00 00是I帧控制域表明发送序号为1、接收序号为064是类型标识总召唤01是ASDU中信息体数目此处只有一个06 00是传送原因激活01 00是公共地址小端表示地址1后面的00 00 00是信息体地址最后的00是总召唤限定词表示“站总召唤”。整个报文要组对一个字节都不能错。发完总召唤从站会先回一个“激活确认”传送原因0x07然后开始上送数据。等它上送完所有遥测遥信会再发一个“激活终止”传送原因0x0A的帧代表这一轮总召唤结束。仿真主站眼里收到激活终止才算一轮完整的总召唤完成。如果只收到中间数据没等到激活终止说明从站可能还有数据没上送完或者上送逻辑本身有异常。4.3 遥控指令的报文构造与处理流程遥控操作是现场最容易出问题的环节因为涉及选择、执行、撤销三个子步骤而且每一步都要有对应的确认。以单点遥控类型标识0x2D为例选择的报文格式是68 0E 02 00 00 00 2D 01 06 00 01 00 01 60 00 01注意看信息体地址是0x6001这里为演示方便取了0x000160的小端表示实际按点表填最后一位是遥控命令状态0x01表示合闸0x00表示分闸0x02表示选择命令的限定词组合。选择命令的传送原因是0x06激活从站如果允许操作会回一个传送原因0x07的确认帧。选择确认后主站再下执行命令传送原因同样是0x06但信息体地址最后一个字节要带上执行限定词。整个过程中从站如果在选择后规定时间内没收到执行命令会自动撤销主站也会收到一个带撤销标识的帧。仿真软件在处理遥控时一定要实现超时监听的逻辑不然会把撤销帧误判为执行成功。5. 常见问题与排查技巧实录5.1 连接正常但报文无回应的排查顺序这类问题占了调试工作的七成以上。我的排查顺序几乎固定先TCP层再规约层。TCP能用ping通、telnet端口能连上只能说明网络通不代表规约层没问题如果TCP都连不上就看地址、掩码、防火墙。规约层最常见的原因有三个没做STARTDT激活、I帧序号对不上、公共地址不匹配。其中公共地址不匹配最为隐蔽——从站收到的报文公共地址不是自己站的地址它连确认帧都不会回你在主站侧看就是“发送超时”玻璃心一点的工程师就开始怀疑网线了。5.2 长度计算错误导致的解析错位104报文里0x68后面的长度字节指的是从控制域第一个字节开始到整个报文结束的所有字节数。很多人习惯性以为这个长度是“ASDU长度”或者“总长度减2”结果就错了。比如完整总召唤报文“68 0E 02 00 00 00 64 01 06 00 01 00 00 00 00 00”总共16个字节0x68和0x0E不算进0E0x0E等于后面14个字节。如果填成0x1016对端解析的时候会把下一条报文的前两个字节吞掉后续报文全部错位表现出来就是交互完全混乱。遇到这种情况抓包看十六进制原始字节十秒钟就能定位。5.3 序号不匹配与重复帧处理I帧序号是收发双方各自维护的发送序号和接收序号分别独立。有一种典型错误是接收方已经收到了序号为0的帧但发送方因为超时重发重发帧还是序号0如果发送方没有正确递增序号接收方会按照“重复帧”处理可能直接丢弃。仿真主站需要维护好本地发送计数器和接收计数器每发一个I帧发送序号加1每收一个I帧接收序号加1。有些从站设备对重复序号的处理并不一样有的直接忽略有的一定会回一个S帧确认但业务数据不会重复处理。搞清楚对端设备的这一特性可以避免很多误判。5.4 虚拟机和本机仿真环境的网络注意事项有些人喜欢在虚拟机里跑Linux再用Docker起仿真服务这本身没问题但要注意虚拟网卡的MAC地址漂移会影响TCP连接稳定性。另外如果在同一台电脑上同时跑主站仿真和从站模拟器一定要用真实网卡的IP不要用127.0.0.1因为有些协议库对loopback地址的处理和物理网卡不一致可能导致收包异常。我在实验环境里遇到过一次VirtualBox虚拟机网络配置出错导致通信中断的情况后来直接换回物理机跑仿真问题立刻消失。因此在排查诡异通信故障时先简化网络环境往往是最快的解决路径。5.5 常用问题速查表故障现象可能原因快速排查方法TCP端口连不上从站未启动、防火墙拦截、IP配置错telnet从站IP 2404不通则逐层查网络连上后发任何报文无回应未进行STARTDT激活或公共地址不匹配先发U帧STARTDT act再核对公共地址总召唤只有部分数据总召唤过程中链路断开或序号错乱抓包看序号是否连续重发总召唤总召唤收不到激活终止从站上送逻辑异常或数据量过大等待更长时间检查从站测点表配置遥控执行后无确认未走选择流程或限定词不对核对选择帧的限定词确认从站支持的功能报文能收到但解析乱码长度字节错误或字节序理解错从0x68开始逐字节核对原始报文6. 一版更贴近现场的扩展思路如果你的104主站仿真软件已经能稳定完成链路激活、总召唤、遥控这几个基础动作我建议再往上叠两个实战功能。第一个是模拟多变位场景即按时间序列连续触发一批遥信变位验证从站的上送时序是否正确这在大批量测点联调时尤其有用第二个是配合GPS或对时报文做网络对时验证检验从站的时间同步机制这直接关系到故障录波和SOE时标的准确性。有一点必须单独拿出来提104规约虽然标准统一但不同厂商的实现细节会有差异。有的从站在收到总召唤后会以极快的速度把所有点一次性上送有的则会在中间插入多个S帧确认还有的在收到执行命令后会回复两次确认帧。作为仿真主站我们要做的不是抱怨对端“不合规”而是想办法让仿真工具兼容这些差异。合理设置接收超时、支持半自动确认模式、允许手动调整发送序号起始值这些功能看着不起眼实际联调时却能省下大量时间。7. 实操中的个人体会我在实际搭建和使用104主站仿真软件的过程中最大的感受是“规约串通了设备就看透了”。一开始总想着找各种高大上的测试平台折腾下来发现真正可靠的反而是自己一行一行写出来的那套脚本。它能让我在出问题时随手加日志、随手改逻辑不用等着厂商售后响应。最后再分享一个小技巧无论你用的是现成工具还是自研脚本一定要把每个收发报文的原始十六进制数据完整记到日志里。很多看似诡异的问题比如偶然丢失的一帧、多出来的一帧S帧确认事后回看十六进制日志都能找到规律。有了这份日志你在跟从站厂商或调度主站团队对接时沟通效率会高出一个量级。本文还有配套的精品资源点击获取 104主站仿真工具实战：从链路激活到总召唤与遥控调试
简介一套面向电力自动化与工业通信工程师的 104 主站仿真调试工具集以客户端软件为核心用于模拟主站、验证子站兼容性、收发遥测遥信报文并排查链路异常。资源共 93 个文件压缩包约 4.18MB主要包含可直接运行的主程序、支撑通信界面与日志的动态库、用于保存场景和通道参数的 xml/pol 配置、记录历史收发过程的 pco 报文以及 PDF 软件使用说明能基本搭建完整的 104 协议调试环境。借助包内多种 104、101 报文样本和配置模板读者可对比学习连接建立、总召、时钟同步等典型交互也可在开发阶段对子站做兼容性测试或用于现场异常快速定位。包内目录按程序、库、配置、报文和文档归位便于快速定位所需模块。目前已有 1411 人学习下载适合刚接触 104 协议的初级工程师也可作为电力系统运维、调试人员的随查参考。1. 项目概述与核心需求解析前阵子项目上需要验证一批新的远动从站设备现场调度主站还没到位光看设备说明书和厂商自测报告心里总不踏实。于是顺手搭了一套104主站仿真软件把链路协商、总召唤、遥信变位、遥控下发这些关键流程全部跑了一遍也算是把IEC 60870-5-104规约从“纸上写的”变成了“实际动的”。这篇文章就聊聊这套主站仿真工具怎么选、怎么配、怎么用以及在调试过程中踩过的那些坑。先解释一个基本概念104规约全称是IEC 60870-5-104是电力系统调度自动化里用于主站与厂站端变电站、RTU、保护装置等之间远动通信的标准规约。它把传统的101规约搬到TCP/IP网络上默认端口2404解决了长距离传输和带宽利用的问题。实际工程里104规约基本是变电站接入调度系统的默认选择所以做电力自动化、系统集成、设备调试的朋友几乎天天要和它打交道。主站仿真软件的核心功能就是在一台普通PC上模拟调度主站侧的行为主动发起TCP连接按规约要求的时序跟从站设备交互包括启动链路、总召唤、时钟同步、接收遥信遥测、下发遥控遥调指令等。有了它在没有真实调度主站的情况下就能把从站设备的数据采集、SOE上报、遥控执行这些功能完整验证一遍。这套工具适合谁来用如果你是做远动设备调试的工程师或者在做变电站自动化系统集成、需要验收第三方RTU或保护装置的通信规约又或者是刚入行想搞懂104规约报文细节的学生都可以照着这篇文章的思路搭一套属于自己的主站仿真环境。不需要多高端的硬件一台Windows电脑、一个网口、一根网线就够了。2. 104规约核心机制速览2.1 APDU结构与三大帧类型104规约的报文结构核心单位叫APDU应用协议数据单元它由APCI应用协议控制信息和ASDU应用服务数据单元组成。APCI在最前面负责传输控制ASDU才是真正携带业务数据的地方。很多初学者一上来就对着报文看懵了其实只要抓住APCI里的那几个关键字节后面的ASDU解析就顺理成章。APCI的构成分两种场景。对于I帧信息帧用于传输应用数据格式是“68 长度 控制域1 控制域2 控制域3 控制域4 ASDU”。其中0x68是启动字符第二个字节是后面的总长度包含控制域和ASDU但不包括0x68和长度字节本身注意这个长度经常有人算错后面排查问题时会重点讲。控制域4个字节里第1和第2字节的低位分别表示发送序号和接收序号每两个字节一组位运算规律后面细说。另外还有两种帧S帧监视帧只有6个字节不携带ASDU专门用来确认接收到的I帧U帧也只有6个字节用于链路控制比如STARTDT启动数据传输、STOPDT停止数据传输、TESTFR测试帧。U帧的格式是“68 04 控制域1 0 0 0”控制域的特定bit位来表示不同命令具体的位操作规则在标准里有明确表格实际使用中对照着填就行。2.2 连接建立与总召唤流程104规约的主从交互最核心的就是建立连接后的启动时序。TCP连接一建立并不是马上就能传数据而是要先进行STARTDT激活握手这个细节特别容易踩坑。具体流程是这样的主站发送U帧的STARTDT act激活请求从站收到后返回STARTDT con确认此时数据传输才算正式激活主站才能下发总召唤命令。很多人在仿真调试时TCP连接是通了但报文发过去从站不回一看抓包原来是漏了STARTDT这一手。总召唤命令是C_IC_NA_1类型标识0x64用I帧发送从站收到后会先回一个确认帧然后逐个上送遥信、遥测数据最后再发一个总召唤结束标志激活终止。仿真主站建议严格按照这个流程走才能验证出从站的真实行为。2.3 信息体地址、公共地址与类型标识再往下拆就是ASDU里的核心字段类型标识、传送原因、公共地址、信息体地址。类型标识决定了这条报文是干什么的比如0x01是单点遥信0x0D是浮点遥测0x2D是单点遥控0x64是总召唤命令。传送原因则标识这条报文的性质常见的有0x06激活、0x07激活确认、0x08停止激活、0x0A激活终止、0x14响应总召唤等。公共地址也常叫站地址就是调度侧给这个厂站分配的地址范围1到65535在TCP链路里是全局有效的。信息体地址则是具体到某个遥信点、遥测点或遥控点的地址它是三个字节的小端表示比如地址4001在报文里就是0xA1 0x0F 0x00。搞清楚了这些字段再去对照报文解析思路会清晰很多。3. 主站仿真软件选型与整体设计3.1 自研脚本和现成工具如何取舍主站仿真软件的选型基本上有三条路。第一是用现成的商业测试软件某些电力仪器厂商会配套出规约测试后台功能全面、界面友好但价格高且不一定允许二次开发。第二是用开源或共享的协议模拟器这类工具适合快速验证但碰到特殊需求比如按自定义顺序循环上送遥测往往会受限。第三就是自己动手写一套用高级语言实现104主站的核心功能灵活度最高也最能帮助你深入理解规约。我当时的选择是“现成工具打底 自研脚本补位”。先用现成的104协议模拟器把基本链路跑通确认对端从站没有硬伤再用自己写的Python脚本针对项目里的特殊点表做自定义测试比如模拟连续变位、按分钟级周期拉遥测、做遥控反校延时等。两套手段互为补充效率比单用任何一种都高。3.2 功能模块划分无论选哪种方案一套像样的104主站仿真软件至少要包含下面几个功能模块连接管理TCP客户端配置支持多IP、多端口、自动重连能手动触发STARTDT激活。报文构造与解析支持常见类型标识的组帧、拆帧能实时显示收发报文的十六进制原始字节和解析后的字段。总召唤与数据轮询一键下发总召唤支持周期性的遥信、遥测类召唤类型标识0x64、0x65等。遥控/遥调操作下发单点或双点遥控能处理选择、执行、撤销三个环节并能解析从站的确认信息。日志与点表映射记录完整交互过程能把信息体地址映射成业务点号方便跟实际测点对应。3.3 关键技术选型与参数考量如果自己写主站脚本语言上我建议用Python理由是生态成熟、网络库方便而且处理十六进制报文非常直观。网络层用标准socket就够不需要额外引入重量级框架。收发线程加一个队列做缓冲主线程负责解析和界面输出即可满足大多数仿真场景。端口号默认是2404这个一般不用改。但有一种情况要注意如果从站前面还有前置机或者防火墙做了端口映射那么在仿真主站里配置的IP和端口必须和最终链路实际映射的地址一致否则会出现TCP能连上但规约报文收不到的情况。这类问题比较隐蔽排查起来费时间建议一开始就确认好网络路径。4. 主站仿真软件的实操过程与核心环节实现4.1 从零搭建一个最小化仿真主站下面以自研Python主站为例给大家一个能直接跑的骨架。我自己的代码结构是四个文件主程序、协议栈组帧拆帧、连接管理、测试用例。这里给出核心的链路激活和总召唤代码片段。import socket import struct import time def build_u_frame(cmd): # cmd: 0x07 STARTDT act, 0x0B STARTDT con, 0x13 STOPDT act, 0x83 TESTFR act return bytes([0x68, 0x04, cmd, 0x00, 0x00, 0x00]) def build_i_frame(send_seq, recv_seq, asdu): # send_seq和recv_seq是实际计数值需要左移1位bit0置0 ctrl1 (send_seq 1) 0xFF ctrl2 ((send_seq 1) 8) 0xFF ctrl3 (recv_seq 1) 0xFF ctrl4 ((recv_seq 1) 8) 0xFF length 4 len(asdu) return bytes([0x68, length, ctrl1, ctrl2, ctrl3, ctrl4]) asdu sock socket.socket(socket.AF_INET, socket.SOCK_STREAM) sock.connect((192.168.1.10, 2404)) # 1. 启动数据传输 sock.send(build_u_frame(0x07)) resp sock.recv(255) # 正常应收到 68 04 0B 00 00 00 print(STARTDT con:, resp.hex())这段代码里build_u_frame和build_i_frame是两个最基本的组帧函数。特别注意I帧的序号处理发送序号和接收序号都要左移一位再填充到控制域里因为第0位固定是0这是规约明确规定的。如果你在某一天发现对端一直不回I帧先检查一下序号是不是写错了这个问题在自定义实现里出现概率非常高。4.2 总召唤流程实现细节链路激活完成后紧接着就发总召唤。总召唤的ASDU构造相对固定类型标识0x64传送原因0x06公共地址用2字节小端信息体地址是0x000000三字节。把一个完整的总召唤报文放出来参考68 0E 02 00 00 00 64 01 06 00 01 00 00 00 00 00拆解一下68是启动字符0E十进制14表示后面总共14个字节02 00 00 00是I帧控制域表明发送序号为1、接收序号为064是类型标识总召唤01是ASDU中信息体数目此处只有一个06 00是传送原因激活01 00是公共地址小端表示地址1后面的00 00 00是信息体地址最后的00是总召唤限定词表示“站总召唤”。整个报文要组对一个字节都不能错。发完总召唤从站会先回一个“激活确认”传送原因0x07然后开始上送数据。等它上送完所有遥测遥信会再发一个“激活终止”传送原因0x0A的帧代表这一轮总召唤结束。仿真主站眼里收到激活终止才算一轮完整的总召唤完成。如果只收到中间数据没等到激活终止说明从站可能还有数据没上送完或者上送逻辑本身有异常。4.3 遥控指令的报文构造与处理流程遥控操作是现场最容易出问题的环节因为涉及选择、执行、撤销三个子步骤而且每一步都要有对应的确认。以单点遥控类型标识0x2D为例选择的报文格式是68 0E 02 00 00 00 2D 01 06 00 01 00 01 60 00 01注意看信息体地址是0x6001这里为演示方便取了0x000160的小端表示实际按点表填最后一位是遥控命令状态0x01表示合闸0x00表示分闸0x02表示选择命令的限定词组合。选择命令的传送原因是0x06激活从站如果允许操作会回一个传送原因0x07的确认帧。选择确认后主站再下执行命令传送原因同样是0x06但信息体地址最后一个字节要带上执行限定词。整个过程中从站如果在选择后规定时间内没收到执行命令会自动撤销主站也会收到一个带撤销标识的帧。仿真软件在处理遥控时一定要实现超时监听的逻辑不然会把撤销帧误判为执行成功。5. 常见问题与排查技巧实录5.1 连接正常但报文无回应的排查顺序这类问题占了调试工作的七成以上。我的排查顺序几乎固定先TCP层再规约层。TCP能用ping通、telnet端口能连上只能说明网络通不代表规约层没问题如果TCP都连不上就看地址、掩码、防火墙。规约层最常见的原因有三个没做STARTDT激活、I帧序号对不上、公共地址不匹配。其中公共地址不匹配最为隐蔽——从站收到的报文公共地址不是自己站的地址它连确认帧都不会回你在主站侧看就是“发送超时”玻璃心一点的工程师就开始怀疑网线了。5.2 长度计算错误导致的解析错位104报文里0x68后面的长度字节指的是从控制域第一个字节开始到整个报文结束的所有字节数。很多人习惯性以为这个长度是“ASDU长度”或者“总长度减2”结果就错了。比如完整总召唤报文“68 0E 02 00 00 00 64 01 06 00 01 00 00 00 00 00”总共16个字节0x68和0x0E不算进0E0x0E等于后面14个字节。如果填成0x1016对端解析的时候会把下一条报文的前两个字节吞掉后续报文全部错位表现出来就是交互完全混乱。遇到这种情况抓包看十六进制原始字节十秒钟就能定位。5.3 序号不匹配与重复帧处理I帧序号是收发双方各自维护的发送序号和接收序号分别独立。有一种典型错误是接收方已经收到了序号为0的帧但发送方因为超时重发重发帧还是序号0如果发送方没有正确递增序号接收方会按照“重复帧”处理可能直接丢弃。仿真主站需要维护好本地发送计数器和接收计数器每发一个I帧发送序号加1每收一个I帧接收序号加1。有些从站设备对重复序号的处理并不一样有的直接忽略有的一定会回一个S帧确认但业务数据不会重复处理。搞清楚对端设备的这一特性可以避免很多误判。5.4 虚拟机和本机仿真环境的网络注意事项有些人喜欢在虚拟机里跑Linux再用Docker起仿真服务这本身没问题但要注意虚拟网卡的MAC地址漂移会影响TCP连接稳定性。另外如果在同一台电脑上同时跑主站仿真和从站模拟器一定要用真实网卡的IP不要用127.0.0.1因为有些协议库对loopback地址的处理和物理网卡不一致可能导致收包异常。我在实验环境里遇到过一次VirtualBox虚拟机网络配置出错导致通信中断的情况后来直接换回物理机跑仿真问题立刻消失。因此在排查诡异通信故障时先简化网络环境往往是最快的解决路径。5.5 常用问题速查表故障现象可能原因快速排查方法TCP端口连不上从站未启动、防火墙拦截、IP配置错telnet从站IP 2404不通则逐层查网络连上后发任何报文无回应未进行STARTDT激活或公共地址不匹配先发U帧STARTDT act再核对公共地址总召唤只有部分数据总召唤过程中链路断开或序号错乱抓包看序号是否连续重发总召唤总召唤收不到激活终止从站上送逻辑异常或数据量过大等待更长时间检查从站测点表配置遥控执行后无确认未走选择流程或限定词不对核对选择帧的限定词确认从站支持的功能报文能收到但解析乱码长度字节错误或字节序理解错从0x68开始逐字节核对原始报文6. 一版更贴近现场的扩展思路如果你的104主站仿真软件已经能稳定完成链路激活、总召唤、遥控这几个基础动作我建议再往上叠两个实战功能。第一个是模拟多变位场景即按时间序列连续触发一批遥信变位验证从站的上送时序是否正确这在大批量测点联调时尤其有用第二个是配合GPS或对时报文做网络对时验证检验从站的时间同步机制这直接关系到故障录波和SOE时标的准确性。有一点必须单独拿出来提104规约虽然标准统一但不同厂商的实现细节会有差异。有的从站在收到总召唤后会以极快的速度把所有点一次性上送有的则会在中间插入多个S帧确认还有的在收到执行命令后会回复两次确认帧。作为仿真主站我们要做的不是抱怨对端“不合规”而是想办法让仿真工具兼容这些差异。合理设置接收超时、支持半自动确认模式、允许手动调整发送序号起始值这些功能看着不起眼实际联调时却能省下大量时间。7. 实操中的个人体会我在实际搭建和使用104主站仿真软件的过程中最大的感受是“规约串通了设备就看透了”。一开始总想着找各种高大上的测试平台折腾下来发现真正可靠的反而是自己一行一行写出来的那套脚本。它能让我在出问题时随手加日志、随手改逻辑不用等着厂商售后响应。最后再分享一个小技巧无论你用的是现成工具还是自研脚本一定要把每个收发报文的原始十六进制数据完整记到日志里。很多看似诡异的问题比如偶然丢失的一帧、多出来的一帧S帧确认事后回看十六进制日志都能找到规律。有了这份日志你在跟从站厂商或调度主站团队对接时沟通效率会高出一个量级。本文还有配套的精品资源点击获取