【正文】 體，系統(tǒng)的維護和更新是通過定制和替換這些部件來實現(xiàn)的。雖然組件技術(shù)已經(jīng)在不同的要求和領(lǐng)域中得到發(fā)展，但是很少有針對以安全為具體要求的嵌入式實時系統(tǒng)的組件技術(shù)。因此，采用軟件開發(fā)模式提高軟件開發(fā)效率變得重要。從歷史上看，這種系統(tǒng)的發(fā)展只使用低級編程語言，以保證對系統(tǒng)性能的充分控制。 小結(jié)本章首先介紹了汽車控制系統(tǒng)的特點，汽車控制系統(tǒng)的數(shù)據(jù)管理的特性進行了詳細分析，然后著重闡述了AUTOSAR標準，介紹了AUTOSAR標準軟件構(gòu)架，AUTOSAR方法和標準接口，說明AUTOSAR標準在汽車電子軟件開發(fā)中的重要性。 （3）“Command”的數(shù)據(jù)類型為“t_onoff”。針對CmdWashing接口定義了以下信息： （1）CmdWashing接口由WiperWasherManager構(gòu)件提供，其數(shù)據(jù)內(nèi)容為FrontWasher構(gòu)件的Activation接口所使用。 這里以車身/舒適系統(tǒng)的雨刷管理的軟件構(gòu)件的接口定義為示例。AUTOSAR按照功能邏輯分別將這些領(lǐng)域的系統(tǒng)劃分成若干個模塊，這些模塊可被視為一個軟件構(gòu)件或多個軟件構(gòu)件的組合，這些功能性的軟件構(gòu)件的接口被明確定義，所定義的接口的內(nèi)容包括名稱，含義，范圍，數(shù)據(jù)類型，通信類型，單位等。 AUTOSAR標準接口通過RTE實現(xiàn)AUTOSAR軟件構(gòu)件（即應用程序）相互間的通信以及軟件構(gòu)件與基礎(chǔ)軟件之間的通信的前提是，軟件構(gòu)件必須具有標準的AUTOSAR接口。軟件構(gòu)件本身對于這種區(qū)別并不關(guān)注，因此我們可以在獨立的情況下開發(fā)軟件構(gòu)件。虛擬功能總線（Virtual Functional Bus）將AUTOSAR軟件構(gòu)件相互間的通信以及軟件構(gòu)件與基礎(chǔ)軟件之間的通信進行了抽象，同時使用預先定義的標準接口。最后一步是生成具體ECU的可執(zhí)行程序，此步將根據(jù)ECU 配置描述文件中的配置信息構(gòu)建完成ECU的基礎(chǔ)軟件的設(shè)置和與基于AUTOSAR構(gòu)件的應用軟件的集成，最終生成ECU的可執(zhí)行代碼。然后進入ECU配置的實際工作中，這一步負責往輸入對象中添加具體應用所必需的信息，如任務調(diào)度、必要的BSW模塊、BSW配置信息、給任務分配的可運行實體等。首先是使用第一個階段的工作成果——系統(tǒng)配置描述文件，從中提取出與各個ECU相關(guān)的系統(tǒng)配置描述信息，提取的信息包括ECU通信矩陣、拓撲結(jié)構(gòu)、頂級功能組合（據(jù)此產(chǎn)生需映射到該ECU上的所有軟件構(gòu)件），將放在另一個XML文件中。該文件將包含所有的系統(tǒng)信息，包括將軟件構(gòu)件映射到相關(guān)的ECU上（這種映射需要考慮到構(gòu)件的需要、構(gòu)件的連接、資源需求以及約束條件，有時也需要考慮成本等方面的因素），以及通信矩陣（整車的網(wǎng)絡(luò)結(jié)構(gòu)、時序以及網(wǎng)絡(luò)數(shù)據(jù)幀的內(nèi)容）。 系統(tǒng)配置輸入包含三部分內(nèi)容，第一個輸入是軟件構(gòu)件描述，定義每個需要的軟件構(gòu)件的接口內(nèi)容，包括數(shù)據(jù)類型，端口，接口等；第二個輸入是ECU資源描述，定義了每個ECU的資源需求，如處理器、外部設(shè)備、存儲器、傳感器和執(zhí)行器等；第三個輸入是系統(tǒng)約束描述，定義總線信號，拓撲結(jié)構(gòu)和軟件構(gòu)件的映射關(guān)系。應用軟件的描述術(shù)語在AOTUSAR中為軟件構(gòu)件（Software Components），該文件將確定需要使用的軟件構(gòu)件（即系統(tǒng)具有哪些功能）和硬件資源（ECU），以及整個系統(tǒng)的約束條件。 圖 AUTOSAR系統(tǒng)設(shè)計與開發(fā)流程主要步驟可劃分兩個階段： 第一個階段是系統(tǒng)配置階段，這屬于系統(tǒng)級設(shè)計決策工作。汽車OEM作為整車系統(tǒng)功能的規(guī)劃和設(shè)計者，需要了解并掌握AUTOSAR提供的這套開發(fā)流程，才能主導和推進符合AUTOSAR標準的系統(tǒng)的開發(fā)過程。RTE層之下的基礎(chǔ)軟件對于應用層來說是不可見的，必須通過RTE進入，它將軟件構(gòu)件從對底層軟件和硬件平臺的依賴中獨立出來，實現(xiàn)了應用程序和基礎(chǔ)軟件之間的分隔。（3）微控制器抽象層，包括微控制器相關(guān)的驅(qū)動（如I/O驅(qū)動、ADC驅(qū)動等）。 （2）ECU抽象層，對 ECU（如外設(shè)與ECU的連接方式等）進行抽象處理。 （1）服務層，為應用層提供診斷協(xié)議、存儲管理、ECU模式管理和操作系統(tǒng)等系統(tǒng)服務?；A(chǔ)軟件組件（BSW）分為下面幾個層次：服務層（Services Layer）、ECU抽象層（ECU Abstraction Layer）和微控制器抽象層（Microcontroller Abstraction Layer）。 AUTOSAR標準軟件構(gòu)架AUTOSAR的目標是實現(xiàn)應用程序和基礎(chǔ)軟件模塊之間的分離，因此汽車電子軟件架構(gòu)被抽象成幾個層。盡管如此，標準化的汽車電子軟件開發(fā)方法和軟件架構(gòu)是汽車行業(yè)未來不可阻擋的發(fā)展趨勢，而且目前還沒有哪種標準比AUTOSAR標準走的更遠。AUTOSAR倡導的原則是“在標準上合作，在實現(xiàn)上競爭”，其核心思想在于“統(tǒng)一標準、分散實現(xiàn)、集中配置”，所以采用AUTOSAR將為OEM帶來發(fā)展機遇，隨著汽車電子軟件的標準化和開放化，更多的供應商可以進入到汽車電子行業(yè)中來， 這將使得OEM可以更加靈活的進行軟件采購，有更多的選擇，同時軟件的質(zhì)量監(jiān)督也會相應提高，有利于提高汽車電子軟件的產(chǎn)品質(zhì)量。例如在寶馬7系量產(chǎn)車型中，已經(jīng)開發(fā)了符合AUTOSAR標準的ECU，預計在2011年AUTOSAR的所有核心成員都將開發(fā)出相關(guān)的產(chǎn)品。AUTOSAR定義了一套支持分布式的、功能驅(qū)動的汽車電子軟件開發(fā)方法，提出了軟件架構(gòu)標準化方案，加強不同平臺之間的軟件復用，從而降低開發(fā)成本。 AUTOSAR標準AUTOSAR（AUTomotive Open Systems ARchitecture）汽車開放系統(tǒng)架構(gòu)，是由多家汽車整車廠商和供應商在2003年夏天成立的汽車電子軟件開發(fā)全球合作聯(lián)盟，其目的就在于降低汽車軟件的復雜性和多樣性，提高軟件復用。那么運行在電子控制單元上的軟件也屬于嵌入式軟件軟件。這些電子控制單元大多是由資源有限，計算能力很小的處理器組成。并且自從嵌入式計算機被引入到汽車中，汽車功能迅速增加，軟件的復雜性也迅速提升。偶爾執(zhí)行超期或失敗的事務一般不會對系統(tǒng)造成致命影響，這類事務稱為軟實時事務。（2）從任務或事物的關(guān)鍵程度可以將其分為：硬實時事務，軟實時事務。同時又由于子系統(tǒng)的處理器是單核的，因此在同一時間內(nèi)需要處理很多的任務，這就需要任務的調(diào)度。例如，從傳感器讀取數(shù)據(jù)的任務隨著系統(tǒng)的運行，不斷的讀取環(huán)境參數(shù)，傳遞給其它任務處理。因此，任務執(zhí)行超期以后，任務所操作的數(shù)據(jù)就不是可信的，汽車控制系統(tǒng)中的數(shù)據(jù)也是具有時間限制的特點。（2）資源消耗最小化：車輛控制系統(tǒng)中的數(shù)據(jù)管理機制應該盡可能的高效，體現(xiàn)在內(nèi)存需求量和CPU使用率上。因此需要一種統(tǒng)一的、高效的方式存儲和管理數(shù)據(jù)，嵌入式實時數(shù)據(jù)庫可以滿足系統(tǒng)的實際要求。一些共享的數(shù)據(jù)元素被不同的應用程序單獨處理，導致軟件在開發(fā)和維護中出現(xiàn)了很多問題，對汽車的安全，舒適性造成了影響。 汽車控制系統(tǒng)數(shù)據(jù)管理特性分析隨著微電子硬件的價格大幅下降、硬件性能的顯著提升和國家對汽車的安全、環(huán)保規(guī)范的日益嚴格使得汽車中所使用的電子控制單元日益增多，甚至已達到近百個，并且汽車功能的復雜性也大大增加了，這使得軟件開發(fā)和維護日益困難。汽車上常用的ECU包括8位機（Intel MCS8048，MCS8049，MCS8032；Motorola的MC68HCII），16位機（Intel的MCS8097，Motorola的MC68HC12，MC68HC16），最近GM公司在Buick車上已采用32位機（Motorola 68332，它有512K ROM，14K RAM）。}}圖 共享變量的I/O任務汽車控制系統(tǒng)，除了是實時系統(tǒng)，還是嵌入式系統(tǒng)。7 signal(engine_semaphore)。5 wait(engine_semaphore)。...//End global data1 TASK OilTempReader(void){2 int s。struct engine_t engine。int waterTemperature。int oilTemperature。在一些關(guān)鍵領(lǐng)域，如自動駕駛、防抱死剎車系統(tǒng)等，離線調(diào)度比在線調(diào)度安全。在系統(tǒng)運行時，運行時刻表不再變化，調(diào)度器根據(jù)這張時刻表啟動相應的任務，調(diào)度被循環(huán)執(zhí)行，因此系統(tǒng)是周期性的。大部分的實時系統(tǒng)，包括汽車控制系統(tǒng)中對任務的調(diào)度往往是離線調(diào)度和周期性調(diào)度。事務超過截止期，很少能影響系統(tǒng)的服務質(zhì)量。很多汽車控制系統(tǒng)的功能有硬實時的需求。 給定了一個端到端的截止期，就是說程序執(zhí)行結(jié)果必須在規(guī)定的時間內(nèi)產(chǎn)生。從輸入到輸出的延遲時間必須足夠小，在可接受的時效性之內(nèi)。延遲時間必須在截止日期內(nèi)才是可以接受的，否則不能保證計算結(jié)果執(zhí)行的正確性。實時系統(tǒng)考慮數(shù)據(jù)及其處理相關(guān)聯(lián)的定時限制，也就是任務中的數(shù)據(jù)只是在一定的時間內(nèi)有效。 展示了一個例子：I/O任務負責讀溫度傳感器的值，然后將它寫到一個共享變量中，共享變量通過一個信號量保證它的完整性，例如，在更新時不能被執(zhí)行讀操作。圖 展示了幾個任務一起執(zhí)行一個控制功能。（2）控制任務：用來執(zhí)行控制決策。車輛控制系統(tǒng)中典型的任務包括：I/O任務、控制任務、管理任務等。OSEK/VDX為控制單元應用程序提供統(tǒng)一的通信環(huán)境，應用程序可以通過它與不論是否在同一個ECU上的應用程序傳遞消息，例如通過CAN, FlexRay[43]總線。例如,車速超過24KM/H，車門自動落鎖，就涉及到動力（速度參數(shù)來自于動力系統(tǒng)）和車身兩個子系統(tǒng)。典型的汽車控制系統(tǒng)是由一系列的車載計算機構(gòu)成的節(jié)點組成。 汽車控制系統(tǒng)在最近三十年中，汽車的控制系統(tǒng)已經(jīng)從簡單的單處理器系統(tǒng)變成了復雜的分布式系統(tǒng)，現(xiàn)在汽車的很多功能都是由車載計算機控制系統(tǒng)實現(xiàn)的。第五章，研究虛實結(jié)合的汽車電子實驗環(huán)境，通過PC機模擬汽車物理部件或者模擬ECU，通過串口將虛擬部件連接到轉(zhuǎn)換芯片上面，形成虛擬的車身電子網(wǎng)絡(luò), 將VDMS應用在安全氣囊系統(tǒng)中，分析系統(tǒng)的性能。第四章，研究如何將VDMS整合到AUTOSAR環(huán)境中，兼容AUTOSAR的特性，給出VDMS的系統(tǒng)模型。 第三章，介紹如何按照組件技術(shù)，將RTDBMS按照功能進行分解形成組件庫，形成一個可剪裁的RTDBMS。第二章，介紹汽車控制系統(tǒng)數(shù)據(jù)管理的背景知識，對汽車控制系統(tǒng)的特點進行了分析，描述了汽車控制系統(tǒng)中數(shù)據(jù)管理的特性。通過PC機模擬汽車物理部件或者模擬ECU，通過串口將虛擬部件連接到轉(zhuǎn)換芯片上面，形成虛擬的車身電子網(wǎng)絡(luò), 將VDMS模塊應用在在安全氣囊控制系統(tǒng)中。（2） 研究如何將基于組件的可配置的VDMS整合到AUTOSAR環(huán)境中，按照AUTOSAR標準體系框架，定義VDMS軟件組件以及描述文件，設(shè)計VDMS在AUTOSAR環(huán)境中的結(jié)構(gòu)模型。本文提出一種基于組件的混合式汽車控制系統(tǒng)數(shù)據(jù)管理系統(tǒng)模型（VDMS），然后按照AUTOSAR標準軟件層次構(gòu)架，AUTOSAR方法論以及標準接口，研究如何將VDMS整合到AUTOSAR環(huán)境中，實現(xiàn)對系統(tǒng)數(shù)據(jù)的統(tǒng)一管理，兼容AUTOSAR的標準。AUTOSAR將汽車電子軟件架構(gòu)分成若干層和模塊，為各個模塊提供標準的接口定義，同時AUTOSAR定義了軟件組件開發(fā)標準，以及易于交換的硬件平臺標準。目前對于汽車控制系統(tǒng)數(shù)據(jù)管理技術(shù)的研究，仍然沒有形成一個統(tǒng)一有效的數(shù)據(jù)管理的標準，隨著汽車功能越來越復雜，系統(tǒng)分布式異構(gòu)的硬件環(huán)境，系統(tǒng)開發(fā)和維護代價極大。CBSE也支持維護性，基本原理是軟件應用都是由組件構(gòu)成。本文針對汽車控制系統(tǒng)的數(shù)據(jù)庫系統(tǒng)進行了研究。 論文的工作綜上所述，汽車控制系統(tǒng)是一個嵌入式實時的異構(gòu)系統(tǒng)，通過對汽車控制系統(tǒng)數(shù)據(jù)管理的需求進行分析發(fā)現(xiàn)，通用的數(shù)據(jù)管理的方法不適合汽車控制系統(tǒng)嵌入式實時的特性。組件規(guī)范及組成，提供了組件模型，其中包括了安全性組件和支持協(xié)助部分的基礎(chǔ)設(shè)施的基本特征，技術(shù)分析和驗證功能的正確性，實時性，安全性和可靠性，運行時的配置支持，包括系統(tǒng)內(nèi)裝配的支持、監(jiān)測時間和可替換配件的評估。通過與2PLHP算法進行性能比較，得出2VDBP與2VDBP SNAP能夠更好的提高系統(tǒng)性能，降低事務沖突和響應時間。將數(shù)據(jù)庫指針整合到一個數(shù)據(jù)庫管理系統(tǒng)中去，而不會破壞數(shù)據(jù)庫的完整性。它提供的數(shù)據(jù)訪問接口類似于指針操作，非常適合于控制系統(tǒng)中的一些數(shù)據(jù)進行高頻訪問的操作。文獻[12]中針對實時數(shù)據(jù)庫系統(tǒng)硬事務和軟事務的要求，提出了數(shù)據(jù)庫指針（Database Pointer）的概念，它可以很好的提高事務的處理效率。按照配置工具集，針對不同的電子控制單元對數(shù)據(jù)管理的不同需求，選擇不同的組件形成不同配置的數(shù)據(jù)庫管理系統(tǒng)。按照CBSD的方法，組件封裝不同的數(shù)據(jù)庫功能，按照AOSD對軟件系統(tǒng)中多種關(guān)注點進行獨立描述，比如并發(fā)控制，日志，和系統(tǒng)恢復等功能，他們的實現(xiàn)必須分散到系統(tǒng)中其他的組件中，稱為橫切關(guān)注點，對橫切關(guān)注點進行封裝、管理，形成方面包。文獻[10]介紹了一個可配置的實時數(shù)據(jù)庫平臺——COMET，由瑞典的馬拉達倫大學和林雪平大學通過與沃爾沃汽車公司聯(lián)合開發(fā)的。針對現(xiàn)有的應用軟件分離出以數(shù)據(jù)為中心的任務，并在此基礎(chǔ)上抽象并提出了數(shù)據(jù)庫管理系統(tǒng)的模型。由于嵌入式數(shù)據(jù)庫系統(tǒng)常常需要對外界環(huán)境作出實時反應，比如在汽車控制系統(tǒng)中，系統(tǒng)必須同時具備實時性、主動性和嵌入式的特點，所以需要開發(fā)一種適合這種嵌入式實時環(huán)境的嵌入式實時數(shù)據(jù)庫系統(tǒng)。系統(tǒng)性能指標只定時限制事務的完成率，它可以犧牲數(shù)據(jù)的準確性與一致性以保證硬實時事務能夠在截止期前能夠完成。實時數(shù)據(jù)庫是指事務和數(shù)據(jù)都定時限制，系統(tǒng)的正確性不僅要滿足事務執(zhí)行的邏輯結(jié)果，又要滿足時間約束[7]。嵌入式數(shù)據(jù)庫在嵌入式系統(tǒng)中越來越常見，主要是用于存儲和處理所在設(shè)備和其他地方的數(shù)據(jù)，可以訪問監(jiān)視器、進行系統(tǒng)診斷以及其他工作。AUTOSAR標準的目的是為軟件開發(fā)流程通過通過工具提供通用的支持，使得開發(fā)人員可以在對硬件一無所知的情況下進行應用軟件的開發(fā)，并將這個軟件應用在任何符合AUTOSAR標準的ECU中，實現(xiàn)應用程序重用[49]。AUTOSAR (AU TOmotive Open System Architecture：汽車開放系統(tǒng)體系結(jié)構(gòu))標準，降低了ECU軟件開發(fā)的復雜度，提高了軟件