Liquid Cooling Loop Monitoring
液冷监控页面如何支持告警排查：关联回路、设备与测点
建设或改造液冷监控页面时，先让一条告警能定位到同一回路、设备与测点，在同一时间窗口核对数据有效性和相关状态，并留下已知变化与待查记录。这样，值班人员才能把“哪个位置出现了什么变化”交给维护人员核查。本文讨论监控界面的查看与记录方法；设备操作、工艺阈值和联锁处置应依照现场制度与专业人员判断。
阅读目录7 个章节
从一条告警开始，固定回路、测点和时间
不要先把全机房所有温度和压力曲线叠在一起。打开一条告警后，先保留来源系统、原始事件编号、发生时间、关联设备、测点和所属回路。若一台设备连接多条回路，还要明确告警来自哪一侧、哪个连接位置，不能仅凭相同的设备名称合并。
页面可同时显示告警发生时的值与当前值，并标明各自时间。当前数值恢复，不代表当时没有异常；当前仍显示旧值，也不能据此认定设备一直保持原状态。回路关系发生过调整时，应保留生效时间，使历史事件仍能回到发生时的设备关系。
如果目前还在盘点DCIM、动环、BMS与设备控制器分别提供哪些数据，可先用DCIM与动环接入清单划清系统责任，再设计本页的单回路查看路径。
把冷却设备、回路和连接点分别对应到页面
回路不等于机房，也不等于某一台泵。建议先用经确认的管路图和设备点表，说明设备属于哪个循环路径、测点位于哪个连接位置。设备名、回路名和测点名可以共同显示，但应保留各自稳定编号，便于从报警列表跳转后仍查看同一对象。
DMTF的《Redfish for Liquid Cooling Equipment》DSP2064 1.1.0在4.2—4.4节分别说明CoolingUnit、CoolingLoop和CoolantConnector：冷却设备、回路及供回液连接有不同的建模职责。该文档是2025-02-05发布的信息性白皮书。这里借它解释对象区分，并不要求项目必须采用Redfish，也不表示下方案例采用该协议。
左右滚动表格，查看完整对照内容。
| 需要区分的对象 | 建议保留的关系 | 页面解决的问题 |
|---|---|---|
| 冷却设备 | 设备编号、类型、运行状态及关联回路 | 确定正在查看哪台泵、散热模组或其他设备。 |
| 循环回路 | 回路编号、设备连接、流向与关系版本 | 限定本次核查的供回液路径，避免混入另一条回路。 |
| 连接位置 | 所属设备、所属回路、供液或回液标识 | 说明压力、温度来自哪一侧，而不是只显示“进液温度”。 |
| 测点与告警 | 测点编号、单位、采集时间、有效性、原始事件编号 | 从异常回到源数据，检查时间与状态是否可用。 |
上表是页面和资料整理建议，不是DMTF对项目交付的强制要求。已有厂商对象编码时，应优先建立对应关系，不必为了换一张界面重新编号全部设备。
先区分数据不可用与过程参数越限
“压力传感器故障”和“压力高”需要保留不同的事件类型。前者提示测量信息可能不可用，后者应来自经确认的测点与告警规则。两种事件可以同时出现；页面应保留来源、时间和原始状态，不能为了减少告警数量把它们合并成一个笼统红点。
左右滚动表格，查看完整对照内容。
| 页面收到的信息 | 应怎样显示 | 下一步核对的证据 |
|---|---|---|
| 通信中断或数据超时 | 标明中断/超时；保留最后有效值及其时间。 | 源端通信状态、采集时间、恢复记录。 |
| 测点故障或无效 | 显示质量状态，避免用无效值表达当前正常工况。 | 设备或采集系统提供的故障码与点位说明。 |
| 过程参数越限 | 显示发生值、单位、规则来源、持续与恢复状态。 | 同一测点的有效数据、规则版本和原始事件。 |
| 设备状态与反馈不同 | 分别保留运行状态、指令状态与反馈状态。 | 各字段定义及更新时间，不用“运行中”替代全部反馈。 |
哪些数据算超时、哪些规则触发越限，应由设备、采集与运维责任方确认。前端不应自行给所有回路套用同一温度、压力或延迟阈值。断线、时间戳与质量状态的链路检查，可继续参考工业实时数据接入指南。
沿同一回路查看，留下可以复查的异常记录
下面用虚构回路“L-A”和测点“T-A”说明页面路径，不对应案例中的真实编号或运行事件。假设T-A产生温度告警，查看顺序可设计为：
- 定位事件：从告警详情进入L-A，突出T-A所在的设备与连接位置，同时保留来源系统和事件编号。
- 确定观察时段：查看事件发生前后经约定长度的时间窗口；曲线保留缺测、迟到和失效标记。
- 核对关联状态：在相同时间窗口查看该回路内已有数据的泵、散热模组与相关测点。供回液数据采集时刻不同，应明确显示差异。
- 记录已知与待查：记录看到的变化、缺失数据和需要现场核查的对象。相关曲线同时变化只能提供线索，不能直接认定故障原因。
- 继续跟踪事件：关联维护记录、确认人员和后续观察结果；区分告警恢复与事项关闭，保留原始事件。
若缺少相邻测点或设备反馈，页面应显示待补项，不用模拟变化补全运行链路。这样形成的记录能说明“查了哪里、有哪些依据、还有什么未知”，便于下一班或设备供应商继续核查。
真实液冷界面展示了哪些观察入口
数据中心液冷智能监控真实案例提供了上述流程总览。图中可以看到设备关系、过程参数、顶部状态卡与报警区，适合用来讨论信息如何放在同一查看入口。图片中的数值和状态属于示例或脱敏展示，不能据此复算实际工况，也不能据此判断控制、联锁或节能效果。
本篇提出的事件定位、历史关系、时间窗口和核查记录，是在既有界面证据基础上给出的设计方法；是否纳入实际开发，应按已有数据与使用需求逐项确定。
把页面开发、数据提供和设备处置分清
液冷监控可以在现有DCIM、BMS、动环或设备系统基础上组织统一视图。设备供应商与运维人员确认回路关系、测点含义、告警规则和现场处置；采集或原系统负责人提供经过授权的数据及异常状态；页面开发负责把对象、数据、事件和记录对应起来。是否需要控制入口，应单独确定，不能因图上有泵或开关就默认包括远程操作。
咨询前可准备一张管路图、一组设备与测点样例、一条脱敏告警及其前后数据，以及现有页面中最难核查的问题。根据这些资料，可约定交付回路与点位对应表、页面原型、状态说明、接口适配范围和代表性事件测试记录；具体文件、系统改造与现场工作由项目范围确定。
平台范围可先看数据中心数字孪生方案，设计与开发能力见数字孪生服务和数据可视化开发服务。已有液冷监控系统需要补充回路查看或告警关联时，可以带上脱敏样例沟通具体改动。
其他设备系统若有类似的回路、测点与异常关联需求，也可结合实际资料评估页面范围，不限于液冷机房。
常见问题
已有DCIM，还需要重新建设整套液冷监控吗？
不一定。先确认已有系统能否提供回路、连接点、测点质量和告警记录。如果主要缺口是这些信息分散在不同页面，可以先评估统一查看与关联功能，保留原系统的数据和控制职责。
看到温度高或压力低，页面能直接判断设备故障吗？
不能只凭一个数值判断。应先核对回路位置、数据有效性、事件时段与关联状态，再由专业人员结合现场资料判断；页面负责呈现证据，不自行给出设备操作结论。
只有流程图和少量点位，可以先做什么？
可以先用明确标注的样例验证回路定位、异常状态和记录路径，并列出缺失点位及提供责任。现场运行能力应等待真实数据与约定测试确认后再判断。