硬件板卡測試系統設計與實現

李倩，張立鵬，張奕男

在信號系統中,為了確保地鐵或國鐵現場中各系統的正常運行,首先要保證硬件板卡本身的功能正常,因此板卡生產廠商需對硬件板卡在出廠前進行充分的測試,以確保硬件的各個接口,如網口、串口、CAN口、定時器等能夠滿足設計及現場的需要［1］,減少出廠板卡的故障率,即在出廠前保證硬件板卡的功能可靠穩定。基于此,為了更加方便地對核心的硬件板卡進行大規模的測試,需要設計一套功能齊全、安全穩定、便捷簡單的自動化硬件板卡測試系統,用于保障硬件板卡的生產質量［2-3］；同時對從板卡生產廠商采購的所有板卡進行抽樣檢查與驗收。

1 測試系統設計

硬件板卡測試系統由硬件環境、上位機軟件與下位機軟件3部分組成。

1）硬件環境包括機柜、機籠、板卡、交換機、電源、工控機等,待測設備通常為機柜,可以同時測試1套或多套設備,1套設備可配插1塊或多塊板卡（取決于硬件機柜的結構）,這是硬件板卡測試系統的基礎。以VLE（中心處理運算板）測試為例,其機籠槽道硬件配置見表1。機籠中設置A、B雙系,每系中有VLE板卡、VPS（安全電源板）板卡及其他板卡。每系VLE板卡上有2個CPU,簡稱為上模塊和下模塊,各模塊中分別設有4個串口、2個CAN口 和2個網 口,A、B系VLE板卡的各硬件接口通過配線通信。A系VLE上模塊串口1～4與B系VLE上模塊串口1～4配線連接；A、B系各個網口獨立配線,連接至交換機；A系VLE上 模 塊CAN1和CAN2與B系VLE上模塊CAN1和CAN2配線連接,VLE下模塊各接口配線方式相同。只有確保硬件中的板卡、配線等都連接正確,才能保證測試的準確性與可靠性。

表1 機籠槽道硬件配置

2）上位機軟件基于Windows平臺下的.NET,使用C#語言開發［4］,使用spring.net框架進行XML配置［5］,將測試軟件安裝到工控機上,通過交換機與通信板卡進行網絡通信,將下位機發出的板卡各接口的測試信息快速采集后存儲在本地［6］,并顯示到界面上警示用戶,最終確定各板卡是否通過測試。

3）下位機軟件基于VxWorks操作系統,使用C語言開發［7］,編譯的軟件鏡像（Image）通過網線直接燒錄到通信板卡的Flash中（VLE的上、下2個模塊分別與交換機連接）。下位機軟件的主要功能是通過特定數據的發送與接收,對硬件板卡上的各個接口按照最高性能指標進行接口功能測試［8］,并將根據自定義通信協議組包生成的測試數據,通過網絡發送給上位機軟件進行處理。

2 軟件架構

整體設計上,測試系統的軟件架構分為表示層、業務層和數據訪問層3層,如圖1所示,目的是實現高內聚、低耦合,增強硬件板卡測試系統的可重用性與擴展性。

圖1 測試系統軟件架構

表示層:以Windows窗體的形式展現,在窗體中顯示測試機籠的結構圖,實時顯示軟件運行過程中各測試板卡的報警或故障信息。用戶可通過表示層操控測試系統。

業務層:對數據相關業務的邏輯處理,業務層處理接收和發送的所有數據,根據通信協議進行組包和不同類型的消息分發與解析。

數據訪問層:接收和發送基于網絡通信的原始數據。

功能結構上,測試系統軟件可分為網絡通信模塊、測試預設模塊、命令發送模塊、數據采集模塊、數據解析模塊、界面顯示及警告模塊和報告生成模塊。各個功能模塊之間需要有關聯性和時序性,以正確地執行軟件功能,滿足軟件功能需求。測試系統軟件處理流程見圖2。

圖2 測試系統軟件處理流程

2.1 網絡通信模塊

由于硬件板卡測試系統對時效性要求較高,為了提高信息傳輸的靈活性和時效性,選擇UDP協議（User Datagram Protocol,用戶數據報協議）進行網絡通信［9］。

上位機軟件與下位機軟件之間的協議約定見圖3。

圖3 幀協議格式

幀頭（0x5A）與幀尾（0xA5）是用于區分是否是本測試系統報文的固定字節,各占1個字節。

版本用于定義協議的版本號,當協議升級時,版本變更。

應用消息長度定義此字段（不包含）后面的所有報文的字節總數,考慮到每包消息的最長字節數,定義為2個字節。

周期號（CycleNo）用于區分下位機周期性發送報文的計數值,占4個字節。

類型（MsgType）用于區分不同類型的報文消息,占1個字節。

子類型用于區分同一類型不同分組的報文消息,占1個字節。

數據長度表示后面填充的應用數據所占的字節總數,占2個字節。

本系統中所有類型報文消息均小于1 000個字節,故未考慮分包與組包。

為了防止消息丟包,保證消息接收的可靠性與完整性,上位機軟件采用異步回調函數接收網絡消息,下位機軟件采用select模式非阻塞方式接收消息,為業務層處理數據提供基礎和保障。

2.2 測試預設模塊

本模塊是開始正式測試前的預設配置,通過與用戶交互方式實現。界面中設有測試人、測試時長、板卡序列號的編輯框,待有數據鍵入后,系統將測試人員姓名或工號、測試時長（精確到分）、待測板卡的序列號記錄到內存中。在上述3個條件編輯框中內容均不為空的情況下,才會允許用戶啟動“開始測試”。

板卡序列號是待測板卡報告及測試記錄的唯一標識,支持傳統條形序列號及二維碼2種格式,可以用掃描槍掃描或手動輸入到指定的編輯框中,板卡序列號按照以下機制設計。

1）檢測機制。如果檢測到當前編碼框中的序列號與其他重復或為空,系統彈出警示框。

2）動態創建。由于不同測試中板卡的個數是不同的,因此,本系統根據板卡復選框的點選情況,采用動態創建文本框和編輯框的模式,使測試系統功能更加靈活。

2.3 數據采集模塊

監聽線程接收到上位機軟件發送的開始測試命令后,首先調用驅動函數對機籠中的槽位是否有板卡進行檢測,并與上位機發送的板卡槽位檢測（拔插）情況進行比對,如果比對不一致,將比對結果通過Send函數發送給上位機軟件；如比對一致,下位機會啟動采集任務,并對采集數據處理后發給上位機,數據采集流程見圖4。

圖4 數據采集流程

系統依次對待測板卡上的網口、CAN口、串口等接口進行數據采集與正確性判斷。測試方案是A系VLE金板（良品,功能正常的板卡）與B系待測VLE板卡的各個對應接口進行通信。首先,金板調用驅動程序的接口函數發送一包固定長度的隨機測試數據,待測板卡收到數據后,先對接收到的數據（不包含發送方計算的CRC校驗碼）計算CRC校驗碼,再與發送方計算的CRC校驗碼進行比對,如果一致,本輪采集是正確無誤的,測試次數遞增1,如果不一致,錯誤次數遞增1；然后,待測板卡將一包固定長度的隨機數據回發,金板收到數據后同樣計算CRC并比對,如果一致,本輪采集是正確無誤的,測試次數遞增1,如果不一致,錯誤次數遞增1。

下位機軟件實時將各個待測接口測試的正確次

數與錯誤次數記錄到數據結構中,并以一定的周期（500 ms）通過Send函數發送給上位機軟件。

2.4 數據解析模塊

本模塊對接收到的數據進行處理。以上位機軟件為例,如圖5所示,監聽線程收到報文后,首先會放到消息隊列中,數據解析模塊會對消息隊列進行輪詢,如果輪詢到數據,便會一次性從消息隊列中pop出全部數據。

圖5 數據解析

上位機軟件根據幀協議針對不同的消息類型（MsgType）進行消息分發,統一用*Response類來解析。不同類型的數據進入到相應的*Response類中進行報文解析,如ShakeRespose類用于解析握手回復消息,BoardStatusResponse類用于解析板卡故障消息,ComponentTestResponse類用于解析接口組件的常規消息等。每個*Response都繼承了基類Response,基類中定義了板卡ID、接收時間Dtime、原始數據OriginalData和周期號CycleNo。每種解析都會返回字符串類型的返回值,并且根據解析結果將對應的待測板卡標志位更新為通過或失敗。

該解析方法既降低了模塊之間的耦合度,也可實現系統的擴展,如果新添加不同類型的網絡消息解析,只需要在業務層復寫對應類型的Response派生類。

2.5 界面顯示及警告模塊

本模塊用于顯示測試指令及必要的警告信息。界面中設置機籠中各板卡的相對槽道簡易圖,如無報錯信息上報,則相應槽道背景色設置為綠色；當對應板卡有報錯信息上報時,將相應槽道背景色設置為紅色,同時在界面的文本框中顯示出具體的故障信息,如故障板卡的名稱、槽道號、首次出錯時間、故障碼等,并同步記錄到本地csv格式日志中,方便用戶查詢。

2.6 報告生成模塊

本模塊以待測板卡的序列號作為唯一標識生成報告,并上傳到服務器,作為待測板卡測試是否通過的重要證據。當系統運行達到預設的測試時間時,會生成報告；當系統的預設測試時間未到,而是用戶手動強制停止測試時,不生成報告,本次測試無效,需要重新對本輪測試的所有板卡進行測試。

3 結束語

目前測試系統已應用于板卡生產廠商及公司質量部,通過對信號系統硬件板卡各項硬件接口進行測試,有效地避免了人為測試的繁瑣或操作不當引起的測試失誤,提高了板卡的測試效率,減少了驗收的人力成本；同時該測試系統可對故障板卡進行故障定位,協助分析現場返回問題板卡的硬件故障［10］,從而保障了現場信號系統中各板卡硬件功能的正確性與完整性。