車載以太網（BroadR-Reach）已經在汽車攝像頭領域得到了應用，并逐步擴展到其他應用領域。為了實現帶寬的高效利用，車載以太網采取與CAN總線通信方式相反的支持動態的、面向服務的通信。因此，相應的開發工具也必須要能夠支持面向服務的協議，如SOME/IP（Scalable service-Oriented MiddlewarE over IP）。
 

本文以SOME/IP為例介紹如何實現動態的、面向服務的IP網絡殘余總線仿真，如圖1所示。并從媒介訪問、同步以及仿真控制的角度進行探討，希望可以給相關開發人員提供一些有價值的參考。

圖1 車載網絡測試示例

基于SOME/ IP的服務協議使用
 

在以太網（IP）領域，有眾多協議可供選擇，從而導致一種錯誤的印象：即現有協議可以直接用于車內所有可想象到的應用程序。但是，車載網絡并非從零開始，所選用的協議也要能滿足特定的需求。比如，新的協議要能很好地適配于當前的車載網絡系統，特別是涉及到AUTOSAR架構的良好集成以及在出現通信錯誤情況下如何確保時間延遲的快速反應機制。寶馬開發并定義的SOME/IP，是一種可以滿足汽車使用需求的開放式協議。Vector提供基于SOME/IP的完整工具鏈，包括TCP/IP協議棧、服務發現（Service Discovery）和BroadR-Reach以太網驅動程序等。
 

SOME/IP提供面向服務的通信接口，與當前汽車主要總線CAN的面向信號的通信方式有很大不同，如圖2所示。SOME/IP可以大致分為三個部分：服務發現（Service Discovery，SD），遠程過程調用（Remote Procedure Call，RPC）以及訪問進程數據。ECU通過SD在網絡中查找服務或者提供服務，客戶端（Client）通過RPC去調用SD提供的方法，如圖3（Part A）所示。此外，ECU還可以將特定事件設置為通知，如圖3（Part B）所示，由服務端（Server）ECU自動向客戶端ECU發送服務內容。客戶端ECU的應用程序也可通過讀寫函數去訪問任意特定進程的數據，如圖3（Part C）所示。SOME/IP期望以一種最優的方式利用帶寬并實現靈活的通信方式，其數據庫格式有FIBEX（FIBEX 4.1或更高版本）和ARXML（AUTOSAR4.1或更高版本）。

圖2 SOME/IP提供可用于標定的接口

圖3 SOME/IP訪問方式

基于CANoe的SOME/IP網絡仿真應用

在殘余總線仿真中，SOME/IP作為復雜的協議和中間件，設計時較為靈活。為了盡可能地降低工程的復雜度，在CANoe中與SOME/IP相關的絕大部分配置都可以自動化完成，前提條件是標準格式的數據庫文件（比如FIBEX或ARXML）。CANoe中SOME/IP的仿真功能基于SomeIP_IL.dll以及CANoeILNL_AUTOSAR_ETH.DLL實現，可在Simulation Setup中將上述dll文件分配給對應的仿真節點并配置其SOME/IP交互層屬性。

> 在以太網網段里添加FIBEX或ARXML數據庫文件

圖4.1 添加數據庫

> 鼠標右擊數據庫文件，選擇Node Synchronization，選擇需要創建的節點，點擊>>按鈕，點擊Next、Finish即可

圖4.2 創建仿真節點

> 在Simulation Setup界面，鼠標右擊bus node分配相應的dll文件（dll文件存儲在CANoe安裝目錄下Exec32文件夾中）

圖4.3 分配dll文件

至此，一個完整的殘余總線仿真環境已經搭建完成。用戶還可以通過右擊Network node，選擇Component Configuration，修改服務的發送方式，如圖5所示，服務發現以及訂閱后的通知就會周期性的發送，進一步的功能還可以通過CAPL編程實現，例如讀寫信號值，調用Method等。

圖5 配置IL屬性

在CANoe->Trace窗口可以查看SOME/IP的通信過程，如圖6所示。

圖6 Trace窗口

CANoe 11.0版本中新增一個EthernetNetwork Monitor分析窗口，可以方便地查看SOME/IP各節點的訂閱關系和相關服務信息，如圖7所示。

圖7 Ethernet Network Monitor

如果沒有數據庫或者數據庫不完整的話，CANoe也可以直接通過相關dll文件封裝好的函數，利用CAPL去創建服務（Event/Method），以及實現Event的觸發發送和Method的調用，相關函數在CANoe的幫助文檔中都有示例可供參考，如圖8所示。

圖8 CAPL腳本

利用測試工具實現靈活的訪問網絡

利用測試工具能夠以最優的方式去實現復雜的測試任務，比如殘余總線仿真，需要工具可以靈活、高效地訪問物理媒介，如圖9所示。通過對物理媒介的訪問，開發人員可以修改網絡上傳輸的數據來生成錯誤的測試用例（如CRC錯誤）。但如果僅僅只是監測分析兩個節點之間的通信行為，則需要一種特殊的測量方法來實現透明、無干擾的訪問物理媒介。雖然邏輯上Open Alliance BroadR-Reach（OABR）是一種總線系統，但從物理層角度來看屬于點對點連接，所以這種特殊的測量方法是很有必要的。解決方案之一是在系統中使用的交換機上增加一個額外的監控端口，但由于成本原因，不是所有交換機都會預留監控端口。在這種解決方案中，交換機會將所有接收到的數據轉發到監控端口，從而產生兩個問題：一是轉發的數據沒有共同的時間基準，因為沒有時戳；二是交換機只會將有效的數據轉發給監控端口，導致對一些錯誤的分析變得困難。

圖9 VN5610在不同應用案例中的使用

為了最大限度地減小媒介訪問對網絡分析的影響，引入了一種名為TAP（TestAccess Point）的分析方法。與標準的數據轉發不同，通過TAP可以在不影響節點通信的前提下透明地分析網絡，如圖9所示。根據具體需求，TAP可以工作在兩種不同的模式：

> 被動模式：可以保證恒定的較短的延遲時間，但是只能監聽物理媒介。

> 主動模式：在數據轉發過程中可以插入額外數據，但是會有一定的延遲。

由于主動模式要對數據流進行處理，而流控涉及到了數據鏈路層（OSI Layer2），因此不能用在物理層（OSI Layer1）。與此同時，流控不能保證恒定的等待時間。無論選擇哪一種模式，為了盡可能精確地分析PacketData（分組數據），都需要獲得盡可能接近物理層的精確時間戳。由于網絡分析通常關注多個以太網路徑，同時還需考慮汽車上其他的總線網絡，因此這些時間戳必須要與其他接口設備進行同步。

選擇合適的開發工具

基于以上的考慮，每個開發者在選擇相應的開發工具時都可以先思考下面五個問題：

> 工具是否能夠支持面向服務的通信，比如SOME/IP？

> 工具是否能夠提供日志記錄以及在有或者沒有違反協議的情況下控制仿真？

> 工具是否能夠支持訪問主流的車載網絡，如OABR，CAN，FlexRay和MOST？

> 接口是否可以靈活的用作鏡像的TAP轉換器以及交換機？

> 支持多種網絡類型的接口是否能夠與常用的總線系統和IP網絡同步？

軟件CANoe.Ethernet與硬件VN5610A/VN5640可以滿足上述的所有要求。通過CANoe.Ethernet可以實現以太網通信的監測、以太網節點仿真、以太網數據鏈路層及其上層協議測試。以太網接口卡VN5610A包含兩路以太網通道和兩路高速CAN/CAN FD通道，VN5640接口卡支持16路以太網通道和兩路高速CAN/CAN FD通道。16路以太網中包含12路車載以太網通道和4路標準以太網通道。VN5640可工作于Standalone模式下，脫離上位機實現2層交換機的報文轉發功能，同時還提供數字/模擬IO通道。Vector一直致力于為用戶提供高效優質的產品和服務，CANoe.Ethernet與VN5610A/VN5640的組合在行業中得到了廣泛應用。