鍋爐蒸汽系統與航空地勤設備的 Modbus/HART 上雲整合:當雲端不能是唯一依靠
鍋爐/蒸汽系統航空地勤設備AWS IoT 整合邊緣優先 × 斷線緩存
鍋爐蒸汽系統與航空地勤設備的 Modbus/HART 上雲整合:當雲端不能是唯一依靠
前面幾篇文章的架構都預設一件事:網路是穩定的、雲端會即時回應。但鍋爐安全連鎖不能等雲端算完才動作,航空地勤設備常常在訊號死角作業。這篇拆解「邊緣優先」與「斷線緩存」這兩種跟雲端優先架構完全相反的設計原則。
當「雲端優先」架構會出人命:兩個反例
前面幾篇文章的架構邏輯都是:現場儀表 → 閘道器 → AWS → 運算判斷 → 觸發動作。這個模式在製程監控、趨勢分析、資料歸檔場景運作得很好,因為即使有幾秒延遲,也不影響安全。
但兩種場景會讓這個假設完全失效:
- 鍋爐蒸汽系統:壓力超壓是秒級事件,等雲端 Lambda 算完再觸發安全閥,時間上根本來不及。安全連鎖動作必須在現場本地完成,雲端只能做事後分析與趨勢預警。
- 航空地勤設備:機坪、機庫、跑道邊經常是 Wi-Fi/行動網路訊號死角,若架構假設「隨時能連上 AWS」,訊號一斷資料就整段遺失,稽核與維護記錄出現空缺。
這兩種場景的共同原則是:把關鍵決策留在本地,把雲端定位為「輔助分析」而非「即時控制中樞」。理解這個分工,是設計工控系統上雲架構時最容易被忽略、卻最重要的一步。
鍋爐蒸汽系統:安全連鎖為什麼不能等雲端
鍋爐與蒸汽系統的壓力、溫度監控牽涉鍋爐本體安全,多數國家法規(如台灣勞動部鍋爐及壓力容器安全規則)要求安全閥、超壓保護等連鎖機制必須具備獨立於一般控制系統的可靠性。這代表雲端架構在這裡的角色,跟前幾篇案例完全不同。
案例:鍋爐超壓保護的三層防護與雲端趨勢分析分工
場景:某工廠鍋爐系統過去僅依賴機械式安全閥與本地 PLC 連鎖,維護團隊難以取得長期壓力/溫度趨勢資料,無法預先掌握結垢、閥件老化等緩慢劣化現象,往往等到異常已經逼近安全閥動作點才發現。
架構分工:
- 第一層(毫秒級,全本地):機械式安全閥,物理動作,不依賴任何電子系統,是最後一道防線
- 第二層(秒級,本地 PLC):壓力/溫度傳送器直接接入本地 PLC,超過連鎖閾值時 PLC 立即動作(洩壓、跳機、警報),全程不經過閘道器或雲端
- 第三層(分鐘至天級,雲端輔助):同一組傳送器的資料透過獨立的 Modbus 分接(不影響安全連鎖迴路)送往閘道器,上傳 AWS 做長期趨勢分析、異常模式辨識、預知性維護排程
與前幾篇架構的關鍵差異:石化廠案例、RO 系統案例的異常判斷邏輯可以放在雲端 Lambda,因為反應時間有分鐘級的緩衝。鍋爐系統的安全連鎖完全不能依賴雲端,雲端只負責「錦上添花」的趨勢分析,絕不能是安全機制的必要環節。
以下是閘道器端的分工邏輯示意——本地連鎖判斷與雲端上傳互相獨立,即使 MQTT 發布失敗,本地連鎖仍正常運作:
import time, logging
from pymodbus.client import ModbusSerialClient
import paho.mqtt.client as mqtt
PRESSURE_INTERLOCK_LIMIT = 12.5 # bar,本地連鎖動作點(獨立於雲端)
PRESSURE_TREND_WARNING = 10.0 # bar,僅供雲端趨勢分析參考
client = ModbusSerialClient(port="/dev/ttyUSB0", baudrate=9600)
mqtt_client = mqtt.Client()
mqtt_connected = False
def trigger_local_interlock():
# 直接控制本地繼電器,不經過網路,不依賴 MQTT 或 AWS 連線狀態
gpio_relay_open("relief_valve")
logging.critical("本地安全連鎖已觸發:洩壓閥開啟")
def try_publish_to_cloud(payload: dict):
# 雲端上傳失敗不影響本地連鎖,僅記錄失敗供後續補傳
try:
mqtt_client.publish("atlantis/boiler-a/pressure", json.dumps(payload), qos=1)
except Exception as e:
logging.warning(f"雲端上傳失敗(不影響本地安全機制): {e}")
def monitor_loop():
while True:
result = client.read_holding_registers(address=0x0000, count=2, slave=1)
pressure = decode_float32(result.registers)
# 第二層:本地連鎖判斷,優先於任何網路動作,反應時間 <100ms
if pressure >= PRESSURE_INTERLOCK_LIMIT:
trigger_local_interlock()
# 第三層:雲端趨勢資料上傳,失敗也不影響上面的連鎖判斷
try_publish_to_cloud({
"pressure": round(pressure, 2),
"warning": pressure >= PRESSURE_TREND_WARNING,
"ts": int(time.time() * 1000)
})
time.sleep(0.2) # 本地監控週期 200ms,遠快於雲端 polling 頻率航空地勤設備:斷網環境下的資料完整性
航空維修、地勤液壓/氣壓系統的量測作業,經常發生在機坪、機庫深處、或停機坪邊緣,這些地點的 Wi-Fi/行動網路覆蓋常有死角。跟前面案例的架構假設不同,這裡要處理的是「連線是間歇性的」,而不是「連線穩定但偶爾延遲」。
案例:機坪液壓系統巡檢資料的離線緩存與斷點續傳
場景:地勤工程師使用行動閘道器(如工業平板搭配藍牙/USB連接的壓力傳送器)在機坪進行液壓系統巡檢,機坪部分區域網路訊號極弱或完全無訊號,過去採人工紙本記錄再事後登打,容易有記錄延遲或遺漏。
架構:行動閘道器內建本地資料庫(如 SQLite),巡檢資料先寫入本地,標記「待上傳」狀態。閘道器持續嘗試連線 AWS IoT Core,一旦偵測到網路恢復,依序補傳所有待上傳記錄,並在雲端以原始量測時間戳記排序,而非以上傳時間排序(避免資料時序錯亂)。上傳成功後才將本地記錄標記為「已同步」,即使閘道器重開機,未同步的資料也不會遺失。
與前幾篇即時上傳架構的差異:石化廠、冷鏈液冷案例都假設閘道器持續在線,資料即時發布。這裡必須額外設計「本地佇列 + 斷點續傳」機制,資料完整性優先於即時性——晚一點看到資料沒關係,但絕不能遺漏資料。
以下是行動閘道器端的離線緩存與斷點續傳邏輯:
import sqlite3, json, time
import paho.mqtt.client as mqtt
db = sqlite3.connect("local_queue.db")
db.execute("""
CREATE TABLE IF NOT EXISTS readings (
id INTEGER PRIMARY KEY AUTOINCREMENT,
device_id TEXT, value REAL, unit TEXT,
measured_at INTEGER, synced INTEGER DEFAULT 0
)
""")
def record_reading(device_id: str, value: float, unit: str):
# 不論網路狀態,先寫入本地資料庫,確保資料不遺失
db.execute(
"INSERT INTO readings (device_id, value, unit, measured_at) VALUES (?, ?, ?, ?)",
(device_id, value, unit, int(time.time() * 1000))
)
db.commit()
def is_network_available() -> bool:
try:
mqtt_client.reconnect()
return True
except Exception:
return False
def sync_pending_readings():
# 網路恢復後,依原始量測時間排序,批次補傳未同步記錄
pending = db.execute(
"SELECT id, device_id, value, unit, measured_at FROM readings WHERE synced = 0 ORDER BY measured_at ASC"
).fetchall()
for row in pending:
record_id, device_id, value, unit, measured_at = row
payload = {
"deviceId": device_id,
"value": value,
"unit": unit,
"measuredAt": measured_at, # 原始量測時間,非上傳時間
"syncedAt": int(time.time() * 1000)
}
try:
mqtt_client.publish(f"atlantis/ramp-ops/{device_id}/data", json.dumps(payload), qos=1)
db.execute("UPDATE readings SET synced = 1 WHERE id = ?", (record_id,))
db.commit()
except Exception:
break # 網路又斷線,停止本輪同步,等下次重試
def main_loop():
while True:
pressure = read_bluetooth_transmitter()
record_reading("HYD-CART-07", pressure, "bar")
if is_network_available():
sync_pending_readings()
time.sleep(5)邊緣優先 vs 雲端優先架構對照
| 比較項目 | 鍋爐蒸汽系統 | 航空地勤設備 | 前幾篇雲端優先案例 |
|---|---|---|---|
| 核心限制 | 反應時間必須是毫秒到秒級 | 網路連線是間歇性的 | 網路穩定,僅有正常延遲 |
| 安全/關鍵判斷位置 | 本地 PLC / 機械連鎖 | 不涉及即時安全連鎖 | 可放在雲端 Lambda |
| 資料上傳策略 | 即時上傳,失敗不影響本地連鎖 | 本地佇列 + 斷線重試補傳 | 即時上傳為主 |
| 雲端角色 | 趨勢分析、預知性維護 | 歷史記錄彙整、事後稽核 | 即時運算與決策中樞 |
| 失敗模式 | 雲端斷線 → 本地連鎖仍正常運作 | 雲端斷線 → 資料排隊等待,最終一致 | 雲端斷線 → 可能造成即時反應中斷 |
技術 FAQ
Q1. 鍋爐系統可以完全不上雲,只靠本地 PLC 連鎖嗎?
可以,本地連鎖本來就應該獨立運作,這是法規要求的基本安全機制。上雲的價值在於「額外」的趨勢分析與預知性維護,不是取代本地安全機制。如果因為導入 IoT 而讓安全判斷邏輯依賴雲端,反而是架構退步。
Q2. 「邊緣優先」架構下,閘道器故障了怎麼辦?
本地 PLC 與機械式安全閥應該獨立於閘道器運作,閘道器故障只會影響資料上傳與趨勢分析,不影響安全連鎖本身。這也是為什麼案例中強調「本地 PLC 直接讀取傳送器」而非「透過閘道器轉發後才判斷」的重要性。
Q3. 航空地勤設備的離線佇列,資料量太大會不會塞爆本地儲存空間?
視巡檢頻率與離線時長而定。建議評估最長可能離線時間,估算資料量並預留足夠的本地儲存空間(SQLite 資料庫搭配定期歸檔清理機制),同時設計資料保留策略(如已同步超過 N 天的本地記錄可清除,因為雲端已有備份)。
Q4. 斷線重連後大量資料同時補傳,會不會造成 AWS IoT Core 的訊息洪水?
會有這個風險,建議在補傳邏輯中加入節流機制(如每秒限制發布筆數),或使用 AWS IoT Core 的批次匯入方式,避免短時間內大量 MQTT 訊息造成節流限制觸發或費用異常增加。
Q5. 鍋爐系統的雲端趨勢分析和本地連鎖判斷用的閾值一樣嗎?
不建議一樣。雲端趨勢警告閾值應該設在比本地連鎖動作點更保守(更低)的數值,讓維運團隊有時間介入處理,避免真的逼近連鎖動作點才發現異常。案例中的 12.5 bar 連鎖點與 10.0 bar 趨勢警告點就是這個設計邏輯。
Q6. 航空地勤設備的資料時序如果依上傳時間而非量測時間記錄,會有什麼問題?
會造成歷史趨勢圖表失真——例如在無訊號區量測到的異常數值,若被記錄成「重新連線那一刻」發生,會讓後續的異常時間點分析完全錯誤,對於需要精確時間軸的維修記錄或事故調查尤其關鍵,因此務必保留原始量測時間戳記並以此排序。
Q7. 這種邊緣優先的設計思維,只適用於這兩個產業嗎?
不是,任何涉及人身安全連鎖(如壓力容器、危險氣體偵測)或網路環境不穩定(如戶外管線、偏遠廠區、船舶)的場景,都應該優先評估邊緣優先架構。核心判斷原則是:問自己「如果雲端連線斷了 5 分鐘,會不會出事」,會的話就必須把該邏輯留在本地。
ATLANTIS 對應產品線
昶特有限公司(ATLANTIS)31 年工業儀錶製造經驗,鍋爐蒸汽與航空液壓系統均有對應的高可靠度傳送器產品線,可直接搭配前述邊緣優先架構使用。

PT-UHP 超高壓型壓力傳送器
高精度金屬應變式量測元件,適用於超高壓或壓力衝擊大的量測需求,特殊一體化結構具高穩定性,適合航空液壓系統。

ATTX-200 防爆溫度傳送器
Pt100 溫度傳感器搭配補償電路,全焊接防爆外殼設計,確保危險環境中安全操作,適合鍋爐周邊高溫環境監測。

SLPTX系列 HART智能型液位傳送器
德國陶瓷電容壓力傳感器,三重防結露保護,支援 HART 通訊,適合鍋爐給水系統液位監控整合。

DPS-2.5SPD3 多功能壓力開關
可選三種雙組警報輸出(Relay、NPN、PNP),適合作為本地安全連鎖的直接觸發元件。
需要為高風險或間歇連線場景設計架構?
不論是鍋爐系統的本地安全連鎖設計,或是航空地勤的離線資料完整性,告訴我們您的場域限制與安全要求,ATLANTIS 工程團隊協助您完成儀表選型與架構分工確認。
豐富產品現貨・TAF 認可校正・材質證明書完整提供・24 小時緊急備品支援
業務一部 Ian:ian@atlantis.com.tw 業務二部 Nori:nori@atlantis.com.tw 電話:02-2820-3405