壓力／溫度感測 → Edge → AI → SCADA/BMS：預測性維護資料骨幹完整建置指南（2026版）

第一章：完整架構拆解——從物理量到決策動作

「壓力／溫度感測 → Edge → AI → SCADA/BMS → 預測維護」看似只有五個節點，但每一段都有工程師必須理解的技術細節與常見誤區。以下依序拆解四層架構，並說明每一層對整體預測準確率的影響。

1.1 感測層（Sensing Layer）——資料骨幹的地基

感測層決定了整條資料鏈的資料品質天花板。無論後端 AI 模型多先進，感測器本身若有以下任一問題，預測結果都會失真：這個道理在資料科學領域有一句經典的說法——「垃圾進、垃圾出」（Garbage In, Garbage Out），套用在預測性維護的情境下，意思是：如果最底層的壓力與溫度讀值本身就不準確、不穩定，那麼無論後端的 AI 模型演算法多麼先進、SCADA/BMS 整合介面多麼精美，最終產出的預測結果，都只是在忠實地放大感測層的缺陷而已。

• 精度不足：一般工業用壓力錶精度約 ±1.6% FS，若用於早期異常偵測（需捕捉 0.5% 以內的緩慢飄移），建議選用精度 ±0.5% FS 甚至 ±0.1% FS 的數位壓力傳送器。
• 取樣頻率過低：傳統機械式錶僅供人工巡檢讀值，無法連續取樣；若要做趨勢分析與早期預警，至少需要每 1–10 秒一筆的連續數位輸出。
• 訊號雜訊與飄移：類比 4-20mA 訊號若配線過長、接地不良，容易產生雜訊；建議搭配 HART 通訊疊加數位診斷資訊，或直接採用 RS-485 Modbus 數位輸出。
• 環境耐受性不足：戶外、防爆區、高溫爐體旁的感測器，若未達對應防護等級（IP66/IP67、ATEX/防爆認證），故障率會顯著提高，反而製造更多「假異常」。

1.2 Edge 邊緣層——把原始訊號變成「有意義的事件」

Edge 層的角色，是在資料離開現場、進入雲端或中控室之前，先完成三件事：訊號正規化（單位轉換、Tag 命名統一）、時間同步（避免多感測點時間戳漂移造成誤判）、以及初步異常偵測（在毫秒等級延遲內做本地判斷，不必事事等雲端回應）。這也是為什麼近年 Edge AI 硬體（如工業級邊緣運算模組）能把單一機台的異常偵測從雲端的秒級延遲，壓縮到 15 毫秒以內的關鍵原因——對於需要即時連鎖保護（interlock）的高壓、高溫設備，這個差異就是「來得及停機」與「已經跳機」的分別。

從硬體規劃角度來看，Edge 層通常不是單一設備，而是一個小型的運算層級：入門等級可能僅是一台工業電腦搭配通訊模組，負責資料蒐集與正規化；進階配置則會加入具備 AI 加速能力的運算模組，處理較複雜的多感測融合模型；若場域規模夠大，也可能在同一廠區部署多台 Edge Gateway，分區負責不同產線或設備群組，再統一匯總至中控室層級。這種分層設計的好處是：單一 Edge Gateway 故障時，只會影響該區域的監控，不會讓整廠監控同時中斷，提升了系統的整體韌性。

Edge Gateway 常見部署型態：

• PLC/RTU 旁接式：Edge Gateway 透過 RS-485 或乙太網路，從既有 PLC/SCADA 讀取壓力、溫度暫存器，不干擾既有控制迴路。
• 感測器直讀式：具數位輸出（Modbus RTU、HART、藍牙）的智慧型壓力/溫度傳送器，直接由 Edge Gateway 輪詢讀取，適合既有系統沒有多餘 I/O 點位的場景。
• 混合式：關鍵設備走直讀式取得高頻資料，非關鍵區域沿用既有 SCADA 資料，兩者於 Edge 層統一格式後再上傳。

1.3 AI 分析層——從「數值」到「趨勢」再到「剩餘壽命」

預測性維護的 AI 模型，大致可分為三個成熟度層級。理解這三個層級的差異非常重要，因為它們對應的資料需求、開發時間與投入資源都截然不同，貿然跳過前期層級、直接追求最高階的剩餘壽命預測，往往會因為資料基礎不足而延宕專案時程：

多數導入專案會從 Lv.2 異常偵測開始，原因是投報比最直接：透過壓力與溫度的多感測融合（Multimodal Sensor Fusion），同時比對多個訊號的相關性，可將誤報率大幅降低（業界實測案例可達 90% 以上的無效警報削減），讓維護團隊真正只在「值得看」的時候收到通知。以下提供一段 Edge 端異常偵測的邏輯範例，供工程團隊參考架構（僅為概念性虛擬碼，非可直接執行版本）：

#（虛擬碼／概念範例）孤立森林異常偵測 — 壓力/溫度雙訊號
# 目的：示意 Edge 端如何以歷史基準資料判斷即時讀值是否異常
#
# 1. 蒐集 2~4 週的正常運轉基準資料 (pressure, temperature)
# 2. 以 IsolationForest 或同等演算法訓練基準模型
# 3. 每次新讀值進來時，計算異常分數並與門檻值比較
#
# from sklearn.ensemble import IsolationForest
#
# baseline = load_baseline_dataset()          # [[pressure, temperature], ...]
# model = IsolationForest(contamination=0.02)
# model.fit(baseline)
#
# def on_new_reading(pressure, temperature):
#     score = model.decision_function([[pressure, temperature]])
#     if score < THRESHOLD:
#         raise_local_alert(pressure, temperature, score)
#     forward_to_scada(pressure, temperature, score)

實務上，這類模型通常部署在 Edge Gateway 或工業電腦上，僅將「事件」（異常分數、告警旗標）而非全部原始波形上傳至雲端或中控室，藉此節省頻寬並降低雲端運算成本。

1.4 SCADA/BMS 整合層——讓 AI 判斷變成可執行的維護動作

再精準的 AI 預測，如果沒有回饋進現場真正在用的監控系統，維護人員終究不會天天盯著另一個獨立平台看。因此整合層的設計原則是：不取代既有 SCADA/BMS，而是把 AI 產出的異常事件、健康分數、預測結果，以標準通訊協定寫回既有系統的標籤（Tag）或警報清單。

這個原則背後的邏輯很直接：維護人員已經習慣在既有 SCADA/BMS 畫面上操作，額外要求他們每天登入另一套獨立的 AI 儀表板，往往會因為「多一個系統要看」而降低實際使用率，長期下來系統形同虛設。把智慧化的判斷結果，包裝成現場人員熟悉介面上的一則告警或一個健康分數欄位，才能真正融入既有的工作流程，而不是增加額外的認知負擔。

下方提供一段架構參考範例，示意 Edge Gateway 如何透過 RS-485 Modbus 讀取智慧型壓力/溫度傳送器，經過本地正規化後，再以 MQTT 發佈事件供上層 SCADA/AI 平台訂閱。此範例僅供工程團隊理解資料流向，實際部署仍需依貴公司網路架構、資安規範與既有系統版本調整：

# ===== 檔案：edge_gateway_reference.py（架構參考範例，非正式產品程式碼）=====
# 功能：從 Modbus RTU 感測器讀取壓力/溫度數值，正規化後以 MQTT 發布
# 執行環境示意：工業電腦 / Raspberry Pi 等級 Edge Gateway

import time
# import minimalmodbus         # 需自行安裝對應 Modbus 函式庫
# import paho.mqtt.client as mqtt

SENSOR_CONFIG = [
    {"tag": "P-101", "slave_id": 1, "register": 0, "unit": "bar", "scale": 0.01},
    {"tag": "T-101", "slave_id": 2, "register": 0, "unit": "degC", "scale": 0.1},
]

def read_modbus_register(slave_id, register):
    # instrument = minimalmodbus.Instrument('/dev/ttyUSB0', slave_id)
    # instrument.serial.baudrate = 9600
    # raw_value = instrument.read_register(register, functioncode=4)
    # return raw_value
    return 0  # 佔位示意，實際串接請依感測器通訊手冊調整

def normalize_and_publish(mqtt_client):
    for sensor in SENSOR_CONFIG:
        raw = read_modbus_register(sensor["slave_id"], sensor["register"])
        value = raw * sensor["scale"]
        payload = {
            "tag": sensor["tag"],
            "value": value,
            "unit": sensor["unit"],
            "timestamp": time.time(),
        }
        # mqtt_client.publish(f"plant/edge/{sensor['tag']}", str(payload))
        print(payload)  # 示意輸出，正式環境請改為發布至 MQTT Broker

if __name__ == "__main__":
    # client = mqtt.Client()
    # client.connect("edge-broker.local", 1883)
    while True:
        normalize_and_publish(mqtt_client=None)
        time.sleep(5)

整條資料流以文字化流程表示如下：

[壓力/溫度智慧型傳送器]
        │ RS-485 Modbus RTU / HART / 4-20mA
        ▼
[Edge Gateway：正規化、時間同步、Lv.2 異常偵測]
        │ MQTT（事件）/ OPC UA（結構化資料流）
        ▼
[SCADA 歷史資料庫 / BMS 控制器] ──┬── 現場 HMI 警報
        │ OPC UA / API                 └── 工作單自動派工（CMMS）
        ▼
[AI 分析平台：趨勢分析、剩餘壽命預測、健康分數]

1.5 歷史資料庫與資料治理——AI 模型的長期糧草

許多團隊在規劃架構時，會把重心全部放在「即時告警」，卻忽略了歷史資料的留存策略。AI 模型（尤其是 Lv.3 的剩餘壽命預測）需要長期、乾淨、可信賴的歷史資料才能持續進化，而歷史資料庫（Historian）的規劃品質，直接決定了未來能否回溯分析、能否重新訓練模型、能否通過稽核。以下是幾個實務上建議優先確認的資料治理原則：

• 保留原始未經抽稀的資料：許多歷史資料庫預設會做「等間隔抽樣」以節省儲存空間，但這會讓瞬態異常（例如尖峰負載時的快速壓力波動）遺失。建議採用異常值觸發式記錄邏輯，在數值變化超過設定門檻時才記錄，兼顧儲存效率與資料完整性。
• 保留品質旗標（Quality Flag）：感測器訊號異常、通訊中斷等「壞資料」時段，往往正是故障前兆最明顯的時間點，不應該被視為無效資料而刪除，反而應標記後保留供後續分析。
• 統一時間戳與時區：跨系統整合時（尤其是感測層與 SCADA 分屬不同廠牌），時間同步誤差會讓多感測融合分析產生錯誤的因果推論，建議所有節點統一使用 NTP 校時。
• 資料保存年限：建議至少保留 2 年歷史資料，涵蓋至少一個完整的季節循環，特別是對於 HVAC、電力設備等具明顯季節性負載的場域。
• 標籤命名一致性：Edge 層正規化階段，應統一感測點位的命名規則，避免同一物理量測點在不同系統中有不同名稱，造成後續資料串接的額外工程成本。

1.6 資安框架——OT/IT 整合不能省略的一步

當感測資料開始從 OT（操作技術）網路流向 IT（資訊技術）網路的 AI 分析平台，攻擊面也隨之擴大。國際自動化學會（ISA）與國際電工委員會（IEC）共同制定的 IEC 62443 系列標準，是目前工業控制系統資安領域最廣泛採用的框架，其核心概念包括：

實務建議：感測層與 Edge 層的規劃階段，就應該邀請資訊安全團隊一起參與網路架構設計，而不是等系統上線後才補強資安措施。

1.7 取樣頻率與延遲需求對照表

不同應用情境對「多快要知道異常」的要求差異很大，過度追求最低延遲會墊高不必要的硬體成本，延遲需求設定過鬆又可能錯過關鍵的反應時間窗。以下提供概略對照，協助工程團隊在規劃階段設定合理的取樣頻率與延遲目標：

掌握這個對照關係，有助於避免「為了不需要的低延遲，投入過高的硬體成本」，或反過來「延遲設定過鬆，導致真正需要即時反應的安全連鎖場景來不及應變」。

1.8 延伸至其他物理量的整合可能性

雖然本文聚焦於壓力與溫度這兩項最基礎、應用最廣的物理量，但實務上，多數預測性維護專案在感測層擴充到一定規模後，往往會進一步納入液位、差壓等相關量測，形成更完整的資產健康監控網路。例如：儲槽或反應釜除了監測本體壓力與溫度，液位變化也是判斷洩漏或製程異常的重要指標；空壓機與過濾系統除了壓力監控，差壓數據更能直接反映濾網阻塞程度。由於這些物理量在 Edge/AI 架構中的資料處理邏輯高度相似（同樣是連續數位訊號、同樣需要正規化與異常偵測），建議在規劃感測層架構時，一併評估是否有液位、差壓等擴充需求，避免日後需要重新設計資料介接邏輯。

第三章：完整儀表清單與配置建議

本章依「感測層 → Edge 整合層」的實際需求，整理出五大應用場景的儀表配置建議。昶特 ATLANTIS 所有壓力／溫度儀表皆採報價制，實際型號、量程、材質與數量需依現場圖面與製程條件確認，以下配置僅供架構規劃參考。

閱讀以下表格時，建議搭配第一章的通訊協定說明與第三章末尾的選型檢查清單一起參考——同一個監測位置，往往有多種儀表類型都能滿足基本量測需求，真正的差異在於輸出介面是否符合現場既有系統、環境耐受性是否足夠，以及長期使用下的穩定度與維護便利性。

3.1 旋轉機械監控（幫浦、壓縮機、風車）

旋轉機械是多數工廠故障頻率最高的設備類型，軸承磨損、密封件老化、不平衡等問題，幾乎都會先反映在進出口壓差與機殼溫度的緩慢變化上。以下配置以「壓力+溫度雙訊號」為核心監測邏輯：

3.2 HVAC／空調系統與 BMS 整合

空調系統的異常往往與季節性負載高度相關，夏季滿載運轉時的冷媒壓力與送風溫度變化，是判斷冰水主機、空調箱是否需要提前維護的關鍵指標，同時也是最容易與既有 BMS 系統整合的應用場景之一：

3.3 製程反應釜與高風險環境

石化、化工等製程反應釜的監測需求最為嚴苛，除了壓力與溫度的即時準確度，防爆認證與耐腐蝕材質往往是選型的第一道門檻，配置時建議優先確認現場防爆區域等級與介質相容性：

3.4 電力設備監控（變壓器、開關站）

電力設備的故障往往牽動範圍最廣、影響最嚴重，變壓器油壓與繞組溫度的異常趨勢，通常是絕緣劣化的早期指標，建議與既有保護迴路並行監測，而非取代原有的安全保護機制：

3.5 壓縮空氣與公用系統

壓縮空氣系統的洩漏與效能衰退，是許多工廠長期被忽視的能耗黑洞，透過持續監測管路壓損與乾燥機露點趨勢，通常能在洩漏擴大前及早發現，同時作為能源管理績效的量化依據：

3.6 選型決策檢查清單

在正式送出詢價需求前，建議工程團隊先完成以下六項自我檢核，能大幅提升後續型號確認的效率，也能避免因為規格漏未確認而導致的交期延誤：

• ✅ 確認現場既有系統的通訊介面（4-20mA類比卡？RS-485？是否已有 HART Modem？）
• ✅ 確認環境條件：溫度範圍、是否防爆區、是否有腐蝕性介質
• ✅ 確認所需精度等級：一般監控用 ±1% FS 已足夠；早期異常偵測建議 ±0.5% FS 以上
• ✅ 確認取樣頻率需求：僅供巡檢比對 vs. 需連續上傳 Edge/AI 平台
• ✅ 確認校正週期規劃：依 ISO 17359／ISO 18436 建議，建立可稽核的校正紀錄
• ✅ 確認資料歷史留存需求：AI 模型訓練建議至少 2～4 週基準資料，季節性設備建議留存 1 年以上

3.7 常見選型錯誤案例

在協助客戶規劃感測層配置的過程中，以下幾種選型錯誤最為常見，提前避開可以省下不少後續返工成本：

所有型號皆採報價制，實際規格、量程與交期請透過 昶特 ATLANTIS 快速詢價表單 提供現場圖面與需求，將由業務工程團隊協助確認最終配置。

第五章：真實案例研究——從尖峰跳機到預測性維護

以下案例為求保護客戶隱私已完全匿名化，設施類型、規模與數據經過去識別化處理，僅保留具代表性的架構邏輯與改善幅度，供讀者參考規劃方向。

5.1 案例背景

個案為北台灣某精密製造廠的動力設備廠務區，廠內設有多組冰水主機、空壓機與變壓器，全廠 24 小時連續運轉。廠務團隊長期仰賴人工巡檢（每日 3 次固定巡檢路線），搭配傳統指針式壓力錶與雙金屬溫度計進行讀值記錄，SCADA 系統僅監控少數關鍵點位的固定閾值告警。

廠務團隊編制精簡，僅有 4 名輪班人員負責全廠動力設備的日常巡檢與維護，人力有限的情況下，異常訊號往往要等到巡檢時段才會被發現，若故障發生在巡檢間隔之間（尤其是夜間與假日），反應時間會被大幅拉長。這也是該廠務主管決定啟動感測層升級專案的主要動機——不是要取代人力，而是要讓有限的人力能更精準地聚焦在真正需要處理的異常上。

5.2 遭遇的問題

• ✅ 過去 12 個月內發生 4 次非計畫性停機，其中 2 次為空壓機軸承卡死，2 次為冰水主機冷媒系統異常
• ✅ 人工巡檢無法捕捉夜間與假日的異常趨勢，多起異常在巡檢間隔內快速惡化
• ✅ 傳統壓力錶精度不足，維護人員難以判斷「緩慢飄移」與「量測誤差」的差異，經常延遲反應
• ✅ 既有 SCADA 告警閾值設定過於寬鬆，多次異常在觸發告警前已造成設備損壞
• ✅ 缺乏歷史趨勢資料，每次故障後僅能事後歸因，無法建立預防機制

5.3 分階段導入方案（12個月）

值得留意的是，這五個階段並非完全依序進行，而是有部分重疊——第二階段的 Edge Gateway 建置，在第一階段感測層升級尚未全部完成時就已同步啟動；第四階段的 SCADA/CMMS 整合，也在第三階段模型驗證期間就開始進行介面規劃與測試環境建置。這種「重疊式」而非「接力式」的專案排程，是該廠務團隊能在 12 個月內完成整體導入的關鍵因素之一，也是多數成功案例的共同特徵：與其等每個階段完全結束才啟動下一階段，不如讓相鄰階段的準備工作提前交疊，縮短整體專案時程。

5.4 六個月後實際成效

系統於第六個月進入穩定運轉階段後，廠務團隊與資訊團隊共同針對四項核心指標進行前後比對，數據來自該廠內部的工單系統與 SCADA 歷史紀錄，以下呈現去識別化後的改善幅度：

5.5 投資與回收分析

依此案例的改善幅度換算，減少的非計畫性停機成本與產能損失，在 6～10 個月內即可回收感測層升級與 Edge/AI 整合的投資，後續每年持續產生穩定的停機成本節省效益。實際投資金額因現場儀表數量、Edge Gateway 規模與是否委外系統整合而異，昶特 ATLANTIS 的儀表部分採報價制，建議依實際點位數量另行確認。

5.5b 敏感度分析：不同故障頻率下的回收週期

投資回收週期高度取決於現場設備的歷史故障頻率——故障愈頻繁、單次停機損失愈高的場域，感測層升級的投報比通常愈明顯。以下提供概略的敏感度分析，協助評估不同情境下的合理預期：

這也呼應第三章「3.7 常見選型錯誤案例」與第四章「4.3 從單點監控到全廠資料骨幹的擴充路徑」的建議：優先從故障頻率高、停機損失大的設備開始導入，能讓有限的預算發揮最大效益。換句話說，投資決策的順序，應該是先盤點設備風險等級，再決定投入規模，而不是反過來先設定預算上限，才回頭挑選哪些設備「勉強」納入範圍——後者容易導致真正高風險的設備，反而因為預算排擠而被延後處理。

5.6 導入過程中的實際挑戰

這個案例並非一路順遂。前兩個月，廠務團隊發現部分新裝設的智慧型傳送器讀值與既有 SCADA 顯示值有些微落差，經排查後發現是既有系統的類比訊號轉換卡精度不足所致，而非新儀表本身問題——這也凸顯了感測層升級時，同步檢視訊號轉換與接線品質的重要性，否則再精準的儀表本體，也可能被上游的類比轉換環節拉低整體精度。第四個月進入異常偵測模型訓練階段時，團隊也經歷了約 3 週的「誤報磨合期」，透過與資深維護人員逐一核對告警事件，才將模型門檻調整到可信賴的水準。

5.7 案例啟示

這個案例最關鍵的轉折點，並不是導入了多先進的 AI 演算法，而是先把感測層的資料品質補齊。在感測層升級之前，就算裝上再好的 AI 分析平台，模型學到的也只是「巡檢頻率不足、精度不夠」所製造出來的雜訊。這也呼應了本文一開始的核心論點：預測性維護的成敗，往往決定於資料骨幹最底層的那顆壓力錶或溫度計，是否夠準、夠即時、夠穩定。同樣重要的是，技術導入從來不是一次到位的專案，而是「感測層升級 → 資料累積 → 模型磨合 → 流程優化」的持續循環，需要維護團隊、自動化工程師與資訊團隊三方持續協作。

第七章：延伸閱讀——相關技術指南

想更深入了解本文提到的各項技術環節，可參考以下昶特 ATLANTIS 其他技術指南：

• OPC UA 工業標準選型指南：智慧工廠數據整合核心架構解析 —— 深入了解 SCADA 與 AI 平台之間的資料整合標準
• 工業控制系統訊號整合：4-20mA 與 Modbus 差異解析 —— 感測層通訊介面選型的完整比較
• 數位溫度傳送器與 IoT 監測方案：從工業現場到智慧化管理的完整指南 —— 溫度感測層的深入選型建議
• 數位壓力錶完全選型指南：從傳統儀表升級到智慧監控方案 —— 壓力感測層升級的實務步驟
• AI 用電暴增後，變電站最常見的壓力監測設備完整指南 —— 電力基礎設施的壓力監控應用案例
• 溫度傳送器完整指南：從工業測量到食品製藥監控的精密解決方案 —— 跨產業溫度感測應用參考