來源：焉知智能汽車 作者：Jessie
對于未來智能汽車推動的汽車電子這一傳統汽車專業的轉型更新，其複雜的設計理念已經從面向使用者轉向面向開發者。即，對于汽車使用者來講隻需要輸入相關的服務需求即可。而實作該服務具體的工作則是開發者應該考慮的問題。
對于未來的智能汽車來說，其重要的ECU應該同時存在基于基于新型開發架構下的 AP Autosar 的 ECU 和基于傳統汽車軟體架構的 CP Autosar，通過車載以太網中的 SOME/IP 這類協定通信實作AP Autosar 軟體架構下的Signal2Service 、Publishe/Subscribe操作。是以，被新一代智能汽車領域所重點關注的面向服務的架構SOA （AP Autosar）通常也與 SOME/IP 常常綁定到一起進行開發。
然而事實是，随着智能汽車對域内和跨域通信要求的不斷提升，其無論是否真正需要實作面向服務架構通信，實際上對于不同ECU層之間的資料通信往往已經不僅限于CAN這類傳統的通信協定。因為無論從通信速度（CAN 一般是 512kb/s，CAN FD 能到 1MB/s，而基于 SOME/IP 的以太網能到1000 Mbps）還是通信負荷（CAN 是 8Byte，CAN FD 能到 64Byte,而 SOME/IP 能到 1500 Byte）上，CAN通信都遠不及以太網ETH協定SomeIP。
對于SomeIP來說，其通信方式為Autosar中提到的CS接口的概念，原理是在接收方有需求時才發送資訊，這樣可以規避出現過多不必要的資料。SomeIP支援廣泛的中間件功能：包括序列化、遠端過程調用（RPC）、消息傳遞、服務發現（SD）、釋出/訂閱（Pub/Sub）、UDP消息分段。是以，對于SomeiP在智能駕駛汽車中的開發一直都是近來智能駕駛汽車開發一個重點。
本文将以智能汽車中智駕域與座艙域通信執行個體（含部分代碼說明）說明整個SomeIP開發方法。
SomeIP服務架構及開發流程
結合下圖說明整個SomeIP的開發模型架構。整個SomeIP從底向上分為Native層、Framework層、應用層。其中，應用層主要包含SomeIP的應用程式及服務發現端口。Framework層主要涉及SomeIP服務封裝，Native層則是包含HAL層主要是将主要的車載控制硬體放到HAL層中，而作為底層作業系統（如Linux驅動僅完成一些簡單的資料互動）。其中從頂至下包括SomeIP管理子產品、通信矩陣子產品、通用API接口、SomeIP協定棧。前兩個子產品主要依賴通用應用接口和SomeIP協定棧子產品。
這裡需要說明的是SomeIP管理子產品是一個守護程序，用于為上層APP提供服務，同時負責維護SomeIP協定棧連接配接，SomeIP支援用戶端開發SomeIP用戶端程式，也支援服務端開發SomeIP服務端程式。同時，SomeIP的通信矩陣子產品實作SomeIP所有業務的通信矩陣開發為Plugin形式被其管理子產品所加載。SomeIP中的通信矩陣元件是基于通用API接口設計開發的，使用了Core-runtime和Someip-runtime兩個元件。而在底層SomeIP協定棧中，以堆棧API中依賴服務發現和配置子產品。
那麼對于整個與SomeIP關聯的服務開發流程而言，主要涉及如下幾個重要的步驟：
1）需求設計階段
該階段需要需求經理送出需要使用SomeIP業務的需求，并輸出至開發工程團隊。通常情況，需求經理給出的SomeIP業務需求是一組客戶級别的自然語言需求，工程團隊在拆解過程中，需要将該客戶級别的自然語言解析成開發團隊能夠識别的僞代碼模式需求。
2）需求開發階段
開發工程團隊按照需求填寫SomeIP通信矩陣文檔，判斷通信矩陣是否規範，是否需要修改。開發主要基于SomeIP的接口進行。
由于Someip協定被新一代智能汽車各類ECU中大量使用來進行車載以太網的資料通信。是以，在用someip協定進行通信時，需要按照someip定義的協定格式進行資料收發和處理，這類協定通信資料的資料結構類型千變萬化，這将會涉及到需要将大量業務資料，并按照someip定義的協定格式進行序列化和反序列化的問題。
序列化：指将資料結構或對象依據事先定義好的規則轉換成二進制串的過程；反序列化：指将二進制串依據相同規則重新建構成資料結構或對象的過程。對于SomeIP而言，均需要将結構體各元素按照順序序列化到緩沖區内，且序列化的過程通常是基于長度Length字段表示結構體中資料元素的位元組長度。
對于整個SomeIP開發來說包括Java端的代碼開發和調用JNI接口native底層服務實作。
①服務端與用戶端頂層應用服務實作代碼示例：
對于服務端與用戶端頂層開發來說，主要采用Java進行服務定義與調用。首先需要擷取someip服務端執行個體、注冊回調，啟動服務端。用戶端實作邏輯和服務端基本一緻，隻是在回調函數需要标記服務是否可用，隻有可用的服務才能被用戶端所訂閱通路。如果檢測到服務可用時，隻要用戶端有業務需求，則在需求觸發後封裝請求資料，調用request方法遠端請求到服務端進行處理。
對于SomeIP協定來說，通常需要確定其資訊傳輸安全性，這一安全性保護通常需要使用TLS這類安全手段進行防護。如果希望使用TLS傳輸，則可以在啟動伺服器後調用配置接口來對設定TLS相關參數進行設定。
②服務端與用戶端底層服務封裝實作代碼示例：
java是跨平台語言，自然而然會失去對底層的控制，于是想要調用底層方法，就必須使用native方法間接調用底層作業系統的方法(c,c++實作)。native是一個關鍵字，其修飾的方法隻說明不實作。native方法需要加載到本地棧中。
本示例中，Java與底層代碼接口native代碼實作需要依賴提前定義的函數庫libsomeipnative.so。首先，定義回調函數類Class mCallBack，用以繼承SomeIP的服務執行個體監聽類SomeIpInstanceListener，在主函數中注冊監聽，啟動服務端。并在子函數中實作對應方法。
3）需求實作驗證
需求驗證階段主要為接口定義Topic和Protobuf檔案，編寫業務代碼，調用SomeIP 應用接口實作業務功能。
topic用于綁定用戶端或者服務端的具體方法。上層應用隻需要調用topic，HAL層服務服務就可通過topic的Java Native Interface關鍵字找到對應的指針調用native服務或用戶端代理的相關接口。
Topic=Message_Type->Service_id->Instance_id->Method_id
protobuf 提供了C++、java、python語言的支援，采用了二進制位元組的序列化方式。保證java和native間序列化的資料能夠正确的反序列化。
SomeIP通信矩陣的設計與實作
SomeIP通信矩陣開發是整個SomeIP開發的核心重點，也是難點。整個工程算法結構涉及編譯配置，定義服務/客戶Base類、接口（包含共同屬性接口和回調接口），資料類型定義，插件定義，SomeIP協定棧配置檔案，日志記錄檔案，Proto檔案等。整個通信矩陣都要嘔通過編譯配置通過CommonAPI工具将field檔案生成出口檔案。
首先，通過SomeIP通信矩陣中接口描述和部署等定義生成field檔案。在應用層和SomeIP通信矩陣子產品進行資料互動中需要進行序列化和反序列化操作，是以，需要定義protobuf檔案進行矩陣接口描述和資料類型定義。
然後，根據SomeIP通信矩陣中的部署描述定義，生成topic檔案。該檔案作為惟一的，用于辨別某個服務下的某一個執行個體接口，通常是被定義為整型資料uint64。
此外，還要根據SomeIP通信矩陣中的部署描述定義，開發協定棧配置檔案，用于對SomeIP的協定棧初始化加載。
如上内容完成後，就需要以一定的通用工具如CommonAPI将接口描述檔案通用可讀源碼檔案（一般是C/C++代碼檔案）放到源碼目錄下。當然該目錄要同樣存放編譯器或編譯接口檔案，以實作對代碼的編譯。
最後，通過生成的接口檔案做對應的服務及調用開發，并對對應的服務在參考示例檔案中進行執行個體化。
如上圖所示為SomeIP通信矩陣開發中的要素分析（以診斷調查問卷為切入點進行通路分析），其中包括在矩陣開發中需要的幾種服務定義，資料類型類型定義，通信行為定義等。其子項的設定充分考慮了關于對智能駕駛域及智能座艙域原始功能的設計關聯項（如原子服務、通信資料類型、服務發現與調用等），從服務層向底層資料定義的拆解中生成代碼字段。通過服務發現、調用生成的服務内容，逐漸形成SomeIp的通行行為代碼。這個過程類似Can通信診斷的開發，對于系統工程師而言，可以從頂層分析分解調用已形成的代碼資料字段進行部分修改，實作在開發過程中嵌入更多有意義的服務内容，并擴充其診斷協定清單和通信矩陣表。