Skip to main content

無塵室壓差監控如何智慧化?從指針錶到 AWS 雲端 AI 分析的完整技術實作指南

無塵室壓差監控AWS IoT SiteWiseAI異常預測FFU壽命管理

無塵室壓差監控如何智慧化?從指針錶到 AWS 雲端 AI 分析的完整技術實作指南

無塵室已經裝了差壓傳送器,但數據還躺在 BMS 裡沒有被真正利用?這篇文章專注在「智慧化」這一步:怎麼把數百個差壓監測點的原始數據,串接到 AWS,做成能提前 3-7 天預警 FFU 故障、自動驗證壓差梯度邏輯的智慧監控系統。

免費技術選型諮詢 →

從「有監測」到「智慧化」:差在哪一步

多數無塵室已經有差壓監測設備,數據也連上了 BMS(Building Management System)。但「有監測」不等於「智慧化」——BMS 通常只做兩件事:顯示即時數值、超過閾值時響鈴。這代表:

  • 濾網堵塞是漸進過程,等到閾值觸發警報時,往往已經逼近臨界點,缺乏提前排程更換的緩衝時間
  • 多個監測點之間的邏輯關係(如相鄰區域應維持壓差梯度)沒有被自動比對,異常要靠人工巡檢才會發現
  • 歷史數據通常只保留在 BMS 本地資料庫,難以做長期趨勢分析或跨廠區比較

「智慧化」的核心,是把這些原本要靠工程師經驗判斷的邏輯,變成雲端自動運算的規則與模型。這篇文章聚焦三個最具體、最快能看到效益的智慧化功能:FFU 壽命預測壓差梯度自動驗證故障來源自動判別

架構總覽:數百個監測點如何彙整上雲

無塵室的監測密度遠高於一般工業場景——中型 FAB 常見 400-800 個差壓監測點。這個規模下,架構設計的重點在於「怎麼有效率地彙整大量點位」,而不是單點的資料傳輸邏輯。

層級設備/服務角色
現場層DPTX 防爆差壓傳送器(每監測點)量測壓差,Modbus RTU / HART 輸出
區域彙整層區域閘道器(每 20-40 點一台)降低單一 RS-485 匯流排負載,分區 polling
廠區層AWS IoT SiteWise Edge Gateway建立資產階層(廠區→無塵室分區→FFU單元→監測點),彙總多台區域閘道器
雲端運算層AWS IoT SiteWise + Lambda + Timestream執行運算表達式(梯度驗證)、趨勢預測、異常判別
呈現層Amazon QuickSight / Grafana即時儀表板、歷史趨勢查詢
架構重點:大規模監測點部署時,不建議把所有點位都掛在同一條 Modbus RTU 匯流排上。每 20-40 點分一個區域,用多台輕量閘道器彙整,再統一送往 SiteWise,可避免單一匯流排 polling 週期過長導致資料更新延遲。
DPTX防爆差壓傳送器

DPTX 防爆差壓傳送器——無塵室壓差智慧監控系統的現場感測層核心元件

核心功能一:FFU 濾網壽命預測

這是智慧化最直接見效的功能。既有文章提到「差壓上升超過初始值 20% 時該考慮更換」,智慧化的價值在於自動計算這個時間點還有多久會到,而不是等它真的發生。

以下是雲端 Lambda 執行的 FFU 壽命預測邏輯,針對每個監測點獨立計算:

ffu_lifetime_predictor.py
import boto3, numpy as np
                from datetime import datetime
                timestream = boto3.client("timestream-query")
                sitewise = boto3.client("iotsitewise")
                sns = boto3.client("sns")
                REPLACEMENT_THRESHOLD_RATIO = 1.20   # 差壓達初始值 120% 視為應更換
                WARNING_DAYS_AHEAD = 7            # 提前幾天預警
                def get_baseline_and_recent(asset_id: str) -> tuple:
                    # baseline:濾網更換後首週平均值;recent:近14天數據
                    query = f"""
                        SELECT time, measure_value::double
                        FROM "cleanroom"."ffu_differential_pressure"
                        WHERE assetId = '{asset_id}'
                        AND time > ago(14d)
                        ORDER BY time ASC
                    """
                    result = timestream.query(QueryString=query)
                    values = [float(row["Value"]) for row in result["Rows"]]
                    baseline = sitewise.get_asset_property_value(
                        assetId=asset_id, propertyId="baseline_dp"
                    )["propertyValue"]["value"]["doubleValue"]
                    return baseline, values
                def predict_replacement_date(asset_id: str, ffu_name: str):
                    baseline, readings = get_baseline_and_recent(asset_id)
                    if len(readings) < 10:
                        return  # 資料量不足,暫不預測
                    threshold = baseline * REPLACEMENT_THRESHOLD_RATIO
                    x = np.arange(len(readings))
                    slope, intercept = np.polyfit(x, readings, 1)
                    if slope <= 0:
                        return  # 差壓沒有上升趨勢,濾網狀態穩定
                    current = readings[-1]
                    steps_to_threshold = (threshold - current) / slope
                    days_to_threshold = steps_to_threshold * (14 / len(readings))
                    if days_to_threshold <= WARNING_DAYS_AHEAD:
                        sns.publish(
                            TopicArn="arn:aws:sns:ap-northeast-1:xxx:ffu-maintenance",
                            Message=f"{ffu_name} 預估 {days_to_threshold:.1f} 天後達到更換閾值(目前 {current:.2f} Pa,基準 {baseline:.2f} Pa)"
                        )
                def handler(event, context):
                    ffu_assets = sitewise.list_assets(assetModelId="ffu-unit-model")["assetSummaries"]
                    for asset in ffu_assets:
                        predict_replacement_date(asset["id"], asset["name"])
與 RO 系統趨勢預測的差異:FFU 預測需要「基準值」(濾網剛更換時的差壓)作為比較基礎,而非單純看絕對數值——因為不同 FFU 單元的初始差壓可能因安裝位置、風量設定不同而有差異,用比例(120%)而非絕對閾值更準確。

核心功能二:壓差梯度邏輯自動驗證

無塵室壓差控制的本質不是單點數值,而是區域之間的梯度關係——晶圓製造區必須高於準備區、準備區必須高於走廊。這種「跨點位邏輯」是既有 BMS 閾值警報最容易忽略的部分:單一監測點可能還在正常範圍內,但梯度關係已經被破壞。

案例:相鄰分區壓差梯度即時驗證

場景:某晶圓廠 ISO 5 製造區與 ISO 7 準備區之間,設計要求前者需比後者高至少 5 Pa。若準備區壓力異常上升(如該區 FFU 風量被誤調),即使兩區各自的絕對值都還在正常範圍,梯度差可能已經低於安全值,這種異常單看個別數值不會觸發警報。

架構:在 AWS IoT SiteWise 中定義資產階層與運算表達式(Asset Property Alias + Metric),將相鄰分區的監測點建立父子關係,即時計算兩點差值,當梯度差低於設計值時觸發獨立警報,不需要等待任一單點超過個別閾值。

以下是梯度驗證的核心邏輯,比對所有相鄰分區配對,自動偵測梯度異常:

pressure_gradient_validator.js
const AWS = require('aws-sdk');
                const sitewise = new AWS.IoTSiteWise();
                const sns = new AWS.SNS();
                // 定義相鄰分區配對與最小梯度要求(Pa)
                const ZONE_PAIRS = [
                  { upstream: 'ISO5-WaferFab', downstream: 'ISO7-PrepArea', minGradient: 5.0 },
                  { upstream: 'ISO7-PrepArea', downstream: 'Corridor', minGradient: 3.0 },
                  { upstream: 'Corridor', downstream: 'Exterior', minGradient: 2.0 }
                ];
                async function getLatestPressure(zoneAssetId) {
                  const result = await sitewise.getAssetPropertyValue({
                    assetId: zoneAssetId,
                    propertyId: 'differential_pressure'
                  }).promise();
                  return result.propertyValue.value.doubleValue;
                }
                exports.handler = async () => {
                  for (const pair of ZONE_PAIRS) {
                    const upstreamValue = await getLatestPressure(pair.upstream);
                    const downstreamValue = await getLatestPressure(pair.downstream);
                    const actualGradient = upstreamValue - downstreamValue;
                    // 即使兩區個別數值都在正常範圍,梯度不足仍會被抓出來
                    if (actualGradient < pair.minGradient) {
                      await sns.publish({
                        TopicArn: 'arn:aws:sns:ap-northeast-1:xxx:gradient-alert',
                        Message: `梯度異常:${pair.upstream} → ${pair.downstream} 
                          實際梯度 ${actualGradient.toFixed(1)} Pa,低於設計值 ${pair.minGradient} Pa`
                      }).promise();
                    }
                  }
                };

核心功能三:HVAC vs FFU 故障自動判別

既有文章提到「全區下降是 HVAC 故障、局部下降是 FFU 故障」的判斷原則,這個邏輯人工判讀通常需要 3-5 分鐘。智慧化的價值是把這個判斷自動化,並直接在警報訊息中標明可能原因,縮短工程師的初步排查時間。

以下是雲端端的故障來源自動判別邏輯,比對同一 AHU 供氣範圍內所有監測點的下降模式:

fault_source_classifier.py
import boto3
                sitewise = boto3.client("iotsitewise")
                sns = boto3.client("sns")
                DROP_THRESHOLD_RATIO = 0.85  # 低於基準值 85% 視為異常下降
                WIDESPREAD_RATIO = 0.6       # 60% 以上監測點同時異常 → 判定為全區性
                def classify_fault_source(ahu_zone_id: str) -> dict:
                    monitoring_points = sitewise.list_associated_assets(
                        assetId=ahu_zone_id, hierarchyId="monitoring-points"
                    )["assetSummaries"]
                    abnormal_points = []
                    for point in monitoring_points:
                        current = sitewise.get_asset_property_value(
                            assetId=point["id"], propertyId="differential_pressure"
                        )["propertyValue"]["value"]["doubleValue"]
                        baseline = sitewise.get_asset_property_value(
                            assetId=point["id"], propertyId="baseline_dp"
                        )["propertyValue"]["value"]["doubleValue"]
                        if current < baseline * DROP_THRESHOLD_RATIO:
                            abnormal_points.append(point["name"])
                    ratio = len(abnormal_points) / len(monitoring_points)
                    if ratio == 0:
                        return {"status": "normal"}
                    elif ratio >= WIDESPREAD_RATIO:
                        return {
                            "status": "abnormal",
                            "likely_source": "HVAC(全區性下降)",
                            "affected_points": abnormal_points,
                            "recommendation": "檢查 AHU 供氣機狀態與備用系統切換"
                        }
                    else:
                        return {
                            "status": "abnormal",
                            "likely_source": "FFU(局部性下降)",
                            "affected_points": abnormal_points,
                            "recommendation": f"檢查以下 FFU 單元的電源與濾網: {abnormal_points}"
                        }
                def handler(event, context):
                    result = classify_fault_source(event["ahu_zone_id"])
                    if result["status"] == "abnormal":
                        sns.publish(
                            TopicArn="arn:aws:sns:ap-northeast-1:xxx:cleanroom-fault",
                            Message=f"疑似故障來源: {result['likely_source']}\n建議動作: {result['recommendation']}"
                        )
                    return result
工程重點:這個判別邏輯把既有文章中「95% 情況 3-5 分鐘可判斷」的人工經驗,壓縮成雲端運算的秒級輸出,讓警報訊息直接附帶初步診斷方向,而不只是「異常」兩個字,大幅縮短工程師到場後的排查時間。

資料架構與監控密度的雲端負載評估

無塵室的監測密度是所有已討論產業案例中最高的,這對雲端架構的資料量與成本評估有直接影響。

400-800
中型 FAB 典型監測點數
1-5秒
建議 polling 更新頻率
20-40
建議單一區域閘道器負責點數
規劃項目建議做法原因
資料上傳頻率不需每次 polling 都上傳,可設 Deadband 過濾壓差變化通常緩慢,過度頻繁上傳增加雲端成本卻無助於分析精度
資產階層設計依廠區→分區→FFU單元→監測點四層建立SiteWise 的階層結構是後續梯度驗證、批次查詢的基礎
閘道器數量規劃依監測點數 ÷ 30 估算所需區域閘道器數避免單一 RS-485 匯流排 polling 週期過長
歷史資料保存策略高頻原始資料本地保留短期,雲端存聚合後資料降低 Timestream 儲存與查詢成本

技術 FAQ

Q1. FFU 壽命預測需要多少歷史資料才能開始運作?

建議至少累積一次完整的濾網更換週期(含更換後的基準值)再開始預測,通常需要數週到數月的歷史資料。若剛導入系統沒有歷史基準,可先以 BMS 既有的閾值警報運作,同時累積資料,待基準穩定後再切換為預測模式。

Q2. 為什麼要用「相對基準值的比例」而不是「絕對差壓值」判斷 FFU 更換時機?

不同 FFU 單元因為安裝位置、風量設定、周邊氣流環境不同,即使是全新濾網的初始差壓也會有差異。用比例(如超過基準值 120%)能讓判斷邏輯適用於所有監測點,不需要為每一台 FFU 分別設定絕對閾值。

Q3. 壓差梯度驗證會不會因為量測雜訊而頻繁誤報?

會有這個風險,建議梯度計算採用短期移動平均(如過去 5 分鐘平均值)而非單次瞬時讀值,並在觸發警報前要求連續多次判定異常(如連續 3 次 polling 都低於閾值)才發送通知,避免單次雜訊造成誤報。

Q4. AWS IoT SiteWise 的資產階層要怎麼對應無塵室的實體佈局?

常見做法是依照廠區的實體空間邏輯建立階層:頂層為廠區,往下依序是無塵室分區(如 ISO 5 製造區、ISO 7 準備區)、FFU 單元群組、個別監測點。這個階層結構除了方便管理,也是梯度驗證邏輯中「取得相鄰分區資料」的查詢基礎。

Q5. 故障來源判別的閾值(85%、60%)要怎麼設定才準確?

沒有放諸四海皆準的數值,需要依照實際廠區的歷史故障案例校準。建議先用寬鬆閾值上線觀察一段時間,比對系統判定結果與工程師實際排查結果的吻合度,再逐步收斂閾值,這個校準過程通常需要數週到一兩個月。

Q6. 800 個監測點全部即時上傳,AWS 費用會不會很可觀?

取決於上傳頻率與資料保存策略。若都採取秒級即時上傳且長期保存原始數據,成本確實會累積。建議搭配 Deadband 過濾(數值變化未超過閾值不上傳)與資料聚合(本地先做分鐘級平均),可大幅降低 Timestream 的寫入與儲存量,同時不影響分析精度。

Q7. 智慧化系統上線後,還需要保留既有的指針式備用錶嗎?

需要。智慧化系統再完善,仍應保留指針式備用錶作為現場快速驗證工具——當雲端系統或閘道器本身發生異常時,指針錶能讓工程師立即確認現場真實壓差,不受任何電子系統故障影響,這個「類比備援」原則在高風險場域是基本配置。

ATLANTIS 對應產品線

昶特有限公司(ATLANTIS)31 年工業儀錶製造經驗,DPTX 防爆差壓傳送器是無塵室壓差智慧監控系統的核心感測元件,支援多種通訊協定可直接對接前述 AWS 架構。

DPTX 防爆差壓傳送器

DPTX 防爆差壓傳送器

半導體矽壓阻效應,防爆設計適合危險環境,訊號與差壓具良好線性關係,適合無塵室與石化管線差壓量測整合。

DPS-2.5SPD3 多功能壓力開關

DPS-2.5SPD3 多功能壓力開關

全量程精度 0.5%,可選配 RS-485 數位輸出,適合作為 FFU 單元級的分散式監測點。

THT-S351系列 溫濕度傳送器

THT-S351系列 溫濕度傳送器

進口溫濕度感測元件,精度高、響應快,適合無塵室環境溫濕度與壓差聯合監控。

STT HART智能型溫度傳送器

STT HART智能型溫度傳送器

支援遠端組態與診斷,適合搭配壓差系統做無塵室環境完整參數監控。

→ 查看完整 257 項產品型錄

需要為您的無塵室設計智慧監控架構?

從差壓傳送器選型到 AWS 雲端架構規劃,告訴我們您的無塵室等級與監測規模,ATLANTIS 工程團隊協助您完成從現場感測到雲端智慧分析的完整對接確認。

豐富產品現貨・TAF 認可校正・材質證明書完整提供・24 小時緊急備品支援

立即詢價 / 技術諮詢 →

業務一部 Ian:ian@atlantis.com.tw  業務二部 Nori:nori@atlantis.com.tw  電話:02-2820-3405