|
接上篇。 2）多項關(guān)鍵技術(shù)共同促進(jìn)SOA在汽車上的應(yīng)用
芯片： 在分布式EEA階段，各個ECU只連接特定的傳感器和執(zhí)行器，ECU的主要工作是提供I/O資源和網(wǎng)絡(luò)接口，并進(jìn)行實時控制。即使ECU需要運(yùn)行操作系統(tǒng)，一般也是短小精悍的實時操作系統(tǒng)。在這個階段，ECU并不需要特別強(qiáng)大的算力和巨大的存儲空間，使用普通的車規(guī)級MCU芯片即可滿足需求。上篇文章提到，當(dāng)EEA發(fā)展到第3階段時開始使用DCU對某一個功能域進(jìn)行集中控制，也是從這個階段開始，DCU對于芯片算力的需求有了大幅度的提升。以娛樂功能為例，最早就是簡單的收音機(jī)或者CD播放器，并且都是實體按鍵操作。后來用觸摸液晶屏進(jìn)行HMI顯示和操作，同時功能不斷增加（視頻播放、藍(lán)牙音樂及電話、導(dǎo)航、語音控制、倒車影像等），這使得對娛樂主機(jī)MCU的數(shù)據(jù)處理能力和軟硬件資源調(diào)度能力的要求不斷提高，不僅MCU提高到32位，還增加了GPU進(jìn)行圖像處理及運(yùn)行類似于android這樣的非實時性嵌入式操作系統(tǒng)，以便有效分配系統(tǒng)資源，對各種任務(wù)調(diào)度管理。等發(fā)展到了信息娛樂功能由智能座艙DCU集中控制階段，除了以上娛樂功能之外，DCU還將組合儀表、HUD、氛圍燈控制、DMS（駕駛員監(jiān)測系統(tǒng)）、行車視頻記錄等功能進(jìn)行集中控制。此外，智能網(wǎng)聯(lián)汽車還需要與外界進(jìn)行海量的數(shù)據(jù)交互。智能座艙DCU要求芯片的數(shù)據(jù)運(yùn)算和處理能力進(jìn)一步提升，并且需要多核異構(gòu)的系統(tǒng)級芯片SOC來滿足不同類型的控制和計算需求。在算力增加的同時，車規(guī)級芯片在功耗、安全和成本方面比消費電子要求更高。綜上所述，強(qiáng)大的車規(guī)級芯片是實現(xiàn)SOA的底層硬件基礎(chǔ)。操作系統(tǒng)（OS）： 強(qiáng)大的芯片構(gòu)成了實現(xiàn)SOA的底層硬件基礎(chǔ)，但軟件技術(shù)同樣很重要。先從離硬件最近的系統(tǒng)軟件-OS開始介紹。在最初的分布式EEA階段，很多ECU的功能簡單，不需要OS。隨著ECU功能的增加以及與外部交互接口越來越復(fù)雜，需要OS來協(xié)調(diào)管理硬件資源及進(jìn)行任務(wù)調(diào)度。汽車不同功能對OS特性的要求也不同。例如，動力域和底盤域功能直接參與車輛的行駛控制，對系統(tǒng)控制的實時性、可靠性和安全性要求非常高，一般使用CP AUTOSAR OS（兼容OSEK OS）。又例如，對于娛樂功能，更注重OS對于應(yīng)用程序的兼容性和應(yīng)用生態(tài)的豐富性，對于實時性和可靠性要求可適當(dāng)降低，因此，android這類OS越來越受歡迎。到了域控制階段，例如，在智能座艙DCU中，由于娛樂與儀表的功能安全等級不同，需要使用不同安全等級的OS，為此在DCU中引入了虛擬機(jī)管理技術(shù)(例如，AUTOSAR Hypervisor)。在虛擬機(jī)上可以同時運(yùn)行兩個或多個不同的OS，例如，娛樂功能使用Android，儀表功能使用QNX。上篇文章介紹了整車能力分層的概念（感知執(zhí)行層、通用控制層及計算層），不同層的能力要求不同，采用的OS也不同。一般來講，感知執(zhí)行層的ECU和通用控制層的ZCU不需要OS或采用實時性O(shè)S，確保對計算層下發(fā)的指令進(jìn)行快速響應(yīng)，對執(zhí)行器進(jìn)行實時控制。計算層的CCU硬件一般采用多核異構(gòu)系統(tǒng)芯片（SOC），滿足復(fù)雜的運(yùn)算和大量的數(shù)據(jù)處理需求。CCU需要通過虛擬機(jī)技術(shù)運(yùn)行多個不同類型的OS，因為不同的業(yè)務(wù)需求所適用的OS不同。例如，關(guān)鍵安全功能運(yùn)行CP AUTOSAR OS，娛樂功能運(yùn)行Linux或Android等。AUTOSAR： 在介紹了芯片和OS之后，接下來以AUTOSAR為例，介紹SOA的軟件架構(gòu)如何設(shè)計。AUTOSAR的設(shè)計理念和思路都著眼于汽車系統(tǒng)的基本軟件要求，并努力做到向前和向后的系統(tǒng)兼容性。AUTOSAR將SOA設(shè)計融入到了它的方法論中，對最終的軟件產(chǎn)品提供了標(biāo)準(zhǔn)化的服務(wù)設(shè)計和實現(xiàn)方式。當(dāng)然，SOA的實現(xiàn)方式可以多種多樣，AUTOSAR只是其中一種可選的方式，它是否能成為最適合SOA的軟件架構(gòu)還需要時間的檢驗，但僅從當(dāng)前來看，AUTOSAR是相對完整并具備可操作性的SOA軟件架構(gòu)解決方案。AUTOSAR分為Classic AUTOSAR(CP）和Adaptive AUTOSAR(AP)。AP是在CP的基礎(chǔ)上發(fā)展而來。CP一般應(yīng)用于對實時性、安全性和可靠性要求高的嵌入式ECU，AP一般應(yīng)用于需要高算力的多核異構(gòu)中央計算單元（CCU）。
圖1 CP AUTOSAR 
圖2 AP AUTOSAR CP的通信協(xié)議基于在系統(tǒng)運(yùn)行前的靜態(tài)預(yù)配置的基于信號的規(guī)范，而AP基于面向服務(wù)的通信，允許動態(tài)啟動通信。即在CP中，運(yùn)行時的服務(wù)必須在編譯時處理確定的，而AP支持運(yùn)行時服務(wù)的動態(tài)注冊。AP支持的應(yīng)用程序動態(tài)調(diào)度策略，它允許在運(yùn)行時動態(tài)部署應(yīng)用程序。SOA的軟件架構(gòu)設(shè)計離不開服務(wù)模型的設(shè)計。針對服務(wù)組件，SOA定義了服務(wù)組件的架構(gòu)模型SCA（SCA，Service Component Architecture），模型中的主要元素分為“服務(wù)接口”和“服務(wù)實現(xiàn)”兩大類。表1 AP的SCA模型描述 
AP采用經(jīng)典的代理(Proxy)-框架(Skeleton)模式來完成SCA模型的描述。這種模式將直接交互的客戶端(Client)和服務(wù)端(Server)分離，由代理負(fù)責(zé)傳遞信息來完成服務(wù)調(diào)用，客戶端和服務(wù)端不需要處理通信層詳細(xì)信息。服務(wù)組件由服務(wù)單元提供的“業(yè)務(wù)邏輯”和適配目標(biāo)系統(tǒng)環(huán)境相關(guān)的“基礎(chǔ)設(shè)施邏輯”兩部分組成。在開發(fā)過程中，這兩部分是解耦的，可同時進(jìn)行的，且軟件形態(tài)是靈活的。服務(wù)單元的邏輯可以是源碼或被封裝為SDK形式，且不關(guān)心具體的編程語言；基礎(chǔ)設(shè)施邏輯 (Interface和Message) 則以C++的形態(tài)編碼，與服務(wù)管理中間件一起確保服務(wù)的動態(tài)響應(yīng)性和服務(wù)自身的可擴(kuò)展性，其軟件形態(tài)同樣可以是源碼或SDK形式提供。在流程上方法論上，”實現(xiàn)和部署”工作主要分為服務(wù)組件接口設(shè)計，服務(wù)組件集成實現(xiàn)和安裝部署3個步驟：1、組件接口設(shè)計階段: 編寫arxml完成對服務(wù)組件SCA中“基礎(chǔ)設(shè)施邏輯”的配置開發(fā)，并經(jīng)由AP中間件供應(yīng)商提供的代碼框架和生成器(Generator)，最終得到相關(guān)的配置文件(.json)和源代碼(.cc/.cpp)；對“服務(wù)單元邏輯”，可同步基于建模工具進(jìn)行開發(fā)；2、組件集成實現(xiàn)階段: 編寫APP框架，完成“服務(wù)單元邏輯”與“基礎(chǔ)設(shè)施邏輯”的軟件集成工作；3、組件安裝部署階段: 編寫編譯和安裝腳本，完成源碼的編譯鏈接和可執(zhí)行文件(App)的安裝，同時，對APP安裝部署權(quán)限和系統(tǒng)環(huán)境做適配調(diào)整。
SOME/IP: SOME/IP (Scalable Service-Oriented MiddlewarE Over IP) ，即“運(yùn)行于IP之上的可伸縮的面向服務(wù)的中間件”。“中間件”是一種獨立的系統(tǒng)軟件或服務(wù)程序，SOA軟件架構(gòu)中的“服務(wù)”可借助中間件在不同的軟件平臺或操作系統(tǒng)之間共享資源。SOME/IP屬于應(yīng)用層協(xié)議，它提供面向服務(wù)的通訊接口。SOME/IP定義的服務(wù)接口包含方法（Methods），事件（Events），字段（Fields）和事件組（Event groups），可以支持請求/響應(yīng)模式的遠(yuǎn)程服務(wù)調(diào)用，也可以支持訂閱/發(fā)布模式的消息通知。
圖3 車載以太網(wǎng)協(xié)議
服務(wù)是SOME/IP的最核心概念，在一個服務(wù)中，定義了服務(wù)端（Server）和客戶端（Client）兩個角色：服務(wù)端提供服務(wù)，客戶端調(diào)用服務(wù)。對于同一個服務(wù)，只能存在一個服務(wù)端，但可以同時存在多個客戶端調(diào)用服務(wù)，一個服務(wù)由Method/EventField組成。
SOME/IP的訪問方式分為事件通知（Notification）、遠(yuǎn)程過程調(diào)用（Remote Procedure Call，RPC）和訪問進(jìn)程數(shù)據(jù)（Getter、Setter）3種。事件通知與傳統(tǒng)CAN通信消息類似，服務(wù)端周期性或者事件變化時向客戶端發(fā)送特定消息。遠(yuǎn)程過程調(diào)用是當(dāng)客戶端有請求的時候，向服務(wù)端發(fā)送一個請求消息，服務(wù)端根據(jù)情況返回響應(yīng)。訪問進(jìn)程數(shù)據(jù)可以使客戶向服務(wù)器端寫入（Setter）或者讀?。℅etter）數(shù)據(jù)。SOME/IP數(shù)據(jù)包括2部分，分別是Header和Data。在傳輸?shù)倪^程中可以通過TCP和UDP兩種通信數(shù)據(jù)協(xié)議進(jìn)行傳輸。SOME/IP定義的通信方式主要包括4類：1. Method: 包含了請求后有應(yīng)答的Method，和請求后沒有應(yīng)答的Method（Fire&Forget）。2. Event：當(dāng)某種事情發(fā)生后，服務(wù)端向客戶端發(fā)送的報文。3. Field：Get/Set/Notifier某種屬性或者狀態(tài)。4. EventGroup：用來進(jìn)行publish/subscribe處理Eventsand Fields的通信的邏輯組。SOME/IP定義了其服務(wù)發(fā)現(xiàn)協(xié)議SOME/IP-SD，用于動態(tài)發(fā)現(xiàn)服務(wù)的提供者地址以及檢查服務(wù)狀態(tài)是否健康。SOME/IP-SD的報文通過UDP發(fā)送，每個設(shè)備通過在局域網(wǎng)中周期性地廣播一條包含其提供的所有服務(wù)的OfferService報文來幫助其他設(shè)備完成服務(wù)發(fā)現(xiàn)（服務(wù)IP，端口等信息）。服務(wù)調(diào)用者也可以通過廣播一條FindService消息來主動查詢自己需要的服務(wù)。SOME/IP中與數(shù)據(jù)通信相關(guān)的一些術(shù)語定義如下：1. Request/Response：客戶端向服務(wù)端請求特定的報文，然后服務(wù)端將相應(yīng)的數(shù)據(jù)報文返回給客戶端。2. Fire&Forget：客戶端調(diào)用服務(wù)端Method的報文，通過請求完成Method遠(yuǎn)程調(diào)用；3. Notification：對應(yīng)Event接口類型，類似CAN報文，在特定的事件觸發(fā)下，服務(wù)端會發(fā)給客戶端一個notification報文主要包括Cyclic事件、數(shù)據(jù)Changed等；4. Publish/Subscribe：主要用于SOME/IP的SD（服務(wù)發(fā)現(xiàn)），客戶端首先訂閱相關(guān)的服務(wù)，只有訂閱成功后，才允許進(jìn)行Notification通信。5. Field：一個可被遠(yuǎn)程訪問的屬性。主要包含三種類型的數(shù)據(jù)通信Getter、Setter和Notifier。其中Getter讀取屬性值，請求報文的payload為空，響應(yīng)報文中含有當(dāng)前屬性值；Setter設(shè)置屬性值，將預(yù)設(shè)值置于請求報文的payload中，屬性的設(shè)置結(jié)果放于響應(yīng)報文中，Notifier類似于Event，Notifier在訂閱完成后，會立即發(fā)送Initial Event，通知當(dāng)前值。小結(jié)： 強(qiáng)大的車規(guī)級芯片是實現(xiàn)SOA軟件架構(gòu)的底層硬件基礎(chǔ)。 操作系統(tǒng)是離底層硬件最近的系統(tǒng)軟件， 它負(fù)責(zé)為應(yīng)用軟件協(xié)調(diào)管理硬件資源并進(jìn)行多任務(wù)的切換和調(diào)度。 AUTOSAR本質(zhì)上是一種軟件設(shè)計的方法論，它為具體如何實現(xiàn)SOA的軟件架構(gòu)提供了標(biāo)準(zhǔn)化的服務(wù)設(shè)計和實現(xiàn)方式。例如，AUTOSAR定義了為了運(yùn)行AP的應(yīng)用程序，操作系統(tǒng)需要具備POSIX標(biāo)準(zhǔn)庫接口，操作系統(tǒng)應(yīng)通過在啟動和運(yùn)行時的動態(tài)調(diào)度和通信路徑的動態(tài)配置來支持應(yīng)用程序的動態(tài)行為。 SOME/IP是一種中間層協(xié)議，是實現(xiàn)SOA的面向服務(wù)通信的一種具體的技術(shù)實現(xiàn)方式。AUTOSAR將SOME/IP也融入到了它的方法論中，例如，規(guī)定CP只能支持SOME/IP協(xié)議，而AP可以運(yùn)行SOME/IP，也支持HTTP協(xié)議，AP后續(xù)還會增加其他協(xié)議。CP僅支持靜態(tài)SOME/IP服務(wù)交互機(jī)制，而AP可以支持靜態(tài)和動態(tài)SOME/IP服務(wù)交互機(jī)制。SOME/IP在AUTOSAR中的實現(xiàn)主要包括與SD相關(guān)的配置和數(shù)據(jù)通信協(xié)議相關(guān)模塊的配置。 正如SOA的軟件架構(gòu)實現(xiàn)方式不是唯一的（AUTOSAR只是其中一種可選的方式），SOA軟件架構(gòu)下的通信協(xié)議也是多元化的，任何基于服務(wù)機(jī)制的協(xié)議均可以認(rèn)為是SOA通信協(xié)議。在汽車上，應(yīng)用比較廣泛的主要是SOME/IP、HTTP、MQTT協(xié)議，其中SOME/IP滿足車規(guī)要求，用于車內(nèi)節(jié)點之間的服務(wù)通信，而HTTP和MQTT承接于互聯(lián)網(wǎng)，多運(yùn)用于無線網(wǎng)絡(luò)，以便于車內(nèi)節(jié)點和云端交互，但也可以用于車內(nèi)有線以太網(wǎng)。 未完待續(xù)。。。
|
