Safety Validation — 整车级安全确认

ISO 26262 严格区分这两个概念,但工程师常误用。Verification 答"做对了"(work product 符合上层 input),Validation 答"做了对的"(整车 SG 真满足)。两者都是必要,不可互替。

常见误区:把"FI 测试通过"当 validation——FI 是 verification 手段(SM 反应在 FTTI 内符合 TSC),validation 是问 "TSC 真避免了 SG 违反吗"。

ISO 26262 Part 4 Clause 8.4 列出 Sa.Val campaign 必须覆盖:

• HARA 假设验证——人 controllability + external measures 实际成立。例:HARA 假设"司机 80% 时能在 1.5 秒内反应",Sa.Val 实测平均反应时间 1.2 秒 → 假设成立。
• FSC 验证——Functional Safety Requirements 实际能避免 SG 违反。例:FSC "电机扭矩超 SG 上限 5% 必须 PWM disable",Sa.Val 注入 5.1% 过扭矩 → 验证 PWM 在 FTTI 内 disable。
• TSC 验证——Safety Mechanisms 在真实工况下有效。例:TSC "DC = 95% 通过 Lockstep + March-C",Sa.Val 注入双 bit ECC → 验证 SafeState 在 $10\mu s$ 内进入。
• Controllability 验证——Warning + degradation 策略对司机可接受。例:降功率到 50%,仪表盘黄灯亮,司机能继续靠边停 → 用户研究 + 实车测试。

关键:这 4 类不能用 verification 替代——FI 测试不能告诉你"司机看得见黄灯",Bench dyno 不能告诉你"HARA 假设对真实司机成立"。

Sa.Val 从 SiL 走到公开路,逐级逼近真实,每级解决前一级解决不了的问题。

ASIL D 项目工时典型分布:HiL ~60% / Bench ~20% / PG ~15% / 公开路 ~5%。跳级走 Lv 5 成本爆炸——所有问题积压到真车阶段,每个修复 cycle 周以上。

不同场景类型有不同的主战场环境。下面是 Sa.Val Plan 必须填的覆盖矩阵——每个空格要么 ✓ 要么 ✗ + rationale。

判断规则:

• FI(Fault Injection)主战场 HiL——✓✓:可重复 / 自动化 / 100% 受控,且不会损坏真硬件;Bench 做部分(真功率级 FI,如人为短路 IGBT);PG 极少做(只挑 1-2 条 critical FI),公开路绝不做。
• HARA 触发场景主战场 PG——✓✓:封闭场地能精确复制 HARA 场景(如 100 km/h 转弯 + 突然失效),公开路 opt(司机意外 fault 真实但不可重复)。
• 耐久(10k+ km 时漂)主战场公开路——✓✓:只有公开路 fleet 能跑足够 mileage 暴露慢漂 / 慢老化。
• 司机 controllability 主战场 PG / 公开路——必须真人在真车上,前 4 级都验不了。

未覆盖的格子必须在 Sa.Val Plan 写明 rationale——"为什么这场景不覆盖,或者为什么换到别的环境"。

Sa.Val Plan 是 Sa.Val campaign 的章程,M6-M9 完成初版,贯穿至 SoP。典型章节:

• 目标 SG/FSC/TSC 清单——每条都有 Plan 入口
• 场景库(scenario catalog)——HARA 触发场景全集 + 边界工况 + FI 列表
• 环境分配——每场景对应主战场环境 + 复用环境
• 覆盖矩阵——上节图,所有空格填明
• PASS 标准——每场景的 expected behavior(FTTI / DC / 司机响应)
• 数据采集——CAN / Flexray / 视频 / 加速度 / 司机感官
• 失败处理——发现 SG 违反 → 走 Change Request → Plan v.next
• 里程碑——Mid-dev val M6 / Bench M9 / PG M12 / 公开路 M15 / Final M17

living document——任何 work product 改动都触发 Sa.Val Plan 重审。

ASIL D 项目从 M0 启动到 M18 SoP,Sa.Val 不是 SoP 前最后 3 个月才做,而是贯穿 M6 至 M18。

按月节奏:

最贵的失误:Mid-dev val 没做,M12 PG 阶段才发现某 SG 不达——这时已经有 30+ 工程师投入 9 个月,改设计 → 重 sample → 重 verify → 重 validate,SoP 推 3-6 月很常见。

Sa.Val 的责任切分必须写进 DIA(Development Interface Agreement),最常见的模糊条款 Top 5:

• "OEM 主导,Tier-1 配合"——没切清谁出 PG 场地、谁出测试车、谁出司机、谁写报告。
• "Mid-dev val 双方共同进行"——双方都觉得对方该排期,M9 才发现一个 HiL 都没搭。
• "Controllability 由 OEM 评估"——但 Tier-1 没拿到 OEM 用户研究报告,无法在 Plan 里写 controllability 标准。
• "公开路 fleet OEM 包"——但 fleet 里没装 Tier-1 的诊断 logger,出问题数据回不来。
• "Final Sa.Val Report 由 OEM 签"——但 Tier-1 想自己看 raw data 复检,DIA 没写 access right。

实战建议:DIA Sa.Val 章节至少 5 页,逐场景逐环境写谁负责什么。

ASIL D 项目 Sa.Val 阶段最常见的失败模式:

• Mid-dev val 缺失。Plan 只在 M15 后做 → SoP 前发现 SG 违反 → 推 3-6 月。
• 场景库不全。Sa.Val Plan 漏了 HARA 某条触发场景 → PG 阶段没测 → Assessment 阶段 TÜV 挑出来 → 重补。
• PASS 标准模糊。"司机感知 OK"——但 OK 是 80% 受访者还是 95%?没量化标准 → 反复争议。
• 数据回不来。fleet 测试发现某次 SG 违反但 logger 没存关键 CAN 帧 → 无法复现 → 无法定根因。
• Controllability 用 engineer 当司机。Tier-1 拿自己工程师做 controllability test → 不代表真实用户群 → OEM 用户研究阶段被打回。

OEM / 头部 Tier-1 都会上 Sa.Val red flag dashboard——每周收集以下指标,任何超阈值触发 Plan v.next:

• 场景库覆盖率(Plan 中场景 / HARA 触发场景总数)< 95% → red
• FI 覆盖率(已注入 SM / TSC 列出 SM 数)< 90% → red
• 上周新发现的 SG 违反次数 > 0 → red(应在 Mid-dev val 阶段已暴露)
• 距 SoP 时间 / Plan 剩余场景数比值 < 2x → yellow

dashboard 是 FSM 工具,不是技术工具——目的是让 Safety Mgr 看到趋势,提前 3-6 个月调资源。

• standard · standard_iso26262_part4_validation — ISO 26262-4 (2018) 系统层 / Safety Validation