OPC無法提供保證數(shù)據(jù)準(zhǔn)確性的功能，需要投入額外的工作來達(dá)到目的。
以一家位于佛羅里達(dá)州的制藥公司為例，此前該公司正面臨著如此挑戰(zhàn)。OPC用于輪詢設(shè)備，這些設(shè)備通常在每次生產(chǎn)運(yùn)行時接收到3000個數(shù)據(jù)包，系統(tǒng)無法自動驗(yàn)證哪個數(shù)據(jù)包是成品批次的正確匹配。為了解決該問題，該公司的工程團(tuán)隊編寫了大量復(fù)雜的自定義代碼來對數(shù)據(jù)源和接收端進(jìn)行雙重檢查，以確保達(dá)到數(shù)據(jù)匹配的目的。
傳統(tǒng)設(shè)備與現(xiàn)代設(shè)備之間的信息交換問題
消息隊列遙測傳輸(MQTT)正迅速成為工業(yè)物聯(lián)網(wǎng)的最好的協(xié)議選項之一，目前許多的終端設(shè)備也支持MQTT協(xié)議。采用MQTT協(xié)議的唯一方法是購買支持MQTT協(xié)議的設(shè)備，但是可想而知，并沒有人愿意為了獲得支持MQTT協(xié)議的設(shè)備而淘汰掉那些已經(jīng)使用了20或30年且還能繼續(xù)使用的傳統(tǒng)設(shè)備。
只有當(dāng)企業(yè)想添加全新設(shè)備的情況下，比如市場上最熱門、最新傳感器時，企業(yè)才有可能會考慮購買基于MQTT協(xié)議設(shè)計的傳感器。這么一來，企業(yè)將不得投入額外的工作，使MQTT設(shè)備與其原本的傳統(tǒng)設(shè)備能夠一起工作。這對于一個擁有成千上萬個設(shè)備的企業(yè)來說，其可能只有10臺支持MQTT協(xié)議的設(shè)備，而將所有設(shè)備遷移到MQTT上將是一個非常緩慢的過程，并且不一定能夠解決已聯(lián)網(wǎng)設(shè)備以及全新設(shè)備聯(lián)網(wǎng)的遺留問題。這就意味著，系統(tǒng)需要更多的自定義編碼。
然而，企業(yè)在眾多問題面前，并非無計可施。下文將提出兩種解決方案：
避免自定義代碼使用以數(shù)據(jù)為中心的IIoT軟件將設(shè)備直接映射到應(yīng)用程序(或其他設(shè)備)
這看起來很簡單，但是你可能已經(jīng)意識到事情并不像你期望的那樣能夠即插即用。
許多IIoT平臺專注于分析，但由于其接入的設(shè)備無法快速收集上來數(shù)據(jù)，所以這些平臺嚴(yán)重缺乏數(shù)據(jù)。當(dāng)然，這些以分析為重點(diǎn)的IIoT平臺仍舊是一個分析平臺，只是如果數(shù)據(jù)不準(zhǔn)確，平臺交付的分析結(jié)果實(shí)際上也是無效的。
為了解決這個問題，你需要將PLC等設(shè)備直接映射到應(yīng)用程序。以數(shù)據(jù)為中心的IIoT軟件平臺就是為此而設(shè)計的。無論通信協(xié)議如何，它都可以將傳統(tǒng)設(shè)備和現(xiàn)代設(shè)備進(jìn)行合并，并為所有聯(lián)網(wǎng)設(shè)備和應(yīng)用程序提供中央數(shù)據(jù)管道，使企業(yè)可以完全控制數(shù)據(jù)的使用方式、時間和位置。
本地驅(qū)動程序—超越API，OPC和MQTT
不要被應(yīng)用程序接口(API)和標(biāo)準(zhǔn)協(xié)議會給你靈活性的想法而吸引住，這其實(shí)更像是為API，OPC和MQTT而做的廣告。
每個IIoT平臺都有針對API，OPC和MQTT的標(biāo)準(zhǔn)工具，但是它們通常沒有很多本地驅(qū)動程序。一個以數(shù)據(jù)為中心的平臺將有大量的本地驅(qū)動程序，這些驅(qū)動程序可以避免在企業(yè)內(nèi)部工程師編寫自定義代碼。得益于此，企業(yè)的終端設(shè)備可以在幾天內(nèi)就能得到改善，而不需要花費(fèi)幾個月的時間。