本文目录

工业生产现场设备层数据采集基础教程

编辑导语： 前言之前写过一篇《聊聊如何做工业现场设备层的数据采集》，其中介绍了针对工业现场多种不同设备的数据采集技术路线，很多看过的朋友都表示其中干货不错，但是真正实践起来还是有很多困惑。究其原…

前言

之前写过一篇《聊聊如何做工业现场设备层的数据采集》，其中介绍了针对工业现场多种不同设备的数据采集技术路线，很多看过的朋友都表示其中干货不错，但是真正实践起来还是有很多困惑。

究其原因，还是由于对工业现场设备层数据采集所涉及的原理缺乏深入的理解。毕竟，工业现场设备层的通讯情况千差万别，只有对相关原理有了深入的掌握才能应对自如。

因此，在这里我想把数据采集这个主题相关的原理知识、技术路线以及一些目前可以利用的组件等进行一次较为全面的介绍，为希望对数据采集进行深入研究的朋友提供一些帮助，同时，为了能够便于理解，本文对一些概念不做过于深入的介绍，希望能够用尽可能简单的语言把需要掌握的要点阐述清楚。

注：下文中参考并引用了很多网文，一并在文章的最后列出，方便大家对相关内容的深入了解

一、设备层数据采集的本质

工业现场设备层的数据采集本质是两个系统之间进行信息交互的过程。

注：这里所说的“系统”不仅包括软件系统，还包括PLC，数控机床等设备。其实有一个概念大家应该清楚，很多以“硬件”形式展现在我们面前的设备，只要其内部进行数据处理的单元是单片机、嵌入式等处理器，那么都可以将其等同于一台配置较低的电脑，我们做数据采集的过程往往都是跟这些处理器打交道

如下图所示，数据采集系统发送“获取数据的请求”给设备，设备将“所需的数据”发送给数据采集系统，完成数据采集过程。

二、背景理论知识

认清了数据采集的本质，我们来了解一下其所涉及的理论知识。

OSI参考模型

我认为，OSI参考模型是数据采集领域最重要的基础知识，是对上文提到的“数据采集本质”的重要支撑。只有充分理解OSI参考模型，才能理清协议等数据采集领域的其他重要概念。

先看官方的定义：OSI，是Open System Interconnection的缩写，OSI参考模型是国际标准化组织（ISO）制定的一个用于计算机或通信系统间互联的标准体系，一般称为OSI参考模型或七层模型。

那么这个定义颇为晦涩的东西到底有什么作用呢？上文提到，数据采集的本质是两个系统之间进行信息交互的过程。而这个模型正是两个系统之间进行信息交互的模式的约定。可以说，所有的数据采集方案都是基于这个模型的框架，这个模型是我们解决所有工业现场设备层数据采集问题的根本，是一切数采方案的落脚点。

这个模型如果深入研究起来，恐怕要说上一天一夜，在这里希望通过简单的介绍帮助大家快速掌握最重要的内容。

首先，OSI模型分为七层，如下图所示。这里不做详细介绍，大家暂时不理解也不要紧，只需要记住一点，两个系统之间的信息交互要按照这七层的方式。

其次，两个系统是如何进行基于这七层模型进行信息交互的呢？

简单讲，如图3中所示，一段数据“DATA”如果想通过网络从一个系统传递到另一个系统，需要先在发送信息的系统（源系统）按照七层模型进行数据的逐层封装，在经过网络到达接收数据的系统（目标系统）后，再进行数据的逐层解封，最后识别出这个“DATA”。

图3中每一层中的黄色部分就是在该层进行封装时所加入的内容，这些内容包括IP包头、TCP/UDP头之类的，数据中只有加入了这些内容，才能在该层传播。而解封的过程恰好相反，相当于一个拆包的过程，将黄色的部分逐层去掉，最终剩下那个我们真正要传递的“DATA”。

最后，经过上述的讲解，如果大家还是觉得上述ISO七层模型以及数据交互过程过于复杂的话，也不要紧，只需要记住下面两句话即可：

两个系统之间的数据交互要按照ISO七层模型的方式进行
数据的传递过程是原始数据在各层中逐层封装以及解封的过程

TCP/IP四层模型

因为我们平时接触的网络通讯方式大多是基于TCP/IP的，所以有必要在了解了OSI模型的基础上，进一步对TCP/IP 四层模型进行掌握。本文中后续的内容也将以TCP/IP四层模型为落脚点进行介绍。

可以把TCP/IP 四层模型理解为OSI七层模型的简化模型，这也是我们网络中常用的消息传输模式。

TCP/IP 模型将OSI模型汇总最上的3层（应用层、表示层、会话层）视为应用层，将最下面的两层（数据链路层、物理层）视为网络接口层，所以 TCP/IP只有4层。

协议及协议解析过程

一提起协议，好多同学纷纷表示头疼不已——很难分清各种协议的区别，更不要说做协议解析等工作。

其实，协议就是一种数据格式约定，进行信息交互的系统通过这种约定进行数据的封装和解封，实现彼此之间信息的传递。下面举个栗子来帮助大家进一步理解协议的本质。

以Modbus-TCP协议为例，下图是按照该协议的格式编写的一段数据，一般称之为报文。

这段报文是由数据采集系统发送给设备的，用来请求设备的指定数据。这段报文主要有两部分组成，报文头和报文内容。报文头中一般包含一些通讯的基本信息，报文内容中主要包含实际传输的数据。

具体解释如下：

事务处理标识：可以理解为每次所发送报文的编号
协议标识：Modbus包含多种协议，Modbus-TCP是其中一种，用00 00作为标识
长度标识：余下的报文的长度，以字节为单位（注，这里的每一数字都是16进制的，因此每两个数字就是一个字节的长度）
单元标识：表示报文发送的目标设备的编号或标识，这里就是发送给编号为“01”的设备
功能码：表示这次发送的报文所要完成的功能，例如读某个地址中的数据，或者向某个地址中写入数据等，这里的“01”表示读取数据
起始地址：表示从目标设备的该地址开始读取数据
数据位数：表示从上面的起始地址开始，读取多少位的数据。注意，这里的数字是“位”的数量，不是“字节”的数量，因此，这里是读取8位数据，即一个字节的数据

通过对上图中一串数字的拆解，我们知道，报文的主要意思是，从编号“01”的设备中的“0002”地址开始读取八位的数据。

设备接收到上述请求后，会回复相应的数据，下图是回复的报文。

其中，

数据长度：表示真正需要获取的数据的字节数，因为上文中请求的是8位数据，即1个字节的数据，所以这里的长度是“01”
数据：这是我们真正要获取的数据

大部分的工业总线协议实质上都是对这样一串由数字组成的报文中不同部分的约定，所谓的协议解析，正是按照上述的约定进行不同数字段落的解读。

很多时候我们不需要了解具体的协议约定，只要根据协议选择对应的协议解析组件，例如kepware等，它们会帮我们完成该协议的数据格式解读，将我们最为关心的数据直接提供给我们。所以大家只需要理解这个协议解析的原理即可。

TCP/IP四层模型与协议的关系

TCP/IP四层模型中每一层都有对应的协议，见下表，这些协议共同组成了我们常说的TCP/IP协议簇，通过这些协议的组合使用，实现系统之间的数据交互。

我们接触最多的互联网以及生产办公环境的以太网都是采用TCP/IP协议簇的网络。

这里有一个非常重要的概念需要澄清。我们耳熟能详的那些工业现场协议大多是应用层的协议，例如OPC Classic, Modbus-TCP。而我们在数据采集领域经常要做的协议解析也主要是针对应用层的协议。我们还以Modbus-TCP为例，它只是应用层的协议，而为了能够在网络中传输，还需要传输层等其他各层的协议的配合，如下表所示

经常在现场听到这样的对话：“这个设备支持什么协议？”“TCP协议”

这样的答案所提供的信息对我们的数据采集来说还不够，因为TCP是传输层的协议，我们做数据采集最关心的是应用层所采用的协议，就像上文中列举的Modbus-TCP协议解析的例子那样。

注：通常情况下，如果生产现场管设备的工程师告诉你这个设备采用的是TCP或者UDP的协议，那么大部分情况下，该设备在应用层采用的设备厂商自定义的协议，要想解析这样的协议，就只能问设备厂商提供报文的格式约定了。

我们做数据采集，其实就在和各种各样的协议打交道，实现协议的解析。很多同学一提到协议就发蒙，我认为根本原因就在于对TCP/IP四层模型缺乏了解，进而混淆各个层所对应的协议。

三、设备层数据采集的技术路线

注：这一节中的内容主要来自之前写的文章《聊聊如何做工业现场设备层的数据采集》

在制定数据采集方案的时候，我们要对设备进行抽象，将关注重点放在该设备所支持的通讯协议上，按照不同的协议制定不同的解决方案，而非针对设备本身。

工业现场设备的数据采集是一项非常个性化的工作，需要从设备的自身情况着手，因此，先将设备进行分类，如下图所示，不同的设备采用不同的技术手段，当然，各种技术路线的实现难易程度有很大的差别。

下面我们将各类设备主要按照设备的协议进行分类，针对不同的协议制定不同的技术路线。

1. 有上位机系统的设备

这里的上位机系统一般是设备自带的监控系统，这样的设备往往自动化程度和信息化程度都比较高。其上位机系统往往已经对设备层的数据进行了采集、存储，因此，对于这种有上位机系统的设备，我们首选的数据采集方案就是直接从上位机系统中获取设备的数据，而不是去和设备打交道。这样就能够把一个OT的问题（设备层的数据采集）转化为IT的问题（两个信息系统的信息集成）。

因为上位机系统能将设备的数据存储到自身所带有的数据库中，然后以开放数据库访问权限的方式，或以WebService等方式释放数据访问接口。这两种方式都是我们IT工程师最为熟悉的，显而易见，实现起来也比直接与设备通讯来的容易。我之前在现场接触到的某德国品牌的自动货柜（见下图）就是采用的WebService的方式与外部的信息系统进行数据交互，非常的方便。

当然，利用上位机系统进行数据采集的重要前提条件是该上位机系统的数据开放性。其实，目前工业现场有很多上位机系统，但是，这些系统与设备自成一体，并没有对外进行数据交互的接口，比如，数据库不开放等。这也就构成了我们经常说的工业现场的“自动化孤岛”——设备的数据虽然已经采集到了上位机系统中，但是仍然无法向其他信息系统中传递，仍然被“困”在生产现场。

2. 基于TCP/IP通讯协议的设备

对于生产现场中没有上位机系统的众多设备，我们就需要从设备所支持的通讯协议角度入手，制定数采方案。

对于“基于TCP/IP通讯协议”，比较常用的有OPC Classic、Siemens S7、Modbus-TCP等通用协议，也有设备厂商自行定义的私有协议。这些协议的特点是都是基于TCP/IP协议簇，只是应用层协议不同。采用这些协议的设备一般都会有RJ45的接口，也就是以太网口，都可以直接通过以太网接入到车间网络中。对这些设备的数据采集，我们需要做的就是对上述协议的解析。

对于OPC等通用协议，其实这方面的工作属于工业自动化的范畴，已经有很多成熟的SCADA产品可以利用，近些年，也有很多开源框架、商业化的组件可以应用，比如Eclipse neoSCADA，Kepware等等，都能够在完成上述协议的解析的同时，将其转换为一些IT领域常用的接口（RESTful API），方便其他信息系统的对接。

对于私有协议，只能自行开发协议解析模块进行对接，好在一般情况下，设备厂商的私有协议都不会太复杂，并且会提供SDK辅助开发，降低了开发的难度。

3. 基于非TCP/IP通讯协议的设备

这一类协议不属于TCP/IP协议簇，往往在硬件接口方面就与以太网不兼容，比如RS-485等。因此，对于这类设备的数据采集首先需要增加网关，将其协议转换为TCP/IP协议，才能接入到车间的网络中并进行协议解析。否则，在物理层面就无法实现互通，就更不要提协议解析了。这类协议比较常用的包括Modbus-RTU、DeviceNet等。下图列举了应用Nport串口服务器作为网关将RS-485接口的协议转换成UDP协议的过程。类似的协议转换板卡有很多，大家可以根据需要自行选取。

4. 不具备通讯接口的设备

这类设备一般为老旧设备，比如那些不带数控系统的机床。遇到这样的设备也是一件比较头疼的事情，我一般会建议不要做这种设备的数据采集，如果一定要做，也可以在机台上放置一个触摸屏之类的设备，用人工辅助的方式采集一些生产相关的信息。之前在三菱电机的工厂参观他们的e-factory系统时，就看到类似的实现方式，我个人认为，不失为一种经济简洁的方式，毕竟我们不是为了采集数据而采集数据，而是为了实现某个业务目标。

如果一定要采集老旧设备的一些运行状态信息，那么就只能是增加一些传感器、数采板卡之类的硬件设备，这就涉及到对设备的一些改造，操作难度还是非常大的，需要将数采板卡直接通过硬接线的方式接入其电控系统中，会对设备的稳定运行带来一定的风险。所以，这样的方式只能是设备厂商的选择，并不适合甲方，更不适合IT厂商。

5. 补充：数据采集的曲线救国方式

某些情况下，在直接采集某目标量Y1比较困难的情况下，可以考虑采集其他比较容易采集、且采集成本较低的其他目标量Y2，用Y2来近似计算Y1的值。举个栗子，比如采集某些老旧设备的运行时间数据，这些设备往往没有对外通讯的接口，我们没有办法直接获得其运行和停止的开关量信号。可以装个互感器监测设备电机的电流，以电流的大小来判断设备的启停，以此获得设备的运行时间。

四、其他需要澄清的概念

做工业现场的数据采集经常会涉及到以下的一些名词和概念，在这里争取抛开书本上的定义，主要从实践的角度做一下简要的介绍。

上位机

所谓的“上位机”，其实是与设备相对的，一般会把设备，如PLC等，叫做下位机，而与设备联网通讯的工控机称之为上位机，上位机一般是位于生产现场的设备附近。

可以将上位机看做是一台计算机，它通过网络与设备连接，能够获取设备的数据，展示设备的运行状态，操作人员也可以通过上位机上的人机交互界面对设备进行控制。

SCADA

SCADA是Supervisory Control And Data Acquisition的缩写，翻译成中文就是“监控与数据采集”。

如果从SCADA的字面意思来看，其包含了用于设备数据采集及监控的所有软硬件，包括传感器、数据采集组件、展示界面等等。但是，一般我们所说的SCADA都是指软件部分，即监控系统部分，完成的主要功能是与设备的协议对接与解析以及界面展示等功能。

这里大家需要注意的是，虽然SCADA系统在流程工业应用较为广泛，例如我们经常在化工厂某个车间的中控室中看到整个车间产线的监控大屏，但是SCADA并非一定是那种比较庞大的监控系统，而且也不是只有流程工业才有应用。只要是实现数据采集与设备状态监控功能的系统都可以归类为SCADA。甚至一台设备的上位机系统本身就是一个小型的SCADA系统。

工业现场的SCADA系统和一些设备的上位机系统中存储了大量的设备层数据，而且很多都是结构化的数据，这些SCADA系统也是我们获取设备层数据的重要途径。很多情况下，我们往往通过对这些系统的数据库的访问就能实现大量设备层数据的获取。

DNC

很多涉及到机械加工的离散制造业会应用DNC系统，DNC是Distributed Numerical Control的缩写，即分布式数控。从名字中我们可以看出DNC是与带有数控系统的设备打交道的，如数控机床等。

DNC系统的作用是将数控设备联网，通过对这些设备的数控加工程序的统一管理，包括程序的下发、修改等，实现数控设备的统一管控。与SCADA的作用不同，DNC主要的作用是控制，而且是通过数控程序的统一联网管控的方式来控制数控设备的生产作业。当然，一般的DNC系统也会完成一些设备监控的功能，但是其核心的功能还是控制，虽然我们可以利用DNC间接获取一些设备数据。这一点是我们需要注意的。

五、智能制造背景下，数据采集领域的新需求

在智能制造背景下，在数据获取方面，单一的设备层数据采集已经无法满足需求，我们需要的是IT与OT的融合，即“OT层的数据采集”加“IT层的信息集成”。

下图是工业4.0的六个成熟度水平，其中第二个Connectivity连接性阶段是后续四个阶段的基础，为了能够实现后续可视化、透明性、预测性以及自适应性，我们在连接性阶段只采集设备层的数据是不够的，一定要将IT系统中的业务数据与设备层的运行数据充分融合，才能实现更多的创新应用场景。

以预测性维护场景为例，为了建立预测性维护的模型，我们需要从设备层获取设备运行状态信息（OT数据），同时也需要从设备运维管理系统中获取设备维修记录（IT数据）。同时，我们的预测性维护系统所产生的设备故障预警信息需要和设备运维系统（IT系统）实现集成，来驱动设备维修流程。

设备层的数据采集能力与IT系统的信息集成能力都是智能制造领域所需要的关键能力，缺一不可，只有兼备两方面的能力才能实现IT与OT的数据融合。因此很多工业物联网平台都配备了对IT层的信息集成能力，如下图所示，ptc的Thingworx平台内置了很多连接器，实现与众多信息系统的集成。

六、常用数据采集组件简介

通常情况下，如果我们进行数据采集的设备所采用的是一些常见的通用协议，我们可以选择市面上成熟的数采组件，而不用自己去从头开发协议解析程序。下面简要介绍两个常用的数据采集组件。

注：这里聚焦在那些专注于数据采集的组件的介绍，像组态软件、物联网平台之类的产品由于提供的是完整的功能开发支持（包括数据采集、数据处理、数据展示等功能），因此不在介绍范围内

Kepware

大名鼎鼎的Kepware相信不少人都听说过，其中主打的产品就是kepserver。

简单来说，kepserver扮演了一个协议转换的组件，核心的功能就是将工业现场PLC等设备的OT层协议（例如西门子PLC的S7协议）转换成OPC UA、MQTT、RESTful等IT层的常用协议，打通IT系统与设备之间的通讯，以此实现设备层的数据采集。

kepserver的优点包括：

成熟稳定，kepserver在工业现场应用了很多年，性能上是非常可靠的
应用方便，只需要进行简单的配置就可以使用

缺点在于价格还是比较昂贵的。

kepserver的产品说明详见官方网站

HSLCommunication

HSLCommunication是国内牛人开发的一个用于工业现场设备数据通讯的组件，其本质是一个API库，目前提供了C#版本、java版本和python版本，下图是C#版本的项目结构，搞.net编程的同学一定很熟悉。

使用HSLCommunication的前提是你要会编程，能够写代码。当然，HSLCommunication已经对底层通讯的操作做了封装，只需要简单的调用API就能实现PLC等设备的数据采集。

HSLCommunication的优势有如下几点：

支持多种开发环境。作为一个API库，可以在多个开发环境中直接引用，包括Visual Studio, Visual Studio Code, IntelliJ IDEA, Eclipse, Labview以及Android Studio
灵活。与我们常用的组态软件相比，在用HSLCommunication开发工程时限制更少，因为它主要提供实现底层设备通讯的API，在此之上的应用开发完全不受它的约束和限制。不像组态软件那样提供了从数据采集到页面展示等一系列配置功能，所有的功能开发都需要在组态软件的框架下进行。同时，HSLCommunication作为一个API库，会与你的系统融为一体，不像kepware那样作为一个单独的系统存在
价格低廉。相对于kepware等商用组件，它的价格很亲民。

所以，HSLCommunication非常适合自身有一定的软件开发能力、且对所开发的功能有个性化需求的团队。否则，如果只是做一个设备的监控应用，莫不如选择工业上常用的组态软件（如组态王等），简单配置就可以实现。

其他详细信息可以参考HSLCommunication的官方网站

结语

数据采集的话题涉及内容很繁杂，在这里我希望用尽可能通俗易懂的语言把这个领域内我认为的重要内容讲述清楚。如果有遗漏或错误之处，希望大家能不吝赐教。对这一领域感兴趣的朋友可以关注公众号，和作者联系，大家一起交流学习。

参考文献：

百度百科 OSI七层模型 https://baike.baidu.com/item/%E4%B8%83%E5%B1%82%E6%A8%A1%E5%9E%8B/1441391?fr=aladdin
OSI七层模型与TCP/IP五层模型 https://www.cnblogs.com/qishui/p/5428938.html
计算机网络基础（二）---TCP/IP 四层模型 http://blog.movesan.me/2017/03/09/network-b/
网络OSI七层模型及各层作用与 TCP/IP https://www.shuzhiduo.com/A/1O5EZwa4d7/
ModbusTCP协议 https://www.cnblogs.com/ioufev/articles/10830028.html

最近更新于 2023-03-23，由 猿小六 于 2021-10-22 发布，已阅 3898 次。