SOME/IP是一種都有所耳聞的以太網(wǎng)的上層協(xié)議,但是其誕生歷史和協(xié)議內(nèi)容都知道的不多吧! ? SOME/IP的誕生是在以太網(wǎng)引入汽車之后更深入的發(fā)展,因此我們需要從車載以太網(wǎng)的歷史開始講起。 ?
01.以太網(wǎng)引入汽車 ?
2004年,寶馬汽車的OBD診斷口采用的是高速CAN總線,速率為500kbit/s,除去CAN協(xié)議本身的開銷,通過OBD口升級(jí)控制器的凈升級(jí)速度降到200kbit/s。而它預(yù)計(jì)到2008年,軟件更新的數(shù)據(jù)量會(huì)達(dá)到1GB,按照現(xiàn)在CAN的速度來算,更新一次軟件要16個(gè)小時(shí),這個(gè)肯定是不能接受的。經(jīng)過內(nèi)部討論,將升級(jí)1GB數(shù)據(jù)的性能參數(shù)設(shè)置為15min,轉(zhuǎn)換為速度約為9Mbit/s,因此開始考慮引入新的刷寫總線。 ? 從當(dāng)時(shí)現(xiàn)有的選擇來看,只有MOST、USB可選,雖然Flexray的速度可達(dá)10Mbit/s,但是2004年還沒有推出,要到2006年才被推出。 ? MOST總線,2004年那會(huì)兒還是MOST25,速度約7Mbit/s,勉勉強(qiáng)強(qiáng)夠格。是在2001年引入寶馬汽車中的,主要用于同步音頻通信。但是其存在一些缺點(diǎn):??
總線拓?fù)浣Y(jié)構(gòu)問題,由于MOST總線必須是環(huán)形拓?fù)?,這意味在測試儀和網(wǎng)關(guān)之間必須添加另外一個(gè)拓?fù)洵h(huán),或者在連接測試儀前接一個(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)用程序,這也意味著成本高昂的問題。
USB作為消費(fèi)類設(shè)備接口,其在PC上非常常見,因此是適合外部測試儀的,而且通信速度高達(dá)480bit/s,遠(yuǎn)遠(yuǎn)高于需求,但是其缺點(diǎn)太明顯: ?
魯棒性和抗擾性不充分,想要保證信號(hào)的完整性,USB需要昂貴的電纜和連接器。
USB最大支持的線纜長度為4m,難以覆蓋使用場景。
必須為開發(fā)基于汽車的協(xié)議棧和驅(qū)動(dòng)程序。
上面這些已有的無法滿足需求后,寶馬開始研究以太網(wǎng),因?yàn)橐蕴W(wǎng)是一種被充分驗(yàn)證的技術(shù),并且有良好的基礎(chǔ)設(shè)施以及足夠的傳輸速度。 ? 在評(píng)估以太網(wǎng)在汽車上的適用性時(shí),最關(guān)鍵部分是物理層,剛開始預(yù)計(jì)會(huì)像USB一樣,為了滿足魯棒性,需要高昂的線纜和接插件,寶馬通過將以太網(wǎng)連接線換成非屏蔽雙絞線,進(jìn)行抗擾度進(jìn)行測試,結(jié)果表明,非屏蔽線也滿足要求,沒必要做任何修改。 ? 從而寶馬開始了將以太網(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 年開發(fā)。這個(gè)名字清楚地表明它是一種中間件解決方案,可以在控制器之間實(shí)現(xiàn)面向服務(wù)的通信。更具體地說,SOME/IP 提供了廣泛的中間件功能,如序列化、遠(yuǎn)程過程調(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)程過程調(diào)用 (RPC):它是客戶端在需要來自服務(wù)器的一些數(shù)據(jù)時(shí)采用的一種數(shù)據(jù)交換方法。RPC 可能有也可能沒有返回值,即客戶端可以請(qǐng)求數(shù)據(jù)作為響應(yīng),或者簡單地調(diào)用一個(gè)函數(shù)來在服務(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)地接收來自服務(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)文格式(來源AUTOSAR) ?
Message ID ? Message ID又通常叫報(bào)文ID,長度為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í)。 ?
長度(Length) ? 長度字段的長度為32bit,指的是從Request ID到Payload的長度。? ?
請(qǐng)求 ID(Request ID) ? Request ID的長度為32bit,由Client ID和Session ID組成。Client ID是客戶端/服務(wù)器的唯一標(biāo)識(shí);Session ID是客戶端和服務(wù)器之間通信過程中每次調(diào)用的標(biāo)識(shí),可以根據(jù)不同的應(yīng)用場景,決定是否使用Session ID。 ?
協(xié)議版本(Protocol Version) ? 該字段長度為8bit,用來表示當(dāng)前使用的協(xié)議的類型,該字段當(dāng)前固定為0x01。
Message Type
用來識(shí)別不同的消息類型,目前存在的類型如下圖所示,其中TP表示分包的報(bào)文,按照AUTOSAR標(biāo)準(zhǔn)(R21-11)定義如下: ?
Message Type表(來源?ADAS與ECU之吾見)
Return Code
Return Code用來指示Message是否被成功處理了,或針對(duì)請(qǐng)求中的錯(cuò)誤內(nèi)容進(jìn)行反饋,如下圖為AUTOSAR(R21-11)中定義的Return Code類型: ?
Return Code定義表(來源?ADAS與ECU之吾見) ?
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)的傳輸 。 ?
序列化示例(來源AUTOSAR) ?
04.SOME/IP通信機(jī)制
SOME/IP的通信機(jī)制包含遠(yuǎn)程過程調(diào)用、Event和Field。遠(yuǎn)程過程調(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)用場景,可以有不同的發(fā)送方式。 ? Field用以表示某一功能的狀態(tài)量??梢酝ㄟ^Method發(fā)布控制命令,即Setter;也可以通過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通信方式(來源知網(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通方式(來源知網(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通信方式(來源知網(wǎng)) ?
4. Field
Field表示一種功能的狀態(tài),可以用來表示某一狀態(tài)量,如車門、車窗等,對(duì)于Setter來說,請(qǐng)求報(bào)文的有效載荷中存放設(shè)置Field表示狀態(tài)量的控制命令?,對(duì)于Getter來說,請(qǐng)求報(bào)文的有效載荷為空,服務(wù)器通過識(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通信方式(來源知網(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)文(來源AUTOSAR) ?
Flags
Flags的第一個(gè)字節(jié)為標(biāo)志字段,其高三位從高到低依次為重啟標(biāo)志位、單播標(biāo)志位和初始數(shù)據(jù)控制標(biāo)志位,低五位為預(yù)留位。 ?
Entry 陣列
? 服務(wù)發(fā)現(xiàn)是通過SD報(bào)文中的Entry陣列字段攜帶的不同類型Entry來實(shí)現(xiàn)的,
Entry用來同步服務(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通過引用Option陣列中的Option攜帶其他信息,如配置信息、傳輸協(xié)議、端口號(hào)和IP地址等相關(guān)信息。根據(jù)Option的作用不同,一般將Option分為配置Option、單播IP地址Option、多播IP地址Option和SD通信IP地址Option。配置Option用來傳輸服務(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ù)器通過快速的發(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ù)端來說,在Initial Wait階段的時(shí)間是在INITIAL_DELAY_MIN和INITIAL_DELAY_MAX之前的隨機(jī)值,當(dāng)計(jì)數(shù)器超時(shí)后,開始發(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)圖?(來源知網(wǎng)) ? 對(duì)于客戶端來說,客戶端在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階段;若沒有收到服務(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)圖?(來源知網(wǎng))
編輯:黃飛
?
評(píng)論
查看更多