龐鑫,陳雪華
(廣汽菲亞特克萊斯勒汽車有限公司產品工程技術中心,湖南 長沙 410100)
目前整車電子電器架構正在經歷由分布式向集中式電子架構的過渡階段,車輛部分功能仍受不同且單一的電子控制單元控制,隨著車輛功能迭代,車載模塊數量遞增,車輛下線電氣檢測的復雜程度也在同步提升。
下線電氣檢測是車輛出廠前的關鍵環節,為確保產品車的出廠品質,在車輛裝配完成后,需使用全自動電氣檢測設備對車輛進行配置文件寫入、參數標定及功能檢測。因新車型試生產前沒有理想的整車環境,電氣檢測程序也未就緒,因一些電氣檢測程序紕漏而報出的問題不能被有效識別,導致一些不必要的車輛拆裝,零部件級的排查耗費較多工時,影響到生產節拍和項目的時間節點。本文對投產前下線電氣檢測的方案進行研究和設計,并在實際項目中采用了該方案,達到了理想的效果。
車輛下線電氣檢測系統主要包括:工廠服務器、手持多功能檢測設備、四輪定位檢測站、轉轂測試檢測站以及打印機等附屬設備。
工廠服務器通過以太網與各檢測裝置相連接,并在整車集成檢測過程中進行中央控制管理、儲存、分析、處理不同源之間傳送的數據。
手持多功能檢測器通過無線連接的方式與服務器交互,通過其附帶線束上的連接器與被檢測車輛OBD接口相連,使多功能測試器能與車輛各控制單元通信,并對其進行初始化寫入配置文件及相關檢測;各檢測站均配置手持多功能檢測器配合檢測站的測試設備執行下線檢測工作。
電氣檢測工位具備車輛配置信息寫入、電子追溯信息校驗、電子系統控制(如燈光、空調)等功能,并將數據實時上傳給服務器。
四輪定位檢測站具備車輛數據采集、四輪定位標定、燈光系統調節、駕駛輔助傳感器標定等功能,并將數據實時上傳給服務器。
轉轂測試檢測站具備車輛動態測試、胎壓傳感器激活、制動力測試、加速度傳感器標定等功能,并將數據實時上傳給服務器。
各檢測工位均配置打印機,用于打印該檢測工位檢測結果報告單,報告單上的不合格項描述信息可以指導工程人員進行問題排查。
車輛白車身投入總裝車間后,經過內飾裝配線、底盤裝配線、油液加注后進入終裝線,完成所有零件的裝配工序后到達檢測工位。檢測員通過手持檢測設備掃描車身上條碼,獲取車輛派生信息,執行對應的檢測程序,檢測完成后,根據打印出來的檢測結果報告單,判斷車輛是否能夠繼續往下工序流動。檢測流程如圖1所示:電氣檢測→四輪定位→轉轂檢測。

圖1 下線檢測流程
車輛下線檢測結果基于UDS(Unified Diagnostic Services,統一診斷服務)來判斷,診斷協議是ISO 15765和ISO 14229定義的一種汽車通用診斷協議,位于OSI模型中的應用層,UDS本質上是一系列的服務,共包含6大類26種。每種服務都有自己獨立的ID,即SID(Service ID)。
在UDS的26種服務中,有7種比較常用。它們分別是:$10 Diagnostic Session Control(診 斷 會 話),$2F Input Output Control By Identifier(通過標識符控制輸入輸出),$14 Clear Diagnostic Information(清 除 診 斷 信 息),$19 Read DTC Information(讀取故障碼信息),$22 Read Data By Identifier(通過ID讀數據),$2E Write Data By Identifier(通過ID寫數據),$31 routinecontrol(例程控制),表1對這7個服務的具體應用進行了簡要說明。

表1 診斷服務及其應用
在某型號試生產車型的下線電氣檢測過程中,有多臺車輛的A模塊報出了不合格項,通過分析打印出來檢測結果報告單,發現A模塊對寫入車輛配置信息的0x2E 2023指令做出了否定響應。
為查明不合格項原因,通過CANoe軟件對電氣檢測的日志進行分析,發現在電氣檢測過程中,當手持設備對該模塊寫入車輛配置信息時,該模塊在否定響應0x78(Request Correctly Received-Response Pending)兩次后,再次發送否定響應0x10(General Reject),詳見圖2,服務器識別該信息后,判斷該檢測項目不合格,并打印檢查結果報告單提醒檢測人員。

圖2 電氣檢測日志分析
繼續對該問題展開調查,最終確認車輛配置信息寫入指令的發送時序存在問題,導致A模塊無法做出肯定響應,在對相關指令的發送時序進行合理調整后,該問題沒有再重復出現。在試生產過程當中,還出現過其他類型的不合格項,比如:對I/O控制指令的否定響應,基于例程控制的功能標定失效等,在此不一一列舉。
隨著新車型的控制系統復雜性不斷提高,整車多達幾十個模塊需要基于診斷服務完成配置參數寫入和標定等流程,單個模塊響應的診斷指令最多可達到100余條,為避免生產線下線電氣檢測過程中因檢出不合格項導致生產節拍降低,需要開發一種基于CAN總線的自動化車輛下線模擬檢測方案,參照下線檢測方式進行提前檢測,并及時解決檢測出來的問題,避免帶入到生產線上。
CAPL是CAN總線訪問編程語言(CANAccess Programming Language)的簡稱,是一種類C語言,應用于Vector CAN工具的節點編程。本方案主要基于CANoe軟件的開發環境,由CAPL模塊、Panel模塊等構成,其中CAPL模塊為系統的控制核心,負責測試用例的編輯、測試過程調度及測試結果判定,Panel模塊負責生成人機交互界面,通過可視化的界面呈現自動化檢測的結果,同時為目視檢測項目提供輸入接口。
模擬檢測系統的硬件系統由安裝了CANalyzer/CANoe軟件的計算機、Vector CAN通信盒VN1640及整車電子電器臺架構成(圖3)。

圖3 下線模擬檢測方案硬件系統(局部圖)
整車電子電器臺架plywoodbuck(后稱PWB)是電子電器領域測試的基礎環境,是項目開發階段和試驗車輛生產出來之前進行電子協調性的重要平臺。PWB主要模擬整車所有的電子回路,構建各電控單元及開關、傳感器、執行器工作的基礎條件。PWB基于新車型的零件清單進行搭建,同時可接入發動機仿真系統,可支持進行與動力總成信號相關的各項通信測試。
Vector CAN通信盒VN1640具有4個高速CAN總線通道,配合CAN總線收發器(CAN piggy),能夠滿足與當前車輛通信的要求。VN1640也支持基于CAPL語言的編程操作。
CANoe是德國Vector公司開發的CAN總線應用系統分析/開發軟件,可通過接口硬件實現虛擬線與真實物理總線的連接,是目前最為通用的CAN總線開發、仿真軟件。其高性能的函數和自由的可編程能力能夠滿足所有CAN總線系統仿真和實現的需要,可仿真和總線相連的全部網絡節點。
本方案將通過CANoe與整車電子電器臺架搭建測試環境,基于通信數據庫文件(DBC),以及各模塊的診斷規范文件,編寫對應的測試腳本,并使用VN1640連接到車輛OBD接口向各模塊發送診斷報文,通過Trace窗口可直接監控各模塊對診斷指令的反饋信息,通過Panel模塊可顯示需重點關注的信息以及測試結果,并可設置進行多次重復的測試過程,圖4為該方案的工作流程圖,具體流程如下。

圖4 下線檢測模擬系統工作流程圖
1)搭建整車電子電器臺架,并完成電器回路檢查及基本的調試工作。
2)根據通信數據庫文件以及各模塊的診斷規范文件,梳理待測試的診斷指令以及目標反饋狀態,結合對診斷指令時序的考慮,編寫測試用例文件。
3)通過VN1640連接臺架,并在CANoe軟件中完成工程文件配置,基于測試用例文件,編寫CAPL測試腳本,配置Panel圖形化模塊,并完成腳本的編譯。
4)運行CANoe,系統會模擬下線診斷設備逐一對各模塊發送診斷指令,通過監控系統運行的情況,判斷腳本是否存在bug,需要修正。
5)正式執行測試,監控測試結果,如有問題及時記錄并制定對策。
測試腳本的編寫需滿足Vector CAPL的基本語法,對系統變量進行申明后,可基于具體事件過程進行編程,圖5為測試腳本部分截圖,包含了對車輛雨刮、前照燈以及車門解鎖等功能的激活和檢測。

圖5 測試腳本的編寫
為了更直觀地監控測試結果,可以使用CANoe軟件集成的Panel Designer工具。通過該工具可以創建面板,對放置的控件關聯上信號變量,同時可以呈現測試結果,監控關注的各類信號,圖6為該Panel的部分截圖。

圖6 測試面板Panel的部分截圖
在Panel面板配置完成后,進行CAPL的編譯,結果OK后,連接到整車電器臺架,運行測試系統,監控其運行狀態是否符合測試用例的需求,如存在bug,及時更新腳本直至滿足需求。
圖7為車輛電氣下線模擬檢測系統的運行效果的部分截圖,Execute及Reset button的設置可以滿足在測試過程中任何時間點重新執行測試的需求,OK及NOK button用于在執行目視檢查項目(如單側前照燈開啟)時對系統的輸入,通過input/output控件可監控到各測試項的執行結果,也可配合trace窗口檢查各模塊對診斷指令的反饋值,Meter控件用于顯示車輛系統電壓、冷卻水溫、發動機轉速、胎壓以及變速器擋位等信息,在一個界面集中展示這些信息更有利于測試人員在測試過程中整體把握車輛狀態。
為提高新車型投入總裝后的電氣檢測合格率,設計了一種用于基于CAPL語言的車輛電氣下線檢測模擬系統。該系統以Vector VN1640和整車電子電器系統臺架為硬件平臺,以CANoe作為基礎軟件,使用CAPL語言編寫測試程序,結合圖形化面板Panel的配置,在新車型正式生產前2個月,就實現了對整車環境的下線模擬檢測。測試過程暴露出來的問題,很多都能在車輛正式投產前順利解決,為項目的開發贏得了寶貴的時間。
該系統操作簡便,人機界面友好,測試內容覆蓋面廣,既縮短了開發周期,又降低了開發成本,自開發完成以來,已成功應用在多個項目的開發過程中。