基于AUTOSAR 架構的汽車電子軟件產品的開發方法

詹克旭

（博世華域轉向系統有限公司， 上海 201821）

隨著中國汽車電子制造業的不斷快速變革和汽車電子信息系統技術的不斷創新發展，以及未來人們對汽車舒適性和汽車功能性的要求逐步提高，越來越多的汽車功能需求被集成在汽車上，使得汽車的電氣系統架構愈加復雜，這樣就可能造成不同功能的電子控制單元之間很可能存在高度耦合。對于汽車軟件的整合開發，各大知名汽車專用電子軟件廠商都已經有自己的開發標準，因此在開發集成軟硬件時，由于軟件開發平臺之間存在著的差異性很可能會造成可移植性差、不正常兼容等問題。由于軟件兼容性問題也會導致汽車軟件開發存在潛在的安全風險，同時也會使軟件開發成本大幅度增加，基于上述分析，如果依然按照傳統的工業軟件開發工作流程，已經不能完全滿足要求，整車軟件系統開發的工作復雜度將大大增加。

汽車開放電子系統軟件架構技術標準名為AUTOSAR（Automotive Open System Architecture），由歐洲的全球汽車部件制造商、供應商、半導體和電動工具制造廠商共同聯合發起組建，并共同制定了一系列用于汽車開放電子系統軟件開發技術規范［1-3］，作為用于汽車軟件開發的一個標準化開放式系統架構。為了有效解決目前汽車電子系統軟件的可復用及在不同硬件平臺上的可移植性，AUTOSAR通過引入各種模塊化的軟件開發方法，能夠有效滿足日益復雜的汽車電子系統軟件開發的技術需求，以達到不斷降低軟件產品成本和不斷提高軟件產品品質的目的。基于AUTOSAR架構的軟件開發越來越受到高度重視，近年來已經得到極大發展，其必將逐步發展成為能夠滿足未來汽車電子軟件系統開發需求的軟件架構。

1 AUTOSAR技術概述

AUTOSAR的計劃目標主要有3個：建立分層的體系架構，為應用程序的開發提供方法論，制定各種應用接口規范。

1.1 AUTOSAR軟件總體架構

為了充分方便用戶切換硬件平臺，實現系統軟件和硬件分開，盡可能最大化提高模塊軟件的功能復用率，AUTOSAR系統架構采用軟件分層和可分布的模塊軟件設計的工作思想。AUTOSAR系統架構從軟件底層到上層共劃分為3層：基礎軟件層、運行時環境層和應用層［4-6］，如圖1所示。

圖1 AUTOSAR軟件總體架構

1） 基礎軟件層BSW。BSW （Basic Software） 由一系列的基礎服務軟件組件模塊構成，主要功能用于提供各種基礎軟件服務，包括標準化的軟件功能接口以及系統功能。BSW主要包括微控制器抽象層 （Microcontroller Abstraction Layer）、ECU抽象層 （ECU Abstraction Layer）、服務層 （Services Layer） 以及復雜驅動層 （Complex Drivers）。BSW每一層均向其上層軟件組件提供服務，并屏蔽了其下層的實現細節。

2） 運行時環境RTE。作為AUTOSAR ECU體系結構的核心組成部分，RTE （Runtime Environment） 不依賴ECU，是最小可運行實體 （Runnable） 的實時運行環境。AUTOSAR虛擬功能總線 （Virtual Function Bus，VFB） 的接口 （針對某個特定ECU） 的實現是由RTE完成的，它為應用程序軟件組件之間的通信提供基本的服務。RTE作為基礎軟件層和應用層的銜接橋梁，使ECU硬件開發和軟件開發分開，因此策略開發人員可以更專注于軟件功能的開發。

3） 應用層。應用層 （Application Software） 代表著汽車電子軟件中最核心的功能，控制功能設計都在這一層進行。AUTOSAR規定以軟件組件SWC （Software Component） 的形式表示應用層軟件的功能，作為AUTOSAR應用軟件最小可以復用的模塊，一個或多個運行實體 （Runnable） 包含在軟件組件之中，而運行實體是軟件中最小的運行單元。應用軟件由多個軟件組件集成得到，組件將把行為和功能封裝而僅把端口顯示出來。

1.2 AUTOSAR方法論

AUTOSAR為汽車電子軟件系統開發定義了一套通用的解決方案，即AUTOSAR方法論［7］。AUTOSAR方法論中不規定要執行哪些活動，而且也沒有定義“責任”和“角色”之類的東西。它既不是商業模型，也不是完整的過程描述。它只是一個“工作產品流” （work-product flow），AUTOSAR方法論定義了具有相互依賴性的“工作產品流”中的活動。AUTOSAR方法論并不定義何時執行和怎樣迭代，也并不定義整體的時間線。在不同的精確度上同樣的行為 （即系統配置行為） 會重復執行，例如第一個“粗糙”配置和最后一個“精確”配置在系統設計中依賴于實際配置甚至是ECU的實現。

AUTOSAR方法論描述了從系統層配置到ECU可執行代碼的設計步驟，具體開發流程如下：①負責編寫系統配置輸入描述文件；②系統配置；③提取特定ECU的描述；④ECU配置；⑤生成可執行文件。

1.3 AUTOSAR接口類型

AUTOSAR共定義了3種類型的接口：標準接口、標準AUTOSAR接口和AUTOSAR接口，如圖2所示。

圖2 AUTOSAR接口類型

1） 標準接口是用C語言定義的標準API，這些接口可實現操作系統和RTE、BSW模塊和ECU內部之間的函數調用。

2） 標準AUTOSAR接口包括兩種類型：BSW提供給ASW的服務接口，整車企業根據需要配置的標準接口，其完全由AUTOSAR 標準規定。

3） AUTOSAR接口一方面描述軟件組件與復雜驅動、ECU抽象層之間提供和獲取的服務，另一方面描述軟件組件之間提供和獲取服務、數據。此種接口是按照AUTOSAR接口定義規則來定義的，這些接口中的一部分已經由AUTOSAR定義，另外一部分需要整車企業自定義，通過這些接口實現了軟件組件在不同ECU上的可重用性。

2 AUTOSAR服務層設計

AUTOSAR的服務層主要包括通信服務、存儲服務和系統服務，如圖3所示。作為基礎軟件中的最高層，服務層與應用軟件之間也具有密切關聯。當用戶訪問一個包含ECU抽象層中的I/O接口信號時，服務層提供：①操作系統功能；②車輛網絡通信及管理服務；③存儲管理 （NVRAM管理）；④診斷數據服務 （主要包括系統故障數據處理、錯誤數據存儲及UDS數據通信）；⑤ECU狀態管理。

圖3 AUTOSAR服務層

2.1 系統服務（System Services）

系統服務模塊是基于一組同時可以由所有不同層次管理模塊相互使用的系統功能和管理模塊，包括AUTOSAR OS、診斷事件管理器、診斷通信管理器、BSW模式管理器、開發錯誤跟蹤器、功能禁止管理器、全局時間軟件模塊、通信管理器、看門狗管理器、ECU狀態管理器等，提供基本服務給應用和基本軟件開發模塊，如圖4所示。

圖4 系統服務

2.1.1 AUTOSAR OS

實時應用的所有基本服務由AUTOSAR系統提供，包括調度、中斷處理、本地消息處理、錯誤檢測機制以及系統時鐘自動同步和系統運行時間。這些服務通過使用API將通信層和OS與應用連接，它們都隱藏在定義的API之后。

AUTOSAR OS的基本特征包括：①軟件提供系統運行時保護功能 （包括計時、存儲等）；②靜態配置；③提供基于優先級的調度策略；④可宿主在低端控制器上，并且不需要其他資源；⑤能夠推斷實時系統性能。

2.1.2 BSW模式管理器

BSW模式管理器 （BswM） 是AUTOSAR BSW軟件中用于控制與切換車輛或應用層模式的模塊，其職責是基于規則仲裁來自應用層SWC或其他BSW模塊的模式請求，并基于仲裁結果來執行動作。

BswM的一個基本功能是它可以描述并分為兩個不同的任務：一個模式控制，一個模式仲裁。

2.1.3 診斷通信管理器

診斷通信管理器DCM （Diagnostic Communication Manager） 的主要作用之一是確保管理診斷通信狀態，確保診斷通信數據流，特別是確保診斷會話模式和確保診斷安全狀態。DCM在把數據消息傳送至AUTOSAR SW組件進一步處理之前，進行診斷消息處理和內部檢查。應用層中的每個調用將根據診斷服務的ID請求來自動執行。

此外，DCM在當前會話模式中診斷服務的執行將根據診斷狀態來進行判斷，以及檢查是否支持相應的診斷服務請求。

2.1.4 功能禁止管理器

軟件組件和軟件組件功能的控制機制由功能禁止管理器中FIM （Function Inhibition Manager） 來提供。功能的具體構成條件是一個、多個或部分的具有相同禁止條件或相同執行權限的可執行實體，通過手動修改和重新配置可以實現對這些功能的禁止，具體可以通過FIM方法實現。這樣一來，極大地提高了功能在新系統環境下的適應性。

2.1.5 診斷事件管理器

診斷事件管理器DEM （Diagnostic Event Manager） 跟AUTOSAR內診斷模塊的功能禁止管理器 （FIM） 和診斷通信管理器 （DCM） 一樣，它本身是一個子組件，負責存儲和處理出錯的診斷事件的Freeze Frame數據和Extended Data數據。例如DCM獲取的所有存儲的DTC （Diagnostic Trouble Code）故障信息都由DEM提供。DEM定義了一種類型可選的過濾服務，給FIM、DCM和應用層提供接口。

2.1.6 開發錯誤跟蹤器

在軟件開發期間，跟蹤和記錄軟件錯誤主要由開發錯誤跟蹤器DET （Development Error Tracer） 來實現，它本身是一個輔助工具，用來實現輔助軟件的開發和軟件的集成工作。API已經明確定義，但在軟件產品的代碼中并不一定都需要包含DET。在特定的軟件測試和應用環境下，軟件系統開發人員和軟件系統集成人員可以為API功能選擇最優的策略。

2.1.7 全局時間軟件模塊

全局時間軟件模塊StbM （Synchronized Time-base Manager） 的功能有兩個：①提供絕對時間值；②同步各個軟件模塊實體。

2.1.8 通信管理器

通信管理器，用于實時收集并協調網絡訪問者的請求，主要用于負責整個網絡通信資源的管理。特定的物理通道對一個應用程序可以使用與否的定義可以用通信管理器通過其定義“通信模式”的方式來進行表示，并以此方式來定義諸如只接收、只發送、不接收也不發送，接收/發送等多種使用方式。

2.1.9 看門狗管理器

看門狗管理器的觸發是基于應用軟件的生存狀態。作為AUTOSAR的標準化基本軟件體系結構的基本安全模塊，與軟件計時器和約束有關的應用程序執行的可靠性由看門狗管理器負責監控。看門狗硬件計時約束和應用計時約束的分離基于分層體系的結構設計方法。這樣一來，在觸發硬件看門狗功能的同時，對一些獨立應用的生存監控也被看門狗管理器來提供。

2.1.10 ECU狀態管理器

ECU狀態管理器可以管理諸如run、off、sleep等ECU內部的不同狀態，此外還會管理諸如startup、shutdown、wakeup等ECU的不同狀態之間的轉換。它是一個基本軟件模塊，控制包括系統的AUTOSAR BSW模塊的啟動階段。

為了保證能夠同時啟動ECU或為了能夠將其轉換模式到具有備用工作狀態、休眠工作狀態等低或高功耗工作狀態，ECU狀態管理器必須同時支持獨立的預處理動作和過渡。通過ECU狀態管理器的能力和特性的優化使用，電源消耗的預定義策略就可以通過該模塊來執行，ECU的能源管理也就能夠得以有效地實現。

2.2 存儲服務

存儲服務負責管理從不同存儲驅動讀/寫非易失性數據，由一個NVRAM管理器模塊構成。它提供給應用快速讀取，需要一個RAM鏡像作為數據接口。

存儲服務抽象了存儲位置和屬性，其任務是為系統提供了諸如數據校驗、保護、保存、加載、可靠性存儲等非易失性應用數據管理機制，以一種統一的方式向應用提供非易失性數據。

2.3 通信服務

通信服務通過車輛通信網絡硬件中的抽象與車輛通信驅動程序進行連接，用于實現車輛LIN、CAN、FlexRay等通信網絡之間通信的一組模塊。通信服務主要職責有如下幾個任務：①為網絡管理提供統一的服務；②可以隱藏放在應用程序文件中的應用消息文件屬性和應用協議；③為車輛網絡提供統一的接口以進行通信。

3 AUTOSAR系統實現

根據客戶需求，在遵從AUTOSAR規范的前提下進行AUTOSAR服務層軟件的各項配置工作。現在比較流行的AUTOSAR系統軟件開發工具主要有使用Bosch公司ETAS的軟件ISOLAR、ElektroBit公司的EB tresos、dspace公司的SystemDesk、Vector公司的DaVinci等［8］。圖5為使用Bosch的ISOLAR軟件進行DCM的相關軟件配置，圖6為DEM的相關軟件配置信息。

圖5 DCM設計實現

圖6 DEM設計實現

在RTE、基礎軟件配置和軟件組件設計完成后，需要通過開發工具生成相應的可執行應用代碼和靜態代碼。之后需要根據客戶需求，進行應用層代碼的開發工作。

4 結束語

當前在汽車電子軟件開發中AUTOSAR架構已經被廣泛采用，基于AUTOSAR 標準并且通過標準化的BSW 接口進行軟件模塊設計和接口配置，實現了底層基礎軟件和應用層軟件的相互獨立，使軟件有了更好的移植性和可重用性。通過AUTOSAR配置工具生成軟件，代碼一致性好，開發周期短，提高了軟件開發的效率，大大降低了成本。本文詳細闡述了AUTOSAR架構方法論中系統級軟件的開發方法，可以幫助開發人員更好地了解AUTOSAR軟件架構優點，從而能夠促進傳統ECU開發模式和開發流程向AUTOSAR架構開發的轉變。基于AUTOSAR架構的軟件開發以其優勢，必將成為未來汽車電子軟件發展的方向。