01 引 入

功能安全是一个从系统设计之初就需要考虑的特性，因为它可能会影响系统设计的决策。因此，AUTOSAR规范中包含了与功能安全相关的要求。

AUTOSAR并不是一个完整的安全解决方案。使用AUTOSAR并不意味着符合ISO 26262标准。不过，AUTOSAR也通过提供安全措施和机制来支持安全相关系统的开发，本文就介绍几个相关的功能安全机制。

02 功能安全机制

现在很多ECU包含高度模块化的嵌入式软件，这些软件可以由与非安全相关的软件组件和安全相关的软件组件组成，这些组件执行具有不同ASIL等级的功能。

根据ISO 26262标准，如果嵌入式软件由具有不同ASIL等级的软件组件组成，那么整个软件必须按照最高的ASIL等级进行开发，或者必须确保具有较高ASIL等级的软件组件免受具有较低ASIL等级的元素的干扰。

此外，ISO 26262标准还提供了导致软件组件之间产生干扰的故障示例，这些故障被归类为以下几类：

• 时序故障
• 执行故障
• 内存故障
• 信息交换故障

下面将介绍AUTOSAR功能安全机制。这些机制有助于预防、检测和减轻硬件和软件故障，以确保软件组件之间不存在干扰。

注意： AUTOSAR功能安全机制用于支持安全相关系统的开发。因此，功能安全机制（软件和硬件）是安全相关的，必须按照相应的要求进行开发和集成。

03 时间监控

在嵌入式系统中，时间特性是一个至关重要的属性。为了确保系统的安全性，系统的动作和反应必须在正确的时间内完成。

“正确的时间”可以通过一组必须满足的时间约束来描述。然而，一个AUTOSAR SWC本身并不能确保正确的时间特性。它依赖于AUTOSAR RTE和 BSW 的适当支持。在集成过程中，需要确保AUTOSAR SWC的时间约束得到满足。

故障模型

根据ISO 26262标准，以下与执行时间和执行相关的故障可以视为软件组件之间产生干扰的原因：

执行阻塞： 某个任务的执行被意外中断或延迟。

死锁： 两个或多个任务因相互等待对方释放资源而无法继续执行。

活锁 ： 任务之间不断尝试获取资源但总是失败，导致所有任务都无法继续执行，尽管没有真正的锁被持有。

执行时间分配错误： 分配给某个任务的执行时许不正确，可能导致任务无法按时完成。

软件元素间同步错误： SWC 之间的同步机制出现问题，导致任务无法正确协调执行。

时间保护与监控

时间保护与监控主要关注以下属性的监测：

任务调度监测： 确保任务在指定的时间被正确调度执行。

执行时间预算监测： 检查任务是否在其分配的执行时间内完成。

资源占用监测： 防止任务长时间占用操作系统资源，如CPU，从而影响其他任务的执行。

保障安全相关功能的时序约束

为了确保与安全相关的功能能够遵守其时序约束，系统需要能够检测和处理那些可能独占CPU的任务（如高CPU负载、大量中断请求等）。这些任务如果未得到妥善处理，可能会导致系统无法满足其时序要求，从而影响安全功能的有效性。

看门狗机制

AUTOSAR提供了以下时间监控机制：

• 使用操作系统的时间保护机制。
• 使用 看门狗管理器 进行时间程序流监控。

下面解释下看门狗管理器在实现应用软件时间监控方面的适用性。时间程序流监控包括截止期监督（Deadline Supervision）和存活监督（Alive Supervision）两种机制。

看门狗管理器负责监控AUTOSAR中应用软件的执行。这些被监控的逻辑单元被称为“ 受监控实体 ”。受监控实体与AUTOSAR架构中的构建块之间不存在固定的关系。通常，根据开发者的选择，一个受监控实体可能代表一个SWC、SWC内的一个Runnable、一个BSW模块或CDD模块。

在受监控实体中，重要的位置被定义为“检查点”。受监控实体的代码与看门狗管理器的函数调用交织在一起。这些调用用于向看门狗管理器报告已达到某个检查点。看门狗管理器（Watchdog Manager）是AUTOSAR架构的一个基础软件模块。

看门狗管理器将看门狗硬件的触发与软件执行的监督联系起来。 当检测到程序执行中配置的时间或逻辑约束被违反时，将采取一系列可配置的操作来从这种故障中恢复。

存活监督： 周期性受监督实体对其执行频率有约束。通过存活监督，看门狗管理器定期检查在给定的限制内，受监督实体的检查点（Checkpoints）是否已经达到。这意味着看门狗管理器检查受监督实体是否运行得不太频繁或不太稀少。

存活监督是使用一个无转换的检查点来执行的。受监督实体必须周期性地调用检查点来指示其及时操作。看门狗管理器由操作系统周期性地执行，以验证检查点参数。一个受监督实体也可以由多个存活监督实例进行监控，因此每个存活监督都包含一个独立的检查点。

具有独立检查点的存活监督

截止时间监督： 非周期性或偶发性受监督实体在两个检查点之间的时间间隔上有各自的约束。通过截止时间监督，看门狗管理器检查受监督实体的两个检查点之间转换的时间。这意味着看门狗管理器会检查受监督实体中的某些步骤所花费的时间是否在配置的最小值和最大值之间。

截至时间监督

如果第二个检查点从未被达到，那么截止时间监督将无法检测到这个问题。这个问题之所以出现，是因为看门狗管理器是在第二个检查点被调用之后才进行时间检查的。

基于这些监督机制，看门狗管理器会启动一系列恢复机制，包括软件组件或复杂设备驱动程序的错误处理、分区关闭、硬件看门狗重置和立即MCU重置，以从监督故障中恢复。

04 逻辑监督

逻辑监督是一种检查软件正确执行的机制，它主要关注控制流错误。

在应用程序无错误执行期间，控制流错误会导致程序偏离有效的（即已编码/编译的）程序序列。如果一条或多条程序指令以错误的顺序被处理，或者甚至根本没有被处理，就会发生错误的控制流。控制流错误可能会导致数据不一致、数据损坏或其他软件故障。

故障模型

根据ISO 26262标准，以下和执行相关的故障可以视为软件组件之间发生干扰的原因：

• 执行阻塞
• 死锁
• 活锁
• 执行时间分配错误
• 软件元素之间同步错误

采用程序序列的逻辑和时间监控，并在例如ISO 26262等标准中提及，作为检测CPU故障的措施，以及作为检测硬件时钟故障的措施。

程序序列执行中的故障（即程序序列的无效执行）可能导致数据损坏、进程崩溃或静默故障违规。ISO 26262、IEC 61508和MISRA等标准要求/建议/提议对程序序列进行逻辑监控。

程序序列执行监控机制

程序执行序列的逻辑监控能够在应用程序无错误执行期间检测到导致程序序列偏离有效路径的错误。如果一条或多条程序指令以错误的顺序执行或甚至根本没有执行，就会发生错误的程序流程。

看门狗管理器负责监控应用软件执行。逻辑监控单元被称为受监控实体。每个受监控实体有一个或多个检查点。受监控实体的检查点及其之间的转换构成了一个Graph。

一个Graph可以有一个或多个初始检查点和一个或多个最终检查点。假设检查点属于同一个Graph，则从任何初始检查点开始并以任何最终检查点结束的任何序列都是正确的。

受监控实体内的Graph被称为Internal Graph。来自不同受监控实体的检查点可以通过外部转换连接，形成一个External Graph。

While循环的抽象控制流图

在运行时，看门狗管理器会验证受监控实体是否按照配置的图表执行。这被称为逻辑监控。此外，看门狗管理器还可以验证图表内检查点和转换的时机。可以通过截止时间监控来验证检查点之间转换的时机，而逻辑监控则验证检查点的正确顺序。

与时间监控中看门狗机制一样，会根据每个受监控实体的本地监督状态和全局监督状态，看门狗管理器会启动一系列机制来从监督故障中恢复。这些机制的范围从受监控实体内的局部错误恢复到ECU的全局重置。

05 E2E保护

在分布式系统中，如果发送方与接收方之间的数据交换的安全性行为依赖于数据的完整性，那么这种数据交换可能会影响功能安全（见本章开头“信息交换”故障示例）。因此，应使用相应的机制来传输这些数据，以保护其免受通信链路中故障的影响

故障模型

根据ISO 26262标准，对于在不同软件分区或ECU中执行的每个发送者或每个接收者软件组件，可以考虑以下与信息交换相关的故障：

1. 信息重复：信息被重复发送。

2. 信息丢失：信息在传输过程中丢失。

3. 信息延迟：信息传输存在延迟。

4. 信息插入：在传输过程中插入了额外的信息。

5. 信息伪装或地址错误：信息被错误地标记或发送到了错误的地址。

6. 信息顺序错误：信息的发送顺序不正确。

7. 信息损坏：信息在传输过程中被损坏。

8. 发送者对多个接收者的信息不对称：同一发送者向多个接收者发送的信息不一致。

9. 部分接收者未收到信息：只有部分接收者收到了来自发送者的信息。

10. 通信通道阻塞：通信通道被阻塞，导致信息无法传输。

这些故障类型涵盖了信息交换过程中可能出现的各种问题。

端到端（End-2-End，E2E）保护的概念假设，与安全相关的数据交换在运行时应当受到保护，以防止通信链路内部故障的影响，参考下图。

E2E保护

此类故障的例子包括随机硬件故障（例如，CAN收发器的寄存器损坏）、干扰（例如，由于电磁兼容性（EMC）问题）以及实现VFB通信的软件内部的系统性故障（例如，运行时异常（RTE）、输入输出通信（IOC）、通信故障（COM）和网络堆栈）等，这些故障可能发生在ECU内部或外部（例如网关上）

E2E的应用与实现

从软件组件的角度看： 通过RTE进行的数据传输看起来就像简单的点对点连接。然而，要实现这种抽象，需要构建由软件层、通信协议栈、驱动程序和底层硬件组成的高度复杂的基础设施。随着复杂性的增加，潜在故障源的数量也随之增多。

端到端保护机制的应用： 该机制假设在通信过程中必须保持安全相关数据的完整性，以保护数据免受通信链路内部故障的影响。端到端保护最重要的方面是保护能力的标准化和机制的灵活适用性。

端到端保护的架构实现如下： 在发送端，由应用程序数据组成的数据元素会附加额外的控制信息（即端到端报头）进行扩展。控制信息通常包含校验和、计数器和其他选项。扩展后的数据元素被提供给RTE进行传输，参考下图：

该图展示了E2E的原理，但并未展示实现所需的所有细节.为了简化说明，省略了使用RTE数据转换器对复杂数据元素进行编码/解码的部分。

在接收端，通过对E2E报头的内容与应用程序数据进行比对来验证数据元素。在接收到的数据元素被处理并确认无误后，控制信息将被移除，应用程序数据将被提供给目标软件组件。错误处理在接收端进行。

06 小 结

CP提供时间监控、逻辑监督和E2E保护等机制（还有内存分区，比较容易理解，此处不多做介绍），以确保汽车电子系统的安全性和可靠性。时间监控通过看门狗管理器实现，采用存活监督和期限监督方式，检测到错误时会采取错误处理策略。逻辑监督用于检查软件是否按照正确的逻辑顺序执行，侧重于控制流错误。E2E保护负责提供应用数据在ECU之间传输过程中的保护，确保数据传输的完整性、可靠性和安全性，支持多种帧保护协议。这些机制共同提升了汽车电子系统的安全性和可靠性。