在汽车软件这行干了快十年，从最早在Tier1做BSW配置，到后来在OEM负责整个软件平台架构，亲眼看着这个行业从“一个ECU跑一个功能”走到今天“一台车跑一个数据计算中心”。

过去二十年，汽车软件产业有一个非常稳定的商业模式，稳定到几乎所有人都觉得它天经地义：

标准组织定义规则 → 软件供应商实现标准 → OEM购买软件 → Tier1集成软件 → ECU最终装车。

AUTOSAR就是这个体系最典型的代表。它不是一套软件，它是一套工业方法论。整个产业链——从OEM到Tier1，从BSW供应商到工具厂商，从芯片厂到代工厂——所有人都在这套共同语言下协作。

但是这两年，我明显感觉到风向变了。

Linux来了、ROS 2来了、COVESA来了、Eclipse SDV来了、SOAFEE来了、S-CORE来了。很多过去只能由供应商打包卖给你的基础软件能力，也开始出现开源实现。甚至AUTOSAR自己，也在2026年8月发布了CAPI 1.0——开始从单纯交付规范，走向交付规范加可执行实现。

于是，一个很有意思的问题摆在了所有汽车软件人面前：

如果汽车底层软件越来越多来自开源，那么AUTOSAR以及传统商业软件供应商的价值，到底还剩多少？

这不是一个技术问题，这是一个产业问题。回答它，需要把过去二十年的逻辑重新捋一遍。

汽车软件正在经历第三次生态迁移

要理解今天发生的事情，得先把汽车软件的演进脉络理清楚。我把它简单划分成三个阶段。

第一阶段：ECU时代。关键词是MCU、ECU、AUTOSAR Classic、BSW、Toolchain。这个阶段的核心竞争力是标准、功能安全、量产经验和工具链。一个典型的车身控制器，跑在几十KB内存的MCU上，AUTOSAR Classic把BSW、RTE、SWC分层得清清楚楚，DaVinci Configurator点几下就能生成代码。这套体系极其成熟，极其稳定，也极其封闭。

第二阶段：软件平台时代。关键词是HPC、Linux、Adaptive AUTOSAR、Middleware、SOA。域控制器出现之后，一颗SoC上要同时跑智驾、座舱、网关，AUTOSAR Classic那套显然不够用了。Adaptive AUTOSAR应运而生，POSIX接口、SOME/IP通信、面向服务架构。但很快大家发现，光有Adaptive还不够，Linux开始进入高算力域，中间件层越来越厚，DevOps成为标配。

第三阶段，也就是我们现在正在进入的：开放软件生态时代。关键词是Open Source、Cloud Native、Containers、AI、Agent。竞争逻辑开始从“谁的软件功能更强”转向“谁能建立更大的开发者和产业生态”。

这三个阶段不是替代关系，是叠加关系。今天一台智能汽车上，可能同时存在Classic AUTOSAR的MCU、Adaptive AUTOSAR的域控、Linux的HPC，以及越来越多的开源中间件。但真正值得警惕的是第三阶段带来的那个判断：

未来汽车软件真正的战争，可能不是AUTOSAR vs Linux，也不是商业软件 vs 开源软件，而是“谁能够成为汽车软件生态的基础设施”。

这句话，我想作为全文的主线。

在批评AUTOSAR之前，得先承认它为什么成功。我见过太多新人一上来就喷AUTOSAR“笨重”“过时”，但说实话，能在汽车行业活二十年还越来越强的东西，没有一个是靠运气。

AUTOSAR解决的从来不是“写代码”

很多人对AUTOSAR有个误解，以为它就是一套软件。不是的。

AUTOSAR是一套汽车软件工业化方法论 + 标准 + 生态体系。

它真正解决的是：软件组件如何标准化、ECU软件架构如何分层、接口如何定义、配置如何管理、ECU间通信如何规范、工具链如何协同、功能安全如何落地、量产工程如何体系化。这些东西，单独拎出来每一个都是大工程。AUTOSAR把它们整合成了一套共同语言。

AUTOSAR真正厉害的地方：建立了“共同语言”

打个比方，AUTOSAR之于汽车软件，有点像英语之于全球软件产业。

不同供应商可以不用同一家公司的软件，但大家按照同一套标准协作。于是形成了这样一条产业链：OEM定义需求 → Tier1负责集成 → AUTOSAR供应商提供BSW → 工具供应商提供配置工具 → 软件团队开发SWC → 最终烧进ECU。

整条链路建立在一个共同语言之上。这个价值，怎么强调都不过分。没有AUTOSAR，中国汽车软件产业不可能在这么短时间内做到今天的规模。

举个具体的例子。一个OEM要换掉某个ECU的BSW供应商，在AUTOSAR体系下，这件事虽然麻烦但可行——因为接口标准是统一的，配置方法是统一的，工具链虽然不同但产出物格式是兼容的。如果没有AUTOSAR，换一家供应商意味着几乎重写整个ECU软件，这种锁定成本会让OEM彻底丧失议价权。

所以AUTOSAR真正的价值，不是它写了多少代码，而是它让整个产业具备了“可替换性”。这个可替换性，是汽车供应链能运转的底层逻辑。

但AUTOSAR体系也有天然边界

优势的另一面就是复杂性。

标准复杂、配置复杂、工具链复杂、学习曲线陡峭、商业工具依赖强、软件成本高、开发流程重。这些在ECU时代还能接受，因为ECU本身就是一个封闭的、功能确定的、生命周期内基本不更新的系统。

但到了中央计算、Linux、云原生、AI时代，问题来了。

汽车软件开始需要吸收IT行业过去二十年积累的大量软件工程能力——容器化、CI/CD、微服务、可观测性、灰度发布、A/B测试。这些东西在互联网行业是基础设施，但在传统AUTOSAR体系里，要么没有，要么很重。

这就给开源留下了空间。

一个巨大的反差

互联网时代，开源软件几乎无处不在，LAMP栈、MEAN栈，哪个不是开源搭起来的。手机时代，Android和Linux成了基础设施。云计算时代，Kubernetes、Docker、Prometheus、LLVM，全是开源。

但汽车产业长期以来，基础软件高度商业化。

为什么？因为汽车行业有三个其他行业没有的特殊约束：安全、可靠性、生命周期。

一辆车卖出去，可能跑十五年。这十五年里，ECU不能崩，功能安全不能破，网络安全漏洞得有人补。这种要求下，车企天然倾向于买商业软件、签长期支持合同、把责任甩给供应商。

所以很长一段时间，汽车行业的开源基本停留在工具链层面，比如编译器、调试器，真正进入量产软件栈的开源代码少之又少。

但汽车正在被“IT化”

这两年情况变了。汽车软件面对的问题越来越像互联网：

软件越来越复杂，一个高阶智驾域控的代码量已经超过一亿行；更新越来越频繁，OTA从一年一次变成一月一次；平台越来越重要，一套软件要适配几十款车型；开发周期越来越短，从三年缩短到一年甚至更短；软件团队越来越大，头部车企的软件团队已经过万人；AI开始进入开发流程，从代码生成到测试自动化；云端协同成为常态，车云一体不再是PPT概念。

于是汽车行业不得不问自己一个问题：

互联网已经验证过的开源生态，汽车为什么不能直接用？

开源真正解决的不是“免费”

很多人谈开源，第一反应就是“免费”。这是最肤浅的理解。

我在OEM做过软件采购，也做过平台架构，可以负责任地说，开源从来不是为了省钱。真正用开源的车企，花在集成、维护、合规上的钱，一点不比买商业软件少。

开源的价值至少有四层：

第一层是成本：减少重复开发，基础能力不用每家车企都自己造一遍。

第二层是复用：让整个行业共同解决基础问题，比如一个DDS实现，一家做不如全行业一起做。

第三层是透明：代码可见、问题可追踪、漏洞可审计。对安全敏感的车企来说，这一点比省钱重要得多。

第四层，也是最重要的，是生态：让不同公司能够共同构建基础设施，而不是每家都守着自己那套封闭系统。

这也是为什么，汽车行业真正值得关注的不是“有没有开源代码”，而是“有没有形成真正的开源生态”。

现在把镜头拉远，看看汽车软件开源到底形成了哪几条清晰的路线。

第一层：OS / 基础设施：Linux

Linux正在成为汽车中央计算的重要基础。核心逻辑很简单：HPC → Linux → Container → Cloud Native。

Linux的优势不是汽车专属的，而是它已经拥有几十年的软件生态。编译器、调试工具、网络栈、容器、CI/CD、安全工具、开发者社区——这些东西汽车厂商不需要重新发明。AGL（Automotive Grade Linux）已经在丰田等车企量产，很多座舱域控底层就是定制Linux。这意味着汽车厂商不用从零造轮子，站在巨人肩膀上就行。

但Linux进汽车也不是没代价。内核实时性、功能安全认证、长期维护，每一个都是硬骨头。

第二层：Middleware / Robotics：ROS 2

这一条我个人觉得最有意思。

汽车和机器人正在越来越接近。尤其是智驾往具身智能演进之后，汽车本质上就是一个带轮子的大机器人。它们共享大量软件基础能力：传感器驱动、中间件、消息传递、服务发现、分布式计算、AI推理框架。

ROS 2已经建立了一套非常成熟的机器人软件生态，DDS作为底层通信，QoS可配置，跨平台支持好。Apollo、Autoware这些自动驾驶开源项目，底层都大量借鉴了ROS的设计思路。

于是可以提出一个大胆的判断：

未来汽车软件和机器人软件会不会逐渐融合？甚至，汽车会不会成为最大的移动机器人平台之一？

这不是天方夜谭。特斯拉的Optimus和FSD共用大量软件栈，小鹏也在做机器人。当汽车和机器人的软件栈开始共享，整个产业格局都会变。

第三层：SOAFEE——汽车开始拥抱云原生

SOAFEE（Scalable Open Architecture For Embedded Edge）的意义不在于某个具体项目，而在于它代表了一个趋势：把云原生技术引入汽车。

传统汽车软件的部署模型是：ECU → Firmware → Flash。刷写一次要拆车、上测试台、走完整流程。新软件架构是：Vehicle → Service → Container → Cloud。服务化、容器化、可编排、可远程部署。

SOAFEE背后是Arm牵头，联合了一堆车企和供应商。它要解决的核心问题是：如何让汽车软件工程逐渐靠近现代软件工程，同时又不破坏功能安全和实时性约束。这件事很难，但方向是对的。

第四层：COVESA——从“代码”走向“标准”

COVESA（Connected Vehicle Systems Alliance）的重要性不在于某个项目，而在于它代表了一种新的组合：开放标准 + 开放社区 + 开源实现。

这实际上与AUTOSAR形成了一个非常有意思的对照：AUTOSAR是标准优先、标准组织主导、商业实现、工具链驱动、企业采购；而COVESA这类开源生态是社区优先、开源社区主导、开源实现、社区驱动、协作贡献。

于是可以问一个问题：未来会不会出现“Open Automotive Stack”？一个像Android之于手机那样的、开放的汽车软件栈？

第五层 ：Automotive Core Stack：S-CORE

S-CORE是Eclipse Foundation下的项目，官方定位是“open-source core stack for Software Defined Vehicles”。它比前面几个都更靠近“vehicle core stack”本身，目标是提供一个面向软件定义汽车的开放核心软件栈。这背后反映的是芯片厂商和软件厂商对“谁是平台主导者”的重新博弈——过去是Tier1定义平台，未来可能是芯片厂通过开放参考设计来定义平台，OEM再在上面做差异化。

重新理解“开放”

讲完这五层，可以发现一个关键问题：整篇文章反复讲开源，但实际上真正想讨论的是“开放软件生态”。这两个概念不是一回事。

Open Source是代码开放。Open Standard是规范开放。Open Governance是治理开放。Open Ecosystem是产业参与开放。这是四个不同层次。

汽车软件真正的开放，不是把代码放到GitHub上，而是把“标准、实现、工具、测试、治理、生态”逐步连接起来。

这个判断比单纯说“汽车开源的下一阶段是Open Engineering”更完整。因为Open Engineering只覆盖了工程体系，而真正的开放需要覆盖从标准到生态的整条链路。

前面讲了五条开源路线，但如果只看到这些，会漏掉2026年最重要的一件事。

2026年8月20日，AUTOSAR正式发布了CAPI 1.0。CAPI全称是Common Adaptive Platform Implementation。这件事的意义，远比外界关注到的要大。

CAPI到底改变了什么

简单说，AUTOSAR开始从交付“规范”，走向交付“规范 + 源码 + 代码生成器 + 可运行demo”。官方用了一个很形象的比喻：从“architectural blueprint”（建筑蓝图）走向“pre-fabricated foundation”（预制地基）。

CAPI 1.0包括15个核心功能集群的实现、源码形式的代码生成器、可运行demo，并且允许AUTOSAR partners参与贡献。这意味着AUTOSAR不再只是一个“定义规则”的组织，它开始亲自下场提供实现。

把过去和现在放在一起对比，变化会非常清晰：

图3  AUTOSAR正在发生什么变化

为什么这件事比“开源挑战AUTOSAR”重要得多

很多人讨论汽车开源，默认的叙事框架是“开源来挑战AUTOSAR”。但CAPI的出现说明，现实比这个框架复杂得多。

真正的变化不是“开源来挑战AUTOSAR”，而是AUTOSAR也开始接受“代码本身就是标准生态的一部分”。

换句话说，AUTOSAR不是被开源逼到墙角，而是在主动进化成一种“标准 + 开放实现”的新生态。标准组织不再只交付规范，开始交付实现；社区不再只是被动实现标准，开始参与标准实现本身。这是一个根本性的模式变化。

这件事的深层含义是：标准定义权和代码实现权，正在AUTOSAR体系内部发生分离。过去这两者是绑定的——AUTOSAR定义标准，商业公司实现标准。现在AUTOSAR自己也开始提供实现，商业公司的角色就必须重新定义。

所以回到文章开头那个问题——“AUTOSAR会不会被开源取代”——这个问题本身就问错了。因为AUTOSAR自己已经在变成开源生态的一部分。真正该问的是：

当AUTOSAR自己开始进入“代码开放、共同实现”的时代之后，汽车软件行业真正的护城河还是什么？

先给答案：不会。但商业软件的价值会发生“上移”。

可以把商业软件的价值拆成四层来看。

第一层：代码

这一层最容易受到开源竞争影响。一个BSW模块、一个中间件组件，开源社区早晚会有对应实现。但“能实现”和“能量产”之间仍然存在巨大的鸿沟。Certification、Qualification、Integration、Safety Case、Security Response、15年Maintenance——这些东西不是有一段开源代码就能解决的。

第二层：产品化

包括集成、配置、工具、调试、测试。这一层商业软件依然有价值，因为开源代码要变成可量产的产品，中间有大量的工程化工作。

第三层：工程能力

包括功能安全、ASPICE、ISO 26262、量产经验、客户支持、长期维护。这一层反而更难被开源替代。因为这些东西不是代码层面的能力，而是组织层面的能力——需要团队、流程、认证体系、历史经验积累。

第四层：生态

未来真正值钱的可能不是代码，而是开发生态。所以商业软件公司的竞争模式可能从“卖代码”变成“卖平台、卖工具、卖验证、卖服务、卖生态”。

更准确地说，商业软件的价值正在发生“上移”：

Value = Code  →  Value = Integration + Certification + Tooling + Support + Ecosystem

用一句话概括：卖代码 → 卖工程 → 卖认证 → 卖信任。

因为汽车软件真正稀缺的不是“有没有一段C++代码”，而是“这套东西你敢不敢放进一辆卖出去跑15年的车里”。这就是商业软件最大的壁垒。

这里可以做一个预判：未来五年，传统BSW供应商会经历一次大洗牌。纯卖代码的会被开源挤压生存空间，但能提供功能安全认证、量产工程支持、长期维护承诺的供应商，反而会因为开源生态的扩张而受益——因为开源代码越多，越需要有人把它工程化、安全化、量产化。这是一个看似矛盾但逻辑自洽的判断。

这一章我想把视角从技术拉到产业。

为什么大众、奔驰、宝马、丰田、比亚迪、特斯拉这些企业，越来越强调软件能力？因为软件正在从“ECU配套”变成“整车核心竞争力”。

OEM真正想控制的是：软件架构、数据、OTA、AI、用户体验、软件生态。

过去是OEM → Tier1 → Supplier的线性供应链。未来可能是OEM → Software Platform → Open Source + Commercial → Developers的网状生态。

汽车产业链的权力结构正在变化。Tier1如果不转型，可能会被挤压成纯代工；OEM如果做不好软件，可能会沦为硬件制造商。这个变化对每一家企业都是生死攸关的。

这里有一个很多人没注意到的细节：OEM自研软件的边界在哪里？我的观察是，OEM会自研应用层和用户体验层，会自研数据平台和AI能力，但底层BSW、中间件、工具链这些重投入长周期的部分，OEM大概率还是会依赖外部供应商和开源社区。完全自研的代价太高，连特斯拉都在用开源代码。所以“掌握软件控制权”不等于“所有代码自己写”，而是“掌握架构定义权和生态主导权”。