登录

软件定义汽车时代,开源软件为何不可或缺


速读:软件定义汽车时代,开源软件为何不可或缺2026年08月18日14:51电子产品世界软件定义汽车(SDV)需要优先上游社区迭代的开源软件(OSS),而非充斥大量本地补丁的闭源构建版本。 以开源软件(OSS)为核心的开发模式,是切实可行的解决路径。 瑞萨电子依托VirtIO虚拟化技术与SparrowHawk硬件平台践行这一理念:开源不只是降本手段,更是一套开发文化。 VirtIO设备虚拟化:软件定义汽车落地的技术基石。
2026年08月18日 14:5

软件定义汽车 (SDV)需要优先上游社区迭代的 开源软件 (OSS),而非充斥大量本地补丁的闭源构建版本。瑞萨电子依托 VirtIO 虚拟化技术与 Sparrow Hawk 硬件平台践行这一理念:开源不只是降本手段,更是一套开发文化。

随着软件成为决定车辆价值的首要因素, 软件定义汽车 (SDV) 已经从行业热词,转变为可落地的设计理念。 软件定义汽车 的架构并非车辆出厂时就固化定型;相反,在车辆的整个生命周期内,可以持续新增功能、提升性能、推送安全更新。

在这样的设计前提下,传统汽车软件开发模式 —— 软硬件深度绑定的闭源实现、不断堆积局部优化补丁 —— 正快速变得难以为继。软件定义汽车时代,产品竞争力不再取决于能否一次性完成开发并交付,而取决于能否实现长期持续迭代演进。

图 1:从硬件定义系统向软件定义汽车的演进 当代汽车软件的三大技术要求

软件定义汽车时代的车载软件面临三项核心技术需求:第一, 支持长期持续更新 。安全漏洞修复、法规合规更新、功能拓展需求会不断涌现,软件在设计之初就必须预留持续演进的能力。

第二, 全供应链代码可复用 。整车厂(OEM)、一级供应商、半导体厂商、软件供应商参与不同开发阶段,代码库容易碎片化,集成与验证成本会呈指数级增长。

第三, 紧跟技术迭代节奏 。Linux 内核、U‑Boot 通用引导程序、虚拟化技术、实时操作系统(RTOS)的迭代周期都很短;系统一旦绑定特定软件版本,未来就会形成技术债务。

很少有方案能够同时满足上述三点。以 开源软件 (OSS) 为核心的开发模式,是切实可行的解决路径。

图 2:传统分布式 ECU 架构对比软件定义汽车集成架构 仅靠 开源软件 ,不足以实现软件定义汽车

有一种常见误区:认为 “没有开源软件就做不出软件定义汽车”。理论上完全依靠闭源软件也可以搭建整套系统,但真正的矛盾点在于 开发速度与长期维护成本 。

汽车开发过程中反复出现这些痛点:

大量本地补丁堆积,导致代码与上游原始版本严重分叉,难以跟进后续版本升级;

不同厂商之间应用程序接口互不兼容,引发集成、测试工作大量失效;

安全漏洞响应总是滞后;

引入新技术、新工具时,需要大规模返工。

这些问题根源不在于软件是开源还是闭源,而在于软件开发方法论本身存在缺陷。

图 3:下游碎片化开发对比优先上游开发模式 软件定义汽车所需的开源策略:优先上游(Upstream‑First)

适配软件定义汽车的开源利用策略,核心可以概括为 优先上游(Upstream‑First) 。该开发理念是:当需要修改软件时,不要只在本地打补丁,而是协同开源社区,将改动提交合并到上游源代码主干。

优先上游模式的价值:

唯一可信代码源 ,避免多版本分叉;

社区专业人员评审 + 持续集成,带来更高代码质量;

多家企业联合开展验证测试;

更容易迁移至下一个长期支持版(LTS)以及新技术。

对软件定义汽车而言,软件当下可以正常运行远远不够,更要确保五年之后仍可持续更新。提交合并到上游主干的代码,会成为可以跟随社区持续进化的 “种子代码”。

AGL 与 SoDeV:参考实现方案带来的价值

汽车级 Linux(AGL) 是从工程实现层面支撑 SDV 开源应用的代表性项目。AGL 不以制定规范为导向,而是推崇 代码先行 ,基于可运行的实际实现,搭建统一的公共代码底座。

面向软件定义汽车场景,业界推出基于虚拟化的参考实现平台 —— SoDeV(软件定义汽车参考平台) 。在 SoDeV 中,Xen 一类的 Ⅰ 型虚拟机监控程序之上,可以同时运行多个客户操作系统:Linux、汽车版 AGL、安卓车载系统、Zephyr 实时系统等。借助 VirtIO 虚拟输入输出技术,剥离硬件绑定依赖,不再需要各个 SoC 专属设备驱动。

这类参考实现意义重大:整车厂与供应商无需从零起步,可以基于这套所有人都可以参与讨论的公共底座,聚焦自身差异化业务开发。

图 4:基于 Xen 与 VirtIO 的 SoDeV 参考架构 VirtIO 设备虚拟化:软件定义汽车落地的技术基石

想要让 SDV 架构具备实际可扩展能力, 设备虚拟化 是关键技术支柱。要把数十个分布式电子控制单元 ECU 收敛到集中式或域控架构,单颗高性能 SoC 上必须能够同时运行多个操作系统。

系统会多平台并行共存:用于座舱与车载信息娱乐的高功能 Linux 系统;执行执行器控制域的实时操作系统;同时还要满足功能安全要求的软件栈。仅仅完成操作系统虚拟化还远远不够,一大核心难题是如何安全、高效地共享显示器、摄像头、存储、网络等硬件外设。

VirtIO 在此扮演关键角色:它定义一套标准化半虚拟化接口,连接客户操作系统,以及运行在主机 / 特权域的后端驱动。将硬件专属细节封装在统一虚拟接口之后,实现软硬件深度解耦。只要 VirtIO 后端遵循规范,客户操作系统就可以依靠通用 VirtIO 前端驱动,跨不同代次 SoC、跨不同硬件配置完成迁移。

这种解耦带来多重收益:

跨车型世代提升软件复用率;

安全关键域与非安全域清晰隔离;

最大限度缩减硬件相关代码,降低长期维护成本。

VirtIO 不只是虚拟化优化手段,更是从架构层面支撑 SDV 软件持续迭代的核心技术。

图 5:用于评估 SDV 的开源就绪参考平台 瑞萨在开源虚拟化领域的实践

瑞萨积极投身虚拟化生态建设,深度参与汽车开源社区。围绕 AGL、SoDeV 项目,瑞萨同时从 SoC 适配层 与 上游软件层 两方面推进,让虚拟化真正落地于实车。

在 SoC 芯片层面,瑞萨芯片设计充分考量 Xen 这类 Ⅰ 型虚拟机所需的隔离机制、中断管理、性能指标。同时推动开源软件满足 ISO 26262 等功能安全标准。Linux 内核、U‑Boot、Yocto 组件、虚拟化相关组件尽量向上游主干提交维护,减少厂商私有差异。

基于 SoDeV 参考架构,VirtIO 对显示、输入子系统等主要设备做虚拟化,多个客户域通过标准化后端驱动共享物理硬件。这套方案遵循优先上游理念,和全球开源社区共同演进,而不是局限于厂商私有实现。

连接架构理念与现实的参考硬件

基于 VirtIO 的 SDV 架构,能否真正落地,取决于开发环境中能否完成评估与验证。参考硬件是打通 SDV 理论概念和实际工程开发的重要载体。

搭载瑞萨 R‑Car V4H 系统级芯片的 Sparrow Hawk 开发板 ,预集成 Linux、AGL、Xen、Zephyr、VirtIO 整套环境。并且紧密对接上游开发社区,虚拟化、混合操作系统部署、设备资源共享这些实现 SDV 所必需的复杂软件架构,开发者开箱即可使用。

它大幅降低了 SDV 开发入门门槛,同时也加快向开源社区反馈迭代的速度。

开源软件是一种开发文化

总结:在软件定义汽车时代,开源软件已经不只是软件组件,也不单纯用来压缩成本。它代表一套以持续迭代为基础的开发文化,也是企业打破自身边界、协同共建软件的通用沟通语言。

把代码回馈上游、开放参考实现、开放评估验证环境,形成完整正向循环,软件定义汽车才真正成为 可落地实现的工程目标 。

SDV 不仅是架构思路的转变,也对开发理念提出全新技术挑战。整个行业如何用好开源软件,终将决定软件定义汽车事业的成败。

主题:软件|软件定义汽车|开源软件|软件定义汽车时代