4.2 轮询、上送与链路看护

4.2 轮询、上送与链路看护

本节摘要：协议定了之后，通信层的设计产出是一份「契约」：谁在什么周期问什么、谁在什么条件报什么、超时多久算断、断了缓存多久、恢复后怎么补。本节讲轮询与上送混合调度的设计方法、广域带宽的估算口径、链路看护的关键参数，并用一段真实报文解读契约在路上的样子。

轮询不是原罪

beginner 常把「轮询」当成落后技术、把「上送」当先进标志，实际两者是互补关系：轮询给你确定性（每个周期全量数据必然刷新一遍，通道健康度可量化），上送给你及时性（突变第一时间到达）。成熟的设计是混合调度：常规遥测按周期轮询兜底，重要事件与突变量走主动上送，总召用于校核与恢复补传。判断一个系统调度设计好不好，就看这三者的分工是否清晰、参数是否互相咬合。

一、混合调度的设计方法

轮询周期的分级。 不必所有点一个周期。按用途分三级：参与显示与统计的常规遥测按秒到十秒级；变化缓慢的量（温度、库存液位）放宽到分钟级；联锁相关的遥信不靠轮询——它们走变化上送，轮询只作为校核。水厂项目的口径示例：泵电流与出口压力两秒一轮，水池液位十秒一轮，进出水温度六十秒一轮。

上送的触发条件。 事件类（状态变位、越限发生与恢复）无条件上送；模拟量突变按死区触发（3.2 节已定死区）；心跳按固定周期发送证明链路存活。上送报文带源端时标，这是 4.1 节选型时反复强调的硬要求。

总召的时机。 全量校核不是日常动作：通道恢复后、主站重启后、每日低峰定时一次足矣。总召报文大、耗时长，放在业务高峰会挤占事件通道。

带宽的估算口径。 广域带宽按「轮询流量 × 站数 ÷ 周期 + 事件风暴余量」估算。给一个数量级感受：一座五十点泵站、两秒轮询、每帧报文几百字节，平均流量每站每秒几百字节，一百座站也只占几兆带宽；真正的带宽压力来自事件风暴（某工艺系统异常时成片越限同时上送）与总召（多站同时重启补传）。所以余量留的不是平均值，是风暴值——按「同站全部遥信变位加两成遥测越限」的假想风暴校核。

二、链路看护的关键参数

链路看护回答三个问题：怎么判定断了、断了怎么办、恢复后怎么收尾。

超时与重试。 请求发出后多久算超时（典型按正常往返时延的数倍设置），超时重试几次（典型两次到三次），连续几轮失败判链路断（典型一轮到两轮）。参数要互相咬合：超时太短，正常抖动被误判；太长，故障发现滞后。一个可用的起点：广域通道超时设为正常往返的四倍、重试三次、连续两个轮询周期全失败即报通道中断告警。

断链期间的行为。 站端网关启动缓存（3.2 节的时长与容量在此生效）、本地策略继续自治；主站侧将对应站测点标记「未刷新」状态，画面用灰色或问号呈现，而不是把旧值伪装成实时值——这是数据可信原则在通信层的直接体现。

恢复后的收尾。 通道恢复先做总召补传，核对缓存数据按时间序回补完整，再恢复常规调度；补传完成前，主站对该站数据保留「回补中」标记，防止统计口径混入乱序数据。

三、一段真实报文的解读

拿 104 规约初始化后的首轮对话（已简化）看看契约长什么样：

主站 -> 站端  STARTDT_act            启动数据传输
站端 -> 主站  STARTDT_con            确认，链路进入传输态
主站 -> 站端  C_IC_NA_1 总召激活      要求全量数据
站端 -> 主站  总召激活确认            收到，准备发送
站端 -> 主站  遥信帧 带毫秒时标        全量状态逐帧上送
站端 -> 主站  遥测帧 带品质描述        全量模拟量逐帧上送
站端 -> 主站  总召结束                全量校核完成
主站 -> 站端  时钟对时命令            下发标准时间
站端 -> 主站  对时确认                站端时钟回读
​

这段对话里有四个值得咀嚼的细节。其一，「确认」是双向的：每一份职责都有回执，STARTDT 与总召都是「请求加确认」成对出现。其二，遥信帧带毫秒时标，事件顺序的裁判权在站端。其三，遥测帧带品质描述字节，坏质量在规约层就有位置承载。其四，对时由主站主动发起并回读校验——时钟不是「配一次管十年」的东西，它的偏差需要被持续测量。这四个细节分别回应了第 1 章埋的四个可信性要求：可确认、可排序、可标记质量、时间有基准。

四、案例：参数咬合不当的一次误报

某项目投运初期，「通道中断」告警每天频发但通道实际正常。排查记录显示：超时参数按出厂默认五秒，而其中一座站走了运营商无线备份通道，晚高峰往返时延经常超过五秒；重试三次叠加，单次轮询最长拖到十五秒，主站又在十五秒后直接判断并告警。整改把参数按通道特性分组：光纤通道维持默认，无线通道超时放宽到十秒、判断条件改为连续三个周期。误报消失，真故障的发现时间也没有变长——因为真故障时无线通道时延是彻底无应答，与晚高峰的慢应答在报文层面是两种现象。案例的解读：链路看护参数不是通用常数，而是按通道画像分组的一组契约；把「慢」与「断」区分开，是看护设计的手艺所在。变式思考：如果两条通道互为主备，告警判据又该怎么改？提示：判「主备全断」而不是「单通道断」，才不会在主通道检修时被告警淹没。

五、遥控链路：下行方向的特殊契约

前面的篇幅都在讲上行（数据到中心），遥控的下行方向需要一组更严的契约，因为它的错误后果直接作用于物理世界。指令的唯一性：一条遥控指令要有编号与时效，过期指令到达现场必须拒执行——防止网络迟滞造成「旧指令迟到执行」。选择的先行：先发选择令，站端返校核对对象无误，再发执行令——两段式确认把「点错对象」拦在动作之前。执行与返核：站端执行后主动上送动作完成事件，主站核对对象状态翻转才算成功；超时未返核即生成「遥控失败」事件并进入人工核查流程。并发互斥：同一对象的遥控在途时，新的遥控请求排队或拒绝；调试与运行模式互斥，联调期间遥控权限锁定。这套契约与 1.1 节的三道闸一脉相承，落点却在通信参数上：指令时效、返核超时、重发策略，每一项都要在通信契约里写明数值。遥控链路的验收也据此设计：模拟返核超时、模拟对象拒动、模拟指令迟到，三种异常场景的反应都符合契约，遥控才算验收通过。

本节要点回顾

• 混合调度三件套：轮询兜底确定性、上送提供及时性、总召负责校核与补传，分工要清晰。

• 带宽留风暴值：平均值很小，事件风暴与批量补传才是容量设计对象。

• 看护参数按通道画像分组：超时、重试、判断条件互相咬合，「慢」与「断」要分开判。

• 断链不伪装：未刷新的数据如实呈现，恢复后先补传再恢复调度。

契约都定好了，真断了怎么办？下一节把两场真实故障从头到尾复盘一遍。