幫我查看今天 IoT 是否異常？AWS IoT Core × Lambda 壓力溫度智慧監控完整指南
幫我查看今天 IoT 是否異常？AWS IoT Core × Lambda 壓力溫度智慧監控完整指南
「幫我查看今天 IoT 是否有異常。」——這句話可能是老闆早會上的隨口一問，也可能是工程師每天最不想聽到、卻每天都要面對的任務。傳統做法要打開好幾套系統、翻 Excel、打電話問現場，等答案出來可能已經過了兩小時。當 Claude、AWS Lambda、IAM Role、AWS IoT Core、DynamoDB 與 CloudWatch 串成一條線之後，同一個問題可以在幾秒內被自動回答：「今天有 3 台壓力表超過 8 bar，建議立即派員巡檢。」這篇文章拆解這句話背後，從感測器到雲端、從 Lambda 判斷邏輯到自然語言摘要的完整技術與商業邏輯。
Part 1．給決策者看的：這套系統，值多少錢？
先回答最現實的問題：花錢導入 IoT 異常監控，公司得到什麼？答案不是「一個很酷的儀表板」，而是三件事——更早發現異常、更少非計畫性停機、以及更少因為選型或巡檢疏漏而付出的代價。以下用實際研究數據，而非空泛的行銷詞彙，說明差異。
反應式 vs 預防式 vs 預測式維護：一張表看懂差異
| 維護模式 | 運作邏輯 | 維護成本變化 | 非計畫性停機 | 資料來源 |
|---|---|---|---|---|
| 反應式（故障才修） | 設備壞了才處理 | 基準值（最高） | 基準值（最高） | 產業慣例 |
| 預防式（定期保養） | 依固定週期巡檢／更換 | 較反應式降低約 18–25% | 下降但仍有突發故障 | McKinsey 相關研究 |
| 預測式／預警式（IoT + AI 監控） | 即時感測 + 異常判斷 + 自動告警 | 最高可降低約 40% | 最高可降低約 50% | Deloitte 相關研究 |
上表數字為產業研究機構公開報告之區間，實際成效依設備型態、產業與導入完整度而異，詳見文末「資料來源與延伸閱讀」。
這套系統到底在做什麼？給非工程背景的三分鐘解釋
想像工廠裡多了一位 24 小時不打瞌睡、不會漏看、而且用中文直接跟你報告的巡檢員。他的工作流程是這樣的：
- 你問一句話：「幫我查看今天 IoT 是否有異常」——可能是文字訊息，也可能是排程自動觸發。
- Claude 判斷需要調閱資料，決定要查詢哪些系統、用什麼條件查詢。
- 呼叫後端 Lambda 函式，這是實際去「跑腿辦事」的程式，在雲端隨需執行、不需要自己養一台伺服器。
- Lambda 使用一組被授權的 IAM Role，這組角色被設計成「只能做被允許的事」——例如只能讀取特定資料表，不能刪除、不能亂改。
- 依序查詢三個資料來源：AWS IoT Core（感測器目前狀態與即時訊息）、DynamoDB（歷史數據資料庫）、CloudWatch（系統健康度與告警記錄）。
- 把三邊資料彙整回傳。
- Claude 用自然語言整理成一句人話：「今天有 3 台壓力表超過 8 bar，建議立即派員巡檢。」
這套流程的價值在於：管理層不需要懂技術細節，只需要問問題；工程師不需要每天手動巡邏，系統會主動說「有事」。兩邊各自省下的時間，就是這套系統的第一層 ROI。
示意圖：CloudWatch 告警邏輯監控 24 小時壓力趨勢，超過 8 bar 門檻立即標記為異常事件。
導入效益試算（情境範例，非特定客戶實績）
| 項目 | 導入前（人工巡檢為主） | 導入後（IoT + AI 監控） |
|---|---|---|
| 異常發現時間 | 依巡檢頻率，可能延遲數小時 | 秒級到分鐘級 |
| 巡檢人力投入 | 每日固定人工巡檢工時 | 轉為例外管理，僅異常時派工 |
| 歷史數據可查性 | 紙本或分散 Excel，難以追溯 | DynamoDB 完整時序記錄，可回溯查詢 |
| 管理層回報方式 | 需等現場回報彙整 | 自然語言自動摘要，隨問隨答 |
| 非計畫性停機（參考產業研究區間） | 基準值 | 最高可降低約 50%（見上方資料來源） |
本表為情境示意，用於說明導入前後的管理模式差異，非特定客戶之實際數據；實際效益需依現場設備數量、產業別與導入範疇評估。
你的工廠適合哪一種導入方式？
| 情境 | 建議規模 | 核心需求 | 建議切入點 |
|---|---|---|---|
| 單一產線／單廠試點 | 10–30 支感測點 | 快速驗證可行性、控制初期投入 | 先選 3–5 個關鍵壓力／溫度點試行 |
| 多廠區集中監控 | 50–300 支感測點 | 跨廠區統一儀表板、集中告警 | 依廠區分群建置 IoT Core Thing Group |
| 任務關鍵／24 小時不可中斷 | 依系統關鍵度而定 | 高可用性、雙訊號冗餘、快速備品 | 導入雙輸出型感測器 + 現地備援 |
| 預算有限之先導計畫 | 5–10 支感測點 | 低成本驗證 ROI，作為擴大依據 | 選用既有 4-20mA 訊號改接閘道器，先不換既有錶頭 |
三個情境，看懂效益怎麼發生（情境示意）
情境示意｜精密機械加工廠
情境挑戰：油壓系統壓力若在夜間無人巡檢時段緩慢下降，隔天早上才會被發現，導致當班加工件精度不穩定。
可能的做法：在油壓迴路加裝可輸出 4-20mA／RS-485 訊號的智慧型壓力傳送器，經閘道器上傳至 AWS IoT Core，由 Lambda 設定壓力下降速率門檻，一旦超出即經 CloudWatch 觸發告警並通知值班人員。
ATLANTIS SDPT-3100 智能型壓力傳送器（HART 通訊、微處理器溫度自動補償）
上述為說明導入邏輯之情境示意，非特定客戶之驗證數據。
情境示意｜食品飲料充填廠
情境挑戰：CIP 清洗系統壓力若超出安全上限，可能造成管路密封件提早老化，過去仰賴人工每小時抄表記錄。
可能的做法：換裝具雙組警報輸出的數位壓力開關，超過設定門檻時螢幕自動變色並輸出訊號，經 Modbus 閘道整合進 AWS IoT Core，異常事件寫入 DynamoDB 作為稽核紀錄（食品業常需保留製程紀錄以利追溯）。
ATLANTIS DPS-2.5SPD3 多功能壓力開關（雙組警報輸出、可選 RS-485 數位輸出）——正是「今天 3 台壓力表超過 8 bar」情境中最典型的監控前端。
上述為說明導入邏輯之情境示意，非特定客戶之驗證數據。
情境示意｜天然氣分銷站
情境挑戰：管線分佈範圍廣，人工巡檢頻率無法做到即時，異常洩壓或壓力異常波動需要遠距即時監控（延伸閱讀可參考 國防工業 × 能源安全高風險環境壓力監控完整選型指南）。
可能的做法：採用防爆等級對應之差壓傳送器，透過 RS-485 Modbus 長距離傳輸整合進雲端架構，多點集中於同一條匯流排，降低單點布線成本。
上述為說明導入邏輯之情境示意，非特定客戶之驗證數據，實際防爆等級與規格須依現場環境評估。
Part 2．給工程師看的：從感測器到雲端的完整技術架構
這一段是本篇的核心重點，目標讀者是負責串接 AWS IoT Core、設計 IAM Role、寫 Lambda 判斷邏輯的現場工程師。我們會把開頭提到的七個步驟，拆解成可以直接落地的技術決策。
整體架構總覽：七個步驟的技術對應
| 步驟 | 業務描述 | 技術對應 |
|---|---|---|
| 1 | 使用者輸入查詢 | Slack／Web／排程觸發 → Claude 對話介面 |
| 2 | Claude 判斷需要工具 | Tool use／Function calling 決策，判斷應查詢哪些資料源 |
| 3 | 呼叫 Lambda | API Gateway 或直接 Invoke 觸發 AWS Lambda 函式 |
| 4 | Lambda 使用 IAM Role | 執行角色綁定最小權限 Policy，僅可存取指定資源 |
| 5 | 查詢三個資料源 | AWS IoT Core（即時狀態）＋ DynamoDB（歷史時序）＋ CloudWatch（告警與指標） |
| 6 | 回傳結果 | Lambda 彙整 JSON 結果回傳給 Claude |
| 7 | 自然語言整理 | Claude 生成摘要，如「今天有 3 台壓力表超過 8 bar，建議立即派員巡檢」 |
感測器層：ATLANTIS 訊號輸出 × AWS 上雲方式對照表
要讓 Claude 能回答「今天 IoT 是否異常」，前提是感測器的類比或數位訊號要能穩定送上雲端。以下整理常見的 ATLANTIS 壓力／溫度感測器輸出類型，以及對應的上雲整合方式：
| 訊號／通訊類型 | 代表機型 | 建議上雲路徑 | 備註 |
|---|---|---|---|
| 4-20mA 類比輸出 | SDPT-3100、STT、多數壓力傳送器 | 類比訊號轉換模組 → 工業閘道器 → MQTT → AWS IoT Core | 最通用、既有系統改造成本最低 |
| RS-485 Modbus RTU | DPS-2.5SPD3（可選）、SLPTX 系列 | Modbus-to-MQTT 閘道（如樹莓派 + pymodbus）→ AWS IoT Core | 單一匯流排可掛載多點，降低布線成本 |
| HART 智能通訊 | SDPT-3100、STT、PTX-CC 系列 | HART Modem → OPC UA／MQTT 閘道 → AWS IoT Core | 支援遠端組態與診斷，適合關鍵設備 |
| 雙組開關量輸出 | DPS-2.5SPD3、DTS-STS | 數位 I/O 模組 → MQTT Publish → AWS IoT Core Rule | 適合門檻告警型應用，資料量小、即時性高 |
| 藍牙／Type-C 數位輸出 | DPG-X112 | 邊緣裝置（如工業平板）彙整後批次上傳 | 適合巡檢點檢、非連續上傳場景 |
ATLANTIS STT HART 智能型溫度傳送器：一體化設計，支援熱電阻／熱電偶輸入，可透過 HART 通訊裝置進行遠端組態，適合整合進工業閘道器。
AWS IoT Core 與 IAM Role 最小權限設計
原始情境提到「Lambda 使用 IAM Role」，這是整個架構中最容易被忽略、卻是資安關鍵的一環。依 AWS 官方文件建議，IAM 與 IoT Core Policy 都應遵循最小權限原則：限制萬用字元、明確列出允許的 Action 與 Resource、依 Client ID 或裝置憑證分別授權。
| 角色／Policy | 允許動作 | 資源範圍 | 設計目的 |
|---|---|---|---|
| 感測器裝置憑證 | iot:Connect、iot:Publish（限定 Topic） | 僅限該裝置對應之 Topic 前綴 | 避免單一裝置被冒用後存取其他裝置資料 |
| 查詢用 Lambda 執行角色 | dynamodb:Query、iot:GetThingShadow、cloudwatch:GetMetricData | 限定特定 Table／Thing／Namespace | 只讀取，不具刪除或修改權限 |
| 告警處理 Lambda 執行角色 | cloudwatch:PutMetricAlarm、sns:Publish | 限定特定告警主題 | 僅能發送通知，不可異動其他資源 |
| 資料寫入 IoT Rule 角色 | dynamodb:PutItem | 限定單一資料表 | 符合單一職責，降低誤寫風險 |
參考來源：AWS IoT Core 安全最佳實務文件（見文末資料來源）。
資料查詢層：IoT Core、DynamoDB、CloudWatch 的分工
很多工程師第一次設計時會疑惑：「這三個服務資料是不是重複了？」答案是分工不同：IoT Core（Device Shadow）負責「現在的狀態」，DynamoDB負責「歷史時序資料的完整記錄」，CloudWatch負責「系統健康度與告警事件」。三者合併查詢，才能完整回答「今天是否異常」這種橫跨即時與歷史的問題。
DynamoDB Table Schema 設計範例
| 欄位名稱 | 型別 | 範例值 | 說明 |
|---|---|---|---|
| device_id（partition key） | String | PG-LINE3-08 | 感測器唯一識別碼 |
| timestamp（sort key） | Number（epoch） | 1784812800 | 資料寫入時間，支援時間範圍查詢 |
| pressure_bar | Number | 8.6 | 壓力讀值 |
| temperature_c | Number | 62.3 | 溫度讀值（如為複合式感測器） |
| status | String | ANOMALY | NORMAL／WARNING／ANOMALY |
| threshold_bar | Number | 8.0 | 當下設定之告警門檻，供事後稽核 |
CloudWatch Alarm 設定範例
| 指標名稱 | 門檻條件 | 評估週期 | 觸發動作 |
|---|---|---|---|
| PressureReading | > 8 bar，連續 1 次資料點 | 1 分鐘 | SNS 通知值班群組 |
| PressureDropRate | 5 分鐘內下降 > 1.5 bar | 5 分鐘 | 標記為 WARNING，寫入 DynamoDB |
| DeviceOffline | 超過 10 分鐘無回報 | 10 分鐘 | 觸發裝置離線告警，區分於量測異常 |
| TemperatureReading | 超出設定溫度區間 | 1 分鐘 | SNS 通知 + 記錄事件 |
Lambda 異常判斷邏輯：門檻式 vs 機器學習式
最簡單也最容易落地的做法是門檻式判斷（固定閾值或變化率），優點是邏輯透明、容易除錯，缺點是對於「正常波動較大」的製程可能誤報。進階做法可導入 Amazon Lookout for Equipment 等異常偵測服務，讓模型從歷史資料學習正常運作模式，偵測非線性的異常樣態（例如溫度與壓力同時緩慢飄移，但都尚未超過個別門檻）。AWS 官方部落格「Using AWS IoT Services for Asset Condition Monitoring」即說明了以 IoT 事件即時計算異常分數、並持久化至 DynamoDB 的參考架構，與本篇的設計邏輯一致。
if pressure_reading > threshold_bar:
status = "ANOMALY"
write_to_dynamodb(device_id, timestamp, pressure_reading, status)
publish_cloudwatch_metric("PressureReading", pressure_reading)
elif rate_of_change(pressure_reading, window="5min") > drop_rate_limit:
status = "WARNING"
三款智慧感測器 × AWS 整合實戰
① SDPT-3100 智能型壓力傳送器
已導入情境（示意）：油壓／液壓系統需要遠端標定與故障診斷，避免每次校正都要拆卸儀錶。
為什麼選這款：內建微處理器，具備環境溫度自動補償與 HART 協議通訊，可在不斷電、不拆機的狀況下進行遠端診斷，非常適合需要 24 小時連續運作、且不希望頻繁中斷產線校正的場域。
與 ATLANTIS 一般型壓力傳送器的差異：一般類比型僅輸出 4-20mA，須現場以三用電表或壓力校正器人工標定；SDPT-3100 可透過 HART 通訊直接於控制室完成組態變更與診斷，減少現場停機時間。
② DPS-2.5SPD3 多功能壓力開關
已導入情境（示意）：需要「超過門檻就要有人知道」的簡單告警情境，例如原始情境中「3 台壓力表超過 8 bar」。
為什麼選這款：雙組警報輸出、警報時螢幕自動變色，且可選配 RS-485 數位輸出直接對接閘道器，不需額外加裝訊號轉換模組，是最貼近本文情境的前端裝置。
與陶瓷壓阻感測基本款的差異：基本款僅提供單一開關輸出；DPS-2.5SPD3 支援雙組獨立設定（例如上限＋下限）與多種壓力單位切換，可因應同一產線不同製程階段的門檻需求。
③ LTPT-410RS 系列 溫度液位傳送器
ATLANTIS LTPT-410RS 系列：溫度與壓力（液位）同時測量的整合型傳送器，適合需要同時監控兩項參數、卻想節省安裝點位的場域。
已導入情境（示意）：儲槽類應用需同時掌握液位變化與溫度趨勢，若分開裝設兩支儀錶，除了成本增加，資料時間戳記也可能無法對齊，影響後續 Lambda 判斷邏輯的準確性。
為什麼選這款：單一裝置同時輸出溫度與壓力（液位）資料，上傳到 AWS IoT Core 時天然具備同一時間戳記，簡化 DynamoDB 資料模型設計，也降低閘道器點位數量。
與分離式雙儀錶方案的差異：分離式方案需要兩套獨立訊號與兩個裝置 ID，資料比對需額外程式邏輯處理時間差；整合型傳送器則原生對齊，適合作為 Lambda 判斷邏輯的簡化起點。
雲端成本概算：導入 100 支感測點的參考量級
| AWS 服務 | 使用假設 | 成本量級（僅供概算方向） |
|---|---|---|
| AWS IoT Core | 100 台裝置，每台每分鐘上傳 1 則訊息 | 依訊息數與規則引擎觸發次數計費，屬於較低量級 |
| Lambda | 每則異常事件觸發 1 次判斷函式 | 依實際觸發次數與執行時間計費，閒置不計費 |
| DynamoDB | 時序資料，依需求設定 TTL 自動清理舊資料 | 依讀寫容量單位與儲存量計費 |
| CloudWatch | 核心指標監控 + 告警規則 | 依自訂指標數與告警規則數量計費 |
實際費用會因區域、資料量、保留策略與服務等級而異，正式評估請以 AWS 官方定價 及 AWS Pricing Calculator 試算為準，本表僅提供架構規劃時的量級參考方向。
自建 vs ATLANTIS 整合方案：怎麼選？
| 比較項目 | 純自建（工程團隊從零串接） | ATLANTIS 感測器 + 既有 AWS 帳號整合 |
|---|---|---|
| 感測器選型與規格確認 | 需自行研究材質、量程、精度等級 | 可直接依應用場景取得選型建議與規格書 |
| 現場安裝相容性 | 需自行確認螺紋、材質相容性 | 可提供樣品試裝與材質證明書 |
| 備品與應急 | 需自建庫存或等待原廠出貨 | 可洽詢現貨與緊急備品支援 |
| 雲端架構（IoT Core／Lambda／IAM） | 需自行設計與維運 | 與感測器選型無關，仍需工程團隊自行負責雲端架構 |
說明：ATLANTIS 專精於感測器本體選型與現場整合支援，AWS 雲端架構的設計與維運仍建議由具備 AWS 專業能力之團隊負責，兩者互為搭配而非取代關係。
資安與可靠性：容錯設計重點
- 裝置憑證分離：每支感測器使用獨立憑證，避免單一裝置外洩牽連整個機隊。
- 離線容錯：閘道器應具備本地暫存能力，網路中斷時先存於邊緣，恢復連線後補傳，避免資料缺口。
- 雙訊號冗餘：任務關鍵系統建議選用同時支援類比與數位輸出的機型（如 SDPT-3100），任一路徑異常時仍有備援。
- 資料保留策略：DynamoDB 適合存放近期高頻查詢資料，長期歷史資料可設定生命週期規則轉存至 S3，兼顧查詢效能與儲存成本。
20 題高頻問答 FAQ
以下 20 題涵蓋管理層決策疑慮與工程師實作細節，點擊展開即可閱讀完整解答。
1. 為什麼需要即時異常監控，而不是等壓力錶壞了再處理？
2. 導入這套系統要花多少錢？多久可以回本？
3. 我們公司 IT／OT 資源有限，會不會很難導入？
4. 資料存在 AWS 安全嗎？會不會被駭客攻擊？
5. Claude 在這個架構中到底扮演什麼角色？會不會誤判？
6. 這跟傳統 SCADA／DCS 系統有什麼不同？
7. 導入後，現場人員的工作會被取代嗎？
8. 只有壓力、溫度嗎？還能監測其他參數嗎？
9. AWS IoT Core 跟傳統 PLC／SCADA 的資料串接方式有什麼不同？
10. RS-485 Modbus RTU 的感測器要怎麼接到 AWS IoT Core？需要哪些閘道設備？
11. IAM Role 要怎麼設計才符合最小權限原則？
12. Lambda 的異常判斷邏輯該怎麼寫？門檻式還是機器學習式？
13. DynamoDB 的 Table Schema 要怎麼設計才能兼顧查詢效能與成本？
14. CloudWatch Alarm 的閾值要怎麼設定才不會誤報或漏報？
15. HART 通訊協定的感測器（如 SDPT-3100）要怎麼整合進這個架構？
16. 資料傳輸延遲大概多久？即時性夠不夠做製程控制？
17. 如果要監測 200 支壓力錶，AWS 的成本大概怎麼估算？
18. 感測器數據要保留多久？冷儲存（S3）跟熱儲存（DynamoDB）怎麼分工？
19. Device Shadow 是什麼？在這個架構中有沒有用處？
20. 這套架構可以跟現有的 Modbus TCP／OPC UA 系統並存嗎？
反思三問
問題一：當老闆問「今天設備正常嗎」，你的團隊現在需要多久才能回答？如果答案是「幾小時」，這篇文章描述的架構所省下的，就是那幾小時裡可能被忽略的異常訊號。
問題二：你的監控系統，是「記錄了數據」還是「真的會在對的時間叫醒對的人」？資料庫裡躺著再多歷史數據，如果沒有門檻與告警邏輯，都只是事後才看得懂的紀錄。
問題三：你現在的架構，是工程團隊「還在手動兜」，還是已經有一套可重複部署到下一個廠區的標準模式？如果答案是前者，或許值得先從一個小規模試點開始驗證。
資料來源與延伸閱讀
- AWS 官方部落格：Using AWS IoT Services for Asset Condition Monitoring
- AWS 官方文件：How AWS IoT Works
- AWS 官方文件：AWS IoT Core FAQs
- AWS 官方文件：AWS IoT Core 安全最佳實務
- ASME 標準：ASME B40.100 — Pressure Gauges and Gauge Attachments
- ANSI Blog：ASME B40.100-2022 解析
- 產業研究彙整：Predictive Maintenance ROI Benchmarks: What the Studies Show（引用 Deloitte／McKinsey 相關數據）
- 產業研究彙整：Predictive Maintenance Cost Savings: ROI Guide for Industrial Plants
- 延伸閱讀（站內）：工業4.0 壓力感測器整合指南｜智慧製造・IoT 遠端監控應用
- 延伸閱讀（站內）：國防工業 × 能源安全 高風險環境壓力監控完整選型指南
- 延伸閱讀（站內）：壓力錶量程為什麼要選 1.5～2 倍？31 年儀錶工程師的選型黃金法則
- 延伸閱讀（站內）：壓力開關完整選型指南
下一步：從一個試點開始
不論你是想先看懂效益的管理者，或是要動手串接架構的工程師，ATLANTIS 累積 31 年壓力／溫度儀錶現場經驗，可協助評估感測器選型與現場整合細節。
台北市北投區致遠一路二段109號｜電話：02-2820-3405