未分類
看懂 BAS 十大失敗模式
依據：本 wiki 的 ASHRAE Guideline 13-2024 教學教案第 2 章「痛點總覽」與第 9.3 節「常見爭議與裁處建議」。BAS 指建築自動化系統（Building Automation System）。
先講結論
十大失敗模式表面上是十個不相干的問題，但有一個共同結構：問題通常在前期（需求、設計、合約）被埋下，卻在後期（測試、驗收、營運）才被看見。等到症狀出現，成因早已寫進文件、簽進合約或裝進現場，修正會牽動更多人和更多工作。所以教案給的 GL13 對策，幾乎都是「在前期把要求寫清楚、在測試時逐項證明」。
讀這份表時，可以對每一項問三件事：
本頁整理「埋下點」和「爆發點」是本頁依症狀與對策條文推論的閱讀框架，教案原表只列出痛點、症狀、GL13 對策與個案警示，沒有標示發生階段。
時間差地圖：問題在哪一步埋下、在哪一步爆發
橫軸沿用 GL13 圖 7-1 的九步建置流程（①需求取得 → ⑨完工保固），最右一欄是保固後的日常營運。每一列是一種失敗模式：橘點是埋下點，紅點是症狀出現的位置，箭頭表示「從埋下到爆發」的時間差，不表示中間每一步都有人做錯。矩陣之後列有十項的詳細說明，點選各項標題即可展開。
從圖上可以看到：十項中有五項（#5～#9）要到營運階段才爆發；另有三項（#1、#3、#10）在測試、驗收或完工時才顯現；只有 #2、#4 在施工期間浮現，而 #2 在個案中到營運時還造成連鎖誤動作。在這張整理圖中，沒有一項會在埋下的同一個環節就被看見。這說明了為什麼教案把對策放在「寫進文件」和「逐項驗證」，而不是等出事再處理。
#1 需求未量化
時間差：埋在 ①需求，症狀出現在 ⑧測試 本頁整理
延伸閱讀：wiki 概念頁「OPR 業主專案需求」。「為什麼前面看不出來」與「最早可以在哪裡攔住」是本頁依相關概念頁整理的說明。
#2 SOO 雙頭馬車
時間差：埋在 ③設計，症狀出現在 ⑤送審，個案中到 營運 才出現更嚴重後果 本頁整理
延伸閱讀：wiki 概念頁「SOO 控制序列」。「為什麼前面看不出來」與「最早可以在哪裡攔住」是本頁依相關概念頁整理的說明。
#3 點對點驗證偷工
時間差：都在第 ⑧ 步：埋在點對點驗證（L2），爆發在功能測試（L4） 本頁整理
延伸閱讀：wiki 概念頁「點對點驗證」。「為什麼前面看不出來」與「最早可以在哪裡攔住」是本頁依相關概念頁整理的說明。
#4 網路責任分界模糊
時間差：埋在 ②概念，症狀出現在 ⑦安裝 本頁整理
延伸閱讀：wiki 概念頁「通訊基礎設施三選項」。「為什麼前面看不出來」與「最早可以在哪裡攔住」是本頁依相關概念頁整理的說明。
#5 點數爆炸
時間差：埋在 ②概念，症狀出現在 營運 本頁整理
延伸閱讀：wiki 概念頁「點清單管理策略」。「為什麼前面看不出來」與「最早可以在哪裡攔住」是本頁依相關概念頁整理的說明。
#6 硬體連鎖被軟體取代
時間差：埋在 ③設計，症狀出現在 營運 本頁整理
延伸閱讀：wiki 概念頁「硬體連鎖」。「為什麼前面看不出來」與「最早可以在哪裡攔住」是本頁依相關概念頁整理的說明。
#7 感測器精度不足
時間差：埋在 ③設計，症狀出現在 營運 本頁整理
延伸閱讀：wiki 概念頁「感測器精度分級」。「為什麼前面看不出來」與「最早可以在哪裡攔住」是本頁依相關概念頁整理的說明。
#8 資安後門
時間差：埋在 ⑦安裝，症狀出現在 營運 本頁整理
延伸閱讀：wiki 概念頁「BAS 資通安全」。「為什麼前面看不出來」與「最早可以在哪裡攔住」是本頁依相關概念頁整理的說明。
#9 訓練不足
時間差：埋在 ⑦安裝，症狀出現在 營運 本頁整理
延伸閱讀：wiki 概念頁「演示驗收與訓練」。「為什麼前面看不出來」與「最早可以在哪裡攔住」是本頁依相關概念頁整理的說明。
#10 資料所有權未約定
時間差：埋在 ④招標，症狀出現在 ⑨完工 本頁整理
延伸閱讀：wiki 概念頁「專有資料所有權」。「為什麼前面看不出來」與「最早可以在哪裡攔住」是本頁依相關概念頁整理的說明。
GL13 對策的三種手法
十項對策看起來各引不同條文，但手法只有三種。這樣分組有助於記憶：遇到新問題時，可以先問「它缺的是哪一種」。本頁分類
| 手法 | 做法 | 對應的失敗模式 |
|---|---|---|
| 把要求寫成可驗收的條文 | 需求量化、精度分級、資安選項、資料所有權寫進 OPR 或規格 | #1 需求未量化、#7 感測器精度不足、#8 資安後門、#10 資料所有權未約定 |
| 讓每件事只有一個來源、一個負責人 | SOO 只放一處；責任矩陣劃清 IT 與 BAS 商；點清單有管理策略 | #2 SOO 雙頭馬車、#4 網路責任分界模糊、#5 點數爆炸 |
| 用設計與測試把關，不靠信任 | 點對點 100% 全檢；安全功能用硬體連鎖；訓練與複訓寫進要求 | #3 點對點驗證偷工、#6 硬體連鎖被軟體取代、#9 訓練不足 |
出事以後：教案建議怎麼裁處爭議
失敗模式在建置後期爆發時，常演變成業主、承包商、設計師之間的爭議。教案第 9.3 節列了四種常見爭議，各自對應到上面的失敗模式。
四項裁處有同一個邏輯：文件寫不清楚時，回到 GL13 條文與業主利益；能舉證才算完成。這也反過來說明，前期把條文寫清楚，比事後裁處便宜得多。
為什麼 #3 和 #9 容易被犧牲
教案第 3.1 節估算了典型 BAS 專案的成本結構，其中「測試／試運轉／訓練」約占 8–12%，教案特別註明這一項「最常被砍、也最不能砍」。點對點全檢（#3）和訓練（#9）都在這一塊，因此預算壓力來時首當其衝。
教學用概估占比是教案提供的教學概估，長條寬度取各區間中位數示意，加總不一定剛好 100%，不代表任何特定專案。
自我檢查：三個問題
1. 它怎樣運作？為什麼「需求未量化」會到驗收才出問題？
設計和施工時，模糊的需求（例如「要節能」）不會阻擋任何人往下做；只有到驗收時，雙方要判定「做到了沒有」，才發現沒有可比較的數字。教案的個案是：算力中心的 PUE 目標沒有寫進 OPR。對策是在第 ① 步用 OPR 訪談十問把需求量化。
2. 證據支持到哪裡？感測器誤差真的會影響 PUE 判讀嗎？
教案的個案警示寫：PUE 用電表誤差 2% 時，PUE 會漂移 0.03 以上。這是教案提供的個案數字，適用條件（PUE 基準值、誤差方向）材料沒有展開，不宜直接套用到其他專案；但它說明了「精度不足時，效能監控的結論可能落在誤差範圍內」這個方向。
3. 什麼情況下不能這樣理解？十大失敗模式涵蓋所有 BAS 風險嗎？
不能。這是教案依兩個個案（AI 算力中心、高防護實驗室）與 GL13 條文整理出的常見問題，不是 GL13 原文的正式清單，也沒有統計排序。教案自己就另外提到一個未列入十大的痛點：業主以為「裝了 BAS 就會省電」，結果主機容量不足、風管洩漏，BAS 反而成為代罪羔羊。另外，本頁的「埋下點／爆發點」是閱讀框架，實際專案的發生時點可能不同。
