Safety Validation — 整车级安全确认

功能安全L3别名 Safety Validation · Sa.Val · 安全验证 · Sa.Val Plan · validation campaign · Vehicle-level Safety Validation · 更新

本质与导读

本质:Sa.Val 不是"再做一遍测试",而是 从 SG 反向倒推——在 vehicle level 验证 HARA 假设成立、FSC 真避免危害、TSC 在真工况下有效、司机能 controllability。Verification 在 V-cycle 每个阶段做(单元 / 集成 / 系统),Sa.Val 只在整车上做,只在 release 前做,且 ISO 26262 强制独立 team(I2/I3)。车规项目延期最大单一风险就是 Sa.Val 阶段才发现 SG 违反——这就是 OEM 普遍要求 mid-development Sa.Val(SiL / HiL 早期模拟)的根因。本页用 Verification ↔ Validation 对比、6 级测试环境梯、场景 × 环境覆盖矩阵、18 月时间线把 Sa.Val 落到能做项目计划的颗粒度。

主线坐标:横轨 · 功能安全(跨站) · ↑ 全景主线

1. Verification ≠ Validation

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

Verification vs Validation

维度VerificationValidation
问题每层符合 input 吗?整车 SG 满足吗?
手段Review / Inspection / 单元 + 集成测试整车测试 + FI + Drive Scenario
环境仿真 / SiL / HiL / benchVehicle level / PG / 公开路
时机V-cycle 每一阶段Release for Production 前 6-3 月
主责开发方(Tier-1)OEM(可 outsource 部分给 Tier-1)
独立性I1/I2 即可ASIL D 必 I3 / 第三方

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

2. Sa.Val 必含 4 类内容

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 在 内进入。
  • Controllability 验证——Warning + degradation 策略对司机可接受。例:降功率到 50%,仪表盘黄灯亮,司机能继续靠边停 → 用户研究 + 实车测试。

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

3. 测试环境梯 6 级

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

Sa.Val 测试环境梯

环境解决什么主要不足
Lv 1SiL(Software-in-Loop)控制算法逻辑 + 边界条件不能验真硬件
Lv 2MiL(Model-in-Loop)控制 ↔ plant 闭环plant 是模型,非真物
Lv 3HiL(Hardware-in-Loop)真 ECU + FI 自动化外设是仿真信号
Lv 4Bench(dyno 台架)真电机 + 真功率级缺整车机械 / 环境
Lv 5Proving Ground真车 + 封闭场地 + HARA 场景工况受限,司机非真用户
Lv 6公开路 fleet真驾驶人 + 真工况 + 长 mileage不可重复,FI 不能做

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

4. 场景 × 环境覆盖矩阵

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

Sa.Val 覆盖矩阵

判断规则:

  • 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——"为什么这场景不覆盖,或者为什么换到别的环境"。

5. Sa.Val Plan 关键章节

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 重审。

6. Sa.Val 时间线 18 月

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

Sa.Val 时间线

按月节奏:

月份阶段Sa.Val 活动
M3概念冻结Sa.Val Plan v0.1(目标 + 场景库初稿)
M6A 样Mid-dev Sa.Val 启动(SiL → HiL,假车试 FSC 关键场景)
M9B 样Bench dyno Sa.Val(真功率级 + FI)
M12C 样Proving Ground Sa.Val(真车,HARA 场景大批量)
M15D 样件 + PV公开路 fleet(20-50 台车,3-6 月路试)
M17RFP 准备Final Sa.Val Report + I3 review
M18SoPSa.Val 报告 = Release for Production 硬前提

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

7. OEM-Tier1 责任切分

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 页,逐场景逐环境写谁负责什么。

8. 5 类 Sa.Val 失败模式

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 用户研究阶段被打回。

9. 实战:Sa.Val 早期预警机制

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 个月调资源。

10. Worked Design — 400V/100kW ASIL D EV 主驱 Sa.Val Campaign

前 9 节讲的是 Sa.Val 的方法论骨架,这一节把它落成一份能被 Assessment 接受的实际检验清单。参考系统沿用本 wiki 主线的 TC397 + TLF35584 + 1EDI3035AS + SCT3080AL 400V/100kW EV 逆变器,把 Safety Goal 分别落到 6 级测试环境梯上,并给出 PASS 标准的具体数字——每个数字都对齐既有 SSOT 页,不另起一套。

系统背景对齐 HV 主驱逆变器 ISO 26262 概念 的 HARA 结论:SG-01(避免静止时意外加速,ASIL D,FTTI = 200 ms)/ SG-02(避免反向扭矩,ASIL D,FTTI = 200 ms)/ SG-03(避免突然失加速,ASIL B,FTTI = 500 ms)。注意 HV 触电 / 绝缘失效不是 ISO 26262 的 Safety Goal——它属电气本征安全,由 UN ECE R100 管辖,在 Sa.Val campaign 里作为一条并行的电气安全验证流单独跑(见 §10.3)。HW 检测路径 FDTI = 0.9 μs / FRTI = 0.3 μs / 总约 1.22 μs,SiC SCSOA 取 3 μs 时余量约 60%(最坏角 2 μs 时约 40%),已在 FTTI 预算分解 §3 验证。

10.1 HARA 假设验证(PG, Lv 5)

HARA 三条 Controllability 假设必须在真车上实测,SiL / HiL 无法替代。这里先厘清 controllability 的分级基准,否则 PASS 门就是拍脑袋:ISO 26262-3 把 controllability 定为 C1(Simply controllable,≥ 99% 的驾驶员能及时避免危害)/ C2(Normally controllable,90-99%)/ C3(Difficult to control or uncontrollable,< 90%)。SG-01 因意外加速属 C3(< 90% 能控)才叠到 ASIL D。

HARA 假设 H-CTRL-01:意外失速/加速场景下,原始工况被评为 C3(即无安全概念时 < 90% 驾驶员能控)——Sa.Val 要证的是上了 degradation / warning 安全概念后,残余工况变得可控

验证方案:Proving Ground 封闭场地,20 名测试司机(非工程师,混合年龄 22-65 岁 / 三段驾龄 < 3 年、3-15 年、> 15 年,含 2 名 65+ 岁老年司机),3 类 HARA 触发场景:

  • 场景 S-PG-01:100 km/h 直行 + 突然 STO(SG-01 触发)→ 成功标准:车辆偏移 ≤ 0.5 m,司机能维持车道(制动距离参照 μ = 0.8 干燥路面车辆动力学模型)
  • 场景 S-PG-02:60 km/h 转弯(R = 80 m)+ Power Degradation 50% → 成功标准:司机能保持在车道内
  • 场景 S-PG-03:城市工况 30 km/h + 三相 ASC(Active Short Circuit,SG-01 后备安全状态)→ 成功标准:扭矩塌到 ≈ 0、车辆平顺降速、司机无失控反应

PASS 门是项目自定的验证判据,不是 ISO 26262 给的数字:典型取 20 名司机中开着安全概念后全场景可控率 ≥ 某阈值(例 ≥ 80% 无危害结果)。ISO 26262-3 给的 99% / 90% 只是 controllability 的分级带(用于评 ASIL),不是 Sa.Val 的合格线——把二者混为一谈是 Assessment 常见质询点。

10.2 FSC / TSC 验证(HiL, Lv 3)

FSC / TSC 的 Fault Injection 验证是 Sa.Val campaign 工时占比最大的部分(HiL 约 60%),且必须在 HiL 自动化环境下跑,才能可重复、可回归。核心检验项如下,PASS 标准的数字均引 TSC / 既有 SSOT,不新造:

FI 编号注入手段目标PASS 标准(引 SSOT 数字)
FI-DESAT-011EDI3035AS DESAT 拉高(模拟 IGBT/SiC VCEsat 异常)SG-01HW 路径 FDTI+FRTI ≈ 1.22 μs < SCSOA 3 μs;余量 ≈ 60%(最坏角 2 μs → 40%)
FI-ECC-01TC397 CPU Core0 单 bit ECC 错误注入SG-01Lockstep 检出 → SafeState ≤ 10 μs;SPF 诊断覆盖 ≥ 99%(Infineon Safety Manual 类别典型)
FI-UVLO-01VCC2 从 15 V 降至 UVLO 阈值以下SG-01PWM 禁止 + TLF35584 FS0B 拉低 ≤ 1 ms(设计目标)
FI-SBC-WD-01TC397 safety task 卡死(TLF35584 窗口看门狗超时)SG-01TLF35584 → FS0B 拉低 ≤ WD 窗口最大值(8-10 ms 可编程)
FI-ISCL-01相电流 ADC 注入 1.2× 额定电流SG-01SW FSM 检出 → STO,SW 路径 ~11 ms ≪ 200 ms(余量约 18×)
FI-NEG-TQ-01强制生成反向扭矩指令SG-02扭矩监控检出 → ASC/STO,SW 路径 ~13 ms ≪ 200 ms
FI-TEMP-01NTC 电压拉至 Tj = 160°C 等效热保护(器件级 QM)SW 检出 + 功率降额/STO ≤ 100 ms(远早于热失控,非 FuSa SG)

FI 覆盖率是 Sa.Val Plan 交 Assessment 的完整性指标:目标覆盖 TSC 列出的每一条 SM(ISO 26262-4 Clause 8.4 要求 validation 全覆盖 SG 的 FSR / TSR)。具体 ≥ 90% 之类的门是项目内部 red-flag 阈值(见 §9),不是标准硬编码的百分比。

10.3 电气安全验证流(UN ECE R100)+ Bench 真功率级(Lv 4)

有两类验证 HiL 替代不了,必须上 Bench dyno 真功率级:真实开关瞬态下的 DESAT 响应,和真实 DC-link 电容的放电时间。

Bench FI-DESAT-02:在真实 SCT3080AL 门极电路插入外部电阻加大 RGon(延迟 VCE 下降)→ 实测 DESAT 消隐期内 VCE 是否越过 VDESAT 阈值(6 V)误触发。这是验证 tBLK ≈ 816 ns(= CDESAT × VDESAT / IDESAT = 68 pF × 6 V / 500 μA,取自 FTTI 预算页 datasheet 值)设计裕量的地面真相——HiL 用仿真电信号,无法复现真实 IGBT/SiC 开关瞬态与门极电荷非线性。PASS 标准:0 次误触发 @ 20 kHz / 400 V / 额定相电流。

电气安全放电验证(法规侧电气安全,不属 26262 SG):在台架触发 HV 断电事件 → 验证母线电压 Vlink 从 400 V 降至 ≤ 60 V DC 的时间 ≤ 5 s(碰撞后电气安全窗口 R94/R95 + ISO 6469-3 断电防护的硬要求;R100 本身无 5s 泄能条款,2026-07-10 按 EUR-Lex 原文勘正)。放电电阻按一阶 RC 放电反推:Vlink(t) = 400·exp(−t / (R·Clink)),要求 Vlink(5 s) ≤ 60 V。时间常数 R·Clink = t / ln(V0 / V) = 5 / ln(400 / 60) = 5 / 1.897 ≈ 2.64 s。取该 100 kW 逆变器代表性 DC-link 电容 Clink ≈ 1 mF,则 R ≈ 2.64 s / 1 mF ≈ 2.64 kΩ,初始放电功率 400² / 2640 ≈ 61 W——落在切换式主动放电电阻的合理区间。若实际 Clink 更大,R 需按此式等比减小以守住 5 s 窗口。绝缘监测(IMD)FI 同属这条流:软件模拟绝缘电阻降到 R100 报警阈值以下(R100 要求绝缘电阻 ≥ 100 Ω/V,400 V 母线即 ≥ 40 kΩ,IMD 报警门通常设更高)→ 验证 IMD 报警 + 启动断高压 + 放电响应。

10.4 覆盖率矩阵(本系统实例)

这个矩阵是 Sa.Val Plan 交 Assessment 的必填表,每个空格要么标环境角色,要么给不覆盖的 rationale:

场景类型SiLHiLBenchPG公开路
SW 逻辑 FI(ECC/WD/FSM)✓✓
HW DESAT / UVLO FI✓✓✓(真功率级补充)
HARA 触发场景(S-PG-01/02/03)✓(SiL 模拟)✓✓opt
Controllability 司机测试✓✓opt
耐久慢漂(10k+ km)✓(加速老化)✓✓
HV 放电验证(R100 电气安全)✓(仿真)✓✓(真 Clink)
热监控(器件级 QM)✓(NTC FI)✓✓(真热路径)opt

注:✓✓ = 主战场;✓ = 辅助/补充;opt = 可选;— = 技术上无法完成或效率极低。

10.5 Sa.Val Plan 里程碑(本系统 M0→M18)

Sa.Val Plan 贯穿全生命周期,不是 SoP 前 3 月的突击工作:

月份阶段Sa.Val 关键活动
M3HARA 冻结Sa.Val Plan v0.1:SG 清单 + 场景库初稿 + 覆盖矩阵 v0(空白)
M6A 样件Mid-dev Sa.Val:SiL FSM 逻辑验证 + HiL FI-ECC-01 / FI-DESAT-01 第一轮
M9B 样件Bench Sa.Val:真功率级 FI-DESAT-02 + HV 放电验证
M12C 样件PG Sa.Val:20 名司机 × 3 场景 controllability 测试
M15D 样件Fleet Sa.Val 启动:50 台车 × 50,000 km,全 FI 覆盖率核查
M17RFP 准备Final Sa.Val Report R1 + I3 Reviewer Confirmation
M18SoPSa.Val Report = Release for Production 硬前提

11. Gotcha Chain — Sa.Val 7 类高危陷阱

这一节把 §10 worked design 背后踩过的坑收成 checklist,每条给根因 + 修复,按危害度递减排。

G1(最高危):Mid-dev Sa.Val 缺失 → M15 才发现 SG 违反 → 推 SoP 3-6 月

Mid-dev Sa.Val(M6 SiL / HiL)是整个 campaign 的保险阀,它的价值不是"提前测一遍",而是把错误发现成本从 3-6 月工期压缩到 2-4 周 sprint。若 M6 跳过、M12 PG 阶段才发现 controllability 评错(HARA 假定残余工况可控但实测不可控),此时已有 30+ 工程师投入 9 月——改 HARA + 调 FSC + 重设计 TSC + 重 FMEDA + 重 Sa.Val PG,SoP 推 3-6 月很常见。

修复:M6 必须有 mid-dev Sa.Val 里程碑(Sa.Val Plan 硬约束,I3 Reviewer 签字);HiL FI-DESAT-01 / FI-ECC-01 + SiL 场景 S-PG-01 模拟必须在 M6 完成。

G2:Controllability 测试用工程师代替驾驶员

工程师知道实验预期动作和系统行为,反应速度和修正能力比真实用户快,导致成功率虚高 → OEM 用户研究阶段被打回 → 需重做 PG。

修复:PG 测试必须招募非工程师司机(≥ 20 人,含老年 / 新手),Sa.Val Plan 的"被试要求"章节明确"排除项目参与人员及其近亲属"。

G3:FI 仅在 HiL 做,跳过 Bench 真功率级 FI

HiL 的 DESAT 触发是仿真电信号(软件控制数字线),无法复现真实开关瞬态(VCE 下降轨迹 + 门极电荷非线性)。真实 DESAT 消隐 tBLK ≈ 816 ns 的裕量基于 SCT3080AL 输入电容 + IDESAT = 500 μA 设计(见 FTTI 预算页),任何 PCB 布线寄生电感变化都会改变 VCE 下降速度 → 改变真实 tBLK。只在 HiL 测通过的 DESAT FI,在真功率级可能因 tBLK 不足而误触发或漏触发。

修复:DESAT / Overcurrent 这两类 SM 必须在 Bench(真功率级)补做 1 次 FI(FI-DESAT-02)。

G4:Sa.Val PASS 标准混淆 FTTI / FDTI 层次

Sa.Val PASS 标准写"HW 保护在 FTTI 内响应"但引用的是 System FTTI = 200 ms(SG-01)。实际 FI-DESAT-01 验证的是 HW path FDTI+FRTI ≈ 1.22 μs——这两个数字差约 5 个数量级。若 PASS 标准写成 200 ms,则 1.22 μs 的结果虽远优于标准,但测试记录"验证 HW 保护在 FTTI (200 ms) 内响应"语义错误:真正要证的是 TSC 中规定的 FDTI / FRTI 分解(微秒级)与 System FTTI(毫秒级)的层次对应关系正确。Assessment 时会挑战这一混淆。

修复:PASS 标准按层分写——System-level FTTI 验证(车辆不发生危害)单独一条;HW-level FDTI / FRTI 验证(SM 响应时间)单独一条,数字引用 TSC 而非 HARA。

G5:Fleet Logger 容量不足,关键事件无法 Root Cause

Fleet 50 台车 50,000 km 期间某台发生 SG-01 相关事件(DESAT 误触发 + SW FSM 异常),但该时刻前 10 ms 的 CAN 帧被循环 buffer 覆盖。无原始数据 → 无法复现 → 无法定根因 → Assessment 阶段要求补测,但 fleet 试验车已归还 OEM。

修复:Sa.Val Plan "数据采集"章节明确:关键 CAN 信号(FAULT / DESAT / 相电流 / Tj / Vdc)用事件触发式存储——任何 FAULT 信号变化触发前向 500 ms + 后向 500 ms 保留,存储容量 ≥ 500 MB/台,数据加密 + OEM 与 Tier-1 双方可访问(DIA 明确 data access right)。

G6:Sa.Val Plan 未包含 OTA 变更触发的 Re-validation 决策树

SoP 后 OEM 推 OTA 更新 SW 扭矩安全参数 ±15% → 触发 Part 6 SW Verification,同时可能影响 SG-01 controllability(扭矩范围改变 HARA C 参数评估)→ ISO 26262-8 Clause 8 变更管理要求 Sa.Val 计划覆盖 change impact。若 Sa.Val Plan 无 OTA 决策树 → 量产后 Assessor 年度审计发现 Plan 不 living → Major NC。

修复:DIA 的 Sa.Val 章节增加"SW 安全参数 OTA 变更触发 Sa.Val 热更新决策树":① 参数变化 ≤ 10% 且不改 SG / HARA → Partial re-val(HiL FI 复测 + I2 Review);② 变化 > 10% 或涉及 HARA C 参数 → Full Sa.Val PG 含 controllability 测试。

G7:Final Sa.Val Report 无独立 Confirmation

ISO 26262-2 Clause 6 / Table 1 的 confirmation measures 按 ASIL 定独立性等级:ASIL D 的 confirmation review 要求最高独立性(I3,独立于开发团队)。若 Final Sa.Val Report 仅有 Tier-1 内部 Safety Mgr(I1)签字就交 Final Assessment → 直接 NC,要求补 I3 Reviewer Confirmation → 补一轮完整 I3 Review ≥ 4 周 → SoP 推延。

修复:Sa.Val Plan 的 Confirmation 章节明确"Final Sa.Val Report = I3 Reviewer Accountable + Assessor Consulted;触发 RFP 前 I3 签字必须到位"。I3 Reviewer 须来自 OEM 或第三方,非 Tier-1 内部人员。

12. Corner 分析

这一节挑三个 §10 主设计边界外、但会真实压垮 Sa.Val 计划的角落场景。

C1:−40°C 极寒冷启动 — 上电自检窗口内 SW 路径尚未 UP

TC397 上电自检(STL + March-C)+ 供电 ramp + PLL 锁定 + flash 等待周期,在 −40°C 极寒下冷启动窗口会拉长(供电 / 时钟 / flash 端主导,非 CPU 算力)。如果 SW 路径 FTTI(FSM activation)已设计在约 11 ms(见 SafeState Manager),而冷启动自检窗口更长,则在自检完成前 SW FSM 尚未激活——此时若发生故障,HW 路径仍保护(DESAT 独立于 CPU),但 SW 层(看门狗 / 相电流 SW 监控)尚未 UP,SW 路径事实上在自检窗口内不可用。

Sa.Val 应对:HiL Sa.Val 增加 −40°C 环境箱冷启动 FI 测试——在自检窗口内注入 FI-ISCL-01(SW 监控路径),实测 HW DESAT(硬件层)是否独立响应,同时测自检完成时刻(给 FSM UP 的时间预算)。若自检窗口内 HW 保护独立有效,则 FTTI 的 HW 与 SW 路径独立性成立,cold-start gap 被覆盖;否则须把 SW 自检拆成后台任务(允许 FSM 先行激活)。不在此写死具体冷启动延迟倍数——那是要靠环境箱实测拿到的数,不是纸面推的。

C2:OTA 升级触发 Sa.Val 部分重新验证

SoP + 18 月,OEM 推 OTA 升级 ADAS L3 功能,同时调整电机扭矩响应曲线(扭矩参数 ±20%)。影响评估路径:

  • HARA C 参数不变(场景未变,速度范围未变)→ Partial re-val:HiL FI 5 项 + SiL 新扭矩参数逻辑验证 + I2 Review
  • HARA C 参数升级(因 ADAS 速度范围扩展至 150 km/h → C3 边界可能更紧)→ Full re-val:PG 20 名司机复测 S-PG-01 + I3 Review

DIA 须明确:"软件安全参数 OTA 变更 → Tier-1 Safety 30 天内出具 Safety Impact Assessment → 依 Partial / Full 判据路由 Sa.Val"。否则 Field 监控期无章可循。

C3:L4 全自动驾驶 — Controllability 概念消失

若系统升级至 ADS L4(无驾驶员),HARA 的 Controllability(C)参数从"司机能否控制"转为"ADS redundancy 能否接管"。Sa.Val campaign 架构从"真人司机 PG 测试"转向"ADS backup path 功能验证"(参考 ISO 21448 SOTIF + SAE J3018 ADS 验证框架)。这对 Sa.Val Plan 是结构性变更:

  • 原有 PG S-PG-01/02/03(依赖人类驾驶员)不再适用
  • 新增场景:ADS backup path fail-over 时间验证(在 FTTI 内完成 ADS 接管)
  • 覆盖矩阵中"Controllability 主战场 PG"列需重写为"ADS redundancy 主战场 HiL + SiL"

Sa.Val Plan 必须预留 ADS 升级触发 Full Re-val 的 scope 条款;DIA 中明确 OEM ADS 域与 Tier-1 电驱域 Sa.Val 接口。

核心要点

  • Verification ≠ Validation:Verification 在每阶段做,Validation 只在 vehicle level 做,不可互替
  • Sa.Val 必含 4 类:HARA 假设 / FSC / TSC / Controllability。
  • 6 级测试环境梯:SiL → MiL → HiL → Bench → PG → 公开路;ASIL D 必至少到 Lv 5。
  • 场景 × 环境覆盖矩阵:FI 主战场 HiL,HARA 主战场 PG,耐久主战场公开路,controllability 必 PG/公开路。
  • Sa.Val 贯穿 M6-M18——不是 SoP 前最后 3 月才做。
  • Mid-dev val 缺失是延期最大单一风险——M6 必启动 SiL / HiL 试关键 SG。
  • DIA Sa.Val 章节模糊 Top 5:责任 / 场地 / 数据 access / fleet 包谁 / 报告谁签。
  • Red flag dashboard 跟踪场景覆盖 / FI 覆盖 / SG 违反次数,提前 3-6 月预警。
  • Final Sa.Val Report 是 RFP 硬前提——Safety Mgr 不签 RFP 没法量产。

Engineering Objects

引用此页的结构化 Engineeri…

引用此页的结构化 Engineering Object(v2.0 Copilot 自动生成,不要手动编辑此段)。

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

Cross-references