3. AURIX安全软件需求分析与测试需求追溯
在AURIX安全软件开发中，安全需求（Safety Requirement）与测试需求（Test Requirement）之间并不是一对一关系。一条安全目标（Safety Goal）经过功能安全概念、技术安全需求（TSR）、硬件安全需求（HSR）与软件安全需求（SSR）逐层分解后，往往对应多条软件测试需求；反过来，一条软件测试需求也可能同时验证多条安全需求。因此，需求分析与测试需求追溯的核心任务，是建立“安全需求—软件安全需求—软件测试需求—测试用例—测试结果”的可追踪链路，并保证每条安全需求都有测试覆盖，且覆盖关系可量化、可审查。
一、从安全需求到软件测试需求的分解逻辑
以AURIX TC3xx平台上一个典型安全机制为例：安全目标“避免电机控制输出非预期扭矩”可分解为技术安全需求“在检测到旋变信号失效时，应在10ms内进入安全状态（关闭PWM输出）”。该TSR进一步分解为软件安全需求：
- SSR-01：软件应周期性采集旋变解码芯片的故障状态寄存器，周期≤2ms；
- SSR-02：当连续3个周期检测到故障标志置位时，软件应在6ms内将PWM输出使能位清零；
- SSR-03：软件应记录故障发生时刻的时间戳与故障码，并写入NVM。
对应的软件测试需求则从“验证SSR是否被正确实现”出发，例如：
- TR-01：验证旋变故障状态采集周期不超过2ms；
- TR-02：验证连续3次故障标志置位后，PWM使能位在6ms内被清零；
- TR-03：验证故障时间戳与故障码被正确写入NVM，且掉电后不丢失；
- TR-04：验证在故障标志抖动（单次置位后立即恢复）时，不触发安全状态，避免误动作。
可以看到，SSR-02对应TR-02和TR-04两条测试需求，前者验证正常触发路径，后者验证抗抖动边界。这种“一条安全需求对应多条测试需求”的分解方式，正是ISO 26262对验证充分性的要求。
二、ISO 26262追溯矩阵的构建方法
ISO 26262-8第6章要求建立双向追溯（Bidirectional Traceability）。在工程实践中，追溯矩阵通常以表格形式维护，行与列分别代表不同层级的需求与验证工件。对于AURIX项目，建议至少包含以下列：安全目标ID、TSR ID、SSR ID、测试需求ID、测试用例ID、测试方法、覆盖状态、ASIL等级、备注。
构建追溯矩阵时，需要遵循三条规则：第一，每条SSR必须至少关联一条测试需求，否则视为“未验证需求”；第二，每条测试需求必须至少关联一条测试用例，否则视为“未实现测试”；第三，测试用例执行后必须回写结果状态（Pass/Fail/Blocked），并保留测试报告链接。对于ASIL D需求，还要求追溯链路上每一层都经过独立评审。
追溯矩阵示例（节选）：
| SG ID | TSR ID | SSR ID | TR ID | TC ID | 测试方法 | 状态 | ASIL |
|---|---|---|---|---|---|---|---|
| SG-01 | TSR-01 | SSR-01 | TR-01 | TC-101 | 时间戳测量 | Pass | D |
| SG-01 | TSR-01 | SSR-02 | TR-02 | TC-102 | 故障注入 | Pass | D |
| SG-01 | TSR-01 | SSR-02 | TR-04 | TC-104 | 边界抖动 | Fail | D |
| SG-01 | TSR-01 | SSR-03 | TR-03 | TC-103 | NVM读写 | Pass | D |
表中TC-104状态为Fail，说明抗抖动逻辑未满足预期，需要回溯到SSR-02的软件实现或测试用例设计。这种“失败可定位”的能力，正是追溯矩阵的工程价值。
三、需求覆盖度与测试用例映射
需求覆盖度（Requirement Coverage）通常从两个维度度量：一是需求覆盖率，即已被至少一条测试用例覆盖的安全需求数占总安全需求数的比例；二是测试用例映射率，即每条测试需求平均对应的测试用例数，用于评估验证深度。对于ASIL D项目，需求覆盖率应达到100%，且关键安全需求建议至少2条测试用例（正常路径+异常/边界路径）。
在AURIX工程中，测试用例映射通常借助需求管理工具（如DOORS、Polarion）与测试管理工具（如TestRail、ECU-TEST）的接口实现。映射时需注意：测试用例的“前置条件”必须与SSR的触发条件一致；测试用例的“预期结果”必须可量化，例如“PWM使能位在6ms内清零”而不是“系统进入安全状态”。
上图展示了从安全目标到测试用例的完整追溯链路。可以看到，SSR-02同时映射到TC-102和TC-104，其中TC-104因边界抖动场景失败，需要回溯到SSR-02的实现逻辑或测试用例的前置条件设计。这种可视化追溯关系，能帮助测试工程师快速定位“哪条安全需求未被充分验证”或“哪个测试用例失败影响哪条安全目标”。
四、工程实践中的常见问题与处理
在AURIX项目中，需求追溯最常见的三个问题是：第一，SSR描述过于抽象，导致测试需求无法量化。例如“软件应快速响应故障”无法直接映射测试用例，应改为“软件应在6ms内将PWM使能位清零”。第二，测试用例只覆盖正常路径，遗漏边界与故障注入场景。对于ASIL D需求，建议每条SSR至少设计正常、边界、故障三类用例。第三，追溯矩阵更新滞后，需求变更后未同步更新测试需求与用例。建议将追溯矩阵纳入配置管理，需求变更时自动触发影响分析。
操作建议：在AURIX TC3xx项目中，可利用AUTOSAR标准接口（如Dem、NvM）的配置参数作为SSR的量化输入。例如Dem模块的故障确认阈值（DemDebounceCounterFailedThreshold）直接对应SSR-02中的“连续3个周期”，测试用例TC-102应将该参数配置为3，并通过故障注入验证6ms内PWM使能位清零。测试结果应记录实际时间戳与预期时间戳的偏差，偏差超过1ms即判定为Fail。
需求覆盖度的计算应定期执行，建议在每个软件基线发布前完成一次全量追溯审查。审查时重点关注：是否存在无测试需求的SSR、是否存在无测试用例的测试需求、是否存在失败用例未关闭、是否存在ASIL等级降级但未记录理由的情况。只有追溯链路完整、覆盖度达标、失败项闭环，才能认为安全软件的测试需求分析达到了ISO 26262的验证充分性要求。