【文章內(nèi)容簡(jiǎn)介】 及人為的干涉，這些系統(tǒng)通常稱為安全關(guān)鍵系統(tǒng)。很多汽車控制系統(tǒng)的功能有硬實(shí)時(shí)的需求。軟實(shí)時(shí)系統(tǒng)：僅要求時(shí)間響應(yīng)是實(shí)時(shí)的，并不要求限定某一任務(wù)在多長(zhǎng)時(shí)間內(nèi)完成。事務(wù)超過(guò)截止期，很少能影響系統(tǒng)的服務(wù)質(zhì)量。對(duì)于汽車控制系統(tǒng)，管理任務(wù)通常被視為軟實(shí)時(shí)的。大部分的實(shí)時(shí)系統(tǒng)，包括汽車控制系統(tǒng)中對(duì)任務(wù)的調(diào)度往往是離線調(diào)度和周期性調(diào)度。在一個(gè)離線調(diào)度的系統(tǒng)中，系統(tǒng)運(yùn)行前根據(jù)各任務(wù)的時(shí)間約束及關(guān)聯(lián)關(guān)系，采用搜索策略生成一張類似于列車運(yùn)行時(shí)刻表的任務(wù)運(yùn)行時(shí)刻表，指明了各任務(wù)的起始運(yùn)行時(shí)刻及運(yùn)行時(shí)間。在系統(tǒng)運(yùn)行時(shí)，運(yùn)行時(shí)刻表不再變化，調(diào)度器根據(jù)這張時(shí)刻表啟動(dòng)相應(yīng)的任務(wù)，調(diào)度被循環(huán)執(zhí)行，因此系統(tǒng)是周期性的。在一些安全關(guān)鍵領(lǐng)域，例如汽車和航空領(lǐng)域，離線調(diào)度系統(tǒng)被認(rèn)為比在線調(diào)度更安全，這樣做是為了在軟件開(kāi)發(fā)設(shè)計(jì)時(shí)就明確任務(wù)的最壞執(zhí)行時(shí)間，保證實(shí)時(shí)系統(tǒng)中的任務(wù)執(zhí)行是可控制與預(yù)期的。在一些關(guān)鍵領(lǐng)域，如自動(dòng)駕駛、防抱死剎車系統(tǒng)等，離線調(diào)度比在線調(diào)度安全。//Global datastruct {int oilPressure。int oilTemperature。int waterPressure。int waterTemperature。} engine_t。struct engine_t engine。semaphore engine_semaphore。...//End global data1 TASK OilTempReader(void){2 int s。3 while(1){4 s=read_sensor()。5 wait(engine_semaphore)。6 =s。7 signal(engine_semaphore)。8 waitForNextPeriod()。}}圖 共享變量的I/O任務(wù)汽車控制系統(tǒng)，除了是實(shí)時(shí)系統(tǒng)，還是嵌入式系統(tǒng)?？紤]到成本問(wèn)題，汽車中所用的電子控制單元都是運(yùn)算處理速度有限、硬件資源有限的單片機(jī)。汽車上常用的ECU包括8位機(jī)（Intel MCS8048，MCS8049，MCS8032；Motorola的MC68HCII），16位機(jī)（Intel的MCS8097，Motorola的MC68HC12，MC68HC16），最近GM公司在Buick車上已采用32位機(jī)（Motorola 68332，它有512K ROM，14K RAM）。這就要求汽車控制系統(tǒng)必須具有最小資源消耗的特點(diǎn)，具體表現(xiàn)為盡可能少的內(nèi)存占用以及CPU的利用。 汽車控制系統(tǒng)數(shù)據(jù)管理特性分析隨著微電子硬件的價(jià)格大幅下降、硬件性能的顯著提升和國(guó)家對(duì)汽車的安全、環(huán)保規(guī)范的日益嚴(yán)格使得汽車中所使用的電子控制單元日益增多，甚至已達(dá)到近百個(gè)，并且汽車功能的復(fù)雜性也大大增加了，這使得軟件開(kāi)發(fā)和維護(hù)日益困難。汽車控制系統(tǒng)所需處理的信息大約以每年7％的速度在增長(zhǎng)[1]。一些共享的數(shù)據(jù)元素被不同的應(yīng)用程序單獨(dú)處理，導(dǎo)致軟件在開(kāi)發(fā)和維護(hù)中出現(xiàn)了很多問(wèn)題，對(duì)汽車的安全，舒適性造成了影響。不同的應(yīng)用程序存取數(shù)據(jù)可能導(dǎo)致數(shù)據(jù)不一致或者數(shù)據(jù)不可用。因此需要一種統(tǒng)一的、高效的方式存儲(chǔ)和管理數(shù)據(jù)，嵌入式實(shí)時(shí)數(shù)據(jù)庫(kù)可以滿足系統(tǒng)的實(shí)際要求。針對(duì)汽車控制系統(tǒng)嵌入式實(shí)時(shí)的特性，汽車控制系統(tǒng)的數(shù)據(jù)管理，必須至少滿足以下兩點(diǎn)：（1）時(shí)間的可預(yù)見(jiàn)性：應(yīng)該盡可能的一直在一定的時(shí)間內(nèi)存取和操作數(shù)據(jù)。（2）資源消耗最小化：車輛控制系統(tǒng)中的數(shù)據(jù)管理機(jī)制應(yīng)該盡可能的高效，體現(xiàn)在內(nèi)存需求量和CPU使用率上。 實(shí)時(shí)特點(diǎn)汽車控制系統(tǒng)需要根據(jù)外界環(huán)境的變化，而在系統(tǒng)規(guī)定的時(shí)間期限內(nèi)完成相應(yīng)的動(dòng)作。因此，任務(wù)執(zhí)行超期以后，任務(wù)所操作的數(shù)據(jù)就不是可信的，汽車控制系統(tǒng)中的數(shù)據(jù)也是具有時(shí)間限制的特點(diǎn)。圍繞著數(shù)據(jù)的實(shí)時(shí)特點(diǎn)，有如下方面的研究：（1）從汽車的實(shí)際運(yùn)行情況看，處理數(shù)據(jù)的任務(wù)或者事務(wù)在整個(gè)運(yùn)行過(guò)程中都是周期性的。例如，從傳感器讀取數(shù)據(jù)的任務(wù)隨著系統(tǒng)的運(yùn)行，不斷的讀取環(huán)境參數(shù)，傳遞給其它任務(wù)處理。一個(gè)控制子系統(tǒng)中含有數(shù)千個(gè)傳感器，由很多個(gè)任務(wù)負(fù)責(zé)周期性的讀取，但是這些任務(wù)的讀取頻率是不同的。同時(shí)又由于子系統(tǒng)的處理器是單核的，因此在同一時(shí)間內(nèi)需要處理很多的任務(wù)，這就需要任務(wù)的調(diào)度。設(shè)計(jì)一個(gè)好的任務(wù)調(diào)度算法，使任務(wù)能在規(guī)定時(shí)間內(nèi)完成。（2）從任務(wù)或事物的關(guān)鍵程度可以將其分為：硬實(shí)時(shí)事務(wù)，軟實(shí)時(shí)事務(wù)。關(guān)鍵性的任務(wù)如果不能在規(guī)定時(shí)間內(nèi)完成可能會(huì)造成系統(tǒng)崩潰；對(duì)于汽車來(lái)講，硬實(shí)時(shí)任務(wù)執(zhí)行超期，可能會(huì)造成交通事故。偶爾執(zhí)行超期或失敗的事務(wù)一般不會(huì)對(duì)系統(tǒng)造成致命影響，這類事務(wù)稱為軟實(shí)時(shí)事務(wù)。 嵌入式特點(diǎn)目前汽車的制動(dòng)等越來(lái)越多的由電子設(shè)備所控制。并且自從嵌入式計(jì)算機(jī)被引入到汽車中，汽車功能迅速增加，軟件的復(fù)雜性也迅速提升。汽車的這些特性大多是由微電子控制單元控制的。這些電子控制單元大多是由資源有限，計(jì)算能力很小的處理器組成。但是在最近十多年，隨著硬件水平提高和成本下降的影響，它們的資源也有了大幅的提升，：表 ECU硬件性能提升 類別 1994年 2008年控制單元個(gè)數(shù) 40 60頻率 85 2000控制單元內(nèi)存+160KB19MB+晶體管數(shù)據(jù)2100萬(wàn)3億4千萬(wàn)總線帶寬700k位/秒32M位/秒從上表可以看出，雖然電子控制單元的硬件性能有了大幅提升，但是電子控制單元本質(zhì)上仍是資源有限，計(jì)算能力小的嵌入式設(shè)備。那么運(yùn)行在電子控制單元上的軟件也屬于嵌入式軟件軟件。但若從嵌入式的角度看，汽車控制系統(tǒng)的軟件要求代碼在完成規(guī)定功能的基礎(chǔ)上，代碼規(guī)模盡量小，另外不同功能之間的切換的計(jì)算和存儲(chǔ)開(kāi)銷也應(yīng)該是可以控制的。 AUTOSAR標(biāo)準(zhǔn)AUTOSAR（AUTomotive Open Systems ARchitecture）汽車開(kāi)放系統(tǒng)架構(gòu)，是由多家汽車整車廠商和供應(yīng)商在2003年夏天成立的汽車電子軟件開(kāi)發(fā)全球合作聯(lián)盟，其目的就在于降低汽車軟件的復(fù)雜性和多樣性，提高軟件復(fù)用。目前AUTO SAR已經(jīng)150多個(gè)成員，包括9個(gè)核心成員：BMW Groups（寶馬）、BOSCH（博世）、Continental（大陸）、DAIMLER（戴姆勒）、Ford（福特）、GM（通用）、PSA Peugeot Citron（標(biāo)志雪鐵龍）、TOYOTA（豐田）、VOLKSWAGEN AG（大眾），我國(guó)目前已有一汽、上汽和恒潤(rùn)科技三家公司加入該組織。AUTOSAR定義了一套支持分布式的、功能驅(qū)動(dòng)的汽車電子軟件開(kāi)發(fā)方法，提出了軟件架構(gòu)標(biāo)準(zhǔn)化方案，加強(qiáng)不同平臺(tái)之間的軟件復(fù)用，從而降低開(kāi)發(fā)成本。，達(dá)到一個(gè)穩(wěn)定的階段，通過(guò)對(duì)AUTOSAR在實(shí)際項(xiàng)目中的幾次實(shí)用性測(cè)試，現(xiàn)在AUTOSAR已經(jīng)可以應(yīng)用在實(shí)際的產(chǎn)品ECU中。例如在寶馬7系量產(chǎn)車型中，已經(jīng)開(kāi)發(fā)了符合AUTOSAR標(biāo)準(zhǔn)的ECU，預(yù)計(jì)在2011年AUTOSAR的所有核心成員都將開(kāi)發(fā)出相關(guān)的產(chǎn)品。同時(shí)，在商業(yè)應(yīng)用中，供應(yīng)商已經(jīng)推出了支持AUTOSAR標(biāo)準(zhǔn)的工具和軟件，提供需求管理，系統(tǒng)描述，軟件構(gòu)件算法模型驗(yàn)證，軟件構(gòu)件算法建模，軟件構(gòu)件代碼生成，RTE生成，ECU配置以及基礎(chǔ)軟件和操作系統(tǒng)等服務(wù)。AUTOSAR倡導(dǎo)的原則是“在標(biāo)準(zhǔn)上合作，在實(shí)現(xiàn)上競(jìng)爭(zhēng)”，其核心思想在于“統(tǒng)一標(biāo)準(zhǔn)、分散實(shí)現(xiàn)、集中配置”，所以采用AUTOSAR將為OEM帶來(lái)發(fā)展機(jī)遇，隨著汽車電子軟件的標(biāo)準(zhǔn)化和開(kāi)放化，更多的供應(yīng)商可以進(jìn)入到汽車電子行業(yè)中來(lái)， 這將使得OEM可以更加靈活的進(jìn)行軟件采購(gòu)，有更多的選擇，同時(shí)軟件的質(zhì)量監(jiān)督也會(huì)相應(yīng)提高，有利于提高汽車電子軟件的產(chǎn)品質(zhì)量。同時(shí)，我們也注意到，在全行業(yè)中推行AUTOSAR標(biāo)準(zhǔn)還存在一定的障礙，一些大的供應(yīng)商和OEM廠商都有自己的標(biāo)準(zhǔn)和框架，推行新的標(biāo)準(zhǔn)和框架可能產(chǎn)生更換成本、喪失控制等風(fēng)險(xiǎn)。盡管如此，標(biāo)準(zhǔn)化的汽車電子軟件開(kāi)發(fā)方法和軟件架構(gòu)是汽車行業(yè)未來(lái)不可阻擋的發(fā)展趨勢(shì)，而且目前還沒(méi)有哪種標(biāo)準(zhǔn)比AUTOSAR標(biāo)準(zhǔn)走的更遠(yuǎn)。鑒于此，國(guó)內(nèi)汽車OEM必須做好應(yīng)對(duì)AUTOSAR的準(zhǔn)備，這對(duì)他們來(lái)說(shuō)，是挑戰(zhàn)更是機(jī)遇。 AUTOSAR標(biāo)準(zhǔn)軟件構(gòu)架AUTOSAR的目標(biāo)是實(shí)現(xiàn)應(yīng)用程序和基礎(chǔ)軟件模塊之間的分離，因此汽車電子軟件架構(gòu)被抽象成幾個(gè)層。 圖 AUTOSAR軟件架構(gòu)層次圖軟件被分為應(yīng)用軟件組件（SWC）和基礎(chǔ)軟件組件（BSW），SWC指具體的應(yīng)用程序，如引擎控制程序等?；A(chǔ)軟件組件（BSW）分為下面幾個(gè)層次：服務(wù)層（Services Layer）、ECU抽象層（ECU Abstraction Layer）和微控制器抽象層（Microcontroller Abstraction Layer）。除此幾層外，在AUTOSAR軟件架構(gòu)中還有復(fù)雜驅(qū)動(dòng)（Complex Driver），由于對(duì)復(fù)雜傳感器和執(zhí)行器進(jìn)行操作的模塊涉及到嚴(yán)格的時(shí)序問(wèn)題，在AUTOSAR中這部分沒(méi)有被標(biāo)準(zhǔn)化。 （1）服務(wù)層，為應(yīng)用層提供診斷協(xié)議、存儲(chǔ)管理、ECU模式管理和操作系統(tǒng)等系統(tǒng)服務(wù)。除操作系統(tǒng)之外，服務(wù)層的各個(gè)軟件模塊都與平臺(tái)相關(guān)。 （2）ECU抽象層，對(duì) ECU（如外設(shè)與ECU的連接方式等）進(jìn)行抽象處理。該層與微控制器無(wú)關(guān)，但是與ECU平臺(tái)相關(guān)。（3）微控制器抽象層，包括微控制器相關(guān)的驅(qū)動(dòng)（如I/O驅(qū)動(dòng)、ADC驅(qū)動(dòng)等）。 SWC和BSW通過(guò)RTE（Runtime Environment）實(shí)現(xiàn)相互獨(dú)立，RTE負(fù)責(zé)AUTOSAR軟件構(gòu)件（即應(yīng)用層）相互間的通信以及軟件構(gòu)件與基礎(chǔ)軟件之間的通信。RTE層之下的基礎(chǔ)軟件對(duì)于應(yīng)用層來(lái)說(shuō)是不可見(jiàn)的，必須通過(guò)RTE進(jìn)入，它將軟件構(gòu)件從對(duì)底層軟件和硬件平臺(tái)的依賴中獨(dú)立出來(lái)，實(shí)現(xiàn)了應(yīng)用程序和基礎(chǔ)軟件之間的分隔。 AUTOSAR方法AUTOSAR為符合該標(biāo)準(zhǔn)的汽車電子軟件系統(tǒng)開(kāi)發(fā)過(guò)程定義了一套通用的技術(shù)方法，這種方法即被稱為AUTOSAR方法論（AUTOSAR Methodology）。汽車OEM作為整車系統(tǒng)功能的規(guī)劃和設(shè)計(jì)者，需要了解并掌握AUTOSAR提供的這套開(kāi)發(fā)流程，才能主導(dǎo)和推進(jìn)符合AUTOSAR標(biāo)準(zhǔn)的系統(tǒng)的開(kāi)發(fā)過(guò)程。 。 圖 AUTOSAR系統(tǒng)設(shè)計(jì)與開(kāi)發(fā)流程主要步驟可劃分兩個(gè)階段： 第一個(gè)階段是系統(tǒng)配置階段，這屬于系統(tǒng)級(jí)設(shè)計(jì)決策工作。首先是編寫(xiě)系統(tǒng)配置輸入文件，為XML類型的文件。應(yīng)用軟件的描述術(shù)語(yǔ)在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)配置階段接下來(lái)的工作是將初步獲得的系統(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í)行代碼。 此外，要說(shuō)明的是，AUTOSAR系統(tǒng)的設(shè)計(jì)過(guò)程使用了虛擬功能總線（Virtual Functional Bus）的概念。虛擬功能總線（Virtual Functional Bus）將AUTOSAR軟件構(gòu)件相互間的通信以及軟件構(gòu)件與基礎(chǔ)軟件之間的通信進(jìn)行了抽象，同時(shí)使用預(yù)先定義的標(biāo)準(zhǔn)接口。而對(duì)于虛擬功能總線來(lái)說(shuō)，ECU內(nèi)部通信和外部總線通信并沒(méi)有什么區(qū)別，這種區(qū)別要等到系統(tǒng)布局以及ECU的具體功能最終確定才會(huì)體現(xiàn)出來(lái)。軟件構(gòu)件本身對(duì)于這種區(qū)別并不關(guān)注，因此我們可以在獨(dú)立的情況下開(kāi)發(fā)軟件構(gòu)件。在系統(tǒng)實(shí)現(xiàn)過(guò)程中，虛擬功能總線所代表的功能最終以RTE的生成來(lái)體現(xiàn)。 AUTOSAR標(biāo)準(zhǔn)接口通過(guò)RTE實(shí)現(xiàn)AUTOSAR軟件構(gòu)件（即應(yīng)用程序）相互間的通信以及軟件構(gòu)件與基礎(chǔ)軟件之間的通信的前提是，軟件構(gòu)件必須具有標(biāo)準(zhǔn)的AUTOSAR接口。目前，AUTOSAR （動(dòng)力，車身/舒適和底盤(pán)）的標(biāo)準(zhǔn)接口。AUTOSAR按照功能邏輯分別將這些領(lǐng)域的系統(tǒng)劃分成若干個(gè)模塊，這些模塊可被視為一個(gè)軟件構(gòu)件或多個(gè)軟件構(gòu)件的組合，這些功能性的軟件構(gòu)件的接口被明確定義，所定義的接口的內(nèi)容包括名稱，含義，范圍，數(shù)據(jù)類型，通信類型，單位等。應(yīng)用軟件開(kāi)發(fā)者在軟件構(gòu)件的設(shè)計(jì)與開(kāi)發(fā)時(shí)需要應(yīng)用這些接口定義。 這里以車身/舒適系統(tǒng)的雨刷管理的軟件構(gòu)件的接口定義為示例。圖 軟件構(gòu)件的接口定義其中雨刷管理構(gòu)件（WiperWasherManager）有兩個(gè)接口，CmdWashing 和StaWasher,圖中WWManager表示為雨刷管理軟件構(gòu)件的實(shí)例。針對(duì)CmdWashing接口定義了以下信息： （1）CmdWashing接口由WiperWash