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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

審核編輯：劉清