从硬件定义汽车过渡到软件定义汽车的主要趋势

一摘要

软件定义汽车（SDV）不再是愿景，转型已全面启动，使成熟度成为汽车厂商在竞争激烈的市场中最重要的差异化因素之一。每个制造商都必须经历三个“阶段”才能达到理想的状态。在第一个阶段里，硬件和软件仍然紧密耦合。2.0阶段标志着用例和软件应用程序呈指数级增长的过渡阶段。3.0阶段是终局，这时的汽车主要由软件设置来定义，从而达到完全可编程状态[1]。这听起来像是一种自然进化，但也意味着有若干挑战需要面对。毕竟，我们讨论的不是手机，而是一种具有潜在危险性、技术高度复杂且生命周期可能长达数十年的可移动物体。

虽然已经设定了软件定义汽车的目标，但具体路径仍不明朗 [2]：汽车厂商各自处于转型的不同阶段，并以其自有“历史”E/E架构和嵌入硬件中的软件堆栈为起点。要取得成功，了解从硬件定义汽车过渡到软件定义汽车的主要趋势至关重要。具备了这些知识，人们才可以重新考量汽车的制造方法以及传统方法注定会失败的原因。

在跨入最后一个阶段的过程中，不难发现三个主要趋势领域的转变：从分布式到集中式，从手动到工具驱动，从闭源到开源。汽车行业的所有创新方法都具备一个共同特点，即对这三种转变中的一种或多种具有促进作用。ETAS在移动出行领域拥有数十年的经验，并与汽车厂商建立了密切的关系。因此，本文所描述的趋势都是基于第一手资料和信息。如果各个汽车公司想保持竞争力并从这些转变中受益，而不是被甩在后面，那么了解进入终局时代所需要采取的措施便极为关键。

本文研究的是与软件相关的趋势。与网络安全相关的挑战和原则见“软件定义汽车的网络安全”[3]一文中的阐述。

二导论

要从传统汽车转为软件驱动汽车，制造商需要经历三个阶段。首先，软件和硬件之间的联系仍然十分牢固。如今行驶于路上的许多汽车都是第一个阶段的产物。代码爆炸标志着向第二个阶段的过渡，并且现已成为制造商产品的一个重要组成。软件和数字服务是除硬件组件之外的两个显著特征。我们目前正身处一场竞赛之中，软件定义汽车得到完全发展的第三个阶段这一目标已十分明确。然而，应对诸多挑战的正确方法仍有待探索。从数字上看，代码（所有新功能的DNA）数量正在不断增长，并且我们所谈论的不只是某个单一的汽车单元；产出车型（包括其变体在内）数量将不断增加，每种车型的预期寿命为数十年，并且需要持续维护。

对于汽车厂商来说，这意味着要为每种车型处理各种成套的组件（例如，传感器、控制单元、通信模块等），每个组件都有各自的规格和配置，由不同的供应商提供。因此，跟踪设备版本、固件更新并确保与系统总体设置的兼容性将成为一个主要问题。简而言之：为了满足客户的需求和愿望，缺陷修复、维护和更新所需要的代码数量正在呈指数级增长。如今的汽车代码数量大约为1亿行，而一架客机的代码数量大约为1500万行。换句话说：现代乘用车的代码行数是飞机的6.5倍。这样比较有助于清晰了解这个数字的大小。随着软件定义汽车的出现，行数将进一步增加，到2030年预计将达到3亿左右[4]。在此情形下，汽车行业对代码复杂性管理策略的需求十分迫切。

作为比较，我们可以参考智能手机的转型过程，即智能手机制造商在经过各个阶段后生产出几乎完全由软件定义的产品的历程。虽然用户对于在整个生命周期中拥有灵活、基于应用程序和个性化体验的期望极为相近，但这两种物品的性质却截然不同。一方面，汽车在很大程度上仍然属于机械物体的范畴，其设备、组成和依赖性要复杂得多，即使是最轻微的软件故障也具有潜在的危害。另一方面，它的使用寿命要长得多，使用场景可能也不尽相同。

了解过程的独特性以及通往软件定义汽车之路所伴随的挑战，这一点十分重要。作为一家经验丰富的汽车行业硬件和软件提供商，ETAS不仅洞察全球趋势，并尝试预测其进一步的发展趋势。通过对全球和地区需求的比较，可以发现若干有趣的差异。应该持续观察转型过程，以更好地了解全局（图1）。

 

 

 

 

 

图1：与软件定义汽车相关的各种预测。

三软件定义汽车——全球转型

图2：2021年全球互联车队规模， 2025年、2030年和2035年按地区预测（单位：百万辆）[11]。

迈向第三个阶段的竞赛已经启动，尽管其光芒尚被另一项重大变化——向电动汽车的平行转型——所遮蔽。在这两种情况下，传统的差异化因素（包括品牌忠诚度）都已退居幕后；市场正在重新洗牌。老牌制造商们不能再依赖于良好的声誉或卓越的机械性能，否则，它们将被创新型后起之秀所取代。

例如，欧洲、北美和日本的制造商正在承受着来自中国的压力（图2）。中国汽车只在当地低价销售并且质量堪忧的时代已经画上了句号。现在，它们正在与全球市场上的成熟品牌并驾齐驱，尤其是在电动汽车方面，价格下降的同时创新性功能与日俱增。而从世界范围来看（例如在欧盟和美国），西方汽车厂商却正在提高此类最先进汽车的价格，因为它们在日益复杂的开发工作上投入了大量资金[12]。

研究中国经济的专家Frank Sieren对传统制造商似乎落于人后的原因做出了三点解释：首先，产品面市时间长，例如德国汽车厂商的产品面市时间约为48个月，中国制造商只需要30个月。其次，中国市场希望软件定义汽车比传统汽车便宜，因而迫使地区制造商优化其开发和生产流程。最后，中国买家通常更关注数字化效果而不是外观[13]。

欧盟要求2035年所有售出汽车实现零排放。因此，可以假设，届时将极有可能不再销售搭载内燃机的汽车（又名内燃机汽车，ICEV）。未来的完全软件定义汽车可能会在某个时点成为电动汽车。此外，电动发动机本身将不再是卖点——快速转型为软件定义汽车的重要性因此而再次成为我们关注的话题。

正如我们所看到的，中国制造商已经成为电动汽车领域的主要创新驱动力。但这是否意味着它们在软件定义汽车开发方面也处于领先地位呢？根据预测[14]，2023年至2032年，亚太软件定义汽车市场将成为最振奋人心的市场。但是，北美和欧洲仍被视为该时段里重要的软件定义汽车地区。尽管如此，鉴于中国汽车行业的研发动态和速度令人困惑，其内部存在的一些趋势仍然值得探讨。

在2023年上海车展上，地区制造商们展示了它们的软件定义汽车愿景，并提供了多种内部软件定义汽车解决方案，如中央或跨域计算平台，用以降低汽车开发成本并缩短汽车开发时间。硬件和软件等方面的用户体验也颇受关注，使制造商们能够将需求旺盛的技术（例如娱乐系统）集成到汽车中[15]。在汽车销量激增的推动下，预计到2030年，亚太地区将在嵌入式车载信息娱乐系统市场上占据最高份额[16]。

根据预测，欧洲和北美制造商未来几年将保持其在软件定义汽车行业的市场主导地位，但之后情况如何尚无法判断。亚太地区的客户似乎越来越趋向于从地区汽车制造商手中购买汽车，尤其是电动化、复杂化、互联化、灵活化和数字化的汽车。此外，中国制造商在其他地区的汽车销售数量正在攀升，其全球市场份额也因此而缓慢增加。要想不依赖于汽车厂商及其发源地而扩张至更多全球市场，便需要制造商们以自适应的方式创建解决方案（硬件和软件），从而满足不同地区的需求。

四进入软件定义汽车的终局时代——三大趋势

阶段1

硬件与软件解耦、集中化，以及越来越多的可复用软件功能

阶段2

应用、服务和用例迅猛增长

阶段3

完全可编程的软件定义汽车

图3：在迈向完全可编程软件定义汽车终局时代的过程中，三大趋势占据着主导地位。

核心问题是：目前哪些趋势正在推动着软件定义汽车向前发展，并且，最重要的是，在规划自有变革流程时应该考虑哪些趋势？这不仅是汽车厂商关注的主要问题，也是供应商、第三方开发商和后续合作公司最关切的议题。毕竟，我们都在同一条船上，在汽车的整个生命周期中，加强合作、共享愿景才是关键。

向完全软件定义汽车的转变可被划分为三个主要趋势领域：从分布式到集中式，从手动到工具驱动，从闭源到开源（图3）。在我们深入探讨之前，先看一下顺序。在某种程度上，趋势领域与迈向软件定义汽车理想状态的三个阶段大致相符，集中化是更多工具驱动和自动化汽车开发流程的一个先决条件。并且，我们在这条路上走得越远，整个行业内的合作和协同效应的重要程度就越高。但开源方法的实施需要在该过程的早期阶段得以解决，以便在长期范围内释放其全部潜力。

因此，趋势领域具有紧密相连的特性，它们相互依赖并相互促进。要进入第三个阶段，三者都需要具有极高的成熟度。

五从分布式到集中式：再定义汽车软件

在过去几十年的汽车开发中，软件功能被紧密集成到特定的电子控制单元（ECU）中，由不同的供应商以软件—硬件捆绑包的形式提供。对于功能数量可控的汽车来说，这不失为一种很好的解决方案。随着汽车对于功能的需求不断增长，需要集成的ECU和子系统的数量激增：一辆典型的乘用车目前有大约150个单独的ECU，使其成为一个高度复杂的系统[17]。

当涉及到新功能时，客户期望开发时间更短、速度更快。但由于复杂程度不断提高，汽车行业当前的现实情况却与此相背：开发人员将60%以上的时间花在了维护、检测、文档化和手续办理上，而不是花在开发新功能或满足客户最新需求方面。每当即将推出的车型需要新的ECU捆绑包时，一切都要重新开始。这种以项目为中心的方法使得所实现的功能代码很难从一辆车转移到另一辆车，从而对可复用性形成了制约。

即使车已上路，工作也不算结束，仍然需要频繁地进行软件交付和更新（包括安全相关的更新），而这一切在上述条件下几乎无法完成。根据麦肯锡的说法，过去十年间，软件复杂程度提高了4.0倍，而开发生产力仅增长了1.0至1.5倍[18]。要开启完全软件定义汽车的旅程，首先需要解决的便是这个问题。

此时，硬件与软件解耦以及集中化的趋势已经形成。开发人员并不希望将数百个单独的CPU与其功能特定的代码和工具进行集成，而是希望采取一种协调一致的方法。减少ECU的数量并将功能和计算能力捆绑到少数分区性ECU和汽车计算机上是一个重要趋势，也是遍布世界各地的渴望保持竞争力的汽车厂商面临的主要挑战之一。

将分布式E/E架构重塑为集中式架构不仅涉及IT知识，还会改变我们的合作方式，尤其是在与供应商和内部/外部开发人员开展合作时。这种全新的协作性、快节奏的工作方式只能以有限的程度映射到原有的既定流程中。同时，在DevOps原则范围内也存在着转向迭代开发流程的趋势。采用这种方法可以使汽车整个生命周期中的工作得到持续优化（图4）。

文化层面的考量以及E/E架构的重新安排都是SDV的首要步骤，也是其先决条件。然而，它们对客户本身并没有什么影响。用户不会注意到一项功能是集中受控还是分布到了不同的ECU上。因此，这算不上销售论据。他们能够注意到的是软件连续更新速度加快以及新功能固有的可用性。当前的任务便是以最佳方式利用这些新的开发流程和原则，从而创造附加价值。

DevOps环展示了一种全新的迭代式

软件开发和运维方式

其中以永久性优化为重点

转向DevOps范式，以便在保持质量的同时提高交付速度

图4：向DevOps范式的转变

六从手动到工具驱动：便利性和效率是未来的核心因素

2022年，汽车软件的价值约占整车价值的20%，2030年预计将达到40%以上[19]。从这些数字来看，很明显，汽车的数字化程度将成为未来的差异化因素，最终客户所期望的正是最先进的汽车配置。硬件和软件的解耦本身并不能显著加快开发速度从而满足不断增长的需求，而需要最大限度地减少手动工作量以缩短软件创建和测试用时。必须能够使开发人员专注于实际功能，而不是耗时的任务。

在标准化方面，AUTOSAR Classic作为一种适用于安全性和硬实时ECU的综合解决方案，已被业界广泛接受。然而，随着主要ECU软件功能向集中式汽车计算机转移，AUTOSAR Adaptive因其面向服务的架构（包括功能安全性和软实时功能）而受到若干汽车厂商的青睐。这两项AUTOSAR标准都以减少分布于汽车内各种（通常与安全性相关的）执行器之间的汽车功能的集成和管理工作量为目的。它们采用的是整个行业普遍认可的标准化格式和接口，因此，开发人员不需要每次都从头开始安排工作。

尽管如此，它仍是一种以ECU为中心的方法，重点关注的是安全相关域。每位开发人员都应该深入探究E/E体系结构的细节，即使只想开发一种简单的新功能，例如关于驾驶员舒适性的功能。由此可以观察到将功能性向非安全域转移这种新趋势的出现，即主要利用工具支持的环境（带有可针对汽车API实施的SDK）进行应用程序开发、测试和发布管理。它允许开发人员完全专注于实际功能和用户体验，而无需关心底层架构、安全和保障问题。

在此背景下，用于运行这些功能的各种中间件和框架（即所谓的车载应用）已发布完成。AUTOSAR Adaptive上可以部署安全关键型应用，而非安全关键型应用有更多选项可用。我们看到基于安卓汽车操作系统（AAOS）的信息娱乐应用非常受欢迎。此外，在轻量级容器框架上运行的容器（灵感来自云原生方法）的使用也具有巨大的吸引力。高级驾驶员辅助系统（ADAS）和自动驾驶（AD）中间件[20]以及通常部署在QNX等安全关键操作系统上的应用是一个特例。然而，在进行机器开发和基础架构测试的情况下，可以在非安全域中进行部署。此外，我们最近发现汽车厂商越来越多地要求将功能性转移到非安全关键域，即质量管理（QM）域，以便提高开发灵活性和开发速度。这一趋势随着安全关键型Linux[21]等的发布而有所增强，例如，它可以以串联方式部署ADAS/AD中间件[22]，或者使用受保护的执行器接口[23]来限制和处理对安全域的访问。在这些促成因素的帮助下，开发人员可以灵活地实施QM域中的安全关键功能，同时保持所需的安全级别。卸下了这副担子之后，开发人员不一定要为该制造商工作，也不一定要明确地为某一特定汽车进行编程。接口的标准化使得将软件推广到不同的车型成为可能。这不仅可以缩短开发时间，而且可以以最佳方式利用扩展效果。汽车厂商可以在其整个汽车产品组合中对软件加以“重复使用”。

通过标准化和特定域编程等方法，我们离实现方便、高效的开发流程的目标越来越近。尽管如此，制造商还是低估了流程的复杂性——从设置开发环境到测试、部署和更新，尚有许多步骤需要手动完成。因此，以工具驱动的方式处理DevOps周期的各个步骤是一种日益明显的趋势。这基本上意味着尽可能地实现自动化操作，以便使开发人员能够通过一个直观的界面，为以前复杂的编程任务提供一键式解决方案。预定义的构建块、现成的软件环境、适用于重复性任务的模板、循序渐进式手册以及适用于现有编程平台的汽车特定附加组件使工具箱日益扩大，而不仅仅局限于开发流程。

汽车厂商面临的关键挑战之一是在软件开发流程即将结束时的软件快速集成，这时通常会发现一些问题，导致汽车生产延迟启动。其中一个难点在于设置足够准确的测试环境来模拟真实的行为（以提供详细的反馈信息来查明根本原因），并自动、灵活地运行和重复（回归测试）。在测试和集成方面，采用基于云的工具和环境已经成为大势所趋。例如，从云端进行虚拟测试的方法越来越受欢迎，它允许以所需要的准确度进行ECU模拟，同时最大限度地减少对于成本高昂的真实测试的需求，并显著提高交付速度[24]。

加速软件交付的另一个难点在于通过基于云的空中传输（OTA）进行更新，以便将含有新功能的软件分布于汽车上。根据市场预测，2027年，使用中互联汽车的数量将从1.92亿辆左右大幅增长至3.67亿辆[25]。然而，关键的挑战不仅是对如此多的汽车进行更新，而且是在软件各组件之间的依赖关系不断变化的情况下，对不同车型及其变体的各类更新（例如，AUTOSAR Adaptive、经典ECU、信息娱乐系统更新、连接单元的自行更新、汽车计算机更新、容器更新等）提供支持。汽车连接完成时需要动态地创建活动，以便在几小时内而不是几天内完成所需软件的分布。能够单独执行OTA更新可能很快就会成为一种商品用例，因为许多汽车厂商和软件供应商都非常重视这一主题。因此，问题根本不在于汽车厂商能否提供OTA更新，而在于其具体的差异化因素能否产生速度更快也更加灵活的效果，例如通过依赖关系的自动化处理、综合性测试功能和/或其他增值终端客户功能来实现。

因此，成功的关键在于显著提高从软件创建（例如，用于各供应商实现的ECU）直至在汽车厂商制造的汽车内实现一系列可用性所需要的速度。

汽车行业正在与许多领域竞争开发人才；青年才俊十分罕见。而软件和工具驱动的开发会吸引青年专业技术人才加入该行业，因为这种工作方式（快速、迭代、面向功能且具有创新性）符合他们的需求，使他们可以利用其熟悉的最先进的多用途编程语言，而不用学习复杂且过时的汽车相关语言。他们认为，向软件定义汽车的转变是该行业的重大转变机遇。最新的Edge方法也很合他们的口味，因为他们熟悉基于LINUX的非安全性环境以及利用云端和边缘运算的容器化应用程序。开发团队有来自其他数字化领先行业的青年专业技术人才加入时，其多样化程度将大幅提升，能够引入新的理念，也一定会加快实现软件定义汽车目标的步伐。

七从闭源到开源：个性化、基于云、协同化

当谈到开发工具和集中式平台时，其来自何处是一个主要议题。业内获得软件的传统方式是内部构建或从第三方供应商处购买（构建或购买）。两者各有利弊（图5）。内部开发（构建）使软件本身具有高度的灵活性和定制性，但资源成本高昂。需要在公司内部长期积累专业知识并加以维护。将整个流程外包时（购买），制造商可以十分灵活地选择市场上最合适的系统提供商，但也取决于具体的产品和价格策略，因此容易出现供应商套牢的后果。这两种情况很可能都会导致互操作性有限且难以交换软件组件的专有解决方案。

此外，在这两种情况下，制造商仍然处在受限于少数外部专家或内部专家的境地。而使用开源软件（OSS）则是一种有趣的趋势，制造商可以从社区的协同作用及其对于创新的推动力中受益。汽车厂商已经在通过开源工作组开展合作，这些工作组将迎接业内的各种挑战，例如一般标准化、平台和整个开发工具链。他们的工作成果可免费向所有人提供；规模较小的公司以及软件开发人员可以更容易地参与到该行业中来。其总体思路是，通过提供开放的规范和解决方案，让越来越多的参与者能够在汽车的整个生命周期中提供服务，而无需关注其实际上正在编程的汽车。

图5：构建、购买和OSS的优缺点比较。

开源社区已经成为智能手机和电脑等其他领域的标杆。由于供应商套牢是汽车行业的一大担忧，因此在最初开展OSS计划方面的合作时，人们尚有些犹豫不决，但现在情况已经改变。Eclipse平台上的软件定义汽车工作组[26]、COVESA联盟[27]或SOAFEE项目[28]等获得了整个汽车行业的重点关注也收获了贡献者。例如，Eclipse软件定义汽车项目的成员数量从2022年的11位增加到2023年的44位，同样，OSS项目数量在一年内从0个增加到了22个。

此外，以更加传统的方式组成的汽车联盟AUTOSAR和COVESA正在开展密切协作。2022年10月，这两个联盟都宣布有意在几个软件定义汽车主题上保持一致的动作。COVESA将专注于汽车数据和云交互，而AUTOSAR将为整个系统架构和车载网络提供开放接口[29]。

图6：不同开源社区中多种类型的成员（汽车厂商、供应商、行业巨头、芯片供应商等）对OSS的贡献在不断增长。

一般来说，创造售后收入是汽车厂商的一个重要考虑因素。汽车厂商已经在通过新的数字业务模式和用例对这种升级销售潜力加以利用。开发流程费用高昂并且引入汽车中的新软件需要长久更新，由此看来，这种升级销售的结论也合乎逻辑。新功能尤其重要，因为消费者不愿意为汽车“数字功能性”的保持而付费。他们只是希望软件能正常工作。很少有人会对与机械零件保养类似的持续性软件维护表示赞赏或理解。

因此，汽车厂商和其他服务提供商需要推出创新性应用程序和升级功能或创新性功能，以优化用户体验。软件不仅能定义汽车，还能对其行为负责，例如在突遇障碍物或危险情况时。要提供此类功能，还有一项挑战必须面对，即传统的软件或功能部署方式不再适用。出现问题后，软件定义汽车不再仅仅通过手动读取到的关于错误的消息与其制造商或服务提供商进行通信。现代汽车通过空中传输方式进行连接，不仅可以接收更新信息，还可以在其整个生命周期中将有用的遥测与诊断信息发送到云端。此时，服务提供商拥有无限多的选项：通过交互式诊断和远程诊断获得汽车健康信息、功能执行、按照个别维护计划进行预测性维护，或通过道路状况分析数据选择完美的路线。客户可以利用应用程序和功能对其汽车进行全面的个性化设置，从而为汽车厂商和其他供应商创造持续的收入流。汽车的使用寿命越长，可以出售的服务就越多。

鉴于许多IT公司已进军新的领域，汽车厂商开始与汽车行业以外的IT行业知名企业合作也就不足为奇了。这些公司不仅拥有长期积累的软件开发经验，而且是智能手机或电脑市场上的知名品牌，对客户具有一定的吸引力。近期有许多这样的合作项目对外公布。为了共同构建汽车操作系统，雷诺集团已将谷歌选定为其软件定义汽车项目的一个关键合作伙伴[30]。宝马已与Microsoft Azure、AWS和IBM等多家公司开展合作[31]。通用汽车与Red Hat开源操作系统合作也已启动，主要是在Linux方面[32]。梅赛德斯宣布与谷歌建立战略合作伙伴关系，以整合新的车载数据和导航功能[33]。曾经紧闭的汽车行业围墙正在一堵接一堵地倒塌，这必定将对汽车厂商的工作文化产生重大影响。除了开发流程迭代加速和敏捷性提高之外，汽车厂商还需要利用更现代的方式将所有参与者整合到一起。这便是基于云的平台发挥作用的时候了。

八基于云的平台作为中央加速器

基于云的平台可通过各种工具和用户友好界面为软件开发提供共同的基础，这对于所有三个趋势领域都十分重要。开发人员可以专注于价值创造和域特定的主题，而不是通用的非差异化功能。这些平台具有加速器的作用，是上述许多趋势和用例的宿主。它们能够提供长期的成本效益，并对不断增加的软件开发成本加以控制。

软件的开发和测试从一开始便已得到简化，变为速度更快的自动化流程，从而使面市时间缩短。工作管道由一系列自动化步骤构成，例如，车队更新快速铺开，而无需手动针对每种车型做出活动安排。

云技术也是汽车厂商内部团队与其供应商合作的良好基础。人们可以随时从任何地点进入它的共同工作场地，使合作变得更方便，成本也更低。

与软件即产品（SaaP）相比，软件即服务（SaaS）交付模式对于迈向第三阶段的汽车厂商益处更大（图7）。通常情况下，基于SaaS的服务和平台从一开始就被设计为能够支持越来越多的客户（又称租户）和汽车。它将云原生计算基金会（CNCF）成熟且久经验证的服务和方法用于基础架构、开发、运营和监控，主要针对适用于快速和巨大价值创造的预定义构建块。这使得公司内有限的开发人员/人才能够专注于差异化功能，而不是将时间浪费在商品功能的基本编程方面。同时，有了SaaS平台，汽车厂商便不必再开发自有安全功能以及为了满足法规要求而进行持续改进。基于SaaS的平台不仅要在安全方面经受众多汽车厂商的考验，其为每个汽车厂商提供更多功能的能力也会经受挑战。也就是说，单独的功能请求可被转化为面向所有平台用户的总体益处，从而形成一个整体可靠且功能丰富的系统。SaaS平台通常会提供若干用例。汽车厂商可以首先关注特定的用例，比如OTA更新，然后通过其他用例来扩展其用例组合，比如汽车健康、汽车数据或功能调用。

在成本方面汽车厂商也获益良多。SaaS通常伴随着即付即得的定价模式，从而实现公平且灵活的定价、利用和增长。开发成本由许多需要相同功能的汽车厂商分摊。部署和运营成本由租户共担。此外，可以根据平台上的租户数和较高的汽车数量向基础架构供应商讨价还价，相较一般的汽车厂商与供应商单独接触的情况，价格会有所下降。此外，服务级别合同允许在不使用自有资源的情况下快速解决停机问题和故障。在此种情形下，协作为汽车厂商提供了更大的个性化空间和专注于差异化功能的可能。相比之下，在基于SaaP的模式下，用户仅能获得以价格相对较低的订阅费和支持合同使用该服务的权利，而在所提及的其他几个方面都必须自行管理/组织。

PANTARIS便是这样一个基于云的集成平台，可以提供如上所述的所有必要的服务和工具。它拥有一个与云无关的基础架构，用于在Azure等知名的云上进行可扩展的服务部署和操作。它还提供在云中和整个生命周期上进行汽车连接、管理和操作的基本服务。它能让汽车厂商专注于差异化服务和功能的开发。通过PANTARIS Marketplace，汽车厂商可以获得一整套现成的服务。所有服务都是基于SaaS商业模式，使得汽车厂商能够快速实现其特定用例。

 

图7：SaaS与SaaP的比较。

九完全由软件定义的汽车：我们将走向何方？

毫无疑问：未来的汽车将由软件定义，第三个阶段也终将到来。本文提出的所有趋势将加快汽车厂商进入最后阶段的速度。但是，什么时候才能出现真正“完全由软件定义的”汽车呢？迄今为止，应用程序、功能、代码行或任何其他可衡量的实体方面尚未达到最后的里程碑。此外，无论我们这段旅程走了多远，汽车仍然是现实中运送人员或货物的机械体。电机功能或电池容量当然可以通过智能应用程序得到进一步优化，整体内饰也可以通过灯光、座椅设置、温度和娱乐系统实现个性化设置，但有些物理边界是无法跨越的，它们是由汽车的物理部件所设置。

然而，我们可以在这些有局限性的条件下展望一下未来的软件定义汽车：上午，为了工作的目的而使用一个完全自适应的软件定义汽车，它具备所需要的全部设置，甚至拥有针对该特定时间段的单独的保险。它与一个车队云服务相连接，该服务可提供在车流中完美穿行直至到达各个目的地所需要的全部信息，如果有会议安排可切换至自动驾驶模式。下午，另一位家庭成员在休闲模式下使用同一辆车，搭配运动设置和娱乐套件。之后，汽车在车库里充电的过程中，家里十几岁的孩子上了一堂数字驾驶课，模拟影像被投射到屏幕上。为此目的，包括方向盘在内的消费者可操作部件都会与实际机械装置分离。也可以为行动不便者切换到一种为刹车和油门分配随机按钮的模式。

汽车制造商的开发时间可最大限度缩短，因为整车功能通过经中央计算平台与云端相连的即插即用部件而发挥作用。消费者可以通过应用商店挑选和下载其所需要的每一项功能或服务，差异化由此形成。这些功能或服务由全球开发团队设计完成。该团队由某个主题领域最优秀的专家组成，他们可能在现实生活中从未见过对方，完全是通过在线平台开展工作。即使到了这一节点，关于如何提高汽车的软件定义程度也将有新的愿景出现。因此，迈向第三个阶段的“竞赛”不是关于谁首先达到非现存的目标，而更像是关于保持较快的速度、灵活性和可扩展性，从而在快速满足不断增长的客户需求和其他外部需求方面具备竞争力。而且这不仅仅关系到特定地区崛起的汽车——由于新的灵活性的形成，在全球范围内销售汽车变得更加容易。使汽车适应当地的习俗——无论是法律要求、用户偏好，还是有关天气、温度、路况和使用场景的具体特征——将在很大程度上成为软件更新问题。当某款车型配备了一套最出色的应用程序和功能时，它可以变成“通用型”，在任何情况下都能运行。不过，我们不应将软件定义汽车视为一件非常复杂的商业化产品。它的灵活性使制造商能够以极快的速度应对突发或意外事件。这些事件有可能是气候保护新规出台、汽车共享运动兴起等社会趋势，也可能是全球流行病等灾难，或者政治冲突导致的资源短缺。汽车改装的可能性变得无穷无尽，并有助于克服当今和未来的挑战。

总结

软件定义的汽车面临着诸多挑战。即使每个汽车厂商和供应商的关注点和策略可能不尽相同，我们也会对模式和趋势进行观察，以应对我们在本文中强调的挑战。

我们着重指出，在这条道路上，这些地区的开发速度及其向其他地区的扩张速度极为不同，而这可能会改变汽车厂商和供应商的格局。在此背景下，我们介绍了不同地区的不同关注点、需求、速度、增长情况和数量。我们所阐述的核心问题是：“目前哪些趋势正在推动着软件定义汽车的演变，最重要的是，在规划自有变革过程时应该考虑哪些趋势？”为此，我们将各种趋势划分为需要由汽车厂商及其供应商应对的三个趋势领域：

从分布式到集中式：再定义汽车软件

我们观察到了一种硬件与软件解耦以及汽车计算机中功能集中化的趋势。功能转移和集中化将导致ECU减少。集中化还将改变各方开发人员的协作方式，以便为通用的汽车计算机平台提供功能。同时，协作方式将得到通过DevOps提供的增强型开发流程和范式的支持。

从手动到工具驱动：便利性和效率是未来的核心因素

汽车厂商成功的关键是在对软件不断增长的复杂性加以管理的同时，显著提高其开发与部署速度。在这方面，我们看到，随着主要ECU软件功能向集中式汽车计算机转移的需求的出现，中间件和框架的标准化程度与普及性也在大幅提升。在与框架相关的方面，我们发现，人们对车载应用极为关注。此外，将功能转移到非安全性关键QM域的需求越来越大，这也吸引了人们的注意。通过DevOps进行工具增强是提高关键开发环节（包括自动化、测试、部署和交付）速度的一种日益增长的趋势。虚拟测试环境可对此提供支持，使开发人员能够进一步加快开发速度，同时也便于其集中精力。另一个突出的趋势是通过基于云的空中传输（OTA）进行更新，以便使包含新功能在内的软件分布于汽车的所有域中。

从闭源到开源：个性化、基于云、协同化

整个行业内部的协作和协同效应有所增强。我们发现不同OSS社区中的成员和项目数量增长强劲，并以移动出行为重点。通过OTA更新能够引入新的软件功能（如车载应用），这一合乎逻辑的结论将为汽车厂商和供应商创建新的数字商业模式。因此，我们看到整个软件价值链上出现了许多新的合作伙伴关系。特别是，云计算平台的兴起对上述许多趋势、用例以及新的合作和商业模式起到了推波助澜的作用。

在ETAS，我们每天都会与世界各地不同的汽车厂商和供应商打交道，无论是以直接方式还是通过不同的标准化机构、法规和OSS计划，或是全球政府层面的咨询。因此，我们可以尽早将这些想法转化为产品，以便为供应商、汽车厂商和最终客户提供帮助。

作者

Ismet Aktaş博士

[e-mail]

Ismet Aktaş博士自2023年1月起成为ETAS车云服务解决方案领域投资组合管理和入职培训团队的一员。他之前曾在与微软合作的“软件定义汽车”项目中担任博世方面（OPS-基于云的后端）的工作流主管。此外，他还曾负责博世各种主题的技术工作，涉及不同领域（如汽车、工业、零售）的技术售前、博世不同部门的技术接口和产品/项目管理等方面。他获得了亚琛工业大学的博士学位和文凭，专注于通信和分布式系统的软件架构和跨层优化领域的工作。

审核编辑：汤梓红