依据:
wind_analytics_算法模型分类报告(上游仓wind-analyticsmain357350d4,2026-09-30 静态核验快照) 的 §4「历史要求与当前实现的关键差异」(9 条) 与 §5「TCM 原判断与修正边界」(6 条)。 目的:把该报告的「原判断 → 反例 → 修正 → 适用域」写法,落到观澜自己的代码与文档上,防名实误读。核验方式(本清单的证据级别):对观澜仓单次遍历 23,828 个文本文件逐条正则核验 + 命中处逐行看上下文(是注释/文案,还是真实逻辑)。 口径纪律:报告中以上游
357350d4的 file:line 为准,不得直接引为观澜结论;下表「观澜实测」列是本清单唯一可引用的结论来源。标签:
[记]报告/文档主张 ·[码]本轮核到观澜代码 ·[待核]需进一步定位 ·[不适用]观澜无此实现 ·[已优于]观澜已优于上游
| # | 报告条目 | 报告原判断 / 反例 / 修正 [记] |
观澜实测 [码] |
结论与处置 |
|---|---|---|---|---|
| 1 | C04 固有线图谱与共模分解 | 「缺陷率>50% ⇒ fleet 全盲」已于 9/5 撤销;当前六层文档仍残留旧句 | 观澜全仓 全盲 仅 1 处:app_algorithmModel/app_algorithmModel_guanlan/windcms/report_std.py:182,上下文是具体机组的说明——"全盲台 02/18/37 各部件皆不可判 → 整机自然不可判" |
不残留 ✓:同词不同义(观澜说的是"某几台不可判",不是那条已撤销的失明定理)。处置:无需改代码;如需彻底消歧,可在六层链文档加一句"本处'全盲台'指具体机组,非'缺陷率>50%⇒fleet 全盲'定理" |
| 2 | A03 CMS 采集可用性与 IEPE 绝对链 | 9/25 已在 l0_view.py:131–156 加告警滞留特判、report_std 已接 avail_detail;但旧缺陷表未同步 |
观澜 report_std.py 有完整三轴口径(状态等级 优秀/良好/报警/危险/不可判 × 证据状态 确诊/准定论·预警/候选/INSUFFICIENT × 行动 P0–P3)与"不可判"释义;discriminators.py 有 Active/CurrentCount/TargetCount(TCM 侧)。观澜无 l0_view.py 同名模块(已重构) |
部分适用 [待核]:观澜无报告所指"旧缺陷表",故不存在"未同步";处置:登记"可用性口径以 report_std 三轴为准",并把"能否区分告警滞留 Active 与在场数据"列入补核 |
| 3 | A04 冻结参照的跨域测量链疑似 | 9/17 判定已改「疑似」;l0_absolute/cms_availability 有绝对电气链;9/18 已有 D1b 绝对检查 |
该主题在观澜多处存在:app_algorithmModel/.../taxonomy.py、subsys/fusion.py、windcms/report_std.py、app_ontology/.../ontology/codes.py、sop/discriminators.py、scripts/rudong_fusion_handoff.py |
[待核]:观澜侧"疑似"这一措辞与判据是否已落文档(不是代码有无);处置:列入 backlog,逐文件确认"疑似/不可判"是否与绝对链并存 |
| 4 | C02 自适应基线与滞回 | oem_hysteresis.py 已有可导入原厂规则;上游 apply_hysteresis 需逐窗 level 序列,而全窗裁决不产生该序列 ⇒ 函数存在 ≠ 默认生产链使用 |
观澜 app_ontology/.../sop/fusion_diag.py 有 3 处滞回相关;未见 oem_hysteresis/apply_hysteresis 同名实现 |
[待核]:需定位观澜的"显示锁存/原厂迟滞"落在哪一层,并确认是否被默认链调用(这正是报告告诫的"函数存在 ≠ 已使用") |
| 5 | C05 同域能量锚与部件实物锚封顶 | 持续性已由固定 4/6 改 ceil(2N/3);rudong_model_run.py:427–432 九窗要求 6 窗;不能再拿四窗当九窗中的同等证据 |
观澜 四窗 命中 3 处,全部是注释里的观测事实(discriminators.py:4796"四窗纹丝不动"、5082"跨四窗 1.61~1.74×fleet"、vib_confidence.py:85 同);观澜 Python 全仓未出现 ceil(2N/3),亦未见 九窗 |
局部适用 [待核]:观澜没有那条"四窗=九窗同等证据"的误用(注释语义清白 ✓),但也未采用比例门 ⇒ 处置:定位观澜的持续性门实现位置并明确其窗数口径(列入 backlog 第 1 项) |
| 6 | C01 ISO 速度 RMS 与宽带标量 | 上游 report_std.iso_state 实际只按 7.1 mm/s 二分报警与优秀,融合脚本另用 7.1/11 mm/s ⇒ 显示与融合口径须分别看 |
观澜 windcms/report_std.py:67:ISO_C, ISO_D = 7.1, 11.0,并带注释记录历史漏判实逮("17# 8.9 超C / 27# 128 超D 漏判实逮") |
已优于上游 [已优于] ✓:观澜 report_std 已同时携带 C/D 双阈 ⇒ 本例的"口径分列"问题在观澜不存在。处置:无需改;可在文档中把该双阈写成显式口径条目 |
| 7 | B21 四层异常检测与预警器 | 旧四层 trend_level.py:20 对空输入/无时间戳/少于 5 日输出 A,存在"旧入口语义风险" |
观澜除 src/windscada/en_text.py 一处翻译字符串外,无四层实现与调用 |
不适用 [不适用] ✓:观澜未移植该模块,风险不传递 |
| 8 | B02 限电、停机与离线分离 | 注册表状态陈旧(configs/analysis_modules.yaml 写 builtin_avail_verify 待实现,实际 discriminators.py:2223 已实现) |
确证同源缺陷:观澜 app_ontology/.../sop/discriminators.py:1094 原文写"…builtin_avail_verify/zero_gen_redflag 待实现",而两者均已实现 —— builtin_avail_verify 在 2203 行、zero_gen_redflag 在 2234 行 |
真缺陷 → 本版已修 ✓:改为"两函数实现均已在本模块落地(§4.3 与同批 n≥2 提级),此处仅说明不入 A_op 抽取面、留 per-farm 传入比对" |
| 9 | D04 gym 算法探索与淘汰图 | 7 月"灰箱永久关闭"是特定实验/治理结论,不是所有灰箱方法被理论否定;应保留失败主张与重新进入条件 | 观澜无 gym 目录 ✗ |
不适用 [不适用] ✓:观澜无该实验套件;该报告条目仅作方法论参照 |
报告这 6 条写法(原判断 → 反例 → 修正 → 适用域)最具复用价值;观澜的 TCM/CMS 复算链正在同一主题上 (实测:
windcms/report_std.py含rms_200/Reference、discriminators.py:4426有"最终阈值是手填的全场统一固定值"的实逮记录、docs/振动六层链_接口规格与缺口_v0.1.md含 TCM/Hysteresis 口径)。
| # | 报告条目 | 报告要点 [记] |
观澜处置(建议) |
|---|---|---|---|
| 1 | Reference 基线 | 原判断"mask.Reference=样本均值"为 FALSE;修正为「均值+3×总体 SD 及 15 样本 Peak 最大值」的对照推断(9/17 登记准定论);适用域:样本级重建未成,不能拿推断基线替实际数值阈定级 |
[待核]:核对观澜 TCM 文档/代码里对 Reference 的表述,补一句"推断值,不得替代实际数值阈" |
| 2 | CurrentCount 样本身份 | 原判断"同计数=同批样本"为假;修正:同计数可对应不同接受样本组;适用域:不可把计数当原始样本覆盖 | [待核]:加入口径说明(覆盖/样本量陈述时不得等同) |
| 3 | 原厂迟滞规则 | 原判断"mask.Hysteresis恒 3 即上限"被反例(rms_200 上限 100);修正:逐测量读取 Red/YellowHysteresis、±1 钳位、到上限起报到 0 解除;适用域:紧邻完整记录,缺口不能当状态机反例 |
[待核]:与观澜 fusion_diag.py 的 3 处滞回实现对照(见 §4 第 4 条 C02) |
| 4 | 相对强度与绝对锚 | "×fleet 很高即严重损伤"被反例(同域能量极弱/共有固有线分母效应);修正:同 shard 能量占比 + 绝对锚 + 空间证据 + 持续性并列;适用域:单场标定阈,未知供应商频率阴性不能销案 | [待核]:观澜融合侧的"相对+绝对"是否并列呈现(与 C05/C04 同源) |
| 5 | 证据独立性 | "谱线+宽带+峭度=三条独立证据"被反例(同测点同信号);修正:信号族合一,独立性须追传感链/事件/时间窗/共同原因/采集触发 | 建议直接采纳 ✓:观澜报告里"多证据"的表述需按此审查(避免把同源信号当独立证据) |
| 6 | 覆盖与缺测传播 | "缺一窗都盲/无判据触发就正常"被反例(部分覆盖被埋进健康);修正:覆盖 ceil(2N/3)、盲区门传导、疑似健康证据撤回;适用域:谱窗与仅标量/原厂状态窗分列,不静默丢窗 |
[待核]:与观澜"不可判/盲区"口径直接相关;结合 §4 第 5 条一起定位持续性/覆盖门 |
| 项 | 结果 |
|---|---|
| 确证真缺陷 | 1 处:app_ontology/app_ontology_guanlan/sop/discriminators.py:1094 陈旧文案(两函数均已实现却写"待实现")—— 本版已修 ✓ |
| 同词不同义(假阳性,已澄清) | 2 处:C04 全盲(指具体全盲台)· A03 滞留(指热滞留) |
| 观澜已优于上游 | 1 处:C01(report_std.py 已同时带 7.1/11 双阈) |
| 不适用(观澜无该实现) | 2 处:B21 四层异常 · D04 gym |
| 列入 backlog(需进一步定位) | 7 处:C05 持续性门位置与窗数口径(优先)· C02 滞回是否被默认链调用 · A03 可用性链路特判 · A04「疑似」措辞与判据 · §5 六条中除"证据独立性"外的 5 条 |
docs/模型谱系与编号_v0.1.md(观澜自口径的 48 类骨架,A01–A05 / B01–B26 / C01–C10 / D01–D03 / D04 / E01–E03 + L0–L5 分层),并在交付文档引入证据标签体例。[INS])。对应 §一 第 5 条(报告 C05)与 §二 第 6 条(TCM 覆盖与缺测传播)。本节为实测定位结果,实现位置与口径均为观澜自身证据。
| 门 | 观澜实现(file:line) | 现行口径 | 与报告 ceil(2N/3) 对照 |
|---|---|---|---|
| 持续性门(A 轴 3 分) | app_ontology/app_ontology_guanlan/sop/vib_confidence.py:146:p = 3.0 * min(persist_windows / max(min(4, n_windows), 1), 1.0) |
分母固定封顶 4;函数默认 n_windows=6 |
仅当 N=6 时 ceil(2·6/3)=4 恰好等价 ✓;N=9 时上游要求 6,观澜仍取 4 ✗ ⇒ 潜在隐患(扩窗即静默放宽) |
| 窗覆盖门(D 轴 10 分) | 同文件 :173:w = 10.0 * min(n_windows_covered / 4.0, 1.0) |
同样 4 封顶 | 同上;且 score_sample() 签名没有 n_windows 参数 ⇒ 无法随窗数伸缩 |
| 盲区门 | 同文件 :168–174:if is_blind: return 0.0 |
盲区台直接 0 分 | 与报告"盲区门传导"一致 ✓ |
| 逐日持续(冲击轴) | app_algorithmModel/.../windcms/report_std.py:187(acute = 持续恶化)、:213(n_high_days_all >= 3) |
3 天门 + 类型枚举(持续恶化/稳定高位/阶跃抬高/反复发作) | 另一轴(逐日),与窗数无关 |
| 比例门(同步/份额) | app_ontology/.../sop/farm_pipeline.py:57 sync_fraction >= 0.5;app_algorithmModel/.../service/fleet_views.py:458 _share >= 0.5 |
0.5 门 | 与"L0 覆盖也是比例门"的精神一致 ✓(观澜已有比例门,只是不在持续性轴上) |
| 实际窗数 | app_ETL/.../builders/baseline_38_build.py:41「本机实况: 只有 w0316 一窗」;component_history_build.py:34「FARMS['rudong']['windows'] 只解析出一个窗」;融合产物 fus.盲区 自述「单窗数据时"逐窗趋势"信息量有限(按日聚合后可见)」 |
当前 1 窗 | ⇒ "四窗当九窗同等证据"的情形在观澜尚未发生 ✗;但门是硬编码 4 ⇒ 扩到 9 窗时会静默放宽 ✗ |
| 是否接入生产链 | score_internal / score_sample 在观澜全仓(排除 .venv/vendor/node_modules)无任何调用点 |
未接线 | 正是报告反复告诫的「函数存在 ≠ 生产链使用」✓ —— 本清单按 [码](存在)记录,不按 [场](已用)记录 |
4 改为随窗数的比例门 —— max(1, ceil(2*n_windows/3))。
理由:N=6 时行为完全不变(ceil(2·6/3)=4)⇒ 零回归;N=9 时自动变为 6,与报告口径一致。
注意:score_sample() 需新增 n_windows 形参(当前签名没有)。fus.盲区 已有同义自述,仅需升格为明文口径)。| 落点 | 内容 |
|---|---|
sop/vib_confidence.py 模块文档 |
修正 P0 后已过时的两处口径行(A 轴「持续≥4/6窗」、D 轴「覆盖窗数≥4」⇒ 均改为 max(4, ceil(2N/3)));并把「窗数口径与单窗拒判」写入模块头 |
scripts/rudong_fusion_handoff.py |
振动 meta 的 纪律 增列窗数口径条款 ⇒ 经 service/fleet_views.py:581 传导到页面 fus.纪律 |
docs/振动六层链_接口规格与缺口_v0.1.md |
新增「窗数口径与拒判条件」节(含门的形式、单窗拒判、不得静默丢窗、当前实况 1 窗、四处出处 file:line) |
| 本清单 | 本节 |
条款要点:① 门 = max(4, ceil(2N/3))(N≤6 恒 4 · N=9 ⇒ 6 · 分母只增不减 ⇒ 不会更宽松);
② N<3 时不得用持续性/逐窗趋势类判据出个体结论,只能标「窗内周段趋势(单窗补充口径,仅参考不作判据)」(与既有降级口径同源);
③ 不得静默丢窗(谱窗与仅标量/原厂状态窗分列,缺窗显式进盲区)。
决定:标注「待接线」(unwired),不擅自接线。 理由:接线会改变报告/页面呈现,属产品决策;而报告告诫的核心风险是"函数存在 ≠ 生产链使用",用明文标注即可消除误读。
| 落点 | 内容 |
|---|---|
sop/vib_confidence.py |
新增常量 WIRING = 'unwired' 与 WIRING_NOTE,并写明:接线实测证据(外部调用 0 处)、接线入口(api.py:45 注册 sop_vib_confidence)、接入前禁令(报告/交付件不得声称已用置信度)、以及接线后须改为 'wired' 并记录接入点与验收证据 |
docs/振动六层链_接口规格与缺口_v0.1.md |
新增「置信度模块接线状态」小节(同步同一事实) |
| 本清单 | 本节 |
实测依据(2026-10-06):score_internal / score_independent / score_falsification / confidence / penalize / band 外部调用 0 处;score_physical、detectability 仅本文件内部使用;模块已在 ontology API 注册(api.py:45)⇒ 具备接线条件但尚未接线。
若日后要真正接线(产品决策,本版未做),需明确三件事:① 消费端(报告等级栏 / 页面字段 / 交付件);② 输入来源(五轴的 A–E 各自取数口径,尤其 B 轴的共时源与 C 轴的实物锚);③ 验收证据(接入点 file:line + 至少一个真实机组的分级结果)。
方法同前:观澜全仓实测(排除 .venv/vendor/node_modules)+命中处逐行看上下文。 标签:
[已实现]观澜已有、[未接线]代码在但无调用、[不适用]观澜无此实现、[提示]仅作适用域提示。
[未接线] + 当前数据下不可实现| 事实 | 证据 |
|---|---|
| 函数存在 | app_ontology/app_ontology_guanlan/sop/fusion_diag.py:88 apply_hysteresis(window_levels, *, h=3);docstring「厂商 Hysteresis=3 的通用化:连续 h 窗同向才改级,否则保持」 |
| 无调用方 | apply_hysteresis 外部调用 0 处;oem_hysteresis 符号在观澜不存在 ✗(此前 3 处命中均为 Hysteresis 关键词,非该符号) |
| 上游输入缺失 | 其入参 window_levels(逐窗 level 序列)无生产端 ✗(level_sequence 命中 0 处)——与上游报告所述「要逐窗序列而全窗裁决不产生该序列」完全一致 |
| 当前数据下不可实现 | 观澜实况 1 窗(baseline_38_build.py:41/component_history_build.py:34/fus.盲区 自述)⇒ 连续 h 窗同向判据无窗可跨 |
处置:按 P2 同法标注「待接线 + 待扩窗(≥2 窗,理想 9 窗)」;不得在报告中称已使用原厂迟滞规则。
[不适用](上游特判)+ 观澜现行口径已明文| 事实 | 证据 |
|---|---|
上游的「告警滞留特判」(l0_view.py:131–156) |
观澜无 l0_view.py 同名模块,亦无「告警滞留」实现 ✗(唯一命中是本清单自身) |
| 观澜现行不可判口径(等价纪律) | app_ETL/.../builders/scada_slim_build.py:19「缺列如实记(columns_missing),不造 0、不静默丢列 —— 各面按列名取,缺了就当"不可判"」 |
| 具体不可判门 | app_ETL/.../builders/pitch_face_build.py:33「消费者的不可判门是 窗内 nop < 144(≈不足 1 天等效)」 |
| 三轴口径 | app_algorithmModel/.../windcms/report_std.py(状态等级 × 证据状态 × 行动等级 + 不可判释义) |
处置:登记观澜现行口径(缺列即不可判 + 三轴),不照搬上游特判;IEPE 绝对链的现场核验仍列 backlog。
[已实现]app_ontology/.../sop/sensor_validation.py:429「疑似同一测量写多列 (仅舍入差) → parity/level/swap 全不可证」;:534「疑似派生/复制相 (rel pair-diff <1e-4):parity 不可证 → INSUFFICIENT」[已实现] ✓app_algorithmModel/.../perf/curves.py:100「显著门 = 物理绝对锚(z 只说"相对同类偏离",定级必须过绝对量;MAD≈0 的镜头会造 z=200 的伪离群)」app_algorithmModel/.../service/fleet_views.py:687「灰域=全场四分位残差带;出带且过锚才算离群」app_algorithmModel/.../subsys/temp_nbm.py:6「⑦相对判据配绝对量(dev 以 K 计,报警需绝对 dev≥4K 非只 z)」;:225「单靠本表最高准定论·预警,升定论须外部绝对锚」app_algorithmModel/.../perf/powercurve.py:3「机舱风=self_ref ⇒ 绝对达成率 INSUFFICIENT 不产出」
⇒ 与报告「相对很强 ≠ 严重损伤;须同 shard 能量占比 / 绝对锚 / 空间证据 / 持续性并列」方向一致 ✓。[已实现] ✓app_ontology/.../sop/discriminators.py:937「疑似同源复制 → 勿当两路独立证据」app_ontology/.../sop/vib_confidence.py 的 PENALTY_KINDS['same_source_multi_stat'] = (-20, '同一路信号的多种统计量当多源')
⇒ 与报告「信号族合一,独立性须追传感链/事件/时间窗/共同原因/采集触发」一致 ✓。[已实现] + 本版 P1 已明文化 ✓scada_slim_build.py:19「缺列如实记、不造 0、不静默丢列」✓fus.纪律/fus.盲区 上线 ✓[提示]CurrentCount 样本身份治理、更无原厂逐测量迟滞读取)app_ontology/.../sop/discriminators.py:4426-4427「(Method=StdDev / StdDevs=3 / TargetCount=15),基线也真的采满了(Active 条目中 CurrentCount<TargetCount 的 = 0,RejectCount 全 0),但最终阈值是手填的全场统一固定值」| 项 | 状态 |
|---|---|
| 第 1 项 · 持续性门/覆盖门定位与窗数口径 | 已完成(2.89.1 定位) |
P0 · 门随窗数伸缩 max(4, ceil(2N/3)) |
已完成(2.89.2) |
P1 · 口径明文化 + 随 fus.纪律/盲区 上线 |
已完成(2.89.3,线上实测条款在场) |
P2 · 置信度接线状态标注 unwired |
已完成(2.89.4) |
| C02 · 滞回接线与逐窗序列 | 已定论:未接线 + 当前 1 窗不可实现 ⇒ 标注「待接线 + 待扩窗」 |
| A03 · 可用性链路特判 | 已定论:上游特判不适用;观澜现行口径(缺列即不可判 + 三轴)已登记 |
| A04 · 「疑似」措辞 | 已定论:观澜已实现(sensor_validation 疑似 → INSUFFICIENT) |
| §5-4 相对强度与绝对锚 | 已实现(四处证据) |
| §5-5 证据独立性 | 已实现(discriminators + vib_confidence 扣分项) |
| §5-6 覆盖与缺测传播 | 已实现 + P1 明文化 |
| §5-1/2/3 TCM 公式与规则 | 未引入(作为适用域提示登记;引入属算法改动,需另立需求) |