0 引言

汽車技術的飛速發展使得汽車電子控制單元（Electronic Control Unit，ECU）中包含的控制參數大量增加，標定工作復雜度越來越高。在ECU開發過程中，控制參數的標定工作直接影響整車性能的優劣。面對日趨多樣的ECU和通信總線類型，開發一種支持多總線的、通用靈活的標定系統，具有非常高的實用價值[1]。目前，CAN總線作為一種可靠的汽車總線已經廣泛應用于高檔汽車，因而多數標定系統都是基于CCP（CAN Calibration Protocol）協議開發的，具有一定的通用性[2]。但隨著更為先進的FlexRay通信總線迅速發展，開發出一種既支持當下主流的CAN總線，又兼容代表汽車總線趨勢的FlexRay總線的標定系統，無疑具有很高的技術應用價值。

本文基于XCP協議設計了一套ECU標定系統，充分利用了XCP協議物理傳輸層與協議層相互獨立的特性，基于同一協議層分別實現了對CAN總線和FlexRay總線的支持，大大提高了標定系統的總線兼容性與可擴展性。

1 標定系統總體方案設計

XCP協議由自動化及測量系統標準協會（Association for Standardization of Automation and Measuring system，ASAM）提出，是對原有CCP2.1協議的繼承和升級，力求使用最小的系統和硬件資源開銷實現高效通信[3]。該協議分別定義了協議層、傳輸層和接口層，其最突出的特點就是協議層獨立于傳輸層。對于不同類型的通信總線，只需要將XCP報文（XCP Message）的報文頭和報文尾填上對應信息，而中間部分的XCP數據包（XCP Packet）由協議層定義，完全不受影響。因此XCP標定協議能夠極好地適應總線多樣化對標定系統通用性提出的要求。目前，ASAM已經在標準中定義的傳輸層包括：XCP-on-CAN、XCP-on-Ethernet（TCP/IP、UDP/IP）、XCP-on-SXI（SPI、SCI）、XCP-on-USB和XCP-on-FlexRay[3]。根據后續的實際需求，也考慮進一步定義XCP-on-LIN、XCP-on-K-Line和XCP-on-MOST。

圖1是標定系統總體架構設計方案。整個標定系統框架遵循ASAM-MCD標準（原ASAP標準）搭建，包括運行于PC端的上位機標定軟件、負責上位機和下位機之間通信的通信控制單元和下位機ECU。ECU端采用Freescale公司的MC9S12XF512芯片。上位機集成了方便用戶進行測量和標定的圖形界面以及XCP命令解析模塊，用戶請求經由上位機XCP協議模塊打包，通過通信控制單元發送至下位機ECU通信接口，再由集成在ECU中的XCP驅動模塊解析后調用對應命令處理模塊進行操作，將處理結果打包并通過通信控制單元發送回上位機。根據通信介質的不同，需要對XCP協議幀的幀頭和幀尾進行對應的信息填充。本文設計的標定系統同時支持當下主流的CAN通信總線和代表未來汽車總線發展趨勢的FlexRay總線。

2 XCP協議驅動程序的實現

XCP協議以主從方式工作，并使用命令傳輸對象（Command Transfer Object，CTO）和數據傳輸對象（Data Transfer Object，DTO）兩種數據包來區分主從節點間的通信，如圖2所示。

XCP協議規定了3種通信模式，分別是標準通信模式(Standard Mode)、塊傳輸通信模式(Block Transfer Mode)和交錯傳輸通信模式(Interleaved Mode)。本文設計的標定系統適用于CAN總線和FlexRay總線，采用標準通信模式，即在主機主動發起會話建立連接之后，對于主機發送的每一條命令，從機都必須進行響應處理，如出錯則返回錯誤報告信息。在沒有接收到從機對上一條命令的應答之前，主機不會發送新的命令[4]。

2.1 下位機端XCP協議驅動程序的實現

XCP協議作為對CCP協議的升級，其所具有的一個重要新功能是對冷啟動測量的支持，即所謂的RESUME模式[3]。集成了XCP協議驅動的下位機啟動后其狀態機模型如圖3所示。

從節點設備啟動并完成初始化后，會立刻檢測ECU的非易失存儲介質中是否有已配置好的DAQ list供RESUME模式使用，如果有，則進入RESUME模式，按配置列表周期性向上位機發送數據；如果沒有相關配置文件，則進入DICONNECTED模式。在RESUME模式和DISCONNECTED模式下，從設備只響應來自主機的CON-NECT命令(XCP-ON-CAN條件下還可響應GET_SLAVE_ID命令)。下位機端XCP驅動的工作流程如圖4所示。

按照主從通信模式，從機端使用中斷方式對主機的命令進行響應。從機啟動后會首先完成系統的初始化工作，包括對從機硬件資源的初始化、配置系統默認參數以及XCP模塊的初始化，并且將標定數據從ROM或Flash鏡像到RAM，為標定工作做好準備。在解析到來自主機的CTO消息中包含CONNECT命令后，從機響應主機建立連接，該設備進入在線狀態，進而處理來自主機的一系列命令，并根據命令碼（CMD code）調用對應的模塊進行響應，完成對應操作后將數據封裝成DTO數據包發送給主機。如處理出錯，則返回對應的ERR數據包，其第二字節包含具體的錯誤碼。

2.2 上位機端XCP協議驅動程序的實現

上位機采用圖形化編程語言LabVIEW開發。XCP協議共規定了18條必選命令和38條可選命令[5]。結合標定系統的功能需求和開發語言特點，實現思路是將18條必選命令和部分可選命令分別定義為獨立的子vi，然后根據實際功能需求對其進行順序調用。實現的部分命令子vi如圖5所示。

結合標定軟件的功能需求和XCP協議規定的CMD列表，上位機端的XCP協議實現框架如圖6所示。

本文設計的標定系統軟件包含部分尚未實現的可選命令。當用戶操作需要用到該命令時，下位機會統一返回ERR_CMD_UNKNOWN錯誤代碼。

3 XCP協議傳輸層設計

作為對CCP協議的升級，XCP協議最突出的特點是協議層獨立于具體的物理傳輸層，從而增加了協議對總線適用的靈活性，減少了開發移植的重復工作。XCP協議規定的XCP報文(XCP Message，也稱XCP Frame)結構如圖7所示。

XCP報文分為3部分，分別是報文頭(XCP Header)、報文尾(XCP Tail)和中間的XCP數據包(XCP Packet)。其中XCP數據包由協議層定義，報文頭和報文尾由傳輸層定義，從而實現同一協議層數據包可通過不同物理總線進行傳輸。

3.1 XCP-on-CAN傳輸層設計

當物理層傳輸介質為CAN總線時，報文頭為空，報文尾由開發者根據實際需求選則有或者無，且XCP數據包中不包含時間標識段(TIMESTAMP)。其原理是：CAN2.1協議規定CAN報文數據幀的數據域長度DLC最多為8 B[6]。如果設置CAN報文中的數據長度DLC始終等于XCP數據包長度LEN，則報文尾為空，此時XCP數據包就是XCP報文；如果設定DLC長度始終為MAX_DLC=8，則當XCP數據包長度小于8 B時，需要通過添加XCP報文尾的方式補足8 B（填充內容任意）。本文設計的XCP-on-CAN報文采用第一種方式，即令DLC始終與LEN相等。

3.2 XCP-on-FlexRay傳輸層設計

當物理層傳輸介質為FlexRay總線時，必包含報文頭，而報文尾則根據所在報文實際情況，可能為空，也可能為1 B的填充域(填充內容任意)。其原理是：報文頭包含4個部分，分別為XCP節點地址(NAX)、計數(CTR)、填充字節(FILL)和XCP報文數(LEN)。除首字節NAX外，其余部分均為可選項。FlexRay作為新一代高速總線，每一幀的理論有效數據長度能達到254 B，實際應用過程中有效數據長度取決于具體的FlexRay控制器參數，其中恩智浦MFR4310控制器已經可以實現0～254 B數據域長度配置[7]。為了增加總線吞吐量，當FlexRay數據幀中含有多個連續的XCP報文時，需要給每一個報文順序計數CTR以保證數據的有序性，同時還要給出所包含的XCP報文個數LEN，而FILL域用于實現Byte或Word對齊，提高FlexRay總線傳輸效率[8]。本文設計的FlexRay數據幀采用最為簡潔的形式，僅包含一個XCP報文。

本文設計的XCP-on-CAN和XCP-on-FlexRay報文結構如圖8所示。

4 標定系統驗證

對系統進行驗證的首要目標是保證系統的各項基本功能均能夠準確、可靠地實現。驗證的基本思路是：第一階段，連接標定系統上位機、下位機，并運行上位機標定軟件，將下位機ECU上電，通過簡單的配置后可以實現上、下位機的成功連接。而后建立監測窗口，選取若干參數進行數據顯示，觀察是否能正常運行；再建立標定窗口，對上述某一參數數值進行修改，從而驗證標定系統的基本功能。第二階段，連接本文開發的標定系統和實驗室一直使用的電池包管理ECU，重復上述驗證程序，驗證標定系統的適用性。實驗結果表明該系統使用簡單靈活，能夠滿足實驗室標定工作的基本需求。標定系統工作時的連接參數配置界面、監測窗口和標定窗口如圖9所示。

5 結論

本文基于XCP協議完成了ECU標定系統的開發，按照ASAM-MCD標準設計系統整體架構并予以實現，保證了系統的通用性。利用其協議層獨立于傳輸層的特性，在同一協議層的基礎上設計了CAN總線和FlexRay總線對應的兩種傳輸層結構，克服了基于CCP協議的標定系統僅支持CAN總線的局限性。最后應用標定系統進行標定試驗，驗證其監測、標定等基本功能。本文設計的標定系統具有良好的總線適用性和可擴展性，不僅滿足當下主流CAN總線的標定需求，而且支持新一代FlexRay總線。與此同時，XCP協議多總線支持的特性也為今后進一步擴展XCP-on-Ethernet、XCP-on-SXI和XCP-on-MOST提供了保證。