數位壓力錶 × MySQL × API × 數位孿生：IT／OT 整合與工業物聯網架構完整指南

第 1 章：整體架構——從現場儀表到數位孿生的五層模型

在討論 MySQL 表怎麼設計、API 怎麼寫之前，先把整條資料鏈切成清楚的層次。每一層只負責一件事，層與層之間用明確的介面溝通，這樣出問題時才知道往哪一層查，擴充時也不會牽一髮動全身。本文採用五層模型：儀表層、邊緣層、傳輸層、資料與 API 層、應用與孿生層。

1.1 五層模型總覽

[ 儀表層 ]  數位壓力錶 / 壓力傳送器 / 溫度 / 液位
     │  4–20mA · 0–10V · RS485 Modbus RTU · HART · 藍芽
     ▼
[ 邊緣層 ]  PLC / 遠端 I/O / Modbus 閘道器 / 工業電腦
     │  輪詢、換算工程單位、時間戳記、品質標記、緩衝
     ▼
[ 傳輸層 ]  MQTT / HTTPS / OPC UA（內網）／ VPN 或專線
     │  加密、重送、離線補傳
     ▼
[ 資料與 API 層 ]  MySQL（讀值、資產、校正、告警）＋ REST API
     │  驗證、授權、查詢、寫入、事件
     ▼
[ 應用與孿生層 ]  儀表板 · 告警通知 · 數位孿生模型 · 分析與預測

這張表有一個重點：昶特 ATLANTIS 的責任集中在第一層。我們確保儀表本身的量測原理、精度、材質、防護等級與輸出介面符合現場需求。從第二層開始，是客戶自己的系統與團隊，我們不提供雲端平台或 AWS 整合服務。這個邊界必須在專案初期就講清楚，避免後期因期待落差導致爭議。

1.2 與 Purdue 模型和 ISA-95 的對應

資安與自動化領域常用 Purdue 參考模型描述工廠網路分層，IEC 62443 也是以區域（Zone）與管道（Conduit）的觀念來設計防護。把本文的五層對應過去，可以幫助 IT 與 OT 用同一套語言討論邊界。

1.3 拉取（Pull）與推送（Push）：兩種資料流方式

資料從邊緣送到資料庫，基本上有兩種模式。拉取是資料庫端或應用端定期向邊緣設備要資料，推送是邊緣設備在有資料時主動送出。工業現場多半建議採用推送，原因在於資安與可靠度：推送模式只需要廠區網路對外開放「出站」連線，不需要在防火牆上開「入站」埠讓外部連進控制網路。

• 推送（建議）：邊緣閘道器以 MQTT 或 HTTPS POST 把批次讀值送往資料庫前端的接收服務。斷線時閘道器本地緩衝，連線恢復後補傳。
• 拉取（有條件使用）：僅限於同一個受控網段內，例如資料庫伺服器與閘道器同在 DMZ，由內部服務定期向閘道器查詢。
• 混合：即時告警用推送，歷史補齊用拉取。

1.4 資料量估算：先算清楚再選資料庫

很多專案在初期只接十幾個壓力點，覺得資料量很小，等到擴到數百個點才發現資料庫撐不住。先做一次粗估，可以提早決定要不要分區、降採樣或改用時序資料庫。下表以每筆讀值約 100 位元組（含索引的粗估）計算。

從表中可以看出，取樣週期對資料量的影響遠大於點位數。多數公用系統（冷卻水、壓縮空氣、空調）的壓力變化是分鐘等級，60 秒甚至 30 秒取樣已經足夠；只有泵浦起停、水錘、液壓脈動等快速事件才需要秒級以下的取樣，而且通常只在事件觸發時才高頻記錄。

1.5 為什麼從壓力開始，而不是一次接全廠

整合專案最常見的失敗模式，是範圍一開始就太大：想一次接全廠、所有參數、所有系統。結果是現場施工拖延、資料格式不一致、各系統責任不清，三個月後仍然沒有任何一張可用的儀表板。更務實的做法是選一個有明確痛點的公用系統，先打通「儀表到 API 到儀表板」的完整鏈路，驗證資料品質與團隊協作流程，再複製到下一個系統。

壓力量測適合當作起點，有四個原因。第一，壓力與流量、液位、洩漏、堵塞等現象有直接關係，一個壓力點往往能提供多重診斷資訊。第二，壓力儀表的介面標準化程度高，4–20mA 與 RS485 幾乎是通用語言。第三，單點成本與安裝複雜度相對低，試點風險小。第四，壓力異常通常有明確的工程判斷準則，容易設定第一批告警規則並看到成效。

1.6 第一個試點的建議範圍

第 3 章：MySQL 資料層——資料表設計、寫入策略與保存期限

MySQL 是許多企業最熟悉、最容易取得維運人力的資料庫。對於數百到數千個壓力點、分鐘到十秒級的取樣，MySQL 8 搭配良好的資料表設計與分區策略，完全可以勝任。本章的重點不是教您 SQL 語法，而是說明為什麼這樣設計，讓您能依自己的規模調整。

3.1 先決定：MySQL 夠用嗎？

在動手之前，先誠實評估資料庫選型。MySQL 是通用關聯式資料庫，不是時序資料庫，兩者各有適用範圍。

一個務實的做法是兩者並用：MySQL 保存資產主檔、儀表資訊、校正紀錄、告警事件等「關聯性強、量不大」的資料；讀值歷史若成長到 MySQL 吃力，再把歷史讀值搬到時序資料庫，API 層對外維持同一份介面，應用端不必改動。本文的資料表設計採用這個思路，讀值表與主檔表邊界清楚，日後要搬遷也容易。

3.2 資料表總覽

3.3 資產、儀表與點位：主檔設計

主檔設計決定了日後數位孿生能不能順利對應。核心觀念是把「資產」「儀表」「點位」三者分開：資產是工廠裡實際存在的東西（泵浦、過濾器、冷卻水主管），儀表是可被更換的量測設備，點位則是「某個資產上的某個量測意義」（泵浦出口壓力）。儀表壞了換新，點位與資產不變，歷史資料就不會斷。

CREATE TABLE assets (
  asset_id      INT UNSIGNED NOT NULL AUTO_INCREMENT,
  parent_id     INT UNSIGNED NULL,
  asset_code    VARCHAR(64)  NOT NULL,          -- 例：FAB1-CW-PUMP01
  name          VARCHAR(128) NOT NULL,
  asset_type    VARCHAR(32)  NOT NULL,          -- site / area / system / equipment
  PRIMARY KEY (asset_id),
  UNIQUE KEY uk_asset_code (asset_code),
  KEY idx_parent (parent_id),
  CONSTRAINT fk_asset_parent FOREIGN KEY (parent_id) REFERENCES assets(asset_id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

CREATE TABLE instruments (
  instrument_id INT UNSIGNED NOT NULL AUTO_INCREMENT,
  model         VARCHAR(64)  NOT NULL,
  serial_no     VARCHAR(64)  NOT NULL,
  range_min     DOUBLE NOT NULL,
  range_max     DOUBLE NOT NULL,
  range_unit    VARCHAR(16)  NOT NULL,          -- bar / kPa / mbar ...
  output_type   VARCHAR(32)  NOT NULL,          -- 4-20mA / RS485 / HART ...
  installed_at  DATE NULL,
  PRIMARY KEY (instrument_id),
  UNIQUE KEY uk_serial (model, serial_no)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

CREATE TABLE tags (
  tag_id        INT UNSIGNED NOT NULL AUTO_INCREMENT,
  tag_name      VARCHAR(96)  NOT NULL,          -- 例：FAB1.CW.PUMP01.DISCH_P
  asset_id      INT UNSIGNED NOT NULL,
  instrument_id INT UNSIGNED NULL,
  measure_type  VARCHAR(32)  NOT NULL,          -- pressure / diff_pressure / level / temp
  eng_unit      VARCHAR(16)  NOT NULL,
  scan_sec      SMALLINT UNSIGNED NOT NULL DEFAULT 60,
  lo_lo DOUBLE NULL, lo DOUBLE NULL, hi DOUBLE NULL, hi_hi DOUBLE NULL,
  deadband      DOUBLE NOT NULL DEFAULT 0,
  is_active     TINYINT(1) NOT NULL DEFAULT 1,
  PRIMARY KEY (tag_id),
  UNIQUE KEY uk_tag_name (tag_name),
  KEY idx_asset (asset_id),
  CONSTRAINT fk_tag_asset FOREIGN KEY (asset_id) REFERENCES assets(asset_id),
  CONSTRAINT fk_tag_inst  FOREIGN KEY (instrument_id) REFERENCES instruments(instrument_id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

點位命名建議採用固定層級的句點分隔，例如「廠區.系統.設備.量測意義」。命名規則在專案初期就要定案並文件化，否則三年後會出現「PUMP1_P」「Pump01Press」「泵浦一壓力」同時存在的混亂，任何跨系統分析都會變得痛苦。

3.4 讀值大表：readings 與分區

讀值表是整個資料庫最大、寫入最頻繁的表，設計上有三個重點：主鍵讓同一點位的時間序列在磁碟上相鄰、依時間分區方便清理、不使用外鍵（分區的 InnoDB 資料表不支援外鍵）。

CREATE TABLE readings (
  tag_id     INT UNSIGNED NOT NULL,
  ts         DATETIME(3)  NOT NULL,             -- 測量時間，UTC
  value      DOUBLE       NULL,                 -- 工程單位值
  raw_value  DOUBLE       NULL,                 -- 原始值（如 mA），可選
  quality    TINYINT UNSIGNED NOT NULL DEFAULT 0,
  recv_ts    DATETIME(3)  NOT NULL DEFAULT CURRENT_TIMESTAMP(3),
  PRIMARY KEY (tag_id, ts)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4
PARTITION BY RANGE COLUMNS (ts) (
  PARTITION p202610 VALUES LESS THAN ('2026-11-01'),
  PARTITION p202611 VALUES LESS THAN ('2026-12-01'),
  PARTITION p202612 VALUES LESS THAN ('2027-01-01'),
  PARTITION pmax    VALUES LESS THAN (MAXVALUE)
);

主鍵採用 (tag_id, ts) 的好處有兩個。其一，InnoDB 的叢集索引會依主鍵排序，同一點位的連續時間資料會物理上聚集，查詢「某點位過去 24 小時」時只需讀取連續的資料頁。其二，主鍵天然提供冪等性：同一點位同一時間戳記的資料不會重複寫入，網路重送造成的重複資料可以被安全地忽略或覆寫。

每月建立一個分區，預先建立未來數個月的分區，並用排程在月底前新增下一個月、刪除超過保存期限的舊分區。刪除分區（DROP PARTITION）幾乎是瞬間完成，遠比對大表執行 DELETE 快，也不會產生大量交易日誌與碎片。

3.5 寫入策略：批次、冪等與背壓

逐筆 INSERT 是效能殺手。每一筆都要經過網路往返、解析、交易提交，數百個點位每十秒各寫一筆，就會讓資料庫忙於處理大量微小交易。正確做法是邊緣端或接收服務累積一小批（例如 500 到 5,000 筆）再一次寫入，使用多值 INSERT 或載入檔案方式。

INSERT INTO readings (tag_id, ts, value, raw_value, quality)
VALUES
  (101, '2026-10-28 03:10:00.000', 4.82, 12.51, 0),
  (102, '2026-10-28 03:10:00.000', 5.01, 12.82, 0),
  (103, '2026-10-28 03:10:00.000', NULL, 2.90, 3)
ON DUPLICATE KEY UPDATE
  value = VALUES(value), raw_value = VALUES(raw_value), quality = VALUES(quality);

其中第三筆示範了品質不良的資料：電流 2.90 mA 低於 3.6 mA，判定為感測器故障，value 留空、品質設為 3。這樣既保留了「當時發生過故障」的證據，也不會讓錯誤數值污染統計。

• 冪等：靠主鍵與 ON DUPLICATE KEY UPDATE，讓補傳與重送都是安全的。
• 背壓：當資料庫繁忙時，接收服務應回應「稍後再試」，邊緣端依指數退避重送並持續本地緩衝，而不是無限制地堆積。
• 死信區：格式錯誤或未知點位的資料不要丟棄，寫入 ingest_errors 供事後排查。
• 交易大小：單一批次不宜過大，避免長時間持有鎖與產生過大的複寫延遲。

3.6 最新值表與快速查詢

儀表板最常見的查詢是「每個點位現在是多少」。如果每次都去大表裡找最後一筆，成本會隨資料量上升。解法是另外維護一張固定列數的 tag_latest，每次批次寫入後順便更新。

CREATE TABLE tag_latest (
  tag_id   INT UNSIGNED NOT NULL,
  ts       DATETIME(3)  NOT NULL,
  value    DOUBLE NULL,
  quality  TINYINT UNSIGNED NOT NULL,
  PRIMARY KEY (tag_id)
) ENGINE=InnoDB;

INSERT INTO tag_latest (tag_id, ts, value, quality)
VALUES (101, '2026-10-28 03:10:00.000', 4.82, 0)
ON DUPLICATE KEY UPDATE
  ts = IF(VALUES(ts) >= ts, VALUES(ts), ts),
  value = IF(VALUES(ts) >= ts, VALUES(value), value),
  quality = IF(VALUES(ts) >= ts, VALUES(quality), quality);

這段語法特別處理了「補傳舊資料不應覆蓋較新的最新值」的情況：只有新資料的時間戳記不早於現有值時才更新。這是邊緣端斷線重連後最常見的資料錯亂來源之一。

3.7 降採樣：分鐘級彙總表

原始高頻資料只需保存較短期間，長期趨勢分析使用彙總即可。建議以排程每分鐘或每五分鐘，把已完成的時間區段彙總到 readings_1min。

CREATE TABLE readings_1min (
  tag_id  INT UNSIGNED NOT NULL,
  bucket  DATETIME     NOT NULL,                -- 分鐘起點，UTC
  avg_v   DOUBLE NULL, min_v DOUBLE NULL, max_v DOUBLE NULL,
  n_good  SMALLINT UNSIGNED NOT NULL,
  n_bad   SMALLINT UNSIGNED NOT NULL,
  PRIMARY KEY (tag_id, bucket)
) ENGINE=InnoDB;

INSERT INTO readings_1min (tag_id, bucket, avg_v, min_v, max_v, n_good, n_bad)
SELECT tag_id,
       DATE_FORMAT(ts, '%Y-%m-%d %H:%i:00') AS bucket,
       AVG(IF(quality = 0, value, NULL)),
       MIN(IF(quality = 0, value, NULL)),
       MAX(IF(quality = 0, value, NULL)),
       SUM(quality = 0), SUM(quality <> 0)
FROM readings
WHERE ts >= '2026-10-28 03:00:00' AND ts < '2026-10-28 03:05:00'
GROUP BY tag_id, bucket
ON DUPLICATE KEY UPDATE
  avg_v = VALUES(avg_v), min_v = VALUES(min_v), max_v = VALUES(max_v),
  n_good = VALUES(n_good), n_bad = VALUES(n_bad);

彙總時只計算品質良好的資料，同時記錄良好與不良筆數，讓使用者能判斷這一分鐘的平均值有多少可信度。最大值與最小值不可省略：平均值會抹平瞬間的壓力尖峰，而尖峰往往正是設備損傷與製程異常的關鍵證據。

3.8 常用查詢範例

以下三個查詢涵蓋了最常見的分析需求：趨勢、變化率與疑似卡值。

-- (1) 某點位最近 24 小時，每 5 分鐘一個點
SELECT FROM_UNIXTIME(FLOOR(UNIX_TIMESTAMP(ts)/300)*300) AS t5,
       AVG(value) AS avg_v, MIN(value) AS min_v, MAX(value) AS max_v
FROM readings
WHERE tag_id = 101 AND quality = 0
  AND ts >= UTC_TIMESTAMP() - INTERVAL 24 HOUR
GROUP BY t5 ORDER BY t5;

-- (2) 壓力變化率：與前一筆相比每秒變化多少（MySQL 8 視窗函式）
SELECT ts, value,
       (value - LAG(value) OVER w) /
       NULLIF(TIMESTAMPDIFF(MICROSECOND, LAG(ts) OVER w, ts) / 1000000, 0) AS dp_per_sec
FROM readings
WHERE tag_id = 101 AND ts >= UTC_TIMESTAMP() - INTERVAL 1 HOUR
WINDOW w AS (ORDER BY ts);

-- (3) 疑似卡值：最近 30 分鐘數值完全沒變
SELECT tag_id
FROM readings
WHERE ts >= UTC_TIMESTAMP() - INTERVAL 30 MINUTE AND quality = 0
GROUP BY tag_id
HAVING COUNT(*) >= 20 AND MIN(value) = MAX(value);

注意第一個查詢的 FROM_UNIXTIME 會依資料庫連線時區轉換，建議連線時固定設定為 UTC，避免顯示層與資料層的時區混淆。

3.9 保存期限與容量規劃

若所屬產業有法規要求資料完整性與保存年限（例如製藥、食品、潔淨室），保存策略應先與品保單位確認，再決定彙總與刪除規則。刪除資料之前，務必確認已備份，且彙總結果已驗證正確。

第 5 章：數位孿生——把壓力資料變成可推演的資產模型

「數位孿生」是近年被過度使用的詞，從簡單的 3D 看板到複雜的物理模擬都自稱孿生。對工程師而言，與其爭論定義，不如問一個實際的問題：這個模型能不能回答「接下來會發生什麼」與「如果我這樣做會怎樣」？只能顯示「現在是多少」的，是儀表板；能比對「應該是多少」、「趨勢往哪走」、「改變條件會如何」的，才開始具備孿生的價值。本章以壓力資料為核心，說明如何循序漸進建立有用的資產模型。

5.1 孿生成熟度的四個階段

多數工廠現階段最有價值、風險也最低的目標是階段 2 到階段 3。階段 4 的「回寫控制」涉及製程安全，需要完整的功能安全評估與責任界定，不建議作為首批專案目標。本文的設計預設為唯讀架構：模型從現場取資料、產生建議，由人決定是否採取行動。

5.2 資產模型：用關係描述系統

孿生的骨架是資產之間的關係。冷卻水迴路不是一堆獨立的壓力點，而是「水源槽 → 泵浦 → 過濾器 → 主管 → 支管 → 負載 → 回水」這條有方向的路徑。把這種上下游關係存進資料庫，才能做到「下游壓力異常時，自動往上游找原因」。

CREATE TABLE asset_links (
  from_asset_id INT UNSIGNED NOT NULL,
  to_asset_id   INT UNSIGNED NOT NULL,
  link_type     VARCHAR(24)  NOT NULL,     -- FEEDS / RETURNS / CONTAINS / MEASURES
  PRIMARY KEY (from_asset_id, to_asset_id, link_type),
  KEY idx_to (to_asset_id)
) ENGINE=InnoDB;

有了這張關係表，API 可以提供「資產狀態」端點，把某個資產及其相關點位、告警、校正狀態彙整成一份文件，孿生模型與儀表板都用這份文件作為輸入：

GET /api/v1/assets/812/state

{
  "asset": { "id": 812, "code": "FAB1-CW-FILTER01", "type": "equipment" },
  "upstream":   [ { "id": 811, "code": "FAB1-CW-PUMP01" } ],
  "downstream": [ { "id": 813, "code": "FAB1-CW-HEADER" } ],
  "measurements": {
    "inlet_p":  { "value": 4.62, "unit": "bar", "quality": 0, "ts": "2026-10-28T03:10:00Z" },
    "outlet_p": { "value": 4.14, "unit": "bar", "quality": 0, "ts": "2026-10-28T03:10:00Z" },
    "delta_p":  { "value": 0.48, "unit": "bar", "derived": true }
  },
  "health": { "score": 82, "status": "WATCH", "reasons": ["delta_p_trend_rising"] },
  "calibration": { "due": "2027-03-15", "overdue": false },
  "alarms": []
}

注意 delta_p 是「衍生量」，由進出口兩個壓力點即時計算，而不是另外裝一個儀表。這是數位孿生很實用的特色：用已有的量測推算出沒有直接量測的量。但衍生量的品質取決於所有輸入的品質，只要任一個輸入品質不良，衍生量就必須標記為不可信。

5.3 預期值模型：先有「應該是多少」，才談得上異常

偵測異常的前提，是知道正常長什麼樣子。最簡單的預期值是固定門檻，但現實中壓力會隨運轉條件變化：泵浦轉速上升，出口壓力隨之變化；流量增加，過濾器壓差也會增加。固定門檻要不就過嚴造成誤報，要不就過鬆漏掉真正的異常。

以過濾器壓差為例，在紊流條件下，壓差大致與流量的平方成正比。要判斷濾網是否變髒，必須先把流量的影響扣掉，換算成「參考流量下的壓差」，才能公平比較不同時間的數據：

ΔP_norm = ΔP_measured × ( Q_ref / Q_measured )²

例：參考流量 Q_ref = 100 m³/h
    今日量測 ΔP = 0.48 bar，流量 Q = 90 m³/h
    ΔP_norm = 0.48 × (100/90)² ≈ 0.593 bar

若沒有流量量測，只能在相對穩定的運轉條件下比較，或使用泵浦轉速與其他壓力作為替代變數建立統計模型。這也說明了一個重要的整合觀念：孿生模型需要的不只是壓力，還有運轉條件，規劃儀表時要把流量、轉速、溫度一併納入考量。

5.4 趨勢外推：估算多久後會到達限值

濾網堵塞、結垢、泵浦磨耗都是漸進式劣化，壓力或壓差會緩慢單調地變化。對這類現象，最簡單也最實用的預測方法，是對正規化後的壓差做線性迴歸，外推何時會到達維護限值。

線性外推有明顯的限制：堵塞速度常常隨時間加速（越堵越快），所以應同時監控上升速率本身的變化，一旦發現斜率明顯變大，就要縮短預估時間。另外，預測應該附帶信賴區間，並在資料不足、品質不良比例偏高時，主動表示「無法預測」，而不是輸出一個看似精確的錯誤答案。

5.5 從規則到統計，再到機器學習

5.6 泵浦與管路：用壓力推算水頭與效率線索

在水系統中，壓力可以換算成水頭（以水柱高度表示），用來與泵浦特性曲線比對。對於水，1 bar 約等於 10.2 公尺水柱：

H（公尺水柱）= ΔP / (ρ × g)

水（ρ ≈ 1000 kg/m³，g ≈ 9.81 m/s²）：
1 bar = 100,000 Pa → H ≈ 100,000 / (1000 × 9.81) ≈ 10.2 m

泵浦出口壓力減去入口壓力，得到泵浦實際提供的揚程。若在相同轉速與流量下，揚程相比過去明顯下降，可能代表葉輪磨耗、內部洩漏或入口吸入條件不佳。入口壓力過低則要留意空蝕（Cavitation）風險，需要核對有效吸入水頭是否大於泵浦所需。這些判斷都只需要最基本的進出口壓力量測，卻能提供很高的診斷價值，這也是為什麼泵浦進出口永遠是壓力量測的優先點位。

5.7 孿生所需點位：用途決定量測

5.8 孿生的呈現：給人看的與給機器用的

孿生的呈現不需要華麗的 3D。工程師真正需要的，是能快速理解的資產狀態圖：用系統流程圖呈現上下游關係，每個節點用顏色表示健康狀態，點擊進入該資產的趨勢、告警與校正資訊。3D 模型在大型設施的導覽、空間定位與簡報展示上有價值，但不應先於資料品質與分析邏輯投入。同時，同一份資產狀態資料也應以機器可讀的 API 形式提供，讓維護管理系統（CMMS）、能源管理系統與報表系統能自動取用，避免資訊孤島。

最後要提醒的是，孿生模型本身也是需要維護的資產。儀表更換、管路改造、泵浦汰換，都必須同步更新資產關係與參數，否則模型會悄悄地與現場脫節。建議把「模型更新」納入工程變更管理流程，任何現場變更單都必須包含對孿生資料的檢視項目。

第 7 章：情境推演與效益評估方法

B2B 的導入決策最終都要回答一個問題：投入值不值得？本章提供一套不依賴單價、可由您自行代入數字的效益評估框架，並以三個推演情境說明資料鏈在不同場景下能帶來哪些改變。

7.1 效益的五個來源

7.2 評估公式

年度總效益 = 工時節省 + 停機損失減少 + 能源耗材節省 + 品質損失減少 + 稽核效率
年度總成本 = 儀表與周邊設備攤提 + 系統建置與維運 + 校正與維護
投資回收期（月）= 初期投入 ÷ （年度總效益 − 年度總成本）× 12
投資報酬率 = （年度總效益 − 年度總成本）÷ 初期投入

評估時有一個常見的偏誤：把所有效益都歸功於新系統。比較誠實的做法是只計入可以明確歸因的效益，並對不確定性高的項目（例如避免的停機）採保守估計，同時列出「悲觀、基準、樂觀」三種情境，讓決策者看到風險範圍。

7.2.1 工時節省的算法示範

工時節省是最容易量化、最少爭議的效益，建議作為評估的基礎。假設某廠區有 40 個機械壓力錶需要每日巡檢：

這 876 小時並不代表人力裁減，而是巡檢人員可以轉去做更有價值的事：處理告警、做預防保養、執行校正。把「節省的時間」轉化為「更高價值的工作」，才是這類導入真正的效益所在。

7.3 情境一：冷卻水迴路的壓力與壓差監測（推演）

情境背景：一個中型廠區的冷卻水系統，包含兩台並聯泵浦、一組過濾器、主管與六條支管，目前以機械壓力錶人工巡檢，每班記錄一次。

常見痛點：泵浦切換時的壓力瞬降不被記錄；過濾器壓差只在每週保養時才看；支管流量不均導致部分負載偏熱，但無法判斷源頭。

建議的資料鏈範圍：泵浦進出口各一點、過濾器前後各一點、主管一點、六條支管末端各一點，共約 15 點，取樣 30 秒，事件觸發時 1 秒。孿生層建立「泵浦到過濾器到主管到支管」的資產關係。

7.4 情境二：壓縮空氣系統的壓降與穩定度（推演）

情境背景：廠內壓縮空氣由多台空壓機供應，主管延伸到各產線，末端壓力不足時，產線氣動設備動作變慢或停頓。

常見痛點：空壓機出口壓力設定偏高以「保險」，造成耗能；各產線末端的壓降無人掌握；洩漏長期存在卻難以量化。

建議的資料鏈範圍：空壓機出口、儲氣槽、主管幹線數處、各產線入口末端，共約 12–20 點。這個情境的關鍵洞察是：壓力設定每降低一些，壓縮機耗能就會相應下降，但前提是末端壓力仍然穩定在需求之上。只有同時看見出口與末端壓力的長期資料，才敢放心調整設定值。

• 用壓降資料找出「主管瓶頸」：出口與末端壓差過大的區段，通常有管徑不足、過濾器堵塞或洩漏。
• 用夜間與假日的壓力下降速率估算洩漏：無生產期間壓力仍持續下降，代表系統存在洩漏。
• 用事件資料連結產線動作與壓力波動，找出突發大量用氣的設備。

7.5 情境三：潔淨室過濾器壓差與孿生預測（推演）

情境背景：潔淨室的風機過濾單元與高效率過濾器，需要維持房間與走廊之間的壓差級聯，濾網堵塞會影響風量與壓差。

建議的資料鏈範圍：各區與走廊的微差壓量測、主要過濾器前後差壓、搭配溫濕度，約 20–40 點。孿生層採用第 5 章的正規化壓差與趨勢外推，對每一組過濾器估算剩餘壽命，並把更換排程與生產排程整合，避免在關鍵批次期間被迫停機更換。

此情境對資料品質與稽核追溯的要求特別高：壓差紀錄常屬於品質文件，需要時間戳記可靠、資料不可竄改、告警與確認動作都有紀錄。因此 API 層的稽核紀錄與資料庫的備份策略，在這個情境下是必要條件而非加分項。

7.6 敏感度分析：哪些假設最影響結果

三個反思問題可以幫助您檢視評估是否紮實：第一，這項效益是否有可驗證的基線數據？第二，如果效益只達預期的一半，專案還值得做嗎？第三，誰負責在導入後持續追蹤這些指標？如果三個問題都答得出來，這份評估才經得起管理層的檢視。

第 9 章：20 個常見問題 FAQ

以下整理工程師、IT 團隊與採購在規劃數位壓力錶、MySQL、API 與數位孿生整合時最常提出的問題。點擊問題即可展開答案。