快速對比：

熱電偶（Thermocouple）：

• 原理：兩種不同金屬產生電位差（Seebeck 效應）
• 測溫範圍：K 型 -200°C～+1,370°C（食品應用通常用 -20°C～+100°C 範圍）
• 優點：反應快速（時間常數 < 5 秒）、結構簡單、成本低
• 缺點：需要「冷端補償」（容易引入誤差），精度 ±1°C～±2°C

PT100（電阻溫度計）：

• 原理：白金電阻隨溫度變化
• 測溫範圍：-200°C～+850°C（食品應用用 -20°C～+100°C）
• 優點：精度高（±0.15°C）、長期穩定性好（漂移 < 0.5%/年）
• 缺點：反應稍慢（時間常數 10～30 秒）、成本較高

食品廠選型建議：

• ❌ 如果只是「監控冷庫溫度是否在 -18°C 附近」→ 用熱電偶足夠（反應快，發現異常快）
• ✅ 如果需要「長期數據追蹤 + 精度證明」（例如 GMP 稽核）→ 用 PT100（精度高，數據可信度高）

ATLANTIS 的做法： 我們同時提供兩款產品。對於食品廠，通常推薦「熱電偶（快速告警） + PT100（精度記錄）」的雙感測設計。

簡單對比：

自建伺服器（傳統 IT 方式）：

• 初期成本：伺服器 10～20 萬 + 網路建設 5～10 萬 = 15～30 萬
• 年度維護成本：IT 人員薪資 40～60 萬/年，加上網路、電力、冷卻成本
• 可靠性：依賴單一伺服器，故障時系統停擺
• 安全性：數據存在廠內，若發生火災/停電，數據可能遺失

AWS IoT Cloud（雲端方式）：

• 初期成本：邊緣閘道 8～15 萬（一次性），無需大型伺服器
• 年度成本：月費 500～2,000 元（AWS 訂閱），完全彈性
• 可靠性：AWS 全球數據中心備份，99.99% 可用性 SLA
• 安全性：AWS 級別加密，符合食品安全法規要求的「不可竄改數據」
• 可擴展性：一個設備可擴展到 100 個感測器，成本線性增長，不需額外伺服器投資

食品廠實務考量： 假如你有 8 個冷庫，自建伺服器需要 IT 人員常駐維護，AWS 則完全託管，廠商只需一個兼職人員定期檢查。成本和風險都更低。

簡單解釋：

4-20mA 是工業標準的「電流訊號」。數值範圍是 4～20 毫安培（mA）：

• 4 mA = 最低溫度（例如 -20°C）
• 20 mA = 最高溫度（例如 +80°C）
• 12 mA = 中間溫度（例如 +30°C）

為什麼食品廠要用 4-20mA？

• ✅ 抗干擾能力強：工廠內有許多電機、馬達產生的電磁干擾，電流訊號（4-20mA）比電壓訊號（0-10V）更穩定
• ✅ 長距離傳輸穩定：若感測器距離主控室 50～100 公尺，電流訊號不會衰減，電壓訊號則會損耗 20～50%
• ✅ 故障自診斷：若線路斷開，訊號會跌到 0 mA，系統能自動檢測「感測器故障」並警報
• ✅ 業界標準相容：AWS 邊緣閘道、PLC、資料採集模組都支援 4-20mA 直接接入

ATLANTIS 產品選型： DTT-P4 和 LTPT-410RS 都是標準 4-20mA 輸出，可直接連接 AWS Greengrass。

實際情況： 食品冷庫溫度通常 -18°C～-25°C，ATLANTIS 熱電偶感測器可以在 -40°C～+80°C 正常運作，所以「低溫損壞」根本不是問題。

真正的壽命決定因素：

• 感測器本身：超過 10 年無故障（如果選用 304 不銹鋼外殼）
• 訊號線路：因為冷凝結霜，可能 3～5 年需要更換一次（冷縮熱脹導致裂口）
• 外殼封套：若使用防冷凝套管，可延長線路壽命至 8～10 年

維保建議：

• 每 6 個月檢查一次感測器連接處（是否有結霜、腐蝕）
• 每 3 年更新一次訊號線（預防性維保）
• 感測器標定（精度檢測）每 2 年一次

ATLANTIS 提供「現場標定服務」，不需拆卸感測器即可進行精度驗證。

簡短答案：不會。這是邊緣計算（Edge Computing）的設計重點。

運作原理：

• 感測器數據首先存儲在「邊緣閘道」（Raspberry Pi 或工業閘道）的本地資料庫
• 閘道每 30 秒嘗試上傳到 AWS，若網路中斷，則在本地快取
• 網路恢復後，會自動補上所有歷史數據到雲端
• 食品廠稽核人員可以查看「完整的溫度曲線」，包括網路斷線期間

最壞情況下的安全機制：

• 邊緣閘道內置 64GB SSD，可存儲 3～6 個月的完整數據（8 個感測器、每 5 分鐘採樣一次）
• 若閘道硬碟滿了（極罕見），系統會自動警報，廠商需升級存儲或減少保留期限

食品安全法規符合性： HACCP 要求「溫度紀錄必須完整且不可修改」。AWS 的數據備份和時間戳記機制完全符合這個要求。紙本記錄反而無法證明「完整性」。

運作流程：

• 冷庫溫度升高到 -15°C（超出設定範圍 -18°C ±2°C）
• 感測器立即檢測（5 秒內），訊號通過 4-20mA 上傳到邊緣閘道
• 閘道上執行的 AWS Lambda 函式立即觸發，判定「溫度異常」
• AWS SNS（簡單通知服務）立即發送多渠道警報：
  • 手機推播通知（主管、廠長、品質主管）
  • 簡訊（確保即使沒收到推播也能收到短訊）
  • 郵件通知（含溫度曲線圖表）
  • Slack/LINE 企業頻道通知（團隊協作）
• 管理人員可以透過手機 APP 查看「實時溫度」和「過去 24 小時曲線」，決定是否立即前往處理

設定彈性：

• 可設定「值班表」（例如：晚上 22:00～08:00 由安全員值班，只通知安全員手機）
• 可設定「分級警報」（例如：溫度升到 -15°C 時推播，升到 -10°C 時同時簡訊和來電提醒）
• 假日前可設定「更嚴格的閾值」（例如：假日期間改為 -18°C ±1°C）

案例應用： 某廠因為集火災，冷卻水斷電，冷庫溫度從 -18°C 快速上升。系統在 3 分鐘內偵測異常，通知廠長。廠長立即啟動「應急冷卻方案」（臨時液氮供應），搶救了 95% 的產品。若沒有實時警報，損失會是 2,000 萬。

食品廠常被問到的 5 個問題：

1. 「請提供過去 3 個月的冷庫溫度紀錄。」
   • ❌ 紙本方式：翻出 90 天的簽核表，但無法證明「每小時溫度連續」
   • ✅ 雲端方式：一鍵下載完整的溫度曲線（甚至每 5 分鐘一筆數據），附帶時間戳記、感測器 ID、自動警報紀錄
2. 「如果發生溫度異常，你們怎麼追蹤？誰在什麼時間發現的？」
   • ❌ 紙本方式：「我們每天巡檢 3 次，應該會發現…」（無法證明）
   • ✅ 雲端方式：「系統自動在異常發生 3 分鐘內通知主管，對應的通知訊息、時間、接收人員都有完整紀錄」
3. 「感測器精度如何保證？最後一次校正是什麼時候？」
   • ❌ 紙本方式：「我們大概每年校正一次…」（無文件證明）
   • ✅ 雲端方式：「每次校正都有數位簽核紀錄，上傳到雲端系統，標定證書自動存檔」
4. 「如果系統發生故障，你們怎麼處理？」
   • ❌ 紙本方式：「我們會改成手工巡檢…」（這其實不是應急方案，而是「系統失效」）
   • ✅ 雲端方式：「我們有備用感測器和備用邊緣閘道現場存放，故障發生後 2 小時內可恢復。同時邊緣閘道有本地快取，故障期間數據不會遺失」
5. 「你們的溫度紀錄可以被修改嗎？」
   • ❌ 紙本方式：「如果簽核表弄濕了，我們可能要用筆修改…」（不符合法規）
   • ✅ 雲端方式：「AWS 數據庫採用『區塊鏈式』時間戳記，任何修改都會留下『修改紀錄』。即使廠內管理人員也無法刪除或竄改歷史數據」

稽核官的最終評語： 「這套系統已經超過法規最低要求。不僅符合 HACCP，還符合『可追溯性』和『資料完整性』的高階標準。」

設計方案：「帳號分層」

• 廠長級帳號（Administrator）：可以看全部數據、修改警報設定、管理其他帳號
• 主管級帳號（Manager）：可以看自己部門的數據、確認警報
• 員工級帳號（Viewer）：只能看實時溫度和當週曲線

人員離職時的程序：

• 廠長在系統中「停用」該員工帳號（不刪除，保留審計紀錄）
• 該帳號的所有操作歷史自動歸檔
• 系統自動轉移「該員工負責的監測點」給新主管
• 所有歷史數據保留在 AWS，永遠不會因為帳號停用而遺失

數據保留政策：

• AWS Timestream 預設保留 3 年完整數據（符合食藥署要求）
• 超過 3 年的數據自動存檔到 Amazon S3（成本更便宜），仍可查詢但讀取速度稍慢
• 廠商可選擇「永久保留」（成本約 +30%/年）

簡短答案：完全不需要停線。導入過程完全「無縫」。

分階段導入計畫：

• 第 1 週（現場評估階段）：
  • ATLANTIS 技術人員上門測量、評估每個冷庫的「溫度取口位置」
  • 決定感測器安裝點（通常在冷庫進出口）
  • 規劃網路線路（不涉及生產區域改動）
• 第 2 週（硬體安裝）：
  • 感測器安裝「不需停線」（只在冷庫壁面打孔，佈設 4-20mA 信號線）
  • 邊緣閘道（主控室內）安裝（完全不影響生產）
  • 測試每個感測器的訊號強度
• 第 3 週（軟體配置 + 測試）：
  • AWS 帳戶開通、IoT Core 配置
  • Lambda 函式部署（警報規則）
  • 手機 APP 和郵件通知設定
  • 全系統壓力測試（模擬溫度異常，驗證警報運作）
• 第 4 週（員工培訓 + 上線）：
  • 廠長、品質主管、安全員參加 1 小時線上培訓
  • 現場展示如何使用手機 APP、查詢歷史數據
  • 系統正式上線（同時保留紙本簽核表 1 個月，雙軌過渡）

對生產的影響： 零。整個過程完全不涉及冷卻系統的改動，溫度監控方式從「人工簽核」升級為「自動記錄」，生產流程毫無變化。

成本分析（以小型廠為例）：

• 2 個冷庫需要 2 個感測器 × 3,500 元 = 7,000 元
• 邊緣閘道 × 1 = 10,000 元
• 安裝 + 配置服務 = 8,000 元
• 初期投資共：25,000 元
• 年度 AWS 雲端費用：1,000～1,500 元

風險成本對比：

• 小型廠每年產值約 1,000～2,000 萬
• 若因溫度異常損失一批產品（50～100 萬），那已經抵掉 2～4 年的導入成本
• 加上「食品安全法規日趨嚴格」，小廠遲早要導入。及早導入反而風險更低

小型廠的現實困境：

• 小廠通常沒有「品質專責部門」，廠長或主管身兼多職
• 傳統紙本方式容易遺漏溫度監控（因為太忙）
• 一旦被稽核不通過，改善成本比大廠還高（因為缺少專業人力）

ATLANTIS 建議： 小型廠更應該導入自動化系統，因為可以用「最低成本」實現「最嚴格的監控」，讓管理人員從「重複巡檢工作」中解放出來，專心做其他事。

FDA 21 CFR Part 11 是什麼？

美國食品藥物管理局（FDA）的法規，要求電子記錄系統必須具備：

• 數據完整性（無法竄改、有修改軌跡）
• 時間戳記（精確到秒）
• 使用者認證（誰修改的、什麼時候改的）
• 加密儲存與傳輸
• 審計日誌（完整的操作紀錄）

ATLANTIS + AWS 系統符合嗎？

✅ 完全符合。甚至超過要求。

• ✅ AWS 採用 AES-256 加密
• ✅ 所有操作有時間戳記（精確到毫秒）
• ✅ 任何數據修改都留下「誰、什麼時間、改了什麼」的軌跡
• ✅ 導出的報表含有數位簽章，無法偽造
• ✅ 所有數據自動備份到 3 個不同地理位置的 AWS 數據中心

實務上的好處： 若你的客戶要求「提供符合 FDA 的溫度證明」，你可以一鍵導出「符合 FDA 格式」的報表，完全無需額外文件整理。

成本結構：

• 硬體成本（感測器）：線性增加。每個感測器 3,000～5,000 元
• 邊緣閘道成本：非線性。1 個閘道可以支援 100～200 個感測器（通常只需 1 個）
• AWS 雲端成本：小幅增加。訊息數量多了，但 AWS 提供「量級折扣」

成本案例對比：

規模優勢： 當你有 50 個感測器時，單位成本只剩下 2 個感測器時的 1/3。這就是「邊緣計算 + 雲端」的成本優勢。

技術支援：

• ATLANTIS 提供「API 文件」，讓客戶的軟體工程師可以自行連接 AWS IoT 數據
• 我們提供「測試環境」（沙箱）供開發階段使用
• 提供「技術顧問」協助集成（時數計費）

開發成本估算：

• 簡易版 APP（基本溫度顯示 + 警報）：3～5 萬
• 進階版（完整數據分析 + 報表導出）：8～15 萬

我們通常建議： 除非你有明確的「差異化需求」（例如集成到現有 ERP 系統），否則用我們的預設 APP 更划算。預設 APP 已經包含 99% 的食品廠所需功能。

故障應急流程：

• 感測器故障 → 立即觸發「感測器離線」警報（系統自動偵測）
• 廠商聯繫 ATLANTIS，我們在 24 小時內寄出「備用感測器」（現地備品庫中取）
• 廠商自行或請 ATLANTIS 派員更換（30 分鐘內完成）
• 更換後系統自動恢復，無需任何軟體重新配置

數據遺失風險： 完全不會。因為：

• 故障期間其他 7 個感測器繼續正常運作
• 若整個邊緣閘道故障（極罕見），本地快取會保留所有數據直到網路恢復
• 雲端 AWS 的數據永遠不會因為本地設備故障而遺失

最壞情況應急方案： 若感測器連續故障 3 天（更換延遲），廠商可以臨時用「傳統溫度計 + 手寫記錄」填補空檔，系統之後仍能導入補充數據（附註說明故障時段）。食品安全法規可以接受「有說明的數據缺口」，但不能接受「毫無紀錄」。

簡短答案：完全可以。而且成本最低。

擴展流程：

• 購買新感測器 × N 個
• 安裝新感測器，連接到現有的邊緣閘道
• 在 AWS 後台「新增感測器 ID」（5 分鐘完成）
• 新感測器立即開始記錄溫度，無需停機

成本特點：

• 邊緣閘道是「一次投資」，後續擴展無需再買
• AWS 成本小幅增加（訊息量增加），但有「量級折扣」
• 人工線路改造成本最小（因為邊緣閘台通常放在中央位置）

3 年後擴建成本估算：

• 新感測器 × 10 個：4 萬元
• 安裝費用：5,000 元
• 年度增加雲端費用：500 元/年
• 總計：4.5 萬元（遠低於「重新建立一套新系統」的 20～30 萬）

完全可以。實際上是很常見的應用。

混合監控的案例：

• 冷凍庫：-18°C ± 2°C（警報）
• 冷藏庫：+4°C ± 1°C（警報）
• 烘焙房：+50°C～+70°C（警報若超出範圍）
• 發酵室：+25°C ± 2°C（警報）

系統設定方式：

• 每個感測器獨立設定「警報上下限」
• AWS Lambda 根據「感測器位置」判斷「該有什麼溫度」，自動觸發相應警報
• 廠商可在 APP 中「按區域查看」，例如點擊「冷凍區」只顯示冷凍庫的溫度

高級應用： 系統可以建立「溫度相關性規則」。例如：

• 「若冷藏庫溫度超過 +8°C，且超過 2 小時，自動觸發『高級警報』並通知環保機關」（符合食品法規要求）
• 「若烘焙房溫度超過 +80°C（表示烤爐故障），自動切斷電源防止火災」

這種「跨區域的智能規則」是紙本系統完全無法做到的。

好問題。這涉及「HACCP 實務」。

實務上的區別：

• 空氣溫度：冷庫內懸掛的溫度計測的是冷風溫度（通常在冷風出口）
• 產品溫度：冷凍食品的「心部溫度」（產品中心），才是食安的真正指標

實務困難：

• 「產品溫度」無法直接即時測量（除非在每個產品內插入感溫針，不現實）
• 業界通常假設「空氣溫度 -18°C → 產品溫度也是 -18°C」（要放置足夠長時間，通常 24 小時以上）
• 食藥署要求「監控『維持溫度』而非『達到溫度』」，所以「空氣溫度持續 -18°C」即代表產品是安全的

ATLANTIS 的建議：

• 感測器應該安裝在「冷風主要出口」，而不是「冷庫角落」
• 同時安裝「備份感測器」在「中層貨架」（驗證冷卻均勻性）
• 每季做一次「人工驗證」（用紅外線溫度計測產品心部溫度，確認與系統一致）

ATLANTIS 技術人員會在安裝時協助「找到最佳感測位置」。

短答案：系統無法自動區分，但可以提供「線索」讓廠商判斷。

分析方法：

• 設備故障的溫度曲線：溫度「緩慢、持續上升」（冷媒洩漏 or 馬達故障的特徵）
• 人為誤操作的溫度曲線：溫度「快速、短時間波動」（打開冷庫門 5～15 分鐘，溫度上升後回復）

進階智能規則： 廠商可設定 Lambda 函式：

• 「若溫度在 5 分鐘內恢復正常 → 記錄為『可能的人為誤操作』，發送『低級警報』」
• 「若溫度超過 2 小時未恢復 → 記錄為『可能的設備故障』，發送『高級警報』並通知維修部」

實務效果： 某廠導入系統後，發現「下午 14:00～15:00 每天都有溫度小波動」。查證發現是「接貨員習慣在這個時段開冷庫收貨」。系統自動提示改用「更快的接貨流程」，消除了不必要的溫度波動。

完全可以。而且是系統的「隱藏強功能」。

可提供的分析報表：

• 📊 溫度穩定性指標：「某冷庫過去 6 個月的溫度波動標準差」（用於判斷冷卻系統效率）
• 📊 能源消耗預測：「若改善隔熱結構，可降低能耗 X%」
• 📊 設備壽命預測：「壓縮機運行頻率、停機時間，可預估還能用多久」
• 📊 成本優化建議：「定期清潔冷凝管，可以降低壓縮機運行負荷 15%，年省電費 X 萬」

實務效果案例：

• 某廠分析發現「冷庫 #3 的溫度波動明顯大於其他冷庫」（標準差 0.8°C vs 0.3°C）
• 調查發現「冷凝管 3 個月未清潔，堵塞導致冷卻效率下降」
• 清潔後溫度穩定性恢復，壓縮機運行時間從 18 小時/天降至 14 小時/天
• 年度省電費：12 萬（4 個月內回本）

這種「數據驅動的優化」是紙本系統完全無法做到的，也是「導入成本快速回本」的原因。

簡短答案：完全可以。一套系統同時符合台灣、日本、美國、歐盟的食安法規。

各國法規對比：

實務應用：

• 廠商可「一鍵導出」符合各國法規格式的報表
• AWS 自動處理「各國數據保護法規」（台灣數據存台灣 DC，日本數據存日本 DC，美國數據存美國 DC）
• 審計日誌自動含有「多語言」說明（中文、日文、英文）

多國出口廠商通常在「食安合規」上花費大量成本（顧問費、重複稽核）。一套 ATLANTIS + AWS 系統可以全部搞定，反而成為「競爭優勢」。