• <xmp id="om0om">
  • <table id="om0om"><noscript id="om0om"></noscript></table>
  • 3 月 19 日下午 2 點,鎖定 NVIDIA AI 網絡中文專場。立即注冊觀看
    數據科學

    RAPIDS AI 加速制造業預測性維護效率

    根據國際自動化協會(ISA)報告,每年有5%的工廠生產因機時間而受到損失。在另一種情況下,各行各業的制造商在全球范圍內放棄了大約647億美元,而相應的部分在生產中則接近13萬億美元。當前的挑戰是預測這些機器的維護需求,以最大限度地減少機時間、降低運營成本并優化維護計劃。

    這種問題在提供 Desktop as a Service (DaaS) 服務的公司中尤為普遍,這些公司租用計算設備用于商業用途,并需要滿足嚴格的 SLAs 要求。DaaS 行業的價值高達 3 億美元,預計將增長 12%。

    在本文中,我們將討論一個案例:我們構建了一個預測模型,以根據各種操作參數、傳感器數據和歷史維護記錄來估計計算資產的剩余使用壽命(RUL)。

    LatentView Analytics

    LatentView Analytics 支持多個 DaaS 客戶端,并通過商業智能、數據分析和科學、數據工程、機器學習和 AI 等領域的高級數據分析咨詢服務,提供運營復雜的服務。

    我們發現,企業組織可以使用預測性維護算法在設備故障發生之前進行檢測,從而節省寶貴的停機時間。數據科學的進步使得預測和預測在企業中得到廣泛應用。與常規或基于時間的預防性維護等標準操作程序相比,預測性維護能夠提前解決問題。

    LatentView 構建了一種名為 PULSE 的解決方案,這是一種先進的預測性維護解決方案,旨在重新定義制造效率。通過連接支持 IoT 的資產,PULSE 使用先進的分析來提供實時見解,使您的團隊能夠采取前瞻性的措施。

    PULSE 有助于減少和消除計劃外機時間、過高的維護成本和運營低效。你可以精確預測機器故障,消除機時間麻煩,并提高制造效率。

    Diagram shows the PULSE model workflow and data stack, starting from data sources and moving through data ingestion frameworks, messaging, processing, security, governance, monitoring, profiling, access, and then data consumption in the form of reports, dashboards, files, applications, and relational databases.
    圖 1.LatentView ML 工作流程

    剩余使用壽命用例

    一家領先的計算設備制造客戶希望實施有效的預防性維護。數百萬臺租賃計算設備發生部件故障,導致客戶流失和不滿足。如果能夠及早發現故障并提出維修和更換建議,將減少客戶流失,提高客戶忠誠度和盈利率。

    為了解決客戶的痛點,我們決定使用預測性維護模型來預測每臺機器的RUL。該模型有助于確定每臺機器在需要維修或更換之前的運行時間,從而消除機器交付給客戶時的部件故障。

    為構建這種適用于計算設備的預測性維護模型,我們首先需要聚合來自關鍵熱感、電池、風扇、磁盤和 CPU 傳感器的數據,這些傳感器測量了機器的溫度、周期和多個方面。然后,將這些數據聚合并應用于預測模型中。

    以下各節將介紹我們的初步嘗試、學習,以及GPU加速的數據科學如何幫助我們加快實施速度,從而為客戶成功交付項目。

    面臨的挑戰

    在我們首次嘗試為客戶構建概念驗證時,我們在使用預測性維護平臺產品 PULSE 時面臨著許多挑戰,這些挑戰主要集中在計算瓶頸和延長周期處理時間上。這主要是因為進行有效預測所需的大量數據和源源不斷的數據流,反過來又吸引了越來越多的節點和圖像來滿足計算需求。

    雖然這些挑戰是問題的整體性,但我們主要希望工具和庫與解決方案集成,以便更好地擴展到動態操作條件,該解決方案應盡可能縮短查看結果所需的時間,并優化 TCO(包括基礎設施成本)。

    我們遇到了以下一些問題:

    • 大型實時數據集
    • 稀疏和噪聲傳感器數據
    • 多元關系
    • 漫長的時間軸
    • 成本方面
    • 推理挑戰

    大型實時數據集

    由于在多個地點部署了數百萬臺機器,且每臺機器上都有多個傳感器,并且每隔 5 分鐘就會收集一次數據,因此每天會收集超過 1TB 的數據。這使得數據處理和清潔成為最耗時和繁瑣的任務,因為我們花了近 60% 的時間準備數據。

    使用最新訓練數據對模型進行持續迭代訓練、數據清潔、添加新功能,以及試驗多個模型以最終確定生產模型,還可以增加總工作量、時間和計算能力。

    稀疏和噪聲傳感器數據

    在制造或 DaaS 環境中,從每臺機器的傳感器數據通常稀疏(大多數值為 0 或為空),以不規則的時間間隔收集,并且容易產生噪音。

    多元關系

    在該用例的單個模型中必須考慮的傳感器類型的數量造成了復雜的多元情況,從而增加了計算需求。

    漫長的時間軸

    創建準確的預測需要包含大量示例的大型數據集來訓練模型。

    隨著大數據用例的不斷增長,CPU 性能成為主要瓶頸,這些限制增加了周期時間和成本,并在我們的 PoC 結果中變得顯而易見。

    成本方面

    必須對基礎設施進行擴展以縮短周期時間。大規模 CPU 基礎設施會產生巨大的成本,從而降低數據驅動型企業的投資回報。

    推理挑戰

    部署大規模預測過程十分困難。通常需要大量軟件重構,有時甚至需要重寫針對用例和團隊之間的傳遞進行優化的代碼。在這種情況下,insight 生成可能會大幅延遲。

    采用 RAPIDS 的加速預測性維護解決方案

    PULSE旨在使用PyData生態系統在CPU基礎設施上運行。隨著 RAPIDS 的推出,我們希望通過RAPIDS為客戶提供一個加速的PULSE平臺,作為所有PyData庫的直接替代品。

    我們發現,在 PULSE 系統中使用 NVIDIA RAPIDS 具有以下明顯的優勢:

    • 創建更快的數據管道
    • 在已知平臺上工作
    • 瀏覽動態操作條件
    • 處理稀疏和噪聲傳感器數據
    • 得益于更快的數據加載和預處理,模型訓練速度也因此加快了。

    創建更快的數據管道

    借助 GPU 的強大功能,工作負載實現了并行化,從而減輕了處理大量近乎實時數據對 CPU 基礎設施的負擔。隨著性能的提高,我們預計基礎設施將以更少的資源更高效地運行,從而節省成本。

    在已知平臺上工作

    我們團隊中的數據科學家使用 Python 包 pandasscikit-learn。RAPIDS 提供語法類似或相同的包,以及在 GPU 上運行工作負載的 RAPIDS cuDF 和 cuML 庫,這有助于縮短開發時間,而無需開發新的技能。

    借助我們使用的 GPU 加速,該模型可借助額外的訓練數據無縫地調整,以適應動態條件,確保其保持穩健,并能響應不斷變化的模式和近期趨勢。

    處理稀疏和噪聲傳感器數據

    事實證明,RAPIDS 在處理復雜的稀疏和噪聲傳感器數據方面發揮了重要作用。通過使用 GPU 加速的 cuDF 庫,我們的數據預處理速度得到了顯著提升。我們以前所未有的效率對缺失值進行了估算,并過濾掉了噪聲,準確地處理了數據收集中的異常情況。

    RAPIDS奠定了清晰可靠的數據集的基礎,為更準確的預測模型奠定了基礎。

    更快的數據加載和預處理、模型培訓

    RAPIDS 的數據加載、預處理和 ETL 功能基于 Apache Arrow 構建,用于加載、連接、聚合、過濾和其他操作數據,所有這些功能均在類似 pandas 的 API 中實現超過 10 倍的加速。這縮短了模型迭代時間,使我們能夠在短時間內嘗試多個模型。

    圖 2. 對 NVIDIA GPU 加速庫的使用位置進行了高度代表性描述。我們已在現有的 PULSE 解決方案中集成 RAPIDS 和 RAPIDS Accelerator for SPARK,以加速 AI/ML 層以及數據處理和高級分析。集成無縫,并且可以無代碼或低代碼更改。

    Diagram shows the aspects of the PULSE workflow accelerated by RAPIDS, including the advanced AI / ML layer, processed layer, and reports and dashboards.
    圖 2.使用 RAPIDS 的 LatentView ML 工作流程

    CPU 和 RAPIDS 性能對比

    為了評估項目中的 GPU 加速,我們計劃進行概念驗證,通過比較我們的 CPU-only 模型與在 GPU 上的 RAPIDS 來對加速性能進行基準測試。這些是我們比較的解決方案:

    • 使用 Pandas 對解決方案進行僅 CPU 的測試運行
    • 使用 RAPIDS cuDF 進行測試運行,以加速 Pandas

    此試點采用本地設置,具有以下 GPU 基礎設施:

    • CPU 插槽:2
    • CPU 型號:AMD EPYC 7742
    • CPU 核心:128 個核心 (256 個超線程)
    • 系統內存:512GiB
    • GPU:NVIDIA A100 PCIe
    • GPU VRAM:80GiB

    數據集

    在此試點項目中,因安全和數據合規性問題,我們無法使用生產數據。這些基準測試是在客戶的安全基礎設施之外完成的。

    我們必須返回到具有備用列的合成數據。當前的生產部署使用 Databricks 和 Microsoft Azure。在測試中,我們希望使合成數據盡可能接近實際數據。我們使用 Databricks 實驗室基于 Spark 的 dbldatagen 實用程序生成大小為 12 GB 的數據。

    以下示例代碼顯示了數據集的詳細信息:

    from pyspark.sql.functions import *
    from pyspark.sql.types import *
    import pandas
    import numpy
    import os
    pandas.set_option('display.max_columns', None)
    import dbldatagen as dg
     
    # Column definitions are stubs only - modify to generate correct data
     
    generation_spec = ( dg.DataGenerator(sparkSession=spark, name='synthetic_data', rows=350000000, random=True, partitions=8 ) .withColumn('Unique_Key', 'string', template=r'\\w') .withColumn('Month', 'string', values=[201908, 202106, 201910, 202102, 202010, 202009, 201907, 202012, 202006, 202207, 201909, 202004, 201906, 202206, 202008, 202104, 201912, 202204, 202001, 202110, 202011, 202108, 202007, 201911, 202208, 202002, 202003, 202203, 202101, 202109, 202103, 202005, 202112, 202210, 202105, 202205, 202202, 202209, 202301, 202201, 202107, 202302, 202111, 202211, 202212])
    .withColumn('Part_No', 'bigint', minValue=1000000000, maxValue=10000000000)
    ……………………………………………..
    )
     
    df1 = generation_spec.build()
     
    df1.coalesce(1).write.format("csv").mode("overwrite").save("/rapids/notebooks/host/hostdata1/lv_data/final_data/final_2", header = True)
     
    data = spark.read.csv("/rapids/notebooks/host/hostdata1/lv_data/final_data/final/header.csv", header=True,inferSchema=True)
     
    data.head(1)
     
    [Row(Unique_Key='laboris', Month=201908, Part_No=4821032423, Region='LA', classification='Erratic', order_type='SVC&RPB', WIB=12226712, CPIB=1723240, COIB=122034, Order_Qty=1111, Business_Segment='other', Market_Segment='EMEA_Consumer', Exception_Flag='N', Load_date=202202, Product_Line='5X', Part_Commodity='Service/Support Kit', commoditygroup='nan', Active_flag='Y', Part_Life='Sustaining', FCS_date=41.62, RV='A', ABC='X', XYZ='N', Roll_Flag=52705, Order_Qty_agg=None)]

    代碼示例生成由參數 rows 定義的所需大小的合成數據。前面定義的數據生成規范與客戶生產數據結合使用。

    生成的數據具有多種數據類型,這些數據類型必須經過預處理和特征工程步驟。這有助于從生成的數據中提取和轉換變量,這些變量可用于進一步的高級數據分析以及監督式或非監督式學習。

    數據處理、轉換和特征工程

    在當前的 RUL 部署用例中,我們通過從熱傳感器、電池傳感器、風扇傳感器、磁盤傳感器和 CPU 傳感器中收集數據來查看來自機器的各種參數。我們的測試包括以下任務,因為這些是準備數據集來訓練機器學習模型的先決條件:

    • 讀取數據
    • Feature engineering
      • 刪除重復項
      • 丟棄不適用
      • 一鍵編碼。
      • 數據歸一化
    • 相關性分析
    • 按組操作(計算組的均值、標準差和最大值)

    我們使用 RAPIDS cuDF 中的 pandas 加速器模式運行這些任務。通過在 Jupyter Notebook 中添加命令 %load_ext cudf.pandas,這種新模式可以在不更改代碼的情況下加速 pandas 代碼。

    # Magic command for using original pandas code with no-code change with RAPIDS
    %load_ext cudf.pandas
     
    %%time
    #Read/Load data
    df = pd.read_csv("/rapids/notebooks/hostdata1/lv_data/q0/t3/part1.csv")
     
    # Feature engineering
    # Drop duplicates
    df = df.drop_duplicates()
     
    # Drop rows with null values
    df = df.dropna()
     
    # Select categorical columns for one-hot encoding categorical_columns = ['cat_0', 'cat_1', 'cat_2', 'cat_3', 'cat_4']
     
    # Perform one-hot encoding df_encoded = pd.get_dummies(df, columns=categorical_columns)
     
    # Normalizing values between 0 and 1
    from sklearn.preprocessing import MinMaxScaler
     
    scaler = MinMaxScaler()
    columns_to_normalize = ['cont_0', 'cont_1', 'cont_2', 'cont_3', 'cont_4', 'cont_5', 'cont_6', 'cont_7', 'cont_8', 'cont_9', 'cont_10', 'cont_11', 'cont_12', 'cont_13', 'target','new_feature_2', 'new_feature_3', 'new_feature_1'] df[columns_to_normalize] = scaler.fit_transform(df[columns_to_normalize])
     
    # Group-by operations
    grouped = df.groupby('cat_0').agg({'target': ['mean', 'std'], 'new_feature_1': 'max'})
     
    # Compute and plot pairwise correlation of columns
     
    # Select continuous features for correlation analysis continuous_features = ['cont_0', 'cont_1', 'cont_2', 'cont_3', 'cont_4', 'cont_5', 'cont_6', 'cont_7', 'cont_8', 'cont_9', 'cont_10', 'cont_11', 'cont_12', 'cont_13', 'target', 'new_feature_1', 'new_feature_2', 'new_feature_3']
     
    # Create a cuxfilter DataFrame
    cux_df = cuxfilter.DataFrame.from_dataframe(df)
     
    # Standardize the data using cuml StandardScaler
     
    scaler = StandardScaler()
    df_std = scaler.fit_transform(cux_df.data[continuous_features])
     
    # Add the standardized data to cux_df
    for i, col in enumerate(continuous_features):
        cux_df.data[col] = df_std[i]
     
    # Calculate the correlation matrix
    correlation_matrix = cux_df.data[continuous_features].corr()
     
    # Convert correlation matrix to cuDF DataFrame correlation_matrix_cudf = cudf.DataFrame(correlation_matrix)
    # Use seaborn for plotting
    plt.figure(figsize=(12, 8)) sns.heatmap(correlation_matrix_cudf.to_pandas(), annot=True, cmap='coolwarm', fmt=".2f")
    plt.title('Correlation Matrix Heatmap')
    plt.show()

    此工作流通過完全無代碼更改功能節省了代碼遷移工作量。此外,通過計算端到端工作流(包括數據準備、可視化、模型訓練和調整)中的四項任務相較于 CPU 的平均改進率,還將性能提升了約 171 倍(圖 3)。

    Diagram shows a 637x speedup for RAPIDS in feature engineering; 39x for group-by operations; 5x for reading data; and 3x for correlation analysis.
    圖 3.PyData 與 RAPIDS 加速對比

    表 1 提供了圖 3 中每個步驟的確切運行時間的更多詳細信息。

    ? 步驟 CPU GPU 提升率
    數據準備 讀取數據 87 14.9 5.8
    特征工程 382 0.6 637.7
    按組操作 703 17.7 39.8
    相關性 相關性分析 27.1 8.3 3.3
    表 1. 以所用時間(秒)衡量的 GPU 加速 ML 工作流程。

    表 1 顯示,相較于 Pandas,特征工程和 group-by 操作的計算密集型工作負載分別實現了 639 倍和 39.8 倍的大幅提速。工作流涵蓋 10 GB 數據:43780407 行和 23 列。

    結束語

    我們的客戶發現這些模擬結果很有說服力,因此現已將其部署為客戶環境中的概念驗證。我們預計將于 2024 年第四季度投入生產,以改進 RUL 預測模型。在取得這一成功后,LatentView 很高興能夠繼續將 RAPIDS 加速應用于制造產品組合中的建模項目。

    要親自試用 RAPIDS cuDF,請開始使用 Google Colab

    ?

    +1

    標簽

    人人超碰97caoporen国产