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

0、引言近年來(lái)汽車的電氣化電子化程度不斷提高，控制器和軟件功能數(shù)量急劇增加，硬件平臺(tái)呈現(xiàn)多樣化，導(dǎo)致軟件復(fù)用性低，開發(fā)成本上升。為了解決這些問(wèn)題，2003年由9家汽車行業(yè)的巨頭攜手合作，提出了致力于為汽車工業(yè)開發(fā)的一個(gè)開放的、標(biāo)準(zhǔn)化的軟件架構(gòu)，即汽車開放系統(tǒng)架構(gòu)(AUTomotiveOpenSystemARchitecture，以下簡(jiǎn)稱AUTOSAR)。汽車企業(yè)采用AUTOSAR標(biāo)準(zhǔn)架構(gòu)定義控制軟件已經(jīng)是主要趨勢(shì)。許多中國(guó)廠商也成為AUTOSAR聯(lián)盟成員。目前，AUTOSAR標(biāo)準(zhǔn)普遍應(yīng)用于汽車電控系統(tǒng)軟件研發(fā)中，構(gòu)建和設(shè)計(jì)符合AUTOSAR標(biāo)準(zhǔn)的軟件架構(gòu)，學(xué)者們已在汽車多個(gè)控制單元如柴油機(jī)后處理控制、主動(dòng)安全帶控制等展開研究。在電動(dòng)汽車驅(qū)動(dòng)電機(jī)領(lǐng)域，傳統(tǒng)電機(jī)控制器的研究普遍以控制算法為核心，以電機(jī)運(yùn)行狀態(tài)及性能為目標(biāo)，聚焦于電機(jī)本體-控制器的自閉環(huán)系統(tǒng)功能實(shí)現(xiàn)。而對(duì)于控制器與整車的通訊、數(shù)據(jù)以及功能安全的信息交互少有設(shè)計(jì)和研究，且控制器沒有進(jìn)行分層設(shè)計(jì)，軟件與軟件、軟件與硬件耦合嚴(yán)重。隨智能化控制趨勢(shì)的逐步推進(jìn)，電動(dòng)汽車架構(gòu)網(wǎng)絡(luò)逐步發(fā)展成分層、模塊化、少耦合特征，電機(jī)控制器作為整車電子控制單元之一，更應(yīng)考慮在其自閉環(huán)系統(tǒng)之外匹配整車分層架構(gòu)并適應(yīng)系統(tǒng)特性，針對(duì)其與整車的通訊、信息交互和系統(tǒng)容錯(cuò)、功能安全的研究與電機(jī)控制算法的需求和重要性并駕齊驅(qū)。另一方面，電機(jī)控制器內(nèi)部功能模塊同樣不斷增多，軟件越來(lái)越復(fù)雜，開發(fā)商也有多樣選擇，進(jìn)行軟件架構(gòu)設(shè)計(jì)，減少其內(nèi)部軟硬件耦合、提升開發(fā)時(shí)間和成本效能愈發(fā)凸顯意義[7]。國(guó)內(nèi)一些公司正在開發(fā)基于分層設(shè)計(jì)的軟件架構(gòu)。各電機(jī)控制器開發(fā)單位已完全掌握電機(jī)控制策略、保護(hù)策略等上層軟件及核心算法的開發(fā)，但是涉及底層硬件外設(shè)的配置與抽象等的底層軟件開發(fā)目前還處于起步階段。對(duì)于功能安全的考慮還在不斷完善中。國(guó)內(nèi)外對(duì)于AUTOSAR在電機(jī)控制器軟件架構(gòu)上的應(yīng)用仍處于起步的探索階段。對(duì)宏觀架構(gòu)設(shè)計(jì)而言，需進(jìn)一步對(duì)分層設(shè)計(jì)的準(zhǔn)則進(jìn)行明確闡述，電機(jī)控制器架構(gòu)與上端整車控制器、下端底層硬件的解耦目標(biāo)有待明晰；從具體實(shí)現(xiàn)角度來(lái)說(shuō)，需更好地提高對(duì)整體架構(gòu)資源利用率，涵蓋更多電機(jī)控制器的功能，尤其是對(duì)于構(gòu)架的通用性和開發(fā)與整車性能密切相關(guān)的狀態(tài)檢測(cè)與故障診斷等安全功能模塊的考慮還不夠充分。為構(gòu)建更通用的電動(dòng)汽車電機(jī)控制器的軟件架構(gòu)，上層軟件的可移植性、底層硬件與軟件的高度解耦性、整體架構(gòu)的高安全性是本文旨在追求的目標(biāo)。本文將提出一種同時(shí)考慮電機(jī)運(yùn)行控制和功能安全的AUTOSAR電機(jī)控制器軟件架構(gòu)，結(jié)合AUTOSAR的架構(gòu)特點(diǎn)和電機(jī)控制器的功能特性，對(duì)分層思想和原則進(jìn)行明晰，建立完整的構(gòu)架體系，對(duì)各層進(jìn)行功能和原理解釋，并通過(guò)具體實(shí)例進(jìn)行分析說(shuō)明。1、AUTOSAR基本思想與構(gòu)成AUTOSAR架構(gòu)將運(yùn)行在微控制器上的軟件分為三層[15]：完全獨(dú)立于硬件的應(yīng)用層(ApplicationLayer,以下簡(jiǎn)稱APP)和與硬件相關(guān)的基礎(chǔ)軟件層(BasicSoftware,以下簡(jiǎn)稱BSW)，以及在兩者之間設(shè)立的實(shí)時(shí)運(yùn)行環(huán)境層(RuntimeEnvironment,以下簡(jiǎn)稱RTE)，如圖1所示。圖1AUTOSAR標(biāo)準(zhǔn)架構(gòu)圖AUTOSARAPP主要包括三部分：應(yīng)用SWC，接口與可運(yùn)行實(shí)體。APP軟件包含許多獨(dú)立的軟件組件單元，一般分為應(yīng)用軟件組件、傳感器軟件組件以及執(zhí)行器軟件組件三類。軟件組件的內(nèi)部行為通過(guò)一個(gè)或多個(gè)可運(yùn)行實(shí)體實(shí)現(xiàn)，軟件組件之間通過(guò)接口進(jìn)行交互，完成數(shù)據(jù)傳輸和函數(shù)調(diào)用操作。運(yùn)行時(shí)RTE是AUTOSAR中虛擬功能總線(VirtualFunctionBus,以下簡(jiǎn)稱VFB)的具體實(shí)現(xiàn)，基本要求是實(shí)現(xiàn)和管理AUTOSAR的軟件組件間、基礎(chǔ)軟件間、軟件組件與基礎(chǔ)軟件之間的通信，以保證其通信行為正確，并且相互之間不會(huì)干擾，使組件設(shè)計(jì)可以專注于內(nèi)部算法的實(shí)現(xiàn)和優(yōu)化。同時(shí)，RTE作為APP和BSW的銜接，為APP提供標(biāo)準(zhǔn)接口來(lái)調(diào)用底層的資源，使得ECU軟件的開發(fā)與具體的硬件相脫離，上層應(yīng)用策略開發(fā)人員可以更加專注于軟件功能的開發(fā)，而不用糾纏于軟件底層的細(xì)節(jié)，增強(qiáng)系統(tǒng)的安全可靠性。BSW主要分為四部分：微控制單元(MicroControlUnit，以下簡(jiǎn)稱MCU)抽象層、ECU抽象層、服務(wù)層以及復(fù)雜驅(qū)動(dòng)層。BSW負(fù)責(zé)將底層控制器提供的數(shù)據(jù)等信息進(jìn)行抽象傳輸至APP，實(shí)現(xiàn)軟硬件的解耦，同時(shí)為APP提供一些基本服務(wù)。MCU抽象層位于BSW最底層，包含內(nèi)部驅(qū)動(dòng)，可以直接訪問(wèn)MCU及片內(nèi)外設(shè)，可分為MCU驅(qū)動(dòng)、存儲(chǔ)器驅(qū)動(dòng)、通信驅(qū)動(dòng)和I/O驅(qū)動(dòng)四部分，各部分由具體的與MCU硬件相對(duì)應(yīng)的驅(qū)動(dòng)模塊組成。ECU抽象層負(fù)責(zé)提供統(tǒng)一的訪問(wèn)接口，實(shí)現(xiàn)對(duì)通信、內(nèi)存或者I/O的訪問(wèn)，從而無(wú)需考慮這些資源是由MCU提供還是由外部設(shè)備提供，MCU外部設(shè)備的驅(qū)動(dòng)就位于這一層，該層主要由板載設(shè)備抽象、存儲(chǔ)器硬件抽象、通信硬件抽象和I/O硬件抽象四部分組成。服務(wù)層是BSW的最高層，可以實(shí)現(xiàn)與APP軟件的關(guān)聯(lián)，主要分成通信服務(wù)、內(nèi)存服務(wù)、系統(tǒng)服務(wù)。通信服務(wù)通過(guò)通信硬件抽象來(lái)與通信驅(qū)動(dòng)程序進(jìn)行交互，為車輛通信網(wǎng)絡(luò)和車載網(wǎng)絡(luò)的診斷通信提供統(tǒng)一接口；內(nèi)存服務(wù)負(fù)責(zé)非易失性數(shù)據(jù)的管理，以統(tǒng)一的方式為應(yīng)用程序提供數(shù)據(jù)，同時(shí)對(duì)存儲(chǔ)位置和屬性進(jìn)行抽象；系統(tǒng)服務(wù)包含一組模塊和函數(shù)，如實(shí)時(shí)操作系統(tǒng)(定時(shí)器服務(wù))、錯(cuò)誤管理等，這些資源可以被所有應(yīng)用層軟件調(diào)用。復(fù)雜驅(qū)動(dòng)層作為BSW中由用戶自主開發(fā)的模塊，主要針對(duì)AUTOSAR不支持或者未標(biāo)準(zhǔn)化的硬件資源，實(shí)現(xiàn)處理復(fù)雜傳感器及執(zhí)行器的特定功能和時(shí)間要求。該層可以通過(guò)提供AUTOSAR模塊可配置的接口與分層架構(gòu)的其他模塊進(jìn)行互相訪問(wèn)。2、電機(jī)控制器各部分功能描述及軟硬件支持電機(jī)控制系統(tǒng)主要執(zhí)行總線傳輸過(guò)來(lái)的整車轉(zhuǎn)矩、轉(zhuǎn)速和方向等控制命令，通過(guò)讀取位置和電流電壓傳感器，獲得電機(jī)的狀態(tài)，經(jīng)過(guò)算法計(jì)算出電機(jī)逆變器的PWM開關(guān)控制信號(hào)，通過(guò)控制電機(jī)的電流和電壓實(shí)現(xiàn)電機(jī)的運(yùn)行狀態(tài)控制。同時(shí)，為了提高系統(tǒng)的安全可靠性，控制器需要通過(guò)傳感器信息和網(wǎng)絡(luò)數(shù)據(jù)監(jiān)測(cè)電機(jī)系統(tǒng)的狀態(tài)，進(jìn)行故障診斷和容錯(cuò)以及保護(hù)等控制。軟件主要具有數(shù)據(jù)獲取、數(shù)據(jù)解算、控制算法、狀態(tài)監(jiān)測(cè)、數(shù)據(jù)存儲(chǔ)以及通信服務(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ù)解算主要是對(duì)獲取的電機(jī)數(shù)據(jù)進(jìn)行Clarke變換、Park變換等處理，為控制算法提供直接數(shù)據(jù)支持。而控制算法由來(lái)自整車控制器的指令進(jìn)行選擇，常見的控制策略包括涵蓋矢量控制、直接轉(zhuǎn)矩控制等的轉(zhuǎn)速、轉(zhuǎn)矩控制模式。根據(jù)不同的控制算法輸出，再通過(guò)選擇電流閉環(huán)、iPark變換、SVPWM等數(shù)據(jù)解算模塊產(chǎn)生控制信號(hào)，并依托驅(qū)動(dòng)電路的硬件支持，最終產(chǎn)生開關(guān)信號(hào)。狀態(tài)檢測(cè)模塊⑤則包括自檢、過(guò)流、過(guò)壓、過(guò)溫等保護(hù)以及基于大數(shù)據(jù)分析、數(shù)字孿生技術(shù)等工況識(shí)別、故障診斷與壽命預(yù)測(cè)等。通過(guò)對(duì)獲取的原始電機(jī)狀態(tài)參數(shù)的判斷，確定是否發(fā)生過(guò)流過(guò)壓過(guò)溫等現(xiàn)象，若有上述現(xiàn)象發(fā)生，將產(chǎn)生相應(yīng)的報(bào)警信號(hào)，并清除PWM軟件使能，阻止SVPWM模塊產(chǎn)生開關(guān)控制信號(hào)，終止上述現(xiàn)象對(duì)逆變電路及電機(jī)的損害。而工況識(shí)別及故障診斷與壽命預(yù)測(cè)則是利用電機(jī)運(yùn)行的狀態(tài)參數(shù)進(jìn)行更深層次的計(jì)算對(duì)比分析，并輸出相應(yīng)的壽命預(yù)測(cè)值及故障特征量，同時(shí)根據(jù)識(shí)別的工況及時(shí)調(diào)整控制策略，以達(dá)到最優(yōu)的燃油經(jīng)濟(jì)性[17]。數(shù)據(jù)存儲(chǔ)模塊④主要存儲(chǔ)電機(jī)標(biāo)定數(shù)表以及故障信息庫(kù)數(shù)據(jù)。其中電機(jī)標(biāo)定數(shù)表主要是為控制算法如最大轉(zhuǎn)矩電流比(MTPA)控制提供數(shù)據(jù)，根據(jù)整車控制器下達(dá)不同的目標(biāo)轉(zhuǎn)矩反饋給控制算法相應(yīng)的交直軸電流，達(dá)到電機(jī)控制器的MTPA控制。而故障信息庫(kù)則是將狀態(tài)監(jiān)測(cè)中故障診斷模塊反饋的故障特征信息及相關(guān)電機(jī)運(yùn)行參數(shù)進(jìn)行存儲(chǔ)。通訊服務(wù)模塊①則是通過(guò)CAN通信、485通信等通信方式與整車控制器以及其他控制器進(jìn)行交互，將電機(jī)轉(zhuǎn)速、轉(zhuǎn)子溫度、報(bào)警信號(hào)以及故障類型上傳給整車控制器，同時(shí)接收整車控制器下達(dá)的目標(biāo)轉(zhuǎn)速、目標(biāo)轉(zhuǎn)矩以及控制模式選擇等信號(hào)。綜上，電機(jī)控制器通過(guò)通訊服務(wù)模塊與整車控制端進(jìn)行信息交互，依托硬件電路獲取電機(jī)的運(yùn)行狀態(tài)參數(shù)，完成電機(jī)控制相關(guān)算法的具體實(shí)現(xiàn)，形成連接整車控制端與電機(jī)本體的統(tǒng)一整體。3、基于AUTOSAR的電機(jī)控制器軟件架構(gòu)設(shè)計(jì)構(gòu)建符合AUTOSAR規(guī)范的軟件架構(gòu)，對(duì)于電機(jī)控制器層面，各算法功能應(yīng)確保實(shí)時(shí)、準(zhǔn)確實(shí)現(xiàn)，且應(yīng)完成軟件與硬件、軟件與軟件間的解耦；從整車架構(gòu)層面，分層后的電機(jī)控制器軟件應(yīng)與整車具有良好的兼容和互操作性?；谝陨显瓌t，本文從以下三個(gè)角度提出新的分層架構(gòu)：(1)對(duì)于整車開發(fā)者，用戶控制端和電機(jī)控制器的信息交互應(yīng)當(dāng)僅限于APP軟件，不同電機(jī)控制器廠商和整車架構(gòu)的兼容在于頂層軟件的反復(fù)適配，具體表現(xiàn)在二者間特定接口的一致性配置；(2)對(duì)于底層硬件，不論是MCU內(nèi)部資源還是外擴(kuò)電路，都應(yīng)嚴(yán)格保證和上層軟件的完全解耦；(3)對(duì)于高實(shí)時(shí)性和安全性的功能任務(wù)，標(biāo)準(zhǔn)化的AUTOSAR流程不足以滿足需求時(shí)，需要對(duì)架構(gòu)中的復(fù)雜驅(qū)動(dòng)層進(jìn)行特殊設(shè)計(jì)。本文基于AUTOSAR的電機(jī)控制器軟件整體架構(gòu)如圖3所示。圖3基于AUTOSAR的電機(jī)控制器軟件架構(gòu)圖3.1控制器硬件層和基礎(chǔ)軟件層的各分層功能概述MCU及硬件層在電機(jī)控制器中是MCU和外接電路的總體呈現(xiàn)，主要包括MCU、ADC采樣電路、溫度采樣電路、旋變解碼電路、通信驅(qū)動(dòng)電路、傳感器以及功率電路等硬件。其中與轉(zhuǎn)速、位置、溫度等相關(guān)的硬件接口直接與電機(jī)連接，電機(jī)控制器與整車進(jìn)行數(shù)據(jù)交互的部分通訊接口與整車控制器相連。BSW主要包括四個(gè)部分，呈現(xiàn)出自下而上的三層架構(gòu)以及一個(gè)獨(dú)立的復(fù)雜驅(qū)動(dòng)層。MCU抽象層作為最底層，包含了PWM、ADC、旋變等I/O驅(qū)動(dòng)，SPI、CAN/CANFD、FLEXRAY等通信驅(qū)動(dòng)，F(xiàn)LASH、RAM、ROM等存儲(chǔ)器驅(qū)動(dòng)，以及定時(shí)器、Watchdog等MCU驅(qū)動(dòng)，使系統(tǒng)軟件與具體MCU型號(hào)無(wú)關(guān)。ECU抽象層為不同的總線通信以及不同的內(nèi)存設(shè)備等分別提供統(tǒng)一的訪問(wèn)機(jī)制，使上層軟件與硬件設(shè)計(jì)無(wú)關(guān)，不用考慮軟件所需的硬件資源由MCU或者外擴(kuò)電路提供，從而實(shí)現(xiàn)軟件與硬件的完全解耦。服務(wù)層作為BSW內(nèi)部的最高層，可以為APP軟件提供標(biāo)準(zhǔn)化的基本服務(wù)，如存儲(chǔ)器服務(wù)、通信服務(wù)、診斷服務(wù)等，具有一定的用戶可配置性。存儲(chǔ)器服務(wù)模塊承擔(dān)著基礎(chǔ)軟件服務(wù)層中的內(nèi)存服務(wù)，其本質(zhì)為非易失性存儲(chǔ)器(Non-VolatileRandomAccessMemory,以下簡(jiǎn)稱NVRAM)，與具體的ECU無(wú)關(guān)，具有高度可配置性，可以完成數(shù)據(jù)的修改、檢查、校驗(yàn)、存儲(chǔ)等功能，具有和APP軟件通信交互的能力。在電機(jī)控制器中其主要存儲(chǔ)電機(jī)標(biāo)定數(shù)表與故障信息庫(kù)。診斷服務(wù)主要用于故障讀取、報(bào)告和錯(cuò)誤記錄。該過(guò)程主要由診斷事件管理器(DiagnosticEventManager,以下簡(jiǎn)稱DEM)、診斷通信管理器(DiagnosticCommunicationManager,以下簡(jiǎn)稱DCM)、函數(shù)禁止管理器(FunctionInhibitionModule,以下簡(jiǎn)稱FIM)具體實(shí)現(xiàn)，DEM和APP的故障診斷算法進(jìn)行交互，報(bào)告是否有故障發(fā)生；FIM根據(jù)報(bào)告的事件狀態(tài)，使能或禁止APP軟件組件內(nèi)部的功能實(shí)體；DCM接收故障診斷請(qǐng)求，并可以完成對(duì)基礎(chǔ)軟件的調(diào)用或?qū)⑿畔鬟f至整車控制器進(jìn)行故障處理。同時(shí)當(dāng)診斷出故障以后DEM還可使用存儲(chǔ)服務(wù)接口來(lái)實(shí)現(xiàn)故障信息儲(chǔ)存，將NVRAM中積累的診斷信息庫(kù)通過(guò)通信服務(wù)上傳至整車控制器，能夠結(jié)合大數(shù)據(jù)進(jìn)行智能算法的開發(fā)等。復(fù)雜驅(qū)動(dòng)層一般用于處理具有高實(shí)時(shí)性和復(fù)雜性要求的任務(wù)，可以使頂層軟件直接與底層硬件進(jìn)行交互，實(shí)現(xiàn)特殊功能。在電機(jī)運(yùn)行過(guò)程中，過(guò)流過(guò)壓保護(hù)需要具有快速實(shí)時(shí)的反應(yīng)性，復(fù)雜驅(qū)動(dòng)層能夠?qū)τ布z測(cè)電路的報(bào)警信號(hào)進(jìn)行抽象，并通過(guò)邏輯判斷迅速做出反應(yīng)。此外，在電機(jī)控制中，轉(zhuǎn)子位置的獲取通常有較高的實(shí)時(shí)性要求且較為復(fù)雜，如增量編碼器解算位置以及英飛凌Tricore系列的MCU具有的DSADC軟解碼位置外設(shè)，可以放在復(fù)雜驅(qū)動(dòng)層實(shí)現(xiàn)進(jìn)行電機(jī)位置的軟解碼。由于復(fù)雜驅(qū)動(dòng)層直接連接著底層硬件，不可避免地會(huì)產(chǎn)生耦合致使該模塊不具備可移植性，因此本文將該層內(nèi)部劃分為ECU驅(qū)動(dòng)抽象層和算法實(shí)現(xiàn)層，如圖4所示，前者可直接參與硬件的配置，不具有通用的可移植性，后者與具體的硬件資源無(wú)關(guān)，如邏輯判斷算法、轉(zhuǎn)子位置信號(hào)解算算法等。圖4復(fù)雜驅(qū)動(dòng)層內(nèi)分層結(jié)構(gòu)3.2APP軟件分層設(shè)計(jì)前文提到，電機(jī)控制器功能模塊逐漸趨于復(fù)雜化、多樣化、智能化，AUTOSAR應(yīng)用層的各軟件組件雖以模塊化進(jìn)行劃分，當(dāng)其數(shù)量增多、實(shí)現(xiàn)的功能分布在多層面、多角度且較為繁雜時(shí)，軟件間的交互和位置關(guān)系若不進(jìn)行額外設(shè)計(jì)，可復(fù)用性以及系統(tǒng)效率將會(huì)降低。本文考慮對(duì)APP內(nèi)各軟件組件進(jìn)行再分層設(shè)計(jì)，按照各個(gè)模塊的功能特性、優(yōu)先等級(jí)，將其劃分為數(shù)據(jù)解算層、控制算法層、狀態(tài)監(jiān)測(cè)層及整車控制層，如圖3所示。層與層之間僅涉及數(shù)據(jù)交換及指令調(diào)用接口，無(wú)其他耦合存在。數(shù)據(jù)解算層除了包括基本的傳感器/執(zhí)行器軟件組件外，還用于實(shí)現(xiàn)Clarke、Park、iPark、SVPWM等計(jì)算算法軟件組件，其共同特點(diǎn)有以下三點(diǎn)：(1)算法流程固定，具有完全的可移植性；(2)在電機(jī)矢量控制中，開關(guān)頻率一致，方便系統(tǒng)進(jìn)行統(tǒng)一映射處理；(3)在目前主流的多核架構(gòu)下，可以有針對(duì)性地進(jìn)行任務(wù)分配，如統(tǒng)一分配給數(shù)據(jù)計(jì)算核或異構(gòu)多核架構(gòu)中計(jì)算能力更強(qiáng)的主核，提高系統(tǒng)整體運(yùn)行效率?？刂扑惴▽又饕姍C(jī)矢量控制和直接轉(zhuǎn)矩控制等。以磁場(chǎng)定向控制(FOC)為例，選擇MTPA或者轉(zhuǎn)速模式不會(huì)對(duì)數(shù)據(jù)解算層中的算法流程或系統(tǒng)對(duì)其的任務(wù)調(diào)度安排產(chǎn)生影響，即數(shù)據(jù)解算與電機(jī)在何種控制策略下運(yùn)行無(wú)關(guān)，兩層之間只需定時(shí)進(jìn)行數(shù)據(jù)交互而無(wú)其他耦合，故設(shè)計(jì)控制算法層僅需考慮控制策略的切換和選擇。同時(shí)該層需留出與整車控制進(jìn)行信息交互的接口，以獲取用戶對(duì)于工作模式的需求。狀態(tài)監(jiān)測(cè)層承擔(dān)電機(jī)的故障診斷、過(guò)壓/過(guò)流/過(guò)溫保護(hù)等功能，電機(jī)各類故障診斷方式共性點(diǎn)在于對(duì)故障特征量進(jìn)行提取和計(jì)算。結(jié)合上文對(duì)BSW診斷服務(wù)模塊的分析，電機(jī)故障診斷流程可以按照?qǐng)D5形式進(jìn)行。當(dāng)APP的診斷算法檢測(cè)到故障發(fā)生時(shí)，將通知DEM模塊進(jìn)行處理，DEM確認(rèn)故障發(fā)生時(shí)調(diào)用NVRAMManager對(duì)信息進(jìn)行儲(chǔ)存，還可以依據(jù)存儲(chǔ)器中已有的故障信息庫(kù)進(jìn)行核驗(yàn)，確認(rèn)診斷結(jié)果的準(zhǔn)確性。同時(shí)，存儲(chǔ)的數(shù)據(jù)庫(kù)可以批量向云端發(fā)送，為數(shù)字孿生、預(yù)測(cè)診斷等智能算法的實(shí)現(xiàn)提供架構(gòu)支持；此外，DEM調(diào)用FIM觸發(fā)軟件保護(hù)，當(dāng)故障發(fā)生時(shí)按需求及時(shí)禁止應(yīng)用層軟件控制算法實(shí)現(xiàn)停機(jī)；最后，故障信息通訊由DCM模塊完成，當(dāng)其接收故障診斷請(qǐng)求時(shí)，一方面可以向下層通信至MCU處觸發(fā)硬件保護(hù)，如閉鎖PWM等；另一方面可以通信至上位機(jī)，由用戶對(duì)故障進(jìn)行處理。過(guò)壓/過(guò)流/過(guò)溫保護(hù)則是將BSW傳遞上來(lái)的電壓、電流與溫度等數(shù)據(jù)與系統(tǒng)設(shè)計(jì)的安全閾值進(jìn)行比較，當(dāng)任意一項(xiàng)指標(biāo)超出安全閾值時(shí)，該保護(hù)機(jī)制將清除SVPWM計(jì)算模塊的使能信號(hào)，在APP切斷開關(guān)信號(hào)的產(chǎn)生，同時(shí)向上層整車控制器報(bào)告相應(yīng)的監(jiān)測(cè)結(jié)果。圖5電機(jī)故障診斷流程整車控制層用于完成電機(jī)控制器和整車開發(fā)控制端的信息交互，通過(guò)特定的接口設(shè)計(jì)，一方面獲取整車端對(duì)控制算法層中電機(jī)工作狀態(tài)、工作模式、旋轉(zhuǎn)方向以及目標(biāo)轉(zhuǎn)矩與轉(zhuǎn)速的設(shè)定要求；另一方面將狀態(tài)監(jiān)測(cè)層的電機(jī)運(yùn)行狀態(tài)、控制器運(yùn)行狀態(tài)以及重要狀態(tài)參數(shù)反饋至用戶界面，進(jìn)行實(shí)時(shí)監(jiān)控。該層在抽象意義上屬于整體架構(gòu)的最高層，在具體實(shí)現(xiàn)層面依托于通訊及相關(guān)驅(qū)動(dòng)實(shí)現(xiàn)。4、實(shí)例分析與驗(yàn)證結(jié)合前面分析，本文選取了電機(jī)FOC算法以及電機(jī)過(guò)流保護(hù)、匝間短路故障診斷三個(gè)實(shí)例，以軟件流程圖和輔助程序代碼的形式對(duì)分層架構(gòu)下的系統(tǒng)運(yùn)行流程進(jìn)行說(shuō)明，并通過(guò)TMS320F28377DDSP實(shí)現(xiàn)該AUTOSAR軟件架構(gòu)，利用如圖6所示的實(shí)驗(yàn)平臺(tái)對(duì)本文的架構(gòu)思想和功能進(jìn)行分析和驗(yàn)證。圖6實(shí)驗(yàn)平臺(tái)實(shí)物圖4.1FOC算法FOC算法的軟件流程圖如圖7所示。由圖7可見，將查表尋數(shù)等行為在BSW中的存儲(chǔ)器服務(wù)中配置完成，上層軟件則只需要發(fā)出查表指令，當(dāng)?shù)讓佑布M(jìn)行更換時(shí)，只需更改與硬件交互的BSW中NVRAM中存儲(chǔ)的標(biāo)定關(guān)系脈譜圖，而保證APP軟件不受干擾，從而具有完整的可移植性，實(shí)現(xiàn)軟件與硬件之間的完全解耦。其次，將數(shù)據(jù)解算和控制算法分別置于APP內(nèi)的不同層次，數(shù)據(jù)解算層中的計(jì)算算法僅需按照開關(guān)頻率周期性的進(jìn)行執(zhí)行，無(wú)需知曉當(dāng)前電機(jī)處于何種控制策略之下，無(wú)需人工干預(yù)，它和控制算法層僅涉及數(shù)據(jù)的周期性交互，由圖7中iPark變換程序?qū)嵗梢钥吹?，兩層間的數(shù)據(jù)傳輸由特定的RTE接口函數(shù)進(jìn)行管理，如圖7中框選部分，該函數(shù)僅服務(wù)于讀取特定電壓信號(hào)而無(wú)其他作用。由此可實(shí)現(xiàn)APP軟件內(nèi)部的層與層間解耦以及數(shù)據(jù)解算層的打包任務(wù)調(diào)度和完全可移植性。而對(duì)于控制算法層，由于具體的控制策略需要上位機(jī)給定，故在該層留出一個(gè)與整車控制器交互的接口，用于指令信息的獲取，同時(shí)對(duì)該接口進(jìn)行明確定義管理，這樣從整車開發(fā)的角度，當(dāng)具體的電機(jī)控制器進(jìn)行更換時(shí)，開發(fā)者只需重復(fù)進(jìn)行新的電機(jī)控制器和已有整車接口的適配工作，無(wú)需對(duì)整體架構(gòu)進(jìn)行更改。圖7FOC算法軟件流程圖對(duì)FOC控制的轉(zhuǎn)速與轉(zhuǎn)矩模式進(jìn)行相關(guān)實(shí)驗(yàn)驗(yàn)證。圖8為電機(jī)運(yùn)行于FOC轉(zhuǎn)速模式下，電機(jī)轉(zhuǎn)速由200r/min變化為2000r/min的實(shí)驗(yàn)結(jié)果。圖9為電機(jī)運(yùn)行于FOC轉(zhuǎn)矩模式下，電機(jī)運(yùn)行轉(zhuǎn)速為1000r/min，轉(zhuǎn)矩由0變化為10N·m的實(shí)驗(yàn)結(jié)果。圖8轉(zhuǎn)速模式下的轉(zhuǎn)速、電流波形圖9轉(zhuǎn)矩模式下的電流、轉(zhuǎn)速波形在電機(jī)運(yùn)行過(guò)程中，任取兩個(gè)控制周期，可觀察到電機(jī)在FOC模式下基于AUTOSAR架構(gòu)的軟件運(yùn)行流程。圖10分別為BSW及硬件層、APP數(shù)據(jù)解算、APP控制算法的運(yùn)行狀態(tài)圖，標(biāo)志位置“1”代表程序正在該層內(nèi)執(zhí)行，置“0”時(shí)表示該層處于靜默狀態(tài)。與圖7的軟件算法流程圖相對(duì)應(yīng)，實(shí)驗(yàn)結(jié)果與理論設(shè)計(jì)保持一致，體現(xiàn)出分層運(yùn)行與層間解耦特點(diǎn)。圖10FOC控制下軟件架構(gòu)分層運(yùn)行狀態(tài)圖4.2電機(jī)過(guò)流保護(hù)電機(jī)過(guò)流保護(hù)的軟件流程圖如圖11所示，電流電壓經(jīng)過(guò)電流電壓傳感器采集之后，同時(shí)進(jìn)行ADC采樣以及硬件過(guò)流檢測(cè)。其中硬件過(guò)流檢測(cè)電路判斷電流是否處在所設(shè)計(jì)的安全范圍內(nèi)，當(dāng)發(fā)生過(guò)流情況時(shí)，硬件檢測(cè)電路將產(chǎn)生相應(yīng)的電平報(bào)警信號(hào)。任意一相報(bào)警信號(hào)都將使PWM驅(qū)動(dòng)的使能信號(hào)失效，阻止開關(guān)信號(hào)的產(chǎn)生。與此同時(shí)，電流采集信號(hào)經(jīng)過(guò)ADC采樣電路轉(zhuǎn)化為數(shù)字量后，在過(guò)流保護(hù)程序中進(jìn)行閾值判斷，當(dāng)發(fā)生過(guò)流情況時(shí)，產(chǎn)生相應(yīng)的數(shù)字報(bào)警信號(hào)。該數(shù)字報(bào)警信號(hào)將使SVPWM模塊的使能信號(hào)失效，直接在軟件層級(jí)屏蔽開關(guān)控制信號(hào)。綜上，當(dāng)發(fā)生過(guò)流情況時(shí)，硬件層級(jí)保護(hù)能夠快速直接切斷開關(guān)信號(hào)，而軟件保護(hù)則從源頭上阻止開關(guān)控制信號(hào)的產(chǎn)生。軟硬件結(jié)合的雙重保護(hù)機(jī)制能夠最大程度保護(hù)電機(jī)及控制器的安全。將硬件保護(hù)邏輯設(shè)置在復(fù)雜驅(qū)動(dòng)層，使其能夠直接與硬件電路進(jìn)行交互，當(dāng)過(guò)流情況發(fā)生時(shí)，能夠?qū)崟r(shí)快速地作用于I/O驅(qū)動(dòng)，使PWM驅(qū)動(dòng)使能失效，充分利用復(fù)雜驅(qū)動(dòng)層的快速實(shí)時(shí)反應(yīng)，最大程度減小過(guò)流對(duì)電機(jī)與控制器的影響。此外，當(dāng)硬件電路發(fā)生改變時(shí)，開發(fā)者只需對(duì)接口數(shù)據(jù)范圍進(jìn)行適配，無(wú)需對(duì)整體架構(gòu)進(jìn)行更改。圖11電機(jī)過(guò)流保護(hù)流程圖4.3匝間短路故障診斷匝間短路故障診斷的原理如圖12所示[19]，當(dāng)電機(jī)在線運(yùn)行時(shí)，通過(guò)提取α、β軸的反電動(dòng)勢(shì)，經(jīng)過(guò)濾波、變換處理計(jì)算出故障特征量的大小，當(dāng)其超出設(shè)定閾值時(shí)即發(fā)出故障信號(hào)。圖12匝間短路故障診斷原理診斷的軟件流程圖如圖13所示，其充分調(diào)用了BSW的模塊化服務(wù)資源，和APP算法進(jìn)行合理配合，將診斷分層次協(xié)調(diào)完成。電機(jī)起動(dòng)運(yùn)行后，電流、位置等信號(hào)在BSW完成標(biāo)定轉(zhuǎn)換后將上傳至APP數(shù)據(jù)解算層，通過(guò)計(jì)算得到α、β軸的反電動(dòng)勢(shì)，將其傳輸至故障診斷層，進(jìn)行匝間短路濾波、故障特征量的算法計(jì)算和執(zhí)行。一旦發(fā)生故障，一方面該算法進(jìn)行二次校核，另一方面將信息傳遞給BSW的DEM故障處理模塊，在BSW中進(jìn)行故障信息存儲(chǔ)、觸發(fā)軟件和硬件保護(hù)以及將故障信息通過(guò)DCM通訊模塊傳至上位機(jī)進(jìn)行人工處理。該流程中，APP數(shù)據(jù)解算同樣只需按照設(shè)定的周期執(zhí)行，并把結(jié)果傳遞至故障診斷算法層，該層次計(jì)算由BSW中上傳的軟件使能信號(hào)進(jìn)行禁止。故障診斷層中，各診斷算法分別進(jìn)行封裝，需要進(jìn)行某種故障判斷時(shí)由上位機(jī)給予使能信號(hào)。如圖13中的部分程序?qū)嵗荆?/p>