過去，在大家的眼中，制造業(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