核心原因：穩定性

• Pt100：精度漂移 < 0.5%/年，5 年後誤差累積 < 2.5%。30 年前的 Pt100 和今天的 Pt100 讀出相同溫度，差異 < 1°C
• K 型熱電偶：精度漂移 1～2%/年，2～3 年後已不可信。用舊數據和新數據比較時，「年份間差異」可能是「感測器老化」不是「真實溫度變化」

對 Timestream 的影響： 若你要分析「過去 10 年的溫度趨勢」，需要確保「10 年前的數據和今天一樣準確」。只有 Pt100 能做到。

壓縮原理：冗餘消除

大多數工業溫度數據是「平穩變化」的。例如冷凍庫溫度可能是：

時間         溫度
10:00:00   -18.0°C
10:00:30   -18.1°C
10:01:00   -18.0°C
10:01:30   -18.2°C
10:02:00   -18.1°C
10:02:30   -18.0°C
10:03:00   -18.1°C
        

Timestream 的壓縮邏輯：

• 檢測「溫度變化的模式」（在 -18.0 到 -18.2 間小幅波動）
• 用「數學模型」描述這個模式：「基準溫度 -18.1°C，波動範圍 ±0.1°C」
• 存儲 7 筆數據變成 2 個參數，儲存空間減少 70%
• 查詢時自動「還原」，用戶看到的仍是完整的每 30 秒一筆的原始數據

精度損失嗎？ 零損失。壓縮只是「改變存儲格式」，查詢時完全還原。

三層存儲設計：

• 熱儲存（0～7 天）：最近數據，存在高速 SSD，查詢秒級回應
• 溫儲存（8～30 天）：本月數據，存在混合儲存，查詢 1～3 秒
• 冷儲存（> 30 天）：歷史數據，存在便宜的物理儲存，查詢 10～30 秒

實務上的感受：

• 「查詢今天的溫度曲線」：< 1 秒
• 「查詢本月的溫度統計」：< 2 秒
• 「查詢去年同月的數據比較」：5～10 秒（可接受）
• 「查詢過去 3 年的完整曲線用於預測分析」：15～30 秒（後台跑，不影響即時操作）

廠商可以根據「查詢頻率」決定「熱/溫/冷存儲的比例」。日常檢查的數據放熱儲存，歷史分析的放冷儲存。成本優化和速度平衡。

存儲容量：完全沒有上限

• Timestream 是「無限容量」的服務（只要付錢）
• AWS 用戶存儲超過 1 PB（1,000 TB）的 Timestream 數據，常見

費用計算（100 個感測器，每 30 秒採樣）：

• 年產生數據量：103 億筆
• 自動壓縮後：約 20～30 GB/年（壓縮率 60～80%）
• 年度存儲成本：30 GB × 0.01 美元/GB × 12 月 ≈ 3.6 美元/年 ≈ 115 元台幣/年
• 加上「攝取費用」（每百萬筆 $0.50）：103 億 ÷ 100 萬 × $0.50 ≈ $5,150/年 ≈ 16 萬台幣/年
• 年度總成本：約 17 萬台幣

（如果用傳統 SQL 資料庫，存儲 30GB 可能需要 30～50 萬/年）

AWS 的安全等級是「銀行級」：

• ✅ 所有數據「傳輸中加密」（TLS 1.2 以上）
• ✅ 所有數據「儲存時加密」（AES-256）
• ✅ AWS 帳戶可以設定「MFA（雙重認證）」，即使密碼被竊也無法登入
• ✅ 可以設定「IP 白名單」，只允許特定辦公室 IP 訪問
• ✅ AWS IAM（身份管理）可以設定「細粒度權限」（例如：只允許「查詢」不允許「刪除」）

實務上： AWS Timestream 已被美國政府、銀行、醫院等「需要最高保安」的組織使用。相比之下，「自建伺服器存在公司網路」的安全性反而更低（容易被內部人士竊取）。

完全可以定制。甚至超過預期。

• ✅ QuickSight 提供「拖拽式報表編輯器」，廠商自己可以設計報表
• ✅ 可以設定「自動排程」（每日早上 08:00 自動生成昨天的報表，寄郵件給主管）
• ✅ 可以內嵌「警報條件」（例如：「若冷凍庫溫度變化斜率 > 0.1°C/小時，報表背景變紅」）
• ✅ 可以與「其他部門的數據」整合（例如：溫度數據 + 生產計劃 + 電費統計，放在一份報表）

不需要寫代碼。 廠商的品質主管可以自己「點擊幾個按鈕」定制報表。

推薦：共用一份 Timestream。

• 原因：Timestream 支援「多維度標籤」（tag），可以區分「區域、設備、感測器類型」等
• 查詢時篩選：「查詢 A 區域的溫度」或「查詢所有區域的冷卻機溫度」都很方便
• 成本最低：共用一份資料庫，存儲費用和管理費用都最低

若分開多份資料庫，好處是「隔離」，但缺點是「無法做跨區域的對比分析」（例如：哪個區域的冷卻效率最高）。

兩種方式都支援：

• 規則引擎（簡單）：「若溫度 > 90°C 持續 5 分鐘」→ 警報。廠商自己設定規則
• AI 異常檢測（高級）：Timestream 配合 AWS SageMaker（機器學習），自動分析「溫度的正常行為」，發現「異常偏離」

AI 的優勢：

• ✅ 「聰明」地區分「設備需要清潔」vs「正常的溫度波動」
• ✅ 學習「季節性」（夏季正常溫度 > 冬季），避免誤警報
• ✅ 預測「故障前的微弱信號」（例如：溫度斜率逐漸增加，預示設備快故障）

大廠通常用「規則 + AI」混合方案。簡單故障用規則（快），複雜故障用 AI 預測。

完全可以。而且很簡單。

• ✅ QuickSight 報表可以「一鍵匯出」為 CSV 或 Excel 格式
• ✅ 或者用 AWS CLI（命令行工具）直接查詢 Timestream，匯出 CSV
• ✅ 或者用 Python 腳本配合 Timestream API，自動每天匯出新數據

Timestream 對「數據匯出」沒有限制。你可以隨時拿出數據去其他地方分析。

可以。而且 Timestream 的數據「比紙本更有說服力」。

• ✅ Timestream 提供「時間戳記」（精確到毫秒），證明「什麼時間測的」
• ✅ 提供「修改日誌」（若有修改，完整記錄「誰改、什麼時間、改成什麼」）
• ✅ 提供「加密驗證」（數據未被篡改的密碼學證明）
• ✅ 一鍵生成「符合 FDA 21 CFR Part 11 格式」的報表

稽核官看到「Timestream 生成的報表」通常會說：「這個真的符合法規要求。」（因為 AWS 專門針對法規合規做設計）

非常大。校正是「數據可信度」的基石。

• 未校正的感測器：第 1 年精度 ±0.15°C，第 3 年可能變成 ±0.8°C（漂移 600%）
• 定期校正：每 2 年校正一次，可以確保精度始終 ±0.15°C

對 Timestream 分析的影響：

• ❌ 若感測器未校正，3 年的溫度「趨勢分析」會被「感測器老化」污染，無法信賴
• ✅ 若定期校正，3 年的數據都「可信」，趨勢分析準確率 > 95%

ATLANTIS 的做法： 提供「校正服務」（每 2 年一次）。校正後自動記錄在 Timestream，系統會自動「計算校正前後的偏差」並調整歷史數據，確保數據連貫性。

Timestream 完全支援「多時間序列相關性分析」。

例如，想知道「冷卻機出風溫度」和「冷藏庫內溫度」的「延遲相關性」（出風溫度變化後，庫內溫度要多久才跟進）：

SELECT
  出風溫度時間序列,
  SHIFT(庫內溫度) OVER (ROWS BETWEEN 10 PRECEDING AND CURRENT ROW) AS 延遲庫內溫度,
  CORRELATION(出風溫度, 延遲庫內溫度) AS 相關性係數
FROM Timestream
        

結果可能發現：「出風溫度下降後，庫內溫度要 15 分鐘才跟進」。用這個發現可以優化「溫控算法」（提前 15 分鐘開啟冷卻機）。

可以。結合 Lambda 和 Timestream 實現「自動故障檢測」。

例如設定規則：

IF 連續 5 筆數據相同（溫度未變化，不合理） THEN:
  發送「感測器可能故障」警報
  自動切換到備用感測器（若有）
        

或者用 AI 方法：學習「正常的溫度變化模式」，若出現「異常的平坦曲線」自動判定為故障。

完全可以。這是 Timestream 的強項。

• ✅ Timestream 支援「外部資料源聯接」（join）
• ✅ 可以將「溫度時間序列」和「生產計劃（ERP 數據）」結合
• ✅ 結合後可以分析：「生產 A 產品時，平均冷卻時間 2 小時；生產 B 產品時，平均冷卻時間 4 小時」

實務應用： 用這個分析可以優化「生產排程」。如果某個產品冷卻時間長，可以「改變烤爐溫度」或「延長冷卻階段」來平衡。

通常需要「6 個月～1 年」的完整歷史數據。

• 6 個月：可以建立初步模型（準確率 60～70%）
• 1 年：覆蓋「四季變化」，模型準確率提升至 80～90%
• 3 年：包含「長期老化趨勢」，模型準確率 > 95%

為什麼需要這麼多？ 機器學習需要「足夠的正負例」（既有正常數據，也有故障前的異常數據）。太少數據會「過擬合」（在已知數據上準確，但對新情況無法預測）。

Timestream 最大的優勢就是「能存 10 年的完整數據」，讓你有足夠的歷史資料建立可靠的預測模型。

這取決於「想測什麼」。三種常見位置有不同目的：

• 1. 設備進風口：測「冷卻源的溫度」（診斷冷卻系統健康度）
• 2. 設備出風口：測「設備散出的熱量」（評估冷卻效果）
• 3. 設備核心位置（軸承、馬達線圈）：測「最熱的地方」（真實工作溫度，用於過熱防護）

ATLANTIS 的建議： 對於「需要長期歷史分析」的應用，建議「進風 + 出風」雙感測設計。這樣可以計算「溫度差」（ΔT），用來判斷「冷卻效率是否下降」。

完全支援。而且這是預設行為。

• ✅ 感測器數據「實時流入」Timestream（每 30 秒一筆）
• ✅ Lambda 對「最新數據」做實時判斷（例如：溫度 > 90°C 立即警報）
• ✅ 同時，QuickSight 在「後台」做批次分析（例如：每天 22:00 計算昨天的能耗趨勢）

兩個過程互不影響。「實時警報」不會因為「後台批次分析」而延遲。

AWS 自動在「3 個地理位置」備份數據。

• ✅ 同區域：有多個備份副本（秒級同步）
• ✅ 跨區域：自動複製到另一個地理位置（數分鐘同步，付費選項可升級到秒級）
• ✅ 長期保留：可以設定「自動備份到 S3」（成本更低，但恢復時間較長）

實務上： AWS 資料中心「故障」是超級罕見的事件（平均 10 年 1 次，且通常只是「輕微中斷」不是「完全喪失」）。而且即使發生，AWS 會自動切到「備份副本」，用戶無感知。

完全可以。這是 QuickSight 的「標準應用」。

• ✅ QuickSight 可以在一個頁面展示 50+ 個即時數值
• ✅ 可以「顏色編碼」（例如：溫度 > 85°C 顯示紅色，正常顯示綠色）
• ✅ 可以「地圖視圖」（例如：廠區平面圖，每個位置標示溫度）
• ✅ 可以「鑽取分析」（點擊某個感測器，展開詳細 24 小時曲線）
• ✅ 自動每 30 秒刷新（實時性 < 1 分鐘）

廠長可以在「辦公室看著儀表板」，一眼掌握整個工廠的溫度狀況。

成本和定制性是核心差異。

• 國際平台：初投資 200～500 萬，年度維護 50～100 萬，功能「全面但固定」
• Timestream 方案：初投資 50～100 萬，年度運營 5～10 萬，「靈活定制」（改 Lambda 邏輯、改 QuickSight 儀表板）

Timestream 的優勢：

• ✅ 成本 1/10
• ✅ 完全定制（不受廠商的「標準功能」限制）
• ✅ 無廠商鎖定（用標準 AWS，隨時可換）
• ✅ 支援快速（ATLANTIS 台灣團隊，3 天內可調整）

劣勢： 需要「IT 基礎」或「願意聘請顧問」。