1. 别被遥控两个字骗了它根本不是远距离控制的那个遥控干电力自动化这行天天跟IEC104打交道。我记得刚接触规约那会儿听到遥控遥调四个字脑子里第一反应是那种拿个手柄控制无人机或者遥控车的东西。后来被老师傅狠狠纠正了一顿——电力系统里的遥控遥调跟日常理解的遥控完全是两码事。先说清楚概念。在电力监控系统里遥测是把现场的电压、电流、功率这些模拟量拿回来遥信是把开关位置、刀闸状态这些开关量拿回来这俩都是往上送的信息。而遥控和遥调是反方向的——从主站往下发命令去控制现场的设备。遥控对应的是开关量的控制比如合闸分闸遥调对应的是设定值的调整比如把变压器的档位往上调一档或者把无功补偿的功率因数目标值改成0.95。之所以说它容易混淆是因为IEC104规约里遥控遥调的命令报文结构看起来长得几乎一样但它们的类型标识号不一样控制方向不一样甚至返回的确认机制也有细微差别。你如果只是浅尝辄止地翻过一遍规约文档很容易把这两者搞混。这篇文章我就把自己在工程现场对接遥控遥调时踩过的坑、总结出来的经验以及一套可以直接照抄的测试方法完整地交个底。不管是刚入行的调试工程师还是被厂家五花八门的后台软件折腾得焦头烂额的项目经理这篇内容对你都会有用。哪怕你现在还没碰过104规约只要你想搞懂主站和厂站之间到底是怎么说话的也能从里面摸出个大概的门道。2. 为什么遥控遥调比遥测遥信难搞定得多2.1 命令不是发出去就完事了设备必须答话遥测遥信的逻辑相对简单主站问子站答答完就算完了。即使数据没上来也就是个坏数的问题不会导致现场设备动作。但遥控遥调不一样。主站下发一条命令现场设备得先收到并确认执行完了还得再告诉主站我已经执行了。这中间的每一个步骤规约里都有明确定义——先选择后执行再确认最后还有结束帧。任何一个环节卡住了这条命令就算失败而现场的开关可能就停在半合半开的状态这在电力系统里是绝对不允许的。IEC104规约中遥控从头到尾的完整交互流程是这样的主站发送选择命令C_SC_NA_1类型标识45告诉子站我准备对某个点进行操作。子站收到后返回选择确认类型标识45的确认帧表示我知道你要干啥了。主站再发执行命令同样是类型标识45但是带执行限定词。子站返回执行确认。设备动作完成子站上报变位遥信单点信息类型标识1告诉主站开关现在已经合上了。主站收到变位遥信后这条完整的控制流程才算闭环。遥调和遥控的结构几乎一样只是类型标识换成了C_SE_NB_1类型标识50归一化设定值命令里带的是设定值而不是合分闸。这里要敲黑板很多刚开始接触104测试的人做完第4步就以为完事了看到子站返回了执行确认就高呼成功。但真正的控制成功一定是以遥信变位回报为最终判据的。如果你只看到了执行确认没等到遥信变位说明现场设备压根没动作或者动作了但遥信没接对这条命令实际上还是失败的。这个道理基本等同于你打电话叫外卖骑手接单了不意味着饭已经送到你手里必须等到门铃响才算完。2.2 类型标识不是随便填的填错了必出事故IEC104的遥控和遥调在类型标识号上有着严格的区分。这个必须刻进骨子里功能类型标识号名称用途遥控选择45C_SC_NA_1双点遥控选择命令遥控执行46C_DC_NA_1双点遥控执行命令遥控撤销47C_RC_NA_1双点遥控撤销命令遥调选择50C_SE_NB_1归一化设定值选择遥调执行51C_SE_NB_1归一化设定值执行遥调撤销58C_SE_NB_1归一化设定值撤销很多老外的规约文档里会给每个功能都分配独立的类型标识号但国内厂家在实现IEC104时普遍采用选择用45执行用46撤销用47这种三段式做法。遥调则是50选51执行58撤销。实际工程配置里最常犯的错是把遥调命令的设定值格式搞错。104规约里归一化设定值是个16位的整数对应工程的量程范围一般从-1.0到1.0之间映射。很多刚从61850转过来的人习惯性地以为设定值可以直接填成实际物理量比如把电压设成230V结果直接把230这个数字塞进设定值里现场设备收到的设定值就变成了离谱的东西。这里的换算逻辑其实跟遥测标度是一套实际值 归一化值 × 量程满度值。比如你的遥调量程是0到100那归一化值0.5就对应实际值50。你填给设备的必须是归一化值而不是实际值。这个映射关系如果没理清楚光这一个坑就能让你在厂里卡三天。2.3 双点遥信才是104遥控操作的地基我在跟很多刚用104规约的同行聊天时发现不少人把遥控和遥信割裂开看。实际上在IEC104里遥控操作的反馈机制依赖的是双点遥信而不是单点遥信。遥信遥测真正落地时要搞明白两者的区别——双点遥信用两个Bit表示一个开关位置00表示中间态/不确定01表示合10表示分11表示故障态。为什么要用双点因为电力系统的开关位置容不得模糊。你用单点遥信0和1就是分和合但现场万一通信瞬断、设备抖动单点很容易给出错误位置。双点可以探测出设备既不在合位也不在分位这种异常主站才能调度员才能判断出这个开关状态可疑先不要操作。实操中我见过不少混乱的做法遥控点位对应的遥信用的是单点或者遥信做对了但在遥控命令下发之后子站上报的遥信变位方向反了——合闸变位回报的是分位。这类问题通常在为什么我遥控成功了后台显示的开关状态却是反的中暴露出来。3. 建立一套完整的IEC104测试环境不再求爷爷告奶奶3.1 测试工具的选择思路与协议栈分层理解搞104规约的遥控遥调测试最核心的工具就是规约测试软件。这类工具市面上不少有厂家的专用软件也有开源的通用工具。我个人的经验是任何工具都要建立在你自己对104规约本身足够理解的基础上否则工具越好用你越不知道它在干什么出了问题照样抓瞎。104规约本质上是IEC60870-5-101规约的网络版走TCP/IP端口号一般是2404。主站侧作为TCP客户端发起连接子站侧作为服务器监听端口。理解整个协议栈的分层对排查问题帮助极大最底层是TCP传输上面是APCI应用层控制信息再上面是ASDU应用服务数据单元。一个完整的遥控命令实际上被封装成APCI加ASDU的组合。主站和目标子站通信时IEC104规约不像101那样需要反复拨号它通过TCP的长连接维护一个持续的会话通道。会话开始时有启动报文STARTDT结束时有停止报文STOPDT中间需要周期性的测试帧TESTFR来确认链路存活。这些握手关系在你做遥控测试时都必须保证正确否则命令根本传不到对端。3.2 完整的环境搭建步骤一套完整可用的104遥控遥调测试环境需要下面这些组件规约调试软件装一台电脑上作为模拟主站或者模拟子站。被测装置比如一台实际的保护测控装置、RTU或者DTU或者是厂家提供的仿真软件。网络环境用一根网线直连或者一个小交换机确保主站和子站IP互通我一般习惯用192.168.1.x段子网掩码255.255.255.0。抓包工具比如Wireshark用来在关键时刻抓报文。很多人觉得抓包是网络工程师的事其实搞规约调试的也必须会——因为当你怀疑工具显示和实际收发不一致时抓包是最公正的裁判。搭建步骤不复杂但有几个细节值得注意。第一主站和子站的IP地址不要设置成同一个网段里容易冲突的地址比如192.168.1.1这种默认网关地址容易无故出问题。第二确认防火墙没有拦截2404端口很多Windows系统自带的防火墙默认会拦掉非标准端口的入站连接这个坑我至少帮人排过三次。第三如果被测设备支持记得设置合适的公共地址Common Address主站和子站必须一致否则报文到了对端也会被丢弃。3.3 点表配置和地址公式这步做错全盘皆输遥控遥调测试前必须把点表配置清楚。所谓点表就是主站和子站之间约定的一张翻译对照表——现场设备第几个开关、第几个回路对应104规约里的什么信息体地址。这是整个遥控遥调工程的灵魂点表错了后面所有测试都没有意义。IEC104的信息体地址一般是按照公式来算的。国内最常见的一种约定是遥信地址从0x0001开始对应1遥测地址从0x1001开始对应4097遥控地址从0x2001开始对应8193遥调地址从0x3001开始对应12289。每个点占一个地址依次递增。举个例子你现场的第5个遥控点按这个约定信息体地址就是0x2005十进制是8197。你填点表时填的就是这个值。有的后台软件里显示的是十进制有的显示十六进制配置时一定要看清楚了别把0x2005当成2005来填这种低级错误真的有人犯过。另外特别提醒不同厂家对地址区间的划分不是完全统一的有的厂家遥测从0x0001开始遥控从0x1001开始有的则跟上面说的不同。所以拿到一张新点表时第一件事就是确认厂家的地址分配规则而不是默认套用自己熟悉的那套公式。最靠谱的做法是直接从厂家提供的配置文档里找到地址映射表而不是自己去猜。4. 遥控遥调联调全流程实录从接线到闭环4.1 接线和硬压板检查比协议本身更容易翻车很多人一上来就抱着规约文档研究报文结构忽略了最基础的一步——确认现场设备确实具备被遥控的条件。这不是废话这是多少血泪教训换来的。对于实际的保护测控装置你要检查的至少包括遥控出口硬压板是否在投入状态。压板没投装置就算收到了遥控命令也不会真正驱动出口继电器。操作方式是否在远方位置。很多装置面板上有个就地/远方切换开关打在就地位置时远方的遥控命令会被装置直接拒绝。机构箱或者断路器操作箱的储能是否正常、控制电源是否送上。控制电源没送发再多的命令也没用。对于需要双点遥信的场合确认辅助触点接入的是哪一对分合闸位置是否和后台定义一致。我记得有个电站的项目遥控合闸命令发下去装置也返回了执行确认但现场开关纹丝不动。我们排查了两三个小时最后发现是控制回路里那个就地/远方把手打在了就地位置装置自动把远方命令屏蔽了。这个问题的报文表现跟正常完全一样如果不看现场你永远找不到原因。所以做104遥控联调先跑现场再看报文。硬条件不满足协议层面做再多测试都是空中楼阁。4.2 初始化、总召唤与时钟同步链路稳定的三部曲104链路建立之后通信的第一阶段不是传数据而是握手初始化。主站向子站发送STARTDT激活命令子站返回STARTDT确认然后主站发总召唤命令C_IC_NA_1类型标识100子站收到后先回一个总召唤确认然后逐个把所有的遥信、遥测数据都发一遍全部发完后回一个总召唤结束命令。总召唤的作用就是让主站和子站的状态完全对齐。相当于你刚进办公室把所有文件从柜子里翻出来摊在桌面上点一遍。而遥控遥调测试能不能做跟链路是否完成初始化密切相关——如果你还没发起总召唤就开始遥控很多子站装置会认为链路状态不对直接拒绝执行。时钟同步同样重要。104报文里带有时标如果主站和子站时间差太多遥控命令的SOE时标事件顺序记录就会出现时间偏移影响事后追忆。一般主站在链路建立后会发时钟同步命令C_CS_NA_1类型标识103把子站时间校准到和主站一致。这里要留意的是有些老装置的时钟同步只接受整秒不接受带毫秒的精度同步命令发下去后对时有偏差但不影响遥控功能本身。4.3 单点遥控还是双点遥控选择命令里怎么填104规约里的遥控支持单点遥控和双点遥控。单点遥控用0和1表示分和合双点遥控在ASDU里用两个bit位表示。实际工程中绝大多数断路器、隔离开关都是用双点遥控双点的好处在于可以区分合位分位中间态故障态四种状态更符合电力系统的安全要求。在测试工具里做双点遥控时你要填的不仅仅是合或者分还有一个选择/执行的步骤。主站发给子站的选择命令里会带一个限定词——选择(SELECT)或者执行(EXECUTE)。选择命令通常对应类型标识45执行命令对应46但具体行为取决于子站装置是选择执行分离还是选择执行合并的工作模式。国网和南网的规范里普遍要求采用先选择后执行的模式。也就是说主站必须先发选择命令确认子站选择成功后再发执行命令。而部分进口装置或者某些老式RTU可能采用直接执行模式只发执行命令即可不需要先选择。测试前一定要确认好装置的工作模式否则你会看到子站返回命令拒绝。这里还有一个细节测试工具的遥控命令里有不带时限和带时限之分。带时限的命令在超时后自动撤销不带时限的命令会一直保持。实际测试中我习惯用不带时限的来做如果失败了可以慢慢抓包分析。但现场运行时遥控执行命令一般会带短暂的超时防止主站和子站之间出现网络抖动后命令悬挂。4.4 遥调命令的归一化设定值到底怎么计算遥调相比遥控多了一个关键环节设定值的计算与转换。这里必须用实际案例讲明白否则很多人在厂里卡住半天还云里雾里。假设现场有一个有载调压变压器遥调的功能是调节变压器分接头位置。分接头范围是1档到17档中档是9档。部分装置的设定值用的是归一化值-1.0到1.0之间对应0x0000到0xFFFF的原始整数范围。但实际装置里归一化值用16位有符号整数表示范围从-32768到32767对应-1.0到1.0。这个换算关系如下假设你要把分接头调到第13档量程是1档到17档那么实际值对应的归一化标幺值可以这么算(13 - 9) / (17 - 1) 4 / 16 0.25所以归一化值为0.25转换成16位有符号整数就是 0.25 × 32767 ≈ 8192。在测试工具里你要填的设定值就是8192或者直接用归一化系数0.25看工具支持哪种输入方式。如果你用的测试工具支持直接填工程量实际物理值那它内部会自动做转换如果工具只支持填原始值你就必须自己算好。很多测试工具界面里那些看起来差不多的输入框填错一个就全部乱套。我建议你把下面这套换算写在手边标幺值归一化值 实际工程值 - 量程零位 / 量程满度 - 量程零位16位原始值 标幺值 × 32767注意有的装置用的是32768看厂家定义4.5 做一次完整的遥控测试并核对报文理论说了这么多现在走一遍完整的实操。假设我们要对一个双点遥控点位地址0x2001做合闸测试主站和子站已经建立TCP连接链路已经激活总召唤已经完成。第一步在主站测试工具里选择遥控填写信息体地址0x2001十进制8193选择双点选择合然后点击选择。主站发出的报文大致是68 0E 00 00 00 00 2D 01 01 00 01 20 01 00 81 01 00。前半部分是APCI后半部分是ASDU。61看着复杂但你要重点关注里面几个字节类型标识是2D45进制45信息体地址是20 01注意字节顺序低字节在前限定词是01表示选择命令合位。第二步子站收到选择命令后如果允许操作会返回一个相同类型标识的确认帧。如果子站因为某些原因拒绝比如就地/远方把手在就地位置会返回带否定确认的报文。第三步主站收到选择确认后点击执行。此时会发出类型标识46的报文限定词表示执行。子站收到后返回执行确认然后驱动出口继电器动作。第四步现场开关动作后子站上送双点遥信变位报文类型标识3双点信息内容从分位变成合位。主站收到这个变位整个测试流程才算闭环。测试完成后务必要在测试报告里记录以下信息时间、操作点位、操作类型选择/执行、命令是否成功、子站确认类型、遥信变位是否回来、变位时间与命令时间的差值。这个差值能反映整个链路的响应速度如果超过几秒钟说明链路或者装置存在延迟需要进一步排查。5. 调试过程中最常踩的8个坑与排查办法5.1 命令发出去了子站没任何反应这是最常见的现象。优先排查顺序是先用抓包工具看报文是否真的到了子站如果抓包都看不到那就是网络层问题再检查公共地址是否一致地址不一致子站会直接丢弃然后检查链路是否处于激活状态很多装置要求在STARTDT激活后才能接收控制命令最后检查信息体地址是否配置正确地址错了对端就不知道你在遥控谁。我见过最隐蔽的一个案例报文全部发到了子站公共地址正确链路也激活了但子站就是没反应。后来抓包发现主站发给子站的ASDU里面信息体地址高字节和低字节写反了。104是低字节在前的传输顺序也就是小端序。某个外购模块软件在处理时用了大端序导致地址变成了0x0120而不是0x2001。这类问题靠肉眼看报文很难发现只有用解析工具看清楚每个字段的字节序才知道。实操建议调试时把Wireshark抓的104报文和测试工具发的报文逐字节对照一遍。特别关注类型标识、传输原因、公共地址、信息体地址、限定词这五个字段只要这几个对了遥控遥调基本不会出大问题。5.2 选择成功了但执行命令被拒绝选择命令发出去子站能正常确认说明通信链路和点表都通了。执行命令被拒绝原因一般是选择后超时未执行装置内部自动撤销了很多装置的选择有效时间只有10到30秒。装置处于闭锁状态比如有保护动作、有未复归信号。执行命令里的限定词和选择命令里的状态不一致。选择了合位执行时却发了分位装置会拒绝。某些装置要求执行命令里的限定词跟选择命令一模一样包括时限标识不一致就会拒绝。排查思路确认选择到执行之间的时间间隔别超过装置的允许范围核对执行命令的限定词查看装置面板或者SOE记录里有没有闭锁信号。有时候从报文上看不出任何异常但装置本地的闭锁条件就是不让执行这种看不见的阻挡只能靠装置侧信息去定位。5.3 执行成功了但遥信没回来这个问题的本质是遥控动作成功了但反馈回路出了问题。可能的原因包括装置的遥控出口动了但遥信采集的辅助触点没接对比如辅助触点接触不良。遥信点表配置错误——装置上送的变位地址和你监控的点位地址对不上。遥信用了单点但遥控点是双点两者状态映射没有对齐。变位报文发出来了但主站软件的实时库刷新机制异常没有及时更新状态。我在实际中遇到最多的情况是第三种和第四种的结合体子站明明上送了双点变位主站侧却因为实时库点表映射配置错了把双点信息当成了单点信息解析导致界面显示不正确。排查技巧是看主站收到的原始报文里信息体地址和状态位再对照主站后台的数据库定义。5.4 总召后一切正常但不做总召就没数据有同事问过我链路激活之后我发了总召唤数据都上来了遥控也正常。但第二次连接时链路激活了我只发了总召唤却什么数据都没有。这怎么回事这个问题的实质是子站是否有变化数据上送机制。104规约里除了总召唤外还有突发数据即变化数据主动上送机制。如果子站侧没有开启变化上送功能或者主站侧没有在总召唤后设置允许突发数据的状态那么设备状态不变数据就不上来只有总召唤时才全量上送一次。所以在配置主站时链路激活后除了发总召唤还应该发起允许突发数据有时也叫解除锁定或允许事件命令。有些规约调试软件会把总召唤和允许突发合并成一步但如果你用的工具是分步操作漏掉允许突发这步就会出现上述现象。5.5 总召唤和时钟同步的先后顺序有讲究吗有。标准流程是链路激活后先对时再总召唤。原因很简单如果先总召唤再对时总召上来的变位和遥测数据都带着旧时间戳主站事后追忆时时间就乱了。先对时再总召能保证所有上送数据的时标统一。有朋友会问总召唤的时间那么长数据那么多中间如果又来了一个事故变位怎么办规约里已经考虑到了总召过程中突发数据是可以插入的不会丢。具体机制可以简单理解为总召是扫全量事件是报增量两不冲突。你看到总召过程中夹杂几个变位报文这是正常现象不要当成异常。5.6 遥控命令的传输原因填激活还是确认传输原因COT是104规约里最容易忽视但最重要的字段之一。遥控选择命令激活的传输原因一般是6激活而对它的确认帧传输原因是7激活确认。如果你用测试工具手动组报文把这个填成别的值比如1或2子站很可能直接丢弃。此外总召唤的传输原因填6激活总召唤确认和总召唤结束的传输原因都是7。很多初学104的人把激活和激活确认搞混导致报文发出去对端没反应还以为是装置坏了。5.7 老装置的特殊性短帧地址不连续、单双点混用电力系统里存量最多的其实不是最新款的装置而是那些服役了十几年的老设备。老装置有些协议实现非常个性化有的遥控点表的地址不连续中间跳着走有的遥信单双点混用——一部分用单点遥信类型标识1一部分用双点遥信类型标识3。这些现象不一定不合规但它们确实增加调试的工作量。我的建议是拿到任何一台你没接触过的装置不要只看它型号新不新先找厂家的点表配置工具生成的实际点表文件把每个点位的类型、地址、量程都过一遍。104规约的表层规则是统一的国标但内部实现细节百花齐放。程序能跑起来不代表没有隐患表和实际装置不一致才是最大的坑。5.8 通信断链又恢复后遥控还能不能做这是一个很多人忽略的场景。TCP链路断开后主站会重新连接子站但104规约规定链路重新建立后主站必须重新启动链路STARTDT重新发起总召唤然后才能继续控制操作。如果你在链路恢复后直接发遥控命令很多子站实现会认为链路没有完全初始化直接拒绝。我曾经遇到一个项目抓包看到主站重连后没发总召唤就直接发了遥控命令子站回复未激活主站侧报控制超时两边来回扯皮了半天才发现是这个原因。另一层的注意事项是104规约里有一个发送序号和接收序号的同步过程。TCP重连后序号会重新从0开始主站发的启动命令会携带序号子站确认后序号才同步。如果你用测试工具手动模拟记得每次连接后第一件事是恢复序号再做初始化。6. 调试习惯与经验沉淀6.1 记报文日志是调试的第一生产力我见过太多调试人员出了问题时第一反应是再看一眼工具界面而不是翻日志。但很多104的偶发问题一旦界面刷过去就再也抓不到了。所以我强烈建议调试全程开着报文记录哪怕觉得应该不会再出问题的时候也开着。日志文件不用太大按小时切割保留最近几天的就行。分析报文日志时也有技巧。不要从第一帧开始逐帧看那是大海捞针。先筛选出你想关注的类型标识比如45、46、50、51再看传输原因和公共地址最后看信息体地址。用Wireshark的过滤器104关键字一下就能把所有TCP 2404端口的报文滤出来配合Follow TCP Stream功能能非常直观地看到一次完整的遥控交互过程。6.2 测试用例设计别只会点了试试做遥控遥调功能测试不能想到哪测到哪否则你测过了也不代表真没问题。我自己习惯把用例分成这几类链路层用例TCP建链、STARTDT激活/停止、TESTFR测试帧、序号异常处理。应用层正向用例单点遥控选择执行、双点遥控选择执行、遥调设定、总召唤。应用层反向用例信息体地址越界、公共地址不匹配、类型标识错误、重复激活、未选择直接执行、选择后超时执行。异常场景用例通信断链后恢复、总召唤未完成时来变位、子站重启。每类用例都要有明确的预期输出比如预期子站返回XXX报文开关Y动作。测试完把报文截图和结论填进记录表归档以后遇到问题可以直接回溯。6.3 测试工具好用的不等于报文就好市面上有些104调试软件把遥控点击做得非常傻瓜化界面上一个合闸按钮点一下自动帮你把选择、执行的报文全发了看起来很方便。但这类工具恰恰容易掩盖问题——它可能自动跳过了选择步骤或者自动帮你把限定词填好了一旦实际现场装置要求严格的选择执行分离你用这个工具测出来的成功就没有参考意义。我的建议是准备两套工具一套傻瓜化的用来快速验证链路和基本功能另一套能逐帧编辑报文的不管开源还是商用用来做细致的协议层诊断。真正到了排查疑难问题时能手动组帧的工具才是你最大的靠山。6.4 遥控联调必须带着脑子去测说了很多技术细节最后还是想给大家交个底。遥控遥调之所以在104规约里被单拎出来讲是因为它跟遥测遥信有本质不同遥测遥信是拿数据坏了大不了数据不对危险性有限遥控遥调是下发指令一旦方向反了、点位错了、逻辑错了轻则设备误动重则引发事故。所以我在每一次联调前都会执行一套固定的死规矩拿到点表后先跟设计图纸核对一遍确认点位含义、地址区间、类型单选/双击。现场操作前确认把手、压板、电源状态不具备条件绝对不操作。每一条遥控命令下发前先在测试工具里核对方向合/分和点位地址再点发送。测试完成后在后台查看事件记录确认SOE和操作记录完整。把联调过程中的所有报文日志、点表截图、测试记录归档方便后续追溯。这套习惯看上去繁琐但每一条都是真金白银换来的教训。搞规约调试这行技术好当然重要但更值钱的是稳——在正确的时间做正确的操作不冒进、不省略、不拍脑袋。6.5 从会调到会设计再往前走一步如果你已经不满足于仅仅会调试想往更深的层次走建议去研究一下104规约在变电站自动化系统里的整体位置。遥控遥调不是一个孤立的功能它跟间隔层装置、站控层后台、调度主站、网络安全防护装置都有千丝万缕的关系。你只有把规约放到整个系统里看才能明白为什么某些报文的设计如此绕为什么某些字段非要有不可。有条件的可以自己搭一个迷你环境一套规约仿真软件一台真实的测控装置哪怕是教学用的一套监控后台。用这个环境把今天文章里说的所有测试用例完完整整走一遍。纸上得来终觉浅绝知此事要躬行。规约这种东西光看文档永远只能知道皮毛真正上手调一调、抓一抓包、踩一踩坑才算真正入了门。从第一次调试104遥控时的满头问号到后来能熟练地在各种装置之间周旋这个过程中积累下来的经验远比任何一本规约书上都来得深刻。希望这篇长文能给你省下几条弯路咱们在现场碰头的时候可以直接聊点更有意思的。