在AUTOSAR架构中，应用软件位于RTE上方，由互连的AUTOSAR SWC组成，这些组件以原子方式封装了应用软件功能的各个组成部分。
图1：应用程序软件
AUTOSAR SWC独立于硬件，因此可以集成到任何可用的ECU硬件上。为了便于ECU内部和内部的信息交换，AUTOSAR SWC仅通过RTE进行通信。
AUTOSAR SWC包含许多提供内部功能的函数和变量。AUTOSAR SWC的内部结构，即其变量和函数调用，通过头文件隐藏在公众视野之外。只有外部RTE调用才会在公共接口上生效。
图2：SWC
AUTOSAR SWC还包含必须在运行时调用的函数。这些C函数在AUTOSAR中称为Runnables。
Runnables不能由它们自己执行;它们必须分配给 OS的可执行实体。可以通过将Runnables的函数调用插入OS任务主体来执行此类分配。
然后，Runnables在调用方OS-Task的上下文中循环执行和/或事件驱动。Runnables对任务的分配是根据图3和图4执行的。
图3：AUTOSAR分层软件架构-Runnables的映射
图4显示了对图3中关系的解释。根据此图，AUTOSAR SWC中的Runnables被分配给 OS任务。
图4：SWC到 OS-Applications的映射
AUTOSAR OS-Applications是 OS对象（如任务、ISR、调度表、计数器和警报）的集合，它们构成了一个内聚的功能单元。属于同一 OS-Applications的所有对象都可以相互访问。
OS-Applications中的 OS对象可能属于不同的AUTOSAR SWC。RTE实现了一个内存区域， OS-Applications的所有成员都可以不受限制地访问该区域，以方便SWC之间有效地进行通信。
OS-Applications有两类：
根据图4和图3，一个 OS-Applications可以包含多个AUTOSAR SWC和关联的Runnables。仅允许Runnables直接访问变量并在其各自的 SWC中执行函数调用。
SWC的内部函数调用和变量不被其他 SWC公开获取，因为它们的定义不由外部接口的头文件提供，因此不能规划通过变量直接通信并执行其他 SWC的代码。
在图5中，代码共享示例对此进行了说明，代码共享只允许在 SWC内使用，而不允许在一个OS-Application的 SWC之间共享。与其他 SWC的通信应通过RTE执行。Runnable4可能无法执行属于SWC2.2的功能。
图5：OS-Applications中的代码共享
AUTOSAR ECU中的应用软件可以由与安全相关的 SWC和非安全相关的 SWC组成。应根据ISO26262的要求，确保具有不同ASIL等级的 SWC之间的免干扰性。
AUTOSAR OS通过将 OS-Applications放入独占的内存区域，从而不受与内存相关的故障的干扰。此机制称为内存分区。OS-Applications之间彼此受到保护，因为在一个 OS-Applications的内存分区中执行的代码不能修改其他内存区域。AUTOSAR OS规范中的相应要求如表1所示。
表1：AUTOSAR OS- OS-Applications的内存分区
应用程序软件可以由具有不同ASIL等级的 SWC组成。但是，具有不同ASIL分级的 SWC不应分配给同一个 OS-Applications。内存分区不能提供分配给同一 OS-Applications的 SWC之间的免干扰性。OS仅阻止其他 OS-Applications执行不正确的访问。不会阻止有故障的 SWC修改同一 OS-Applications中其他SWC的内存区域。
注意：有关任务级分区的详细信息，请参阅后续分区。
混合ASIL SWC可能由具有不同ASIL评级的Runnable组成，因此需要一个支持不受这些Runnable之间干扰的执行环境。由于以下原因，无法在不同的内存分区中执行一个 SWC的不同Runnables：
内存分区在 OS-Applications级别执行。如图所示图3和图4，一个 SWC只能分配给一个OS-Applications，因此只有一个内存分区。此外， SWC的Runnables只能由一个 OS-Applications的任务调用。
如图6所示， SWC的Runnables不能分发到多个 OS-Applications的任务。
图6：SWC与分区
内存分区不能用于分隔同一SWC中的Runnables。如果有必要让 SWC包含具有不同ASIL的Runnable，并且这些Runnable需要免干扰的独立执行，那么在 OS-Applications级进行内存分区是不够的，内存分区必须在任务级别执行。方法如图7所示。
图7：任务级分区
与任务级别的内存分区相关的要求列在表2的AUTOSAR OS规范中。使用弱词“may”表明任务级分区的实现对于AUTOSAR OS是可选的。因此，并非每个AUTOSAR OS实现都支持任务级内存分区。
表2：AUTOSAR OS要求–任务级的内存分区
可以使用内存分区机制在系统和软件级别上实现各种技术安全概念。
图8显示了一个可能的实现，而所有基础软件模块都在一个受信任/监控模式内存分区中执行（图8中以红色突出显示）。某些SWC在逻辑上分组并放在单独的非受信任/用户模式内存分区中（以绿色突出显示）。选定的软件模块与基础软件模块属于同一可信/管理模式内存分区（参见图8中红色高亮的第四个SWC）。可能有多个不受信的/用户模式分区，每个分区包含一个或多个SWC。
在非受信任/用户模式内存分区中执行SWCs会受到限制，不能修改其他内存区域，而受信任/监控程序内存分区的SWCs的执行不受限制。
用于安全相关应用的现代微控制器支持通过专用硬件（内存保护单元（MPU））进行内存分区。
注意：假设内存分片将在具有MPU或类似硬件功能的微控制器上实现。
使用典型的MPU实现，不受信的应用程序可以允许访问微控制器地址空间的多个分区。访问控制定义为读取、写入和执行访问的组合。MPU的配置仅在监控模式下是允许的。
注意：在某些微控制器实现中，MPU集成在处理器内核中。因此，MPU仅控制关联内核的访问。其他总线主站（如DMA控制器和其他内核）不受此分段MPU实例的控制。
下表和用例说明了内存保护单元的配置派生自系统要求时的一组可能方案。注意：对于正在使用的特定硬件设备的功能，此表可能不完整。
表3：内存保护的配置方案
图标说明：
X–需要保护
O–可选保护
注意：从性能角度来看，由于总线争用、接口仲裁等原因，可能会产生副作用。
用例1：SWC位于同一分区中。
功能安全机制内存分区通过限制对内存和内存映射硬件的访问来提供保护。在一个分区中执行的代码不能修改另一个分区的内存。内存分区可以保护只读内存段，以及保护内存映射硬件。此外，在用户模式下执行的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也会受到影响。
2. 内存分区不适用于受信任的 OS-Applications。
受信任/监控模式内存分区的执行不受 OS和某些MMU/MPU硬件实现的控制。
3. 任务级别不支持内存分区。
任务级分区的实现对于AUTOSAR OS实现不是必需的。因此，可能不支持 OS-Applications中的免干扰性。
4. 由于内存分区导致的性能损失。
根据应用软件的架构以及微控制器硬件和 OS的实现，使用内存分区会降低性能。此损失随着每个时间单位执行的上下文切换数的增加而增加。
5. 无基础软件分区。
基础软件的当前规范未指定来自不同供应商的不同ASIL等级的基础 SWC的内存分区。
以上是内存分区和实现的功能安全机制的详细内容。更多信息请关注PHP中文网其他相关文章！
