基于AUTOSAR自適應平臺的PREEvision通信建模方法和原理研究

【摘" 要】文章以SOMEIP服務通信為例，主要介紹如何通過PREEvision工具開發滿足AUTOSAR AP標準的通信模型，以流程為導向，從機器部署、網絡設計和服務實例3個方面剖析建模方法，以OSI模型為切入點，從物理層到應用層的5層結構角度，配合實際ARXML的表現，研究AUTOSAR AP的實現機制、理念以及PREEvision建模配置當中的原理，并評估建模過程中的重點關注項。

【關鍵詞】PREEvision；自適應平臺；通信；建模；AUTOSAR

中圖分類號：U463.6" " 文獻標識碼：A" " 文章編號：1003-8639（ 2024 ）04-0048-03

PREEvision Communication Modeling Based on AUTOSAR AP Research on Methods and Principles

CHUAI Mengyang，GUAN Jing，KONG Xiangming，LI Guohui，LI Changlong，LI Xiang

（China FAW Corporation Limited，Chuangchun 130011，China）

【Abstract】The article takes SOMEIP service communication as an example and mainly introduces how to develop a communication model that meets the AUTOSAR AP standard through the PREEvision tool. It analyzes modeling methods from three aspects：machine deployment，network design，and service instance based on a process-oriented approach. From the perspective of the OSI model as a starting point，the five-layer structure from the physical layer to the application layer is studied，along with the actual representation of ARXML. The implementation mechanism and concept of AUTOSAR AP，as well as the principles in PREEnvision modeling configuration，are studied，and evaluate the key focus items during the modeling process.

【Key words】PREEvision；AP；communication；modeling；AUTOSAR

1" 前言

隨著汽車產業的不斷優化，以及電子電氣架構的不斷升級，越來越多的OEM和TIER1選擇認同AUTOSAR的理念，開發滿足其標準規范的產品，以實現標準的軟硬件分離。作為AUTOSAR的兩大平臺之一，自適應平臺（AUTOSAR Adaptive Platform，AP）是能夠提供高性能計算和通信機制的軟件平臺，是為補充其經典平臺（AUTOSAR Classic Platform，CP）在MCU上深度定義無法適配操作系統而擴展的中間件平臺，其特點是基于統一的AUTOSAR標準體系下能夠提供靈活的軟件配置，可廣泛應用于基于操作系統的MPU開發當中[1]。

PREEvision作為Vector開發的符合AUTOSAR標準的配置工具鏈，可以通過建模反映架構師的設計意圖，并基于AP的不同版本導出ARXML供下游銜接開發。作為OEM的配置工具，PREEvision憑借其靈活的配置能力、標準的接口對接，使得OEM的上層設計團隊與下游開發團隊能夠快速對接起來。通信建模在整個建模過程中上承軟件接口、下啟協議棧配置，是PREEvision建模中的核心。

文章以SOMEIP服務通信為例，從PREEvision在AP側的通信建模方法和建模原理兩方面進行研究，了解其在機器部署、網絡設計和服務實例方面的建模方法，挖掘其在OSI模型物理層、媒體訪問控制層、網絡層、傳輸層和應用層實現的原理機制。

2" AP側PREEvision通信建模方法

2.1" 機器部署建模

按照AP的實現原理，同一設備內的不同應用APP之間的信息交互是通過ARA（AP的Runtime）完成的，此時并沒有產生通信。通信按照介質劃分，可以劃分為有線通信和無線通信。有線通信是指傳輸媒質為導線、電纜、光纜、波導、納米材料等形式的通信，其特點是媒質能看得見，摸得著（明線通信、電纜通信、光纜通信、光纖光纜通信）；無線通信是指傳輸媒質看不見、摸不著（如電磁波）的一種通信形式[2]，如微波通信、短波通信、移動通信、衛星通信、散射通信。不論是哪種通信方式，通信的產生都是通過向總線收發數據，其核心目的主要有兩種：應答（接收）和命令（發送），通信的基礎都是不同的設備之間有信息交互的需求。因此，在AP建模中最基礎也是最先需要明確的就是各個設備的信息，AP中稱之為Machine，即機器。機器的部署分為2個部分：機器模式和服務發現配置。

2.1.1" 機器模式

機器模式主要是搭建機器模式的框架，包括創建Function Groups和Mode Declaration Group，創建完成后實際的模式如何應用是在下游開發當中體現，不需要在前端架構設計中進行約束。機器模式配置示例如圖1所示。

2.1.2" 服務發現配置

服務發現配置的內容包括機器部署與機器的映射配置、機器部署與服務發現的映射配置、服務發現的IP地址配置、服務發現的組播端口配置。重點是配置后面2項服務發現的參數，前面2項映射的配置與前文2.1.1一樣，只需要創建出來即可。服務發現的配置有兩點注意事項：①按照SOMEIP規范，服務發現必須用組播，組播必須采用UDP傳輸，端口號默認為30490；②按照PREEvision配置需求，同一個傳輸層端口不能被多個設備引用，但是不同的傳輸層端口可以用同一個端口號。服務發現配置示例如圖2所示。

2.2" 網絡設計建模

機器部署建模完成后各個設備的單一信息就完整了，距離通信產生的必要條件還缺少一個通信介質的建模，即設備與設備之間如何通過物理連接在一起的。

網絡設計建模的本質是對整個網絡拓撲進行建模，會體現全部設備間的包含關系和連接關系[3]。比如一個控制器包含了很多芯片工程，那么每個芯片工程都可以建模為一個Computer電腦，Computer下再創建硬件相關的Bus Co-nnector總線連接器和MicroProcessor微處理器，多個Computer間創建Switch交換機以及Switch上的Bus Connector，在Ethernet Cluster以太網集下創建Bus Connector間的Bus System總線系統，即總線連接線路。這樣，每個Computer利用它的Bus Connector通過對應的Bus System連接到Switch上打通整個網絡架構的通信鏈路。網絡拓撲建模示例如圖3所示。

2.3" 服務實例建模

服務實例是AP通信建模的核心，在設備和連接關系都配置好的基礎上，通過服務實例建模能夠明確服務的提供方和消費方，明確服務的實際通信行為和APP的監測端口信息。服務實例建模分為3個部分：服務實例與接口/進程的映射、服務實例TP/IP配置、服務實例SD參數配置。

2.3.1" 服務實例與接口/進程的映射

服務實例與接口/進程的映射（圖4）主要是PREEvision軟件運行信號路由生成，定義了服務實例、APP的接口、APP的進程這三者的映射關系。

2.3.2" 服務實例TP/IP配置

APP在監控服務時是通過Socket套接字接口來實現的，Socket由IP和Port端口組成，IP和Port的配置就是在此處完成[4-5]，其配置示例如圖5所示。

IP可以唯一標識網絡中的主機，而IP加Port可以唯一標識主機中的APP，因此不同服務可以是相同Socket接口，也可以是不同Socket接口，取決于提供或消費服務的APP是否為同一個。

另外，由于SOMEIP的特殊性，其作為中間件，本質也是一種APP，所以即便是不同的APP，只要部署在同一個設備，其SOMEIP服務監控所使用的Socket就可以是同一個，在不同APP調用SOMEIP時由SOMEIP的APP去協調服務的應用。

2.3.3" 服務實例SD參數配置

服務分為事件和方法，服務實例分為提供服務實例和消費服務實例，接口實例最終要與提供/消費服務實例進行關聯，因此服務和服務實例排列組合會使服務實例關聯4種接口實例：①事件的提供服務實例關聯提供事件組（事件）實例；②事件的消費服務實例關聯消費事件組實例；③方法的提供服務實例關聯提供方法實例；④方法的消費服務實例關聯消費方法實例[6-9]。

不論是哪種服務實例，亦或是事件組的接口服務實例，按照SOMEIP規范都需要有SD時間參數，這些參數就是在此處進行配置的。服務實例SD參數配置示例如圖6所示。

服務提供方和消費方的時間參數如果不匹配，可能會影響SOMEIP協議棧的工作效率，嚴重的還會影響到實際訂閱效果，導致應用服務無法按預期進行發布，因此同一個服務的SD參數對于提供方和消費方來說，可以統一為同一個指標，甚至不同的服務其SD參數也可以進行統型，以保證服務通信的穩定性。

另外，一個服務與其部署的設備并非一一綁定關系，一個服務可以實例化多次，即不同設備可以提供同一服務，這種場景下，不同設備提供的服務需要用服務實例ID來區分，因此提供服務實例SD參數配置除了時間參數外還需要配置服務實例ID。

3" AP側PREEvision通信建模原理研究

3.1" 物理層和媒體訪問控制層建模原理

AP作為一種平臺中間件，其本身并不關注物理層和媒體訪問控制層的信息，這兩層比較靠近硬件，對于應用和中間件來說屬于底層開發，在產品開發當中，一般會有專門的團隊進行單獨配置。所以基于這個事實，不論按照AP的哪個版本導出生成ARXML，其中都不會包含物理層和絕大部分媒體訪問控制層的信息，只有媒體訪問控制層的VLAN信息會體現在ARXML當中，如圖7所示。

PREEvision之所以需要進行物理層和媒體訪問控制層的相關配置，歸根結底還是因為需要確定設備間的關聯關系，明確通信行為，以保證建模的基礎。所以，在建模過程中，物理層和媒體訪問控制層的信息只需要保證物理連接和部署的正確性即可，相關的名稱、參數對于通信建模來說都沒有實際意義，在建模過程中要有策略性、傾向性地調整關注點。

3.2" 網絡層和傳輸層建模原理

網絡層即IP層，傳輸層即UDP/TCP，是Socket的組成部分，既是以太網協議棧中的銜接層，又是上層識別應用服務的唯一接口。按照AP的實現機制，只關注自己的IP和Port是什么，不關注對端的信息，無論對端是什么，只要滿足媒體訪問控制層的規則，就可以實現網絡層和傳輸層的對接。所以基于這個事實，不論按照AP的哪個版本導出生成ARXML，其中都只會有自己的IP和Port信息，如圖8所示。

PREEvision之所以需要全量的網絡層和傳輸層配置是因為PREEvision是全局建模，在一個模型中體現全部的通信行為，但各設備的IP和Port信息只對各自負責。所以，在建模過程中，網絡層和傳輸層的信息只需要保證要導出ARXML的設備其信息的正確性即可，其余不導出ARXML的設備其IP、Port在沒有沖突的前提下對于通信建模來說都沒有實際意義，在建模過程中也可差異化對待。

另外，如果使用PREEvision自帶的信號路由，則會生成一些Signal、Pdu、Socket Address、Transmission等過程產物，因為AP的機制不需要這些元素，所以從模型的體量考慮，可以將這些無用的元素刪除掉。

3.3" 應用層建模原理

應用層軟件的開發是ECU開發當中非常重要的一環，往往在應用層中凝聚了整個ECU最為精華的算法與策略。對于AP來說，應用層是一個封裝好的盒子，而且是一個只知道接口不知道邏輯功能的黑盒子，而AP只需要負責提供和管理這些接口即可[10]。故不論按照AP的哪個版本導出生成ARXML，其中都只會包含接口的描述。

PREEvision的應用接口是以服務為單位，即便一個服務當中有非常多的事件或方法，建模中提供給應用的接口都只有一個，而對于這個服務的調用，則完全交由操作系統來完成，建模過程只需要將服務定義整個移到模型當中即可，這樣就大大減少了架構師的建模工作量。ARXML中詳細的服務定義見圖9。

所以，在建模過程中，應用層的信息需要非常完整和準確，服務的調用都將基于應用層的定義開展，哪怕有一個數值寫錯都可能造成功能的故障，在建模過程中需要尤其關注服務定義的正確性。

4" 結束語

PREEvision作為上層架構設計的配置工具，其建模過程中的配置項非常自由，但配置方法非常復雜，配置項數量也非常多。在掌握建模方法的基礎上，了解并思考如何更加便捷、規范、準確地進行建模，是架構工程師和網絡工程師需要重點對待的課題。希望通過文章能夠讓讀者朋友們對于如何應用PREEvision進行通信建模有更深一步的了解。

參考文獻：

[1] 詹德開. 基于PREEvision的SOA設計[J]. 汽車實用技術，2022，47（23）：62-70.

[2] [美]約翰.G.普羅克斯，[美]馬蘇德·薩萊希. 通信系統原理[M]. 郭宇春，張立軍，李磊，譯.北京：機械工業出版社，2016.

[3] 王永輝. 基于PREEvision的汽車電子電氣架構設計介紹[J]. 汽車技術，2019（15）：111-112.

[4] 王璇，王亮，楊玻. Linux環境下基于Socket的數據傳輸軟件設計[J]. 數碼世界，2020（11）：15-16.

[5] 師永林. 一種基于TCP/IP協議的通信數據傳輸方式[J]. 網絡安全技術與應用，2021（11）：2-3.

[6] 張海濤，胡勝，仇林至. 基于AUTOSAR的SOME IP通信及其多核應用的實現[J]. 上海汽車，2021（1）：17-22，28.

[7] 甄海川，牛玉嬌，路哲，等. 車載以太網通信開發及應用[J]. 汽車文摘，2022（1）：40-44.

[8] 符丹丹，趙杰，美少楠，等. 基于商用車的車載以太網通信技術應用[J]. 汽車電器，2021（7）：34-35，39.

[9] 趙穎慧，白楊，趙聰聰. 車載以太網SOME/IP在信息娛樂系統的應用[J]. 汽車文摘，2020（4）：31-34.

[10] 李震，劉敏. 基于Autosar的整車電子電氣架構設計方法[J]. 機電一體化，2012（11）：73-76.

（編輯" 凌" 波）