汽车服务架构(SOA)开发设计
目錄
汽車服務(wù)架構(gòu)(SOA)開發(fā)設(shè)計(jì)
1.什么是SOA
1.1 SOA優(yōu)缺點(diǎn)
1.2 SOA 應(yīng)用優(yōu)勢(shì)
1.3 服務(wù)的基本結(jié)構(gòu)
1.4 SOA架構(gòu)的核心要素
1.5 SOA服務(wù)架構(gòu)開發(fā)趨勢(shì)
1.6 SOA與E/E架構(gòu)
1.6.1 域控制為核心的架構(gòu)
1.6.2 區(qū)域控制為核心的SOA架構(gòu)
1.7 以服務(wù)為核心的SOA開發(fā)思路
1.7.1 AP（Adaptive Platform）的開發(fā)
a. 定義服務(wù)內(nèi)容
b. 定義服務(wù)接口
c. 配置服務(wù)關(guān)系
d. 通訊協(xié)議設(shè)計(jì)
2. SOA設(shè)計(jì)
2.1 ?SOA 設(shè)計(jì)原則
2.2 ?服務(wù)構(gòu)件與傳統(tǒng)構(gòu)件
2.3 ?關(guān)鍵技術(shù)
2.3.1 ?UDDI?
2.3.2 WSDL?
2.3.3 SOAP
2.3.4 REST?
2.3.5 ESB
2.4 SOA實(shí)現(xiàn)
2.4.1 ?Web Service
2.4.2 服務(wù)注冊(cè)表
2.4.3 企業(yè)服務(wù)總線
2.5 SOA實(shí)現(xiàn)基礎(chǔ)
2.6 開發(fā)流程
2.7 開發(fā)工具鏈
2.8 SOA的應(yīng)用實(shí)例
3. 汽車SOA開發(fā)
3.1面向服務(wù)架構(gòu)的汽車軟件及開發(fā)方法
3.1.1 如何分析和設(shè)計(jì)服務(wù)架構(gòu)
3.1.2 如何建模和記錄面向服務(wù)的架構(gòu)
3.1.3 如何部署和實(shí)現(xiàn)面向服務(wù)的軟件
3.1.4 SOA汽車軟件創(chuàng)新平臺(tái)
3.2 面向服務(wù)架構(gòu)的汽車軟件分析和設(shè)計(jì)
3.2.1 系統(tǒng)需求分析
3.2.2 系統(tǒng)功能分析
3.2.3 候選服務(wù)分析
3.2.4 系統(tǒng)架構(gòu)設(shè)計(jì)
3.2.5 軟件架構(gòu)設(shè)計(jì)
3.3 面向服務(wù)架構(gòu)（SOA）的汽車軟件實(shí)現(xiàn)和部署
3.3.1 滿足 SOA 架構(gòu)的服務(wù)組件架構(gòu)SCA
(Service-Component-Architecture)
3.3.2 服務(wù)組件架構(gòu)SCA的配置描述
3.3.3 汽車SOA軟件的實(shí)現(xiàn)方案
3.3.4 SOA服務(wù)組件實(shí)現(xiàn)和部署的具體步驟
3.4 核心模型設(shè)計(jì)
3.5 圖表設(shè)計(jì)
3.6 服務(wù)設(shè)計(jì)
3.7 AP平臺(tái)SOA相關(guān)技術(shù)規(guī)范概述
4. SOA流程開發(fā)在自動(dòng)駕駛車企中布局
5. 企業(yè)管理開發(fā)流程與SOA軟件架構(gòu)開發(fā)之間的關(guān)系
6. SOA的兩種不同開發(fā)模式原理
6.1業(yè)務(wù)驅(qū)動(dòng)型開發(fā)
6.2平臺(tái)驅(qū)動(dòng)型開發(fā)
7. 基于AUTOSAR的SOA開發(fā)
7.1 基于AUTOSAR的SOA軟件架構(gòu)
7.2 基于SOA構(gòu)建軟件設(shè)計(jì)方法
7.3 系統(tǒng)架構(gòu)-虛擬功能總線
7.4 SOA軟件分層
7.4.1 應(yīng)用軟件
7.4.2 實(shí)時(shí)運(yùn)行環(huán)境
7.4.3 基礎(chǔ)軟件
7.5 基于AUTOSAR的SOA服務(wù)
7.6 硬件抽象
7.7 基于AUTOSAR的SOA系統(tǒng)配置
8.總結(jié)
1.什么是SOA
SOA (服務(wù)導(dǎo)向架構(gòu)，Service Oriented Architecture)??作為一種架構(gòu)范式，展示了技術(shù)中立的最佳實(shí)踐。其建立在標(biāo)準(zhǔn)之上，可在供應(yīng)商的廣泛支持下在全球范圍內(nèi)實(shí)現(xiàn)經(jīng)濟(jì)高效的實(shí)施。以在企業(yè)內(nèi)部和跨企業(yè)創(chuàng)建新業(yè)務(wù)功能方面重用和重新組合服務(wù)，SOA很好的做到了“粗粒度”和“松散耦合”的特點(diǎn)，相較于當(dāng)前分布式物理架構(gòu)具有更大的靈活性。SOA 最佳實(shí)踐創(chuàng)建包含業(yè)務(wù)流程的設(shè)計(jì)?—— 并增強(qiáng)將流程外包和擴(kuò)展給業(yè)務(wù)合作伙伴的能力。此外，SOA也可以復(fù)用已有的系統(tǒng)和流程，與傳統(tǒng)的基于孤島的應(yīng)用程序開發(fā)更具戰(zhàn)術(shù)性的本質(zhì)形成對(duì)比，可以保留和增強(qiáng)現(xiàn)有投資承建的架構(gòu)、軟件等實(shí)現(xiàn)的部分有用性。
1.1 SOA優(yōu)缺點(diǎn)
優(yōu)點(diǎn)：
缺點(diǎn)：
1.2 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á)。
1.3 服務(wù)的基本結(jié)構(gòu)
獨(dú)立的服務(wù)結(jié)構(gòu)如下圖
服務(wù)模型的表示層從邏輯層分離出來，增加了服務(wù)對(duì)外的接口層。通過對(duì)服務(wù)接口的標(biāo)準(zhǔn)化描述，使得服務(wù)可以提供給在任何異構(gòu)平臺(tái)和任何用戶接口使用。這允許并支持基于服務(wù)的系統(tǒng)成為松散耦合、面向構(gòu)件和跨技術(shù)實(shí)現(xiàn)，服務(wù)請(qǐng)求者很可能根本不知道服務(wù)在哪里運(yùn)行、是由哪種語言編寫的，以及消息的傳輸路徑，而是只需要提出服務(wù)請(qǐng)求，然后就會(huì)得到答案。
1.4 SOA架構(gòu)的核心要素
要準(zhǔn)確全面理解SOA，首先必須理解SOA的核心要素：
SOA的目標(biāo)就是實(shí)現(xiàn)靈活可變的IT系統(tǒng)。要達(dá)到靈活性，通過三個(gè)途徑來解決：標(biāo)準(zhǔn)化封裝、復(fù)用、松耦合可編排。
互操作(標(biāo)準(zhǔn)化封裝)、復(fù)用、松耦合等SOA技術(shù)的內(nèi)在機(jī)制，也是中間件技術(shù)和產(chǎn)品的本質(zhì)特征。
標(biāo)準(zhǔn)化封裝（互操作性）
傳統(tǒng)軟件架構(gòu)，因?yàn)榉庋b的技術(shù)和平臺(tái)依賴性，一直沒有徹底解決互操作問題。互聯(lián)網(wǎng)前所未有的開放性意味著各節(jié)點(diǎn)可能 采用不同的組件、平臺(tái)技術(shù)，對(duì)技術(shù)細(xì)節(jié)進(jìn) 行了私有化的約束，構(gòu)件模型和架構(gòu)沒有統(tǒng)一標(biāo)準(zhǔn)，從而導(dǎo)致架構(gòu)平臺(tái)自身在組件描述、發(fā)布、發(fā)現(xiàn)、調(diào)用、互操作協(xié)議及數(shù)據(jù)傳輸?shù)确矫娉尸F(xiàn)出巨大的異構(gòu)性。各種不良技術(shù)約束的結(jié)果是軟件系統(tǒng)跨互 聯(lián)網(wǎng)進(jìn)行交互變得困難重重，最終導(dǎo)致了跨企業(yè)/部門的業(yè)務(wù)集成和重組難以靈活快速的進(jìn)行。
在軟件的互操作方面，傳統(tǒng)中間件只是實(shí)現(xiàn)了訪問互操作，即通過標(biāo)準(zhǔn)化的API實(shí)現(xiàn)了同類系統(tǒng)之間的調(diào)用互操作，而連接互 操作還是依賴于特定的訪問協(xié)議，如JAVA使用RMI，CORBA使用IIOP等。而SOA通過標(biāo)準(zhǔn)的、支持Internet、與操作系統(tǒng)無 關(guān)的SOAP協(xié)議實(shí)現(xiàn)了連接互操作。而且，服務(wù)的封裝是采用XML協(xié)議，具有自解析和自定義的特性，這樣，基于SOA的中間 件還可以實(shí)現(xiàn)語義互操作。
SOA要實(shí)現(xiàn)互操作，就是通過一系列的標(biāo)準(zhǔn)族，來實(shí)現(xiàn)訪問、連接和語義等各種層面的互操作。
軟件復(fù)用
軟件復(fù)用，即軟件的重用，也叫再用，是指同一事物不作修改或稍加改動(dòng)就多次重復(fù)使用。從軟件復(fù)用技術(shù)的發(fā)展來看，就 是不斷提升抽象級(jí)別，擴(kuò)大復(fù)用范圍。最早 的復(fù)用技術(shù)是子程序，人們發(fā)明子程序，就可以在不同系統(tǒng)之間進(jìn)行復(fù)用了。但 是，子程序是最原始的復(fù)用，因?yàn)檫@種復(fù)用范圍是一個(gè)可執(zhí)行程序內(nèi)復(fù)用，靜態(tài)開發(fā) 期復(fù)用，如果子程序修改，意味著所有 調(diào)用這個(gè)子程序的系統(tǒng)必須重新編譯、測(cè)試和發(fā)布。
SOA的復(fù)用
為了解決這個(gè)問題，人們發(fā)明了組件（或者叫控件），如MS操作系統(tǒng)下的DLL組件。組件將復(fù)用提升了一個(gè)層次，因?yàn)榻M件可以在一個(gè)系統(tǒng)內(nèi)復(fù)用（同一種操作系統(tǒng)），而且是動(dòng)態(tài)、運(yùn)行期復(fù)用。這樣組件可以單獨(dú)發(fā)展，組件與組件調(diào)用者之間的耦合度降低。
為解決分布式網(wǎng)絡(luò)計(jì)算之間的組件復(fù)用，人們發(fā)明了企業(yè)對(duì)象組件，如（Com+,.NET,EJB等)，或者叫分布式組件。通過遠(yuǎn)程對(duì)象代理，來實(shí)現(xiàn)企業(yè)網(wǎng)絡(luò)內(nèi)復(fù)用，不同系統(tǒng)之間復(fù)用。
傳統(tǒng)架構(gòu)的核心是組件對(duì)象的管理。但分布式組件也是嚴(yán)重依賴其計(jì)算環(huán)境，由于構(gòu)件實(shí)現(xiàn)和運(yùn)行支撐技術(shù)之間存在著較大的 異構(gòu)性，不同技術(shù)設(shè)計(jì)和實(shí)現(xiàn)的構(gòu)件之間無法直接組裝式復(fù)用。
而現(xiàn)代SOA的重要特征就是以服務(wù)為核心，如WebService,SCA/SDO等。通過服務(wù)，或者服務(wù)組件來實(shí)現(xiàn)更高層次的復(fù)用、 解耦和互操作，即SOA架構(gòu)中間件。
因?yàn)榉?wù)是通過標(biāo)準(zhǔn)封裝，服務(wù)組件之間的組裝、編排和重組，來實(shí)現(xiàn)服務(wù)的復(fù)用。而且這種復(fù)用，可以在不同企業(yè)之間，全球復(fù)用，達(dá)到復(fù)用的最高級(jí)別，并且是動(dòng)態(tài)可配置的復(fù)用。
耦合關(guān)系
SOA架構(gòu)在松耦合解耦過程也發(fā)展到了最后的境界。傳統(tǒng)軟件將軟件之中核心三部分網(wǎng)絡(luò)連接、數(shù)據(jù)轉(zhuǎn)換、業(yè)務(wù)邏輯全部耦 合在一個(gè)整體之中，形成“鐵板一塊”的軟件， “牽一發(fā)而動(dòng)全身”，軟件就難以適應(yīng)變化。分布式對(duì)象技術(shù)將連接邏輯進(jìn)行分 離，消息中間件將連接邏輯進(jìn)行異步處理，增加了更大的靈活性。消息代理和一些分 布式對(duì)象中間件將數(shù)據(jù)轉(zhuǎn)換也進(jìn)行了分 離。而SOA架構(gòu)，通過服務(wù)的封裝，實(shí)現(xiàn)了業(yè)務(wù)邏輯與網(wǎng)絡(luò)連接、數(shù)據(jù)轉(zhuǎn)換等進(jìn)行完全的解耦。
SOA不斷解耦的過程
總之，從科學(xué)哲學(xué)的角度來看，SOA是一個(gè)不斷解構(gòu)的過程，傳統(tǒng)軟件強(qiáng)調(diào)系統(tǒng)性，耦合度過高，所以需要松耦合（解耦）；SOA也是一個(gè)組件粒度的平衡，集成電路趨勢(shì)是集成度越來越高，軟件發(fā)展的趨勢(shì)是相反的過程；SOA是架構(gòu)，更是 方法，反映了人們對(duì)哲學(xué)思想的追求的原動(dòng)力。
按照這個(gè)特性，SOA基本上來說與WebService并不是同一個(gè)概念，SOA并不一定需要WebService實(shí)現(xiàn)，理論上可以在其他技 術(shù)體系下，實(shí)現(xiàn)SOA。但事實(shí)上，到目前為止，能夠?qū)崿F(xiàn)SOA架構(gòu)風(fēng)格的技術(shù)就是WebService，因?yàn)樗奶匦院蛷S商的支持 力度，使得WebService成為了實(shí)現(xiàn)SOA實(shí)現(xiàn)技術(shù)的事實(shí)標(biāo)準(zhǔn)。也正因?yàn)閃ebService技術(shù)的成熟，才使得已經(jīng)提出10多年了的 SOA思想和概念，得以能夠?qū)崿F(xiàn)落地，成為一種可以使用的技術(shù)。這也就是回答了SOA和WebService的關(guān)系。
1.5 SOA服務(wù)架構(gòu)開發(fā)趨勢(shì)
傳統(tǒng)汽車使用由上百個(gè)ECU組成的分布式EE架構(gòu)，OEM定義對(duì)各ECU的功能需求，由不同供應(yīng)商負(fù)責(zé)最終功能實(shí)現(xiàn)。這種架構(gòu)導(dǎo)致大量功能控制邏輯在子節(jié)點(diǎn)ECU內(nèi)部完成，傳感器、執(zhí)行器信號(hào)被掩埋在分布網(wǎng)絡(luò)下，僅通過在局部網(wǎng)絡(luò)的ECU部署基于服務(wù)的通訊，無法實(shí)現(xiàn)對(duì)整車硬件能力的充分暴露。且考慮到基于SOA軟件平臺(tái)，未來SOP后的車型也需具備硬件冗余能力以應(yīng)對(duì)OTA軟件升級(jí)，上百個(gè)ECU的冗余設(shè)計(jì)將極大增加成本支出，也導(dǎo)致跨域功能OTA的實(shí)現(xiàn)將涉及數(shù)量眾多的ECU。
???隨著車載芯片算力的提升和高帶寬、低時(shí)延車載以太網(wǎng)通訊技術(shù)的落地，EE架構(gòu)已從分布式演進(jìn)至域集中 (Domain Centralized)，并向整車集中＋區(qū)域 (Vehicle Computer & Zonal)、整車集中 (Vehicle Centralized)不斷進(jìn)化。在高集成度的EE架構(gòu)下，域控制器將承擔(dān)整車主要邏輯，而執(zhí)行器、傳感器將成為純粹的執(zhí)行機(jī)構(gòu)，執(zhí)行控制命令或是提供環(huán)境感知數(shù)據(jù)。
???基于整車集中EE架構(gòu)的“硬地基”， SOA在域控制器上的部署才能夠?qū)崿F(xiàn)整車能力的資源獲取，并將其封裝為標(biāo)準(zhǔn)的服務(wù)和接口向應(yīng)用層開放。
1.6 SOA與E/E架構(gòu)
1.6.1 域控制為核心的架構(gòu)
電子電氣架構(gòu)的概念從總線引入汽車開始就不斷更新和演化，如今一套完整的整車數(shù)字架構(gòu)所考慮的內(nèi)容除了傳統(tǒng)的拓?fù)洹⒕W(wǎng)絡(luò)、線束與電氣分配、邏輯功能分配，還需結(jié)合整車的功能/信息安全架構(gòu)、數(shù)據(jù)架構(gòu)、計(jì)算架構(gòu)，以及實(shí)現(xiàn)通訊架構(gòu)與軟件架構(gòu)的協(xié)同，功能架構(gòu)與服務(wù)架構(gòu)的協(xié)同，車內(nèi)服務(wù)與云端服務(wù)的協(xié)同。
如圖所示：域集中架構(gòu)在連接上由功能域控制器，分別通過子網(wǎng)與各功能域內(nèi)ECU相連接，而域控制器之間則修建通訊“高速公路”，通過高帶寬的骨干網(wǎng)絡(luò)相連。拓?fù)浣Y(jié)構(gòu)只是架構(gòu)的表象，而表象背后的核心特征是功能邏輯被抽象上移至功能域控制器中。每個(gè)域控制器有對(duì)應(yīng)的集成的（Signal to Services）, 在域控制器中進(jìn)行功能的分配、功能的集成。而某個(gè)域控制器作為云端鏈接的橋梁，將平行的幾個(gè)域控制器的邏輯運(yùn)算功能輸入到云端。功能邏輯運(yùn)算服務(wù)的重心在域控制器中。
1.6.2 區(qū)域控制為核心的SOA架構(gòu)
如圖所示：整車集中和區(qū)域架構(gòu)在連接上是通過分布在車內(nèi)各物理區(qū)域的區(qū)域網(wǎng)關(guān)/控制器將車內(nèi)物理I/O分別就近連接和控制，形成整車數(shù)字系統(tǒng)的“手”和“腳”，然后通過骨干網(wǎng)絡(luò)與系統(tǒng)中的“大腦”控制單元進(jìn)行連接。連接關(guān)系同樣只是表象，而核心價(jià)值在于將車內(nèi)軟件（運(yùn)算）和硬件解耦，徹底實(shí)現(xiàn)軟件獨(dú)立“生長(zhǎng)”（或者說算力架構(gòu)可以迭代，共享算力變成了可能），而硬件同樣可以獨(dú)立“生長(zhǎng)”（跨車型平臺(tái)，或者在車輛生命周期內(nèi)為用戶提供升級(jí)服務(wù)，而這些在傳統(tǒng)架構(gòu)中實(shí)現(xiàn)的成本是不可控的）。
1.7 以服務(wù)為核心的SOA開發(fā)思路
雖然電子電氣架構(gòu)開發(fā)從理論上是正向開發(fā)，但實(shí)際上一款車型的開發(fā)并不是完全從零開始的，很多功能方案會(huì)沿用老款車型。這樣的后果是，系統(tǒng)和軟件模塊已經(jīng)固定，即無法通過正向設(shè)計(jì)的思路拆解邏輯，設(shè)計(jì)服務(wù)。考慮這種情況，服務(wù)設(shè)計(jì)可以分為以下兩種方法。
(1)自下而上的方法
適用于現(xiàn)有平臺(tái)上已實(shí)現(xiàn)的功能或系統(tǒng)。此種方法的基礎(chǔ)是，功能的網(wǎng)絡(luò)分配，通信，ECU軟件架構(gòu)，功能規(guī)范和使用場(chǎng)景等都已經(jīng)有明確定義。我們可以利用現(xiàn)有的這些輸入，完成將原有功能對(duì)SOA的轉(zhuǎn)換。
適用功能和系統(tǒng)：
(2)自上而下的方法
自上而下的方法即為正向設(shè)計(jì)方法。在基于SOA的電子電氣架構(gòu)開發(fā)中，對(duì)于復(fù)雜功能，或者引入到平臺(tái)中的新功能和新系統(tǒng)，必須遵循這種方法完成服務(wù)設(shè)計(jì)。基于上述所介紹的開發(fā)流程，從需求出發(fā)，進(jìn)行邏輯拆解，服務(wù)拆解，軟件架構(gòu)搭建，系統(tǒng)設(shè)計(jì)等。這個(gè)方法所依賴的輸入一般是功能需求表和用戶場(chǎng)景。
不管使用哪種方法，通常服務(wù)的設(shè)計(jì)是在單個(gè)功能或系統(tǒng)級(jí)別定義的，最后需要架構(gòu)師綜合考慮整車系統(tǒng)，將高度復(fù)用性的服務(wù)歸類為平臺(tái)級(jí)通用服務(wù)。通用服務(wù)池子是“生態(tài)共創(chuàng)”的基礎(chǔ)。
服務(wù)的分類：
服務(wù)設(shè)計(jì)的輸入要求：
(1)應(yīng)用級(jí)別的服務(wù)
(2)平臺(tái)級(jí)別的服務(wù)
因此，服務(wù)設(shè)計(jì)的輸出主要為：
(1)服務(wù)的定義
對(duì)應(yīng)的輸出文檔可以分為：
1.7.1 AP（Adaptive Platform）的開發(fā)
a. 定義服務(wù)內(nèi)容
此步驟實(shí)際上就是搭建了一個(gè)系統(tǒng)功能架構(gòu)，從整車層面即是按照功能需求定義并劃分服務(wù)。對(duì)于SOA中的服務(wù)表示了一種獨(dú)立的功能單元，一個(gè)服務(wù)可以包含其他子服務(wù)單元，使用標(biāo)準(zhǔn)接口進(jìn)行通訊，將內(nèi)部信息封裝成一個(gè)黑盒子，實(shí)現(xiàn)子服務(wù)的重用性。上層服務(wù)可以通過該標(biāo)準(zhǔn)接口調(diào)用下層服務(wù)封裝的子服務(wù)內(nèi)容。同時(shí)，整體的服務(wù)內(nèi)容可以被操控單元遠(yuǎn)程訪問和獨(dú)立更改或更新。同時(shí)，對(duì)于SOA來說，需要通過服務(wù)編排來定義清楚服務(wù)之間的相互關(guān)系。
簡(jiǎn)單地說服務(wù)對(duì)于智能駕駛汽車而言就是定義產(chǎn)品，對(duì)其中產(chǎn)品的能力進(jìn)行描述，這里的產(chǎn)品能力我們稱之為PC（Product Capability）。實(shí)現(xiàn)這種產(chǎn)品能力需要從下至上定義硬件抽象服務(wù)、平臺(tái)核心服務(wù)、域核心服務(wù)、應(yīng)用程序服務(wù)。而每一個(gè)服務(wù)內(nèi)容對(duì)應(yīng)著一個(gè)或多個(gè)實(shí)現(xiàn)的軟件模塊，這里我們稱之為SWC（Software Capability）
產(chǎn)品能力 (PC) 描述了系統(tǒng)所需的一些高級(jí)功能。區(qū)別于系統(tǒng)設(shè)計(jì)，PC是用來分配職責(zé)的，所以很清楚哪個(gè)SWC Module軟件模塊（如攝像頭識(shí)別模塊、雷達(dá)識(shí)別模塊、中央域控制器模塊）應(yīng)該實(shí)現(xiàn)什么。它們?cè)诠δ茉O(shè)計(jì)時(shí)由功能負(fù)責(zé)人識(shí)別和請(qǐng)求。一些系統(tǒng)相關(guān)的PC也可以由系統(tǒng)架構(gòu)師或模塊負(fù)責(zé)人直接識(shí)別，在模塊架構(gòu)工作中映射PC時(shí)，模塊所有者還可以確定對(duì)更多 PC 的需求。
在確定并決定添加?PC?后，對(duì)應(yīng)的軟件模塊擁有該?PC，模塊所有者負(fù)責(zé)將其實(shí)施到正確的版本，并在平臺(tái)的整個(gè)生命周期內(nèi)維護(hù)/發(fā)展?PC。
b. 定義服務(wù)接口
????服務(wù)接口是一種通信內(nèi)容定義，其目的在于將服務(wù)從功能架構(gòu)過渡到軟件技術(shù)架構(gòu)，且軟件模塊之間的關(guān)系需要被清晰的定義出來，過程中將服務(wù)內(nèi)容封裝成相應(yīng)的接口被實(shí)際調(diào)用。這種接口定義是獨(dú)立于通信協(xié)議的抽象實(shí)體，這種接口可以建立任何兩個(gè)服務(wù)間的通信能力，而使用合適的工具鏈可以由此生成基于特定協(xié)議的接口。
服務(wù)接口可分為方法（Method）、屬性（Property）、事件（Event）三種類型。以智能駕駛的一個(gè)子功能執(zhí)行接口服務(wù)為例，假設(shè)需要獲取攝像頭傳感器探測(cè)的環(huán)境數(shù)據(jù)，而需要進(jìn)行定義的服務(wù)接口中方法是要對(duì)傳感器的參數(shù)進(jìn)行后融合，那么就需要其底層服務(wù)提供攝像頭處理的基礎(chǔ)函數(shù)（如ISP、深度學(xué)習(xí)函數(shù)、BEV函數(shù)等）。而服務(wù)接口的屬性則是通過一定的方法操作（如get/set）來獲取該服務(wù)函數(shù)，這種服務(wù)屬性可以對(duì)上層調(diào)用的服務(wù)部分可見，底層服務(wù)有變動(dòng)上層的調(diào)用方式也會(huì)隨之變動(dòng)，這種變動(dòng)所帶來的更新會(huì)由服務(wù)底層決定何時(shí)發(fā)送給上層調(diào)用它的服務(wù)單元。
服務(wù)接口定義完整后，開發(fā)人員可以根據(jù)該接口定義對(duì)其中的函數(shù)進(jìn)行定義開發(fā)了。
c. 配置服務(wù)關(guān)系
????此過程會(huì)建立軟硬件之間的映射關(guān)系，實(shí)現(xiàn)從抽象的服務(wù)定義到軟件層面的推導(dǎo)，從而方便實(shí)現(xiàn)軟件驅(qū)動(dòng)或調(diào)用硬件實(shí)現(xiàn)單元，這種結(jié)果是實(shí)現(xiàn)服務(wù)與中間件或底層硬件ECU之間的映射關(guān)系。從整個(gè)SOA的架構(gòu)模型中我們知道服務(wù)需要從通用服務(wù)平臺(tái)開始進(jìn)行底層驅(qū)動(dòng)，然后對(duì)上層傳感器執(zhí)行器的控制管理進(jìn)行驅(qū)動(dòng)。由于AP直接支持服務(wù)接口，可以直接面向上層應(yīng)用層，CP仍然是對(duì)常用的底層應(yīng)用服務(wù)的驅(qū)動(dòng)映射，因此，兩層驅(qū)動(dòng)分別對(duì)應(yīng)著經(jīng)典的CP Autosar中間件調(diào)用和AP Autosar模式。
d. 通訊協(xié)議設(shè)計(jì)
????智能網(wǎng)聯(lián)汽車的SOA架構(gòu)設(shè)計(jì)需要強(qiáng)大的環(huán)境感知、信息處理、實(shí)施決策、控制能力可以把智能交通、地圖、定位、通訊、云、大數(shù)據(jù)等進(jìn)行系統(tǒng)集成，故車端與云端、車輛與車輛之間、車輛內(nèi)部的各個(gè)ECU之間通信的速率和數(shù)據(jù)量都比傳統(tǒng)汽車高出幾個(gè)數(shù)量級(jí)，這些需要由多種復(fù)雜的硬件、軟件和高速通信總線共同實(shí)現(xiàn)，并在很大程度上決定智能汽車的功能實(shí)現(xiàn)和擴(kuò)展的可靠性。車載以太網(wǎng)能夠很好的解決大數(shù)據(jù)量的信息交互，整個(gè)通信協(xié)議的定義包括虛擬以太網(wǎng)VLAN，以太網(wǎng)交換機(jī)Switch，套接字Socket，基于IP的可擴(kuò)展面向服務(wù)的中間件SOME/IP，SD等。而基于AVB的下一代協(xié)議TSN（時(shí)間敏感網(wǎng)絡(luò)）可以提供非常優(yōu)秀的實(shí)時(shí)性。
????以太網(wǎng)通訊設(shè)計(jì)過程包含對(duì)服務(wù)實(shí)例進(jìn)行通訊協(xié)議相關(guān)的信息配置。由于SOA架構(gòu)中包含多個(gè)應(yīng)用實(shí)體之間的多通路通信過程，且這些通信通常是網(wǎng)狀通信，因此需要在各個(gè)實(shí)體節(jié)點(diǎn)之間建立中間路由、轉(zhuǎn)化等。區(qū)別于傳統(tǒng)總線（Can/Lin），在軟件架構(gòu)設(shè)計(jì)過程中，開發(fā)人員需要設(shè)計(jì)具體的服務(wù)類型、服務(wù)ID、服務(wù)數(shù)據(jù)類型、服務(wù)角色等。
詳細(xì)內(nèi)容見下面鏈接：
汽車服務(wù)架構(gòu)（SOA）開發(fā)設(shè)計(jì)https://download.csdn.net/download/ChrisKKC/82048291
【積分下載】軟件定義汽車服務(wù)API-第一部分：原子服務(wù)API參考https://download.csdn.net/download/ChrisKKC/85089142【積分下載】軟件定義汽車服務(wù)API-第一部分：原子服務(wù)API參考 變更說明https://download.csdn.net/download/ChrisKKC/85089150【積分下載】軟件定義汽車服務(wù)API-第二部分：設(shè)備抽象API參考https://download.csdn.net/download/ChrisKKC/85089177【積分下載】軟件定義汽車服務(wù)API-第二部分：設(shè)備抽象API參考變更說明1、軟件定義汽車服務(wù)2、SOA架構(gòu)3、API接口參考4、設(shè)備抽象API5、變更說明更多下載資源、學(xué)習(xí)資料請(qǐng)?jiān)L問CSDN下載頻道.https://download.csdn.net/download/ChrisKKC/85089158
總結(jié)
以上是生活随笔為你收集整理的汽车服务架构(SOA)开发设计的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： linux curl模拟登录网页
- 下一篇： Quartz2 定时器 《一》（概述）