車輛EOL智能檢測技術(shù)研究

袁瑞澤，吳發(fā)勇，鄭海濤，溫德龍，劉亞川，顧 軒

（一汽-大眾汽車有限公司，吉林 長春 130011）

1 引言

EOL（End Of Line，下線）檢測是汽車行業(yè)在車輛出廠前重要的電器及整車質(zhì)量把控環(huán)節(jié)，其基本工作原理為總裝車間上位機(jī)系統(tǒng)向生產(chǎn)線現(xiàn)場診斷設(shè)備發(fā)送診斷指令，通過診斷設(shè)備連接車輛OBD（On-Board Diagnostics，車載診斷）接口將診斷指令傳輸至車輛各控制器并執(zhí)行，診斷設(shè)備接收控制器響應(yīng)結(jié)果并反饋至上位機(jī)進(jìn)行結(jié)果評價并完成檢測。

以一汽-大眾車輛生產(chǎn)過程為例，EOL檢測主要負(fù)責(zé)整車所有控制器的數(shù)據(jù)檢查和功能檢測，具體內(nèi)容包含：①控制器的軟硬件版本核查，②控制器的配置參數(shù)寫入，③控制器軟件版本的在線刷新升級，④控制器的自學(xué)習(xí)及功能標(biāo)定，⑤協(xié)同車間加注設(shè)備完成燃料、剎車液等加注流程，⑥車輛在線防盜匹配，⑦前束轉(zhuǎn)轂測試，⑨輔助及自動駕駛功能標(biāo)定，⑩生產(chǎn)過程關(guān)鍵工藝參數(shù)及控制器裝配版本信息報交上傳。

近些年，汽車行業(yè)在電動化、智能化及網(wǎng)聯(lián)化上的進(jìn)程不斷向前推進(jìn)，車輛在自動駕駛、智能座艙、車聯(lián)網(wǎng)及動力驅(qū)動領(lǐng)域的電器控制功能需求逐漸增多和豐富，從而需要增加更多控制器來實現(xiàn)這些功能，控制器之間的信息傳遞和交互邏輯日趨復(fù)雜，導(dǎo)致整車的電器架構(gòu)復(fù)雜度大幅增加。為了應(yīng)對這種電器架構(gòu)上的復(fù)雜性提升，需對底層電器架構(gòu)進(jìn)行顛覆性的技術(shù)升級和更新。目前行業(yè)的共識是博世的電器架構(gòu)演進(jìn)趨勢[1]，即從傳統(tǒng)分布式電器架構(gòu)經(jīng)域集中電器架構(gòu)最終向車輛中央電器架構(gòu)發(fā)展。

在新的電器架構(gòu)下，車輛應(yīng)用及控制器軟件逐漸成為未來體現(xiàn)各車企差異化競爭力的核心領(lǐng)域，即軟件定義汽車?yán)砟睿⊿DV，Software Defined Vehicles）。通過硬件預(yù)置，快速迭代開發(fā)升級軟件功能及配置，并基于OTA（Over-the-air Technology，空中下載技術(shù)）對車輛的軟件遠(yuǎn)程更新，從而實現(xiàn)車輛功能的常用常新，也推動汽車產(chǎn)業(yè)的業(yè)務(wù)模式發(fā)生根本上的改變[2]。

在上述技術(shù)發(fā)展背景下，傳統(tǒng)的車輛EOL檢測系統(tǒng)難以應(yīng)對新的技術(shù)變化，主要體現(xiàn)在以下幾個方面：①檢測內(nèi)容隨著車輛功能的增加及新增的新能源檢測項而成比例上升，車型生產(chǎn)階段的電器檢測方案設(shè)計過程愈加復(fù)雜；②電器檢測方案需根據(jù)車輛及控制器軟件版本變化快速迭代，版本管理難度增大，驗證釋放周期縮短；③傳統(tǒng)診斷模式為離線，難以快速應(yīng)對檢測方案的快速迭代并實施檢測，且設(shè)備成本較高；④檢測過程生成的大量結(jié)果數(shù)據(jù)價值挖掘不足；⑤全流程數(shù)字化程度不足，工作效率較低。

為解決上述EOL檢測領(lǐng)域面臨的問題，一汽-大眾推進(jìn)EOL智能檢測技術(shù)研究，下面章節(jié)將對智能檢測的當(dāng)前現(xiàn)狀和實施方案進(jìn)行闡述，并對未來技術(shù)的發(fā)展方向進(jìn)行展望。

2 EOL重點環(huán)節(jié)現(xiàn)狀及痛點

當(dāng)前車輛EOL檢測閉環(huán)流程的關(guān)鍵環(huán)節(jié)的業(yè)務(wù)模式和技術(shù)水平均存在局限，難以適應(yīng)車輛電器技術(shù)的高速發(fā)展。

2.1 電器檢測方案設(shè)計

在方案設(shè)計環(huán)節(jié)，需定義車型所有控制器的檢測內(nèi)容，并需根據(jù)生產(chǎn)階段的質(zhì)量及技術(shù)要求持續(xù)集成新檢測項，形成車型級檢測方案。最終，需將車型檢測內(nèi)容根據(jù)控制器依賴邏輯及裝配工序合理排布至總裝車間各EOL檢測點，如圖1所示。

圖1 電器檢測方案設(shè)計流程

實際執(zhí)行過程中，由于缺少標(biāo)準(zhǔn)化的診斷數(shù)據(jù)格式定義，且為PDF或者Excel等線下形式，電器檢測數(shù)據(jù)傳遞和方案的設(shè)計效率低且容易出錯，并難以應(yīng)對頻繁的檢測方案調(diào)整和調(diào)整。以ID.4車型為例，涉及80余個控制器、600余個檢測模塊和3 000余條檢測序列，且項目期間檢測方案更新超過30版，傳統(tǒng)線下的檢測方案設(shè)計方式復(fù)雜度呈指數(shù)上升。

2.2 檢測實施及診斷

現(xiàn)場專用檢測實施設(shè)備在檢測前需將經(jīng)過程序化編譯的檢測方案和全部所需相關(guān)數(shù)據(jù)下載至設(shè)備本地，檢測設(shè)備的計算能力則限制了診斷系統(tǒng)的擴(kuò)展。此外，檢測過程需專職操作人員照管設(shè)備，效率低下。難以應(yīng)對SDV背景下的頻繁線下軟件刷新及快速車輛返修電檢場景[3]。因此，診斷技術(shù)核心計算功能亟待向云端轉(zhuǎn)移和升級。

2.3 檢測方案閉環(huán)驗證

現(xiàn)有的檢測方案驗證需在車輛完成檢測后，下載檢測報告人工逐項比對實際執(zhí)行內(nèi)容與方案內(nèi)容的匹配性，從而評估檢測方案的正確與合理性。

但從方案設(shè)計、現(xiàn)場檢測實施再到人工比對整個流程周期可長達(dá)7天，且局限于檢測報告的顆粒度無法深入診斷總線底層邏輯，導(dǎo)致驗證的效率和正確率都存在局限。

2.4 檢測結(jié)果數(shù)據(jù)分析

檢測結(jié)果數(shù)據(jù)分析是快速定位檢測過程中出現(xiàn)的電器問題原因的重要手段，確定電器問題是來自于檢測數(shù)據(jù)、軟件版本、產(chǎn)品設(shè)計、工藝布置和程序編寫等具體領(lǐng)域，從而針對性制定解決方案。

但當(dāng)前檢測結(jié)果數(shù)據(jù)是以檢測車輛為標(biāo)準(zhǔn)劃分離散分布的，沒有統(tǒng)一入湖管理，對問題的解決難以形成趨勢化的大數(shù)據(jù)監(jiān)控和問題解決方案知識庫，導(dǎo)致數(shù)據(jù)價值利用率較低。且整個分析過程由人工逐步比對進(jìn)行，分析效率較低。

3 系統(tǒng)方案及應(yīng)用實施

基于當(dāng)前EOL檢測各重點環(huán)節(jié)的現(xiàn)狀，通過數(shù)字化、云端計算、數(shù)字孿生和智能算法等技術(shù)研究和方案，進(jìn)行針對性地逐項技術(shù)升級，以實現(xiàn)EOL檢測領(lǐng)域全流程的智能化。

3.1 數(shù)字化檢測方案設(shè)計

針對檢測數(shù)據(jù)格式不統(tǒng)一問題，自2017年起大眾康采恩集團(tuán)進(jìn)行檢測規(guī)范數(shù)據(jù)的標(biāo)準(zhǔn)化進(jìn)程，實現(xiàn)了控制器檢測規(guī)范源數(shù)據(jù)標(biāo)準(zhǔn)格式的定義和推廣，累計定義標(biāo)準(zhǔn)字段300余個，且采用計算機(jī)可識別和批量處理的XML（eXtensible Markup Language，可擴(kuò)展標(biāo)記語言）數(shù)據(jù)格式。

以數(shù)據(jù)化標(biāo)準(zhǔn)為基礎(chǔ)，建立數(shù)字化檢測方案設(shè)計系統(tǒng)，實現(xiàn)：

1）建立控制器檢測規(guī)范數(shù)據(jù)庫，將不同平臺及車型的檢測數(shù)據(jù)統(tǒng)一管理，對檢測數(shù)據(jù)結(jié)構(gòu)化用戶交互展示，并實時在線進(jìn)行檢測方案的編輯和發(fā)布，下一層自動引用和集成。同時針對PDX（Package of ODX data，診斷描述文件）進(jìn)行解析，可在檢測方案設(shè)計過程中直接調(diào)取診斷序列碼流參數(shù)，進(jìn)一步保障檢測方案的設(shè)計質(zhì)量[4]。數(shù)字化檢測方案設(shè)計如圖2所示。

圖2 數(shù)字化檢測方案設(shè)計

2）基于動態(tài)節(jié)點的比對算法，系統(tǒng)自動核查版本變動信息，提示技術(shù)人員對變動點進(jìn)行及時的調(diào)用和發(fā)布。應(yīng)對檢測源數(shù)據(jù)的頻繁更新，僅對變動點進(jìn)行關(guān)注和處理，而無需人工核對整個新的檢測方案，檢測方案設(shè)計和發(fā)布效率得到大幅提升和改善。

3）引入圖形化引擎，實現(xiàn)工藝流程方案的拖拽化生成，即將車間檢測工位的工藝流程直觀地以圖形化形式編輯和展現(xiàn)，且各圖形節(jié)點背后由數(shù)據(jù)模型支撐，通過點擊可查看該節(jié)點具體的上層級控制檢測內(nèi)容和步驟。

通過數(shù)字化的檢測方案設(shè)計實施，一汽大眾在多個車型實現(xiàn)了從產(chǎn)品檢測源數(shù)據(jù)到工藝檢測流程全體系線上化，電器工藝設(shè)計效率提升2倍以上，單車型節(jié)省工時925 h以上。下一步計劃逐步打通該系統(tǒng)同產(chǎn)品研發(fā)數(shù)據(jù)系統(tǒng)的接口，進(jìn)一步提升研發(fā)與生產(chǎn)的協(xié)同效率。

3.2 云端診斷及數(shù)字孿生

在檢測實施診斷環(huán)節(jié)，智能檢測方案引入云端計算和物聯(lián)網(wǎng)技術(shù)，將整車電器診斷的復(fù)雜計算過程的內(nèi)核和數(shù)據(jù)向云端轉(zhuǎn)移。該模塊方案主要涉及三個方面：

1）云計算平臺開發(fā)。在云平臺依據(jù)ISO 14229的UDS（Unified Diagnostic Services，統(tǒng)一診斷服務(wù)）汽車診斷標(biāo)準(zhǔn)協(xié)議，對診斷中安裝檢測、參數(shù)寫入、DTC讀取、軟件刷新、例程控制和功能標(biāo)定等基礎(chǔ)模塊檢測流程進(jìn)行定義和封裝，并依照控制器安全訪問及保護(hù)等策略，與車輛控制器建立安全連接。這些基礎(chǔ)檢測模塊可進(jìn)行任意組合形成診斷實施流程以適應(yīng)返修、刷新等應(yīng)用場景。通過內(nèi)置PDX的解析模塊，可將該流程解析為OBD插頭及車輛可識別及執(zhí)行的十六進(jìn)制診斷序列，由云平臺通過Wi-Fi或藍(lán)牙無線數(shù)據(jù)傳輸方式下發(fā)給OBD插頭。此外，云平臺通過多線程設(shè)計，實現(xiàn)多個診斷任務(wù)的同時進(jìn)行，并在診斷實施進(jìn)行過程中實時記錄執(zhí)行狀態(tài)，并生成診斷檢測報告。

2）設(shè)計研發(fā)OBD診斷插頭。由于診斷的核心計算功能移至云平臺，診斷插頭則作為數(shù)據(jù)傳輸?shù)闹修D(zhuǎn)和路由，集成了無線傳輸模塊接收云平臺數(shù)據(jù)，并依照CAN、CAN-FD和DoIP等診斷協(xié)議開發(fā)相應(yīng)的診斷數(shù)據(jù)處理模塊[3]，將云平臺下發(fā)的十六進(jìn)制診斷序列解析成為車輛控制器能夠識別和執(zhí)行的二進(jìn)制底層程序，控制器執(zhí)行完畢后則通過診斷插頭回傳診斷狀態(tài)及結(jié)果。

3）數(shù)字孿生?；谠破脚_和診斷插頭的診斷實施實體基礎(chǔ)，建立檢測方案與實施方案的數(shù)字孿生模式。數(shù)字化檢測方案設(shè)計系統(tǒng)輸出的診斷任務(wù)作為虛實映射的數(shù)字端完成虛擬方案的設(shè)計，通過基于ISO 13209的OTX（Open Test Sequence eXchange Format，開路測試序列交換格式）協(xié)議開發(fā)，完成標(biāo)準(zhǔn)檢測序列的定義，向云平臺可映射出可下發(fā)執(zhí)行的任務(wù)并在生產(chǎn)端實施。

通過云端診斷技術(shù)在預(yù)批量生產(chǎn)、下線返修及軟件刷新等場景的實際應(yīng)用，實現(xiàn)了試制車診斷效率提升10倍，軟件刷新效率提升1.5倍。未來基于系統(tǒng)的穩(wěn)定性檢驗，將該診斷實施方案向批量生產(chǎn)過程及售后診斷場景繼續(xù)擴(kuò)展。

3.3 虛擬工藝仿真驗證

在檢測方案方案驗證環(huán)節(jié)，增加檢測實施前的前期驗證流程，靠前建立工藝驗證能力，提升生產(chǎn)過程中的過程質(zhì)量和效率。針對車輛控制器的檢測過程和生產(chǎn)線的運(yùn)行流程，依托虛擬仿真技術(shù)，設(shè)計數(shù)據(jù)模型，對檢測方案運(yùn)行情況進(jìn)行仿真和驗證[5]。

1）單車仿真，首先對控制器的檢測內(nèi)容進(jìn)行解析和流程化，轉(zhuǎn)換成十六進(jìn)制檢測序列。依照控制器的輸入輸出響應(yīng)算法，對檢測序列的執(zhí)行過程進(jìn)行實時仿真，如圖3所示，從而實現(xiàn)不合格檢測及風(fēng)險項的自動提醒，并對控制器執(zhí)行檢測時長進(jìn)行監(jiān)控。在檢測工位及車間檢測方案層面，依據(jù)工位的規(guī)劃工時，實時計算工位符合率及車輛各條總線的占用情況，并完成對檢測內(nèi)容覆蓋度的自動檢測和重復(fù)檢測項的監(jiān)控。最后對仿真輸出的問題建立問題庫。

圖3 工藝仿真案例

2）產(chǎn)線仿真，通過設(shè)置不同車輛配置及控制器檢測內(nèi)容的隨機(jī)合格率，結(jié)合生產(chǎn)線的生產(chǎn)節(jié)拍和裝配順序數(shù)據(jù)輸入，模擬在各種變量情況下的生產(chǎn)線運(yùn)行狀態(tài)，驗證生產(chǎn)線的節(jié)拍負(fù)荷及超時擁堵情況。

通過工藝虛擬仿真方案的引入，實現(xiàn)了檢測方案的快速驗證，預(yù)先檢驗發(fā)現(xiàn)檢測方案的沖突項和不合理設(shè)置，降低了檢測方案設(shè)計問題在批量生產(chǎn)中出現(xiàn)的概率，并大幅縮短了檢測方案的優(yōu)化時間。工藝仿真案例如圖3所示。

3.4 電檢數(shù)據(jù)智能分析

針對檢測結(jié)果數(shù)據(jù)離散化分布的問題，在電檢數(shù)據(jù)的管理上建立統(tǒng)一數(shù)據(jù)湖，由中央數(shù)據(jù)接口實時接收來自不同產(chǎn)地和車間的檢測結(jié)果數(shù)據(jù)，并進(jìn)行結(jié)構(gòu)化解析存儲至該數(shù)據(jù)湖。

基于大量入湖的生產(chǎn)檢測數(shù)據(jù)，首先可實現(xiàn)對車間生產(chǎn)狀態(tài)實時監(jiān)控，包含EOL檢測的合格率及重點電器問題。

在電器問題解決方面，實現(xiàn)檢測方案數(shù)據(jù)、生產(chǎn)物流數(shù)據(jù)和檢測結(jié)果數(shù)據(jù)的一鍵協(xié)同獲取，通過開發(fā)智能算法及模型，對電器問題進(jìn)行智能的分析和定位，并計算給出可能的解決方案。將經(jīng)技術(shù)人員最終確定的問題原因和解決措施動態(tài)充實至專家問題庫，不斷優(yōu)化訓(xùn)練算法的分析準(zhǔn)確性。

4 結(jié)束語

車輛EOL檢測智能檢測方案依據(jù)汽車行業(yè)在電器領(lǐng)域的技術(shù)發(fā)展更新和工藝特點，以及結(jié)合EOL檢測的關(guān)鍵環(huán)節(jié)現(xiàn)狀，充分考慮汽車企業(yè)在數(shù)字化及診斷技術(shù)升級上的實際需求，通過針對性地設(shè)計數(shù)字化檢測方案設(shè)計、云端診斷、虛擬仿真驗證及智能數(shù)據(jù)分析關(guān)鍵功能模塊，并完成相應(yīng)地硬件及數(shù)字化系統(tǒng)開發(fā)。從而實現(xiàn)了從EOL方案設(shè)計、檢測實施、方案驗證到方案優(yōu)化整個閉環(huán)流程的數(shù)字化和技術(shù)升級，提升在生產(chǎn)過程中針對車輛電器檢測的工作效率和整車交付質(zhì)量，較好地應(yīng)對電動化、智能化及網(wǎng)聯(lián)化趨勢下車輛電器架構(gòu)復(fù)雜度提升在EOL檢測領(lǐng)域帶來的挑戰(zhàn)。

方案中所包含的檢測方案設(shè)計、云端檢測平臺建設(shè)、OBD插頭、車間生產(chǎn)狀態(tài)監(jiān)控及專家知識庫等內(nèi)容，具有顯著的汽車行業(yè)特色，具備在各主流主機(jī)廠商推廣的價值。