車載分布式ATS動態可配置實現策略研究

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

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

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

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

1 設計思想概述

本文提出的車載分布式ATS動態可配置實現策略，基于測試系統“生產者-消費者”的開發模式，在保持實現測試功能所必須的基本環節與業務形態不變的前提下，充分考慮測試前端可變對系統造成的影響，對其進行動態適配性設計。

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

圖1 設計用例簡圖

2 分布式ATS動態可重構設計

2.1 通訊平臺設計

為實現硬件通訊平臺的動態可重構，本文基于開放式現場總線技術，通過車載CAN通信局域網和分布式測試管理器構建分布式ATS的硬件通訊平臺，其系統組成結構框圖如圖2。

圖2 硬件通訊平臺結構框圖

CAN協議規范定義了OSI開放式互聯模型中的物理層、數據鏈路層以及應用層，使得在保證系統開放可擴展的基礎之上簡化其組成，提高開發與運行效率。網絡總線物理層采用雙絞線作為通訊介質，信號以差分電壓的形式進行傳輸[9]。所有測試前端設備與分布式測試管理器通過內部CAN總線彼此互聯，構成分布式測試局域網。

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

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

2.2 測試資源建模

對測試節點信息模型化、結構化的管理方式為系統實現測試資源動態可適配提供了軟件層面的可能。設計通過數據字典組織測試節點的屬性信息，并建立測試資源模型，建模原理示意圖如圖3。

圖3 測試資源模型示意圖

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

SysResource={Node1,Node2,…,Noden}

(1)

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

Node=(NodeID,FramBytesLenth,TestBusiness)

(2)

其中:NodeID為通訊標識符；FramBytesLenth為該節點所上傳的數據幀字節長度；TestBusiness為該測試節點所具有的測試業務。在此以信道代表測試節點上單個信號采集端口的業務實現，每個節點所包含的測試業務可描述為

TestBusiness={Ch1,Ch2,…,Chn}

(3)

模型當中對信道的描述形式為

Channel=(ChID,SigType,CaliModel,ValRange,

ByteLenth,Precision)

(4)

其中:ChID為該信道的標識符；SigType為端口信號類型；CaliModel為該信道測試所得數據的標定方式，在系統上位機當中對應于不同的數據標定業務與相關參數，以實現測試數據的處理與解析適配；ValRange表示該信道的值域范圍；ByteLenth為該信道的數據字節長度；Precision代表測試精度。

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

2.3 存儲映射的重建

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

本設計當中對系統進行動態適配的主要工作將集中于重建通訊節點與數據緩沖區地址之間的映射。

系統上位機根據測試資源模型提供的有效信息長度描述生成底層配置協議，配置協議格式如表1所示。協議當中的測試節點表示CAN測試局域網當中具備測試數據上傳業務、并通過CAN通訊ID進行標識的通訊對象；每個測試節點下所包含的配置描述信息包括該節點的通訊ID、該節點所上傳的有效信息長度、信道數量以及信道的字長。

表1 通訊協議配置信息

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

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

圖4 配置協議與鏈表節點關系示意圖

鏈表節點Node(k)通過數據結構COM_NODE實現，其內容按如下方式定義：

typedef struct

{

byte *dataAddr;

unsigned short nodeID;

unsigned short dataLenth;

unsigned short chelCount;

unsigned short chelLenth;

struct COM_NODE *next;

}COM_NODE

其中，*next代表下一個鏈表節點Node(k+1)的存放地址；nodeID為該鏈表節點所對應通訊節點的ID標識符；dataLenth為對應通訊節點上傳數據幀當中有效數據的總長；chelCount為上傳數據幀當中所包含的信道數量；chelLenth為信道的字節長度。基于設計當中所采用的CAN通訊協議，其數據幀最大有效數據長度為8 Byte，設計將信道長度統一定義為2 Byte，則每個通訊節點上傳的數據幀當中最多包含4條有效信道。動態緩沖區當中，由通訊節點上傳所得的測試數據按鏈表節點的先后順序連續分布，如圖5所示。

圖5 存儲緩沖區結構

第k個測試節點于動態緩沖上的映射關系通過對應鏈表節點Node(k)下的成員dataAddr進行描述，dataAddr的數值按式(5)進行計算：

(5)

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

3 測試數據的接收與保存

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

系統的采樣周期由定時中斷的定時時長決定，當定時器中斷到達時，系統向緩沖區末端添加時間信道信息構成一個數據采樣點，并將之經FRAM向Flash轉存。

4 功能驗證

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

圖7 試驗平臺

為了對該策略下的配置功能進行充分驗證，在驗證過程中依據系統配置流程對系統測試資源(在配置功能中表現為測試設備)進行重新配置，并根據所得結果下發底層配置協議，通過查看串口上傳的數據內容以判斷底層配置功能是否正確執行。

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

圖8 系統配置界面

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

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

圖9 配置前后的系統串口數據接收對比

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

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

5 結論

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