MUNIK解读ISO26262：功能安全之配置管理

虽然各公司规模、体制及客户群体不同，对于配置管理的方式自然也不同，但是这并不意味着配置管理在项目管理中不重要。在涉及人员较多、跨职能部门、跨组织的项目中，一个清晰的配置管理方法和制度，能为项目管理、产品管理、公司运营提供非常大的助力。

这里首先需要明确的一个概念在于，什么是配置项？配置管理中的受控对象称为配置项，它们是在生命周期中创建的信息，包括程序、数据和文档，分为基线配置项和非基线配置项两类（基线与非基线定义会在后文中进行阐述），并不局限于功能安全体系开发所要求生成的工作成果。通俗来讲，配置管理就是对项目内配置项进行的管理活动。

配置管理主要目的是通过配置管理相关活动来建立并维护研发项目中的工作产品的完整性。配置项一旦发布就会受控，编写者本人也不会有权限去进行修改，同一版本的配置项是唯一存在的，当变更管理结束后，涉及修改的配置项需要重新发布才能归入配置管理，因此配置管理确保了所有配置项在任何时间都可以被唯一识别和重生成。通过配置管理，可以确保当前版本和较早版本的关系及区别是可追溯的。

配置管理流程大致可以分为准备计划阶段以及执行维护阶段。在配置管理活动之初，首先需要考虑参与配置管理员职责和权限的分配。由于不同公司存在不同规模的情况，选择的配置管理员这一角色也有不同，通常情况下，如果没有专职的配置管理员，会由开发或测试人员兼任。从职责上看，需要配置管理员来建立和维护配置管理计划，并根据配置管理计划执行各项管理活动。

配置管理员对配置管理工作有关人员和职责的设置以及不同配置库的访问权限进行详细说明。

组织在实际运作时，通常会采用相应的计算机资源和配置工具配合实现。

图1：常见配置管理工具

项目中成员的权限可通过配置管理工具来进行管理。可对不同成员的身份进行识别并分配相应的权限。例如在开发库中，开发人员具有入库及可读写的权限，配置管理员只负责监督，不负责入库，在受控库中，只有配置管理员有权限入库和出库，其他人为只读，产品库一般只有组织层级指定的人员有权限入库和出库。

基线是一组经过正式审查或测试并达成一致的规范或工作产品，作为下一阶段工作的基础。基线中的配置项被“冻结”了，不能再被任何人随意修改。对基线的变更必须遵循正式的变更控制程序。非基线的特点在于配置项的变动与否，不会影响后续环节的向下执行，或者最终的开发结果。在考虑到功能安全的情况下，需要在配置管理计划中定义基线管理，包括基线的类型、命名规则、版本等。

图2：系统设计阶段的基线时机

如上图示例，由于功能安全开发过程中，系统开发流程基于V模型概念，建议的基线类型可以有客户需求基线、系统设计基线、系统发布基线。

标识配置项的意义在于保存配置项的所有版本，避免发生版本丢失或混淆等现象，同时可以实现快速准确地查找配置项的任何版本。配置项的标识是功能安全生命周期中划分各类配置项，定义配置项的种类、隶属的基线和规划时间，并为配置项分配标识符的过程。建立完整的配置项清单需要普通项目的配置项加上功能安全特有的配置项（如安全分析产生的工作产品）。

研发项目一般会创建三个配置库，分别为：开发库、受控库和产品库。

三者的关联可参考下图：

图3：开发库、受控库和产品库及三者的关联

配置项的更改主要包括标识和记录变更申请、分析和评价变更、批准或否决申请、实现，验证和发布已修改的配置项。当配置项发生变更时，需要配置管理员对此做好记录及管理每次变更的版本，作为追溯每次变更的重要依据。

配置审核的实施是为了确保项目配置管理的有效性，用以验证配置项的一致性和完整性。配置审核包括功能配置审核和物理配置审核，功能配置审核用以验证配置项的实际内容是否与其需求一致，物理配置审核用以审计配置项的物理存在是否与预期一致。

如果配置项通过审核，便可进入发布程序。例如某个设计工程师完成了一个IP的设计工作，按设计规范的要求完成了该IP的代码(工程文件，非文档)。他需要按命名规则来命名这个文件，并将文件放在开发库中。然后该设计工程师通过配置管理平台、邮件或者其它方式通知配置管理员该工作成果已经完成可以进行发布。配置管理员按照发布程序将这个文件移入受控库，并向会使用或需要知情的人员发出通知，说明该文件已经是可以使用的状态。

综上所述，配置管理在整个功能安全项目周期中的的重要性可见一斑。除此之外，更需要配置管理和变更管理进行良好的配合，这样我们在具体的项目执行中才会更加高效有序的进行，关于变更管理的相关内容，我们会在后续进行分享。

回到本文的源头文章“ISO26262标准解读”，请点击链接：ISO26262 Functional Safety of Automotive汽车功能安全服务