编者按：
作为一名曾在主机厂干到过“九代长老”级别的DRE，对控制器的软硬件版本管理自有一套成熟的心法。这个项目用哪个零件总成号、零件总成号匹配哪个软件号和硬件号，都让我记录在时常找不到存放位置的Excel里。
当零件被对手件工程师怀疑有问题时，我总是第一时间检查车上软硬件版本否和我的Excel记录匹配上。当老状态车要集体升级到某一新状态时，我也会根据Excel的指引，发送相应的软件版本给相关工程师。当然，我也曾因一时眼花，下放了错误的软件版本给工厂，导致下线车辆集体趴窝的惨剧。在控制器软硬件版本管理这一领域，虽称不上经验丰富，但也算得上小有心得。
但这种平衡很快被新出现的一波项目管理工程师所打破，他们举着“整车基线管理”的大旗，疯狂质疑“九代长老”关于软硬件版本管理的心法。在与无中生有搅局者的一波波拉扯和斡旋中，我没有认同拥抱、也没有屈服认输，一直到我褪去“九代长老”的外衣。
但当读到作者的这篇文章，并通过这篇文章理解了整车基线管理的来龙去脉，我才醒悟何为一颗螺丝钉的目光狭隘、何为底层打工人的囚徒困境。
——不愿署名的编者
FOTA专栏已经更新了两期，前两期专注在技术细节的分享。第三期我们放松一下神经，讨论一个非技术问题。一个与FOTA运营过程紧密相关，一个着眼于汽车软件快速迭代带来的整车软件版本管理问题。故事要从主机厂的整车开发流程说起。目前国内各大主机厂基本沿用通用汽车的GVDP(Global Vehicle Development Process，整车开发流程)来定义自己的整车开发计划。GVDP作为汽车领域最广为人知的开发流程之一，贯穿了车型开发的整个生命周期。GVDP将整车开发归纳为五个阶段：架构阶段、战略阶段、概念阶段、开发阶段、产品及生产成熟阶段。而每个阶段又分别定义了相应的“里程碑”节点。“里程碑”意味着整车开发工作阶段性结束，同时意味着下一阶段的开始。“里程碑”往往也伴随着本阶段交付物的锁定及下阶段交付物的启动。
（图片来源：https://new.qq.com/rain/a/20211110a02ezl00）主机厂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运营，随着整车基线管理的成熟，势必将由点到面，不再以控制器的颗粒度去运营，而将捏合成整车基线的控制器组，以整车功能的迭代计划作为基准，整体去迭代或者统一回滚，真正实现整车软件的生命周期管理。
初心 | 记录生而为人的证据，分享工农阶层原创作品，聚焦智能网联与人情冷暖。声明 | 本文部分文字及图片资料取自网络，如有侵权，请联系平台进行修改或删除；文章属于作者本人，仅代表个人观点，不代表平台立场，如有不妥，也请联系平台修改或删除；本文不作任何商业用途。
