AUTOSAR功能安全机制之:内存分区与实现、时序监控

来源：汽车电子与软件 作者：杨玉柱

（一）内存分区与实现

1. 应用软件

在AUTOSAR架构中，应用软件位于RTE上方，由互连的AUTOSAR SWC组成，这些组件以原子方式封装了应用软件功能的各个组成部分。

AUTOSAR SWC独立于硬件，因此可以集成到任何可用的ECU硬件上。为了便于ECU内部和内部的信息交换，AUTOSAR SWC仅通过RTE进行通信。

AUTOSAR SWC包含许多提供内部功能的函数和变量。AUTOSAR SWC的内部结构，即其变量和函数调用，通过头文件隐藏在公众视野之外。只有外部RTE调用才会在公共接口上生效。

AUTOSAR SWC还包含必须在运行时调用的函数。这些C函数在AUTOSAR中称为Runnables。

Runnables不能由它们自己执行;它们必须分配给 OS的可执行实体。可以通过将Runnables的函数调用插入OS任务主体来执行此类分配。

然后，Runnables在调用方OS-Task的上下文中循环执行和/或事件驱动。Runnables对任务的分配是根据图3和图4执行的。

2. OS-Applications

图4显示了对图3中关系的解释。根据此图，AUTOSAR SWC中的Runnables被分配给 OS任务。

AUTOSAR OS-Applications是 OS对象（如任务、ISR、调度表、计数器和警报）的集合，它们构成了一个内聚的功能单元。属于同一 OS-Applications的所有对象都可以相互访问。

OS-Applications中的 OS对象可能属于不同的AUTOSAR SWC。RTE实现了一个内存区域， OS-Applications的所有成员都可以不受限制地访问该区域，以方便SWC之间有效地进行通信。

OS-Applications有两类：

1. 受信任的 OS-Applications：“允许受信任的 OS-Applications在运行时禁用监控或保护功能的情况下运行。他们可能不受限地访问内存和 OS模块的API。受信任的 OS-Applications不需要在运行时强制执行其时序行为。当处理器支持时，它们被允许在特权模式下运行。
2. 不受信的 OS-Applications：“不允许在运行时禁用监控或保护功能的情况下运行不受信的 OS-Applications。它们限制了对内存的访问，限制了对 OS模块的API的访问，并在运行时强制执行其时序行为。当处理器支持时，不允许它们在特权模式下运行。

3. 通信和代码共享

根据图4和图3，一个 OS-Applications可以包含多个AUTOSAR SWC和关联的Runnables。仅允许Runnables直接访问变量并在其各自的 SWC中执行函数调用。

SWC的内部函数调用和变量不被其他 SWC公开获取，因为它们的定义不由外部接口的头文件提供，因此不能规划通过变量直接通信并执行其他 SWC的代码。

在图5中，代码共享示例对此进行了说明，代码共享只允许在 SWC内使用，而不允许在一个OS-Application的 SWC之间共享。与其他 SWC的通信应通过RTE执行。Runnable4可能无法执行属于SWC2.2的功能。

4. 应用软件中的内存分区

AUTOSAR ECU中的应用软件可以由与安全相关的 SWC和非安全相关的 SWC组成。应根据ISO26262的要求，确保具有不同ASIL等级的 SWC之间的免干扰性。

AUTOSAR OS通过将 OS-Applications放入独占的内存区域，从而不受与内存相关的故障的干扰。此机制称为内存分区。OS-Applications之间彼此受到保护，因为在一个 OS-Applications的内存分区中执行的代码不能修改其他内存区域。AUTOSAR OS规范中的相应要求如表1所示。

应用程序软件可以由具有不同ASIL等级的 SWC组成。但是，具有不同ASIL分级的 SWC不应分配给同一个 OS-Applications。内存分区不能提供分配给同一 OS-Applications的 SWC之间的免干扰性。OS仅阻止其他 OS-Applications执行不正确的访问。不会阻止有故障的 SWC修改同一 OS-Applications中其他SWC的内存区域。

注意：有关任务级分区的详细信息，请参阅后续分区。

5. SWC中的内存分区

混合ASIL SWC可能由具有不同ASIL评级的Runnable组成，因此需要一个支持不受这些Runnable之间干扰的执行环境。由于以下原因，无法在不同的内存分区中执行一个 SWC的不同Runnables：

内存分区在 OS-Applications级别执行。如图所示图3和图4，一个 SWC只能分配给一个OS-Applications，因此只有一个内存分区。此外， SWC的Runnables只能由一个 OS-Applications的任务调用。

如图6所示， SWC的Runnables不能分发到多个 OS-Applications的任务。

内存分区不能用于分隔同一SWC中的Runnables。如果有必要让 SWC包含具有不同ASIL的Runnable，并且这些Runnable需要免干扰的独立执行，那么在 OS-Applications级进行内存分区是不够的，内存分区必须在任务级别执行。方法如图7所示。

与任务级别的内存分区相关的要求列在表2的AUTOSAR OS规范中。使用弱词“may”表明任务级分区的实现对于AUTOSAR OS是可选的。因此，并非每个AUTOSAR OS实现都支持任务级内存分区。

6. 内存分区的实现

可以使用内存分区机制在系统和软件级别上实现各种技术安全概念。

图8显示了一个可能的实现，而所有基础软件模块都在一个受信任/监控模式内存分区中执行（图8中以红色突出显示）。某些SWC在逻辑上分组并放在单独的非受信任/用户模式内存分区中（以绿色突出显示）。选定的软件模块与基础软件模块属于同一可信/管理模式内存分区（参见图8中红色高亮的第四个SWC）。可能有多个不受信的/用户模式分区，每个分区包含一个或多个SWC。

在非受信任/用户模式内存分区中执行SWCs会受到限制，不能修改其他内存区域，而受信任/监控程序内存分区的SWCs的执行不受限制。

用于安全相关应用的现代微控制器支持通过专用硬件（内存保护单元（MPU））进行内存分区。

注意：假设内存分片将在具有MPU或类似硬件功能的微控制器上实现。

使用典型的MPU实现，不受信的应用程序可以允许访问微控制器地址空间的多个分区。访问控制定义为读取、写入和执行访问的组合。MPU的配置仅在监控模式下是允许的。

注意：在某些微控制器实现中，MPU集成在处理器内核中。因此，MPU仅控制关联内核的访问。其他总线主站（如DMA控制器和其他内核）不受此分段MPU实例的控制。

下表和用例说明了内存保护单元的配置派生自系统要求时的一组可能方案。注意：对于正在使用的特定硬件设备的功能，此表可能不完整。

图标说明：

X–需要保护

O–可选保护

注意：从性能角度来看，由于总线争用、接口仲裁等原因，可能会产生副作用。

用例1：SWC位于同一分区中。

• 同一分区中的 SWC可以访问彼此的RAM区域，因此可能会损坏彼此的内存内容。
• 根据定义， SWC无法访问外围设备，因为它们不应了解底层微控制器架构。当 SWC被允许直接访问外围设备时，可能会创建不安全的系统。
• 
  

用例2：不同分区中的 SWC。

• 不同分区中的 SWC无法访问彼此的RAM区域，因此无法损坏彼此的内存内容。
• 根据定义， SWC无法访问外围设备，因为它们不应了解底层微控制器架构。当 SWC被授予对外围设备的直接访问权限时，可能会创建可能不安全的系统。

用例3：MCAL驱动程序

• MCAL驱动程序是函数的集合，例如读/写/初始化。它们必须由另一个实体执行，例如BSW或CDD。有关详细信息，请参见图8。
• MCAL驱动程序需要对相应外设硬件模块的外设空间进行读/写访问。根据硬件架构，可能还需要处理器的监控模式。

2.1.1 检测和响应

功能安全机制内存分区通过限制对内存和内存映射硬件的访问来提供保护。在一个分区中执行的代码不能修改另一个分区的内存。内存分区可以保护只读内存段，以及保护内存映射硬件。此外，在用户模式下执行的SWC对CPU指令的访问受到限制，例如重新配置。

内存分区机制可以在微控制器硬件（如内存保护单元或内存管理单元）的支持下实现。微控制器硬件必须由 OS进行适当配置，以便于检测和防止不正确的内存访问。然后监控在不受信的/用户模式内存分区中SWC的执行。

如果内存访问违规或非受信任/用户模式分区中的CPU指令冲突，则错误访问将被阻止，微控制器硬件会引发异常。OS和RTE通过执行分区关闭或重新启动此分区的所有软件分区来消除错误的软件分区。

注意：OS的实际响应可以通过保护挂钩实现进行配置。有关更多详细信息，请参阅 OS SWS[i]文档。

注：AUTOSAR文档“应用程序级错误处理说明”[ii]提供了有关错误处理的其他信息。在文档中，解释了如何执行错误处理以及可以从何处获取所需数据（例如替代值）。此外，本文档还提供了有关如何在AUTOSAR中执行 OS-Applications/分区终止和重新启动的详细说明（用户手册）。

2.1.2 限制

1. 具有相同ASIL分级的SWC的内存分区。

ISO26262标准要求不同ASIL等级[iii]的 SWC之间的免干扰性。但是，标准不要求在具有相同ASIL等级的 SWC之间的免干扰性。

允许使用由大量 SWC组成的 OS-Applications。如果单个 SWC导致冲突，从而导致关闭或重新启动整个内存分区，则此内存分区的所有其他正常工作的SWC也会受到影响。

2. 内存分区不适用于受信任的 OS-Applications。

受信任/监控模式内存分区的执行不受 OS和某些MMU/MPU硬件实现的控制。

3. 任务级别不支持内存分区。

任务级分区的实现对于AUTOSAR OS实现不是必需的。因此，可能不支持 OS-Applications中的免干扰性。

4. 由于内存分区导致的性能损失。

根据应用软件的架构以及微控制器硬件和 OS的实现，使用内存分区会降低性能。此损失随着每个时间单位执行的上下文切换数的增加而增加。

5. 无基础软件分区。

基础软件的当前规范未指定来自不同供应商的不同ASIL等级的基础 SWC的内存分区。

（二）时序监控

2.2 时序监控

时序是嵌入式系统的一个重要属性。安全行为要求在正确的时间内执行系统操作和响应。

正确的时间可以用一组必须满足的时序约束来描述。然而，AUTOSAR SWC本身无法确保正确的时机。这取决于AUTOSAR运行时环境和基础软件的适当支持。在集成过程中，需要确保AUTOSAR SWC的时序约束。

2.2.1 故障模式

根据ISO26262，以下与时序和执行相关的故障可被视为 SWC之间干扰的原因：

• 阻塞执行
• 死锁
• 活锁
• 执行时间分配不正确
• 软件要素之间的同步不正确

时序保护和监控可以描述为对以下属性的监控：监控任务在指时序间调度，满足执行时间预算，并且不独占OS资源。

为了保证与安全相关的功能将遵守其时序约束，应检测并处理垄断CPU的任务（例如CPU负载过重，太多中断请求）。

2.2.2 描述

AUTOSAR提供以下时序监控机制：

1. 使用 OS的时序保护机制。
2. 使用Watchdog Manager进行时序程序流监控。

本章将解释Watchdog Manager在实现应用软件时序监控方面的应用。

Watchdog Manager还引入了一种称为逻辑监控的机制，该机制可以与死线监控结合使用，以提供高诊断覆盖率。

此外，本章还将概述AUTOSAR OS的时序保护机制。

2.2.2.1 受监控实体

Watchdog Manager监控AUTOSAR ECU中应用程序软件的执行。监控的逻辑单元称为监控实体。在AUTOSAR中，受监控实体和架构构建基块之间没有固定的关系。通常，受监控实体可以表示一个SWC或SWC的一个Runnable、一个BSW模块或CDD，具体取决于开发者的选择。

受监控实体中的重要节点被定义为检查点。受监控实体的代码与Watchdog Manager的函数调用交互。这些调用用于向Watchdog Manager报告已到达检查点。

2.2.2.2 Watchdog Manager

Watchdog Manager是AUTOSAR架构的基础软件模块。Watchdog Manager将看门狗硬件的触发与软件执行的监控联系起来。当检测到对程序执行的时态和/或逻辑约束的违反时，将采取许多可配置的操作来从此故障中恢复。

Watchdog Manager为时序程序流监控提供以下机制：

活体监控：定期监控实体对执行频率有限制。通过活体监控，Watchdog Manager会定期检查受监控实体的检查点是否已达到给定限制。这意味着Watchdog Manager会检查受监控实体的运行频率是否太高或太低。

活体监控是使用单个检查点执行的，没有切换。受监控实体必须周期性地调用检查点，以发出其及时操作的信号。OS定期执行Watchdog Manager以验证检查点参数。

受监控的实体也可以通过多个活体监控实例进行监控，因此每个活体监控都包含一个独立的检查点。请参见图9。

死线监控：非周期性或周期性监控实体对两个检查点之间的时间安排有单独的限制。通过死线监控，Watchdog Manager检查受监控实体的两个检查点之间的转换时间。这意味着Watchdog Manager会检查受监控实体中的某些步骤所花费的时间是否在配置的最小值和最大值之内。请参见图10。

如果从未到达第二个检查点，则死线监控将无法检测到此问题。出现此问题的原因是，在调用第二个检查点后，Watchdog Manager将执行时序检查。

2.2.2.3 OS的时序保护

根据AUTOSAR OS规范，当任务或中断在运行时错过其死线时，就会发生实时系统中的时序故障。

AUTOSAR OS不提供时序保护的死线监控。死线监控不足以正确识别导致AUTOSAR系统中时序故障的任务或中断。违反死线可能是由不相关的任务或干扰执行的中断引起的。请咨询AUTOSAR OS规范23了解更多详情。

在固定优先级抢占式 OS（如AUTOSAR OS）中，任务或中断是否满足其死线取决于以下因素：

• 任务/中断在系统中的执行时间。
• 任务/中断遭受较低优先级的任务/中断阻塞共享资源或禁用中断的阻塞时间。
• 系统中任务/中断的到达间隔速率。

为了安全准确地提供时序保护， OS必须在运行时控制这些因素，以确保任务/中断可以满足各自的死线。AUTOSAR OS提供以下时序保护机制：

1. 执行时间保护。任务或2类中断的执行时间上限，即所谓的执行预算，通过 OS进行监控，以防止时序错误。
2. 锁定时间保护。OS监控资源阻塞、锁定和暂停中断的上限，即所谓的锁定预算。
3. 到达时间保护。正在激活的任务或2类中断到达之间的下限，即所谓的时间片，通过 OS进行监控，以防止时序错误。

注意：执行时间实施需要硬件支持，例如时序实施中断。如果使用中断来实现时间执行，则该中断的优先级应高到足以“中断”受监控的任务或中断。

2.2.3 检测与响应

Watchdog Manager为时序和逻辑程序流监控提供了三种机制：死线监控、活体监控和逻辑监控。

监控机制是静态配置的。对于受监控实体的监控，可以采用多种监控机制。

根据每个已启用机制的结果，计算受监控实体的状态（称为局部状态）。当确定每个受监控实体的状态时，然后根据每个局部监控状态，确定整个MCU的状态（称为全局监控状态）。

根据每个受监控实体的局部监控状态和全局监控状态，Watchdog Manager会启动许多机制来从监控失败中恢复。这些范围从受监控实体内的局部错误恢复到ECU的全局重置。

Watchdog Manager可以采用以下错误恢复机制：

1.受监控实体中的错误处理

如果受监控实体是SWC或CDD，则Watchdog Manager可以通过RTE模式机制通知受监控实体有关监控情况。然后，受监控实体可以采取措施从该故障中恢复。

Watchdog Manager可能会在检测到监控故障时向诊断事件管理器（DEM）注册一个条目。受监控实体可能会根据该错误条目执行恢复操作。

2.分区关闭

如果Watchdog Manager模块在位于不受信的分区中的受监控实体中检测到监控故障，则Watchdog Manager模块可以通过调用BswM请求分区关闭。

3.通过硬件看门狗重置

Watchdog Manager向看门狗接口指示看门狗接口何时不再触发硬件看门狗。在硬件看门狗超时后，硬件看门狗将重置ECU或MCU。这导致ECU和/或MCU硬件的重新初始化以及软件的完全重新初始化。

4.立即复位MCU

如果需要对监控故障立即做出全局响应，Watchdog Manager可能会直接导致MCU复位。这将导致MCU硬件和完整软件的重新初始化。通常，MCU复位不会重新初始化ECU硬件的其余分区。

注：AUTOSAR文档“应用程序级别的错误说明”提供了有关错误处理的其他信息。在文档中，解释了如何执行错误处理以及可以从何处获取所需数据（例如替代值）。此外，本文档还详细介绍了如何在AUTOSAR中执行 OS-Applications/分区终止和重新启动。

2.2.4 限制

1. 检查点的粒度不是由Watchdog Manager固定的。很少有粗制的检查点会限制Watchdog Manager的检测能力。例如，如果应用程序SWC只有一个检查点，指示循环可运行已启动，则Watchdog Manager只能检测此可运行已重新启动并消除时序约束。相反，如果该SWC在可运行的每个块和分支上都有检查点，则Watchdog Manager也可能检测到该SWC的控制流中的故障。检查点的高粒度会导致Watchdog Manager的复杂和大量配置。
2. 死线监控有一个弱点：它只检测延迟（当报告结束检查点时），但它不检测超时（当根本没有报告结束检查点时）。
3. 不支持死线监控（即开始1、开始2、结束2、结束1）的嵌套。
4. 每个受监控实体具有多个检查点的“活体监控”功能在“Watchdog Manager规范”中未一致地指定。目前，建议每个监控实体仅支持一个活体监控检查点。
5. 为了关闭或重新启动（作为错误响应）包含受监控实体的分区，集成代码（ OS-Applications的重新启动任务）通过调用Watchdog Manager的可用函数来停用（或停用+激活）受影响分区的所有受监控实体。这有点复杂，在Watchdog Manager规范文档的未来版本中被认为是Watchdog Manager的新加功能。
6. 库无法调用BSW，因此库不能由Watchdog Manager监控。但是，可以通过在模块的代码中放置库调用之前和之后的检查点来使用死线监控，以监控库实例运行。
7. 如何使用受监控实体ID标识BSW模块尚未标准化。