《工业大数据导论》 课件 第3-5章 工业大数据网络协议、工业大数据采集技术基础、工业大数据存储与安全基础

工业大数据网络协议目录工业大数据网络基础模型工业大数据网络典型协议0102学习目标1.熟悉工业大数据网络模型2.了解工业网络的发展与应用3.理解典型工业数据采集网络的运行机制01工业大数据网络基础模型工业大数据网络基础模型工业以太网网络模型计算机网络模型现场总线网络模型计算机网络模型计算机网络普遍采用的网络互联模型是IOS/OSI模型，它采用分层的结构化技术，把计算机通信网络分为七个层次，如图所示。在IOS/OSI模型下，两个通信对象同等层之间的通信规则和约定被称为“协议”。计算机网络模型分层总结名称作用应用示例常用编码方式/协议应用层为具体应用程序提供网络通信服务电子邮件、远程桌面HTTP协议、FTP协议、TFTP协议、SMTP协议、DNS协议、DHCP协议等表示层规定数据传输的语义和语法，解决不同操作系统之间的异构通信Windows系统下可以访问Linux系统远程桌面ASCII，MPEG，JPEG等会话层建立、管理和终止表示层与实体之间的通信会话文件断点续传、用户登录验证SQL协议、NFS协议、RPC协议等传输层向会话层提供可靠的端到端的网络数据流服务端口（socket）TCP协议、UDP协议等网络层通过IPV4或IPV6等确定通信实体的网络位置，在通信实体之间建立连接路由器、防火墙IP协议，ARP协议，RARP协议，因特网报文协议ICMP、因特网组管理协议IGMP等数据链路层在通信实体之间建立数据链路连接，确定对数据流如何进行分包网桥、二层交换机SDLC、HDLC、PPP、STP、帧中继等物理层将比特流进行编码转换成相应的物理信号，并提供原始比特流的传输通道中继器、集线器、网线、RJ-45标准常用编码方式：非归零编码、曼彻斯特编码、差分曼彻斯特编码现场总线网络模型现场总线的网络建模是以IOS/OSI模型为基础的。但是工业控制网络与普通计算机网络的应用场景及需求是有很大不同的。工业大数据有别于一般计算机网络数据的主要特性如下图所示数据种类实时性要求完整性要求连续性要求是否高并发一般大数据低低允许数据丢失，可恢复是工业大数据高高不允许数据丢失，不可重现否现场总线网络模型结构模型的定义现场总线对IOS/OSI参考模型进行了简化，按照IEC（InternationalElectrotechnicalCommission，国际电工技术委员会）现场总线的基础网络架构包括３层，分别为物理层、数据链路层和应用层（如图3-2所示）。这样就舍去从3网络层到6表示层，降低由层间操作与信号转换而引起的网络接口造价与时间消耗，保证工业控制系统的实时性与可靠性。由此可见，现场总线是一种具有简化网络结构和开放性的实时系统，为制造现场和控制设备之间提供了一种有效的串行数据通信链路。现场总线网络模型的实际应用建立高尔夫球场顾客问题的决策树模型：在实际应用中，有些现场总线（如美国仪表学会制定的ISA/SPSO现场总线）结构会增加一层用户层，如下图所示。这是因为，虽然现场总线物理层、数据链路层和应用层的功能与IOS/OSI模型基本是一致的，但是现场总线在数据通信上是有独特应用需求的。数据通信上的独特需求①IOS/OSI参考模型只支持点对点/端对端的通信模式，不支持多播或广播，而现场总线中的一个主站需要向多个从站发送控制命令。②IOS/OSI参考模型不提供周期性通信服务，而工业控制系统中某些应用需要周期性通信。工业以太网网络模型工业以太网在Ethernet+TCP/IP协议之上，建立了完整、高效的通信服务模型，提供广大工控生产厂商和用户所能接受的应用层、用户层协议，从而形成开放的标准，成为了智能车间建设、大数据中心可靠运作、以及实现生产过程智能监控与管理的关键因素。。现场总线具备开放性、全数字化、智能化等特征，但是异构现场总线之间互不兼容，不同协议产品之间无法实现透明的信息交互，难以体现互操作性，存在“自动化”孤岛的瓶颈，不支持与互联网集成，随着物联网技术的快速发展，工业以太网应运而生。工业以太网是在以太网技术的基础上开发出来的“第二代现场总线”，易实现控制现场数据与信息系统的资源共享，支持工业生产过程的“管控一体化”，已然成为了智能制造的关键支撑技术。工业以太网网络模型的结构模型工业以太网的网络模型与普通现场总线网络模型类似，依然是对原有IOS/OSI参考模型进行“裁剪”，以1物理层、2数据链路层和7应用层为基础，有些工业以太网协议还支持用户层。工业以太网与普通现场总线协议最大的不同是，工业以太网在网络层和传输层采用了标准的TCP/IP协议簇（包括UDP、TCP、IP、ICMP等）。从另一个角度来说，普通现场总线协议只定义物理层、数据链路层和应用层，为了与以太网技术融合，工业以太网在数据包之前加入了IP地址，并通过TCP/UDP进行数据传输，如左图所示。02工业大数据网络典型协议工业大数据典型网络协议工业大数据典型网络协议工业网络协议综述OPCUA协议MT-Connect协议NC-Link协议COAP协议MQTT协议工业网络协议综述截至2018年，国际上已有40多种现场总线，每一种现场总线都有各自的适用范围和技术特点。Profibus-DP主要用于分散外设间的高速数据传输，适用于加工自动化领域。Profibus-FMS适用于纺织、楼宇自动化、可编程控制器、低压开关等DeviceNet主要被广泛应用于现代工厂自动化系统。在工业以太网与智能制造的发展推动下，基础自动化控制网络与过程和管理控制系统之间实现了无缝集成，保证从底层现场设备到顶层生产管理之间高质量的数据传输和数据转换。….……..工业网络协议级别按照工业网络的应用层次，本书将工业网络协议分为4个级别：单元级、设备级、车间级和企业管理级，如下图所示。当然这种划分方式也不是绝对的，因为工业现场总线已经呈现有互相融合的趋势，各类总线通过合理搭配形成真正开放的互联互通，不断推动工业控制系统的变革与发展。工业网络协议级别单元级总线以“Ethercat、NCUC-Bus”为代表，主要用于设备内部（如伺服系统内）的数据传输，由于高速、高精的通信需求，它对信号实时性要求特别苛刻，甚至要求总线周期在纳秒级。设备级总线以“Modbus、Fieldbus、Fieldnet”为代表，用于自动控制系统与分散的I/O设备级之间的通信，适用于分布式控制系统，如水站、电站等，总线周期一般都低于10ms。车间级总线如OPCUA、MTConnect、NC-Link等，可用于大范围和复杂的通讯场景，用来解决车间级通用性通讯任务。总线周期一般小于100ms，但时间跨度也允许在秒级或分钟级，支持工业数据采集，建立工业数据向管理网络传输的通道。企业管理级网络将孤立的现场设备带进了企业信息网络，它以车间级总线为基础通信层，将现场设备与企业管理系统（如ERP、MES等）连接起来，实现工业自动化生产控制/过程的智能管控。OPCUA协议1.OPCUA技术背景在实际应用中，工业生产设备种类繁多，异构工业设备之间没有通用的标准接口，这为现场生产设备之间的互联互通造成了很大的困难，从现场底层的生产数据到高层的企业决策信息无法进行有效集成和整合。因此，设备供应商和软件开发商需要一种具有高效性、可靠性、开放性、可互操作性的即插即用的设备驱动程序，简化每个层级之间的数据交换，于是OPC应运而生！OPC标准以微软公司的OLE（ObjectLinkingandEmbedding，对象链接和嵌入）技术为基础，向用户提供具有开放性和互操作性的OLE/COM接口标准，避免非标准数据接口的复杂性，使各种工业设备和管理层系统/工业应用层之间能够互相操作，工业应用程序的使用不再依赖特定的开发语言与环境。OPC标准OPCUA协议OPCUA作为新一代OPC技术，其主要优势的简单总结：1)

跨平台性，独立于各种开发平台和编程语言；2) 访问统一性，提供一致、完整的地址空间和服务模型，通过一个调用接口为客户端提供数据、报警、事件和历史数据，详见节；3) 安全通讯机制，底层通信技术集成了由公用秘钥与私用秘钥形成的加密功能和标记技术，保证了传输消息的完整性与安全性；4) 信息授权访问机制，集成用户授权、签名、加密传输等功能，防止信息非授权访问，以及过程数据损坏和误操作。5) 高可靠性，集成可配置超时、自动错误检查和自动恢复等机制，可对OPCUA客户端与服务器之间的物理连接进行监视，及时发现通信故障，自动处理通信错误和失败；6) 冗余性，支持来自不同厂商的软件应用同时被采纳并彼此兼容，实现高可用性的通信系统。因此，自OPCUA技术诞生以来，越来越多的公司将其作为开放的数据标准，包括主流的自动化厂商，以及IT界的华为、CISCO、Microsoft等都是OPCUA的支持者，还包括Profibus/Profinet的PI组织、POWERLINK。在2017年9月5日，OPCUA已正式成为国家推荐性标准。OPCUA协议2OPCUA规范总览OPCUA协议开发规范由OPC基金会于2006年8月首次发布，截至2018年10月，最新版官方正式发布的OPCUA开发规范主要包括13个部分说明，如右图所示，OPCUA协议第一部分：概要与概念主要介绍了服务器和客户端的基本概念。第二部分：安全模型描述了OPCUA客户端与服务器之间的安全交互，包括交互通道安全、消息传输安全、数据访问安全等。第三部分：地址空间模型用以描述服务器地址空间的内容和结构。地址空间是整个系统的最基层，系统绝大多数的功能调用都需要经过该模块，是OPCUA架构的最核心部分。第四部分：服务说明了OPCUA可提供的所有服务功能和服务函数对系统的功能进行了全面性描述。第五部分：信息模型说明了为OPCUA服务器定义的标准数据类型和它们之间的关系。第六部分：服务映射对协议支持的传输映射和数据编码机制进行了说明。第七部分：协议描述了OPCUA服务器和客户端可以实现的行为类别，说明了可用于OPCUA客户端和服务器的协议，这些协议提供了可用于一致性标准的服务和功能。OPCUA协议第八部分：数据访问为过程数据定义了变量类型、属性和状态码等模型，说明了OPCUA系统的数据访问规则。第九部分：报警与事件定义了使用OPCUA对过程报警与条件通道的支持。第十部分：程序说明了OPCUA对程序访问的支持。第十一部分：历史访问说明了历史数据和历史事件的访问方式。第十二部分：查找用以说明客户端采用何种方式在网络中发现服务端，以及客户端如何获得需要的信息与特定服务器建立连接。第十三部分：聚合说明了如何从原始数据计算样本值，主要用于实时数据和历史数据的处理。第十四部分：订阅发布定义了数据访问的发布订阅模式，但截至到2018年10月，该部分规范还处于候选版本，没有被正式发布。OPCUA协议3OPCUA架构分析OPCUA系统体系结构采用服务端/客户端（C/S）模式，其中OPCUA服务器负责生产过程数据的收集，然后通过标准接口为OPCUA客户端提供数据服务，OPCUA客户端通过标准接口获取数据，实现用户所需的应用程序功能。如右图所示。1.网络架构OPCUA协议假定要开发一套OPC系统，OPCUA客户端和服务器都要开发对应的应用程序，先了解一下OPCUA的服务器和客户端的运行和配置方式。2.系统架构OPC基金会定义的OPCUA客户端系统架构，客户端应用程序是指执行客户端功能的代码，它通过“客户端API”向服务器发送数据请求或从服务器接收信息。需要说明的是，“客户端API”是一个内部接口，将应用程序代码从通信堆栈中分离出来，通信堆栈负责将客户端的API调用转换为服务消息，并通过底层消息体发送给服务器。OPCUA协议OPC基金会定义的OPCUA服务器系统架构，服务器应用程序“服务器API”与客户端进行交互，同理“服务器API”也是内部接口。OPCUA客户端与服务器有两种交互方式：第一种：客户端发送服务请求，经底层通信实体发送给OPCUA通信栈，并通过服务器API调用请求/响应服务，然后在地址空间内执行指定任务后，向客户端返回一个响应，这种交互称为请求响应模式。第二种：客户端发送消息发布请求，经底层通信实体发送给OPCUA通信栈，并通过服务器API发送给订阅，当订阅指定的监控项监测到数据/事件/报警变化时，产生一个消息通知由订阅转发给客户端，这种交互称为发布订阅模式。OPCUA协议OPCUA客户端和OPCUA服务器之间的合法连接称为“会话”，每个客户端与服务器建立一个单独的请求响应对话，每个服务器可以根据自身资源或其他约束条件来决定可支持的并发会话数量，即可接受的客户端连接数量。会话的终止由客户端或服务器的指令、或客户端失效来决定。每个会话是不依赖底层通信协议的，但是会话的进行是建立在底层通信架构的基础上的，如右图所示。OPCUA通信架构主要包括两个部分：UA应用程序和通信栈，其中通信栈由编码层、安全信道层和传输层构成，负责向UA应用程序（包括服务器应用程序和客户端应用程序）提供一套标准接口（API）。3.通信架构OPCUA协议4OPCUA服务OPCUA服务指的是OPCUA服务器对外的接口，是服务器信息模型和客户端信息模型进行数据交互的桥梁，即OPCUA客户端若想访问服务器的数据必须通过服务才能实现，服务以“方法”的形式提供给OPCUA客户端使用。OPCUA协议规范在其第四部分对所有服务进行了介绍与划分，形成了多个服务子集，每个服务子集定义用于访问服务器特定功能部分的逻辑组合，解决了传统OPC规范在应用时服务重叠的问题。OPCUA服务规范定义的服务子集如右图所示，包括安全信道服务集、节点管理服务集、方法服务集、查询服务集、会话服务集、视点服务集、属性服务集和订阅服务集等。OPCUA协议5OPCUA信息模型OPCUA客户端如何访问服务器是通过对象模型描述的，该模型定义了一组标准化节点类型，代表地址空间内的对象、对象属性、方法、事件以及对象间的关系。相关对象模型及其之间的关系按照特定的规则进行分组，便形成信息模型。换句话说，信息模型是使用地址空间的概念定义自有的、领域特定的类型和约束，以及明确定义的实例。信息模型是OPCUA技术的基础，可以定义节点标识（NodeId）、节点类型、建模规则等，它还可以通过定义浏览名称和语义定义标准的特性和方法。此外，信息模型也能定义标准视点，以及包含明确数据的标准变量。数据访问（DC）历史数据访问（HDA）报警和事件（A&E）程序本书不详细介绍OPCUA如何进行信息建模，只向读者介绍OPCUA已定义的4种标准信息模型。OPCUA协议1、数据访问（DC）数据访问信息模型主要定义了模拟和离散变量、工程单位和质量代码的自动化数据表示形式，基于该模型，OPCUA规范在第8部分详细说明了如何使用OPCUA进行数据访问。数据访问信息模型定义的标准变量层次结构见右图。OPCUA协议2、报警和事件（A&E）OPCUAA&E接口接收事件或报警通知。事件是通知客户端有一个事件发生；报警事件通知客户端过程状态的变化，比如水箱的水位值，超过最高水位或低于最低水位就会产生状态变化。OPCUA通过A&E接口接收通知的基本原理为：在A&E服务器中创建OPC事件服务器（OPCEventServer），然后生成OPC事件订阅（OPCEventScription）对象接收消息通知。3、历史数据访问（HDA）4、程序历史访问信息模型主要描述了如何找到历史数据的配置信息。OPCUADA接口可访问数据源的历史信息，OPCUA客户端连接到HAD服务器中的OPCHDAServer对象，此对象可提供读取和更新历史数据的接口和方法。程序是相对于方法而言。方法是由客户端发出请求，在服务器执行，并将结果返回给客户端，这个过程可在短时间内完成，比如电机的启动、停止等。程序则是用来完成长时间运行、有状态的功能。OPCUA协议6OPCUA地址空间模型1.节点与引用OPCUA地址空间内的内容是以一组通过“引用”形式连接起来的节点来描绘的，如右图所示。节点是地址空间的基本单位，代表OPCUA服务器定义的真实对象，OPCUA客户端通过使用OPCUA服务（接口和方法）来访问节点。引用定义了节点与节点之间的关联，如右图中的箭头表示两个节点间的引用关系，箭头方向表示引用方向，箭头的起点是源节点，箭头的末端指向目标节点。OPCUA协议节点由属性描述并由引用进行关联组织，属性用来描述节点的数据元素，客户端可通过读、写、查询、订阅的方式存取属性值。属性是节点类的基本组成部分，比如对于一个监控项而言，监控对象就是节点的某个属性。属性内容包括属性ID、名称、描述、数据类型、和强制/可选指示器等，其中属性ID用来唯一标识属性。一个引用关系由源节点、引用类型、目标节点的联合唯一标识，如下图所示。需要说明的是，每个节点可以与其他多个节点形成引用关系，但是引用的定义是非常严格的，相同的两个节点之间不允许提供两次方向和类型都相同的引用。另外，目标节点可以在与源节点相同的地址空间里，也可以在不同的地址空间里，OPCUA协议2.节点组织OPCUA服务器可以在它们的地址空间中自由的组织它们选择的节点。基于节点间的引用关系，OPCUA服务器将地址空间内的许多个节点组织成分层结构、网状结构或任何可能的混合结构，如下图就是一种网状组织结构。OPCUA协议3.节点类型OPCUA定义了多种类型节点，每种节点类别都具有自身特有的属性，但是其都继承于一个基节点，基节点定义了它们的共有属性，见下表所示。序号属性数据类型说明1NodeIdNodeId用于定位OPCUA服务器中的节点，并用来对节点进行唯一标识2NodeClassNodeClass定义节点类型（NodeClass）的枚举类别，如对象、方法或视点等3BrowseNameQualifiedName用于客户端浏览OPCUA服务器时的节点标识4DisplayNameLocalizedText用于节点名称在用户界面的可视化显示5DescriptionLocalizedText可选属性，描述该节点的本地化说明6WriteMask

UInt32可选属性，定义节点属性是否可写7UserWriteMaskUInt32可选属性，定义连接到OPCUA服务器的某一个客户端是否有修改节点属性的权限OPCUA协议NodeClass是一个枚举类型，用来标记节点属于OPCUA规范定义的哪一种节点类型，当然OPCUA规范定义范围之外的是非法的。BrowseName是一个包含命名空间（Namespace）和非本地化字符串的结构，服务器通常为NodeId和BrowseName设置同一个Namespace，但是BrowseName不能唯一标识节点，一批类似的实例节点可能具有相同的BrowseName属性值。DisplayName用来显示节点名称，BrowseName仅用于浏览目的，不用于节点名称的显示。WriteMask和UserWriteMask定义了客户端对节点属性的可写性，由WriteMask定义的可写属性集不能小于UserWriteMask定义的可写属性集，因为WriteMask定义任何用户可写的属性集，UserWriteMask定义指定用户的可写属性集，可以理解为，UserWriteMask是WriteMask的子集。需要说明的是，基节点是抽象的节点类型，不能被实例化。OPCUA从基节点派生了8种可被实例化的节点类别，分别为Variable（变量）、VariableType（变量类型）、Object（对象）、ObjectType（对象类型）、View（视点）、DataType（数据类型）、ReferenceType（引用类型）和Method（方法）。OPCUA协议（1）引用类型引用的实质是“两个节点之间的关联”，用于说明节点如何连接的不同语义。即引用不是节点，它没有任何属性和特性，不能被直接访问，只能间接的以浏览的方式访问，OPCUA便使用“引用类型”来说明引用的语义，定义引用属于哪一种类型。属性数据类型说明属性数据类型说明IsAbtract布尔定义引用类型可否用于引用，或者只用于组织引用类型层次结构Sysmetric布尔指定引用是否对称，即正反向意思是否相同InverseNameLocalizedText可选属性，只适用于非对称引用，指定引用在反方向上的语义注意：一个引用类型的Browsename在一个OPCUA服务器中必须是唯一的，避免同名的引用类型语义不同而导致混乱。DisplayName必须定义有Browsename的本地化描述，两者共同确定引用类型的正向语义。OPCUA协议（2）对象、变量和方法1) 对象节点类别为对象的节点用于描述地址空间结构，对象除了Browsename（浏览名称）、DisplayName（显示名称）等属性外，不能包含任何数据，通过使用变量对外提供值。对象主要用于变量、方法或其他对象的分组管理。一个对象可能包含有其他的对象，基于同一个对象可以定义不止一个变量以及不同的方法实现。2) 变量节点类别为变量的节点代表一个数值，数值的数据类型取决于该变量节点类别。即变量提供真实的值，该值支持读取、重写、变化订阅等客户端操作，类似于面向对象编程中的“a=1”，a是一个变量，数值为1。实际上，OPCUA定义了两种变量：数据和特性（Property），它们是数据建模的基本因素。3) 方法节点类别为方法的节点代表由客户端调用并返回结果的一个服务器方法，方法的输入是由客户端提供的输入参数，输出参数是按照客户端要求返回的结果。OPCUA协议节点类别（NodeClass）属性数据类型说明对象（Object）EventNotifierByte表示对象是否可以用来订阅事件，以及事件的历史是否会被访问或改变变量（Variable）Value由其他属性决定变量实际值，数据类型由ArrayDimensions、ValueRank或DataType决定DataTypeNodeId标识地址空间的节点，该属性包含一个此类型节点的NodeId，以此来定义Value属性的数据类型ValueRankInt32标识值是否为数组，以及定义数组的维度。OPCUA内置支持多维数组，客户端可以读取或写入数组的一部分，也可以只订阅数组的一部分ArrayDimensionsUInt32[]可选属性，用来定义数组大小，只能适用于Value值是一个数组的情况AccessLevelByte定义Value属性的当前值是否可读写，以及Value是否有历史可用，注意与WriteMask属性的区分，WriteMask不包括变量类型的Value属性，与AccessLevel在信息上不会重复UserAccessLevelByte定义指定用户是否有权限读写Value属性的当前值，是否有权查询历史值MinimumSamplingIntervel时间区间可选属性，定义服务器能检测到Value属性变化的时间Historizing布尔标识目前服务器是否收集了Value历史信息。AcessLevel指示是否有历史可用，Historizing指示服务器是否收集了历史信息方法（Method）Executable布尔指示方法在当前是否可以被调用UserExecutable布尔指示方法在当前是否可以被指定用户调用InputArgumentsArgument[]可选属性，定义一个方法输入参数的属性OutputArgumentsArgument[]可选属性，定义一个方法输出参数的属性OPCUA协议（3）对象类型类似于面向对象编程，OPCUA技术规范定义的对象都是有类型的，称为对象类型（ObjectType）。OPCUA对象类型节点的运行机制：如左图中定义了两个对象类型：FolderType和BranchType，对象Branch1引用了BranchType，因此是BranchType类型的。服务器在创建一个对象时，必须提供对象类型定义，对象的Description和DisplayName可以不指定，使用对象类型的对应属性值填充，比如图中的对象Branch1的Description属性值来自对应的BranchType的。OPCUA协议OPCUA对象类型节点的使用和实现：对象类型是一次定义多次使用，即基于同一个对象类型，可以创建多个不同的对象实例。左图展示了一个对象类型定义的例子，其中MotorType是一个对象类型节点，基于该节点创建了对象节点Motor1，还可以创建Motor2.Motor3等多个对象节点。MotorType定义了一个状态变量Status，一个包含两个变量的配置对象Configuration，两个方法Start和Stop，Motor1与MotorType保持相同的结构，但是两者也存在本质相异点：对象类型节点MotorType下定义的变量、对象和方法是实例，但是这些实例不提供真正的实例值，因此这些实例节点被称为实例声明（InstanceDeclarations）。OPCUA协议（4）变量类型像对象一样，OPCUA提供的变量也是有类型的，通过变量类型（VariableType）指定，也支持继承机制。下表列出了变量类型的附加属性。属性数据类型说明Value由其他属性决定可选属性，变量的实际值，数据类型由DataType、ValueRank或ArrayDimensions决定DataTypeNodeId定义Value属性的数据类型ValueRankInt32标识参数类型：标量、数组或矩阵等ArrayDimensionsUInt32[]可选属性，用来定义数组或矩阵大小，只能适用于Value值是一个数组的情况。这个数组的每项定义了值数组的对应维度大小IsAbstract布尔标识变量类型是具体的或者抽象的OPCUA协议（5）数据类型在变量和变量类型部分已经提到过数据类型（DataType），实际上，OPCUA规定：除了变量和变量类型的Vaule属性外，所有属性都有一个数据类型，变量和变量类型的Vaule属性是由变量和变量类型的数据类型属性、ValueRank、ArrayDimensions共同定义的。OPCUA技术规范定义的数据类型有5种。1)内置数据类型2)简单数据类型3)枚举数据类型4)结构化数据类型5)抽象数据类型OPCUA协议（6）视点视点是用来组织空间地址的关键依据。它可以从以下两种方面来理解：1） 视点是地址空间的一个节点，提供视点内容的入口。2） 使用节点的NodeId作为地址空间浏览的过滤参数，通过视点的过滤机制，客户端可以快速地从庞大的数据集中查询并定位到需要的数据节点。同时，服务器可以限制客户端访问到视点外部节点的引用。因此，客户端浏览地址空间需要从视点进入，然后把视点当作过滤器浏览指定范围的节点。但是需要注意，视点总是服务器定义的，也就是说客户端对视点只能浏览和访问；而且客户端同时只能浏览一个视点，因为视点不能合并。属性数据类型说明ContainsNoLoops布尔指示视点包含的节点中是不是产生循环EventNotifierByte标识对象是否支持事件订阅，事件的历史是否会被访问或改变OPCUA协议7OPCUA消息交互1.请求响应模式OPCUA服务器和客户端之间的交互是基于服务集的消息传递机制实现的。服务消息可以是二进制格式，也可以是XML文本格式，这便意味着OPCUA不仅仅适于设备层、自动化层到信息化层的数据交换，还可以透过互联网实现远程的数据交换，能满足自动化工厂所有层面数据交换的需要。OPCUA协议规范定义了两种消息服务框架，即请求响应模式和发布订阅模式。2.发布订阅模式OPCUA协议1.请求响应模式OPCUA请求响应模式的消息交互与网络服务交互类似，即每次交互都是由请求消息和响应消息构成，大致过程如下图所示。客户端将服务请求经底层通信实体发送给OPCUA通信栈，通过OPCUA服务器API调用请求/响应服务，服务器接收消息请求并在地址空间内执行，执行完成后向客户端返回一个响应消息。OPCUA协议2.发布订阅模式发布订阅是一种新型消息范式。消息的发送者（称为发布者）不会将消息直接发送给特定的接收者（称为订阅者），而是将发布的消息进行分类标记，不需要关心是否有订阅者存在，也不需要关心有哪些订阅者存在。OPCUA订阅发布机制中主要有三个关键服务：发布服务、监控项服务和订阅服务。发布服务是由客户端通过OPCUA服务接口（API）调用的服务，它的主要任务是周期性地向客户端发送通知，包括报警、事件、数据变化等。监控项是由客户端在服务器中创建的实体，用来监测地址空间内节点及其他们所对应的物理实体。若某一个监控项检测到有数据变化或者事件/报警发生时，便会产生一个通知消息，通过订阅发送给客户端。订阅是客户端控制请求发布的条件，用来由监控项向客户端发送通知，也就是说，客户端与服务器是通过订阅进行消息交互的。OPCUA协议（1）订阅和监控项概述订阅和监控项是OPCUA服务器与客户端交互的桥梁。与传统的基于COM/DCOM的OPC采用轮询查询进行数据访问的方式不同，OPCUA规范中规定消息的发布是通过订阅周期性地向客户端发送监控项消息队列中的通知消息。OPCUA订阅与监控项在服务器中的分布如下图所示。OPCUA协议（2）监控项模型客户端通过定义监控项来订阅数据和事件等，而每个监控项都被指定了需要被监控的内容和发送通知的订阅。被监控内容可以是任意一个节点的属性，通知则是描述被监控对象发生变化的数据结构和事件等，这些通知被打包成消息通过订阅发送给客户端。下图中的通知器是可订阅的对象，订阅后可从相关联的条件节点中获取事件，事件数据用于指定要更新的事件的信息。监控项有四个主要属性来定义被监控项如何被采样、评价和报告，在左图中已有所示意。这四个主要的属性为：采样间隔监控模型过滤器属队列属性OPCUA协议(3) 订阅模型订阅用于接收来自监控项的通知消息，并将其转发给客户端，这也说明了订阅只能从OPCUA服务器读取信息，而不能写入信息。订阅实现的过程如右图所示，过程大致如下：1) 客户端向服务器发出订阅请求；2) 服务器接收到订阅请求后创建订阅，并通过监控项监控数据变化及事件；3) 监控项监测到数据变化或有事件报警；4) 监控项调用客户端的服务，通过订阅将通知消息发送给客户端，这种模式也称为“回调（Callback）”。MT-Connect协议目前，大多数工业通讯协议（包括OPCUA）是彼此不兼容的，即异构制造设备间无法直接进行信息交互。而针对异构设备定义专用的数据接口来实现单元内所有设备互联通信将造成开发成本增加，因此，美国机械制造技术协会（AMT）在2006年提出了机床设备互联互通协议MTConnect协议。MTConnect协议与OPCUA协议相似，是一种开放、免版税的设备互联标准和技术，旨在采用互联网协议通过网络传输数据，实现数控系统、设备和应用软件之间更广泛的互操作。但两者存在以下区别：OPCUA能进行双向的实时数据读取和写入MT-Connect只能进行实时数据监视（读）MTConnectV1.3.0标准架构和协议概要数据模型和设备信息机床状态信息数据模型语义模型本书将仅对MT-Connect的关键概念与技术做出介绍。MT-Connect协议：标准架构MTConnect协议的应用系统由五个基础的组件组成，如右图所示。包括：Device（设备）Adapter（适配器）Agent（代理服务器）Network（网络）Application（应用程序）等MT-Connect协议：标准架构（1）Device——设备Device通常是一个刀具，但是也可以是机床设备、工业软件或者数据源等。（2）Adapter——适配器Adapter用于建立一个从数据源和MT-ConnectDataDefinition之间的连接，实现Agent与不同数据协议设备之间的数据交互，即Adaper负责将非MT-Connect标准的设备数据转换成MT-Connect标准。因此Adapter可认为是一个翻译器，即它具备可选属性，且在以MT-Connect为本地语言的设备上是不需要的。MT-Connect为开发者提供Adaper开发包，Adaper可以嵌入到设备控制器，也可以以软件的形式集成到监控计算机中。MT-Connect协议：标准架构（3）Agent——代理服务器Agent是一个收集、组织、存储来自于Device或Adapter数据的软件，是MTConnect协议数据采集的核心组件。Agent负责工业设备信息的采集，并响应应用程序的请求，为其提供所需的数据服务。Agent可以嵌入到设备控制器内部，也可以分布在网络中。Agent的数据字典在MTConnect标准中进行了定义，源代码也是开源的，支持多种语言开发平台，包括C#、C++、JAVA等，开发者可通过Agent调用设备的API获取实时数据，然后以XML数据格式提供给应用程序的数据请求。（4）Network——网络Network是数据源（Device）和数据消费者（Application）之间的物理连接，通常指的是以太网。值得注意的是MT-Connect结构是可变的，可以使用除了Ethernet和网络协议之外的其他网络解决办法。这是唯一在MT-Connect标准里定义的通讯系统的部分。MT-Connect协议：标准架构（5）Application——客户端应用程序Application是实际的MT-Connect数据请求者和消费者。通常应用程序的功能就是请求、存储、维持和展示数据。MT-Connect应用程序开发独立于设备底层协议，MT-Connect采用XML格式表达数据，即Agent发布的消息是由MT-Connect标准定义的XML数据文档。【综上所述，MT-Connect系统的数据交互流程】Adaper将从工业设备采集到数据转换为对应Agent可识别的数据格式；Agent从Adaper获取数据，并对数据进行封装，形成MT-Connect标准格式的采集报文；Application向Agent发起数据请求，由Agent向用户返回相应的数据信息。MT-Connect是一种只读协议，不支持工业设备的反向控制。【MT-Connect特性】开放性的标准使客户在购置设备时不需再考虑异构设备交互操作性和非兼容性的问题，客户端应用程序开发者也无需考虑底层数据的格式，直接使用Agent提供的统一数据访问接口，程序通用性良好，可移植性高。MT-Connect协议：设备描述方法MT-Connect标准采用可扩展标记语言（ExtensibleMarkupLanguage，XML）描述设备数据，也是MT-Connect协议可适用于不同类型设备的描述、监控、管理和互操作的关键。【XML数据】以纯文本格式存储，因此XML提供了一种与硬件和软件均无关的数据共享方法，允许开发者创建一个可被不同应用程序读取的数据文件。因此，XML可以轻易地描述不同种类工业设备/应用软件中的各种类型数据，实现了MT-Connect标准的统一数据接口，支持不同来源的结构化数据间的交互，大大减少了数据交换的复杂性。【XML文档】以“元素”为单位组成，元素指出了文档的逻辑结构，并且包含了文档的信息内容。每一个元素至少包括开始标签、结束标签和CDATA三个部分。CDATA实质上是该条元素的内容。如<FOO>ACK!</Foo>，“<FOO>”为开始标签，“</Foo>”为结束标签（ACK!”为该条元素的CDATA“

）；XML允许元素自定义属性，格式为<元素名属性名=“属性值”>，如<FOOname=“bob”>ACK!</Foo>。还允许元素嵌套，即单元素可包含多个子元素，但一个元素包含CDATA，则不能嵌套子元素。MT-Connect协议：设备描述方法【XML文档】文档的首行通常是XML声明，如：1. <?xmlversion=“1.0”encoding=“UTF-8”?>上述声明指明了XML的版本号和编码方式。每个XML文档必须有且只有一个根元素，MT-Connect支持4种根元素：MT-ConnectDevicesMT-ConnectStreamsMT-ConnectAssetsMT-ConnectError该类文档提供各个设备的描述性信息，并指定可使用的数据项类型。该类文档按照时间序列提供设备及其组件的采样、事件、条件等信息。该类文档包含与机床资产相关的信息，此类信息并非机床的直接组件，并且在其设备生命周期中可转移给其他设备，如刀具。该类文档提供请求处理过程中出现的错误信息。MT-Connect协议：设备描述方法MT-Connect使用XMLSchema来判断XML是否符合要求，其根元素必须提供XMLschemaURL和位置，一个标准的XMLschema属性如下所示（以MT-ConnectStream类报文为例）：1.<MTConnectStreamsxmlns:m=“urn::MTConnectStreams:1.1”2.

xmlns:xsi=http:///2001/XMLSchema-instance3.xmlns=“urn::MTConnectStreams:1.1”4.xsi:schemaLocation=“urn::MTConnectStream:1.1”/schema/MTConnectStream.xsd”>从表现形式来看，XML报文包括有两个部分：Header和Body。其中，Header必须是根元素的第一个子元素，提供与协议相关的说明信息，包括createTime、nextSequence、instanceId、sender、buffersize等。表3-10（翻页）说明了MT-ConnectV1.3.0可提供的所有的Header属性。MT-Connect协议：设备描述方法属性名称说明出现率createTime创建时间1nextSequence64位无符号整数，用于指定下一个请求的序号，最大值为2^64-10或1instanceId64位无符号整数，指明是代理服务器的哪一个调用命令1TestIndicator可选属性，用于指明系统正处于测试模式0或1sender代理服务器的身份识别信息1bufferSize指定代理服务器可支持的Samples、Events和Condition数量1firstSequence第一个可使用的采样或事件的序列号0或1lastSequence最后一个可使用的采样或事件的序列号0或1version协议版本号1assetBuffersize代理服务器可存储的最大资产数量1assetCount代理服务器当前的资产总量1表3-10MT-ConnectV1.3.0的Header属性说明MT-Connect协议：设备描述方法不同根元素的Header具备不同属性，MT-ConnectStreamsHeader格式如下：<HeadercreationTime=“2010-03-13T03:59:11+00:00”sender=“localhost”instaceId=“1268463594”bufferSize=“131074”version=“1.1”nextSquence=“156”firstSequence=“1”lastSequence=“155”/>XML报文的Body部分是Devices、Streams和Errors的具体信息，并按层次封装，可读性强。如下Errors描述报文的Body部分：<Errors><ErrorerrorCode=“OUT_OF_RANGE”>Argumentwasoutofrange</Error><ErrorerrorCode=“INVALID_XPATH”>Badpath</Error></Errors>MT-Connect协议：设备描述实现1设备组件描述MT-ConnectDevices文档描述设备的配置信息以及满足客户端程序用于发送的数据。设备本身可以看做是许多组件（Component，如轴、电源、传感器等）的有机集合，每个固定的组件都有自己的属性（如名称、主轴数、最大转速、最大工作长度等），同时每个组件还可以有子组件。从XML文档结构上讲，Devices元素作为MT-ConnectDevices文档的核心元素，也是Body部分的第一个元素，它还包含许多的Component（组件），这些Component按照功能逻辑进行组织，MT-Connect协议标准采用不同的标识定义不同的逻辑组件和设备名称。在MT-Connect协议中，Devices元素具有统一的组件类型，可支持所有符合MT-Connect协议标准的设备或组件功能定义。这样通过XML文档可以描述任意复杂的设备，支持一个代理对多个设备的连接与识别。下图（翻页）是MT-Connect标准定义的一种MT-ConnectDevices逻辑架构。MT-Connect协议：设备描述实现1设备组件描述MT-ConnectDevices各部分构成Component作为Devices元素的重要组成部分，最能体现一个设备的构造特点和功能，是客户端获取设备测量数据的保证。MT-Connect协议：设备描述实现1设备组件描述Component元素主要包括四个部分：ComponentDescription、ComponentComponents、ComponentDataItems和ComponentConfiguration，其中Components和DataItems是最主要的两个元素。ComponentsComponents是一个集合，包含了所有与当前设备相关的子元素，实质上就是由一个或多个Component构成的XML元素。目前，MT-Connect协议标准可提供的组件类型包括轴、控制器、系统等，详见表3-11（翻页）。DataltemsDataltems（数据项）是从Device、Component或Subcomponent中采集到的一些数据信息，比如Sample和Event类反馈的一些数据，或者Condition类反馈的有关设备的运行状况信息。MT-Connect协议：设备描述实现1设备组件描述Components组件类型功能说明轴（Axes）通过速度和位置对轴进行描述，其中轴位置数据以机床坐标为参考系控制器（Controller）描述有关程序执行的信息以及设备当前的工作状态系统（Systems）用于描述一个设备所有相关部件和子部件的工作状态，与轴类型类似，但是最为复杂且不易被拆分传感器（Sensor）提供相关设备和组件的测量数据，该类型组件是独立运行的执行机构（Actuator）用于描述将系统控制信号转换成相应动作的机构。门(Door)门类型用于描述防护门的打开和关闭状态。表3-11MT-Connect协议标准组件类型及功能说明MT-Connect协议：设备描述实现2数据流描述数据流MT-ConnectStreams用于表示客户端某个时刻从设备和其组件中采集到的Samples（采样值）、Events（事件值）和Condition（条件值）。SamplesEventsCondition某一时刻某一数据项的测量值，例如位置、转速等，这个测量值是连续变化的。一系列逻辑状态的改变，如执行状态、控制模式、G代码程序名等，它是设备或组件状态的离散变化值，是异步的。提供关于设备的运行和工作状态数据或设备性能信息，如Normal、Warning、Fault、Unavailable。数据流Streams至少包括有一个DeviceStream（设备数据流），而DeviceStream由一个或多个ComponentStream（组件数据流）元素构成，个数取决于Samples和Events的数量。MT-Connect协议：设备描述实现2数据流描述如图是MT-ConnectStreams的Schema图，显然Samples、Events和Conditon是数据流的最底层元素。注：DeviceStream的目的是保存设备具体信息，这些信息并不需要频繁地更新。这样就只需要在DeviceStream中传输一些需要的数据即可，有利于减小Samples和Events的大小。MT-Connect协议：设备描述实现3资产描述MT-Connect协议中资产（Assets）是有关于机床加工刀具方面的描述，通过MT-ConnectAssets类XML报文进行定义。资产涉及的内容主要是刀具、工装夹具、固定装置等，这些是与制造过程紧密相关的，但是它们并不是设备本身的组件，因此在不影响设备功能的情况下是可以去掉的。MT-Connect协议只关注与所建模型有关，并且能够使用MT-Connect协议进行数据传输和管理的资产内容，这些内容主要是刀具类型和刀具参数，包括四个部分：CuttingItemToolItemAdaptiveItemAssemblyItemMT-Connect协议：设备描述实现3资产描述当然刀具的种类是非常繁杂的，很多刀具的几何尺寸也非常复杂，但是MTConnect协议只提供在加工过程中需要的几何信息，如果想要获取其他的信息需要通过添加XSD文件来实现。MT-Connect资产结构图MT-Connect协议：设备描述实现4错误描述MT-Connect协议采用HTTP状态码来标识代理对请求的响应状态，目前MT-Connect代理支持以下4种HTTP状态码，见表3-12。HTTP状态代理状态Error说明2000K请求在代理服务器中被成功处理400BadRequest请求不能被代理服务器解析500InternalError在请求处理过程中，代理服务器产生一个内部错误501NoImplemented代理服务器不支持当前请求，无法处理表3-12MT-Connect支持的HTTP响应代码如果代理不能处理一个请求，将会返回MTConnectError文档，该文档以Error元素定义了所有请求相关的错误类型。每个Error元素包含了一个错误代码（表3-13）和一个完整错误Error元素内容的文本数据（CDATA）。错误代码说明UNAUTHORIZED没有足够权限执行请求NO_DEVICE没有发现URI中指定的设备OUT_OF_RANGE序列号超出缓冲区末尾TOOMANY范围(count)超出INVALIDURIURI格式不正确INVALID_REQUEST请求不符合指定的请求要求INTERNAL_ERROR代理工作不正常INVALID_XPATH无效的语法UNSUPPORTED代理不支持该功能或请求的类型ASSET_NOT_FOUND找不到指定资产的位置表3-13Error元素的错误代理MT-Connect协议：设备描述实现4错误描述1. HTTP/1.1200Success2. Content-Type:text/xml;charset=UTF-83. Server:Agent4. Date:Sun,23Dec200721:16:56GTM5. 6. <?xmlversion=“1.0”encoding=“UTF-8”?>7. <MTConnectErrorxmlns:m=“urn::MTConnectError:1.1”xmlns:xsi=http:///2001/XMLSchema-instancexmlns=“urn::MTConnectError:1.1”xsi:schemaLocation=“urn::MTConnectError:1.1”http:///schema/MTConnectError.xsd”>8. <Header…/>9. <Errors>10. <ErrorerrorCode=“OUT_OF_RANGE”>Argumentwasoutofrange</Error>11. <ErrorerrorCode=“INVALID_XPATH”>Badpath</Error>12. </Errors>13. </MTConnectError>示例（右）向读者展示了一种HTTP的错误信息MT-Connect协议：代理机制MT-Connect代理Agent负责工业数据的采集，并为应用层按需提供数据服务。实质上，Agent就是一种支持MT-Connect协议、基于HTTP协议和XML文件传输实现车间设备数据网络传输的软件服务。它通过XML报文描述各个设备的结构与功能，用以识别一个或多个与MT-Connect协议相兼容的机器设备。因此，Agent作为应用层与设备层之间的数据交互“纽带”，必须能够快速响应客户端的数据请求，请求格式必须符合MT-Connect协议规范。此外，为了更好的实现客户端对工业设备近乎实时性的监控要求，Agent还支持客户端可根据系统自身需求向其请求并获取所需的数据，以减少数据的传输量和时间。Agent除了采集数据之外，最关键的是如何高效保存数据。MT-Connect协议：代理机制1Agent数据存储Agent采用“管道式”定量存储数据。也就是说，Agent只能存储有限的数据，比如有限量的事件、样本和条件，数据总量被限定在Agent为自身设置的存储阈值内。Agent在存储方式上类似于“数据栈”，Agent会提供一条固定长度的单向管道，当设备数据有更新时，更新的数据便从一端塞入管道内部，若管道被装满，最初进入管道内部的数据项将被后面的数据项所替代。如图，假设Agent设置的缓存大小为8位，A最先进入管道，随后B、C、D…相继被塞入管道，当第8个数据项H被塞入后，管道便被塞满，此时，第9个数据项I进入到管道的时候，A即被挤出管道。MT-Connect协议：代理机制1Agent数据存储Agent为每个进入管道的数据项分配唯一序列号，序列号按照数据项进入顺序依次增加。客户端从代理服务器获取信息即通过数据的开始序列号（firstSequence）和数量（count）实现。对于当前请求，必须至少提供所请求数据项的最后更新值，才会知道该数据项是否被更新。因此，如果已经从缓冲区内删除了事件值（Event）、样本值（Sample）或者条件值（Condition）的数据项，Agent也必须保存该数据项最后更新的值作为后续数据请求的查询依据。如图，客户端从序列号15开始查询，数据长度为3，那么下一次查询的序列号（nextSequence）便是18，最后序列号（lastSequence）是19。如果客户端请求管道中的最后一个数据项，nextSequence的值将是lastSequence+1，只要管道中没有新的数据，客户端请求的数据超出了Agent缓存容量，nextSequence的值将保持为lastSequence+1。MT-Connect协议：代理机制2Agent资产存储Agent的资产存储机制与其数据存储十分类似，提供管道式有限的存储空间，并且缓冲区内数据储存满后，采用同样的方式将新数据替代旧数据。不同的是当资产缓冲区中某一项数据更新的时候，该数据项将直接从缓存区中移除，并将新的数据项值塞入缓冲区。如右图所示，A7的值在缓冲区时被更新，它便被移到最右端。因此，资产的数据项并不能采用序列号的方式作为标识，而是采用key/value的方式，其中key是独立的资产序号（assetId），value通过XML格式进行描述。assetId代表资产的特定编码，比如对于机床的刀具来说，它必须定义刀具的编号，作为刀具的唯一标识，可由任意字符串、数字号或标点符组成。MT-Connect协议：代理机制2Agent资产存储MT-Connect协议标准通过编号实现对资产的查询，查询结果将返回对应编号的资产文档Asset.xml中。表3-14中是几种本地Agent资产的查询方式。当客户端有设备资产添加或修改需求时，通过触发资产变更事件（AssetChange）告知Agent新的资产信息，然后客户端即可通过资产查询从Agent中获得最新数据。资产变更事件是会即时触发的，因为Agent一旦接收到资产变更请求，便会更新全部信息，而不是针对某个指定的独立的值去改变，这也就意味着许多相关的值都需要更改。查询类型查询地址单个资产url::5000/asset/cc多个资产mi:http://l:5000/asset/cc;g3;g5所有资产url:http://127.0.0.l:5000/assets按类型查询url::5000/assets?type=CuttingTool表3-14MT-Connect资产查询NC-Link协议：概述NC-Link（NumericalcontrolLinks）协议是中国自主研发的工业设备互联互通协议，由数控机床互联通讯协议标准联盟提出，支持数控机床之间、数控机床与生产线之间以及数控机床与企业信息化软件（CAX、MES，ERP、CAPP、PDM等）之间的互联互通。NC-Link与MT-Connect、OPC-UA都可用于工业设备的互联互通，在系统和模型定义上有很多相似之处，但是NC-Link可以兼容MT-Connect和OPC-UA协议，在实现和应用上有很多其他互联互通协议不可比拟的优势，见表3-15。

MTConnectOPCUANC-Link说明数据表达方式HTTP+XMLHTTP+SOAPHTTP+JSON+XMLNC-Link所采用的JSON可读性好，数据量小，速度更快数据模型有机床模型无机床模型有机床模型定义有机床模型，更适合加工设备和最终应用数据基本类型强类型强类型弱类型NC-Link弱类型更适合分布式系统，管控系统，更适合云服务和APP扩展应用数据流向单向双向双向双向是系统必须要求数据订阅无有有数据订阅提供按需获取数据安全无专用OauthNC-Link采用开放式安全标准，适用性更广，安全性更高跨平台强Windows支持强，其他平台弱强NC-Link使用基于WebAPI跨平台更好表3-15NC-Link、MT-Connect和OPCUA对比NC-Link协议：标准组成NC-Link是面向设备运行大数据采集的M2M（MachinetoMachine）协议，协议标准的结构由以下5个部分组成：通用技术条件在通用技术条件中，对标准的定位、组成、基础软硬件环境做了整体描述，是标准的基础部分。机床模型定义在机床模型定义中阐述了机床模型的描述方法，是标准的灵魂。数据字典对数控机床运行大数据内容进行标准化定义，建立数据一致性理解基础。接口定义对系统各部件互联互通方法进行标准化定义，是模型从定义到运用的关键。安全要求在该部分对设备接入认证、数据权限分层两个方面给出规范，从而确保设备安全运行、数据防泄密等安全性要求。NC-Link协议：体系架构NC-Link标准的体系结构由代理和适配器组成。适配器负责从设备上采集信息，并把采集的信息传送到代理。同时，适配器可以从代理器获取下行的控制信息，并把控制信息传送给相应的设备。适配器可以和多个设备相连，一个设备只能连接一个适配器，每个适配器必须连接一个代理器，且只能连接一个代理器。代理负责把适配器上采集的设备的信息传送到请求信息的相关应用系统，或者接收应用系统设备的控制信息，并把控制信息传送到与相关设备对应的适配器上。每个代理器支持多个应用系统，应用系统可以连接多个代理器。NC-Link协议：体系架构NC-Link标准不限定NC与适配器间的连接方式，仅要求适配器可以“适配”数控系统提供的通讯接口。适配器、代理、应用系统之间通过以太网互联，通讯协议采用TCP/IP。NC-Link联网模型可以兼容多种工控协议，如MODBUS、OPCUA、MT-Connect、Profibus-DP等，只要提供对应的协议转换模块，任何工控协议都可以接入NC-Link网络。NC-Link联网模型NC-Link协议：体系架构1适配器适配器由与设备通信的驱动模块、数据解析模块和通信模块组成，如下图。NC-Link适配器典型架构【驱动模块】负责与设备通信，从设备获取数据，或把数据设置给设备，不同厂家不同型号设备的适配器的驱动模块具有差异性。【数据解析模块】负责设备模型解析与数据映射。【数据传输模块】负责把驱动模块获取的数据以统一格式传送到代理器；或从代理器获取对设备的控制信息，并传送到驱动模块。NC-Link协议：体系架构2

代理代理包括与应用系统通信的上层数据传输模块和与适配器通信的下层数据传输模块。下层数据传输模块从适配器获取到设备的数据，或者把上层数据传输模块从应用系统读取到的控制信息传送到适配器。上层数据传输模块把下层数据传输模块传来的数据发送到应用系统，或者从应用系统获取对设备的控制信息。因此，NC-Link标准定义代理必备组件有三个：客户端接口、管理层和适配器接口，如下图。NC-Link代理器架构NC-Link协议：体系架构3客户端客户端（应用系统）为数据使用方，它与代理连接，按需采集数据以实现具体业务。客户端发出具体指令，通过代理透传到适配器，由适配器具体处理相应请求。客户端可以添加身份和权限信息于指令之上，通过代理的鉴权系统有甄别地发往适配器，实现数控系统远程控制。下图展示了一种客户端架构。NC-Link客户端架构NC-Link协议：设备模型1设备模型概述设备模型是NC-Link协议的核心组成部分，规范了“设备提供了什么数据”、“数据以什么格式提供”等关键问题。NC-Link设备模型由两部分组成：模式文件模型文件描述设备模型的JSON模式文件，简称Schema文件。该文件是NC-LINK描述设备模型的基础文件，在生成机床模型文件时使用，在进行数据传输时并不依赖该文件。根据模式文件，将具体的设备实例化，简称模型文件。对每一个设备都必须生成一个模型文件。模型文件的依据是模式文件，但不必包含模式文件的全部内容。每个设备的模型文件与该设备关联的适配器存储在同一个位置，代理器可以缓存该文件副本。NC-Link标准的模式文件与模型文件关系图NC-Link协议：设备模型1设备模型概述NC-Link采用面向对象的方法来描述设备运行过程中交互的信息模型。设备模型通过根对象、设备对象、组件对象、数据对象描述设备的组成、配置信息、可采样的数据和数据格式等相关内容。如下图，机床模型文件采用树状结构描述了机床构成、数据、采样通道等。NC-Link机床模型图NC-Link协议：设备模型2设备建模方法NC-Link设备模型使用