上一篇文章對智能汽車軟件的范圍、軟硬件升級、SOA的內涵進行了介紹，本篇將圍繞 SOA的實現(xiàn)細節(jié)。

重點闡述以下問題：SOA 基礎軟件框架SOA 參考實現(xiàn)SOA 實現(xiàn)所需相關技術

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

上圖中所表示的就是一個典型的中央計算電子電氣架構，幾十個 ECU 的功能，集中到少數(shù)計算單元上，大部分 ECU 消失了，但是由于底盤域的特殊性，依然保留了部分 ECU 的功能。幾大控制器，選用的都是高性能的 SOC（畫3個只是示意），由于工作任務的不同，選用了不同的操作系統(tǒng)。SOA Framework 是這個分布式軟硬件系統(tǒng)運行的關鍵，具有以下特點：它是一個操作系統(tǒng)中間件運行在不同的OS 內核之上，可以跨平臺。除了基于以太網(wǎng)，最好還能兼容傳統(tǒng) AutoSAR需要為上層應用提供良好的開發(fā)接口。需要與多個 SOC 上的 SOA Framework 進行分布式協(xié)同。

SOA Framework 架構．png

SOA Framework 整體架構如上圖所示，其主要功能如下：本地服務、遠程服務（運行在另外一個 SOC 上的服務），相互之間以統(tǒng)一的接口描述語言IDL為契約。IDL 是一種中立的語言，與 OS 以及開發(fā)語言無關。通過Service Development Framework，為開發(fā)者提供服務開發(fā)的基本框架。Service Manager 管理本地服務，并負責與遠端的 Service Manager 進行同步。Policy Manager 負責控制各個服務間的訪問權限。Network Manager 負責網(wǎng)絡通信管理，有可能會使用不同的通信協(xié)議。Startup Manager 定義服務間的依賴關系與啟動順序。Update Manager 負責服務的更新與升級。OS Abstraction Layer 負責抽象各個 OS 的差異。

實際實現(xiàn)過程中，還需要很多其他服務作為支撐，比如持久化、加解密等，以上架構圖，只是為大家講明原理。 在這個基礎框架之上開發(fā)的服務，相互之間都是松耦合關系，通過我們上一篇中講的，重新定義新的組合服務和流程服務，就能產生新的軟件功能。不同芯片的差異會在操作系統(tǒng)層面屏蔽掉，而基礎軟件框架又屏蔽了操作系統(tǒng)的差異，在此架構下，即使更換新的 SOC，軟件上的改動也會很小，也為硬件可升級也提供了軟件基礎。

二、SOA 參考實現(xiàn)

ROS與Adaptive AutoSAR 都是遵循 SOA 架構設計思想的一種操作系統(tǒng)中間件。為什么放在一起講，是因為他們都有可能發(fā)展成為一種適用于車載環(huán)境的分布式通信與計算框架。
ROS（Robot Operating System）主要目標是為機器人研究和開發(fā)提供代碼復用的支持。是一個分布式的進程（也就是“節(jié)點”）框架，這些進程被封裝在易于被分享和發(fā)布的程序包和功能包中。
ROS 之前更多的用于學術研究，隨著這幾年人工智能和自動駕駛的發(fā)展，在很多自動駕駛的原型系統(tǒng)中都能夠看到 ROS 的身影，百度 Apollo 最初也是使用了 ROS。在發(fā)展過程中，ROS原先架構設計上的缺陷也慢慢暴露出來，為了解決這些問題，2017年，采用新架構的 ROS2 問世。

ROS2 最大的改變是，取消Master中央節(jié)點，實現(xiàn)節(jié)點的分布式發(fā)現(xiàn)，發(fā)布／訂閱，請求／響應通；底層基于DDS通信機制，支持多操作系統(tǒng)，包括Linux、windows、Mac、RTOS。要把 ROS2改造的完全適合車載，還有不少工作要做，之前提到的 APEX．AI公司，就是在做這個事情。
Classic AutoSAR 是開發(fā) ECU 的主要標準 ，相關的介紹網(wǎng)上很多，就不多做介紹，Adaptive AutoSAR  2017年才發(fā)布第一個release 草案，主要用于高性能 SOC，運行在兼容 POSIX的操作系統(tǒng)之上，其也運用了 SOA 的架構設計思想。

adaptive autosar．png

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

傳統(tǒng) ECU 開發(fā)中，Classic AutoSAR 依然會占主導地位， 德系公司是毫無疑問的主導者，但是我個人并不看好 Adaptive AutoSAR 的發(fā)展，主要有以下幾點：其標準的推進事實上已經落后于行業(yè)應用。在自動駕駛的發(fā)展方面，中美是主導，德國已經無法實現(xiàn)他在傳統(tǒng)汽車領域的霸主地位。開源軟件，成就了人工智能、自動駕駛相關行業(yè)的繁榮，德系軟件商這種設置高門檻，通過標準掙錢的做法，很難繼續(xù)下去，一套基礎軟件收費超過千萬，沒實力的會選擇開源，有實力的也會自己去開發(fā)，大家頂多借鑒一下其設計思想。

三、DDS 與 SOME／IP
DDS（Data Distribution Service） 與SOME／IP（Scalable service－Oriented MiddlewarE over IP），都是基于TCP／IP 實現(xiàn)的一種應用層通信協(xié)議，主要實現(xiàn)以下功能：數(shù)據(jù)序列化服務發(fā)現(xiàn)數(shù)據(jù)的發(fā)布訂閱機制

DDS 主要用于工業(yè)互聯(lián)網(wǎng)、軍工等領域，車載領域也有一些使用，比如 Nvidia 的 Drive AV 平臺，底層通信就是基于 DDS，也是 ROS2的底層通信協(xié)議。SOME／IP是隨著 AutoSAR 發(fā)展起來的，目前已經被納入進了 AutoSAR 的標準當中，是 Adaptive AutoSAR 的底層通信協(xié)議。DDS 與 SOME／IP兩者功能大同小異，SOME／IP 與 AutoSAR 生態(tài)兼容良好，但是 DDS 功能更強大，比如能夠實現(xiàn) QoS（Quality of Service，服務質量，是網(wǎng)絡的一種安全機制， 是用來解決網(wǎng)絡延遲和阻塞等問題的）。

在CAN總線中，通信過程是面向信號的，發(fā)送方周期性的發(fā)布信息，而不考慮接收者是否有需求。DDS與 SOME／IP則不同，收發(fā)雙方是一種訂閱／發(fā)布機制，它是在接收方有需求的時候才發(fā)送，優(yōu)點在于總線上不會出現(xiàn)不必要的數(shù)據(jù)，從而降低負載。
DDS 與 SOME／IP的實現(xiàn)，是以以太網(wǎng)為基礎的，為什么要用車載以太網(wǎng)，除了大家都知道的傳輸帶寬問題，其實從軟件的角度來講，以太網(wǎng)最大的好處，在于它的網(wǎng)絡模型層次比CAN要全，能夠在此基礎上定義比較復雜的應用層協(xié)議。

結語

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