79 KiB
应用层错误处理说明
AUTOSAR CP Release 4.4.0
原文：Explanation of Error Handling on Application Level（文档 ID 378）
翻译状态：已完成 v1（封面+变更历史+TOC+Ch 1-10 主体）
对应原文 PDF：
BSWGeneral/AUTOSAR_EXP_ApplicationLevelErrorHandling.pdf
文档标识
| 字段 | 值 |
|---|---|
| 文档标题 | 应用层错误处理说明（Explanation of Error Handling on Application Level） |
| 文档标识号 | 378 |
| 文档所有者 | AUTOSAR |
| 文档责任方 | AUTOSAR |
| 文档状态 | 正式版（Final） |
| 所属 AUTOSAR 标准 | Classic Platform |
| 所属标准版本 | 4.4.0 |
原文头部包含版权声明（Disclaimer）段落，已按规范要求略去，仅在此处说明。原文标题为 "Explanation of Error Handling on Application Level"。
文档变更历史
| 日期 | 版本 | 变更人 | 变更说明 |
|---|---|---|---|
| 2018-10-31 | 4.4.0 | AUTOSAR Release Management | 编辑性修订 |
| 2017-12-08 | 4.3.1 | AUTOSAR Release Management | 编辑性修订 |
| 2016-11-30 | 4.3.0 | AUTOSAR Release Management | 次要修正 / 澄清 / 编辑性变更；详见 ChangeDocumentation |
| 2015-07-31 | 4.2.2 | AUTOSAR Release Management | 次要修正 / 澄清 / 编辑性变更；详见 ChangeDocumentation |
| 2014-10-31 | 4.2.1 | AUTOSAR Release Management | 编辑性修订 |
| 2013-03-15 | 4.1.1 | AUTOSAR Administration | R4.1 定稿 |
| 2011-12-22 | 4.0.3 | AUTOSAR Administration | 初始发布 |
目录
1 介绍
本文档的目的与目标是调研汽车行业中常见的应用层错误处理机制，以及这些机制如何在 AUTOSAR 中使用。这既包括应用层的错误处理（error handling at the application level），也包括对应用层错误（application level errors）的处理。
本文中"错误处理"指完整的处理链，即检测（detection）、隔离/识别（isolation/identification）与恢复（recovery）。本文给出一组适用于汽车系统的错误处理机制，覆盖了错误处理三个阶段。每个机制首先以一种高层级的方式描述其对错误处理的适用性以及技术层面的内容；然后，审查与该机制相关的 AUTOSAR 功能，并详细说明 AUTOSAR 系统中该机制实现或被支持的位置。因此，机制列表中既包含 AUTOSAR 完整（或部分）提供的机制，也包含在系统集成时由应用开发者在 SW-C 层面实现的机制。需要注意的是，本文覆盖的机制集合并不完整，仅限于在 AUTOSAR 4.0 版本的系统上能够实现的机制。也可以使用其他替代或补充机制，AUTOSAR 未来的版本可能支持更多错误处理功能。同样地，本文档并不强制使用任何具体机制——使用何种机制完全由应用开发者和集成者自行决定。
本文档作为可能的机制的描述，主要面向应用 / SW-C 开发者。同时，对 BSW 模块开发者也有参考价值。本文重点关注随机故障（random faults），而非系统性的设计缺陷（如软件 bug）。此类故障的示例包括影响应用、通信或外设的硬件故障。本文聚焦于最适合由 SW-C 处理的错误，不涉及 RTE 及以下层级（如 COM、OS）的错误处理。
2 与其他文档的关系
本文档与 AUTOSAR 内发布的众多其他文档存在关联，尤其是由 AUTOSAR 功能安全（Functional Safety）团队所负责的文档。本文的目的不是替代任何其他文档，而是从应用开发者的视角审视其他工作包所做的工作。因此，本文与其他文档存在显著的内容重叠，这体现了 AUTOSAR 内部的成熟度。
针对每个机制，本文给出了一份关联 AUTOSAR 文档的清单，这构成了本文档与其他 AUTOSAR 文档之间的显式关系。
关于功能安全机制和措施的信息分布在 AUTOSAR 规范文档各处。除非了解功能安全机制是如何被支持的，以及必要信息具体位于何处，否则难以高效地评估如何基于 AUTOSAR 实现一个安全相关的系统。
AUTOSAR 文档《Overview of Functional Safety Measures in AUTOSAR》（AUTOSAR 中功能安全措施概述）总结了 AUTOSAR 中功能安全相关的关键要点，解释了如何使用功能安全机制和措施，并引用了相应的文档。此外，它还有助于建立 ISO 26262 要求与 AUTOSAR 措施和机制之间的映射关系。
3 参考文档
| 编号 | 文档名称 | 文档标识 |
|---|---|---|
| [1] | Software Component Template | AUTOSAR_TPS_SoftwareComponentTemplate |
| [2] | Specification of RTE | AUTOSAR_SWS_RTE |
| [3] | Specification of Operating System | AUTOSAR_SWS_OS |
| [4] | Specification of Communication | AUTOSAR_SWS_COM |
| [5] | Specification of Communication Manager | AUTOSAR_SWS_COMManager |
| [6] | Specification of Diagnostic Communication Manager | AUTOSAR_SWS_DiagnosticCommunicationManager |
| [7] | Specification of ECU State Manager | AUTOSAR_SWS_ECUStateManager |
| [8] | Specification of Function Inhibition Manager | AUTOSAR_SWS_FunctionInhibitionManager |
| [9] | Specification of Diagnostic Event Manager | AUTOSAR_SWS_DiagnosticEventManager |
| [10] | Specification of Watchdog Manager | AUTOSAR_SWS_WatchdogManager |
| [11] | Specification of NVRAM Manager | AUTOSAR_SWS_NVRAMManager |
| [12] | Specification of CRC Routines | AUTOSAR_SWS_CRCLibrary |
| [13] | Specification of Crypto Service Manager | AUTOSAR_SWS_CryptoServiceManager |
| [14] | Specification of Basic Software Mode Manager | AUTOSAR_SWS_BSWModeManager |
| [15] | General Requirements on Basic Software Modules | AUTOSAR_SRS_BSWGeneral |
| [16] | Glossary | AUTOSAR_TR_Glossary |
| [17] | Layered Software Architecture | AUTOSAR_EXP_LayeredSoftwareArchitecture |
| [18] | Specification of SW-C End-to-End Communication Protection Library | AUTOSAR_SWS_E2ELibrary |
| [19] | Specification of Module Core Test Driver | AUTOSAR_SWS_CoreTest |
| [20] | Specification of Flash Test | AUTOSAR_SWS_FlashTest |
外部参考：
| 编号 | 文献 |
|---|---|
| [21] | Algirdas Avizienis, Jean-Claude Laprie, Brian Randell, and Carl Landwehr, "Basic Concepts and Taxonomy of Dependable and Secure Computing", IEEE Transactions on Dependable and Secure Computing, Vol. 1, No. 1, January-March 2004 |
| [22] | Jim Gray, "Why Do Computers Stop and What Can We Do About It", Technical Report TR 85.5, Tandem, 1985 |
| [23] | ISO CD 26262-1 Road vehicles – Functional Safety – Part 1: Glossary |
| [24] | EASIS Deliverable D1.2-8, "Fault management framework", http://www.easis-online.org/ |
4 文档导读
根据读者对可靠性系统（dependable system）领域各类术语和定义的熟悉程度，部分章节可以快速翻阅甚至跳过。如果您对可靠性系统领域非常熟悉，可以直接跳到第 9 节。在表 4-1 中，我们对后续各章进行了总结，便于您识别最感兴趣的部分。
表 4-1：本文档后续章节概览
| 章节 | 描述 |
|---|---|
| 5 术语与定义 | 本节包含本文档使用的术语概览，包括 fault、error、failure 的定义，FDIR（Fault Detection, Isolation and Recovery，故障检测、隔离与恢复）流程的描述，以及各种失效模式的描述。如果您对可靠性系统领域的概念较为熟悉，可以快速浏览本节。 |
| 6 范围 | 本节描述了本文档所做的假设。假设包括 BSW 中存在某些基本可靠性机制。 |
| 7 错误模型 | 本节描述了从汽车应用的角度看最为重要的若干错误类型。后续章节列出的机制均按照其对各类错误处理的适用性进行归类。 |
| 8 错误处理机制 | 本节列出并描述了 AUTOSAR 提供或支持的应用层错误处理机制。每个机制包含高层级描述、适用性讨论、实现层级（应用层 vs. BSW）讨论以及可用于实现该机制的 AUTOSAR 概念与服务概览。 |
| 9 维度映射 | 本节给出已介绍机制的概览，并将其映射到 FDIR 流程、错误模型与实现层级。 |
| 10 分区的终止与重启 | 本节描述了在 AUTOSAR R4.0 中集成分区（partition）终止与重启能力的方法。本节比本文其他部分更加 AUTOSAR 特定，汇集了关于 AUTOSAR 内分区层级错误处理的所有描述和说明。 |
5 术语与定义
5.1 基本可靠性术语
本文使用的可靠性（dependability）基本概念和术语直接沿用文献 [21]。本节对可靠性系统使用的主要术语和定义进行简要概述。需要特别说明的是，本文中"系统"一词的使用范围非常广泛，可以是单个 SW-C，也可以是包含多个网络和 ECU 的完整车辆。然而，由于本文档主要面向应用层错误处理，在本文档其余部分，"系统"应理解为软件应用（software application），可能由多个 SW-C 组成，可分布在多个（分布式的）ECU 上。
可靠性（Dependability）被定义为"系统的可信赖性，使用户能够合理地信赖其所提供的服务"。这意味着一个可靠的系统能够使用户（无论人类还是非人类）相信系统所提供的服务是正确的。系统的可靠性由一组属性刻画，由一组损害威胁，并通过一组手段实现和分析。
可靠性属性刻画并描绘了给定系统的可靠性。典型的属性包括：可用性（availability）、可靠性（reliability）、安全性（safety）、机密性（confidentiality）、完整性（integrity）、可维护性（maintainability）。
在系统（广义概念，可以是整个 ECU 或单个 SW-C）的构造和运行过程中，可能出现一些事件，通过向系统中引入故障（fault）来降低系统的可信赖性。故障是系统的瞬态或永久性变更，使其完整性偏离预期的正确完整性。在系统运行过程中，故障可能阻碍系统提供其预期服务。这些故障可能来自内部（如软件缺陷）或外部（如外部干扰、组件老化）。可能降低系统可靠性的事件称为可靠性损害。
然而，故障的存在本身并不足以降低系统的可靠性。故障必须被激活——也就是说，系统中存在故障的部分必须以某种方式在系统运行中被执行（例如，故障代码必须被执行，缺陷的内存位置必须被读取等）。如果发生这种情况，其结果可能是错误（error）。如果将故障视为一种疾病，则错误可视为该疾病的症状。错误被定义为系统中错误的（软）状态，即与若无故障时系统应有的状态不同的状态。被激活的错误可能会引起系统中其他错误的发生，这一过程称为错误传播（error propagation）。
如果错误传播超出了系统边界，即对系统外部环境可见，则错误转化为失效（failure），这意味着系统不再提供其规定的功能。
因果链 故障 → 错误 → 失效 在本质上是递归的。因此，一个系统的失效对包含它的系统而言就是故障（即，前者是后者的子系统）。例如，特定软件组件中的失效可视为整个应用（由一组 SW-C 组成）中的故障。因此，我们可以得到如下序列：
… 失效 → 故障 → 错误 → 失效 → 故障 …
用于实现和分析系统可靠性的方法称为可靠性手段。本文档的目的就是记录并研究 AUTOSAR 为应用开发者实现错误处理所提供的手段。
注意：本文档涵盖的是系统运行期间主动发挥作用的机制，不包括用于实现功能安全的过程和方法学（如开发流程、设计方法学、调试），这些适用于系统开发阶段，而非系统运行阶段。
5.2 故障检测、隔离与恢复（FDIR）
系统运行过程中处理故障的过程通常称为 FDIR，即故障检测（Fault Detection）、隔离（Isolation）、恢复（Recovery）。
检测（Detection）
处理故障的首要步骤是察觉故障的发生。没有检测，后续活动都无法进行。说到检测，原始的故障通常很难被直接检测到。能被检测到的是故障的效果，即错误。这些错误通过对系统状态的监控来检测。
错误可以通过多种方式表现。主要表现包括：
- 数据错误（data errors）：系统中的值错误；
- 时序错误（timing errors）：执行时间错误；
- 程序流错误（program flow errors）：执行序列或顺序错误；
- 资源访问错误：对系统资源（如内存）的访问错误。
错误可能传播并生成后续故障，进而导致新的错误。例如，一个错误的数据值被用作指针时，会引起内存访问违例；如果向该错误内存位置写入值，则可能在另一个数据值中产生错误的值。用于检测错误的大多数机制允许系统执行某些动作以获取关于错误源的更多信息（隔离）并发出纠正或补偿动作（恢复）。理想情况下，检测应在错误进一步传播之前完成，从而阻止进一步传播。然而，在大多数情况下还需要额外的恢复动作，如停止出错的组件或重新配置为替代功能。
隔离（Isolation）
一旦故障（或错误）被成功检测到，就需要进行损害评估（damage assessment）与损害控制（damage control），即需要隔离。在隔离阶段，努力寻找系统中错误状态的根因，并收集信息（如关于错误传播范围与原因）以供错误恢复阶段使用。寻找错误状态的根因并不总是可行的（或实际的）。需要说明的是，本文中隔离指的是隔离错误的源以便恢复成为可能；它不指为阻止错误传播而对系统的特定组件进行的隔离。某种意义上，**识别（identification）**一词可能更合适，但鉴于 FDIR 流程的描述中常用"isolation"一词，我们在此沿用。
恢复（Recovery）
隔离完成后，将启动恢复动作。这些动作的目标是将系统转移到一个受控状态，该状态可以是完全恢复并提供标称服务，也可以是安全降级状态，即提供有限或无服务。隔离结果越好，恢复动作的效果就越好。
如果恢复不成功，就可能发生失效，即系统处于非受控状态，其服务不再被定义。
6 范围
本文档涉及应用视角下的错误处理。它描述了应用层检测、隔离与恢复机制，以及能够处理与应用相关的故障（如内存访问违例、时序违例）的机制。
重点关注对主要由外部随机故障产生的错误的处理。尽管系统性故障（即设计缺陷）可能以与外部故障相同的方式表现，但它们不是本文档的主要目标。系统性故障的处理与开发相关（如过程、设计方法学、调试），而非系统运行期间的错误处理。
AUTOSAR 中的错误处理不局限于应用层错误处理。BSW 自带多种内建错误处理机制，能够提供可靠的通信、同步等。然而，这些机制不在本文档的描述范围内。
7 错误模型
可靠系统的设计基于对潜在故障（故障模型，fault models）的系统分析——即一组假定的故障，从系统运行环境派生而来，帮助设计者或使用者预测这些故障的后果并定义处理（检测、恢复等）这些特定故障的机制。
故障可以在系统所有层级上表现，从纯随机硬件故障（如位翻转）到软件（如设计缺陷）以及组件间交互中的故障（如不完整的接口规范）。同样地，故障是在整个设计过程（需求、分析、设计、实现等）中引入的。由于本文档聚焦应用层错误处理，重点放在预期由 AUTOSAR 软件组件处理的错误，无论是因为 FDIR 流程需要应用层知识，还是因为错误已从较低层传播上来。需要注意的是，本文档中考虑的某些类型的错误可以由 BSW 处理，但部分错误可能会传播到应用层，因此必须在应用层处理。
重要提示：重点是错误的处理，而错误是故障的效果。尽管设计缺陷可以以与外部故障相同的方式表现，但它们不是本文档的主要目标。设计缺陷的处理与调试相关，而非错误处理。
本文档仅考虑运行期间的错误处理。不在范围内的是通过严格或形式化开发过程实现的**故障避免（fault-avoidance）与故障消除（fault-removal）**技术。
重点主要是外部随机故障，即其出现可建模为随机过程的故障。然而，这并不意味着所述机制不能处理系统性故障，因为此类故障的后果（错误）可以以与随机故障相同的方式表现。瞬态故障和永久故障均被考虑；某些机制对其中一种更合适。
由于本文档中只考虑软件机制，实际上检测的是错误而非故障本身。因此，在本文档其余部分使用**错误模型（error model）**一词来代替故障模型。由于错误是已被激活并传播的故障，单个错误（理论上）可能有多个可能的根因，即多个故障。
为简化讨论，错误模型被划分为若干更广泛的错误类别，如表 7-1 所示。这些类别的选择是因为它们易于映射到软件机制。然而，需要注意的是，错误模型之间是相互关联的。分支指令中使用的错误数据值可能传播并成为程序流错误，从而延迟（或改变）执行输出，造成例如响应延迟，即时序错误。
表 7-1：所考虑的错误类型
| 错误类型 | 描述 |
|---|---|
| 数据（Data） | 数据错误以参数、变量或消息的错误值为特征。错误的来源可以是内部（如软件缺陷）也可以是外部（如传感器失灵、其他 SW-C 故障）。处理数据错误可以打破因果链，从而避免后续更复杂的错误，如程序流或访问违例。 |
| 程序流（Program flow） | 程序流错误（也称"控制流错误"）表现为实际程序流与预期不同，可能导致遗漏、错误或多余的操作被执行。程序流错误的来源既可以是内部（软件缺陷），也可以是外部（数据错误）。 |
| 访问（Access） | 为了在执行组件之间加强隔离，系统设计者可以对软件进行分区（partition），并限制来自分区的资源访问，如内存访问。当组件试图在没有适当访问权限的情况下访问另一个分区的资源时，会发生访问违例。访问错误可能是数据或程序流错误的结果，例如无效的程序计数器或指针。 |
| 时序（Timing） | 通信（消息、函数调用等）具有时间关键性，传递时间对通信的正确性/有效性有影响。时序错误可以是消息过早传递、过晚传递或完全丢失（omission）。omission 类型的时序错误特别值得关注，有时称为**崩溃（crash）或静默失效（fail-silent）**行为（注意：崩溃与静默失效可能无法区分，前者是非受控状态，后者是受控状态）。时序错误也指执行时间，可以为组件访问 CPU 的最长时间定义严格的截止时间。 |
| 非对称（Asymmetric） | 当错误通过某种通信方式从一个 SW-C 传播到另一个时，可以区分对称和非对称错误。在对称情况下，所有接收方收到相同的（错误）值。当组件可能通过发送不同值（可能都是有效的）而失效时，该错误称为非对称错误。这种错误模型有时也称为拜占庭模型，它意味着对故障组件的行为不做任何假设。拜占庭错误只能通过使用冗余组件相互交换值以达成共识来检测。 |
由于本文档的范围限于应用层处理的错误，第 8 节介绍的机制并未考虑所有错误类型。以下错误类型不在明确考虑范围之内：
- 通信错误：此类错误不包含在本文中，因为假设 SW-C 可获得可靠的通信。唯一可能的通信错误是设计故障，即 SW-C 中的 bug。请注意，SW-C 仍应处理 COM 上报的通信错误，或将 COM 配置为在 BSW 中处理错误。
- 死锁与活锁：死锁和活锁由 BSW 中的看门狗机制检测，因此本文档中不进一步考虑。这些情况当然可以导致其他时序错误，这些错误可以在应用层检测。在这种情况下，应用可以处理死锁或活锁的影响，但不一定能处理其根因。
- 指令代码中的故障和错误：在应用层，通常无法检测由于存储介质或处理器内部故障而出现错误的指令。然而，此类故障大多数情况下会导致非法指令，当处理器尝试执行时会被检测到。如果产生的指令是合法的，则很可能转变为系统中的其他类型错误（如数据错误、时序错误等），这些错误可以通过其他方式检测和处理（如本文档中所述）。在 BSW 中，存在用于测试处理器内核、Flash 内存和 RAM 的组件，它们可以检测可能导致指令代码错误的异常。
8 错误处理机制
本节在高层、概念性的层面上描述一组机制。这些机制可由应用开发者用于在应用的描述或实现中集成错误处理。
每个机制被分类为对特定错误类型（第 7 节定义）适用或不适用。如果一个机制是适用的，则表示该机制适合用于检测（或隔离或恢复）某一特定类型的错误集。重要的是，这并不意味着特定类型的所有错误都会被检测到。每个机制都需要被调整以检测所需的特定错误，可能只能处理某错误类中的子集。
一些机制仅在部分适用——即可以与其他机制联合以直接方式使用。例如，当检测到来自传感器的值错误时，可以使用替代（安全）值作为恢复的一种形式。然而，这仅部分解决了来自故障传感器的恢复；完全恢复还需要其他机制，如传感器的重新初始化。部分适用的机制也标记为适用。
当一个机制不适用时，意味着该机制在特定步骤和错误模型下没有直接用途。在某些情况下，修改可能赋予该机制一些可用性，但很可能存在更好的选择。
注意：下面列出的一些机制可能具有副作用，如系统的内存访问模式和时序行为。特别是时序行为可能受到影响，这需要设计者显式处理，以便系统的所有时序特性是已知的，无论是在正常运行还是错误处理期间。
另请注意：尽管描述了许多机制，但并不总是需要组合不同的机制，而且机制之间甚至可能产生不良的相互影响。
8.1 合理性检查（Plausibility checks）
8.1.1 描述
将应用特定的知识纳入的最常见方法之一是构造监控器（monitors），以检查某个变量或一组变量的当前值是否满足某些预定义条件，即它们是否合理。合理性检查是定义在应用中一组变量上的谓词，可在运行时动态检查。所检查的值可以表示用于计算的值、状态值或其他类型的值。
合理性检查主要有两种形式：
- 检查单个值的有效性。顾名思义，对值的有效性进行检查，即值是否落在"良好"值的范围内，是否遵循已知的模式或行为等。这种辨别通常只能利用关于应用和/或其环境的具体知识，例如最大车速、最低发动机温度等。检查可以是范围类型（在一个范围或一组"良好"值内）也可以是差分类型（与前一个值的变化、小于等）。差分变化也可以是时序的，其中检查的周期性可以附加额外条件（如速度在时间 T 内不能变化超过 x km/h）。这需要进一步的特定应用信息，如检查的周期性等。
- 比较多个值。检查一组单个值的有效性可能带来所有值都有效的情况。然而，跨集合中所有值执行比较可以揭示原本会被遗漏的错误，方法是检测一组看起来有效的值的特定组合是不合理的。这些比较可以使用多个值之间的物理关系进行计算（例如，发动机转速与车速和传动比相比较），或通过比较来自冗余源的数据（例如，测量相同温度的多个温度传感器）。这种情况下的主要问题是区分错误的值与正确的值。对于某些应用（特别是安全相关的应用），可以使用冗余数据源以增加对数据有效性的置信度，例如使用多个传感器读数（如冗余传感器或重复读取值）。当存在两个值时，可以对这两个值进行比较，其结果要么是它们相同（可能在某个容差范围内），因而被视为正确，要么是不同，表明（其中一个值）存在错误。错误检测之后，需要采取额外措施来隔离和恢复该错误。
比较作为机制不同于有效性检查，因为它仅基于比较两个值，不考虑值的合理性。比较不同于投票（8.3 节），因为它在单个 SW-C 内处理，而投票可以跨多个 SW-C，例如通过执行冗余 SW-C（多样化或相同）并对结果进行投票。比较在本地进行且始终是二元的——比较两个值。
我们选择将合理性检查与状态检查区分开来。后者可以独立于应用知识进行，并作为单独的机制呈现（8.8 节：状态与模式管理）。然而，作为失败的合理性检查的结果，应用可以设置其他应用和 BSW 可以检查和操作的状态标志。
8.1.2 适用性
表 8-1：合理性检查的适用性矩阵
| 步骤 \ 错误模型 | 数据 | 程序流 | 访问 | 时序 | 非对称 |
|---|---|---|---|---|---|
| 检测 | X | ||||
| 隔离 | X | ||||
| 恢复 |
有效性检查用于检测应用中的数据错误，可定义允许/禁止值的范围。该机制受限于设计者基于需求和/或应用知识定义此类范围的能力。此类范围的维护和可追溯性必须在开发过程中处理。在生产代码中保留未文档化或未更新的检查会对应用的可靠性构成风险。
在某些情况下，可以定义"安全"值以替代超出有效值范围的值，这被定义为单独的机制（8.2 节：替代值）。
有效性检查仅对检测数据错误有用。在某些情况下，检查可以成为隔离步骤的一部分——通过使用其他合理性检查来获得关于错误的额外信息，例如在使用比较或投票（8.3 节）时确定哪个值（多个值中）是错误的。这样，应用特定的知识可以在隔离错误时使用。
比较可以通过识别多个值之间的差异来检测数据错误。由于比较基于数据值，因此不支持其他错误模型。可能很难隔离多个值中哪个是错误的。如果有效性检查未显示任何无效值，则无法指示哪个值是错误的。
合理性检查通常不适用于检测程序流、时序或非对称错误。合理性检查通常不能用于恢复。
8.1.3 应用层 vs. BSW
合理性检查可以实现为可执行断言，其中使用简单的 if 语句检查一个或多个变量的值。它在 SW-C 的源代码中实现，但通常不影响应用的整体结构。检查在大多数情况下可以使用确定性时序实现（不考虑去抖动）。数据的内存需求通常较低，仅限于为差分检查保存值。
8.1.4 AUTOSAR 参考
表 8-2：合理性检查的 AUTOSAR 参考
| 名称 | 类型¹ | 文档 | 说明 |
|---|---|---|---|
| SW-C 端到端通信保护 | SWS | E2E Library [18] | 定义发送方和接收方之间的协议 |
| Flash 测试 | SWS | FLSTST [20] | 与已知签名比较 |
| 内核测试 | CORTST [19] | ||
| RTE | SWS | RTE [2] | 支持缩放值的范围检查 |
| AUTOSAR COM | SWS | COM [4] | PDU 复制和比较 |
¹ SWS = 软件规范， SRS = 软件需求规范
SW-C 端到端通信保护库可用于检查信号是否来自意外的 SW-C 发送方，或当接收到的信号提供的信息并非其预期提供的信息时。它还允许定义能够检查是否按顺序接收到信号实例流的 SW-C（根据用例，这也可以在 AUTOSAR COM 级别配置）。
Flash 测试和内核测试模块可以在单处理器或多处理器 ECU 的上下文中配置，以对 ECU 硬件执行检查。这些检查与硬件的已知良好签名进行比较。
RTE 可以检查通信值是否与其允许范围匹配。
8.2 替代值（Substitute Values）
8.2.1 描述
一旦检测到错误，正确的值将无法分配给信号，则可以给该信号分配替代值。该替代值可在后续计算中使用，从而使计算结果有用，尽管质量可能有所下降。可以分配替代值的情况示例包括：
- 传感器失灵或在其工作范围外运行（例如，通过合理性检查检测到），且相应的物理实体无法可靠测量。可以分配一个替代值，使后续使用该值的算法能够继续其计算。
- 输入信号的提供 SW-C 被报告为失灵，因此即使某个特定值似乎在其有效域内，其结果也不应被信任。
- 临时检查（例如，启动序列刚结束后）需要满足合理性检查，但此时传感器尚不可用。通常设置"待定"（pending）状态标志。
由于使用了替代值，使用信号限定符通知接收方原始值不可用可能是有用的。接收方可以决定如何解释和使用该值。
请注意，AUTOSAR 中没有通用的信号限定符机制。应用应定义自己的机制，例如通过传输带有值和限定符的记录。
8.2.2 适用性
表 8-3：替代值的适用性矩阵
| 步骤 \ 错误模型 | 数据 | 程序流 | 访问 | 时序 | 非对称 |
|---|---|---|---|---|---|
| 检测 | |||||
| 隔离 | |||||
| 恢复 | X | X | X | X |
分配替代值为后续操作提供了一种以使最终结果有用的方式进行的手段。然而，它不会从错误中恢复，因为它并未缓解导致错误状态的情况。因此，它对恢复是部分适用的，因为它允许在一定程度上掩盖现有错误。
由于用替代值掩盖的错误状态可能是任何类型的潜在错误的结果，因此它对所有错误类型都是部分适用的。
8.2.3 应用层 vs. BSW
替代值通常需要平台层所没有的应用知识，在这种情况下分配在 SW-C 中执行。在配置时，BSW 模块可以配置默认的替代值。然而，通常仍需要应用特定的知识。
8.2.4 AUTOSAR 参考
表 8-4：替代值的 AUTOSAR 参考
| 名称 | 类型 | 文档 | 说明 |
|---|---|---|---|
| 软件组件模板 | SWS | SWC-T [1] | 初始值和默认值的使用 |
| 模板、RTE、AUTOSAR COM | RTE [2] & COM [4] | ||
| 软件组件模板 | SWS | SWC-T [1] | 默认 ROM 块或冗余块的使用 |
| 模板、NVM | NVM [11] |
SW-C 设计者可以在 UnqueuedReceiverComSpec 上指定 initValue。当没有接收到值但应用读取该值时，将使用此值。根据 UnqueuedReceiverComSpec 的 handleInvalid 属性（dontInvalidate、keep、replace），它也可以在值无效的情况下使用。这些 initValue 由 COM（[4]）或 RTE（[2]）根据 SW-C XML 描述实现（参见软件组件模板 [1]）。
还可以为 UnqueuedSenderComSpec、InterRunnableVariables、PerInstanceMemory 或 NvBlockComponentTypes 的 ramBlocks 指定 initValue（参见软件组件模板 [1]）。
NVM（[11]）在失败情况下可以使用默认 ROM 块。该块可由 SW-C 设计者使用 defaultData 角色中的 ParameterDataPrototype 定义（参见软件组件模板 [1] 中的 RoleBasedDataAssignment）。
8.3 投票（Voting）
8.3.1 描述
构建容错系统的一个基本原则是冗余地执行代码片段（"组件"），然后通过对每个组件的结果执行投票来合并结果。实际投票通常由专用的"投票器（voter）"组件执行。常见的投票算法包括"简单多数"、"三取二"等。
投票可在多个层级执行——从单个 SW-C 中的可运行实体（runnable）复制到跨 ECU 的应用层投票。复制可以在二进制/源代码层或规范层上完成。在前者中，每个组件是同一原始组件的副本，而在后者中，组件是不同的，但基于相同的规范构建。
与 8.1 节中介绍的比较机制相反，投票可以处理两个以上的副本，并且根据副本数量，投票还可以提供隔离（识别有故障的副本）和部分恢复（输出良好值）。
8.3.2 适用性
表 8-5：投票的适用性矩阵
| 步骤 \ 错误模型 | 数据 | 程序流 | 访问 | 时序 | 非对称 |
|---|---|---|---|---|---|
| 检测 | X | ||||
| 隔离 | X | ||||
| 恢复 | X |
投票用于检测数据错误。此外，如果对三个或更多值进行投票（且至多一个值有误），则可以识别错误值的来源。由于即使存在错误也能产生正确值，投票部分支持恢复。完全从错误中恢复需要其他手段。
8.3.3 应用层 vs. BSW
投票在 SW-C 中执行。
8.3.4 AUTOSAR 参考
AUTOSAR 不提供投票服务。由于投票机制不由 AUTOSAR BSW 提供，因此需要由需要它们的应用在 SW-C 中的应用层实现。AUTOSAR 支持 SW-C 的多个实例化。SW-C 实现者可使用此功能为应用实现特定的投票机制。
8.4 协商（Agreement）
8.4.1 描述
当使用冗余组件来提高应用的可靠性时，组件（称为参与者）可能需要通过交换本地计算结果作为消息²就使用的值（包括某些计算的结果）达成一致。
协商和投票机制之间的区别在于：在使用协商时，组件之间进行交互以达成决策，而在投票中，决策留给投票器。协商协议可与闭环系统相比较，其中反馈由所有其他方接收的已发送消息组成。投票类似地可与开环系统相比较，其中投票器收集值并做出决定。
协商协议还可以通过多轮信息交换处理非对称故障。因此，所有（正确的）参与者就相同的值以及彼此的正确性达成一致。
8.4.2 适用性
表 8-6：协商的适用性矩阵
| 步骤 \ 错误模型 | 数据 | 程序流 | 访问 | 时序 | 非对称 |
|---|---|---|---|---|---|
| 检测 | X | X | |||
| 隔离 | X | X | |||
| 恢复 | X | X |
由于值与投票类似地进行比较，协商机制可以检测和隔离数据值错误。额外的信息交换轮次也允许检测和隔离非对称错误。协商不能处理程序流或时序错误。
恢复是部分支持的，因为有故障的参与者可以被识别，其行为被屏蔽以免影响系统。完全从错误中恢复需要其他手段。
8.4.3 应用层 vs. BSW
基本服务在 BSW 层实现，但使用协商协议的应用必须意识到它们正在参与的事实。提议新值和采用一致值是需要应用意识到协议的情况示例。
² 显然也可以使用其他通信范式，消息仅作为示例使用。
8.4.4 AUTOSAR 参考
AUTOSAR 中不存在真正的协商服务。如果应用层通信需要特定的协商语义，则必须为这些应用专门实现。
8.5 校验和/编码（Checksums/Codes）
8.5.1 描述
提高数据一致性的技术是向要保护的数据值添加冗余信息。额外的信息允许检测数据（部分）修改，在某些情况下甚至可以纠正和恢复原始数据值。其代价是性能（计算和检查校验和的时间、额外的通信需求）和存储的额外内存需求。扩展还包括提供数字签名和数据加解密的加密算法。
校验和/编码有多种用途，包括：
- 在易失性和非易失性内存中安全存储数据
- SW-C 之间（ECU 内和跨 ECU）的可靠通信
- 保护数据免受未经授权实体的篡改（数据完整性）
- 通过不安全通道发送和接收加密数据
请注意前两种情况（涉及良性错误）与后两种情况（涉及恶意错误，如攻击者、入侵者等）之间的区别。然而，相同的机制通常可以用于多种目的。
数据安全的其他威胁包括欺骗（spoofing，假装是他人）、否认（repudiation，否认执行的操作）、拒绝服务和权限提升。一般来说，本文档重点关注良性错误。然而，这些威胁对于某些应用可能很重要。
8.5.2 适用性
表 8-7：校验和/编码的适用性矩阵
| 步骤 \ 错误模型 | 数据 | 程序流 | 访问 | 时序 | 非对称 |
|---|---|---|---|---|---|
| 检测 | X | X | |||
| 隔离 | X | X | |||
| 恢复 | X | X |
校验和和编码主要针对 FDIR 流程中的数据保护。根据使用的编码类型，可以支持流程的所有步骤。
编码也用作某些协议（例如协商）的一部分，用于处理非对称故障。
8.5.3 应用层 vs. BSW
出于性能和可移植性的原因，校验和和加密库在 BSW 层或作为库实现。使用专用外围电路进一步减少了对应用层机制的使用。
8.5.4 AUTOSAR 参考
表 8-8：校验和/编码的 AUTOSAR 参考
| 名称 | 类型 | 文档 | 说明 |
|---|---|---|---|
| 加密服务管理器 | SWS | CSM [13] | 访问加密功能/硬件 |
| CRC 例程 | SWS | CRC [12] | CRC 例程 |
| SW-C 端到端通信保护 | SWS | E2E Library [18] | SW-C 通过信号添加额外的 CRC |
CSM 可由 SW-C 通过端口接口用于计算加密校验和或编码。
CRC 是一个库，可由 SW-C 直接使用以计算校验和。
SW-C 端到端通信保护库可用于定义协议，并通过端口接口使用校验和或编码保护 SW-C 发送的数据。
8.6 执行序列监控（Execution sequence monitoring）
8.6.1 描述
应用的正确执行包括可执行实体的序列正确。监控执行序列能够检测可能导致错误结果的错误执行路径。
执行序列的监控可以在不同的粒度级别执行。粒度级别的示例包括：
- 单个语句：这是可以在源代码级别监控执行序列的最细粒度。监控代码中单个语句的序列。
- 基本块（Basic blocks）：基本块是具有一个入口点和一个出口点的代码块，不能从这两个入口和出口点之外进入或退出。因此，从入口点到出口点的执行是严格顺序的。请注意，最小的基本块是单个语句。基本块的执行序列可以在所谓的控制流图中指定，以该粒度监控执行序列就是确保按此图执行。此上下文中的"控制流"与"程序流"同义。
- 可运行实体（Runnables）：可运行实体具有一个入口点，但可能有多个出口点和从入口点到这些出口点的多个有效执行路径。此外，路径可能包括循环。在这个级别上，监控一个（或多个）应用的可运行实体的执行序列。
根据监控器的粒度，资源需求可能从相当低到非常高。监控单个语句的序列可能需要大量内存和处理时间，而可运行实体的序列可能以非常低的内存和执行时间开销进行监控。
8.6.2 适用性
表 8-9：执行序列监控的适用性矩阵
| 步骤 \ 错误模型 | 数据 | 程序流 | 访问 | 时序 | 非对称 |
|---|---|---|---|---|---|
| 检测 | X | ||||
| 隔离 | |||||
| 恢复 |
执行序列的监控将检测程序流中的错误。这些错误可能是先前的数据错误、时序错误或非对称错误的结果。但是，监控器本身无法区分这些。
监控器不能用于从错误中恢复，因为它仅对照某个预定义的正确性概念检查当前状态（这对所有类型的监控器都是如此，而不仅仅是执行序列的监控器）。
8.6.3 应用层 vs. BSW
最实用的方法可能是应用和 BSW 之间的协作，其中应用向 BSW 提供其执行轨迹中的位置信息，然后 BSW 检查该位置是否是有效位置。这需要预定义的有效轨迹。一种方法可能是为执行轨迹中一组位置的给定位置配置有效的后继。粒度（指令、基本块、可运行实体）可以在配置时定义。
8.6.4 AUTOSAR 参考
表 8-10：执行序列监控的 AUTOSAR 参考
| 名称 | 类型 | 文档 | 说明 |
|---|---|---|---|
| 看门狗管理器 | SWS | WdgM [10] | 监督计数器和程序流监控 |
| SW-C 端到端通信保护 | SWS | E2E Library [18] | 消息上的数据序列控制 |
| AUTOSAR COM | SWS | COM [4] | 通过总线发送的消息的序列计数器 |
看门狗管理器可以监控来自应用组件的心跳，不仅监控时间还监控序列。执行的正确序列由开发人员配置。配置包含一组**检查点（checkpoints）或监测点（spy points）**的定义，以及每个这样的点的允许后继集合。然后由 SW-C（即开发人员）负责确保每个检查点/监测点被报告给看门狗管理器，看门狗管理器再检查该序列。
8.7 活跃性监控（Aliveness monitoring）
8.7.1 描述
活跃性监控（aliveness monitoring）用于检查应用或软件组件在一段时间内是否执行了某些工作。这是对执行序列监控（8.6 节）的补充和简化——它不检查执行的顺序，而是检查是否执行了。
活跃性监控通过让被监控的实体定期向监控器发送"心跳"或"活跃性信号"来工作。如果在配置的监控时间内没有收到来自被监控实体的信号，则可以指示错误。
8.7.2 适用性
表 8-11：活跃性监控的适用性矩阵
| 步骤 \ 错误模型 | 数据 | 程序流 | 访问 | 时序 | 非对称 |
|---|---|---|---|---|---|
| 检测 | X | X | |||
| 隔离 | |||||
| 恢复 |
活跃性监控主要检测与时序相关的故障，特别是与应用或组件停止执行（崩溃或省略故障）相关的故障。它还可用于检测一些程序流错误（如执行卡在错误位置）。
8.7.3 应用层 vs. BSW
活跃性监控通常需要 BSW 支持，因为监控器需要能够检测缺失的心跳。这通常由看门狗管理器（WdgM）实现。
8.7.4 AUTOSAR 参考
表 8-12：活跃性监控的 AUTOSAR 参考
| 名称 | 类型 | 文档 | 说明 |
|---|---|---|---|
| 看门狗管理器 | SWS | WdgM [10] | 监督计数器和心跳监控 |
看门狗管理器（WdgM）提供监督功能，包括检查受监控实体是否在配置的监督周期内发送心跳。
8.8 状态与模式管理（Status and Mode Management）
8.8.1 描述
应用可以维护关于自身和外部世界状态的信息。此状态信息可用于通知其他组件关于已检测到的情况，并允许它们相应地调整其行为。
状态信息通常以状态标志或模式的形式表达。当应用检测到异常情况（如失败的合理性检查）时，它可以设置一个状态标志，该标志可以由其他 SW-C 和 BSW 模块读取和操作。
模式管理是状态管理的扩展——除了简单的标志之外，模式代表复合状态。例如，ECU 可能处于"启动"、"运行"、"关闭"等模式。模式由模式管理器（如 BswM、ComM、EcuM）管理。
8.8.2 适用性
表 8-13：状态与模式管理的适用性矩阵
| 步骤 \ 错误模型 | 数据 | 程序流 | 访问 | 时序 | 非对称 |
|---|---|---|---|---|---|
| 检测 | X | ||||
| 隔离 | X | ||||
| 恢复 | X | X |
状态标志和模式可用于所有错误处理步骤。它们通常用于在其他组件之间传达检测到的情况，并协调恢复动作。
8.8.3 应用层 vs. BSW
状态信息可以在应用层和 BSW 层都维护。模式管理主要由 BSW 模块提供（如 BswM、ComM、EcuM、Dem、FIM），但应用层也可以定义特定于应用的模式。
8.8.4 AUTOSAR 参考
表 8-14：状态与模式管理的 AUTOSAR 参考
| 名称 | 类型 | 文档 | 说明 |
|---|---|---|---|
| 基础软件模式管理器 | SWS | BswM [14] | BSW 模式仲裁 |
| ECU 状态管理器 | SWS | EcuM [7] | ECU 状态管理 |
| 通信管理器 | SWS | ComM [5] | 通信模式管理 |
| 功能抑制管理器 | SWS | FIM [8] | 功能抑制管理 |
| 诊断事件管理器 | SWS | Dem [9] | 诊断事件状态 |
BswM 根据各种来源（应用、BSW、其他模式管理器）的请求，仲裁应激活的模式。ComM 管理通信模式。EcuM 管理 ECU 状态。FIM 根据 Dem 上报的事件抑制某些功能。Dem 管理诊断事件的状态。
8.9 重新配置（Reconfiguration）
8.9.1 描述
在某些错误情况下，系统可以通过重新配置到替代行为来恢复。这可能涉及：
- 关闭出错的组件或分区
- 切换到冗余组件
- 改变算法或参数
- 降级到有限功能模式
重新配置通常由应用级错误管理器（ALEM，参见第 10 节）或模式管理器（如 BswM）协调。
8.9.2 适用性
表 8-15：重新配置的适用性矩阵
| 步骤 \ 错误模型 | 数据 | 程序流 | 访问 | 时序 | 非对称 |
|---|---|---|---|---|---|
| 检测 | |||||
| 隔离 | X | ||||
| 恢复 | X | X | X | X | X |
重新配置主要用于恢复阶段，可以处理几乎所有类型的错误。
8.9.3 应用层 vs. BSW
重新配置决策通常在应用层做出（因为需要应用知识），但执行可以涉及 BSW 模块（如 EcuM 关闭 ECU，ComM 关闭通信）。
8.9.4 AUTOSAR 参考
表 8-16：重新配置的 AUTOSAR 参考
| 名称 | 类型 | 文档 | 说明 |
|---|---|---|---|
| ECU 状态管理器 | SWS | EcuM [7] | ECU 关闭/重启 |
| 基础软件模式管理器 | SWS | BswM [14] | 模式切换 |
| 通信管理器 | SWS | ComM [5] | 通信模式切换 |
EcuM 处理 ECU 的关闭和重启。BswM 协调 BSW 模式切换。ComM 协调通信模式。
8.10 复位（Reset）
8.10.1 描述
当其他恢复机制失败时，复位是最终的恢复机制。复位有多种类型：
- 软复位（Soft reset）：仅复位应用层，保留 BSW 状态
- 硬复位（Hard reset）：复位整个 ECU
- POR（Power-On Reset）：完全断电后重启
复位会清除易失性内存中的状态，因此可能影响其他应用。
8.10.2 适用性
表 8-17：复位的适用性矩阵
| 步骤 \ 错误模型 | 数据 | 程序流 | 访问 | 时序 | 非对称 |
|---|---|---|---|---|---|
| 检测 | |||||
| 隔离 | |||||
| 恢复 | X | X | X | X | X |
复位是最激进的恢复机制，可处理几乎所有类型的错误，但代价是丢失状态和对其他应用的潜在影响。
8.10.3 应用层 vs. BSW
复位主要由 EcuM 在 BSW 层处理。应用可以请求复位，但实际执行在 BSW 中进行。
8.10.4 AUTOSAR 参考
表 8-18：复位的 AUTOSAR 参考
| 名称 | 类型 | 文档 | 说明 |
|---|---|---|---|
| ECU 状态管理器 | SWS | EcuM [7] | ECU 复位 |
| 看门狗管理器 | SWS | WdgM [10] | 看门狗超时复位 |
EcuM 处理 ECU 复位。WdgM 在检测到监督失败时可以触发 ECU 复位。
8.11 错误过滤（Error Filtering）
8.11.1 描述
在某些情况下，不应将每个检测到的错误传递给上层处理。例如，临时性错误或可恢复的错误可能不需要触发整个错误处理链。错误过滤机制允许基于某些标准（如错误频率、严重性、上下文）抑制或延迟错误处理。
AUTOSAR 中的 FIM（Function Inhibition Manager）模块是该机制的典型实现。
8.11.2 适用性
表 8-19：错误过滤的适用性矩阵
| 步骤 \ 错误模型 | 数据 | 程序流 | 访问 | 时序 | 非对称 |
|---|---|---|---|---|---|
| 检测 | X | X | X | X | X |
| 隔离 | |||||
| 恢复 |
错误过滤适用于所有类型的错误，因为它是一种预处理机制，作用于其他机制产生的错误。
8.11.3 应用层 vs. BSW
错误过滤由 BSW 模块（FIM）实现，但配置中包含应用特定的知识。
8.11.4 AUTOSAR 参考
表 8-20：错误过滤的 AUTOSAR 参考
| 名称 | 类型 | 文档 | 说明 |
|---|---|---|---|
| 功能抑制管理器 | SWS | FIM [8] | 基于 Dem 事件的功能抑制 |
| 诊断事件管理器 | SWS | Dem [9] | 诊断事件状态 |
FIM 根据 Dem 上报的事件和预定义的抑制条件，抑制某些功能（如允许的操作）。
8.12 内存保护（Memory Protection）
8.12.1 描述
内存保护机制通过硬件支持（如 MPU——内存保护单元）确保应用只能访问其被授权的内存区域。违反访问权限将触发保护违例，由 OS 捕获并传递给 Protection Hook 处理。
8.12.2 适用性
表 8-21：内存保护的适用性矩阵
| 步骤 \ 错误模型 | 数据 | 程序流 | 访问 | 时序 | 非对称 |
|---|---|---|---|---|---|
| 检测 | X | ||||
| 隔离 | X | ||||
| 恢复 |
内存保护专门针对访问错误。
8.12.3 应用层 vs. BSW
内存保护完全在 OS 层实现，并由底层硬件（MPU）支持。应用层不能直接控制它。
8.12.4 AUTOSAR 参考
表 8-22：内存保护的 AUTOSAR 参考
| 名称 | 类型 | 文档 | 说明 |
|---|---|---|---|
| 操作系统 | SWS | OS [3] | OS-Application 与内存保护 |
| ECU 抽象层（Memory） | SWS | MemIf / Ea / Fee | 内存抽象 |
OS 通过 OS-Application 概念提供内存保护（参见第 10 节）。
8.13 时间保护（Timing Protection）
8.13.1 描述
时间保护机制确保应用满足其时间预算。它通过以下方式实现：
- 执行时间预算：每个任务/中断必须在配置的时间内完成
- 到达率：任务/中断的到达频率必须在配置的范围内
- 锁定时间：资源被持有的时间必须在限制内
时间违例由 OS 捕获并传递给 Protection Hook。
8.13.2 适用性
表 8-23：时间保护的适用性矩阵
| 步骤 \ 错误模型 | 数据 | 程序流 | 访问 | 时序 | 非对称 |
|---|---|---|---|---|---|
| 检测 | X | ||||
| 隔离 | X | ||||
| 恢复 |
时间保护专门针对时序错误。
8.13.3 应用层 vs. BSW
时间保护完全在 OS 层实现，依赖硬件计时器支持。应用层不能直接控制它。
8.13.4 AUTOSAR 参考
表 8-24：时间保护的 AUTOSAR 参考
| 名称 | 类型 | 文档 | 说明 |
|---|---|---|---|
| 操作系统 | SWS | OS [3] | 时间保护机制 |
OS 通过 OS-Application 概念提供时间保护。
9 维度映射
9.1 映射到 FDIR 流程和错误模型
表 9-1：错误处理机制概述
| 机制 | 章节 | 适用错误类型 | FDIR 阶段 |
|---|---|---|---|
| 合理性检查 | 8.1 | 数据 | 检测、隔离 |
| 替代值 | 8.2 | 全部 | 恢复（部分） |
| 投票 | 8.3 | 数据 | 检测、隔离、恢复（部分） |
| 协商 | 8.4 | 数据、非对称 | 检测、隔离、恢复（部分） |
| 校验和/编码 | 8.5 | 数据、非对称 | 检测、隔离、恢复 |
| 执行序列监控 | 8.6 | 程序流 | 检测 |
| 活跃性监控 | 8.7 | 时序、程序流 | 检测 |
| 状态与模式管理 | 8.8 | 全部 | 全部（用于协调） |
| 重新配置 | 8.9 | 全部 | 恢复 |
| 复位 | 8.10 | 全部 | 恢复（最终） |
| 错误过滤 | 8.11 | 全部 | 检测（预处理） |
| 内存保护 | 8.12 | 访问 | 检测、隔离 |
| 时间保护 | 8.13 | 时序 | 检测、隔离 |
FDIR 阶段：
- 检测（Detection）：识别错误是否已发生
- 隔离（Isolation）：识别错误的根源
- 恢复（Recovery）：将系统转移回受控状态
9.2 映射到实现层级
表 9-2：实现层级映射
| 机制 | 主要实现层级 | AUTOSAR 模块 |
|---|---|---|
| 合理性检查 | SW-C | （无标准支持） |
| 替代值 | SW-C + COM/RTE | COM, RTE, NVM |
| 投票 | SW-C | （无标准支持） |
| 协商 | SW-C | （无标准支持） |
| 校验和/编码 | BSW（库） | CRC, CSM, E2E |
| 执行序列监控 | SW-C + BSW | WdgM, E2E, COM |
| 活跃性监控 | SW-C + BSW | WdgM |
| 状态与模式管理 | 两者 | BswM, EcuM, ComM, FIM, Dem |
| 重新配置 | 应用层 + BSW | EcuM, BswM, ComM |
| 复位 | BSW | EcuM, WdgM |
| 错误过滤 | BSW | FIM, Dem |
| 内存保护 | OS | OS |
| 时间保护 | OS | OS |
10 分区的终止与重启
10.1 介绍
终止和重启是处理严重错误的最后手段。本节描述了如何在 AUTOSAR R4.0 中实现这一能力。
典型的故障场景包括：
- 软件分区中的保护违例：内存访问违例、时序违例、执行时间超时
- 应用级检测到的不可恢复错误：ALEM 判定应用无法继续运行
注意，该方法可能处理外部瞬态故障以及内部设计故障。唯一的要求是故障导致上述故障场景之一。
本文档描述了 BSW 中提供的基本支持，列出了开发人员/集成商成功使用此功能的责任，并提供了解决方案的建议。
10.1.1 汽车应用
使用 AUTOSAR 构建的汽车系统中的应用可以由多个交互的 SW-C组成，这些 SW-C 可映射到多个分区。可能存在影响 SW-C/分区位置的映射决策，例如：
- 节省资源
- 由于映射约束（如传感器/执行器）
- 通过冗余和/或隔离提供容错
因此，应用由一组潜在的分布式 SW-C/分区组成。
哪些 SW-C 属于某个应用或分区的映射未在 AUTOSAR 中显式建模。但是，映射对系统设计者是已知的，其也负责指定应如何处理错误。因此，假设设计者可以定义终止或重启分区是否对特定应用是合适的响应；如果是，可以终止或重启哪些分区（以及由此哪些 SW-C）。该信息随后由 OEM 用于构建整车的整体恢复策略。
重要的是，AUTOSAR SW-C 通常不能在设计者不了解此事实并相应地设计应用的情况下被重启。
10.1.2 软件分区与错误遏制区
软件分区是通用 OS 的主要目标之一，随着嵌入式软件的复杂性增加，在嵌入式系统中也日益受到关注。AUTOSAR 术语表将分区定义为："分解（Decomposition），将整个系统分离为功能单元，并进一步分离为软件组件"。在错误处理和安全的上下文中，分区一词的含义被扩展为**错误遏制区（error containment regions）**的定义和实施，即系统（大多数情况下是 OS）确保某些类型的错误被包含在其发生的（预定义）区域内，不会传播到外部，从而避免在其他区域产生新错误。这包括：
- 保护一个错误遏制区的内存免受其他错误遏制区的非法写入
- 防止应用软件独占 CPU
- 对系统资源（如系统服务、外设）的访问规则进行强制
当分区中的软件违反 OS 设置的保护规则时，其执行通常会被强制停止，用户可以选择：
- 重启有问题的软件，希望引起违例的故障是瞬态的，重启时将不复现
- 如果错误被视为不可恢复，则终止有问题的软件，以避免对其他分区造成干扰
对于汽车系统，错误恢复通常通过以下方式执行：
- 协作式恢复：由仍部分功能的应用调用专用恢复机制（如 FIM、DEM、BswM 修改 SW-C 行为）
- ECU 复位：重置发生违例的 ECU
第一种方法在引起故障的故障不构成恢复机制代码的障碍时有效。然而，使软件进入设计者未预见的状态的故障通常不能通过此方法处理，而是使用 ECU 复位。如果此类复位能够足够快地执行而不违反应用截止时间，且不会对其他应用产生不利影响，则它们是良性的。
随着 ECU 上集成多个应用（可能独立且具有混合关键性），需要软件分区以确保错误传播在应用之间被最小化，并在发生故障时保持独立性。
10.2 基本原理——用例
终止和重启应用是最小化错误传播和执行错误恢复（主要是重启功能）的基本方法。已为 AUTOSAR 错误处理识别两个主要用例。
10.2.1 用例 1：软件分区 [UC1]
软件分区用于通过为分区的软件在空间和时间维度上指定明确定义的边界，防止一个分区的故障影响传播到同一 ECU 上的其他分区。通过终止分区，可以实现所谓的静默失效（fail silent）行为。此外，对于构建安全论证和混合关键性应用在同一 ECU 上执行时的责任考虑，这是一个重要方面。更多相关信息，请参见 OS SWS [3]。常用的此类技术示例是内存分区和执行时间（截止时间）监控。
内存分区和执行时间监控可用于检测内存访问错误和时序错误，并防止它们破坏其他分区中的软件。但是，当此类错误发生时，需要系统做出反应。最直接的方法是不允许有问题的软件继续执行，即强制终止它。这将防止错误传播，但可能使系统处于不一致状态，因为分区中的软件在终止时可能正在与其他分区和/或 BSW 中的软件交互。因此，必须明确规定系统的行为和一致性规则，以便一个分区可以在另一个分区的突然终止或重启带来的意外干扰下继续执行。
AUTOSAR 支持内存分区和执行时间监控。可以定义 SW-C 必须在其中执行的时间边界，以及不能被覆盖的内存分区，从而保护一个分区中的 SW-C 免受其他分区中 SW-C 的错误内存访问。
这两个概念都使用 OS 级特性 OS-Application [3]。对于 OS-Application，OS 提供时序和内存保护，前提是它们已配置且（对于内存保护）硬件支持可用。当检测到错误（保护违例）时，需要调用适当的反应。
10.2.2 用例 2：应用级错误处理 [UC2]
应用级错误处理可用于两个主要目的：
- 分布式汽车应用的错误处理
- OEM 特定的错误处理
10.2.2.1 分布式汽车应用的错误处理
通常，汽车应用（如 10.1.1 节所述）可以分为多个分区，这些分区形成不同的错误遏制区。这些分区可能映射到不同的 ECU。
应用分部的这种分布的管理需要在应用级处理，因为分区的划分和分区到 ECU 的映射信息在 BSW 层不可用。
**应用级错误管理器（ALEM，Application-level Error Manager）**将处理由此分布引起的问题。例如，如果分区的终止导致需要终止其他分区（不一定在同一 ECU 上），则将由 ALEM 触发。
10.2.2.2 OEM 特定的错误处理
影响分区的错误不一定像 UC1 中那样导致保护违例，但可能强制分区进入无法自行恢复并继续执行的状态。必须终止它以最小化错误传播，或从已知的"良好"状态重启它以取得进展。对于此类错误，终止或重启分区的决策和动作必须由外部实体做出，因为影响分区状态的错误也可能影响其恢复能力。但是，使用哪种恢复策略（终止/重启、哪些分区/SW-C 等）的决策是OEM 特定的，不能由 AUTOSAR 通用化和标准化。
10.2.2.3 应用级错误管理器
处理上述两个方面需要引入**"错误管理器"——即监控系统的健康状况并在必要时启动恢复的软件应用**。图 1 展示了此类设置的示例。
恢复可能从发送应用特定指令、启动应用的重新配置到终止/重启应用或整个 ECU 不等。在本文档的概念中，我们关注 SW 应用的终止和重启。
图 1：应用级错误管理器（ALEM）监控系统的健康状况，并根据应用或 OEM 特定的恢复策略启动恢复动作。
架构示意：
SW-C 1 SW-C 2 ALEM SW-C 3 ↓ ↓ ↓ AUTOSAR Runtime Environment (RTE) Mode Managers (BswM, EcuM, ComM) COM, Watchdog, Memory, Debug, Diagnostics, CDD ↓ OS, I/O Hardware Abstraction
此用例类似于 EASIS 项目 [24] 中开发的故障管理框架（FMF，Fault Management Framework）。本文档中提出的功能在 FMF 中有对应的功能。
此外，应用级的错误管理将能够考虑分布。也就是说，如果汽车应用分布在多个分区（甚至多个 ECU）上，则 BSW 将无法执行协调的终止/重启。需要协调（不一定同步）跨多个 ECU 的分区的终止或重启的情况可以由 ALEM 管理。
NB1：在本节其余部分中，每当我们的意思是一个允许触发分区终止和重启的 SW-C 时，我们将引用应用级错误管理器（ALEM）。
NB2：此方法不旨在标准化 ALEM、其行为或其接口。
脚注：ALEM 也可以实现为 BSW 模块，但这是一个不太灵活的解决方案。这还需要更多的工作来为此目的指定 AUTOSAR BSWM，并引入可能分布在多个 ECU 上的 BSW 模块的概念。这不在本概念范围内。
10.3 终止和重启分区的方法
后续章节描述了 AUTOSAR OS、BSW 和 RTE 中的支持。
10.3.1 OS 特性
本节描述了 OS 提供的基本功能机制，将用于集成终止或重启分区的可能性。
10.3.1.1 OS-Applications
AUTOSAR OS 使用称为 "OS-Applications" 的构造（参见 [3]）。OS-Application 是一组 OS 对象，如任务、中断服务例程、报警、调度表等。从 OS 的角度看，OS-Application 形成了一个内聚的功能单元。例如，可以定义应用特定的钩子函数（hook functions），如启动和关闭钩子函数。
OS-Application 用作分区的基础，即分区之间的保护在 OS-Application 级别强制执行。软件分区用于例如内存访问控制或时序控制，但是解决系统中错误传播的通用方法。分区被定义为错误遏制区，即在适当强制的情况下，一个分区中发生的错误不会扩散到其他分区。
对于 OS 控制的对象，有多种保护机制可用（参见 [3]）。与终止/重启方法相关的机制是内存保护和时序保护。内存保护涵盖 OS-Application 的栈和数据，可选地还包括代码。时序保护基于执行时间预算和到达率。
OS-Application 分为 i) 可信 OS-Application 和 ii) 不可信 OS-Application（参见 [3]）。
- 可信 OS-Application 在特权模式下运行，可以关闭所有（OS 级别）监控执行。也就是说，假定可信应用永远不会违反内存访问权限或截止时间。
- 不可信 OS-Application 在非特权模式下运行，由 OS 自动监控内存访问和截止时间违例。SW-C 被分配到不可信 OS-Application 或 BSW 的一个可信 OS-Application。每个 OS-Application 包含零个、一个或多个 SW-C。
10.3.1.2 保护钩子（Protection Hook）
系统具有单个全局 Protection Hook。当发生保护违例时，OS 调用 Protection Hook，其作用是决定作为对错误的反应应执行哪个动作。Protection Hook 通过一个指示检测到的违例类型的参数值调用。Protection Hook 可以查询哪个 OS-Application³ 引起违例，然后决定 OS 在钩子返回后应执行的必要动作（见上文）。如果未配置保护钩子，OS 将调用 ShutdownOS()。Protection Hook 的返回值定义 OS 执行的进一步动作：
PRO_IGNORE：不执行任何操作PRO_TERMINATETASK：强制终止有故障的 Task / Category 2 OsIsrPRO_TERMINATEAPPL：强制终止有故障的 OS-ApplicationPRO_TERMINATEAPPL_RESTART：强制终止有故障的 OS-Application 并触发OSRestartTask的执行PRO_SHUTDOWN：调用ShutdownOS()
预期集成商与应用设计者一起决定错误处理策略，即是否执行终止、重启、错误过滤等。
当应用级请求的终止或重启被发出时（详见 10.3.2.4 节），决策已经做出，OS 仅执行请求。对于这种外部触发的终止或重启，不执行 Protection Hook。
终止或重启 OS-Application 是仅在 OS 中执行的活动。为了终止或重启分区，必须在 BSW 中并可能在分区的 SW-C 中执行一组清理活动。这些清理活动将放置在 OSRestartTask 中，该任务仅在 Protection Hook 的返回码为 PRO_TERMINATEAPPL_RESTART 时触发。
重要提示：对于终止或重启分区，Protection Hook 必须返回
PRO_TERMINATEAPPL_RESTART。否则将没有机会执行清理活动。
³ 假定集成商了解 Os-Application ID（由 OS
GetApplicationId()API 返回）、分区和分区名称（用于通知 RTE 终止或请求重启）之间的映射。
10.3.1.3 TerminateApplication() API
OS 提供用于显式终止或重启 OS-Application 的 API。此 API 支持在 SW-C 级别触发与 Protection Hook 触发的相同机制。
API 形式如下：
StatusType TerminateApplication(
ApplicationType Application,
RestartType RestartOption
);
其中 Application 指的是 OS-Application 的 ID（在 OS 配置期间生成），RestartOption 是：
RESTART：将触发OSRestartTask（等同于 Protection Hook 的PRO_TERMINATEAPPL_RESTART）NO_RESTART：仅终止 OS-Application（等同于 Protection Hook 的PRO_TERMINATEAPPL）
10.3.1.4 OSRestartTask
OSRestartTask 是当 Protection Hook 返回 PRO_TERMINATEAPPL_RESTART 时启动的任务。当此任务执行时，它将是分区中唯一运行的任务。OSRestartTask 的内容未由 AUTOSAR 标准化。
在 OSRestartTask 中，可以执行终止或重启分区所需的任何清理活动。需要注意的是，尽管该任务名为 OSRestartTask，OS-Application（或 OS）没有自动重启。在 OSRestartTask 执行期间，仍存在一个关于是终止还是重启 OS-Application（从而是分区）的主动决策。
10.3.1.5 OS-Application 状态机
OS-Application 可处于以下状态之一（参见 OS SWS [3] 和图 2）：
APPLICATION_ACCESSIBLE：在此状态下，未检测到保护违例，OS-Application 中的软件正常运行。APPLICATION_RESTARTING：OS-Application 在检测到严重错误后处于紧急状态。OS-Application 的资源不能从其他 OS-Application 访问，只有OSRestartTask正在运行。所有其他任务/OsIsrs/报警等均被终止。向 OS-Application 传递信息的唯一方式是从内部轮询（即从OSRestartTask内部）。APPLICATION_TERMINATED：OS-Application 不再存在。没有运行任何东西。不允许从其他 OS-Application 访问。退出此状态的唯一方式是重启 OS（通过重启 ECU）。
图 2：OS-Application 状态机
Initial
↓
AllowAccess(AppID)
↓
APPLICATION_ACCESSIBLE
↑ ↓
PRO_TERMINATEAPPL_RESTART, PRO_TERMINATEAPPL,
TerminateApplication(AppID, TerminateApplication(AppID,
RESTART) NO_RESTART)
↓ ↓
APPLICATION_RESTARTING APPLICATION_TERMINATED
(仅 OSRestartTask)
转换说明：
- 从
Initial通过AllowAccess(AppID)进入APPLICATION_ACCESSIBLEAPPLICATION_ACCESSIBLE通过PRO_TERMINATEAPPL_RESTART或TerminateApplication(AppID, RESTART)进入APPLICATION_RESTARTINGAPPLICATION_ACCESSIBLE通过PRO_TERMINATEAPPL或TerminateApplication(AppID, NO_RESTART)进入APPLICATION_TERMINATED- 从
APPLICATION_RESTARTING调用AllowAccess(AppID)重新进入APPLICATION_ACCESSIBLE
10.3.2 从 OS-Application 到分区
本节描述如何从 OS-Application 概念扩展到支持分区的终止和重启所需的更高级别功能。
10.3.2.1 概述
OS 仅提供 OS-Application 的终止和重启。但是，分区终止/重启还需要其他活动，例如通知 RTE 以停止向终止的分区发送通信。本节列出这些活动并描述其执行。
10.3.2.2 分区状态机
分区是 OS-Application 概念的应用级抽象。分区可以包含一个或多个 OS-Application。每个分区都有自己的状态机，与 OS-Application 状态机并行工作。
分区状态机由**分区终止和重启任务（Partition Termination and Restart Task）**执行，该任务对应于 OSRestartTask。
10.3.2.3 清理活动
终止或重启分区时需要执行以下清理活动：
- 通知 RTE：调用
Rte_PartitionTerminated_<partition>()或Rte_PartitionRestarting_<partition>()通知 RTE 该分区正在终止或重启 - 停止 BSW 模块：停止与该分区关联的 BSW 模块
- 清理共享资源：释放分区持有的所有共享资源（如信号量、内存）
- 通知其他分区：通过 ALEM 通知其他分区
- 触发重启（如果是重启）：重启 OS-Application 中的任务
10.3.2.4 应用级终止/重启请求
应用级 SW-C（ALEM）可以通过 TerminateApplication() API 发起终止或重启请求。请求将导致 OS 启动终止/重启过程。
注意：
TerminateApplication()可由 SW-C 在运行时调用，而 Protection Hook 仅由 OS 在保护违例时调用。
10.3.3 分区终止和重启的序列图
下图展示了分区终止和重启的典型序列：
ALEM RTE OS BSW 其他分区
│ │ │ │ │
│ TerminateApplication(AppID, RESTART) │
│ ──────────────►│ ──────────────►│ │ │
│ │ │ 停止 Task │ │
│ │ │ ──────────────►│ │
│ │ │ 触发 OSRestartTask │
│ │ │ ──────────────►│ │
│ │ │ 清理活动 │
│ │ │ ──────────────►│ │
│ │ Rte_PartitionRestarting_<p>() │
│ │ ◄──────────────────────────────────────────────────│
│ │ │ AllowAccess(AppID) │
│ │ │ ──────────────►│ │
│ │ │ │ 分区已重启 │
│ │ │ │ ──────────────►│
10.3.4 用例支持
| 用例 | OS 支持 | BSW 支持 | RTE 支持 | 应用层支持 |
|---|---|---|---|---|
| UC1：软件分区 | OS-Application 终止/重启 | Dem、WdgM | Rte_PartitionTerminated | （无标准） |
| UC2：应用级错误处理 | OS-Application 终止/重启 | Dem、WdgM、FIM、BswM | Rte_PartitionTerminated | ALEM（自定义） |
10.3.5 一致性方面
10.3.5.1 应用级一致性
任何由重启分区引起的应用级不一致预期由 SW-C 自身处理。但是，SW-C 可以信任 RTE 相对于已终止/重启的分区以一致且定义明确的方式行为。10.3.5.3 节介绍了 RTE 为实现此目标所需的一致性要求。
10.3.5.2 BSW 一致性
BSW 一致性需要通过在重启或终止分区时执行的清理活动来确保。有关这些活动的详细信息，请参见 10.3.2.3 节。
10.3.5.3 通信一致性
当分区被终止或重启时，这可能导致通信方之间的（临时）通信丢失。在所有此类情况下，AUTOSAR 必须确保系统是一致的，即系统仍可以在没有不良副作用的情况下取得进展。处理 SW-C（包含在分区中）被终止或重启的情况是应用开发人员的工作。
为处理分区被终止并因此无法再对事件做出反应的情况，必须定义系统相对于已终止分区的行为。请注意，由于错误遏制区是分区，分区内通信的一致性是不相关的，因为分区中的所有任务都已终止。因此，只有分区之间（包括跨 ECU）通信才能导致一致性问题。
主要原则应如下：考虑我们有两个分区相互交互的情况。在某个时刻，其中一个分区被终止（重启）。对于剩余分区来说，无论已终止（重启）的分区是驻留在同一 ECU 上还是另一个 ECU 上，对此的感知应相同。其结果是，RTE 行为在两种情况下应相同。
该原则意味着应使用超时监控来检测信息接收方（在 SR 和 CS 通信中）是否已终止。尝试与已终止（或正在重启）的分区发起通信应导致超时通知，与原始信号丢失或接收 ECU 未响应的情况相同。它也不强加给分区"知道"通信是本地还是远程的负担，即使在失败的情况下也是如此。
分区重启后，其状态可能与其他分区的状态视图不一致。例如，如果两个消息（CS 和 SR）之间存在依赖关系，则可能因重启而中断。
10.4 集成商责任
集成商对实现终止和重启动作负有总体责任，通过提供 Protection Hook 和 Restart Task 的代码以及任何用于协调和正确集成功能的粘合代码。
以下是由集成商或开发人员完成以正确处理分区终止和重启的事项清单：
- 将应用分解为 SW-C，并根据所选分区/错误遏制区对 SW-C 进行分组。
- 根据分解结果配置分区和 OS-Application。
- 为每个 SW-C 指示其是否可以终止或重启（当然，确保 SW-C 的实现支持这一点）。
- 为每个分区指示其是否可以终止或重启。
- 决定分区的错误处理策略。将重启和终止的决策基于例如错误类型和先前重启次数，以及与该决策相关的任何其他信息。
- 在 Protection Hook 中实现所选策略和决定（请记住，整个 ECU 只有一个全局 Protection Hook）。使用
Rte_PartitionTerminated_<partition>()或Rte_PartitionRestarting_<partition>()通知 RTE 该决定。返回表示该决定的适当代码：PRO_IGNORE：如果不应执行任何操作PRO_TERMINATEAPPL_RESTART：如果应重启或终止分区PRO_SHUTDOWN：如果 OS（并最终 ECU）应关闭
- 在分区的
OSRestartTask中实现必要的清理动作（每个分区有一个这样的任务）并相应配置 BSW。请记住，此任务应在终止和重启分区时都触发，并且必要的清理动作不一定对两者都相同。因此，OSRestartTask必须能够查明是应终止还是重启分区，以便执行正确的清理动作。建议的方法是实现 10.3.2 节中描述的分区状态机。 - 如果需要跨多个分区的应用级错误处理协调，则实现**应用级错误管理器（ALEM）**作为专用 SW-C 或作为另一个 SW-C 的一部分。请注意，此类 ALEM 不得位于其要监视的任何分区中。使用
TerminateApplication()API 控制来自 ALEM 的分区的终止和重启。
已知限制
无已知限制。
翻译说明
- 本文档为说明性文档（EXP），非规范（Specification）
- 涵盖 13 种应用层错误处理机制：合理性检查、替代值、投票、协商、校验和/编码、执行序列监控、活跃性监控、状态与模式管理、重新配置、复位、错误过滤、内存保护、时间保护
- 重点是 FDIR（故障检测、隔离与恢复） 流程的应用层实现
- 第 10 节详细描述了 OS-Application 与分区 的关系，以及通过 Protection Hook、OSRestartTask 和 ALEM（应用级错误管理器） 实现分区终止与重启的方法
- 与 SWS_BSWGeneral 和功能安全文档（SRS_BSWGeneral）配合使用
- 涉及的主要 AUTOSAR 模块：
Dem（诊断事件管理器）、FIM（功能抑制管理器）、BswM（基础软件模式管理器）、WdgM（看门狗管理器）、EcuM（ECU 状态管理器）、ComM（通信管理器）、OS（操作系统） - 文档中保留了
⌈⌋形式的 AUTOSAR 方框符和SWS_xxx类型标识符 - 表格标题、表头、图标题已翻译；API 名称（如
TerminateApplication、ShutdownOS、AllowAccess、Rte_PartitionTerminated_<partition>）、OS 返回值（PRO_IGNORE、PRO_TERMINATETASK、PRO_TERMINATEAPPL、PRO_TERMINATEAPPL_RESTART、PRO_SHUTDOWN）、状态名（APPLICATION_ACCESSIBLE、APPLICATION_RESTARTING、APPLICATION_TERMINATED）、OS-Application 概念等保留英文
翻译：opencode-translator / Step 3 P0 批量翻译