软件定义车辆(SDV)技术深入研析（一）

点击蓝字 关注我们

今天，曾经以“排气管数量”、“发动机动力”为荣的汽车行业终于站到了转型的前夜，特斯拉、理想、蔚来、小鹏、零跑等造车新势力们纷纷推出了有着可交互大屏、万物互联、软件功能持续更新、堪称“车轮上的智能手机”的新汽车。许多互联网大厂也以身入局，比如华为、小米、百度，或端上自己的造车方案，或拿出这样那样的自动驾驶技术。

与此同时，许多仍然购买并使用着传统汽车的消费者开始思考一个尴尬的问题：在这个大屏+智能软件已然成为新能源汽车标配的时代，为什么我昂贵的汽车它为什么如此的“不智能”？为什么我的车机，不能像只需要几百块钱的便宜智能手机一样完成同样的任务？

太阳底下没有新鲜事，事实上，我们只要简单的回望手机的发展历史，看看这个曾经是世界上领先的手机操作系统，技术历史上最成功的失败者——塞班系统（Symbian OS）的故事：2007年中期（也就是iPhone发布当年）塞班是最领先的移动操作系统，它占据了65%的移动市场，全球售出的手机中，每两部手机就有一部带有诺基亚标志。直到2010年底，塞班仍然是全球最畅销的手机操作系统。但仅仅一两年后，塞班就被安卓和苹果共同埋葬了。

塞班系统最失败的地方在于版本之间的不兼容，即新版本无法运行旧版本的应用程序。这给开发者带来了困难，也使得塞班系统的软件虽然多但能用的却很少，因为同一个塞班系统却不能运行同一个软件。因此，新的塞班系统设备也受到了更谨慎的欢迎，因为消费者担心在新的塞班系统设备上找不到他们喜欢的应用程序。在很多业内人士看来，这是塞班系统失败的的根本原因，因为当时竞争对手的操作系统都具有非常好的向后兼容性。

导致兼容性差的原因之一在于当时手机硬件的异构性。塞班与安卓的显著不同是，塞班系统是和手机型号相互结合、相互绑定的，而安卓明显就不存在这一问题。这种绑定关系固然在发布过程中带来了便利，但是一旦需要开发一款软件，开发人员就需要适配每一款主流塞班手机的键盘，触屏，全键盘等，这给塞班软件的开发带来了相当大的工作量。制造商之间的内讧也加剧了这一问题，因为每个制造商都提供了自己的IDE和SDK，且基本上不通用。同时，Symbian系统使用闭源方案，软件开发者需要支付高昂的许可证费用；Symbian C++非常复杂，需要付出高昂的学习成本。所有这些阻碍了来自第三方的开发，也阻止了塞班的原生应用生态系统发展成为像苹果的AppStore或安卓的GooglePlay。

此外，大部分运行塞班系统的设备都与它的操作系统版本永久绑定，用户无法将旧设备上的操作系统升级到新版本，这使得塞班系统更加碎片化、不友好、更加受限。作为对比，安卓手机每6个月就有一次全方位功能更新，而使用塞班系统的诺基亚却要 12 个月到 18 个月。也就是说，使用塞班只会被竞争对手越拉越远而不是越追越近。在这些因素的共同作用下，塞班的市场份额从2010年第三季度的39%下滑至2010年第四季度的31%，塞班系统迅速被iOS和Android击败，最终在2010年第四季度落后于Android。诺基亚最终从2014年1月1日起终止了对塞班系统的软件开发和维护支持，此后塞班系统连同功能机一同淡出于历史舞台，这也正是无法跟上现代需求步伐的技术的残酷命运。

传统汽车行业正在面临一个与诺基亚当年如出一辙的巨大挑战——5级自动驾驶的代码量估计达到3亿行，而开发人员却坚持使用过去的软件开发方法，这意味着软件的复杂性正在失去控制；硬件和软件至今仍然紧密集成并同时发布，这意味着重大变化每七年左右才发生一次。如同诺基亚和黑莓等曾经的领先品牌很快就被苹果等智能手机超越。汽车行业的老牌企业似乎也有可能面临类似的命运。

在当年，许多手机行业的资深人士坚持认为，他们的业务与计算机、软件有着根本的不同，但智能手机革命很快打破了这种错觉。要想了解为何汽车软件究竟为何迟滞不前，我们不妨先从汽车的基本硬件与软件结构谈起，进而理解在此之上进行的汽车软件开发与普通软件开发究竟有何区别。

汽车的早期分布式架构与AutoSAR CP

显然的，汽车不可能像手机或是电脑那样将所有硬件集中在一块电路板上，然后通过板载线路通讯。汽车的硬件分散在各处，因此必须使用可靠的通讯电缆将他们连接至一起。我们通常使用电子电气架构（E/E架构）来描述这一结构。汽车E/E架构把汽车中的各类传感器、 ECU (电子控制单元)、线束拓扑和电子电气分配系统整合在一起完成运算、动力和能量的分配，进而实现整车的各项功能。

早期车辆E/E架构是分布式架构，在这一架构下，每个ECU功能独立——每个ECU通常只负责控制一个单一的功能单元，彼此独立，分别控制着发动机、刹车、车门等部件，各个ECU之间通过CAN总线或者LIN总线连接在一起，实现信息交换。随着汽车功能增加，ECU的数量从几十个快速增加到 100 多个，ECU数量越多，对应的总线的线束长度、重量也相应增加，导致整车成本增加、重量增加、汽车组装的自动化水平降低。车企要进行任何功能变更都需要和许多不同的供应商去协商软硬件协调开发问题，每新增一个新功能都需要增加一套 ECU 和通信系统，耗时长，流程繁琐。且由于每个ECU绑定一个具体功能，无法实现横跨多个ECU传感器的复杂功能，亦无法通过OTA来保持汽车软件的持续更新。

在传统分布式ECU架构时代，中间件市场一直由AutoSAR垄断，目前市场上依然有很多企业使用AutoSAR。最早出现的AutoSAR是CP版本（Classical Platform AutoSAR），主要针对分布式架构，这个版本的AutoSAR已经使用了十多年，形成了标准化的框架体系。它定义了从系统开发到单个ECU开发的各个阶段，以及在各个阶段需要完成的工作内容、需要提供的成果物。在AutoSAR CP分层架构中， 自上而下分别为应用软件层（Application Layer）、运行时环境（Runtime Environment）、基础软件层（Basic Software Layer）， 如下图所示。

AutoSAR CP的架构图

AutoSAR CP的应用软件层包含若干个软件组件，软件组件间通过端口进行交互。每个软件组件可以包含一个或者多个运行实体，运行实体中封装了相关控制算法。运行时环境作为应用软件层与基础软件层交互的桥梁，为软硬件分离提供了可能。基础软件层又可分为四层，包括服务层、ECU 抽象层、微控制器抽象层和复杂驱动。各层又由一系列基础软件组件构成，包括系统服务、存储服务、通信服务等，它们主要用于提供标准化的基础软件服务。

AutoSAR CP主要特点是面向功能的架构（FOA），采用分层设计，实现应用层、基础软件层和硬件层的解耦。在AutoSAR CP架构下，所有应用都是静态配置的，一旦软件编译完成就不可更改，其调用的周期也是确定的。

汽车软件开发究竟有何不同?

首先，是复杂性（Complexity）和异质性（Heterogeneity）。正如我们上面展示的那样，汽车行业和智能手机行业的一个关键区别在于它们的复杂程度。在过去的十年中，智能手机行业通过标准化和抽象化解决了技术的复杂性。今天的智能手机高度集成了多层抽象和接口。而汽车行业仍然受到高度复杂性和异质性的困扰。此外，高水平的抽象使智能手机行业能够封装大部分硬件复杂性，使其能够处理软件层面的复杂性。

时至今日，交通工具仍然是复杂的系统。汽车中的每个子系统，从刹车到动力系统，都是由不同的供应商提供，并与独特的软件架构集成在一起的复杂实体。复杂程度和系统之间无缝互操作性的需求远远超过了智能手机。

另一个关键因素是，汽车行业面临客制化需求：许多汽车的配置都是根据客户个人偏好定制的。用户偏好和不同地区的法律法规的差异（比如我国和欧美国家道路行驶方式的差别）都导致了大量的产品变体。此外，不同的功能需求，比如家用厢式车、敞篷车、卡车，导致了更多不同的型号、配置和变体。因此，每个汽车型号的产量通常比每个智能手机型号的产量低得多。

其次，是功能安全（Functional Safety）。当我们考虑到汽车的功能安全要求时，“车轮上的智能手机”的比喻就显得不合时宜了。车辆设计的首要目标是降低风险，这是一个寻求降低潜在危险的过程。例如，传感器可能故障而产生错误速度信号，这个风险可以通过引入冗余传感器来降低：额外的传感器可以交叉验证信号，从而最大限度地减少出错的机会，提高车辆的整体安全性。因此，虽然“车轮上的智能手机”简洁地描绘了软件在车辆中的重要作用，但它其实没有完全涵盖到汽车行业必须采用的安全标准与风险防控策略。汽车不仅仅是一个简单的移动设备——汽车是一个复杂的系统集合，而且必须将安全性、功能性和便利性放在首位。

与智能手机不同，汽车必须遵守严格的安全标准，如ISO-26262等。ISO-26262标准主要涉及车辆内电气和电子系统的功能安全，根据三个因素对风险进行分类：严重性(可能发生的潜在危害)、暴露程度(风险情况可能发生的频率)和可控性(驾驶员预防危险的能力)。通过评估这些因素，这一标准能够有效平衡了汽车设计中的创新和安全性。

为了量化风险，该标准采用了一个被称为汽车安全完整性等级(ASIL)的框架，如图1-3所示，该框架根据严重程度、暴露程度和可控性对故障可能导致的危险事件进行分类。风险等级从最低的ASIL A级到最高的ASIL D级不等。ISO-26262定义了在每个ASIL中应用的要求和安全措施。

ISO-26262标准定义的汽车风险等级

这里还包括一个称之为QM(质量管理)的类，它管控的是那些只需要标准的质量管理过程的功能，因为它们对安全的潜在影响较小。例如，与安全相关的功能，如制动系统，将被分配为高ASIL评级，而车载娱乐系统将被分配为QM评级。控制刹车的软件需要遵守比娱乐系统更严格的安全标准。

最后，则是软件开发的思路和方法，我们更愿意称之为两个世界的碰撞。这里的两个世界指的是传统物理汽车世界和未来的数字汽车世界。从早期的电子功能(如安全气囊、车辆稳定和制动系统)到现代驾驶辅助系统，甚至是自动驾驶，汽车工程历来都对物理(Physical)功能更加重视。然而，由软件驱动的新一代数字化(Digital)车辆则对改善用户体验更加感兴趣。相比之下，新一代数字化车辆则建立在技术领域的最佳实践基础之上，包括敏捷方法和云开发等。

传统汽车的研发模型遵循“V流程”，层层递进、相互关联，各个环节都有严格的限制和不灵活的交付期限，导致软件难以实现快速开发和变更。对于传统车辆来说，软件只有嵌入硬件后才能进行测试，这延长了软件的迭代周期，延迟了用户需求的响应。这是因为传统物理车辆工程的目标是“设计复杂的、满足功能安全、安保和实时性要求的系统”并“满足政府批准的产品上市标准要求”。

传统汽车的研发模型——“V流程”

未来的现代汽车应当是这二者的融合：我们必须将传统工程的可靠性与现代软件开发的敏捷性结合起来。为了实现汽车产品的敏捷迭代，软件和硬件的研发应该分离并独立验证，这样软件和硬件就可以在不同的周期内发展。同时，需要注意的是，车辆研发具有必要的安全基线和独特逻辑，因此直接照搬信息和通信技术领域的研发模式是不可行的，如敏捷开发。有必要将传统的车辆研发模式与信息和通信技术领域的研发模式进行有效整合，而这无疑是给汽车行业提出了一个重大挑战：能有效解决“两个世界的冲突”的制造商才最有可能取得成功。

两个世界的冲突——数字(Digital)世界与物理(Physical)世界

“两个世界的碰撞”到“两个世界的融合”的灵丹妙药是什么？SDV能解决这个问题吗？

为了解决“两个世界的冲突”，软件定义车辆(SDV，Software-Defined Vehicle)的想法应运而生。对于传统汽车来说，硬件既是充要条件，软件只是辅助，而对于未来汽车来说，硬件只是基础必要条件，软件才是决定用户体验的充分条件。

软件定义汽车是一种全新的汽车概念，它将软件定义网络(Software-Defined Networking，SDN)和网络功能虚拟化(Network Function Virtualization，NFV)技术应用于汽车领域。通过将汽车的网络和功能抽象为软件，可以实现汽车的灵活性、可扩展性和安全性的增强，为用户提供更多个性化的智能服务。它是架构设计由软件决定的车辆，其功能、性能、服务和体验主要取决于软件。SDV是一种可彻底编程的汽车：新功能可以在几个月内开发和部署，而不是几年；有额外的计算能力；可以在未来持续交付更新。

软件定义汽车的关键是将汽车的功能实现从硬件中解耦出来，并将其抽象为软件模块，通过软件定义网络进行配置和管理。而传统车辆组件子系统中的软件嵌入在硬件中，软硬件高度绑定的结果就是车辆功能和性能的固化。传统汽车中的许多功能都是由硬件实现的，例如车载娱乐系统、车辆控制系统等，这些功能无法根据用户需求进行灵活配置和升级。为了提高汽车软件的灵活性以获得更好的用户体验，传统汽车的组件子系统在SDV中将逐渐分层，并减少不同层次技术要素之间的耦合。软件定义汽车则通过将这些功能实现抽象为软件模块，使其可以根据用户需求进行随时配置和升级。

SDV的概念与智能汽车并不相同。SDV是打造智能汽车的举措，智能汽车是SDV的外在表现之一。

如目前您所看见的这幅图所示，SDV汽车架构由传统汽车架构演进而来，其中，硬件将被标准化并抽象为功能硬件，而ECU则专注于计算，变为计算平台，计算平台和功能硬件之间，使用E/E进行架构，从而形成车载硬件底座。

SDV汽车架构图

软件则拆分为具体业务应用与驱动，驱动演化为车载基础软件。在SDV描述的架构中，车载基础软件由操作系统内核、中间件和SOA服务层组成，可促进不同子系统和领域之间的数据聚合和交叉使用，其中：

• 操作系统核心（OS Kernel）：典型的汽车操作系统内核包括 Linux、QNX 和其他实时操作系统，每个内核负责管理一个或多个子系统的软件和硬件。

• 中间件（Middleware）：中间件是分布式系统之间的通信技术，可以屏蔽底层差异，向上提供统一的数据聚合（API）。

• SOA服务层（Service layer of SOA）：SOA是一种以服务为基本组件的软件架构，通过服务的排列和组合形成应用软件。SOA的服务层将稳定、重复的汽车功能封装为服务，提高了上层应用的灵活性和复用性。

基础软件之上是针对具体业务场景的应用软件。应用软件可分为功能应用和服务应用。功能应用通常涉及硬件控制和安全，服务应用则与内容服务和信息娱乐相关，如充电、异常检测和能源服务。

车辆SDV/SOA化给我们带来了什么好处？

一旦我们实现了SDV汽车，SOA和以API为中心的工作方式将会使得我们能够在技术与组织层级上实现松耦合。

我们可以根据车辆API创建和实现原型。这些原型可以用于从客户和管理层那里获得非常早期的反馈。接下来，对早期的SDV原型进行改进，使其更接近实际应用。在早期开发阶段，这些SDV应用程序可以利用API背后的车辆模拟（Vehicle Simulations）来创建真实的测试环境。一旦真正的车辆硬件被生产出来，就可以直接取代车辆模拟。由于API没有变化(至少在理想情况下是这样)，并且SDV应用程序是根据API实现的，因此从车辆模拟到真实车辆硬件的转变从SDV应用程序的角度来看将会是无缝的。

此外，开发用户软件的团队能够使用模拟器，他们可以以自己的速度进行开发，由于API模拟独立于真实硬件，因此他们无需关心硬件的可用性。这种方法将硬件在环(Hardware-In-the-Loop, HIL)和软件在环(Software-In-the-Loop, SIL)的成熟概念提升到了另一个层次。

这种软硬件分治的策略能解构复杂工作，确保复杂性降低到一个人可以承受的水平。其中API扮演了“主时钟”的角色，帮助在不同价值流中的不同团队之间同步工作。SDV将成为解决两个世界冲突的灵丹妙药。

硬件在环(HIL)和软件在环(SIL)分离

目前汽车行业SDV/SOA化的进展如何？都有什么SOA解决方案？

那目前汽车行业SDV/SOA化的进展如何了呢，又都有什么SOA解决方案出现了呢？敬请参考本系列第二讲：软件定义的车辆(SDV)技术深入研析（二）

本文主要引用与参考：

• 塞班系统（SymbianOS）还能用吗（塞班系统失败的根本原因）

https://www.xyzshouji.com/4038.html

• 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/

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

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