崔淑梅，張玉琦，杜博超，姚 凱，程 遠(yuǎn)

(哈爾濱工業(yè)大學(xué) 電氣工程及自動化學(xué)院，哈爾濱 150001)

0 引 言

近年來汽車的電氣化電子化程度不斷提高，控制器和軟件功能數(shù)量急劇增加，硬件平臺呈現(xiàn)多樣化，導(dǎo)致軟件復(fù)用性低，開發(fā)成本上升。為了解決這些問題，2003年由9家汽車行業(yè)的巨頭攜手合作，提出了致力于為汽車工業(yè)開發(fā)的一個開放的、標(biāo)準(zhǔn)化的軟件架構(gòu)，即汽車開放系統(tǒng)架構(gòu)[1](AUTomotive Open System ARchitecture， 以下簡稱AUTOSAR)。汽車企業(yè)采用AUTOSAR標(biāo)準(zhǔn)架構(gòu)定義控制軟件已經(jīng)是主要趨勢[2]。許多中國廠商也成為AUTOSAR聯(lián)盟成員。目前，AUTOSAR標(biāo)準(zhǔn)普遍應(yīng)用于汽車電控系統(tǒng)軟件研發(fā)中[3-4]，構(gòu)建和設(shè)計符合AUTOSAR標(biāo)準(zhǔn)的軟件架構(gòu)，學(xué)者們已在汽車多個控制單元如柴油機(jī)后處理控制[5]、主動安全帶控制[6]等展開研究。

在電動汽車驅(qū)動電機(jī)領(lǐng)域，傳統(tǒng)電機(jī)控制器的研究普遍以控制算法為核心，以電機(jī)運(yùn)行狀態(tài)及性能為目標(biāo)，聚焦于電機(jī)本體-控制器的自閉環(huán)系統(tǒng)功能實(shí)現(xiàn)。而對于控制器與整車的通訊、數(shù)據(jù)以及功能安全的信息交互少有設(shè)計和研究，且控制器沒有進(jìn)行分層設(shè)計，軟件與軟件、軟件與硬件耦合嚴(yán)重。隨智能化控制趨勢的逐步推進(jìn)，電動汽車架構(gòu)網(wǎng)絡(luò)逐步發(fā)展成分層、模塊化、少耦合特征，電機(jī)控制器作為整車電子控制單元之一，更應(yīng)考慮在其自閉環(huán)系統(tǒng)之外匹配整車分層架構(gòu)并適應(yīng)系統(tǒng)特性，針對其與整車的通訊、信息交互和系統(tǒng)容錯、功能安全的研究與電機(jī)控制算法的需求和重要性并駕齊驅(qū)。另一方面，電機(jī)控制器內(nèi)部功能模塊同樣不斷增多，軟件越來越復(fù)雜，開發(fā)商也有多樣選擇，進(jìn)行軟件架構(gòu)設(shè)計，減少其內(nèi)部軟硬件耦合、提升開發(fā)時間和成本效能愈發(fā)凸顯意義[7]。國內(nèi)一些公司正在開發(fā)基于分層設(shè)計的軟件架構(gòu)。各電機(jī)控制器開發(fā)單位已完全掌握電機(jī)控制策略、保護(hù)策略等上層軟件及核心算法的開發(fā)，但是涉及底層硬件外設(shè)的配置與抽象等的底層軟件開發(fā)目前還處于起步階段。對于功能安全的考慮還在不斷完善中[8]。

目前，行業(yè)內(nèi)基于AUTOSAR的電機(jī)控制器軟件構(gòu)架的研究主要針對某一具體需求進(jìn)行研究。文獻(xiàn)[9]以電機(jī)控制器運(yùn)行控制參數(shù)的優(yōu)化和標(biāo)定為目標(biāo)，研究并設(shè)計基于AUTOSAR的電子控制單元(Electronic Control Unit, 以下簡稱ECU)標(biāo)定軟件；文獻(xiàn)[10]基于AUTOSAR編寫工具對電機(jī)助力轉(zhuǎn)向系統(tǒng)的軟件組件進(jìn)行設(shè)計開發(fā)，提高了系統(tǒng)可替代性和靈活性，并使用MATLAB/Simulink進(jìn)行驗證；文獻(xiàn)[11，12]均設(shè)計開發(fā)了基于AUTOSAR的永磁同步電機(jī)矢量控制系統(tǒng)，并通過硬件在環(huán)設(shè)備對控制效果進(jìn)行了仿真驗證，軟件功能的實(shí)現(xiàn)均集中在應(yīng)用層；文獻(xiàn)[13]采用英飛凌TC1767處理器針對永磁同步電機(jī)設(shè)計了基于AUTOSAR標(biāo)準(zhǔn)的電機(jī)ECU控制軟件架構(gòu)，將整個軟件架構(gòu)分為應(yīng)用層、算法庫層、ECU抽象層及微控制器抽象層，但僅考慮了電機(jī)矢量控制算法對應(yīng)用層和算法庫層進(jìn)行說明，其余電機(jī)控制功能以及各層設(shè)計未有提及。文獻(xiàn)[14]基于AUTOSAR對電機(jī)軟件控制系統(tǒng)軟硬件架構(gòu)進(jìn)行了適配設(shè)計，具體功能實(shí)現(xiàn)均放在應(yīng)用軟件層，而對于基礎(chǔ)軟件層的中斷服務(wù)等未具體說明，且電機(jī)矢量控制算法被封裝在一個電機(jī)控制算法軟件組件(Software Component, 以下簡稱SWC)中執(zhí)行，架構(gòu)設(shè)計較為單一。

綜上分析，國內(nèi)外對于AUTOSAR在電機(jī)控制器軟件架構(gòu)上的應(yīng)用仍處于起步的探索階段。對宏觀架構(gòu)設(shè)計而言，需進(jìn)一步對分層設(shè)計的準(zhǔn)則進(jìn)行明確闡述，電機(jī)控制器架構(gòu)與上端整車控制器、下端底層硬件的解耦目標(biāo)有待明晰；從具體實(shí)現(xiàn)角度來說，需更好地提高對整體架構(gòu)資源利用率，涵蓋更多電機(jī)控制器的功能，尤其是對于構(gòu)架的通用性和開發(fā)與整車性能密切相關(guān)的狀態(tài)檢測與故障診斷等安全功能模塊的考慮還不夠充分。

為構(gòu)建更通用的電動汽車電機(jī)控制器的軟件架構(gòu)，上層軟件的可移植性、底層硬件與軟件的高度解耦性、整體架構(gòu)的高安全性是本文旨在追求的目標(biāo)。本文將提出一種同時考慮電機(jī)運(yùn)行控制和功能安全的AUTOSAR電機(jī)控制器軟件架構(gòu)，結(jié)合AUTOSAR的架構(gòu)特點(diǎn)和電機(jī)控制器的功能特性，對分層思想和原則進(jìn)行明晰，建立完整的構(gòu)架體系，對各層進(jìn)行功能和原理解釋，并通過具體實(shí)例進(jìn)行分析說明。

1 AUTOSAR基本思想與構(gòu)成

AUTOSAR架構(gòu)將運(yùn)行在微控制器上的軟件分為三層[15]：完全獨(dú)立于硬件的應(yīng)用層(Application Layer, 以下簡稱APP)和與硬件相關(guān)的基礎(chǔ)軟件層(Basic Software, 以下簡稱BSW)，以及在兩者之間設(shè)立的實(shí)時運(yùn)行環(huán)境層(Runtime Environment, 以下簡稱RTE)，如圖1所示。

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

AUTOSAR APP主要包括三部分：應(yīng)用SWC，接口與可運(yùn)行實(shí)體。APP軟件包含許多獨(dú)立的軟件組件單元，一般分為應(yīng)用軟件組件、傳感器軟件組件以及執(zhí)行器軟件組件三類。軟件組件的內(nèi)部行為通過一個或多個可運(yùn)行實(shí)體實(shí)現(xiàn)，軟件組件之間通過接口進(jìn)行交互，完成數(shù)據(jù)傳輸和函數(shù)調(diào)用操作。

運(yùn)行時RTE是AUTOSAR中虛擬功能總線(Virtual Function Bus, 以下簡稱VFB)的具體實(shí)現(xiàn)，基本要求是實(shí)現(xiàn)和管理AUTOSAR的軟件組件間、基礎(chǔ)軟件間、軟件組件與基礎(chǔ)軟件之間的通信，以保證其通信行為正確，并且相互之間不會干擾，使組件設(shè)計可以專注于內(nèi)部算法的實(shí)現(xiàn)和優(yōu)化。同時，RTE作為APP和BSW的銜接，為APP提供標(biāo)準(zhǔn)接口來調(diào)用底層的資源，使得ECU軟件的開發(fā)與具體的硬件相脫離，上層應(yīng)用策略開發(fā)人員可以更加專注于軟件功能的開發(fā)，而不用糾纏于軟件底層的細(xì)節(jié)，增強(qiáng)系統(tǒng)的安全可靠性。

BSW主要分為四部分：微控制單元(Micro Control Unit，以下簡稱MCU)抽象層、ECU抽象層、服務(wù)層以及復(fù)雜驅(qū)動層。BSW負(fù)責(zé)將底層控制器提供的數(shù)據(jù)等信息進(jìn)行抽象傳輸至APP，實(shí)現(xiàn)軟硬件的解耦，同時為APP提供一些基本服務(wù)。MCU抽象層位于BSW最底層，包含內(nèi)部驅(qū)動，可以直接訪問MCU及片內(nèi)外設(shè)，可分為MCU驅(qū)動、存儲器驅(qū)動、通信驅(qū)動和I/O驅(qū)動四部分，各部分由具體的與MCU硬件相對應(yīng)的驅(qū)動模塊組成。ECU抽象層負(fù)責(zé)提供統(tǒng)一的訪問接口，實(shí)現(xiàn)對通信、內(nèi)存或者I/O的訪問，從而無需考慮這些資源是由MCU提供還是由外部設(shè)備提供，MCU外部設(shè)備的驅(qū)動就位于這一層，該層主要由板載設(shè)備抽象、存儲器硬件抽象、通信硬件抽象和I/O硬件抽象四部分組成。服務(wù)層是BSW的最高層，可以實(shí)現(xiàn)與APP軟件的關(guān)聯(lián)，主要分成通信服務(wù)、內(nèi)存服務(wù)、系統(tǒng)服務(wù)。通信服務(wù)通過通信硬件抽象來與通信驅(qū)動程序進(jìn)行交互，為車輛通信網(wǎng)絡(luò)和車載網(wǎng)絡(luò)的診斷通信提供統(tǒng)一接口；內(nèi)存服務(wù)負(fù)責(zé)非易失性數(shù)據(jù)的管理，以統(tǒng)一的方式為應(yīng)用程序提供數(shù)據(jù)，同時對存儲位置和屬性進(jìn)行抽象；系統(tǒng)服務(wù)包含一組模塊和函數(shù)，如實(shí)時操作系統(tǒng)(定時器服務(wù))、錯誤管理等，這些資源可以被所有應(yīng)用層軟件調(diào)用。復(fù)雜驅(qū)動層作為BSW中由用戶自主開發(fā)的模塊，主要針對AUTOSAR不支持或者未標(biāo)準(zhǔn)化的硬件資源，實(shí)現(xiàn)處理復(fù)雜傳感器及執(zhí)行器的特定功能和時間要求。該層可以通過提供AUTOSAR模塊可配置的接口與分層架構(gòu)的其他模塊進(jìn)行互相訪問[16]。

2 電機(jī)控制器各部分功能描述及軟硬件支持

電機(jī)控制系統(tǒng)主要執(zhí)行總線傳輸過來的整車轉(zhuǎn)矩、轉(zhuǎn)速和方向等控制命令，通過讀取位置和電流電壓傳感器，獲得電機(jī)的狀態(tài)，經(jīng)過算法計算出電機(jī)逆變器的PWM開關(guān)控制信號，通過控制電機(jī)的電流和電壓實(shí)現(xiàn)電機(jī)的運(yùn)行狀態(tài)控制。同時，為了提高系統(tǒng)的安全可靠性，控制器需要通過傳感器信息和網(wǎng)絡(luò)數(shù)據(jù)監(jiān)測電機(jī)系統(tǒng)的狀態(tài)，進(jìn)行故障診斷和容錯以及保護(hù)等控制。軟件主要具有數(shù)據(jù)獲取、數(shù)據(jù)解算、控制算法、狀態(tài)監(jiān)測、數(shù)據(jù)存儲以及通信服務(wù)等功能模塊。具體功能描述如圖2所示。

圖2 電機(jī)控制器功能模塊及其軟硬件支持

其中數(shù)據(jù)獲取模塊⑥是控制器的基礎(chǔ)功能，并且與外部電機(jī)直接關(guān)聯(lián)。其主要依托電壓傳感器、電流傳感器、ADC采樣電路、溫度采樣電路以及旋變解碼電路等硬件電路的支持，獲得電機(jī)的電壓、電流、溫度、轉(zhuǎn)速以及位置等基礎(chǔ)數(shù)據(jù)，為控制器的各部分功能提供原始的數(shù)據(jù)支撐。

數(shù)據(jù)解算模塊③與控制算法模塊②是控制器的核心功能。其中數(shù)據(jù)解算主要是對獲取的電機(jī)數(shù)據(jù)進(jìn)行Clarke變換、Park變換等處理，為控制算法提供直接數(shù)據(jù)支持。而控制算法由來自整車控制器的指令進(jìn)行選擇，常見的控制策略包括涵蓋矢量控制、直接轉(zhuǎn)矩控制等的轉(zhuǎn)速、轉(zhuǎn)矩控制模式。根據(jù)不同的控制算法輸出，再通過選擇電流閉環(huán)、iPark變換、SVPWM等數(shù)據(jù)解算模塊產(chǎn)生控制信號，并依托驅(qū)動電路的硬件支持，最終產(chǎn)生開關(guān)信號。

狀態(tài)檢測模塊⑤則包括自檢、過流、過壓、過溫等保護(hù)以及基于大數(shù)據(jù)分析、數(shù)字孿生技術(shù)等工況識別、故障診斷與壽命預(yù)測等。通過對獲取的原始電機(jī)狀態(tài)參數(shù)的判斷，確定是否發(fā)生過流過壓過溫等現(xiàn)象，若有上述現(xiàn)象發(fā)生，將產(chǎn)生相應(yīng)的報警信號，并清除PWM軟件使能，阻止SVPWM模塊產(chǎn)生開關(guān)控制信號，終止上述現(xiàn)象對逆變電路及電機(jī)的損害。而工況識別及故障診斷與壽命預(yù)測則是利用電機(jī)運(yùn)行的狀態(tài)參數(shù)進(jìn)行更深層次的計算對比分析，并輸出相應(yīng)的壽命預(yù)測值及故障特征量，同時根據(jù)識別的工況及時調(diào)整控制策略，以達(dá)到最優(yōu)的燃油經(jīng)濟(jì)性[17]。

數(shù)據(jù)存儲模塊④主要存儲電機(jī)標(biāo)定數(shù)表以及故障信息庫數(shù)據(jù)。其中電機(jī)標(biāo)定數(shù)表主要是為控制算法如最大轉(zhuǎn)矩電流比(MTPA)控制提供數(shù)據(jù)，根據(jù)整車控制器下達(dá)不同的目標(biāo)轉(zhuǎn)矩反饋給控制算法相應(yīng)的交直軸電流，達(dá)到電機(jī)控制器的MTPA控制。而故障信息庫則是將狀態(tài)監(jiān)測中故障診斷模塊反饋的故障特征信息及相關(guān)電機(jī)運(yùn)行參數(shù)進(jìn)行存儲。

通訊服務(wù)模塊①則是通過CAN通信、485通信等通信方式與整車控制器以及其他控制器進(jìn)行交互，將電機(jī)轉(zhuǎn)速、轉(zhuǎn)子溫度、報警信號以及故障類型上傳給整車控制器，同時接收整車控制器下達(dá)的目標(biāo)轉(zhuǎn)速、目標(biāo)轉(zhuǎn)矩以及控制模式選擇等信號。

綜上，電機(jī)控制器通過通訊服務(wù)模塊與整車控制端進(jìn)行信息交互，依托硬件電路獲取電機(jī)的運(yùn)行狀態(tài)參數(shù)，完成電機(jī)控制相關(guān)算法的具體實(shí)現(xiàn)，形成連接整車控制端與電機(jī)本體的統(tǒng)一整體。

3 基于AUTOSAR的電機(jī)控制器軟件架構(gòu)設(shè)計

構(gòu)建符合AUTOSAR規(guī)范的軟件架構(gòu)，對于電機(jī)控制器層面，各算法功能應(yīng)確保實(shí)時、準(zhǔn)確實(shí)現(xiàn)，且應(yīng)完成軟件與硬件、軟件與軟件間的解耦；從整車架構(gòu)層面，分層后的電機(jī)控制器軟件應(yīng)與整車具有良好的兼容和互操作性?；谝陨显瓌t，本文從以下三個角度提出新的分層架構(gòu)：(1)對于整車開發(fā)者，用戶控制端和電機(jī)控制器的信息交互應(yīng)當(dāng)僅限于APP軟件，不同電機(jī)控制器廠商和整車架構(gòu)的兼容在于頂層軟件的反復(fù)適配，具體表現(xiàn)在二者間特定接口的一致性配置；(2)對于底層硬件，不論是MCU內(nèi)部資源還是外擴(kuò)電路，都應(yīng)嚴(yán)格保證和上層軟件的完全解耦；(3)對于高實(shí)時性和安全性的功能任務(wù)，標(biāo)準(zhǔn)化的AUTOSAR流程不足以滿足需求時，需要對架構(gòu)中的復(fù)雜驅(qū)動層進(jìn)行特殊設(shè)計。本文基于AUTOSAR的電機(jī)控制器軟件整體架構(gòu)如圖3所示。

圖3 基于AUTOSAR的電機(jī)控制器軟件架構(gòu)圖

3.1 控制器硬件層和基礎(chǔ)軟件層的各分層功能概述

MCU及硬件層在電機(jī)控制器中是MCU和外接電路的總體呈現(xiàn)，主要包括MCU、ADC采樣電路、溫度采樣電路、旋變解碼電路、通信驅(qū)動電路、傳感器以及功率電路等硬件。其中與轉(zhuǎn)速、位置、溫度等相關(guān)的硬件接口直接與電機(jī)連接，電機(jī)控制器與整車進(jìn)行數(shù)據(jù)交互的部分通訊接口與整車控制器相連。

BSW主要包括四個部分，呈現(xiàn)出自下而上的三層架構(gòu)以及一個獨(dú)立的復(fù)雜驅(qū)動層。MCU抽象層作為最底層，包含了PWM、ADC、旋變等I/O驅(qū)動，SPI、CAN/CANFD、FLEXRAY等通信驅(qū)動，F(xiàn)LASH、RAM、ROM等存儲器驅(qū)動，以及定時器、Watchdog等MCU驅(qū)動，使系統(tǒng)軟件與具體MCU型號無關(guān)。

ECU抽象層為不同的總線通信以及不同的內(nèi)存設(shè)備等分別提供統(tǒng)一的訪問機(jī)制，使上層軟件與硬件設(shè)計無關(guān)，不用考慮軟件所需的硬件資源由MCU或者外擴(kuò)電路提供，從而實(shí)現(xiàn)軟件與硬件的完全解耦。

服務(wù)層作為BSW內(nèi)部的最高層，可以為APP軟件提供標(biāo)準(zhǔn)化的基本服務(wù)，如存儲器服務(wù)、通信服務(wù)、診斷服務(wù)等，具有一定的用戶可配置性。存儲器服務(wù)模塊承擔(dān)著基礎(chǔ)軟件服務(wù)層中的內(nèi)存服務(wù)，其本質(zhì)為非易失性存儲器(Non-Volatile Random Access Memory, 以下簡稱NVRAM)，與具體的ECU無關(guān)，具有高度可配置性，可以完成數(shù)據(jù)的修改、檢查、校驗、存儲等功能，具有和APP軟件通信交互的能力。在電機(jī)控制器中其主要存儲電機(jī)標(biāo)定數(shù)表與故障信息庫。診斷服務(wù)主要用于故障讀取、報告和錯誤記錄。該過程主要由診斷事件管理器(Diagnostic Event Manager, 以下簡稱DEM)、診斷通信管理器(Diagnostic Communication Manager, 以下簡稱DCM)、函數(shù)禁止管理器(Function Inhibition Module, 以下簡稱FIM)具體實(shí)現(xiàn)，DEM和APP的故障診斷算法進(jìn)行交互，報告是否有故障發(fā)生；FIM根據(jù)報告的事件狀態(tài)，使能或禁止APP軟件組件內(nèi)部的功能實(shí)體；DCM接收故障診斷請求，并可以完成對基礎(chǔ)軟件的調(diào)用或?qū)⑿畔鬟f至整車控制器進(jìn)行故障處理。同時當(dāng)診斷出故障以后DEM還可使用存儲服務(wù)接口來實(shí)現(xiàn)故障信息儲存，將NVRAM中積累的診斷信息庫通過通信服務(wù)上傳至整車控制器，能夠結(jié)合大數(shù)據(jù)進(jìn)行智能算法的開發(fā)等。

復(fù)雜驅(qū)動層一般用于處理具有高實(shí)時性和復(fù)雜性要求的任務(wù)，可以使頂層軟件直接與底層硬件進(jìn)行交互，實(shí)現(xiàn)特殊功能。在電機(jī)運(yùn)行過程中，過流過壓保護(hù)需要具有快速實(shí)時的反應(yīng)性，復(fù)雜驅(qū)動層能夠?qū)τ布z測電路的報警信號進(jìn)行抽象，并通過邏輯判斷迅速做出反應(yīng)。此外，在電機(jī)控制中，轉(zhuǎn)子位置的獲取通常有較高的實(shí)時性要求且較為復(fù)雜，如增量編碼器解算位置以及英飛凌Tricore系列的MCU具有的DSADC軟解碼位置外設(shè)，可以放在復(fù)雜驅(qū)動層實(shí)現(xiàn)進(jìn)行電機(jī)位置的軟解碼。由于復(fù)雜驅(qū)動層直接連接著底層硬件，不可避免地會產(chǎn)生耦合致使該模塊不具備可移植性，因此本文將該層內(nèi)部劃分為ECU驅(qū)動抽象層和算法實(shí)現(xiàn)層，如圖4所示，前者可直接參與硬件的配置，不具有通用的可移植性，后者與具體的硬件資源無關(guān)，如邏輯判斷算法、轉(zhuǎn)子位置信號解算算法等。

圖4 復(fù)雜驅(qū)動層內(nèi)分層結(jié)構(gòu)

3.2 APP軟件分層設(shè)計

前文提到，電機(jī)控制器功能模塊逐漸趨于復(fù)雜化、多樣化、智能化，AUTOSAR應(yīng)用層的各軟件組件雖以模塊化進(jìn)行劃分，當(dāng)其數(shù)量增多、實(shí)現(xiàn)的功能分布在多層面、多角度且較為繁雜時，軟件間的交互和位置關(guān)系若不進(jìn)行額外設(shè)計，可復(fù)用性以及系統(tǒng)效率將會降低。本文考慮對APP內(nèi)各軟件組件進(jìn)行再分層設(shè)計，按照各個模塊的功能特性、優(yōu)先等級，將其劃分為數(shù)據(jù)解算層、控制算法層、狀態(tài)監(jiān)測層及整車控制層，如圖3所示。層與層之間僅涉及數(shù)據(jù)交換及指令調(diào)用接口，無其他耦合存在。

數(shù)據(jù)解算層除了包括基本的傳感器/執(zhí)行器軟件組件外，還用于實(shí)現(xiàn)Clarke、Park、iPark、SVPWM等計算算法軟件組件，其共同特點(diǎn)有以下三點(diǎn)：(1)算法流程固定，具有完全的可移植性；(2)在電機(jī)矢量控制中，開關(guān)頻率一致，方便系統(tǒng)進(jìn)行統(tǒng)一映射處理；(3)在目前主流的多核架構(gòu)下，可以有針對性地進(jìn)行任務(wù)分配，如統(tǒng)一分配給數(shù)據(jù)計算核或異構(gòu)多核架構(gòu)中計算能力更強(qiáng)的主核，提高系統(tǒng)整體運(yùn)行效率。

控制算法層主要包括電機(jī)矢量控制和直接轉(zhuǎn)矩控制等。以磁場定向控制(FOC)為例，選擇MTPA或者轉(zhuǎn)速模式不會對數(shù)據(jù)解算層中的算法流程或系統(tǒng)對其的任務(wù)調(diào)度安排產(chǎn)生影響，即數(shù)據(jù)解算與電機(jī)在何種控制策略下運(yùn)行無關(guān)，兩層之間只需定時進(jìn)行數(shù)據(jù)交互而無其他耦合，故設(shè)計控制算法層僅需考慮控制策略的切換和選擇。同時該層需留出與整車控制進(jìn)行信息交互的接口，以獲取用戶對于工作模式的需求。

狀態(tài)監(jiān)測層承擔(dān)電機(jī)的故障診斷、過壓/過流/過溫保護(hù)等功能，由文獻(xiàn)[19-21]，電機(jī)各類故障診斷方式共性點(diǎn)在于對故障特征量進(jìn)行提取和計算。結(jié)合上文對BSW診斷服務(wù)模塊的分析，電機(jī)故障診斷流程可以按照圖5形式進(jìn)行。當(dāng)APP的診斷算法檢測到故障發(fā)生時，將通知DEM模塊進(jìn)行處理，DEM確認(rèn)故障發(fā)生時調(diào)用NVRAM Manager對信息進(jìn)行儲存，還可以依據(jù)存儲器中已有的故障信息庫進(jìn)行核驗，確認(rèn)診斷結(jié)果的準(zhǔn)確性。同時，存儲的數(shù)據(jù)庫可以批量向云端發(fā)送，為數(shù)字孿生、預(yù)測診斷等智能算法的實(shí)現(xiàn)提供架構(gòu)支持；此外，DEM調(diào)用FIM觸發(fā)軟件保護(hù)，當(dāng)故障發(fā)生時按需求及時禁止應(yīng)用層軟件控制算法實(shí)現(xiàn)停機(jī)；最后，故障信息通訊由DCM模塊完成，當(dāng)其接收故障診斷請求時，一方面可以向下層通信至MCU處觸發(fā)硬件保護(hù)，如閉鎖PWM等；另一方面可以通信至上位機(jī)，由用戶對故障進(jìn)行處理。過壓/過流/過溫保護(hù)則是將BSW傳遞上來的電壓、電流與溫度等數(shù)據(jù)與系統(tǒng)設(shè)計的安全閾值進(jìn)行比較，當(dāng)任意一項指標(biāo)超出安全閾值時，該保護(hù)機(jī)制將清除SVPWM計算模塊的使能信號，在APP切斷開關(guān)信號的產(chǎn)生，同時向上層整車控制器報告相應(yīng)的監(jiān)測結(jié)果。

圖5 電機(jī)故障診斷流程

整車控制層用于完成電機(jī)控制器和整車開發(fā)控制端的信息交互，通過特定的接口設(shè)計，一方面獲取整車端對控制算法層中電機(jī)工作狀態(tài)、工作模式、旋轉(zhuǎn)方向以及目標(biāo)轉(zhuǎn)矩與轉(zhuǎn)速的設(shè)定要求；另一方面將狀態(tài)監(jiān)測層的電機(jī)運(yùn)行狀態(tài)、控制器運(yùn)行狀態(tài)以及重要狀態(tài)參數(shù)反饋至用戶界面，進(jìn)行實(shí)時監(jiān)控。該層在抽象意義上屬于整體架構(gòu)的最高層，在具體實(shí)現(xiàn)層面依托于通訊及相關(guān)驅(qū)動實(shí)現(xiàn)。

4 實(shí)例分析與驗證

結(jié)合前面分析，本文選取了電機(jī)FOC算法以及電機(jī)過流保護(hù)、匝間短路故障診斷三個實(shí)例，以軟件流程圖和輔助程序代碼的形式對分層架構(gòu)下的系統(tǒng)運(yùn)行流程進(jìn)行說明，并通過TMS320F28377D DSP實(shí)現(xiàn)該AUTOSAR軟件架構(gòu)，利用如圖6所示的實(shí)驗平臺對本文的架構(gòu)思想和功能進(jìn)行分析和驗證。

圖6 實(shí)驗平臺實(shí)物圖

4.1 FOC算法

FOC算法的軟件流程圖如圖7所示。由圖7可見，將查表尋數(shù)等行為在BSW中的存儲器服務(wù)中配置完成，上層軟件則只需要發(fā)出查表指令，當(dāng)?shù)讓佑布M(jìn)行更換時，只需更改與硬件交互的BSW中NVRAM中存儲的標(biāo)定關(guān)系脈譜圖，而保證APP軟件不受干擾，從而具有完整的可移植性，實(shí)現(xiàn)軟件與硬件之間的完全解耦。其次，將數(shù)據(jù)解算和控制算法分別置于APP內(nèi)的不同層次，數(shù)據(jù)解算層中的計算算法僅需按照開關(guān)頻率周期性的進(jìn)行執(zhí)行，無需知曉當(dāng)前電機(jī)處于何種控制策略之下，無需人工干預(yù)，它和控制算法層僅涉及數(shù)據(jù)的周期性交互，由圖7中iPark變換程序?qū)嵗梢钥吹?，兩層間的數(shù)據(jù)傳輸由特定的RTE接口函數(shù)進(jìn)行管理，如圖7中框選部分，該函數(shù)僅服務(wù)于讀取特定電壓信號而無其他作用。由此可實(shí)現(xiàn)APP軟件內(nèi)部的層與層間解耦以及數(shù)據(jù)解算層的打包任務(wù)調(diào)度和完全可移植性。而對于控制算法層，由于具體的控制策略需要上位機(jī)給定，故在該層留出一個與整車控制器交互的接口，用于指令信息的獲取，同時對該接口進(jìn)行明確定義管理，這樣從整車開發(fā)的角度，當(dāng)具體的電機(jī)控制器進(jìn)行更換時，開發(fā)者只需重復(fù)進(jìn)行新的電機(jī)控制器和已有整車接口的適配工作，無需對整體架構(gòu)進(jìn)行更改。

圖7 FOC算法軟件流程圖

對FOC控制的轉(zhuǎn)速與轉(zhuǎn)矩模式進(jìn)行相關(guān)實(shí)驗驗證。圖8為電機(jī)運(yùn)行于FOC轉(zhuǎn)速模式下，電機(jī)轉(zhuǎn)速由200 r/min變化為2 000 r/min的實(shí)驗結(jié)果。圖9為電機(jī)運(yùn)行于FOC轉(zhuǎn)矩模式下，電機(jī)運(yùn)行轉(zhuǎn)速為1 000 r/min，轉(zhuǎn)矩由0變化為10 N·m的實(shí)驗結(jié)果。

圖8 轉(zhuǎn)速模式下的轉(zhuǎn)速、電流波形

圖9 轉(zhuǎn)矩模式下的電流、轉(zhuǎn)速波形

在電機(jī)運(yùn)行過程中，任取兩個控制周期，可觀察到電機(jī)在FOC模式下基于AUTOSAR架構(gòu)的軟件運(yùn)行流程。圖10分別為BSW及硬件層、APP數(shù)據(jù)解算、APP控制算法的運(yùn)行狀態(tài)圖，標(biāo)志位置“1”代表程序正在該層內(nèi)執(zhí)行，置“0”時表示該層處于靜默狀態(tài)。與圖7的軟件算法流程圖相對應(yīng)，實(shí)驗結(jié)果與理論設(shè)計保持一致，體現(xiàn)出分層運(yùn)行與層間解耦特點(diǎn)。

圖10 FOC控制下軟件架構(gòu)分層運(yùn)行狀態(tài)圖

4.2 電機(jī)過流保護(hù)

電機(jī)過流保護(hù)的軟件流程圖如圖11所示，電流電壓經(jīng)過電流電壓傳感器采集之后，同時進(jìn)行ADC采樣以及硬件過流檢測。其中硬件過流檢測電路判斷電流是否處在所設(shè)計的安全范圍內(nèi)，當(dāng)發(fā)生過流情況時，硬件檢測電路將產(chǎn)生相應(yīng)的電平報警信號。任意一相報警信號都將使PWM驅(qū)動的使能信號失效，阻止開關(guān)信號的產(chǎn)生。與此同時，電流采集信號經(jīng)過ADC采樣電路轉(zhuǎn)化為數(shù)字量后，在過流保護(hù)程序中進(jìn)行閾值判斷，當(dāng)發(fā)生過流情況時，產(chǎn)生相應(yīng)的數(shù)字報警信號。該數(shù)字報警信號將使SVPWM模塊的使能信號失效，直接在軟件層級屏蔽開關(guān)控制信號。綜上，當(dāng)發(fā)生過流情況時，硬件層級保護(hù)能夠快速直接切斷開關(guān)信號，而軟件保護(hù)則從源頭上阻止開關(guān)控制信號的產(chǎn)生。軟硬件結(jié)合的雙重保護(hù)機(jī)制能夠最大程度保護(hù)電機(jī)及控制器的安全。將硬件保護(hù)邏輯設(shè)置在復(fù)雜驅(qū)動層，使其能夠直接與硬件電路進(jìn)行交互，當(dāng)過流情況發(fā)生時，能夠?qū)崟r快速地作用于I/O驅(qū)動，使PWM驅(qū)動使能失效，充分利用復(fù)雜驅(qū)動層的快速實(shí)時反應(yīng)，最大程度減小過流對電機(jī)與控制器的影響。此外，當(dāng)硬件電路發(fā)生改變時，開發(fā)者只需對接口數(shù)據(jù)范圍進(jìn)行適配，無需對整體架構(gòu)進(jìn)行更改。

圖11 電機(jī)過流保護(hù)流程圖

4.3 匝間短路故障診斷

匝間短路故障診斷的原理如圖12所示[19]，當(dāng)電機(jī)在線運(yùn)行時，通過提取α、β軸的反電動勢，經(jīng)過濾波、變換處理計算出故障特征量的大小，當(dāng)其超出設(shè)定閾值時即發(fā)出故障信號。

圖12 匝間短路故障診斷原理

診斷的軟件流程圖如圖13所示，其充分調(diào)用了BSW的模塊化服務(wù)資源，和APP算法進(jìn)行合理配合，將診斷分層次協(xié)調(diào)完成。電機(jī)起動運(yùn)行后，電流、位置等信號在BSW完成標(biāo)定轉(zhuǎn)換后將上傳至APP數(shù)據(jù)解算層，通過計算得到α、β軸的反電動勢，將其傳輸至故障診斷層，進(jìn)行匝間短路濾波、故障特征量的算法計算和執(zhí)行。一旦發(fā)生故障，一方面該算法進(jìn)行二次校核，另一方面將信息傳遞給BSW的DEM故障處理模塊，在BSW中進(jìn)行故障信息存儲、觸發(fā)軟件和硬件保護(hù)以及將故障信息通過DCM通訊模塊傳至上位機(jī)進(jìn)行人工處理。該流程中，APP數(shù)據(jù)解算同樣只需按照設(shè)定的周期執(zhí)行，并把結(jié)果傳遞至故障診斷算法層，該層次計算由BSW中上傳的軟件使能信號進(jìn)行禁止。故障診斷層中，各診斷算法分別進(jìn)行封裝，需要進(jìn)行某種故障判斷時由上位機(jī)給予使能信號。如圖13中的部分程序?qū)嵗?，該層與數(shù)據(jù)解算層的信息交互由特定RTE接口函數(shù)進(jìn)行管理，不同診斷算法適配于不同接口函數(shù)。匝間短路故障診斷相關(guān)的RTE接口函數(shù)(以α軸為例)，與數(shù)據(jù)解算層相配合來管理α、β軸反電動勢，而無其他聯(lián)系。可見，層與層間處于解耦的狀態(tài)。綜上，當(dāng)?shù)讓佑布l(fā)生更改時，BSW的ECU抽象層已經(jīng)完成了所有接口的統(tǒng)一封裝，而故障診斷流程全部位于ECU抽象層之上，故不會受到硬件更改的影響。

圖13 電機(jī)故障診斷軟件流程圖

在上述FOC實(shí)驗的基礎(chǔ)上，對電機(jī)匝間短路故障診斷進(jìn)行實(shí)驗驗證，實(shí)驗結(jié)果如圖14所示，提取電機(jī)運(yùn)行時α、β軸的反電動勢，在APP狀態(tài)監(jiān)測層中對提取量進(jìn)行處理，得到故障特征量，確認(rèn)診斷出故障發(fā)生時故障標(biāo)志位置1，并將故障信息傳遞至上位機(jī)，上位機(jī)給予降速信號，轉(zhuǎn)速逐漸過渡至某一較低水平后下降至0，實(shí)現(xiàn)安全停車，同時觸發(fā)軟件保護(hù)禁用APP FOC算法,并結(jié)合MCU硬件保護(hù)，閉鎖PWM信號，系統(tǒng)停機(jī)。實(shí)驗流程與結(jié)果和圖13的故障診斷軟件流程圖一致，同時體現(xiàn)出APP狀態(tài)監(jiān)測中故障診斷算法與電機(jī)控制FOC算法并行實(shí)現(xiàn)，二者軟件獨(dú)立進(jìn)行，實(shí)現(xiàn)了架構(gòu)設(shè)計的軟件互相解耦功能。

圖14 電機(jī)匝間短路故障標(biāo)志位、轉(zhuǎn)速、PWM波形圖

綜合以上三個實(shí)例，本文的新架構(gòu)在功能全面性、分層設(shè)計上結(jié)合了AUTOSAR架構(gòu)及電機(jī)控制器的特點(diǎn)，實(shí)現(xiàn)軟件與硬件、軟件與軟件、層與層之間的高度解耦，利于推動各層、各模塊開發(fā)獨(dú)立。此外，不論從上層的整車控制端，還是下層的底層硬件角度，本分層架構(gòu)均具有良好可移植性。

5 結(jié) 語

基于AUTOSAR的電機(jī)控制器軟件架構(gòu)為電機(jī)智能控制的實(shí)現(xiàn)提供了基本的架構(gòu)支持，具有廣闊前景。本文對電機(jī)控制器各部分功能及軟硬件支持進(jìn)行了具體描述，結(jié)合AUTOSAR架構(gòu)的特點(diǎn)，提出明確的分層思想和原則，建立了基于AUTOSAR的電機(jī)控制器軟件架構(gòu)。該構(gòu)架提升了軟件的可復(fù)用性、便于控制更新硬件以及整車更換供應(yīng)商，提高開發(fā)及更新速度，降低開發(fā)維護(hù)成本。構(gòu)架分層具有底層軟件及系統(tǒng)、RTE層、上層軟件的三層級開發(fā)能力，包括存儲管理、診斷控制、通訊協(xié)議、標(biāo)定開發(fā)等基本系統(tǒng)功能。構(gòu)架提升了軟件的故障診斷與容錯等功能安全的擴(kuò)展性以及基于網(wǎng)絡(luò)大數(shù)據(jù)的控制策略優(yōu)化和容錯控制的靈活性，方便應(yīng)用功能的集成和轉(zhuǎn)換，以及控制器網(wǎng)絡(luò)的優(yōu)化。