面向OEM的AUTOSAR解決方案

　　說明：

　　雨刷管理構(gòu)件（WiperWasherManager）有兩個接口，CmdWashing 和StaWasher,圖中WWManager表示為雨刷管理軟件構(gòu)件的實(shí)例。針對CmdWashing接口定義了以下信息：

　　1) CmdWashing接口由WiperWasherManager構(gòu)件提供，其數(shù)據(jù)內(nèi)容為FrontWasher構(gòu)件的Activation接口所使用。

　　2）CmdWashing包含一個“Command”的數(shù)據(jù)元素。

　　3）“Command”的數(shù)據(jù)類型為“t_onoff”。

　　4）“t_onoff”屬于“RecordType”，該類型描述一般的開/關(guān)信息。

　　應(yīng)用軟件開發(fā)者應(yīng)該意識到，面向AUTOSAR運(yùn)行時環(huán)境（RTE）接口的應(yīng)用軟件設(shè)計(jì)的重要性，及早地將AUTOSAR應(yīng)用層接口引入到實(shí)際的項(xiàng)目中來，為實(shí)現(xiàn)應(yīng)用軟件的可復(fù)用性做好準(zhǔn)備，從而優(yōu)化整個軟件開發(fā)流程。

三、 設(shè)計(jì)應(yīng)用與實(shí)施

　　仍以車身/舒適領(lǐng)域的外部車燈控制系統(tǒng)的設(shè)計(jì)為例，在本例中只涉及轉(zhuǎn)向燈的閃爍控制功能的實(shí)現(xiàn)。

　　在系統(tǒng)配置階段，第一步是收集系統(tǒng)配置輸入內(nèi)容。首先收集實(shí)現(xiàn)該功能所需的軟件構(gòu)件，如圖4右部邊框所示，在本系統(tǒng)中共使用了5個軟件構(gòu)件，按照AUTOSAR提供的軟件構(gòu)件模板編寫每個軟件構(gòu)件的描述文件；然后明確系統(tǒng)中所用到的ECU資源，形成ECU資源描述文件，如圖4左上部邊框所示，這里有3類ECU；最后是系統(tǒng)約束條件的描述文件，描述系統(tǒng)的網(wǎng)絡(luò)拓?fù)潢P(guān)系。一般OEM需要提供軟件構(gòu)件描述和系統(tǒng)約束描述文件，以供零部件供應(yīng)商在ECU系統(tǒng)開發(fā)時使用。

圖4：系統(tǒng)配置輸入內(nèi)容。

　　以上描述文件的生成均有專門的工具（這類工具統(tǒng)稱為AUTOSAR描述文件編輯器）支持，用戶只需向工具中填充規(guī)定的內(nèi)容即可。

　　軟件構(gòu)件描述文件的生成，需要獲取每個軟件構(gòu)件的關(guān)于接口，行為，直接的硬件接口（I/O），運(yùn)行性能需求（內(nèi)存，功耗，定時等）等方面的信息；而軟件構(gòu)件描述文件本身將包含4部分內(nèi)容：

* 一般特性：名稱，生產(chǎn)商等

* 通信屬性：端口，接口

* 內(nèi)部結(jié)構(gòu)：子構(gòu)件，連接關(guān)系

* 需要的硬件資源：處理時間，調(diào)度，內(nèi)存大小和類型等。

　　ECU資源描述文件生成之前，需要獲取每個ECU的關(guān)于傳感器和執(zhí)行器，硬件接口，硬件屬性（內(nèi)存，處理器，功耗），連接和帶寬等方面的信息；而ECU描述文件本身將包含7部分內(nèi)容：

* 一般特性：名稱，生產(chǎn)商等

* 溫度（自身，環(huán)境，冷卻/加熱）

* 可用的信號處理方法

* 可用的編程能力

* 可用的硬件：微控制器，架構(gòu)（如多處理器）；內(nèi)存，接口（CAN，LIN，MOST，F(xiàn)lexRay），外設(shè)（傳感器/執(zhí)行器），連接（如引腳數(shù)目）。

* RTE之下針對微控制器的基礎(chǔ)軟件模塊

* 從引腳到ECU抽象層的信號

　　系統(tǒng)約束描述文件生成之前，需要關(guān)于整個系統(tǒng)的信息，如總線系統(tǒng)，協(xié)議，通信矩陣和屬性，功能集群，功能部署（向ECU的分布）；而系統(tǒng)約束描述文件本身將包含3部分內(nèi)容：

* 網(wǎng)絡(luò)拓?fù)洌嚎偩€（CAN，LIN，F(xiàn)lexRay），連接的ECU，網(wǎng)關(guān)，電源供應(yīng)

* 通信（針對每個通道）：通信矩陣，網(wǎng)關(guān)表

* 軟件構(gòu)件的映射

　　以上所描述的系統(tǒng)配置輸入內(nèi)容收集完整后，使用系統(tǒng)配置工具導(dǎo)出系統(tǒng)配置文件，這一步?jīng)Q定哪個軟件構(gòu)件運(yùn)行在哪塊ECU上，它生成ECU配置描述；此外還生成該系統(tǒng)內(nèi)的通信矩陣。如圖5所示。

圖5：系統(tǒng)配置結(jié)果。

　　以上工作完成后，接下來進(jìn)入ECU配置階段。將每個ECU的配置信息從系統(tǒng)配置文件中提取出來，其內(nèi)容包括ECU通信矩陣、拓?fù)浣Y(jié)構(gòu)、頂級功能組合（即需映射到該ECU上的所有軟件構(gòu)件的組合）。此外，還需要更具體的關(guān)于AUTOSAR的基礎(chǔ)軟件各主要部分的配置，如RTE的配置，OS的配置，MCAL（微控制器抽象層）的配置和通信協(xié)議棧配置等。這些軟件部件的配置目前均有相應(yīng)的工具支持，直接生成可編譯的頭文件以供ECU系統(tǒng)軟件的集成使用。在生成ECU可執(zhí)行程序之前，需獲得相關(guān)軟件構(gòu)件和基礎(chǔ)軟件的代碼，然后與上述基礎(chǔ)軟件的配置頭文件進(jìn)行連編，最后生成ECU的可執(zhí)行程序。如圖6所示。

圖6：ECU的配置與可執(zhí)行程序的生成。

　　綜上所述，整個系統(tǒng)設(shè)計(jì)和開發(fā)流程可用圖7表示，這里要注意的是，該過程可能需要多次迭代修改，以達(dá)到最優(yōu)。

圖7：系統(tǒng)設(shè)計(jì)和開發(fā)流程。

四、總結(jié)

　　AUTOSAR正在成為現(xiàn)實(shí)，建立這樣一個標(biāo)準(zhǔn)化平臺并貫徹標(biāo)準(zhǔn)化，將會縮短新產(chǎn)品的研發(fā)時間和測試時間，從而幫助企業(yè)實(shí)現(xiàn)快速的市場反應(yīng)。許多OEM都計(jì)劃在接下來的車型中采用AUTOSAR。在市場上不少工具和軟件供應(yīng)商都已推出了符合AUTOSAR標(biāo)準(zhǔn)的工具或軟件支撐，可為AUTOSAR系統(tǒng)的設(shè)計(jì)和開發(fā)提供完整的無縫的解決方案。

　　AUTOSAR是汽車電子軟件平臺標(biāo)準(zhǔn)化的歷程中的一個巨大飛躍，我們需要學(xué)習(xí)和理解它。但是也必須看到，在整個汽車行內(nèi)打破傳統(tǒng)的軟件開發(fā)平臺需要相當(dāng)長的一個過程。我們可以根據(jù)用戶的需求和目標(biāo)，在初期搭建AUTOSAR與傳統(tǒng)軟件的混合平臺，這是是一個能夠?qū)崿F(xiàn)向AUTOSAR平滑升級的可行的方法。在這個過程里，重點(diǎn)不是單純地使用，理解AUTOSAR的理念和思想才最重要，因?yàn)樗鼘ζ囯娮榆浖_發(fā)的工作流程和商業(yè)模式都將帶來意義深遠(yuǎn)的變革。