基于CAN 驅動庫的CAN 虛擬設備

文/吳效威 唐懷棟 喬海強 張臻 李茁

通常在CAN 通信程序開發過程中，開發人員經常需要對程序進行仿真及調試。一般情況下，開發人員通常會采用硬件USB 轉CAN板卡來進行CAN 通信程序的仿真或調試工作。USB 轉CAN 板卡一般具備2 個CAN 口供開發人員使用，若通過在Windows 環境下編譯的CAN 通信應用程序打開USB 轉CAN 的0或者1 通道，此時若需通過CANTest 應用終端監聽CAN 通信設備之間的報文，則會出現CANTest 應用無法正常打開USB 轉CAN 設備的1 或0 通道現象出現，該現象即應用程序對USB 轉CAN 設備操作的獨占性，仿真或調試過程中由此現象導致硬件資源出現浪費的現象時有發生 。

通常情況下，上述問題可通過2 塊USB轉CAN 設備并聯方案解決，但是對硬件資源產生了巨大的需求及浪費，經濟性較差。理論上若應用程序在使用CAN0 的同時使用CAN1充當CAN Test 軟件，二者之間進行報文交互，即可模擬應用程序CAN 通信測試功能，但是在應用程序中內置CAN Test 軟件的功能，會造成應用程序架構的冗余，對程序的穩定性和可靠性都會產生影響。

針對上述問題，本文提出了一種基于CAN 虛擬設備的方法，通過對CAN 虛擬設備制作及多CAN 設備及其通道自由連接方法的分析及研究，將虛擬CAN 接口函數和VC 界面相結合，開發了一種CAN 虛擬設備。在無USB 轉CAN 條件下，通過CAN 虛擬設備即可完成即可實現在編寫應用程序的過程中對程序CAN 通信功能的測試，有效降低了測試環境搭建所需硬件資源及所需投入成本。

1 CAN虛擬設備設計方案

CAN 虛擬設備主要由操作界面部分和接口函數兩部分組成。

1.1 操作界面

為了實現對多個CAN 設備及其通道進行自由連接，需對CAN 虛擬設備操作界面進行詳細設計。

如圖1所示，該操作界面共包含8 個CAN 設備，在操作界面的第一行表示，設備索引號從左到右依次是0 到7；每個CAN 設備均有2 個CAN 通道，從左到右的通道號分別是0 和1。其中黑框框起來的CAN 設備表示該設備已經被其他程序打開，CAN 通道變成黃色表示該通道已經完成比特率和濾波等參數設置，白色表示未設置。CAN 通道下面延伸出的黑色、灰色的豎線，表示CAN 通道的狀態。如圖所示，索引0 的通道0，以及索引1 的通道0，下部均延伸出雙黑線，表示0 通道已經正常打開，可以進行正常發送和接收；索引2 的通道0，下面延伸出單黑線，表示該通道設置為“只聽”模式，可以進行接收，但無法進行發送，也無法對收到的報文進行回應；其他通道都是雙灰線，表示無應用程序使用。

界面的主體有大量的彩色、黑色的雙橫線，以及處在橫豎線交叉點上的指示塊，指示塊的顏色與所在的雙橫線顏色保持一致。彩色的雙橫線共8 條，若各通道對應的指示塊均落在同一根彩線上，表示的上述通道是相連的，并且該條線上所有指示塊之間的連線為了單條粗實線表示；黑色的雙橫線共1 條，各通道對應的指示塊若落在黑色雙橫線上時表示通道為鎖死狀態（既不能自發自收，也不和其他通道相連）。另外，若出現一條彩線上只有1 個指示塊的時，表示與該指示塊對應的通道是孤立的（可以自發自收，但與其他通道不相連）[3]。

根據上述界面可知，共提供了8 個CAN虛擬設備，共計16 個CAN 通道，每個CAN網絡至少需要2 個CAN 通道，所以我們通過上述8 條雙橫線上各通道對應指示塊的組合即可實現這16 個CAN 通道進行任意的連接組合，針對需要孤立的通道，可通過將其對應的指示塊與黑色雙橫線連接即可。

針對調試過程中出現主動停止調試，或者程序崩潰等現象，均可導致設備被永久占用，界面設計時提供一個解鎖功能，通過鼠標點擊界面的第一行任何一個設備，即可以解除占用。上述操作界面只允許出現一個，因此檢測到新程序后，舊程序自動退出。完成操作界面之后，生成的程序命名為

“connect_can.exe”。

1.2 接口函數設計

為了實現報文收發，需要編寫動態庫，并提供接口庫函數，共計14 個，其中大部分函數作用均為實現對CAN 設備的控制，譬如開關狀態的轉換、比特率設置和濾波設置等，僅需對參數合法性驗證簡單處理即可。VCI_Transmit 為核心庫函數，該函數發出的報文可由VCI_GetReceiveNum，VCI_ClearBuffer，VCI_Receive 來處理。每個通道均具有相對應的接收緩沖區，從而實現將報文從其中一個CAN 通道傳遞至其他CAN 通道。虛擬CAN的各個函數，不僅需支持進程內部的多線程操作，而且需要支持跨越多個進程之間的操作。為了便于操作，可采用進程間共享內存的方式，對緩沖區進行操作。發送函數需獲得與之相連接的設備及其設置參數方可實現發送功能。操作界面和動態庫之間需通過內存共享來實現數據共享。不論多線程或者單線程，為了確保線程安全，對緩沖區的操作前需進行加鎖設置，操作完成后解鎖，防止出現多個線程同時對同一個緩沖區操作導致的非法狀態，可采用標準庫中的標準原子操作實現加鎖操作。

針對發送函數，主要需作如下處理：

（1）必須對參數進行驗證，任何一個參數無效均返回0，表示失敗。

（2）確定設備是否已經打開、通道是否已經掛在彩色的雙橫線上、通道是否已經初始化、通道是否工作于非只聽模式、通道是否已經打開，其中任何一個不滿足，均返回0。鑒于函數均有返回值，在通過上述驗證工作后，通過變量（初始值為0）對成功發送的報文數量進行計數，對所有CAN 通道進行遍歷，并對每個CAN 通道進行相應處理。對于每一條報文，都要定義一個發送成功標志，這個標志初始值為假，然后遍歷各個目標通道。遍歷目標通道時，首先對發送方和遍歷目標進行比較：對于不是“自發自收”類型的報文，發送方和遍歷目標不同，才能通過；反過來，對于是“自發自收”類型的報文，只有發送方和遍歷目標一致，才能通過。對遍歷目標繼續判斷：它所在的設備必須已經打開；通道必須已經初始化并打開；必須掛在和發送方相同顏色的雙橫線上；它的比特率必須與發送方的一致。接下來要討論目標的運行模式，是正常模式還是只聽模式。不論是什么模式，都只是影響發送成功標志，而不會影響對方的接收。對正常模式，將發送成功標置為真。然后不論是正常模式還是只聽模式，都可以進行后續處理。

圖1：CAN 虛擬設備操作界面

圖2：默認連接方式

（3）進行接收方的驗收濾波處理。驗收通過后數據存入目標的緩沖區，驗收不通過放棄數據。不論驗收是否通過，對之前的發送成功標志均無影響。對緩沖區的操作前需進行加鎖處理，完成后進行解鎖。一般情況下，緩沖區的容量均有限，若在緩沖區存儲已滿下仍繼續接受報文，則易產生數據丟幀現象。可采用報文最新收到的數據，丟棄歷史數據的處理方法進行處理。當全部目標遍歷完成后，即可對報文的發送成功標志位進行置位：若標志位為假，程序直接終止后續處理，直接返回發送成功報文數量；若標志位為真，報文發送成功數量自加1。

該程序的核心是對報文傳遞的驗證操作，在實現上述14 個接口函數后，生成動態庫“virtual_can.dll”。

2 虛擬設備使用方法

當使用虛擬CAN 時，將動態庫“virtual_can.dll”重新命名為“controlcan.dll”，并放置在與應用程序相同的路徑下，替換掉原來的同名文件。在Debug 模式下使用虛擬CAN，在Release 模式下使用USBCAN，僅需設置好各自的工作目錄即可，同時將“virtual_can.dll”改名為“controlcan.dll”的動態庫放置在Debug 模式的工作目錄中，將“usbcan.dll”改名為“controlcan.dll”的動態庫放置在Release模式的工作目錄中。完成上述操作即可實現“VCI_USBCAN2”在應用程序中的設備類型中的統一使用。

對于CAN Test 工具，則需要對工具下的配置文件進行修改處理。如上所述，首先為工具的安裝路徑下的“cfg.ini”文件，該文件會影響界面的菜單。改完之后保存；然后打開安裝路徑下的“kerneldlls”目錄，將制作好的“virtual_can.dll”動態庫復制到該目錄下；最后修改這個目錄下的“kerneldll.ini”文件，修改完成后保存。

將“connect_can.exe”文件放置在任意路徑中即可，打開這個文件即可顯示操作界面。為了使用者方便，該界面默認狀態下的連接方式如圖2所示。

打開CAN Test 軟件，點擊“選擇設備”按鈕，即可看到虛擬CAN 的菜單項了，打開之后即可進行正常使用。

另外，根據圖2所示默認連接方式，用戶也可通過直接打開應用程序和CAN Test 軟件方式來使用虛擬CAN 設備。用戶可以隨時打開操作界面，對連接方式進行修改，也可以隨時關閉操作界面，以節省打開窗口的數量。與虛擬CAN 有關的所有進程，包括操作界面、使用到虛擬CAN 的應用程序、使用到虛擬CAN 的CAN Test 軟件，全部關閉之后，共享內存會由操作系統釋放，因此連接方式的配置會消失，重新打開后會恢復默認連接方式。

3 實驗結果與分析

打開4 個CAN Test 軟件界面，每個界面下打開2 塊虛擬CAN，每個虛擬CAN 的兩個通道都打開，然后在操作界面 將全部的16 個通道連接在一起，每個通道連續發送10 萬條報文，同時發送不會丟幀，每個通道都收到了150 萬條報文。

4 結論

本文針對Windows 操作系統環境下采用USB 轉CAN 設備進行應用程序CAN 通信測試存在的一些問題，提出了一種CAN 虛擬設備設計及測試方法。通過CAN 虛擬設備，在無需USB 轉CAN 輔助硬件設備條件下即可實現對Windows 操作系統環境下編譯的應用程序CAN 通信功能測試，實驗結果再次表明了該方法的有效性和可行性。該方法減少了搭建硬件測試環境工作量，有效降低了測試所需的硬件成本，具備較好的經濟性。