尧图网页设计 
简介在电力自动化通信调试中IEC 104主站仿真软件是验证子站设备与协议实现的重要工具。这款软件包主要面向电力系统运维工程师、104协议开发者和测试人员用于模拟主站功能完成遥测、遥信、遥控等报文的发送与解析帮助排查通信链路故障、验证设备兼容性并可模拟异常场景辅助故障定位。包体共93个文件以ProIEC104Client.exe主程序、dll动态库、xml配置文件、pco历史报文记录和pol报文模板为主整体大小仅4.18MB并附带详细的PDF使用说明与示例报文可快速上手。目前已有1411人学习下载既适用于设备开发阶段的功能验证也适合现场调试和协议学习等场景。通过该工具使用者可以自由构造并发送各类104报文实时观察子站响应校验报文正确性从而大幅提升协议调试效率为电力系统稳定通信提供技术保障。 我最早接触104主站仿真软件是在一个从站设备调试的现场。当时手里的远动装置没有真实调度主站可连只能靠PC端的仿真软件扮演主站角色一遍遍发总召、收遥测、试遥控。那一刻我才意识到搞104规约的联调手里有一款趁手的主站仿真软件比堆什么文档都管用。这篇博文就围绕104主站仿真软件展开它到底仿真的是什么、协议底层有哪些必须搞懂的细节、怎么自己搭建一套可用的仿真环境以及联调过程中常见的那些坑。适合电力自动化调试工程师、SCADA开发人员以及刚接触IEC 60870-5-104规约的入门者。1. 项目概览104主站仿真软件到底在仿什么1.1 先从104规约的两个角色说起IEC 60870-5-104规约以下简称104规约是基于TCP/IP的远动规约在电力调度自动化里几乎是标配。它把通信双方分成主站和从站主站是调度端或者集控中心从站是变电站里的远动装置、测控装置或RTU。从站负责采集现场的遥测、遥信数据主站负责下发遥控、遥调命令。通信关系上主站作为TCP客户端主动发起连接从站作为TCP服务端监听2404端口。连接建立后主站发送STARTDT激活帧从站确认后双方才开始传数据。整个交互过程很像一个“老板”和一个“员工”的对话老板问“汇报一下情况”员工开始上报数据老板说“把3号开关合上”员工执行后回复“已执行”。104主站仿真软件本质上就是把这个“老板”角色装进PC里用软件模拟调度主站的完整行为。它能替代真实主站去连接从站设备也能模拟主站侧的报文交互逻辑用来验证、测试、培训。1.2 哪些场景会让它成为刚需场景一最典型子站侧调试。远动装置或测控装置在现场安装完需要验证104通信参数、点表映射、报文打包是否正确。这时候大概率没有真实调度主站可连或者调度主站还在建设期。用104主站仿真软件直接按IP和端口连接从站设备下总召、看数据、发遥控问题定位效率能提升一大截。场景二在主站侧开发测试。SCADA系统在开发阶段需要模拟大量从站数据来验证主站画面、告警、遥控流程。这时候光靠真实设备不现实要么用从站模拟器灌数据要么在仿真主站软件里做报文回放和压力测试。场景三是培训。刚入行的同事对104规约不熟悉直接在真实系统上操作风险大用仿真软件发几个报文、解析几帧数据很快就能建立起直观认识。所以104主站仿真软件解决的从来不是“有没有设备”的问题而是“在没有真实主站的情况下如何把通信链路和功能逻辑验证到位”的问题。它是调试工具更是一个理解规约的窗口。2. 核心细节104规约帧结构与数据类型拆解2.1 拆一帧报文搞懂APDU结构要用好仿真软件先得能看懂报文。104规约的报文单位叫APDU格式固定启动字符0x68、APDU长度1字节、控制域2到4字节、ASDU信息体可选的。控制域决定帧类型有三大类I帧信息帧用于传输ASDU控制域4字节带发送序号N(S)和接收序号N(R)。bit0为0。S帧确认帧只确认接收序号不携带ASDU控制域2字节。bit0为1、bit1为0。U帧控制帧用于启动、停止、测试链路控制域2字节。bit0和bit1都为1。实际抓包最常见的就是这几条主站 - 从站: 68 04 07 00 00 00 # STARTDT激活 从站 - 主站: 68 04 0B 00 00 00 # STARTDT确认 主站 - 从站: 68 0E 00 00 00 00 64 01 06 00 01 00 00 00 00 14 # 总召最后一条的总召报文长度0x0E表示后面还有14字节控制域四个0表示N(S)0、N(R)0ASDU里0x64是类型标识100对应总召C_IC_NA0x01是可变结构限定词表示一个信息体0x0600是传送原因6表示激活0x0100是公共地址1再往后是三字节信息体地址000000最后0x14是召唤限定词QOI20表示站召唤。这一帧发出去从站就会开始全数据上送。很多人在仿真软件里调不通就是没搞懂I帧的序号规则。I帧的发送序号和接收序号是累加的每发一个I帧N(S)1每收到一个I帧N(R)对方已收到的N(S)1。如果序号不对从站可能不回包或者直接链路复位。2.2 常用的ASDU类型与点表设计ASDU是104报文的“正文”由类型标识、可变结构限定词、传送原因、公共地址、信息体地址、信息体元素组成。主站仿真软件里最常用到的类型标识有这些类型标识名称方向用途1M_SP_NA从站-主站单点遥信3M_DP_NA从站-主站双点遥信11M_ME_NB从站-主站带品质描述的归一化遥测13M_ME_NC从站-主站带品质描述的短浮点遥测45C_SC_NA主站-从站单点遥控46C_DC_NA主站-从站双点遥控100C_IC_NA主站-从站总召唤传送原因也要记住几个关键值1是周期上送3是突发上送6是激活7是激活确认10是激活终止20是响应站召唤。很多报文看起来一样但传送原因不同含义完全不同。比如总召后从站批量上送的遥测传送原因往往是20不是3。信息体地址在104规约中是3字节低字节在前。它对应到现场实际测点就是“点表”的概念。仿真软件里要维护一张映射表把信息体地址翻译成“1号主变有功”“110kV线路开关位置”这样的可读名称。联调现场最常见的调试点就是确认从站的测点地址和主站期望的地址是否一致。地址对不上数据上来了也是错位画面全是乱码。3. 实操搭建一套可用的104主站仿真环境3.1 选现成工具还是自己写脚本我刚接触104主站仿真的时候也是到处找现成软件。市面上确实有一些商业的规约调试工具功能全界面友好支持遥测遥信遥脉搏的展示但普遍不便宜而且有些对非标点表的兼容性一般。还有一些开源库比如lib60870、Java的j60870以及Python生态里的相关实现都能作为二次开发基础。如果拿不定主意可以参考这个对比方案上手难度灵活性适用场景商业仿真软件低中现场快速调试、培训演示开源库二次开发中高定制协议逻辑、批量自动化测试Python脚本手搓偏高极高深度联调、协议学习、特殊场景我的建议是现场抢时间先用现成工具打通链路后续要做自动化回归测试再考虑用Python脚本做一套自己的主站模拟器。原因很简单现成工具能让你快速看到结果但理解不深自己写脚本的过程才是真正把104规约吃透的过程。3.2 手搓一个最小可用的主站仿真器以下是一个基于Python socket的最小主站仿真核心代码目标是连接从站、激活链路、发送总召、接收一帧数据并打印。import socket import struct import time HOST 192.168.1.100 # 从站IP PORT 2404 def u_frame(cmd): # U帧: 68 04 命令 00 00 00 return bytes([0x68, 0x04, cmd, 0x00, 0x00, 0x00]) def i_frame(send_seq, recv_seq, asdu): # I帧: 68 长度 控制域4字节 ASDU c1 ((send_seq 0x7f) 1) c2 (send_seq 7) 0xff c3 ((recv_seq 0x7f) 1) c4 (recv_seq 7) 0xff apci bytes([0x68, 4 len(asdu), c1, c2, c3, c4]) return apci asdu def build_interrogation(ca): # 总召: 类型100, VSQ1, COT6(激活), CA站地址, IOA0, QOI20 asdu bytes([0x64, 0x01, 0x06, 0x00]) struct.pack(H, ca) bytes([0x00, 0x00, 0x00, 0x14]) return asdu sock socket.socket(socket.AF_INET, socket.SOCK_STREAM) sock.connect((HOST, PORT)) # 1. 启动链路 sock.send(u_frame(0x07)) # STARTDT激活 resp sock.recv(256) print(STARTDT确认:, resp.hex()) # 2. 发送总召 send_seq 0 recv_seq 0 asdu build_interrogation(ca1) sock.send(i_frame(send_seq, recv_seq, asdu)) send_seq 1 print(已发送总召) # 3. 接收数据并解析 while True: data sock.recv(4096) if not data: break print(收到报文:, data.hex()) # 这里可根据类型标识进一步解析ASDU if data[0] 0x68 and len(data) 6: type_id data[6] print(类型标识:, type_id) time.sleep(0.5)这段代码能跑通一个最简流程连接从站、启动链路、发总召、收数据。实际项目中还需要处理粘包拆包、序号确认、超时重传、测试帧应答但这些逻辑在联调初期可以先不写先把链路打通看到数据再逐步完善。注意很多从站设备只允许一个TCP连接。如果调试时发现连上了又被踢掉检查是不是有其他调试软件占用了连接。这是现场非常常见的问题。3.3 扩展周期召唤与遥控命令最小仿真器跑通后下一步就是扩展功能。最常用的是周期召唤和遥控下发。周期召唤可以在循环里定时发送总召I帧每次发送前N(S)1收到数据后N(R)更新。主站仿真软件里这类定时任务要和收发线程分开否则接收会被发送阻塞。遥控命令的构造也不复杂。单点遥控C_SC_NA类型45的信息体元素是SCO一个字节bit0为命令值0分、1合bit7是选择/执行标志。直接执行时通常发0x00或0x01。双点遥控C_DC_NA类型46的DCO字节bit0-1表示命令状态常用0x01分、0x02合bit6-7表示选择/执行。整个报文的ASDU格式和总召类似只是类型标识不同信息体地址换成对应的遥控点号信息体元素换成SCO或DCO字节。发完遥控后从站会先回一帧传输原因7激活确认表示收到命令执行完成后返回传输原因10激活终止。在主站仿真软件里如果只收到确认没有收到终止就要考虑是不是执行环节出了问题比如闭锁条件不满足、操作权限不对。4. 实战踩坑联调中常见的8个问题4.1 连接层连不上、被踢掉、地址不对104联调第一个坎就是TCP连接。从站IP、端口2404、网络通不通这三项定了才能往下走。常见问题有从站配置成了客户端模式等着主站当服务端导致连接失败防火墙挡了2404端口从站同时只允许一个连接被其他调试工具占用了。还有一个容易被忽略的是公共地址站地址。104规约里的公共地址是2字节低字节在前。仿真主站里填的公共地址必须和从站配置一致。不一致时从站收到总召可能直接丢弃或回复不明确表现为主站侧“发送正常但没有任何返回”。我见过不少人在这个字段上栽跟头因为工具默认公共地址是1而现场远动装置配置的是21。4.2 报文层长度、序号、品质位报文层面的问题更隐蔽。一个是粘包拆包从站可能一次TCP报文里带好几帧APDU如果仿真软件没有做缓存和按长度字段拆包解析就会错乱。另一个是序号错乱主站发了I帧后没等确认就继续狂发超过从站接收窗口k默认12从站会断开链路。品质位也是调试高频点。104遥信信息体元素里有品质描述bit7可能是无效位IVbit4可能是封锁位BL。如果从站上送的遥信品质位是0x80或0x10主站仿真软件里显示的数值虽然能出来但状态可能是“无效”或“封锁”。很多现场“数据上来了但不刷新”的怪问题最后都出在品质位上。建议联调时把每帧的品质位打印出来看。4.3 心跳与超时别让链路悄悄断了104规约有一套链路保活机制t0是连接超时t1是发送或测试超时t2是接收确认超时t3是测试帧周期。默认值分别是30秒、15秒、10秒、20秒。主站仿真软件必须在t3时间内发测试帧TESTFR探活如果链路长时间没数据仿真软件还在干等从站可能已经把链路超时释放了。如果你发现仿真软件界面显示连接正常但发任何命令都没反应大概率是链路已经死了软件没检测到。好的仿真软件应该能主动发送TESTFR帧收到TESTFR确认后再继续。自己写脚本时这个逻辑一定要加进去否则模拟主站就是个“假连接”。一点个人体会用了这么久的104主站仿真软件我的经验是别一上来就追求大而全先把“连接-启动-总召-收数据-遥控”这条主链路跑通再去抠细节。仿真软件真正难的不是发帧而是对规约状态机的理解——什么时候该回确认什么时候该发测试帧序号怎么维护这些搞清楚了任何工具在你手里都能玩出花来。另外如果只是临时验证一下从站配置优先用现成工具快速看结果如果是长期维护一个项目或者做自动化测试非常建议自己写一套小脚本哪怕只有几百行后面加功能、复现问题都方便得多。最后再分享一个小技巧联调现场不要把报文内容凭空记直接抓包存成pcap文件配合仿真软件里的报文日志一起看很多疑难问题当场就能定位。本文还有配套的精品资源点击获取 104主站仿真软件实战：从协议拆解到联调踩坑
简介在电力自动化通信调试中IEC 104主站仿真软件是验证子站设备与协议实现的重要工具。这款软件包主要面向电力系统运维工程师、104协议开发者和测试人员用于模拟主站功能完成遥测、遥信、遥控等报文的发送与解析帮助排查通信链路故障、验证设备兼容性并可模拟异常场景辅助故障定位。包体共93个文件以ProIEC104Client.exe主程序、dll动态库、xml配置文件、pco历史报文记录和pol报文模板为主整体大小仅4.18MB并附带详细的PDF使用说明与示例报文可快速上手。目前已有1411人学习下载既适用于设备开发阶段的功能验证也适合现场调试和协议学习等场景。通过该工具使用者可以自由构造并发送各类104报文实时观察子站响应校验报文正确性从而大幅提升协议调试效率为电力系统稳定通信提供技术保障。 我最早接触104主站仿真软件是在一个从站设备调试的现场。当时手里的远动装置没有真实调度主站可连只能靠PC端的仿真软件扮演主站角色一遍遍发总召、收遥测、试遥控。那一刻我才意识到搞104规约的联调手里有一款趁手的主站仿真软件比堆什么文档都管用。这篇博文就围绕104主站仿真软件展开它到底仿真的是什么、协议底层有哪些必须搞懂的细节、怎么自己搭建一套可用的仿真环境以及联调过程中常见的那些坑。适合电力自动化调试工程师、SCADA开发人员以及刚接触IEC 60870-5-104规约的入门者。1. 项目概览104主站仿真软件到底在仿什么1.1 先从104规约的两个角色说起IEC 60870-5-104规约以下简称104规约是基于TCP/IP的远动规约在电力调度自动化里几乎是标配。它把通信双方分成主站和从站主站是调度端或者集控中心从站是变电站里的远动装置、测控装置或RTU。从站负责采集现场的遥测、遥信数据主站负责下发遥控、遥调命令。通信关系上主站作为TCP客户端主动发起连接从站作为TCP服务端监听2404端口。连接建立后主站发送STARTDT激活帧从站确认后双方才开始传数据。整个交互过程很像一个“老板”和一个“员工”的对话老板问“汇报一下情况”员工开始上报数据老板说“把3号开关合上”员工执行后回复“已执行”。104主站仿真软件本质上就是把这个“老板”角色装进PC里用软件模拟调度主站的完整行为。它能替代真实主站去连接从站设备也能模拟主站侧的报文交互逻辑用来验证、测试、培训。1.2 哪些场景会让它成为刚需场景一最典型子站侧调试。远动装置或测控装置在现场安装完需要验证104通信参数、点表映射、报文打包是否正确。这时候大概率没有真实调度主站可连或者调度主站还在建设期。用104主站仿真软件直接按IP和端口连接从站设备下总召、看数据、发遥控问题定位效率能提升一大截。场景二在主站侧开发测试。SCADA系统在开发阶段需要模拟大量从站数据来验证主站画面、告警、遥控流程。这时候光靠真实设备不现实要么用从站模拟器灌数据要么在仿真主站软件里做报文回放和压力测试。场景三是培训。刚入行的同事对104规约不熟悉直接在真实系统上操作风险大用仿真软件发几个报文、解析几帧数据很快就能建立起直观认识。所以104主站仿真软件解决的从来不是“有没有设备”的问题而是“在没有真实主站的情况下如何把通信链路和功能逻辑验证到位”的问题。它是调试工具更是一个理解规约的窗口。2. 核心细节104规约帧结构与数据类型拆解2.1 拆一帧报文搞懂APDU结构要用好仿真软件先得能看懂报文。104规约的报文单位叫APDU格式固定启动字符0x68、APDU长度1字节、控制域2到4字节、ASDU信息体可选的。控制域决定帧类型有三大类I帧信息帧用于传输ASDU控制域4字节带发送序号N(S)和接收序号N(R)。bit0为0。S帧确认帧只确认接收序号不携带ASDU控制域2字节。bit0为1、bit1为0。U帧控制帧用于启动、停止、测试链路控制域2字节。bit0和bit1都为1。实际抓包最常见的就是这几条主站 - 从站: 68 04 07 00 00 00 # STARTDT激活 从站 - 主站: 68 04 0B 00 00 00 # STARTDT确认 主站 - 从站: 68 0E 00 00 00 00 64 01 06 00 01 00 00 00 00 14 # 总召最后一条的总召报文长度0x0E表示后面还有14字节控制域四个0表示N(S)0、N(R)0ASDU里0x64是类型标识100对应总召C_IC_NA0x01是可变结构限定词表示一个信息体0x0600是传送原因6表示激活0x0100是公共地址1再往后是三字节信息体地址000000最后0x14是召唤限定词QOI20表示站召唤。这一帧发出去从站就会开始全数据上送。很多人在仿真软件里调不通就是没搞懂I帧的序号规则。I帧的发送序号和接收序号是累加的每发一个I帧N(S)1每收到一个I帧N(R)对方已收到的N(S)1。如果序号不对从站可能不回包或者直接链路复位。2.2 常用的ASDU类型与点表设计ASDU是104报文的“正文”由类型标识、可变结构限定词、传送原因、公共地址、信息体地址、信息体元素组成。主站仿真软件里最常用到的类型标识有这些类型标识名称方向用途1M_SP_NA从站-主站单点遥信3M_DP_NA从站-主站双点遥信11M_ME_NB从站-主站带品质描述的归一化遥测13M_ME_NC从站-主站带品质描述的短浮点遥测45C_SC_NA主站-从站单点遥控46C_DC_NA主站-从站双点遥控100C_IC_NA主站-从站总召唤传送原因也要记住几个关键值1是周期上送3是突发上送6是激活7是激活确认10是激活终止20是响应站召唤。很多报文看起来一样但传送原因不同含义完全不同。比如总召后从站批量上送的遥测传送原因往往是20不是3。信息体地址在104规约中是3字节低字节在前。它对应到现场实际测点就是“点表”的概念。仿真软件里要维护一张映射表把信息体地址翻译成“1号主变有功”“110kV线路开关位置”这样的可读名称。联调现场最常见的调试点就是确认从站的测点地址和主站期望的地址是否一致。地址对不上数据上来了也是错位画面全是乱码。3. 实操搭建一套可用的104主站仿真环境3.1 选现成工具还是自己写脚本我刚接触104主站仿真的时候也是到处找现成软件。市面上确实有一些商业的规约调试工具功能全界面友好支持遥测遥信遥脉搏的展示但普遍不便宜而且有些对非标点表的兼容性一般。还有一些开源库比如lib60870、Java的j60870以及Python生态里的相关实现都能作为二次开发基础。如果拿不定主意可以参考这个对比方案上手难度灵活性适用场景商业仿真软件低中现场快速调试、培训演示开源库二次开发中高定制协议逻辑、批量自动化测试Python脚本手搓偏高极高深度联调、协议学习、特殊场景我的建议是现场抢时间先用现成工具打通链路后续要做自动化回归测试再考虑用Python脚本做一套自己的主站模拟器。原因很简单现成工具能让你快速看到结果但理解不深自己写脚本的过程才是真正把104规约吃透的过程。3.2 手搓一个最小可用的主站仿真器以下是一个基于Python socket的最小主站仿真核心代码目标是连接从站、激活链路、发送总召、接收一帧数据并打印。import socket import struct import time HOST 192.168.1.100 # 从站IP PORT 2404 def u_frame(cmd): # U帧: 68 04 命令 00 00 00 return bytes([0x68, 0x04, cmd, 0x00, 0x00, 0x00]) def i_frame(send_seq, recv_seq, asdu): # I帧: 68 长度 控制域4字节 ASDU c1 ((send_seq 0x7f) 1) c2 (send_seq 7) 0xff c3 ((recv_seq 0x7f) 1) c4 (recv_seq 7) 0xff apci bytes([0x68, 4 len(asdu), c1, c2, c3, c4]) return apci asdu def build_interrogation(ca): # 总召: 类型100, VSQ1, COT6(激活), CA站地址, IOA0, QOI20 asdu bytes([0x64, 0x01, 0x06, 0x00]) struct.pack(H, ca) bytes([0x00, 0x00, 0x00, 0x14]) return asdu sock socket.socket(socket.AF_INET, socket.SOCK_STREAM) sock.connect((HOST, PORT)) # 1. 启动链路 sock.send(u_frame(0x07)) # STARTDT激活 resp sock.recv(256) print(STARTDT确认:, resp.hex()) # 2. 发送总召 send_seq 0 recv_seq 0 asdu build_interrogation(ca1) sock.send(i_frame(send_seq, recv_seq, asdu)) send_seq 1 print(已发送总召) # 3. 接收数据并解析 while True: data sock.recv(4096) if not data: break print(收到报文:, data.hex()) # 这里可根据类型标识进一步解析ASDU if data[0] 0x68 and len(data) 6: type_id data[6] print(类型标识:, type_id) time.sleep(0.5)这段代码能跑通一个最简流程连接从站、启动链路、发总召、收数据。实际项目中还需要处理粘包拆包、序号确认、超时重传、测试帧应答但这些逻辑在联调初期可以先不写先把链路打通看到数据再逐步完善。注意很多从站设备只允许一个TCP连接。如果调试时发现连上了又被踢掉检查是不是有其他调试软件占用了连接。这是现场非常常见的问题。3.3 扩展周期召唤与遥控命令最小仿真器跑通后下一步就是扩展功能。最常用的是周期召唤和遥控下发。周期召唤可以在循环里定时发送总召I帧每次发送前N(S)1收到数据后N(R)更新。主站仿真软件里这类定时任务要和收发线程分开否则接收会被发送阻塞。遥控命令的构造也不复杂。单点遥控C_SC_NA类型45的信息体元素是SCO一个字节bit0为命令值0分、1合bit7是选择/执行标志。直接执行时通常发0x00或0x01。双点遥控C_DC_NA类型46的DCO字节bit0-1表示命令状态常用0x01分、0x02合bit6-7表示选择/执行。整个报文的ASDU格式和总召类似只是类型标识不同信息体地址换成对应的遥控点号信息体元素换成SCO或DCO字节。发完遥控后从站会先回一帧传输原因7激活确认表示收到命令执行完成后返回传输原因10激活终止。在主站仿真软件里如果只收到确认没有收到终止就要考虑是不是执行环节出了问题比如闭锁条件不满足、操作权限不对。4. 实战踩坑联调中常见的8个问题4.1 连接层连不上、被踢掉、地址不对104联调第一个坎就是TCP连接。从站IP、端口2404、网络通不通这三项定了才能往下走。常见问题有从站配置成了客户端模式等着主站当服务端导致连接失败防火墙挡了2404端口从站同时只允许一个连接被其他调试工具占用了。还有一个容易被忽略的是公共地址站地址。104规约里的公共地址是2字节低字节在前。仿真主站里填的公共地址必须和从站配置一致。不一致时从站收到总召可能直接丢弃或回复不明确表现为主站侧“发送正常但没有任何返回”。我见过不少人在这个字段上栽跟头因为工具默认公共地址是1而现场远动装置配置的是21。4.2 报文层长度、序号、品质位报文层面的问题更隐蔽。一个是粘包拆包从站可能一次TCP报文里带好几帧APDU如果仿真软件没有做缓存和按长度字段拆包解析就会错乱。另一个是序号错乱主站发了I帧后没等确认就继续狂发超过从站接收窗口k默认12从站会断开链路。品质位也是调试高频点。104遥信信息体元素里有品质描述bit7可能是无效位IVbit4可能是封锁位BL。如果从站上送的遥信品质位是0x80或0x10主站仿真软件里显示的数值虽然能出来但状态可能是“无效”或“封锁”。很多现场“数据上来了但不刷新”的怪问题最后都出在品质位上。建议联调时把每帧的品质位打印出来看。4.3 心跳与超时别让链路悄悄断了104规约有一套链路保活机制t0是连接超时t1是发送或测试超时t2是接收确认超时t3是测试帧周期。默认值分别是30秒、15秒、10秒、20秒。主站仿真软件必须在t3时间内发测试帧TESTFR探活如果链路长时间没数据仿真软件还在干等从站可能已经把链路超时释放了。如果你发现仿真软件界面显示连接正常但发任何命令都没反应大概率是链路已经死了软件没检测到。好的仿真软件应该能主动发送TESTFR帧收到TESTFR确认后再继续。自己写脚本时这个逻辑一定要加进去否则模拟主站就是个“假连接”。一点个人体会用了这么久的104主站仿真软件我的经验是别一上来就追求大而全先把“连接-启动-总召-收数据-遥控”这条主链路跑通再去抠细节。仿真软件真正难的不是发帧而是对规约状态机的理解——什么时候该回确认什么时候该发测试帧序号怎么维护这些搞清楚了任何工具在你手里都能玩出花来。另外如果只是临时验证一下从站配置优先用现成工具快速看结果如果是长期维护一个项目或者做自动化测试非常建议自己写一套小脚本哪怕只有几百行后面加功能、复现问题都方便得多。最后再分享一个小技巧联调现场不要把报文内容凭空记直接抓包存成pcap文件配合仿真软件里的报文日志一起看很多疑难问题当场就能定位。本文还有配套的精品资源点击获取