|
汽車OEM正在開發基于AUTOSAR的電子系統以應對當代汽車中日益復雜的軟件。AUTOSAR簡化了開發流程并使得ECU軟件具有復用性。從2004年AUTOSAR面世開始，這項創新性的前沿技術就在許多研究性的項目中進行測試；現在，AUTOSAR開始通過產品化ECU進入真正的實現階段。AUTOSAR軟件代表了當前的技術水平，并通過不斷的版本更新來保證技術上的不斷進步。 汽車工業正在面臨新的時代。復雜的汽車功能越來越多，使得汽車電子的開發越來越復雜。顧客對于產品的功能和個性化要求，以及象診斷這種非功能性需求的增加，更加劇了ECU開發過程的復雜度。汽車，尤其是高級豪華車，大約有超過1000個軟件功能，幾條車內總線網絡，以及超過70個ECU。由于汽車電子領域硬件平臺的多樣性，ECU軟件開發嚴重依賴硬件和系統配置。每次相關的約束條件的更改都將導致重新編寫程序或對軟件的修改。 為了降低ECU軟件開發的復雜度，AUTOSAR開發成員提供了一套經過實踐驗證的軟件架構，并以此作為開發可重用應用程序的基礎。AUTOSAR這一開放的系統架構標準是由全世界的汽車OEM，零部件供應商以及軟件、半導體和電子工業的企業共同制定。AUTOSAR可以使得用戶避免因為采用私有的解決方案導致日益增長的開發成本。 AUTOSAR將電子架構分成若干層和模塊。在定義接口的同時，AUTOSAR也定義了軟件組件和易于交換的硬件平臺標準。AUTOSAR開發成員不僅提供了基礎軟件模塊的規范，還提供了用于開發分布式系統應用程序的方法。這種方法以基于模型的軟件和分布式系統描述開始，以自動代碼生成和可重復的測試結束。這種方法簡化了工具鏈的使用。 在AUTOSAR面世之后三年，AUTOSAR開發成員在2007年發布了2.1版本。此時，AUTOSAR的發展到達了一個穩定的階段。幾個不同的開發項目對AUTOSAR的實用性進行了測試。在商業領域里，“AUTOSAR評估系統”已經完成。現在，AUTOSAR已經做好進入到產品ECU的準備了。 1 AUTOSAR體系結構 為了實現AUTOSAR的目標，即實現應用程序和基礎模塊之間的分離，汽車電子被抽象成幾個層，如圖1所示。 與實際微控制器之間的連接，也就是物理基礎，抽象為微控制器抽象層（Microcontroller Abstraction Layer），用于映射微控制器的功能和外圍接口。微控制器抽象層定義了內存接口、I/O驅動接口和通信連接接口，同時還可以模擬一些微控制器無法提供的功能。第二層是ECU抽象層（ECU Abstraction Layer）。這一層在ECU相關硬件的基礎上，為ECU提供外圍設備的驅動程序。第三層是服務層（Services Layer）。這一層提供了各種服務，例如網絡服務、內存管理、網絡通信和操作系統。服務層在很大程度上獨立于硬件系統。第四層的RTE真正實現了應用程序和基礎軟件之間的分隔。RTE負責處理應用程序集成以及應用程序與基礎軟件模塊之間的數據交換。RTE的存在是真正實現應用程序重用的基礎。由于RTE預定義了相關的接口，所以開發人員可以在對硬件一無所知的情況下進行應用軟件的開發，并將這個軟件應用在任何符合AUTOSAR標準的ECU中。 虛擬功能總線（Virtual Functional Bus）形成了這些層的配置基礎。通過這條虛擬總線，所有汽車電子通信組件都可以進行抽象，同時使用預先定義的端口；而對于虛擬功能總線來說，ECU內部通信和外部總線通信并沒有什么區別。這種區別要等到系統布局以及ECU的具體功能最終確定才會體現出來。軟件組件本身對于這種區別并不關注，因此我們可以在獨立的情況下開發軟件組件。軟件組件被分成若干個可執行單元，即運行實體。當某一個規定的事件發生時，就會有對應的運行實體被觸發。這樣的事件有可能是一個新的傳感器信號，也有可能是一個周期性定時。從虛擬功能總線的角度對電子系統的形式化描述最終定義了相關軟件組件的接口。因此，應用軟件的開發可以獨立于具體的ECU。 RTE實現了對于I/O、內存和其它基本服務的訪問。利用基于模型的描述，可以針對指定的ECU定制RTE，這樣可以適應不同的需求并節省資源。 2 方法 在定義ECU軟件體系架構的同時，AUTOSAR標準也定義了開發AUTOSAR系統的方法。符合經過確認的開發過程是開發軟件的一個重要前提。需求列表中的不足會在開發早期被發現，軟件組件的重用使得開發流程變得簡化，整個系統也就更加可靠。但是，這種方法也允許一定程度的自由：例如，用戶可以自己決定是使用從上至下還是從下至上的開發流程。 AUTOSAR的目的在于通過工具為軟件開發流程提供通用的支持。成熟的工具用于需求的結構化實現和相應的管理，同時建立相應的配置。 第一步包括三個主要方面的形式化描述：軟件（軟件組件），ECU（ECU資源）和系統約束。合適的編輯工具用于創建完整的系統描述，如圖2所示。 系統配置作為ECU配置的基礎，而用戶可以利用配置工具根據ECU配置生成基礎軟件組件。在開發流程的末期，有多種生成工具可以用來生成RTE和基礎軟件。開發過程中的所有設計和配置數據都用統一的文件格式保存。為此，AUTOSAR定義了一種基于XML的文件格式。一方面，統一的文件格式保證了開發流程的通用性；另一方面，它簡化了開發工具之間的無縫集成。 3 移植 AUTOSAR的軟件體系結構并非單一模塊，它包含了大量接口定義完整的標準模塊。這使得AUTOSAR的移植非常容易，即使是在項目之間進行移植；另外可以在一個項目之內同時使用標準的AUTOSAR模塊和私有的軟件模塊。 為了實現這樣的移植工作，首先必須將已有的軟件架構和AUTOSAR體系結構進行比較。通過分析重疊的功能和集成選項，進而決定哪些模塊可以保留，哪些模塊應該被標準的軟件模塊替換。 因此，在應用程序和基礎軟件之間引入一個分隔層是非常明智的選擇。一個可行的方法是在移植過程的早期就準備好應用程序和AUTOSAR軟件組件，并將它們通過RTE集成在一起。在RTE之下，一個專用的修改層用于為已有的基礎軟件提供接口，如圖3所示。 如果已有的基礎軟件有一部分需要被AUTOSAR基礎軟件替換，那么重點就集中在使用統一的工具。Vector提供合適的工具，可以用于配置私有的軟件模塊。非AUTOSAR模塊可以被AUTOSAR模塊逐步取代，從而避免推倒整個體系結構所需承擔的風險或重新編寫模塊所帶來的巨大工作量。 4 前景 AUTOSAR 3.0的發布標志著AUTOSAR標準的進一步完善。參與標準制定的各家公司承諾為實現AUTOSAR的目標而進行持續的努力。當前引入的各種想法將在AUTOSAR未來的4.0版本中得到實現。 工具供應商也提出了一些和AUTOSAR相關的想法。Vector的AUTOSAR開發團隊正在致力于將基于AUTOSAR的ECU開發變得更加便利和容易。一個典型例子是運行在PC上的AUTOSAR應用組件的測試工具，這個工具同時還可以作為符合AUTOSAR標準的ECU的仿真環境。這使得在PC上測試AUTOSAR軟件組件的實現代碼變得更加容易。廣泛使用的標準化工具（例如Vector的CANoe）可以用于測試實現、可視化測試以及生成測試報告。Vector利用全套的AUTOSAR基礎軟件組件和通用的設計與開發工具鏈支持整個開發流程，如圖4所示。 Vector的AUTOSAR解決方案已經在若干個項目中得到了實際驗證，同時得到驗證的還有符合AUTOSAR 2.0和2.1的成熟產品（符合AUTOSAR 3.0的產品將于2008年第二季度面世）。 5 總結 AUTOSAR正在成為現實。許多OEM都計劃在接下來的車型中采用AUTOSAR。Vector為AUTOSAR提供了完整的解決方案，包括AUTOSAR軟件組件和開發工具。這不僅僅支持純粹的AUTOSAR系統開發，而且支持逐步地將現有系統向AUTOSAR移植。 |
