可用于云制造環(huán)境的新型現(xiàn)場總線協(xié)議

胡鐵楠，呂云蕾，劉亞秋

(東北林業(yè)大學 信息與計算機工程學院，黑龍江 哈爾濱 150040)

0 引 言

云制造是一種面向服務的、高效低耗的新型制造模式。其關鍵技術之一便是將分散的物理資源接入云平臺進行集中管理，這也是將物理資源虛擬映射為虛擬資源以向用戶推送服務的前提。在云制造關鍵技術研究方面：文獻[1]對云制造平臺中計算資源和制造資源的調(diào)度、企業(yè)層調(diào)度和車間層調(diào)度問題進行了綜述。文獻[2]針對現(xiàn)有集中模式的局限性，研究了云制造中面向自治的SCOS方法。文獻[3]提出了一種DPDCM優(yōu)化模型，以滿足公司在云制造環(huán)境中執(zhí)行DPD的各種要求。文獻[4]提出一種分布式對等網(wǎng)絡架構(gòu)，以提高云制造的安全性和可擴展性。文獻[5]提出了眾包是云制造戰(zhàn)略實施的一種有效運作模式，從眾包角度實現(xiàn)了云制造。文獻[6]提出一種面向設備資源組合服務鏈的方法以有效地對云制造環(huán)境下的異地設備資源進行優(yōu)化選擇?，F(xiàn)有的研究成果大多為對云制造上層服務資源的建模與描述，在針對云制造環(huán)境下制造資源層的接入研究很少，為此，本文針對云制造模式底層的物理資源，設計多協(xié)議轉(zhuǎn)換模塊支持不同數(shù)據(jù)接口的加工制造設備，并研究一種新型云現(xiàn)場總線用于資源匯集池與多協(xié)議轉(zhuǎn)換模塊之間的數(shù)據(jù)交換，結(jié)合兩者屏蔽各種物理資源接口協(xié)議之間的異構(gòu)性，對硬制造資源進行統(tǒng)一接入云平臺，解決云制造底層物理資源難以接入的問題。

1 云制造平臺資源接入模型構(gòu)建

作為云制造模式的關鍵技術之一，各種物理資源向云制造平臺的接入在云制造模式中占有十分重要的地位，由于其處于云制造模式的底層，直接關系到上層虛擬映射的實現(xiàn)與否，因而物理資源的接入成為云制造模式實現(xiàn)過程中的重中之重。

1.1 云制造模式整體模型

云制造虛擬化整體模型可分為物理資源層、物理資源接入層、物理資源描述層、映射規(guī)則層以及虛擬資源層[7]，如圖1所示。

圖1 云制造整體模型

物理資源層包括軟制造資源和硬制造資源，是實現(xiàn)加工制造的實體資源；物理資源接入層將眾多物理資源接入云制造平臺；軟制造資源可通過交互接口、人工錄入的方式接入云制造平臺，而硬制造資源則需要通過讀取其參數(shù)數(shù)據(jù)將其數(shù)據(jù)化后接入云制造平臺；物理資源描述層是對物理資源功能屬性的具體描述，通過資源描述模板建立虛擬機器，導入屬性信息，此層實現(xiàn)了物理資源在計算機的體現(xiàn)，對物理資源的虛擬映射提供條件[8]；映射規(guī)則為物理資源與虛擬資源之間的映射關系，基于物理資源描述層的物理資源描述進行虛擬映射，有一對一、一對多、多對一映射方式，例如物理的銑床及其操作方式可以映射為虛擬的銑服務，銑鉆二合一機床可以映射為虛擬的銑服務和鉆服務，而虛擬發(fā)動機氣缸加工服務則需要多臺機床以及氣缸加工工藝共同映射完成；虛擬資源層為通過映射規(guī)則將物理資源轉(zhuǎn)化為虛擬資源，接入云制造虛擬資源池進行統(tǒng)一集中管理，并向用戶推送服務。

1.2 物理資源接入模型

作為物理資源接入方的企業(yè)，需將本企業(yè)的物理資源接入云制造平臺，對于軟制造資源和硬制造資源，采用不同的接入方式。

軟制造資源的接入：軟制造資源一般為工程師、技術員、理論知識等，這類資源的接入相對簡單，可采用人機交互接口、數(shù)據(jù)化存入數(shù)據(jù)庫的方式接入云平臺[9]。

硬制造資源的接入：硬制造資源具有物理存在性，需要對其運行中實時狀態(tài)數(shù)據(jù)接入。在工廠加工車間中，通常采用現(xiàn)場總線技術對各種設備狀態(tài)進行傳遞，云制造模式的硬制造資源同樣采用現(xiàn)場總線技術將不同的加工設備的狀態(tài)信息接入到資源管理系統(tǒng)，企業(yè)物理資源的接入模型如圖2所示。

圖2 企業(yè)物理資源接入模型

然而不同廠商生產(chǎn)的設備所支持的總線協(xié)議不盡相同，資源管理系統(tǒng)無法提供各式各樣的接口以迎合不同廠商的加工設備，對物理資源的接入造成了極大的阻礙。針對總線協(xié)議異構(gòu)性大的問題，本文設計了一種新型云現(xiàn)場總線Cloud_Field_Bus，資源管理系統(tǒng)只需提供Cloud_Field_Bus總線接口，整個車間所有設備的狀態(tài)數(shù)據(jù)均通過Cloud_Field_Bus總線上傳到資源管理系統(tǒng)，并設計多協(xié)議轉(zhuǎn)換模塊，實現(xiàn)多種總線協(xié)議與Cloud_Field_Bus總線協(xié)議的雙向轉(zhuǎn)換，解決因現(xiàn)場設備接口異構(gòu)性大而難以接入硬制造資源的問題。

2 新型云現(xiàn)場總線Cloud_Field_Bus

ISO(國際標準化組織)組織研究的網(wǎng)絡互聯(lián)OSI參考模型，定義了網(wǎng)絡互連的7層框架，即物理層、數(shù)據(jù)鏈路層、網(wǎng)絡層、傳輸層、會話層、表示層和應用層，本課題研究的新型云現(xiàn)場總線Cloud_Field_Bus也以該參考模型為標準，為保證Cloud_Field_Bus總線響應迅速，只設計7層框架中的物理層和數(shù)據(jù)鏈路層。在多協(xié)議轉(zhuǎn)換系統(tǒng)中，一端為Cloud_Field_Bus協(xié)議總線，另一端為掛接加工設備的多種其它標準總線，Cloud_Field_Bus協(xié)議總線負責將所有其它現(xiàn)場總線傳遞到多協(xié)議轉(zhuǎn)換模塊的數(shù)據(jù)，即整個制造加工車間所有制造設備的狀態(tài)數(shù)據(jù)上傳至資源管理系統(tǒng)，由此可見Cloud_Field_Bus協(xié)議總線需要傳輸?shù)臄?shù)據(jù)量大，需要較大的傳輸速率，因而選用以太網(wǎng)IEEE802.3協(xié)議物理層，數(shù)據(jù)鏈路層以IEEE802.3協(xié)議數(shù)據(jù)鏈路層為基礎，對其LLC子層進行修改，設計Cloud_LLC子層以良好兼容多協(xié)議轉(zhuǎn)換模塊。

2.1 數(shù)據(jù)鏈路層分析

數(shù)據(jù)鏈路層以IEEE802.3協(xié)議數(shù)據(jù)鏈路層為基礎，保持其MAC子層不變，對其LLC子層進行修改，設計Cloud_LLC子層幀格式替代原有的LLC子層。

2.1.1 標準以太網(wǎng)幀格式

以太網(wǎng)數(shù)據(jù)幀的格式如圖3所示，以太網(wǎng)數(shù)據(jù)幀由前導碼、目的主機地址、源主機地址、幀類型、數(shù)據(jù)、CRC構(gòu)成。

圖3 標準以太網(wǎng)幀格式

前導碼：占8個字節(jié)，用于目的主機和源主機的時鐘同步，約定通信速率。

目的從機地址：以太網(wǎng)中該地址占6個字節(jié)，為目的從機的硬件地址。

源主機地址：以太網(wǎng)中該地址占6個字節(jié)，為源主機的硬件地址。

幀類型：占2個字節(jié)，表示數(shù)據(jù)幀的類型。

數(shù)據(jù)：該區(qū)占用字節(jié)數(shù)應在1500以下，最小字節(jié)數(shù)為46，字節(jié)數(shù)不足46要進行填充。

CRC：占4個字節(jié)，用于數(shù)據(jù)的CRC校驗[10,11]。

2.1.2 Cloud_Field_Bus協(xié)議幀格式

LLC子層數(shù)據(jù)幀最大支持1500字節(jié)數(shù)據(jù)，Cloud_LLC子層把這1500字節(jié)數(shù)據(jù)作為多協(xié)議轉(zhuǎn)換模塊的數(shù)據(jù)組，將其劃分為15等分數(shù)據(jù)段，每個數(shù)據(jù)段100字節(jié)，其中1字節(jié)為次目的地址號，其余99字節(jié)提供給用戶數(shù)據(jù)使用，用戶可自由選用其中數(shù)據(jù)段，Cloud_Field_Bus協(xié)議總線的用戶程序便是通過次目的地址號來尋找協(xié)議轉(zhuǎn)換系統(tǒng)中的緩沖區(qū)；此外Cloud_LLC子層幀格式還包含前導碼、源主機地址、主目的地址、有效數(shù)據(jù)段數(shù)量以及CRC校驗。Cloud_LLC幀格式如圖4所示。

圖4 Cloud_LLC幀格式

前導碼：與標準以太網(wǎng)相同。

主目的地址：Cloud_Field_Bus中該地址占6個字節(jié)，為目的多協(xié)議轉(zhuǎn)換模塊地址。

源主機地址：Cloud_Field_Bus中該地址占6個字節(jié)，為源資源管理中心地址。

數(shù)據(jù)段數(shù)量：占2個字節(jié)，表示有效數(shù)據(jù)段的數(shù)量。

數(shù)據(jù)：該區(qū)由數(shù)據(jù)段數(shù)量配置，每段占有100字節(jié)，首字節(jié)作為次目的地址，其余99字節(jié)作為用戶數(shù)據(jù)，最多15段。

CRC：與標準以太網(wǎng)相同。

Cloud_LLC子層向上層提供需響應的非連接服務Cloud_REPLY與無需響應的非連接服務Cloud_UNREPLY。Cloud_REPLY服務允許主站點Cloud_LLC用戶發(fā)送一組數(shù)據(jù)到從站點Cloud_LLC用戶，并接收一個來自從站點的響應幀，此時表示數(shù)據(jù)已經(jīng)無誤傳達到從站點，除此之外從站點也需要向主站點返回數(shù)據(jù)，因而Cloud_Field_Bus協(xié)議的Cloud_LLC服務不僅要求從站發(fā)送響應幀中表示已經(jīng)無誤的接收數(shù)據(jù)，還必須發(fā)送數(shù)據(jù)返回到主站點，該服務用于主從站點之間的數(shù)據(jù)交換。Cloud_UNREPLY服務則僅是主站點Cloud_LLC用戶發(fā)送一組數(shù)據(jù)到從站點Cloud_LLC用戶，從站點返回響應幀即可，無需再向主站點返回數(shù)據(jù)，該服務用于主站向從站發(fā)送設置數(shù)據(jù)。

2.2 Cloud_User接口設計

為保證總線的實時性，Cloud_Field_Bus協(xié)議不涉及數(shù)據(jù)鏈路層之上的架構(gòu)，因而設計Cloud_User接口原語映射Cloud_LLC子層Cloud_REPLY服務和Cloud_UNREPLY服務。

Cloud_User接口中Usr_Set_port原語映射Cloud_LLC子層的Cloud_UNREPLY服務，應用程序通過該原語設置數(shù)據(jù)幀中的可用數(shù)據(jù)段數(shù)量，該原語促使主站點的Cloud_LLC用戶向從站點的Cloud_LLC用戶發(fā)送數(shù)據(jù)，該原語無需從機返回數(shù)據(jù)；Usr_Data_Exchange原語映射Cloud_LLC子層的Cloud_REPLY服務，應用程序調(diào)用該原語促使主站點的Cloud_LLC用戶向從站點的Cloud_LLC用戶發(fā)送數(shù)據(jù)，并向從站點即多協(xié)議轉(zhuǎn)換模塊請求數(shù)據(jù)，兩種原語的功能及參數(shù)見表1、表2。

表1 Usr_Set_port原語參數(shù)

具體參數(shù)功能：

Rem_Add：設置多協(xié)議轉(zhuǎn)換模塊的主目的地址；

Req_Add：設置資源管理中心的源地址；

Status： 指示該原語的成功或失敗；

Amount：設置數(shù)據(jù)段使用數(shù)量。

表2 Usr_Data_Exchange原語參數(shù)

具體參數(shù)功能：

參數(shù)Rem_Add、Req_Add及Status的功能與Usr_Set_port中相同，此處不再贅述。

In_Data0-15：此參數(shù)包含輸入的Cloud_LLC中多個數(shù)據(jù)段的用戶數(shù)據(jù)以及次目的地址，數(shù)據(jù)段數(shù)量由Usr_Set_port原語中Amount參數(shù)配置。

Out_Data0-15：此參數(shù)包含輸出的Cloud_LLC中多個數(shù)據(jù)段的用戶數(shù)據(jù)以及次目的地址，數(shù)據(jù)段數(shù)量由Usr_Set_port原語中Amount參數(shù)配置。

Cloud_Field_Bus協(xié)議采用主從通信模式，主機用戶通過請求原語(Request)向從機請求數(shù)據(jù)，并通過確認原語(Confirm)進行確認，由主機發(fā)送的請求原語(Request)到達從機后成為指示原語(Indication)，完成一次通信。應用程序程序必須先通過Usr_Set_port原語對Usr_Data_Exchange原語的In_Data0-15參數(shù)和Out_Data0-15參數(shù)進行數(shù)據(jù)段數(shù)量配置，再通過Usr_Data_Exchange原語對數(shù)據(jù)進行收發(fā)。其執(zhí)行順序如圖5所示。

圖5 Usr_Set_port原語與Usr_Data_Exchange原語執(zhí)行順序

2.3 多協(xié)議轉(zhuǎn)換模塊

云制造企業(yè)加工車間中，每間車間裝有各種不同的加工設備，這些設備提供的通訊接口互不兼容，為解決該問題，本文設計多協(xié)議轉(zhuǎn)換模塊，資源管理系統(tǒng)提供單一Cloud_Field_Bus總線協(xié)議接口，通過協(xié)議轉(zhuǎn)換將多種不同總線協(xié)議轉(zhuǎn)換成Cloud_Field_Bus總線協(xié)議，整個車間的狀態(tài)數(shù)據(jù)通過Cloud_Field_Bus總線協(xié)議一次上傳。通過協(xié)議轉(zhuǎn)換和新型Cloud_Field_Bus總線協(xié)議將資源管理系統(tǒng)與加工設備徹底隔離開來，利于各個加工設備的添加、移除或者更換，實現(xiàn)云制造硬制造資源的接入。

2.3.1 多協(xié)議轉(zhuǎn)換模塊設計

用戶數(shù)據(jù)以某種總線協(xié)議傳輸，即是在用戶數(shù)據(jù)前后加上該協(xié)議的幀頭和幀尾，然后裝載到特定的物理層上以一定的比特流進行發(fā)送，總線協(xié)議的不同之處在于幀格式以及在物理總線上的比特流。因而不同總線協(xié)議之間的轉(zhuǎn)換，首先需要具備物理層的支持，以實現(xiàn)比特流的傳輸，在鏈路層，得到一幀數(shù)據(jù)后，需要對幀格式進行轉(zhuǎn)換，去掉該總線協(xié)議的幀頭和幀尾，提取出用戶數(shù)據(jù)，再加上另一種總線的幀頭和幀尾，裝載到物理層上進行傳輸；多協(xié)議轉(zhuǎn)換模塊則是支持多種總線協(xié)議幀頭和幀尾的拆分以及重組，即可實現(xiàn)多種異構(gòu)協(xié)議之間的相互轉(zhuǎn)換[12]。

本文設計的多協(xié)議轉(zhuǎn)換模塊是專門為云制造硬制造資源接入而設計，其一端僅支持Cloud_Field_Bus總線接口，另一端支持多種其它類型總線接口，實現(xiàn)一對多協(xié)議轉(zhuǎn)換，多協(xié)議轉(zhuǎn)換模塊總體模型如圖6所示。

圖6 多協(xié)議轉(zhuǎn)換模塊總體模型

Cloud_Field_Bus協(xié)議幀進入多協(xié)議轉(zhuǎn)換模塊后，Cloud_Field_Bus協(xié)議處理模塊去掉Cloud_Field_Bus協(xié)議的幀頭和幀尾，得到用戶數(shù)據(jù)并存儲在Cloud_Field_Bus協(xié)議輸入緩沖區(qū)，中央處理模塊通過數(shù)據(jù)段所包含的次目的地址，將Cloud_Field_Bus協(xié)議輸入緩沖區(qū)中的數(shù)據(jù)組以數(shù)據(jù)段為單位存儲在A、B、C、D這4種協(xié)議輸出緩沖區(qū)，由其各自的協(xié)議處理模塊加上各自協(xié)議的幀頭和幀尾，發(fā)送到遠端；反向傳輸亦然。

2.3.2 多協(xié)議轉(zhuǎn)換模塊實現(xiàn)

多協(xié)議轉(zhuǎn)換模塊要求能夠?qū)崿F(xiàn)多種不同協(xié)議與Cloud_Field_Bus協(xié)議之間的轉(zhuǎn)換，多協(xié)議轉(zhuǎn)換模塊作為Cloud_Field_Bus協(xié)議從站點，需要具備Cloud_Field_Bus協(xié)議從站點模塊以及其它協(xié)議的協(xié)議芯片，暫存數(shù)據(jù)的輸入輸出緩沖區(qū)則需要RAM存儲器實現(xiàn)，采用微控制器作為中央處理單元。多協(xié)議轉(zhuǎn)換模塊通過軟件為每種協(xié)議緩沖區(qū)分配唯一端口號，端口號與Cloud_Field_Bus協(xié)議數(shù)據(jù)幀的次目的地址相對應，通過次目的地址將用戶數(shù)據(jù)存儲在相應端口號的緩沖區(qū)中；主程序負責對各種協(xié)議用戶數(shù)據(jù)的提取，幀頭幀尾的添加以及對緩沖區(qū)數(shù)據(jù)的讀寫，通過軟件控制硬件各個模塊，從而實現(xiàn)其它協(xié)議和Cloud_Field_Bus協(xié)議之間的轉(zhuǎn)換，多協(xié)議轉(zhuǎn)換模塊程序流程如圖7所示。

圖7 多協(xié)議轉(zhuǎn)換模塊程序流程

系統(tǒng)上電首先對各個模塊進行初始化操作，然后根據(jù)需求設置可用端口，將開啟的端口對應的輸入緩沖區(qū)的數(shù)據(jù)寫入Cloud_Field_Bus協(xié)議輸出緩沖區(qū)，為主站點的數(shù)據(jù)請求準備數(shù)據(jù)，若收到主站點請求，則將Cloud_Field_Bus協(xié)議輸出緩沖區(qū)數(shù)據(jù)回復給主站點，同時提取Cloud_Field_Bus協(xié)議數(shù)據(jù)寫入Cloud_Field_Bus協(xié)議輸入緩沖區(qū)，并根據(jù)此目的地址依次將數(shù)據(jù)依次寫入其它協(xié)議的輸出緩沖區(qū)，并通過相應協(xié)議發(fā)送到遠端。

3 Cloud_Field_Bus協(xié)議性能分析測試

由于Cloud_Field_Bus協(xié)議是在以太網(wǎng)物理層、數(shù)據(jù)鏈路層的基礎上進行優(yōu)化設計得來，并采用主從通信模式，因而通過對比實驗與性能較優(yōu)的工業(yè)級現(xiàn)場總線profibus-DP協(xié)議作比較，對比數(shù)據(jù)交換過程中兩種協(xié)議的報文循環(huán)時間以及編碼效率來分析Cloud_Field_Bus協(xié)議性能的優(yōu)劣。

3.1 報文循環(huán)時間

兩種協(xié)議采用主從通信模式，每一次報文循環(huán)內(nèi)，主站點向從站點發(fā)送數(shù)據(jù)并向從站點請求數(shù)據(jù)，從站點在響應幀中包含數(shù)據(jù)返回給主站點，一次循環(huán)結(jié)束。報文循環(huán)時間是傳輸1 bit數(shù)據(jù)所需要的時間乘以傳輸?shù)目倲?shù)據(jù)位數(shù)。因而報文循環(huán)時間TC可用式(1)表示

(1)

其中，N為網(wǎng)絡中的從站點個數(shù)；TSLV(i) 為對第i個從站點進行請求所需要的時間；Tinter為幀間間隙。Cloud_Field_Bus協(xié)議取Tinter=192Tbit。

對于Cloud_Field_Bus協(xié)議，由于其只定義了物理層和數(shù)據(jù)鏈路層，因而Cloud_Field_Bus協(xié)議數(shù)據(jù)幀并不包含傳統(tǒng)以太網(wǎng)的上層幀數(shù)據(jù)，僅包括8個字節(jié)前導碼、6個字節(jié)主目的地址、6個字節(jié)源主機地址、2個字節(jié)數(shù)據(jù)段數(shù)量、4個字節(jié)CRC校驗碼以及4個字節(jié)的LLC幀頭，次目的地址包含在用戶數(shù)據(jù)中，不屬于固定數(shù)據(jù)，因而一幀數(shù)據(jù)有30個字節(jié)的固定數(shù)據(jù)。當主站點發(fā)送和接收的數(shù)據(jù)均滿足Cloud_Field_Bus協(xié)議數(shù)據(jù)幀最短幀要求時，Cloud_Field_Bus協(xié)議訪問第i個字節(jié)所需的時間為

TSLV(i)=[2×30×8+8(Ii+Oi)]·Tbit

(2)

其中，Ii是主站點發(fā)送給第i個從站點的數(shù)據(jù)字節(jié)數(shù)；Oi是第i個從站點返回給主站點的數(shù)據(jù)字節(jié)數(shù)；Tbit是傳輸1 bit數(shù)據(jù)的單位時間。由于Cloud_Field_Bus協(xié)議源于傳統(tǒng)以太網(wǎng)，因而與以太網(wǎng)數(shù)據(jù)幀同樣有最短字節(jié)限制，因此式(2)只在Cloud_Field_Bus協(xié)議主站點與從站點間交互的數(shù)據(jù)幀大于72 Byte時才有效，數(shù)據(jù)幀少于這個最短字節(jié)數(shù)是會在數(shù)據(jù)域中填充一些無效字節(jié)，Cloud_Field_Bus協(xié)議報文循環(huán)時間如式(3)所示

(3)

對于profibus-DP協(xié)議，在只有一個主站點的profibus-DP環(huán)境中，數(shù)據(jù)交換過程中其報文循環(huán)時間如式(4)所示

(4)

其中，N為網(wǎng)絡中的從站點個數(shù)；Tif與Cloud_Field_Bus協(xié)議中Tinter含義相同且Tif=192Tbit；Tftx為發(fā)送固定數(shù)據(jù)所需的時間，取Tftx=231Tbit。LIO為主站點發(fā)送并請求從站點的數(shù)據(jù)字節(jié)數(shù)。代入式(4)可得profibus-DP協(xié)議的報文循環(huán)時間如式(5)所示

(5)

3.2 報文編碼效率

報文編碼效率同樣是衡量一個協(xié)議優(yōu)劣的重要指標。協(xié)議的報文編碼效率是指在一次數(shù)據(jù)交換過程中有用數(shù)據(jù)與交換的總數(shù)據(jù)的位數(shù)之比，其計算公式如下

(6)

其中，NData為數(shù)據(jù)交換過程中有用數(shù)據(jù)位數(shù)；NFrame為數(shù)據(jù)交換過程中總數(shù)據(jù)位數(shù)。

對于Cloud_Field_Bus協(xié)議，根據(jù)其數(shù)據(jù)幀格式，當傳輸字節(jié)數(shù)少于42字節(jié)時，需要在數(shù)據(jù)域中無用的字節(jié)以滿足其最短幀長度要求。當傳輸字節(jié)數(shù)多于42字節(jié)時，則無需填充無用字節(jié)。因此Cloud_Field_Bus協(xié)議的報文編碼效率如下式所示

(7)

對于profibus-DP協(xié)議，在只有一個主站點的profibus-DP環(huán)境中，數(shù)據(jù)交換過程中其報文編碼效率如下式所示

(8)

3.3 誤碼率

誤碼率是衡量數(shù)字通信系統(tǒng)可靠性的重要指標。誤碼率是在傳輸過程中發(fā)生誤碼的碼元個數(shù)與傳輸?shù)目偞a元數(shù)之比，用Pe表示

(9)

誤碼率的大小由通路的系統(tǒng)特性和信道質(zhì)量決定，誤碼率與兩者均成反比關系，即系統(tǒng)特性與信道質(zhì)量越好，則誤碼率越低。對于多數(shù)的通信系統(tǒng)來說，如光纖通信，千兆以太網(wǎng)，PCI Expree，USB2.0等都要求接收機的誤碼率應小于10-10甚至更低。

3.4 分析測試

本文實驗環(huán)境采用NS2網(wǎng)絡仿真軟件，NS2用C++語言和OTcl語言共同開發(fā)，是一款面向?qū)ο蟛⒂墒录?qū)動的網(wǎng)絡模擬器，可以模擬各種常見的網(wǎng)絡協(xié)議，本實驗在Ubuntu系統(tǒng)上安裝了NS2軟件，創(chuàng)建新協(xié)議需要在NS-3.35目錄下添加新協(xié)議的算法。

創(chuàng)建Cloud_Field_Bus協(xié)議的具體步驟是：

(1)編寫Cloud_Field_Bus協(xié)議的C++類；

(2)編寫Cloud_Field_Bus協(xié)議類的成員函數(shù)；

(3)編寫TCL相關的類和變量；

(4)綁定C++代碼和TCL；

(5)修改packet.h文件向NS2添加Cloud_Field_Bus協(xié)議。

在NS2中創(chuàng)建Cloud_Field_Bus協(xié)議部分偽代碼如下所示。

Cloud_PingAgent_command()

{

If (參數(shù)數(shù)量為2)

{

If (參數(shù)類型為send)

{

創(chuàng)建新的數(shù)據(jù)包；

訪問新數(shù)據(jù)包的ping標頭；

保存當前時間；

發(fā)送數(shù)據(jù)包；

返回成功；

}

}

Else 調(diào)用基類的command函數(shù)；

}

參數(shù)設定Cloud_Field_Bus協(xié)議和profibus-DP協(xié)議網(wǎng)絡均有1個主站點和5個從站點，且每個從站點皆與主站點交換相同的字節(jié)數(shù)；設定Cloud_Field_Bus協(xié)議訪問鏈路帶寬為10 Mbit/s，profibus-DP協(xié)議訪問鏈路帶寬設定為其最高的12 Mbit/s，進行報文循環(huán)時間以及編碼效率對比實驗；設定Cloud_Field_Bus協(xié)議訪問鏈路帶寬分別為 100 Mbit/s 和200 Mbit/s進行誤碼率對比實驗。

Cloud_Field_Bus協(xié)議與profibus-DP協(xié)議報文循環(huán)時間仿真對比結(jié)果如表3、圖8所示。Cloud_Field_Bus協(xié)議與profibus-DP協(xié)議報文編碼效率仿真對比結(jié)果如表4、圖9 所示。Cloud_Field_Bus協(xié)議分別為100 Mbit/s和200 Mbit/s訪問鏈路帶寬時的誤碼率仿真結(jié)果如圖10所示。

表3 部分傳輸字節(jié)數(shù)與報文循環(huán)時間數(shù)據(jù)

圖8 傳輸字節(jié)數(shù)與報文循環(huán)時間關系

由圖8、圖9可以看出，在相同的條件下，在傳輸數(shù)據(jù)字節(jié)數(shù)較少時，profibus-DP協(xié)議的報文循環(huán)時間小于Cloud_Field_Bus協(xié)議，但隨著傳輸數(shù)據(jù)字節(jié)數(shù)增加，profibus-DP協(xié)議的報文循環(huán)時間便超過Cloud_Field_Bus協(xié)議，且二者差距越來越大，并且本實驗profibus-DP協(xié)議傳輸速率采用12 Mibt/s，實際在工程中其傳輸速率一般僅為1.5 Mibt/s，遠遠小于12 Mibt/s，而Cloud_Field_Bus協(xié)議采用以太網(wǎng)的物理層，速率可達百兆甚至千兆，由此可見Cloud_Field_Bus協(xié)議傳輸速率遠勝于profibus-DP協(xié)議，報文循環(huán)時間遠小于profibus-DP協(xié)議；對于報文編碼效率，由于Cloud_Field_Bus協(xié)議數(shù)據(jù)幀需要添加無用數(shù)據(jù)，在傳輸數(shù)據(jù)字節(jié)數(shù)較少時，profibus-DP協(xié)議的報文編碼效率高于Cloud_Field_Bus協(xié)議，但隨著傳輸數(shù)據(jù)字節(jié)數(shù)增加，Cloud_Field_Bus協(xié)議數(shù)據(jù)幀有用數(shù)據(jù)字節(jié)數(shù)可滿足其最短幀要求，Cloud_Field_Bus協(xié)議的報文編碼效率便超過了profibus-DP協(xié)議。圖10中分別為100 Mbit/s鏈路帶寬和200 Mbit/s鏈路帶寬的誤碼率仿真結(jié)果，從仿真結(jié)果可以看到，100 Mbit/s鏈路帶寬的誤碼率峰值比200 Mbit/s鏈路帶寬的誤碼率要高，兩者平均誤碼率均為10-12左右，200 Mbit/s鏈路帶寬的誤碼率峰值在10-10以下，滿足總線協(xié)議誤碼率最高限度。

表4 部分傳輸字節(jié)數(shù)與報文編碼效率數(shù)據(jù)

圖9 傳輸字節(jié)數(shù)與編碼效率關系

圖10 鏈路帶寬分別為100 Mbit/s和 200 Mbit/s時誤碼率對比

4 結(jié)束語

本文在以太網(wǎng)協(xié)議的基礎上，設計了一種新型的現(xiàn)場總線協(xié)議Cloud_Field_Bus以及多協(xié)議轉(zhuǎn)換模塊，用于對云制造物理資源的實時接入。通過仿真實驗對比Cloud_Field_Bus協(xié)議與profibus-DP協(xié)議的報文循環(huán)時間和編碼效率，并對比Cloud_Field_Bus協(xié)議分別在100 Mbit/s鏈路帶寬和100 Mbit/s鏈路帶寬時的誤碼率，實驗結(jié)果表明了Cloud_Field_Bus協(xié)議信息表達的高效性和傳輸可靠性。因而在對云制造企業(yè)現(xiàn)場設備海量的數(shù)據(jù)實時傳輸環(huán)境中，Cloud_Field_Bus協(xié)議既可保證其現(xiàn)場工作的實時性，又能輕易的對海量數(shù)據(jù)進行傳輸；多協(xié)議轉(zhuǎn)換模塊則屏蔽通訊接口的異構(gòu)性；結(jié)合兩者，在一定程度上解決了云制造系統(tǒng)中底層資源難以接入的難題。對于低帶寬傳輸誤碼率較大問題有待進一步解決。