無塵室壓差監控如何智慧化?從指針錶到 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 | 即時儀表板、歷史趨勢查詢 |
DPTX 防爆差壓傳送器——無塵室壓差智慧監控系統的現場感測層核心元件
核心功能一:FFU 濾網壽命預測
這是智慧化最直接見效的功能。既有文章提到「差壓上升超過初始值 20% 時該考慮更換」,智慧化的價值在於自動計算這個時間點還有多久會到,而不是等它真的發生。
以下是雲端 Lambda 執行的 FFU 壽命預測邏輯,針對每個監測點獨立計算:
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"])核心功能二:壓差梯度邏輯自動驗證
無塵室壓差控制的本質不是單點數值,而是區域之間的梯度關係——晶圓製造區必須高於準備區、準備區必須高於走廊。這種「跨點位邏輯」是既有 BMS 閾值警報最容易忽略的部分:單一監測點可能還在正常範圍內,但梯度關係已經被破壞。
案例:相鄰分區壓差梯度即時驗證
場景:某晶圓廠 ISO 5 製造區與 ISO 7 準備區之間,設計要求前者需比後者高至少 5 Pa。若準備區壓力異常上升(如該區 FFU 風量被誤調),即使兩區各自的絕對值都還在正常範圍,梯度差可能已經低於安全值,這種異常單看個別數值不會觸發警報。
架構:在 AWS IoT SiteWise 中定義資產階層與運算表達式(Asset Property Alias + Metric),將相鄰分區的監測點建立父子關係,即時計算兩點差值,當梯度差低於設計值時觸發獨立警報,不需要等待任一單點超過個別閾值。
以下是梯度驗證的核心邏輯,比對所有相鄰分區配對,自動偵測梯度異常:
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 供氣範圍內所有監測點的下降模式:
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資料架構與監控密度的雲端負載評估
無塵室的監測密度是所有已討論產業案例中最高的,這對雲端架構的資料量與成本評估有直接影響。
| 規劃項目 | 建議做法 | 原因 |
|---|---|---|
| 資料上傳頻率 | 不需每次 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 防爆差壓傳送器
半導體矽壓阻效應,防爆設計適合危險環境,訊號與差壓具良好線性關係,適合無塵室與石化管線差壓量測整合。

DPS-2.5SPD3 多功能壓力開關
全量程精度 0.5%,可選配 RS-485 數位輸出,適合作為 FFU 單元級的分散式監測點。
THT-S351系列 溫濕度傳送器
進口溫濕度感測元件,精度高、響應快,適合無塵室環境溫濕度與壓差聯合監控。

STT HART智能型溫度傳送器
支援遠端組態與診斷,適合搭配壓差系統做無塵室環境完整參數監控。
需要為您的無塵室設計智慧監控架構?
從差壓傳送器選型到 AWS 雲端架構規劃,告訴我們您的無塵室等級與監測規模,ATLANTIS 工程團隊協助您完成從現場感測到雲端智慧分析的完整對接確認。
豐富產品現貨・TAF 認可校正・材質證明書完整提供・24 小時緊急備品支援
業務一部 Ian:ian@atlantis.com.tw 業務二部 Nori:nori@atlantis.com.tw 電話:02-2820-3405