2026-W43 週報：觀察者也有拓撲¶

第十三份週報。本週 5 張卡、5 個工作日全齊（10-19 ~ 10-23），連續第二個滿週。內容上收掉第四輪「系統與協定」（dc-42 ~ dc-45），週五由 topic-01 開第五輪主題卡。

W42 的母題是「裸值不是事實」：一個數字要帶著不確定度、年齡、時鐘、登記才是事實。這週往外推一層：帶著那些限定語的數字，是某個觀察者交出來的；觀察者本身有路徑、有週期、有故障域——也就是有自己的拓撲，而且那張圖跟電力圖長得不一樣。 電力 2N，可觀測性常常只有 N。

本週卡片¶

卡	標題	這張卡最關鍵的一個事實
`dc-42`	BACnet 物件模型與 MS/TP vs IP	命令是 16 格的優先序堆疊，不是一個值。 16=40／10=60／8=100 → 有效值 100（優先序 8），BMS 再寫 16 級「成功」但有效值不動；依序放開 → 60 → 40 → `Relinquish_Default` 0 %。MS/TP 9600 baud、11 個 master、讀 100 屬性 16.46 s
`dc-43`	SNMP 與 MIB	語意在 MIB 文件裡，而 MIB 會錯。 RFC 1628 自己的 compliance 段把 battery 寫成 4，Errata 4831 裁定 4＝bypass、5＝battery；scale 是每個物件的事實（0.1 A／0.01 kW／讀 `DecimalDigits`）；counter 差值是三態（繞回 496／重開機丟棄／被歸零丟棄）
`dc-44`	Redfish / IPMI 帶外管理	BMC 與 rack PDU 是看同一條電的兩個觀察者，而 IPMI 的 1 byte 會靜默飽和。 M=4 上限 1020 W，1600 W 伺服器永遠顯示 1020 且不報錯；對帳 8050 − 7600 − 300 = 150 W OK，讀成輸出側變 −335.1 W
`dc-45`	閘道器與協定轉換	閘道器是有自己輪詢週期的第二個觀察者。資料年齡＝916.7 ms＋5 s＝5.92 s；一台死設備每輪吃 1500 ms，第 3 台死就超過上層 5 s，健康設備年齡 10.28 s；hold-last 讓 `POINT_STALE` 永遠不響
`topic-01`	銘牌 vs 降載 vs 實測 vs 配額	四種數字、兩個方向：供給側降載往安全修，需求側打折往風險修。同一 8 646 VA rack PDU：銘牌 32 台、實測零緩衝 56、實測 ×1.2 47；峰值不可相加，40 × 6 kW＝240 vs 同時峰值 172.6 kW

串起來¶

單張卡是點。這週有一條很乾淨的線：四張協定卡是 topic-01「實測值」的上游，topic-01 是第四輪的下游出口。

伺服器 PSU ─┬─ BMC（dc-44，IPMI／Redfish）───────────────────────────┐
            └─ rack PDU outlet（dc-43，SNMP）────────────────────────┤
UPS ────────┬─ 網卡 NMC（dc-43，SNMP → IT）───────────────────────────┼─→ MEASURED ─×1.2─→ ALLOCATED
            └─ RS-485 Modbus → 閘道器（dc-45）→ BACnet/IP → BMS（dc-42）┘    （topic-01，容量帳本）

每一條路徑都有一種「成功的錯誤」——協定回成功、時間戳新鮮、值是錯的：SNMP 是 scale 錯一個 10 的次方（dc-43）、IPMI 是飽和在 1020 W（dc-44）、閘道器是 hold-last 與 Unit ID 指錯（dc-45）、BACnet 是 Out_Of_Service 時被人鎖住的值（dc-42）。

第一條線：高估會被抓，低估不會¶

topic-01 有兩個拿 kind 互相比對的告警：ALLOCATION_BELOW_MEASURED（配額 < 實測）與 MEASURED_ABOVE_NAMEPLATE（實測 > 銘牌）。把上游四種錯誤分方向看：

高估（scale ×10、把 PSU 輸出側當輸入側卻除錯效率）→ 實測衝過銘牌 → MEASURED_ABOVE_NAMEPLATE 響，而且 topic-01 正確地把它歸為資料品質告警。
低估（IPMI 飽和、DCMI 3 h 平均窗把 900 W 抹成 522.2 W、scale ÷10、hold-last 停在離峰值）→ 兩個告警都不響。原因是結構性的：配額是從實測算出來的，錯誤同時流進比較式的兩邊。

算一次（以下是我把 dc-44 與 topic-01 的數字接起來，卡片沒有這個情境）：伺服器 PSU 1600 W、真實峰值 1400 W，IPMI SDR M=4 → 讀值卡在 1020 W。配額 1020 × 1.2 = 1224 W → 1288.4 VA（PF 0.95）→ 一具 8 646 VA 的 PDU 放 6 台。真實負載 6 × 1400 / 0.95 = 8 842 VA，超過降載上限 195.7 VA（2.3%）——超的是 dc-14 的 80% 連續負載線。ALLOCATION_BELOW_MEASURED：1224 > 1020，不響；MEASURED_ABOVE_NAMEPLATE：1020 < 1600，不響。照銘牌放只會是 5 台。

唯一抓得到的是第二個觀察者。 若那具 PDU 有計量，它讀到 ≈ 8 400 W，而 Σ BMC 只有 6 × 1020 = 6 120 W，殘差 2 280 W → dc-44 的 RACK_POWER_UNRECONCILED。所以 dc-44 的「兩個觀察者看同一條電」不是冗餘浪費，是低估方向唯一的防線；dc-44 的 SERVER_POWER_UNATTRIBUTED 把「至少一條路徑」當合格，對這個問題是不夠的——能對帳要兩條。

第二條線：觀察圖有自己的故障域¶

dc-45 的 GATEWAY_SPANS_REDUNDANT_PAIR（A／B 路 UPS 的點位走同一顆閘道器）是全軌跡第一次把電力圖和觀察圖 join。但同一個形狀其實四張協定卡都寫了，只是沒有命名：

卡	共用的觀察節點	掉了的樣子
dc-42	一條 MS/TP trunk、一個沒 BBMD 的子網路	整條 trunk 或整個子網路一起消失
dc-43	一台 trap receiver、一組 community／v3 帳號	所有 trap 消失而輪詢照常、儀表板正常；或一整批同設定的設備同時消失
dc-44	管理網、一組 BMC 帳密	整批 BMC 同時失明；管理網被打穿則能開關機
dc-45	一顆閘道器、一條 RS-485	後面整條總線失明，A／B 路一起

Point.via 目前只裝 gateway id（dc-45 意涵 1），所以 join 只看得到表格最後一列。這是本週連貫性 🔴2 與自我測驗 Q5 的來源。

第三條線：同一個「現在」差三個數量級¶

每條路徑的資料年齡：閘道器代理模式 5.92 s（死 3 台變 10.28 s）、BACnet MS/TP 讀 100 屬性 16.46 s、SNMP 60 s 輪詢、Redfish 500 台逐一爬 70 個 GET 262.5 s 一輪。topic-01 的演算三說「先 sum 再 max」，coincident() 假設各序列的第 i 個樣本是同一時刻——跨這四條路徑，同一個 i 可能相差四分鐘以上（這是我的推論，卡片沒寫）。同時峰值需要對齊的時間軸，而對齊需要 dc-39 的 clock_id 與 dc-44 的 ReadingTime，不是 collector 的收到時間。

掉一個會連鎖到哪¶

掉的東西	第一層	第二層	有沒有告警說它發生了
IPMI SDR 功率 M=4（1600 W 機）	讀值飽和在 1020 W	配額 1224 W → 每 PDU 放 6 台，真實超降載 2.3%	topic-01 兩個告警都不響；PDU 有計量時 `RACK_POWER_UNRECONCILED` 響
Raritan 韌體升級改了 `DecimalDigits`，collector 快取舊 scale	讀值差 10 倍	×10 → 配額膨脹、擱置容量；÷10 → 配額被砍、過載	只有高估方向有 `MEASURED_ABOVE_NAMEPLATE`；`MIB_REVISION_UNDECLARED` 只看宣告不看值
A／B 路 UPS 共用的閘道器 G1，離線策略 hold-last	兩台 UPS 的 Modbus 點同時凍結、`last_good_ts` 仍新鮮	若這是唯一路徑 → 轉電池事件看不見	事前：`GATEWAY_SPANS_REDUNDANT_PAIR`（設定期）；事後：`POINT_VALIDITY_UNSIGNALED`；若另有 SNMP 路徑，`UPS_NO_NOTIFICATION_PATH` 仍 OK——這正是兩種 `Coverage.kind` 對同一 target 的價值
BACnet 進風溫度 AI 被設 `Out_Of_Service`、鎖在 22.0 °C	值新鮮、不報錯	dc-42 `quality_of` → BAD → 從覆蓋裡拿掉	✅ `RACK_INLET_UNCOVERED` 響——W42 🔴2 的收斂在這裡生效（W42 時這一列是放行的）

節奏紀錄¶

本週 5/5：10-19（dc-42）、10-20（dc-43）、10-21（dc-44）、10-22（dc-45）、10-23（topic-01）。但 10-22 那一輪沒有 commit：protocol-gateway.md 的 mtime 是 10-22 00:18，commit d1d7d6f 卻在 10-23 00:17，由隔天的排程補上（commit message 自己註明）。backlog 記載同一輪還誤用沙箱 C locale 的 wc -m（實為位元組數 15532），一度拆出 dc-45b 又撤回——推測那一輪是在處理這件事時中斷的（推論，未確認）。本次開工時 .git/*.lock 不存在、工作樹乾淨。

建議（給 dc-daily-card 收尾）：(1) 收工最後一步 git status --porcelain 必須為空，不為空就在 index 標紅；(2) 字數一律 LC_ALL=C.UTF-8 wc -m。第一條是 W38 那條「runlog」建議的最小版本——這次是靠下一輪恰好有人看 git status 才救回來。

連貫性檢視：這週累積的 model code¶

⚠ 範圍說明：repo 內仍沒有實際的 .py 檔（已搜尋，排除 .venv、site、.git）。我檢視的是五張卡練習區塊的骨架與「對資料模型的意涵」段落（core.py、points.py、bacnet.py、coverage.py、snmp.py、bmc.py、gateway.py、figures.py）。本機若已有實作，請以實作對照。

先對帳：W42 收斂清單，這次落地了¶

W42 項目	結果
🔴3 「不確定」只留一態＋`Result.reason`	✅ dc-42 第 0 步：`Reason{MISSING_INPUT, UNSOURCED, PRECISION_INSUFFICIENT, ORDER_AMBIGUOUS}`、`Quality.UNCERTAIN → SUSPECT`
🔴2 單一 `Point`、拆兩個時間戳、`kind → role`	✅ dc-42 第 0 步：`points.py`、`live()` 只看 `last_good_ts_s`（驗收 #14 釘住）、`Equip → Asset`
🔴1 `Coverage`＋`effective()`	✅ dc-43 第 0 步：`coverage.py`；本週已有 9 個 kind 註冊（`inlet_sensor`、`snmp_poll`、`snmp_trap`、`bmc_psu`、`pdu_outlet`、`gw_exception`、`bacnet_reliability`、`gw_status_register`、`sentinel`）。dc-38／39／41 的三個舊查詢「留到週報」→ 見下方 🟡6
🟡6 時間欄位 `*_ts_s`／`now_s`	✅ 本週新骨架全部遵守
🟡4 dc-37 的第三個 `Rack`	❌ dc-43 改寫 `uncovered` wrapper 時沒提
🟡5 假設值藏在預設參數	◐ dc-43 意涵段把 `timeout_s`／`retries` 標成 `Sourced(evidence="assumed")`，但程式預設值照舊（見 🟡5）
🟡7 冷卻預算沒有生產者	❌ W42 排在 dc-45 前，未處理

為什麼這次有人接？ 跟 W42 的推論一致：W42 的清單同時寫進 index.md 該列與 backlog.md 的 dc-42 條目，而 dc-daily-card 讀的就是 backlog 最上面那一項。機制驗證了第二次。 所以本週清單照做：寫進 backlog 的 topic-02、topic-03 條目。

🔴 1. `Finding` 連續第三週沒有形狀，而「缺東西」已經十五個¶

W41 🔴1 提了 Finding(code, subject_kind, subject_id, reason, kind)，W42 沒落地，這週 dc-42 練習寫「Finding(code, subject) 有現成的就換掉」——欄位名又跟 core.py 的 Finding(code, space_id, reason) 不同。然後本週七個檢查函式全部回元組：check_mstp、check_instances、check_subnets（dc-42）、check_snmp（dc-43）、check_bmc（dc-44）、check_gateways（dc-45）、check（topic-01），型別都是 list[(code, id)]。

代價已經看得見：十五個「缺東西」告警（第十二到十五個是本週的 SUBNET_NO_BBMD、UPS_NO_NOTIFICATION_PATH、SERVER_POWER_UNATTRIBUTED、POINT_VALIDITY_UNSIGNALED）沒有 kind 可以聚合；topic-01 的 MEASURED_ABOVE_NAMEPLATE 自稱「資料品質告警，不得同時吐容量類告警」——這句話在元組裡沒有欄位可以表達。而 uncovered() 已經回 (target_id, Result)，Result 帶著 reason，到了 Finding 這一層卻被壓回字串。

收斂建議（約 10 分鐘）：

class FindingKind(Enum): VIOLATION; MISSING_PROTECTION; DATA_QUALITY; FACT
@dataclass(frozen=True)
class Finding: code: str; subject_kind: str; subject_id: str; result: Result; kind: FindingKind
def from_uncovered(code, subject_kind, pairs) -> list[Finding]   # kind = MISSING_PROTECTION

space_id 刪除；check_* 一律回 list[Finding]。掛進 topic-02 練習第 0 步（80% 規則卡的檢查天然會產出 VIOLATION 與 DATA_QUALITY 兩種，正好驗這個欄位）。

🔴 2. `Point` 才統一一週，三張卡各長了欄位，沒有一張回頭改 `points.py`¶

dc-42 立的唯一 Point(id, asset_id, role, protocol, native_ref, interval_s, last_attempt_ts_s, last_good_ts_s, quality, time_basis="poll", clock_id=None)。之後：

dc-44 意涵加 side ∈ {input, output}、aggregation{kind: instant|avg|min|max, window_s}，並要把 resolution／range_max「寫回 Point 的不確定度」。
dc-45 意涵加 via: list[gateway_id] 與 age_bound_s，同時說 poll_cycle_s「是算出來的」——存一個由 via 與死設備數重算的值，就是 topic-01 剛批評的 NetBox available_power（dc-02 叫我們別做的那種）。
time_basis 出現三個自由字串："poll"（dc-41／42）、"device"（dc-44）、"gateway_poll"（dc-45）。
topic-01 的 MEASURED 存 (node_id, window, statistic, point_ids)——跟 dc-44 的 aggregation{kind, window_s} 是同一個概念、兩組名字（statistic／kind、window／window_s）。

收斂建議（約 15 分鐘）：

class TimeBasis(Enum): POLL; DEVICE; GATEWAY_POLL
@dataclass(frozen=True)
class Aggregation: stat: Literal["instant","avg","min","max","p95","peak"]; window_s: float | None
# Point 新增：via: tuple[HopRef, ...] = ()、tap: Literal["psu_input","psu_output"] | None、
#            aggregation: Aggregation = Aggregation("instant", None)、resolution、range_max
def age_bound_s(point, hops, now_s) -> float      # 派生，不存

topic-01 的 MEASURED Figure.basis 直接放 Aggregation＋point_ids，不另起名字。via 的元素是 HopRef(kind, id) 而不只是 gateway id——理由見「串起來」第二條線與 Q5。掛進 topic-03（N／N+1／2N）練習第 0 步：冗餘定義那張卡正好需要「觀察路徑也要算冗餘」這個查詢。

🔴 3. 一週內四個名字各指兩件以上的事¶

名字	意思 A	意思 B（以後）	後果
`effective`	dc-43 `coverage.effective(c, state, now_s) -> Result`	dc-42 `bacnet.effective(pa, rd) -> (value, priority)`	兩個模組都 `from … import effective` 時後者靜默覆蓋前者
`kind`	`Coverage.kind`＋`@kind` decorator（dc-43）	`Figure.kind`（topic-01）、`aggregation.kind`（dc-44）、W41 提案的 `Finding.kind`	一個詞四個列舉
`side`	`Figure.side ∈ {SUPPLY, DEMAND}`（topic-01）	`Point.side ∈ {input, output}`（dc-44，PSU 的哪一側）	同一筆「伺服器實測功率」兩個 `side` 都要填，而且意思不同
`quality`	dc-42 `quality_of(flags) -> Quality`（GOOD／SUSPECT／BAD）	dc-45 `quality(read, gw) -> Result`，驗收 #13 期望「BAD；BAD；BAD；UNDETERMINED」	BAD 是 `Quality` 的成員，不是 `Check` 的——一個函式的回傳型別裝了兩個列舉

收斂建議（約 10 分鐘，與 🔴1 同一次）：bacnet.effective → effective_command；@kind → @observer_kind；aggregation.kind → stat（已在 🔴2）；Point.side → tap（已在 🔴2）；dc-45 quality() 改名 quality_of(read, gw) -> Quality，與 dc-42 同簽名形狀——hold-last 無其他訊號時回 SUSPECT，「失效看不看得見」交給 POINT_VALIDITY_UNSIGNALED 的 Coverage 判斷，不塞進點位品質。Figure.kind 保留（它是 topic-01 的核心詞）。

🟡 4. `Reason` 剛定案，`UNSOURCED` 就被拿去裝三件事¶

W42 定義 UNSOURCED = 「只有搜尋摘要、沒有可用出處」。本週：dc-44 意涵 4「side 未知 → UNSOURCED」、dc-45 驗收 #13「hold-last → UNDETERMINED(UNSOURCED)」、dc-44 bmc_psu「side None → UNDETERMINED」（沒寫 reason）。side 未知是缺輸入（MISSING_INPUT）；hold-last 是有值但無法驗證有效性，四個既有 reason 都不貼切。建議：side 未知改 MISSING_INPUT；新增 Reason.VALIDITY_UNSIGNALED（給 hold-last）與 Reason.SATURATED（給 dc-44 讀值 = range_max——它不是精度不夠，是只知道下界，見「串起來」第一條線）。

🟡 5. 假設值仍在預設參數裡（W42 🟡5 未清）¶

本週新增：dc-45 cycle_ms(…, timeout_ms=500, attempts=3)（卡片自己標 500 ms 為單一來源）、dc-42 rp_ms(baud, req=30, resp=40)／token_ms(frame=8)（卡片標單一來源 Chipkin）、dc-42 check_instances(hi=4194302)——這是一個「來源分歧」的值（4,194,302 vs 4,194,303），被寫成了沉默的預設、topic-01 measured_peak(min_days=30)。dc-43 在意涵段做對了（Sourced(evidence="assumed")），但程式沒跟上。建議：core.ASSUMPTIONS 一次收齊，函式只收參數不給預設；hi 這種分歧值帶 Sourced(evidence="relayed", note="來源分歧")。

🟡 6. 三個舊覆蓋查詢的 wrapper（dc-43 留給週報的）¶

dc-43 把 dc-37 改成 @kind("inlet_sensor")，dc-38／39／41 留下。照同一格式（改名後用 @observer_kind）：

@observer_kind("control_edge")    # dc-38 EQUIPMENT_UNMONITORED：target=設備，observer=控制器
#  控制器 live 且邊存在 → OK；控制器 STALE 且 edge.standalone is None → UNDETERMINED(MISSING_INPUT)；否則 VIOLATED
@observer_kind("breaker_status")  # dc-39 BREAKER_NO_STATUS：target=斷路器，observer=狀態點
#  點 live 且 contacts ⊇ {a, b, trip} → OK；缺 trip → VIOLATED(detail="incomplete")
@observer_kind("register_map")    # dc-41 ASSET_NO_REGISTER_MAP：target=Modbus 資產，observer=RegisterMap
#  map.version == asset.firmware_map_version → OK；asset 版本未知 → UNDETERMINED(MISSING_INPUT)

dc-42 的 SUBNET_NO_BBMD 寫於 Coverage 之前，是第四個候選（observer＝監督者的可達集合）；不急，check_subnets 驗收表已釘住行為。

🟡 7. `Figure` 是「值＋出處」家族第九次，而 `source` 預設是空字串¶

topic-01 的 Figure(value, unit, kind, side, basis="", source="") 收斂了六個 Rating／Limit，方向對。但 dc-30／33 起 core.Sourced(value, source, evidence) 就存在，而 W40 🔴3 的教訓正是「出處可以是空的就等於沒有防線」。Figure 讓 source="" 合法，等於重開那個洞。建議：Figure 的 source 改必填，加 evidence（或直接 Figure.value: Sourced）；topic-01 驗收 #1 的 251 W 就填 relayed（Fan 2007）。

做得好的地方¶

W42 清單整份落地，而且有驗收表守著：dc-42 #14 用三列釘住「只看 last_good」、dc-43 #11 用七個 target 釘住 uncovered 的 OK／UNDETERMINED／VIOLATED 三種出口。這是 W37 以來第一次收斂建議被下一張卡連驗收一起接住。
Coverage 的抽象撐住了三個新協定：dc-44、dc-45 都沒有再寫一個自己的覆蓋函式，直接 @kind 註冊。W42 說「等第三個協定共用才看得出抽象夠不夠」——答案是夠。
來源分歧照舊被當資料：RFC 1628 自己跟自己衝突（dc-43）、DCMI 窗口單位差 1000 倍不裁決（dc-44）、閘道器離線三種慣例並存（dc-45）、McFarlane 一句話兩種讀法差 30 個百分點（topic-01）。

建議的收斂順序：🔴1＋🔴3（20 分）掛 topic-02 第 0 步；🔴2＋🟡4（20 分）掛 topic-03 第 0 步；🟡5、🟡7 在 topic-04（擱置容量正是「兩個 kind 的差」，會大量用到 Figure）一起做，同時補 W42 🟡7 的冷卻預算——擱置容量的四種型態裡本來就有「冷卻先見底」。🟡6 隨手。已同步寫入 backlog topic-02／topic-03 條目。

自我測驗¶

Q1.〔事實回憶，dc-43〕 UPS-MIB upsOutputSource 讀到 4 是什麼狀態？5 呢？為什麼有人會搞反？另外，一個 Counter32 前值 4,294,966,000、本值 1,500：sysUpTime 上升時差值多少？sysUpTime 下降時呢？

答案

4 = bypass、5 = battery（RFC 1628 SYNTAX；同一份 RFC 的 MODULE-COMPLIANCE 段寫成 normal(2)／battery(4)，Errata 4831 裁定 SYNTAX 正確，observium 照抄了錯的版本）。繞回：1500 + 2³² − 4,294,966,000 = 1500 + 1296 = 2796。sysUpTime 下降表示重開機，差值丟棄、重新取基準，不是繞回。 對你的模型：enum 對照存成有出處的 MibObject.enum_map（帶 errata_applied）；差值函式回三態 OK／WRAP／DISCONTINUITY(REBOOT|RESET)，每台 agent 要另存 AgentState.uptime_ticks，能量帳本把 DISCONTINUITY 區間標為缺口、不補零。

Q2.〔事實回憶，dc-42〕 一個 CRAH 冰水閥 AO，Relinquish_Default = 50 %。優先序 16 = 30 %、12 = 55 %、8 = 90 %。有效值是多少？值班員放開 8 之後呢？接著 BMS 寫 16 = 45 %，有效值變不變？再放開 12 呢？

答案

90 %（8） → 放開 8 → 55 %（12） → BMS 寫 16 = 45：寫入成功，有效值仍 55 %（12 比 16 優先）→ 放開 12 → 45 %（16）。全部放開才回到 50 %。 對你的模型：命令是 CommandSlot{point_id, priority, value, writer, written_ts_s} 的集合，有效值是查詢結果；「WriteProperty 回成功」不能當作「閥到位」，COMMAND_OVERRIDE_STALE 由 priority ≤ 8 與 written_ts_s 推導。

Q3.〔應用，dc-45〕 一條 RS-485 掛 24 台電錶（每台一次交易 45.83 ms），閘道器代理模式、序列側 timeout 400 ms × attempts 3，上層每 5 s 讀一次。最多容忍幾台死設備？死到上限時健康設備的最壞資料年齡是多少？collector 的 timeout 至少要設多少？

答案

健康一輪 24 × 45.83 = 1100 ms；每台死設備多花 1200 − 45.83 = 1154.17 ms。1100 + n × 1154.17 ≤ 5000 → n ≤ 3.38 → 3 台（3 台 4562.5 ms，4 台 5716.7 ms）。3 台死時最壞年齡 4.5625 + 5 = 9.56 s。 collector timeout 要 > 400 × 3 = 1200 ms（透通模式再加佇列中最長等待），否則例外碼 11 會被記成 TIMEOUT、排查方向錯成「網路掛了」→ TIMEOUT_NOT_NESTED。 對你的模型：age_bound_s 由 via 每一跳的 cycle_ms(n_ok, n_dead) 派生（不存）；n_dead 來自同閘道器後方點位的 quality，所以一台設備的品質會改變別台點位的年齡上界。

Q4.〔應用，跨 dc-44 × topic-01〕 一櫃 rack PDU 降載後 8 646 VA，PF 取 0.95。伺服器 PSU 銘牌 1600 W，真實峰值 1400 W，但 BMC 的 IPMI SDR 功率感測器 M=4。你用「實測峰值 × 1.2」做配額。一具 PDU 放幾台？真實負載超不超？topic-01 的四條告警哪條會響？什麼能抓到？

答案

M=4 上限 4 × 255 = 1020 W，讀值飽和。配額 1224 W → 1288.4 VA → ⌊8646/1288.4⌋ = 6 台。真實 6 × 1400/0.95 = 8 842 VA，超降載上限 195.7 VA（2.3%）。（照銘牌只會放 5 台。） ALLOCATION_BELOW_MEASURED（1224 > 1020）不響、MEASURED_ABOVE_NAMEPLATE（1020 < 1600）不響——配額由實測算出，錯誤同時流進兩邊。能抓到的是第二個觀察者：PDU 計量讀到約 8 400 W vs Σ BMC 6 120 W，殘差 2 280 W → RACK_POWER_UNRECONCILED。 對你的模型：Point.range_max（由 SDR 的 x=255 推出），讀值 = range_max 時該樣本只是下界——Result(UNDETERMINED, SATURATED)（本週 🟡4 建議新增的 reason），不得進 measured_peak()；SERVER_POWER_UNATTRIBUTED 之外，容量用途還需要「有兩條路徑可對帳」的覆蓋等級。

Q5.〔建模判斷，跨 dc-42 ~ dc-45〕 dc-45 的 GATEWAY_SPANS_REDUNDANT_PAIR 只檢查「冗餘配對共用閘道器」。請把它推廣成一個查詢：找出任何冗餘配對的觀察路徑共用的節點。你需要哪些資料？Point.via 要改成什麼？哪些共用不該算問題？

答案

以下是我的設計建議，不是卡片原文。資料：Point.via 改成有序的 HopRef(kind, id) 清單，kind ∈ {gateway, bus, trunk, subnet, mgmt_net, collector, trap_receiver, credential_set}——本週四張卡各自點名了其中幾種（「串起來」第二條線的表）。電力側沿用 Asset.redundancy_peer。查詢：對每一組冗餘配對 (A, B) 的同類關鍵點位（例：轉電池狀態），若 A 的每一條有效觀察路徑都經過某個 hop h，B 的每一條也都經過 h——h 同時是兩邊的單點——出 OBSERVATION_SPOF_SPANS_PAIR(h)。只有一條路徑時退化成 dc-45 的版本。 不該算問題的：(1) 那個點位另有一條不經該 hop 的有效路徑（例：UPS 同時有 SNMP 與 Modbus，見本週 UPS_NO_NOTIFICATION_PATH 兩種 kind）——所以判斷要在 Coverage 層做，不是在單一 Point 上；(2) 共用的是 credential_set 但設備在不同網段——仍是共因（帳號被鎖兩邊一起消失），應該算，容易被誤排除。結構上這是 dc-10b 共祖測試在觀察圖上的對偶：電力圖問「兩路有沒有共同上游」，觀察圖問「兩個證人有沒有共同的嘴」。

間隔複習¶

兩週前（W41）與四週前（W39）各抽一張。W41 的卡（dc-33 ~ dc-36）尚未被抽過，選 dc-34；W39 已抽過 dc-27（W41），改抽 dc-29。

抽 W41 的 dc-34 門禁與門控制器（2026-10-07，18 天前）¶

題目：機房有 40 扇 fail-safe 電磁鎖，每扇 500 mA。鎖的總電流多少？若鎖電源不在 UPS 上，市電中斷那一刻會發生什麼？用本週 topic-01 的語言，這 500 mA 是哪一種數字，40 扇直接相加可以嗎？另外，Wiegand 26 位元為什麼不能拿「卡號」當身分鍵？

答案

40 × 0.5 = 20 A。不在 UPS 上 → fail-safe 斷電釋放 → 40 扇門同時打開。 500 mA 是需求側銘牌（NAMEPLATE, DEMAND）。topic-01 說峰值不可相加，但電磁鎖是持續通電的恆定負載，同時峰值就等於峰值總和——這是 peak(Σ) = Σ peak 的等號情況，相加是對的；相加對不對取決於負載型態，不是一條通則（這是我的推論）。身分鍵：H10301 不防重複，兩個設施可發出同一組 (123, 4567)；身分是 (format, facility, number) 三元組，且 26 位元格式可用 255 × 65535 = 16,711,425 張。 對你的模型：Door.lock_mode ＋鎖是 PowerFeed 下游的消費者（電力圖的邊）；EGRESS_BLOCKED_ON_POWER_LOSS 由 is_egress_path ∧ fail_secure ∧ ¬mech_egress 推導；沒有 DPS 的門 → DOOR_UNMONITORED（第四個「缺東西」，本週 🔴1 的 MISSING_PROTECTION 家族）。

抽 W39 的 dc-29 機櫃與 U（2026-09-25，30 天前）¶

題目：一個 OCP ORv3 44OU 機櫃的可用高度等於幾個 EIA U？為什麼不存在整數答案？一個 42U 櫃裝滿盲板，片間縫 1/16″ 時前面等效開了多少 U？用 IEC 60297 公差 0.4 mm 算呢？這和本週 topic-01 的 NetBox 預設值陷阱是同一種病嗎？

答案

44 × 48 / 44.45 = 47.5 U（1 OU = 1.0799 U），兩種格線對不齊，所以沒有整數換算。盲板縫：42 × 1.5875 = 66.7 mm = 1.50 U；IEC 公差 42 × 0.4 = 16.8 mm = 0.38 U——來源分歧，差 4 倍，差在採購規格。同一種病：一個不帶前提的欄位會被靜默套上預設前提。u_height 不帶單位制，混用機房每台錯 7%；NetBox PowerFeed 不改 120 V／15 A 就是 1 440 VA，三相不標線／相電壓只得 57.9%。 對你的模型：位置標準形是「從底算起的半 U 整數」＋ RackType.unit_system ∈ {EIA, OU}；OPEN_U_IN_FRONT_PLANE 是第一個「缺東西」告警（dc-29 立的，今天已有十五個）；topic-01 的 FEED_VOLTAGE_REF_UNKNOWN 是同一條規則在電力側的版本。

本週該問 facility 的問題¶

從五張卡的該問問題（共 16 題）去重、排序後選 3 題。排序依據：答案會直接決定本週 🔴 或「串起來」某個欄位的值，且只有現場能給。

1.〔建議問：控制系統承包商（BMS 與閘道器），RS-485 實體接線請機電確認〕

「A 路和 B 路 UPS 的監控，是不是走同一條 RS-485 或同一顆閘道器？每顆閘道器是透通還是代理模式，序列側 timeout 和重試次數多少、重試含不含第一次？下游設備離線時，閘道器回給 BMS 的是舊值、哨兵值（多少？是原始值還是工程值？），還是例外碼——幾號？BMS 讀閘道器的 timeout 設多少？」

為什麼是它：GATEWAY_SPANS_REDUNDANT_PAIR、TIMEOUT_NOT_NESTED、Gateway.offline_policy 與 POINT_VALIDITY_UNSIGNALED 全部取決於這題；若答案是「同一顆、hold-last」，A／B 路 UPS 的轉電池事件可能只剩 SNMP 一條路徑。來源：dc-45 該問 #1–#4。

2.〔建議問：維運（DCIM／NetBox 帳本負責人），三相饋線電壓請機電確認〕

「容量帳本裡每台伺服器的功率，填的是銘牌、打折後的銘牌、還是實測？打折打幾折、誰定的？如果是實測，用多長的時窗、取峰值還是 95 分位、加多少緩衝？資料是從 BMC 還是 PDU 來的？雙電源設備兩個 power port 是不是各填一次？三相饋線的電壓欄填的是 380 還是 220？」

為什麼是它：決定 Figure.kind、Aggregation、ALLOCATION_UNBASED 與 FEED_VOLTAGE_REF_UNKNOWN 的實際值；「資料從 BMC 來」這一句會告訴你 Q4 那個飽和情境是不是真的風險。來源：topic-01 該問 #1–#3。

3.〔建議問：維運（IT 網管／伺服器管理）〕

「BMC 和 UPS／PDU 的網卡是不是在獨立的帶外管理網？IPMI over LAN 關了沒、出廠密碼上架時有沒有換？collector 讀 BMC 是用 IPMI 還是 Redfish、讀新的 PowerSubsystem 還是舊的 Power？SNMP 是 v2c 還是 v3，trap 送到哪幾台，上一次實際測試是哪天？」

為什麼是它：IPMI_LAN_EXPOSED（CVE-2013-4786 無修補，只能靠隔離）、Bmc.power_schema、SnmpAgent.trap_targets 與 UPS_NO_NOTIFICATION_PATH 的 trap 路徑都從這題取值；「trap 上次測試是哪天」答不出來，那條路徑就是 UNDETERMINED。來源：dc-44 該問 #1、#2；dc-43 該問 #2。

沒選但值得順帶問：問 #1 時順便問控制系統承包商哪些 BACnet 物件的優先序 ≤ 8 還有值、誰寫的、Relinquish_Default 各是多少（dc-42 #2）；問 #3 時順便問 NMC 韌體與 MIB 檔版本、PDU 能量計數器有沒有人歸零過（dc-43 #1、#3），以及 BMC 進風溫度有沒有被拿來當機櫃進風感測器（dc-44 #3）。

下一張：topic-02 斷路器 80% 連續負載規則（建議第 0 步：本週 🔴1 Finding＋🔴3 改名，約 20 分鐘）。下次間隔複習（W44）：抽 W42 的卡（dc-37 ~ dc-41）＋ W40 的卡（dc-30、dc-30b、dc-32；⚠ dc-31 已在 W42 抽過）。