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的標準工具，但是它們通常沒有很多本地驅動程序。一個以數據為中心的平臺將有大量的本地驅動程序，這些驅動程序可以避免在企業內部工程師編寫自定義代碼。得益于此，企業的終端設備可以在幾天內就能得到改善，而不需要花費幾個月的時間。