可用于云制造环境的新型现场总线协议

胡铁楠，吕云蕾，刘亚秋

(东北林业大学 信息与计算机工程学院，黑龙江 哈尔滨 150040)

0 引 言

云制造是一种面向服务的、高效低耗的新型制造模式。其关键技术之一便是将分散的物理资源接入云平台进行集中管理，这也是将物理资源虚拟映射为虚拟资源以向用户推送服务的前提。在云制造关键技术研究方面：文献[1]对云制造平台中计算资源和制造资源的调度、企业层调度和车间层调度问题进行了综述。文献[2]针对现有集中模式的局限性，研究了云制造中面向自治的SCOS方法。文献[3]提出了一种DPDCM优化模型，以满足公司在云制造环境中执行DPD的各种要求。文献[4]提出一种分布式对等网络架构，以提高云制造的安全性和可扩展性。文献[5]提出了众包是云制造战略实施的一种有效运作模式，从众包角度实现了云制造。文献[6]提出一种面向设备资源组合服务链的方法以有效地对云制造环境下的异地设备资源进行优化选择。现有的研究成果大多为对云制造上层服务资源的建模与描述，在针对云制造环境下制造资源层的接入研究很少，为此，本文针对云制造模式底层的物理资源，设计多协议转换模块支持不同数据接口的加工制造设备，并研究一种新型云现场总线用于资源汇集池与多协议转换模块之间的数据交换，结合两者屏蔽各种物理资源接口协议之间的异构性，对硬制造资源进行统一接入云平台，解决云制造底层物理资源难以接入的问题。

1 云制造平台资源接入模型构建

作为云制造模式的关键技术之一，各种物理资源向云制造平台的接入在云制造模式中占有十分重要的地位，由于其处于云制造模式的底层，直接关系到上层虚拟映射的实现与否，因而物理资源的接入成为云制造模式实现过程中的重中之重。

1.1 云制造模式整体模型

云制造虚拟化整体模型可分为物理资源层、物理资源接入层、物理资源描述层、映射规则层以及虚拟资源层[7]，如图1所示。

图1 云制造整体模型

物理资源层包括软制造资源和硬制造资源，是实现加工制造的实体资源；物理资源接入层将众多物理资源接入云制造平台；软制造资源可通过交互接口、人工录入的方式接入云制造平台，而硬制造资源则需要通过读取其参数数据将其数据化后接入云制造平台；物理资源描述层是对物理资源功能属性的具体描述，通过资源描述模板建立虚拟机器，导入属性信息，此层实现了物理资源在计算机的体现，对物理资源的虚拟映射提供条件[8]；映射规则为物理资源与虚拟资源之间的映射关系，基于物理资源描述层的物理资源描述进行虚拟映射，有一对一、一对多、多对一映射方式，例如物理的铣床及其操作方式可以映射为虚拟的铣服务，铣钻二合一机床可以映射为虚拟的铣服务和钻服务，而虚拟发动机气缸加工服务则需要多台机床以及气缸加工工艺共同映射完成；虚拟资源层为通过映射规则将物理资源转化为虚拟资源，接入云制造虚拟资源池进行统一集中管理，并向用户推送服务。

1.2 物理资源接入模型

作为物理资源接入方的企业，需将本企业的物理资源接入云制造平台，对于软制造资源和硬制造资源，采用不同的接入方式。

软制造资源的接入：软制造资源一般为工程师、技术员、理论知识等，这类资源的接入相对简单，可采用人机交互接口、数据化存入数据库的方式接入云平台[9]。

硬制造资源的接入：硬制造资源具有物理存在性，需要对其运行中实时状态数据接入。在工厂加工车间中，通常采用现场总线技术对各种设备状态进行传递，云制造模式的硬制造资源同样采用现场总线技术将不同的加工设备的状态信息接入到资源管理系统，企业物理资源的接入模型如图2所示。

图2 企业物理资源接入模型

然而不同厂商生产的设备所支持的总线协议不尽相同，资源管理系统无法提供各式各样的接口以迎合不同厂商的加工设备，对物理资源的接入造成了极大的阻碍。针对总线协议异构性大的问题，本文设计了一种新型云现场总线Cloud_Field_Bus，资源管理系统只需提供Cloud_Field_Bus总线接口，整个车间所有设备的状态数据均通过Cloud_Field_Bus总线上传到资源管理系统，并设计多协议转换模块，实现多种总线协议与Cloud_Field_Bus总线协议的双向转换，解决因现场设备接口异构性大而难以接入硬制造资源的问题。

2 新型云现场总线Cloud_Field_Bus

ISO(国际标准化组织)组织研究的网络互联OSI参考模型，定义了网络互连的7层框架，即物理层、数据链路层、网络层、传输层、会话层、表示层和应用层，本课题研究的新型云现场总线Cloud_Field_Bus也以该参考模型为标准，为保证Cloud_Field_Bus总线响应迅速，只设计7层框架中的物理层和数据链路层。在多协议转换系统中，一端为Cloud_Field_Bus协议总线，另一端为挂接加工设备的多种其它标准总线，Cloud_Field_Bus协议总线负责将所有其它现场总线传递到多协议转换模块的数据，即整个制造加工车间所有制造设备的状态数据上传至资源管理系统，由此可见Cloud_Field_Bus协议总线需要传输的数据量大，需要较大的传输速率，因而选用以太网IEEE802.3协议物理层，数据链路层以IEEE802.3协议数据链路层为基础，对其LLC子层进行修改，设计Cloud_LLC子层以良好兼容多协议转换模块。

2.1 数据链路层分析

数据链路层以IEEE802.3协议数据链路层为基础，保持其MAC子层不变，对其LLC子层进行修改，设计Cloud_LLC子层帧格式替代原有的LLC子层。

2.1.1 标准以太网帧格式

以太网数据帧的格式如图3所示，以太网数据帧由前导码、目的主机地址、源主机地址、帧类型、数据、CRC构成。

图3 标准以太网帧格式

前导码：占8个字节，用于目的主机和源主机的时钟同步，约定通信速率。

目的从机地址：以太网中该地址占6个字节，为目的从机的硬件地址。

源主机地址：以太网中该地址占6个字节，为源主机的硬件地址。

帧类型：占2个字节，表示数据帧的类型。

数据：该区占用字节数应在1500以下，最小字节数为46，字节数不足46要进行填充。

CRC：占4个字节，用于数据的CRC校验[10,11]。

2.1.2 Cloud_Field_Bus协议帧格式

LLC子层数据帧最大支持1500字节数据，Cloud_LLC子层把这1500字节数据作为多协议转换模块的数据组，将其划分为15等分数据段，每个数据段100字节，其中1字节为次目的地址号，其余99字节提供给用户数据使用，用户可自由选用其中数据段，Cloud_Field_Bus协议总线的用户程序便是通过次目的地址号来寻找协议转换系统中的缓冲区；此外Cloud_LLC子层帧格式还包含前导码、源主机地址、主目的地址、有效数据段数量以及CRC校验。Cloud_LLC帧格式如图4所示。

图4 Cloud_LLC帧格式

前导码：与标准以太网相同。

主目的地址：Cloud_Field_Bus中该地址占6个字节，为目的多协议转换模块地址。

源主机地址：Cloud_Field_Bus中该地址占6个字节，为源资源管理中心地址。

数据段数量：占2个字节，表示有效数据段的数量。

数据：该区由数据段数量配置，每段占有100字节，首字节作为次目的地址，其余99字节作为用户数据，最多15段。

CRC：与标准以太网相同。

Cloud_LLC子层向上层提供需响应的非连接服务Cloud_REPLY与无需响应的非连接服务Cloud_UNREPLY。Cloud_REPLY服务允许主站点Cloud_LLC用户发送一组数据到从站点Cloud_LLC用户，并接收一个来自从站点的响应帧，此时表示数据已经无误传达到从站点，除此之外从站点也需要向主站点返回数据，因而Cloud_Field_Bus协议的Cloud_LLC服务不仅要求从站发送响应帧中表示已经无误的接收数据，还必须发送数据返回到主站点，该服务用于主从站点之间的数据交换。Cloud_UNREPLY服务则仅是主站点Cloud_LLC用户发送一组数据到从站点Cloud_LLC用户，从站点返回响应帧即可，无需再向主站点返回数据，该服务用于主站向从站发送设置数据。

2.2 Cloud_User接口设计

为保证总线的实时性，Cloud_Field_Bus协议不涉及数据链路层之上的架构，因而设计Cloud_User接口原语映射Cloud_LLC子层Cloud_REPLY服务和Cloud_UNREPLY服务。

Cloud_User接口中Usr_Set_port原语映射Cloud_LLC子层的Cloud_UNREPLY服务，应用程序通过该原语设置数据帧中的可用数据段数量，该原语促使主站点的Cloud_LLC用户向从站点的Cloud_LLC用户发送数据，该原语无需从机返回数据；Usr_Data_Exchange原语映射Cloud_LLC子层的Cloud_REPLY服务，应用程序调用该原语促使主站点的Cloud_LLC用户向从站点的Cloud_LLC用户发送数据，并向从站点即多协议转换模块请求数据，两种原语的功能及参数见表1、表2。

表1 Usr_Set_port原语参数

具体参数功能：

Rem_Add：设置多协议转换模块的主目的地址；

Req_Add：设置资源管理中心的源地址；

Status： 指示该原语的成功或失败；

Amount：设置数据段使用数量。

表2 Usr_Data_Exchange原语参数

具体参数功能：

参数Rem_Add、Req_Add及Status的功能与Usr_Set_port中相同，此处不再赘述。

In_Data0-15：此参数包含输入的Cloud_LLC中多个数据段的用户数据以及次目的地址，数据段数量由Usr_Set_port原语中Amount参数配置。

Out_Data0-15：此参数包含输出的Cloud_LLC中多个数据段的用户数据以及次目的地址，数据段数量由Usr_Set_port原语中Amount参数配置。

Cloud_Field_Bus协议采用主从通信模式，主机用户通过请求原语(Request)向从机请求数据，并通过确认原语(Confirm)进行确认，由主机发送的请求原语(Request)到达从机后成为指示原语(Indication)，完成一次通信。应用程序程序必须先通过Usr_Set_port原语对Usr_Data_Exchange原语的In_Data0-15参数和Out_Data0-15参数进行数据段数量配置，再通过Usr_Data_Exchange原语对数据进行收发。其执行顺序如图5所示。

图5 Usr_Set_port原语与Usr_Data_Exchange原语执行顺序

2.3 多协议转换模块

云制造企业加工车间中，每间车间装有各种不同的加工设备，这些设备提供的通讯接口互不兼容，为解决该问题，本文设计多协议转换模块，资源管理系统提供单一Cloud_Field_Bus总线协议接口，通过协议转换将多种不同总线协议转换成Cloud_Field_Bus总线协议，整个车间的状态数据通过Cloud_Field_Bus总线协议一次上传。通过协议转换和新型Cloud_Field_Bus总线协议将资源管理系统与加工设备彻底隔离开来，利于各个加工设备的添加、移除或者更换，实现云制造硬制造资源的接入。

2.3.1 多协议转换模块设计

用户数据以某种总线协议传输，即是在用户数据前后加上该协议的帧头和帧尾，然后装载到特定的物理层上以一定的比特流进行发送，总线协议的不同之处在于帧格式以及在物理总线上的比特流。因而不同总线协议之间的转换，首先需要具备物理层的支持，以实现比特流的传输，在链路层，得到一帧数据后，需要对帧格式进行转换，去掉该总线协议的帧头和帧尾，提取出用户数据，再加上另一种总线的帧头和帧尾，装载到物理层上进行传输；多协议转换模块则是支持多种总线协议帧头和帧尾的拆分以及重组，即可实现多种异构协议之间的相互转换[12]。

本文设计的多协议转换模块是专门为云制造硬制造资源接入而设计，其一端仅支持Cloud_Field_Bus总线接口，另一端支持多种其它类型总线接口，实现一对多协议转换，多协议转换模块总体模型如图6所示。

图6 多协议转换模块总体模型

Cloud_Field_Bus协议帧进入多协议转换模块后，Cloud_Field_Bus协议处理模块去掉Cloud_Field_Bus协议的帧头和帧尾，得到用户数据并存储在Cloud_Field_Bus协议输入缓冲区，中央处理模块通过数据段所包含的次目的地址，将Cloud_Field_Bus协议输入缓冲区中的数据组以数据段为单位存储在A、B、C、D这4种协议输出缓冲区，由其各自的协议处理模块加上各自协议的帧头和帧尾，发送到远端；反向传输亦然。

2.3.2 多协议转换模块实现

多协议转换模块要求能够实现多种不同协议与Cloud_Field_Bus协议之间的转换，多协议转换模块作为Cloud_Field_Bus协议从站点，需要具备Cloud_Field_Bus协议从站点模块以及其它协议的协议芯片，暂存数据的输入输出缓冲区则需要RAM存储器实现，采用微控制器作为中央处理单元。多协议转换模块通过软件为每种协议缓冲区分配唯一端口号，端口号与Cloud_Field_Bus协议数据帧的次目的地址相对应，通过次目的地址将用户数据存储在相应端口号的缓冲区中；主程序负责对各种协议用户数据的提取，帧头帧尾的添加以及对缓冲区数据的读写，通过软件控制硬件各个模块，从而实现其它协议和Cloud_Field_Bus协议之间的转换，多协议转换模块程序流程如图7所示。

图7 多协议转换模块程序流程

系统上电首先对各个模块进行初始化操作，然后根据需求设置可用端口，将开启的端口对应的输入缓冲区的数据写入Cloud_Field_Bus协议输出缓冲区，为主站点的数据请求准备数据，若收到主站点请求，则将Cloud_Field_Bus协议输出缓冲区数据回复给主站点，同时提取Cloud_Field_Bus协议数据写入Cloud_Field_Bus协议输入缓冲区，并根据此目的地址依次将数据依次写入其它协议的输出缓冲区，并通过相应协议发送到远端。

3 Cloud_Field_Bus协议性能分析测试

由于Cloud_Field_Bus协议是在以太网物理层、数据链路层的基础上进行优化设计得来，并采用主从通信模式，因而通过对比实验与性能较优的工业级现场总线profibus-DP协议作比较，对比数据交换过程中两种协议的报文循环时间以及编码效率来分析Cloud_Field_Bus协议性能的优劣。

3.1 报文循环时间

两种协议采用主从通信模式，每一次报文循环内，主站点向从站点发送数据并向从站点请求数据，从站点在响应帧中包含数据返回给主站点，一次循环结束。报文循环时间是传输1 bit数据所需要的时间乘以传输的总数据位数。因而报文循环时间TC可用式(1)表示

(1)

其中，N为网络中的从站点个数；TSLV(i) 为对第i个从站点进行请求所需要的时间；Tinter为帧间间隙。Cloud_Field_Bus协议取Tinter=192Tbit。

对于Cloud_Field_Bus协议，由于其只定义了物理层和数据链路层，因而Cloud_Field_Bus协议数据帧并不包含传统以太网的上层帧数据，仅包括8个字节前导码、6个字节主目的地址、6个字节源主机地址、2个字节数据段数量、4个字节CRC校验码以及4个字节的LLC帧头，次目的地址包含在用户数据中，不属于固定数据，因而一帧数据有30个字节的固定数据。当主站点发送和接收的数据均满足Cloud_Field_Bus协议数据帧最短帧要求时，Cloud_Field_Bus协议访问第i个字节所需的时间为

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

(2)

其中，Ii是主站点发送给第i个从站点的数据字节数；Oi是第i个从站点返回给主站点的数据字节数；Tbit是传输1 bit数据的单位时间。由于Cloud_Field_Bus协议源于传统以太网，因而与以太网数据帧同样有最短字节限制，因此式(2)只在Cloud_Field_Bus协议主站点与从站点间交互的数据帧大于72 Byte时才有效，数据帧少于这个最短字节数是会在数据域中填充一些无效字节，Cloud_Field_Bus协议报文循环时间如式(3)所示

(3)

对于profibus-DP协议，在只有一个主站点的profibus-DP环境中，数据交换过程中其报文循环时间如式(4)所示

(4)

其中，N为网络中的从站点个数；Tif与Cloud_Field_Bus协议中Tinter含义相同且Tif=192Tbit；Tftx为发送固定数据所需的时间，取Tftx=231Tbit。LIO为主站点发送并请求从站点的数据字节数。代入式(4)可得profibus-DP协议的报文循环时间如式(5)所示

(5)

3.2 报文编码效率

报文编码效率同样是衡量一个协议优劣的重要指标。协议的报文编码效率是指在一次数据交换过程中有用数据与交换的总数据的位数之比，其计算公式如下

(6)

其中，NData为数据交换过程中有用数据位数；NFrame为数据交换过程中总数据位数。

对于Cloud_Field_Bus协议，根据其数据帧格式，当传输字节数少于42字节时，需要在数据域中无用的字节以满足其最短帧长度要求。当传输字节数多于42字节时，则无需填充无用字节。因此Cloud_Field_Bus协议的报文编码效率如下式所示

(7)

对于profibus-DP协议，在只有一个主站点的profibus-DP环境中，数据交换过程中其报文编码效率如下式所示

(8)

3.3 误码率

误码率是衡量数字通信系统可靠性的重要指标。误码率是在传输过程中发生误码的码元个数与传输的总码元数之比，用Pe表示

(9)

误码率的大小由通路的系统特性和信道质量决定，误码率与两者均成反比关系，即系统特性与信道质量越好，则误码率越低。对于多数的通信系统来说，如光纤通信，千兆以太网，PCI Expree，USB2.0等都要求接收机的误码率应小于10-10甚至更低。

3.4 分析测试

本文实验环境采用NS2网络仿真软件，NS2用C++语言和OTcl语言共同开发，是一款面向对象并由事件驱动的网络模拟器，可以模拟各种常见的网络协议，本实验在Ubuntu系统上安装了NS2软件，创建新协议需要在NS-3.35目录下添加新协议的算法。

创建Cloud_Field_Bus协议的具体步骤是：

(1)编写Cloud_Field_Bus协议的C++类；

(2)编写Cloud_Field_Bus协议类的成员函数；

(3)编写TCL相关的类和变量；

(4)绑定C++代码和TCL；

(5)修改packet.h文件向NS2添加Cloud_Field_Bus协议。

在NS2中创建Cloud_Field_Bus协议部分伪代码如下所示。

Cloud_PingAgent_command()

{

If (参数数量为2)

{

If (参数类型为send)

{

创建新的数据包；

访问新数据包的ping标头；

保存当前时间；

发送数据包；

返回成功；

}

}

Else 调用基类的command函数；

}

参数设定Cloud_Field_Bus协议和profibus-DP协议网络均有1个主站点和5个从站点，且每个从站点皆与主站点交换相同的字节数；设定Cloud_Field_Bus协议访问链路带宽为10 Mbit/s，profibus-DP协议访问链路带宽设定为其最高的12 Mbit/s，进行报文循环时间以及编码效率对比实验；设定Cloud_Field_Bus协议访问链路带宽分别为 100 Mbit/s 和200 Mbit/s进行误码率对比实验。

Cloud_Field_Bus协议与profibus-DP协议报文循环时间仿真对比结果如表3、图8所示。Cloud_Field_Bus协议与profibus-DP协议报文编码效率仿真对比结果如表4、图9 所示。Cloud_Field_Bus协议分别为100 Mbit/s和200 Mbit/s访问链路带宽时的误码率仿真结果如图10所示。

表3 部分传输字节数与报文循环时间数据

图8 传输字节数与报文循环时间关系

由图8、图9可以看出，在相同的条件下，在传输数据字节数较少时，profibus-DP协议的报文循环时间小于Cloud_Field_Bus协议，但随着传输数据字节数增加，profibus-DP协议的报文循环时间便超过Cloud_Field_Bus协议，且二者差距越来越大，并且本实验profibus-DP协议传输速率采用12 Mibt/s，实际在工程中其传输速率一般仅为1.5 Mibt/s，远远小于12 Mibt/s，而Cloud_Field_Bus协议采用以太网的物理层，速率可达百兆甚至千兆，由此可见Cloud_Field_Bus协议传输速率远胜于profibus-DP协议，报文循环时间远小于profibus-DP协议；对于报文编码效率，由于Cloud_Field_Bus协议数据帧需要添加无用数据，在传输数据字节数较少时，profibus-DP协议的报文编码效率高于Cloud_Field_Bus协议，但随着传输数据字节数增加，Cloud_Field_Bus协议数据帧有用数据字节数可满足其最短帧要求，Cloud_Field_Bus协议的报文编码效率便超过了profibus-DP协议。图10中分别为100 Mbit/s链路带宽和200 Mbit/s链路带宽的误码率仿真结果，从仿真结果可以看到，100 Mbit/s链路带宽的误码率峰值比200 Mbit/s链路带宽的误码率要高，两者平均误码率均为10-12左右，200 Mbit/s链路带宽的误码率峰值在10-10以下，满足总线协议误码率最高限度。

表4 部分传输字节数与报文编码效率数据

图9 传输字节数与编码效率关系

图10 链路带宽分别为100 Mbit/s和 200 Mbit/s时误码率对比

4 结束语

本文在以太网协议的基础上，设计了一种新型的现场总线协议Cloud_Field_Bus以及多协议转换模块，用于对云制造物理资源的实时接入。通过仿真实验对比Cloud_Field_Bus协议与profibus-DP协议的报文循环时间和编码效率，并对比Cloud_Field_Bus协议分别在100 Mbit/s链路带宽和100 Mbit/s链路带宽时的误码率，实验结果表明了Cloud_Field_Bus协议信息表达的高效性和传输可靠性。因而在对云制造企业现场设备海量的数据实时传输环境中，Cloud_Field_Bus协议既可保证其现场工作的实时性，又能轻易的对海量数据进行传输；多协议转换模块则屏蔽通讯接口的异构性；结合两者，在一定程度上解决了云制造系统中底层资源难以接入的难题。对于低带宽传输误码率较大问题有待进一步解决。