李育
(上海汽車(chē)變速器有限公司,上海 201807)
基于AUTOSAR標(biāo)準(zhǔn)的TCU軟件設(shè)計(jì)
李育
(上海汽車(chē)變速器有限公司,上海 201807)
基于AUTOSAR汽車(chē)電子軟件架構(gòu)標(biāo)準(zhǔn)提出了濕式雙離合變速箱控制單元(TCU)的嵌入式軟件架構(gòu),并對(duì)其軟件組件與接口層實(shí)時(shí)環(huán)境的配置進(jìn)行了詳細(xì)設(shè)計(jì)。測(cè)試結(jié)果表明,接口層實(shí)時(shí)環(huán)境配置實(shí)現(xiàn)了應(yīng)用層軟件與底層基礎(chǔ)軟件的分離,并通過(guò)AUTOSAR操作系統(tǒng)對(duì)TCU任務(wù)進(jìn)行調(diào)度。
AUTOSAR;濕式雙離合變速箱控制單元;軟件設(shè)計(jì)
隨著汽車(chē)電子產(chǎn)業(yè)的日益成熟,其內(nèi)嵌的控制算法也越來(lái)越復(fù)雜,所以提高嵌入式軟件的開(kāi)發(fā)周期以及應(yīng)用軟件的可重用性,便成了各大汽車(chē)軟件供應(yīng)商急需解決的難題。為此,全球主流汽車(chē)制造商、零部件供應(yīng)商以及半導(dǎo)體供應(yīng)商、軟件開(kāi)發(fā)商在2003年聯(lián)合成立了AUTOSAR(Automotive Open System Architecture)組織,建立了一種標(biāo)準(zhǔn)化的汽車(chē)電子軟件平臺(tái),提出新的汽車(chē)電子開(kāi)發(fā)理念來(lái)簡(jiǎn)化ECU(Electronic Control Unit,電子控制器)開(kāi)發(fā)流程,即汽車(chē)電子系統(tǒng)開(kāi)發(fā)過(guò)程中軟件與硬件分離,使汽車(chē)電子開(kāi)發(fā)從ECU硬件驅(qū)動(dòng)轉(zhuǎn)變?yōu)閼?yīng)用軟件功能化驅(qū)動(dòng)[1]。
隨著AUTOSAR標(biāo)準(zhǔn)逐漸成為未來(lái)汽車(chē)軟件架構(gòu)的主流,作為汽車(chē)電子核心部件的雙離合變速箱控制單元(Transmission Control Unit,TCU),也將在今后的軟件開(kāi)發(fā)中遵循該標(biāo)準(zhǔn)。因此,作者在系統(tǒng)地分析AUTOSAR標(biāo)準(zhǔn)及開(kāi)發(fā)方法的基礎(chǔ)之上,研究了如何在TCU平臺(tái)上設(shè)計(jì)符合AUTOSAR 標(biāo)準(zhǔn)的應(yīng)用層軟件系統(tǒng)架構(gòu)、軟件組件以及接口層配置,其中,重點(diǎn)闡述了應(yīng)用層軟件組件的設(shè)計(jì)方法。
基于TCU的系統(tǒng)需求,作者設(shè)計(jì)了符合AUTOSAR架構(gòu)的TCU軟件系統(tǒng)架構(gòu),如圖1所示。
圖1 AUTOSAR軟件架構(gòu)
為了實(shí)現(xiàn)軟件功能的復(fù)用和標(biāo)準(zhǔn)化,AUTOSAR定義了層次化、模塊化的體系架構(gòu),劃分為以下3個(gè)模塊[2-3]:
應(yīng)用層代表著汽車(chē)電子軟件中最核心的功能,控制功能設(shè)計(jì)都在這一層進(jìn)行。應(yīng)用層最基本的組成是軟件組件 SWC(Software Component),包括圖1中的信號(hào)處理、離合器控制、協(xié)調(diào)控制、同步器控制、電子泵、自適應(yīng)學(xué)習(xí)等功能組件。每個(gè)SWC 都封裝了單個(gè)或多個(gè)運(yùn)行體(Runnables),并通過(guò)實(shí)時(shí)環(huán)境實(shí)現(xiàn)軟件組件之間的通信、系統(tǒng)功能調(diào)用以及TCU硬件資源的訪(fǎng)問(wèn)。
如圖1中的鏈接線(xiàn),RTE(Runtime Environment)實(shí)現(xiàn)了應(yīng)用層軟件與底層基礎(chǔ)軟件之間的分離,上層的每個(gè) SWC 都與 RTE 交互,使得數(shù)據(jù)與事件傳遞到其他各個(gè)模塊。RTE 實(shí)現(xiàn)了對(duì)I/O、存儲(chǔ)和其他基本服務(wù)的訪(fǎng)問(wèn)。
如圖1所示,基礎(chǔ)軟件BSW(Basic Software)位于RTE之下、微控制器硬件之上,起到承上啟下的作用。BSW主要為應(yīng)用層提供硬件驅(qū)動(dòng)、網(wǎng)絡(luò)通信和實(shí)時(shí)任務(wù)調(diào)度等底層服務(wù)。BSW本身又包括微控制器抽象層、ECU抽象層、服務(wù)層以及復(fù)雜驅(qū)動(dòng)層。 BSW每一層均向其上層軟件組件提供服務(wù),并屏蔽了其下層的實(shí)現(xiàn)細(xì)節(jié)。例如,微控制器抽象層為 ECU 抽象層提供服務(wù),卻并不涉及微控制器與外部設(shè)備具體的物理連接,如接口類(lèi)型和引腳等。
系統(tǒng)結(jié)構(gòu)設(shè)計(jì)需要根據(jù)系統(tǒng)需求來(lái)詳細(xì)定義上述3個(gè)模塊的拓?fù)浣Y(jié)構(gòu),并定義各模塊內(nèi)功能子系統(tǒng)的接口屬性[4]。
應(yīng)用層軟件是由多個(gè)相互交互的SWC構(gòu)成, SWC的設(shè)計(jì)除了定義自身的類(lèi)型外,還需定義端口、接口、運(yùn)行實(shí)體及觸發(fā)運(yùn)行實(shí)體所對(duì)應(yīng)的RTE事件等屬性,如圖2所示。
圖2 組件開(kāi)發(fā)內(nèi)容
AUTOSAR按功能屬性將SWC劃分為應(yīng)用層、傳感器/執(zhí)行器、標(biāo)定參數(shù)、服務(wù)層、ECU抽象層、復(fù)雜設(shè)備驅(qū)動(dòng)等類(lèi)型[5]。如圖1中的InputOutput組件即為傳感器/執(zhí)行器類(lèi)型的SWC,而Auxiliary Coordinator等組件則實(shí)現(xiàn)了TCU應(yīng)用層控制策略,即為應(yīng)用層類(lèi)型的SWC。以下描述的屬性設(shè)置都針對(duì)應(yīng)用層SWC。
2.2.1 端口
端口(Port)定義了SWC與外界通信的傳輸方向以及所承載的接口。根據(jù)傳輸方向,端口分為供型端口(Provide-Port,對(duì)外提供某種數(shù)據(jù)或者某類(lèi)操作)和需型端口(Receive-Port,請(qǐng)求從其他SWC獲得所需數(shù)據(jù)或者操作)。要實(shí)現(xiàn)數(shù)據(jù)由供型端口傳向需型端口,還需對(duì)這兩個(gè)端口指定數(shù)據(jù)傳輸?shù)慕涌陬?lèi)型。如圖3所示,設(shè)置Motor Control的端口為供型端口,Input/Output的端口為需型端口,兩者之間的數(shù)據(jù)通過(guò)這兩個(gè)端口中的接口實(shí)現(xiàn)傳輸。
圖3 SWC之間端口和接口連接示意圖
2.2.2 軟件接口
端口只定義了軟件組件間通信方向,其中的通信內(nèi)容及交互方式則由AUTOSAR中定義的接口(Interface)來(lái)描述。對(duì)于應(yīng)用層軟件,接口有2種:發(fā)送者/接收者接口(Sender-Receiver:直接訪(fǎng)問(wèn)數(shù)據(jù)的n∶n交互方式,文中主要用于應(yīng)用層各SWC間的交互);客戶(hù)端/服務(wù)器接口(Client-Server:通過(guò)參數(shù)調(diào)用訪(fǎng)問(wèn)數(shù)據(jù)的1∶n交互方式,文中主要用于應(yīng)用層SWC與BSW之間的交互)。如圖3所示,Motor Control與Output通過(guò)Sender-Receiver接口交互數(shù)據(jù);Input/Output通過(guò)Client-Server接口與BSW的復(fù)雜驅(qū)動(dòng)層(CDD)進(jìn)行數(shù)據(jù)交互,復(fù)雜驅(qū)動(dòng)層即為服務(wù)端。
2.2.3 運(yùn)行實(shí)體
運(yùn)行實(shí)體(Runnables)定義了SWC所需實(shí)現(xiàn)的功能函數(shù)及其輸入輸出信號(hào),而TCU的功能函數(shù)是由基于Simulink開(kāi)發(fā)的模型來(lái)實(shí)現(xiàn)。為生成符合AUTOSAR要求的SWC代碼,需要將Simulink模型通過(guò)dSPACE公司提供的TargetLink工具封裝成AUTOSAR架構(gòu)模型。如圖4所示,架構(gòu)模型的封裝包括:模型封裝成運(yùn)行實(shí)體,相應(yīng)的輸入輸出封裝成虛擬BUS,并從SWC的端口中提取所需的信號(hào)。此外,運(yùn)行實(shí)體還提供了參數(shù)訪(fǎng)問(wèn)端口,通過(guò)該端口模型可以訪(fǎng)問(wèn)外部的標(biāo)定參數(shù)。
圖4 AUTOSAR架構(gòu)轉(zhuǎn)換
運(yùn)行實(shí)體的運(yùn)行是由觸發(fā)事件來(lái)激活的, 為此AUTOSAR定義了多種觸發(fā)類(lèi)型,而對(duì)于實(shí)時(shí)性要求比較高的TCU應(yīng)用層軟件,運(yùn)行實(shí)體都選擇由周期性時(shí)間來(lái)觸發(fā)運(yùn)行。具體的觸發(fā)周期需由運(yùn)行實(shí)體的設(shè)計(jì)要求而定,如圖1中的Auxiliary Coordinator的運(yùn)行周期為5 ms,而控制要求更高的Motor Control,運(yùn)行周期為2.5 ms。
按上述方法設(shè)計(jì)完成的SWC只是獨(dú)立的個(gè)體描述,要想將這些SWC關(guān)聯(lián)起來(lái)并通過(guò)RTE來(lái)實(shí)現(xiàn)這些關(guān)聯(lián),則需將這些描述進(jìn)行實(shí)例化并加載到一個(gè)容器里,此容器即稱(chēng)之為組合(Composition)。組合原則上可以有多個(gè),這里只需創(chuàng)建一個(gè)即可。
在組合里,包含了SWC和BSW各模塊的實(shí)例,通過(guò)關(guān)聯(lián)實(shí)例之間的端口來(lái)創(chuàng)建彼此鏈接關(guān)系。需要注意的是,不同接口類(lèi)型的端口之間不能創(chuàng)建鏈接,而且只能由Sender指向Receiver,或只能由Client調(diào)用Server,反之都無(wú)法鏈接。除了建立內(nèi)部鏈接,還需定義外部端口來(lái)與外部系統(tǒng)通信,對(duì)于TCU,即實(shí)現(xiàn)與CAN總線(xiàn)的鏈接。文中通過(guò)dSPACE公司的SystemDesk工具創(chuàng)建了如圖5所示組合。
圖5 組合的內(nèi)部連接圖
前面描述了TCU的系統(tǒng)架構(gòu)和軟件組件,但如何將這些設(shè)計(jì)映射到具體的ECU中及其代碼實(shí)現(xiàn)則需要通過(guò)配置RTE來(lái)完成。
SWC與BSW、SWC之間的交互都是通過(guò)RTE提供的虛擬功能總線(xiàn)通信機(jī)制(Virtual File System,VFS)來(lái)實(shí)現(xiàn)的,如圖6所示。這樣的設(shè)計(jì)抽象了應(yīng)用層和基礎(chǔ)層,能防止SWC直接訪(fǎng)問(wèn)BSW和OS,有利于監(jiān)控?cái)?shù)據(jù)傳輸并保證數(shù)據(jù)一致性,而且同時(shí)支持簡(jiǎn)單數(shù)據(jù)及復(fù)雜數(shù)據(jù)結(jié)構(gòu)以及SWC的多途徑應(yīng)用。
圖6 RTE實(shí)現(xiàn)的VFS通信機(jī)制
配置完成的RTE將自動(dòng)生成C語(yǔ)言代碼,上述的數(shù)據(jù)交互是通過(guò)函數(shù)調(diào)用的方式實(shí)現(xiàn),而不是傳統(tǒng)嵌入式C代碼(ERT)中的變量直接賦值形式。兩者間的差異如表1所示。
表1 AUTOSAR代碼與ERT代碼的差異
RTE定義的接口函數(shù)結(jié)構(gòu)如下:
_ 為端口; RTE還需配置運(yùn)行實(shí)體與操作系統(tǒng)中任務(wù)(Tasks)的映射關(guān)系以及ECU內(nèi)部信號(hào)與系統(tǒng)信號(hào)(CAN信號(hào))的映射關(guān)系,這些映射關(guān)系也會(huì)在RTE代碼中實(shí)現(xiàn)定義。 作者通過(guò)ETAS公司的ISOLAR-A工具完成RTE配置,如圖7所示。 圖7 RTE配置 將上述設(shè)計(jì)的配置文件通過(guò)TargetLink、RTA-RTE等工具轉(zhuǎn)換為真實(shí)的C代碼,同時(shí)嵌入各組件的功能代碼以及BSW的目標(biāo)代碼文件,再通過(guò)編譯、鏈接等步驟生成十六進(jìn)制文件(*.Hex),最后,將其下載到目標(biāo)TCU中,并在硬件在環(huán)測(cè)試平臺(tái)下進(jìn)行測(cè)試,如圖8所示。該硬件在環(huán)平臺(tái)可以通過(guò)dSPACE軟件仿真整車(chē)環(huán)境并注入故障,而TCU與電磁閥、傳感器等真實(shí)負(fù)載相連。通過(guò)該平臺(tái)可以真實(shí)有效地測(cè)試TCU軟件系統(tǒng)的接口功能,用以檢驗(yàn)基于AUTOSAR標(biāo)準(zhǔn)的TCU軟件開(kāi)發(fā)方法應(yīng)用是否正確,能否達(dá)到預(yù)期目標(biāo)。 圖8 硬件在環(huán)測(cè)試平臺(tái) 軟件組件SWC和RTE是AUTOSAR的重要概念之一,因此測(cè)試SWC和RTE能否成功在TCU上運(yùn)行,將是檢驗(yàn)軟件開(kāi)發(fā)方法的重要標(biāo)準(zhǔn)。 以位置信號(hào)為例,該信號(hào)的原始值由底層GPIO的頻率傳感器模塊輸出,并經(jīng)由RTE傳至應(yīng)用層的Input軟件組件中,再經(jīng)過(guò)信號(hào)處理組件處理后輸出給Auxiliary Coordinator使用。測(cè)試結(jié)果如圖9所示,采集到的PositionRAW即為通過(guò)Rte_Call_Run_IP_RP_IP_Positon(&PositonRAW)接口函數(shù)調(diào)用到的位置信號(hào)原始值,而Position則為經(jīng)過(guò)信號(hào)處理(Signal Process)組件之后的值,即通過(guò)Rte_IRead_Run_AC_RP_SP_Positon()接口函數(shù)讀取到的值。顯然,測(cè)試結(jié)果符合預(yù)期結(jié)果。 圖9 撥叉位置信號(hào)采集 任務(wù)調(diào)度測(cè)試的主要目的是為了驗(yàn)證AUTOSAR操作系統(tǒng)的基本功能是否正常運(yùn)行。比如RTE是否成功配置SWC的運(yùn)行實(shí)體與任務(wù)的映射鏈接。測(cè)試結(jié)果如圖10所示,y軸表示任務(wù)和運(yùn)行實(shí)體的運(yùn)行狀態(tài)。Auxiliary Coordinator和Input都放在5 ms任務(wù)下運(yùn)行,Input首先運(yùn)行,執(zhí)行完畢之后進(jìn)入等待狀態(tài),同時(shí)激活A(yù)uxiliary Coordinator的運(yùn)行。同樣地,放在2.5 ms任務(wù)下的Motor Control首先激活,并在運(yùn)行完畢后激活Output里的Runnable_fast。測(cè)試結(jié)果顯示,TCU軟件已經(jīng)實(shí)現(xiàn)了操作系統(tǒng)的基本調(diào)度功能。 圖10 任務(wù)和運(yùn)行實(shí)體的執(zhí)行過(guò)程 基于AUTOSAR標(biāo)準(zhǔn)的軟件開(kāi)發(fā)是未來(lái)汽車(chē)電子嵌入式系統(tǒng)發(fā)展的趨勢(shì)。基于AUTOSAR標(biāo)準(zhǔn)對(duì)TCU軟件進(jìn)行模塊化設(shè)計(jì)和實(shí)時(shí)環(huán)境接口配置,可實(shí)現(xiàn)應(yīng)用層軟件與底層基礎(chǔ)軟件的分離,從而便于實(shí)現(xiàn)軟件的擴(kuò)展、移植和復(fù)用,相對(duì)于傳統(tǒng)的TCU軟件開(kāi)發(fā)模式,將提高TCU的可靠性,并縮短開(kāi)發(fā)周期,提高維護(hù)效率。 [1]孫升,宋珂,章桐,等.AUTOSAR標(biāo)準(zhǔn)發(fā)展及應(yīng)用現(xiàn)狀[J].機(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ā)動(dòng)機(jī)ECU軟件設(shè)計(jì)[D].杭州:浙江大學(xué),2010. [3]王建俊.基于AUTOSAR規(guī)范的AMT系統(tǒng)軟件開(kāi)發(fā)[D].濟(jì)南:山東大學(xué),2014. [4]李震,劉敏.基于Autosar的整車(chē)電子電氣架構(gòu)設(shè)計(jì)方法[J].機(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é)本科,高級(jí)工程師,研究方向?yàn)樽詣?dòng)變速器控制系統(tǒng)開(kāi)發(fā)。E-mail:liyu@sagw.com。 10.19466/j.cnki.1674-1986.2017.08.006 U463.6 A 1674-1986(2017)08-026-054 測(cè)試驗(yàn)證
4.1 RTE接口測(cè)試
4.2 RTE任務(wù)調(diào)度測(cè)試
5 結(jié)論