Anomaly Detection · Incident Response
PlantPulse AI detects anomalies, diagnoses them with AI and proposes actions, has a person approve the action for execution, and then verifies the result automatically.
In the UI this case is called an incident — because it is opened not only by failures but also by alarms and anomaly signals. Screens from before 2026-10-14 show it as «Breakdown report». The name used in the API and config keys is incident.
감지 (이상탐지 · 알람 · 고장 전조)
→ 확인할 이상 · 이상 접수 + 알림 (화면 · 메일 · Slack · 푸시)
→ AI 진단 (원인 후보 · 제안 조치)
→ 사람이 승인 (고쳐서 승인 · 거절) · 조치 실행
→ 자동 재발 검증 (기본 1시간 뒤)
→ 결과 기록 · 종결
What you do in the UI — check, approve (edit and approve · reject), execute the action, record the result, close — all happens in a single detail view of Proposals (/tasks) →
Proposals — Tasks, anomalies and incidents from start to finish. This page describes what the server does, and when, behind it.
The «Anomaly Diagnosis» and «Resolution» menus and the mobile-only version (/m) are gone. Anomalies to check and incidents live under Proposals › Tasks › Unplanned,
and the new screen works as-is on a phone (you can add it to the home screen as an app). Old URLs do not redirect →
Copilot screen map — Old URLs
Anomaly detection — what is measured, and when
| What | Interval (default) | Setting |
|---|---|---|
| Full sweep — all equipment. For sensors, only equipment whose tags moved recently | Every 2 hours | anomaly.schedule.cron |
| Targeted detection | Every 10 minutes | anomaly.targeted.cron |
| Receive ERROR alarms (MQTT subscription) → incident | Continuous (subscription checked every minute) | incident.mqtt.subscribe.cron |
| Receive failure precursor early warnings → incident | Hourly | incident.precursor.poll.cron |
| Receive AI findings written by the engine itself | Every minute | finding.poll.cron |
All times are based on the installation's plant time zone.
One equipment · one hour = one row
An equipment anomaly is recorded as one row per equipment per hour. Sensor, OEE, RAM and energy are branches within that row; the title and severity are determined by the number of anomalous tags and the anomalous minutes (the minutes within the last hour that were anomalous).
| Severity | Anomalous minutes in the last hour (default) | Setting |
|---|---|---|
| Low | 10 minutes or more — below this, no row is recorded | anomaly.asset.min.minutes |
| Medium | 20 minutes or more | anomaly.asset.medium.minutes |
| High | 40 minutes or more | anomaly.asset.high.minutes |
- A single anomaly to check line in Proposals is this row. Anomalies originating from the same cause are grouped into one line.
- Equipment listed in
anomaly.exclude.assets(defaultTEST_*,ASSET_TEST_*) is excluded from detection. - Detection targets follow the eligibility the engine determines per equipment — sensor detection, production (OEE · RAM · work orders), energy. Equipment with no applicable detection is skipped.
- Thresholds are
anomaly.detector.score.threshold(sensors; leave empty for the engine default) andanomaly.detector.domain.score.threshold(everything else, default 0.5). Per-equipment sensor thresholds are adjusted by the AI itself → AI findings and accuracy
Failure precursor early warning
The time series engine compares the current waveform against a collection of waveforms recorded just before past ERROR alarms to gauge failure risk. The copilot pulls that result hourly and files it as a failure. The incident is created when there is a «sign of» a failure, not after one «has already happened». You can also ask directly in Ask: "Check the failure precursor risk for this equipment" → Time series insight
How an incident is created
| Path | Condition |
|---|---|
| Equipment anomaly | Automatically at severity High or above (lower bound incident.source.anomaly.minSeverity) |
| ERROR alarm | As soon as a platform alarm is received |
| Failure precursor | The early warning above |
| A person | Raise as incident from an anomaly to check in Proposals |
| Automation | When a person approves the Raise incident attached by an automation to its result → Automation — Approval actions |
- If the same problem is already open, no new record is created; it is merged into that incident (only the occurrence count increases).
- A created incident enters the diagnosis queue and the AI diagnoses them in turn (estimated cause plus up to four proposed actions).
- Each source can be turned on or off —
incident.enabled·incident.source.*. - The former Watch is gone and no longer raises incidents. Incidents previously raised by Watch remain as they are → Automation
Notification channels
| Channel | When you receive it | Setting |
|---|---|---|
In-app — the sidebar notification bell and the notification list (/alerts) | Always. Anomalies to check and incidents within your scope from the last 24 hours | — |
| Push — phone · browser | Severity High (default) or above. Enable per device under Settings › Notifications | push.enabled · push.notify.severity |
| When recipients and a severity level are configured | anomaly.notify.email.* · incident.notify.email.* | |
| Slack | When a webhook and a severity level are configured | anomaly.notify.slack.* · incident.notify.slack.* |
- In-app notifications and push go to each person only for items within that person's equipment scope.
- Push is enabled under Settings (
/settings) › Notifications › Phone/Browser notifications. It works only on an HTTPS address, and on iPhone and iPad only from an app added to the home screen → Copilot screen map — Settings · Opening the copilot - Tapping a push notification opens Proposals › Tasks › Unplanned. Old links in previously received notifications and emails do not redirect and show "Screen not found" — find the item in Proposals.
- Email and Slack for anomaly and incident notifications are configured with the keys above under System Settings (
/admin/config) in the admin console → Copilot admin console
The Teams and Slack channels registered under Notification channels (/admin/channels) in the admin console and the allowed email domains are used by the automation «Send» action —
when an automation sends a result to a messenger channel or company email, it can only go to the channels registered and the domains allowed here. The anomaly and incident notifications in the table above do not use this screen;
they follow the System Settings keys (messenger = Slack webhook). → Copilot admin console · Automation — Send
The four action types — what actually happens when you execute
AI diagnosis produces four types of proposed action. Pressing Execute action in the proposal detail does the following.
| Type | What actually happens when you press it |
|---|---|
Acknowledge alarm (ack_alarm) | Acknowledges the corresponding alarm on the Platform |
Notify assignee (notify) | Sends an email with the incident summary to the recipient (below). Cannot run on an installation without a mail server (SMTP) (below) |
Issue field inspection (inspect) | Issues an inspection card in the Execute proposals, assigns the recipient (below), and sends an email containing a link for registering the result. The email is an add-on, so the card is issued even without SMTP |
Further investigation (investigate) | No outbound action — only records the fact that «the investigation item was received», with the executor and timestamp |
- Recipient — the person who receives a notification · inspection comes from the Contacts list in the admin console (separate from login accounts). It is set automatically only when exactly one person has a Notify Role equal to the proposed action's role (maintenance · operations · safety) and a scope (sites · assets — empty means all) covering this incident. If there is none or several, it does not run, and the person running it picks on screen. It is never sent to «the first person on the list» → Copilot admin console — Contacts
- Installations without SMTP — if the mail server (
smtp.host·smtp.username) is empty, Notify assignee cannot be used on this installation. The AI diagnosis is also told not to propose this action, and any notify action that still appears is blocked on screen with the reason and leaves no failure record — it stays the same however many times you press it. It is not rerouted to another channel. If the mail server refuses to send, it fails with "The mail server did not send the notification (…). Check the mail settings." → System Settings - Who — the button is visible only to users with the «Execute action» permission (
approve:incident_action) (by default: line leader, maintenance, plant manager, administrator) → Permissions Approve · edit and approve · reject of the action plan can be done by anyone who can see incidents (menu:resolve) → Proposals — Action Plan Review - Duplicate prevention — if two people press it at the same time, only one execution occurs. An executed action cannot be executed again; only failed actions can be retried.
- Safety scope — equipment control commands are not executable. Only reversible actions such as acknowledging an alarm, notifying, or issuing a card are executed.
- Execution, failure and closure are all recorded in the detail's History with the executor and timestamp.
- An assignee who receives an inspection email registers the result (done · not applicable, plus notes) via the link in the email without logging in.
Automatic recurrence verification
One hour after an action is executed (default, incident.verify.delay.minutes = 60), the server checks by itself whether the anomaly recurred on the same equipment. The check runs hourly.
| Result | UI |
|---|---|
| No recurrence | «No recurrence» in the Done tab; counted in the Verification passed % in the header line |
| Recurrence | Shown as «Recurrence» in the Done tab and counted in the Recurrence figure in the header line — a signal that further response is needed |
The header line of the Done tab in Proposals (actions · handling time · verification passed · recurrence · awaiting result) is the scorecard for this verification.
Untouched incidents close themselves
| Case | Default | Setting |
|---|---|---|
| An incident raised by anomaly detection (not yet picked up by a person) stays quiet with no recurrence | Closed as «Resolved» after 6 hours | incident.autoresolve.quiet.hours |
| An in-progress incident goes stale with no recurrence or status change | Closed after 7 days | incident.stale.close.days |
| An incident left without receiving a diagnosis | Closed after 24 hours | incident.diagnose.expire.hours |
Setting a value of 0 or below turns off the first two. The closure is recorded in the history.
Actions that start from an AI finding
AI findings that the time series engine discovers on its own (order target shortfall · part delay recovery plan · failure risk …) follow the same principle — the AI proposes, the person decides. No button controls equipment or changes an order or schedule. The types of findings and the notification rules are in AI findings and accuracy.
AI proposal cards — accept, reject, effect
Findings that require human judgment — order target shortfall · part delay recovery plan · failure risk — appear as AI proposal cards under Proposals › Plan (failure risk only when that assessment is enabled at the site). In the AI proposal decision field of the detail you accept or reject, and after accepting you record effective · not effective · not yet known → Proposals — AI proposal decision
- Accept and reject are records only — orders, schedules and equipment are not changed automatically.
- Findings of the same type on the same equipment are grouped into one card for that day.
- A card whose grouped findings are all closed and that no person has touched drops off the list (the record remains).
Automatic post-repair verification
If you choose "Already done" as the rejection reason, the server measures by itself whether the action worked (finding.repair.enabled, on by default).
| Result | Meaning |
|---|---|
| Effect confirmed | The tag returned to the reference range, or the condition cleared and did not reappear |
| No effect | The same anomaly reappeared, or the tag remained outside the reference range |
| Inconclusive | There was not enough data during operation, or the condition could not be confirmed as cleared |
The verification time depends on the type — typically 30 minutes of stabilization plus 120 minutes of observation; 15 + 60 minutes for data dropouts and power peaks. The result is recorded as the effect record for that proposal and does not overwrite a mark left by a person.
Approval → draft
When a proposal corresponds to an action in another system, the card gains a Draft created on approval field. Two are currently supported.
| Proposal | What is created | Target |
|---|---|---|
| Part delay recovery plan | Expedite request draft for the purchase order line | Supply chain (SCM) |
| Failure risk | Equipment maintenance request | MES |
- An enabled connector that issues that action must be registered in the digital thread. Without one, the card supports only accept, reject and effect.
- What is created is a single draft or request in that system. Confirmation is done by a person inside that system. Approving the same proposal twice still produces one draft.
- Approval reasons, two-person approval and permissions are covered in Proposals — Draft created on approval.
- Connectors are registered in the digital thread of the AI admin console → Digital thread
Related documents
- Proposals — check, approve, act, record results and close in the UI
- AI findings and accuracy
- Automation — automations that run when a new incident is created (alert execution)
- Copilot admin console — assignees · system settings · equipment criticality levels