前言
功能安全（Functional Safety）是一项系统特性，由于基于功能安全的设计会影响到系统设计，所以从系统开发初始阶段就要进行考虑。
由于软件的复杂度会影响 到功能安全的设计，所以在AUTOSAR规范中，包含了部分与功能安全相关的需求，这些新技术和概念能够帮助降低功能安全相关组件的复杂度。
不过需要强调的是，AUTOSAR虽然通过提供安全措施和机制来支持基于功能安全产品开发，但这些独立的安全措施（Safety Measure）并不能形成整体的安全解决方案。
在功能安全标准（ISO 26262 2018, Part 6）中，提到了要避免软件相关元素之间干扰（Freedom from Interference between software elements）。软件之间的相互干扰主要集中在软件的执行时间（Timing），软件间的死锁（Dead locks，Live locks），内存使用（Memory），信息交换（Information Exchange）。
本文主要介绍一下AUTOSAR规范中对于软件内存分区的保护措施。
1 失效模式
基于组件化设计的嵌入式系统中，通常会同时包含不同ASIL等级的功能安全相关组件（包括非功能安全相关的组件）。
低ASIL等级的软件组件有可能会以错误的方式读写高ASIL等级的软件组件。如果不同的软件组件能够在不同的内存分区中执行，则可以避免产生内存访问相关的影响。
这篇文章中介绍了AUTOSAR OS和RTE的部分功能，这些功能用于支持多个SWC在不同的内存分区中执行，用于避免内存异常访问。
根据ISO 26262 Part 6，内存相关的异常访问分类如下：
内容的破坏（Corruption of Contents）
读写其它组件的分配管理的内存空间
AUTOSAR中提供的内存分区（Memory Partitioning）机制通过限制访问内存及基于内存映射的硬件（如Flash，Register）等，支持内存使用的保护。
内存分区意味着把不同的OS-Application部署于不同的内存区域，这样，特别是代码执行时，一个分区内的代码无法修改另一个分区的内存数据。而且，内存分区还可以保护只读的区域（如代码段）。
AUTOSAR的内存分区和用户/特权机制相关的特性，可以支持软件组件之间的FFI，如SWC内存相关的错误不会扩散到其它的软件组件，同时，处于用户态的SWC也无法修改或重新配置CPU内部的寄存器。
2 内存分区机制介绍
内存分区是AUTOSAR OS和RTE的一个扩展机制，这在AUTOSAR相关的规范中有描述。在这篇文章中，会以在AUTOSAR方法论中提到的Runnable，Tasks，SWC和OS-Application之间上下文关系的形式介绍这个扩展机制。
2.1 应用程序（Application Software）
在AUTOSAR架构中，应用程序位于RTE之上的，并且包含一组内部存在信息交换的软件组件（SWC），这些软件组件实现一系列的原子功能（不可拆分），组合在一起实现应用程序的功能。
AUTOSAR的SWC与硬件无关，所以这些SWC可以集成在任何ECU的硬件上。为了实现ECU内（Inter-）和ECU间（Intra-）通信，AUTOSAR SWC仅通过RTE进行通信（Exclusively）。
AUTOSAR SWC包含一系列的功能实现和变量定义，通过这些提供内部的功能实现。这些功能实现和变量定义对于外部是不可见的，仅能通过公布的RTE接口使用。
AUTOSAR SWC也提供了函数接口，但只能在运行时调用。这些C语言的函数在AUTOSAR中被叫做Runnable。Runnable不能主动执行，而是通过配置的形式，分配到某个位于
操作系统中的可执行的实体上，比如，作为一个OS-Task调用的代码段。
Runnable以周期性执行或者以外部触发的形式在OS-Task的上下文中执行。从分配的角度来看，一个SWC可以由多个Runnable构成，一个OS-Task可以触发多个Runnable（同一个SWC内的Runnable可以在不同的OS-Task上执行），一个OS-Application可以管理多个OS-Task，而OS-Application和内存分区（Partition）之间，是一对一的关系。
2.2 OS-Application
AUTOSAR的OS-Application是操作系统对象的集合体，其中包括任务 (Tasks)，中断服务程序 (ISRs)，调度表 (Schedule Tables)，计数器 (Counters)和警报 (Alarms)，这些对象构成一个内聚的功能单元。在一个OS-Application内的各个对象可以互相访问。
操作系统内的在同一个OS-Application内的对象，可以分属于不同的SWC。RTE实现了一段内存空间，为这些在同一个OS-Application内的对象相互访问，提供了不受限的通信支持。
OS-Application可以分为2类：
受信任 (Trusted)的OS-Application可以不受那些运行时的监控 (Monitoring)或者保护 (Protection)特性的限制执行。这类应用可以不受限的访问内存和操作系统API。受信任的应用对于执行时间上也不受限制，同时也可以在任何支持的处理器上以特权模式执行。
不受信任 (Non-trusted)的OS-Application不可以在运行时监控及保护机制关闭的时候执行。这类应用在访问内存、操作系统API时都有限制，同时也不允许以特权模式执行。
2.3 通信与代码共享
一个OS-Application可以包含多个SWC及相关的Runnable。Runnable只允许直接访问SWC内部的变量和函数。内部的函数调用及变量访问对于其它SWC来说是不可见的，主要原因是这些函数及变量在SWC相关的头文件中根本就没有声明。
这也说明，AUTOSAR标准并不期望从其它的SWC中直接通过变量访问及直接的执行另一个SWC内部的代码。AUTOSAR中，SWC之间，仅允许基于RTE进行组件间的通信。
2.4 应用 (Application Software)内的内存分区
基于AUTOSAR开发的ECU内部可以包含功能安全相关与功能安全无关的SWC。ISO 26262要求不同的ASIL等级的软件组件之间要避免相互干扰 (Freedom from interference)。
AUTOSAR操作系统通过将OS-Application放置于独立的内存区域内，实现避免内存相关的干扰。这个机制叫做内存分区 (Memory Partitioning)。一个OS-Application不能直接修改另一个OS-Application的内部数据，从而实现相互之间的保护。
应用软件可以包含不同等级的SWC，但这些SWC不能分配到同一个OS-Application内。内存分区无法对位于同一个OS-Application内部的SWC提供保护。
操作系统也只能阻止OS-Application间的非法访问，无法阻止一个有故障的SWC访问位于同一个OS-Application内的其它SWC的数据。
2.5 SWC内部的内存分区
可能会有一些SWC有在内部包含不同ASIL等级的Runnable的需求，这就要求避免相互干扰的机制要在这些SWC之间进行。但在Runnable的设计上来说，是属于SWC的属性，但一个SWC只能分配到一个OS-Application上，所以基于OS-Application的内存分区机制无法保障一个SWC内部的不同等级的Runnable之间相互干扰。
这个特性就需要AUTOSAR操作系统支持Task之间的内存分区，因为Runnable是在某个Task上调用执行的。（目前还不确定是否有AUTOSAR OS支持这个特性）
2.6 实现内存分区
大量的系统及软件级的TSC (Technical Safety Concept)可以使用内存分区机制来实现。
通常BSW位于受信任 (Trusted)区域，部分SWC可以和BSW一样在受信任区域，以管理 (Supervisor)权限运行。其它的内存区域可以划分为多个内存分区，每个内存分区内可以有一个或多个SWC以用户态运行。
现代的安全相关的微处理器通常都在硬件级别上支持内存分区机制，这主要是通过内存保护单元 (Memory Protection Unit, MPU)来实现的。
在一个典型的MPU实现中，不受信的应用也可以配置为访问多个内存区域。访问的方式可以是读、写、执行及这些的组件。针对MPU的配置要用管理权限。MPU的保护可以针对内存、Flash及外设进行。另外，使用内存分区的可能场景有如下几个：
SWC位于同一个内存分区中
位于同一个内存分区中的SWC可以相互访问内部数据，进而可以造成内部数据破坏；
标准定义SWC不能直接访问外设，因为处理器的架构对于SWC来说不透明。如果强行使用SWC访问外设，这会导致系统严重的安全风险；
SWC位于不同的内存分区中
位于不同内存分区的的SWC不可以相互访问内部数据，也就不能破坏其它SWC的数据了；
标准定义SWC不能直接访问外设，因为处理器的架构对于SWC来说不透明。如果强行使用SWC访问外设，这会导致系统严重的安全风险；
MCAL驱动程序
MCAL驱动是一系列函数集合，如读、写及初始化等。这类接口必须在BSW或CDD中执行；
MCAL驱动可以访问外设空间，根据不同的处理器实现，可能会需要管理权限；
3 检测与响应
内存分区的安全机制通过限制访问内存及支持内存映射的外设的方法来实现保护。一块分区内的代码，无法修改另一个分区的数据。
内存分区也支持只读方式的访问，这个可以用来保护那些基于内存映射访问的硬件。SWC也可以被限定为禁止访问CPU的寄存器，如重新配置等。
在支持MPU或MMU的硬件上使用内存分区机制，操作系统要事先进行合理的配置来检测和阻止不正确的内存访问。
一旦出现了在非受信区域的内存访问或者执行了不合法的CPU指令，这些访问首先会被阻止，然后处理器硬件会产生一个异常 (Exception)。操作系统和RTE会处理这些异常，执行内存分区的关闭 (Shutdown)，或重启分区内的所有SWC的动作。
4 限制条件
如果分区内的SWC都设置为相同的ASIL等级，则不需要按照ISO 26262中要求的FFI来设计安全机制。同时，对于OS-Application，可以包含多个SWC，但内存分区的关闭或重启机制是针对整个分区进行，所以即使状态正常的SWC也会受到影响
内存分区机制不适用于受信任的OS-Application，受信区域中的代码执行不会被保护机制监控。Task级的内存保护不是AUTOSAR的强制标准，所以OS-Application内部的FFI可能
内存分区会带来性能上的影响。由于增加了内存分区，会导致上下文的切换增多。
BSW的软件不支持内存分区，所以才会有Safe BSW的方案。
