4. 安全需求分析与AUTOSAR软件架构设计

在ISO 26262的功能安全开发流程中，安全需求分析是连接“危害分析”与“软件实现”的桥梁。很多工程师在拿到安全目标（Safety Goal）后，直接开始写代码或配置BSW模块，结果导致安全需求无法追溯、验证无依据。本节将沿着“安全目标 → 功能安全需求（FSR） → 技术安全需求（TSR） → 软件安全需求（SSR） → AUTOSAR SWC/BSW分配”这条主线，讲清楚每一步该产出什么、怎么推导，以及如何在AUTOSAR架构中落地。

一、安全需求的层级与推导逻辑

安全需求不是一步到位的，它需要经过多次细化。以“防止电机非预期扭矩输出”这一安全目标（ASIL D）为例：

• 安全目标（SG）：避免电机输出超过驾驶员请求的扭矩，ASIL D。
• 功能安全需求（FSR）：系统应在检测到扭矩监控偏差超过阈值时，在100ms内切断电机使能。FSR描述的是“系统级功能行为”，不涉及具体实现。
• 技术安全需求（TSR）：将FSR分配到具体技术层面，例如“由扭矩监控模块以10ms周期采集实际扭矩，与请求扭矩比较，偏差超过15%且持续3个周期时，输出切断信号”。TSR开始涉及传感器、执行器、ECU资源等。
• 软件安全需求（SSR）：进一步细化到软件层面，例如“扭矩监控SWC每10ms读取一次IoHwAb提供的实际扭矩值，计算偏差，若连续3次超过15%，调用Dem_SetEventStatus上报故障，并通过Rte向执行器SWC发送切断请求”。

这个推导过程必须保持双向追溯：每个SSR都能向上追溯到TSR，每个TSR都能追溯到FSR，最终追溯到安全目标。在AUTOSAR项目中，通常用需求管理工具（如DOORS、Polarion）维护追溯矩阵。

二、从TSR到SSR的分解要点

TSR到SSR的分解不是简单的文字改写，而是需要结合AUTOSAR软件架构做“可分配性”判断。关键考虑以下三点：

1. 时间约束的分解：TSR要求100ms内切断，SSR需要拆解为“监控周期10ms + 3次确认30ms + Rte通信延迟 + 执行器响应时间”，确保总时间预算不超过100ms。如果Rte通信延迟无法满足，就需要调整SWC到SWC的通信方式，例如从Sender-Receiver改为直接函数调用或使用IOC。
2. 安全机制的分配：TSR中的“偏差超过15%”需要明确由哪个SWC计算、哪个BSW模块提供底层数据。通常实际扭矩来自ADC采样，由IoHwAb SWC封装，监控逻辑放在应用层SWC中。
3. ASIL等级的继承与分解：如果TSR是ASIL D，SSR可以继承ASIL D，也可以按照ISO 26262-9进行ASIL分解（如D = D(D) + QM(D)），但分解需要满足独立性要求。在AUTOSAR中，独立性通常通过内存保护（MPU）、时间保护（Timing Protection）和E2E保护来实现。

三、AUTOSAR SWC与BSW的分配策略

SSR确定后，下一步是决定哪些需求由应用层SWC实现，哪些由BSW模块实现。分配策略直接影响软件的可移植性、安全性和认证工作量。

SWC侧适合实现的需求：与具体控制算法、监控逻辑、状态机相关的安全需求。例如扭矩监控算法、故障降级策略、安全状态切换逻辑。这些需求通常与车辆功能强相关，变化频繁，放在SWC中便于复用和独立测试。

BSW侧适合实现的需求：与硬件抽象、通信、诊断、内存保护相关的通用安全需求。例如：

• 看门狗管理（WdgM）：监控SWC的执行时序，属于BSW服务层。
• E2E保护（E2E Transformer）：保护安全相关信号在通信中的完整性，属于通信栈。
• 内存保护（MemMap/MPU）：由OS和Rte配合实现，属于BSW。
• 诊断事件管理（Dem）：故障上报和存储，属于BSW服务层。

分配时有一个重要原则：安全需求应尽量分配到已经过充分验证的BSW模块，减少应用层SWC的安全实现负担。例如，如果E2E保护已经由BSW的E2E Transformer提供，SWC就不需要自己实现CRC校验，只需在Rte端口上配置E2E Profile即可。

四、一个完整的分配示例

继续以扭矩监控为例，假设系统由三个SWC组成：TorqueMonitor_SWC（监控）、MotorControl_SWC（电机控制）、IoHwAb_SWC（IO抽象）。SSR分配如下：

这个表格可以直接作为需求分配矩阵的输入。注意SSR-04和SSR-06虽然由BSW实现，但它们的配置参数（E2E Profile、WdgM周期）仍然需要作为软件安全需求的一部分进行验证。

五、配置与验证要点

在AUTOSAR工具链中，SSR的落地通常体现为ARXML配置。例如，E2E保护需要在Rte端口上配置E2E-PROFILE，WdgM需要配置WdgMTrigger和WdgMCheckpoint。以下是一个简化的E2E配置片段示例：

<E2E-PROFILE>
  <SHORT-NAME>E2EProfile1_TorqueCutoff</SHORT-NAME>
  <PROFILE-NAME>PROFILE_1</PROFILE-NAME>
  <DATA-ID>0x1234</DATA-ID>
  <MAX-DELTA-COUNTER>3</MAX-DELTA-COUNTER>
</E2E-PROFILE>

验证时，需要确认：E2E保护是否覆盖了所有安全相关信号；WdgM的监控周期是否小于故障容忍时间；Dem事件是否与SSR-05一致。这些验证活动应记录在安全验证计划中。

总结来说，从安全目标到AUTOSAR软件架构的落地，核心是“逐级细化、明确分配、保持追溯”。安全目标回答“避免什么”，FSR回答“系统做什么”，TSR回答“技术怎么做”，SSR回答“软件怎么实现”，而SWC/BSW分配则回答“由谁实现”。只有每一步都清晰可查，后续的软件单元测试、集成测试和功能安全评估才有坚实的基础。