民用客机机载软件构型管理活动的方案研究.docxVIP

民用客机机载软件构型管理活动方案研究 　　随着航空电子技术的发展与应用，现代民用客机大量采用高新技术，自动化和数字化程度越来越高，计算机软件的使用越来越广泛，通过软件实现的功能也随着翻番，软件功能、结构和数据愈加复杂。由于机载软件涉及的承办单位比较多，涉及的系统多而复杂，而且系统之间还存在着交联关系，对机载软件的管理提出了越来越高的要求，传统的机载软件管理模式已远远不能满足现代民用客机对软件状态控制的需要，必须采取基于全生命周期的系统管理方法―构型管理。　　机载软件的构型管理活动包括机载软件的构型标识、构型控制、构型审核和构型记实等活动[1]。本文依据RTCA/DO-178B、ANSI/EIA-649B要求及型号工程经验简要阐述了在“主制造商-供应商”模式下有关机载软件构型管理活动方案。　　一、构型标识　　构型项标识　　构型项标识就是为每一个构型项分配唯一的标识，以便为构型项的控制和参考确定一个基准。机载软件应标识出以下构型项：　　a） 飞机级的文件，如SCMP和SQAP、系统规范、接口控制文件、软件兼容性矩阵和飞机构型矩阵；　　b） 供应商文件，如需求文件、设计描述文档、软件构型索引和软件完结综述；　　c） 计算机软件构型项，包括源代码和可执行目标码。　　文件都应有唯一标识号。每份文件的修订也应有唯一标识。一旦一份文件已经发布了，之后发布的任何文件的更改都应有一个不同的版本号。CSCI应具有唯一件号。每个CSCI应具备一个唯一的版本标识。每一次新版本的CSCI发布将修改版本标识。软件构型索引SCI应指定与发布软件相兼容的硬件。SCI应同时标识出硬件设备件号和版本、软件构型项的件号和版本。　　基线　　基线就是在某一时间点上确定和建立产品属性的一致信息，它被作为定义更改的基础。在机载软件构型管理活动中，基线定义应包括飞机上所有软件数据项和它们的版本。一旦定义了一条基线，就要保证此基线内的构型项都不能被更改。如果需要更新一条基线，则要定义并更新需要更改的构型项版本并定义新的基线。通过基线管理确保机载软件的设计状态能够在下一个里程碑处得到弥补和修正，达到阶段性设计要求，最终达到产品的设计目标。　　二、构型控制　　问题报告机制　　在机载软件构型管理活动中问题报告机制就是记录不符合软件计划和标准的过程、记录软件生命周期过程输出的缺陷、记录软件产品的异常状态并确保这些问题的解决。主制造商的软件问题报告机制应归入主制造商的飞机级问题报告机制。供应商内部产生的问题报告应依据他们的软件构型管理计划进行。　　主制造商需要按照开口问题报告评估要求对主制造商内部、系统开发商或者任意次级供应商的问题报告流程、分类机制以及所有申请延期的问题报告进行评估。主制造商可以要求系统开发商或子供应商提供更多信息来说明延期问题报告的可接受性和合理性，主机厂经过评估后可能会拒绝供应商申请延期的问题报告。TC前，主制造商需接受局方对任何层级问题报告机制进行审查，并在TC前与局方就延期问题报告达成一致。　　如果飞机/系统使用了先前开发软件并存在开口问题报告，主制造商应重新评估其对该飞机/系统基线的潜在影响。　　与强制更改有关的开口问题报告，除非得到局方同意，否则不能够在TC时申请延期关闭。　　更改控制　　更改控制在机载软件构型管理活动中就是在软件生命周期内为更改提供记录、评估、处理和批准等保证。机载软件更改控制活动应纳入飞机级的项目构型控制活动中。由于各机载软件供应商合同约定的交付情况以及供应商的知识产权保护要求不同，存在部分供应商编制的机载软件构型项不交付给主制造商的情况，因此，机载软件构型项的更改控制要求也存在区别，具体的执行要求如下图1所示：　　a） 对于纳入主制造商飞机构型基线的机载软件构型项，按主制造商飞机级的项目构型控制要求执行更改控制；　　b） 对于纳入供应商构型基线的机载软件构型项，按机载软件供应商提交给主制造商批准发布的软件构型管理计划要求执行更改控制。　　软件加载控制　　软件加载控制在机载软件构型管理活动中就是采用合适的安保措施保证可执行目标代码被加载到机载系统或设备中。对于非现场可加载软件，软件在设备交付前就已经加载好了，且无法现场更改，软件加载控制的责任在设备的制造商；对于正式交付主制造商的现场可加载软件，其软件构型索引应包含软件加载过程和确认软件加载完整性的操作指南或单独的文件描述软件加载和确认过程，其一般控制流程如下图2所示。　　供应商控制　　主制造商在?C载软件构型管理活动中对供应商的控制原则应考虑以下几个方面：　　a） 供应商根据RTCA/DO-178B中构型管理活动要求以及主制造商的构型管理原则与要求编制软件构型管理计划SCMP并提交主制造商批准；