硬件板卡測試系統(tǒng)設計與實現(xiàn)

李倩，張立鵬，張奕男

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

1 測試系統(tǒng)設計

硬件板卡測試系統(tǒng)由硬件環(huán)境、上位機軟件與下位機軟件3部分組成。

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

表1 機籠槽道硬件配置

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

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

2 軟件架構(gòu)

整體設計上,測試系統(tǒng)的軟件架構(gòu)分為表示層、業(yè)務層和數(shù)據(jù)訪問層3層,如圖1所示,目的是實現(xiàn)高內(nèi)聚、低耦合,增強硬件板卡測試系統(tǒng)的可重用性與擴展性。

圖1 測試系統(tǒng)軟件架構(gòu)

表示層:以Windows窗體的形式展現(xiàn),在窗體中顯示測試機籠的結(jié)構(gòu)圖,實時顯示軟件運行過程中各測試板卡的報警或故障信息。用戶可通過表示層操控測試系統(tǒng)。

業(yè)務層:對數(shù)據(jù)相關(guān)業(yè)務的邏輯處理,業(yè)務層處理接收和發(fā)送的所有數(shù)據(jù),根據(jù)通信協(xié)議進行組包和不同類型的消息分發(fā)與解析。

數(shù)據(jù)訪問層:接收和發(fā)送基于網(wǎng)絡通信的原始數(shù)據(jù)。

功能結(jié)構(gòu)上,測試系統(tǒng)軟件可分為網(wǎng)絡通信模塊、測試預設模塊、命令發(fā)送模塊、數(shù)據(jù)采集模塊、數(shù)據(jù)解析模塊、界面顯示及警告模塊和報告生成模塊。各個功能模塊之間需要有關(guān)聯(lián)性和時序性,以正確地執(zhí)行軟件功能,滿足軟件功能需求。測試系統(tǒng)軟件處理流程見圖2。

圖2 測試系統(tǒng)軟件處理流程

2.1 網(wǎng)絡通信模塊

由于硬件板卡測試系統(tǒng)對時效性要求較高,為了提高信息傳輸?shù)撵`活性和時效性,選擇UDP協(xié)議（User Datagram Protocol,用戶數(shù)據(jù)報協(xié)議）進行網(wǎng)絡通信［9］。

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

圖3 幀協(xié)議格式

幀頭（0x5A）與幀尾（0xA5）是用于區(qū)分是否是本測試系統(tǒng)報文的固定字節(jié),各占1個字節(jié)。

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

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

周期號（CycleNo）用于區(qū)分下位機周期性發(fā)送報文的計數(shù)值,占4個字節(jié)。

類型（MsgType）用于區(qū)分不同類型的報文消息,占1個字節(jié)。

子類型用于區(qū)分同一類型不同分組的報文消息,占1個字節(jié)。

數(shù)據(jù)長度表示后面填充的應用數(shù)據(jù)所占的字節(jié)總數(shù),占2個字節(jié)。

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

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

2.2 測試預設模塊

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

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

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

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

2.3 數(shù)據(jù)采集模塊

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

圖4 數(shù)據(jù)采集流程

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

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

數(shù)與錯誤次數(shù)記錄到數(shù)據(jù)結(jié)構(gòu)中,并以一定的周期（500 ms）通過Send函數(shù)發(fā)送給上位機軟件。

2.4 數(shù)據(jù)解析模塊

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

圖5 數(shù)據(jù)解析

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

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

2.5 界面顯示及警告模塊

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

2.6 報告生成模塊

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

3 結(jié)束語

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