RS485 ATLANTIS 壓力表上雲實戰：AWS IoT Core、Timestream 與 QuickSight 完整架構

工廠現場已有 RS485 壓力表，卻只能在控制室看數字、無法遠端查歷史趨勢？本文用 ATLANTIS DPS-2.5SPD3 為例，完整拆解從 RS485 訊號到雲端儀表板的實作路徑。

為什麼 RS485 壓力表值得上雲

台灣工業現場的壓力量測，長期以來多半停留在「現場讀值」或「接 PLC 顯示在控制室 HMI」的階段。這種做法有兩個明顯限制：資料無法離開廠區，管理者出差在外看不到即時狀態；歷史數據難以保存與分析，多數 PLC 只保留近期少量資料，難以回溯半年前的壓力趨勢做設備健康評估。

RS485 Modbus 訊號本身已經是結構化的數位資料，這代表把它送上雲端不需要額外的類比轉數位轉換，只需要一個閘道器把 Modbus RTU 訊號轉成 AWS IoT Core 認得的 MQTT 訊息即可。這也是這篇文章要拆解的核心路徑。

整體架構：從壓力表到雲端儀表板

ATLANTIS DPS-2.5SPD3 (RS485 Modbus)
                                │
                                ▼
                          RS485 轉 MQTT 閘道器 (現場端)
                                │  MQTT / TLS
                                ▼
                           AWS IoT Core (裝置身分驗證、訊息路由)
                                │  IoT Rule (SQL 篩選/轉換)
                                ▼
                           Amazon Timestream (時序資料庫)
                                │
                                ▼
                           Amazon QuickSight (視覺化儀表板)

整條路徑分成三個階段：現場訊號採集（RS485 → MQTT）、雲端資料接收與儲存（IoT Core → Timestream）、視覺化與分析（QuickSight）。以下逐段說明。

第一階段：RS485 訊號如何送上 AWS IoT Core

1. 現場端：RS485 轉 MQTT 閘道器

AWS IoT Core 本身不直接支援 RS485/Modbus RTU 協定，因此現場需要一個閘道設備做協定轉換。常見做法是使用工業閘道器（例如支援 Modbus 轉 MQTT 的商用閘道，或用樹莓派 / 工業電腦搭配 Python pymodbus 套件自行開發）。

閘道器的工作很單純：定期用 Modbus RTU 讀取 DPS-2.5SPD3 的暫存器數值（壓力讀值），組成 JSON 格式，再透過 MQTT 發布到 AWS IoT Core。

// 閘道器發布到 IoT Core 的 MQTT 訊息範例
                        {
                          "device_id": "dps-2.5spd3-tank01",
                          "timestamp": "2026-07-21T09:15:32Z",
                          "pressure_bar": 4.82,
                          "unit": "bar",
                          "slave_id": 1
                        }

2. 裝置身分驗證：X.509 憑證

每個閘道器在 IoT Core 註冊為一個「Thing」，並配發 X.509 憑證用於 TLS 雙向驗證。這一步確保只有授權的閘道器能夠發送資料，避免未經驗證的裝置冒充感測器發送假數據。

3. IoT Rule：篩選與轉發

IoT Core 收到訊息後，用 IoT Rule 的 SQL 語法決定這則訊息要往哪裡送。以下規則將壓力數據轉發到 Timestream：

SELECT device_id, timestamp, pressure_bar, unit
                        FROM 'sensors/pressure/+'
                        WHERE pressure_bar IS NOT NULL

實務上建議在這一層做基本的資料驗證（例如排除明顯異常的極端值、確認必要欄位存在），避免無效資料寫入 Timestream 浪費儲存成本。

第二階段：Amazon Timestream 儲存時序資料

為什麼選 Timestream 而不是一般關聯式資料庫

壓力監測資料的特性是「持續寫入、依時間查詢、很少更新」，這正是時序資料庫（Time Series Database）設計要解決的問題。相較於用 RDS 存放同樣的資料，Timestream 針對時間範圍查詢做了優化，並且內建資料生命週期管理：近期資料放在記憶體層（查詢快），較舊資料自動轉存到磁碟層（成本低），不需要自己寫排程刪資料或搬資料。

資料表設計建議

Timestream 的資料模型分為 Dimension（維度，用於篩選，如 device_id）與 Measure（量測值，如 pressure_bar）。建議設計如下：

Dimension: device_id, location, sensor_model
                        Measure:   pressure_bar (DOUBLE)
                        Time:      timestamp

這樣設計的好處是之後可以用 WHERE device_id = 'dps-2.5spd3-tank01' 快速篩選特定壓力表的歷史數據，也方便未來擴充多台壓力表時用 location 做廠區分組查詢。

第三階段：Amazon QuickSight 視覺化

建立資料來源

QuickSight 可以直接連接 Timestream 作為資料來源，不需要額外的資料匯出流程。連接後即可用 SPICE（QuickSight 的記憶體內快取引擎）加速大量歷史資料的查詢與渲染速度。

常見儀表板設計

• 即時壓力趨勢線圖：顯示最近 24 小時各壓力表的讀值變化，快速判斷是否有異常波動
• 多測點對比視圖：同時顯示多台 DPS-2.5SPD3 的壓力曲線，用於比較同批次設備的運作差異
• 歷史區間查詢：拉取任意時間區間（例如上月同期）做趨勢比對，用於設備健康評估
• 閾值告警視覺標記：在圖表上標示超出正常範圍的區段，方便工程師快速定位異常時間點

成本與維運考量

導入前的準備清單

常見問題 FAQ