3. 安全需求分析与技术安全概念

整车安全目标（Vehicle Safety Goal）通常以“避免或减轻某类危害”的定性表述出现，例如“避免车辆在行驶中发生非预期加速”。它本身不能直接落到某一条代码或某一个寄存器上，必须经过安全需求分解，才能变成ECU可设计、可实现、可验证的技术安全需求（TSR，Technical Safety Requirement）。本节围绕这条分解链展开：整车安全目标 → 功能安全需求（FSR）→ 技术安全需求（TSR）→ 安全机制（SM）分配 → S32K硬件/软件机制映射。

一、从安全目标到功能安全需求

安全目标描述的是“要防止什么危害”，功能安全需求描述的是“系统层面要提供什么功能来达成该目标”。以“避免非预期加速”为例，可分解出两条典型FSR：其一，扭矩输出必须与驾驶员请求一致；其二，当检测到扭矩请求链路异常时，应在规定时间内将扭矩限制到安全水平。这里的关键是给每条FSR配上可度量的安全属性：ASIL等级、FTTI（故障容错时间间隔）、安全状态、响应时间。

假设某电机控制器项目定义：安全目标ASIL D，FTTI为100 ms，安全状态为“切断扭矩输出并进入降级模式”。那么FSR必须满足：从故障发生到进入安全状态的总时间不超过100 ms。这个100 ms就是后续所有TSR和机制分配的时间预算来源，也是判断机制是否“够快”的依据。

二、技术安全需求与安全机制分配

TSR是把FSR落到ECU内部的具体要求，通常包含：监测对象、判断条件、响应动作、时间约束、覆盖的故障模式。例如由FSR“扭矩请求链路异常时限制扭矩”可导出TSR：

• TSR-01：MCU应周期性校验扭矩请求报文的CRC与计数器，检测到连续3帧校验失败时，在20 ms内将扭矩请求置为安全默认值。
• TSR-02：MCU应通过独立看门狗监测主控制任务的执行，若任务超时未刷新，在50 ms内触发复位并关闭PWM输出。
• TSR-03：MCU应监测ADC采样链路的参考电压与通道范围，若采样值超出物理合理区间，在10 ms内标记该通道失效并切换到冗余通道或安全值。

每条TSR都要分配安全机制。分配时遵循两个原则：一是机制必须能覆盖目标故障模式（如报文损坏、任务卡死、采样漂移）；二是机制的时间预算必须落在FTTI之内。通常把FTTI拆成“故障检测时间 + 故障响应时间 + 安全状态达成时间”，三者之和必须小于100 ms。若某机制检测时间过长，就需要提高诊断周期或改用更快的硬件机制。

三、S32K硬件安全机制与软件安全机制的映射

S32K系列MCU提供了一组硬件安全机制，常见包括：

• 看门狗（WDOG）：独立时钟源，监测软件刷新，超时触发复位。
• CRC模块：硬件计算CRC，用于报文、存储区或代码完整性校验。
• ECC：对Flash和SRAM进行单比特纠错、双比特检错。
• MCM/ERM：监测内存访问错误和总线错误。
• 时钟监测（CMU）：监测时钟频率是否偏离预期。
• ADC自检与BIST：部分型号支持ADC自校准和内置自测试。

软件安全机制则包括：任务级看门狗刷新、报文CRC与计数器校验、ADC采样合理性检查、RAM/Flash周期性CRC巡检、程序流监控（如PC指针范围检查）、安全状态管理（降级、切断输出、复位）。

映射关系不是“一条TSR对应一个硬件模块”，而是“一条TSR由硬件机制与软件机制共同实现”。例如TSR-02“任务超时监测”由WDOG硬件提供超时复位能力，软件负责按正确节奏刷新并区分任务；TSR-01“报文校验”由CRC硬件加速计算，软件负责帧计数、连续失败判断和扭矩置安全值。下图给出从整车安全目标到S32K机制映射的完整关系。

四、映射落地时的关键检查点

完成映射后，需要逐条检查以下内容，避免“有机制但覆盖不了故障”或“机制够快但漏检”的情况：

1. 故障模式覆盖：每条TSR对应的故障模式是否被至少一个机制覆盖。例如报文损坏可由CRC覆盖，但报文丢失需要计数器或超时机制覆盖，二者不能互相替代。
2. 时间预算闭合：以TSR-01为例，若CRC校验周期为5 ms，连续3帧失败需要15 ms，加上扭矩置安全值执行时间约3 ms，总检测响应时间约18 ms，小于20 ms要求，剩余裕量2 ms。若周期改为10 ms，则30 ms超出要求，必须缩短周期或减少连续失败帧数。
3. 共因失效：若CRC硬件和软件校验共用同一时钟源，时钟失效会导致两者同时失效。此时需要CMU监测时钟，或引入独立时钟源作为补充。
4. 安全状态可达性：机制触发后，ECU是否真的能进入安全状态。例如WDOG复位后，PWM输出是否被硬件默认拉低，还是需要软件重新配置。若复位后引脚状态不确定，必须在外部增加下拉或使用安全输出模块。

五、一个可复用的映射记录示例

下表给出本节示例项目的部分映射记录，字段可直接用于安全需求追溯矩阵。表中数据为教学示例，非实测结果。

从表中可以看到，三条TSR的剩余裕量都为正，说明在当前假设下时间预算闭合。若某条裕量为负，就需要调整诊断周期、更换更快机制，或重新分配FTTI。完成这一步后，安全需求分析才算真正落到S32K的可实现层面，后续的软件架构设计、单元测试和集成测试都可以直接引用这些TSR编号和机制映射关系。