面向OEM的AUTOSAR解決方案

一、 AUTOSAR背景介紹

　　AUTOSAR是英文AUTomotive Open Systems ARchitecture的縮寫，中文意思是汽車開放系統架構，它定義了一套支持分布式的、功能驅動的汽車電子軟件開發方法和電子控制單元上的軟件架構標準化方案，以便應用于不同的汽車平臺，提高軟件復用，降低開發成本。AUTOSAR是由汽車OEM和其一線供應商建立的汽車軟件開發全球合作聯盟，于2003年夏天正式成立，并于2004年啟動了主要的工作，其目的就在于控制汽車軟件的復雜性和多樣性。AUTOSAR包括9個核心成員：BMW Groups（寶馬）、BOSCH（博世）、Continental（大陸）、DAIMLER（戴姆勒）、Ford（福特）、GM（通用）、PSA Peugeot Citron（標志-雪鐵龍）、TOYOTA（豐田）、VOLKSWAGEN AG（大眾）。目前其成員已超過150個，國內OEM中已有一汽及上汽加入，恒潤科技成為繼一汽、上汽之后，國內第三家加入該組織的公司。

　　AUTOSAR自面世以來，從半導體工業、工具和軟件廠商、零部件供應商到汽車制造商本身，整個汽車領域內的價值體系都給予該標準積極的推動。 AUTOSAR開發成員在2007年發布了2.1版本，使AUTOSAR的發展到達了一個穩定的階段，隨后通過幾個不同的開發項目對AUTOSAR的實用性進行了測試，現在AUTOSAR已經做好進入到產品ECU的準備，而寶馬集團已將符合AUTOSAR標準的ECU（電子控制單元）應用在全新BMW 7系量產車型中，預計在2010年AUTOSAR的所有核心成員都將推出相關的產品。在商業領域里，支持AUTOSAR標準的工具和軟件供應商已推出了相應的工具和軟件，提供需求管理，系統描述，軟件構件算法模型驗證，軟件構件算法建模，軟件構件代碼生成，RTE生成，ECU配置以及基礎軟件和操作系統等服務，幫助OEM實現無縫的AUTOSAR系統軟件架構開發流程。目前AUTOSAR版本為3.1版，預計將于2009年秋季發布4.0版本。

　　 由于AUTOSAR提倡“在標準上合作，在實現上競爭”的原則，其核心思想在于“統一標準、分散實現、集中配置”，所以采用AUTOSAR將為OEM帶來很大的好處，這將使得他們對于軟件采購和控制擁有更靈活和更大的權利，因為軟件系統的標準化和開放化將使更多的軟件供應商進入汽車電子行業，從而使得他們有更多的選擇，同時軟件的質量監督也會相應提高，有利于提高他們的產品質量。但是，也必須看到在全行業內推行此標準還是存在潛在障礙的，就是來自一些OEM廠商和大的第一級汽車供應商的抵制，因為他們已經有自己的標準和架構了，而采用AUTOSAR標準及其架構可能產生更換成本、喪失控制等風險。盡管如此，汽車電子軟件開發方法和軟件架構的標準化是汽車行業不可阻擋的發展趨勢，而且目前還沒有哪種標準比AUTOSAR標準走的更遠。鑒于此，國內汽車OEM必須做好應對AUTOSAR的準備，這對他們來說，是挑戰更是機遇。

　　在AUTOSAR標準的實施過程中，OEM將起主導作用。OEM應如何提出需求并在他們的產品上使用這些來自不同供應商的具有標準功能和接口的軟件呢？AUTOSAR為此同時制定了方法上、流程上的標準，即AUTOSAR方法論。 本文將著重解讀AUTOSAR方法論內容，講解OEM應如何將該標準應用在他們的產品研發及生產過程中。

二、 AUTOSAR 技術概述

　　AUTOSAR的計劃目標主要有3項，第一是建立獨立于硬件的分層的軟件架構；第二是為實施應用提供方法論，包括制定無縫的軟件架構堆疊流程并將應用軟件整合至ECU中；第三是制定各種車輛應用接口規范，作為應用軟件整合標準，以便軟件構件在不同的汽車平臺上的復用。

　　1、AUTOSAR軟件架構

　　為了實現AUTOSAR的目標，即實現應用程序和基礎模塊之間的分離，汽車電子軟件架構被抽象成幾個層，如圖1所示。

圖1：AUTOSAR軟件架構層次圖。

　　為了區別軟件依賴和硬件依賴，基礎軟件分為四個層次：服務層（Services Layer）、ECU抽象層（ECU Abstraction Layer）、微控制器抽象層（Microcontroller Abstraction Layer）和RTE（Runtime Environment）。除此四層外，在AUTOSAR軟件架構中還有復雜驅動（Complex Driver），由于對復雜傳感器和執行器進行操作的模塊涉及到嚴格的時序問題，在AUTOSAR中這部分沒有被標準化。

* 服務層提供包括診斷協議、存儲管理、ECU模式管理和操作系統等在內的系統服務。除了操作系統外，服務層的軟件模塊都是與平臺無關的。

* ECU抽象層將ECU結構（如外設與ECU的聯接方式等）進行了抽象處理。該層與ECU平臺相關，但與微控制器無關。

* 微控制器抽象層包括微控制器相關的驅動（如I/O驅動、ADC驅動等）。

* RTE層負責AUTOSAR軟件構件（即應用層）相互間的通信以及軟件構件與基礎軟件之間的通信。RTE層之下的基礎軟件對于應用層來說是不可見的，必須通過RTE進入，它將軟件構件從對底層軟件和硬件平臺的依賴中獨立出來，實現了應用程序和基礎軟件之間的分隔。2、 AUTOSAR方法論

　　AUTOSAR為符合該標準的汽車電子軟件系統開發過程定義了一套通用的技術方法，這種方法即被稱為AUTOSAR方法論（AUTOSAR Methodology）。汽車OEM作為整車系統功能的規劃和設計者，需要了解并掌握AUTOSAR提供的這套開發流程，才能主導和推進符合AUTOSAR標準的系統的開發過程。

　　兼容AUTOSAR標準的汽車電子軟件系統設計與開發流程如圖 2所示。

圖2：AUTOSAR系統設計與開發流程。

　　主要步驟可劃分兩個階段：

　　第一個階段是系統配置階段，這屬于系統級設計決策工作。首先是編寫系統配置輸入文件，為XML類型的文件。應用軟件的描述術語在AOTUSAR中為軟件構件（Software Components），該文件將確定需要使用的軟件構件（即系統具有哪些功能）和硬件資源（ECU），以及整個系統的約束條件。AUTOSAR提供了一系列的模板（軟件構件模板，ECU資源模板和系統模板）和標準的信息交換格式，工具供應商可據此提供相應的工具支持，從而簡化系統設計的工作，最終系統設計者只需要使用工具填充或編輯相應的模板即可導出系統配置輸入文件。

　　系統配置輸入包含三部分內容，第一個輸入是軟件構件描述，定義每個需要的軟件構件的接口內容，包括數據類型，端口，接口等；第二個輸入是ECU資源描述，定義了每個ECU的資源需求，如處理器、外部設備、存儲器、傳感器和執行器等；第三個輸入是系統約束描述，定義總線信號，拓撲結構和軟件構件的映射關系。

　　系統配置階段接下來的工作是將初步獲得的系統配置輸入文件借助系統配置生成器生成系統配置描述文件，同樣為XML文件，這是系統配置階段的最終工作成果。該文件將包含所有的系統信息，包括將軟件構件映射到相關的ECU上（這種映射需要考慮到構件的需要、構件的連接、資源需求以及約束條件，有時也需要考慮成本等方面的因素），以及通信矩陣（整車的網絡結構、時序以及網絡數據幀的內容）。

　　第二個階段是ECU的配置，這階段的工作需要對系統中每個ECU分別進行。首先是使用第一個階段的工作成果――系統配置描述文件，從中提取出與各個ECU相關的系統配置描述信息，提取的信息包括ECU通信矩陣、拓撲結構、頂級功能組合（據此產生需映射到該ECU上的所有軟件構件），將放在另一個XML文件中。提取信息的工作可借助工具完成。然后進入ECU配置的實際工作中，這一步負責往輸入對象中添加具體應用所必需的信息，如任務調度、必要的BSW模塊、BSW配置信息、給任務分配的可運行實體等。這一步的結果被放在ECU 配置描述文件中，它包含了具體ECU所需的所有信息。最后一步是生成具體ECU的可執行程序，此步將根據ECU 配置描述文件中的配置信息構建完成ECU的基礎軟件的設置和與基于AUTOSAR構件的應用軟件的集成，最終生成ECU的可執行代碼。

　　此外，要說明的是，AUTOSAR系統的設計過程使用了虛擬功能總線（Virtual Functional Bus）的概念。虛擬功能總線（Virtual Functional Bus）將AUTOSAR軟件構件相互間的通信以及軟件構件與基礎軟件之間的通信進行了抽象，同時使用預先定義的標準接口。而對于虛擬功能總線來說，ECU內部通信和外部總線通信并沒有什么區別，這種區別要等到系統布局以及ECU的具體功能最終確定才會體現出來。軟件構件本身對于這種區別并不關注，因此我們可以在獨立的情況下開發軟件構件。在系統實現過程中，虛擬功能總線所代表的功能最終以RTE的生成來體現。

　　3、標準化的應用接口

　　通過RTE實現AUTOSAR軟件構件（即應用程序）相互間的通信以及軟件構件與基礎軟件之間的通信的前提是，軟件構件必須具有標準的AUTOSAR接口。目前，AUTOSAR 3.1版已定義了一些典型的汽車電子應用領域（動力，車身/舒適和底盤）的標準接口。AUTOSAR按照功能邏輯分別將這些領域的系統劃分成若干個模塊，這些模塊可被視為一個軟件構件或多個軟件構件的組合，這些功能性的軟件構件的接口被明確定義，所定義的接口的內容包括名稱，含義，范圍，數據類型，通信類型，單位等。應用軟件開發者在軟件構件的設計與開發時需要應用這些接口定義。

　　這里以車身/舒適系統的雨刷管理的軟件構件的接口定義為示例，如圖3：

圖3：軟件構件的接口定義。