1、设备联网，本就是一个艰巨的任务
在问题初显时，许多工业物联网领域的厂商都趋向于将这些问题视若无睹。一旦制造商决定冒险尝试，这些企业就会突然意识到，原本打算连接到所有不同设备的计划，这些设备涉及了传统的、现代的终端，有封闭的和开源的软件，因此这个计划实现起来是非常困难的，更糟糕的情况是导致严重的延迟，最终打乱了最初的计划时间表。
如果你曾经为工厂里设计过系统，那么你就会了解，在这些工厂系统里连接、集成了各种各样的应用程序简直就是一场噩梦。这么做的后果是，哪怕一个简单的数据收集任务都有可能导致系统瘫痪，最终需要数周的时间来修护。
2、车间不断提高的复杂性
我们知道，没有一个单一的连接技术就可以将所有东西连接在一起。随着时间的推移、技术的演进，工业车间也在不断发展。车间内所应用到的技术的进步也意味着车间内部更高的复杂性。这种复杂性并不会消失，甚至会随着时间推移而增加。因此，工厂车间混合了各种设备品牌，这些终端设备有着不同的支持协议和不同的专有数据集。
因此，需要企业拥抱车间不断提高的复杂性，这也意味着企业接受在工业物联网解决方案中有很多移动部件、终端。只有将这些部件、终端连接在一起才能取得更大的收获。对企业工作人员来说，为了更好的驾驭这样的解决方案，他们需要更专业的知识。这些工作人员不应该将其视为一个复杂的补丁系统。
3、系统延迟问题凸显
为了更好的解决系统的复杂性，或许企业可以选择开放平台通信。OPC旨在为工业自动化提供标准网络协议，要求轮询接收来自设备的数据。轮询是指系统必须以预设速率向设备询问数据的位置，例如每秒一次或每半小时一次。
OPC需要多个步骤来发送数据，并不是简单地从A点到B点。典型的路径如下所示：从PLC到OPC服务器再到OPC客户端，然后，OPC客户端将其发送到本地服务器或云网络进行使用和处理。
为了进一步添加到多级过程中，PLC必须与其他任何事物或软件应用程序分开连接。连接必须从PLC 1输入事物1，PLC 1输入事物2，依此类推。然后将PLC数据传输到ERP软件中：PLC 1到ERP软件1，ERP软件2等的连接需要代码。
4、传统设备与现代设备之间的信息交换问题
消息队列遥测传输正迅速成为工业物联网的最好的协议选项之一，目前许多的终端设备也支持MQTT协议。采用MQTT协议的唯一方法是购买支持MQTT协议的设备，但是可想而知，并没有人愿意为了获得支持MQTT协议的设备而淘汰掉那些已经使用了20或30年且还能继续使用的传统设备。
只有当企业想添加全新设备的情况下，比如市场上最热门、最新传感器时，企业才有可能会考虑购买基于MQTT协议设计的传感器。这么一来，企业将不得投入额外的工作，使MQTT设备与其原本的传统设备能够一起工作。这对于一个拥有成千上万个设备的企业来说，其可能只有10台支持MQTT协议的设备，而将所有设备迁移到MQTT上将是一个非常缓慢的过程，并且不一定能够解决已联网设备以及全新设备联网的遗留问题。这就意味着，系统需要更多的自定义编码。
然而，企业在众多问题面前，并非无计可施。下文将提出两种解决方案：
1、避免自定义代码使用以数据为中心的IIoT软件将设备直接映射到应用程序(或其他设备)
这看起来很简单，但是你可能已经意识到事情并不像你期望的那样能够即插即用。许多IIoT平台专注于分析，但由于其接入的设备无法快速收集上来数据，所以这些平台严重缺乏数据。当然，这些以分析为重点的IIoT平台仍旧是一个分析平台，只是如果数据不准确，平台交付的分析结果实际上也是无效的。
为了解决这个问题，你需要将PLC等设备直接映射到应用程序。以数据为中心的IIoT软件平台就是为此而设计的。无论通信协议如何，它都可以将传统设备和现代设备进行合并，并为所有联网设备和应用程序提供中央数据管道，使企业可以完全控制数据的使用方式、时间和位置。
2、本地驱动程序—超越API，OPC和MQTT
不要被应用程序接口(API)和标准协议会给你灵活性的想法而吸引住，这其实更像是为API，OPC和MQTT而做的广告。
每个IIoT平台都有针对API，OPC和MQTT的标准工具，但是它们通常没有很多本地驱动程序。一个以数据为中心的平台将有大量的本地驱动程序，这些驱动程序可以避免在企业内部工程师编写自定义代码。得益于此，企业的终端设备可以在几天内就能得到改善，而不需要花费几个月的时间。
