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

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

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

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

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

以維護(hù)替代修理

縮減計(jì)劃外的停機(jī)時(shí)間

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

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

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

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

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

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

通過(guò)檢測(cè)異常和分類錯(cuò)誤，來(lái)判斷設(shè)備運(yùn)行正常嗎?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

小結(jié)

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

譯者介紹

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

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