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

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