4. 安全监控需求分析与ETAS工具支持
在完成相关项定义、HARA与安全目标制定之后，功能安全工作的重心会从“识别风险”转向“把安全目标变成可实现的工程约束”。这一阶段的核心产物是安全需求，而安全监控需求则是安全需求中专门针对“偏离预期行为”的那一部分。ETAS 的工程工具链（典型组合为 ISOLAR-AB / ISOLAR-EVE / RTA 系列 / ASCET 及需求管理接口）在这一环节的价值，不是替工程师写需求，而是把安全目标、技术安全需求、监控需求与最终实现之间的追溯关系固化下来，使需求可分解、可分配、可验证、可审计。
一、从安全目标到监控需求的三级分解
安全目标（Safety Goal）是整车层面的定性描述，例如“避免因驱动扭矩非预期增大导致车辆非预期加速”。它本身不可直接实现，必须逐级分解：
- 功能安全需求（FSR）：从安全目标导出，描述功能层面必须实现的行为，如“当检测到扭矩请求与驾驶员意图不一致时，应在 100 ms 内将扭矩限制到安全水平”。
- 技术安全需求（TSR）：把 FSR 落到具体系统/ECU 上，明确信号、阈值、时间、精度，如“电机控制器应在 20 ms 周期内比较扭矩请求与扭矩监控值，偏差超过 15% 且持续 3 个周期时触发降扭”。
- 安全监控需求（SMR）：TSR 中负责“检测—判断—反应”的那部分，直接对应监控机制，如“扭矩比较监控模块应具备自检能力，自检周期 500 ms，自检失败进入安全状态”。
分解过程中必须遵守两条原则：一是可追溯，每条 TSR 都能向上追溯到 FSR 和安全目标；二是可验证，每条 SMR 都要有明确的观测点、阈值和判定条件，否则无法设计测试用例。
二、用 ETAS 工具捕获与规范监控需求
ETAS 工具链中，需求捕获通常通过 ISOLAR-AB 的需求管理接口完成，可与 DOORS、Polarion 等需求库双向同步。实际操作中，工程师在 ISOLAR-AB 中建立需求容器，按 ASIL 等级、安全目标编号、FSR/TSR/SMR 类型打标签，并建立 satisfies、derives、verifies 三类链接。这样做的直接好处是：当某条安全目标变更时，工具能自动列出受影响的全部下游需求。
监控需求的规范化建议采用“触发条件 + 监控对象 + 判定逻辑 + 反应动作 + 时间约束”五要素结构。例如一条扭矩监控需求可写成：
SMR-TRQ-012
监控对象：实际扭矩 T_act 与请求扭矩 T_req
触发条件：使能条件 Enable == TRUE 且 |T_act - T_req| > 15% * T_req
判定逻辑：连续 3 个 20 ms 任务周期满足触发条件
反应动作：进入降扭模式，扭矩限值降至 30% 并置故障码 P0Axx
时间约束：从首次越限到进入安全状态 ≤ 100 ms
ASIL：D
追溯：satisfies TSR-TRQ-005，derives from FSR-TRQ-002这种写法把“检测什么、怎么判断、多久反应、反应成什么样”全部量化，后续无论是做模型在环测试还是硬件在环测试，都能直接映射为测试用例的输入与期望输出。
三、需求到监控实现的追溯链
追溯不是一张静态表格，而是一条贯穿工具链的链路。在 ETAS 环境中，典型路径是：需求库中的 SMR → ISOLAR-AB 中的软件组件（SWC）端口与运行实体 → RTA-OS 中的任务与调度 → RTA-BSW 中的监控模块配置 → 生成的 ARXML 与代码 → 测试用例与验证报告。下图展示了这条追溯链以及各环节的关键对象。
图中左侧是需求层，中间是 ISOLAR-AB 的映射层，右侧下方是 RTA-OS、RTA-BSW 与代码生成，最右侧是测试验证。虚线回环表示验证结果必须能反向追溯到原始 SMR，否则追溯链不完整。实际项目中，这条链的每一段都应有唯一标识符，例如 SMR-TRQ-012 对应 SWC 端口 P_TorqueMon、任务 TASK_20ms_Mon、测试用例 TC-TRQ-012-01。
四、监控需求规范中的常见问题与检查要点
需求分析阶段最容易出问题的地方，往往不是“写不出来”，而是“写得不完整”。以下检查要点可直接用于评审：
| 检查项 | 合格判据 | 常见缺陷 |
|---|---|---|
| 触发条件 | 使能条件、越限判据、去抖策略明确 | 只写“偏差过大”，无量化阈值 |
| 时间约束 | 检测时间 + 反应时间 ≤ FTTI | 只写检测周期，未核算总反应时间 |
| 安全状态 | 降扭/断使能/跛行等具体动作可执行 | 写“进入安全状态”但未定义状态内容 |
| 自检与失效 | 监控自身失效时有独立检测路径 | 监控模块失效后无任何告警 |
| 追溯完整性 | 每条 SMR 可上溯至 SG，下溯至测试用例 | 存在孤立需求或断链 |
五、从需求到实现的落地建议
在 ETAS 工具链中落地时，建议把 SMR 的标识符直接嵌入 SWC 的端口命名和任务命名中，例如 SMR_TRQ_012_Mon 作为运行实体名，Rte_Call_SMR_TRQ_012 作为接口名。这样在代码审查和 HIL 测试时，工程师无需查表就能判断某段逻辑对应哪条安全需求。同时，在 ISOLAR-AB 中为每条 SMR 维护一个“验证方法”属性，取值如 MIL、SIL、HIL、代码审查，确保每条需求都有明确的验证手段，而不是等到测试阶段才发现某条需求无法验证。
最后需要强调：安全监控需求不是一次性写完就冻结的文档。当系统架构调整、传感器精度变化或 FTTI 重新分配时，SMR 的阈值和时间约束都可能需要重新评估。ETAS 工具链的追溯能力，正是为了让这种变更影响分析变得可操作——改一条需求，工具能告诉你哪些 SWC、哪些任务、哪些测试用例需要同步更新。