基于μC／OS-Ⅱ的線控轉向FlexRay通信控制
加入技術交流群
以Freescale公司開發的針對該芯片的FlexRay通訊傳輸層和表示層的驅動程序為基礎，進行應用層的程序設計，即編寫通信任務程序，完成協議的運行過程。
3．2．1 FlexRay通信啟動任務
按照上文介紹的FlexRay協議中定義的協議運行過程，當對FlexRay通信進行初始配置后，協議將進入就緒狀態，之后發送啟動節點命令等待協議狀態由啟動狀態變為正常主動狀態；在正常主動狀態中，首先發送關鍵幀啟動網絡中的其他節點，發送完成后進入到節點喚醒狀態，然后開啟FlexRay通信的各種中斷，包括：傳輸中斷、接收中斷、存儲區中斷以及定時器中斷等，最后掛起任務等待檢測到通信故障時進行喚醒；協議正常被動狀態是在通信出現故障時，重新配置協議，進行協議的重啟。需要注意的是用戶必須在多任務系統啟動以后再開啟時鐘節拍器，也就是在調用Osatart()之后，由任務優先級最高的那個任務開啟RTI中斷，否則系統容易死鎖。程序流程圖如圖2所示。本文引用地址：http://www.104case.com/article/197684.htm
3．2．2 數據接收發送任務
FlexRay數據的接收發送是通過中斷服務程序進行的，因此在該任務中，只需判斷POC狀態是否進入正常主動狀態，如果是則使用全局變量對接收函數Fr_receive_da()和發送函數Fr_transmit_data()的消息緩沖區進行數據的讀取和更新。
3．2．3 故障檢測任務
在通信過程中，當其他節點因故障重啟或是通信線路中斷時，可以利用故障檢測任務檢查POC狀態，當協議運行在正常被動狀態時，則判斷為通信線路出現故障，將故障LED指示燈設定為閃爍狀態；當協議運行在暫停狀態時，則判斷為節點控制器故障，故障LED指示燈設定為常亮狀態，并對FlexRay通信啟動任務進行解掛，重新對協議進行配置，待故障解決，系統可以自動啟動節點運行。程序流程圖如圖3所示。
4 實驗驗證
使用Vector公司的CANoe軟件，可以方便地觀察FlexRay總線上的數據流情況。實驗中，將CANoe軟件提供的FlexRay接口板VN3600接入總線網絡中，之后參考MC9S12XF512芯片手冊中FlexRay通信的MicroTick定義為25 ns，因此在FlexRay初始化定義中，設置參數P_MICRO_PER_M-ACRO_NOM為40，則一個MareroTick等于40個MicroTick，也就是說，FlexRay通信配置的基準時間片為lμs。據此，配置通信周期為5 000 μs；1個靜態時槽長度為24μs，共有91個；1個動態時槽為5μs，共有289個；特征窗與網絡空閑時間為1 371μs。
程序中對節點Node_A和Node_B的時槽定義如表2所示。
實驗結果如圖4所示，運行時間2 289 s，時槽變化與周期數均與設計一致，數據收發正常。由圖5可知，幀速率為3 200幀／s，總計傳輸7 369 600幀，沒有出現無效幀與錯誤幀，達到了實時性和穩定性的要求。
在通信過程中，分別進行故障模擬實驗。
(1)突然斷開總線來模擬應用現場出現線路故障的情況，可以發現數據停止更新，故障檢測LED指示燈閃爍，說明程序檢測到了線路故障問題并進行報警。當再次連接總線后，故障檢測LED熄滅，數據繼續更新，說明通信自動重新啟動。
(2)將任意一個控制器進行掉電，模擬單一控制器故障情況，可以發現數據停止更新，故障檢測LED指示燈開始常亮，說明程序檢測到了任意節點故障導致通信中斷的問題并進行報警。當再次開啟掉電控制器后，故障檢測LED熄滅，數據繼續更新，說明通信自動重新啟動。通過以上兩個實驗，驗證了故障檢測報警功能良好。
5 結語
針對線控轉向系統FlexRay通信過程中存在的問題，將實時操作系統μC／OS-Ⅱ應用于系統中，進行了代碼移植和通信任務設計。之后通過硬件實驗，對數據結果和故障檢測進行了測試，從實驗結果可以看出，該系統解決了FlexRay總線應用的復雜問題，并利用μC／OS-Ⅱ操作系統保證了系統實時性、穩定性和安全性的要求，為今后實現線控轉向系統在汽車輔助駕駛和智能駕駛方面的應用奠定了基礎。
評論