FS-C3 — 看门狗三档(simple / window / Q&A):为什么只有问答式才算一个真正独立的监控 channel

更新

本质与导读

专家养成 · 模块一(功能安全)· C 阶第 3 讲。上一讲 FS-C2 拆了安全态:永磁电机没有"零能量"归宿,STO / ASC 由 分界。但那一讲结尾留了个没答的前提——是谁在故障时可靠地扣下 STO/ASC 这个扳机? 主 MCU 自己可能就是失效源:它死锁、跑飞、时序乱了,靠什么独立通道兜底?答案是 SBC 上的看门狗。今天的核心问题只有一个,而且它比"看门狗是什么"深一层:看门狗根本看不见"MCU 是否在正确跑代码",它只能观测一个代理信号(喂狗动作)。三档协议(simple / window / Q&A)的本质区别,是这个代理信号与"CPU 真的还活着且在算"这件真相耦合得有多紧。只有问答式把代理信号绑到了 CPU 的算力上——这正是它才配称"独立 channel"的原因。

开篇:硬约束——监控是一个推断问题,不是一个测量问题

先把问题的性质钉死,否则后面全是招式罗列。看门狗面对的根约束是:它无法直接观测它真正关心的那个量。 它关心的真相是"主 MCU 是否在按预期执行安全应用",但这是一个藏在 MCU 芯片内部、跨 CPU / Flash / RAM / 调度器的复合状态,SBC 从外部一根引脚 / 一条串行总线根本看不到。SBC 能拿到的,只有 MCU 主动送出来的一个代理信号(proxy):一次喂狗、一次寄存器写入、一个电平翻转。

于是看门狗设计的全部功夫,都落在一件事上:让这个代理信号尽可能紧地耦合到你真正关心的健康状态。 用信息论的话说,代理信号能承载多少关于"MCU 真健康"的信息,决定了这个诊断的覆盖能力。耦合松,就存在大片"代理信号正常、但 MCU 其实已经坏了"的假健康区(false-healthy region)——MCU 落在这个区里失效,看门狗浑然不觉,FMEDA 里被 claim 的那份诊断覆盖率是假的。

所以三档协议不是"三种不同的看门狗",而是同一个推断问题上、代理信号耦合强度递增的三级台阶。评判每一档的唯一尺子是:它把假健康区收缩到了多小? 下面逐级推,看每一档具体堵掉了哪一类"坏了却还在喂狗"的失效,以及为什么到 Q&A 这一档,假健康区才小到能让 SBC 真正宣称"我在替 channel A 兜底"。


中段一:simple 与 window——代理信号只绑住"控制流的存在与节律"

最基础的 simple watchdog:MCU 在超时窗 内喂一次狗,计数器清零;超时未喂则 trip。它的代理信号是"一次喂狗在 内到达"。这个信号耦合到的真相是:"有某条代码路径周期性地到达了 feed()"。

它能堵住什么、堵不住什么,由这个耦合直接决定。CPU 整体死锁(hang)、时钟停摆、跑飞到一段永不返回 feed() 的地方——喂狗动作随之消失,超时 trip,这一类"控制流完全停止"的失效被覆盖。但它对另一类失效完全瞎:MCU 跑飞进了一个仍然周期性碰到 feed() 的死循环——比如中断风暴里喂狗 ISR 照跑、或应用主逻辑挂了但喂狗 task 独立存活。代理信号照常到达,看门狗判"健康",而应用其实已死。这就是 simple WD 的假健康区:一切"控制流没停、但停在了错误的地方"的失效。 ISO 26262 因此只给"有独立时基、但无时间窗"的看门狗**低诊断覆盖(low DC)**的资格(据 ISO 26262-5/-6 的 DC 分级表与 ADI 等厂商解读)。

window watchdog 加一条约束把假健康区削小一块:喂狗必须落在 窗口内,早喂也 trip。为什么加下限就有用?因为它给代理信号绑上了节律这一维信息。一个跑飞进紧凑死循环的 MCU,循环执行极快,会早于 就把狗喂了——simple WD 看不出,window WD 立刻 trip。同理任务超载导致的迟喂也被上限抓住。于是 window WD 把"控制流节律异常(太快/太慢)"这一子类从假健康区里挖了出来,ISO 26262 相应给它中诊断覆盖(medium DC)

但 window WD 仍有一块顽固的假健康区没堵:一个跑飞的 MCU,只要它碰巧在合法窗口内喂了一次狗,就蒙混过关。喂狗这个动作本身太廉价——它不要求 MCU 证明任何"算力"。代理信号绑住了控制流的存在节律,却没绑住控制流的内容:CPU 到底还会不会算。要堵这最后一块,代理信号必须涨价——喂一次狗必须以"做一次正确的计算"为代价。这就是 Q&A。


中段二:Q&A——把代理信号绑到 CPU 算力上,靠的是"不可预测"三个字

问答式(challenge-response)看门狗把喂狗从"送一个廉价动作"改成"答一道现出的题":SBC 内部用一个 16-bit LFSR 生成一个伪随机 challenge,MCU 必须读到这个 challenge、按约定的确定性变换算出 answer、在窗口内写回,SBC 比对正确才刷新窗口(据 NXP FS65/VR5510 challenger WD:默认种子 0x5AB2,答错时 LFSR 不重新生成、错误计数器累加,见 SBC Watchdog 深度)。

关键要看清:为了产出这一个"正确 answer"的代理信号,MCU 必须让一整条算力链同时活着——读 challenge(串行总线活)、执行变换算法(ALU 与取指/译码/跳转的程序流活)、从 Flash 取到算法/查找表(Flash 完整)、维护跨轮状态(RAM 活)、且在窗口内完成(时基/调度活)。代理信号第一次和 CPU 的计算能力发生了因果纠缠:一个跑飞的、不再执行正确程序流的 MCU,算不出这道题。simple/window 那块"跑飞但还在喂狗"的假健康区,到这里被物理地堵死了——因为喂狗不再是一个能被残废 MCU 偶然触发的廉价动作。

而"不可预测"三个字是这整套机制的承重墙,不是实现细节。设想 challenge 是固定的:一个跑飞的 MCU 只要曾经存过一次正确 answer,就能无脑重放(replay),代理信号立刻与算力解耦——它证明的不再是"我现在能算",而只是"我曾经算过"。这与密码学里 nonce 的作用同源:challenge-response 的诊断强度,等于应答方每一轮被迫消耗、且无法预先算好的那份熵。 熵一旦可被预测或重放,Q&A 就退化回 simple WD(这正是弱 LFSR 种子的危险——注入退化种子让 challenge 可预测,覆盖悄悄塌陷)。前面提到的"答错时 LFSR 不重生成"细节在这里反而是加固:它让所需的正确 answer 在错误期间冻结在一个未知值上,一个乱答的 MCU 只能靠撞中这个唯一值过关,概率极低——下一节把这个概率算出来。


中段三:worked example——量化 Q&A 对"跑飞乱答"失效的覆盖与检测时延

前一讲的姊妹深页已算过纯时间预算(10 ms 窗口 vs 100 ms FTTI),这里换一个角度算 Q&A 真正独有的东西:它把"跑飞但还在喂狗"这一子类失效的覆盖率,从 window WD 的约 0 抬到了多少。 这是一个可以从第一性原理(熵)直接推的数,不需要查表。

建模。 把最刁钻的失效设成"babbling runaway":MCU 跑飞了,不再执行正确变换,但仍在每个窗口往回写一个均匀随机的 16-bit answer(比"重放旧值"更宽容的假设,因为重放在 LFSR 冻结下几乎必错)。应答空间与 16-bit challenge 同阶,故单轮蒙对概率

检测的计数器机制。 FS65 家族用滞回错误计数器:答错 、答对 、数到 final(,默认)触发 deep fail-safe(增量以 SMUG 为准,见深页)。从全对(计数 0)到 final,需连续 3 次答错:。所以一个彻底算不出题的 MCU,恰好在第 3 轮被逮住。

覆盖率 = 3 轮内被逮住的概率。 babbling runaway 每轮"答对(逃脱一次累加)"的概率只有 ,故前 3 轮全错、从而必在第 3 轮 trip 的概率:

≈ 99.995%:一个乱答的跑飞 MCU,在 3 轮内被问答式看门狗逮住的概率约 99.995%。逃脱需要它在 3 轮里至少撞对一次(概率 ),而撞对只把计数器 、仅延迟一轮,drift 仍压倒性向上(要长期压住计数器需答对率 ),故期望 trip 时间几乎仍是 3 轮。

换算成时间,接回 FTTI。 取窗口周期 :检测时延 ,加硬件反应(SBC 拉 FS0B + 栅驱关栅传播数 )。对失控类危害的 有约 余量——这条链吃得进 FS-A3 立的时间预算。

诚实边界(这个 99.995% 覆盖的是什么、不覆盖什么)。 这个数不是看门狗对 MCU 全部危险失效的总 DC,只是它对"丧失计算活性 / 程序流跑飞"这一失效类的覆盖。看门狗对另一大类失效——CPU 数据通路被腐蚀、但仍算出了一个合法 answer(例如 ALU 偶发位错却恰好不影响这道题、或 RAM 里的控制变量翻转但喂狗算法路径无恙)——覆盖几乎为 0,因为这类失效不改变代理信号。正因如此,ISO 26262 把软件 Q&A WD 归在 low DC、把 window WD 归 medium:单靠看门狗这一条通路永远够不到 High(≥99%)。High 只能靠第二个独立物理观察源实时比对——那是 channel A 里 lockstep 双核干的活(见 Lockstep 核深度FS-C1)。看门狗与 lockstep 各覆盖一类失效,不是竞争关系,是互补。


中段四:为什么"独立 channel"= 独立观察 + 独立反应,Q&A 只解决了前一半

curriculum 的题目说"为何 Q&A 才算独立 channel"——这句话要拆精确一点,不然会误导。独立性和诊断覆盖是两个分开的要求,而三档协议动的其实只是后者。承载看门狗的 SBC,无论跑哪一档协议,都可以是物理/时钟/软件/电源四项独立于 MCU 的(单独一颗 die、内部时基、内置 ROM 算法、独立 LDO)。所以严格说,不是"只有 Q&A 才独立",而是:一个独立的监控器,只有当它的诊断覆盖深到能真正逮住 channel A 的危险失效时,它才够格在 ASIL D 分解里被算作一条能"闭合论证"的 channel B。 simple/window 的 SBC 是独立的,但它对 channel A 的计算失效覆盖太浅,填进 FMEDA 撑不起 channel B 该给的 DC;Q&A 把覆盖抬到够用,这条 channel 才立得住。这是本讲要对那句口号做的一次精修(第一性原理压过顺口的说法)。

但即便覆盖够了,"独立 channel"还差一半没解决——反应路径的独立性。看门狗逮住了 MCU 跑飞,可如果它还要指望这个已经跑飞的 MCU 去执行安全态,那等于让病人给自己做手术。所以 SBC trip 时必须绕开 MCU:直接拉硬件安全输出 FS0B/FS1B,命令外部栅驱执行 STO 进上一讲的安全态,全程不经 MCU 决策(SBC 上并无字面 STO 引脚,STO 是被 FS0B 命令出来的)。独立观察(Q&A 给的覆盖)+ 独立反应(FS0B 直连给的旁路),两半合起来才是一条真正的独立 channel。 这与 FS-C2"把 ASC 能力下沉进栅驱硬件、不经 MCU"、FS-A3"快故障必须离开软件域"是同一条第一性原理的三个侧面:兜底机制绝不能把自己的生死系在被兜底的那个部件上。 完整的两级保护分工见 安全状态管理器深度


落到工程结论:选档与配置的判断链 + 三条准则

给定一个"要用看门狗兜底 MCU"的场景,专家的判断链是:

  1. 先按 ASIL 与失效类选档,不要默认最贵:要覆盖的是不是"控制流跑飞/程序流错乱"这一类?ASIL B 上限用 simple 足够;ASIL C 用 window;ASIL D 主驱必须 Q&A——因为只有它堵住"跑飞但还在喂狗"的假健康区。经济车身档用 window/timeout SBC 反而对,上错档次要么防不住、要么白烧成本。
  2. 算法与不可预测性入安全评审:challenge 必须真伪随机(用厂商验证过的默认种子如 0x5AB2,别让应用工程师随手填退化种子);算法用厂商 reference code。把"种子选取"当安全项而非配置项,否则 Q&A 会静默退化成 simple。
  3. 窗口周期由 FTTI 反推,不是拍脑袋:检测时延 ( = 触发 final 所需连续错次,FS65 家族 、final 6 → );要求 。FTTI 收紧(高转速工况)就得降 ,或向 SMUG 核实计数器实际增量。
  4. 别把看门狗当全能诊断:它只覆盖"程序流/计算活性"一类,数据通路腐蚀、RAM 内容错要交给 lockstep + ECC + plausibility。看门狗的 DC 在 FMEDA 里按 low/medium 老实填,想要 High 去找第二个独立比对源。
  5. 反应路径必须旁路 MCU:trip 直连 FS0B/FS1B → 栅驱 STO,写进 TSR;HIL 上注入"跑飞乱答""迟喂/早喂""弱种子"三类故障,示波器核检测时延 + 反应时延落在 FTTI 内(接 FS-A3/FS-C2 的实测闭环)。

带走三条准则:

  1. 看门狗看的是代理信号,不是真相;三档的差别是代理信号与"CPU 真活着且在算"耦合得多紧。 simple 绑控制流的存在(低耦合)、window 加节律(中)、Q&A 绑算力(高)——每升一档,收缩一块假健康区。
  2. Q&A 的诊断强度 = 应答方每轮被迫消耗、且无法预算/重放的熵。 不可预测是承重墙:种子退化或 challenge 可预测,Q&A 立刻塌回 simple。本例里 16-bit 熵给出对"跑飞乱答"约 99.995%(3 轮内)的覆盖。
  3. "独立 channel" = 独立观察 + 独立反应,且都不能依赖被监控的那个部件。 Q&A 给足观察覆盖,FS0B 直连给反应旁路;兜底机制把生死系在被兜底件上,就等于没有兜底。

承上启下:今天我们看清看门狗是一个推…

承上启下:今天我们看清看门狗是一个推断问题——三档协议在收缩"坏了却还在喂狗"的假健康区,只有 Q&A 把代理信号绑到 CPU 算力上,再配 FS0B 直连的反应旁路,才凑齐一条真正独立的 channel B。但这里埋了一个没细究的前提:那条"MCU 必须按约定算法、在窗口内、用正确种子喂狗"的规矩,到底写在哪、由谁保证 MCU 侧真照做?SBC 是一颗脱离具体整车语境开发的现货安全件(SEooC),它对使用者提出的正是这样一串"使用假设(AoU)"。下一讲 FS-C4 拆 SEooC 接口工程:AoU(Assumptions of Use)与 Safety Manual 如何双向闭合——今天看门狗那些"喂狗算法/时序/种子"的约束,正是 AoU 里最典型的条目。预热可读 MCU-SBC ASIL D 集成


延伸阅读