點(diǎn)擊上方藍(lán)字談思實(shí)驗(yàn)室
獲取更多汽車網(wǎng)絡(luò)安全資訊
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)
CAN總線通訊是我們每天都會(huì)使用的工業(yè)通訊總線，工程師經(jīng)常會(huì)遇到各種由于CAN總線通訊異常導(dǎo)致的問題。這篇文章將會(huì)帶您了解怎么進(jìn)行新能源汽車CAN總線的故障定位與干擾排除。
優(yōu)點(diǎn)：
擴(kuò)展方便：可針對(duì)單個(gè)服務(wù)提供資源擴(kuò)展
語(yǔ)言通用：接口通用，服務(wù)可以基于任何語(yǔ)言
新人友好：?jiǎn)我荒K服務(wù)理解透徹即可服務(wù)此模塊，不必理會(huì)架構(gòu)
發(fā)版方便：可更新單一模塊，不影響架構(gòu)
缺點(diǎn)：
問題排查不便：功能調(diào)用服務(wù)多，很難直接定位問題點(diǎn)
溝通不便：模塊獨(dú)立，不確定其他模塊狀態(tài)
性能問題：通信時(shí)間損耗
關(guān)系混亂：服務(wù)越來(lái)越多，調(diào)用方越來(lái)越多的時(shí)候，就會(huì)比較混亂
運(yùn)維難度：隨著服務(wù)的增多，系統(tǒng)架構(gòu)會(huì)越發(fā)復(fù)雜，這就給運(yùn)維層面帶來(lái)了挑戰(zhàn)
數(shù)據(jù)一致性問題：?jiǎn)误w項(xiàng)目因?yàn)閿?shù)據(jù)都在同一個(gè)數(shù)據(jù)庫(kù)里面，不需要過多的關(guān)注分布式事務(wù)等問題，SOA就需要關(guā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í)帶來(lái)的復(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)接口集成，而無(wú)需各個(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ù)模型的表示層從邏輯層分離出來(lái)，增加了服務(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)行、是由哪種語(yǔ)言編寫的，以及消息的傳輸路徑，而是只需要提出服務(wù)請(qǐng)求，然后就會(huì)得到答案。
1.4 SOA架構(gòu)的核心要素
要準(zhǔn)確全面理解SOA，首先必須理解SOA的核心要素：
SOA的目標(biāo)就是實(shí)現(xiàn)靈活可變的IT系統(tǒng)。要達(dá)到靈活性，通過三個(gè)途徑來(lái)解決：標(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)無(wú) 關(guān)的SOAP協(xié)議實(shí)現(xiàn)了連接互操作。而且，服務(wù)的封裝是采用XML協(xié)議，具有自解析和自定義的特性，這樣，基于SOA的中間 件還可以實(shí)現(xiàn)語(yǔ)義互操作。
SOA要實(shí)現(xiàn)互操作，就是通過一系列的標(biāo)準(zhǔn)族，來(lái)實(shí)現(xiàn)訪問、連接和語(yǔ)義等各種層面的互操作。
軟件復(fù)用
軟件復(fù)用，即軟件的重用，也叫再用，是指同一事物不作修改或稍加改動(dòng)就多次重復(fù)使用。從軟件復(fù)用技術(shù)的發(fā)展來(lái)看，就 是不斷提升抽象級(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ì)象代理，來(lái)實(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)件之間無(wú)法直接組裝式復(fù)用。
而現(xiàn)代SOA的重要特征就是以服務(wù)為核心，如WebService,SCA/SDO等。通過服務(wù)，或者服務(wù)組件來(lái)實(shí)現(xiàn)更高層次的復(fù)用、 解耦和互操作，即SOA架構(gòu)中間件。
因?yàn)榉?wù)是通過標(biāo)準(zhǔn)封裝，服務(wù)組件之間的組裝、編排和重組，來(lái)實(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é)的角度來(lái)看，SOA是一個(gè)不斷解構(gòu)的過程，傳統(tǒng)軟件強(qiáng)調(diào)系統(tǒng)性，耦合度過高，所以需要松耦合（解耦）；SOA也是一個(gè)組件粒度的平衡，集成電路趨勢(shì)是集成度越來(lái)越高，軟件發(fā)展的趨勢(shì)是相反的過程；SOA是架構(gòu)，更是 方法，反映了人們對(duì)哲學(xué)思想的追求的原動(dòng)力。
按照這個(gè)特性，SOA基本上來(lái)說(shuō)與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ù)的通訊，無(wú)法實(shí)現(xiàn)對(duì)整車硬件能力的充分暴露。且考慮到基于SOA軟件平臺(tái)，未來(lá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)”（或者說(shuō)算力架構(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)固定，即無(wú)法通過正向設(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)：
車身舒適的大部分功能，如車門，車窗，座椅，空調(diào)等，功能邏輯沒有太大爭(zhēng)議，就可以通過現(xiàn)有子系統(tǒng)規(guī)范和網(wǎng)絡(luò)信號(hào)清單，進(jìn)行服務(wù)接口設(shè)計(jì)。
動(dòng)力和底盤系統(tǒng)。這是整車中對(duì)安全要求最高的兩個(gè)系統(tǒng)，因此一般來(lái)說(shuō)，我們?cè)谠O(shè)計(jì)第一代SOA架構(gòu)時(shí)。這兩個(gè)系統(tǒng)更適合自下而上的方法，通過對(duì)已有功能的提取，轉(zhuǎn)換為服務(wù)接口，接入整車服務(wù)系統(tǒng)。
傳感器和執(zhí)行器資源。汽車上的每個(gè)元件都代表了一種基礎(chǔ)能力。基于整車傳感器和執(zhí)行器清單，能夠快速形成一份基礎(chǔ)服務(wù)清單。由此出發(fā)，再通過功能梳理，層層往上，可以形成更加豐富多層次的服務(wù)列表。
(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ù)根據(jù)ECU的功能和硬件外圍設(shè)備（傳感器和執(zhí)行器），定義硬件抽象服務(wù)。這些服務(wù)同時(shí)屬于平臺(tái)級(jí)核心服務(wù)。示例：Camera interface，Rain sensor interface
平臺(tái)級(jí)核心服務(wù)在應(yīng)用程序集群和域之間通用的所有服務(wù)。示例：Power mode，Vehicle speed，Key status
域級(jí)核心服務(wù)在域內(nèi)的應(yīng)用程序集群內(nèi)不同應(yīng)用程序之間通用的服務(wù)。示例：Front vehicle distance calculate，F(xiàn)ront obstacles
應(yīng)用服務(wù)為每個(gè)特定的應(yīng)用程序或系統(tǒng)功能服務(wù)的服務(wù)。示例：Enable ACC，AEB system status
服務(wù)設(shè)計(jì)的輸入要求：
(1)應(yīng)用級(jí)別的服務(wù)
功能和系統(tǒng)描述，用戶場(chǎng)景描述
功能和系統(tǒng)需求
功能和系統(tǒng)邏輯架構(gòu)
(2)平臺(tái)級(jí)別的服務(wù)
跨域的系統(tǒng)設(shè)計(jì)文檔
跨域的功能清單
網(wǎng)絡(luò)拓?fù)?/p>
傳感器和執(zhí)行器列表（用于提取硬件抽象服務(wù)）
因此，服務(wù)設(shè)計(jì)的輸出主要為：
(1)服務(wù)的定義
服務(wù)接口的定義
服務(wù)提供方和消費(fèi)方信息
軟件模塊信息
對(duì)應(yīng)的輸出文檔可以分為：
服務(wù)定義矩陣
服務(wù)詳細(xì)設(shè)計(jì)文檔（包含軟件實(shí)現(xiàn)信息）
服務(wù)數(shù)據(jù)庫(kù)ARXML（涵蓋通訊、服務(wù)、軟件部署等信息）
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來(lái)說(shuō)，需要通過服務(wù)編排來(lái)定義清楚服務(wù)之間的相互關(guān)系。
簡(jiǎn)單地說(shuō)服務(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是用來(lái)分配職責(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)系需要被清晰的定義出來(lái)，過程中將服務(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）來(lái)獲取該服務(wù)函數(shù)，這種服務(wù)屬性可以對(duì)上層調(diào)用的服務(wù)部分可見，底層服務(wù)有變動(dòng)上層的調(diào)用方式也會(huì)隨之變動(dòng)，這種變動(dòng)所帶來(lái)的更新會(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ù)角色等。
來(lái)源：CSDN@不懂汽車的胖子
https://blog.csdn.net/ChrisKKC/article/details/123094116
?end?
?專業(yè)社群?
?精品活動(dòng)推薦?
更多文章
關(guān)于涉嫌仿冒AutoSec會(huì)議品牌的律師聲明
一文帶你了解智能汽車車載網(wǎng)絡(luò)通信安全架構(gòu)
網(wǎng)絡(luò)安全：TARA方法、工具與案例
汽車數(shù)據(jù)安全合規(guī)重點(diǎn)分析
淺析汽車芯片信息安全之安全啟動(dòng)
域集中式架構(gòu)的汽車車載通信安全方案探究
系統(tǒng)安全架構(gòu)之車輛網(wǎng)絡(luò)安全架構(gòu)
車聯(lián)網(wǎng)中的隱私保護(hù)問題
智能網(wǎng)聯(lián)汽車網(wǎng)絡(luò)安全技術(shù)研究
AUTOSAR 信息安全框架和關(guān)鍵技術(shù)分析
AUTOSAR 信息安全機(jī)制有哪些？
信息安全的底層機(jī)制
汽車網(wǎng)絡(luò)安全
Autosar硬件安全模塊HSM的使用
首發(fā)!小米雷軍兩會(huì)上就汽車數(shù)據(jù)安全問題建言：關(guān)于構(gòu)建完善汽車數(shù)據(jù)安全管理體系的建議
