本文主要是介绍汽车功能安全--AutoSAR中的功能安全机制，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
目录
1. Memory Partitioning
2. Timing\Excute Monitor
3. E2E
4.小结
大家好，这里是高温下认真码字的肌肉；许久没有聊中间件的问题，正巧可能要启动SafetyPack的开发，因此今天回顾回顾在AUTOSAR文档中关于Safety的一些机制。
在实际开发中，我们经常遇到不同功能安全等级的软件模块集成到一个ECU中，例如座舱域中MCU电源管理模块和IPC通信模块的ASIL等级在产品定义就不同，如何保证低ASIL等级的软件模块不对高ASIL等级软件模块的造成影响？
ISO26262 -6 附录D给出了思考角度，而AUTOSAR文档进一总结下来可以概括为四个大方向：
- 内存：在软件开发部署过程中，AUTOSAR OS提出内存分区机制(Memory Partitioning Mechanisms)用于隔离不同软件程序；
- 定时：使用WdgM的程序流监控、使用OS的时间保护机制；
- 程序执行：使用WdgM的逻辑监控机制；
- 信息交互：使用E2E等监测通信是否失效；
从方向上虽然是四个方面，但从实际产品看，内存保护、时序可以由OS、WdgM来保证，信息交互可以由E2E来保证。
1. Memory Partitioning
在ISO26262中提到，软件组件交互造成的与memory失效因素，主要有以下几个方面：
- memory内容被破坏；
- 各软件组件对外的读写访问权限；
- 栈溢出；
- ...
因此，内存分区就是通过限制memory或者外设寄存器的访问权限来实现保护内存，避免出现上述问题；
我们知道，分区这个概念最早是在OS、RTE相关文档中进行描述，其中比较难以理解的就是OS提到的OS-Appliaction的概念，原文如下：
AUTOSAR OS-Applications are collections of Operating System objects such as Tasks, ISRs, Schedule Tables, Counters and Alarms that form a cohesive functional unit. All objects which belong to the same OS-Application have access to each other.
The Operating System objects within an OS-Application may belong to different AUTOSAR Software Components. The RTE implements a memory area which is accessible by all members of the OS-Application without restrictions to facilitate communication between the SW-Cs efficiently.
个人理解OS-Application像是大杂烩，包含了系统稳定运行的各种元素，同时是OS用于实现分区的一个抽象，包含如下成员：
因此我们就不难理解在代码里看到过的两种类型OS-Appliaction。
- Trusted OS-Appllcation：权限比较高的一类，一般对memory、OS API的调用访问没有限制
- Non-Trusted OS-Application：有限制访问权限，并且在运行时必须打开监控或者保护功能；
在OS配置时，我们通常会考虑将一些关键的Task、SWC分配到Trust OS-App，如下：
而Trust与Non-Trusted 之间的通信，一般只能通过RTE进行，如下图：
有了上述概念之后，我们来继续探讨内存分区。
实际上，提供内存保护大家可能都会想到MPU或者MMU；AUTOSAR也不能免俗，在具体实现上，可以通过MPU设置memory的不同访问属性（读写执行）来保证memory分区，如下图：
那这个MPU是属于哪个AUTOSAR模块？ 毫无疑问，就是系统运行的基石--OS，配置示例如下：
不仅如下，OS的监控机制还包括栈监控、时间保护、服务保护等等，如下：
总结下来，内存分区关键点在于隔离，MPU可以进行实现，除此之外，MPU还可以保证栈的隔离。
2. Timing\Excute Monitor
时间是嵌入式实时系统的一个重要特性。一般要求系统的动作和反应在正确的时间内执行。
常见的失效模式有：死锁、任务执行时间分配错误、任务执行被阻塞。
在AutoSAR定义了OS、WdgM等模块用于实现时间监控机制。
OS提供了Timing Protection机制，主要包括如下三种：
- Execution Time Protection：通过监控任务或者2类中断的Execution Budget，来防止时间错误；
- Locking Time Protection：通过监控中断挂起、资源阻塞等的Lock Budget防止时间错误；
WdgMd监控功能之前已经聊过了，包含：
- Alive Monitoring：对周期性任务（软件）的时间进行监控；
- Dealine Monitoring：对非周期性任务的时间进行监控；
- Logical Monitoring：对程序执行顺序的正确性进行监控；
因此，关于时间保护，我们使用Alive和Dealine，关于程序流我们可以使用Logic监控。
3. E2E
之前聊SecOC时简单提过E2E，主要面向Safety，保证了数据的完整性和时效性，它不仅可以用在板端通信，还可以用在不同SWC之间的通信。
通信常见的失效模式包括：通信丢失、通信数据损坏、通信数据重放、延迟等等；
因此E2E(End to End)从分别从如下几个方面进行保护：
- 使用CRC对数据、数据ID、counter进行计算，可以探测到信号\数据的完整性；
- 使用Counter计数来探测消息、数据的重放；
- 接收端通过计时来探测消息的丢失、延迟等
回过头来，如果E2E仅用在板端通信，那么SecOC可以涵盖全大部分数据校验过程，包括完整性、身份识别、重放攻击等；因此在实际使用中，我们通常把会将Safety相关信号融合进CanFD，然后将该报文设置为SecOC属性，先校验SecOC，最后拆出信号校验E2E，既保证了Security(红框)，又保证了Safety（蓝框），如下图：
4.小结
虽然AutoSAR对这些做了定义，但不管MICROSAR还是RTA-BSW，或多或少都有自己的独特实现。
所谓标准统一、实现竞争，最终到现在形成了用惯了一家产品，再去适应别家产品就有点困难的局面。
简单单叹口气，周末愉快！
这篇关于汽车功能安全--AutoSAR中的功能安全机制的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
