以嵌入式智能邊緣實現預測性維護  

作者：Ing.Giulio Corradi 博士 / AMD 工業、視覺、醫療和科學首席架構師

從歷史上看，在全面生產環境中，企業最寶貴的資產之一就是機器操作人員的經驗，因為他們能預測出何時需要進行維護。工廠經理會報告任何異常行為，例如機器內的叮噹聲或咔嗒聲，催促維護人員開展檢查。如今，自動化水平的提升嚴重削弱了操作員覺察即將發生的故障的能力，並且大部分維護工作都是按計劃進行，而非預測性維護，如果某些情況下未被發現或被忽視，則會引起不必要的工廠停運。

然而，近來席捲全球的新冠疫情迫使更多機器採用無人值守或遠程值守的方式運行，現場運行被降至最低水平，維護團隊規模被壓縮。因此對工廠經理而言，為輕鬆預測故障而提高機器設備的自動檢測、自我診斷能力成為眼下的戰略優勢。

故障預測與健康管理（PHM）等方法與預測性維護4.0（PdM4.0）等計劃已經問世數年，但現在才從工廠經理的觀察名單轉為當務之急。目標是為自動運行和遠程值守機器設備提供人工在環決策，進行最佳且及時的維護操作。


PHM 旨在採集和分析數據，通過算法檢測異常和診斷即將發生的故障，以提供設備的實時健康狀態，進而估算其剩餘使用壽命（RUL）。相關的財務效益包括延長設備使用壽命，以及降低運營成本。

PdM4.0 是工業 4.0 和工業物聯網（IIoT）計劃的組成部分，其目的是進一步提高設備自動化水平，為設備配備更多的數據採集傳感器，使用數字信號處理、機器學習和深度學習作為預測故障的工具並觸發維護活動。

各項標準與配套的詞彙、演示和指南已製定完成，如 IEEE 1451、1232，ISO 體系的 13372、13373、13374、13380、13381。它們為維護 4.0 奠定了共同的基礎。

圖 1 提供了從計劃維護向 PdM4.0 轉型的路徑。顯然，隨著向 PdM4.0 的轉型不斷深入，複雜性也隨之增加。

然而，雖然PHM 和PdM4.0的意圖清晰並提供了一般性建議，但它們的實際實施並末完全實現，這是因為工廠經理或維護經理尚不具備所需的技能組合。要充分發揮 PHM 和PdM4.0 的優勢，必須思考以下問題：

首先，在建立預測性維護實現的業務案例時，應重點關注能最大限度降低風險的具體問題。
思考問題：最容易出現問題的關鍵資產是什麼？

其次，很多工廠的機器設備的連通性仍然有限，因此數據採集並不容易。
思考問題：如何在不降低機器設備的可靠性、 安全性與保障性的前提下，在機器設備上裝配更多能夠連接到信息技術（1）基礎設施的傳感器？

第三，在採集數據、建立通信後，下一個挑戰是如何使用它們。
思考問題：如何進行數據分組，以便檢測、預測故障並最大限度減少故障的發生？

大多數時候沒有明確的答案。最原始的簡單想法是採集工廠和機器設備產生的所有數據，將這些數據傳遞到雲端的本地數據中心，並嘗試使用數據分析從中提煉信息。這也被視為批處理數據。


圖2所示的是通向雲的數據漏斗以及有助於形成預測性維護的不同數據源。

並非所有的工廠和機器設備數據都相同。還有一些非結構化數據，如檢查報告、維護日誌、原材料和批次組織，這些數據與用於預測性維護的數據相關聯。此外也有來自 ERM、EAM 和MES 等企業自動化技術的結構化數據，它們提供了另一個信息來源，用於檢驗機器設備狀況、 工作量和使用情況。這也稱為批處理數據。

大多數非結構化信息來自與邊緣設備相連的傳感器，因為數據流經常以毫秒為周期大量產生。


PdM4.0 推薦的分析框架如圖3所示

基線分析功能可在實際事件發生後的幾毫秒內檢測到資產的異常行為。用於執行這些分析的數據通常屬於相關資產的本地數據，並旦依賴於資產正常工作時採集的數據。

診斷分析功能用於確定異常的根源，例如電機軸承失效，這需要具備故障狀態的相關知識。診斷結果可以在幾分鐘內返回。

告知軸承剩餘使用壽命的預後分析可能需要數小時才能返回結果，並且需要訪問來自多個來源的多種類型的數據，才能做出預測。

實現架構 - 兩種主要架構正在興起。

結構化數據和非結構化數據、批處理和流處理數據、速度和容量，這些都是工業 4.0 計劃的宏大分析架構的組成部分，而預測性維護則搭載在此類框架上。兩種主要架構正在興起：

• Lambda 架構
• Kappa 架構

Lambda 架構
Lambda 架構是一種用於數據處理的部署模型，將傳統的批處理管道與高速實時的流管道相結合在面對快速產生的海量數據時，可提供數據驅動和事件驅動的數據訪問。


Apache Kafka 是一種用於實現數據源(Data Source）的框架。它是一種分佈式數據存儲，針對實時、順序和增量攝取以及處理流數據進行了優化。
它充當中間存儲，可以保存數據並為 Lambda 架構的批處理層和速度層提供支持。

批處理層 (Batch Layer）通常使用諸如 Apache Hadoop 之類的技術來實現，以便能經濟高效地獲取和存儲數據。為了確保所有傳入數據的可信歷史記錄，這些數據被視為不可變且僅允許追加。

服務層(Serving Layer）會對最新的批量視圖進行增量索引，以允許最終用戶進行查詢。處理過程以一種極度並行化的方式完成，以最大限度縮短對數據集的索引時間。

速度層(Speed Layer）通過索引最新添加的、尚未被服務層完全索引的數據來補充服務層。通常來講 ，最靠近現場流數據的現場網關起著速度層的作用。它們攝取消息、過濾數據、提供身份映射、日志消息並提供到雲端或本地網關的鏈接。如果這些網關也能執行本地分析和機器學習，那麼向上游移 動數據就沒有優勢，而且在確定現場網關平台的大小時，此功能需要考慮CPU 和存儲器大小的影響。查詢層(Query Layer）是數據科學家、工廠專家和管理人員查詢所有數據（包括最近添加的數據） 所需的，以提供近乎實時的分析系統。


Kappa 架構
許多機構可能同時擁有批處理、實時以及非常嚴格的端到端時延需求，要求可以在數據流層中採用包括數據質量技術在內的複雜轉換。因此，Kappa架構是一種流優先的架構部署模式。 Apache Kafka 的功能是攝取數據，並將數據傳遞到 Apache Spark、Apache Flink 等流處理引擎中進行轉換， 然後將富化後的數據發布回服務層， 以實現報告和儀表板功能。

PdM4.0 邊緣設備的硬件要求 - 如何部署 Lambda 或 Kappa 架構？

要部署 Lambda 或Kappa架構，屬於嵌入式系統的設備和邊緣網關需要足夠的算力性能和足夠的內存。以Apache Kafka 為示例進行重點講解：Apache Kafka可以部署到這樣的嵌入式 系統中，為Lambda和Kappa架構提供支持。 Apache Kafka 可以採用不同的配置進行部署，包括裸機、虛擬機（VM）、容器等。以最低配置運行 Apache Kafka 的最低硬件要求是單核處理器和幾個100MB 的RAM。然而，這種小規模的實現方案不足以為 Lambda 和Kappa架構提供適當的服務質量。

具體而言，在 Apache Kafka 的系統概念中，消息流被劃分成名為 “話題〞（topic）的特定類別。這些消息使用名為 “生產方” (producer）的專用進程發布給特定話題。發布後的消息隨後被存儲在名為 “中間代理”（broker）的服務器集群中。

從根本上說，Kafka“ 中間代理〞期望客戶端“生產方〞（現場設備）發送消息給系統，客戶端消費者（邊緣設備）拉出消息，管理客戶端工具（在現場設備和邊緣設備內）允許創建話題、刪除話題並配置安全設置。僅從這些對 “中間代理〞、〞生產方〞、〞消費方者〞和“管理工具"的基本要求， 就可以洞悉需求的多樣性。對於“生產方”，如果我們增加互聯功能和數據採集功能，那麼，算 力性能和存儲器佔用就會成為嵌入式系統的嚴重問題。因此，要讓這樣的嵌入式計算系統提供合理水 平的服務質量，應具備下列特性：

• 異構密集型1/0 採集與處理；
• 能夠執行數字信號處理，以過濾、提取頻譜分量並減少冗餘數據；
• 能夠運行 VM 和容器；
• 能夠實時執行機器學習和深度學習推斷；
• 能夠支持運營數據聯網和信息技術互聯

您可以在片上系統 (SoC)、CPU或GPU中找到一些上述功能，但某些器件 I/O 能力不足，某些器件的機器學習和數字信號處理能力有限，還有些器件不具備足夠的互聯能力。綜合所有這些技術， 另一種技術類別正異軍突起。自適應計算加速平台（ACAP） 集成了上述所有功能，包括面向機器學 習和深度學習推斷的矢量處理、面向運行相關框架的標量 CPU、面向實時數據採集和 I/O 密集型處理 的緊密轉合可編程邏輯（PL)。這些功能結合高帶寬片上網絡(NoC)，能提供對全部三種處理元泰 類型的存儲器映射訪問和對採集和處理數據的存儲器訪問。

ACAP 隨後提供了實現基線所需的資源和靠近數據源的診斷分析功能，並能夠集成 Apache Kafka 和 其他集群系統等流處理框架。