萬物互聯時代，制造業對數字技術的應用早已是一個不可逆轉的趨勢。雖然這種轉變是一個循序漸進的過程，但就目前來看，加快轉變的速度早已給企業帶來了巨大的壓力。此前，惠普企業聯合世界物聯網協會（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的标準工具，但是它們通常沒有很多本地驅動程式。一個以資料為中心的平台将有大量的本地驅動程式，這些驅動程式可以避免在企業内部工程師編寫自定義代碼。得益于此，企業的終端裝置可以在幾天内就能得到改善，而不需要花費幾個月的時間。
原文出處：物聯網智庫
<a href="http://mp.weixin.qq.com/s/QMiKu8C-agY2slUfCPWOLQ" target="_blank">原文連結</a>
轉載請與作者聯系，同時請務必标明文章原始出處和原文連結及本聲明。