前言：尋找寫作靈感？中文期刊網用心挑選的車載電控OSEK網絡管理測試設備設計，希望能為您的閱讀和創作帶來靈感，歡迎大家閱讀并分享。
摘要：汽車電控單元ECU的數量在不斷增多，對于ECU的網絡管理測試需求猛增。手動測試及單個ECU網絡管理專用測試程序已經很難滿足測試需求，因此有必要設計一種通用性高、適用性廣的網絡管理自動測試設備。該測試設備基于OSEK/VDX網絡管理規范開發，硬件主要使用Vector工具鏈，如總線接口卡、電源管理模塊及VH6501等。測試設備通過CAPL編寫測試腳本，在CANoe環境下進行測試。通過開NM通信模型的方式，支持OSEK網絡管理單元測試或集成測試模式。
關鍵詞：OSEK；CAPL；NM通信模型；自動化測試
1前言
汽車技術在朝著電子化發展的過程中，車載ECU（ElectronicControlUnit，電子控制單元）的數量必然急劇增加。ECU通信過程中，為防止其他節點未在線或處于故障狀態而導致網絡信號的丟失，專門的網絡管理機制隨之出現［1］。網絡管理機制不僅能夠保證ECU間通信的穩定，也可以作為休眠喚醒的管理機制，使ECU適時地進入靜態功耗狀態［2］。汽車軟件標準OESK/VDX規范提供了兩種網絡管理機制，直接網絡管理和間接網絡管理，統稱OSEK網絡管理。間接網絡管理基本沒有節點間的通信控制邏輯，而直接網絡管理涉及較為復雜的測試邏輯，因此也是本系統測試的重點。OSEK網絡管理定義了NM通信報文，以特定ID作為與其他應用報文的區分，并為報文設定了特定數據內容。網絡管理（NetworkManagement，簡稱NM）測試主要關注NM報文格式、NM時間參數測試和NM管理邏輯測試。下文將會詳細討論OSEKNM的測試內容和方法。
2測試內容分析
通過分析OSEK網絡管理的需求規范，確定NM一致性測試的測試內容及方法。如圖1所示為OSEK網絡管理狀態跳轉示意圖，網絡管理狀態如下：NMOff、NMOn、NMShutDown，其中NMOn狀態下，又分為NMIinit、NMAwake、NMBusSleep三種子狀態，NMAwake又包含NMReset、NMNormal、NMLimpHome三種狀態。OSEK通過讓各節點建環的形式進行網絡的管理，如網段上包含A、B、C三個節點，則邏輯環為A-B-C-A，如此循環往復。為滿足NM通信需求，OSEK定義了3種NMPDU（網絡管理數據幀）：Alive、Ring、LimpHome報文，并定義了幾個重要時間參數，見表1。根據上述，可以設計一致性測試用例，本系統涵蓋50+條OSEKNM測試用例，覆蓋范圍廣泛，測試用例劃分為以下幾部分。
1）NM報文格式測試，如Alive報文格式、Ring報文格式、Limphome報文格式測試等。
2）NM時間參數測試：如T_Typ、T_Max、T_Error、T_WaitBusSleep等時間測試。
3）邏輯環測試：如邏輯環建立、異常Ring報文干擾等測試。
4）狀態跳轉測試：如Normal狀態下睡眠響應、Limphome狀態下睡眠響應、Limphome復位、睡眠中斷等測試?；谝陨蠝y試需求，本文設計了一套車載電控單元網絡管理自動化測試設備。設備以CANoe為軟件平臺，輔以針對測試而開發的osekNM通信模型，實現NM的自動化測試。較手動測試而言，該設備具有自動化程度高、通用性強、執行效率高等優點，通過NM通信模型的加入，可以模擬各種NM邏輯，使測試范圍覆蓋度遠遠高于手動測試。
3系統設計與實現
3.1測試系統設計
該測試設備基于測試內容設計，由測試執行軟件、硬件系統、NM通信模型、測試腳本4部分組成。測試執行軟件選用Vector公司的CANoe軟件。CANoe具有分布式系統設計、仿真、測試、評估等功能，支持CAN總線通信仿真模型編寫［3］。本設備應用到CANoe的CAPL編程環境，進行NM通信模型及測試腳本的開發。測試硬件系統包括總線接口卡、測試配置板卡、程控電源等，硬件通過開發程控包，可在CANoe中直接調用，例如配置測試終端電阻，通過串口進行供電電源的電壓輸出控制等［4］。測試配置示意如圖2所示，虛線框內為通過測試配置板卡控制的可選終端電阻。NM通信模型由CAPL開發，因此可以與下位機執行軟件無縫銜接。NM通信模型實現OSEK網絡管理的虛擬節點在線仿真功能，如可以建立OSEK虛擬邏輯環、邏輯環異常干擾等，如圖3所示。虛擬節點支持對NM報文的信號值、周期等參數進行設置，以滿足不同的測試項要求，這些模型參數的調整接口在測試腳本中能夠直接調用。測試腳本同樣基于CAPL編寫，因此可與NM通信模型聯合運行在CANoe平臺上進行NM測試。
3.2OSEKNM測試用例實現
假定測試ECU的NM網絡管理報文ID為0x627，則設置NM通信模型主要參數如表2所示。根據測試需求，可以提煉出幾種模型狀態定義，如圖4所示。兩個比較典型的測試用例加以說明。1）插入指向ECU的Ring報文測試。首先，為ECU供電，使ECU喚醒；調用VirNode建環模型，使ECU與編號1~3的虛擬節點建立正常的邏輯環；然后調用VirNode異常干擾模型，即插入編號4的虛擬節點，且設置VirNode4.Byte（0）=0x27，VirNode4.OpCode=0x2，即指向ECU的Ring報文；最后觀察ECU發送報文狀態。2）Normal狀態進入睡眠時NM喚醒中斷測試。首先，為ECU供電，使ECU喚醒；調用VirNode建環模型，使ECU與編號1~3的虛擬節點建立正常的邏輯環；然后改變ECU供電狀態，使其滿足睡眠條件，則ECU發送帶有睡眠請求的Ring報文；之后調用VirNode睡眠響應模型，滿足總線睡眠；在T_WaitBusSleep時間內，調用VirNode睡眠中斷模型，即重新使編號1的模擬節點上線，發送VirNode1.Byte（0）=0x28，VirNode1.OpCode=0x1的Alive報文；最后觀察ECU發送報文狀態。
4測試結果分析
因OSEKNM的測試條目總和達到了50條以上的規模，因此本節也只選取了兩個典型的測試案例進行分析說明。
4.1T_WaitBusSleep時間測試
測試描述：驗證T_WaitBusSleep時間參數的偏差。評價標準：T_WaitBusSleep時間應滿足在4~6s時間內。測試結果分析如下。1）如圖5所示，ECU在時間戳940.396s發送了睡眠幀，但是在之后又發送了一幀ID為0x2C9的應用幀，不滿足OSEK的要求。2）如圖6所示，在時間戳945.397s出現ECU不應答的發送錯誤幀，說明ECU進入睡眠狀態，則T_WaitBusSleep時間為睡眠幀到出現錯誤幀的時間差，即5.001s。綜合1）、2）結果分析，該項測試結果為錯誤，雖然T_WaitBusSleep時間正確，但是睡眠幀發出后，ECU應停止發送所有報文，因此狀態錯誤。
4.2Limphome狀態下睡眠中斷測試
測試用例：Limphome狀態進入睡眠時NM喚醒中斷測試。測試描述：驗證在ECU從Limphome狀態進入睡眠模式過程中，接收到NM報文時的睡眠中斷反應。評價標準：T_WaitBusSleep時間內，接收到NM報文時，ECU能被喚醒，并重新發送Limphome報文。測試結果分析如下。1）如圖7所示，在時間戳1866.971s接收到NM報文，E－CU在1867.962s發出自身NM報文。2）喚醒后，ECU仍然處于limphome狀態。喚醒后ECU.OpCode=0x14。綜合1）、2）評價，本項測試結果正確
5結束語
基于OSEK/VDX網絡管理規范開發的車載電控單元OSEK網絡管理測試設備，通過開發NM通信模型的設計理念，使系統對于OSEK網絡管理的測試更智能、更準確，且能覆蓋更多的測試用例。通過驗證，該設備能夠準確的完成網絡管理測試，且比人工測試縮短3倍以上的時間，因此極大提高了OSEK網絡管理的整體測試效率。
作者：朱龍 周旋 王凱 黃帥 單位：徐州徐工汽車制造有限公司
