不是取代，而是把老師傅的經驗規則化、24小時不打烊。老師傅的判斷依據通常是「吸氣壓力偏低＋排氣壓力偏高＋過熱度異常」這組經驗法則，AWS Lambda 做的事情，就是把這組法則寫成程式碼，並且用感測器取代人眼巡檢，讓判斷可以在凌晨3點沒有人巡廠時依然運作。老師傅的深度診斷經驗（例如判斷是接頭洩漏還是壓縮機閥片磨損）仍需要現場複判，但「該不該立即派工」這個第一層判斷，可以交給系統。

因為冷媒不足與感測器本身故障、環境溫度變化都可能造成單一壓力值偏移。但冷媒不足有一個特殊的「雙向背離」特徵：低壓側因蒸發器缺乏冷媒而壓力下降，高壓側則因壓縮比被迫升高而壓力上升。如果只有一邊變化、另一邊正常，反而更可能是感測器漂移或環境溫度影響，而非真正的冷媒不足。這也是為什麼 ASHRAE 診斷準則強調要交叉比對過熱度與過冷度，而非單看壓力值。

關鍵在吸氣壓力與過冷度的方向。冷媒不足時，吸氣壓力通常偏低、過冷度偏低甚至無法量測；冷媒過充時，吸氣壓力通常偏高、過冷度異常偏高。判斷邏輯必須同時納入這兩個維度的方向性，而不只是「排氣壓力超過門檻」這種單一條件，否則會把兩種成因完全相反的故障混為一談，導致錯誤的派工建議。

這正是本文第五章案例C要說明的重點。建議在雲端 AWS Lambda 判斷之外，於現場加裝具備本地端安全連鎖能力的產品，例如 ATLANTIS DPS-2.5SPD3 多功能壓力開關。即使雲端通訊中斷，開關本身仍可在壓力超出安全極限時直接觸發跳機或警報，等網路恢復後，雲端系統會補發歷史告警紀錄，確保「安全機制」與「即時通知」是兩套互為備援的獨立防線。

技術上可以只選一個，但實務上不建議。原因是四個通道服務的受眾與用途不同：LINE／Slack 負責「秒級反應」給值班人員；Teams 負責跨部門與管理層彙整；Email 負責正式紀錄留存供稽核。如果只裝一個，通常會犧牲掉其中一種情境——例如只裝 LINE，管理層就看不到彙整報表；只裝 Email，值班人員可能延遲數十秒才看到，錯過黃金反應時間。建議至少同時保留「一個即時通道＋Email 留存」的組合。

Lambda 採用「用多少算多少」的計費模式，以本文情境（每15秒到每60秒取樣一次、單廠數十個監測點）估算，每月執行次數通常落在數十萬次等級，遠低於 AWS Lambda 免費額度與低成本區間的門檻。真正的成本大宗通常在於感測器硬體、閘道器與初期系統整合服務，雲端運算本身的費用相對可控。建議在導入前先以小規模試點估算實際流量，再評估年度雲端費用預算。

這也是為什麼 ATLANTIS 提供的不只是感測器硬體，而是包含閘道設定、雲端串接與門檻邏輯建置的完整導入服務。多數中小型製造業客戶並不需要自建 IT 團隊，而是由供應商協助完成初期部署與門檻校準，後續僅需依循簡單的操作介面調整告警設定即可。建議在評估供應商時，明確詢問「導入後的維運責任如何劃分」。

一般工業應用建議每 1～2 年校正一次；高精度或製程關鍵應用（如半導體冷卻水系統）建議每 6 個月一次。若感測器本身支援 HART 通訊（如 SDPT-3100），可透過遠距診斷功能在不拆卸的情況下判斷是否需要提前校正，這對於接入 AWS Lambda 的連續監測系統特別重要——因為感測器一旦漂移，錯誤的原始數據會讓再聰明的雲端判斷邏輯也得出錯誤結論。

建議做法是先蒐集該設備至少 2～4 週的正常運轉數據，建立「基準運轉曲線」，再以偏離基準的百分比（例如 ±15% 為黃色、±25% 為紅色）作為門檻，而非套用產業通用的固定數值。本文表2提供的門檻範例僅為起始參考值，實際部署時建議搭配至少 1 個月的觀察期微調，避免因季節溫度變化或設備老化造成的正常波動被誤判為異常。

短期而言是造成工程師不必要的緊急排查；長期而言，頻繁誤報會導致「警報疲勞」，讓工程師開始忽略通知，這才是真正危險的後果——當真正的異常發生時，可能因為過去太多次誤報而被輕忽。因此門檻設計與告警訊息品質（如本文表4的建議欄位設計）比技術架構本身更重要，這也是為什麼建議導入初期要有 1～2 個月的門檻微調期。

PT-RF321 適合大量部署於一般冷媒系統監測點（吸氣、排氣、油壓），是連續監測的主力機種；SDPT-3100 則適合單一監測點價值高、需要遠端診斷能力的關鍵設備（如半導體製程冷卻水主幹管路）。判斷原則是：看這個監測點故障的代價有多高——代價越高，越值得選擇具備 HART 遠端診斷能力的 SDPT-3100。具體價格請洽詢 ATLANTIS 業務團隊依實際規格報價。

可以。ATLANTIS 感測器多數支援 4-20mA 標準類比輸出或 RS-485 Modbus 數位輸出，這兩種都是既有工廠自動化系統（PLC/SCADA）的通用介面。實務作法通常是「雙軌並行」：既有 PLC 系統維持原本的本地控制邏輯，同時透過閘道器將同一組訊號另外送一份到 AWS IoT Core，兩者互不干擾，AWS Lambda 的雲端判斷是既有控制系統之外「加值的異常偵測層」，而非取代。

建議確認以下三點：（1）裝置與 AWS IoT Core 之間的通訊採用 TLS 加密與憑證雙向驗證；（2）依公司資安政策確認資料儲存的 AWS 區域（Region）是否符合內部規範；（3）IAM 權限採最小權限原則，Lambda 函式僅授予執行判斷與發送通知所需的權限，避免過度授權。若貴公司屬於國安相關或高度管制產業，建議另外評估地端（On-premise）或混合雲架構的必要性。

基本監測建議至少 2 支（吸氣、排氣）；若要完整診斷冷媒充填狀態，建議再加裝油壓與液管視窗前後壓力，共 4 支左右；若是多迴路或多壓縮機系統，則需依迴路數量等比例增加。ATLANTIS 可依實際機型與診斷需求提供監測點配置建議，避免「裝太少看不出問題」或「裝太多增加不必要成本」。

只要異常會反映在壓力訊號的變化上，理論上都能透過類似的門檻與趨勢判斷邏輯偵測，例如：乾燥過濾器阻塞（吸氣壓力異常偏低但排氣正常）、冷凝器結垢或風量不足（排氣壓力持續偏高）、壓縮機閥片磨損（吸氣排氣壓差縮小、效率下降）、冷媒過充（如Q3所述）。每種故障模式的壓力特徵不同，建議依實際設備類型建立對應的判斷規則庫。

壓力傳送器的安裝通常需要在既有壓力量測口或新增取壓點進行，若設備本身已有備用量測口，多數情況下可利用歲修或排定的保養時段完成安裝，單一監測點安裝時間約 30～60 分鐘；若需要新增取壓點（鑽孔攻牙），則需配合系統降壓或短暫停機，建議與 ATLANTIS 工程團隊確認貴廠設備管路配置後，安排在原訂保養排程內施工，將額外停機影響降到最低。

規模大小不是決定性因素，單次故障的代價才是。即使是小型工廠，如果一次冷凍設備故障可能導致整批原料報廢，或是一次製程中斷造成客戶違約賠償，投資這套監測系統的 ROI 可能反而比大型工廠更快回本。建議先盤點貴廠「最怕出事的那一台設備」，從單點試行開始，而非一開始就規劃全廠導入。

這種情況在導入初期屬於正常的門檻校準過程，不代表系統失敗，反而是收集「假陽性」案例、細化判斷邏輯的重要機會。建議建立回饋機制：每次派工後由工程師回報實際檢查結果（確實異常/虛驚一場/其他原因），這些回饋數據可用於逐步優化 Lambda 的判斷門檻與規則，讓系統隨著使用時間拉長而越來越準確。

ATLANTIS 的核心專業是 31 年工業儀錶製造與現場應用經驗，包含感測器選型、安裝與校正服務；雲端 AWS Lambda 架構的軟體開發部分，我們會依客戶既有 IT 資源狀況，提供技術規格建議或協助對接合作的系統整合夥伴，確保感測層的數據品質是雲端判斷邏輯可以信賴的基礎。建議在洽詢時明確告知貴公司內部是否已有雲端開發資源，以便規劃最適合的合作分工。

建議三步驟：第一步，盤點廠內「故障代價最高、但目前監測手段最原始」的 1～2 台設備；第二步，聯繫 ATLANTIS 進行現場勘查，依設備類型建議適合的壓力傳送器型號與監測點配置（可參考本文表2、表5）；第三步，以 4～8 週為試行週期，先驗證感測數據品質與門檻設定，確認告警邏輯符合現場實際狀況後，再評估擴大部署至全廠。歡迎直接致電洽詢：02-2820-3405。