

关键基础设施
有关远程站点和网络连接的内容请参见本页。如果您担心的是套餐、违约金和市场情况,请从这里开始: 能源 →
用了很多年的老设备,故障方式是表格预测不出来的。监测必须迁就资产的现状。
资产负责人管线、变电站和泵站远离可靠网络。云优先的工具,恰恰在最关键的时刻失明。
现场工程师定期巡检看不到巡检间隔里发生的劣化,而风险最高的资产往往最难抵达。
巡检负责人把关键运营放在租来的看板上,意味着您的可见性止步于厂商 API 的边界。
运营总监
最先发生的变化
远端资产不再是盲区
状态在站点本地采集并排序,劣化在出车之前就能看见,而不是等故障之后。
断链不再等于丢数据
站点在离线期间继续监测、继续记录,等链路恢复再同步。
告警以一个判定收尾
每条异常都以具名工程师的判定结束,结果是真实、暂缓或误报,并记在该条目上。
工作从哪里漏掉,我们又构建什么
用了很多年的设备,坏法从来不在那张表格的预料之内
基于您的振动、温度、电流传感器数据建模,在劣化演变成停运之前预警。用您的资产训练,在您的硬件上运行。
您的维护工程师对每条异常做出采纳、暂缓或标记误报的判定。每一次判定都被记录。
真正要紧的那条告警,淹在一堆不要紧的里面
智能体盯遥测、关联告警、为调度室人员起草事件摘要。每一步操作仍由人掌控。
由控制室来决定。智能体只做关联和起草,绝不代为确认或清除告警。
远端站点偏偏在链路断掉的时候变成瞎子
推理在站点上运行。默认情况下采用本地运行模式,并在网络连接允许时进行同步。
同步什么、什么时候同步,由您来定。本地运行是常态,而不是兜底。
风险最高的资产,往往也是最难抵达的
基于摄像头与无人机影像,对线路、管道和构筑物做缺陷检测。这是我们所建监测系统中的一项辅助能力。
在生成任何工单之前,每一处检出都由巡检人员确认。
与系统共度的一周
- 星期一
- 网络末端的一台泵取流高于上个月。站点里的盒子已经看到了,并附上了趋势。
- 星期二
- 通往那个站点的链路整个下午都断着。站点继续监测、继续记录,恢复后再同步。
- 星期三
- 同一条馈线上的一簇告警被关联成一份摘要草稿,交由控制室采纳或驳回。
- 星期四
- 一张巡检图像显示某处结构存在缺陷,而那里本来好几周都排不上巡检。您的工程师确认后开出工单。
- 星期五
- 站点报告自己写好,每条告警都带着工程师的判定:真实还是误报。
示例说明。此处内容均非实际测量结果。
我们会和您一起盯的指标
| 我们关注什么 | 如何衡量 | 基线 |
|---|---|---|
| 每台资产每个周期的非计划停运小时 | 自动状态采集,而不是靠操作员回忆。 | 今天靠纸面估算,而第一个诚实数字通常比旧数字更难看。 |
| 告警准确度 | 工程师确认为真实的异常与发出的异常之比。 | 通常没有度量,而它恰恰是决定这套系统能否被用起来的目标。 |
| 从异常到留下判定的时长 | 异常时间戳,与具名工程师做出判定的时间戳。 | 今天看不见,因为判定根本没有被记录在任何地方。 |
| 由状态证据触发的工单占比 | “工单来源”字段,已设为必填项。 | 往往全部来自计划或故障,因为没有任何东西把证据带过去。 |
| 断网条件下的持续能力 | 监测不中断的站点离线运行小时数。 | 只写在产品说明书里,从来没真正测过。 |
运营方常问的问题
网络断了,监测还能继续运行吗?
可以。这本来就是我们出发时的设计约束。推理在站点本地运行;链路恢复后数据再同步。运行在离线状态下照常继续。
预测性维护在实际中怎么跑?
视情况而定:取决于您的资产。准确度是在您的资产上实测出来的,不是从宣传册上抄的。我们对您的传感历史建模,在故障之前标出劣化,并把告警接进您团队已经在用的流程。
系统是我们买断,还是租用?
您是所有者。软件、模型和配置将连同相关文档一并交付至您的环境,并完成交接。支持合同可选。


