汽车零部件软件与样件产品交付方法

最近阅读了一本关于智能汽车的专业书籍《智能汽车电子与软件：开发方法、系统集成、流程体系与项目管理》。

作者在全球百强汽车企业的一级供应商和整车厂（OEM）中拥有10余年技术与管理实战经验，书中从技术和管理视角全面剖析智能汽车电子与软件领域。

内容涵盖行业背景、组织架构、项目管理、开发方法、系统集成、流程体系、团队构建、核心标准、工具链、行业痛点及未来展望，推荐给从事智能汽车开发和管理的专业人士学习和参考。

接下来，我将分享这本书中的一些重要知识，希望对大家有所帮助。

无论是生命周期管理还是项目裁剪，实际上都是抽象出来的框架体系。如果我们把话说得更直接一点，汽车软件开发或产品开发的核心目的是什么？

归根结底，就是向下游客户交付软件或已经刷写好软件的样件。

也就是说，最终目标是按时、按质、按量地交付软件或样件，而在不同的项目节点交付不同成熟度的软件或样件，实际上构成了项目组工作的主线。

这也是我们理解项目的另一种视角。

此外，从形式上看，汽车软件与纯软件领域的最大区别之一就是物理样件的存在。

在汽车软件开发中，我们几乎无法脱离物理样件或硬件来谈论软件开发。

1、软件交付的3个关注点

从狭义上理解软件交付动作，可能会觉得没有太多可讲的，就像把大象装进冰箱，分三步：复制、粘贴、提交就完成了。

但是，即便是从“测试完成到交付客户”这一狭义的交付阶段来看，仍然有一些值得思考的关键点，尤其是在功能安全要求较高的软件中。

如果交付过程中出现问题，后果可能轻则影响整车功能，重则导致车毁人亡。

此外，软件与硬件或机械件的区别在于，硬件通常以具体可见的物理实体承载产品，而软件作为抽象的智力产品，不仅仅包括程序本身，相关的说明文档同样至关重要。

没有详细的文档说明，下一环节的工作无法顺利展开。

例如，对于迭代频繁的软件，如果没有明确的变更范围说明，下游的测试团队就无法进行有针对性的测试。

对于成熟体系的公司，不同成熟度和不同客户用途的软件交付过程，通常做了明确的定义。例如，用户产线装车或整车路试的软件必须完成哪些流程、测试、文档和评审等工作。

从更普适的交付思路来看，通常会关注以下三点：

1. 是否做对了：确保软件开发和测试的质量符合要求。
2. 是否交对了：确保交付的版本是正确的，符合客户需求。
3. 是否交全了：确保交付了完整的内容，包括程序、文档、测试报告等。

这些是软件交付过程中需要重点关注的三个核心问题，如图3-6所示。

1. 是否做对了

这一部分涉及对软件开发过程的整体把控，从需求分析、开发、编译、集成到测试的各个环节都要确保执行正确。

然而，是否“做对了”的最终判断并不是在交付环节做出的，而是在整个开发过程中判断的。

交付环节的作用更多是作为最终的把关，确保软件最终交付的版本符合预期和标准。

2. 是否交对了

最直观的检查就是版本是否正确，这与前期的软件分支管理、代码管理、集成管理等密切相关。

同时，还需要确认关键参数的正确性，例如，交付的软件中读取版本号或其他关键参数后，与需求方确认其是否正确。

当然，实际操作中，细心和谨慎也是不可忽视的因素。

3. 是否交全了

“全不全”由客户定义，不同客户的需求差异可能很大。

例如，有的客户仅需要一个可烧录的HEX文件，而有的客户则可能需要一整套测试报告、过程记录、OTA刷新包等。

通常，业内会使用SW Release Notes（版本说明）来汇总该版本软件的状态。

一个好的版本说明能够清晰展示软件的全貌，通常包括但不限于以下内容：

• 软件版本号：基础版本号，视开放程度可包括标定、底层、芯片、操作系统等版本信息。
• 软件用途：说明软件的应用领域和功能。
• 使用环境：如仿真环境、台架测试、路试车、产线等。
• 软件成熟度级别：根据软件的稳定性和开发阶段进行标注。
• 软件释放履历：记录软件的发布历史。
• 需求基线：与需求的对应关系。
• 变更点：相较上一版本的新增功能、修改的模块、修复的bug等。
• 测试汇总：包括测试范围、结果、问题等。
• 软件局限：如未解决的bug、已知的风险等。
• 匹配硬件信息：确保软件与硬件的兼容性。

总的来说，这三个关注点定义了交付过程中的“要做好的”范围。为了确保交付的质量和完整性，我们必须对这些环节进行严格把控。

2

样件交付成熟度的划分——ABCD样件

软件的交付除了直接交付软件版本外，还有一种方式是将软件刷写到硬件中，直接交付硬件。

这种方式是汽车电子软件行业中较为常见的黑盒交付模式，汽车行业通常将零部件样件视为商品进行交付，且其开发流程的主线往往围绕交付样件展开（量产交样内容不在此讨论）。

然而，随着软硬件解耦的程度不断提高以及OTA（远程升级）的普及，交付模式逐渐更多聚焦于软件交付。

在这里，我们将举一个样件成熟度划分的例子，涉及到机械和软硬件状态的描述，这有助于加深大家对项目流程的理解。

总体而言，研发样件的划分通常是根据其设计和验证的成熟度来定义的。

不同公司基于各自的开发流程和产品特点，可能会有不同的定义和习惯，同一公司不同人员在细节理解上也可能存在差异。

为了便于理解，这里我们给出一种常见的样件成熟度划分方式，即按照ABCD样件来划分成熟度，具体见下表。

1. A样件

A样件通常是非常早期且不成熟的产品。

其制作方式可能不规范，例如使用手工制作、3D打印、现有样件修改或其他样件代替等。

这类样件一般只用于非常基础的功能验证，如外观确认、结构匹配、包装开发、硬件在环（HIL）测试、台架测试或其他基本的工作原理确认等，不能用于耐久类环境测试。

A样件的软件开发可能未完成，或仅做了简单的基本功能和接口测试。

2. B样件

B样件的成熟度比A样件稍高，通常被视为过渡阶段。由于该阶段的定义相对模糊，很难与A样件划定清晰的界限。

B样件的制作方式、功能状态和测试完成度等关键部分通常已接近满足要求，但仍有一些非关键问题，如非配合尺寸不良、非正式产线出件等。

B样件可以用于车载测试或受限的路试验证。

此外，常说的DV（设计验证）阶段就是在这一阶段进行验证。

B样件的软件可能仍有部分非关键模块未开发完成，或者存在一些bug，标定可能还在调整阶段，但至少满足了可测试的条件，核心功能已经能正常运行，剩下的是工程化的打磨工作。

可以说，大多数开发阶段的模块处于B样件状态。

3. C样件

C样件代表了设计完成并验证合格的样件状态，所有功能需求已满足，硬件或机械件已经是正式模具或产线生产出的零件。

尽管如此，C样件还不能用于销售，因为此时只证明了可以通过非量产方式生产出单件或少量合格品。

对于软件开发团队而言，需求已经完成，所有子功能都已验证，即使仍然存在已知的bug（实际上没有完美无bug的软件），这些bug通常不影响核心功能，而且相关方已达成偏差许可。

开发工作基本完成，只剩下最后一步——客户确认（例如整车或产线确认）。

如果在这一阶段发现问题，可能需要迭代优化。简单来说，C样件的技术层面没有问题（包括产品和生产）。

4. D样件

尽管C样件在技术层面已无明显问题，但汽车行业强调程序“正义”和量产稳定性，因此引出了D样件的概念。

D样件是指经过小批量试生产（量产工艺）并获得必要认可（如PPAP）的样件，证明设计、工艺、组织及流程都已被认可，且组织具备批量生产合格产品的能力。

此时，软件也已完成全部确认工作，D样件标志着开发阶段的结束，进入量产供货阶段。