車載以太網(wǎng)SOA架構下ECU間的互通性研究

作者簡介：糜斌（1971— ），男，江蘇揚州人，工程師，學士；研究方向：車載以太網(wǎng)。

摘要：文章從車載以太網(wǎng)SOA架構下AUTOSAR與GENIVI的關系出發(fā)，闡述了采用不同類型SOME/IP協(xié)議棧的設備之間實現(xiàn)互通的需求。通過對實際項目中互聯(lián)問題的深入分析，揭示了問題來源，給出相應場景下的解決方法。最后，文章提出了工具化檢查方法，以利于采用不同協(xié)議棧設備之間的互聯(lián)互通。

關鍵詞：車載以太網(wǎng)；SOA架構；SOME/IP協(xié)議

中圖分類號：中圖分類號 文獻標志碼：文獻標志碼

0 引言

車載以太網(wǎng)適合用于橋接車內多個域的骨干網(wǎng)絡［1］。服務導向架構（Service Oriented Architecture，SOA）有助于構建靈活可變的平臺系統(tǒng)。SOA架構下車內ECU之間的互聯(lián)互通，可能會面臨不同的框架、不同的信息交互需求表述格式、不同的SOME/IP協(xié)議棧等方面的問題，需要對其進行研究。

1 項目背景與互聯(lián)需求

2020—2021年，筆者參與開發(fā)某車載以太網(wǎng)項目，車載以太網(wǎng)拓撲，如圖1所示。IVI通過Switch與IVC，Meter，DVR，HUD相連。

IVI與其他ECU間通過SOME/IP交互信息。由于設備架構不同，所以存在互操作性問題。在AUTOSAR與GENIVI框架下，采用不同接口定義語言的設備綁定各自的SOME/IP協(xié)議棧實現(xiàn)信息交互的示意圖，如圖2所示。

項目組遵循TC8 V3.0 ［4］標準，對IVI采用的協(xié)議棧能否通過SOME/IP_ETS測試進行了評估。測試結果表明vsomeip3是可用的。

2 互聯(lián)問題分析歸類

在系統(tǒng)聯(lián)調階段，ECU間不能正常交互的問題較多。通過分析，這些問題歸類如下：

2.1 測試規(guī)范的版本問題

有部分設備的ETS測試采用的是TC8V2.0版本。與V3.0相比，V2.0在一些細節(jié)方面定義不清晰，不能保證協(xié)議棧細節(jié)實現(xiàn)上的一致性。

2.2 協(xié)議棧配置問題

vsomeip3增加了對E2E［5］的支持，但需要在json配置文件中對E2E進行配置，且要求client端和server端的E2E配置一致。有部分設備采用的是XML格式的配置文件，其中E2E配置的profile參數(shù)項不一致導致協(xié)議棧不能正常解析E2E Header，造成互聯(lián)問題。

2.3 協(xié)議棧完成度問題

SOME/IP并不是“1個”協(xié)議，SOME/IP包含多個部分：SOME/IP基本協(xié)議［6］、SOME/IP-SD服務發(fā)現(xiàn)協(xié)議［7］、SOME/IP-TP傳輸協(xié)議［8］等。無論是TC8V2.0還是V3.0，其對SOME/IP協(xié)議棧的測試用例針對的是基本協(xié)議和服務發(fā)現(xiàn)協(xié)議，后來被AUTOSAR納入標準的傳輸協(xié)議并不在其范圍之內。SOME/IP-TP支持在協(xié)議棧層面對大數(shù)據(jù)進行UDP方式傳輸。vsomeip3目前尚未支持SOME/IP-TP，造成互聯(lián)問題。

2.4 中間文件的兼容問題

中間文件作為不同廠家之間表達接口需求的數(shù)據(jù)文件，最好采用同一種標準。但如前述，AUTOSAR采用的是ARXML；GENIVI則是采用FIDL/FDEPL。轉換面臨兼容性問題，F(xiàn)IDL的表達與SOME/ IP的序列化需求存在差距，在面對定長字符串、定長數(shù)組、枚舉基類型以及可選字段的結構時，F(xiàn)IDL/FDEPL與ARXML之間的轉換存在困難，這給不同陣營的設備互聯(lián)帶來了問題。

2.5 原始需求的表達與解讀問題

FIDL/FDEPL與ARXML還不能一一對應，有些地方須參照原始需求來確定序列化。車廠對信息交互的原始需求一般以xlsx文件形式給出。但各家模板不一致導致歧義，造成互聯(lián)問題。

3 互聯(lián)問題的解決

解決方案采用了從上到下、從需求→實現(xiàn)→測試的次序。

3.1 針對原始需求表達

SOME/IP相關的原始需求是在車廠提供的網(wǎng)絡設計規(guī)范中給出的。但信息表述比較分散，格式不夠規(guī)范，通常各ECU開發(fā)方采用各自的xlsx文件模板整理規(guī)格化的SOME/IP需求表格，以便工具的后續(xù)處理。但需求表格會因為理解上的原因或版本更新原因而不一致。

筆者推薦的解決辦法是xlsx文件由服務提供方按統(tǒng)一的模板填寫，并提供給使用方。這樣做有效避免了歧義的產生。

3.2 針對中間文件

在GENIVI與AUTOSAR框架下，從用戶需求→接口定義的中間文件→接口代碼和配置文件的順序（見圖3）。在各自框架下，中間文件都起到了承上啟下的作用。但不同框架下的中間文件轉換存在兼容性問題，對此，可以采用以下兩種方法。

（1）規(guī)避：在xlsx文件中定義業(yè)務相關的接口時，參數(shù)的定義盡量避免引入兼容性問題，如：給字符串/數(shù)組加入長度定義。

（2）后處理：在服務接口代碼生成后再處理，如：根據(jù)FIDL/FDEPL生成的接口代碼中枚舉基類型與基于ARXML生成的代碼中類型不一致時，對生成的代碼進行手動修改/工具軟件掃描修改。

FIDL/FDEPL規(guī)范定義也在不斷完善中，最新資料表明，F(xiàn)DEPL文件中可以設置EnumBackingType來改變枚舉的默認數(shù)據(jù)類型，這樣枚舉基類型的問題就不復存在了。

3.3 針對協(xié)議棧完成度

vsomeip3不支持SOME/IP-TP，但項目最初需求中存在超長的UDP數(shù)據(jù)報文。針對不同情況，可以采用以下3種對策。

（1）規(guī)避：在定義業(yè)務相關的接口時，對采用UDP傳輸?shù)臄?shù)據(jù)包長度進行檢查，確保數(shù)據(jù)包長度不超過1 400字節(jié)。

（2）調整傳輸方式：部分消息的傳輸方式改成TCP。

（3）引入其他協(xié)議處理：基本信息采用SOME/IP傳輸，而擴展信息采用TFTP傳輸。

3.4 針對協(xié)議棧配置

協(xié)議棧的配置與協(xié)議棧的具體實現(xiàn)關系很大。如問題中提到的E2E配置項，在本地配置是完整的，但與對端配置不一致，造成雙方不能正常交互信息，將E2E的profile配置項更正一致后，這個問題就解決了。

配置不正確或者不一致會導致很多莫名其妙的問題，需要認真檢查。

3.5 針對測試驗證

統(tǒng)一按TC8V3.0進行SOME/IP_ETS測試，以保證一致性。

在測試過程中，有時需要分析是協(xié)議棧在實現(xiàn)方面的問題還是測試程序的問題。在進行SOMEIP_ETS_034：echoUINT8E2E測試時，就出現(xiàn)了E2E Header數(shù)據(jù)順序錯誤的情況。好在TC8V3.0比V2.0中多了對echoUINT8E2E_req的參數(shù)順序的明確規(guī)定，采用抓取測試程序發(fā)出的數(shù)據(jù)包進行比對的方法明確了是測試程序的問題，更正測試程序后問題解決。

4 檢查工具的開發(fā)

在對SOA架構下采用不同SOME/IP協(xié)議棧的設備互聯(lián)問題的分析與解決過程中，筆者萌生了開發(fā)檢查工具的想法。檢查工具可以將項目中積累的知識經(jīng)驗保留下來，在以后的項目中發(fā)揮作用，提高開發(fā)效率。

當前，檢查工具包括如下模塊：（1）xlsx需求文件檢查模塊。對格式規(guī)范的檢查和信息完整性檢查。（2）ARXML文件檢查模塊。檢查是否存在FIDL/FDEPL文件不支持的定義。（3）FIDL/FDEPL文件檢查模塊。檢查FIDL和FDEPL文件之間的一致性。（4）協(xié)議棧管理模塊。管理各協(xié)議棧的基本信息及協(xié)議棧對規(guī)范的完成情況。（5）json配置文件檢查模塊。檢查格式正確性和配置項完整性。

5 結語

本文通過對車載以太網(wǎng)實際項目中ECU間互聯(lián)問題的分析，給出了解決方案。檢查工具的開發(fā)則進一步提高了解決互聯(lián)問題的能力和效率。車載以太網(wǎng)在不斷發(fā)展，SOA架構下ECU間的互通性研究不會止步。

參考文獻

［1］CHARLES M，ROBERT B，JEFFREY Q.Automotive Ethernet-The Definitive Guide［M］.America：Intrepid Control Systems，2014.

［2］AUTOSAR.ARXML Serialization Rules 4.3.1［EB/OL］.（2017-12-08）［2022-10-27］.https：//www.autosar.org/fileadmin/user_upload/standards/classic/4-3/AUTOSAR_TPS_ARXMLSerializationRules.pdf.

［3］Wiki.Franca IDL［EB/OL］.（2018-04-13）［2022-10-27］.https：//www.detailedpedia.com/wiki-Franca_IDL.

［4］OPEN ALLIANCE.Automotive Ethernet ECU TestSpecification V3.0［EB/OL］. （2020-05-08）［2022-10-27］.http：//www.opensig.org/download/document/275/OA_Automotive_Ethernet_ECU_TestSpecifications_Version_3.0.zip.

［5］AUTOSAR.E2E Protocol Specification R19-11［EB/OL］.（2017-10-27）［2022-10-27］.https：//www.autosar.org/fileadmin/user_upload/standards/foundation/19-11/AUTOSAR_PRS_E2EProtocol.pdf.

［6］AUTOSAR. Requirements on SOME/IP Protocol［EB/OL］.（2020-11-30）［2022-10-27］.https：//www.autosar.org/fileadmin/user_upload/standards/foundation/20-11/AUTOSAR_RS_SOMEIPProtocol.pdf.

［7］AUTOSAR.SOME/IP Service Discovery Protocol Specification［EB/OL］. （2017-03-31）［2022-10-27］.https：//www.autosar.org/fileadmin/user_upload/standards/foundation /1-1/AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol.pdf .

［8］AUTOSAR.Specification on SOME/IP Transport Protocol［EB/OL］.（2017-10-27）［2022-10-27］.https：//www.autosar.org/fileadmin/user_upload/standards/classic/21-11/AUTOSAR_SWS_SOMEIPTransportProtocol.pdf.

（編輯 姚 鑫）

Abstract： Starting from the relationship between AUTOSAR and GENIVI under the on-board Ethernet SOA architecture， this article elaborates on the requirements for interoperability between devices using different types of SOME/IP protocol stacks. Through in-depth analysis of interconnection issues in actual projects， the sources of the problems were revealed and corresponding solutions were provided in the corresponding scenarios. Finally， the article proposes a tool based inspection method to facilitate interconnectivity between devices using different protocol stacks.

Key words： vehicle Ethernet; SOA architecture; SOME / IP protocol