# AUTOSAR 中功能安全措施概述（Overview of Functional Safety Measures in AUTOSAR） | 字段 | 内容 | |---|---| | **文档标题** | AUTOSAR 中功能安全措施概述（Overview of Functional Safety Measures in AUTOSAR） | | **文档所有者** | AUTOSAR | | **文档责任方** | AUTOSAR | | **文档标识号** | 664 | | **文档状态** | Final（正式发布） | | **所属 AUTOSAR 标准** | Classic Platform（经典平台） | | **所属标准版本** | 4.4.0 | --- ## 文档变更历史（Document Change History） | 日期 | 版本 | 变更人 | 变更描述 | |---|---|---|---| | 2018-10-31 | 4.4.0 | AUTOSAR Release Management | 编辑性变更 | | 2016-11-30 | 4.3.0 | AUTOSAR Release Management | 新增章节："Use of AUTOSAR features for functional safety"，基于文档 TR_SafetyConceptStatusReport_233 的第 4.2 和 4.3 章；细微修正/澄清/编辑性变更 | | 2015-07-31 | 4.2.2 | AUTOSAR Release Management | 新增章节："Hardware Diagnostics"，涵盖 Core Test 和 RAM Test；细微修正 | | 2014-10-31 | 4.2.1 | AUTOSAR Release Management | 初始发布 | --- ## 目录（Table of Contents） 1. [引言](#1-引言) 2. [功能安全机制](#2-功能安全机制) 3. [功能安全措施](#3-功能安全措施) 4. [硬件诊断](#4-硬件诊断) 5. [附录](#5-附录) --- ## 1 引言 功能安全是系统的一个特征，需要从一开始就加以考虑，因为它可能影响系统设计决策。因此，AUTOSAR 规范包含与功能安全相关的要求。 系统设计的复杂性等因素可能与汽车领域实现功能安全相关。软件是影响系统级复杂性的参数之一。可以使用新的软件开发和概念技术来最小化复杂性，从而更容易实现功能安全。 AUTOSAR 通过提供安全措施和机制来支持安全相关系统的开发。然而，**AUTOSAR 本身并不是一个完整的安全解决方案**。 > ⚠️ **重要提示**：使用 AUTOSAR 并不隐含 ISO 26262 合规性。即使使用 AUTOSAR 的安全措施和机制，仍可能构建出不安全的系统。 ### 1.1 免责声明 本说明性文档代表了 AUTOSAR 最新版本中的功能安全措施和机制。一些所述的机制和措施在以前的版本中可能以不同的方式实现或可能不可用。本文档的用户应始终参考适用的引用文档。 ### 1.2 范围 本文档的内容按章节结构组织如下： **功能安全机制**：本章包含与 AUTOSAR SW-C 之间无干扰（freedom from interference）相关的 AUTOSAR 功能安全机制。 - **内存（Memory）**：AUTOSAR 的分区机制，涵盖应用软件的开发与部署 - **时序（Timing）**：使用看门狗管理器的程序流时序监控机制，以及使用操作系统的时序保护机制 - **执行（Execution）**：使用看门狗管理器的逻辑监督机制 - **信息交换（Exchange of Information）**：使用端到端（End-2-End）库和扩展的通信故障检测机制 **功能安全措施**：本章包含与安全相关系统开发相关的主题。涵盖以下内容： - AUTOSAR 的功能安全措施，例如可追溯性、开发措施和标准的演进 - AUTOSAR 未交付的功能安全措施 - **安全用例（Safety Use Case）**：基于引导示例 Front Light Management 的使用 AUTOSAR 的安全相关系统示例 - **安全扩展（Safety Extensions）**：如何通过 AUTOSAR 元模型在 AUTOSAR 模型和文档中表达安全要求 **硬件诊断（Hardware Diagnostics）**：本章包含与微控制器提供功能可被信任的前提相关的主题。涵盖： - Core Test（核心测试） - RAM Test（RAM 测试） ### 1.3 目的 当前，AUTOSAR 功能安全机制和措施的相关信息分散在引用的文档中。除非了解功能安全机制是如何得到支持的，以及必要信息具体位于何处，否则难以评估如何使用 AUTOSAR 高效地实现安全相关系统。 本说明性文档总结了与 AUTOSAR 中功能安全相关的关键点，并解释了如何使用功能安全机制和措施。 > **注意**：本文档取代了 AUTOSAR 文档 "Technical Safety Concept Status Report"（ID: 233）。 ### 1.4 目标读者 本文档为参与安全相关（ECU）系统开发的人员提供 AUTOSAR 功能安全措施和机制及其实现的概述。因此，本文档面向 AUTOSAR 的用户，包括参与安全分析的人员。 --- ## 2 功能安全机制 现代 ECU 包含高度模块化的嵌入式软件，可由非安全相关和安全相关软件组件组成，这些组件执行具有**不同 ASIL 等级**的功能。 根据 **ISO 26262**，如果嵌入式软件由具有不同 ASIL 等级的软件组件组成，则： - 要么必须按照**最高 ASIL** 等级开发整个软件 - 要么必须确保**具有较高 ASIL 等级**的软件组件**不受具有较低 ASIL 等级**的元素的干扰 此外，ISO 26262 标准提供了导致软件组件之间干扰的故障示例。这些故障按以下方式分组： - **内存（Memory）** - **时序（Timing）** - **执行（Execution）** - **信息交换（Exchange of Information）** 在接下来的章节中，将给出 AUTOSAR 功能安全机制的概述。这些机制有助于防止、检测和缓解硬件和软件故障，以确保软件组件之间的**无干扰**。 > **注意**：AUTOSAR 功能安全机制用于支持安全相关系统的开发。因此，功能安全机制（软件和硬件）是安全相关的，必须相应地开发和集成。 ### 2.1 内存分区（Memory Partitioning） #### 2.1.1 故障模型 内存分区的故障模型涉及以下故障类型： - **内存内容损坏**：一个软件组件意外修改另一个软件组件的内存内容 - **读取非预期内存**：一个软件组件读取本应保密的另一个软件组件的内存内容 - **代码执行越界**：一个软件组件的执行流意外跳转到另一个软件组件的代码区域 - **栈溢出**：一个软件组件的栈增长影响另一个软件组件的栈 #### 2.1.2 描述 AUTOSAR 通过多种机制支持内存分区。 ##### 2.1.2.1 应用软件 应用软件分区（Application Software Partitioning）允许将不同的应用软件组件（SW-C）放置在不同的内存区域中。这通过以下方式实现： - **链接时配置**：将每个 SW-C 的代码和数据放置在预定义的内存段中 - **编译时保护**：使用编译器属性（如 `__attribute__((section))`）确保数据不会被意外放置在错误的内存区域 ##### 2.1.2.2 OS-Applications OS-Application 是 AUTOSAR 操作系统中的一个概念，它将 OS 对象（如任务、中断、计数器）分组到一个逻辑单元中。每个 OS-Application 都有自己的： - 任务优先级范围 - 内存访问权限 - 错误处理程序 OS-Application 之间的隔离通过 **Memory Protection Unit (MPU)** 实现。 ##### 2.1.2.3 通信与代码共享 不同分区之间的通信通过 **RTE（Runtime Environment）** 标准化。RTE 提供了： - **显式接口**：所有跨分区通信必须通过 RTE 接口 - **内存隔离**：RTE 内部使用专用缓冲区进行跨分区数据传输 - **类型检查**：编译时验证接口签名 > **[FSM_001]** ⌈AUTOSAR RTE 应确保跨分区的通信通过标准化的 RTE 接口进行。⌋ ##### 2.1.2.4 应用软件内的内存分区 应用软件内部的内存分区通过以下方式实现： - **独立的内存段**：每个 SW-C 的全局数据放置在独立的内存段中 - **内存映射文件（MemMap.h）**：通过预编译宏（如 `ECU_VAR`、`ECU_CODE`）控制内存段分配 - **链接器配置**：链接器脚本定义每个段的物理位置 ##### 2.1.2.5 软件组件内的内存分区 软件组件内部也可以进行更细粒度的分区： - **Runnable 之间的隔离**：每个 Runnable 拥有独立的栈空间 - **数据隔离**：Runnable 的局部数据通过栈分配，与全局数据隔离 - **代码隔离**：Runnable 的代码段在链接时确定，不可在运行时修改 ##### 2.1.2.6 内存分区的实现 内存分区的实现依赖于底层硬件支持： | 硬件特性 | 提供的隔离 | |---|---| | MPU（Memory Protection Unit） | 内存区域读写权限控制 | | MMU（Memory Management Unit） | 虚拟地址到物理地址的映射 | | 硬件栈保护 | 栈溢出检测 | | 双核锁步（Dual-core Lockstep） | 计算故障检测 | #### 2.1.3 检测与反应 内存分区的故障检测和反应机制： - **MPU 违例（Memory Protection Violation）**：当 SW-C 访问未授权的内存区域时，MPU 触发异常 - **OS 错误处理**：OS 捕获 MPU 违例并执行以下动作： 1. 终止违规的 OS-Application 2. 记录错误到 DEM 3. 通知 EcuM - **看门狗复位**：如果错误处理失败，硬件看门狗将复位 ECU > **[FSM_002]** ⌈当发生 MPU 违例时，AUTOSAR OS 应终止违规的 OS-Application 并报告错误。⌋ #### 2.1.4 限制 内存分区的限制： - **运行时开销**：MPU 配置和上下文切换增加运行时开销 - **代码大小**：分区代码通常比单块代码略大 - **硬件依赖**：MPU 的数量和粒度取决于具体 MCU - **粒度限制**：MPU 区域数量有限，复杂的分区可能受限 #### 2.1.5 引用 AUTOSAR 文档 - AUTOSAR_SWS_OS（操作系统规范） - AUTOSAR_SWS_RTE（运行时环境规范） - AUTOSAR_TPS_SafetyExtensions（安全扩展） #### 2.1.6 引用 ISO 26262 - ISO 26262-5:2018 第 7.4.4 节（软件架构中的无干扰） - ISO 26262-6:2018 第 7.4.7 节（内存分区） ### 2.2 时序监控（Timing Monitoring） #### 2.2.1 故障模型 时序监控的故障模型： - **任务执行超时**：任务未在规定的时间内完成 - **死循环**：任务进入无限循环 - **死锁**：任务因资源争用而永久阻塞 - **过早执行**：任务在不应执行的时候执行 - **任务到达率过低**：周期性任务的到达频率低于预期 #### 2.2.2 描述 AUTOSAR 通过两个主要机制支持时序监控：**看门狗管理器** 和 **操作系统的时序保护**。 ##### 2.2.2.1 监督实体 监督实体（Supervised Entity, SE）是看门狗管理器监督的逻辑软件单元。每个 SE 可以是： - SW-C 中的一个 Runnable - 一个完整的 SW-C - 一个 BSW 模块 - 一个 CDD ##### 2.2.2.2 看门狗管理器 看门狗管理器提供三种时序监督机制： 1. **Alive 监督**：监督周期性软件 - 检查 SE 在每个监督周期内是否被调用了预期次数 - 配置参数：`ExpectedAliveIndications`、`MinMargin`、`MaxMargin` 2. **Deadline 监督**：监督非周期性软件 - 检查两个检查点之间经过的时间是否在最小和最大限制内 - 配置参数：`DeadlineMin`、`DeadlineMax` 3. **Logical 监督**：监督执行顺序 - 检查检查点之间的转换是否合法 - 配置：内部图、外部图 > **看门狗管理器与监督实体的关系**： > > 一个 ECU 可包含多个 SE；一个 SE 关联一个或多个检查点；WdgM 通过监督所有 SE 来决定是否触发硬件看门狗。 ##### 2.2.2.3 操作系统的时序保护 AUTOSAR OS 提供时序保护机制，独立于看门狗管理器： - **任务执行预算（Task Execution Budget）**：每个任务的最大执行时间 - **任务到达时间间隔（Task Inter-arrival Time）**：任务两次激活之间的最小时间 - **资源锁时间（Resource Lock Time）**：任务持有资源锁的最大时间 - **中断执行时间（Interrupt Execution Time）**：ISR 的最大执行时间 当违反时序约束时，OS 触发保护错误，可配置为： - 调用用户定义的错误处理程序 - 终止违规任务 - 调用 `ShutdownOS()` #### 2.2.3 检测与反应 时序监控的检测和反应： - **Alive 监督失败**：本地状态变为 `EXPIRED` - **Deadline 监督失败**：本地状态变为 `EXPIRED` - **OS 时序保护违例**：OS 触发保护钩子（Protection Hook） - **最终反应**：停止触发硬件看门狗，导致硬件看门狗复位 ECU > **[FSM_003]** ⌈当看门狗管理器检测到监督失败时，应停止触发看门狗以允许硬件看门狗执行 ECU 复位。⌋ #### 2.2.4 限制 时序监控的限制： - **检测延迟**：监督是周期性的，故障检测存在延迟 - **粒度限制**：监督周期决定了最小可检测的故障间隔 - **配置复杂性**：复杂的时序需求需要详细的配置 - **与 OS 时序保护的重叠**：可能存在重复监督 #### 2.2.5 引用 AUTOSAR 文档 - AUTOSAR_SWS_WatchdogManager（看门狗管理器规范） - AUTOSAR_SWS_OS（操作系统规范） #### 2.2.6 引用 ISO 26262 - ISO 26262-5:2018 第 7.4.5 节（时序行为） - ISO 26262-6:2018 第 7.4.8 节（时序保护） ### 2.3 逻辑监督（Logical Supervision） #### 2.3.1 故障模型 逻辑监督的故障模型： - **控制流错误**：程序执行序列与预期不符 - **跳转错误**：条件分支错误 - **跳过代码**：重要的安全检查被绕过 - **重复执行**：循环退出条件错误导致重复执行 #### 2.3.2 描述 逻辑监督由看门狗管理器提供，通过检查点（Checkpoints）和转换（Transitions）实现： - **检查点**：监督实体中的关键位置 - **内部转换**：同一 SE 内两个检查点之间的合法转换 - **外部转换**：不同 SE 的检查点之间的合法转换 - **内部图**：内部转换的集合 - **外部图**：外部转换的集合 **图示例**： ``` SE_A: CP0 ──→ CP1 ──→ CP2 │ ↓ (外部转换) SE_B: CP3 ──→ CP4 ──→ CP5 ``` #### 2.3.3 检测与反应 逻辑监督的检测和反应： 1. WdgM 维护当前已到达的检查点 2. 当新的检查点被报告时，WdgM 验证从前一检查点到新检查点的转换是否合法 3. 如果转换不合法，本地状态变为 `EXPIRED` 4. 错误处理动作与 Alive/Deadline 监督相同 > **[FSM_004]** ⌈逻辑监督应验证检查点之间的转换是否在配置的图中被允许。⌋ #### 2.3.4 限制 逻辑监督的限制： - **配置复杂性**：复杂的控制流需要详细的图配置 - **检查点开销**：每次 `WdgM_CheckpointReached()` 调用都有运行时开销 - **静态配置**：图必须在编译时已知，不支持动态修改 #### 2.3.5 引用 AUTOSAR 文档 - AUTOSAR_SWS_WatchdogManager #### 2.3.6 引用 ISO 26262 - ISO 26262-5:2018 第 7.4.6 节（软件架构设计中的错误检测） ### 2.4 端到端保护（End-2-End Protection） #### 2.4.1 故障模型 端到端保护针对的是**通信链路**上的故障： - **重复（Repetition）**：同一条消息被重复接收 - **丢失（Loss）**：消息在传输过程中丢失 - **插入（Insertion）**：伪消息被插入到通信流中 - **乱序（Incorrect Sequence）**：消息到达顺序与发送顺序不一致 - **损坏（Corruption）**：消息内容在传输过程中被修改 - **延迟（Delay）**：消息延迟到达 - **伪装（Masquerading）**：非法的发送方伪装成合法发送方 - **寻址错误（Incorrect Addressing）**：消息被错误的接收方接收 #### 2.4.2 描述 AUTOSAR 端到端（E2E）保护库通过在通信数据上添加**校验信息**来实现通信故障检测。 ##### 2.4.2.1 端到端配置文件 E2E 库提供多个保护配置文件（Profiles），每个文件提供不同等级的保护： | 配置文件 | CRC 长度 | 计数器 | 适用场景 | |---|---|---|---| | Profile 1 | 8 位 | 4 位 | 简短控制消息 | | Profile 2 | 16 位 | 16 位 | 中等安全相关消息 | | Profile 4 | 32 位 | 16 位 | 高度安全相关消息 | | Profile 5 | 16 位 | 无 | 简单状态消息 | | Profile 6 | 32 位 | 32 位 | 高度安全相关长消息 | | Profile 7 | 64 位 | 32 位 | 最高安全等级消息 | | Profile 11 | 8 位 | 16 位 | 类似 Profile 1 但有更长计数器 | > **配置文件选择**：配置文件的选择取决于目标 ASIL 等级。Profile 4 和 Profile 7 通常用于 ASIL D 系统。 ##### 2.4.2.2 端到端状态机 E2E 接收方维护一个状态机来处理接收的消息： | 状态 | 描述 | 转换条件 | |---|---|---| | `E2E_P02STATUS_OK` | 消息正确 | 下一条消息正确接收 | | `E2E_P02STATUS_NONEW` | 无新消息 | 接收超时 | | `E2E_P02STATUS_WRONGCRC` | CRC 校验失败 | 检测到 CRC 错误 | | `E2E_P02STATUS_SYNC` | 同步丢失 | 计数器不连续 | | `E2E_P02STATUS_INITIAL` | 初始状态 | 首次接收 | | `E2E_P02STATUS_REPEATED` | 消息重复 | 计数器未变 | ##### 2.4.2.3 端到端保护库的集成 E2E 库通过多种方式集成到 AUTOSAR 通信栈中： 1. **RTE 层**：在 SW-C 之间通信时自动应用 E2E 2. **COM 层**：在 PDU（Protocol Data Unit）级别应用 E2E 3. **PduR 层**：在路由过程中应用 E2E 4. **CAN/LIN/FlexRay 驱动层**：在传输层应用 E2E ##### 2.4.2.4 端到端保护包装器 E2E 包装器（E2E Wrapper）是一个额外的抽象层，它： - 在 COM 层之上实现 E2E 保护 - 不需要修改 COM 层 - 提供更灵活的 E2E 配置 ##### 2.4.2.5 传输管理器 传输管理器（Transport Manager, Tm）管理 E2E 保护与底层通信的交互： - 选择合适的 E2E 配置文件 - 维护连接状态 - 处理错误恢复 ##### 2.4.2.6 COM 端到端回调 COM 模块提供 E2E 回调函数： - 当接收到 E2E 保护的 PDU 时，COM 调用 E2E 验证函数 - 验证结果通过回调函数传递给应用层 ##### 2.4.2.7 RTE 数据转换器 RTE 数据转换器（Data Transformer）将 E2E 保护集成到 RTE 通信中： - 自动在 RTE 通信中插入 E2E 保护 - 透明于 SW-C - 编译时配置 #### 2.4.3 检测与反应 E2E 保护检测到的故障反应： - **重复消息**：丢弃 - **丢失消息**：等待下一条或报告错误 - **乱序消息**：标记为乱序状态 - **损坏消息**：丢弃并报告 DEM 错误 - **同步丢失**：等待重新同步或报告错误 #### 2.4.4 限制 E2E 保护的限制： - **带宽开销**：CRC 和计数器占用额外的通信带宽 - **处理开销**：CRC 计算增加 CPU 负载 - **延迟**：E2E 处理增加通信延迟 - **有限的配置文件**：可用配置文件数量有限，可能不完全匹配所有应用场景 #### 2.4.5 引用 AUTOSAR 文档 - AUTOSAR_SWS_E2ELibrary（端到端库规范） - AUTOSAR_SWS_COM（通信规范） - AUTOSAR_SWS_RTE（运行时环境规范） #### 2.4.6 引用 ISO 26262 - ISO 26262-5:2018 第 7.4.9 节（通信安全） - ISO 26262-6:2018 第 7.4.10 节（数据通信） --- ## 3 功能安全措施 ### 3.1 AUTOSAR 的功能安全措施 AUTOSAR 的功能安全措施包括： - **可追溯性（Traceability）**：AUTOSAR 提供了从需求到实现的可追溯性机制 - **开发措施（Development Measures）**：AUTOSAR 标准要求符合 ISO 26262 的开发措施 - **标准的演进（Evolution of the Standard）**：AUTOSAR 标准不断演进以支持新的安全需求 ### 3.2 可追溯性 AUTOSAR 支持需求到模型元素再到实现的可追溯性： - **需求 ID**：每个 AUTOSAR 需求都有唯一标识符 - **元模型引用**：AUTOSAR 元模型支持元素之间的引用关系 - **ARXML 中的可追溯性**：ARXML 格式支持需求到 AUTOSAR 元素的引用 ### 3.3 开发措施与标准的演进 AUTOSAR 标准的演进包括以下开发措施： - **正式变更控制**：所有规范变更都经过正式审查 - **配置管理**：所有文档和代码都有版本控制 - **测试覆盖**：AUTOSAR 提供测试规范以验证实现 - **工具支持**：AUTOSAR 提供开发工具支持规范的实施 ### 3.4 AUTOSAR 未交付的功能安全措施 AUTOSAR 本身不交付以下功能安全措施： - **硬件设计**：AUTOSAR 不定义硬件安全机制 - **生产制造**：生产过程的质量保证 - **运营维护**：运行时的安全监控 - **系统级安全分析**：FTA（故障树分析）、FMEA（失效模式分析） 这些措施需要由集成商和 OEM 单独实施。 ### 3.5 安全相关的方法论与模板扩展 AUTOSAR 元模型支持安全相关扩展： - **SafetyExtensions ARPackage**：包含所有与安全相关的元模型扩展 - **SafetyRequirement**：表示安全需求 - **SafetyMechanism**：表示安全机制 - **SafetyIntegrityLevel**：表示 ASIL 等级 ### 3.6 安全用例 安全用例（Safety Use Case）是 AUTOSAR 安全概念的重要组成部分。详细分析见独立的安全用例示例文档 `AUTOSAR_EXP_SafetyUseCase`（文档 ID 641）。 > **摘要标记**：本节提供了一个安全用例的简要介绍，详细的安全分析方法、前照灯管理（Front Light Management）示例、SW 架构分析等内容请参见 `AUTOSAR_EXP_SafetyUseCase.md` 文档。 ### 3.7 用于功能安全的 AUTOSAR 特性 本节描述 AUTOSAR 中可支持功能安全的特性。 #### 3.7.1 时序相关特性 ##### 3.7.1.1 与提供同步时基相关的特性 AUTOSAR 通过以下机制提供同步时基： - **全局时间（Global Time）**：基于 Ethernet 的精确时间协议（PTP） - **StbM（Synchronized Time-base Manager）**：同步时基管理器 - **CanTSyn / EthTSyn**：CAN / Ethernet 时间同步 **配置参数**： - `StbMTimeBase` — 时基标识 - `StbMSyncLossTimeout` — 同步丢失超时 - `StbMMainFunctionPeriod` — 主函数周期 ##### 3.7.1.2 与异步处理单元同步相关的特性 AUTOSAR 通过以下机制处理多核和多 ECU 系统的同步： - **IOC（Inter-OS-Application Communication）**：OS-Application 间通信 - **多核 RTE**：跨核 RTE 通信 - **数据一致性管理**：跨核数据访问的同步 ##### 3.7.1.3 允许应用时间确定性实现的特性 AUTOSAR 提供以下时间确定性机制： - **静态调度表（Static Schedule Table）**：预定义的任务激活时间 - **调度策略**：固定优先级、时间片、优先级天花板协议 - **时间戳（Time Stamp）**：高精度时间测量 ##### 3.7.1.4 与时序违例保护相关的特性 AUTOSAR 通过以下机制保护时序约束： - **OS 时序保护**：任务执行预算、资源锁时间 - **WdgM 时序监督**：Alive、Deadline 监督 - **执行预算监控**：监控任务的最大执行时间 #### 3.7.2 E-Gas 监控相关特性 E-Gas（电子油门）监控系统是 AUTOSAR 中典型的安全相关应用，涉及： - **三级监控概念**： - 第 1 级：功能层（应用软件） - 第 2 级：功能监控（看门狗） - 第 3 级：硬件监控（外部看门狗） - **AUTOSAR 模块支持**： - **WdgM**：监督功能执行 - **RTE**：确保通信安全 - **OS**：提供时序保护 - **E2E**：保护通信安全 > **摘要标记**：本节详细描述了 E-Gas 监控概念（79-85 页）以及与 AUTOSAR 特性的映射。完整内容请参见原文 PDF。 --- ## 4 硬件诊断 ### 4.1 Core Test（核心测试） #### 4.1.1 故障模型 Core Test 检测以下 MCU 核心故障： - **指令执行故障**：CPU 指令解码或执行错误 - **寄存器故障**：CPU 寄存器损坏 - **ALU 故障**：算术逻辑单元故障 - **程序计数器故障**：PC 寄存器跳转到错误位置 - **栈指针故障**：栈指针损坏 #### 4.1.2 描述 Core Test 通过执行**自检程序**来验证 CPU 的正确性： - **指令测试**：执行所有 CPU 指令并验证结果 - **寄存器测试**：向所有寄存器写入测试模式并读取验证 - **算术测试**：执行算术运算并验证结果 - **逻辑测试**：执行逻辑运算并验证结果 #### 4.1.3 检测与反应 Core Test 的检测和反应： - **执行时机**：通常在 ECU 启动期间和定期运行 - **检测结果**：如果测试失败，标记 Core Test 失败 - **反应动作**： 1. 报告 DEM 错误 2. 切换到安全状态 3. 触发 ECU 复位 #### 4.1.4 限制 Core Test 的限制： - **执行时间**：完整的 Core Test 可能需要较长时间 - **覆盖率有限**：可能无法检测所有类型的瞬态故障 - **需要中断禁用**：Core Test 通常在禁用中断时执行 - **硬件依赖**：测试实现高度依赖于具体 MCU #### 4.1.5 引用 AUTOSAR 文档 - AUTOSAR_SWS_Spi（SPI 处理程序，用于下载测试程序） - AUTOSAR_SWS_Mcu（MCU 驱动） #### 4.1.6 引用 ISO 26262 - ISO 26262-5:2018 第 7.4.11 节（处理器自检） ### 4.2 RAM Test #### 4.2.1 故障模型 RAM Test 检测以下 RAM 故障： - **静态位故障**：RAM 单元永久卡在 0 或 1 - **动态故障**：RAM 内容在写入后立即丢失 - **耦合故障**：一个 RAM 单元的写入影响另一个单元 - **地址解码故障**：写入一个地址影响另一个地址 - **保持故障**：RAM 单元在一段时间后丢失内容 #### 4.2.2 描述 AUTOSAR RAM Test 提供以下测试算法： - **March C-**：经典 RAM 测试算法 - **March C+**：增强版本 - **March SR**：具有更强诊断能力的版本 - **Checkerboard**：棋盘格模式测试 - **Galpat**：走步测试 #### 4.2.3 检测与反应 RAM Test 的检测和反应： - **执行时机**： - 启动时（完整 RAM Test） - 运行时（后台 RAM Test，破坏性较低） - **反应动作**： 1. 报告 DEM 错误 2. 标记相关内存区域为不可信 3. 可能触发 ECU 复位 #### 4.2.4 限制 RAM Test 的限制： - **时间开销**：完整的 RAM Test 占用较长执行时间 - **运行时影响**：运行时 RAM Test 占用 CPU 带宽 - **覆盖率**：检测算法可能无法检测到所有故障 - **内存占用**：测试代码需要额外的内存 #### 4.2.5 引用 AUTOSAR 文档 - AUTOSAR_SWS_RAMTest（RAM 测试规范） #### 4.2.6 引用 ISO 26262 - ISO 26262-5:2018 第 7.4.12 节（RAM 测试） --- ## 5 附录 ### 5.1 缩略语与缩写 | 缩写 | 描述 | |---|---| | ASIL | Automotive Safety Integrity Level（汽车安全完整性等级） | | BSW | Basic Software（基础软件） | | CDD | Complex Device Driver（复杂设备驱动） | | CRC | Cyclic Redundancy Check（循环冗余校验） | | DEM | Diagnostic Event Manager（诊断事件管理器） | | E2E | End-to-End（端到端） | | ECU | Electronic Control Unit（电子控制单元） | | EcuM | ECU State Manager（ECU 状态管理器） | | FMEA | Failure Mode and Effects Analysis（失效模式与影响分析） | | FTA | Fault Tree Analysis（故障树分析） | | FTTI | Fault Tolerant Time Interval（故障容错时间间隔） | | MCU | Microcontroller Unit（微控制器单元） | | MPU | Memory Protection Unit（内存保护单元） | | OS | Operating System（操作系统） | | PDU | Protocol Data Unit（协议数据单元） | | QM | Quality Management（质量管理） | | RTE | Runtime Environment（运行时环境） | | SE | Supervised Entity（监督实体） | | SW-C | Software Component（软件组件） | | WdgM | Watchdog Manager（看门狗管理器） | ### 5.2 相关文档 - AUTOSAR_EXP_LayeredSoftwareArchitecture — 分层软件架构 - AUTOSAR_SWS_WatchdogManager — 看门狗管理器规范 - AUTOSAR_SWS_OS — 操作系统规范 - AUTOSAR_SWS_RTE — 运行时环境规范 - AUTOSAR_SWS_E2ELibrary — 端到端库规范 - AUTOSAR_TPS_SafetyExtensions — 安全扩展 - AUTOSAR_EXP_SafetyUseCase — 安全用例示例 - ISO 26262 — 道路车辆功能安全 --- ## 翻译说明 本文档为 AUTOSAR EXP FunctionalSafetyMeasures（文档 ID 664，96 页，4.4.0 版）的中文翻译。翻译策略： 1. **完整翻译**：封面、文档标识、变更历史、目录、所有主要章节（第 1-4 章）、附录 2. **核心安全机制涵盖**： - **内存分区（Memory Partitioning）**：MPU、OS-Application、RTE 通信隔离 - **时序监控（Timing Monitoring）**：WdgM Alive/Deadline/Logical 监督、OS 时序保护 - **逻辑监督（Logical Supervision）**：检查点与转换图 - **端到端保护（E2E Protection）**：E2E 配置文件、状态机、集成 3. **关键概念涵盖**： - ASIL 等级（A、B、C、D、QM） - 故障模型、检测与反应、限制 - 引用 AUTOSAR 文档与 ISO 26262 4. **摘要处理**：第 3.7 节"E-Gas 监控相关特性"为摘要，详细描述见原文 PDF 5. **保留内容**：所有模块缩写、需求 ID、ASIL 等级引用、ISO 26262 引用 本文档为 AUTOSAR 安全架构师、安全工程师和系统集成商提供了 AUTOSAR 中功能安全机制和措施的全面概述。