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

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

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

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

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

SomeIP服務(wù)架構(gòu)及開發(fā)流程 ?

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

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

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

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

1）需求設(shè)計階段 ?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

topic用于綁定客戶端或者服務(wù)端的具體方法。上層應(yīng)用只需要調(diào)用topic，HAL層服務(wù)服務(wù)就可通過topic的Java Native Interface關(guān)鍵字找到對應(yīng)的指針調(diào)用native服務(wù)或客戶端代理的相關(guān)接口。 ?

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

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

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

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

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

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

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

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

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

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

審核編輯：劉清