基于MPC5746R的燃料電池發動機控制器標定系統設計

馬天才 楊柳明 葉川 楊月華

（1.同濟大學，汽車學院，上海 201804；2.同濟大學，新能源汽車工程中心，上海 201804）

主題詞：燃料電池 控制器 標定

1 前言

燃料電池汽車擁有續航里程長、加氫速度快等獨特優勢，與純電動汽車相比，其在性能上更接近傳統的內燃機汽車[1-2]。燃料電池發動機控制器（Fuelcell Control Unit，FCU）作為各輔助系統的控制中樞，需要對散熱風扇、水泵、氫氣減壓閥、排水電磁閥、空壓機等各執行器進行控制，其標定結果直接影響電堆的工作條件。通過使用標定系統，不僅能實時觀察各控制參數對控制效果的影響，也能隨時修改標定參數，從而提高標定效率。因而，對FCU標定系統的研究與設計十分必要。

近年來，國內很多高校基于CAN標定協議（CAN Calibration Protocol，CCP）和通用的測量與標定協議（Universal Measurement and Calibration Protocol，XCP）進行了相關標定系統的開發設計：劉運瀟[3]選取飛思卡爾MC9S12XEQ512作為主芯片，基于CCP手工開發了下位機CCP驅動和CAN驅動，使用LabVIEW設計了上位機標定界面；楊攀[4]選用英飛凌XC2365A作為主芯片，基于CCP，使用CANape作為上位機，并使用Simulink完成了CCP底層驅動的編寫；梁恒[5]采用英飛凌XC2785芯片，基于XCP在Visual Studio平臺上使用C#語言開發了上位機標定程序，完成了標定系統的設計。

本文針對燃料電池發動機高安全性與高實時性的要求，選用32位汽車級芯片——恩智浦MPC5746R，通過MCAL配置生成符合汽車開放系統架構（AUTomotive Open System ARchitecture，AUTOSAR）的底層驅動，結合XCP協議包與CANape上位機，完成標定系統開發，實現了數據實時顯示與在線標定的功能。

2 架構與協議

2.1 AUTOSAR架構

AUTOSAR的核心思想可概括為“統一標準、分散實現、集中配置[6]”，通過建立統一標準使各廠商在一個開放的平臺下工作。不同廠商可采用滿足標準的不同實現方式制作模塊化的軟件，由整車廠將這些模塊整合起來，加入應用層軟件，進行相應配置后，完成軟件開發。如圖1所示，AUTOSAR架構可具體分為3個部分：

圖1 AUTOSAR架構框架

a.應用層。應用層算法以軟件組件的形式進行設計，每個軟件組件都具有標準化的應用程序接口并通過運行時環境層進行通信。

b.運行時環境層（RTE）。RTE提供基礎的通信服務，支持軟件組件間以及其與基礎軟件層間的通信。

c.基礎軟件層（BSW）。BSW被劃分為4個部分：服務層、ECU抽象層、微控制器抽象層（MCAL）和復雜驅動層。服務層將各種基礎軟件功能模塊以服務的形式封裝起來，供應用層調用。ECU抽象層封裝了MCAL和MCU外圍設備的驅動，并將對MCU外圍設備的訪問進行了統一，使上層應用與ECU硬件布局無關。MCAL包含了訪問MCU和內部外設的驅動，使上層軟件獨立于使用的微控制器，以便應用程序的移植。該部分軟件由相應芯片制造商提供。復雜驅動層可以直接訪問MCU，從而實現一些復雜的傳感器和執行器操作。

2.2 XCP

XCP在2003年被提出，它建立在CCP的研究基礎上，其中“X”指的是傳輸層可使用多種通訊方式，如CAN、FlexRay、Ethernet（UDP/IP和TCP/IP）、USB和串口（SPI和SCI）等[7]。XCP消息幀由3個部分組成：XCP幀頭、XCP報文包和XCP幀尾，如圖2所示。

圖2 XCP消息幀結構

其中，XCP幀頭和幀尾根據XCP傳輸層協議不同發生變化，而XCP報文包的格式和內容由XCP協議層定義，固定不變，故XCP協議支持多種傳輸方式。

3 下位機軟件設計

3.1 底層驅動

為實現在線標定功能，下位機需使用軟件地址重定位的方法：標定開始前，將存儲在FLASH中的待標定參數拷貝至RAM中；標定過程中，直接在RAM中進行讀寫；標定結束后，將RAM中的參數寫入FLASH中保存[8-9]。在具體實現方式上，為保證下位機軟件的可移植性、可重用性和功能安全性，本文使用MCAL配置工具，生成符合AUTOSAR架構要求的CAN驅動和FLASH驅動。以FLASH模塊配置為例，其驅動開發過程如下。

3.1.1 FLASH模塊MCAL配置

FLASH模塊的配置內容主要包括FLASH通用設置、FLASH具體配置、FLASH版本信息設置，如圖3所示。

圖3 FLASH模塊配置框架

FLASH的讀、寫函數均通過異步方式實現，即調用讀或寫函數后只是將需要讀寫的FLASH地址、數據緩存區地址、讀寫長度等信息傳遞給底層的FLASH驅動，而并未立即執行相應的讀寫操作。因而需要在MCAL配置時啟用FLASH工作結束的通知函數（Fls_JobEnd-Notif函數），使FLASH在完成相應工作后調用該函數。這是設計FLASH讀、寫任務函數以及狀態轉移的基礎。

本文結合實際的標定需求，考慮到FLASH的大小對刷寫速度的影響，配置了大小為16 KB的FLS_DATA_ARRAY_0_PART_2_M00數據FLASH[10]。

3.1.2 FLASH模塊讀、寫任務函數

前文FLASH模塊MCAL配置過程中，設置了FLASH工作結束通知函數。在該函數中根據當前FLASH的狀態，進行相應的狀態轉移以完成FLASH模塊的讀取任務。在FLASH進行讀任務時，FLASH狀態機被設置為FLASH讀狀態，根據當前的狀態依次執行讀任務函數和驗證函數，在工作結束后完成各狀態的切換，最后到達FLASH最終狀態。狀態設置如圖4所示。寫任務與讀任務類似，不再贅述。

圖4 FLASH讀任務狀態機

3.2 XCP驅動

XCP驅動需要完成對XCP模塊的初始化、協議的解析、XCP報文的打包與解包、DAQ的分配、DAQ的發送、標定數據的下載等功能。

3.2.1 XCP命令處理機

命令處理機的工作流程如圖5所示。XCP命令處理機的主要任務是根據上位機發送CAN幀數據場的第1個字節判斷當前上位機發送的命令類型，并按照協議的要求，解析數據場中其他的命令參數，并作出相應的回復。接收到連接命令時，下位機將如下信息填入數據緩沖區中：當前可用的功能、使用的通信模式、上位機XCP命令的最大字節數、上位機DAQ的最大字節數及當前下位機使用的XCP協議版本和傳輸層版本。

圖5 命令處理機流程

如接收到標定命令，若修改的數據地址屬于FLASH，則使用軟件地址映射的方法，修改其在RAM中存放的值，與上位機斷開連接后再進行FLASH相應扇區的擦寫。

3.2.2 DAQ處理機

DAQ處理機的工作流程如圖6所示。下位機根據上位機的命令先將所有DAQ分配到不同的事件中。根據不同事件的發送周期將滿足要求的DAQ打包發送。該過程中，如遇地址在FLASH區域的情況，則進行軟件地址映射，通過增加偏移量讀取其在RAM中存放的值，避免對FLASH扇區進行讀取操作。在同一事件中所有記錄發送完畢后，DAQ處理機狀態切換為發送成功。

圖6 DAQ處理機流程

4 標定系統測試

4.1 安全訪問功能測試

對標定系統而言，安全性是首先需要保證的。下位機需要識別正在總線上發送消息的上位機是否有權限對本機進行標定，是否有必要向上位機發送DAQ。具體實現過程為：上位機確定需要下位機解鎖的資源后，按XCP的要求發送GET_SEED命令，請求下位機給出所請求資源的SEED值，并通過一定的密鑰算法求出對應的密鑰；上位機使用UNLOCK命令，將密鑰發送給下位機；下位機將密鑰與自身計算出的密鑰進行比較，決定解鎖需要使用的資源或斷開與上位機的連接。CANape中密鑰算法以dll文件的形式導入。下位機通過使用相同的密鑰算法，可以保證上位機正常解鎖標定資源。

4.2 數據采集功能測試

在進行數據采集前，可通過使用Vector ASAP2 Editor工具提取下位機編譯生成的map文件中的變量名和地址信息，生成CANape能讀取的A2L文件。

數據采集測試的結果如圖7所示。被采集的變量滿足如下關系：test7在0～0.7間波動，test8=0.7，test7與test8相加得到test9。在DAQ模式下，這3個變量都分配在同一個事件通道，被同時采集，因而可以保證其對應關系，即test9=test7+test8。在Polling模式下，3個變量數據的上傳周期雖然也被設置為相同的值，但變量并不是同時集中采集的，而是在接收到UPLOAD或SHORT_UPLOAD命令后依次發送給上位機。由于上傳存在先后順序，因而3個變量間的對應關系無法滿足。

圖7 DAQ和Polling測試結果

4.3 在線標定功能測試

為驗證系統的標定功能，設計了應用層算法y=ax+b，其中a、x和b分別與存儲在FLASH中的3個標定量cal3、cal2、cal1的RAM備份相對應。在標定窗口中修改標定量的值，觀察相應的a、x、b、y是否發生變化。測試結果如圖8所示，各變量隨著標定量的變化而變化，說明軟件地址映射功能正常，上位機能通過FLASH地址訪問存儲在下位機RAM中的變量，應用層算法也能通過軟件映射使用存放在RAM中的參數，在線標定功能基本實現。

圖8 在線標定測試結果

5 結束語

本文基于MCAL配置了符合AUTOSAR架構的CAN驅動模塊與FLASH驅動模塊，設計了相關狀態機與接口函數，并開發了XCP驅動的命令處理機和DAQ處理機，完成了MPC5746R芯片的標定系統設計，實現了通信安全訪問、數據在線標定和DAQ上傳數據的功能。