3. 功能安全 ECU 需求分析
功能安全需求分析的核心任务，是把整车层面的安全目标（Safety Goal）逐级分解为可分配到具体 ECU、可被硬件与软件实现、可被验证的技术安全需求（Technical Safety Requirement, TSR）。在 Stellar 这类集成多核 MCU、安全监控单元与硬件安全机制的微控制器上，需求分解不是简单的文字改写，而是一条带有明确输入、约束、分配与追溯关系的工程链路。本节以“整车安全目标 → 功能安全需求 → 技术安全需求 → ECU 软硬件安全机制”为主线，结合 Stellar 安全手册（Safety Manual）中的假设条件与安全机制，说明分解方法与需求映射的实际做法。
一、需求分解的层级与输入
按照 ISO 26262 的流程，需求分解通常经历四个层级：整车安全目标（SG）、功能安全需求（FSR）、技术安全需求（TSR），以及分配到硬件/软件的安全机制（Safety Mechanism）。每一层都有明确的输入与输出：
- SG 输入：来自危害分析与风险评估（HARA），包含 ASIL 等级、S、E、C 参数与安全状态定义。例如“防止电机在行车中非预期输出扭矩”，ASIL D。
- FSR 输出：把 SG 转化为功能层面的行为要求，如“系统应在检测到扭矩指令异常时，在 100 ms 内进入安全状态（切断扭矩输出）”。
- TSR 输出：把 FSR 分配到具体 ECU 与实现层，如“Stellar 的 eMotor 控制核应在 20 ms 内检测到 PWM 占空比越界，并通过安全输出禁用模块关断驱动”。
- 安全机制：Stellar 安全手册中列出的 SMU、ECC、Lockstep、看门狗、时钟监控等，用于实现 TSR 中的检测与响应。
分解过程中必须保持双向追溯：每个 TSR 都能追溯到上层 FSR 与 SG，每个 SG 都能被至少一个 TSR 覆盖。Stellar 安全手册提供的“Assumptions of Use（AoU）”是分解时的重要约束，例如外部电源监控、复位行为、时钟源精度等，若 AoU 不满足，则 TSR 的假设失效，需要重新分配或增加外部安全机制。
二、从 FSR 到 TSR 的分解方法
分解不是逐字翻译，而是按“检测—决策—响应”三段式把功能需求落到 ECU 资源上。以“非预期扭矩输出”为例，FSR 要求“检测到扭矩指令异常后 100 ms 内进入安全状态”。分解到 Stellar 时，需要回答三个问题：
- 检测什么、在哪里检测：扭矩指令由 CAN 或 SPI 输入，Stellar 的 CAN 控制器与 DMA 可对报文做 CRC 与超时检查；同时 eMotor 控制核可对 PWM 占空比做范围检查。
- 用什么机制检测：Stellar 安全手册中的 SMU（Safety Management Unit）可汇聚来自 ECC、Lockstep、时钟监控、ADC 自检等故障信号；CRC 单元可对关键数据流做校验。
- 如何响应、响应时间多少：通过安全输出禁用模块（如关断 PWM 输出、拉低安全引脚）在 20 ms 内进入安全状态，满足 FSR 的 100 ms 预算。
分解时还要做时间预算分配。假设 FSR 给出 100 ms 的故障处理时间（FHTI），可拆分为：检测 20 ms、SMU 汇聚与决策 10 ms、执行关断 10 ms，剩余 60 ms 作为余量。Stellar 的 SMU 报警响应时间、看门狗超时窗口、时钟监控精度都会影响这个预算，必须在 TSR 中写明具体数值与假设条件。
三、结合 Stellar 安全手册的需求映射
Stellar 安全手册为每个安全机制给出了适用场景、覆盖的故障模式、诊断覆盖率（DC）假设与使用条件。需求映射时，应把 TSR 与安全机制一一对应，并记录覆盖情况。下表给出一个示例映射（数值为教学示例，非实测值）：
| TSR 编号 | TSR 内容（示例） | Stellar 安全机制 | 覆盖故障 | 假设/约束 |
|---|---|---|---|---|
| TSR-01 | eMotor 控制核在 20 ms 内检测 PWM 占空比越界 | Lockstep + 比较逻辑 | 核内运算错误 | 需使能 Lockstep，AoU 要求时钟同源 |
| TSR-02 | 关键 SRAM 数据在 10 ms 内检测单位/双位错误 | SRAM ECC | SRAM 位翻转 | ECC 初始化需在启动自检中完成 |
| TSR-03 | SMU 汇聚故障并在 10 ms 内触发安全响应 | SMU + 报警映射 | 多源故障汇聚 | 报警优先级与滤波需按安全手册配置 |
| TSR-04 | 看门狗在 50 ms 内检测程序流异常 | 窗口看门狗 | 程序跑飞/死锁 | 喂狗窗口与任务周期匹配 |
| TSR-05 | 时钟偏差超过 ±5% 时进入安全状态 | 时钟监控单元 | 时钟漂移/失效 | 参考时钟精度需满足 AoU |
映射完成后，需要检查每个 TSR 是否被至少一个安全机制覆盖，以及安全机制的 DC 是否满足 ASIL 分解后的要求。若某 TSR 无对应机制，则需增加外部监控或调整 FSR 分配。Stellar 安全手册中的 AoU 必须逐条确认，例如“复位后 SMU 配置需在 1 ms 内完成”，否则 TSR-03 的响应时间假设不成立。
四、需求分解的检查与追溯
分解结果应形成可检查的需求清单，至少包含：TSR 编号、描述、ASIL、分配对象（核/外设/软件）、安全机制、检测时间、响应时间、假设条件、验证方法。追溯关系可用需求管理工具维护，确保 SG→FSR→TSR→安全机制→测试用例的链路完整。对于 Stellar，还需特别记录安全手册版本与 AoU 条目，因为不同版本的安全机制参数可能变化，直接影响 TSR 的可行性。
上图展示了从 SG 到 FSR、TSR 的分解路径，以及 TSR 与 Stellar 安全机制的对应关系。图中同时给出 100 ms 故障处理时间的预算分配示例，并强调 AoU 对 TSR 假设的约束作用。实际项目中，每个 TSR 都应附带验证方法，例如通过故障注入测试 SMU 报警路径、通过 ECC 错误注入验证 SRAM 检测覆盖率、通过看门狗超时测试验证程序流监控。只有需求、机制、验证三者闭环，功能安全 ECU 的需求分析才算完成。