基于規(guī)則算法的新能源專家診斷系統(tǒng)

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

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

中圖分類號：U471 DOI ：10.20042/j.cnki.1009-4903.2024.03.005

0 引言

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2 實例

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

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

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

3 結(jié)束語

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

參考文獻

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

[2] 張云鵬.基于數(shù)據(jù)驅(qū)動的設備故障診斷技術(shù)[J]，機械工程與自動化，2022（02）：130-132.

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