熊春艷，龔元明

（201620 上海市 上海工程技術大學 機械與汽車工程學院）

0 引言

隨著汽車各控制模塊逐步向自動化和智能化的方向發(fā)展[1]，汽車電子控制系統(tǒng)變得日益復雜，電子控制單元（ECU）診斷測試復雜度也隨之增大[2]。車載電控單元的診斷測試是ECU 診斷開發(fā)的一項重要內(nèi)容，該診斷測試用于驗證ECU 診斷功能實現(xiàn)的正確性以及測試結(jié)果是否符合UDS 規(guī)范，從而確保ECU 的性能以及可靠性[3-4]。

目前汽車行業(yè)通用的診斷協(xié)議是基于CAN 總線的UDS（Unified Diagnosis Specification）協(xié)議[5-6]，UDS 協(xié)議又稱ISO 14229 協(xié)議，它是由ISO 組織制定的國際通用的統(tǒng)一診斷服務標準?；赨DS 協(xié)議定義了多種診斷服務，診斷服務報文的第一個字節(jié)是服務標識符SID（Service Identifier）[7-8]。不同SID 號對應不同類型的診斷服務，UDS 協(xié)議對診斷服務是否支持子服務和具體的功能也進行了詳細定義，具體診斷服務如表1 所示。

表1 UDS 診斷服務表Tab.1 Unified diagnostic services overview

本文基于Vector 公司的CANoe 硬軟件工具研究和設計了基于ISO 14229 協(xié)議的自動化診斷測試平臺，該平臺由CANoe 軟件通過CAN 線與ECU通信，CANoe 對ECU 發(fā)送各種UDS 診斷服務命令，并采集ECU 的響應，最后判斷ECU 的響應狀態(tài)。測試完成后，生成測試報告，記錄測試狀態(tài)。

1 診斷測試系統(tǒng)結(jié)構(gòu)

本測試系統(tǒng)的構(gòu)建滿足某汽車公司規(guī)范定義的ECU 診斷測試的所有需求。測試系統(tǒng)包括整車所有ECU 的CAN ID，具有良好的拓展性。為了提高測試效率和滿足ECU 開發(fā)過程中產(chǎn)生的大量測試的要求，測試系統(tǒng)旨在實現(xiàn)自動化診斷測試。測試系統(tǒng)整體框架包括4 部分：CANoe 仿真和測試軟件、CANoe 硬件、待測ECU 模塊、車輛信息產(chǎn)生和故障模擬系統(tǒng)。測試系統(tǒng)整體框架如圖1 所示。

圖1 測試系統(tǒng)整體框架圖Fig.1 Test system overall frame diagram

自動化診斷測試平臺按照一定的順序進行測試，測試順序按照ISO 14229 定義的診斷服務分類以及網(wǎng)絡安全定義的要求進行設計。測試順序如圖2 所示。

圖2 測試順序圖Fig.2 Test sequence diagram

2 診斷測試系統(tǒng)軟件設計

車載電控單元自動診斷測試平臺主要測試ECU 能否正確響應UDS 協(xié)議下的各種診斷服務，以及其診斷響應結(jié)果是否符合UDS 協(xié)議規(guī)范。為了提高測試效率和滿足ECU 開發(fā)過程中產(chǎn)生的大量診斷測試要求，診斷測試系統(tǒng)基于CANoe 環(huán)境搭建自動化診斷測試平臺，實現(xiàn)了自動化診斷測試。本系統(tǒng)由CANoe 對某公司ECU 支持的所有診斷服務進行診斷，共計15 個診斷服務，包括10 03 服務、2C 03 服務、2A 01 服務、10 02 服務、10 01 服務、3E 00 服務、85 02 服務、85 01 服務、28 03 服務、28 00 服務、14 服務、19 01 服務、19 02 服務、19 0A 服務、27 服務。測試軟件搭建分為3 步創(chuàng)建控制面板、創(chuàng)建系統(tǒng)變量、編寫CAPL 程序。

2.1 創(chuàng)建控制面板

CANoe 環(huán)境中的Panel Designer 可以搭建控制面板，Panel Designer 有文本框、位圖框、按鈕、開關、進度條、數(shù)值顯示框、進制編輯器、顯示控制、時間控制、儀表盤、輸入輸出窗口等多種常用組件，用戶可以在Panel 中搭建個性化定制的狀態(tài)顯示面板和操作面板。通過控制面板，用戶可以更改或?qū)崟r顯示系統(tǒng)變量的值。在Panel 編輯器中定義好各種組件后，將組件系統(tǒng)變量關聯(lián)起來，這樣便可在診斷測試過程進行操控和顯示。面板控件均與系統(tǒng)變量的信號相連接，當該系統(tǒng)接收到ECU 的響應報文，便可以將報文的數(shù)值顯示在各個控制器面板中。同理，面板可以設置系統(tǒng)變量。本系統(tǒng)搭建了參數(shù)配置面板、UDS 診斷測試面板。參數(shù)配置面板用于在配置測試參數(shù)，包括Cycle Times，Period。其中，Cycle Times 表示診斷服務循環(huán)次數(shù)，Period表示循環(huán)間隔時間。UDS 診斷測試面板包括了需要測試的所有診斷服務，可以實現(xiàn)一鍵測試所有診斷服務。

2.2 創(chuàng)建系統(tǒng)變量

系統(tǒng)變量是ECU、CAPL 程序和控制面板相連接的媒介。在CAPL 程序中，系統(tǒng)變量可以通過改變或監(jiān)控來觸發(fā)特定動作，也可以用來記錄診斷測試數(shù)據(jù)。診斷測試系統(tǒng)定義了2 種系統(tǒng)變量，即設置系統(tǒng)變量和顯示系統(tǒng)變量。其中，顯示系統(tǒng)變量用來記錄診斷測試系統(tǒng)中ECU 響應的診斷數(shù)據(jù)（只需記錄3 個有效字節(jié)），設置系統(tǒng)變量用于配置診斷測試前需要配置的系統(tǒng)變量（Cycle Times，Period），通過改變系統(tǒng)變量可以觸發(fā)CAPL 程序?qū)CU 進行診斷。

2.3 CAPL 程序?qū)崿F(xiàn)

自動診斷測試軟件平臺在CANoe 軟件環(huán)境中搭建，利用CAPL 函數(shù)編寫自動化診斷測試函數(shù)。CAPL（通信訪問編程語言，Communication Access Programming Language）是Vector 公司為CANoe 開發(fā)環(huán)境設計的編程語言。CAPL 程序主要由3 部分組成，分別是全局變量、自定義函數(shù)和事件過程。CAPL 語言編寫的程序是事件觸發(fā)程序，CAPL 程序主要是利用對觸發(fā)事件的檢測來執(zhí)行和事件相關的程序。系統(tǒng)中一共有4 個觸發(fā)事件，分別是系統(tǒng)事件、系統(tǒng)變量事件、timer 事件、報文事件。系統(tǒng)事件點擊CANoe 運行時觸發(fā)，然后初始化全局變量；系統(tǒng)變量事件在點擊測試按鍵時觸發(fā)，面板配置好系統(tǒng)變量后，觸發(fā)系統(tǒng)變量事件，初始化timer 并啟動，并把面板的值賦值給系統(tǒng)變量在CAPL 程序中運行；timer 事件是定時器觸發(fā)事件，timer 啟動后周期性地進行診斷測試；報文事件在收到ECU 反饋時觸發(fā)，程序進入報文事件對反饋數(shù)據(jù)做邏輯處理，最后將處理的結(jié)果顯示到面板上。觸發(fā)事件圖如圖3 所示。

圖3 觸發(fā)事件圖Fig.3 Trigger event graph

CAPL 程序?qū)CU 的診斷請求格式見表2。在診斷測試完成后，ECU 響應觸發(fā)報文事件，將響應的值賦值給診斷服務對應的系統(tǒng)變量。

表2 診斷服務請求格式表Tab.2 Diagnostic service request format

（續(xù)表）

3 診斷測試平臺的實現(xiàn)

以車身模塊（DDM）為例進行測試說明測試情況。根據(jù)CANoe 平臺編寫的CAPL 測試函數(shù)對ECU 進行診斷測試，測試結(jié)果通過CANoe 報文跟蹤窗口（Trace Window）可以實時跟蹤網(wǎng)絡上的報文情況（包括節(jié)點發(fā)送及接收到的所有報文）。由于篇幅限制此處僅列舉$10、$85 的CANoe 報文跟蹤窗口進行分析，其余診斷服務響應結(jié)果以列表形式給出。對于診斷會話控制服務(10 h)的子服務擴展會話服務，請求數(shù)據(jù)填充服務格式為0x10（SID）+0x03（SF）。本文設計ECU 支持該子服務，ECU 回復肯定響應，若響應格式為0x50（SID+40）+0x03（SF），則10 03 服務的響應格式符合UDS規(guī)范，測試通過。圖4 為ECU 對擴展會話的響應。

由圖4 所示，CANoe 發(fā)送報文02 10 03 AA AA AA AA AA，ECU 響應的報文為06 50 03 00 32 00 C8 AA。其中第1 個字節(jié)表示報文有效長度。DDM模塊對擴展會話的響應格式符合UDS 協(xié)議規(guī)范。10 03 服務響應格式正確，測試通過。

圖4 ECU 對擴展會話的響應Fig.4 Response format of ECU extended session

對打開DTC 檢測功能85 服務的子服務01，請求數(shù)據(jù)填充服務格式為 0x85（SID）+0x01（SF）。本文設計ECU 支持該子服務，若響應格式為0xC5（SID+40）+0x01（SF），則85 01 服務的響應格式符合UDS 規(guī)范，測試通過。圖5 為 ECU 對DTC檢測功能的響應。

由圖5 所示，CANoe 發(fā)送報文02 85 01 AA AA AA AA AA，ECU 響應的報文為02 C5 01 AA AA AA AA AA。DDM 模塊對85 01 子服務的響應格式符合UDS 協(xié)議規(guī)范，85 01 服務響應格式正確，測試通過。

圖5 ECU 對DTC 檢測功能的響應Fig.5 ECU response format to DTC detection function

表3 為所有診斷服務的響應，響應結(jié)果只用驗證3 個字節(jié)，其余字節(jié)為無效字節(jié)。由表可知，診斷服務的實際響應與目標響應一致，所有診斷服務的響應格式符合UDS 規(guī)范，所有的診斷服務測試通過。

表3 診斷服務響應表Tab.3 Diagnostic service response form

4 結(jié)論

本文通過構(gòu)建并應用車載電控單元自動化診斷測試軟件平臺，測試ECU 能否正確響應UDS 協(xié)議下的各種診斷服務，以及其診斷響應結(jié)果是否符合UDS 協(xié)議規(guī)范。通過該診斷測試平臺，可在新車型項目開發(fā)過程中以較短時間完成大量的診斷測試工作，保證了ECU 的交付狀態(tài)。