面向需求高动态变化的强适应性可信飞行软件设计方法

高 飞，黄万伟，杨 威，吴 润，方建平

（1. 北京航天自动控制研究所，北京，100854；2. 中国运载火箭技术研究院，北京，100076）

0 引 言

某项目高度融合科学与工程，以工程产品为基础探索科学边界为目标，要求工程产品需根据科学探索目标不同进行研制。不同于传统运载火箭、导弹武器围绕特定任务开展研制，产品研制周期长、目标统一，针对最终产品进行质量测试及鉴定等特点，该项目并行目标多、变化频率高，阶段间产品可继承性弱、阶段产品交付频率高等。

工程产品的质量对于科学探索目标的实现具有“0-1”式决定作用，要求“万无一失”。飞行控制软件是航天型号的核心产品，它的质量直接决定着航天飞行的成败。此类研制过程要求飞行软件需求随着每一次飞行试验探索验证目标的不同而发生较大的变化，导致在进行飞行控制软件设计时，新一次飞行试验用的软件对之前的软件继承性相对较少，需要根据探索目标的不同不断重新设计软件，在快速迭代交付的要求下，工作量大且存在质量风险。因此，在有限的时间资源条件下确保软件能够快速适应新需求、确保软件的可信性、最大程度继承前序研制工作的成果就成了影响此类航天项目目标是否能够顺利达成的关键问题。

针对这样的研制特点，从技术角度出发，对传统型号飞行控制软件的设计方法进行了比较，并从中归纳出最小化功能加接口的抽象子集模型，从而在此基础上对传统飞行控制软件设计思路进行重新整合定义，形成一套面向高动态需求变化的强适应高扩展性飞行控制软件架构策略，让飞行控制软件的架构更加适应后续类似的需求高动态变化、阶段产品可信可交付等极限开发的要求。

1 传统飞行软件设计

传统航天领域飞行控制软件研制以瀑布模型为基础，通过定义软件需求明确了全软件生命周期中的统一功能目标，分解该功能目标后，针对每一个需求子目标设计模块或实体对象，然后对所有模块集合或对象集合进行组装，形成在特定环境中可以正常运行的软件。随后通过独立测试，保证软件正确实现了需求定义的所有功能点，满足规定的性能要求，并具有一定的可靠性和安全性。

李兰兰等提出一种基于构件的运载器控制系统飞行软件设计方法，其从加大重用率的角度将常用的功能点定义为功能构件，通过对功能构件的重用来提高飞行控制软件的研制效率。但该方法假设部分功能点保持不变，无法适应功能发生变化的设计要求。薛恩对飞行软件复杂性进行了分析，并从降低复杂性的角度论述了采用瀑布模型和敏捷开发各自优点，同时指出，瀑布模型在需求改变时较难修改设计以适应变化，而敏捷开发又会在每次迭代引入新的限制，排除一些未来功能或增加和引入新的复杂度。宋征宇提出了双CPU 环境下飞行控制软件的设计方法，从可靠性提升的角度提出了如何利用双CPU 克服在飞行过程中出现CPU 出错、程序跑飞以及数据出错等问题，并补充提出了此类飞行控制软件的可靠性设计方法。马卫华讨论了飞行控制软件可靠性设计的通用原则。贺彦博等从通用化的角度讨论了飞行软件的框架设计。

这些飞控软件设计方法大部分是直接从需求出发，以需求功能点为设计焦点，对每个功能进行封装，并通过对封装接口的设计来兼容需求功能点的变化。但此类设计方法的兼容能力仅局限在具体细节特征上，如时序处理的时间和类型、判据阈值的选择、硬件端口的适配等。通过前期设计可以将这些易变的细节定义为接口参数，从而通过对接口参数的调整，兼容这些变化，但对于功能需求的高频大幅变化的问题还没有成熟通用的解决方案。

根据以科学探索为目的的航天工程的特点及其对飞行控制软件研制功能需求变化大、质量要求高、交付频率高的要求，从框架适应性，功能适应性，设计可信性的角度出发，根据需求的专业类型不同对需求进行切分分层设计，着眼于需求的可调整性、高适应性，接口的高适配性以及功能的可配置性，提出了功能数据对象化的理念，形成了一套面向高动态需求变化的强适应性高扩展性飞行控制软件设计方法。

与以往的设计方法不同，本文所提出的方法主要在分层解耦架构设计，并以控制逻辑数据化、控制流程配置化、功能模块独立化为设计思路来解决需求中的功能点的大幅度高频率变化。对于需求中功能点的变化，通过针对性在不同层次进行适应性更改，同时保持其他层稳定的方法，将变化的影响限制在最小范围，让软件中已有的实现和质量保证工作得到继承，大大提高了研发的效率。为了更好的获得层间独立性和功能点解耦的目标，本文在制导、姿控的封装，硬件接口定义方面做出了改进。可信性设计通过逐层设计与逐层验证相配合的方式确保软件的可信性，简化了软件可信性设计的过程，在设计过程中即确保了软件的质量，体现了“设计质量”在设计中实现的思想，从软件设计本身大大提高了在高速迭代下软件功能、质量的适应性，为可信性软件设计在航天领域的应用走出了探索性的一步。

2 分层抽象的软件结构

2.1 适应需求高动态变化的层次化架构

需求的变化通常分为4 个层次：算法变化、逻辑功能变化、硬件环境变化、系统交互环境变化。例如由飞行轨道和气动外形变化引起的制导算法的变化、由电气安全性变化引起的I/O 时序指令的变化、由芯片变更引起的硬件接口的变化以及由协同设备交互逻辑变化引起的系统输入输出需求发生变化。

为了应对需求变化，将从需求到产品的设计实现过程抽象为以理论模型、实现模型、产品模型、系统产品为阶段性产品的4 个渐进式研制子过程。理论模型是求解问题的基本算法理论在理想化条件下运行的实验模型，其定义了产品的理论可行性；实现模型是软件的基本功能在理想条件下运行的实验模型，其定义了产品的实现可行性；产品模型是软件在特定芯片环境下运行的实验模型，其定义了产品的工程可行性；系统产品即为最终达到交付质量标准的产品。

封装的思想源于面向对象领域，其最大的优点在于：保持模块与模块、对象与对象、层与层之间接口不变的条件下，模块内部、对象内部及层内部的实现方式发生变化后不影响集成后的功能。根据4 个渐进研制子阶段的定义，将飞行软件的模块封装为4 个层次，也对应需求的4 个渐进层次。当不同层次的需求变化时，将软件更改限制在对应的层次中，同时也缩小了变更的影响域，从而让变更更有针对性、影响域更可控。

传统的飞行控制软件主要负责的功能包括：导航设备敏感信息获取，导航计算，制导律计算，姿控指令计算，时序控制，自毁控制，转级转段等功能。通过分析传统飞行软件的实现方式并结合以科学探索为目标的航天型号特点，将飞行软件抽象为如图1 所示的抽象层次化模型。

图1 飞行软件抽象层次模型Fig. 1 Abstraction Hierarchy of Flight Software

为了能够灵活、快速适应不同专业、不同层次的需求变更，将需求按照运行层次，即下层为上层的运行环境，上层为下层的任务输入和运行对象，进行抽象化分类。在抽象层次化模型中，算法层对应制导、姿控和导航3 个专业的技术需求，综合控制层对应着电气综合专业的技术需求，硬件层对应着芯片及模块技术手册规范。接口封装层的部分功能实现了软件间通信数据帧的封装和解包功能。通过需求专业分类和层次化抽象结构的封装，就实现了各专业、各层次的需求可以进行独立更改，同时对其他专业需求实现部分影响最小化的要求。

根据以科学探索为目标的航天型号算法变化较大，芯片及硬件运行环境变化较小的特点，用接口封装层将上层的技术要求与底层的运行环境分离开来，从而获得了需求与硬件环境的独立性；将算法层与综合控制层分离开来，从而获得了软件逻辑架构和制导姿控算法的独立性；将导航计算、制导计算以及姿控计算分离开来，获得了导航、制导及姿控3 个专业功能的独立性。

2.2 制导功能的封装设计

由于导航计算和制导计算关系较为紧密，逻辑耦合度较高，因此，为了减少运行过程中的通信开销，将导航和制导两部分功能封装为1 个模块——制导模块。制导功能主要封装为惯性数据解算模块、导航计算模块、运动参数计算模块、制导率计算模块、转段控制计算模块。各模块接口如图2 所示。

图2 制导模块封装Fig. 2 Encapsulation of Guidance Module

其中惯性数据解算对应惯性敏感器件，若惯性敏感器件不发生变化，则该模块亦无须发生变化；导航计算通常会根据解算的惯性数据计算各个通用飞行坐标系下的位置、速度、姿态等基础参数，该模块属于基本理论范畴，当输入惯性器件增量接口保持不变时，本部分通常不会变化；运动参数计算模块对应于航天飞行器专用定义的一些坐标系参数计算、气动参数以及控制参数计算，该模块根据不同的控制需求计算不同的参数。因此该模块属于需求适应模块，在轨道、控制方式等发生变化后，该模块容易发生相应的变化；制导律计算用于计算制导指令，该部分会随制导控制方法的变化而变化；转段控制计算模块通常会根据飞行轨道的不同段所采用的不同控制方法而进行变化，通常计算结果为轨道上的分段点信息。这些模块整合后形成制导功能模块的封装包，输出制导指令作为姿控模块的输入部分。

2.3 姿控功能的封装设计

姿控模块根据制导输入的制导指令完成计算飞行器姿态控制设备动作指令的功能。该部分根据控制机构不同，根据输入处理的过程分为：偏差计算，控制段计算、控制指令计算、设备动作指令计算、执行机构输出限制几个模块。具体的流程如图3 所示。

图3 姿控模块封装Fig.3 Encapsulation of Attitude Control Module

其中偏差计算部分主要通过计算当前运动参数与制导指令之间的差异来供后续姿态控制指令计算模块使用。该模块通常对制导输入做一定的预处理，在飞行轨道不发生巨大变化的情况下，该模块不发生变化。控制段计算模块主要考虑姿态控制能够兼容的控制方法类别，通过该模块来进行切换，通常与不同的飞行方式相关。当飞行轨道确定后，姿控控制段计算模块通常不发生变化。执行机构指令计算模块将根据不同的姿态控制硬件设备的驱动和接口进行封装，仅仅根据硬件设备不同会有少许变化。

2.4 硬件接口封装式设计

硬件接口是和底层运行的芯片特征关系较为紧密，为了保证上层算法逻辑功能层的稳定性，在硬件层上面插入一层逻辑硬件层，从而向上屏蔽芯片、总线等硬件具体细节，维持上层的独立性。图4 说明了硬件逻辑层的设计状态。

图4 从软件设计层架构到软件实施层架构Fig.4 From Design Architecture to Implementation Architecture

其中，硬件描述层对芯片的细节进行描述，逻辑硬件层将其封装起来，将功能层与硬件层独立开来，并使功能层能够“看到”的硬件控制接口保持不变，从而就解放了功能层以上的部分，使其具有更大的设计独立性，与底层的硬件细节变化实现了完全解耦。

2.5 具有可信性的质量结构

对于以飞行理论探索为目的的航天工程设计飞行软件来说，快速迭代是一个显著的特点。在这种快速迭代的情况下，无法提供按照传统的软件开发设计流程完成工作所要求的时间，这给产品的质量保证提出了严峻的挑战。基于前述软件架构的层次化结构，可以容易确认更改的影响层范围，从而通过层次化增量测试的策略，将测试范围限定在测试层内，有效提升软件的可测试性以及测试的效率和效果。

根据从理论模型到实现模型，到产品模型和系统产品的设计层次，将可信性验证架构定义为算法层、功能匹配层、芯片层以及系统接口层，通过在不同层次针对性对软件进行可信性、可测试性设计，使软件在相应层次上达到可被验证的最小子集，从而分层实现对软件可信性的验证。

可信性层次化设计及验证结构如图5 所示。

图5 可信性层次化设计及验证结构Fig.5 Validation Hierarchy of Software Trustworthiness

算法层是一个仅包括导航、制导和姿控算法的模块子集，其对应的输入和输出仅为算法运算的结果。算法层可信性验证要求对算法相关模块进行高内聚，与功能层间定义清晰的接口，方便易于从产品模块中单独剥离出来，嵌入到以PC 机+VS 仿真其功能层接口的数学仿真验证环境中，从而针对算法来定义的输入输出来验证算法的有效性和适应性。输入输出可以直接定义存储到外部存储（如文件）中，用以将算法层的执行结果与各专业的理论结果进行对比。通过此层的验证，确保软件中的算法层具有可信级实现质量。在此层，所有算法运行的平台均为PC 机等于软件实际运行的目标环境独立的验证，因此其不涉及和硬件相关的任何接口及细节，聚焦了验证的范围，提高了验证的效率。

功能匹配层可信性是通过补充综合控制功能如通信控制、时序控制、逻辑控制、自毁管理等功能，让算法层的输出结果更接近产品的输出结果，让产品实现完成从理论模型到实现模型的转化。该层基于功能层和逻辑硬件层的范围，定义清晰的接口，从而便于“算法层+功能层”可以从软件产品中剥离出来，对软件产品中功能层及其以上的部分进行仿真验证。本层同样在虚拟验证环境中，如PC 机环境中，对逻辑硬件层进行等效，以逻辑硬件层的输出形式定义针对功能层的输入输出（如将算法层可信性验证所需的输入输出的变量集合形式变为时序逻辑定义、高层总线协议等形式），对实现模型的程序结果进行验证。在验证过程中，可以通过确认算法层输出的正确性对问题的范围进行确认，从而缩小验证的范围，提高验证的效率。

芯片层可信性则是将集成算法层后的功能层“放到”虚拟芯片中运行，来检查产品模型的实现有效性。该可信性验证要求逻辑硬件层与真实硬件层间接口清晰，能够将芯片层以上的部分从软件中剥离出来，嵌入到等效硬件环境和芯片的虚拟环境中进行验证。该层虚拟验证环境通过模拟硬件描述层的输出（如将功能匹配层可信性验证所需的时序逻辑定义、高层总线协议等形式的输入变为以硬件逻辑表示的I/O 变量形式、总线通信层协议等），来验证软件在芯片上的逻辑行为与预期的一致性，从而保证该层的可信性。在出现超预期偏差时，通过确认功能匹配层的输出正确性，缩小化问题定位的范围，提高验证效率。

系统接口层可信性则是将上述产品模型的软件变为软件产品，放入真实的硬件环境中进行验证。其主要针对软件实现的最下层——硬件描述层进行验证，确保软件在真实环境中的硬件接口匹配性、响应性能、与系统中其他软件的功能匹配性等进行验证。同样可以通过芯片层的输出正确性，来缩小定位问题的范围，从而提高软件的验证效率。

从上述各层次的实现过程可以看出，后一层只需在前一层的基础上通过增加新的验证层内容、代替前一层辅助部分就可以得到。因此，在设计的过程中，需要对上下两层的替换内容和增加内容进行设计即可逐层确认每层设计的可信性，最终实现飞行控制软件的可信性。

3 实施效果及应用前景分析

软件缺陷密度（千行代码缺陷率），是一个评价软件产品质量的重要指标。缺陷率越低，则软件研制质量越高。以软件第三方测评中统计的千行代码缺陷率为测量指标，可以对软件的研制质量及其在整个型号的多次交付过程中的变化趋势进行分析。

本文提出的飞行软件层次化架构在某项目中得到应用，在每次飞行方案的变化过程中，涉及软件代码更改量高达70%以上，其中包括了制导、姿控的算法变化，综合控制时序的变化等，图6 说明了软件在历次产品交付过程的缺陷密度的变化情况。从图6 中可以看出，在最初一次变更后交付后，本文所述的软件架构逐步成熟起来，从千行代码缺陷率4.64，下降至2.96 左右，相对于行业内典型型号，缺陷率下降非常明显。软件很好地适应了这些状态变化，保证了较高的质量。

图6 某实践项目软件缺陷率统计Fig.6 Defect Rate of Some Aerospace Software System

在软件质量要求不变的情况下，软件交付频率高，对软件开发人员的生产率要求较高。软件生产率指的是交付达到质量标准的软件产品代码行的效率。本文所述的结构化设计方法通过分层设计、分层影响分析以及分层实现和可信性验证保证，大大提升了软件人员的编码效率。图7 展示了本文架构在多轮高频次交付过程中生产率的变化情况。从图7 中可以看出，软件在最初几次交付后，软件的生产率很快有了明显的提升，甚至在软件规模增大的情况，生产率依然保持了较高水平。

图7 某实践项目软件研制效率统计Fig.7 Development Efficiency of Some Aerospace Software System

分层设计的理念也让软件具有更好的可重用性。型号中的其他软件如综合测试软件、各种等效器软件、仿真环境软件等，也可以直接移植重用对应层的程序。实现了一处验证，多处重用，从而提高了软件研制的效率。

随着中国后续具有重大技术革新意义的航天型号的研制工作的不断发展，对航天飞行、空天运输等新理论、新技术的探索需求日益增加。航天型号的不断增多，同型号不同衍生状态数量的快速增长要求飞行软件的研制过程具有更高的适应性。本文提出的方法基于软件设计的层次化对架构进行分层，将软件需求的变化限制在较小的范围内，从变更影响的范围内控制了软件的质量风险，有效继承了原有代码的质量成果，从而帮助软件生产者提升了高频交付的能力和有效有质的代码生产率。因此，本项目的实践成果具有较大的推广意义。

4 结束语

本文针对功能需求高动态变化、高频率交付的研制要求提出了一种层次化的飞控软件设计架构，其将飞控软件分为算法层、功能层、逻辑硬件层、硬件描述层，通过保持各层接口的稳定性，将各层功能解耦，使其能够应对对应各层的需求点变更。在验证方面，方便将各层程序剥离出来，采用更适合的验证环境对其进行独立验证，提高了验证效率。总体上新飞行软件可以最大程度继承原有软件的程序实现成果和质量工作成果，从而提高了产品交付效率。

本文提出的方法也可以用于传统航天型号的研制过程中，有效缩小软件更改的影响范围，提高软件的结构级重用效率，促进代码生产率和质量水平的提升。对其他诸如小型无人机等飞行器的飞行软件的设计与实现也具有很强可借鉴意义。