4. 功能安全需求分析与DRIVE平台映射

功能安全开发的核心不是“把 ISO 26262 的条款走一遍”，而是把整车层面的安全意图，逐级翻译成可验证、可实现、可追溯的技术约束。对 NVIDIA DRIVE 这类高算力自动驾驶计算平台而言，这条翻译链尤其关键：整车安全目标（Vehicle Safety Goal）经过 HARA 导出功能安全需求（FSR），再分配到 DRIVE 平台的硬件安全机制与软件安全机制，最终形成可测试的安全需求条目。本节围绕这条链路展开，重点讲清“怎么从整车目标推导到平台机制”。

一、从整车安全目标出发：HARA 的三个关键输出

HARA（危害分析与风险评估）的输入是整车层面的功能定义与运行场景，输出是三个直接决定后续设计的东西：危害事件（Hazardous Event）、ASIL 等级、安全目标（Safety Goal）。以“高速公路自动巡航（ACC+LKA）”为例，典型危害事件可描述为“车辆在无驾驶员接管的情况下偏离车道并与其他车辆发生碰撞”。评估时按 ISO 26262 的三要素打分：

• S（严重度）：S3，可能造成人员重伤或死亡；
• E（暴露度）：E4，高速巡航场景几乎每次行程都会出现；
• C（可控性）：C3，驾驶员在系统误转向时难以在短时间内可靠纠正。

S3+E4+C3 对应 ASIL D，这是最高完整性等级。由此导出的安全目标可写为：“应避免系统在无有效驾驶员接管请求的情况下输出导致车辆非预期横向运动的转向指令。”注意，安全目标描述的是“避免什么”，而不是“怎么实现”，这是后续需求分解的起点。

二、从安全目标到功能安全需求（FSR）

安全目标需要被分解为功能安全需求。仍以上述目标为例，可导出若干条 FSR，例如：

• FSR-01：系统应能检测自身横向控制输出的异常，并在检测到异常后的一个控制周期内进入安全状态；
• FSR-02：系统应保证横向控制指令在传输过程中不被静默篡改；
• FSR-03：当驾驶员接管请求有效时，系统应在规定时间内退出横向控制。

每条 FSR 都要带 ASIL 等级、FTTI（故障容错时间间隔）和验证准则。FTTI 是这里最容易被忽略却最关键的参数：它决定了后续安全机制必须在多长时间内完成“检测—反应”。例如横向控制回路的 FTTI 若为 100 ms，则检测加反应的总延迟必须小于 100 ms，否则安全目标无法达成。

三、映射到 DRIVE 平台：硬件与软件安全机制

FSR 落到 DRIVE 平台时，需要区分“硬件机制”和“软件机制”，并明确它们各自覆盖哪类故障。下图给出了一条从整车安全目标到平台机制的映射关系，重点展示 FSR 如何被分配到 DRIVE 的 SoC 内部安全机制与软件监控层。

图中左侧是整车层，中间是需求分配层，右侧是 DRIVE 平台机制层，底部是验证闭环。需要强调的是：FSR 到机制的映射不是“一对一”，而是一对多、多对一。例如 FSR-01（异常检测）既依赖硬件 Lockstep 核检测 CPU 故障，也依赖软件运行时自检检测算法输出异常；FSR-02（传输完整性）则主要落在软件 E2E 保护和硬件总线 ECC 上。

四、ASIL 分解与 FTTI 预算：映射时的两个硬约束

把 ASIL D 的需求直接压到单个机制上往往不现实，因此需要做 ASIL 分解。例如 FSR-01 可分解为：

• ASIL D 的“检测 CPU 计算错误”，由 Lockstep 核承担；
• ASIL B 的“检测算法输出越界”，由软件监控承担；
• ASIL A 的“记录故障日志”，由非安全核承担。

分解后必须验证：各子需求的 ASIL 组合是否仍能覆盖原始 ASIL D 目标。同时，FTTI 预算要逐级分配。假设 FTTI = 100 ms，可做如下预算示例：

这张预算表是示例，实际项目中每个数字都要由具体机制的最坏执行时间（WCET）和调度分析支撑，不能凭经验拍定。

五、验证闭环：怎么判断映射是否成立

映射完成后，必须通过故障注入验证机制是否真的能在 FTTI 内生效。以 FSR-01 为例，可在 DRIVE 平台上注入两类故障：一是 CPU 寄存器位翻转，观察 Lockstep 是否在 10 ms 内报错；二是算法输出注入一个超出转向角限值的数值，观察软件监控是否在 20 ms 内拦截。若任一环节超时，则说明 FTTI 预算不成立，需要回到需求分配阶段重新分解，或更换更快的机制。

总结来看，从整车安全目标到 DRIVE 平台机制的映射，本质上是三次翻译：第一次把危害事件翻译成安全目标，第二次把安全目标翻译成 FSR，第三次把 FSR 翻译成硬件与软件机制。每一次翻译都要保留 ASIL 等级和 FTTI 约束，并通过故障注入验证闭环。只有这条链路完整且可追溯，功能安全需求分析才真正落地。