欧美为什么现在集体放弃新能源汽车了?

调研范围：聚焦新能源汽车（尤其是新势力、智能网联汽车）从设计到生产之间的技术资料传递与技术状态管理，分别从硬件与软件两个维度展开分析。
调研时间：2026年6月
关键词：技术状态管理、BOM/PLM、数字主线、MBSE、软件定义汽车、OTA升级、CI/CD、变更管理

目录

1. 核心概念与行业背景
2. 硬件维度的技术状态管理

• 2.1 BOM管理体系：从EBOM到MBOM
• 2.2 PLM系统：设计与生产的桥梁
• 2.3 工程变更管理：ECR/ECO/ECN闭环
• 2.4 新势力车企的硬件管理实践

1. 软件维度的技术状态管理

• 3.1 软件定义汽车（SDV）下的新挑战
• 3.2 软件版本管理与CI/CD
• 3.3 OTA升级管理体系
• 3.4 ASPICE与ISO 26262合规

1. 硬件-软件协同管理
2. 政策法规环境
3. 趋势展望
4. 结论与建议
5. 参考文献

一、核心概念与行业背景

1.1 技术状态管理的定义与范畴

技术状态管理（Configuration Management） 是指在产品生命周期内，运用技术和管理手段，对产品的功能特性、物理特性进行标识、控制、记录和审核的活动。在汽车行业，它涵盖了从产品定义、设计开发、生产制造到售后服务的全过程。

核心要素包括：

• 技术状态标识：定义产品结构（BOM）、确定配置项
• 技术状态控制：变更管理（ECR/ECO/ECN）
• 技术状态记实：版本管理、基线管理
• 技术状态审核：一致性检查与验证

1.2 新能源汽车行业的技术状态管理特殊性

与传统燃油车相比，新能源汽车（尤其是智能网联汽车）的技术状态管理面临四大根本性变化：

二、硬件维度的技术状态管理

2.1 BOM管理体系：从EBOM到MBOM

BOM（Bill of Materials，物料清单）是汽车行业技术资料传递的核心载体，是连接设计、采购、生产、售后的数据纽带。

2.1.1 汽车BOM的多视图体系

汽车行业的BOM管理呈现典型的多视图特征，不同阶段和部门需要不同视角的BOM：

关键技术痛点：EBOM向MBOM的转化是技术资料传递中最容易出错的环节。传统做法依赖工艺工程师手工转换，效率低且易出错。

2.1.2 新能源与智能网联汽车BOM管理的新特点

1. 电子电气BOM的崛起：三电系统（电池、电机、电控）和智能驾驶域控制器成为BOM的核心模块，其变更频率远高于传统机械件。
2. 软件BOM（SBOM）的出现：智能网联汽车需要管理软件组件清单（Software BOM），包括操作系统版本、中间件、应用软件、AI模型版本等。
3. 配置管理的超级复杂性：新能源车型的选装配置组合可达数万种，传统BOM管理方式难以应对。

行业实践：领先企业采用”超级BOM + 配置规则引擎“模式，通过150% BOM覆盖所有可能配置，再通过配置规则筛选出具体车型的100% BOM。

2.2 PLM系统：设计与生产的桥梁

2.2.1 PLM在汽车行业的定位

PLM（Product Lifecycle Management，产品生命周期管理）系统是技术状态管理的IT基础设施，在汽车行业中承担以下核心功能：

• 设计协同：管理CAD数模、图纸的版本与权限
• BOM管理：作为EBOM的权威数据源
• 变更管理：驱动ECR/ECO/ECN流程
• 配置管理：管理车型平台和选装配置

2.2.2 PLM与周边系统的集成架构

                    ┌─────────────┐
                    │   CAD/CAE   │  设计工具
                    └──────┬──────┘
                           │ 设计数据
                    ┌──────▼──────┐
                    │    PLM      │  产品数据管理核心
                    │ (Teamcenter/│
                    │  Windchill/ │
                    │   ENOVIA)   │
                    └──┬──────┬──┘
                     EBOM发布 │      │ 变更通知
                    ┌──▼──┐ ┌─▼──────┐
                    │ ERP │ │  MES   │
                    │     │ │        │
                    └─────┘ └────────┘
                   采购/财务   生产执行

关键集成逻辑：

• PLM→ERP：EBOM转化为MBOM后推送至ERP，驱动采购和成本核算
• PLM→MES：工艺路线、作业指导书推送至MES，指导现场生产
• MES→PLM：生产实测数据回传，形成设计-制造闭环

2.2.3 主流PLM平台与国产替代趋势

趋势洞察：新势力车企倾向于自研+开源+商业PLM混合模式，而非全盘采购传统PLM套件。例如，理想汽车在研发组织重构中采用了高度自研的数据管理架构。

2.3 工程变更管理：ECR/ECO/ECN闭环

2.3.1 变更管理的三阶段模型

工程变更是技术状态管理中频次最高、风险最大的环节。行业标准采用ECR→ECO→ECN三阶段流程：

ECR（工程变更请求）        ECO（工程变更指令）        ECN（工程变更通知）
  "我想改这个"      →       "按这个方案改"      →      "所有人都按新规矩来"
  
  问题识别阶段                方案执行阶段                信息同步阶段
  - 提出变更需求              - 制定技术方案              - 通知所有相关方
  - 评估可行性                - 明确执行步骤              - 更新图纸/BOM
  - 成本/风险分析             - 分配责任人                - 供应商切换
  - 审批决策                  - 设定验证标准              - 售后备件更新

2.3.2 新能源汽车变更管理的新特点

1. 软件驱动的变更激增：软件版本的频繁迭代导致硬件接口和参数的关联变更大幅增加。一个软件功能升级可能触发多个ECU的硬件配置调整。
2. 变更传播路径复杂化：三电系统、智能驾驶域、座舱域之间的耦合关系使得变更影响分析更加困难。
3. 供应商协同深度增加：电池、芯片等核心零部件的变更需要Tier-1供应商的深度参与。

行业数据：据行业调查，实施数字化变更管理的企业，工程变更周期可缩短30%以上，BOM错误率可降低50%以上。

2.4 新势力车企的硬件管理实践

2.4.1 蔚来：智能制造驱动的全链数字化

蔚来F2工厂代表了新势力在硬件技术状态管理方面的最高水平：

• “飞地”智能装配岛：全球首创的柔性生产线架构，支持多车型混线生产和个性化定制，实现了”一车一BOM”的实时驱动
• 高精度在线测量系统：车身自适应定位技术可检测0.05mm级误差，100%在线实时监测，异常即时闭环
• “天瞳”智能检验岛：自研AI质检系统，32个检测项目，缺陷识别准确率从人工的92%提升至99.7%
• IT/OT融合的工业互联网：自研工业AI算法 + Wi-Fi 6 + 5G，打通信息技术与运营技术的边界

2.4.2 特斯拉：数字孪生驱动的设计制造一体化

特斯拉在硬件技术状态管理方面的革命性在于数字孪生技术的深度应用：

• 数字线程（Digital Thread）：打通设计到生产的数据流，工程变更响应时间缩短至2小时
• 虚拟验证取代物理样车：电池冷却系统优化周期缩短75%，虚拟调试使零部件安全库存降低35%
• 数据闭环：每辆车每天生成1.6TB数据，通过数字孪生体实时反馈至研发端
• 设备综合效率（OEE）：上海超级工厂利用数字孪生预验证产线节拍，OEE提升至92%

2.4.3 理想汽车：研发组织重构驱动效率变革

理想汽车在2026年1月完成了重大研发组织调整，对技术状态管理产生深远影响：

• 四大核心体系：将研发重组为”数字人器官”（芯片/数据集/操作系统）、”脑系统”（感知/训练/Infra）、”软件本体”、”硬件本体”四大体系
• 硬件本体体系：整合能源、驱动、控制体系，不再按单独控制器拆分，通过MCP协议实现模型对所有执行环节的直接控制
• 效率提升：智驾模型迭代周期从2周一次缩短至1天一次

2.4.4 小鹏汽车：全栈自研物理AI体系

小鹏的技术状态管理建立在全栈自研基础上：

• 3万卡云端算力集群：运行效率>90%，支撑720亿参数基座模型
• “芯片-算子-模型”全链路优化：自研图灵AI芯片 + 针对性编译器，实现车端数十亿级参数模型部署
• 数据驱动：近1亿clips训练数据，无需人工标注，每5天全链路迭代一次
• 明确量产时间表：VLA 2026年Q1全量推送，Robotaxi 2026年量产试运营

三、软件维度的技术状态管理

3.1 软件定义汽车（SDV）下的新挑战

3.1.1 汽车软件的爆炸式增长

软件定义汽车（Software Defined Vehicle, SDV）是当前行业最深刻的变革。现代高端智能汽车包含：

案例：福特2023款纯电SUV CX727项目包含70+ ECU、1500万行代码、5万条需求、100万页文档。

3.1.2 软件技术状态管理的核心挑战

1. 版本爆炸：每个ECU有独立软件版本，整车软件配置组合可达数百万种
2. 跨域依赖：智能驾驶、座舱、车身、动力域的软件存在复杂的接口依赖
3. 持续变更：OTA升级使车辆出厂后仍持续接收软件更新，出厂时的技术状态基线不断被打破
4. 安全合规：功能安全（ISO 26262）、网络安全（ISO 21434）、数据安全等要求对软件变更施加严格约束

3.2 软件版本管理与CI/CD

3.2.1 汽车行业的DevOps转型

传统汽车软件开发采用V模型，周期长达6-18个月。SDV时代要求转向DevOps模式：

3.2.2 SDV工具链架构（参考Eclipse SDV工作组）

┌─────────────────────────────────────────────────┐
│                   开发工具层                       │
│  GitHub / VS Code / Dev Box / Container Registry  │
├─────────────────────────────────────────────────┤
│                CI/CD 编排层                        │
│    元数据管理 → 构建 → 测试 → 部署 → 监控          │
├─────────────────────────────────────────────────┤
│                执行环境层                          │
│  SIL（软件在环）  │  HIL（硬件在环）  │  实车验证    │
│  vECU / vHPC     │  目标硬件         │  测试车队    │
├─────────────────────────────────────────────────┤
│                车辆软件栈                          │
│  服务注册  │  动态主题管理  │  数字孪生  │  云同步   │
│  (Chariott)│  (uProtocol)   │  (Ibeji)  │ (Freyja) │
└─────────────────────────────────────────────────┘

关键实践：

• 虚拟ECU（vECU）：在硬件就绪前通过云端虚拟环境进行软件开发和验证，实现”软硬分离”并行开发
• SIL→HIL→实车三级验证：软件在环→硬件在环→实车测试的渐进验证体系
• 容器化部署：汽车应用以容器形式部署，支持独立的版本管理和升级

3.2.3 软件物料清单（SBOM）管理

智能网联汽车需要建立软件BOM作为技术状态基线：

整车软件基线
├── 自动驾驶域
│   ├── 感知模型 v3.2.1
│   ├── 规划决策 v2.1.0
│   └── 控制执行 v1.8.3
├── 智能座舱域
│   ├── 操作系统 v4.0
│   ├── 语音助手 v2.5
│   └── 导航引擎 v6.1
├── 车身域
│   ├── BCM固件 v3.0
│   └── 网关软件 v5.2
└── 三电域
    ├── BMS软件 v7.1
    ├── VCU软件 v4.3
    └── OBC/DCDC v2.8

合规要求：工信部2025年45号文要求企业在车辆产品主要技术参数表中补充OTA升级信息，实质上推动了SBOM的标准化管理。

3.3 OTA升级管理体系

3.3.1 OTA技术分类

3.3.2 OTA升级的技术状态管理要求

OTA升级本质上是出厂后对技术状态的持续变更，其管理要求包括：

1. 升级前基线记录：完整记录升级前各ECU的软件版本和配置参数
2. 升级包版本管理：每个OTA升级包需有唯一版本号，记录变更内容和影响范围
3. 升级过程可追溯：记录升级时间、升级结果、异常情况
4. 回滚机制：升级失败时能回退至上一稳定版本
5. 用户告知与授权：涉及主要技术参数变更的需用户确认

3.3.3 典型OTA流程

云端开发     →    灰度发布    →    全量推送    →    升级执行    →    效果验证
(CI/CD构建)     (1%-5%车辆)      (剩余车辆)       (车端下载安装)    (影子模式评估)

3.4 ASPICE与ISO 26262合规

3.4.1 ASPICE对软件配置管理的要求

ASPICE（Automotive SPICE）是汽车软件过程改进和能力评定的核心标准，其SUP.8配置管理过程域对技术状态管理提出了明确要求：

• 配置管理计划：制定详细的配置管理计划，明确管理目标、流程、角色和职责
• 配置项标识：对软件代码、需求文档、设计文档、测试用例等进行系统化标识
• 版本控制：采用Git/SVN等工具对配置项进行版本管理，记录变更历史
• 基线管理：在关键节点建立配置基线（功能基线、分配基线、产品基线）
• 工具链支持：Jira、Azure DevOps、Polarion等ALM工具支撑配置管理流程

3.4.2 ISO 26262对技术状态管理的要求

ISO 26262（道路车辆功能安全）从安全生命周期角度对技术状态管理提出约束：

• 安全相关配置项管理：对安全需求、安全机制设计、安全测试用例等进行严格管理
• 工具鉴定：对软件开发工具进行可靠性评估（TI/TD/TCL三级）
• 可追溯性：建立从安全目标→安全需求→架构设计→实现→测试的完整追溯链
• 变更影响分析：任何变更需评估对功能安全的影响

行业共识：ASPICE与ISO 26262构成汽车软件质量与安全的”双支柱”，协同实施是行业最佳实践。

四、硬件-软件协同管理

4.1 机电软一体化的技术状态管理框架

新能源汽车的技术状态管理已从单纯的硬件BOM管理，演进为机电软一体化的综合管理体系：

技术状态基线
                             │
          ┌──────────────────┐
          ▼                  ▼                  ▼
    硬件配置基线          软件配置基线         标定数据基线
    (Hardware Config)    (Software Config)    (Calibration)
          │                  │                  │
    
    │ EBOM       │      │ SBOM      │      │ 参数集     │
    │ MBOM       │      │ 版本号    │      │ MAP图      │
    │ 硬件版本   │      │ 依赖关系  │      │ 配置开关   │
    │ 序列号追溯 │      │ 数字签名  │      │ 标定日期   │
    
 
          └───────────┼────────────┘
                             ▼
                    整车技术状态标识
                    (Vehicle Configuration)

4.2 数字主线（Digital Thread）：贯通设计到生产

数字主线是实现硬件-软件协同管理的核心技术理念。它构建了从概念设计到运行维护的连续数据流：

核心价值：确保”设计即所得、生产即所设计”，消除设计与生产之间的信息断层。

4.3 MBSE：基于模型的系统工程

MBSE（Model-Based Systems Engineering）正在成为新能源汽车技术状态管理的方法论基础：

4.3.1 从文档驱动到模型驱动

4.3.2 汽车行业的MBSE应用案例

案例：某头部新势力800V高压平台研发

传统模式下，机械、电子、软件部门设计冲突频发——PDU散热孔与芯片布局偏差5mm，单次返工成本超200万元。采用MBSE后：

• 使用SysML搭建需求-功能-逻辑-物理四维度数字孪生体
• 实现散热孔与芯片位置1:1匹配
• 电子部电路板设计直接调用物理模型参数
• 研发周期从7个月缩短至4个月，样品一次性通过所有测试

案例：福特CX727纯电SUV

• MBSE打通”用户需求→系统架构→整车仿真→功能安全→系统集成”全流程
• 首台原型车下线前完成9万公里虚拟里程，发现142项设计缺陷（37%为跨域耦合问题）
• 需求变更响应时间从7天缩短至1.5天
• 原型车从6轮减少至3轮，节省4200万美元
• 功能安全文档一次性通过TÜV审核，SOP提前6周

4.4 新势力车企的软硬件协同实践对比

五、政策法规环境

5.1 智能网联汽车OTA升级管理新规

2025年2月，工业和信息化部、市场监管总局联合发布《关于进一步加强智能网联汽车产品准入、召回及软件在线升级管理的通知》（工信部联通装〔2025〕45号），这是中国对智能网联汽车技术状态管理最具里程碑意义的法规：

5.1.1 核心要求

5.1.2 对技术状态管理的实质影响

• 软件变更被纳入正式监管：OTA不再只是技术行为，而是受监管的产品变更行为
• 软件技术状态基线法定化：OTA升级信息作为技术参数纳入公告管理，实质上建立了法定的软件基线
• 分类管理倒逼内控：企业需建立清晰的OTA分类评估机制，区分”主要技术参数变更”与”一般升级”
• 追溯性成为合规刚需：事件报告和沙盒监管要求软件版本、变更历史完整可追溯

5.2 其他关键法规与标准

六、趋势展望

6.1 方法论层面

趋势一：MBSE全面取代文档驱动

基于模型的系统工程将从领先企业的实践走向行业标配：

• 系统模型成为”单一数据源”（Single Source of Truth），取代分散的文档体系
• 需求→功能→逻辑→物理（RFLP）四层模型成为标准设计范式
• 变更影响分析由模型自动完成，而非依赖专家经验
• 预测：2028年前，头部新势力和自主品牌将全面导入MBSE方法

趋势二：数字主线贯通全生命周期

从”设计到生产”的数据贯通将扩展为”从概念到报废”的全生命周期数字主线：

• CAD→PLM→ERP→MES→售后系统的端到端数据流
• 每次工程变更在所有系统中自动同步，消除信息孤岛
• 生产反馈数据实时回流至设计端，形成持续改进闭环

趋势三：AI驱动的技术状态管理

人工智能将深度嵌入技术状态管理流程：

• 智能变更分析：AI自动评估变更影响范围，推荐最优变更方案
• 配置优化：基于历史数据和市场反馈，AI推荐最优车型配置组合
• 异常检测：AI监控生产数据与设计基线的偏差，自动告警
• 生成式AI辅助：自动生成变更通知文档、测试用例、追溯报告

6.2 技术工具层面

趋势四：云原生PLM与SaaS化

传统本地部署的PLM系统正向云原生架构迁移：

• 支持全球化分布式团队的实时协同设计
• 弹性扩展满足大规模仿真和数据处理需求
• API-first架构便于与DevOps工具链集成
• 代表方向：西门子Teamcenter X（SaaS）、PTC Windchill+（云原生）、Aras Innovator（开放架构）

趋势五：软件-硬件版本联合管理平台

独立管理的硬件BOM和软件BOM将走向统一的技术状态管理平台：

• 单一平台管理机械、电子、软件全要素配置
• 软件版本与硬件版本自动关联，建立联合基线
• 跨域变更影响分析自动化
• 整车数字孪生作为技术状态的实时镜像

趋势六：OTA升级管理平台成熟化

随着法规要求的明确，OTA升级管理将从技术工具升级为合规管理平台：

• OTA全生命周期管理：开发→测试→审批→备案→发布→监控
• 软件版本树状管理和车辆级配置追踪
• 升级安全验证和回滚机制自动化
• 与监管机构备案系统的数据接口标准化

6.3 产业组织层面

趋势七：研发组织从功能型向产品型转变

理想的”四大体系”重构代表了行业趋势：

• 从按”硬件/软件”分工 → 按”产品能力”分工
• 打破部门墙，围绕产品功能组建跨域团队
• 软件本体与硬件本体通过标准化协议（如MCP）解耦
• 技术状态管理从部门级上升为企业级治理

趋势八：供应链技术状态协同深化

智能网联汽车的复杂供应链要求更紧密的技术状态协同：

• 联合基线管理：OEM与Tier-1供应商共享技术状态基线
• 协同变更管理：供应商变更自动触发OEM端的影响分析和审批
• 数字孪生共享：核心零部件的数字孪生模型在供应链中共享
• SBOM透明化：供应商提供标准化的软件物料清单，满足网络安全合规

6.4 趋势总结表

七、结论与建议

7.1 核心发现

1. 技术状态管理正在经历范式转变：从以硬件BOM为中心的静态管理模式，转向机电软一体化的动态、持续管理模式。软件定义汽车使技术状态管理从”阶段性”变为”持续性”。
2. 新势力车企在技术状态管理上实现了”弯道超车”：蔚来、小鹏、理想、特斯拉等新势力从零开始构建数字化体系，避免了传统车企的历史包袱，在数字主线、数据闭环、研发组织等方面展现出更强的前瞻性。
3. 硬件与软件的技术状态管理仍存在脱节：大多数企业的硬件BOM管理和软件版本管理运行在独立系统中，缺乏统一的联合基线管理和跨域变更影响分析能力。
4. 法规正在成为技术状态管理的核心驱动力：2025年工信部45号文的发布，使OTA软件升级的合规管理从”企业自发行为”升级为”法定要求”，倒逼行业建立规范化的软件技术状态管理体系。
5. AI和数字孪生是下一代技术状态管理的核心使能技术：特斯拉、小鹏等企业的实践表明，数字孪生技术可以将设计到生产的反馈周期从天级缩短至小时级，AI技术则有望实现变更影响的自动分析。

7.2 发展建议

对整车企业：

对零部件供应商：

• 建立与OEM协同的技术状态管理机制，支持联合基线和协同变更
• 提供标准化SBOM，满足OEM的网络安全和功能安全合规需求
• 投资数字化工具链，提升与OEM系统的互操作能力

对行业/监管：

• 加快汽车软件升级国标（GB/T）的制定，提供统一的技术规范
• 推动OTA备案信息标准化，促进行业数据互通
• 鼓励MBSE和数字主线技术的行业推广和人才培养

八、参考文献

1. 工业和信息化部、市场监管总局.《关于进一步加强智能网联汽车产品准入、召回及软件在线升级管理的通知》（工信部联通装〔2025〕45号）. 2025年2月.
2. 中国汽车工程学会.《2026年度中国汽车十大技术趋势报告》. 2025年10月.
3. 伊迪安（IDEON）. 软件定义汽车DevOps工具链. 知乎专栏, 2025年4月.
4. 知乎作者（匿名）. 浅谈汽车行业的数据管理（BOM/PLM）. 知乎, 2021年11月.
5. 知乎作者. 工程变更管理ECR、ECO、ECN一文搞懂. 知乎, 2025年9月.
6. 知乎作者. 特斯拉数字孪生黑科技：一辆车如何拥有”数字分身”. 知乎, 2025年5月.
7. honglinonline. 基于模型的系统工程（MBSE）框架完整解析. CSDN, 2026年4月.
8. Sumedhas Tech Solutions. Digital Thread in Manufacturing: Connecting CAD, PLM, ERP and MES. 2026年3月.
9. 蔚来汽车. 蔚来十二全栈技术 - 智能制造篇. 蔚来官网, 2025年12月.
10. 腾讯云开发者社区. 李想：理想今年1月已完成研发团队组织重构. 2026年3月.
11. 搜狐汽车. 从车端到云端，小鹏全栈自研物理AI体系首度全面曝光. 2025年11月.
12. 亚远景科技. ASPICE与ISO 26262的协同：实现功能安全与流程合规. aspice.cn.
13. 亚远景科技. ASPICE与ISO 26262：汽车软件配置管理的技术与工具支撑. aspice.cn.
14. CSDN. 软件定义汽车中的DevOps实践与CI/CD创新. 2026年5月.
15. 汽车电子与软件. 整车VCU软件版本管理及SVN工具的二次开发. 微信公众号.
16. Eclipse SDV Working Group. Automotive Software Stack and SDV Toolchain Architecture. eclipse.org.

报告说明：本报告基于公开资料和行业研究综合形成，信息截至2026年6月。部分案例和数据来源于企业公开披露和行业分析报告，仅供研究参考。