1 介绍（Introduction）
本文档的目的和目标是综述汽车行业中常用且可在 AUTOSAR 中使用的应用层错误处理机制。这包括应用层的错误处理以及应用层错误的处理。
此处的"错误处理"指完整的处理链，即检测、隔离/识别与恢复。本文档展示了一组对汽车系统有用的错误处理机制，涵盖错误处理的三个阶段。每个机制首先以高级方式进行描述，包括其在错误处理中的适用性和技术方面。然后，回顾与该机制相关的 AUTOSAR 功能，并详细说明该机制在 AUTOSAR 系统中的哪个位置实现或支持。因此，机制列表既包含 AUTOSAR 全部（或部分）提供的机制，也包含在纳入系统时应当由应用开发者在 SW-C 级别实现的机制。
注意：所涵盖的机制并不完整，仅限于可以在基于 AUTOSAR 4.0 版本构建的系统上实现的机制。可以存在替代和额外的机制，AUTOSAR 的未来版本可能支持更多错误处理功能。此外，本文档不强制使用任何机制——决策当然完全取决于应用开发者和集成商。
本文档旨在描述可能的机制，主要面向应用/SW-C 开发者。然而，对于 BSW 模块开发者也可能有用。关注点是随机故障，而非系统性设计故障（如 SW bug）。此类故障的示例包括影响应用、通信或外围设备的硬件故障。本文聚焦于最适合由 SW-C 处理的错误，不涵盖 RTE 内或 RTE 以下的错误处理，例如 COM 和 OS 的错误处理。
2 与其他文档的关系（Relation to other documents）
本文档与 AUTOSAR 发布的许多其他文档相关，尤其是由 AUTOSAR 功能安全团队处理的文档。本文档的目的不是替代这些文档中的任何一个，而是从应用开发者的视角审视其他工作包已完成的工作。
因此，本文档与其他文档之间存在相当数量的重叠，这表明 AUTOSAR 内已达到的成熟度。
针对每个机制，列出了相关的 AUTOSAR 文档清单，作为本文档与其他 AUTOSAR 文档之间的显式关系。
关于功能安全机制和措施的信息分布在整个 AUTOSAR 规范文档中。除非知道功能安全机制是如何被支持的以及必要信息的具体位置，否则难以评估如何使用 AUTOSAR 高效地实现安全相关系统。 AUTOSAR 文档《AUTOSAR 中功能安全措施概述》总结了 AUTOSAR 中功能安全相关的关键点，解释了功能安全机制和措施的使用方式，并参考了相应文档。此外，它有助于建立 ISO 26262 要求与 AUTOSAR 措施和机制之间的映射。
3 参考资料（References）
本文档引用了 AUTOSAR 4.0 规范中的多个标准文档，包括：
- 软件组件模板（Software Component Template）
- RTE 规范（Specification of RTE）
- 操作系统规范（Specification of Operating System）
- 通信规范（Specification of Communication）
- 通信管理器规范（Specification of Communication Manager）
- 诊断通信管理器规范（Specification of Diagnostic Communication Manager）
- ECU 状态管理器规范（Specification of ECU State Manager）
- 诊断事件管理器规范（Specification of Diagnostic Event Manager）
- 基础软件模式管理器规范（Specification of BSW Mode Manager）
- 以及更多
完整引用清单见原文第 9–11 页。
4 文档导读（Guide to the document）
本文档按以下方式组织：
- 第 5 章 定义关键术语，包括基本可靠性术语和 FDIR 概念。
- 第 6 章 描述本文档的范围。
- 第 7 章 介绍错误模型。
- 第 8 章 是核心内容，详细描述 13 种错误处理机制（8.1–8.13），每种机制包括：描述、适用性、应用层 vs BSW 的对比、AUTOSAR 参考。
- 第 9 章 将所有机制映射到 FDIR 过程、错误模型和实现层级。
- 第 10 章 详细描述分区终止与重启机制。
5 术语与定义（Terms and definitions）
5.1 基本可靠性术语（Basic dependability terms）
| 中文 | 英文 | 定义 |
|---|---|---|
| 故障 | Fault | 系统组件的异常状态，可能导致错误。 |
| 错误 | Error | 系统状态的不正确，可能导致失效。 |
| 失效 | Failure | 系统偏离其规定功能。 |
| 永久故障 | Permanent Fault | 持续存在的故障，直到被修复。 |
| 瞬态故障 | Transient Fault | 短暂出现的故障，随后消失。 |
| 间歇故障 | Intermittent Fault | 间歇性出现的故障。 |
| 可靠性 | Dependability | 系统可被信赖的属性，包括可用性、可靠性、安全性、机密性、完整性、可维护性等。 |
5.2 故障检测、隔离与恢复（FDIR）（Fault Detection, Isolation and Recovery）
FDIR 是错误处理的三阶段过程：
- 故障检测（Detection）：识别故障的发生；
- 故障隔离（Isolation）：定位故障源；
- 故障恢复（Recovery）：将系统恢复到正常状态。
三种恢复策略：
- 前向恢复（Forward Recovery）：在故障状态下继续运行，使用替代值或重新配置；
- 后向恢复（Backward Recovery）：回滚到之前的已知良好状态；
- 重启（Restart）：重启系统或部分系统。
6 范围（Scope）
本文档的范围：
- 包含：SW-C 级别的错误处理机制，以及部分由 AUTOSAR BSW 支持的机制。
- 不包含：RTE 之内的错误处理（如 COM、OS 错误处理）；系统性设计故障（SW bug）；硬件设计故障。
7 错误模型（Error model）
AUTOSAR 错误模型区分以下错误类别：
| 错误类型 | 英文 | 说明 | 处理位置 |
|---|---|---|---|
| 开发错误 | Development Error | 开发阶段发现的问题（如参数错误、状态错误） | Det（默认错误追踪器） |
| 运行时错误 | Runtime Error | 运行时发生的错误（如除零、溢出） | Det |
| 瞬态故障 | Transient Fault | 短暂出现的故障 | Dem（诊断事件管理器） |
| 生产错误 | Production Error | 生产环境（量产）下发生的错误 | Dem |
| 扩展生产错误 | Extended Production Error | 带有额外信息的生产错误 | Dem |
错误传播路径：
- 错误源（BSW 或 SW-C）通过 API 返回值或回调通知检测到错误；
- 调用者根据错误类型决定处理（继续、降级、复位）；
- 严重错误通过 DEM 上报，由诊断机制处理。
8 错误处理机制（Error handling mechanisms）
8.1 合理性检查（Plausibility checks）
8.1.1 描述（Description）
合理性检查通过范围检查、关系检查或逻辑检查验证输入/输出数据是否在合理范围内。
示例：
- 传感器读数是否在物理可能范围内（如温度 -40°C 至 +125°C）；
- 两个相关传感器的读数是否符合物理关系；
- 状态变量是否进入非法状态。
8.1.2 适用性（Applicability）
适用场景：
- 几乎所有安全相关系统都需要某种形式的合理性检查；
- 特别适用于检测因传感器故障、信号干扰等引起的输入异常。
8.1.3 应用层 vs. BSW（Application level vs. BSW）
BSW 层可执行基础合理性检查（如参数范围）。应用特定的合理性检查应在 SW-C 层实现，因为只有应用层知道数据的语义。
8.1.4 AUTOSAR 参考（AUTOSAR References）
主要参考 AUTOSAR_EXP_ErrorDescription.pdf。
8.2 替代值（Substitute Values）
8.2.1 描述
当检测到错误时，使用预定义的合理替代值代替错误值，继续系统运行。
示例：
- 传感器失效时，使用上一次的有效值；
- 使用默认值（如温度 25°C）。
8.2.2 适用性
适用场景：
- 需要维持基本功能的关键系统；
- 错误为瞬态时特别有用。
8.2.3 应用层 vs. BSW
应用层提供替代值；BSW 提供默认值定义机制。
8.2.4 AUTOSAR 参考
主要参考 AUTOSAR_SWS_DefaultErrorTracer.pdf。
8.3 投票（Voting）
8.3.1 描述
投票机制通过比较多个独立源（例如多个传感器）的结果来确定"正确答案"。例如：
- 2-out-of-3 投票：3 个传感器中至少 2 个一致即采用；
- 中值选择：取中值而非平均值。
8.3.2 适用性
适用于安全关键系统，特别是涉及物理量测量的场景（如制动、转向）。
8.8.3 应用层 vs. BSW
通常在 SW-C 层实现；BSW 提供冗余通信机制。
8.3.4 AUTOSAR 参考
主要参考 RTE 规范和 SW-C 模板。
8.4 一致性（Agreement）
8.4.1 描述
一致性检查用于验证分布式系统中多个节点对同一事实的认知是否一致。例如：
- 两个 ECU 对车速的估计差异应在一定范围内；
- 多源信号融合时的一致性校验。
8.4.2 适用性
适用于分布式功能（如 V2X、协同驾驶）。
8.4.3 应用层 vs. BSW
应用层使用一致的信息进行决策。
8.4.4 AUTOSAR 参考
主要参考 AUTOSAR_TPS_SoftwareComponentTemplate。
8.5 校验和/校验码（Checksums/Codes）
8.5.1 描述
校验和用于检测数据在传输或存储过程中的损坏：
- CRC（循环冗余校验）；
- 校验和（Checksum）；
- 哈希（Hash）；
- MAC（消息认证码）。
8.8.2 适用性
适用于所有关键数据的存储和传输。
8.5.3 应用层 vs. BSW
BSW 层提供 CRC 库（AUTOSAR_SWS_CRCLibrary），应用层决定何时使用。
8.5.4 AUTOSAR 参考
主要参考 CRC 库规范、E2E 库规范。
8.6 执行序列监控（Execution sequence monitoring）
8.6.1 描述
监控代码的执行顺序是否正确。例如：
- 状态机在进入某状态前是否经过合法的转换；
- 初始化序列是否按预期顺序执行。
8.6.2 适用性
适用于复杂控制逻辑和状态机实现。
8.6.3 应用层 vs. BSW
应用层在 SW-C 中实现。
8.6.4 AUTOSAR 参考
主要参考 RTE 和 SW-C 模板。
8.7 活性监控（Aliveness monitoring）
8.7.1 描述
活性监控验证监控对象（任务、SW-C、ECU）是否按预期频率报告存活。如果未在规定时间内报告，则认为该对象发生故障。
AUTOSAR 中通过 WdgM（看门狗管理器）实现。
8.7.2 适用性
几乎所有安全相关 ECU 都需要活性监控。
8.7.3 应用层 vs. BSW
WdgM 是 BSW 模块；SW-C 通过 WdgM_CheckpointReached() 报告活性。
8.7.4 AUTOSAR 参考
主要参考 AUTOSAR_SWS_WatchdogManager.pdf。
8.8 状态与模式管理（Status and Mode Management）
8.8.1 描述
通过统一的状态机管理 ECU 各子系统的运行模式：
- BswM：基础软件模式管理；
- EcuM：ECU 状态管理；
- ComM：通信模式管理；
- 应用层模式管理（用户自定义）。
8.8.2 适用性
所有 ECU 都需要状态与模式管理。
8.8.3 应用层 vs. BSW
BswM、EcuM、ComM 是 BSW；应用层模式由 SW-C 实现。
8.8.4 AUTOSAR 参考
主要参考 BswM、EcuM、ComM 规范。
8.9 重配置（Reconfiguration）
8.9.1 描述
在运行时重新配置系统参数或软件组件，以适应故障状态或工作模式变化。
示例：
- 切换到降级运行模式；
- 禁用故障模块，使用备份。
8.9.2 适用性
适用于需要在故障后调整行为的系统。
8.9.3 应用层 vs. BSW
BSW 提供配置切换机制；具体策略由应用层决定。
8.9.4 AUTOSAR 参考
主要参考 EcuM、BswM 规范。
8.10 复位（Reset）
8.10.1 描述
当其他恢复策略失败时，执行复位。复位类型包括：
- ECU 复位；
- 分区复位（OS-Application 终止并重启）；
- 部分模块重启。
8.10.2 适用性
适用于无法通过其他方式恢复的严重故障。
8.8.3 应用层 vs. BSW
EcuM 管理复位；SW-C 可请求复位。
8.10.4 AUTOSAR 参考
主要参考 AUTOSAR_SWS_ECUStateManager.pdf。
8.11 错误过滤（Error Filtering）
8.11.1 描述
通过过滤机制避免错误洪流（error storm），例如：
- 仅在规定时间间隔内上报同一错误；
- 仅在错误首次发生时上报。
8.11.2 适用性
所有使用 Dem 的系统。
8.11.3 应用层 vs. BSW
Dem 实现过滤；SW-C 可通过 API 配置。
8.11.4 AUTOSAR 参考
主要参考 AUTOSAR_SWS_DiagnosticEventManager.pdf。
8.12 内存保护（Memory Protection）
8.12.1 描述
通过内存保护机制防止分区之间相互干扰（freedom from interference）：
- OS-Application 的内存隔离；
- MPU（内存保护单元）配置；
- 栈隔离。
8.12.2 适用性
所有多分区 ECU 都应启用内存保护。
8.12.3 应用层 vs. BSW
OS 和 Memory Mapping 提供内存保护，应用层不直接涉及。
8.12.4 AUTOSAR 参考
主要参考 OS 规范和 Memory Mapping 规范。
8.13 时间保护（Timing Protection）
8.13.1 描述
通过时间保护机制检测：
- 任务执行时间超出预算；
- 中断锁定时间过长；
- 资源占用时间过长。
8.13.2 适用性
所有 ASIL 等级 ECU 都应启用时间保护。
8.13.3 应用层 vs. BSW
OS 提供时间保护，应用层无需直接涉及。
8.13.4 AUTOSAR 参考
主要参考 AUTOSAR_SWS_OS.pdf。
9 方面映射（Aspect mapping）
9.1 映射到 FDIR 过程和错误模型（Mapping to FDIR process and Error Model）
每种错误处理机制与 FDIR 阶段和错误模型的对应关系：
| 机制 | 检测 | 隔离 | 恢复 | 错误模型 |
|---|---|---|---|---|
| 合理性检查 | ✓ | 部分 | — | 开发/运行时 |
| 替代值 | — | — | ✓ | — |
| 投票 | ✓ | ✓ | ✓ | 瞬态/永久 |
| 一致性 | ✓ | ✓ | — | 永久 |
| 校验和 | ✓ | — | — | 瞬态/永久 |
| 执行序列 | ✓ | — | — | 开发 |
| 活性监控 | ✓ | 部分 | — | 永久 |
| 状态/模式管理 | — | — | ✓ | — |
| 重配置 | — | — | ✓ | — |
| 复位 | — | — | ✓ | 永久 |
| 错误过滤 | — | — | — | — |
| 内存保护 | ✓ | ✓ | ✓ | 永久 |
| 时间保护 | ✓ | — | ✓ | 永久 |
9.2 映射到实现层级（Mapping to implementation level）
每种机制在不同 AUTOSAR 层的实现位置：
| 机制 | SW-C | RTE | BSW | OS |
|---|---|---|---|---|
| 合理性检查 | ✓ | — | ✓ | — |
| 替代值 | ✓ | — | ✓ | — |
| 投票 | ✓ | 部分 | — | — |
| 校验和 | ✓ | — | ✓ | — |
| 活性监控 | — | ✓ | ✓（WdgM） | — |
| 状态/模式管理 | ✓ | — | ✓（BswM、EcuM） | — |
| 复位 | — | — | ✓（EcuM） | ✓ |
| 内存保护 | — | — | ✓ | ✓ |
| 时间保护 | — | — | — | ✓ |
10 终止与重启分区（Terminating and restarting partitions）
10.1 介绍（Introduction）
10.1.1 汽车应用（Automotive Applications）
汽车应用对可用性和安全性有严格要求。当某个软件组件发生故障时，立即复位整个 ECU 往往不可接受（驾驶体验差）。更好的方案是仅终止并重启故障分区。
10.1.2 软件分区与错误隔离区域（Software Partitioning & Error Containment Regions）
AUTOSAR 通过OS-Application（OS 应用）实现分区。每个 OS-Application 有独立的内存、时间和错误隔离。
10.2 基本原理 – 用例（Rationale – Use Cases）
10.2.1 用例 1：软件分区（Use Case 1: Software Partitioning）
用例：将不同 ASIL 等级的 SW-C 部署到不同分区。例如：
- ASIL-D 分区：制动控制；
- ASIL-B 分区：车身控制；
- QM 分区：信息娱乐。
10.2.2 用例 2：应用层错误处理（Use Case 2: Application-level Error Handling）
用例：单个 SW-C 内部检测到错误，请求重启所在分区，以保持 ECU 其他部分继续运行。
10.3 终止与重启分区的方法（Approach for Terminating and Restarting Partitions）
10.3.1 OS 特性（OS features）
AUTOSAR OS 提供以下与分区终止/重启相关的特性：
TerminateApplication()：终止 OS-Application；AllowAccess()：允许其他应用访问终止应用的资源；GetApplicationState()：查询应用状态；- 重启策略：冷启动/暖启动；
- 错误钩子（ErrorHook、StartupHook、ShutdownHook）。
10.3.2 从 OS-Application 到分区的演进（Going from OS-Applications to partitions）
AUTOSAR 4.x 将 OS-Application 概念进一步发展为分区（Partition）。每个分区可有多个 OS-Application，支持更细粒度的隔离。
10.3.3 分区终止与重启的时序图（Sequence diagram for termination and restart of a partition）
典型流程：
- SW-C 检测到不可恢复错误；
- SW-C 调用
Rte_Call_<PartitionTerminate>()； - RTE 调用 OS 的
TerminateApplication()； - OS 触发分区中其他任务的 ShutdownHook；
- OS 停止分区；
- EcuM 检测到分区停止；
- EcuM 根据重启策略重启分区（冷启动或暖启动）；
- 分区重新初始化；
- SW-C 重新开始正常运行。
10.3.4 对用例的支持（Support for Use Cases）
上述机制同时支持用例 1（分区）和用例 2（应用层错误处理）。
10.3.5 一致性考量（Consistency Aspects）
分区重启时需要考虑数据一致性：
- 非易失数据应在重启后保持；
- 运行时状态应在重启后重新初始化；
- 与其他分区的通信应在重启期间保持稳定。
10.4 集成商责任（Integrator Responsibility）
集成商负责：
- 确定每个分区的 ASIL 等级；
- 配置分区的重启策略；
- 配置错误钩子；
- 验证分区隔离的有效性；
- 确保分区重启不影响其他分区的安全目标。