Skip to main content

鍋爐蒸汽系統與航空地勤設備的 Modbus/HART 上雲整合:當雲端不能是唯一依靠

鍋爐/蒸汽系統航空地勤設備AWS IoT 整合邊緣優先 × 斷線緩存

鍋爐蒸汽系統與航空地勤設備的 Modbus/HART 上雲整合:當雲端不能是唯一依靠

前面幾篇文章的架構都預設一件事:網路是穩定的、雲端會即時回應。但鍋爐安全連鎖不能等雲端算完才動作,航空地勤設備常常在訊號死角作業。這篇拆解「邊緣優先」與「斷線緩存」這兩種跟雲端優先架構完全相反的設計原則。

免費技術選型諮詢 →

當「雲端優先」架構會出人命:兩個反例

前面幾篇文章的架構邏輯都是:現場儀表 → 閘道器 → AWS → 運算判斷 → 觸發動作。這個模式在製程監控、趨勢分析、資料歸檔場景運作得很好,因為即使有幾秒延遲,也不影響安全。

但兩種場景會讓這個假設完全失效:

  • 鍋爐蒸汽系統:壓力超壓是秒級事件,等雲端 Lambda 算完再觸發安全閥,時間上根本來不及。安全連鎖動作必須在現場本地完成,雲端只能做事後分析與趨勢預警。
  • 航空地勤設備:機坪、機庫、跑道邊經常是 Wi-Fi/行動網路訊號死角,若架構假設「隨時能連上 AWS」,訊號一斷資料就整段遺失,稽核與維護記錄出現空缺。

這兩種場景的共同原則是:把關鍵決策留在本地,把雲端定位為「輔助分析」而非「即時控制中樞」。理解這個分工,是設計工控系統上雲架構時最容易被忽略、卻最重要的一步。

鍋爐蒸汽系統:安全連鎖為什麼不能等雲端

鍋爐與蒸汽系統的壓力、溫度監控牽涉鍋爐本體安全,多數國家法規(如台灣勞動部鍋爐及壓力容器安全規則)要求安全閥、超壓保護等連鎖機制必須具備獨立於一般控制系統的可靠性。這代表雲端架構在這裡的角色,跟前幾篇案例完全不同。

案例:鍋爐超壓保護的三層防護與雲端趨勢分析分工

場景:某工廠鍋爐系統過去僅依賴機械式安全閥與本地 PLC 連鎖,維護團隊難以取得長期壓力/溫度趨勢資料,無法預先掌握結垢、閥件老化等緩慢劣化現象,往往等到異常已經逼近安全閥動作點才發現。

架構分工:

  • 第一層(毫秒級,全本地):機械式安全閥,物理動作,不依賴任何電子系統,是最後一道防線
  • 第二層(秒級,本地 PLC):壓力/溫度傳送器直接接入本地 PLC,超過連鎖閾值時 PLC 立即動作(洩壓、跳機、警報),全程不經過閘道器或雲端
  • 第三層(分鐘至天級,雲端輔助):同一組傳送器的資料透過獨立的 Modbus 分接(不影響安全連鎖迴路)送往閘道器,上傳 AWS 做長期趨勢分析、異常模式辨識、預知性維護排程

與前幾篇架構的關鍵差異:石化廠案例、RO 系統案例的異常判斷邏輯可以放在雲端 Lambda,因為反應時間有分鐘級的緩衝。鍋爐系統的安全連鎖完全不能依賴雲端,雲端只負責「錦上添花」的趨勢分析,絕不能是安全機制的必要環節。

架構鐵律:任何會觸發安全連鎖(跳機、洩壓、警報)的判斷邏輯,都必須能在閘道器或本地 PLC 斷網狀態下正常運作。如果你的安全邏輯寫在 AWS Lambda 裡、依賴雲端 API 呼叫才能觸發,這是架構層級的重大風險,需要立即重新設計。

以下是閘道器端的分工邏輯示意——本地連鎖判斷與雲端上傳互相獨立,即使 MQTT 發布失敗,本地連鎖仍正常運作:

boiler_edge_interlock.py
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,一旦偵測到網路恢復,依序補傳所有待上傳記錄,並在雲端以原始量測時間戳記排序,而非以上傳時間排序(避免資料時序錯亂)。上傳成功後才將本地記錄標記為「已同步」,即使閘道器重開機,未同步的資料也不會遺失。

與前幾篇即時上傳架構的差異:石化廠、冷鏈液冷案例都假設閘道器持續在線,資料即時發布。這裡必須額外設計「本地佇列 + 斷點續傳」機制,資料完整性優先於即時性——晚一點看到資料沒關係,但絕不能遺漏資料。

以下是行動閘道器端的離線緩存與斷點續傳邏輯:

mobile_gateway_offline_queue.py
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 超高壓型壓力傳送器

PT-UHP 超高壓型壓力傳送器

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

ATTX-200 防爆溫度傳送器

ATTX-200 防爆溫度傳送器

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

SLPTX系列 數位式HART智能型液位傳送器

SLPTX系列 HART智能型液位傳送器

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

DPS-2.5SPD3 多功能壓力開關

DPS-2.5SPD3 多功能壓力開關

可選三種雙組警報輸出(Relay、NPN、PNP),適合作為本地安全連鎖的直接觸發元件。

→ 查看完整 257 項產品型錄

需要為高風險或間歇連線場景設計架構?

不論是鍋爐系統的本地安全連鎖設計,或是航空地勤的離線資料完整性,告訴我們您的場域限制與安全要求,ATLANTIS 工程團隊協助您完成儀表選型與架構分工確認。

豐富產品現貨・TAF 認可校正・材質證明書完整提供・24 小時緊急備品支援

立即詢價 / 技術諮詢 →

業務一部 Ian:ian@atlantis.com.tw  業務二部 Nori:nori@atlantis.com.tw  電話:02-2820-3405