2026-W42 週報：裸值不是事實¶
第十二份週報（W31 起算第十二週）。本週 5 張卡、5 個工作日全齊（10-12 ~ 10-16），是 W39 之後第一次滿週。內容上跨過一條界線：dc-37 收掉第三輪（空間、消防、安全），dc-38 起進入第四輪：系統與協定。前三輪的卡片都在談「設備」；這一週談的是設備說話的方式。
母題只有一句：一個裸數字不是事實，它要帶著「多不確定、多新、誰的時鐘、誰登記的、怎麼解碼」才是事實。 五張卡各幫同一個數字加上一個限定語。
本週卡片¶
| 卡 | 標題 | 這張卡最關鍵的一個事實 |
|---|---|---|
dc-37 |
溫濕度感測器佈點策略 | 感測器量的是進風口的「代理」，讀值是區間不是點。 24 °C／60% RH 的露點 15.75 °C 超過建議上限 15 °C（RH 數字上合規）；±0.5 °C／±5%RH 下區間 [13.94, 17.49] 橫跨限值 → 判定是 IN／OUT／UNCERTAIN 三態 |
dc-38 |
BMS 樓宇管理系統 | 畫面上有值不等於有人在看；同一句「BMS 掛了」，依 standalone 一個欄位可以是無事，也可以是冰水機失控。 值的可信度是 value × quality × age，不是 value |
dc-39 |
EPMS 電力監控系統 | 事件順序是三態：兩個時間戳只有在 |Δt| 大於兩端（時鐘誤差＋解析度）之和時才能排先後。 PTP–PTP 門檻 2.2 ms、PTP–NTP 3.1、NTP–NTP 4.0；對時失聯（假設 20 ppm）203 s 後誤差就超過 60 Hz 的四分之一週期 4.17 ms |
dc-40 |
DCIM 的範疇與市場現況 | DCIM 的產品是「被維護的資產記錄」，容量取最先見底的維度，準確度隨登記率衰減。 38U／8000 W／冷卻 7000 W、2U 450 W → 19／17／15 卡在冷卻，擱置 8U＋1250 W；準確度掉到 90%，登記率 80% 要 18 個月、50% 只要 7 個月 |
dc-41 |
Modbus RTU / TCP | Modbus 只傳位元組：型別、字序、scale、時間全在協定外，暫存器表是有版本的實體，總線時間是共享資源。 9600 baud 讀 10 暫存器 45.83 ms，30 台一輪 1375 ms（上限 21 台）；字序錯解 50.0 Hz 得 2.38×10⁻⁴¹，而且是一個成功的回應 |
串起來¶
單張卡是點。這週的線是一條資料供應鏈，方向跟卡片的出場順序相反：
物理量 → 感測器（dc-37：代理、精度）→ 傳輸（dc-41：暫存器表、字序、輪詢週期）→ 控制與監看（dc-38 BMS／dc-39 EPMS：品質、時鐘）→ 記錄（dc-40 DCIM：登記、驗證）
卡片是由上往下（BMS → EPMS → DCIM → Modbus）寫的，資料卻是由下往上流的。所以最後一張卡 dc-41 其實是前四張的上游，它的數字約束了前面每一張：
- 輪詢週期約束取樣間隔。 dc-41 算出 30 台、9600 baud 一輪 1375 ms，所以 dc-38 的
Point.interval_s實際最小值是 1.375 s，而 dc-38 的可觀測性規則（interval_s ≤ 事件長度／2）因此只能觀測 ≥ 2.75 s 的現象（這是我把兩張卡的數字相乘的推論，卡片沒寫）。同一條電力事件，dc-39 的 SER 用 1 ms 記——差 1375 倍。dc-38 說「BMS 看不見毫秒事件」，dc-41 說的是「連 BMS 自己想要的取樣率，總線也可能給不起」。 - 輪詢也是時間基準。 dc-41 把 Modbus 點的
time_basis定成poll，不確定度＝bus 週期；這正好是 dc-39 的Clock概念換個皮：1375 ms 的不確定度，比 NTP 的 1 ms 大三個數量級，跨設備加總（總電力、PUE）混了不同時刻。 - 字序錯是「新鮮的壞值」。 dc-41 的 2.38×10⁻⁴¹ 帶著剛剛的時間戳回來。dc-38 說可信度是
value × quality × age；dc-41 補上：age好、quality看起來好，value仍可以是錯的。dc-37 的感測器若是這樣壞，它會被算作覆蓋。
再往下游走，是第二條線：「缺東西」告警家族的分母問題。 本週新增五個（第七到第十一個：RACK_INLET_UNCOVERED、EQUIPMENT_UNMONITORED、BREAKER_NO_STATUS、ASSET_UNREGISTERED 系列、ASSET_NO_REGISTER_MAP），前四個的形狀都是「對清單上的每個東西，找一個有效的觀察者」。但這份清單是誰給的？ dc-41 的練習把 modbus_assets 明寫成「取 dcim.reconcile 的已登記資產子集」。於是：DCIM 登記率掉到 50%，7 個月後準確度低於 90%——所有「缺東西」查詢迭代的對象就少了一成以上，而不在清單上的設備永遠不會被報成缺東西。dc-40 的 ASSET_UNREGISTERED（D−A）是唯一往外看的那一個，而它的 D（探索結果）自己又靠 dc-43／dc-44 還沒寫的 SNMP／Redfish。偵測「缺」的能力，上限是清單的準確度——這是 W38「綠燈的四種死法」之後，母題的新一層。
掉一個會連鎖到哪¶
| 掉的東西 | 第一層 | 第二層 | 有沒有告警說它發生了 |
|---|---|---|---|
| 一條 RS-485 過載（30 台、9600 baud） | 輪詢週期 1375 ms，超過 1 s 需求 | 點位全部變 STALE（dc-38）→ dc-37 的感測器 live=False → 同一排機櫃同時觸發 RACK_INLET_UNCOVERED |
三層各有告警，根因是 Bus，模型裡沒有 Bus 節點可以把它們聚成一件事（見下方 🔴3） |
| 電錶韌體升級後暫存器位址變了 | 讀取回 EXCEPTION 02，或讀到隔壁暫存器 | 時間戳新鮮、值是錯的 | dc-38 的 live_sensors 只看 last_ts，把它算成活的；dc-41 的告警是「表版本不符」，但沒接到 live |
| 對時源（GPS 主時鐘）失聯 | 設備仍在記時間，逐漸漂移 | 203 s（假設 20 ppm）後事件順序在四分之一週期尺度不可信；BMS 的點沒有 clock_id，跨系統對不上 |
CLOCK_SYNC_STALE（dc-39 提出，未實作）；BMS 側沒有 |
| DCIM 登記率從 80% 掉到 50% | 7 個月後資產記錄準確度 < 90% | 所有以登記清單為分母的「缺東西」查詢漏掉未登記的設備 | ASSET_VERIFICATION_STALE 只看已登記者的驗證日期，看不到沒登記的 |
節奏紀錄¶
本週 5/5：10-12（dc-37）、10-13（dc-38）、10-14（dc-39）、10-15（dc-40）、10-16（dc-41）。五個 commit 都在 00:08–00:50 UTC（對應 08:00 +0800 排程），W41 那種兩個 commit 不在排程時間點的狀況沒有重現；開工時 .git/*.lock 不存在、工作樹乾淨。W40、W41 各缺一天，本週補滿——不同週缺不同天、這週沒缺，仍看不出週期，維持「不補卡」的判斷。
連貫性檢視：這週累積的 model code¶
⚠ 範圍說明：repo 內仍沒有使用者實際寫的 .py 檔（已搜尋，排除 .venv、site），我檢視的是卡片裡的練習骨架與意涵段落（sensors.py、bms.py、epms.py、dcim.py、modbus.py）。本機若已有實作，請以實作對照。
先對帳：W41 的收斂清單，本週零落地¶
W41 排了三項 🔴（Finding 形狀、Door 合一、effective()）要掛在 dc-37 練習的第 0 步，🟡4／🟡5 留給 dc-38。結果：dc-37 到 dc-41 五張卡裡搜尋不到任何第 0 步，且五張練習都寫「沿用 (code, subject) 元組」——正是 W41 🔴1 要求刪掉的退路。 Door 與 effective() 本週沒有出場機會（Door 在 dc-35 之後沒再用過；effective 見下方 🔴1）。
為什麼 W40 的清單有人接、W41 的沒有？我能確認的差異：W40 週報的指示被寫進了 index.md 該週那一列（「三項排進 dc-33 練習第 0 步」），dc-33 的卡確實照做；W41 週報在 index.md 那一列只寫了母題與三條線，沒有寫收斂清單；dc-daily-card 的 SKILL.md 裡也沒有「讀最近一份週報的收斂清單」這一步。這是推論，不是確認——但它與 W37 週報指出的規律吻合（可貼的 code 只被下一張卡採納，而讀得到指示的地方才有人採納）。datacenter/topics/model.md（W37 建議的單一真相來源）至今不存在。本週的處理：W42 的清單同時寫進 index.md 該列與 backlog.md 的 dc-42 條目（dc-daily-card 取的就是 backlog 最上面的未完成項）。
🔴 1. 覆蓋查詢已經寫了四次，effective() 一次都沒寫¶
W41 說「等 dc-37 出現第五個覆蓋關係再決定要不要抽象成 Coverage」。dc-37 到了，之後又來了三個：
| 卡 | 函式 | 形狀 |
|---|---|---|
| dc-37 | uncovered(racks, sensors, reach, need_heights) |
每個機櫃 ∃ 活著的感測器 |
| dc-38 | state(eq, nodes, failed) |
每台設備 ∃ 控制邊 → 控制器 |
| dc-39 | check_breakers(breakers, mon) |
每台斷路器 ∃ 狀態點，且含 trip |
| dc-41 | check_maps(modbus_assets, maps) |
每個 Modbus 資產 ∃ 暫存器表 |
四個函式、四種簽名、四種回傳（清單、字串、元組清單、元組清單），全是「對 target 找有效的 observer」。W41 已經抓到「有效」的判定會漂移，本週 dc-38 把 live 改成派生值是半步：它只用了年齡（見 🔴2）。決策點已過，建議現在決定：做。 Coverage(observer, target, kind, valid_when) ＋ 一個 effective(kind, state) -> Result ＋ 一個通用 uncovered(targets, coverage, effective)；上面四個函式各縮成十行以內的 wrapper。DCIM 的 A／D／P 差集（dc-40）形狀不同（登記簿之間的對帳，不是覆蓋），不併。
🔴 2. Point 有三份定義，而 live 只看年齡不看品質¶
- dc-38 意涵 #2：
Point{id, equipment, kind, native_address, protocol, owner_system, interval_s, last_ts, quality, units}。dc-38 練習：Point(id, equip, kind, interval_s, last_ts)——少了quality、owner_system、protocol、units。 - dc-40 說「
Point.owner_system在這裡多一個外鍵asset_id」，但 dc-38 的外鍵叫equipment／equip。同一個外鍵兩個名字；而「東西」本身是Equip（dc-38）、Asset（dc-40）、modbus_assets（dc-41）三個詞。 kind: AI|AO|BI|BO是 BACnet 物件型別；Modbus 點（dc-41）有table、fc、access。同一欄位裝不下兩個協定，而 dc-38 自己說「AO 是命令，只有 AO 可被寫」——那是角色，不是 BACnet 專屬。Reg(name, addr, count, dtype, order)（dc-41 練習）vsRegisterDef{pdu_addr, doc_addr, doc_basis, word_order…}（意涵）：addr／pdu_addr、order／word_order——W41Door的老模式。測資Reg("freq", 3109, …)沒說 3109 是手冊位址還是 PDU 位址。- 最重要的一條：dc-38 意涵 #2 定義
live = quality == GOOD and not stale，但練習live_sensors(points, now)與驗收表 #11 只用last_ts。而 dc-41 的驗收表 #7 剛好展示了反例：字序用錯，不報錯、時間戳新鮮、值是 2.38×10⁻⁴¹。照現在的骨架，這顆感測器是live=True，繼續替那一排機櫃「提供覆蓋」。專門抓靜默失效的RACK_INLET_UNCOVERED，對這種失效是放行的——與 W41 🔴3（contaminated、silenced放行）同一個洞，換了一個入口。
收斂建議：一個 points.py、一個 Point(id, asset_id, role, protocol, native_ref, interval_s, last_attempt_ts_s, last_good_ts_s, quality, time_basis, clock_id)。role ∈ {measure, status, command}（AO／FC05·06·16 → command），BACnet／Modbus 的原生型別放 native_ref；Equip 改叫 Asset、外鍵只叫 asset_id；live(point, now_s) 看 quality 與 last_good_ts_s（不是 last_attempt_ts_s）。拆兩個時間戳是關鍵：Modbus 例外回應是「剛剛試過、沒拿到好值」，只有一個 last_ts 就分不出來。這個決定剛好是 dc-42（BACnet 物件類型）的主題，放在 dc-42 的第 0 步最自然。
🔴 3. 「不確定」有四種拼法、兩種意思，且本週零個檢查回 Result¶
| 位置 | 名稱 | 實際意思 |
|---|---|---|
core.py（dc-30／33）Check |
UNDETERMINED |
資訊不在：沒有額定值、只有搜尋摘要 |
dc-37 verdict() |
UNCERTAIN |
精度不夠：資訊在，區間跨限值 |
dc-39 order() |
INDETERMINATE |
精度不夠：|Δt| ≤ 門檻 |
dc-38 Point.quality |
UNCERTAIN |
又一個（品質旗標，語意未定） |
另外 dc-41 的讀取結果是四態 OK／EXCEPTION／TIMEOUT／CRC_ERROR，第五套詞彙。W41 🟡5 說「會被 Finding 消費的檢查一律回 Result」，本週 verdict() 回字串、order() 回 (字串, 門檻)、state() 回字串、check_* 回元組——零個回 Result。
兩種意思下游處置相同（不是綠也不是紅，出低優先事件），補救不同（去找資料 vs 換更準的儀器／對時）。收斂建議：只保留 Check.UNDETERMINED，用 Result.reason 區分：MISSING_INPUT、UNSOURCED、PRECISION_INSUFFICIENT、ORDER_AMBIGUOUS；IN／OUT 對應 OK／VIOLATED；A_FIRST／B_FIRST 放 Result.detail，不另開列舉。Point.quality 的 UNCERTAIN 改成 SUSPECT（有值、有疑慮）以免撞名。約 10 分鐘，與 🔴2 同一次。
🟡 4. dc-37 的 Rack(id, aisle, pos) 是第三個 Rack¶
W39 才剛合一（RackType ＋ Placement，全軌跡唯一的 Rack），W40／W41 也確認過。dc-37 練習又定義 Rack(id, aisle, pos)，而 Sensor(id, aisle, pos, height_mm, live) 與意涵段的 SensorPoint{space, aisle, rack_pos, side, height_mm} 欄位名不同（pos／rack_pos、缺 space）。aisle 與 pos 是位置事實，應由 Placement 與 dc-28 的封閉 Zone 推導，不是 Rack 的屬性。建議：uncovered() 吃 rack.py 的 Rack，位置序由 Placement 沿通道排序取得；Sensor.aisle 改 space_id（指向封閉區），pos 刪掉。順手修是便宜的，等 🔴1 做 Coverage 時一起改掉。
🟡 5. 假設值藏在預設參數裡¶
各卡的文字都誠實標了「假設」，但程式裡它們是沉默的預設值：dc-37 t_acc=.5, rh_acc=5.、dc-38 stale(..., k=2) 與 bias=50、dc-39 Clock.drift_ppm=20、dc-40 limit=180、dc-41 turn_ms=0.0。其中最危險的是 dc-39：「203 s」這個結論整個依賴 20 ppm，但 holdover_limit_s(0.1, 20, 4.17) 只是把 20 當參數傳進去，結果上看不出它是假設。W40 立的規矩（Sourced.evidence 區分 first_hand／relayed／snippet／assumed）在這裡斷了。建議：core.py 一個 ASSUMPTIONS: dict[str, Sourced]（evidence="assumed"），檢查回傳的 Result 帶 depends_on=["drift_ppm"]；顯示層看到 depends_on 非空就標「基於假設值」。
🟡 6. 時間欄位沒有統一的單位與基準¶
last_ts、now（dc-38，無後綴、沒說是 epoch 還是相對秒）；at_s、last_sync_s、ts_ms、err_ms（dc-39，有後綴）；executed_ts、verified_ts（dc-40，意涵段）；verified_days（dc-40 練習輸入，是「距上次驗證的天數」，可由 verified_ts 與 now 算出的值被存了，與 W41 on_ups: bool 同類）。建議：時間點一律 *_ts_s（UTC epoch 秒）、區間一律 *_s／*_ms／*_days，now_s 由呼叫端傳入；verified_days 改由 verified_ts_s 推導。
🟡 7. 冷卻維度在容量帳本裡沒有生產者¶
dc-40 的 fit(u_free, power_w, cool_w, unit_u, unit_w) 與 CapacityLedger(rack, dimension, budget, committed) 把冷卻當作第三個維度，但 cool_w=7000（「分到這個機櫃的冷卻能力」）是憑空輸入：空間有 dc-29、電力有 dc-14 的降額後預算、重量有 total_weight_kg，冷卻預算每櫃多少，我用關鍵字搜尋整個 devices/ 與 topics/，只有 dc-40 本身出現（未逐張精讀，可能漏在更早某張卡的容量段）。ledger 的結論「卡在冷卻」靠的正是這個沒有來歷的數字。另外練習把 u_free（剩餘 U）當輸入，而意涵段明說「不要存剩餘 U」——測試輸入的方便，但骨架應吃 Rack 與 Placement、自己算剩餘。建議：先在 CapacityLedger 標 cooling.budget 為 Sourced(evidence="assumed")，並排一個主題卡或在 dc-45 之前補上「機櫃冷卻預算怎麼從 Zone／CRAH／RDHx 容量推」。
做得好的地方¶
- 來源衝突被當資料記下：dc-40 的 IMARC 內文與 meta 數字對調、datacentres.com 授權區間與自己的「五年 2–5M」換算差 5 到 6 倍，兩處都是「算給你看再標出矛盾」，沒有默默挑一個。dc-41 抓到來源把
7F 7F 00 00誤算成 1.7E+38（實為 3.39E+38）也一樣。 - 可驗收邊界有守住：嚴格大於（stale 差 120 s → False）、含等號（INDETERMINATE）、整數除法（
breakers_per_ser32÷3＝10）都在驗收表裡逐條釘住。 - 「缺東西」告警維持同一種問法：每張都回答「這個告警在沒有事件的狀況下，要從哪個欄位推導」，這是 🔴1 能做抽象的前提。
建議的收斂順序：🔴3（10 分）＋🔴2（15 分）掛進 dc-42 練習第 0 步（BACnet 物件型別正好逼出 role）；🔴1（20 分）掛進 dc-43（SNMP 是第三個協定，三個協定共用 Coverage 才看得出抽象夠不夠）；🟡4、🟡6 順手改；🟡5 與 🟡7 排在第四輪結束（dc-45）前各一次。
自我測驗¶
Q1.〔事實回憶，dc-37〕 ASHRAE 建議範圍的濕度上限是用相對濕度還是露點定的？24 °C／60% RH、感測器 ±0.5 °C／±5%RH，能不能判定合規？資料模型該怎麼存這個判定？
答案
用露點定（建議 −9 ~ 15 °C，再加 RH 上限）。24 °C／60% RH 的露點 15.75 °C，點估計已超過 15 °C，但區間 [13.94, 17.49] 橫跨限值，判定是 UNCERTAIN，不是合規也不是違規。
對你的模型：只存溫度與 RH 的原始讀值與精度；露點是派生值（帶區間）；Reading{value, accuracy, ts}，判定回三態（本週 🔴3 建議併入 Check.UNDETERMINED＋reason=PRECISION_INSUFFICIENT）。告警規則寫在露點上，不寫在 RH 上。
Q2.〔事實回憶，dc-39〕 PTP–PTP、PTP–NTP、NTP–NTP 的事件排序門檻各是多少？60 Hz 的四分之一週期是多少？「203 秒」這個失聯時限是怎麼來的，哪個輸入是假設？
答案
門檻 2.2／3.1／4.0 ms（時鐘誤差＋解析度，兩端相加；取 PTP 100 µs、NTP 1 ms、SER 解析度 1 ms）。60 Hz 四分之一週期 1000/60/4 = 4.17 ms。
失聯時限：誤差 ε(t) = 0.1 + 0.02t（ms），碰到 4.17 ms 的時間 (4.17 − 0.1)/0.02 ≈ 203 s。漂移率 20 ppm 是假設值，不是來源數字——換成 100 ppm，時限就變成約 41 s。（50 Hz 的 5 ms 則 245 s。）
對你的模型：這就是 🟡5：結果要帶 depends_on=["drift_ppm"]。
Q3.〔應用，dc-41〕 一條 RS-485 掛 28 台電錶，每台讀 12 個暫存器，需求是 1 秒內輪完一輪。9600 baud 做得到嗎？19200 呢？如果 BMS 的點位設定取樣間隔是 1 s，Point 的有效間隔是多少？這在資料模型裡要怎麼表達？
答案
t(12, baud) = (8 + 5 + 2×12 + 7) × 11 / baud＝44 字元 × 11 位元。9600：50.42 ms，28 台 1411.7 ms > 1000，做不到（最多 ⌊1000/50.42⌋ = 19 台）。19200：25.21 ms，28 台 705.8 ms，可以（最多 39 台）。這還是下限（未含從站回應延遲與重試）。
9600 時，設定 1 s 的點位有效間隔是 max(1, 1.41) = 1.41 s。
對你的模型：Bus.cycle_ms 是派生值（各端點 t(n, baud) 之和），Point.interval_s 的有效值 = max(設定值, cycle_ms)；POLL_BUDGET_EXCEEDED 掛在 Bus 上，不是掛在每個點。
Q4.〔應用，dc-40〕 機櫃 42U，預留 6U → 36U 可用；降額後電力預算 6400 W；冷卻能力 5500 W；要放 1U 伺服器，單台尖峰 300 W（熱負載取同值）。可放幾台？卡在哪一維？其他維度剩多少？另外，現場月變更率 c＝2%，登記率 60% 時，資產記錄準確度掉到 90% 以下要幾個月？拉到 90% 呢？
答案
空間 36、電力 ⌊6400/300⌋ = 21、冷卻 ⌊5500/300⌋ = 18 → 18 台，卡在冷卻。剩：空間 36 − 18 = 18U、電力 6400 − 5400 = 1000 W、冷卻 100 W（不夠第 19 台）。
A(t) = (1 − c(1 − r))^t：r＝60% → 每月 0.992，ln 0.9 / ln 0.992 = 13.1 → 14 個月（第 13 個月 0.9010，第 14 個月 0.8938）；r＝90% → 0.998，ln 0.9 / ln 0.998 = 52.6 → 53 個月。登記率從 60 提到 90，保鮮期延長近 4 倍。
對你的模型：剩餘量不存，是 ledger 的派生值（placeable 取各維度最小，binding_dimensions 回傳所有等於最小的）；登記率 r 由 Change.verified_ts 量出來而不是猜。
Q5.〔建模判斷，跨 dc-37／38／39／41〕 Modbus 讀取有四種結果：OK、EXCEPTION(02)、TIMEOUT、CRC_ERROR。你要把它們接到 dc-38 的 Point.quality 與 dc-37 的 live。請設計對應：每種結果要不要更新 last_ts？哪些會讓感測器從覆蓋裡被拿掉？同一條 bus 上 11 顆感測器同時變 STALE，你要發 11 個告警還是一個？
答案
以下是我的設計建議，不是卡片原文。
拆兩個時間戳：last_attempt_ts_s（最近一次嘗試）與 last_good_ts_s（最近一次拿到好值）。OK → 兩個都更新、quality=GOOD。EXCEPTION(02) → 只更新 attempt，quality=BAD、原因 REGISTER_MAP_MISMATCH：設備活著、值不可用，告警是「表版本不符」，不是「離線」。TIMEOUT → 都不更新，quality 維持，直到 now − last_good > k × interval 才轉 STALE。CRC_ERROR → 當暫時性錯誤重試，連續 N 次才降為 SUSPECT。
live 只看 quality == GOOD 且 last_good 夠新；因此 EXCEPTION、STALE、SUSPECT 都會讓感測器從 uncovered() 的覆蓋裡被拿掉——這正是本週 🔴2 說現有骨架沒做到的部分。
告警聚合：11 顆同一條 bus 的 STALE 是一個事件，根因掛在 Bus（若 bus 本身已在 POLL_BUDGET_EXCEEDED 或所有端點同時 TIMEOUT）；其餘 11 個降為它的「受影響」清單。這需要 Point → Endpoint → Bus 這條邊，也是 W41 共因查詢（「同一條 UPS 分支養四個證人」）在資料層的對應版本。
間隔複習¶
兩週前（W40）與四週前（W38）各抽一張。W41 抽的是 W39／W37，這次不重複；W40 抽過 dc-25，故 W38 改抽 dc-24。
抽 W40 的 dc-31 結構化布線與配線架（2026-10-01，17 天前）¶
題目：某條 channel 兩端跳線是 28 AWG，合計 12 m。固定線最長可以多長（用 perm_max = 102 − 1.95 × L_cord，上限 90）？整條 channel 多長？取整要往哪個方向？同一條改成 Cat 8，水平線最長多少？這些在資料模型裡對應什麼？
答案
102 − 1.95 × 12 = 78.6 m，固定線往下取整 → 78 m（四捨五入成 79 就超標，這是真實的舍入方向約束）；channel = 78 + 12 = 90 m。Cat 8：channel 30 m ＝ 水平 24 m ＋ 兩端各 3 m 跳線，且最多 2 個連接點。
對你的模型：不能只存 Cable.length——要 Cable.kind／awg／category，以及 ChannelRule（公式、取整方向、來源）。規則來源沒說的情況回 UNDETERMINED，不要預設 100 m。與本週的連結：Cable.awg 是這類「前提變欄位」的欄位；而 ChannelRule 的係數（1.95、102）是 relayed 出處（Fluke 轉述 TIA-568.2-D），不是 first_hand。
抽 W38 的 dc-24 加濕與除濕（2026-09-15，33 天前）¶
題目：冰水設定 18 °C 時，CRAH 盤管能把室內露點壓到多少？對 ASHRAE 建議上限 15 °C 意味什麼？台北七月補氣 646 CFM 的除濕量約多少 kg/h、多少 kW？它和 dc-21 的 free cooling 建議為什麼在台北正面衝突？
答案
室內露點下限 ≈ 盤管面溫度 ≈ T_chws ＋ approach → 18 °C 冰水約 20 °C，永遠壓不到 15 °C（7 °C 冰水才壓得到約 10 °C）。
除濕量：補氣 646 CFM ≈ 0.305 m³/s ≈ 1278 kg/h 乾空氣；台北七月室外露點 23.6 °C（w 18.4 g/kg）→ 目標 15 °C（10.6 g/kg），Δw 7.8 g/kg → 約 10.0 kg/h；潛熱 10.0 × 2450 / 3600 ≈ 6.8 kW（1600 kW IT 的 0.43%）——能量小，難的是冰水溫度買不到除濕。
衝突：dc-21 說 free cooling 小時數是冰水設定值的函數，18 °C 冬季可觀；dc-24 說 18 °C 冰水放棄濕度上限。台北 4–11 月室外露點高於 15 °C，這個衝突只在台北爆。
對你的模型：Room.min_achievable_dewpoint_c 是 CoolingLoop.chws_setpoint_c 的函數；與 dc-27 的「窗口為空」同型（兩條各自合理的約束交集為空），需要對約束求交集的檢查。（附帶：卡內寫「0.5 ACH 只有 18 kW 凝水」，依上式應為 18 kg/h，單位是筆誤，不影響結論。）
本週該問 facility 的問題¶
從五張卡的「該問 facility 的問題」（共 15 題）去重、排序後選 3 題。排序依據：答案會直接決定本週 🔴 裡某個欄位的值，且只有現場能給。
1.〔建議問：控制系統承包商（BMS 與 EPMS 的廠商），斷路器接點部分請機電確認〕
「全站的時間源是什麼——GPS 主時鐘還是 NTP 伺服器？每台 SER、電錶、保護電驛各用什麼協定對時，有沒有哪些設備只能用 NTP？對時源失聯時現場會不會有告警？還有，每台斷路器是不是都接了 a、b 和 trip 三種接點進 SER？發電機和 ATS 的斷路器目前有沒有狀態點？」
為什麼是它：Clock.kind／err_ms、Event.clock_id 與 BREAKER_NO_STATUS／BREAKER_STATUS_INCOMPLETE 全部取決於這題；沒有答案，dc-39 的 order() 只能對每個事件回 INDETERMINATE。來源：dc-39 該問 #1、#2、#3。
2.〔建議問：控制系統承包商（BMS）〕
「每台 CRAH、冰水機、冰水泵分別掛在哪一台現場控制器？那台控制器失去上層連線時，是獨立運作還是掉到預設位置，預設位置是什麼？BMS 能不能匯出每個點的最後更新時間和品質旗標？有沒有『畫面上有值、其實已經沒在更新』的點？」
為什麼是它：直接給出 ControlEdge.standalone、fail_position（目前預設 unknown）與 Point.quality／last_good_ts_s 能不能從現場取得——這決定本週 🔴2 的收斂能不能落在真實資料上。來源：dc-38 該問 #1、#3。
3.〔建議問：維運（輪詢與資產清單），RS-485 接線細節請控制系統承包商補〕
「每條 RS-485 掛幾台設備、鮑率與同位設定是什麼？EPMS、BMS、DCIM 是不是各自在輪詢同一台電錶，那台電錶同時最多收幾條 TCP 連線？每種設備的暫存器表從哪裡拿、換韌體時有沒有人驗過位址？資產清單放在哪，上一次和現場逐台核對是什麼時候？」
為什麼是它：Bus.cycle_ms、POLL_BUDGET_EXCEEDED、ASSET_NO_REGISTER_MAP 和 DCIM 登記率 r 都從這題的答案取值。尤其最後一句：本週串起來第二條說「缺東西」告警的上限是清單準確度，這句問的是清單現在多準。來源：dc-41 該問 #1、#2、#3；dc-40 該問 #1。
沒選但值得順帶問：dc-37 的感測器位置（進風口前、冷通道中央還是回風）、型號精度、最近一次校正與搬動後有無重校，以及空排與退場租戶的感測器有沒有停用（問 #2 時順便要即可）；dc-40 的現場變更誰負責回寫記錄。
下一張：dc-42 BACnet 物件模型與 MS/TP vs IP（建議第 0 步：本週 🔴3＋🔴2 的 Result.reason 與單一 Point，約 25 分鐘，BACnet 的 AI／AO／BI／BO 正好逼出 role）。下次間隔複習（W43）：抽 W41 的卡（dc-33 ~ dc-36）＋ W39 的卡（dc-26、dc-26b、dc-28、dc-29；⚠ dc-27 已在 W41 抽過）。