沃尔沃两吨半重车型软件开发全流程揭秘

安德斯·贝尔指着自己满头银发笑道：“三年前，这还是一头金色卷发。”这位沃尔沃首席工程与技术官的自嘲，远不止一句调侃。它精准折射出这家传统汽车制造商过去五年的真实处境：在毫无现成蓝图、没有任何供应商能提供现成方案的前提下，从零起步，硬生生搭建起一套完整的软件定义汽车（SDV）体系。

核心车型EX60——这款中型纯电SUV于2026年1月在斯德哥尔摩首发，基于沃尔沃全新的SPA3电动车架构打造。今年4月，首辆量产客户车型在哥德堡托斯兰达工厂下线。关键点在于：它是第一辆完全基于沃尔沃自研计算平台HuginCore制造的车型。

正是这套体系，让标普全球出行将沃尔沃的软件定义汽车能力评定为最高等级——Level 5，使其成为全球唯一获此评级的汽车制造商。贝尔用了一个生动的比喻描述这段历程：“就像把一块木炭放在高压下反复锤炼，直到变成钻石。而现在，我们正在打磨这颗钻石。”

统一的“数字脊柱”：HuginCore的核心

HuginCore的精髓在于一套统一的软件主干：一个单一代码库。所有车型的软件都从这里配置和派生，实现跨平台共享。举个例子，当开发者修改某项门锁功能时，代码并非直接提交给EX60，而是提交到这个主干库，再由主干库配置到每一辆相关的车上。

EX90、ES90，再到EX60，每一款基于该主干开发的车型投入使用，都反向强化了这个代码库本身。贝尔直言不讳地指出了其中的逻辑：“这正是苹果和微软的做法。如果你想在软件领域做到卓越，统一的代码库是唯一的选择。”

从阵痛中学习：用户体验是终极试金石

不过，这条路并非一帆风顺。作为平台上的首款车型，EX90在上市初期经历了一段艰难时期。自动化测试未能发现的问题，在实际用户手中暴露无遗，直接影响了体验。“公司内部的磨砺可以接受，”贝尔坦言，“但一旦波及用户，就令人非常遗憾。”

这种自研模式也彻底改变了与供应商的合作关系。过去，一级供应商通常交付完整的、软硬件打包的电子控制单元（ECU）。而在HuginCore体系下，沃尔沃自主研发区域控制器，然后自行集成供应商的软件。“我们不再是从博世拿来一个现成的ECU，”贝尔解释道，“而是必须与他们深度协作，将他们的软件集成到我们的控制器上，确保整个系统协调运行。”

这种转变带来的，是对整车集成层的绝对掌控。而掌控力带来的优化空间，远比架构图上来得深刻。

贝尔举了一个具体例子：在零下25℃的极寒环境中，电池需要防冻保护。传统方案是加装一个独立的电加热器，成本约150欧元。但沃尔沃的团队提出了一个新问题：能否让电机在低温下以略低的效率运行，从而主动产生所需的热量？

答案是肯定的。于是，独立的加热器被取消了。“我们测算过，在电机上增加约8欧元的零件，就能省去其他地方150欧元的部件。”贝尔说。这类跨系统的优化，只有在将整车视为一个集成系统、而非独立模块的拼凑时，才有可能实现。在旧有的组织架构下，这样的对话几乎不会发生。

规模化部署：99.9%成功率的精密手术

统一软件主干在部署层面的威力是实实在在的。目前，沃尔沃正在向220万辆最早可追溯至2020年的车型，推送一次统一的人机交互界面更新，为这些在大语言模型时代之前出厂的车辆，带来标准化界面和谷歌Gemini对话式AI。

“2020年造那些车的时候，我们完全没想到，到了2026年，能在同一套硬件上推出对话式AI，”贝尔感慨道，“那时候，我们甚至不知道大语言模型是什么。”

软件定义的产品永远没有“最终完成版”，总有新功能可以添加。因此，发布的时机判断就变得至关重要。贝尔的标准很务实：“发布的时候，它必须足够出色。”而目标也不仅仅是满足购车那一刻的期望，更是在此后持续给用户带来惊喜。向老车推送AI功能，正是这一理念的体现。

背后的工程逻辑同样严谨。沃尔沃每天构建20个完整的软件版本，每四小时筛选出最优候选，在测试台架上进行全天候自动化整车测试。用户每季度会收到一次实质性更新。

对于这220万辆车的更新，成功率要求达到99.9%或更高。但贝尔对这个数字有着清醒的认知：0.1%的失败，仍然意味着超过两千辆车可能出问题。

“我绝不会在220万辆车上直接按下按钮就一键推送，”他强调。他关注的不是那99.9%，而是那0.1%。即便在这一小部分中，也有严格区分：“一次可以重试的失败更新没什么大不了；但一次导致车辆无法启动的更新，就是灾难。”

因此，部署机制是精细化的。当监控数据显示某一特定市场或车型变体出现故障集中时，该群体的推送会立即暂停，其他车辆继续更新。待问题修复后，暂停的群体才会收到更新。每一次部署，都是一次精密的外科手术。而在这种规模下执行精密操作，需要真正理解自己在构建什么的人才。

人才困境：一个尚未成熟的学科

人才问题，是结构性的。“我们现在所做的汽车软件工程，从规模化角度来看，基本上是一个只有五年历史的新兴学科，”贝尔指出，“所有人都在争夺软件定义汽车领域的领军人才，但这样的人才根本不存在。”

这并非抱怨，而是在描述一个现实：为一辆两吨半重的车辆编写符合ISO 26262功能安全标准的安全关键代码，与开发消费类应用程序截然不同。背景、约束条件，尤其是出错的后果，都天差地别。“关键不是把软件工程师招进汽车公司，而是要在汽车的背景下写代码。”

为此，沃尔沃几乎从零构建了整套环境：工具链、测试基础设施、代码库结构，以及跨多代芯片和多家工厂配置单一代码库的流程。“我们起步时什么都没有，”贝尔回忆道，“没有任何一级供应商能提供现成方案，所有东西都必须自己创造。”

这也解释了为何需要投入巨量资源。沃尔沃在哥德堡的软件测试中心占地2.5万平方米，耗资约2600万欧元。即便如此，贝尔从过去五年中总结出的最重要一课仍然是：“早点开始。千万不要低估这项工作的体量。”

自研与合作的平衡艺术

当然，HuginCore并不意味着沃尔沃走向完全封闭。该平台运行于英伟达的Drive AGX Orin和高通的骁龙座舱平台之上，并集成了谷歌的AI能力。

贝尔坦然承认这种依赖关系的张力：“依赖别人，从来都不是件舒服的事。”他认为，答案在于长期协议和应急规划，而非一味追求垂直整合。“技术在演进，我们也会随之演进。”

更深层的问题是：自研与共享的边界在哪里？贝尔认为，软件栈的底层——如网络安全、更新管理和基础设施——最终将走向商品化。“你是否需要事事亲力亲为，还是可以采购更大模块，甚至与其他车企共担投入？我认为后者是有意义的。”这个问题，在汽车行业乃至整个企业IT领域，都仍在探索中。

核心经验：节奏、准备与组织规模

对于汽车行业以外的技术领导者，贝尔的核心建议或许不在于具体技术，而在于节奏与准备。“进场前先深呼吸。不要企图一口气做太多。不要在第一个版本上设置过于激进的时间表。在确定产品规划之前，先做好扎实的概念验证。”

他还特别提到了一个常被忽视的因素：组织规模。在贝尔看来，沃尔沃可能是西方世界规模最小的独立汽车开发机构。“我们足够大，能够理解所需的规模化程度；但我们又足够小，不会陷入体制僵化，不会被无尽的委员会会议拖慢脚步。”

这种平衡难以复制，但其背后的原则具有普适性——只要你的软件转型必须在硬约束下快速推进，且其后果远不止于屏幕之内。在金融服务、医疗健康、关键基础设施等领域，这套方法论同样值得借鉴。

“我们无法指着任何人说，‘嘿，我们应该学他们’，”贝尔总结道，“我们必须走自己的路，一条没有人走过的路。”这颗由木炭锤炼而来的钻石，尚未打磨完成，但打磨的过程，正在持续定义未来。

Q&A

Q1：沃尔沃的HuginCore平台是什么？它有什么特别之处？

HuginCore是沃尔沃自主研发的车载计算平台，其核心是一套统一的软件主干——单一代码库，按车型配置，跨平台所有车型共享。开发者提交代码至主干库，再由主干库配置到每辆车，这与苹果、微软的软件管理思路一致。沃尔沃因此成为全球唯一获得标普全球出行软件定义汽车最高评级Level 5的汽车制造商。

Q2：沃尔沃是怎么向220万辆老车推送AI功能的？

沃尔沃通过HuginCore统一软件主干，向最早可追溯至2020年出厂的220万辆车辆推送人机交互界面更新，带来标准化界面与谷歌Gemini对话式AI。其部署机制高度精密：每天构建20个软件版本，每四小时自动化测试一次，用户每季度收到一次实质性更新。成功率要求达到99.9%以上，并对异常市场或车型实施分组暂停机制，确保部署精准可控。

Q3：汽车软件工程师为什么这么难招？

汽车软件工程是一个从规模化角度看只有约五年历史的新兴学科，行业内真正具备系统经验的领军人才极为稀缺。为重达两吨半的车辆编写符合ISO 26262功能安全标准的安全关键代码，与开发普通消费类应用截然不同，需要在特定的汽车工程背景下理解复杂的约束条件与安全后果。因此，沃尔沃的解决方案是从零开始，自建全套工具链、测试体系和工程流程来培养和支撑团队。

来源：互联网