車載以太網協議棧總共可劃分為五層，分別為物理層，數據鏈路層，網絡層，傳輸層，應用層，其中今天所要介紹的內容SOME/IP就是一種應用層協議。
SOME/IP協議內容按照AUTOSAR中的描述，我們可以更進一步的拆分為三類子協議：應用層的SOME/IP標準協議，SOME/IP-SD協議以及TP層的SOME/IP-TP協議。
SOME/IP協議特點
| 特點 | 描述 |
| Serialization(序列化) | 在ECU內部進行序列化及反序列化以實現信息的高效傳輸 |
| Remote Procedure Calls(遠程調用) | 該協議可以傳遞消息(作為字段發送)以及方法的遠程調用(實現過程/函數調用) |
| Service Discovery(服務發現) | SOME/IP協議的數據通信發生在客戶端-服務器模型中,同時服務器提供客戶端可以訂閱的許多不同服務。該協議允許客戶端動態查找服務、訂閱服務并配置對服務的訪問。 |
| Publish/Subscribe(發布與訂閱) | SOME/IP中的數據通信通過發布/訂閱進行。客戶端可以訂閱服務器提供的服務,服務器可以向活躍的訂閱者發布通知。 |
| Segementation of UDP message | 每當服務器必須向活動訂閱者發送通知時，他們是通過UDP協議發送的。SOME/IP能夠在不需要任何分段的情況下傳送大型UDP消息。 |
SOME/IP協議解析
如果應用了 E2E 通信保護，則 E2E 報頭將放置在 Return Code 之后，具體取決于為 E2E 報頭選擇的偏移值。默認偏移值為 64 位，這將 E2E 報頭恰好放置在 Return Code 和 Payload 之間。
SOME/IP協議Header包含Message ID，Request ID, Protocal Version 以及Interface Version。
各字段解釋如下：
| Item | Description |
| Message ID | 前2個字節為Service ID，后2個字節為Method ID（每個服務僅定義一個唯一的Service ID，Method ID的最高位為0即為方法（包括Method Filed.Getter及Filed.Setter），最高位為1就為事件（包括Event和Filed.Notify）） |
| Length | 標識從Request ID開始至SOME/IP報文結束的長度 |
| Request ID | 前2個字節為Client ID，用來識別一個客戶端；后2個字節為Session ID，用來識別同一個客戶端的多次請求。（其中Client ID可通過配置前綴或者固定值來實現唯一性，可不進行Session處理，如果需要，則Session ID需根據各自的用例從0x0001遞增） |
| Protocol Version | 協議版本號，目前固定為1 |
| Interface Version | 用來識別服務接口的主版本號，由用戶定義 |
| Message Type | 用來識別不同的消息類型，Message Type（8Bits）的Bit5標識TP-Flag，當TP-Flag=1時，標識一個TP類型的Message Type (當SOME/IP下層通信協議為UDP，且SOME/IP傳輸大數據（>1452Bytes）時，將使用SomeIpTp進行分段） |
| Return Code | 用來指示Message是否被成功處理了，或針對請求中的錯誤內容進行反饋 |
| E2E Header | 可選是否使能，并且可變長度（默認長度是8Bytes），可選使用一種E2E profile（常用E2E Profile4） |
| Payload | 有效載荷，序列化和反序列化定義了 PDU 中所有數據結構的確切位置，并且考慮了內存對齊 |
Message Type
用來識別不同的消息類型，目前存在的類型如下所示，其中TP表示分包的報文,按照AUTOSAR標準(R21-11)定義如下：
| ID | Name | Description |
| 0x00 | REQUEST | A request expecting a response 請求并期待響應 |
| 0x01 | REQUEST_NO_RETURN | A fire&forget request 請求但不期待響應 |
| 0x02 | NOTIFICATION | A request for a notification expecting no response 通知/事件回調的請求，不期待有響應 |
| 0x40 | REQUEST_ACK | Acknowledgment for REQUEST (optional) REQUEST的ACK確認 |
| 0x41 | REQUEST_NO_RETURN_ACK | Acknowledgment for REQUEST_NO_RETURN (informational) REQUEST_NO_RETURN的ACK確認 |
| 0x42 | NOTIFICATION_ACK | Acknowledgment for NOTIFICATION (informational) NOTIFICATION的ACK確認 |
| 0x80 | RESPONSE | The response message 響應 |
| 0x81 | ERROR | The response containing an error 響應中包含的錯誤 |
| 0x20 | TP_REQUEST | TP segment of a Request Message for methods TP請求并期待響應 |
| 0x21 | TP_REQUEST_NO_RETURN | TP segment of a Request Message for Fire & Forget methods TP請求但不期待響應 |
| 0x22 | TP_NOTIFICATION | TP segment of an Event (Notification) Message TP通知/事件回調的請求，不期待有響應 |
| 0xA0 | TP_RESPONSE | TP segment of a Response Message for methods TP響應 |
| 0xA1 | TP_ERROR | TP segment of an Error Message for methods TP響應中包含的錯誤 |
Return Code
用來指示Message是否被成功處理了，或針對請求中的錯誤內容進行反饋，如下為AUTOSAR(R21-11)中定義的Return Code類型：
| ID | Name | Description |
| 0x00 | E_OK | 沒有錯誤發生 |
| 0x01 | E_NOT_OK | 發生了未定義的錯誤 |
| 0x02 | SOMEIPXF_E_UNKNOWN_SERVICE | 未知的服務ID |
| 0x03 | SOMEIPXF_E_UNKNOWN_METHOD | 未知的Method ID |
| 0x04 | SOMEIPXF_E_NOT_READY | 應用程序未就緒 |
| 0x05 | SOMEIPXF_E_NOT_REACHABLE | 運行該服務的系統不可用 |
| 0x06 | SOMEIPXF_E_TIMEOUT | 發生超時 |
| 0x07 | SOMEIPXF_E_WRONG_PROTOCOL_VERSION | SOME/IP協議版本不支持 |
| 0x08 | SOMEIPXF_E_WRONG_INTERFACE_VERSION | 接口版本不匹配 |
| 0x09 | SOMEIPXF_E_MALFORMED_MESSAGE | 反序列化錯誤 |
| 0x0A | SOMEIPXF_E_WRONG_MESSAGE_TYPE | 接收到不符合預期的消息類型 |
| 0x0B | E_E2E_REPEATED | E2E重復錯誤 |
| 0x0C | E_E2E_WRONG_SEQUENCE | E2E錯誤的時序 |
| 0x0D | E_E2E | 沒有進一步的E2E錯誤 |
| 0x0E | E_E2E_NOT_AVAILABLE | E2E不可用 |
| 0x0F | E_E2E_NO_NEW_DATA | 沒有E2E計算的新數據 |
| 0x10-0x1F | RESERVED | 預留給到SOME/IP一般性錯誤 |
| 0x20-0x5E | RESERVED | 預留給到服務及方法的特定錯誤 |
Payload的序列化與反序列化
SOME/IP報文收發的過程中，上層應用所定義的Method、Event、Field參數都是面向用戶的struct，string等，序列化就是將這些輸出參數轉換為字節流的過程；而反序列化的過程正好相反，就是將字節流反向解析成struct、string等具體的參數。
大小端：
SOME/IP報文的payload(負載)大小端(字節序)指的是數據在內存中的存儲和傳輸順序。在計算機系統中,數據的存儲和傳輸順序主要有兩種標準:大端字節序(Big-Endian)和小端字節序(Little-Endian)。
-大端字節序(Big-Endian):是指數據的高位字節存放在低地址處,而低位字節存放在高地址處。也就是說,從內存的起始位置開始,第一個字節是最高位字節。
-小端字節序(Little-Endian):是指數據的低位字節存放在低地址處,而高位字節存放在高地址處。在這個模式下,內存起始位置存放的是最低位字節。
SOME/IP報文的payload部分可以采用上述兩種字節序中的任何一種,這取決于數據交換雙方的協議約定或者通信端點的實現。在網格協議中,端字節序通常由協議規范明確指出。開發者在處理SOME/IPP報文時,必須確保發送方和接收方在端字節序上保持一致,以避免數據解析錯誤。
SOME/IP通信機制
服務發現(Service Discovery)
服務發現的通信機制是通過SOME/IP-SD協議實現的，主要是為了實現在車載以太網中告知客戶端當前服務實例的可用性及訪問方式，可通過Find Service 和Offer Service來實現。
SOME/IP 服務發現流程可以分為以下三大基本步驟：
Client通過發送Find Service的報文去尋找車載網絡中可用的服務實例；
Server接收到Client的Find Server后通過UDP發送Offer Service響應；
Client通過發送Subcribe Event Group去訂閱相關Event；
Server檢查是否滿足Client是否滿足訂閱條件，如果滿足回復ACK，如果不滿足，則回復NACK；
Client成功訂閱相關事件后，Server會按照事件本身屬性來實現對已訂閱該事件的Client的發布；
遠程進程調用(RPC)
遠程進程調用主要可分為四種通信模式：
Request/Response通信模式
可歸納為Method中的一種；其基本通信模型如下圖所示：
Request-Response模型作為一種最為常見的通信方式，其主要任務就是客戶端發送請求信息，服務端接收到請求，進行相關處理之后進行相應的響應。
Fire&Forget通信模式
可歸納為Method中的一種；
該通信模型的主要任務就是客戶端向服務端發送請求，服務端無需進行任何響應，有點類似診斷服務中的抑制正響應。
Notification Event通信模式
該通信模式主要描述了發布 /訂閱消息內容，主要任務就是為了實現客戶端向服務端訂閱相關的事件組，當服務端的事件組發生或者值發生變化時，就需要向已訂閱該事件組的客戶端發布更新的內容。
遠程進程控制(Field)
訪問進程通信機制主要是為了實現針對對應用程序的數據獲取與更改，主要任務就是實現客戶端通過Getter獲取Server的值，通過Setter設置Server的值。
Field就可理解為一個Service的基本屬性，可包含Getter，Setter，Notifier三種方式。其中Getter就是讀取Field中某個值的方法，Setter就是一種改變Field值的方法，而Notifier則是一種當Field中的值發生變化的觸發事件，發生變化時就通知Client。
錯誤處理機制
AUTOSAR為了更為高效的定位到通訊過程中的問題所在，制定了一套檢查SOME/IP協議格式內容的錯誤處理機制。比如版本信息檢查，服務ID等，其他故障信息可以在Payload中進行詳細定義。目前SOME/IP支持以下兩種錯誤處理機制，這兩種uowu處理機制可以根據配置進行選擇。
-消息類型0x80，Response信息，即可以通過Response Message中的Return Code來定位到問題所在；
-消息類型0x81，顯式的錯誤信息；
主要是校驗協議首部結構，對Message Type和Return code進行賦值，通知對端。
參考：
AUTOSAR SOME/IP Protocol Specification：https://www.autosar.org/fileadmin/standards/R19-11/FO/AUTOSAR_PRS_SOMEIPProtocol.pdf
智猩猩
這樣的問題怎么解決)
