車載分布式ATS動態(tài)可配置實現(xiàn)策略研究

申 飛,崔建峰,劉慧豐,馮 亮,李 杰,尤文斌

(1.中北大學(xué) 電氣與控制工程學(xué)院，太原 030051；2.北京特種車輛試驗場，北京 100072；3.中國北方車輛研究所，北京 100072)

為準(zhǔn)確分析車輛設(shè)備的健康狀況，需對車輛設(shè)備開展全面性的設(shè)備綜合測試。傳統(tǒng)的車輛測試方案采用“分立式”的測試方案，即針對每個具體的被測對象開發(fā)專項ATS，以實現(xiàn)車輛在運行過程中不同部位運行工況的反映——比如采用網(wǎng)絡(luò)化耐高溫溫度場測試系統(tǒng)實現(xiàn)對動力艙溫度分布狀態(tài)的實時獲取[1]；采用應(yīng)變應(yīng)力微型在線監(jiān)測遙測裝置實現(xiàn)對車輛關(guān)鍵構(gòu)件的載荷測試[2-3]；采用分布式加速度傳感裝置實現(xiàn)對車輛懸架系統(tǒng)振動工況的實時監(jiān)測[4]等。上述“分立式”方案的主要問題在于：專項ATS功能設(shè)計單一，可擴(kuò)展性差，從而導(dǎo)致車輛ATS開發(fā)成本高、系統(tǒng)優(yōu)化難度大[5]。解決此問題的一個有效途徑是采用分布式設(shè)計架構(gòu)[6]。分布式架構(gòu)采用開放式的通訊網(wǎng)絡(luò)結(jié)構(gòu)以實現(xiàn)系統(tǒng)的可擴(kuò)展，通過測試資源的集成與共用以降低系統(tǒng)開發(fā)成本。但現(xiàn)有分布式ATS存在以下問題：分布式ATS軟件以靜態(tài)化的方式配置主控單元與各個節(jié)點之間的關(guān)系。當(dāng)分布式ATS的測試節(jié)點發(fā)生變更時，要求重調(diào)主控單元程序代碼當(dāng)中的配置參數(shù)，從而導(dǎo)致系統(tǒng)配置效率的大幅下降[7]。

為解決分布式系統(tǒng)對節(jié)點單元變化的適應(yīng)能力問題，文獻(xiàn)[8]采用軟插件技術(shù)幫助實現(xiàn)異構(gòu)數(shù)控系統(tǒng)通信協(xié)議的動態(tài)轉(zhuǎn)換。結(jié)合軍用車輛底盤系統(tǒng)的測試需求，本文提出一種車載分布式ATS的動態(tài)可配置實現(xiàn)策略。該策略以開放式的硬件通訊平臺設(shè)計為基礎(chǔ)，通過對測試資源建模以及在底層配置協(xié)議下對數(shù)據(jù)接收存儲映射的動態(tài)重建，最終實現(xiàn)分布式ATS的動態(tài)可適配。相比于傳統(tǒng)分布式ATS靜態(tài)化的配置思想，本設(shè)計將系統(tǒng)配置作為系統(tǒng)動態(tài)業(yè)務(wù)的一部分，業(yè)務(wù)中由于配置參數(shù)動態(tài)可變，從而實現(xiàn)系統(tǒng)結(jié)構(gòu)形態(tài)在一定范圍內(nèi)柔性可調(diào)。

1 設(shè)計思想概述

本文提出的車載分布式ATS動態(tài)可配置實現(xiàn)策略，基于測試系統(tǒng)“生產(chǎn)者-消費者”的開發(fā)模式，在保持實現(xiàn)測試功能所必須的基本環(huán)節(jié)與業(yè)務(wù)形態(tài)不變的前提下，充分考慮測試前端可變對系統(tǒng)造成的影響，對其進(jìn)行動態(tài)適配性設(shè)計。

設(shè)計當(dāng)中，適配目標(biāo)為在統(tǒng)一電氣接口與通訊協(xié)議約束設(shè)計下的測試前端。整個適配過程在系統(tǒng)上位機(jī)與分布式測試管理器的統(tǒng)一協(xié)調(diào)工作下完成：首先，系統(tǒng)上位機(jī)收集并整合當(dāng)前所有處于連接狀態(tài)的測試前端的屬性信息，建立測試資源模型；其次，系統(tǒng)上位機(jī)調(diào)用模型數(shù)據(jù)訪問業(yè)務(wù)對測試資源模型進(jìn)行訪問，根據(jù)訪問結(jié)果分析當(dāng)前測試任務(wù)對底層數(shù)據(jù)緩沖區(qū)的配置需求，生成底層配置協(xié)議；最后，分布式測試管理器則根據(jù)系統(tǒng)上位機(jī)下發(fā)的配置協(xié)議控制調(diào)整緩沖結(jié)構(gòu)，重建其與數(shù)據(jù)源之間的映射關(guān)系，最終實現(xiàn)對測試前端變化的自適應(yīng)。設(shè)計用例簡圖如圖1。

圖1 設(shè)計用例簡圖

2 分布式ATS動態(tài)可重構(gòu)設(shè)計

2.1 通訊平臺設(shè)計

為實現(xiàn)硬件通訊平臺的動態(tài)可重構(gòu)，本文基于開放式現(xiàn)場總線技術(shù)，通過車載CAN通信局域網(wǎng)和分布式測試管理器構(gòu)建分布式ATS的硬件通訊平臺，其系統(tǒng)組成結(jié)構(gòu)框圖如圖2。

圖2 硬件通訊平臺結(jié)構(gòu)框圖

CAN協(xié)議規(guī)范定義了OSI開放式互聯(lián)模型中的物理層、數(shù)據(jù)鏈路層以及應(yīng)用層，使得在保證系統(tǒng)開放可擴(kuò)展的基礎(chǔ)之上簡化其組成，提高開發(fā)與運行效率。網(wǎng)絡(luò)總線物理層采用雙絞線作為通訊介質(zhì)，信號以差分電壓的形式進(jìn)行傳輸[9]。所有測試前端設(shè)備與分布式測試管理器通過內(nèi)部CAN總線彼此互聯(lián)，構(gòu)成分布式測試局域網(wǎng)。

分布式測試局域網(wǎng)在一主多從的模式下進(jìn)行工作，分布式測試管理器作為通訊主節(jié)點向局域網(wǎng)內(nèi)的測試前端設(shè)備(從節(jié)點)發(fā)送廣播信息或一對一定向指令，測試前端設(shè)備依據(jù)指令內(nèi)容執(zhí)行對應(yīng)的操作——包括系統(tǒng)初始化、配置參數(shù)修改、運行數(shù)據(jù)采集、采集數(shù)據(jù)上傳、工作狀態(tài)上傳以及錯誤信息報告等。

分布式測試管理器由主控模塊、通訊模塊、存儲模塊以及外圍電路構(gòu)成。主控模塊采用飛思卡爾MC9S12XEP100作為主控芯片，該芯片內(nèi)置MSCAN通訊模塊，可實現(xiàn)CAN2.0A與CAN2.0B兩種CAN協(xié)議，在進(jìn)行實際開發(fā)時，只需設(shè)計外圍電路與CAN驅(qū)動器即可[10]。系統(tǒng)設(shè)計將測試數(shù)據(jù)以文件的形式保存于FLASH芯片當(dāng)中，為防止數(shù)據(jù)掉電丟失，設(shè)計在FLASH數(shù)據(jù)寫入之前先將緩沖數(shù)據(jù)、文件屬性信息以及FLASH當(dāng)前的寫入狀態(tài)信息保存于鐵電存儲器FRAM當(dāng)中，從而使得系統(tǒng)能夠在重新上電之后快速恢復(fù)工作狀態(tài)。

2.2 測試資源建模

對測試節(jié)點信息模型化、結(jié)構(gòu)化的管理方式為系統(tǒng)實現(xiàn)測試資源動態(tài)可適配提供了軟件層面的可能。設(shè)計通過數(shù)據(jù)字典組織測試節(jié)點的屬性信息，并建立測試資源模型，建模原理示意圖如圖3。

圖3 測試資源模型示意圖

模型當(dāng)中以測試節(jié)點Nodei(1≤i≤n)作為系統(tǒng)測試資源的組織單位：

SysResource={Node1,Node2,…,Noden}

(1)

對于包含其中的每個測試節(jié)點，可將其屬性通過式(2)進(jìn)行描述：

Node=(NodeID,FramBytesLenth,TestBusiness)

(2)

其中:NodeID為通訊標(biāo)識符；FramBytesLenth為該節(jié)點所上傳的數(shù)據(jù)幀字節(jié)長度；TestBusiness為該測試節(jié)點所具有的測試業(yè)務(wù)。在此以信道代表測試節(jié)點上單個信號采集端口的業(yè)務(wù)實現(xiàn)，每個節(jié)點所包含的測試業(yè)務(wù)可描述為

TestBusiness={Ch1,Ch2,…,Chn}

(3)

模型當(dāng)中對信道的描述形式為

Channel=(ChID,SigType,CaliModel,ValRange,

ByteLenth,Precision)

(4)

其中:ChID為該信道的標(biāo)識符；SigType為端口信號類型；CaliModel為該信道測試所得數(shù)據(jù)的標(biāo)定方式，在系統(tǒng)上位機(jī)當(dāng)中對應(yīng)于不同的數(shù)據(jù)標(biāo)定業(yè)務(wù)與相關(guān)參數(shù)，以實現(xiàn)測試數(shù)據(jù)的處理與解析適配；ValRange表示該信道的值域范圍；ByteLenth為該信道的數(shù)據(jù)字節(jié)長度；Precision代表測試精度。

最終形成的測試資源數(shù)據(jù)字典通過基于可擴(kuò)展標(biāo)記語言的XML文件實現(xiàn)[11]，并由.NET框架下的System.Xml命名空間提供訪問支持。

2.3 存儲映射的重建

對于分布式測試管理器而言，系統(tǒng)測試節(jié)點改變對系統(tǒng)存儲配置的影響主要在于原有通訊節(jié)點與存儲地址之間的映射關(guān)系被打破。傳統(tǒng)的分布式ATS軟件一般采用靜態(tài)數(shù)組實現(xiàn)測試數(shù)據(jù)的緩沖，數(shù)據(jù)源與緩沖區(qū)之間的映射關(guān)系往往是固定不變的，而此種靜態(tài)配置方式下的映射關(guān)系一旦被打破，只能通過線下重寫程序代碼進(jìn)行修復(fù)。因此，

本設(shè)計當(dāng)中對系統(tǒng)進(jìn)行動態(tài)適配的主要工作將集中于重建通訊節(jié)點與數(shù)據(jù)緩沖區(qū)地址之間的映射。

系統(tǒng)上位機(jī)根據(jù)測試資源模型提供的有效信息長度描述生成底層配置協(xié)議，配置協(xié)議格式如表1所示。協(xié)議當(dāng)中的測試節(jié)點表示CAN測試局域網(wǎng)當(dāng)中具備測試數(shù)據(jù)上傳業(yè)務(wù)、并通過CAN通訊ID進(jìn)行標(biāo)識的通訊對象；每個測試節(jié)點下所包含的配置描述信息包括該節(jié)點的通訊ID、該節(jié)點所上傳的有效信息長度、信道數(shù)量以及信道的字長。

表1 通訊協(xié)議配置信息

在指定控制命令下，分布式測試管理器通過串口接收系統(tǒng)上位機(jī)下發(fā)的底層配置協(xié)議，接收成功后，分布式測試管理器通過重置緩沖區(qū)容量、重建緩沖區(qū)地址與通訊節(jié)點之間的映射兩個步驟實現(xiàn)配置重置。

分布式測試管理器首先讀取配置協(xié)議中的有效數(shù)據(jù)總長，然后通過malloc動態(tài)內(nèi)存分配函數(shù)在存儲堆區(qū)(Heap)中開辟相應(yīng)字節(jié)大小的緩存空間，并將其用于數(shù)據(jù)接收，從而實現(xiàn)數(shù)據(jù)接收對于數(shù)據(jù)容量變動的適配。其后，分布式測試管理器讀取配置協(xié)議中的通訊節(jié)點信息，據(jù)此建立動態(tài)鏈表以映射動態(tài)緩沖區(qū)當(dāng)中的各個節(jié)點數(shù)據(jù)存放的首地址。配置協(xié)議與鏈表節(jié)點之間的關(guān)系示意圖如圖4。

圖4 配置協(xié)議與鏈表節(jié)點關(guān)系示意圖

鏈表節(jié)點Node(k)通過數(shù)據(jù)結(jié)構(gòu)COM_NODE實現(xiàn)，其內(nèi)容按如下方式定義：

typedef struct

{

byte *dataAddr;

unsigned short nodeID;

unsigned short dataLenth;

unsigned short chelCount;

unsigned short chelLenth;

struct COM_NODE *next;

}COM_NODE

其中，*next代表下一個鏈表節(jié)點Node(k+1)的存放地址；nodeID為該鏈表節(jié)點所對應(yīng)通訊節(jié)點的ID標(biāo)識符；dataLenth為對應(yīng)通訊節(jié)點上傳數(shù)據(jù)幀當(dāng)中有效數(shù)據(jù)的總長；chelCount為上傳數(shù)據(jù)幀當(dāng)中所包含的信道數(shù)量；chelLenth為信道的字節(jié)長度?；谠O(shè)計當(dāng)中所采用的CAN通訊協(xié)議，其數(shù)據(jù)幀最大有效數(shù)據(jù)長度為8 Byte，設(shè)計將信道長度統(tǒng)一定義為2 Byte，則每個通訊節(jié)點上傳的數(shù)據(jù)幀當(dāng)中最多包含4條有效信道。動態(tài)緩沖區(qū)當(dāng)中，由通訊節(jié)點上傳所得的測試數(shù)據(jù)按鏈表節(jié)點的先后順序連續(xù)分布，如圖5所示。

圖5 存儲緩沖區(qū)結(jié)構(gòu)

第k個測試節(jié)點于動態(tài)緩沖上的映射關(guān)系通過對應(yīng)鏈表節(jié)點Node(k)下的成員dataAddr進(jìn)行描述，dataAddr的數(shù)值按式(5)進(jìn)行計算：

(5)

式(5)中:buffStartAddr為動態(tài)緩沖區(qū)的首地址；dataLenthi為基于鏈表排序，第i個節(jié)點的有效數(shù)據(jù)長度。

3 測試數(shù)據(jù)的接收與保存

分布式測試管理器通過CAN中斷接收由各個測試節(jié)點上傳的測試結(jié)果。當(dāng)系統(tǒng)從CAN通訊局域網(wǎng)接收數(shù)據(jù)包信息成功后，從鏈表頭指針Com_Head開始逐個索引鏈表節(jié)點。若被索引鏈表節(jié)點的通訊標(biāo)識符tempNode->nodeID與CAN報文標(biāo)識符接收寄存器(CANxIDR0～CANxIDR3)當(dāng)中的報文標(biāo)識符信息相匹配，則根據(jù)該鏈表節(jié)點下的緩沖區(qū)地址映射tempNode->dataAddr進(jìn)行尋址，存放接收所得的數(shù)據(jù)幀信息。數(shù)據(jù)接收流程框圖如圖6。

系統(tǒng)的采樣周期由定時中斷的定時時長決定，當(dāng)定時器中斷到達(dá)時，系統(tǒng)向緩沖區(qū)末端添加時間信道信息構(gòu)成一個數(shù)據(jù)采樣點，并將之經(jīng)FRAM向Flash轉(zhuǎn)存。

4 功能驗證

為驗證該策略的有效性，在實驗室環(huán)境下搭建了如圖7所示的試驗驗證平臺。圖中左側(cè)為分布式測試管理器，其內(nèi)部包含一塊搭載高速FLASH存儲芯片的存儲板卡以收集數(shù)據(jù)，3塊CAN通訊板卡用于模擬測試網(wǎng)絡(luò)中的通訊節(jié)點，每塊通訊板卡均以3 ms為周期向CAN通訊網(wǎng)絡(luò)上傳單個通訊地址下的信號采樣結(jié)果，3塊通訊板卡可上傳具有60個不同通訊地址(0x01～0x3C)的報文信息。

圖7 試驗平臺

為了對該策略下的配置功能進(jìn)行充分驗證，在驗證過程中依據(jù)系統(tǒng)配置流程對系統(tǒng)測試資源(在配置功能中表現(xiàn)為測試設(shè)備)進(jìn)行重新配置，并根據(jù)所得結(jié)果下發(fā)底層配置協(xié)議，通過查看串口上傳的數(shù)據(jù)內(nèi)容以判斷底層配置功能是否正確執(zhí)行。

系統(tǒng)于初始狀態(tài)下共計包含48條測試信道，其中每4地址，所涉及的通訊地址范圍為0x01～0x0C。現(xiàn)通過配置功能在原始狀態(tài)的基礎(chǔ)上另行增加新的測試設(shè)備，并向其中增加測試信道，配置界面如圖8所示。

圖8 系統(tǒng)配置界面

通過為新測試設(shè)備設(shè)定與已有設(shè)備相同的通訊協(xié)議編號屬性以保證通訊協(xié)議版本一致。現(xiàn)新增共計48條測試信道，使系統(tǒng)信道總數(shù)達(dá)到98條。在保證對指定版本通訊協(xié)議中通訊地址引用完整性的原則下，為每4條新增信道指定相同的通訊地址，并按其在消息負(fù)載當(dāng)中的先后順序設(shè)置信道的字節(jié)號分別為0、2、4、6，以代表信道數(shù)據(jù)于消息負(fù)載字段當(dāng)中的位置偏移。配置完畢后，系統(tǒng)可處理在0x01～0x18通訊地址范圍下的測試數(shù)據(jù)。

將系統(tǒng)在原始狀態(tài)下和配置后的狀態(tài)下從串口所獲取的測試結(jié)果進(jìn)行對比，對比結(jié)果如圖9所示。結(jié)果表明：經(jīng)配置后的系統(tǒng)可成功接收并處理對應(yīng)通訊節(jié)點上傳所得的測試數(shù)據(jù)，即該策略具備工程上的可行性。

圖9 配置前后的系統(tǒng)串口數(shù)據(jù)接收對比

為驗證該策略下系統(tǒng)的配置效率，本文統(tǒng)計并對比基于傳統(tǒng)的配置操作和基于動態(tài)配置策略的配置操作在配置同一測試項目時所消耗的平均時間長度。傳統(tǒng)的配置操作過程普遍包含測試裝置拆卸、調(diào)試裝置連接、運行編程環(huán)境及編程工具、代碼編寫、功能的調(diào)試驗證以及測試裝置的重新安裝部署等。相比之下，本文所提出的動態(tài)配置過程完全是在線進(jìn)行的，故統(tǒng)計時僅考慮測試人員在熟悉配置操作流程的情況下，通過上位機(jī)平臺當(dāng)中配置界面進(jìn)行實際配置操作所消耗的時間。

所選擇的測試項目為底盤總成溫度測試，該項目一般包含25～35條測試信道，在保持項目類型不變的前提下取常見值26、32和35對其進(jìn)行配置測試?；趦煞N不同的配置操作，對每種常見值下的目標(biāo)項目分別進(jìn)行3次配置操作并統(tǒng)計其消耗的平均時間長度。統(tǒng)計結(jié)果表明：基于傳統(tǒng)配置操作在配置上述數(shù)量信道的項目時所消耗的平均時間分別為8.3 h、8.5 h以及8.6 h，而基于動態(tài)配置操作所消耗的平均時間分別為1.9 h、2 h以及2.1 h。由此可得，本文所提出的動態(tài)配置策略可有效提高分布式ATS的配置效率。

5 結(jié)論

本文提出了一種車載分布式ATS系統(tǒng)動態(tài)可配置實現(xiàn)策略。該策略通過測試資源建模、配置協(xié)議實時下發(fā)以及存儲映射的動態(tài)重建實現(xiàn)了車載分布式ATS的快速配置自適應(yīng)，解決了傳統(tǒng)車載分布式ATS測試任務(wù)切換難、功能擴(kuò)展成本高、無法實現(xiàn)在線動態(tài)配置的缺陷。經(jīng)多次測試結(jié)果表明：該策略具有可行性并能有效提升車載測試系統(tǒng)的靈活性與應(yīng)變能力。