做变电站自动化调试这些年IEC103是我始终绕不开的协议。后台监控要采保护装置的数据那就避不开和不同厂家打交道而每个厂家的私有规约几乎都不一样IEC103标准至少把保护设备与监控系统之间最基础的信息交互方式给定下来了——遥信、遥测、事件、扰动数据这些基本内容有了统一的报文格式和传输规则。这篇文章我就把自己解析IEC103报文、做传输优化时踩过的一些坑和验证过的方法整理一遍给做继保调试、嵌入式开发和自动化测试的朋友做个参考。全文会从协议基础、报文结构、逐字节拆包、传输优化以及现场排查这几个维度展开尽量做到拿着文章能直接干活。1. IEC103协议到底是什么为什么到现在还在用1.1 从变电站通信说起IEC103的定位一个110kV或者35kV变电站里保护装置分散在各个间隔后台监控或者保护信息子站要把这些装置的状态量、模拟量、动作事件、故障录波数据集中上送这就需要在装置和后台之间建立一条通信链路。IEC103的全称是IEC 60870-5-103它是国际电工委员会为“继电保护设备与监控系统之间通信”专门制定的标准。它继承了IEC 60870-5系列标准的整体框架链路层采用FT1.2帧格式物理层通常走RS-485总线应用层则针对保护设备定义了特有的信息模型比如扰动数据传输、事件顺序记录、带时标的跳闸报告等。从我实际接触的项目看IEC103最常见的应用场景有三个一是老变电站的后台监控改造保护装置不动只换后台监控软件二是保护信息子站、故障信息管理系统要与多个厂家的保护装置对接通过IEC103做规约转换把数据统一上送到调度端三是新建设备出厂调试阶段用继保测试仪、规约测试软件模拟后台验证保护装置的通信功能是否正常。即便很多新站已经开始用IEC104走网络传输但存量设备里IEC103的保有量依然很大而且它里面保护语义的定义比104更细很多私有扩展也是从103延续下来的。1.2 和IEC101、IEC104的对比为什么不能完全替代很多刚开始接触的人都会问IEC101、IEC103、IEC104到底有什么差别我习惯用一句话区分101解决远方调度和厂站之间的通信103解决站内保护装置和监控系统之间的通信104是101在TCP/IP网络上的实现。三者底层都源自IEC 60870-5系列ASDU应用服务数据单元结构一脉相承但面向对象和语义内容不同。下面这张表是我经常拿来给新同事讲的对比对比维度IEC 60870-5-101IEC 60870-5-103IEC 60870-5-104主要用途调度端与厂站远动通信站内保护设备与监控通信基于网络的调度/站内通信物理/传输层RS-232/RS-485串口RS-485串口TCP/IP网络链路层FT1.2FT1.2APCITCP上封装典型帧格式可变/固定帧长可变/固定帧长68 04 0A 0A 08 00...保护专用语义较少丰富含扰动数据等继承101扩展保护语义当前使用率存量较多新增下降存量很大新增仍有新增最多这里我多提一句很多人做“104通讯tcp链路层报文解析”时会把链路层和IEC103的链路层搞混。104在TCP链路上的传输控制用的是APCI启动字符也是68所以看到一帧数据开头是68先别急着按103解析要看链路层之后的内容是ASDU还是控制报文。我在后面第三节会演示103的链路层完整拆包两者对照着看会更容易理解。2. 理解报文结构从物理层到应用层的逐层拆解2.1 链路层FT1.2帧格式先找到帧头再说IEC103的通信底层用的是IEC 60870-5-1中定义的FT1.2帧格式常见的有三种帧单字符帧、固定帧长帧、可变帧长帧。单字符帧一般用在确认应答场景固定帧长帧用于电厂、变电站里一些简单的命令而我们实际解析过程中遇到最多的是可变帧长帧因为ASDU长度不固定。可变帧长帧的结构固定为这样一串字节68 L L 68 C A ASDU... CS 16逐个字段解释一下起始符68固定十六进制0x68用于标识一帧的开始。长度L从控制域C开始到ASDU结束的字节数在同一帧中出现两次是冗余校验的一部分防止传输出错。注意它不包含起始符、长度字节本身、校验CS和结束符16。再次出现的68重复的帧起始符和第一个68合成一个特征头。控制域C一个字节包含传输方向、FCB帧计数位、FCV帧计数有效位和功能码。主站发出时方向位为0从站返回时方向位为1。功能码决定这帧数据是发送/确认、请求/响应还是其它类型例如功能码3往往是带数据的发送/确认功能码0是确认帧。地址域A一个字节表示从站地址也就是保护装置的地址。一般范围是0到255其中255保留给广播或全局地址。ASDU应用服务数据单元协议真正要表达内容的区域。CS校验和按FT1.2的算法对控制域C、地址域A以及ASDU的所有字节求和取低8位然后用256减去这个低8位结果就是CS。也就是说把C、A、ASDU、CS加起来低8位应该正好是0。这是现场排查误码最重要的一步。结束符16固定十六进制0x16标志帧结束。为什么要有长度L的重复和最后的CS校验因为RS-485是半双工共享总线在线路上无法像网络通信那样依赖TCP保证可靠交付只能靠帧格式自身的冗余校验来控制误码。现场电磁干扰复杂一个字节被干扰成别的值太常见了没有这套校验机制报文错乱根本无从发现。2.2 应用层ASDU结构类型标识、传送原因、信息体ASDU是整帧报文的“业务核心”。IEC103的ASDU结构和IEC101大体一致都包括数据单元标识符和信息体两部分。数据单元标识符由四个字节组成类型标识一个字节告诉接收方这帧数据是什么类型的。比如总查询、时钟同步、单点遥信、双点遥信、带时标的跳闸报告、扰动数据传输等。IEC103标准里有很多保护专用类型标识但不同厂商实现时可能在这个基础上扩展所以看协议时先看类型标识是最快的定位方法。可变结构限定词VSQ一个字节bit7表示信息体地址是否连续低7位表示信息体的个数。也就是说一个ASDU里可以装多个信息元素比如一批连续的遥信点可以合并成一个ASDU上送这样能明显减少帧数量。传送原因COT一个字节描述这次传输的原因常见的有周期传输、突发传输、总查询激活、总查询响应、激活确认、时钟同步等。比如从站收到主站总查询后先回一个“激活确认”再把数据发出来这个“激活确认”就通过传送原因字段表达。公共地址一个字节一般对应从站地址或者一个逻辑设备地址用于区分ASDU归属于哪个设备。信息体部分则按照类型标识的不同存放着具体的数据信息体地址、信息元素遥信值是0还是1、遥测值是多少、双点状态是01还是10、时标毫秒、分、时、日等信息。理解ASDU的关键就是抓住“类型标识决定后续信息体的解释方式”这条主线拿到一帧报文先看类型标识再去查对应的信息体字段就不会懵。2.3 常见报文类型总查询、时钟同步、扰动数据在IEC103的标准交互流程里主站和从站之间会循环执行几类典型报文交换我把它们归纳成三个场景第一是总查询。主站周期性下发总查询命令要求从站把当前全部遥信、遥测状态上送一遍从站收到后先回确认再把所有信息体按设定的顺序发出来。总查询是监控后台“上画面”的基础画面刚打开时所有开关状态、实时数值都靠这一轮查询填充。总查询周期过长画面数据刷新慢周期过短总线会一直被占用。第二是时间同步。保护装置动作事件的时标必须准确否则事故分析时无法判断先后顺序所以主站会定期广播时钟同步命令从站收到后把本地时钟校准到主站时间。常见问题是主站没配置自动对时或者从站处于闭锁状态导致事件时标和实际时间偏差大。第三是扰动数据传输。当线路发生故障、保护动作瞬间装置会记录下故障前后的电流电压波形和开关量变化形成扰动数据文件。IEC103中定义了专门的数据传输过程主站发送召唤命令从站按数据块把扰动数据传输上来整个过程包含请求、确认、数据块上送、结束等多个环节比普通遥信遥测复杂得多调试时也是最容易出问题的地方。 提示不同厂家的保护装置即使宣称支持IEC103在类型标识、信息体地址、时标长度上也可能存在差异。遇到新设备我建议先向厂家要一份通信规约说明书对照着标准框架看比自己盲解析高效得多。3. 实战报文解析用串口工具和总线分析仪抓帧拆包3.1 搭建最小调试环境准备哪些工具解析IEC103报文最重要的不是用什么高级软件而是先把物理链路打通。我最常用的一套方案是一台电脑加一个USB转RS-485模块双绞线接到保护装置通信口上波特率、校验位、停止位需要和保护装置设置一致。IEC103常规配置是9600bps8位数据位1位停止位偶校验也有装置用无校验或者19200bps具体以设备参数为准。这里提醒一句RS-485是A/B差分信号接反了收不到数据但往往不会损坏设备调试时可以先用万用表确认A、B线对应关系。抓包工具方面我分三种场景如果只是简单看几帧数据直接用串口调试助手比如SSCOM、友善串口助手设置好串口参数打开监听把接收到的十六进制数据保存成文本即可。如果需要做较专业的帧分析可以用Bus Hound、CANalyzer/CANoe这类总线分析工具。很多人以为canoe报文解析只能用来做CAN或CAN FD其实CANoe配上串口接口也能挂接RS-232/RS-485线路对IEC103这种串口协议做报文解析。解析逻辑和can报文解析里DBC映射的思路是相通的都是把字节流映射成带业务含义的信号。如果要在研发阶段做协议栈验证我会用Python写一个小脚本从串口读取原始字节按FT1.2帧格式切帧并解析ASDU这样方便批量回放和自动化测试。我见过不少新手一上来就想着用高大上的工具结果连串口助手都还没整明白。我的建议是先从串口助手开始手动抓几帧、对一下字节练熟了解析思路再上自动化工具这样理解才扎实。3.2 一帧总查询报文的逐字节拆解下面我用一个简化后的示例来演示逐字节拆解过程这样比空谈理论直观得多。假设主站向地址为01的从站下发总查询命令抓到的原始字节流是这样的68 09 09 68 73 01 64 01 46 00 00 00 00 E1 16第一件事是看帧头开头是68 09 09 68帧起始符正确长度字段L0x09也就是十进制9。那我们数一下从控制域73开始到ASDU结束依次是73 01 64 01 46 00 00 00 00正好9个字节长度对得上。接着拆控制域和地址域73是控制域01是从站地址。这里的控制域73表示主站向从站发送的带数据确认帧FCB/FCV的状态位结合具体通信过程来理解01说明命令是给1号从站的。再往下是ASDU部分64类型标识对应十进制100在101/103体系里这个类型标识常用于总查询命令。01可变结构限定词bit7为0表示信息体地址不连续低7位为1表示只有1个信息体。46传送原因对应十进制70在私有扩展里表示“总查询激活”不同厂家的定义略有不同这里遵循该装置规约说明书。00 00 00 00前两个字节是信息体地址后两个字节是总查询的具体信息元素本例中为0表示查询全对象。这里就不展开说明私有字段细节了。最后是校验和与结束符计算控制域、地址域和ASDU所有字节的和730164014600000000取低8位为0x1F用256减去0x1F得到0xE1正好是帧里第14个字节说明这帧数据没有受到干扰。最后的16表示帧结束。3.3 从站响应报文的解析实例看看带时标的信息体怎么读主站总查询发出后从站会回多条报文。我拿一条带时标的单点事件响应来演示这比无时标的报文多一层信息足以说明解析时标的重要性。假设从站返回的原始字节流是68 0F 0F 68 13 01 01 01 16 03 00 01 02 05 0C 1E 00 00 00 9F 16先检查帧结构从68开始长度L0x0F也就是15字节从控制域13到ASDU结束的字节数是13 01 01 01 16 03 00 01 02 05 0C 1E 00 00 00正好15字节长度正确。控制域13说明这是从站向主站返回的确认帧地址域01表示从站地址为1。再拆ASDU类型标识01单点信息遥信表示一个开关量状态。可变结构限定词01信息体个数为1地址不连续。传送原因16对应十进制22在这个厂家规约里表示突发遥信。公共地址03设备逻辑地址经常和站内装置编号对应。信息体地址00 01表示信息点号是1对应具体的开关位置。信息元素02单点遥信值通常bit0表示状态0为分、1为合bit2置1表示信息有效所以02表示“合位且有效”。时标05 0C 1E 00 00 00这里我取了一个简化时标包含了相对毫秒和分时秒字段。读取时先看毫秒低字节和高字节再读分钟、小时、日、月按顺序拼起来就是事件发生时刻。校验和的计算方法和上节一样把所有对应字节相加取低8位再取补码结果正好是帧里的9F说明这一帧在传输过程中没有发生误码。从这帧数据我们能得到完整信息1号从站、公共地址3、信息点1的开关状态为合位且有效事件发生时刻由时标给出。一个现场画面里上千个遥信点就是这样一帧一帧解析出来的。3.4 工具选型用CANoe这类总线分析仪能省多少事前面说了串口助手适合入门和抓原始数据但如果你需要同时监控多路串口、处理复杂时序或者要长期记录和回溯我建议上总线分析工具。行动轨迹上CANoe是业内使用较多的工具它不仅仅能处理CAN报文解析还支持通过串口通道对RS-232/RS-485链路进行报文监控和仿真。你可以在CANoe里根据IEC103的帧格式定义链路层模板再按ASDU结构定义解析函数把原始字节流转换成直观的信号列表字段名、数值、单位一目了然。它和can报文解析里的做法本质一样只是把DBC映射换成了IEC103的ASDU模板。用这类工具最明显的好处是时间戳精度高。通过CANoe抓到的每一帧都带高精度时间戳能直接算出主站下发到从站响应之间的时延这个数据对于后面讲传输优化非常关键。串口助手虽然也能正常抓包但时间精度达不到毫秒级以下用来判断“从站响应速度是否达标”就会差很多。还有一个容易被忽略的问题用USB转RS-485做调试时USB串口芯片的缓冲区如果太小在持续高速通信时容易丢字节。我遇到过用某款USB芯片挂载在9600bps下正常但数据量一大就出现帧头找不到的情况后来换了带大缓冲的芯片才解决。分析工具记录的原始数据如果穿插着丢字节解析结果就没有意义这是排查时必须先排除的因素。4. 传输优化策略让IEC103通信更快更稳4.1 轮询周期、超时与重传机制怎么平衡IEC103在不平衡传输模式下主站按顺序向各从站发起查询从站收到后才允许上送数据这就导致通信效率和轮询策略强相关。轮询周期设置得过短主站可能在上一条命令的响应还没完全回来时就发出下一条造成总线冲突或从站无响应设置得过长监控画面上遥信变位和遥测刷新就会出现明显延迟保护动作信号可能滞后数秒才上送这是运行人员无法接受的。我在现场一般这样调总查询周期在5到30秒之间具体取决于从站数量和总线波特率。先测出单个从站完成一轮总查询的耗时然后按“轮询周期≥所有从站一轮总查询耗时之和×2”的经验值来设置留出一倍余量应对突发上送。对于单条命令的超时比如总查询命令发出后从站响应超时通常设为1秒突发事件的响应超时设为500毫秒到1秒超过时间没收到响应主站重发连续重发三次仍然失败就置该从站通信故障警告不再无限等待。这里要解释一下“从站处理时间”这个坑。不少保护装置内部是分任务的通信板收到命令后还要去主控板读数据响应时间可能波动很大。同一台装置平时响应只要几十毫秒但在动作事件触发的瞬间内部优先级全被保护逻辑占用通信响应可能延长到数百毫秒。所以超时时间不能只看静态测试值要留足动作场景下的余量。4.2 波特率、校验位和通信参数的影响分析很多调试人员习惯把所有设备都设成9600、偶校验如果现场通信不稳定第一反应就是线路问题。但我做过一个对比测试同一套装置改到19200bps后偶发性通讯中断反而多了起来因为波特率翻倍意味着每一位的时间缩短一半同样的干扰脉冲在采样窗口内更容易造成误码。波特率的选择取决于传输距离和电缆质量。站内RS-485布线通常在几百米以内9600bps足够可靠19200bps在短距离优质双绞线上也没有问题如果线缆比较长、强电干扰大我建议老老实实用9600甚至更低。IEC103的帧结构本身带校验和CS误码能检测出来但检出来之后就要重传重传次数一多实时性照样下降所以宁可一开始把波特率选保守一点。校验位是另一个常被忽略的因素。IEC103很多装置默认配置是偶校验但也有厂家用无校验或者奇校验。主站和从站校验位不一致时帧内容无论对错接收端从起始位就断定格式错误表现出来就是完全收不到报文或者收到大量随机字节。排查这种问题时用示波器看波形也行但最简单的办法是轮换参数组合9600/偶校验、9600/无校验、19200/偶校验等各测一轮记录哪种组合下通信最稳定。4.3 多从站轮询调度与报文裁剪技巧一条RS-485总线上挂多个从站时主站要合理地给每个从站分配时间片。我见到的常见做法是按从站地址从小到大顺序轮询但这不是最优的。如果某个从站历史数据量大、响应用时长其他从站会被长时间晾着。更合理的做法是把从站按响应耗时分组快的组多查几次、慢的组少查几次把事件实时性要求高的从站优先放在轮询队列靠前的位置。报文裁剪方面IEC103支持把多个地址连续的信息体放在同一个ASDU里上送这就要用到可变结构限定词里的连续标志。我在调试时发现有些从站实现得不理想明明支持连续信息体但每次上送还是每个信息体单独一帧结果总线被无效帧头、校验和这些开销白白占掉。遇到这种情况可以尝试在从站侧修改上送策略配置或者在后端规约转换装置里做合并。对一帧普通可变帧来说固定开销大约占7个字节如果单一信息体只占3个字节连续上送10个信息体就能省下约68%的帧开销在低速总线下效果非常明显。另外总查询时可以考虑按信息体地址分段查询。有些装置整站几百个遥信点全量上送要分十几次才能完成而监控画面往往只关心部分点位为了快速刷新核心点位可以先把关键地址段换成较短的信息体列表上送待稳定后再统一补齐这种“优先上送关键信息”的思路在现场实战中很实用。4.4 干扰场景下的传输可靠性优化变电站一次设备操作、断路器和隔离开关分合闸时会产生很强的电磁干扰通过线缆耦合进RS-485总线轻则造成单帧误码重则导致通信长时间瘫痪。传输可靠性优化可以从几个方向同时下手。线缆层面RS-485要用屏蔽双绞线屏蔽层在电源侧单端接地或两端接地要看现场接地系统我一般建议在通信柜侧单端接地避免地环流干扰。总线两端要接120欧姆终端电阻特别是距离长或分支多的时候不接终端电阻会让信号反射明显波形变形严重。很多现场为了省事不接电阻结果误码率居高不下接上以后立刻就好转。电气隔离层面如果从站设备电源和主站设备电源不共地或者现场有潜在的地电位差尽量选用带隔离的RS-485收发器或隔离模块。站内调试时我吃过一次亏两个设备地电位差超过允许范围通信口虽然有保护但数据始终乱码接了一对隔离模块后彻底解决。通信机制层面在应用层增加故障恢复机制比如连续多次收不到响应就主动切断该链路、隔一段时间重新恢复避免一台故障从站把整条总线的轮询周期拖垮。 提示现场做传输优化时一定要先拿到“正常通信”的基线数据再逐项改变量。每改一个参数记录一次通断情况不要同时改多个变量否则出了新问题根本说不清是哪个改动引起的。4.5 用通信压力测试验证优化效果优化效果不是靠感觉的要量化验证。我自己常用CANoe或者自制脚本做一个简单的压力测试模拟主站按设定的轮询周期和超时参数连续运行半小时以上统计总发送帧数、总接收帧数、超时次数、重发次数和校验错误次数。通过这几组数据可以算出链路误码率和通信可靠性。一个简便的测试方案让主站以最快速度连续下发总查询命令持续10分钟记录从站每轮响应的完整度和平均响应时间。如果总查询周期设计得合理从站每轮都应该能完整应答不应出现连续超时如果出现超时就说明周期太短或者从站处理能力到了上限。再观察异常帧的数据特征是集中在某些地址段还是随机分布据此判断是软件逻辑问题还是硬件干扰问题。我还喜欢做一件事人为制造干扰验证装置的容错恢复能力。比如在总线上短接触碰到地模拟短路干扰或者拔掉从站通信线模拟掉线观察主站是否能在设定的超时和重发机制下自动恢复。这种测试在验收阶段很关键能提前暴露通信机制里的隐患而不是等到真正故障时才手忙脚乱排查。5. 常见问题与排查技巧实录5.1 CRC校验错误和帧失步排查检验报文的第一步永远是看校验和。很多新手在串口助手里看到一串68开头的字节立刻就去解析ASDU这容易走弯路。我记得有一次现场报“后台收不到保护装置数据”抓包软件里确实有大量68开头的帧但用脚本逐帧算CS校验和发现一半以上都不通过。最后定位到原因是USB转RS-485模块的驱动缓存设置不合理导致数据流中出现丢字节好几个帧的校验和自然对不上。排查这类问题我习惯写一段几十行的Python脚本批量处理抓包文件把不满足FT1.2结构或校验和错误的帧单独标出来统计占比。如果错误帧占比高优先怀疑物理链路、串口参数和驱动如果错误帧占比低只是零星出现大概率是偶发干扰可以检查终端电阻和屏蔽接地。帧失步时表现为找不到完整帧头或帧长和实际不匹配可以先降低波特率试试很多时候干扰随着波特率下降就消失了。5.2 地址不匹配和公共地址设置错误从站地址地址域A和公共地址是两回事但现场经常有人混淆。地址域A是链路层定位从站用的主站轮询时通过它选择目标从站公共地址是应用层ASDU里的字段用于标识信息所属的逻辑设备。有的装置要求两者保持一致有的装置允许不同如果设置不一致主站虽然能在链路层正常和从站通信但应用层会丢弃ASDU表现出来的现象就是主站发什么从站都不回应或者回应报文主站不接收。这种问题排查方法很简单逐条报文检查地址域和公共地址是否与装置配置一致。最好在项目开始时就做一个通信参数表把所有从站的地址、公共地址、波特率、校验位登记清楚调试时对照着改能少踩很多坑。5.3 时间标签异常和时钟同步问题事件时标异常是IEC103调试里的典型怪现象表征上像“动作事件上报时间比实际时间差了好几个小时”或者“时报文时标是1970年”。根本原因基本都是主站没有按时发出时钟同步命令或者从站收到同步命令后没有正确校正内部时钟。我处理过一台装置站控后台连续运行一个月后保护和后台的事件时标对不上前后差了十几分钟。排查后确认是后台的自动对时功能默认关闭只有手动点了一次对时之后就再没同步过。把对时周期改为每小时自动执行一次问题就消失了。另外要注意时钟同步命令本身也需要确认机制从站收到同步命令后如果没回确认主站要重发否则从站对时不一定生效。5.4 线路干扰和硬件连接导致的典型故障现场最常见的硬件问题有三个RS-485的A/B线接反、终端电阻缺失、屏蔽层接地不当。A/B线接反时收到数据往往是乱码或者完全没有数据用万用表量A/B之间电压正常通信时应存在大约1.5V到5V的压差接反时压差会反向。终端电阻缺失时总线信号反射会造成长距离下的误码加装120欧姆电阻会有明显改善。屏蔽层接地不当可能引入地环流引起更复杂的偶发故障排查时可以用排除法分别测试屏蔽层不接、单端接地、两端接地的三种状态选择误码率最低的方式。5.5 一个实际问题的完整排查思路参考说一个我印象很深的案例。某站后台监控在无操作的情况下保护装置频繁上送重复的遥信变位事件每几分钟就出现一次。从抓包数据看从站确实持续上送突发遥信报文但信息量和一次真正的变位事件完全不符更像是重复上放历史事件。先检查时钟同步和时间标签发现从站时标比后台快了三秒于是推断是主站对时周期过长导致时钟漂移事件重复上送是装置内部判断“时标变化”后再次打包历史事件所致。把主站对时周期从24小时改成1小时并且调整从站的事件上送去重机制后问题消失。从这个案例能看出来排查IEC103问题不能只盯着一帧报文要结合对时、事件存储、轮询机制一起分析。6. 一点个人经验和后续可以扩展的内容说了这么多最后再分享一个这些年总结下来的调试习惯开工前先做两张表一张是通信参数表把所有装置地址、波特率、校验位、公共地址、类型标识定义记录下来另一张是报文样本表把典型的总查询、遥信、遥测、扰动数据传输报文各存一帧正常的原始数据。这两张表能在后续所有调试、排错、验收阶段派上大用场遇到新问题先和正常样本对比往往能快速缩小排查范围。调试IEC103协议本质上就是和字节流打交道核心能力是三点能看懂帧结构、会拆ASDU、会分析传输时序。建议刚开始接触的朋友拿串口助手手动解析几帧再慢慢过渡到CANoe这类自动化工具。后续如果想往更深走还可以研究私有扩展类型标识的解析以及用Python写IEC103主站模拟器做自动化测试这些方法对104、101协议同样适用掌握了思路之后就一通百通了。