互联网的出现实现了人与人之间的连接，物联网的出现实现了人与物、物与物之间的连接，使得万物互联成为可能。物联网时代，越来越多的企业将会使用物联网设备， 众所周知，一家企业并不是通过购买技术就能轻松进军工业物联网领域或者轻易完成数字化转型的。
万物互联时代，制造业对数字技术的应用早已是一个不可逆转的趋势。虽然这种转变是一个循序渐进的过程，但就目前来看，加快转变的速度早已给企业带来了巨大的压力。此前，惠普企业联合世界物联网协会（the Industry of Things World Conference ）进行了一项深入的调查。通过本次调查，旨在了解过去12个月中，众多企业推出的工业物联网项目取得了多大的进展。调查发现，只有53％的受访者认为他们的工业物联网项目达到或者超过了预期的目标；其余的47％表示他们的目标还没有达成。
众所周知，一家企业并不是通过购买技术就能轻松进军工业物联网领域或者轻易完成数字化转型的。工业物联网需要一个完整的架构，在这个完整的生态系统中，一个组织内部包含的各种节点之间可以进行无障碍的沟通。这一切也要求其内部有一个共同的标准以及新的技术体系结构来创建IT和OT的融合。
当然，我们目前面临着一个关键且普遍的问题，那就是缺乏对设备连接的理解。由于这个问题的存在，即使所有终端设备都连接上了网络之后，还有更多问题随之而来。举个例子，在设备联网之后，我们没有一个简单可用的工具来管理这些设备，通常也就没有能将数据、信息从一种语言中提取并用另一种语言表示的方法。 可以说，当下的可编程逻辑控制器（PLC）数据传输和转换成企业资源规划（ERP）系统就存在着这种隔阂。这一问题只是企业数字化转型过程中会遇到的种种问题中的一小点。
本文的目的是，让读者了解到关于连接难题的五大要点，同时提出了两大解决方案：
设备联网，本就是一个艰巨的任务
在问题初显时，许多工业物联网领域的厂商都趋向于将这些问题视若无睹。一旦制造商决定冒险尝试，这些企业就会突然意识到，原本打算连接到所有不同设备的计划，这些设备涉及了传统的、现代的终端，有封闭的和开源的软件，因此这个计划实现起来是非常困难的，更糟糕的情况是导致严重的延迟，最终打乱了最初的计划时间表。
如果你曾经为工厂里设计过系统，那么你就会了解，在这些工厂系统里连接、集成了各种各样的应用程序简直就是一场噩梦。这么做的后果是，哪怕一个简单的数据收集任务都有可能导致系统瘫痪，最终需要数周的时间来修护。
车间不断提高的复杂性
我们知道，没有一个单一的连接技术就可以将所有东西连接在一起。随着时间的推移、技术的演进，工业车间也在不断发展。车间内所应用到的技术的进步也意味着车间内部更高的复杂性。这种复杂性并不会消失，甚至会随着时间推移而增加。因此，工厂车间混合了各种设备品牌，这些终端设备有着不同的支持协议和不同的专有数据集。
因此，需要企业拥抱车间不断提高的复杂性，这也意味着企业接受在工业物联网解决方案中有很多移动部件、终端。只有将这些部件、终端连接在一起才能取得更大的收获。对企业工作人员来说，为了更好的驾驭这样的解决方案，他们需要更专业的知识。这些工作人员不应该将其视为一个复杂的补丁系统。
系统延迟问题凸显
为了更好的解决系统的复杂性，或许企业可以选择开放平台通信（open platformcommunications ，OPC）。OPC旨在为工业自动化提供标准网络协议，要求轮询接收来自设备的数据。轮询是指系统必须以预设速率向设备询问数据的位置，例如每秒一次或每半小时一次。
OPC需要多个步骤来发送数据，并不是简单地从A点到B点。典型的路径如下所示：从PLC到OPC服务器再到OPC客户端，然后，OPC客户端将其发送到本地服务器或云网络进行使用和处理。
为了进一步添加到多级过程中，PLC必须与其他任何事物或软件应用程序分开连接。连接必须从PLC 1输入事物1，PLC 1输入事物2，依此类推。然后将PLC数据传输到ERP软件中：PLC 1到ERP软件1，ERP软件2等的连接需要代码。
毫无疑问，向所有这些层添加轮询，这将导致巨大的延迟。
收集上来的数据并不总是准确的
OPC无法提供保证数据准确性的功能，需要投入额外的工作来达到目的。
以一家位于佛罗里达州的制药公司为例，此前该公司正面临着如此挑战。OPC用于轮询设备，这些设备通常在每次生产运行时接收到3000个数据包，系统无法自动验证哪个数据包是成品批次的正确匹配。为了解决该问题，该公司的工程团队编写了大量复杂的自定义代码来对数据源和接收端进行双重检查，以确保达到数据匹配的目的。
传统设备与现代设备之间的信息交换问题
消息队列遥测传输（MQTT）正迅速成为工业物联网的最好的协议选项之一，目前许多的终端设备也支持MQTT协议。采用MQTT协议的唯一方法是购买支持MQTT协议的设备，但是可想而知，并没有人愿意为了获得支持MQTT协议的设备而淘汰掉那些已经使用了20或30年且还能继续使用的传统设备。
只有当企业想添加全新设备的情况下，比如市场上最热门、最新传感器时，企业才有可能会考虑购买基于MQTT协议设计的传感器。这么一来，企业将不得投入额外的工作，使MQTT设备与其原本的传统设备能够一起工作。这对于一个拥有成千上万个设备的企业来说，其可能只有10台支持MQTT协议的设备，而将所有设备迁移到MQTT上将是一个非常缓慢的过程，并且不一定能够解决已联网设备以及全新设备联网的遗留问题。这就意味着，系统需要更多的自定义编码。
然而，企业在众多问题面前，并非无计可施。下文将提出两种解决方案：
避免自定义代码使用以数据为中心的IIoT软件将设备直接映射到应用程序（或其他设备）
这看起来很简单，但是你可能已经意识到事情并不像你期望的那样能够即插即用。
许多IIoT平台专注于分析，但由于其接入的设备无法快速收集上来数据，所以这些平台严重缺乏数据。当然，这些以分析为重点的IIoT平台仍旧是一个分析平台，只是如果数据不准确，平台交付的分析结果实际上也是无效的。
为了解决这个问题，你需要将PLC等设备直接映射到应用程序。以数据为中心的IIoT软件平台就是为此而设计的。无论通信协议如何，它都可以将传统设备和现代设备进行合并，并为所有联网设备和应用程序提供中央数据管道，使企业可以完全控制数据的使用方式、时间和位置。
本地驱动程序—超越API，OPC和MQTT
不要被应用程序接口（API）和标准协议会给你灵活性的想法而吸引住，这其实更像是为API，OPC和MQTT而做的广告。
每个IIoT平台都有针对API，OPC和MQTT的标准工具，但是它们通常没有很多本地驱动程序。一个以数据为中心的平台将有大量的本地驱动程序，这些驱动程序可以避免在企业内部工程师编写自定义代码。得益于此，企业的终端设备可以在几天内就能得到改善，而不需要花费几个月的时间。
（原标题：物联网时代，五大连接难题及两大解决方案！）
