一种适用于功能安全和ASPICE流程实施的配置管理策略

随着汽车电子化的快速发展，软件在整车中的重要性越来越凸显。目前，行业内主要遵循两个国际标准进行产品开发以保证产品的质量和安全，一是ASPICE（汽车软件过程改进及能力评定），二是汽车功能安全标准ISO 26262。这两个标准中都包含了配置管理方面的内容，明确要求在产品开发过程中，对工作产品进行严格的配置管理。本文将介绍一种适用于功能安全和ASPICE流程实施的配置管理策略，重点从配置项识别、基线策略和分支策略3个方面进行解读。

配置管理（Configuration Management，CM）是通过技术或行政手段对产品及其开发过程和生命周期进行控制、规范的一系列措施。配置管理的目标是记录产品的演化过程，确保在各个生命周期阶段都能得到精确的产品配置，配置管理策略中最重要的三项是配置项识别、基线策略、分支策略。

对于哪些属于配置项，ASPICE中SUP.8给出了一些描述。首先BP1，需要在配置管理策略中定义配置项准则，以说明“什么”应该属于配置项；其次BP2，在实际项目中需要根据配置项准则来确定具体的配置项。配置控制通常应用于交付给客户的产品、指定的内部工作产品、获得的产品、工具和用于创建和描述工作产品的其他配置项。所以，通常的配置项类型有以下三类。

一是文档。包括计划文档、需求文档、设计文档、验证文档、各种报告等。

二是代码。包括组件、标定数据、配置参数等。

三是工具。包括设计工具、测试工具等。

而对于功能安全来说，关于配置项准则的定义从High Level层面是没有任何区别的，都是说明“什么”应该属于配置项，区别在于对于具体配置项的确定。

ASPICE的PAM本身不包含硬件阶段，所以评估时并没有对硬件方面的配置管理有“过多”的要求。但功能安全不同，硬件方面的配置项是需要完整识别并详细记录的。此外，在实践中往往比较容易遗漏的是功能安全特有的一些工作产品，如安全分析产生的安全FMEA、安全FTA，以及DFA等工作产品。

从实践角度来说，比较推荐的方法是建立完整的配置项清单，普通项目的配置项加上功能安全特有的配置项，从而形成一个比较完整的配置项清单。然后，针对不同项目进行裁剪，挑选配置项，生成适合某个具体项目的配置项清单。

配置项主要需要配置项名称、文件类型（交付、内部、外部、供应商交付）、控制级别（存储控制、版本控制、基线控制）、存储位置、文件名称、作者、是否需要评审、批准人、基线、当前状态（draft、reviewed、released）等属性信息。

除此之外，还要注意一点，对于配置项的组织结构也需重视。需要按照一定的组织方式来结构化配置项，也就是可以利用不同的组来分类，比如分为计划类、支持类、系统开发类、硬件开发类、软件开发类、工具类。

那配置项的控制级别应该怎么确定呢？配置项的控制级别通常包括存储控制、版本控制、基线控制。

2.1 存储控制

对于一些记录、报告类型的文档可以采用存储控制方式，因为这类文档往往都是“一次性的”，发布后保存即可，不需要再进行内容更新，如周报、月报、会议记录等。

2.2 版本控制

工作产品需要有版本信息，当工作产品发生修改时，需要生成相应的新的版本，如测试报告等。

2.3 基线控制

经过正式评审和批准，与受影响方达成一致后冻结的工作产品或产品集合。建立基线后，这些工作产品将被冻结，作为下一个阶段进行的基础和输入。此后，如果工作产品需要进行修改，需要按照已定义的变更管理流程进行变更，如需求文档、设计文档以及源代码等。

基线时间是一种正式完成工作的状态，后续工作基于此状态，仅对其进行授权更改。打过基线的工作产品就意味着已经处于冻结状态，此后需要修改就需要走正式的变更流程。需要在配置管理策略中定义基线策略，基线策略包括基线类型和时机、基线命名规则、批准基线。

3.1 基线类型和时机

对于基线类型的划分方式不只一种。如果是一个包含系统、软件、硬件以及相关测试过程的完整项目，在不考虑功能安全的情况下，一般可以不将基线划分为计划基线、需求基线、设计基线、代码基线、发布基线。具体可分为客户需求基线（客户需求评审通过）、系统需求基线（系统需求评审通过）、系统架构设计基线（系统架构设计评审通过）、软件需求基线（软件需求评审通过）、软件架构设计基线（软件架构设计评审通过）、代码基线（软件详细设计、代码构建以及软件单元测试完成后）、软件发布基线（软件合格性测试完成后）、产品发布基线（系统合格性测试完成后）。

但是，如果是功能安全项目，上面的基线策略就需要调整和优化，这是为什么呢？

首先，根据功能安全要求，在需求分析阶段是需要将需求具体分配到某一个架构要素上的。例如：需要将系统需求分配到系统架构中的具体某个模块上面，这就意味着在系统需求分析阶段输出的工作产物并不是完整的，因为此时还没有最终确定系统架构，也就无法将系统需求完整并正确地分配到合适的模块上面。

此外，根据系统需求进行系统架构设计，然后通过对系统架构设计的评审以及相应的安全分析（安全FMEA、安全FTA、DFA）结果，可能会发现现有系统架构无法满足功能安全相关指标的要求，进而需要增加安全机制/措施，这样就会导致需要将安全机制/措施转化为系统需求，再对系统需求进行更新，然后再更新系统架构设计，进行安全分析进行验证，直到满足功能安全的相关指标。

由此可见，系统需求分析阶段和系统架构设计阶段是一个相互紧密关联的关系，也是一个迭代关系。如图1所示。

图1 系统需求分析和系统架构设计的迭代关系

那么面对这样一个紧密关联的迭代过程，单独对系统需求分析进行打基线就会导致频繁的变更。如图2所示。

图2 系统设计阶段的基线时机（1）

所以，应对这种情况，建议可以在系统需求分析、系统架构设计，以及相应的安全分析都做完并通过验证后，再统一打一个系统设计基线，这样更便于功能安全项目的顺利实施。那这样是否就意味着可以随意修改系统需求，对于系统需求没有任何的管控了呢？

事实是，可以对系统需求实施版本控制，每个版本的修改也需要进行评审并且和相关关系人达到共识，这样既可以保证系统需求的相对稳定，也可以减少频繁的变更。软件需求和软件架构设计同样如此。如图3所示。

图3 系统设计阶段的基线时机（2）

所以，如果是功能安全项目，那么建议的基线类型有客户需求基线、系统设计基线、软件设计基线、代码基线、软件发布基线、系统发布基线。

3.2 基线命名规则

统一基线命名定义规则，有助于基线管理。

3.3 批准基线

一般来说，需要定义满足什么条件，经由谁的批准，才可以建立基线。比如，系统需求分析、系统架构设计、安全分析（FMEA、FTA、DFA）通过了评审，并且通过了配置审计，由项目经理批准后方可建立系统设计基线。

一般建立基线的步骤如下。

（1）配置管理工程师按照基线计划时间或被通知建立基线的时间，获取相应的工作产物。

（2）配置管理工程师进行CSA和配置审计。

（3）项目经理批准基线。

（4）配置管理工程师建立基线并发布通知。

4.1 代码配置管理

对于代码的配置管理比较特殊，与文档或工具的配置管理有所不同。通常来说，会使用到分支以支持程序的开发。一个好的分支策略，可以提高软件的开发效率、集成效率、发布效率以及管理效率。同样需要在配置管理策略中定义分支策略，如图4所示。通常的分支类型如下（以Git为例）。

图4 分支策略

(1)   Feature（功能分支）：进行新功能/新特性开发的分支。

(2)   Develop（开发分支）：主开发分支。

(3)   Release（发布分支）：版发布分支。

(4)   Hotfix（修复分支）：Bug（缺陷）修复分支。

(5)   Master（主干）：最新版本基线分支。

4.2 流程描述

（1）针对下个版本或需要预研的每一个新功能/新特性都可以建立一个Feature分支，以确保这些新功能/新特性可以相对独立地进行开发，彼此不会相互干扰，也不会干扰到Develop分支的正常开发。等到需要在某个版本发布这些新功能/新特性时，再把对应的Feature分支Merge（合并）到Develop分支上进行集成。

（2）在Develop分支上进行主要开发，有新功能/新特性并入时进行集成，当需要发布版本时可拉出Release分支进行发布。（Develop分支永远都是最近的未发布版本。）

（3）在Release分支上进行集成和合格性测试，如发现缺陷可直接在此分支上进行修复。测试通过后，一是需将Release分支Merge回Develop分支以保证缺陷修复的同步有效性；二是需将Release分支Merge到Master分支进行正式发布。

（4）在Master分支上为每个最新的发布版本打基线（Tag）。

（5）当已正式发布的软件发现缺陷时，从Maser分支拉出一个Hotfix分支进行缺陷修复。修复完成并通过测试后，将Hotfix分支Merge到Master分支进行正式发布。同时将Hotfix分支Merge回Develop分支以保证缺陷修复的同步有效性。

以上的配置管理策略只是众多实践中的一种，不一定适合所有情况，每个团队对于配置管理策略的理解和定义也有所不同。但是，进行配置管理的目的都是一致的，就是要确保工作产物是处于有效控制下，以此保证产品的质量。

参考文献

［1］VDAQMC第13工作组/汽车行业SIG.AutomotiveSPICE：ProcessAssessmentModelVersion3.1[S].德国,2017:21,63.

［2］Road vehicles—Functional safety:ISO26262-2018[S].