壓力溫度監控上雲手機化：AWS 串接 Android / iOS 推播概念完整解析

工廠壓力異常時，第一時間知道的人是誰？如果答案是「巡檢人員下次經過的時候」，代表你的監控系統還停留在上一個時代。本文拆解壓力、溫度感測數據如何經過 AWS 雲端架構，最終以推播通知的形式送達 Android / iOS 手機——包含真正可行的技術路徑、常見誤解，以及 ATLANTIS 感測器在這條鏈路中扮演的角色。

先講清楚：這篇文章談的是「概念與架構」，不是某個現成產品

在動手規劃之前，有一件事必須先說清楚，否則後面的技術內容容易被誤讀：「壓力溫度監控 AWS 接 Android/iOS」描述的是一種系統架構模式，而不是單一廠商就能整套賣給你的現成產品。這條鏈路橫跨了感測器製造商、雲端服務商（AWS）、以及行動應用開發，三者分屬不同專業領域，沒有一家公司會同時是這三者。

ATLANTIS 昶特在這條鏈路中扮演的角色，是感測層（Sensing Layer）的供應商——生產能輸出 HART、4-20mA 或藍芽等數位化訊號的壓力、溫度儀表。AWS 那一層（IoT Core、SNS 推播服務等）與最終的 Android/iOS App，需要客戶自行建置或委託系統整合商 / App 開發商完成。本文會誠實拆解整條路徑，讓你在規劃專案時清楚知道每一段該找誰。

整體架構：從一顆壓力錶到你手機的震動提醒

ATLANTIS 感測器（壓力 / 溫度）
                                │  HART / 4-20mA / 藍芽 BLE
                                ▼
                          現場閘道器（訊號轉換 + 上傳）
                                │  MQTT / TLS
                                ▼
                           AWS IoT Core（裝置驗證、訊息路由）
                                │  IoT Rules Engine（條件判斷）
                                ▼
                           AWS Lambda（觸發告警邏輯）
                                │
                                ▼
                           Amazon SNS（推播服務）
                                │
                           ┌────┴────┐
                           ▼         ▼
                        Android    iOS
                        (FCM)     (APNs)

這條鏈路可以拆成四個階段來理解，每個階段用到的技術與需要的專業完全不同：

第一階段：感測器要具備什麼條件，才有資格「上雲」

並非所有壓力錶、溫度計都能接進這條鏈路。純機械式指針錶完全沒有電訊號輸出，物理上無法連網。要能被閘道器讀取，感測器必須具備數位化或標準化的訊號輸出。以下是 ATLANTIS 產品線中，實際具備此條件的類型。

1. HART 智能傳送器：走 AWS IoT Core 的主要路徑

HART 協議能在既有 4-20mA 訊號線上疊加數位通訊，同時傳送即時數值與診斷資訊，是這條「感測器 → 閘道器 → AWS」鏈路中最常見的訊號來源。

SDPT-3100 智能型壓力傳送器：支援 HART 協議通訊，具環境溫度自動補償

SDPT-3100 是基於微處理器的高性能傳送器，具有靈活的壓力校準和輸出、HART 協議通訊、環境溫度自動補償等功能，適用於需要高精度壓力測量與遠端通訊的工業應用。溫度端則有 STT HART 智能型溫度傳送器，通用型一體化設計，支援熱電阻、熱電偶、電阻、電壓多種訊號輸入，透過 HART 通訊裝置進行遠端組態與診斷。

STT HART智能型溫度傳送器：通用型一體化設計，支援遠端組態與診斷

2. 藍芽數位錶：另一種「行動化」路徑，但要弄清楚它做到哪裡

ATLANTIS 部分數位壓力錶支援藍芽連接與 App 配置參數，這是一個經常被誤解的地方，值得特別說明。

DPG-X112 高精度藍芽數位壓力錶：可旋轉 330°，支援 Type-C 或藍芽匯出記錄數據

DPG-X112 為可旋轉 330° 的高精度數位壓力錶，主屏顯示壓力，副屏同時顯示環境溫度、壓力最大／最小值及量程範圍等數據，支援 Type-C 或藍芽功能匯出記錄數據，並可設置多種參數。同系列的 DPG-X182R 藍芽旋轉式數位壓力錶內置高精度壓力傳感器，錶盤同樣可 330° 旋轉，支援藍芽連接和 App 配置參數，適用於便攜式壓力測量、設備配套、校驗設備等領域。

DPG-X182R 藍芽旋轉式數位壓力錶：支援藍芽連接與 App 參數配置

第二、三階段：AWS 雲端如何判斷「該不該通知你」

感測器把數據送上雲端之後，不是每一筆數據都需要推播——如果每秒上傳的讀數都跳出通知，手機會被轟炸到失去意義。這是 AWS IoT Rules Engine 與 Lambda 存在的原因。

IoT Rules Engine：用 SQL 語法篩選數據

AWS IoT Core 收到裝置上傳的訊息後，Rules Engine 可以用類似 SQL 的語法對訊息內容做篩選與轉換，只有符合條件的訊息才會觸發下一步動作。

-- IoT Rule 範例：篩選壓力超過設定值的訊息
                        SELECT device_id, pressure_bar, timestamp
                        FROM 'sensors/pressure/+'
                        WHERE pressure_bar > 8.5

Lambda：告警邏輯的核心

符合條件的訊息會觸發 Lambda 函式，由 Lambda 決定接下來要做什麼——單純記錄、還是要發送告警。比起單次超標就推播，較成熟的做法通常會加入「持續超標達一定時間」的邏輯，避免單一瞬間的訊號雜訊造成誤報。

import json
                        import boto3
                        def lambda_handler(event, context):
                            """
                            判斷壓力數據是否需要觸發推播告警
                            重點：避免單次瞬間超標就推播，改為持續超標才觸發
                            """
                            pressure = event['pressure_bar']
                            device_id = event['device_id']
                            threshold = 8.5
                            if pressure > threshold:
                                # 實務上這裡通常會查詢近期歷史數據，
                                # 確認是否「持續」超標而非單次雜訊，
                                # 再決定是否真正觸發 SNS 推播
                                sns = boto3.client('sns')
                                sns.publish(
                                    TopicArn='arn:aws:sns:REGION:ACCOUNT:PressureAlerts',
                                    Message=json.dumps({
                                        'device_id': device_id,
                                        'pressure_bar': pressure,
                                        'alert_type': 'PRESSURE_HIGH'
                                    })
                                )
                                return {'statusCode': 200, 'alert_sent': True}
                            return {'statusCode': 200, 'alert_sent': False}

第四階段：Amazon SNS 如何同時觸及 Android 與 iOS

這是整條鏈路裡最多人誤解的一段。Amazon SNS（Simple Notification Service）本身不會直接把通知送進 Android 或 iOS 手機——它是透過對接各平台原生的推播閘道來完成的。

換句話說，SNS 是一個「中繼站」的角色：Lambda 把告警訊息送進 SNS，SNS 再依照手機裝置註冊時取得的 Token，分別透過 FCM（給 Android）或 APNs（給 iOS）把通知真正送達裝置。這代表你的 App 開發團隊需要完成裝置註冊、Token 管理、以及與 Firebase / Apple 開發者帳號的對接——這部分工作量不小，且與感測器、AWS IoT Core 完全是不同的技術領域。

Android 與 iOS 的推播差異，會影響你的專案時程

App 端要做什麼：從收到 Token 到畫面跳轉的完整實作

前面談的是雲端如何「送出」推播，但完整的鏈路還有另一半——App 本身要怎麼「接住」這個推播、並且正確顯示給使用者。這部分工作量常被低估，尤其在工業監控類 App（相對於一般消費性 App）還有幾個特別需要注意的細節。以下拆解 App 端開發真正需要處理的幾個環節。

第一步：選擇開發框架——原生 vs. 跨平台

App 開發第一個要決定的技術選型，是要分別用原生語言開發兩個 App（Android 用 Kotlin，iOS 用 Swift），還是用跨平台框架（如 React Native、Flutter）一套程式碼同時產出兩個平台的 App。這個選擇會影響後續所有開發工作的效率與維護成本。

第二步：裝置註冊——App 啟動時要做的第一件事

App 要能收到推播，第一步是向 FCM（Android）或 APNs（iOS）註冊，取得屬於這個裝置的專屬 Token，並把這個 Token 回傳給後端儲存起來。這裡分別示範 Flutter 跨平台寫法，以及 Android／iOS 原生寫法，讓採用不同技術路線的團隊都能對照。

// Flutter 概念範例：App 啟動時註冊並取得推播 Token
                        import 'package:firebase_messaging/firebase_messaging.dart';
                        Future<void> registerForPushNotifications() async {
                          FirebaseMessaging messaging = FirebaseMessaging.instance;
                          // 向使用者請求推播權限（iOS 必須明確請求，Android 較寬鬆）
                          NotificationSettings settings = await messaging.requestPermission(
                            alert: true,
                            badge: true,
                            sound: true,
                          );
                          if (settings.authorizationStatus == AuthorizationStatus.authorized) {
                            // 取得這支裝置的專屬 Token
                            String? token = await messaging.getToken();
                            // 將 Token 連同使用者身分（如員工編號）回傳後端，
                            // 由後端呼叫 AWS SNS 建立對應的端點（Endpoint）訂閱
                            await sendTokenToBackend(token, currentUserId);
                          }
                        }

原生 Android（Kotlin）等效寫法

如果團隊選擇原生開發而非 Flutter，Android 端的對應邏輯如下：

// Kotlin 概念範例：使用 Firebase Messaging SDK
                        class MonitorApp : Application() {
                            override fun onCreate() {
                                super.onCreate()
                                FirebaseMessaging.getInstance().token
                                    .addOnCompleteListener { task ->
                                        if (!task.isSuccessful) {
                                            Log.w("FCM", "取得 Token 失敗", task.exception)
                                            return@addOnCompleteListener
                                        }
                                        val token = task.result
                                        // 回傳後端，觸發 SNS Endpoint 建立
                                        ApiClient.sendTokenToBackend(token, currentUserId)
                                    }
                            }
                        }
                        // 監聽 Token 更新（換手機、重灌後會觸發）
                        class MyFirebaseService : FirebaseMessagingService() {
                            override fun onNewToken(token: String) {
                                super.onNewToken(token)
                                ApiClient.sendTokenToBackend(token, currentUserId)
                            }
                        }

原生 iOS（Swift）等效寫法

iOS 端需要同時處理 APNs 系統層級的裝置 Token，以及 Firebase（若使用）的 FCM Token 兩層：

// Swift 概念範例：AppDelegate 中註冊推播
                        func application(_ application: UIApplication,
                            didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool {
                            UNUserNotificationCenter.current().requestAuthorization(
                                options: [.alert, .badge, .sound]) { granted, error in
                                guard granted else { return }
                                DispatchQueue.main.async {
                                    application.registerForRemoteNotifications()
                                }
                            }
                            return true
                        }
                        // 取得系統層級的 APNs Token
                        func application(_ application: UIApplication,
                            didRegisterForRemoteNotificationsWithDeviceToken deviceToken: Data) {
                            let tokenString = deviceToken.map { String(format: "%02.2hhx", $0) }.joined()
                            ApiClient.sendTokenToBackend(tokenString, currentUserId)
                        }

後端這一側：如何把 Token 變成「可以送達的地址」

App 把 Token 回傳後端只是第一半，另一半經常被文章跳過、卻是真正讓推播「打得中」的關鍵：後端要用這個 Token 向 SNS 註冊一個「平台端點」（Platform Endpoint），才能取得一個可以拿來精準發送訊息的端點 ARN。以下是這一段 Lambda 邏輯的示意寫法：

import boto3
                        sns = boto3.client('sns')
                        dynamodb = boto3.resource('dynamodb')
                        device_table = dynamodb.Table('DeviceRegistry')
                        # FCM 與 APNs 各自對應的 SNS 平台應用程式 ARN
                        PLATFORM_ARNS = {
                            'android': 'arn:aws:sns:REGION:ACCOUNT:app/GCM/YourApp',
                            'ios': 'arn:aws:sns:REGION:ACCOUNT:app/APNS/YourApp'
                        }
                        def register_device(event, context):
                            """
                            App 呼叫此 API 時觸發：
                            把裝置 Token 註冊為 SNS 平台端點，並記錄使用者對應關係
                            """
                            body = json.loads(event['body'])
                            user_id = body['user_id']
                            device_token = body['device_token']
                            platform = body['platform']  # 'android' 或 'ios'
                            # 向 SNS 註冊，取得這支裝置專屬的端點 ARN
                            response = sns.create_platform_endpoint(
                                PlatformApplicationArn=PLATFORM_ARNS[platform],
                                Token=device_token
                            )
                            endpoint_arn = response['EndpointArn']
                            # 存進 DynamoDB，之後才知道「這個人的手機」對應哪個 SNS 端點
                            device_table.put_item(Item={
                                'user_id': user_id,
                                'endpoint_arn': endpoint_arn,
                                'platform': platform,
                                'updated_at': datetime.utcnow().isoformat()
                            })
                            return {'statusCode': 200, 'body': json.dumps({'status': 'registered'})}
                        def publish_alert_to_user(user_id, alert_message):
                            """
                            告警觸發時呼叫：查出這個人的端點 ARN，精準發送（而非廣播給所有人）
                            """
                            record = device_table.get_item(Key={'user_id': user_id}).get('Item')
                            if not record:
                                return  # 這個人尚未註冊裝置，無法推播
                            sns.publish(
                                TargetArn=record['endpoint_arn'],
                                Message=json.dumps({
                                    'default': alert_message,
                                    'GCM': json.dumps({'notification': {'title': '壓力異常警報', 'body': alert_message}}),
                                    'APNS': json.dumps({'aps': {'alert': alert_message, 'sound': 'default'}})
                                }),
                                MessageStructure='json'
                            )

第三步：處理「前景」與「背景」推播的不同行為

這是開發團隊最常低估複雜度的一塊。App 在「前景」（使用者正在使用）、「背景」（App 開著但沒在看）、「完全關閉」三種狀態下，收到推播的處理方式在 Android 與 iOS 上都不完全相同，需要分別測試驗證。

對工業告警場景而言，這件事特別重要：值班人員的手機很可能大部分時間是螢幕鎖定、App 在背景或完全關閉的狀態，因此告警訊息必須確保在這三種狀態下都能可靠送達與顯示，開發階段建議針對這三種狀態分別實測，而不是只在「App 開著測試」的情境下驗收。

第四步：點擊通知後，跳轉到正確的畫面

收到「設備A壓力異常」的通知後，使用者點擊它，理想的體驗是直接跳轉到設備A的即時數據頁面，而不是打開 App 首頁讓使用者自己找。這需要在推播訊息中夾帶「深層連結」（Deep Link）資訊，App 收到點擊事件後依此導向正確畫面。

// SNS 發送的推播訊息可以夾帶自訂資料（data payload）
                        {
                          "notification": {
                            "title": "壓力異常警報",
                            "body": "設備A：壓力 9.2 bar，超過設定值 8.5 bar"
                          },
                          "data": {
                            "device_id": "device-a-001",
                            "screen": "device_detail",
                            "alert_type": "PRESSURE_HIGH"
                          }
                        }
                        // App 端：解析 data payload，導向對應畫面
                        void handleNotificationTap(Map<String, dynamic> data) {
                          if (data['screen'] == 'device_detail') {
                            navigateTo(DeviceDetailScreen(deviceId: data['device_id']));
                          }
                        }

第五步：離線與弱網環境下的資料同步

工廠環境的手機收訊不一定穩定（特別是地下室機房、金屬結構密集區域），App 除了接收推播，通常還需要能在網路恢復後，主動向後端查詢是否有錯過的告警記錄，避免因為當下收訊不良而完全漏掉異常通知。這通常透過 App 啟動或恢復前景時，額外呼叫一次 API 查詢「未讀告警列表」來補強，而不能完全依賴推播本身的即時送達。

現場閘道器：這條鏈路裡最容易被忽略的一環

前面提到「感測器數據需要透過閘道器上傳雲端」，但閘道器本身該怎麼選，是規劃專案時最容易被輕描淡寫帶過、卻往往決定專案成敗的環節。閘道器的工作是把 HART 或 4-20mA 訊號轉換成 MQTT 訊息，這個轉換過程有幾種常見做法，各有不同的維護成本與技術門檻。

選項一：商用工業 IoT 閘道器

市面上有專門設計用於工業訊號轉雲端的商用閘道器產品，通常具備 Modbus/HART 讀取功能與 MQTT 輸出，並附帶圖形化設定介面，不需要撰寫程式碼即可完成基本設定。這類產品的優勢是穩定性經過驗證、有原廠技術支援，適合不想自行維護底層程式碼的團隊，但相對地採購成本較高，且客製化彈性受限於原廠功能。

選項二：工業電腦 + 自行開發程式

另一種做法是用工業電腦或樹莓派等單板電腦，搭配 Python（如 pymodbus 函式庫讀取 Modbus 訊號、paho-mqtt 函式庫發布 MQTT 訊息）自行開發閘道邏輯。這種做法的優勢是客製化彈性最高，可以依照專案需求加入任何額外的邊緣運算邏輯（例如在送上雲端前先做初步的異常過濾），但需要團隊具備基本的程式開發與長期維運能力，前期建置時間通常也比商用閘道器長。

選項三：PLC 廠牌原生雲端模組

部分主流 PLC 廠牌（如西門子、三菱等）近年推出可直接對接雲端服務的通訊模組，如果現場已有這些廠牌的 PLC 在運作，透過原生模組上雲有時比另外加裝獨立閘道器更省事，但需要確認該模組是否原生支援 AWS IoT Core，或是否需要額外的協議轉換層。

自建 vs. 委外：這條鏈路該找幾家廠商合作

理解了完整架構之後，接下來最實際的問題是：這整套系統該由一家廠商統包，還是分別找不同專業的合作夥伴？以下拆解幾種常見的專案組成方式，供評估參考。

模式一：感測器廠商 + 系統整合商（最常見）

感測器廠商（如 ATLANTIS）負責確認訊號規格與提供對應儀表，系統整合商負責閘道器建置、AWS 架構設計、以及 App 開發（或委託第三方 App 開發商）。這是目前業界最常見的分工方式，因為每個環節都由該領域的專業者負責，責任界線清楚。

模式二：企業內部團隊自建

如果企業本身已有 IT/MIS 團隊、且具備 AWS 與行動開發經驗，可以只向感測器廠商採購儀表，其餘架構全部由內部團隊建置。這種模式的優勢是長期維護成本較低（不需持續支付整合商服務費），但前期需要投入內部人力學習曲線，且如果團隊對工業通訊協議不熟悉，前期溝通成本可能不低。

模式三：尋找同時具備工控與雲端背景的整合商統包

市場上也有部分系統整合商同時具備自動化工程與雲端開發雙重背景，可以提供從閘道器到 App 的一站式服務。這種模式對缺乏內部技術團隊的企業較友善，但選擇廠商時建議實際確認對方是否真的同時熟悉兩個領域，而不只是其中一項外包給下游廠商轉手處理——可以透過詢問對方過去是否有類似的工業感測器上雲案例來初步判斷。

可靠性與資安：工業現場不能忽略的兩件事

把工業現場的壓力溫度數據送上公有雲、再推播到員工個人手機，這件事本身就牽涉到幾個工業自動化領域特別在意、但一般 App 開發流程未必會主動提醒的考量點。

網路中斷時，資料會遺失嗎？

工廠現場的網路穩定性不一定和辦公室環境相同，若閘道器與雲端之間的連線短暫中斷，這段時間的感測數據該怎麼辦？較穩健的做法是讓閘道器具備本地緩衝機制——網路正常時即時上傳，一旦偵測到連線中斷，先將數據暫存在閘道器本機，待網路恢復後補送，避免這段空窗期的數據完全遺失。這個細節在初期規劃時容易被忽略，但對於需要完整歷史記錄做稽核或故障回溯的場域（如食品製藥業），是必須事先確認的規格。

誰能存取雲端上的工廠數據？

壓力、溫度數據雖然聽起來不像客戶個資那樣敏感，但對競爭對手而言，產能利用率、製程參數等衍生資訊仍有商業價值。AWS IoT Core 的裝置驗證機制（X.509 憑證）確保只有授權裝置能夠上傳數據，但雲端服務本身的存取權限管理（誰能登入 AWS 主控台看到原始數據、誰能修改告警規則）同樣需要謹慎規劃，建議依照最小權限原則設定不同角色的存取範圍，而非讓所有相關人員共用同一組管理員帳號。

推播通知的內容要包含多少細節？

手機鎖定畫面上顯示的推播通知內容，預設情況下可能會被螢幕旁人看到。如果告警內容包含較敏感的製程參數細節，需要考慮通知內容的呈現方式（例如只顯示「設備A異常，請開啟App查看」而非直接顯示具體數值），這是 App 設計階段就該納入考量的細節，而非上線後才發現的問題。

各產業怎麼用這套架構：從半導體到冷鏈

以下是幾種代表性場景的監測邏輯示範，說明架構如何對應不同產業的實際需求特性（案例已匿名化處理，並非承諾特定效益數字）。

半導體與潔淨室：分鐘級異常必須被看見

半導體製程對腔體壓力與潔淨室正負壓差的穩定性要求極高，任何壓力偏移都可能直接影響良率。這類場域多半是 24 小時運作、且大部分時段無人巡檢，因此異常必須能在分鐘級被相關工程師掌握，而不能等到下一輪巡檢才發現。這種場景通常會搭配高精度數位微差壓錶或 HART 智能壓力傳送器，走完整的 HART → 閘道器 → AWS → 推播鏈路。

冷凍空調與食品冷鏈：對抗「緩慢惡化」而非「瞬間故障」

冷凍倉儲類場域的異常往往不是瞬間發生，而是壓縮機老化或冷媒緩慢洩漏導致的漸進式溫度飄移。這種漸進式異常最難被傳統的每日人工巡檢及時抓到，因為單次抄錶看到的數字可能還在「看起來正常」的範圍內。透過分鐘級的持續監測與趨勢判斷（而非單一時間點的數值），能在溫度真正超出安全範圍之前就發現異常訊號。

化工與能源：夜間無人值守時段的風險視窗

化工廠反應釜、天然氣管線的壓力異常往往關係到工安，而風險最高的時段通常是夜間無人值守。如果值班主管能在異常初期就透過手機收到通知，即使人不在廠區，也能立即遠端聯繫現場應變人員或啟動緊急處理流程，而不是等到隔天早班人員到場才發現前一晚已經發生的異常。

食品製藥：異常記錄需要完整可追溯

食品製藥業的殺菌釜溫度、無菌製程壓力等數據，除了即時異常通報的需求外，通常還牽涉法規對記錄可追溯性的要求。雲端記錄相較於人工抄錶，能提供更頻繁、更難被事後竄改的數據軌跡，但是否符合特定稽核標準（如電子簽章、資料完整性認證），需要與品保部門及稽核顧問確認，本文僅說明技術架構本身的可行性。

規劃這類專案前，先回答三個問題

問題一：你真正需要的是「推播告警」還是「查看即時數據」？

這兩者需要完全不同的技術投入。如果只是想「隨時打開手機看目前壓力多少」，其實不一定需要走完整的推播鏈路，一個能顯示即時數據的雲端儀表板網頁（在手機瀏覽器打開）就能滿足；只有在「異常發生時要主動被通知、不用自己去查」的情境下，才真正需要走 SNS + FCM/APNs 這條完整路徑。

問題二：告警的誤報成本有多高？

推播告警最大的風險不是「做不到」，而是「做得太敏感」。如果告警邏輯只看單次讀數超標就推播，現場任何訊號雜訊都可能觸發誤報，久而久之現場人員會養成「看到推播先不理」的習慣，讓整套系統形同虛設。告警邏輯的設計（例如需要持續超標多久才推播）往往比推播技術本身更關鍵。

問題三：Android 和 iOS 都需要支援嗎？

如果使用者僅限公司內部特定人員（例如僅發給幾位主管或值班工程師），先確認這些人實際使用的手機系統，可能只需要開發單一平台的推播對接，能省下另一個平台的開發與維護成本。

常見問題 FAQ

延伸閱讀

本文技術架構說明參考 AWS 官方文件公開資訊（IoT Core、Lambda、SNS）及 Google Firebase、Apple 官方推播服務公開文件所述之通用工作原理；Lambda 程式碼為說明架構邏輯的示意範例，非可直接部署之完整解決方案。產業應用情境已匿名化處理，具體效益因個案而異，僅供規劃參考。ATLANTIS 昶特有限公司為壓力、溫度感測器製造商，不提供 AWS 官方認證服務、App 開發服務或代管雲端平台，文中 AWS／Android／iOS 相關服務商標權利均屬各自所有者。