龐鑫，陳雪華

（廣汽菲亞特克萊斯勒汽車有限公司產(chǎn)品工程技術(shù)中心，湖南 長沙 410100）

目前整車電子電器架構(gòu)正在經(jīng)歷由分布式向集中式電子架構(gòu)的過渡階段，車輛部分功能仍受不同且單一的電子控制單元控制，隨著車輛功能迭代，車載模塊數(shù)量遞增，車輛下線電氣檢測的復(fù)雜程度也在同步提升。

下線電氣檢測是車輛出廠前的關(guān)鍵環(huán)節(jié)，為確保產(chǎn)品車的出廠品質(zhì)，在車輛裝配完成后，需使用全自動電氣檢測設(shè)備對車輛進行配置文件寫入、參數(shù)標(biāo)定及功能檢測。因新車型試生產(chǎn)前沒有理想的整車環(huán)境，電氣檢測程序也未就緒，因一些電氣檢測程序紕漏而報出的問題不能被有效識別，導(dǎo)致一些不必要的車輛拆裝，零部件級的排查耗費較多工時，影響到生產(chǎn)節(jié)拍和項目的時間節(jié)點。本文對投產(chǎn)前下線電氣檢測的方案進行研究和設(shè)計，并在實際項目中采用了該方案，達到了理想的效果。

1 車輛下線電氣檢測系統(tǒng)概述

1.1 系統(tǒng)構(gòu)成

車輛下線電氣檢測系統(tǒng)主要包括：工廠服務(wù)器、手持多功能檢測設(shè)備、四輪定位檢測站、轉(zhuǎn)轂測試檢測站以及打印機等附屬設(shè)備。

工廠服務(wù)器通過以太網(wǎng)與各檢測裝置相連接，并在整車集成檢測過程中進行中央控制管理、儲存、分析、處理不同源之間傳送的數(shù)據(jù)。

手持多功能檢測器通過無線連接的方式與服務(wù)器交互，通過其附帶線束上的連接器與被檢測車輛OBD接口相連，使多功能測試器能與車輛各控制單元通信，并對其進行初始化寫入配置文件及相關(guān)檢測；各檢測站均配置手持多功能檢測器配合檢測站的測試設(shè)備執(zhí)行下線檢測工作。

電氣檢測工位具備車輛配置信息寫入、電子追溯信息校驗、電子系統(tǒng)控制（如燈光、空調(diào)）等功能，并將數(shù)據(jù)實時上傳給服務(wù)器。

四輪定位檢測站具備車輛數(shù)據(jù)采集、四輪定位標(biāo)定、燈光系統(tǒng)調(diào)節(jié)、駕駛輔助傳感器標(biāo)定等功能，并將數(shù)據(jù)實時上傳給服務(wù)器。

轉(zhuǎn)轂測試檢測站具備車輛動態(tài)測試、胎壓傳感器激活、制動力測試、加速度傳感器標(biāo)定等功能，并將數(shù)據(jù)實時上傳給服務(wù)器。

各檢測工位均配置打印機，用于打印該檢測工位檢測結(jié)果報告單，報告單上的不合格項描述信息可以指導(dǎo)工程人員進行問題排查。

1.2 檢測流程

車輛白車身投入總裝車間后，經(jīng)過內(nèi)飾裝配線、底盤裝配線、油液加注后進入終裝線，完成所有零件的裝配工序后到達檢測工位。檢測員通過手持檢測設(shè)備掃描車身上條碼，獲取車輛派生信息，執(zhí)行對應(yīng)的檢測程序，檢測完成后，根據(jù)打印出來的檢測結(jié)果報告單，判斷車輛是否能夠繼續(xù)往下工序流動。檢測流程如圖1所示：電氣檢測→四輪定位→轉(zhuǎn)轂檢測。

圖1 下線檢測流程

1.3 檢測結(jié)果判斷

車輛下線檢測結(jié)果基于UDS（Unified Diagnostic Services，統(tǒng)一診斷服務(wù)）來判斷，診斷協(xié)議是ISO 15765和ISO 14229定義的一種汽車通用診斷協(xié)議，位于OSI模型中的應(yīng)用層，UDS本質(zhì)上是一系列的服務(wù)，共包含6大類26種。每種服務(wù)都有自己獨立的ID，即SID（Service ID）。

在UDS的26種服務(wù)中，有7種比較常用。它們分別是：$10 Diagnostic Session Control（診 斷 會 話），$2F Input Output Control By Identifier（通過標(biāo)識符控制輸入輸出），$14 Clear Diagnostic Information（清 除 診 斷 信 息），$19 Read DTC Information（讀取故障碼信息），$22 Read Data By Identifier（通過ID讀數(shù)據(jù)），$2E Write Data By Identifier（通過ID寫數(shù)據(jù)），$31 routinecontrol（例程控制），表1對這7個服務(wù)的具體應(yīng)用進行了簡要說明。

表1 診斷服務(wù)及其應(yīng)用

2 下線檢測不合格項案例分析

在某型號試生產(chǎn)車型的下線電氣檢測過程中，有多臺車輛的A模塊報出了不合格項，通過分析打印出來檢測結(jié)果報告單，發(fā)現(xiàn)A模塊對寫入車輛配置信息的0x2E 2023指令做出了否定響應(yīng)。

為查明不合格項原因，通過CANoe軟件對電氣檢測的日志進行分析，發(fā)現(xiàn)在電氣檢測過程中，當(dāng)手持設(shè)備對該模塊寫入車輛配置信息時，該模塊在否定響應(yīng)0x78（Request Correctly Received-Response Pending）兩次后，再次發(fā)送否定響應(yīng)0x10（General Reject），詳見圖2，服務(wù)器識別該信息后，判斷該檢測項目不合格，并打印檢查結(jié)果報告單提醒檢測人員。

圖2 電氣檢測日志分析

繼續(xù)對該問題展開調(diào)查，最終確認(rèn)車輛配置信息寫入指令的發(fā)送時序存在問題，導(dǎo)致A模塊無法做出肯定響應(yīng)，在對相關(guān)指令的發(fā)送時序進行合理調(diào)整后，該問題沒有再重復(fù)出現(xiàn)。在試生產(chǎn)過程當(dāng)中，還出現(xiàn)過其他類型的不合格項，比如：對I/O控制指令的否定響應(yīng)，基于例程控制的功能標(biāo)定失效等，在此不一一列舉。

隨著新車型的控制系統(tǒng)復(fù)雜性不斷提高，整車多達幾十個模塊需要基于診斷服務(wù)完成配置參數(shù)寫入和標(biāo)定等流程，單個模塊響應(yīng)的診斷指令最多可達到100余條，為避免生產(chǎn)線下線電氣檢測過程中因檢出不合格項導(dǎo)致生產(chǎn)節(jié)拍降低，需要開發(fā)一種基于CAN總線的自動化車輛下線模擬檢測方案，參照下線檢測方式進行提前檢測，并及時解決檢測出來的問題，避免帶入到生產(chǎn)線上。

3 系統(tǒng)方案介紹

3.1 基于CAPL語言編程的車輛下線電氣檢測模擬系統(tǒng)方案

CAPL是CAN總線訪問編程語言（CANAccess Programming Language）的簡稱，是一種類C語言，應(yīng)用于Vector CAN工具的節(jié)點編程。本方案主要基于CANoe軟件的開發(fā)環(huán)境，由CAPL模塊、Panel模塊等構(gòu)成，其中CAPL模塊為系統(tǒng)的控制核心，負(fù)責(zé)測試用例的編輯、測試過程調(diào)度及測試結(jié)果判定，Panel模塊負(fù)責(zé)生成人機交互界面，通過可視化的界面呈現(xiàn)自動化檢測的結(jié)果，同時為目視檢測項目提供輸入接口。

3.2 硬件系統(tǒng)

模擬檢測系統(tǒng)的硬件系統(tǒng)由安裝了CANalyzer/CANoe軟件的計算機、Vector CAN通信盒VN1640及整車電子電器臺架構(gòu)成（圖3）。

圖3 下線模擬檢測方案硬件系統(tǒng)（局部圖）

整車電子電器臺架plywoodbuck（后稱PWB）是電子電器領(lǐng)域測試的基礎(chǔ)環(huán)境，是項目開發(fā)階段和試驗車輛生產(chǎn)出來之前進行電子協(xié)調(diào)性的重要平臺。PWB主要模擬整車所有的電子回路，構(gòu)建各電控單元及開關(guān)、傳感器、執(zhí)行器工作的基礎(chǔ)條件。PWB基于新車型的零件清單進行搭建，同時可接入發(fā)動機仿真系統(tǒng)，可支持進行與動力總成信號相關(guān)的各項通信測試。

Vector CAN通信盒VN1640具有4個高速CAN總線通道，配合CAN總線收發(fā)器（CAN piggy），能夠滿足與當(dāng)前車輛通信的要求。VN1640也支持基于CAPL語言的編程操作。

3.3 軟件方案

CANoe是德國Vector公司開發(fā)的CAN總線應(yīng)用系統(tǒng)分析/開發(fā)軟件，可通過接口硬件實現(xiàn)虛擬線與真實物理總線的連接，是目前最為通用的CAN總線開發(fā)、仿真軟件。其高性能的函數(shù)和自由的可編程能力能夠滿足所有CAN總線系統(tǒng)仿真和實現(xiàn)的需要，可仿真和總線相連的全部網(wǎng)絡(luò)節(jié)點。

本方案將通過CANoe與整車電子電器臺架搭建測試環(huán)境，基于通信數(shù)據(jù)庫文件（DBC），以及各模塊的診斷規(guī)范文件，編寫對應(yīng)的測試腳本，并使用VN1640連接到車輛OBD接口向各模塊發(fā)送診斷報文，通過Trace窗口可直接監(jiān)控各模塊對診斷指令的反饋信息，通過Panel模塊可顯示需重點關(guān)注的信息以及測試結(jié)果，并可設(shè)置進行多次重復(fù)的測試過程，圖4為該方案的工作流程圖，具體流程如下。

圖4 下線檢測模擬系統(tǒng)工作流程圖

1）搭建整車電子電器臺架，并完成電器回路檢查及基本的調(diào)試工作。

2）根據(jù)通信數(shù)據(jù)庫文件以及各模塊的診斷規(guī)范文件，梳理待測試的診斷指令以及目標(biāo)反饋狀態(tài)，結(jié)合對診斷指令時序的考慮，編寫測試用例文件。

3）通過VN1640連接臺架，并在CANoe軟件中完成工程文件配置，基于測試用例文件，編寫CAPL測試腳本，配置Panel圖形化模塊，并完成腳本的編譯。

4）運行CANoe，系統(tǒng)會模擬下線診斷設(shè)備逐一對各模塊發(fā)送診斷指令，通過監(jiān)控系統(tǒng)運行的情況，判斷腳本是否存在bug，需要修正。

5）正式執(zhí)行測試，監(jiān)控測試結(jié)果，如有問題及時記錄并制定對策。

測試腳本的編寫需滿足Vector CAPL的基本語法，對系統(tǒng)變量進行申明后，可基于具體事件過程進行編程，圖5為測試腳本部分截圖，包含了對車輛雨刮、前照燈以及車門解鎖等功能的激活和檢測。

圖5 測試腳本的編寫

為了更直觀地監(jiān)控測試結(jié)果，可以使用CANoe軟件集成的Panel Designer工具。通過該工具可以創(chuàng)建面板，對放置的控件關(guān)聯(lián)上信號變量，同時可以呈現(xiàn)測試結(jié)果，監(jiān)控關(guān)注的各類信號，圖6為該Panel的部分截圖。

圖6 測試面板Panel的部分截圖

在Panel面板配置完成后，進行CAPL的編譯，結(jié)果OK后，連接到整車電器臺架，運行測試系統(tǒng)，監(jiān)控其運行狀態(tài)是否符合測試用例的需求，如存在bug，及時更新腳本直至滿足需求。

3.4 運行結(jié)果

圖7為車輛電氣下線模擬檢測系統(tǒng)的運行效果的部分截圖，Execute及Reset button的設(shè)置可以滿足在測試過程中任何時間點重新執(zhí)行測試的需求，OK及NOK button用于在執(zhí)行目視檢查項目（如單側(cè)前照燈開啟）時對系統(tǒng)的輸入，通過input/output控件可監(jiān)控到各測試項的執(zhí)行結(jié)果，也可配合trace窗口檢查各模塊對診斷指令的反饋值，Meter控件用于顯示車輛系統(tǒng)電壓、冷卻水溫、發(fā)動機轉(zhuǎn)速、胎壓以及變速器擋位等信息，在一個界面集中展示這些信息更有利于測試人員在測試過程中整體把握車輛狀態(tài)。

4 結(jié)束語

為提高新車型投入總裝后的電氣檢測合格率，設(shè)計了一種用于基于CAPL語言的車輛電氣下線檢測模擬系統(tǒng)。該系統(tǒng)以Vector VN1640和整車電子電器系統(tǒng)臺架為硬件平臺，以CANoe作為基礎(chǔ)軟件，使用CAPL語言編寫測試程序，結(jié)合圖形化面板Panel的配置，在新車型正式生產(chǎn)前2個月，就實現(xiàn)了對整車環(huán)境的下線模擬檢測。測試過程暴露出來的問題，很多都能在車輛正式投產(chǎn)前順利解決，為項目的開發(fā)贏得了寶貴的時間。

該系統(tǒng)操作簡便，人機界面友好，測試內(nèi)容覆蓋面廣，既縮短了開發(fā)周期，又降低了開發(fā)成本，自開發(fā)完成以來，已成功應(yīng)用在多個項目的開發(fā)過程中。