01 机载软件过程保证的目的和背景

民机机载软件研制过程一直是行业内公认的要求最为严苛、开发验证难度最大的软件开发实例之一。由于其高安全以及严格的政府监管特性，使得传统其他领域的软件开发人员往往难以适应。这里有必要分析和解释民用飞机机载软件体系下的语境和对过程的基本要求出发点。

1.1 机载软件的研制过程仅指从严密的系统需求定义到代码实现和集成的过程

由于飞机自身层次化的研发体系存在，以及民用飞机对功能安全的苛刻要求，民用飞机体系下软件研制活动实际上包括传统软件工程的需求收集和系统/产品级验证活动。民机工程中的软件验证过程起自经过确认，完整、准确、无二义性的系统需求。任何系统需求方面的错误和不完善则应退回到上级过程进行，任何软件设计过程中对系统需求的补充，则也不应由软件工程师决定其存在合理性。

产生这一现象的原因在于民机整体研制过程中，非常强调对需求和设计的确认、分析和安全性工作。而几乎所有的确认（确定功能和要求的合理性）以及安全性工作都必须充分结合使用条件和使用场景开展。大家可能还记得本系列第一篇中所描述的民用飞机安全性相关工作介绍。而民用飞机的设计，实际上并不是最求极致的正确，而是根据所能产生的安全影响提出相应的要求。在机载软件设计层次，实际上并不能充分理解其所提供的飞机级功能及其使用场景，因此民机研制者通常将软件定义为只需要按照要求的功能和性能实现软件代码，并确定可执行目标代码能够在预期的目标机环境下正确实现分配给他的功能即可。

1.2 民机机载软件过程及其适航评估关注的软件缺陷种类

在上述这种语境下，机载软件的缺陷很大程度上被理解为是由于人为错误。这种人为错误发生的诱因可能是人的认识水平、理解能力、劳累疲惫、利益考虑等诸多方面。这种诱因可能导致软件需求的问题、软件设计的问题、软件编码的问题、软件质量的问题。这些问题表现出来可能是软件与硬件的不兼容，软件不能满足用户的预期用途，软件在边界输入上不能正确响应，软件结构复杂带来的维护和扩展问题，软件能力不能满足负载和容量压力。这些问题可以列举很多，但归根结底，软件要么对输入没有进行正确的理解，要么技术方案出现了问题，要么自身的研发出现了问题。以上的这些软件缺陷或者错误在软件运行之后其发生的方式或者暴露的原因，不具有偶然性，一定是在满足一定的条件下才能够发生。这种软件的错误不像某些硬件失效那样，会表现为一定的中间状态，软件的错误不会介乎于好与不好之间的无法定性的状态。所以软件的错误在统计学上不呈现任何的规律。

鉴于软件错误的发生一定是满足一定的触发条件才能发生。因此，这种错误的存在可以得到人为的控制而减少。不像硬件的失效，硬件的失效并不因为人为的努力而不会发生，其更多的是一种物理或者化学现象，是一种自然科学上的必然现象。所以硬件的不能满足要求，是一种失效，而非错误。硬件失效则呈现统计规律，统计学上称之为失效概率。软件的错误和硬件的失效在机载系统上的处理截然不同。硬件的失效要求满足失效率的要求，对于可能造成单点失效的硬件，则必须设置相应的冗余、备份手段。软件错误的防范在机载领域则应用过程保证的方法。通过较少引入错误的机会，提高检出错误的能力，来规范软件的质量要求。

1.3 机载软件过程保证的基本出发点

过程保证以层次化方法为核心，通过划分软件的研发层次，以不同的视角和角色开发软件生命周期数据。软件的开发不能一蹴而就，必然是从系统视角到软件视角，软件视角是一种以审视软件轮廓和外部行为的黑盒角度。软件黑盒被进一步打开，软件模块及框架和逻辑被明确出来。当软件框架和框架内部子模块的行为被充分细化，此时才可走向编程语言及编译链接。简单来讲，是一种外部-内部-实现-可执行的层次化框架。这种层次化方法，避免编码人员的自由发挥，通过软件架构和低级需求的设计，表面软件代码行为与外部要求的不一致；这种层次化方法，通过设置软件高级需求，对软件的预期和利益人意见进行汇总和权衡，避免了软件实现与软件预期的不匹配。因此，机载软件为了保证软件本身与系统或设备需求的一致性，设置了目前呈现出来的研发层次。

1.4 设计的颗粒度、层次依据和界面原则

过程保证以界面原则作为特定层次颗粒度/模块化定义的依据。拿一个通常算账使用的简单计算器来举例讲，划分输入模块、处理模块、输出模块是一种颗粒度，划分机械键盘、防抖模块、计算模块、存储模块、电源模块、显示处理和液晶模块等也是一种颗粒度的定义方式。其实这种颗粒度的不同定位，就是一种何为内何为外的界面划分。对于软件高级需求来说这种界面可以按照不同的业务流程划分，也可以按照不同的任务系统进行划分，也可以按照面向外部交互角色进行划分。对于软件低级需求来讲，这种界面可以按照数据流向进行划分、可以按照更为细致的服务或者功能进行划分，可以按照业务步骤进行划分。这种界面决定了颗粒度的大小。界面原则可以保证需求、设计、代码各层次内部组合和解耦的合理性，也对该层次抽象程度的合理性进行定义。

过程保证以内外关联为界面原则的依赖性策划依据。内外关联的原则是将那些牢固的不易变化的界面关系明确为模块间的外部耦合关系，将那些内部可灵活处置的关系内化为内部耦合。外部耦合宜松，内部耦合宜紧。模块功能内聚，则不会失去聚焦，不会偏离模块的中心任务；模块间关联松散，则模块间的开发与维护都相对便捷，不会有过多顾虑。对于每个层次的内部需求/设计之间的关联关系，有不同的划分方法，正如同统一建模语（Unified Modeling Language，UML）将类间关系划分为关联、泛化、聚合和组合一般，依据这种关联原则的定义，将上下游、同层间的需求设计关系进行梳理和净化，进一步将需求和设计的形式与内容进行雕琢。

02 机载软件的开发过程

在软件开发过程中，DO-178C定义了如下四个子过程：

（1）软件需求过程：该过程的输入是分配给软件的系统需求，主要输出是软件系统的高级需求（HLR）。它包含了软件的功能需求、性能需求、软硬件接口和安全相关需求等内容。

（2）软件设计过程：该过程的输入是软件高级需求、软件开发计划和软件设计标准，主要输出是设计描述，包括软件架构和低级需求（LLR）。

（3）软件编码过程：这一过程根据软件低级需求和软件架构编写软件的源代码。过程的主要输出结果是源码和目标码。

（4）软件集成过程：该过程对源码和目标码进行编译、链接，并加载到机载系统或设备中。该过程应包含软件集成和软/硬件集成两个子过程。

下图给出了DO-178C标准中系统需求和软件开发四个过程之间的关系。

图1 DO-178C开发过程

软件开发过程在DO-178C中分为四个阶段，这四个子阶段的划分要求保证软件行为的整体性、内在模块之间的协调性、内部耦合之间的正确性、内部异常与错误之间的隔离性、上级功能与下层资源分配之间的合理性和适当裕度，同时还要兼顾到软件的效率。这四个子阶段的划分可以从软件行为到结构，再到编程语言的转换，也可以是从软件能力到软件规格，再到软件实现的转换，也可以是去粗求精、去伪存真的不断迭代过程，还可以是更为复杂的从外在到多视角描述肢解系统需求的过程。但是不管怎样，这是一个从整体出发到各个部分，然后再到整体的一个开发过程。层次化的步进是为了顺利完成视角的转换。每个层次的切割和分配是功能聚焦和开发人员关注点聚焦的现实需要。在这个过程中，复杂度随着模块、组件、单元的降维，开发难度不断降低，但是软件整体的行为却变得越来越不受控。在软件开发不断的开发过程中，仍然有一种总体的行为变得尤为重要，仍有一个角色在以总体的责任性视角审视各个实体的综合行为。所以在这四个子阶段的实施过程中，要么前期规划非常明确，各个部分的定义在顶层需求中已经框定，要么在演进过程中，总是有一个全局考虑的机制在发挥作用。否则局面将变得不可收拾。

03 机载软件的综合过程

在软件综合过程中，DO-178C又包含如下四个过程：

（1）软件验证过程

该过程由软件验证计划定义，用于检测和报告在软件开发过程中可能引入的错误，而错误的消除属于软件开发过程的活动；

（2）软件构型管理过程

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

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

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

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

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

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

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

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

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

（3）软件质量保证过程

该过程由软件质量保证计划定义，用于审核软件的生命周期过程及其输出，确保其目标被实现，错误被检测、评估、跟踪和解决，以及保证其它软件生命周期数据能够满足软件需求。软件质量保证过程用于提供相关证据来表明经过软件生命周期生产的软件产品与需求相一致，保证这些过程的执行与软件计划和标准一致。

（4）审定联络过程

该过程用于在整个软件生命周期中建立应用程序与证明授权之间的通讯和理解，辅助软件的证明过程。

在机载软件开发过程中，软件综合过程与软件开发过程是并行执行的。在整个软件生命周期中，以软件开发过程为主线，在其各个子过程中实施相应的软件综合过程，其执行根据独立性要求等可由两个以上的不同团队来完成，实现软件开发与软件综合的分离。软件生命周期中各个过程的关系可用下图表示，图中软件计划过程是所有过程的起始点，根据软件计划过程制定的各种软件计划执行相应的软件生命周期活动。

图2 DO-178C软件生命周期方阵

综合过程也称之为整体过程，预示其长期性和伴生性。这种综合性还体现在其支持性，其是保证在日复一日的开发过程中的软件中间产品的质量特性、清晰的数据变化路径、过程和产品的监督监理。综合过程的设置不但适用于软件，对于其它层级甚至其它行业都是非常必要的，其是现代工业活动长期实施过程中的宝贵经验总结。

笔者在这里想到丰田的精益管理，其中蕴含的思路也对综合过程的设置给出了一些提示和指导。例如透明的信息与数字看板，软件项目研制中的构型管理和质量保证其实就为实现这一目的，提供了良好的手段。通过构型管理和质量保证，可以为管理层提供诊断、监控、管理的依据。管理层要实施有效的管理，总是离不开管控范围、问题定位、解决措施、效果统计等这些俗套的环节或者要素。软件综合过程的这些项目可以系统性的提供这种手段，如构型项的梳理、构型项状态的管控、问题报告机制和构型变更管理机制等，为项目的范围状态，人力时间资源的投入等提供决策依据。精而有益、由精益而形成良好循环，最终质变。

当然，软件适航本身坚持的更多是一种底线思维。如果软件研制企业想在人力、进度、成本上取得进一步的收益，还必须在流程优化、技术视野、管理与激励机制上做出更广阔层面上的革新。

参考资料：

[1]《机载软件适航符合性教程》，2022，ISBN：9787313241344，上海交通大学出版社.

[2] Software Considerations in Airborne Systems and Equipment Certification（DO-178C）,RTCA,2011.