全串接架構：感測器→IoT Core→Lambda→DynamoDB→儀表板的完整案例研究

ian

工廠IT技術人員專用全系列總結完整案例研究ATLANTIS 自有品牌

全串接架構：感測器→IoT Core→Lambda→DynamoDB→儀表板的完整案例研究

台灣31年工業儀錶製造商 ATLANTIS 昶特有限公司系列教學文章第十篇（完結篇）：這是我們「工業壓力溫度計上雲」系列的最後一篇。前九篇分別拆解了每一個技術環節——RS-485接線、MQTT訂閱、Lambda觸發、封包解析、SNS告警、DynamoDB歷史記錄、規則引擎多動作路由、CloudWatch管線監控、API Gateway儀表板串接。本篇要做一件事：把這九塊拼圖組回一張完整的地圖，用一個完整案例，帶你從頭到尾走過一次全串接架構。

「Re-Atlantis」的品牌使命，是重現古代理想文明對精密秩序的追求。走完這十篇文章，你會發現雲端監控系統的秩序，其實與精密儀錶的設計哲學完全相通：每一層都各司其職，彼此獨立卻又緊密協作，最終匯聚成一套值得信賴的完整系統。詳見 ATLANTIS 品牌故事。

一、完整架構總覽：九篇文章、五層架構

層① 現場感測層 ATLANTIS RS-485變送器 第一篇 層② 訊息傳輸層 MQTT / AWS IoT Core 第一、二篇 層③ 事件運算層 規則引擎 + Lambda解析 第三、四、七篇 層④ 儲存與告警層 DynamoDB / S3 / SNS 第五、六篇 層⑤ 應用與監控層 API Gateway儀表板（第九篇）＋ CloudWatch管線健康監控（第八篇） 工廠管理者 / 值班工程師 / 稽核人員

這張圖把系列文章重新分成五層。層①②是「資料如何產生並抵達雲端」，層③是「資料如何被理解」，層④是「資料如何被保存與觸發反應」，層⑤是「資料如何被人使用」。任何一層缺席，整個系統的價值都會打折扣——這也是我們建議工廠IT技術人員按部就班、從第一篇開始逐步建置的原因。

二、完整案例：某中部電子代工廠的12週上雲之旅

以下案例經匿名化處理，綜合呈現我們在協助多家中部電子代工廠導入雲端監控過程中的典型時程與決策脈絡，客戶原本的痛點是：SMT產線的迴焊爐溫度僅依賴機台本身面板顯示，異常時完全依賴作業員目視巡檢，曾因溫度曲線偏移未及時發現，導致整批產品焊接不良，損失超過200萬元。

週次對應文章完成項目關鍵決策
第1～2週第一篇更換為支援RS-485輸出的ATLANTIS溫度傳送器，完成MQTT發布測試選擇RS-485而非4-20mA，為未來多點擴充預留彈性
第3週第二篇用主控台MQTT測試客戶端驗證資料流暢通，確立主題命名規範及早發現IoT Policy授權範圍設定錯誤
第4週第三篇建立最小Lambda函式，確認事件驅動架構打通先驗證架構通不通，再逐步疊加功能
第5週第四篇解決部分舊型號設備的位元組順序解析問題建立裝置設定檔架構因應多品牌混用現況
第6～7週第五篇建立SNS告警並加入抑制邏輯避免簡訊轟炸異常告警門檻先保守設定，逐步收斂
第8週第六篇建立DynamoDB歷史記錄與告警狀態追蹤表採用隨選容量模式降低初期規劃負擔
第9週第七篇加入S3原始資料歸檔，符合客戶端品質稽核要求採用Hive風格分區降低未來查詢成本
第10週第八篇建立心跳監控，偵測感測器沉默故障設定告警門檻為正常回報間隔的3倍
第11～12週第九篇建立REST API並串接產線儀表板，開放產線主管自助查詢選用HTTP API並發放部門專屬API金鑰

從第1週動工到第12週正式上線，這家工廠沒有增加任何一名專職資料工程師，全程由原本的2名電控工程師依照本系列文章的架構逐步建置完成。這也印證了本系列文章的初衷：雲端監控系統的建置，並不需要工廠重新招募一整個IT團隊。

三、導入前後成效對照

1.5小時
導入前平均
異常發現時間
3分鐘
導入後平均
異常發現時間
0人
新增專職
資料工程師人力
12週
從動工到
正式上線總時程
指標導入前導入後
異常發現方式作業員定時巡檢（每2小時一次）Lambda自動判斷 + SNS即時通知（數秒內）
歷史數據查詢需人工調閱機台面板記錄或紙本表單API Gateway自助查詢，任意時間範圍
資料保存完整度機台本地儲存空間有限，僅保留約1週DynamoDB保留90天+S3永久歸檔
系統故障發現方式依賴人員察覺數據異常CloudWatch自訂心跳監控自動告警
跨部門資料存取僅IT人員能撈取資料各產線工程師依權限自助查詢

四、常見的三個實作陷阱，回顧整個系列

陷阱對應文章正確作法
只做「發布」沒做「驗證」，資料到底有沒有送達完全靠猜第二篇養成用MQTT測試客戶端驗證的習慣，再往下建置後續架構
位元組順序判斷錯誤，導致數值錯亂卻長期沒被發現第四篇上線前準備已知答案的測試數據，逐一驗證解析邏輯
告警門檻設太敏感，工程師收到告警疲勞後直接關閉通知第五篇門檻先保守設定，並加入狀態變化觸發與冷卻時間抑制邏輯
只監控「資料異常」，沒監控「資料完全沒來」的沉默故障第八篇建立自訂心跳指標，定期檢查每個裝置最後回報時間
前端儀表板直接嵌入AWS憑證查詢資料庫，形成資安漏洞第九篇一律透過API Gateway + Lambda做代理查詢，憑證留在後端

這五個陷阱，涵蓋了我們在協助多家工廠導入雲端監控過程中最常見的踩雷模式。如果你正在規劃自己的專案，建議把這張表當作上線前的最終檢查清單。

五、費用總覽：完整架構每月大約要花多少錢？

服務本文案例規模估算（約20支感測器，每30秒回報）對應文章
AWS IoT Core訊息傳遞費用，落在入門等級第一篇
AWS Lambda（解析+告警+API查詢）多數落在每月100萬次免費請求額度內第三、四、五、九篇
Amazon SNS異常通知數量遠低於原始數據量，費用有限第五篇
Amazon DynamoDB（隨選容量）依讀寫請求與儲存量計費，20支感測器規模通常費用可控第六篇
Amazon S3儲存單價低，主要成本來自長期累積的資料量第七篇
CloudWatch（含自訂指標）自訂指標依數量計費，一定額度內免費第八篇
API Gateway（HTTP API）依請求次數計費，內部儀表板查詢量通常費用不高第九篇

對於中小型工廠的典型規模（數支到數十支感測器），整體雲端服務費用通常遠低於一次因異常未及時發現造成的停機或報廢損失。實際費率會隨用量與AWS官方定價調整而變動，建議導入前用AWS官方定價計算器依實際規模試算，並持續關注AWS官網最新公告。

六、ATLANTIS 貫穿全系列的核心自有品牌產品

SDPT-3100 智能型壓力傳送器

SDPT-3100 智能型壓力傳送器 —— 基於微處理器的HART通訊傳送器，貫穿本系列多篇文章，是高精度雲端監控應用的核心選型

DPS-2.5SPD3 多功能壓力開關

DPS-2.5SPD3 多功能壓力開關 —— 支援RS-485數位輸出與雙組警報，是本系列文章中RS-485與本地告警雙重防護的代表產品

STT HART智能型溫度傳送器

STT HART智能型溫度傳送器 —— 通用型一體化溫度傳送器，支援熱電阻/熱電偶輸入，是本系列溫度監控範例的主要參照型號

THT-S81 室內溫濕度傳送器

THT-S81 室內溫濕度傳送器 —— 支援RS485 Modbus RTU通訊，是本系列文章示範多欄位解析與主題命名規則的代表產品

完整規格請參考 ATLANTIS 產品型錄與工業4.0壓力感測器整合指南，我們的應用工程團隊可協助比對您現場既有設備的暫存器規格與通訊協定。

七、給準備開始這趟旅程的工廠IT技術人員：三個建議

建議一：不要試圖一次到位

本系列文章刻意拆成九個技術主題循序漸進，正是因為一次性建置完整架構容易在除錯時迷失方向。建議依照第一篇到第九篇的順序，每完成一層就充分驗證，再往下一層邁進。

建議二：資安與權限規劃要從第一天就納入考量

從第一篇的IoT Policy、第七篇的規則角色，到第九篇的API金鑰管理，最小權限原則應該貫穿整個系列，而不是等到系統上線後才回頭補強，這也是我們在每一篇文章中反覆強調的重點。

建議三：監控你的監控系統

第八篇的核心精神值得再次強調：再完美的告警邏輯，都救不回一個已經停止回報數據的沉默故障。任何雲端監控專案上線後，都應該持續投入資源維護監控系統本身的健康度，而不是建置完成後就當作永久解決方案束之高閣。

資料來源與延伸閱讀

本文彙整參考自本系列前九篇文章所引用之 AWS IoT Core、Lambda、DynamoDB、SNS、S3、CloudWatch與API Gateway官方文件（docs.aws.amazon.com）。費用與服務規格請以AWS官網最新公告為準。ATLANTIS產品技術規格引用自內部產品規格書與出廠檢驗報告。

八、完整系列文章索引

九、20 大常見問題 FAQ（全串接架構總結）

1. 我一定要照這九篇文章的順序建置嗎？
建議照順序建置，因為每一篇都建立在前一篇的基礎上（例如第五篇的告警抑制邏輯需要第六篇的DynamoDB才能完整實作），跳著做容易在某個環節卡關卻找不到根本原因。
2. 中小型工廠真的需要這麼完整的架構嗎？會不會太複雜？
可以依實際需求裁減，例如只需要即時告警而不需要長期歸檔的工廠，可以省略第七篇的S3動作；核心建議是至少完成第一到第六篇（發布到告警與歷史記錄），第七篇之後屬於進階優化。
3. 這套架構需要多少人力維護？
案例中的工廠僅由2名電控工程師建置與維護，未額外招募專職資料工程師，但需要工程師具備基礎Python與AWS服務概念，這也是本系列文章設計的入門難度。
4. 如果中途想換掉某一層的AWS服務，架構會受影響嗎？
因為各層之間是透過標準介面（MQTT訊息、DynamoDB查詢、HTTP API）串接，理論上可以個別替換某一層的實作方式而不影響其他層，這也是模組化架構設計的優勢。
5. 這套架構可以套用在壓力監控，還是只適合溫度？
完全適用，本系列的架構設計與壓力、溫度、濕度、液位等各類感測器數據無關，只要感測器能輸出數位訊號（如RS-485）並轉換為MQTT訊息，都能套用同一套架構。
6. 為什麼要花12週才能上線，可以更快嗎？
案例中的12週包含每個階段的充分測試與驗證，若團隊AWS經驗豐富且感測器規格單純，時程可以壓縮；但我們不建議為了求快而跳過每個階段的驗證步驟，這會增加後續除錯的隱性成本。
7. 導入這套架構後，原本的PLC本地監控系統還需要保留嗎？
建議保留，如第五篇所述，本地告警（如警報燈、蜂鳴器）是不依賴網路的最後一道防線，雲端監控應該視為「加強」而非「取代」現有的本地安全機制。
8. 這套架構符合哪些產業法規要求？
如第六篇案例所述，具備完整歷史記錄與稽核追溯能力的架構，有助於符合食品業HACCP、製藥業GMP等要求資料完整保存的法規，但實際合規性仍需依個別法規要求與稽核單位確認。
9. 我可以只做告警（第五篇）而跳過歷史記錄（第六篇）嗎？
技術上可行，但會失去第五篇提到的狀態變化觸發與冷卻時間抑制能力（因為這需要外部狀態儲存），也無法回溯異常發生前的趨勢變化，建議至少建立簡化版的狀態記錄機制。
10. 這套架構的資安風險主要在哪裡？
主要風險點包括：IoT裝置憑證管理（第一篇）、IAM角色權限範圍（第三、六、七篇）、以及API存取控制（第九篇），建議全程遵循最小權限原則並定期檢視權限設定。
11. 我們工廠沒有IT部門，一般電控工程師能自己做嗎？
案例中的工廠即是由電控工程師（而非專職IT人員）主導建置，只要具備基礎Python程式能力並願意投入時間學習AWS服務概念，是可行的，本系列文章的設計初衷正是為了這樣的讀者群。
12. 這套架構未來還能擴充什麼功能？
可以進一步擴充機器學習異常偵測（如Amazon SageMaker）、更豐富的資料視覺化（如Amazon QuickSight）、或多廠區彙總分析等進階應用，本系列文章建立的是紮實的基礎架構，後續擴充空間很大。
13. 如果同時有多個品牌的感測器，架構需要改動很多嗎？
如第四篇所述，只需要依裝置設定檔（Device Profile）架構增加不同品牌型號的解析規則，核心的MQTT、Lambda、DynamoDB與API架構不需要改動，這也是模組化設計的價值所在。
14. 這套架構的單點故障風險高嗎？
整體架構的各層服務本身都是AWS代管的高可用性服務，單點故障風險主要來自現場端（如單一Modbus閘道器故障導致多支感測器同時斷線），這也是第八篇心跳監控要偵測的重點情境。
15. 學完這十篇文章，我還需要學什麼才能算「精通」？
建議接續深入學習IAM權限精細設計、AWS Well-Architected Framework的最佳實務、以及特定產業法規（如GMP、HACCP）對資料保存的具體要求，這些都是實務上會持續遇到的進階課題。
16. 這套架構可以用在既有的老舊機台上嗎？
可以，只要老舊機台或其配套的壓力溫度儀錶能輸出RS-485或4-20mA訊號（多數工業設備皆具備），就能透過Modbus閘道器接入本系列架構，不需要更換整台機台。
17. ATLANTIS可以協助我們從頭到尾建置這整套架構嗎？
ATLANTIS的核心專業在於變送器選型、暫存器規格對照與現場接線建議（架構中的層①與層②基礎），雲端服務架構的細部程式開發建議由工廠IT團隊或合作的雲端服務商執行，我們可提供產品端的技術諮詢與現場支援。
18. 這套架構的投資報酬率大概多久能回收？
依本文案例，一次異常未及時發現造成的損失（約200萬元）已遠超過整套雲端架構的建置與年度維運成本，多數工廠案例顯示，只要避免一到兩次重大異常事件，即可回收整體投資成本。
19. 未來AWS服務更新，這套架構需要跟著大改嗎？
AWS服務更新通常是新增功能而非破壞既有相容性，本系列文章介紹的核心概念（MQTT、事件驅動、鍵值資料庫查詢、REST API）是雲端架構的基礎模式，即使底層服務細節更新，整體架構邏輯仍將長期適用。
20. 如果我看完這十篇文章後還有疑問，該怎麼辦？
歡迎直接聯繫ATLANTIS應用工程團隊，我們可以協助確認您現場感測器的通訊規格、暫存器對照表，並根據您的實際產線環境提供選型與接線建議，加速您的雲端監控專案落地。

十、系列完結：讓 ATLANTIS 陪你走完從感測器到儀表板的最後一哩路

31年工業儀錶製造經驗 × 完整雲端監控架構實戰知識

感謝您讀完這整個系列。從變送器選型、RS-485接線，到雲端架構的每一個環節，我們都樂意提供產品端的專業諮詢，協助您的工廠IT團隊少走一些我們曾經走過的彎路。

📞 02-2820-3405 免費選型諮詢 📧 線上快速詢價

業務一部 Ian：ian@atlantis.com.tw ｜ 業務二部 Nori：nori@atlantis.com.tw

文章更新時間：2026年7月｜作者：ATLANTIS 應用工程團隊｜本文為「工業壓力溫度計上雲」系列教學文章第十篇（完結篇），感謝您陪我們走完整個系列。