章鴻濱,徐旭,黃熙,鐘再敏

(同濟大學汽車學院，上海 200092)

基于AUTOSAR標準的以太網診斷通信實現

章鴻濱,徐旭,黃熙,鐘再敏

(同濟大學汽車學院，上海 200092)

在AUTOSAR標準下實現了基于以太網的診斷，并簡要分析了基于以太網診斷通信的優(yōu)勢。將開源的TCP/IP協(xié)議棧LwIP移植進AUTOSAR的基礎軟件層，在此基礎上，構建基于以太網的通信協(xié)議棧，從下到上依次為以太網驅動、以太網接口、TCP/IP協(xié)議棧、套接字適配器。在以太網通信協(xié)議棧的基礎之上加入與診斷通信相關的模塊，分別是基于IP協(xié)議的診斷、PDU Router 和診斷通信管理，實現基于AUTOSAR標準的以太網診斷通信。并設計相應的診斷上位機測試UDS診斷服務，說明基于以太網診斷通信在大數據量傳輸過程中具有基于CAN診斷通信無可比擬的優(yōu)越性。

AUTOSAR標準；TCP/IP協(xié)議棧；UDS協(xié)議；基于IP協(xié)議的診斷通信

0 引言

車載診斷通信長期以來是以CAN網絡為主，但是CAN網絡的帶寬限制了診斷儀與ECU之間的通信速率，尤其在讀取的故障碼涉及成百上千個字節(jié)的數據時，診斷儀與ECU之間通信的時間開銷亟待優(yōu)化?；谝蕴W的診斷通信將充分利用以太網高帶寬的優(yōu)點，讓診斷儀與ECU之間建立起高速率的數據傳輸通道。文中基于AUTOSAR標準，移植開源TCP/IP協(xié)議棧LwIP到AUTOSAR的軟件架構下，實現了基于以太網和UDS協(xié)議的診斷通信，并對其相關的UDS診斷服務進行測試和驗證。

1 AUTOSAR架構下以太網通信協(xié)議棧

在AUTOSAR架構下以太網的通信協(xié)議棧[1]如圖1下半部

分雙點劃線框所示，其中標準化的模塊包括以太網驅動模塊(Ethernet Driver)、以太網接口模塊(Ethernet Interface)、中間的TCP/IP協(xié)議棧以及套接字適配器模塊(Soaket Adaptor)。這4個模塊都屬于基礎軟件層，其中以太網驅動模塊屬于微控制器抽象層(Microcontroller Abstraction Layer )，以太網接口模塊屬于ECU抽象層，TCP/IP協(xié)議棧和套接字適配器模塊屬于通信服務層。后續(xù)，基于以太網的診斷就是在以太網通信協(xié)議棧進行通信的。考慮診斷應用的實現，以太網通信協(xié)議棧之上還有3個標準的基礎軟件模塊，分別是基于IP協(xié)議的診斷通信(Diagnostic Communication Over IP)、協(xié)議數據單元路由器(PDU Router)和診斷通信管理者(Diagnostic Communication Manager)，如圖1上半部分雙點劃線框所示。

圖1 AUTOSAR架構下基于以太網的診斷通信

1.1 以太網驅動層

以太網驅動層[2]在AUTOSAR架構下屬于基礎軟件層中的微控制器抽象層，提供初始化、配置和數據傳輸服務，是與微控制器類型直接相關的。文中實驗采用的平臺是英飛凌的TC275芯片，主芯片內部帶有以太網MAC層，控制板上集成了以太網物理層芯片TJA1100，如圖2所示。

圖2 TJA1100周邊電路原理圖

因此在對以太網控制器進行初始化的時候，必須對以太網MAC層和物理層芯片同時初始化，并保證兩者工作模式匹配。TC275芯片以太網控制器的工作模式是RMII，因此以太網MAC層和以太網物理層之間數據傳輸用了4根數據線，收發(fā)各占兩根數據線，在RMII模式下以太網數據傳輸的時鐘頻率是50 MHz。以太網MAC層可以通過MDIO控制和讀取物理層芯片的工作狀態(tài)，避免數據鏈路擁堵時傳輸數據，導致數據鏈路進一步惡化。MDIO控制包含兩根線，一根是時鐘線，另一根是數據線，標準情況下時鐘線的時鐘頻率是5 MHz。在初始化以太網物理層芯片時，作者正是利用MDIO初始化以太網物理層芯片內部的寄存器。

1.2 以太網接口層

以太網接口層[3]負責封裝底層以太網控制器的差異包括以太網控制器在硬件上的分布，為上層提供一個統(tǒng)一的接口。如圖3所示，硬件上可能會有多個不同類型的以太網控制器(A、B、C型)存在，以太網接口層主要工作是將底層Ethernet Driver的函數進一步封裝成統(tǒng)一的API，在統(tǒng)一的API中會有一個參數表示不同以太網控制器的ID，方便應用程序中使用不同的以太網控制器。例如下面以太網接口層的標準函數EthIf_SetControllerMode(uint8 CtrlIdx, Eth_ModeType CtrlMode)，它有兩個參數，一個參數CtrlIdx用于指定以太網控制器的ID，另一個參數CtrlMode用于指定該以太網控制器的工作模式。若需設定不同以太網控制器的工作模式，上層模塊調用的API都是一樣的，只需修改參數CtrlIdx。

圖3 以太網接口層

1.3 TCP/IP協(xié)議棧

該部分的主要工作是尋找一個適合嵌入式系統(tǒng)的TCP/IP協(xié)議棧，并把它移植到AUTOSAR軟件架構下。嵌入式設備要連入因特網，它就必須遵循網絡的通信協(xié)議，即TCP/IP協(xié)議。從協(xié)議分層模型方面來講，TCP/IP由4個層次組成：網絡接口層、網絡層、傳輸層、應用層。LwIP是一款主要應用于嵌入式領域開源的TCP/IP協(xié)議棧。

LwIP的移植可以分為兩類：第一類是只移植內核核心，此時用戶應用程序編寫只能基于Raw/Callback API進行；第二類是移植內核核心和上層API函數模塊，此時用戶可以使用所有3種API進行編程，即除了Raw/Callback API外，還有Sequential API和BSD-style socket API。第一種移植比較簡單，移植者只需完成幾個頭文件的定義，同時根據使用的具體的以太網控制器完成驅動的編寫即可。第二種移植在第一種移植的基礎之上，還必須使用操作系統(tǒng)提供的郵箱和信號量機制，完成操作系統(tǒng)模擬層的移植[4]。

AUTOSAR中的OS源于OSEK，在OSEK的OS基礎上加入了調度表、時間保護和內存保護[5]，但是沒有提供郵箱和信號量。因此，若要完成帶操作系統(tǒng)模擬層的LwIP協(xié)議棧的移植，就必須利用AUTOSAR的OS實現郵箱和信號量機制。

1.3.1 郵箱的實現

在LwIP中，上層API函數(應用層調用的API)與協(xié)議棧內核之間的數據交互都是通過郵箱來實現的。郵箱的本質是隊列，它通常支持兩種主要操作：入隊和出隊。入隊操作是把元素添加到隊列中，即投遞消息到郵箱。出隊操作是從隊列中刪除元素，即從郵箱中取消息。隊列遵循先進先出(FIFO)原則，即第一個添加到隊列的元素也是第一個離開隊列的元素。用鏈表來實現隊列，入隊操作就是將節(jié)點添加到鏈表頭，出隊操作就是從鏈表尾刪除節(jié)點。

郵箱中消息的本質是一個指針，API將這個指針傳遞給內核，內核通過這個指針找到相應的數據處理，反之亦然。在操作系統(tǒng)模擬層環(huán)境下，LwIP作為系統(tǒng)的一個任務運行(Tcpip_Task)，該任務完成相關初始化后，會阻塞在一個郵箱上，等待消息、處理數據。這個郵箱內的消息可能來自底層硬件驅動接收到的數據包，也可能來自上層應用程序的API函數調用。當在郵箱內取得消息后，LwIP會對消息進行解析并處理相關的數據，處理結束后任務繼續(xù)阻塞在郵箱上等待下一條消息。

如圖4所示，作者在操作系統(tǒng)中配置了3個任務。Eth_Task負責處理LwIP協(xié)議棧提交上來的信息，它與協(xié)議棧的任務Tcpip_Task之間利用郵箱進行通信。通過郵箱1將信息傳遞給Tcpip_Task。Eth_Task通過郵箱2來獲取Tcpip_Task提交上來的信息。Tcpip_Task為LwIP協(xié)議棧運行所在的任務，負責收發(fā)來自上下層任務的以太網報文。收取消息利用的是郵箱1，發(fā)送消息給應用層利用郵箱2，發(fā)送消息到以太網控制器則直接調用相關API發(fā)送，不利用郵箱機制。NetIf_Task為網絡接口層任務，負責接收以太網的幀，然后將相關的消息發(fā)送到LwIP協(xié)議棧的任務Tcpip_Task，消息遞交給LwIP協(xié)議棧利用郵箱1。

圖4 郵箱的工作圖解

略去一些只運行一次的初始化任務和與以太網診斷無關的任務，自上而下包含了4個任務Bsw_Task、Eth_Task、Tcpip_Task和NetIf_Task，其中包括兩個基本任務(Bsw_Task、NetIf_Task)、兩個擴展任務(Eth_Task、Tcpip_Task)。Bsw_Task任務運行DCM、BswM、EcuM等基礎軟件模塊；Eth_Task任務運行DoIP和Socket Adaptor；Tcpip_Task運行TCP/IP Module和Ethernet Interface；NetIf_Task任務運行以太網控制器驅動。其中Bsw_Task、Eth_Task和NetIf_Task是由調度表(Schedule Table)周期性地調度，調度周期為10 ms。Tcpip_Task由系統(tǒng)初始化時激活，一旦激活就一直駐留在操作系統(tǒng)內核中，根據郵箱中是否有消息需要處理，Tcpip_Task會在睡眠狀態(tài)和運行狀態(tài)間切換。信號量的實現需要操作系統(tǒng)的支持，此處需要定義操作系統(tǒng)事件給信號量使用，同時讓兩個擴展任務關聯(lián)。因為引入了擴展任務，因此需要預估任務堆棧的使用情況，為任務分配合適的堆棧空間,如表1所示。

表1 操作系統(tǒng)任務的堆棧配置

1.3.2 信號量的實現

在使用上層API函數時，上層API函數的實現需要調用內核相關函數來完成，信號量為上層API函數與內核函數執(zhí)行提供了同步與互斥支持。在應用程序調用某個API函數時，例如Socket綁定特定的服務端口bind函數，API函數會阻塞在一個信號量上，同時請求Tcpip任務調用LwIP內核對應的bind函數，當內核函數執(zhí)行完成后，便釋放信號量，這樣原來被阻塞的API函數得以繼續(xù)執(zhí)行。在信號量的實現上，作者引入事件機制，讓協(xié)議棧內核和應用層任務同時綁定同一個事件，并利用相關的算法，實現同步與互斥。

讓操作系統(tǒng)事件EVENT_MASK_OsEvent1關聯(lián)兩個任務Eth_Task和Tcpip_Task。系統(tǒng)在初始化時，會先將信號量分配給Tcpip_Task。如圖5所示，當Eth_Task需要調用Lwip協(xié)議棧的API時， Eth_Task將相關的API調用消息投遞到郵箱后，Eth_Task獲取信號量，但是此時的信號量已經被占用，信號量結構體中used字段的值為1，因此，Eth_Task主動進入等待事件的狀態(tài)。在Eth_Task將相關的消息投遞到郵箱后，Tcpip協(xié)議棧進行處理，調用協(xié)議棧的API，處理完成后，將被Tcpip_Task占用的信號量釋放。同時，激活Eth_Task等待的事件，使Eth_Task繼續(xù)運行。

圖5 信號量的實現圖解

1.4 套接字適配器

套接字適配器[6]是介于TCP/IP 協(xié)議棧和DoIP之間的模塊，它負責建立診斷通信時需要用到的Socket連接，Socket連接既可以基于UDP協(xié)議，也可以基于TCP協(xié)議，取決于DoIP中用該連接進行通信的服務是采用UDP協(xié)議還是TCP協(xié)議，具體可以參看標準文檔ISO13400。套接字適配器在接收到診斷相關的報文后，會向上遞交給DoIP模塊，DoIP處理的報文形式是PDU，因此套接字適配器需要將Socket連接的報文轉化成PDU報文。套接字適配器中Socket連接數是靜態(tài)配置的，連接的個數可以根據需要自行定義，以滿足需求為準，因為過多的連接會占用大量的內存。

套接字適配器具有自己的調度函數SoAd_MainFunction()，該調度函數需要被任務周期性地運行。套接字適配器負責建立和維護Socket連接，開發(fā)板作為服務端，套接字適配器新建完Socket連接后，綁定特定的端口號會進入監(jiān)聽狀態(tài)，等待客戶端的連接請求。

2 基于AUTOSAR標準的以太網診斷通信

2.1 基于AUTOSAR標準的以太網診斷通信協(xié)議棧

如前文所述，基于AUTOSAR標準的以太網診斷通信協(xié)議棧是建立在之前的以太網通信協(xié)議棧之上，它在以太網通信協(xié)議棧之上還有3個標準的基礎軟件模塊，分別是DoIP、PduR和DCM。

2.1.1 DoIP

DoIP[7]是基于IP協(xié)議的診斷，是標準文檔ISO13400-2的具體實現。進入DoIP的PDU報文結構如表2所示。

表2 DoIP的報文結構

DoIP模塊接收到報文后，會根據裝載信息類型值來解析裝載信息的具體內容，如表3所示。不同的裝載信息類型對應著不同的傳輸層協(xié)議，ISO13400里做了具體的規(guī)定，例如與診斷相關的裝載信息類型(0x8001-0x8003)規(guī)定必須是基于TCP協(xié)議的連接。DoIP中保存了一張連接許可表，包含診斷儀和ECU的地址，用于判斷當前診斷儀請求的連接是否合法。診斷儀在與DCM取得通信之前，必須激活DoIP的路由服務即請求激活路由(0x0005)，這樣發(fā)送給DCM的診斷報文，即裝載信息類型值等于0x8001的報文才會經PDU Router模塊路由到DCM模塊。DoIP與診斷儀之間的連接是有時間窗口的，因此若要保持長時間的連接，需要發(fā)送請求保持連接的報文(0x0007)，請求保持會話窗口。

表3 裝載消息的類型

2.1.2 PDU Router

PDU Router[8]模塊是PDU報文轉發(fā)的模塊，處理不同通信系統(tǒng)(CAN，Lin，Eth和FlexRay)之間或者不同模塊(Com，CanTp，CanIf和DoIP等)的通信數據包。PDU Router沒有自己的調度函數(MainFunction)，也沒有自己的Buffer，不對報文內容做任何處理，只是根據內部維護的一張靜態(tài)的路由表進行PDU的轉發(fā)。

2.1.3 DCM

DCM[9]是實現AUTOSAR診斷通信功能的核心模塊，DCM收到支持的診斷服務請求時，通過調用診斷事件管理者(Diagnostic Event Manager)、應用層軟件組件或者其他基礎軟件模塊提供的接口，進行相應的故障診斷處理操作。在DCM模塊中包含3個子模塊，分別是診斷會話DS(Diagnostic Session)、診斷服務調度DSD(Diagnostic Service Dispatcher)、診斷服務處理DSP(Diagnostic Service Processing)。DS模塊負責與PDU Router的交互，接收從PDU Router轉發(fā)來的請求報文并將處理后的響應報文發(fā)出,管理整個診斷對話的狀態(tài)，確保診斷協(xié)議的時間性要求。DSD模塊作為一個中間模塊，負責將診斷請求從DS模塊轉發(fā)到DSP模塊中處理，并將DSP處理完診斷請求產生的響應報文轉發(fā)給DS模塊。DSP模塊是實際處理診斷服務請求的模塊，分析接收到的請求信息，檢查信息格式和請求服務是否支持，通過調用DEM、應用層軟件組件或者其他基礎軟件模塊提供的接口，進行相應的故障診斷處理操作。

文中采用的診斷服務協(xié)議是UDS，DCM模塊的實質是在內存中維護一張UDS診斷的服務表，根據接收到的診斷儀的診斷服務請求報文做出相應的處理，其中包含了診斷會話和安全訪問的管理。常見的UDS服務見表4。

表4 常用的UDS服務

2.2 以太網診斷通信的測試

以太網診斷通信的測試工具采用MFC進行開發(fā)，MFC(Microsoft Foundation Classes)是微軟基礎類庫的簡稱，診斷測試的上位機界面如圖6所示。從面向對象編程的角度看，類是對象的抽象，而對象是類的具體化，是類的實例[10]。一個CAsyncSocket對象就是CAsyncSocket類的一個實例，它最核心的成員是Windows套接字。除套接字本身外，它還封裝了所有與套接字直接相關的WinSock函數和各種網絡事件的處理函數，其中的網絡事件處理函數又被稱為回調函數或通知函數。當網絡事件發(fā)生時，MFC會自動調用套接字對象中相應的回調函數。

在進行診斷通信測試前，先用Ping命令測試下LwIP協(xié)議棧的IP層是否正常工作，開發(fā)板設置的IP地址是192.168.1.2，主機在進行測試時必須保證網卡的IP地址和開發(fā)板的IP地址在同一網段，如圖7所示。

診斷客戶端的服務器IP設置為192.168.1.2，點擊連接按鈕，此時診斷上位機與開發(fā)板經過3次TCP的握手，與Socket Adaptor模塊建立連接。點擊激活按鈕，診斷上位機會發(fā)送包含診斷儀自身地址和請求訪問的ECU的地址，DoIP收到請求激活的報文，經過認證后，后續(xù)有關診斷的報文就會從DoIP經PDUR路由到DCM模塊。此后，用戶可以通過點擊界面上不同的按鈕發(fā)送UDS診斷服務請求，與ECU進行診斷通信。

圖6 診斷測試的上位機界面

圖7 測試電腦與開發(fā)板的網絡連接

關于UDS診斷服務的測試結果如表5所示。最后一行測試讀取特定DTC快照信息，該測試中DTC(0x000001)包含3個字節(jié)長度，其包括24個快照信息，用于記錄出現該故障時系統(tǒng)此刻的一些狀態(tài)信息，該快照信息ID的編號從0x0d00到0x0d17，每個快照信息占一個字節(jié)，不過分配給每個快照信息的存儲空間是4個字節(jié)，這樣出現故障時可以通過讀取DTC的快照信息查看出現故障前3個測試循環(huán)的快照信息[11]。該測試中，人為注入系統(tǒng)故障，對應于快照信息0x0d00記錄的系統(tǒng)狀態(tài)。當診斷儀向ECU發(fā)送讀取DTC快照信息的診斷請求時，ECU需要向診斷儀發(fā)送152字節(jié)的DTC信息，以太網可以通過一幀報文將所有的DTC信息發(fā)送給診斷儀，但是如果采用CAN網絡進行傳輸，至少需要二十幾幀的CAN報文才能完整地將DTC信息發(fā)送給診斷儀。由此可見，在長報文傳輸過程中，以太網通信具有CAN無法比擬的優(yōu)越性，因此在診斷通信中采用以太網進行通信是很有意義的。

表5 UDS診斷服務的測試結果

3 結束語

在AUTOSAR標準下，實現了基于以太網和UDS協(xié)議的診斷通信，并對相關的UDS診斷服務進行測試和驗證。采用AUTOSAR軟件架構，有利于基礎軟件模塊的復用，提高軟件的可移植性?；谝蕴W的診斷通信，充分利用以太網高帶寬、傳輸可靠的優(yōu)點，讓診斷儀與ECU之間建立起高速率、可靠的數據傳輸通道，在車載診斷中是很有意義的。

【1】AUTOSAR Administration. Specification of TCP/IP Stack V1.1.1[EB/OL].http://www.autosar.org/.

【2】AUTOSAR Administration.Specification of Ethernet Driver V1.5.0[EB/OL].http://www.autosar.org/.

【3】AUTOSAR Administration.Specification of Ethernet Interface V2.2.0[EB/OL].http://www.autosar.org/.

【4】朱升林，歐陽駿，楊晶.嵌入式網絡那些事[M].北京：中國水利水電出版社，2015.

【5】AUTOSAR Administration.Specification of Operating System V5.0.0[EB/OL].http://www.autosar.org/.

【6】AUTOSAR Administration.Specification of Socket Adaptor V2.2.0[EB/OL].http://www.autosar.org/.

【7】AUTOSAR Administration.Specification of Diagnostic over IP V1.2.0[EB/OL].http://www.autosar.org/.

【8】AUTOSAR Administration.Specification of PDU Router V4.2.0[EB/OL].http://www.autosar.org/.

【9】AUTOSAR Administration.Specification of Diagnostic Communication Manager V5.2.0[EB/OL].http://www.autosar.org/.

【10】楊傳棟,張煥遠.Windows網絡編程基礎教程[M].北京:清華大學出版社,2015.

【11】AUTOSAR Administration.Specification of Diagnostic Event Manager V5.2.0[EB/OL].http://www.autosar.org/.

Implementation of Ethernet Diagnostic Communication Based on AUTOSAR Standard

ZHANG Hongbin,XU Xu, HUANG Xi,ZHONG Zaimin

(Automotive Colleges,Tongji University, Shanghai 200092,China)

Ethernet diagnostic communication based on the AUTOSAR standard was realized and the advantages of Ethernet diagnostic communication were analyzed briefly.The open source TCP/IP protocol stack LwIP was transplanted into the AUTOSAR basis software layer, and then the communication protocol stack based on Ethernet was built which included the Ethernet driver, Ethernet interface, TCP/IP protocol stack , socket adapter.The module of the diagnosis communication was added on the basis of the Ethernet communication protocol stack.Finally, the corresponding upper computer was designed to test the UDS diagnosis services.It is proved that Ethernet diagnostic communication is better than CAN diagnostic communication in the large data transmission process.

AUTOSAR standard;TCP/IP protocol stack;UDS protocol; Diagnostic communication over IP

2016-09-26

國家科技支撐計劃資助項目(2015BAG17B00)；國家自然科學基金資助項目(51075301)

章鴻濱(1991—)，男，碩士研究生，研究方向為基于AUTOSAR標準的車用控制器開發(fā)和以太網診斷通信。E-mail：15000137017@163.com。

10.19466/j.cnki.1674-1986.2017.01.001

U463.67

A

1674-1986(2017)01-003-06