软件功能安全 ASIL D（Software Functional Safety）

考虑这段代码:

if (a && b && c) { do_x(); }

• Statement:跑一次 a=b=c=true 即覆盖
• Branch:跑 (true,true,true) + (false,,) 即覆盖两个分支
• MC/DC:必须证明每个变量(a/b/c)独立影响结果——至少 4 个测试用例(n 个条件需 n+1 例):
  • (T,T,T) → x
  • (F,T,T) → not x(证明 a 影响)
  • (T,F,T) → not x(证明 b 影响)
  • (T,T,F) → not x(证明 c 影响)

MC/DC 抓的是"逻辑表达式有 bug 但其它条件掩盖了" —— 比如 a && b 写成 a || b,statement / branch 可能仍 100% 但功能错。ASIL D 必须 ≥ 90% MC/DC。

工业上不可能手算 MC/DC 用例,要靠工具:

这些工具本身必须 qualified —— 见 §7 工具链 qualification。

根据 HARA Safety Goal 分配软件安全需求到具体核:

ASIL D 软件分区严格隔离:每个 TriCore 核有自己的 MPU —— 18 个 Data Protection Range(DPR0..17)+ 10 个 Code Protection Range(CPR0..9),排布在可切换的 6 组 Protection Set(PS0..5,由 PSW.PRS 字段 0–5 选择);ASIL D 核与 ASIL B 核各配独立堆栈,跨核数据交换走 AUTOSAR IOC(Inter-OS-Application Communication)。

ASIL D + ASIL B 共存时必须满足 Freedom from Interference(FFI,见 §9):配置 ASIL B 核(CPU4)的 MPU,使其 DPR 不覆盖 ASIL D 核的 DSPR / 全局安全数据区——CPU4 若越权写这些地址 → 触发 MPU class-3 同步精确 trap → safety reaction(关 PWM + assert STO)。注意这是靠 FFI 隔离让不同 ASIL 共存,不是 ASIL 分解——两者别混。

WdgM 三类 supervision 全开——单纯 alive 无法检测 task 提前/延迟完成。

WdgM 对接 TLF35584 SBC:TLF35584 同时支持 window watchdog(open/close window 由 integrator 通过寄存器配置)与 Q&A watchdog(challenge-response),ASIL D 项目常用 Q&A 提高诊断覆盖。WdgM 定期向 SBC 发握手;窗口时间为项目配置值(示例:open window ≈ 80ms,低温下按晶振/RC 漂移额外留 +20% 余量 ≈ 96ms)。若 WdgM 任一 supervision 失败 → 停止喂狗 → SBC 窗口超时 reset MCU → TC397 上电重跑 LBIST+MBIST 后重启控制栈。

WdgM 反模式:只配 alive supervision + 10ms 周期任务被调度延迟阻塞 15ms → alive 仍满足(本周期没超时)但 deadline 超了 → 控制精度丢失。故 deadline supervision 是发现调度抖动的关键。

MC/DC 配置流程:

1. Tessy 接入:Tessy 直接从 Tasking LLVM 生成 instrumented binary(插桩编译),在 AURIX 评估板上跑。每次 test run 完成后,Tessy 导出 .trd 覆盖率报告。

2. 基准覆盖率测量:初始 MC/DC 约 65%——剩余 35% 主要集中在:

   • 死亡码路径:仅在 ASIL D 失效 corner 激活(如 DESAT interrupt)的分支,正常 HIL 测试不易触发
   • 防御性代码:double check assertion 总被 guard condition 拦截的分支
   • 通信协议错误处理:CAN bus-off recovery 逻辑

3. 缺口补全策略:

   • 故障注入测试(FI):HIL 上注入传感器失效信号,激活 ASIL D 错误路径 → MC/DC 提升至 85%
   • 静态分析确认不可达代码:Polyspace 标记 22 个 dead code branch → deviation note

4. 最终结果(示例项目数据):MC/DC = 91.3%,偏差记录 22 条(全部 Polyspace 确认为 dead code),满足 ≥ 90% 门槛。实际数字须按项目实测。

TC397 CPU0 的 MPU 配置(DPR = data protection range、CPR = code protection range,示例配置):

动态 FFI 测试:在 HIL 台架上让 CPU4(ASIL B)任务写入 CPU0 的 ASIL D DSPR 地址。CPU4 的 MPU 未授予该 DPR 写权限 → 触发 class-3 数据访问 trap。TriCore MPU trap 是同步精确 trap,在越权 load/store 指令的同一执行点产生,不存在检测延迟——随即引发 Safety Reaction。

ASIL D 项目使用的 TCL1 工具及 qualification 方法:

Qualification 使用限制:商用工具 TCL1 qualification kit 绑定具体版本——必须用 kit 指定的工具版本,版本升级需重新走 qualification verification(通常 2-4 周工作量,具体按厂商报价)。自研/开源工具自做 TCL1 qualification 估计 2-6 人月,成本极高 → 工业上几乎不走此路。

WdgM 监控的不是"task 还在跑没",而是 task 在期望时序内完成它的活:

WdgM 的 checkpoint 有 alive / deadline / logical 三种监控,组合用能盖住"task 卡死 / 提前完成 / 顺序错"。ASIL D 必须三种全配:只配 alive 等同于 §11 反模式 G1(卡死 task 仍满足 alive supervision)。

现象:转矩控制任务在某 edge case 下进入死循环(while 等待 ADC ready 超时),但中断仍在周期性执行喂 checkpoint。Alive supervision:checkCount = 10/10 ✓。WdgM 正常喂狗,SBC 不 reset。系统静默输出错误转矩,不进 safe state。

根因:Alive 只看"喂了没",不看"是否在预期时间窗口内"。Deadline supervision 检查 checkpoint A → checkpoint B 时间 [min, max]:若任务阻塞在 ADC 等待里,从 A 到 B 的时间会超出 max 阈值。

修法:WdgM 必须同时配 alive + deadline + logical supervision;deadline 窗口设为 control cycle 的 [0.5×, 1.5×]。

数字:EV 主驱 250μs 电流环,deadline window = [125μs, 375μs];超出即 WdgM 失败 → SBC 断供 → reset。

现象:ASIL D 代码为抗单粒子翻转(SEU)对安全标志做双重读检查:

uint32_t safetyFlag;                                  /* 忘了加 volatile */
if (safetyFlag != EXPECTED_VALUE) ErrorHandler();
if (safetyFlag != EXPECTED_VALUE) ErrorHandler();     /* 想做 double check */

-O2 下编译器做 common subexpression elimination(CSE):它认为两次读之间没有可观察副作用,把第二次读缓存进寄存器 / 直接删掉,双检退化成单检——若两次读之间发生 bit flip 就漏检。

根因(关键澄清):很多资料写反了——C 标准规定 volatile 访问是可观察副作用,编译器绝不能省略或合并任何一次 volatile 读(每次 volatile 读都必须真的从内存 load)。所以问题恰恰出在忘加 volatile:普通变量的重复读才会被 CSE 合并。给 safetyFlag 加 volatile 就强制两次都重新 load,双检成立。

修法:①把安全标志声明为 volatile(根治,强制两次 load);②必要时再加 __asm volatile("") 内存屏障隔开两次读,防止周边优化;③降为 -O1 并在 safety manual 中记录;④Polyspace 形式化确认两次读之间无编译器折叠。

现象:域控平台切换到 AUTOSAR Adaptive(Linux PREEMPT_RT),safety architect 认为"PREEMPT_RT 延迟已经足够低,可以跑 ASIL D 转矩控制"。

根因:POSIX Linux 内核无 ASIL D 证书。ISO 26262-6 要求软件平台本身必须 qualified 或用 SEooC 论证。Linux kernel 代码量 ~2000 万行,随机 bug 触发概率不可证明为 systematic-free。AUTOSAR Adaptive 规范(R22-11)明确"仅适用于 QM to ASIL B"。

修法:ASIL D 功能保留在 Classic(TC397 lockstep 核);Adaptive 只接 QM/ASIL B CAN 路由 / 诊断上报。用 Hypervisor(如 INTEGRITY RTOS)隔离 Classic 与 Adaptive 分区。

现象:软件团队上报 "MC/DC coverage = 95%"。Assessor 拿到 Tessy 报告一看:选择的是 "Statement Coverage Mode",不是 "MC/DC Mode"。实际 MC/DC 约 62%,未达 ASIL D 门槛。

根因:Tessy 支持多种覆盖率模式,默认不一定是 MC/DC。LDRA 同理。Statement 覆盖率天然比 MC/DC 高(同样测试用例 statement ≈ 100% 而 MC/DC 可能只有 60%)——用错模式会误报。

修法:在 Tessy 项目配置中显式选择 MC/DC Mode,并在 test report header 中打印所选覆盖类型 + 版本。Safety Officer review 时第一步核对覆盖类型字段。

现象:代码库有 34 条 MISRA C:2023 R17.7 偏差(忽略 printf 返回值——团队认为 printf 不影响安全)。Safety Case 里没有 deviation record 文档。Assessor 第一眼就发现 MISRA checker 报 34 个 warning,项目无法说明这 34 条为什么可以接受。首发 NCR(Non-Conformance Report)。

修法:每条 deviation 写 Deviation Note:①违反的 Rule 号;②偏差的代码位置;③为什么可以接受(理由 + 风险分析);④Safety Officer 签字。LDRA 可以导入 deviation justification 数据库,自动 suppress 有 note 的 warning 并在报告中链接 justification。

现象:项目购买了 Tessy v5.1 的 qualification kit,但工具升级到 Tessy v5.3。Assessor 要求"v5.3 的 qualification evidence 在哪",答不上来。Qualification kit 有版本号绑定。

根因:工具升级 = 新版本引入新 change set → 旧的 qualification evidence 不覆盖新功能/修复。ISO 26262-8 §11 的工具 qualification 是针对具体版本的。

修法:工具版本 freeze(贯穿整个项目 V 循环,不随意升级);如必须升级,向厂商申请 delta qualification kit(覆盖 v5.1→v5.3 的变更),并更新 safety plan 中的 tool list 版本字段。

现象:MPU DPR table 是 BSP 团队配置的,软件分区是应用团队设计的。两个团队各自维护文档,配置没有交叉审查。上线前发现:应用 ASIL B 任务的 BSS 段起始地址落在了 ASIL D data range(某 DPR)之内——但该 DPR 对 ASIL B 核是可写的(配置错误)。ASIL B 任务若有越界写 → 直接污染 ASIL D 数据栈。

根因:MPU 配置和 linker script 是两个独立文件,没有自动一致性校验。

修法:在 build 脚本中加 Python 脚本:读 MPU DPR/CPR table + linker symbol map → 检查每个 section 的地址是否落在正确 range 内,不一致则 build 失败。这个检查本身用于发现集成级 FFI 漏洞,不需 TCL1 qualified(属于 TCL3 开发工具)。

TC397 上电时执行 LBIST(Logic BIST),测试所有数字逻辑的 stuck-at fault。LBIST 时间随温度变化(低温下较 25°C 慢约 15-20%,实际数值查 TC3xx Safety Manual)。

若 FTTI 对"车辆上电后恢复正常驾驶"有约束(如 ASIL C SG "BEV 上电后 3s 内逆变器可用"),用示例估算量级:

结论:-40°C LBIST 扩展 ~10ms 对 3s FTTI 基本无影响(余量充足)。若项目 FTTI 压缩至 500ms(L4 场景),需在 Safety Plan 中明确 worst-case LBIST 时间为上电预算输入,并以 Safety Manual 的实测查表值替换上面的量级估算。

L4 自动驾驶时 driver 不在环:Safety Goal "禁止非预期转矩" 的 FTTI 可能从 100ms 压缩到 10ms(driver intervention 不可用)。

影响软件 SM 选型:

• 10ms FTTI → tdet + treact ≤ 10ms
• WdgM 10ms 周期任务:DTI = 10ms → 最坏情况 tdet = 10ms → treact 剩 0ms → 不够
• 必须把 DESAT 保护改为纯硬件通路(tdet ≈ 0 的连续监测):1EDI3035AS DESAT → 直接断 PWM → tdet ≈ 0 + treact ≈ 1.2μs → 总 < 10ms ✓
• SW 路径的转矩 monitor 无法满足 10ms FTTI:不能作为 SG 的主保护 → 需 architecture 变更(加硬件 STO 通路独立于 SW)

结论:FTTI 10ms 场景下,软件 SM 只能做冗余/监控层,主保护必须硬件 SM。L4 项目需重走 HARA → FSR → SM 分配全流程。

当 TC397 搭配 SEooC 芯片(TLF35584 / 1EDI3035AS)时,软件版本更新可能触发 AoU(Assumptions of Use)重验证义务:

触发场景:

1. WdgM 配置变更(窗口时间 / checkpoint 映射) → TLF35584 AoU 条款 "WD 窗口由 integrator 配置" 需重确认
2. MCU startup 流程修改(LBIST timing 变更) → TLF35584 AoU "INIT_OK 握手时序" 可能受影响
3. ISR 优先级重排 → ASIL D FFI 假设需重验证

工程纪律:变更影响分析(CIA,Change Impact Analysis)必须将"AoU 重验"列为检查项。实践上建立 AoU 矩阵(每条 AoU ↔ 受影响软件 section ↔ 触发条件),CIA 工具扫变更集自动标记需复审的 AoU。