基于SOME/IP 的整車(chē)電氣通信網(wǎng)絡(luò)設(shè)計(jì)研究

李陽(yáng)春

（華晨汽車(chē)工程研究院，沈陽(yáng) 110141）

主題詞：車(chē)載以太網(wǎng) 中間件 服務(wù)發(fā)現(xiàn)

縮略語(yǔ)

SOME/IP Scalable service-Oriented MiddlewarE over IP（車(chē)載以太網(wǎng)協(xié)議的，可擴(kuò)展的面向服務(wù)的中間件）

SD Service Discovery（服務(wù)發(fā)現(xiàn)）

ADAS Advanced Driver Assistance Systems（高級(jí)駕駛輔助系統(tǒng)）

OTA Over the Air(遠(yuǎn)程升級(jí))

V2X Vehicle To X（車(chē)聯(lián)網(wǎng)）

ECUElectronic Control Unit（電控單元）

CAN Controller Area Network（控制器局域網(wǎng)絡(luò)）

LIN Local Interconnect Network（局域網(wǎng)）

AUTOSAR Automotive Open System Architecture（汽車(chē)開(kāi)放系統(tǒng)構(gòu)架）

SOA Service Oriented Architecture（面向服務(wù)的架構(gòu)）

ISO/OSI IOS Open System Interconnection（ISO開(kāi)放系統(tǒng)互聯(lián)）

RPCRemote Procedure Call（遠(yuǎn)程過(guò)程調(diào)用）

OSEK Offene Systeme und deren Schnittstellen für die Elektronik im Kraftfahrzeug（Open System and Corresponding Interfaces for Automotive Electronics）

MOST Media Oriented System Transport（面向媒體的系統(tǒng)傳輸總線）

TTL Time To Live（生存時(shí)間）

CRC Cyclic Redundancy Check（循環(huán)冗余校驗(yàn)）

1 概述

汽車(chē)智能化、網(wǎng)聯(lián)化、自動(dòng)駕駛大浪已經(jīng)來(lái)臨，浪潮帶來(lái)的是ADAS技術(shù)的不斷革新、高品質(zhì)車(chē)載娛樂(lè)影音的推進(jìn)以及遠(yuǎn)程升級(jí)（Over the Air，OTA）、V2X、大數(shù)據(jù)、云計(jì)算等一系列技術(shù)的發(fā)展，這些均促進(jìn)車(chē)內(nèi)控制器運(yùn)算能力和硬件的高速發(fā)展，最明顯的體現(xiàn)于越來(lái)越復(fù)雜和多樣的車(chē)載電子系統(tǒng)，大量的傳感器和執(zhí)行器被用在車(chē)輛的不同系統(tǒng)實(shí)現(xiàn)相應(yīng)的功能。在不斷的演進(jìn)過(guò)程中，每增加一個(gè)新的傳感器或應(yīng)用程序需要通過(guò)增加一個(gè)新的獨(dú)立的電子控制單元（ECU）設(shè)備及其關(guān)聯(lián)的傳感器電路來(lái)實(shí)現(xiàn)，這種做法是非常低效的，因?yàn)殡S著點(diǎn)對(duì)點(diǎn)鏈接，需要增加連接的數(shù)量與安裝在車(chē)內(nèi)的ECU數(shù)量呈指數(shù)上升。為了克服這個(gè)問(wèn)題，建立相關(guān)的ECU之間的通信鏈路，允許ECU彼此使用更高級(jí)的功能和共享數(shù)據(jù)，這種增長(zhǎng)逐漸發(fā)展成了現(xiàn)在復(fù)雜的、異構(gòu)的車(chē)載網(wǎng)絡(luò)。相對(duì)于點(diǎn)對(duì)點(diǎn)的鏈路系統(tǒng)，提出使用基于總線的網(wǎng)絡(luò)是一種進(jìn)步，但隨著時(shí)間增加，新的子系統(tǒng)會(huì)被添加到車(chē)輛中，ECU數(shù)量的增加帶來(lái)的是帶寬消耗的顯著增加。傳統(tǒng)的車(chē)輛控制應(yīng)用所需帶寬普遍較低，帶寬問(wèn)題并未引起廣泛的關(guān)注。當(dāng)引入信息娛樂(lè)系統(tǒng)和基于視頻的高級(jí)駕駛輔助系統(tǒng)（ADAS）后，這些應(yīng)用程序相比傳統(tǒng)控制系統(tǒng)的數(shù)據(jù)傳輸帶寬需求有顯著增長(zhǎng)，現(xiàn)有車(chē)載網(wǎng)絡(luò)傳輸帶寬不足的問(wèn)題凸顯，因此迫切需求下一代的車(chē)載網(wǎng)絡(luò)技術(shù)及架構(gòu)。車(chē)載網(wǎng)絡(luò)容量需求的爆發(fā)式發(fā)展，顯然這已經(jīng)超出了CAN總線等傳統(tǒng)車(chē)載網(wǎng)絡(luò)的能力。這也正是以太網(wǎng)與汽車(chē)深度融合和集成的契機(jī)。

近些年來(lái)，基于車(chē)載以太網(wǎng)設(shè)計(jì)電氣通信網(wǎng)絡(luò)已經(jīng)被明確為下一代車(chē)載電子電氣架構(gòu)的發(fā)展方向，且受到了各大整車(chē)廠研發(fā)設(shè)計(jì)部門(mén)的廣泛關(guān)注。在車(chē)載以太網(wǎng)領(lǐng)域，有眾多協(xié)議可供選擇，從而導(dǎo)致一種錯(cuò)誤的印象，即現(xiàn)有協(xié)議可以直接用于車(chē)內(nèi)所有可想象到的應(yīng)用程序。但是，車(chē)載網(wǎng)絡(luò)并非從零開(kāi)始，所選用的協(xié)議也要能滿足特定的需求。比如，新的協(xié)議要能很好地適配于當(dāng)前的車(chē)載網(wǎng)絡(luò)系統(tǒng)，特別是涉及到AUTOSAR架構(gòu)的良好集成以及在出現(xiàn)通信錯(cuò)誤情況下如何確保時(shí)間延遲的快速反應(yīng)機(jī)制。SOME/IP（Scalable service-Oriented MiddlewarE over IP）這樣基于服務(wù)的通信模式，是一種可以滿足汽車(chē)使用需求的開(kāi)放式協(xié)議。但是當(dāng)前汽車(chē)軟件數(shù)目十分龐大，且隨著車(chē)輛功能與系統(tǒng)的分布擴(kuò)展而不斷增加。這些分布功能可能使用一個(gè)ECU中的不同進(jìn)程，也可能擴(kuò)展到不同ECU的不同進(jìn)程中去，隨著系統(tǒng)的復(fù)雜程度增加，不能僅僅將消息放入網(wǎng)絡(luò)中傳輸便完成了功能的實(shí)現(xiàn)。另外，不同ECU可能使用不同的軟件架構(gòu)，甚至是不同的操作系統(tǒng)。所以如何合理的基于SOME/IP設(shè)計(jì)整車(chē)電子電氣通信網(wǎng)絡(luò)是非常關(guān)鍵的，不僅影響著車(chē)輛的開(kāi)發(fā)驗(yàn)證和量產(chǎn)，成本也影響著車(chē)輛網(wǎng)絡(luò)功能的穩(wěn)定性、后續(xù)車(chē)型功能拓展的可行性一系列問(wèn)題。隨著汽車(chē)綠色智能互聯(lián)的快速發(fā)展，對(duì)汽車(chē)運(yùn)行時(shí)的高靈活性、車(chē)輛內(nèi)部與外部服務(wù)的可關(guān)聯(lián)、服務(wù)和軟件的擴(kuò)展與升級(jí)需求都提出了更高的要求，此時(shí)面向服務(wù)架構(gòu)（Service Oriented Architecture）的優(yōu)勢(shì)也變得越來(lái)越凸顯。SOME/IP作為面向服務(wù)架構(gòu)的通信基礎(chǔ)，將會(huì)得到越來(lái)越多的應(yīng)用。

2 SOME/IP

SOME/IP，即 Scalable service-Oriented MiddlewarE over IP protocol，是一種靈活的，基于車(chē)載以太網(wǎng)協(xié)議的，面向服務(wù)的中間件。SOME/IP是一種專(zhuān)門(mén)運(yùn)用于汽車(chē)領(lǐng)域的中間技術(shù)，主要用于控制報(bào)文通信。雖然SOME/IP協(xié)議冗余繁瑣，但從網(wǎng)絡(luò)通訊層面來(lái)看，還是能保證基本的穩(wěn)定與效率。從整車(chē)角度，其提供通信方式是面向服務(wù)的，就是功能實(shí)現(xiàn)，這也是其關(guān)鍵特性與優(yōu)勢(shì)。

區(qū)別于傳統(tǒng)CAN/LIN等總線面向信號(hào)（Signal-Oriented）的通信方式，SOME/IP用于面向服務(wù)（Service-Oriented）的通信，這也是以太網(wǎng)在汽車(chē)領(lǐng)域應(yīng)用的最大優(yōu)勢(shì)所在。面向服務(wù)的通信傳輸是服務(wù)的相關(guān)信息，汽車(chē)以太網(wǎng)應(yīng)用方面最重要的是面向服務(wù)的架構(gòu)，簡(jiǎn)稱(chēng)為 SOA（Service Oriented Architecture）。SOA的核心是服務(wù)，服務(wù)可以簡(jiǎn)單理解為是實(shí)現(xiàn)某種功能的函數(shù)或算法。面向服務(wù)的通信，顧名思義，這種通信是為了對(duì)服務(wù)的相關(guān)信息進(jìn)行傳輸。比如在餐廳點(diǎn)餐，服務(wù)員(Server)就提供了一種“點(diǎn)餐”的服務(wù)(Service)，作為一個(gè)客戶(Client)，就能夠使用這些服務(wù)。服務(wù)的相關(guān)信息就是各種屬性信息、控制信息等內(nèi)容。如果服務(wù)與服務(wù)使用者同在一臺(tái)電腦上，那么可以直接通過(guò)程序接口實(shí)現(xiàn)過(guò)程調(diào)用。但是如果服務(wù)與服務(wù)使用者位于不同的電腦，則需要進(jìn)行遠(yuǎn)程調(diào)用。在遠(yuǎn)程調(diào)用時(shí)，就需要借助中間件及網(wǎng)絡(luò)傳輸實(shí)現(xiàn)信息傳輸，這種通信就是面向服務(wù)的通信，就是要通過(guò)一定的方式對(duì)服務(wù)的相關(guān)信息進(jìn)行打包，打包后再把這些信息在網(wǎng)絡(luò)上進(jìn)行傳遞。

2.1 中間件(MiddlewarE)

“中間件（Middleware）”起源于復(fù)雜的軟件系統(tǒng)開(kāi)發(fā)，并涉及“服務(wù)”所需的所有功能以實(shí)現(xiàn)其他軟件組件之間數(shù)據(jù)交換，這種數(shù)據(jù)交換需要經(jīng)由網(wǎng)絡(luò)，中間件的任務(wù)就是確保需要交換數(shù)據(jù)的軟件組件在網(wǎng)絡(luò)中透明地傳輸數(shù)據(jù)，如圖1所示，中間件在ISO/OSI層的較高層運(yùn)行。其組織傳輸復(fù)雜數(shù)據(jù)（消息傳遞）并調(diào)節(jié)軟件組件之間的函數(shù)調(diào)用（遠(yuǎn)程過(guò)程調(diào)用RPC），服務(wù)提供者作為服務(wù)端（Server），服務(wù)消費(fèi)者作為客戶端（Client），服務(wù)實(shí)現(xiàn)是借助于遠(yuǎn)程過(guò)程調(diào)用機(jī)制（RPC），客戶端和服務(wù)端通過(guò)中間件進(jìn)行信息的傳輸，而中間件是應(yīng)用層軟件和底層硬件之間的軟件統(tǒng)稱(chēng)。

圖1 ISO/OSI模型[1]

2.2 SOME/IP特點(diǎn)

SOME/IP(Scalable service-Oriented MiddlewarE over IP)是車(chē)載以太網(wǎng)通信引入的一個(gè)概念，位于OSI 7層模型的層4之上。在以CAN總線為主的車(chē)載網(wǎng)絡(luò)中，通信過(guò)程是面向信號(hào)的（除了診斷通信之外），這是一種根據(jù)發(fā)送者需求實(shí)現(xiàn)的通信過(guò)程，當(dāng)發(fā)送者發(fā)現(xiàn)信號(hào)的值變化了，或者發(fā)送周期到了，就會(huì)發(fā)送信息，而不考慮接收者是否有需求。而SOME/IP則不同，它是在接收方有需求的時(shí)候才發(fā)送，這種方法的優(yōu)點(diǎn)在于總線上不會(huì)出現(xiàn)過(guò)多不必要的數(shù)據(jù)，從而降低負(fù)載。在車(chē)載網(wǎng)絡(luò)中，某個(gè)ECU有時(shí)會(huì)需要調(diào)用實(shí)現(xiàn)在其他ECU上的服務(wù)，這個(gè)時(shí)候它倆就分別扮演了Client和Server的角色，而SOME/IP就是實(shí)現(xiàn)這種遠(yuǎn)程服務(wù)調(diào)用的接口，如下圖2所示。

SOME/IP提供面向服務(wù)的通信接口，與當(dāng)前汽車(chē)主要總線CAN的面向信號(hào)的通信方式有很大不同。SOME/IP可以大致分為3個(gè)部分：服務(wù)發(fā)現(xiàn)（Service Discovery，SD），遠(yuǎn)程過(guò)程調(diào)用（Remote Procedure Call，RPC）和訪問(wèn)進(jìn)程數(shù)據(jù)。ECU通過(guò)SD在網(wǎng)絡(luò)中查找服務(wù)或者提供服務(wù)，客戶端（Client）通過(guò)RPC去調(diào)用SD提供的方法。此外，ECU還可以將特定事件設(shè)置為通知，由服務(wù)端（Server）ECU自動(dòng)向客戶端ECU發(fā)送服務(wù)內(nèi)容。客戶端ECU的應(yīng)用程序也可通過(guò)讀寫(xiě)函數(shù)去訪問(wèn)任意特定進(jìn)程的數(shù)據(jù)。SOME/IP期望以一種最優(yōu)的方式利用帶寬并實(shí)現(xiàn)靈活的通信方式。

圖2 服務(wù)的遠(yuǎn)程調(diào)用[2]

SOME/IP滿足車(chē)用要求的特性如下：

（1）基于服務(wù)的通信方式；

（2）占用空間?。?/p>

（3）與AUTOSAR兼容（其他中間件均不兼容）；

（4）可伸縮性，小平臺(tái)或超大平臺(tái)均可以使用；

（5）兼容性，可用于車(chē)用的各種操作系統(tǒng)，如AUTOSAR，OSEK和Linux。

2.3 SOME/IP消息格式

圖3是SOME/IP數(shù)據(jù)在以太網(wǎng)報(bào)文中位置，SOME/IP其實(shí)是構(gòu)架在傳輸層之上的應(yīng)用層通信協(xié)議，它的內(nèi)容雖然很多很雜，但本質(zhì)上也就是定義了SOME/IP報(bào)頭和數(shù)據(jù)的內(nèi)容而已。

圖3 SOME/IP數(shù)據(jù)在以太網(wǎng)報(bào)文中位置[1]

（1）Message ID：Message ID的前16 bit表示所使用的服務(wù)ID，服務(wù)是通信總體類(lèi)別（圖4）。每個(gè)服務(wù)需要一個(gè)唯一的服務(wù)ID，有系統(tǒng)集成商進(jìn)行標(biāo)識(shí)。其后的16 bit是方法ID，用于表示構(gòu)成服務(wù)的方法、時(shí)間與字段。相比之下，CAN很少使用基于服務(wù)的通信。不過(guò)SOME/IP里面的Message ID的基本思想與CAN的Message ID類(lèi)似，因此可使用相同的進(jìn)程來(lái)處理SOME/IP的Message ID，這只是對(duì)CAN中的處理方法進(jìn)行增強(qiáng)或者采用即可。

圖4 SOME/IP消息頭格式[1]

（2）Length：長(zhǎng)度字段共32 bit，表示包括有效載荷，報(bào)頭消息和請(qǐng)求/客戶端ID在內(nèi)的字節(jié)長(zhǎng)度。

（3）Request ID：用于區(qū)分同一處理方式的多次調(diào)用，其前16 bit為Client ID并標(biāo)識(shí)特定的客戶端，其后16 bit代表Session ID，Request ID來(lái)源于AUTOSAR的客戶端與服務(wù)器端（控制器之間）的通信。

（4）Protocol Version：表示SOME/IP協(xié)議版本，長(zhǎng)度為8 bit，此一般情況為1。

（5）Interface Version：表示服務(wù)接口版本，長(zhǎng)度為8 bit，此接口的定義與版本均有接口設(shè)計(jì)方提供，若定義了新的版本，則該字段自動(dòng)檢測(cè)接口的兼容性。

（6）Message Type：用于區(qū)分不同的消息類(lèi)型，如表1所示，列舉了所有SOME/IP版本1.0中包含的消息類(lèi)型。

表1 SOME/IP消息類(lèi)型[1]

（7）Return Code：用于表示消息的反饋（接收方是否成功處理消息）。

（8）Payload：有效載荷包含SOME/IP消息的參數(shù)，SOME/IP有效負(fù)載字段的長(zhǎng)度取決于使用的傳輸協(xié)議，對(duì)于UDP而言，SOME/IP有效載荷的范圍為0～1 400 Byte，該上限主要是為日后協(xié)議更改而設(shè)定（如使用IPv6或者添加安全協(xié)議），由TCP可以將數(shù)據(jù)進(jìn)行分段，因此TCP支持更大的有效負(fù)載。UDP同樣支持有效負(fù)載分段。

2.4 服務(wù)和RPC機(jī)制

SOME/IP根據(jù)服務(wù)接口來(lái)定義一系列服務(wù)，服務(wù)接口為依據(jù)已有的通信原則定義的客戶和服務(wù)器的行為。

服務(wù)接口(Service Interface)就是服務(wù)與外界通信的接口，也就是說(shuō)服務(wù)模塊與外界溝通的基本出入口。通俗地理解為你問(wèn)服務(wù)員，我要點(diǎn)一份蛋炒粗面。服務(wù)員反饋，沒(méi)有粗面。這種對(duì)話方式及內(nèi)容就是服務(wù)接口。而至于為什么沒(méi)有，那就是服務(wù)員在接收到客戶端的信息后，根據(jù)服務(wù)員的大腦分析得到的結(jié)果，也就是服務(wù)的內(nèi)部代碼處理的結(jié)果。在通信方面，更多關(guān)注的是服務(wù)接口，而不是服務(wù)的內(nèi)部代碼分析過(guò)程。

圖5SOME/IP中通信原理實(shí)例[1]（C為Client，S為Server）

圖5 概述了SOME/IP支持的不同通信原則，服務(wù)接口包括：

（1）具有響應(yīng)（Request/Response）或者沒(méi)有響應(yīng)（Fire&Forget）的方法。

Request/Response：描述具體請(qǐng)求消息與響應(yīng)消息的通信方案，請(qǐng)求是客戶端向服務(wù)器發(fā)送的調(diào)用方法的消息，響應(yīng)則是服務(wù)器反饋客戶端調(diào)用結(jié)果的消息。

Fire&Forget：描述僅存在請(qǐng)求消息的通信方式，與Request/Response相同，同樣方法向客戶端向服務(wù)器發(fā)送請(qǐng)求調(diào)用，不同的是，此情況下，客戶端并不期待來(lái)自服務(wù)器的回復(fù)響應(yīng)。

（2）事件（Event），即觸發(fā)事件時(shí)，服務(wù)器向客戶端發(fā)送的消息。

服務(wù)器會(huì)周期性地或在情況發(fā)生變化（事件）時(shí)向客戶端發(fā)送具有特定內(nèi)容的消息，前提是客戶端告訴服務(wù)器它希望接收此類(lèi)消息，這也就是“訂閱”。此情況下，客戶端不會(huì)發(fā)送回應(yīng)服務(wù)器的消息。這種通信方式對(duì)于服務(wù)器而言也遵循“Fire&Forget”的原則，Event消息與CAN消息類(lèi)似。

（3）字段（Field），用于獲得、設(shè)置或通知性能或者狀態(tài)。

Field表示可以遠(yuǎn)程訪問(wèn)的屬性，它可以由客戶端設(shè)置。獲取Field的溝通原則與Event一致，不同的是，系統(tǒng)在任何時(shí)候都可以獲取“Field”，而Event只是在事件發(fā)生的時(shí)間內(nèi)有效，因此，“屬性”可以視為一種可以從外部接口尋址的軟件變量，F(xiàn)ield類(lèi)似MOST總線中的“屬性”。

（4）事件組（Event groups），是用于發(fā)布與訂閱處理的時(shí)間和字段的邏輯組。

3 SOME/IP SD服務(wù)發(fā)現(xiàn)

車(chē)載以太網(wǎng)可以為車(chē)內(nèi)通信網(wǎng)絡(luò)提供更高的傳輸速率，且它基于傳統(tǒng)以太網(wǎng)，提供了面向服務(wù)的通信方式。在引入以太網(wǎng)之前，MOST是唯一一個(gè)支持面向服務(wù)的車(chē)載網(wǎng)絡(luò)技術(shù)，因?yàn)?，只有使用MOST的整車(chē)廠的信息娛樂(lè)系統(tǒng)才會(huì)使用面向服務(wù)的通信方式。高端信息娛樂(lè)系統(tǒng)最需要基于服務(wù)提供的復(fù)雜接口，MOST也首先在信息娛樂(lè)系統(tǒng)中需要進(jìn)行遠(yuǎn)程過(guò)程調(diào)用（RPC）。

目前，CAN總線仍為電子電氣通信主流總線，即信息在網(wǎng)絡(luò)中傳輸，由接收器決定是否以及如何處理該信息。但是如駕駛輔助領(lǐng)域，“CAN-approach”的通信方式越來(lái)越不適用。另外，CAN數(shù)據(jù)長(zhǎng)度為8字節(jié)，且沒(méi)有大量的報(bào)頭信息，這些均限制了RPC或服務(wù)發(fā)現(xiàn)（SOME/IP SD）的使用，為滿足未來(lái)的車(chē)載通信需求，通信方式將轉(zhuǎn)換為面向服務(wù)的通信。通信不僅是通過(guò)廣播的方式，同時(shí)也使用單播，因此尋址方式也很重要。對(duì)于單播而言，只有在通信伙伴真正可用時(shí)才有尋址意義。

用于協(xié)助客戶端去尋找可用服務(wù)的一種機(jī)制，服務(wù)(Service)部署在服務(wù)器端（Server），在具體實(shí)現(xiàn)時(shí)（實(shí)例化）有些參數(shù)可能會(huì)發(fā)生變化，比如網(wǎng)絡(luò)地址。為了能夠讓客戶端隨時(shí)找到服務(wù)器上的服務(wù)，因此需要這種服務(wù)發(fā)現(xiàn)機(jī)制?？梢院?jiǎn)單理解為服務(wù)發(fā)現(xiàn)(SD)是Service的秘書(shū)。SD清楚的知道Service的地址、狀態(tài)等內(nèi)容。舉例說(shuō)明，員工要找大領(lǐng)導(dǎo)簽字，得先問(wèn)一下秘書(shū)，領(lǐng)導(dǎo)在嗎、什么時(shí)間有空。秘書(shū)會(huì)告訴你，領(lǐng)導(dǎo)今天在哪個(gè)會(huì)議室開(kāi)會(huì)，什么時(shí)間段有空。在SOME/IP SD包含了發(fā)現(xiàn)服務(wù)、提供服務(wù)、停止提供服務(wù)、訂閱事件組、停止訂閱事件組型的服務(wù)發(fā)現(xiàn)相關(guān)報(bào)文。

通過(guò)SD，SOME/IP可以確定服務(wù)是否可用。然而，服務(wù)發(fā)現(xiàn)機(jī)制（SD）在電氣網(wǎng)絡(luò)設(shè)計(jì)時(shí)仍存在歧義，主要問(wèn)題在于車(chē)載網(wǎng)絡(luò)和功能均偏靜態(tài)。

合理使用SD，是能夠解決看似靜態(tài)的網(wǎng)絡(luò)不斷增長(zhǎng)的動(dòng)態(tài)問(wèn)題。

此外，SD可結(jié)合單獨(dú)可調(diào)節(jié)的生存時(shí)間（TTL），用以表示參數(shù)輸入的有效時(shí)間，一旦TTL過(guò)期，SD則可用于需要進(jìn)行參數(shù)與服務(wù)更新。如果更新消息未能到達(dá)，用戶也可分析對(duì)方的故障行為，且可以開(kāi)始特定的故障處理。這有助于網(wǎng)絡(luò)的穩(wěn)定性。但這不能替代安全應(yīng)用程序發(fā)送的循環(huán)消息。帶有應(yīng)用程序循環(huán)冗余校驗(yàn)（CRC）的循環(huán)消息通常用于端到端的安全應(yīng)用程序。

車(chē)載網(wǎng)絡(luò)越復(fù)雜，越能體現(xiàn)基于服務(wù)的通信方式與SD的優(yōu)勢(shì)，如沒(méi)有基于服務(wù)的通信，車(chē)載以太網(wǎng)網(wǎng)絡(luò)的復(fù)雜度就會(huì)更高。在網(wǎng)絡(luò)中應(yīng)用SD時(shí)，有2種方法。

（1）集中式：一個(gè)ECU監(jiān)視和維護(hù)網(wǎng)絡(luò)的服務(wù)信息，每個(gè)參與者只將相應(yīng)的信息發(fā)給這個(gè)ECU，且僅向這個(gè)ECU做相應(yīng)的請(qǐng)求。

（2）分散式：所有參與通信的成員都遵守以下規(guī)則，每個(gè)節(jié)點(diǎn)通過(guò)多播和廣播的方式宣告可用服務(wù)，且每個(gè)節(jié)點(diǎn)通過(guò)多播或者廣播請(qǐng)求其他節(jié)點(diǎn)的可用服務(wù)。如果服務(wù)請(qǐng)求找到了服務(wù)提供方，他們則可以建立一對(duì)一通信。這種方式的優(yōu)勢(shì)在于，啟動(dòng)延遲非常小，主要取決于物理網(wǎng)絡(luò)的啟動(dòng)時(shí)間，不需要單獨(dú)的ECU對(duì)此過(guò)程進(jìn)行控制，且此過(guò)程存在多個(gè)數(shù)據(jù)源，這意味著沒(méi)有單個(gè)節(jié)點(diǎn)需要處理所有數(shù)據(jù)，此方式分散了負(fù)載和故障風(fēng)險(xiǎn)，簡(jiǎn)言之，不存在單一故障點(diǎn)。

4 實(shí)際設(shè)計(jì)應(yīng)用

上述篇幅介紹了SOME/IP(SD)特點(diǎn)和應(yīng)用原理，下面根據(jù)實(shí)際功能來(lái)介紹SOME/IP(SD)在整車(chē)電子電氣通信網(wǎng)絡(luò)設(shè)計(jì)中的應(yīng)用。

4.1 SOME/IP實(shí)際應(yīng)用

以CD播放器（CD_Player）服務(wù)為例說(shuō)明如何基于實(shí)際功能應(yīng)用SOME/IP和RPC，每個(gè)服務(wù)都必須在開(kāi)發(fā)過(guò)程中通過(guò)其服務(wù)接口定義，這通常使用接口描述語(yǔ)言完成。

Service CD_player

{

Track_number-----------------------//Field

{unsigned int track------------------//the track number

Set(track)--------------//Method for setting the track(uses a request/response method)()

Get()；----------//Method for getting the actual track number played

}

Tray.eject()；-------//Event that is triggered if the eject button is pressed

Boolean tray_state；-//Status OPEN or CLOSED when tray is open or closed respectively

Tray_state:open_tray-//Method(for open the tray)，the return value of this method is

()；

}

在定義了上述接口后，假設(shè)此時(shí)用戶希望將CD設(shè)置為10（track number），那么用戶將會(huì)向CD（服務(wù)器）發(fā)命令CD_player，Track_number.set(10)。該服務(wù)的方法為track_number.set，set值為10。此命令設(shè)置的通信方式為request/response，即該命令設(shè)置后希望接收到回應(yīng)。

假設(shè)另一種使用情況，用戶希望打開(kāi)CD某一個(gè)通道，并反饋完成情況，則上述命令中，用戶將向CD發(fā)送設(shè)置指令，且希望得到反饋（當(dāng)用戶接收到CD_Player.open_Tray()===opens時(shí)，說(shuō)明發(fā)出的命令已經(jīng)成功執(zhí)行）。在基于服務(wù)的通信中，選擇的關(guān)鍵在于數(shù)據(jù)類(lèi)型清晰的定義，數(shù)據(jù)結(jié)構(gòu)以及使用方案和通信原則。在上述功能情形中，還可向CD發(fā)送read（get Field）指令，接收CD track狀態(tài)信息。也可以訂閱CD track狀態(tài)信息，每當(dāng)CD狀態(tài)改變時(shí)會(huì)自動(dòng)發(fā)送通知（event）。還有一條命令，“subscribe.CD_player.event()”，當(dāng)CD打開(kāi)后，CD會(huì)向所有訂閱用戶發(fā)送此命令。

該設(shè)計(jì)與功能驗(yàn)證是基于Technica公司的Andi軟件進(jìn)行的。

4.2 SOME/IP SD 實(shí)際應(yīng)用

SD（Service Discovery）是服務(wù)的信息清單及管理機(jī)制，也是一種服務(wù)，主要實(shí)現(xiàn)服務(wù)尋址及事件訂閱2種功能。SD用來(lái)對(duì)服務(wù)進(jìn)行尋址時(shí)，服務(wù)提供者（Server端）通過(guò)服務(wù)發(fā)現(xiàn)（SD）通知其他ECU（Client端）某服務(wù)可用，并間接地通知該服務(wù)的地址（Server端地址）；服務(wù)消費(fèi)者（Client端）了解到某服務(wù)狀態(tài)后，能夠調(diào)用該服務(wù)的相關(guān)內(nèi)容。SD用來(lái)事件訂閱時(shí)，專(zhuān)門(mén)針對(duì)Event類(lèi)型的接口，可以通過(guò)SD實(shí)現(xiàn)對(duì)Event所在的Event group進(jìn)行訂閱、停止訂閱等操作。

4.2.1 車(chē)輛起動(dòng)

車(chē)輛起動(dòng)是電氣系統(tǒng)設(shè)計(jì)中最復(fù)雜的任務(wù)之一，啟動(dòng)時(shí)每個(gè)ECU均有不同的行為。有些ECU啟動(dòng)速度快，有些慢，有些ECU電壓低至3.5 V仍然可啟動(dòng)，有些則到8 V也是不夠的。因此，啟動(dòng)時(shí)各個(gè)功能就緒所需要的時(shí)間不同，如果不使用服務(wù)發(fā)現(xiàn)（SD），則需要規(guī)定一個(gè)確定所有功能就緒的時(shí)間點(diǎn)，這需要根據(jù)花費(fèi)最長(zhǎng)啟動(dòng)時(shí)間的功能的或者ECU定義。如使用SD，則每個(gè)功能或ECU都可以在準(zhǔn)備就緒時(shí)候宣布其可用性，且通?？梢蕴崆疤峁┯脩艄δ?，在起動(dòng)過(guò)程中，SD在交換式以太網(wǎng)網(wǎng)絡(luò)中，交換機(jī)可以直接通過(guò)SD消息建立地址表。

4.2.2 功能變更

大量的功能選擇意味著OEM根據(jù)客戶要求來(lái)進(jìn)行功能配置，如沒(méi)有SD，每個(gè)ECU執(zhí)行靜態(tài)配置確定其他ECU功能可用性。但是通過(guò)SD、ECU則可以自行建立車(chē)輛可用功能列表，而不需要任何特定組合的預(yù)配置，這一方式更為可靠。車(chē)輛電氣功能越復(fù)雜變化越多，SD優(yōu)勢(shì)越大，越可靠。

5 結(jié)論與總結(jié)

SOME/IP相關(guān)參數(shù)的設(shè)計(jì)是汽車(chē)以太網(wǎng)面向服務(wù)的架構(gòu)SOA設(shè)計(jì)中的主要設(shè)計(jì)內(nèi)容，在本文中介紹的服務(wù)、服務(wù)的提供者、消費(fèi)者、服務(wù)接口的各種方法、事件、字段等內(nèi)容，以及TCP/IP通信中的配置信息，都是以太網(wǎng)SOA設(shè)計(jì)中的主要內(nèi)容，因此對(duì)SOME/IP中各種參數(shù)的理解，對(duì)于整個(gè)架構(gòu)和通信設(shè)計(jì)都非常重要。

車(chē)載以太網(wǎng)中SOME/IP強(qiáng)調(diào)了基于服務(wù)的通信方式，與CAN總線傳輸簡(jiǎn)單消息的Fire&Forget的通信原則有所不同。SOME/IP的序列化確保消息向所有其他流量一樣適合現(xiàn)有的數(shù)據(jù)包格式，而SOME/IP的內(nèi)容則確保了通信雙方之間約定履行的服務(wù)類(lèi)型。隨著汽車(chē)功能配置越來(lái)越復(fù)雜，客戶在購(gòu)車(chē)時(shí)，汽車(chē)廠商向客戶提供了很多選擇，汽車(chē)越大，價(jià)格越高，可供選擇的功能就越多，電氣架構(gòu)及越復(fù)雜，合理正確運(yùn)用SOME/IP可以保證整車(chē)電氣系統(tǒng)功能實(shí)現(xiàn)的同時(shí)，也可以降低未來(lái)車(chē)型改款或者升級(jí)時(shí)所帶來(lái)的開(kāi)發(fā)和管理成本。隨著汽車(chē)綠色智能互聯(lián)的快速發(fā)展，對(duì)汽車(chē)運(yùn)行時(shí)的高靈活性、車(chē)輛內(nèi)部與外部服務(wù)的可關(guān)聯(lián)、服務(wù)和軟件的擴(kuò)展與升級(jí)等需求都提出了更高的要求，此時(shí)面向服務(wù)架構(gòu)（SOA）的優(yōu)勢(shì)也變得越來(lái)越凸顯。SOME/IP作為面向服務(wù)架構(gòu)的通信基礎(chǔ)將會(huì)得到越來(lái)越多的應(yīng)用。