【正文】 它包含了具體ECU所需的所有信息。 此外，要說(shuō)明的是，AUTOSAR系統(tǒng)的設(shè)計(jì)過程使用了虛擬功能總線（Virtual Functional Bus）的概念。而對(duì)于虛擬功能總線來(lái)說(shuō)，ECU內(nèi)部通信和外部總線通信并沒有什么區(qū)別，這種區(qū)別要等到系統(tǒng)布局以及ECU的具體功能最終確定才會(huì)體現(xiàn)出來(lái)。在系統(tǒng)實(shí)現(xiàn)過程中，虛擬功能總線所代表的功能最終以RTE的生成來(lái)體現(xiàn)。目前，AUTOSAR （動(dòng)力，車身/舒適和底盤）的標(biāo)準(zhǔn)接口。應(yīng)用軟件開發(fā)者在軟件構(gòu)件的設(shè)計(jì)與開發(fā)時(shí)需要應(yīng)用這些接口定義。圖 軟件構(gòu)件的接口定義其中雨刷管理構(gòu)件（WiperWasherManager）有兩個(gè)接口，CmdWashing 和StaWasher,圖中WWManager表示為雨刷管理軟件構(gòu)件的實(shí)例。 （2）CmdWashing包含一個(gè)“Command”的數(shù)據(jù)元素。 （4）“t_onoff”屬于“RecordType”，該類型描述一般的開/關(guān)信息。第3章 可配置的汽車控制系統(tǒng)VDMS框架研究 汽車控制系統(tǒng)中的組件技術(shù)汽車領(lǐng)域作為嵌入式實(shí)時(shí)系統(tǒng)的一類代表，對(duì)安全性，可靠性，資源使用和消耗等方面的要求一直在不斷提高。隨著系統(tǒng)的復(fù)雜性和由軟件執(zhí)行的功能數(shù)量的增加，軟件開發(fā)的代價(jià)也隨之提高?；诮M件的軟件工程（CBSE）是一種很有前途的方法，用于高效率的軟件開發(fā)，使得軟件架構(gòu)和可重用性被很好的界定。這些系統(tǒng)以安全和任務(wù)可靠運(yùn)行為關(guān)鍵，系統(tǒng)行為的及時(shí)性至關(guān)重要。這需要貫穿于組件和系統(tǒng)整個(gè)生命周期的確定的方法體系和工具的支持，包括技術(shù)、組織、市場(chǎng)、法律等其他方面。CBSE的基本原理是軟件應(yīng)用都是由組件構(gòu)成。組件技術(shù)為基于組件的軟件合成提供支持，經(jīng)常包含許多不同的開發(fā)工具來(lái)簡(jiǎn)化工程過程，為組件的必要運(yùn)行時(shí)間提供支持，還附加上有組裝組件的某種模式。組件技術(shù)中的一個(gè)最重要的部分是組件框架，它為組件提供必要的運(yùn)行時(shí)間，而不是由底層的運(yùn)行平臺(tái)提供支持(例如：操作系統(tǒng)或相似的系統(tǒng))。在比喻中，組件框架主要提供力量的建設(shè)，不是所提供的基本執(zhí)行平臺(tái)。組件框架往往是介于操作系統(tǒng)和基于組件的應(yīng)用程序之間的一層。 組件模型定義了用戶所應(yīng)遵循的一套規(guī)則。圖 任意形狀組成的組件技術(shù)基于組件的策略支持能有效地開發(fā)應(yīng)用系統(tǒng)，它解決了整個(gè)軟件生命周期問題。CBSE也支持維護(hù)性，因?yàn)榻M件的組裝是系統(tǒng)模型的應(yīng)用支持的對(duì)象，而且它被定義成與系統(tǒng)相一致的狀態(tài)。當(dāng)使用一個(gè)基于組件的方法時(shí)，組件的擴(kuò)展接口是支持這種方法的，同時(shí)通過CBSE可以增強(qiáng)測(cè)試和調(diào)試，因?yàn)榻M件很容易統(tǒng)一測(cè)試同時(shí)能夠監(jiān)視接口保證行為的正確性?；诮M件的軟件工程（CBSE）的基本原理是軟件應(yīng)用都是由組件構(gòu)成。組件技術(shù)為基于組件的軟件合成提供支持，經(jīng)常包含許多不同的開發(fā)工具來(lái)簡(jiǎn)化工程過程，為組件的必要運(yùn)行時(shí)間提供支持，還附加上有組裝組件的某種模式。AOSD允許對(duì)軟件系統(tǒng)中多種關(guān)注點(diǎn)進(jìn)行獨(dú)立描述，同時(shí)又能自動(dòng)統(tǒng)一組合到工作系統(tǒng)中。對(duì)于數(shù)據(jù)庫(kù)管理系統(tǒng)中的一些關(guān)注點(diǎn)，比如并發(fā)控制，日志，和系統(tǒng)恢復(fù)等功能，他們的實(shí)現(xiàn)必須分散到系統(tǒng)中其他的組件中，稱為橫切關(guān)注點(diǎn)。模塊化和效率之間的權(quán)衡，服務(wù)粒度和服務(wù)間關(guān)系數(shù)量的權(quán)衡，都將導(dǎo)致這些關(guān)注點(diǎn)分散在數(shù)據(jù)庫(kù)管理系統(tǒng)（DBMS）的很多部分之中[41].面向方面編程（AOP）由于其固有的模塊化特性和對(duì)橫切關(guān)注點(diǎn)的組合能力，因此是定制和演化問題的一種很好的解決方案。 基于組件的數(shù)據(jù)庫(kù)管理系統(tǒng)設(shè)計(jì)基于組件的軟件開發(fā)，首先考慮嵌入和實(shí)時(shí)的特性，將DBMS按照功能分解成一個(gè)個(gè)獨(dú)立的子系統(tǒng)，然后將子系統(tǒng)封裝成組件，組件是對(duì)功能的高度抽象和概括，也是系統(tǒng)的執(zhí)行單元，執(zhí)行事先已定義好的功能。（2）設(shè)計(jì)組件，設(shè)計(jì)組件所提供的服務(wù)， 還要定義其接口和狀態(tài)。 組件劃分在軟件體系結(jié)構(gòu)里面，一個(gè)組件被認(rèn)為是一個(gè)合成的功能單元，所有類型的組件均通過已經(jīng)定義好的接口和環(huán)境進(jìn)行通信。組件具有黑匣子的特性，隱藏了具體的實(shí)現(xiàn)細(xì)節(jié)，封裝內(nèi)部的狀態(tài)和屬性，每個(gè)組件都提供屬性和方法供別的組件訪問[32]，每個(gè)模塊只能看到對(duì)其他模塊的接口，每個(gè)模塊實(shí)現(xiàn)各自域的功能，而域可被分為低等級(jí)的域，即軟件可以分層組織，如一些組件可以由子組件構(gòu)成。比較常見的方面包有：（1） 并發(fā)控制方面包（2） 日志和恢復(fù)方面包分解形成的組件和方面包，構(gòu)成組件庫(kù)，在設(shè)計(jì)一個(gè)RTDBMS系統(tǒng)時(shí)，可以將不同的軟件組件組合在一起，完成數(shù)據(jù)管理的功能。為應(yīng)用程序或者用戶提供數(shù)據(jù)庫(kù)接口，這個(gè)接口包括數(shù)據(jù)操作語(yǔ)言，用戶（或應(yīng)用程序）可以查詢和操作數(shù)據(jù)元素。應(yīng)用程序的請(qǐng)求被接口組件解析，然后提交到事務(wù)調(diào)度計(jì)劃中。（2） 事務(wù)管理組件：負(fù)責(zé)提交來(lái)的執(zhí)行計(jì)劃，在此對(duì)數(shù)據(jù)庫(kù)中的數(shù)據(jù)進(jìn)行操作。它還調(diào)用并發(fā)控制包里的所管理組件了保證事務(wù)的串行化處理。（4） 內(nèi)存管理組件：主要負(fù)責(zé)內(nèi)存存儲(chǔ)的管理，事務(wù)管理組件（TMC）和索引管理組件（IMC）調(diào)用MMC操作來(lái)分配內(nèi)存或者釋放內(nèi)存。它允許用戶根據(jù)配置文件選擇是否可搶占，并且能動(dòng)態(tài)調(diào)整事務(wù)的優(yōu)先級(jí)。管理并發(fā)事務(wù)需要一些并發(fā)控制算法。并發(fā)控制包包括加鎖和釋放鎖的代碼，以及事務(wù)沖突的解決方法。（7）日志和恢復(fù)方面包（Logging and recovery aspect package，LRA）：保證數(shù)據(jù)庫(kù)的一致性，當(dāng)發(fā)生系統(tǒng)故障時(shí)，進(jìn)行系統(tǒng)恢復(fù)。下圖是基本的RTDBMS配置結(jié)構(gòu)。 汽車控制系統(tǒng)數(shù)據(jù)管理方法汽車控制系統(tǒng)中，每一個(gè)ECU采用內(nèi)部數(shù)據(jù)處理的方法管理數(shù)據(jù)，將降低系統(tǒng)的性能，可擴(kuò)展和可維護(hù)性差，不能滿足日益增長(zhǎng)的汽車控制系統(tǒng)數(shù)據(jù)管理的需求。汽車中通常包含70多個(gè)ECU，以對(duì)不同的子系統(tǒng)進(jìn)行控制和監(jiān)測(cè)。由于各個(gè)ECU控制單元中沒有相互聯(lián)系，把與某個(gè)汽車子系統(tǒng)（比如傳動(dòng)系、地盤、車身和多媒體子系統(tǒng)等）相關(guān)的功能，制定為某個(gè)電子控制單元來(lái)負(fù)責(zé)控制和監(jiān)視是比較容易的。按照功能的不同，可以將汽車控制系統(tǒng)分為不同的子系統(tǒng)，如傳動(dòng)子系統(tǒng)、底盤子系統(tǒng)、車身子系統(tǒng)和多媒體子系統(tǒng)[27]。 集中式集中式數(shù)據(jù)庫(kù)系統(tǒng)，在汽車控制系統(tǒng)中某一個(gè)單獨(dú)的ECU上面實(shí)現(xiàn)一個(gè)DBMS，這樣DBMS就可以與各個(gè)子系統(tǒng)或他們各自的ECU通信。系統(tǒng)及其數(shù)據(jù)管理被某個(gè)ECU或中心站點(diǎn)集中控制，就相當(dāng)于傳統(tǒng)的集中式數(shù)據(jù)庫(kù)系統(tǒng)結(jié)構(gòu)。更新或者擴(kuò)展（例如功能方面的）只需要給單個(gè)硬件提供合適的單個(gè)軟件更新。在集中式數(shù)據(jù)庫(kù)里，大多數(shù)功能（如修改、備份、查詢、控制訪問等）都很容易實(shí)現(xiàn)。從其他子系統(tǒng)或者ECU到中心站點(diǎn)ECU的通信開銷是很昂貴的。此外，如果網(wǎng)關(guān)發(fā)生錯(cuò)誤或者沒有存取一個(gè)或者多個(gè)子系統(tǒng)，這將對(duì)整個(gè)系統(tǒng)造成毀滅性的打擊由于數(shù)據(jù)無(wú)效或者超時(shí)。其次，因?yàn)橐粋€(gè)ECU（或者網(wǎng)關(guān)）是資源限制的，集中式DBMS不能滿足汽車控制系統(tǒng)數(shù)據(jù)處理的需求（例如硬實(shí)時(shí)，計(jì)算能力）。組件通過定義好的接口相互連接。首先，將DBMS分布在整個(gè)ECU網(wǎng)絡(luò)中，解決了當(dāng)某一個(gè)ECU發(fā)生錯(cuò)誤時(shí)會(huì)影響系統(tǒng)性能的瓶頸問題。假設(shè)原始的組件發(fā)生錯(cuò)誤的話，復(fù)用的組件可以代替原始的組件。除了這些提高外（對(duì)比集中式DBMS方法），分布式DBMS還有增強(qiáng)系統(tǒng)的可維護(hù)性和可擴(kuò)展性的優(yōu)點(diǎn)。由于軟件組件的分布式，不同ECU之間的通信增加了。此外，當(dāng)一個(gè)或者多個(gè)組件發(fā)生錯(cuò)誤（也可能是相應(yīng)的ECU出錯(cuò)），不同組件之間的協(xié)調(diào)也十分的復(fù)雜。分布式數(shù)據(jù)庫(kù)系統(tǒng)在許多情形下與客戶/服務(wù)器架構(gòu)類似，它們都使用多個(gè)子系統(tǒng)以及應(yīng)用程序能夠訪問遠(yuǎn)程子系統(tǒng)的數(shù)據(jù)。在分布式數(shù)據(jù)庫(kù)系統(tǒng)里，數(shù)據(jù)可以在多個(gè)不同的數(shù)據(jù)庫(kù)中進(jìn)行傳送，由不同的DBMS軟件進(jìn)行管理，運(yùn)行在多種不同的ECU之上。在分布式數(shù)據(jù)庫(kù)系統(tǒng)里，一個(gè)應(yīng)用程序可以操作位于不同地理位置的ECU上的數(shù)據(jù)。每臺(tái)機(jī)器都有數(shù)據(jù)和它自己的應(yīng)用程序。因此，每個(gè)節(jié)點(diǎn)對(duì)一些應(yīng)用程序來(lái)說(shuō)是服務(wù)器，而對(duì)另外一些應(yīng)用程序來(lái)說(shuō)是客戶。在子系統(tǒng)的內(nèi)部，DBMS的軟件組件可以分布在任意的ECU，利用分布式方法的優(yōu)點(diǎn)。 我們認(rèn)為，這種異構(gòu)的方法可以解決上述的所有缺點(diǎn)，是最適合汽車控制系統(tǒng)的方法。硬實(shí)時(shí)任務(wù)不能管理復(fù)雜的數(shù)據(jù)結(jié)構(gòu)，這個(gè)限制在實(shí)際中是相當(dāng)小的，因?yàn)橛矊?shí)時(shí)的組件通常是靜態(tài)的，之間的通信是相當(dāng)簡(jiǎn)單的數(shù)據(jù)結(jié)構(gòu)，當(dāng)一個(gè)數(shù)據(jù)庫(kù)被使用，硬實(shí)時(shí)任務(wù)需要可預(yù)測(cè)的執(zhí)行數(shù)據(jù)元素的存取。軟實(shí)時(shí)任務(wù)通過軟事務(wù)去讀或?qū)憚?dòng)態(tài)的、復(fù)雜的數(shù)據(jù)結(jié)構(gòu)，典型的像收集當(dāng)前的統(tǒng)計(jì)信息，日志或者作為系統(tǒng)更新時(shí)的服務(wù)接口。為了支持可預(yù)測(cè)的硬實(shí)時(shí)和軟實(shí)時(shí)任務(wù)，我們認(rèn)為一個(gè)汽車控制系統(tǒng)數(shù)據(jù)庫(kù)管理系統(tǒng)（VDMS）有兩個(gè)分離的接口，軟接口是利用規(guī)則的SQL查詢接口，保證從軟實(shí)時(shí)任務(wù)靈活的存取。圖 VDMS結(jié)構(gòu) 數(shù)據(jù)庫(kù)指針數(shù)據(jù)庫(kù)指針[12][13][36]可以不需要通過數(shù)據(jù)庫(kù)索引，快速、可預(yù)見地訪問數(shù)據(jù)庫(kù)中的數(shù)據(jù)。在數(shù)據(jù)庫(kù)通過數(shù)據(jù)庫(kù)指針來(lái)操作數(shù)據(jù)，不會(huì)破壞數(shù)據(jù)在邏輯和時(shí)間上的一致性，以及事務(wù)的串行性。硬實(shí)時(shí)任務(wù)一般是指是關(guān)系到安全關(guān)鍵問題的數(shù)據(jù)處理，或者是一些控制任務(wù)高頻執(zhí)行時(shí)所需要的數(shù)據(jù)，比如汽車發(fā)動(dòng)機(jī)控制系統(tǒng)中的發(fā)動(dòng)機(jī)轉(zhuǎn)速，發(fā)動(dòng)機(jī)注油量等，通過傳感器采集數(shù)據(jù)，然后由系統(tǒng)的I／O任務(wù)讀取，最后交給控制任務(wù)來(lái)進(jìn)行處理。對(duì)于控制系統(tǒng)中那些訪問頻率很高的熱點(diǎn)數(shù)據(jù)數(shù)據(jù)，往往與硬實(shí)時(shí)任務(wù)有關(guān)，如關(guān)鍵控制點(diǎn)的采樣數(shù)據(jù)等。 給出了一個(gè)I/O任務(wù)的例子，周期性的讀傳感器的值，然后通過數(shù)據(jù)庫(kù)指針傳送到數(shù)據(jù)庫(kù)中。這個(gè)任務(wù)包含兩部分，初始化部分（第2行至第4行），當(dāng)系統(tǒng)啟動(dòng)時(shí)執(zhí)行；周期性部分（第5至8行）實(shí)時(shí)掃描傳感器的值。這個(gè)由bind函數(shù)[14][36]執(zhí)行，調(diào)用數(shù)據(jù)庫(kù)的服務(wù)執(zhí)行查詢。1 TASK oilTemp(void){//Initialization part2 Int temp。4 Bind(amp。oil39。 //Control part5 While(1){6 Temp=readOilTempSensor()。8 waitForNextPeriod()。在這個(gè)操作中，只有幾行連續(xù)的代碼執(zhí)行類型檢查，與其他相同數(shù)據(jù)元素存取同步，并且寫操作被執(zhí)行。在每一個(gè)子系統(tǒng)中，根據(jù)不同子系統(tǒng)數(shù)據(jù)管理特性的不同，選擇不同的VDMS組件，分布在子系統(tǒng)中任意的ECU上，不同組件之間通過預(yù)先定于好的接口相互連接，為每一個(gè)子系統(tǒng)配置一個(gè)特殊的VDMS。圖 混合式系統(tǒng)模型在系統(tǒng)設(shè)計(jì)時(shí)，根據(jù)不同子系統(tǒng)性能需求，從組件庫(kù)中選擇合適的組件，借助配置工具，形成不同的VDMS配置結(jié)構(gòu)。系統(tǒng)運(yùn)行時(shí)，各個(gè)組件之間通過接口相互通信，每個(gè)子系統(tǒng)中的通信管理模塊負(fù)責(zé)系統(tǒng)的分布式事務(wù)處理。第4章 基于AUTOSAR的可配置VDMS系統(tǒng)設(shè)計(jì)在第三章我們介紹了適合汽車控制系統(tǒng)的混合式數(shù)據(jù)庫(kù)管理系統(tǒng)結(jié)構(gòu)模型，隨著AUTOSAR標(biāo)準(zhǔn)的提出，提高了軟件系統(tǒng)的標(biāo)準(zhǔn)化和開放化，減少了系統(tǒng)的復(fù)雜性，提高系統(tǒng)的可維護(hù)性，因?yàn)楫?dāng)前的汽車控制系統(tǒng)中缺少結(jié)構(gòu)化的數(shù)據(jù)管理技術(shù)，我們基于AUTOSAR標(biāo)準(zhǔn)，參照AUTOSAR的層次化構(gòu)架，利用AUTOSAR方法將一個(gè)基于組件的VDMS整合到AUTOSAR框架中，在VBF中定義各個(gè)組件之間的通信，按照AUTOSAR標(biāo)準(zhǔn)的接口定義VDMS組件的接口。VFB具體到一個(gè)系統(tǒng)是通過定義ECU的拓?fù)浣Y(jié)構(gòu)和網(wǎng)絡(luò)結(jié)構(gòu)，部署軟件組件到ECU，并得出通信矩陣內(nèi)部連接的分布式特性，這可以直接在某一階段或在兩個(gè)階段中實(shí)現(xiàn)。與系統(tǒng)描述同步的， 按照定義實(shí)現(xiàn)軟件組件滿足VFB的要求，在部署ECU時(shí)整合起來(lái)，注意：實(shí)現(xiàn)軟件組件幾乎和ECU配置獨(dú)立。基礎(chǔ)軟件模塊（BSW）和VFB獨(dú)立，他們可以在任何時(shí)候開發(fā)。 AUTOSAR軟件組件定義AUTOSAR軟件組件是完成某些功能的一個(gè)代碼集合，是AUTOSAR中可以部署在ECU上的最小代碼單元，AUTOSAR軟件組件具有原子性，就是說(shuō)一個(gè)軟件組件必須被分配在一個(gè)ECU上。軟件組件中的端口有四種類型，端口是通過接口來(lái)實(shí)例化得到的。Port3Port2Port1Software ComponentPort4圖 AUTOSAR軟件組件AUTOSAR （動(dòng)力，車身/舒適和底盤）的標(biāo)準(zhǔn)接口。 軟件組件描述文件模板根據(jù)AUTOSAR的定義，每一個(gè)軟件組件都對(duì)應(yīng)一個(gè)描述文件，AUTOSAR軟件組件描述包含了以下幾個(gè)信息[34][35]：（1）軟件組件提供和需要的操作，以及數(shù)據(jù)元素等內(nèi)部行為（2）軟件組件對(duì)于底層服務(wù)的需求（3）軟件組件所需要的資源(內(nèi)存，CPU時(shí)間等)（4）針對(duì)軟件組件的特定實(shí)現(xiàn)的信息AUTOSAR軟件組件描述的結(jié)構(gòu)和格式稱為“軟件組件模板”。AUTOSAR使用XML文件作為軟件組件和系統(tǒng)描述文件的格式，并通過定義一個(gè)XML Schema來(lái)定義XML文件需要遵循的語(yǔ)義規(guī)范。AUTOSAR軟件組件的通信是通過接口實(shí)例化產(chǎn)生的端口完成，端口必須成對(duì)出現(xiàn)，一個(gè)是提供數(shù)據(jù)或者服務(wù)端口，一個(gè)是需求數(shù)據(jù)或者服務(wù)端口。AUTOSAR中軟件組件的接口類型有兩種[33][34][35]：發(fā)送——接收接口：發(fā)送——接收接口中定義1個(gè)或多個(gè)數(shù)據(jù)元素。不同數(shù)據(jù)元素之間的定義相互獨(dú)立，所有的端口都可以對(duì)系統(tǒng)的數(shù)據(jù)進(jìn)行發(fā)送或者接收，一對(duì)端口之間不同數(shù)據(jù)元素之間的通信互不干擾。數(shù)據(jù)元素串行化發(fā)送，所有的數(shù)據(jù)被保存在隊(duì)列中，發(fā)送方發(fā)出的數(shù)據(jù)元素將在接收方依次被接收。而非串行化的數(shù)據(jù)元素發(fā)送方式中，接收方只接收最近一次收到的數(shù)據(jù)?？蛻舳恕?wù)器接口：客戶端——服務(wù)器端口中定義1個(gè)或多個(gè)操作，每個(gè)操作中有0個(gè)或多個(gè)IN、INOUT、OUT類型的參數(shù)。其中，IN類參數(shù)用于客戶端調(diào)用操作時(shí)候輸入?yún)?shù)的值；OUT類參數(shù)用于向客戶端返回調(diào)用的結(jié)果；INOUT類參數(shù)是輸入／輸入?yún)?shù)，既用來(lái)輸入?yún)?shù)值也用來(lái)返回結(jié)果值。表 端口類型名稱端口類型接口類型說(shuō)明發(fā)送端口提供端口發(fā)送——接收接口接收端口需求端口發(fā)送——接收接口服務(wù)器端口提供端口客戶——服務(wù)器接口客戶端端口需求端口客戶——服務(wù)器接口AUTOSAR中軟件組件的端口間的連接關(guān)系通過軟件組件外部的集合來(lái)實(shí)現(xiàn)，必須時(shí)同時(shí)連接一個(gè)供型端口和一個(gè)需型端口，并且這一對(duì)端口必須是同一個(gè)接口實(shí)例化出