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的标准工具，但是它们通常没有很多本地驱动程序。一个以数据为中心的平台将有大量的本地驱动程序，这些驱动程序可以避免在企业内部工程师编写自定义代码。得益于此，企业的终端设备可以在几天内就能得到改善，而不需要花费几个月的时间。