民机机载软件的配置管理

作者 | 蔡喁 上海控安可信软件创新研究院副院长

版块 | 鉴源论坛 · 观擎

社群 | 添加微信号“TICPShanghai”加入“上海控安51fusa安全社区”

01

配置管理的意义

配置管理（Configuration Management）在航空领域经常又称为构型管理，是现代复杂产品研制的核心技术。与很多传统观念中配置管理是对文档和版本的简单管理不同，现代复杂产品由于其内部组成部分较多、研制分工普遍以及设计中的版本状态以及配合关系频繁变换的原因，往往对配置/构型管控要求极高。

设计过程中的配置/构型管理往往需要解决三个方面的主要问题：

· 设计对象之间的关系

软件设计过程中的对象往往由多个程序文件、需求文档、架构文档、可执行目标码文件乃至测试用例和测试程序等组成。这些组成部分那些分离那些作为整体进行版本和更改控制，特别是在产品研制过程中、投入使用以后还需要能保证上述对象之间的关系正确管理首先需要对产品的内部设计对象的架构进行有效的设计。这种设计就是配置和构型管理的早期核心工作。

配置/构型管理架构设计的好坏，会影响到产品研制过程中的分工和过程控制。特别是航空类产品经常硬件成本高昂，配置/构型框架设计也会对产品后续持续升级和改进带来明显的影响。随着设计成熟度的提高，越来越多的机载系统和设备企业采用产品线方法对运用到不同型号中类似的产品进行配置/构型管理，在不同的设计对象中区分不同产品需要的功能和组成部分，从而组合成不同的产品而整个研制团队框架不用进行大的调整，这将是对配置/构型管理的终极挑战。

值得注意的是，配置/构型管理除了对产品设计数据进行管控以外，还需要对用于研制、测试乃至加载相关产品所需的外围工具和环境的构型进行管控。民用飞机领域强调生命周期数据管理与产品同寿，也是其中的原因之一。这就要求在所生产的飞机或机载系统全部退出使用以前，必须始终保持研制环境的可用，从而能够随时对产品中发现的问题进行分析和落实更改。

· 基线和更改控制

复杂产品设计中，由于涉及到大规模的团队协作，一般来说即使是按照双V模型或者瀑布模型也无法确保所有的需求和设计一次到位。因此根据不同研制阶段和不同成熟度的产品开展基线控制也就显得尤为重要。在成熟的基线管理工作中，所有并行开展的研发活动都以基线为出发点和中间落脚点，避免了不同设计对象的更改频繁造成其他设计对象的更改联动，也为团队整体控制研制节奏带来了便利。

复杂产品配置/构型管理中，更改的评估、落实以及回归等工作是配置/构型管理的核心之一。通常，更改控制流程中包含问题报告、更改评估、更改执行以及更改验证等多个不同的作业环节（ECR/ECN等）。考虑到产品设计的复杂性以及专业分工和协作，在民用飞机更改控制中，更改的评估和执行等环节，往往还会涉及到不同父更改和子更改的划分，通过不同专业的更改任务最终落实对某一问题的整体修正。

在软件等复杂产品设计中，更改往往是引入错误的原因之一。频繁无序的更改必将造成软件产品中错误百出。在面向商业化市场的产品研制中，更改往往由某一问题引发，并且需要对更改的方案结合更改的潜在影响开展深入的分析。这种分析一般必须依赖研制体系中需求-设计-代码-测试完整的追溯链开展，确保不会遗留所需评估的对象，保证更改不会造成非预期的影响。同时，通常配置/构型控制委员会（CCB）会对更改请求进行评估。考虑到时间、成本以及潜在的安全风险，并不是每一个更改请求都将会得到批准或者被要求立即实施。

· 配置/构型纪实

最后，产品研制以及使用和后续改进的任何阶段，研制团队需要能随时掌握和分析设计对象的状态和关系，这就带来的配置/构型纪实的要求。要求能够对任何阶段、任何组成范围的产品设计数据进行提取和分析，还要能对数据的更改历史进行严密的追踪。

图 1 配置/构型管理的三个维度

02

民机机载软件过程标准中

配置管理的要求

机载软件研制过程标准RTCA DO-178C第7章，详细描述了机载软件研制过程中配置/构型管理的活动、目标和相应生命周期数据。

该过程由软件构型管理计划定义，与其它软件生命周期过程协同执行，其主要功能包括：

· 用于在软件生命周期中提供确定的、可控的软件构型；

· 提供可执行目标代码的复制能力，当需要检查和修改时可快速复制；

· 在软件生命周期中提供过程输入/输出控制能力，保证过程活动的一致性和可重复性；

· 通过控制构型项、建立构型基础，提供用于走查、状态判断、修改控制的节点；

· 提供控制，保证所有问题都被处理，所有修改都被记录、提交和实现；

· 通过控制软件生命过程的输出提供软件的证明；

· 辅助判断软件产品与需求是否兼容；

· 保证构型项维护了加密、恢复和控制数据等；

其中，针对机载软件的构型管理活动，标准中明确定义软件构型管理活动包括：

· 构型标识（7.2.1）；

· 基线和追踪（7.2.2）；

· 问题报告跟踪和纠正（7.2.3）

· 更改控制（7.2.4）

· 更改评审（7.2.5）

· 更改状态纪实（7.2.6）

· 归档、检索和发布（7.2.7）

同时，秉承民机机载软件标准中，根据影响和风险来确定管控级别的思路，对更改控制分为了CC1和CC2两个级别。其中不同CC级别对构型管理活动的要求不同。CC1类管控要求实施上述所有构型管控活动，相比之下CC2类管控主要对数据的版本和基本更改进行管控。根据软件级别和具体的生命周期数据，DO-178C标准对其逐个进行了构型管控级别的要求定义。

图 2 DO-178C构型管控级别定义

图 3 DO-178C目标矩阵中对不同级别软件中不同生命周期数据的构型管控级别要求

03

支持其他研制环节的配置管理

软件配置/构型管理本身涉及到不同类型的数据特殊的管理方式。比如配置数据（在DO-178C中也称为参数化数据项PDI），其研制过程以及与系统其他部分软件的集成方式与应用软件差别交大，因此往往需要专门涉及配置/构型管理活动和要求。

实际上，软件的配置/构型管理只是飞机产品以及机载系统产品配置/构型中的一个组成部分。民机机载软件在飞机以及系统验证活动，生产制造活动中需要与不同的产品配置/构型管理进行衔接，因此会产生不同环节中配置管理的不同问题。

笔者始终认为，除去机载软件开发技术以外，考虑到项目的复杂性以及研制周期和成本的严苛要求。过程管控与配置/构型管控，是在民用飞机机载软件中的核心难点，也是今后一段时间国内机载系统和软件研制单位需要掌握和攻关的关键技术。

审核编辑 黄宇