基于CAN的混合協(xié)議解析軟件設(shè)計(jì)與實(shí)現(xiàn)

濰柴動力股份有限公司 王懷寬 劉月美 高國樑

串行通訊協(xié)議CAN在汽車電子中有著廣泛應(yīng)用，基于CAN總線的上層協(xié)議也非常多。隨著人們對汽車的要求的提升，控制策略也變得愈發(fā)復(fù)雜，外部工具要實(shí)現(xiàn)對ECU的訪問，需要使用多種協(xié)議才能完成。而對通信協(xié)議進(jìn)行解析通常存在耗費(fèi)時(shí)間長、錯誤率較高等問題。為解決這些問題，解析出工程師更易于理解的序列說明，本文設(shè)計(jì)并實(shí)現(xiàn)了基于CAN的混合協(xié)議解析軟件。軟件實(shí)時(shí)接收CAN報(bào)文序列，并進(jìn)行實(shí)時(shí)的解析，同時(shí)能夠根據(jù)自定義關(guān)注點(diǎn)數(shù)據(jù)庫，自動匹配目標(biāo)序列。經(jīng)測試，該軟件可以準(zhǔn)確解析出協(xié)議內(nèi)容，滿足實(shí)際的應(yīng)用需求。

當(dāng)今時(shí)代，人們對汽車的要求越來越高，這大大推動了汽車電子技術(shù)的發(fā)展，使得汽車電子逐步成為汽車各方面性能提升和功能擴(kuò)展的關(guān)鍵技術(shù)支撐。在汽車電子中，CAN （Controller Area Network，控制器局域網(wǎng)）總線有著廣泛的應(yīng)用，但是CAN本身并不完整，它只定義了物理層和數(shù)據(jù)鏈路層，而沒有定義應(yīng)用層，因此出現(xiàn)了許多基于CAN總線的上層協(xié)議，如常見的XCP（Universal Measurement and Calibration Protocol，通用測量標(biāo)定協(xié)議）、CCP（CAN Calibration Protocol，CAN標(biāo)定協(xié)議）、UDSonCAN（Unified Diagnostic Services on CAN，統(tǒng)一診斷協(xié)議在CAN上的實(shí)現(xiàn)）以及SAE J1939（美國汽車工程協(xié)會規(guī)定的整車通訊協(xié)議）等。

隨著功能需求的不斷增加，發(fā)動機(jī)策略變得日益復(fù)雜，外部工具對汽車電子控制系統(tǒng)的核心ECU的訪問往往需要使用多種通信協(xié)議才能實(shí)現(xiàn)。而對協(xié)議進(jìn)行解析，需要耗費(fèi)大量的時(shí)間并且錯誤率較高。

為了解決上述的問題，提升工程師的工作效率，本文設(shè)計(jì)實(shí)現(xiàn)了基于CAN的混合協(xié)議解析軟件CANHPA（CAN Hybrid Protocol Analysis）。該軟件可用于對外部工具進(jìn)行監(jiān)控，按照時(shí)間序列、上層類型對ECU所做的所有處理進(jìn)行解析。

1 CAN總線協(xié)議概述

CAN為串行通訊協(xié)議，能夠有效地支持具有很高安全等級的分布式實(shí)時(shí)控制。如圖1所示，根據(jù)ISO/OSI參考模型，CAN被分為物理層和數(shù)據(jù)鏈路層兩個(gè)層級，其中數(shù)據(jù)鏈路層又被細(xì)分為邏輯鏈路控制子層（LLC）和媒體訪問控制子層（MAC）。各個(gè)層的主要作用如下。

圖1 CAN結(jié)構(gòu)Fig.1 CAN structure

（1）邏輯鏈路控制子層：報(bào)文濾波、過載通知、恢復(fù)管理；

（2）媒體訪問控制子層：報(bào)文分幀、仲裁、應(yīng)答、錯誤檢測和標(biāo)定；

（3）物理層：在不同節(jié)點(diǎn)之間根據(jù)所有的電氣屬性進(jìn)行位的實(shí)際傳輸。

CAN報(bào)文的傳輸涉及四種不同的幀類型，分別是數(shù)據(jù)幀、遠(yuǎn)程幀、錯誤幀以及過載幀。

2 需求分析

軟件的需求分析關(guān)乎軟件開發(fā)的成敗甚至是最終的產(chǎn)品質(zhì)量，是開發(fā)工作的基礎(chǔ)。根據(jù)實(shí)際的業(yè)務(wù)需求，分析出基于CAN的混合協(xié)議解析軟件應(yīng)具備協(xié)議接收、協(xié)議存儲、協(xié)議解析等功能。此外，軟件還需要滿足一定的非功能性需求，如安全性、魯棒性、可擴(kuò)展性等。

CANHPA的基本流程圖如圖2所示。軟件首先初始化各個(gè)數(shù)據(jù)庫。點(diǎn)擊啟動后，軟件開始接收報(bào)文并將接收到的原始報(bào)文存儲在數(shù)據(jù)庫中以備后續(xù)使用。在存儲報(bào)文的同時(shí)，軟件根據(jù)CAN ID得出報(bào)文的協(xié)議類型，對于CANPHA不支持的協(xié)議類型，直接以原始報(bào)文的形式的呈現(xiàn)給用戶；對于軟件所支持的協(xié)議類型，CANPHA將該協(xié)議依據(jù)對應(yīng)的描述文件解析出物理含義。接下來CANPHA讀取高級翻譯數(shù)據(jù)庫對類型受支持的協(xié)議進(jìn)行更進(jìn)一步的解析。若設(shè)置了自定義關(guān)注數(shù)據(jù)庫，則根據(jù)設(shè)置匹配總線報(bào)文，若匹配成功，則輸出匹配一致。

圖2 CANPHA基本流程圖Fig.2 CANPHA basic flow diagram

3 軟件設(shè)計(jì)與實(shí)現(xiàn)

3.1 總體設(shè)計(jì)

CANHPA使用分層模式，軟件整體由數(shù)據(jù)層、業(yè)務(wù)層和展示層構(gòu)成。軟件的架構(gòu)圖如圖3所示。

圖3 CANHPA架構(gòu)圖Fig.3 CANHPA architecture diagram

（1）數(shù)據(jù)層：數(shù)據(jù)層負(fù)責(zé)存儲實(shí)際業(yè)務(wù)數(shù)據(jù)以及軟件接收到的原始報(bào)文數(shù)據(jù)，同時(shí)還提供ECU中程序描述文件的存儲服務(wù)，例如CCP/XCP對應(yīng)的A2L文件、UDS對應(yīng)的ODX文件、SAE J1939對應(yīng)的DBC文件等。

（2）業(yè)務(wù)層：業(yè)務(wù)層實(shí)現(xiàn)軟件具體的業(yè)務(wù)邏輯。CANHPA預(yù)先加載對應(yīng)ECU中程序的各種數(shù)據(jù)庫文件，當(dāng)CAN總線打開時(shí)，軟件接收報(bào)文序列，然后與預(yù)設(shè)的內(nèi)容進(jìn)行匹配，若匹配成功，則輸出經(jīng)過解析的報(bào)文；若匹配失敗，則以原始報(bào)文數(shù)據(jù)的形式輸出。

（3）展示層：展示層用于將解析后的報(bào)文信息展示給軟件用戶，該層主要依托HTML、JavaScript、CSS等技術(shù)進(jìn)行實(shí)現(xiàn)。用戶根據(jù)具體場景，可選擇按照協(xié)議類型或者接收時(shí)間顯示解析結(jié)果。

3.2 主要功能詳細(xì)設(shè)計(jì)與實(shí)現(xiàn)

在軟件的開發(fā)過程中，選用Spring Boot框架實(shí)現(xiàn)CANPHA的具體業(yè)務(wù)功能。Spring Boot 繼承了Spring 框架的優(yōu)點(diǎn)，并且能夠根據(jù)項(xiàng)目依賴進(jìn)行自動配置，可以在很大程度上簡化軟件的開發(fā)過程。

CANPHA使用Packet這一核心類來定義協(xié)議的數(shù)據(jù)包，它包含ID、Length、Data等屬性。CCPPacket、UDS Packet等描述已知類型的協(xié)議的類通過繼承Packet得到。CANHPA主要功能如圖4所示。

圖4 CANHPA主要功能Fig.4 CANHPA main functions

ASAM MCD-2 MC定義了用于測量和標(biāo)定的內(nèi)部ECU變量的描述格式，A2L文件是ASAM MCD-2 MC標(biāo)準(zhǔn)的表現(xiàn)形式。測量和標(biāo)定系統(tǒng)需要A2L描述文件調(diào)整ECU軟件的標(biāo)量常數(shù)、曲線和映射，并在實(shí)時(shí)測試期間通過測量變量記錄系統(tǒng)的響應(yīng)。該描述包含ECU變量的數(shù)據(jù)類型、維度，布局和存儲位置的信息，并進(jìn)一步描述了如何將變量值轉(zhuǎn)換為易于理解的物理量，從而可以在MC系統(tǒng)中直觀地顯示。

DBC文件描述了單個(gè)CAN網(wǎng)絡(luò)的通信。這些信息可以用來監(jiān)視以及分析網(wǎng)絡(luò)，也可以用來模擬CAN節(jié)點(diǎn)，此外，DBC文件還可用于開發(fā)電控單元的通信軟件。描述CAN網(wǎng)絡(luò)基本通信的DBC文件包含bit_timing、Nodes和Messages等部分，其中bit_timing是必須的但通常留空，CAN網(wǎng)絡(luò)的波特率和BTR寄存器設(shè)置在此部分定義；Nodes也是必須的，該部分用于定義網(wǎng)絡(luò)節(jié)點(diǎn)，節(jié)點(diǎn)名需唯一；Messages用于定義消息和信號。

ODX（Open Diagnostic Data Exchange）標(biāo)準(zhǔn)定義了一個(gè)數(shù)據(jù)模型，用于描述ECU從開發(fā)、測試、生產(chǎn)到售后和服務(wù)的整個(gè)生命周期所需的診斷能力。ODX將診斷數(shù)據(jù)存儲在一個(gè)中心位置，ODX以XML格式將數(shù)據(jù)進(jìn)行序列化。該標(biāo)準(zhǔn)統(tǒng)一了診斷文件的格式，使得ECU所有開發(fā)階段的診斷數(shù)據(jù)可以完全復(fù)用，例如診斷通信的設(shè)計(jì)、ECU內(nèi)核和應(yīng)用軟件的開發(fā)、診斷測試設(shè)備的配置以及車輛診斷文檔的生成，促進(jìn)了開發(fā)過程中合作伙伴之間的診斷信息交換。

AcquisitionService類的getMessage方法實(shí)現(xiàn)了CAN總線上報(bào)文的實(shí)時(shí)接收。報(bào)文輸入到軟件中時(shí)，調(diào)用AnalysisService類的Analyse方法對報(bào)文進(jìn)行初步解析，該方法返回協(xié)議的類型，如果該協(xié)議是CANHPA暫不支持的類型，則使用WebSocket協(xié)議將原始報(bào)文推送給前端進(jìn)行顯示；如果該協(xié)議是CANHPA支持的類型，則調(diào)用對應(yīng)的解析方法對協(xié)議繼續(xù)進(jìn)行解析，并將最終的解析結(jié)果反饋給軟件前端界面。

4 結(jié)語

本文針對CAN協(xié)議，設(shè)計(jì)并實(shí)現(xiàn)了基于CAN的混合協(xié)議解析軟件CANHPA。軟件能夠根據(jù)自定義關(guān)注點(diǎn)數(shù)據(jù)庫，自動匹配目標(biāo)序列，并將解析出的協(xié)議內(nèi)容按照更易于理解的方式顯示。測試結(jié)果表明，CANHPA能夠準(zhǔn)確地解析出協(xié)議的內(nèi)容，提升工程師的工作效率，滿足了實(shí)際工作的需求。