潘運平，李　暢，張　俊，汪　洋，張松喬

(武漢理工大學(xué)機(jī)電工程學(xué)院，湖北武漢430070)

?

基于J1939協(xié)議的LabVIEW平臺發(fā)動機(jī)通信研究

潘運平，李暢，張俊，汪洋，張松喬

(武漢理工大學(xué)機(jī)電工程學(xué)院，湖北武漢430070)

摘要：隨著CAN總線在車載通信上使用的普及及發(fā)展， J1939通信協(xié)議在汽車領(lǐng)域得到了廣泛的應(yīng)用。然而現(xiàn)階段在對J1939協(xié)議的解析及NI硬件平臺、LabVIEW軟件平臺上的開發(fā)、應(yīng)用存在許多不足，系統(tǒng)性、可讀性、通訊穩(wěn)定性、精度欠缺。針對以上問題，以NI公司CAN通訊硬件為硬件基礎(chǔ)，以LabVIEW為軟件開發(fā)平臺，重點研究了J1939傳輸協(xié)議，解析了J1939協(xié)議下的數(shù)據(jù)幀結(jié)構(gòu)及通訊規(guī)則，以J1939協(xié)議下以道依茨(Deutz_can_spec_emr2_5_engl)柴油發(fā)動機(jī)組報文接收為例，對其通信的硬件平臺進(jìn)行了搭建，并且可讀性高，對便于維護(hù)的LabVIEW軟件及NI—J1939工具包進(jìn)行軟件系統(tǒng)的編寫。通過以上工作和對程序的調(diào)試，實現(xiàn)了CAN通訊數(shù)據(jù)的自發(fā)送和自接收，并且穩(wěn)定性和精度得到了提升。實現(xiàn)了J1939協(xié)議在LabVIEW平臺上的系統(tǒng)實驗通訊，并為以后LabVIEW車載系統(tǒng)的開發(fā)、實現(xiàn)奠定基礎(chǔ)。

關(guān)鍵詞：J1939LabVIEW發(fā)動機(jī)通訊

汽車行業(yè)，作為從21世紀(jì)最龐大、最具有現(xiàn)代化氣息的工業(yè)部門，格外受到人們的關(guān)注。隨著我國人民的生活越發(fā)富裕，有更多的人會選擇擁有自己的交通工具,也越來越多的人關(guān)注汽車的性能與穩(wěn)定性。

實現(xiàn)發(fā)動機(jī)的油溫油壓還有發(fā)動機(jī)轉(zhuǎn)速的實時傳輸以及可視化控制是改善發(fā)動機(jī)狀態(tài)性能的基本途徑。例如：當(dāng)發(fā)動機(jī)的油溫超過預(yù)警值，不但耗油量會增加，而且對機(jī)油的品質(zhì)也存在很大的影響，導(dǎo)致各零件的接觸表面不容易形成油膜，或者形成的油膜易遭到破壞導(dǎo)致干摩擦，促使了接觸表面的磨損，影響汽車零部件的壽命，嚴(yán)重降低了發(fā)動機(jī)的安全性和穩(wěn)定性。發(fā)動機(jī)性能參數(shù)監(jiān)測對整車性能來說至關(guān)重要[1]。

J1939協(xié)議是目前汽車行業(yè)常用的CAN應(yīng)用層協(xié)議。LabVIEW是美國國家儀器公司(NI)研發(fā)的圖形化編程G語言[2]。本文以NI公司CAN通訊硬件為硬件基礎(chǔ)，以道依茨柴油發(fā)動機(jī)組通訊協(xié)議為目標(biāo)(Deutz_can_spec_emr2_5_engl)[3]，深入研究了J1939協(xié)議，解析了J1939協(xié)議下的數(shù)據(jù)幀結(jié)構(gòu)及通訊規(guī)則，并以LabVIEW為軟件平臺，對發(fā)動機(jī)通信平臺進(jìn)行了探究。

1J 1939協(xié)議解析

1.1J 1939簡介

J1939是美國汽車工程協(xié)會SAE(Society of Automotive Engineer)發(fā)布的以CAN總線為基礎(chǔ)、以CAN2.0B作為網(wǎng)絡(luò)核心協(xié)議的車輛網(wǎng)絡(luò)串行通信和控制協(xié)議, 可達(dá)到250 kbps的通訊速率, 廣泛應(yīng)用于貨車、客車、商用車輛、艦船、軌道機(jī)車、農(nóng)業(yè)機(jī)械和大型發(fā)動機(jī)中。SAE J1939協(xié)議是在CAN2.0B的基礎(chǔ)上，對仲裁場部分的29位擴(kuò)展標(biāo)識符(ID)的重新定義，控制場、數(shù)據(jù)場、ACK場等其他部分的定義與CAN2.0B協(xié)議基本相同，是一種高級的CAN協(xié)議標(biāo)準(zhǔn)。同時J1939協(xié)議也對汽車ECU內(nèi)部的地址分配、通訊手段以及報文的優(yōu)先級都做了詳細(xì)的定義。在通訊方式上，SAE J1939定義的網(wǎng)絡(luò)是可以使用節(jié)點地址發(fā)送CAN報文，以達(dá)到每個節(jié)點對應(yīng)的CAN標(biāo)識符的唯一性，相比于使用通信數(shù)據(jù)塊編碼的CAN 2.0B具有很大的優(yōu)勢。

1.2仲裁場分析

表1

仲裁場的位關(guān)系

下面對J1939協(xié)議的29位仲裁場進(jìn)行詳細(xì)分析：

(1)3位的優(yōu)先級P

優(yōu)先級P共有8級，傳遞控制信號的幀P值系統(tǒng)默認(rèn)為3，傳輸數(shù)據(jù)的幀P值系統(tǒng)默認(rèn)為6，與CAN2.0B中用于驅(qū)動系統(tǒng)的高速CAN相對應(yīng)，實時性要求較高的控制單元優(yōu)先級最高，最高優(yōu)先級P值為000，但是可以使用OEM根據(jù)實際需要對優(yōu)先級進(jìn)行編程調(diào)整。

(2)1位的保留位R

保留位R目前未明確定義，當(dāng)前值均設(shè)為0，SAE委員會在將來需要的時候，可根據(jù)實際情況定義保留位R為PDUF場、擴(kuò)展優(yōu)先級場P或者定義更多的PDUF等。

(3)1位的Data Page數(shù)據(jù)頁DP

可用于擴(kuò)展參數(shù)組PG，目前實際使用的參數(shù)組都在0頁，當(dāng)0頁已經(jīng)使用完了之后，頁1將可用來拓展。同時，數(shù)據(jù)頁的選擇也需要根據(jù)PF的具體數(shù)值確定。

(4)8位的幀格式PDUF、幀擴(kuò)展PDUS

PDUF可簡寫為PF，能夠根據(jù)PF的數(shù)值大小判斷數(shù)據(jù)場DF中的參數(shù)組編號PGN。在J1939協(xié)議中，根據(jù)PF的值的不同分為不同的協(xié)議數(shù)據(jù)單元PDU1和PDU2兩種格式。

當(dāng)PF<240時，消息格式為PDU1，表示消息采用點對點方式發(fā)送到目標(biāo)地址，PS即為目標(biāo)地址；當(dāng)240<=PF<255時，消息格式為PDU2，表示消息采用廣播的方式發(fā)送。PS為擴(kuò)展地址，該PS擴(kuò)展地址上的值足夠標(biāo)志數(shù)據(jù)幀，以使這些數(shù)據(jù)幀能夠廣播至所有的ECU。

(5)8位的源地址SA

在同一個網(wǎng)絡(luò)中，每個網(wǎng)絡(luò)上的ECU都有唯一的對應(yīng)的源地址，在網(wǎng)絡(luò)管理層(SAE J1939-81)中對所有的源地址詳細(xì)分配進(jìn)行了說明[4]。

1.3參數(shù)組編號(PGN)

報文的識別基本可以用參數(shù)組編號(PGN)來完成，可以形象的解釋PGN為在定義了“批次”之后的一個“生產(chǎn)編號”。

報文的PGN由保留位R，數(shù)據(jù)頁表示位DP，PDU標(biāo)識符(PF)和PDU特定標(biāo)識符(PS)組成。R、DP、PF構(gòu)成了PGN的組位，而PS則是該組位中的特定一個參數(shù)組編號。

J1939的這種設(shè)置最大化的利用了CAN總線物理層并行ECU的特點，ECU對報文的識別不需要PS，而是進(jìn)入特定部位ECU之后進(jìn)行再分配，提高了數(shù)據(jù)傳輸效率[5]。

1.4報文傳輸分析

數(shù)據(jù)鏈路層由PGN定義了請求報文、命令報文、廣播/相應(yīng)報文、確認(rèn)報文和組功能報文五種類型的報文傳輸。

(1)請求報文

請求報文具備了從某一個特定的目標(biāo)地址或者全部范圍請求報文數(shù)據(jù)的能力。從某一個特定的目標(biāo)地址請求報文數(shù)據(jù)稱為目的地指定請求。當(dāng)目標(biāo)地址支持請求的參數(shù)組編號時，相應(yīng)節(jié)點就會將被請求的數(shù)據(jù)發(fā)送到目標(biāo)地址，則在數(shù)據(jù)場中的控制字節(jié)的值為非1的數(shù)(在0、2、3選擇)；當(dāng)目標(biāo)地址不支持請求的參數(shù)組編號時，則在目標(biāo)地址中會發(fā)送否定信號NACK至原地址，同時在數(shù)據(jù)場中的控制字節(jié)的值為1。同理，對于非點對點的請求報文的全局請求，當(dāng)某個節(jié)點不支持請求的參數(shù)組編號時，它不會反饋否定請求的NACK響應(yīng)。

(2)命令報文

命令報文主要是指從某個源地址采用點對點的方式發(fā)送到目標(biāo)地址或者全局地址發(fā)出的命令PG(Parameter Group)，若干個地址或者單獨是特定地址接收到命令報文，PDU 1(PF<240)和PDU 2(PF>=240)都是命令報文格式。如發(fā)動機(jī)轉(zhuǎn)速控制、車窗動作控制或者地址請求，采取命令報文中包含的數(shù)據(jù)命令，而采取相應(yīng)的動作。

(3)廣播/響應(yīng)報文

廣播/響應(yīng)報文是在CAN報文中最常見的消息類型，可以是某個節(jié)點主動往CAN總線上發(fā)出的廣播消息也可以是對命令報文或者請求報文的響應(yīng)，在CAN2.0B協(xié)議總線上，如TCU以某個特定的周期廣播參數(shù)組，或者某個ECU接收其他的電控單元的PGN請求的響應(yīng)。

(4)確認(rèn)報文

確認(rèn)報文能夠提供對數(shù)據(jù)發(fā)送方與數(shù)據(jù)接收方之間的“握手機(jī)制”。確認(rèn)報文有兩種機(jī)制：一種是由CAN 協(xié)議規(guī)定，判斷在J1939數(shù)據(jù)幀的ACK場中的ACK位確定消息是否被某個或者若干個節(jié)點接收；另一種對于特定的命令報文或請求報文的NACK響應(yīng)，由應(yīng)用層規(guī)定確認(rèn)報文的形式。在64位即8個字節(jié)的數(shù)據(jù)場中，字節(jié)1是控制字節(jié)，當(dāng)控制字節(jié)為0時，表示肯定確認(rèn)ACK；當(dāng)控制字節(jié)為1時，表示否定確認(rèn)NACK；當(dāng)控制字節(jié)為2時，表示拒絕訪問；當(dāng)控制字節(jié)為3時，表示無法響應(yīng)；當(dāng)控制字節(jié)為3-255時，保留待CATARC分配[6]。

(5)特別注意

組功能報文可用于特殊功能組的傳輸(如專用功能、網(wǎng)絡(luò)、管理功能、多包傳輸功能等)，多包傳輸功能是指當(dāng)報文數(shù)據(jù)長度大于8 Byte時，組功能報文之一的“連接管理”報文，能夠?qū)崿F(xiàn)多包傳輸功能，長度大于8 Byte的報文拆分為若干字節(jié)長度小于8的小數(shù)據(jù)包，每個小數(shù)據(jù)包當(dāng)中數(shù)據(jù)域的首字節(jié)定義為數(shù)據(jù)包的序列編號，然后通過單個數(shù)據(jù)幀傳輸至目標(biāo)地址，目標(biāo)地址根據(jù)每個幀的PGN 來識別具體是哪個組功能，識別之后根據(jù)每個數(shù)據(jù)場中的首字節(jié)將接收到的小數(shù)據(jù)包重組還原為原始數(shù)據(jù)幀，這樣能夠?qū)崿F(xiàn)多包傳輸?shù)墓δ?，并且保證數(shù)據(jù)幀不丟失。

1.5信號的拆分重組和連接

當(dāng)所傳輸?shù)膱笪臄?shù)據(jù)場長度大于8 bytes時(如發(fā)動機(jī)配置的報文PGN65251總共有28 bytes)，傳輸協(xié)議功能能夠根據(jù)報文的實際將該報文分成若干個子報文形式進(jìn)行傳送。傳輸協(xié)議功能主要由兩部分組成：信號的拆分重組和連接管理。

(1)信號的拆分重組

協(xié)議數(shù)據(jù)單元PDU包含了仲裁場、控制場、數(shù)據(jù)場的內(nèi)容，實現(xiàn)了報文的拆分打包封裝，再通過物理層發(fā)送到總線上的其他設(shè)備節(jié)點或者特定的節(jié)點，而進(jìn)行報文消息重組。

(2)連接管理

連接管理針對的是節(jié)點之間通信的建立和關(guān)閉等功能，實現(xiàn)“多包傳輸功能”的功能報文稱為“連接管理”報文。它用于報文數(shù)據(jù)場長度大于8 bytes的數(shù)據(jù)幀的傳輸，速率由PGN定義，數(shù)據(jù)長度依舊為8 bytes，數(shù)據(jù)頁標(biāo)識為“0”,PDUF為236，PDUS為目標(biāo)地址發(fā)送，缺省優(yōu)先級7，PGN參數(shù)組編號60416(00EC0016)，第一字節(jié)為控制字節(jié)。

1.6總結(jié)

對基于J1939協(xié)議的CAN報文的解析從一定程度來說其本質(zhì)就是對PDU的解析。各個拆分開的數(shù)據(jù)幀具有相同的PGN，能夠被目標(biāo)地址識別，同時數(shù)據(jù)場中的第一個字節(jié)被用作消息的序列編號，因此編號的范圍為1-255，后面的七個字節(jié)存儲了所要攜帶的數(shù)據(jù)，因此每一個拆分開的數(shù)據(jù)幀最大長度只能是255*7=1 785，特別是未使用的位應(yīng)該默認(rèn)其填充“1”補(bǔ)齊。報文在接收的過程中，按照數(shù)據(jù)場中的序號重組信號。重構(gòu)成一個完整的PDU數(shù)據(jù)包后，再從該PDU中提取參數(shù)組列表PGN和特定的參數(shù)編號SPN，然后通過查看相對應(yīng)的J1939應(yīng)用層中的PGN的數(shù)據(jù)位，就能推導(dǎo)出信息數(shù)據(jù)。

2道依茨報文發(fā)送協(xié)議解析

上文介紹了如何在J1939協(xié)議下的數(shù)據(jù)幀中提取出所需的數(shù)據(jù)。本研究是在道依茨柴油發(fā)動機(jī)組作為數(shù)據(jù)發(fā)出源的基礎(chǔ)上進(jìn)行的。下面對道依茨發(fā)出的數(shù)據(jù)幀的所需數(shù)據(jù)位置進(jìn)行定位。

2.1油溫參數(shù)組解析

根據(jù)《道依茨Deutz EMR 3 CAN BUS Specification》發(fā)動機(jī)的油溫解析，數(shù)據(jù)長度為8字節(jié)，參考字節(jié) 3, 字節(jié)4即為發(fā)動機(jī)的油溫。分辨率為每位0.031 25℃/bit，偏移量為-273℃。PGN為65 262(00FEEE H) 則相對應(yīng)的PDUF=254(11111110 B)，PDUS=238(11101110 B)，數(shù)據(jù)長度Data Length=8，使用的數(shù)據(jù)頁Data Page=0，優(yōu)先級Priority=6。源地址Source Address: EMR3 sends Device Nr. EMR3

字節(jié)定義如下：

EMR3

receives External Device Nr.

2.2油壓參數(shù)組解析

根據(jù)《道依茨Deutz EMR 3 CAN BUS Specification》發(fā)動機(jī)的油壓解析，數(shù)據(jù)長度為8字節(jié)，參考字節(jié)4即為發(fā)動機(jī)油壓。分辨率為每位4 kPa/Bit或者0.04 bar/Bit。參數(shù)組編號PGN為65 263(00FEEF H) ，則相對應(yīng)的PDUF=254(11111110 B)，PDUS=239(11101111 B)，數(shù)據(jù)長度Data Length=8，使用的數(shù)據(jù)頁Data Page=0，優(yōu)先級Priority=6。

源地址Source Address: EMR3 sends Device Nr. EMR3

字節(jié)定義如下：

EMR3

receives External Device Nr.

2.3轉(zhuǎn)速參數(shù)組解析

根據(jù)《道依茨Deutz EMR 3 CAN BUS Specification》發(fā)動機(jī)的轉(zhuǎn)速解析，數(shù)據(jù)長度為8字節(jié)，參考字節(jié)4和字節(jié)5即為發(fā)動機(jī)的轉(zhuǎn)速。分辨率為每位0.125 rpm/Bit。參數(shù)組編號PGN為61 444(00F004 H) ，則相對應(yīng)的PDUF=240(11110000 B)，PDUS=4(00000100 B)，數(shù)據(jù)長度Data Length=8，使用的數(shù)據(jù)頁Data Page=0，優(yōu)先級Priority=3。

源地址Source Address: Device -Nr. EMR3

字節(jié)定義如下：

EMR3

receives External Device Nr.

3通信系統(tǒng)硬件

汽車發(fā)動機(jī)監(jiān)測技術(shù)正在向高精尖的方向快速發(fā)展。監(jiān)測系統(tǒng)具備的基本性能要求，主要包括：實時性、穩(wěn)定性、可操作性、可維護(hù)性、可擴(kuò)展性。實時性主要針對能夠?qū)AN總線中高速采集到的數(shù)據(jù)精確地、完整地上傳至接口卡，并且反映到上位機(jī)。系統(tǒng)的穩(wěn)定性是根本，杜絕系統(tǒng)自身內(nèi)存沖突程序運行不穩(wěn)定等原因，處理結(jié)果的穩(wěn)定性也是非常關(guān)鍵的因素，其應(yīng)具有數(shù)據(jù)的可重復(fù)性[7]。

本研究中發(fā)動機(jī)通信平臺是直接通過發(fā)動機(jī)上的CAN接口作為數(shù)據(jù)輸出接口，通過CAN-PXI接口卡將CAN中的數(shù)據(jù)幀解析，最后將解析的數(shù)據(jù)上傳至上位機(jī)及軟件系統(tǒng)。

研究建立直接給出項目名稱硬件基礎(chǔ)上，通訊板卡為PXI轉(zhuǎn)CAN接口8513通訊卡，工控機(jī)為PXI-1082機(jī)箱(圖1)。

圖1

3.1工業(yè)控制計算機(jī)

PXIe-1082機(jī)箱，該機(jī)箱使用PXIe混合總線，總線帶寬高達(dá)6 GB/s，PXIe機(jī)箱實現(xiàn)了與PCI和PCI Express模塊的通信，同時兼容CompactPCI和CompactPCI Express模塊， PCI 和PCI Express都是采用總線拓?fù)涞慕Y(jié)構(gòu)，實現(xiàn)機(jī)箱中的每臺設(shè)備都能通信。借助于機(jī)箱的系統(tǒng)參考時鐘以及觸發(fā)總線，生成具有高穩(wěn)定性的參考時鐘PXI恒溫晶體振蕩器(Oven Controlled Crystal Oscillator)，也可以通過設(shè)置組成高精度、高分辨率的直接數(shù)字式頻率合成器時鐘(Direct Digital Synthesizer)，PXIe-1082機(jī)箱可以實現(xiàn)多設(shè)備(GPIB、VXI和其它儀器)的同步，也可以在同步各個設(shè)備的基礎(chǔ)上將其作為一臺設(shè)備同步運行。

3.2PXI-CAN接口卡

NI PXI-8513/2CAN通訊卡，是一款2端口高速CAN接口，與高速CAN設(shè)備進(jìn)行達(dá)1 Mb/s的高速通信，兩個端口既可以作為報文接收的端口，又可以作為報文發(fā)送端口(圖2)。

圖2

NI PXI-8513/2能夠支持CAN2.0標(biāo)準(zhǔn)數(shù)據(jù)幀、2.0B數(shù)據(jù)幀。選用PXI-8513/2，適合于具有大量數(shù)據(jù)交換、快速反應(yīng)時間、精確時間同步和時間戳的高端應(yīng)用場合。

NI PXI-8513/2板卡的特點是：

(1)收發(fā)器

能夠?qū)崿F(xiàn)自收自發(fā)的同時，還能對測試系統(tǒng)進(jìn)行單獨監(jiān)聽，能夠基本滿足濾波需求，同時還提供了休眠/喚醒模式支持。

(2)同步性

可使用PXI觸發(fā)總線同步CAN、DAQ、視覺和運動板卡。同時，正在申請專利的NI-XNET設(shè)備內(nèi)置驅(qū)動型DMA引擎能夠耦合CAN總線和主機(jī)內(nèi)存，使得PC的CAN接口系統(tǒng)延遲縮短到微秒，極大地提高了PC主機(jī)的響應(yīng)能力[8]。

4LabVIEW上位機(jī)軟件

LabVIEW能夠提供更加友好、直接、簡潔的人機(jī)交互界面。本課題中的CAN的數(shù)據(jù)幀完成通信和解析之后，存儲在固定的硬盤位置，儲存方式采用LabVIEW中的TDMS文件，TDMS具有獨特的三層邏輯結(jié)構(gòu)，能夠?qū)崿F(xiàn)數(shù)據(jù)的高速讀寫、易存取、方便快捷等優(yōu)勢，而且在LabVIEW中提供了大量的API函數(shù)用于數(shù)據(jù)處理。

4.1登陸界面

系統(tǒng)的第一部分對系統(tǒng)登陸界面進(jìn)行了設(shè)計，并對登陸系統(tǒng)設(shè)置了密碼。設(shè)管理員密碼，防非專業(yè)系統(tǒng)使用，對系統(tǒng)內(nèi)部程序進(jìn)行了修改。

圖3　check用戶名密碼

圖4　主程序調(diào)入

PXI-8513板卡具有自發(fā)自收功能，板卡上的兩個CAN1口和CAN2口具備既可以作為報文接收的端口，又可以作為報文發(fā)送端口的能力。課題中用模擬CAN數(shù)據(jù)報文的發(fā)送進(jìn)行實驗，以實現(xiàn)CAN數(shù)據(jù)報文的解析以及實時顯示。

4.2數(shù)據(jù)解析流程(圖5)

圖5

4.3報文生成和發(fā)送程序

CAN報文生成和發(fā)送是基于LabVIEW的生產(chǎn)者-消費者的模式進(jìn)行，它在數(shù)據(jù)發(fā)送方和數(shù)據(jù)接收方之間提供了緩沖區(qū)間，采用“先進(jìn)先出”的方式,解決了程序并行運行的問題，能夠?qū)崿F(xiàn)將多個循環(huán)的數(shù)據(jù)進(jìn)行交互和共享，而不使數(shù)據(jù)丟失或重復(fù)。

(1)報文初始化

首先，對CAN報文進(jìn)行初始化操作，定義當(dāng)前設(shè)備地址，輸出簇形式的隊列消息，同時，需要創(chuàng)建NI-XNET域，并且在NI-XNET域配置波特率。

圖6　報文初始化

(2)處理數(shù)據(jù)幀

用NI-XNET模塊中的CAN數(shù)據(jù)解析工具，能夠快速地解析發(fā)動機(jī)的油溫油壓和轉(zhuǎn)速。借助NI-XNET可以非?？旖莸貙崿F(xiàn)CAN報文的轉(zhuǎn)換，發(fā)送，接收以及解析等功能。

程序初始化后，使用“XNET Read”控件對輸入的數(shù)據(jù)進(jìn)行讀操作，對所得的數(shù)據(jù)幀進(jìn)行格式轉(zhuǎn)化，最后將J1939格式的CAN幀發(fā)送到其他循環(huán)。

圖7　報文格式轉(zhuǎn)化

(3)生產(chǎn)者隊列發(fā)報文

當(dāng)接收到J1939協(xié)議CAN幀之后，按照名稱解除捆綁，得到“Processed Incoming”隊列。將發(fā)動機(jī)的油溫(FEEE00)、油壓(FEEF00)和轉(zhuǎn)速(F00400)入隊列的操作。當(dāng)Send Message為真時，隨機(jī)的發(fā)動機(jī)的參數(shù)入隊列，方式為“先入先出”，即在隊列后端添加元素。當(dāng)Send Message為假時，選擇結(jié)構(gòu)不執(zhí)行任何操作。

圖8　生產(chǎn)者隊列

(4)輸出報文

在通過元素出隊列之后，需要將已經(jīng)處理好的數(shù)據(jù)幀進(jìn)行格式轉(zhuǎn)換：J1939協(xié)議的CAN報文轉(zhuǎn)換成NI-XNET的CAN報文的格式。將轉(zhuǎn)換好的數(shù)據(jù)幀發(fā)送至PXI-8513板卡的接口1，通過串口總線將報文發(fā)送到板卡的接口2，實現(xiàn)CAN報文的模擬發(fā)送。

4.4報文接收程序

收報程序的初始化和報文格式轉(zhuǎn)化與發(fā)報程序類似，此處不再贅述。

首先在程序循環(huán)結(jié)構(gòu)的外部定義發(fā)動機(jī)的油溫、油壓、轉(zhuǎn)速的名稱，以供波形顯示程序引用。在循環(huán)結(jié)構(gòu)內(nèi)部分為兩個結(jié)構(gòu)部分：1)根據(jù)PF和PS對CAN報文進(jìn)行解析并發(fā)送通知；2)另一部分的目的是確保整個循環(huán)的連續(xù)運行，即對“processed incoming”的隊列中的最大值判定是否大于零，為真時即將發(fā)動機(jī)字符串通知發(fā)送，以供后面的程序調(diào)用。

對報文的解析主要是通過“J1939parse”實現(xiàn)的，從“parse”控件中輸出的PF和PS值通過條件結(jié)構(gòu)判斷之后，將得到的數(shù)值乘以分辨率加上偏移量即可得到實際的油溫，最后通知器將數(shù)據(jù)發(fā)送。

圖9　報文接收與通知

圖10　報文信息匹配

最后CAN報文顯示模塊能夠?qū)笪慕馕瞿K中所得到的數(shù)據(jù)發(fā)送到波形圖中顯示。通知器引用控件能通過已命名的通知器在程序框圖的兩部分之間或兩個VI之間傳遞數(shù)據(jù)。本程序?qū)崿F(xiàn)了油溫、油壓、轉(zhuǎn)速的實時顯示。

4.5數(shù)據(jù)儲存

數(shù)據(jù)存儲模塊的設(shè)計主要是采用文本文件的格式記錄數(shù)據(jù)和存儲數(shù)據(jù)。在LabVIEW中文本文件讀操作和寫操作分別采用的控件是“Write To Text File”和“Read From Text File”，以上的兩個函數(shù)的輸入可以是File Refnum，也可以為File Path。

圖11　報文實時波形顯示

圖12　數(shù)據(jù)儲存

5總結(jié)

本文對J1939協(xié)議的深入剖析，對道依茨柴油發(fā)動機(jī)發(fā)報規(guī)則進(jìn)行了解讀，對LabVIEW平臺進(jìn)行通信系統(tǒng)上位機(jī)軟件編寫。實現(xiàn)了以道依茨發(fā)動機(jī)為例的，發(fā)動機(jī)油溫，油壓，轉(zhuǎn)速的CAN報文的自發(fā)自收通信。一定程度上彌補(bǔ)了在J1939協(xié)議上用LabVIEW平臺進(jìn)行開發(fā)的空白。

然而，由于實驗時間和條件有限，此次開發(fā)的系統(tǒng)并未在實驗室以外道路上的車輛進(jìn)行實測，路試可能會存在跟實驗環(huán)境有所不同的地方，對軟件的穩(wěn)定性和處理數(shù)據(jù)的能力方面有較大的要求。本文

只對發(fā)動機(jī)的油溫，油壓，轉(zhuǎn)速三個數(shù)據(jù)進(jìn)行了采集，在實際應(yīng)用中，這只是一個縮版，真正汽車上CAN總線傳輸?shù)臄?shù)據(jù)量巨大，對設(shè)備系統(tǒng)性能又是一個巨大挑戰(zhàn)，此方面值得繼續(xù)深入研究。

參考文獻(xiàn)

[1]曾志斌，桂江一.發(fā)動機(jī)的分類及各大系統(tǒng)結(jié)構(gòu)[J].汽車維護(hù)和保養(yǎng)，2007(2)58-60.

[2]趙金星.基于LabVIEW的磨漿機(jī)綜合參數(shù)檢測系統(tǒng)的研究[D].天津科技大學(xué)，2010.

[3]Deutz CAN-Specification for EMR2[Z]. Cologne:Deutz,2014.

[4]戴西槐，楊林，張毅，邱國茂，劉欣偉，卓斌.EV電控系統(tǒng)的CAN總線通信研究與開發(fā)[J].計算機(jī)工程及應(yīng)用，2005，41(5)：200-203.

[5]周濤.ISO15765協(xié)議的研究與實現(xiàn)[D].合肥工業(yè)大學(xué)，2011.

[6]劉永木，劉望生，李洪澤.SAE J1939標(biāo)準(zhǔn)下的汽車CAN通訊報文/幀格式[J].長春工業(yè)大學(xué)學(xué)報(自然科學(xué)版),2003,24(1):53-55.

[7]YANG Q H, CAI Y F, LAN B,et al. Development of high speed acquisition module based on FPGA[C]//2014 International Conference on Electrical, Control and Automation. Shanghai:ICECA ,2014:121-125.

[8]http://china.ni.com/?nipkw=NI&nicam=China-Others&nigrp=NIChina&nisrc=baidu[Z].

李暢，男，23歲，河北辛集市人，現(xiàn)為武漢理工大學(xué)機(jī)電工程學(xué)院機(jī)械工程專業(yè)研究生，研究方向為機(jī)電一體化。

Study on the engine communication system based on J1939 and LabVIEW

PAN Yunping, LI Chang, ZHANG Jun, WANG Yang, ZHANG Songqiao

Abstract:With the popularization and development of CAN in vehicle communication, SAE J1939 has been widely used in automotive field. However, there are many deficiencies in the parsing of SAE J1939 and in its application on NI hardware platform and LabVIEW software platform, such as lack of systematicness, readability, stability and accuracy. To solve these problems, we parsed the data frame structure and communication rules of SAE J1939 based on CAN hardware and LabVIEW development environment. Taking the message reception of Deutz diesel engines under SAE J1939 as example, we established its communicational hardware platform, and developed its software system using LabVIEW and NI-J1939 kit. After debugging, we realized the functions of self-transmission and self-reception of CAN communicational data, and improved its stability and accuracy. Through this study, we realized experimental communication under SAE J1939 on LabVIEW platform, and layed foundation for further development of vehicle systems by LabVIEW.

Keywords:J1939; LabVIEW; engine communication

收稿日期：2015-07-30

作者簡介：潘運平，男，42歲，湖北公安人，現(xiàn)為武漢理工大學(xué)機(jī)電工程學(xué)院副教授，研究方向為機(jī)電一體化。

中圖分類號：TP311

文獻(xiàn)標(biāo)識碼：B

文章編號：1002-6886(2016)02-0062-08