學校廚房大規模溫度監控完整指南
學校廚房大規模溫度監控完整指南
從 HACCP 標準到 IoT 自助串接的食品安全監控體系 — 適合 319 校級規模的廚房運營方案
第 1 章
問題與現狀 — 為什麼學校廚房需要溫度監控?
⚠️核心問題: 目前國內 319 校型的大規模廚房,每天需處理 500~1000 名學生的營養午餐。廚房內存在多個溫度敏感區域:
- 冷藏櫃區 — 需維持 0°C~4°C,防止食物腐敗與細菌滋生
- 蒸煮加熱區 — 需達到中心溫度 ≥ 63°C,確保病原體滅活
- 保溫區 — 需維持 60°C~65°C,防止食物冷卻與二次污染
- 蒸汽鍋爐系統 — 壓力需控制在 0.1~0.5 MPa,超壓會損傷設備
🔥傳統問題
手工記錄的風險: 許多學校仍依賴員工每小時用溫度計手工記錄,這導致:
- 人為誤差:1~3°C 的記錄誤差很常見
- 監控盲點:下班後、假日無人記錄
- 追溯困難:一旦食安事件發生,無法快速定位問題時點
- 法規風險:衛生單位稽查時無完整記錄,面臨罰款
💡機遇: 近年 IoT 溫度感應器成本大幅下降(單套成本已降至 $2,000~$5,000),結合自助串接方案,學校無需支付高額軟體授權費,即可建立符合 HACCP 的監控體系。
第 2 章
物理基礎 — 溫度、壓力、熱傳遞耦合原理
🧬 廚房溫度監控的底層邏輯涉及三個物理量的耦合:
2.1 溫度與病原體滅活
食品中致病菌(如大腸桿菌、沙門氏菌、李斯特菌)的生死臨界點:
| 溫度範圍 | 細菌狀態 | 應用場景 |
|---|---|---|
| 0°C ~ 4°C | 緩慢繁殖(冷藏狀態) | 冷藏食材保存 |
| 5°C ~ 60°C | 快速繁殖(危險溫度帶) | 盡量避免;若必須經過,應 <2 小時 |
| 63°C, 30 分鐘 | 大部分病原體滅活(巴氏消毒) | 廚房蒸煮標準溫度 |
| ≥ 75°C, 1 分鐘 | 幾乎所有病原體滅活 | 高風險食材(肉類)的加熱標準 |
HACCP 啟示: 溫度不是單點控制,而是時間-溫度的組合控制。例如,63°C 需維持 30 分鐘才能確保滅菌,單純達到 63°C 後立即冷卻是不夠的。
2.2 蒸汽壓力與食品加熱效率
蒸汽加熱是廚房最高效的加熱方式。壓力越高,蒸汽溫度越高,加熱速度越快:
| 蒸汽壓力 (MPa) | 蒸汽溫度 | 食品中心溫度達成時間* | 能耗 |
|---|---|---|---|
| 0.1 | 99.6°C | 45 分鐘 | 基準 |
| 0.2 | 120.2°C | 20 分鐘 | +15% |
| 0.3 | 133.5°C | 12 分鐘 | +25% |
* 假設食材為 2kg 食肉類,初始溫度 5°C,目標溫度 63°C
✅設計啟示
透過監控蒸汽壓力,可以推斷食品加熱速率,進而預測何時達到安全溫度。過低的壓力意味著加熱效率下降,可能導致安全溫度達成時間延長。
第 3 章
硬體架構 — 感應器選型與網路設計
🔧 一個完整的廚房溫度監控系統包含五個硬體層:
3.1 感應器層
溫度感應器類型比較:
| 類型 | 精度 | 響應時間 | 成本 | 適用場景 |
|---|---|---|---|---|
| PT100 RTD | ±0.5°C | 1~3 秒 | $80~$150 | 冷藏、保溫區 |
| K-型熱電偶 | ±1°C | 0.5~1 秒 | $30~$80 | 高溫蒸煮區 |
| NTC 熱敏電阻 | ±1.5°C | 2~5 秒 | $10~$30 | 低成本監控 |
| 紅外線溫度計 | ±2°C | 即時 | $200~$500 | 表面溫度快速測量 |
推薦配置(針對 319 校):
- 冷藏區 × 3 組:PT100 RTD,精度最關鍵
- 蒸煮區 × 2 組:K-型熱電偶,響應快速
- 保溫區 × 2 組:NTC 熱敏電阻,成本效益好
- 蒸汽系統 × 1 組:壓力感應器 (0~0.5 MPa)
- 備用 × 1 組:便於替換檢修
3.2 數據采集單元 (Data Logger)
數據采集單元的核心功能是將多個感應器的類比信號轉換為數位信號,並存儲或上傳。選型要點:
- 輸入通道數: 至少 8~12 路(考慮未來擴展)
- 采樣頻率: 建議 ≥ 1Hz(每秒採樣),精度 12 位元以上
- 儲存容量: 至少 32MB(可存儲 3 個月每分鐘採樣的資料)
- 通訊方式: WiFi 或 4G,支持即時上傳
- 成本: $3,000~$8,000
💡實務建議
許多廠商提供「一體化智慧溫度計」(集感應器、通訊、儲存於一身),適合中小規模廚房。但對於 319 校這種大規模廚房,分層架構(感應器+數據采集器)更靈活,便於日後維護和升級。
3.3 網路層
聯網方案對比:
| 方案 | 覆蓋範圍 | 延遲 | 基礎設施成本 | 推薦場景 |
|---|---|---|---|---|
| WiFi (2.4GHz) | 50~100 公尺 | <100ms | $0 (校內既有) | 廚房範圍內監控 |
| LoRaWAN | 1~5 公里 | 100~1000ms | $10,000~$50,000 | 跨區域或多個廚房 |
| 4G/5G 卡 | 覆蓋全島 | <50ms | $500/月 | 偏遠校區或需遠端監控 |
推薦方案: WiFi 為主(無額外成本),備用 4G 作為故障轉移。
3.4 雲端或本地存儲
消費級方案(Google Cloud, AWS, Microsoft Azure)每月成本 $100~$500,但涉及隱私合規問題。推薦本地存儲方案:
- 在廚房或校內伺服器室部署 NAS(Network Attached Storage)
- 成本:$5,000~$15,000(一次性投資)
- 後續維護簡單,數據完全掌握在校內
- 支持客戶自助配置與維護
第 4 章
HACCP 標準解讀
📋 HACCP (Hazard Analysis and Critical Control Point) 是全球食品安全管理的金標準。對於學校廚房,核心要求如下:
4.1 七大原則
- 危害分析: 辨識廚房中所有可能的生物、化學、物理危害(例:交叉污染、溫度不足)
- CCP 辨識: 確定關鍵控制點(Critical Control Point),例溫度、壓力
- 設定臨界限: 為每個 CCP 設定明確的數值臨界值(例:冷藏 ≤ 4°C)
- 監控程序: 建立實時或定期的監控方案
- 糾正措施: 當 CCP 超出臨界值時的應急反應流程
- 驗證與確認: 定期檢驗監控系統的有效性
- 紀錄與追溯: 保存完整的監控、糾正、驗證記錄
4.2 廚房常見 CCP
| CCP | 危害類型 | 臨界限 | 監控方式 | 監控頻率 |
|---|---|---|---|---|
| 冷藏 | 細菌增殖 | 0°C ~ 4°C | 自動溫度感應 | 每 15 分鐘 |
| 蒸煮加熱 | 病原體存活 | ≥ 63°C, 30min | 探針測量食品中心溫度 | 每批次驗證 |
| 保溫區 | 細菌增殖 + 毒素分泌 | 60°C ~ 65°C | 自動溫度感應 | 每 15 分鐘 |
| 蒸汽系統 | 設備損傷、洩漏風險 | 0.1~0.3 MPa | 壓力感應器 | 每 10 分鐘 |
✅法規遵循要點
台灣衛生福利部規定,食品製造業(包括學校廚房)必須建立 HACCP 體系。溫度記錄必須保存 至少 3 個月,並可在衛生稽查時即時提供。自動化監控系統能完全滿足此要求。
第 5 章
蒸汽系統安全管理
🔐 蒸汽系統是廚房的高風險設備,超壓可能導致爆炸。壓力監控是絕對必需。
5.1 台灣法規要求
根據《鍋爐及壓力容器安全規則》,容積 > 1 升的蒸汽容器必須:
- 安裝安全洩壓閥(設定壓力通常為 0.3 MPa)
- 安裝壓力表(精度 ±2.5%)
- 定期檢驗(每年至少 1 次)
- 保存壓力記錄(推薦保存 2 年以上)
⚠️常見違規
許多學校廚房的蒸汽鍋爐年久失修,壓力表損壞、安全閥失效。一旦超壓,可能發生洩漏甚至爆炸。自動化壓力監控能即時發現異常,觸發警報。
5.2 壓力感應器選型
- 量程: 0~0.5 MPa(建議量程為最大工作壓力的 1.5 倍)
- 精度: ±0.005 MPa(±0.5%)
- 防護等級: IP67(防塵防水)
- 輸出信號: 4~20mA 或 0~10V(易於數據采集器讀取)
- 成本: $500~$1,500
5.3 監控與警報邏輯
{
"steam_system": {
"sensor_id": "steam_001",
"location": "鍋爐出口",
"unit": "MPa",
"normal_range": [0.1, 0.3],
"alerts": {
"low_pressure": {
"threshold": 0.08,
"message": "蒸汽壓力過低,加熱效率下降",
"action": "發送通知到廚師"
},
"high_pressure": {
"threshold": 0.35,
"message": "蒸汽壓力過高,存在安全風險",
"action": "立即觸發警報,通知設備維護員"
},
"critical": {
"threshold": 0.4,
"message": "蒸汽壓力臨界危險",
"action": "自動關閉進氣閥,通知消防隊"
}
},
"log_interval_seconds": 60
}
}第 6 章
實際案例 — 台灣某 319 校食堂
📊 以下是基於真實場景的案例分析(校名保密):
6.1 背景
- 學生人數:650 人
- 廚房規模:180 m²
- 日烹飪量:約 2 噸食材
- 廚房人員:12 人(廚師、幫手、清潔人員)
- 過往問題:手工記錄溫度,經常遺漏;曾因溫度不足引發食安疑慮
6.2 系統配置
| 區域 | 感應器型號 | 數量 | 成本 |
|---|---|---|---|
| 冷藏區 | PT100 RTD | 3 | $450 |
| 蒸煮區 | K-型熱電偶 | 2 | $160 |
| 保溫區 | NTC 熱敏電阻 | 2 | $60 |
| 蒸汽系統 | 壓力感應器 0~0.5MPa | 1 | $1,000 |
| 備用 | 混合 | 2 | $200 |
6.3 建置與ROI
6.4 效益量化
✅直接效益
- 減少人力投入: 原需每小時手工記錄 3 次,現自動化,減少 15 小時/月 = $7,500/年(按廚師時薪計)
- 避免違規罰款: 建立完整監控記錄,衛生稽查通過率 100%,避免 $3,000~$10,000 的罰款風險
- 食材損耗下降: 溫度控制精確,過度冷卻或過度加熱情況減少 8%,年省 $8,000
💡間接效益
- 家長信任度提升:公開透明的溫度監控數據,增強營養午餐品牌形象
- 緊急應變能力提升:一旦發生食安事件,能快速定位問題時點和原因
- 廚師工作滿意度提升:減少手工記錄負擔,可專注烹飪品質
6.5 回本週期
根據上述案例:
- 年度淨效益 = $7,500(人力)+ $8,000(食材)- $2,400(維護)= $13,100
- 投資回本週期 = $28,500 ÷ $13,100 ≈ 2.2 年
- 系統預期壽命 > 8 年,所以長期來看極為划算
第 7 章
決策框架與成本分析
🎯 本章幫助決策者評估是否應該投資溫度監控系統。
7.1 決策檢查清單
判斷標準: 若上述 4 項以上勾選 ✓,則投資 ROI 明顯,強烈建議導入。
7.2 成本分類
| 成本項目 | 規模 (大廚房) | 備註 |
|---|---|---|
| 一次性投資 | ||
| 感應器組件 | $2,000~$5,000 | 取決於區域數量和精度需求 |
| 數據采集器 | $5,000~$8,000 | 支持 8~16 路輸入 |
| 本地儲存 (NAS) | $5,000~$15,000 | 4 盤位以上,容量 16TB+ |
| 安裝與調試 | $8,000~$15,000 | 包括佈線、校準、系統配置 |
| 小計 | $20,000~$43,000 | |
| 年度運營成本 | ||
| 定期檢驗與校準 | $1,500~$3,000 | 1 次/年 |
| 感應器更換耗材 | $500~$1,500 | 老化感應器替換 |
| 軟體授權 (可選) | $0 (自助) ~ $3,000 | 若選擇廠商提供的雲端服務 |
| 技術支援 | $0~$1,000 | 視校內 IT 能力 |
| 小計 | $2,000~$8,500/年 | |
第 8 章
常見踩坑與預防策略
🚧 根據行業經驗,以下是 5 個最常見的失敗案例及其預防方法:
8.1 踩坑 #1:感應器安裝位置不當
問題描述
在冷藏櫃上方安裝溫度感應器,導致讀數偏高(上升熱氣流影響)。實際食材溫度可能 >4°C,卻因感應器位置不當而無法被發現。
預防策略:
- 感應器應置於食材堆放區,距離牆壁和熱源 ≥30cm
- 冷藏櫃感應器應放在中層(避免上層溫度較高、下層溫度較低的分層現象)
- 安裝後,用標準溫度計驗證 5 個不同位置,確保誤差 <±1°C
8.2 踩坑 #2:數據采集器通訊中斷
問題描述
WiFi 信號不穩定或被遮擋(金屬廚具、高磁場環境),導致數據采集器無法連接至伺服器。一旦連接中斷,數據丟失,監控盲點。
預防策略:
- 安裝前進行網路信號測試,確保采集器位置信號強度 ≥-70dBm
- 配置 4G 備用卡,當 WiFi 斷開時自動切換
- 采集器本地儲存 ≥7 天的數據,待網路恢復後自動上傳
- 設置每 15 分鐘的心跳檢測,若 30 分鐘無訊號立即警報
8.3 踩坑 #3:忽視感應器的定期校準
問題描述
感應器安裝後,多年未進行校準。溫度漂移(drift)導致讀數逐漸不準,監控數據失效。HACCP 稽查時被發現,面臨違規。
預防策略:
- 每 6 個月進行一次校準,使用標準溫度源(如冰水混合物 0°C、沸水 100°C)
- 建立校準記錄表,記錄日期、校準人、校準前後讀數
- 若漂移 >±0.5°C,立即更換感應器
- 聘請第三方檢測機構每年進行一次官方校準報告(可作為食安證明)
8.4 踩坑 #4:超出預警阈值後無應急措施
問題描述
系統設置了溫度告警,但廚房人員收到告警後不知道該如何應對。經常發生「打了1000次警報,卻沒有採取任何行動」的情況。
預防策略:
- 建立《溫度異常應急處理操作手冊》,明確界定:
- Yellow Alert (輕度異常):溫度偏離±1°C,立即調整設備、檢查是否有門開啟
- Red Alert (嚴重異常):溫度超出 ±2°C,停止使用該設備,通知維護人員
- Critical Alert (緊急異常):超出 CCP 臨界限,食材隔離、查明原因、決定是否銷毀
- 每月進行一次應急演習,確保全體廚房人員能熟練執行操作手冊
- 將操作手冊張貼在廚房顯眼位置,新員工入職時必須簽署確認
8.5 踩坑 #5:數據格式不符合法規,影響稽查
問題描述
廚房建立了溫度監控系統,但衛生單位稽查時,廚房提供的數據格式混亂(有的是 Excel 匯出、有的是圖片截圖),無法清晰展示 HACCP 要求的「時間-溫度」對應關係。
預防策略:
- 系統應自動生成標準的監控報表,包含:日期、時間、感應器 ID、讀數、是否超警值、人員簽名(如適用)
- 報表應支援 PDF 和 CSV 匯出,便於存檔和查閱
- 每月自動生成合規性審核報告,列出所有異常事件及處理結果
- 保存至少 3 年的歷史數據,應對衛生單位的回溯查詢
第 9 章
20 項常見問題 (FAQ)
回答: 在台灣,依據《食品安全衛生管理法》,學校廚房屬於「大型食品製造業」,必須建立 HACCP 體系。溫度監控記錄是 HACCP 的核心要素,因此是法規要求,而非可選項。但監控方式(手工 vs. 自動化)在法規上並無強制,只要能提供完整記錄即可。不過實務上,自動化監控更能確保記錄完整性和準確性。
回答: 系統故障不等於廚房停止運作。對於短期故障(<4 小時),可以恢復為臨時手工記錄。對於長期故障(>1 天),應立即更換故障感應器或採用備用組件。許多廚房會配置 1~2 套備用感應器,確保快速應對。具體應急程序應納入《廚房操作手冊》。
回答: ±0.5°C 表示感應器的讀數可能偏離真實溫度 ±0.5°C。例如,真實溫度為 63°C,感應器可能讀取 62.5~63.5°C。這是所有物理感應器的固有特性。對於 HACCP 監控,只要精度在 ±1°C 以內就被認為可接受。原因是 HACCP 臨界限本身有裕度(例如:63°C 而非 62.9°C),所以 ±0.5°C 的誤差不會跨越安全邊界。
回答: 是的。每個新加建的冷藏區、蒸煮區等都應配備獨立的溫度監控。好的系統設計應考慮未來擴展,例如在數據采集器上預留未使用的輸入通道,便於日後增加感應器。建議選擇模組化系統,允許動態增加感應器和通道。
回答: 自動化監控是補充而非替代。廚師仍需每日目視檢查冷藏櫃是否有結冰或食材腐敗跡象。原因是傳感器只能測量環境溫度,無法檢測食材本身是否已變質。建議的最佳實踐是:自動化監控負責環境溫度連續監控,廚師每班進行 2~3 次目視檢查。
回答: 建議採取以下措施:
(1) 採用時間戳記 (Timestamp),記錄每個數據點的採集精確時間
(2) 實現讀取紀錄 (Audit Log),記錄誰在何時查閱或下載了數據
(3) 本地儲存優於雲端,減少第三方篡改風險
(4) 定期備份到外部媒體(例如每月一次DVD光碟備份)
(5) 進行密碼保護和用戶權限控制
回答: 改造成本通常不會高於新建,反而可能更低,因為:
(1) 感應器和數據采集器是標準模組,不受廚房大小影響
(2) 佈線可沿著現有管道或隱藏在牆體,不需大規模重建
(3) 本地 NAS 儲存可放在任何位置(甚至學校其他辦公室)
主要成本差異在於:舊廚房可能需要先進行設備檢修(例如鍋爐檢驗),這是獨立成本。
回答: 設計良好的系統應具備以下備受保護機制:
(1) 數據采集器配備本地緩存 (SD卡 或內建快閃記憶體),停電期間持續儲存采樣數據
(2) 不斷電電源 (UPS) 供電,確保采集器運作 ≥4 小時
(3) 感應器本身無需電源(大多數是無源感應器)
(4) 停電復電後,系統自動同步本地數據到伺服器
成本考量:小型 UPS 約 $500~$1,500,強烈建議配置。
回答: 可以。無線感應器(Wireless Temperature Sensor)使用 ZigBee、LoRaWAN 或 WiFi 通訊,優點是安裝簡單、無須佈線。但缺點是:
(1) 電池壽命有限(通常 1~3 年),需定期更換
(2) 無線訊號在金屬廚具環境中衰減明顯
(3) 成本通常比有線感應器高 30~50%
建議:對於新建廚房採用有線方案(成本低、維護少),對於老舊廚房佈線困難的區域才考慮無線方案。
回答: 溫度數據本身不涉及個人隱私,但若系統記錄了廚師的操作日誌(誰在何時調整溫度),則涉及員工隱私。建議:
(1) 溫度監控僅記錄數據,不記錄操作人員
(2) 若要記錄人員操作(用於問責),應事先告知員工並徵求同意
(3) 本地儲存 NAS 位置應限制存取權限
(4) 刪除政策:監控數據保存 3 年後可依法刪除(無法律要求更長期限)
回答: 可以,但需要滿足以下條件:
(1) 多個廚房需要各自部署獨立的感應器和本地數據采集器
(2) 可共享一個中央 NAS 伺服器(通過 VPN 或專線連接),集中儲存所有廚房的數據
(3) 中央伺服器需具備自動數據同步和備份功能
(4) 實務上,建立中央監控儀表板,即時顯示各校廚房狀態,便於總務單位統一管理
這種架構適合有多校園的大型教育機構。
回答: 溫度數據流量非常小。假設 10 個感應器、每分鐘採樣一次,每條數據約 50 字節:
每小時流量 = 10 × 60 × 50 = 30KB
每月流量 = 30KB × 720 = 21.6MB
這對校網幾乎無任何負擔。建議採用本地儲存方案(數據不上傳雲端),頻寬消耗更低。
回答: 廚房應實施以下防護:
(1) 感應器安裝在廚師不易觸及的位置(例如冷藏櫃上方、牆角)
(2) 采集器放在上鎖的機房或辦公室,限制人員進出
(3) 感應器損壞時立即警報並通知主管
(4) 建立故障記錄,用於追蹤異常損壞事件
(5) 配備備用感應器,允許快速替換
實務上,故意破壞極為罕見,主要是無意觸碰,做好物理隔離即可。
回答: 是的,為了安全起見,應當:
(1) 在《廚房 IT 交接清單》中明確規定:員工離職時要重置所有系統密碼
(2) 禁用該員工的系統賬户
(3) 檢查該員工是否有下載過敏感的監控數據
(4) 更新操作手冊中的「授權人員清單」
實務上,一般廚房員工通常沒有直接存取監控系統的權限(只有主廚或食安負責人有),所以密碼重置的影響範圍很小。
回答: 不建議,原因如下:
(1) 消費級設備精度通常 ±2~3°C,不符合 HACCP 要求(±1°C)
(2) 無法連續自動監控,需人工定期記錄
(3) 數據格式混亂,難以符合衛生單位稽查的規範要求
(4) 失敗風險高:手機可能損壞、遺失、被誤刪
消費級應用可作為備用或補充工具(例如廚師用紅外線溫度計快速檢查),但不能作為主要監控系統。
回答: 這是自動化監控最大的價值所在。流程如下:
(1) 食安事件發生日期(例如 8 月 20 日有學生中毒)
(2) 推斷該食材的準備日期(例如前一天 8 月 19 日)
(3) 查詢 8 月 19 日的監控數據,檢查:
- 冷藏溫度是否一直 ≤4°C(沒有?→ 食材腐敗)
- 加熱溫度是否達到 ≥63°C 持續 30 分鐘(沒有?→ 病原體存活)
- 保溫溫度是否穩定在 60~65°C(偏低?→ 二次污染)
(4) 根據數據快速鎖定原因,例如「冷藏櫃故障,導致溫度上升至 15°C,細菌增殖」
(5) 這份詳細證據能幫助法律訴訟中證明廚房已盡力防控,減少賠償責任
反之,若無監控數據,廚房無法證明當時的溫度狀況,食安責任難以澄清。
回答: 根據食品安全法規,建議保存至少 3 年。原因是:
(1) 食安事件可能延後才發現,需要回溯查詢
(2) 衛生單位稽查可能要求提供過去 1~2 年的數據
(3) 民事訴訟時效通常為 2 年,需保存足夠的證據
實務做法:每年自動備份完整的監控數據到外部媒體(光碟、行動硬碟),妥善保管。3 年後可視情況刪除(無法律要求更長保存期限)。
回答: 初期培訓約 4~6 小時:
(1) 系統原理與操作 (1.5 小時)
(2) 應急程序演練 (2 小時)
(3) 數據查閱與報表生成 (1 小時)
(4) 常見故障排除 (1~1.5 小時)
後續維護:每年安排一次複習課程 (1~2 小時),特別是新員工入職時。建議錄製操作影片供隨時查看。
回答: 可以,但需要滿足以下技術條件:
(1) 現有系統需提供 API 介面或 SQL 資料庫連接
(2) 溫度監控系統需支援資料匯出為標準格式 (CSV、JSON)
(3) 需要專業的 IT 人員編寫整合程式
整合的好處:廚房人員在一個儀表板看到所有營運資訊(今日菜單、採購食材、溫度監控、庫存等),提升效率。但整合成本通常需額外 $5,000~$15,000,須謹慎評估 ROI。
回答: 考量以下因素:
(1) 硬體老化:感應器通常可用 5~7 年,數據采集器 8~10 年,超過年限應逐步更換
(2) 功能落後:若需要新功能(例如手機APP遠端監控、AI 異常檢測),可升級軟體或硬體
(3) 維修成本:若年度維修費 > 新設備成本的 20%,建議更新
(4) 法規變更:若有新的 HACCP 要求,可能需要調整監控項目
實務上,感應器分批更換(不需一次全換),系統整體壽命可達 10~15 年。
第 10 章
技術附錄 — 客戶自助串接方案
💻 本章提供客戶自行實現溫度監控系統的完整技術方案,無需依賴昂貴的商用軟體。
10.1 系統架構
🏗️完整流程
[溫度感應器]
↓ (類比信號 / I2C / SPI)
[數據采集器]
↓ (WiFi / 4G)
[本地 NAS 或 Raspberry Pi]
↓ (儲存 + 處理)
[Web 儀表板 / Mobile App]
10.2 硬體列表
| 元件 | 型號建議 | 成本 (USD) | 數量 | 小計 |
|---|---|---|---|---|
| 溫度感應器 (PT100) | Omega PT100-3mm-6" RTD | $80 | 5 | $400 |
| A/D 轉換模組 | ADS1256 (8 通道,24-bit) | $30 | 2 | $60 |
| 單板電腦 | Raspberry Pi 4B (8GB RAM) | $75 | 1 | $75 |
| 儲存裝置 | Kingston A400 SSD 480GB | $60 | 1 | $60 |
| WiFi 模組 | Raspberry Pi WiFi (內建) | $0 | - | $0 |
| USB 電源 | 60W USB-C | $25 | 1 | $25 |
| 壓力感應器 (0~0.5MPa) | Honeywell MLH100PSI06A | $80 | 1 | $80 |
| 總硬體成本 | $700 USD (~NT$22,000) |
✅注意
以上成本為核心感應與採集組件,不含佈線、機械安裝、軟體開發等成本。實際項目成本通常為硬體成本的 3~5 倍。
10.3 Python 數據采集程式
以下是在 Raspberry Pi 上運行的 Python 程式,實現溫度數據采集、儲存與遠端上傳。
#!/usr/bin/env python3
# -*- coding: utf-8 -*-
"""
School Kitchen Temperature Monitoring System
適用於 Raspberry Pi + ADS1256 A/D 轉換器
"""
import time
import json
import os
from datetime import datetime
from decimal import Decimal
import RPi.GPIO as GPIO
import sqlite3
import requests
from threading import Thread
import logging
# ============= 配置段 =============
CONFIG = {
"db_path": "/var/lib/temperature_monitor/data.db",
"log_path": "/var/log/temperature_monitor/",
"update_interval": 60, # 采樣間隔 (秒)
"sensors": {
"cold_storage_1": {"channel": 0, "name": "冷藏櫃 #1", "unit": "°C", "min": 0, "max": 5},
"cold_storage_2": {"channel": 1, "name": "冷藏櫃 #2", "unit": "°C", "min": 0, "max": 5},
"cooking_area": {"channel": 2, "name": "蒸煮區", "unit": "°C", "min": 63, "max": 85},
"warming_area": {"channel": 3, "name": "保溫區", "unit": "°C", "min": 60, "max": 65},
"steam_pressure": {"channel": 4, "name": "蒸汽壓力", "unit": "MPa", "min": 0.1, "max": 0.35},
},
"alerts": {
"low_temp": 2.0, # 溫度偏低 2°C 以上
"high_temp": 2.0, # 溫度偏高 2°C 以上
"critical": True, # 啟用緊急警報
},
"cloud_upload": {
"enabled": False, # 暫停雲端上傳,改為本地儲存
"url": "https://api.example.com/temperature",
"api_key": "YOUR_API_KEY_HERE"
}
}
# ============= 日誌設定 =============
os.makedirs(CONFIG["log_path"], exist_ok=True)
logging.basicConfig(
level=logging.INFO,
format='%(asctime)s - %(name)s - %(levelname)s - %(message)s',
handlers=[
logging.FileHandler(os.path.join(CONFIG["log_path"], "monitor.log")),
logging.StreamHandler()
]
)
logger = logging.getLogger(__name__)
# ============= 資料庫初始化 =============
def init_database():
"""初始化 SQLite 資料庫"""
os.makedirs(os.path.dirname(CONFIG["db_path"]), exist_ok=True)
conn = sqlite3.connect(CONFIG["db_path"])
cursor = conn.cursor()
cursor.execute('''
CREATE TABLE IF NOT EXISTS measurements (
id INTEGER PRIMARY KEY AUTOINCREMENT,
timestamp DATETIME DEFAULT CURRENT_TIMESTAMP,
sensor_name TEXT NOT NULL,
sensor_id TEXT NOT NULL,
value REAL NOT NULL,
unit TEXT NOT NULL,
status TEXT, -- 'normal', 'warning', 'alert'
notes TEXT
)
''')
cursor.execute('''
CREATE TABLE IF NOT EXISTS alerts (
id INTEGER PRIMARY KEY AUTOINCREMENT,
timestamp DATETIME DEFAULT CURRENT_TIMESTAMP,
sensor_name TEXT NOT NULL,
alert_type TEXT, -- 'low', 'high', 'critical'
value REAL NOT NULL,
threshold REAL NOT NULL,
action_taken TEXT
)
''')
cursor.execute('''
CREATE INDEX IF NOT EXISTS idx_measurements_timestamp
ON measurements(timestamp)
''')
conn.commit()
conn.close()
logger.info("Database initialized")
# ============= 感應器讀取模擬 =============
def read_sensor(sensor_id, channel):
"""
從 ADS1256 讀取感應器數據
實際實現時需加載 Adafruit_ADS1x15 驅動程式
此處為簡化示意
"""
try:
# 實際程式碼應使用:
# import Adafruit_ADS1x15
# adc = Adafruit_ADS1x15.ADS1256()
# raw_value = adc.read_adc(channel, gain=1)
# 開發階段測試數據
import random
if "cold" in sensor_id:
value = 2.5 + random.uniform(-0.5, 0.5)
elif "cooking" in sensor_id:
value = 68 + random.uniform(-2, 2)
elif "warming" in sensor_id:
value = 62 + random.uniform(-1, 1)
elif "steam" in sensor_id:
value = 0.2 + random.uniform(-0.02, 0.02)
else:
value = 20
return value
except Exception as e:
logger.error(f"Failed to read sensor {sensor_id}: {e}")
return None
# ============= 警報邏輯 =============
def check_alert(sensor_id, sensor_config, value):
"""檢查是否超出警報範圍"""
alert_status = {
"has_alert": False,
"alert_type": None,
"message": ""
}
if value < sensor_config["min"] - CONFIG["alerts"]["low_temp"]:
alert_status["has_alert"] = True
alert_status["alert_type"] = "low"
alert_status["message"] = f"{sensor_config['name']}: 溫度過低 ({value}°C),低於安全範圍"
if value > sensor_config["max"] + CONFIG["alerts"]["high_temp"]:
alert_status["has_alert"] = True
alert_status["alert_type"] = "high"
alert_status["message"] = f"{sensor_config['name']}: 溫度過高 ({value}°C),超過安全範圍"
if value < sensor_config["min"] - CONFIG["alerts"]["low_temp"] - 1:
alert_status["has_alert"] = True
alert_status["alert_type"] = "critical"
alert_status["message"] = f"⚠️ 危急警報:{sensor_config['name']} 溫度嚴重異常!({value}°C)"
return alert_status
# ============= 資料儲存 =============
def save_measurement(sensor_id, sensor_name, value, unit, alert_info):
"""將測量結果儲存到資料庫"""
try:
conn = sqlite3.connect(CONFIG["db_path"])
cursor = conn.cursor()
status = "alert" if alert_info["has_alert"] else "normal"
cursor.execute('''
INSERT INTO measurements (sensor_name, sensor_id, value, unit, status, notes)
VALUES (?, ?, ?, ?, ?, ?)
''', (sensor_name, sensor_id, value, unit, status, alert_info.get("message", "")))
if alert_info["has_alert"]:
cursor.execute('''
INSERT INTO alerts (sensor_name, alert_type, value, threshold, action_taken)
VALUES (?, ?, ?, ?, ?)
''', (
sensor_name,
alert_info["alert_type"],
value,
sensor_config.get("max", 0),
"logged"
))
conn.commit()
conn.close()
except Exception as e:
logger.error(f"Failed to save measurement: {e}")
# ============= 主監控迴圈 =============
def monitor_loop():
"""主要監控迴圈,每隔 update_interval 秒采樣一次"""
init_database()
logger.info("Temperature monitoring started")
while True:
try:
timestamp = datetime.now().isoformat()
measurements = {}
for sensor_id, sensor_config in CONFIG["sensors"].items():
value = read_sensor(sensor_id, sensor_config["channel"])
if value is not None:
alert_info = check_alert(sensor_id, sensor_config, value)
save_measurement(
sensor_id,
sensor_config["name"],
value,
sensor_config["unit"],
alert_info
)
measurements[sensor_id] = {
"name": sensor_config["name"],
"value": round(value, 2),
"unit": sensor_config["unit"],
"status": "alert" if alert_info["has_alert"] else "normal",
"message": alert_info.get("message", "")
}
if alert_info["has_alert"]:
logger.warning(alert_info["message"])
# 可選:上傳到雲端 (若啟用)
if CONFIG["cloud_upload"]["enabled"]:
try:
requests.post(
CONFIG["cloud_upload"]["url"],
json=measurements,
headers={"Authorization": f"Bearer {CONFIG['cloud_upload']['api_key']}"},
timeout=5
)
except Exception as e:
logger.error(f"Cloud upload failed: {e}")
logger.debug(f"Measurements recorded: {measurements}")
except Exception as e:
logger.error(f"Monitor loop error: {e}")
time.sleep(CONFIG["update_interval"])
# ============= Web API (Flask) =============
def start_web_api():
"""啟動 Web API 伺服器,提供實時數據查詢"""
from flask import Flask, jsonify
app = Flask(__name__)
@app.route('/api/latest', methods=['GET'])
def get_latest():
"""取得最新的所有感應器數據"""
try:
conn = sqlite3.connect(CONFIG["db_path"])
cursor = conn.cursor()
cursor.execute('''
SELECT sensor_name, value, unit, status, timestamp
FROM measurements
WHERE timestamp >= datetime('now', '-5 minutes')
ORDER BY sensor_name, timestamp DESC
''')
results = {}
for row in cursor.fetchall():
sensor_name, value, unit, status, timestamp = row
if sensor_name not in results:
results[sensor_name] = {
"value": value,
"unit": unit,
"status": status,
"timestamp": timestamp
}
conn.close()
return jsonify(results)
except Exception as e:
logger.error(f"API error: {e}")
return jsonify({"error": str(e)}), 500
@app.route('/api/alerts', methods=['GET'])
def get_alerts():
"""取得今日的所有警報"""
try:
conn = sqlite3.connect(CONFIG["db_path"])
cursor = conn.cursor()
cursor.execute('''
SELECT timestamp, sensor_name, alert_type, value, threshold
FROM alerts
WHERE DATE(timestamp) = DATE('now')
ORDER BY timestamp DESC
''')
alerts = [
{
"timestamp": row[0],
"sensor": row[1],
"type": row[2],
"value": row[3],
"threshold": row[4]
}
for row in cursor.fetchall()
]
conn.close()
return jsonify({"alerts": alerts, "count": len(alerts)})
except Exception as e:
logger.error(f"API error: {e}")
return jsonify({"error": str(e)}), 500
app.run(host='0.0.0.0', port=5000, debug=False)
# ============= 主程式 =============
if __name__ == "__main__":
# 啟動監控迴圈 (主執行緒)
monitor_thread = Thread(target=monitor_loop, daemon=False)
monitor_thread.start()
# 啟動 Web API (背景執行緒)
api_thread = Thread(target=start_web_api, daemon=True)
api_thread.start()
# 保持程式運行
try:
monitor_thread.join()
except KeyboardInterrupt:
logger.info("Monitoring stopped by user")
安裝與執行步驟:
在 Raspberry Pi 上安裝 Python 3.7+ 及必要套件:
sudo apt-get update sudo apt-get install python3-pip pip3 install flask requests adafruit-ads1x15- 將上述程式碼保存為
temperature_monitor.py 設置為系統服務 (systemd),開機自動啟動:
[Unit] Description=School Kitchen Temperature Monitor After=network.target [Service] Type=simple User=pi WorkingDirectory=/home/pi/temperature-monitor ExecStart=/usr/bin/python3 temperature_monitor.py Restart=always RestartSec=10 [Install] WantedBy=multi-user.target啟動服務:
sudo systemctl start temperature-monitor sudo systemctl enable temperature-monitor- 訪問 Web 介面:
http://Raspberry-Pi-IP:5000/api/latest
10.4 前端儀表板 (HTML + JavaScript)
以下是實時顯示溫度數據的 Web 儀表板:
<!DOCTYPE html>
<html lang="zh-Hant">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>廚房溫度監控儀表板</title>
<style>
* { margin: 0; padding: 0; box-sizing: border-box; }
body {
font-family: 'Segoe UI', Tahoma, Geneva, Verdana, sans-serif;
background: linear-gradient(135deg, #667eea 0%, #764ba2 100%);
min-height: 100vh;
padding: 20px;
}
.container { max-width: 1200px; margin: 0 auto; }
h1 { color: white; margin-bottom: 30px; text-align: center; }
.dashboard-grid {
display: grid;
grid-template-columns: repeat(auto-fit, minmax(300px, 1fr));
gap: 20px;
}
.sensor-card {
background: white;
border-radius: 12px;
padding: 25px;
box-shadow: 0 8px 16px rgba(0, 0, 0, 0.1);
transition: transform 0.3s, box-shadow 0.3s;
}
.sensor-card:hover { transform: translateY(-5px); }
.sensor-card.alert {
background: #ffebee;
border-left: 4px solid #ef4444;
}
.sensor-name {
font-size: 16px;
font-weight: 600;
color: #333;
margin-bottom: 10px;
}
.sensor-value {
font-size: 36px;
font-weight: bold;
color: #667eea;
margin: 15px 0;
}
.sensor-value.alert { color: #ef4444; }
.sensor-timestamp {
font-size: 12px;
color: #999;
margin-top: 10px;
}
.status-dot {
display: inline-block;
width: 12px;
height: 12px;
border-radius: 50%;
background: #22c55e;
margin-right: 8px;
}
.status-dot.alert { background: #ef4444; }
</style>
</head>
<body>
<div class="container">
<h1>🌡️ 學校廚房溫度監控系統</h1>
<div class="dashboard-grid" id="dashboard"></div>
</div>
<script>
async function updateDashboard() {
try {
const response = await fetch('/api/latest');
const data = await response.json();
const dashboard = document.getElementById('dashboard');
dashboard.innerHTML = '';
for (const [key, value] of Object.entries(data)) {
const card = document.createElement('div');
card.className = 'sensor-card' + (value.status === 'alert' ? ' alert' : '');
card.innerHTML = `
<div class="sensor-name">
<span class="status-dot${value.status === 'alert' ? ' alert' : ''}"></span>
${key}
</div>
<div class="sensor-value${value.status === 'alert' ? ' alert' : ''}">
${value.value} ${value.unit}
</div>
<div class="sensor-timestamp">
更新:${new Date(value.timestamp).toLocaleString('zh-TW')}
</div>
`;
dashboard.appendChild(card);
}
} catch (error) {
console.error('Failed to fetch data:', error);
}
}
// 每 10 秒更新一次
updateDashboard();
setInterval(updateDashboard, 10000);
</script>
</body>
</html>10.5 定期備份與維護
建立自動備份腳本,每日將數據庫備份到外部媒體:
#!/bin/bash
# 每日備份溫度監控數據
BACKUP_DIR="/mnt/backup/temperature-monitor"
DB_PATH="/var/lib/temperature_monitor/data.db"
DATE=$(date +%Y%m%d)
mkdir -p $BACKUP_DIR
# 備份資料庫
cp $DB_PATH $BACKUP_DIR/data_${DATE}.db
# 備份日誌
tar -czf $BACKUP_DIR/logs_${DATE}.tar.gz /var/log/temperature_monitor/
# 刪除 30 天前的備份
find $BACKUP_DIR -name "data_*.db" -mtime +30 -delete
find $BACKUP_DIR -name "logs_*.tar.gz" -mtime +30 -delete
echo "Backup completed: $DATE" | mail -s "Temperature Monitor Backup" admin@school.edu透過 crontab 定時執行:
0 2 * * * /home/pi/backup.sh 2>&1 | logger -t temperature-backup
關於本文
本文由 ATLANTIS Re-IoT Solutions 撰寫,基於 15 年食品安全監控與 IoT 系統實施經驗。內容涵蓋物理原理、法規要求、實際案例、技術方案,針對台灣 319 校規模的廚房設計。所有建議均已在實際學校環境中驗證,適合校務行政人員、採購決策者、以及 IT 技術人員參考。
免責聲明: 本文提供的技術方案為參考性質,具體實施時應根據貴校設備狀況、預算、以及當地法規進行調整。如需專業協助,歡迎聯繫我們。