摘要： 在新能源商用車售后市場(chǎng)中，面對(duì)車輛故障而電控系統(tǒng)未能直接報(bào)出明確故障碼的情況，售后技術(shù)人員往往面臨診斷難題。對(duì)此，可以利用基于規(guī)則算法的新能源專家診斷系統(tǒng)。該系統(tǒng)能夠通過快速、高效的方式識(shí)別并定位故障原因，從而提高售后維修效率。系統(tǒng)內(nèi)不同組件協(xié)同工作，以多樣化的數(shù)據(jù)流傳輸方式，共同驅(qū)動(dòng)軟件功能，實(shí)現(xiàn)智能化故障診斷。

關(guān)鍵詞：專家診斷系統(tǒng)；數(shù)據(jù)驅(qū)動(dòng)；故障排查；云平臺(tái)

中圖分類號(hào)：U471 DOI ：10.20042/j.cnki.1009-4903.2024.03.005

0 引言

在當(dāng)今汽車行業(yè)電動(dòng)化、網(wǎng)聯(lián)化、智能化、共享化的新四化浪潮推動(dòng)下，汽車電子化程度持續(xù)攀升，汽車電子成本在整車成本中的占比日益增大。隨著汽車電子技術(shù)的廣泛應(yīng)用，汽車已逐步演變?yōu)橐粋€(gè)高度集成的復(fù)雜智能網(wǎng)絡(luò)系統(tǒng)，其技術(shù)含量與結(jié)構(gòu)復(fù)雜性均達(dá)到了前所未有的高度。

目前，汽車售后維修人員主要依賴專業(yè)的診斷工具及自身豐富的經(jīng)驗(yàn)來診斷車輛問題。各汽車制造商提供的診斷設(shè)備能夠通過OBD（ 車載診斷系統(tǒng)） 接口對(duì)整車進(jìn)行故障檢測(cè)，并根據(jù)檢測(cè)出的故障代碼提供可能的故障原因及相應(yīng)的處理方案。但當(dāng)車輛未報(bào)出明確的故障代碼時(shí)，售后人員就難以處理，尤其是在處理電子系統(tǒng)復(fù)雜且集成度高的新能源商用車時(shí)，情況尤為棘手。此時(shí)，售后人員往往只能記錄故障車輛的CAN（ 控制器局域網(wǎng)） 總線報(bào)文，并將其發(fā)送給制造商進(jìn)行分析，這一過程不僅耗時(shí)較長，還難以迅速、便捷地定位并解決車輛故障。

鑒于上述現(xiàn)狀，本文旨在開發(fā)一個(gè)基于規(guī)則算法的新能源專家診斷系統(tǒng)。該系統(tǒng)依托故障診斷專家建立的數(shù)據(jù)庫，驅(qū)動(dòng)診斷軟件的故障排查流程界面，實(shí)現(xiàn)自動(dòng)定位整車故障根源的功能，從而快速維修那些無故障碼但存在實(shí)際問題的車輛，顯著提升售后服務(wù)的效率與質(zhì)量。

1 系統(tǒng)數(shù)據(jù)傳遞

1.1 新能源專家診斷系統(tǒng)概述

新能源專家診斷系統(tǒng)由云平臺(tái)、Android 端軟件以及故障診斷專家3 部分組成，如圖1 所示。其中，故障診斷專家擁有豐富的故障處理經(jīng)驗(yàn)，熟悉控制器控制邏輯和車輛診斷技術(shù)，并具備良好的軟件編程能力。云平臺(tái)則負(fù)責(zé)數(shù)據(jù)錄入、存儲(chǔ)和推送。通過平臺(tái)的UI 界面，故障診斷專家能夠輕松輸入各類診斷數(shù)據(jù)，而云平臺(tái)則根據(jù)車輛診斷的實(shí)際需求，將對(duì)應(yīng)數(shù)據(jù)下發(fā)至Android 軟件。此外，云平臺(tái)還能確保數(shù)據(jù)傳輸過程中的安全性，保護(hù)用戶隱私不受侵犯。Android 端軟件則通過云平臺(tái)獲取最新、最準(zhǔn)確的診斷數(shù)據(jù)，并通過藍(lán)牙與車輛進(jìn)行通信。在接收到數(shù)據(jù)后，Android 端軟件能夠自動(dòng)運(yùn)行故障排查功能，通過智能算法與預(yù)設(shè)的故障排查流程，迅速定位故障源頭，為用戶提供及時(shí)有效的解決方案。

為了更直觀地展示新能源專家診斷系統(tǒng)中數(shù)據(jù)的流轉(zhuǎn)過程，我們繪制了如圖2 所示的數(shù)據(jù)流轉(zhuǎn)圖。該圖清晰地展示了數(shù)據(jù)從故障診斷專家通過云平臺(tái)輸入，到Android 端軟件獲取并解析，再到故障排查流程自動(dòng)執(zhí)行，并最終完成故障定位的整個(gè)周期。在這一過程中，數(shù)據(jù)始終在系統(tǒng)中保持活躍狀態(tài)，為系統(tǒng)的正常運(yùn)行提供著不可或缺的支持。

1.2 規(guī)范數(shù)據(jù)模板

故障排查模板的設(shè)計(jì)匯聚了售后服務(wù)站、診斷專家、Android 軟件開發(fā)人員、數(shù)據(jù)庫專家及UI 設(shè)計(jì)等各方意見，旨在滿足診斷專家的輸入要求，并方便維修人員的實(shí)際操作?；谠撃０澹琔I 設(shè)計(jì)師精心打造了故障輸入界面，數(shù)據(jù)庫專家則負(fù)責(zé)設(shè)計(jì)了高效的數(shù)據(jù)存儲(chǔ)方案。云平臺(tái)開發(fā)者則設(shè)計(jì)數(shù)據(jù)接口的輸入輸出參數(shù)并開發(fā)接口。最終，Android 端軟件開發(fā)人員通過解析JSON 數(shù)據(jù)，實(shí)現(xiàn)數(shù)據(jù)驅(qū)動(dòng)界面的功能，有效定位車輛故障源頭。

1.3 云平臺(tái)數(shù)據(jù)錄入與傳遞

云平臺(tái)的UI 輸入界面依托于Vue Next Admin 后臺(tái)管理模板開發(fā)而成，該模板基于Vue 3.x 構(gòu)建，融合了CompositionAPI setup 語法糖、TypeScript、Vite 構(gòu)建工具、Element PlusUI 組件庫、Vue Router Next 及Pinia 狀態(tài)管理等先進(jìn)技術(shù)，全面支持手機(jī)、平板及PC 等多種設(shè)備。云平臺(tái)UI 不僅實(shí)現(xiàn)了對(duì)用戶和角色的靈活管理，還提供了便捷的故障分類錄入功能，界面設(shè)計(jì)友好且具備響應(yīng)式布局，適配多種設(shè)備。

在數(shù)據(jù)存儲(chǔ)方面，云平臺(tái)采用了Spring Boot 框架，并集成了MongoDB、MySQL 及Redis 等多種數(shù)據(jù)庫技術(shù)，以構(gòu)建高效的后端系統(tǒng)。通過Spring Data MongoDB 和Spring DataJPA，系統(tǒng)能夠輕松實(shí)現(xiàn)與MongoDB 和MySQL數(shù)據(jù)庫的交互，確保數(shù)據(jù)的持久化與管理。同時(shí)，利用Spring Data Redis，系統(tǒng)有效利用了Redis 作為緩存和數(shù)據(jù)存儲(chǔ)介質(zhì)，顯著提升了系統(tǒng)的性能與響應(yīng)速度。這一系列技術(shù)的整合，使得云平臺(tái)能夠迅速完成數(shù)據(jù)的訪問、存儲(chǔ)與管理，為用戶帶來流暢、可靠的后端服務(wù)體驗(yàn)。

云平臺(tái)的發(fā)送與接收接口遵循前后端分離原則，后端采用Spring Boot 框架實(shí)現(xiàn)，這些接口全面覆蓋了故障數(shù)據(jù)的錄入、解析、處理、存儲(chǔ)及響應(yīng)等功能，確保了數(shù)據(jù)在云平臺(tái)與Android 端之間的順暢傳遞。

1.4 Android 端數(shù)據(jù)接收與處理

Android 端與云平臺(tái)的通信采用了CS 架構(gòu)開發(fā)模式。在這種模式下，業(yè)務(wù)邏輯與數(shù)據(jù)處理被明確分離：客戶（Android 端）負(fù)責(zé)接收數(shù)據(jù)和與終端用戶交互，而云平臺(tái)上的數(shù)據(jù)庫則負(fù)責(zé)處理并存儲(chǔ)數(shù)據(jù)。Android 端通過okhttp 框架向云平臺(tái)發(fā)送請(qǐng)求以獲取數(shù)據(jù)，并將數(shù)據(jù)處理功能封裝成軟件接口函數(shù)，這些函數(shù)既可供UI 界面調(diào)用，也可供業(yè)務(wù)邏輯模塊調(diào)用。這種設(shè)計(jì)實(shí)現(xiàn)了數(shù)據(jù)處理與業(yè)務(wù)邏輯的解耦，有效降低了系統(tǒng)的維護(hù)成本。

此外，Android 端軟件還通過診斷儀硬件與整車進(jìn)行通信，支持藍(lán)牙或Wi-Fi 2 種通信模式。為實(shí)現(xiàn)這一功能，需要制定診斷中間件SDK 包的接口，并編寫相應(yīng)的診斷協(xié)議棧，以確保通信的順暢與穩(wěn)定。

1.5 Android 端數(shù)據(jù)驅(qū)動(dòng)界面

Android 端軟件架構(gòu)選用了MVP（Model-View-Presenter）模式。在MVP 模式中，模型（Model） 負(fù)責(zé)處理數(shù)據(jù)的加載或存儲(chǔ)，視圖（ View） 負(fù)責(zé)界面的展示及與用戶的交互，而主持人（Presenter） 則負(fù)責(zé)協(xié)調(diào)模型與視圖之間的通信，并將它們分離開來。這種架構(gòu)使得代碼更加簡潔、清晰，便于開發(fā)與維護(hù)。

故障排查流程界面通過綁定自定義適配器，實(shí)現(xiàn)了界面內(nèi)容的動(dòng)態(tài)變化。界面上包含了ViewText、Button、ListView、ImageView 等多種控件，根據(jù)故障排查步驟的數(shù)據(jù)流動(dòng)態(tài)展示相應(yīng)的界面內(nèi)容。其中，界面數(shù)據(jù)的動(dòng)態(tài)實(shí)時(shí)顯示是通過Handler 與Message 機(jī)制的緊密配合實(shí)現(xiàn)的。Handler 負(fù)責(zé)發(fā)送與處理信息，而Message 則作為消息對(duì)象承載具體的數(shù)據(jù)內(nèi)容。這種機(jī)制確保了數(shù)據(jù)的實(shí)時(shí)可視化，使得界面切換更加流暢，避免了卡頓現(xiàn)象的發(fā)生。

對(duì)于界面更新的自動(dòng)與手動(dòng)功能，系統(tǒng)通過控制列表（list） 的序號(hào)來實(shí)現(xiàn)。當(dāng)序號(hào)有值且被傳遞給流程軟件時(shí)，界面將顯示對(duì)應(yīng)序號(hào)的內(nèi)容；若序號(hào)為空，則界面暫停更新。在自動(dòng)更新模式下，序號(hào)會(huì)自動(dòng)加一以顯示下一步內(nèi)容；而在手動(dòng)控制模式下，用戶可以通過操作觸發(fā)序號(hào)的增加或減少，從而實(shí)現(xiàn)界面的靈活跳轉(zhuǎn)。

2 實(shí)例

本文以新能源商用車中“驅(qū)動(dòng)限扭換擋無動(dòng)力故障”的排查流程為例進(jìn)行說明。基于控制器功能邏輯、維修經(jīng)驗(yàn)以及診斷功能，診斷專家精心設(shè)計(jì)了詳盡的故障排查流程步驟。這一流程必須全面覆蓋該故障可能涉及的所有問題原因，否則可能導(dǎo)致問題定位失敗或不準(zhǔn)確。流程步驟按照功能檢測(cè)的維度進(jìn)行劃分，每個(gè)功能檢測(cè)構(gòu)成一個(gè)獨(dú)立的步驟，而每個(gè)步驟內(nèi)部又進(jìn)一步細(xì)分為若干個(gè)小步驟，以便軟件能夠按照既定流程逐一完成監(jiān)測(cè)與分析工作。

在傳統(tǒng)模式下，面對(duì)這類邏輯復(fù)雜且不易直接報(bào)出故障碼的車輛問題，售后服務(wù)站智能采集車輛總線報(bào)文，并將其發(fā)送給車輛制造商，再由設(shè)計(jì)人員進(jìn)行分析，這一過程不僅耗時(shí)較長，而且效率低下。而采用本文所述的新能源專家診斷系統(tǒng)后，售后人員只需在Android 軟件中選擇相應(yīng)的故障類型，診斷軟件便能自動(dòng)從云平臺(tái)獲取“驅(qū)動(dòng)限扭換擋無動(dòng)力故障”對(duì)應(yīng)的排查流程，并自動(dòng)與車輛建立通信，自動(dòng)排查油門踏板信號(hào)、MaxPositivePwr 信號(hào)、配置字等關(guān)鍵數(shù)據(jù)，最終給出具體的故障原因判斷。

在圖3 所示的排查流程界面中，針對(duì)“驅(qū)動(dòng)限扭換擋無動(dòng)力故障”，系統(tǒng)成功排查出故障原因?yàn)椤坝烷T踏板異?！?，從而解釋了車輛無法行駛的問題所在。這一新的檢查方法不僅極大地節(jié)省了時(shí)間，還顯著提高了故障診斷的準(zhǔn)確性和效率。通過運(yùn)用先進(jìn)的技術(shù)和設(shè)備，車輛問題得以更快速地被發(fā)現(xiàn)和解決，有效縮短了車輛維修過程中的停車時(shí)間，降低了維修成本。此外，這種快速而準(zhǔn)確的檢查方法還有助于提升車輛的可靠性和安全性，以及車輛維修服務(wù)的質(zhì)量和效率，為車主帶來更好的駕駛體驗(yàn)。

3 結(jié)束語

本文所介紹的新能源專家診斷系統(tǒng)，以規(guī)則算法為核心，深度融合了數(shù)據(jù)驅(qū)動(dòng)的理念。通過不斷優(yōu)化Android 端軟件的故障排查流程界面，該系統(tǒng)實(shí)現(xiàn)了數(shù)據(jù)的高效獲取、精準(zhǔn)處理與實(shí)時(shí)動(dòng)態(tài)顯示，從而能夠迅速且準(zhǔn)確地定位故障問題的根源。在數(shù)據(jù)驅(qū)動(dòng)的軟件設(shè)計(jì)思想下，我們制定了規(guī)范的數(shù)據(jù)輸入模板，并嚴(yán)格確保了接口的安全性，確保了每一步排查步驟都能準(zhǔn)確無誤地執(zhí)行。不過，值得注意的是，由于不同車輛配置下的整車控制邏輯存在顯著差異，這直接導(dǎo)致了數(shù)據(jù)特性的多樣化。因此，對(duì)于該專家診斷系統(tǒng)而言，版本管理顯得尤為重要。此外，與傳統(tǒng)的維修方法相比，基于規(guī)則算法的專家診斷系統(tǒng)不僅操作更加便捷，問題定位更加精確無誤，而且在數(shù)據(jù)維護(hù)方面也更為方便高效。

參考文獻(xiàn)

[1]普華永道“.新四化”和全球低碳背景下，汽車產(chǎn)業(yè)鏈存在哪些挑戰(zhàn)？[J]，汽車與配件，2024（5） ：25.

[2] 張?jiān)迄i.基于數(shù)據(jù)驅(qū)動(dòng)的設(shè)備故障診斷技術(shù)[J]，機(jī)械工程與自動(dòng)化，2022（02）：130-132.

[3] 莊萌榕.數(shù)據(jù)驅(qū)動(dòng)的空調(diào)系統(tǒng)故障診斷算法綜述[J]，智能建筑，2024（01）：91-95.