|
一、 AUTOSAR背景介紹 AUTOSAR是英文AUTomotive Open Systems ARchitecture的縮寫(xiě)，中文意思是汽車(chē)開(kāi)放系統架構，它定義了一套支持分布式的、功能驅動(dòng)的汽車(chē)電子軟件開(kāi)發(fā)方法和電子控制單元上的軟件架構標準化方案，以便應用于不同的汽車(chē)平臺，提高軟件復用，降低開(kāi)發(fā)成本。AUTOSAR是由汽車(chē)OEM和其一線(xiàn)供應商建立的汽車(chē)軟件開(kāi)發(fā)全球合作聯(lián)盟，于 2003年夏天正式成立，并于2004年啟動(dòng)了主要的工作，其目的就在于控制汽車(chē)軟件的復雜性和多樣性。AUTOSAR包括9個(gè)核心成員：BMW Groups（寶馬）、BOSCH（博世）、Continental（大陸）、DAIMLER（戴姆勒）、Ford（福特）、GM（通用）、PSA Peugeot Citron（標志-雪鐵龍）、TOYOTA（豐田）、VOLKSWAGEN AG（大眾）。目前其成員已超過(guò)150個(gè)，國內OEM中已有一汽及上汽加入，恒潤科技成為繼一汽、上汽之后，國內第三家加入該組織的公司。 AUTOSAR自面世以來(lái)，從半導體工業(yè)、工具和軟件廠(chǎng)商、零部件供應商到汽車(chē)制造商本身，整個(gè)汽車(chē)領(lǐng)域內的價(jià)值體系都給予該標準積極的推動(dòng)。 AUTOSAR開(kāi)發(fā)成員在2007年發(fā)布了2.1版本，使AUTOSAR的發(fā)展到達了一個(gè)穩定的階段，隨后通過(guò)幾個(gè)不同的開(kāi)發(fā)項目對AUTOSAR的實(shí)用性進(jìn)行了測試，現在A(yíng)UTOSAR已經(jīng)做好進(jìn)入到產(chǎn)品ECU的準備，而寶馬集團已將符合AUTOSAR標準的ECU（電子控制單元）應用在全新BMW 7系量產(chǎn)車(chē)型中，預計在2010年AUTOSAR的所有核心成員都將推出相關(guān)的產(chǎn)品。在商業(yè)領(lǐng)域里，支持AUTOSAR標準的工具和軟件供應商已推出了相應的工具和軟件，提供需求管理，系統描述，軟件構件算法模型驗證，軟件構件算法建模，軟件構件代碼生成，RTE生成，ECU配置以及基礎軟件和操作系統等服務(wù)，幫助OEM實(shí)現無(wú)縫的AUTOSAR系統軟件架構開(kāi)發(fā)流程。目前AUTOSAR版本為3.1版，預計將于2009年秋季發(fā)布4.0版本。 由于A(yíng)UTOSAR提倡“在標準上合作，在實(shí)現上競爭”的原則，其核心思想在于“統一標準、分散實(shí)現、集中配置”，所以采用AUTOSAR將為OEM帶來(lái)很大的好處，這將使得他們對于軟件采購和控制擁有更靈活和更大的權利，因為軟件系統的標準化和開(kāi)放化將使更多的軟件供應商進(jìn)入汽車(chē)電子行業(yè)，從而使得他們有更多的選擇，同時(shí)軟件的質(zhì)量監督也會(huì )相應提高，有利于提高他們的產(chǎn)品質(zhì)量。但是，也必須看到在全行業(yè)內推行此標準還是存在潛在障礙的，就是來(lái)自一些 OEM廠(chǎng)商和大的第一級汽車(chē)供應商的抵制，因為他們已經(jīng)有自己的標準和架構了，而采用AUTOSAR標準及其架構可能產(chǎn)生更換成本、喪失控制等風(fēng)險。盡管如此，汽車(chē)電子軟件開(kāi)發(fā)方法和軟件架構的標準化是汽車(chē)行業(yè)不可阻擋的發(fā)展趨勢，而且目前還沒(méi)有哪種標準比AUTOSAR標準走的更遠。鑒于此，國內汽車(chē) OEM必須做好應對AUTOSAR的準備，這對他們來(lái)說(shuō)，是挑戰更是機遇。 在A(yíng)UTOSAR標準的實(shí)施過(guò)程中，OEM將起主導作用。OEM應如何提出需求并在他們的產(chǎn)品上使用這些來(lái)自不同供應商的具有標準功能和接口的軟件呢？AUTOSAR為此同時(shí)制定了方法上、流程上的標準，即AUTOSAR方法論。本文將著(zhù)重解讀AUTOSAR方法論內容，講解OEM應如何將該標準應用在他們的產(chǎn)品研發(fā)及生產(chǎn)過(guò)程中。 二、 AUTOSAR 技術(shù)概述 AUTOSAR的計劃目標主要有3項，第一是建立獨立于硬件的分層的軟件架構；第二是為實(shí)施應用提供方法論，包括制定無(wú)縫的軟件架構堆疊流程并將應用軟件整合至ECU中；第三是制定各種車(chē)輛應用接口規范，作為應用軟件整合標準，以便軟件構件在不同的汽車(chē)平臺上的復用。 1、AUTOSAR軟件架構 為了實(shí)現AUTOSAR的目標，即實(shí)現應用程序和基礎模塊之間的分離，汽車(chē)電子軟件架構被抽象成幾個(gè)層，如圖1所示。 圖1：AUTOSAR軟件架構層次圖。 為了區別軟件依賴(lài)和硬件依賴(lài)，基礎軟件分為四個(gè)層次：服務(wù)層（Services Layer）、ECU抽象層（ECU Abstraction Layer）、微控制器抽象層（Microcontroller Abstraction Layer）和RTE（Runtime Environment）。除此四層外，在A(yíng)UTOSAR軟件架構中還有復雜驅動(dòng)（Complex Driver），由于對復雜傳感器和執行器進(jìn)行操作的模塊涉及到嚴格的時(shí)序問(wèn)題，在A(yíng)UTOSAR中這部分沒(méi)有被標準化。 * 服務(wù)層提供包括診斷協(xié)議、存儲管理、ECU模式管理和操作系統等在內的系統服務(wù)。除了操作系統外，服務(wù)層的軟件模塊都是與平臺無(wú)關(guān)的。 * ECU抽象層將ECU結構（如外設與ECU的聯(lián)接方式等）進(jìn)行了抽象處理。該層與ECU平臺相關(guān)，但與微控制器無(wú)關(guān)。 * 微控制器抽象層包括微控制器相關(guān)的驅動(dòng)（如I/O驅動(dòng)、ADC驅動(dòng)等）。 * RTE層負責AUTOSAR軟件構件（即應用層）相互間的通信以及軟件構件與基礎軟件之間的通信。RTE層之下的基礎軟件對于應用層來(lái)說(shuō)是不可見(jiàn)的，必須通過(guò)RTE進(jìn)入，它將軟件構件從對底層軟件和硬件平臺的依賴(lài)中獨立出來(lái)，實(shí)現了應用程序和基礎軟件之間的分隔。 2、 AUTOSAR方法論 AUTOSAR為符合該標準的汽車(chē)電子軟件系統開(kāi)發(fā)過(guò)程定義了一套通用的技術(shù)方法，這種方法即被稱(chēng)為AUTOSAR方法論（AUTOSAR Methodology）。汽車(chē)OEM作為整車(chē)系統功能的規劃和設計者，需要了解并掌握AUTOSAR提供的這套開(kāi)發(fā)流程，才能主導和推進(jìn)符合 AUTOSAR標準的系統的開(kāi)發(fā)過(guò)程。 兼容AUTOSAR標準的汽車(chē)電子軟件系統設計與開(kāi)發(fā)流程如圖 2所示。 圖2：AUTOSAR系統設計與開(kāi)發(fā)流程。 主要步驟可劃分兩個(gè)階段： 第一個(gè)階段是系統配置階段，這屬于系統級設計決策工作。首先是編寫(xiě)系統配置輸入文件，為XML類(lèi)型的文件。應用軟件的描述術(shù)語(yǔ)在 AOTUSAR中為軟件構件（Software Components），該文件將確定需要使用的軟件構件（即系統具有哪些功能）和硬件資源（ECU），以及整個(gè)系統的約束條件。AUTOSAR提供了一系列的模板（軟件構件模板，ECU資源模板和系統模板）和標準的信息交換格式，工具供應商可據此提供相應的工具支持，從而簡(jiǎn)化系統設計的工作，最終系統設計者只需要使用工具填充或編輯相應的模板即可導出系統配置輸入文件。 系統配置輸入包含三部分內容，第一個(gè)輸入是軟件構件描述，定義每個(gè)需要的軟件構件的接口內容，包括數據類(lèi)型，端口，接口等；第二個(gè)輸入是ECU資源描述，定義了每個(gè)ECU的資源需求，如處理器、外部設備、存儲器、傳感器和執行器等；第三個(gè)輸入是系統約束描述，定義總線(xiàn)信號，拓撲結構和軟件構件的映射關(guān)系。 系統配置階段接下來(lái)的工作是將初步獲得的系統配置輸入文件借助系統配置生成器生成系統配置描述文件，同樣為XML文件，這是系統配置階段的最終工作成果。該文件將包含所有的系統信息，包括將軟件構件映射到相關(guān)的ECU上（這種映射需要考慮到構件的需要、構件的連接、資源需求以及約束條件，有時(shí)也需要考慮成本等方面的因素），以及通信矩陣（整車(chē)的網(wǎng)絡(luò )結構、時(shí)序以及網(wǎng)絡(luò )數據幀的內容）。 第二個(gè)階段是ECU的配置，這階段的工作需要對系統中每個(gè)ECU分別進(jìn)行。首先是使用第一個(gè)階段的工作成果——系統配置描述文件，從中提取出與各個(gè)ECU相關(guān)的系統配置描述信息，提取的信息包括ECU通信矩陣、拓撲結構、頂級功能組合（據此產(chǎn)生需映射到該ECU上的所有軟件構件），將放在另一個(gè)XML文件中。提取信息的工作可借助工具完成。然后進(jìn)入ECU配置的實(shí)際工作中，這一步負責往輸入對象中添加具體應用所必需的信息，如任務(wù)調度、必要的BSW模塊、BSW配置信息、給任務(wù)分配的可運行實(shí)體等。這一步的結果被放在ECU 配置描述文件中，它包含了具體ECU所需的所有信息。最后一步是生成具體ECU的可執行程序，此步將根據ECU 配置描述文件中的配置信息構建完成ECU的基礎軟件的設置和與基于A(yíng)UTOSAR構件的應用軟件的集成，最終生成ECU的可執行代碼。 此外，要說(shuō)明的是，AUTOSAR系統的設計過(guò)程使用了虛擬功能總線(xiàn)（Virtual Functional Bus）的概念。虛擬功能總線(xiàn)（Virtual Functional Bus）將AUTOSAR軟件構件相互間的通信以及軟件構件與基礎軟件之間的通信進(jìn)行了抽象，同時(shí)使用預先定義的標準接口。而對于虛擬功能總線(xiàn)來(lái)說(shuō)，ECU內部通信和外部總線(xiàn)通信并沒(méi)有什么區別，這種區別要等到系統布局以及ECU的具體功能最終確定才會(huì )體現出來(lái)。軟件構件本身對于這種區別并不關(guān)注，因此我們可以在獨立的情況下開(kāi)發(fā)軟件構件。在系統實(shí)現過(guò)程中，虛擬功能總線(xiàn)所代表的功能最終以RTE的生成來(lái)體現。 3、標準化的應用接口 通過(guò)RTE實(shí)現AUTOSAR軟件構件（即應用程序）相互間的通信以及軟件構件與基礎軟件之間的通信的前提是，軟件構件必須具有標準的 AUTOSAR接口。目前，AUTOSAR 3.1版已定義了一些典型的汽車(chē)電子應用領(lǐng)域（動(dòng)力，車(chē)身/舒適和底盤(pán)）的標準接口。AUTOSAR按照功能邏輯分別將這些領(lǐng)域的系統劃分成若干個(gè)模塊，這些模塊可被視為一個(gè)軟件構件或多個(gè)軟件構件的組合，這些功能性的軟件構件的接口被明確定義，所定義的接口的內容包括名稱(chēng)，含義，范圍，數據類(lèi)型，通信類(lèi)型，單位等。應用軟件開(kāi)發(fā)者在軟件構件的設計與開(kāi)發(fā)時(shí)需要應用這些接口定義。 這里以車(chē)身/舒適系統的雨刷管理的軟件構件的接口定義為示例，如圖3： 圖3：軟件構件的接口定義。 說(shuō)明： 雨刷管理構件（WiperWasherManager）有兩個(gè)接口，CmdWashing 和StaWasher,圖中WWManager表示為雨刷管理軟件構件的實(shí)例。針對CmdWashing接口定義了以下信息： 1) CmdWashing接口由WiperWasherManager構件提供，其數據內容為FrontWasher構件的Activation接口所使用。 2）CmdWashing包含一個(gè)“Command”的數據元素。 3）“Command”的數據類(lèi)型為“t_onoff”。 4）“t_onoff”屬于“RecordType”，該類(lèi)型描述一般的開(kāi)/關(guān)信息。 應用軟件開(kāi)發(fā)者應該意識到，面向AUTOSAR運行時(shí)環(huán)境（RTE）接口的應用軟件設計的重要性，及早地將AUTOSAR應用層接口引入到實(shí)際的項目中來(lái)，為實(shí)現應用軟件的可復用性做好準備，從而優(yōu)化整個(gè)軟件開(kāi)發(fā)流程。 三、 設計應用與實(shí)施 仍以車(chē)身/舒適領(lǐng)域的外部車(chē)燈控制系統的設計為例，在本例中只涉及轉向燈的閃爍控制功能的實(shí)現�！� 在系統配置階段，第一步是收集系統配置輸入內容。首先收集實(shí)現該功能所需的軟件構件，如圖4右部邊框所示，在本系統中共使用了5個(gè)軟件構件，按照AUTOSAR提供的軟件構件模板編寫(xiě)每個(gè)軟件構件的描述文件；然后明確系統中所用到的ECU資源，形成ECU資源描述文件，如圖4左上部邊框所示，這里有3類(lèi)ECU；最后是系統約束條件的描述文件，描述系統的網(wǎng)絡(luò )拓撲關(guān)系。一般OEM需要提供軟件構件描述和系統約束描述文件，以供零部件供應商在ECU系統開(kāi)發(fā)時(shí)使用。 圖4：系統配置輸入內容。 以上描述文件的生成均有專(zhuān)門(mén)的工具（這類(lèi)工具統稱(chēng)為AUTOSAR描述文件編輯器）支持，用戶(hù)只需向工具中填充規定的內容即可。 軟件構件描述文件的生成，需要獲取每個(gè)軟件構件的關(guān)于接口，行為，直接的硬件接口（I/O），運行性能需求（內存，功耗，定時(shí)等）等方面的信息；而軟件構件描述文件本身將包含4部分內容： * 一般特性：名稱(chēng)，生產(chǎn)商等 * 通信屬性：端口，接口 * 內部結構：子構件，連接關(guān)系 * 需要的硬件資源：處理時(shí)間，調度，內存大小和類(lèi)型等。 ECU資源描述文件生成之前，需要獲取每個(gè)ECU的關(guān)于傳感器和執行器，硬件接口，硬件屬性（內存，處理器，功耗），連接和帶寬等方面的信息；而ECU描述文件本身將包含7部分內容： * 一般特性：名稱(chēng)，生產(chǎn)商等 * 溫度（自身，環(huán)境，冷卻/加熱） * 可用的信號處理方法 * 可用的編程能力 * 可用的硬件：微控制器，架構（如多處理器）；內存，接口（CAN，LIN，MOST，FlexRay），外設（傳感器/執行器），連接（如引腳數目）。 * RTE之下針對微控制器的基礎軟件模塊 * 從引腳到ECU抽象層的信號 系統約束描述文件生成之前，需要關(guān)于整個(gè)系統的信息，如總線(xiàn)系統，協(xié)議，通信矩陣和屬性，功能集群，功能部署（向ECU的分布）；而系統約束描述文件本身將包含3部分內容： * 網(wǎng)絡(luò )拓撲：總線(xiàn)（CAN，LIN，FlexRay），連接的ECU，網(wǎng)關(guān)，電源供應 * 通信（針對每個(gè)通道）：通信矩陣，網(wǎng)關(guān)表 * 軟件構件的映射 以上所描述的系統配置輸入內容收集完整后，使用系統配置工具導出系統配置文件，這一步?jīng)Q定哪個(gè)軟件構件運行在哪塊ECU上，它生成ECU配置描述；此外還生成該系統內的通信矩陣。如圖5所示。 圖5：系統配置結果。 以上工作完成后，接下來(lái)進(jìn)入ECU配置階段。將每個(gè)ECU的配置信息從系統配置文件中提取出來(lái)，其內容包括ECU通信矩陣、拓撲結構、頂級功能組合（即需映射到該ECU上的所有軟件構件的組合）。此外，還需要更具體的關(guān)于A(yíng)UTOSAR的基礎軟件各主要部分的配置，如RTE的配置，OS 的配置，MCAL（微控制器抽象層）的配置和通信協(xié)議棧配置等。這些軟件部件的配置目前均有相應的工具支持，直接生成可編譯的頭文件以供ECU系統軟件的集成使用。在生成ECU可執行程序之前，需獲得相關(guān)軟件構件和基礎軟件的代碼，然后與上述基礎軟件的配置頭文件進(jìn)行連編，最后生成ECU的可執行程序。如圖6所示。 圖6：ECU的配置與可執行程序的生成。 綜上所述，整個(gè)系統設計和開(kāi)發(fā)流程可用圖7表示，這里要注意的是，該過(guò)程可能需要多次迭代修改，以達到最優(yōu)。 圖7：系統設計和開(kāi)發(fā)流程。 四、總結 AUTOSAR正在成為現實(shí)，建立這樣一個(gè)標準化平臺并貫徹標準化，將會(huì )縮短新產(chǎn)品的研發(fā)時(shí)間和測試時(shí)間，從而幫助企業(yè)實(shí)現快速的市場(chǎng)反應。許多OEM都計劃在接下來(lái)的車(chē)型中采用AUTOSAR。在市場(chǎng)上不少工具和軟件供應商都已推出了符合AUTOSAR標準的工具或軟件支撐，可為 AUTOSAR系統的設計和開(kāi)發(fā)提供完整的無(wú)縫的解決方案。 AUTOSAR是汽車(chē)電子軟件平臺標準化的歷程中的一個(gè)巨大飛躍，我們需要學(xué)習和理解它。但是也必須看到，在整個(gè)汽車(chē)行內打破傳統的軟件開(kāi)發(fā)平臺需要相當長(cháng)的一個(gè)過(guò)程。我們可以根據用戶(hù)的需求和目標，在初期搭建AUTOSAR與傳統軟件的混合平臺，這是是一個(gè)能夠實(shí)現向AUTOSAR平滑升級的可行的方法。在這個(gè)過(guò)程里，重點(diǎn)不是單純地使用，理解AUTOSAR的理念和思想才最重要，因為它對汽車(chē)電子軟件開(kāi)發(fā)的工作流程和商業(yè)模式都將帶來(lái)意義深遠的變革。 |
