123,123

基于Autosar的SOA軟件開發(fā)設(shè)計(jì)詳解

2022-01-09點(diǎn)擊量：154

面向服務(wù)的架構(gòu)SOA的出現(xiàn)可以打破車內(nèi)靜態(tài)交互模型，并且建立功能靈活治理的系統(tǒng)架構(gòu)。確保新增功能的實(shí)現(xiàn)可以與車輛原有的系統(tǒng)架構(gòu)、驅(qū)動(dòng)方式、通信方式相匹配。（SOA）總體思路是設(shè)計(jì)組件模型，將不同的應(yīng)用功能服務(wù)進(jìn)行拆分，并通過定義恰當(dāng)?shù)耐ㄐ沤涌趯⑾鄳?yīng)的服務(wù)串聯(lián)起來。接口定義是獨(dú)立于實(shí)現(xiàn)服務(wù)的硬件平臺(tái)、操作系統(tǒng)和編程語言。確保構(gòu)建在不同系統(tǒng)中的服務(wù)可以以一種統(tǒng)一和通用的方式進(jìn)行交互。SOA是基于系統(tǒng)的概念，這種系統(tǒng)是由一組服務(wù)組成的，其中一個(gè)服務(wù)可以輪流使用另一個(gè)服務(wù)，應(yīng)用程序可以根據(jù)各自的需要調(diào)用一到多個(gè)服務(wù)。這一點(diǎn)上，SOA與Autosar的工作方式是一致的，因此，當(dāng)前自動(dòng)駕駛系統(tǒng)的開發(fā)中往往采用了基于Autosar的SOA設(shè)計(jì)模式。基于Autosar的SOA軟件架構(gòu)基于SOA開發(fā)模式的軟件架構(gòu)（見下圖）主要在于通過軟件抽象層——運(yùn)行時(shí)環(huán)境(RTE)拆分獨(dú)立于硬件的應(yīng)用軟件（ASW）和面向硬件的基礎(chǔ)軟件(BSW)。一方面，這個(gè)抽象層能夠?yàn)镺EM自動(dòng)駕駛系統(tǒng)開發(fā)特定的、有競爭力的軟件應(yīng)用程序。另一方面，它簡化了獨(dú)立于OEM的基礎(chǔ)軟件標(biāo)準(zhǔn)化，其中，基礎(chǔ)軟件進(jìn)一步分為以下幾層，“服務(wù)”、“ECU抽象”、“微控制器抽象”。此外，它是ECU軟件可擴(kuò)展性的前提條件。運(yùn)行時(shí)環(huán)境RTE是從基礎(chǔ)軟件中抽象出應(yīng)用層，并組織它們之間的數(shù)據(jù)和信息流量。這構(gòu)成了在應(yīng)用層面向組件、獨(dú)立于硬件的軟件結(jié)構(gòu)的基礎(chǔ)，軟件模塊可以作為獨(dú)立的單元存在。例如，下一代自動(dòng)駕駛系統(tǒng)采用SOA軟件模塊架構(gòu)，其所有頂層功能都由底層軟件模塊實(shí)現(xiàn)。這些軟件模塊共同構(gòu)成了應(yīng)用程序。各個(gè)軟件模塊僅直接與RTE通信。因此，無論是在ECU內(nèi)還是超出ECU邊界，都設(shè)計(jì)了清晰的通信邊界。通過這種獨(dú)立性，可以在不了解使用或計(jì)劃的硬件情況下開發(fā)軟件組件，或者更確切地說是在ECU之間分配現(xiàn)有軟件模塊。基于SOA構(gòu)建軟件設(shè)計(jì)方法除了基于SOA的軟件架構(gòu)模塊設(shè)計(jì)外，AUTOSAR針對(duì)汽車軟件開發(fā)提出了一套標(biāo)準(zhǔn)化的方法論，構(gòu)建ECU中的軟件模塊，將各種ECU集成到具有不同總線系統(tǒng)的車輛通信網(wǎng)絡(luò)。它定義了通用工件和相關(guān)活動(dòng)，特別是活動(dòng)的依賴關(guān)系。在SOA的設(shè)計(jì)方法中可以使用AUTOSAR的相關(guān)信息，定義了一種具有語義約束的正式數(shù)據(jù)交換格式，這種數(shù)據(jù)信息作為標(biāo)準(zhǔn)描述了存儲(chǔ)在AUTOSARXML(.arxml)文件中，這種ARXML文件實(shí)際是由頂層SOA系統(tǒng)架構(gòu)設(shè)計(jì)者通過構(gòu)建相應(yīng)的SWC組件接口來生成的。軟件組件描述為應(yīng)用軟件提供了標(biāo)準(zhǔn)化的組件模型，系統(tǒng)描述定義了系統(tǒng)上的純軟件層與物理系統(tǒng)架構(gòu)之間的關(guān)系，許多工具使用這些描述來配置和生成AUTOSAR中RTE的基礎(chǔ)軟件�；赟OA架構(gòu)的流程設(shè)計(jì)方法的原理如下圖所示。其中各框圖表示了帶有交叉鏈接的ECU實(shí)例。它描述了網(wǎng)絡(luò)拓?fù)�、每個(gè)通道的通信以及各種ECU上軟件模塊的分配�；贏utosar的SOA軟件架構(gòu)設(shè)計(jì)方法除了具備描述汽車行業(yè)E/E系統(tǒng)的基本能力外，還有許多方面需要實(shí)際交換格式的支持，例如可以通過技術(shù)文檔（包括規(guī)范、定義、技術(shù)要求等）、接口需求表等可追溯性來貫穿整個(gè)軟件生命周期。這種集成的變體管理允許OEM和供應(yīng)商共同深入到基本的AUTOSAR產(chǎn)品線，并在必要時(shí)與其合作伙伴交換相互的信息，對(duì)這些變體的共同理解和一致解釋是聯(lián)合開發(fā)項(xiàng)目成功合作的關(guān)鍵因素。SOA中的應(yīng)用程序接口用于確保應(yīng)用程序模塊與RTE進(jìn)行有效鏈接。其中，APAutosar并未標(biāo)準(zhǔn)化應(yīng)用程序的內(nèi)部功能流程，例如算法，而是將在應(yīng)用程序之間交換的信息。一方面Autosar使用專用語法將基本接口機(jī)制進(jìn)行了標(biāo)準(zhǔn)化。這種標(biāo)準(zhǔn)化接口規(guī)范允許軟件設(shè)計(jì)人員和開發(fā)人員獨(dú)立于任何特定硬件或ECU來開發(fā)軟件模塊，這種軟件模塊可以在包含其使用的數(shù)據(jù)類型、單位和縮放因子下進(jìn)行擴(kuò)展或重用。另一方面對(duì)車輛域主體中應(yīng)用程序接口的語義、內(nèi)涵、舒適性、動(dòng)力傳動(dòng)系、底盤以及乘客和行人保護(hù)進(jìn)行了標(biāo)準(zhǔn)化。重點(diǎn)是廣泛引入應(yīng)用程序的接口規(guī)范，以重點(diǎn)突破軟件模塊的重用和交換。最后，標(biāo)準(zhǔn)化應(yīng)用程序接口的使用對(duì)于應(yīng)用程序的重用至關(guān)重要。系統(tǒng)架構(gòu)-虛擬功能總線為了開發(fā)功能系統(tǒng)架構(gòu)，AUTOSAR引入了虛擬功能總線的概念——VFB（VirtualFunctionBus）。為了避免誤解，應(yīng)該明確指出：AUTOSAR已經(jīng)指定了VFB概念。這個(gè)概念在市場上可用的各種系統(tǒng)架構(gòu)工具中實(shí)現(xiàn)。VFB允許描述整個(gè)系統(tǒng)中應(yīng)用模塊之間的功能交互，此描述獨(dú)立于實(shí)際ECU的架構(gòu)和實(shí)施的網(wǎng)絡(luò)。通過這種方式，VFB將應(yīng)用程序從硬件中抽象出來，在這里，軟件組件被分配給ECU，在每個(gè)ECU中，VFB的功能由RTE和底層基礎(chǔ)軟件實(shí)現(xiàn)。在進(jìn)一步架構(gòu)構(gòu)建過程中，功能系統(tǒng)架構(gòu)被映射到物理架構(gòu)上或者說在ECU和網(wǎng)絡(luò)拓?fù)渖�。SOA中將單個(gè)應(yīng)用程序描述為軟件組件(SWC)。VFB既提供了它們之間的通信機(jī)制，也提供了使用基本軟件服務(wù)到軟件組件的機(jī)制，各種機(jī)制由所謂的端口表示。SOA軟件分層1、應(yīng)用軟件SOA軟件架構(gòu)的層模型將應(yīng)用軟件以軟件組件的形式放置在應(yīng)用層中，可以將軟件組件分組為在外部再次充當(dāng)軟件組件的組合。通過這個(gè)通用組件概念，可以將軟件組件的任何嵌套層次結(jié)構(gòu)實(shí)現(xiàn)為一個(gè)系統(tǒng)。應(yīng)用軟件可以獨(dú)立于硬件進(jìn)行設(shè)計(jì)和開發(fā)。軟件組件通過端口進(jìn)行通信，每個(gè)端口代表某種通信機(jī)制。應(yīng)用程序之間通信中最重要的機(jī)制是“發(fā)送方-接收方”用于由數(shù)據(jù)發(fā)送方發(fā)起的通信，以及“客戶端-服務(wù)器”用于接收方發(fā)起的通信。除此之外，還有用于過程控制（外部觸發(fā)事件）或用于訪問某些參數(shù)（校準(zhǔn)、操作模式、非易失性存儲(chǔ)器）的更多端口。每個(gè)端口都有一個(gè)接口，用于確定要通信的數(shù)據(jù)類型。AUTOSAR已在編程語言C中定義了端口的精確映射。下圖顯示了ECU內(nèi)以及不同ECU中的應(yīng)用程序之間的通信路徑。軟件組件在AUTOSAR中由“軟件組件模板”做特定描述。除了端口和接口的描述之外，這還包含所謂的內(nèi)部行為。在AUTOSAR的上下文中，“內(nèi)部行為”是描述與時(shí)間或事件相關(guān)的過程控制（事件和調(diào)度）相關(guān)的組件。這包括“可運(yùn)行實(shí)體”的定義，即底層操作系統(tǒng)可在事件或時(shí)間上調(diào)度的最小軟件實(shí)體。需要說明的是，要在組件中明確實(shí)現(xiàn)的算法不屬于“內(nèi)部行為”。在實(shí)踐中，有幾種典型的方法來填寫或編輯軟件組件描述。許多基于模型開發(fā)的設(shè)計(jì)工具如EA、Rapshody等，可以從圖形模型中生成軟件組件描述，并允許編輯相應(yīng)的條目。此外，RTE生成器通常允許編輯軟件組件描述。對(duì)于具有特定硬件要求的應(yīng)用程序，例如作為依賴于某些傳感器或執(zhí)行器的軟件，AUTOSAR提供了所謂的傳感器/執(zhí)行器軟件組件，其中可以在軟件組件描述中注明此類約束。2、實(shí)時(shí)運(yùn)行環(huán)境AUTOSAR運(yùn)行時(shí)環(huán)境(RTE)從基本軟件的任何實(shí)現(xiàn)細(xì)節(jié)和控制設(shè)備的硬件中提取應(yīng)用程序。它表示特定ECU上VFB的運(yùn)行時(shí)實(shí)現(xiàn)。RTE提供應(yīng)用程序之間的通信機(jī)制和訪問基礎(chǔ)軟件服務(wù)的機(jī)制。這還包括為通信提供數(shù)據(jù)緩沖和排隊(duì)。RTE的實(shí)際程序代碼取決于應(yīng)用程序及其通信、使用的基礎(chǔ)軟件服務(wù)和調(diào)度。在實(shí)踐中，代碼是由RTE生成器根據(jù)軟件組件描述信息創(chuàng)建的。嚴(yán)格來說，RTE是一種“中間件”層技術(shù)，它可以通過去中心化網(wǎng)絡(luò)實(shí)現(xiàn)應(yīng)用層組件的重新定位。3、基礎(chǔ)軟件基礎(chǔ)軟件通過RTE為應(yīng)用程序提供所有系統(tǒng)服務(wù)和功能。盡管基本軟件的功能對(duì)于應(yīng)用程序來說是必不可少的，但車輛用戶通常不會(huì)很好地注意到這些功能。隨著對(duì)硬件的依賴性越來越大，基本軟件進(jìn)一步劃分為多個(gè)層次：即服務(wù)層、ECU抽象層和微控制器抽象層。反過來，每一層都包含代表精確指定功能范圍的單獨(dú)模塊。AUTOSAR基礎(chǔ)軟件總共包含大約80個(gè)不同的模塊，標(biāo)準(zhǔn)對(duì)每個(gè)模塊都有一個(gè)要求和軟件規(guī)范。其中模塊的功能行為及其接口是用C定義的，因此一個(gè)模塊的兩種不同但符合標(biāo)準(zhǔn)的實(shí)現(xiàn)可以直接互換。基本軟件模塊的功能行為參數(shù)化及其配置使用與應(yīng)用程序組件相同的形式描述機(jī)制�？刂茊卧拒浖K的配置描述總結(jié)在ECU配置描述中�；贏utosar的SOA服務(wù)服務(wù)層包括通信服務(wù)、診斷協(xié)議、存儲(chǔ)服務(wù)、ECU工作模式管理等系統(tǒng)服務(wù)，以及作為獨(dú)立模塊的AUTOSAR操作系統(tǒng)（OS）。AUTOSAROS基于實(shí)時(shí)系統(tǒng)標(biāo)準(zhǔn)OSEK/VDX，在某些領(lǐng)域得到擴(kuò)展，但在其他領(lǐng)域也受到限制。它是靜態(tài)配置和縮放的，并提供基于優(yōu)先級(jí)的實(shí)時(shí)行為和中斷處理。在運(yùn)行時(shí)，可以使用各種用于內(nèi)存訪問或時(shí)間行為的保護(hù)機(jī)制。AUTOSAROS也適用于小型和較低性能的微控制器，同時(shí)也支持多核對(duì)代碼、數(shù)據(jù)使用和使用多個(gè)內(nèi)存分區(qū)，服務(wù)的模塊是獨(dú)立于硬件的操作系統(tǒng)。這些系統(tǒng)服務(wù)可通過RTE提供給應(yīng)用程序，應(yīng)用程序不能直接訪問底層的基本軟件模塊。這是保留提供服務(wù)作為其功能的一部分從而訪問ECU或微控制器資源。服務(wù)模塊及其底層模塊也稱為功能棧，例如FlexRay的通信棧。此類堆棧有時(shí)會(huì)作為一個(gè)大型軟件單元來實(shí)現(xiàn)和集成，而沒有AUTOSAR定義的底層模塊結(jié)構(gòu)。雖然這破壞了抽象原則并降低了靈活性，但由于實(shí)現(xiàn)的效率和性能可能更高，因此在AUTOSAR中使用函數(shù)堆棧進(jìn)行處理很普遍。硬件抽象服務(wù)層主要用于硬件抽象。首先，ECU抽象層將ECU布局（即外圍模塊如何與微控制器連接）與上層分離。盡管這一層是特定于ECU的，但它獨(dú)立于微控制器。下一級(jí)抽象是由微控制器抽象層實(shí)現(xiàn)的，其中包括微控制器特定的驅(qū)動(dòng)程序。例如，這些驅(qū)動(dòng)程序是用于數(shù)字輸入和輸出的I/O驅(qū)動(dòng)程序，或用于將模擬信號(hào)轉(zhuǎn)換為數(shù)字值的ADC驅(qū)動(dòng)程序。因此，AUTOSAR標(biāo)準(zhǔn)直接支持標(biāo)準(zhǔn)化硬件。復(fù)雜驅(qū)動(dòng)層用于處理特殊情況，例如，用于控制具有特殊實(shí)時(shí)要求或具有特定機(jī)電硬件要求的復(fù)雜傳感器或執(zhí)行器。此類模塊并未標(biāo)準(zhǔn)化為AUTOSAR基本軟件模塊，因?yàn)檫@里需要汽車制造商或供應(yīng)商的特定專業(yè)知識(shí)和知識(shí)產(chǎn)權(quán)。然而，復(fù)雜的驅(qū)動(dòng)程序和標(biāo)準(zhǔn)化的模塊必須滿足AUTOSAR基礎(chǔ)軟件中接口機(jī)制的要求。基于Autosar的SOA系統(tǒng)配置在AUTOSAR的上下文中，系統(tǒng)是指網(wǎng)絡(luò)控制單元的組合或集成，其中可能包括車輛的所有ECU。系統(tǒng)配置遵循VFB級(jí)功能系統(tǒng)架構(gòu)的開發(fā)。在設(shè)計(jì)系統(tǒng)配置時(shí)，會(huì)根據(jù)系統(tǒng)的實(shí)際物理架構(gòu)做出決定。這些決定主要與系統(tǒng)拓?fù)溆嘘P(guān)，即哪些控制單元可用以及它們?nèi)绾芜B接。對(duì)于每個(gè)控制單元，都有關(guān)于處理器架構(gòu)、處理器容量、內(nèi)存、接口和外圍設(shè)備或信號(hào)方法的資源描述。網(wǎng)絡(luò)拓?fù)涞拿枋龇秶鷱目偩€系統(tǒng)到各個(gè)通道的通信矩陣。此外，它還包括確定哪個(gè)應(yīng)用軟件組件應(yīng)該在哪個(gè)控制單元上運(yùn)行，所有這些信息都記錄在系統(tǒng)描述中。在實(shí)踐中，這可以通過系統(tǒng)架構(gòu)設(shè)計(jì)工具以及VFB設(shè)計(jì)（也稱為系統(tǒng)生成器）或通過基本軟件模塊的配置工具來完成。系統(tǒng)配置成功需要通過對(duì)各個(gè)控制單元的進(jìn)一步配置，最后通過軟件集成來完成，每個(gè)ECU都是獨(dú)立的，即如果需要，它可以并行運(yùn)行。此外，某個(gè)控制單元的所有相關(guān)信息都被復(fù)制到系統(tǒng)配置之外的ECU描述中。這被命名為系統(tǒng)描述的ECU摘錄。ECU描述還匯總了每個(gè)基本軟件模塊的配置描述。基本軟件配置的許多參數(shù)直接來自系統(tǒng)描述或軟件組件的描述。其余的自由參數(shù)通過使用基本的軟件配置工具來設(shè)置。在幾乎所有基本軟件模塊的配置步驟之后，屬于配置的代碼由生成器生成——就像在RTE中一樣。應(yīng)用軟件組件的實(shí)現(xiàn)是算法和編碼的創(chuàng)建，可以與系統(tǒng)配置完全并行完成，因?yàn)檫@一步獨(dú)立于硬件。最終，基礎(chǔ)軟件的整個(gè)代碼連同RTE代碼以及所有應(yīng)用軟件組件的代碼都集成到每個(gè)控制單元的ECU軟件中�？偨Y(jié)整體上講，面向服務(wù)的SOA架構(gòu)設(shè)計(jì)主要包含五個(gè)步驟：梳理整車功能、規(guī)劃SOA架構(gòu)、服務(wù)定義、服務(wù)矩陣和ARXML設(shè)計(jì)、服務(wù)驗(yàn)證和仿真；SOA不是一種具體的技術(shù)實(shí)現(xiàn)，而是一種模板軟件架構(gòu)，而APAUTOSAR則稱是一個(gè)模板SOA。如何利用Autosar構(gòu)建好的SOA模型是我們需要特別關(guān)注的。本文詳細(xì)闡述了面向服務(wù)的SOA軟件設(shè)計(jì)過程，以Autosar為基礎(chǔ)分析軟件架構(gòu)及其設(shè)計(jì)方法、系統(tǒng)配置、硬件抽象、軟件分層等。本文由培訓(xùn)無憂網(wǎng)長沙牛耳教育課程顧問老師整理發(fā)布，希望能夠?qū)ο朐陂L沙參加影視動(dòng)漫培訓(xùn)的學(xué)生有所幫助。更多課程信息可關(guān)注培訓(xùn)無憂網(wǎng)電腦IT培訓(xùn)頻道或添加老師微信：15033336050...

SOA如何應(yīng)用于經(jīng)典的軟件開發(fā)流程

2022-01-09點(diǎn)擊量：99

Aspice作為車載軟件過程中，關(guān)注于功能場景定義（functiondefinition）、架構(gòu)定義（SystemArchitecture）、系統(tǒng)設(shè)計(jì)（SystemDesign）、產(chǎn)品設(shè)計(jì)（ProductDesign）幾個(gè)大的方面。而下一代智能駕駛系統(tǒng)需要面向服務(wù)進(jìn)行相應(yīng)的功能設(shè)計(jì)和開發(fā)，實(shí)現(xiàn)軟硬件解耦。這種開發(fā)方式將對(duì)整個(gè)智能駕駛來說產(chǎn)生顛覆性的影響，比如高性能計(jì)算平臺(tái)HPC包含多核異構(gòu)處理模式，通過Hypervisor技術(shù)實(shí)現(xiàn)對(duì)硬件抽象，Inter-Core通信技術(shù)使多篇和單片多核實(shí)現(xiàn)信息互通，計(jì)算單元趨于“云計(jì)算+中央計(jì)算+邊緣計(jì)算結(jié)合等多個(gè)方面的變革。如上這些設(shè)計(jì)原則更多的是基于SOA的架構(gòu)進(jìn)行的，這就大大增強(qiáng)了平臺(tái)的可拓展性，可移植性。當(dāng)前更多的主機(jī)廠選擇在智能駕駛中采用SOA的開發(fā)模式，這可以更加快速的實(shí)現(xiàn)從底層、中間層到應(yīng)用層的軟件開發(fā)，且相對(duì)較多的軟件只要接口定義得當(dāng)，就可以實(shí)現(xiàn)軟件本體和功能的遷移，同時(shí)可以大大的降低開發(fā)周期和成本。對(duì)于SOA的設(shè)計(jì)過程來講，其服務(wù)設(shè)計(jì)原則包括重用、抽象、封裝、協(xié)調(diào)在內(nèi)的多個(gè)層面。比如對(duì)于智能駕駛功能開發(fā)而言，如果需要多次用到某一邏輯元素比如車道線等環(huán)境信息，則應(yīng)該將車道線檢測模塊創(chuàng)建為重用（比如封裝到BuildingBlock中），則對(duì)該車道線檢測源（如不同方位的攝像頭）進(jìn)行調(diào)整，則由此對(duì)車道線檢測產(chǎn)生的任何更新改變都會(huì)對(duì)后續(xù)級(jí)聯(lián)的應(yīng)用實(shí)例產(chǎn)生影響。而上層應(yīng)用軟件端對(duì)于底層的如何獲取車道線，如何處理的細(xì)節(jié)也不需要深究，這就是實(shí)現(xiàn)模塊抽象的整個(gè)過程。抽象后的邏輯功能需要保證其體系相類似的功能需要集成到一起，比如自動(dòng)換道功能的控制邏輯可以在自動(dòng)激活后調(diào)用觸發(fā)換道相關(guān)的規(guī)劃控制模塊進(jìn)行車控。因此，觸發(fā)換道的規(guī)劃決策控制邏輯單元可以完全應(yīng)用于自動(dòng)換道模塊。系統(tǒng)工程師只需要保證定義的接口適用于觸發(fā)換道已經(jīng)發(fā)布或預(yù)定的數(shù)據(jù)流即可。對(duì)于自動(dòng)駕駛域控單元負(fù)責(zé)人而言，應(yīng)該保持邏輯系統(tǒng)結(jié)構(gòu)之間的協(xié)調(diào)和重用，包含對(duì)公共池中的元素排布，對(duì)局部域單元中的邏輯構(gòu)造，跨域之間的資源或模塊調(diào)度等。本文將以智能駕駛系統(tǒng)開發(fā)設(shè)計(jì)實(shí)例來講解和分析相應(yīng)的SOA為基礎(chǔ)下的架構(gòu)設(shè)計(jì)和軟件開發(fā)。面向ASPICE流程的SOA軟件架構(gòu)流程適用于SOA架構(gòu)的ASPICE軟件開發(fā)過程也是在敏捷開發(fā)的模式下進(jìn)行的系統(tǒng)開發(fā)流程。從智能駕駛功能開發(fā)層面上講，基于SOA架構(gòu)開發(fā)模式包括了系統(tǒng)功能、系統(tǒng)架構(gòu)、軟件功能、軟件架構(gòu)幾個(gè)方面。其中分別由分別稱之為產(chǎn)品負(fù)責(zé)人ProductOwner、功能負(fù)責(zé)人FunctionOwner、架構(gòu)負(fù)責(zé)人ArchitectOwner、子模塊負(fù)責(zé)人ModuleOwner的幾個(gè)角色共同承擔(dān)。功能設(shè)計(jì)是搭建功能架構(gòu)圖和依據(jù)產(chǎn)品工程師輸入的產(chǎn)品需求定義進(jìn)行功能分解定義，架構(gòu)負(fù)責(zé)人則根據(jù)整車架構(gòu)及功能負(fù)責(zé)人輸入的要素信息制定合適的軟硬件架構(gòu)。這里需要說明的是很多情況下，功能負(fù)責(zé)人和架構(gòu)負(fù)責(zé)人往往是同一個(gè)人。模塊負(fù)責(zé)人則是根據(jù)功能定義編制相應(yīng)的系統(tǒng)軟硬件模塊、零部件軟硬件模塊以實(shí)現(xiàn)上層定義的功能需求。各負(fù)責(zé)人之間的角色定位將在如下分層流程圖中進(jìn)行詳細(xì)說明。這里我們僅關(guān)注V模型中的與SOA相關(guān)度較高的設(shè)計(jì)開發(fā)部分，測試驗(yàn)證部分不在本文中進(jìn)行詳述。其中，各階段的開發(fā)輸出功能過程如下：1、項(xiàng)目功能定義項(xiàng)目功能元素（functionelement）包含與頂層設(shè)計(jì)相關(guān)的不同屬性，例如車輛類型、預(yù)期市場、項(xiàng)目功能以及功能發(fā)布計(jì)劃等。在實(shí)際開發(fā)中，這類輸出一般是產(chǎn)品策劃部門或市場部輸出的整車功能開發(fā)需求或整車裝備需求。本文將以開發(fā)智能駕駛系統(tǒng)功能中的點(diǎn)對(duì)點(diǎn)自動(dòng)駕駛NOP為例進(jìn)行詳細(xì)的分析說明基于SOA的架構(gòu)設(shè)計(jì)是如何應(yīng)用于自動(dòng)駕駛系統(tǒng)開發(fā)的。如下圖舉例中，表示了實(shí)現(xiàn)下一代自動(dòng)駕駛系統(tǒng)NOP場景定義需求。2、系統(tǒng)架構(gòu)設(shè)計(jì)階段（SystemArchitectureDesign）這個(gè)階段涉及產(chǎn)品能力定義及模塊定義。用于描述智能汽車中的用戶功能，通過定義相應(yīng)的函數(shù)來指出使用哪些子系統(tǒng)或者零部件具備相應(yīng)的產(chǎn)品能力（ProductCapabilities，PC）并對(duì)其進(jìn)行相應(yīng)的實(shí)例化來實(shí)現(xiàn)此功能。（1）產(chǎn)品能力PC：這種稱之為產(chǎn)品能力的模塊主要是用于定義想要實(shí)現(xiàn)該功能模塊的傳感器或執(zhí)行器所具備的能力，這也是位于各個(gè)時(shí)序圖上各個(gè)節(jié)點(diǎn)的能力描述。通常，該產(chǎn)品能力的定義主要由產(chǎn)品工程師牽頭，功能所有者、架構(gòu)師和模塊所有者/設(shè)計(jì)者的跨職能小組共同決定。（2）產(chǎn)品能力實(shí)例化PCInstance：產(chǎn)品能力可以被認(rèn)為是一種高級(jí)服務(wù)，一些需要在汽車中實(shí)現(xiàn)的功能，但它沒有描述應(yīng)該如何實(shí)現(xiàn)。產(chǎn)品能力實(shí)例是PC的簡單實(shí)例化，可以在平臺(tái)中擁有PC的不同變體。如果需要PC的不同變體實(shí)例以及在何處使用不同的實(shí)例，則模塊所有者負(fù)責(zé)。系統(tǒng)架構(gòu)師負(fù)責(zé)定義系統(tǒng)中定義了產(chǎn)品能力PC的不同類型，并確定哪些PC需要由跨職能團(tuán)隊(duì)才能完成。通過將當(dāng)前定義的PC和其他的需要PC建立依賴關(guān)系，我們可以建模一個(gè)完整的功能架構(gòu)，該功能層級(jí)的架構(gòu)無需研究實(shí)際的實(shí)現(xiàn)機(jī)制。這對(duì)于定義需要哪些高級(jí)服務(wù)(PC)以及分配誰（哪個(gè)模塊）負(fù)責(zé)實(shí)施每個(gè)PC非常有幫助。如上過程一般是通過各種圖表（包含用例圖、序列圖、活動(dòng)圖等）來完成的。如下圖表示了一種活動(dòng)圖所示意的系統(tǒng)交互方式。由于在定義過程中還建立了與功能之間的連接，因此我們可以使用該模塊來規(guī)劃需要實(shí)現(xiàn)PC的順序，以便我們?cè)诿總€(gè)版本的集成階段開發(fā)出正確的功能。（3）模塊及實(shí)例ModuleInstance：模塊是整個(gè)模型甚至整個(gè)組織中非常核心的元素。從SOA的架構(gòu)設(shè)計(jì)上講，每個(gè)設(shè)計(jì)的PC都被分配到一個(gè)并且只有一個(gè)模塊（或者稱之為函數(shù)），該模塊負(fù)責(zé)實(shí)現(xiàn)PC，但在整個(gè)平臺(tái)生命周期內(nèi)維護(hù)和發(fā)展PC，規(guī)劃PC的演進(jìn)步驟，提供路線圖等。PC定義的功能在Component中實(shí)現(xiàn)，模塊實(shí)例可以確保在平臺(tái)中擁有模塊的不同變體。系統(tǒng)架構(gòu)師負(fù)責(zé)定義系統(tǒng)中存在哪些模塊，但模塊所有者負(fù)責(zé)領(lǐng)導(dǎo)模塊內(nèi)的工作，并負(fù)責(zé)維護(hù)和發(fā)展模塊。模塊所有者還負(fù)責(zé)是否需要模塊的不同變體實(shí)例以及在何處使用等。同時(shí)，模塊中的相關(guān)參數(shù)是在對(duì)應(yīng)構(gòu)建的系統(tǒng)功能規(guī)范中實(shí)現(xiàn)定義的。3、軟件架構(gòu)設(shè)計(jì)階段軟件組件SoftwareComponent：組件是模塊的實(shí)際設(shè)計(jì)和實(shí)現(xiàn)。組件可以是軟件或硬件組件，但在SOA的軟件架構(gòu)中，我們將主要處理軟件組件，組件定義了模塊需要哪些接口以及提供哪些接口。其中接口將包括SOA架構(gòu)所要求的服務(wù)、屬性和事件。在硬件組件上，接口可以是螺孔或電線連接器。軟件包SoftwarePackage：軟件包是將部署到特定運(yùn)行環(huán)境時(shí)的所有軟件組件、清單文件等的集合。為了實(shí)現(xiàn)面向SOA的架構(gòu)設(shè)計(jì)和開發(fā)過程，需要重點(diǎn)定義。4、底層驅(qū)動(dòng)設(shè)計(jì)階段中央控制單元ECU/處理器Processor/虛擬機(jī)VirtualMachine：一個(gè)ECU可以由一個(gè)或多個(gè)處理器組成，一個(gè)處理器可以運(yùn)行一個(gè)或多個(gè)虛擬機(jī)。不必對(duì)每個(gè)組件進(jìn)行建模，例如，如果ECU僅包含一個(gè)處理器，則僅對(duì)ECU進(jìn)行建模就足夠了�？梢詫⒏鱾€(gè)軟件包部署到如上運(yùn)行時(shí)環(huán)境中的任何一個(gè)。網(wǎng)絡(luò)及連接器NetworkConnector：定義網(wǎng)絡(luò)以及連接到它的運(yùn)行時(shí)環(huán)境。運(yùn)行時(shí)環(huán)境可以由一個(gè)或多個(gè)網(wǎng)絡(luò)連接組成，這些網(wǎng)絡(luò)連接可以是CAN、CANFD、以太網(wǎng)、VLAN、LIN等。嚴(yán)格說來，底層驅(qū)動(dòng)設(shè)計(jì)應(yīng)該屬于軟件架構(gòu)設(shè)計(jì)的其中一個(gè)部分，面向底層軟件設(shè)計(jì)部分，通常與頂層軟件開發(fā)團(tuán)隊(duì)不是一伙人，且具有較大區(qū)別，該開發(fā)過程由頂層軟件設(shè)計(jì)人員對(duì)底層軟件開發(fā)人員單獨(dú)提出需求及建議。一般的需求包括平臺(tái)軟件總體架構(gòu)及對(duì)相關(guān)AUTOSAR標(biāo)準(zhǔn)組件和復(fù)雜驅(qū)動(dòng)的調(diào)度框架設(shè)計(jì)、開發(fā)和集成要求；內(nèi)存、非易失性存儲(chǔ)、任務(wù)、中斷等等資源和權(quán)限分配；上下電流程和管理的設(shè)計(jì)；系統(tǒng)運(yùn)行狀態(tài)監(jiān)控、異常處理等功能的設(shè)計(jì)等方面�；赟OA架構(gòu)模型設(shè)計(jì)分工基于SOA軟件模型架構(gòu)的設(shè)計(jì)過程實(shí)際是在研究如何在開發(fā)流程中進(jìn)行軟硬件解耦。包括構(gòu)建不同的分層來隔離硬件與軟件功能和服務(wù)。例如，將自動(dòng)駕駛相關(guān)的傳感器和執(zhí)行器邏輯與應(yīng)用程序邏輯分開，則能夠在中央系統(tǒng)中分配應(yīng)用程序，同時(shí)保持傳感器/執(zhí)行器盡可能的具體。程序之間可以利用SOA的服務(wù)模式實(shí)現(xiàn)軟件包的調(diào)用，傳感器和執(zhí)行器也可以作為組件或模組來進(jìn)行邊緣采購，性能則是集中管控，中央系統(tǒng)可以將戰(zhàn)略軟件進(jìn)行分開，這就更容易進(jìn)行軟件模塊移植和處理。這一過程實(shí)際就是在提高上層應(yīng)用層軟件關(guān)鍵功能的復(fù)用性，瞄準(zhǔn)軟硬件功能與邏輯控制分離。這里需要說明的是，軟硬件之間的協(xié)調(diào)和調(diào)度是通過中間件來實(shí)現(xiàn)。從如下圖所示，SOA的架構(gòu)從下至上分別底層驅(qū)動(dòng)功能管理，物理層功能管理，車輛控制服務(wù)，面向用戶的應(yīng)用服務(wù)，云端遠(yuǎn)程管理。底層驅(qū)動(dòng)功能管理：用于實(shí)現(xiàn)包含診斷、日志記錄、存儲(chǔ)管理、驅(qū)動(dòng)管理等相關(guān)功能。物理層功能管理：主要是設(shè)置I/O接口將原始傳感器數(shù)據(jù)進(jìn)行輸入，同時(shí)也是執(zhí)行到車端的控制單元（如電機(jī)、制動(dòng)卡鉗等）；車輛控制服務(wù)：車端控制包含上層ADAS發(fā)送的執(zhí)行指令到控制執(zhí)行器執(zhí)行該指令的相應(yīng)ECU（如控制電機(jī)的VCU、HCU或ESP），該車輛控制服務(wù)是綜合考慮了車身穩(wěn)定性與動(dòng)力學(xué)反饋模型得出的。應(yīng)用層服務(wù)：該層服務(wù)就是智能駕駛面向用戶級(jí)別的頂層開發(fā)功能，主要用于實(shí)現(xiàn)包含傳統(tǒng)的智能駕駛功能，比如HWP、NOP、TJP以及ALC等。云端管理服務(wù)：該層服務(wù)主要是面向遠(yuǎn)程監(jiān)控，遠(yuǎn)程控制，大數(shù)據(jù)存儲(chǔ)等特殊場景。通常該服務(wù)需要基于4G/5G網(wǎng)絡(luò)進(jìn)行遠(yuǎn)程連接。人機(jī)交互管理功能：人機(jī)交互管理功能一般是針對(duì)不同的車型呈現(xiàn)出不同的模式的，因此，這一塊一般是獨(dú)立于SOA的功能架構(gòu)。SOA通常只涉及底層對(duì)車輛控制邏輯，對(duì)于平臺(tái)化車型功能開發(fā)來說，這一塊是無法為用戶所感知的。而HMI的顯示設(shè)置則是用戶能夠真切感知和控制的，因此，不同車型肯定是有極大的不同之處。因此，從協(xié)議上分析不難看出，SOA內(nèi)部的網(wǎng)絡(luò)架構(gòu)一般是基于以太網(wǎng)為基礎(chǔ)的交互方式，采用Some/ip的協(xié)議進(jìn)行通信控制。而如果在平臺(tái)化車型的開發(fā)過程中，HMI這一塊的通常仍然按照原始CAN/CANFD信號(hào)模式的通信協(xié)議進(jìn)行交互控制。這么做的原因是，智能駕駛的HMI行為比核心應(yīng)用功能更容易改變，特別是在不同車型開發(fā)后期通常會(huì)選擇不同的顯示和交互方式。同時(shí)，由于開發(fā)核心軟件和HMI設(shè)計(jì)需要不同的能力技能，因此，將HMI功能與其他應(yīng)用層軟件功能分離，為了實(shí)現(xiàn)這一點(diǎn)，一般需要使用Model-View-Controller，用戶輸入由Controller處理，Controller用于解釋用戶的意圖并操作模型。SOA服務(wù)實(shí)現(xiàn)過程隨著車載以太網(wǎng)技術(shù)的日益成熟，國內(nèi)大部分OEM都已經(jīng)著手SOA的設(shè)計(jì)工作，并將以太網(wǎng)通信矩陣生成ARXML文件，用于項(xiàng)目前期的網(wǎng)絡(luò)行為仿真和后期測試驗(yàn)證。對(duì)于已經(jīng)完成架構(gòu)搭建的SOA來講，需要將其建模后的成品導(dǎo)入到軟件團(tuán)隊(duì)進(jìn)行服務(wù)實(shí)現(xiàn)。其過程包含：以Some/Ip協(xié)議導(dǎo)入ServiceARXML，導(dǎo)入后新增ETH、TCP/IP、Some/IP模塊（BSW工程），建立與ServiceHandlerSWC（應(yīng)用層）中PortInterface連接，為所有ServiceHandlerSWC增加可運(yùn)行時(shí)間，定義WindowsServiceHandlerSWC和FeatureSWC到Simulink/Stateflow。通過符合Autosar的ARXML和Simulink進(jìn)行交互，將由軟件開發(fā)工程師繼續(xù)進(jìn)行算法設(shè)計(jì)并自動(dòng)生成代碼�？偨Y(jié)本文從SOA軟件架構(gòu)模型的構(gòu)建角度出發(fā)講解了相應(yīng)實(shí)現(xiàn)過程原理，利用了基于模型、集成式的可視化開發(fā)工具PREEvision進(jìn)行了智能汽車行業(yè)及相關(guān)領(lǐng)域E/E架構(gòu)開發(fā)并支持以太網(wǎng)SOA的架構(gòu)開發(fā)設(shè)計(jì)，本文以介紹SOA架構(gòu)設(shè)計(jì)模型為基礎(chǔ)展示了如何在EnterpriseArchitect中進(jìn)行SOA建模。同時(shí)，以系統(tǒng)工程師的角度說明如何利用EnterpriseArchitect構(gòu)建SOA系統(tǒng)及軟件架構(gòu)設(shè)計(jì)、功能設(shè)計(jì)FunctionDesign和模塊設(shè)計(jì)ModuleDesign。對(duì)于SOA在整個(gè)智能駕駛系統(tǒng)設(shè)計(jì)原理有個(gè)清晰的把控。本文由培訓(xùn)無憂網(wǎng)長沙牛耳教育課程顧問老師整理發(fā)布，希望能夠?qū)ο朐陂L沙參加影視動(dòng)漫培訓(xùn)的學(xué)生有所幫助。更多課程信息可關(guān)注培訓(xùn)無憂網(wǎng)電腦IT培訓(xùn)頻道或添加老師微信：15033336050...