今年小怿开设了CLASSIC AUTOSAR系列科普专栏，将对AUTOSAR内容进行较为基础的科普，希望能对不同背景下的工程师带来帮助，本期主要描述os模块，一起来看一下吧！
目录
01
汽车操作系统分类及发展
在正式进入主题之前，我们先对车载使用的操作系统进行一个梳理，引出我们今天的主角。从应用场景上我们可以将车控操作系统分为两类：一类是嵌入式实时操作系统，用于传统的车辆控制，适用于动力系统与底盘控制等领域；另一类是基于POSIX标准的操作系统，适用于自动驾驶所需要的高性能计算和高带宽通信。
嵌入式实时操作系统是车辆电控系统的内核与基石，能够利用有限资源及时处理多个任务。车辆底盘控制与动力系统对操作系统最基本的要求是高实时性，系统需要在规定时间内完成资源分配、任务同步等指定动作。嵌入式实时操作系统具有高可靠性、及时性、交互性以及多路性的优势，系统响应极高，通常在微秒级别，满足了高实时性的要求。
在欧洲，1994成立OSEK/VDX协会，并于1995年达成共识发布其规范OSEK/VDX标准，提出OSEK OS；2003年，9家企业作为核心成员，以OSEK/VDX为基础，成立AUTOSAR组织，相应的在OSEK OS基础上提出了AUTOSAR OS。
02
AUTOSAR OS是什么
那AUTOSAR OS是什么？AUTOSAR OS是一个Operating System，即操作系统。操作系统大家应该都有用过，不管是Windows、Linux 或者是Android之类的。但因为车控类控制器资源的限制和主要场景的不同，它和我们平时常用的这些操作系统还是差别很大的，就所承担的任务而言，AUTOSAR OS相比于通用OS还是很局限的。
用过Windows的都应该有体会，通用操作系统功能很强大，能装软件，能同时跑多个程序，能连接打印机、游戏手柄，能上网，能保存文件，当然也有很美观的图形界面等。
而AUTOSAR OS是干什么的呢？它最核心的功能是管理任务和事件的调度，不同任务间的同步流，并且提供监控和错误处理功能。或者用最简化理解就是一个函数调度器。有的同学问了：那什么是调度器呢？其实可以类比于一个工作中的场景：
比如，一家公司的老板，每天的待办事项很多，同一时间可能要参加好多个会，每个会都有各自不同的会议材料和报告要准备。如果这些事都让老板自己来安排，就算精力再旺盛也会感到手忙脚乱。这时候如果能有个秘书专门来帮他管理这些，提前和下属约定会议时间，准备参加不同会议的会议材料，如果会议冲突，就根据老板定的紧急程度来排先后顺序，那整个行程就会轻松很多。
这和任务管理或是函数调度的概念是一模一样的。也就是说同样基于一个紧急程度或是优先级来管理，我们的ECU可能同时要采集多种采样频率的A/D信号，可能需要驱动不同频率的PWM执行器，又或者可能需要定期处理各种周期不同的总线信号。程序员手动来安排什么时候该执行什么任务，我估计他会疯掉的，那这时候我们的“齐天大圣”出现了：这些工作全都可以交由我们AUTOSAR OS来自动完成！
我们再看它不是什么。如前所述，我们这个AUTOSAR OS的功能有限，它几乎只能干上面的任务。那有的同学又问了：我们汽车ECU几乎都得联网（CAN、LIN、Ethernet），也得存数据（Flash、EEPROM），还得连一些传感器执行器（电机，温度传感器）......如果AUTOSAR OS干不了，那谁来干这些呢？这些都是通用需求，AUTOSAR如果没有这些功能，那它有点鸡肋啊！
别急，让AUTOSAR组织告诉你，啥叫送佛送到西！请看下图：
03
AUTOSAR OS 与 OSEK OS联系
言归正传，我们在论述发展的时候提过，AUTOSAR 是在OSEK的基础上发展而来的，相应的AUTOSAR OS也是从OSEK OS发展而来的，所以他们两者的关系是：鸡蛋和蛋黄。
AUTOSAR OS完全兼容OSEK，能在OSEK上跑的，都能在AUTOSAR OS跑；但是AUTOSAR OS的文档几乎只介绍OSEK上没有的功能，如果需要弄懂AUTOSAR OS必须理解OSEK OS。从下面AUTOSAR OS的Scalability Class图可以看出，AUTOSAR OS包含了OSEK OS支持的所有功能。
04
AUTOSAR OS的基本对象
好了，OS的主要功能我们已经和清楚了，那究竟是如何完成这些任务的呢？当然OS是通过操作一系列元素（数据结构）来完成功能的，下图展示了AUTOSAR OS主要核心的元素，主要包含：Task、ISR、Counter、Alarm、Event、Schedule Table、Application。
4.1
调度实体—Task & ISR
我们刚才说到了，AUTOSAR OS最主要的功能是调度。那究竟要调度什么东西呢？在OS里有专业一点的术语叫调度实体；并且在OS中我们有两种可供调度的实体，其中一种就是Task(任务)，另一种叫ISR(Interrupt Service Routine )。所谓的任务就是我们常规执行的一些工作，比如说我们ECU里面设计的控制逻辑等；而中断几乎都是和硬件相关联的（排除软中断），是我们的一些MCU的外设触发事件时执行的一些函数，比如我们的定时器时间耗尽时触发的周期型采样，或者收到某个特定报文等事件来触发的处理函数。
Task
Task有两种类型，一个是 Basic Task ；另一种是 Extended Task。两者的区别在于Extend类型相比Basic多了一个Waiting状态：
Waiting状态又称挂起态，允许Task在执行的过程中如果发现某些前提条件不满足，可以主动暂停自己这个Task的执行，然后把CPU让出来给别的任务执行，增加了CPU的利用率。
而Basic task不允许 Waiting，就是说这种函数执行中不会主动让出CPU资源，除非自己停止或者被高优先级的任务抢占；而Extend则允许这种场景发生。
另外，其他三个状态分别为：
· running状态：运行态，即这个Task正在占用 CPU运行；
· suspend状态：暂停态，即这个Task被其他Task或是ISR抢占，或是自己运行结束；
· ready状态：就绪态，即运行这个Task的前提条件已经满足，但是可能由于高优先级的任务正在运行；
下图为截取一段Task代码的展示，大家可以具体感受下：
ISR
ISR，即中断服务例程，就是说它提供了一种机制，不需要一直循环地去查看事件的发生（轮询），而是事先预判事件发生了需要执行的任务项（ISR），等事件来了后通知CPU，然后CPU按照我的预先安排去执行动作；
ISR分为两类：Category 1和Category 2。Category 1指不允许执行在服务例程这段函数中执行任何OS的提供的功能函数(API) 。Category 1是为了能够更快地响应。因为如果执行OS的某些函数，势必会造成一些环境的切换等等，可能会有一些时延。Category 2 则相应的可以执行OS的提供的功能函数(API)，并且在执行完后，可能会触发Task调度；
4.2
Counter & Alarm
Alarm字面意思理解就是一个闹钟。比如说到 9 点响一下铃，提醒我上班；到 6 点再响一下，提醒我下班。同样的在OS alarm中也是起到相同的作用，比如周期性的采样，周期性执行某项任务等场景；alarm在底层实现时，它会绑定一个 counter计数器，原理也很简单，Counter的周期是固定的，通过计算周期数来确定时间间隔。
4.3
Schedule Table
与Alarm应用场景类似，OS还提供了一个schedule table的元素，它直观理解就是把多个alarm组合成一个组，alarms之间有一个静态定义好的相对位置关系，即所谓的同步关系。当然，Schedule Table并没有 alarm，它是以 expire point来表达类似的概念。如图， Expiry point 1 和 Expiry point 2 之间，你可以用一个 delay 把它们两个联系在一起。至于为啥要多这一个元素，主要有两个方面原因：1.性能方面有优化空间；2.更好实现时间点之间的同步。
4.4
Event
Event概念其实也是服务于调度的，主要就是前文介绍过的扩展任务Extended Task的场景。前文说了Extended Task有一个状态是可以Waiting的状态，那等待什么呢？最常用的情况就是等待Event的发生。比如Task先执行了一段C程序语句，发现如果想继续执行接下来的语句，必须要收到某一条报文，如果没收到，task就需要停下等待直到收到该报文。做法也是很简单的“把大象装冰箱”三步：
创建一个Event，把这个Event和该Extend Task关联（需在配置工具中设置）
在该Task中需要等待的地方使用WaitEvent来等待事件
在收到报文的中断处理函数中，对该Event通过SetEvent进行设置事件
Event在此处完成的是类似于标志位Flag的功能。完成这三步，在收到报文后，OS会自动将该Event的状态设置为“发生”，并将Event关联的这个Task的状态设置为Ready就绪态，该Task就变为可以调度的状态。
4.5
Application
OS application其实就是一个边界或者是一个保护的功能，基于AUTOSAR开发的ECU内部可以包含功能安全相关与功能安全无关的SWC。ISO 26262要求不同的ASIL等级的软件组件之间要避免相互干扰 (Freedom from interference)。
AUTOSAR OS通过将OS-Application放置于独立的内存区域内，实现避免内存相关的干扰。这个机制叫做内存分区 (Memory Partitioning)。把一系列的之前提到过的所有对象放到一个容器里面，然后默认只有在里面的元素可以互相访问，如果别的 application 中元素要访问必须进行显式地授权（IOC等），也就是需要通过配置进行关联，这个元素其实和通用操作系统里面的进程概念有些类似。
05
结束语
本文介绍了汽车操作系统分类及发展，AUTOSAR OS主要功能以及AUTOSAR OS的关键元素，这些是掌握和理解操作系统的其他机制，比如资源分配与访问、任务调度方式和功能安全保护措施、工具链集成等的大前提，之后我们会持续推出一系列AUTOSAR专题来讲解其中的各个方面，记得关注哈。
喜欢此篇文章欢迎评论、收藏、分享支持小编~