過去，在大家的眼中，制造業(yè)往往只是與設(shè)備以及硬件有關(guān)。如今，軟件和服務(wù)已經(jīng)從制造業(yè)的成本中心，變成了利潤創(chuàng)造中心。一種名為設(shè)備即服務(wù)(Equipment-as-a-Service，EaaS)模式能夠通過諸如Apache Kafka等事件流平臺，提供的可靠且可擴展的實時數(shù)據(jù)處理服務(wù)，進(jìn)而實現(xiàn)地將維護工作外包給了服務(wù)供應(yīng)商。

下面，我將和您探討那些用于狀態(tài)監(jiān)測和預(yù)測性維護的物聯(lián)網(wǎng)軟件，是如何協(xié)助構(gòu)建新的產(chǎn)品，并改善設(shè)備綜合效率是(Overall Equipment Effectiveness，OEE)的。

首先讓我們來看看狀態(tài)監(jiān)測和預(yù)測性維護這兩個術(shù)語。由于尚無標(biāo)準(zhǔn)定義，因此一些文獻(xiàn)會將狀態(tài)監(jiān)測視為預(yù)測性維護的一個主要組成部分。當(dāng)然，也有將后者解釋為能夠利用機器學(xué)習(xí)的現(xiàn)代化軟件。更有甚者，會將這兩個術(shù)語視為同義。

現(xiàn)代化維護的策略和目標(biāo)

現(xiàn)代化維護的策略與目標(biāo)主要著眼于更加有效地、更優(yōu)化地利用資源。而這些往往是建立在基于狀態(tài)的維護策略之上的。那么，工業(yè)物聯(lián)網(wǎng)/工業(yè) 4.0到底能夠在車間層面上實現(xiàn)并帶來哪些優(yōu)勢呢?

以維護替代修理

縮減計劃外的停機時間

通過優(yōu)化，去除不必要的維護工作

減少負(fù)面的財務(wù)影響

優(yōu)化生產(chǎn)力

提高設(shè)備綜合效率(OEE)

從孤立的視角上升到整個企業(yè)的視角

與此同時，設(shè)備的操作員則會關(guān)注如下方面：

通過檢測異常和分類錯誤，來判斷設(shè)備運行正常嗎?

通過剩余使用壽命(Remaining useful life，RUL)和首次故障時間，來判斷設(shè)備還能運轉(zhuǎn)多久?

通過傳感器監(jiān)控和根本原因分析，來判斷設(shè)備運行正常嗎?

狀態(tài)監(jiān)測和預(yù)測性維護的本質(zhì)

狀態(tài)監(jiān)測是指監(jiān)測設(shè)備的振動、溫度等狀態(tài)參數(shù)，以識別指定檢查指標(biāo)在故障中顯著變化的過程。它是預(yù)測性維護的重要組成部分。我們可以通過狀態(tài)監(jiān)測來安排維護，或采取其他行動，以防止故障產(chǎn)生危害。也就是說，狀態(tài)監(jiān)測可以在被檢測項發(fā)展成為重大故障之前，及時或預(yù)先提供相關(guān)信息。

而預(yù)測性維護技術(shù)將有助于識別在役設(shè)備的狀況，以估計何時需要實施維護。它有效地方便了運維人員對設(shè)備實施糾正性維護，進(jìn)而防止了設(shè)備發(fā)生意外故障。此外，由于維護任務(wù)是按需觸發(fā)的，因此預(yù)測性維護會比常規(guī)方式更節(jié)省成本。

當(dāng)然，只有保證基礎(chǔ)架構(gòu)和軟件的可靠性、可擴展性、以及實時性的基礎(chǔ)上，狀態(tài)監(jiān)控和預(yù)測性維護才能很好地發(fā)揮作用。這通常源于合理的、基于總體擁有成本(TCO)和投資回報(ROI)的成本風(fēng)險分析與投入。

設(shè)備即服務(wù)(EaaS)是新的商業(yè)模式

作為一種以服務(wù)為驅(qū)動的商業(yè)模式，設(shè)備即服務(wù)(EaaS)體現(xiàn)在向最終用戶出租設(shè)備，并收取使用設(shè)備的定期費用上。該模式能夠為雙方提供如下好處：

EaaS提供商(如，OEM和設(shè)備制造企業(yè))能夠按需提高產(chǎn)品在研發(fā)、以及數(shù)字孿生(Digital Twins)等方面的設(shè)計，規(guī)劃常規(guī)性的收入，以及提供預(yù)測性維護服務(wù)。

·客戶(如制造型工廠)可以在EaaS軟件的幫助下，優(yōu)化設(shè)備的利用率和自身生產(chǎn)率，減少資本支出(CAPEX)、運營開支(OPEX)、以及運營成本等各類總體成本。

可以說，只有當(dāng)狀態(tài)監(jiān)控和預(yù)測性維護能夠7×24小時地、穩(wěn)定且持續(xù)地收集、處理和分析傳入的數(shù)據(jù)流時，EaaS才是一個成功的商業(yè)模式。

將Apache Kafka用于工業(yè)物聯(lián)網(wǎng)/工業(yè)4.0

作為一種事實上的事件流的??標(biāo)準(zhǔn)??，Apache Kafka往往被全球工業(yè)物聯(lián)網(wǎng)/工業(yè)4.0部署在他們的邊緣和混合云環(huán)境中。下圖展示了一個結(jié)合了公共云和邊緣事件流的智能工廠架構(gòu)模型：

由5G Kafka和AWS Wavelength實現(xiàn)的、低延遲的混合邊緣云架構(gòu)

在邊緣處，Kafka雖然可以從具有操作技術(shù)(operational technology，OT)的設(shè)備上收集數(shù)據(jù)，但是它被普遍認(rèn)為屬于軟實時(soft real-time)，且并不適合嵌入式系統(tǒng)設(shè)備。具體討論請參見--《??Apache Kafka不是硬實時，但在自動化和工業(yè)物聯(lián)網(wǎng)中無處不在??》一文。

盡管如此，Kafka仍然適用于關(guān)鍵任務(wù)型低延遲的用例。例如：端到端延遲為幾毫秒的狀態(tài)監(jiān)控和預(yù)測性維護場景。下圖是一個在5G環(huán)境中，Kubernetes利用Kafka和ksqlDB的示例：

基于Outposts和Confluent的AWS Wavelength低延遲5G用例

使用事件流和流處理的動態(tài)數(shù)據(jù)

狀態(tài)監(jiān)控和預(yù)測性維護需要基于事件的架構(gòu)，來收集、處理和分析動態(tài)數(shù)據(jù)。傳統(tǒng)的IIoT(Industrial Internet of Things，工業(yè)物聯(lián)網(wǎng))平臺是專有的、不靈活的，無法擴展的，且不適合跨供應(yīng)商與不同標(biāo)準(zhǔn)的集成。而Kafka的原生流處理是一種開放、靈活、可擴展的技術(shù)，并可用于實現(xiàn)跨物聯(lián)網(wǎng)接口的數(shù)據(jù)集成。

針對上述矛盾，讓我們看兩個例子：一個是使用Kafka Streams進(jìn)行無狀態(tài)狀態(tài)的監(jiān)控，另一個是使用ksqlDB和TensorFlow進(jìn)行預(yù)測性維護。需要明確的是：這些只是示例而已，其中的集成庫可以被任何其他技術(shù)所替代。例如，用于流處理的Apache Flink、基于云端的ML(機器學(xué)習(xí))平臺、以及用于“最后一公里”集成的專有物聯(lián)網(wǎng)邊緣平臺等。以下便是使用Kafka構(gòu)建狀態(tài)監(jiān)控和預(yù)測性維護的基本設(shè)置：

來自設(shè)備PLC的傳感器事件--Scada IoT

在上圖的左側(cè)，我們可以看到由存儲和轉(zhuǎn)發(fā)事件所產(chǎn)生的Kafka日志。而在右側(cè)，各種設(shè)備會實時地捕獲傳感器上的數(shù)據(jù)。該架構(gòu)可在任何規(guī)模的環(huán)境中實時運行。例如，某些Confluent客戶會利用Confluent Cloud進(jìn)行每秒10GB或更多的數(shù)據(jù)處理。

設(shè)備、PLC(可編程邏輯控制器)、以及傳感器等之間的物聯(lián)網(wǎng)集成，是通過Kafka Connect或其他API實現(xiàn)的，同時可以用到MQTT、OPC-UA、REST/HTTP、文件、以及不同的開放或?qū)Ｓ薪涌?。如果您對此感興趣，可以參考《??用于工業(yè)物聯(lián)網(wǎng)集成的Kafka和PLC4x???》和《??Kafka即現(xiàn)代數(shù)據(jù)歷史學(xué)家??》兩篇文章。

使用Kafka Streams進(jìn)行無狀態(tài)監(jiān)控

下圖顯示了如何實時地去分析在溫度峰值的Kafka原生狀態(tài)監(jiān)控：

使用Kafka Streams進(jìn)行無狀態(tài)監(jiān)控

該示例是使用Kafka Streams實現(xiàn)的。這是一個基于Java的庫，可以被嵌入到任何應(yīng)用程序中。業(yè)務(wù)邏輯在實時處理大數(shù)據(jù)的同時，能夠持續(xù)監(jiān)控傳感器的數(shù)據(jù)。其中，只有顯示溫度峰值超過100度的相關(guān)事件，才會被轉(zhuǎn)發(fā)到另一個Kafka主題(topic)處。而任何對此感興趣的消費者(consumers，如實時警報系統(tǒng)或批量報告)都會捕獲到。

由于應(yīng)用程序是無狀態(tài)的，只能逐個處理事件，因此無狀態(tài)監(jiān)控能力，對于實現(xiàn)根據(jù)復(fù)雜的業(yè)務(wù)邏輯，過濾或轉(zhuǎn)換流式ETL(Extract-Transform-Load)來說非常實用。

使用ksqlDB進(jìn)行有狀態(tài)的預(yù)測性維護

雖然無狀態(tài)流處理已經(jīng)很強大了，但有狀態(tài)流處理(stateful stream processing)能夠解決更多的業(yè)務(wù)問題。如下示例展示了Kafka原生的ksqlDB微服務(wù)，是如何實現(xiàn)有狀態(tài)的流處理，以及持續(xù)檢測異常的：

使用Kafka和ksqlDB進(jìn)行有狀態(tài)預(yù)測性維護

如上圖所示，一個一小時的滑動窗口會不斷匯總來自各個傳感器的溫度峰值。消費者會實時使用這些數(shù)據(jù)，去主動根據(jù)預(yù)定義的閾值采取行動。例如，數(shù)據(jù)科學(xué)團隊可以通過分析歷史數(shù)據(jù)，來確定平均超過100度的十多個溫度峰值，是如何顯著增加斷電風(fēng)險的，并據(jù)此實時地提醒設(shè)備操作員，按需進(jìn)行維護。

使用Kafka和TensorFlow采取實時的機器學(xué)習(xí)

上述簡單的業(yè)務(wù)邏輯，可以被用來改進(jìn)OEE和維護流程。如果我們嵌入機器學(xué)習(xí)，則能夠使?fàn)顟B(tài)監(jiān)測和預(yù)測性維護達(dá)到更好的效果。通常，在不需要改變架構(gòu)的情況下，分析模型可以像任何其他業(yè)務(wù)邏輯一樣，被嵌入到Kafka的應(yīng)用中。您可以通過查看如下鏈接，了解更多相關(guān)內(nèi)容：

??Kafka簡介和用于模型訓(xùn)練與部署的機器學(xué)習(xí)??

??使用Kafka進(jìn)行模型服務(wù)與評分的架構(gòu)和權(quán)衡??

??使用Kafka原生模型部署的流式機器學(xué)習(xí)??

??使用Kafka、Streams、ksqlDB、TensorFlow、DL4J、H2O等代碼示例??

下圖是一個帶有ksqlDB和嵌入式TensorFlow模型的示例：

使用Kafka的KSQL和TensorFlow進(jìn)行實時機器學(xué)習(xí)

如上圖所示，一個ksqlDB類型的用戶定義函數(shù)(user-defined function，UDF)被嵌入到了該模型中。該模型使用無監(jiān)督式的自動化編碼器，在Kafka應(yīng)用程序中實時地進(jìn)行異常檢測。

這種架構(gòu)智能地解決了數(shù)據(jù)科學(xué)團隊和生產(chǎn)團隊之間的錯配問題。數(shù)據(jù)科學(xué)家可以使用Python和Jupyther notebook進(jìn)行快速原型設(shè)計和模型開發(fā);而生產(chǎn)團隊則會在集群中部署ksqlDB的查詢，以實現(xiàn)大規(guī)模的實時評分。您可以通過如下優(yōu)秀的Github項目進(jìn)行深入學(xué)習(xí)。該項目使用??Kappa架構(gòu)???，實現(xiàn)了關(guān)注點的分離，可被用于互聯(lián)汽車的基礎(chǔ)架構(gòu)，并使用MQTT和Kafka進(jìn)行??預(yù)測性維護??：

帶有Apache Kafka的MQTT Kubernetes和用于流式機器學(xué)習(xí)的Tensorflow Kappa架構(gòu)

使用完全托管的Kafka式設(shè)備即服務(wù)

如下圖所示，根據(jù)麥肯錫最近發(fā)布的一份??行業(yè)趨勢報告??，制造型企業(yè)往往希望提供機械和設(shè)備即服務(wù)，并獲得豐厚的利潤：

麥肯錫關(guān)于設(shè)備即服務(wù)的報告

過去，在獨自運維設(shè)備時，企業(yè)往往面臨著“過晚的維護會導(dǎo)致無法修復(fù)，而過早的維護會拉高成本”的兩難局面。如今，EaaS為客戶擔(dān)負(fù)了設(shè)備的運營與維修。設(shè)備供應(yīng)商只需設(shè)定好一個最佳維護服務(wù)的提供方式，便可提供更好的客戶體驗。

目前，許多制造企業(yè)都會將Kafka和事件流，運行到他們的設(shè)備上，或連接到云服務(wù)中。許多現(xiàn)代化的IIoT服務(wù)也會利用完全托管、且真正無服務(wù)器的Kafka解決方案(如，Confluent Cloud)，讓他們能夠真正關(guān)注業(yè)務(wù)問題，而不必去操作事件流的基礎(chǔ)架構(gòu)。以下是一些與完全托管式Kafka相關(guān)的文章，其中不乏用于使用數(shù)字孿生來構(gòu)建設(shè)備即服務(wù)的產(chǎn)品：

??Kafka數(shù)字孿生用例??

??帶有Kafka的數(shù)字孿生和數(shù)字線程式物聯(lián)網(wǎng)架構(gòu)??

??專注業(yè)務(wù)邏輯并使用托管事件流的無服務(wù)器Kafka??

??Apache Kafka的各種產(chǎn)品、供應(yīng)商和云服務(wù)的比較??

小結(jié)

上文展示了Kafka生態(tài)系統(tǒng)的事件流，如何為制造型企業(yè)提供新的設(shè)備即服務(wù)模式。其中，無狀態(tài)和有狀態(tài)的流式分析，能夠?qū)崟r地為大規(guī)模數(shù)據(jù)做出主動和預(yù)測性的決策。這種架構(gòu)可以被用在一到多個云服務(wù)區(qū)域、數(shù)據(jù)中心的內(nèi)部部署、以及外部邊緣與混合架構(gòu)的任意組合中。可以說，該方式將成為下一代物聯(lián)網(wǎng)平臺和設(shè)備服務(wù)事件流的主要處理方式。

譯者介紹

陳 峻 （Julian Chen），51CTO社區(qū)編輯，具有十多年的IT項目實施經(jīng)驗，善于對內(nèi)外部資源與風(fēng)險實施管控，專注傳播網(wǎng)絡(luò)與信息安全知識與經(jīng)驗；持續(xù)以博文、專題和譯文等形式，分享前沿技術(shù)與新知；經(jīng)常以線上、線下等方式，開展信息安全類培訓(xùn)與授課。

原文標(biāo)題：Kafka for Condition Monitoring and Predictive Maintenance in Industrial IoT，作者: Kai Wähner