去年5月份,九章智驾发布的《自动驾驶OS现状及市场格局》在产业内引起了强烈反响,但这篇文章的重点是在说狭义OS即“内核”,对作为广义OS一部分的“中间件”,却着墨不多。那么,中间件到底是什么,它分为哪些类别?每个类别又有何特殊意义?目前市场上有哪些主要玩家?
带着这些问题,《九章智驾》在2021年11月份采访了华玉通软联合创始人毕晓鹏、前中科创达首席架构师汪浩伟(现为均联智行首席架构师)、东软睿驰业务线总监兼欧美全球销售总经理茅海燕、Vector产品专家蔡守群等诸多操作系统领域的专家。
接下来,我们将结合这一系列采访成果,通过4篇文章对自动驾驶中间做个简单的“科普”,这是第一篇。
一.中间件的定义与作用
1.什么是中间件?
图片摘自公众号“筋斗云与自动驾驶”
笔者在交流中发现,不同的人对中间件的理解并不一样,甚至可以说,到现在,这个概念还是模糊不清的。比如:
(1)有的人认为中间件仅指位于OS内核之上、功能软件之下的那部分组件,为上层提供进程管理、升级管理等服务;而有的人则认为中间件还应包括功能软件和应用软件中间的那部分(参见上图)。按茅海燕的说法,前者是“通用中间件”,而后者是“专用中间件”。本文中提到的“中间件”,若不做专门说明,便特指“通用中间件”。
(2)有一些人提到的自动驾驶中间件,包括了AUTOSAR(又分为AUTOSAR CP和AUTOSAR AP),还有一些人口中的中间件,特指ROS2、Cyber RT、DDS等。
(3)未动科技VP萧猛认为,“中间”一词是相对的,当有多层堆叠的时候,每一层都是其上下两层的中间层,因此,在用“中间件”这个词的时候,我们需要特别指明它究竟位于“哪两层之间”。按萧猛的说法,当我们称“ROS/ROS2 为中间件”时,其含义与 “AUTOSAR AP为中间件”并不是对等的关系。
(4)Vector产品专家蔡守群说,他理解的中间件,“是给App开发提供功能支撑的,对外是没有功能表征的;但是站在操作系统内核的角度,中间件跟App并没有本质的区别”。
2.中间件的作用
汪浩伟说:“专用中间件原本是应用程序的一部分,只是很多公司做自动驾驶都需要用到,就被抽象出来了。”
那么,它究竟有什么用?
毕晓鹏认为,自动驾驶中间件最主要的作用是:对下,它能够去适配不同的OS内核和架构;对上,它能够提供一个统一的标准接口,负责各类应用软件模块之间的通信以及对底层系统资源的调度。
据毕晓鹏解释,前者,使开发者们无需考虑底层的OS内核是什么,也无需考虑硬件环境是什么,即不仅实现了应用软件与OS的解耦,也实现了应用软件与硬件的解耦;而后者则确保了数据能够安全实时地传输、资源进行合理的调度。
为什么要通过中间件来支持软硬件解耦?毕晓鹏解释道:
我开发一个应用软件,其中很多内容都是与具体应用逻辑无关的,包括数据通信、通信安全、系统资源调度等,比如,有十个进程需要数据交互,完全没有必要在十个程序的软件代码里各自进行实现和配置。针对这种情况,我们就可以把重复的部分抽象成一种服务,单独封成一层东西(这就是中间件),并提供统一的库、接口和配置方法,供上层去调用。这样的话,有一部分人专门去做中间件的,而做上层应用的人也不需要考虑跟底层交互的事情。
举例说,如果要做一个自动泊车系统,它有各个模块或业务逻辑独立的不同软件,在进行通信、数据交互,或者调用底层资源时,只需要中间件的一个接口就可以实现,其他事情不需要考虑,这样开发人员就可以专注于自己的业务逻辑。
又比如,一个摄像头需要感知前面的车道线、红绿灯等,开发人员就专门做红绿灯和车道线检测算法,与外界的数据交互只需要使用中间件的通信服务(例如订阅摄像头信息,发布检测结果),而不必关心数据从哪里来、发给谁。
Nullmax纽劢科技系统平台总监苗乾坤博士在此前的一篇文章中写道:
“芯片算力大幅增长,摄像头像素呈翻倍之势,激光雷达出现在更多新车规划上……没有谁能够断言车上的传感器应该有多少,又或者是将来的汽车还会增加哪些硬件,但所有人都知道硬件的变化将会来得更加猛烈。
“所以我们也可以看到,汽车对软硬件架构的要求也越来越高,既要能满足当下的需求,还要具备相当的前瞻性、兼容性和扩展性,能够支持接下来软硬件升级换代、增减模块的需求。而自动驾驶的中间件,就正是这样一个可以按需调整、满足各样需求的现代温室。
“在早期开发中,中间件可以化整为零,将巨大的软件工程分解成若干小任务,分散解决。在后期应用时,它又可以化零为整,像拼积木一样,根据需求将一个个模块组合成一个整体,严丝合缝。”
在春节前的一场直播中,东软睿驰产品销售总监安志鹏说,在软硬件解耦、模块化管理后,再遇到问题,就不用整个系统都改,只改相对应的部分就行了。这样,软件的可复用程度就极大地提升了,同时,验证的工作量也会减少许多,整体开发效率也会因此提升。
相反,没有中间件的话,应用层就得直接调用操作系统的接口,后期要是换了操作系统,应用层的代码和算法可能就要推倒重来。
简言之,中间件通过对计算平台、传感器等资源进行抽象,对算法、子系统、功能采取模块化的管理,并提供统一接口,让开发人员能够专注于各自业务层面的开发,无需了解无关细节。
按东软睿驰产品销售总监安志鹏的说法,搞AUTSOAR这样的中间件,并不是只对OEM有利,“零部件供应商的选择面也大了——应用做好了,下面的软件、芯片可以选好几家供应商的,要比传统的开发模式快很多,因而,零部件供应商也是受益者”。
用萧猛的话说,中间件最直接的好处就是“为上层屏蔽底层的复杂性”,软件开发人员可以忽略芯片、传感器等硬件的差异,从而高效、灵活地将上层应用及功能算法在不同平台上实现、迭代、移植。萧猛认为,中间件可以看做是自动驾驶应用背景下的一项“新基建”。
(图片摘自冯占军博士的《AUTOSAR对基础软件开发是喜还是忧?》一文。AUTOSAR只是中间件的一种,但这里写的“AUTOSAR开发优势”基本也适用于其他中间件。)
不过,站在开发者的角度看,中间件的意义也未必全部是正面的。如冯占军博士在《AUTOSAR对基础软件开发是喜还是忧?》一文中就提到了如下两点:
底层软件工程师变成了工具人,“只要你去点点鼠标,用工具配合就可以了”,很多原本由自己做的测试也改由供应商来做,进而导致工程师的成就感严重降低;时间久了,工程师从0到1开发的能力也会降低。
(图片摘自冯占军博士的文章。尽管文章说的是Autosar,但实际上这些问题在ROS等其他中间件的使用过程中也会存在。)
对软件工程师来说,中间件造成的“能力退化”这一问题几乎是无解的。但冯占军博士认为,“如果这个中间件在开发过程中,有使用公司的工程师深度参与,提出需求并一起实施,会好一些”。
此外,殷玮在一篇文章提到,使用AUTOSAR这样的中间件,Tier 1们应该是很不情愿的,“因为不到增加了成本,还有可能逐步沦为硬件生产商”。但这个也不能说是中间件的锅,在软件定义汽车大大趋势下,这几乎是必然的。
二.常见的基本概念
1.AUTOSAR CP与AUTOSAR AP
在所有的中间件方案中,最著名的非AUTOSAR莫属了。
严格地说,AUTOSAR并非特指由某一家软件公司开发出来的某款操作系统或中间件产品,而是由全球的主要汽车生产厂商、零部件供应商、软硬件和电子工业等企业共同制定的汽车开放式系统架构标准。不过,在实践中,各公司基于AUTOSAR标准开发出来的中间件也被被称为“AUTOSAR”。
当前,AUTOSAR可分为Classic Platform和Adaptive Platform两个平台,两者分别被简称为AUTOSAR CP与AUTOSAR AP。
简单地说,AUTOSAR CP主要跑在8bit、16bit、32bit的MCU上,对应传统的车身控制、底盘控制、动力系统等功能,如果涉及到自动驾驶的话,AUTOSAR CP可能无法实现;而AUTOSAR AP主要跑在64bit以上的高性能MPU/SOC上,对应自动驾驶的高性能电子系统。
严格地说,AUTOSAR CP并不只是个“中间件”,它是相当于“OS内核+中间件”的一套完整的“操作系统”。AUTOSAR CP定义了基本的上层任务调度、优先级调度等。
在基于分布式架构的ADAS功能中,AUOTSAR CP便是最常见的“操作系统”。在AUTOSAR的生态形成后,很多芯片厂商的MCU上标配的就是AUTOSAR CP,主机厂没有什么选择权。
由于分布式架构下的芯片主要是MCU,因此,便有了“AUTOSAR CP主要跑在MCU上”的说法。
在分布式架构下,不同的功能对应着不同的MCU,而每一个MCU上都需要跑一套AUTOSAR CP,若传感器的类型比较多,则仅ADAS相关功能就需要很多套AUTOSAR CP,那怎么收费呢?
常规的做法是:根据MCU的类型来收费——如果MCU是两个异构的MCU,那AUTOSAR CP就按两套来收费;如果MCU是同构的,那AUTOSAR CP就按一套来收费。
随着EE架构从分布式向集中式演进、芯片由MCU向SOC演进,计算量及通信量成数量级地上升,另外,多核处理器、GPU、FPGA以及专用加速器的需求,还有OTA等,都超出了AUTOSAR CP的支持范围。
(图片摘自安志鹏的直播课)
2017年,为更好地满足集中式架构+SOC时代的高等级自动驾驶对中间件的需求,AUTOSAR联盟推出了通信能力更强、软件可配置性更灵活、安全机制要求更高的AUTOSAR AP平台。
需要强调的是,不同于AUTOSAR CP自身已经包含了基于OSEK标准的OS,AUTOSAR AP只是一个跑在Lunix、QNX等基于POSIX标准的OS上面的中间件——它自身并不包含OS。
结合aFakeProgramer于2020年发表在CSDN上的《为什么要用AP?Adaptive AutoSAR到底给企业提供了一些什么?》一文及东软睿驰安志鹏在2022年春节前的一场直播中讲的内容,AUTOSAR CP与AUTOSAR AP最主要的区别有如下几点:
1).编程语言不同——AUTOSAR CP基于C语言,而AUTOSAR AP基于C++语言;
2).架构不同——AUTOSAR CP 采用的是FOA架构(function-oriented architecture),而AUTOSAR AP采用的则是SOA架构(service-oriented architecture);
3).通信方式不同——AUTOAR CP采用的是基于信号的静态配置通信方式(LIN\CAN...通信矩阵),而AUTOSAR AP采用的是基于服务的SOA动态通信方式(SOME/IP);
4).连接关系不同——在AUTOSAR CP中,硬件资源的连接关系受限于线束的连接,而在AUTOSAR AP中,硬件资源间的连接关系虚拟化,不局限于通信线束的连接关系;
5).调度方式不同——AUTOSAR CP采用固定的任务调度配置,模块和配置在发布前进行静态编译、链接,按既定规则顺序执行,而AUTOSAR CP则支持多种动态调度策略,服务可根据应用需求动态加载,并可进行单独更新。
6).代码执行和地址空间不同——AUTOSAR CP中,大部分代码静态运行在ROM,所有application共用一个地址空间,而在AUTOSAR AP中,应用加载到RAM运行,每个application独享(虚拟)一个地址空间。
这些区别,带给AUTOSAR AP的优势有如下几点——
1).ECU更加智能:基于SOA通信使得AP中ECU可以动态的同其他ECU同其他ECU进行连接,提供或获取服务;
2).更强大的计算能力:基于SOA架构使得AP能够更好地支持多核、多ECU、多SoCs并行处理,从而提供更强大的计算能力;
3).更加安全:基于SOA架构使得AP中各个服务模块独立,可独立加载,IAM管理访问权限;
4).敏捷开发:Adaptive AUTOSAR服务不局限于部署在ECU本地可分布于车载网络中,使得系统模块可灵活部署,后期也能灵活独立更新(FOTA);
5).高通信带宽:可实现基于Ethernet等高通信带宽的总线通信;
6).更易物联:基于以太网的SOA通信,更易实现无线、远程、云连接,方便部署V-2-X应用。
(图片摘自东软睿驰)
当然了,在某些方面,AUTOSAR AP与AUTOSAR CP相比是有一些“劣势”的。比如,AUTOSAR CP的时延可低至微秒级、功能安全等级达到了ASIL-D,硬实时;而AUTOSAR AP的时延则在毫秒级,功能安全等级则为ASIL-B,软实时。
上述区别也导致了两者应用领域的不同:AUTOSAR CP一般应用在对实时性和功能安全要求较高、对算力要求较低的场景中,如引擎控制、制动等传统ECU;而AUTOSAR则应用在对实时性和功能安全有一定要求,但对算力要求更高的场景中,如ADAS、自动驾驶,以及在动态部署方面追求较高自由度的信息娱乐场景。
尽管AUTOSAR AP有种种优点,但总的来说,它目前还不够成熟——主要是信息安全及UCM等模块不成熟。量产车上装AUTOSAR AP的不少,但主要用在娱乐场景,真正用在自动驾驶场景的还很少。
此外,由于SOC+MCU组合的现象会长期存在,因而,在今后相当长一段时间内,AUTOSAR AP都不可能彻底取代AUTOSAR CP——最常见的分工会是,需要高算力的工作交给AUTOSAR AP,而需要高实时性的工作则交给AUTOSAR CP。
(图片摘自超星未来)
2.ROS2
ROS是机器人操作系统(Robot Operating System)的英文缩写,原生的ROS本是机器人OS,并不能直接满足无人驾驶的所有需求,用作自动驾驶中间件的是ROS 2。
ROS 2与ROS 1的主要区别如下:
(1).ROS 1主要构建于Linux系统之上,主要支持Ubuntu;ROS 2采用全新的架构,底层基于DDS(Data Distribution Service)通信机制,支持实时性、嵌入式、分布式、多操作系统,ROS 2支持的系统包括Linux、windows、Mac、RTOS,甚至是单片机等没有操作系统的裸机。
(2).ROS 1的通讯系统基于TCPROS/UDPROS,强依赖于master节点的处理;ROS 2的通讯系统是基于DDS,取消了master,同时在内部提供了DDS的抽象层实现,有了这个抽象层,用户就可以不去关注底层的DDS使用了哪个商家的API。
(3).ROS运行时要依赖roscore,一旦roscore出现问题就会造成较大的系统灾难,同时由于安装与运行体积较大,对很多低资源系统会造成负担;ROS2基于DDS进行数据传输,而DDS基于RTPS的去中心化的通信框架,这就去除了对roscore的依赖,系统的稳定性强,对资源的消耗也得到了降低。
(4).由于ROS 缺少Qos机制,topic的稳定性与质量难以保证;ROS2则提供了Qos机制,对通信的实时性、完整性、历史追溯等功能有了支持,这便大幅加强了框架功能,避免了高速系统难以适用等问题。
不过,ROS2的QoQ配置较为复杂,目前主要是国外一些专业的大学或实验室在使用,国内仅有极少数公司在尝试;此外,ROS 2的生态成熟度远不如ROS,这也给推广应用带来了不便。
跟AUTOSAR AP一样,ROS 2也是跑在soc芯片上、用于满足高等级自动驾驶的需求的。不过,萧猛在去年的一批文章中却特别强调:当我们称“ROS/ROS2 为中间件”时,其含义与 “AUTOSAR AP为中间件”并不是对等的关系。
萧猛的文章称:
当我们说AutoSar是中间件时,这个中间件是很明确的 L.BSW层语义,即处于计算机OS与车载ECU特定功能实现之间,为 ECU功能实现层屏蔽掉特定处理器和计算机OS相关的细节,并提供与车辆网络、电源等系统交互所需的基础服务;
ROS/ROS2 是作为机器人开发的应用框架,在机器人应用和计算机OS之间提供了通用的中间层框架和常用软件模块(ROS Package),而且, ROS团队认为这个框架做得足够好,可以称作操作系统(OS)了。
ROS 2尽管在功能上跟AUTOSAR AP有不少重叠之处,但两者的思路是不一样的:
(1).从表现形式上看,AUTOSAR AP首先是一套标准,这个标准定义了一系列基础平台组件,每个平台组件定义了对应用的标准接口,但没有定义实现细节,和平台组件之间的交互接口(这些部分留给AUTOSAR AP供应商实现);ROS2则从一开始就是代码优先,每个版本都有完整的代码实现,也定义有面向应用标准API接口。
(2)AUTOSAR AP从一开始就面向ASIL-B应用;ROS 2不是根据ASIL的标准设计的,ROS 2实现功能安全的解决方案是,把底层换为满足ASIL要求的RTOS和商用工具链(编译器)。
ROS 2“过不了车规”似乎已成为一个很广泛的行业共识。但在萧猛看来,ROS2本来就不是为实时域设计的,如果一定要把实时性要求高的车辆控制算法运行在 ROS2中,“那是软件设计的错误,而不是ROS2的问题”。
萧猛认为,只要能补齐L.BSW层所需要完成的所有功能、补齐A 轴所有切面要求的特性,ROS 2就能用于自动驾驶量产车。如前段时间刚拿到采埃孚等多家巨头投资的Apex.AI公司基于ROS 2定制开发的Apex.OS就已经通过了最高等级的ASIL D认证。
萧猛说:“这实际上是基于ROS 2的架构去实现一套 AUTOSAR AP 规范。这可以成为一个单独的产品,投入时间+人+钱可以开发出来,只是看有没有必要,值不值得”。
在具体的实践中,ROS 2跟AUTOSAR AP存在直接竞争关系——尽管对用户来说,并不存在严格意义上的“二选一”问题,但通常来说,若选了ROS 2,就不会选AUTOSAR AP了;若选了AUTOSAR AP,就不会选ROS 2了。
3.CyberRT
Cyber RT是百度Apollo开发出来的中间件,在Apollo 3.5中正式发布。Cyber RT和ROS2是比较像的, 其底层也是使用了一个开源版本的DDS。
百度最早用的是ROS 1,但在使用的过程中逐渐发现了ROS 1存在“若ROS Master出故障了,则任何两个节点之间的通信便受到影响”的问题,所以就希望使用一个“没有中间节点”的通信中间件来代替ROS 1,那时还没有ROS2,所以自己去做了一个Cyber RT。
为了解决ROS 遇到的问题,Cyber RT删除了master机制,用自动发现机制代替,这个通信组网机制和汽车网络CAN完全一致。此外,Cyber RT的核心设计将调度、任务从内核空间搬到了用户空间。
其相对于其他系统,Cyber RT的一大优势是,专为无人架驶设计。百度已将Cyber RT开源,某互联网巨头的自动驾驶团队使用的中间件便是百度开源出来的Cyber RT。
Cyber RT跟ROS 2之间也存在竞争关系。
在谈到AUTOSAR AP、ROS 2与Cyber RT这些中间件的关系时,Vector产品专家蔡守群的解释是:
“不需要很机械地去分类,你可以把AUTOSAR AP, ROS和Cyber RT都想象成一个提供一组中间件的超市,用户可以按需从不同的超市购买,并不是说从一个超市买过一个中间件,就不能从其他超市买了。
蔡守群说:AUTOSAR AP中也包含了对ROS接口的支持。说不准哪天ROS和Cyber RT就会加入AUTOSAR AP的组件,或者AUTOSAR AP会引入Cyber RT的组件。
4.DDS(通信中间件)
(1)什么是DDS?
在自动驾驶领域,中间件的功能涉及到通信、模块升级、任务调度、执行管理,但其最主要的功能就是通信。当前市场上,无论是Cyber RT还是 ROS,基本上90%的功能就是通信,狭义上说就是通信中间件。
通信中间可以分成开源和闭源的两种。开源的为OPEN DDS、FAST DDS、Cyclone等,闭源的就RTI的DDS和Vector的SOME/IP。DDS的全称为Data Distribution Service ,指一种数据分发服务标准,由对象管理组织(OMG)制定。
DDS能够实现低延迟、高可靠、高实时性的数据融合服务,能够从根本上降低软件的耦合性、复杂性,提高软件的模块化特性。高等级自动驾驶现在基本上都在探索依靠DDS来解决异构通信、低时延等CP解决不了的挑战。
融合了DDS的汽车软件能够更好地运行在下一代汽车的体系架构中,更能降低开发的成本、缩短研发的时间,更快地将产品推向市场。
(2)DDS与ROS 2、AUTOSAR AP之间的关系
ROS 2和Cyber RT的底层都使用了开源的DDS,将DDS作为最重要的通信机制。但也有自动驾驶公司的工程师认为,DDS可以起到替代ROS 2的作用,站在用户的角度看,两者之间其实存在“二选一”的关系。
AUTOSAR CP里一直没有包含跟DDS有关的东西,但AUTOSAR AP在 2018年3月的最新版(版本18-10)里开始支持DDS标准。将DDS与AUTOSAR AP结合使用,不仅可以保证和扩展AUTOSAR AP系统内部互操作性的功能,而且还可以将其开放给来自不同的生态系统(即ROS 2)。
从工程角度来看,将AUTOSAR和DDS结合起来的最大优势是,功能域和网络拓扑不再是对手,而是车辆中的盟友。网络拓扑结构能够更好地适应车辆的物理约束,功能域在物理车辆的顶部提供了一个灵活的覆盖层,这就是所谓的分区体系结构。
当然,DDS仅是通信中间件的一种。关于各类通信中间件之间的异同,我们将在本系列的第二篇做更详细的阐释。
三.AUTOSAR AP的地位正在弱化?
尽管AUTOSAR是当下最有名的自动驾驶中间件,但《九章智驾》在对诸多中间件厂商们的调研中得出一个结论:AUTOSAR在产业链中的地位可能正在弱化。 当然了,那些专注于AUTOSAR系统的厂商们并不认同这一观点。
我们在上文已经提到,随着EE架构从分布式向集中式演进、MCU被SOC取代,CP AUTSAR被AUTOSAR AP、ROS 2和Cyber RT等取代已是大势所趋,在下文,我们主要谈的是“AUTOSAR AP的地位会不会弱化”。
2021年12月中旬,两家AUTOSAR发起公司大陆集团、丰田联合采埃孚、捷豹路虎、沃尔沃、海拉等多家汽车行业龙头企业宣布投资车载操作系统初创公司Apex.AI,而Apex.AI的主力产品Apex.OS则是基于ROS 2发展起来的。
拿到了Apex.AI公司15%股权的采埃孚方面在接受媒体采访时说:“这意味着,我们可以为客户提供AUTOSAR AP的替代方案。”
尽管AUTOSAR AP已经有了标准,但还没有落地。安波福、采埃孚、大陆这些公司提供的方案,仍然是基于AUTOSAR CP标准的接口。事实上,越来越多的OEM不太想完全用AUTOSAR去解决智能驾驶操作系统的问题。
不仅特斯拉没有用AUTOSAR AP,国内的几大造车新势力也没有用(他们用的是AUTOSAR CP+DDS)。甚至,连一些正在转型的传统车企也没打算用AUTOSAR AP。
从产业链中各方的反应来看,AUTOSAR AP“地位不稳”的原因主要有以下几个:
1.使用成本太高
冯占军博士在《AUTOSAR对基础软件开发是喜还是忧?》一文中透露,AUTOSAR的费用通常是“几百万起”,并且,针对不同的域控制器、不同的芯片需要“重复收费”,一般小厂根本吃不消。“可能还没有什么产出,几百万就花出去了”。
除购买成本高外,毕晓鹏和萧猛都提到,AUTOSAR前期的学习难度很大、学习成本也非常高。为了学会如何使用AUTOSAR,企业甚至不得不专门培训一批人,如果受培训的人临时离职了,那培训费用就打了水漂。
2.效率不高
毕晓鹏认为,AUTOSAR AP的配置非常多,它是通过配置加上一部分代码去实现自己的功能,但配置多了之后,效率不高,而且代码臃肿。
3.静态部署与动态部署的理念冲突
毕晓鹏博士提到,AUTOSAR AP其实是从AUTOSAR CP发展而来的,AUTOSAR CP是静态部署,只适用于相对简单的业务逻辑和功能,其代码是固化的,有点像以前的功能手机——功能无法改变,不可能往里面再加一个APP;但AUTOSAR AP有点像现在的智能手机,软件开发人员开发一个APP,跨平台就可以用不同手机上了,这种动态部署的理念和之前的静态部署概念不甚相同,而其方法论却是基于静态部署衍生而来的,因此在实践层面会遇到不少问题。
4.无法满足智能网联的需求
由于云端跟车端所使用的操作系统不一样,AUTOSAR只能负责车内的通信,不能支持车端到云端的通信,因而无法支持车路协同场景(车端跟云端的通信,是通过MQTT、kafka等中间件来实现的)。除此之外,AUTOSAR能否兼容车辆网联化中需要用到的数据平台、通信平台和地图平台,也存在很大的疑问。
毕晓鹏说,在发现了这些问题后,有一些OEM开始逐渐放弃AUTOSAR架构,“转而自己去研发一套更适合动态部署、成本较低的新型软件架构”。
传统车厂是从使用CP过来的,所以在惯性上,他们可能还会考虑AP是否适合智能驾驶,但慢慢地也在尝试转型。如奥迪和TTTech合作做的通信中间件——zFAS,也没有采用AP。
不同于AUTOSAR CP已经是非常标准化的东西,大家用起来没什么问题,AUTOSAR AP现在的标准也不是很完善,每年也在更新,具体AP能发展成什么样,这个谁也不知道,大家更多也是观望的态度。
毕晓鹏认为,AUTOSAR标准并不能很好地支撑自动驾驶应用和创新的发展,因此,我们有必要建立一套更适合中国智能驾驶发展、且自主可控的技术架构和生态体系。
萧猛认为,由于从AUTOSAR CP到AUTOSAR AP一脉相承,一些已经对AUTOSAR形成路径依赖的公司会坚持使用AUTOSAR AP,但在经历过招人难、开发周期长等教训之后,他们有可能转向ROS 2。
当然,以AUTOSAR为主业的公司,显然不会认可上述“涉嫌唱衰”AUTOSAR AP的观点的。
比如,Vector蔡守群就认为,AUTOSAR AP只会越来越重要,因为它是顺应车载技术不断发展的一套规范,覆盖面会越来越广。
东软睿驰茅海燕也认为,要将整车域控制器和智驾域控制器合并到统一的中央计算平台上,没有AUTOSAR AP的支持很难搞定。“不是每家公司都能像特斯拉一样自己从头搭建系统的,目前,最好的工具还是AUTOSAR AP”。
智能驾驶行业报告专题调研