Windows 10 ARM工控主板CAN總線實時性能測試
在常規的Windows系統中支持CAN總線應用，需要外接CAN總線適配器，通常為USB轉CAN模塊或PCI接口CAN卡。實時性本身是CAN總線的顯著特性之一，但由于Windows并非實時操作系統，應用程序容易受到系統CPU負載影響，導致調度周期不確實，這就限制了CAN總線在Windows系統中的應用。
英創公司推出的名片尺寸Windows工控主板ESM8400，其核心是基于NXP的iMX8MP 4核ARM64 MPU，安裝Windows 10 IoT企業版操作系統，Windows 10 IoT企業版就是完整版本的Windows 10，而且支持軟實時特性。ESM8400自帶兩路CAN總線接口，結合Windows 10 IoT企業版的軟實時特性，可以實現可靠的10ms(甚至更小)循環周期調度，這使得ESM8400可作為軟實時IPC直接應用于對控制周期有嚴格時序要求的控制回路中，以觸發狀態機的行為，然后通過CAN總線調度較小的硬實時控制單元。
本文將介紹基于安裝Windows 10 IoT企業版的ESM8400 CAN總線實時應用的測試目標、測試方法，以及對測試數據進行統計與分析。對于開發實時應用程序的具體編程細節將在單獨的一篇文檔中進行說明。
1、測試目標
模擬工業自動化現場實際應用，在ESM8400應用程序中生成10ms的固定循環周期，在每個循環周期內調用CAN接口以250kBits/s波特率連續發送6幀數據。最終統計分析兩個時間指標：
1、10ms循環周期在各種軟件配置、以及各種CPU負載情況下的實際最大時間是多少。
2、在各種工況下連續發送6幀CAN數據的耗時情況，并統計最長耗時。
2、測試方法
2.1 硬件環境
ESM8400評估底板直接支持1路CAN總線接口，通過PCAN模塊(USB轉CAN)連接到計算機。測試時需要注意短接評估底板上的CAN總線匹配電阻跳線器。
2.2 PCAN-View
PCAN-View是PCAN模塊對應的Windows應用程序，PCAN-View可以記錄接收的CAN數據，同時可記錄每幀數據的時間戳，時間戳精度為0.1ms。時間戳由PCAN模塊自身標記，不會受測試計算機軟件系統調度問題所影響。所以利用接收到的CAN數據時間戳，可以對各項時間指標進行精確的統計。
2.3 測試程序
ESM8400上運行的測試程序利用Windows系統的高精度定時器QPC實現10ms的循環定時，每個循環周期內連續發送6幀CAN數據，測試發送12W幀CAN數據(2W個循環)后程序退出。下面是測試程序的主要代碼，關于ESM8400 CAN接口在Windows中的使用細節，將在另一編文檔中進行說明。
CFlexCAN can;
flexcan_frame_t frame;
volatile BOOLEAN txComplete = TRUE;
LARGE_INTEGER frequency;
LARGE_INTEGER end, last;
// 設置本進程優先級
// SetPriorityClass(GetCurrentProcess(), REALTIME_PRIORITY_CLASS);
// 將本進程設置為僅在CPU3, CPU4上運行
// SetProcessAffinityMask(GetCurrentProcess(), (1 << 3) | (1 << 2));
// 打開ESM8400 CAN1,波特率設置為250kBit/s
can.Open(1, 250000);
// 獲取QPC的頻率
result = QueryPerformanceFrequency(&frequency);
// 計算10毫秒對應的QPC計數，減去1是為了補償可能的調度延遲
LARGE_INTEGER interval = { frequency.QuadPart / 100 - 1 };
QueryPerformanceCounter(&last);
end = last;
while(1){
// 等待直到達到或超過預定的10毫秒間隔
do {
QueryPerformanceCounter(&end);
} while ((end.QuadPart - last.QuadPart) < interval.QuadPart);
// 更新上一次循環結束的時間
last = end;
// 連續發送6幀CAN數據，每幀的CAN ID從1到6
for (int i = 1; i < 7; i++) {
frame.mfs_1.id = i;
can.Write(&frame);
while (!can.txComplete) {};
can.txComplete = FALSE;
frame.mfp.mfp_w.dataWord1++;
// 此處可進行其它操作，注意代碼執行時間不要超過循環定時
// 每個循環發送6幀，發送超過12W幀(2W個循環)后退出程序
if (frame.mfp.mfp_w.dataWord1 > 120010)
break;
}3、進行測試
3.1 測試項目
將測試程序分別設置為Normal和Realtime優先級類，在CPU空閑和CPU負載75%的情況下，測試程序運行于Windows 10標準模式和軟實時環境進行了6個項目的對比測試。
測試項目 | CPU負載 | Windows 10 系統模式 | 進程優先級類 |
1 | 空閑 | 標準模式 | Normal |
2 | 75% | 標準模式 | Normal |
3 | 75% | 標準模式 | RealTime |
4 | 空閑 | 軟實時模式， 3個標準CPU + 1個實時CPU | RealTime |
5 | 75% | 軟實時模式， 3個標準CPU + 1個實時CPU | RealTime |
6 | 75% | 軟實時模式， 3個標準CPU + 1個實時CPU | RealTime |
對于測試項目的進一步說明：
1． ESM8400的處理器i.MX8MP有4個CPU核心，在Windows標準模式下，測試程序由系統自動調度在某個CPU上運行。在3+1軟實時模式下，應用程序通過SetProcessAffinityMask函數設置當前進程在CPU4(實時核心)上運行，在2+2軟實時模式下，通過SetProcessAffinityMask函數設置當前進程在CPU3和CPU4上運行。
2． 測試程序進程優先級類由SetPriorityClass系統API配置為NORMAL_PRIORITY_CLASS或REALTIME_PRIORITY_CLASS。
3． 測試時利用CPU Stress程序為系統增加75%的高優先級 (HIGH_PRIORITY_CLASS)負載。
4． 在啟用的Windows 10 軟實時的情況下，可以看到在CPU Stress中增加的75%負載，Windows系統分別施加到了CPU1~CPU3上，不占用CPU4資源，這就是Windows IoT企業版的軟實時特性之一——CPU隔離技術的體現。(下圖中為1個實時核心 + 3個標準核心)
3.2 數據統計與分析
每個測試項目執行2W次循序，得到12W幀、帶精度為0.1ms時間戳的CAN數據，將6個測試超過72W幀數據導入Excel。
如前面的測試程序所示，每個循環發送的第1幀CAN數據的ID為1，最后第6幀CAN ID為6，這里利用每一個ID為1的CAN幀時間戳、統計10ms循環的實際最大時間，利用ID為1和6的CAN幀時間戳計算連續發送6幀CAN數據的實際耗時。統計結果如下：
1. 各工況下CAN數據發送的耗時情況
CAN總線在250kBit/s波特率下，理論上每秒最多能傳輸約2300個CAN標準幀，傳輸6個標準幀的最短時間理論上需要約2.6ms。分別統計發送6幀數據耗時在3ms內、3ms~6ms之間、6ms~9ms之間以及耗時超過9ms的次數。
從上面的統計結果可以看到：
a) Win10標準模式下，如果不對應用進程優先級作任何設置，即使CPU空閑，也有一次發送時間超過9ms，當CPU負載增加時，CAN的發送時間變得很不確實，接近1000次發送時間超過9ms。
b) 在Win10標準模式下，無論CPU負載如何，發送耗時都小于等于6ms。唯一在CPU負載75%時，有一次耗時處于6ms~9ms之間，根據原始數據查得這次耗時為6.1ms。
c) 在分配2個實時核心的情況下，發送實時性要好于1個實時核心。這是因為測試程序實際上有兩個線程：一個主循環線程；一個完成端口線程，用于為發送結果提供異步通知。
d) 在Windows標準模式下，將應用程序設置為實時進程，得到了最好的實時性能，這將在稍后的測試總結中進一步說明。
2. 最大時間統計
通過統計發送6幀數據的最長耗時，以及統計10ms周期的實際最大時間更能直觀的反應系統在各個工況下的性能表現，和可預測性。
4、測試總結
在Windows標準模式下，如果不對應用進程優先級做特別設置，程序的調度響應時間將很不確定，在本次測試中，原本10ms的循環定時周期實際上最長測得為160ms。
在Windows標準模式下，提高進程優先級可顯著提高響應的實時性，但需要注意的是在標準模式下， Windows線程可以被調度到任意CPU上，Windows的音頻驅動、SysMain、DPS等后臺服務可能會在某一時間對關鍵應用程序造成影響，這會增加系統的不可預測性。
在ESM8400上啟用Windows的軟實時特性，對多核CPU進行隔離應用，將關鍵應用進程固定在實時CPU上運行，能得到可預測的實時性能，具備在對控制周期有嚴格時序要求的使用場景中應用的能力。