車載以太網(wǎng)（BroadR-Reach）已經(jīng)在汽車攝像頭領(lǐng)域得到了應(yīng)用，并逐步擴(kuò)展到其他應(yīng)用領(lǐng)域。為了實(shí)現(xiàn)帶寬的高效利用，車載以太網(wǎng)采取與CAN總線通信方式相反的支持動(dòng)態(tài)的、面向服務(wù)的通信。因此，相應(yīng)的開發(fā)工具也必須要能夠支持面向服務(wù)的協(xié)議，如SOME/IP（Scalable service-Oriented MiddlewarE over IP）。
本文以SOME/IP為例介紹如何實(shí)現(xiàn)動(dòng)態(tài)的、面向服務(wù)的IP網(wǎng)絡(luò)殘余總線仿真，如圖1所示。并從媒介訪問(wèn)、同步以及仿真控制的角度進(jìn)行探討，希望可以給相關(guān)開發(fā)人員提供一些有價(jià)值的參考。
圖1 車載網(wǎng)絡(luò)測(cè)試示例
基于SOME/ IP的服務(wù)協(xié)議使用
在以太網(wǎng)（IP）領(lǐng)域，有眾多協(xié)議可供選擇，從而導(dǎo)致一種錯(cuò)誤的印象：即現(xiàn)有協(xié)議可以直接用于車內(nèi)所有可想象到的應(yīng)用程序。但是，車載網(wǎng)絡(luò)并非從零開始，所選用的協(xié)議也要能滿足特定的需求。比如，新的協(xié)議要能很好地適配于當(dāng)前的車載網(wǎng)絡(luò)系統(tǒng)，特別是涉及到AUTOSAR架構(gòu)的良好集成以及在出現(xiàn)通信錯(cuò)誤情況下如何確保時(shí)間延遲的快速反應(yīng)機(jī)制。寶馬開發(fā)并定義的SOME/IP，是一種可以滿足汽車使用需求的開放式協(xié)議。Vector提供基于SOME/IP的完整工具鏈，包括TCP/IP協(xié)議棧、服務(wù)發(fā)現(xiàn)（Service Discovery）和BroadR-Reach以太網(wǎng)驅(qū)動(dòng)程序等。
SOME/IP提供面向服務(wù)的通信接口，與當(dāng)前汽車主要總線CAN的面向信號(hào)的通信方式有很大不同，如圖2所示。SOME/IP可以大致分為三個(gè)部分：服務(wù)發(fā)現(xiàn)（Service Discovery，SD），遠(yuǎn)程過(guò)程調(diào)用（Remote Procedure Call，RPC）以及訪問(wèn)進(jìn)程數(shù)據(jù)。ECU通過(guò)SD在網(wǎng)絡(luò)中查找服務(wù)或者提供服務(wù)，客戶端（Client）通過(guò)RPC去調(diào)用SD提供的方法，如圖3（Part A）所示。此外，ECU還可以將特定事件設(shè)置為通知，如圖3（Part B）所示，由服務(wù)端（Server）ECU自動(dòng)向客戶端ECU發(fā)送服務(wù)內(nèi)容。客戶端ECU的應(yīng)用程序也可通過(guò)讀寫函數(shù)去訪問(wèn)任意特定進(jìn)程的數(shù)據(jù)，如圖3（Part C）所示。SOME/IP期望以一種最優(yōu)的方式利用帶寬并實(shí)現(xiàn)靈活的通信方式，其數(shù)據(jù)庫(kù)格式有FIBEX（FIBEX 4.1或更高版本）和ARXML（AUTOSAR4.1或更高版本）。
圖2 SOME/IP提供可用于標(biāo)定的接口
圖3 SOME/IP訪問(wèn)方式
基于CANoe的SOME/IP網(wǎng)絡(luò)仿真應(yīng)用
在殘余總線仿真中，SOME/IP作為復(fù)雜的協(xié)議和中間件，設(shè)計(jì)時(shí)較為靈活。為了盡可能地降低工程的復(fù)雜度，在CANoe中與SOME/IP相關(guān)的絕大部分配置都可以自動(dòng)化完成，前提條件是標(biāo)準(zhǔn)格式的數(shù)據(jù)庫(kù)文件（比如FIBEX或ARXML）。CANoe中SOME/IP的仿真功能基于SomeIP_IL.dll以及CANoeILNL_AUTOSAR_ETH.DLL實(shí)現(xiàn)，可在Simulation Setup中將上述dll文件分配給對(duì)應(yīng)的仿真節(jié)點(diǎn)并配置其SOME/IP交互層屬性。
> 在以太網(wǎng)網(wǎng)段里添加FIBEX或ARXML數(shù)據(jù)庫(kù)文件
圖4.1 添加數(shù)據(jù)庫(kù)
> 鼠標(biāo)右擊數(shù)據(jù)庫(kù)文件，選擇Node Synchronization，選擇需要?jiǎng)?chuàng)建的節(jié)點(diǎn)，點(diǎn)擊>>按鈕，點(diǎn)擊Next、Finish即可
圖4.2 創(chuàng)建仿真節(jié)點(diǎn)
> 在Simulation Setup界面，鼠標(biāo)右擊bus node分配相應(yīng)的dll文件（dll文件存儲(chǔ)在CANoe安裝目錄下Exec32文件夾中）
圖4.3 分配dll文件
至此，一個(gè)完整的殘余總線仿真環(huán)境已經(jīng)搭建完成。用戶還可以通過(guò)右擊Network node，選擇Component Configuration，修改服務(wù)的發(fā)送方式，如圖5所示，服務(wù)發(fā)現(xiàn)以及訂閱后的通知就會(huì)周期性的發(fā)送，進(jìn)一步的功能還可以通過(guò)CAPL編程實(shí)現(xiàn)，例如讀寫信號(hào)值，調(diào)用Method等。
圖5 配置IL屬性
在CANoe->Trace窗口可以查看SOME/IP的通信過(guò)程，如圖6所示。
圖6 Trace窗口
CANoe 11.0版本中新增一個(gè)EthernetNetwork Monitor分析窗口，可以方便地查看SOME/IP各節(jié)點(diǎn)的訂閱關(guān)系和相關(guān)服務(wù)信息，如圖7所示。
圖7 Ethernet Network Monitor
如果沒(méi)有數(shù)據(jù)庫(kù)或者數(shù)據(jù)庫(kù)不完整的話，CANoe也可以直接通過(guò)相關(guān)dll文件封裝好的函數(shù)，利用CAPL去創(chuàng)建服務(wù)（Event/Method），以及實(shí)現(xiàn)Event的觸發(fā)發(fā)送和Method的調(diào)用，相關(guān)函數(shù)在CANoe的幫助文檔中都有示例可供參考，如圖8所示。
圖8 CAPL腳本
利用測(cè)試工具實(shí)現(xiàn)靈活的訪問(wèn)網(wǎng)絡(luò)
利用測(cè)試工具能夠以最優(yōu)的方式去實(shí)現(xiàn)復(fù)雜的測(cè)試任務(wù)，比如殘余總線仿真，需要工具可以靈活、高效地訪問(wèn)物理媒介，如圖9所示。通過(guò)對(duì)物理媒介的訪問(wèn)，開發(fā)人員可以修改網(wǎng)絡(luò)上傳輸?shù)臄?shù)據(jù)來(lái)生成錯(cuò)誤的測(cè)試用例（如CRC錯(cuò)誤）。但如果僅僅只是監(jiān)測(cè)分析兩個(gè)節(jié)點(diǎn)之間的通信行為，則需要一種特殊的測(cè)量方法來(lái)實(shí)現(xiàn)透明、無(wú)干擾的訪問(wèn)物理媒介。雖然邏輯上Open Alliance BroadR-Reach（OABR）是一種總線系統(tǒng)，但從物理層角度來(lái)看屬于點(diǎn)對(duì)點(diǎn)連接，所以這種特殊的測(cè)量方法是很有必要的。解決方案之一是在系統(tǒng)中使用的交換機(jī)上增加一個(gè)額外的監(jiān)控端口，但由于成本原因，不是所有交換機(jī)都會(huì)預(yù)留監(jiān)控端口。在這種解決方案中，交換機(jī)會(huì)將所有接收到的數(shù)據(jù)轉(zhuǎn)發(fā)到監(jiān)控端口，從而產(chǎn)生兩個(gè)問(wèn)題：一是轉(zhuǎn)發(fā)的數(shù)據(jù)沒(méi)有共同的時(shí)間基準(zhǔn)，因?yàn)闆](méi)有時(shí)戳；二是交換機(jī)只會(huì)將有效的數(shù)據(jù)轉(zhuǎn)發(fā)給監(jiān)控端口，導(dǎo)致對(duì)一些錯(cuò)誤的分析變得困難。
圖9 VN5610在不同應(yīng)用案例中的使用
為了最大限度地減小媒介訪問(wèn)對(duì)網(wǎng)絡(luò)分析的影響，引入了一種名為TAP（TestAccess Point）的分析方法。與標(biāo)準(zhǔn)的數(shù)據(jù)轉(zhuǎn)發(fā)不同，通過(guò)TAP可以在不影響節(jié)點(diǎn)通信的前提下透明地分析網(wǎng)絡(luò)，如圖9所示。根據(jù)具體需求，TAP可以工作在兩種不同的模式：
> 被動(dòng)模式：可以保證恒定的較短的延遲時(shí)間，但是只能監(jiān)聽物理媒介。
> 主動(dòng)模式：在數(shù)據(jù)轉(zhuǎn)發(fā)過(guò)程中可以插入額外數(shù)據(jù)，但是會(huì)有一定的延遲。
由于主動(dòng)模式要對(duì)數(shù)據(jù)流進(jìn)行處理，而流控涉及到了數(shù)據(jù)鏈路層（OSI Layer2），因此不能用在物理層（OSI Layer1）。與此同時(shí)，流控不能保證恒定的等待時(shí)間。無(wú)論選擇哪一種模式，為了盡可能精確地分析PacketData（分組數(shù)據(jù)），都需要獲得盡可能接近物理層的精確時(shí)間戳。由于網(wǎng)絡(luò)分析通常關(guān)注多個(gè)以太網(wǎng)路徑，同時(shí)還需考慮汽車上其他的總線網(wǎng)絡(luò)，因此這些時(shí)間戳必須要與其他接口設(shè)備進(jìn)行同步。
選擇合適的開發(fā)工具
基于以上的考慮，每個(gè)開發(fā)者在選擇相應(yīng)的開發(fā)工具時(shí)都可以先思考下面五個(gè)問(wèn)題：
> 工具是否能夠支持面向服務(wù)的通信，比如SOME/IP？
> 工具是否能夠提供日志記錄以及在有或者沒(méi)有違反協(xié)議的情況下控制仿真？
> 工具是否能夠支持訪問(wèn)主流的車載網(wǎng)絡(luò)，如OABR，CAN，F(xiàn)lexRay和MOST？
> 接口是否可以靈活的用作鏡像的TAP轉(zhuǎn)換器以及交換機(jī)？
> 支持多種網(wǎng)絡(luò)類型的接口是否能夠與常用的總線系統(tǒng)和IP網(wǎng)絡(luò)同步？
軟件CANoe.Ethernet與硬件VN5610A/VN5640可以滿足上述的所有要求。通過(guò)CANoe.Ethernet可以實(shí)現(xiàn)以太網(wǎng)通信的監(jiān)測(cè)、以太網(wǎng)節(jié)點(diǎn)仿真、以太網(wǎng)數(shù)據(jù)鏈路層及其上層協(xié)議測(cè)試。以太網(wǎng)接口卡VN5610A包含兩路以太網(wǎng)通道和兩路高速CAN/CAN FD通道，VN5640接口卡支持16路以太網(wǎng)通道和兩路高速CAN/CAN FD通道。16路以太網(wǎng)中包含12路車載以太網(wǎng)通道和4路標(biāo)準(zhǔn)以太網(wǎng)通道。VN5640可工作于Standalone模式下，脫離上位機(jī)實(shí)現(xiàn)2層交換機(jī)的報(bào)文轉(zhuǎn)發(fā)功能，同時(shí)還提供數(shù)字/模擬IO通道。Vector一直致力于為用戶提供高效優(yōu)質(zhì)的產(chǎn)品和服務(wù)，CANoe.Ethernet與VN5610A/VN5640的組合在行業(yè)中得到了廣泛應(yīng)用。
