在软件定义车辆价值的时代，工程团队面临着摩擦瓶颈。他们花费数小时解决依赖冲突、工具链不匹配和集成失败问题，而不是编写车辆功能。随着车辆实际上变成了数据中心，团队在桌面工作站、云环境和物理目标之间浪费大量时间解决依赖冲突。
本文探讨了如何在桌面、云和嵌入式目标之间建立一致性，以防止硅选项之间的不一致并简化开发人员的工作流程。
目标集成瓶颈
传统汽车工程将每个环境（包括桌面、云和目标电子控制单元 (ECU)）视为独特的宇宙。开发团队在 x86 工作站上编写代码，并在云实例上验证算法。然后，他们在部署到目标 ARM 或 RISC-V 架构时才发现依赖错误。
每一种新的硅芯片都带来定制的工具链、不匹配的库版本和集成延迟。此外，孤立编写的代码需要手动回归测试和自定义移植才能在物理车辆硬件上执行。
这种碎片化模型无法适应现代软件定义车辆 (SDV) 的需求。为了以云速度构建、测试和部署软件，汽车团队必须采用基于环境一致性的现代实践。
理解环境一致性
环境一致性意味着无论在哪里执行，您的软件行为都完全相同。在笔记本电脑上编译的应用程序在云持续集成管道中和车辆 ECU 内部运行时，具有相同的依赖项、库和内核。
实现真正的一致性需要两个不同层次的架构抽象：
- 硬件抽象：软件不应绑定到特定硅芯片供应商的驱动程序。您需要一个中间层来解耦目标应用程序与底层硬件，使您能够在不重写应用程序的情况下更换硅芯片。
- 操作系统抽象：在桌面、云和嵌入式目标上运行相同版本的操作系统内核和开源库，可确保完全满足依赖关系。这种方法解决了“在我的机器上能运行”的问题。
当您实施这些抽象时，整个系统将在云中运行虚拟 ECU (vECU)，其镜像物理道路硬件。
环境一致性始于操作系统
因此，下一个自然的问题是：如何实现硬件和操作系统抽象？在 Canonical，我们应对这一挑战的答案是 Ubuntu.
在硬件层面，Ubuntu 专为在所有主要硅芯片架构上优化运行而设计，原生支持 x86、ARM64 和 RISC-V。我们将特定硅芯片的驱动程序直接构建到内核中，向开发人员隐藏硬件复杂性。
这一基础完全将您的软件与底层芯片解耦。因此，您可以随时更换硬件，而无需重写任何一行代码。
在软件层面，Ubuntu 通过持续集成在不同平台上提供一致的体验。您可以在开发人员工作站上编写一次代码，在云端进行大规模测试，然后直接部署到生产道路车辆，无需针对目标进行重写。
此外，当您将汽车软件栈标准化为 Ubuntu Pro 时，您将解锁关键的商业和运营优势：
- 长期企业安全：Canonical 通过 Ubuntu Pro 提供长达 15 年的长期支持 (LTS)，保护车辆车队在其整个运营生命周期内的安全。
- API 稳定性和回归测试：Canonical 保持严格的 API 稳定性并进行持续回归测试，防止在常规系统更新期间出现破坏性变更。
- 内置汽车合规性：我们将流程与关键的汽车网络安全标准（包括 ISO/SAE 21434）保持一致，简化供应链中的合规性和审计工作。
转型您的汽车软件流水线
汽车工程的未来不在于为车辆网络上的每块芯片管理不同的工具链。而在于建立从桌面到云再到道路的parity。Canonical 提供了可预测、安全维护且开源的基础，以交付下一代移动出行解决方案。
