民用飞机机载软件研制过程中的安全性方法

陈刚，罗旭升

中国航空工业集团公司第一飞机设计研究院，陕西 西安 710089

0 引言

民用飞机的系统及软硬件设计过程通常要求严格的安全性工作，SAE ARP 4754A及SAE ARP 4761从系统研制过程入手，提出了安全性工作的要求，并给出了详细指南，但4761从PSSA分析工作给出软硬件研制保证等级之后就停止了进一步的向下延伸。给出的软硬件等级仅仅是软硬件应达到的总体的可靠性指标，如A级软硬件理论上应达到10-9的失效发生率[1]。而作为相对应的软件标准，RTCA DO-178C（或欧洲对等标准CM-SWCEH-002[2]）中并未明确说明软件研制过程中应执行的安全性活动，仅仅通过对不同等级软件实施不同的过程控制来满足其对应安全目标，似乎在提出软件安全性目标之后就再没有安全性相关的软件活动要求。

GJB/Z 102A[3]给出了一些软件安全性设计的基本原则，但其主要描述要求和原则，并未给出一般方法；另外，其研制过程与DO-178C中要求的机载软件研制过程不尽相同，不便于应用。

本文以民用飞机机载软件研制过程为基础，结合DO-178C中要求的各项评审、分析活动，提出了民用飞机机载软件满足软件安全性要求的简单方法，旨在不增加或少增加软件研制过程活动的基础上，明确软件研制过程中的安全性活动，满足日益提高的软件安全性相关要求。

1 软件需求分析过程中的安全性活动

1.1 软件高层安全性需求开发

DO-178C中要求标注安全性相关的软件需求，但并未明确说明如何获取相关需求。软件安全性需求的来源主要有以下几个方面[4]：①系统安全性需求的继承：由系统安全性需求分解而来的软件需求都应标识为软件安全性需求；②由初步危险分析（Preliminary Hazard Analysis）得来的软件安全性相关高层需求：若系统初步危险分析结果中，部分危险可由软件直接造成，则应编写相应的软件安全性需求，用于消除或限制该软件根源错误的产生；③后续过程反馈：由软件后续的设计、编码、集成等过程反馈后，根据反馈信息重新补充的软件安全性相关高层需求；④派生高层需求的安全性评估：按照DO-178C的要求，所有的派生需求应反馈给系统过程或安全性过程进行安全性影响评估，确认对安全性有影响的派生需求，应标注为软件安全性需求；⑤对A、B级软件，其关键功能（即所有影响软件等级分配的功能）应具备非相似的冗余设计，以避免因该功能的单一失效引起系统故障。

1.2 软件高层安全性需求的验证

DO-178C中有相关的需求验证目标，对于软件安全性需求同样适用。软件安全性需求验证的主要目标是为了确认是否所有的系统安全性需求都被精确地传递到软件并进行了足够的分解和补充，系统安全性需求和对应的软件安全性需求之间是否建立了追踪关系等。目前，民用飞机行业主要采用人工评审的方式验证软件安全性需求，主要评估准则为软件安全性需求的精确性、完整性（由某条系统需求分解得到的多个软件需求均被满足时，能否保证该系统需求的自然满足）、正确性、一致性（包括上下级需求之间的一致性和同级需求之间的一致性）、无二义性、追踪性及可测试性[5]。软件安全性需求的评审可与其他需求的评审一起进行，供应商应设计对应的需求检查单，对软件需求的评审准则进行固化。

另外，无论软件高层需求或软件低层需求或两者都采用了模型的方式进行了需求的表达，则也可以通过模型仿真的形式进行需求的验证，确认需求的逻辑正确性和一致性，时序、性能等方面则需在目标机上进行测试验证[6]。

2 软件架构设计中的安全性考虑

软件架构设计时，如果计划采用划分组件的方式来降低部分组件的软件研制保证等级。则应保证低等级的软件组件的行为不会造成高等级软件组件的行为异常，为此应制定相应的分区隔离策略及软件安全性需求，以确保分区隔离策略的有效性[7]。另外，尽管具体的组件划分可能会在软件架构设计过程进行，但由于分区可能涉及CPU、内存、总线和接口等硬件资源的划分或共享策略，需要在系统阶段就进行决策和资源隔离的考虑[8]。

3 软件设计过程中的安全性活动

3.1 软件低层安全性需求开发

与软件安全性需求开发类似，在软件设计过程中，除了编写软件低层需求外，还需要编写和识别软件的安全性低层需求，其主要来源如下：①软件高层安全性需求的继承：由软件高层安全性需求进行分解而来的需求都应标注为安全性相关需求；②由架构设计决策确定的安全性需求：由于软件架构设计中做出的设计决策所导致的影响软件安全性的需求，如分区隔离、与安全关键功能之间的接口关系等；③后续过程反馈：由软件后续编码、集成等过程反馈后，根据反馈信息重新补充的软件安全性相关低层需求；④派生低层需求的安全性评估：按照DO-178C的要求，所有的派生需求应反馈给系统过程或安全性过程进行安全性影响评估，确认对安全性有影响的派生需求，应标注为软件安全性需求。

3.2 软件低层安全性需求的验证

软件低层需求的验证目标包括精确性、一致性、与上级需求的追踪性、完整性、与目标硬件的兼容性、标准的符合性等。对于安全性需求来说，除了这些通用目标之外，在验证时更应额外关注以下项目：①安全关键功能与非安全关键功能之间的控制和数据依赖关系，判断非安全关键功能是否会对安全关键功能产生不利影响；②判断软件设计，尤其是软件安全关键功能的设计是否会造成系统限制的违例，如响应时间、内存占用等方面。

4 软件综合过程中的安全性活动

在DO-178C中，将软件验证过程、软件配置管理过程和软件质量保证过程这三个贯穿软件生命周期的过程统称为软件综合过程。

4.1 软件安全性测试分析

软件安全性测试分析对软件测试的结果进行分析，用以判断符合软件研制保证等级的测试强度是否已经达到。对于未达标的情况应进行补充测试，如补充后仍然无法满足的，应进行合理的解释说明[9]。同时，分析还应展示测试中出现的错误类型、数量及严重程度，必要时应在讨论后确定是否进行软件的修改和回归测试。民用飞机采用的软件安全性测试分析主要包括：①需求覆盖分析：用以确定是否所有的软件需求都进行了正确的测试，包括正常测试和鲁棒性测试，该分析适用于C级以上的机载软件；②耦合覆盖分析：用以确定软件不同组件间的数据耦合关系和控制耦合关系是否至少被测试过程执行过一次，该分析适用于C级以上的机载软件；③语句覆盖分析：用以确定软件代码的所有语句是否至少被测试过程执行过一次，该分析适用于C级以上的机载软件；④判定覆盖分析：用以确定软件代语句中包含的所有判定是否至少被测试过程执行过一次，该分析适用于B级以上的机载软件；⑤MCDC覆盖分析：用以确定为软件测试所编写的测试用例，是否符合MCDC准则的要求，该分析仅适用于A级机载软件。

4.2 安全性需求的持续测试

由于软件安全性需求的最终目的是支撑系统安全性目标的实现，因此，为了验证这些安全性目标或需求，应将测试继续向上延伸，确保系统级安全性测试结果的正确性。另外，由于系统设备及周边环境一般都在上级集成商处才能够获得，这就需要软件供应商与上级集成商或主机商之间进行测试协调，在系统联试、铁鸟试验或机上地面试验阶段进一步对软件安全性进行验证，同时在多家供应商联合测试时应确保软件质量保证过程及配置管理过程的连续性和有效性[10]。

4.3 软件安全性更改分析

软件配置管理过程要求对软件的更改进行控制，软件的更改影响分析属于软件更改控制流程中的一个环节，目的在于通过分析，确定软件更改的影响范围，以此决定所有受到影响的软件资料是否需要同时更改或采取其他合适的方案。软件安全性更改分析与正常的更改影响分析过程并无不同，只是需要更加关注对安全关键功能的影响。DO-178C在软件配置管理过程中已经提出了软件更改控制及影响分析的相关要求，因此，只需注意在软件更改控制委员会中加入软件或系统安全性相关人员，以执行相关影响分析即可。另外，软件质量保证人员应在更改控制流程中，对软件的更改进行跟踪和监督，以保证该流程的正确执行。

5 培训

对于有操作人员参与的系统来说，操作人员本身也应被考虑为系统的一个部件，因此，系统整体的安全性也与人员的合规和正确操作无法脱离。为保证操作的正确性，详细可靠的用户手册和操作人员培训计划必不可少。软件操作培训的准备工作应在软件研制过程中开始考虑，如软件人机界面设计的易用性考虑、防出错措施、可维护设计等。针对软件安全关键功能，在培训工作中应提供完整详尽的操作流程，并明确告知操作或维护人员系统中现存的可能风险。与培训相关的所有活动和安排应以书面形式在培训计划或软件安全性计划中明确。

6 结语

对于民用飞机机载软件来说，尽管RTCA DO-178C并没有明确提出安全性相关要求和目标，但实际上已经将大部分安全性活动融入了软件生命周期的各个环节，如软件需求的验证（已经包含了安全性需求的验证）、软件设计的验证、软件需求覆盖率分析、结构覆盖分析等。因此，如果使用DO-178C来满足主机商或其他应用标准（如GJB/Z 102A）中关于软件安全性的要求，仅需补充或细化部分活动。本文以此为出发点，以民用飞机机载软件研制过程为基础，提出了民用飞机机载软件满足软件安全性要求的简单方法，明确了软件研制过程中的安全性活动，满足了不同主机商对机载软件系统日益提高的安全性要求，同时也便于飞机软件适航符合性工作的进一步推广。