基于AUTOSAR標準的TCU軟件設計

李育

(上海汽車變速器有限公司，上海 201807)

基于AUTOSAR標準的TCU軟件設計

李育

(上海汽車變速器有限公司，上海 201807)

基于AUTOSAR汽車電子軟件架構標準提出了濕式雙離合變速箱控制單元(TCU)的嵌入式軟件架構，并對其軟件組件與接口層實時環境的配置進行了詳細設計。測試結果表明，接口層實時環境配置實現了應用層軟件與底層基礎軟件的分離，并通過AUTOSAR操作系統對TCU任務進行調度。

AUTOSAR；濕式雙離合變速箱控制單元；軟件設計

0 引言

隨著汽車電子產業的日益成熟，其內嵌的控制算法也越來越復雜，所以提高嵌入式軟件的開發周期以及應用軟件的可重用性，便成了各大汽車軟件供應商急需解決的難題。為此，全球主流汽車制造商、零部件供應商以及半導體供應商、軟件開發商在2003年聯合成立了AUTOSAR(Automotive Open System Architecture)組織，建立了一種標準化的汽車電子軟件平臺，提出新的汽車電子開發理念來簡化ECU(Electronic Control Unit,電子控制器)開發流程，即汽車電子系統開發過程中軟件與硬件分離，使汽車電子開發從ECU硬件驅動轉變為應用軟件功能化驅動[1]。

隨著AUTOSAR標準逐漸成為未來汽車軟件架構的主流，作為汽車電子核心部件的雙離合變速箱控制單元(Transmission Control Unit，TCU)，也將在今后的軟件開發中遵循該標準。因此，作者在系統地分析AUTOSAR標準及開發方法的基礎之上，研究了如何在TCU平臺上設計符合AUTOSAR 標準的應用層軟件系統架構、軟件組件以及接口層配置，其中，重點闡述了應用層軟件組件的設計方法。

1 AUTOSAR架構

基于TCU的系統需求，作者設計了符合AUTOSAR架構的TCU軟件系統架構，如圖1所示。

圖1 AUTOSAR軟件架構

為了實現軟件功能的復用和標準化，AUTOSAR定義了層次化、模塊化的體系架構，劃分為以下3個模塊[2-3]：

1.1 應用軟件層SWC

應用層代表著汽車電子軟件中最核心的功能，控制功能設計都在這一層進行。應用層最基本的組成是軟件組件 SWC(Software Component)，包括圖1中的信號處理、離合器控制、協調控制、同步器控制、電子泵、自適應學習等功能組件。每個SWC 都封裝了單個或多個運行體(Runnables)，并通過實時環境實現軟件組件之間的通信、系統功能調用以及TCU硬件資源的訪問。

1.2 實時環境 RTE

如圖1中的鏈接線，RTE(Runtime Environment)實現了應用層軟件與底層基礎軟件之間的分離，上層的每個 SWC 都與 RTE 交互，使得數據與事件傳遞到其他各個模塊。RTE 實現了對I/O、存儲和其他基本服務的訪問。

1.3 基礎軟件層 BSW

如圖1所示，基礎軟件BSW(Basic Software)位于RTE之下、微控制器硬件之上，起到承上啟下的作用。BSW主要為應用層提供硬件驅動、網絡通信和實時任務調度等底層服務。BSW本身又包括微控制器抽象層、ECU抽象層、服務層以及復雜驅動層。 BSW每一層均向其上層軟件組件提供服務，并屏蔽了其下層的實現細節。例如，微控制器抽象層為 ECU 抽象層提供服務，卻并不涉及微控制器與外部設備具體的物理連接，如接口類型和引腳等。

系統結構設計需要根據系統需求來詳細定義上述3個模塊的拓撲結構，并定義各模塊內功能子系統的接口屬性[4]。

2 AUTOSAR應用層軟件組件開發

應用層軟件是由多個相互交互的SWC構成， SWC的設計除了定義自身的類型外，還需定義端口、接口、運行實體及觸發運行實體所對應的RTE事件等屬性，如圖2所示。

圖2 組件開發內容

2.1 SWC類型

AUTOSAR按功能屬性將SWC劃分為應用層、傳感器/執行器、標定參數、服務層、ECU抽象層、復雜設備驅動等類型[5]。如圖1中的InputOutput組件即為傳感器/執行器類型的SWC，而Auxiliary Coordinator等組件則實現了TCU應用層控制策略，即為應用層類型的SWC。以下描述的屬性設置都針對應用層SWC。

2.2 SWC屬性設置

2.2.1 端口

端口(Port)定義了SWC與外界通信的傳輸方向以及所承載的接口。根據傳輸方向，端口分為供型端口(Provide-Port，對外提供某種數據或者某類操作)和需型端口(Receive-Port，請求從其他SWC獲得所需數據或者操作)。要實現數據由供型端口傳向需型端口，還需對這兩個端口指定數據傳輸的接口類型。如圖3所示，設置Motor Control的端口為供型端口，Input/Output的端口為需型端口，兩者之間的數據通過這兩個端口中的接口實現傳輸。

圖3 SWC之間端口和接口連接示意圖

2.2.2 軟件接口

端口只定義了軟件組件間通信方向，其中的通信內容及交互方式則由AUTOSAR中定義的接口(Interface)來描述。對于應用層軟件，接口有2種：發送者/接收者接口(Sender-Receiver：直接訪問數據的n∶n交互方式，文中主要用于應用層各SWC間的交互)；客戶端/服務器接口(Client-Server：通過參數調用訪問數據的1∶n交互方式，文中主要用于應用層SWC與BSW之間的交互)。如圖3所示，Motor Control與Output通過Sender-Receiver接口交互數據；Input/Output通過Client-Server接口與BSW的復雜驅動層(CDD)進行數據交互，復雜驅動層即為服務端。

2.2.3 運行實體

運行實體(Runnables)定義了SWC所需實現的功能函數及其輸入輸出信號，而TCU的功能函數是由基于Simulink開發的模型來實現。為生成符合AUTOSAR要求的SWC代碼，需要將Simulink模型通過dSPACE公司提供的TargetLink工具封裝成AUTOSAR架構模型。如圖4所示，架構模型的封裝包括：模型封裝成運行實體，相應的輸入輸出封裝成虛擬BUS，并從SWC的端口中提取所需的信號。此外，運行實體還提供了參數訪問端口，通過該端口模型可以訪問外部的標定參數。

圖4 AUTOSAR架構轉換

運行實體的運行是由觸發事件來激活的， 為此AUTOSAR定義了多種觸發類型，而對于實時性要求比較高的TCU應用層軟件，運行實體都選擇由周期性時間來觸發運行。具體的觸發周期需由運行實體的設計要求而定，如圖1中的Auxiliary Coordinator的運行周期為5 ms，而控制要求更高的Motor Control，運行周期為2.5 ms。

2.3 組合

按上述方法設計完成的SWC只是獨立的個體描述，要想將這些SWC關聯起來并通過RTE來實現這些關聯，則需將這些描述進行實例化并加載到一個容器里，此容器即稱之為組合(Composition)。組合原則上可以有多個，這里只需創建一個即可。

在組合里，包含了SWC和BSW各模塊的實例，通過關聯實例之間的端口來創建彼此鏈接關系。需要注意的是，不同接口類型的端口之間不能創建鏈接，而且只能由Sender指向Receiver，或只能由Client調用Server，反之都無法鏈接。除了建立內部鏈接，還需定義外部端口來與外部系統通信，對于TCU，即實現與CAN總線的鏈接。文中通過dSPACE公司的SystemDesk工具創建了如圖5所示組合。

圖5 組合的內部連接圖

3 RTE配置

前面描述了TCU的系統架構和軟件組件，但如何將這些設計映射到具體的ECU中及其代碼實現則需要通過配置RTE來完成。

SWC與BSW、SWC之間的交互都是通過RTE提供的虛擬功能總線通信機制(Virtual File System，VFS)來實現的，如圖6所示。這樣的設計抽象了應用層和基礎層，能防止SWC直接訪問BSW和OS，有利于監控數據傳輸并保證數據一致性，而且同時支持簡單數據及復雜數據結構以及SWC的多途徑應用。

圖6 RTE實現的VFS通信機制

配置完成的RTE將自動生成C語言代碼，上述的數據交互是通過函數調用的方式實現，而不是傳統嵌入式C代碼(ERT)中的變量直接賦值形式。兩者間的差異如表1所示。

表1 AUTOSAR代碼與ERT代碼的差異

RTE定義的接口函數結構如下：