OSEK/VDX直接網(wǎng)絡(luò )管理一致測試方法設計

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

OSEK/VDX (Open Systems and the Corresponding Interfaces for Automotive Electronics/Vehicle Distributed eXecutive) 是歐洲主要的汽車(chē)廠(chǎng)商和研究機構聯(lián)合提出的一種基于汽車(chē)電子開(kāi)放式系統及其接口的軟件標準。鑒于汽車(chē)網(wǎng)絡(luò )的安全性和可靠性，OSEK/VDX中的網(wǎng)絡(luò )管理NM(Network Management)規范提供了標準的管理策略，通過(guò)接口和服務(wù)來(lái)實(shí)現汽車(chē)網(wǎng)絡(luò )中ECU節點(diǎn)的監控和管理[3]。OSEK/VDX規范對網(wǎng)絡(luò )管理提出直接網(wǎng)絡(luò )管理和間接網(wǎng)絡(luò )管理兩種實(shí)現機制。

OSEK/VDX規范是通過(guò)自然語(yǔ)言和圖表形式進(jìn)行描述的，程序開(kāi)發(fā)人員在根據規范編寫(xiě)應用程序時(shí)，可能因為對規范的不同理解、編寫(xiě)代碼時(shí)的失誤等原因，導致應用程序與規范的不一致。對于安全性有極高要求的汽車(chē)電子系統而言，這種現象是不允許的。因此，有必要通過(guò)一致性測試來(lái)判斷開(kāi)發(fā)的應用程序是否符合預定規范。近年來(lái)，學(xué)術(shù)界對OSEK OS（OSEK Operation System）的一致性測試方法提出了一些解決方案。參考文獻[4]提出了一種OSEK OS服務(wù)調用規范的一致性測試方法，參考文獻[5]設計了一種OSEK OS一致性測試用例生成的方法，但是很少對OSEK NM的一致性測試做相應研究。

本文在深入研究OSEK網(wǎng)絡(luò )管理規范的基礎上提出了一種OSEK NM一致性測試方法，設計出一種基于直接網(wǎng)絡(luò )管理功能的測試架構，并定義了測試方案、測試報文的數據結構和測試流程。

1 OSEK直接網(wǎng)絡(luò )管理基本原理

在OSEK NM規范中，直接網(wǎng)絡(luò )管理是一種自組織形式網(wǎng)絡(luò )管理。網(wǎng)絡(luò )中節點(diǎn)之間沒(méi)有主從之分，每個(gè)節點(diǎn)都被網(wǎng)絡(luò )中其他的節點(diǎn)監控，同時(shí)該節點(diǎn)也監控網(wǎng)絡(luò )中的其他節點(diǎn)。直接網(wǎng)絡(luò )管理通過(guò)邏輯環(huán)對車(chē)載網(wǎng)絡(luò )進(jìn)行管理與監控，如圖1所示為直接網(wǎng)絡(luò )管理邏輯環(huán)的體系結構。連接在總線(xiàn)上的A、B、C 3個(gè)節點(diǎn)都擁有自己唯一的網(wǎng)絡(luò )管理身份標識ID,且IDAIDBIDC，根據ID的大小，以A→B→C→A的順序傳輸特定的網(wǎng)絡(luò )管理報文，形成一個(gè)虛擬邏輯環(huán)。在邏輯環(huán)中連接的所有節點(diǎn)按照邏輯環(huán)規定的方向發(fā)送特定的網(wǎng)絡(luò )管理報文，實(shí)現直接網(wǎng)絡(luò )管理功能。

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

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

Destination ID表示網(wǎng)絡(luò )管理報文的目標地址，即接收該網(wǎng)絡(luò )管理報文的節點(diǎn)地址；Option Code表示操作碼，用來(lái)設置網(wǎng)絡(luò )管理報文的類(lèi)型,其有Ring、Alive、LimpHome三種。 Data表示數據場(chǎng)，用于定義網(wǎng)絡(luò )管理報文中的附加信息。

直接網(wǎng)絡(luò )管理中各類(lèi)型報文的作用：

(1)Ring報文：一個(gè)基本的監視報文，當網(wǎng)絡(luò )狀態(tài)為正常狀態(tài)時(shí)，網(wǎng)絡(luò )節點(diǎn)在定時(shí)器的觸發(fā)下，根據節點(diǎn)ID的大小順序地傳送Ring報文。

(2)Alive報文：一個(gè)在非正常狀態(tài)下的特殊報文，當一個(gè)新的節點(diǎn)要加入網(wǎng)絡(luò )時(shí)，節點(diǎn)向網(wǎng)絡(luò )中發(fā)送Alive報文。

(3)LimpHome報文：當接收/發(fā)送錯誤計數器超過(guò)其閾值或總線(xiàn)出現嚴重錯誤時(shí)，節點(diǎn)進(jìn)入NMLimpHome狀態(tài)，并周期地發(fā)送LimpHome報文。

2 OSEK NM的一致性測試方法

OSEK NM的一致性測試是一種功能性測試，在一致性測試中，測試者不必關(guān)心被測IUT（Implementation Under Test）內部的具體實(shí)現，只需關(guān)心其表現出來(lái)的外部行為[6-7]。

2.1 測試的體系結構

根據OSEK NM規范，將網(wǎng)絡(luò )管理的測試體系結構分為兩個(gè)部分，即被測系統及測試系統。

(1)被測系統，是IUT的載體，在測試系統中實(shí)現網(wǎng)絡(luò )管理功能。

(2)測試系統，用來(lái)執行測試案例程序，該設備通過(guò)網(wǎng)絡(luò )跟被測設備相互通信。

整個(gè)網(wǎng)絡(luò )管理測試方案分為兩個(gè)子塊，即測試管理模塊和輔助測試模塊。測試管理模塊由測試案例組成，在測試系統中運行；輔助測試模塊作為被測系統的應用程序在被測設備中運行，用來(lái)配合測試管理模塊完成網(wǎng)絡(luò )管理功能的測試。在網(wǎng)絡(luò )管理功能測試中，輔助測試模塊起到兩方面的作用，一方面用來(lái)響應測試系統的發(fā)來(lái)的請求，另一方面作為被測系統的應用程序，通過(guò)調用NM API函數，控制IUT的運行模式，并收集被測系統中IUT當前的狀態(tài)信息，返回給測試系統。

測試管理模塊和輔助測試模塊之間的數據信息交換通過(guò)應用報文完成，該報文為測試管理協(xié)議數據單元（TM_PDU）。該方式下，2個(gè)測試模塊之間的通信獨立于底層網(wǎng)絡(luò )管理通信協(xié)議，不影響網(wǎng)絡(luò )管理功能。

在OSEK 直接網(wǎng)絡(luò )管理中，網(wǎng)絡(luò )出錯處理機制是很重要的一部分。根據OSEK NM規范，OSEK NM可以處理一些常見(jiàn)的網(wǎng)絡(luò )錯誤，如通信超時(shí)、BusOff等，所以本文在網(wǎng)絡(luò )管理功能測試系統中增加了模擬和制造網(wǎng)絡(luò )錯誤的模塊。

綜上所述，在直接網(wǎng)絡(luò )管理的測試架構中，測試系統必須具備以下功能：

(1)測試系統必須具備網(wǎng)絡(luò )管理功能，發(fā)送網(wǎng)絡(luò )管理報文,并能模擬一個(gè)或多個(gè)網(wǎng)絡(luò )管理節點(diǎn)的網(wǎng)絡(luò )關(guān)系行為。

(2)測試系統能接受并分析NMPDU，判斷被測系統中的IUT是否符合網(wǎng)絡(luò )管理規范，即帶有OSEK 直接網(wǎng)絡(luò )管理功能。

(3)測試系統能夠通過(guò)測試設備中一種特定的測試軟件編程來(lái)控制相應的硬件設備，使總線(xiàn)出現特定的網(wǎng)絡(luò )故障(如Vector公司的CAN總線(xiàn)干擾儀CANstress)。

2.2 測試方案和測試管理報文的定義

在直接網(wǎng)絡(luò )管理模塊正常工作時(shí)，ECU應用程序通過(guò)調用NM API接口函數來(lái)控制OSEK NM的相關(guān)動(dòng)作，如功能開(kāi)啟、關(guān)閉及睡眠等。而在直接網(wǎng)絡(luò )管理的測試過(guò)程中，整個(gè)測試系統必須能夠模擬這一過(guò)程。為了實(shí)現這一功能，在測試系統與被測系統之間有兩種類(lèi)型的報文，即直接網(wǎng)絡(luò )管理報文和測試管理報文。測試管理報文是測試管理模塊和輔助測試模塊之間的數據通道，使測試管理模塊能夠間接控制IUT，從而實(shí)現測試功能。圖4所示為測試管理模塊和輔助測試模塊之間的兩種通信模式。

測試系統用圖4(a)所示的通信模式獲取被測系統中NM模塊當前的狀態(tài)以及配置信息，用圖4(b)所示的通信模式控制輔助測試模塊調用NM服務(wù)函數，圖中虛線(xiàn)箭頭表示根據需求服務(wù)的返回值可以選擇性的傳回測試系統。

測試管理報文的格式有apiCall和apiStatus兩種：

(1)apiCall：用來(lái)請求輔助測試模塊調用NM API，控制OSEK NM實(shí)現特定的動(dòng)作。報文名定義形式為CallXXX（其中“XXX”表示NM API名稱(chēng)，如：StartNM）；
(2)apiStatus：將調用NM API函數的返回值和當前NM的狀態(tài)信息返回給測試系統，相應的報文有APIStatus，NetStatusMsg等。

測試管理報文兩種格式的數據單元映射到CAN報文的數據幀上,如表1所示。其中，報文名編號為不同功能測試管理報文的編號;服務(wù)編號為NM API編號，用以標識該報文是控制某個(gè)API的調用或對某個(gè)API的響應;目的ID為標識該測試管理報文要發(fā)送到的目標網(wǎng)絡(luò )管理節點(diǎn)；報文數據單元為apiStatus報文專(zhuān)有數據單元，用來(lái)存儲API函數調用的返回值或當前網(wǎng)絡(luò )管理單元的配置和狀態(tài)信息。


2.3 測試的流程

OSEK NM測試可分為以下步驟：
(1)根據OSEK NM規范，抽象出需要測試的內容。如從NMNormal→NMBusSleep轉換過(guò)程中,網(wǎng)絡(luò )管理內部狀態(tài)的變化。
(2)根據測試內容和測試方法，將直接網(wǎng)絡(luò )管理功能分為一個(gè)或多個(gè)功能模塊，針對各個(gè)功能模塊設計相應的測試用例。
(3)在測試系統中執行測試用例，并記錄執行過(guò)程中測試系統獲取的網(wǎng)絡(luò )管理狀態(tài)數據。
(4)將測試結果數據與OSEK NM管理協(xié)議做對比，分析被測功能模塊是否與協(xié)議一致，并分析不一致的可能原因。

3 測試方法驗證

3.1 測試用例設計

本文以網(wǎng)絡(luò )管理狀態(tài)從NMNormal轉向NMBusSleep為例進(jìn)行測試。測試用例分為三個(gè)部分，即初始狀態(tài)、測試步驟和期望結果。下面給出測試用例的詳細內容：

(1)初始狀態(tài)

①操作模式為主動(dòng)模式（NMActive）;
②本地NM設置networkstatus.bussleep=0;
③網(wǎng)絡(luò )管理狀態(tài)為NMNormal;
④測試系統狀態(tài)與被測節點(diǎn)一致，在整個(gè)網(wǎng)絡(luò )中已建立邏輯環(huán)，并正常工作。

(2)測試步驟

①測試設備發(fā)送CallGotoMode(Sleep)報文；
②當接收接下來(lái)IUT發(fā)來(lái)的第一條報文后使測試系統中其他的虛擬節點(diǎn)調用GotoMode(Sleep)服務(wù)；
③當接收到IUT發(fā)來(lái)的第二條報文后，測試設備發(fā)送CallGetStatus報文，等待NetStatusMsg報文的響應，讀取被測節點(diǎn)中IUT當前的狀態(tài)；
④等待TwaitBusSleep時(shí)間段后，再次發(fā)送CallGetStatus報文，等待NetStatusMsg報文的響應，讀取被測節點(diǎn)中IUT當前的狀態(tài)。

(3)期望結果

①I(mǎi)UT發(fā)送的第一條網(wǎng)絡(luò )管理報文中，sleep.ind位被置位；
②IUT發(fā)送的第二條網(wǎng)絡(luò )管理報文中，sleep.ack位被置位，且當前IUT的網(wǎng)絡(luò )狀態(tài)為NMTwbsNormal；
③接收到sleep.ack=1的報文TwaitBusSleep后節點(diǎn)進(jìn)入NMBusSleep狀態(tài)；
④整個(gè)運行過(guò)程中，IUT都處于NMActive狀態(tài)。

3.2 測試平臺搭建與測試

測試設備由裝有CANoe軟件的PC機、CANcaseXL和CANstress組成。CANoe是由Vector公司開(kāi)發(fā)的網(wǎng)絡(luò )分析、設計和測試的專(zhuān)用工具，支持多種總線(xiàn)系統。CANcaseXL為Vector提供的新一代CAN和LIN的USB 2.0接口卡，與CANoe軟件組合使用。CANstress是CAN總線(xiàn)干擾儀，它可以直接串連到CAN網(wǎng)絡(luò )中，實(shí)現各種觸發(fā)條件與邏輯的干擾。被測設備為帶有OSEK NM功能的汽車(chē)儀表，外接12 V直流電源為汽車(chē)儀表供電。

基于上述測試平臺進(jìn)行網(wǎng)絡(luò )管理功能測試。首先在CANoe軟件平臺上實(shí)現3個(gè)CAN節點(diǎn)，并用CAPL語(yǔ)言對每個(gè)節點(diǎn)編程，實(shí)現基于OSEK 規范的直接網(wǎng)絡(luò )管理功能，在其中一個(gè)節點(diǎn)中添加測試管理功能模塊，運行測試用例，實(shí)現總體測試管理控制。汽車(chē)儀表ECU軟件中添加輔助測試程序模塊，作為儀表的應用軟件。最后，根據預先設計好的測試用例對NMNormal到NMBusSleep的狀態(tài)轉換進(jìn)行一致性測試，并記錄測試結果。

3.3 測試結果

圖5所示為直接網(wǎng)絡(luò )管理測試在CANoe的Trace窗口上的顯示結果。圖中對報文和數據的含義做了相應的說(shuō)明。在測試系統的控制下，整個(gè)網(wǎng)絡(luò )進(jìn)入睡眠狀態(tài)，并根據測試案例成功讀取到直接網(wǎng)絡(luò )管理的狀態(tài)信息。

通過(guò)對Trace窗口中的數據進(jìn)行分析可見(jiàn),測試結果跟測試案例中的預期結果一致，這說(shuō)明儀表節點(diǎn)中直接網(wǎng)絡(luò )管理睡眠流程符合OSEK NM規范。同時(shí)也驗證了該測試方法的正確性。

本文提出了一種基于OSEK NM管理的一致性測試方法，并詳細敘述了測試系統的體系結構、測試方案、測試管理報文的定義，以及測試流程。最后通過(guò)對儀表節點(diǎn)的直接網(wǎng)絡(luò )管理睡眠過(guò)程的測試，說(shuō)明了該方法的有效性。通過(guò)對基于OSEK規范的直接網(wǎng)絡(luò )管理的測試，能夠發(fā)現OSEK NM在正常工作中很難出現的錯誤，并能有效地驗證OSEK NM的正確性,對提高基于OSEK規范的直接網(wǎng)絡(luò )管理可靠性和穩定性有重要的作用。