胡鐵楠，呂云蕾，劉亞秋

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

0 引 言

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

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

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

1.1 云制造模式整體模型

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

圖1 云制造整體模型

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

1.2 物理資源接入模型

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

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

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

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

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

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

ISO(國際標(biāo)準(zhǔn)化組織)組織研究的網(wǎng)絡(luò)互聯(lián)OSI參考模型，定義了網(wǎng)絡(luò)互連的7層框架，即物理層、數(shù)據(jù)鏈路層、網(wǎng)絡(luò)層、傳輸層、會(huì)話層、表示層和應(yīng)用層，本課題研究的新型云現(xiàn)場總線Cloud_Field_Bus也以該參考模型為標(biāo)準(zhǔn)，為保證Cloud_Field_Bus總線響應(yīng)迅速，只設(shè)計(jì)7層框架中的物理層和數(shù)據(jù)鏈路層。在多協(xié)議轉(zhuǎn)換系統(tǒng)中，一端為Cloud_Field_Bus協(xié)議總線，另一端為掛接加工設(shè)備的多種其它標(biāo)準(zhǔn)總線，Cloud_Field_Bus協(xié)議總線負(fù)責(zé)將所有其它現(xiàn)場總線傳遞到多協(xié)議轉(zhuǎn)換模塊的數(shù)據(jù)，即整個(gè)制造加工車間所有制造設(shè)備的狀態(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ù)鏈路層為基礎(chǔ)，對其LLC子層進(jìn)行修改，設(shè)計(jì)Cloud_LLC子層以良好兼容多協(xié)議轉(zhuǎn)換模塊。

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

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

2.1.1 標(biāo)準(zhǔn)以太網(wǎng)幀格式

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

圖3 標(biāo)準(zhǔn)以太網(wǎng)幀格式

前導(dǎo)碼：占8個(gè)字節(jié)，用于目的主機(jī)和源主機(jī)的時(shí)鐘同步，約定通信速率。

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

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

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

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

CRC：占4個(gè)字節(jié)，用于數(shù)據(jù)的CRC校驗(yàn)[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等分?jǐn)?shù)據(jù)段，每個(gè)數(shù)據(jù)段100字節(jié)，其中1字節(jié)為次目的地址號(hào)，其余99字節(jié)提供給用戶數(shù)據(jù)使用，用戶可自由選用其中數(shù)據(jù)段，Cloud_Field_Bus協(xié)議總線的用戶程序便是通過次目的地址號(hào)來尋找協(xié)議轉(zhuǎn)換系統(tǒng)中的緩沖區(qū)；此外Cloud_LLC子層幀格式還包含前導(dǎo)碼、源主機(jī)地址、主目的地址、有效數(shù)據(jù)段數(shù)量以及CRC校驗(yàn)。Cloud_LLC幀格式如圖4所示。

圖4 Cloud_LLC幀格式

前導(dǎo)碼：與標(biāo)準(zhǔn)以太網(wǎng)相同。

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

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

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

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

CRC：與標(biāo)準(zhǔn)以太網(wǎng)相同。

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

2.2 Cloud_User接口設(shè)計(jì)

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

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

表1 Usr_Set_port原語參數(shù)

具體參數(shù)功能：

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

Req_Add：設(shè)置資源管理中心的源地址；

Status： 指示該原語的成功或失?。?/p>

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

表2 Usr_Data_Exchange原語參數(shù)

具體參數(shù)功能：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.1 報(bào)文循環(huán)時(shí)間

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

(1)

其中，N為網(wǎng)絡(luò)中的從站點(diǎn)個(gè)數(shù)；TSLV(i) 為對第i個(gè)從站點(diǎn)進(jìn)行請求所需要的時(shí)間；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個(gè)字節(jié)前導(dǎo)碼、6個(gè)字節(jié)主目的地址、6個(gè)字節(jié)源主機(jī)地址、2個(gè)字節(jié)數(shù)據(jù)段數(shù)量、4個(gè)字節(jié)CRC校驗(yàn)碼以及4個(gè)字節(jié)的LLC幀頭，次目的地址包含在用戶數(shù)據(jù)中，不屬于固定數(shù)據(jù)，因而一幀數(shù)據(jù)有30個(gè)字節(jié)的固定數(shù)據(jù)。當(dāng)主站點(diǎn)發(fā)送和接收的數(shù)據(jù)均滿足Cloud_Field_Bus協(xié)議數(shù)據(jù)幀最短幀要求時(shí)，Cloud_Field_Bus協(xié)議訪問第i個(gè)字節(jié)所需的時(shí)間為

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

(2)

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

(3)

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

(4)

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

(5)

3.2 報(bào)文編碼效率

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

(6)

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

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

(7)

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

(8)

3.3 誤碼率

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

(9)

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

3.4 分析測試

本文實(shí)驗(yàn)環(huán)境采用NS2網(wǎng)絡(luò)仿真軟件，NS2用C++語言和OTcl語言共同開發(fā)，是一款面向?qū)ο蟛⒂墒录?qū)動(dòng)的網(wǎng)絡(luò)模擬器，可以模擬各種常見的網(wǎng)絡(luò)協(xié)議，本實(shí)驗(yàn)在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相關(guān)的類和變量；

(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標(biāo)頭；

保存當(dāng)前時(shí)間；

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

返回成功；

}

}

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

}

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

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

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

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

由圖8、圖9可以看出，在相同的條件下，在傳輸數(shù)據(jù)字節(jié)數(shù)較少時(shí)，profibus-DP協(xié)議的報(bào)文循環(huán)時(shí)間小于Cloud_Field_Bus協(xié)議，但隨著傳輸數(shù)據(jù)字節(jié)數(shù)增加，profibus-DP協(xié)議的報(bào)文循環(huán)時(shí)間便超過Cloud_Field_Bus協(xié)議，且二者差距越來越大，并且本實(shí)驗(yàn)profibus-DP協(xié)議傳輸速率采用12 Mibt/s，實(shí)際在工程中其傳輸速率一般僅為1.5 Mibt/s，遠(yuǎn)遠(yuǎn)小于12 Mibt/s，而Cloud_Field_Bus協(xié)議采用以太網(wǎng)的物理層，速率可達(dá)百兆甚至千兆，由此可見Cloud_Field_Bus協(xié)議傳輸速率遠(yuǎn)勝于profibus-DP協(xié)議，報(bào)文循環(huán)時(shí)間遠(yuǎn)小于profibus-DP協(xié)議；對于報(bào)文編碼效率，由于Cloud_Field_Bus協(xié)議數(shù)據(jù)幀需要添加無用數(shù)據(jù)，在傳輸數(shù)據(jù)字節(jié)數(shù)較少時(shí)，profibus-DP協(xié)議的報(bào)文編碼效率高于Cloud_Field_Bus協(xié)議，但隨著傳輸數(shù)據(jù)字節(jié)數(shù)增加，Cloud_Field_Bus協(xié)議數(shù)據(jù)幀有用數(shù)據(jù)字節(jié)數(shù)可滿足其最短幀要求，Cloud_Field_Bus協(xié)議的報(bào)文編碼效率便超過了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ù)與報(bào)文編碼效率數(shù)據(jù)

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

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

4 結(jié)束語

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