實時嵌入式產品的測試系統設計

葉永鑫,丁曉明

(北京交通大學,北京 100044)

引 言

嵌入式系統是以應用為中心,以計算機技術為基礎,能夠適應實際應用中對功能、可靠性、成本、體積、功耗等嚴格要求的專用計算機系統。它是先進的計算機技術、半導體技術以及電子技術與各個行業的具體應用相結合的產物。在一些特定領域,它被要求能夠實時響應外部的請求并處理相應的計算,最后把結果及時地反饋給用戶或者外設。

隨著嵌入式應用領域的迅速擴大,人們對嵌入式軟件質量提出了更高的要求,如何對日益復雜的嵌入式軟件進行快速有效的測試成了目前的關注熱點。

1 設計原理

1.1 系統需求

圖1 原系統架構

本文采用的被測試嵌入式系統如圖1所示,是一套運行有飛行控制軟件的嵌入式系統。它需要對飛行的姿態、軌跡做出計算,并通過總線的方式與舵機、發動機、導引頭、慣性測量單元進行交互。測試的對象為該嵌入式平臺上運行的飛行控制軟件,其余的外設由測試系統仿真實現。本文主要討論測試系統的設計與實現。嵌入式系統所使用的核心器件是DSP芯片,它擁有多種接口,有1路A/D、1路D/A、8路開關量、2路串行422接口、2路串行485接口。通過各種接口的通信完成要求的功能。系統運行后將長時間處于每隔5 ms與外設完成1次交互的狀態,其中1次交互包括2次請求收發數據(狀態和控制數據)、傳輸所有開關量、A/D的數據。

圖2 測試系統架構

測試系統具體要求如下:首先,由工控機(由測試系統模擬,如圖2所示)發送裝訂參數給嵌入式設備;接著,嵌入式設備根據裝訂參數進行初始化,并處于等待命令狀態;工控機發送開始運行命令給嵌入式設備;嵌入式設備收到開始命令后,進入周期循環狀態。

周期循環狀態:

①嵌入式系統會向外部1號設備(由測試系統模擬)請求外設1控制數據,外部1號設備需要在2 ms內把數據發送給嵌入式系統。

②嵌入式系統會向外部2號設備(由測試系統模擬)請求外設2控制數據,外部2號設備需要在2 ms內把數據發送給嵌入式系統。

③上位機(由測試系統模擬)需要在發送完外設2的控制數據后的1 ms完成對嵌入式系統相關數據的采集。整個循環周期要求嚴格控制在5 ms以內。

通信流程如圖3所示。

圖3 通信流程

1.2 設計思想

設計一套能夠符合需求要求的測試系統,對于測試系統有5點要求:第一,能夠及時響應DSP以中斷方式的數據請求;第二,有足夠的性能解析數據,發送數據;第三,擁有良好的人機交互界面;第四,能夠管理測試過的用例及結果;第五,能夠靈活地增加故障,如通信故障、指令故障、數據故障。

較高實時性的要求使得在設計測試系統時大大增加了系統的復雜度和限制了可用的解決方案。Windows是一種分時操作系統,處理中斷的能力不是很穩定,有時候將不能滿足嵌入式系統要求的條件。另外,分時操作系統定時器精度差,漂移現象嚴重,存在隱含的不確定的線程調度機制。但是這里需要Windows操作系統上的一些高級特性,如功能強大的圖形化接口(GUI)支持,支持多種開發工具及應用程序,眾多廉價的第三方硬件及驅動的支持,豐富的Win32應用程序接口。

RTX(Real-time Extension for Control of Windows),是向Windows平臺加入了一個實時擴展子系統(RTSS)。它獨立的基于搶占式的RTX線程調度機制允許RTSS線程優先于所有的Windows線程和中斷,持續中斷響應頻率30 k Hz以上,最大IST處理延遲不超過16μs;提供高速準確的實時時間響應,定時器最小周期為100μs,時鐘最小分辨率為100 ns。特別適合于飛行模擬器、復雜視頻監控系統、視頻圖像處理、轉臺、機器人、導彈發射裝置、火炮等典型的既有圖形又要求實時的控制伺服系統。它是一種基于Windows平臺的硬實時解決方案。Windows處理人機接口等通用GUI任務,實時擴展子系統用于進行實時控制和實時的數據采集,它們之間的數據傳遞機制通過進程間通信的方式,應用共享內存、信號量等機制實現。

綜上考慮,給出兩種設計方案。

2 設計方案

2.1 Windows+RTX(工控機+接口卡)

Windows+RTX方案如圖4所示,此種設計方案軟件部分分為3層。

圖4 工控機+接口卡結構圖

Windows用戶界面層。在Windows操作系統上開發部分軟件,負責數據庫的管理、用例的添加、運行結果的保存,提供一套優秀界面呈現給用戶。

RTX邏輯控制層。主要負責用例運行,實時地與被測系統交互,滿足被測系統相關數據的請求,保存被測系統發出的狀態數據。

外設驅動層。為了滿足對系統100%的測試,還需要有測試系統與被測系統之間的通信接口卡。從硬件劃分包括1臺工控機、2塊ISA總線RS422通信卡、2塊PCI總線RS485通信卡、1塊A/D卡、開關量采集卡、D/A卡。這些硬件板卡通過ISA、PCI總線的方式連接到測試平臺里,測試平臺管理所有板卡的驅動程序,使其與被測系統形成閉環。

這樣,3層的軟件結構就能夠順利地運行用例,實現對系統的完整的功能測試。

2.2 Windows+Verilog(工控機+FPGA板卡+接口芯片)

第2套方案使用的是Windows+Verilog,如圖5所示。在這種方案中,使用FPGA來管理各個接口,并通過PCI總線與工控機通信。PCI總線能夠把各種接口的數據上傳到工控機,同時把工控機的數據下載到被測試系統上。

圖5 工控機+FPGA板卡+接口芯片結構圖

系統也是3層結構,上兩層與第1種方案基本一樣,但在外設驅動層上不再是從多塊板卡之間取數送數,而是單一地與FPGA板卡通過制定好的協議進行通信,而后的接口芯片采集、編碼等工作都交給FPGA完成。

3 方案比較

3.1 兩種方案優缺點比較

表1詳細比較了上述2套方案的優缺點。第2種設計方案中,因為有了FPGA器件,使得原來考慮不周的設計可以只重新配置硬件就得以修改,減少重新制版的周期、經費等一系列不確定因素,達到更廣泛的測試目的。

表1 多張板卡與單一板卡比較

3.2 不同操作系統優缺點比較

此外,方案的實行也可以考慮在工控機上直接運行一些實時操作系統,如DOS、VxWorks等等。DOS是單任務實時系統,人機交互界面差,沒有網絡功能。表2比較了Windows+RTX和VxWorks兩種方案的優缺點。

表2 Windows+RTX和 VxWorks比較

4 用例管理軟件設計

在軟件上層,需要設計出帶有數據庫的用例管理系統,它需要管理用例的定義、簡介、組別、運行時間、過程數據、結果數據,并能夠作用例回歸測試的用例管理層。用例運行前需要收集用戶輸入的各種參數,并從相應的文件位置提前把相關數據讀取到內存里,提前準備數據。用例運行時,RTX層會有相應的CPU空閑時間,而用例管理層會利用這段時間進行運行狀態的顯示。用例運行結束后,相應的標志位會被置位,用例管理層讀到相應的狀態后會主動向RTX層索要運行的各種數據和結果,并把相應的數據存入數據庫,寫入日志,并呈現到界面上。

結 語

試驗證明,上述設計的測試系統在整機聯調過程中運行狀態良好,符合對系統各個模塊功能全面測試的要求。

本文針對目前嵌入式系統測試這一熱點問題,提出了1種實時嵌入式軟件的測試系統的結構框架,并且按照這個思路實現了對黑盒(功能)測試的測試系統。下一步工作就是開發1個嵌入式軟件的通用測試平臺,能夠同時對多種型號、多種接口的嵌入式系統進行測試。

此方案也適用于視頻圖像處理、視頻監控系統。

[1]康一梅,張永革,李志軍,等.嵌入式軟件測試[M].北京:機械工業出版社,2008.

[2]朱少民.軟件質量保證和管理[M].北京:清華大學出版社,2007.