汽车软件正在进入一个新的阶段。

随着高性能计算平台逐渐承担越来越多的车辆功能，Linux 凭借成熟的开源生态、丰富的软件工具和广泛的硬件支持，正在成为汽车软件平台的重要选择。

但当 Linux 从信息娱乐等应用进一步走向自动驾驶以及其他具有功能安全要求的场景，一个更关键的问题随之出现：

如何保留 Linux 的开放性和创新速度，同时满足汽车对功能安全、可靠性以及十年以上生命周期的要求？

为什么汽车高性能计算平台需要 Linux？

对于软件开发者而言，Linux 的吸引力非常直接。

成熟的 API、大量可获取的软件和工具、广泛的硬件支持、透明的源代码，以及庞大的开发者生态，都可以帮助汽车软件团队更快地构建和迭代应用。

Linux 还能够减少对单一供应商的依赖，并让开发人员更容易利用已经在其他行业得到广泛应用的软件技术。

对于正在向软件定义汽车演进的主机厂和 Tier 1 而言，这意味着更快的项目启动速度、更高的软件开发效率，以及更大的创新空间。

但汽车需要的不只是“开发得快”。

真正的挑战，是让快速发展的开源生态适应汽车工业截然不同的生命周期。

开源软件的速度，与汽车的生命周期并不天然匹配

典型的开源软件世界强调快速创新和持续演进。

汽车却需要面对完全不同的现实：产品生命周期很长，存储和内存资源受到约束，对成本高度敏感，而且软件出现问题时，工程团队往往希望能够针对具体问题进行修改，而不是为了一个安全漏洞升级大量不相关组件。

这种差异在车辆进入长期维护阶段之后尤其明显。

以 15 年的软件维护周期计算，到第 8 年，可能已经累计出现约 

；到第 15 年，累计安全更新可能达到约 

这带来了一个很现实的工程问题：

车辆需要持续获得安全修复，但是否应该为了每一次修复，都升级整个软件平台？

对于生命周期以十年甚至更长时间计算的汽车而言，答案显然不能只是不断追随社区软件版本。

汽车 Linux 需要一套更加适合汽车产品生命周期的维护方式。

不必为了安全修复，不断升级整个系统

EB corbos Linux 采用了一种更符合汽车产品生命周期的维护思路。

客户可以选择停留在特定 EB corbos Linux 版本，并在产品有效生命周期内持续获得维护更新，包括安全修复。

如果客户不希望升级，系统中的组件不会因为维护而被强制进行版本升级。

例如，EB corbos Linux 1.0、2.0 和 3.0 的维护规划分别延伸至 2034、2036 和 2038 年底。

这种模式试图解决一个长期存在于汽车软件中的矛盾：

既要持续处理安全问题，又要尽可能维持已经验证的软件平台稳定。

这对主机厂和 Tier 1 的意义并不仅仅是延长一个操作系统版本的使用时间，更重要的是减少长期维护过程中不必要的软件变化。

用稳定接口和容器，应对底层 Linux 的持续演进

Linux 内核、硬件和 SoC 都会继续发展。汽车应用软件如何避免被底层平台的每一次变化反复影响，同样是架构设计必须解决的问题。

其架构基于冻结接口和容器，使相同的应用和中间件二进制文件能够继续用于未来版本的 EB corbos Linux；容器中的工具和库则保持向前和向后兼容。

这意味着底层内核和 SoC 支持可以继续演进，而上层应用与中间件不必因此承担同等规模的迁移工作。

容器同时承担软件隔离的作用。

EB containers 可以建立明确的软件组件和资源边界，将用户空间与基础系统隔离，也可以让不同用户空间彼此隔离。

在资源层面，可以对 RAM、CPU、磁盘和网络进行管理；容器支持经过验证的磁盘格式以及独立的持久化加密存储，并能够独立更新和支持 A/B 更新。同时，其 OCI 兼容性也为云端与边缘环境之间的迁移提供基础。

对于下一代汽车软件平台来说，这种架构带来的一个重要价值是：

让应用生命周期与底层操作系统生命周期在一定程度上实现解耦。

长期维护解决的是“能不能长期用”的问题。

当 Linux 进一步进入自动驾驶等安全相关场景时，还需要回答另一个更困难的问题：

功能安全在自动驾驶开发中发挥着至关重要的作用。与此同时，未来的高性能计算平台并不一定只运行一种安全等级的软件。

安全相关应用、不同重要性等级的软件以及普通 QM 软件可能需要在同一个计算平台上运行，既要满足安全要求，又希望能够继续重用既有软件。

 的可扩展 EB corbos 产品系列，覆盖单核、多核产品以及 Linux for Safety Applications 产品组合。

对于汽车 Linux 而言，这意味着讨论的重点已经开始从：

“Linux 能不能进入具有功能安全要求的汽车应用？”

安全与非安全应用，如何在同一平台共存？

要实现这一点，软件隔离成为关键。

EB corbos Linux for Safety Applications 的安全概念涉及多个层次，包括 SoC、Bootloader、EB corbos Hypervisor、Linux Kernel、Linux for Safety Applications Kernel、OS Safety Monitor，以及运行在其上的应用和容器。

在这个架构中，内存以及读、写、执行访问并不是完全开放的。

MMU、Hypervisor、OS Safety Monitor 和不同的 Exception Levels（ELs）

同时，EB corbos Linux for Safety Applications Kernel、安全应用、Hypervisor 与 OS Safety Monitor 之间通过明确的异常处理和执行流机制进行集成。

其背后的核心思路，是建立不同软件组件之间的边界。

对于未来的中央计算和高性能计算架构而言，这一点尤其重要，因为同一颗高性能 SoC 上可能同时运行大量不同类型的应用。

如果能够让安全相关软件与其他软件共享高性能计算资源，同时建立明确的隔离机制，就有机会在集中式计算架构中兼顾计算效率与功能安全要求。

功能安全之外，汽车 Linux 还必须面对网络安全

软件越来越多，开源组件越来越多，车辆生命周期越来越长，汽车 Linux 面临的安全问题也就不可能只局限于功能安全。

汽车软件平台还需要同时考虑网络安全管理、漏洞管理、软件更新以及软件供应链。

Elektrobit 的汽车 Linux 方案将多项网络安全法规与标准纳入考虑范围，包括 

ISO/SAE 21434:2021、UNECE R.155/156、VDA 汽车网络安全管理系统（ACSMS）以及 ISO/IEC 5962:2021 SPDX 格式

这反映出汽车开源软件正在发生的另一个变化：

企业真正需要管理的已经不是某一个 Linux 版本，而是 Linux 在整个汽车生命周期中的安全与合规。

从软件组件进入项目，到量产，再到车辆交付后的多年维护

汽车 Linux 走向功能安全：如何兼顾开源创新与 ASIL B？

操作系统

物联网

Linux凭借成熟生态和硬件支持，正成为汽车高性能计算平台关键选择，但其开放性与汽车功能安全、长生命周期要求存在矛盾。Elektrobit的EBcorbos Linux通过长期维护、稳定接口和容器隔离，实现安全与非安全应用共存，兼顾开发效率与ASIL B安全合规。

高性能计算平台

网络安全

漏洞管理

自动驾驶

软件开发

软件维护

Bootloader

中间件

容器

Linux

2026上云采购 | AI焕新·智启新局

thpc

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

汽车 Linux 走向功能安全：如何兼顾开源创新与 ASIL B？

汽车 Linux 走向功能安全：如何兼顾开源创新与 ASIL B？

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐