车载软件架构 — 赢得汽车软件开发竞赛

我是穿拖鞋的汉子,魔都中坚持长期主义的汽车电子工程师。

老规矩,分享一段喜欢的文字,避免自己成为高知识低文化的工程师:

做到欲望极简,了解自己的真实欲望,不受外在潮流的影响,不盲从,不跟风。把自己的精力全部用在自己。一是去掉多余,凡事找规律,基础是诚信;二是系统思考、大胆设计、小心求证;三是“一张纸制度”,也就是无论多么复杂的工作内容,要在一张纸上描述清楚;四是要坚决反对虎头蛇尾,反对繁文缛节,反对老好人主义。

不觉间来到八月,横坐在电脑前,敲击点文字,对自己也算一个时间的记忆,多年后再次点击,也期待那时会像触发记忆的闸口,让现在的这点岁月传递至那时那刻。

一、背景信息

传统原始设备制造商(OEM)正致力于缩小与创新型市场新进入者在汽车软件开发方面的差距。有针对性的改进可显著加快其发展步伐。

多年来,汽车原始设备制造商一直试图通过汽车的款式、质量和性能在市场上脱颖而出。如今,软件开发已成为另一个首要任务。随着汽车越来越依赖软件来实现所需系统和功能,并创造独特的客户体验,传统原始设备制造商在开发速度、质量和成本方面一直难以跟上步伐,这主要归因于其遗留的系统架构。

传统原始设备制造商正迫切寻求加快软件开发进程,以与特斯拉、蔚来和比亚迪等企业保持竞争力。要成功做到这一点,仅简单复制速度更快竞争对手的方法和流程是远远不够的。传统原始设备制造商拥有涵盖内燃机汽车(ICE)和电动汽车(EV)的更广泛汽车产品组合,以及由此产生的一系列遗留架构、流程和系统,这些都极大地增加了复杂性。此外,我们对软件开发四个阶段(需求与架构、电气与电子(E/E)开发、功能开发和生命周期管理)的研究发现了一系列阻碍原始设备制造商发展的根本原因。

要解决这些根本原因,原始设备制造商需要在所有四个阶段改变方法。本文为传统汽车原始设备制造商提出了一系列可提高透明度、协调性和协作性的措施,以加快软件开发速度。

二、新进入者凭借软件打造卓越产品

过去十年间,在消费者需求和监管压力的双重推动下,汽车行业在电气化、互联化和自动驾驶等领域取得了巨大技术进步。如今的汽车配备了由中央到更本地化的控制器组成的网络,可对汽车所有领域(如动力系统、运动、能源、信息娱乐、自动驾驶和互联)的大部分功能进行管理和监控。

车辆的域控制单元或中央计算机的电气与电子(E/E)内容(如先进的信息娱乐系统和驾驶辅助技术)水平越来越高,这已成为普遍趋势,从而提升了豪华性、安全性和性能特征。此外,汽车行业还见证了座椅、转向(线控转向)和电子系统等的集成,以及全球车辆平台的采用,以简化生产、创新和维护。支持这些电子控制单元(ECU)的软件代码可达1亿行,这使得软件开发成为原始设备制造商的首要任务。1

这些发展重塑了竞争格局。创新型新进入者(尤其是那些专注于电动汽车和自动驾驶汽车的企业,如特斯拉、蔚来和比亚迪)正日益占据市场份额。在相对较短的时间内,这些新进入者通过彻底重新思考产品开发流程,并利用以软件为中心的开发和纯电动汽车(BEV)的优势,重新设定了行业标准,强调更短的开发周期、新的交付模式和不同的运营模式。“软件速度”已成为新进入者上市时间的关键,它们在自动驾驶和信息娱乐领域建立了领先功能。

这些趋势使得传统原始设备制造商和一级供应商在软件开发方面远远落后(图1)。从开发项目开始到软件发布,它们通常需要40至50个月的漫长周期。在需求冻结后,从架构和基础软件开发到首次集成发布(可实现初始用户体验和完整的端到端测试)可能需要超过1.5年的时间。从这一点来看,在市场推出之前,仍可能需要一到四年的时间才能达到最终软件发布。

相比之下,创新型市场新进入者设计并开发一款新车仅需24至30个月。其优势包括:在开发过程中更早地部署软件,拥有更稳健的软件发布周期;在投产(SOP)前后实施持续部署流程;具备高度的软件复用性;以及严格部署通用软件平台。供应商领域也呈现出类似趋势。一些中国公司能在两年内推出新型电驱动平台,且成本仅为欧洲传统供应商的20%至30%,而欧洲传统供应商通常需要四年时间才能将新平台投入生产。

传统原始设备制造商通常需要较长的测试阶段来调试软件,并在测试阶段提高发布频率,这导致软件版本分支众多,修复漏洞面临挑战。此外,它们的空中下载(OTA)技术能力较弱,无法在车辆投入使用后修复漏洞。

传统原始设备制造商与新进入者在方法上的差异还不止于此。原始设备制造商往往不重视漫长的需求和架构阶段,而倾向于开展雄心勃勃的测试和集成工作,这导致需求质量低下,电气与电子(E/E)架构和软件架构不佳。2新进入者则更注重合理但更短的需求和架构阶段,这种方法能加快初始软件发布速度,实现更快的软件迭代周期、更好的OTA性能,以及更顺畅的测试和集成。

三、结构性和运营性挑战

原始设备制造商认识到,要想跟上新进入者的步伐,必须在软件开发方面另辟蹊径,然而在当前环境下优化软件开发流程仍面临挑战。

传统原始设备制造商(OEM)管理着多样化的汽车产品组合,包括内燃机汽车(ICE)、纯电动汽车(BEV)和插电式混合动力电动汽车(PHEV)。与新进入者(基于所提供的车型)相比,传统原始设备制造商产品组合的复杂度差异可达150倍。为了适应这一范围,传统原始设备制造商同时开发了多个软件平台。同时维护和升级这些多样化的平台,加剧了复杂性和资源分配的挑战。

数代以来塑造了原始设备制造商的结构和文化,也使得它们难以采用更为敏捷的方法。例如,传统原始设备制造商为以硬件为中心的汽车制定了一套流程,以便将汽车拆分为功能部件,由内部和外部的传统工程师团队按照瀑布模型进行开发。这一流程的特点是开发周期漫长,缺乏灵活性,无法促进快速的软件创新。

传统原始设备制造商还难以吸引顶尖的软件人才。它们的竞争对手——国际科技公司,能够提供更具吸引力的薪酬、文化和流程。因此,传统原始设备制造商常常由传统工程师或技术项目负责人来管理软件开发。虽然他们能够引导供应商完成流程,但缺乏软件工程和开发方面的核心竞争力,无法与团队有效协作或提供更有效的指导。

所有这些因素共同造就了一个极其复杂的硬件与软件集成开发流程。当原始设备制造商在汽车V模型(图2)中未能建立左右两侧之间的系统性联系时,难度会进一步加大。

除了架构惯性和根深蒂固的流程之外,许多原始设备制造商面临的另一个根本性挑战在于技术采用速度的差距日益扩大。具有敏捷基础的市场颠覆者正在迅速整合人工智能和云原生解决方案。相比之下,传统企业则处于严重的竞争劣势,因为它们难以利用这些变革性技术。

四、识别软件开发问题的根源

为加速软件开发进程,原始设备制造商(OEM)必须找出导致延迟的潜在根本原因,而非仅仅试图解决表面症状。我们的分析识别出了11个独立的根本原因,其中4个贯穿整个流程,其余则集中在特定阶段。

1、整体流程

-> 软件交付流程不透明

原始设备制造商通常在发布规划和跟踪方面投入不足。质量关卡(确保软件在进入下一步前满足所有要求)可能在开发过程中定义模糊且频繁变更。关键指标,如功能间的依赖关系、测试覆盖率以及端到端系统的通信矩阵或待办事项列表,往往未得到充分跟踪或考虑,导致投产(SOP)延迟数月甚至数年。

-> 缺乏先进的端到端工具链

端到端工具链可确保整个软件开发过程的一致性,例如,用于需求定义和功能开发与测试的进度跟踪。自动化接口等功能可减少行政工作量,实现持续集成和持续部署(CI/CD),因此高性能工具链至关重要。原始设备制造商通常从众多供应商处采购工具链,导致接口标准化和自动化程度有限,端到端数据骨干网络发展不足,以及所需功能(如虚拟化测试)短缺。

-> 忽视适当的项目和风险管理

了解可能的障碍和整体关键路径有助于指导复杂的软件平台开发。若没有系统性的总体项目计划来汇总所有领域的个别计划和相互依赖关系,特定领域(如集成周期或单个功能测试)和跨领域(如足够的测试资源可用性)的障碍可能无法被发现。例如,单个功能分支存在多个或不一致的计划可能阻碍项目和风险管理,使原始设备制造商无法进行现实评估,包括确定可实现的软件发布日期和后续投产日期的风险。

-> 按顺序瀑布式分工

传统汽车原始设备制造商的开发流程通常遵循经典的V模型,并受长期基于瀑布模型、专注于硬件的开发历史影响。若将这种行为应用于软件开发的四个阶段并简单叠加,会导致低效的分工。V模型左侧定义需求的团队不参与右侧针对需求的软件测试,导致整个V模型缺乏端到端视角。

2、需求和架构

-> 需求管理松散

最佳实践是在最终软件发布前约两年确定需求。若初始需求不够详细,原始设备制造商将面临延迟达到冻结和评估软件组合的初始里程碑的风险。此外,在流程后期或官方冻结后向组合中添加新软件功能的情况并不罕见,这需要对电子控制单元(ECU)之间的通信进行更改(在最坏情况下,还需进行架构更改),导致资源短缺和评估需求的时间不足。

-> 供应商互动和协作效率低下

在许多原始设备制造商中,供应商是软件开发的重要贡献者,提供了必要的能力、专业知识和产能。然而,他们通常在架构冻结后才被纳入流程,导致原始设备制造商无法在架构概念阶段利用供应商平台和知识。因此,原始设备制造商指定的技术解决方案可能既昂贵又复杂,将开发和测试工作推向下游。

-> 软件和硬件开发缺乏同步

传统原始设备制造商通常遵循经典的V模型和瀑布式开发流程进行硬件开发,时间线长达三至七年。相比之下,软件开发采用快速迭代周期,需要频繁更新和灵活性。关键问题是硬件和软件开发之间缺乏同步,特别是在V模型的早期和晚期阶段。

3、电气与电子(E/E)开发和更新

-> 集成周期长且软硬件集成复杂

在传统原始设备制造商中,由于存在多个并行软件分支、需求和集成管理不善以及架构划分和碎片化不佳,软件-硬件集成周期可能变得复杂。例如,在需要对ECU之间的通信信号、控制器局域网(CAN)和本地互连网络(LIN)进行升级时,确保已开发软件功能的稳定性可能需要超过20周的时间。变更请求管理不善可能导致新漏洞的晚期发现或产生,而团队可能缺乏洞察根本原因的可见性,无法高效全面地修复软件问题,进一步减缓软件-硬件集成速度。

4、功能开发和集成

-> 发布管理

软件交付周期内的高频发布虽出于好意,但可能导致版本控制问题,并增加修复漏洞和错误管理的额外工作量。若再加上CI/CD工具链不佳,原始设备制造商可能最终将更多资源用于管理发布和手动集成,而非软件开发本身。高频发布还会在测试车队中部署的发布范围和重叠软件版本方面产生歧义。

-> 自制或外购决策及代码或知识产权所有权

传统原始设备制造商仍将大量软件工程能力外包。对供应商和工程公司的依赖可能在开发周期中带来挑战。例如,供应商可能在不提供源代码可见性的情况下交付软件,使原始设备制造商无法了解实施更改和更新功能所需的工作量。这种信息不对称也限制了原始设备制造商在软件生命周期内就修复漏洞和发布的成本进行谈判的能力。

-> 端到端测试策略

大规模有效测试软件需要一种全面方法,涵盖从组件到系统再到车辆的集成步骤。此外,必须首先开发基础软件和操作系统,并利用测试自动化和虚拟化,这需要先进的测试基础设施。许多传统原始设备制造商依赖工程师的集体经验,但未利用现场可用的关于客户行为和产品性能的大量数据。因此,它们在数据驱动工程和虚拟工程能力方面存在不足。

5、原始设备制造商如何加速软件开发

基于这些根本原因,我们认为传统汽车原始设备制造商可以采取多项行动来加速软件开发,但也需要一级供应商的贡献。拟议的变更涵盖软件开发周期的四个阶段。

-> 优化需求定义

在需求和架构阶段,原始设备制造商(OEM)必须精心优化需求定义,以有效管理变更,确保软件无缝集成。一个重要变革是,原始设备制造商应基于明确定义的功能基线设立严格的需求冻结点,以此作为后续所有开发和软件集成活动的基础。优先级需求应反映对成本、利润和可行性的平衡、现实考量。尽管法律要求至关重要,但功能需求可根据竞争力必要性、利润贡献和期望程度进行排序。强有力的管理对于防止冻结后添加宽泛需求以及强制实施需求优先级排序至关重要。供应商在此阶段的参与不可或缺。

需求冻结后建立完善且明确的需求变更流程,可在不影响整体交付的情况下处理任何修改。此外,利用生成式人工智能(Gen AI)等先进技术创建需求、起草描述和推导规范,可加速这些任务,并确保规范符合行业标准。

-> 与一级供应商的合作模式

原始设备制造商应在需求和架构阶段初期就与供应商展开合作。这有助于各方在需求以及技术概念或平台的采用上达成一致并进行迭代,而无需进行复杂的调整或变通。如此可得出更具成本效益且开发周期更短的解决方案。然而,为避免对供应商产生依赖,原始设备制造商应在软件开发过程初期就明确代码和知识产权的所有权。

-> 电子控制单元(ECU)通信网络的稳健性与“增量”流程

加速软件交付的一个主要促成因素是高效的架构,该架构集成功能,以尽量减少开发周期中通信矩阵(电子控制单元网络及其在车内和与外部系统的通信)的“关键”变更。若变更影响到需要通过新的、冗长的道路测试来获得批准的组件,则被视为关键变更。原始设备制造商应考虑区分通过“增量”流程评估实现的更快的内部认证(评估软件代码和流程中的变更与修改,以满足质量、安全和合规标准)和专门的、冗长的道路测试。这种方法涉及设计系统以隔离电子控制单元配置和安全关键软件模块等元素,从而减少频繁调整的需求。

在测试期间,具备足够的空中下载(OTA)技术能力可通过远程访问数据和运行模拟来进一步提高开发速度。此外,原始设备制造商还可利用OTA技术持续向实地车辆推送升级,以及提供按需功能(FoD)和新功能。此类能力可实现高效的漏洞修复,并在车辆生命周期内保持软件的竞争力,同时减轻原始设备制造商在投产时交付完整无缺软件的压力。

-> 集成和测试阶段的软件交付周期

优化集成和测试阶段的软件交付周期频率至关重要。原始设备制造商通常认为测试越快越好,但过于频繁的(手动且孤立的)测试可能导致版本控制问题,增加供应商成本,并导致重复漏洞和更复杂、耗时的漏洞修复过程。为应对这些挑战,原始设备制造商可降低交付频率,从而减少软件版本数量。此外,在一个软件版本上完成测试后再测试下一个版本,可防止重复漏洞,并实现更高效、捆绑式的漏洞修复。这些变更可简化测试流程,降低复杂性,最终产出更高质量、更可靠的软件。

-> 云原生架构和容器化作为基础促成因素

虽然持续集成/持续部署(CI/CD)至关重要,但只有向云原生开发架构和广泛容器化进行基础性转变,才能充分发挥其潜力。这一战略举措可实现真正的微服务方法,促进卓越的模块化、弹性和无与伦比的可扩展性。容器编排平台(如Kubernetes)所提供的固有灵活性和快速部署能力,可直接转化为显著缩短的开发周期和更稳健、频繁的软件发布。这代表着从传统基础设施模型的巨大转变,使原始设备制造商能够与领先软件公司的敏捷性和快速迭代能力保持一致。

-> 架构师在流程中的作用

架构师应参与整个V模型开发过程,包括测试和集成阶段。在电气与电子(E/E)开发和功能开发期间,架构师可确保解决方案按照基础架构概念和原则进行开发,同时帮助快速修复问题。

在功能开发期间,架构师可考虑功能与特性在功能提升过程中的依赖关系,并在集成过程中加以考虑。在测试和集成阶段,他们可帮助实施概念变更,领导车辆集成和漏洞修复,并根据整体性能和架构边界,以最小的架构影响实现高效解决方案。如此,他们可确保最初定义的概念在整个发布过程中得到一致遵循。原始设备制造商还应考虑让架构师参与生命周期管理,为OTA更新做出贡献,并验证未来更新是否具备足够的计算能力。

-> 利用人工智能和机器学习加速开发

为真正实现下一代开发速度,原始设备制造商必须积极地将人工智能和机器学习(ML)融入整个软件生命周期。这一努力涉及战略转变,即利用人工智能驱动的代码生成工具,这些工具可自动完成大量常规编码工作,大幅缩短新功能的开发时间线。此外,采用智能、人工智能驱动的测试框架将改变质量保证方式,能够在周期早期主动识别并解决缺陷。

除了开发和传统维护之外,先进的人工智能和机器学习能力正开创车内智能的新领域。应用包括高度复杂、人工智能驱动的高级驾驶辅助系统(ADAS)和自动驾驶平台的基础要素。这些系统利用实时数据融合、复杂感知算法和预测行为建模,不仅实现安全功能,还能持续学习,提升驾驶体验和车辆性能。这种级别的人工智能集成不仅仅局限于添加功能,而是重塑车辆生命周期内的交互和能力的本质。

-> 更敏捷、基于系统工程的运营模式

寻求提高软件交付能力的原始设备制造商应采用一种运营模式,该模式将敏捷原则与真正的系统工程方法相结合,贯穿所有阶段。这一模型将开发过程分解为可管理的系统和子系统,每个系统和子系统都需要专门的架构师和集成商,以确保开发周期在整个开发过程中顺利进行。这些团队必须在整个开发周期内保持稳定,以促进持续集成和对齐。为此,原始设备制造商必须打破原有的顺序瀑布式模型。应在资源计划中保护子系统团队在整个阶段的持续参与,防止资源被重新分配到其他项目。参考数据库可帮助原始设备制造商根据基准更严格地规划团队能力,并就自身资源的部署和供应商在过程中的贡献做出更明智的决策。

采用这些变革将提高所有阶段的软件开发速度。我们的基准分析表明,原始设备制造商可将软件开发周期的总持续时间从2.0年缩短至1.5年,并调整开发阶段的分布如下:需求和架构可优化至总分布的25%至30%(目前为15%至20%);E/E开发和更新可优化至15%至20%(目前为35%至40%);功能开发和集成可优化至50%至60%(目前为45%至50%)。

延长的架构阶段将为原始设备制造商提供更多时间来指定、开发和冻结需求,从而提高需求的稳定性。同样,延长的功能开发阶段将实现更早的首次发布(最小可行产品)和更多自下而上的测试。

采用上述变革性措施的原始设备制造商需要在所有领域谨慎实施。这些变革需要时间,并应融入整个开发周期。此外,通过打破各自原始设备制造商的遗留惯例和边界条件(如要求每个开发周期进行两次冬季测试),可以增强措施的影响。

简化传统原始设备制造商的软件开发流程还需要全面的变革管理策略。领导层可倡导创新和持续改进的心态,并辅以强大的治理结构来监督流程。关键绩效指标(KPI)可衡量变革的影响,跟踪进度并确定进一步改进的领域。原始设备制造商可以从一个与现有项目完全脱节的新软件项目的端到端试点开始,为试点投入专门的团队和工具,并建立一个基于系统工程原则的明确指导模型。

-> 培养专业软件人才

通用软件工程师的竞争异常激烈,但对于原始设备制造商而言,真正的战略要务在于培养专业软件人才。这一举措需要积极的策略来吸引和留住在高级人工智能和机器学习工程、数据科学、网络安全以及专业的开发运维(DevOps,软件开发和信息技术运维)角色等领域高度熟练的人才。吸引这些稀缺专家需要一个超越传统薪酬模式的、有吸引力的雇主价值主张。同时,对现有工程团队进行强大且持续的技能提升和再培训计划投资也是必不可少的。这些计划确保内部能力随着技术需求的发展而发展,使员工能够实施和维持如今已成为标准的先进、数据驱动的软件解决方案。

软件已对汽车竞争格局产生巨大影响,未来几年这一动态将更加明显。对于传统原始设备制造商而言,简化和加速软件开发势在必行。这一努力需要持续投入资源和精力,但成功可带来公平的竞争环境。

缩小与创新市场进入者差距的最有力杠杆之一可能在于大规模合作。例如,如果欧洲的一批传统汽车原始设备制造商进行大规模合作,打破壁垒,共同开发未来车辆的软件基础,会怎样?将Catena-X等倡议扩展为一个供原始设备制造商、供应商和软件开发商使用的安全共享网络,可加速创新,降低集成成本,并实现更智能、更安全车辆的创造。

另一个大胆举措是联合开发开源汽车软件。通过共享核心软件组件(如操作系统和面向客户的功能)并标准化应用程序编程接口(API)和开发工具,欧洲传统原始设备制造商可解锁新的商业模式,消除低效环节,并使整个汽车软件生态系统具备未来适应性。德国汽车工业协会支持的11家汽车公司(包括原始设备制造商、一级供应商和软件供应商)最近签署了一份开发开源软件的谅解备忘录,这是朝着这一方向迈出的一步。这种级别的合作不仅可增强行业的竞争优势,还可培育一个更敏捷、更具韧性的生态系统,能够塑造未来出行方式。现在正是采取紧急行动的时候。

搁笔分享完毕!

愿你我相信时间的力量

做一个长期主义者