汽車控制器軟件開發模式調研

張可可，周沛澤

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

關鍵字：汽車控制器；軟件開發模式；汽車電子軟件架構

1 緒論

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

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

2 整車廠開發應用層軟件的開發模式

整車廠在的軟件開發過程的精力主要集中在應用層軟件開發上，由供應商負責主導其他軟件開發過程。為了方便應用層軟件的移植，通常采用一些成熟的汽車電子軟件架構，其中OSEK標準作為廣泛應用的汽車電子軟件架構標準經常在這種開發模式下被使用。

2.1 OSEK標準概述

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

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

OSEK操作系統規范[5]是OSEK標準的核心內容，定義了一系列實時操作系統的內核機制和面向上層應用的標準API接口，包括任務管理和調度機制、中斷機制、事件機制、資源管理及計數器和警報管理等。

OSEK通訊規范[6]為應用層軟件提供了一個統一的通信環境，它定義了獨立于所有通信協議之外的應用軟件通信接口，規定了內部通信（ECU內部）和外部通信（ECU之間）時的行為方式。

OSEK網絡管理規范[7]提供了一種整車系統各節點的休眠喚醒狀態管理的策略。

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

2.2 開發模式的優勢及局限性分析

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

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

2.2.1 軟件開發過程

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

2.2.2 軟件迭代過程

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

2.2.3 軟件維護過程

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

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

3 基于AUTOSAR標準架構的開發模式

為了建立標準的汽車電子軟件架構，優化應用層軟件架構，并且降低控制器軟件開發，國內多家整車廠開始傾向于使用AUTOSAR架構作為控制器軟件自主開發方案。

3.1 Autosar架構概述

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

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

圖2 AUTOSAR標準架構

應用軟件層（ASW）是由一些軟件組件組成[9]，軟件組件是根據系統功能分解的最小子單元，軟件組件是系統功能的模型化抽象，每個軟件組件實現一個系統功能。通過多個軟件組件間的合作執行，最終實現控制器的功能實現。

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

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

3.2 開發模式的優勢及局限性分析

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

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

3.2.1 軟件開發過程

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

3.2.2 軟件迭代過程

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

3.2.3 軟件維護過程

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

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

4 總結

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

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