整车软件开发流程介绍

一、背景

整车基线管理，实质是整车的软件版本管理问题，故事要从车厂的整车开发流程说起。车企均具有完整的整车开发流程，其贯穿了车型开发的生命周期，各家流程大同小异。以通用汽车经典的GVDP(Global Vehicle Development Process，整车开发流程)为例。



图1 通用GVDP整车开发流程

GVDP将整车研发流程分为了多个阶段，定义了各里程碑节点(G9~G1)。里程碑意味着本阶段交付物的锁定及下阶段交付物的启动。交付物包括 SOR 发布、数据发布，定点，送样、认可，生产断点、零部件版本的更新等，以整车零部件硬件作为单元，通过跨部门的团队合作跟踪零部件的诞生直至零部件最终成熟，从而协调、跟踪和控制零件可用性，并保证零部件软硬件状态均满足项目要求。

对零件的生命周期管理，大部分车厂采用PDM[1]+BOM[2]的系统方案，同时在PDM系统集成Catia、ProE等工程制图软件，将车型零件的工程数据和文档联系起来，实现对零件数据的组织、管理与控制。系统方案保证了工程、制造、售后等数据的一致性，支持各部门的高效协作，规范企业技术管理行为并实现流程制度化，提高了企业研发效率。

注释：

[1] PDM(Product Data Management，产品数据管理)，提供规范的业务流程管理，文档管理、CAD 集成管理、产品配置管理、设计变更管理等。缩短产品的设计周期，加快产品投入市场的进度。

[2] BOM(Bill of Material，物料清单)有的汽车企业也叫做零件俱乐部，是汽车生产企业的主导数据，贯穿从项目预言、立项、研发设计、试生产、正式生产制造到销售以及售后服务的各个方面。



图2 PDM/BOM零件生命周期管理

PDM/BOM系统中定义了整车结构树的概念。整车结构树由各零件总成组成，硬件、软件、配置文件等作为零件总成下的子节点，如图3所示。



图3 整车结构树

由于软件为零件总成的子节点，同时车型配置信息和零件硬件具备关联关系，因此控制器的软件变更和管理依赖零件进行，识别高低配车辆的不同控制器软件亦通过车型的硬件配置实现。

二、问题起源

在软件定义汽车热潮前，先前整车开发流程和零件生命周期管理有序保证了整车零件软硬件的顺利开发和量产。例如GVDP要求，G3（预试生产）阀点前必须锁定零件的状态，即冻结零件的硬软件信息。由于先前车型的功能简单，软件相对独立，代码量少。SOP后亦无新需求迭代。因此软件会随硬件于同一节点冻结，并在产线一次性交付。

然而近几年随着车联、智驾、座舱等新功能兴起，整车电子架构日新月异，控制器数量大幅增加，SOP后的软件频繁迭代，车企必须实施整车软硬件的开发流程并行管理，整车物理结构与整车功能有效解耦迫在眉睫。传统车企的整车开发流程缺乏用户使用阶段软件迭代的规范定义，导致不少车企在实际运营过程中遇到较大的困难，典型的问题有如下四个：

1、软件无整车级别的流程管控，致使软件需求阶段、开发阶段、验证测试阶段、发布阶段均运营无序。例如各控制器版本发布日期、产线断点日期无法统一，不仅整车功能集成和兼容性测试的严谨性受到挑战，断点时间不同导致的下线车辆版本不一致会使车辆版本碎片化严重，影响功能正常使用。

2、弱化下游业务（FOTA、线下诊断仪刷写、工厂刷写等）的运营效率。由于BOM中无整车软件之间版本依赖关联关系，使得在FOTA和线下刷写平台上软件配置、车辆识别等工作经常需要通过硬件配置关联，给升级任务配置带来了难度。

3、无法满足日趋严苛的汽车软件更新法规。国标草案《汽车软件升级通用技术要求》、WP29/UN R156等国内外法规条文均规定，升级管理体系建设应具备唯一的软件识别码，该识别码在每次升级完成后更新，标识准入或认证相关系统所有初始和更新版本的软件，并能识别软件版本的一致性。

4、由于缺乏整车功能层面和软件的关联关系，用户车辆版本碎片化严重，后续功能可售或订阅实现只能通过硬件绑定，增加了实现难度。笔者曾服务于一家传统车企的软件可售项目，核心问题在于单车的可售范围、功能的上下架管理。如没有相关系统的建设，极大影响商品的露出策略和部署实施。

三、解决方案

针对上述问题，车企进行着流程的优化和变革，加强整车生命周期内软件开发的协同管理，保证整车状态可控、计划有序，整车软件新版本可以及时分步实施。并期望通过系统的自动化管理，解决线下材料的繁琐和不稳定性。 传统车企的软件管理模式仍以控制器为颗粒度，一般由零件工程师提出发版需求，软件发布小组或工程支持部门人为控制管理发布流程。

在转型全新车型和电子架构的开发过程中容易导致运营混乱，例如A车型的TBOX在量产后有新版本需求，由零件工程师发起软件发布流程，整车功能测试通过后发起OTA流程。零件工程师根据断点时间线下提供车辆清单至OTA运营。如有其他控制器亦提出了发布需求，需由OTA运营决定是否加入本次任务。

而一旦有多个控制器加入，用户车辆的版本碎片化问题凸显，一般需要按车辆版本分组，或是通过多个OTA任务，才能实现用户车辆的同步。



图4 部分传统车企的OTA运营流程

对于没有历史包袱新势力车企，建立了初步的基线管理系统，并配套了相应的运营流程。基线管理是把整车的控制器软件版本按照一定周期划分基线。在节点到达时，根据当前释放的各控制器软件版本捏合成基线，并以基线发布为节点，整体管控整车各控制器软件版本的需求、开发、测试、发布阶段。

 

图5 整车基线示例

在基线的集成测试和兼容性测试通过后，锁定发布基线至下游系统，FOTA、售后诊断刷写系统获取基线数据，根据单车配置计算本次任务的软件包。 目前，国内也有相对成熟的方案，如艾拉比的VSP[3]，不仅为传统车企实现了整车基线管理，通过建设完整的软件运营流程和系统，将数据在研发设计、质量、销售、售后跨部门之间同步与共享。

更以功能为核心将场景功能基线对齐，为软件可售的运营管理提供基础支撑；串联车企内部的FOTA系统、售后质量及智能诊断系统，建立软件BOM和软件仓库，弥补PDM/BOM体系对于软件管理的不足；并打造软件升级SUMS体系并匹配国家监管，支持海外市场法规政策。

 

注释：

[3] VSP是一款艾拉比自主研发的面向软件定义汽车和新一代整车EE架构下的汽车软件协同管理平台，管理汽车ECU固件包、功能配置、整车基线、应用软件、诊断数据库、广告、主题皮肤等内容。可解决软件定义时代软件升级通道多需要同源管理、软件种类多需要统一的分层管理、车主触点丰富需要统一体验、汽车生命周期数字资产需要统一管理四大痛点。实现汽车软件内容从研发、试制、生产、售后的全生命周期管理。

四、总结

对于车企而言，基线管理流程的建立，解决了整车软件开发发布的问题，使汽车成为具有生命力的产品，有效解耦整车软硬件开发流程，实现了车辆全生命周期持续迭代。 未来整车功能的定义与实现必将通过软件驱动，为了支撑软件多样化开发与部署，真正达到软件定义汽车，基线管理的内容还将继续丰富和拓展。





审核编辑：刘清