2026-W32 週報：備援那條腿¶

第二份週報。本週產出 4 張卡，全部圍繞同一件事的四個問法——市電掉了之後接手的那條腿：能不能切（dc-04）、切過去有多少電（dc-05）、多快切得過去（dc-05b）、以及你憑什麼相信它還行（dc-05c）。

節奏備註：五個工作日只消耗了 4 項佇列（8/6 沒有新卡，dc-05b 的 written_at 是 8/5 但 commit 落在 8/6）。不是問題，但 dc-05 被拆成三張是計畫外的——原本佇列上它是一項。佇列的「一項」不等於「一天」，這件事下週排 dc-08 UPS 時要先想清楚，UPS 幾乎必然也要拆。

本週卡片¶

卡	標題	這張卡最關鍵的一個事實
`dc-04`	自動切換開關 ATS	ATS 是電力鏈第一個「收斂節點」——兩路上游都健康，它自己壞掉照樣全滅。而它合不合規取決於五個會被韌體更新悄悄還原的設定值，不是硬體
`dc-05`	柴油發電機 — 額定、降載與容量	規格書沒寫 rating class 就等於沒寫容量——同一顆引擎 ESP 2750 kW / COP 2100 kW，差 23.6%，還沒開始算場址降載
`dc-05b`	起動時序與暫態性能	中間那 6.5 秒是物理不是設定，而且它會隨電池老化變長——合規不是布林值，是一條會漂的曲線
`dc-05c`	NFPA 110 測試制度、30% 門檻與 wet stacking	30% 的分母是 ESP 銘牌（五個額定裡最大的、且不套降載）——選錯永遠偏小，你以為合規、實際長期輕載，而那正是 wet stacking 的成因

串起來¶

一、這四張卡不是四個節點，是一條時間軸上的四個切片¶

dc-01～dc-03b 那四張是空間上的串接：一台接一台，電從左邊流到右邊。本週不是。把它們排成拓撲圖你只會看到兩個設備（ATS 和發電機），另外兩張卡連設備都不是——dc-05b 是「ATS 與發電機之間那條時間軸」，dc-05c 是「掛在旁邊的制度層」。

真正把四張卡串起來的是 NFPA 110 Level 1 的 10 秒預算：

市電消失
  │
  ├─ T1  TDES 感測延遲          3.0 s   ← dc-04：可程式設定值
  │
  ├─ T2  起動到穩定             6.5 s   ← dc-05b：五段物理，其中 crank 會逐月漂
  │       ├ 起動繼電器閉合        0.3
  │       ├ crank 到起火          1.5    ← 電池老化 → 這段變長
  │       ├ 加速到 1800 rpm       2.5
  │       ├ AVR 建壓至 90%        1.5
  │       └ 控制器判定 ready      0.7    ← 又是一個韌體參數
  │
  ├─ T3  TDNE 穩定判定          1.0 s   ← dc-04：可程式設定值
  ├─ T3' TDN 中性停留           0.5 s   ← dc-04：開放轉換才有
  └─ T4  機構動作（死區）        0.09 s  ← dc-04：硬體
                              ─────────
                     開放轉換合計 11.09 s   ✗ 超標 1.09 s

而「這台機到底能出 2750 還是 2100 kW」（dc-05）決定了 dc-05c 月測要帶多少負載；月測是唯一能發現 T2 裡那 1.5 秒 crank 有沒有變長的手段（dc-05b 的故障域：一台停著的發電機所有讀值都正常）。

所以四張卡首尾相接成一個環，不是一條線：

dc-05  額定 2750 kW（ESP 銘牌）
   └→ dc-05c  月測門檻 = 2750 × 30% = 825 kW
        └→ 只有真的帶載跑，才量得到 dc-05b 的 crank_time
             └→ crank_time 決定 dc-04 的 10 秒預算還剩多少餘裕
                  └→ 餘裕不夠時，你只能回頭砍 dc-04 的 TDES

這個環上任何一節斷掉，你都不會收到告警——你只會在下一次真的停電時發現。

二、電力路徑上，誰在誰上游¶

市電 (dc-01) → MV (dc-03) → 變壓器 (dc-02) ─┐
                                            ├→ ATS (dc-04) → LV 主盤 (dc-07) → UPS (dc-08)
燃料 (dc-06) → 發電機 (dc-05) ──────────────┘
                    ↑
              [時間軸 dc-05b]        [制度層 dc-05c]（不在電力路徑上）

三件事值得停下來看：

（1）發電機是全鏈唯一一台「上游不是電」的設備。 它的上游是燃料 + 起動能量 + 空氣。這讓它成為唯一一台上游斷了不會馬上停、但幾小時後一定停的節點——dc-06 的儲油量因此不是庫存管理問題，是可用度參數。

（2）dc-05c 的故障域完全不在電力拓撲上。 測試不合格不讓任何東西掉電，後果落在 AHJ 稽核、保固條件，以及引擎在你不知情下逐年劣化。這是全鏈第一個「故障域不是一組設備」的項目，你的 fault_domain 模型接不住它，也不該硬接——它需要的是另一種東西（合規覆蓋查詢）。

（3）冷卻鏈這週被點名兩次，方向不同。 dc-04 說：開放轉換那 8.5 秒，IT 有 UPS 擋著無感，但 CRAH 風扇與水泵直接停 → 1 MW 機房空氣溫升約 3.5 K（只算空氣熱容的下界估計）。 dc-05b 說：就算切過去了，G3 允許電壓掉到 −15% 並花 4 秒恢復，而壓縮機低電壓保護的動作範圍與這個包絡有重疊。 兩張卡指向同一個尚未解決的問題：冷卻設備到底接在 UPS 後面還是直吃發電機。 這決定的不是舒適度，是每次切換會不會連鎖跳掉冰水主機。dc-18 之前不會有答案，但問 facility 不必等（見下面第 3 題）。

三、故障域的形狀，這週長出四種新的¶

W31 的四張卡談的是「掉了會怎樣」，故障域都是往下傳播的樹。本週四張卡各自打破一次這個假設：

卡	形狀	一句話
`dc-04`	收斂	兩個獨立故障域在此合而為一。上游再多條腿，可用度上限就是這台 ATS 的可靠度
`dc-05`	共因	N+1 三台透過共用日用油總管／並聯盤／進排氣井／電池充電器偷偷變回 N。瓶頸幾乎不在引擎本體，起動電池排第一
`dc-05b`	延遲引爆	起動失敗不讓任何東西「立刻」掉——UPS 正撐著。故障與後果不同時發生，最壞 78 秒後才有人知道
`dc-05c`	不在拓撲上	後果是稽核、保固與看不見的劣化。合規文件本身會掩蓋物理劣化

W31 的結論是「故障域不是只會分岔，也會匯流」；本週把它推得更遠：故障域不一定是一組設備，也不一定和後果同時發生。 topic-06 那張卡真正要建模的是這四種形狀，不是一棵樹。

四、同一個誤解，兩次代價，方向相反¶

本週最該記住的一句話，來自 dc-05 與 dc-05c 的接縫：

ESP 2750 kW  vs  COP 2100 kW   →  差 650 kW = 23.6%

在容量規劃上用錯（拿 ESP 當可用容量）  →  高估 23.6%，真停電時電不夠
在測試合規上用錯（拿 COP 當分母）      →  少載 23.6%，長期輕載 → wet stacking

同一個數字、同一個誤解，一次讓你高估、一次讓你少載，兩次都往危險的方向走，而且兩次的錯誤都會被文件掩護：報價單寫「2750 kW」看起來很清楚，測試報告寫「合規」看起來很安心。

順帶一提 dc-05c 那個 5.7 倍的落差也是同一種病：月測不合規時直覺去租 265 kW 的 load bank，但月測不合規觸發的是年度補充測試，而年度測試最高段是 75%，規格由它決定 → 實際要 1502.5 kW。看到的數字和該用的數字不是同一個。

五、母題換檔了¶

W31 的四張卡是同一個母題：單一欄位無法承載一個事實（數字要帶著量測條件）。本週前三張仍然是它的延伸——

卡	這個值不能脫離什麼	第幾種變形
`dc-04`	設定值不能脫離時間與變更者（韌體更新會還原它）	第四種
`dc-05`	額定不能脫離用途分級與場址條件	第五種
`dc-05b`	當前值根本不存在，意義只在歷史序列裡	第六種

但 dc-05c 換了一個母題，而且是更難的那個：

事實與規則之間不是一對一。

§8.4.9.6 允許一次 36 月測試同時算作月測與年度測試——一筆事實可以是三條規則的證據。這不是「欄位需要更多脈絡」，這是規則本身必須被實體化成資料列（requirement 表 + requirement_satisfaction 中介表），不能寫死在 test_type enum 或 if 分支裡。合規查詢因此從「查最近一筆記錄」變成「過去 12 個月每條要求有沒有被至少一個事件覆蓋」的覆蓋問題。

再加上 §8.4.3 的 ATS 輪替要求——「這台發電機月測合規」是沒有意義的斷言，正確的是「(genset, ats) 這組邊在過去 N 個月被驗證過」。全鏈第一個掛在圖的邊上而非頂點上的約束。

自我測驗¶

Q1（事實回憶）. 維護商回報「本月測試帶 700 kW 跑了 45 分鐘，合規」。這台是 ESP 2750 / COP 2100 / 場址額定 2393 kW。門檻應該是多少？他最可能拿了哪個數字當分母？

答案

門檻是 ESP 銘牌 2750 × 30% = 825 kW。§8.4.2 原文兩個修飾詞都關鍵：standby（就是 ESP，五個額定裡最大的）、nameplate（不套場址降載）。700 kW 只有 25.5%，不合規。

三個可能的錯誤分母，注意誤差方向永遠偏小：

正解  ESP 銘牌   2750 × 30% = 825 kW
誤用  COP        2100 × 30% = 630 kW  → 700 就「過了」← 最可能是這個
誤用  場址額定    2393 × 30% = 718 kW  → 700 仍差一點

跑 45 分鐘不能補償負載不足——時間與負載是 AND 不是 OR。

第二層追問：若 700 kW 已達廠商建議最低排氣溫度，走路徑 B（排氣溫度法）一樣合規。所以正確的問法是「走哪條路徑？量到幾度？原廠要求幾度？記錄在哪？」——沒有排氣溫度記錄就只剩路徑 A，那就是不合規。

第三層：不合規的後果不是罰款，是觸發年度補充 load bank 測試義務（見 Q3）。

Q2（事實回憶）. 發電機三次 crank 都沒起來，控制器進 overcrank lockout。從 ATS 送出起動訊號到那一刻過了多久？為什麼說 overcrank 這個告警本身設計就是錯的？

答案

TDES 3.0 s + cycle crank 75 s（3×15 s crank + 2×15 s rest）≈ **78 s**。期間 ATS 不會切，全靠 UPS 撐——典型雙轉換 UPS 滿載後備 5–15 分鐘，撐得住。問題從來不是撐不撐得住，是這 78 秒有沒有人知道。

overcrank 告警錯在它是 75 秒之後才響的事後通知。真正的分界線在更前面：

第一次 crank 的 15 秒上限，本身就已經超過 Type 10 的整個 10 秒預算。

所以只要進到第二次嘗試，這次起動在合規上必然已經失敗——即使機組最後成功起動、即使 overcrank 從未觸發。該告警的是 crank_attempt_count > 1，而傳統 BMS 通常完全看不到這種「合規上失敗、技術上成功」的起動。

Q3（應用）. 機房 IT 400 kW、PUE 1.4，這台 ESP 2750 kW 的機。年度補充測試（50% × 30 min + 75% × 60 min）要燒掉多少柴油？佔 Class 48 儲油量的幾成？

答案

先確認為什麼一定要做這個測試：發電機側 = 400 × 1.4 = 560 kW = 銘牌 20.4% < 30%，月測路徑 A 過不了 → 每年觸發補充測試義務。

50% 段：2750 × 0.50 = 1375 kW × 0.5 h =   687.5 kWh × 0.298 L/kWh = 204.9 L
75% 段：2750 × 0.75 = 2062.5 kW × 1.0 h = 2062.5 kWh × 0.2814 L/kWh = 580.4 L
                                                        合計 ≈ 785 L
Class 48 儲油（ESP 機帶 70% = 1925 kW）：
    1925 × 0.267 × 48 = 24,671 L
785 ÷ 24,671 = 3.2%；吃掉年度配額 1.5 h ÷ 200 h = 0.75%

兩個容易踩的點：

SFC 要隨負載率變——50% 用 0.298、75% 用 0.2814，低負載每度電更耗油。用一個固定的 0.267 會低估。
load bank 是電阻負載，電是機組自己發的，所以油照燒。而 load bank 規格要抓 max(265, 815, 1502.5) = 1502.5 kW，不是 30% 那段的 265 kW——差 5.7 倍。1.5 MW 電阻式 load bank 就是一台 1.5 MW 電暖器，排熱與擺放才是真瓶頸。

對你的模型：燃料消耗必須是 output_kw 時序的積分（每段用該負載率的 SFC），不是 hours × 固定係數。這也是 dc-06 儲油量計算唯一正確的輸入形狀。

Q4（應用）. 把 TDES 從 3.0 砍到 1.5，總時序回到合規。crank_time 現在 1.5 s，每月漂 +0.05 s。還剩幾個月會失去 Type 10 合規？dc-05b 的驗收表說 ≈10 個月，但你老實從 dc-04 的 Timers 算，會得到不一樣的答案。差在哪？

答案

老實算（dc-04 預設 transition_type="open"，TDN = 0.5）：

固定開銷 = TDES 1.5 + (T2 扣掉 crank：0.3+2.5+1.5+0.7 = 5.0) + TDNE 1.0 + TDN 0.5 + 機構 0.09
         = 8.09 s
crank 預算 = 10 − 8.09 = 1.91 s
剩餘月數 = (1.91 − 1.5) ÷ 0.05 = **8.2 個月**

dc-05b 驗收表用的 fixed_overhead_s = 8.0 是手算的整數，隱含把 TDN 忽略掉了（8.0 → 預算 2.0 → 10.0 個月）。差 1.8 個月，來自一個沒人負責維護的常數。

更誇張的是換成閉合轉換（TDN = 0）：

固定開銷 = 7.59 → crank 預算 2.41 → **18.2 個月**

同一台機、同一個漂移速率，transition_type 這一個欄位讓「合規剩餘壽命」差兩倍以上（8.2 vs 18.2 個月），而它在 dc-04 的骨架裡只是一個預設值字串 "open"。

對你的模型：fixed_overhead_s 絕對不能是傳進去的參數，必須是 TransferSwitch 從自己的 Timers + transition_type + StartEvent 的分段時戳算出來的。手寫常數在這裡的代價是「還有多久失去合規」直接錯 20%–120%。詳見下面連貫性檢視的第 1 點。

Q5（建模判斷）. 本週出現了三種「W31 那套欄位型別裝不下」的資料。分別是什麼？schema 上各需要什麼機制？

答案

W31 的六格與那批欄位都在回答同一種問題：「這個東西現在是什麼」。本週三次撞牆：

（1）存量（dc-05：runtime_hours_ytd） ESP 只給 200 h/年。這是全鏈第一個用掉就沒了的欄位——kVA、kA、開關位置、計時器設定都是「當下是什麼」，可覆寫可重讀；運轉小時是「已經消耗多少」，只增不減、跨年度重置。機制：quota_hours（由 rating_class 決定）+ 按 trigger 分組累計（TEST_MONTHLY / TEST_ANNUAL_SUP / TEST_36M / OUTAGE / COMMISSIONING / WET_STACK_CURE）。分組是必要而非優化——EPA 的非緊急運轉時數是第二套獨立配額。告警語意是「還剩多少、燒得多快」。

（2）趨勢量（dc-05b：crank_time） 單筆讀值幾乎沒有意義（今天 1.8 秒是好是壞？不知道），只有序列有意義。機制：start_event 事件表存時間戳，所有秒數 derived（NFPA 7.13.4.1.4 本身就要求分段記錄）。告警不是「超過門檻」，是「斜率為正且外推會超過門檻」——監控系統要能對它做迴歸，不只是比大小。

（3）多對多的覆蓋（dc-05c：test_event ↔ requirement） §8.4.9.6 允許一次測試同時滿足三條要求。機制：test_event 不能有 test_type enum，改用 requirement_satisfaction(test_event_id, requirement_id, verdict) 中介表。規則必須是資料列，不是 enum 值或 if 分支。 合規查詢是覆蓋問題，不是查最近一筆。

加碼（4）邊上的約束：§8.4.3 的 ATS 輪替讓合規對象變成 (genset, ats) 配對。「這台發電機合規」是沒有意義的斷言。全鏈第一個掛在圖的邊而非頂點上的約束，你現在的 DeviceRegistry 設計（節點字典 + upstream_id）沒有地方掛它——邊還沒有身分。

一句話總結本週的建模躍遷：W31 教你「一個欄位裝不下一個事實」，W32 教你「有些事實根本不住在欄位裡」——它們住在序列、存量、以及事實與規則之間的多對多關係裡。

間隔複習¶

正式排程：尚無。

本軌跡起始於 2026-07-28。兩週前（W30）與四週前（W28）都還沒有卡片，與 W31 週報公告的排程表一致：

週次	抽兩週前	抽四週前
W32（本週）	尚無	尚無
W33	W31 的卡（dc-01 ~ dc-03b）	尚無
W34	W32 的卡（dc-04 ~ dc-05c）	尚無
W35	W33	W31 的卡

不過本週不讓這一段空著——加一題提前補考（不佔用 W33 的正式抽卡，W33/W35 照原排程跑）。挑它的理由是：W31 的一個結論在本週原封不動地重演了一次，只是換了設備。

補考題（W31 dc-01 × 本週 dc-05）. 「我們有兩路市電進線」和「我們有三台 N+1 發電機」——這兩句話為什麼是同一個錯誤？你的 schema 用同一個機制擋得住嗎？

答案

兩句話都在用數量冒充獨立性。

dc-01：兩路 feed 若來自同一座變電所，只防饋線故障、不防變電所故障。缺 substation_id / feeder_id，你的冗餘報表會把假冗餘顯示成綠燈。
dc-05：三台機若共用一條日用油總管、一面並聯盤、一個進排氣井、一組電池充電器，任一失效同時帶走三台。「三台機」不等於 N+1，要看它們共用什麼——而瓶頸幾乎都在附屬系統而非引擎本體，起動電池排第一。

同一個機制擋得住嗎？可以，但你現在的模型還沒有它。 兩者需要的都是「共用依賴」這條邊，而不是父子樹：

shared_dependency(component_id, dependency_id, dependency_type)
  dependency_type ∈ {substation, feeder, fuel_header,
                     paralleling_switchgear, air_intake_plenum,
                     battery_charger, ...}

有了它，「N 台設備的實際冗餘度」才是查得出來的：沿 shared_dependency 分群，群數才是真正的獨立來源數，count(devices) 從來不是。

這也回答了 W31 第 5 題留下的伏筆：冗餘判定不能是單一 boolean，必須是跨層 AND；本週補上的是——其中一層永遠是「它們共用什麼」，而那一層在拓撲圖上看不見。

本週的 model code 連貫性檢視¶

W31 列的五處漂移中，第 2、3 點（邊存兩端、id 參照 vs 物件內含）到現在還沒收斂，而本週四張卡的骨架已經在為此付出代價。新增七處，前三處會產生錯誤數字：

🔴 1. `fixed_overhead_s` 是手算常數，且兩張卡的公式對不起來¶

dc-04 定義開放轉換 = TDES + crank + TDNE + TDN + mech/1000（預設 11.09 s）。 dc-05b 正文寫「接回 dc-04 的總時序：3.0 + 6.5 + 1.0 + 0.09 = 10.59」——那是 dc-04 的閉合轉換公式（dc-04 驗收表明寫閉合 = 10.59、開放 = 11.09）。接著 dc-05b 的 months_until_noncompliant 又用了一個手寫的 fixed_overhead_s = 8.0。

三個地方對同一件事有三種算法，結果就是 Q4 那個 8.2 vs 10 vs 18.2 個月的差距。

收斂建議：TransferSwitch 加一個 fixed_overhead_s(start_event) method，從自己的 Timers + transition_type + StartEvent 的分段時戳算出來；StartHistory.months_until_noncompliant() 改吃 TransferSwitch 物件，不吃裸 float。現在不修，dc-08 UPS 進來時會有第四種算法。

🔴 2. `genset_crank_to_stable_s` 同時存在兩處，一處是常數一處是實測¶

dc-04 的 TransferSwitch.genset_crank_to_stable_s = 6.5 是硬編碼欄位；dc-05b 明講「它不該是一個欄位」並改用 StartEvent 的五個時戳 derive。但 dc-04 的骨架沒有回頭改，兩份資料會各自漂。

收斂建議：TransferSwitch 刪掉這個欄位。時序計算改成 total_transfer_time_s(crank_to_stable_s: float)，由呼叫端從 StartHistory 取最近一次實測（或 commissioning 基線）傳入。dc-04 驗收表的 11.09 仍然成立，只是 6.5 從「內建假設」變成「有來源的輸入」——這正是 dc-04 自己在講的那件事。

🔴 3. `ComplianceEngine.esp_nameplate_kw` 自己存了一份分母¶

dc-05 已經有 Genset.ratings[ESP].power_kw = 2750，dc-05c 又在 ComplianceEngine 上存 esp_nameplate_kw。註解寫著「唯一合法的分母」，但它是第二份副本。

收斂建議：ComplianceEngine 持有 genset: Genset（或 registry 裡的 id），threshold_kw() 從 genset.rating(RatingClass.ESP).power_kw * 0.30 讀。換機、修正銘牌、或有人把場址額定誤填進去時，兩邊才不會漂。這是本週最可能造成「合規報表說 OK 但分母是舊的」的漏洞——而 dc-05c 整張卡的論點就是這個分母。

🟡 4. `TransferSwitch` 沒有任何拓撲欄位（W31 第 2、3 點的帳單到了）¶

dc-04 的「對資料模型的意涵」第 1 點要求 candidate_sources（集合）+ active_source（當下）+ source_history（時間軸）三件套，但骨架只有 active_source。結果是：TransferSwitch 目前是一個浮在圖外的節點——沒有 upstream_ids，也沒有東西指向 Genset；Genset 也沒有 downstream_ats_id。

更明顯的訊號是：dc-05c 的 TestEvent.initiating_ats_id 是整套模型裡第一個真的指向 ATS 的欄位，而它是個裸字串，沒有任何東西保證那個 id 存在。

收斂建議：W31 建議的 DeviceRegistry（dict[str, Node]）這週一定要補，並讓 TransferSwitch.candidate_sources: list[str] 走 registry 驗證。ats_rotation_gaps() 那個查詢本來就需要 registry 才寫得出來。

🟡 5. `runtime_quota_status()` 的簽章接不上 `annual_runtime_hours()`¶

dc-05c 驗收表最後明寫「接回 dc-05 的 runtime_quota_status()」，但：

dc-05：runtime_quota_status(rc, hours_ytd: float) — 吃一個純量
dc-05 自己的「對資料模型的意涵」第 3 點：必須按 trigger 分組累計
dc-05c：annual_runtime_hours() 回 8.83 / 8.17，那只是測試時數，不含真實停電與 commissioning

這是本週唯一一個「驗收標準本身就接不上」的地方。

收斂建議：改成 runtime_quota_status(rc, hours_by_trigger: dict[Trigger, float])，內部加總並分開報「測試佔配額 %」與「非計畫佔配額 %」。EPA 的非緊急時數是第二套配額，沒有分組就算不出來。

🟡 6. 時間單位命名漂移，最危險的是 `Timers`¶

本週四張卡混用了 _s / _ms / _min / _minutes / _hours：

dc-04 : mech_transfer_ms（ms）、genset_crank_to_stable_s（s）
        Timers.TDES / TDNE / TDN / TDEN / TDEC  ← 五個欄位全部沒有單位後綴
dc-05 : max_hours_per_year
dc-05b: crank_time_s、worst_case_ups_hold_s
dc-05c: COOLDOWN_MIN、loaded_minutes_at_or_above()、engine_minutes()、annual_runtime_hours()

Timers 是最危險的一個：TDEN = 300.0 到底是 300 秒還是 300 分鐘？只有註解說是秒。而 TDEN 的正常設定值範圍恰好是「5–30 分鐘」——這是一個註解掉了就會錯 60 倍的欄位。

收斂建議：一律加單位後綴（tdes_s、tden_s…），或整組換成 timedelta。趁只有五個欄位時改，dc-08 UPS 的 runtime 進來後會更亂。

🟡 7. 「值不能脫離量測點」已經各自發明了三套形狀¶

dc-04 : transfer_time_ms + measurement_point + source + measured_at
dc-05 : SiteConditions.temp_point: TempPoint
dc-05c: exhaust_temp_c / min_exhaust_temp_ref_c   ← 完全沒有 measurement point

三張卡都在講同一件事，但每張各自發明一套；而 dc-05c 那組排氣溫度根本沒帶量測點，儘管它是路徑 B 的唯一證據。

收斂建議：把 W31 第 5 題答案裡的「值物件而非裸量」真的實作出來——

@dataclass(frozen=True)
class Measured:
    value: float
    unit: str
    point: str          # air_filter_inlet / ats_output / exhaust_stack / ...
    source: str         # nameplate / factory_test / field_measured
    at: datetime | None = None

本週是這個構想第一次有三個獨立實例可以驗證。三次都自己寫一遍，第四次（dc-08 UPS runtime 綁放電率）還是會再寫一遍。

優先序：1–3 先修（會產生錯誤數字，且 1 和 3 直接影響「我們合不合規」的答案）。4 必須在 dc-07／dc-08 之前——那兩張會把節點數翻倍。5–7 可以併到 dc-06 那天一起做。

本週該問 facility 的問題¶

四張卡共提出 13 個問題，去重後選 3 個下週真的拿去問人的。挑選標準與 W31 相同：「現在問還來得及改，晚問就固化了」。本週多一個更急的理由——Q3 那組數字只有在 commissioning 當下才拿得到，事後永遠補不回來。

Q1 — 問機電設計單位 / 發電機供應商¶

「發電機是照哪個 rating class 採購的——ESP、PRP 還是 DCC？若寫 DCC，是貴司自訂還是 ISO 8528-1:2018 的 DCP，定義一樣嗎？場址額定是用拇指法則還是原廠降載表算的？拿得到 Table A 嗎？計算用的溫度是室外還是發電機房進氣（air filter inlet）？機房通風的設計溫升是多少？另外，三台機共用什麼——日用油是一條總管分三支還是各自獨立？並聯盤一面還是兩面？進排氣井與電池充電器呢？」

為什麼是這題：一次拿到三個決定性的模型欄位，而且三個都是採購當下固化、事後改不了的。

rating class：規格書沒寫它就等於沒寫容量（ESP 2750 vs COP 2100，差 23.6%），而且它同時決定 dc-05c 月測的分母與年度運轉時數配額。
溫度量測點：原廠 Table A 的橫軸是 air filter inlet temperature 不是室外溫度。機房通風不良時進氣可比室外高 10 °C 以上——你可能是自己的機房通風把自己的發電機降載了，而型錄與氣象站都不會告訴你。兩種算法差 123 kW ≈ 4.5 個百分點。
共用什麼：這是上面補考題的答案落地。三台 N+1 的實際冗餘度，取決於它們不共用什麼，而這件事在拓撲圖上看不見。

Q2 — 問維運 / 發電機維護商¶

「月測走 30% 負載還是排氣溫度路徑？走溫度的話——原廠手冊的最低排氣溫度是幾度、量測點在哪、誰負責記錄？走負載的話——請調最近三次月測記錄，我要對分母是哪個 kW。另外 §8.4.3 要求逐月輪替起動的 ATS，這件事現在有在做嗎、記在哪？年度補充 load bank 測試：租還是常設、多大、排熱擺哪、預算編了嗎？」

為什麼是這題：這題直接檢驗「合規文件會不會在掩護物理劣化」——全鏈唯一一個文件說 OK 但引擎在劣化的地方。三個具體的踩點：

分母選錯永遠偏小（ESP 是最大額定、銘牌又大於場址值），所以錯的方向一定是「你以為合規、實際長期輕載」，而長期輕載正是 wet stacking 的成因，且它會正回饋（碳煙堵噴油嘴 → 霧化更差 → 更燒不完全）。
「原廠最低排氣溫度」這個數字只存在於原廠手冊。資料庫裡沒有它，路徑 B 在制度上就不存在——合規能力被欄位存在性決定。
爬坡期（IT 400 kW / PUE 1.4 → 銘牌 20.4%）幾乎必然要租 load bank，而規格是 1502.5 kW 不是 265 kW，差 5.7 倍。這是預算題，晚問就來不及編。

順帶問一句：NFPA 110 對我們是法令還是合約？誰是 AHJ？租戶合約有沒有直接引用條文編號？ 台灣的法定依據是消防／電業法規與 CNS 體系，兩者不自動等同。

Q3 — 問控制系統承包商 / 電驛設定承包商（⚠️ 時效最急）¶

「ATS 五個計時器（TDES / TDNE / TDN / TDEN / TDEC）目前實際設定值各是多少？有變更紀錄嗎？韌體更新後有沒有重新確認過？ commissioning 驗收時，請依 NFPA 110 §7.13.4.1.4 分開記錄四段：起動延時、crank time、達額定轉速時間、以及所有開關轉到 emergency 位置達穩態的時間——不要只給一個總秒數。還有：冰水主機、冷卻水泵、CRAH 接在 UPS 後面還是直接吃發電機？它們的低電壓保護設定多少伏、延時多久？」

為什麼是這題，而且為什麼最急：

五個計時器：合規與否幾乎全由它們決定（硬體 T2 + T4 最壞才 6.6 s，剩下 3.4 s 全是人設的），而韌體更新會把它們悄悄還原成原廠預設，原廠預設可能讓你從合規變違規（3.0 + 6.5 + 1.0 + 0.09 = 10.59 s > 10 s）。沒有變更歷史，你連「什麼時候開始不合規的」都答不出來。
分段記錄：那四個數字是 genset_crank_to_stable_s 的真值來源，也是日後判斷「crank 有沒有變慢」的唯一基線。commissioning 只發生一次，事後永遠補不回來——這是本週三題裡唯一有硬期限的。
冷卻設備接哪裡：dc-04 的 8.5 秒死區與 dc-05b 的 G3 包絡（電壓 −15%、恢復 4 秒）都打在同一組設備上，而壓縮機低電壓保護的動作範圍與這個包絡有重疊。「G3 合規」不等於「切換時冷卻不會跳」——必須拿實際的保護電驛設定去對，不能推論。

這週沒選上、但別忘記的¶

ATS 是 PC 級還是 CB 級、依 UL 1008 還是 IEC 60947-6-1 標示？WCR／Icw 綁的上游保護裝置型號是哪一顆？（上游斷路器一換，這筆評等就該標記為 stale。）
單台 ATS 還是雙路徑？是不是旁路隔離型（維護時能不能不斷電）？—— 這題和 Q1 的「三台機共用什麼」是同一個問題的兩端。
規格書寫了 G3 的同時，有沒有另外寫自訂的單步加載百分比？若有，依 ISO 8528-5 的判定邏輯那已經是 G4，須雙方另行議定——那份規格書自我矛盾。
wet stacking 治療：若有長期輕載或無近期帶載記錄，治療（75% 銘牌連續 3 h）的排氣溫度高於柴油自燃點，排氣系統內起火雖罕見但確有發生，必須交專業維護商。

下週¶

佇列下一張：dc-06 日用油箱與儲油槽——接住本週兩個數字：dc-05 的 13.4 m³（1500 kW 機 Class 48）與 dc-05c 的 24,671 L（2750 kW 機 Class 48）。它也是上面連貫性檢視第 5 點最好的落地場合：儲油量必須是 output_kw 時序的積分，不是 hours × 固定係數。
連貫性檢視的 1–3 點請在寫 dc-06 之前修完——三個都會產生錯誤數字，而 dc-06 的所有計算都要吃它們的輸出。第 4 點（DeviceRegistry）必須趕在 dc-07／dc-08 之前，那兩張會把節點數翻倍。
排程提醒：dc-05 一項拆成三張卡，佇列的 64 項實際會膨脹。下週排 dc-08 UPS 時先決定要不要主動拆（雙轉換架構／旁路與維護模式／電池另有 dc-09），不要又在寫到一半時發現超字數。
⚠️ commissioning 隨時可能開始。一旦開始就中斷佇列，全部時間投進去。本週的 Q3 已經把該在現場拿到的表單列出來了——整廠斷電測試、發電機帶載測試、ATS 切換時序，一次性且不可重現。