“標準的網絡七層架構，SOME/IP (Scalable service-Oriented MSOME/IP (Scalable service-Oriented MiddlewarE over IP) 是車載以太網通信引入的一個概念，位于OSI 7層模型的層4之上。在以CAN總線為主的車載網絡中，通信過程是面向信號的（除了診斷通信之外），這是一種根據發送者需求實現的通信過程，當發送者發現信號的值變化了，或者發送周期到了，就會發送信息，而不考慮接收者是否有需求。而SOME/IP則不同，它是在接收方有需求的時候才發送，這種方法的優點在于總線上不會出現過多不必要的數據，從而降低負載。”
服務是SOME/IP的最核心的一個概念，屬于會話層的協議。在一個服務中，定義了Server和Client兩個不同角色：Server提供服務，Client調用服務。對于同一個服務，只能存在一個Server，但可以同時存在多個Client調用服務。一個Service由0~多個Event/Method/Field組成。與CAN相比，面向服務的通訊方式能夠大大降低總線的負載率。
-
在以CAN總線為主的車載網絡中，通信過程是面向信號的（除了診斷通信之外），這是一種根據發送者需求實現的通信過程，當發送者發現信號的值變化了，或者發送周期到了，就會發送信息，而不考慮接收者是否有需求。
-
而SOME/IP則不同，它是在接收方有需求的時候才發送，這種方法的優點在于總線上不會出現過多不必要的數據，從而降低負載。
-
在車載網絡中，某個ECU有時會需要調用實現在其他ECU上的個服務，這個時候它倆就分別扮演了client和server的角色，而SOME/IP就是實現這種遠程服務調用的接口。
調用或引用一個進程/函數/子程序，通常由Client發起，并由Server答復。Request是最常見的一種Method，由Client向Server請求數據；Response是Request的結果，由Server答復Client的Request。而Method Fire & Forget方式，只Client向Server發起，但Server對該請求不回復。
一個單向的數據傳輸，只能是on change類型，用于Server主動向訂閱（Subscribe）了相關服務的Client發布（Publish）信息。
Notifier：通知，Server的Client訂閱了服務后第一時間主動向其發送數據。
Getter：獲取，由Client向Server請求數據。
Setter：設置，由Client修改Server的數據。
NOTIFICATION又分為Event和Field 兩類，這兩類通知都需要首先使用SOME/IP-SD(Service Discovery)來進行服務訂閱，然后才能發布通知。區別在于，Event是某一時刻的快照，只是事件通知，而Field除了事件通知之外，還具有Getter和Setter的功能，即對信息進行讀寫的操作。
SOME/IP-SD可以被當作SOME/IP的一種特殊服務，前面提到過，client可以遠程調用server提供的服務，或者訂閱server發布的內容，那么client是怎么知道server提供哪些服務呢，就是通過SOME/IP-SD來實現服務發現過程的。
通常在傳輸數據時，為了使數據傳輸更可靠，要把原始數據分批傳輸，并且在每一批數據的頭和尾都加上一定的輔助信息，比如數據量的大小、校驗位等，這樣就相當于給已經分批的原始數據加一些外套，這些外套起標示作用，使得原始數據不易丟失，一批數據加上“外套”就形成了傳輸通道的基本傳輸單元，叫做數據幀或數據包，而其中的原始數據就是payload。
SOME/IP 數據的格式：
上圖是SOME/IP數據的格式，除了最下面的Payload之外都屬于SOME/IP的header。SOME/IP消息由報頭header和有效負載Payload組成。
-
-
Length：包含從請求ID到SOME/IP消息結束的長度（以字節為單位）
-
請求ID：允許提供者和訂閱者區分同一方法、事件、getter或setter的多個并行使用
-
-
-
-
Message Type [8 Bit]，它有以下幾種取值：
-
-
REQUEST_NO_RETURN（不期待響應的請求）
-
-
-
由于以太網數據傳輸服務需要由Server和Client兩個部分共同完成，因此在進行數據傳輸之前，需要準備一系列的工作來確認Server和Client之間是否已建立網絡連接。其次，Client還要詢問Server能否提供所需的服務，滿足數據傳輸需求，并對服務的Event進行訂閱。這些工作都是通過SOME/IP服務發現（Service Discovery）實現的。
服務發現的報文格式與一般的SOME/IP報文相同，但是其Message ID固定為0xFFFF8100。
SOME/IP SD報文也是一種SOME/IP的數據報文，是在SOME/IP數據報文的前提上進行了擴展需求，增加了Entry、Option等字段；Entries用于同步服務實例的狀態和發布/訂閱的管理，Options用于傳輸Entries的附加信息。
SOME/IP SD數據報文的ServiceID（0xFFFF）、MethodID（0x8100）、Request ID（0x0000）、ProtocolVersion（0x01）、Interface Version（0x01）、MessageType（0x02）、ReturnCode（0x00）等等屬性都是一個固定值。
Entry字段是為服務實例的“入口”，該入口包含服務實例以及需要訂閱的事件組的信息。基本上是通過Entry來實現提供服務、發現服務，以及訂閱事件組的功能。
對于
Offer/ StopOfferService、Subscribe/ StopSubscribe
和
SubscribeAck/ Nack
，每一組Entries都共用了Type值，但通過TTL字段可以分辨出究竟是開始或是停止提供服務，是訂閱或者取消訂閱，是訂閱成功應答或者訂閱失敗應答：當TTL = 0時，表示報文對應的服務實例失效，此時對應的Type類型分別就是停止提供服務、停止訂閱事件以及訂閱失敗應答。
每一個Option都是有一個2字節的Length字段、1字節的Type字段和1字節的保留位開始的。Length字段指示的長度是從保留位開始的。Options的類型如下表所示：
不管是Server還是Client，都有同樣的狀態機，但是他們的狀態機具有不同的行為。
狀態 |
服務端行為 |
客戶端行為 |
|
|
|
服務未被應用請求，則停留在該狀態；收到OfferService，啟動TTL計時器，此時服務若被應用請求，進入Main；
|
|
|
收到Find Service報文后服務端忽略此消息；
INITIAL_DELAY，當定時器超時進入Repetition。
|
如果收到OfferService，取消計時器，進入Main ；
計時器超時發送第一個Find service，進入Repetition。
|
|
|
收到某客戶端的FindService，會延遲一定時間后，發送單播OfferService給服務請求端；
收到SubscribeEventgroup后，發送單播Ack/Nack，啟動此訂閱Entry的TTL計時器；
如果收到StopSubscribeEventgroup，停止此訂閱Entry的TTL計時器；
如果服務不可用，離開此階段進入Down ，并發送StopOfferService通知所有客戶端。
|
收到Offer Service，停止發送計數和計時，立即進入Main觸發發送SubscribeEventgroup；
服務請求被釋放，進入Down ，有訂閱，則發送StopSubscribeEventgroup。
|
|
|
收到某客戶端的FindService，不影響發送計數，發送單播OfferService給服務請求端；
收到SubscribeEventgroup后，發送單播Ack/Nack，啟動此訂閱Entry的TTL計時器；
收到StopSubscribeEventgroup后，停止此訂閱Entry的TTL計時器；
服務不可用，離開此階段進入Down，并發送StopOfferService。
|
收到Offer Service，觸發發送SubscribeEventgroup；
收到StopOfferService，則停止所有計時器；
服務請求被釋放，進入Down Phase；若有訂閱，則發送StopSubscribeEventgroup。
|
SOME/IP序列化
4.1 概念
序列化（Serialization）指的是將數據結構或對象依據事先定義的規則轉換成二進制串的過程；反序列化（Deserialization）指的是將二進制串依據相同規則重新構建成數據結構或對象的過程。
4.2 說明
在AUTOSAR中是指數據在PDU中的表達形式，可以理解為來自應用層的真實數據轉換成固定格式的字節序，以實現數據在網絡上的傳輸。軟件組件將數據從應用層傳遞到RTE層，在RTE層調用SOME/IP Transformer，執行可配置的數據序列化（Serialize）或反序列化（Deserialize）。SOME/IP Serializer將結構體形式的數據序列化為線性結構的數據；SOME/IP Deserializer將線性結構數據再反序列化為結構體形式數據。在服務端，數據經過SOME/IP Serializer序列化后，被傳輸到服務層的COM模塊；在客戶端，數據從COM模塊傳遞到SOME/IP Deserializer反序列化后再進入RTE層。如下圖參考Autosar Com過程
4.3 舉例
一個unit32類型數據（0x12345678）的序列化。
客戶端發送一條Request消息，該消息由服務端Response。（帶返回值的函數調用）
客戶端向服務器調用方法，無需服務器響應消息的請求稱為fire＆forget。（空函數調用）
與CAN報文類似，當客戶端訂閱Event Group后，當發生某些特定事件時（周期更新、值發生改變或值改變了），服務器就會給客戶端發送Event報文。（應用數據轉換）
SOME/IP通過以太網提供面向服務的通訊，采用SOME/IP-Service Discovery定位服務實例，并檢測服務的運行狀態，同時發布訂閱處理功能。
客戶端收到需要的服務，會發送訂閱報文，服務端給出訂閱ACK后，開始發送Event。所有需要Event或NotificationEvent的客戶端必須在運行時間中利用SOME/IP-SD在某個server上注冊。
對每一個服務實例或事件組，服務發現在發送條目時必須至少包含初始等待階段、重復階段和主階段。
隨機等待一段時間后發送報文（發現服務和提供服務條目）。
服務發現實現時必須在重復階段等待一段時間，且發送的條目數量有限制。如果發送的條目數量設置為0，則必須跳過重復階段。在初始等待階段之后服務實例進入主階段。
在進入主階段之后，必須等待一段時間后發送第一條報文，循環發送提供服務報文。
當某ECU的服務實例停止服務時，必須發送停止提供服務條目。服務端的狀態機如下圖所示：
客戶端在Down階段如收到提供服務條目，可內部調用服務請求；如未收到提供服務條目，則進入初始等待階段等待一段時間后進入重復階段發送報文，接收到提供服務條目，進入主階段。當收到服務實例停止服務時，服務停止，仍停留在主階段。客戶端的狀態機如下圖所示：
在AUTOSAR架構中，SOME/IP-SD模塊位于AUTOSAR BSW Mode Manager module（BswM）和AUTOSAR Socket Adaptor module (SoAd)之間，如圖11所示。BswM模塊提供了通用模式請求和服務請求之間的連接。SoAd模塊則處理以太網堆棧和Sd模塊之間的服務請求。通過配置SoAd中的SocketConnection表，可以接收其他ECU的Sd模塊發來的單播和多播報文。
