适航工程师指南系列：关于DO-178C中耦合分析的考虑

编者注：本文作者翱坤科技是一家航空工程综合服务机构。“适航思维”在此衷心感谢其无私的知识和经验分享。

1

概述

RTCA/DO-178C (Software Considerations in Airborne Systems and Equipment Certification) 提出了对机载软件结构的测试覆盖目标要求，其中包括数据耦合（DC）和控制耦合（CC）的测试覆盖，本文基于工程经验浅谈对耦合分析的理解和认识。

DO-178C表A-7中的目标8：对A、B和C级软件要求达到了软件结构（数据耦合和控制耦合）的测试覆盖（6.4.4.d），如下表所示：

DO-178C 6.4.4.2 c中活动包括通过分析确认基于需求的测试已经检查了代码部件之间数据耦合和控制耦合。

2

术语

DO-178C附录B给出了耦合分析相关术语的定义：

数据耦合：一个软件部件对不完全由其控制的数据的依赖。

控制耦合：一个软件部件影响另一个软件部件执行的方式或程度。

部件：执行系统的一个清晰功能的一个自包含的零部件，或者零部件、分组件、单元的组合。

3

耦合的测试覆盖目标解析

结构覆盖分析为基于需求的软件测试（RBT）活动提供了完整性的度量手段，如果满足结构覆盖准则，则软件测试的完整性是可接受的。

对不同研制等级的软件，“完整性”的要求是不一样的，研制等级越高，对完整性的要求也越高，例如，C级软件的结构覆盖分析只需要满足语句覆盖；B级需要满足语句覆盖和判定覆盖；A级在B级要求的基础上还增加了修正/判定覆盖（MC/DC）。

这些覆盖测量和分析活动可以确保执行的RBT满足了软件部件本身的结构覆盖要求，但部件之间的的交互和依赖关系的正确性并没有得到验证，所以增加数据耦合和控制耦合分析，以验证架构和集成的正确性，也就是说通过耦合分析表明软件部件以预期的方式相互影响，无非预期的方式导致计划外、异常或错误的行为。

耦合分析的本质是对软件集成测试的完整性进行评估，分析应当基于在集成环境中执行的RBT测试，确保软件部件交互和依赖关系正确，并满足软件需求和软件架构。

软件部件不是一个指代明确的名词，可以定义为函数、过程、可单独进行编译的文件或整个软件系统，因此需要在软件架构设计中对软件的组成及软件部件的指代进行明确描述。耦合分析针对软件部件之间的依赖关系，对于单个的部件内部并不需要进行耦合分析，所以对部件的颗粒度的定义是进行耦合分析的基础。

4

耦合分析工作开展步骤

为满足DC/CC的测试覆盖目标，需要软件研制单位在整个软件生命周期活动中对耦合相关的因素进行考虑，如下图所示。在开发过程中应尽早对耦合进行相关的考虑。

步骤1：在软件策划过程中，通过软件开发标准（SDS）和软件编码标准（SCS）定义相关设计和实现中对耦合的限制，可以较好地促进耦合分析实践， 例如：合理地进行模块划分，增加模块的内聚，降低模块间耦合，限制模块的扇入扇出数，简化软件架构，减少条件分支使用等。

步骤2：在软件开发过程中，应考虑数据流和控制流并描述出来，这是软件开发工作的一部分，明确定义软件部件间的接口，在软件架构中说明与数据或控制流相关的内容，包括数据结构、软件架构、内部和外部输入／输出、设计的数据流和控制流、调度过程和处理器内/任务内通信机制、分区方法，以及软件部件说明。

步骤3：对软件架构和代码的一致性进行评审和分析，记录耦合信息。

DO-178C表A-4目标9：确保软件架构是一致的，即包含确保软件架构中各部件的关系是正确的，这种关系存在于数据流和控制流中。如果较高等级软件部件与较低等级软件部件之间有接口，应确认软件有合适的保护机制避免来自较低软件等级的潜在错误输入。

DO-178C表A-5目标2：确保源代码符合软件架构，对于耦合覆盖即需评审确保软件源代码与软件架构中定义的数据流和控制流相匹配。

验证人员在软件需求、架构和代码中找到与数据流、控制流相关的信息和相关的追踪数据，对相关信息和追踪数据进行评审分析，确认相关数据是正确和完整的，发现其中的错误并提出PR进行更改。

步骤4: 执行基于需求的集成测试，软件集成测试旨在确保软件组件之间正确交互，满足软件需求和软件体系结构（DO-178C 6.4.3.b）。

集成测试的目的是识别以下类型的错误：

变量和常量的不正确的初始化

参数传递错误

数据破坏（特别是全局数据）

事件和操作的不正确顺序

不恰当的端到端数值解析。

在设计评审中，软件架构与需求之间的一致性已经过验证，因此基于需求的测试包含了对软件架构也实施了检查。

步骤5：对基于需求的测试进行分析，识别出耦合覆盖测试用例和程序并建立与开发数据之间的追踪关系，确认基于需求的测试检查了部件之间的DC/CC。

按照上述步骤3在架构、需求和代码评审中已识别出相关的耦合信息，通过分析找到耦合覆盖的对应的测试用例、程序和测试结果，确保耦合路径通过相应的测试程序的执行被正确覆盖。

步骤5的分析通常会对上述步骤2~4工作产生迭代。如果在设计时没有很好地定义接口和软件部件间的依赖关系，那么将难以通过基于需求的测试证明耦合覆盖的目标得到满足。

5

使用耦合分析工具

当软件规模和复杂度到一定程度时，对代码中的数据耦合和控制耦合路径进行分析的工作量会很大，而且容易出错，通常会考虑到借助工具进行分析。目前进行语句、判定和MC/DC结构覆盖分析的工具已在业界普遍使用，但进行耦合分析的工具的使用还不是那么普及。在选择通过工具进行或辅助进行耦合分析时，一方面需要考虑工具是否需要鉴定，另外还需要考虑工具是否满足耦合分析的目标需求：

正确识别代码中的数据耦合和控制耦合路径；

正确识别出基于需求的测试执行对耦合路径的覆盖；

工具的执行环境满足要求。

6

总结

DO-178C将数据耦合/控制耦合的测试覆盖率归类到表A-7目标8，属于验证的验证，目的是确保基于需求的测试（RBT）覆盖了代码部件之间数据耦合和控制耦合，为集成测试的完整性提供度量指标。耦合分析工作还涉及DO-178C的表A-4目标9和表A-5目标2，对软件架构和代码的一致性进行评审和分析是为了确保软件架构的正确性、代码准确实现了架构设计的控制流和数据流，如果在架构设计和代码评审时没有考虑到数据耦合和控制耦合相关信息，在测试阶段实现耦合覆盖目标是非常有挑战性的，甚至造成返工。因此耦合分析工作的顺利开展离不开设计和验证人员的共同参与。

笔者注：本文参考了DO-178C、CAST-19，总结公司多位实际参与C919研发同仁的经验编制，旨在分享一些工程经验与观点，在审定中有关耦合分析的具体实施要求，申请人应充分与局方审查员沟通联络。