软件定义的车辆（SDV）技术深入研析（二）

点击蓝字 关注我们

在软件定义的车辆（SDV）技术深入研析（一）中，我们介绍了什么是SDV，以及汽车SOA化能给我们带来的好处。今天我们将把目光转移到目前汽车行业SDV/SOA化的进展方面，关注目前出现并被积极讨论的SOA解决方案。

汽车E/E架构变迁史

SDV概念的提出是随着E/E架构的不断演进而诞生的，由过去的分布式ECU架构在向域集中式架构进化过程中形成的，因此简要回顾一下E/E架构的变迁史就显得非常必要。如调研（一）中提及的那样，早期车辆E/E架构是分布式架构，每个ECU通常只负责控制一个单一的功能单元，彼此独立，通过CAN总线或者LIN总线连接在一起，实现信息交换。随着汽车功能增加，ECU的数量从几十个快速增加到 100 多个，不仅导致更高的线束负担与成本，还导致车辆功能新增与变更变得更加困难。

因此，现代车辆采用以功能域（Domain）为中心的E/E架构。基于少量高性能处理器打造汽车的“ 大脑”，通过一套新型的电子电气架构，形成快速传递信息的“神经网络”和“血管”，以控制和驱动所有电子器件和传感器。少量的高性能计算单元替代过去大量ECU，使车辆上的ECU大量减少；ECU 的减负意味着把整车原先搭载的几十上百个 ECU 逐一进行软硬件剥离，再把功能主要通过软件迁移到域控制器中。不同的车辆域（如动力总成、底盘、乘客舱和车身）在逻辑上被组合在一起，并通过专用总线系统（如CAN总线）连接起来。

然而，功能域为中心的E/E架构没有从根本上解决车辆线束复杂、沉重的问题。如果在域集中式架构的基础上，更进一步把不同功能的域进行整合，那么就到了跨域融合阶段，形成所谓的位置域（Zonal）架构。位置域根据在车辆中的物理位置对不同的车辆传感器和执行器进行分组。在区域E/E架构中，线束变得不那么冗余，能够简化单个区域内的连接，减少复杂性和重量，并使新功能和技术更容易集成。区域架构通常是专用区域控制器与高性能车载计算机的结合。区域控制器通常使用如CAN、LIN和FlexRay等不同的总线系统来连接到各种传感器和执行器。然后，区域控制器通过基于以太网（Ethernet）的新型车载高速网络相互连接，并与高性能车载计算机连接。功能域（Domain）与位置域（Zonal）架构的区别如下图所示。

在可预期的未来，汽车部分功能更有可能进一步迁移至云端，车内架构进一步简化。汽车的各种传感器和执行器可以通过软件进行定义和控制，使汽车零部件逐步标准化，从而彻底实现软件定义的汽车功能。这就是所谓的车云计算阶段。

AutoSAR从CP到AP

随着汽车功能的飞跃式增加以及E/E架构的变迁，车辆底层的硬件结构变得十分复杂，处理器也由简单的单片机芯片发展到多核异构处理器。面对这种情况，企业需要能够屏蔽底层复杂硬件的东西，从而可以专注于上层的应用开发。

在传统ECU架构时代，AutoSAR一直垄断中间件市场。最早出现的AutoSAR CP版本主要针对分布式ECU架构，采用的是典型的分层软件体系结构。由于CP版本的软件需求在设计时是通过每一层的静态配置来实现，因此对于运行时的更改它的灵活性较低。通常来说，被控制的传感器和执行器的应用逻辑不会经常改变，因此这一不足在过去的物理世界中通常可以被接受。随着E/E架构的变化，以及物理世界向数字世界的演进，AutoSAR CP版本已经无法适应智能化汽车的应用。在2017年，AutoSAR组织推出了第一个AP版本（Adaptive Platform AutoSAR）R1703，专门应用于域集中式E/E架构。AP AutoSAR的核心是自适应应用程序（Adaptive Application），它是一种可以根据运行时环境动态调整的软件组件。

Adaptive AutoSAR构建在POSIX操作系统之上，由不同的功能模块组成，这些模块被划分在服务模块和基础模块上，它的的通信是面向服务类型的，会将网络绑定到DDS或者Scalable service-Oriented MiddlewarE over IP （可扩展的面向服务的 IP 中间件，SOME/IP）使用以太网与其它ECU通信。为了支持复杂的应用程序，同时在处理分布和计算资源分配方面允许最大的灵活性和可伸缩性，AP遵循SOA（service-oriented-architecture）的架构，并遵循以下基本概念：系统由一组服务构成，其中一个可使用另外一个服务，应用程序可根据自己的需要使用一个或者多个服务；此外服务可以在应用程序运行的本地ECU上，也可以运行在另一个AP实例的****远程ECU上。AP和CP的差异具体如下表所示：

重要的是，AP并不旨在取代CP或非AUTOSAR平台，而是旨在与这些平台及外部后端系统（如路边基础设施）互动，共同构成一个完整系统。

下图表示AP的架构，其中Adaptive Application（自适应应用,AA）运行在AutoSAR Runtime for Adaptive applications （AutoSAR自适应应用的运行环境, ARA）之上。ARA是应用程序运行时的基础环境，可以提供多种本地功能供应用程序调用，这些本地功能在AP中统称为Function Clusters，其分为两个部分：Foundation和Service。这些API的语言基于C++绑定的，C++标准库也可以作为ARA的一部分使用。关于OS接口，只有POSIX标准的单进程概要文件（PSE51接口）作为ARA的一部分可用。选择PSE51是为了为现有的POSIX应用程序提供可移植性，并实现应用程序之间的自由干扰。

Services提供了AP的标准服务，状态管理（特定于项目实现），网络管理，更新配置管理（UCM，即我们比较熟悉的OTA）。Foundation提供了AP的基础功能，如服务发现、事件发布订阅、请求回复、持久化数据管理等。这些服务主要用于实现AA之间以及AA与外部系统之间的面向服务的、基于以太网和SOME/IP协议的通信，以及支持ARA和AA的运行。

值得关注的一个关键模块是Execution Management（EM），该模块管理AP上所有应用和服务的生命周期。EM还负责系统执行管理的各个方面，包括系统初始化和应用的启停。当机器启动时，操作系统会被首先初始化，然后EM作为操作系统一个初始进程被启动。然后EM启动自适应平台基础的其他功能集群和平台级应用程序。自适应平台基础启动并运行后，EM将继续启动自适应应用程序。EM负责AP平台和应用执行管理的各个方面，包括：

1) 平台生命周期管理：EM是自适应平台启动阶段的一部分，负责自适应平台和部署的应用程序的初始化。

2) 应用生命周期管理：EM负责已部署的应用程序的有序启动和关闭。EM根据机器清单和应用程序清单中的信息确定已部署的应用程序集，并根据声明的应用程序依赖项派生启动/关闭顺序。

值得注意的是，EM不负责应用程序的运行时调度，因为这是操作系统的责任。但EM负责操作系统的初始化/配置，使其能够根据执行管理从机器清单和应用程序清单中提取的信息执行必要的运行时调度。

值得关注的另外两个关键模块是Communication Management（CM）和Restful。CM实现了AP应用程序之间面向服务的通信，适用于所有级别的通信，如进程内通信、进程内通信、机器间通信等。CM的功能包括：

1) 将协议无关的服务导向通信映射到配置的协议绑定，并执行相应的协议。应用程序代码使用服务导向通信的API，而不需要关心底层的协议细节。

2) 支持服务发现、服务注册、服务请求、服务响应等功能，实现不同的通信模式和质量，如点对点、发布订阅、可靠、实时等。

3) 支持事件、方法和字段三种类型的服务，实现不同的数据交换和远程调用功能。事件用于发布和订阅数据，方法用于请求和响应数据，字段用于获取和设置数据。

Restful模块是一个构建RESTful API的框架，以及在RESTful API之上构建特定服务的框架。它没有定义特定的开箱即用的API来直接构造RESTful服务，但允许开发人员直接访问RESTful消息事务中涉及的不同层。与MM不同之处在于MM的重点是提供一个传统的函数调用接口，并隐藏超出这一点的事务的所有细节，而Restful模块的重点在于确保与非AutoSAR平台的互操作性。例如，一个Restful服务可以与一个HTTP/JSON客户端通信，反之亦然。值得关注的是，在AP的21-11规范里RESTful被删除了。

尽管AutoSAR是目前最常见和最常用的中间件方案，但AutoSAR遵循的“标准开源，成果独占”的思想却并不友好。首先AutoSAR仅是一个标准，需要完全实现AutoSAR，需要购买第三方公司做好的AutoSAR工具链并进行二次开发，全球主要有三家商业化的AutoSAR软件供应商，分别是Vector、EB、ETAS，如EB的tresos、Vector的达芬奇、ETAS的ISOLAR为CP版本的开发工具；EB的Corbos Studio、Vector的Davinci Adaptive、etas的RTA-VRTE AP为AP版本开发工具。目前中国境内亦也有很多公司在从事AutoSAR中间件的开发，例如东软睿驰、普华基础软件等大型企业，以及经纬恒润、华为、斑马智行、超星未来、映驰科技、未动科技、零念科技、上海赫千、国汽智控、成都道伟等新兴企业。

然而，迄今为止，AutoSAR的工具链仍然不够成熟且售价异常高昂。通常，AutoSAR的许可证费用达数百万元之巨。此外，针对不同的域控制器和芯片，还需重复支付费用。AutoSAR的规范在制定时并不会进行开发测试，修复通常只能等待后续版本分发。整个车辆设计与实施的过程，也是工具链逐渐更新修复BUG的过程。由于工具BUG而调整的手写代码让整个软件工程项目变得十分脆弱，由于这些修补代码软件集成也要格外小心翼翼。 

AutoSAR号称软件模块具有复用性与独立性，但这在实践中往往无法达到。一方面是因为工具链厂商对于自己产品的问题修复已自顾不暇，无暇处理这一问题；另一方面出于利益冲突，互相之间未完成兼容性沟通与设计，同时各个厂家对于AutoSAR规范的理解可能也并不完全一致。这会造成一些严重的问题，不同厂家原希望借助AutoSAR合作完成软件项目，但由于工具链的兼容性问题而不得不保持工具链的一致性，无疑对合作产生巨大阻碍。这些因素共同使得AutoSAR的学习成本极高，学习曲线陡峭，企业难以招聘到合适的技术人才。

“标准先行”还是“代码先行”：AutoSAR竞争者的破局之路

有部分资深工程师列举了AutoSAR“标准先行”、“依赖软件供应商”的种种不便之处。例如：在AP中存在面向服务的通信方式DDS和RESTful，但是这不意味着我们就可以直接使用DDS与RESTful。能否使用DDS与RESTful取决于 “工具供应商”，据其了解，当前几乎没有工具供应商支持DDS与RESTful；诊断模块不可直接使用，需要进行定制化开发，这部分也与 “工具供应商”有关；一个操作系统符合POSIX OS标准，不意味着有工具供应商会与该OS进行了适配；某一标定方案可直接在AP端实现标定，但是有个很大的问题是需要标定工具支持SOME/IP，但据其了解当前没有相关的工具支持通过SOME/IP的方式进行标定……

目前，一部分企业已经开始积极寻找AutoSAR的替代品，比如大陆、丰田联合采埃孚、捷豹路虎、沃尔沃等多家汽车企业投资车载操作系统初创公司Apex.AI，其主力产品Apex.OS正是基于ROS 2发展起来的。采埃孚曾表示：“这表明，我们能够向客户提供AutoSAR AP的有效替代方案”。

百度Apollo也推出了Cyber RT，不过Cyber RT专为无人驾驶设计，优势是专注于高等级自动驾驶系统，缺点是市场面较窄。

AutoSAR仍旧继续占有一席之地，由于成本问题，不是每家公司都能如特斯拉一样重新搭建系统。目前对许多汽车制造企业来说，最好的工具仍然是AutoSAR AP，但其固有缺点和蜕变速度仍需进一步改善。

已有部分企业把IT行业的软件开发方法论SOA引入到汽车制造中，希望借助SOA软件服务架构打通车内E/E的壁垒，进一步对嵌入式应用软件的接口进行标准化，能够真正做到整车级软件接口的“标准”和“开放”。例如东软睿驰在使用AutoSAR AP的同时也提出了SOA架构理念；上汽零束也推出了SOA软件平台，由SOA软件及开发者平台组成，将车云能力服务化，提供车端、云端整体软件解决方案。

零束首席架构师孟超认为SOA根本上解决的就是两个问题，第一个是“快”，即软件的快速迭代，对普通的小白开发者，只需要通过拖拽，再搭载SOA软件平台汽车就可以做到即编辑即用，专业开发者可以做到一天或者七天上架应用，所以这是SOA的快。

这里又引出了另一个目前比较流行的概念，开发者生态。孟超表示，“SOA一定不是一家企业或者一个人能做出来的事情，这是个很难的过程。”百度车联网事业部总经理苏坦也表示，汽车SOA的边界应该放大，打开对开发者的限制，同时平台应该在最广泛的规模上回报开发者。清华大学汽车产业与技术战略研究院院长赵福全也表示，SOA平台不是某一家独有的，而是所有开发者的。只有开放，要把所有的参与者不仅仅当成用户，更要当成一个很重要的建设者，才能最终实现合作共赢。

当今的汽车模型包括来自许多供应商的定制硬件和软件组件。硬件和软件组件紧密集成并同时发布。这就造成了碎片化和单一的编程框架。开放源代码是应对这种复杂性和异质性的一种方法。在技术框架（如通用应用程序接口和硬件抽象）上的合作意味着原始设备制造商和其他行业参与者不需要重新发明轮子，从而可以将更多的资源投入到差异化功能和技术进步上。开放源码生态系统还具有加速创新的潜力，它使全球开发人员能够解决问题并创建汽车领域的应用程序。

2022年3月，Eclipse基金会在其官网宣布成立软件定义汽（SDV）车工作组。工作组的核心成员有在全世界开发软件最多的Microsoft、世界上最大开源基金会之一的Eclipse，以及全球汽车零部件Top5中的三家：博世（Bosch）、ZF和Conti。Eclipse SDV工作组专注于使用开源和开放式规范，加速车规级车载软件栈的创新。

这一工作组专注于使用开源和开放式规范，加速车规级车载软件栈的创新。该工作组为个人及组织提供了一个论坛，以此构建和推广所需的开源软件、规范和开放协作模式，从而创建一个可缩放、模块化、可扩展、业界即用型且采用开源许可证的汽车软件平台，支持车载与车辆周围应用程序的开发和部署。最重要的是，**SDV相关项目以“代码优先”的方法为重点，致力于构建行业首个开源软件栈和相关工具，以支持新型汽车的核心功能。Eclipse SDV开源了它们的代码、文档、工作组记录，并提供了可运行的初始版本供开发人员试验。这相较于AutoSAR，会相对更容易被尝试、测试、接受并使用，并更容易形成事实标准。**SDV工作组认为，这种方法将更快地对行业产生实质性的影响。由博世、Microsoft、大陆、采埃孚、Cariad、埃森哲和Eteration等领导者领导的这些新项目，已经向任何希望利用它们进行自己车辆开发的组织提供他们的软件。Eclipse SDV工作组提出的SOA架构如下图所示。

为了支持SDV的转型，Eclipse SDV来自软件行业和汽车行业的参与者正积极开发开源车载应用程序运行时、基于云的车辆操作系统以及高度集成的开发工具链。Eclipse SDV旨在为不同车型、产品线、品牌、组织和时间段的车载软件提供可用的开源代码。Eclipse SDV认为这将极大地加速创新速度、生产速度以及以软件为核心的车辆规模化生产能力，显著降低新车设计的复杂性，同时提高效率。行业参与者能够专注于创新，同时在实时操作系统、中间件层的特定部分或通信协议等非差异化元素上节省时间和成本。

不仅是Eclipse SDV，由ARM公司主导的适用于嵌入式边缘的可扩展开放架构特别兴趣小组（Scalable Open Architecture for Embedded Edge special interest group, SOAFEE SIG）也正在通过标准化系统架构规范来应对车辆SOA挑战。SOAFEE打算通过采用云原生计算和边缘计算的标准来改变这种状况，使汽车原始设备制造商能够专注于其核心竞争力，并提高软件的可重用性。SOAFEE 采用并增强当前在云原生世界中使用的标准，以帮助管理软件定义汽车架构的软件和硬件复杂性，这与Eclipse SDV不谋而合。

SOAFEE 的主要目标是定义一个如图所示的框架，以支持云原生开发以及车辆应用和功能的车辆边缘平台部署。但同时SOAFEE也提供了他们框架的一个参考实现EWAOL。尽管EWAOL仅实现了SOAFEE V1.0的部分功能，这仍然是一个不错的开端。

那Eclipse SDV和SOAFEE分别擘画了怎样的车辆SOA蓝图？SDV“代码先行”这张饼又做熟了几分呢？有哪些工程实践呢？敬请参考本系列第三、四讲：软件定义的车辆（SDV）技术深入研析（三）：Eclipse SDV探秘 和 软件定义的车辆（SDV）技术深入研析（四）：SOAFEE与容器化

本文主要引用与参考：

• 万字长文解读AutoSAR完整架构及AP特性，https://zhuanlan.zhihu.com/p/536367959

•  Adaptive AutoSAR 中的，https://blog.51cto.com/u\_12740336/6168486 

• AutoSAR AP硬核知识点梳理架构详解. http://www.cartech8.com/plugin.php?id=attachcenter:page&aid=538443 

• 从AutoSAR到SOA,中间件的问题依然没有解决（红色星际），https://zhuanlan.zhihu.com/p/552056189

• Dirk Slama, Achim Nonnenmacher & Thomas Irawan, The Software-Defind Vehicle: A Digital-First Approach to Creating Next-Generation Experiences. 2023-09-13,  https://www.digital.auto/sdv-report

• Liu, Z., Zhang, W. & Zhao, F. Impact, Challenges and Prospect of Software-Defined Vehicles. Automot. Innov. 5, 180–194 （2022）.

• COVESA官网及Wiki, https://covesa.global/

• SOAFEE官网，https://www.soafee.io/ 

本文可能还引用了其他公开的科技博客、新闻信息，如未列出敬请联系作者及时补充；如本文内容存在疏误，敬请及时向作者指出；本文不用于盈利目的，如本文侵犯了包括他人的著作权在内的知识产权、商业秘密以及其他合法权利，敬请联系作者及时修正。

本文是在复旦大学软件工程实验室（CodeWisdom研究团队）支持下完成的。未经许可不得转载或用于商业目的。

作者：孙家正

编辑：汪莹

审核：孙家正，彭鑫