SBC Watchdog 深度 — Simple / Window / Q&A + MCU 协同

看门狗的本质都是"MCU 定时喂狗,超时则 reset",但喂的方式 + 验证深度决定保护强度。Simple 只看时间;Window 加时间窗口;Q&A 还验算法正确性。下图把三类时序 + Q&A 详细协议一次画清:

最基础形式:MCU 任何时间在 Tmax 内喂一次,WD 计数器 reset;超 Tmax 未喂 → WD trip → SBC 拉 nRESET。

实现:

void main_task(void) {
  while (1) {
    // application code...
    feed_watchdog();  // GPIO toggle 或 SPI write
    delay_ms(50);
  }
}

保护强度:

• ✓ MCU 整体卡死 (CPU hang) → 喂狗 task 也停 → reset
• ✗ 死循环里调 feed_watchdog():仍喂狗,WD 不 trip,application 实际挂了
• ✗ stuck loop:也喂狗,WD 不查 application 在哪里

ASIL 上限 B。EV 主驱不够。

升级版:喂狗必须在时间窗口 [Tmin, Tmax] 内,早喂也 trip。

典型:

• Tmin = 5 ms
• Tmax = 15 ms
• 喂狗时间窗口宽度 10 ms

实现:

void main_task(void) {
  uint32_t last_feed_us = get_time_us();
  while (1) {
    // application code...
    uint32_t now = get_time_us();
    if (now - last_feed_us >= T_MIN_US) {
      feed_watchdog();
      last_feed_us = now;
    }
    // 不在窗口内不喂
  }
}

保护强度:

• ✓ 同 Simple WD
• ✓ 防"死循环喂狗" — 死循环执行快,会早喂触发 reset
• ✓ 防 stuck loop(任务慢 → 错过窗口)
• ✗ 不能验"喂狗代码"是否真在 main task 里跑(还是被错误调度跑了)

ASIL 上限 C-D。EV 主驱够用但偏简单。

最严:SBC 出题 → MCU 算 → 答。整个 protocol 验CPU + Flash + 算法真在执行。

典型 SBC (NXP FS65 挑战式) Q&A 算法(核到 datasheet / AN14879 Fig.4):

• SBC 内 16-bit LFSR 生成伪随机 challenge,存 WD_LFSR 寄存器(默认种子 0x5AB2;INIT_FS 阶段 MCU 也可注入自己的 seed)
• MCU 读 seed,按固定变换(取反全部 bit + 交换 MSB/LSB)算出 answer,经 SPI 写回——不是查表也不是 CRC,是 LFSR 的确定性变换(不同 SBC 变换不同,见 §5)
• SBC 比对:对 → 刷新窗口 + 生成新 LFSR;错 / 超时 / 喂早(CLOSED 段)→ bad refresh,fault error counter 上升(bad +2 / good −1 是 FS65/TLF35584 家族的滞回模式)
• counter 数到 final(默认 6) → 升级到 latched 的 Deep Fail-Safe(拉 FS0B/FS1B + 关 rail,只能 power-cycle 退出);单次 RSTB 只是重开 256 ms INIT_FS 窗口 retry

通用 Q&A 骨架(算法随 SBC 变:FS65=LFSR 变换 / L9788=64-byte ROM LUT / TPS65381A=计算式):

// MCU 端
void wd_task_10ms(void) {
  uint8_t Q = sbc_read_question();  // SPI 读 SBC
  uint16_t A = compute_answer(Q);    // 加密 / 查表 / CRC
  sbc_write_answer(A);
}

uint16_t compute_answer(uint8_t Q) {
  // 算法在 Flash table + RAM 状态
  uint8_t seed = (Q >> 4) & 0x0F;
  uint8_t counter = Q & 0x0F;
  uint16_t base = ANSWER_LUT[seed];
  return crc16(base + counter);  // 真涉及 Flash + RAM + CPU
}

保护强度:

• ✓ Window WD 所有
• ✓ 验 CPU 真在执行算法(死循环喂狗也算不对答案)
• ✓ 验 Flash 完整性(LUT 数据正确)
• ✓ 验 RAM 状态(counter 递增)
• ✗ 仍不能验 application 逻辑正确(算法本身可能 bug)

ASIL 上限 D,EV 主驱 ASIL D 首选。

下表汇总主流 SBC 挑战式/Q&A 协议特征,每格均核到官方 datasheet(窗口周期几乎都可配,故不列固定周期,以免误当硬值):

原稿曾列 "ST L9784 / MPS MP2932" 两行——核后均属虚构料号误用:L9784 是 ST 发动机管理的传感器接口 IC、无 SBC Q&A 狗;MP2932 是 MPS 的 6-phase VR10/VR11 PWM 控制器、根本不是 SBC。已删,换成上表 5 颗可核实的真器件(见 SBC 页 §5 与 FS65 深页 §3.2)。

EV ASIL D 主流配对:TC397 + TLF35584 / S32K3 + FS65 — 都跑挑战式 Q&A。经济车身档反而用无 Q&A 的窗口/超时狗 SBC(如 NXP UJA1169),Q&A 只在 ASIL C-D 才必需——上错档次要么防不住(见 §2)要么白花成本。

watchdog 错次达阈值 → SBC 不是只 reset,而是多硬件信号同时拉:

1. nRESET / RSTB 拉低 → MCU 复位 → 应用停,并重开 256 ms INIT_FS 窗口 retry(单次不锁死)
2. FS0B(必要时叠 FS1B)安全输出 拉低 → 栅极驱动 IC 的 enable/STO 输入被拉停 → 关栅 → 主驱 safe state
3. FCCU / INTb 通知 VCU 或汇集片内 fault(可选)
4. fault error counter 数到 final(默认 6)→ 进 latched Deep Fail-Safe — 除 VKAM 外全 rail 关断、FS0B+FS1B 同时拉低,只能 power-cycle 退出

注意 SBC 上没有字面 'STO' 引脚:STO 是 IEC 61800-5-2 的安全功能,由 SBC 的 FS0B 命令外部栅驱执行。EV 主驱watchdog trip 直接拉硬件安全输出、不靠 MCU 决策 — 这是 ASIL D 分解 channel B 的本质。

链接:SafeState Manager §3 2nd-Level

EV PEU 开发中 watchdog 是最容易 debug 失败的模块。下表 5 个反复出现的:

ASIL D = B(D) + B(D) 分解时,SBC Q&A WD 是 channel B 的核心:

• channel A:主 MCU 双核 lockstep(开发 B 等级)
• channel B:SBC + Q&A WD + STO 硬件(开发 B 等级)

DFA 4 项独立性证据(见 topic-asil-decomposition-deep §3):

1. 物理独立:SBC 单独 IC,独立 LDO
2. 时钟独立:SBC 内部时钟,不共享 MCU 时钟
3. 软件独立:Q&A 算法跑 SBC 内部 ROM,跟 MCU SW 完全分离
4. 电源独立:12V → SBC 独立 buck,不共享 MCU 主 power

watchdog 是 SBC 监视 MCU 的主要手段,SBC 自身不需要被 MCU 监视(双向不对称是 OK 的)。

EV 主驱 ASIL D Q&A WD 典型参数:

前面讲协议,这节把它落到一块真板子:EV 主驱 PEU,channel B = NXP FS6523(2.2 A FS1b 版安全 SBC:CAN+FS1B,无 LIN)+ S32K344(lockstep MCU)。危害"非预期扭矩输出"的 HARA 定出 FTTI = 100 ms,要验证挑战式 WD 的检测时延 + 硬件反应能否吃进这个预算。

第一步 — 单轮应答延迟(会不会错过 OPEN 窗口):取窗口周期 10 ms、CLOSED/OPEN 各 50% → OPEN 窗口 5 ms。MCU 一轮要读 16-bit LFSR 种子、算 answer、写回,逐项预算:

单轮延迟根本不是瓶颈——真正的紧约束是两条:(a) INIT_FS 首次 good refresh 必须 ≤ 256 ms,否则上电即 RSTB;(b) 连续 miss 到 fault counter final 的检测时延要 ≤ FTTI。

第二步 — FTTI 分解(检测 + 反应):bad refresh 使 fault counter +2、good −1(FS65/TLF35584 家族的滞回;FS65 精确增量以 SMUG 为准),final = 6。MCU 一旦跑飞持续答错,从全对到 final 需连续 3 次 bad refresh,故检测时延 = 3 × 窗口周期 = 3 × 10 ms = 30 ms。再加硬件反应(RSTB/FS0B 拉低 < 1 μs + 栅驱关栅传播数 μs),整链 ≈ 30 ms,远小于 FTTI = 100 ms。

结论:10 ms 窗口对 100 ms FTTI 有约 3× 余量,剩 ~70 ms 留给上游诊断链路 jitter + 安全裕度。但若高转速工况把 FTTI 收紧到 30 ms,30 ms 检测时延就吃满预算——此时必须把窗口降到 ~5 ms(检测降到 15 ms)或向 SMUG 确认 fault counter 实际增量,否则 WD 检测链在最坏工况下无余量。这正是"窗口周期不是拍脑袋填 10 ms,而是 FTTI 反推"的落点。

watchdog 设计失败往往不是协议本身,而是配置 / timing / 测试 4 类问题。下表 7 个典型坑:

挑战式 WD 在三个极端场景最容易暴露盲区,需在 DVT 专项覆盖——都不是协议逻辑错,而是环境 / 种子 / 调度把"本该通过"逼成"误判失效"。