作者結合自身的工作經驗介紹SomeIP協議以及在AutoSAR中的實現。汽車不斷智能化和網聯化的趨勢，使得原本的通訊方式（CAN）不堪重負，因此新的需求帶來了新的技術，SomeIP應運而生。
1 SomeIP的由來
隨著汽車智能化和網絡化的發展，汽車自動駕駛、車載娛樂、遠程診斷升級等新技術對車載通信提出了更高的要求。如何將現有的以太網技術運用到汽車領域是我們面臨的一大挑戰。而在汽車領域長期都是CAN通信占據主導地位，在汽車中如何找到一種像CAN、MOST一樣通信方式，同時支持現有的TCP、UPD協議，又具有網絡通信的單播協議，有限制的使用多播和廣播通信，加強對以太網的重用性，充分利用以太網傳輸數據多，安全性高等特點，開發一種合適的中間來滿足上面的要求是不容易的，而SomeIP的誕生成功的將以太網通信作為一種中間件成功運用到了車載通信領域。
2 SomeIP簡介
SomeIP (Scalable service-Oriented Middlewareover IP) 是車載以太網的一種通信協議。對于熟悉CAN通信的開發者而言，CAN通信一般屬于周期或者觸發的形式在總線上傳輸的，而SOMEIP則不同，它是在接收方有需求的時候才發送，他是一種以服務為導向的數據通信方式。
SomeIP通信協議基于以太網通信協議傳輸，在一幀以太網數據中的位置如下所示
SomeIP數據包主要包括兩大部分，分別是Header和Data。在傳輸的過程中可以通過TCP和UDP兩種通信數據協議進行傳輸。
SomeIP定義的通信方式主要包括四大類。分別是:
1. Methods:Methods包含了請求后有應答的Method，和請求后沒有應答的Method（Fire&Forget）。
2. Event：當某種事情發生后，服務端向客戶端發送的Message。
3. Field：Get/Set/Notifier某種屬性或者狀態。
4. EventGroup：用來進行publish/subscribe處理Eventsand Fields的通信的邏輯組。
其中SomeIP中與數據通信相關的幾個術語如下：
1. Request/Response：客戶端向服務端請求特定的報文，然后服務端將相應的數據報文返回給客戶端。
2. Fire&Forget：客戶端調用服務端方法的報文，通過請求完成方法遠程調用；
3. Notification：對應Event接口類型，類似CAN報文，在特定的事件觸發下，服務端會發給客戶端一個notification報文主要包括周期性事件、數據Changed等
4. Publish/Subscribe概念：主要用于SomeIP的SD（服務發現），客戶端首先訂閱相關的服務，只有訂閱成功后，才允許進行Notification通信。
5. Field：一個可被遠程訪問的屬性。主要包含三種類型的數據通信Getter、Setter和Notifier。
其中Getter讀取屬性值，請求報文的payload為空，響應報文中含有當前屬性值；
Setter設置屬性值，將預設值置于請求報文的payload中，屬性的設置結果放于響應報文中，Notifier類似于Event，Notifier在訂閱完成后，會立即發送InitialEvent，通知當前值。
SomeIP面向服務的通信機制分兩類：分別是請求應答類和提交訂閱類。
其中請求應答類型的數據主要包括 Fire&Forget通信，Method、Getter、Setter類型的數據通信；
而提交訂閱類通信主要包括Event和Field中的Notifier。
Method通信
分為有應答的通信Request&Response和無應答的Fire&Forget通信
Request&Response：
Fire&Forget：
Field通信
主要包括三種類型，Set、Get、Notifier。
Set和Get是客戶端向服務器發送的一種請求通信
Notifier是訂閱后，服務端的通知。
Set/Get：
Notifier：
事件通知
由client向server訂閱服務內容，然后server向client自動發布服務內容。
Notification分為Event和Field兩類，這兩類通知都需要首先使用SoemIP-SD(ServiceDiscovery)來進行服務訂閱，然后才能發布通知。
區別在于，Event是僅僅是某個事件的發生，只是事件通知，Event沒有初始值，同時Event的生命周期沒有定義，
而Field除了事件通知之外，還具有Getter和Setter的功能，即對信息進行讀寫的操作，同時帶有初始化的事件僅僅在Field中。
3 SomeIP Header
SomeIP協議的Header主要包括：
Message ID （32bit）
Length（32bit） --> Length（32bit）表示Request ID至Payload的字節長度；
RequestID（32bit）
ProtocolVersion（8bit）
InterfaceVesion（8bit）
MessageType（8bit）
ReturnCode(8bit)
Message ID類似CANID主要用于區分不同的服務和服務接口，其中分為16bit的ServiceID和16bit的MethodID，
MethodID的最高位為0表示的是Method
MethodID最高為為1表示的是Event或者Notifier。
在SomeIP中由于可以支持多種不同的數據通信，因此可以通過MethodID的最高位來判斷具體的通信方式。
RequestID（32bit）用來響應特定的數據請求和發送，主要包括Client ID用來區分特定的車載ECU的客戶端，在整車系統中該值必須唯一
SessionID 主要對于Request和Response類型的通信協議的多次調用，每調用一次，sessionID增加1，在其他類型的數據通信中可以根據需要進行選擇性使用；
ProtocolVersion，表明當前的SOMEIP協議版本信息，當前為0x01；
InterfaceVersion表明服務接口主版本信息；
Message Type表明具體的通信類型；
ReturnCode: 主要用來指明通信中的相關錯誤的信息。
4 SomeIP數據域
SomeIP的數據部分，用來表明具體的傳輸數據:
對于UDP協議而言：SomeIPHeader +payload ≤1416Byte，
對于TCP而言分段傳輸下SomeIP Header +payload≤4095 而UDP TP Payload可達4G大小。
5 SomeIP的序列化
SomeIP的數據在通信的過程中都會放在對應的數據payload中，但是在數據協議中對于結構體、數據、聯合體等不同類型的數據在SomeIP傳輸中必須按照一定的規則定義成相應的二進制數據流，這個就是SomeIP的序列化操作，在數據的接收端按照相應的規則將二進制的數據流按照同樣的規則解析成與發送端一樣的實際的數據類型，比如結構體、數組等這個過程就是反序列化操作。
序列化與反序列化的應用主要在AutoSAR中滿足整個軟件架構的定義。
數據在AutoSAR的定義一般都是用PDU的形式存在的定義了一組大小可以配置的數據。
典型的應用就是CAN通信，一般一個PDU代表了一幀報文，一般8個字節或者CANFD中64個字節。
同樣在以太網通信中數據從PDUR到COM層也是基于PDU來傳輸的。
在COM層的數據也是以單個的信號進行數據傳輸的，因此在序列化過程中要在數據到COM層之前將SomeIP傳輸的復雜的數據類型通過序列化的操作解析成單個的數據信號，并按照定義的位置和大小映射到具體的PDU中特定的位置，此時在PDU上就是一個個的緊密排列的信號，而在COM層中直接對具體的信號操作便會在PDU中更新特定位置特定長度的信號。
而接收的時候，PDU中的信號會在COM層更新到特定位置特定長度的對應的信號，然后在RTE層根據數據的反序列化操作經SomeIP傳遞的數據進行整合，在APP層實現對一個結構體、數據或者單獨一個信號的操作，從而完成數據的傳輸。在AutoSAR中的傳輸示意圖如下所示:
6 SomeIP-SD
SomeIP-SD為服務發現，可以被當作SomeIP的一種特殊服務，client可以遠程調用Server提供的服務，或者訂閱Server發布的內容，
那么client是怎么知道Server提供哪些服務呢？就是通過SomeIP-SD來實現服務發現過程的。
在SomeIP傳輸過程中主要用來提供和發現有效的服務，并提交和訂閱特定的服務實例，實現SomeIP數據的傳輸。
下面是SomeIP的數據幀定義:
SomeIP SD主要是通過UDP進行數據傳輸的，對于特定的SomeIP的Header，SD有明確的定義，其中:
MessageID固定為0xFFFF8100；
ClientID 一般固定為0x0000；InterfaceVersion為0x01；Message type固定為0x02；
SessionID在初始化配置為0x0001，在沒發送一次數據后便加1；ProtocolVersion為0x01；
Flag主要包括RebootFlag和UnicastFlag，用于向全局服務發現信息發送信號，其中包括最近一次Reboot的當前狀態以及接收單播消息的能力，同時基于單播傳輸可以檢測Reboot，UnicastFlag設置為1可以接收UnicastMessage。
Reserved field為空，當前不需要考慮；
EntriesArray分為兩類，分別是Service和EventGroup。其中ServiceEntry主要是用于Find或者Offer特定的服務包括Find、Offer、StopService三種類型的操作，
EventGroup Entry主要用來提交或者訂閱特定的服務事件。
其中ServiceEntry三種服務支持多播傳輸，OfferSevice也可以單播傳輸，EventGroupEntry只支持單播傳輸。
Option類型主要是Entry的附屬信息，主要包括：
1.配置信息，可以用來配置服務的名稱等；
2.在Offer服務中定義服務的優先級；
3.聲明服務實例（offer引用，Request的目的地址，表明使用它所服務的終端地址）或者訂閱端(SubscribeEventgroup引用，Request的源地址)的IP、端口號、傳輸協議等；
4.聲明服務端發送多播協議數據傳達的終端的IP、端口號等，只能被SubscribeEventgroupAckEntry引用；
5.聲明發送SD信息的IP、端口號、傳輸協議，接收端使用該地址代替源地址等。
SD的數據通信一般分為發現服務、訂閱事件組、接收事件，
其中發現服務和訂閱事件組需要SD完成，
接收或者通知事件由SomeIP直接完成。
主要的通信流程如下所示:
7 AutoSAR中SomeIP的實現
SomeIP在AutoSAR中的實現主要包括與SD相關的配置和數據通信協議相關模塊的配置。
在SD中相互關聯的模塊主要是SoAd、SD、BSWM三個主要模塊，而SoAd下層的模塊基本與Eth的通用配置一樣，根據需要定義相關的UPD和TCP協議即可。
如果采用了像Preevision等SomeIP數據描述文件相關的工具定義好系統描述文件導入到AutoSAR工程中就可以，該部分與CAN的DBC導入原理類似，導入相應的系統描述文件會生成相應的模塊，然后根據需要修改即可。
對于SD而言，導入相應的SomeIP系統描述文件會生成相應的PDU以及跟SD相關的Service、EventGroup、Method等。
對于SD而言根據導入的文件修改相關的配置即可。而對于數據通信相關的配置，由于本人沒有做過導入現在還沒有查看具體的內容。
下面主要介紹下在沒有系統描述文件過程中自己對SomeIPSD的實現。
SD模塊配置
在SD模塊中主要定義該節點是作為Client還是Server端使用，在SD中主要的定義的配置選項如下所示：
其中General的配置主要包括了定義一些SD的主函數的周期，以及部分API的使能，在使用的時候根據需要選擇即可。
SdInstanceUnicastRxPdu定義了接收單播PDU的參考，SdInstanceMulticastRxPdu定義了接收多播的PDU、SdInstanceTxPdu定義了發送數據的PDU參考，對于定義的這三個全局的PDU需要且在SoAd模塊將該PDU與特定的Socket進行關聯，建立起PDU與特定的IP和Port之間的交互，實現Socket數據與PDU數據的關聯。
SdProvidedMethods中主要用于定義SdServerServiceActivationRef，關聯到特定的SoAdroutingGroup在Server端來控制激活或者禁用相應的Method。
SdConsumedMethods中主要用于定義 SdClientServiceActivationRef關聯到特定的SoAdroutingGroup在Client端來控制激活或者禁用相應的Method。
Config中主要定義如下所示，主要是下邊標記的一般主要考慮，用于在訂閱EventGroup沒有ACK下繼續嘗試訂閱的次數和每次的間隔。
SD 如果作為Server使用的時候，配置的參數主要如下所示，其中SdServerTimerd定義了在SD通信過程中相關的時間參數，主要包括了OfferServer的周期時間、Server的存活時間等。TCP/UDPRef在SD層要將相應的服務關聯到SoAd定義的數據Connection中，用來獲得數據通信的TCP、UPD協議，建立起LocalIP與EndPoint的綁定。
其中有兩個主要的ID需要區分，SdServerServiceHandleId用于BswM控制相關的狀態變換，而SdServerServiceInstanceId指明了特定的服務ID，用來提供相應的服務。
SD Client的定義與Server基本相似，這里就不做介紹，具體的配置內容可以參考相應的AutoSAR標準。
SD定義了相應的EventGroup，只有在服務端定義的服務可以被客戶端消費，每次客戶端使用相應的服務的時候必須進行訂閱特定的EventGroup，訂閱成功后，服務端才會提供特定的Event供客戶端使用。具體的配置參數如下，其中SdConsumedEventGroupHandleId用作BswM進行控制，而SdConsumedEventGroupId表明特定的ID，用來區分訂閱和提供不同的實例，每個SdConsumedEventGroupId包含了多個不同的Event，一旦訂閱成功，內部的Event可以通知。
對于相關的TCP/UDPRef同樣是關聯到SoAd中定義的RoutingGroup用來激活接收相應的Event，同時也會用于得到對應的IP地址和Port用于綁定Subscribe EventGroup Entry中的Endpoint。
SD EventHandler作為一個服務實體的EventGroup存在。其中SdEventHandlerEventGroupId 用來標識特定的EventGroup，也就是提供給訂閱者使用的特定事件組，而SdEventHandlerHandleId主要用于被BswM模塊進行狀態控制使用。
對于SdEventActivationRef關聯到SoAdRoutingGroup用來控制激活與否，激活后在訂閱后，才可以提供特定的Event。SdEventTriggeringRef用于觸發事件的發送。SdMulticastEventSoConRef主要將其關聯到特定的組播連接中，將特定的PDU數據與多播的Socket進行連接。
在SD中主要配置所用的Instance以及對應的EventGroup和Method。同時SD與BSWM建立了對應的控制邏輯。通過BSWM定義相關的參考，APP通過BSWM的接口可以控制SD中的Instanc、EventGroup的Request和Release。根據需要先定義Instance也就是一個特定的服務，然后定義該服務內部的EventGroup，剩下的就是根據相應的SD數據頭定義相關的參數即可。
其中在SD通信過程中有相關的狀態變換的時間參數，根據實際的需要定義即可。
在SD中主要定義三個傳輸數據用的PDU用于和SoAd模塊進行數據的交互，其中一個Tx、一個UnicastRx、一個MulticastRx，所有這些PDU都用于SD和SoAd之間的數據交互，用于SomeIPSD端數據的接收和發送，根據SD數據通信中Offer/Find/StopService以及Supscribe/Provice EventGroup等進行具體的選擇，同時在SD層要將相應的服務關聯到SoAd定義的數據Connection中，用來獲得數據通信的TCP、UPD協議，建立起LocalIP與EndPoint的綁定。
一旦發現服務，訂閱EventGroup成功后，客戶端便可以接收服務端發來的事件通知。
SoAd配置
SoAd主要將以太網傳輸的Socket與PDU進行關聯。在SomeIP的配置中主要有以下參數：
SoAdBswModules用來指定SoAd對于UL（Upper Layer）層的模塊，對于SD相關的Socket與PDU的交互UL主要是SD模塊，而對于普通的不需要SD介入的SomeIP操作只需要定義為PDUR就可以可，在PDUR層將數據傳輸到COM層，這一點與CAN基本一致。SoAdSocketConnectionGroup定義特定的連接，將本地IP、Port與遠端的IP和Port關聯在一起。每一個Connection都關聯到有特定的TCP、UDP中，一方面用來控制以太網通信中TCP、UDP連接的打開還是關閉，另一方面定義了TCP、UDP數據如何被接收和發送。SoAdSocketRoute定義了Socket的路由Socket來源，并關聯到SocketConnection中，SoAdSocketRouteDest定義了Socket UL層的PDU的目的地址，將UL層的PDU與Socket進行關聯，實現了將Socket數據解析成PDU數據，實現了數據的接收。SoAdPduRoute定義了UL層的PDU來源，SoAdPduRouteDest定義了UL層的PDU的目的地址，并且關聯到了Socket Connection和RoutingGroup 中，實現了UL層PDU與Socket的關聯，實現了PDU數據的發送。SoAdRoutingGroup包含了多個PDU，可以實現對PDU的使能和禁用，同時實現了UL層PDU到TCP/UDP Socket的數據傳遞。
SomeIP數據通信
對于SomeIP中非SD相關的數據操作，在SoAd中將接收和發送的PDU關聯到PDUR中即可，通過在PDUR中將SoAd參考的PDU通過PDUR關聯到COM層，從而實現以太網數據在COM層的解析。如果采用相關的配置工具配置SomeIP的數據通信矩陣，導入到AutoSAR工具中，根據配置手冊對SoAd以及PDUR、COM等模塊的修改，達到對SomeIP數據通信的要求即可。除了前面提到的Event和Field中的Notifier外，其它的數據通信方式都可以不需要SD。但是在使用中要注意SomeIP的序列化和反序列化操作即可。如果沒有相關的工具來配置SomeIP的數據通信矩陣也是可以實現的，但是比較麻煩，本人在測試中就模仿了CAN的數據通信，自己定義了以太網的數據PDU，定義信號在PDU的位置和長度，可以直接在APP解析以太網的數據，但是這樣問題比較多，實現起來遇到復雜的邏輯很難處理，最好定義好SomeIP的通信矩陣，然后導入到工具中使用比較好。
