生成式AI進入工廠後，壓力錶與溫度計會變成什麼？從感測器、PLC、SCADA 到 AI 異常偵測與預測維護的完整指南

昶特 ATLANTIS｜台灣 31 年工業儀錶製造商｜壓力錶、溫度計、壓力傳送器、溫度傳送器完整選型知識庫

本文目錄

• 前言：為什麼「AI 進廠」的第一個問題是儀錶，而不是模型
• 第 1 章　六層資料鏈：感測器 → PLC → SCADA → AI → 異常偵測 → 預測維護
• 第 2 章　壓力錶與溫度計的角色轉變：從「看」到「被讀取」
• 第 3 章　感測層選型：類比、HART、RS-485 與藍牙如何取捨
• 第 4 章　PLC 與 SCADA：資料怎麼從現場走到畫面（含範例程式 1～3）
• 第 5 章　生成式 AI 在工廠的真實定位（含範例程式 4）
• 第 6 章　異常偵測：從門檻警報到機器學習（含範例程式 5～6）
• 第 7 章　預測維護：儀錶漂移、校正週期與剩餘壽命（含範例程式 7～8）
• 第 8 章　三個情境案例與效益推估
• 第 9 章　90 天導入路線圖與常見的十個坑
• 第 10 章　OT 資安與責任邊界
• 第 11 章　20 個常見問題（FAQ）
• 第 12 章　延伸閱讀與相關資源
• 結論與聯絡方式

第 1 章　六層資料鏈：感測器 → PLC → SCADA → AI → 異常偵測 → 預測維護

談「AI 進廠」最容易犯的錯，是把它想成一個單一的系統。實際上，從現場一支壓力錶到管理者手機上的一則維護提醒，中間至少經過六個層次。每一層有不同的責任、不同的技術語言，也由不同的團隊負責。看懂這六層，才知道自己的專案卡在哪裡、該找誰、該買什麼。

表 1-1　六層資料鏈的責任分工與關鍵產出

1.1　「垃圾進，垃圾出」在儀錶層最致命

在資料科學領域，「垃圾進、垃圾出」是老生常談，但在工廠現場它有更具體的樣貌。一支量程選得太大的壓力傳送器，在正常操作壓力只有滿量程 15% 時，解析度與精度都被犧牲，AI 看到的其實是被量化噪聲放大的雜訊。一支安裝在死角、受環境溫度影響劇烈的溫度計，AI 學到的則是廠房空調的日夜變化，而不是製程本身。這些錯誤，後段的任何演算法都無法救回來。

所以我們主張：AI 專案的第一筆預算，應該先投在「量測品質稽核」上。盤點哪些測點值得被 AI 使用、它們的量程與精度是否匹配、有沒有校正紀錄、安裝方式是否合理。這件事看起來不像 AI，卻是整個專案成功率最高的投資。

1.2　OT 與 IT 兩種語言

六層資料鏈裡，前三層屬於 OT（營運技術）領域，後三層屬於 IT（資訊技術）領域。OT 人員講的是 4-20 mA、隔離、接地、防爆等級、掃描週期；IT 人員講的是 API、資料表、模型、雲端與延遲。兩邊都沒有錯，但常常彼此聽不懂。一個好的 AI 專案，會刻意安排一位「翻譯者」，通常是熟悉 PLC 與 SCADA 的自動化工程師，他能把「這支壓力傳送器輸出 4-20 mA、量程 0-10 bar、精度 ±0.5%」翻譯成「這個欄位的解析度、極限與可信區間」。

第 4 章　PLC 與 SCADA：資料怎麼從現場走到畫面

當傳送器把壓力或溫度轉成 4-20 mA，接下來進入 PLC 的類比輸入模組。這一段看似陽春，卻是資料鏈中最常出現「小錯誤、大後果」的地方。換算公式寫錯、濾波參數不恰當、掃描週期與記錄週期不一致，都會讓 AI 拿到的資料與現場實況產生落差。

4.1　類比訊號到工程值：換算公式與斷線判斷

4-20 mA 訊號進入 PLC 後，會被 A/D 轉換成整數計數值，例如 12 位元模組的 0～4095，或是廠牌自訂的 0～27648。工程師需要把這個計數值換算成工程單位，例如 bar 或 °C。線性換算公式為：

工程值 = (原始值 − 原始下限) ÷ (原始上限 − 原始下限) × (量程上限 − 量程下限) + 量程下限

此外，4-20 mA 迴路的優勢之一，是「4 mA 為活零點」。當電流低於約 3.6 mA，通常代表斷線或感測器故障；高於約 21 mA，則可能是超量程或短路。好的 PLC 程式一定會為每個類比點加上故障判斷，並把狀態位元一併送到 SCADA，AI 才能知道「這筆數據是不是有效」。下面是一段以結構化文本（Structured Text，IEC 61131-3）撰寫的通用換算範例。

(* ===== 通用 IEC 61131-3 結構化文本範例 ===== *)
            (* 用途：把 4-20 mA 對應的原始計數值換算成 bar，並產生品質旗標 *)
            (* 注意：原始計數範圍依 PLC 模組而異，請依廠牌手冊修改 RAW_MIN / RAW_MAX *)
            VAR_INPUT
                raw_value : INT;          (* 類比輸入模組的原始計數值 *)
            END_VAR
            VAR CONSTANT
                RAW_MIN   : REAL := 0.0;      (* 4 mA 對應的原始值，依模組調整 *)
                RAW_MAX   : REAL := 27648.0;  (* 20 mA 對應的原始值，依模組調整 *)
                ENG_LOW   : REAL := 0.0;      (* 量程下限 bar *)
                ENG_HIGH  : REAL := 10.0;     (* 量程上限 bar，須與傳送器量程一致 *)
                FAULT_LOW : REAL := -1000.0;  (* 低於此原始值視為斷線 *)
                FAULT_HIGH: REAL := 29000.0;  (* 高於此原始值視為超量程或短路 *)
            END_VAR
            VAR_OUTPUT
                pressure_bar : REAL;      (* 換算後的工程值 *)
                sensor_ok    : BOOL;      (* TRUE 表示資料有效，需一併送給 SCADA *)
                wire_break   : BOOL;
                over_range   : BOOL;
            END_VAR
            VAR
                raw_r : REAL;
            END_VAR
            raw_r := INT_TO_REAL(raw_value);
            wire_break := raw_r < FAULT_LOW;
            over_range := raw_r > FAULT_HIGH;
            sensor_ok  := NOT (wire_break OR over_range);
            IF sensor_ok THEN
                pressure_bar := (raw_r - RAW_MIN) / (RAW_MAX - RAW_MIN)
                                * (ENG_HIGH - ENG_LOW) + ENG_LOW;
            ELSE
                pressure_bar := 0.0;      (* 無效時不要輸出看似合理的數值，並保留 sensor_ok 供上層判斷 *)
            END_IF;

4.2　通訊協定：Modbus、OPC UA 與其他選項

PLC 與 SCADA 之間，以及 SCADA 與上層 AI 系統之間，需要選擇通訊協定。在台灣工廠最常遇到的是 Modbus（RTU 與 TCP）與 OPC UA，其次是各家 PLC 的原生協定。選擇的核心原則是「開放性」與「語意完整」：Modbus 簡單、普及、容易實作，但只傳遞暫存器數值，缺少單位與描述；OPC UA 則能提供資料模型、單位、時間戳記與安全機制，較適合作為 OT 與 IT 之間的標準介面。

表 4-1　常見通訊協定在 AI 專案中的適用性

4.3　邊緣閘道：把儀錶資料安全地送出現場

在不想動到既有 PLC 程式的情況下，許多專案會在現場加裝一台邊緣閘道（工業電腦或嵌入式盒子），以 RS-485 直接輪詢支援 Modbus 的儀錶，並將資料轉發給上層。這種做法的好處是「旁路採集」：不影響原本的控制迴路，風險最低，也最容易做試點。下面是一段以 Python 與 pymodbus 撰寫的參考範例，示範如何輪詢一台支援 Modbus RTU 的儀錶，並輸出帶有時間戳記與品質旗標的資料。

# ===== 檔案名稱：modbus_poller.py =====
            # ===== 執行環境：工業電腦 / 邊緣閘道，Python 3.9+，pip install pymodbus =====
            # 說明：暫存器位址、資料型態與位元組順序「因儀錶型號而異」，
            #       請以該型號的 Modbus 位址表為準，以下位址僅為示意。
            import time
            import json
            import struct
            from datetime import datetime, timezone
            from pymodbus.client import ModbusSerialClient
            # ---------- 設定區 ----------
            PORT      = "/dev/ttyUSB0"     # RS-485 轉 USB 裝置
            BAUDRATE  = 9600
            PARITY    = "N"
            STOPBITS  = 1
            BYTESIZE  = 8
            POLL_SEC  = 5                  # 輪詢週期（秒）
            DEVICES = [
                # id：Modbus 從站位址；reg：起始暫存器（示意）；tag：測點名稱；unit：單位
                {"slave": 1, "reg": 0, "tag": "P-101_pump_outlet", "unit": "bar"},
                {"slave": 2, "reg": 0, "tag": "T-201_cw_return",   "unit": "degC"},
            ]
            def regs_to_float(high, low):
                """把兩個 16 位元暫存器組成 32 位元浮點數（大端序，須依型號確認）"""
                raw = struct.pack(">HH", high, low)
                return struct.unpack(">f", raw)[0]
            def read_device(client, dev):
                rr = client.read_holding_registers(dev["reg"], count=2, slave=dev["slave"])
                if rr.isError():
                    return {"tag": dev["tag"], "value": None, "quality": "BAD"}
                value = regs_to_float(rr.registers[0], rr.registers[1])
                return {"tag": dev["tag"], "value": round(value, 4),
                        "unit": dev["unit"], "quality": "GOOD"}
            def main():
                client = ModbusSerialClient(port=PORT, baudrate=BAUDRATE, parity=PARITY,
                                            stopbits=STOPBITS, bytesize=BYTESIZE, timeout=1)
                if not client.connect():
                    raise SystemExit("無法開啟序列埠，請檢查接線與埠號")
                try:
                    while True:
                        ts = datetime.now(timezone.utc).isoformat()
                        for dev in DEVICES:
                            record = read_device(client, dev)
                            record["ts"] = ts
                            print(json.dumps(record, ensure_ascii=False))
                            # 這裡可改為寫入本機資料庫或轉發給上層系統（由客戶自行規劃）
                        time.sleep(POLL_SEC)
                finally:
                    client.close()
            if __name__ == "__main__":
                main()

4.4　SCADA 的三個資料管理重點

SCADA 通常是工廠第一個真正「留存」歷史資料的系統，也是 AI 專案最主要的資料來源。與其急著另建一套資料平台，不如先把 SCADA 的資料管理做好。以下三個重點特別影響後續 AI 的表現。

重點一：標籤命名規則。一致的命名能讓 AI 與工程師一眼看出測點的物理意義。建議採用「區域-設備-測點類型-編號」的結構，例如 UTL-CH01-PT-001 代表公用系統、冰水主機 1 號、壓力測點 001。命名規則看似瑣碎，但當測點超過一千個時，它是資料能否被自動化處理的關鍵。

重點二：記錄策略。歷史庫常採用「變化才記錄」（死區壓縮）以節省空間，但對 AI 而言，不規則的時間間隔會增加處理難度。建議關鍵測點採固定週期記錄，例如每秒或每 5 秒，並保留原始未壓縮資料至少 90 天，供模型訓練與驗證。

重點三：警報與事件分離。SCADA 的警報事件（誰在何時確認、如何處置）是極為珍貴的「標籤資料」，代表人類專家對異常的判斷。把警報事件與時序資料一起保存，未來才有機會訓練出真正有用的異常分類模型。

接著，我們示範如何從 SCADA 常見的 OPC UA 介面讀取資料。以下範例使用開源的 Python 套件 asyncua，展示讀取節點值與時間戳記的最小流程。實際的節點識別碼、驗證與憑證設定，須依貴廠 SCADA 而定。

# ===== 檔案名稱：opcua_reader.py =====
            # ===== 執行環境：Python 3.9+，pip install asyncua =====
            # 說明：端點網址、節點 ID、安全模式均為示意，請依貴廠 SCADA 設定修改。
            #       正式環境務必啟用憑證與帳號驗證，並限制為唯讀帳號。
            import asyncio
            from asyncua import Client
            ENDPOINT = "opc.tcp://192.168.10.20:4840"     # 示意位址
            NODES = {
                "UTL-CH01-PT-001": "ns=2;s=UTL.CH01.PT001.PV",
                "UTL-CH01-TT-001": "ns=2;s=UTL.CH01.TT001.PV",
            }
            async def read_once():
                async with Client(url=ENDPOINT) as client:
                    for tag, node_id in NODES.items():
                        node = client.get_node(node_id)
                        dv = await node.read_data_value()          # 含值、狀態碼與時間戳記
                        print({
                            "tag": tag,
                            "value": dv.Value.Value,
                            "status": str(dv.StatusCode),
                            "source_ts": dv.SourceTimestamp.isoformat() if dv.SourceTimestamp else None,
                        })
            if __name__ == "__main__":
                asyncio.run(read_once())

第 6 章　異常偵測：從門檻警報到機器學習

異常偵測是資料鏈中最能立即展現價值的一環，也是預測維護的前哨站。它的目標很單純：在人來不及發現、或傳統門檻不會觸發的時候，先一步提醒「有東西不太對勁」。好的異常偵測不是追求最先進的演算法，而是追求「現場人員願意相信」。一個每天誤報二十次的系統，第三天就會被靜音。

6.1　異常偵測的四個層級

表 6-1　異常偵測方法由簡入深

建議的路徑是「由下往上、逐層加碼」：先確保 L1 門檻完整可靠，再導入 L2 統計方法處理緩慢劣化，最後才在有明確需求時導入 L3、L4。許多專案花大錢做了 L4，卻連 L1 的門檻設定都不合理，是本末倒置。

6.2　L2 實作：EWMA 與滾動 Z 分數

指數加權移動平均（EWMA）是製程管制中歷史悠久的方法，對小幅度、持續性的偏移特別敏感，很適合用來抓「壓力慢慢往下掉」或「溫度慢慢往上爬」這類緩慢異常。搭配滾動 Z 分數，可以快速判斷當前值相對於近期正常區間的偏離程度。以下範例使用 pandas 實作，並加入「連續 N 點超標才觸發」的機制，有效降低誤報。

# ===== 檔案名稱：rolling_anomaly.py =====
            # ===== 執行環境：Python 3.9+，pip install pandas numpy =====
            import numpy as np
            import pandas as pd
            def detect_anomaly(df, value_col="value", window=360, z_thresh=3.5,
                               ewma_span=60, consecutive=5):
                """
                df 需含 'ts'（時間）與 value_col、'quality' 欄位。
                window：計算基準的滾動視窗筆數（例如 5 秒一筆，360 筆約 30 分鐘）
                consecutive：連續超標多少點才發出警報，降低瞬間雜訊造成的誤報
                """
                df = df.copy()
                df = df[df["quality"] == "GOOD"]              # 只用品質良好的資料
                df = df.sort_values("ts").reset_index(drop=True)
                roll_mean = df[value_col].rolling(window, min_periods=window // 2).mean()
                roll_std  = df[value_col].rolling(window, min_periods=window // 2).std()
                df["z"] = (df[value_col] - roll_mean) / roll_std.replace(0, np.nan)
                df["ewma"] = df[value_col].ewm(span=ewma_span, adjust=False).mean()
                df["ewma_dev"] = df["ewma"] - roll_mean       # EWMA 相對基準的偏移
                df["out_of_band"] = df["z"].abs() > z_thresh
                # 連續 N 點皆超標才視為異常
                df["alarm"] = (
                    df["out_of_band"]
                    .rolling(consecutive)
                    .apply(lambda x: 1.0 if x.all() else 0.0, raw=True)
                    .fillna(0) > 0
                )
                return df
            if __name__ == "__main__":
                rng = np.random.default_rng(42)
                n = 2000
                base = 5.95 + rng.normal(0, 0.03, n)
                base[1500:] -= np.linspace(0, 0.6, n - 1500)   # 模擬 1500 點之後壓力緩慢下降
                df = pd.DataFrame({
                    "ts": pd.date_range("2026-09-01", periods=n, freq="5s"),
                    "value": base,
                    "quality": "GOOD",
                })
                out = detect_anomaly(df)
                first = out[out["alarm"]].head(1)
                print("首次異常警報：", first[["ts", "value", "z"]].to_string(index=False)
                      if not first.empty else "未偵測到異常")

6.3　L3 實作：多變數的 Isolation Forest

許多故障的徵兆不在單一變數，而在變數之間的「關係」。例如，泵浦出口壓力沒有超標、軸承溫度也沒超標，但兩者的組合和平常不一樣；又如冷卻水供回水溫差不變，但壓差悄悄變大。Isolation Forest 是一種常用的無監督異常偵測演算法，不需要故障標籤，只需要一段「大致正常」的訓練資料，就能對新資料給出異常分數。

# ===== 檔案名稱：multivar_isoforest.py =====
            # ===== 執行環境：Python 3.9+，pip install scikit-learn pandas numpy joblib =====
            import numpy as np
            import pandas as pd
            from sklearn.ensemble import IsolationForest
            from sklearn.preprocessing import StandardScaler
            from sklearn.pipeline import make_pipeline
            FEATURES = ["p_out_bar", "p_in_bar", "t_supply_c", "t_return_c"]
            def add_features(df):
                """加入有物理意義的衍生特徵，通常比原始值更能抓到異常"""
                df = df.copy()
                df["dp_bar"] = df["p_out_bar"] - df["p_in_bar"]          # 泵浦揚壓
                df["dt_c"]   = df["t_return_c"] - df["t_supply_c"]       # 供回水溫差
                return df
            def train(df_normal, contamination=0.01):
                df = add_features(df_normal)
                cols = FEATURES + ["dp_bar", "dt_c"]
                model = make_pipeline(
                    StandardScaler(),
                    IsolationForest(n_estimators=200, contamination=contamination,
                                    random_state=0)
                )
                model.fit(df[cols])
                return model, cols
            def score(model, cols, df_new):
                df = add_features(df_new)
                # decision_function 越低越異常；轉成 0~1 的異常分數方便分級
                raw = model.decision_function(df[cols])
                df["anomaly_score"] = 1 / (1 + np.exp(raw * 10))
                df["level"] = pd.cut(df["anomaly_score"], [0, 0.55, 0.7, 1.0],
                                     labels=["NORMAL", "WATCH", "ALERT"])
                return df
            if __name__ == "__main__":
                rng = np.random.default_rng(7)
                n = 3000
                normal = pd.DataFrame({
                    "p_out_bar":  6.0 + rng.normal(0, 0.04, n),
                    "p_in_bar":   1.2 + rng.normal(0, 0.02, n),
                    "t_supply_c": 7.0 + rng.normal(0, 0.15, n),
                    "t_return_c": 12.0 + rng.normal(0, 0.20, n),
                })
                model, cols = train(normal)
                # 模擬異常：揚壓下降，同時回水溫差變大
                test = normal.tail(200).copy()
                test["p_out_bar"] -= 0.35
                test["t_return_c"] += 1.2
                result = score(model, cols, test)
                print(result["level"].value_counts())

6.4　降低誤報的五個實務技巧

第一，排除非正常工況：開機、停機、切換負載期間的資料，不應混入「正常」訓練集，否則模型會把啟停視為常態。第二，分工況建模：夏季與冬季、滿載與輕載的正常範圍不同，分開建模比混在一起更準。第三，連續確認機制：連續多點超標才發警報，過濾瞬間雜訊。第四，警報分級：將異常分成「觀察」與「警報」兩級，前者只記錄與通知，後者才通知值班人員。第五，建立回饋迴路：值班人員可在系統中標記「誤報」或「確認異常」，這些標記日後能用來調整門檻與訓練模型。

6.5　警報管理：把「異常分數」變成人能行動的事

異常偵測產生的是分數與旗標，但現場需要的是「該做什麼」。因此，警報管理的設計要和演算法同樣用心。建議把警報分成三級：資訊級只寫入記錄、供事後分析，不主動通知；注意級透過看板或訊息通知相關工程師，要求在當班內確認；警報級則通知值班人員並要求立即處置，同時附上建議的檢查步驟。每一則警報都應該包含五項資訊：發生什麼（現象）、在哪裡（測點與設備）、與正常相比差多少（量化）、儀錶是否可信（品質旗標與健康狀態）、建議先做什麼（檢查步驟）。

「儀錶是否可信」這一項尤其重要。當異常分數升高，但同一時間雙儀錶的差值也在擴大，系統應該優先提示「請先確認儀錶」，而不是宣告製程故障；反之，若兩支儀錶一致且趨勢同步，則可信度較高。這種「先排除儀錶問題」的邏輯，能大幅減少無謂的緊急處置，也讓現場人員逐漸建立對系統的信任。

另一個實務要點是警報的「抑制與關聯」。設備停機、切換、校正作業期間，相關測點的異常應被自動抑制；同一根因引發的一連串警報，應聚合成一個事件，而不是各自獨立通知。這類規則不需要複雜的 AI，只需要把生產排程與設備狀態納入邏輯，往往就能讓誤報數量減少一半以上。

表 6-2　警報分級與處置建議

第 8 章　三個情境案例與效益推估

案例一：北台灣某半導體廠的冰水主機房

背景。該廠廠務區有 4 台冰水主機、6 組冷卻水泵浦與數十個壓力與溫度測點。過去以每班巡檢加上固定門檻警報管理，曾發生過冷卻水泵浦劣化導致供水壓力緩降，在凌晨時段觸發低低壓連鎖，造成製程冷卻中斷的事件。

遭遇的問題。第一，壓力是緩慢下降而非突然掉落，固定門檻在最後一刻才動作；第二，部分測點量程選得過大（0～25 bar 卻只在 6 bar 附近操作），解析度不足；第三，儀錶的校正紀錄分散在紙本，無法判斷資料可信度；第四，警報事件與處置紀錄沒有數位化，難以事後分析。

解決方案。分三階段導入。第一階段（第 1～4 週）：盤點 60 個關鍵測點，將量程不合適者更換為 0～10 bar，並為重要測點採用 HART 智能型壓力傳送器；第二階段（第 5～10 週）：在 SCADA 建立固定週期記錄，導入 EWMA 與連續確認的異常偵測；第三階段（第 11～16 週）：建立泵浦壓力與溫差的多變數模型，並接入工單系統。

表 8-1　案例一：導入前後指標對照（情境推估）

投資回報（以比例與時間表達）。這類專案的效益主要來自「避免一次非計畫性停機」。半導體製程一次冷卻中斷的損失，通常遠高於整個儀錶升級與資料化專案的總投入。以避免每年 1 次事件推估，整體回本期間約落在 6～12 個月之間；若加計巡檢人力節省與備品優化，回本時間可能更短。實際數字需依貴廠損失評估而定。

案例二：中部某食品飲料廠的殺菌與熱水系統

背景。該廠有多條殺菌線與一座集中式熱水系統，溫度與壓力直接影響產品安全與能耗。原本靠雙金屬溫度計與機械式壓力錶現場指示，品質紀錄為手寫，每年稽核前需要大量整理文件。

遭遇的問題。殺菌溫度雖有紀錄，但缺少連續資料，稽核時難以證明每一批次都達標；熱水管線疏水閥失效造成蒸汽浪費卻無人察覺；溫度計的定期校正靠人工排程，曾發生逾期未校的情形。

解決方案。殺菌管線採用衛生型管路溫度傳送器並保留現場雙金屬溫度計作為交叉檢核；關鍵點以 RTD 搭配溫度傳送器取得高準確度資料；以數位壓力錶取代部分人工抄錄點；建立校正履歷資料庫並以前述漂移估算輔助排程。生成式 AI 則用於自動彙整批次溫度曲線與稽核報告草稿，由品保人員審核後定稿。

表 8-2　案例二：導入前後指標對照（情境推估）

投資回報。此案例效益來自三個面向：稽核與文件人力節省、疏水閥失效造成的熱能損失減少、以及避免不合格批次的風險。以保守估計，回本時間約落在 10～18 個月。值得注意的是，食品廠對「資料完整與可追溯」的價值，往往高於單純的節能。

案例三：南台灣某石化廠的防爆區壓力監測

背景。該廠有多座反應與儲存單元位於防爆區，過去以機械式壓力錶巡檢，巡檢人員需要進入危險區域抄錄，效率低且有人員安全風險。

遭遇的問題。巡檢頻率受限於人力與安全規範，壓力異常常在下一輪巡檢才被發現；區域內無法隨意加裝耗電或無線設備；歷史資料不足以支撐任何分析。

解決方案。在防爆區採用符合防爆規範的壓力傳送器，以 4-20 mA 搭配 HART 傳輸至控制室，保留原機械錶作為現場獨立指示；重要點位加入壓力趨勢與變化率警報；累積資料後，以統計模型建立各單元的正常操作包絡線。安裝與防爆認證須依當地法規與廠區規範執行。

表 8-3　案例三：導入前後指標對照（情境推估）

投資回報。石化廠的價值主要體現在「安全」與「風險降低」，這類效益難以完全金額化。若僅以巡檢人力與異常延遲造成的損失估算，回本時間約為 12～24 個月；若納入避免重大事故的風險價值，實質回報遠高於此。

第 12 章　延伸閱讀與相關資源

如果您想進一步了解昶特 ATLANTIS 在不同應用場景下的儀錶配置與選型思路，以下資源可以作為延伸閱讀。

• 石化反應器 Physical AI 完整指南：從邊緣運算到預測維護的儀錶配置
• BMS 壓力監測怎麼選？壓力變送器、壓力錶與差壓計完整選型指南
• 天然氣設備壓力監測與供氣安全技術指南
• 壓力錶選型精靈：依介質、量程與環境快速篩選
• 壓力傳送器選型精靈：輸出訊號、精度與防護等級對照
• 昶特 ATLANTIS 工業儀表完整產品目錄
• 昶特 ATLANTIS 品牌故事：31 年台灣工業儀錶製造經驗

圖說：ATLANTIS AT-PT186 智慧型壓力傳送器 — 通用工業壓力資料源

圖說：ATLANTIS ATT-P4/D4 管路型溫度傳送器 — 管線溫度資料化

圖說：ATLANTIS DPG-X002 高精度數位壓力錶 — 現場驗證與校驗參考