當產業界開始談論「AI 驅動的空調系統」，工程師最常忽略的環節不是演算法的選擇，而是數據的品質與完整性。一個再精密的機器學習模型，若建立在雜訊充斥、缺失嚴重的數據之上，其預測結果將毫無工程價值。本文作為「AI × 冷凍空調」系列的首篇，從最基礎的感測器層出發，逐步建構 AI 空調應用的數據基礎架構。

AI × 冷凍空調 系列探討
  1. 數據基礎：從感測器到機器學習模型（本篇）
  2. 故障偵測與預測性維護
  3. 冰水主機群最佳化：MPC 到深度強化學習
  4. 未來願景：數位孿生、生成式 AI 與邊緣智慧

一、感測器層：AI 空調的神經末梢

空調系統的 AI 應用始於感測器。每一個溫度探頭、壓力傳感器與流量計都是系統的「感官」，提供模型訓練與即時推論所需的原始信號。ASHRAE Handbook — Fundamentals 第 37 章對量測與儀器有完整的技術規範[1]，但在 AI 應用場景下，感測器的佈設策略需要更進一步的思考。

核心量測參數

一座典型的冰水主機系統，要建立有效的 AI 模型，至少需要以下量測點：

  • 冰水主機側：冰水供/回水溫度、冷卻水供/回水溫度、壓縮機電流/功率、冷媒壓力（高壓/低壓）、冷媒溫度
  • 水路系統：冰水流量、冷卻水流量、各分路流量、水泵頻率與功率、管路壓差
  • 空側系統：送/回風溫度、送/回風濕度、CO₂ 濃度、風車頻率與功率、過濾器壓差
  • 外氣條件：乾球溫度、相對濕度（或濕球溫度）、日射量、風速風向

感測器的精度與取樣頻率直接影響模型品質。溫度感測器需達到 ±0.1°C 的精度才能有效捕捉冰水主機的性能曲線變化；功率量測需涵蓋真實功率（kW）而非僅有電流值，否則功率因數的變動將引入系統性誤差。

取樣頻率的抉擇

傳統 BMS 的取樣週期多為 5–15 分鐘，足以應付監控與告警需求。但對 AI 模型而言，不同應用場景需要不同的取樣頻率：故障偵測需要 1–5 分鐘的數據以捕捉異常模式，設備效能預測可使用 15 分鐘數據，而長期能耗分析則可降至每小時[2]。取樣頻率越高，數據儲存與傳輸的壓力越大，工程師必須在模型需求與系統負擔之間取得平衡。

二、通訊協定：BACnet 與 MQTT 的融合

建築自動化的通訊協定是連接感測器與 AI 平台的橋樑。ASHRAE Standard 135（BACnet）[3]是建築自動化領域最廣泛採用的標準協定，定義了設備之間的數據交換格式與服務。BACnet/IP 支援乙太網路傳輸，使大量數據點的即時讀取成為可能。

然而，BACnet 的設計初衷是設備互操作性，而非大數據傳輸。當需要將數十萬筆時序數據串流至雲端 AI 平台時，MQTT（Message Queuing Telemetry Transport）以其輕量級的發布/訂閱架構，成為 IoT 與 AI 應用的主流選擇。許多現代 BMS 系統已支援 BACnet 到 MQTT 的閘道轉換，讓既有的 BACnet 設備無縫接入 AI 數據管線。

數據標準化挑戰

不同廠牌的 BMS 對同一物理量的命名、單位與數據格式各不相同。ASHRAE 的 Project Haystack 與 Brick Schema 正試圖建立統一的建築物聯網語義標準。對 AI 模型而言，數據的語義一致性至關重要——若訓練數據中的「冰水出水溫度」在不同案場分別以 °C 與 °F 記錄，模型的泛化能力將大打折扣。

三、數據品質：AI 模型的成敗關鍵

Lawrence Berkeley National Laboratory（LBNL）的研究團隊在對美國數百棟商業建築的 BMS 數據分析中發現，原始數據中普遍存在 15–30% 的品質問題[4]，包括感測器漂移、通訊斷線造成的缺失值、時間戳記錯誤、以及量測範圍外的異常值。這些問題若不妥善處理，將直接污染 ML 模型的訓練過程。

常見的數據品質問題

  • 感測器漂移（Drift）：溫度與濕度感測器隨時間偏移，在未定期校正的情況下，年漂移量可達 0.5–1.0°C
  • 卡住故障（Stuck-at Fault）：感測器輸出固定在某一數值不再變化，常見於老舊的類比式感測器
  • 缺失值（Missing Data）：通訊中斷、設備斷電或控制器重啟導致的數據空白段
  • 離群值（Outliers）：電磁干擾、接線不良或量測範圍溢位產生的異常數值

數據清洗策略

有效的數據清洗流程包括：異常值偵測（基於物理範圍與統計方法）、缺失值填補（線性插值、k-NN 或基於物理模型的填補）、感測器校驗（交叉比對冗餘感測器）。Purdue 大學 Braun 教授的研究團隊早在 2002 年就系統性地探討了 HVAC 系統的感測器故障對控制性能的影響[5]，為後續的 AI 數據品質研究奠定了基礎。

四、特徵工程：領域知識的數據化

特徵工程是將空調工程師的領域知識轉化為 ML 模型可理解的數值特徵的過程。原始感測器讀值（溫度、壓力、流量）需要經過轉換，才能有效輸入模型。這正是空調工程師在 AI 團隊中不可替代的價值所在。

關鍵衍生特徵

  • 冰水主機效能：kW/RT = 壓縮機功率 / 冷凍噸數，其中冷凍噸數由冰水流量與溫差計算
  • 冷卻水趨近溫度：冷卻水出塔溫度 − 外氣濕球溫度，反映冷卻塔的運作效率
  • 部分負載率（PLR）：當前冷凍負載 / 額定容量，是預測設備效能的核心指標
  • 時間特徵：一天中的時段、星期幾、是否為假日，捕捉空調使用的周期性模式
  • 延遲特徵（Lag Features）：加入前 1–6 個時間步的數值，讓模型理解系統的動態響應

Fan 等人（2018）的研究顯示，經過妥善特徵工程的 ML 模型，在建築能耗預測的準確度上可提升 15–25%[6]。特徵工程的品質直接決定了模型的天花板——即使使用最先進的深度學習架構，輸入低品質或不相關的特徵，模型表現仍將受限。

五、ML 方法論入門：從線性迴歸到深度學習

對空調工程師而言，ML 模型的選擇不應追求最新、最複雜的演算法，而應根據數據量、問題複雜度與可解釋性需求進行務實的選擇。

監督式學習

當有明確的輸入-輸出對應關係時（如用感測器數據預測冰水主機 kW/RT），監督式學習是最直接的選擇。線性迴歸適合關係簡單的場景，隨機森林（Random Forest）在處理非線性關係與抗離群值方面表現穩健，梯度提升樹（XGBoost/LightGBM）則在多數表格式數據的預測任務中展現頂尖性能。

非監督式學習

當缺乏標記數據時（如不知道「正常」運轉的明確定義），非監督式學習可用於發現數據中的潛在模式。主成分分析（PCA）可用於降維與異常偵測，k-means 聚類可將運轉模式分群，自編碼器（Autoencoder）則可學習正常運轉的數據分布，將偏離分布的情況標記為異常。

時間序列方法

空調數據本質上是時間序列，具有明顯的日週期與季節週期。LSTM（長短期記憶網路）與 Transformer 架構近年在時間序列預測領域取得顯著進展。新加坡國立大學 Miller 與 Nagy 教授的研究團隊利用 Building Data Genome 2 數據集，系統性地比較了各類 ML 方法在建築能耗預測上的表現[7]，為工程師的方法選擇提供了實證基礎。

六、台灣在地挑戰

在台灣推動 AI 空調應用，除了技術本身的挑戰外，還有幾個在地化的關鍵議題：

  • 既有建築的感測器不足：台灣大量既有商業建築的 BMS 佈點遠低於 AI 模型需求，感測器補設涉及配管、配線與施工協調的實務難題
  • BMS 系統封閉性：部分在地 BMS 廠商的系統不開放標準協定介接，數據取得需要客製化的閘道開發
  • 高溫高濕的數據特性：台灣全年高濕的氣候條件使得潛熱負荷佔比顯著，ML 模型必須特別處理濕度相關特徵，而非直接套用溫帶地區的模型架構
  • 工程人才斷層：同時具備空調工程與資料科學能力的跨領域人才稀缺，阻礙了技術落地的速度

ASHRAE Guideline 36[3] 所定義的高效能控制序列，雖然以規則式邏輯為主，但其對感測器配置與數據點的詳細規範，恰好為 AI 系統的數據基礎設定了最低門檻。台灣的工程團隊若能以 Guideline 36 的標準為起點，逐步擴充感測器佈點與數據基礎建設，將為後續的 AI 應用奠定堅實的地基。

結語

數據是 AI 空調應用的地基。感測器的佈設策略、通訊協定的選擇、數據品質的把關、特徵工程的設計，以及 ML 方法論的匹配——每一個環節都需要空調工程師與資料科學家的深度協作。在本系列的下一篇文章中，我們將在這個數據基礎之上，探討 AI 如何實現空調系統的故障偵測與預測性維護，讓系統自己說出哪裡不對。