一種基于AUTOSAR的電機控制器軟件架構設計

崔淑梅，張玉琦，杜博超，姚 凱，程 遠

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

0 引 言

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

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

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

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

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

1 AUTOSAR基本思想與構成

AUTOSAR架構將運行在微控制器上的軟件分為三層[15]：完全獨立于硬件的應用層(Application Layer, 以下簡稱APP)和與硬件相關的基礎軟件層(Basic Software, 以下簡稱BSW)，以及在兩者之間設立的實時運行環境層(Runtime Environment, 以下簡稱RTE)，如圖1所示。

圖1 AUTOSAR標準架構圖

AUTOSAR APP主要包括三部分：應用SWC，接口與可運行實體。APP軟件包含許多獨立的軟件組件單元，一般分為應用軟件組件、傳感器軟件組件以及執行器軟件組件三類。軟件組件的內部行為通過一個或多個可運行實體實現，軟件組件之間通過接口進行交互，完成數據傳輸和函數調用操作。

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

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

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

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

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

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

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

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

數據存儲模塊④主要存儲電機標定數表以及故障信息庫數據。其中電機標定數表主要是為控制算法如最大轉矩電流比(MTPA)控制提供數據，根據整車控制器下達不同的目標轉矩反饋給控制算法相應的交直軸電流，達到電機控制器的MTPA控制。而故障信息庫則是將狀態監測中故障診斷模塊反饋的故障特征信息及相關電機運行參數進行存儲。

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

綜上，電機控制器通過通訊服務模塊與整車控制端進行信息交互，依托硬件電路獲取電機的運行狀態參數，完成電機控制相關算法的具體實現，形成連接整車控制端與電機本體的統一整體。

3 基于AUTOSAR的電機控制器軟件架構設計

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

圖3 基于AUTOSAR的電機控制器軟件架構圖

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

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

BSW主要包括四個部分，呈現出自下而上的三層架構以及一個獨立的復雜驅動層。MCU抽象層作為最底層，包含了PWM、ADC、旋變等I/O驅動，SPI、CAN/CANFD、FLEXRAY等通信驅動，FLASH、RAM、ROM等存儲器驅動，以及定時器、Watchdog等MCU驅動，使系統軟件與具體MCU型號無關。

ECU抽象層為不同的總線通信以及不同的內存設備等分別提供統一的訪問機制，使上層軟件與硬件設計無關，不用考慮軟件所需的硬件資源由MCU或者外擴電路提供，從而實現軟件與硬件的完全解耦。

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

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

圖4 復雜驅動層內分層結構

3.2 APP軟件分層設計

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

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

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

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

圖5 電機故障診斷流程

整車控制層用于完成電機控制器和整車開發控制端的信息交互，通過特定的接口設計，一方面獲取整車端對控制算法層中電機工作狀態、工作模式、旋轉方向以及目標轉矩與轉速的設定要求；另一方面將狀態監測層的電機運行狀態、控制器運行狀態以及重要狀態參數反饋至用戶界面，進行實時監控。該層在抽象意義上屬于整體架構的最高層，在具體實現層面依托于通訊及相關驅動實現。

4 實例分析與驗證

結合前面分析，本文選取了電機FOC算法以及電機過流保護、匝間短路故障診斷三個實例，以軟件流程圖和輔助程序代碼的形式對分層架構下的系統運行流程進行說明，并通過TMS320F28377D DSP實現該AUTOSAR軟件架構，利用如圖6所示的實驗平臺對本文的架構思想和功能進行分析和驗證。

圖6 實驗平臺實物圖

4.1 FOC算法

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

圖7 FOC算法軟件流程圖

對FOC控制的轉速與轉矩模式進行相關實驗驗證。圖8為電機運行于FOC轉速模式下，電機轉速由200 r/min變化為2 000 r/min的實驗結果。圖9為電機運行于FOC轉矩模式下，電機運行轉速為1 000 r/min，轉矩由0變化為10 N·m的實驗結果。

圖8 轉速模式下的轉速、電流波形

圖9 轉矩模式下的電流、轉速波形

在電機運行過程中，任取兩個控制周期，可觀察到電機在FOC模式下基于AUTOSAR架構的軟件運行流程。圖10分別為BSW及硬件層、APP數據解算、APP控制算法的運行狀態圖，標志位置“1”代表程序正在該層內執行，置“0”時表示該層處于靜默狀態。與圖7的軟件算法流程圖相對應，實驗結果與理論設計保持一致，體現出分層運行與層間解耦特點。

圖10 FOC控制下軟件架構分層運行狀態圖

4.2 電機過流保護

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

圖11 電機過流保護流程圖

4.3 匝間短路故障診斷

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

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

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

圖13 電機故障診斷軟件流程圖

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

圖14 電機匝間短路故障標志位、轉速、PWM波形圖

綜合以上三個實例，本文的新架構在功能全面性、分層設計上結合了AUTOSAR架構及電機控制器的特點，實現軟件與硬件、軟件與軟件、層與層之間的高度解耦，利于推動各層、各模塊開發獨立。此外，不論從上層的整車控制端，還是下層的底層硬件角度，本分層架構均具有良好可移植性。

5 結 語

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