萬物互聯(lián)時代，制造業(yè)對數(shù)字技術(shù)的應用早已是一個不可逆轉(zhuǎn)的趨勢。雖然這種轉(zhuǎn)變是一個循序漸進的過程，但就目前來看，加快轉(zhuǎn)變的速度早已給企業(yè)帶來了巨大的壓力。此前，惠普企業(yè)聯(lián)合世界物聯(lián)網(wǎng)協(xié)會(the Industry of Things World Conference)進行了一項深入的調(diào)查。通過本次調(diào)查，旨在了解過去12個月中，眾多企業(yè)推出的工業(yè)物聯(lián)網(wǎng)項目取得了多大的進展。調(diào)查發(fā)現(xiàn)，只有53%的受訪者認為他們的工業(yè)物聯(lián)網(wǎng)項目達到或者超過了預期的目標;其余的47%表示他們的目標還沒有達成。
眾所周知，一家企業(yè)并不是通過購買技術(shù)就能輕松進軍工業(yè)物聯(lián)網(wǎng)領(lǐng)域或者輕易完成數(shù)字化轉(zhuǎn)型的。工業(yè)物聯(lián)網(wǎng)需要一個完整的架構(gòu)，在這個完整的生態(tài)系統(tǒng)中，一個組織內(nèi)部包含的各種節(jié)點之間可以進行無障礙的溝通。這一切也要求其內(nèi)部有一個共同的標準以及新的技術(shù)體系結(jié)構(gòu)來創(chuàng)建IT和OT的融合。
當然，我們目前面臨著一個關(guān)鍵且普遍的問題，那就是缺乏對設(shè)備連接的理解。由于這個問題的存在，即使所有終端設(shè)備都連接上了網(wǎng)絡(luò)之后，還有更多問題隨之而來。舉個例子，在設(shè)備聯(lián)網(wǎng)之后，我們沒有一個簡單可用的工具來管理這些設(shè)備，通常也就沒有能將數(shù)據(jù)、信息從一種語言中提取并用另一種語言表示的方法。可以說，當下的可編程邏輯控制器(PLC)數(shù)據(jù)傳輸和轉(zhuǎn)換成企業(yè)資源規(guī)劃(ERP)系統(tǒng)就存在著這種隔閡。這一問題只是企業(yè)數(shù)字化轉(zhuǎn)型過程中會遇到的種種問題中的一小點。
本文的目的是，讓讀者了解到關(guān)于連接難題的五大要點，同時提出了兩大解決方案：
設(shè)備聯(lián)網(wǎng)，本就是一個艱巨的任務(wù)
在問題初顯時，許多工業(yè)物聯(lián)網(wǎng)領(lǐng)域的廠商都趨向于將這些問題視若無睹。一旦制造商決定冒險嘗試，這些企業(yè)就會突然意識到，原本打算連接到所有不同設(shè)備的計劃，這些設(shè)備涉及了傳統(tǒng)的、現(xiàn)代的終端，有封閉的和開源的軟件，因此這個計劃實現(xiàn)起來是非常困難的，更糟糕的情況是導致嚴重的延遲，最終打亂了最初的計劃時間表。
如果你曾經(jīng)為工廠里設(shè)計過系統(tǒng)，那么你就會了解，在這些工廠系統(tǒng)里連接、集成了各種各樣的應用程序簡直就是一場噩夢。這么做的后果是，哪怕一個簡單的數(shù)據(jù)收集任務(wù)都有可能導致系統(tǒng)癱瘓，最終需要數(shù)周的時間來修護。
車間不斷提高的復雜性
我們知道，沒有一個單一的連接技術(shù)就可以將所有東西連接在一起。隨著時間的推移、技術(shù)的演進，工業(yè)車間也在不斷發(fā)展。車間內(nèi)所應用到的技術(shù)的進步也意味著車間內(nèi)部更高的復雜性。這種復雜性并不會消失，甚至會隨著時間推移而增加。因此，工廠車間混合了各種設(shè)備品牌，這些終端設(shè)備有著不同的支持協(xié)議和不同的專有數(shù)據(jù)集。
因此，需要企業(yè)擁抱車間不斷提高的復雜性，這也意味著企業(yè)接受在工業(yè)物聯(lián)網(wǎng)解決方案中有很多移動部件、終端。只有將這些部件、終端連接在一起才能取得更大的收獲。對企業(yè)工作人員來說，為了更好的駕馭這樣的解決方案，他們需要更專業(yè)的知識。這些工作人員不應該將其視為一個復雜的補丁系統(tǒng)。
系統(tǒng)延遲問題凸顯
為了更好的解決系統(tǒng)的復雜性，或許企業(yè)可以選擇開放平臺通信(open platformcommunications ，OPC)。OPC旨在為工業(yè)自動化提供標準網(wǎng)絡(luò)協(xié)議，要求輪詢接收來自設(shè)備的數(shù)據(jù)。輪詢是指系統(tǒng)必須以預設(shè)速率向設(shè)備詢問數(shù)據(jù)的位置，例如每秒一次或每半小時一次。
OPC需要多個步驟來發(fā)送數(shù)據(jù)，并不是簡單地從A點到B點。典型的路徑如下所示：從PLC到OPC服務(wù)器再到OPC客戶端，然后，OPC客戶端將其發(fā)送到本地服務(wù)器或云網(wǎng)絡(luò)進行使用和處理。
為了進一步添加到多級過程中，PLC必須與其他任何事物或軟件應用程序分開連接。連接必須從PLC 1輸入事物1，PLC 1輸入事物2，依此類推。然后將PLC數(shù)據(jù)傳輸?shù)紼RP軟件中：PLC 1到ERP軟件1，ERP軟件2等的連接需要代碼。
毫無疑問，向所有這些層添加輪詢，這將導致巨大的延遲。
收集上來的數(shù)據(jù)并不總是準確的
OPC無法提供保證數(shù)據(jù)準確性的功能，需要投入額外的工作來達到目的。
以一家位于佛羅里達州的制藥公司為例，此前該公司正面臨著如此挑戰(zhàn)。OPC用于輪詢設(shè)備，這些設(shè)備通常在每次生產(chǎn)運行時接收到3000個數(shù)據(jù)包，系統(tǒng)無法自動驗證哪個數(shù)據(jù)包是成品批次的正確匹配。為了解決該問題，該公司的工程團隊編寫了大量復雜的自定義代碼來對數(shù)據(jù)源和接收端進行雙重檢查，以確保達到數(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è)備。
只有當企業(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è)備直接映射到應用程序(或其他設(shè)備)
這看起來很簡單，但是你可能已經(jīng)意識到事情并不像你期望的那樣能夠即插即用。
許多IIoT平臺專注于分析，但由于其接入的設(shè)備無法快速收集上來數(shù)據(jù)，所以這些平臺嚴重缺乏數(shù)據(jù)。當然，這些以分析為重點的IIoT平臺仍舊是一個分析平臺，只是如果數(shù)據(jù)不準確，平臺交付的分析結(jié)果實際上也是無效的。
為了解決這個問題，你需要將PLC等設(shè)備直接映射到應用程序。以數(shù)據(jù)為中心的IIoT軟件平臺就是為此而設(shè)計的。無論通信協(xié)議如何，它都可以將傳統(tǒng)設(shè)備和現(xiàn)代設(shè)備進行合并，并為所有聯(lián)網(wǎng)設(shè)備和應用程序提供中央數(shù)據(jù)管道，使企業(yè)可以完全控制數(shù)據(jù)的使用方式、時間和位置。
本地驅(qū)動程序—超越API，OPC和MQTT
不要被應用程序接口(API)和標準協(xié)議會給你靈活性的想法而吸引住，這其實更像是為API，OPC和MQTT而做的廣告。
每個IIoT平臺都有針對API，OPC和MQTT的標準工具，但是它們通常沒有很多本地驅(qū)動程序。一個以數(shù)據(jù)為中心的平臺將有大量的本地驅(qū)動程序，這些驅(qū)動程序可以避免在企業(yè)內(nèi)部工程師編寫自定義代碼。得益于此，企業(yè)的終端設(shè)備可以在幾天內(nèi)就能得到改善，而不需要花費幾個月的時間。
轉(zhuǎn)型的最終目的 -提質(zhì)降本增效
分享到微信 ×
打開微信，點擊底部的“發(fā)現(xiàn)”，
使用“掃一掃”即可將網(wǎng)頁分享至朋友圈。