【正文】 ARPACKAGE ARPACKAGE SHORTNAMEAUTOSAR/SHORTNAME LONGNAMEL4 L=ENAUTOSAR/L4/LONGNAME REFERENCEBASES REFERENCEBASE SHORTLABELARUnits/SHORTLABEL 。端口是由接口實(shí)例化的，有四種類型，由發(fā)送—接收接口實(shí)例化的發(fā)送端口、接收端口和由客戶端——服務(wù)器接口實(shí)例化的客戶端端口和服務(wù)器端口。通信時(shí)，客戶端對(duì)某個(gè)操作發(fā)出調(diào)用請(qǐng)求，服務(wù)器端收到客戶端請(qǐng)求后讀取調(diào)用中的輸入?yún)?shù)，實(shí)現(xiàn)請(qǐng)求的操作，然后用輸出參數(shù)將結(jié)果返回。發(fā)送方發(fā)出的數(shù)據(jù)，可能在沒(méi)有被接收方讀取便被更新到達(dá)的數(shù)據(jù)覆蓋從而沒(méi)有被讀取，也可能因?yàn)闆](méi)有新數(shù)據(jù)到達(dá)而被讀取兩次或多次。當(dāng)隊(duì)列未滿時(shí)，發(fā)出的數(shù)據(jù)都會(huì)被接收方收到，并且只讀取一次；當(dāng)隊(duì)列未滿時(shí)，發(fā)出的數(shù)據(jù)將被丟棄。數(shù)據(jù)元素發(fā)送方式分為串行化和非串行化兩種。每個(gè)數(shù)據(jù)元素對(duì)發(fā)送者和接受者之間傳遞的消息進(jìn)行定義，包括消息的數(shù)據(jù)類型和發(fā)送模式。并且這對(duì)端口必須由同一個(gè)接口定義來(lái)實(shí)例化產(chǎn)生。圖 軟件組件類型軟件組件的描述文件模板文件名為：模板文件的屬性定義為：xsd:schema xmlns:xsd= attributeFormDefault=unqualified elementFormDefault=qualified targetNamespace= xmlns:AR= xmlns:xml= xsd:import namespace= schemaLocation=/! AUTOSAR Schema Definition ....../xsd:schema圖 軟件組件描述文件模板 軟件組件接口類型這些功能性的軟件構(gòu)件的接口被明確定義，所定義的接口的內(nèi)容包括名稱，含義，范圍，數(shù)據(jù)類型，通信類型，單位等。軟件組件內(nèi)部是由若干個(gè)可以獨(dú)立調(diào)度的代碼片段構(gòu)成，稱為運(yùn)行實(shí)體(Runnable Entity)，是操作系統(tǒng)進(jìn)行任務(wù)調(diào)度的基本單位。AUTOSAR按照功能邏輯分別將這些領(lǐng)域的系統(tǒng)劃分成若干個(gè)模塊，這些模塊可被視為一個(gè)軟件構(gòu)件或多個(gè)軟件構(gòu)件的組合。在系統(tǒng)的設(shè)計(jì)階段，在接口模板中定義不同軟件組件之間的通信方法和內(nèi)容。不同軟件組件之間通過(guò)描述文件中所定義的端口進(jìn)行通信。當(dāng)基礎(chǔ)軟件模塊（BSW），ECU抽象，和應(yīng)用軟件組件都完成時(shí)，就可以開始整合一個(gè)AUTOSAR的ECU中，現(xiàn)階段ECU 通過(guò)建立任務(wù)，調(diào)度軟件組件，配置基礎(chǔ)軟件模塊等進(jìn)行配置的, 生成的代碼編譯和鏈接到一個(gè)可執(zhí)行文件。 這是AUTOSAR methodology的關(guān)鍵特性。 圖 AUTOSAR軟件設(shè)計(jì)流程在系統(tǒng)描述完成以后，主要是根據(jù)不同的ECU，提取不同的信息。 AUTOSAR系統(tǒng)設(shè)計(jì)流程開發(fā)一個(gè)AUTOSAR系統(tǒng)從定義VFB開始，VFB總線系統(tǒng)支持所有的功能，獨(dú)立于任何ECU和網(wǎng)絡(luò)。 小結(jié)本章介紹一種可配置的汽車控制系統(tǒng)數(shù)據(jù)庫(kù)管理系統(tǒng)框架，針對(duì)汽車控制系統(tǒng)嵌入式實(shí)時(shí)分布式的硬件環(huán)境，通過(guò)分析集中式和分布式的DBMS的優(yōu)缺點(diǎn)，知道這兩種框架不適合應(yīng)用在汽車控制環(huán)境中，我們利用集中式和分布式的優(yōu)點(diǎn)，基于組件技術(shù)，提出一種混合式的可配置適合汽車控制系統(tǒng)環(huán)境特性的數(shù)據(jù)管理系統(tǒng)框架。將VDMS組件分布在子系統(tǒng)中任意的ECU上，各個(gè)組件可以重用，如多個(gè)ECU都有硬實(shí)時(shí)任務(wù)需求，在這些ECU之上就需要配置數(shù)據(jù)庫(kù)指針模塊。子系統(tǒng)中每個(gè)VDMS中，都有一個(gè)通信管理組件，為不同子系統(tǒng)的VDMS提供可靠的通信服務(wù)功能，提供支持分布式事務(wù)管理的通信機(jī)制。 系統(tǒng)結(jié)構(gòu)和模型首先按照汽車控制系統(tǒng)功能的不同，將汽車電子劃分為不同的子系統(tǒng)，如動(dòng)力子系統(tǒng)，車身子系統(tǒng)等。 }}圖 使用數(shù)據(jù)庫(kù)指針的I/O任務(wù)在控制部分，write功能函數(shù)將新的值temp寫到數(shù)據(jù)庫(kù)指針中。7 Write(dbp,temp)。)。dbp, Select TEMP from ENGINEWhere SUBSYSTEM=39。3 DBPointer *dbp。然而返回值并不是一個(gè)有實(shí)際價(jià)值的查詢，在本例中，測(cè)量油溫，服務(wù)器返回的是一個(gè)實(shí)時(shí)的處理，可以被實(shí)時(shí)應(yīng)用程序用來(lái)執(zhí)行可預(yù)測(cè)的直接數(shù)據(jù)存取。在初始化部分，數(shù)據(jù)庫(kù)指針被創(chuàng)建，并且綁定數(shù)據(jù)元素在數(shù)據(jù)庫(kù)中。如發(fā)動(dòng)機(jī)中油溫的值。我們利用數(shù)據(jù)庫(kù)指針來(lái)執(zhí)行硬實(shí)時(shí)任務(wù)和操作熱點(diǎn)數(shù)據(jù)。這種類型的數(shù)據(jù)如果發(fā)生擁塞，將會(huì)導(dǎo)致整個(gè)系統(tǒng)的故障。將數(shù)據(jù)庫(kù)指針整合到一個(gè)數(shù)據(jù)庫(kù)管理系統(tǒng)中去，而不會(huì)破壞數(shù)據(jù)庫(kù)的完整性。它提供的數(shù)據(jù)訪問(wèn)接口類似于指針操作，非常適合于控制系統(tǒng)中的一些數(shù)據(jù)進(jìn)行高頻訪問(wèn)的操作。對(duì)于硬實(shí)時(shí)事務(wù)，則使用一個(gè)數(shù)據(jù)庫(kù)指針接口，保證應(yīng)用程序存取獨(dú)立的數(shù)據(jù)元素。軟實(shí)時(shí)任務(wù)可以被用來(lái)作為在運(yùn)行時(shí)的差錯(cuò)管理和執(zhí)行即時(shí)查詢。軟實(shí)時(shí)任務(wù)通常運(yùn)行在一個(gè)很低的頻率，控制非關(guān)鍵的功能。圖 混合式結(jié)構(gòu) 混合式數(shù)據(jù)庫(kù)管理系統(tǒng)體系結(jié)構(gòu)汽車控制系統(tǒng)是典型的實(shí)時(shí)系統(tǒng)，硬實(shí)時(shí)任務(wù)是用硬任務(wù)從傳感器/執(zhí)行器中讀和寫信號(hào)，執(zhí)行實(shí)時(shí)的循環(huán)控制。 其中某一DBMS對(duì)整個(gè)汽車控制系統(tǒng)的的數(shù)據(jù)都有一個(gè)全局的視圖，例如，如果某一段數(shù)據(jù)被傳動(dòng)控制子系統(tǒng)的DBMS上鎖了，其他子系統(tǒng)的DBMS不能對(duì)整個(gè)數(shù)據(jù)執(zhí)行寫操作直到他被解鎖。 混合式我們介紹的是將上述兩種方法混合起來(lái)，為每一個(gè)子系統(tǒng)建立一個(gè)DBMS，通過(guò)這樣的分離，我們可以根據(jù)不同子系統(tǒng)的功能，數(shù)據(jù)傳輸?shù)刃阅苄枨螅{(diào)整DBMS的功能，因此，優(yōu)化了整個(gè)系統(tǒng)的負(fù)載平衡。但是，一個(gè)ECU上的應(yīng)用程序可以訪問(wèn)其他節(jié)點(diǎn)上的數(shù)據(jù)。這樣，在分布式數(shù)據(jù)庫(kù)系統(tǒng)里，系統(tǒng)數(shù)據(jù)可以分布在不同的節(jié)點(diǎn)上，比如，將一部分?jǐn)?shù)據(jù)存放在一個(gè)節(jié)點(diǎn)上，而另一個(gè)部分的數(shù)據(jù)存放在其他的節(jié)點(diǎn)上。這些ECU位于（或分圖 分布式結(jié)構(gòu)布在）不同的地理位置并通過(guò)多種通信網(wǎng)絡(luò)連接在一起。然而，分布式數(shù)據(jù)庫(kù)系統(tǒng)可以更好地實(shí)現(xiàn)數(shù)據(jù)共享，超過(guò)了客戶/服務(wù)器系統(tǒng)可以達(dá)到的程度。總之，分布式方法還是比集中式DBMS適合一些，盡管這還有很大的優(yōu)化空間。這將導(dǎo)致高的數(shù)據(jù)傳輸。但是除了這些優(yōu)點(diǎn)之外，這種方法同樣有一些關(guān)鍵的缺點(diǎn)。其次，由于分布式，我們不再因?yàn)槟硞€(gè)ECU的資源限制而降低系統(tǒng)性能，這同樣是集中式DBMS的問(wèn)題。此外，一些軟件組件還可以在不同的ECU上面復(fù)用。這種方法能夠克服集中式DBMS的缺點(diǎn)。我們斷定，這樣以一個(gè)集中式的DBMS不適合汽車控制系統(tǒng)的要求 分布式這里的分布式與傳統(tǒng)的分布式數(shù)據(jù)庫(kù)系統(tǒng)不同，這種方法還是為整個(gè)汽車控制系統(tǒng)建立一個(gè)DBMS，但和集中式DBMS不同，首先按照基于組件的方法，將DBMS按照功能分解，然后將DBMS的軟件組件分布在整個(gè)系統(tǒng)的任意ECU之上，是DBMS軟件組件的“分布式”結(jié)構(gòu)。所以這種解決方法減少了汽車系統(tǒng)的效率和可靠性。如果系統(tǒng)中數(shù)據(jù)交換比較頻繁，DBMS可能運(yùn)行非常緩慢，將導(dǎo)致數(shù)據(jù)傳輸延遲或者丟失。（2）缺點(diǎn)：當(dāng)中心站點(diǎn)ECU或數(shù)據(jù)庫(kù)系統(tǒng)不能運(yùn)行時(shí)，在系統(tǒng)恢復(fù)之前所有用戶都不能使用系統(tǒng)。此外，并發(fā)控制策略或者其他的一些機(jī)制能夠被內(nèi)部操作，因?yàn)闆](méi)有其他的DBMS存在系統(tǒng)中，因此系統(tǒng)的最優(yōu)化應(yīng)該比較容易。圖 集中式結(jié)構(gòu)（1）優(yōu)點(diǎn)：這種系統(tǒng)主要的優(yōu)點(diǎn)是增強(qiáng)了系統(tǒng)的可維護(hù)性和可擴(kuò)展性。系統(tǒng)提供數(shù)據(jù)處理的能力，用戶可以在同樣的ECU上操作，也可以在網(wǎng)絡(luò)結(jié)構(gòu)中其他ECU上存取數(shù)據(jù)。圖 汽車控制系統(tǒng)結(jié)構(gòu)我們認(rèn)為在汽車控制系統(tǒng)中建立一個(gè)RTDBMS，有三種方法： 集中式，分布式以及混合式。在20世紀(jì)90年代初期，隨著強(qiáng)大的總線系統(tǒng)技術(shù)的引入，如CAN總線，使得電子系統(tǒng)網(wǎng)絡(luò)化，系統(tǒng)可以從各個(gè)傳感器接收信號(hào)。在早期的汽車電子技術(shù)應(yīng)用中，這些ECU的運(yùn)行很大程度上是獨(dú)立的。在系統(tǒng)中實(shí)現(xiàn)一個(gè)RTDBMS可以很好的解決這個(gè)問(wèn)題，例如采用組件技術(shù)的RTDBMS，但是目前的研究中并沒(méi)有考慮RTDBMS詳細(xì)的體系結(jié)構(gòu)。圖 基于組件的RTDBMS結(jié)構(gòu)嵌入式實(shí)時(shí)數(shù)據(jù)庫(kù)的體系結(jié)構(gòu)中可以利用組件的重用和替換功能， 這樣做具有以下好處： ①降低了數(shù)據(jù)庫(kù)系統(tǒng)的維護(hù)代價(jià)以及復(fù)雜程度②降低了系統(tǒng)開發(fā)成本，提高系統(tǒng)的可擴(kuò)展性③系統(tǒng)的功能更新將更簡(jiǎn)單， 對(duì)于新功能的需求可以增加的新組件到整個(gè)系統(tǒng)中[32]。 系統(tǒng)結(jié)構(gòu)按照系統(tǒng)的開發(fā)流程，根據(jù)不同節(jié)點(diǎn)數(shù)據(jù)管理需求的不同，可以選擇不同的組件和方面包，按照預(yù)先定義的組件接口類型，配置形成RTDBMS的基本結(jié)構(gòu)。并發(fā)控制包的代碼包括（i）TMC強(qiáng)制事務(wù)獲得鎖，在存取數(shù)據(jù)元素之前，完成時(shí)釋放，（ii）SMC保證撤銷的事務(wù)正常終止，（iii）LMC根據(jù)使用的沖突解決策略修改它的性能。CCA包括一個(gè)鎖管理組件（Locking Management Component，LMC）和并發(fā)控制包（Concurrency control aspect）LMC允許事務(wù)在數(shù)據(jù)元素上面取得讀/寫鎖。表 事務(wù)調(diào)度組件接口接口類型描述iSchedule提供接口事務(wù)調(diào)度接口iExecute需求接口事務(wù)執(zhí)行的接口圖 內(nèi)存管理組件接口UML圖（6）并發(fā)控制方面包：允許多個(gè)事務(wù)并發(fā)執(zhí)行。表 索引管理組件接口類型接口類型描述iIndex提供接口索引訪問(wèn)接口iMemory需求接口訪問(wèn)內(nèi)存數(shù)據(jù)元素接口圖 索引管理組件接口UML圖表 內(nèi)存管理組件接口類型接口類型描述iMemory提供接口訪問(wèn)內(nèi)存數(shù)據(jù)元素接口圖 內(nèi)存管理組件接口UML圖（5） 事務(wù)調(diào)度組件：主要根據(jù)事務(wù)類型和截止時(shí)間確定事務(wù)的優(yōu)先級(jí)，并根據(jù)優(yōu)先級(jí)調(diào)整事務(wù)執(zhí)行順序。表 用戶接口組件接口類型描述DBPointer提供接口為硬實(shí)時(shí)任務(wù)提供數(shù)據(jù)操作iSQL提供接口為軟實(shí)時(shí)任務(wù)提供數(shù)據(jù)操作iSchedule需求接口事務(wù)調(diào)度接口圖 用戶接口組件的接口UML圖表 事務(wù)管理組件接口定義接口類型描述iExecute提供接口事務(wù)執(zhí)行的接口iIndex需求接口訪問(wèn)所有的接口iChecked需求接口事務(wù)調(diào)度接口iLock需求接口訪問(wèn)數(shù)據(jù)庫(kù)鎖接口iMemory需求接口訪問(wèn)內(nèi)存數(shù)據(jù)元素接口圖 事務(wù)管理組件接口UML圖（3） 索引管理組件：負(fù)責(zé)維護(hù)數(shù)據(jù)庫(kù)中所有元組的索引，這通常是通過(guò)哈希表或索引樹實(shí)現(xiàn)的，一般是T樹和B+樹的索引結(jié)構(gòu)。事務(wù)管理組件中包含緩存管理組件，在事務(wù)運(yùn)行時(shí)管理緩沖區(qū)。用戶接口組件中保存所有活動(dòng)的事務(wù)列表，包括沒(méi)有提交或者回滾的事務(wù)。此外，接口還包括數(shù)據(jù)定義語(yǔ)言，允許用戶操作數(shù)據(jù)庫(kù)模式，例如：創(chuàng)建或者刪除關(guān)系表。圖 基于組件的RTDBMS配置流程 組件設(shè)計(jì)（1） 用戶接口組件：用戶接口組件包括數(shù)據(jù)庫(kù)指針模塊和SQL查詢接口模塊。根據(jù)嵌入式實(shí)時(shí)數(shù)據(jù)庫(kù)系統(tǒng)的特征，按照CBSD和AOSD的方法，分解汽車控制系統(tǒng)RTDBMS可以得到如下基本組件[36]：（1） 用戶接口組件：（2） 事務(wù)管理組件（3） 索引管理組件（4） 內(nèi)存管理組件（5） 事務(wù)調(diào)度組件然后，一個(gè)RTDBMS還有其他的一些功能，并發(fā)控制，日志，和系統(tǒng)恢復(fù)等，不能被獨(dú)立的劃分為組件，他們的實(shí)現(xiàn)必須分散到系統(tǒng)中其他的組件中，我們按照面向方面的軟件開發(fā)（AOSD），將這些不能被分割成獨(dú)立的活動(dòng)部分，稱為橫切關(guān)注點(diǎn)，將它封裝到方面包（Aspect package）中，它包括方面和組件。一個(gè)組件提供的接口是其他組件所需求的接口，提供一個(gè)接口的模塊可能服務(wù)于多個(gè)模塊， 如在供應(yīng)接口和需求接口中存在一對(duì)多的關(guān)系。（3）組件的集成，將創(chuàng)建好的組件集成在一起，構(gòu)成應(yīng)用系統(tǒng)[29]。 主要實(shí)現(xiàn)步驟如下：（1）劃分組件，按照功能將數(shù)據(jù)庫(kù)分解成功能獨(dú)立的組件。通過(guò)AOP開發(fā)人員不僅有效地解決了系統(tǒng)中由于橫切屬性引起的“代碼混亂”和“代碼分散”等問(wèn)題，使得代碼更加簡(jiǎn)單、更易于維護(hù)，大大提高了系統(tǒng)的模塊性和重用性。當(dāng)前主流的“適合所有的單一解決方案”數(shù)據(jù)庫(kù)設(shè)計(jì)中，實(shí)現(xiàn)定制化的代價(jià)可能是昂貴的：因?yàn)橄到y(tǒng)缺乏變化會(huì)影響局部化的模塊化的特性。傳統(tǒng)的軟件開發(fā)將系統(tǒng)分解為主要的功能單元，識(shí)別出關(guān)注點(diǎn)的其他問(wèn)題，使程序員不但能編寫主要功能的代碼模塊，還要確保有關(guān)注點(diǎn)的其他問(wèn)題在代碼的適當(dāng)位置進(jìn)行處理。 基于方面的軟件開發(fā)面向方面的軟件開發(fā)（AOSD）[42]是一系列的新型技術(shù)，用以尋找軟件系統(tǒng)中新的模塊化的特性。組件都被合成（組裝）到應(yīng)用中，例如，組合它們來(lái)提供所期望的行為。組件開發(fā)系統(tǒng)關(guān)注的是將組件裝配來(lái)滿足系統(tǒng)的需求。在維護(hù)性階段，添加新的組件，升級(jí)現(xiàn)有的組件是很常見的行為。CBSE通過(guò)組件重用和簡(jiǎn)化以及并行組件開發(fā)能夠縮短軟件開發(fā)的時(shí)間。它定義技術(shù)所支持的不同類型的組件，組件之間可能的交互方案，并闡明為什么要將不同的資源組裝成組件，供應(yīng)商在制造區(qū)塊時(shí)，區(qū)塊也遵循了組件模型，以確保區(qū)塊符合他們所支持對(duì)方各種托盤。組件技術(shù)是一種具體實(shí)現(xiàn)組件模式的一個(gè)組成部分。雖然對(duì)軟件組件，組件框架通常處理組件交互，并調(diào)用組件所提供的服務(wù)，除了提供經(jīng)常使用范圍內(nèi)的服務(wù)，還提供在應(yīng)用領(lǐng)域有針對(duì)性的技術(shù)。在游樂(lè)場(chǎng)圖比喻中，區(qū)塊代表組件，托盤上的展臺(tái)代表了提供組件支持的框架，圖上站立的托盤在代表執(zhí)行平臺(tái)。這是在游樂(lè)場(chǎng)的一張平面照片，放在托盤上不同的積木可以被安排在不同的組合，該游樂(lè)場(chǎng)圖將在下列描述的技術(shù)概念中用作組件技術(shù)的比喻。組件都被合成（組裝）到應(yīng)用中，例如，組合它們來(lái)提供所期望的行為。傳統(tǒng)的軟件工程學(xué)科需要新的方法學(xué)支持基于組件的開發(fā)。 基于組件的軟件開發(fā)基于組件的軟件工程（CBSE）的主要任務(wù)是從事把部件（組件）集成為系統(tǒng)的開發(fā)，這種開發(fā)中部件作為可重用實(shí)