Autosar以太網(wǎng)及SOME/IP實現(xiàn)?

MICROSAR ETH 簡介

以太網(wǎng)即 ETH （Ethernet） 是 MICROSAR (*MICROSAR 是由Vector 開發(fā)的一套符合 AUTOSAR 標 準的基礎軟件代碼包，包含了 MICROSAR.RTE 以及 MICRO- SAR.BSW，覆蓋了 AUTOSAR 的所有標準，還具有一些擴展功能模塊，每一個AUTOSAR 的BSW 模塊都能對應到具體的 MICROSAR 模塊。Vector DaVinci Configurator Pro 工具用于對 MICROSAR 模塊進行具體配置，并生成代碼。*)中的一個 BSW 模塊，其概念是由 Xerox 公司創(chuàng)建并由 Xerox、Intel 和 DEC/' 公司聯(lián)合開發(fā)的基帶局域網(wǎng)規(guī)范，是當今現(xiàn)有局域網(wǎng) 采用的最通用的通信協(xié)議標準。

圖1 汽車以太網(wǎng)

圖2 以太網(wǎng)無線充電
以太網(wǎng)包括標準的以太網(wǎng) （10Mbit/s）、快速以太網(wǎng)（100Mbit/s）和 10G（10Gbit/s）以太網(wǎng)。IEEE 組織的 IEEE 802.3 標準制定了以太網(wǎng)的技術標準，它規(guī)定了包括物理層的連線、電子信號和介質(zhì)訪問層協(xié)議的內(nèi)容。

圖3 Vector全棧解決方案
AUTOSAR 對于車載以太網(wǎng)的架構提出了新的解決方案，不同于計算機網(wǎng)絡通信的 7 層 OSI 架構模型，AUTOSAR 規(guī)范首次提出了一種適用于車載以太網(wǎng)的 TCP/IP 模型。如圖 4 所示，以太網(wǎng)在 OSI 七層模型定義于物理層和數(shù)據(jù)鏈路層，相對應地在 TCP/IP 模型中處于網(wǎng)絡接口層。由于 OSl 七層模型對于車用網(wǎng)絡架構而言過于復雜，而 AUTOSAR 使用的TCP/IP 模型更貼近實用，故其在車載以太網(wǎng)領域獲得了更廣泛的應用。

圖4 OSI 模型與車載以太網(wǎng) TCP/IP 模型
在 TCP/IP 模型中，網(wǎng)絡通信架構被分為 4 層，其中應用層是應用程序訪問網(wǎng)絡的通道，常見FTP、HTTP、DNS 和TEL- NET 協(xié)議，AUTOSAR 內(nèi)還包含了 SOME/IP、DoIP 和 XCP 等 協(xié)議；傳輸層主要指的是 TCP 協(xié)議和 UDP 協(xié)議；網(wǎng)絡層包括 IP 協(xié)議，ARP、RARP 協(xié)議，ICMP 協(xié)議等；網(wǎng)絡接口層是 TCP/ IP 協(xié)議的基層，負責數(shù)據(jù)幀的發(fā)送和接收。

車載以太網(wǎng) SOME/IP 協(xié)議簡介

SOME/IP（Scalable service-Oriented MiddlewarE over IP） 是車載以太網(wǎng)通信領域的一個概念，是一種位于應用層的通信協(xié)議。在目前主流的以 CAN 總線為主的車載網(wǎng)絡中，通信過程是面向信號的（除了診斷通信之外），這是一種根據(jù)發(fā)送者需求實現(xiàn)的通信過程，當發(fā)送者發(fā)現(xiàn)信號的值變化了或者到達預定的發(fā)送周期，就會向外發(fā)送該信號，而不考慮接收者是否有需求。而 SOME/IP 則不同，它是在接收方有需求的時候才發(fā)送，這種協(xié)議使得總線上不會出現(xiàn)過多不必要的數(shù)據(jù)收發(fā)，從而有效地降低總線負載。在車載網(wǎng)絡中，某個 ECU 有時會需要調(diào)用實現(xiàn)在其他 ECU 上的服務，此時兩個ECU 就分別扮演了網(wǎng)絡通信中client 和 server 的角色，而 SOME/IP 就是實現(xiàn)這種遠程服務調(diào)用的接口，如圖 5 所示。

圖 5 SOME/IP 通信示意圖
從圖 5 和圖 6 可以看出，SOME/IP 本質(zhì)上是構架在傳輸層之上的應用層通信協(xié)議，它是位于TCP/UDP 報文的Payload 部分內(nèi)的。

圖 6    SOME/IP報文位置
SOME/IP數(shù)據(jù)的 Header 部分的 Message Type  字段是 SOME/IP 功能實現(xiàn)的重要部分，其長度為 8 bit，有以下五種取值：REQUEST（期待響應的請求）、REQUEST_NO_RETURN （不期待響應的請求）、NOTIFICATION     （事件通知）、RE- SPONSE（響應消息）和 ERROR（報錯消息）。

圖 7 SOME/IP 協(xié)議通信方法
如圖 7 所示，當 ECU A 作為 Client 端對 ECU B 的某個服務有需求時，發(fā)送一個Request 消息，之后ECU B 作為Ser- ver 端根據(jù)接收到的 Request 類型決定是否返回一個 Re- sponse 消息。在二者經(jīng)過上述通信沒有發(fā)生錯誤后，首先由 Client 向 Server 訂閱服務內(nèi)容，然后 Server 向 Client 自動發(fā) 布服務內(nèi)容。3 實現(xiàn)方法 MICROSAR ETH 模塊功能的實現(xiàn)需要一個上位機與單片機上的 ETH 模塊進行信息交互，為了更好的進行交互過程觀察和單片機上的變量觀察，本文使用德國 Vector 公司的產(chǎn)品 VN5640 配合電腦上的 CANoe 軟件作為上位機。

圖 8 實現(xiàn)方法示意圖
在 MICROSAR 中，DaVinci 配置工具將以太網(wǎng)相關的配置內(nèi)容分為如圖 9 所示的多個分層模塊結構。用戶需要自下而上進行配置，即從底層的Eth 收發(fā)器、接口和驅(qū)動模塊開始， 之后配置網(wǎng)絡傳輸協(xié)議 TCP/IP 模塊，配置對 TCP/IP 協(xié)議進行封裝的SoAd 模塊，然后將其和信號相關的PduR、Com 模塊相互配合，最后和上層的 SOME/IP 協(xié)議應用相關聯(lián)。其設計路線與上文 MICROSAR 提出的車載以太網(wǎng) TCP/IP 模型結構的順序基本符合。

圖 9 MICROSAR 配置工具的分層模塊架構
因此，本文采用的技術路線如下：（1）使用Vector DaVinci 開發(fā)工具搭建操作系統(tǒng)，實現(xiàn)RTE、任務配置和運行實體的映射，配置應用層用于測試的簡單應用；
（2）配置 Eth/EthIf/EthTrcv 模塊，即以太網(wǎng)通信底層模塊，包括以太網(wǎng)接口、以太網(wǎng)收發(fā)器和以太網(wǎng)驅(qū)動的相關配置；
（3）配置 TCP/IP 模塊，即以太網(wǎng)通信協(xié)議，對傳輸層和網(wǎng)絡層進行配置。
（4）配置 SoAd 模塊，每一條 TCP 連接通過一個雙向的通信連接實現(xiàn)數(shù)據(jù)的交換，連接的兩個端點稱為一個 Socket。其本質(zhì)是編程接口（API），即一種對 TCP/IP 的封裝。
（5）配置信號定義（該步驟用于SOME/IP 通信），主要通過以太網(wǎng)描述文件(.arxml)完成，通過 Com 相關模塊和 Pdu 相關模塊進行配置實現(xiàn)其具體功能。
（6）在 Tasking 編譯器中集成靜態(tài)代碼以及配置工具生成 的代碼，生成可執(zhí)行文件；
（7）使用調(diào)試工具進行測試驗證，使用 CANoe 對所需變量進行觀測；
本文設計了如下方案以驗證 ETH 基礎通信及 SOME/IP 通信的功能的正確性。在驗證ETH 基礎通信功能時，如下圖所示，設計了一個以太網(wǎng)接收數(shù)據(jù)的中斷服務，即每當單片機成功接收到上位機發(fā)來的以太網(wǎng)報文后，產(chǎn)生一個二類中斷。為了驗證以太網(wǎng) 基礎通信在UDP 和TCP 兩種協(xié)議下均可正常工作，故設計適用于 UDP 和 TCP 兩種協(xié)議的中斷服務程序，在其內(nèi)部調(diào)用以太網(wǎng)發(fā)送函數(shù)SoAd_IfTransmit()，即當單片機成功接收到上位機發(fā)來的以太網(wǎng)報文后，立刻向外發(fā)出一個以太網(wǎng)報文，本文設計發(fā)送內(nèi)容與接收到的數(shù)據(jù)一致，以此驗證以太網(wǎng)基礎通信的收發(fā)功能。

圖 10 驗證通信功能的中斷服務程序及任務的簡單代碼

圖 11 測試系統(tǒng)示意圖

• ETH 基礎通信測試
  

圖 12 UDP Message
在單片機運行的程序中添加代碼，目的是使單片機收到上位機CANoe 發(fā)送來的數(shù)據(jù)時，直接將收到的數(shù)據(jù)轉發(fā)出去， 即發(fā)回 CANoe。這樣只要分別對比在 UDP 與 TCP 協(xié)議下， 發(fā)送與接收到的 UDP/TCP 的 Payload 數(shù)據(jù)是否一致，以及 UDP/TCP 的Header 部分是否相互匹配，即可確認以太網(wǎng)基礎 通信功能是否正常。點擊 CANoe 的運行按鍵，在 Trace 窗口可以看到以太網(wǎng)網(wǎng)絡的數(shù)據(jù)幀，Trace 結果的片段如下圖所示。在 Trace 窗口中點擊任意一幀接收報文Rx，可以在Detail View 中查看UDP報文和 TCP 報文的詳細信息，從圖 13 中可以看到幀類型、物理地址、本地和目標地址及其端口，在 UDP 與 TCP 下的 Pay- load 是主要的用戶數(shù)據(jù)。

圖 13 UDP 報文 Trace

在 UDP 協(xié)議下，將 CANoe 接收到的數(shù)據(jù)報文與之前預設在 CANoe 中發(fā)送的數(shù)據(jù)報文進行對比，可以看出兩者的 Payload 部分相同，其他部分嚴格對應無誤。在 UDP 協(xié)議下，將 CANoe 接收到的數(shù)據(jù)報文與之前預設在 CANoe 中發(fā)送的數(shù)據(jù)報文進行對比，可以看出兩者的 Payload 部分相同，其他部分嚴格對應無誤。

圖 14 TCP 報文 Trace

• 以太網(wǎng) SOME/IP 通信測試
  

通過網(wǎng)線將 VN5610 與 TC397 單片機相連接，另一端通過數(shù)據(jù)線將 VN5610 與電腦相連接。首先測試從 TC397 單片機向外發(fā)送數(shù)據(jù)，在代碼中聲明要發(fā)送的信號為如圖 10 所示結構體 aSOAData_RDA_HSC4_S00，賦值為｛1，0，0，4｝。正常運行單片機之后，可以在 UDE 調(diào)試器中通過 Watches 窗口查看到代碼中設置好的信號的值。保持單片機上的程序正常運行，建立 CANoe 工程。只要分別對比：（1）上位機 CANoe 發(fā)送出的報文，即上述結構體的值，是否被單片機正確接收，即單片機內(nèi)存中該結構體的值與發(fā)送 報文的相應值是否一致。（2）上位機 CANoe 接收到的報文，即上述結構體的值，是否與單片機發(fā)出的報文相應值一致，即上位機中收到的數(shù)據(jù) 是否與單片機內(nèi)存中該結構體的值一致。以及各自的 Header 部分是否相互匹配，即可確認以太網(wǎng)SOME/IP 通信功能是否正常。

圖 15 SOME/IP 通信接收測試

使用 CANoe 的 Trace 窗口觀測報文，和 UDE 調(diào)試器中看到的單片機預設數(shù)據(jù)進行對比?？梢钥吹?CANoe 收到的信號中的結構體與代碼中設置的名稱相同，數(shù)據(jù)｛1，0，0，4｝一致，報文其他部分互相對應無誤。之后測試從上位機CANoe 向單片機發(fā)送數(shù)據(jù)，在CANoe 中利用 CAPL 語言手寫代碼，聲明要發(fā)送的信號為如圖 10 所示結構體 aSOAData_IECU_HSC4_RDA_FrP01，賦值為｛1， 34，51，68｝。正常運行單片機和 CANoe 工程之后，可以在 CA- Noe 的 Trace 窗口查看在 CAPL 語言中設置好的信號的內(nèi)容。

圖 16 SOME/IP 通信發(fā)送測試

小結