楊 棟 陳小華 熊 俊

三一智能控制設(shè)備有限公司，長(zhǎng)沙，410100

0 引言

隨著電子信息技術(shù)的迅速發(fā)展和工程機(jī)械監(jiān)控的日益智能化，客戶對(duì)監(jiān)控系統(tǒng)的實(shí)時(shí)性、準(zhǔn)確性、大數(shù)據(jù)量傳輸及底層信息共享等提出了更高要求［1］。CAN總線在數(shù)據(jù)通信中具有突出的可靠性、實(shí)時(shí)性、靈活性及強(qiáng)抗干擾性，廣泛應(yīng)用于底層控制設(shè)備之間的數(shù)據(jù)通信，但其通信速度不高，且吞吐量有限，已不能很好地滿足工程機(jī)械智能化程度日益增高、部件數(shù)量日益增多的應(yīng)用需求；此外CAN總線通信距離有限，且難以接入Internet，無(wú)法使底層控制設(shè)備信息得到很好共享和利用。以太網(wǎng)具有較長(zhǎng)的通信距離和較高的通信速率，且能方便地接入Internet，在信息量需求大的上層管理網(wǎng)絡(luò)和過(guò)程監(jiān)控網(wǎng)絡(luò)中應(yīng)用廣泛。但傳統(tǒng)以太網(wǎng)無(wú)法保證數(shù)據(jù)傳輸?shù)膶?shí)時(shí)性要求，且單點(diǎn)故障容易擴(kuò)散，從而造成整個(gè)網(wǎng)絡(luò)系統(tǒng)的癱瘓；此外，工業(yè)以太網(wǎng)魯棒性和抗干擾能力都不高，很難適應(yīng)環(huán)境惡劣的工業(yè)現(xiàn)場(chǎng)［2］。

基于以上問(wèn)題，本文結(jié)合CAN總線和以太網(wǎng)的優(yōu)點(diǎn)，構(gòu)建了一種CAN網(wǎng)和以太網(wǎng)技術(shù)相結(jié)合的雙網(wǎng)分流網(wǎng)絡(luò)架構(gòu)（couble nets sharing architecture，DNSA），重點(diǎn)對(duì)以太網(wǎng)鏈路層協(xié)議進(jìn)行了改進(jìn)，簡(jiǎn)化了通信協(xié)議，實(shí)現(xiàn)了CAN與以太網(wǎng)的無(wú)縫對(duì)接。實(shí)驗(yàn)證明，DNSA在保證數(shù)據(jù)低丟包率的同時(shí)，能很好地實(shí)現(xiàn)監(jiān)控網(wǎng)絡(luò)間的資源共享和利用。

1 網(wǎng)絡(luò)構(gòu)架

1.1 傳統(tǒng)架構(gòu)

傳統(tǒng)的監(jiān)控系統(tǒng)采用CAN總線進(jìn)行通信，通信網(wǎng)絡(luò)可分為現(xiàn)場(chǎng)設(shè)備層、控制層和遠(yuǎn)程管理層。現(xiàn)場(chǎng)設(shè)備層主要完成現(xiàn)場(chǎng)設(shè)備的數(shù)據(jù)采集和控制命令的執(zhí)行，控制層主要完成現(xiàn)場(chǎng)設(shè)備數(shù)據(jù)的處理、上傳及將監(jiān)控主站命令下達(dá)至現(xiàn)場(chǎng)設(shè)備層，遠(yuǎn)程管理層主要指監(jiān)控主站。遠(yuǎn)程管理層和控制層間通過(guò)無(wú)線網(wǎng)絡(luò)進(jìn)行通信，典型的網(wǎng)絡(luò)結(jié)構(gòu)如圖 1所示［3］。

每個(gè)被監(jiān)控的設(shè)備部件包括一個(gè)或多個(gè)傳感器，傳感器采集設(shè)備部件的壓力、溫度和伸縮量等數(shù)據(jù)；分布式控制器將采集到的現(xiàn)場(chǎng)數(shù)據(jù)處理后將結(jié)果傳至CAN總線，供CAN總線上其他設(shè)備使用；某些帶有CAN通信結(jié)構(gòu)的部件（如傾角傳感器和發(fā)動(dòng)機(jī)）等可直接連接在CAN總線上；主控制器從CAN總線收集所需信息，完成某些預(yù)定的處理功能，將結(jié)果輸入給HMI設(shè)備和遠(yuǎn)程設(shè)備；HMI設(shè)備主要用于顯示現(xiàn)場(chǎng)數(shù)據(jù)及響應(yīng)現(xiàn)場(chǎng)輸入命令；遠(yuǎn)傳設(shè)備是遠(yuǎn)程管理層和控制層的接口，主站和遠(yuǎn)傳設(shè)備間可通過(guò)無(wú)線網(wǎng)絡(luò)或Internet進(jìn)行通信。操作人員命令通過(guò)HMI設(shè)備或主站經(jīng)主控制器、CAN總線下發(fā)至分布式控制器，各分布式控制器通過(guò)執(zhí)行器對(duì)設(shè)備部件執(zhí)行用戶命令，如油缸位移調(diào)整、診斷性保護(hù)等。

傳統(tǒng)的網(wǎng)絡(luò)通信架構(gòu)結(jié)構(gòu)簡(jiǎn)單，成本低，系統(tǒng)可靠性高，但吞吐量低。隨著部件信息、智能化需求的提高及部件數(shù)量的日益增多，傳感器、執(zhí)行器、分布式控制器和主控制器等形成大量數(shù)據(jù)，吞吐量有限的CAN總線顯然已很難滿足工程需求。以太網(wǎng)數(shù)據(jù)傳輸效率高，能彌補(bǔ)CAN總線在吞吐量低的缺陷，且能很好地實(shí)現(xiàn)監(jiān)控單元間及監(jiān)控單元與遠(yuǎn)傳計(jì)算機(jī)間資源共享［4］。本文結(jié)合CAN總線和以太網(wǎng)優(yōu)點(diǎn)，構(gòu)建了適合工程機(jī)械現(xiàn)場(chǎng)數(shù)據(jù)通信的DNSA架構(gòu)。

1.2 DNSA架構(gòu)

DNSA構(gòu)架的核心思想是根據(jù)數(shù)據(jù)量和數(shù)據(jù)的重要性進(jìn)行分類傳輸。對(duì)于實(shí)時(shí)性要求高或數(shù)據(jù)量不大的數(shù)據(jù)（如傳感器數(shù)據(jù)、執(zhí)行器數(shù)據(jù)等），通過(guò)CAN總線進(jìn)行傳輸，以保證傳輸?shù)目煽啃院蛯?shí)時(shí)性；對(duì)于實(shí)時(shí)性不高或數(shù)據(jù)量大的數(shù)據(jù)（如設(shè)備程序文件、視頻流數(shù)據(jù)和主控制層診斷數(shù)據(jù)等），則通過(guò)工業(yè)以太網(wǎng)傳輸，以保證大數(shù)據(jù)量通信。DNSA架構(gòu)如圖2所示。

DNSA數(shù)據(jù)傳輸構(gòu)架由CAN總線和以太網(wǎng)兩部分組成。在整個(gè)傳輸網(wǎng)絡(luò)中，主控制器相當(dāng)于大腦，通過(guò)以太網(wǎng)獲得執(zhí)行部件及傳感器等設(shè)備信息，同時(shí)結(jié)合其他監(jiān)控信息如圖像監(jiān)控信息、防撞監(jiān)控信息等，綜合監(jiān)控整個(gè)系統(tǒng)的運(yùn)行。分布式控制器協(xié)助主控制器完成單元控制功能。以太網(wǎng)具有很好的資源共享能力，可直接與Internet相連，實(shí)現(xiàn)工業(yè)現(xiàn)場(chǎng)和監(jiān)控主站網(wǎng)絡(luò)資源共享。人機(jī)接口界面用于顯示系統(tǒng)的實(shí)時(shí)參數(shù)及用戶指令下達(dá)。對(duì)于某些自帶CAN傳輸功能且實(shí)時(shí)性要求高的設(shè)備（如傾角傳感器、旋轉(zhuǎn)編碼器等），直接放在CAN總線上進(jìn)行處理，因CAN總線負(fù)載率有限，對(duì)于實(shí)時(shí)性要求不高，或需數(shù)據(jù)量較大的數(shù)據(jù)，可以放在以太網(wǎng)上進(jìn)行傳輸。

圖2 DNSA數(shù)據(jù)傳輸構(gòu)架

交換機(jī)用于完成以太網(wǎng)各節(jié)點(diǎn)的數(shù)據(jù)交換及CAN總線和以太網(wǎng)數(shù)據(jù)交互。單純CAN總線和以太網(wǎng)在工業(yè)控制領(lǐng)域應(yīng)用已相對(duì)成熟，因此DNSA架構(gòu)的最大難點(diǎn)在于CAN總線－以太網(wǎng)對(duì)接模塊的設(shè)計(jì)和實(shí)現(xiàn)。該模塊放在交換機(jī)中，下面將重點(diǎn)對(duì)此進(jìn)行研究。

為了使雙網(wǎng)數(shù)據(jù)對(duì)接，必須在以太網(wǎng)和CAN總線之間必須加入互聯(lián)網(wǎng)關(guān)，如圖3所示。

圖3 DNSA網(wǎng)關(guān)硬件結(jié)構(gòu)框圖

DNSA網(wǎng)關(guān)是本架構(gòu)的核心，負(fù)責(zé)從接收到的鏈路層數(shù)據(jù)幀中解析出完整的CAN協(xié)議報(bào)文，并通過(guò)CAN控制器組幀后發(fā)送到CAN總線；同時(shí)，也可將收到的CAN協(xié)議報(bào)文打包成數(shù)據(jù)幀，通過(guò)以太網(wǎng)控制器發(fā)送到以太網(wǎng)上。因?yàn)橐蕴W(wǎng)比CAN總線傳輸速度快，所以在處理器里應(yīng)該開(kāi)辟一塊緩存區(qū)。從以太網(wǎng)傳至CAN總線的數(shù)據(jù)大多為執(zhí)行命令，數(shù)據(jù)包不會(huì)很大，根據(jù)實(shí)際工程需求，緩存區(qū)大小設(shè)為1MB。1MB以內(nèi)的數(shù)據(jù)，先在緩存區(qū)中全部保存完后再發(fā)送至CAN總線。理論上，1MB之內(nèi)的數(shù)據(jù)不可能出現(xiàn)丟包現(xiàn)象。來(lái)自CAN網(wǎng)絡(luò)的數(shù)據(jù)，同樣存儲(chǔ)在緩存區(qū)中，根據(jù)預(yù)先設(shè)定的CAN包數(shù)組成以太網(wǎng)幀進(jìn)行發(fā)送。

2 網(wǎng)絡(luò)傳輸協(xié)議

2.1 傳統(tǒng)協(xié)議

2.1.1 CAN總線協(xié)議

CAN總線是目前應(yīng)用最廣泛的現(xiàn)場(chǎng)總線之一，通信距離最遠(yuǎn)可達(dá)10km（速率低于5kbit／s），速率可達(dá)到1Mbit／s（通信距離小于40m）。本文以CAN2.0B版本協(xié)議定義的擴(kuò)展數(shù)據(jù)幀為例對(duì)CAN幀格式進(jìn)行說(shuō)明。標(biāo)準(zhǔn)數(shù)據(jù)幀格式如圖4所示。

圖4 標(biāo)準(zhǔn)數(shù)據(jù)幀格式

標(biāo)準(zhǔn)數(shù)據(jù)幀由1bit的幀起始，然后是32bit仲裁場(chǎng)、6bit控制場(chǎng)、0～64bit數(shù)據(jù)場(chǎng)、16bit循環(huán)冗余碼CRC場(chǎng)、2bit應(yīng)答場(chǎng)，最后以7bit幀結(jié)尾。如果數(shù)據(jù)位全填滿，則CAN幀長(zhǎng)為128bit。

傳輸時(shí)延是指一個(gè)站點(diǎn)從開(kāi)始發(fā)送數(shù)據(jù)幀到數(shù)據(jù)幀發(fā)送完畢所需要的全部時(shí)間，是衡量通信網(wǎng)絡(luò)質(zhì)量的一個(gè)重要指標(biāo)。假設(shè)從節(jié)點(diǎn)a到節(jié)點(diǎn)b傳輸L字節(jié)（B），鏈路傳輸速率為Rbit／s，B為負(fù)載率，幀長(zhǎng)為F，有效載荷為m，則傳輸幀數(shù)N為

其中，［8L／m］表示對(duì)［8L／m］取上整。為計(jì)算方便，本文將其約等于8L／m，m取CAN總線最大載荷64bit。傳輸時(shí)延t為

對(duì)于CAN總線，F(xiàn)為128bit，R 為1Mbit／s。CAN總線負(fù)載率常在60%以下。當(dāng)總線負(fù)載率超過(guò)40%，系統(tǒng)性能將惡化，當(dāng)總線負(fù)載率超過(guò)60%，系統(tǒng)將不再穩(wěn)定［5］，所以選用60%負(fù)載率，代入式（2）得

2.1.2以太網(wǎng)協(xié)議

Ethernet II和IEEE802.3是局域網(wǎng)中最常見(jiàn)的以太網(wǎng)，本文選用用更適合工程機(jī)械的大數(shù)據(jù)量傳輸?shù)腅thernet II協(xié)議，EthernetII鏈路層幀格式如表1所示。

表1 以太網(wǎng)鏈路層幀結(jié)構(gòu)

前同步碼的前7B值都為10101010，用于“喚醒”接收適配器，第8個(gè)字節(jié)為10101011，第8個(gè)字節(jié)的最后兩個(gè)1，通知主機(jī)接下來(lái)字節(jié)為目的地址；目的地址為6B，該字段包含目的設(shè)備的MAC地址；源地址占6B，該字段包含傳輸該幀到局域網(wǎng)上源設(shè)備的MAC地址；類型字段允許以太網(wǎng)復(fù)用多種網(wǎng)絡(luò)層協(xié)議，目的設(shè)備根據(jù)類型判斷該將數(shù)據(jù)字段傳輸給哪層，并根據(jù)哪種協(xié)議類型進(jìn)行解析；循環(huán)冗余檢測(cè)（cyclic redundantcy check，CRC）用于檢測(cè)幀中是否引入了差錯(cuò)。數(shù)據(jù)字段為以太網(wǎng)幀的有效載荷，對(duì)于傳統(tǒng)的以太網(wǎng)幀，數(shù)據(jù)字段為IP數(shù)據(jù)報(bào)，IP數(shù)據(jù)報(bào)格式如表2所示。

表2 IP數(shù)據(jù)報(bào)

IP數(shù)據(jù)報(bào)網(wǎng)絡(luò)層為IPV4、IPV6等協(xié)議，首部至少為20B，傳輸層為T(mén)CP等協(xié)議，首部占20。

設(shè)一幀全部填滿，則幀長(zhǎng)F為1526B，以太網(wǎng)速率取10Mbit／s，有效載荷為數(shù)據(jù)長(zhǎng)度為1460B，負(fù)載率也取60%，根據(jù)式（2），可得傳輸延時(shí)如下：

從表2可以看出，傳統(tǒng)以太網(wǎng)的數(shù)據(jù)填充位包括網(wǎng)絡(luò)層首部、傳輸層首部，假設(shè)網(wǎng)絡(luò)層采用IPV4，IP數(shù)據(jù)報(bào)首部有20B（假定無(wú)選項(xiàng)），假設(shè)傳輸層采用TCP協(xié)議，TCP首部有20B。應(yīng)用層采用HTTP文件傳輸協(xié)議。網(wǎng)絡(luò)層、傳輸層占用至少了40B，浪費(fèi)了帶寬。為提高帶寬利用率，簡(jiǎn)化以太網(wǎng)模型，可去掉各層首部，將網(wǎng)絡(luò)層、傳輸層和應(yīng)用層壓縮為一層，即將模型簡(jiǎn)化為物理層、鏈路層和應(yīng)用層。此時(shí)有

CAN總線和以太網(wǎng)是兩種截然不同的通信方式，為實(shí)現(xiàn)二者融合，必須對(duì)傳輸協(xié)議進(jìn)行改進(jìn)，為此本文提出率DNSA協(xié)議，用于CAN總線和以太網(wǎng)的對(duì)接。

2.2 DNSA協(xié)議

DNSA協(xié)議是DNSA架構(gòu)中以太網(wǎng)和CAN總線的對(duì)接協(xié)議，組幀及解析均由圖2中交換機(jī)中的以太網(wǎng)－CAN總線對(duì)接模塊實(shí)現(xiàn)。其核心思想是將CAN幀填充至以太網(wǎng)協(xié)議中的數(shù)據(jù)段進(jìn)行傳輸；為提高帶寬利用率，將傳統(tǒng)以太網(wǎng)的網(wǎng)絡(luò)層首部和傳輸層首部全部取消。因?yàn)榇藚f(xié)議為用戶自定義傳輸協(xié)議，為使該類型幀在以太網(wǎng)上傳輸而不影響現(xiàn)有協(xié)議幀的正常傳輸，必須避開(kāi)已有以太網(wǎng)幀類型碼［6］，此處將類型定義為0x9931。以太網(wǎng)－CAN總線對(duì)接協(xié)議組幀規(guī)則如下：幀頭和幀尾和傳統(tǒng)以太網(wǎng)相同，數(shù)據(jù)字段由數(shù)據(jù)包數(shù)和C個(gè)數(shù)據(jù)包組成，如表3所示。其中，1≤c≤C，m1，m2，…，mc為每個(gè)數(shù)據(jù)包對(duì)應(yīng)的CAN包數(shù)。

表3 數(shù)據(jù)字段格式

用戶可將數(shù)據(jù)分成不同數(shù)據(jù)包進(jìn)行傳輸，同一幀數(shù)據(jù)可同時(shí)傳輸多種類型數(shù)據(jù)。該協(xié)議允許一幀數(shù)據(jù)傳輸不同類型的CAN數(shù)據(jù)，每個(gè)數(shù)據(jù)包中的CAN包類型必須相同，不同數(shù)據(jù)包的CAN包類型可以不同。以第一個(gè)數(shù)據(jù)包為例說(shuō)明數(shù)據(jù)包字段的組成情況，如表4所示。

表4 數(shù)據(jù)包字段格式

因?yàn)镃AN幀由4B的CANID和8B的CAN數(shù)據(jù)場(chǎng)組成，所以此處為CAN包分配12B長(zhǎng)度，CAN包格式如表5所示。

表5 CAN包格式

CAN包用于定義設(shè)備部件的屬性值。CANID的前2B用于表示設(shè)備類型，后2B表示部件類型，8B的CAN數(shù)據(jù)中，前2B用于表示屬性類型，保留2B，后4B表示故障數(shù)據(jù)類型。

設(shè)備類型用于識(shí)別主機(jī)類型，如挖掘機(jī)、起重機(jī)等，設(shè)備及相應(yīng)的類型如表6所示。

表6 設(shè)備類型碼

部件類型碼用于識(shí)別機(jī)械部件，如發(fā)動(dòng)機(jī)、油缸等，部件類型碼如表7所示。

表7 部件類型碼

屬性類型碼為數(shù)據(jù)本身代表的物理含義，如溫度、濕度等，屬性類型碼如表8所示。

表8 屬性類型碼

如果CAN包為0x0001 0001 0000 0000 1E，則表示起重機(jī)油缸溫度為30℃。在組幀和解析CAN包時(shí)需查詢?cè)O(shè)備類型碼、部件類型碼及屬性類型碼表。定義一個(gè)結(jié)構(gòu)體用于描述設(shè)備、部件和屬性類型，結(jié)構(gòu)體包括類型名稱和類型碼兩個(gè)屬性。系統(tǒng)初始化時(shí)，構(gòu)建設(shè)備類型、部件和屬性三個(gè)結(jié)構(gòu)體鏈表，根據(jù)類型碼從小到大排列。

當(dāng)從以太網(wǎng)接收到數(shù)據(jù)包，以太網(wǎng)通信模塊對(duì)數(shù)據(jù)包進(jìn)行分析，如果類型為0x9931，則認(rèn)為該數(shù)據(jù)報(bào)正確。取出數(shù)據(jù)段，根據(jù)協(xié)議進(jìn)行解析，取出CAN包數(shù)據(jù)填充CANID和CAN數(shù)據(jù)，通過(guò)CAN控制器發(fā)送到CAN總線。數(shù)據(jù)從以太網(wǎng)傳至CAN網(wǎng)的流程如圖5所示。

圖5 以太網(wǎng)至CAN總線傳輸

若從CAN總線接收到數(shù)據(jù)，則將若干個(gè)CAN包組成數(shù)據(jù)包，把若干各數(shù)據(jù)包填充至以太網(wǎng)數(shù)據(jù)填充位，從而組成以太網(wǎng)幀，由以太網(wǎng)控制器發(fā)送到以太網(wǎng)上，具體流程如圖6所示。

圖6 CAN總線至以太網(wǎng)傳輸

3 工業(yè)應(yīng)用與性能分析

為驗(yàn)證DNSA的有效性，我們將其用于泵車監(jiān)控系統(tǒng)，以其中的臂架姿態(tài)控制為例進(jìn)行說(shuō)明。遠(yuǎn)傳設(shè)備采用三一移動(dòng)終端，HMI設(shè)備采用三一顯示屏，交換機(jī)包含DNSA網(wǎng)關(guān)，此處的分布式控制器為油缸控制器。圖7所示為DNSA用于泵車監(jiān)控系統(tǒng)。

傾角傳感器采集的臂架角度數(shù)據(jù)和旋轉(zhuǎn)編碼器采集的轉(zhuǎn)塔角度數(shù)據(jù)經(jīng)CAN總線傳輸至交換機(jī)，交換機(jī)中的DNSA網(wǎng)關(guān)將此CAN數(shù)據(jù)轉(zhuǎn)為以太網(wǎng)數(shù)據(jù)傳輸至主控制器，主控器接收到角度信息，并依此計(jì)算達(dá)到臂架目標(biāo)姿態(tài)所需各節(jié)臂油缸的運(yùn)動(dòng)過(guò)程，將運(yùn)動(dòng)過(guò)程傳給分布式控制器，分布式控制器用接收到的命令控制比例閥開(kāi)關(guān)，從而控制油缸伸縮，壓力傳感器可實(shí)時(shí)采集油缸出油口等位置壓力，作為分布式控制器對(duì)油缸平穩(wěn)運(yùn)動(dòng)的判定依據(jù)。油缸信息也可根據(jù)用戶需要經(jīng)以太網(wǎng)傳輸至交換機(jī)，交換機(jī)將以太網(wǎng)數(shù)據(jù)轉(zhuǎn)為CAN數(shù)據(jù)傳給發(fā)送機(jī)等部件。主控制器也可直接將某些實(shí)時(shí)性要求高的命令通過(guò)以太網(wǎng)、交換機(jī)和CAN總線傳回給執(zhí)行器，如臂架運(yùn)動(dòng)過(guò)程，主控制器如果發(fā)現(xiàn)臂架處在即將碰撞的安全范圍外，將通過(guò)CAN總線強(qiáng)制停止發(fā)動(dòng)機(jī)。

圖7 DNSA用于泵車監(jiān)控系統(tǒng)

通過(guò)式（3）和式（5）可以分別求CAN總線和以太網(wǎng)傳輸延時(shí)，對(duì)比結(jié)果如圖8所示。

圖8 CAN和以太網(wǎng)傳輸延時(shí)

從圖8可看出，在相同負(fù)載率下，以太網(wǎng)傳輸延時(shí)明顯低于CAN總線，以太網(wǎng)傳輸速率可到100Mbit／s以 上，而 CAN 總 線 在 傳 輸 速 率1Mbit／s時(shí)速度基本達(dá)到了上限。因此說(shuō)明以太網(wǎng)在大數(shù)據(jù)量傳輸時(shí)更占優(yōu)勢(shì)。

為驗(yàn)證DNSA的有效性，下面對(duì)CAN總線和以太網(wǎng)間的通信丟包率進(jìn)行測(cè)試。以太網(wǎng)到CAN總線發(fā)送數(shù)據(jù)分為600B、2kB、5MB三組，緩存區(qū)大小為1MB，發(fā)送次數(shù)為1000，丟包率如表9所示。

表9 以太網(wǎng)至CAN丟包率測(cè)試

在600B和2kB情況下，丟包率為0；在5M情況下，因?yàn)榫彺鎱^(qū)小于以太網(wǎng)所發(fā)數(shù)據(jù)包大小，而以太網(wǎng)發(fā)送速率遠(yuǎn)遠(yuǎn)大于CAN總線發(fā)送速率，所以會(huì)產(chǎn)生比較嚴(yán)重的丟包現(xiàn)象。CAN總線至以太網(wǎng)根據(jù)表10所設(shè)參數(shù)及分組進(jìn)行測(cè)試。因?yàn)镃AN總線速度小于以太網(wǎng)速度，所以從CAN總線至以太網(wǎng)基本上不會(huì)出現(xiàn)丟包現(xiàn)象。

表10 CAN總線至以太網(wǎng)丟包率測(cè)試

對(duì)于丟包，可從如下幾方面做改進(jìn)：①提高數(shù)據(jù)接收處理線程優(yōu)先級(jí)；②對(duì)于數(shù)據(jù)完整性要求高的CAN設(shè)備采用一對(duì)一連接；③在應(yīng)用層加入應(yīng)答重傳機(jī)制；④從總線拓?fù)浣嵌?，尋找最?yōu)布置線路方案。

實(shí)際工程應(yīng)用中，主要是將底層數(shù)據(jù)通過(guò)CAN總線傳送至以太網(wǎng)，而以太網(wǎng)至CAN總線傳輸?shù)氖侵骺刂苹蚱渌植际娇刂破飨掳l(fā)的一些控制命令，很少出現(xiàn)1MB以上的文件，所以本設(shè)計(jì)能很好地滿足工程需求。

4 結(jié)語(yǔ)

本文結(jié)合CAN總線可靠性高和以太網(wǎng)吞吐量大、資源共享能力強(qiáng)等優(yōu)點(diǎn)，建構(gòu)了一種適合工程機(jī)械控制領(lǐng)域的DNSA構(gòu)架，重點(diǎn)對(duì)CAN總線和以太網(wǎng)的對(duì)接模塊進(jìn)行了研究，同時(shí)從網(wǎng)關(guān)設(shè)計(jì)及傳輸協(xié)議上進(jìn)行了改進(jìn)。實(shí)驗(yàn)證明，該網(wǎng)絡(luò)結(jié)構(gòu)丟包率低，能很好地滿足工業(yè)現(xiàn)場(chǎng)多部件、智能化、高可靠性和高實(shí)時(shí)性的通信需求。

［1］張炳賢.工程機(jī)械的智能化趨勢(shì)與發(fā)展對(duì)策［J］.企業(yè)技術(shù)開(kāi)發(fā)，2012（11）：115－116.Zhang Binxian.Intelligent Trend and Development Countermeasures for Engineering Machinery［J］.Technological Development of Enterprise，2012（11）：115－116.

［2］金敏，羅恩澤，周翔.面向工程機(jī)械遠(yuǎn)程智能監(jiān)控的無(wú)線通信協(xié)議［J］.中國(guó)工程機(jī)械，2011，22（19）：2316－2324.Jin Min，Luo Enze，Zhou Xiang.Wireless Communication Protocol for Remote Intelligent Monitoring of Construction Machinery［J］.China Mechanical Engineering，2011，22（19）：2316－2324.

［3］黃斑斑.工程機(jī)械智能控制以太網(wǎng)CAN總線轉(zhuǎn)換器設(shè)計(jì)［D］.武漢：武漢科技大學(xué)，2011.

［4］陳曦，楊振興，柳國(guó)輝.CAN總線和以太網(wǎng)在中央空調(diào)系統(tǒng)遠(yuǎn)程監(jiān)控中的應(yīng)用［J］.工業(yè)儀表與自動(dòng)化裝置，2010，1（3）：71－73.Chen Xi，Yang Zhenxing，Liu Guohui.The Application of CAN Bus and Ethernet in the Central Air－conditioning System Remote Monitoring［J］.Industrial Instrumentation ＆ Automation，2010，1（3）：71－73.

［5］荊楠，王林，安佰岳.基于CAN總線網(wǎng)絡(luò)控制系統(tǒng)中的時(shí)延分析及對(duì)策［J］.計(jì)算機(jī)工程與設(shè)計(jì)，2009，3（20）：4599－4602.Jin Nan，Wang Lin，An Baiyue.Analysis and Policy of Network Latency in CAN Control System［J］.Computer Engineering and Design，2009，3（20）：4599－4602.

［6］Stevens W R.TCP／IP Illustrated Volume 1：the Protocols［S］.S.L.：Addison Wesley／Pearson，1994.