基于PREEvision的SOA設(shè)計

詹德凱，高 越

基于PREEvision的SOA設(shè)計

詹德凱1，高 越2

（1.遼寧省交通高等專科學(xué)校 智能網(wǎng)聯(lián)協(xié)同創(chuàng)新中心，遼寧 沈陽 110122；2.沈陽東信創(chuàng)智科技有限公司，遼寧 沈陽 110111）

隨著汽車新“四化”的深入發(fā)展，電子電氣系統(tǒng)越來越復(fù)雜，電子電氣架構(gòu)革新和拓展勢在必行。汽車面向服務(wù)的架構(gòu)（SOA）、基于模型的開發(fā)方式（MBD）、AutoSAR和以太網(wǎng)等已成為電子電氣架構(gòu)的發(fā)展趨勢。文章通過闡述基于PREEvision工具實現(xiàn)服務(wù)及接口定義、軟件架構(gòu)、網(wǎng)絡(luò)拓?fù)?、服?wù)部署、以太網(wǎng)通訊、以太網(wǎng)SoAd模塊和SOMEIP序列化等設(shè)計，實現(xiàn)面向服務(wù)的架構(gòu)開發(fā)，通過建模之后導(dǎo)出ARXML文件完成輸出。開發(fā)過程符合模型的開發(fā)方式和AutoSAR的技術(shù)要求。促進(jìn)了軟件定義汽車的實現(xiàn)，形成并完善了新的電子電氣架構(gòu)平臺。

面向服務(wù)的架構(gòu)（SOA）；PREEvision；基于模型的開發(fā)（MBD）；AutoSAR；SOMEIP；以太網(wǎng)

電子電氣架構(gòu)是支持智能網(wǎng)聯(lián)汽車發(fā)展的基礎(chǔ)技術(shù)，體現(xiàn)了整車電氣系統(tǒng)集成能力[1]。隨著智能互聯(lián)、自動駕駛、電動汽車及共享出行的發(fā)展，軟件、計算能力和先進(jìn)傳感器正逐漸取代發(fā)動機(jī)的統(tǒng)治地位。差異化（或獨特性）將不再僅僅停留于傳統(tǒng)的車輛硬件方面，而更多地通過由軟件和先進(jìn)電子技術(shù)賦能的用戶交互界面和體驗層面來體現(xiàn)[2]。未來汽車電子電氣架構(gòu)的發(fā)展方向是集成化越來越高的域控制器架構(gòu)或者中央計算單元的環(huán)形網(wǎng)絡(luò)架構(gòu)，以高速率以太網(wǎng)作為骨干網(wǎng)，支持基于模型的開發(fā)方式（Model Based Design, MBD），支持軟件架構(gòu)標(biāo)準(zhǔn)AutoSAR, 支持面向服務(wù)的架構(gòu)（Service-oriented Architecture, SOA）[3]。本文將介紹如何基于PREEvision工具進(jìn)行SOA模型創(chuàng)建，該模型符合經(jīng)典的自動恒星平臺（Classic AutoSAR Platform, CP）的要求，綁定的是以太網(wǎng)中間件協(xié)議SOMEIP。

1 概念介紹

1.1 AutoSAR

AutoSAR，全稱為Automotive Open System Architecture，即汽車開放系統(tǒng)架構(gòu)。它是由全球各家汽車制造商、零部件供應(yīng)商以及各種研究、服務(wù)機(jī)構(gòu)共同參與的一種汽車電子系統(tǒng)的合作開發(fā)框架，并建立了一個開放的汽車控制器（Electr- onic Control Unit, ECU）標(biāo)準(zhǔn)軟件架構(gòu)。由此提升原始設(shè)備制造商Original Equipment Manufacturer, OEM以及供應(yīng)商之間軟件模塊的可復(fù)用性和可互換性來改進(jìn)對復(fù)雜汽車電子電氣架構(gòu)的管理[4]。

為此，AutoSAR做了以下三件事情：

第一，對應(yīng)用軟件與底層軟件之間以及應(yīng)用軟件之間的接口進(jìn)行標(biāo)準(zhǔn)化。

第二，給出一個控制器軟件參考架構(gòu)。

第三，規(guī)范分布式開發(fā)流程中的交換格式。

當(dāng)前AutoSAR包含兩個平臺，Classic AutoSARPlatform（CP）和Adaptive AutoSAR Platform（AP）。

1.2 SOA

SOA，全稱為Service-Oriented Architecture，是一種架構(gòu)風(fēng)格，也是一種軟件架構(gòu)開發(fā)方法，其特點是擁有標(biāo)準(zhǔn)的服務(wù)接口，服務(wù)和服務(wù)之間是松耦合的，具有靈活性?？蓴U(kuò)展性和互操作性，而這些特性恰恰是軟件定義汽車必不可少的[5]。某個功能或系統(tǒng)由一組服務(wù)組成，并且其中的總服務(wù)包可以依次使用其他的多個子服務(wù)，面向服務(wù)的架構(gòu)SOA的出現(xiàn)可以打破車內(nèi)靜態(tài)交互模型，并且建立功能靈活治理的系統(tǒng)架構(gòu)。確保新增功能的實現(xiàn)可以與車輛原有的系統(tǒng)架構(gòu)、驅(qū)動方式、通信方式相匹配[6-7]。

1.3 SOMEIP

SOMEIP，全稱為Scalable service-Oriented Middleware over IP，是AutoSAR組織針對汽車領(lǐng)域應(yīng)用制定的一組中間件框架。以Server-Client服務(wù)形式進(jìn)行通信，為應(yīng)用層協(xié)議運行于車載以太網(wǎng)OSI模型四層以上，作為以太網(wǎng)通信中間件來實現(xiàn)應(yīng)用層和IP層的數(shù)據(jù)交互，其不依賴于操作系統(tǒng)，兼容AutoSAR和非AutoSAR平臺[8]。主要包含了RPC協(xié)議；服務(wù)相關(guān)的查找申請訂閱停止等相關(guān)服務(wù)（Service Discovery）；數(shù)據(jù)序列化的定義（SOME/IP Transformer）等三部分內(nèi)容。

1.4 PREEvision

PREEvision 是一款自上而下（Top-Down）用于實現(xiàn)電子電氣架構(gòu)設(shè)計構(gòu)想的計算機(jī)輔助設(shè)計軟件工具[9]。其核心技術(shù)就是基于模型的開發(fā)，符合AutoSAR標(biāo)準(zhǔn)，實現(xiàn)了層與層之間相互滲透和數(shù)據(jù)的可追溯性。它的功能包括需求開發(fā)、邏輯功能設(shè)計、網(wǎng)絡(luò)和部件架構(gòu)等[10]。

2 基于PREEvision的SOA設(shè)計

面向服務(wù)的架構(gòu)（SOA）在汽車電子領(lǐng)域的實現(xiàn)方法，是采用 AutoSAR 的方案，基于模型MBD的開發(fā)方法實現(xiàn)的?；赩ector架構(gòu)開發(fā)工具PREEvision進(jìn)行SOA建模，完全符合AutoSAR的要求。圖1是PREEvision工具推薦的SOA建模工作流程，主要包括服務(wù)及服務(wù)接口定義、軟件架構(gòu)設(shè)計、網(wǎng)絡(luò)拓?fù)湓O(shè)計、服務(wù)部署、以太網(wǎng)通信設(shè)計、以太網(wǎng)SoAd的設(shè)計、SOMEIP序列化、SOMEIP SD、導(dǎo)出ARXML。

圖1 SOA建模工作流程

2.1 服務(wù)及服務(wù)接口設(shè)計

服務(wù)及服務(wù)接口設(shè)計主要包括定義服務(wù)、定義服務(wù)的標(biāo)準(zhǔn)接口、綁定網(wǎng)絡(luò)通訊協(xié)議和定義數(shù)據(jù)類型。

2.1.1定義服務(wù)

定義服務(wù)內(nèi)容就是搭建一個系統(tǒng)功能架構(gòu)，從整車層面按照功能需求定義并劃分服務(wù)。服務(wù)有兩個角色，服務(wù)的提供者（service provider）和服務(wù)的消費者（service consumer）。服務(wù)的提供者和服務(wù)的消費者之間是關(guān)聯(lián)關(guān)系（useage）。如圖2所示，定義一個服務(wù)SpeedLimiter。服務(wù)提供者為SpeedLimiter_sp，服務(wù)的消費者為SpeedLimi- ter_sc。

圖2 SpeedLimiter服務(wù)定義

2.1.2定義服務(wù)接口

服務(wù)以標(biāo)準(zhǔn)化的接口提供功能，服務(wù)接口是一種通信內(nèi)容定義，其目的在于將服務(wù)從功能架構(gòu)過渡到軟件技術(shù)架構(gòu), 軟件模塊之間的關(guān)系需被清晰地定義出來，將服務(wù)內(nèi)容封裝成相應(yīng)的接口被實際調(diào)用。服務(wù)接口可分為方法（Method）、屬性（Property）、事件（Event）三種類型。Method包含了請求后有應(yīng)答的Method（Request&Res- ponse）和請求后沒有應(yīng)答的Method（Fire&For- get）。Property表示Getter/Setter/Notifier某種屬性或者狀態(tài)。Event表示某種事情發(fā)生后，服務(wù)端向客戶端發(fā)送的Message。

如圖3所示，SpeedLimiter這個服務(wù)，包含一個VehicleSpeed的Method（request&response）, 一個speedLimitSet的Property（此屬性支持getter, setter和notifier），一個speedLimitStatus的Event。

圖3 SpeedLimiter服務(wù)接口定義

2.1.3綁定SOMEIP協(xié)議

服務(wù)及服務(wù)接口定義完成之后，需要綁定網(wǎng)絡(luò)通訊協(xié)議，可以綁定DDS、SOMEIP、或者用戶自定義的協(xié)議，這里綁定專門針對汽車領(lǐng)域SOA設(shè)計的輕量化的SOMEIP協(xié)議。服務(wù)SpeedLimiter需要定義SOMEIP協(xié)議的相關(guān)參數(shù)如下：

Interface ID：同Service ID 的0x1001；

Major version：主版本號定義為1；

Minor version：副版本號定義為0；

Method/Event ID：兩個byte數(shù)據(jù)，最高位是0代表method，最高位是1代表event；

Event Group：用來進(jìn)行publish/subscribe處理Events和Fields（Notifier）的通信的邏輯組。每個Events或者Fields（Notifier）至少存在于一個Event Group中。同時需要為每個Event Group定義ID。本示例中的一個event和一個notifier同時屬于一個Event Group：speedLimiter_EG，Event Group ID為0x01。

2.1.4定義數(shù)據(jù)類型

AutoSAR按照不同的抽象級別，定義了對數(shù)據(jù)進(jìn)行描述的三個不同的層次[11]，分別如下：

應(yīng)用數(shù)據(jù)類型（Application Data Type, ADT）：從應(yīng)用邏輯的角度描述數(shù)據(jù)，體現(xiàn)該數(shù)據(jù)在現(xiàn)實中的物理語義、物理取值范圍、物理單位等。在ADT中通常會關(guān)聯(lián)一個計算公式（Computation Method, CM），描述數(shù)據(jù)從物理（值）范圍到內(nèi)部數(shù)字（位）級別的轉(zhuǎn)換關(guān)系。一般地，在功能定義的過程中，我們會使用ADT的方式對數(shù)據(jù)進(jìn)行描述。

實現(xiàn)數(shù)據(jù)類型（Implementation Data Type, IDT）：從代碼實現(xiàn)的角度描述數(shù)據(jù)，盡管IDT仍是一層抽象概念，但可近似認(rèn)為IDT為從實際代碼實現(xiàn)（如C語言）的角度，對數(shù)據(jù)類型的定義。

基本類型（Base Type）：從Bit或Byte的角度描述底層平臺（Platform）支持的原生類型，這些原生類型最終構(gòu)建了IDT的實現(xiàn)。

完整的AutoSAR數(shù)據(jù)類型定義包含ADT、IDT和Base Type，且ADT和IDT之間需要定義映射關(guān)系，IDT和Base Type之間需要定義關(guān)聯(lián)關(guān)系。

圖4是服務(wù)speedLimiter定義的數(shù)據(jù)類型，其中關(guān)于vehicleSpeed Method定義了四個輸入?yún)?shù)和一個輸出參數(shù)。

圖4 數(shù)據(jù)類型定義及賦予

2.2 軟件架構(gòu)設(shè)計

系統(tǒng)軟件架構(gòu)描述了整車各個系統(tǒng)功能的邏輯實現(xiàn)方式，包含傳感器（源），功能，技術(shù)相關(guān)的邏輯架構(gòu)。PREEvision工具中系統(tǒng)軟件架構(gòu)包括了各種符合AutoSAR標(biāo)準(zhǔn)的軟件組件技術(shù)規(guī)范的定義，從而能與 AutoSAR更好地保持一致性。

AutoSAR CP（Classic Platform）中的軟件架構(gòu)設(shè)計是為不同的服務(wù)角色創(chuàng)建對應(yīng)的不同軟件類型software type、定義接口類型interface type、定義端口類型port type，連接相應(yīng)的port，最后為了滿足下游工具設(shè)置runnable的需求，這里需要設(shè)置SWC的internal behavior[12]。

接口類型interface type定義如圖5所示。

圖5 service interface定義

R&R method的Interface用 Server-Client Interface 實現(xiàn)；

F&F method Interface用Sender-Receiver Inter face 實現(xiàn)；

Properties中的get/set用Server-Client Inter- face實現(xiàn)；

Properties中的Notifier用Sender-Receiver Interface實現(xiàn)；

Event 用 Sender-Receiver Interface 實現(xiàn)。

端口類型port type的定義與接口類型定義相對應(yīng)，Port type主要包括：

Sender port type；

Receiver port type；

Client port type；

Server port type。

端口類型port type定義完之后，為相應(yīng)的Port分配Interface，并連接相應(yīng)的端口。如圖6所示。

圖6 軟件架構(gòu)原理圖

2.3 網(wǎng)絡(luò)拓?fù)湓O(shè)計

網(wǎng)絡(luò)拓?fù)湓O(shè)計用于確定各以太網(wǎng)節(jié)點的連接方式和配置方式[13]，建立連接硬件部件的概念中最頂層的抽象連接關(guān)系，用于指導(dǎo)后續(xù)以太網(wǎng)的設(shè)計和開發(fā)工作，如圖7所示。主要內(nèi)容包括：

確定以太網(wǎng)節(jié)點，是ECU類型還是computer類型；

確定Switch位置，是在以太網(wǎng)節(jié)點內(nèi)部還是以太網(wǎng)節(jié)點外部，如果是在以太網(wǎng)節(jié)點內(nèi)部，是在哪個節(jié)點內(nèi)部。

分配Bus Connection Type為Ethernet Types；

分配Connector Type為Ethernet Connector Types；

將Bus Systems分配給Ethernet Cluster；

利用Switch Configuration將物理網(wǎng)絡(luò)劃分成邏輯網(wǎng)絡(luò)VLAN。

圖7 網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)圖

2.4 服務(wù)部署

服務(wù)部署包括軟件和硬件的映射和信號路由兩部分內(nèi)容。

2.4.1軟件與硬件映射

軟件與硬件映射即是將Software Component分配到硬件ECU中，通過Software Type實例化得到具體的Software Component。

2.4.2信號路由

通過信號路由將實現(xiàn)服務(wù)的軟件部件間的虛擬通信轉(zhuǎn)變成真實的Ethernet總線通信，通過PREEvision的信號路由功能，可自動生成PDU, Signal, PDU Transmission和Signal Transmission等一系列構(gòu)件。

然后針對新生成的構(gòu)件配置參數(shù)，signal需要配置的參數(shù)如下：

Signal Length設(shè)置根據(jù)實際長度進(jìn)行設(shè)置；

Data Type Policy設(shè)置為TRANSFORMINIGI- SIGNAL；

Signal IPDU參數(shù)設(shè)置：

Bit Length設(shè)置根據(jù)實際長度進(jìn)行設(shè)置；

在Signal IPDU下創(chuàng)建Timing Mode On True →Event Controlled Timing，將Number of Repetiti- ons設(shè)置為0。

Signal-IPDU-Assignment參數(shù)設(shè)置：

Start Position設(shè)置為0；

Byte Order設(shè)置為Opaque；

Transfer Property設(shè)置為Trigger或Trigger Without Repetitions；

Update Indication Bit Position不設(shè)置。

2.5 以太網(wǎng)通信設(shè)計

以太網(wǎng)通訊設(shè)計包括以太網(wǎng)物理層、數(shù)據(jù)鏈路層、網(wǎng)絡(luò)層和傳輸層等底層協(xié)議的參數(shù)配置[14]。

Physical layer type：包括100 BASE T1、1000 BASE T1，100BASE TX等；這是一種以太網(wǎng)標(biāo)準(zhǔn)，100表示理論上最大的傳輸速率，單位：Mbit/s。Base是Baseband的縮寫，表示使用基帶傳輸,沒有進(jìn)行調(diào)制和頻分復(fù)用。T表示twisted pair cable，表明傳輸?shù)慕橘|(zhì)是雙絞線。

CNB（Connection Negotiation Behavior）：車內(nèi)的協(xié)商機(jī)制都采用主從形式，為每個控制器選擇主從節(jié)點配置。

MAC-Address：以太網(wǎng)采用介質(zhì)訪問控制（Medh Access Control, MAC）地址進(jìn)行物理尋址。MAC地址為硬件地址，它采用48位（6字節(jié)）的十六進(jìn)制格式。

MAC Kind：包括Hardware類型和可以刷寫的Flashed類型。

PCP：概率可檢測證明（Probabilistically Che- ckable Proofs, PCP），包含在VLAN tag中，在PCP列可以設(shè)置優(yōu)先級，范圍0至7，數(shù)值越小優(yōu)先級越低。

VLAN：虛擬局域網(wǎng)（Virtual Local Area Network, VLAN）的中文名為“虛擬局域網(wǎng)”。虛擬局域網(wǎng)（VLAN）是一組邏輯上的設(shè)備和用戶，這些設(shè)備和用戶并不受物理位置的限制。VLAN限制了廣播域，廣播幀只允許在域內(nèi)廣播，合理的劃分VLAN有利于網(wǎng)絡(luò)通訊安全及負(fù)載分配。VLAN ID表示VLAN的唯一數(shù)據(jù)標(biāo)識符。

互聯(lián)網(wǎng)協(xié)議（Internet Protocol, IP），是TCP/IP協(xié)議棧中最核心的協(xié)議之一，通過IP地址，保證了聯(lián)網(wǎng)設(shè)備的唯一性，實現(xiàn)了網(wǎng)絡(luò)層的尋址。車內(nèi)網(wǎng)絡(luò)節(jié)點一般都使用IPv4協(xié)議，它為互聯(lián)網(wǎng)協(xié)議的第四版本，地址由4個字節(jié)的數(shù)據(jù)組成。另外車內(nèi)IP地址是預(yù)先定義的，不會使用動態(tài)分配IP地址的方式。在AutoSAR協(xié)議中IP地址包含在網(wǎng)絡(luò)終端（Network End Point, NEP）下。

TCP/UDP：用戶數(shù)據(jù)報User Datagram Protocol, UDP是一種簡單的、無連接、不可靠的傳輸協(xié)議，若某進(jìn)程需要發(fā)送一個不關(guān)心其可靠性的報文，可使用UDP，UDP沒有流量控制機(jī)制，數(shù)據(jù)長度最大為1 400 byte，可以支持組播和單播；而TCP不同于UDP，TCP是一種面向連接的、可靠的傳輸協(xié)議，它能夠保證兩端通信主機(jī)之間的信息可達(dá)，TCP帶有流量控制機(jī)制，可以傳輸比UDP更長的數(shù)據(jù)，只支持單播。如果要基于UDP傳輸大于1 400 byte的數(shù)據(jù)，可以使用SOMEIP TP將數(shù)據(jù)分包。

端口號（Port Number）：所謂的端口號，就好像是門牌號一樣，客戶端可以通過IP地址找到對應(yīng)的服務(wù)器端，但是服務(wù)器端是有很多端口的，每個應(yīng)用程序?qū)?yīng)一個端口號，通過類似門牌號的端口號，客戶端才能真正的訪問到該服務(wù)器。

Socket address：Socket address由IP地址，傳輸協(xié)議TCP或者UDP及對應(yīng)的端口號組成。

圖8是使用PREEvision工具進(jìn)行的以太網(wǎng)通訊OSI模型1層至4層的設(shè)計。

2.6 以太網(wǎng)SoAd的設(shè)計

在AutoSAR協(xié)議中，SoAd模塊的主要目的是在PDU和基于Socket的TCP/IP堆棧之間創(chuàng)建一個接口。建立起Socket與PDU之間的數(shù)據(jù)傳輸。TCP/IP的數(shù)據(jù)接收時通過SoAd的接口可以將數(shù)據(jù)轉(zhuǎn)換成PDU的形式，在發(fā)送的時候可以將具體的PDU數(shù)據(jù)轉(zhuǎn)化成Socket的形式在TCP/IP協(xié)議層進(jìn)行發(fā)送。定義PDU的Header ID區(qū)分不同的Socket與PDU的交互，即在同一個socket中關(guān)聯(lián)多個不同的PDU；Socket Connection是連接目標(biāo)Socket（PDU）和源PDU（Socket）的路由關(guān)系，每一個Connection都關(guān)聯(lián)到有特定的TCP、UDP中，一方面用來控制以太網(wǎng)通信中TCP、UDP連接的打開還是關(guān)閉，另一方面定義了TCP、UDP數(shù)據(jù)如何被接收和發(fā)送。

2.7 SOMEIP序列化（SOMEIP Serializer）

SOMEIP Serializer是AutoSAR協(xié)議Trans- former模塊中的一個功能模塊，用于數(shù)據(jù)的序列化，即進(jìn)行以太網(wǎng)并行的結(jié)構(gòu)化數(shù)據(jù)和線性數(shù)據(jù)的轉(zhuǎn)換[15]。圖9為SOMEIP Serializer的過程，在AutoSAR中，發(fā)送端SWC發(fā)送數(shù)據(jù)到RTE，RTE調(diào)用SOMEIP Serializer模塊將結(jié)構(gòu)化的數(shù)據(jù)按照一定的規(guī)則轉(zhuǎn)換成線性數(shù)據(jù)，再傳輸?shù)紺OM模塊；在接收端，數(shù)據(jù)按照相同的規(guī)則進(jìn)行反序列化后再發(fā)送給SWC。

以太網(wǎng)結(jié)構(gòu)化數(shù)據(jù)包括結(jié)構(gòu)體、數(shù)組、聯(lián)合體和字符串等[17]。結(jié)構(gòu)體和數(shù)組的區(qū)別是，結(jié)構(gòu)體所有數(shù)據(jù)元素的數(shù)據(jù)類型是不同的，數(shù)組所有數(shù)據(jù)元素的數(shù)據(jù)類型必須是相同的。圖10為帶有長度域的結(jié)構(gòu)體數(shù)據(jù)類型序列化示例，結(jié)構(gòu)體的長度域是可選的，可在結(jié)構(gòu)體之前添加一個8位，16位或32位的長度字段；如果未指定長度域的長度，則必須假定長度為0，并且報文中不包含長度；如果長度段大于實際長度，則仍會解析，只解析接口規(guī)范中定義的字節(jié)；如果是嵌套結(jié)構(gòu)體每個結(jié)構(gòu)體前都要添加長度域。

圖9 SOMEIP Serializer視圖

圖10 結(jié)構(gòu)體數(shù)據(jù)序列化示例

在PREEvision工具創(chuàng)建SOMEIP 序列化包括配置SOMEIP Transformer，配置SOMEIP Trans- formation properties，分配SOMEIP Transformation Properties給各個接口元素。

2.7.1SOMEIP Transformer

SOMEIP Transformer需要設(shè)置的相關(guān)參數(shù)如下：

Protocol設(shè)置為SOMEIP；

Transformer Class選擇SERIALIZER；

Version設(shè)置為1.0.0；

Header Length設(shè)置為64；

Alignment設(shè)置根據(jù)實際域控制器狀態(tài)填寫，比如車身域控制器一般為32位對齊，座艙域控制器一般為64位對齊；

Byte Order選擇也需要根據(jù)實際情況填寫，不能選擇opaque類型，為與以太網(wǎng)header保持一致，通常選擇Motorola Big Endian類型。

3.7.2SOMEIP Transformation properties

創(chuàng)建SOMEIP Transformation properties構(gòu)件，并配置相關(guān)參數(shù)。如存在多種不同的配置參數(shù)，需要對應(yīng)創(chuàng)建多個不同的SOMEIP Transformation properties。每個SOMEIP Transformation properties都要關(guān)聯(lián)SOMEIP Transformer。SOMEIP Transfor- mation properties需要配置的相關(guān)參數(shù)如下：

Interface version：1；

Message type：報文類型，位于SOMEIPheader中；

Implements SOMEIP String Handling：用于說明string類型的數(shù)據(jù)是否兼容SOMEIP規(guī)范的定義；

各類型數(shù)據(jù)長度域長度設(shè)置

最后將SOMEIP Transformation Properties分配給各個接口元素即可。

2.8 SOMEIP SD

服務(wù)發(fā)現(xiàn)（Service Discovery, SD）是服務(wù)的信息清單及管理機(jī)制，也是一種服務(wù)，主要實現(xiàn)服務(wù)尋址及事件訂閱兩種功能[16]。SD用來對服務(wù)進(jìn)行尋址時，服務(wù)提供者（Server端）通過服務(wù)發(fā)現(xiàn)（SD）通知其他ECU（Client端）某服務(wù)可用，并間接地通知該服務(wù)的地址（Server端地址）；服務(wù)消費者（Client端）了解到某服務(wù)狀態(tài)后，能夠調(diào)用該服務(wù)的相關(guān)內(nèi)容。SD用來事件訂閱時，專門針對Event類型的接口，可以通過SD實現(xiàn)對Event所在的Event group進(jìn)行訂閱、停止訂閱等操作。SD最突出的優(yōu)點是需要的時候才會提供/訂閱服務(wù)，節(jié)省帶寬和CPU資源?？芍С謩討B(tài)的布置服務(wù)，符合SOA架構(gòu)的靈活性、可復(fù)用性和可移植性。

通過PREEvision工具會生成SD相關(guān)構(gòu)件，然后配置相關(guān)參數(shù)，包括如下內(nèi)容：

SD PDU配置：每一個以太網(wǎng)節(jié)點都會生成三個general purpose PDU：用于接收單播SdInstance UnicastRxPdu，用于接收組播的SdInstanceMuticast RxPdu，及用于發(fā)送的SdInstanceTxPdu，PDU的類別為SD。

SD socket address的配置，包括單播IP地址，組播IP地址，SD端口號推薦為30490。如圖11所示。

圖11 SOMEIP SD Socket定義

2.8.1服務(wù)器端SOMEIP SD通信行為

服務(wù)器端SOMEIP SD通信行為主要包括四個階段：Down Phase，Initial Wait Phase，Repetition Phase，Main Phase。需要配置的時間參數(shù)示例可參看圖12。

圖12 Server時間參數(shù)示例

Down Phase：在這個階段，Service是不可用的，即服務(wù)端無法提供服務(wù)。

Initial Wait Phase：當(dāng)服務(wù)準(zhǔn)備完畢（Availa- ble）后，進(jìn)入此階段；如果此階段收到Find Service報文，服務(wù)端忽略此消息，不做任何處理。需要配置的時間參數(shù)+為INITIAL_DELAY時間（最大和最小值之間的隨機(jī)值）。

Repetition Phase：為了讓客戶端快速找到有哪些Service，此階段重復(fù)發(fā)送OfferService，重復(fù)次數(shù)由REPETITIONS_MAX決定；發(fā)送間隔以REPETITIONS_BASE_DELAY為基本時間，每發(fā)送一次，間隔是前一間隔的2倍；如果收到某客戶端的FindService，不影響當(dāng)前階段的發(fā)送計數(shù)和計時，延遲一定時間（REQUEST_RESPONSE_ DELAY）后，單獨發(fā)送單播Offer Service給服務(wù)請求端；如果收到Subscribe Eventgroup后，發(fā)送單播Ack/Nack，啟動此訂閱Entry的晶體管-晶體管邏輯Transistor-Transistor Logic, TTL）計時器；如果收到Stop Subscribe Eventgroup后，停止此訂閱Entry的TTL計時器；如果服務(wù)不可用，離開此階段進(jìn)入Down Phase，并發(fā)送Stop Offer Service通知所有客戶端。

Main Phase：此階段將周期性發(fā)送Offer Service，周期時間為Offer Cyclic Delay。如圖13所示。

圖13 providedServiceInstance時間參數(shù)

2.8.2客戶端的通信行為

客戶端SOMEIP SD通信行為主要包括四個階段：Down Phase，Initial Wait Phase，Repetition Phase，Main Phase。需要配置的時間參數(shù)示例可參看圖14所示。

圖14 SOMEIP Client 時間參數(shù)示例

Down Phase：服務(wù)未被應(yīng)用請求；

Initial Wait Phase：服務(wù)被請求后，進(jìn)入此階段；等待INITIAL_DELAY時間（最大和最小值之間的隨機(jī)值）；如果此時收到Offer Service，則取消計時器，直接進(jìn)入Main Phase；計時器超時后，發(fā)送第一個Find service，進(jìn)入下一階段。

Repetition Phase：重復(fù)發(fā)送Find service，重復(fù)次數(shù)由REPETITIONS_MAX決定；發(fā)送間隔以REPETITIONS_BASE_DELAY為基時間，每發(fā)送一次間隔加倍；收到Offer Service，停止發(fā)送計數(shù)和計時，立即進(jìn)入Main Phase；觸發(fā)發(fā)送Subscribe Eventgroup（延遲一定時間）；如果服務(wù)請求被釋放，進(jìn)入Down Phase；若有訂閱，則發(fā)送StopSub- scribeEventgroup。

Main Phase：不再發(fā)送Find Service。

2.9 導(dǎo)出ARXML

當(dāng)所有的建模設(shè)計完成后，即可導(dǎo)出Auto- SAR System Description，ECU extract, ECU System Description三種ARXML。PREEvision導(dǎo)出的格式文件ARXML可以準(zhǔn)確地、可靠地導(dǎo)入到下游工具Simulink或者Vector DaVinci中，以便后續(xù)在開發(fā)過程中使用[18]。圖15中導(dǎo)出的是ECU extract的arxml，共有7個AR-package，按字母順序排列有Communication, DataTypeMappingSets, DataTypes, SoAdRoutingGroups, SoftwareTypes, System, Topo- logy。

圖15 ECU Extract arxml層級結(jié)構(gòu)

3 結(jié)束語

本文主要介紹了基于PREEvision 工具和Classic AutoSAR的面向服務(wù)的電子電氣架構(gòu)設(shè)計方法，PREEvision能夠保證數(shù)據(jù)一致性和整個模型的一致性，同時能夠進(jìn)行數(shù)據(jù)的跟蹤和一致性檢查[19]。PREEvision工具自帶1 000多條的AutoSAR的檢查規(guī)則，是目前應(yīng)用最多的AutoSAR模型創(chuàng)建工具。PREEvision快速推進(jìn)了國內(nèi)軟件定義汽車的步伐，為國內(nèi)很多主機(jī)廠搭建了電子電氣架構(gòu)平臺，加快了國內(nèi)面向SOA架構(gòu)的智能網(wǎng)聯(lián)汽車的開發(fā)進(jìn)度[20]。

[1] 王文偉,徐匡一.智能汽車電子架構(gòu)分析與研究[J].時代汽車,2020(4):43-46.

[2] 孟天闖,李佳幸,黃晉,等.軟件定義汽車技術(shù)體系的研究[J].汽車工程,2021,43(4):10.

[3] 華一丁,龔進(jìn)峰,戎輝,等.國外智能汽車電子電氣架構(gòu)綜述及分析[J].汽車電器,2018(12):8.

[4] 孫升,宋珂,章桐.AutoSAR標(biāo)準(zhǔn)發(fā)展及應(yīng)用現(xiàn)狀[J].機(jī)電一體化,2014(12):33-38,44.

[5] 李丹,呂穎,李駿,等.面向服務(wù)的體系架構(gòu)[J].汽車文摘,2021(10):52-57.

[6] UGELE S,OBERGFELL P,BROY M,et al.On Service- orientation for Automotive Software[C]//2017 IEEE International Conference on Software Architecture Piscataway: IEEE,2017:193-202.

[7] RUMEZ M,GRIMM D,KRIESTEN R,et al.An Over- view of Automotive Service-oriented Architectures and Implications for Security Countermeasures[J].IEEE access,2020(8):221852-221870.

[8] 張海濤,胡勝,仇林至.基于AutoSAR的SOMEIP通信及其多核應(yīng)用的實現(xiàn)[J].上海汽車,2021(1):17-22,28.

[9] 匡小軍,唐香蕉,周濤,等.基于PREEvision的汽車電子電氣架構(gòu)工具鏈研究[J].汽車電器,2019(8):3.

[10] 馮香枝,胡朝峰,張海濤.基于PREEVISION的汽車電子電氣架構(gòu)設(shè)計[J].汽車電器,2013(10):43-46.

[11] AutoSAR.System Template.AutoSAR Classic PlatformR20-11[R].Redmond:AutoSAR Foundation.2020:2130- 2190.

[12] AutoSAR. Software Component Template. AutoSAR Classic Platform Release 4.3.0[R].Redmond:AutoSAR Foundation.2016:65-220.

[13] 袁仲楠.基于PREEvison的電子電氣架構(gòu)開發(fā)研究[J].電子測試,2020(3):55-57,130.

[14] 符丹丹,趙杰,美少楠,等.基于商用車的車載以太網(wǎng)通信技術(shù)應(yīng)用[J].汽車電器,2021(7):34-35,39.

[15] AutoSAR. Specification of SOME/IP Transformer. AutoSAR Classic Platform Release 4.3.1[R]. Redmond: AutoSAR Foundation.2017:26-44.

[16] AutoSAR.SOME/IP Service Discovery Protocol Spe- cification Release 20-11[S].Redmond:AutoSAR Fou- ndation,2020.

[17] 崔曉通,陳宇鵬,張亮,等.車載以太網(wǎng)類型及測試[J].西安郵電大學(xué)學(xué)報,2020(4):90-96.

[18] 劉敏,郭永斌,童菲,等.基于PREEvison的AutoSAR軟件建模[J].機(jī)電一體化,2014(11):74-76.

[19] 王永輝.基于PREEvision的汽車電子電氣架構(gòu)設(shè)計介紹[J].汽車實用技術(shù),2019,44(15):111-112.

[20] 矯莉,章日欣.PREEvision提供從電子電氣架構(gòu)設(shè)計到系列開發(fā)階段的支持[J].汽車與配件,2014(10):56- 58.

Service-oriented Architecture Design Based on PREEvision

ZHAN Dekai1, GAO Yue2

( 1.Collaborative Innovation Center for ICV, Liaoning Provincial College of Communications,Shenyang 110122, China; 2.Shenyang DoTrust Technologies Company Limited, Shenyang 110111, China )

With the in-depth development of the new "four modernizations" of automobiles, electronic and electrical systems are becoming more and more complex, and the innovation and expansion of electronic and electrical architecture is imperative. Service-oriented architecture(SOA),model based design(MBD), AutoSAR and Ethernet have become trends for development of the electronic and electrical architecture. The article describes how to realize the developing contents based on the PREEvision software for the service-oriented architecture design. The contents included service and service interface, software architecture, network topology, service deployment, Ethernet protocols, Ethernet SoAD module and SOMEIP serializer,etc. The ARXML files should be produced after building the module. The development process met the technical requirement of the MBD and AutoSAR. It promoted the realization of software-defined vehicles and formed and improved new electronic and electrical architecture platforms.

Service-oriented architecture(SOA);PREEvision;Model based design(MBD);AutoSAR;SOMEIP; Ethernet

U462.1

A

1671-7988(2022)23-62-09

U462.1

A

1671-7988(2022)23-62-09

10.16638/j.cnki.1671-7988.2022.023.012

詹德凱（1973—），男，高級工程師，研究方向為智能網(wǎng)聯(lián)汽車、新能源汽車、汽車電子電氣，E-mail:zhan dekai@163.com。