一种无人机飞行控制软件自动测试方法

刘玉军，赵创新，王振华，刘国强，彭 怡

(航空工业成都飞机工业(集团)有限责任公司，成都 610000)

0 引言

近年来，软件成为航空装备的大脑和灵魂，机载软件信息化程度越来越高，需要完成大量数据采集、处理和信息融合，其复杂程度高，具有较强的实时性[1-2]，其质量不容有失，对软件测试的要求也在不断提高[3-5]。机载软件的规模、复杂程度呈增长趋势。装备训练贴近实战，机载软件质量缺陷不断暴露，软件的功能和性能需要持续优化，软件的变更和维护升级极为频繁[6]。

机载飞行控制管理系统为嵌入式系统，由飞控计算机和飞行控制管理软件(简称飞行控制软件)组成，飞行控制软件运行在飞控计算机中，实现对无人机的飞行控制、模式控制、应急处置、余度管理等功能。在传统的研制模式中，飞行控制管理系统的研制首先要进行系统设计，系统设计完成后，硬件团队开始进行硬件设计和调试样机的生产。软件团队要在硬件团队提交硬件设备后才能进行开发和测试。这种开发方式存在以下问题：1)研制周期较长，软件设计要等待硬件的选购、布线、制版、加工、调试，需要大量的时间，软件的开发人员和测试人员无法及时参与其中；2)由于进度、环境等原因，多配置项的系统集成和联试只能在主机联试时开展，同时不具备增量的、自动测试能力，导致软件无法响应需求的快速变更；3)机载硬件成本较高，在全实物系统的测试环境和半实物系统的测试环境中很多系统故障无法构造，如测试飞控计算机存储器故障下，飞行控制软件对数据的处理等。由测试环境导致的测试用例无法执行的数量越多，软件测试验证就越不充分，后期的无人机飞行就存在质量风险；4)软件的测试自动程度低，测试环境构建周期长、成本高[7]。

在测试用例的设计和执行方面，飞行控制管理软件的测试用例数量多、执行周期长，如何既能控制测试数据的数量，又可以满足语句覆盖率、分支覆盖率、MC/DC覆盖率等覆盖率的要求，一直是困扰测试人员的难题。

针对以上问题，本文介绍了一种机载飞行控制软件自动测试方法，测试数据的生成采用自研AETG-SA算法，并加入了反馈机制，提升了测试覆盖率。在全数字仿真平台的基础上搭建测试环境，测试用例自动执行并记录测试结果，使飞行控制软件的快速原型验证和测试不再过度依赖硬件，大大缩减了系统研制周期，同时提升了系统的可靠性与安全性。

1 全数字仿真环境构建

1.1 全数字仿真环境介绍

全数字仿真环境采用分布式网络架构和模块化设计，可以在通用平台(如Windows)模拟真实的嵌入式硬件，包括芯片和外围器件[8]。嵌入式软件可运行在虚拟目标机上，实现软件设计的各项功能。全数字仿真环境可以对所有CPU寄存器、片上器件、内存的状态进行显示和修改，支持ARM、DSP、PowerPC、龙芯、飞腾等[9]，具备单步、断点、变量监视等常用调试功能，系统的状态可以保存和恢复，提供外围设备控制器仿真库，具备可扩展能力[10]，支持各种仿真模型的扩展开发和接入，提供多种API接口。基于全数字仿真环境可以实现嵌入式系统的快速原型研制，系统故障注入，处理器被执行代码单元级测试等多项仿真、软件验证和测试功能。全数字仿真环境架构如图1所示。

图1 全数字仿真环境架构图

1.2 全数字仿真环境的关键技术

1)基于AADL的系统架构建模技术：AADL(架构分析设计语言)描述嵌入式实时系统的软件体系结构和执行平台体系结构的语言。AADL为嵌入式实时系统(如航空电子等系统)的体系结构建模提供标准而精确的方法，可以对系统属性进行分析，并支持实现系统集成[11-12]。

2)基于DML的虚拟硬件建模技术：硬件虚拟化技术通过硬件模型和虚拟机两部分实现嵌入式软件的虚拟运行环境。DML(设备建模语言)提供一整套虚拟硬件模型构建接口和方法，实现嵌入式软件运行所依赖的硬件环境虚拟化。

3)基于DDS的网络通信技术：DDS(数据订阅/分发服务)是按照数据订阅分发服务标准实现数据订阅分发服务网络中间件DDS构建以数据为中心的数据订阅/分发网络，广泛应用于未来机载航电通信网络[13-14]，实现数据的稳定、高效、透明传输。

4)动态二进制翻译技术(Dynamic Binary Translation)：二进制翻译技术是一种即时编译技术，指的是从一种指令集翻译到另一指令集的技术。动态二进制翻译技术采用边运行边翻译的方式，将源机器码翻译成目标机器代码[15-16]它将源体系结构的二进制机器指令动态编译为可在目标体系结构上运行的代码[17]。全数字仿真环境中的底层翻译控制模块根据源机器码解码、翻译、优化编码，并将输出的机器代码送到执行模块，执行源机器代码，仿真目标系统及外围器件。

1.3 飞行控制系统全数字仿真环境构建

全数字仿真环境可以通过界面图形拖拽方式快速组建。利用全数字仿真环境可以有效地提高嵌入式软件的自动程度[18]，具体构建步骤如下：

1)全数字仿真平台可以直接虚拟出目标系统CPU，按系统设计，首先选择CPU型号并进行配置，设置ROM和RAM的大小及其他参数。

2)搭建外设接口，将与飞行控制系统的外围接口如CAN、RS422等进行仿真，通过协同仿真时间同步保证系统运行时的时序一致。

3)搭建与飞行控制系统交联的设备或仿真软件，建立资源库，可快速建立复用场景。

1.4 飞行控制软件测试数据自动生成算法

机载软件对安全性、可靠性、稳定性的要求比普通软件严格得多。飞行控制软件的安全运行受很多因素的影响，软件测试人员对各个因素组合全部进行测试才能充分的发现软件问题，但这显然是不切实际的。因为测试用例的组合数量是非常巨大的，有些时候无法穷举并进行测试。根据航空无线电技术委员会发布的DO-178C标准，飞控软件的测试要达到MC/DC覆盖级别。有效的测试用例组合既可以最大限度地发现软件缺陷，又可以满足MC/DC覆盖率要求。

为提升测试效率，需要设计一种算法可以自动生成有效的测试数据，对被测软件进行测试。

解决测试用例自动生成的算法包含贪婪算法、随机方法、启发式搜索算法等[19]。在软件测试领域，郑燕妮等提出蚁群模拟退火算法约简测试用例[20]，仲晓敏等提出基于退火遗传算法的多路径测试用例生成[21]，傅博提出基于模拟退火遗传算法的软件测试数据自动生成[22]。以上算法都是软件测试用例的生成或约简，对飞行控制软件的适用性不强，且算法并未将生成的测试用例的执行结果进行反馈，从而动态调整算法参数，在软件测试过程中不能形成闭环。

以下对两种算法进行研究，并提出一种测试数据自动生成算法AETG-SA(Automated Expert Test Generator-Simulated Annealing)算法，既可以满足MC/DC覆盖率要求，又可以在测试过程中动态调整算法参数，从而获得最优测试集合。

贪婪算法是测试用例生成应用较为广泛的算法，其核心思想是使用局部最优解近似全局最优[23]，算法效率较高，生成速度快，但容易产生冗余，参数维度较高时不易产生理想的测试用例集。

一种贪婪算法AETG生成测试用例集合的基本框架如下：

输入:待测软件FMS参数及范围

输出:测试数据集合Ts

a) S=Generate(FMS) //根据参数范围生成目标集合;

b) 随机选择参数τ的一个取值P,使得P在S中出现的次数最多;

c) 生成一条测试数据τ[k]=Pk;

d)Pi(i≠k)选择Pi的某个值来扩展测试数据τ,最大限度地覆盖S中的组合;

e) 测试数据τ加入Ts;

f) 以相同的方法扩展Pi+1直至所有的参数取值完毕;

g) 返回Ts。

贪婪算法只能遍历有限范围内的测试用例，收敛速度慢，选择的测试用例也并不一定是最优的。

模拟退火算法(SA，simulated annealing)是基于Monte-Carlo迭代求解策略的一种寻优算法，由高温到低温，遍历搜索空间，搜索过程中使用到Metropolis准则[24]。若系统在温度T时达到热平衡，系统在指定状态的概率PT(S)为：

其中：ES为s状态下的能量，K为Boltzmann常系数，S是所有可能状态的集合，Metropolis准则给出新状态SN的接收准则为若E(SN)≤E(So)则新状态自动接受，若E(SN)>E(So)，新状态的接收概率取决于以下概率函数：

飞行控制软件参数多为实际意义的变量，主要以浮点数、整数为主，在逻辑判断时也会用到布尔类型[25]。根据飞行控制软件的数据特点，结合测试经验，若某条测试数据发现软件问题，相邻的测试数据也容易发生软件问题。此时，降低降温速率的值，生成更多相邻数据，尽可能找到引发软件问题的数据边界。在贪婪算法上引入模拟退火算法并进行进一步改进，设计一种测试用例自动生成的算法AETG-SA。AETG-SA将贪婪算法和模拟退火算法进行融合，融合的过程为：首先采用贪婪算法生成全部目标集合S和测试数据τo，在生成下一组数据τn时采用模拟退火算法，根据降温速率和当前数据获取下一组测试数据，再依据Metropolis准则判断是否接受新解τn，若接受则将τn纳入测试数据集合Ts，生成初步的测试数据集合Ts。测试进行的过程中根据测试数据是否发现软件缺陷动态调整模拟退火算法中的降温速率rate，形成最终的测试数据集合。

算法基本流程框架如下：

设软件模块累加的MC/DC覆盖率为能量E，集合S为初始温度，集合Ts为达到热平衡的温度，降温速率rate。

输入：待测软件参数及范围、降温速率rate、判断退出条件次数m，覆盖率差值

输出：测试数据集合Ts

a)InitTs,rate,m, //初始化;

b)S=Generate(FMS) //根据参数范围生成目标集合;

c)τo=random(S)//在S中随机生成一组测试数据;

d)τn=Get(τo,rate)//根据降温速率和当前数据获取下一组测试数据;

e) ifE(τn)>E(τo) ore-[E(τn)-E(τo)]/KT>random[0,1);//判断是否接收新解;

f)τn∈Ts//τn纳入测试集合Ts;

g) ErrorFlag=Test(τn) //执行测试数据;

h) if ErrorFlag=1 //测试发现软件缺陷;

i)rate=Lower(rate)//降低降温速率并更新;

j) repeata～j;//重复步骤a～j;

k) while(E(τn)-E(τo)<σorE(τn)==1)//连续m次满足终止条件;

l) returnTs。

2 飞行控制软件自动测试设计与实现

飞行器控制管理软件是飞行器的核心和大脑，随着无人机技术的快速发展，飞行器控制管理软件的设计越来越复杂，模块之间交联众多。传统的飞行控制软件进行配置项测试需要搭建全套的软硬件测试环境。即使与飞控系统交联的设备采用模拟软件代替，飞行控制软件的测试用例依赖于系统状态[26]，需要等待软件运行到特定情况下，观察输出是否正确。测试用例需要经过精心的组合，才可能减少测试的时间和模拟飞行的次数，往往一轮完整的配置项测试需要数个星期的时间，费时费力。

飞行控制软件自动测试的设计与实现过程如图2所示，分为以下几个步骤：

1)梳理功能需求及软件输入。将飞行控制软件的功能分为综检指令处理、遥控指令处理、应急处置管理、航线管理、控制模式管理、飞行控制管理共6大模块。将模块进一步分解为功能点，明确每一个功能点的输入、输出及前提条件，给每个功能点编号。

2)自动生成测试用例。根据每个功能点的输入、输出及参数范围，使用1.4节设计的AETG-SA算法自动生成测试用例，覆盖正常场景和异常场景，测试用例的输入符合飞行控制软件与交联软件的接口协议。

3)编写自动测试驱动代码。首先搭建自动测试框架。采用代码隔离的思想，自动测试代码和飞行控制软件虽然都运行在全数字仿真环境中，但测试代码与飞行控制软件代码工程独立，减少了代码插桩导致后期装机时的代码冗余和因插桩引起的软件问题。将测试用例数据导入到自动测试框架中，执行测试用例，获取软件的输出结果并断言。

4)导入全数字仿真环境。基于全数字仿真环境搭建飞行控制软件的配置项测试环境，配置芯片和外围器件的参数，将编译后的代码导入到全数字仿真环境中运行。

5)记录并存储测试用例执行结果。将全数字仿真环境中的测试用例执行结果进行统计分析，生成测试报告并导出至Excel文件中。

首轮测试结束后，回归测试可以重用首轮测试设计的测试用例并自动执行，测试环境可以复用首轮搭建的全数字仿真环境，仅将修改后的代码加载到测试环境中，大大提升了测试效率。

3 某型无人机飞行控制软件自动测试应用实践

某型无人机飞行控制软件运行在飞控计算机中，实现无人机全过程的飞行控制与飞行管理功能，通过RS422、CAN等多种接口与机载系统进行数据交换，实现飞行管理、飞行制导、飞行控制、应急处置、数据处理、余度管理等多种功能。飞行控制软件软件是无人机的控制核心，对无人机的飞行安全至关重要。由于软件的复杂程度较高，软件测试过程耗时较长，为提升测试效率，采用基于全数字仿真环境的自动测试方法。飞行器管理系统与交联设备的连接如图3所示。

对飞行控制软件进行功能分解，可以分解为多个功能点，测试用例即对多个功能点是否符合设计要求进行验证。以测试起飞滑跑时角速率内环的俯仰角保持控制功能为例，说明自动测试流程。角速率内环的俯仰角保持控制是无人机处于起飞滑跑、起飞拉起、着陆滑跑阶段对俯仰角进行控制的重要功能，测试过程中首先飞控软件判断无人机是否进入了起飞滑跑阶段，进入后生成俯仰角给定、俯仰角、俯仰角速率3个参数的测试数据，将测试数据引入，执行自动测试用例，计算升降舵偏度后判断测试是否通过，最后记录并存储测试结果。测试流程如图4所示。

图4 角速率内环俯仰角保持控制自动测试流程

自动测试伪代码如下：

Begin

SetModePitch_Hold_MODE

if FlightMode = Pitch_Hold_MODE

then

Generate Theta_Given,Theta,Theta_q

else

Report Set Pitch_Hold_MODEError

exit PitchHoldTest

Import Theta_Given,Theta,ThetaSpe

if abs() <0.1(误差范围)

Display(“PitchHoldTest Success”)

Store PitchHoldTest Result

else

Display(“PitchHoldTest Fail”)

Store PitchHoldTest Result

End

将某型无人机飞行控制软件的功能模块进行梳理，在全数字仿真环境中自动执行测试用例，并将测试结果存储到本地。该软件测试数据对比见表1。

表1 某型飞行控制软件测试数据对比

本次测试共搭建3种测试环境：全实物系统测试环境、半实物系统测试环境，全数字仿真测试环境。其中全实物系统测试环境和半实物系统测试环境采用的是传统的人工设计并执行测试用例，全数字仿真测试环境中采用的是1.4节中的AETG-SA算法自动生成测试用例并执行。全实物系统测试环境中所有的设备均为实装设备，包括飞控计算机、大气压力传感器、起落架、动力系统、舵机控制器、配电装置等，搭建全套的测试环境非常费时费力，需要的资源的投入较大。半实物系统测试环境中，飞控计算机为真实设备，其余与飞控计算机交联的设备均使用仿真软件模拟，测试环境如图5所示。

图5 飞行控制系统全数字仿真环境图

相较于全实物系统测试环境在资源占用和时间花费上都有节约。而全数字仿真测试环境的飞控计算机和交联的测试设备均在仿真平台上搭建，平台构建的底层技术采用了1.2节中基于AADL的系统架构建模技术、基于DML的虚拟硬件建模技术、基于DDS的网络通信技术、动态二进制翻译技术。编译完成的飞行控制软件的二进制代码才可以运行到全数字仿真平台上，模拟真实的目标机实现相应的功能，接口类型和数据逻辑与真实环境一致，可以满足软件功能和接口的测试需求。

此次飞行控制软件共设计动态测试用例545个，设计相同数量的测试用例545个，在全实物系统测试环境中，受系统硬件和环境的影响，如故障构造、传感器数据未在飞行状态下只能产生部分数据等，只能执行516个测试用例，29个测试用例未执行。如测试用例中设计的舵机控制器故障时，测试无人机飞控软件的故障处理，在全实物系统测试环境中，无法在不破坏硬件的情况下构造出此类故障，因此无法执行此测试用例。

半实物系统测试环境由于飞控计算机交联的设备采用仿真软件代替，增加了测试充分性，可执行530个用例，共15个用例未执行。半实物系统中虽然与飞控计算机交联的设备采用仿真设备代替，但飞控计算机本身的故障测试用例无法执行，如飞控计算机的存储器故障测试用例，一般测试为向飞控计算机存储器中写入测试数据以验证存储器工作是否正常，在半实物系统测试环境中无法执行。

全数字仿真测试环境由于不受系统硬件影响，以上举例的测试用例舵机控制器故障、飞控计算机存储器故障均可构造，设计的测试用例可全部执行，对软件的测试更充分，能更大程度地发现潜在的软件缺陷。

在测试耗时方面，全实物系统测试环境中人工执行516个测试用例，耗时68.8 h，半实物系统测试环境中人工执行530个测试用例耗时70.6 h，全数字仿真测试环境自动执行545个测试用例仅需0.3 h。

分析上述数据不难发现，在全数字仿真环境下，使用AETG-SA算法自动生成测试数据，结合自动测试框架自动执行测试用例，测试充分性提升5.3%。相较于半实物测试环境，全数字仿真环境测试手段执行充分性提升2.8%。合并首轮测试用例的设计时间和回归测试耗时，相较于在全实物系统中进行测试，自动测试耗时缩短44%，相较于半实物系统，自动测试耗时缩短45%，大大提升了测试效率。

4 结束语

本文针对机载飞行控制软件功能测试耗时长、对硬件依赖程度高、自动化程度低、测试数据设计覆盖率低等问题，提出了一种基于全数字仿真环境的机载飞行控制软件自动测试方法，并在工程实践中进行应用。相较于全实物系统测试环境和半实物系统测试环境，全数字仿真测试环境进行功能自动测试极大的缩短了测试耗时，同时具备快速重建能力，提升了测试效率。但目前来说，该测试方法适用于同一型号软件及迭代版本的测试，不同型号软件之间的通用性有待提升。后续逐步对该测试方法进行优化，提高复用性。