AutoSar Classic Platform Os功能安全机制解析

这篇具有很好参考价值的文章主要介绍了AutoSar Classic Platform Os功能安全机制解析。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

AutoSar Classic Platform Os功能安全机制解析

前言

功能安全（Function Safety，有时也简称为FuSa）在工业控制、智能网联汽车、航空航天等安全关键领域中已经有了成熟的应用。在国内和国际，也有众多标准定义了它的思路、流程和规范。本系列文章试图以浅显的方式，为这方面的初学者提供一些有益的参考。

一、如何理解功能安全？

我们不妨先来看看国家标准是怎么描述的（GB/T 20438）：
fusa 功能安全,功能安全专栏,安全,系统安全,mcu

这里有几个关键点：

1. 功能安全针对谁

功能安全只针对“电气、电子或者可编程电子设备”，我们在汽车领域中常见的ECU，就属于这类设备。有些读者可能会问：汽车上的机械装置，比如刹车踏板，在不在功能安全研究的范围？答案是：不在。

在工程上，通常认为机械装置是绝对可靠的。虽然机械装置也可能存在设计缺陷，或者原材料供应或者在生产阶段引入的缺陷，但这些是质量管理要解决的问题，而不在功能安全的范畴内。

2. 如何理解失效

失效很容易理解，国标里面也讲的很清楚。但是，有一个概念常常和它形成混淆，那就是“缺陷”。在功能安全培训一开始，也有同学常常问一个问题：如果这个ECU过了功能安全认证，是不是说ECU里面的软件就没有Bug了？当然不是这样的。

众所周知，没有缺陷的软件是不存在的。功能安全的目标是通过一定的流程和技术手段，确保这个ECU失效后，能够有其他手段使系统不会产生预期的危害，或者将危害降低到可以接受的范围内。例如，我们可以在系统中增加一个ECU作为它的备份，如果另一个ECU失效，可以第一时间接替失效的ECU，避免出现列车碰撞、刹车失灵等危害。虽然标准中会引入保证软件质量的方法和技术要求，但是消灭缺陷不是功能安全的最终目标。

3. 几个关键概念

[1]共因失效(Common Cause Failure, CCF)

共因失效是在多通道系统里，两个或多个通道由于共同故障导致的失效。避免共因失效最主要的手段是隔离和异构。一方面，在设计上让各个通道相互独立；另一方面，各个通道尽量采用不同的技术来实现，如采用不同的物理原理的传感器（压力/温度…）。

[2]安全完整性等级(Safety Integrity Level, SIL)

SIL越高，故障的风险也越大，对安全性的要求也越高。GB/T 20438把安全完整性等级分为4个级别：SIL1/SIL2/SIL3/SIL4。SIL4对应最高安全完整性等级。

[3]常用的安全技术：三板斧之冗余

fusa 功能安全,功能安全专栏,安全,系统安全,mcu 如上面这张图，冗余的关键在于：各个通道需要保持独立性，避免产生上面讲过的共因失效（CCF）。

[4]常用的安全技术：三板斧之诊断
fusa 功能安全,功能安全专栏,安全,系统安全,mcu
通过诊断通道对通道A的运行状态或者输出进行监控，如果发现异常，则运行异常处理程序。异常处理程序可以是采用重启通道A等手段使通道A重新恢复正常工作，也可以是给整个系统输出错误信息，从而将通道A失效的影响降低到可接受的范围内。

[5]常用的安全技术：三板斧之端到端通信保护
fusa 功能安全,功能安全专栏,安全,系统安全,mcu
端到端通信保护的目标是确保参与通信的两端A和B，它们之间的数据收到不存在重复、丢失、延迟、错误、第三方篡改等异常情况。常用的措施有：给数据加CRC校验，增加计数校验等。

二、AutoSar Classic Platform Os功能安全机制解析

AUTOSAR是AUTomotive Open System Architecture的缩写，是由全球汽车制造商、部件供应商及其他电子、半导体和软件系统公司联合建立的一套体系结构。这个体系结构亮点很多，覆盖面也很大，本文仅以其中的Classic Platform Os这一个模块为例，看它采用了哪些技术来达到功能安全预期目标。

1. AutoSar Classic Platform Os简介

AutoSar Classic Platform Os是AutoSar Classic Platform中定义的一个嵌入式实时操作系统标准。这个标准的基础是汽车领域中已经被成熟应用的OSEK标准。虽然在汽车领域中，OSEK已经不是什么新鲜事物，但经过AutoSar Classic Platform扩展之后，这个系统形成了它的独到之处：

1. Os_Application
在OSEK中，最基本的运行单位是任务（Task）和中断（Isr）。而在AutoSar Classic Platform中，在任务和中断的外面又加了一层，称为Os_Application。
Os_Application中可以包含多个任务和中断，这有点类似于进程和线程之间的关系，但又不完全一样。在进行调度时，操作系统处理的最基本单位仍然是任务，Os_Application只是一个逻辑上的容器。这个容器的具体作用和特点，将在下文中单独进行描述。

2. 强实时性
在同一个Os_Application内部，任务调度方式只支持抢占式调度，高优先级任务立即获得处理器并进入执行体。在Os_Application执行结束后，还必须显示调用TerminateApplication触发后续的任务调度。

对于中断，AutoSar Classic Platform继承了OSEK的逻辑：将中断分成两类，一类中断和二类中断。一类中断操作系统不感知，可以抢断正在运行的任务，中断退出时也不触发任务调度，非常适合对中断处理实时性有很高要求的场合。二类中断操作系统可以感知，在退出中断时，操作系统可以触发任务调度。通过以上设计，使AutoSar Classic Platform Os具备了很强的实时性。

3. 静态资源分配
AutoSar Classic Platform Os中，不管是任务还是中断，都是静态配置的，这和通常见到的Ucos这类操作系统有本质区别。

在Ucos中，通过调用OsTaskCreate来创建一个任务。而在AutoSar Classic Platform Os中，每个任务所需要的参数（任务ID、优先级等）和所需要的资源（任务堆栈、执行体指针等），在Os配置阶段（在编译之前），通过专用的配置工具，结合源代码自动生成技术，就被静态指定了。在Os运行时，只能决定哪个任务在什么时候运行，在什么时候退出，而不能对已经指定的任务资源进行动态创建和回收。

2. 空间分区和时间分区

内存分区的作用是使不同功能安全等级的应用在同一个操作系统上共存，且互不影响。比如在一个操作系统之上，构建了3个应用：应用1满足SIL2功能安全等级要求，应用2满足SIL4功能安全等级要求，应用3满足没有功能安全等级要求。很显然，这三个应用所采用的功能安全等级不同，所以在运行时必须确保相互独立，才能避免由于某个应用失效而对其他应用产生不利影响。对于应用来说，确保相互独立，主要从两方面入手：空间和时间，即所谓的空间分区和时间分区。而这也是功能安全标准中所要求的，如前面提到的GB/T 20438以及汽车领域中的ISO26262。AutoSar Classic Platform Os也正是针对ISO26262的要求进行了相应设计。

1. 空间分区

在 AutoSar Classic Platform Os中，一个Os_Application就是一个应用，包含了若干任务和中断。在存储上，Os_Application无非就是由代码段和数据段构成的。这里的数据段包含了像堆栈、BSS段等，因为这些段也都是人为定义的，其本质上也都可以算在数据段里面。所以，空间分区实质上就是把各个Os_Application的代码段和数据段进行隔离，使不同Os_Application只能执行自己的代码段，可以受控访问其他Os_Application的数据段，这样一来，就可以避免Os_Application之间产生不利的相互影响。

同时，在空间分区机制中，还涉及到用户态和特权态的切换。用户态和特权态是处理器的两种工作状态。当处理器工作在用户态时，应用代码不能访问处理器核心控制寄存器等硬件资源，否则会产生异常（Trap）。如果要访问，则必须在应用代码中明确触发一个预定义好的异常，从而使处理器进入特权态，才能访问这些受控硬件资源。通过这种机制，就可以避免应用代码对关键硬件资源产生非法访问。很明显，操作系统应该工作在特权态下，处于用户态的应用代码进出特权态的接口，以及在特权态下所执行的各种操作，都应该由操作系统来提供。

空间分区这一机制在高安全嵌入式实时操作系统中被广泛应用，如Ucos安全版、VxWorks认证版、Qnx微内核操作系统等。但是 AutoSar Classic Platform Os所设计的空间分区方案有自己的特点：AutoSar Classic Platform Os把Os_Application分为两类，一是可信Os_Application，二是不可信Os_Application。在这里，可信Os_Application主要是指由厂商自行开发的应用，而不可信Os_Application主要是指由第三方开发的应用。可信Os_Application可以和操作系统一起，运行在处理器特权态下，不可信Os_Application必须运行在用户态下。这样做的好处是能够减少Os_Application进出特权态而产生的消耗。可别小看这个消耗：由用户态进入特权态，需要引发一次异常，而异常可以看做是中断，那么就会多出1个中断响应时间。如果需要频繁进入特权态，那么这个时间累积起来，还是非常可观的。像Qnx这样的微内核操作系统，把操作系统内核放在特权态，而把外设驱动、上层应用等统统作为应用看待，放在用户态。这样做虽然有它的好处，但是也带来了由于频繁进行处理器状态切换而产生的性能问题。

那么，空间分区如何实现呢？这里就要依赖于处理器本身。只有处理器具备MMU（内存管理单元），或者MPU（内存保护单元），才能实现这一机制。MMU把存储空间划分成多个页面（Page），每个页面可以设置访问权限（只读、可写、可执行等），这样以来，就可以把Os_Application的代码段和数据段映射到不同的页面上，就可以实现不同Os_Application之间的隔离。使用MPU也可以实现，只不过MPU在灵活性上通常比MMU要差一些。

2. 时间分区

时间分区是指，不同应用在运行时间上相互隔离，不能产生相互影响。例如，应用1出现死循环，占着处理器不放，其他应用都没法运行，就是一个典型的例子。

时间分区的实现机制相对简单一些。一般的做法是采用时间片轮转的调度策略，就是每个任务运行完自己的时间片之后，就切换到其他任务运行，这样就可以避免由单一任务运行时间过长，使其他任务“饿死”的问题。但在AutoSar Classic Platform Os中，由于没有时间片轮转调度机制，所以也就不能采用这种方式。

AutoSar Classic Platform Os定义了时间保护机制，变相实现时间分区。时间保护机制针对任务或者第二类中断，通过预先配置的时间上限，来控制任务或者中断的执行时间、执行频次和锁定资源的时间，具体如下：
1、执行时间上限：当任务或者中断的执行时间达到该上限时，操作系统强制结束该任务或者中断，避免任务或者中断运行时间过长；
2、间隔时间下限：当任务或者中断到来的间隔小于该下限时，操作系统需要捕获这一异常，避免系统出现时序错误；
3、锁定资源上限：当任务或者中断锁定资源的时间达到该上限时，操作系统强制结束该任务或者中断，避免任务或者中断长时间占用资源而阻塞其他任务或者中断。

3. 保护类机制

AutoSar Classic Platform Os在错误处理方面主要包括三块内容：堆栈保护、服务保护和Hook机制。

1. 堆栈保护

堆栈保护的主要目的是避免出现堆栈溢出。堆栈是任务或者中断执行所必须依赖的数据结构。堆栈通常用来存放函数入参、出参、局部变量等运行时数据。堆栈有生长方向，向低地址生长还是向高地址生长，不同处理器定义有所不同。

堆栈保护的实现同样依赖于处理器是否具备MMU或者MPU。如果具备，则利用MMU或者MPU的页保护/段保护机制对堆栈进行保护，如果堆栈指针超出了页面/段的保护范围，则会产生异常。如果不具备MMU或者MPU，AutoSar Classic Platform Os同样要求实现一种简化的堆栈保护机制，但是这个时候，只能在发生任务调度或者中断发生时去判断任务或者中断是否已经发生了堆栈溢出，而无法在任务或者中断执行过程中实时监控。

对于不具备MMU或者MPU的场景，这里介绍一种实现方法：
1、在操作系统初始化阶段，将每个任务或者中断所对应的堆栈（就是一个静态数组）初始化为预定义的魔术字，例如0xCC；
2、在任务调度时，在进入待执行任务体之前，首先判断该任务堆栈顶端数组元素值是否仍未预定义的魔术字0xCC，如果不是，则说明栈顶已经被改写过，说明任务已经用满了整个堆栈，有可能产生堆栈溢出；
3、在中断（二类中断）到来时，咱中断响应函数（Isr）头部，执行第二点中的操作，判断中断是否已经用满了整个堆栈。

2. 服务保护

服务保护中的“服务”是指操作系统对外提供的API编程接口，服务保护的意义就是要确保API编程接口本身抵抗出错的能力。具体包含以下三类场景：
1、API接口入参合法性检查；
2、API接口上下文错误检查。例如：在禁止调用某接口的场景下调用了该接口，比如在操作系统启动时，在StartupHook里面不能调动启动任务的接口；
3、排除可能导致出错的调用场景。例如：在任务结束时，必须调用相应接口释放所占用的资源；在Os_Application之间相互调用接口时，需要检查该接口的调用权限。

服务保护贯彻了功能安全标准中提倡防御式编程这一思想。