對于未來智能汽車推動的汽車電子這一傳統(tǒng)汽車專業(yè)的轉型升級，其復雜的設計理念已經從面向用戶轉向面向開發(fā)者。即，對于汽車用戶來講只需要輸入相關的服務需求即可。而實現(xiàn)該服務具體的工作則是開發(fā)者應該考慮的問題。 ?

對于未來的智能汽車來說，其重要的ECU應該同時存在基于基于新型開發(fā)架構下的 AP Autosar 的 ECU 和基于傳統(tǒng)汽車軟件架構的 CP Autosar，通過車載以太網中的 SOME/IP 這類協(xié)議通信實現(xiàn)AP Autosar 軟件框架下的Signal2Service 、Publishe/Subscribe操作。因此，被新一代智能汽車領域所重點關注的面向服務的架構SOA （AP Autosar）通常也與 SOME/IP 常常綁定到一起進行開發(fā)。 ?

然而事實是，隨著智能汽車對域內和跨域通信要求的不斷提升，其無論是否真正需要實現(xiàn)面向服務架構通信，實際上對于不同ECU層之間的數(shù)據(jù)通信往往已經不僅限于CAN這類傳統(tǒng)的通信協(xié)議。

因為無論從通信速度（CAN 一般是 512kb/s，CAN FD 能到 1MB/s，而基于 SOME/IP 的以太網能到1000 Mbps）還是通信負荷（CAN 是 8Byte，CAN FD 能到 64Byte,而 SOME/IP 能到 1500 Byte）上，CAN通信都遠不及以太網ETH協(xié)議SomeIP。 ?

對于SomeIP來說，其通信方式為Autosar中提到的CS接口的概念，原理是在接收方有需求時才發(fā)送信息，這樣可以規(guī)避出現(xiàn)過多不必要的數(shù)據(jù)。SomeIP支持廣泛的中間件功能：包括序列化、遠程過程調用（RPC）、消息傳遞、服務發(fā)現(xiàn)（SD）、發(fā)布/訂閱（Pub/Sub）、UDP消息分段。因此，對于SomeiP在智能駕駛汽車中的開發(fā)一直都是近來智能駕駛汽車開發(fā)一個重點。 ?

SomeIP服務架構及開發(fā)流程 ?

結合下圖說明整個SomeIP的開發(fā)模型架構。整個SomeIP從底向上分為Native層、Framework層、應用層。其中，應用層主要包含SomeIP的應用程序及服務發(fā)現(xiàn)端口。Framework層主要涉及SomeIP服務封裝，Native層則是包含HAL層主要是將主要的車載控制硬件放到HAL層中，而作為底層操作系統(tǒng)（如Linux驅動僅完成一些簡單的數(shù)據(jù)交互）。

其中從頂至下包括SomeIP管理模塊、通信矩陣模塊、通用API接口、SomeIP協(xié)議棧。前兩個模塊主要依賴通用應用接口和SomeIP協(xié)議棧模塊。這里需要說明的是SomeIP管理模塊是一個守護進程，用于為上層APP提供服務，同時負責維護SomeIP協(xié)議棧連接，SomeIP支持客戶端開發(fā)SomeIP 客戶端程序，也支持服務端開發(fā)SomeIP服務端程序。

同時，SomeIP的通信矩陣模塊實現(xiàn)SomeIP所有業(yè)務的通信矩陣開發(fā)為Plugin形式被其管理模塊所加載。SomeIP中的通信矩陣組件是基于通用API接口設計開發(fā)的，使用了Core-runtime和Someip-runtime兩個組件。而在底層SomeIP協(xié)議棧中，以堆棧API中依賴服務發(fā)現(xiàn)和配置模塊。 ?

那么對于整個與SomeIP關聯(lián)的服務開發(fā)流程而言，主要涉及如下幾個重要的步驟： ?

1）需求設計階段 ?

該階段需要需求經理提交需要使用SomeIP業(yè)務的需求，并輸出至開發(fā)工程團隊。通常情況，需求經理給出的SomeIP業(yè)務需求是一組客戶級別的自然語言需求，工程團隊在拆解過程中，需要將該客戶級別的自然語言解析成開發(fā)團隊能夠識別的偽代碼模式需求。 ?

2）需求開發(fā)階段 ?

開發(fā)工程團隊按照需求填寫SomeIP通信矩陣文檔，判斷通信矩陣是否規(guī)范，是否需要修改。開發(fā)主要基于SomeIP的接口進行。 ?

由于Someip協(xié)議被新一代智能汽車各類ECU中大量使用來進行車載以太網的數(shù)據(jù)通信。因此，在用someip協(xié)議進行通信時，需要按照someip定義的協(xié)議格式進行數(shù)據(jù)收發(fā)和處理，這類協(xié)議通信數(shù)據(jù)的數(shù)據(jù)結構類型千變萬化，這將會涉及到需要將大量業(yè)務數(shù)據(jù)，并按照someip定義的協(xié)議格式進行序列化和反序列化的問題。 ?

序列化：指將數(shù)據(jù)結構或對象依據(jù)事先定義好的規(guī)則轉換成二進制串的過程；反序列化：指將二進制串依據(jù)相同規(guī)則重新構建成數(shù)據(jù)結構或對象的過程。對于SomeIP而言，均需要將結構體各元素按照順序序列化到緩沖區(qū)內，且序列化的過程通常是基于長度Length字段表示結構體中數(shù)據(jù)元素的字節(jié)長度。 ?

對于整個SomeIP開發(fā)來說包括Java端的代碼開發(fā)和調用JNI接口native底層服務實現(xiàn)。 ?

①服務端與客戶端頂層應用服務實現(xiàn)代碼示例： ?

對于服務端與客戶端頂層開發(fā)來說，主要采用Java進行服務定義與調用。首先需要獲取someip服務端實例、注冊回調，啟動服務端?？蛻舳藢崿F(xiàn)邏輯和服務端基本一致，只是在回調函數(shù)需要標記服務是否可用，只有可用的服務才能被客戶端所訂閱訪問。如果檢測到服務可用時，只要客戶端有業(yè)務需求，則在需求觸發(fā)后封裝請求數(shù)據(jù)，調用request方法遠程請求到服務端進行處理。 ?

對于SomeIP協(xié)議來說，通常需要確保其信息傳輸安全性，這一安全性保護通常需要使用TLS這類安全手段進行防護。如果希望使用TLS傳輸，則可以在啟動服務器后調用配置接口來對設置TLS相關參數(shù)進行設置。 ? ?

②服務端與客戶端底層服務封裝實現(xiàn)代碼示例： ?

java是跨平臺語言，自然而然會失去對底層的控制，于是想要調用底層方法，就必須使用native方法間接調用底層操作系統(tǒng)的方法(c,c++實現(xiàn))。native是一個關鍵字，其修飾的方法只說明不實現(xiàn)。native方法需要加載到本地棧中。 ?

本示例中，Java與底層代碼接口native代碼實現(xiàn)需要依賴提前定義的函數(shù)庫libsomeipnative.so。首先，定義回調函數(shù)類Class mCallBack，用以繼承SomeIP的服務實例監(jiān)聽類SomeIpInstanceListener，在主函數(shù)中注冊監(jiān)聽，啟動服務端。并在子函數(shù)中實現(xiàn)對應方法。 ?

3）需求實現(xiàn)驗證 ?

需求驗證階段主要為接口定義Topic和Protobuf文件，編寫業(yè)務代碼，調用SomeIP 應用接口實現(xiàn)業(yè)務功能。 ?

topic用于綁定客戶端或者服務端的具體方法。上層應用只需要調用topic，HAL層服務服務就可通過topic的Java Native Interface關鍵字找到對應的指針調用native服務或客戶端代理的相關接口。 ?

Topic=Message_Type->Service_id->Instance_id->Method_id ? protobuf 提供了C++、java、python語言的支持，采用了二進制字節(jié)的序列化方式。保證java和native間序列化的數(shù)據(jù)能夠正確的反序列化。 ?

SomeIP通信矩陣的設計與實現(xiàn) ?

SomeIP通信矩陣開發(fā)是整個SomeIP開發(fā)的核心重點，也是難點。整個工程算法結構涉及編譯配置，定義服務/客戶Base類、接口（包含共同屬性接口和回調接口），數(shù)據(jù)類型定義，插件定義，SomeIP協(xié)議棧配置文件，日志記錄文件，Proto文件等。整個通信矩陣都要嘔通過編譯配置通過CommonAPI工具將field文件生成出口文件。 ?

首先，通過SomeIP通信矩陣中接口描述和部署等定義生成field文件。在應用層和SomeIP通信矩陣模塊進行數(shù)據(jù)交互中需要進行序列化和反序列化操作，因此，需要定義protobuf文件進行矩陣接口描述和數(shù)據(jù)類型定義。 ? 然后，根據(jù)SomeIP通信矩陣中的部署描述定義，生成topic文件。該文件作為惟一的，用于標識某個服務下的某一個實例接口，通常是被定義為整型數(shù)據(jù)uint64。 ?

此外，還要根據(jù)SomeIP通信矩陣中的部署描述定義，開發(fā)協(xié)議棧配置文件，用于對SomeIP的協(xié)議棧初始化加載。 ?

如上內容完成后，就需要以一定的通用工具如CommonAPI將接口描述文件通用可讀源碼文件（一般是C/C++代碼文件）放到源碼目錄下。當然該目錄要同樣存放編譯器或編譯接口文件，以實現(xiàn)對代碼的編譯。 ?

最后，通過生成的接口文件做對應的服務及調用開發(fā)，并對對應的服務在參考示例文件中進行實例化。 ?

?如上圖所示為SomeIP通信矩陣開發(fā)中的要素分析（以診斷調查問卷為切入點進行訪問分析），其中包括在矩陣開發(fā)中需要的幾種服務定義，數(shù)據(jù)類型類型定義，通信行為定義等。

其子項的設置充分考慮了關于對智能駕駛域及智能座艙域原始功能的設計關聯(lián)項（如原子服務、通信數(shù)據(jù)類型、服務發(fā)現(xiàn)與調用等），從服務層向底層數(shù)據(jù)定義的拆解中生成代碼字段。通過服務發(fā)現(xiàn)、調用生成的服務內容，逐漸形成SomeIp的通行行為代碼。

這個過程類似Can通信診斷的開發(fā)，對于系統(tǒng)工程師而言，可以從頂層分析分解調用已形成的代碼數(shù)據(jù)字段進行部分修改，實現(xiàn)在開發(fā)過程中嵌入更多有意義的服務內容，并擴充其診斷協(xié)議列表和通信矩陣表。

審核編輯：劉清