文 趙玉龍

“軟件定義汽車”，這可能是在當(dāng)今智能網(wǎng)聯(lián)的“風(fēng)口”下，被“炒”得最火的一個(gè)概念了。

一、從“軟件定義汽車”到SOA

“軟件定義汽車”，這可能是在當(dāng)今智能網(wǎng)聯(lián)的“風(fēng)口”下，被“炒”得最火的一個(gè)概念了。

為什么這么火？

我個(gè)人覺得無外乎以下幾個(gè)原因：

首先，在以內(nèi)燃機(jī)為核心的傳統(tǒng)汽車被新能源智能汽車顛覆的趨勢(shì)下，軟件在產(chǎn)業(yè)價(jià)值鏈和商業(yè)模式中的重要性越來越大。以前車廠賣車，商業(yè)模式是“一錘子買賣”，從硬件到軟件，成本和利潤(rùn)全部都“打包”在車價(jià)里。車輛被消費(fèi)者購(gòu)買之后，車輛就不再為整車廠創(chuàng)造新的利潤(rùn)。

而現(xiàn)在呢？擁有智能網(wǎng)聯(lián)功能的汽車被賣給最終客戶以后，整車廠仍然可以通過OTA（Over-the-Air，空中下載）技術(shù)的形式對(duì)車內(nèi)軟件和固件進(jìn)行更新、升級(jí)，甚至添加新的應(yīng)用。這樣一來，只要汽車沒有報(bào)廢，消費(fèi)者就可以通過OTA源源不斷地獲得更多新的“功能體驗(yàn)”，比如ADAS系統(tǒng)從L2升級(jí)到L2.5后獲得更加成熟的自動(dòng)駕駛體驗(yàn)，電源管理系統(tǒng)（BMS）升級(jí)后獲得大幅提升的續(xù)航里程等等。

但是，天下沒有免費(fèi)的午餐！所有新的駕駛體驗(yàn)、功能體驗(yàn)和性能升級(jí)都是需要消費(fèi)者額外購(gòu)買訂閱的！這種全新的商業(yè)模式最早由特斯拉推出，如今已經(jīng)越來越多地被其他整車廠效仿和采用。

至此，整車廠的盈利模式就由以前的“一錘子買賣”變成了現(xiàn)在的“搖錢樹”模式，照此發(fā)展下去，傳統(tǒng)的4S店都有可能被慢慢取代。以前一些必須送修的故障或者返廠升級(jí)的服務(wù)（Service）工作，現(xiàn)在通過OTA就可以輕松解決了。

或許會(huì)有朋友不同意以上的說法，但是單單從進(jìn)化趨勢(shì)來講，我認(rèn)為：未來的智能網(wǎng)聯(lián)汽車，本質(zhì)上，或許真的就只是一臺(tái)裝著4個(gè)輪子的高性能計(jì)算機(jī)。

其次，隨著車聯(lián)網(wǎng)、信息娛樂系統(tǒng)以及ADAS系統(tǒng)的不斷發(fā)展壯大，車內(nèi)控制器的復(fù)雜程度將越來越高，其所屬的軟件代碼的行數(shù)將呈指數(shù)級(jí)增長(zhǎng)。相對(duì)應(yīng)的軟件研發(fā)費(fèi)用在整車研發(fā)費(fèi)用中的比例也將大幅增加。

三十年河?xùn)|，三十年河西，各大車企以及供應(yīng)商的硬件研發(fā)團(tuán)隊(duì)或?qū)⒚媾R嚴(yán)峻挑戰(zhàn)，隨之而來的是軟件團(tuán)隊(duì)的不斷發(fā)展擴(kuò)大。所有跟車內(nèi)軟件開發(fā)相關(guān)的職位（嵌入式軟件開發(fā)，Linux內(nèi)核開發(fā)，功能算法開發(fā)等等）的薪資都將水漲船高，人才市場(chǎng)上的競(jìng)爭(zhēng)不可謂不激烈。在未來高收入程序員的隊(duì)伍中或?qū)⒍喑鲆活愋氯恕囓浖こ處煟?/p>

從技術(shù)層面來分析，倘若我們把智能汽車內(nèi)的系統(tǒng)復(fù)雜程度的提高看作“因”，那么“軟件定義汽車”就是自然而然會(huì)產(chǎn)生的“果”。這個(gè)因果關(guān)系明了了，對(duì)我們這些開發(fā)人員來說，總的“指導(dǎo)思想”就算樹立好了！

現(xiàn)在新的問題來了：“軟件定義汽車”和SOA（Service Oriented Architecture，面向服務(wù)架構(gòu)）有何必然聯(lián)系？

對(duì)此，AUTOSAR（Automotive Open System Architecture，汽車開放系統(tǒng)架構(gòu)）標(biāo)準(zhǔn)給出的解釋是這樣的：

“為了支持復(fù)雜的應(yīng)用程序，同時(shí)在處理分布和計(jì)算資源分配方面提供最大的靈活性和可擴(kuò)展性，AP（Adaptive Platform，自適應(yīng)平臺(tái)） 應(yīng)遵循面向服務(wù)的體系結(jié)構(gòu) （SOA）。

SOA基于這樣一個(gè)概念：系統(tǒng)由一組服務(wù)組成，其中一個(gè)服務(wù)可以依次使用另一個(gè)服務(wù)，以及根據(jù)需要使用一個(gè)或多個(gè)服務(wù)的應(yīng)用程序。SOA 通常表現(xiàn)出系統(tǒng)間系統(tǒng)的特性，AP 也具有這種特性。例如，一個(gè)服務(wù)可能駐留在一個(gè)應(yīng)用程序運(yùn)行的本地 ECU （Electronic Control Unit，電子控制單元，又稱“行車電腦”）上，或者駐留在一個(gè)遠(yuǎn)程 ECU 上，該 ECU 也在運(yùn)行另一個(gè) AP 實(shí)例。兩種情況下的應(yīng)用程序代碼是相同的——通信基礎(chǔ)設(shè)施將處理提供透明通信產(chǎn)生的差異?？创@種架構(gòu)的另一種方式是分布式計(jì)算，通過某種形式的消息傳遞進(jìn)行通信?？偟膩碚f，所有這些都代表相同的概念。這種基于消息傳遞、基于通信的架構(gòu)也可以從快速和高帶寬通信（例如以太網(wǎng)）的興起中受益?！?/p>

這段話強(qiáng)調(diào)了SOA架構(gòu)的靈活性和可擴(kuò)展性，而這個(gè)恰恰與“軟件定義汽車”的思路不謀而合。通過采用SOA架構(gòu)，雖然可以更好地支持車控軟件的分布式部署與更新迭代，但是這在基于信號(hào)的通信架構(gòu)（Signal-oriented Communication Architecture）下是不太可能實(shí)現(xiàn)的，至少是十分困難的。

這時(shí)候有人可能會(huì)有疑問：“特斯拉就沒有使用SOA，不照樣可以通過OTA進(jìn)行迭代升級(jí)？”

其實(shí)，實(shí)現(xiàn)OTA，并不需要SOA。

別說特斯拉用的是基于Linux的操作系統(tǒng)了，就是在跑CP（Classic Platform，經(jīng)典平臺(tái)）的MCU（MicroController Unit，微控制單元）上也可以實(shí)現(xiàn)OTA，只是具體方法有所不同。

在SOA架構(gòu)下，OTA的實(shí)現(xiàn)更加方便靈活，最主要的一個(gè)優(yōu)勢(shì)是可以實(shí)現(xiàn)軟硬解耦，服務(wù)實(shí)體可以部署在任意的域控制器上，而且可以在出廠后進(jìn)行部署策略的調(diào)整。

這個(gè)優(yōu)勢(shì)衍生出SOA在汽車功能安全方面的另外一個(gè)先天優(yōu)勢(shì)——冗余。例如，對(duì)于安全性要求比較高的功能可以進(jìn)行冗余部署，比如剎車控制服務(wù)、轉(zhuǎn)向控制服務(wù)可以被同時(shí)部署在兩個(gè)域控制器上，如果一個(gè)域控制器失效，那么另外一個(gè)域控制器上的備用服務(wù)實(shí)例立刻啟動(dòng)，重新與服務(wù)使用者建立連接，以保證正常功能的運(yùn)轉(zhuǎn)，借此實(shí)現(xiàn)冗余機(jī)制。

當(dāng)然，怎么在實(shí)時(shí)運(yùn)行環(huán)境下保證這一套動(dòng)作的快速完成（兩次Service Discovery的完成，一次在開機(jī)初始化階段，一次在默認(rèn)服務(wù)實(shí)例失效時(shí)），需要在具體實(shí)現(xiàn)的過程中做更深入的研究。

結(jié)合SOA的各種特性回到本段最初的問題“軟件定義汽車”的過程和SOA有何必然聯(lián)系？

我的答案是：“不一定，但是SOA肯定是可行的解決方案之一”。

說了這么多，下面咱們模擬做一個(gè)SOA架構(gòu)設(shè)計(jì)，來看看從頭至尾都需要完成哪些具體的工作。

二、SOA的設(shè)計(jì)流程

AUTOSAR標(biāo)準(zhǔn)中定義了AP的開發(fā)流程示范，其中也包含SOA相關(guān)的開發(fā)步驟。（見圖1）

圖1 AP的開發(fā)流程示范圖

大體上，AP的開發(fā)是一個(gè)“從上至下”的流程，其中跟SOA設(shè)計(jì)相關(guān)的有以下幾個(gè)重要步驟：

（一）服務(wù)定義（Define Services）

從整車層面按照功能需求定義并劃分服務(wù)。

那么到底什么是服務(wù)呢？

IEEE對(duì)服務(wù)的定義如下：服務(wù)是一個(gè)獨(dú)立的功能單元，可以遠(yuǎn)程訪問和獨(dú)立更改或更新。

服務(wù)一般應(yīng)具有如下特性：

●代表功能單元（represents functional unit）

●是自我包含的（self-contained）

●是無狀態(tài)的 （stateless）

●使用標(biāo)準(zhǔn)接口進(jìn)行通訊（uses standardized interfaces to communicate）

●對(duì)外是一個(gè)黑盒子（black box for consumers）

●可重用性（reusability）

●可以由下層服務(wù)組成（can consist of underlying services）

此步驟實(shí)際上就是搭建了一個(gè)系統(tǒng)功能架構(gòu)。

（二）服務(wù)接口描述（Service Interface Description）

本質(zhì)上就是想辦法從功能架構(gòu)過渡到軟件技術(shù)架構(gòu)并對(duì)服務(wù)接口進(jìn)行定義。如果是同時(shí)包含CP和AP的架構(gòu)，還需要定義從CP SWC（CP Software Component）接口到服務(wù)接口的映射。

如圖2所示：不論是從哪種視角，軟件模塊之間的相互關(guān)系都需要表示出來。對(duì)于SOA來說，需要定義清楚服務(wù)之間的相互關(guān)系，也稱為服務(wù)編排（Service Orchestration）。下面我們來具體舉例說明。

圖2 定義軟件技術(shù)架構(gòu)

圖3為我們展示了一個(gè)簡(jiǎn)單的關(guān)于獲取天氣信息的例子：Test作為服務(wù)消費(fèi)者（Service Consumer）想獲取當(dāng)前位置的天氣，只需要申請(qǐng)使用服務(wù)提供者（Service Provider）WheatherControlService提供的服務(wù)。這個(gè)例子依存于兩個(gè)基礎(chǔ)的服務(wù)，一個(gè)是MapService，另一個(gè)是WeatherService。它需要通過服務(wù)接口申請(qǐng)使用這兩個(gè)服務(wù)。

圖3 獲取天氣信息的服務(wù)編排

有了上面的軟件架構(gòu)，接下來我們需要定義具體的服務(wù)接口（Service Interface），具體定義見圖4。服務(wù)接口可分為以下三種類型：

圖4 服務(wù)接口定義

方法（Method）

在服務(wù)消費(fèi)者要求下的一個(gè)由服務(wù)提供者執(zhí)行的函數(shù)。

屬性（Property）

由服務(wù)提供者管理的數(shù)據(jù)，對(duì)消費(fèi)者可見，可以通過get/set方法操作，并且可以在有變動(dòng)的情況下收到通知。

事件（Event）

表示一塊數(shù)據(jù)的更新。服務(wù)提供者決定何時(shí)發(fā)送此更新給一個(gè)或多個(gè)服務(wù)消費(fèi)者。

可以看出，這里對(duì)服務(wù)接口的定義是完全抽象的，跟通信協(xié)議無關(guān)，任何兩個(gè)服務(wù)之間都可以使用此接口進(jìn)行通信。而使用合適的工具鏈可以生成基于特定協(xié)議的接口，比如web service，AA（Adaptive Application）接口或者CP SWC接口。

有了服務(wù)及其接口的定義，接下來就可以交給軟件開發(fā)人員進(jìn)行開發(fā)了。通過軟件集成生成軟件包（Software Package），它包含可執(zhí)行文件（Executable File），執(zhí)行清單（Execution Manifest）和服務(wù)實(shí)例清單（Service Instance Manifest）。最后這個(gè)服務(wù)實(shí)例清單是通過定義與配置服務(wù)實(shí)例生成，也是我們下面要重點(diǎn)說明的一個(gè)步驟。

（三）定義與配置服務(wù)實(shí)例（Define and Configure Service Instances）

對(duì)服務(wù)進(jìn)行部署，也就是建立服務(wù)實(shí)例到機(jī)器（AP）或者ECU（CP）的映射（軟件/硬件之間的映射），此步驟會(huì)生成服務(wù)實(shí)例清單。

圖5為我們展示了映射服務(wù)接口的兩種類型：

圖5 服務(wù)實(shí)例的映射

●映射到Machine上的AP SWC

●映射到ECU上的CP SWC

其中，一個(gè)SWC對(duì)應(yīng)服務(wù)編排中的一個(gè)服務(wù)提供者或者服務(wù)消費(fèi)者。

需要注意的是，AP和CP支持的軟件接口是不一樣：AP支持服務(wù)接口，所以之前定義的服務(wù)接口可以1比1地拿過來用。而CP不支持服務(wù)接口，所以這里需要一個(gè)接口之間的映射。

圖6展示的是從抽象的接口定義到具體的軟件層面接口的映射。

圖6 軟件接口之間的映射

左邊是1比1的到AP SWC接口的映射（或者說實(shí)例化），因?yàn)锳P SWC本來就支持服務(wù)接口。

而右邊是到CP SWC接口的映射，因?yàn)镃P SWC不提供服務(wù)接口。為此需要使用CP中現(xiàn)有的接口對(duì)服務(wù)接口的三種類型（圖4）分別進(jìn)行描述：

方法（Method）

●對(duì)于帶參數(shù)的Method可以使用Client-Server接口

●對(duì)于帶自變量的Fire&Forget Method可以使用Sender-Receiver接口

●對(duì)于無參數(shù)的Fire&Forget Method可以使用Trigger接口

屬性（Property）

●對(duì)于Get/Set操作（對(duì)property的讀寫）可以使用Client-Server接口

●對(duì)于notifier（由于property改變而觸發(fā)的事件）可以使用Sender-Receiver接口

事件（Event）

觸發(fā)事件，可以使用Sender-Receiver接口

至此我們完成了從抽象的服務(wù)定義到軟件層面的推導(dǎo)。接下來是通信協(xié)議層面的設(shè)計(jì)。

圖7展示了AP下SOA架構(gòu)的整個(gè)設(shè)計(jì)流程。從服務(wù)定義到服務(wù)實(shí)例化，我們?cè)谇懊娑冀忉屵^了。最后一步就是紅框標(biāo)出的部分，以太網(wǎng)通信設(shè)計(jì)。

圖7 通信設(shè)計(jì)

以太網(wǎng)通信設(shè)計(jì)主要是對(duì)服務(wù)實(shí)例進(jìn)行相關(guān)的通信協(xié)議層面的配置，包括VLAN，Switch，Socket，SOME/IP，SD等。配置完成之后可以生成Arxml文件。

這一步的輸出是服務(wù)實(shí)例清單，也是前面提到的軟件包的一部分。

三、混合系統(tǒng)的SOA設(shè)計(jì)

前面我們著重向大家講解了純AP以及純CP系統(tǒng)的SOA設(shè)計(jì)流程，但是實(shí)際工作中，還有一種更常見的，是AP與CP共存的混合系統(tǒng)，這里我覺得有必要為大家簡(jiǎn)單說明一下此類情況下的SOA設(shè)計(jì)要點(diǎn)。

在圖8中我們可以看到：在這個(gè)拓?fù)浣Y(jié)構(gòu)中，有兩個(gè)AP Machine（綠色）和三個(gè)CP ECU（淡藍(lán)色）節(jié)點(diǎn)。而在ServerMachine上又同時(shí)存在AP，CP還有android系統(tǒng)。

圖8 混合系統(tǒng)示例

整個(gè)網(wǎng)絡(luò)拓?fù)淇梢苑殖缮舷聝蓚€(gè)Cluster：上面的Cluster使用基于信號(hào)的傳輸協(xié)議，下面的Cluster使用面向服務(wù)的傳輸協(xié)議。

這導(dǎo)致我們需要在中間這個(gè)ServerMachine上實(shí)現(xiàn)一個(gè)從信號(hào)到服務(wù)的轉(zhuǎn)換（signal to service translation）。

在圖9中，AP上的黑色模塊就是用來實(shí)現(xiàn)此轉(zhuǎn)換的。

圖9 信號(hào)到服務(wù)的轉(zhuǎn)換

轉(zhuǎn)換完成以后得到的服務(wù)實(shí)例就可以被AA（Adaptive Application）通過ara ::com API直接使用了。

圖10描述的混合系統(tǒng)的設(shè)計(jì)流程與前面的AP的設(shè)計(jì)流程大同小異。除了需要同時(shí)完成AP和CP的幾個(gè)類似的步驟之外，最主要的區(qū)別是多了中間Software Connection環(huán)節(jié)。

圖10 混合系統(tǒng)的設(shè)計(jì)流程

Software Connection實(shí)現(xiàn)了AP服務(wù)接口與CP SWC接口的映射。

圖11中按照服務(wù)接口的不同類型使用CP現(xiàn)有的各種接口進(jìn)行一個(gè)轉(zhuǎn)換。Vector的工具鏈中直接提供了一個(gè)接口轉(zhuǎn)換器（Port Adapter）來實(shí)現(xiàn)AP與CP SWC的互聯(lián)。

圖11 AP與CP的軟件連接

接下來的工作和前面一樣，我們需要把軟件模塊映射到硬件上：CP SWC到ECU上，AP SWC到Machine上。

流程設(shè)計(jì)的最后步驟，就是對(duì)通信協(xié)議層面的配置，根據(jù)通信方式的不同，生成基于信號(hào)的通信路徑或者面向服務(wù)的通信路徑。

四、結(jié)語

以上就是我所理解的SOA架構(gòu)設(shè)計(jì)的大概流程。

總體來講，SOA設(shè)計(jì)是一個(gè)從上至下的過程，可以說是比較直接（straightforward）。

從需求分析出發(fā)，導(dǎo)出服務(wù)定義，然后進(jìn)行服務(wù)編排，定義服務(wù)接口，最后是軟件到硬件的映射以及對(duì)通信協(xié)議的配置。

當(dāng)然，整個(gè)設(shè)計(jì)過程當(dāng)中有很多細(xì)節(jié)需要更深入的研究。另外，怎么保證實(shí)際的運(yùn)行效果能夠達(dá)到預(yù)期值（性能，資源消耗），或者說怎么對(duì)設(shè)計(jì)進(jìn)行驗(yàn)證（比如服務(wù)相關(guān)性的測(cè)試），都是工程師們所要面對(duì)的實(shí)際問題。（作者系“幾何四驅(qū)”專欄作者。國(guó)內(nèi)智能汽車增量部件供應(yīng)商解決方案架構(gòu)師、曾在ADAS、中央網(wǎng)關(guān)、車載計(jì)算平臺(tái)等多個(gè)業(yè)內(nèi)前沿的研發(fā)項(xiàng)目中負(fù)責(zé)軟件架構(gòu)設(shè)計(jì)。）