赋能新一代软件定义汽车

摘要：在过去的二十年中，汽车软件的需求和应用急剧增长，随之复杂性急剧上升。现有技术和框架不足以应对这种复杂性，现在很明显，汽车制造商（OEM）必须重新考虑他们生产车辆的方式以及车辆本身的生命周期。通过将重点放在软件上，OEM可以在车辆整个生命周期中实现许多新的应用用例，并打开一个充满机遇的新世界。博世及其子公司ETAS在过去几十年中一直处于汽车创新的前沿。

通过他们的专业知识和与汽车制造商的密切关系，他们正在亲身经验体验软件复杂性的增加和开发概念的改变。本文介绍为了赋能新一代 “软件定义汽车 “，OEM所必须采取的改变其当前技术栈的步骤。

介绍

在过去的二十年中，软件组件在塑造汽车行业方面发挥了主导作用。汽车制造商（OEM）正面临着新一代的买家，他们希望拥有一辆可以满足所有新愿望的个性化和互联的汽车，软件甚至正在成为OEM的决定性区别和销售论据。根据波士顿咨询集团（Boston Consulting Group）的数据，目前汽车行业90%的创新来自软件[1]。同样，据麦肯锡[2]预计，汽车电子和软件市场的增长速度将远远超过整个汽车市场。驾驶员辅助系统的基于传感器的环境检测和广泛的信息娱乐产品只是客户期望他们的车辆所具备的软件定义功能中的两个示例。

在未来，实现更高级别的自动驾驶功能、提供即时错误修复并持续提供新功能将成为新的规范。后者似乎很熟悉，因为智能手机市场经历了一场类似的革命[1]，现在已经成为客户数字生活的中心。车辆多样性和固有管理复杂性的增加，要求新的软件和硬件的开发方式。因此，在软件和硬件开发解耦的情况下，需要从传统的V模型向持续开发和集成的转变。尽管汽车制造商需要进行大量的初始投资来开发和建立新的电气和电子（E/E）架构及其软件平台，但预计他们每年将避免在测试、集成和维护多个领域获得160亿美元的节省[3]。

现有的方式将软件引入车辆有明显的主要局限性。OEM依赖分布式E/E架构和整体的软件架构，由于开发新功能以及更新现有协议栈所需的复杂度和工作导致了测试、集成和维护成本很高[3]。由于缺乏速度和巨大的开发成本，汽车设备制造商无法快速进行试验和创新。因此，这限制了他们满足单个客户需求的能力，从而限制最大限度地利用车辆的整个生命周期的价值。

很明显，当前的开发理念不再合适，行业需要转向以软件为中心的方法[3]。基于软件的功能需要“可靠、快速反应并在车辆使用寿命内快速更新”[1]。通过重新思考汽车的生产方式，将以软件为中心，汽车设备制造商可以提高其客户忠诚度，并在其生命周期内增加汽车的价值。例如，特斯拉Model S在购买七年后比其竞争对手更保值，这归功于其始终最新的软件协议栈和功能更新[1]。

本文旨在涵盖技术解决方案，使原始设备制造商能够成功地从“耗费大量精力和成本的软件创新和更新”转向“自动、连续、快速、轻松地将任何数量的软件功能交付给任何期望的车辆”。

二

成功转向软件定义车辆（SDV）意味着什么？

为了释放SDV的全部潜力，必须通过在云端和车辆中运行的合适的工具和软件解决方案来理解和掌握几个挑战。

2.1硬件和软件解耦——SDV的基础

在过去的几十年中，汽车设备制造商主要从不同供应商处采购电子控制单元（ECU），作为一个组合的硬件-软件系统，以功能为中心，并承受较高的成本压力。因此，系统级的集成工作随着每一个新的子系统呈指数增长，计算资源在预生产定义的功能范围内得到优化，开发工具链专门针对OEM、供应商和功能特定需求进行项目实施。因此，实现的功能代码从一个车辆项目转移到另一个几乎是不可能的。

同时，汽车行业一直面临着车辆软件功能数量和交付频率的增加[1,3]，涉及数量不断增加的ECU。这种复杂性导致了集成工作的泛滥，成本飙升，项目持续时间更长。麦肯锡表示，过去十年，软件复杂性增长了4倍，而开发生产力仅增长了1.0至1.5倍[4]。

因此，必须采取三项主要行动：

减少ECU的数量，同时增加计算资源，以降低硬件复杂性并提高其性能。

协调OEM内部的基础软件及其底层开发工具链，以实现跨车辆平台的车辆功能兼容性。

引入开放接口和面向服务的体系结构，以简化OEM、其供应商和开发人员之间的协作和集成。

因此，OEM目前引入了硬件和软件生命周期的解耦，允许将通常分布在几个区域ECU和车辆计算机内的多个ECU上的功能捆绑在一起[2,5]。车辆中的这种新E/E）架构简化了功能部署，同时需要更高的计算资源和工具来支持管理依赖性和变量。

2.2选择标准化中间件

集中式E/E架构正在推动平台软件方面的大规模技术变革，需要根据领域的不同而扩展一系列功能。AUTOSAR Classic[6]为安全和硬实时ECU提供了全面的解决方案。该标准在汽车行业被广泛接受和采用，涵盖多个网络的诊断和安全通信等服务，通常是发动机控制器、变速器ECU等所必需的。

随着车载计算机的引入，另一个标准与经典一起被定义，这就是AUTOSAR自适应标准[6]。尽管共享了大部分基本原则，但目标却截然不同，因为AUTOSAR自适应旨在为基于POSIX的ECU提供一组集群式服务，其微处理器能够执行车辆范围的功能，以增强驾驶员体验。

最近，LINUX（独立或与信息娱乐集成）上非安全通用计算环境的采用受到了越来越多的关注。在这个称为车辆边缘，像容器化这样的云原生方法针对汽车用途进行了优化。这使得能够进一步简化和加速车辆应用程序的集成，同时通过隔离实现封装和安全性。

当涉及到支持汽车中最先进的技术功能，转向自动驾驶时，汽车操作系统（AOS）为ADAS功能引入了一个完整的新开发模式，涵盖了整个开发周期以及实现ADAS功能的中间件平台软件。领先的汽车原始设备制造商正利用其非常有效的方法采用此类技术。

2.3使用云开发工具链简化和加快开发速度

在理想的世界中，开发人员有一个随时可用的开发环境，支持他们检查更改并从自动化流水线系统收集反馈。经过少量调整和迭代后，他们一直在开发的功能就准备好发布了。如果他们是由分布式开发团队组成的更大组织的一部分，那么他们将连接到正确的代码库，所有开发人员将在一个共同的协作平台中同步。最后，作为流水线系统管道的一部分，自动生成认证和其他发布手续所需的文档。

然而，汽车行业的现实情况却大不相同。开发人员将60%以上的时间用于维护开发环境、手动执行大量测试、处理文档（包括其他手续）以及最终发布代码。

汽车云开发工具链和协作平台旨在通过结合汽车领域的专业知识以及云技术提供的可能性。通过使用标准化接口，现在可以集成第三方工具。这使开发人员能够专注于创建新内容，而不是维护现有工具。由于自动化流水线系统，开发测试和反馈周期可以加快。云技术还为OEM内部不同团队及其供应商之间的协作平台提供了基础。

2.4快速轻松地开发车辆应用程序

来自终端消费者和高性能软件驱动的竞争对手的压力越来越大，迫使原始设备制造商提高其软件交付性能。这种性能可以通过几个关键性能指标（KPI）来衡量，如功能交付周期、部署频率、恢复时间或更改失败百分比。

通过选择经过验证的云原生模式并将其用于汽车，可以显著减少软件开发持续时间。例如，通过将容器隔离、开发人员为中心的工具链和车辆API相结合减少软件流程负载。这种方法为从ECU上的ASIL环境（具有不同的安全等级）到车辆计算机上的质量管理（QM）环境（没有安全要求）的业务逻辑转变打开了大门。

从车载软件的角度来看，需要一个异构的车辆边缘QM环境，以便在车辆内便捷开发、部署和运行应用程序。为了加快开发，开发者商不必履行任何与安全相关约束。相反，运行环境与基础E/E和安全架构相结合，确保车辆始终处于安全状态。

此外，这种方法在软件人才招聘方面带来了进一步的好处，汽车行业在聘请足够熟练的开发人员以C或C++等编程语言进行经典汽车软件开发方面面临越来越大的困难。通过上述现代软件开发方法，OEM拥有的或第三方开发人员能够使用他们选择的现代编程语言开发基于容器的应用程序，并专注于差异化的业务逻辑，而不是处理安全问题和汽车特定流程。

2.5虚拟测试软件

原始设备制造商面临的一个关键问题是软件开发过程即将结束时的“大爆炸”集成，其中一些问题被发现，导致车辆生产延迟。

对对于车辆的开发，有不同的角色。每一个都有不同的测试关注点。功能开发人员对底层协议栈或操作系统不感兴趣，但他们希望了解他们对功能KPI（针对ASIL）产生的影响。软件集成商希望验证功能增量（快速反馈回路），而无需运行在基于硬件的设置。安全工程师希望检测软件中的异常和弱点。测试工程师希望能够尽早开始（前置）验证所有功能。

更重要的是，需要基于不同版本的软件进行回归运行测试以实现可比性，即执行不同代码版本的重复运行，并检查它们是否导致相同（确定性）结果输出。一旦报告了现场错误，就需要在实验室（电子取证）重现情况。

面临的挑战在于建立一个足够模块化的测试解决方案，以支持所有用户，无论在哪个开发阶段，在这种情况下，以下能力是效率的重要标准：

加快测试，例如，避免等待几天来完成回归测试

自动化测试，例如，在后台进行实际测试时更改配置并获得反馈。

SDV方法允许独立于硬件的可用性来解决这些问题。上述用例和角色视角清楚地表明，虚拟测试解决方案需要

模块化和标准化，

适用于自动化（无头，CI-CD-CT），

可以在云中进行扩展，以按需处理回归峰值，从而优化成本。

因此，OEM可以从旨在解决这些需求的解决方案中受益，该解决方案采用模块化和标准化的云虚拟测试解决方案，以实现高效开发，并向第三方供应商开放。

2.6在影子模式下采集现场数据

在不可能指定和验证所有驾驶或环境情况（例如，“开放环境”或“开放世界”问题）的所有系统中，良好的确认和验证（V&V）策略会增加很高的价值。

影子模式是这种V&V策略的重要组成部分。新开发的数据驱动功能或算法在真实条件下在目标环境中执行，以获得“真实世界”输入数据。影子功能不会主动控制驾驶系统，而是以静音模式运行，并通过使用可配置的基于AI的过滤器和触发条件从系统收集相关数据。功能、过滤器和条件通过OTA部署到一个系列车队。

而收集的输出数据则通过OTA传送回云后端进行分析和进一步处理。

2.7大规模部署和管理软件

软件和硬件生命周期的为SDV建立一个连续的软件开发和部署过程。车辆因此能够不断地适应其当前的需求。结合部署个性化车辆应用的能力，现场硬件软件组合的多样性使每辆车都独一无二。数字维修也是如此：预计每辆车每年会更新数百次大量电子部零件、应用程序和服务。因此，SDV对灵活更新的需求将大幅增加。

传统的OTA更新解决方案需要大量的手动工作来创建更新包（内在依赖关系管理）和管理活动。这种繁琐的方法在当今车辆中跨异构软件域管理更新时已经显示出了局限性。因此，现有的解决方案不再适应来处理由于SDV所需的软件更新数量和种类不断增加带来的挑战。

为了克服这些挑战，易特驰正致力于下一代OTA更新解决方案，该解决方案的灵感来源于云原生模范式[7]。基于声明性方法[8]，授权车辆单独识别其必须执行哪些操作（例如，“下载”、“安装”、“更新”、“删除”）以达到预期的状态。

下一代OTA更新带来以下好处：

通过上下文感知流水线并通过应用基础设施即代码[9]原则，自动生成和验证车辆的各个预期状态，

减少云后端的量和依赖性管理工作，

减少通过移动网络传输并存储在云中的数据量，

通过统一的车载更新API对所有车载域进行更新，如Linux/QNX OS、AUTOSAR经典/自适应中间件和应用程序、Container/AAAOS框架和应用程序以及ADAS/AD系统。

2.8从现场正确的数据中提取、分析、学习和改进

在“真实世界”条件下从现场车辆和设备收集的数据是各种用例的重要来源。例如，来自连接车辆的诊断数据用于检测和解决质量问题，旨在减少召回活动和软件故障。基于传感器的环境检测依赖于雷达、激光雷达或摄像头，正被用于ADAS/AD功能的背景下的数据驱动开发。

然而，通过从车辆中收集数据，必须在收集不必要的数据和冒着丢失有价值的数据之间进行权衡。前者可能导致昂贵的流量、存储和处理成本，但后者可能导致缺乏适当决策所需的相关数据。由于正确的权衡在很大程度上取决于用例，OEM应在车辆外部上有一个灵活的数据通道，以便在需要时仅收集相关数据。

除此之外，数据不仅来自现场，还来自各种来源。为了充分利用其价值，必须将收集的数据提供给公司在世界各地的开发团队，甚至是其它公司的开发团队，例如从OEM到Tier 1。因此，需要解决的挑战有两个方面：1.为数据共享创建法律基础的组织基础；2.建立接口和工具的技术基础，以方便提取、处理和分析车辆现场数据。

在这种情况下，成功的基础的关键标准是：

可扩展性和资源效率，其中集中式的一次性集成实现了针对多个用例快速载入不同的数据源

标准化，以便转化来自不同来源的异构数据

卓越运营，依靠可扩展的全球数据基础设施来确保数据可用性。

2.9遵循法规和标准

最近，汽车行业很少有法规和标准受到关注。在这方面最需要强调的是描述车辆软件更新要求的第156号UNECE法规[10]。特别是OEM需要提供“软件更新管理系统（SUMS）”正常运行的证据。SUMS是一种系统化方法，它定义了组织过程，以符合软件更新管理和部署的要求。这种方法：

解决软件更新是否会影响任何已有的系统，

使用RxSWIN（RX软件识别号）生成已有系统的唯一识别软件版本，

评估软件更新与目标车辆的兼容性、更新系统的相互依赖性、通知车辆用户更新的能力以及车辆所有软件更新的记录。

这种方法还包括车辆类型的专用功能。软件更新的真实可靠性和完整性应通过以上步骤获得保证。

更新失败也是需要进行管理的，例如，通过将系统恢复到以前的版本或进入安全状态。还需要确保OTA软件更新之前、期间和之后的车辆安全。

在这种情况，ISO/FDIS 24089[11]标准的目标是支持第156号UNECE法规的执行。用于解决执行软件更新的基础架构、涉及的车辆和车辆系统、软件更新包的开发以及软件更新活动的运行。目前，ISO文件仍处于起草阶段，计划于2023年初发布。

2.10确保软件环境的安全，防止黑客入侵

随着车辆功能由软件定义，从而变得更加通用，相关安全风险预计会不断变化，并可能增加。这对于定义安全风险的两个因素来说是正确的：1.成功攻击的潜在影响（特别是在自动驾驶领域）2.成功攻击的可能性，因为更高的软件复杂性与漏洞概率的增加直接相关。当今的安全方法主要集中在车辆开发和设计阶段，因此需要延伸以覆盖SDV生命周期。

此外，需要通过持续的安全监测和风险管理来修改安全方法。这些概念包括以下功能：

利用入侵检测系统检测车辆中的潜在入侵，

通过车辆安全运营中心持续监控车队安全并统筹攻击迁移

通过各自车辆和云端能力来阻止和/或应对新发现的攻击

2.11在基于开源的生态系统中合作

过去，汽车行业在构建新技术时通常面临两种选择：“制造与购买”。虽然“制造”选项提供完全控制，但在就开发和运营而言，它是最昂贵的选项。它需要稀少而多样化的技能，最终可能会成为难以在市场上成功且跨车系或品牌复用率低的一个利基小众解决方案，另一方面，“购买”选项可能会导致供应商或技术锁定，从而降低在市场上差异化的可能性。

其他行业已经成功地展示了通过利用开源社区而带来经过验证和充分测试的优势，例如免于技术锁定、广大技术人员的力量、可靠性和免费测试、缩短上市时间或提高安全性。

将其适应汽车行业提供了一种更灵活、更平衡的解决方案以摆脱“制造或购买”：开放式SDV计划推动所需技术在非差异化构造块上的开发和增强。因此，汽车行业可以分享基于在一个开放技术平台、标准，和以开源车内协议栈为中心的框架上的成就。利用开放标准和供应商中立的治理模式可以避免市场分裂，并为OEM提供广泛采适用的技术平台和解决方案。此外，在这些开放的、经过测试的、无差别的要素上构建软件可以释放出宝贵的开发人员资源。Eclipse SDV工作组、COVESA联盟或SOAFEE项目在这些上是公认先进的典范。

三

结论

软件是OEM满足客户期望的关键差异化因素。由于它解锁开启了新的使应用用例和收入模式，也成为了延长车辆生命周期的推动者。

对软件的巨大需求和增长导致OEM面临多项挑战，例如处理复杂性，同时保证整个技术链的安全性，以便将新软件引入车辆。本文全面概述了这些挑战，并概述了OEM为成功克服这些挑战所需要的技术方案。这些方案涵盖了汽车价值所在定位、使用哪些开发工具、需要考虑的相关云服务和车辆组件等方面的心态理念转变。在这个前提下，强调了行业法规和基于开源生态系统的必要性。同时把上述那些不同的构造块结合在一起，将使OEM及其解决方案提供商能够简化、加速和自动化软件的创建和测试，以改进开发、节省上市时间并降低成本。

审核编辑：刘清