编辑推荐: |
本文主要介绍汽车软件功能安全的4个软件层面:内存、时间、执行和数据交换,
希望对你的学习有帮助。
本文来自于
合肥工大本大
,由火龙果软件Linda编辑,推荐。 |
|
从软件层面可以分为下面四组来实现 • 内存 • 时间 • 执行 • 数据交换 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 都是下面描述的过程,就没必要一一介绍了。

|