软硬件解耦驱动下的SDV变革:技术栈升级与安全验证

摘要

汽车行业正经历一场由软件定义汽车(SDV)驱动的根本性变革。在这一变革中,软件不仅协调车辆功能,还通过服务化重新定义价值主张,使服务成为关键差异化因素,而非物理产品本身。本文探讨了行业从硬件为中心的范式向软件定义范式的转变,通过对科学文献和专利的系统分析,全面综述了软件定义汽车(SDV)的相关研究。文章阐述了汽车架构从分布式计算架构向集中式计算架构的演进历程,探讨了软件定义汽车(SDV)的发展前景与面临的挑战。特别地,本文重点指出了当前存在的关键障碍,包括分散的认证框架、标准化工具链的缺失、持续验证支持不足以及软件维护与维修复杂度的不断上升。其他相关问题还涉及漏洞管理、长期软件支持、供应链去中心化、法规合规性,以及开放数据集、模拟器和基准测试工具的匮乏。软件定义汽车(SDV)的软件核心特性还对硬件的可扩展性和前瞻性设计提出了新的要求。最后,本文展望了未来的发展方向与研究机遇,如生态系统协作、开放式创新、开放标准化数据集、开放式教育模拟器与测试平台、可量化的体验质量(QoX)、认知数据采样以及上下文可观测性等。本研究为软件定义汽车(SDV)如何从根本上重塑汽车技术及商业模式、迈向智能化、服务化的移动生态系统提供了结构化且具有前瞻性的视角。要充分释放其潜力,必须在软件定义汽车(SDV)的全生命周期中解决一系列技术、运营、法规和组织层面的挑战。

一、引言

软件定义汽车(SDV)标志着汽车行业的变革性转变,摆脱了传统以硬件为中心的设计模式,转向以软件为核心来定义车辆功能、性能和用户体验(UX)的全新范式。这一变革与消费电子设备的发展趋势相呼应 ------ 消费电子产品已演变为软件驱动、云连接的平台,能够支持各类新型数字应用和服务,并可通过持续升级不断优化。软件定义汽车(SDV)还推动了汽车行业与云计算行业的融合,将实时控制与可扩展、互联且可持续更新的软件平台相结合。借助计算能力、 connectivity、面向服务架构(SoA)和微服务等领域的技术进步,软件定义汽车(SDV)能够对车辆功能和特性进行更新、增强和个性化定制,且通常无需进行任何物理改装。

软件定义汽车的概念应运而生,部分原因是传统车辆的用户体验具有静态性和局限性。相比之下,智能手机作为可升级平台,能够持续优化用户体验,这也凸显了传统车辆在适应性和功能扩展性方面的不足。与此同时,联网自动驾驶汽车(CAV)的兴起进一步凸显了对现代化、可扩展的云连接架构的需求 ------ 这种架构需实现软件与车辆硬件的解耦。

值得注意的是,现代豪华汽车的软件复杂度已超过先进航空器。例如,F-22 "猛禽" 战斗机的代码量约为 170 万行,波音 787 "梦想客机" 约为 650 万行,而如今的高端汽车集成的代码量可能超过 1 亿行。这些数百万行的代码通常嵌入在车辆中近 100 个电子控制单元(ECU)中,每个 ECU 负责运行一项或多项特定的车辆功能,包括复杂的传感器和执行器网络。这种由数量不断增加的 ECU 组成的分布式架构,其嵌入式软件在车辆售出后无法修改,已不再适合管理未来车辆的复杂性。在新的软件定义汽车(SDV)范式中,所有车辆功能和特性都被设想为软件驱动的服务,理想情况下运行在集中式计算平台上,而非专用的独立 ECU。这一变革以模块化架构为特征,实现了软件与底层硬件的解耦,通过空中下载(OTA)修改或添加特定领域、跨领域及基于生态系统的应用程序或服务,为持续创新创造了新的机遇。

这种向以软件为中心、互联且可持续更新的车辆范式转变,不仅重新定义了车辆的开发和维护方式,还改变了其使用方式和盈利模式。随着软件定义汽车(SDV)演变为可编程平台,它们为围绕服务而非单纯硬件的价值创造模式打开了大门。在此背景下,服务化概念具有重要意义。服务化指原始设备制造商(OEM)从销售产品向提供集成产品 - 服务系统(PSS)转型的过程,其竞争优势不仅来自硬件,还来自增值服务。服务化已成为原始设备制造商(OEM)支持未来经济增长和产品差异化的潜在机遇。通过扩大市场、建立长期客户关系和获得多项成本优势,服务化提供了极具吸引力的价值主张。它不仅包括在传统产品中添加服务,在某些情况下,还涉及用完全基于服务的解决方案替代物理产品。表 1 展示了各类服务化商业模式在软件定义汽车中的应用,凸显了从产品所有权向功能即服务(FaaS)支持的结果导向型服务范式的转变。

表 1、汽车行业服务化商业模式的演进

软件定义汽车(SDV)的架构演进显著增强了原始设备制造商(OEM)适应这些新兴商业模式和不断变化的客户期望的能力。在 "服务仅作为必需品" 的传统模式中,客户主要购买具有固定功能集的物理产品,除偶尔的保修支持外,制造商与客户之间几乎没有额外交易。随着客户需求转向 "增值服务",软件定义汽车(SDV)使原始设备制造商(OEM)能够通过空中下载(OTA)提供按需功能和个性化功能更新。当发展到 "服务作为业务核心" 模式时,软件定义汽车(SDV)固有的灵活性支持订阅制增强功能、按使用量定价和上下文感知功能激活等新商业模式,使原始设备制造商(OEM)能够随着时间的推移动态地将车辆功能货币化。最终,在最成熟的 "服务作为核心业务" 模式中,软件定义汽车(SDV)成为完全以结果为导向的移动平台的赋能者 ------ 在这一平台中,不仅功能,整个车辆都与所有权分离。服务完全由软件协调,按需满足用户需求。因此,软件定义汽车(SDV)架构通过实现软件与硬件的解耦,并支持在车辆全生命周期内提供持续、灵活且以用户为中心的服务,不仅为这一演进提供了支持,更是其根本驱动力。

本文全面综述了软件定义汽车(SDV)的相关研究,分析了行业和学术研究的现状,包括技术进步和障碍。文章探讨了软件定义汽车(SDV)的发展前景以及汽车软件化的复杂性,并聚焦软件在汽车生态系统中的长期影响,展望了未来的研究机遇。通过本综述,旨在为关于软件定义汽车(SDV)的未来及其对汽车行业影响的持续讨论提供参考。

本文其余部分结构如下:第二部分描述软件定义汽车(SDV)的三个发展阶段;第三部分遵循 PRISMA 方法,对软件定义汽车(SDV)相关的科学文献和专利进行系统综述;第四部分探讨软件在汽车行业中的作用,分析汽车软件化的前景与挑战以及行业如何应对以软件为中心的变革;第五部分概述潜在的发展方向和研究机遇;最后,第六部分总结全文。

二、软件定义汽车(SDV)架构的演进

软件定义汽车在架构和功能上都实现了根本性变革。这一变革可通过四个演进阶段来理解:硬件定义汽车 / 软件定义汽车 0.0(HDV/SDV 0.0)、软件定义汽车 1.0(SDV 1.0)、软件定义汽车 2.0(SDV 2.0)和软件定义汽车 3.0(SDV 3.0),如图 1 所示。每个阶段都体现了软硬件分离以及计算模块集群化和集中化的显著进步。

图1、SDV世代

(一)硬件定义汽车 / 软件定义汽车 0.0:分布式架构

传统汽车通常被称为硬件定义汽车(HDV)或软件定义汽车 0.0(SDV 0.0),由分布式的专用电子控制单元(ECU)系统组成,这些 ECU 带有嵌入式软件并连接到车辆总线。在传统汽车模式中,机械和电子部件独立运行,每个功能都有专用的电子控制单元(ECU),并配备集成或嵌入式软件。一辆高端汽车可能拥有超过 100 个这样的电子控制单元(ECU)。嵌入式软件难以更改或更新,车辆依赖固定功能的硬件,导致开发成本高且功能部署周期长。

软件定义汽车(SDV)架构的设计初衷是将这种静态系统转变为更具动态性和灵活性的系统 ------ 通过将应用程序软件、操作系统(OS)和其他中间件与底层硬件解耦或分离,并将它们整合到数量更易于管理的电子控制单元(ECU)中。由此产生的架构更易于管理和修改,通常可通过空中下载(OTA)软件更新进行远程操作。例如, Rivian 的第一代电动皮卡和运动型多用途汽车(SUV)将计算硬件从 80 个电子控制单元(ECU)整合为 17 个,第二代则进一步从 17 个集群化至仅 7 个电子控制单元(ECU)。

(二)软件定义汽车 1.0:域架构

软件定义汽车 1.0(SDV 1.0)引入了基于域的方法,将子系统内的多个功能(如信息娱乐、互联、车身、动力总成、车辆控制)整合到域控制器(DCU)中,域控制器负责管理特定领域或一组车辆功能,如高级驾驶辅助系统(ADAS)或底盘控制功能。这种结构实现了一定程度的软硬件解耦,支持空中下载(OTA)更新,并使系统布局更简洁。然而,架构孤岛依然存在,限制了软件组件的整体可扩展性和可重用性。

(三)软件定义汽车 2.0:区域架构

软件定义汽车 2.0(SDV 2.0)进一步迈向模块化和抽象化。区域架构将底层传感器和执行器管理分配给区域控制器,而集中式计算平台通过高带宽通信网络协调高级功能。这一架构提高了开发和部署效率,降低了布线复杂性,并增强了系统的可扩展性和可更新性。它强化了硬件整合,进一步推动了实时功能升级,提升了功能即服务(FaaS)的能力。

(四)软件定义汽车 3.0:集中式计算架构

软件定义汽车 3.0(SDV 3.0)代表了计算架构的进一步整合 ------ 通过高速以太网通信,集中式高性能计算机(HPC)在分布式区域网关中运行虚拟化软件工作负载。该模型最大限度地实现了软件与硬件的解耦,并支持实时协调。尽管全集中式架构具备极大的灵活性和创新性,但也在软件生命周期管理、网络复杂性、安全验证和网络安全方面带来了新的挑战。

在所有发展阶段中,软件定义汽车(SDV)演进的关键特征和驱动力是软硬件的逐步解耦。在软件定义汽车 2.0(SDV 2.0)和软件定义汽车 3.0(SDV 3.0)中,架构支持完整的技术栈:功能硬件(传感器和执行器)、用于数据交换的电子电气(E/E)架构、计算平台、操作系统内核(如 Linux、QNX)、用于统一消息传递的中间件以及面向服务架构(SoA)层。在这一技术栈之上,从安全关键功能到信息娱乐系统的应用程序软件独立于底层硬件运行。软件定义汽车 1.0/2.0/3.0 这三种模型均支持动态软件开发流程,如持续集成和持续部署(CI/CD)、快速功能迭代以及通过云服务实现客户个性化。软件定义汽车 2.0(SDV 2.0)通过将计算任务分配给区域单元,并利用集中式计算平台处理复杂的跨区域任务来增强模块化;而软件定义汽车 3.0(SDV 3.0)则将所有计算任务完全集中,以优化资源效率,但这也带来了诸如需要统一的高速软件定义网络(SDN)以及单点故障风险等挑战。表 2 概述了硬件定义汽车 / 软件定义汽车 0.0(HDV/SDV 0.0)、软件定义汽车 1.0(SDV 1.0)、软件定义汽车 2.0(SDV 2.0)和软件定义汽车 3.0(SDV 3.0)在关键架构和运营因素上的差异。

表2、软件定义汽车(SDV)架构代际对比:从硬件定义汽车/软件定义汽车0.0(HDV/SDV 0.0)到软件定义汽车3.0(SDV 3.0)

三、系统综述

近年来,关于软件定义汽车(SDV)的研究涵盖了广泛的技术和组织挑战。许多研究提出了新颖的软件定义汽车(SDV)架构和框架,如集中式计算平台、区域架构和基于虚拟化的系统。关键研究成果还包括探索虚拟化和容器化技术,以实现高效的软件部署、性能评估和微服务协调。中间件创新和面向服务设计在软件定义汽车(SDV)的演进中继续发挥核心作用。多篇论文讨论了安全关键和非安全关键软件定义汽车(SDV)应用的资源分配、安全性、网络安全和功能完整性,涉及安全软件更新流水线、诊断框架、混合关键度执行模型和公钥基础设施等。此外,多项研究致力于探究软件定义汽车(SDV)面临的挑战。刘等人探讨了软件定义汽车(SDV)对汽车生态系统的影响,指出了传统开发模式在适应迭代需求方面的障碍。博尔多洛伊等人针对集中式架构的局限性(如时序不确定性增加和最坏情况执行时间(WCET)估算复杂)提出了提高效率的解决方案。潘查尔和王强调了向软件主导架构的转变,强调需要实现软硬件解耦,并整合云连接生态系统以实现敏捷开发。此外,苏雷迪探讨了敏捷方法在汽车行业的整合。探讨了敏捷方法在汽车行业的优势、挑战和机遇,描述了用于软件定义汽车(SDV)跨组织软件整合的跨组织敏捷团队软件嵌入式系统整合(SCATS)框架。这些研究共同强调了敏捷方法和稳健设计框架对确保软件定义汽车(SDV)安全性、可靠性和可扩展性的必要性。

本研究采用系统综述和元分析优先报告项目(PRISMA)框架对软件定义汽车(SDV)进行系统综述,以确保识别、筛选、评估和纳入相关文献的过程透明且结构化。综述涵盖了学术和行业数据库(如 Web of Science、Google Scholar、SAE 数字图书馆、Google 专利、世界知识产权组织(WIPO))的全面检索,使用目标关键词识别与软件定义汽车(SDV)技术相关的同行评审文献和专利。在去除重复文献并排除主要关注自动驾驶或车辆网络(如自动驾驶汽车或软件定义网络)的研究后,对剩余文献进行全文资格评估。为避免与非标准或冲突的缩写(如将 SDV 用于指代自动驾驶汽车)产生混淆,仅纳入明确讨论软件定义汽车的文献。最终分析共包含 2019-2024 年间发表的 171 篇科技文献和 101 项专利。本系统综述全面分析了软件定义汽车(SDV)的研究趋势。

图 2 展示了聚焦软件定义汽车(SDV)的科技文献数量。2019-2024 年间,数据显示软件定义汽车(SDV)相关文献总体呈上升趋势,2019-2021 年增长缓慢,2022-2024 年快速增长。复合增长率显著:2019 年仅有 2 篇文献,2024 年增至 90 篇,2021-2024 年间年均增长率超过 300%。这一趋势表明,软件定义汽车(SDV)研究在此期间获得了广泛关注,这可能得益于技术进步、行业投资或学术聚焦。

图2、关于SDV的科学/技术出版物数量趋势

收集的数据显示,软件定义汽车(SDV)研究在全球分布不均,少数国家主导了大部分研究产出。如图 3 所示,学术界以约 46% 的占比引领软件定义汽车(SDV)文献发表,行业紧随其后(约 35%),学术界与行业的联合研究贡献了显著但占比较小的 17%。数据表明,学术界和行业是主要驱动力,学术界略占优势,而合作发挥辅助作用但非主导作用。

图3、关于SDV的学术界、工业界和联合出版物

德国和美国在软件定义汽车(SDV)科技文献中处于明显领先地位,分别贡献了约 17% 和 13%,这得益于其汽车和技术实力(如图 4 所示)。中国、韩国和印度作为新兴力量紧随其后,而包括日本和法国等传统技术创新国家在内的其他国家占比较小。

在软件定义汽车(SDV)相关专利申请数量方面,图 5 显示,2020-2022 年软件定义汽车(SDV)专利数量快速增长,2023-2024 年有所下降,呈现先升后降的趋势。这一趋势反映了软件定义汽车(SDV)专利活动在 2022 年达到峰值后,2023-2024 年逐渐减少。

图4、关于SDV的科学/技术出版物最多的国家

图5、SDV专利数量趋势

2020-2022 年的早期增长与软件驱动汽车解决方案的兴起相契合,企业和发明者争相获取知识产权。2023-2024 年的后续下降可能表明,软件定义汽车(SDV)的基础技术已获得专利,新的创新点减少;或者行业已转向现有创新的执行和完善,而非产生新的想法。此外,经济状况或法规变化等外部因素也可能影响了专利申请。

软件定义汽车(SDV)专利领域由行业主导,92 项专利来自企业实体,远超独立发明者(6 项专利)和学术界(3 项专利)(如图 6 所示)。这一分布凸显了软件定义汽车(SDV)技术的商业优先级,行业在知识产权开发中处于领先地位。同时也表明,行业注重软件定义汽车(SDV)知识产权的保护,而学术界和独立发明者在专利方面发挥次要作用,凸显了以商业为导向的专利生态系统。

就专利的市场来源而言,尽管全球范围内软件定义汽车(SDV)相关专利的精确评估较为复杂,且不同检索平台可能存在差异,但收集的数据表明,中国占据绝对领先地位,美国和欧盟分别位居第二和第三。大多数中国专利属于 "实用新型专利" 而非 "外观设计专利",这表明原始设备制造商(OEM)和行业生态系统其他参与者注重技术实施。这与文献发表格局形成对比 ------ 在美国和欧洲在文献发表方面占据绝对领先地位。研究结果表明,软件定义汽车(SDV)研究正在迅速扩展,行业优先考虑知识产权保护,而学术界则专注于基础研究和知识传播。地理分布凸显了对软件定义汽车(SDV)技术的战略投资,尤其是来自中国、德国和美国的投资。

图6、关于SDV的学术界、工业界和联合专利申请

四、汽车软件化:前景与挑战

效仿特斯拉、Rivian、Lucid、蔚来、小鹏等新兴电动汽车(EV)制造商,传统汽车原始设备制造商(OEM)正日益采用这种新的软件中心化范式,这有望重新定义车辆所有权体验。这一变革预计将带来诸多积极成果 ------ 从产品开发、制造到最终的端到端消费者体验。部分潜在优势包括:

· 简化架构:软件定义汽车(SDV)的模块化设计支持车辆组件的整合(如标准化线束),减少了布线和整体重量。

· 敏捷且加速的开发:软件定义汽车(SDV)支持软件优先的敏捷开发方法,通过云基仿真、虚拟模型和数字孪生实现早期创新。这种 "左移" 策略将上市时间从数年缩短至数月,并通过最小可行产品(MVP)开发和持续功能交付促进快速迭代。

· 持续功能交付:空中下载(OTA)更新使制造商能够在车辆售出后修复漏洞、提升性能并推出新功能,确保持续优化。

· 功能即服务(FaaS):软件定义汽车(SDV)解锁了高端驾驶辅助、自适应驾驶模式和车内个性化等按需功能,支持灵活的货币化和数字收入流。

· 个性化用户体验:软件定义驾驶舱可适应用户偏好,提供个性化媒体、导航、气候控制和车内设置。

· 提高可扩展性和代码可重用性:统一的软件平台允许同一代码库部署在多个车型上,增强了可扩展性并减少了重复开发。

· 可持续性和运营效率:软件定义汽车(SDV)支持改进的实时、数据驱动和云连接服务,实现更智能的能源使用、优化路线规划等功能,助力更可持续的移动出行。

尽管这些优势标志着向软件定义汽车(SDV)的积极转变,但也伴随着一系列技术、运营、法规和组织挑战。要充分释放软件定义汽车(SDV)的潜力,必须解决这些挑战。以下小节将详细讨论这些挑战。

(一)车辆开发过程中的软件管理

由于软件深度集成到安全关键、性能敏感且高度分布式的车辆系统中,软件定义汽车(SDV)的开发面临重大技术挑战。随着软件定义汽车(SDV)演变为复杂的信息物理平台,工程师不仅要应对系统复杂性的增加,还要满足严格的安全、安保和性能要求。一个关键挑战是协调众多异构软件实体 ------ 这些实体在严格的功能安全约束下实时交互。车辆作为安全关键设备,要求软件在具有不同汽车安全完整性等级(ASIL)的子系统中可靠运行。此外,软件定义汽车(SDV)的动态性和互联性使它们面临不断演变的网络安全威胁,这就要求构建稳健且具有弹性的软件框架。

随着汽车原始设备制造商(OEM)将软件深度整合到车辆开发过程中,行业面临着若干新出现的挑战,包括:

软件作为资产传统上,关键车辆功能由带有嵌入式软件的专用电子控制单元(ECU)控制,汽车行业并未将软件作为经济资产进行管理。与采用会计方法在财务账簿中体现软件价值的技术行业不同,汽车原始设备制造商(OEM)如今面临着重新定义软件经济评估和管理方式的挑战。

互操作性目前,行业内没有一致的方法将软件从供应商交付给原始设备制造商(OEM),也没有统一的方法整合来自多个来源的软件。不同供应商提供的执行相同功能的软件之间常常存在不兼容性,而标准化工具链和验证流程的缺失进一步加剧了互操作性的复杂性。

认证随着软件在车辆功能中的作用日益关键,确保可靠性至关重要 ------ 尤其是在安全关键系统中。这增加了对第三方认证的需求。尽管存在诸如德国莱茵 TÜV 的汽车安全完整性等级 D(ASIL-D)认证等框架,但目前尚无全面的汽车软件认证体系,现有认证方法仍然分散。

测试与验证传统汽车产品开发是一个线性过程,终点通常是量产启动(SOP)。以软件为中心的产品开发面临的主要挑战之一是从传统的 "设计 - 开发 - 测试 V 型框架"转向整合持续集成和持续部署(CI/CD)实践的持续开发周期。这一转变需要采用 "左移"(早期测试)和 "右移"(生产环境测试与监控)原则,要求设计师、开发人员和验证人员之间加强协作。

在汽车领域,"左移" 意味着将测试活动嵌入设计早期阶段,例如通过模型在环(MiL)和软件在环(SiL)仿真、设计阶段的故障注入,以及在硬件可用前对安全关键功能进行自动化单元测试和集成测试。这种早期验证有助于在缺陷修复成本最低时识别问题,并确保从一开始就符合 ISO 26262 安全目标。另一方面,"右移" 强调利用现场遥测、空中下载(OTA)回滚机制和运行时异常检测进行部署后监控和验证,使开发人员能够观察系统在实际工况下的表现。这对于不断演进的软件定义汽车(SDV)功能尤为关键 ------ 在车辆运行过程中,使用数据和运行反馈可以为补丁和改进提供参考。

历史上,汽车系统根据 ISO 26262 标准进行验证、重新验证和严格的安全认证。在持续交付环境中以同等严格的标准发布软件仍然是一个不断发展的挑战。2024 年最近发生的 CrowdStrike 事件展示了仓促向数百万联网设备推送有缺陷、未经审查的更新可能带来的灾难性后果。不难想象,如果这 850 万个目标是安全关键的软件定义汽车(SDV),后果将多么严重。因此,行业必须找到方法,在严格的汽车级验证与持续软件交付所需的敏捷性之间取得平衡。尽管存在功能安全(ISO 26262)、网络安全(欧洲 WP.29)和风险管理(ISO/SAE 21434)等标准,但当前的测试协议和认证方案仍无法满足持续交付的需求。原始设备制造商(OEM)及其供应链必须与德国莱茵 TÜV、Exida、SAE 和 ISO 等认证机构合作,开发更新的流程和框架,以确保安全性和敏捷性。

开源软件采用的问题尽管开源软件在软件定义汽车(SDV)框架中的优势已得到认可,但它们的采用也带来了新的漏洞风险。2023 年,Java 下广泛使用的日志库 log4j 出现了严重的安全问题,所有 Java 应用程序都必须迅速更新以避免恶意代码执行。这是一个典型例子,表明采用开源库可能导致重大安全问题。同样,研究人员在 liblzma 库的 Linux 工具 XZ 中发现了恶意植入的后门,用于绕过正常认证。因此,必须定期扫描所采用的开源代码,以排查任何常见漏洞披露(CVE),汽车行业需要制定应对潜在漏洞的通用策略。

软件安全自 2015 年米勒和瓦拉塞克演示远程入侵吉普切诺基以来,软件安全一直是一个主要问题。白帽黑客暴露了众多原始设备制造商(OEM)的漏洞,包括 Sirius-XM 服务以及宝马、法拉利和梅赛德斯 - 奔驰等品牌的后端系统相关事件。持续扫描硬件和软件库中的漏洞至关重要。软件定义汽车(SDV)的安全性必须从设计之初就予以考虑,并包括对空中下载(OTA)更新的全面保护。尽管 UN R156(SUMS)等法规提供了指导,但仅靠这些法规还不够。验证更新并防止有缺陷软件的传播现已成为开发生命周期的关键组成部分。多项研究探讨了软件定义汽车(SDV)相关的各类安全和安保挑战。例如,提出了 ISO 26262 要求下的功能安全风险分解和优化方法。强调拒绝服务攻击和干扰攻击仍是主要威胁。通过应用自适应信任模型探索了实时入侵响应。指出了将 Linux 整合到安全关键系统中的挑战。讨论了联网软件定义汽车(SDV)中的无线漏洞和攻击面。最后,还提出了许可证验证机制、安全服务调用认证和防篡改车辆数据存储等方案。

(二)维修与长期维护

由于软件定义汽车(SDV)涉及海量软件 ------ 应用层、中间件和硬件驱动程序的代码量通常在 1 亿至 3 亿行之间,其维修工作变得日益复杂。排查或修复损坏的软件需要复杂的诊断工具和专业技能。虽然许多问题可以通过空中下载(OTA)更新远程解决,但其他问题 ------ 尤其是那些受 ISO 26262 等标准约束的功能安全相关问题------ 可能需要现场服务,并需要与半导体或软件供应商直接协作。第三方软件组件的介入(尤其是如果它们引入安全漏洞)可能会进一步复杂化维修流程和责任管理。

除技术挑战外,软件维修和维护的相关成本预计将很高。与传统的第三方物理部件服务提供商生态系统不同,软件定义汽车(SDV)中的软件通常具有专有性,且与原始设备制造商(OEM)的基础设施紧密集成。这种排他性本质上推高了维护成本,并限制了车辆所有者的服务选择。

此外,随着车辆在路上行驶的时间越来越长,产品生命周期内的软件维护变得至关重要。挑战包括维护对旧软件版本的可追溯性,以及确保跨硬件代际的向后兼容性。即使有 ISO 26262和 ASPICE 可追溯性要求,不同时代的软件和硬件之间仍可能出现兼容性问题。另一个日益受到关注的问题是软件中断风险。对原始设备制造商(OEM)更新和支持的依赖增加了以下可能性:如果旧技术的支持被撤回,系统将变得过时。如果原始设备制造商(OEM)或其供应商倒闭、被收购或宣布破产,用户将无法获得关键软件支持或安全补丁,这将进一步加剧这些风险。

(三)"软件优先" 范式下的产品开发

随着软件定义汽车(SDV)架构中软硬件的解耦,频繁的空中下载(OTA)更新有望使车辆始终保持 "最新状态"。然而,这种以软件为中心的范式也对硬件提出了新的要求。

前瞻性设计虽然软件可以随时间更新,但底层硬件最终需要升级。这可能导致车辆生态系统中存在多个硬件版本,从而使软件兼容性变得复杂。模块化硬件设计、芯粒和即插即用组件等理念提供了潜在解决方案,但原始设备制造商(OEM)和供应商之间尚未形成普遍采用的策略。

可扩展性原始设备制造商(OEM)必须在不同车型、价格区间和配置级别中扩展硬件平台。这种可扩展性既要支持向上扩展以提供高端功能,也要支持向下适配入门级车型。值得注意的是,向下扩展通常更具挑战性,尤其是对于旨在高效交付广泛产品组合的高产量制造商而言。

(四)传统与新兴汽车制造商之间的差距

特斯拉仍然是完善其软件定义汽车(SDV)框架的原始设备制造商(OEM)中的佼佼者,美国的 Lucid 和 Rivian 以及中国的蔚来、小鹏、吉利和比亚迪等多家新兴纯电动汽车原始设备制造商(OEM)紧随其后。这些公司采用了 "软件优先" 的全新方法,确保软件在车辆开发和运营的各个方面都处于核心地位。而大众、通用、福特、奔驰、丰田等传统原始设备制造商(OEM)则发现,从以硬件为中心的方法向软件中心化转变更具挑战性。这是 2024 年高德纳(Gartner)数字汽车制造商指数(如图 7 所示)得出的结论。该指数衡量全球汽车制造商的数字成熟度和技术能力,重点关注它们向以软件为中心、技术驱动型企业的转型。

该数字汽车制造商指数从领导力、人才和技术整合等多个指标对 22 家汽车制造商进行评估,包括软件开发、空中下载(OTA)更新的使用、人工智能整合、云采用和数字产品战略等。该指数凸显了每家汽车制造商从以硬件为中心的模式向软件定义、服务导向型平台的转变进展,为其应对不断演变的移动出行格局的准备情况提供了宝贵见解。它反映了汽车制造商如何适应行业重大变革、拥抱新技术(包括互联和软件定义汽车(SDV)范式),并识别出哪些公司在将数字技术整合到其车辆和业务运营方面处于领先地位。深入分析了传统原始设备制造商(OEM)推出软件定义汽车(SDV)面临的挑战。

图7、Gartner 2024年数字汽车制造商指数和2023年的改进。与2023年相比,绿色表示正变化,灰色表示无变化,红色表示负变化

(五)供应链结构的变化

行业的传统供应链正从博世、大陆、采埃孚等一级供应商占据主导地位的层级结构,向原始设备制造商(OEM)可能直接与包括初创企业在内的任何合作伙伴合作的网络状结构转变。一方面,这要求原始设备制造商(OEM)培养传统上属于一级供应商的技能。另一方面,一级供应商以及大型技术公司和小型初创企业必须明确与原始设备制造商(OEM)的最佳合作方式,如图 8 所示。

图8、OEM:组织设备制造商,T1,2,3:分层供应商,S:初创公司,大型科技公司:谷歌、英伟达、AWS等科技巨头

(六)研究与教育障碍

尽管对软件定义汽车(SDV)的兴趣日益浓厚,但重大的研究和教育障碍仍然阻碍着该领域的进展。一个主要限制是,缺乏专门针对软件定义汽车(SDV)开发和验证的开源模拟器、测试平台和实验平台。汽车软件系统的专有性和复杂性限制了获取实际开发和原型设计所需的真实环境的机会。

支持软件定义汽车(SDV)开发和教育的有前景的举措正在涌现。例如,Eclipse Velocitas 提供了用于构建容器化车载应用程序的开源开发工具链,而 digital.auto 的 dreamKIT 和 Playground则提供了模块化的云基环境,用于车辆功能的快速原型设计和仿真。然而,这些平台仍处于采用初期阶段,尚未广泛整合到学术课程或研究流程中。此外,迫切需要可访问、高质量的平台,以支持敏捷的实践实验,并降低汽车软件化创新的门槛。雪上加霜的是,缺乏涵盖异常检测、因果推断和运行时可靠性等关键领域的开放数据集,限制了数据驱动研究的可重复性、基准测试和进展。克服这些挑战对于培养下一代工程师和研究人员,为他们提供在软件定义汽车(SDV)领域进行创新所需的工具至关重要。

(七)可持续性与废弃物问题

软件定义汽车(SDV)对电子和软件组件的依赖日益增加,带来了新的可持续性挑战。最紧迫的问题之一是淘汰问题:硬件和软件的快速发展增加了产生大量电子废弃物的风险。与通常可以修复或重复使用数十年的机械部件不同,数字组件和平台可能会更快过时。

为减轻环境影响,必须将可持续性嵌入软件定义汽车(SDV)的设计中。这包括开发支持可重用性和可回收性的硬件系统,减少产品生命周期内的生态足迹。采用模块化设计还可以简化升级流程,并防止整个系统因单个组件过时而报废。此外,正如电动汽车行业为二手电池创造了二级市场一样,软件定义汽车(SDV)生态系统可能需要探索高科技车辆组件的再利用方案。原始设备制造商(OEM)、半导体供应商和回收商之间的合作至关重要,以确保传感器、芯片和计算单元等组件在原始部署之外能够找到二次利用价值。

(八)法规与标准化问题

软件定义汽车(SDV)开发和部署面临的关键挑战之一是有效的数据治理。随着软件定义汽车(SDV)越来越依赖敏感数据的收集和处理(如位置信息、驾驶行为和车内偏好),在不影响车辆安全或性能的前提下,解决隐私、公平性和数据所有权问题至关重要。此外,遵守复杂且不断演变的全球和区域法规,对汽车制造商而言是一项持续的挑战。确保符合不同司法管辖区的法律要求,增加了软件部署、数据处理和车内服务的复杂性。

另一个主要问题是缺乏专门针对软件定义汽车(SDV)的标准化协议和开发框架。构建以软件为中心的车辆要求制造商采用开放标准,并在可行的情况下利用开源软件。这种方法使汽车制造商能够将有限的内部资源分配给创新和品牌差异化功能及应用程序的开发。为支持这一愿景,过去十年中行业涌现了多个工作组和联盟 ------ 包括汽车开放系统架构(AUTOSAR)、Eclipse SDV、嵌入式边缘可扩展开放架构(SOAFEE)和联网车辆系统联盟(COVESA)------ 致力于软件定义汽车(SDV)生态系统的标准化、互操作性和通用工具开发。例如,Eclipse SDV 等组织在促进开源解决方案在汽车环境中的采用和治理方面发挥着关键作用。然而,随着标准化工作的扩展,这些组织之间的协调变得越来越重要。尽管每个联盟都有独特的章程,并专注于软件定义汽车(SDV)领域的不同方面,但越来越需要加强协调与合作,以避免重复工作并确保协调进展。若无此类协调,各项工作可能会重叠,造成效率低下并减缓行业整体采用速度。

五、未来方向与研究机遇

随着软件定义汽车(SDV)的不断发展,研究和合作机遇正在涌现。这些机遇涵盖技术、运营、教育和法规领域,反映了软件定义汽车(SDV)生态系统的复杂性和多学科性质。本节概述了关键领域 ------ 在这些领域,创新、合作和进一步研究对于解决当前限制并释放软件定义汽车(SDV)的全部潜力至关重要。

(一)生态系统协作与开放式创新推动软件定义汽车(SDV)发展

传统上,汽车行业遵循相对 "封闭创新" 的模式,强调专有技术和严格控制的开发流程。然而,随着软件定义汽车(SDV)架构中固有的 "软件优先" 方法(底层硬件与应用程序软件和中间件解耦)的出现,行业对标准化、协作和开源软件(尤其是非差异化应用)的采用需求日益增加。这一范式转变促进了跨行业协作,吸引了来自云和物联网领域的专业知识,并催生了 SOAFEE、Eclipse SDV 和 COVESA 等新联盟(如前所述)。这些组织分别致力于将云原生技术引入汽车系统、培育开源开发模式以及建立互操作性通用数据格式。

展望未来,加强移动出行生态系统内的协作对于释放软件定义汽车(SDV)的全部潜力至关重要。开放式创新方法为应对软件定义汽车(SDV)开发的复杂性提供了有前景的基础 ------ 在这一过程中,原始设备制造商(OEM)、供应商、软件供应商和云提供商等多个利益相关者必须跨越组织和技术边界进行协调。这种方法可以鼓励共享工具链、联合开发框架和跨平台数据互操作性。一个前瞻性的例子是通用汽车、麦格纳和威普罗联合开发的新型汽车软件市场 SDVerse,该市场旨在为所有原始设备制造商(OEM)、供应商和拥有相关软件产品的公司提供服务。SDVerse 汇集了买家和卖家,以简化软件采购并加速整合流程。扩大此类开放市场和共享创新框架的采用,将有助于缩短开发时间、促进重用,并支持可扩展的模块化软件定义汽车(SDV)架构。围绕开放式创新模式的持续研究和行业协调,将是提升软件定义汽车(SDV)敏捷性、互操作性和可持续性的关键。

1. 开放数据集的开发

尽管软件定义汽车(SDV)功能日益复杂,但针对软件定义汽车(SDV)系统独特特性的公开可用数据集仍然明显不足。原始设备制造商(OEM)和供应商之间的专有限制和分散的数据收集做法,阻碍了可重复性和基准测试工作。为促进创新、加速算法开发并建立稳健的评估框架,软件定义汽车(SDV)研究界必须优先创建、整理和标准化开源数据集,其中应包括多模态数据流(如车辆状态、传感器日志、软件执行轨迹和系统健康指标)。例如,在软件定义汽车(SDV)可观测性方面,整合指标、轨迹和日志的遥测数据集,对于开发和验证实时监控、异常检测、因果分析和自动化事件响应系统至关重要。此类数据集的建立对于促进透明、可重复的研究以及加强软件定义汽车(SDV)生态系统内的跨学科协作至关重要。

2. 开放式教育模拟器与测试平台

软件定义汽车(SDV)研究和教育的进展,需要更加重视可访问、模块化和开源的仿真及测试环境。尽管 digital.auto 的 dreamKIT和digital.auto Playground等有前景的举措已经涌现,但它们仍处于采用初期阶段,尚未广泛整合到学术课程、工业研究流程和培训中心中。缺乏标准化、开放获取的软件定义汽车(SDV)模拟器和测试平台,是实践学习、快速原型设计和跨机构协作的重大障碍。未来的研究和教育工作应优先开发和推广教育平台,使学生、研究人员和从业者能够在可重复和可扩展的环境中,对实际软件定义汽车(SDV)功能进行实验。此类工具对于扩大软件定义汽车(SDV)知识普及、推动创新民主化以及弥合学术探索与工业级实施之间的差距至关重要。

3. 可量化的体验质量(QoX)

国际电信联盟(ITU)将体验质量(QoE 或 QoX)定义为应用程序或服务的总体可接受性,由最终用户主观感知。体验质量(QoX)反映了用户基于技术的实用性和愉悦感,结合其个性和当前状态,对期望的满足程度。在软件定义汽车(SDV)背景下,这转化为用户对自适应驾驶模式、个性化车内设置或信息娱乐服务等功能的满意度 ------ 这些功能越来越多地通过软件定义和交付。体验质量(QoX)受三大类因素影响:系统影响因素(与软件定义汽车(SDV)平台的性能和功能相关)、人为影响因素(包括用户的期望、情绪和偏好)以及环境影响因素(如驾驶条件、交通状况或环境背景)。与传统车辆不同,传统车辆的体验与机械性能和静态功能相关,而软件定义汽车(SDV)提供了动态的、软件驱动的体验,能够实时适应。因此,衡量软件定义汽车(SDV)的体验质量(QoX)需要制定评估不同条件下舒适性、响应性和安全性的指标,以及开发能够根据实时体验质量(QoX)反馈优化车辆行为的智能算法。

4. 认知数据采样

软件定义汽车(SDV)从各种分布式和异构软件实体生成大量功能使用和遥测数据,这些实体包括控制关键车辆功能的嵌入式系统、空中下载(OTA)可更新模块和面向用户的应用程序。尽管这些数据对于改进车辆性能、实现预测性维护、创造新的商业机会和增强用户体验具有不可估量的价值,但它们也给原始设备制造商(OEM)的基础设施带来了巨大负担 ------ 增加了数据收集、传输、存储和分析的成本,并占用了带宽和计算资源。此外,还需要适当的资源来遵守合理的数据隐私政策。为缓解这些挑战,认知数据采样方法至关重要。此类方法并非不加区分地收集所有数据,而是利用上下文线索优先处理最相关的数据。

软件定义汽车(SDV)中数据采样的上下文类别包括多种旨在优化效率和相关性的策略。基于时间的采样根据时间模式(如季节变化或使用高峰期)收集数据。基于位置的采样侧重于特定地理区域(尤其是具有独特道路基础设施的区域)的数据。基于事件的采样由特定的运行、环境或法规事件(如空中下载(OTA)更新、天气异常或合规检查)触发。最后,自适应采样根据系统健康状况、资源限制或检测到的异常等实时条件,动态调整数据收集频率。例如,在出现意外行为时,它可能会增加采样频率;或者在电动汽车中采用能源感知策略。

为确保采样准确性,可以采用分层采样等统计方法,以保持不同车型、使用模式和环境的代表性。此外,实现云和边缘计算的最佳平衡至关重要。边缘计算支持低延迟、实时决策(如碰撞避免),而云平台则提供可扩展的存储和来自聚合数据的人工智能驱动洞察。跨这些层级的战略工作负载分配确保了效率和性能。

此外,在获得适当消费者同意的情况下,进行智能且有针对性的数据采样,对于增强消费者信心也很重要。最近一系列车辆数据泄露事件引发了消费者的不安。与广泛的数据收集不同,更精确和有限的方法(即仅收集服务所需的数据)可以让消费者感到安心。

5. 上下文可观测性

可观测性被定义为从系统外部输出推断系统内部状态的能力,这一概念在软件定义汽车(SDV)中尚未得到充分发展,但对于其安全可靠运行至关重要。需要高效的实时数据收集和分析,以适应动态环境。关键能力包括:持续监控以检测停机、瓶颈或运行异常;因果推断以识别检测到问题的根本原因和促成因素;以及自动化事件响应以实现实时解决,减少停机时间并维持系统可用性。

在软件定义汽车(SDV)背景下,诸如 ASAM 的面向服务的车辆诊断(SOVD)和通常基于 Prometheus 和 Grafana 等开源工具构建的云集成遥测流水线等新兴框架,正在被探索用于支持可扩展的实时可观测性。Grafana、Elastic、Dynatrace、思科系统(Splunk)、Chronosphere、New Relic、http://Logz.IO 和 SigNoz等可观测性平台提供了基础支持,但通常依赖于基于相关性的分析。整合因果人工智能技术(包括因果发现、识别、估计和验证)将提高可观测性精度。此外,这些系统应整合关键上下文信息,如服务级别目标(SLO)、空中下载(OTA)部署日志、网络条件、峰值负载指标和环境因素,以确保获得最佳洞察和自适应行为。通过将原始遥测数据与这些上下文信息相结合,可观测性系统能够区分真正的异常与预期的瞬态变化。例如,它可以识别出与大型空中下载(OTA)部署同时发生的 CPU 突然峰值是正常的、计划内的工作负载,而非性能故障。这种上下文感知能力可以防止误报,在已知高负载期间动态调整警报阈值,并确保仅在偏差超出计划更新和运行参数范围时才触发警报。

六、结论

向软件定义汽车(SDV)的转变正在重新定义汽车行业 ------ 从以硬件为中心的系统转向软件驱动的平台。这一演进引入了模块化架构、持续空中下载(OTA)功能交付以及功能即服务(FaaS)等新的服务导向型商业模式。尽管这些进步带来了显著优势,但也在安全、可扩展性、可靠性和成本等方面带来了重大挑战。这些问题对传统原始设备制造商(OEM)及其供应网络而言尤为复杂。要解决这些问题,需要采用敏捷开发方法和持续集成 / 持续部署(CI/CD)实践,同时维持汽车级质量标准。

本文对软件定义汽车(SDV)领域进行了系统综述,强调了学术界和行业贡献的强度和不平衡性。学术研究通常侧重于基础技术和架构概念,而行业专利则倾向于强调系统整合和商业化。学术界和行业之间需要加强合作,以弥合从业者、学生和研究人员之间当前存在的差距。

综述还确定了关键挑战,包括分散的认证协议、软件作为战略资产的经济管理、测试和验证工具的不足,以及维修和维护成本的上升。其他障碍包括车辆和云系统中弹性软件运行的需求、可扩展的硬件平台、不断演变的供应链结构以及有效的车辆数据治理。此外,开放数据集、测试平台和仿真平台的缺乏,继续阻碍着异常检测和上下文可观测性等关键领域的可重复性和进展。

本文强调了若干未来方向和研究机遇,以解决这些差距并释放软件定义汽车(SDV)的全部潜力。关键优先事项包括促进生态系统协作、采用开放式创新模式,以及推进开放数据集、教育模拟器和测试平台的开发。进一步的研究还应侧重于建立可量化的体验质量(QoX)指标、开发认知数据采样方法,以及增强上下文可观测性框架。

软件定义汽车(SDV)不仅仅是技术的进步;它们标志着汽车向持续演进、软件定义的数字平台的系统性和前所未有的变革。要实现这一愿景,需要在创新、法规、基础设施和人力资本开发等方面进行协调努力,以构建可扩展且可持续的软件中心化移动出行未来。

相关推荐
NewCarRen8 小时前
动态链接驱动的模块化电动车E/E架构云重构方案
汽车软件
慧都小项3 个月前
Parasoft软件测试解决方案助力Renovo汽车ADAS开发安全与合规
自动驾驶·汽车软件·parasoft·renovo
亚远景aspice2 年前
亚远景科技-如何应对汽车软件开发中质量与速度的冲突带来的挑战?
科技·汽车·敏捷开发·aspice4.0·软件研发管理·汽车软件·aspice认证
亚远景aspice2 年前
亚远景科技-如何看待汽车软件开发中的质量管理与传统质量管理的异同?结合ASPICE标准谈谈
科技·汽车·aspice4.0·软件研发管理·汽车软件研发·汽车软件
亚远景aspice2 年前
亚远景科技-ASPICE 4.0 二级 GP2.1.3/2.1.4 Determine和Identify资源的区别
科技·aspice4.0·软件研发管理·汽车软件研发·汽车软件