數位壓力錶／溫度計如何結合 AWS 雲端？IT 工程師與韌體開發者的 Modbus・HART 上雲整合完整指南
工業物聯網 IIoTModbus / HARTAWS IoT 整合預知性維護
數位壓力錶／溫度計如何結合 AWS 雲端？IT 工程師與韌體開發者的 Modbus・HART 上雲整合完整指南
你是負責串接現場儀表與雲端平台的 IT 工程師，還是要寫 Modbus polling 程式的開發者？這篇文章從協定層的真實限制出發，拆解「儀表輸出」與「雲端輸入」之間到底發生了什麼事，並提供石化、冷鏈、能源三種產業的實戰架構，讓你能直接對照自己的專案落地。
為什麼「Modbus/HART 輸入」這個問題本身就問錯了方向
幾乎每個第一次接觸工業儀表整合的工程師都會問同一句話：「這顆壓力錶除了 Modbus/HART 輸出，可以輸入嗎？」但這個問題背後藏著一個協定層級的誤解——現場儀表的角色設計，從來就不是接收數值。
Modbus RTU 架構下，壓力錶／溫度計幾乎全部扮演 Slave（從站）角色，被動等待上位機（PLC、閘道器、SCADA）發出 Read Holding Register（功能碼 03）或 Read Input Register（功能碼 04）指令，才會把量測值送出。HART 則是疊加在 4-20mA 迴路上的數位訊號，設計初衷是把 PV/SV/TV/QV 四個變數往外送給控制系統或手持通訊器，同時允許少量的組態寫入（如量程、阻尼、位址）。
換句話說，儀表確實能接受「寫入」——但寫入的是組態參數，不是要讓儀表顯示的即時數值。真正意義上的「外部數值輸入」，是發生在資料鏈路的更上層：閘道器、邊緣運算裝置，以及 AWS 雲端本身。
那"AWS結合"的真正意義是什麼？
當客戶問「有輸入結合 AWS 的場景嗎」，實際上想問的通常是以下三件事之一：
- 資料上雲（最常見）：把現場 Modbus/HART 讀到的數值，透過閘道器送進 AWS IoT Core，做即時儀表板、歷史趨勢、異常預警。
- 雲端下發控制（進階）：AWS 端根據運算結果，透過 Device Shadow 機制把「期望狀態」送回閘道器，閘道器再用 Modbus Write Register 寫入儀表（調整警報閾值、量程等）。
- 雙向數位分身（Digital Twin）：雲端維護一份儀表狀態的鏡像，任何一端變更都會同步，適合多廠區集中管理的場景。
儀表到 AWS 的完整資料鏈路：五層架構拆解
不管是壓力錶、溫度計還是電表，只要要串上 AWS，資料一定會經過以下五層。理解這個鏈路，你才知道「輸入」到底發生在哪一層。
第一層：現場儀表（Field Instrument）
壓力錶、溫度傳送器、液位計，透過 Modbus RTU（RS-485 雙線）或 HART（疊加在 4-20mA）把量測數值往外送。這一層只有「輸出」與「組態寫入」，沒有「即時數值輸入」。
第二層：現場匯流排（Fieldbus）
多顆儀表掛載同一條 RS-485 匯流排（Modbus RTU 最多可掛 32 個節點，實務上建議控制在 16-20 個以內以確保 polling 週期），或是 HART Multidrop 模式（同一迴路掛多顆 HART 裝置，僅限數位通訊，不再輸出 4-20mA 類比訊號）。
第三層：邊緣閘道器（Edge Gateway）——「輸入」開始出現的地方
這是整個架構的關鍵翻譯層。閘道器負責：
- Polling（輪詢）：依照設定週期主動對每個 Modbus 從站發出讀取請求
- 協定轉換：把 Modbus RTU/TCP 或 HART 訊號轉成 MQTT、HTTPS 或 OPC-UA
- 寫入代理：接收雲端下發的指令，轉換成 Modbus Write Register 或 HART 寫入命令送回儀表——這才是真正的"輸入"發生的位置
以下是閘道器端典型的 Modbus RTU 讀取邏輯（使用 Python pymodbus 函式庫），每次 polling 讀取壓力值與溫度值後，組裝成 JSON 發布到 MQTT：
from pymodbus.client import ModbusSerialClient
import json, time, paho.mqtt.client as mqtt
# RS-485 連線設定
client = ModbusSerialClient(
port="/dev/ttyUSB0",
baudrate=9600,
parity="N",
stopbits=1,
bytesize=8,
timeout=1
)
mqtt_client = mqtt.Client()
mqtt_client.connect("a1b2c3d4e5.iot.ap-northeast-1.amazonaws.com", 8883)
def read_transmitter(slave_id: int, register: int) -> float:
# 讀取 Holding Register（FC03），2 個 word 組成 float32
result = client.read_holding_registers(
address=register,
count=2,
slave=slave_id
)
if result.isError():
raise ConnectionError(f"Slave {slave_id} 讀取失敗")
return decode_float32(result.registers)
def poll_loop():
devices = [
{"slave_id": 1, "name": "PT-01", "register": 0x0000},
{"slave_id": 2, "name": "TT-01", "register": 0x0002},
]
while True:
for dev in devices:
value = read_transmitter(dev["slave_id"], dev["register"])
payload = {
"deviceId": dev["name"],
"value": round(value, 2),
"unit": "bar" if dev["name"].startswith("PT") else "C",
"ts": int(time.time() * 1000)
}
topic = f"atlantis/plant-a/{dev['name']}/data"
mqtt_client.publish(topic, json.dumps(payload), qos=1)
time.sleep(1) # polling 週期 1 秒
if __name__ == "__main__":
poll_loop()第四層：AWS IoT 服務層
常見的服務組合：
| AWS 服務 | 角色 | 適用情境 |
|---|---|---|
| AWS IoT Core | MQTT Broker，接收裝置訊息、管理裝置憑證 | 幾乎所有場景的入口點 |
| AWS IoT SiteWise | 工業資料模型化，原生支援資產階層（廠區→產線→設備→標籤） | 多廠區、多設備的製程資料彙整 |
| AWS IoT SiteWise Edge Gateway | 可安裝在工業電腦上的邊緣軟體，內建 Modbus/OPC-UA 連接器 | 不想自建 Greengrass 應用程式的場景 |
| AWS IoT Greengrass | 可程式化邊緣運算框架，能跑自訂 Lambda 函式做本地推論 | 需要離線運算、OTA 更新、自訂協定轉換邏輯 |
| Amazon Kinesis Data Streams | 高頻即時資料流處理 | 秒級或更高頻率的溫度/壓力數據分析 |
| Amazon Timestream | 時序資料庫，針對感測器數據優化 | 長期歷史趨勢查詢、異常比對 |
| AWS Lambda | 事件驅動運算，觸發規則引擎 | 異常值判斷、警報邏輯 |
| Amazon SNS | 訊息推播（簡訊、Email、Slack Webhook） | 異常時通知維運人員 |
| Amazon QuickSight | 商業智慧儀表板 | 管理層/工程主管的視覺化報表 |
第五層：Device Shadow——雙向同步的關鍵機制
AWS IoT Device Shadow 是實現「雲端輸入」最乾淨的做法。每個裝置在雲端有一份 JSON 格式的「影子文件」，分成：
- reported（回報狀態）：閘道器定期把儀表實際讀到的數值寫進這裡
- desired（期望狀態）：雲端或維運人員設定「希望儀表變成的狀態」，例如「警報閾值改成 8.5 bar」
閘道器訂閱 desired 的變更事件，一旦偵測到差異，就會用 Modbus Write Register 或 HART 命令把新設定寫入實體儀表，完成後再更新 reported，形成完整的閉環。這個機制本質上就是把「輸入儀表」這件事，包裝成雲端原生的非同步狀態同步，而不是即時的數值注入。
Modbus RTU vs HART：協定層技術對照表
在設計 AWS 整合架構之前，先搞清楚這兩種協定的物理層差異，會直接影響你的閘道器選型與 polling 邏輯設計。
| 比較項目 | Modbus RTU | HART |
|---|---|---|
| 實體層 | RS-485 差動雙線 | 疊加於 4-20mA 迴路上的 1200Hz FSK 訊號 |
| 主從架構 | Master-Slave，一個主站對多個從站 | Point-to-Point（單點模式）或 Multidrop（多點） |
| 最大掛載數 | 理論 247 個位址，實務建議 16-32 個 | Multidrop 最多 15 個裝置（依電流負載而定） |
| 資料更新速率 | 依 Baud Rate 與 polling 週期，通常 1-5 次/秒/裝置 | 約 2-3 次/秒（FSK 調變速率限制） |
| 是否保留類比輸出 | 純數位，無類比訊號 | Point-to-Point 模式仍保留 4-20mA；Multidrop 模式類比訊號固定為 4mA |
| 多變量傳輸 | 依暫存器映射自訂，理論上無上限 | 固定 4 組（PV/SV/TV/QV） |
| 組態寫入方式 | Write Single/Multiple Register（FC06/FC16） | HART Command（如 Command 35 設定量程） |
| 典型閘道器 | Modbus-to-MQTT 轉換器、SiteWise Edge、Greengrass | HART-to-Modbus 轉換器（如 HRT-710/310 類產品），再接 Modbus 閘道 |
三大產業實戰案例：石化、冷鏈、能源
案例一：石化／半導體廠 — 數百顆傳送器的預知性維護系統
場景：某石化製程廠區有超過 300 顆壓力／溫度傳送器分散於反應槽、蒸餾塔、輸送管線，過去採人工巡檢紀錄，異常反應時間平均超過 45 分鐘。
架構：每 20-30 顆傳送器分區掛載一條 Modbus RTU 匯流排（RS-485），區域閘道器採用 AWS IoT SiteWise Edge Gateway，透過乙太網路上傳 SiteWise，再串接 QuickSight 建立即時製程儀表板。異常規則透過 SiteWise 的資產模型定義（如壓力超過歷史平均值 3 個標準差），觸發 Lambda 呼叫 SNS 通知值班工程師。
成效方向：導入後多數廠區能將異常發現時間從人工巡檢的數十分鐘級，壓縮到分鐘級以內，同時累積的歷史數據可用於後續故障率分析與備品庫存優化。
案例二：冷鏈物流／CDU 液冷系統 — 即時溫度串流分析
場景：AI 伺服器機房液冷 CDU（Cooling Distribution Unit）系統需要毫秒到秒級的溫度與差壓數據，因為液冷系統一旦過熱或流量異常，硬體損壞速度遠比傳統氣冷系統快。
架構：溫度傳送器與差壓傳送器透過 Modbus RTU 輸出，經工業閘道器轉 MQTT 發布至 AWS IoT Core，由 Amazon Kinesis Data Streams 做即時串流處理，並用 Lambda 進行滑動視窗異常偵測（如溫度斜率超過設定閾值），異常時透過 SNS 發送 Slack Webhook 通知維運團隊，同時寫入 Timestream 供後續趨勢分析。
技術重點：液冷系統的資料頻率需求高於一般 HVAC 監控，因此建議 Modbus polling 週期設定在 1 秒以內，並評估是否需要多顆閘道器分散 polling 負載，避免單一閘道器成為瓶頸。
案例三：能源管理（電表整合） — 用能趨勢分析與異常回饋
場景：製造業廠區需要同時監控多台電表與環境溫度計，做能源使用效率（EUI）分析，並在異常用電模式出現時（如設備老化導致的功率飄移）提前預警。
架構：多台電表／溫度計透過 Modbus RTU 閘道器彙總資料，上傳 AWS IoT Analytics 建立資料管道（Pipeline），進行資料清洗與 SQL-like 查詢後，輸出至 QuickSight 建立用能趨勢報表。進階場景可加入 Amazon Lambda 做週期性用能基準比對，異常時觸發告警。
延伸應用：若廠區同時導入溫度感測器（如冷卻水塔、變壓器室溫度監控），可將溫度與電力數據整合分析，找出因散熱不良導致的效率下降問題，這正是 ATLANTIS 溫濕度傳送器系列常見的應用切入點。
雙向控制怎麼做？Device Shadow 與寫入指令實作邏輯
如果你的專案確實需要「雲端下發指令回儀表」，以下是實作上需要注意的技術細節。
典型寫入流程
- 維運人員或自動化規則在 AWS IoT Console／API 更新 Device Shadow 的
desired欄位，例如將某顆壓力錶的高限警報值改為 8.5 bar - 閘道器（Greengrass 或自訂 MQTT client）訂閱該裝置的 Shadow Delta Topic，收到變更通知
- 閘道器將 desired 值轉換成對應的 Modbus Write Register 指令（功能碼 06 或 16），或 HART Command 寫入命令
- 閘道器透過 RS-485 或 HART 迴路將寫入指令送至實體儀表
- 儀表確認寫入成功後，閘道器讀回新設定值，更新 Shadow 的
reported欄位，完成閉環同步
Device Shadow 的資料結構是標準 JSON，以下是一個壓力傳送器的 Shadow 文件範例——維運人員把 desired 的警報閾值從 10 bar 改成 8.5 bar，閘道器訂閱到差異後會執行寫入：
{
"state": {
"desired": {
"alarmHighLimit": 8.5,
"damping": 0.5,
"unit": "bar"
},
"reported": {
"alarmHighLimit": 10.0,
"damping": 0.5,
"unit": "bar",
"lastValue": 6.42,
"connected": true
}
}
}閘道器端訂閱 Shadow Delta Topic，收到差異後轉換成 Modbus Write Register 指令送回儀表：
const mqtt = require('mqtt');
const ModbusRTU = require('modbus-serial');
const modbusClient = new ModbusRTU();
const deltaTopic = '$aws/things/PT-01/shadow/update/delta';
mqttClient.on('message', async (topic, message) => {
if (topic !== deltaTopic) return;
const delta = JSON.parse(message.toString()).state;
// 差異出現在警報閾值 → 寫入 Modbus Holding Register
if (delta.alarmHighLimit !== undefined) {
await modbusClient.setID(1); // slave id = PT-01
await modbusClient.writeRegisters(
0x0010,
encodeFloat32(delta.alarmHighLimit)
);
// 寫入成功後回報 reported，完成 Shadow 閉環
mqttClient.publish(
'$aws/things/PT-01/shadow/update',
JSON.stringify({
state: { reported: { alarmHighLimit: delta.alarmHighLimit } }
})
);
}
});常見可寫入的儀表參數
| 參數類型 | 典型用途 | Modbus 對應操作 |
|---|---|---|
| 量程設定（LRV/URV） | 變更 4-20mA 對應的下限/上限值 | Write Holding Register |
| 警報閾值（高低限） | 調整繼電器動作點 | Write Holding Register |
| 阻尼時間常數 | 抑制訊號雜訊、震盪 | Write Holding Register |
| Modbus 從站位址 | 系統整合、避免位址衝突 | Write Single Register（需重啟生效） |
| 零點/滿量程校正 | 定期校正，部分機種支援遠端在線校正 | Write Register + 校正命令序列 |
常見閘道器選型比較表
選擇閘道器時，工程師常見的困惑是「該用現成硬體閘道器，還是自己在工業電腦上跑 Greengrass？」以下整理決策參考。
| 方案 | 優點 | 限制 | 適合情境 |
|---|---|---|---|
| 專用 Modbus-to-MQTT 硬體閘道器 | 開箱即用、設定簡單、穩定性高 | 客製化邏輯彈性較低 | 標準化 polling 需求、快速導入 |
| AWS IoT SiteWise Edge Gateway | 原生對接 SiteWise 資產模型、免寫程式碼 | 需符合 SiteWise 的資料模型架構 | 多資產階層管理、製程數據標準化 |
| AWS IoT Greengrass（自訂應用） | 最高彈性，可跑自訂 Lambda 做邊緣運算與離線推論 | 需要開發與維護程式碼 | 需要客製協定轉換邏輯、邊緣 AI 推論 |
| HART-to-Modbus 轉換模組 | 解決 HART 訊號無法直接被一般 Modbus 閘道器讀取的問題 | 多一層轉換設備與位址對應表維護 | 現場仍有大量既有 HART 傳送器 |
給工程師的技術 FAQ
Q1. 壓力錶／溫度計的 Modbus 真的完全不能「輸入」數值嗎？
嚴格來說，儀表不接受外部數值取代自己的量測結果——量測值永遠來自感測元件本身。但儀表可以接受「組態寫入」，如量程、警報閾值、阻尼參數，這類寫入透過 Modbus Write Register（FC06/16）完成，屬於設定層級的輸入，不是數值層級的輸入。
Q2. HART 和 Modbus 可以同時存在同一顆儀表上嗎？
可以。許多智能傳送器同時支援 HART（疊加在 4-20mA 上）與獨立的 RS-485 Modbus 輸出，兩種協定可並行運作，端視控制系統端要用哪一種介接。選型時建議確認廠商是否提供雙協定選項，避免後續系統升級時被迫更換硬體。
Q3. AWS IoT Core 與 AWS IoT SiteWise 該選哪一個？
IoT Core 是底層的 MQTT Broker 與裝置管理服務，任何 IoT 專案幾乎都會用到。SiteWise 則是建立在 IoT Core 之上的工業資料模型層，原生支援資產階層（廠區/產線/設備）與 Modbus/OPC-UA 連接器。如果你的需求單純是資料上傳與簡單規則觸發，IoT Core + Lambda 已足夠；如果需要管理數百個資產與標籤的階層關係，SiteWise 能省下大量自建資料模型的工時。
Q4. Modbus RTU 一條 RS-485 匯流排最多可以掛幾顆儀表？
協定規格上位址範圍是 1-247，理論可掛 247 個從站，但實務上受限於通訊距離（RS-485 標準傳輸距離約 1200 公尺內）、終端電阻匹配、以及 polling 週期需求，建議控制在 16-32 個裝置以內，確保每顆裝置的資料更新頻率不會因為排隊等待而過度延遲。
Q5. 為什麼我的 Modbus 讀取數值會偶爾出現亂碼或逾時？
常見原因包括：終端電阻未正確設置（120Ω）、傳輸線長度超過建議距離未加中繼器、Baud Rate 或校驗位設定不一致、多台裝置位址衝突、以及電磁干擾未做好屏蔽接地。建議先用 Modbus 除錯工具（如 Modbus Poll）單獨測試每顆裝置，排除匯流排整體問題後再介接閘道器。
Q6. HART Multidrop 模式下為什麼類比輸出會固定在 4mA？
因為 Multidrop 模式下多顆裝置共用同一條迴路，若每顆裝置都輸出獨立的類比電流值，迴路上的總電流會混亂而無法判讀。因此 HART 規格規定 Multidrop 模式下所有裝置的類比輸出固定為 4mA（僅代表裝置存在，不代表量測值），量測數據改由數位訊號傳輸。
Q7. AWS IoT Greengrass 需要多強的邊緣硬體才能跑？
Greengrass Core 軟體本身對硬體要求不高，官方建議至少 1GB RAM 與支援的作業系統（Linux/Windows），實務上工業樹莓派等級的裝置即可運行基本的 Modbus polling 與 MQTT 發布邏輯。若需要跑邊緣 AI 推論模型，才需要評估額外的運算資源。
Q8. Device Shadow 的資料多久同步一次？會不會有延遲？
Device Shadow 是事件驅動的，desired 狀態一旦被修改，會立即透過 MQTT Delta Topic 推送給訂閱的裝置，延遲通常在秒級以內（取決於網路狀況與裝置端輪詢邏輯）。這不是定時輪詢機制，而是即時推播，因此比傳統的定期同步更有效率。
Q9. 我可以用同一個閘道器同時處理 Modbus RTU 和 HART 訊號嗎？
需要視閘道器硬體規格而定。部分工業閘道器內建多協定支援卡，可同時接 RS-485 Modbus 與 HART Modem 模組；若閘道器僅支援單一協定，則需先透過 HART-to-Modbus 轉換模組將 HART 訊號轉為 Modbus 位址映射，再統一由閘道器處理。
Q10. 上雲的資料要怎麼避免佔用過多頻寬與儲存成本？
常見做法是在邊緣端先做資料篩選與聚合，例如只上傳變化量超過設定閾值的數據（Deadband 過濾），或是將高頻原始資料做本地聚合（如 1 分鐘平均值）後才上傳，原始高頻資料僅保留在本地做短期除錯用途。AWS IoT SiteWise 內建部分資料轉換功能可以協助處理。
Q11. 石化廠這類防爆區域的儀表可以直接掛 Modbus 匯流排上雲嗎？
防爆區域內的儀表本體需符合 Ex d / ATEX / IECEx 等防爆認證，但 Modbus RTU 通訊本身（RS-485 訊號線）若未特別隔離，仍需評估是否需要本安（Intrinsically Safe）隔離柵或將閘道器設置在安全區。建議在專案前期就與儀表廠商確認防爆等級與通訊介面的相容性。
Q12. 溫度與壓力數據上傳 AWS 後，異常判斷邏輯該寫在哪一層？
簡單的閾值判斷（如超過高限）可以直接在邊緣閘道器完成，減少往返雲端的延遲，適合需要快速反應的安全聯鎖情境。複雜的趨勢分析、多變數關聯判斷（如溫度與壓力同時異常才觸發），則建議放在雲端用 Lambda 搭配 Kinesis Analytics 或 SiteWise 的運算表達式處理。
Q13. 液冷 CDU 系統的溫度監控，多快的 polling 頻率才夠用？
視系統設計的熱容量與失效速度而定，一般 HVAC 空調監控 5-10 秒週期已足夠，但液冷 CDU 系統因為流體循環速度快、熱慣性小，建議至少 1 秒或更高頻率，並搭配差壓監測，才能在流量異常初期就捕捉到訊號。
Q14. Modbus TCP 和 Modbus RTU 在 AWS 整合架構上有什麼差異？
Modbus TCP 直接透過乙太網路傳輸，較容易與現有 IT 網路架構整合，也更適合搭配虛擬化的閘道器軟體（如跑在既有伺服器上的 Greengrass）。Modbus RTU 則需要 RS-485 轉乙太網路的轉換器（Gateway/Converter）才能上網。若廠區儀表支援雙協定，優先選擇 Modbus TCP 可簡化後續整合工作。
Q15. 電表整合的用能分析，AWS IoT Analytics 和一般的資料庫方案有什麼差別？
AWS IoT Analytics 專為 IoT 時序資料設計，內建資料清洗、轉換、批次分析的 Pipeline 機制，可以直接處理不規則抵達的感測器資料。若你已經有成熟的資料工程團隊與既有資料倉儲（如 Redshift），也可以選擇自建 Pipeline，兩者各有優劣，取決於團隊既有的技術棧與維運能力。
Q16. 一顆傳送器同時支援 4-20mA、HART、RS-485 三種輸出，實務上該怎麼接線？
4-20mA 與 HART 共用同一組端子（HART 訊號疊加在類比迴路上），RS-485 Modbus 則需要獨立的兩線端子（A/B）。多數智能傳送器會在接線圖上明確標示，建議依照廠商提供的接線圖施工，並避免將 RS-485 訊號線與動力線同管槽配線，減少電磁干擾。
Q17. 如何確認閘道器與 AWS IoT Core 之間的通訊安全性？
AWS IoT Core 採用 X.509 憑證進行裝置身份驗證，並強制使用 TLS 加密傳輸，閘道器需妥善保管私鑰，避免憑證外洩。建議搭配 AWS IoT Device Defender 監控異常連線行為，並定期輪替憑證。
Q18. 儀表韌體版本不同，Modbus 暫存器位址會不會不一樣？
會。不同韌體版本可能調整暫存器映射表，因此建議在專案初期向廠商索取對應韌體版本的 Modbus 位址對照表（Register Map），並在閘道器設定中明確記錄韌體版本，避免日後批次更換設備時因位址不一致導致資料錯亂。
Q19. AWS 端可以直接對儀表下「歸零校正」指令嗎？
部分支援遠端校正功能的智能傳送器，可以透過 HART Command 或特定 Modbus 暫存器觸發歸零校正流程，但這類操作建議保留人工確認機制（如雙重驗證或現場派工單），避免在製程運轉中誤觸發校正導致量測中斷。
Q20. 中小型工廠沒有專職 IT 團隊，適合自己導入 AWS IoT 整合嗎？
如果團隊沒有雲端架構經驗，建議先從 AWS IoT SiteWise Edge Gateway 這類低程式碼方案開始，搭配儀表廠商提供的 Modbus 位址對照表，多數情況下可以在不寫大量客製程式的狀況下完成基本的資料上雲與儀表板建置，待需求成熟後再評估是否導入 Greengrass 客製化邏輯。
ATLANTIS 支援 Modbus/HART 通訊的產品線
昶特有限公司（ATLANTIS）自 1994 年起深耕台灣工業儀錶製造領域，累積超過 31 年實戰經驗，多款壓力／溫度傳送器原生支援 Modbus RTU 或 HART 通訊協定，可直接對接前述的閘道器與 AWS 整合架構。
SDPT-3100 智能型壓力傳送器
基於微處理器設計，支援 HART 協議通訊、環境溫度自動補償，適合需要高精度量測與遠端通訊的整合場景。
STT HART智能型溫度傳送器
通用型一體化溫度傳送器，透過 HART 通訊裝置安裝於感測器內部，支援遠端組態與診斷，適用於智能化溫度監控系統。
DPS-2.5SPD3 多功能壓力開關
全量程精度 0.5%（最高 0.25%），可選配 4-20mA 或 1-5V 類比輸出、RS-485 數位輸出功能，適合搭配 Modbus 閘道器整合。
SLPTX系列 HART智能型液位傳送器
德國陶瓷電容壓力傳感器，具三重防結露保護，支援 HART 通訊，適合水處理與液位監控系統整合。
DTS-STS 數位溫度開關
標配兩組開關輸出、一組類比訊號輸出及 OLED 顯示螢幕，集溫度開關、變送器與顯示功能於一體。
THT-S351系列 溫濕度傳送器
進口溫濕度感測元件，可搭配 RS485 輸出，適用於能源管理場景中的環境溫濕度監控整合。
這個場景需要哪個型號？免費技術選型諮詢
告訴我們您的通訊協定需求（Modbus RTU / HART / RS-485）、掛載數量、更新頻率，ATLANTIS 工程團隊協助您完成閘道器對接前的規格確認。
豐富產品現貨・TAF 認可校正・材質證明書完整提供・24 小時緊急備品支援
業務一部 Ian：ian@atlantis.com.tw 業務二部 Nori：nori@atlantis.com.tw 電話：02-2820-3405