張可可，周沛澤

（1.合肥工業(yè)大學(xué)汽車與交通工程學(xué)院，安徽 合肥 230009；2.安徽江淮汽車集團股份有限公司技術(shù)中心，安徽 合肥 230601）

關(guān)鍵字：汽車控制器；軟件開發(fā)模式；汽車電子軟件架構(gòu)

1 緒論

隨著汽車的智能化、網(wǎng)聯(lián)化、電動化、共享化趨勢，電子設(shè)備的配備成本在汽車整體成本中所占比例居高不下，甚至高達百分之四十以上[1]。汽車電子技術(shù)的發(fā)展趨向于集成化、智能化，當前汽車電子控制器在逐步取代機械控制系統(tǒng)，“軟件定義汽車”已經(jīng)成為未來汽車發(fā)展的共識。近年來的汽車行業(yè)發(fā)展顯示，汽車行業(yè)70%的創(chuàng)新都來自于汽車電子[2]。

在以往大部分汽車控制器功能復(fù)雜度不高，汽車主要的創(chuàng)新點還停留在傳統(tǒng)機械機構(gòu)上的時候，整車廠對于汽車技術(shù)上的投入大多還是集中于發(fā)動機、變速箱和底盤的開發(fā)、標定和測試。大多數(shù)汽車電子零部件作為非關(guān)鍵零部件往往依賴零部件供應(yīng)商進行開發(fā)，整車廠在零部件軟硬件開發(fā)參與度不高，軟件開發(fā)水平較低。

2 整車廠開發(fā)應(yīng)用層軟件的開發(fā)模式

整車廠在的軟件開發(fā)過程的精力主要集中在應(yīng)用層軟件開發(fā)上，由供應(yīng)商負責(zé)主導(dǎo)其他軟件開發(fā)過程。為了方便應(yīng)用層軟件的移植，通常采用一些成熟的汽車電子軟件架構(gòu)，其中OSEK標準作為廣泛應(yīng)用的汽車電子軟件架構(gòu)標準經(jīng)常在這種開發(fā)模式下被使用。

2.1 OSEK標準概述

1993年5月，德國汽車工業(yè)界提出了OSEK標準，其含義是汽車電子開放式系統(tǒng)及接口的標準化，得到了寶馬、博世、歐寶、大眾及西門子等企業(yè)和組織的支持。同時，法國的標志和雷諾公司也開發(fā)了一個類似的開放式系統(tǒng)VDX。在1995年召開的國際專題研討會上，各廠商對OSEK和VDX標準達成了共識，產(chǎn)生了一個全新的標準OSEK/VDX，也被簡稱為OSEK標準[3]。

OSEK標準規(guī)范主要包含四個部分：OSEK操作系統(tǒng)規(guī)范（OSEK Operating System，OSEK OS）、OSEK通訊規(guī)范（OSEK Communication，OSEK COM）、OSEK網(wǎng)絡(luò)管理規(guī)范（OSEK Network Management，OSEK NM）、OSEK實現(xiàn)語言（OSEK Implementation Language，OIL）。其中 OSEK OS、OSEK COM、OSEK NM可以彼此獨立使用，在不同的控制器中不依賴于其他部分而單獨實現(xiàn)[4]。

OSEK操作系統(tǒng)規(guī)范[5]是OSEK標準的核心內(nèi)容，定義了一系列實時操作系統(tǒng)的內(nèi)核機制和面向上層應(yīng)用的標準API接口，包括任務(wù)管理和調(diào)度機制、中斷機制、事件機制、資源管理及計數(shù)器和警報管理等。

OSEK通訊規(guī)范[6]為應(yīng)用層軟件提供了一個統(tǒng)一的通信環(huán)境，它定義了獨立于所有通信協(xié)議之外的應(yīng)用軟件通信接口，規(guī)定了內(nèi)部通信（ECU內(nèi)部）和外部通信（ECU之間）時的行為方式。

OSEK網(wǎng)絡(luò)管理規(guī)范[7]提供了一種整車系統(tǒng)各節(jié)點的休眠喚醒狀態(tài)管理的策略。

OSEK操作系統(tǒng)作為OSEK標準最核心的內(nèi)容，針對汽車電子的實時性高、任務(wù)調(diào)度類型多的特點，提出了一系列的調(diào)度方式，并為調(diào)度方式提供了定時器、報警器等不同的事件類型。OSEK操作系統(tǒng)內(nèi)核針對汽車電子而設(shè)計，滿足了大部分控制器任務(wù)調(diào)度需求，實現(xiàn)了基于操作系統(tǒng)的軟件系統(tǒng)開放，提高了應(yīng)用層軟件的移植性，使獨立開發(fā)的應(yīng)用層軟件在不同硬件平臺進行復(fù)用成為可能。

2.2 開發(fā)模式的優(yōu)勢及局限性分析

這種開發(fā)模式，由整車廠提出系統(tǒng)需求，并對應(yīng)用層軟件進行開發(fā)，需求開發(fā)人員和應(yīng)用層軟件開發(fā)人員可以方便及時的溝通，避免了應(yīng)用層軟件開發(fā)人員對系統(tǒng)需求理解不充分。并且這種開發(fā)方式，可以很好地保護整車廠在控制器上的核心控制算法。整車廠對應(yīng)用層軟件進行開發(fā)，還有利于提高應(yīng)用層軟件的復(fù)用性，減少應(yīng)用層軟件開發(fā)周期，減少應(yīng)用層軟件存在的問題。

下面從整車廠的角度出發(fā)，在軟件開發(fā)、軟件迭代、軟件維護過程對這種開發(fā)模式進行分析。

2.2.1 軟件開發(fā)過程

這種軟件開發(fā)模式下，對整車廠和供應(yīng)商的分工有明確的規(guī)定，并且整車廠的開發(fā)需求都以標準接口文檔的形式表達，減少了供應(yīng)商軟件開發(fā)人員的理解難度，方便軟件開發(fā)人員的開發(fā)。

2.2.2 軟件迭代過程

在控制器的迭代開發(fā)中，軟件也要相應(yīng)的進行迭代開發(fā)，應(yīng)用層軟件由整車廠開發(fā)的方式，保證了應(yīng)用層軟件不會因為硬件平臺的切換、供應(yīng)商的更改而無法使用。但是，由于底層軟件是基于具體的軟件需求開發(fā)的，當應(yīng)用層軟件需求變更，可能會導(dǎo)致底層軟件也發(fā)生相應(yīng)的變更，底層軟件無法進行復(fù)用。而由于底層軟件的復(fù)雜性，底層軟件的變更周期和驗證周期較長。

2.2.3 軟件維護過程

應(yīng)用層軟件的沿用較好的減少了應(yīng)用層軟件算法出現(xiàn)的問題，避免了絕大部分軟件問題的發(fā)生。但是應(yīng)用層軟件的增量開發(fā)、軟件維護，需要一個較好的應(yīng)用層軟件框架支持，而OSEK標準或者其他一些通用的軟件架構(gòu)并沒有對應(yīng)用層軟件架構(gòu)有很好的指導(dǎo)，應(yīng)用層軟件架構(gòu)往往不夠清晰。這種情況導(dǎo)致應(yīng)用層軟件功能復(fù)雜度較高時，應(yīng)用層軟件內(nèi)各單元耦合度過高，軟件功能的刪減修改牽扯較多，增加軟件維護難度。

通過上面的分析，整車廠開發(fā)應(yīng)用層軟件的開發(fā)模式，在提高應(yīng)用層軟件復(fù)用性的同時，保護了整車廠的控制器核心算法。但是這種開發(fā)模式還存在兩個問題：底層軟件復(fù)用性差，更改難度大；沒有應(yīng)用層軟件架構(gòu)標準指導(dǎo)，應(yīng)用層軟件架構(gòu)不合理會導(dǎo)致軟件維護難度大。

3 基于AUTOSAR標準架構(gòu)的開發(fā)模式

為了建立標準的汽車電子軟件架構(gòu)，優(yōu)化應(yīng)用層軟件架構(gòu)，并且降低控制器軟件開發(fā)，國內(nèi)多家整車廠開始傾向于使用AUTOSAR架構(gòu)作為控制器軟件自主開發(fā)方案。

3.1 Autosar架構(gòu)概述

在2003年，由全球汽車制造商、零部件供應(yīng)商及其他電子、半導(dǎo)體和軟件系統(tǒng)公司聯(lián)合建立了汽車開放系統(tǒng)架構(gòu)聯(lián)盟（AUTomotive Open System Architecture，AUTOSAR），并聯(lián)合推出了一個開放化的、標準化的汽車嵌入式系統(tǒng)軟件架構(gòu)——AUTOSAR規(guī)范[8]。

根據(jù)AUTOSAR標準的分層規(guī)范，汽車嵌入式系統(tǒng)由上到下分為應(yīng)用軟件層（Application Software Layer，ASW）、運行時環(huán)境（Runtime Environment，RTE）、基礎(chǔ)軟件層（Basic Software Layer，BSW）、微控制器（Microcontroller）。為保證低耦合性和可移植性，在一般情況下，每一層級只能使用其下一層級所提供的接口和服務(wù)，并向其上一層級提供接口和服務(wù)，每層級僅能與其相鄰的層級進行接口和服務(wù)的調(diào)用，不允許跨層級調(diào)用。

圖2 AUTOSAR標準架構(gòu)

應(yīng)用軟件層（ASW）是由一些軟件組件組成[9]，軟件組件是根據(jù)系統(tǒng)功能分解的最小子單元，軟件組件是系統(tǒng)功能的模型化抽象，每個軟件組件實現(xiàn)一個系統(tǒng)功能。通過多個軟件組件間的合作執(zhí)行，最終實現(xiàn)控制器的功能實現(xiàn)。

運行時環(huán)境（RTE）是AUTOSAR規(guī)范實現(xiàn)軟硬件分離的重要手段[10]，RTE對上層的應(yīng)用軟件層的軟件組件進行調(diào)度和通信接口做管理，對下層的基礎(chǔ)軟件層的服務(wù)進行進一步封裝。應(yīng)用軟件層可以也只能通過RTE實現(xiàn)各個軟件組件間、基礎(chǔ)軟件與軟件組件間的接口通訊。RTE對基礎(chǔ)軟件的各項服務(wù)進行了標準化的定義，使得不同的開發(fā)者開發(fā)的軟件組件都通過相同的接口與基礎(chǔ)軟件通信，實現(xiàn)了高度的可移植性。

基礎(chǔ)軟件層（BSW）是直接與硬件進行數(shù)據(jù)交換[11]，將硬件的不同功能進行抽象，為上層提供基礎(chǔ)的軟件支持。由于基礎(chǔ)軟件層是對硬件進行直接操作，該部分軟件差異性較大，為了對這部分內(nèi)容做標準化，AUTOSAR對基礎(chǔ)軟件層繼續(xù)分為四層，服務(wù)層（Services Layer）、ECU抽象層（ECU Abstraction Layer）、微控制器抽象層（Microcontroller Abstrac-tion Layer，MCAL）和復(fù)雜驅(qū)動（Complex Drivers）。

3.2 開發(fā)模式的優(yōu)勢及局限性分析

基于Autosar標準的軟件開發(fā)模式，軟件分層更加明確，各層級之間的接口標準化更加徹底，有利于軟件的移植和復(fù)用。軟件組件的定義，增強了應(yīng)用層軟件的可裁剪性和可移植性。基于配置開發(fā)的方式，降低了底層軟件的開發(fā)難度，讓軟件開發(fā)經(jīng)驗不足的整車廠也可以更大程度地參與軟件開發(fā)過程中。

下面從整車廠的角度出發(fā)，在軟件開發(fā)、軟件迭代、軟件維護過程對這種開發(fā)模式進行分析。

3.2.1 軟件開發(fā)過程

首先，AUTOSAR基于配置工具的配置開發(fā)的方式，減少了代碼的編寫量，降低了軟件開發(fā)難度。但是，依賴配置工具的開發(fā)方式，帶來的成本增加過高，每個新項目都要重新購買軟件的開發(fā)許可。而且，軟件開發(fā)難度的降低并沒有很明顯地降低開發(fā)工作量，BSW的配置工具需要定義各層級的所有接口，對各層級接口進行匹配，這在代碼中的實現(xiàn)其實并不復(fù)雜。

3.2.2 軟件迭代過程

由于AUTOSAR軟件組件的定義，應(yīng)用層軟件可以方便地裁剪和移植，方便應(yīng)用層軟件的迭代開發(fā)。而且底層軟件都是基于配置開發(fā)，僅需要對相應(yīng)的配置進行修改，修改難度低。但是，AUTOSAR并沒有完全實現(xiàn)底層軟件的重用，需求的變更依然會導(dǎo)致底層軟件的重新配置，這在合作開發(fā)中依然會增加時間成本。

3.2.3 軟件維護過程

由于AUTOSAR軟件基于配置工具開發(fā)，手工編寫代碼量較少，很大程度地減少了軟件出現(xiàn)的問題，軟件可靠性強。并且軟件分層明確，軟件問題的查找和修復(fù)液較為簡單。

通過上述的分析，基于AUTOSAR的軟件開發(fā)模式，最大的優(yōu)勢在于軟件開發(fā)難度低，軟件可靠性高，軟件修改和迭代也較為簡單。但是AUTOSAR最大的問題在于，開發(fā)過于依賴配置工具，配置工具成本過高，很難在所有控制器中應(yīng)用。并且，AUTOSAR也沒有完全解決驅(qū)動軟件的復(fù)用問題，項目開發(fā)中依然需要對驅(qū)動軟件重復(fù)開發(fā)。

4 總結(jié)

本文調(diào)研了幾種當前常用的控制器軟件開發(fā)模式，分析了不同開發(fā)模式下制約軟件開發(fā)的主要原因。

根據(jù)上述調(diào)研結(jié)果，AUTOSAR標準通過“軟件組件”和基于配置開發(fā)的底層軟件開發(fā)方式，基本解決了應(yīng)用層與底層軟件分離后，軟件架構(gòu)還存在的問題，但隨之帶來了配置工具的成本問題。因此，汽車電子軟件架構(gòu)的優(yōu)化應(yīng)該是基于應(yīng)用層與底層軟件分離的思想，借鑒AUTOSAR架構(gòu)的解決思路，研究如何在不使用配置工具的情況下，降低底層軟件的開發(fā)難度，并提高應(yīng)用層軟件以及底層軟件的可移植性和可剪裁性。