OS 之系统：电子电气架构、整车操作系统与 AI 定义汽车

摘要

“整车 OS”已经成为每一家想被称为软件定义汽车的车企都必须拥有的词，但这些叫”OS”的东西根本不是同一种东西。本文先做一次本体清理：座舱 OS 不是整车 OS，域 OS 不是整车 OS，运行时也不是 OS。所有已量产的”整车 OS”——MB.OS、蔚来天枢、理想星环、Pleos Vehicle OS——都是多内核拼合，由一个整车控制面统一治理。我们把这个控制面拆成三个可观察的部件：契约、编排、生命周期，并据此提出六维的整车 OS 能力矩阵（VOCM），与 D2 的 AR 评分对照，给 15 家车企做了初评。

全文的核心是一个因果结构：E/E 架构划定整车 OS 的可能性边界；而功能一旦软件化，因果就会反转——软件工作负载开始设计下一代 E/E（架构—OS 共演化环）。在此之上，本文论证自动驾驶是检验整车 OS 是否名副其实的压力测试，AI 让 OS 的上半截变薄、下半截变厚，行业真正走向标准化的是车辆 API、数据模型与运行时契约，而不是”一个汽车 OS”。结论交付三个判断与一个提醒，并附五条修订触发器。

---

体例声明

本文属 Deep Dive，不属 Working Paper。两者的分界不在长度，而在承诺等级：

• Working Paper（D1–D4，Zenodo DOI）＝锁定的主张。不可静默修订，须扛得住被引用五年。
• Deep Dive（本栏目）＝有纪律的观察。可修订、可推翻，明确标注”这是我们此刻看到的”，不进 DOI 体系。

本文继承 Working Paper 的认知纪律——来源分级、证据可追溯、必须写出反论与失效模式——但不继承其终局性。本文不修订 D1–D4 的任何已发布结论；所引用的 D2 评分以已发布版本为准。证据等级在正文中以〔T1〕〔T2〕〔T3〕〔推断〕标注，含义见附录 A。本文结论自带修订触发器（第十章），任一触发即发布修订版并标注变更。

---

引言：一个被所有人使用、却没有人定义的词

2025 年 6 月，第一台搭载 MB.OS 的 CLA 在德国拉施塔特工厂下线〔T1〕。同一年，蔚来把”天枢”称为整车全域操作系统，理想把”星环 OS”以 Apache 2.0 协议开源，丰田让 Arene 随新款 RAV4 上市，现代汽车把 Pleos 拆成”Vehicle OS”和”Connect”两个品牌。到 2026 年，“整车 OS”已经成为每一家想被称为软件定义汽车的车企都必须拥有的词。

问题在于，这些叫”OS”的东西，根本不是同一种东西。

Android Automotive 是 OS；BMW Operating System X 也叫 OS；NVIDIA DriveOS 叫 OS；AUTOSAR 有时被误叫成 OS；MB.OS、天枢、星环、Pleos Vehicle OS 也都是 OS。如果把它们放进一张表做排名，比较的就是苹果、橙子和果园。

本研究系列此前已经三次触碰这个词，却从未停下来定义它。D1 把 OS 列为七个架构控制点中的 C3，把 RTOS、AUTOSAR、中间件写进 E/E 架构的软件层，并在 §3.4 指出 Hypervisor 是”开放生态”与”硬实时”之间的桥。D2 在梅赛德斯的个案里专门区分 MMA（硬件平台）与 MB.OS（软件操作系统），提醒读者二者不可混为一谈。DD-08《司机退场》则论证：一旦人类驾驶员退出回退链，fail-operational 就从高级配置变成了准入条件。

三篇文章的接口都指向同一个空位：在”电子电气拓扑”与”智能”之间，究竟是哪一层把一堆控制器变成了一台可以编程、可以持续进化、最终可以承载自动驾驶与 AI 的机器？

本文要回答的就是这个问题。主问题只有一个：

一套 E/E 架构在什么条件下，不再只是电子电气拓扑，而真正成为一台”可编程汽车”的平台？

我们的回答可以压缩成四句话，也是全文的骨架：

E/E 是基底，控制面是 OS，AI 是自适应智能，自动驾驶是压力测试。

展开来是六个判断：

• T1｜定义： 整车 OS 不是一个操作系统，而是由一个整车控制面治理的”OS 之系统”。控制面 = 契约 + 编排 + 生命周期。
• T2｜前提： 没有足够解耦的 E/E，就没有整车 OS。软件抽象的天花板由物理架构决定。
• T3｜反转： 功能一旦软件化，因果就会反转——软件工作负载开始设计下一代 E/E。这是本文的核心原创：架构—OS 共演化环。
• T4｜压力测试： 自动驾驶不是整车 OS，而是检验一个”整车 OS”是否名副其实的那项工作负载。
• T5｜治理： AI 不会消灭 OS。它让 OS 的上半截变薄、下半截变厚——概率智能，必须运行在确定性的治理之内。
• T6｜收敛点： 行业真正走向标准化的不是”一个汽车 OS”，而是”车辆 API + 数据模型 + 运行时契约”。内核正在商品化，控制点 C3 正被 C2（芯片）与 C4（中间件）两面夹击。

先从最基础的一件事做起：把这个词清理干净。

---

一、命名问题：叫”OS”的，不一定是 OS

1.1 一次本体清理

“操作系统”在计算机科学里有一个相当清楚的含义：管理硬件资源、为上层程序提供抽象与隔离的那层软件。Linux、QNX、各类 RTOS 都符合这个定义。麻烦在于，汽车行业把同一个词用到了至少四个不同的层级上：

• 内核级 OS：QNX、Linux、Classic AUTOSAR OS、各类 RTOS、微内核。它们管理的是一颗芯片或一个 ECU。
• 运行时与中间件：AUTOSAR Adaptive Platform、SOME/IP、DDS、ROS 2。它们定义通信、服务发现、执行管理，但本身运行在某个内核之上——Adaptive Platform 的目标硬件运行符合 POSIX PSE51 的操作系统，AP 本身构建在这个操作系统之上〔T2〕。
• 域 OS：Android Automotive、BMW OS X、NVIDIA DriveOS、鸿蒙座舱。它们管理一个功能域，比如座舱或者智驾计算单元。
• OEM 所称的”整车 OS”：MB.OS、天枢、星环、Pleos Vehicle OS。它们声称管理的是整台车。

前三层都有清楚的工程边界。第四层没有。它是一个品牌名、一套组织承诺，也是一组跨越多个内核、多个域、多颗芯片的软件——本文的全部工作，就是给第四层一个可检验的定义。

1.2 三条判别规则

在定义之前，先给出三条否定式的判别规则。它们的作用是把不属于”整车 OS”的东西先排除出去。

规则一：座舱 OS ≠ 整车 OS。

BMW Operating System X 基于 AOSP，负责 Panoramic iDrive 的显示、交互和数字体验〔T2〕；Neue Klasse 真正的整车架构，是四台分别负责信息娱乐、自动驾驶、驾驶动力学和基础功能的”superbrain”，加上区域控制器〔T1–T2〕。现代汽车的拆分更彻底：Pleos Connect 是基于 Android Automotive 的信息娱乐系统，计划 2026 年第二季度上市；Pleos Vehicle OS 则是建立在高性能车载计算机与区域控制器之上的车控 OS〔T2–T3〕。一家公司把这两件事分成两个品牌，本身就是最好的证据：座舱上跑得最漂亮的系统，不等于能控制整车的系统。

规则二：域 OS ≠ 整车 OS。

NVIDIA DriveOS 是面向加速计算、传感器集成、智能驾驶和 AI 座舱的操作系统与运行时，DriveOS 6.0 已获 TÜV SÜD 的 ISO 26262 ASIL D 认证〔T2〕。它是这个领域里最强的产品之一。但它管理的是 DRIVE 计算平台这个域，而不是车身、热管理、能量、底盘在内的全车功能。

规则三：运行时 ≠ OS。

AUTOSAR Adaptive 定义的是行为规范：执行管理、通信、存储、安全。它依赖下层的 POSIX 内核，也依赖上层的车企集成。把它称为”OS”，就像把 TCP/IP 称为网络本身。

三条规则的共同含义是：**名字不能作为判据。**叫”OS”的不一定是整车 OS（BMW OS X 就不是）；不叫”OS”的，反而可能是事实上的整车平台（Tesla 从不给它的软件栈起 OS 品牌名，Rivian 同样如此）。丰田的口径漂移更说明问题：2023 年 4 月，丰田官方把 Arene 描述为”comprehensive software platform and vehicle operating system”〔T1〕；到 2025 年随新款 RAV4 量产时，官方与媒体更多称其为”software development platform”〔T2〕。这不是文字游戏。它引出了一个本文第四章还会回到的问题：整车 OS 的控制点，究竟在运行时，还是在软件生命周期？

1.3 中国的分类法：一个有国标背书的答案

在定义这个问题上，中国比任何地区都走得更远，因为它已经写进了国家标准。

2019 年，全国汽车标准化技术委员会发布《车用操作系统标准体系》，把车用操作系统分为两大类：车控操作系统与车载操作系统〔T1〕。车控 OS 再分为安全车控 OS（动力、底盘、车身，实时性与安全性要求最高）和智能驾驶 OS（面向智驾域控制器）；车载 OS 面向中控、仪表与 T-box。

2026 年 3 月 31 日，这套分类升级为两项推荐性国家标准，同年 7 月 1 日实施〔T1〕：

• GB/T 47351-2026：车控操作系统，定义 Ⅰ 型（智能驾驶操作系统）与 Ⅱ 型（安全车控操作系统）。
• GB/T 47341-2026：车载操作系统技术要求及试验方法。据商业译本片段，它把车载 OS 定义为”为智能网联汽车提供除驾驶自动化功能实现以外的服务的软件集合”，并建议支持仪表告警等高实时场景的车载 OS 达到 ASIL B 及以上〔T3：商业译本，非标准原文〕。

据公开报道，起草单位名单本身就是一张产业地图：华为（引望）、地平线、高通、蔚来、比亚迪、理想（车和家）、梅赛德斯-奔驰中国、大众中国等都在其中〔T2〕。

国标的价值在于，它按功能安全属性而不是按品牌来切分 OS。但它也留下了一个空位：标准里有车控 OS、有车载 OS，却没有”整车 OS”。学术与产业界常用的四分法——安全车控 OS、智能驾驶 OS、智能座舱 OS、跨域”中央计算 OS”——第四类在国标里找不到对应。〔推断〕这个空位，正是”整车 OS”营销概念所栖身的位置，也正是本文要用”控制面”去界定的对象。

1.4 那么，整车 OS 到底是不是伪命题？

先把最尖锐的质疑摆上桌：如果去掉品牌层，所谓”整车 OS”只剩下 QNX + Linux + AUTOSAR + Hypervisor + 一堆中间件——这些东西十年前就有了。那”整车 OS”还剩什么？

本文的回答是：**作为品牌，它被夸大了；作为工程实体，它是真的。**剩下的那部分，不是任何一个内核，而是把多个内核、多个域、多颗芯片组织成一台车的那套东西——统一的服务契约、跨关键性等级的编排、贯穿整个车辆生命周期的更新与验证体系。下一章把它拆开来看。

---

二、OS 之系统：拆开一台”整车 OS”

2.1 所有量产的”整车 OS”，都是多内核拼合

拆开任何一台已经量产的”整车 OS”，都看不到一个内核，只看到一个家族。

蔚来 天枢 SkyOS 采用”1+4+N”结构〔T2〕：“1”是 SkyOS-H，一个管理异构计算资源的 Hypervisor；“4”是四个面向不同场景的内核——其中车控内核基于 seL4 形式化验证微内核，座舱内核基于深度定制的 Android；“N”是 N 个自研中间件，负责跨域协同与全生命周期升级。〔T3：关于其余子内核的具体分工，不同来源的描述存在出入，本文不展开〕天枢 2024 年 7 月 27 日全量发布，在 NT3 平台车型上实现全功能〔T2〕。

理想 星环 OS 是三件套：车控 OS、智能驾驶 OS、通信中间件〔T2〕。2025 年 3 月 27 日，理想宣布开源；4 月发布 0.1.0（安全实时 RTOS + 通信总线 Lite），6 月 30 日发布 1.0.0，此后开放虚拟化引擎〔T2〕。理想自称投入 200 余人、超过 10 亿元，2024 年首版量产，芯片适配周期从 3–6 个月缩短到 4 周〔T2，企业宣称〕。

现代 Pleos 把车控 OS 与座舱 OS 分成两个品牌（见 1.2）。国标 GB/T 47351 把车控 OS 本身再分成 Ⅰ 型与 Ⅱ 型。

结论只有一个，也是本文的第一个论点：

T1｜整车 OS 不是一个操作系统，而是由一个整车控制面治理的”OS 之系统”（a system of operating systems）。

2.2 六层栈模型：S0–S5

为了让不同厂商的产品可以放进同一张图里比较，本文提出一个六层栈模型（图 2.1）。

外层还包着一圈不属于车端、却决定车端能力的东西：云、OTA、数据闭环、DevSecOps，以及新出现的模型生命周期。

图 2.1　整车软件控制面：S0–S5 栈与外环。读图要点：整车 OS 不是图中的任何一层，而是 S4 对 S1–S3 的统一治理；S0 决定了 S4 能治理多大的范围；外环决定了 S4 能否在车辆售出之后继续演进。

2.3 控制面的三个部件：契约、编排、生命周期

“控制面”（control plane）这个词借自网络工程：数据面负责转发每一个数据包，控制面决定数据包该怎么走。放到汽车上，数据面就是 S1–S3 里真正在跑的那些进程、任务与信号；控制面是决定谁可以在哪里运行、以什么优先级、通过什么接口、在什么条件下被替换的那一层。

本文把整车控制面拆成三个部件：

1. 契约（Contract）：服务接口、车辆 API、信号与数据语义。它承诺”功能与 ECU 的物理位置解耦”——一个空调控制服务，不必关心自己最终跑在哪颗芯片上。
2. 编排（Orchestration）：混合关键性调度、隔离证明（freedom from interference）、功能迁移、资源仲裁。它决定 ASIL D 的制动功能与 QM 级的音乐播放如何共享同一颗芯片而互不干扰。
3. 生命周期（Lifecycle）：OTA、回滚、诊断、DevSecOps，以及新增的模型生命周期。它决定这辆车出厂之后，还能被改变多少、以多快的速度、在什么样的安全论证之下。

用这三个部件去看 1.2 中的判别规则，问题会清楚很多：座舱 OS 只有座舱域的契约；域 OS 有强编排，但范围限于一个域；运行时有契约规范，但没有对整车的编排与生命周期负责。只有当契约、编排、生命周期三者同时覆盖了全车主要域时，我们才把它称为整车 OS。

这个定义有一个直接的好处：它可以被观察。一家车企声称拥有整车 OS，我们只需要问三个问题——它的车辆 API 覆盖了哪些域？它的混合关键性整合达到了什么认证等级？它的 OTA 能更新到哪一个域？第五章的 VOCM 评分，就是把这三个问题展开成六个维度。

2.4 一个被低估的事实：底层极度集中，上层极度分散

把各家产品投到 S0–S5 上，会出现一个鲜明的图景：

• **在 S1，市场极度集中。**BlackBerry 2026 财年年报披露，QNX 已嵌入超过 2.75 亿辆汽车，同比增加 2000 万辆，与 45 家以上车企合作，覆盖前 10 大 OEM 与前 25 大电动车 OEM 中的 24 家〔T1〕。QNX OS for Safety 与 QNX Hypervisor for Safety 均获 ISO 26262 ASIL D 认证〔T1〕。
• **在 S4，市场极度分散。**十余家车企各自宣称拥有整车 OS，彼此互不兼容。

这正是 D1 两层收敛-分化模型在软件层上的再现：**底层基础设施收敛，上层控制语义分化。**它也预示了第七章要讨论的那场争夺——如果 S1 和 S2 终将商品化，那么价值会落到哪里？

---

三、先有路，再有车：E/E 划定了 OS 的可能性边界

3.1 为什么分布式架构上长不出整车 OS

设想一台有 100 个 ECU 的传统汽车。每个 ECU 都跑着自己的 OSEK 或 Classic AUTOSAR，各自来自不同的一级供应商，各自有自己的软件版本、标定数据和刷写流程。在这样的车上，“整车 OS”在物理上就不可能存在——没有一个地方可以让统一的运行时落脚，也没有一条带宽足够的通道让服务契约跨越 ECU 边界。

这就是本文的第二个论点：

T2｜没有足够解耦的 E/E，就没有整车 OS。软件抽象的天花板，由物理架构决定。

3.2 五个使能物

E/E 架构从分布式走向域控、再走向区域 + 中央计算的过程中，有五样东西让整车控制面在工程上成为可能（与 D1 第二章的 Bosch 六阶段框架对应）：

五个使能物里，前四个决定控制面能不能统一，第五个决定控制面能不能托付。没有前四个，就没有整车 OS；没有第五个，整车 OS 就只能停在 fail-soft 的世界里——这一点第六章会展开。

3.3 代际矩阵：哪一代 E/E 上能长出哪一层

把 S0–S5 与 E/E 代际交叉起来看（图 3.1），可以得到一个简洁的规律：

• 分布式：只有 S1（每个 ECU 自己的 RTOS）。
• 域控：出现 S2 与 S3——座舱 Android、智驾 Linux / QNX、域内 SOA。但每个域各自为政，这一代所谓的”整车 OS”多是营销。
• 跨域融合：出现了部分 S4——两到三个域开始共享契约，舱驾一体开始尝试。
• 区域 + 中央计算：S4 在工程上真正成立。
• 中央计算 + AI 原生：S5 开始出现。

图 3.1　E/E 代际 × 控制面栈层：可行性矩阵。横轴是 E/E 代际（分布式 → 域控 → 跨域融合 → 区域 + 中央 → 中央 + AI 原生），纵轴是 S1–S5。每个格子标注”不可行 / 部分 / 已量产 / 新兴”。读图要点：S4 的”已量产”格子只在区域 + 中央这一列出现；在此之前标为”整车 OS”的产品，多数落在 S3。

这个矩阵给出一个可以证伪的推论：**如果有人在不改变 E/E 代际的前提下，造出了覆盖全车主要域的控制面，T2 就需要修订。**我们把它列为修订触发器之一（第十章）。

---

四、因果反转：当软件开始设计硬件

4.1 从”E/E 支撑 OS”到”OS 设计 E/E”

第三章讲的是一个方向：E/E 先行，OS 随后。这是行业里被讲得最多的故事，也是最不完整的那一半。

另一半是：一旦一家车企真正建立起整车控制面，它就会开始反过来决定下一代 E/E 架构。

GM 给出了一个罕见的、由车企自己公开的例子。其 2028 年中央计算平台宣称：OTA 能力提升 10 倍，带宽提升 1000 倍，AI 算力提升 35 倍〔T1，企业宣称〕。这三个数字没有一个是从”更好的硬件”出发定义的，它们全部是从软件要做什么倒推出来的硬件规格。

2026 年 9 月的零跑技术日，给出了第二个、也更细的例子。零跑把自己的电子电气架构演进讲成一条清晰的代际线：

• LEAP 3.0：2023 年发布”四叶草”中央集成式架构。
• LEAP 4.0：在 D 平台上用单芯片实现舱驾一体〔T3〕。
• LEAP 5.0：即将到来的”四叶草 5.0”，有三处变化〔T2–T3〕：
  • 控制：中央集成控制。
  • 供电：全车 48V，整车线束缩短到 500 米以内，线束重量最多减少 50%，官方称线束热损耗降至原来的 1/16。
  • 网络：全车以太网采用非对称带宽方案，下行 10G、上行 100M。
• 量产时间：首批车型 2027 年投产〔T2〕。

最后一项值得停下来看。对称带宽是”通用网络”的思路；非对称带宽则意味着，网络是按照数据实际怎么流动来设计的——哪个方向要承载大流量，哪个方向只需传送控制与状态。〔推断〕这是一个由软件与数据流定义的网络拓扑：先知道控制面要怎样搬运数据，再决定线怎么铺。48V 与线束长度的变化也是同一逻辑——中央集成控制让配电与布线可以按”一个大脑 + 若干区域”重新组织，而不是按”一个功能一个盒子”去铺。

这就是本文的核心论点：

T3｜功能一旦软件化，因果就会反转：软件工作负载开始设计下一代 E/E 架构。

两个方向合起来，就是一个闭环（图 4.1）：

E/E 架构 → 整车控制面 → 工作负载 / 数据 / AI → 下一代 E/E 架构

我们称之为架构—OS 共演化环（Architecture–OS Co-Evolution Loop）。

图 4.1　架构—OS 共演化环。读图要点：环的上半圈（E/E → OS）是”可能性边界”，由第三章的五个使能物构成；下半圈（OS → E/E）是”反向设计”，由上表的六类需求构成。一家车企是否进入了软件定义阶段，判据不是它有没有 OS 品牌，而是下半圈是否开始转动。

需要说明的是，这个环不是又一个成熟度阶梯。本系列已经有 AR0–AR5（被设计系统的能力门槛）和 AI²-ML（工具链的成熟度）。共演化环描述的是一种因果结构，而不是一个等级。

4.2 哑化光谱：一场关于信任的分歧

共演化环的下半圈最直观的体现，是区域控制器的”哑化”程度——也就是关键控制逻辑留在区域、还是集中到中央。

**一端是 GM。**它的区域”聚合器”明确”不执行控制逻辑”，所有智能——传感融合、控制仲裁、机器学习推理——都放在中央计算单元〔T1〕。这是彻底的哑化路线。

**另一端是 BMW。**Neue Klasse 把驾驶动力学单独放在一台名为”Heart of Joy”的高性能计算单元里，它比传统 ECU 快 10 倍〔T2〕；信息娱乐、自动驾驶、基础功能各有一台 superbrain。这是”关键控制不进中央”的路线。

再往外，是仍然把控制逻辑分布在大量 ECU 上的传统架构。

图 4.2　哑化光谱。从左到右：分布式 ECU → BMW 式”关键控制独立计算” → GM 式”聚合器只转发、全部智能进中央”。读图要点：横轴不是”先进程度”，而是”把 ASIL D 执行链托付给中央控制面的信任程度”。

〔推断〕两条路线的分歧，表面上是硬件拓扑之争，本质上是一个关于信任的问题：**中央控制面的确定性，是否已经足以被托付 ASIL D 的执行链？**GM 的回答是”是”，BMW 的回答是”还不完全”。这个问题没有标准答案，但它清楚地说明了因果的方向——是对 OS 能力的判断，在决定 E/E 的拓扑。

4.3 一个可观测的代理指标：OTA 粒度

控制面的覆盖度很难从外部直接观察——车企不会公开它们的车辆 API 清单。但有一个东西是可以观察的：OTA 能更新到哪一个域。

丰田新款 RAV4 是一个干净的例子：搭载 Arene 后，座舱与 ADAS 可以 OTA 升级，车身与动力学暂时不可以〔T2〕。〔推断〕这说明 Arene 的契约尚未覆盖车控域。反过来，一家车企如果能通过 OTA 更新制动或动力系统的标定，说明它的控制面已经把安全关键执行链纳入了生命周期管理。

因此本文把 OTA 粒度作为”控制面契约覆盖度”的外部代理指标，并在第五章的 V5 维度中使用它。它不完美——能 OTA 不等于架构优雅——但它是少数可以从公开信息中被验证的指标之一。

4.4 康威定律的另一张脸：E/E 与 OS 由同一个组织交付

D3 讨论过 Tesla 把 FSD 团队与 Optimus 团队合并，用组织结构反过来塑造技术架构。在 E/E 与 OS 的关系上，有一个更新、也更直接的公开证据。

Rivian 在 2026 年代理声明中，把它与大众集团成立的合资公司 RV Tech 定义为”electrical architecture technology company with a focus on software, electronic control units and related network architecture”〔T1〕。也就是说，E/E 拓扑、ECU 和软件，在这家公司里是同一个交付物。

Rivian 2025 财年的数据显示了这个交付物的经济分量：软件与服务毛利从 2024 年的 700 万美元增至 5.76 亿美元，主要来自与合资公司相关的”vehicle electrical architecture and software development services”〔T1〕。

〔推断〕这组数字的意义不在于金额，而在于定价单位：**“E/E + OS”已经可以作为一个整体被定价、被交易。**当一个架构可以被单独出售时，它就不再只是一辆车的附属物，而是一种资产。共演化环在这里有了资产负债表上的对应物。

大众集团在这件事上走得更远：它同时运营两套由不同组织交付的 E/E 架构——西半球的 RV Tech，中国的 CEA。5.5 节会回到这一点。

4.5 前代兼容：共演化环的代价，也是契约的试金石

共演化环有一个容易被忽略的副作用：**下一代 E/E 被软件需求重新设计的同时，上一代车辆仍然在路上。**它们能不能继续收到新的软件？这引出一个比”能不能 OTA”更严格的问题：

整车 OS 能否做到前代兼容——让上一代甚至上两代硬件的车辆，继续通过 OTA 获得新一代软件能力？

本文的回答是：**能否前代兼容，是判断软硬解耦是否真实的最严格的外部标准；但评判时要看”契约是否稳定”，而不是”功能是否对等”。**理由有四。

**第一，它是软硬解耦唯一能被外部检验的形式。**每家车企都会说自己”软硬解耦”。但如果新软件只能跑在新硬件上，所谓解耦其实只是”每一代重新集成一次”。只有当新一代软件能通过同一套契约部署到旧硬件上时，解耦才得到了证明。

**第二，存量车队是软件经济的分母。**软件订阅、功能付费、数据闭环，规模都取决于能接收更新的车辆数量。每次换代都切断旧车，软件收入的分母就会周期性归零。

**第三，法规已经把兼容性写进了更新流程。**UN R156 第 7.1.1 条要求车企的软件更新管理体系具备一系列流程，包括：识别更新的目标车辆（7.1.1.6）、在发布前确认更新与目标车辆配置的兼容性（7.1.1.7）、识别被更新系统与其他系统的相互依赖（7.1.1.5），以及维护更新前后的软件版本标识 RXSWIN（7.1.1.3）〔T1〕。前代兼容不只是用户体验问题，它是软件更新管理体系里必须回答的一项。

第四，它暴露了共演化环的张力。如果下一代 E/E 必须为老车保留同一套契约，契约就会锁定 E/E 的演进路径——这正是控制面价值与代价同时出现的地方。不保留契约，就是放弃存量车队；保留契约，就要在新架构里背上旧接口。

但前代兼容不可能是”功能对等”。算力、传感器配置、冗余设计，都是物理事实，OTA 改变不了。D3 已讨论过 Tesla HW3 与新版本 FSD 之间的代际断层：在硬件代际跨度过大时，即使是最激进的软件定义者，也无法让旧硬件运行全部新能力。

所以更合理的评判方式，是借用智能手机行业的思路——能力分级下的契约稳定：

零跑技术日给出了一个第 3 级的公开样本：其 LWM 世界模型辅助驾驶宣称代码量减少 90%，可部署在 200、640、1280 TOPS 三个算力档上，并承诺所有激光雷达版车型免费升级、终身免费使用，媒体报道涉及约 35 万辆存量车〔T3，企业宣称〕。〔推断〕“同一模型、多档算力”本身就是为前代兼容而做的设计——它把能力差异从”有或没有”变成了”多或少”。

本文因此把前代兼容并入 VOCM 的 V2（软硬解耦）评分细则（附录 B）：只有当软件能力被证明可以跨硬件代际下放时，V2 才能拿到 4 分以上。它没有被单列为第七个维度，是因为它本质上是软硬解耦的一个检验方式，而不是一项独立能力。

4.6 小结：判断一家车企有没有整车 OS，看下半圈

本章的结论可以作为一个实用的判别方法：

不要问一家车企”有没有整车 OS”，要问它的下半圈有没有开始转动——它的下一代 E/E 规格，是不是由现在这一代软件的需求定义出来的？

如果是，它已经进入了软件定义汽车。如果不是，无论 OS 品牌叫什么，它仍然处在”硬件定义、软件填充”的阶段。

还有第二个问题：**上一代车，是否仍然在同一套契约里？**下半圈转得越快，这个问题就越尖锐。

---

五、牌桌 2026：谁在做，做到了哪一步

5.1 不问”成不成熟”，问”哪一层成熟”

“整车 OS 成熟了吗？“这个问题没有答案，因为不同层的成熟度相差了一个时代。

总体判断：

**2026 年是整车 OS 从”架构抱负”进入”早期量产现实”的一年。**它不再是幻灯片，但也远未形成 Android / iOS 那样稳定的产业范式。

按量产程度，可以把主要选手分成四档。注意这只是描述性的分层，不是新的成熟度阶梯：

• M1 规模化基础设施（亿级 / 百万级装车）：QNX、Classic AUTOSAR、鸿蒙座舱、Android Automotive。
• M2 车企全域控制面已量产：MB.OS（CLA）、天枢（NT3 平台）、星环、BMW Neue Klasse、Tesla。
• M3 首发或部分域量产：丰田 Arene（RAV4，车身与动力学暂不可 OTA）〔T2〕；现代 Pleos Connect（2026 年第二季度首发，仅信息娱乐域）〔T2–T3〕；Rivian 第二代平台。
• M4 路线图或重组中：GM 中央计算平台（2028，首搭 Cadillac Escalade IQ）〔T1〕；Stellantis STLA Brain（原计划 2024 年底整合，现随 STLA One 平台于 2027 年首次集成）〔T1–T2〕；大众集团 × Rivian 的 RV Tech 架构（2026 年第一季度完成冬季测试，2027 年随 ID.EVERY1 首发）〔T1〕；现代 Pleos Vehicle OS 与中央区域架构（2030 年目标）〔T3〕。

大众集团的中国架构 CEA 则已越过这一档：2025 年底在安徽投产，2026 年 1 月随 ID. UNYX 07 上市，官方称支持整车 OTA〔T1〕，属于 M3。

一个反复出现的模式值得记下：**M4 里的车企，几乎都比自己最初宣布的时间表晚了。**大众集团的软件子公司 CARIAD 是最受关注的例子：原定由它交付的统一软件平台几经推迟，2025 年起公司经历大规模重组与裁员〔T3〕，西半球的下一代架构转由 RV Tech 交付。〔推断〕延期的原因很少是内核或芯片，更多是组织——把几十个职能孤岛改造成一个平台组织，比写一个 Hypervisor 难得多。第九章回到这一点。

5.2 按角色而不是按品牌：九类玩家

整车 OS 的牌桌上，坐着角色完全不同的玩家。按品牌排名会把它们混在一起；按架构角色分类，才能看清谁在和谁竞争。

5.3 VOCM：用六个维度给整车控制面打分

为了让第 ① 到第 ④ 类玩家可以被放在同一把尺子上衡量，本文提出整车 OS 能力矩阵（Vehicle OS Capability Matrix，VOCM）。它是对第 2.3 节”契约 + 编排 + 生命周期”的展开，共六个维度，每个维度 0–5 分，满分 30 分。评分细则见附录 B。

VOCM 与本系列现有框架的关系——这一点必须说清楚，以免重复计分：

• AR0–AR5 衡量的是被设计系统（整车）的架构能力门槛，主要看硬件拓扑与系统集成；VOCM 只衡量软件控制面。二者正交：一家车企完全可能 AR 高而 VOCM 低，反之亦然——而这种错位，恰恰是分析价值所在。
• AI²-ML 衡量的是架构工具链的成熟度，评估对象根本不同。VOCM 的 V2、V5 与 AI²-ML 的 D2（软硬解耦）、D3（OTA）在名称上相近，但前者看车上的软件，后者看设计车的工具。
• VOCM 不是成熟度阶梯，不定义”VOCM 等级”。它是一个六维的能力剖面。

5.4 初评结果

下表是 VOCM 的初评结果，横向对照 D2 的 AR 快照评分（Snapshot 2026.1.31，五维总分 /25，本文引用而不重评）。

评分只依据公开资料。置信度 H / M / L 反映证据强度：H = 多数维度有 Tier 1–2 证据直接支撑；M = 部分维度依赖企业宣称；L = 多数维度依赖二手资料或推断。与 D2 一样，对旗舰架构已量产、但集团多数车型尚未切换的车企，本表评的是其最新量产架构，并在备注中注明。

未评分（本轮证据不足）：福特、Lucid、吉利、长城、上汽、Stellantis、雷诺、起亚。

零跑不在 D2 的 22 家样本中，因此只有 VOCM 分、没有 AR 分，不进入图 5.1 的散点。评分依据：

• V1、V3：LEAP 3.0 起的中央集成式架构，LEAP 4.0 单芯片舱驾一体〔T3〕。
• V2：世界模型可在三个算力档部署，并承诺向存量激光雷达版车型免费下放〔T3，企业宣称〕。
• V6：车云 AgentOS〔T3〕。
• 其余维度依据二手报道，置信度为低。

LEAP 5.0 于 2027 年量产后再更新。

备注：

• 梅赛德斯评的是 MB.OS 在 CLA 上的首发形态。
• 大众集团评的是中国 CEA 架构（ID. UNYX 07）。公开依据：区域控制加准中央计算，控制器数量减少约 30%，支持整车 OTA，覆盖纯电、混动与燃油全部动力形式〔T1〕；CEA 每两年迭代一代（2.0 于 2027 年覆盖 A 到 D 级车型），智驾计算同时规划了小鹏图灵芯片与酷睿程（大众与地平线的合资公司）方案〔T3〕。CEA 由小鹏共同开发、沿用其架构体系，因此 V1、V3、V4、V5 中公开信息不足的部分参照小鹏评分〔推断〕——这是附录 B「证据不足不高于 2 分」的同源例外。V6 比小鹏低 1 分：智驾计算由两家供应商提供，公开资料未显示小鹏的端到端 / VLA 与 OS 联合调度已在 CEA 上落地。
• RV Tech 架构尚未量产（2027 年），本轮不评，留待首发后更新。官方称其由”modular central computers control all vehicle functions”〔T1〕。如果这一表述在量产时兑现，它的 V1 将直接达到 4–5 分。

图 5.1　E/E × 整车 OS 能力图。横轴：D2 的 AR 快照总分（/25）；纵轴：VOCM 总分（/30）。每家车企一个点，空心点表示低置信度。虚线是等比例对角线（两把量表按满分折算持平）；浅色带是样本趋势线 ±2.5 分（拟合不含大众 CEA）。读图要点：趋势带内的车企，其控制面与 E/E 同步演进；明显偏离趋势带的点，才是值得追问的对象。

5.5 读图：四个发现

**发现一：AR 与 VOCM 高度同步，但控制面整体落后半步。**除大众 CEA 外，图 5.1 中的 13 个点几乎排成一条直线：拟合斜率约 1.2，恰好等于两把量表的满分之比（30/25），每个点与趋势线的偏差都在 3 分以内。这本身就是 T2 的证据——E/E 走到哪里，控制面就大致走到哪里。但这条趋势线整体落在等比例对角线下方约 3 分：按满分折算，行业的控制面普遍比 E/E 落后约十分之一。〔推断〕这与共演化环的判断一致：上半圈（E/E 设定可能性边界）已经转了多年，下半圈（软件反向设计 E/E）才刚开始转动。在 AR 低于 15 分的车企中，只有大众 CEA 的 VOCM 超过 15 分，原因见发现四。

**落在趋势带下方的，是”E/E 领先控制面”的车企：**丰田最明显，Rivian 位于带内下沿。〔推断〕对丰田而言，这说明硬件架构已经先行一步，而 Arene 的契约还没有跟上——与 4.3 节 OTA 粒度的观察一致。Rivian 的情况不同：它的 E/E 是样本中最激进的之一，但公开资料对其软件栈的披露最少，偏低的分数更多反映的是证据不足（置信度为低），而不是能力不足。

**发现二：中国新势力的 V4 和 V2 普遍偏高。**理想开源星环、华为的跨品牌生态、小米的人车家生态，都把”开放”作为策略。〔推断〕这与中国国标先行、产业链共建的环境有关——当接口被标准化时，开放接口的成本下降，收益上升。

**发现三：同一 AR 档内，梅赛德斯的控制面得分最高。**梅赛德斯与比亚迪在 D2 中同为 AR2.5（17 分），但 MB.OS 的 VOCM 初评（20）比比亚迪（17）高出 3 分，在图中落在趋势带的上沿。这需要谨慎解读：D2 的 AR 快照评的是集团整体，而 MB.OS 首先落在 CLA 一款车上。〔推断〕更可能的解释是，梅赛德斯在用一个旗舰车型先把控制面做出来，再让 E/E 在后续车型上追上来——这正好是共演化环下半圈开始转动的样子。如果这个判断成立，它的下一代车型的 AR 会显著上升；如果不成立，就说明 MB.OS 的契约覆盖度被高估了（MB.OS 中安全关键执行器的实际归属，公开资料尚未披露）。

**发现四：大众集团用”一家车企、两套架构、两个外部伙伴”回答了整车 OS 问题。**这是样本中最特殊的一个点，值得单独讨论。

• 中国 CEA：由大众中国科技公司、CARIAD 中国与小鹏汽车共同开发，从概念到投产只用了 18 个月——官方称这是集团历史上最快的全新电子架构；新车型开发成本在部分关键项目中最多降低 50%〔T1，企业宣称〕。
• 西半球 RV Tech：与 Rivian 成立合资公司，员工超过 1,500 人，分布在美国、加拿大、瑞典、塞尔维亚与柏林〔T1〕。

两条路线有一个共同点：大众集团的新一代整车控制面，都不是由集团内部的软件子公司独立交付的，而是与一家在控制面上已经走在前面的新势力共建。

〔推断〕这件事的意义超出了大众本身。它说明整车控制面已经可以跨企业”引进”——不是买一个内核或一套中间件，而是引进一整套 E/E 拓扑、软件栈与开发方法。CEA 的 18 个月，是把共演化环的下半圈”借来”转动的速度。代价同样清楚：一家集团需要同时维护两套架构、两个合作方，以及两套面向不同接口规范（中国国标与西方标准体系）的软件。按两套量表各自的满分折算，CEA 的 VOCM 初评（20/30）明显高于集团整体的 AR 快照（13/25），是图 5.1 中唯一远离趋势带上方的点。这有一部分是口径造成的——与梅赛德斯同理，AR 评的是集团整体，VOCM 评的是最新架构；〔推断〕但更主要的原因是，控制面随同源架构被整套引进，先于集团整体的 E/E 到位。CEA 只是中国区的一套新架构，它与集团在欧洲的存量平台之间的落差，才是更值得追踪的地方。RV Tech 量产之后，大众集团将成为样本中唯一一家在两个市场各有一套区域 + 中央计算控制面的传统车企。这究竟是过渡形态，还是会成为跨国车企的常态，是 7.6 节要讨论的问题。

---

六、压力测试：座舱检验 OS 能不能跑应用，自动驾驶检验它能不能跑整车

6.1 自动驾驶不是 OS

这个说法听起来多余，但行业里经常把它们混为一谈——把一家公司的智驾软件栈直接称为它的”OS”。

T4｜自动驾驶不是整车 OS。它是运行在控制面上最严苛的工作负载——也是检验一个”整车 OS”是否名副其实的最好的压力测试。

用一句话说：

座舱检验的是 OS 能不能跑应用；自动驾驶检验的是整车 OS 能不能跑整车。

6.2 失效后果的阶梯

为什么自动驾驶是压力测试？因为它让失效的代价逐级上升，直到没有任何人类可以兜底。

图 6.1　失效后果的阶梯。读图要点：从左到右，失效的代价从”不便”上升到”整车级回退”；对控制面的要求从”能重启”上升到”能证明自己在部分失效时仍然安全运行”。L3 与 L4 之间的台阶最高——那是人类离开回退链的位置。

这正是 DD-08《司机退场》讨论过的分水岭：驾驶员退出之后，冗余硬件、安全论证、运行时监控与 OTA 验证不再是附加项，而成了系统能力本身。本文在 DD-08 的基础上补上一个视角——这些要求最终都落在控制面上。冗余的计算单元需要一个能在它们之间切换的编排层；OTA 需要一个能证明”这次更新不会破坏安全论证”的生命周期体系；运行时监控需要一个能隔离、观察并在必要时接管 AI 负载的确定性底座。

〔推断〕所以，**一个从未承载过 L3 及以上责任的”整车 OS”，它的整车性还没有经过检验。**它可能在座舱、车身、能量上表现出色，但只有当安全关键的执行链被纳入同一个控制面、并接受 fail-operational 的考验时，“整车”二字才算名副其实。

6.3 OS 的新职责：从”管理资源”到”证明隔离”

传统操作系统的核心职责是管理资源：分配 CPU、内存、I/O。在混合关键性的汽车计算平台上，这个职责发生了质变——OS 必须证明不同关键性等级的负载互不干扰。

这在 2026 年已经是量产现实：

• Qualcomm 称 Snapdragon Ride Flex 为”业界首个商用的混合关键性平台”，可在单颗 SoC 上同时运行 QM、ASIL B 和 ASIL D 负载，已在 8 个全球项目中量产〔T2，企业宣称〕。
• NVIDIA Halos OS 用 Hypervisor 把安全关键功能与 AI 负载隔离，并提供经安全认证的 CUDA 与 TensorRT〔T2〕。

工程上，“证明隔离”意味着 Hypervisor 的空间分区、时间分区、内存带宽分区，以及对这些分区的形式化或认证级论证。蔚来把 seL4 形式化验证微内核用于车控内核〔T3〕，就是把”证明”推到了数学层面的一次尝试。

6.4 端到端模型对 OS 提出的新要求

端到端驾驶模型与 VLA（视觉-语言-动作）模型的普及，给控制面带来了三类新压力：

1. 内存带宽争用：大模型推理会大量占用 DDR 带宽，可能挤压同一芯片上的实时任务。
2. 时延抖动：GPU 推理时间的不确定性，与控制回路的确定性要求天然冲突。
3. 加速器抢占：当智驾模型与座舱大模型共享加速器时，谁有优先权？

NVIDIA 的 Halos SDK 明确把”deterministic scheduling, zero-copy inter-process communication”作为卖点〔T2〕，说明这些问题已经从研究议题变成了产品需求。

6.5 舱驾一体：隔离从可选项变成前提

当座舱与智驾被放进同一颗芯片或同一个中央计算单元时，它们就进入了同一个硬件故障域。在分布式架构里，座舱崩溃不会影响刹车，因为它们在物理上是分开的；在舱驾一体的架构里，这种”天然隔离”消失了，必须由控制面在软件层重新建立起来。

〔推断〕**舱驾一体把隔离从一项”可选的优化”变成了”安全的前提”。**这也是为什么混合关键性整合（V3）在 VOCM 中被单列为一个维度。

6.6 Robotaxi：双通道结构

在 L4 无人驾驶车队中，〔推断：Waymo、百度 Apollo、小马智行、文远知行等对软件栈实现的公开披露有限〕一种常见的结构是”AI 主栈 + 独立的安全监控与冗余计算”——主栈负责驾驶，另一条通道持续监督主栈的行为，并在异常时把车辆带入最小风险状态。这种双通道结构，正是 fail-operational 契约在软件层的体现，也是控制面的编排职责最极端的形态。

---

七、水平平台来敲门：Google、芯片厂与接口之争

7.1 一个新的战场

智能手机时代，苹果和 Google 吃掉了操作系统，手机厂商退守硬件与品牌。汽车行业过去十年的共识是：车企绝不会让这一幕在车上重演。

2026 年，这个共识第一次受到实质性挑战。

T6｜行业真正走向标准化的不是”一个汽车 OS”，而是车辆 API、数据模型与运行时契约。内核正在商品化，控制点 C3（OS）正被 C2（芯片）与 C4（中间件）两面夹击。

7.2 Google：Android 走出座舱

2026 年 3 月 24 日，Google 在 Android Developers Blog 上发布了 Android Automotive OS 的 SDV 扩展（AAOS SDV），标题直白：Beyond Infotainment〔T2〕。核实后的事实如下：

• 形态：一个”轻量、快速启动的无界面 Android 基础（SDV Core，类似 Microdroid）“，作为虚拟机运行在支持 VirtIO 的 Hypervisor 之上；服务接口用 Google 定义的 VSIDL 加 protobuf 描述，通过 SOME/IP、VirtIO socket、以太网等与外部 ECU 互联；座舱侧有一个 SDV Gateway〔T1：source.android.com，文档最后更新 2026-09-24，适用于 Android 17 及以上〕。
• 覆盖域：官方列出”Core Compute, Body Controls, and Cluster domains”，功能示例包括座椅执行器、仪表、空调、灯光、摄像头、后视镜、遥测〔T2〕。官方材料没有提到底盘或 ADAS。
• 安全边界：文档与博客没有任何 ASIL 声明。安全相关的内容只有 Display Safety（车速、警示灯等仪表显示），外加一套安全设计工具链和一个参考 Safety Monitor〔T1–T2〕。
• 采用方：Qualcomm 在 CES 2026 宣布在 Snapdragon Digital Chassis 上提供预集成的 AAOS SDV 栈；首个量产项目是雷诺的一款轻型商用车，计划 2026 年底量产〔T2〕。官方称 AAOS SDV 将于 2026 年内进入 AOSP。

〔推断〕这组事实画出了一条清晰的边界线：**水平平台已经越过了座舱，进入车身舒适域与仪表域；但它还停在 QM 到低 ASIL 的范围内，尚未触及底盘、制动、转向与智驾这些安全关键执行链。**这条线会不会继续往下移，是未来五年最值得追踪的产业信号之一（第十章修订触发器 4）。

7.3 芯片厂：C2 吸收 C3

如果说 Google 是从上往下压，芯片厂则是从下往上包。

• NVIDIA：DriveOS（ASIL D 认证）+ Halos OS（Hypervisor 隔离 AI 负载与安全功能）+ Halos SDK（确定性调度、零拷贝 IPC）〔T2〕。GM 2028 年的中央计算平台基于 NVIDIA Thor〔T1〕。
• Qualcomm：Ride Flex 混合关键性平台 + 预集成 AAOS SDV 栈〔T2〕。

〔推断〕芯片厂提供的已经不是芯片，而是”芯片 + Hypervisor + 安全认证的运行时 + 部分中间件”的整套交付。对一家车企而言，选择一颗芯片，越来越意味着同时选择了 S1 和 S2，甚至部分 S3。这就是 D1 七个控制点中，C2（SoC）正在吸收 C3（OS）。

7.4 中间件与”Vehicle OS 供应商”：C4 的扩张

另一股力量来自中间件和第三方 Vehicle OS 供应商。

• Applied Intuition 向车企提供 Vehicle OS。2026 年 5 月，Stellantis 宣布扩大与其在 STLA Brain 上的合作〔T1〕；该公司自称全球前 20 大车企中有 18 家使用其方案〔T2，企业宣称〕。
• Eclipse S-CORE：2025 年 6 月，11 家企业签署 VDA 的开源 SDV 合作备忘录（BMW、Continental、ETAS、HELLA、梅赛德斯-奔驰、Qorix、博世、法雷奥、Vector、保时捷、ZF）〔T1〕；据 VDA 2026 年 1 月 7 日新闻稿，签署方扩展到 32 家〔T1–T2〕。S-CORE 0.5 于 2025 年 11 月发布，参考平台首先在 QNX 与 Qualcomm 硬件上演示〔T2〕。

〔推断〕当一家欧洲车企选择用开源的 S-CORE 做 S2、用 QNX 做 S1、用芯片厂的 Hypervisor 做隔离、再采购一个第三方 Vehicle OS 做部分 S4 时，它自己真正掌握的还剩什么？答案是：车辆语义、安全责任，以及集成—验证—数据闭环的能力。

7.5 争夺的是接口，不是内核

把上面三股力量放在一起看，会发现一个被低估的事实：各方真正在争夺、也真正在走向标准化的，是接口层。

〔推断〕这些努力合起来指向一个结论：**正在走向标准化的，不是”一个汽车 OS”，而是”车辆 API + 数据模型 + 运行时契约”。**这正好对应 2.3 节控制面三部件中的第一个——契约。

这给出了一个关于价值分布的推论：

契约层正在收敛；编排层和生命周期层，才是车企差异化的剩余空间。

7.6 水平平台 vs 车企控制面：终局是什么

那么，行业会收敛到一个水平的整车 OS，还是车企会保住整车控制面？

〔推断〕本文的判断是：**不是二选一。**底层基础设施（S1、S2、契约层的标准）会持续收敛；车辆语义、安全责任归属与品牌差异（编排、生命周期、数据闭环）会持续分化。这正是 D1 两层收敛-分化模型在软件层的第二次再现。

有四类车企会走出四种不同的终局形态：

1. 垂直整合者（Tesla、华为、蔚来）：同时掌握 C2、C3、C4，控制面完全自有。它们是 T6 最强的反例——对它们来说，OS 不是正在被商品化的东西，而是护城河的一部分。

2. 联邦式控制面：按区域甚至按合作伙伴建立多套控制面，共享品牌、供应链与部分底层，但不追求全球一套软件栈。大众集团是目前最清楚的样本：中国 CEA 与小鹏共建，西半球 RV Tech 与 Rivian 共建（见 5.5 发现四）。它的优势是速度与本地适配——18 个月投产，直接对齐中国国标与本地智驾生态。它的风险是规模经济被拆散：两套架构意味着两套验证、两套 OTA 运维、两条人才线，以及长期的整合成本。〔推断〕整车 OS 的终局未必是”one kernel to rule them all”，联邦式控制面可能是跨国车企在中国市场与西方市场标准分化之下的理性选择；但联邦能否在下一代收敛为一套，决定了这条路线最终是”过渡”还是”负债”。

3. 平台消费者：在 S4 也大量采购第三方方案（Applied Intuition、Google、芯片厂整包），把差异化集中在品牌、设计与渠道上。

4. 控制面输出者：把自己的整车控制面——连同 E/E 拓扑与开发方法——作为产品输出给其他车企。这是 2025–2026 年出现的最新形态，主角几乎都是中国车企：

   • 小鹏与大众共建 CEA（5.5）；
   • 零跑在 2026 年技术日上宣布，其电子系统已与 5 家合作伙伴合作，并向一汽、Stellantis 集团等提供整车级技术赋能〔T3〕；
   • 华为的鸿蒙座舱与乾崑覆盖 25 个品牌〔T2〕。

〔推断〕第四种形态改写了 T6 的图景。控制点 C3 不只被芯片厂（C2）和中间件 / 水平平台（C4）从上下两端挤压，还在被另一类车企横向争夺。对输入方来说，引进一套控制面比自研快得多：CEA 从概念到投产只用 18 个月。对输出方来说，控制面成了第二条收入曲线，也是规模经济的放大器——零跑自称平台通用化率 90%，正是控制面可以被复制输出的前提〔T3，企业宣称〕。Stellantis 同时与 Applied Intuition（第三方 Vehicle OS）和零跑（整车级技术）合作，说明同一家车企可以在不同市场、不同车型上分别扮演”平台消费者”与”控制面输入方”。

四种形态没有高下之分，只是对”控制点放在哪里”的不同下注。

---

八、AI 进入操作系统：沙漏与确定性治理

8.1 车里装一个大模型，不等于 AI 进入了 OS

关于”AI 与整车 OS”，最常见、也最浅的讨论是：车里装了哪个大模型——Gemini、GPT、DeepSeek、盘古还是 Grok。这只是 AI 作为一个应用。真正的变化发生在更深的地方，可以分成三个阶段。

阶段 B 有一个容易被忽视、却影响深远的推论：**模型成为一等软件制品。**今天一次 OTA 更新的是”软件包 v3.7”；明天它更新的将是”软件 + 模型 + 策略 + 智能体图 + 安全包络”的组合。生命周期管理的对象，从代码扩展到了概率性的产物。

产业已经在往阶段 B 走：

• 梅赛德斯 MBUX 虚拟助手同时集成 Microsoft 与 Google 的 AI，并基于 Gemini 构建汽车 AI 智能体〔T2〕。
• 现代汽车的 Gleo AI 智能体随 Pleos Connect 上车，官方提出从 SDV 走向”AIDV”（AI 定义汽车）〔T2〕。
• 蔚来把天枢称为”面向 AI 的整车全域操作系统”〔T2〕。
• 零跑在 2026 年技术日上发布”车云 AgentOS”：车端部署核心智能体，负责低时延与隐私敏感的任务；云端智能体负责复杂推理与长期记忆〔T3〕。〔推断〕这是一种”按信任与时延切分智能”的设计——与控制面的外环（云、OTA、数据闭环）正好对应：智能体本身也被拆成了”车上的确定部分”和”云上的扩展部分”。
• 中国汽车基础软件生态委员会（AUTOSEMO）2025 年 10 月发布的《中国汽车基础软件发展研究报告 6.0》聚焦 AIOS，提出”算力抽象—数据融合—功能服务化”的架构〔T2〕。

8.2 OS 会变薄还是变厚？

AI 会不会吸收掉操作系统？两种看法都有道理。

**变薄的一方：**交互、应用编排、功能逻辑正在被大模型与智能体吸收。过去需要写死的 HMI 流程、菜单层级、规则引擎，正在被一个能理解意图的模型替代。端到端驾驶模型也吸收了原本分成感知、预测、规划多个模块的中间件。从这个角度看，OS 的上半截正在变薄。

**变厚的一方：**模型越不确定，就越需要一个确定的骨架。资源隔离、时间确定性、安全监控、可证明的回退路径，以及 ISO/PAS 8800 要求的 AI 生命周期证据链，都必须沉到 OS 层。NVIDIA 把”用 Hypervisor 把安全关键功能与 AI 负载隔离”作为 Halos OS 的核心卖点〔T2〕，就是证据。从这个角度看，OS 的下半截正在变厚。

本文的回答是：两者同时发生。

T5｜AI 不会消灭整车 OS，而是让它两极化：上半截（交互、编排）变薄，下半截（确定性、隔离、证明）变厚，中间的服务契约成为窄腰。概率智能，必须运行在确定性的治理之内。

图 8.1　沙漏：从软件定义到 AI 定义。上部宽口：被模型吸收的交互、编排与功能逻辑。中部窄腰：控制面的服务契约。下部宽底：变厚的确定性层（隔离、调度、安全监控、回退、证据链）。右侧标注软件制品的演变：“代码” → “代码 + 模型 + 策略 + 智能体 + 安全包络”。

这与本系列 D3 的判断——“AI 是语言能力，不是大脑”——完全一致：语言能力上移，进入模型；安全的”脑干”，也就是确定性骨架，留在 OS。二者不矛盾，而是同一件事的两面。

8.3 一个可证伪的预测

“两极化”很容易被批评为”两头都对”的折中。为了避免这一点，本文给出一个明确的、可以被事实推翻的预测：

**〔推断〕2030 年之前，不会出现由大语言模型或通用智能体直接获得 ASIL D 执行器控制权的量产乘用车。**智能体可以建议、可以请求、可以调用经过授权的车辆服务，但对制动、转向等安全关键执行器的最终控制，仍将由确定性的控制面裁决。

如果这个预测被推翻，T5 就需要修订（第十章修订触发器 3）。

8.4 标准与法规：AI 进入 OS 的约束已经成形

AI 进入整车 OS，不是一个技术问题就能决定的。约束它的规则体系已经成形：

• ISO 26262（功能安全）与 ISO 21448（SOTIF，预期功能安全）〔T1〕。
• ISO/PAS 8800:2024（道路车辆——安全与人工智能），2024 年 12 月发布，裁剪了 ISO 26262 第 4、6、8 部分的相关条款〔T1〕。2025 年 8 月，SGS-TÜV Saar 向吉利颁发全球首个 ISO/PAS 8800 流程认证〔T2〕。
• UN R155 / R156（网络安全管理体系 / 软件更新管理体系），以及中国对应的强制性国标 GB 44495 / 44496 / 44497，2026 年 1 月 1 日起实施〔T1〕。

〔推断〕这些标准的共同效果是：**AI 越多，生命周期管理越重。**每一次模型更新都可能需要更新安全论证；每一个获得车辆动作权限的智能体，都需要一套可审计的权限模型。这些负担无法由模型自己承担，只能由控制面承担。

一个尚未被回答的问题：**AI 生成的 OS 代码，如何进入 ISO 26262 的安全论证？**本系列 D4 已经指出，架构工具链中”AI 生成”能力已经与”推理自主”能力解耦。在整车 OS 层面，截至本文数据截止日，我们尚未找到 AI 生成代码进入 ASIL 论证的公开量产案例。这是一个值得持续观察的空白。

---

九、路线图 2026–2035：从软件定义到 AI 定义

9.1 五个阶段

下表区分了已观察到的状态与研究假设。前三个阶段是已观察的，后两个是假设。

说明：阶段 Ⅴ 与本研究系列提出的八级 EEA 演化分类中的 L8”AI-Defined Vehicle”同名，但二者描述的对象不同：八级分类描述的是整车 EEA 的形态，本表描述的是软件控制面的形态。两个维度正交，不可混用。

9.2 Ⅲ、Ⅳ、Ⅴ 到底差在哪里

后三个阶段最容易被混为一谈。用一句话区分：Ⅲ 把功能变成了软件，Ⅳ 把软件变成了可调度的资源，Ⅴ 让模型参与决定调度什么。

数据中心的演进是一个现成的类比：

• 阶段 Ⅲ 像虚拟机时代：服务器被虚拟化了，但每台虚拟机跑什么、放在哪里，都由运维事先配好。
• 阶段 Ⅳ 像 Kubernetes 时代：工作负载被打包成标准单元，由调度器按规则放进资源池，可以迁移、扩缩、替换。
• 阶段 Ⅴ 像 AI 原生时代：调度器之上多了一层理解意图的模型，系统可以根据目标，临时组合出原本没人写过的流程。

阶段 Ⅳ 的六个特征，各有一个具体的样子：

1. **功能位置动态化。**主计算单元故障时，编排器把非安全关键功能迁移到备份单元；或者同一功能按车型配置被部署到不同节点。
   • 需要强调一个限制：ASIL D 功能在可预见的未来不会被”动态”调度。它们的迁移路径是事先设计、事先认证的冗余切换。真正动态的，主要是 QM 与低 ASIL 负载。
2. **共享算力。**车停着时，智驾芯片的大部分算力是闲置的。阶段 Ⅳ 的平台可以把它借给座舱大模型、哨兵模式的视觉分析或车端数据预处理，车一开动再按优先级收回。阶段 Ⅲ 做不到，因为座舱与智驾分属两个域、两套软件栈。
3. **跨域服务。**在阶段 Ⅲ，“露营模式”是专门开发的功能，要分别改空调、屏幕、电池管理与门锁的代码。在阶段 Ⅳ，它只是对已有服务的一次组合。中国车企的”场景编排”已经朝这个方向走，但多数仍停留在座舱层面，尚未深入车控域〔推断〕。
4. **车云开发环境一致。**同一个软件容器先在云端虚拟车上跑完回归，再部署到实车。Google 的 AAOS SDV 文档明确写道，在虚拟机中运行的设计”facilitates testing and integration in the cloud”〔T1〕。
5. **混合关键性整合常态化。**今天 Ride Flex 在 8 个量产项目中让 ASIL D 与 QM 负载共享一颗芯片〔T2〕，这还是”首批”；到阶段 Ⅳ，它会成为新平台的默认配置，而不再是卖点。
6. **模型生命周期标准化。**智驾模型的版本、验证与回滚，从各家自建，走向与软件同一条、受 ISO/PAS 8800 与 R156 约束的管线。零跑”同一模型部署到三个算力档”〔T3〕，是按硬件档位做部署决策的早期样本。

**阶段 Ⅳ 与 Ⅴ 的分界，在于谁写规则。**阶段 Ⅳ 的编排器再聪明，执行的也是工程师写好的规则。阶段 Ⅴ 中，模型与智能体开始参与决定。看一个对比：

• 阶段 Ⅳ：用户说”打开露营模式”，系统执行一个预先做好的服务组合。
• 阶段 Ⅴ：用户说”今晚在山里过夜，明早要能开回城里”。智能体自己去核对剩余电量与回程距离，算出空调可用的电量，设定电池保留下限，调低屏幕亮度，并查好明早沿途的充电桩。这个组合没有任何工程师事先写过，它在权限模型与安全包络之内被临时生成。

零跑的 AgentOS、现代的 Gleo AI、梅赛德斯基于 Gemini 的智能体，都还处在第八章所说的”AI 成为 OS 服务”阶段：能理解意图，但可调用的车辆服务范围与权限仍然有限。

**如何判断行业进入了阶段 Ⅳ？**看四个可观测信号：

1. 量产车上出现无需发布新版本、即可在计算单元间迁移的功能；
2. 同一软件容器在云端验证后，被部署到多个硬件档位；
3. 新平台默认采用 ASIL D 与 QM 共享 SoC；
4. 模型更新进入有回滚机制、受监管的统一管线。

阶段 Ⅴ 的信号是：量产车上出现通过权限模型调用车辆服务的智能体，以及没有被预先编码、由用户意图生成的功能组合。

〔推断〕三个阶段之间的边界是模糊的，同一家车企往往同时跨在两个阶段上；上表描述的是重心的移动，而不是一刀切的分界线。

9.3 控制点的迁移

〔推断〕从现在到 2030 年，D1 七个控制点中与本文相关的三个会这样变化：

• C2（SoC）：继续向上吸收，交付”芯片 + Hypervisor + 认证运行时 + 部分中间件”的整套栈。
• C3（OS）：内核与基础运行时商品化；独立价值转移到控制面的编排与生命周期。
• C4（中间件）：开源（S-CORE、星环）与标准（VSS、国标）加速收敛，契约层逐步公共化。

图 9.1　控制点夹击：C2 — C3 — C4。读图要点：C3 被上下两股力量挤压；剩下来属于车企自己的，是编排、生命周期与数据闭环（C5）。

9.4 中国路线：自研、开源、国标三线并进

中国的整车 OS 演进有一个独特的结构：自研、开源、国标三条线同时推进，并互相强化。

• 自研：蔚来天枢、华为鸿蒙座舱与乾崑、小鹏、小米等都在建设自有的软件栈〔T2〕。
• 开源：理想以 Apache 2.0 开源星环 OS（2025 年），把自研成果变成产业公共品〔T2〕。
• 国标：GB/T 47351 / 47341-2026 于 2026 年 7 月 1 日实施；GB 44495 / 44496 / 44497 三项强制性标准于 2026 年 1 月 1 日实施，并与 UN R155 / R156 协调〔T1〕。

〔推断〕国标的一个重要后果是：**它成为所有在中国销售的车企——包括外资车企——都必须对齐的接口。**国标起草单位名单中出现了梅赛德斯-奔驰中国与大众中国，说明这一点已被外资车企认识到。这也可能是”联邦式控制面”在全球出现的一个结构性原因：同一家车企，可能需要在中国与其他市场维护面向不同接口规范的软件栈。

9.5 经济与组织：真正的瓶颈

经济上，整车 OS 的回报来自四个方面：ECU 与线束的物料成本下降、软件跨车型复用、平台成本摊销，以及车辆售出后的软件收入。Rivian 2025 财年软件与服务毛利从 700 万美元跃升到 5.76 亿美元〔T1〕，说明”E/E + OS”作为资产的价值已经可以在财务报表上体现。

组织上，它的成本却经常被低估。5.1 节注意到，路线图档（M4）里的车企几乎都经历了延期。〔推断〕原因很少是技术，更多是组织：

• 把几十个按功能划分的部门改造成一个平台组织；
• 把与一级供应商之间以”黑盒 ECU”为单位的合同，改成以”软件模块 + 集成责任”为单位的合同；
• 在保持现有车型交付的同时，建设下一代平台。

这正是康威定律在整车 OS 上的体现：**你的组织长什么样，你的控制面就长什么样。**一个仍然按”车身、底盘、动力、座舱”四个部门分工的车企，很难造出一个跨越四个域的控制面。

用一句话概括本章：

**集中化以系统复杂度换掉了局部复杂度。**它消除了 100 个 ECU 之间的碎片化，却带来了更大的爆炸半径、更集中的攻击面、更复杂的验证——以及一个必须先重组自己、才能重组车辆的组织。

---

十、把刀架在自己脖子上：反论与修订触发器

10.1 七个反论

反论一：整车 OS 只是营销概念。 如果去掉品牌层，所谓整车 OS 只剩 QNX + Linux + AUTOSAR + Hypervisor。 **回应：**这正是 T1 的出发点。本文不认为整车 OS 是一个新内核，而认为它是治理多个内核的控制面。品牌确实被夸大了，但契约、编排与生命周期这三个部件是真实的、可观察的、可评分的。

反论二：中央计算未必经济。 虚拟化、冗余、液冷的开销可能抵消 ECU 削减带来的节省。 **回应：**本文不对此下结论。经济性取决于车型规模与软件收入，目前公开数据不足以判断。我们只指出，“集中化以系统复杂度换局部复杂度”——这笔交易是否划算，因车企而异。

反论三：整车 OS 反而增加系统性风险。 **回应：**同意。这正是第六章的论点：集中化把隔离从天然属性变成了必须被证明的属性。风险是否被控制，取决于 V3（混合关键性）做得怎么样。

反论四：标准化 API 会消灭车企的差异化。 **回应：**契约层的差异化确实会减少（T6），但编排、生命周期与数据闭环仍是差异化空间。差异化不会消失，只会迁移。

反论五：AI 智能体永远不应进入安全关键控制路径。 **回应：**本文的立场比这个更具体：智能体可以进入控制面，但必须在确定性的治理之下；对 ASIL D 执行器的最终控制权，在可预见的未来不会交给智能体（8.3 的预测）。

反论六：区域化软件栈会阻止全球统一的整车 OS。 **回应：**同意，而且这可能不是问题，而是终局。7.6 讨论的”联邦式控制面”就是这一判断的展开。

反论七：L4 最终需要一套独立的 OS，而不是整车 OS 的一部分。 **回应：**这是一个开放问题。双通道结构（6.6）可能意味着 L4 的安全监控通道在逻辑上独立于整车控制面。如果 L4 车队普遍采用与乘用车整车 OS 完全分离的软件栈，T4 的表述需要修订为”自动驾驶检验的是整车 OS 与安全通道的契约”。

10.2 五个修订触发器

以下任何一项事实发生，本文的相应论点都需要修订：

---

十一、结论：三个判断和一个提醒

回到标题。“OS 之系统”不是一个修辞——它是对每一辆软件定义汽车里那层东西最准确的描述。它被叫成了各种各样的”OS”名字，以至于没有人停下来问它究竟是什么。

本文的回答是：它是一个由契约、编排与生命周期构成的控制面，治理着一组操作系统，而不是任何一个操作系统本身。

判断一：整车 OS 是一个”OS 之系统”，它的边界由 E/E 划定。 叫”OS”的不一定是整车 OS，不叫”OS”的反而可能是。判别它的方法不是看品牌名，而是看契约覆盖到哪些域、编排能否证明隔离、生命周期能更新到哪一层。而这三者能走多远，首先取决于 E/E 走到了哪一代。

判断二：真正的分水岭，是因果的反转。 一家车企进入软件定义阶段的标志，不是它有没有 OS 品牌，而是共演化环的下半圈有没有开始转动——它的下一代 E/E 规格，是不是由当前这一代软件的需求定义出来的。GM 的”10 倍 / 1000 倍 / 35 倍”，BMW 与 GM 在哑化路线上的分歧，Rivian 把”E/E + OS”作为一个整体出售，都是这个环开始转动的信号。

判断三：AI 让操作系统更重要，而不是更不重要。 AI 会吸收 OS 的上半截，但会让下半截变得更厚。概率越多，确定性越珍贵。自动驾驶是检验这一点的压力测试：座舱只检验 OS 能不能跑应用，而一辆没有司机的车，检验的是整车 OS 能不能跑整车。

一个提醒：别把”拥有 OS”当成终点。 内核在商品化，契约在标准化，芯片厂与水平平台从上下两端挤压。对多数车企来说，真正的问题不是”要不要自研一个 OS”，而是”在控制面的哪一部分，我必须自己说了算”。编排、生命周期、数据闭环，以及对安全责任的最终承担——这些才是在标准化浪潮之后还属于车企自己的东西。

整车 OS 之争不会以某一个系统胜出而结束。它会以一个更朴素的问题收尾：当一辆车的每一层都可以被采购时，哪一层是你不能采购的？这张坐标系，本文已经摆在桌上；在哪里下注，始终是读者自己的决定。

---

附录 A｜证据分级与主要来源

A.1 证据分级

**说明：**所有未来时间点（GM 2028、STLA One 2027、现代 2030 等）均为企业计划或目标，不是事实，且已有延期先例。

A.2 主要来源（按章节，节选）

• QNX 装车量：BlackBerry FY2026 10-K — https://www.sec.gov/Archives/edgar/data/1070235/000107023526000039/bbry-20260228.htm
• MB.OS 量产：Mercedes-Benz Group，CLA 拉施塔特投产 — https://group.mercedes-benz.com/company/production/production-network/start-of-production-cla-rastatt.html
• 天枢：蔚来官方（NIO 十二全栈技术·整车全域操作系统篇）— https://www.nio.cn/smart-technology/20251215002 ；IT之家 — https://www.ithome.com/0/720/560.htm
• 星环 OS 开源：钛媒体 / 科技新闻汇总 — https://cn.technode.com/post/2025-03-29/lixiang-xinghuan-os/
• 国标：全国标准信息公共服务平台 — https://std.samr.gov.cn/gb/search/gbDetailed?id=0BBF0FBBBE1AE46FE06397BE0A0AD1FD ；https://std.samr.gov.cn/gb/search/gbDetailed?id=D33BADAFBDDF2CD0E05397BE0A0A113C
• GB/T 47341-2026 商业译本（T3）— https://www.chinaautoregs.com/archives/7587
• GM 中央计算平台：GM 新闻稿 2025-10-22 — https://news.gm.com/home.detail.html/Pages/news/us/en/2025/oct/1022-SDV-GM-centralized-vehicle-computer-platform-electric-gas-vehicles.html
• BMW Neue Klasse superbrains：https://www.bmwgroup.com/en/news/general/2025/superbrains.html
• 丰田 Arene / RAV4：https://pressroom.toyota.com/three-two-one-toyota-debuts-amazing-all-new-rav4/ ；https://insideevs.com/news/775729/2026-toyota-rav4-phev-arene-software-ev/
• 现代 Pleos：https://www.hyundainews.com/releases/4774 ；S&P Global Mobility — https://www.mobilityglobal.com/en-us/automotive-insights/blog/hyundai-pleos-software-launch-shifts-mobility-game
• Rivian / RV Tech：Rivian FY2025 8-K — https://www.sec.gov/Archives/edgar/data/1874178/000187417826000007/ex-991pressrelease4q25earn.htm ；DEF 14A — https://www.sec.gov/Archives/edgar/data/0001874178/000187417826000023/rivn-20260427.htm
• Qualcomm Ride Flex：TechInsights — https://www.techinsights.com/blog/qualcomm-integrates-cockpit-adas
• NVIDIA Halos：https://www.nvidia.com/en-us/ai-trust-center/halos/autonomous-vehicles/
• Google AAOS SDV：Android Developers Blog 2026-03-24 — https://android-developers.googleblog.com/2026/03/Beyond-Infotainment-Extending-Android-Automotive-OS-for-Software-defined-Vehicles.html ；AAOS SDV 系统架构 — https://source.android.com/docs/automotive/sdv/sdv-system-architecture
• Stellantis × Applied Intuition：https://www.stellantis.com/en/news/press-releases/2026/may/stellantis-and-applied-intuition-expand-collaboration-with-stla-brain-to-advance-vehicle-software-and-enhance-customer-experience
• VDA / Eclipse S-CORE：https://blogs.eclipse.org/post/sara-gallian/eclipse-sdv-2025-all-roads-lead-open-source ；https://www.adt.media/software-defined-vehicles/vda-and-eclipse-foundation-expand-sdv-software-ecosystem/2587652
• ISO/PAS 8800：UL — https://www.ul.com/sis/blog/safety-related-systems-road-vehicles-artificial-intelligence-are-addressed-isopas-88002024 ；吉利认证（SGS）— https://www.sgs.com/en-hk/news/2025/08/geely-auto-awarded-first-global-ai-safety-certification-for-road-vehicles
• 华为鸿蒙座舱 / 乾崑装车量：https://news.qq.com/rain/a/20260908A0664N00
• AUTOSEMO 报告 6.0：东软睿驰新闻稿（2025 年 10 月），代表 AUTOSEMO 发布《中国汽车基础软件发展研究报告 6.0》 — https://www.reachauto.com/en/2025/10/
• 大众集团 CEA：Volkswagen Group 新闻稿 2026-01-28 — https://www.volkswagen-group.com/en/press-releases/volkswagen-group-china-starts-production-of-its-first-locally-developed-zonal-electronic-architecture-20144 ；CarNewsChina — https://carnewschina.com/2026/01/29/volkswagen-starts-production-of-xpeng-co-developed-cea-architecture-five-new-models-due-in-2026/ ；CarNewsChina 2025-12-10 — https://carnewschina.com/2025/12/10/volkswagen-and-xpengs-first-joint-vehicle-id-unyx-07-nears-production-after-just-18-month-chinese-led-development/ ；IT 之家 — https://www.ithome.com/0/903/897.htm
• RV Tech：Volkswagen Group 新闻稿 2025-11-12 — https://www.volkswagen-group.com/en/press-releases/one-year-after-its-founding-joint-venture-between-volkswagen-group-and-rivian-shows-strong-progress-19980 ；冬季测试 — https://www.electrive.com/2026/03/27/vw-and-rivian-conclude-winter-testing-programme/
• 零跑 LEAP 5.0：Stellantis Media（Leapmotor Tech Day 2026，2026-09-30）— https://www.media.stellantis.com/uk-en/leapmotor/press/leapmotor-unveils-next-generation-vehicle-architecture-battery-technology-at-tech-day-2026 ；Gasgoo — https://autonews.gasgoo.com/articles/ev/leapmotor-counters-tech-peak-theory-with-one-architecture-and-three-systems-2101156419729817601 ；新浪汽车 2026-09-16 — https://auto.sina.cn/news/2026-09-16/detail-inirzwqt4627345.d.html
• UN R156（第 7.1.1 条原文）：EUR-Lex — https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:42021X0388
• 丰田 Arene（2023 表述）：Toyota 新闻稿 2023-04-11 — https://global.toyota/en/newsroom/corporate/39070846.html
• AUTOSAR Adaptive 与 POSIX：UL Solutions — https://www.ul.com/sis/blog/autosar-part-2-adaptive-platform
• SOAFEE：https://www.globenewswire.com/news-release/2026/04/22/3279060/0/en/here-joins-soafee-to-bring-expertise-in-ai-powered-mapmaking-into-open-software-defined-vehicle-platforms.html ；Open AD Kit — https://autoware.org/open-ad-kit-the-first-soafee-blueprint-powering-open-collaboration-in-autonomous-driving/
• Eclipse Open Vehicle API：https://projects.eclipse.org/projects/automotive.openvehicle-api/reviews/eclipse-open-vehicle-api-2026.08-progress-review
• CARIAD 重组（T3）：https://allthingstalent.org/volkswagen-to-cut-1600-jobs-at-cariad-software-division-in-major-restructuring-move/2025/03/13/

---

附录 B｜VOCM 评分细则

每个维度 0–5 分。评分只依据公开资料；证据不足的维度不得高于 2 分，或标为 n.a.。

**置信度：**H = 多数维度有 Tier 1–2 直接证据；M = 部分维度依赖企业宣称；L = 多数维度依赖二手资料或推断。

**同源例外：**与已评分车企共同开发、沿用同一架构体系的平台（如大众 CEA 之于小鹏），在自身公开信息不足的维度上可参照同源方评分，须在备注中逐项注明，置信度最高为 L。

---

附录 C｜缩写表

---