【摘 要】
智能駕駛的整車控制部分需要采用AUTOSAR框架進行開發，以滿足高實時性以及高級別的功能安全需求。在本文中，通過采用AUTOSAR框架中網絡管理的實現方式，對網絡管理報文的格式進行定義，并描述CAN網絡休眠與喚醒的狀態轉換、網絡喚醒狀態中各個子狀態的切換、CAN Bus-off狀態下的處理策略以及非正常電壓模式下的處理策略等。在CANoe上對網絡管理功能的策略進行驗證，測試結果表明能夠實現AUTOSAR網絡管理的各項功能。
1 引言
近些年來，智能駕駛相關技術在世界范圍內獲得廣泛關注和蓬勃發展。智能網聯汽車是指搭載各傳感器、控制器、執行器等裝置，融合現代通信與網絡、人工智能等技術，實現車與X（車、路、人、云等）智能信息交換、共享，具備復雜環境感知、智能決策、協同控制等功能，可實現 “安全、高效、舒適、節能”行駛，并最終可實現替代人來操作的新一代汽車[1-2]。美國高速公路管理局（NHTSA）發布了對自動駕駛各個級別的定義：Level 0代表人工駕駛，Level 1代表輔助駕駛，Level 2代表部分自動駕駛，Level 3代表條件自動駕駛，Level 4代表完全的自動駕駛。對于高級別自動駕駛，對控制器硬件以及基礎軟件的要求相對要高。高度自動駕駛級別的域控制器系統架構如圖1所示。
圖1 自動駕駛域控制器系統架構
數據融合與處理部分既要求實時性和一定的功能安全級別，又要求基礎軟件能管理更大內存，需要有文件系統的支持，因此采用具有文件系統的實時操作系統框架進行開發。整車控制部分需要基礎軟件具有高實時性以及高級別的功能安全需求，因此采用車控基礎軟件AUTOSAR框架進行開發[3]。AUTOSAR是由各大汽車制造廠商、零部件供應商、汽車電子、半導體和軟件系統公司于2003年聯合推出的一個開放的、標準化的軟件架構。該架構專門應用于汽車電子領域，嘗試通過增加軟件模塊的重用和互換，來降低系統軟件架構的復雜度，從而優化整個軟件的開發流程。滿足AUTOSAR框架的基礎軟件，具有可移植、可擴展、高實時、高可靠、滿足功能安全要求等特點[4]。本文采用基于AUTOSAR架構的網絡管理，在汽車CAN系統中進行實現，并在CANoe上對網絡管理的各功能進行仿真驗證[5]。
2 AUTOSAR CAN網絡管理報文格式
在網絡管理中，網絡中的各個節點通過網絡管理報文進行通信，AUTOSAR CAN網絡管理報文的數據場格式見表1。
表1 網絡管理報文的數據場格式
表1中，字節0為ECU Address，作為源節點標識符，用以告知其他節點該報文是由哪個節點發送的；處于CAN網絡中的每個節點都會分配一個唯一的標識符，本文中網絡管理報文的ECU Address=0x439。字節1為控制比特向量，字節2～7為用戶自定義的數據信息。本文中字節2User date 0用于將網絡喚醒原因顯示出來，其他自定義數據作為擴展保留，用“0x00”填充。表2列出了控制比特向量各位的含義。其中Bit0為重復報文狀態請求位，置1代表需進入重復報文發送狀態，清零代表不再需要重復報文發送狀態；Bit4位為激活喚醒位，置1代表主動喚醒狀態，清零代表被動喚醒狀態。其他位為保留位，以0填充。
表2 控制比特向量格式
3 網絡管理的策略實現
3.1 網絡休眠與喚醒
AUTOSAR網絡管理包含3個主要狀態：總線休眠狀態、預休眠狀態和喚醒狀態。當網絡節點滿足休眠條件，不需要進行CAN通信時，進入總線休眠狀態。網絡處于總線休眠狀態可以降低車輛電量消耗。一般情況下，當節點上電之后默認進入總線休眠狀態，當在總線休眠狀態接收到應用程序喚醒需求或者網絡通信需求時，節點從總線休眠狀態進入喚醒狀態。當在喚醒狀態下再次滿足休眠條件時，節點首先進入預休眠狀態，從預休眠狀態延時一段時間再進入總線休眠狀態。在預休眠狀態下，節點停止網絡管理報文和應用報文的發送，但是可以進行ACK的應答活動，用以監控總線網絡需求。當定時器到時進入總線休眠狀態后，關閉總線活動。3個主要網絡狀態的轉移過程如圖2所示。
圖2 網絡休眠與喚醒狀態處理策略
3.2 網絡喚醒狀態
當總線處于網絡喚醒狀態時，包含3個子狀態：重復報文狀態、正常模式狀態和休眠準備狀態。而重復報文狀態又包含報文快速發送狀態和正常發送狀態兩種。如上文提到，當在總線休眠狀態接收到應用程序喚醒需求或者網絡通信需求時，節點從總線休眠狀態進入喚醒狀態。當接收到應用程序喚醒需求時，節點進入重復報文狀態中的報文快速發送狀態，當接收到網絡通信需求時，節點進入重復報文狀態中的報文正常發送狀態。當節點進入報文快速發送狀態時，會開啟定時器，當定時器到時后，節點從報文快速發送狀態進入報文正常發送狀態。節點進入重復報文狀態后會開啟另一定時器，定時器到時后，節點從重復報文狀態退出。當網絡需要繼續進行CAN通信，節點從重復報文狀態進入正常模式狀態。當網絡不再需要進行CAN通信，節點從重復報文狀態進入休眠準備狀態。在正常模式狀態下，若需要與網絡上的其他節點繼續通信時，需要保持在正常模式，若不再需要網絡通信，節點從正常模式狀態進入休眠準備狀態。進入休眠準備狀態后需要停止網絡管理報文和應用報文的發送。網絡喚醒狀態的轉移過程如圖3所示。
圖3 網絡喚醒狀態處理策略
3.3 CAN Bus-off狀態
CAN網絡管理需要考慮Bus-off狀態下的處理策略。當檢測到總線處于Bus-off狀態時，停止網絡報文和應用報文的發送，并開啟定時器BusOffRecoveryCounter。定時器大小由Bus-off具體的快慢恢復策略決定。當定時器到時后，網絡進入喚醒狀態。若Bus-off狀態進入之前網絡已經處于喚醒狀態，則退出Bus-off狀態后，具體進入喚醒狀態的哪個子狀態由之前的歷史狀態確定。
3.4 電壓狀態
網絡管理需要在正常電壓模式下進行工作。當總線處于總線休眠狀態或者預休眠狀態時，檢測到應用程序的喚醒需求或者網絡通信需求時，需要確認當前電壓處于正常電壓狀態才會退出當前狀態，進入網絡喚醒狀態。當總線處于網絡喚醒狀態時，檢測到電壓處于過低或過高電壓狀態，則退出網絡喚醒狀態進入預休眠狀態。
3.5 網絡管理的策略實現
在上述策略中詳細描述了網絡管理的狀態轉移過程，本文通過Stateflow的狀態機進行實現，程序中的具體策略如圖4所示。
圖4 AUTOSAR網絡管理處理策略
4 測試
網絡管理策略實現之后，在CANoe上對其功能進行驗證測試。接收到本地喚醒需求時的測試結果如圖5所示，待測試節點ID為0x439。當接收到本地喚醒事件后，節點0x439從總線休眠狀態進入網絡喚醒狀態中的報文快速發送狀態，以20ms的發送周期快速發送網絡管理報文，發送完成10幀網絡管理報文后，報文快速發送狀態定時器到時，進入到正常發送狀態，按照500ms的發送周期發送網絡管理報文。
圖5 本地喚醒策略測試結果
接收到網絡通信需求時的測試結果如圖6所示，待測試節點ID為0x439。當被網絡中的0x43A節點喚醒后，節點0x439從總線休眠狀態進入網絡喚醒狀態中的正常發送狀態，并發出第1幀網絡管理報文，之后按照500ms的發送周期發送網絡管理報文。發送完成3幀網絡管理報文后，正常發送狀態定時器到時，進入到正常模式狀態，正常模式狀態與重復報文狀態中的正常發送狀態報文周期相同，同樣按照500ms的發送周期發送網絡管理報文。
圖6 網絡喚醒策略測試結果
5 結論
在本文中，介紹了基于AUTOSAR標準的域控制器進行網絡管理的實現過程，包括AUTOSAR CAN網絡管理報文格式，網絡休眠與喚醒的狀態轉換、網絡喚醒狀態中的各個子狀態的切換、CAN Bus-off狀態下的處理策略以及非正常電壓模式下的處理策略等，通過Stateflow的狀態機進行實現，并在CANoe上進行了驗證。測試結果表明所述策略能夠實現網絡管理的各項功能。
參考文獻：
［1］節能與新能源汽車技術路線圖戰略咨詢委員會，中國汽車工程學會.節能與新能源汽車技術路線圖（智能網聯汽車技術路線圖專題）[M].北京：機械工業出版社，2020.
［2］中國智能網聯汽車產業創新聯盟，華為技術有限公司，中國汽車技術研究中心有限公司，等.智能網聯汽車產品測試評價白皮書（2020年）[C]//CICV 2020，10：5.
［3］張曉謙，李巖，孫忠剛，等.智能汽車綜合控制系統基礎軟件架構分析［J］.汽車零部件，2016（12）：74-76
［4］PELZ G，OEHLER P，FOURGEAU E，et al.Automotive System Design and Autosar［J］.Springer US，2004：293-305.
［5］戎輝，王曉靜，汪春華，等.基于OSEK標準的直接網絡管理功能的策略實現［J］.電子測量技術，2017，40（2）：162-165.
轉自智能汽車設計
