箭載飛控軟件系統最差情況執行時間測試研究

姚佳瑜

摘要：為了更加準確地完成嵌入式箭載計算機飛行控制軟件系統最差情況執行時間的自動化測試工作，根據軟件的高實時性特點，結合靜態分析和動態測量的優點，提出了基于RapiTime測試工具及應用RTBx硬件的測試解決方案，構建了嵌入式箭載計算機飛行控制軟件系統最差情況執行時間的測試過程，并將測試結果與其他方法進行比較，通過實驗驗證了所提方法的有效性，為提升軟件的性能及可靠性提供依據。

關鍵詞：嵌入式軟件測試；系統最差情況執行時間；軟件插樁；動態測試；基于測量的時間分析方法

中圖分類號：TP302 文獻標識碼：A 文章編號：1009-3044（2016）07-0087-03

Investigation on the Testing of Worst-Case Execution Time of the Rocket Flight-Control Software

YAO Jia-yu

（Shanghai Aerospace Electronic Technology Institute， Shanghai 201109， China）

Abstract： To accomplish the automatic test of the system's worst-case execution time， according to the real time performance of the flight control software based on embedded system， a test solution based on RapiTime testing tool and application RTBx hardware is proposed. The test procedure of the worst-case execution time of the software system for the flight control software system is constructed. The result provides the basis for improving the performance and reliability of the software.

Key words： testing of embedded system； worst-case execution time； software plug-in； dynamic testing； the analytical method based on measured execution time

嵌入式箭載計算機飛行控制軟件（以下簡稱飛行控制軟件）作為火箭控制系統中的核心組成部分，是一個復雜的軟件。由于其高實時性要求，就要求其在規定時間內（毫秒級）完成任務處理，要求系統嚴格按照一定的時序進行處理。這就要求對此軟件中關鍵模塊進行系統最差情況執行時間的測試。

1 飛行控制軟件系統最差情況執行時間測試的需求與困難

在實時系統中，確保系統執行時間的正確性是非常重要的。實時系統執行時間的要求相對于非實時系統來說有明顯的不同：非實時系統的時限是柔性靈活的，可以容忍偶然的超時錯誤，超時造成的后果并不嚴重，僅僅是輕微地降低了系統的吞吐量；而實時系統有剛性的、不可改變的時間限制，它不允許任何超出時限的錯誤，超時錯誤會帶來損害甚至導致系統失敗、或者導致系統不能實現它的預期目標[1]。

因此，非實時系統的時間性要求集中在平均的執行時間上，關注于系統在一段時間內的平均性能，保證系統的高吞吐量。而實時系統的時間性要求更關注于最差情況下的執行時間（WCET，worst-case execution time），要求在邏輯結果正確的前提下，在規定的時限內能夠傳遞正確的結果，滿足設計的響應時間要求。

利用普通的分析工具（如SystemVerify），程序開發人員只能得到軟件的平均執行時間和測試過程中所出現的最長的執行時間信息。對于一般的非實時系統來說，這些信息對于分析系統性能已經足夠了[2]。但對于具有嚴格時間性要求的實時系統來說，開發人員更關注于軟件的最差情況執行時間（WCET）。確保軟件的最差情況執行時間能夠滿足系統的時間性要求對于保障整個系統的可靠性具有非常重要的意義[3]。

然而隨著整個計算機技術的發展，軟件和處理器愈加復雜，如何得到軟件的最差情況執行時間是一個非常困難的工作，這是由于：首先，軟件的代碼量日益增加，功能愈發復雜，因此識別軟件的最差執行路徑并加以測試是非常困難乃至于很難完成的事情。其次，隨著一些新技術在硬件上的使用，如指令和數據cache，流水線結構和分支預測單元等，雖然這些技術極大地提升了硬件的性能，但也正由此指令不再是按照固定的時鐘節拍來順序執行，所以使得最差執行時間變得更加難以確定[4]。

目前國內的現狀基本上是依賴技術人員的經驗對系統執行時間進行估算，缺點在于：一是無法全面考慮各個軟件模塊的執行時間在真實的硬件環境中能否滿足設計要求，最差執行時間的獲取依賴于測試用例的設計以及測試路徑的選擇，往往需要經過幾輪測試之后才能逐步確認；二是由于無法得到每個函數語句的精確執行時間，代碼優化工作很困難，在代碼執行效率和代碼維護（可讀性）兩者之間很難找到一個平衡；三是由于手段落后，一些隱藏的時間性錯誤在常規的測試過程中無法顯現，帶來嚴重的設計隱患。而系統一旦在最差情況下的執行時間超出了設計的要求，就會帶來嚴重的質量問題[5]。

2 飛行控制軟件系統最差情況執行時間自動化測試工具

2.1 系統最差情況執行時間測試工具的選擇

對嵌入式箭載計算機飛行控制軟件系統最差情況執行時間進行自動化測試，一般使用軟件插樁技術來實現，其原理是：在被測試源代碼中的執行路徑上插入一個樁點，通過運行樁點來進行數據信息采集，獲取被測試程序的最差情況執行時間信息等。

一般通用的平臺上（例如Windows），由于其平臺資源豐富，性能強大，一般的插樁對其影響比較??；但是對于嵌入式軟件資源相對比較匱乏，性能相對較低，就要求考慮對插樁后的軟件進行影響分析，這些影響主要體現有：

1）源代碼插樁后空間膨脹。嵌入式系統資源匱乏，內存空間較小，但插樁源代碼會帶來源碼膨脹，統計比較分析得到源代碼膨脹率會達到20%-40%，往往超過嵌入式系統所提供內存空間，無法下載執行[6]。

2）源代碼插樁后時間膨脹。嵌入式系統對實時性要求比較強，但是由于插樁使系統增加了額外的開銷，函數的執行時間增加，性能下降，人機導致軟件時序混亂，功能失效[7]。

RapiTime是將動態測量和靜態分析兩種方法相結合的工具。測量方法的優點在于可以得到軟件的真實執行時間[8]，而靜態分析方法能夠通過對程序進行分析而得到最差情況的執行路徑。RapiTime結合了這兩種方法的優點而避免了它們的缺陷。

RapiTime采用“基于測量的時間分析方法”，不僅可以計算出執行時間的最大值，還可以通過靜態分析得出它們分類，從而得出不同硬件影響下執行時間的區別，并識別出缺乏效率的代碼。從而不僅能夠避免實時軟件的執行時間問題，同時對于提高軟件性能也有很大幫助。通過實驗得到使用RapiTime工具插樁后飛行控制軟件源程序的空間和時間膨脹率，見表1。

通過上述分析，本文提出應用RTBx硬件的解決方案，來完成嵌入式箭載計算機飛行控制軟件最差情況執行時間的自動化測試。

RTBx是RapitaSystems 公司提供的一個用于目標機程序執行時間獲取的可選硬件，在用戶的目標機硬件資源有限的情況下，用于記錄用戶應用程序執行的時間信息并輸入到RapiTime中進行分析。使用RTBx能夠方便的完成程序執行時間的獲取和存儲。

RTBx提供的硬件接口能夠與用戶目標硬件的輸出端口直接相連，當程序執行到時間獲取代碼時，對應的執行時間信息會輸出到目標硬件的輸出端口，與之相連的RTBx會記錄下檢測點的標識和對應的時間信息，用于RapiTime后續的分析過程。RTBx的優點在于：

1）測試不會被中斷：RTBx能夠對得到的測試數據采用壓縮格式進行存儲，這樣做一方面可以提高存儲的數據量，同時減低傳輸測試數據的時間。TraceBox的標準配置包括一個定制的I/O接口板（自帶1G的內存），2G的高達1066MHz的CPU內存，以及1TB的硬盤。雖然TraceBox的配置已經足以滿足現階段最復雜的程序的分析要求，但也可以根據用戶的需要進行擴展。即使是采用最高的采樣頻率，標準配置的 RTBx也可以無間斷的持續記錄數天的測試數據。

2）最大化的測量時間精確性：RTBx用于記錄檢測點的標識及對應的時間戳信息，檢測點的開銷僅僅是向某個指定的輸出端口寫一個常數，這通常只需要一到兩條匯編語句就可完成。這種方法將檢測點代碼的尺寸和執行時間的開銷都降到了最低。RapiTime可以通過在分析時減去一個固定的開銷時間從而將檢測點的時間影響進一步減少。

3）對于目標機的高適應性：由于RTBx直接與用戶目標硬件的輸出端口相連（可以是一個固定的輸出端口或者根據目標硬件的實際情況也可以是由不同輸出端口的單個輸出位組合而成），因此RTBx適用于任何目標機體系結構，而不是局限于某種特定的處理器類型。

RapiTime插入的檢測點具有唯一的標識（采用32位或者16位的范圍）。但是，當用戶目標硬件上可用的輸出位數有限時，RapiTime所獨有的技術保證能夠采用較少的輸出位數就能標識出檢測點，從而適用與資源有限的目標環境。

4）快速設置和遠程管理：RTBx的控制和顯示并不運行在用戶的目標系統上，是通過配置和運行在Windows或Linux遠程主機上的GUI進行控制。

5）長時間連續跟蹤數據（采用最高采樣頻率，存儲32位/16位數據持續時間可達69小時/ 138小時）。

6）不存儲于目標內存中，使用1M的緩存和6.25ms的存儲速度，RTBx的采樣頻率至少為20M/秒；作為對比，使用邏輯分析儀，在8位的采樣寬度下，使用20M/秒的采樣頻率，通常只能存儲0.2秒的數據。

7）低檢測開銷：測試代碼所帶來的額外開銷極低（通常每條測試代碼的執行只需要一至兩條CPU指令）。

8）對目標機的影響極?。号c測試數據直接存儲于目標機內存中不同，不需要預留大量內存為測試所用。

9）為收集測試數據所需的工作量很少：不需要為了獲取測試數據而停止應用程序的執行；不需要為了將測試數據上傳到開發主機中而建立單獨的連接方式。

2.2 RapiTime測試工具技術原理與特點

RapiTime需要根據目標程序的執行時間信息來進行軟件的時間性能分析。所謂的執行時間信息是由一組成對的數據組成，包括檢測點的標識（ID）和對應的時間戳信息，這些數據是隨著目標程序的執行而自動產生的。

通常，執行時間信息是在程序的執行過程中直接存儲在目標機內存中，開發人員需要在目標機的內存中預留出存放測試數據的部分。對于每個檢測點，檢測點的標識和對應的時間戳信息都需要存儲在內存中。當測試結束后，存儲在目標機內存中的測試數據需要上傳到開發主機中使用RapiTime進行進一步的分析。

RapiTime采用的“基于測量的執行時間分析方法”結合了靜態和動態分析方法的優點，動態測量是通過在真實硬件平臺上的“運行時測量”來實現，并結合對軟件結構的靜態分析，從而得到系統在具體目標硬件下真實的最差情況執行時間。RapiTime的技術特點有三點：

1）RapiTime使用測量的方法以確定代碼不同分支的子路徑在具體目標硬件上的真實執行時間。由于不需要對處理器進行建模，因此RapiTime能夠對8、16、32位處理器及DSP等硬件提供廣泛的支持。

2）RapiTime使用路徑分析技術對代碼的整體結構建立一個精確的數學模型，并確定代碼的哪些分支可以組合形成完整可行的路徑。RapiTime對于實時系統所廣泛使用的C和Ada語言提供全面的支持。

3）RapiTime結合測量和路徑分析信息，利用連接函數理論，捕獲對于不同的處理器硬件下各個路徑的執行時間，從而得到相對應的最差執行時間。

3 飛行控制軟件系統最差情況執行時間測試技術

3.1 飛行控制軟件系統最差情況執行時間測試過程

嵌入式箭載計算機飛行控制軟件系統最差情況執行時間測試過程共需6個步驟。

1）代碼預處理

通過一個自動化的程序將一些輕量級的時間檢測代碼加入到源程序中。

RapiTime提供cins工具自動化地將檢測點添加到源代碼中 （*.c文件）。在預編譯階段對源代碼進行處理，將所有的宏定義和#include定義全部展開。cins 工具能夠自動地將檢測點添加到經過預處理的代碼中（通常為*.p文件），根據測試的需要可以選擇在程序中的所有分支點中都添加檢測點。所謂的檢測點指的是一些輕量級的代碼執行時間獲取代碼。將添加過檢測點的代碼（*.i）以及檢測點的執行程序（rpt.c）編譯在一起生成可執行的程序，下載到目標機硬件中執行。

在編譯的過程中，cins工具同時對每個插入檢測點的C文件進行結構分析，生成對應文件的語法結構分析文件（*.xsc），用于后面的結構分析過程中。

2）結構分析

xstutils工具用于分析由 cins 生成的.xsc 文件中包含的結構信息。 xstutils 生成文件是待分析程序的語法結構說明。通過對經過預處理的代碼進行分析，就能夠得到整個程序的結構信息，并生成代碼調用的語法樹的總體結構說明。該說明用于后續的執行時間的跟蹤運行和最差情況執行時間分析過程。

3）獲得程序執行時間的數據（運行測試用例）

將經過預處理的程序在目標處理器上運行，也可以運行在周期準確的 CPU 模擬器上，目的是使得代碼在各種條件下執行所有的分支路徑。

在跟蹤過程中，RapiTime提供兩種手段用來獲得程序的執行時間信息：

第一種：當某一個時間獲取代碼被執行時，則該獲取代碼的標識和相對應的時間戳信息就會被紀錄下來，并存儲在板上目標板上的內存中，在測試結束后可上傳到RapiTime的運行環境中，用于接下來的時間性分析過程。需要注意的是，在這種方法中，由于程序的執行時間信息是存儲在目標板的內存中的，因此會有一定的內存開銷。

第二種方法：在目標板的內存資源有限的情況下，用戶可以選擇使用RapiTime的可選硬件RTBx來完成執行時間的獲取和存儲。

4）測試數據預處理

對上步過程中得到的時間信息文件進行處理，對數據進行過濾和更正（如定時器反轉），并將數據壓縮為二進制格式，與第二步中得到的程序結構說明相結合得到函數級的執行時間信息。

5）最差情況執行時間分析

一旦跟蹤結果已處理，分析過程的下一步就是最差情況執行時間的計算。 將子路徑的執行時間和代碼的整體架構相結合，生成一組針對特定代碼執行范圍的執行時間文件。

6）生成測試報告

生成基于Eclipse架構的執行時間報告。

3.2 飛行控制軟件系統最差情況執行時間測試結果分析

通過對嵌入式箭載計算機飛行控制軟件進行插樁，使用插樁后的源碼替代原始的源碼，重新編譯成功后，下載到目標機上運行執行測試用例，測試的執行時間分布結果見圖2，其中，Max、Average、Min為通過測量的方法得到的軟件在測試過程中所出現的最大、平均和最小執行時間。

從圖1中可見，使用RapiTime測試工具測到的最差情況執行時間超出了使用測量的方法得到的測試結果，并且超出了軟件需求規格說明中所提出的性能要求，發現了以前未能發現的問題，基于RapiTime測試工具所得到系統最差情況（WCET）和最佳情況（BCET）執行時間更接近于真實結果。測試方通過提問題單的方式建議開發方對程序進行優化，以滿足性能要求。

4 結束語

本研究詳細地闡述了嵌入式箭載計算機飛行控制軟件系統最差情況執行時間測試的需求與難點，詳細介紹了基于RapiTime測試工具及應用RTBx硬件的測試解決方案的技術原理，并通過具體的實驗分析比較了測試工具插樁后的代碼膨脹率，為測試工具的選擇提供依據。介紹了嵌入式箭載計算機飛行控制軟件系統最差情況執行時間測試的全過程，詳細地分析和研究了系統最差情況執行時間測試的結果，使得軟件設計師能夠依據測試結果提升軟件的性能和可靠性。

參考文獻：

[1] 高熾揚，曹玉紅.測試目的變遷帶來軟件發展[J].軟件世界，2005（10）：87-88.

[2] 鄭人杰.計算機軟件測試技術[M].北京：清華大學出版社，1992：43-48.

[3] John C，Munson. Software faults，software failures and software reliability modeling[J].Information and Software Technology，1996（38）：687-699.

[4] Ian Sommerville. Software Engineering[M].北京：清華大學出版社，2004：115-117.

[5] Erman Coskun，Martha Grabowski. Software complexity and its impacts in embedded intelligent real-time systems[J].The Journal of Systems and Software，2005（78）：128-145.

[6] 喬文軍，萬曉冬.嵌入式軟件覆蓋測試工具的研究[J].計算機測量與控制，2007（9）：1238-1240.

[7] 佟偉光.軟件測試[M].北京：人民郵電出版社，2008：12-24.

[8] 李書浩，齊治昌.程序設計規則檢查：一種保障軟件質量的基本方法[J].計算機科學，2003（11）：148-151.