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 项目管理的翻车几乎都不在技术本身,而在流程接口——Safety Plan 承诺与实际执行之间的偏差、独立性要求被无意间打破、交付物签字链中间断。以下 7 条是 I3 评审与 TUV 实践中最高频的陷阱,共性是在项目中期才暴露、代价远高于早期预防。

G1 HARA 冻结日晚于 Safety Plan 承诺:Safety Plan 在 M0 约定 HARA 于 6 月底冻结;项目实际 HARA 到 8 月才完成。M1 评审时 I3 对比 Safety Plan 发现偏差,判 NC + 要求 Change Notice,M2/M3 排期连锁顺延约 8 周。根治:Safety Plan 写 HARA deadline 时留 4-6 周缓冲,且用跟踪工具自动对比 plan vs 实际,偏差即发 Change Notice。

G2 I3 Assessor 充当 Consulting 角色:I3 Assessor 在 M2 被邀请"帮看 FMEDA 数字怎么过线"并提了修改建议。到 M4 时该 Assessor 已对被评对象施加实质性影响,按 ISO 26262-2 §6.4 独立性要求不再具备 Assessment 资格,需换人重评,通常引发 3-6 个月延期。规避:M4 Assessor 在 M0 前确认,此后交流仅限 formal 评审,不提修改建议。

G3 HSI "冻结"但供应商未签字:系统团队宣布 HSI v1.0 冻结,但 HW vendor 与 SW team 未同步签字确认。HW vendor 按 v0.9 理解实现 ADC 采样时序,集成时发现与 SW 期望偏差 200 us,须发 HSI v1.1 变更并重确认双方实现,耗时约 6 周。根治:HSI 冻结定义为"HW/SW/System 三方签字 + 版本管控",未签字不算冻结。

G4 ASIL 分解只算 PMHF 忘了 SPFM/LFM 双指标:B(D)+B(D) 分解后团队专注证明 PMHF ≤ 10 FIT,遗漏 SPFM ≥ 99% 与 LFM ≥ 90% 的独立约束。扭矩监控子链 SPFM 仅 96.9%(单点故障诊断覆盖不足),即使 PMHF 过线仍 NC;补加系统级 SM 才能升到 99%+。ASIL D 三指标必须同时满足,FMEDA 表格要同时显示三列。

G5 B(D)+B(D) 分解双通道跑同一 MCU Lockstep 核:以为 Lockstep 两核天然独立,把 Main Channel 和 Monitor Channel 都跑在同一 TC397 的两个 Lockstep 核上。按 ISO 26262-9 Annex D CCF 评估:共享 silicon/clock/供电,β=5%;B(D)+B(D) 要求 β<2%,分解无效,ASIL D 论证断链。正确做法是两通道使用不同 MCU(如 TC397 + 独立 SBC 监控通道),将 β 压至 1-2%。

G6 Safety Plan 执行后未 Change Notice 更新:项目中途 HARA 工具从 Excel 改为 MEDINI,评审参与人也变了,但 Safety Plan 没有对应 Change Notice。M3 FS Audit 对比 Safety Plan 逐条核实际:发现"HARA 评审由三人进行"实际只有两人签字,且工具不符,判 2 条 NC。根治:Safety Plan 是活文档,每次 process 偏离即发 Change Notice,并在 M3 前经 I3 确认。

G7 FTTI 只取最紧约束,遗漏松约束场景的假阳性风险:HARA 只分析高车速 S3/E4/C3→ASIL D 最紧 FTTI = 100 ms,SM 按 100 ms 全场景触发 ASC/STO。低速停车场场景下,轻微扭矩波动也在 100 ms 内触发 SM(假安全事件),引发驾驶员投诉。根治:HARA 覆盖所有 ODD 工况,按工况分别定 FTTI;SM 加速度/场景条件门控,不能用单一最紧 FTTI 一刀切。

三个高风险边界场景会让时间线的假设失效,需要在项目初期规划缓冲或预案,否则到节点才暴露只能硬扛延期。

C1 中途 MCU/SoC 器件 EOL:项目第 16 月(开发集成阶段末),主 MCU 供应商宣布 EOL,需换型。新器件 λ 值(如 100 FIT → 85 FIT)和 DCspf 不同,需全量重做 FMEDA 并重新核验 SPFM/PMHF;若 EOL 在 M3 后发生还需走 SCR 流程并通知 I3,典型延期 2-4 个月。缓冲手段:器件选型时优先选 Long-Term Supply (LTS) 承诺的 PPAP 器件,合同锁定 EOL 预警期 ≥ 3 年。

C2 SEooC AoU 与实际集成不匹配:Tier-1 以 SEooC 方式交付电机控制器(含安全手册 + AoU,假定"栅极驱动 CMTI ≥ 50 kV/us")。实际 PCB 布局不理想,实测 CMTI 仅 45 kV/us 低于 AoU 下限;Safety Case 中出现"AoU 未满足"断链,需回 HW 改布局或换器件。教训:AoU 每一条都是 SEooC FMEDA 的假设边界,集成时必须用实测值逐条核验,不能只看器件 datasheet 额定值。

C3 OTA 软件更新触发部分重新认证:量产后 OTA 推送修改了扭矩监控阈值(±10% → ±12% 额定值),阈值宽松意味着 SG 约束放松。按 ISO 26262-2 变更管理条款(Part 2 change management clause,含 SCR 流程)须做影响分析:新阈值下 PMHF 是否仍 ≤ 10 FIT?若 FMEDA 仍过线可走"miniHARA 豁免"无需重开 M4;若不过则需重走部分 V&V 并通知 I3。常见错误:将 OTA 当普通 SW bug fix 处理而跳过 SCR,被监管机构追查后需召回和补档。

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