SOA通信中間件及其協議介紹

關注公眾號，點擊公眾號主頁右上角“ ··· ”，設置星標，實時關注智能汽車電子與軟件最新資訊

前言

SOA（面向服務的架構）的軟件設計原則之一是模塊化。模塊化可以提高軟件系統的可維護性和代碼重用性，并且能夠隔離故障。舉例來說，自動駕駛系統可以分解為特定的任務模塊，如數據采集、狀態估計和任務規劃等。為了完成各自的任務，這些模塊需要相互交換信息。在現代操作系統中，將單個模塊映射到獨立的軟件進程非常方便，這些進程可以位于同一計算設備上，也可以位于物理上獨立的計算設備上。這使得進程間通信成為一個深入研究的問題，因為信息交換是通過進程間的通信來實現的。

一.?通信中間件

在軟件定義汽車中，應用程序之間的跨進程或跨核通信是一個需要解決的問題。模塊化架構為開發人員提供了便利，但也引入了對通信中間件的需求。

在沒有使用通信中間件的情況下，開發人員需要自己定義數據的格式、發送方和接收方。然而，使用基于服務/數據的發布和訂閱模式（如SOME/IP和DDS），開發人員只需要明確需要什么樣的數據以及數據應該傳遞到哪里，而無需關注數據的發送方和發送方式。

以數據為中心是相對于傳統的以消息為中心而言的，其本質區別在于通信中間件知道存儲了什么數據并能夠控制如何共享這些數據。對于傳統的以消息為中心的中間件，程序員必須為發送消息編寫代碼，而對于以數據為中心的中間件，程序員只需為如何共享數據編寫代碼，然后可以直接共享數據值。

通信中間件可以采用點對點、消息隊列和發布/訂閱三種工作模式，SOME/IP和DDS都采用了發布/訂閱模式。

在發布/訂閱模型中，發布者和訂閱者通過主題進行關聯，雙方不需要知道對方在何處，也不需要同時在線。這實現了通信雙方在時間、空間和數據通信上的多維松耦合。

此外，與面向信號的CAN相比，DDS和SOME/IP都是面向服務的通信協議。兩者的區別在于面向信號的數據傳輸始終循環發送，而面向服務的通信方式不同，只有在客戶端請求或服務器通知特定訂閱者時，才在客戶端-服務器配置中交換數據。這確保了永遠不會浪費帶寬，并且僅在需要的時間和地點進行數據通信/交換。因此，面向服務的通信協議可以大大減少網絡負載，提高通信效率。

在軟件定義汽車時代，車內的所有可調用功能都被視為服務，并提供不同類型的調用接口，這些接口可以按以下方式分類：

1、API接口：提供各類函數的調用接口，使應用程序能夠調用系統內部的功能實現函數。應用程序可以通過調用相關的API接口來提供和使用功能服務。

2、文件方式：以配置文件或設備文件的形式提供系統內部的調用能力。這些文件可以通過配置自動生成，包含有效的配置信息，并且可以在運行環境中被特定的程序讀取和識別，實現特定的服務。

3、系統原生服務：操作系統和基礎類庫提供的可操作能力，包括對系統CPU和內存的監測、應用程序的監控、系統資源的劃分等。此外，還可以調用C++、boost等基礎類庫。

4、IPC接口：各種IPC機制提供系統內進程間的調用能力，包括使用套接字（socket）、共享內存等進程間通信方式，以及使用特定的跨核通信方式如IPCF。

5、協議棧接口：通過網絡協議棧提供跨平臺的調用能力，包括SOME/IP、DDS、MQTT、HTTP等網絡協議的調度服務、接口封裝和協議轉換等。

盡管在互聯網領域中SOA（面向服務的架構）已經被應用了很長時間，但在汽車行業中，它算是相對較新的概念。在Adaptive AutoSAR框架中，通信管理模塊包括進程間通信和網絡協議棧。

鑒于汽車應用場景和通信需求的特殊性，許多互聯網的SOA技術并不能直接應用于汽車領域。一般來說，SOA通信中間件系統的各個層面需要滿足以下要求：

1、本地服務和遠程服務之間的通信應該使用統一的接口描述語言（IDL）定義的文件作為契約。IDL是一種中立的接口描述語言，與具體的操作系統和編程語言無關。

2、SOA框架的底層核心功能應具備以下特點：服務發現、消息序列化、內部事件/消息處理和傳輸功能。應用程序、服務和操作系統之間可以通過標準的通信協議或服務接口相互通信或訪問，特別是要滿足傳感數據的大數據吞吐傳輸需求。必須支持典型的車內通信協議，如SOME/IP協議、DDS規范等。服務發現功能應具備訪問控制功能，以防止未經授權的用戶進行竊聽和侵入；傳輸功能應具備數據加密和簽名等功能，以確保通信數據的安全性。

在未來，汽車將與更多的基礎設施進行連接，為了實現與它們的連接，將需要使用不同的通信協議。

汽車SOA 通信架構

HTTP、MQTT、SOME/IP和DDS等協議都用于實現SOA架構中的通信，只是在不同的場景下承擔不同的責任。例如，SOME/IP協議用于車內節點之間的服務通信，而HTTP和MQTT用于與互聯網模塊進行通信。盡管它們在實現機制上有些許差異，但它們可以相互切換使用。

MQTT、DDS、AMQP、REST和CoAP等協議都已被廣泛應用，并且每種協議都至少有10種不同的代碼實現。它們都宣稱支持實時的發布/訂閱物聯網協議。然而，在具體的系統架構設計中，需要考慮實際場景中的通信需求，并選擇適合的協議。各種協議的特點如表所示。

二、SOME/IP 介紹

2011年，寶馬設計并提出了SOME/IP（Scalable Service-oriented Middleware over IP）協議。SOME/IP采用服務器-客戶端的服務通信模式，并且具備高度可擴展性。SOME/IP協議是一種應用層協議，運行在TCP/UDP傳輸協議之上（車載以太網第四層以上）。它作為以太網通信的中間件，實現應用層與IP層之間的數據交互，使其不依賴于操作系統，并且兼容AUTOSAR和非AUTOSAR平臺。因此，SOME/IP可以獨立于硬件平臺、操作系統和編程語言。

SOME/IP 協議架構

SOME/IP具備滿足車用需求的特性，主要包括以下幾個方面：基于服務的通信方式，占用空間小，與AUTOSAR兼容（其他中間件不具備兼容性），可伸縮性（適用于小型和大型平臺），以及兼容性（可適用于車輛使用的各種操作系統，如AUTOSAR、OSEK、QNX和Linux）。

SOME/IP支持AUTOSAR CP、AUTOSAR AP以及非AUTOSAR平臺之間的通信交互。寶馬設計SOME/IP協議后，它被AUTOSAR納入正式標準，并隨著CP規范的發布而被廣泛應用于車載以太網，因此可以說是AUTOSAR CP推動了SOME/IP的廣泛使用。

在AUTOSAR架構中，SOME/IP-SD模塊位于AUTOSAR BSW Mode Manager模塊（BswM）和AUTOSAR Socket Adaptor模塊（SoAd）之間。BswM模塊提供了通用模式請求和服務請求之間的連接，而SoAd模塊處理以太網堆棧和SD模塊之間的服務請求。通過配置SoAd中的Socket Connection表，可以接收其他ECU的SD模塊發送的單播和多播報文。

借助SOME/IP協議的高度平臺擴展性，可以實現不同平臺之間的數據交互，而統一的SOME/IP通信機制是不同平臺通信的前提。為了在不同軟件平臺上運行SOME/IP，實現整車以太網上的SOA架構通信機制，AP規范中也同步引入了SOME/IP，因此在AUTOSAR系統中，CP和AP之間實現SOME/IP通信相對容易。

為了促進非AUTOSAR軟件平臺與車內CP和APECU之間的交互，GENIVI系統同樣開發了一套開源的vSOME/IP軟件源碼，以便與CP/AP進行交互。然而，由于vSOME/IP是開源的，性能可能略有差異，因此需要統一的規范進行約束，以進行深度的二次開發。目前，全球最大的商用SOME/IP產品供應商是Vector，而開源版的vSOME/IP由GENIVI協會維護。

三、DDS 介紹

DDS（Data Distribution Service）是由OMG（Object Management Group）發布的分布式通信規范。OMG成立于1989年，是一個國際性、開放性、非營利性的技術標準聯盟，由供應商、終端用戶、學術機構和政府機構推動。OMG工作組致力于制定企業集成標準和開發可為數千個垂直行業提供現實價值的技術標準，其中包括統一建模語言SYSML、UML，以及中間件標準CORBA、DDS等。

DDS最早應用于美國海軍系統，用于解決在軍艦系統復雜網絡環境中進行大量軟件升級時的兼容性問題。隨著DDS被ROS2和AUTOSAR引入，目前它已經廣泛應用于航空、航天、船舶、國防、金融、通信、汽車等領域。

DDS的特點：

1、數據中心（Data Centricity）

來源：汽車ECU開發

關注公眾號，點擊公眾號主頁右上角“ ··· ”，設置星標，實時關注智能汽車電子與軟件最新資訊