异常检测 · 事件响应

PlantPulse AI 会检测异常,由 AI 进行诊断并提出处置建议,经人员批准后执行处置,并自动验证其结果。在界面中,这类条目称为事件 —— 因为它不仅由故障触发,也可能由报警 · 异常信号触发。2026-10-14 之前的界面中显示为«故障受理»。API · 配置键的名称为 incident。

감지 (이상탐지 · 알람 · 고장 전조)
  → 확인할 이상 · 이상 접수 + 알림 (화면 · 메일 · Slack · 푸시)
  → AI 진단 (원인 후보 · 제안 조치)
  → 사람이 승인 (고쳐서 승인 · 거절) · 조치 실행
  → 자동 재발 검증 (기본 1시간 뒤)
  → 결과 기록 · 종결

在界面上完成的工作 —— 确认 · 批准(修改后批准 · 拒绝) · 执行处置 · 记录结果 · 关闭 —— 全部在建议(/tasks)的某一详情页中完成 → 建议 — 把待办 · 异常 · 事件做到底。本页记述其背后服务器在何时做了什么。

相比旧界面的变化

«异常诊断» · «解决»菜单以及移动专用版(/m)已取消。待确认异常与事件位于建议 › 待办 › 突发中, 新界面在手机上也可直接使用(可添加到主屏幕作为应用)。旧地址不会跳转 → Copilot 界面地图 — 旧地址

异常检测 — 何时测什么

内容	周期(默认)	配置
全量扫描 —— 所有设备。传感器仅针对近期标签有变化的设备	每 2 小时	`anomaly.schedule.cron`
定向检测	每 10 分钟	`anomaly.targeted.cron`
接收 ERROR 报警(MQTT 订阅)→ 事件	常驻(订阅检查每分钟)	`incident.mqtt.subscribe.cron`
接收故障前兆早期预警 → 事件	每小时	`incident.precursor.poll.cron`
接收引擎自行记录的 AI 发现	每 1 分钟	`finding.poll.cron`

所有时间均以安装所在工厂时区为准。

一台设备 · 一小时 = 一行

设备异常以每台设备每小时一行的形式记录。传感器 · OEE · RAM · 能源是该行内的分支,标题与严重度由 异常标签数和异常分钟数(最近 1 小时内处于异常的分钟数)决定。

严重度	最近 1 小时的异常分钟数(默认)	配置
低	10 分钟以上 —— 低于此值不生成记录行	`anomaly.asset.min.minutes`
中	20 分钟以上	`anomaly.asset.medium.minutes`
高	40 分钟以上	`anomaly.asset.high.minutes`

建议中的待确认异常一行即对应该记录行。源自同一原因的异常会合并为一行显示。
列入 anomaly.exclude.assets(默认 TEST_*,ASSET_TEST_*)的设备将被排除在检测之外。
检测对象依据引擎对每台设备判定的适用性 —— 传感器检测 · 生产(OEE · RAM · 工单) · 能源。没有任何适用检测的设备将被跳过。
阈值为 anomaly.detector.score.threshold(传感器,留空则使用引擎默认值) · anomaly.detector.domain.score.threshold(其他,默认 0.5)。各设备的传感器阈值由 AI 自行调整 → AI 发现与准确度

故障前兆早期预警

时序引擎将当前波形与历史 ERROR 报警发生前的波形集合进行比对,测算故障风险。Copilot 每小时获取该结果并登记为故障事件 —— 即在异常«尚未发生»而只是«有征兆»时,事件就会先行生成。也可在提问中直接询问「帮我确认这台设备的故障前兆风险」 → 时序洞察

事件的产生途径

途径	条件
设备异常	严重度达到高以上时自动生成(下限 `incident.source.anomaly.minSeverity`)
ERROR 报警	收到平台报警后立即生成
故障前兆	上述早期预警
人工	在建议的待确认异常中点击升级为事件
自动化	人员批准自动化在结果上附加的升级为事件时 → 自动化 — 审批动作

若同一问题已处于打开状态,则不新建而是合并到该事件中(仅发生次数增加)。
新建的事件进入诊断队列,由 AI 依次诊断(推定原因及最多四项处置方案)。
可按来源分别开关 —— incident.enabled · incident.source.*。
原有的**监视(Watch)**已取消,不再生成事件。此前由监视生成的事件仍会保留 → 自动化

通知渠道

渠道	接收条件	配置
界面 —— 侧边栏通知铃与通知列表(`/alerts`)	始终。过去 24 小时内范围内的待确认异常 · 事件	—
推送 —— 手机 · 浏览器	严重度高(默认)以上。需在各设备的设置 › 通知中开启	`push.enabled` · `push.notify.severity`
邮件	已配置收件人 · 等级时	`anomaly.notify.email.` · `incident.notify.email.`
Slack	已配置 Webhook · 等级时	`anomaly.notify.slack.` · `incident.notify.slack.`

界面通知与推送仅发送该人员设备范围内的内容。
开启推送的位置为设置(/settings) › 通知 › 手机·浏览器通知。仅在 HTTPS 地址下可用,iPhone · iPad 仅在添加到主屏幕的应用中可用 → Copilot 界面地图 — 设置 · 如何打开 Copilot
点击推送会打开建议 › 待办 › 突发。此前收到的通知 · 邮件中的旧链接不会跳转,会显示「未找到相应界面」—— 请在建议中查找。
异常 · 事件通知的邮件 · Slack 在管理控制台的系统设置(/admin/config)中通过上述键配置 → Copilot 管理控制台

管理 › 通知渠道是自动化的发送出口

在管理控制台的通知渠道(/admin/channels)中登记的 Teams · Slack 频道与邮件允许域名,供**自动化的«发送»**使用 —— 自动化将结果发送到即时通讯频道 · 公司邮箱时,只会发往此处登记的频道与允许的域名。上表中的异常 · 事件通知不使用该界面, 而是遵循系统设置中的键(即时通讯为 Slack Webhook)。→ Copilot 管理控制台 · 自动化 — 发送

四种处置 —— 执行后实际发生的事

AI 诊断给出的处置方案分为四种类型,在建议详情中点击执行处置后,会发生以下操作。

类型	点击后实际发生的事
报警确认 (`ack_alarm`)	将平台中对应的报警标记为已确认
通知负责人 (`notify`)	向接收人(见下文)发送事件摘要邮件。没有邮件服务器(SMTP)的安装中无法执行(见下文)
现场巡检指令 (`inspect`)	在执行建议中生成巡检卡片并指派接收人(见下文),同时发送含结果登记链接的邮件。邮件只是附带的,因此即使没有 SMTP 也会生成卡片
追加调查 (`investigate`)	不产生任何对外动作 —— 仅记录«已受理调查项»这一事实及执行人 · 时间

接收人 —— 接收通知 · 巡检的人来自管理控制台的负责人名单(与登录账户无关)。只有当处置方案的角色(维修 · 运营 · 安全)与负责人的通知角色相同、且负责范围(站点 · 设备 —— 留空即全部)覆盖该事件的人恰好只有一位时,才会自动确定。没有或有多位时不执行,由执行人在界面中选择。不会发给«名单中的第一个人» → Copilot 管理控制台 — 负责人
没有 SMTP 的安装 —— 邮件服务器(smtp.host · smtp.username)为空时,本安装中无法使用通知负责人。也会告知 AI 诊断不要提出此处置, 即使仍然出现了通知处置,也会在界面中附带原因被拦截,且不留下失败记录 —— 点多少次都一样。不会改用其他渠道发送。邮件服务器拒绝发送时,会以「邮件服务器未能发送通知邮件(…)。请检查邮件设置。」失败 → 系统设置
谁可操作 —— 仅拥有«执行处置»权限(approve:incident_action)的人员可见该按钮(默认为班长 · 维修 · 厂长 · 管理员) → 权限处置方案的批准 · 修改后批准 · 拒绝,凡能查看事件的人(menu:resolve)都可以进行 → 提案 — 处理方案审核
防重复 —— 两人同时点击时只有一方生效。已执行的处置无法再次执行,只有失败的处置可重新执行。
安全范围 —— 设备控制指令不属于可执行对象。仅执行报警确认 · 通知 · 卡片下发等可回退的处置。
执行 · 失败 · 关闭均会连同执行人 · 时间记录在详情的进展中。
收到巡检指令邮件的负责人可通过邮件中的链接免登录登记处置结果(完成 · 不适用及备注)。

自动复发验证

执行处置后,服务器会在一小时后(默认,incident.verify.delay.minutes = 60)自行确认同一设备是否再次出现异常。该检查每小时执行一次。

结果	界面
无复发	在完成页签显示«无复发»,并计入顶部概览行的验证通过 %
复发	在完成页签显示«复发»,并计入顶部概览行的复发件数 —— 表示需要进一步处置

建议的完成页签顶部概览行(处置 · 处理时间 · 验证通过 · 复发 · 待出结果)即为此项验证的成绩。

无人处理的事件会自行关闭

情形	默认	配置
异常检测生成的事件(尚无人接手)且无复发、保持安静	6 小时后以«已消解»关闭	`incident.autoresolve.quiet.hours`
处理中的事件长期无复发 · 无状态变化	7 天后关闭	`incident.stale.close.days`
未获得诊断而遗留的事件	24 小时后关闭	`incident.diagnose.expire.hours`

设为 0 或以下时,前两项关闭功能停用。关闭事实会记录在进展中。

由 AI 发现发起的处置

时序引擎自行发现的 AI 发现(工单目标未达成 · 零部件延迟恢复方案 · 故障风险 …)同样遵循相同原则 —— AI 提出建议,由人决定。 任何按钮都不会控制设备,也不会更改工单 · 排程。发现的种类与通知规则见 AI 发现与准确度。

AI 建议卡片 — 接受 · 拒绝 · 效果

需要人工判断的发现 —— 工单目标未达成 · 零部件延迟恢复方案 · 故障风险 —— 会以 AI 建议卡片出现在建议 › 计划中 (故障风险仅在该判定在现场启用时)。在详情的 AI 建议判定栏中进行接受 · 拒绝,接受后再记录 有效 · 无效 · 尚不确定 → 建议 — AI 建议判定

接受 · 拒绝仅作记录 —— 工单 · 排程 · 设备不会自动变更。
同一设备 · 同一种类的发现在当天会合并为一张卡片。
合并的发现全部关闭且无人处理过的卡片将从列表中移除(记录仍保留)。

维修后自动确认

若拒绝理由选择**「已经处理过」**,服务器会自行判定该处置是否奏效(finding.repair.enabled,默认开启)。

结果	含义
效果已确认	标签已回到基准范围内,或条件解除后未再出现
无效果	同一异常再次出现,或标签仍处于基准范围之外
无法判定	运行中数据不足,或未能确认条件已解除

确认时间因种类而异 —— 通常为稳定化 30 分钟 + 确认 120 分钟,数据中断 · 电力峰值为 15 分钟 + 60 分钟。结果作为该建议的效果记录保留,不会覆盖人员已填写的标记。

批准 → 草稿

当建议对应其他系统中的动作时,卡片上会出现批准后生成的草稿栏。目前支持两种。

建议	生成的内容	目标
零部件延迟恢复方案	采购订单行的催货请求草稿	供应链(SCM)
故障风险	设备维修请求	MES

发出该动作的已启用连接器必须已登记在数字主线中。若没有,卡片只能进行接受 · 拒绝 · 效果记录。
生成的是该系统中的一份草稿 · 请求。最终确认需由人在该系统内完成。同一建议即使批准两次,草稿也只有一份。
批准理由 · 双人批准 · 权限参见建议 — 批准后生成的草稿。
连接器登记在 AI 管理控制台的数字主线中进行 → 数字主线

异常检测 — 何时测什么​

一台设备 · 一小时 = 一行​

故障前兆早期预警​

事件的产生途径​

通知渠道​

四种处置 —— 执行后实际发生的事​

自动复发验证​

无人处理的事件会自行关闭​

由 AI 发现发起的处置​

AI 建议卡片 — 接受 · 拒绝 · 效果​

维修后自动确认​

批准 → 草稿​

相关文档​