引言：
本文节选自汽标委智能网联汽车分标委今年7月编撰的《汽车控制总体技术要求研究报告》，本报告由国汽（北京）智能网联汽车研究院有限公司、华为技术有限公司牵头，共30余家单位参与撰写。
1 相关背景及介绍
2019 年10 月，汽标委发布了《车用操作系统标准体系》，规范了车用操作系统定义，划分了车用操作系统边界，明确了车用操作系统分类（如下图1 所示），构建了车用操作系统标准体系。
图1 车用操作系统分类
车控操作系统分为安全车控操作系统和智能驾驶操作系统，其中，安全车控操作系统主要面向经典车辆控制领域，如动力系统、底盘系统和车身系统等，该类操作系统对实时性和安全性要求极高，生态发展已趋于成熟。智能驾驶操作系统主要面向智能驾驶领域，应用于智能驾驶域控制器，该类操作系统对安全性和可靠性要求较高，同时对性能和运算能力的要求也较高。该类操作系统目前在全世界范围内都处于研究发展的初期，生态尚未完备。
车载操作系统主要面向信息娱乐和智能座舱，主要应用于车机中控系统，对于安全性和可靠性的要求处于中等水平，该类操作系统发展迅速，依托于该类操作系统的生态也处于迅速发展时期。
本研究报告的涉及范围主要是车控操作系统。
2.1 车控操作系统需求分析
汽车电子电气架构（EEA，Electrical/Electronic Architecture）是集合了汽车的电子电气系统原理设计、中央电器盒设计、连接器设计、电子电气分配系统等设计为一体的整车电子电气解决方案。汽车电子电气架构具体是在功能需求、设计要求和标准法规等特定约束下，通过对功能、性能、成本和装配等各方面进行分析，将动力总成、智能驾驶系统、信息娱乐系统等信息转化为实际的电源分配物理布局、信号网络、数据网络、诊断、电源管理等电子电气解决方案。
随着汽车智能化、网联化趋势的发展，汽车电子底层硬件不再是由单一芯片提供简单的逻辑计算，而是需要复杂的多核芯片提供更为复杂控制逻辑以及强大的算力支持。软件也不再是基于某一固定硬件开发，而是要具备可移植、可迭代和可扩展等特性。汽车智能化与网联化发展趋势共同推动了汽车电子电气架构的变革，一方面是车内网络拓扑的优化和实时、高速网络的启用，另一方面是电子控制单元（ECU）的功能进一步集成到域控制器甚至车载计算机。汽车电子电气架构的演进趋势为从分布式架构到域集中式架构最后到中央集中式架构转变，如图2 所示。
图2 汽车电子电气架构演进趋势（来源于博世）
当前，集中式电子电气架构的主要类型有三域EEA（如图3 所示）和Zonal EEA（如图4 所示）。本研究报告主要是针对三域EEA架构类型。其中，三域主要是指车辆控制域、智能驾驶域和智能座舱域，车辆控制域是将原动力域、底盘域和车身域等经典车辆域进行了整合，负责整车控制，实时性及安全性要求高；智能驾驶域负责自动驾驶相关感知、规划、决策相关功能的实现；智能座舱域负责HMI 交互和智能座舱相关功能的实现。对于集中式电子电气架构，智能驾驶系统功能的实现在其中扮演重要地位，相对于分布式电子电气架构，集中式电子电气架构可以提供更为强大的算力，而强大的算力实现不仅需要硬件的支持，更需要和集中式电子电气架构适配的先进车控操作系统。随着软件定义汽车、数字驱动设计趋势的发展，车控操作系统作为车载智能计算基础平台的核心技术，也将成为未来智能汽车领域竞争的重要方向。
图3 三域EEA 示意图（来源于网络）
图4 Zonal EEA 示意图（来源于网络）
车控操作系统包括安全车控操作系统和智能驾驶操作系统。安全车控操作系统主要是实时操作系统（RTOS），主要应用对象是ECU。ECU 对安全车控操作系统最基本的要求是高实时性，系统需要在规定时间内完成资源分配、任务同步等指定动作。嵌入式实时操作系统具有高可靠性、实时性、交互性以及多路性的优势，系统响应极高，通常在毫秒或者微秒级别，满足了高实时性的要求。目前，主流的安全车控操作系统都兼容OSEK/VDX 和Classic AUTOSAR 这两类汽车电子软件标准。其中，Classic 平台基于OSEK/VDX 标准，定义了安全车控操作系统的技术规范。
随着智能化、网联化技术的发展，智能汽车感知融合、决策规划和控制执行功能带来了更为复杂算法并产生大量的数据，需要更高的计算能力与数据通讯能力。基于OSEK/VDX 和Classic AUTOSAR 软件架构的安全车控操作系统已经不能满足未来自动驾驶汽车的发展需求，AUTOSAR 组织为面向更复杂的域控制器和中央计算平台的集中式电子电气架构推出Adaptive AUTOSAR 平台。Adaptive 平台定义采用了基于POSIX 标准的操作系统，可以为支持POSIX 标准的操作系统及不同的应用需求提供标准化的平台接口和应用服务，主要是为了适应汽车智能化的发展需求。Adaptive AUTOSAR 尚处于发展初期，其生态建设获得Tier1、主机厂的普遍认可尚需时日。同时，由于智能网联汽车的区域属性及社会属性增加，在行驶过程中需要通信、地图、数据平台等本国属性的支撑和安全管理，每个国家都有自己的使用标准规范，因此，Adaptive AUTOSAR 能否满足智能化的需求尚有待验证。
智能汽车的发展需要符合中国标准的车内电子电气架构、通信系统、智能终端、驾驶辅助和自动驾驶系统、云平台等新架构汽车产品标准，因此，在软件定义汽车的趋势下，网联、云控也成为中国智能网联汽车发展的特色，而作为智能网联汽车的核心车控操作系统，更应该满足“中国标准”方案的智能汽车电子电气架构。此外，车控操作系统的架构设计某种程度上决定能否建立良好的应用软件生态，从而建立基于软件、服务的商业模式。
2.2 车控操作系统研究现状
2.2.1 安全车控操作系统
安全车控操作系统国外发展较早，目前已经开展了一系列的标准化工作，国内目前主要处于跟随状态。欧洲在20 世纪90 年代发展出用于汽车电子上分布式实时控制系统的开放式系统标准OSEK/VDX，主要包括4 部分标准：1）操作系统规范（OS）；2）通信规范；3）网络管理规范；4）OSEK 实现语言。但随着技术、产品、客户需求等的升级，OSEK 标准逐渐不能支持新的硬件平台。
2003 年，宝马、博世、大陆、戴姆勒、通用、福特、标志雪铁龙、丰田、大众9 家企业作为核心成员，成立了一个汽车开放系统架构组织（简称AUTOSAR 组织），致力于建立一个标准化平台，独立于硬件的分层软件架构，制定各种车辆应用接口规范和集成标准，为应用开发提供方法论层面的指导，以减少汽车软件设计的复杂度，提高汽车软件的灵活性和开发效率，以及在不同汽车平台的复用性。AUTOSAR 以OSEK/VDX 为基础，但涉及的范围更广。
截至目前，AUTOSAR 组织已发布Classic 和Adaptive 两个平台规范，分别对应安全控制类和自动驾驶的高性能类。Classic 平台基于OSEK/VDX 标准，定义了安全车控操作系统的技术规范。Classic AUTOSAR 的软件架构如图5 所示，其主要特点是面向功能的架构（FOA），采用分层设计，实现应用层、基础软件层和硬件层的解耦。
图5 Classic AUTOSAR 软件架构
AUTOSAR 标准平台由于采用开放式架构和纵向分层、横向模块化架构，不仅提高了开发效率，降低开发成本，同时保障了车辆的安全性与一致性。AUTOSAR 组织发展至今，得到了越来越多的行业认可，目前已有超过180 家的车、零部件、软件、电子等领域的成员。AUTOSAR 目前已经成为国际主流的标准软件架构，基于 AUTOSAR 标准平台，拥有完整的汽车软件解决方案的企业主要有Vector、KPIT、ETAS 、DS 以及被大陆收购的Elektrobit 和被西门子收购的MentorGraphics。此外，宝马、沃尔沃等汽车厂商都相继推出了基于AUTOSAR 标准平台的车型。
在日本，日本汽车软件平台架构组织（Japan Automotive Software Platform Architecture，JasPar）成立于2004 年，旨在联合企业横向定制兼顾汽车软硬件的通信标准、实现车控操作系统的通用化，提高基础软件的再利用率等。JasPar 组织成员包括绝大多数的日系汽车及配套软硬件产品厂商。
我国主机厂及零配件供应商目前主要使用Classic AUTOSAR 标准进行软件开发。一汽集团、长安集团等主机厂于2009 年开始利用Classic AUTOSAR 标准的工具进行ECU 的设计、开发、验证。同时，上汽集团、一汽集团、长安集团、奇瑞集团等主机厂和部分高校成立了CASA 联盟，旨在中国推广和发展AUTOSAR 架构。目前江淮汽车也是主要基于Classic AUTOSAR 标准进行软件和产品开发。
在产品方面，普华软件是中国电子科技集团的国产操作系统战略平台，并作为牵头单位承担了关于汽车电子操作系统的十一五、十二五核高级重大专项，所形成的车控操作系统在车身控制模块（BCM）、新能源整车控制器（VCU/HCU）、电子转向系统（EPS）等关键零部件得到量产应用，并已被德国博世的先进辅助驾驶系统（ADAS）量产使用。
东软睿驰发布了NeuSAR 产品，其基于AUTOSAR 研发制作，为自主研发自动驾驶系统的OEM 整车企业及零部件供应商提供的面向下一代汽车通讯和计算架构的系统平台，包含AUTOSAR Classic、AUTOSAR Adaptive 及系列开发系统工具。
2.2.2 智能驾驶操作系统
智能驾驶操作系统将会成为自动驾驶汽车发展的核心竞争力之一，由于安全车控操作系统相对成熟，且智能驾驶操作系统部分包含安全车控操作系统，所以本文提到的车控操作系统主要是指智能驾驶操作系统。智能驾驶操作系统发展趋势和特点是纵向分层，以实现层与层之间的解耦，方便快速开发和移植，如图6 所示。
图6 智能驾驶操作系统纵向分层示意图
AUTOSAR 组织为应对自动驾驶技术的发展推出了Adaptive AUTOSAR（AP）架构，如图7 所示，其主要特点是采用面向服务的架构（SOA），服务可根据应用需求动态加载，可通过配置文件动态加载配置，并可进行单独更新，相对于Classic AUTOSAR（CP），可以满足更强大的算力需求，更安全，兼容性好，可进行敏捷开发。
图7 Adaptive AUTOSAR 架构
Adaptive AUTOSAR 系统主要适应于新的集中式的高性能计算平台，满足车内部件之间的高速通信需求和智能驾驶的高计算能力需求。AP 平台采用了服务化的架构，系统由一系列的服务组成，应用和其他软件模块可以根据需求调用其中的一个或者多个服务，而服务可以是平台提供的，也可以是远程其他部件提供，OEM 可以按照功能设计需求定义自己的服务组合。AP 设计也在CP 成功的设计方法论的指导下进行开发，兼顾灵活和功能安全的确定性需求，同时可以进行整车功能的统一设计，兼顾安全车控和智能驾驶系统。AP 平台没有设计新的操作系统内核，所有符合POSIX PSE51 接口的操作系统内核都可以使用，AP 平台重点是在操作系统内核之上的系统服务中间层，主要分为平台基础功能和平台服务功能两部分。平台基础功能更多的是本地服务，采用库的方式进行调用，如生命周期管理、通信管理、存储管理、诊断功能等；平台服务不限制服务的提供实例的位置，采用互联网常用的服务类似的调用方式，如升级管理、网络管理、状态管理、传感器服务接口等。AP 平台主要的三个支撑和演进方向是：安全（包含信息安全和功能安全），连接（包括车内和车外各种新的通信机制），可升级（包含OTA，灵活的软件设计和管理等）。AP 平台仍采用传统的标准设计方式，每年一个版本集中进行新的功能发布。
虽然AUTOSAR AP 在继承ATUOSAR CP 成功经验的基础上，采用了很多互联网的思路来设计，但是由于汽车软件需求变化较快，仍存在很多问题，如传统的AUTOSAR 方法论配置繁琐，支持的通信速率低，不支持解耦部署策略和动态升级方案，特别是车车协同、车路协同、车云协同等还一直处于需求讨论阶段，没有支持的时间表。
AUTOSAR AP 平台是适应新一代电子电气架构下的集中式计算需求而产生的，但只是整车功能中的一小部分，缺乏从整车电子电气系统视角考虑信息安全、功能安全、通信等需求。在底层操作系统之上， 软件中间件在智能驾驶领域也备受关注。中间件的主要目标是为上层应用提供数据通信、协议对齐、计算调度、模块化封装等常用功能，为应用开发提供标准化、模块化的开发框架，实现模块解耦和代码复用。ROS 作为最早开源的机器人软件中间件，很早就被机器人行业使用，很多知名的机器人开源库，比如基于quaternion 的坐标转换、3D 点云处理驱动、定位算法SLAM 等都是开源贡献者基于ROS 开发的。ROS 的首要设计目标是在机器人研发领域提高代码复用率。ROS 是一个分布式的进程（也就是“节点”）框架，这些进程被封装在易于被分享和发布的程序包和功能包中。整个智能驾驶系统和机器人系统有很强的相似度，ROS 的开源特性，丰富的开源库和工具链，特别在智能驾驶的研究领域有着较为广泛的应用，很多自动驾驶的原型系统中都能够看到 ROS 的身影，例如AUTOWARE，百度 Apollo 最初也是使用了 ROS，直至Apollo 3.5版本才切换至自研的车载中间件Cyber RT。
ROS 在发展过程中主要有两个版本，ROS1 和ROS2，ROS1 的通信依赖中心节点的处理，无法解决单点失败等可靠性问题。为了更好的符合工业级的运行标准，ROS2 最大的改变是，取消Master 中央节点，实现节点的分布式发现，发布/订阅，请求/响应；底层基于DDS（数据分发服务）这个工业级的通信中间件通信机制，支持多操作系统，包括Linux、windows、Mac、RTOS 等。虽然ROS2 基于ROS1 有了很大的改进，但是距离完全车规应用还有很大的距离，有些公司如APEX.AI 也在对ROS 进行车规级的改造尝试。
图8 ROS 架构（来源于网络）
目前普遍采用的车控操作系统底层内核主要有Linux、QNX 和其他RTOS（如FreeRTOS、ThreadX、VxWorks 等），三者之间的主要特点对比如表2 所示。
Linux 最初是作为通用操作系统而设计开发的，但提供了一些实时处理支持，这包括大部分POSIX 标准中的实时功能，支持多任务、多线程，具有丰富的通信机制等。除此之外，Linux 社区有实时性增强patch，在Linux 内核原有RT 功能上，增加了中断线程化、优先级默认继承等功能。Linux 也提供了符合POSIX 标准的调度策略，包括FIFO 调度策略、时间片轮转调度策略和静态优先级抢占式调度策略。另外，Linux 还提供了内存锁定功能，以避免在实时处理中存储页面被换出，同时提供了符合POSIX 标准的实时信号机制。
QNX 是一种商用的遵从POSIX 规范的类Unix 实时操作系统，其主要特点是符合分布式、嵌入式、可规模扩展的硬实时操作系统。QNX 遵循POSIX.1 (程序接口）和POSIX.2 (Shell 和工具）、部分遵循POSIX.1b（实时扩展）。QNX 的微内核结构是它区别于其它操作系统的显著特点。QNX 的微内核结构，内核独立自处于一个被保护的地址空间；驱动程序、网络协议和应用程序处于程序空间中。
表2 车用操作系统内核比较
在此衷心感谢参加研究报告编写的各单位、组织及个人:
组织指导：汽标委智能网联汽车分标委
牵头单位：国汽(北京)智能网联汽车研究院有限公司、华为技术有限公司
参与单位：国汽智控（北京）科技有限公司、中国汽车技术研究中心有限公司、北京地平线机器人技术研发有限公司、电子科技大学、中国第一汽车股份有限公司、一汽解放汽车有限公司、上汽大众汽车有限公司、北汽福田汽车股份有限公司、惠州市德赛西威汽车电子股份有限公司、上汽通用五菱汽车股份有限公司、长城汽车股份有限公司、东风汽车有限公司东风日产乘用车公司、上海汽车集团股份有限公司零束软件分公司、大众汽车（中国）投资有限公司、中汽研软件测评（天津）有限公司、北京百度智行科技有限公司、江淮汽车集团股份有限公司、长安汽车软件科技有限公司、清华大学、东风汽车集团有限公司技术中心、东风商用车有限公司、国家ITS 中心智能驾驶研究院、北京汽车股份有限公司、阿里巴巴（中国）有限公司、高通无线通信技术（中国）有限公司、中国汽车工程研究院股份有限公司、中兴通讯股份有限公司、中国软件评测中心（工业和信息化部软件与集成电路促进中心）、上海机动车检测认证技术研究中心有限公司、斑马网络科技有限公司、上海瓶钵信息科技有限公司
参与人员：田思波、丛炜、潘晏涛、褚文博、周铮、程智锋、吴含冰、罗蕾、石庆鹏、张晓谦、孔涛、孟宪刚、郑岩、石景文、余得水、钱国平、伍宇志、罗覃月、周思儒、邹德英、孙华、郑四发、樊胜利、吴丹丹、唐波、周明珂、彭琪惠、徐耀宗、彭伟、冯锦文、吴琼、朱乾勇、黄懿、桂绍靖、江浩、刘珺、王琳、刘红军、李俨、凌晓峰、徐立锋、郭盈、李玉坷、高长胜、金一华、刘时珍、王锦、张路、刘晨曦、程唐平、田俊涛、马涛、王圭、许梦枚、林智桂、王萌、金天、侯昕田、丁钊、李毓强、郑方、殷苏辰、陈书平、贾元辉、秦文婷、刘大鹏、崔云峰、周波、刘海威、满志勇
作者：NTCAS
来源：https://mp.weixin.qq.com/s/wMStudrHlwjv5TSjw4p6PA
微信公众号：
推荐阅读：
更多汽车电子干货请关注汽车电子与软件专栏。
