數位壓力錶怎麼接上 IoT 與數位孿生？從現場讀值到 AWS IoT TwinMaker 的完整選型與架構指南
昶特 ATLANTIS｜數位壓力錶 × IoT 物聯網 × AWS 數位孿生｜2026 年 10 月更新
給設備工程師、廠務、系統整合商與採購：先搞清楚「數位壓力錶」和「壓力傳送器」誰負責顯示、誰負責傳資料，再決定訊號、閘道、雲端服務與數位孿生要做到哪一層。
本文重點：1）數位壓力錶本身擅長現場高精度顯示與記錄，連續串流資料通常由壓力傳送器或具輸出訊號的型號負責；2）2026 年 AWS IoT Core、IoT SiteWise、IoT TwinMaker 與 Greengrass 的最新動態整理；3）三層配置方案、監測點矩陣與客戶自行串接的程式範例；4）20 則常見問題。
責任分界請先看清楚：昶特 ATLANTIS 專注於壓力、溫度、液位等量測儀表的研發與製造，並不提供 AWS 或其他雲端平台的整合服務。儀表如何接入貴公司的 PLC、閘道器、AWS 帳號與數位孿生系統，由客戶或貴公司的系統整合商自行規劃與實作；昶特負責協助確認儀表端的規格、輸出訊號與選型。
前言：為什麼搜尋「數位壓力錶」的人，開始問 IoT 與數位孿生
過去採購數位壓力錶，工程師關心的是三件事：精度夠不夠、量程對不對、接頭能不能鎖上去。這幾年問題變了。設備端的工程師開始被主管問：「這個壓力能不能在辦公室看到？」「過濾器壓差有沒有辦法提前預警？」「能不能把整條冷卻水迴路做成數位孿生，讓我們在模型裡看哪裡異常？」
這些需求背後有一個共同的現實：數位孿生不是軟體功能，而是資料品質的問題。一個沒有可靠即時資料的 3D 模型，只能叫做漂亮的展示。壓力又是流體系統中最基礎的狀態量，泵浦、過濾器、閥門、管路的健康狀況，幾乎都會先反映在壓力與壓差上。所以，當企業要做 IoT 或數位孿生，壓力量測往往是第一批要接上的資料點。
這就是本文要回答的問題：如果你的目標是讓數位壓力錶的資料進入雲端，甚至進入 AWS IoT TwinMaker 這類數位孿生平台，應該怎麼從儀表端開始設計？哪些事情儀表能做，哪些事情要靠閘道器、PLC 或雲端服務做？哪些選型錯誤，會在三個月後變成整合團隊的惡夢？
本文的寫作立場
昶特 ATLANTIS 是台灣工業儀錶製造商，已有 31 年的壓力錶、溫度計與傳送器製造經驗。本文以量測儀表端的角度出發，說明儀表選型如何影響後端 IoT 與數位孿生的成敗。AWS 的部分，我們整理的是 AWS 官方文件與公告中的技術事實，供工程師在規劃時對照；實際的雲端架構、帳號權限、費用與資安設計，需由貴公司的 IT 或系統整合商依自己的環境決定。
請特別注意：昶特 ATLANTIS 不提供 IoT 或 AWS 整合服務。客戶需要把儀表資料送進雲端，必須自行串接，或委託系統整合商處理。本文提供的程式碼僅為概念示範，用來幫助工程師理解資料流程，不是昶特的服務項目，也不構成對任何第三方平台相容性的保證。
三種常見的需求，其實是三種不同的專案
在實務上，搜尋「數位壓力錶 IoT」的客戶，大致可以分成三類，各自需要的儀表與架構差異很大。
- 第一類是巡檢與記錄需求：現場人員用數位壓力錶讀值，需要保存壓力記錄、匯出資料、事後追溯。這類需求不需要連續串流，重點是精度、記錄功能與藍芽或 Type-C 匯出。
- 第二類是遠端監控需求：控制室或辦公室需要即時看到壓力，異常時要警報。這類需求需要穩定的標準訊號輸出，典型做法是 4–20 mA 接 PLC，再由 PLC 或閘道器往上送。
- 第三類是數位孿生與預測性維護需求：不只要看到壓力，還要把壓力放進設備模型，跟溫度、液位、運轉狀態一起分析。這類需求最看重資料的時間戳記、品質標記、資產階層與長期穩定性。
三類需求的儀表選型邏輯完全不同。把第一類的產品拿去做第三類的事，是最常見的錯誤，也是為什麼本文要花一整章先講清楚系統架構。
第 1 章：數位壓力錶 × IoT × 數位孿生的五層系統架構
要把數位壓力錶的資料送進數位孿生，最清楚的方式是把整個系統拆成五層。每一層都有各自的責任，也各自會出問題。把層次分清楚，才知道問題發生時該找誰。
1.1 五層架構總覽
| 層級 | 名稱 | 主要元件 | 責任 | 常見失誤 |
|---|---|---|---|---|
| L1 | 量測層 | 數位壓力錶、壓力傳送器、溫度傳送器、液位傳送器 | 把壓力轉成可信的數值，並提供現場顯示 | 量程選太大、接液材質不符、未校正 |
| L2 | 訊號層 | 4–20 mA、0–10 V、HART、RS485 Modbus、藍芽、Type-C 匯出 | 把數值以標準方式送出 | 選了 PLC 不支援的訊號、沒有隔離與接地 |
| L3 | 邊緣層 | PLC、IoT 閘道器、工業 PC、Node-RED、AWS IoT Greengrass、IoT SiteWise Edge | 採集、轉換協定、緩衝、前處理 | 沒有離線緩衝、時間戳記不準、點位表亂 |
| L4 | 雲端層 | AWS IoT Core、IoT SiteWise、時序資料庫（如 Amazon Timestream for InfluxDB）、Amazon S3 | 安全接入、儲存、結構化、規則路由 | 憑證管理不當、訊息量失控、未做資料保存策略 |
| L5 | 呈現與孿生層 | AWS IoT TwinMaker、Amazon Managed Grafana、IoT App Kit | 把資料綁定到資產模型與 3D 場景，做視覺化與告警 | 先做模型後找資料，結果沒有資料可綁 |
昶特的專長在 L1 與 L2：確保儀表量得準、輸出得穩、型號與規格能對上現場。L3 到 L5 屬於客戶自己的系統工程範圍，但 L1 與 L2 的選型決定了後面三層的難度。一個典型的例子是：如果現場只裝了沒有輸出訊號的數位壓力錶，後面的閘道器再強，也無從採集連續資料。
1.2 數位壓力錶本身，能不能直接上雲？
這是客戶最常問、也最容易誤解的問題。答案要分型號來看。以昶特 DPG 系列為例，這個系列的定位是高精度的現場數位顯示，部分型號可同時顯示壓力、溫度、最大與最小值，也有型號支援藍芽與 Type-C 匯出記錄。這些功能讓它非常適合巡檢、校驗、測試與保存壓力記錄，但它的設計目標不是 24 小時連續串流到雲端。
如果需求是連續、無人值守、自動送資料，建議從具有標準訊號輸出的壓力傳送器開始評估，例如 4–20 mA、0–10 V、HART 或 RS485 輸出的型號。這類儀表的設計邏輯就是把壓力變成控制系統可以長期讀取的標準訊號。
簡單判斷法：只需要人看與保存記錄，選數位壓力錶；需要系統自動讀取，選有標準輸出的傳送器；兩者都要，就現場裝數位壓力錶做比對基準，管路上裝傳送器做資料來源。
實務上，很多成熟的工廠會同時使用兩種儀表：傳送器負責把資料送進系統，數位壓力錶放在旁邊當現場比對與校驗參考。當雲端上的數位孿生顯示 5.2 bar，而現場數位壓力錶顯示 5.0 bar，工程師立刻知道要檢查訊號鏈或校正。這個簡單的並聯設計，是防止「模型一直在騙人」的最便宜保險。
1.3 什麼才算數位孿生？別把儀表板當孿生
數位孿生這個詞被濫用得很嚴重，有必要先釐清。業界常把成熟度分成幾個層次。最基礎的是單向資料流：實體設備的資料送到數位模型上顯示，這比較像數位影子。更進一步，模型會用資料做分析與預測，並可能把結果回饋給實體系統，這才接近真正的孿生。
對壓力量測來說，這個差別很具體。只是把壓力曲線畫在畫面上，是監控。把壓力與泵浦曲線、過濾器壓差趨勢、閥門開度放在同一個資產模型裡，並且能回答「這個壓差上升速度，是否代表濾網還剩多少壽命」，這才是孿生要做的事。而要做到後者，儀表的長期穩定性、量測重複性、校正紀錄與時間戳記品質，都是不可省略的基礎。
有一句工程界常說的話值得記住：孿生的準確度，受限於它所吃進去的感測資料。資料不準，模型只會給出看起來很有自信的錯誤答案。這也是為什麼我們一再強調，數位孿生專案應該從量測層開始，而不是從 3D 模型開始。
1.4 AWS 相關服務的角色分工
AWS 在物聯網與數位孿生領域有一組彼此搭配的服務。以下整理的是各服務在這個架構裡的角色，內容依據 AWS 官方文件與公告，工程師在實際規劃時，請以 AWS 最新文件為準。
| 服務 | 角色 | 與壓力量測專案的關係 |
|---|---|---|
| AWS IoT Core | 讓裝置或閘道器以 MQTT 等協定安全連入 AWS，並透過規則把資料送往其他服務 | 閘道器把壓力資料以 MQTT 發佈到 IoT Core，是最常見的雲端入口 |
| AWS IoT Greengrass | 在邊緣端執行的軟體，可在本地處理資料、緩衝並與雲端同步 | 適合在現場閘道器上做前處理與離線緩衝 |
| AWS IoT SiteWise | 收集、儲存、組織與監控工業設備資料，支援資產模型 | 把壓力、溫度、液位組織成資產模型，並自動計算常用統計值 |
| AWS IoT SiteWise Edge | 把 SiteWise 的部分能力放到地端，可透過 OPC-UA、MQTT 等協定採集 | 在網路不穩或需要低延遲的廠區使用 |
| AWS IoT TwinMaker | 建立實體系統的數位孿生，把資料綁定到實體資產的虛擬表示與 3D 場景 | 把壓力資料呈現在管路、泵浦、過濾器的 3D 或 2D 模型上 |
| Amazon Managed Grafana | 提供營運儀表板，並可搭配 TwinMaker 與 SiteWise 外掛 | 把壓力曲線與 3D 場景放在同一畫面 |
1.5 2026 年 AWS IoT 的重要更新（依官方公告整理）
想把壓力資料送進 AWS 的團隊，2026 年有幾項更新值得留意。這些更新不會改變儀表選型，但會影響閘道器與雲端的設計，也讓整合團隊在除錯與維運上更容易。
| 時間 | 更新內容 | 對壓力量測專案的意義 |
|---|---|---|
| 2026 年 5 月 28 日 | AWS IoT Core 新增 GetConnection 與 ListSubscriptions 兩個 MQTT 連線管理 API | 閘道器連不上或訂閱異常時，可查詢連線狀態與訂閱清單，協助除錯 |
| 2026 年 5 月 28 日 | AWS IoT Core 支援 SendDirectMessage，可對已連線裝置做點對點訊息，並取得送達確認 | 遠端下達設定給閘道器時，可知道訊息是否真的送達 |
| 2026 年 6 月 3 日 | AWS IoT Core 新增 Ping 與 Connection.AuthNError 兩種 CloudWatch 日誌事件 | 更容易分辨是 Keep-alive 中斷，還是憑證與驗證問題 |
| 2026 年 6 月 25 日 | AWS IoT TwinMaker API 參考文件更新發佈 | 開發團隊規劃 workspace、entity、component 與 scene 時，需對照最新文件 |
| 2026 年 7 月 8 日 | AWS IoT Greengrass Core v2.18.0 發佈，支援切換核心裝置連接的 AWS 帳號或區域，並新增 Windows Server 2025 支援 | 閘道器資產搬遷或帳號整併時更方便 |
| 2026 年 8 月 25 日 | AWS IoT Core 新增 InfluxDB 規則動作，可把時序資料直接路由到 Amazon Timestream 或自建的 InfluxDB | 壓力這類時序資料可不寫自訂程式就進入時序資料庫 |
| 2026 年 10 月 7 日 | AWS IoT Greengrass V1 終止支援 | 仍在使用 V1 的閘道器，應規劃升級到 V2 |
此外還有幾項基礎事實，工程師規劃時常用得到。AWS IoT Core 的 MQTT 支援 3.1.1 與 5.0 兩個版本，QoS 支援等級 0 與 1，不支援等級 2。IoT SiteWise 閘道器支援 OPC-UA、Modbus TCP 與 EtherNet/IP 協定。Grafana 的 AWS IoT TwinMaker 外掛，官方文件要求使用 Grafana 10.4.0 或更新版本。
第 2 章：壓力資料的取樣、訊息量與品質設計
決定了架構之後，下一個問題是資料要怎麼送。很多專案在這一步出問題，不是因為技術不行，而是因為沒人認真算過：要多久取樣一次？每個點位一天會產生多少訊息？哪些資料值得送，哪些在邊緣端就該濾掉？
2.1 取樣頻率不是越高越好
取樣頻率的決定，應該來自你要用這筆資料做什麼，而不是來自儀表能提供多快的更新。壓力變化的時間尺度，跟系統類型有很大關係。
| 應用場景 | 壓力變化特性 | 建議上傳間隔 | 邊緣端處理建議 |
|---|---|---|---|
| 冷卻水與冰水迴路 | 緩慢變化，以趨勢為主 | 5 至 30 秒 | 設定死區，變化小於門檻時降低上傳頻率 |
| 泵浦進出口 | 啟停時有明顯暫態 | 1 至 5 秒，啟停期間可提高 | 偵測啟停事件，暫態期間才提高取樣 |
| 過濾器前後壓差 | 緩慢上升，趨勢比瞬間值重要 | 30 秒至數分鐘 | 在邊緣端計算壓差與移動平均 |
| 水槽、儲槽液位（以壓力換算） | 非常緩慢 | 1 至 5 分鐘 | 異常變化率才立即上傳 |
| 液壓系統 | 極快，含尖峰衝擊 | 不建議直接以雲端取樣捕捉尖峰 | 在本地用具峰值記錄功能的儀表或專用量測設備，雲端只收峰值與統計值 |
| 空壓機與氣體管路 | 隨負載起伏 | 1 至 10 秒 | 計算每小時最大、最小與平均後上傳 |
| 巡檢與校驗記錄 | 人工作業時產生 | 以事件或批次為單位 | 匯出記錄檔後批次匯入，並附上校正資訊 |
液壓系統那一列特別值得提醒。雲端傳輸的延遲與取樣頻率，本來就不適合捕捉毫秒級的壓力尖峰。如果要掌握尖峰，應該在現場端使用有峰值記錄功能的儀表或專用設備，再把峰值、發生時間與次數等整理後的資訊上傳。把原始高頻資料全部丟上雲端，通常只會得到巨量的費用與延遲，卻抓不到真正的尖峰。
2.2 訊息量要先估算，不要等帳單來才發現
在規劃階段，花五分鐘做一次簡單的算術，可以避免日後很多爭議。假設有 100 個壓力點位，每個點位每秒上傳 1 筆，每筆訊息大小為 200 位元組。
每日訊息數：100 點 × 86,400 秒 = 8,640,000 筆。每日資料量：8,640,000 筆 × 200 位元組 ≈ 1.73 GB。若改成每 10 秒上傳一次，訊息數與資料量都降為十分之一。若再加入死區設定，只在壓力變化超過門檻或每 60 秒保底上傳一次，實際訊息數通常可再大幅下降。
這個算術的重點不是精確數字，而是讓團隊意識到：取樣頻率、點位數與訊息大小三者相乘，決定了整體負載。把點位數乘上十，或把取樣頻率提高十倍，成本與複雜度都會等比放大。建議在設計初期就用試算表把這三個數字列出來，並與 IT 及財務一起確認。
2.3 邊緣端的三種資料減量技巧
- 死區與變化上報：壓力變化小於設定門檻時不上傳，但設一個保底週期，確保雲端知道儀表仍然在線。
- 邊緣聚合：在閘道器上計算一分鐘或五分鐘的平均、最大、最小與標準差，雲端只存聚合值。IoT SiteWise 本身也會自動計算常用的統計聚合，例如平均、總和與計數，可供儀表板直接使用。
- 事件觸發：偵測到啟停、超限、壓差快速上升等事件時，才提高取樣頻率並附上前後數秒的原始資料。
2.4 資料品質：時間戳記、品質標記與缺值
數位孿生最怕的是「看起來有資料，其實不可信」。要避免這種情況，至少要處理三件事。
第一是時間戳記。資料應該在採集端就打上時間，並確保閘道器的時鐘與網路時間同步。AWS IoT Greengrass 在 2026 年 7 月的更新中，也修正了 systemd 裝置啟動時序問題，讓軟體在系統時鐘同步之後才啟動，這正是時間可信度在邊緣裝置上的實際重要性。
第二是品質標記。感測器斷線、超量程、訊號異常時，應該明確標記資料品質，而不是送出一個看似正常的數字。IoT SiteWise 在 2025 年 1 月起支援 NULL 與 NaN 這類代表壞品質或不確定品質的資料，讓合規報告與分析不必把缺值偽裝成數字。
第三是中繼資料。每一筆壓力資料，最好能對應到儀表型號、序號、量程、最近一次校正日期與安裝位置。這些資訊不必隨每筆資料傳送，但應該存在資產模型裡。當數位孿生發現某個點位的漂移異常時，工程師需要立刻查到這支儀表上次什麼時候校正、用的是哪種標準器。
量測儀表的角色在這裡很清楚：昶特可以協助確認儀表的量程、精度與輸出規格；校正方面，儀表的校正週期與校正報告，也是資料可信度的一部分，建議與品保單位一起規劃。
第 3 章：監測點、儀表清單與三層配置方案
有了架構與資料策略，接下來要落到具體的儀表配置。這一章把常見的流體系統拆成監測點，再依專案成熟度分成基礎、進階、企業級三層配置。三層不是價格分級，而是資料能力分級：越往上，資料越自動、越連續、越能支撐孿生分析。
3.1 流體系統的標準監測點矩陣
| 編號 | 位置 | 量測項目 | 為何要量 | 孿生可回答的問題 |
|---|---|---|---|---|
| P1 | 泵浦入口 | 吸入壓力 | 判斷吸入是否不足、是否有汽蝕風險 | 吸入壓力下降是否與水位或濾網有關 |
| P2 | 泵浦出口 | 排出壓力 | 反映泵浦實際輸出 | 出口壓力與運轉曲線是否偏離 |
| P3 | 過濾器上游 | 前壓 | 與後壓相減得到壓差 | 壓差上升速度是否異常 |
| P4 | 過濾器下游 | 後壓 | 確認過濾後供應壓力 | 何時該清洗或更換濾芯 |
| P5 | 主管路集管 | 集管壓力 | 反映整體供應狀況 | 負載變化如何影響集管壓力 |
| P6 | 各分支末端 | 末端壓力 | 確認末端是否足夠 | 哪個分支有阻塞或洩漏 |
| P7 | 儲槽或水槽 | 靜壓（換算液位） | 估算槽內存量 | 液位與用水量是否一致 |
| T1 | 供水與回水 | 溫度 | 與壓力搭配判斷熱負載 | 溫差與流量、壓力的關係 |
表中的 P3 與 P4 是一個典型的「兩點算一個量」的例子：單看前壓或後壓，意義有限，兩者相減得到的壓差，才是判斷濾網阻塞的關鍵。在數位孿生裡，壓差通常是在邊緣端或 SiteWise 中計算出的衍生指標。這也提醒我們，兩支儀表的精度與零點一致性，會直接影響壓差的可信度。
3.2 三層配置方案
| 項目 | 基礎層：巡檢與記錄 | 進階層：遠端監控 | 企業級：數位孿生 |
|---|---|---|---|
| 主要目的 | 現場高精度讀值、保存壓力記錄 | 控制室與辦公室即時監看、超限警報 | 資產模型、趨勢分析、預測性維護 |
| 主要儀表 | 數位壓力錶（DPG 系列） | 壓力傳送器，搭配數位壓力錶做現場比對 | 具標準輸出與診斷能力的傳送器，並搭配溫度與液位傳送器 |
| 訊號與資料取得 | 藍芽或 Type-C 匯出，人工整理 | 4–20 mA 或 0–10 V 進 PLC，再由 PLC 或閘道器上傳 | HART 或數位通訊，搭配邊緣閘道器與時間戳記管理 |
| 邊緣設備 | 不需要 | PLC 與簡易閘道器 | 工業閘道器，執行 Greengrass 或 SiteWise Edge 等邊緣軟體 |
| 雲端部分 | 可選，批次匯入試算表或資料庫 | AWS IoT Core 加時序資料庫與儀表板 | IoT Core、IoT SiteWise、IoT TwinMaker 與 Grafana |
| 資料連續性 | 間斷 | 連續 | 連續且含品質標記 |
| 導入難度 | 低 | 中 | 高，需要跨部門 |
| 適合對象 | 剛開始數位化、預算與人力有限的現場 | 已有 PLC 或 SCADA，想把資料往上延伸 | 已有雲端團隊，想做預測性維護與整廠孿生 |
三層之間是可以逐步升級的路徑，不必一步到位。比較健康的做法是先在關鍵點位完成進階層，累積一段時間的資料，確認資料品質與使用價值之後，再決定是否要投入數位孿生。很多專案失敗，原因就是一開始就追求完整孿生，卻沒有足夠的資料基礎。
3.3 選擇輸出訊號：這是整合成敗的關鍵決定
| 訊號 | 優點 | 限制 | 適合情境 |
|---|---|---|---|
| 4–20 mA | 抗干擾佳、可長距離傳輸、斷線可偵測（電流歸零）、幾乎所有 PLC 都支援 | 一對線只傳一個變數 | 最通用的工業標準，大多數專案的首選 |
| 0–10 V | 接線簡單、成本低 | 傳輸距離短、易受干擾，斷線不易判斷 | 短距離、低干擾的盤內應用 |
| HART | 在 4–20 mA 上疊加數位通訊，可讀取診斷與設定 | 需要支援 HART 的 I/O 或數據機 | 需要遠端診斷與設定的重要點位 |
| RS485 Modbus RTU | 一條匯流排可串接多台，可傳多個變數 | 需設定位址與通訊參數，需要主站支援 | 多點位集中，且主站為 PLC 或閘道器 |
| 藍芽與 Type-C | 便於手機或電腦匯出記錄與設定 | 非設計用於 24 小時連續串流 | 巡檢、測試、校驗與設定 |
選訊號時，有一個簡單的原則：先看現場已經有什麼，再決定用什麼。如果現場已有 PLC 類比輸入模組，4–20 mA 幾乎永遠是最低風險的選擇。如果現場已有 Modbus 主站，RS485 可以節省佈線。不確定時，建議在詢價階段就把 PLC 型號、現有通訊協定與預計的閘道器方案一起提供，讓選型一次到位。
3.4 安裝與接線的幾個實務重點
- 量程選擇：正常操作壓力建議落在滿量程的 30% 至 70%，並預留系統瞬間峰值的餘裕。量程過大會浪費精度，過小則容易過載。
- 取壓位置：避開泵浦出口的劇烈脈動，必要時加裝緩衝器或針閥；液體管路要確保排氣，避免氣泡造成讀值跳動。
- 高度差：儀表與取壓點的高度差會產生液柱壓力，造成讀值偏差。在兩點壓差計算時尤其要注意，兩支儀表應盡量安裝在同一高度，或在模型中做高度補償。
- 接線與接地：類比訊號線使用屏蔽雙絞線，屏蔽層單點接地，並遠離變頻器與動力線，避免電磁干擾進入類比訊號。
- 電源：數位壓力錶多為電池供電，需要規劃電池更換週期；傳送器通常為迴路供電，要確認電源供應器的電壓與負載電阻。
- 螺紋規格：確認現場管件是 NPT、G（PF）還是其他標準，避免到貨後無法對接。不同螺紋不可混用。
一般型號並非防爆認證產品。若安裝區域屬於爆炸性氣體或粉塵環境，請在詢價時先說明現場分區與需求，由昶特協助評估合適的防爆型號，不要自行把一般型號用於防爆區域。
第 4 章：昶特 ATLANTIS 數位壓力錶與相關傳送器推薦
這一章依「資料取得方式」來介紹昶特的儀表，而不是只列規格。你會看到每一款產品在 IoT 專案裡扮演的角色：誰適合當現場讀值與校驗的基準，誰適合當資料來源。各型號的詳細量程、接頭與精度等級依訂購規格而定，請於詢價時提供應用條件，由昶特確認最適配置。
4.1 現場讀值、校驗與記錄：DPG 數位壓力錶系列
昶特 DPG 系列共 9 款，涵蓋標準校驗級、旋轉藍芽款、LED 高亮度款、氣壓專用款與經濟型，精度最高可達 ±0.05%F.S.。在 IoT 專案裡，它最適合扮演兩個角色：一是現場比對基準，二是巡檢與測試時的記錄工具。
圖說：ATLANTIS DPG-0.05B4.5(5CD)，±0.05%F.S. 標準校驗級數位壓力錶
DPG-0.05B4.5(5CD)
進口精密壓力傳感器搭配內部精度溫度補償傳感器，精度可達 ±0.05%F.S.，可作標準校驗用，也適合化工、液壓、石油等需要高精度現場顯示的場合。
- 在數位孿生專案中的角色：現場比對基準，用來驗證傳送器與雲端數值是否一致。
圖說：ATLANTIS DPG-X002，超大 LCD 主副屏數位壓力錶
DPG-X002
超大尺寸 LCD，主屏與副屏分屏顯示，可同時呈現即時壓力、現場溫度與最大與最小值；內建高精度 ADC 與高速微處理器，穩定性佳。
- 在專案中的角色：現場讀值與峰值檢查，適合壓力實驗室、自動化與機械配套。
圖說：ATLANTIS DPG-X112，330 度旋轉、藍芽與 Type-C 匯出記錄
DPG-X112
錶盤可旋轉 330 度，主副屏顯示壓力、環境溫度、最大與最小值與量程；支援 Type-C 或藍芽匯出記錄，並可設置多種參數。
- 在專案中的角色：巡檢記錄與資料匯出，記錄可批次匯入自己的資料庫。
圖說：ATLANTIS DPG-X182R，藍芽與 APP 配置參數
DPG-X182R
內置高精度壓力傳感器，錶盤可 330 度旋轉，支援藍芽連接與 APP 配置參數，適合便攜量測、設備配套與校驗。
- 在專案中的角色：現場設定與便攜量測，適合維修與巡檢人員。
圖說：ATLANTIS DPG-X3.0，高精度數位壓力錶，另有 SP 保壓偵漏客製型
DPG-X3.0
內建高精度壓力傳感器，即時準確顯示、長期穩定，適用便攜式壓力測量、設備配套與校驗設備。SP 型為客製品，針對長期持壓與保壓並偵測是否微漏的需求。
- 在專案中的角色：設備配套與保壓測試，SP 型可用於偵漏類驗證。
除上述型號外，DPG 系列還有 DPG-GH0.05（耐酸鹼超寬量程，±0.05%F.S.）、DPG-X062（不鏽鋼 304 經濟型）、DPG-X162（氣體專用）與 DPG-X282(ED)（LED 高亮度，適合惡劣環境）。完整比較請見昶特數位壓力錶 DPG 系列產品頁。
4.2 連續資料來源：壓力傳送器與溫度傳送器
需要連續、自動地把資料送進系統時，資料來源應該是具標準輸出的傳送器。以下是昶特產品目錄中，適合作為 IoT 與數位孿生資料來源的幾個代表型號。實際輸出方式、量程與認證，請以各型號規格書與詢價確認為準。
圖說：ATLANTIS SDPT-3100，HART 智能型壓力傳送器
SDPT-3100
HART 智能型壓力傳送器，依產品目錄資訊提供 4–20 mA 與 0–10 V 輸出，IP67 防護，並支援 HART 通訊與遠端診斷。
- 在專案中的角色：關鍵點位資料來源，需要遠端診斷時優先評估。
圖說：ATLANTIS AT-PT186，智慧型壓力溫度複合傳送器
AT-PT186
智慧型壓力傳送器，依產品目錄資訊整合壓力與溫度量測，提供 4–20 mA 與 485 通訊，適用蒸汽系統、加熱爐與複合工況。
- 在專案中的角色：同一點位同時取得壓力與溫度，減少接線與安裝點。
圖說：ATLANTIS STT，HART 智能型溫度傳送器
STT
HART 智能型溫度傳送器，一體化設計，支援 Pt100 與熱電偶，量測範圍涵蓋 -200 至 +600°C。
- 在專案中的角色：與壓力搭配的溫度資料來源，用於計算與判斷熱負載。
溫度與壓力搭配有它的道理。流體系統中，壓力與溫度常常互相影響，單看其中一個量，容易誤判。數位孿生如果同時掌握兩者，就能區分「壓力下降是因為濾網阻塞」還是「溫度變化造成的物理現象」。
4.3 選型速查表
| 你的需求 | 建議方向 | 原因 |
|---|---|---|
| 作為標準器、實驗室或校驗用 | DPG-0.05B4.5(5CD)、DPG-GH0.05 | ±0.05%F.S. 精度等級 |
| 需要記錄數據、手機設定參數 | DPG-X112、DPG-X182R | 藍芽、Type-C、APP 配置 |
| 同時看壓力、溫度與最大與最小值 | DPG-X002、DPG-X112 | 主副屏分屏顯示 |
| 現場光線強、環境惡劣 | DPG-X282(ED) | LED 高亮度螢幕 |
| 量測空氣、氮氣等氣體 | DPG-X162 | 氣壓專用，銅合金接頭 |
| 預算有限的一般監控 | DPG-X062 | 經濟型，不鏽鋼 304 接頭 |
| 需要連續自動送資料到系統 | 壓力傳送器系列（如 SDPT-3100、AT-PT186） | 標準訊號輸出，可接 PLC 或閘道器 |
| 需要遠端診斷與設定 | HART 型傳送器（如 SDPT-3100、STT） | 在 4–20 mA 上提供數位診斷 |
| 長時間保壓、偵測微漏 | DPG-X3.0 SP 型（客製） | 針對持壓與保壓需求 |
不確定要選哪一類時，可以使用昶特的數位壓力錶選型精靈，輸入條件後取得建議規格，或直接透過線上詢價表單提供介質、壓力範圍、精度、輸出需求與現有 PLC 資訊。
第 5 章：客戶自行串接範例：從 4–20 mA 到 AWS 的資料流程
再次聲明：以下內容是概念示範，目的是幫助工程師理解資料如何從類比訊號變成雲端上的時間序列。昶特 ATLANTIS 不提供 AWS 整合服務，也不保證範例可直接套用到任何現場。實際部署前，請依 AWS 官方文件、貴公司資安規範與現場環境逐項驗證。
5.1 資料流程總覽
| 步驟 | 動作 | 常見工具 | 主要責任方 |
|---|---|---|---|
| 1 | 儀表量測並輸出 4–20 mA | 壓力傳送器 | 儀表端（昶特協助確認規格） |
| 2 | 類比輸入轉為數位值 | PLC 類比輸入模組或 I/O 模組 | 客戶或系統整合商 |
| 3 | 工程量換算（mA 轉為壓力單位）、濾波、品質標記 | PLC、Node-RED、閘道器 | 客戶或系統整合商 |
| 4 | 以 MQTT 或 OPC UA 方式往上送 | Greengrass、SiteWise Edge、MQTT 用戶端 | 客戶或系統整合商 |
| 5 | 雲端接收、規則轉送、儲存 | AWS IoT Core、IoT SiteWise、Timestream | 客戶的雲端團隊 |
| 6 | 建立資產模型與孿生場景 | IoT SiteWise、IoT TwinMaker、Managed Grafana | 客戶的雲端團隊 |
5.2 工程量換算：mA 轉壓力
4–20 mA 是線性訊號，4 mA 對應量程下限，20 mA 對應量程上限。換算公式很簡單，但有幾個細節必須處理：低於 3.8 mA 通常視為斷線或故障，高於 20.5 mA 可能是儀表過載或故障，這些值不應該當成正常壓力送上去，而應該標成品質不良。
def ma_to_pressure(ma, p_min, p_max):
"""4-20 mA 轉工程量，並回傳品質標記。
p_min, p_max 為該傳送器的量程下限與上限。"""
if ma < 3.8:
return None, "BAD_UNDER_RANGE" # 疑似斷線
if ma > 20.5:
return None, "BAD_OVER_RANGE" # 疑似故障或過載
value = p_min + (ma - 4.0) / 16.0 * (p_max - p_min)
return value, "GOOD"
# 範例：量程 0 至 10 bar，讀到 12 mA
print(ma_to_pressure(12.0, 0.0, 10.0)) # (5.0, 'GOOD')這段程式把「值」與「品質」一起回傳，是整個資料鏈中最重要的習慣之一。很多數位孿生出現難以解釋的異常，根本原因是斷線時送上去的 0 被當成真實壓力。把品質標記一路帶到雲端，後端才有機會正確處理缺值。
5.3 以 MQTT 送到 AWS IoT Core（概念示範）
AWS IoT Core 支援 MQTT 3.1.1 與 MQTT 5，裝置通常以 X.509 憑證做雙向 TLS 認證，並用 IoT policy 限制可發布與訂閱的主題。下面的示範使用常見的 Python 用戶端函式庫概念，主題命名建議包含廠區、資產與量測點，方便規則引擎與權限政策做階層管理。
import json, time
# 假設已建立好 MQTT 連線 mqtt_connection（憑證、端點由客戶自行準備）
topic = "plant01/coolingloop/pump01/pressure/p2"
def publish_reading(conn, value, quality):
payload = {
"ts": int(time.time() * 1000), # 毫秒時間戳記，建議在邊緣端產生
"value": value,
"unit": "bar",
"quality": quality,
"asset": "pump01",
"point": "P2"
}
# QoS 1：至少送達一次，AWS IoT Core 支援 QoS 0 與 1
conn.publish(topic=topic, payload=json.dumps(payload), qos=1)這裡有三個設計重點。第一，時間戳記在邊緣端產生，而不是等到雲端收到才打，這樣即使網路中斷後補傳，時間序列仍然正確。第二，QoS 選 1，確保至少送達一次，後端要能容忍偶爾的重複資料。第三，主題採階層式命名，之後可以用萬用字元與規則引擎做彈性路由。
5.4 IoT Core 規則：把資料轉進時序資料庫
資料進入 IoT Core 之後，可以用規則引擎（IoT rules）依主題篩選，再轉送到其他 AWS 服務。2026 年 8 月 25 日，AWS 公告了新的規則動作，可以將 MQTT 訊息直接寫入 Amazon Timestream for InfluxDB，這讓時序資料的落地路徑更短。下面是規則 SQL 的概念範例。
SELECT
timestamp() AS rule_time,
topic(2) AS line,
topic(3) AS asset,
topic(5) AS point,
value, unit, quality, ts
FROM 'plant01/+/+/pressure/+'
WHERE quality = 'GOOD'注意 WHERE 條件把品質不良的資料濾掉，只讓可信資料進入分析資料庫。是否要保留品質不良的原始紀錄，要看稽核與故障分析的需求；比較穩健的做法是另寫一條規則，把原始資料完整存進 S3 作為冷儲存，分析庫只保留乾淨的資料。
5.5 寫入 IoT SiteWise（概念示範）
IoT SiteWise 可以用資產模型來描述設備與量測點，並支援在模型中定義轉換（transform）與指標（metric）。若要從自己的程式寫入資料，可以使用批次寫入的 API。SiteWise 在 2025 年 1 月起支援在屬性值中帶入 null 與 NaN，這對處理斷線與缺值很有幫助，可以明確表達「沒有資料」而不是塞一個假的數字。
import boto3, time
sw = boto3.client("iotsitewise", region_name="ap-northeast-1")
def put_pressure(asset_id, property_id, value, quality="GOOD"):
sw.batch_put_asset_property_value(entries=[{
"entryId": "e1",
"assetId": asset_id,
"propertyId": property_id,
"propertyValues": [{
"value": {"doubleValue": value},
"timestamp": {"timeInSeconds": int(time.time())},
"quality": quality # GOOD、BAD 或 UNCERTAIN
}]
}])SiteWise 的品質欄位採用 GOOD、BAD、UNCERTAIN 三種狀態，與前面程式中自訂的品質字串需要做對應。這也是為什麼我們建議在設計階段就先定義統一的品質代碼表，而不是等到串接時才各自發明。
5.6 用 SiteWise 資產模型算壓差
前面提到濾網壓差是兩個壓力點相減的結果。在 SiteWise 的資產模型中，可以定義一個轉換屬性，直接用兩個測量屬性的表達式計算，概念如下。
資產模型：Filter（過濾器）
測量屬性（Measurement）：
upstream_pressure 單位：bar
downstream_pressure 單位：bar
轉換屬性（Transform）：
diff_pressure = upstream_pressure - downstream_pressure
指標屬性（Metric，視窗 1 小時）：
diff_pressure_avg = avg(diff_pressure)
diff_pressure_max = max(diff_pressure)把計算放在模型裡有一個好處：所有同型號的過濾器共用同一個模型，新增一台只要建立資產並綁定兩個測量點，壓差與平均值就會自動出現。這正是資產模型的價值，也是數位孿生能規模化的前提。
5.7 TwinMaker 與 Grafana 的角色
資料進了 SiteWise 之後，AWS IoT TwinMaker 可以把這些屬性綁定到 3D 場景中的元件，讓使用者在模型裡直接點選設備、看到即時壓力與歷史趨勢。TwinMaker 的官方文件在 2026 年 6 月 25 日有更新。另一條路線是使用 Amazon Managed Grafana，搭配 TwinMaker 的 Grafana 外掛（需要 Grafana 10.4.0 以上版本），把孿生場景直接嵌進儀表板，適合已經以 Grafana 做維運監看的團隊。
要提醒的是，3D 場景並不是必要條件。很多團隊的第一個價值版本，只是一張帶有警報狀態的二維流程圖加趨勢圖，而不是完整的 3D 模型。建議先把資料與資產模型做好，3D 呈現可以放在第二階段，等到資料已經被使用者信任之後，再投入。
5.8 邊緣端：Greengrass 與 SiteWise Edge
現場網路常常不穩定，邊緣運算可以讓資料先在本地緩衝與處理，網路恢復後再補傳。AWS IoT Greengrass v2 在 2026 年 7 月 8 日發布了 2.18.0 版。另外，若你仍在使用 Greengrass V1，需要特別留意：V1 的終止支援日期是 2026 年 10 月 7 日，已經過了。仍在使用 V1 的現場，應盡快規劃遷移到 v2。
IoT SiteWise 的閘道器則可以直接連接 OPC UA、Modbus TCP 與 EtherNet/IP 等工業協定的資料來源。若現場已有 PLC 並提供 OPC UA 或 Modbus TCP，這條路線可以不必自己寫採集程式。
第 6 章：效益試算與導入風險
6.1 假設情境：冷卻水迴路的濾網壓差監測（非真實客戶案例）
以下是一個為說明試算邏輯而設計的假設情境，所有數字都是示範用，不代表任何真實客戶、也不是對效益的承諾。目的是讓讀者學會如何為自己的現場做效益評估。
| 項目 | 導入前 | 導入後 | 說明 |
|---|---|---|---|
| 濾網清洗方式 | 固定週期清洗，不論髒污程度 | 依壓差趨勢決定清洗時機 | 避免過早清洗或過晚才發現阻塞 |
| 異常發現方式 | 巡檢人員定時抄表 | 壓差超限即時警報 | 縮短發現異常的時間 |
| 巡檢頻率 | 每班多次人工抄表 | 改為異常觸發與定期校驗 | 人力轉用於更高價值工作 |
| 資料用途 | 紙本或個人試算表 | 時間序列資料庫，可回溯分析 | 事故後可調閱完整壓力歷程 |
如何估算自己的投資報酬？可以用下面這個簡單的框架。投資報酬率等於每年可避免的損失與節省的人力，扣掉每年的儀表、邊緣、雲端與維運成本，再除以總投資。其中最難估的是可避免損失：建議從歷史上最近兩三次與壓力相關的停機或品質事件出發，算出單次事件的損失，再估計早期預警能避免其中多少比例。保守的估計，比樂觀的估計更容易說服財務單位。
6.2 導入風險與對策
| 風險 | 典型徵兆 | 對策 |
|---|---|---|
| 選錯儀表類型 | 買了只能現場顯示的數位壓力錶，卻期待連續上雲 | 先釐清是巡檢、遠端監控還是孿生需求，再選型 |
| 資料品質不佳 | 斷線時趨勢圖出現 0，造成誤警報 | 全程帶品質標記，雲端區分缺值與真值 |
| 時間不同步 | 多點資料對不上，壓差出現鋸齒 | 邊緣端統一時間來源，在邊緣產生時間戳記 |
| 訊息量失控 | 雲端費用超預期 | 依表 4 的取樣策略，邊緣端做變化量上報與聚合 |
| 資安疏漏 | 憑證共用、權限過大 | 每裝置獨立憑證，IoT policy 採最小權限 |
| 責任不清 | 儀表、PLC、雲端三方互相推諉 | 在專案開始時就寫明各方責任分界 |
| 校驗被忽略 | 雲端數值與現場讀值逐漸不一致 | 定期用現場標準錶比對，記錄偏差與校驗日期 |
| 過度追求 3D | 模型很漂亮但沒有人用 | 先做資料與資產模型，再做視覺化 |
6.3 建議的導入路線
- 盤點：列出要量的點位、介質、壓力範圍、現有 PLC 與網路條件。
- 選型：依需求類型決定使用數位壓力錶、傳送器，或兩者搭配。
- 試點：選一條迴路或一組泵浦，先跑通完整資料鏈。
- 驗證：用現場標準錶比對，確認雲端數值與實際一致。
- 擴展：把試點驗證過的資產模型與點位命名，複製到其他迴路。
- 優化：累積足夠資料後，再導入異常偵測、預測性維護與 3D 孿生。
第 7 章：資安、校驗與維運：讓資料長期可信
IoT 與數位孿生專案最容易被低估的部分，不是上線，而是上線之後的三年。儀表會漂移、憑證會到期、網路會改版、人員會異動。一個能長期運作的系統，必須在設計階段就把資安、校驗與維運想清楚。這一章從三個角度整理實務重點。
7.1 裝置身分與權限：每個閘道器一張憑證
AWS IoT Core 的標準做法，是讓每一個連線的裝置擁有自己的 X.509 憑證與 IoT policy。在儀表場域中，通常不是每支傳送器直接上雲，而是由閘道器或 PLC 代表一組儀表連線，因此「每個閘道器一張獨立憑證」是最基本的原則。多個閘道器共用同一張憑證，一旦其中一台被取出或複製，整批裝置都必須撤銷，維運成本極高。
IoT policy 則應採最小權限原則。一個負責冷卻水迴路的閘道器，只需要發布自己廠區與迴路主題下的訊息，不需要訂閱其他廠區的主題，更不需要有管理類操作的權限。主題階層若在一開始就設計得清楚，policy 就可以用變數與前綴精準限制，避免日後權限越擴越大。
| 檢查項目 | 建議做法 | 常見疏漏 |
|---|---|---|
| 裝置身分 | 每個閘道器獨立憑證，記錄憑證與資產對應 | 多台共用同一張憑證 |
| 權限範圍 | IoT policy 僅允許自己的主題前綴 | 開放萬用字元的全部權限 |
| 憑證輪替 | 建立到期提醒與更換流程 | 憑證過期才發現斷線 |
| 私鑰保護 | 儲存在受保護的位置，限制存取帳號 | 私鑰放在共享資料夾 |
| 網路邊界 | 現場網路與辦公網路分區，只開放必要的對外連線 | 控制網路與辦公網路直接互通 |
| 日誌與稽核 | 啟用連線與驗證失敗的日誌，定期檢視 | 日誌從未被查看 |
| 下行指令 | 寫入類指令預設不開放，必要時另行審核 | 雲端可直接改寫現場設定 |
AWS 在 2026 年 6 月 3 日公告了與連線相關的日誌更新，包含 Ping 與驗證失敗（AuthNError）的記錄，對排查「為什麼裝置突然連不上」很有幫助。5 月 28 日的更新則提供了 GetConnection 與 ListSubscriptions，可用來查詢某個用戶端目前的連線狀態與訂閱清單，對維運人員做遠端診斷相當實用。這些都是雲端側的工具，現場閘道器仍需要自己的本地日誌與監看機制。
7.2 為什麼儀表資料要預設唯讀
壓力、溫度、液位這類量測資料，本質上是單向的：從現場流向雲端。AWS IoT Core 在 2026 年 5 月 28 日新增了 SendDirectMessage 這類可由雲端向裝置傳送訊息的能力，這在許多情境很有價值，但在工業現場必須謹慎。建議的原則是：量測資料通道預設唯讀；若需要下行，例如調整取樣頻率或警報門檻，應走獨立的、經過審核的通道，並且與任何會影響製程的控制動作完全隔離。
數位孿生與預測性維護屬於輔助決策系統，不應直接取代安全儀控。涉及人員與設備安全的壓力保護，仍應由現場獨立的安全迴路與機械式保護裝置負責，不要把安全責任交給雲端分析結果。
7.3 校驗：資料可信度的底線
數位孿生的所有分析，都建立在「量測值是準的」這個前提上。儀表會隨時間、溫度循環、壓力衝擊與介質腐蝕而漂移，因此校驗不是可有可無的流程。比較實務的做法，是依儀表重要性分級，決定校驗週期。
| 等級 | 點位特徵 | 建議做法 |
|---|---|---|
| 關鍵點位 | 影響安全、品質或產能的壓力點，以及用於計算壓差的成對儀表 | 縮短校驗週期，並以高精度數位壓力錶做定期現場比對 |
| 一般點位 | 用於趨勢監看與一般警報 | 依製程需求與廠內規範，定期抽檢或校驗 |
| 輔助點位 | 僅供參考，不參與判斷 | 發現異常時再檢查，或與相鄰點位交叉比對 |
用數位壓力錶做現場比對，是一個低成本且有效的方法。以 ±0.05%F.S. 的高精度型號作為比對基準，量測當下傳送器所在位置的壓力，再與雲端顯示的數值對照，就能快速判斷偏差是出在傳送器、類比輸入模組、換算公式，還是雲端的單位設定。這種分段排查的邏輯，遠比單看雲端趨勢圖有效。校驗週期、容許偏差與追溯方式，請依貴公司品質系統與適用規範訂定。
7.4 兩點壓差的特別提醒
濾網壓差、熱交換器壓差這類應用，需要兩支壓力儀表相減。假設兩支儀表量程是 0 至 10 bar，精度各為滿量程的一定比例，那麼相減之後的誤差可能與實際壓差同一個數量級，尤其壓差本身很小的時候。因此，壓差監測有兩種常見的處理方式：一是使用量程較小、精度較高的儀表，讓兩點誤差降低；二是直接使用差壓傳送器，由單一儀表量測壓差。到底哪一種適合，取決於壓差大小、靜壓大小與要求的解析度，建議在詢價階段就把這些條件一起提供。
7.5 維運：把「誰負責什麼」寫成表
| 項目 | 負責角色 | 頻率 |
|---|---|---|
| 儀表校驗與更換 | 設備或儀控工程師 | 依校驗週期 |
| PLC 與閘道器維護 | 自動化或系統整合商 | 依維護合約 |
| 憑證與權限管理 | IT 或雲端團隊 | 憑證到期前 |
| 資料品質檢視 | 資料或製程工程師 | 每週或每月 |
| 資產模型與點位命名維護 | 專案負責人 | 新增設備時 |
| 警報門檻檢討 | 製程與設備共同 | 每季 |
實務上，最常見的失敗模式並不是技術問題，而是沒有人負責。儀表壞了，操作員以為儀控會處理；數值跳了，儀控以為雲端團隊會處理；雲端團隊又看不懂現場。把這張表在專案開始時就填好、並獲得各部門主管同意，比任何技術設計都更能保護專案。
第 8 章：四個典型應用情境的儀表與資料設計
前面的章節講的是通則，這一章把通則套用到四個常見的應用情境。每個情境的重點都不同，儀表配置與資料策略也因此有差異。以下內容為設計思路示範，實際方案需依現場條件調整。
8.1 情境一：冷卻水與冰水系統
冷卻水系統是壓力監測最典型的場域：泵浦入口與出口、過濾器前後、集管與各分支末端。這類系統的壓力變化相對緩慢，資料取樣可以保守，每數秒到數十秒一筆通常足夠。重點在於壓差趨勢與泵浦運轉曲線的比對。
- 儀表建議：關鍵點位使用具 4–20 mA 輸出的壓力傳送器，並在泵浦出口等位置加裝數位壓力錶作現場比對。
- 資料設計：泵浦入口與出口、過濾器前後成對命名，在資產模型中計算壓差與平均值。
- 孿生價值：濾網阻塞的早期預警、泵浦性能衰退的趨勢、管網洩漏的初步定位。
8.2 情境二：蒸汽與熱媒系統
蒸汽系統中，壓力與溫度緊密耦合，飽和蒸汽的壓力與溫度存在固定對應關係，兩者偏離常常意味著凝結水、積水或量測問題。因此這類應用特別適合壓力與溫度複合量測。AT-PT186 這類整合壓力與溫度量測的智慧型傳送器，可以在同一點位取得兩個變數，降低安裝點數量。
- 儀表建議：壓力與溫度成對量測，並考慮介質溫度對取壓接頭與膜片的影響，必要時使用冷凝管等隔離措施。
- 資料設計：同一點位的壓力與溫度使用相同時間戳記，方便計算偏離。
- 孿生價值：識別積水與疏水器異常，追蹤熱效率變化。
8.3 情境三：壓縮空氣系統
壓縮空氣是許多工廠的隱形耗能大戶，洩漏與壓降是主要問題。這類系統的壓力量測點包括空壓機出口、乾燥機前後、儲氣罐與各用氣區。重點是找出壓降發生的位置，以及用氣量與壓力的關係。
- 儀表建議：氣體專用的數位壓力錶如 DPG-X162 適合現場讀值與巡檢；要連續監控的關鍵點位使用傳送器。
- 資料設計：儲氣罐壓力搭配空壓機啟停狀態，可以估算洩漏率；非生產時段的壓力衰減速度，是判斷洩漏的有用指標。
- 孿生價值：洩漏的量化追蹤、節能效果的驗證。
8.4 情境四：液位換算與儲槽管理
對於開放式水槽與儲槽，可以利用底部靜壓換算液位。換算公式是靜壓除以介質密度與重力加速度，因此介質密度必須已知且穩定。若介質密度會隨溫度變化，則需要同時量測溫度並做補償。
- 儀表建議：投入式或底部取壓的壓力傳送器；現場以數位壓力錶做交叉驗證。
- 資料設計：靜壓、換算液位與溫度分開存放，換算在邊緣端或 SiteWise 模型中完成，並記錄所用的密度參數。
- 孿生價值：存量估算、用量異常偵測、補料時機提示。
8.5 選型前的十個問題
- 要量的介質是什麼？是否具腐蝕性、黏稠或含顆粒？
- 正常操作壓力與最大瞬間壓力各是多少？
- 需要的精度等級是多少？是否作為標準器使用？
- 使用環境溫度、濕度與防護等級需求？
- 現場是否有爆炸性氣體或粉塵？
- 螺紋與接頭規格是什麼？材質是否有要求？
- 需要現場顯示、遠端訊號，還是兩者都要？
- 現有 PLC 或控制系統的型號與輸入類型？
- 供電方式是電池還是迴路供電？維護週期能否接受？
- 後續是否需要校驗證明與追溯？
把這十個問題的答案整理好再詢價，通常能一次就確認出適合的型號，節省來回溝通的時間。若尚未釐清，也可以先使用選型精靈做初步篩選。
第 9 章：2026 年 AWS 動態對儀表場域的意義
前面各章已經零散提到幾個 AWS 的更新。這一章把它們集中起來，並從儀表現場的角度說明意義，幫助讀者判斷哪些更新值得關注、哪些可以暫時忽略。
| 日期 | 更新內容 | 對儀表場域的意義 |
|---|---|---|
| 2026 年 5 月 28 日 | IoT Core 新增 GetConnection 與 ListSubscriptions | 維運人員可查詢閘道器連線狀態與訂閱清單，加快斷線排查 |
| 2026 年 5 月 28 日 | IoT Core 新增 SendDirectMessage | 可由雲端對特定用戶端傳訊；量測通道建議維持唯讀，下行需經審核 |
| 2026 年 6 月 3 日 | IoT Core 新增 Ping 與驗證失敗的日誌 | 更容易分辨是憑證、權限還是網路問題造成的連線失敗 |
| 2026 年 6 月 25 日 | IoT TwinMaker 文件更新 | 規劃孿生場景時，應以最新文件為準 |
| 2026 年 7 月 8 日 | Greengrass v2 發布 2.18.0 | 邊緣端元件更新，維護現場閘道器時宜評估升級 |
| 2026 年 8 月 25 日 | IoT 規則新增 Timestream for InfluxDB 動作 | 壓力時序資料可直接從 MQTT 落地到時序資料庫 |
| 2026 年 10 月 7 日 | Greengrass V1 終止支援 | 仍使用 V1 的現場應立即規劃遷移到 v2 |
9.1 如何追蹤 AWS 的變動
雲端服務的更新速度遠快於儀表。建議負責雲端端的團隊，訂閱 AWS 的 What's New 與各服務的文件更新記錄，並每季檢視一次是否有對現有架構有影響的變更。儀表端則相對穩定，只需要在新增點位或更換型號時，確認輸出訊號與閘道器相容。兩端的更新節奏差異，正是為什麼我們建議在儀表與雲端之間，保留 PLC 或閘道器這一層作為緩衝。
9.2 一個簡單的原則：儀表選型要比雲端服務活得更久
儀表常常運作十年以上，而雲端服務的細節可能每年都在變。因此，儀表選型時，應優先選擇標準輸出，例如 4–20 mA，而不是綁定特定雲端平台的專用介面。標準輸出的儀表，今天接 AWS，明天也可以接其他平台，或接回本地的 SCADA，不會因為雲端策略改變而被淘汰。這也是為什麼昶特專注於把儀表本身做好，而讓客戶保有選擇資料平台的自由。
9.3 給不同角色的行動建議
- 設備工程師：先釐清現場屬於巡檢、遠端監控還是孿生需求，再決定儀表類型；先做試點，再擴展。
- 廠務與維護主管：把校驗週期與責任分工寫成表，並確保儀表更換時資料對應不會中斷。
- 系統整合商：在專案初期取得儀表規格書，確認輸出訊號、量程與供電，並建立統一的品質代碼與時間戳記策略。
- 採購：詢價時一次提供完整應用條件，避免因規格不明而重新報價；將校驗證明與交期納入評估。
- 雲端與資料團隊：先做資產模型與資料品質，再做視覺化；量測通道維持唯讀，並建立憑證與權限的輪替流程。
第 10 章：看懂數位壓力錶的規格：精度、解析度與溫度影響
要把數位壓力錶的讀值當成孿生的基準，就必須看懂規格上每一個數字的意義。許多現場人員習慣只看「精度」，卻忽略了解析度、溫度影響與長期穩定性，結果買到的儀表與預期的使用情境不符。這一章整理幾個最常被誤解的概念。
10.1 精度 %F.S. 的真正意思
精度標示為 ±0.05%F.S.，指的是誤差上限為滿量程的 0.05%。舉例來說，量程 0 至 10 bar 的儀表，誤差上限為 0.005 bar；量程 0 至 100 bar 的儀表，誤差上限就變成 0.05 bar。同樣的百分比，量程越大，絕對誤差越大。因此選型時應該讓量程貼近實際操作壓力，而不是一味選大量程。
| 量程 | 滿量程誤差上限 | 在滿量程 10% 處的相對誤差 |
|---|---|---|
| 0 至 1 bar | 0.0005 bar | 約 0.5% |
| 0 至 10 bar | 0.005 bar | 約 0.5% |
| 0 至 100 bar | 0.05 bar | 約 0.5% |
表中最後一欄揭露了一個重要觀念：當實際壓力只有滿量程的 10% 時，相對誤差會放大為滿量程時的十倍。這就是為什麼建議正常操作壓力落在滿量程的 30% 至 70% 之間。對於壓差計算，這個放大效應更明顯。
10.2 解析度與精度不是同一件事
解析度是儀表顯示的最小變化量，精度是顯示值與真實值的接近程度。顯示五位數不代表精度就是五位數。解析度高但精度低的儀表，會顯示出看起來很精確但其實偏離真值的數字。反過來說，精度高但解析度太低的儀表，會讓你看不出細微的壓力變化。選型時兩者都要看，並確認它們對應的是同一個量程範圍。
10.3 溫度對讀值的影響
壓力傳感器的輸出會隨環境溫度與介質溫度變化，這就是溫度漂移。高精度型號通常內建溫度補償機制，例如 DPG-0.05B4.5(5CD) 採用壓力傳感器搭配內部精度溫度補償傳感器，目的就是降低溫度變化造成的讀值偏差。實際使用時，應確認規格書所標示的補償溫度範圍，若現場溫度超出範圍，精度保證可能不再成立。
- 安裝位置避開熱源與日曬，必要時加裝隔熱或冷凝管。
- 校驗時儘量在接近實際使用溫度的條件下進行。
- 溫度劇烈變化後，讓儀表穩定一段時間再讀值。
10.4 最大與最小值功能的價值
許多數位壓力錶（如 DPG-X002 與 DPG-X112）具有最大與最小值記錄，這個看似簡單的功能，在除錯時非常有用。壓力的瞬間峰值，往往不會出現在人眼看到的那一刻，但儀表會記住它。巡檢人員在換班時，只要讀取並清除最大最小值，就能知道這段時間內是否有超出預期的壓力波動，補足了抄表式監測的盲點。
10.5 藍芽與 Type-C 記錄的合理用法
具藍芽或 Type-C 匯出的型號，適合用在以下幾種流程：
- 安裝驗收：施工完成後，匯出一段穩定壓力的記錄，作為驗收依據。
- 定期巡檢：巡檢人員用手機讀取並保存壓力記錄，批次上傳到公司的資料庫。
- 故障追查：在懷疑有壓力異常的位置，臨時安裝並記錄一段時間，與系統數據對照。
- 參數設定：透過 APP 配置單位、顯示與其他參數，省去現場逐項按鍵的麻煩。
這些流程的共同點，是資料以批次方式取得，而非連續串流。因此在規劃專案時，要明確區分哪些資料是「連續來源」，哪些是「補充記錄」，並在資產模型中標示資料來源類型，讓使用者知道圖上每一段曲線的可信程度與取得方式。
10.6 常見誤解與正確觀念
| 常見誤解 | 正確觀念 |
|---|---|
| 買了數位壓力錶就可以上雲 | 多數數位壓力錶以現場顯示與記錄為主，連續上雲需有標準輸出的傳送器與閘道器 |
| 精度越高越好，量程越大越保險 | 量程過大會犧牲實際精度，應讓操作壓力落在 30% 至 70% 滿量程 |
| 雲端數值就是真實壓力 | 雲端數值經過量測、換算、傳輸與處理，每一段都可能引入誤差，需定期比對 |
| 3D 孿生是專案的核心 | 資料品質與資產模型才是核心，3D 是呈現方式 |
| 儀表供應商會提供整套雲端方案 | 儀表供應商負責儀表端，雲端整合需由客戶或系統整合商處理 |
| 一次建置完就不用管 | 校驗、憑證、模型與門檻都需要持續維護 |
第 11 章：專案時程與驗收檢查表
11.1 一個典型的試點專案時程
| 階段 | 主要工作 | 產出 |
|---|---|---|
| 需求釐清 | 確認用途類型、點位、介質與壓力範圍、現有系統 | 點位清單與需求規格 |
| 儀表選型與採購 | 與昶特確認儀表規格、輸出與數量 | 儀表規格確認書 |
| 安裝與接線 | 取壓、接線、接地、類比輸入設定 | 安裝紀錄與接線圖 |
| 邊緣與雲端串接 | 閘道器設定、MQTT 或 OPC UA 連線、資產模型 | 可運作的資料鏈 |
| 驗證 | 以現場標準錶比對、故障模擬、斷線測試 | 驗證報告 |
| 運轉與優化 | 警報門檻調整、資料品質檢視 | 運轉記錄與優化清單 |
時程長度取決於現場規模與整合團隊的熟練程度。重點不是趕時間，而是每個階段都要有明確的產出與驗收標準。很多專案延誤，是因為前一階段沒有把規格確認清楚，到後面才發現輸出訊號不符或量程不對。
11.2 驗收檢查表
- 儀表型號、量程、螺紋與銘牌資料與採購規格一致。
- 取壓點位置正確，管路已排氣，無洩漏。
- 類比訊號接線正確，屏蔽與接地符合規範。
- PLC 或閘道器中的量程設定與儀表一致。
- 工程量換算正確，斷線與超範圍時有品質標記。
- 時間戳記來源統一，多點資料對齊。
- 雲端點位命名、單位與資產模型符合規劃。
- 以現場標準錶比對，偏差在可接受範圍內，並已記錄。
- 警報門檻已確認，通知對象與流程已建立。
- 憑證、權限與網路防護已通過資安檢視。
- 維運責任分工表已簽署。
11.3 常見的驗收失敗原因
從整合經驗來看，驗收失敗最常見的原因有三個。第一是單位不一致，儀表以 bar 輸出，PLC 換算成 kPa，雲端模型卻以 psi 顯示，每一層都有人「好心」轉換了一次。解決方式是全鏈統一一個內部標準單位，只在最後的呈現層做顯示轉換。第二是量程設定錯誤，PLC 中的量程與儀表實際量程不符，造成全部數值按比例偏移。這類錯誤只有靠現場比對才抓得到。第三是時間不同步，多個閘道器各自校時，造成壓差曲線出現鋸齒。統一時間來源並在邊緣端打時間戳記，通常就能解決。
11.4 結語：讓每一筆資料都有來歷
數位孿生的價值，在於讓設備的狀態可以被理解、被預測。但這一切都建立在資料可信之上。從一支數位壓力錶的選型開始，每一個決定，包括量程、精度、輸出、安裝位置、校驗週期，都在為資料的可信度加分或扣分。當你能夠回答「雲端上這個數字，是從哪支儀表、經過哪些轉換、在什麼時間、以什麼品質來的」，數位孿生才真正有了根基。
如果你正在規劃壓力量測相關的 IoT 專案，歡迎先與昶特確認儀表端的規格。儀表選對了，後面的整合工作就會順利許多。再次提醒，昶特不提供 AWS 或其他雲端平台的整合服務，雲端與系統串接請由貴公司團隊或系統整合商負責。
附錄：術語表與服務選擇決策指南
A.1 常用術語表
| 術語 | 白話說明 | 在專案中的位置 |
|---|---|---|
| %F.S. | 相對於滿量程的百分比，用來表示精度或誤差上限 | 儀表規格 |
| 4–20 mA | 以電流大小表示量測值的工業標準訊號，4 mA 為下限、20 mA 為上限 | 儀表到 PLC |
| HART | 疊加在 4–20 mA 上的數位通訊協定，可讀取診斷資訊與設定 | 儀表到 I/O 或數據機 |
| Modbus | 常見的工業通訊協定，RTU 版本走 RS485，TCP 版本走乙太網路 | 儀表、PLC、閘道器之間 |
| OPC UA | 跨平台的工業資料交換標準 | PLC 與閘道器之間 |
| MQTT | 輕量的發布與訂閱訊息協定，物聯網常用 | 閘道器到雲端 |
| QoS | 訊息傳遞的服務等級，0 為最多一次、1 為至少一次 | MQTT 設定 |
| 邊緣運算 | 在靠近現場的設備上先處理資料，再送往雲端 | 閘道器 |
| 資產模型 | 以階層與屬性描述設備與量測點的資料結構 | SiteWise |
| 數位孿生 | 與實體資產對應的數位模型，結合資料、模型與分析 | TwinMaker 與 Grafana |
| 品質標記 | 描述一筆資料是否可信的欄位，如良好、不良、不確定 | 全資料鏈 |
| 溫度漂移 | 因溫度變化導致的輸出偏移 | 儀表規格 |
A.2 AWS 服務選擇決策指南
面對 AWS 眾多服務，工程師常問：我到底需要哪幾個？以下用幾個簡單的問題，協助判斷。實際決策仍應由貴公司的雲端團隊依需求、成本與資安政策決定。
| 如果你的需求是 | 可以考慮 | 原因 |
|---|---|---|
| 只要把壓力資料安全地送上雲並保存 | IoT Core 加 S3 或時序資料庫 | 架構最簡單，成本與複雜度最低 |
| 要管理大量設備與量測點的階層，並計算衍生指標 | 加上 IoT SiteWise | 資產模型、轉換與指標計算內建 |
| 現場已有 OPC UA 或 Modbus TCP 的資料來源，不想自己寫採集 | SiteWise Edge 閘道器 | 直接連接常見工業協定 |
| 現場網路不穩，需要本地緩衝與處理 | Greengrass v2 | 邊緣元件可在斷線時持續運作 |
| 已有 Grafana 維運習慣 | Managed Grafana | 以現有儀表板方式呈現，學習成本低 |
| 要把資料綁定到 3D 或場景化的設備模型 | IoT TwinMaker | 場景與資料綁定的專用服務 |
| 要長期保存原始資料供稽核與重新分析 | S3 | 低成本的冷儲存 |
A.3 邊緣降採樣的概念做法
如前述，100 個壓力點若每秒各送一筆，一天就是八百多萬筆訊息。邊緣端降採樣是控制成本的關鍵手段。常見的做法有三種：
- 變化量上報：只有當壓力變化超過設定的死區（例如滿量程的某個小比例）時才上傳，並搭配固定間隔的心跳，確保即使沒有變化也能證明儀表仍在線。
- 時間窗聚合：每分鐘或每五分鐘，計算平均、最大、最小值後再上傳，保留趨勢又減少訊息量。
- 事件觸發加高頻擷取：平時低頻上傳，一旦超限或偵測到異常，自動切換為高頻並保存事件前後的原始資料。
這三種做法可以組合使用。關鍵是要在資料模型中記錄每個點位目前採用的策略，讓分析人員知道資料的粒度，避免把聚合後的資料當成原始資料來做高頻分析，得出錯誤的結論。
A.4 給採購與主管的快速摘要
如果你只有五分鐘，請記住以下幾點。第一，數位壓力錶擅長現場高精度讀值與記錄，連續上雲需要具標準輸出的傳送器與閘道器。第二，先定義需求類型，再選儀表，再選雲端服務，順序不能反。第三，資料品質、時間戳記、校驗與責任分工，比任何雲端功能都更決定專案成敗。第四，昶特 ATLANTIS 負責儀表端的規格確認與製造，不提供 AWS 或雲端整合；系統串接由客戶或系統整合商自行處理。第五，先做試點、驗證資料、再擴展，是風險最低的路線。
A.5 為什麼先談儀表，再談雲端
許多團隊在啟動 IoT 專案時，習慣先挑雲端平台、先畫架構圖、先做展示畫面，最後才發現現場的儀表不能提供所需的資料。這種由上而下的做法，容易在整合階段遇到無法逆轉的限制：量程不對就要換儀表，輸出訊號不符就要加轉換器，安裝位置不佳就要重新施工。每一項都會拖延時程、增加成本。
相對地，由下而上的做法先確認量測需求：要量什麼、量多準、多久量一次、資料要給誰用。這些答案決定儀表的類型與輸出，再往上決定 PLC 與閘道器，最後才是雲端服務。順序看似保守，實際上卻是最快的路，因為每一層的規格都有明確依據，不會在後段反覆修改。
A.6 與昶特討論需求時的準備清單
- 點位清單：每個量測點的位置、用途與編號。
- 介質資料：種類、溫度、是否具腐蝕性或含顆粒。
- 壓力資料：正常操作壓力、最大瞬間壓力與期望量程。
- 精度與校驗需求：是否作為標準器、是否需要校驗證明。
- 輸出與通訊：現場已有的 PLC 型號與輸入模組類型、是否需要 HART 或 RS485。
- 環境條件：溫度、濕度、防護等級與是否有防爆需求。
- 安裝條件：螺紋規格、安裝方向與空間限制。
- 數量與交期：首批試點數量與預計擴展規模。
把這些資料整理在一份簡單的表格中提供給昶特，通常能大幅縮短選型時間。昶特會依儀表端的條件協助確認適合的型號與配置；至於資料如何進入 PLC、閘道器與雲端，則是客戶端的整合工作，請由貴公司或系統整合商負責。
第 12 章：常見問題 FAQ（20 則）
數位壓力錶可以直接連上 AWS IoT 嗎？
數位壓力錶本身通常不具備雲端連線功能。DPG 系列的強項是現場高精度顯示、最大最小值，以及藍芽或 Type-C 匯出記錄。要讓資料連續進入 AWS，建議使用具 4–20 mA、0–10 V 或 RS485 等標準輸出的壓力傳送器，再經 PLC 或閘道器上傳。實際輸出規格請以各型號規格書與詢價確認為準。
數位壓力錶和壓力傳送器差在哪裡？
數位壓力錶的主要任務是在現場顯示讀值，由人員直接判讀；壓力傳送器的主要任務是把壓力轉成標準電訊號，供 PLC、閘道器或控制系統讀取。兩者常搭配使用：傳送器負責資料來源，數位壓力錶負責現場比對與校驗。
昶特 ATLANTIS 有提供 AWS 或 IoT 整合服務嗎？
沒有。昶特專注於壓力、溫度、液位等量測儀表的研發與製造，不提供 AWS 或其他雲端平台的整合。客戶需自行規劃與實作儀表接入 PLC、閘道器與雲端的流程，或委託系統整合商處理。昶特可協助確認儀表端的規格、輸出訊號與選型。
什麼是數位孿生？跟一般遠端監控有何不同？
遠端監控是看到現在的數值；數位孿生則是為實體資產建立可對應的數位模型，把即時資料、歷史資料、資產階層與分析結果放在同一個模型中，能回答「為什麼」與「接下來會怎樣」。孿生的前提是可靠的資料與清楚的資產模型。
AWS IoT TwinMaker 需要先有 3D 模型嗎？
不一定。3D 場景只是呈現方式之一。多數專案的第一階段價值來自資料與資產模型，例如用 IoT SiteWise 管理量測點、計算壓差，再用 Grafana 或簡單的二維畫面呈現。等資料被使用者信任後，再投入 3D 場景更有效率。
AWS IoT Core 支援哪些 MQTT 版本與 QoS？
依 AWS 官方文件，IoT Core 支援 MQTT 3.1.1 與 MQTT 5，QoS 支援 0 與 1。需要至少送達一次時使用 QoS 1，後端要能容忍偶爾重複的訊息。
要把 100 個壓力點每秒送一筆上雲，訊息量有多大？
100 點乘以每天 86,400 秒，等於每天 8,640,000 筆訊息。若每筆約 200 位元組，資料量約 1.73 GB。這還沒計入連線、協定與重送的額外負擔。因此建議在邊緣端做變化量上報、聚合與降採樣，不必所有點位都用最高頻率上傳。
壓力點的取樣頻率該怎麼訂？
依用途決定。泵浦起停與水錘分析可能需要較高頻率，並多半在邊緣端分析；濾網壓差、管網趨勢通常每數秒到數十秒一筆即足夠；儲槽靜壓換算液位則可以更慢。詳見本文表 4 的取樣策略。
斷線或感測器故障時，資料要怎麼處理？
不要把 0 當成真實壓力送上去。4–20 mA 若低於約 3.8 mA 視為疑似斷線，高於約 20.5 mA 視為過載或故障，應標成品質不良。SiteWise 自 2025 年 1 月起支援 null 與 NaN 值，可明確表達缺值。
時間戳記應該在哪裡產生？
建議在邊緣端或 PLC 產生，並統一時間來源。若等到雲端收到才打時間，網路中斷後補傳的資料時間就會錯亂，導致兩點壓差計算出現鋸齒。
Greengrass V1 還能用嗎？
Greengrass V1 的終止支援日期是 2026 年 10 月 7 日，現在已過期。仍在使用 V1 的現場應規劃遷移到 Greengrass v2。v2 在 2026 年 7 月 8 日發布了 2.18.0 版。
IoT SiteWise 閘道器可以直接讀 PLC 嗎？
SiteWise 閘道器可連接 OPC UA、Modbus TCP 與 EtherNet/IP 等資料來源。若 PLC 提供其中一種協定，可以不必自己寫採集程式。實際相容性與設定需由客戶或整合商依現場驗證。
Grafana 要用哪個版本才能搭配 TwinMaker？
依 AWS 文件，TwinMaker 的 Grafana 外掛需要 Grafana 10.4.0 以上版本。使用 Amazon Managed Grafana 時，請確認工作區版本符合需求。
IoT Core 的資料能直接寫進時序資料庫嗎？
可以。AWS 在 2026 年 8 月 25 日公告了新的 IoT 規則動作，可將 MQTT 訊息直接寫入 Amazon Timestream for InfluxDB，縮短時序資料落地的路徑。
藍芽數位壓力錶的記錄可以用在孿生嗎？
可以作為歷史資料補充，例如巡檢記錄、校驗過程與測試資料，批次匯入自己的資料庫。但它不是設計用於 24 小時連續串流，不適合作為即時孿生的主要資料來源。
怎麼確認雲端數值和現場一致？
在安裝後以現場標準錶或高精度數位壓力錶比對，記錄偏差與日期，並定期校驗。高精度型號如 DPG-0.05B4.5(5CD) 精度可達 ±0.05%F.S.，可作為比對基準。
量程該怎麼選？
正常操作壓力建議落在滿量程的 30% 至 70%，並預留瞬間峰值餘裕。量程過大會損失解析度，過小則易過載。介質、溫度與接頭規格也請一併提供給昶特確認。
一般型號可以用在防爆區域嗎？
不可以。一般型號並非防爆認證產品。若現場有爆炸性氣體或粉塵，請在詢價時說明分區與需求，由昶特協助評估合適的防爆型號。
導入數位孿生要先做哪些準備？
先盤點點位、介質、壓力範圍與現有 PLC 與網路；選定試點迴路；定義點位命名與品質代碼；確認責任分界；最後才是雲端與視覺化。建議先跑通一條完整資料鏈，再複製擴展。
如何向昶特詢價或確認選型？
可使用昶特的數位壓力錶選型精靈，或透過線上詢價表單提供介質、壓力範圍、精度、輸出需求、螺紋與現有 PLC 資訊。也可以直接來電 (02) 2820-3405 或寄信至 gauge6@atlantis.com.tw。
延伸閱讀與相關資源
- 昶特數位壓力錶 DPG 系列產品頁：9 款型號完整比較。
- 數位壓力錶選購指南：精度、量程與接頭的選擇邏輯。
- 數位壓力錶選型精靈：輸入條件取得建議規格。
- 數位壓力錶客製化與校驗：客製需求與校驗服務說明。
- 溫度傳送器系列：與壓力搭配的溫度資料來源。
- 蒸汽鍋爐監測系統：壓力與溫度複合監測的應用參考。
- 昶特產品總覽：壓力、溫度、液位與開關全系列。
資料來源（AWS 官方文件與公告）
- AWS IoT Core 開發者指南：MQTT
- AWS IoT SiteWise 使用者指南
- AWS IoT TwinMaker 使用者指南
- AWS IoT Greengrass v2 開發者指南
- AWS 最新公告（What's New）
文中 2026 年的 AWS 更新日期，來自 AWS 官方公告與文件的整理；服務內容會持續變動，實際規劃請以 AWS 官方最新文件為準。
需要確認儀表端規格？歡迎聯絡昶特 ATLANTIS
請提供介質、壓力範圍、精度需求、螺紋規格、所需輸出訊號與現有 PLC 資訊，昶特協助確認儀表端的最適配置。再次提醒：昶特不提供 AWS 或雲端整合服務，系統串接由客戶或系統整合商自行規劃。
- 公司：昶特企業有限公司 ATLANTIS
- 電話：(02) 2820-3405
- 信箱：gauge6@atlantis.com.tw
- 地址：台北市北投區致遠一路二段 109 號
- 網站：re-atlantis.tw
- 線上詢價表單