0. 感想

这大概是我写的所有文章里最痛苦的一篇，从22年7月开始写，到现在也还是个半成品，中间断断续续新学习、复习了几门课程，还较浅的实践了一些东西。回过头看，这篇东西还是比较肤浅，感觉就是拾人牙慧，把别人讲过的东西东拼西凑了一番，最大的作用大概是给我自己补课，否则我平时的工作总是感觉到稀里糊涂的，各位看官轻喷吧。

我需要承认，真正理解文章提到的知识点和概念是困难的，这需要大量的学习和实践过程。比如，对于下文提到的“ASIC、FPGA、CPU、GPU的区别”，学过硬件课程、写过Verilog/ VHDL才能有更加深刻的体会；而对于 “车身、底盘、动力、ABS、ESP、CAN、AutoSAR，功能安全”等名词，对车辆工程部不熟悉的听起来就像天书一样。而由于我并非计算机科班出身，在写3、4章的时候十分吃力，为此还专门学了《计算机组成原理》《操作系统》《计算机网络》的课程，但现在又忘掉了一大半（好难受T~T）。

有限的精力限制了人们不能保证在每一个方向上深挖，但承认这种局限性恰是促使我们进步的动力。

1. 前言

当下汽车行业发生的技术革新中，汽车动力由内燃机逐步转向电动机，自动驾驶、智能座舱、智能网联相关应用逐步落地。而这一切的基础，是整车电子电气（EE）架构以及汽车软件的深刻变化：

电气架构由分布式转为集中式——单辆汽车数十个ECU被缩减为3-5个域控制器（Domain Controller）；

芯片算力大幅提升——2022年多款车型将搭载Nvidia的Orin SoC芯片，算力可达254TOPS，后续还有算力高达2000TOPS的Thor；

汽车操作系统变得更复杂——驾驶域原有的嵌入式RTOS变少，Tesla的汽车操作系统基于Linux改造而来，一些新势力采用QNX+Linux开发自动驾驶域操作系统；座舱系统Android系统开发；

以上所有的演化，也伴随着功能安全方法论的更新重构；

下面的架构图基本囊括了新一代汽车电子架构中硬件和软件的内容（这张图参照了《九章智驾》发的一张架构图，原图不太清晰，我重画了一下，也算加深记忆和理解）本文也会围绕这张图的内容展开，这张图会反复出现加深记忆。

自动驾驶车辆软硬件平台架构

2. 汽车的电子电气架构（2022.07.25）

2.1 汽车EE架构的演化

早期的汽车是纯粹的机械 + 电气产品，其功能基本依靠机械系统和原始的电气系统来实现：车窗靠手摇、燃油与空气混合靠化油器、转向靠液压泵助力、刹车没有ABS全凭脚踩、电气设备的控制基本依靠简单的开关+导线.....

而从1967年Bosch发布第一套发动机电子燃油喷射系统D-Jettronic取代化油器后，电子技术开始普遍被应用到汽车上，以实现更为复杂的控制逻辑。（尽管初代的D-Jettronic采用模拟电路 + 25个晶体管来执行所有的处理，并未发展出现代的ECU）

这又让我想起了读书时特别爱看的一个英国修车纪录片《Wheeler Dealer》，里面不同年代的汽车明显有着不一样的电气化程度——70s以前的车都是化油器，而80s之后的车则大多是电喷系统。汽车其他的系统模块同理。

Wheeler Dealer修车师傅Edd China（没错，这位主持人的姓氏是China）

后来，整车安装了大量的电子传感器、执行机构、以及计算芯片。通过微控芯片MCU对多个传感器回传的参数进行计算后，向执行机构发出控制指令，从而实现各种复杂的功能。我们来尝试罗列当前汽车装备的电子电气装置（不严谨，仅做粗略分类，读者只需要体会汽车EE设备的“多”即可）：

2.1.1 ECU的出现与点对点架构

如上所述，汽车电子电气化的重要里程碑就是：复杂的逻辑功能由专门的电子控制单元ECU（Electronic Control Unit）来实现。具体地讲：ECU架构和普通的冯诺依曼架构计算机类似，由微控制器MCU、存储单元ROM、RAM、输出/输出IO、模数AD换电路等组成。不同的ECU根据功能需求，还会具备如“PWM调制、PID控制、电压控制、看门狗、DSP、脉冲发生、各种电机驱动（如电动车的IGBT高功率芯片）”等等一系列单元——这应当是典型的嵌入式系统。

德国大陆Conti的车门控制单元

ECU的典型架构，作者：TechSugar

目前多数ECU上运行的汽车软件采用C语言开发，遵循《BUAA火车侠：自动驾驶仿真及其工具链（6万字扫盲）》中1.2节提到的基于V-Shape的开发流程，多用Matlab-Simulink生成C代码，搭配传统的仿真软件和硬件，进行从MIL、SIL到HIL、VIL的仿真验证，在保证ISO26262 功能安全基础上，大幅缩短了软件的开发时间。

在整车电子电气化初期，多采用点对点的架构，哪两个硬件之间存在通信需求，就连接一根线缆。然而问题很快就出现了：

首先，随着EE组件的增多以及控制逻辑的复杂化，硬件之间的物理连接开始变得复杂混乱；

其二，各ECU之间的运行并非完全隔离，而是需要大量的数据交互，尤其是动力和底盘相关的功能。点对点的架构使得整车开发效率低下，且可靠性降低。

2.1.2 基于总线的分布式架构

为解决该问题，80年代基于总线Bus的汽车电子电子架构应运而生。效仿计算机的I/O总线结构，所有汽车电子组件都连接在总线上，任何按照该总线协议生产的硬件单元都可以加入汽车总线网络进行通信。如此就简化了线路连接，提高了可靠性，最典型的就是CAN总线。而CAN总线也是由德国BOSCH公司开发，并最终成为汽车计算机控制系统和嵌入式工业控制局域网的标准总线，并演化为国际标准ISO 11898。

汽车的CAN总线架构案例

然而，此种基于总线的分布式架构随着时代发展也开始逐渐出现弊端：

随着车辆的深度电气化/智能化，汽车ECU的数量开始大幅增长，普通车型会采用数十个ECU，豪华车型甚至可达上百个ECU，而每加入一个新的ECU都会改变原有整车的网络拓扑结构，ECU、传感器之间的通讯和匹配变得极度复杂，严重拖慢开发进度。

整车线束动辄长达三五公里，重达几十公斤，成本居高不下（热知识：整车厂有专门的线束部门负责线束开发，此部门可能多达上百人）。

更为重要的是，ECU的软件大部分由Bosch、Conti、Denso等Tier1供应商提供，与硬件打包出售，整车厂拿到的是不开放的“黑盒”，无法形成自己的软件开发能力。在几十上百个ECU组成的分布式架构下，整车厂无法对所有功能进行整合，这对于ADAS/AD功能的开发是严重的障碍。并且，几十上百个ECU更是阻碍了“OTA升级”。

故事：之前美团的王兴曾经说“宝马代码有几亿行，而Tesla只有几千万行”，以此判断宝马的软件更完善，这明显是不熟悉汽车EE架构引起的言论。宝马当时采用了传统架构，其代码分布在众多ECU中，造成极大的代码冗余。而tesla采用集中式架构，代码量更少的情况下功能更为强大。

Audi A8的整车电子电器布局

2.1.3 基于域控制器的集中式架构

如果说目前仅仅是新的电子电器设备的增加堆叠，原有的分布式EE架构尚且能够维持，但随着自动驾驶、智能座舱、智能网联的兴起，该架构再也无力负担。

此时，汽车的EE架构开始转向集中式的“域架构”——将多个功能领域相近的ECU，集中到一个算力和资源都更强大的控制器中。这个控制器就被称之为“域控制器Domain Controller”（注意，这个和计算机网络领域的域控制器不是一个概念）。每个域控制器里面的应用程序对应一个传统ECU，而执行器的底层驱动也由域控制器统一管理，原来的ECU直接被取消，或者仅作为IO设备。域控制器间采用CAN FD、FlexRay、Ethernet等高速总线进行通信，由中央网关协调信息传输。

几个典型的集中式架构如：

Tesla的电子电气架构

典型的域控制器架构，From NXP恩智浦

小马智行基于Nvidia Orin的自动驾驶域控制器

集中式架构带来的优点有：

极大降低整车网络拓扑结构的复杂性和线束长度，例如早期的Tesla model S的整车线束为3km，而model 3的线束长度则控制在1.5km以内；

整车控制代码的开发权限收回OEM，想要引入一个新的功能时候，只要在现有域控制器基础上开发即可，OTA更新也更加方便；

供应商管理的难度降低，只需关注少数几家供应商即可；有志向一点的OEM，甚至会全栈自研（包括域控制器）；

不同的域控制器存在差异：自动驾驶和智能座舱域控制器对芯片算力、操作系统以及算法要求较高；动力域、底盘域和自动驾驶域涉及行车安全，出现失效可能造成致命后果，因此功能安全等级要求较高（关于功能安全等级的概念会反复提到，在后文会给出解释）。

2.2 车载通信网络

随着EE架构的进化，车载总线通信也在发展——通过统一的通信协议将汽车内各节点连接形成车内局域网络。在分布式架构中，各节点ECU根据自身传感器信息 + 从总线上接收的信息，完成计算并输出控制信号。传输协议的本质即：不同硬件之间交换数据时遵守的一套规则，其区别无非体现在编码格式、物理线缆要求、噪声抑制等方面。

1. CAN（Controller Area Network）控制局域网

其中最为典型的是由Bosch于1983年开发的CAN总线，其是一种共享式双线串行总线。1991年奔驰W140成为第一台搭载CAN总线的量产车型（当年的虎头奔，真正的“大哥车”），而后CAN总线逐渐成为事实上的车载通信主干网标准，为Bosch带来了丰厚的利润。在此基础上Bosch开发了速度更快的CAN-FD（现行的主流车载网络）、CAN-XL（~10Mbps）。

2. LIN（Local Interconnect Network）局域交互网络

LIN总线属于低成本的串行总线，尽管其带宽不到20Kbps，但能够在满足一些对带宽要求不高的应用基础上有效降低成本，与CAN形成互补。

3. Flex Ray

Flex Ray和CAN一样属于共享式总线，比CAN拥有更高带宽，但成本很高，只用于豪华品牌的线控系统中。

4. MOST（Media Oriented Systems Transport）面向多媒体的通信

MOST是2001年德国制定的面向汽车多媒体的通信标准，其物理层可采用光纤传输，拥有高带宽、低干扰、低衰减的特性。但其扩展性差，成本高，普及性不好，也仅仅用于豪华车型中。未来，甚至目前汽车多媒体通信也已经是车载以太网的天下了。

5. LVDS（Low Voltage Differential Signaling）低压差分信号

LVDS成本较低，带宽可达850Mbps。但自身抗干扰性差，为满足车规级的抗电磁干扰需求，其线缆屏蔽层较厚重；其次LVDS属于点对点的图像传输技术，扩展性很差。

6. 车载Ethernet

车载以太网是在消费领域以太网技术基础上发展而来，其在数据链路层和网络层的协议已经十分成熟，主要是在物理层进行优化，以适应车规需求。车载Ethernet的基本架构依然是MAC + PHY芯片 + 传输链路。主要有100M（BroadR-Reach、100Base-T1）和1G（1000Base-T1）。

车载以太网在单对单对非屏蔽双绞线上可实现 100 Mbit/s 甚至 1 Gbit/s 的数据传输速率，同时满足汽车行业高可靠性、低电磁辐射、低功耗、带宽分配、低延迟以及同步实时性等方面的要求。当前随着汽车自动驾驶、智能座舱、车载娱乐应用的发展，数据传输的带宽需求爆炸式增长，例如当前新势力品牌安装的多个相机、激光雷达在运行时会产生相当可观的数据流量，车载Ethernet也将在其中发挥重要的作用。

100Base-T1的基本架构

各传输协议的对比如下：

CAN-FD 2011 双绞线 5Mb 低 动力、底盘控制

车载网络通信的对比

讨论：车载以太网是否会取代低速的CAN、LIN总线？

目前（2022年）倾向于不会取代，汽车不同设备之间、不同场合下的通信需求也不同：有的需要高带宽，有的需要高可靠性和抗干扰，有的则是便宜够用就行。

采用何种通信网络，无非是基于速度、安全性、成本、扩展性等因素的考量。目前（2022）流行的几种标准还不存在取代关系，而是互补关系。比如动力、底盘等系统的控制数据量并不会很大，但对实时性、可靠性、确定性的要求很高，使用CAN总线即为合理的选择；对于车辆上大量的简单执行机构，如车灯、门锁、座椅控制，慢速LIN接口则完全够用，犯不上使用高成本的方案。而对于自动驾驶和智能座舱，则只有Ethernet能够负担海量数据的传输。

因此，当前基于域控制器的EE架构下，网络拓扑设计会将以太网作为主干网，连接各个域控制器。各域控制器子网会用到CAN，LIN等传统网络。当然，不排除以后的Ethenet会加入实时性保障，或许会彻底将传统的网络架构替代。

2.3 车端算力的升级

2.3.1 厂商特点

汽车电子领域另一显著的变化就是芯片算力的升级，这主要由自动驾驶域和智能座舱域推动。而车用高性能芯片的供应商主要是消费级半导体公司如Nvidia、Intel (mobileye)、AMD、高通、华为等厂商（显然，这些企业在高算力芯片上的技术积累更加深厚），也有地平线、黑芝麻等专门生产车用芯片的中国初创企业。当前几乎所有整车厂、Tier1都开始采用这类企业的高算力芯片来搭建自动驾驶和智能座舱域控制器。

原有的几大汽车半导体厂商德州仪器TI，恩智浦NXP、瑞萨、英飞凌Infineon、意法半导体等主要生产传统EE架构下的MCU芯片，在新兴的汽车高算力芯片领域的建树则乏善可陈。当然，但这也不代表其在未来不会有高算力产品，更不代表其无法生存，毕竟整车需要的半导体器件还有许多——如各种传感器芯片（视觉、超声波、毫米波雷达、激光雷等传感器芯片，以及传统的力、位移、温湿度、气体传感器芯片）、电池包管理BMS芯片、车内通信芯片、驱动芯片（尤其是功率半导体IGBT）等。这都属于偏向工业领域的芯片，而消费级半导体公司基本不太会染指这一领域。

与消费级芯片相比，车规级芯片的工况更为严苛，对安全性和寿命的要求也更高，需要符合一系列的标准（如ISO26262、AECQ100、ISO16949等）。当然，车规级芯片在功耗控制、散热、尺寸方面宽容度相对比较高，因此开始涉足汽车领域的半导体公司需要基于这些需求去进行一定的优化。

2.3.2 自动驾驶域芯片

AD域在具备高算力的同时也需要具备安全性和可拓展性。因此当前汽车芯片基本采用异构多核的系统级SOC（System on a Chip）——即在单一芯片上集成CPU、GPU、MCU、ISP、DSP、AI单元、存储器、视频、音频处理器、通信模块等模块，这其实在目前的手机、电脑等消费电子领域已经很常见。

AD域芯片大致包含了：控制核心、计算核心以及AI核心，其中：

过去几年AD芯片出货量比较大的是Mobileye，其采用纯视觉方案 + 基于ASIC的芯片架构，将算法写死在了芯片内。这意味着ME交付的是一个“黑箱”，整车厂无法对算法进行任何的更改和定制，更不用说进行后续的OTA升级。理想One、极氪001在开发过程中整车厂都深受其苦：理想one想要通过mobileye的摄像头对道路数据进行采集，并对算法进行训练，但ME的封闭性不允许，理想最终只好另加了一颗摄像头。

理想One：左侧为行车记录Camera，右侧为ME摄像头

而Nvidia、地平线在AI核心上采用GPU实现，支持软硬件的解耦，整车厂可以基于硬件移植自家的自动驾驶算法，并支持算法的改进和OTA，这种开放性对整车厂是十分友好的。当然，地平线也提供自动驾驶算法支持，如理想汽车在开发过程中地平线派驻团队在幕后做了许多工作。正因如此，Mobileye的ASIC方案逐渐式微，大部分客户流失（如蔚来、宝马等）。尽管Mobileye在Eye Q5上提供了开发的SDK，但这种开放程度仍然是有限的。

2022年Nvidia最新量产的Orin芯片算力可达254TOPS（价格也高达500美元），蔚来ET7采用4片Orin芯片自研了AD域控制器，算力被堆到了1000TOPS以上，这个算力预埋基本可以满足未来几年的算法迭代需求。

2022年3月的GTC大会上，Nvidia发布了AD芯片Altan，其单片算力就突破了1000TOPS，而9月的秋季GTC上，则又发布了Thor取代了Altan，将算力堆到2000Tops，预计2024年上市。这很大程度上为L4、L5级别的自动驾驶解决了算力问题。

Thor 2024 / /

Nvidia Orin SOC芯片架构

地平线征程5芯片架构

2.3.3 智能座舱域芯片

对于早期的座舱系统，可以粗略理解为将手机 /平板移植到了车机中，并进行了一定的拓展，比如苹果Carplay将手机投影到汽车频幕上即可替代部分车机功能。但当前智能座舱的功能已经大为拓展，当下其发挥的功能有：

座舱内大多数电子元器件的协同，如液晶仪表、中控（包含驾驶模式、空调、除霜等控制）、副驾娱乐屏、HUD等；

车内外摄像头识别、语音识别；

车载APP（包含导航、音乐、收音机等）、远程车控、OTA升级的数据传输等；

一些车型的智能座舱芯片甚至兼顾辅助驾驶功能，比如自动泊车、盲区监测等。

不过，从芯片角度看，手机芯片和智能座舱芯片的硬件、软件架构并无太大区别，许多手机领域的技术可以迁移到智能座舱，笔者认为当前的智能座舱有点像一个大号的、外设更为丰富的智能手机。这也是当前大量整车厂的座舱芯片都开始由TI、瑞萨等传统企业迁移到了高通、三星等手机芯片企业。

例如，高通最早的座舱芯片820A就是手机的平移版本，目前几乎所有新势力企业和传统企业的高端车型都采用了高通的8155芯片，而最新的8295芯片也几乎将配置堆到了一个很高的水平；大众、奥迪的纯电车型采用了三星猎户座汽车芯片，其硬件素质同样很强（2022年的情况，尽管其软件能力较差导致车机系统拉跨，未能发挥出芯片的应有水平）；华为的麒麟990A其实也就是990的车规版本。

在功能安全方面，座舱领域对于行车安全的影响其实并不大，只需要达到ASIL-B级别即可，例如就算车机黑屏卡死也并不会波及油门、刹车、转向、灯组的基础控制（事实上很多汽车都会出现此类问题，消费者的抱怨也很多）。因此很多厂商甚至直接拿消费级芯片来做车机，比如并不急于推进智能化的比亚迪，在一些项目中直接采用更便宜的高通625、665芯片。

高通的Gen4座舱平台

3. 汽车操作系统（2022.08.01）

硬件平台的上一层就是操作系统，与PC、移动端的操作系统功能类似，汽车OS的主要功能是调度汽车的硬件、软件资源，并提供接口。在传统的分布式EE架构下，各ECU基本只处理某项单一任务，并不需要“分配调度资源”，所以也不需要高性能、复杂的OS，传统的实时操作系统RTOS搭配AutoSAR CP架构即可应对。

而到了集中式EE架构，许多驾驶相关的任务处理被集成在一个域控制器内；且随着自动驾驶的发展，由相机、激光雷达等感知器件产生的海量数据使得数据处理的复杂度极高；而智能座舱内部也存在极多的任务调度需求——此时硬件内必须要有一个甚至数个强大的操作系统才能handle上述任务。

这也就是本章要阐述的内容。

3.1 名词解释

3.1.1 实时操作系统与分时操作系统

日常生活中的PC和移动端设备乃至服务器采用的都是分时操作系统（Time-sharing Operating System，TSOS），例如常见的Windows、Macintosh、Android、IOS、Linux。TSOS一般采用时间片轮转的方式，由各个程序轮流使用CPU，不区分或较少区分任务的优先级。这种调度策略的优点是吞吐量极大，资源利用率高，对每一个程序都能保证足够快的相应时间。而反面则是无法保证某个程序能在某个时间节点之前完成任务。

而实时操作系统（Real Time Operating System，RTOS）的核心能力则是严格区分任务的优先级，保障重要程序的实时性，在高优先级的任务需要执行时，能在时间限制内抢占式切换到该任务上。换言之，提交给此OS的任务，其一定能在规定的时间节点前完成，并且能在规定的时间内来做出快速的响应。但反面是RTOS不能同时处理多个任务，硬件利用率较低。工业界常用的RTOS主要是QNX（Quick Unix）、VxWorks。

3.1.2 汽车OS的分类

显然，动力域、底盘域与车辆的底层控制，如加减速、转向等动作密切相关，可以类比为人类负责协调肌肉的小脑。系统需要在规定时间内完成指定动作，对实时性和功能安全等级有着极高的要求，因此必须采用RTOS。

而自动驾驶域控制器则需要根据传感器的输入做出决策规划，可以类比为人类进行思考决策的大脑。其需要具备高算力和高通信带宽，以满足图像、雷达的信号感知以及后续决策、规划算法的需求；其同样需要具备较高的实时性，否则也可能产生灾难性的后果。

智能座舱域则更大程度上与用户体验相关，并不直接参与汽车行驶的控制决策，对车辆行驶性能和安全影响较小。反而由于同时运行导航、语音识别、多媒体等应用，需要较大吞吐量，分时操作系统会更加适合。

由上此引出：汽车OS主要有基础控制OS、自动驾驶OS和智能座舱OS，其主要方案为：

这是目前业界的主流方案，例如之前百度的Robotaxi即在基础的动力底盘域采用QNX OS，而在自动驾驶域采用更改后的Linux系统。至于为何会采用此种方案，下文会逐步介绍。

并且，由2.3的内容可知，如果采用动力、底盘、车身、自动驾驶域的“一片式SOC方案”。那么就需要在负责车控的MCU部分运行Classic AutoSAR架构的RTOS，而在高算力部分运行POSIX标准的OS。在一片SOC上运行两套系统，就涉及到了硬件虚拟化技术Hypervisor（3.2节）。

Ref：

posix是什么都不知道，还好意思说你懂Linux？ - 知乎 (zhihu.com)

3.1.3 狭义OS与广义OS

自动驾驶车辆软硬件平台架构

再次祭出文章开头这张图，车载计算平台自下而上可划分为：

狭义OS指OS内核；而广义OS则包括了：硬件抽象层、OS内核、中间件、功能软件等硬件和具体应用软件之间的所有程序。

其实，对于绝大部分声称“自研OS”的厂商，都不会去重新研发OS内核，而是对开源的Linux内核进行一定的裁剪修改，重点开发的是中间件和功能软件。因此，下文所有的研发案例都指代此种开发模式。

3.2 集中式EE架构-自动驾驶域-系统软件

3.2.1 HyperVisor硬件虚拟化技术

由前面硬件章节可知，自动驾驶域采用了异构分布的硬件，而不同的应用程序，如AI计算以及基础的控制功能需要分别依赖不同的内核环境和驱动，而在物理层面共享CPU。要做到这一点就需要依靠硬件虚拟化技术。

早在1960s，由于大型机的价格十分昂贵，每个人不能拥有自己的电脑。因此一台大型机会进行分时，服务于多个用户（类似于前述TSOS的机制），可以理解为每一个用户获得了一台虚拟机VM，如此就是Hypervisor的雏形。

Hypervisor是一种运行在硬件和 OS之间的中间软件层，可允许多个OS共享硬件（这些OS可以是不同的OS），为每一个OS分配CPU、GPU、内存、存储等硬件资源，因此可以理解为一种“虚拟机管理器”。

Hypervisor技术的应用相当广泛，比如个人电脑使用VMware、VirtualBox实现双系统，一些企业直接使用虚拟机替代电脑终端，以及开发中使用的Docker/容器也是Hypervisor思想的延申。

Hypervisor的架构与演化，来自知乎用户“木头龙”

尽管这一技术已经诞生并发展多年，不过在近几年才刚被应用到了嵌入式领域。当前主流的嵌入式硬件虚拟化技术厂商有两家：

3.2.2 BSP（Board Support Package）板级支持包

BSP是介于主板硬件和OS之间的系统软件之一，主要是对OS提供支持，使之能更好的运行于硬件主板。不同的OS对应的BSP的形式也有所不同，例如VxWorks和QNX的BSP相对于某一CPU来说实现的功能一样，但写法和接口定义可能完全不同。

开发车载芯片BSP的厂商较多，芯片制造商（高通、Nvidia）、第三方软件厂商（东软睿驰、德赛西威）、整车厂（比亚迪、毫末等）都会参与。

3.2.3 自动驾驶的OS内核

OS的内核是操作系统最为底层的部分，这才是如《操作系统》课程所讲授的那样，负责管理系统进程、管理内存、设备驱动程序、文件和网络系统，提供最基本的功能。在OS内核上一层是中间件Middleware，充当OS内核与应用程序之间的桥梁，这在下一节会讲到。

自动驾驶领域的OS内核主要是QNX、Linux、Vxworks这三种（其实Vxworks主业在航空市场，汽车产业内基本是凑数的，主要还是前两种）。如前文所提，几乎没有企业会开发全新的OS内核，市面上所有“自研OS”的内核仍然是QNX或Linux。

内核的实时性

还是根据前面的描述，OS可分为实时OS和分时OS，出于功能安全需求，自动驾驶需要实时OS。在工业界广泛应用的QNX、Vxworks属于实时OS，但原生的Linux却是分时OS，因此需要对Linux进行改进，才能满足自动驾驶域的实时性需求。当前的Linux是支持内核抢占式调度的，使用Linux CONFIG_PREEMPT_RT补丁可使得Linux实时性大为改善，成为实时OS。但这仍然不足以满足自动驾驶的需求，还有很多其他的优化项，具体可以参考：

微内核与宏内核

QNX和Vxworks都是微内核架构，即OS内核只包含了最基本的任务调度和内存管理，驱动和文件系统都是通过用户态的守护进程实现。其优点在于稳定性极高，驱动的错误也只会导致相应进程死掉，不会导致整个系统的崩溃。其缺点在于OS的效率较低，难以应对高算力、高吞吐量的任务。

而Linux则是宏内核，将进程、线程管理、内存管理、文件系统，驱动，网络协议等等都集成在内核里面。其优缺点正好和微内核是反过来的：优点是效率更高，能发挥硬件性能，而缺点则是稳定性差。

开源&非开源

QNX是半封闭的OS，客户是不能改动其内核的，只能在其基础上开发中间件和功能软件，当然还要给Blackberry交授权费用。但QNX的优点在于其架构简单（毕竟也只有30万行代码，复杂度低），通过了ISO26262 ASIL-D认证，拥有很好的安全性和稳定性，也因此目前其占据了汽车驾驶域操作系统 50% 以上的市场份额。

Vxworks属于开源的OS，其由400多个相对独立的目标模块组合而成，用户可以在其基础上进行增加、删减，但其开发生态较为贫瘠，且开发过程同样需要给Wind River交授权费。

Linux也是开源的，并且其生态非常丰富，可扩展性极高，用户也有着最大程度上的自主权。但Linux现有数千万行代码，组件更多，官方承认的bug有上万个。其复杂性使得基于Linux的开发难度极高，系统运行的稳定性更差，潜在安全风险更高，通过ASIL-D认证的难度也会陡然上升。

在软件能力较强的厂商面前，如华为、Tesla等，相较于Linux带来的优点，其风险和代价则是完全可以接受的。例如，Tesla当前的自动驾驶OS内核即为基于Linux进行裁剪后的版本；据不可靠消息，华为在研发自动驾驶OS也是基于Linux内核开发。目前蔚来的自动驾驶OS应该是基于QNX开发，但这只是暂时的，后面的研发应该会基于Linux进行。大众正在开发的VW.OS是基于AUTOSAR Adaptive，意欲将Linux、QNX和VxWorks多个底层内核整合到一块。但由于缺乏本土软件人才，很多代码工作外包，导致开发进展缓慢。

下面则是三种OS内核的对比信息：

生态 较丰富 非常丰富 较贫乏

3.3 基础车控OS、自动驾驶OS、智能座舱OS

回到本章开头汽车OS的分类以及方案：（下表的“低”、“高”是相对而言，事实上车用的软件标准都比消费级/ C端的高一大截）

POSIX标准OS、AutoSAR-Adaptive

基础控制OS

对于底盘、动力等基础控制域，是完全不能容忍任何的非实时性和不稳定因素的，但其对于算力、通信带宽其实并无太高要求。因此继续使用QNX、配合AUTOSAR CP平台即为最合理稳妥的方案。（AUTOSAR也是反复提到，后面会详细介绍其概念）

自动驾驶OS

自动驾驶域对操作系统的要求是最为严苛的，既要满足庞大数据处理和众多上层应用所需要的高性能、高吞吐量、高扩展性，还要满足功能安全所需的高实时性、高稳定性，这两种需求某种程度上是互相矛盾的。

而能够同时满足这些需求的，基本只有基于Linux开发的自动驾驶OS。也因此，随着自动驾驶的深入发展，Linux的市场份额必然会越来越大。而提升其实时性，实现功能的基础上保证其可靠性则是其研发的难点。

案例：AGL（Automotive Grade Linux）是一个协作性开源项目，它将汽车制造商，供应商和技术公司召集在一起，以加速开发和采用针对互联汽车的完全开放的软件堆栈。AGL 以 Linux 为核心，正在从头开始开发一个开放平台，该平台可以用作汽车OS标准。

AGL 早期主要为丰田、本田、日产等日系厂商，随着 2019 年大众、现代汽车的加入，AGL 势力规模逐渐壮大。截至 2020 年 3 月，国内已有中国移动、上汽集团、德赛西威、中科创达等公司加入了 AGL，成员总数超过 150 个。

智能座舱OS

从需求侧来看，智能座舱OS与基础控制OS的需求恰恰相反：其对性能和带宽的需求极高，但对实时性和稳定性的需求则没那么严格。因此，目前智能座舱系统一般是也是基于Linux或者Andriod来开发（安卓其实也是基于Linux衍生而来）。

Linux/Android在移动端构建的丰富生态可以较好的移植到车端，其改造难度远小于自动驾驶域。不难推断，互联网基因的厂商、移动终端厂商在此领域具备较大的优势。比如阿里AliOS、斑马OS、百度小度车载OS、蔚来 NIO OS、小鹏 Xmart OS 等座舱系统基本是基于Android进行定制化改造而来。

4. 自动驾驶系统中间件（2022.09.23）

本章会提到很多名词缩写，其互相之间存在衍生关系。为了避免读者产生混乱，先将其关系框图给出：

本章介绍内容的关系

4.1 中间件概述

4.1.1 中间件的概念：

名称：处在OS内核的上一层、功能软件的下一层的软件就是中间件(middleware) ——其名称也是这么来的。中间件和Hypervisor、BSP一样在计算机分布式系统中已经发展了许多年，也是最近几年被应用到了汽车领域。

功能：简而言之就是解决共性需求。展开讲：服务于上层的应用软件，充当底层OS和上层应用之间的桥梁：对下，它能够适配不同的OS内核与架构；对上，它能够提供统一的标准接口、库以及配置方法，负责各类应用软件之间的通信，以及对底层系统资源的调度和执行管理——事实上，中间件90%以上的功能就是数据通信；因此其狭义称呼就是 “通信中间件”）

中间件是车载硬件平台和软件解耦的关键角色：通过中间件提供的统一接口，开发人员可以专注于业务层面，而不需要去定义数据通信格式、发送方和接收方，也不需要调用OS接口，设计通信、安全、资源调度等与业务逻辑无关的底层内容，避免重复造轮子，进而提升开发效率以及代码的可移植性。例如，在自动驾驶的感知模块，开发人员只需要关注目标的分割、检测、追踪算法，与外界的数据交互只需要使用中间件提供的通信服务即可，如订阅Camera、Lidar、Radar的数据，发布数据感知的结果。

4.1.2 中间件的需求：

那么，从自动驾驶的需求端出发，来看看自动驾驶需要什么样的中间件：

1. 中间件的通信的模式：

显然，发布/订阅模式的中间件更能够胜任自动驾驶软件系统的需求，而后面要介绍的SOME/IP和DDS都是支持该种模式的通信标准；

2. 通信中间件应当包含：

数据类型规范语言IDL：即类似于Protocol buffer、XML、JSON的数据交换格式，其独立于编程语言和平台，对传输字段的名称、顺序进行了预定义。比如CyberRT即采用了Protobuf；

消息传递系统：在不同进程之间传递消息，要求低延迟，消除对中央通信的依赖。比如CyberRT采用了开源的DDS作为消息传递系统的底层；

日志/ 回访工具和实时分析工具：简化开发、调试；

4.2 底层通信协议与实现：DDS、SOME/IP、ICEORYX

许多文章说：“DDS、SOME/IP可以作为自动驾驶中间件”，笔者认为这是一种模糊、不精确表述。事实上，DDS、SOME/IP本质上都是通信协议，而基于此类标准，可以开发中间件的底层消息传递系统；

4.2.1 SOME/IP 以服务为中心的通信

1. 基础概念：

SOME/IP的全称是：Scalable service-Oriented MiddlewarE over IP——基于IP通信的、面向服务的、可扩展的网络传输协议，其可以实现前述的发布/订阅模式的通信，通信速度可达1000Mbps。SOME/IP最早由宝马在2012-2013年开发，并在2014年集成进AUTOSAR-CP 4.2.1中。

2. 特性解读：

对于SOME/IP标准，其英文全称蕴含了其主要特性：

3. SOME/IP的报文结构：（补充）

SOME/IP是基于TCP/IP的应用层协议，那么，其单个报文的总长即为1500B。

SOME/IP的报文结构

4. 支持的数据类型有：

bool、uint8、uint16、...sint8...float32、float64、str等常规数据类型；

struct结构化数据；

array数据；

5. 消息格式：一共有3种消息格式

6. 消息通信类型

6. SOME/IP 标准的具体实现

前面提到，SOME/IP是一种技术标准，而只要基于该协议的产品就可以进行互操作。当前主要的商用版本SOME/IP产品供应商是Vector（也是Autosar工具的主要供应商）。开源版的SOME/IP主要是vsomeip，由BMW实现，目前由COVESA互联汽车系统联盟维护（可见下方github）。SOME/IP在2013年被收录到了AUTOSAR4.1中（CP），AP同样支持该协议。

在具体应用上，SOME/IP可以作为AUTOSAR中的一个通信模块，也可以集成到POSIX操作系统中作为独立的lib存在；

SOME/IP的存在形式

当然，想要成为一个完整的中间件，还需要数据序列化的机制、接口定义语言（IDL）形式、数据传输的连接管、如何调度RPC请求、以及软件编程接口等。

4.2.2 DDS 以数据为中心的通信

1. 基础概念与特点：

DDS，全称Data Distribution Service 数据分发服务，是由对象管理组织OMG制定的以数据为中心的、分布式的、采用发布/订阅模型的、实时通信中间件协议。

DDS各分布式节点在逻辑上无主从关系，而是对等关系（此与ROS中使用master节点非常不同），因此可靠性、安全性都会更高；

在计算机网络模型中，如同SOME/IP，DDS也是在TCP/UDP之上的应用层协议；

通信方式：可以是点对点、点对多、多对多等，在QoS的控制下建立连接，自动发现和配置网络参数；

提供多种QoS服务质量策略（见4.4.3节）；

特点：跨平台、低延迟、高可靠、通信解耦，通常会绑定如protobuf等数据序列化工具；

DDS在网络模型中的位置

DDS的通信方式

2. DDS的通信模型

如前述，DDS采用了以数据为中心的发布/订阅模型（DCPS,Data-Centric Publish Subscribe）。意思是用户只关心自己想要的数据，数据通过Topic进行标识，发布者根据Topic发布数据，订阅者则根据自己感兴趣的主题来订阅数据。仅当Client请求或Server通知订阅者时候，才会交换数据，如此降低了网络占用。

如果读者使用过CyberRT中的 “话题通信”，则会有更为直观的感受：

采用Protobuf定义结构化的信息，例如命名为“Lidar”；

定义数据发布方talker发布“Lidar”话题的数据包；

数据接收方根据“Lidar”话题接收到相应的数据报；

数据时间空间的解耦

3. DDS的具体实现

商用DDS：RTI

当前商用的DDS方案主要是美国RTI（全称Real-Time Innovations）的 Connext DDS。RTI作为OMG组织的董事会成员，主导了DDS标准的建设工作，也因此占据了约80%左右的商用DDS市场份额，例如理想汽车即采用了RTI的DDS产品。

开源DDS：OPEN DDS、FAST DDS、Cyclone等

RTI原核心团队成员在欧洲创办的eProsima公司推出的FastDDS，尽管开放源代码，但商用仍然可以要向eProsima付费获得技术支持；OpenDDS和FAST相似，两者都是基于RTPS（real Time Publish Subscriobe）实现的；一般多种DDS可以相互通信，例如提到的FAST DDS、OpenDDS、Connext DDS。

在应用上，ROS2和CyberRT都采用了开源的DDS，可以说DDS是其最为核心的通信机制。而现在的自动驾驶芯片如Xavier、Orin也都预留了DDS接口。

基于DDS在自动驾驶中间件中的广泛应用，2018年DDS被引入了AUTOSAR AP。

4.2.3 DDS与QoS

1. 概念：

DDS的一项重要特性是支持QoS（Quality of Service，服务质量）。QoS指的是通信网络利用一些基础技术，为网络通信提供更好的服务。

例如，网络发生拥塞时数据流可能发生丢弃，而在这个时候，具备QoS的网络就可以根据用户的需求来分配资源，对不同的数据流提供差异化的服务质量：对实时性强、关键的报文优先处理；对于实时性不强的、不重要的报文处理优先级则比较低，网络拥塞时甚至丢弃。

因此，针对某一类数据，在QoS中可以设置其传输优先级、数据可靠性、资源限制、事件过滤等特性，并使用设备提供的各种优先级转发策略、拥塞避免机制来为一些数据流提供更高的保障。

2. 案例：

数据传输中会出现丢帧现象：如果是关键信息（报警指令），我们需要发送方重发，如果是非关键信息（如Camera的高频传感数据），系统就不必把丢失的部分都找回来，这些都只需配置QoS的Reliability选项即可。

Kind = RELIABLE：重发；

Kind = BEST_EFFORT：不重发。

感知系统有冗余时：如果一个传感器宕机，就需要第二个传感器补上来。针对这种情况，QoS可以配置一个ownership，对两个传感器的数据做优先级高低的区分。然后就可以按照最新配置运行，完成不同节点之间的发布/订阅。

数据的生命周期：QoS也需要避免交付过期数据，通过设置参数Duration，发送方和接收方的时钟同步，那么接收方即可通过接收时间戳信息计算出该数据已经失效。

3. 优点：

QoS能够提供RT系统所要求的性能、可预知性，合理分配利用网络资源；

保证发布/订阅模型的模块性、可量测性和鲁棒性；因此，DDS能够满足复杂、灵活的数据流要求。

如下图则是开源DDS支持的20余种QoS

开源DDS支持的22种QoS

4.2.4 SOME/IP和DDS对比

1. 面向服务 or 面向数据：

SOME/IP其将数据打包成了Service，之后消费方向服务提供方订阅服务中的事件组。而DDS则是直接以数据为中心进行发布/订阅，可以看出DDS要比SOME/IP更加直接。

2. 耦合性：

SOME/IP中，在数据传输前，Client需要与Server建立网络连接并询问server是否提供所需服务。因此节点间仍然有一定耦合性。而在DDS中，订阅方或发布方只需要在自己的程序里面订阅或发布数据就可以，不需要关心任何连接，因此订阅方和发布方的解耦更加彻底。

3. 服务策略：

商用的RTI DDS则可以提供50多个QoS，开源的DDS也可以提供20多个，这基本能够覆盖到自动驾驶场景对通信的需求。而SOME/IP仅解决了发布/订阅问题，由于仅有一个可靠性的QoS，原生SOME/IP注定无法解决诸如“数据量大时丢包”等问题，就需要开发人员来编写QoS，重复造轮子。

4. 总结对比如下：

当然，尽管看起来DDS与SOME/IP是直接的竞争关系，且DDS相比SOME/IP有很多优点，但最终还是需要看具体应用场景。具体可见Ref。

4.2.5 Iceoryx 开源共享内存技术

1. 共享内存的需求

问题：在自动驾驶领域中，Camera、Lidar等传感器会产生大量的数据，而一般不止一个应用会订阅感知硬件产生的信息——如此数据传输量会轻松达到Gb/s的级别，进而占据很大通信资源，造成通信效率的隐患。

解决：减少数据的copy次数，仅需要保留一份原始数据，然后传递其指针给其他应用即可——即所谓的“零拷贝共享内存通信（Zero copy shared memory）”。当然此过程中需要注意互斥，避免同时占用。

（这让我想起我读研时候捣鼓工业相机，一开始比较愚蠢的用两个for循环来拷贝像素信息，直接让程序速度慢的像蜗牛爬。后来才想起来将相机buffer指针直接传给算法，速度就快了很多。）

2. Iceoryx

2020年7月，Bosch推出了用于自动驾驶的中间件技术Iceoryx (冰羚)，其基于共享内存实现了进程间（即不同应用）的通信。iceoyrx可以使用互斥锁，对OS内存操作、同步机制进行封装，实现了零拷贝通信，极大减少了应用层在数据传输中的资源占用。其特性有：

开源，提供相应的分析工具和开发案例；

信息传输的延迟小于 1 微秒；

可应对 GB/s 的数据传输需求；

支持多种操作系统（Linux、QNX、macOS、Win10、FreeBSD）、通信模式和 API（C、C++）；

可与AUTOSAR、ROS集成，移植方便；

基于静态内存和 lock-free 算法的实现；

具备Buffer的管理机制和流量控制；

3. Iceoryx工作过程

iceoryx会预先开辟一些内存块，称之为chunk；

通过其API，publisher可以将信息写入由中间件预先制定好的chunk中；

publisher将数据写入chunk中；

subscriber通过指针到chunk获取信息，当chunk中被写入数据时，订阅相应topic的subscriber就会收到一个指针，不同的subscriber可以订阅同一个topic信息，它们彼此并不知道对方；

iceoryx知道每个chunk对应的subscriber订阅记录，每增加一个subscriber读取信息，对应的reference就 +1，如果一个subscriber不再消费，reference 就-1，如果reference没有人订阅了就被置为 0，然后就被后台重置回收，避免造成资源浪费。

4.2.6 MQTT（Message Queuing Telemetry Transport，消息队列遥测传输）开源

由IBM开发的即时通讯协议，也采用发布/订阅模式。其延时控制交叉，QoS也较少，因此并不适用于实时性强、速度需求高的项目，仅适用于低带宽、不可靠传输的网络场景。

在自动驾驶领域，MQTT比较典型的应用场景是V2X。 终端通过TCP链接云端，云端通过主题方式管理各个设备关注的通讯内容，负责消息转发。

4.3 中间件产品：ROS2、Cyber RT、Apex.OS

对于QNX、Vxworks这类RTOS，Blackberry、Wind River都会为客户提供定制的中间件。而我们要讨论的是热点的基于Linux的自动驾驶中间件。前面提到，ROS2和CyberRT底层都使用了开源的DDS，将其作为最核心的通信模块，然后添加了其他的调度、控制模块。

那么ROS2和CyberRT当然其实可以作为自动驾驶的中间件产品。当然，ROS2主要服务的还是机器人行业，Apollo CyberRT则是专精于自动驾驶。市场上也有很多公司提供自己的自动驾驶中间件方案，比如美国的Apex公司基于ROS2开发的Apex.OS，再比如东软睿驰的中间件产品NeuSAR。

本章会对这些中间件产品进行简要介绍，但并不会介绍太多这些中间件的原理、架构，如此一来就会篇幅过长且偏离主题，感兴趣读者可以自行学习，ROS2和CyberRT的资源非常丰富。

4.3.1 ROS2 - 开源

1. ROS的缺点

首先从ROS说起，ROS是机器人操作系统（Robot Operating System）的缩写，原生的ROS并不能直接满足自动驾驶的所有需求：

首先ROS是非实时的系统，这对于自动驾驶是完全不可接受的；

ROS通信体系可靠性较低，其采取中心化管理模式，各节点通信依赖ROS Master作为中转，如果其被劫持则会导致整个通信失效；

ROS的计算调度效率低下，ROS分散为大量独立进程，集成度低。CPU、GPU以及内存资源全部由各模块抢占，缺乏全局的分配调度系统；

中心化的通信节点

当然，不可否认ROS是一款非常优秀的开源机器人操作系统，其易用性和丰富的资源大大缩短了自动驾驶前期开发验证的事件。但对于量产阶段，ROS则力不从心。

2. ROS2的改进

这对于上述缺点，ROS2做出了相当多的改进，使之能够作为自动驾驶的中间件。具体地：

当前来看，ROS2的主要缺点在于成熟度较低，其资源也相对不足。

去中心化的通信节点

4.3.2 ROS2的商业化：Apex.OS

即使ROS2采用DDS，改善了ROS的许多缺陷，但ROS2本身仍然并非面向工业量产项目而设计，其自身带有较为浓重的“面向科研”、“面向原型设计”的色彩。最直观的例子就是：ROS2仍然是一个非实时的中间件。

而当然，只要能够基于自动驾驶的需求，基于ROS2进行开发，补足其缺点，那么就可以使其称为合格的自动驾驶中间件。最有代表性的就是美国Apex研发的Apex.OS，补齐了ROS2的实时性以及功能安全的短板，使得Apex.OS最终通过了ASIL-D认证。

4.3.2 Apollo CyberRT 开源

在百度的Apollo早期版本中，其通信中间件使用的是ROS（做了裁剪，打了补丁）。显然工程师们在使用过程中也发现了前述ROS存在的弊端，而彼时还没有基于DDS的ROS2。于是在Apollo 3.5版本中，百度开发了基于开源DDS的CyberRT。

CyberRT相比ROS的升级包括但不限于：

Cyber RT删除了master机制，采用服务发现协议RTPS，每个rosnode都有域中其他节点的信息，消除了单点故障；

使用开源的Google protobuf封装成msg， 提供了良好的消息向前兼容性；

采用linux container轻量级虚拟化技术，把每个ROS Node 放入沙盒，限制每个ROS node 权限。节点与节点的通信消息可以进行加密解密处理，防止中间人攻击；

Cyber RT的核心设计将调度、任务从内核空间搬到了用户空间。

CyberRT对于想要深入理解自动驾驶中间件的从业者是非常值得尝试和学习的（ROS2其实也可以），对于其详细介绍，互联网上资料很多，这里不过多介绍。

5. 自动驾驶底层OS与中间件的标准化

名词辨析：在许多文章中，都会看到把ROS2、AUTOSAR、CyberRT并称为“自动驾驶中间件”。但其概念是存在差异的：

ROS2和CyberRT都是使用了开源DDS的中间件产品，有着完整的代码实现；是直接可以拿来用、或者修改的产品；

而AUTOSAR则是一套标准，定义了一系列平台组件、以及对上层应用的标准接口；但并没有定义具体实现细节，也没有定义平台组件之间的交互接口；

供应商根据AUTOSAR的标准各自去实现具体的代码，然后就可以称他们的产品为“符合AUTOSAR标准的中间件”；

至于为啥非得搞一个AUTOSAR的标准：一来的确汽车的软件系统太复杂，需要有所规范；二来其实这也是巨头利用标准进行垄断的一种方式。

5.1 OSEK/VDX标准的OS - 分布式架构

首先，简要介绍自动驾驶时代之前整车的OS标准：

如第2节所述，在传统的分布式EE架构下，ECU 一般用来处理特定功能。因此，其运行过程相对简单，并不需要复杂的OS实现资源调度和分配，但出于功能安全考虑，对实时性和稳定性的要求很高。因此，分布式EE架构的MCU中，一般运行的是符合OSEK/VDX和Classic AUTOSAR标准的嵌入式RTOS。

1993年，德国汽车工业界提出了OSEK - Offene Systeme and deren Schnittstellen fuer die Elektronik im Kraftfahrzeug 车载电子设备的开发系统和接口。主导的厂商还是熟悉的那几家：BMW、Daimler、Siemens、VW、Bosch等。而法国的标致和雷诺于1994年加人OSEK体系，并将法国汽车工业所使用的汽车分布式运行系统（Vehicle Distributed eX-ecutivr, VDX）也纳人这一体系。

1997年，OSEK/VDX规范正式发布，其主要由操作系统规范、通信规范、网络管理规范、实现语言四部分组成（当然这个时候也不需要什么中间件）。基于此规范，各嵌入式OS厂商都相继推出了符合OSEK规范的产品，典型的有：

符合OSEK/VDX标准的典型车控OS

5.2 AUTOSAR CP - 分布式架构

2003年，全球汽车巨头VW、Toyota、Ford、Bosch等组建了AUTOSAR联盟，旨在建立一套开放式的汽车系统架构标准（Automotive Open System Architecture）。AUTOSAR继承了OSEK/VDA的成果，CP AUTOSAR中的操作系统即发展自OESK/VDX标准，还继承了其通信和网络管理部分，可以认为OSEK/ VDX包含于AUTOSAR中。

很多文章对AUTOSAR的介绍十分抽象，看几遍仍然让人搞不明白它究竟是干啥的。AUTOSAR的核心思想主要是：

AUTOSAR CP架构：AUTOSAR CP是涵盖了底层OS+中间件的一套完整标准

多年来，越来越多的整车厂、Tier1、以及下游的芯片制造商、软件供应商都加入了AUTOSAR联盟。在分布式EE架构时代，AUTOSAR也成为事实上的汽车软件架构标准。而随着辅助驾驶/自动驾驶以及集中式域架构的发展，算力和通信带宽需求急速上升，多核异构的SOC代替原有ECU，原有的AUTOSAR架构基于CAN通信设计，无法兼容Ethernet，也不能支持GPU/FPGA/APU等处理器，因此已经无法满足业界需求。

2013年开始，AUTOSAR的更新就越来越少，主要是一些维护工作。联盟开始设计新的标准AUTOSAR Adaptive Platform，而原有的标准后被称为AUTOSAR Classic Platform，二者互不兼容。

5.3 AUTOSAR AP - 域架构

2018年，AUTOSAR联盟推出了Adaptive Platform。不同于AUTOSAR CP包含了OSEK标准的OS，AUTOSAR AP的范围限制在“跑在Linux、QNX等POSIX标准OS上的中间件”，其并不包含OS。

AUTOSAR AP的主要特点是：

POSIX操作系统：采用基于POSIX标准的操作系统，可为支持POSIX标准的OS以及不同的应用需求提供标准化的平台接口与应用服务。

集中式域架构：将整车软件平台分为三类，即传统车控、自动驾驶、信息娱乐；

通信模块：DDS、SOME/IP被引入了AUTOSAR AP标准当中；

这里不会对AP架构过多展开介绍，感兴趣可自行学习，总结AUTOSAR Classic和Adaptive平台的区别如下：

操作系统 AUTOSAR OS（OSEK） 符合POSIX规范的OS

和CP的思想一样，AP的具体实现也是AUTOSAR成员各凭本事。当前，市面上有代表性的量产AUTOSAR AP供应商如有：

当前AUTOSAR AP还不够完善，仍然处于建设中，并不能完全取代AUTOSAR CP。如前面所说，负责动力、底盘控制的车控MCU仍然需要跑AUTOSAR CP，能够满足实时性和功能安全，其本身对算力的要求也并不高。

5.4 AUTOSAR 地位的讨论

AUTOSAR CP在过去的分布式EE架构时代下居于绝对的垄断地位，芯片厂商和Tier1基本标配AUTOSAR CP，整车厂也几乎没有选择余地。其收费模式也比较粗暴——每有一个MCU跑AUTOSAR标准的系统，就收一套lic费用，如此一来，多ECU的车型成本就会很高。

好处就是基本不用担心软件会出问题，工程师按照需求进行配置即可，研发周期相对短；

坏处就是车型还没量产，就需要数千万的资金，前面提到，AOTOSAR标准的其实也是行业巨头进行垄断的一种方式，所以非AUTOSAR核心成员的OEM对此是很不满的；

但在自动驾驶和集中式EE架构下，AUTOSAR AP是否还能维持CP平台的地位？目前，AP平台已经继承了不少CP平台的缺点：使用成本高（授权费用高、人员学习成本高）、标准与代码臃肿、暂不支持车路协同场景（通过MQTT、Kafka等中间件实现）。

更关键的是，许多软件能力很强的汽车厂商，如特斯拉、国内的蔚小理，都并不在意，甚至非常乐意在软件上亲力亲为。这些企业必然很乐意基于ROS2、CyberRT来做开发，而不用采购符合AUTOSAR的方案，这已经是目前的大趋势。

笔者个人以为：AUTOSAR的未来可能和OSI的网络七层模型有点像——这一套理论有着很多值得借鉴学习的地方，但并不代表市场会100%按照其标准行事。吸取其架构中精华的部分，然后各自建设自动驾驶中间件。

6. 功能软件 & 自动驾驶框架 （等我学完Apollo在回来施工）

中间件很大程度上解决了上层应用和底层OS之间沟通的问题，而中间件的上一层则是功能软件，包含了实现自动驾驶的核心功能模块：如算法的编程框架（TF、Caffe等）。更进一步地，将自动驾驶APP开发所需的公共部分打包即形成了“自动驾驶开发框架”。在此框架中，传感器标定支配、感知融合、地图定位、决策规划、控制执行等部分都有标准的开发模式以及基础实现，可以更快速地完成APP开发。典型的开发框架有百度的Apollo、日本Tier V的Autoware。

6.1 Apollo——百度

6.2 Autoware——日本Tier IV发起

基于ROS和Linux所做的自动驾驶框架，可以作为学术研究使用，但ROS无法作为量产使用。

7. 功能安全：ISO26262 与 ASIL D 2022.08.24

7.1 概述

本文中所有提到的硬件、操作系统、中间件都反复提到了：需要满足汽车功能安全需求，这也是汽车EE系统和消费级电子系统最大的区别。那么需要满足哪些条件才算是 “满足了功能安全需求”？这就需要一套Methodology，而当前汽车产业现行的这套方法论就是 ISO26262《Road Vehicles Functional Safety 道路车辆功能安全国际标准》。

一切的起源是国际电工委员会在2000年发布的IEC61508《电气/电子/可编程电子安全相关系统的功能安全性标准》，其规定了电气电子系统运行和故障预测能力两方面的基本安全要求。首先引入了SIL-Safety Integrity Level 功能安全等级的概念。而后该标准延伸到了各个行业：ISO 26262 汽车、ISO13849机械控制、ICE 62061、DO-178 航空、ICE 32604、ISO 25519 农业。中国的《车辆功能安全管理标准》GB/T 34590.2 基本是直接翻译了ISO26262的内容：

对ISO 26262的简要介绍如下表：

ISO26262的内容较为庞杂， 我们只需要了解其最重要的三个部分即可：

V-Shape开发流程(《BUAA火车侠：自动驾驶仿真及其工具链（6万字扫盲）》)；

ASIL概念（6.2节）；

功能安全设计开发流程；

7.2 方法论

随机性失效：

硬件安全完整性要求；

系统性失效：

函数覆盖：检出基于需求测试的违反案例，检出未被调用的多余函数，提升代码维护性可靠性。

函数调用覆盖：架构层级的质量测试，在基于需求的测试中，找出不足的测试用例需求，死代码，确保调用的意义；都需要达到100%，没达到需要审查。

而但是仅靠调用的覆盖率，无法检出多余的函数；BTC EmbeddedPlatform 自动测试用例的生成，自动的

ASPICE功能安全——Verification、Validation。

7.3 安全目标ASIL的评级

ASIL Automotive Safety Integrity Level 车辆功能安全等级。其从低到高分为五个等级：QM、A、B、C、D（QM代表与安全无关）。这种分级方式并不难理解：如前文提到的涉及基础车控、自动驾驶相关的功能，一旦发生故障有很高安全风险的功能，一般都需要达到ASIL D等级，而比如导航失灵、空调故障、雨刮失灵这些一般不会带来致命问题，则要求会低一些，再比如天窗漏水、饰件脱胶此种情况，造成严重后果的可能性就更小了。

ASIL主要从以下三方面进行评价：

综合这三个维度的评价指标 ASIL = S & E & C，按照下表即可得出最终的安全等级。

最终的ASIL等级评判表

7.4 自动驾驶发展下的标准

ISO26262这套体系是2011年左右搭建并完善的，而那个时候的汽车EE系统仍然是分布式的，开发仍然是基于MBD、V-shape的范式。随着目前AD/ADAS的发展，整个行业都开始发现，这一套方法论开始与实际产生脱节，覆盖不到所有的领域。对前述的SOC、域控制器、传感器等硬件，RTOS、中间件等软件，ISO26262 的方法论还是基本能够应付。例如Nvidia Orin即满足ASIL-B级别的芯片安全和ASIL-D级别的系统安全认证。华为基于Linux系统开发的的自动驾驶OS则通过了最高的ASIL-D等级。

但在应用层，针对基于DL的感知算法、基于RL的规划控制算法，或者Een to End的自动驾驶模型，则缺乏相应的理论指导以及安全测试标准，业界需要摸索出一套适用的方法来对其功能安全进行评价。

8. 案例 2022.09.01（估计应该会有事实性错误以及时效性）

量产案例会抽取互联网公司、整车企业、Tier1、的不同样本。本章节会从头到尾串起来，从SOC芯片，到域控制器架构，到自动驾驶OS内核，中间件，到软件架构以及自动驾驶算法。（部分内容会和前面有所重复)

8.1 Tesla

8.2 Nvidia

结合Nvidia在自动驾驶仿真的Nvidia Constellation仿真平台，Nvidia实力相当深厚

当然，Nvidia可以基于Nvidia的硬件开发OS，比如小鹏P7就是基于Xavier自研OS。

8.3 百度

8.4 华为

8.5 大众

8.6 蔚来

8.7 个人私货：“全栈自研”的分析（2022.08.11）

当前市面上几乎所有涉及自动驾驶的OEM、供应商都在宣称“全栈自研”，这个词几乎像“端到端”之类的黑话被用烂了。那么所谓“全栈”的定义是什么？是仅仅涉及感知、定位、决策、规划算法的自研？还是包括了下层的功能软件框架、中间件、乃至OS内核；甚至是自动驾驶域控制器和SOC等关键硬件？那么产品落地过程中的仿真测试工具&方法、以及感知阶段的Camera和Lidar模组是否也应该算在内？

从上述疑问可知，市面上绝大部分“全栈自研”，对词汇滥用的口嗨成分比较大。几种算法是远不足以搞定自动驾驶的量产落地的，“算法”在整个自动驾驶环节链条中所占比例并没有想象的那么高。这也是2021年来大部分自动驾驶公司话语权丧失，逐渐依附于OEM的原因。整合实现自动驾驶所需资源整合的能力，目前来看仍然掌控在OEM手里。之前的自动驾驶公司对这种上下游的资源整合能力不以为意，而接受市场教育之后逐渐变得务实。

而华为、Tesla、Nvidia等少数巨型企业则依靠其强大的体量和技术实力打通了所有环节，实现了真正意义的全栈自研。走到这一步，此类企业往往也就不太需要依附OEM的资源，离下场造车也就不远了。事实也正是如此：Tesla一开始就是全栈自研的车企；华为与金康深度绑定生产问界、与长安汽车宁德时代合资生产Avita；百度则与吉利合资成立集度汽车（百度在软件上基本可以打通，硬件存疑）。

下表是企业涉及自动驾驶的领域：