3. ETAS RTA-CAR安全监控架构设计

在 AUTOSAR 分层架构中，安全监控并不是一个孤立模块，而是一组跨越应用层、运行时环境（RTE）和基础软件（BSW）的协同机制。ETAS RTA-CAR 作为符合 ISO 26262 与 AUTOSAR 规范的嵌入式基础软件平台，提供了从 OS 保护机制、E2E 保护、WdgM 到功能安全监控实体（SE）的完整支撑。本节围绕三个核心问题展开：RTA-CAR 的监控概念是什么、安全监控层如何嵌入 AUTOSAR 分层架构、监控实体与安全机制之间如何建立映射。

一、RTA-CAR 的监控概念

RTA-CAR 将监控能力划分为三个层次：执行监控、功能监控和外部监控。执行监控关注程序流是否按预期顺序执行、任务是否在截止期内完成，典型实现是 OS 的 Timing Protection 与 WdgM 的 Alive Supervision；功能监控关注计算结果是否合理，典型实现是 E2E Protection 与逻辑校验；外部监控则通过外部看门狗或安全控制器确认 ECU 整体是否仍处于可控状态。

这三层监控共享一个关键概念——监控实体（Supervision Entity, SE）。SE 是 WdgM 中的最小监控单元，通常对应一个被监控的软件组件或一个功能路径。每个 SE 拥有独立的 Alive、Deadline、Logical 三类监督计数器，并维护自己的本地状态机（OK、FAILED、EXPIRED、DEACTIVATED）。RTA-CAR 通过配置工具将 SE 与具体的 Runnable、Task 或 SWC 绑定，使监控逻辑与 AUTOSAR 的软件结构一一对应。

二、安全监控层与 AUTOSAR 分层架构的集成

AUTOSAR 经典分层自下而上为：微控制器抽象层（MCAL）、ECU 抽象层（ECUAL）、服务层（Services）、RTE、应用层。安全监控层并非独立于这些层之外，而是以“横切”方式嵌入其中。下图展示了 RTA-CAR 中监控机制在分层架构中的分布与数据流。

从图中可以看到，安全监控层在 RTE 中通过 E2E Profile 对信号进行端到端保护，在 BSW 中由 WdgM 管理 SE 状态机、由 OS 提供时序保护、由 Dem/FiM 记录故障并触发功能抑制。MCAL 层的 Wdg 驱动最终驱动外部看门狗。这种“横切”集成方式意味着：安全监控不是某一层的专属职责，而是贯穿整个软件栈的协同机制。

三、监控实体与安全机制的映射方法

建立 SE 与安全机制的映射，核心是回答三个问题：监控什么、用什么机制监控、失败后做什么。RTA-CAR 推荐采用“安全目标 → 安全机制 → 监控实体 → 安全反应”的四级映射链。

以电子驻车制动（EPB）为例，假设安全目标为“防止车辆在非预期情况下驻车制动失效”，对应的安全机制包括：执行器电流闭环校验、CAN 通信 E2E 保护、控制算法时序监控。映射到 SE 时，可以建立如下对应关系：

在 RTA-CAR 配置工具中，这一映射通过 WdgM 配置容器实现。每个 SE 需要配置以下关键参数：

WdgM_SupervisedEntity {
  SE_ID = SE_EPB_Current;
  SE_AliveSupervision = {
    ExpectedAliveIndications = 10;
    MaxMargin = 2;
    MinMargin = 2;
    SupervisionCycle = 10ms;
  };
  SE_DeadlineSupervision = {
    DeadlineMin = 5ms;
    DeadlineMax = 15ms;
  };
  SE_LogicalSupervision = {
    CheckpointRef = CP_CurrentCheck;
    ExpectedTransitions = 3;
  };
  SE_FailedReaction = DEM_EVENT_EPB_CURRENT_FAIL;
}

配置完成后，RTA-CAR 生成 WdgM 的 SE 状态机代码。每个 SE 在运行时会经历 OK → FAILED → EXPIRED 的状态迁移。当 Alive 计数器超出 MaxMargin 或 MinMargin 时，SE 进入 FAILED；若连续多个周期未恢复，则进入 EXPIRED，并触发 Dem 事件和 FiM 功能抑制。全局状态由所有 SE 的状态聚合而成，任一 SE 进入 EXPIRED 都会导致全局监控状态变为 EXPIRED，进而触发 ECU 级安全反应。

四、监控参数的设计与验证

监控参数的设计直接决定安全监控的有效性。以 Alive Supervision 为例，ExpectedAliveIndications 表示在一个 SupervisionCycle 内预期收到的存活指示次数。若设为 10，MaxMargin 和 MinMargin 均为 2，则实际允许范围为 8～12 次。低于 8 次说明任务执行过慢或丢失，高于 12 次说明任务可能被重复触发或时序异常。

Deadline Supervision 则关注两次存活指示之间的时间间隔。DeadlineMin 和 DeadlineMax 定义了允许的最小和最大间隔。若实际间隔小于 DeadlineMin，可能意味着任务被意外高频调用；若大于 DeadlineMax，则说明任务超时。这两个参数需要结合任务的实际调度周期和抖动范围来设定，通常建议 DeadlineMax 不超过任务周期的 1.5 倍。

Logical Supervision 用于校验程序流的正确性。它通过 Checkpoint 机制记录关键代码段的执行顺序，ExpectedTransitions 定义了预期的状态迁移次数。若实际迁移次数与预期不符，说明程序流发生了跳转或遗漏。Logical Supervision 特别适合监控安全关键的控制算法，例如“传感器读取 → 数据校验 → 控制计算 → 执行器输出”这一固定序列。

五、从监控到安全反应的闭环

安全监控的最终目的是在故障发生时将系统导向安全状态。RTA-CAR 中，SE 状态变化会通过 WdgM 的全局状态接口通知应用层或安全管理器。安全管理器根据全局状态决定反应策略：对于可恢复故障，尝试重启 SE 或切换冗余通道；对于不可恢复故障，触发降级模式或安全状态。

整个闭环可以概括为：安全目标定义 → 安全机制选择 → SE 配置与映射 → 运行时监控 → 状态聚合 → 安全反应执行 → 故障记录与诊断。这一闭环的每一环都需要在开发阶段通过故障注入测试进行验证。例如，人为延迟一个 Runnable 的执行时间，观察 SE_EPB_Timing 是否在预期周期内进入 FAILED 并触发 Dem 事件；人为篡改 CAN 报文，验证 E2E 保护是否能够检测并丢弃异常帧。

只有经过完整的映射设计、参数配置和故障注入验证，RTA-CAR 的安全监控架构才能真正满足 ISO 26262 对功能安全的要求，并在实际项目中形成可追溯、可验证、可维护的安全监控体系。