ENERGY / DOMAIN MODEL LAB
让数据有归属，
让变化有解释。
一座共享冷站，两个机房，六层对象。
沿着同一场景，观察模型如何组织系统、时间与证据。
对象设计 · 交互图形推演
点击图中对象，展开它的含义。
概念依据项目设计讨论 S1–S8。这里的快照、片段边界、模式归属与事件均为教学编排，不代表算法识别或生产验证；稳定片段内仍可存在约 40 分钟功率周期。
辅助实验 / 全天功率与室外温度 展开曲线、缩放与数值气泡
观察周期与温度的合成关系；这里的阈值标签与上方的领域模式是不同层次。
DATA CENTER HVAC / AC-01
一台设备的 24 小时
时间轴：滚轮缩放 · 鼠标拖动平移 · 悬浮查看数值 · 纵轴刻度保持不变
FOLLOW THE SAME DATA
从身份到观测
所有数字均来自当前合成示例。
TWO TIME SCALES
短周期起伏，
叠加全天温度变化。
本演示以约 40 分钟为基准，展示机房空调持续用电中的周期起伏。全天图看慢趋势，四小时视图看单个周期。
教学设定：26°C 对应 40 分钟周期；温度每升高 1°C，功率基线上移 1.4 kW、振幅增加 0.25 kW、周期缩短 0.6 分钟（限制在 30–50 分钟）。室外日温围绕基准日均温度平滑变化，约 15 时达峰。额外温升叠加后，实际全天均温也会升高。“午后额外升温”会在此基础上增加一段温升。
这些数值和温度响应方向是合成演示假设。实际关系还取决于空调类型、控制策略、IT 负荷和室内设定，不能只凭室外温度确定。40 分钟分片也不等于实际周期边界。
功率（kW）描述用电强度，用电量（kWh）是功率随时间的累计。本演示每点代表 5 分钟平均功率；只累计已知区间，不用缺失数据推算完整全天用电量。“周期高位/低位”只是相对温度基线的位置，不代表开关机、异常或效率。
理论可视化 · 合成数据。温度基线是本示例的已知构造，实际系统需估计并验证基线。阶段编号不是研发版本号，本页不提供真实诊断或节能收益证明。
THE DESIGN BEHIND THE MODEL
对象不是先画出来的，
是被问题一步步推出来的。
从“这个值属于谁”，到“这次变化凭什么成立”。
展开六段推导，看看每次设计增加了什么，又修正了什么。
依据项目设计讨论整理 · 六步为阅读顺序，不代表已核实的发布版本。图中的机房、时间和模式均为教学示例；不代表生产系统已实现。
01先让一个数值有身份测点描述 / Observation · 从数值到可追溯事实
最初的问题
一条“功率 52 kW”还不足以进入模型：属于哪台设备？什么时候测到？是否过期？另一个同名测点会不会被混进来？
对象如何形成
将“测量什么”的身份与“这次测到了什么”的记录分开理解。观测携带设备与信号标识、单位、事件时间、接收时间和质量，让后续计算能回到原始证据。
依据 S1 / 统一观测事件对象关系 · 教学归纳
含义 / 单位
值 / 来源 / 质量
例如：机房 A 的功率点与机房 B 的同名点各自保留身份；10:00 测得、10:03 收到，两个时间都保留。
有数值不等于可信。缺失、过期与估计值必须显式表达，不能把空缺填成“正常”。
02设备清单解释不了热量去向CoolingTopology · 从设备类型到角色与连接
为什么继续扩展
“几台空调、几台水泵”描述了数量，却没有说明谁给谁供冷。直接按风冷、水冷各做一套模型，会重复上层概念。
引入拓扑对象
用功能节点、端口和连接描述热量与介质路径。设备类型说明实现方式，角色说明承担什么任务，能力说明能做什么。
依据 S2 / Cooling Topology · S7 / 角色与能力热量传递方向 · 简化示意
对象词汇：technology（实现）、role（角色）、capability（能力）、port（端口）、edge（域内连接）、binding（域间服务）。
统一核心对象仍需保留设备差异。新的制冷技术可能需要扩展角色、端口和能力。
03一次关键修正：物理相连，控制未必同域Room / Source / Binding · 从一条物理链到两个控制边界
原设计哪里不够
如果把机房、末端、水系统和冷站全部装进一个控制域，就容易忽略共享冷站同时服务多个机房的事实。
修正后的对象
RoomCoolingDomain 管机房末端；CoolingSourceDomain 管供冷侧；CoolingServiceBinding 描述供冷服务关系。机房通过 CoolingSupplyState 理解供冷条件。
依据 S3 / 控制边界修正 · S8 / 架构基线讨论共享冷源 · 服务关系（箭头为供冷方向）
↓ CoolingServiceBinding ↓
CRAC 与 CRAH 在机房侧归为 RoomCoolingUnit：都能承担制冷、送风意图，执行时仍分别对应压缩机/设定值或水阀等能力。
冷站调整对机房是外部供冷边界变化，不能记成机房自己的动作。
04从“这一刻”走向“一段运行”StateSnapshot → StateSegment · 从时间对齐到边界识别
单个测点还缺什么
功率、温度、设备状态可能在不同时间到达。先重建同一状态时刻的多变量快照，并保留实测、派生、估计的区别与质量。
为什么需要片段
StateSnapshot 回答某时刻的状态；StateSegment 描述连续运行区间。片段边界结合控制事件、物理变化、统计变化与数据质量识别。
依据 S4 / 状态重建 · S5 / 快照与分段同一条时间线 · 示例时间
10:15 动作发生：可以形成边界，但不意味着 10:15 已进入新的稳定状态。系统还可能处于响应中、不稳定或未知。
固定 40 分钟分片只是观察窗口，不等于稳定片段；上方合成曲线的阈值分段是入门演示，未实现这里的多变量边界识别。
05一次片段，不等于一种模式Operational Regime · 从连续区间到历史归纳
片段之后还要回答什么
今天这段运行，与昨天或上周的哪段相似？需要从历史片段归纳可复现、可解释的典型运行模式。
对象职责分开
Segment 是一次有起止时间的发生；Regime 是许多相似片段的模式描述。同一模式可以在不同时段再次出现。
依据 S5 / 历史片段与 Regime多次发生 → 一类模式 → 可以再识别
相近负载、温度与设备组合
适用条件与识别依据
举例：同为 52 kW，IT 负载、室外温度或运行台数不同，可能属于不同模式，不能只靠功率阈值命名。
上方“周期高位 / 低位”不等于 Regime；这里没有训练或验证真实模式，也不据此标注“高效”。
06最后追问：这次变化凭什么成立？TransitionEpisode / Evidence · 从前后差异到完整过程
只有 A → B 不够
状态改变可能伴随本域动作、冷源变化、室外温度变化或人工操作。前后数值不同，还无法说明是谁造成的。
给迁移一个过程对象
TransitionEpisode 串起前段、响应窗口、后段，并关联动作回执、供冷边界、外部扰动和证据。StateChange 先记录变化事实；有足够支持后才讨论归因。
依据 S6 / 迁移与证据一次迁移的证据结构
反例：调整设定后功率下降，但动作回执缺失且室外同时降温。此时保留状态变化及证据缺口，不能宣称该动作导致节能。
本页展示对象如何组织推理，未进行因果验证。优化建议、执行策略与实际收益验证属于后续环节。
这条设计主线的落点
先说明系统由什么组成、谁能控制什么，再描述状态如何持续、如何变化，以及每个解释有哪些证据。
资料依据与展示边界
来源为项目所有者提供的设计讨论，以下是内容索引。公开展示只保留概念摘要，原始讨论不在此下载；这些讨论本身不证明生产实现或节能效果。
- S1 ·《千点位数据中心数据管道具体设计》：观测事件、时间与质量。
- S2 ·《从设备枚举升级成 Cooling Topology》：热力角色与连接。
- S3 ·《热力物理链路与实际控制边界》：机房域、冷源域及服务关系修正。
- S4 ·《Frontend v0.2：Cooling State》：状态重建与来源区分。
- S5 ·《StateSnapshot → StateSegment → Regime 的正式机制》：快照、片段、模式。
- S6 ·《Frontend v0.4 — Transition》：迁移过程、作用域及归因边界。
- S7 ·《前端驱动的领域模型验证 01.01.00》：设备实现、角色与能力。
- S8 ·《前端驱动的领域模型验证 00.00.00》：架构主线与职责分工。