楊 棟 陳小華 熊 俊
三一智能控制設(shè)備有限公司,長沙,410100
隨著電子信息技術(shù)的迅速發(fā)展和工程機(jī)械監(jiān)控的日益智能化,客戶對監(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,無法使底層控制設(shè)備信息得到很好共享和利用。以太網(wǎng)具有較長的通信距離和較高的通信速率,且能方便地接入Internet,在信息量需求大的上層管理網(wǎng)絡(luò)和過程監(jiān)控網(wǎng)絡(luò)中應(yīng)用廣泛。但傳統(tǒng)以太網(wǎng)無法保證數(shù)據(jù)傳輸?shù)膶?shí)時(shí)性要求,且單點(diǎn)故障容易擴(kuò)散,從而造成整個(gè)網(wǎng)絡(luò)系統(tǒng)的癱瘓;此外,工業(yè)以太網(wǎng)魯棒性和抗干擾能力都不高,很難適應(yīng)環(huán)境惡劣的工業(yè)現(xiàn)場[2]。
基于以上問題,本文結(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)對以太網(wǎng)鏈路層協(xié)議進(jìn)行了改進(jìn),簡化了通信協(xié)議,實(shí)現(xiàn)了CAN與以太網(wǎng)的無縫對接。實(shí)驗(yàn)證明,DNSA在保證數(shù)據(jù)低丟包率的同時(shí),能很好地實(shí)現(xiàn)監(jiān)控網(wǎng)絡(luò)間的資源共享和利用。
傳統(tǒng)的監(jiān)控系統(tǒng)采用CAN總線進(jìn)行通信,通信網(wǎng)絡(luò)可分為現(xiàn)場設(shè)備層、控制層和遠(yuǎn)程管理層?,F(xiàn)場設(shè)備層主要完成現(xiàn)場設(shè)備的數(shù)據(jù)采集和控制命令的執(zhí)行,控制層主要完成現(xiàn)場設(shè)備數(shù)據(jù)的處理、上傳及將監(jiān)控主站命令下達(dá)至現(xiàn)場設(shè)備層,遠(yuǎn)程管理層主要指監(jiān)控主站。遠(yuǎn)程管理層和控制層間通過無線網(wǎng)絡(luò)進(jìn)行通信,典型的網(wǎng)絡(luò)結(jié)構(gòu)如圖 1所示[3]。
每個(gè)被監(jiān)控的設(shè)備部件包括一個(gè)或多個(gè)傳感器,傳感器采集設(shè)備部件的壓力、溫度和伸縮量等數(shù)據(jù);分布式控制器將采集到的現(xiàn)場數(shù)據(jù)處理后將結(jié)果傳至CAN總線,供CAN總線上其他設(shè)備使用;某些帶有CAN通信結(jié)構(gòu)的部件(如傾角傳感器和發(fā)動機(jī))等可直接連接在CAN總線上;主控制器從CAN總線收集所需信息,完成某些預(yù)定的處理功能,將結(jié)果輸入給HMI設(shè)備和遠(yuǎn)程設(shè)備;HMI設(shè)備主要用于顯示現(xiàn)場數(shù)據(jù)及響應(yīng)現(xiàn)場輸入命令;遠(yuǎn)傳設(shè)備是遠(yuǎn)程管理層和控制層的接口,主站和遠(yuǎn)傳設(shè)備間可通過無線網(wǎng)絡(luò)或Internet進(jìn)行通信。操作人員命令通過HMI設(shè)備或主站經(jīng)主控制器、CAN總線下發(fā)至分布式控制器,各分布式控制器通過執(zhí)行器對設(shè)備部件執(zhí)行用戶命令,如油缸位移調(diào)整、診斷性保護(hù)等。
傳統(tǒng)的網(wǎng)絡(luò)通信架構(gòu)結(jié)構(gòu)簡單,成本低,系統(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)場數(shù)據(jù)通信的DNSA架構(gòu)。
DNSA構(gòu)架的核心思想是根據(jù)數(shù)據(jù)量和數(shù)據(jù)的重要性進(jìn)行分類傳輸。對于實(shí)時(shí)性要求高或數(shù)據(jù)量不大的數(shù)據(jù)(如傳感器數(shù)據(jù)、執(zhí)行器數(shù)據(jù)等),通過CAN總線進(jìn)行傳輸,以保證傳輸?shù)目煽啃院蛯?shí)時(shí)性;對于實(shí)時(shí)性不高或數(shù)據(jù)量大的數(shù)據(jù)(如設(shè)備程序文件、視頻流數(shù)據(jù)和主控制層診斷數(shù)據(jù)等),則通過工業(yè)以太網(wǎng)傳輸,以保證大數(shù)據(jù)量通信。DNSA架構(gòu)如圖2所示。
DNSA數(shù)據(jù)傳輸構(gòu)架由CAN總線和以太網(wǎng)兩部分組成。在整個(gè)傳輸網(wǎng)絡(luò)中,主控制器相當(dāng)于大腦,通過以太網(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)場和監(jiān)控主站網(wǎng)絡(luò)資源共享。人機(jī)接口界面用于顯示系統(tǒng)的實(shí)時(shí)參數(shù)及用戶指令下達(dá)。對于某些自帶CAN傳輸功能且實(shí)時(shí)性要求高的設(shè)備(如傾角傳感器、旋轉(zhuǎn)編碼器等),直接放在CAN總線上進(jìn)行處理,因CAN總線負(fù)載率有限,對于實(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)用已相對成熟,因此DNSA架構(gòu)的最大難點(diǎn)在于CAN總線-以太網(wǎng)對接模塊的設(shè)計(jì)和實(shí)現(xiàn)。該模塊放在交換機(jī)中,下面將重點(diǎn)對此進(jìn)行研究。
為了使雙網(wǎng)數(shù)據(jù)對接,必須在以太網(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)文,并通過CAN控制器組幀后發(fā)送到CAN總線;同時(shí),也可將收到的CAN協(xié)議報(bào)文打包成數(shù)據(jù)幀,通過以太網(wǎng)控制器發(fā)送到以太網(wǎng)上。因?yàn)橐蕴W(wǎng)比CAN總線傳輸速度快,所以在處理器里應(yīng)該開辟一塊緩存區(qū)。從以太網(wǎng)傳至CAN總線的數(shù)據(jù)大多為執(zhí)行命令,數(shù)據(jù)包不會很大,根據(jù)實(shí)際工程需求,緩存區(qū)大小設(shè)為1MB。1MB以內(nèi)的數(shù)據(jù),先在緩存區(qū)中全部保存完后再發(fā)送至CAN總線。理論上,1MB之內(nèi)的數(shù)據(jù)不可能出現(xiàn)丟包現(xiàn)象。來自CAN網(wǎng)絡(luò)的數(shù)據(jù),同樣存儲在緩存區(qū)中,根據(jù)預(yù)先設(shè)定的CAN包數(shù)組成以太網(wǎng)幀進(jìn)行發(fā)送。
2.1.1 CAN總線協(xié)議
CAN總線是目前應(yīng)用最廣泛的現(xiàn)場總線之一,通信距離最遠(yuǎn)可達(dá)10km(速率低于5kbit/s),速率可達(dá)到1Mbit/s(通信距離小于40m)。本文以CAN2.0B版本協(xié)議定義的擴(kuò)展數(shù)據(jù)幀為例對CAN幀格式進(jìn)行說明。標(biāo)準(zhǔn)數(shù)據(jù)幀格式如圖4所示。
圖4 標(biāo)準(zhǔn)數(shù)據(jù)幀格式
標(biāo)準(zhǔn)數(shù)據(jù)幀由1bit的幀起始,然后是32bit仲裁場、6bit控制場、0~64bit數(shù)據(jù)場、16bit循環(huán)冗余碼CRC場、2bit應(yīng)答場,最后以7bit幀結(jié)尾。如果數(shù)據(jù)位全填滿,則CAN幀長為128bit。
傳輸時(shí)延是指一個(gè)站點(diǎn)從開始發(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ù)載率,幀長為F,有效載荷為m,則傳輸幀數(shù)N為
其中,[8L/m]表示對[8L/m]取上整。為計(jì)算方便,本文將其約等于8L/m,m取CAN總線最大載荷64bit。傳輸時(shí)延t為
對于CAN總線,F(xiàn)為128bit,R 為1Mbit/s。CAN總線負(fù)載率常在60%以下。當(dāng)總線負(fù)載率超過40%,系統(tǒng)性能將惡化,當(dāng)總線負(fù)載率超過60%,系統(tǒng)將不再穩(wěn)定[5],所以選用60%負(fù)載率,代入式(2)得
2.1.2以太網(wǎng)協(xié)議
Ethernet II和IEEE802.3是局域網(wǎng)中最常見的以太網(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ī)接下來字節(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)冗余檢測(cyclic redundantcy check,CRC)用于檢測幀中是否引入了差錯。數(shù)據(jù)字段為以太網(wǎng)幀的有效載荷,對于傳統(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,傳輸層為TCP等協(xié)議,首部占20。
設(shè)一幀全部填滿,則幀長F為1526B,以太網(wǎng)速率取10Mbit/s,有效載荷為數(shù)據(jù)長度為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(假定無選項(xiàng)),假設(shè)傳輸層采用TCP協(xié)議,TCP首部有20B。應(yīng)用層采用HTTP文件傳輸協(xié)議。網(wǎng)絡(luò)層、傳輸層占用至少了40B,浪費(fèi)了帶寬。為提高帶寬利用率,簡化以太網(wǎng)模型,可去掉各層首部,將網(wǎng)絡(luò)層、傳輸層和應(yīng)用層壓縮為一層,即將模型簡化為物理層、鏈路層和應(yīng)用層。此時(shí)有
CAN總線和以太網(wǎng)是兩種截然不同的通信方式,為實(shí)現(xiàn)二者融合,必須對傳輸協(xié)議進(jìn)行改進(jìn),為此本文提出率DNSA協(xié)議,用于CAN總線和以太網(wǎng)的對接。
DNSA協(xié)議是DNSA架構(gòu)中以太網(wǎng)和CAN總線的對接協(xié)議,組幀及解析均由圖2中交換機(jī)中的以太網(wǎng)-CAN總線對接模塊實(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é)議幀的正常傳輸,必須避開已有以太網(wǎng)幀類型碼[6],此處將類型定義為0x9931。以太網(wǎng)-CAN總線對接協(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ù)包對應(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ù)包為例說明數(shù)據(jù)包字段的組成情況,如表4所示。
表4 數(shù)據(jù)包字段格式
因?yàn)镃AN幀由4B的CANID和8B的CAN數(shù)據(jù)場組成,所以此處為CAN包分配12B長度,CAN包格式如表5所示。
表5 CAN包格式
CAN包用于定義設(shè)備部件的屬性值。CANID的前2B用于表示設(shè)備類型,后2B表示部件類型,8B的CAN數(shù)據(jù)中,前2B用于表示屬性類型,保留2B,后4B表示故障數(shù)據(jù)類型。
設(shè)備類型用于識別主機(jī)類型,如挖掘機(jī)、起重機(jī)等,設(shè)備及相應(yīng)的類型如表6所示。
表6 設(shè)備類型碼
部件類型碼用于識別機(jī)械部件,如發(fā)動機(jī)、油缸等,部件類型碼如表7所示。
表7 部件類型碼
屬性類型碼為數(shù)據(jù)本身代表的物理含義,如溫度、濕度等,屬性類型碼如表8所示。
表8 屬性類型碼
如果CAN包為0x0001 0001 0000 0000 1E,則表示起重機(jī)油缸溫度為30℃。在組幀和解析CAN包時(shí)需查詢設(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)通信模塊對數(shù)據(jù)包進(jìn)行分析,如果類型為0x9931,則認(rèn)為該數(shù)據(jù)報(bào)正確。取出數(shù)據(jù)段,根據(jù)協(xié)議進(jìn)行解析,取出CAN包數(shù)據(jù)填充CANID和CAN數(shù)據(jù),通過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)傳輸
為驗(yàn)證DNSA的有效性,我們將其用于泵車監(jiān)控系統(tǒng),以其中的臂架姿態(tài)控制為例進(jìn)行說明。遠(yuǎn)傳設(shè)備采用三一移動終端,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)動過程,將運(yùn)動過程傳給分布式控制器,分布式控制器用接收到的命令控制比例閥開關(guān),從而控制油缸伸縮,壓力傳感器可實(shí)時(shí)采集油缸出油口等位置壓力,作為分布式控制器對油缸平穩(wěn)運(yùn)動的判定依據(jù)。油缸信息也可根據(jù)用戶需要經(jīng)以太網(wǎng)傳輸至交換機(jī),交換機(jī)將以太網(wǎng)數(shù)據(jù)轉(zhuǎn)為CAN數(shù)據(jù)傳給發(fā)送機(jī)等部件。主控制器也可直接將某些實(shí)時(shí)性要求高的命令通過以太網(wǎng)、交換機(jī)和CAN總線傳回給執(zhí)行器,如臂架運(yùn)動過程,主控制器如果發(fā)現(xiàn)臂架處在即將碰撞的安全范圍外,將通過CAN總線強(qiáng)制停止發(fā)動機(jī)。
圖7 DNSA用于泵車監(jiān)控系統(tǒng)
通過式(3)和式(5)可以分別求CAN總線和以太網(wǎng)傳輸延時(shí),對比結(jié)果如圖8所示。
圖8 CAN和以太網(wǎng)傳輸延時(shí)
從圖8可看出,在相同負(fù)載率下,以太網(wǎng)傳輸延時(shí)明顯低于CAN總線,以太網(wǎng)傳輸速率可到100Mbit/s以 上,而 CAN 總 線 在 傳 輸 速 率1Mbit/s時(shí)速度基本達(dá)到了上限。因此說明以太網(wǎng)在大數(shù)據(jù)量傳輸時(shí)更占優(yōu)勢。
為驗(yàn)證DNSA的有效性,下面對CAN總線和以太網(wǎng)間的通信丟包率進(jìn)行測試。以太網(wǎng)到CAN總線發(fā)送數(shù)據(jù)分為600B、2kB、5MB三組,緩存區(qū)大小為1MB,發(fā)送次數(shù)為1000,丟包率如表9所示。
表9 以太網(wǎng)至CAN丟包率測試
在600B和2kB情況下,丟包率為0;在5M情況下,因?yàn)榫彺鎱^(qū)小于以太網(wǎng)所發(fā)數(shù)據(jù)包大小,而以太網(wǎng)發(fā)送速率遠(yuǎn)遠(yuǎn)大于CAN總線發(fā)送速率,所以會產(chǎn)生比較嚴(yán)重的丟包現(xiàn)象。CAN總線至以太網(wǎng)根據(jù)表10所設(shè)參數(shù)及分組進(jìn)行測試。因?yàn)镃AN總線速度小于以太網(wǎng)速度,所以從CAN總線至以太網(wǎng)基本上不會出現(xiàn)丟包現(xiàn)象。
表10 CAN總線至以太網(wǎng)丟包率測試
對于丟包,可從如下幾方面做改進(jìn):①提高數(shù)據(jù)接收處理線程優(yōu)先級;②對于數(shù)據(jù)完整性要求高的CAN設(shè)備采用一對一連接;③在應(yīng)用層加入應(yīng)答重傳機(jī)制;④從總線拓?fù)浣嵌?,尋找最?yōu)布置線路方案。
實(shí)際工程應(yīng)用中,主要是將底層數(shù)據(jù)通過CAN總線傳送至以太網(wǎng),而以太網(wǎng)至CAN總線傳輸?shù)氖侵骺刂苹蚱渌植际娇刂破飨掳l(fā)的一些控制命令,很少出現(xiàn)1MB以上的文件,所以本設(shè)計(jì)能很好地滿足工程需求。
本文結(jié)合CAN總線可靠性高和以太網(wǎng)吞吐量大、資源共享能力強(qiáng)等優(yōu)點(diǎn),建構(gòu)了一種適合工程機(jī)械控制領(lǐng)域的DNSA構(gòu)架,重點(diǎn)對CAN總線和以太網(wǎng)的對接模塊進(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)場多部件、智能化、高可靠性和高實(shí)時(shí)性的通信需求。
[1]張炳賢.工程機(jī)械的智能化趨勢與發(fā)展對策[J].企業(yè)技術(shù)開發(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)控的無線通信協(xié)議[J].中國工程機(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]陳曦,楊振興,柳國輝.CAN總線和以太網(wǎng)在中央空調(diào)系統(tǒng)遠(yuǎn)程監(jiān)控中的應(yīng)用[J].工業(yè)儀表與自動化裝置,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í)延分析及對策[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.