AUTOSAR支持的四种功能安全机制（General）

本文主要阐述AUTOSAR支持的四种功能安全机制：

• 内存分区（Memory Partitioning）
• 时间监控（Timing Monitoring）
• 逻辑监督（Logical Supervision）
• 端到端保护（End-2-End Protection）

1.内存分区

内存分区的功能是操作系统和RTE功能的一部分，这是让一组SW-C在单独的内存分区中运行，以提供软件组件之间不受干扰。防止对内存存储数据或代码段的错误访问和篡改，限制对内存和内存映射的硬件外设的访问。

1.1应用程序

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

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

AUTOSAR架构下，分区以OS-Application为对象划分，属于一个OS-Application内的任务Task可以互相访问。

一个OS-Application包括多个任务Task，软件组件SW-C的实现由一组可运行实体Runnable组成，即Runnables是由可运行调用的C函数组成。

Runnables不能由它们自己执行，它们必须分配给 OS的可执行实体。可以通过将Runnables的函数调用插入OS任务主体来执行此类分配。Runnables在其调用者OS-Task的上下文中被循环执行和/或以事件作为触发。

下图展示了OS-Application、Task、Runnable、SW-C之间的关系。

1.2 OS-Applications

AUTOSAR 操作系统将OS-Application放入独立的内存区域，由操作系统实现不同应用免受内存故障干扰，这种机制称为内存分区。由于在一个OS-Application的内存分区中执行的代码不能修改其他内存区域，因此OS-Application之间相互保护。

具有不同 ASIL等级的软件组件不应分配给同一个 OS-Application。操作系统只是防止其他 OS-Application进行不适当的访问。一个有问题的软件组件不会被阻止修改同一 OS-Application中其他软件组件的内存区域。同一软件组件不能分配到不同的OS-Application中。

1.3通信和代码共享

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

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

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

1.4应用软件中的内存分区

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

AUTOSAR OS通过将 OS-Applications放入独占的内存区域，从而不受与内存相关的故障的干扰。此机制称为内存分区。OS-Applications之间彼此受到保护，因为在一个 OS-Applications的内存分区中执行的代码不能修改其他内存区域。AUTOSAR OS规范中的相应要求如表1所示。
要求ID要求文本[SWS_Os_00207]OS模块应阻止对 OS的写入访问来自其他不受信的OS-Applications的应用程序的私有数据分区。[SWS_Os_00355]OS模块应阻止从其他不受信的 OS-Applications对 OS-Applications的任务/2类ISR的所有私有堆栈进行写入访问。[SWS_Os_00356]OS模块应阻止从其他不受信的 OS-Applications对 OS-Applications的任务/2类ISR的所有私有数据分区进行写入访问。
表1：AUTOSAR OS- OS-Applications的内存分区

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

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

1.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实现都支持任务级内存分区。
要求ID要求文本[SWS_Os_00208]OS模块可能会阻止从同一 OS-Applications中的所有其他任务/ISR写入对非受信任应用程序的任务/2类ISR的专用堆栈的写入访问。[SWS_Os_00195]OS模块可能会阻止从同一 OS-Applications中的所有其他任务/ISR写入对非受信任应用程序的任务/2类ISR的私有数据分区的写入访问。
表2：AUTOSAR OS要求–任务级的内存分区

1.6内存分区的实现

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

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

内存分区的实现方案是通过CPU的supervisor/ user mode进行分区，基础应用任务运行于supervisor mode，普通应用任务运行于user mode。

所有基础软件模块都在一个受信任/监控模式内存分区中执行（图8中以红色突出显示）。

某些SWC在逻辑上分组并放在单独的非受信任/用户模式内存分区中（以绿色突出显示）。

选定的软件组件属于与基本软件模块相同的受信任/监督者模式内存分区（见图8中第四个SW-C以红色突出显示）。可能有几个非信任/用户模式分区，每个分区包含一个或多个软件组件。

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

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

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

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

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

下表和用例说明了内存保护单元的配置派生自系统要求时的一组可能方案。注意：对于正在使用的特定硬件设备的功能，此表可能不完整。
地址空间理由读写执行闪存读取、执行和写入访问不会修改闪存内容。必须首先擦除闪存，并启用其他机制才能写入。注意：从安全角度来看，以下含义：读取和执行外来代码可能用于获取原本不适用于软件的信息。OOORAM对RAM的写入访问可能会导致内存损坏，从而影响软件的行为。OXO外设即使从外设地址空间读取，也可能产生副作用。例如通过对中断控制器的读取访问来执行中断确认，对外围设备的读取访问可能会导致I/O错误。XXX
表3：内存保护的配置方案

图标说明：

X–需要保护

O–可选保护

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

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

• 同一分区中的 SWC可以访问彼此的RAM区域，因此可能会损坏彼此的内存内容。
• 根据定义， SWC无法访问外围设备，因为它们不应了解底层微控制器架构。当 SWC被允许直接访问外围设备时，可能会创建不安全的系统。 用例2：不同分区中的 SWC。
• 不同分区中的 SWC无法访问彼此的RAM区域，因此无法损坏彼此的内存内容。
• 根据定义， SWC无法访问外围设备，因为它们不应了解底层微控制器架构。当 SWC被授予对外围设备的直接访问权限时，可能会创建可能不安全的系统。 用例3：MCAL驱动程序
• MCAL驱动程序是函数的集合，例如读/写/初始化。它们必须由另一个实体执行，例如BSW或CDD。有关详细信息，请参见图8。
• MCAL驱动程序需要对相应外设硬件模块的外设空间进行读/写访问。根据硬件架构，可能还需要处理器的监控模式。

检测和响应

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

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

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

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

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

限制

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

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

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

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

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

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

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

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

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

1. 无基础软件分区。

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

2.时间监控

为避免软件组件之间出现的执行阻塞、死锁、活锁、执行时间的不正确分配、软件元素之间的不同步，需要对软件的运行时间进行监控，以确定软件运行的正确时序。

2.1监控实体

受监督的软件实体可以是软件组件、基础软件模块或CDD中的一个SW-C或Runnable。受监督实体中的重要位置被定义为checkpoint。受监督实体的代码与看门狗管理器的函数调用交错在一起。这些调用用于向看门狗管理器报告达到了一个checkpoint。

2.2看门狗管理

看门狗管理器实现两种监督方式：Alive supervision和Deadline supervision。

Alive Supervision: 周期检查被监督实体的checkpoint是否在给定的范围内到达。这意味着看门狗管理器检查被监督实体的运行频率是否过高或过低。

Deadline Supervision：

非周期性或偶发性的被监督实体对两个checkpoint之间的时间有单独的约束。通过Deadline Supervision，看门狗管理器检查被监督实体的两个checkpoint之间的转换时间。这意味着看门狗管理器检查被监督实体的某些步骤所需时间是否在配置的最小和最大范围内。

错误处理策略：

当检测到错误时，看门狗管理器将启动以下错误处理策略的一种：

1. 被监督实体内的错误处理：如果被监督实体是SW-C或CDD，看门狗管理器可以通过RTE模式机制通知被监督实体监督失败的情况，然后，被监督实体可以采取其行动从该故障中恢复。
2. 分区关闭：如果看门狗管理模块检测到位于非信任分区的被监督实体的监督失败，看门狗管理模块可以通过调用BswM请求分区关闭。
3. 由硬件看门狗复位：看门狗管理器向看门狗接口指示看门狗接口何时应不再触发硬件看门狗。在硬件看门狗超时后，硬件看门狗对ECU或MCU进行复位。这将导致ECU和/或MCU硬件的重新初始化和软件的完全重新初始化
4. 立即MCU复位：如果有必要对监控故障做出立即的、全局的反应，看门狗管理器可以直接导致MCU复位。这将导致MCU硬件和整个软件的重新初始化。通常情况下，MCU复位不会重新初始化ECU的其他硬件。

2.3操作系统时间保护

According to the AUTOSAR OS Specification, a timing fault in a real-time system occurs when a task or interrupt misses its deadline at runtime.
The AUTOSAR OS does not offer deadline supervision for timing protection.
Deadline supervision is insufficient to correctly identify the Task or Interrupt causing a timing fault in an AUTOSAR system. A deadline violation may be caused by
unrelated Tasks or Interrupts interfering with the execution. Please consult the AUTOSAR OS Specification23 for further details.
Whether a task or interrupt meets its deadline in a fixed priority preemptive operating system like AUTOSAR OS is determined by the following factors:
 The execution time of Task/Interrupt in the system.
 The blocking time that Task/Interrupt suffers from lower priority Tasks/Interrupts locking shared resources or disabling interrupts.
 The inter-arrival rate of Task/Interrupt in the system.
For safe and accurate timing protection it is necessary for the operating system to control these factors at runtime to ensure that Tasks/Interrupts can meet their respective deadlines. The AUTOSAR OS provides the following timing protection
mechanisms:

1. Execution Time Protection. An upper bound for execution time of Tasks or Cat2 Interrupts, the so called Execution Budget, is monitored via the OS to prevent timing errors.
2. Locking Time Protection. An upper bound for blocking of resources, locking and suspending of interrupts, the so called Lock Budget, is monitored by the OS.
3. Inter-Arrival Time Protection. A lower bound between tasks being activated or Cat 2 Interrupts arriving, a so called Time Frame, is monitored via the OS to prevent timing errors.
   Note: Execution time enforcement requires hardware support, e.g. a timing enforcement interrupt. If an interrupt is used to implement the time enforcement, the priority of this interrupt shall be high enough to “interrupt” the supervised tasks or interrupts.

3.逻辑监督

逻辑监督用于检查软件是否按照正确的逻辑顺序执行。如果一条或多条程序指令以不正确的顺序被处理，或者甚至根本没有被处理，就会发生不正确的控制流。例如，控制流错误会导致数据不一致、数据损坏或其他软件故障。程序序列的逻辑监测是ISO26262、IEC61508、MISRA所要求或建议提出。

与时间监控一样，受监督的软件实体可以是软件组件、基础软件模块或CDD中的一个SW-C或Runnable。逻辑监督同样基于checkpoint进行检查，每个被监督实体都有一个或多个checkpoint。一个被监督实体的checkpoint之间的转换形成一个图。

一个图可以有一个或多个初始checkpoint和一个或多个最终checkpoint。假设checkpoint属于同一个图，那么从任何初始checkpoint开始到任何最终checkpoint结束的任何顺序都是正确的。

错误处理策略：

逻辑监督的故障处理策略与时间监控的处理策略一致。

4.端到端保护

End-to-End Communication Protection Library 端到端通信保护库，保证发送端和接收端之间的Safety data element数据传输过程中的完整性、连续性及加密性。

通信失效类型主要包含以下几种：

1. 信号重复： 接收端接收到信息超过一次；
2. 信号丢失： 在发送端发送的信息流中全部或部分信息丢失；
3. 信号延迟： 在预期时间内没有收到信号；
4. 额外信号插入： 额外的信息被插入到了发送端发送的信息流中；
5. 伪造信号： 未认证的信息被接收端当作已认证的信息接收；
6. 信号地址错误：一种通道故障， 表征信息被错误的发送端发送或被错误的接收端接收；
7. 信号顺序错误： 在一串发送信息流中，信息的顺序被修改；
8. 信号损坏： 信息被改变；
9. 信号接收不对称： 不同接收端从同一发送端接收到不同的信息；
10. 部分接收端未收到期望信号： 数个接收端中，只有部分接收到信息；
11. 信号通道阻塞： 访问通信通道受阻。

这些故障类型存在于一个ECU内部的不同软件组件、OS-Application，也存在于不同ECU硬件之间。

实现端到端保护的方法是在通信协议中，数据发送方增加端到端控制信息，控制信息通常包含一个校验和、一个计数器和其他选项。扩展后的数据元素被提供给RTE进行传输。

数据元素在接收方通过处理端到端控制信息的内容与应用数据进行验证。在收到的数据元素被处理并接受为正确后，控制信息被删除，应用数据被提供给目标软件组件，错误处理是在接收方进行的。

4.1 E2E Profiles

端到端的数据保护机制包括：

CRC

完整性

由CRC Library提供

Counter

连续性

每次发送请求时加1，接收端检查是否正确增加

DataID

加密性

参与CRC校验

上图为Profile1 E2E机制与可以检测出的错误。

AUTOSAR CP目前支持以下几种Profile：
序号****Profile112234455667711822

4.2 E2E状态机

AUTOSAR 4.2.1 版还引入了一个状态机，帮助确定所收到的应用数据是否可以接受，并且更加详细。通信状态机用于接收方接收到正确数据、错误数据以及可恢复、不可恢复的状态转换。

4.3 E2E Lib集成

E2E以软件库的方式提供，可以有不同的解决方案。

它们可能取决于RTE、COM或其他基本软件模块的完整性、ASIL功能安全等级，以及其他SW/HW机制的使用（例如：内存分区）。

E2E Lib可用的集中调用场景如下图所示，接口有保护和检测两种。

4.4 E2E保护封装（Protection Wrapper）

用户在SW-Cs进行了一层封装

SW-Cs调用E2E Protect Wrapper函数

E2E Protect Wrapper函数再调用E2E Lib和RTE接口函数

4.5 E2E发送管理者（Transmission Manager）

发送端选取一个SW-C作为发送管理者，收集被保护数据集合，调用一次或多次E2E Lib，完成保护Header添加处理，最后调用发送接口发送出去。

4.6 COM E2E回调（Callout）

以I-PDU为单位，通过在COM模块回调函数中添加E2E保护和检测接口，实现对被保护数据I-PDU的处理。

4.7 RTE数据序列化和反序列化（Data Transformer）

RTE层处理E2E数据的序列化（发送端保护）和反序列化（接收端检测）处理。

错误处理策略：

端到端通信保护功能在 AUTOSAR 4.0 中作为标准库实现。这个库提供了End-2-End通信保护机制，使发送方能够在传输前保护数据，接收方能够在运行时检测和处理通信链路中的错误。当接收方检测到通信错误后，将向应用提供错误类型，数据处理方式（丢弃/使用上周期/重启）。

可以仅通过E2E Profile状态，也可结合E2E状态机来判断数据的可用性。

总结

下图为AUTOSAR功能安全机制的系列规范引用：

以上是AUTOSAR架构提供的四种功能安全机制，用于在内存保护、软件执行的时间和逻辑顺序、数据交互需要考虑的安全机制，这些内容更多是规范性方面的要求，不涉及具体的实现方法，例如时间和顺序监控中，看门狗的checkpoint应该设置多少个，监督检测到错误应该采用何种处理，由各厂商在遵循AUTOSAR框架下去具体实现，为保证互通性，AUTOSAR仅提供统一的外部调用接口。

这些安全措施作为ISO26262中的通用性安全要求，应予以遵循，但AUTOSAR没有从系统层进行结构化的安全分析，这些安全要求并不完备，也没有ASIL等级，还应结合具体的相关项定义进行补充和规定。

从应用方角度来看，安全功能的设计实现不是应用方所关注的，已在AUTOSAR架构中予以实现，应用只要实现对这些功能进行参数配置，按照给定手册中的要求进行调用即可，简化了安全功能的实现过程，另一方面来说，由于对接口做了封装，也了解不到具体的实现细节。

3.4 Functional Safety Measures not delivered by AUTOSAR
Not all functional safety measures, which may be required for the development of
safety-relevant applications, are delivered by AUTOSAR. Therefore the implementers
of safety-relevant applications must ensure that the safety development life cycle is
adequate.
As an example, the following functional safety measures are neither enforced nor
delivered by AUTOSAR. This list does not imply completeness.
 The AUTOSAR specification does not define Safety Elements out of Context
(SEooC) as described in ISO26262 Part 10, Chapter 9.
 The AUTOSAR Specification does not define the use of systematic and structured
techniques for system examination, risk analysis and management, such as
Hazard Analysis (HARA) and Hazard & Operability Analysis (HAZOP).
 No overall safety concept.
 No ASIL identification
 No dependent failure analysis is performed.
 No AUTOSAR safety case
 No confirmation measures
 No functional safety audits
 No conformance test
 Implementation techniques of Software Components such as low complexity,
robustness, defensive programming, conventions, coding rules.
 Tracing of AUTOSAR features to Software Component implementation.
 Software integration testing
 Validation and Verification against the AUTOSAR specification.
 Defect reporting, tracking, resolution with regard to implementation.

除此以外，硬件层面还提供了一些功能安全机制，主要为硬件诊断功能。

本文主要内容来自于AUTOSAR官方文档《Overview of Functional Safety Measures in AUTOSAR》CP R20-11，如有疏漏，以原文为准。