詹克旭

（博世華域轉向系統(tǒng)有限公司， 上海 201821）

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

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

1 AUTOSAR技術概述

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

1.1 AUTOSAR軟件總體架構

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

圖1 AUTOSAR軟件總體架構

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

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

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

1.2 AUTOSAR方法論

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

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

1.3 AUTOSAR接口類型

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

圖2 AUTOSAR接口類型

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

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

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

2 AUTOSAR服務層設計

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

圖3 AUTOSAR服務層

2.1 系統(tǒng)服務（System Services）

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

圖4 系統(tǒng)服務

2.1.1 AUTOSAR OS

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

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

2.1.2 BSW模式管理器

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

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

2.1.3 診斷通信管理器

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

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

2.1.4 功能禁止管理器

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

2.1.5 診斷事件管理器

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

2.1.6 開發(fā)錯誤跟蹤器

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

2.1.7 全局時間軟件模塊

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

2.1.8 通信管理器

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

2.1.9 看門狗管理器

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

2.1.10 ECU狀態(tài)管理器

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

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

2.2 存儲服務

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

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

2.3 通信服務

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

3 AUTOSAR系統(tǒng)實現(xiàn)

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

圖5 DCM設計實現(xiàn)

圖6 DEM設計實現(xiàn)

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

4 結束語

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