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

下面，我將和您探討那些用于狀態監測和預測性維護的物聯網軟件，是如何協助構建新的產品，并改善設備綜合效率是(Overall Equipment Effectiveness，OEE)的。

首先讓我們來看看狀態監測和預測性維護這兩個術語。由于尚無標準定義，因此一些文獻會將狀態監測視為預測性維護的一個主要組成部分。當然，也有將后者解釋為能夠利用機器學習的現代化軟件。更有甚者，會將這兩個術語視為同義。

現代化維護的策略和目標

現代化維護的策略與目標主要著眼于更加有效地、更優化地利用資源。而這些往往是建立在基于狀態的維護策略之上的。那么，工業物聯網/工業 4.0到底能夠在車間層面上實現并帶來哪些優勢呢?

以維護替代修理

縮減計劃外的停機時間

通過優化，去除不必要的維護工作

減少負面的財務影響

優化生產力

提高設備綜合效率(OEE)

從孤立的視角上升到整個企業的視角

與此同時，設備的操作員則會關注如下方面：

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

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

通過傳感器監控和根本原因分析，來判斷設備運行正常嗎?

狀態監測和預測性維護的本質

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

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

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

設備即服務(EaaS)是新的商業模式

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

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

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

可以說，只有當狀態監控和預測性維護能夠7×24小時地、穩定且持續地收集、處理和分析傳入的數據流時，EaaS才是一個成功的商業模式。

將Apache Kafka用于工業物聯網/工業4.0

作為一種事實上的事件流的??標準??，Apache Kafka往往被全球工業物聯網/工業4.0部署在他們的邊緣和混合云環境中。下圖展示了一個結合了公共云和邊緣事件流的智能工廠架構模型：

由5G Kafka和AWS Wavelength實現的、低延遲的混合邊緣云架構

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

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

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

使用事件流和流處理的動態數據

狀態監控和預測性維護需要基于事件的架構，來收集、處理和分析動態數據。傳統的IIoT(Industrial Internet of Things，工業物聯網)平臺是專有的、不靈活的，無法擴展的，且不適合跨供應商與不同標準的集成。而Kafka的原生流處理是一種開放、靈活、可擴展的技術，并可用于實現跨物聯網接口的數據集成。

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

來自設備PLC的傳感器事件--Scada IoT

在上圖的左側，我們可以看到由存儲和轉發事件所產生的Kafka日志。而在右側，各種設備會實時地捕獲傳感器上的數據。該架構可在任何規模的環境中實時運行。例如，某些Confluent客戶會利用Confluent Cloud進行每秒10GB或更多的數據處理。

設備、PLC(可編程邏輯控制器)、以及傳感器等之間的物聯網集成，是通過Kafka Connect或其他API實現的，同時可以用到MQTT、OPC-UA、REST/HTTP、文件、以及不同的開放或專有接口。如果您對此感興趣，可以參考《??用于工業物聯網集成的Kafka和PLC4x???》和《??Kafka即現代數據歷史學家??》兩篇文章。

使用Kafka Streams進行無狀態監控

下圖顯示了如何實時地去分析在溫度峰值的Kafka原生狀態監控：

使用Kafka Streams進行無狀態監控

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

由于應用程序是無狀態的，只能逐個處理事件，因此無狀態監控能力，對于實現根據復雜的業務邏輯，過濾或轉換流式ETL(Extract-Transform-Load)來說非常實用。

使用ksqlDB進行有狀態的預測性維護

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

使用Kafka和ksqlDB進行有狀態預測性維護

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

使用Kafka和TensorFlow采取實時的機器學習

上述簡單的業務邏輯，可以被用來改進OEE和維護流程。如果我們嵌入機器學習，則能夠使狀態監測和預測性維護達到更好的效果。通常，在不需要改變架構的情況下，分析模型可以像任何其他業務邏輯一樣，被嵌入到Kafka的應用中。您可以通過查看如下鏈接，了解更多相關內容：

??Kafka簡介和用于模型訓練與部署的機器學習??

??使用Kafka進行模型服務與評分的架構和權衡??

??使用Kafka原生模型部署的流式機器學習??

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

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

使用Kafka的KSQL和TensorFlow進行實時機器學習

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

這種架構智能地解決了數據科學團隊和生產團隊之間的錯配問題。數據科學家可以使用Python和Jupyther notebook進行快速原型設計和模型開發;而生產團隊則會在集群中部署ksqlDB的查詢，以實現大規模的實時評分。您可以通過如下優秀的Github項目進行深入學習。該項目使用??Kappa架構???，實現了關注點的分離，可被用于互聯汽車的基礎架構，并使用MQTT和Kafka進行??預測性維護??：

帶有Apache Kafka的MQTT Kubernetes和用于流式機器學習的Tensorflow Kappa架構

使用完全托管的Kafka式設備即服務

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

麥肯錫關于設備即服務的報告

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

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

??Kafka數字孿生用例??

??帶有Kafka的數字孿生和數字線程式物聯網架構??

??專注業務邏輯并使用托管事件流的無服務器Kafka??

??Apache Kafka的各種產品、供應商和云服務的比較??

小結

上文展示了Kafka生態系統的事件流，如何為制造型企業提供新的設備即服務模式。其中，無狀態和有狀態的流式分析，能夠實時地為大規模數據做出主動和預測性的決策。這種架構可以被用在一到多個云服務區域、數據中心的內部部署、以及外部邊緣與混合架構的任意組合中。可以說，該方式將成為下一代物聯網平臺和設備服務事件流的主要處理方式。

譯者介紹

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

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