SOME/IP是一種都有所耳聞的以太網(wǎng)的上層協(xié)議，但是其誕生歷史和協(xié)議內(nèi)容都知道的不多吧！ ? SOME/IP的誕生是在以太網(wǎng)引入汽車之后更深入的發(fā)展，因此我們需要從車載以太網(wǎng)的歷史開(kāi)始講起。 ?

01.以太網(wǎng)引入汽車 ?

2004年，寶馬汽車的OBD診斷口采用的是高速CAN總線，速率為500kbit/s，除去CAN協(xié)議本身的開(kāi)銷，通過(guò)OBD口升級(jí)控制器的凈升級(jí)速度降到200kbit/s。而它預(yù)計(jì)到2008年，軟件更新的數(shù)據(jù)量會(huì)達(dá)到1GB，按照現(xiàn)在CAN的速度來(lái)算，更新一次軟件要16個(gè)小時(shí)，這個(gè)肯定是不能接受的。經(jīng)過(guò)內(nèi)部討論，將升級(jí)1GB數(shù)據(jù)的性能參數(shù)設(shè)置為15min，轉(zhuǎn)換為速度約為9Mbit/s，因此開(kāi)始考慮引入新的刷寫總線。 ? 從當(dāng)時(shí)現(xiàn)有的選擇來(lái)看，只有MOST、USB可選，雖然Flexray的速度可達(dá)10Mbit/s，但是2004年還沒(méi)有推出，要到2006年才被推出。 ? MOST總線，2004年那會(huì)兒還是MOST25，速度約7Mbit/s，勉勉強(qiáng)強(qiáng)夠格。是在2001年引入寶馬汽車中的，主要用于同步音頻通信。但是其存在一些缺點(diǎn)：??

總線拓?fù)浣Y(jié)構(gòu)問(wèn)題，由于MOST總線必須是環(huán)形拓?fù)洌@意味在測(cè)試儀和網(wǎng)關(guān)之間必須添加另外一個(gè)拓?fù)洵h(huán)，或者在連接測(cè)試儀前接一個(gè)臨時(shí)的擴(kuò)展環(huán)，這增加了復(fù)雜性。

較高的資源需求，要實(shí)現(xiàn)7Mbit/s的最大帶寬，需要使用1014B的數(shù)據(jù)包，而且需要64個(gè)包組成一個(gè)塊(這個(gè)是MOST-high協(xié)議的一部分)，也就意味著光數(shù)據(jù)包的接收就需要64KB的RAM，在當(dāng)時(shí)這個(gè)資源占太多了。

新接口，MOST25做升級(jí)，屬于全新的接口，與現(xiàn)有的不兼容，需要另做一套診斷應(yīng)用程序，這也意味著成本高昂的問(wèn)題。

USB作為消費(fèi)類設(shè)備接口，其在PC上非常常見(jiàn)，因此是適合外部測(cè)試儀的，而且通信速度高達(dá)480bit/s，遠(yuǎn)遠(yuǎn)高于需求，但是其缺點(diǎn)太明顯： ?

魯棒性和抗擾性不充分，想要保證信號(hào)的完整性，USB需要昂貴的電纜和連接器。

USB最大支持的線纜長(zhǎng)度為4m，難以覆蓋使用場(chǎng)景。

必須為開(kāi)發(fā)基于汽車的協(xié)議棧和驅(qū)動(dòng)程序。

上面這些已有的無(wú)法滿足需求后，寶馬開(kāi)始研究以太網(wǎng)，因?yàn)橐蕴W(wǎng)是一種被充分驗(yàn)證的技術(shù)，并且有良好的基礎(chǔ)設(shè)施以及足夠的傳輸速度。 ? 在評(píng)估以太網(wǎng)在汽車上的適用性時(shí)，最關(guān)鍵部分是物理層，剛開(kāi)始預(yù)計(jì)會(huì)像USB一樣，為了滿足魯棒性，需要高昂的線纜和接插件，寶馬通過(guò)將以太網(wǎng)連接線換成非屏蔽雙絞線，進(jìn)行抗擾度進(jìn)行測(cè)試，結(jié)果表明，非屏蔽線也滿足要求，沒(méi)必要做任何修改。 ? 從而寶馬開(kāi)始了將以太網(wǎng)應(yīng)用到車上，包括組織聯(lián)盟建立車載以太網(wǎng)標(biāo)準(zhǔn)，例如OPEN聯(lián)盟，著手基于以太網(wǎng)的上層協(xié)議，比如下面要講的SOME/IP。 ? 02.什么是SOME/IP？ ? SOME/IP 是 Scalable Service-Oriented Middleware over IP 的縮寫，由寶馬于 2011 年開(kāi)發(fā)。這個(gè)名字清楚地表明它是一種中間件解決方案，可以在控制器之間實(shí)現(xiàn)面向服務(wù)的通信。更具體地說(shuō)，SOME/IP 提供了廣泛的中間件功能，如序列化、遠(yuǎn)程過(guò)程調(diào)用 (RPC)、服務(wù)發(fā)現(xiàn)和訂閱，以使 ECU 軟件能夠相互通信。 ?

SOME/IP 的一些主要特點(diǎn)：

序列化和反序列化：將數(shù)據(jù)結(jié)構(gòu)轉(zhuǎn)換成字節(jié)序列或者將字節(jié)序列轉(zhuǎn)換為數(shù)據(jù)結(jié)構(gòu)，這樣有利于數(shù)據(jù)的高效傳輸。

遠(yuǎn)程過(guò)程調(diào)用 (RPC)：它是客戶端在需要來(lái)自服務(wù)器的一些數(shù)據(jù)時(shí)采用的一種數(shù)據(jù)交換方法。RPC 可能有也可能沒(méi)有返回值，即客戶端可以請(qǐng)求數(shù)據(jù)作為響應(yīng)，或者簡(jiǎn)單地調(diào)用一個(gè)函數(shù)來(lái)在服務(wù)器端執(zhí)行某些任務(wù)。

服務(wù)發(fā)現(xiàn)：服務(wù)發(fā)現(xiàn) (SD) 協(xié)議是 SOME/IP 概念的支柱。在面向服務(wù)的架構(gòu)中，服務(wù)（功能實(shí)體-方法、事件或字段）必須是可發(fā)現(xiàn)的。SOME/IP SD 協(xié)議管理這個(gè)方面——是提供服務(wù)還是阻止它可用。

發(fā)布/訂閱：客戶端可以訂閱服務(wù)器的內(nèi)容，從而可以動(dòng)態(tài)地接收來(lái)自服務(wù)器的更新數(shù)據(jù)。SOME/IP 的發(fā)布/訂閱功能推斷客戶需要哪些數(shù)據(jù)（事件/字段）并共享相同的數(shù)據(jù)。Pub/Sub 由 SOME/IP SD 管理。

在2014年，SOME/IP正式被集成進(jìn)AUTOSAR 4.X，并且得到了持續(xù)的發(fā)展和完善：

AUTOSAR 4.0 - 完成寶馬SOME/IP消息的初步集成；

AUTOSAR 4.1 - 支持SOME/IP-SD及其發(fā)布/訂閱功能；

AUTOSAR 4.2 - 添加transformer用于序列化以及其他相關(guān)優(yōu)化；

AUTOSAR 4.3 - 修復(fù)一些transformer bug同時(shí)添加針對(duì)大量UDP數(shù)據(jù)包的SOME/IP-TP協(xié)議以及其他SOME/IP-SD的優(yōu)化工作。

SOME/IP協(xié)議

? SOME/IP協(xié)議首先定義了報(bào)文的格式，如下圖所示。 ?

SOME/IP報(bào)文格式(來(lái)源AUTOSAR) ?

Message ID ? Message ID又通常叫報(bào)文ID，長(zhǎng)度為32bit，包 含 Service ID 和 Method ID，各16bit，?每一個(gè)SOME/IP報(bào)文有唯一的報(bào)文ID，類似于CAN ID。當(dāng)定義為Method時(shí)，Method ID的最高有效位值為0，當(dāng)定義為Event時(shí)，Method ID的最高有效位為1，此時(shí)的Method ID又叫做Event ID。每一個(gè)服務(wù)應(yīng)該由唯一的 Service ID作為標(biāo)識(shí)；在同一服務(wù)， 不同的Method和Event也有唯一的Method ID或Event ID作為標(biāo)識(shí)。 ?

長(zhǎng)度(Length) ? 長(zhǎng)度字段的長(zhǎng)度為32bit，指的是從Request ID到Payload的長(zhǎng)度。? ?

請(qǐng)求 ID(Request ID) ? Request ID的長(zhǎng)度為32bit，由Client ID和Session ID組成。Client ID是客戶端/服務(wù)器的唯一標(biāo)識(shí)；Session ID是客戶端和服務(wù)器之間通信過(guò)程中每次調(diào)用的標(biāo)識(shí)，可以根據(jù)不同的應(yīng)用場(chǎng)景，決定是否使用Session ID。 ?

協(xié)議版本(Protocol Version) ? 該字段長(zhǎng)度為8bit，用來(lái)表示當(dāng)前使用的協(xié)議的類型，該字段當(dāng)前固定為0x01。

Message Type

用來(lái)識(shí)別不同的消息類型，目前存在的類型如下圖所示，其中TP表示分包的報(bào)文,按照AUTOSAR標(biāo)準(zhǔn)(R21-11)定義如下： ?

Message Type表(來(lái)源?ADAS與ECU之吾見(jiàn))

Return Code

Return Code用來(lái)指示Message是否被成功處理了，或針對(duì)請(qǐng)求中的錯(cuò)誤內(nèi)容進(jìn)行反饋，如下圖為AUTOSAR(R21-11)中定義的Return Code類型： ?

Return Code定義表(來(lái)源?ADAS與ECU之吾見(jiàn)) ?

Payload?：數(shù)據(jù)段，用于放置需要傳輸?shù)臄?shù)據(jù)。 ?

03.序列化

? AUTOSAR對(duì)SOME/IP傳輸數(shù)據(jù)的序列化(數(shù)據(jù)結(jié)構(gòu)轉(zhuǎn)換成線性字節(jié)序列，或反之，如下圖所示)也進(jìn)行了標(biāo)準(zhǔn)化，除了支持AUTOSAR規(guī)定的基本數(shù)據(jù)類型(布爾類型、uint8、uint16、uint32,、sint8、sint16、sint32、float32和float64)之外，還支持包括結(jié)構(gòu)體、聯(lián)合體、字符串、數(shù)組等復(fù)雜的數(shù)據(jù)結(jié)構(gòu)的傳輸 。 ?

序列化示例(來(lái)源AUTOSAR) ?

04.SOME/IP通信機(jī)制

SOME/IP的通信機(jī)制包含遠(yuǎn)程過(guò)程調(diào)用、Event和Field。遠(yuǎn)程過(guò)程調(diào)用是指一個(gè)節(jié)點(diǎn)向另一個(gè)節(jié)點(diǎn)發(fā)送請(qǐng)求服務(wù)，這種方式又稱為Method，多用于客戶端向服務(wù)器發(fā)送控制命令，根據(jù)服務(wù)器是否有反饋分為Request/Response(R/R)和通信Fire&Forget(F&F)通信。 ? Event類似于CAN報(bào)文，用以發(fā)布狀態(tài)，根據(jù)實(shí)際的應(yīng)用場(chǎng)景，可以有不同的發(fā)送方式。 ? Field用以表示某一功能的狀態(tài)量?？梢酝ㄟ^(guò)Method發(fā)布控制命令，即Setter；也可以通過(guò)Method去請(qǐng)求獲取狀態(tài)，即Getter；在狀態(tài)發(fā)生改變時(shí)也可以發(fā)送通知，即Notification。 ?

1.Request/Response(R/R)通信

? ? R/R是一種有請(qǐng)求和響應(yīng)的Method，意味著客戶端發(fā)送請(qǐng)求之后，服務(wù)端需要返回響應(yīng)報(bào)文。 ?

Request/Response通信方式(來(lái)源知網(wǎng)) ? 2. Fire&Forge(T&F)通信 ? 客戶端向服務(wù)器發(fā)送請(qǐng)求報(bào)文，服務(wù)器不會(huì)有響應(yīng)報(bào)文反饋。F&F通信中與R/R通信中的客戶端行為一樣，不同的是F&F通信時(shí)，請(qǐng)求報(bào)文的報(bào)文類型為REQUEST_NO_RETURN，而R/R的報(bào)文類型為RESPONS。 ?

Fire&Forget通方式(來(lái)源知網(wǎng))

? 3. Event

SOME/IP中定義了3種不同的Event方式，分別是周期發(fā)送、值改變觸發(fā)

和值大于某一閾值觸發(fā)。SOME/IP中的Event在網(wǎng)絡(luò)中的發(fā)送是基于事件組傳輸?shù)?，要為定義的每一個(gè)Event分配事件組，同一個(gè)Event可以存在于不同的事件組，但不能定義空的事件組。Event的收發(fā)基于SOME/IP的發(fā)布和訂閱行為，在SD通信時(shí)，客戶端訂閱服務(wù)器的事件組，在正常的SOME/IP通信時(shí)，依據(jù)定義的發(fā)送行為，周期或者值改變觸發(fā)Event的發(fā)送。 ?

Event通信方式(來(lái)源知網(wǎng)) ?

4. Field

Field表示一種功能的狀態(tài)，可以用來(lái)表示某一狀態(tài)量，如車門、車窗等，對(duì)于Setter來(lái)說(shuō)，請(qǐng)求報(bào)文的有效載荷中存放設(shè)置Field表示狀態(tài)量的控制命令?，對(duì)于Getter來(lái)說(shuō)，請(qǐng)求報(bào)文的有效載荷為空，服務(wù)器通過(guò)識(shí)別請(qǐng)求報(bào)文的報(bào)文ID，然后將Field表示的狀態(tài)量放在響應(yīng)報(bào)文的有效載荷中。Notification指的是Field表示的狀態(tài)量值，當(dāng)Field表示的狀態(tài)量值發(fā)生改變或被外界觸發(fā)時(shí)發(fā)送Notification。 ?

Field通信方式(來(lái)源知網(wǎng)) ?

05.SOME/IP SD

? SOME/IP SD報(bào)文是一種特殊的SOME/IP報(bào)文，其報(bào)文格式和SOME/IP報(bào)文是一樣的。不同的是SOME/IP SD報(bào)文的SOME/IP報(bào)頭字段的報(bào)文ID、接口版本、報(bào)文類型和返回碼的值是固定不變的，SOME/IP SD報(bào)文的SOME/IP SD部分又包含了標(biāo)志字段、預(yù)留字段、Entry和Option等字段，SOME/IP SD報(bào)文格式如下圖所示： ?

SOME/IP SD報(bào)文(來(lái)源AUTOSAR) ?

Flags

Flags的第一個(gè)字節(jié)為標(biāo)志字段，其高三位從高到低依次為重啟標(biāo)志位、單播標(biāo)志位和初始數(shù)據(jù)控制標(biāo)志位，低五位為預(yù)留位。 ?

Entry 陣列

? 服務(wù)發(fā)現(xiàn)是通過(guò)SD報(bào)文中的Entry陣列字段攜帶的不同類型Entry來(lái)實(shí)現(xiàn)的，

Entry用來(lái)同步服務(wù)實(shí)例狀態(tài)和處理事件組的發(fā)布和訂閱。依據(jù)SD 報(bào)文中Entry的作用不同將SD的報(bào)文類型分為七種，其中Find報(bào)文、Offer報(bào)文和Stop Offer報(bào)文基于不同的機(jī)制周期發(fā)送，用于同步服務(wù)實(shí)例的狀態(tài)；訂閱事件組報(bào)文、停止訂閱事件組報(bào)文、訂閱ACK報(bào)文和訂閱NACK報(bào)文用于處理事件組的發(fā)布和訂閱。 ?

Option 陣列

SD報(bào)文中的Entry通過(guò)引用Option陣列中的Option攜帶其他信息，如配置信息、傳輸協(xié)議、端口號(hào)和IP地址等相關(guān)信息。根據(jù)Option的作用不同，一般將Option分為配置Option、單播IP地址Option、多播IP地址Option和SD通信IP地址Option。配置Option用來(lái)傳輸服務(wù)名稱、協(xié)議類型、實(shí)例名稱等信息，IP地址Option分別表明節(jié)點(diǎn)通信單播、多播的地址信息和SD通信地址信息。 ?

06.SOME/IP SD通信機(jī)制

? ? SD中，不管是客戶端還是服務(wù)端，通信行為分為Down和Available，在Available下又分為Initial Wait階段、Repetition階段和Main階段。 ? 在Down階段，服務(wù)不可用。服務(wù)可用后會(huì)立即進(jìn)入Initial Wait階段，該階段的作用一是避免流量突發(fā)，防止擁堵；二是可以將多個(gè)Entry放到一個(gè)SD報(bào)文中，降低報(bào)文數(shù)量。在Repetition階段，客戶端和服務(wù)器通過(guò)快速的發(fā)送Find和Offer報(bào)文實(shí)現(xiàn)服務(wù)消費(fèi)關(guān)系的快速同步， 在Main階段，SD通信處于穩(wěn)定狀態(tài)，為了降低SD報(bào)文的數(shù)量，定義客戶端不發(fā)送Find報(bào)文，而服務(wù)器以相對(duì)較慢的周期發(fā)送Offer報(bào)文。 ? 對(duì)于服務(wù)端來(lái)說(shuō)，在Initial Wait階段的時(shí)間是在INITIAL_DELAY_MIN和INITIAL_DELAY_MAX之前的隨機(jī)值，當(dāng)計(jì)數(shù)器超時(shí)后，開(kāi)始發(fā)送第一個(gè)offer報(bào)文，并且進(jìn)入Repetition階段，在這個(gè)時(shí)候，會(huì)定期發(fā)送REPETITIONS_MAX次offer報(bào)文。然后進(jìn)入Main階段，在Main階段會(huì) 以 周 期 時(shí) 間 CYCLIC_OFFER_DELAY 周 期 性 發(fā) 送Offer報(bào)文。若收到客戶端發(fā)送的Find報(bào)文，服務(wù)器單播響應(yīng)Offer報(bào)文。 ?

服務(wù)端的狀態(tài)跳轉(zhuǎn)圖?(來(lái)源知網(wǎng)) ? 對(duì)于客戶端來(lái)說(shuō)，客戶端在Down階段不請(qǐng)求服務(wù)。若收到服務(wù)器發(fā)送的Offer報(bào)文，客戶端存儲(chǔ)該服務(wù)實(shí)例的狀態(tài)，并啟動(dòng)該Offer報(bào)文的TTL計(jì)時(shí)器，此時(shí)若客戶端請(qǐng)求服務(wù)，直接進(jìn)入Main階段。 ? 在客戶端需要請(qǐng)求服務(wù)后，進(jìn)入Initial Wait階段。若收到服務(wù)器發(fā)送的Offer報(bào)文，取消計(jì)時(shí)器，直接進(jìn)入Main階段；若沒(méi)有收到服務(wù)器發(fā)送的Offer報(bào)文，等待INITIAL_DELAY(位于INITIAL_DELAY_MAX和INITIAL_DELAY_MIN之間的隨機(jī)值)，計(jì)時(shí)器超時(shí)后，發(fā)送一個(gè)Find報(bào)文，進(jìn)入Repetition階段。 ? 客 戶 端 在Repetition階 段 定期快速發(fā)送REPETITIONS_MAX次Find報(bào)文，若收服務(wù)器發(fā)送的Offer報(bào)文，停止當(dāng)前階段的計(jì)數(shù)和計(jì)時(shí)，進(jìn)入Main階段。 ? 在Main階段，SD通信已進(jìn)入相對(duì)穩(wěn)定的狀態(tài)，這里定義客戶端不發(fā)送Find報(bào)文，以降低SD報(bào)文數(shù)量。 ?

客戶端狀態(tài)跳轉(zhuǎn)圖?(來(lái)源知網(wǎng))

編輯：黃飛

?