讨论一个整车软件版本管理问题

一、问题来源  

故事要从主机厂的整车开发流程说起。目前国内各大主机厂基本沿用通用汽车的GVDP(Global Vehicle Development Process，整车开发流程)来定义自己的整车开发计划。GVDP作为汽车领域最广为人知的开发流程之一，贯穿了车型开发的整个生命周期。  

GVDP将整车开发归纳为五个阶段：架构阶段、战略阶段、概念阶段、开发阶段、产品及生产成熟阶段。而每个阶段又分别定义了相应的“里程碑”节点。“里程碑”意味着整车开发工作阶段性结束，同时意味着下一阶段的开始。“里程碑”往往也伴随着本阶段交付物的锁定及下阶段交付物的启动。

 


主机厂DRE（Design Release Engineer）们的零件开发工作会严格按照GVDP定义的阶段及节点按部就班完成。整车项目经理和VSE（Vehicle System Engineer）们同样以此制定工作计划，在相应的整车阀点收集并审核DRE们提供的交付物，包括但不局限于样件、设计文档、台架整车测试结果、最终的量产件。  

至于工程管理系统架构，主要由BOM（Bill of Material，物料清单）、PDM(Product Data Management，产品数据管理)等子系统构成。在这些子系统中，一般会以零件的LOU(Line of Usage)信息作为整车零件的管理颗粒度，零件的硬件和软件序号和信息在PDM中均挂在该零件总成下。DRE牵头零件工程更改的过程中，同样会以这个零件总成号和相应的LOU向整车项目组提交更改方案和费用。  

在新四化的热潮尚未开始前，该管理模式有序保证了整车的顺利开发和量产。对于涉及软件的控制器或执行器，一般硬件供应商同为软件供应商，功能范围相对稳定因而软件代码量较少，硬件和软件可按GVDP的节点要求统一测试和交付。在G3（预试生产）阀点前即可锁定零件的状态，在SOP（Start of Production，正式生产）后继续迭代的可能性较小。  

然而近几年软件定义汽车的热潮涌动，伴随着网联、智驾功能的蓬勃发展，软件的开发和迭代日益复杂，交付逐步与硬件分离。整车的一些域控制器，比如常见的ADAS，在实际的开发过程中，会由多家供应商和主机厂一起协同开发。   例如，硬件由A供应商提供，底层软件发包给B供应商，应用层软件定点至第三家供应商C。一些应用层的支持功能，例如FOTA，也会选择开发经验更丰富的供应商D，甚至于测试台架或者人力也会外包给供应商E协作完成。  

这样便会给控制器的开发和软件的集成和测试带来巨大的挑战，很多控制器无法在SOP前完成所有功能的开发和测试验收，不少功能和BUG需要在车辆下线后去迭代。这一软件版本发布的现状对原有的GVDP开发流程也带来了变化，流程中尚未定义对于控制器软件版本快速迭代的管理方案，也没有定义SOP后软件发版流程。  

对于当前整车分布式电子电气架构及过渡阶段的域架构，新开发的车型都将拥有几十个控制器，各供应商的能力参差不齐导致了开发周期大相径庭，各控制器断点时间的不一致导致了交付的整车版本碎片化严重，碎片化的整车版本严重不利于整车的功能测试和验证。  

二、解决方案  

为了解决上述问题，同时加强整车生命周期内软件开发的协同管理，保证整车状态可控、计划有序，整车软件新版本可以及时分步实施，不少主机厂尤其是新势力厂商都制定了整车基线管理。  

整车基线管理是把整车的控制器软件版本按照周期划分基线。在节点到达时，根据当前释放的各控制器软件版本捏合成基线，以此作为基准进行集成测试和兼容性测试。测试通过后，锁定并发布基线。  

基线管理流程可基于GVDP的流程，对于GVDP中定义的阀点，如EP、PPV、PP、P、SOP等，均可定义为整车基线节点，对网络诊断、整车功能的成熟度进行定义。随着整车SOP后的持续运营，基线计划可根据需求，根据FIP的持续迭代，定期更新发布。大致的运营流程如下图所示。    

车厂的基线小组需要在整车层面制定整车软件基线的需求、开发计划，并将计划输出给各控制器端，统一在某一节点交付当期基线的软件，并在测试验证通过后发布，通过OTA或者线下刷写的方式应用新版基线。  

三、遗留问题  

上文主要论述的是基线管理的需求来源和总体方案。随着OTA在各主机厂落地，极大改变了车辆软件迭代的方式。主机厂的整车基线管理势必与OTA的运营管理紧密相关，OTA的运营流程作为整车基线发布的下游，需要按着基线的节拍去实施。  

主机厂希望通过OTA迭代整车基线，并作为基线管理的主要手段。但对于目前尚不稳定的FOTA能力和流程的缺失，仍有如下问题待主机厂根据自己的实际情况解决：  

（1）对于多配置或者具有高低配零件的车型，整车基线的定义方式；  

（2）对于不具备FOTA能力或者FOTA失败风险较大的控制器，如何通过OTA+线下刷写的方式共同拉齐整车基线；  

（3）控制器售后换件或异常刷写导致整车基线异常的拉齐策略；  

（4）随着运营的深入，跨基线升级带来的开发和测试工作量。  

四、写在最后  

综上所述，对于OTA运营，随着整车基线管理的成熟，势必将由点到面，不再以控制器的颗粒度去运营，而将捏合成整车基线的控制器组，以整车功能的迭代计划作为基准，整体去迭代或者统一回滚，真正实现整车软件的生命周期管理。  

审核编辑：刘清