前言
近些年在“工业4.0”，“智能制造”，“工业互联网”的大背景下，工业现场设备层的数据采集逐渐成为一个热门话题，大家都认识到实时获取设备层数据、消除自动化孤岛现象是实现智能制造、工业互联网的重要基础环节。
但是，工业现场的设备种类繁多，各种工业总线协议并存，这也就导致了数据采集这项工作是一件非常个性化的事情，很难总结出一套放之四海而皆准的方案来。
在这里结合我以往的项目经验，为大家梳理一下如何针对不同的设备情况制定经济高效的数据采集技术路线。
实现数据采集的原则
目的性
在做设备的数据采集之前，先问问自己为什么要采集这些数据，这些数据到底能够带来什么样的业务价值。工业现场其实已经有很多的数据采集系统了，SCADA、HMI什么的也都是应用很广泛了，但是，请问，这么多年下来，其中又有多少数据被充分的分析，挖掘其潜在的价值。
大多数情况是，采集了很多数据，但是大家都不知道怎么用。诚然，国内大部分的工业现场还处在解决生产过程可见性的阶段，因此，能够先把数据采集上来是当务之急，至少能够实时地了解到现场都发生了什么。但是，在智能制造的大背景下，我们能否再看的远一些，在做数据采集之前，尽可能地多去思考一下什么样的数据对我们的业务改进帮助最大，这样也许会让我们在数据采集方面的投资回报率更好看一些。
经济性
对于工业现场的数据采集，很多人第一个想法就是装传感器，尤其是没大去过现场的广大IT从业者。记得之前有一次打单，有位厂长说到，“数采其实很简单，只要花钱就一定能解决，没有采不上来的数据”。听后我深以为然。确实如此，现在传感器技术这么发达，只要肯投入，玩了命地往设备上装传感器、数采板卡，肯定能采集到你想要的数据。但实际上我们真的能这么做吗？不管什么样的项目，我们首先需要考虑的是投资回报率的问题，而装传感器的方式可能是投资最大的一种。因此，我们做设备层的数据采集，一定要结合我们的数采目标，充分利用设备的现有条件（比如，设备已经具备的上位机系统、已经具备的通讯协议等）用最经济高效的方式来做数采技术路线的设计。
此外，很多情况下，装传感器和板卡都需要涉及到一定程度的设备改造，不仅技术上有难度，也会对设备运行的稳定性方面造成影响。因此，可以负责任的讲，这种装传感器、数采板卡的数据采集方式应该是我们最后的选择，而非最优选择。
数据采集的技术路线
工业现场设备的数据采集是一项非常个性化的工作，需要从设备的自身情况着手，因此，先将设备进行分类，如下图所示，不同的设备采用不同的技术手段，当然，各种技术路线的实现难易程度有很大的差别。下面我们就各种设备的技术路线进行逐一的阐述。
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的值。举个栗子，比如采集某些老旧设备的运行时间数据，这些设备往往没有对外通讯的接口，我们没有办法直接获得其运行和停止的开关量信号。可以装个互感器监测设备电机的电流，以电流的大小来判断设备的启停，以此获得设备的运行时间。
结语
上述列举的各种技术路线只是根据我有限的项目经历的总结。工业现场的情况纷繁复杂，欢迎各位拍砖，补充其他的一些场景。
欢迎转载，转载请注明出处。
如果想获得更多关于智能制造以及物联网方面的文章，关注我的公众号“聊聊智能制造那些事”，查看历史文章即可。