引言

上一篇文章對智慧汽車軟體的範圍、軟硬體升級、SOA的內涵進行了介紹，本篇將圍繞 SOA的實現細節，重點闡述以下問題：

• SOA 基礎軟體框架
• SOA 參考實現
• SOA 實現所需相關技術

一、SOA 基礎軟體框架

上一篇中，介紹了面向服務的軟體架構設計SOA，但它只是一架構種設計思想，本身並不是一個軟體模組。工程中需要一個基礎軟體框架去實現其架構設計思想，下圖中的 SOA Framework 就是我所說的基礎軟體框架。

SOA Framework

上圖中所表示的就是一個典型的中央計算電子電氣架構，幾十個 ECU 的功能，集中到少數計算單元上，大部分 ECU 消失了，但是由於底盤域的特殊性，依然保留了部分 ECU 的功能。幾大控制器，選用的都是高效能的 SOC（畫3個只是示意），由於工作任務的不同，選用了不同的作業系統。SOA Framework 是這個分散式軟硬體系統執行的關鍵，具有以下特點：

• 它是一個作業系統中介軟體
• 執行在不同的OS 核心之上，可以跨平臺。
• 除了基於乙太網，最好還能相容傳統 AutoSAR
• 需要為上層應用提供良好的開發介面。
• 需要與多個 SOC 上的 SOA Framework 進行分散式協同。

SOA Framework 架構

SOA Framework 整體架構如上圖所示，其主要功能如下：

• 本地服務、遠端服務（執行在另外一個 SOC 上的服務），相互之間以統一的介面描述語言IDL為契約。IDL 是一種中立的語言，與 OS 以及開發語言無關。
• 通過Service Development Framework，為開發者提供服務開發的基本框架。
• Service Manager 管理本地服務，並負責與遠端的 Service Manager 進行同步。
• Policy Manager 負責控制各個服務間的訪問許可權。
• Network Manager 負責網路通訊管理，有可能會使用不同的通訊協議。
• Startup Manager 定義服務間的依賴關係與啟動順序。
• Update Manager 負責服務的更新與升級。
• OS Abstraction Layer 負責抽象各個 OS 的差異。

實際實現過程中，還需要很多其他服務作為支撐，比如持久化、加解密等，以上架構圖，只是為大家講明原理。

在這個基礎框架之上開發的服務，相互之間都是鬆耦合關係，通過我們上一篇中講的，重新定義新的組合服務和流程服務，就能產生新的軟體功能。不同晶片的差異會在作業系統層面遮蔽掉，而基礎軟體框架又遮蔽了作業系統的差異，在此架構下，即使更換新的 SOC，軟體上的改動也會很小，也為硬體可升級也提供了軟體基礎。

二、SOA 參考實現

ROS與Adaptive AutoSAR 都是遵循 SOA 架構設計思想的一種作業系統中介軟體。為什麼放在一起講，是因為他們都有可能發展成為一種適用於車載環境的分散式通訊與計算框架。

ROS（Robot Operating System）主要目標是為機器人研究和開發提供程式碼複用的支援。是一個分散式的程式（也就是“節點”）框架，這些程式被封裝在易於被分享和釋出的程式包和功能包中。

ROS 之前更多的用於學術研究，隨著這幾年人工智慧和自動駕駛的發展，在很多自動駕駛的原型系統中都能夠看到 ROS 的身影，百度 Apollo 最初也是使用了 ROS。在發展過程中，ROS原先架構設計上的缺陷也慢慢暴露出來，為了解決這些問題，2017年，採用新架構的 ROS2 問世。

ros2

ROS2 最大的改變是，取消Master中央節點，實現節點的分散式發現，釋出/訂閱，請求/響應通；底層基於DDS通訊機制，支援多作業系統，包括Linux、windows、Mac、RTOS。要把 ROS2改造的完全適合車載，還有不少工作要做，之前提到的 APEX.AI公司，就是在做這個事情。

Classic AutoSAR 是開發 ECU 的主要標準 ，相關的介紹網上很多，就不多做介紹，Adaptive AutoSAR 2017年才釋出第一個release 草案，主要用於高效能 SOC，執行在相容 POSIX的作業系統之上，其也運用了 SOA 的架構設計思想。

adaptive autosar

從Adaptive AutoSAR 和 ROS 當中，能夠看到德系與美系架構設計思想之間鮮明的差別。我的第一感受是，美系架構設計更加簡潔、靈活，追求開源。而德國人喜歡把簡單的問題複雜化，喜歡過度設計，搞很深的抽象層次，喜歡搞程式碼生成，喜歡強繫結 IDE，這可能與他們工程師思維的嚴謹性有關係，總之搞得看起來門檻特別高，相關的公司還可以賣標準，賣工具，賺的盆滿缽滿。

傳統 ECU 開發中，Classic AutoSAR 依然會佔主導地位， 德系公司是毫無疑問的主導者，但是我個人並不看好 Adaptive AutoSAR 的發展，主要有以下幾點:

• 其標準的推進事實上已經落後於行業應用。
• 在自動駕駛的發展方面，中美是主導，德國已經無法實現他在傳統汽車領域的霸主地位。
• 開源軟體，成就了人工智慧、自動駕駛相關行業的繁榮，德系軟體商這種設定高門檻，通過標準掙錢的做法，很難繼續下去，一套基礎軟體收費超過千萬，沒實力的會選擇開源，有實力的也會自己去開發，大家頂多借鑑一下其設計思想。

三、DDS 與 SOME/IP

DDS(Data Distribution Service) 與SOME/IP(Scalable service-Oriented MiddlewarE over IP)，都是基於TCP/IP 實現的一種應用層通訊協議，主要實現以下功能：

• 資料序列化
• 服務發現
• 資料的釋出訂閱機制

DDS 主要用於工業網際網路、軍工等領域，車載領域也有一些使用，比如 Nvidia 的 Drive AV 平臺，底層通訊就是基於 DDS，也是 ROS2的底層通訊協議。SOME/IP是隨著 AutoSAR 發展起來的，目前已經被納入進了 AutoSAR 的標準當中，是 Adaptive AutoSAR 的底層通訊協議。DDS 與 SOME/IP兩者功能大同小異，SOME/IP 與 AutoSAR 生態相容良好，但是 DDS 功能更強大，比如能夠實現 QoS(Quality of Service,服務質量，是網路的一種安全機制, 是用來解決網路延遲和阻塞等問題的）。

在CAN匯流排中，通訊過程是面向訊號的，傳送方週期性的釋出資訊，而不考慮接收者是否有需求。DDS與 SOME/IP則不同，收發雙方是一種訂閱/釋出機制，它是在接收方有需求的時候才傳送，優點在於匯流排上不會出現不必要的資料，從而降低負載。

DDS 與 SOME/IP的實現，是以乙太網為基礎的，為什麼要用車載乙太網，除了大家都知道的傳輸頻寬問題，其實從軟體的角度來講，乙太網最大的好處，在於它的網路模型層次比CAN要全，能夠在此基礎上定義比較複雜的應用層協議。

結語

本篇主要對SOA 軟體框架進行了介紹，對常見的技術概念，車載乙太網、SOME/IP、DDS、Adaptive AutoSAR、ROS2 等，梳理各自所處的技術層次與要解決的問題，闡述其與SOA的關係，下一篇主要聊聊一些非技術性的問題，比如行業現狀，落地中實際會碰到的困難等。

本文轉自Leo Huang​

---

譯文連載

RTPS規範-譯文連載：實時釋出訂閱協議（RTPS）DDS互操作網路協議規範-中文翻譯_001

DDS規範-譯文連載：DDS (Data Distribution Service) 資料分發服務-規範中文翻譯_001

---

相關連結

【What：什麼是DDS？ 】【Why：為什麼選擇DDS？ 】

【How：DDS如何工作？】

DDS科普：一文讀懂DDS（資料分發服務）

產品介紹：BLUE DCS分散式資料連線解決方案

產品試用：海藍雲平臺-Blue DCS

博文彙總：博文彙總（技術部落格_行業應用_規範翻譯）

---