汽车操作系统和中间件的关系

随着汽车智能化的深入，除了自动驾驶算法以外，操作系统和中间件是目前整车软件架构中最核心的两个环节，这一点已基本形成行业共识，但这些软件是否需要自研，如何开发，Autosar到底是操作系统还是中间件，能不能替代，这些都是最常见的问题。对于非计算机专业的团队，要理解清楚这些复杂软件对汽车的意义和整个图景，是比较困难的一件事。本文从基本的操作系统设计概念出发，尝试厘清汽车行业对操作系统和中间件等核心技术的定位和理解误区。

首先是目前能不能真正从零开发一个标准的大型操作系统(即所谓的POSIX OS, 严格意义上的操作系统)? 很遗憾不能, 虽然我们很需要,但是无论国内某些互联网/IT大厂如何宣传包装, 从零开发的操作系统目前在技术和商业上都无法实现, 汽车操作系统也不例外。

简单来讲,如果嵌入式操作系统(比如FreeRTOS, uCOS或Autosar CP的内核)的开发难度和工作量是1, 那么大型操作系统的开发难度和工作量就是99, 从体量就能看出,一个完整的嵌入式操作系统最多几十M, 而一个大型操作系统最少也有几个G, Debug版本十几年前就已经超过50G, 不管是代码量,还是其涉及的生态体系,两者都不能相提并论。对于嵌入式操作系统,国内聚集一下力量是可以自研的,且嵌入式的应用层软件也多是定制开发,系统的自建标准,应用层很容易配合。而一个大型操作系统,实际就是海量的协议和标准的集合体, 几乎要全世界的软硬件公司认可和配合,所以目前国内没有任何公司能建立真正的操作系统,一是没有领袖级的底层开发人员,二是即使操作系统开发出来了,也没有上下游公司配合新的标准来重新开发软硬件。简而言之,开发操作系统的时代已经过去了。

狭义上的操作系统无法开发, 那广义上的汽车操作系统还能做什么？首先明确一点，无论谁再来做，都只能是在操作系统内核之上根据车规或场景对现有的操作系统进行优化和增补, 使其适配汽车。(也有车厂对操作系统UI进行升级替换, 冠以自家系统的名称,这更多属于品牌和营销层面的操作, 不在本文讨论范围内)。

适配和优化操作系统的主要方向之一，就是让操作系统上的新的复杂软件也满足汽车功能安全, 比如汽车软件的执行需要确定性: 软件需要在规定的时间内,规定的时序去执行任务。(这个问题涵盖的领域很多, 还有物理网络,或应用层的因素, 这些不属于操作系统范畴，也不在本文讨论范围内)。

目前，汽车行业有观点认为大型操作系统的多进程调度机制不能满足确定性任务的需求,多个任务在经过了复杂的跨进程调度以及多核CPU的负载均衡之后,任务执行时间,输出结果和顺序都有概率无法与预设的一致。这在自动驾驶或者高安全等级的应用中可能会产生某些问题（类似于偶发的glitch）。以时序为例，比如某个场景需要执行1,2,3,4步操作, 被Linux的多进程策略调度之后达到执行层,随机变成了3,4,1,2。反之从传感器获取数据亦然。

这种不确定性在Linux/Android/Windows等操作系统中的确存在。对待这个问题, 行业一般有两种态度: 

1

暂时不解决或忽略, 从用户场景的角度来看, 这种不确定性造成的问题并不是很严重, 能用其他冗余来备份;

2

必须得解决，严格按照汽车软件规范或者26262的标准,把这种不确定性消灭掉。

先说第二种态度, 解决方案就很有意思，一般有两种路线, 第一种,通过中间件去弥补操作系统进程调度造成的不确定性。第二种,更换操作系统内核。多数汽车操作系统或中间件方案,其实都是第一种方案, 典型的就是Autosar AP（运行时的执行管理模块）, 这类方案能否解决问题？这里就需要先理解一下大型操作系统的基本设计理念。

操作系统从整体架构上分为两个空间, 即内核空间和用户空间。从软件运行权限的角度来看,操作系统是按Ring(环)的理念来设计, 内核空间在内环Ring0, 用户空间是外环Ring3, Ring0权限最大,Ring3权限最小；对硬件资源的调度优先级和限制也是从内到外递减, Ring0可以访问全部资源, Ring3受到各种限制(Ring1,2基本不用)。不管Linux,安卓还是Windows, 都是按此理念来设计,如下图:

Ring0上的程序就是操作系统内核,包括进程管理、进程间通信、设备管理、网络通信、文件系统等经典模块,哪些模块在内核,哪些系统服务在用户空间,不同的操作系统有些差异,但功能基本一致。内核空间的模块简单理解就是超级管理员,能访问全部硬件资源, 而Ring3上的用户程序相当于普通用户,访问的硬件资源是受限制的。这里需要特别指出的是,用户空间内的软件并不是仅包括普遍理解中的APP,而是全部非操作系统内核模块都属于用户空间,包括但不限于中间件,数据库,HMI, APP, 算法, 业务逻辑, 甚至很多操作系统自带的服务和组件, 当然Autosar AP也不例外,都只能运行在Ring3的用户空间中。整个操作系统的两层结构如下图所示:

无论如何包装,运行时也好，中间件也好，广义OS也好，这些方案都是在大型操作系统的用户空间中开发软件, 尝试去解决内核调度的不确定性。这里就有一个很严重的错位, 操作系统内核(进程调度机制)产生的问题,能否由一个用户空间的软件(AutosarAP或其他中间件)去解决? 这明显是有问题的, 因为上层或者Ring3的中间件或其他运行时的软件,从最基本的操作系统设计原理上来看, 没有权限去插手更高权限的Ring0内核的事。所有Ring3自定义的优先级和执行规则,到了Ring0上都不会被认可, Ring0始终会按照操作系统原有的进程调度策略来执行。

那确定性问题的根本解决方案就很明显了, 内核的问题只能用同在内核空间的软件来解决, 用户空间的软件无权干涉内核。要从根本上解决任务执行的不确定性, 只能修改操作系统内核调度策略或直接更换内核, 这个技术难度非常大，实际是操作系统中最难开发的部分，全球市场上有1-2家内核解决方案商可提供这类第三方实时性内核，用于实现多进程下的任务确定性执行, 这类方案实际是开发新内核而不是开发中间件。

而Autosar AP或者类似的中间件，都是基于Linux和其系统接口来开发的用户空间软件, 无法根治内核的问题。那是不是AP（AP有多个功能划分，这里重点讨论其核心的执行管理/状态机等模块）完全无用？也不尽然，Autosar AP实际是设计了一种取巧的办法来尝试解决内核任务调度的问题: 建立一个RTE机制（运行时, 借鉴了高级编程语言的理念）,在操作系统之上充当一个壳, 让其他汽车软件全部运行在RTE之上,或接受RTE的管理，调度和跨进程通信, 这样从Ring0内核的角度来看, 整个Ring3上就像是只有1个APP -- AutosarAP RTE,  而运行在RTE上的各种APP间的调度, 对于内核来说是都属于RTE内部的问题, 上层APP被RTE统一装进了RTE设计的沙盒内,这些沙盒和其中的APP都是通过RTE的调度策略来控制状态机和实现跨进程通信。这种方案等于Autosar AP在系统中加了一层新的Ring4, Autosar RTE自己运行在Ring3上, 其他APP运行在Ring4上, 只要AP的RTE和操作系统内核之间用固定规则约束好, 保证RTE和Ring0的内核交互不出问题, 那Ring4的APPs最终经过RTE的管控, 理论上最终在Ring0上执行时出问题的概率就大大降低。这种理念, 类似于在Linux的用户空间中又实现了一个嵌入式操作系统. 如下图:

这种办法并未从根本上调整操作系统内核调度策略, 但在理论上提供了一种绕路的办法,让所有应用必须接受AP RTE的管理,在量产的时候, 可以限制各种APP直接和操作系统接口进行交互。但实际上这种方案问题较多：

01

用户空间的软件，既有操作系统组件和服务，也有第三方应用，包括中间件、算法和APP，这些软件对系统服务和内核均有很复杂的依赖关系，这些服务和更多间接依赖的系统组件之间又有更为复杂的依赖关系，（实际上除了操作系统团队本身，第三方搞不明白深层次的系统组件调用关系），而由于各个软件需要层层调用和依赖大量公用的系统服务和资源，在此过程中会对公用资源进行竞争和互斥，最终产生等待和延迟，这属于最根本的操作系统机制。而RTE想用自己的跨任务通信机制去覆盖现有系统的机制，就得考虑RTE自身和系统内核调用的协同是否能完美无缺的实现，或者能否完全摆脱对系统组件的依赖，实际上这种方案实现难度极大，严重的情况可能会破坏组件间的依赖关系，如果仅是做守护进程，则没有什么效果和价值。

02

安全很难保证，稍微有点经验的软件团队, 都能绕开一个非系统内核的程序(RTE)或者其定义的规则, 直接无约束的调用系统接口, 从而对底层进行控制。事实上，从过往历史来看, 没有哪个行业能实现如此封闭的开源系统, 即便实现了, 在本来内置了大量功能和协议的POSIX系统之上，再去覆盖一层复杂的管理机制，最终性能几何? 而从更长远的生态来看, 这种做法与汽车要实现类似于智能硬件一样的开放生态愿景,似乎也背道而驰的。

特斯拉或者某些比较擅长软件的新势力是怎么做的呢? 他们实际是第一种态度, 容忍这种不确定性, 也许他们没那么循规蹈矩。总之，特斯拉既没有更换系统内核, 也没有使用Autosar, 他们只是认为在绝大多数用户场景中这种偶发的不确定性无需解决或暂不解决, 对于个别的高安全场景, 通过独立的MCU和嵌入式软件进行冗余处理即可。

这里就要提及经典的多传感器传输数据由于延时不一致导致的融合问题, 这些数据表面上是通过操作系统的不同进程来收发，最终出现了不同的延迟,但其实大多数延时并非由任务调度策略造成的,而是因为别的原因, 目前智驾域控上的软件就那么几个,真正海量跨进程的问题还没有出现。实际ADAS这类问题不需要修改操作系统任务调度策略也能解决, 对于软件能力强的团队, 这个问题有不少解决方案, 这也是特斯拉或者个别新势力既不换实时性内核,也不用Autosar的原因,因为有更好的解决办法。

至于中间件,这套架构创立开始,就不是用来给操作系统做补充的, 尤其是DDS, MQTT, SOME/IP中间件, 都有其他目的和价值。而把中间件包装成广义的汽车操作系统, 仅是商业动机，技术上两者还是有严格界限的。

再来看看Autosar, 很多人以为CP和AP是同一套理念和架构，差异仅是针对不同类型的芯片，但 Autosar CP和AP实际是两套完全不同的软件。简单讲CP是嵌入式操作系统+嵌入式中间件，而AP只是Linux之上的一个中间件软件（AP必须先安装Linux）。AutosarCP包含嵌入式操作系统内核, 驱动模型, 还提供了一个类似于进程调度的机制来支持多个软件团队的并行开发和集成 (嵌入式系统一般没有进程概念,任务和线程都在同一个工程下, 所以任务执行的确定性很容易实现)。而嵌入式软件本身代码量少, 用工具可实现低代码的一站式开发, 成本低，对软件开发人员没有要求，所以CP用在汽车MCU生态中很成功，形成了行业标准.

Autosar CP的成功并不意味着AP沿用这种思路就行得通，反观目前Autosar AP的局面, 归根结底还是技术理念有问题, AP用嵌入式的思维和架构,去给一个复杂度和体积达上千倍的大型操作系统套壳, 这个宏大的目标对开发AP工具的技术团队的要求之高, 实难想象。而用一个用户空间的软件去解决内核的问题, 也是一种典型的错位：中间件就是中间件，它去做操作系统的事，实际是缘木求鱼。