郭健忠 ，胡文龍 ，謝斌 ，閔銳 ，杜新寶 ，王迅

(1.武漢科技大學(xué)汽車(chē)與交通工程學(xué)院,湖北 武漢 430065；2.武漢保華顯示科技有限公司,湖北 武漢 430082)

隨著汽車(chē)智能化的到來(lái),汽車(chē)功能不斷豐富,車(chē)上控制器的數(shù)量也隨之增多。作為汽車(chē)控制器之間的主要通訊網(wǎng)絡(luò),CAN(Controller Area Network)總線上的信息交互愈加頻繁,需要解析處理的CAN 報(bào)文信息也越來(lái)越多[1-4]。面對(duì)逐漸增多的CAN 報(bào)文信息,采用單報(bào)文逐一解析的傳統(tǒng)解析方式出現(xiàn)了一系列的問(wèn)題,例如,由于CAN 報(bào)文數(shù)據(jù)增多而導(dǎo)致的解析代碼量大、解析框架復(fù)雜、可移植性差、穩(wěn)定性不高等一系列缺點(diǎn)[5-6],直接增加了汽車(chē)儀表的開(kāi)發(fā)周期,并降低了汽車(chē)儀表數(shù)據(jù)顯示的準(zhǔn)確性,可能導(dǎo)致最終開(kāi)發(fā)產(chǎn)品的質(zhì)量不達(dá)標(biāo)。因此,傳統(tǒng)CAN 報(bào)文信息解析的方式逐漸滿(mǎn)足不了當(dāng)前的產(chǎn)品開(kāi)發(fā)需求,有必要設(shè)計(jì)出一種針對(duì)大量CAN 報(bào)文信息的解析方式。

1 CAN 報(bào)文解析現(xiàn)狀分析

1.1 CAN 報(bào)文形式

在對(duì)CAN 報(bào)文信息進(jìn)行解析時(shí),通常是對(duì)數(shù)據(jù)幀中所包含的數(shù)據(jù)段進(jìn)行解析。數(shù)據(jù)幀具有兩種格式,即標(biāo)準(zhǔn)幀格式和擴(kuò)展幀格式。兩種數(shù)據(jù)幀格式主要區(qū)別在于標(biāo)識(shí)符的長(zhǎng)度不同,標(biāo)準(zhǔn)幀標(biāo)識(shí)符為11 位,擴(kuò)展幀標(biāo)識(shí)符為29 位,因此,與標(biāo)準(zhǔn)幀相比,擴(kuò)展幀可以擴(kuò)展更多的CAN 節(jié)點(diǎn),更好地支持上層協(xié)議[7-8]。在數(shù)據(jù)解析方面,兩種幀格式并無(wú)較大差別。由于商用車(chē)ECU 所需傳輸信息較多,CAN 報(bào)文多用擴(kuò)展幀,乘用車(chē)多用標(biāo)準(zhǔn)幀。

1.2 CAN 報(bào)文解析現(xiàn)狀

傳統(tǒng)CAN 報(bào)文解析采用單個(gè)報(bào)文依次解析的方式。其解析過(guò)程主要包括報(bào)文名稱(chēng)定義、報(bào)文接收郵箱配置、報(bào)文丟失信息處理和報(bào)文信息解析四個(gè)步驟[9-11]。汽車(chē)儀表,作為主要的CAN 數(shù)據(jù)收發(fā)設(shè)備,其CAN 報(bào)文解析的具體流程如圖1 所示。

圖1 CAN 單報(bào)文解析流程圖

在新款汽車(chē)的研發(fā)過(guò)程中,ECU 的品牌往往具有多個(gè)選擇。因此,為提升汽車(chē)儀表對(duì)不同ECU 品牌間數(shù)據(jù)傳遞的兼容性,通常需對(duì)多種品牌ECU 的CAN 報(bào)文進(jìn)行解析,所以在報(bào)文名稱(chēng)定義時(shí),需考慮多個(gè)ECU 品牌,并分品牌進(jìn)行定義。在配置接收郵箱時(shí),由于接收郵箱數(shù)目有限,會(huì)添加標(biāo)識(shí)符過(guò)濾處理,即通過(guò)相應(yīng)掩碼操作將不同報(bào)文信息同時(shí)存入同一郵箱中[12-14]。報(bào)文丟失信息處理是當(dāng)ECU故障未發(fā)送報(bào)文或報(bào)文丟幀過(guò)多而造成的信息丟失時(shí)所做出的應(yīng)急處理。報(bào)文信息解析即對(duì)報(bào)文數(shù)據(jù)中包含的ECU 工況信息進(jìn)行相應(yīng)代碼編寫(xiě)。

在傳統(tǒng)CAN 報(bào)文解析過(guò)程中,通常按照?qǐng)D1 所示流程進(jìn)行單個(gè)報(bào)文逐一解析,解析工作量大,所需解析的時(shí)間成本較高。若接收郵箱數(shù)目不足,涉及過(guò)濾處理時(shí),解析代碼結(jié)構(gòu)框架將變得復(fù)雜,解析過(guò)程易出錯(cuò),整體項(xiàng)目工程的穩(wěn)定性和可移植性將會(huì)降低。因此,傳統(tǒng)CAN 報(bào)文解析方式逐漸滿(mǎn)足不了當(dāng)前汽車(chē)儀表的開(kāi)發(fā)需求。

2 相似性原理解析策略

基于相似性原理對(duì)報(bào)文的解析代碼進(jìn)行分析,將其解析代碼中的相似邏輯結(jié)構(gòu)、相似報(bào)文ID 定義等相似結(jié)構(gòu)提取出來(lái)[15],按照開(kāi)發(fā)者的解析要求進(jìn)行代碼框架的自動(dòng)生成,所生成的解析代碼框架可直接導(dǎo)入整體軟件的開(kāi)發(fā)工程中使用。根據(jù)CAN單報(bào)文解析流程可知,進(jìn)行單報(bào)文解析時(shí),以下三步解析操作相似度較高:

①在參照功能規(guī)范編寫(xiě)解析代碼之前,需要在接收郵箱結(jié)構(gòu)體中添加該報(bào)文ID(若接收郵箱已存滿(mǎn)報(bào)文信息,則需要進(jìn)行掩碼操作)。

②在參照功能規(guī)范編寫(xiě)解析代碼之前,還需在報(bào)文丟失處理的枚舉結(jié)構(gòu)中添加枚舉定義。

③在參照功能規(guī)范編寫(xiě)解析代碼時(shí),為實(shí)時(shí)接收來(lái)自接收郵箱中的報(bào)文信息,進(jìn)行報(bào)文解析,需先構(gòu)建相應(yīng)報(bào)文的接收代碼框架,即接收條件語(yǔ)句(若包含掩碼操作,則需在接收條件語(yǔ)句中進(jìn)一步判斷)。

以某商用車(chē)儀表開(kāi)發(fā)中不同型號(hào)發(fā)動(dòng)機(jī)CAN報(bào)文解析為例,相似接收郵箱結(jié)構(gòu)體代碼框架如下。在接收郵箱結(jié)構(gòu)體代碼框架中,結(jié)構(gòu)體的名稱(chēng)可自定義。所接收的報(bào)文信息存儲(chǔ)在相應(yīng)的結(jié)構(gòu)體數(shù)組中,數(shù)組成員具體包括郵箱序號(hào)、報(bào)文幀類(lèi)別、所存儲(chǔ)報(bào)文的ID 和過(guò)濾處理,其中郵箱序號(hào)前綴信息和報(bào)文幀類(lèi)別均可自定義,結(jié)構(gòu)體數(shù)組最多不超過(guò)32 個(gè)。

相似枚舉結(jié)構(gòu)如下所示。在報(bào)文丟失處理枚舉結(jié)構(gòu)中,枚舉名稱(chēng)可按報(bào)文對(duì)應(yīng)的ECU 名稱(chēng)進(jìn)行自定義,枚舉成員在能體現(xiàn)報(bào)文對(duì)應(yīng)ID 的前提下也可進(jìn)行自定義。

相似CAN 報(bào)文解析代碼框架如下所示。在CAN 報(bào)文解析時(shí),對(duì)接收郵箱僅存單一報(bào)文的解析代碼框架,僅需通過(guò)一個(gè)接收條件語(yǔ)句即可達(dá)到實(shí)時(shí)接收?qǐng)?bào)文效果,之后在條件語(yǔ)句中參照功能規(guī)范內(nèi)容進(jìn)行報(bào)文信息解析。若有掩碼操作,則先處理接收郵箱整體報(bào)文的接收條件語(yǔ)句,再進(jìn)一步對(duì)內(nèi)部條件語(yǔ)句進(jìn)行逐一處理[16]。參照功能規(guī)范所做的功能解析在內(nèi)部條件語(yǔ)句中進(jìn)行。在帶有掩碼處理的兩幀報(bào)文解析代碼框架中,含有掩碼操作的報(bào)文解析框架可根據(jù)掩碼需要,進(jìn)行多個(gè)子報(bào)文接收條件語(yǔ)句的解析操作。

根據(jù)以上分析可知,可利用相似性原理,對(duì)CAN 報(bào)文解析代碼中的枚舉結(jié)構(gòu)、接收郵箱結(jié)構(gòu)體以及相似的代碼解析框架進(jìn)行同時(shí)解析,相比傳統(tǒng)的CAN 報(bào)文解析策略,基于相似性原理的報(bào)文解析具有解析時(shí)間成本低、代碼結(jié)構(gòu)可視性更高、解析出錯(cuò)率更低的優(yōu)點(diǎn)。為實(shí)現(xiàn)該解析策略,設(shè)計(jì)了一種CAN 報(bào)文解析輔助軟件,用于提高開(kāi)發(fā)者的報(bào)文解析效率。

3 輔助軟件設(shè)計(jì)

3.1 輔助軟件總體框架

根據(jù)CAN 報(bào)文解析相似邏輯結(jié)構(gòu)分析可知,該輔助軟件需要設(shè)計(jì)獲取CAN 報(bào)文基本信息以及掩碼信息的輸入模塊,其中CAN 報(bào)文基本信息包括CAN 報(bào)文類(lèi)型、ID、功能備注等；掩碼信息包括掩碼報(bào)文類(lèi)型、主ID、子ID 等。還需設(shè)計(jì)生成相似解析代碼文件的輸出模塊,生成文件中包括枚舉結(jié)構(gòu)文件、接收郵箱文件和代碼解析文件。為檢測(cè)所獲取CAN 報(bào)文基本信息的準(zhǔn)確性,并使得軟件使用者對(duì)所獲取信息有整體認(rèn)知,需設(shè)計(jì)基本信息顯示模塊。為方便軟件使用者對(duì)生成代碼框架,以及生成文件格式的自定義,還需設(shè)計(jì)用戶(hù)自定義配置模塊。輔助軟件總體設(shè)計(jì)框架如圖2 所示。

圖2 軟件總體設(shè)計(jì)框架圖

3.2 軟件開(kāi)發(fā)環(huán)境選擇

在對(duì)一款功能性軟件的開(kāi)發(fā)過(guò)程中,往往需要通過(guò)對(duì)其功能需求進(jìn)行分析,選擇恰當(dāng)?shù)拈_(kāi)發(fā)語(yǔ)言及編譯環(huán)境,利用開(kāi)發(fā)語(yǔ)言及其編譯環(huán)境的優(yōu)點(diǎn),來(lái)簡(jiǎn)化開(kāi)發(fā)過(guò)程,提高軟件的開(kāi)發(fā)效率。通過(guò)對(duì)軟件的設(shè)計(jì)思路分析可知,在獲取CAN 報(bào)文基本信息時(shí),涉及相應(yīng)信息的分類(lèi)存儲(chǔ)及輸出,以及需設(shè)計(jì)用戶(hù)可自定義配置的UI 界面。

C＃語(yǔ)言是一種面向?qū)ο蟮木幊陶Z(yǔ)言,可按開(kāi)發(fā)者意愿,對(duì)不同對(duì)象信息進(jìn)行類(lèi)定義,并可按類(lèi)定義進(jìn)行數(shù)據(jù)的存儲(chǔ),其編譯環(huán)境Visual Studio 中強(qiáng)大的Windows 窗體應(yīng)用(.NET Framework)工作臺(tái),可進(jìn)行可視化的圖形交互界面開(kāi)發(fā),諸多窗體類(lèi)型以及公共控件為軟件的UI 界面設(shè)計(jì)提供了操作上的便捷[17-18]。因此,為了滿(mǎn)足所需的功能,本文采用C＃語(yǔ)言在Visual Studio 中的Windows 窗體應(yīng)用工作臺(tái)上進(jìn)行輔助軟件的開(kāi)發(fā)。

3.3 輸入模塊設(shè)計(jì)

在獲取CAN 報(bào)文基本信息以及掩碼信息時(shí),為便于所需信息的提取,需制定相應(yīng)的信息填寫(xiě)規(guī)范。CAN 報(bào)文基本信息填寫(xiě)規(guī)范如表1 所示,其中包含生成相似代碼所需的CAN 報(bào)文ID、周期和報(bào)文類(lèi)型三點(diǎn)必須信息,以及報(bào)文信息備注選填信息。掩碼信息填寫(xiě)規(guī)范如表2 所示,其中包含生成掩碼所需的報(bào)文類(lèi)型以及軟件使用者指定的主ID 和子ID?？紤]到所提取信息量較大,為降低解析信息文件工作難度,故輸入文件均采用Excel 表格中以逗號(hào)進(jìn)行信息分割的.CSV 文件格式。

表1 CAN 報(bào)文基本信息填寫(xiě)規(guī)范

表2 接收郵箱掩碼添加規(guī)范

對(duì)于輸入文件中的信息提取過(guò)程設(shè)計(jì),Visual Studio 中的Windows 窗體應(yīng)用工作臺(tái)為開(kāi)發(fā)者提供了可視化的開(kāi)發(fā)環(huán)境。以CAN 報(bào)文基本信息的提取為例,可視化開(kāi)發(fā)過(guò)程如圖3 所示。點(diǎn)擊“打開(kāi)指定CSV 文件”的button 控件,即可觸發(fā)打開(kāi)指定CSV 文件的操作,并將其文件地址返回至textbox 控件進(jìn)行地址顯示。通過(guò)對(duì)CAN 報(bào)文基本信息的分析,構(gòu)建相應(yīng)類(lèi)結(jié)構(gòu)和列表結(jié)構(gòu),并將其信息分類(lèi)存儲(chǔ)在列表中,供其他功能模塊調(diào)用,列表存儲(chǔ)過(guò)程如圖4 所示。

圖3 文件信息提取可視化開(kāi)發(fā)

圖4 列表結(jié)構(gòu)數(shù)據(jù)存儲(chǔ)過(guò)程

3.4 自定義配置模塊

在不同的項(xiàng)目開(kāi)發(fā)中,開(kāi)發(fā)者所使用的開(kāi)發(fā)環(huán)境以及所需解析的CAN 報(bào)文類(lèi)型也會(huì)有所不同,為提高輔助軟件開(kāi)發(fā)環(huán)境的兼容性,需在一定程度上實(shí)現(xiàn)軟件使用者對(duì)生成解析文件的自定義。在生成解析代碼框架方面,根據(jù)CAN 報(bào)文解析相似邏輯結(jié)構(gòu)分析可知,可對(duì)其解析報(bào)文種類(lèi)、接收郵箱結(jié)構(gòu)體名稱(chēng)、郵箱數(shù)目、報(bào)文丟失處理枚舉結(jié)構(gòu)名稱(chēng)和解析條件判斷語(yǔ)句五個(gè)方面進(jìn)行自定義,同時(shí)解析過(guò)程中涉及到的狀態(tài)變量名稱(chēng)也可進(jìn)行自定義；在生成文件方面,可按開(kāi)發(fā)者需求,對(duì)生成的文件格式進(jìn)行自定義,以便導(dǎo)入不同的開(kāi)發(fā)環(huán)境。其自定義界面初步設(shè)計(jì)如圖5 所示。

圖5 自定義配置界面

3.5 掩碼生成運(yùn)算

通過(guò)輸入模塊對(duì)掩碼信息文件進(jìn)行提取之后,軟件使用者指定掩碼操作的報(bào)文主ID 和子ID 已對(duì)應(yīng)存入數(shù)據(jù)列表中,供生成掩碼調(diào)用。在對(duì)CAN 報(bào)文主ID 和子ID 進(jìn)行過(guò)濾生成掩碼時(shí),通常采用同或運(yùn)算,其運(yùn)算邏輯如表3 所示。

表3 同或運(yùn)算真值表

在對(duì)掩碼進(jìn)行運(yùn)算時(shí),首先將數(shù)據(jù)列表中存儲(chǔ)的每組報(bào)文十六進(jìn)制的主ID 與子ID 進(jìn)行遍歷對(duì)比,得到數(shù)值不同的位。接著將這些不同位上的數(shù)值進(jìn)行二進(jìn)制轉(zhuǎn)換,并分別進(jìn)行同或邏輯運(yùn)算,得到不同位的掩碼值。最后將掩碼值轉(zhuǎn)換為十六進(jìn)制,并添加上相同位的掩碼值即可得到十六進(jìn)制掩碼。以某汽車(chē)儀表開(kāi)發(fā)中發(fā)動(dòng)機(jī)PTO 指示燈報(bào)文(ID:18FEF100) 和緩速器故障指示燈報(bào)文(ID:18FEF500)為例,掩碼運(yùn)算過(guò)程如圖6 所示。

圖6 掩碼運(yùn)算過(guò)程示意圖

3.6 軟件UI 界面設(shè)計(jì)

本文采用C＃語(yǔ)言在Visual Studio 中的Windows窗體應(yīng)用工作臺(tái)上進(jìn)行輔助軟件的開(kāi)發(fā),開(kāi)發(fā)過(guò)程中主要涉及兩個(gè)界面,一是軟件UI 設(shè)計(jì)界面,二是程序編輯界面,兩個(gè)界面相互配合使用,實(shí)現(xiàn)了軟件開(kāi)發(fā)的可視化。其UI 設(shè)計(jì)界面的工具箱模塊中包含了大量便捷的控件、組件等工具,使用時(shí),僅需在工具箱中點(diǎn)擊相應(yīng)工具名稱(chēng),之后可隨意且多次地拖動(dòng)到設(shè)計(jì)界面的任何位置,以滿(mǎn)足界面的設(shè)計(jì)需求。雙擊設(shè)計(jì)界面上相應(yīng)的圖標(biāo)即可索引到對(duì)應(yīng)程序編輯界面中的指定功能函數(shù)位置,便于功能代碼的編輯。以“生成文件”的button 按鈕為例,其UI設(shè)計(jì)流程如圖7 所示。

圖7 button 組件UI 設(shè)計(jì)流程圖

參照button 組件的設(shè)計(jì)方法,類(lèi)似地可設(shè)計(jì)出其他相應(yīng)功能的組件UI,最終,本文使用C＃語(yǔ)言在Visual Studio 中的Windows 窗體應(yīng)用工作臺(tái)開(kāi)發(fā)的輔助軟件UI 界面效果如圖8 所示。

圖8 輔助軟件UI 設(shè)計(jì)效果圖

4 輔助軟件測(cè)試分析

4.1 測(cè)試項(xiàng)目背景

在完成CAN 報(bào)文解析輔助軟件的設(shè)計(jì)之后,為驗(yàn)證其可在開(kāi)發(fā)工程項(xiàng)目的使用中達(dá)到預(yù)期設(shè)計(jì)效果,本文以某商用車(chē)汽車(chē)儀表(如圖9 所示)開(kāi)發(fā)中CAN 報(bào)文解析模塊為例。該商用車(chē)儀表預(yù)期設(shè)計(jì)可兼容六個(gè)品牌ECU,具體報(bào)文信息如表4 所示。在CAN 信號(hào)輸入方面,項(xiàng)目采用Kvaser 測(cè)試儀與BUSMASTER 測(cè)試軟件配合使用,對(duì)儀表進(jìn)行CAN信號(hào)的模擬發(fā)送。

圖9 商用車(chē)儀表實(shí)測(cè)圖

4.2 輔助軟件功能測(cè)試

由表4 可知,某商用車(chē)儀表兼容品牌YC 的ECU 共有32 條CAN 報(bào)文信息,項(xiàng)目開(kāi)發(fā)指定郵箱數(shù)目為20。輔助軟件功能測(cè)試以品牌YC 中發(fā)動(dòng)機(jī)PTO 指示燈報(bào)文(ID:18FEF100)和緩速器故障指示燈報(bào)文(ID:18FEF500)解析為例(前者為主ID,后者為子ID)。按圖10 所示流程進(jìn)行解析。首先將Kvaser 測(cè)試儀與BUSMASTER 軟件連接,搭建CAN報(bào)文模擬發(fā)送平臺(tái)[19]；接著導(dǎo)入輔助軟件生成的YC 品牌報(bào)文解析代碼文件,并按照功能規(guī)范進(jìn)行代碼解析；之后在BUSMASTER 軟件中配置PTO 指示燈報(bào)文和緩速器故障指示燈報(bào)文顯示信息；最后通過(guò)工程仿真驗(yàn)證所生成的解析框架能否接收到CAN 報(bào)文信息,仿真結(jié)果及儀表指示燈顯示如圖11、圖12 所示。

表4 某商用車(chē)儀表所兼容ECU 品牌的報(bào)文信息

圖10 輔助軟件測(cè)試流程圖

圖11 報(bào)文接收工程仿真

圖12 CAN 報(bào)文信息發(fā)送前后儀表狀態(tài)對(duì)比

通過(guò)以上測(cè)試結(jié)果可以看出,使用CAN 報(bào)文輔助軟件生成的含有掩碼操作的解析文件可直接導(dǎo)入項(xiàng)目工程中進(jìn)行使用,并且能夠獲得正確功能效果。

4.3 軟件生成代碼效率分析

參照4.2 所示測(cè)試流程,對(duì)與該商用車(chē)儀表兼容的其他五個(gè)品牌的ECU 報(bào)文分別進(jìn)行解析。若將解析郵箱結(jié)構(gòu)體內(nèi)的1 個(gè)數(shù)組、解析代碼框架中的1 個(gè)條件語(yǔ)句和1 個(gè)變量處理語(yǔ)句均定義為1 個(gè)解析復(fù)雜度,則對(duì)該儀表開(kāi)發(fā)解析6 個(gè)品牌ECU 報(bào)文信息,其傳統(tǒng)解析策略與基于相似性原理的解析策略解析復(fù)雜度對(duì)比如表5 所示。其中,相似性原理解析復(fù)雜度僅需計(jì)算自定義模板的復(fù)雜度,其他解析內(nèi)容按模板自動(dòng)生成,即模板的復(fù)雜度為11；傳統(tǒng)解析復(fù)雜度為:郵箱數(shù)目＋報(bào)文數(shù)目*3＋掩碼郵箱數(shù)目。

經(jīng)對(duì)比可知,使用基于相似性原理設(shè)計(jì)的CAN報(bào)文解析輔助軟件解析報(bào)文,平均每個(gè)ECU 品牌報(bào)文解析的復(fù)雜度縮減為傳統(tǒng)解析策略的8.8%,且省去掩碼計(jì)算過(guò)程,極大地節(jié)省了解析報(bào)文所需的時(shí)間成本,并提升了整體解析代碼框架的穩(wěn)定性。

5 結(jié)束語(yǔ)

本文根據(jù)相似性原理,結(jié)合CAN 報(bào)文解析代碼編寫(xiě)的結(jié)構(gòu)相似特點(diǎn),提出了基于相似性原理的CAN 報(bào)文解析策略,并設(shè)計(jì)了一種CAN 報(bào)文解析輔助軟件。本文有以下創(chuàng)新點(diǎn)和特色:

(1)根據(jù)相似性原理設(shè)計(jì)的CAN 報(bào)文解析輔助軟件具有解析代碼生成效率高、生成代碼框架清晰的特點(diǎn)。測(cè)試可知,其生成的解析文件導(dǎo)入項(xiàng)目工程的穩(wěn)定性較高,且解析時(shí)間減少至傳統(tǒng)解析方式的8.8%,極大地節(jié)省了大量CAN 報(bào)文解析所需的時(shí)間。

(2)在設(shè)計(jì)生成代碼框架過(guò)程中,根據(jù)代碼框架的主流結(jié)構(gòu),較大程度上實(shí)現(xiàn)了軟件使用者結(jié)構(gòu)的自定義,并結(jié)合不同文件格式的生成,所生成的解析文件具有一定的開(kāi)發(fā)環(huán)境兼容性,為后續(xù)簡(jiǎn)化CAN 解析模塊的開(kāi)發(fā)提供了經(jīng)驗(yàn)。