EV 主驱 ASIL D 项目总线 — 18-24 个月交付物流转 + V-cycle 全站 worked 导览

单篇 deep 是"零件说明书",回答"这个零件怎么造"。但 ASIL D 项目的本质是一条 18-24 个月、跨 7-8 个 FTE、上百份交付物的装配线,它的失败模式不在零件而在装配接口。从第一性原理看,功能安全论证是一条单一逻辑链:整车 hazard 倒推到每颗器件 fault,再正向论证回 Safety Goal —— 这条链断任何一环,整个 Safety Case 就站不住,而断点几乎全发生在交付物交接处。

项目总线视角要解决三个散页解决不了的硬约束。第一是时间约束:I3 功能安全评估(Functional Safety Assessment,I3 指其要求的独立性等级)有固定 milestone,M1 要在概念阶段结束前过,这反向锁死了 HARA / FSC 必须在第几个月冻结。第二是双向可追溯(bidirectional traceability):ISO 26262 强制每条安全需求向上连到 SG、向下连到实现与验证,断链在 I3 会被直接判 NC(Non-Conformity)。第三是交付物时序耦合:HSI 文档没冻结,HW vendor 和 SW team 就不能并行开工,排错一个交付物的冻结点会让整条线停摆几周。

项目时间线的骨架是三个等长阶段,各占约 1/3,这不是巧合而是 ISO 26262 工作量的自然分布:概念阶段(HARA → FSC/TSC)定义"做什么",开发集成阶段(HW/SW 设计 → 集成)实现"怎么做",验证评审阶段(V&V → FSAR → I3)证明"做对了"。下图把 24 个月、三阶段、5 个 I3 milestone、以及主要交付物的投放点排在一条线上。

项目总线的"信号线"是交付物之间的 traceability 链。从第一性原理看,ISO 26262 要求的不是"写齐文档",而是每条安全需求都能双向走通:向上回答"我为哪条 SG 服务",向下回答"我被什么实现、被什么验证"。下图把一条 SG 如何逐级细化成器件级需求(下行)、又如何被 FMEDA 与 V&V 回证(上行)画成闭环。

把项目总线当"作战地图",每一站都对应 wiki 上一篇可直接照做的 deep —— 这是把 40+ 散页当工具书用的索引。下图按 V-cycle 顺序把 14 站与对应 deep 排在一起,星标的是本仓库已有完整工程化写作模板的站点。

V-cycle 左臂(概念 + 设计)各站与对应 deep:HARA 用 HARA Worked Example,需求细化用 FSR/TSR 写作,接口用 HSI 写作,时间预算用 FTTI 预算分解深度,安全状态用 Safe State Manager 深度。

V-cycle 右臂(集成 + 验证)各站与对应 deep:量化分析用 FMEDA / FTA 深度 / CCF 共因失效深度,故障注入用 Fault Injection Test 深度,硬件实现用 Lockstep Core 深度,软件约束用 MISRA-C 2012 深度,最终论证用 FSAR 深度。横向贯穿的 supporting 用 Tool Qualification 深度 与 Confirmation Measures 深度。

把抽象的总线落到一条具体 Safety Goal 上,最能看清流转。取 EV 主驱最经典的 hazard —— 非预期加速(Unintended Acceleration,UT = Unwanted Torque),它在高车速、不可控的工况下评为 S3/E4/C3,推出 ASIL D。下面按时间线走完这条 SG 的全程,每站只记"实际产出 + 关键数字 + 喂给下游什么"。

第一阶段冻结的是意图与时序。HARA 输出 SG:"防止驱动方向非预期扭矩 > ±10% 额定值",并定 FTTI(Fault Tolerant Time Interval,故障容错时间)= 100 ms —— 这个数字直接喂给后续所有 SM 的反应窗口预算。FSC 把 SG 拆成功能需求:独立的扭矩监控通道 + 安全状态切换。TSC 落到架构:主 MCU 算扭矩,安全 MCU(Lockstep)做独立监控,超限触发 safe state = ASC(主动短路)或 STO(安全转矩关断)。

第二阶段把时序与架构落成器件需求与实现。FTTI 100 ms 经 FTTI 预算分解 拆成 FDTI(检测)+ FRTI(反应):取检测 ≤ 40 ms、反应 ≤ 60 ms,反推扭矩监控采样率 ≥ 1 kHz。HSI 文档冻结 HW/SW 接口:扭矩信号的精度、刷新率、诊断标志位定义。HW 设计选 Lockstep 安全 MCU(器件级实现见 TI Hercules TMS570 深度),SW 按 MISRA-C 编码并做扭矩合理性检查。

第三阶段聚合证据回证 SG。FMEDA 算出扭矩监控链的 $\text{SPFM}=99.2\%$、$\text{PMHF}=8\text{FIT}$,过 ASIL D 阈;若某子链不过(如 driver 链典型 SPFM 仅 90.9%),则按 Driver IC FMEDA worked 的方法用系统级 SM 或 $B(D)+B(D)$ 分解补救。Fault Injection 实测注入扭矩传感器失效,确认 80 ms 内切入 ASC(< FTTI 100 ms)。最后 Safety Case GSN 树把 HARA 的 SG 与这些证据连成闭环,FSAR 签字闭合,M4 通过。

这一条线就是项目总线的缩影:每个数字都有上游来源、每份产出都有下游去处,中间任何一站断链(如 FTTI 没拆到采样率、FMEDA 假设的 SM 没在 SW 实现),整条 ASIL D 论证就在 I3 被打回。

总线视角下,ASIL D 项目最常见的翻车都是接口断链而非单件做不出。下面 5 个断点是 I3 评审高频 NC,且都源于交付物交接处的疏漏,在项目早期堵住的成本远低于后期返工。

第一个断点是 SG 与 FSR 的覆盖缺口:FSR 集合没完整覆盖 SG 的所有失效方向(如只防"扭矩过大"漏了"扭矩反向"),M1 直接判 NC。第二个是 TSR 没绑定 SM:TSR 写了"应监控扭矩"但没指定由哪个 SM、用什么诊断,导致 FMEDA 无法给该需求算 DC(诊断覆盖率)。第三个是 HSI 漏 timing 约束:接口只定义了信号语义没定义刷新率与时延,SW team 按自己理解实现,集成时才发现不满足 FTTI。

第四个断点是 FMEDA 假设与实现脱节:FMEDA 为达标假设了某 SM 存在并给了 DC,但该 SM 在 SW 里从未实现 —— 这个断点最危险,因为它直到 V&V 的 Fault Injection 才暴露,此时返工要回退到设计阶段。第五个是 Safety Case 证据悬空:GSN 树的某个 solution 节点引用了一份不存在或未签字的证据文档,FSAR 闭合时 I3 逐条核验会查出。5 个断点的共性是双向 traceability 工具链没强制约束,根治手段是用 Polarion 等需求管理工具做 traceability 矩阵的自动完整性检查,而非靠人工审。

ASIL D 项目不是 40 件事的清单,而是一条 18-24 个月的装配线 —— 价值在接口不在零件。 把时间线(I3 M0-M4 倒推交付物冻结日)、双向 traceability(SG ↕ 器件证据闭环)、全站 deep 导览三者合起来,就是从概念走到 FSAR 不断链的项目总线。翻车几乎全在交付物交接处,根治靠 traceability 工具强制核验。每一站要照做时,翻对应的 wiki deep 即可。