面向OEM的AUTOSAR汽車開放系統(tǒng)架構(gòu)解決方案

兼容AUTOSAR標(biāo)準(zhǔn)的汽車電子軟件系統(tǒng)設(shè)計(jì)與開發(fā)流程如圖 2所示。

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

　　主要步驟可劃分兩個(gè)階段：

　　第一個(gè)階段是系統(tǒng)配置階段，這屬于系統(tǒng)級(jí)設(shè)計(jì)決策工作。首先是編寫系統(tǒng)配置輸入文件，為XML類型的文件。應(yīng)用軟件的描述術(shù)語在 AOTUSAR中為軟件構(gòu)件（Software Components），該文件將確定需要使用的軟件構(gòu)件（即系統(tǒng)具有哪些功能）和硬件資源（ECU），以及整個(gè)系統(tǒng)的約束條件。AUTOSAR提供了一系列的模板（軟件構(gòu)件模板，ECU資源模板和系統(tǒng)模板）和標(biāo)準(zhǔn)的信息交換格式，工具供應(yīng)商可據(jù)此提供相應(yīng)的工具支持，從而簡(jiǎn)化系統(tǒng)設(shè)計(jì)的工作，最終系統(tǒng)設(shè)計(jì)者只需要使用工具填充或編輯相應(yīng)的模板即可導(dǎo)出系統(tǒng)配置輸入文件。

　　系統(tǒng)配置輸入包含三部分內(nèi)容，第一個(gè)輸入是軟件構(gòu)件描述，定義每個(gè)需要的軟件構(gòu)件的接口內(nèi)容，包括數(shù)據(jù)類型，端口，接口等；第二個(gè)輸入是ECU資源描述，定義了每個(gè)ECU的資源需求，如處理器、外部設(shè)備、存儲(chǔ)器、傳感器和執(zhí)行器等；第三個(gè)輸入是系統(tǒng)約束描述，定義總線信號(hào)，拓?fù)浣Y(jié)構(gòu)和軟件構(gòu)件的映射關(guān)系。

　　系統(tǒng)配置階段接下來的工作是將初步獲得的系統(tǒng)配置輸入文件借助系統(tǒng)配置生成器生成系統(tǒng)配置描述文件，同樣為XML文件，這是系統(tǒng)配置階段的最終工作成果。該文件將包含所有的系統(tǒng)信息，包括將軟件構(gòu)件映射到相關(guān)的ECU上（這種映射需要考慮到構(gòu)件的需要、構(gòu)件的連接、資源需求以及約束條件，有時(shí)也需要考慮成本等方面的因素），以及通信矩陣（整車的網(wǎng)絡(luò)結(jié)構(gòu)、時(shí)序以及網(wǎng)絡(luò)數(shù)據(jù)幀的內(nèi)容）。

　　第二個(gè)階段是ECU的配置，這階段的工作需要對(duì)系統(tǒng)中每個(gè)ECU分別進(jìn)行。首先是使用第一個(gè)階段的工作成果——系統(tǒng)配置描述文件，從中提取出與各個(gè)ECU相關(guān)的系統(tǒng)配置描述信息，提取的信息包括ECU通信矩陣、拓?fù)浣Y(jié)構(gòu)、頂級(jí)功能組合（據(jù)此產(chǎn)生需映射到該ECU上的所有軟件構(gòu)件），將放在另一個(gè)XML文件中。提取信息的工作可借助工具完成。然后進(jìn)入ECU配置的實(shí)際工作中，這一步負(fù)責(zé)往輸入對(duì)象中添加具體應(yīng)用所必需的信息，如任務(wù)調(diào)度、必要的BSW模塊、BSW配置信息、給任務(wù)分配的可運(yùn)行實(shí)體等。這一步的結(jié)果被放在ECU 配置描述文件中，它包含了具體ECU所需的所有信息。最后一步是生成具體ECU的可執(zhí)行程序，此步將根據(jù)ECU 配置描述文件中的配置信息構(gòu)建完成ECU的基礎(chǔ)軟件的設(shè)置和與基于AUTOSAR構(gòu)件的應(yīng)用軟件的集成，最終生成ECU的可執(zhí)行代碼。

　　此外，要說明的是，AUTOSAR系統(tǒng)的設(shè)計(jì)過程使用了虛擬功能總線（Virtual Functional Bus）的概念。虛擬功能總線（Virtual Functional Bus）將AUTOSAR軟件構(gòu)件相互間的通信以及軟件構(gòu)件與基礎(chǔ)軟件之間的通信進(jìn)行了抽象，同時(shí)使用預(yù)先定義的標(biāo)準(zhǔn)接口。而對(duì)于虛擬功能總線來說，ECU內(nèi)部通信和外部總線通信并沒有什么區(qū)別，這種區(qū)別要等到系統(tǒng)布局以及ECU的具體功能最終確定才會(huì)體現(xiàn)出來。軟件構(gòu)件本身對(duì)于這種區(qū)別并不關(guān)注，因此我們可以在獨(dú)立的情況下開發(fā)軟件構(gòu)件。在系統(tǒng)實(shí)現(xiàn)過程中，虛擬功能總線所代表的功能最終以RTE的生成來體現(xiàn)。

　　3、標(biāo)準(zhǔn)化的應(yīng)用接口

　　通過RTE實(shí)現(xiàn)AUTOSAR軟件構(gòu)件（即應(yīng)用程序）相互間的通信以及軟件構(gòu)件與基礎(chǔ)軟件之間的通信的前提是，軟件構(gòu)件必須具有標(biāo)準(zhǔn)的 AUTOSAR接口。目前，AUTOSAR 3.1版已定義了一些典型的汽車電子應(yīng)用領(lǐng)域（動(dòng)力，車身/舒適和底盤）的標(biāo)準(zhǔn)接口。AUTOSAR按照功能邏輯分別將這些領(lǐng)域的系統(tǒng)劃分成若干個(gè)模塊，這些模塊可被視為一個(gè)軟件構(gòu)件或多個(gè)軟件構(gòu)件的組合，這些功能性的軟件構(gòu)件的接口被明確定義，所定義的接口的內(nèi)容包括名稱，含義，范圍，數(shù)據(jù)類型，通信類型，單位等。應(yīng)用軟件開發(fā)者在軟件構(gòu)件的設(shè)計(jì)與開發(fā)時(shí)需要應(yīng)用這些接口定義。

這里以車身/舒適系統(tǒng)的雨刷管理的軟件構(gòu)件的接口定義為示例，如圖3：

圖3：軟件構(gòu)件的接口定義。

　　說明：

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

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

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

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

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

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

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

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