基于AUTOSAR標(biāo)準(zhǔn)的TCU軟件設(shè)計
2017-12-18 08:02李育
汽車零部件 2017年8期
李育
(上海汽車變速器有限公司，上海 201807)
基于AUTOSAR標(biāo)準(zhǔn)的TCU軟件設(shè)計
李育
(上海汽車變速器有限公司，上海 201807)
基于AUTOSAR汽車電子軟件架構(gòu)標(biāo)準(zhǔn)提出了濕式雙離合變速箱控制單元(TCU)的嵌入式軟件架構(gòu)，并對其軟件組件與接口層實時環(huán)境的配置進行了詳細(xì)設(shè)計。測試結(jié)果表明，接口層實時環(huán)境配置實現(xiàn)了應(yīng)用層軟件與底層基礎(chǔ)軟件的分離，并通過AUTOSAR操作系統(tǒng)對TCU任務(wù)進行調(diào)度。
AUTOSAR；濕式雙離合變速箱控制單元；軟件設(shè)計
0 引言
隨著汽車電子產(chǎn)業(yè)的日益成熟，其內(nèi)嵌的控制算法也越來越復(fù)雜，所以提高嵌入式軟件的開發(fā)周期以及應(yīng)用軟件的可重用性，便成了各大汽車軟件供應(yīng)商急需解決的難題。為此，全球主流汽車制造商、零部件供應(yīng)商以及半導(dǎo)體供應(yīng)商、軟件開發(fā)商在2003年聯(lián)合成立了AUTOSAR(Automotive Open System Architecture)組織，建立了一種標(biāo)準(zhǔn)化的汽車電子軟件平臺，提出新的汽車電子開發(fā)理念來簡化ECU(Electronic Control Unit,電子控制器)開發(fā)流程，即汽車電子系統(tǒng)開發(fā)過程中軟件與硬件分離，使汽車電子開發(fā)從ECU硬件驅(qū)動轉(zhuǎn)變?yōu)閼?yīng)用軟件功能化驅(qū)動[1]。
隨著AUTOSAR標(biāo)準(zhǔn)逐漸成為未來汽車軟件架構(gòu)的主流，作為汽車電子核心部件的雙離合變速箱控制單元(Transmission Control Unit，TCU)，也將在今后的軟件開發(fā)中遵循該標(biāo)準(zhǔn)。因此，作者在系統(tǒng)地分析AUTOSAR標(biāo)準(zhǔn)及開發(fā)方法的基礎(chǔ)之上，研究了如何在TCU平臺上設(shè)計符合AUTOSAR 標(biāo)準(zhǔn)的應(yīng)用層軟件系統(tǒng)架構(gòu)、軟件組件以及接口層配置，其中，重點闡述了應(yīng)用層軟件組件的設(shè)計方法。
1 AUTOSAR架構(gòu)
基于TCU的系統(tǒng)需求，作者設(shè)計了符合AUTOSAR架構(gòu)的TCU軟件系統(tǒng)架構(gòu)，如圖1所示。
圖1 AUTOSAR軟件架構(gòu)
為了實現(xiàn)軟件功能的復(fù)用和標(biāo)準(zhǔn)化，AUTOSAR定義了層次化、模塊化的體系架構(gòu)，劃分為以下3個模塊[2-3]：
1.1 應(yīng)用軟件層SWC
應(yīng)用層代表著汽車電子軟件中最核心的功能，控制功能設(shè)計都在這一層進行。應(yīng)用層最基本的組成是軟件組件 SWC(Software Component)，包括圖1中的信號處理、離合器控制、協(xié)調(diào)控制、同步器控制、電子泵、自適應(yīng)學(xué)習(xí)等功能組件。每個SWC 都封裝了單個或多個運行體(Runnables)，并通過實時環(huán)境實現(xiàn)軟件組件之間的通信、系統(tǒng)功能調(diào)用以及TCU硬件資源的訪問。
1.2 實時環(huán)境 RTE
如圖1中的鏈接線，RTE(Runtime Environment)實現(xiàn)了應(yīng)用層軟件與底層基礎(chǔ)軟件之間的分離，上層的每個 SWC 都與 RTE 交互，使得數(shù)據(jù)與事件傳遞到其他各個模塊。RTE 實現(xiàn)了對I/O、存儲和其他基本服務(wù)的訪問。
1.3 基礎(chǔ)軟件層 BSW
如圖1所示，基礎(chǔ)軟件BSW(Basic Software)位于RTE之下、微控制器硬件之上，起到承上啟下的作用。BSW主要為應(yīng)用層提供硬件驅(qū)動、網(wǎng)絡(luò)通信和實時任務(wù)調(diào)度等底層服務(wù)。BSW本身又包括微控制器抽象層、ECU抽象層、服務(wù)層以及復(fù)雜驅(qū)動層。 BSW每一層均向其上層軟件組件提供服務(wù)，并屏蔽了其下層的實現(xiàn)細(xì)節(jié)。例如，微控制器抽象層為 ECU 抽象層提供服務(wù)，卻并不涉及微控制器與外部設(shè)備具體的物理連接，如接口類型和引腳等。
系統(tǒng)結(jié)構(gòu)設(shè)計需要根據(jù)系統(tǒng)需求來詳細(xì)定義上述3個模塊的拓?fù)浣Y(jié)構(gòu)，并定義各模塊內(nèi)功能子系統(tǒng)的接口屬性[4]。
2 AUTOSAR應(yīng)用層軟件組件開發(fā)
應(yīng)用層軟件是由多個相互交互的SWC構(gòu)成， SWC的設(shè)計除了定義自身的類型外，還需定義端口、接口、運行實體及觸發(fā)運行實體所對應(yīng)的RTE事件等屬性，如圖2所示。
圖2 組件開發(fā)內(nèi)容
2.1 SWC類型
AUTOSAR按功能屬性將SWC劃分為應(yīng)用層、傳感器/執(zhí)行器、標(biāo)定參數(shù)、服務(wù)層、ECU抽象層、復(fù)雜設(shè)備驅(qū)動等類型[5]。如圖1中的InputOutput組件即為傳感器/執(zhí)行器類型的SWC，而Auxiliary Coordinator等組件則實現(xiàn)了TCU應(yīng)用層控制策略，即為應(yīng)用層類型的SWC。以下描述的屬性設(shè)置都針對應(yīng)用層SWC。
2.2 SWC屬性設(shè)置
2.2.1 端口
端口(Port)定義了SWC與外界通信的傳輸方向以及所承載的接口。根據(jù)傳輸方向，端口分為供型端口(Provide-Port，對外提供某種數(shù)據(jù)或者某類操作)和需型端口(Receive-Port，請求從其他SWC獲得所需數(shù)據(jù)或者操作)。要實現(xiàn)數(shù)據(jù)由供型端口傳向需型端口，還需對這兩個端口指定數(shù)據(jù)傳輸?shù)慕涌陬愋?。如圖3所示，設(shè)置Motor Control的端口為供型端口，Input/Output的端口為需型端口，兩者之間的數(shù)據(jù)通過這兩個端口中的接口實現(xiàn)傳輸。
圖3 SWC之間端口和接口連接示意圖
2.2.2 軟件接口
端口只定義了軟件組件間通信方向，其中的通信內(nèi)容及交互方式則由AUTOSAR中定義的接口(Interface)來描述。對于應(yīng)用層軟件，接口有2種：發(fā)送者/接收者接口(Sender-Receiver：直接訪問數(shù)據(jù)的n∶n交互方式，文中主要用于應(yīng)用層各SWC間的交互)；客戶端/服務(wù)器接口(Client-Server：通過參數(shù)調(diào)用訪問數(shù)據(jù)的1∶n交互方式，文中主要用于應(yīng)用層SWC與BSW之間的交互)。如圖3所示，Motor Control與Output通過Sender-Receiver接口交互數(shù)據(jù)；Input/Output通過Client-Server接口與BSW的復(fù)雜驅(qū)動層(CDD)進行數(shù)據(jù)交互，復(fù)雜驅(qū)動層即為服務(wù)端。
2.2.3 運行實體
運行實體(Runnables)定義了SWC所需實現(xiàn)的功能函數(shù)及其輸入輸出信號，而TCU的功能函數(shù)是由基于Simulink開發(fā)的模型來實現(xiàn)。為生成符合AUTOSAR要求的SWC代碼，需要將Simulink模型通過dSPACE公司提供的TargetLink工具封裝成AUTOSAR架構(gòu)模型。如圖4所示，架構(gòu)模型的封裝包括：模型封裝成運行實體，相應(yīng)的輸入輸出封裝成虛擬BUS，并從SWC的端口中提取所需的信號。此外，運行實體還提供了參數(shù)訪問端口，通過該端口模型可以訪問外部的標(biāo)定參數(shù)。
圖4 AUTOSAR架構(gòu)轉(zhuǎn)換
運行實體的運行是由觸發(fā)事件來激活的， 為此AUTOSAR定義了多種觸發(fā)類型，而對于實時性要求比較高的TCU應(yīng)用層軟件，運行實體都選擇由周期性時間來觸發(fā)運行。具體的觸發(fā)周期需由運行實體的設(shè)計要求而定，如圖1中的Auxiliary Coordinator的運行周期為5 ms，而控制要求更高的Motor Control，運行周期為2.5 ms。
2.3 組合
按上述方法設(shè)計完成的SWC只是獨立的個體描述，要想將這些SWC關(guān)聯(lián)起來并通過RTE來實現(xiàn)這些關(guān)聯(lián)，則需將這些描述進行實例化并加載到一個容器里，此容器即稱之為組合(Composition)。組合原則上可以有多個，這里只需創(chuàng)建一個即可。
在組合里，包含了SWC和BSW各模塊的實例，通過關(guān)聯(lián)實例之間的端口來創(chuàng)建彼此鏈接關(guān)系。需要注意的是，不同接口類型的端口之間不能創(chuàng)建鏈接，而且只能由Sender指向Receiver，或只能由Client調(diào)用Server，反之都無法鏈接。除了建立內(nèi)部鏈接，還需定義外部端口來與外部系統(tǒng)通信，對于TCU，即實現(xiàn)與CAN總線的鏈接。文中通過dSPACE公司的SystemDesk工具創(chuàng)建了如圖5所示組合。
圖5 組合的內(nèi)部連接圖
3 RTE配置
前面描述了TCU的系統(tǒng)架構(gòu)和軟件組件，但如何將這些設(shè)計映射到具體的ECU中及其代碼實現(xiàn)則需要通過配置RTE來完成。
SWC與BSW、SWC之間的交互都是通過RTE提供的虛擬功能總線通信機制(Virtual File System，VFS)來實現(xiàn)的，如圖6所示。這樣的設(shè)計抽象了應(yīng)用層和基礎(chǔ)層，能防止SWC直接訪問BSW和OS，有利于監(jiān)控數(shù)據(jù)傳輸并保證數(shù)據(jù)一致性，而且同時支持簡單數(shù)據(jù)及復(fù)雜數(shù)據(jù)結(jié)構(gòu)以及SWC的多途徑應(yīng)用。
圖6 RTE實現(xiàn)的VFS通信機制
配置完成的RTE將自動生成C語言代碼，上述的數(shù)據(jù)交互是通過函數(shù)調(diào)用的方式實現(xiàn)，而不是傳統(tǒng)嵌入式C代碼(ERT)中的變量直接賦值形式。兩者間的差異如表1所示。
表1 AUTOSAR代碼與ERT代碼的差異
RTE定義的接口函數(shù)結(jié)構(gòu)如下：
_ 為端口； RTE還需配置運行實體與操作系統(tǒng)中任務(wù)(Tasks)的映射關(guān)系以及ECU內(nèi)部信號與系統(tǒng)信號(CAN信號)的映射關(guān)系，這些映射關(guān)系也會在RTE代碼中實現(xiàn)定義。 作者通過ETAS公司的ISOLAR-A工具完成RTE配置，如圖7所示。 圖7 RTE配置 將上述設(shè)計的配置文件通過TargetLink、RTA-RTE等工具轉(zhuǎn)換為真實的C代碼，同時嵌入各組件的功能代碼以及BSW的目標(biāo)代碼文件，再通過編譯、鏈接等步驟生成十六進制文件(*.Hex)，最后，將其下載到目標(biāo)TCU中，并在硬件在環(huán)測試平臺下進行測試，如圖8所示。該硬件在環(huán)平臺可以通過dSPACE軟件仿真整車環(huán)境并注入故障，而TCU與電磁閥、傳感器等真實負(fù)載相連。通過該平臺可以真實有效地測試TCU軟件系統(tǒng)的接口功能，用以檢驗基于AUTOSAR標(biāo)準(zhǔn)的TCU軟件開發(fā)方法應(yīng)用是否正確，能否達到預(yù)期目標(biāo)。 圖8 硬件在環(huán)測試平臺 軟件組件SWC和RTE是AUTOSAR的重要概念之一，因此測試SWC和RTE能否成功在TCU上運行，將是檢驗軟件開發(fā)方法的重要標(biāo)準(zhǔn)。 以位置信號為例，該信號的原始值由底層GPIO的頻率傳感器模塊輸出，并經(jīng)由RTE傳至應(yīng)用層的Input軟件組件中，再經(jīng)過信號處理組件處理后輸出給Auxiliary Coordinator使用。測試結(jié)果如圖9所示，采集到的PositionRAW即為通過Rte_Call_Run_IP_RP_IP_Positon(&PositonRAW)接口函數(shù)調(diào)用到的位置信號原始值，而Position則為經(jīng)過信號處理(Signal Process)組件之后的值，即通過Rte_IRead_Run_AC_RP_SP_Positon()接口函數(shù)讀取到的值。顯然，測試結(jié)果符合預(yù)期結(jié)果。 圖9 撥叉位置信號采集 任務(wù)調(diào)度測試的主要目的是為了驗證AUTOSAR操作系統(tǒng)的基本功能是否正常運行。比如RTE是否成功配置SWC的運行實體與任務(wù)的映射鏈接。測試結(jié)果如圖10所示，y軸表示任務(wù)和運行實體的運行狀態(tài)。Auxiliary Coordinator和Input都放在5 ms任務(wù)下運行，Input首先運行，執(zhí)行完畢之后進入等待狀態(tài)，同時激活A(yù)uxiliary Coordinator的運行。同樣地，放在2.5 ms任務(wù)下的Motor Control首先激活，并在運行完畢后激活Output里的Runnable_fast。測試結(jié)果顯示，TCU軟件已經(jīng)實現(xiàn)了操作系統(tǒng)的基本調(diào)度功能。 圖10 任務(wù)和運行實體的執(zhí)行過程 基于AUTOSAR標(biāo)準(zhǔn)的軟件開發(fā)是未來汽車電子嵌入式系統(tǒng)發(fā)展的趨勢?；贏UTOSAR標(biāo)準(zhǔn)對TCU軟件進行模塊化設(shè)計和實時環(huán)境接口配置，可實現(xiàn)應(yīng)用層軟件與底層基礎(chǔ)軟件的分離，從而便于實現(xiàn)軟件的擴展、移植和復(fù)用，相對于傳統(tǒng)的TCU軟件開發(fā)模式，將提高TCU的可靠性，并縮短開發(fā)周期，提高維護效率。 [1]孫升,宋珂,章桐,等.AUTOSAR標(biāo)準(zhǔn)發(fā)展及應(yīng)用現(xiàn)狀[J].機電一體化,2014(12):33-38,44. SUN S,SONG K,ZHANG T,et al.Development and Application Status of AUTOSAR[J].Mechatronics,2014(12):33-38,44. [2]張培鋒.參照AUTOSAR的汽油發(fā)動機ECU軟件設(shè)計[D].杭州:浙江大學(xué),2010. [3]王建俊.基于AUTOSAR規(guī)范的AMT系統(tǒng)軟件開發(fā)[D].濟南:山東大學(xué),2014. [4]李震,劉敏.基于Autosar的整車電子電氣架構(gòu)設(shè)計方法[J].機電一體化,2012,18(11):73-76. LI Z,LIU M.Electric & Electrical Architecture Developing Method Based on Autosar[J].Mechatronics,2012,18(11):73-76. [5]龍榮深.基于AUTOSAR標(biāo)準(zhǔn)的系統(tǒng)配置工具[D].杭州:浙江大學(xué),2010. TCUSoftwareDevelopmentBasedonAUTOSAR LI Yu (Shanghai Automobile Transmission Co.,Ltd., Shanghai 201807,China) A software architecture was proposed for wet dual clutch transmission control unit based on AUTOSAR. The detail designs of the component software and the real-time environment interface were described. The test results show that the application software can work independently upon the hardware, and the tasks of the transmission control unit can be scheduled by the operating system. AUTOSAR； Wet dual clutch transmission control unit； Software design 2017-03-30 李育(1970—)，女，大學(xué)本科，高級工程師，研究方向為自動變速器控制系統(tǒng)開發(fā)。E-mail：liyu@sagw.com。 10.19466/j.cnki.1674-1986.2017.08.006 U463.6 A 1674-1986(2017)08-026-05
4 測試驗證
4.1 RTE接口測試
4.2 RTE任務(wù)調(diào)度測試
5 結(jié)論
猜你喜歡
無線互聯(lián)科技(2022年8期)2022-06-23西安航空學(xué)院學(xué)報(2021年1期)2021-07-24科學(xué)家(2021年24期)2021-04-25艦船電子對抗(2020年2期)2020-06-23電子技術(shù)與軟件工程(2017年3期)2017-03-22教育教學(xué)論壇(2016年49期)2017-02-27新高考·高二數(shù)學(xué)(2016年7期)2017-01-23股市動態(tài)分析(2016年17期)2016-10-20太空探索(2016年6期)2016-07-10物聯(lián)網(wǎng)技術(shù)(2015年8期)2015-09-14
