一種無人機飛行控制軟件自動測試方法

劉玉軍，趙創新，王振華，劉國強，彭 怡

(航空工業成都飛機工業(集團)有限責任公司，成都 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 結束語

本文針對機載飛行控制軟件功能測試耗時長、對硬件依賴程度高、自動化程度低、測試數據設計覆蓋率低等問題，提出了一種基于全數字仿真環境的機載飛行控制軟件自動測試方法，并在工程實踐中進行應用。相較于全實物系統測試環境和半實物系統測試環境，全數字仿真測試環境進行功能自動測試極大的縮短了測試耗時，同時具備快速重建能力，提升了測試效率。但目前來說，該測試方法適用于同一型號軟件及迭代版本的測試，不同型號軟件之間的通用性有待提升。后續逐步對該測試方法進行優化，提高復用性。