英伟达ORIN等大算力芯片推广离不开AUTOSAR中间件三巨头

要想推广芯片的车载应用，AUTOSAR中间件三巨头VECTOR、ETAS和EB是绕不开的，必须与其中一家合作，否则无法大范围推广，特别是在海外市场。这其中的关键就是微控制器抽象层（MCAL），简单地说就是把微控器从物理上的硬件抽象为逻辑上的软件组件。

图片来源：互联网

MCAL就是微控器的驱动软件包和通讯软件包。显然只有芯片厂家才能提供MCAL层信息，外人是无法做的。对中间件厂家来说，芯片平台的开发工作是无法复用的，除了VECTOR能覆盖几乎所有芯片平台，其余厂家都没有那么多精力人力覆盖太多平台，只能选重点合作伙伴，因此芯片厂家和中间件厂家是互惠互利互帮互助的关系。

我们来分析一下未来汽车软件开发的模式，看看为什么AUTOSAR无处不在，而特斯拉又完全无视AUTOSAR。

汽车电子架构从过去的分布式到今天的域控制器再到明天的中央集中计算或者说Zonal式，将对软件开发产生比较大的影响，是电子架构决定了汽车软件的开发模式，而不是软件定义电子架构。

图片来源：互联网

汽车电子架构可以简单总结为上图，一个是微处理器MPU，一个是MCU，MPU运行多种应用软件和多种操作系统和高等级虚拟机，用车载以太网连接。MCU连接车辆致动器如牵引电机、转向电机、制动缸，需要保证安全，具备硬实时性。

图片来源：互联网

未来汽车的软件架构，有两个重要的中间件，一个是自适应AUTOSAR，另一个是经典AUTOSAR。中间件（Middleware）的概念是随着对象管理组织（Object Management Group,OMG）推出的公用对象请求代理体系结构（Common Object Request Broker Architecture,CORBA）被引入到软件工程当中的，尽管CORBA标准本身与汽车行业无关，但是其原则在AUTOSAR标准的设计中得到了体现，例如，使用CORBA标准中的元模型来描述汽车软件中的一些常见元素。IT行业对于中间件的定义：中间件是一种独立的系统软件服务程序，分布式应用软件借助于这种软件在不同的技术之间共享资源，中间件位于客户机服务器的操作系统之上，管理计算资源和网络通信。从这个意义上可以用一个等式来表示中间件：中间件=平台+通信，这也就限定了只有用户分布式系统中才能叫中间件，同时也能把它与支撑软件和实用软件区分开来。

除部分日本厂家和特斯拉，大部分传统车厂包括中国车厂都使用AUTOSAR中间件。为什么有些车厂不用AUTOSAR中间件？原因有四点：

• 一是AUTOSAR将上层软件与底层硬件分离（实际这个分离是相对的），AUTOSAR架构的引入带来的标准化以及分层解耦的好处是显而易见的，比如主机厂与供应商定义好RTE接口，主机厂也参与到软件开发当中来，因为主机厂了解车辆的使用场景或者说车辆主机厂离用户更近，更了解客户的需求，主机厂擅长车辆底盘控制策略和联网应用，供应商的优势在自动驾驶和Infotainment的中低层如修改后的安卓，供应商做这些成本会相对略低。不过有些厂家习惯于内部完成全部软件，这样AUTOSAR中间件的意义不大。

• 第二就是AUTOSAR定义了一套车载环境的以太网通信中间件，即SOME/IP（Service-Oriented MiddleWare over IP），这是AUTOSAR最核心的部件之一。SOME/IP协议于2011年由BMW集团的Lars Völker设计，并于2013年纳入AUTOSAR 4.1规范，在车载以太网的协议架构中，SOME/IP位于应用层，提供面向服务的通信接口。其通信方式为AUTOSAR中提到的CS接口的概念，就是客户端(client)和服务端(Server)，当有请求发出时，SOME/IP才会发出数据，否则不发送数据，类似于COM模块的Direct模式，这样总线上就没有不必要的数据，降低总线负载。同时在整车电子电气架构中可以将Classic AUTOSAR和Adaptive AUTOSAR桥接起来。SOME/IP主要为应用层提供API接口，创建CS接口，通过TCP/IP协议进行通信。而SOME/IP的访问方式分为三种，分别是事件通知、远程过程调用和访问进程数据。

  但从工业界的角度看，SOME/IP不是以太网通信的唯一方案，很多非汽车行业的人更喜欢DDS，DDS（数据分发服务）的目标是更广泛的工业物联网领域。DDS与SOME/IP之间的重要区别在于，使用DDS，应用程序不需要绑定到特定的服务实现。它简单地引用了主题和服务，并且可以完全透明地一对一或一对多地进行通信，而无需更改应用程序代码。虽然它需要跟踪单独对等方的存在或响应对等方的加入或离开来管理任何新对象，这都是自动处理的。从这个意义上讲，它比SOME/IP更灵活。DDS更适合自动驾驶，如激光雷达和300万像素以上相机的数据传输。新一代的自适应AUTOSAR也兼容IPC/DDS/S2S等以太网通信协议。但你可以不用AUTOSAR而直接用DDS。

• 第三就是AUTOSAR通常需要VECTOR这样的第三方中间件供应商协助，因为AUTOSAR只是个标准的大概框架，且内容非常多，据说第一版打印出来有11米那么高。目前全球成熟的主流的只有三家，分别是德国大陆汽车旗下的Elektrobit(EB)，德国博世旗下的ETAS和独立供应商VECTOR，因为EB和ETAS的独立性都不强，有些企业是大陆汽车或博世的竞争对手，自然不会选择其旗下子公司的产品，独立的供应商只有VECTOR一家，其价格惊人，并且有时候是采取按模块而非按项目收费。依赖第三方有可能拿不到源代码（VECTOR是罕见地以源代码交付），或者源代码价格惊人，同时也不利于快速迭代，有些受制于人。这对一向无视车规的特斯拉来说尤其无法忍受。

• 第四，AUTOSAR有着强大的安全机制，能够完美符合功能安全或者说ISO26262。但对特斯拉这样的厂家来说，ISO26262就是束缚，软硬件如果都要达到这个标准，这个成本会增加不少，敢用桌面级x86 CPU做车载的特斯拉不屑于这个功能安全标准。

图片来源：互联网

经典AUTOSAR确保MCU阶段达到ASIL-D级，自适应AUTOSAR领域即使要求不太高的Infotainment也达到C级或B级。

图片来源：互联网

自适应AUTOSAR定义了一套OTA系统，安全高效可靠，不过特斯拉之类的厂家早就建立了自己的OTA系统，自然不屑于自适应AUTOSAR那一套。

典型AUTOSAR工具链包括四部分：

• 一是authoring tools创作工具，即AUTOSAR Authoring Tools(简称AAT，比如ETAS的ISOLAR和Vector的Davinci) 有比较多的耦合关系，提高了开发的复杂度。

• 二是RTE生成器RTE Generator，RTE生成器必须支持生成基础软件调度器，而不需要软件组件相关的RTE片段。基本软件调度程序生成阶段只适用于不包含任何软件组件的构建。在基础软件调度器生成阶段，RTE生成器将生成没有RTE功能的基础软件调度器。在这种情况下，RTE生成器仅为基础软件模块和基础软件调度代码生成API。

• 三是BSW基础软件生成器，典型如ETAS的RTA-BSW。BSW按照层级结构可分为服务层、ECU抽象层、硬件抽象层（MCAL）和复杂驱动层（CDD）。

• 四是OS生成器，低级的如OSEK，高级的如LINUX，还有自适应AUOTOSAR的虚拟机。

以ETAS为例，典型AUTOSAR中间件的工具链

图片来源：互联网

三巨头之一：Elektrobit，简称EB

德国大陆汽车眼光长远，在2015年以6.8亿美元收购Elektrobit Automotive GmbH，这是一家位于芬兰的软件企业，软件行业在汽车领域日益重要，今天估值至少是30亿美元以上。2014年该公司收入大约1.7亿欧元，EBIT为2240万欧元。2017年该公司收购以色列信息安全公司Argus Cyber Security。EB与奥迪有合资公司，EB最主要合作伙伴就是大众和奥迪。ID系列电动车大量采用EB的软件组件，包括了经典AUTOSAR的EB tresos，自适应AUTOSAR的EB Corbos，针对网关的Zoneo。

图片来源：互联网

EB Corbos的主要产品包括Studio、Linux、Hypervisor和Adaptive Core。我们看到最底层的与硬件关联度很高，EB主要基于瑞萨的H3和M3开发，也支持NXP的S32G以及英特尔的Denverton，此外中国的黑芝麻也刚刚与EB达成合作协议，而EB的母公司大陆汽车与地平线是合作关系，未来EB也会加入对地平线的支持。虚拟机方面是德国的L4RE，L4微内核系统由德国国家信息技术研究院 JochenLiedtke设计（此人已在2001年过世），1995年公开。1998年德国德累斯顿大学开发了基于L4的开源操作系统Fiasco.OC，采用基于对象的C++语言。同时也开发了L4运行环境，即L4Re。

EB corbos体系架构

图片来源：互联网

EB corbos内部框架

图片来源：互联网

不过瑞萨的M3算力很低，再加上这套复杂的系统，就更加吃力。不过这也没办法，EB corbos开发是在2017年，当时没有太多芯片可选，同时考虑大众对成本的要求，用M3是无奈之举。

三巨头之二：博世旗下的ETAS

很多人或许不知道ETAS是博世的全资子公司，博世也淡化ETAS的博世身份，ETAS为博世内部做了大量贡献，很多成本博世分摊了，因此ETAS最大优点是便宜。此外ETAS产品线很广，包括HIL和多种发动机原型，燃油车时代几乎可以一站购齐。HIL硬件在环巨头NI与ETAS有合资公司ETAS NI Systems。ETAS有简易桌面HIL系统即LABCAR，国内有不少客户，包括上汽、一汽、蔚来、吉利、宁德时代。ETAS AUTOSAR产品国际上最大客户是PSA和FIAT，也就是Stellantis。在国内主要客户是吉利、宁德时代。

ETAS联合BOSCH推出了RTA-VRTE AP方案，该方案基于AP R19-11版本，在国内ETAS联合BOSCH工程技术服务公司、联合汽车电子推出Adaptive AutoSAR的全栈解决方案，包含中间件RTA-VRTE以及AP开发工程服务，和全套工具链，以及域控制硬件平台XCU。

ETAS RTA-VRTE分层架构

图片来源：互联网

ETAS RTA-VRTE软件栈

图片来源：互联网

ETAS是针对高级汽车软件工程师设计的，自动化程度不高，很多地方需要工程师手动配置，新手很难胜任，但老手就会做得又快又好。这是其国内难以大面积推广的主要原因，并非是因为ETAS属于博世，实际大家不介意ETAS是博世全资子公司，毕竟汽车行业即便是特斯拉想绕开博世那也是完全不可能的。

霸主：VECTOR

VECTOR是毫无争议的霸主，不仅因为其独立性最强，还因为其工具链最齐全，自动化程度高，上手容易，生态系统强大无比，其硬件覆盖面也最广，特别是针对某些高性能芯片如英伟达Orin或高通的SA8540P是独家支持，ETAS和EB对MCU的覆盖面很广，但自适应AUTOSAR需要更多对高性能芯片的支持。这一点VECTOR非常强大，它的人力资源是最强大的。还有一点，它是开放源代码的，当然代价是价格比较高。

VECTOR的AAT工具达芬奇异常强大，诊断的配置文件cdd、CAN总线的配置文件DBC都是VECTOR自家的标准，实际也成为汽车业内标准，典型如DBC，DBC（Data Base CAN）文件用于描述单个CAN网络的通信。相较于Excel、Word版的CAN协议描述文件，DBC文件格式比较固定、不会产生歧义和理解误差，便于交流。每一个CAN网络子网间的通信都离不开DBC，而VECTOR的工具可直接关联DBC，完全不需要再编写。就连常用的CAN总线数据格式blf（二进制数据格式）都是他家的。也就是说，大部分诊断和CAN总线的需求只需要在cdd或dbc文件里进行编辑，然后导入至达芬奇工具就可以实现大部分的功能，对于警告项，只需在提醒栏点击修复，基本大部分可以自动修复，甚至都不需要你知道配置选项的含义是什么。

自动化程度高意味着开发周期短，迭代快，新手短时间培训也能行。

VECTOR最大缺点就是昂贵，其市场地位太强势，据说自适应AUTOSAR中间件ADAPTIVE MICROSAR开价就是200万欧元一个模块，基本上没有打折的可能。并且最贵的地方在于硬件平台换了就要再收一次费，国内公司不比国外选定一个硬件平台用上七八年都有可能，国内快的一两年就换个硬件平台，成本大幅度增加。

VECTOR CAN总线ECU开发工具链

图片来源：互联网

其中PREEvision是个非常重要的软件，这是全球应用最多的电子电气系统（E/E）架构设计工具。PREEvision是基于JAVA语言开发的，并且开放了用户可以再次二次开发的接口。除了PREEvision，另外一家电子电气系统（E/E）架构设计工具是Mentor Graphics收购的VALCANO的VNA，VALCANO跟沃尔沃有些渊源，某些日系二线厂家如马自达是其主要客户。PREEvision最初是德国Aquintos在2008年推出，后VECTOR收购了Aquintos。

图片来源：互联网

PREEvision从最顶层逻辑功能到最下层的线束物理拓扑都完全覆盖，最大限度减少开发周期，避免出错。

国内AUTOSAR中间件厂家众多

除了三巨头，还有很多厂家参与AUTOSAR中间件，国际上有奥地利的TTTech，与上汽有合作。印度的KPIT，与TATA有合作。国内多达十几家，比较大的有三家，分别是中研普华、东软睿驰、经纬恒润。其余有华为、斑马智行、超星未来、映驰科技、未动科技、零念科技、上海赫千、国汽智控、成都道纬。

对中小厂家来说开发AUTOSAR中间件非常困难，首先因为一旦用上三巨头的产品，除非出现重大错误或国际封锁，否则是不可能更换供应商的，那样等于放弃了全部研发人员的研发经验从零开始。其次，AUTOSAR毕竟在欧洲，英语书写的，这种方法论类型的英语文本，对母语是汉语的中国人来说深入理解是不可能的，AUTOSAR有上万个文档，都是晦涩难懂。不是AUTOSAR顶级会员也拿不到最新最全的解释。最后是芯片厂家支持，VECTOR有所有芯片厂家的支持，因为它市场占有率太高了，谁都绕不开。但是初创厂家，芯片厂家不会跟你合作，除非你打开市场了，特别是国外的芯片厂家。

困难很大，可也得做，毕竟这国际形势，不做不行啊。