面向服務(wù)架構(gòu)(SOA):超經(jīng)典合集
第一部:面向服務(wù)架構(gòu)(SOA)的汽車軟件及其開發(fā)方法
一. 為什么要引入SOA汽車軟件?
SOA是一種軟件架構(gòu),同時(shí)也是一種軟件設(shè)計(jì)方法和理念,在IT領(lǐng)域已有數(shù)十年的應(yīng)用經(jīng)驗(yàn)。SOA具備”松耦合”、”接口標(biāo)準(zhǔn)可訪問”和”易于擴(kuò)展”等特點(diǎn),使得開發(fā)人員能以最小的軟件變更應(yīng)對(duì)迭代多變的客戶需求。在智能網(wǎng)聯(lián)汽車中,大量的功能需要控制器(ECU)間的協(xié)調(diào)工作來實(shí)現(xiàn),當(dāng)前ECU 間基于信號(hào)(Signal-Oriented)的點(diǎn)對(duì)點(diǎn)通訊將會(huì)變得異常復(fù)雜,且不具備靈活性和擴(kuò)展性,微小的功能改動(dòng)都會(huì)引起整車通訊矩陣的改動(dòng)(圖1)。因此,聯(lián)合電子將SOA引入到當(dāng)前汽車軟件設(shè)計(jì)中(圖2),車輛功能被以面向服務(wù)的設(shè)計(jì)理念架構(gòu)為不同的服務(wù)組件,有別于面向信號(hào)的傳統(tǒng)架構(gòu),SOA中的每個(gè)服務(wù)都具有唯一且獨(dú)立互不影響的身份標(biāo)識(shí)(ID),并通過服務(wù)中間件(Service Middleware)完成自身的發(fā)布,對(duì)其他服務(wù)的訂閱以及與其他服務(wù)的通訊工作。由此,SOA良好的解決了傳統(tǒng)架構(gòu)中因個(gè)別功能增減/變更而導(dǎo)致整個(gè)通訊矩陣與路由矩陣都要變更的問題。更進(jìn)一步,由于其”接口標(biāo)準(zhǔn)可訪問”的特性,服務(wù)組件的部署不再依賴于具體特定的操作系統(tǒng)和編程語言,在一定程度上實(shí)現(xiàn)了組件的”軟硬分離”。圖1 面向信號(hào)的架構(gòu)(Signal-Oriented Architecture)圖2 面向服務(wù)的架構(gòu)(Service-Oriented Architecture)二. 如何有效的開發(fā)SOA汽車軟件?
對(duì)于汽車行業(yè)而言,SOA是一套新引入的技術(shù),需要一套有效的流程、方法和工具,用以解決如下三個(gè)問題:1) 如何分析和設(shè)計(jì)服務(wù)架構(gòu),2) 如何建模和記錄服務(wù)架構(gòu),3)如何部署和實(shí)現(xiàn)面向服務(wù)的軟件。- 如何分析和設(shè)計(jì)面向服務(wù)的架構(gòu)?
- 如何建模和記錄面向服務(wù)的架構(gòu)?
- 如何部署和實(shí)現(xiàn)面向服務(wù)的軟件
三. SOA汽車軟件創(chuàng)新平臺(tái)
聯(lián)合電子開發(fā)的域控制器XCU ,提供了部署SOA汽車軟件的平臺(tái)。在硬件方面,XCU具備高算力處理器芯片和多路車規(guī)級(jí)以太網(wǎng)通道;在軟件方面,XCU搭載POSIX操作系統(tǒng)和AUTOSAR Adaptive平臺(tái)。根據(jù)SOA軟件開發(fā)方法,可從兩個(gè)切入點(diǎn)開展SOA汽車軟件平臺(tái)的開發(fā)。1)自下至上,從車輛基礎(chǔ)功能/信號(hào)出發(fā),將已有的應(yīng)用功能邏輯/信號(hào)(eg:車輛車速信息)抽象或封裝成服務(wù)組件,這類組件被稱為基礎(chǔ)服務(wù)層(Basic/Platform Service Layer)組件,具有最高的可復(fù)用性和可組合性,這些組件將為上層(業(yè)務(wù)服務(wù)層Business Service Layer)的服務(wù)組件提供最基礎(chǔ)的支持。2)自上而下,從整車業(yè)務(wù)邏輯和用例出發(fā),結(jié)合各領(lǐng)域的核心業(yè)務(wù)知識(shí),設(shè)計(jì)業(yè)務(wù)服務(wù)層(Business Service Layer)的服務(wù)組件;同時(shí),遵循服務(wù)組件的復(fù)用性和自主性等原則,向下設(shè)計(jì)規(guī)劃基礎(chǔ)服務(wù)層(Basic/Platform Service Layer)的服務(wù)組件(圖8)。http://www.uml.org.cn/soa/images/20210603128.webp.jpg圖8 基于域控制器(XCU)的SOA服務(wù)架構(gòu)四. SOA架構(gòu)的核心要素與優(yōu)勢(shì)
SOA作為一種面向服務(wù)的架構(gòu),是一種設(shè)計(jì)思想和方法論。在SOA架構(gòu)中,服務(wù)是最核心的抽象手段和系統(tǒng)最基礎(chǔ)的描述單元。每個(gè)服務(wù)組件具備獨(dú)立的功能,且可被復(fù)用;服務(wù)組件之間的接口遵循統(tǒng)一標(biāo)準(zhǔn),可互相訪問,可組合擴(kuò)展。業(yè)務(wù)過程則是帶有狀態(tài)和服務(wù)調(diào)度策略的服務(wù)組件的組合與擴(kuò)展(圖1)。通過SOA架構(gòu),可整合規(guī)劃OEM在不同操作系統(tǒng),硬件平臺(tái)上(控制器)上的業(yè)務(wù)功能,實(shí)現(xiàn)對(duì)功能的快速迭代和重組,應(yīng)對(duì)靈活多變的智能網(wǎng)聯(lián)趨勢(shì)下的業(yè)務(wù)需求。http://www.uml.org.cn/soa/images/20210603129.png圖9:SOA架構(gòu)模型結(jié)合未來汽車域?qū)蛐碗娮与姎饧軜?gòu)(Domain-Oriented)和區(qū)域?qū)蛐碗娮与姎饧軜?gòu)(Zone-Oriented),應(yīng)用SOA架構(gòu)可實(shí)現(xiàn)業(yè)務(wù)過程(功能)的快速迭代與靈活重組,為智能網(wǎng)聯(lián)趨勢(shì)下的軟件個(gè)性化與創(chuàng)新需求提供了良好的平臺(tái)性解決方案。SOA架構(gòu)應(yīng)用于汽車新電子電氣架構(gòu)下的優(yōu)勢(shì)(圖2):車輛功能軟件實(shí)現(xiàn)軟硬分離由于服務(wù)組件接口“標(biāo)準(zhǔn)可訪問”,且描述方式獨(dú)立于硬件平臺(tái)和操作系統(tǒng),因此組件功能可脫離硬件平臺(tái)任意部署移動(dòng),對(duì)于算力有要求的復(fù)雜功能組件可向具備高帶寬大算力的域控制器移動(dòng)。車輛功能可被大范圍復(fù)用一些使用頻度很高且基礎(chǔ)的功能可作為基礎(chǔ)服務(wù)組件先被開發(fā),由于服務(wù)組件的獨(dú)立性以及接口的標(biāo)準(zhǔn)可訪問,基礎(chǔ)服務(wù)開發(fā)完成后可向服務(wù)中間件注冊(cè),并供所有電子電氣架構(gòu)中的控制器訂閱使用。車輛功能在SOP后可新增(擴(kuò)展)“小”的基礎(chǔ)服務(wù)可組合成為“大”服務(wù),“大”服務(wù)可進(jìn)一步組合擴(kuò)展并最終構(gòu)建出新的業(yè)務(wù)過程,實(shí)現(xiàn)OEM的業(yè)務(wù)目標(biāo)。結(jié)合OTA技術(shù),用戶可在車輛使用期限里,訂閱一個(gè)類似,“預(yù)測(cè)性能量管理”的新功能并安裝于域控制器上,新功能的業(yè)務(wù)邏輯依賴于一些已有的服務(wù)組件(eg:預(yù)測(cè)性能量管理依賴于能量管理策略,地圖預(yù)測(cè)信息等基礎(chǔ)服務(wù))。http://www.uml.org.cn/soa/images/202106031210.png圖10 新汽車電子電氣架構(gòu)中的SOA架構(gòu)應(yīng)用第二部:面向服務(wù)架構(gòu)(SOA)的汽車軟件分析和設(shè)計(jì)
面向服務(wù)架構(gòu)的開發(fā)過程從整體上可以概括為6個(gè)步驟,分別是:面向服務(wù)分析、面向服務(wù)設(shè)計(jì)、服務(wù)開發(fā)、服務(wù)測(cè)試、服務(wù)部署和服務(wù)權(quán)限管理,如圖11所示。其中,分析和設(shè)計(jì)面向服務(wù)的架構(gòu)是開發(fā)SOA軟件的開端,也是判斷系統(tǒng)是否基于SOA架構(gòu)的最重要且核心的環(huán)節(jié)。聯(lián)合電子對(duì)分析和設(shè)計(jì)面向服務(wù)架構(gòu)汽車軟件的具體流程與方法進(jìn)行了探索,將面向服務(wù)的分析分解為系統(tǒng)需求分析、系統(tǒng)功能分析、候選服務(wù)分析三個(gè)子步驟,將面向服務(wù)的設(shè)計(jì)分解為系統(tǒng)架構(gòu)設(shè)計(jì)和軟件架構(gòu)設(shè)計(jì)兩個(gè)子步驟。經(jīng)過架構(gòu)師的良好分析,車輛功能(業(yè)務(wù)邏輯/業(yè)務(wù)過程)將結(jié)合實(shí)際實(shí)現(xiàn)情況,按不同業(yè)務(wù)領(lǐng)域完成解耦,并分解得到候選服務(wù)組件。后續(xù),經(jīng)過詳細(xì)且不斷迭代的設(shè)計(jì),在候選服務(wù)的基礎(chǔ)上,最終會(huì)產(chǎn)出面向服務(wù)(SOA)的軟件架構(gòu)。http://www.uml.org.cn/soa/images/202106031211.png圖11 面向服務(wù)的分析與設(shè)計(jì)是服務(wù)架構(gòu)開發(fā)的核心環(huán)節(jié)接下來本文將圍繞這5個(gè)子步驟對(duì)面向服務(wù)的分析與設(shè)計(jì)過程進(jìn)行介紹。- 系統(tǒng)需求分析
- 系統(tǒng)功能分析
- 候選服務(wù)分析
- 系統(tǒng)架構(gòu)設(shè)計(jì)
- 軟件架構(gòu)設(shè)計(jì)
第三部:面向服務(wù)架構(gòu)(SOA)的汽車軟件實(shí)現(xiàn)和部署
根據(jù)SOA架構(gòu)層級(jí)模型(圖18),業(yè)務(wù)邏輯經(jīng)過面向服務(wù)架構(gòu)(SOA)的軟件分析和設(shè)計(jì)過程后,被分解為單個(gè)服務(wù)并綁定相應(yīng)的可執(zhí)行軟件單元。以服務(wù)軟件架構(gòu)為輸入,汽車服務(wù)軟件的實(shí)現(xiàn)和部署工作主要在服務(wù)組件層(Service Components)完成(圖1紅色箭頭)。http://www.uml.org.cn/soa/images/202106031217.png圖 18 SOA 層級(jí)架構(gòu)模型01 滿足 SOA 架構(gòu)的服務(wù)組件架構(gòu) (Service-Component-Architecture)針對(duì)服務(wù)組件,SOA定義了服務(wù)組件的架構(gòu)模型(SCA)(圖19),在SCA的框架下,服務(wù)組件內(nèi)部被分為業(yè)務(wù)邏輯(Service)與基礎(chǔ)設(shè)施邏輯(Interface和Message)兩部分,并互相解耦:服務(wù)軟件單元(Service):業(yè)務(wù)/功能邏輯,不關(guān)心操作系統(tǒng)和編程語言,可由熟悉業(yè)務(wù)邏輯的相關(guān)方開發(fā)接口(Interface):決定對(duì)外提供哪些服務(wù)以及自身服務(wù)依賴哪些服務(wù),不關(guān)心操作系統(tǒng)和編程語言,可由SOA架構(gòu)設(shè)計(jì)方完成開發(fā)和部署消息(Message):接口數(shù)據(jù)的通訊鏈路/環(huán)境綁定,不關(guān)心操作系統(tǒng)和編程語言,可由SOA架構(gòu)設(shè)計(jì)方完成開發(fā)和部署整個(gè)服務(wù)組件層的工作是對(duì)服務(wù)組件進(jìn)行規(guī)范型描述,描述內(nèi)容主要包含兩個(gè)部分:服務(wù)組件架構(gòu)模型SCA的配置描述服務(wù)組件內(nèi)部業(yè)務(wù)邏輯和基礎(chǔ)設(shè)施邏輯的集成http://www.uml.org.cn/soa/images/202106031218.png圖19 SOA服務(wù)組件架構(gòu)模型(SCA)02 服務(wù)組件架構(gòu)SCA的配置描述通過SCA架構(gòu)模型,每個(gè)服務(wù)軟件單元(Service)以標(biāo)準(zhǔn)的接口形式(Interface)向消費(fèi)方提供服務(wù)內(nèi)容,以統(tǒng)一的通訊協(xié)議傳遞序列化消息(Message)。對(duì)于SOA架構(gòu)設(shè)計(jì)和應(yīng)用人員,需要通過工具配置SCA架構(gòu)模型中的參數(shù),使其與服務(wù)管理組件一同實(shí)現(xiàn)SOA軟件的部署和運(yùn)作。http://www.uml.org.cn/soa/images/202106031219.webp.jpg圖20 SCA架構(gòu)模型中的配置信息SCA架構(gòu)模型中的主要元素分為“服務(wù)接口”和“服務(wù)實(shí)現(xiàn)”兩大類。其中,“服務(wù)接口描述”包含服務(wù)軟件單元(Services),組件接口(Interface)和消息通訊(Message);“服務(wù)實(shí)現(xiàn)”則包括通訊協(xié)議綁定(Binding)和服務(wù)端口信息等(Endpoint)(圖20)。WebService的SCA架構(gòu)模型配置描述以IT行業(yè)SOA封裝使用較為廣泛的WebService為例,其對(duì)SCA架構(gòu)模型的描述遵從如下標(biāo)準(zhǔn)協(xié)議:http://www.uml.org.cn/soa/images/202106031220.png表1 SCA架構(gòu)模型中的配置信息在IBM公司發(fā)布的SOA系統(tǒng)解決方案- 企業(yè)服務(wù)總線(Enterprise-Service-Bus)中提供了WebSphere Integration Developer開發(fā)環(huán)境,該環(huán)境支持配置生成符合WSDL規(guī)范的服務(wù)組件描述文檔。汽車軟件的SCA架構(gòu)模型配置描述在汽車軟件領(lǐng)域,當(dāng)前,聯(lián)合電子采用AUTOSAR Adaptive組織提供的模型描述規(guī)范。AUTOSAR Adaptive組織對(duì)SCA架構(gòu)模型的描述遵循如下標(biāo)準(zhǔn):http://www.uml.org.cn/soa/images/202106031221.webp.jpg表2 SCA架構(gòu)模型中的配置信息03 汽車SOA軟件的實(shí)現(xiàn)方案如上文所述,汽車軟件領(lǐng)域,聯(lián)合電子遵循AUTOSAR Adaptive標(biāo)準(zhǔn)來完成SOA中間件的部署和應(yīng)用,AUTOSAR Adaptive組件采用經(jīng)典的代理(Proxy)-框架(Skeleton)模式來完成SCA架構(gòu)模型的描述(如圖21)。http://www.uml.org.cn/soa/images/202106031222.png圖21 Proxy(stub)/Skeleton架構(gòu)模式這種模式將原本直接交互的調(diào)用者(Client)與被調(diào)用者(Server)分離,由代理負(fù)責(zé)傳遞信息來完成調(diào)用,client和server不需要處理通信層詳細(xì)信息。同時(shí),AUTOSAR Adaptive廠商基于C 語言具體實(shí)現(xiàn)代理-框架模式,確保應(yīng)用服務(wù)開發(fā)人員可以靈活配置自定義的服務(wù)接口,并結(jié)合對(duì)應(yīng)工具生成SCA架構(gòu)模型代碼(.cpp/.cc)和配置文件(.json)。具體的,這些代碼:封裝了SOME-IP協(xié)議棧和底層通訊細(xì)節(jié)(Middleware Transport Layer)提供了相應(yīng)的服務(wù)虛接口(virtual function)通過1),服務(wù)組件開發(fā)人員不必再關(guān)心服務(wù)Message對(duì)應(yīng)的協(xié)議如何實(shí)現(xiàn);通過2),服務(wù)組件開發(fā)人員基于C 的語言特性,可繼承(inherit)虛接口并覆寫(override)虛接口的具體實(shí)現(xiàn)(函數(shù)體)。該機(jī)制保證了“基礎(chǔ)設(shè)施邏輯”和“業(yè)務(wù)(功能)邏輯”的解耦,服務(wù)內(nèi)部業(yè)務(wù)邏輯的改動(dòng)不影響服務(wù)組件向外的接口提供。04 SOA服務(wù)組件實(shí)現(xiàn)和部署的具體步驟SOA服務(wù)組件“實(shí)現(xiàn)和部署”的整個(gè)過程以面向服務(wù)(SOA)的軟件架構(gòu)為輸入,內(nèi)容上除完成第二章提到的“基礎(chǔ)設(shè)施邏輯”配置工作外,還需將業(yè)務(wù)(功能)邏輯與基礎(chǔ)設(shè)施邏輯集成,最終編譯成可執(zhí)行的服務(wù)組件單元(Service Component)(圖22)。http://www.uml.org.cn/soa/images/202106031223.webp.jpg圖22 服務(wù)組件單元(Service Component)如第一章中對(duì)服務(wù)組件的SCA描述,整體服務(wù)組件(Service Component)由服務(wù)單元(Service)提供的“業(yè)務(wù)邏輯”和適配目標(biāo)系統(tǒng)環(huán)境相關(guān)的“基礎(chǔ)設(shè)施邏輯”兩部分組成。在開發(fā)過程中,這兩部分是解耦的,可同時(shí)進(jìn)行的,且軟件形態(tài)是靈活的。服務(wù)單元(Service)的邏輯可以是源碼或被封裝為SDK形式,且不關(guān)心具體的編程語言;基礎(chǔ)設(shè)施邏輯 (Interface和Message) 則以C 的形態(tài)編碼,與服務(wù)管理中間件一起確保服務(wù)的動(dòng)態(tài)響應(yīng)性和服務(wù)自身的可擴(kuò)展性,其軟件形態(tài)同樣可以是源碼或SDK形式提供。在流程上方法論上,”實(shí)現(xiàn)和部署”工作主要分為服務(wù)組件接口設(shè)計(jì),服務(wù)組件集成實(shí)現(xiàn)和安裝部署三個(gè)步驟:組件接口設(shè)計(jì)階段: 聯(lián)合電子編寫arxml完成對(duì)服務(wù)組件SCA中“基礎(chǔ)設(shè)施邏輯”的配置開發(fā),并經(jīng)由AUTOSAR Adaptive中間件供應(yīng)商提供的代碼框架和生成器(Generator),最終得到相關(guān)的配置文件(.json)和源代碼(.cc/.cpp);對(duì)“服務(wù)單元邏輯”,聯(lián)合電子可同步基于建模工具進(jìn)行開發(fā);組件集成實(shí)現(xiàn)階段: 聯(lián)合電子編寫APP框架,完成“服務(wù)單元邏輯”與“基礎(chǔ)設(shè)施邏輯”的軟件集成工作;組件安裝部署階段: 聯(lián)合電子編寫編譯和安裝腳本,完成源碼的編譯鏈接和可執(zhí)行文件(App)的安裝,同時(shí),對(duì)APP安裝部署權(quán)限和系統(tǒng)環(huán)境做適配調(diào)整。http://www.uml.org.cn/soa/images/202106031224.png“分析和設(shè)計(jì)面向服務(wù)的架構(gòu)”、“實(shí)現(xiàn)和部署面向服務(wù)的軟件”是有效開發(fā)SOA汽車軟件的關(guān)鍵環(huán)節(jié),“實(shí)現(xiàn)和部署面向服務(wù)軟件”的過程是SOA軟件可以“落地”不可或缺的環(huán)節(jié)第四部:面向服務(wù)架構(gòu)(SOA)的應(yīng)用
原子服務(wù)說到服務(wù)架構(gòu),關(guān)于原子服務(wù)的話題非常火,那么,什么是原子服務(wù)?原子服務(wù)有哪些特征?在系統(tǒng)層面如何拆分業(yè)務(wù)服務(wù)并且定義原子服務(wù)?原子服務(wù)對(duì)我們的軟件又有什么影響呢?他和服務(wù)的關(guān)系又是什么呢?
我們先從服務(wù)的最小單元——原子服務(wù)講起。原子服務(wù)的定義是:業(yè)務(wù)上最小粒度的一系列操作。原子服務(wù)的特點(diǎn)是松耦合,相對(duì)獨(dú)立,且在可預(yù)見的范圍內(nèi)不會(huì)對(duì)其他原子服務(wù)造成影響。任何一項(xiàng)都劃定了自己的業(yè)務(wù)范圍;他們不用關(guān)心非自己業(yè)務(wù)范圍是如何實(shí)現(xiàn),對(duì)于調(diào)用其他原子服務(wù),只需要考慮調(diào)用場(chǎng)景及返回結(jié)果如何處理即可。
舉一個(gè)例子,先看看下面三句話:
- 現(xiàn)金存款是金融賬戶發(fā)生現(xiàn)金交易的收費(fèi)服務(wù)行為。
- 信用卡還款是金融賬戶發(fā)生的,可能有銀聯(lián)參與的、信用卡的現(xiàn)金交易。
- 現(xiàn)金轉(zhuǎn)賬是金融賬戶與交易對(duì)手金融賬戶發(fā)生現(xiàn)金交易的收費(fèi)服務(wù)行為。
這三句話中的,現(xiàn)金存款、信用卡還款和現(xiàn)金轉(zhuǎn)賬就是服務(wù),現(xiàn)金交易就是原子服務(wù),而金融賬戶、銀聯(lián)卡和信用卡則是服務(wù)的業(yè)務(wù)參與方,也是大家熟知的服務(wù)消費(fèi)者和提供方。
通過這個(gè)例子,大家應(yīng)該對(duì)原子服務(wù)已經(jīng)有了一個(gè)基本的概念。那么,服務(wù)是由原子服務(wù)構(gòu)成的,SOA是不是只是簡(jiǎn)單地由服務(wù)構(gòu)成的呢?
1. SOA 架構(gòu)的特性
答案很顯然,要實(shí)現(xiàn)真正完整的 SOA 架構(gòu),只靠原子服務(wù)和服務(wù)是不夠的。首先,我們看一下SOA的基礎(chǔ)定義:
SOA基于服務(wù)的架構(gòu),繼承了來自對(duì)象(指的是“面向?qū)ο蟮募軜?gòu)”)和構(gòu)件設(shè)計(jì)的各種原則,例如,封裝和自我包含等。那些保證服務(wù)的靈活性、松散耦合和復(fù)用能力的設(shè)計(jì)原則,對(duì) SOA 架構(gòu)來說同樣是非常重要的。
關(guān)于服務(wù)的基本特性如下:
標(biāo)準(zhǔn)接口服務(wù)提供方以統(tǒng)一的方式即標(biāo)準(zhǔn)的接口向消費(fèi)者提供服務(wù)信息,比如車載服務(wù)軟件一般會(huì)使用SOME/IP協(xié)議作為實(shí)現(xiàn)基礎(chǔ)。自主和模塊化服務(wù)封裝了那些在業(yè)務(wù)上穩(wěn)定、重復(fù)出現(xiàn)的活動(dòng)和構(gòu)件,實(shí)現(xiàn)服務(wù)的功能實(shí)體是完全獨(dú)立自主的,獨(dú)立進(jìn)行部署、版本控制、自我管理和恢復(fù)。松耦合服務(wù)請(qǐng)求者可見的是服務(wù)的接口,其位置、實(shí)現(xiàn)技術(shù)、當(dāng)前狀態(tài)和私有數(shù)據(jù)等,對(duì)服務(wù)消費(fèi)者而言是不可見的。互操作性、兼容和策略聲明為了確保服務(wù)規(guī)約的全面和明確,策略成為一個(gè)越來越重要的方面。例如,一個(gè)服務(wù)對(duì)安全性方面的要求;也可以是與業(yè)務(wù)有關(guān)的語義方面的內(nèi)容,例如,需要滿足的費(fèi)用或者服務(wù)級(jí)別方面的要求,這些策略對(duì)于服務(wù)在交互時(shí)是非常重要的。
而服務(wù)的最小顆粒度則是上文提到的不可拆分的原子服務(wù)。那原子服務(wù)的顆粒度是不是越小越好呢?答案肯定不是的,如何定義合理的原子服務(wù),如何把握顆粒度的大小,在服務(wù)架構(gòu)設(shè)計(jì)中至關(guān)重要。舉個(gè)更形象的例子,原子服務(wù)就類似于電路設(shè)計(jì)中的電容和電阻,他們有著統(tǒng)一的標(biāo)準(zhǔn),看似一樣卻又有著不同的封裝,在不同的ECU控制器中組合成不同的應(yīng)用電路,適當(dāng)調(diào)整又能實(shí)現(xiàn)非常多的新的功能。
2.?SOA架構(gòu)的實(shí)現(xiàn)基礎(chǔ)
有了理論基礎(chǔ),下一步就是看實(shí)現(xiàn)服務(wù)架構(gòu)的必要條件。很多同學(xué)其實(shí)會(huì)問,為什么服務(wù)總是和以太網(wǎng),DDS或SOME/IP綁定的呢?CAN網(wǎng)絡(luò)上是否可以實(shí)現(xiàn)完整的SOA架構(gòu)?
首先,以SOME/IP舉例,因?yàn)镾OME/IP的完整名稱其實(shí)能回答上面的大多數(shù)問題,SOME/IP = Scalable service-Oriented MiddlewarE over IP。即“運(yùn)行于IP之上的可伸縮的面向服務(wù)的中間件”。可見,并不是SOA必須和SOME/IP綁定,而是SOME/IP天生就是為了SOA架構(gòu)而生。SOME/IP的精華在于“Middleware中間件”,這是一種獨(dú)立的系統(tǒng)軟件或服務(wù)程序,分布式應(yīng)用軟件可借助Middleware在不同的技術(shù)之間共享資源。分布式應(yīng)用軟件,在這里指的就是“服務(wù)”;不同的技術(shù)之間,在這里指的就是不同的平臺(tái)或操作系統(tǒng),比如Linux系統(tǒng)或AUTOSAR OS OSEK等。而Scalable Middleware,顧名思義,則是“可伸縮中間件”,指的是該中間件能夠適配于不同的平臺(tái)及操作系統(tǒng),其支撐的平臺(tái)可大可小。
簡(jiǎn)單來說,SOA是軟件架構(gòu)的一種設(shè)計(jì)理念;SOME/IP是一種將軟件接口進(jìn)行打包的打包方式,是一種中間件。而汽車行業(yè)通常所指的"以太網(wǎng)"是泛化之后的概念,涵蓋了基于以太網(wǎng)技術(shù)所實(shí)現(xiàn)的各種相關(guān)技術(shù)手段,包括TCP/IP協(xié)議、DoIP協(xié)議、SOME/IP協(xié)議等。當(dāng)然若通過其他非以太網(wǎng)的通信方式來實(shí)現(xiàn)SOA也是可行的,但通常大家不那么用。比如基于CAN總線的架構(gòu),由于其基礎(chǔ)的架構(gòu)和通信協(xié)議棧里不存在Middleware中間層的概念,所以要實(shí)現(xiàn)SOA的代價(jià)是非常巨大的。
3. SOA 應(yīng)用的優(yōu)勢(shì)
正如大家所知,早期的車內(nèi)嵌入式軟件沒有統(tǒng)一標(biāo)準(zhǔn),基礎(chǔ)軟件和應(yīng)用軟件強(qiáng)耦合,不具可移植性;AUTOSAR Classic 的應(yīng)用,對(duì)嵌入式基礎(chǔ)軟件的接口進(jìn)行標(biāo)準(zhǔn)化,讓應(yīng)用開發(fā)者基于統(tǒng)一的基礎(chǔ)軟件接口進(jìn)行應(yīng)用開發(fā)。目前采用SOA軟件服務(wù)架構(gòu)的應(yīng)用打通了車內(nèi)的電子電氣架構(gòu)的壁壘,進(jìn)一步對(duì)嵌入式應(yīng)用軟件的接口(即服務(wù)接口)進(jìn)行了標(biāo)準(zhǔn)化,讓APP開發(fā)者基于統(tǒng)一基礎(chǔ)服務(wù)接口進(jìn)行應(yīng)用的迭代開發(fā),隱藏了不同車型配置下應(yīng)用軟件的差異,真正做到了整車級(jí)軟件接口的"標(biāo)準(zhǔn)"和"開放"。
- 平臺(tái)架構(gòu)升級(jí)更便于實(shí)現(xiàn),通過服務(wù)設(shè)計(jì)的方式,能夠有效降低架構(gòu)升級(jí)帶來的復(fù)雜度;同時(shí),由于操作系統(tǒng)跨平臺(tái)的難度大幅度降低,能夠大幅提升用戶體驗(yàn),能夠?qū)崿F(xiàn)更為便捷的聯(lián)網(wǎng)功能,實(shí)現(xiàn)不同平臺(tái)間的各種APP共享等功能;
- 通過“服務(wù)Hub”區(qū)域控制器的引入,各種新功能能夠靈活地與其他域功能,乃至互聯(lián)網(wǎng)接口集成,而無需各個(gè)控制器各自進(jìn)行信號(hào)到服務(wù)的轉(zhuǎn)換;
- ?一些相對(duì)獨(dú)立的域開發(fā)能夠打破界限,找到新的上限,例如自動(dòng)駕駛功能不再是電子電氣架構(gòu)“孤島”,通過區(qū)域控制器進(jìn)行服務(wù)互通,可以輕松實(shí)現(xiàn)高清地圖的創(chuàng)建、更新及路線預(yù)測(cè)等功能,便于實(shí)現(xiàn)車輛信息的上傳及云端指令的下達(dá);
4. SOA 的應(yīng)用實(shí)例
正如上文提到的,一旦自動(dòng)駕駛域不再成為電子電氣孤島,那么他的傳感器、雷達(dá)、攝像頭都能成為整車功能體驗(yàn)提升的利器。同時(shí),由于區(qū)域控制器ZONE具有服務(wù)轉(zhuǎn)換能力,ADAS計(jì)算中心也不需要拖著大量的傳感器,雷達(dá)或攝像頭一一連接,只需要簡(jiǎn)單從服務(wù)中間層直接發(fā)起調(diào)度請(qǐng)求即可。下面是一個(gè)潛在的開發(fā)實(shí)例:
第一階段也就是目前90%的E/E架構(gòu)中所使用的平行式分布,由于ZONE在初期無法實(shí)現(xiàn)LVDS和攝像頭視頻的處理能力,所以暫時(shí)不會(huì)動(dòng)AD的“孤島”。但是其他的比如車身等相關(guān)的會(huì)通過區(qū)域控制器的服務(wù)轉(zhuǎn)換能力,將信號(hào)打包成業(yè)務(wù)服務(wù)。
當(dāng)然,ZONE區(qū)域控制器并不是簡(jiǎn)單的hub,在拆分和打包服務(wù)的同時(shí),也會(huì)同步進(jìn)行原子服務(wù)的開發(fā)和豐富,后續(xù)隨著整車的FOTA更新,我們的原子服務(wù)越來越完善,同步也會(huì)有更多豐富的業(yè)務(wù)服務(wù)在互聯(lián)互通的大環(huán)境下呈現(xiàn)給用戶。
第二階段在這個(gè)階段,隨著區(qū)域下一代產(chǎn)品的發(fā)展,會(huì)在硬件上具備一些特殊接口的集成能力,例如上圖中原來AD的專屬武器如雷達(dá)或分布式攝像頭等可以直接連接到區(qū)域控制器,這一步看上去僅僅是硬件兼容的一小步,但卻是E/E架構(gòu)升級(jí)的一大步。因?yàn)檫@意味著,環(huán)境感知服務(wù)的使用權(quán)被平等地交付到了每個(gè)域手中。
如果說過去的車身域是電子域,一旦環(huán)境感知信號(hào)的引入,會(huì)讓車身域真正地進(jìn)化出“眼睛”,燈光、雨刮、天窗、門鎖、防盜不再是冷冰冰的電子功能,他們會(huì)成為整車人工智能的新入口,從電子域進(jìn)化為智能域。一些過去只存在想象中的功能,例如視覺識(shí)別天氣自動(dòng)調(diào)整雨刮、根據(jù)周圍行人和車輛自動(dòng)調(diào)整燈光方向、單人使用車輛的時(shí)候僅解鎖離車主最近的一扇門,這些功能都不再是幻想。
第三階段也是BOSCH體系定義的電子電氣架構(gòu)最終階段,區(qū)域控制器會(huì)“返璞歸真”,將所有特殊接口的能力打包成真正統(tǒng)一的虛擬服務(wù)接口,而這其中的關(guān)鍵條件則在于區(qū)域控制器是否具備了完整的原子服務(wù),例如,一旦區(qū)域能夠提供“視頻解析”的原子服務(wù),那么我們無需在區(qū)域上接入LVDS信號(hào),直接通過千兆以太網(wǎng)將視頻服務(wù)“原封不動(dòng)”地傳遞到區(qū)域上,然后在區(qū)域控制器里會(huì)有對(duì)應(yīng)的“解碼器”,將這些信號(hào)解析、解碼、重構(gòu)、并打包成服務(wù),以極低的延時(shí)和極高的保真率提供給不同的處理單元和控制模塊。
而這個(gè)階段一旦實(shí)現(xiàn),接口的標(biāo)準(zhǔn)化和統(tǒng)一化會(huì)上升到新的高度,整車電子電氣架構(gòu)的成本也可以大幅度下降,主干網(wǎng)通過以太網(wǎng)傳遞服務(wù),支路通過CAN/LIN等傳統(tǒng)總線收集原子服務(wù)需要的信號(hào)流,所有的系統(tǒng)、軟件、硬件有條不紊地在自己的服務(wù)領(lǐng)域中開發(fā)。未來,一輛既便宜、又智能的“溫馨智能移動(dòng)起居室”指日可待。