面向汽車應用的AUTOSAR設計技巧
汽車OEM正在開發基于AUTOSAR的電子系統以應對當代汽車中日益復雜的軟件。AUTOSAR簡化了開發流程并使得ECU軟件具有復用性。
本文引用地址:http://www.j9360.com/article/84418.htm從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的準備了。
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。
評論