過去,在大家的眼中,制造業(yè)往往只是與設備以及硬件有關。如今,軟件和服務已經(jīng)從制造業(yè)的成本中心,變成了利潤創(chuàng)造中心。一種名為設備即服務(Equipment-as-a-Service,EaaS)模式能夠通過諸如Apache Kafka等事件流平臺,提供的可靠且可擴展的實時數(shù)據(jù)處理服務,進而實現(xiàn)地將維護工作外包給了服務供應商。
下面,我將和您探討那些用于狀態(tài)監(jiān)測和預測性維護的物聯(lián)網(wǎng)軟件,是如何協(xié)助構建新的產(chǎn)品,并改善設備綜合效率是(Overall Equipment Effectiveness,OEE)的。
首先讓我們來看看狀態(tài)監(jiān)測和預測性維護這兩個術語。由于尚無標準定義,因此一些文獻會將狀態(tài)監(jiān)測視為預測性維護的一個主要組成部分。當然,也有將后者解釋為能夠利用機器學習的現(xiàn)代化軟件。更有甚者,會將這兩個術語視為同義。
現(xiàn)代化維護的策略和目標
現(xiàn)代化維護的策略與目標主要著眼于更加有效地、更優(yōu)化地利用資源。而這些往往是建立在基于狀態(tài)的維護策略之上的。那么,工業(yè)物聯(lián)網(wǎng)/工業(yè) 4.0到底能夠在車間層面上實現(xiàn)并帶來哪些優(yōu)勢呢?
以維護替代修理
縮減計劃外的停機時間
通過優(yōu)化,去除不必要的維護工作
減少負面的財務影響
優(yōu)化生產(chǎn)力
提高設備綜合效率(OEE)
從孤立的視角上升到整個企業(yè)的視角
與此同時,設備的操作員則會關注如下方面:
通過檢測異常和分類錯誤,來判斷設備運行正常嗎?
通過剩余使用壽命(Remaining useful life,RUL)和首次故障時間,來判斷設備還能運轉多久?
通過傳感器監(jiān)控和根本原因分析,來判斷設備運行正常嗎?
狀態(tài)監(jiān)測和預測性維護的本質
狀態(tài)監(jiān)測是指監(jiān)測設備的振動、溫度等狀態(tài)參數(shù),以識別指定檢查指標在故障中顯著變化的過程。它是預測性維護的重要組成部分。我們可以通過狀態(tài)監(jiān)測來安排維護,或采取其他行動,以防止故障產(chǎn)生危害。也就是說,狀態(tài)監(jiān)測可以在被檢測項發(fā)展成為重大故障之前,及時或預先提供相關信息。
而預測性維護技術將有助于識別在役設備的狀況,以估計何時需要實施維護。它有效地方便了運維人員對設備實施糾正性維護,進而防止了設備發(fā)生意外故障。此外,由于維護任務是按需觸發(fā)的,因此預測性維護會比常規(guī)方式更節(jié)省成本。
當然,只有保證基礎架構和軟件的可靠性、可擴展性、以及實時性的基礎上,狀態(tài)監(jiān)控和預測性維護才能很好地發(fā)揮作用。這通常源于合理的、基于總體擁有成本(TCO)和投資回報(ROI)的成本風險分析與投入。
設備即服務(EaaS)是新的商業(yè)模式
作為一種以服務為驅動的商業(yè)模式,設備即服務(EaaS)體現(xiàn)在向最終用戶出租設備,并收取使用設備的定期費用上。該模式能夠為雙方提供如下好處:
EaaS提供商(如,OEM和設備制造企業(yè))能夠按需提高產(chǎn)品在研發(fā)、以及數(shù)字孿生(Digital Twins)等方面的設計,規(guī)劃常規(guī)性的收入,以及提供預測性維護服務。
·客戶(如制造型工廠)可以在EaaS軟件的幫助下,優(yōu)化設備的利用率和自身生產(chǎn)率,減少資本支出(CAPEX)、運營開支(OPEX)、以及運營成本等各類總體成本。
可以說,只有當狀態(tài)監(jiān)控和預測性維護能夠7×24小時地、穩(wěn)定且持續(xù)地收集、處理和分析傳入的數(shù)據(jù)流時,EaaS才是一個成功的商業(yè)模式。
將Apache Kafka用于工業(yè)物聯(lián)網(wǎng)/工業(yè)4.0
作為一種事實上的事件流的??標準??,Apache Kafka往往被全球工業(yè)物聯(lián)網(wǎng)/工業(yè)4.0部署在他們的邊緣和混合云環(huán)境中。下圖展示了一個結合了公共云和邊緣事件流的智能工廠架構模型:
由5G Kafka和AWS Wavelength實現(xiàn)的、低延遲的混合邊緣云架構
在邊緣處,Kafka雖然可以從具有操作技術(operational technology,OT)的設備上收集數(shù)據(jù),但是它被普遍認為屬于軟實時(soft real-time),且并不適合嵌入式系統(tǒng)設備。具體討論請參見--《??Apache Kafka不是硬實時,但在自動化和工業(yè)物聯(lián)網(wǎng)中無處不在??》一文。
盡管如此,Kafka仍然適用于關鍵任務型低延遲的用例。例如:端到端延遲為幾毫秒的狀態(tài)監(jiān)控和預測性維護場景。下圖是一個在5G環(huán)境中,Kubernetes利用Kafka和ksqlDB的示例:
基于Outposts和Confluent的AWS Wavelength低延遲5G用例
使用事件流和流處理的動態(tài)數(shù)據(jù)
狀態(tài)監(jiān)控和預測性維護需要基于事件的架構,來收集、處理和分析動態(tài)數(shù)據(jù)。傳統(tǒng)的IIoT(Industrial Internet of Things,工業(yè)物聯(lián)網(wǎng))平臺是專有的、不靈活的,無法擴展的,且不適合跨供應商與不同標準的集成。而Kafka的原生流處理是一種開放、靈活、可擴展的技術,并可用于實現(xiàn)跨物聯(lián)網(wǎng)接口的數(shù)據(jù)集成。
針對上述矛盾,讓我們看兩個例子:一個是使用Kafka Streams進行無狀態(tài)狀態(tài)的監(jiān)控,另一個是使用ksqlDB和TensorFlow進行預測性維護。需要明確的是:這些只是示例而已,其中的集成庫可以被任何其他技術所替代。例如,用于流處理的Apache Flink、基于云端的ML(機器學習)平臺、以及用于“最后一公里”集成的專有物聯(lián)網(wǎng)邊緣平臺等。以下便是使用Kafka構建狀態(tài)監(jiān)控和預測性維護的基本設置:
來自設備PLC的傳感器事件--Scada IoT
在上圖的左側,我們可以看到由存儲和轉發(fā)事件所產(chǎn)生的Kafka日志。而在右側,各種設備會實時地捕獲傳感器上的數(shù)據(jù)。該架構可在任何規(guī)模的環(huán)境中實時運行。例如,某些Confluent客戶會利用Confluent Cloud進行每秒10GB或更多的數(shù)據(jù)處理。
設備、PLC(可編程邏輯控制器)、以及傳感器等之間的物聯(lián)網(wǎng)集成,是通過Kafka Connect或其他API實現(xiàn)的,同時可以用到MQTT、OPC-UA、REST/HTTP、文件、以及不同的開放或專有接口。如果您對此感興趣,可以參考《??用于工業(yè)物聯(lián)網(wǎng)集成的Kafka和PLC4x???》和《??Kafka即現(xiàn)代數(shù)據(jù)歷史學家??》兩篇文章。
使用Kafka Streams進行無狀態(tài)監(jiān)控
下圖顯示了如何實時地去分析在溫度峰值的Kafka原生狀態(tài)監(jiān)控:
使用Kafka Streams進行無狀態(tài)監(jiān)控
該示例是使用Kafka Streams實現(xiàn)的。這是一個基于Java的庫,可以被嵌入到任何應用程序中。業(yè)務邏輯在實時處理大數(shù)據(jù)的同時,能夠持續(xù)監(jiān)控傳感器的數(shù)據(jù)。其中,只有顯示溫度峰值超過100度的相關事件,才會被轉發(fā)到另一個Kafka主題(topic)處。而任何對此感興趣的消費者(consumers,如實時警報系統(tǒng)或批量報告)都會捕獲到。
由于應用程序是無狀態(tài)的,只能逐個處理事件,因此無狀態(tài)監(jiān)控能力,對于實現(xiàn)根據(jù)復雜的業(yè)務邏輯,過濾或轉換流式ETL(Extract-Transform-Load)來說非常實用。
使用ksqlDB進行有狀態(tài)的預測性維護
雖然無狀態(tài)流處理已經(jīng)很強大了,但有狀態(tài)流處理(stateful stream processing)能夠解決更多的業(yè)務問題。如下示例展示了Kafka原生的ksqlDB微服務,是如何實現(xiàn)有狀態(tài)的流處理,以及持續(xù)檢測異常的:
使用Kafka和ksqlDB進行有狀態(tài)預測性維護
如上圖所示,一個一小時的滑動窗口會不斷匯總來自各個傳感器的溫度峰值。消費者會實時使用這些數(shù)據(jù),去主動根據(jù)預定義的閾值采取行動。例如,數(shù)據(jù)科學團隊可以通過分析歷史數(shù)據(jù),來確定平均超過100度的十多個溫度峰值,是如何顯著增加斷電風險的,并據(jù)此實時地提醒設備操作員,按需進行維護。
使用Kafka和TensorFlow采取實時的機器學習
上述簡單的業(yè)務邏輯,可以被用來改進OEE和維護流程。如果我們嵌入機器學習,則能夠使狀態(tài)監(jiān)測和預測性維護達到更好的效果。通常,在不需要改變架構的情況下,分析模型可以像任何其他業(yè)務邏輯一樣,被嵌入到Kafka的應用中。您可以通過查看如下鏈接,了解更多相關內容:
??Kafka簡介和用于模型訓練與部署的機器學習??
??使用Kafka進行模型服務與評分的架構和權衡??
??使用Kafka原生模型部署的流式機器學習??
??使用Kafka、Streams、ksqlDB、TensorFlow、DL4J、H2O等代碼示例??
下圖是一個帶有ksqlDB和嵌入式TensorFlow模型的示例:
使用Kafka的KSQL和TensorFlow進行實時機器學習
如上圖所示,一個ksqlDB類型的用戶定義函數(shù)(user-defined function,UDF)被嵌入到了該模型中。該模型使用無監(jiān)督式的自動化編碼器,在Kafka應用程序中實時地進行異常檢測。
這種架構智能地解決了數(shù)據(jù)科學團隊和生產(chǎn)團隊之間的錯配問題。數(shù)據(jù)科學家可以使用Python和Jupyther notebook進行快速原型設計和模型開發(fā);而生產(chǎn)團隊則會在集群中部署ksqlDB的查詢,以實現(xiàn)大規(guī)模的實時評分。您可以通過如下優(yōu)秀的Github項目進行深入學習。該項目使用??Kappa架構???,實現(xiàn)了關注點的分離,可被用于互聯(lián)汽車的基礎架構,并使用MQTT和Kafka進行??預測性維護??:
帶有Apache Kafka的MQTT Kubernetes和用于流式機器學習的Tensorflow Kappa架構
使用完全托管的Kafka式設備即服務
如下圖所示,根據(jù)麥肯錫最近發(fā)布的一份??行業(yè)趨勢報告??,制造型企業(yè)往往希望提供機械和設備即服務,并獲得豐厚的利潤:
麥肯錫關于設備即服務的報告
過去,在獨自運維設備時,企業(yè)往往面臨著“過晚的維護會導致無法修復,而過早的維護會拉高成本”的兩難局面。如今,EaaS為客戶擔負了設備的運營與維修。設備供應商只需設定好一個最佳維護服務的提供方式,便可提供更好的客戶體驗。
目前,許多制造企業(yè)都會將Kafka和事件流,運行到他們的設備上,或連接到云服務中。許多現(xiàn)代化的IIoT服務也會利用完全托管、且真正無服務器的Kafka解決方案(如,Confluent Cloud),讓他們能夠真正關注業(yè)務問題,而不必去操作事件流的基礎架構。以下是一些與完全托管式Kafka相關的文章,其中不乏用于使用數(shù)字孿生來構建設備即服務的產(chǎn)品:
??Kafka數(shù)字孿生用例??
??帶有Kafka的數(shù)字孿生和數(shù)字線程式物聯(lián)網(wǎng)架構??
??專注業(yè)務邏輯并使用托管事件流的無服務器Kafka??
??Apache Kafka的各種產(chǎn)品、供應商和云服務的比較??
小結
上文展示了Kafka生態(tài)系統(tǒng)的事件流,如何為制造型企業(yè)提供新的設備即服務模式。其中,無狀態(tài)和有狀態(tài)的流式分析,能夠實時地為大規(guī)模數(shù)據(jù)做出主動和預測性的決策。這種架構可以被用在一到多個云服務區(qū)域、數(shù)據(jù)中心的內部部署、以及外部邊緣與混合架構的任意組合中??梢哉f,該方式將成為下一代物聯(lián)網(wǎng)平臺和設備服務事件流的主要處理方式。
譯者介紹
陳 峻 (Julian Chen),51CTO社區(qū)編輯,具有十多年的IT項目實施經(jīng)驗,善于對內外部資源與風險實施管控,專注傳播網(wǎng)絡與信息安全知識與經(jīng)驗;持續(xù)以博文、專題和譯文等形式,分享前沿技術與新知;經(jīng)常以線上、線下等方式,開展信息安全類培訓與授課。
原文標題:Kafka for Condition Monitoring and Predictive Maintenance in Industrial IoT,作者: Kai Wähner