从软件层面可以分为下面四组来实现

• 内存

• 时间

• 执行

• 数据交换

1. 内存分区

对于内存方面的错误一般可以有下面几种情况。

• 数据内容

• 读写权限

• 数据一致性

• 栈使用

在功能安全机制中，是如何处理的呢。memory partitioning 是限制对内存的访问，和内存映射硬件的访问来保护的。

内存分区就意味着操作系统的应用程序可能是互相隔离开，互相受到保护的。在一个区域的代码，不应该也不可以去访问别的内存区域的信息。更无法去修改。

对ram，外设内存，flash，等设置了权限。可以区分为user mode 和 supervisor mode. 对CPU 指令的使用以及对外设的使用都添加了限制。

诸如上面的叙述，来保证内存分区对内存的保护。进而达到功能安全内存方面软件层面的实现。下面我们来详细聊一下 how and why.

1.1 Application Software

从上一节可以知道，限制的是软件使用过程中对内存的使用，那么是什么来使用内存呢，当然是软件本身的应用代码，所以这里不得不说一下Application Software 也就是我们所谓的SWC。因为使用内存的东西，就是SWC 里面的runnable.

在autosar架构中，SWC 是独立于硬件的，被集成在RTE 之上，且相互独立的软件模块。SWC 中包含了很多data, functions. SWC 中的function 也就是runnable 是需要被RTE 进行“调度的”否则就是静态代码，没有用途。这里可以是周期的，也可以是event类型的，方式方法很多，取决于设计者如何去设计。

这里看SWC 好像也没什么用，没错在代码层面SWC 确实没什么用。代码层面有用的就是内部的runnable 和 调用的interface 以及 所归属的task 去调度。那么这里就需要捋清楚他们的关系

• SWC

• runnable

• task

• OS-Application

可以抽象的理解runnable 为最小可以执行的单元，并且可以分配到不同的task。Task 是独立被调度的单元。OS-Application是整个环境的集合体。SWC 只是设计层面的概念。

既然大家明白了上面各个elements 的关系与区别。回归到内存保护的主题。

1.2. OS-Application

Os-aplication 是autosar os 操作系统对象的集合体，可以包括 任务，中断，调度表，counter和alarm 以及上面说到的SWC。可以理解这一个小的生态的资源，权限是可以互相访问的，是一个小圈子。所以在实现的角度可以通过设置OS-Application的访问来做到对内存的保护。

OS-Application 就可以分为下面两种。

• Trusted OS-Applications

在这里面的element 他们可以不受限制的访问内存和操作OS 的API， 这个区域的程序可以关闭监控，以及保护功能。并且当OS 允许的情况下，这里面的element 可以使用特权模式。也就是上面提到的supervisor mode.

• Non-Trusted OS-Application

这里就稍微憋屈一点，无法关闭监控以及保护功能。无法访问Trusted OS-Application的资源。限制使用系统API。等等。

但是这只是软件层面的约束，后面会从内存物理的角度来进行约束。不过这就需要芯片本身有MPU模块。

1.3 Application Software 中的内存分区

ISO26262 中针对不同的模块有着不同的要求，可以允许一个软件中有不同的功能安全等级的SWC 存在，所以这里也就会产生一些约束。下面提炼出来三点需求。

粗犷点理解就是 不要让non-trusted OS-Application 来有意无意的访问，破坏，甚至阅读 受保护的区域。

1.4 SWC 中的内存分区

上面的概念落地的实际，就是要保护好SWC 里面的runnable, 也就是要保护好SWC。

通过上面的解释SWC 存在于概念的设计，这里设计的过程就不应该把一个SWC 的内容架构到不同的OS-Application 里面。因为SWC 内部是可以通讯的。如果放在不同的SO-Application 那么可能就会出现non-trust 来访问trust的空间了。如下图。

但是如果一个SWC 里面的不同runnable 确实有比较重要的，也有不重要的，这就出现使用OS-Application 来区分不是那么容易。这里可以使用不同的task 来互相限制。

在任务层面的内存分区可以总结下面两条需求

也就是说在相同的OS-Application 中其他的任务，中断，也不能拥有写权限。

1.5 内存分区的实现

在实际的实现中，所有的BSW 部分都会被当作trust 区域，有supervisor权限的区域。所以可以说对于内存的保护，实际上是针对应用层软件的，也就是上面说到的SWC。这里给出一张图。

从上图的左边可以看出来，有一些SWC 是放在non-trusted 空间的，拥有的只是User Mode的权限。右边和下面的BSW 是属于supervisor 权限的代码。在图的右边 才是实际的内存分配情况。按照实际的物理地址进行了分离。当然这就需要MPU 的支持。下面假设控制器支持MPU。

下面给出了三种内存的一些需求

X – Protection is needed

O – Protection is optional

显然最主要的还就是运行过程中的ram写权限，和外设的操作权限。

所以下面也会有对象三个user case

• SWC 在同一个Partition

– SWC 在同一个partition 是有权限去访问别的SWC 的ram 空间的。

– 当SWC 被定义为无法直接访问系统外设的时候，如果去访问了，这时候操作系统会报相关的错误

• SWC 在不同的partition

– SWC 不可以，不应该去直接访问别的partition 里面的ram 空间数据。

• Mcal Drivers

– Mcal 驱动如上图所示，有读写访问，执行的权限。可以操作外设寄存器，属于supervisor权限。

2. 时间监控

对于时间监控一般会从下面几个方面入手。

• Blocking of execution

• Deadlocks

• Livelocks

• Incorrect allocation of execution

• Incorrect synchronization between software element

时间保护和监控可以通过下面几个属性来进行描述。

• 任务的调度周期，特定的事件

• 系统负载

• 任务的执行时间长短

• 中断的处理

对于时间的监控，一般有两个方法，一个是通过OS 本身，另外一个就是通过看门狗来实现。这里我们先说一下autosar中的看门狗 WDGM

2.1 看门狗

直接抄一下别人的代码的设计。方便下面的阅读。WDGM 主函数

在autosar 架构中，定义了标准的模块，Watchdog Manager. 这里面维护的是监控实体。也就是Supervised Entities。

监控实体本身和SWC， CDD 以及BSW 模块没有关系，是开发人员把这些实体放在需要监控的位置，也可以叫做checkpoint。相当于在需要的地方进行打卡，然后WDGM 统一维护所有的打卡记录。然后针对打卡记录进行判断是否符合设计时候的定义。

2.1.1 Alive Supervision

监控任务，SWC 是否还在运行的checkpoint. 比如说10ms 运行一次的SWC, 看看是不是运行的准确？是不是快了，或者慢了，或者被不运行了。一般来说这种监控会使用在周期的运行中，

不过这种也会有很多的弊端，比如一个SWC1 被发现运行不到了，实际上很大情况不是这个SWC1 的问题，而是前面的SWC 或者是任务 不行了。这里也不重要了，各有利弊的监控手段。

2.1.2 Deadline Supervision

这里面就需要两个checkpoint. 一个开始，一个结束，概念很好理解。当然这个就可以用在周期的和非周期的。主要是看SWC 是否有进有出。中间没有卡顿，或者说被抢占回不来了的情况。

2.2 操作系统的时间保护

这里面可以通过操作系统的配置。之前的文章说到过了操作系统分为

SC1,SC2,SC3,SC4 这里当SC3 级别的操作系统是可以进行时间保护功能的。可以对每一个任务进行时间执行的配置。

具体的机制如下

• 执行时间保护。通过操作系统监控任务或Cat2中断的执行时间上限，即所谓的执行预算，以防止定时错误。

• 锁定时间保护。阻塞资源、锁定中断和挂起中断的上限，即所谓的锁预算，由操作系统监控。

• 到达时间保护。被激活的任务或到达的Cat 2中断之间的下限，即所谓的时间框架，通过操作系统监控以防止计时错误。

3 逻辑监控

逻辑监控简单的来说就是增加了很多个有定义顺序的checkpoint点来进行监控。很早以前叫做PFC - program flow control。

它可以监控出下面几种错误

• Blocking of execution

• Deadlocks

• Livelocks

• Incorrect allocation of execution time

• Incorrect synchronization between software elements

在watchdog 里面配置很多个checkpoints， 在代码中不同的地方加入。达到下图的效果，经过每一个打卡点， WDGM 都会进行判断。

上述所有的checkpoint 都是下面描述的过程，就没必要一一介绍了。