什么是SOA
SOA(面向服務(wù)的架構(gòu))可以理解為一種架構(gòu)設(shè)計方法,它是將一個系統(tǒng)所具有的能力抽象成可調(diào)用的并具有標(biāo)準(zhǔn)接口的服務(wù),從而可以通過調(diào)用服務(wù)或者調(diào)用多個服務(wù)的組合來滿足系統(tǒng)的業(yè)務(wù)需求。
SOA并不是某一種具體的技術(shù)實現(xiàn),而是一種系統(tǒng)架構(gòu)的設(shè)計思想。SOA的提出是為了解決隨著面臨的問題越來越復(fù)雜,軟件系統(tǒng)變得難以維護、難以擴展、容易出錯等問題。
SOA也是一種軟件架構(gòu)設(shè)計方案,它用以組織和運用分散在系統(tǒng)不同部分的能力(capabilities)。能力與運用能力,概念上有所差別。需求與能力可以獨立于 SOA 而存在。
在SOA架構(gòu)中,服務(wù)是更高效地利用現(xiàn)有能力滿足需求的一種手段,這也是SOA的意義。
為什么汽車上要應(yīng)用SOA
SOA在IT領(lǐng)域已經(jīng)存在很久,究竟是什么原因促使SOA應(yīng)用在汽車上呢?
對于任何一個系統(tǒng)來說,外部對系統(tǒng)的“需求”和系統(tǒng)本身具備的“能力”是決定如何設(shè)計系統(tǒng)的2個最關(guān)鍵的因素。
能力越強則可以滿足更多的需求,但能力越強也意味著需要耗費更多的資源。資源從來都是有限和稀缺的,但需求卻不斷地增加和快速地變化。有限的資源和能力與無限的需求之間的矛盾是系統(tǒng)設(shè)計面臨的最大挑戰(zhàn)。
對于任何一個盈利性組織來講,在設(shè)計開發(fā)汽車電氣系統(tǒng)時,如何用相同的能力滿足更多的需求,如何用更少的能力滿足相同的需求,如何用現(xiàn)有的能力更快速地、更好地滿足不斷增長的復(fù)雜多變的需求,這是促使SOA設(shè)計思想和設(shè)計方法應(yīng)用在汽車上的最本質(zhì)原因。
如何實現(xiàn)SOA
汽車EEA的發(fā)展使SOA具備了初步的應(yīng)用條件
汽車EEA從分布式逐步向集中式發(fā)展。從整車廠的角度,這種趨勢背后的最大驅(qū)動力也是為了更好地解決能力與需求的結(jié)合和匹配問題。
所謂分布式EEA,可以理解為汽車電氣系統(tǒng)的軟硬件資源和能力是分散的,分散在不同的供應(yīng)商手中。ECU的軟硬件開發(fā)全部由供應(yīng)商完成,整車廠主要負(fù)責(zé)提出設(shè)計需求和測試驗證。
分布式EEA導(dǎo)致的ECU軟硬件資源和能力的浪費是顯而易見的。不同的供應(yīng)商負(fù)責(zé)不同的ECU開發(fā),整車數(shù)十個ECU分別負(fù)責(zé)實現(xiàn)特定的軟硬件功能,然后通過硬線信號或者網(wǎng)絡(luò)信號進行交互,這種信息交互方式也被稱為面向信號的通信。
受限于研發(fā)周期、項目資源、技術(shù)發(fā)展(芯片算力、操作系統(tǒng)、軟件架構(gòu)等)、供應(yīng)商能力以及整車廠能力等眾多因素,由分布式EEA走向集中式EEA必然是一個漸進的過程,一般會經(jīng)歷以下幾個階段:
1)在局部子系統(tǒng)做一些簡單的物理集成。例如,在三電系統(tǒng),將DCDC和OBC整合為一個ECU,外殼和接插件可以共用(資源的利用率得到提升),但內(nèi)部還是兩個獨立的控制器,分別具有各自的PCB和軟硬件資源。
2)在局部子系統(tǒng)做一些功能集成。例如,在車身控制系統(tǒng),將BCM、PEPS、TPMS實現(xiàn)的功能通過一個ECU來實現(xiàn)。外殼、接插件、PCB可以共用,軟硬件資源也可以部分共享,相對于物理集成,功能集成進一步提高了資源的利用率。
3)將某個功能域的大部分或全部功能通過域控制單元進行集中控制。比較典型的功能域劃分方式將整車分為5個域:動力域、底盤域、車身控制域、智能座艙域和智能駕駛域(包括ADAS和AD)。
4)功能域的進一步融合,整車由幾個核心計算單元進行集中控制。例如,特斯拉的整車電氣系統(tǒng)主要由autopilot+MCU(智能駕駛+多媒體)、左車身控制和右車身控制三個核心計算單元進行集中控制。華為的智能駕駛、智能座艙和整車控制器三個核心計算單元。
5)終極EEA形態(tài):整車電氣系統(tǒng)由一個中央計算單元進行集中控制。
目前大部分整車廠量產(chǎn)車型的EEA處于第1和第2個階段,少部分處于第3階段或第4階段。前2個階段從本質(zhì)上講還是處于分布式EEA階段,因為無論是物理集成還是功能集成,都僅僅是在局部功能實現(xiàn)上減少ECU的數(shù)量,實現(xiàn)功能所需的軟硬件資源還是以ECU為核心進行設(shè)計。
從第3階段開始,EEA才算是進入了集中式控制階段。分布式與集中式控制的本質(zhì)區(qū)別在于,分布式階段的整車功能是圍繞一個個ECU作為主體進行設(shè)計的,而集中式階段則需要從子系統(tǒng)甚至整車的軟硬件資源所具備的不同能力的角度,對功能實現(xiàn)進行分層設(shè)計,核心思想是不同的層面具備不同的能力,其主要目的是軟硬件資源和能力的解耦。
可以粗略地將整車軟硬件資源所具備的能力分為3類:計算能力、通用控制能力和感知執(zhí)行能力,并將這3種能力分別對應(yīng)到計算層、通用控制層和感知執(zhí)行層。
在第3階段,將某個功能域的計算能力集中到DCU(域控制單元)中,通用控制和感知執(zhí)行能力由各個功能域中的下層ECU實現(xiàn)。
在第4和第5階段,將整車的計算能力集中到幾個核心計算單元或者唯一的中央計算單元中。通用控制能力則分布在整車不同區(qū)域的ZCU(區(qū)域控制單元)中,從某個區(qū)域的范圍看,通用控制能力則集中在特定區(qū)域的某個ZCU中。感知執(zhí)行能力只有特定類型的傳感器和執(zhí)行器才具備,只能分布于整車各個傳感器和執(zhí)行器中。
在SOA架構(gòu)中,服務(wù)是更高效地利用現(xiàn)有能力滿足需求的一種手段,而汽車電氣系統(tǒng)的所具備的最基礎(chǔ)的能力是由所具備的傳感器和執(zhí)行器的類型和數(shù)量決定的,也可以理解為由最底層的硬件資源所決定的,因此在汽車上應(yīng)用SOA的一個重要前提是實現(xiàn)業(yè)務(wù)需求與硬件資源的解耦。
當(dāng)EEA發(fā)展到第3階段時,即引入DCU集中控制某個功能域時,汽車上開始具備了實現(xiàn)SOA的條件。
DCU的芯片算力、操作系統(tǒng)以及軟件架構(gòu)可以滿足業(yè)務(wù)需求與硬件資源解耦的需求,即有能力通過一套基礎(chǔ)軟件框架去實現(xiàn)SOA的設(shè)計思想,從而將底層的硬件資源具備的能力抽象為一種服務(wù)供外部使用,并能夠支持一系列的服務(wù)管理功能(服務(wù)定位、服務(wù)發(fā)現(xiàn),服務(wù)調(diào)用等)。此外,DCU必須支持基于IP協(xié)議的車載以太網(wǎng)通信,因為目前支持SOA的主流中間件,例如,SOME/IP等,都是基于IP協(xié)議通信的。
多項關(guān)鍵技術(shù)共同促進SOA在汽車上的應(yīng)用
芯片:
在分布式EEA階段,各個ECU只連接特定的傳感器和執(zhí)行器,ECU的主要工作是提供I/O資源和網(wǎng)絡(luò)接口,并進行實時控制。即使ECU需要運行操作系統(tǒng),一般也是短小精悍的實時操作系統(tǒng)。在這個階段,ECU并不需要特別強大的算力和巨大的存儲空間,使用普通的車規(guī)級MCU芯片即可滿足需求。
當(dāng)EEA發(fā)展到第3階段時開始使用DCU對某一個功能域進行集中控制,也是從這個階段開始,DCU對于芯片算力的需求有了大幅度的提升。
以娛樂功能為例,最早就是簡單的收音機或者CD播放器,并且都是實體按鍵操作。后來用觸摸液晶屏進行HMI顯示和操作,同時功能不斷增加(視頻播放、藍牙音樂及電話、導(dǎo)航、語音控制、倒車影像等),這使得對娛樂主機MCU的數(shù)據(jù)處理能力和軟硬件資源調(diào)度能力的要求不斷提高,不僅MCU提高到32位,還增加了GPU進行圖像處理及運行類似于android這樣的非實時性嵌入式操作系統(tǒng),以便有效分配系統(tǒng)資源,對各種任務(wù)調(diào)度管理。
等發(fā)展到了信息娛樂功能由智能座艙DCU集中控制階段,除了以上娛樂功能之外,DCU還將組合儀表、HUD、氛圍燈控制、DMS(駕駛員監(jiān)測系統(tǒng))、行車視頻記錄等功能進行集中控制。此外,智能網(wǎng)聯(lián)汽車還需要與外界進行海量的數(shù)據(jù)交互。
智能座艙DCU要求芯片的數(shù)據(jù)運算和處理能力進一步提升,并且需要多核異構(gòu)的系統(tǒng)級芯片SOC來滿足不同類型的控制和計算需求。在算力增加的同時,車規(guī)級芯片在功耗、安全和成本方面比消費電子要求更高。
綜上所述,強大的車規(guī)級芯片是實現(xiàn)SOA的底層硬件基礎(chǔ)。
操作系統(tǒng)(OS):
強大的芯片構(gòu)成了實現(xiàn)SOA的底層硬件基礎(chǔ),但軟件技術(shù)同樣很重要。先從離硬件最近的系統(tǒng)軟件-OS開始介紹。
在最初的分布式EEA階段,很多ECU的功能簡單,不需要OS。隨著ECU功能的增加以及與外部交互接口越來越復(fù)雜,需要OS來協(xié)調(diào)管理硬件資源及進行任務(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中引入了虛擬機管理技術(shù)(例如,AUTOSAR Hypervisor)。在虛擬機上可以同時運行兩個或多個不同的OS,例如,娛樂功能使用Android,儀表功能使用QNX。
感知執(zhí)行層、通用控制層及計算層,不同層的能力要求不同,采用的OS也不同。一般來講,感知執(zhí)行層的ECU和通用控制層的ZCU不需要OS或采用實時性O(shè)S,確保對計算層下發(fā)的指令進行快速響應(yīng),對執(zhí)行器進行實時控制。計算層的CCU硬件一般采用多核異構(gòu)系統(tǒng)芯片(SOC),滿足復(fù)雜的運算和大量的數(shù)據(jù)處理需求。CCU需要通過虛擬機技術(shù)運行多個不同類型的OS,因為不同的業(yè)務(wù)需求所適用的OS不同。例如,關(guān)鍵安全功能運行CP AUTOSAR OS,娛樂功能運行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)運行前的靜態(tài)預(yù)配置的基于信號的規(guī)范,而AP基于面向服務(wù)的通信,允許動態(tài)啟動通信。即在CP中,運行時的服務(wù)必須在編譯時處理確定的,而AP支持運行時服務(wù)的動態(tài)注冊。AP支持的應(yīng)用程序動態(tài)調(diào)度策略,它允許在運行時動態(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ù)端不需要處理通信層詳細信息。
服務(wù)組件由服務(wù)單元提供的“業(yè)務(wù)邏輯”和適配目標(biāo)系統(tǒng)環(huán)境相關(guān)的“基礎(chǔ)設(shè)施邏輯”兩部分組成。在開發(fā)過程中,這兩部分是解耦的,可同時進行的,且軟件形態(tài)是靈活的。
服務(wù)單元的邏輯可以是源碼或被封裝為SDK形式,且不關(guān)心具體的編程語言;基礎(chǔ)設(shè)施邏輯 (Interface和Message) 則以C++的形態(tài)編碼,與服務(wù)管理中間件一起確保服務(wù)的動態(tài)響應(yīng)性和服務(wù)自身的可擴展性,其軟件形態(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ù)單元邏輯”,可同步基于建模工具進行開發(fā);
2、組件集成實現(xiàn)階段:編寫APP框架,完成“服務(wù)單元邏輯”與“基礎(chǔ)設(shè)施邏輯”的軟件集成工作;
3、組件安裝部署階段:編寫編譯和安裝腳本,完成源碼的編譯鏈接和可執(zhí)行文件(App)的安裝,同時,對APP安裝部署權(quán)限和系統(tǒng)環(huán)境做適配調(diào)整。
表2 服務(wù)組件的設(shè)計和部署
SOME/IP:
SOME/IP (Scalable Service-Oriented MiddlewarE Over IP),即“運行于IP之上的可伸縮的面向服務(wù)的中間件”?!爸虚g件”是一種獨立的系統(tǒng)軟件或服務(wù)程序,SOA軟件架構(gòu)中的“服務(wù)”可借助中間件在不同的軟件平臺或操作系統(tǒng)之間共享資源。
SOME/IP屬于應(yīng)用層協(xié)議,它提供面向服務(wù)的通訊接口。SOME/IP定義的服務(wù)接口包含方法(Methods),事件(Events),字段(Fields)和事件組(Eventgroups),可以支持請求/響應(yīng)模式的遠程服務(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)、遠程過程調(diào)用(Remote Procedure Call,RPC)和訪問進程數(shù)據(jù)(Getter、Setter)3種。事件通知與傳統(tǒng)CAN通信消息類似,服務(wù)端周期性或者事件變化時向客戶端發(fā)送特定消息。遠程過程調(diào)用是當(dāng)客戶端有請求的時候,向服務(wù)端發(fā)送一個請求消息,服務(wù)端根據(jù)情況返回響應(yīng)。訪問進程數(shù)據(jù)可以使客戶向服務(wù)器端寫入(Setter)或者讀取(Getter)數(shù)據(jù)。
SOME/IP數(shù)據(jù)包括2部分,分別是Header和Data。在傳輸?shù)倪^程中可以通過TCP和UDP兩種通信數(shù)據(jù)協(xié)議進行傳輸。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:用來進行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遠程調(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ù),只有訂閱成功后,才允許進行Notification通信。
5. Field:一個可被遠程訪問的屬性。主要包含三種類型的數(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)前值。
強大的車規(guī)級芯片是實現(xiàn)SOA軟件架構(gòu)的底層硬件基礎(chǔ)。
操作系統(tǒng)是離底層硬件最近的系統(tǒng)軟件, 它負(fù)責(zé)為應(yīng)用軟件協(xié)調(diào)管理硬件資源并進行多任務(wù)的切換和調(diào)度。
AUTOSAR本質(zhì)上是一種軟件設(shè)計的方法論,它為具體如何實現(xiàn)SOA的軟件架構(gòu)提供了標(biāo)準(zhǔn)化的服務(wù)設(shè)計和實現(xiàn)方式。例如,AUTOSAR定義了為了運行AP的應(yīng)用程序,操作系統(tǒng)需要具備POSIX標(biāo)準(zhǔn)庫接口,操作系統(tǒng)應(yīng)通過在啟動和運行時的動態(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可以運行SOME/IP,也支持HTTP協(xié)議,AP后續(xù)還會增加其他協(xié)議。CP僅支持靜態(tài)SOME/IP服務(wù)交互機制,而AP可以支持靜態(tài)和動態(tài)SOME/IP服務(wù)交互機制。SOME/IP在AUTOSAR中的實現(xiàn)主要包括與SD相關(guān)的配置和數(shù)據(jù)通信協(xié)議相關(guān)模塊的配置。
正如SOA的軟件架構(gòu)實現(xiàn)方式不是唯一的(AUTOSAR只是其中一種可選的方式),SOA軟件架構(gòu)下的通信協(xié)議也是多元化的,任何基于服務(wù)機制的協(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),多運用于無線網(wǎng)絡(luò),以便于車內(nèi)節(jié)點和云端交互,但也可以用于車內(nèi)有線以太網(wǎng)。
技術(shù)是手段,不是目的
在汽車產(chǎn)業(yè)重構(gòu)期,諸多的新技術(shù)不斷涌現(xiàn),整車廠的核心能力到底是什么?
不管是對于企業(yè)還是個人,能力和資源都是有限的,必須集中有限的資源做自己應(yīng)該做的事。
整車廠之所以為整車廠,就是因為它必須對最終生產(chǎn)出來的車輛負(fù)責(zé),它必須對客戶的用車體驗負(fù)責(zé)。在軟件定義汽車的時代,不斷提升客戶的用車體驗也是整車廠的生存之本。
SOA只是諸多應(yīng)用在汽車上的新技術(shù)之一,整車廠的核心能力應(yīng)該是掌握有效應(yīng)用這些新技術(shù)的集成能力,而有效應(yīng)用新技術(shù)必須以深入理解目標(biāo)客戶的用車需求為前提,其最終的目的就是提升客戶的用車體驗。
對于SOA在汽車上的應(yīng)用而言,服務(wù)設(shè)計才是整車廠的核心能力,因為車輛能夠提供服務(wù)的好壞決定了用戶體驗,并且服務(wù)設(shè)計必須針對目標(biāo)客戶的用車需求來完成。
這篇文章從服務(wù)設(shè)計的角度介紹SOA。
智能汽車的本質(zhì)屬性并不是功能的多少,因為功能再多也只是一個靜態(tài)的概念。靜態(tài)意味著一旦功能設(shè)計完成,汽車能夠完成的任務(wù)是固定的。
一個功能的實現(xiàn)可以分為輸入、處理邏輯和輸出三個部分。功能設(shè)計完成后,它只能根據(jù)特定的輸入、特定的處理邏輯和特定的輸出控制來完成固定的任務(wù),也可以理解為向客戶提供特定的用車服務(wù),滿足客戶的用車需求。
為什么是SOA(面向服務(wù)的架構(gòu))而不是FOA(面向功能的架構(gòu))?服務(wù)和功能到底有什么區(qū)別和聯(lián)系?
筆者認(rèn)為,服務(wù)和功能這兩個概念從完成任務(wù)的實現(xiàn)方式(輸入、處理邏輯、輸出)來講,并沒有本質(zhì)區(qū)別。
之所以使用服務(wù)這個概念,相對于傳統(tǒng)的功能而言,主要是為了突出智能汽車在完成各種任務(wù)時所體現(xiàn)的靈活性、主動性以及預(yù)測性,也是就可以根據(jù)不同用車場景動態(tài)地調(diào)整完成任務(wù)的方式。
汽車是由各種配置(偏重于硬件)和服務(wù)(偏重于軟件)組成的。配置的高低決定了車輛的下限,而服務(wù)的好壞則決定了車輛的上限。
在特定的時間和空間中,當(dāng)一個或多個事件發(fā)生時,對于車輛而言就形成了我們通常所說的用車場景。
真正意義上的智能汽車是能夠更有效地識別用車場景甚至預(yù)測用車場景,并且主動通過各種服務(wù)來滿足客戶用車需求的汽車。這里的核心詞是“主動”,智能的本質(zhì)就是具有自主性甚至預(yù)測性,并且這種“自主性”和“預(yù)測性”的能力也能夠在不斷的自我進化中得到提升,越來越好地滿足用車需求。
基于以上對于智能汽車所提供服務(wù)的理解,我們在設(shè)計SOA服務(wù)時可以將服務(wù)分為以下3類:
1、場景感知類服務(wù):
這類服務(wù)主要用于用車場景的感知,即對時間、空間以及發(fā)生事件的感知。
時間感知服務(wù):例如,車輛通過4G網(wǎng)絡(luò)獲取時間信息;
空間感知服務(wù):例如,車輛通過GPS天線獲取位置信息;
事件感知類服務(wù):例如,車輛上電感知,車輛換擋感知,環(huán)境溫度感知、駕駛員表情感知、駕駛員視線感知;
場景感知服務(wù)主要是基于車輛硬件配置來實現(xiàn)的。
從服務(wù)與功能的關(guān)系來理解,場景感知類服務(wù)屬于基礎(chǔ)服務(wù),可以等同于傳統(tǒng)的感知類功能。
2、控制決策類服務(wù):
這類服務(wù)是造就智能汽車的核心服務(wù)。它根據(jù)場景感知類服務(wù)以及用戶操作所提供的各種輸入,經(jīng)過分析和計算,最終決定車輛應(yīng)該以何種方式滿足客戶的用車需求。
既然智能汽車的本質(zhì)屬性是具有主動性和預(yù)測性,那么對于控制決策類服務(wù)而言,能多大程度地減少對于用戶操作輸入的依賴,能多大程度地充分利用場景感知類服務(wù)輸入,并將各種輸入通過強大的算力進行綜合分析計算,完成最終的控制決策過程,這是判斷控制決策類服務(wù)智能化程度高低的依據(jù)。
例如:
氛圍燈的顏色可以根據(jù)用戶心情自主調(diào)節(jié)。
用戶吃飯的餐廳可以根據(jù)用戶的口味、綜合最新的餐廳優(yōu)惠折扣活動自主推薦。
溫度、濕度、空氣質(zhì)量可以根據(jù)用戶身體狀態(tài)、當(dāng)前天氣情況自主調(diào)節(jié)。
控制決策類服務(wù)依賴于算法和控制策略,并且這種算法和控制策略自身也可以不斷進化,它主要是基于軟件來實現(xiàn)。從服務(wù)與功能的關(guān)系來理解,控制決策類服務(wù)屬于高級服務(wù),它可以理解為一種具備自主性的高級功能,它可以靈活調(diào)用和組合基礎(chǔ)服務(wù)完成不同的任務(wù),滿足不同場景的用車需求。
3、動作執(zhí)行類服務(wù):
這類服務(wù)主要是用于控制車輛執(zhí)行各種動作,包括所有用戶可以感知到的聲音,文字、圖像、電機動作等等。
動作執(zhí)行類服務(wù)主要是基于整車硬件配置來實現(xiàn)的。從服務(wù)與功能的關(guān)系來理解,動作執(zhí)行類服務(wù)也屬于基礎(chǔ)服務(wù),可以等同于傳統(tǒng)的動作執(zhí)行類功能。
在之前的文章“SOA在汽車上的應(yīng)用(1)-(3)”中,筆者介紹了SOA是什么,為什么要應(yīng)用SOA、如何實現(xiàn)SOA以及如何設(shè)計SOA服務(wù)。
這篇文章繼續(xù)介紹如何來設(shè)計SOA服務(wù)。
服務(wù)是更高效地利用車輛能力滿足需求的一種手段,那么設(shè)計服務(wù)必然是從車輛所具有能力入手。
車輛電氣功能的實現(xiàn)需要輸入、處理、輸出三個過程,它們對應(yīng)車輛的三種能力:感知能力(提供信息輸入),計算控制能力(對信息進行處理)、執(zhí)行能力(實現(xiàn)輸出的結(jié)果)。
筆者曾將車輛的軟硬件資源所具備的能力分為3類:計算能力、通用控制能力和感知執(zhí)行能力,并將這3種能力根據(jù)EEA發(fā)展的5個階段,分別對應(yīng)到計算層、通用控制層和感知執(zhí)行層。
感知和執(zhí)行能力取決于車輛具備的傳感器和執(zhí)行器硬件配置,它們是車輛最底層的能力,這些能力可以被抽象為SOA原子服務(wù)。
這里的“原子”有2個含義,1個是底層(對應(yīng)集中式EEA的感知執(zhí)行層)的意思,可以理解為最基礎(chǔ)的服務(wù);1個是不可再分的意思,即原子服務(wù)是最小顆粒度的服務(wù),可以通過組合調(diào)用1個或多個原子服務(wù)形成高層級的(通用控制層和計算層)服務(wù)。
既然感知和執(zhí)行能力是車輛的基礎(chǔ)能力,在設(shè)計原子服務(wù)時,我們可以從傳感器和執(zhí)行器入手,分析所需要的原子服務(wù)。
例如,對于車身控制類服務(wù),可以基于不同的執(zhí)行器(電動車門、電動車窗、電動門鎖等)設(shè)計原子服務(wù),也可以基于不同的傳感器(門狀態(tài)開關(guān)、車窗位置傳感器、門鎖狀態(tài)開關(guān))設(shè)計原子服務(wù)。
這里需要注意,原子服務(wù)雖然是最底層和最小顆粒度的服務(wù),但原子服務(wù)也是一種服務(wù),設(shè)計服務(wù)的目的是為了滿足實際的需求,而不是機械化地將原子服務(wù)等同于車輛最底層的感知和執(zhí)行能力。
車輛的傳感器和執(zhí)行器數(shù)量龐大,且其類型、接口和參數(shù)也種類繁多。
例如,對于僅僅一個HVAC電氣系統(tǒng)來說,傳感器和執(zhí)行器類型涉及溫度傳感器、壓力傳感器、濕度傳感器、光線傳感器、水泵電機、電動壓縮機、PTC加熱器、電磁閥、電子膨脹閥、冷卻風(fēng)扇、風(fēng)門電機、鼓風(fēng)機等;設(shè)備接口涉及數(shù)字輸入、模擬輸入、高端驅(qū)動、低端驅(qū)動、CAN、LIN等;設(shè)備參數(shù)涉及電壓、電流、壓力、溫度、位置等;
如果將車輛所有電氣系統(tǒng)的所有傳感器和執(zhí)行器抽象為原子服務(wù),不僅使原子服務(wù)的數(shù)量過于龐大,而且從實際需求的角度也是沒有必要的。
對于HVAC電氣系統(tǒng)而言,我們需要從實際需求的角度,分析可能需要哪些原子服務(wù)。
例如,獲取當(dāng)前車內(nèi)某個區(qū)域的溫度值或者設(shè)定目標(biāo)溫度值、開啟或關(guān)閉某個區(qū)域的自動溫度控制、開啟或關(guān)閉通風(fēng)、獲取當(dāng)前風(fēng)量大小,設(shè)置目標(biāo)風(fēng)量大小、獲取當(dāng)前吹風(fēng)模式、設(shè)置吹風(fēng)模式等等;
如果要實現(xiàn)SOA,則需要實現(xiàn)原子服務(wù)與車型平臺的解耦,從而提升原子服務(wù)的復(fù)用性。不同車型平臺的硬件設(shè)備與驅(qū)動程序不同,這需要包括操作系統(tǒng)在內(nèi)的廣義平臺系統(tǒng)軟件來實現(xiàn)軟件與硬件設(shè)備的解耦,屏蔽硬件設(shè)備與驅(qū)動的差異,給原子服務(wù)提供統(tǒng)一的API。
因此,從軟硬件解耦的角度去考慮,車輛所有的硬件設(shè)備有必要抽象為標(biāo)準(zhǔn)的接口。另一方面,原子服務(wù)可能根據(jù)需求進行增加,全面的硬件設(shè)備的API接口使原子服務(wù)的設(shè)計更加靈活。
SOA只是諸多應(yīng)用在汽車上的新技術(shù)之一,整車廠的核心能力應(yīng)該是掌握有效應(yīng)用這些新技術(shù)的集成能力,而有效應(yīng)用新技術(shù)必須以深入理解目標(biāo)客戶的用車需求為前提,其最終的目的就是提升客戶的用車體驗。
從這個角度來理解SOA的服務(wù)設(shè)計,整車廠可以參與原子服務(wù)的設(shè)計,但這并不是構(gòu)建整車廠差異化競爭力的關(guān)鍵。
基于原子服務(wù)的組合,在不同的用車場景中構(gòu)建個性化、智能化的應(yīng)用,提升用車體驗,這才是SOA服務(wù)設(shè)計的最終目的,也是整車廠需要掌握的核心能力。
審核編輯 :李倩
-
汽車電子
+關(guān)注
關(guān)注
3023文章
7835瀏覽量
166045 -
ecu
+關(guān)注
關(guān)注
14文章
877瀏覽量
54362 -
SOA
+關(guān)注
關(guān)注
1文章
282瀏覽量
27405 -
智能汽車
+關(guān)注
關(guān)注
30文章
2755瀏覽量
107094 -
架構(gòu)設(shè)計
+關(guān)注
關(guān)注
0文章
31瀏覽量
6916
原文標(biāo)題:一文聊聊智能汽車中SOA架構(gòu)設(shè)計方法
文章出處:【微信號:智能汽車電子與軟件,微信公眾號:智能汽車電子與軟件】歡迎添加關(guān)注!文章轉(zhuǎn)載請注明出處。
發(fā)布評論請先 登錄
相關(guān)推薦
評論