夜雨聆风主机厂的软件管理，正在从“把某个车型按期交付”转向“持续经营一套可复用的软件平台”。这不是给研发部门换一个名字，而是把需求、架构、基础软件、应用、车型配置、OTA和售后运营放到同一条产品链里。
Volkswagen Group公开资料提到CARIAD平台需要与多个品牌协作、按区域适配并全球规模化；Mercedes-Benz在MB.OS资料中强调跨产品线复用和硬件软件标准化；GM则把Ultifi描述为连接车辆、云服务和应用的端到端软件平台。不同企业的组织方式不同，但管理问题高度相似。
本文不讨论哪家主机厂的路线最好，而是从内部管理视角拆出一套可落地的框架：谁拥有平台、如何拆产品、如何控制车型变体、如何组织供应商，以及如何把“软件质量”变成可度量的经营指标。
01｜主机厂为什么必须建立软件产品组织
项目制适合一次性硬件交付，却不适合需要多年更新的软件。车型项目结束后，软件仍然要修漏洞、适配新硬件、增加功能、支持不同市场并处理车队反馈。如果没有产品组织，软件责任会在项目结束时失去归属。
项目交付：关注里程碑、样车、量产和法规节点，适合制造业的确定性交付。
平台产品：关注API、基础软件、工具链、版本兼容和长期复用，服务多个车型。
车队运营：关注线上质量、更新成功率、故障趋势和用户价值，贯穿车辆全生命周期。
图1｜主机厂软件管理的三层目标：项目交付、平台产品与车队运营
02｜平台产品到底要交付什么
平台不是一个模糊的“软件底座”部门。它应该像产品一样有清晰边界、客户、接口和版本节奏。主机厂内部的客户可能是车型项目、品牌团队、售后运营，也可能是座舱、智驾和能源等域团队。
基础平台：启动、OS、虚拟化、网络、诊断、日志、更新和安全服务。
车辆服务：速度、挡位、能源、门锁、热管理、驾驶状态等跨域可信接口。
开发平台：仿真、虚拟原型、CI、测试、刷写、数据和故障分析工具。
运营平台：版本、车队、用户反馈、远程诊断、OTA和软件质量看板。
图2｜软件平台的交付物：基础平台、车辆服务、开发平台与运营平台
工程提醒：如果平台团队只交付一份架构图和一套SDK，它还不是平台产品。平台必须提供兼容承诺、样例、工具、测试证据和清晰的升级策略。
03｜软件架构委员会要管哪些决策
主机厂常见的问题不是没有架构师，而是关键决策没有形成可追溯的治理机制。架构委员会不应该审查每个函数，而要把会影响多个车型和多年生命周期的决策集中起来。
边界决策：哪些能力归中央平台，哪些能力留在域或区域节点，哪些能力允许供应商自定义。
接口决策：车辆服务、数据模型、诊断语义、时间同步和安全权限如何保持兼容。
变体决策：哪些差异通过配置解决，哪些差异值得形成独立分支，哪些差异必须拒绝。
风险决策：性能、功能安全、网络安全、许可证和供应链风险由谁接受、谁关闭。
图3｜软件架构委员会：边界、接口、变体与风险四类决策
04｜车型项目如何消费平台能力
平台与车型项目之间需要类似“产品目录”的关系。车型项目不应该直接复制平台代码，而应选择一个经过验证的平台版本，再声明自己的硬件、功能、法规和品牌配置。
平台基线：规定OS、BSP、通信、诊断、安全和更新能力的版本组合。
车型配置：声明芯片、传感器、屏幕、市场、品牌和功能包的差异。
集成验证：只验证变体差异和跨域交互，不重复验证所有平台基础能力。
发布回馈：把车型项目发现的问题反哺平台，而不是只在项目分支里打补丁。
图4｜车型项目消费平台：基线、配置、集成验证与问题回馈
05｜软件供应商怎么被主机厂管理
主机厂不能只用采购合同管理软件。真正的软件管理，需要把供应商交付物、接口、构建、测试、漏洞、版本和现场责任连到同一套工程系统。
交付物清单：源代码或可审计工件、SBOM、接口说明、测试报告、故障反应和版本说明。
接口责任：明确数据所有权、时间预算、权限、诊断、更新和回滚责任。
质量门禁：把静态分析、单元测试、集成测试、故障注入和实车验证设为发布条件。
现场责任：定义漏洞响应、数据分析、远程诊断、升级失败和长期维护的SLA。
图5｜主机厂管理软件供应商：交付物、接口、质量门禁与现场责任
06｜软件管理指标，不能只有进度
如果软件部门只用项目进度、缺陷数量和人员投入衡量绩效，团队会倾向于短期交付，而不是长期可维护。更有效的指标要覆盖平台复用、线上质量和更新能力。
复用指标：平台版本被多少车型采用，重复代码和重复测试是否下降。
工程指标：构建成功率、自动化测试覆盖、回归周期、缺陷逃逸和关键路径耗时。
运营指标：OTA成功率、回滚率、现场故障关闭时间、线上崩溃和用户反馈。
风险指标：未关闭漏洞、供应商响应时延、未知组件比例和安全案例完成度。
07｜组织转型的三个常见误区
误区一：把所有开发人员集中到一个中央部门，结果车型和用户问题离平台更远。
误区二：把“平台化”理解成所有车型必须完全相同，结果配置和品牌差异被迫绕过平台。
误区三：只建立工具平台，不建立版本、接口和责任治理，最后又回到项目分支。
主机厂的软件管理，本质是把一次性交付变成持续经营：平台要有产品负责人，车型要有清晰的消费方式，供应商要有可验证的接口，车队要能反馈真实质量。软件组织越早建立这些机制，后续的中央计算、区域架构和OTA越容易形成规模效应。
参考资料
1. Volkswagen Group：CARIAD平台与集团软件协作说明，https://www.volkswagen-group.com/en/cariad-16008
2. Volkswagen Group Annual Report 2024：CARIAD、E³架构与SDV Hub，https://annualreport2024.volkswagen-group.com/group-management-report/sustainable-value-enhancement/research-and-development.html
3. Mercedes-Benz Group：MB.OS平台与跨产品线复用，https://group.mercedes-benz.com/technology/digitalisation/operating-system/mb-os.html
4. General Motors：Ultifi端到端车辆软件平台，https://news.gm.com/home.detail.html/Pages/news/us/en/2021/sep/0929-ultifi.html
如果这篇内容对你有帮助，欢迎关注“人与车科技”，也欢迎转发给正在做汽车电子软件的朋友。
人与车科技
汽车电子软件架构、MCU 与 SDV
从一手资料回到工程问题