Lambda入門：當溫度數據抵達時自動觸發運算的最小範例

ian

工廠IT技術人員專用AWS LambdaIoT Core規則引擎ATLANTIS 自有品牌

Lambda入門：當溫度數據抵達時自動觸發運算的最小範例

台灣31年工業儀錶製造商 ATLANTIS 昶特有限公司系列教學文章第三篇：接續第一篇 RS-485接AWS IoT Core與第二篇 MQTT訂閱驗證，本篇教你如何設定 AWS IoT Core 規則引擎，讓溫度數據一抵達雲端就自動觸發 Lambda 函式運算，不需要任何常駐程式或伺服器，寫給工廠IT技術人員的最小可行範例。

ATLANTIS的品牌使命「Re-Atlantis」，源自對古代理想文明精密秩序的追求。在雲端架構的世界裡，「事件驅動」正是這種秩序的展現——不需要工程師隨時盯著螢幕，系統會在對的時間點自動反應。這也是本篇要帶你認識的核心概念：Lambda無伺服器運算。詳見 ATLANTIS 品牌故事。

一、為什麼是Lambda？無伺服器運算對工廠監控系統的意義

在前兩篇文章中，我們示範了「感測器 → RS-485 → MQTT發布 → AWS IoT Core」的資料流，以及如何用主控台或Python程式「訂閱」驗證資料是否送達。但光是把資料送上雲端還不夠——資料本身不會自動判斷異常、不會自動發送告警。這正是Lambda要解決的問題。

0台
需要自行管理的
伺服器數量
100萬次
Lambda每月
免費請求額度
毫秒級
從訊息抵達到
Lambda開始執行的延遲
1條規則
即可連接IoT Core
與Lambda函式

Lambda是什麼？用工廠比喻理解「無伺服器」

如果把傳統伺服器比喻成「一台24小時待命的機台」，那Lambda就像是「感應式自動化設備」——只有當特定事件發生（例如溫度數據抵達），系統才會啟動運算，執行完畢後立即釋放資源。你不需要租一台伺服器24小時開機等待溫度數據，也不需要煩惱伺服器當機或維護，AWS會自動處理底層運算資源的配置與回收。

本篇的最小目標

建立一條最簡單的資料路徑：溫度數據透過MQTT發布到AWS IoT Core → 規則引擎偵測到符合條件的訊息 → 自動觸發Lambda函式 → Lambda印出並判斷是否超過警戒值。全程不需要撰寫任何常駐訂閱程式，這也是與第二篇「Python程式訂閱」架構最大的差異：Lambda是「事件觸發」，而非「持續監聽」。

二、架構總覽：從IoT Core規則引擎到Lambda

① 溫度變送器發布 MQTT Topic： factory/line1/temperature ② AWS IoT Core MQTT Broker 接收訊息 ③ 規則引擎 Rules Engine SQL篩選條件 符合則觸發動作 ④ Lambda函式 自動執行運算 判斷/記錄/告警 ⑤ CloudWatch 執行日誌 監控紀錄

整條路徑的核心在於③：規則引擎（Rules Engine）。它用類似SQL的語法，從MQTT主題中篩選出符合條件的訊息，並將訊息內容傳遞給Lambda函式作為輸入事件（event）。這一步不需要寫任何程式碼，完全在AWS主控台上用設定完成。

三、建立第一條IoT Core規則：從主題到Lambda

步驟一：撰寫規則的SQL篩選語句

在AWS IoT Core主控台的「規則（Rules）」頁面新增規則時，需要填入一段SQL-like查詢語句，決定要篩選哪些訊息、擷取哪些欄位。以下是本篇範例使用的查詢語句：

規則SQL語句範例

SELECT *, topic() as source_topic
FROM 'factory/+/+/temperature/#'

這段語句代表：「選取所有欄位，並額外附加訊息來源的主題路徑，資料來源為符合factory/+/+/temperature/#樣式的所有主題」。你也可以加上WHERE條件，例如只篩選溫度超過某個數值的訊息，減少不必要的Lambda觸發次數。

進階範例：只篩選溫度超過80度的訊息

SELECT *, topic() as source_topic
FROM 'factory/+/+/temperature/#'
WHERE temperature > 80

把篩選邏輯放在規則引擎這一層，而不是全部交給Lambda判斷，有一個實務上的好處：可以降低Lambda的觸發次數與費用，因為只有真正符合條件的異常訊息才會啟動運算。

步驟二：新增「動作（Action）」，指定觸發的Lambda函式

在規則設定頁面的「動作」區塊，選擇「傳送訊息至Lambda函式（Send a message to a Lambda function）」，並選擇你已建立好的Lambda函式名稱。儲存後，這條規則就會開始運作：只要有符合SQL條件的MQTT訊息進來，就會自動呼叫指定的Lambda函式。

四、撰寫最小可行的Lambda函式

以下是本篇的核心範例：一個不到20行的Lambda函式，接收IoT Core規則引擎傳來的事件，判斷溫度是否異常，並將結果印出到CloudWatch日誌。

範例一：最小溫度異常判斷 Lambda函式

import json

def lambda_handler(event, context):
    # event即為規則引擎依SQL語句篩選後傳入的訊息內容
    print("收到事件：", json.dumps(event))

    device_id = event.get("device_id", "unknown")
    temperature = event.get("temperature")
    source_topic = event.get("source_topic", "")

    if temperature is None:
        print("警告：事件中未包含temperature欄位")
        return {"statusCode": 400, "body": "缺少temperature欄位"}

    if temperature > 80:
        print(f"[異常告警] 主題：{source_topic}"
            f" 裝置：{device_id} 溫度：{temperature}°C 超過警戒值")
    else:
        print(f"裝置 {device_id} 溫度正常：{temperature}°C")

    return {"statusCode": 200, "body": json.dumps("處理完成")}

這段程式碼刻意保持最小：沒有連接資料庫、沒有發送通知，目的是先確認「規則引擎 → Lambda」這條路徑本身是通的。等你在CloudWatch日誌中看到自己印出的訊息，就代表整個事件驅動架構已經成功打通，接下來才是加上SNS告警、DynamoDB寫入等進階功能（這些會在系列文章後續篇章展開）。

Lambda函式的執行角色（Execution Role）設定

建立Lambda函式時，AWS會要求指定一個「執行角色（Execution Role）」，這個IAM角色決定了Lambda函式可以存取哪些AWS資源。對於本篇的最小範例，只需要最基本的AWSLambdaBasicExecutionRole（允許寫入CloudWatch日誌）即可；後續若要加上SNS告警或DynamoDB寫入，需要額外授權對應的權限。

五、如何測試：不用真的等感測器資料，也能驗證Lambda是否正常運作

Lambda主控台提供「測試事件（Test Event）」功能，可以直接在網頁上模擬一筆規則引擎會傳入的事件內容，不需要真的觸發現場感測器發布數據。

測試事件範例JSON

{
    "device_id": "ATL-STT-001",
    "temperature": 92.5,
    "unit": "C",
    "timestamp": 1784812345,
    "source_topic": "factory/taipei-plant1/line1/temperature/ATL-STT-001"
}

在Lambda主控台建立這個測試事件後，點擊「測試（Test）」按鈕執行，即可在畫面下方看到執行結果與print()輸出的日誌內容，快速確認函式邏輯是否正確，而不需要等待真實感測器數據抵達。

三種驗證層次，建議依序完成

驗證層次驗證方式目的
第一層：函式邏輯驗證Lambda主控台「測試事件」確認程式碼本身邏輯正確，不涉及IoT Core
第二層：規則引擎串接驗證用第一篇的Python發布程式手動發送一筆訊息確認規則引擎能正確篩選並觸發Lambda
第三層：端到端現場驗證從實體ATLANTIS溫度變送器讀取真實數據並發布確認完整資料管線在現場環境穩定運作

依序完成這三層驗證，可以大幅降低除錯難度——當某一層出問題時，你能明確知道是「程式邏輯」、「雲端串接」還是「現場環境」的問題，而不是面對整條管線一起除錯。

六、Lambda觸發方式比較：IoT Core規則 vs 其他常見架構

觸發方式適用情境延遲特性工廠監控建議
IoT Core規則引擎直接呼叫即時事件驅動運算（如本文範例）毫秒級，最低延遲異常告警、即時判斷首選
Amazon SQS佇列需要緩衝、批次處理大量訊息視佇列處理速度而定高流量、可容忍些微延遲的場景
Amazon Kinesis串流大規模即時串流分析秒級，依串流分片設定多產線、大量感測點的進階分析
排程觸發（EventBridge）定期批次運算，非事件驅動依排程間隔（如每5分鐘）定期彙總報表、非即時性統計

對於本系列文章設定的「工廠IT技術人員入門」情境，IoT Core規則引擎直接觸發Lambda是最單純、最容易理解的架構，也是後續要加上SNS告警、DynamoDB儲存的基礎骨架。待系統規模擴大、感測點數量大幅增加後，再評估是否需要導入SQS或Kinesis做流量緩衝。

Lambda費用試算：小規模工廠監控通常落在免費額度內

情境每月觸發次數估算是否落在免費額度
10支感測器，每30秒觸發一次約86.4萬次/月落在每月100萬次免費請求額度內
30支感測器，每30秒觸發一次約259萬次/月超出免費額度，需依實際請求數計費
10支感測器，僅異常時觸發（規則篩選）依實際異常事件數量，通常遠低於上述估算幾乎必定落在免費額度內

這也是為什麼我們在第三節建議把篩選條件寫在規則引擎的SQL語句中，而不是讓每一筆訊息都觸發Lambda再由函式內部判斷——這樣不僅降低費用，也讓CloudWatch日誌更乾淨，只記錄真正需要關注的事件。實際費率請以AWS官網最新公告為準。

七、ATLANTIS 適合搭配Lambda異常判斷架構的量測產品

ATT-P4/D4系列 管路型溫度傳送器

ATT-P4/D4系列 管路型溫度傳送器 —— 不鏽鋼外殼搭配德國進口感測元件，可輸出4-20mA或數位訊號，適合搭配規則引擎設定溫度異常門檻

RTD-907A 白金電阻溫度計

RTD-907A 白金電阻溫度計 —— 4線Pt100歐姆感溫棒設計，消除引線電阻影響，適合需要高精度異常判斷的雲端監控應用

DTS-4ED(0.5) 數位溫度開關

DTS-4ED(0.5) 數位溫度開關 —— 雙組開關輸出搭配LED顯示，本地告警與雲端Lambda判斷可雙重並行，提高異常反應可靠度

DPTX 防爆差壓傳送器

DPTX 防爆差壓傳送器 —— 半導體矽材料壓阻效應設計，適用於需要同時監控壓力與觸發雲端異常告警的防爆環境

完整規格請參考 ATLANTIS 產品型錄與精密溫度感測器完整決策指南。

八、案例分享：某南部電子廠的Lambda異常判斷導入過程

以下案例經匿名化處理，客戶為台灣南部一家電子製造廠，主要監控製程冷卻水溫度，原先僅依賴PLC本地告警，導入AWS IoT Core與Lambda後的過程如下。

階段作法耗時成效
第一週建立IoT Core規則，SQL篩選溫度超過設定門檻的訊息1天確認規則引擎正確路由訊息
第二週撰寫最小Lambda函式，先僅印出日誌驗證半天確認事件驅動架構打通
第三週Lambda函式加上SNS通知邏輯（下一篇主題）1天異常時值班人員手機立即收到簡訊
第四週正式上線並觀察一週穩定性持續監控異常反應時間從原本PLC本地告警燈的「巡檢才發現」，縮短為「即時簡訊通知」

資深工程師分享：「很多工廠IT一開始會想把Lambda函式寫得很複雜，一次把告警、資料庫、報表全部塞進去。但我們建議的做法剛好相反——先寫一個只會print的最小函式，確認整條路徑真的通了，再一層一層往上加功能。這跟儀錶校正的邏輯完全一樣：先確認基準點是對的，才有資格談後面的精密調校。」

資料來源與延伸閱讀

本文技術架構參考 AWS Lambda 官方文件與 AWS IoT Core 規則引擎官方文件（docs.aws.amazon.com）。費用與免費額度數字請以AWS官網最新公告為準。ATLANTIS產品技術規格引用自內部產品規格書與出廠檢驗報告。

九、內連延伸閱讀

十、20 大常見問題 FAQ（Lambda入門與IoT Core規則引擎）

1. Lambda函式的event參數裡面到底是什麼？
當Lambda由IoT Core規則引擎觸發時，event參數就是規則SQL語句SELECT子句所選取出來的欄位內容，格式為JSON物件，可直接用event.get("欄位名稱")取值。
2. 規則引擎的SQL語句和一般資料庫SQL一樣嗎？
語法相似但並非完全相同，AWS IoT Core的規則SQL是專為MQTT訊息篩選設計的簡化版本，支援SELECT、FROM、WHERE等基本子句，以及topic()等內建函式，但不支援複雜的JOIN等操作。
3. 一個Lambda函式可以被多條IoT Core規則觸發嗎？
可以。同一個Lambda函式可以被多條不同的規則設定為觸發動作，適合用於「多種感測器類型但共用同一套異常判斷邏輯」的情境，只需在函式內依事件內容做不同分支處理。
4. Lambda函式執行失敗，規則引擎會重試嗎？
IoT Core規則引擎呼叫Lambda屬於非同步呼叫模式，若Lambda執行失敗，AWS Lambda本身有內建的非同步呼叫重試機制（依預設設定重試特定次數），詳細行為建議查閱AWS官方文件確認最新機制與可設定選項。
5. AWSLambdaBasicExecutionRole具體允許做什麼？
這是AWS提供的受管理政策，允許Lambda函式將執行日誌寫入CloudWatch Logs，是最基本、幾乎所有Lambda函式都需要的權限，本篇最小範例僅需此權限即可運作。
6. 為什麼建議在規則SQL加WHERE條件，而不是全部交給Lambda判斷？
在規則引擎層先篩選可以減少不必要的Lambda觸發次數，降低執行費用，同時讓CloudWatch日誌更聚焦於真正需要關注的異常事件，避免大量正常數值的日誌淹沒真正重要的告警記錄。
7. Lambda函式的逾時設定要設多少？
本篇最小範例邏輯簡單，執行時間通常在毫秒等級，預設逾時（如3秒）已相當充裕。若後續加上資料庫寫入或外部API呼叫，建議依實際測試結果適度調高逾時設定，避免因網路延遲導致函式意外中斷。
8. 測試事件（Test Event）和真實IoT Core觸發的event格式會不同嗎？
若測試事件的JSON結構與規則引擎實際傳入的欄位一致，兩者行為應相同。建議測試事件的內容直接參考規則SQL語句的SELECT欄位設計，確保測試情境與正式環境一致。
9. Lambda可以同時處理溫度和壓力兩種數據嗎？
可以，在規則SQL的FROM子句涵蓋溫度與壓力兩種主題路徑，並在Lambda函式內依事件中是否包含temperature或pressure欄位分流處理邏輯，或分別建立兩條規則對應兩個不同的Lambda函式，依團隊偏好選擇架構。
10. CloudWatch日誌要保留多久？會不會產生額外費用？
CloudWatch Logs預設會無限期保留日誌，可能產生儲存費用，建議在日誌群組設定「保留期限（Retention）」，例如保留30或90天，超過期限自動刪除，避免長期累積產生不必要的儲存成本。
11. Lambda函式可以直接發簡訊或Email告警嗎？
Lambda本身不直接發送簡訊或Email，但可以在函式內呼叫Amazon SNS（簡易通知服務）的API觸發簡訊或Email發送，這是本系列下一篇文章會展開的主題，需額外授權Lambda執行角色呼叫SNS的權限。
12. 如果我不熟悉Python，可以用其他語言寫Lambda嗎？
可以，AWS Lambda支援多種執行環境，包括Node.js、Java、Go、.NET等，本文選用Python是因為語法簡潔、適合工廠IT快速上手，實際專案可依團隊熟悉的程式語言選擇。
13. 規則引擎的WHERE條件可以用複合條件嗎（例如溫度和壓力同時超標）？
可以，規則SQL支援基本的邏輯運算子（如AND、OR），可以組合多個欄位條件，但若邏輯過於複雜，建議改為在Lambda函式內部處理，保持規則SQL語句的可讀性與維護性。
14. Lambda函式版本更新後，正在執行中的舊版本會受影響嗎？
Lambda支援版本控制與別名（Alias）機制，更新函式程式碼不會影響當下正在執行的呼叫，但後續新的觸發會使用最新版本（若規則指向$LATEST或特定別名），建議正式環境使用別名機制做版本管理，降低更新風險。
15. 一條IoT Core規則可以同時觸發Lambda和寫入DynamoDB嗎？
可以，一條規則可以設定多個「動作（Actions）」，例如同時觸發Lambda函式進行即時判斷，並將原始訊息寫入DynamoDB做歷史記錄保存，兩個動作會平行執行，互不影響。
16. Lambda函式的記憶體設定要怎麼選？
Lambda的運算能力與記憶體設定成正比，本篇最小範例邏輯簡單，128MB（AWS預設最低值附近）通常已足夠。若後續加入較複雜的運算或函式庫載入，建議依實際測試結果與CloudWatch指標調整記憶體配置。
17. 規則引擎觸發Lambda失敗時，我怎麼知道發生了什麼事？
可以在IoT Core規則設定中額外加上「錯誤動作（Error Action）」，將觸發失敗的訊息路由到另一個主題或CloudWatch Logs，方便後續追蹤規則本身或Lambda執行是否發生問題。
18. 我可以用同一個Lambda函式服務多個工廠據點嗎？
可以，只要規則SQL的FROM子句涵蓋所有據點的主題路徑（例如使用萬用字元factory/+/+/temperature/#），並在Lambda函式內依事件中的廠區代號欄位分流處理告警邏輯或儲存位置。
19. Lambda函式的程式碼要放在哪裡管理？
小規模專案可直接在Lambda主控台的內建編輯器撰寫與部署；隨著程式碼複雜度提高，建議改用版本控制工具（如Git）搭配AWS SAM或CloudFormation等基礎架構即程式碼（IaC）工具管理，並建立正式的部署流程。
20. 學會這篇的Lambda入門後，下一步該學什麼？
建議接續學習Amazon SNS告警通知整合、DynamoDB資料寫入與歷史記錄查詢，這些正是本系列文章後續篇章「溫度異常自動告警」與「把壓力溫度數據寫入DynamoDB」要展開的主題。

十一、下一步：讓 ATLANTIS 協助你完成感測器選型與雲端事件驅動架構規劃

31年工業儀錶製造經驗 × 完整數位輸出產品線

從變送器選型、規則引擎門檻設定，到Lambda異常判斷邏輯規劃，我們可以陪工廠IT團隊完成從硬體到雲端事件驅動的完整驗證流程。

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

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

文章更新時間：2026年7月｜作者：ATLANTIS 應用工程團隊｜本文為系列教學文章第三篇，下一篇將深入「用AWS Lambda解析Modbus/RS-485感測器封包資料」。