李陽春

（華晨汽車工程研究院，沈陽 110141）

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

縮略語

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

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

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

OTA Over the Air(遠程升級)

V2X Vehicle To X（車聯(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（汽車開放系統(tǒng)構(gòu)架）

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

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

RPCRemote Procedure Call（遠程過程調(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（生存時間）

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

1 概述

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

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

2 SOME/IP

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

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

2.1 中間件(MiddlewarE)

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

圖1 ISO/OSI模型[1]

2.2 SOME/IP特點

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

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

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

SOME/IP滿足車用要求的特性如下：

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

（2）占用空間??；

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

（4）可伸縮性，小平臺或超大平臺均可以使用；

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

2.3 SOME/IP消息格式

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

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

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

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

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

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

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

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

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

表1 SOME/IP消息類型[1]

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

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

2.4 服務(wù)和RPC機制

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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è)此時用戶希望將CD設(shè)置為10（track number），那么用戶將會向CD（服務(wù)器）發(fā)命令CD_player，Track_number.set(10)。該服務(wù)的方法為track_number.set，set值為10。此命令設(shè)置的通信方式為request/response，即該命令設(shè)置后希望接收到回應(yīng)。

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

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

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

SD（Service Discovery）是服務(wù)的信息清單及管理機制，也是一種服務(wù)，主要實現(xiàn)服務(wù)尋址及事件訂閱2種功能。SD用來對服務(wù)進行尋址時，服務(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進行訂閱、停止訂閱等操作。

4.2.1 車輛起動

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

4.2.2 功能變更

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

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

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

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