隨著近年汽車產(chǎn)業(yè)的快速發(fā)展，電子產(chǎn)品廣泛應用于汽車控制，如發(fā)動機控制系統(tǒng)、轉向系統(tǒng)、制動系統(tǒng)等裝置中都采用電子控制單元ECU(Electronic Control Unit)[1]。一些高檔的轎車大約有70個ECU，ECU之間傳遞的信息超過2500條[2]。為了使ECU之間實現(xiàn)信息共享，誕生了在汽車控制系統(tǒng)中應用的互聯(lián)網(wǎng)絡，即車載網(wǎng)絡。隨著汽車中電子單元的增加，網(wǎng)絡越來越復雜，ECU在通信時，可能由于其他節(jié)點未上線或出現(xiàn)故障而造成信息丟失，所以需要專門的網(wǎng)絡管理組件對車載網(wǎng)絡進行管理，以達到車載網(wǎng)絡信息傳輸準確性、安全性的目的。

    OSEK/VDX (Open Systems and the Corresponding Interfaces for Automotive Electronics/Vehicle Distributed eXecutive) 是歐洲主要的汽車廠商和研究機構聯(lián)合提出的一種基于汽車電子開放式系統(tǒng)及其接口的軟件標準。鑒于汽車網(wǎng)絡的安全性和可靠性，OSEK/VDX中的網(wǎng)絡管理NM(Network Management)規(guī)范提供了標準的管理策略，通過接口和服務來實現(xiàn)汽車網(wǎng)絡中ECU節(jié)點的監(jiān)控和管理[3]。OSEK/VDX規(guī)范對網(wǎng)絡管理提出直接網(wǎng)絡管理和間接網(wǎng)絡管理兩種實現(xiàn)機制。
    OSEK/VDX規(guī)范是通過自然語言和圖表形式進行描述的，程序開發(fā)人員在根據(jù)規(guī)范編寫應用程序時，可能因為對規(guī)范的不同理解、編寫代碼時的失誤等原因，導致應用程序與規(guī)范的不一致。對于安全性有極高要求的汽車電子系統(tǒng)而言，這種現(xiàn)象是不允許的。因此，有必要通過一致性測試來判斷開發(fā)的應用程序是否符合預定規(guī)范。近年來，學術界對OSEK OS（OSEK Operation System）的一致性測試方法提出了一些解決方案。參考文獻[4]提出了一種OSEK OS服務調用規(guī)范的一致性測試方法，參考文獻[5]設計了一種OSEK OS一致性測試用例生成的方法，但是很少對OSEK NM的一致性測試做相應研究。
    本文在深入研究OSEK網(wǎng)絡管理規(guī)范的基礎上提出了一種OSEK NM一致性測試方法，設計出一種基于直接網(wǎng)絡管理功能的測試架構，并定義了測試方案、測試報文的數(shù)據(jù)結構和測試流程。
1 OSEK直接網(wǎng)絡管理基本原理
     在OSEK NM規(guī)范中，直接網(wǎng)絡管理是一種自組織形式網(wǎng)絡管理。網(wǎng)絡中節(jié)點之間沒有主從之分，每個節(jié)點都被網(wǎng)絡中其他的節(jié)點監(jiān)控，同時該節(jié)點也監(jiān)控網(wǎng)絡中的其他節(jié)點。直接網(wǎng)絡管理通過邏輯環(huán)對車載網(wǎng)絡進行管理與監(jiān)控，如圖1所示為直接網(wǎng)絡管理邏輯環(huán)的體系結構。連接在總線上的A、B、C 3個節(jié)點都擁有自己唯一的網(wǎng)絡管理身份標識ID,且IDA<IDB<IDC，根據(jù)ID的大小，以A&rarr;B&rarr;C&rarr;A的順序傳輸特定的網(wǎng)絡管理報文，形成一個虛擬邏輯環(huán)。在邏輯環(huán)中連接的所有節(jié)點按照邏輯環(huán)規(guī)定的方向發(fā)送特定的網(wǎng)絡管理報文，實現(xiàn)直接網(wǎng)絡管理功能。

    圖2所示為直接網(wǎng)絡管理的狀態(tài)模型。通過網(wǎng)絡管理服務的調用和網(wǎng)絡通信狀況的改變，引起網(wǎng)絡管理狀態(tài)的遷移，如調用StartNM()服務可啟動網(wǎng)絡管理功能，使節(jié)點的狀態(tài)從NMOff轉為NMOn。

    在直接網(wǎng)絡管理中，為了滿足通信和網(wǎng)絡管理的需要，網(wǎng)絡管理協(xié)議數(shù)據(jù)單元NMPDU(NM Protocol Data Unit)包括地址域、控制域和數(shù)據(jù)域。圖3是網(wǎng)絡管理協(xié)議數(shù)據(jù)單元的基本格式。其中，Source ID表示網(wǎng)絡管理報文的源地址，即發(fā)送該網(wǎng)絡管理報文的節(jié)點地址；

    Destination ID表示網(wǎng)絡管理報文的目標地址，即接收該網(wǎng)絡管理報文的節(jié)點地址；Option Code表示操作碼，用來設置網(wǎng)絡管理報文的類型,其有Ring、Alive、LimpHome三種。    Data表示數(shù)據(jù)場，用于定義網(wǎng)絡管理報文中的附加信息。
    直接網(wǎng)絡管理中各類型報文的作用：
    (1)Ring報文：一個基本的監(jiān)視報文，當網(wǎng)絡狀態(tài)為正常狀態(tài)時，網(wǎng)絡節(jié)點在定時器的觸發(fā)下，根據(jù)節(jié)點ID的大小順序地傳送Ring報文。
    (2)Alive報文：一個在非正常狀態(tài)下的特殊報文，當一個新的節(jié)點要加入網(wǎng)絡時，節(jié)點向網(wǎng)絡中發(fā)送Alive報文。
    (3)LimpHome報文：當接收/發(fā)送錯誤計數(shù)器超過其閾值或總線出現(xiàn)嚴重錯誤時，節(jié)點進入NMLimpHome狀態(tài)，并周期地發(fā)送LimpHome報文。
2 OSEK NM的一致性測試方法
   OSEK NM的一致性測試是一種功能性測試，在一致性測試中，測試者不必關心被測IUT（Implementation Under Test）內部的具體實現(xiàn)，只需關心其表現(xiàn)出來的外部行為[6-7]。
2.1 測試的體系結構
    根據(jù)OSEK NM規(guī)范，將網(wǎng)絡管理的測試體系結構分為兩個部分，即被測系統(tǒng)及測試系統(tǒng)。
    (1)被測系統(tǒng)，是IUT的載體，在測試系統(tǒng)中實現(xiàn)網(wǎng)絡管理功能。
    (2)測試系統(tǒng)，用來執(zhí)行測試案例程序，該設備通過網(wǎng)絡跟被測設備相互通信。
    整個網(wǎng)絡管理測試方案分為兩個子塊，即測試管理模塊和輔助測試模塊。測試管理模塊由測試案例組成，在測試系統(tǒng)中運行；輔助測試模塊作為被測系統(tǒng)的應用程序在被測設備中運行，用來配合測試管理模塊完成網(wǎng)絡管理功能的測試。在網(wǎng)絡管理功能測試中，輔助測試模塊起到兩方面的作用，一方面用來響應測試系統(tǒng)的發(fā)來的請求，另一方面作為被測系統(tǒng)的應用程序，通過調用NM API函數(shù)，控制IUT的運行模式，并收集被測系統(tǒng)中IUT當前的狀態(tài)信息，返回給測試系統(tǒng)。
     測試管理模塊和輔助測試模塊之間的數(shù)據(jù)信息交換通過應用報文完成，該報文為測試管理協(xié)議數(shù)據(jù)單元（TM_PDU）。該方式下，2個測試模塊之間的通信獨立于底層網(wǎng)絡管理通信協(xié)議，不影響網(wǎng)絡管理功能。
　  在OSEK 直接網(wǎng)絡管理中，網(wǎng)絡出錯處理機制是很重要的一部分。根據(jù)OSEK NM規(guī)范，OSEK NM可以處理一些常見的網(wǎng)絡錯誤，如通信超時、BusOff等，所以本文在網(wǎng)絡管理功能測試系統(tǒng)中增加了模擬和制造網(wǎng)絡錯誤的模塊。
    綜上所述，在直接網(wǎng)絡管理的測試架構中，測試系統(tǒng)必須具備以下功能：
　 (1)測試系統(tǒng)必須具備網(wǎng)絡管理功能，發(fā)送網(wǎng)絡管理報文,并能模擬一個或多個網(wǎng)絡管理節(jié)點的網(wǎng)絡關系行為。
　 (2)測試系統(tǒng)能接受并分析NMPDU，判斷被測系統(tǒng)中的IUT是否符合網(wǎng)絡管理規(guī)范，即帶有OSEK 直接網(wǎng)絡管理功能。
　 (3)測試系統(tǒng)能夠通過測試設備中一種特定的測試軟件編程來控制相應的硬件設備，使總線出現(xiàn)特定的網(wǎng)絡故障(如Vector公司的CAN總線干擾儀CANstress)。
2.2 測試方案和測試管理報文的定義
　 在直接網(wǎng)絡管理模塊正常工作時，ECU應用程序通過調用NM API接口函數(shù)來控制OSEK NM的相關動作，如功能開啟、關閉及睡眠等。而在直接網(wǎng)絡管理的測試過程中，整個測試系統(tǒng)必須能夠模擬這一過程。為了實現(xiàn)這一功能，在測試系統(tǒng)與被測系統(tǒng)之間有兩種類型的報文，即直接網(wǎng)絡管理報文和測試管理報文。測試管理報文是測試管理模塊和輔助測試模塊之間的數(shù)據(jù)通道，使測試管理模塊能夠間接控制IUT，從而實現(xiàn)測試功能。圖4所示為測試管理模塊和輔助測試模塊之間的兩種通信模式。
    測試系統(tǒng)用圖4(a)所示的通信模式獲取被測系統(tǒng)中
NM模塊當前的狀態(tài)以及配置信息，用圖4(b)所示的通信模式控制輔助測試模塊調用NM服務函數(shù)，圖中虛線箭頭表示根據(jù)需求服務的返回值可以選擇性的傳回測試系統(tǒng)。

    測試管理報文的格式有apiCall和apiStatus兩種：
　 (1)apiCall：用來請求輔助測試模塊調用NM API，控制OSEK NM實現(xiàn)特定的動作。報文名定義形式為CallXXX（其中&ldquo;XXX&rdquo;表示NM API名稱，如：StartNM）；
    (2)apiStatus：將調用NM API函數(shù)的返回值和當前NM的狀態(tài)信息返回給測試系統(tǒng)，相應的報文有APIStatus，NetStatusMsg等。
    測試管理報文兩種格式的數(shù)據(jù)單元映射到CAN報文的數(shù)據(jù)幀上,如表1所示。其中，報文名編號為不同功能測試管理報文的編號;服務編號為NM API編號，用以標識該報文是控制某個API的調用或對某個API的響應;目的ID為標識該測試管理報文要發(fā)送到的目標網(wǎng)絡管理節(jié)點；報文數(shù)據(jù)單元為apiStatus報文專有數(shù)據(jù)單元，用來存儲API函數(shù)調用的返回值或當前網(wǎng)絡管理單元的配置和狀態(tài)信息。

2.3 測試的流程
    OSEK NM測試可分為以下步驟：
    (1)根據(jù)OSEK NM規(guī)范，抽象出需要測試的內容。如從NMNormal&rarr;NMBusSleep轉換過程中,網(wǎng)絡管理內部狀態(tài)的變化。
    (2)根據(jù)測試內容和測試方法，將直接網(wǎng)絡管理功能分為一個或多個功能模塊，針對各個功能模塊設計相應的測試用例。
    (3)在測試系統(tǒng)中執(zhí)行測試用例，并記錄執(zhí)行過程中測試系統(tǒng)獲取的網(wǎng)絡管理狀態(tài)數(shù)據(jù)。
    (4)將測試結果數(shù)據(jù)與OSEK NM管理協(xié)議做對比，分析被測功能模塊是否與協(xié)議一致，并分析不一致的可能原因。
3 測試方法驗證
3.1 測試用例設計
    本文以網(wǎng)絡管理狀態(tài)從NMNormal轉向NMBusSleep為例進行測試。測試用例分為三個部分，即初始狀態(tài)、測試步驟和期望結果。下面給出測試用例的詳細內容：
　　(1)初始狀態(tài)
　?、俨僮髂Ｊ綖橹鲃幽Ｊ剑∟MActive）;
　?、诒镜豊M設置networkstatus.bussleep=0;
　?、劬W(wǎng)絡管理狀態(tài)為NMNormal;
　　④測試系統(tǒng)狀態(tài)與被測節(jié)點一致，在整個網(wǎng)絡中已建立邏輯環(huán)，并正常工作。
　　(2)測試步驟
　?、贉y試設備發(fā)送CallGotoMode(Sleep)報文；
　?、诋斀邮战酉聛鞩UT發(fā)來的第一條報文后使測試系統(tǒng)中其他的虛擬節(jié)點調用GotoMode(Sleep)服務；
　?、郛斀邮盏絀UT發(fā)來的第二條報文后，測試設備發(fā)送CallGetStatus報文，等待NetStatusMsg報文的響應，讀取被測節(jié)點中IUT當前的狀態(tài)；
　    ④等待TwaitBusSleep時間段后，再次發(fā)送CallGetStatus報文，等待NetStatusMsg報文的響應，讀取被測節(jié)點中IUT當前的狀態(tài)。
　　(3)期望結果
　?、買UT發(fā)送的第一條網(wǎng)絡管理報文中，sleep.ind位被置位；
　?、贗UT發(fā)送的第二條網(wǎng)絡管理報文中，sleep.ack位被置位，且當前IUT的網(wǎng)絡狀態(tài)為NMTwbsNormal；
　?、劢邮盏絪leep.ack=1的報文TwaitBusSleep后節(jié)點進入NMBusSleep狀態(tài)；
　?、苷麄€運行過程中，IUT都處于NMActive狀態(tài)。
3.2 測試平臺搭建與測試
　    測試設備由裝有CANoe軟件的PC機、CANcaseXL和CANstress組成。CANoe是由Vector公司開發(fā)的網(wǎng)絡分析、設計和測試的專用工具，支持多種總線系統(tǒng)。CANcaseXL為Vector提供的新一代CAN和LIN的USB 2.0接口卡，與CANoe軟件組合使用。CANstress是CAN總線干擾儀，它可以直接串連到CAN網(wǎng)絡中，實現(xiàn)各種觸發(fā)條件與邏輯的干擾。被測設備為帶有OSEK NM功能的汽車儀表，外接12 V直流電源為汽車儀表供電。
    基于上述測試平臺進行網(wǎng)絡管理功能測試。首先在CANoe軟件平臺上實現(xiàn)3個CAN節(jié)點，并用CAPL語言對每個節(jié)點編程，實現(xiàn)基于OSEK 規(guī)范的直接網(wǎng)絡管理功能，在其中一個節(jié)點中添加測試管理功能模塊，運行測試用例，實現(xiàn)總體測試管理控制。汽車儀表ECU軟件中添加輔助測試程序模塊，作為儀表的應用軟件。最后，根據(jù)預先設計好的測試用例對NMNormal到NMBusSleep的狀態(tài)轉換進行一致性測試，并記錄測試結果。
3.3 測試結果
    圖5所示為直接網(wǎng)絡管理測試在CANoe的Trace窗口上的顯示結果。圖中對報文和數(shù)據(jù)的含義做了相應的說明。在測試系統(tǒng)的控制下，整個網(wǎng)絡進入睡眠狀態(tài)，并根據(jù)測試案例成功讀取到直接網(wǎng)絡管理的狀態(tài)信息。
    通過對Trace窗口中的數(shù)據(jù)進行分析可見,測試結果跟測試案例中的預期結果一致，這說明儀表節(jié)點中直接網(wǎng)絡管理睡眠流程符合OSEK NM規(guī)范。同時也驗證了該測試方法的正確性。

    本文提出了一種基于OSEK NM管理的一致性測試方法，并詳細敘述了測試系統(tǒng)的體系結構、測試方案、測試管理報文的定義，以及測試流程。最后通過對儀表節(jié)點的直接網(wǎng)絡管理睡眠過程的測試，說明了該方法的有效性。通過對基于OSEK規(guī)范的直接網(wǎng)絡管理的測試，能夠發(fā)現(xiàn)OSEK NM在正常工作中很難出現(xiàn)的錯誤，并能有效地驗證OSEK NM的正確性,對提高基于OSEK規(guī)范的直接網(wǎng)絡管理可靠性和穩(wěn)定性有重要的作用。
參考文獻
[1] SUWATTHIKUL J, MCMURRAN R, JONES R. Adaptive OSEK network management for in-vehicle network fault detection[C]. Vehicular Electronics and Safety,2007.ICVES. IEEE International Conference. Feb. 2008
[2] ALBERT A. Comparison of event-triggered and time-triggered concepts with regard to distributed control systems[C].Embedded World 2004, 2004.
[3] SEK Network Management-Concept and Application Programming Interface.V2.5.3[S].http://www.osek-vdx.org,2004.
[4] 李銀國，葉家盛，蔣建春. OSEK/VDX OS服務調用的規(guī)范一致性檢測方法[J].重慶郵電大學學報:自然科學版,2010,22(6):786-790.
[5] 李銳，王三宏，范德全,等. OSEK操作系統(tǒng)一致性測試用例的生成[J]. 計算機工程,2011,37(9):54-56.
[6] 朱振華，許毅平，周曼麗. 網(wǎng)絡協(xié)議測試生成方法綜述[J]. 計算機工程與應用, 2005(15):172-175.
[7] 邢熠，葉新銘，謝高崗.網(wǎng)絡協(xié)議測試的符號化一致性關系研究[J]. 計算機工程與應用, 2008,44(29):11-16.