工業壓力溫度計如何連上AWS IoT Core：從RS-485到雲端的第一步
工廠IT技術人員專用AWS IoT CoreRS-485 / ModbusATLANTIS 自有品牌
工業壓力溫度計如何連上AWS IoT Core：從RS-485到雲端的第一步
當柏拉圖在《對話錄》中描繪理想國時，他所追求的是一種「精密」與「秩序」——這正是 ATLANTIS（昶特）31 年來投入工業量測的初衷。我們的品牌使命「Re-Atlantis」，不只是做出精準的壓力錶與溫度計，更希望把這份精密延伸到工業4.0的雲端世界。這篇文章，就是我們從現場儀錶工程師的角度，寫給工廠IT技術人員的第一份「感測器上雲」實戰手冊。詳見 ATLANTIS 品牌故事。
一、為什麼工廠要把壓力溫度計連上 AWS IoT Core？
過去工廠的壓力錶、溫度計多半只在「現場可視」——工程師巡檢、抄錶、記錄在紙本或 Excel。但隨著工業4.0與智慧製造趨勢，愈來愈多工廠導入雲端監控，原因很簡單：異常事件的發現速度，決定了停機成本的大小。
vs 人工巡檢4小時
可靠度實測值
可降低的佈線成本
（原4小時人工巡檢）
這些數字並非空泛的行銷用語，而是我們在 天然氣管線與能源產業壓力監控案例中實際觀察到的成效：全台管線監測點從「24小時人工巡檢」改為「15秒自動採樣」後，異常警報延遲從4小時降到3分鐘，成功預防2次洩漏事件。同樣的邏輯，也適用於一般工廠的壓力溫度監控——只是規模更小、導入門檻更低。
本文適合誰？
本文設定的讀者是工廠IT技術人員、電控工程師、自動化課的維護人員——你可能懂PLC、懂網路，但對AWS IoT Core這類雲端服務還在入門階段。我們會用最短的範例程式，把「RS-485感測器 → Modbus閘道器 → AWS IoT Core → Lambda」這條路徑講清楚，讓你在一個下午內完成第一次資料串接。
二、系統架構總覽：從變送器到雲端的五個階段
這張圖是本系列文章的骨架，也是本篇要拆解的重點：階段①～②是儀錶與現場通訊層，③是資料橋接層，④～⑤是雲端服務層。本篇聚焦在①到④，也就是「怎麼把RS-485訊號送進AWS IoT Core」；後續系列文章會深入 Lambda 解析、DynamoDB儲存、告警系統與儀表板串接。
RS-485 為什麼是工業現場的主流通訊介面？
在工業儀錶領域，RS-485搭配Modbus RTU協定，是過去30年最普及的數位通訊標準，原因有三：抗雜訊能力強（差動訊號傳輸，適合馬達、變頻器林立的工廠環境）、傳輸距離長（理論上可達1,200公尺）、多點集成（一條匯流排最多可連接32個裝置，甚至透過中繼器擴充到127個）。這也是為什麼 ATLANTIS 的多款溫度、壓力、溫濕度變送器都支援RS-485/Modbus輸出的原因——它是連接「舊有現場設備」與「新雲端架構」之間最務實的橋樑。
三、通訊介面比較：RS-485 vs 4-20mA vs HART vs 無線
在規劃上雲架構之前，工廠IT技術人員第一件要確認的事，是「現場儀錶到底輸出什麼訊號」。以下整理四種常見工業通訊介面的技術特性，協助你判斷升級路徑。
| 通訊介面 | 訊號型態 | 最大距離 | 多點集成 | 上雲難易度 | 典型應用 |
|---|---|---|---|---|---|
| 4-20mA 類比 | 類比電流 | 約300～500公尺 | 不支援（點對點） | 需加裝ADC模組 | 單點壓力/溫度傳送器 |
| RS-485 / Modbus RTU | 數位差動訊號 | 約1,200公尺（可中繼延伸） | 最多32～127個裝置 | 中等（需Modbus閘道器） | 多點溫度/壓力監控網路 |
| HART | 4-20mA疊加數位訊號 | 約1,500公尺 | 多點模式最多15個 | 中等偏高（需HART Modem） | 智能型壓力/溫度傳送器 |
| 無線（LoRaWAN/NB-IoT） | 無線射頻 | 依環境可達數公里 | 大量節點 | 視閘道器整合能力 | 戶外分散式監測點 |
對於多數中小型工廠而言，RS-485/Modbus RTU 是投資報酬率最高的選擇：既能沿用現有配線與PLC架構，又能透過一台Modbus閘道器同時將多支變送器的數據集中上傳雲端，不需要為每一支儀錶單獨佈線到雲端閘道器。
ATLANTIS 支援 RS-485 / 數位輸出的溫度壓力量測產品
DPS-2.5SPD3 多功能壓力開關 —— 可選配 4-20mA / 1-5V 類比輸出或 RS-485 數位輸出，全量程精度0.5%，防護等級IP65
THT-S81 室內溫濕度傳送器 —— 支援 RS485 Modbus RTU 通訊，量測範圍 -20℃～80℃、0～95%RH，適合機房與潔淨室環境雲端監控
SDPT-3100 智能型壓力傳送器 —— 基於微處理器的HART協議傳送器，支援遠端組態與診斷，適合需要高精度與自動溫度補償的雲端監控應用
STT HART智能型溫度傳送器 —— 通用型一體化溫度傳送器，支援熱電阻/熱電偶輸入，透過HART通訊裝置進行遠端組態，可整合至雲端監控架構
更多產品規格請參考 ATLANTIS 產品型錄與工業4.0壓力感測器整合指南。
四、實作第一步：Modbus RTU 讀取 RS-485 溫度壓力數據（Python範例）
在把資料送上AWS之前，第一步永遠是「先在本地端把感測器的數值讀出來」。以下範例使用 Python 的 pymodbus 套件，透過RS-485轉USB轉接器，讀取一支支援Modbus RTU的ATLANTIS溫度傳送器的暫存器數值。
範例一：用 pymodbus 讀取 Modbus RTU 溫度數據
from pymodbus.client import ModbusSerialClient
client = ModbusSerialClient(
port="/dev/ttyUSB0", # Windows請改為 "COM3" 等
baudrate=9600,
parity="N",
stopbits=1,
bytesize=8,
timeout=1
)
client.connect()
# 讀取從站ID=1，起始暫存器0，讀取2個暫存器（依產品手冊調整位址）
result = client.read_holding_registers(address=0, count=2, slave=1)
if not result.isError():
raw_value = result.registers[0]
temperature = raw_value / 10.0 # 依產品規格書換算比例
print(f"目前溫度讀值：{temperature} °C")
else:
print("讀取失敗，請檢查接線與從站位址")
client.close()
這段程式只有20行左右，卻是整個上雲架構的第一塊拼圖。務必先確認三件事：變送器的Modbus從站位址（Slave ID）、暫存器位址對照表（產品手冊會標示）、以及數值換算比例。這些資訊在ATLANTIS各產品型錄的技術規格中都會提供，若不確定可直接聯繫我們的應用工程團隊協助對照。
五、把數據送上 AWS IoT Core：MQTT 發布範例
確認能穩定讀到現場數值後，下一步是把資料透過MQTT協定發布到AWS IoT Core。這裡需要先在AWS IoT Core主控台完成三件事：建立「物件（Thing）」、下載X.509憑證、設定IoT Policy授權發布權限。完成後，就能用以下Python範例將讀取到的溫度數據發布上雲。
範例二：用 AWSIoTPythonSDK 發布 MQTT 訊息
import json, time
from AWSIoTPythonSDK.MQTTLib import AWSIoTMQTTClient
mqtt_client = AWSIoTMQTTClient("factory-line1-thermometer-01")
mqtt_client.configureEndpoint(
"your-endpoint.iot.ap-northeast-1.amazonaws.com", 8883
)
mqtt_client.configureCredentials(
"root-CA.crt", "private.pem.key", "certificate.pem.crt"
)
mqtt_client.configureConnectDisconnectTimeout(10)
mqtt_client.configureMQTTOperationTimeout(5)
mqtt_client.connect()
payload = {
"device_id": "ATL-STT-001",
"temperature": 68.4,
"unit": "C",
"timestamp": int(time.time())
}
mqtt_client.publish(
"factory/line1/temperature", json.dumps(payload), 1
)
print("已發布溫度數據至 AWS IoT Core")
mqtt_client.disconnect()
把範例一（讀取RS-485數據）與範例二（發布MQTT）合併成一個迴圈，加上例外處理與斷線重連機制，就是一套最基礎但可運作的「感測器上雲」程式。這也是我們建議工廠IT技術人員在概念驗證（PoC）階段採用的最小可行架構——先求穩定連線，再考慮效能優化。
下一步：用 Lambda 接收並處理數據
當數據透過MQTT送達AWS IoT Core後，可以設定「規則引擎（Rules Engine）」將符合條件的訊息觸發Lambda函式執行運算。以下是一個最簡單的Lambda範例，用來接收溫度數據並判斷是否超過警戒值。
範例三：AWS Lambda 接收溫度數據並判斷異常
def lambda_handler(event, context):
temperature = event.get("temperature")
device_id = event.get("device_id", "unknown")
# 簡易門檻判斷，正式環境建議搭配歷史數據做動態閾值
if temperature is not None and temperature > 80:
print(f"[警報] 裝置 {device_id} 溫度異常：{temperature}°C")
# 此處可接續呼叫 SNS 發送告警通知
else:
print(f"裝置 {device_id} 溫度正常：{temperature}°C")
return {"statusCode": 200, "body": json.dumps("處理完成")}
這個Lambda函式只做了最基本的門檻判斷，但已經足以說明整條資料管線的核心價值：從感測器到告警，中間不需要任何人工巡檢介入。後續系列文章會進一步展開SNS告警、DynamoDB歷史記錄與CloudWatch監控等主題。
六、精度與資料可信度：為什麼儀錶等級決定了雲端數據的價值
很多工廠IT工程師會忽略一件事：再好的雲端架構，也救不回一支精度不足的感測器。當你把數據自動化、即時化、雲端化之後，任何量測誤差都會被放大成「錯誤的自動化決策」。以下是不同精度等級的溫度壓力儀錶，在雲端監控情境下可能造成的影響。
| 精度等級 | 在50°C量測情境下的誤差 | 雲端自動化可能後果 | 建議適用場合 |
|---|---|---|---|
| ±3%（指針式） | ±1.5°C | 誤報率高，告警系統形同虛設 | 僅供人工目視，不建議接雲端 |
| ±1%（一般數位式） | ±0.5°C | 可用但需人工複核異常事件 | 一般監控用途 |
| ±0.5%（ATLANTIS標準型） | ±0.25°C | 自動化告警可靠度可達98%以上 | 製程控制、雲端自動告警 |
| ±0.2%（HART智能型如SDPT-3100） | ±0.1°C | 可用於自動化參數調整與趨勢預測 | 關鍵製程、精密溫控 |
換句話說，「感測器上雲」這件事的順序應該是：先確保現場儀錶精度足夠，再談雲端架構。這也是為什麼我們建議工廠IT技術人員在規劃AWS IoT專案初期，就把儀錶部門或設備商拉進來一起討論，而不是等到雲端架構完成後才發現「數據不準」的問題。
簡易趨勢圖：自動化監控頻率與異常發現時間的關係
七、資安與現場網路：工廠IT最常見的疑慮
把工廠現場資料送上公有雲，資安永遠是第一個被提出的問題。以下是我們在協助工廠導入雲端監控時，最常被工廠IT主管詢問的架構建議。
| 資安考量 | 建議作法 | 對應AWS服務/功能 |
|---|---|---|
| 現場網路不直接暴露於公網 | 採用單向資料上傳架構，現場閘道器僅發布不接收指令 | IoT Policy 限制 publish-only 權限 |
| 裝置身分驗證 | 每台閘道器使用獨立X.509憑證，禁止共用憑證 | AWS IoT Core 裝置憑證管理 |
| 傳輸加密 | 全程使用TLS 1.2以上加密傳輸 | MQTT over TLS（預設8883埠） |
| 異常裝置阻斷 | 單一裝置異常時可立即撤銷憑證，不影響其他產線 | IoT Core 憑證撤銷機制 |
| 內網與外網隔離 | 閘道器建議部署於DMZ或獨立VLAN，不與辦公室網路混用 | 需搭配工廠既有防火牆/VLAN規劃 |
值得注意的是，資安架構的第一道防線，其實還是在「現場儀錶」這一端。若使用防爆型或工業級變送器，本身在硬體層級就具備更嚴謹的電氣隔離與訊號穩定性，能降低因電氣雜訊或接地不良導致的異常訊號誤觸發雲端告警。
八、案例分享：某中部精密機械廠的溫度雲端監控導入過程
以下案例經匿名化處理，客戶為台灣中部一家精密機械加工廠，主要痛點是「多台加工機的液壓油溫需要人工每2小時巡檢一次，記錄在紙本表單」。
| 導入階段 | 作法 | 耗時 | 成效 |
|---|---|---|---|
| 階段一：儀錶盤點與選型 | 將既有指針式溫度計替換為支援RS-485輸出的數位溫度傳送器 | 1週 | 取得可數位讀取的溫度數據來源 |
| 階段二：RS-485集中佈線 | 8支變送器串接於同一條RS-485匯流排，接至1台Modbus閘道器 | 3天 | 佈線成本較個別網路佈線降低約65% |
| 階段三：AWS IoT Core串接 | 閘道器透過MQTT每30秒發布一次數據 | 2天（含測試） | 建立雲端即時監控看板 |
| 階段四：Lambda告警邏輯 | 溫度超過閾值時觸發SNS簡訊通知值班人員 | 1天 | 異常反應時間從2小時降至5分鐘內 |
資深工程師賴祥德分享：「很多工廠IT一開始會覺得AWS IoT Core很複雜，但其實整套架構拆解開來，跟工廠既有的PLC通訊邏輯是相通的——只是把『本地HMI顯示』換成『雲端MQTT發布』。真正困難的不是雲端服務本身，而是現場感測器的訊號穩定性與精度是否足夠支撐自動化決策。」
九、AWS IoT Core 費用估算：小規模PoC到底要花多少錢？
| 項目 | 計費方式（依AWS官方公告，實際費率請以AWS官網最新公告為準） | 10支感測器/每30秒上傳一次的估算 |
|---|---|---|
| 連線費用 | 依連線分鐘數計費 | 每月數美元等級 |
| 訊息傳遞費用 | 依訊息數量計費（每百萬則訊息一個級距） | 每月訊息量約86.4萬則，落在入門級距 |
| 規則引擎執行 | 依規則觸發次數計費 | 視告警規則複雜度而定 |
| Lambda執行 | 有免費額度（每月100萬次請求、40萬GB-秒運算時間） | 小規模PoC通常落在免費額度內 |
對大多數中小型工廠的PoC（概念驗證）階段而言，10支以內的感測器、30秒回報一次的頻率，每月雲端費用通常落在入門等級，遠低於「一次人工巡檢異常延誤造成的停機損失」。建議工廠IT在導入前，先用AWS官方定價計算器搭配實際感測器數量與回報頻率試算，並持續關注AWS官網公告的最新費率。
資料來源與延伸閱讀
本文技術架構參考 AWS IoT Core 官方文件（docs.aws.amazon.com/iot）、Modbus組織發布之Modbus應用協定規範（modbus.org），以及 ATLANTIS 內部產品技術規格書。防爆等級與精度數據引用自國際電工委員會（IEC）Ex系列標準與ATLANTIS產品出廠檢驗報告。市場數據建議讀者於決策前查閱最新版官方資料。
十、內連延伸閱讀
- 國防工業 × 能源安全 高風險環境壓力監控完整選型指南 —— 了解RS-485遠距監測在能源產業的實戰案例
- 工業4.0 壓力感測器整合指南｜智慧製造・IoT 遠端監控應用
- 精密溫度感測器完整決策指南
- ATLANTIS 產品型錄 —— 查詢支援RS-485/HART輸出的完整產品線
十一、20 大常見問題 FAQ（工廠IT技術人員必讀）
1. RS-485和4-20mA哪個比較適合接AWS IoT Core？
2. Modbus RTU轉MQTT需要哪些硬體？
3. AWS IoT Core的X.509憑證怎麼申請？
4. Lambda函式的免費額度夠工廠使用嗎？
5. RS-485最大傳輸距離與速率限制？
6. 工廠現場如何避免MQTT斷線導致數據遺失？
7. AWS IoT Core和AWS IoT Greengrass差在哪？
8. 溫度變送器輸出4-20mA vs RS-485該怎麼選？
9. Modbus TCP閘道器怎麼設定IP才能連上AWS？
10. 資安：工廠內網如何安全地把數據送上雲端？
11. AWS IoT Core每月費用怎麼估算？
12. Lambda函式冷啟動會不會影響即時監控？
13. 防爆型溫度變送器可以直接接Wi-Fi網關嗎？
14. HART協定的傳送器可以整合進AWS IoT架構嗎？
15. 資料上雲後要保存多久？DynamoDB還是S3？
16. 現場PLC已經在用Modbus，還能疊加AWS IoT嗎？
17. AWS IoT Core規則引擎（Rules Engine）怎麼用？
18. 感測器資料異常時，Lambda怎麼觸發告警？
19. 一條RS-485匯流排最多能掛幾支變送器？
20. 導入AWS IoT監控系統，工廠IT要準備哪些技能？
十二、下一步：讓 ATLANTIS 協助你完成第一次感測器選型與上雲規劃
31年工業儀錶製造經驗 × 完整RS-485/HART數位輸出產品線
從變送器選型、Modbus暫存器對照，到現場佈線建議，我們可以陪工廠IT團隊完成第一次PoC。
📞 02-2820-3405 免費選型諮詢 📧 線上快速詢價
業務一部 Ian：ian@atlantis.com.tw ｜ 業務二部 Nori：nori@atlantis.com.tw
文章更新時間：2026年7月｜作者：ATLANTIS 應用工程團隊｜本文為系列教學文章第一篇，後續將陸續發布 Lambda 進階解析、DynamoDB 儲存架構、CloudWatch 監控與 REST API 儀表板串接等主題。