汽車控制器軟件開(kāi)發(fā)模式調(diào)研

張可可，周沛澤

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

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

1 緒論

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

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

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

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

2.1 OSEK標(biāo)準(zhǔn)概述

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

OSEK標(biāo)準(zhǔn)規(guī)范主要包含四個(gè)部分：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實(shí)現(xiàn)語(yǔ)言（OSEK Implementation Language，OIL）。其中 OSEK OS、OSEK COM、OSEK NM可以彼此獨(dú)立使用，在不同的控制器中不依賴于其他部分而單獨(dú)實(shí)現(xiàn)[4]。

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

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

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

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

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

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

下面從整車廠的角度出發(fā)，在軟件開(kāi)發(fā)、軟件迭代、軟件維護(hù)過(guò)程對(duì)這種開(kāi)發(fā)模式進(jìn)行分析。

2.2.1 軟件開(kāi)發(fā)過(guò)程

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

2.2.2 軟件迭代過(guò)程

在控制器的迭代開(kāi)發(fā)中，軟件也要相應(yīng)的進(jìn)行迭代開(kāi)發(fā)，應(yīng)用層軟件由整車廠開(kāi)發(fā)的方式，保證了應(yīng)用層軟件不會(huì)因?yàn)橛布脚_(tái)的切換、供應(yīng)商的更改而無(wú)法使用。但是，由于底層軟件是基于具體的軟件需求開(kāi)發(fā)的，當(dāng)應(yīng)用層軟件需求變更，可能會(huì)導(dǎo)致底層軟件也發(fā)生相應(yīng)的變更，底層軟件無(wú)法進(jìn)行復(fù)用。而由于底層軟件的復(fù)雜性，底層軟件的變更周期和驗(yàn)證周期較長(zhǎng)。

2.2.3 軟件維護(hù)過(guò)程

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

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

3 基于AUTOSAR標(biāo)準(zhǔn)架構(gòu)的開(kāi)發(fā)模式

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

3.1 Autosar架構(gòu)概述

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

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

圖2 AUTOSAR標(biāo)準(zhǔn)架構(gòu)

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

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

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

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

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

下面從整車廠的角度出發(fā)，在軟件開(kāi)發(fā)、軟件迭代、軟件維護(hù)過(guò)程對(duì)這種開(kāi)發(fā)模式進(jìn)行分析。

3.2.1 軟件開(kāi)發(fā)過(guò)程

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

3.2.2 軟件迭代過(guò)程

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

3.2.3 軟件維護(hù)過(guò)程

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

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

4 總結(jié)

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

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