Anomalieerkennung · Incident-Bearbeitung
PlantPulse AI erkennt Anomalien, die KI diagnostiziert sie und schlägt Maßnahmen vor, ein Mensch genehmigt und führt die Maßnahme aus, und das Ergebnis wird automatisch verifiziert.
In der Oberfläche heißt ein solcher Vorgang Incident — denn er wird nicht nur durch Ausfälle, sondern auch durch Alarme und Anomaliesignale eröffnet. In Oberflächen vor dem 2026-10-14 erscheint er als «Störungsmeldung». Der Name in API und Konfigurationsschlüsseln lautet incident.
감지 (이상탐지 · 알람 · 고장 전조)
→ 확인할 이상 · 이상 접수 + 알림 (화면 · 메일 · Slack · 푸시)
→ AI 진단 (원인 후보 · 제안 조치)
→ 사람이 승인 (고쳐서 승인 · 거절) · 조치 실행
→ 자동 재발 검증 (기본 1시간 뒤)
→ 결과 기록 · 종결
Was in der Oberfläche geschieht — Prüfen · Genehmigen (Ändern und freigeben · Ablehnen) · Maßnahme ausführen · Ergebnis erfassen · Abschließen — erfolgt vollständig in der Detailansicht eines Vorschlags (/tasks) →
Vorschläge — Aufgaben · Anomalien · Incidents bis zum Abschluss. Diese Seite beschreibt, wann der Server was tut.
Die Menüs «Anomaliediagnose» und «Behebung» sowie die reine Mobilversion (/m) entfallen. Zu prüfende Anomalien und Incidents finden sich unter Vorschläge › Aufgaben › Störfälle,
und die neue Oberfläche lässt sich unverändert auf dem Smartphone nutzen (sie kann als App auf dem Homescreen abgelegt werden). Alte Adressen werden nicht weitergeleitet →
Copilot-Bildschirmübersicht — alte Adressen
Anomalieerkennung — wann was gemessen wird
| Was | Intervall (Standard) | Einstellung |
|---|---|---|
| Vollständiger Durchlauf — alle Anlagen. Sensoren nur bei Anlagen mit zuletzt bewegten Tags | alle 2 Stunden | anomaly.schedule.cron |
| Gezielte Erkennung | alle 10 Minuten | anomaly.targeted.cron |
| ERROR-Alarme empfangen (MQTT-Abonnement) → Incident | laufend (Abonnementprüfung jede Minute) | incident.mqtt.subscribe.cron |
| Ausfallvorboten als Frühwarnung empfangen → Incident | stündlich | incident.precursor.poll.cron |
| Von der Engine selbst erfasste AI-Erkenntnisse empfangen | jede Minute | finding.poll.cron |
Alle Zeitangaben beziehen sich auf die Werkszeitzone der Installation.
Eine Anlage · eine Stunde = eine Zeile
Anlagenanomalien werden pro Anlage und Stunde als eine Zeile festgehalten. Sensor · OEE · RAM · Energie sind Zweige innerhalb dieser Zeile; Titel und Schweregrad ergeben sich aus der Anzahl auffälliger Tags und den Anomalieminuten (Minuten der letzten Stunde, in denen eine Anomalie vorlag).
| Schweregrad | Anomalieminuten der letzten Stunde (Standard) | Einstellung |
|---|---|---|
| Niedrig | ab 10 Minuten — darunter wird keine Zeile angelegt | anomaly.asset.min.minutes |
| Mittel | ab 20 Minuten | anomaly.asset.medium.minutes |
| Hoch | ab 40 Minuten | anomaly.asset.high.minutes |
- Eine Zeile zu prüfende Anomalie im Vorschlag entspricht genau dieser Zeile. Anomalien derselben Ursache werden zu einer Zeile zusammengefasst.
- Anlagen in
anomaly.exclude.assets(StandardTEST_*,ASSET_TEST_*) werden von der Erkennung ausgenommen. - Welche Erkennung greift, richtet sich nach der je Anlage von der Engine bestimmten Eignung — Sensorerkennung · Produktion (OEE · RAM · Fertigungsaufträge) · Energie. Anlagen ohne passende Erkennung werden übersprungen.
- Schwellen:
anomaly.detector.score.threshold(Sensorik, leer = Engine-Standardwert) ·anomaly.detector.domain.score.threshold(übrige, Standard 0.5). Anlagenspezifische Sensorschwellen passt die KI selbstständig an → AI-Erkenntnisse und Genauigkeit
Frühwarnung bei Ausfallvorboten
Die Zeitreihen-Engine vergleicht den aktuellen Signalverlauf mit Verlaufsmustern unmittelbar vor früheren ERROR-Alarmen und bewertet so das Ausfallrisiko. Der Copilot übernimmt dieses Ergebnis stündlich und legt einen Störungs-Incident an — der Incident entsteht also nicht erst, wenn die Anomalie «bereits eingetreten» ist, sondern bei «Anzeichen dafür». In der Abfrage lässt sich auch direkt fragen: «Prüfe das Ausfallvorboten-Risiko dieser Anlage» → Zeitreihen-Insight
Wie ein Incident entsteht
| Weg | Bedingung |
|---|---|
| Anlagenanomalie | automatisch ab Schweregrad Hoch (Untergrenze incident.source.anomaly.minSeverity) |
| ERROR-Alarm | unmittelbar beim Empfang eines Plattform-Alarms |
| Ausfallvorbote | siehe Frühwarnung oben |
| Mensch | über Als Incident anlegen bei einer zu prüfenden Anomalie im Vorschlag |
| Automatisierung | wenn ein Mensch die vom Automatisierungsergebnis angehängte Aktion Incident anlegen genehmigt → Automatisierung — Genehmigungsaktionen |
- Ist dasselbe Problem bereits offen, wird kein neuer Vorgang erzeugt, sondern in den bestehenden Incident zusammengeführt (nur der Ereigniszähler steigt).
- Ein entstandener Incident geht in die Diagnosewarteschlange; die KI diagnostiziert ihn der Reihe nach (Ursachenvermutung und bis zu vier Maßnahmenvorschläge).
- Pro Quelle ein- und ausschaltbar —
incident.enabled·incident.source.*. - Der frühere Watch entfällt und legt keine Incidents mehr an. Zuvor von Watch angelegte Incidents bleiben erhalten → Automatisierung
Benachrichtigungskanäle
| Kanal | Empfangsbedingung | Einstellung |
|---|---|---|
Oberfläche — Glockensymbol in der Seitenleiste und Benachrichtigungsliste (/alerts) | immer. Zu prüfende Anomalien · Incidents im Bereich der letzten 24 Stunden | — |
| Push — Smartphone · Browser | ab Schweregrad Hoch (Standard). Je Gerät unter Einstellungen › Benachrichtigungen aktivieren | push.enabled · push.notify.severity |
| wenn Empfänger und Stufe konfiguriert sind | anomaly.notify.email.* · incident.notify.email.* | |
| Slack | wenn Webhook und Stufe konfiguriert sind | anomaly.notify.slack.* · incident.notify.slack.* |
- Oberflächenbenachrichtigungen und Push gehen je Person nur für Anlagen im jeweiligen Zuständigkeitsbereich ein.
- Push wird unter Einstellungen (
/settings) › Benachrichtigungen › Smartphone-/Browser-Benachrichtigungen aktiviert. Dies funktioniert nur unter einer HTTPS-Adresse, auf iPhone und iPad nur in der auf dem Homescreen abgelegten App → Copilot-Bildschirmübersicht — Einstellungen · Copilot öffnen - Ein Tippen auf die Push-Benachrichtigung öffnet Vorschläge › Aufgaben › Störfälle. Alte Links aus früheren Benachrichtigungen oder E-Mails werden nicht weitergeleitet und zeigen «Seite nicht gefunden» — die Vorgänge sind über Vorschläge zu finden.
- E-Mail und Slack für Anomalie- und Incident-Benachrichtigungen werden in den Systemeinstellungen der Admin-Konsole (
/admin/config) über die obigen Schlüssel festgelegt → Copilot-Admin-Konsole
Die unter Benachrichtigungskanäle (/admin/channels) in der Admin-Konsole registrierten Teams- und Slack-Kanäle sowie die zugelassenen E-Mail-Domänen werden vom «Senden» der Automatisierung genutzt —
wenn eine Automatisierung Ergebnisse an Messenger-Kanäle oder interne E-Mail-Adressen sendet, geschieht dies ausschließlich über die hier registrierten Kanäle und zugelassenen Domänen. Die Anomalie- und Incident-Benachrichtigungen aus der obigen Tabelle nutzen diese Seite nicht, sondern
die Schlüssel der Systemeinstellungen (Messenger = Slack-Webhook). → Copilot-Admin-Konsole · Automatisierung — Senden
Vier Maßnahmentypen — was bei der Ausführung tatsächlich passiert
Die KI-Diagnose schlägt Maßnahmen in vier Typen vor; ein Klick auf Maßnahme ausführen in der Vorschlagsdetailansicht löst Folgendes aus.
| Typ | Was beim Klick tatsächlich passiert |
|---|---|
Alarm quittieren (ack_alarm) | Der betreffende Plattform-Alarm wird quittiert |
Zuständige benachrichtigen (notify) | An den Empfänger (siehe unten) geht eine E-Mail mit der Incident-Zusammenfassung. In Installationen ohne Mailserver (SMTP) nicht ausführbar (siehe unten) |
Vor-Ort-Inspektion beauftragen (inspect) | Es wird eine Inspektionskarte im Ausführungsvorschlag erstellt, der Empfänger (siehe unten) zugewiesen und eine E-Mail mit Link zur Ergebniserfassung versendet. Die E-Mail ist nur ein Zusatz — auch ohne SMTP wird die Karte erstellt |
Weitere Untersuchung (investigate) | Keine nach außen gerichtete Aktion — es wird lediglich festgehalten, dass «der Untersuchungspunkt aufgenommen wurde», samt Ausführendem und Zeitpunkt |
- Empfänger — wer Benachrichtigung · Inspektion erhält, stammt aus der Liste Zuständige der Admin-Konsole (unabhängig von Anmeldekonten). Automatisch festgelegt wird nur, wenn es genau eine Person gibt, deren Benachrichtigungsrolle der Rolle des Maßnahmenvorschlags (Instandhaltung · Betrieb · Sicherheit) entspricht und deren Zuständigkeitsbereich (Standort · Anlage — leer bedeutet alles) diesen Incident abdeckt. Gibt es keine oder mehrere, wird nicht ausgeführt; die ausführende Person wählt im Bildschirm. Ein Versand an «die erste Person der Liste» findet nicht statt → Copilot-Admin-Konsole — Zuständige
- Installationen ohne SMTP — ist der Mailserver (
smtp.host·smtp.username) leer, ist Zuständige benachrichtigen in dieser Installation nicht verfügbar. Auch die KI-Diagnose wird angewiesen, diese Maßnahme nicht vorzuschlagen; dennoch erscheinende Benachrichtigungsmaßnahmen werden im Bildschirm mit Begründung blockiert und hinterlassen keinen Fehlschlag-Eintrag — egal wie oft man klickt. Es wird nicht auf einen anderen Kanal ausgewichen. Lehnt der Mailserver den Versand ab, schlägt die Maßnahme mit «Der Mailserver konnte die Benachrichtigungs-E-Mail nicht senden (…). Prüfen Sie die Mail-Einstellungen.» fehl → Systemeinstellungen - Wer — die Schaltfläche sehen nur Personen mit der Berechtigung «Maßnahme ausführen» (
approve:incident_action) (Standard: Schichtführer · Instandhaltung · Werkleiter · Administrator) → Berechtigungen Freigeben · Ändern und freigeben · Ablehnen des Maßnahmenvorschlags kann jede Person, die Incidents einsehen darf (menu:resolve) → Vorschläge — Maßnahmenvorschlag prüfen - Doppelausführungsschutz — klicken zwei Personen gleichzeitig, wird nur einmal ausgeführt. Bereits ausgeführte Maßnahmen lassen sich nicht erneut ausführen, nur fehlgeschlagene.
- Sicherheitsrahmen — Steuerbefehle an Anlagen sind nicht ausführbar. Ausgeführt werden nur umkehrbare Maßnahmen wie Alarmquittierung, Benachrichtigung oder Kartenerstellung.
- Ausführung, Fehlschlag und Abschluss werden sämtlich im Verlauf der Detailansicht mit Ausführendem und Zeitpunkt protokolliert.
- Zuständige, die eine Inspektionsauftrags-E-Mail erhalten, erfassen das Ergebnis (Erledigt · Nicht zutreffend samt Notiz) über den Link in der E-Mail ohne Anmeldung.
Automatische Wiederholungsprüfung
Nach Ausführung einer Maßnahme prüft der Server eine Stunde später (Standard, incident.verify.delay.minutes = 60) selbstständig, ob an derselben Anlage erneut eine Anomalie aufgetreten ist. Die Prüfung läuft stündlich.
| Ergebnis | Oberfläche |
|---|---|
| Kein Wiederauftreten | Im Tab Abgeschlossen als «kein Wiederauftreten»; fließt in den Wert Verifizierung bestanden % der Kopfzeile ein |
| Wiederauftreten | Im Tab Abgeschlossen als «Wiederauftreten» gekennzeichnet; fließt in die Anzahl Wiederauftreten der Kopfzeile ein — ein Signal, dass weitere Maßnahmen nötig sind |
Die Kopfzeile des Tabs Abgeschlossen im Vorschlag (Maßnahmen · Bearbeitungszeit · Verifizierung bestanden · Wiederauftreten · Ergebnis ausstehend) bildet die Bilanz dieser Verifizierung.
Unbearbeitete Incidents schließen sich selbst
| Fall | Standard | Einstellung |
|---|---|---|
| Durch Anomalieerkennung angelegter Incident (noch von niemandem übernommen) bleibt ohne Wiederauftreten ruhig | nach 6 Stunden Abschluss als «behoben» | incident.autoresolve.quiet.hours |
| In Bearbeitung befindlicher Incident ohne Wiederauftreten und ohne Statusänderung überaltert | Abschluss nach 7 Tagen | incident.stale.close.days |
| Incident ohne erfolgte Diagnose | Abschluss nach 24 Stunden | incident.diagnose.expire.hours |
Bei Werten ≤ 0 sind die ersten beiden deaktiviert. Der Abschluss wird im Verlauf festgehalten.
Maßnahmen ausgehend von AI-Erkenntnissen
Auch die von der Zeitreihen-Engine selbst gefundenen AI-Erkenntnisse (Auftragsziel verfehlt · Wiederherstellungsvorschlag bei Teileverzug · Ausfallrisiko …) folgen demselben Grundsatz — die KI schlägt vor, der Mensch entscheidet. Keine Schaltfläche steuert eine Anlage oder verändert Aufträge oder Termine. Arten der Erkenntnisse und Benachrichtigungsregeln stehen unter AI-Erkenntnisse und Genauigkeit.
AI-Vorschlagskarte — Annehmen · Ablehnen · Wirkung
Erkenntnisse, die eine menschliche Entscheidung erfordern — Auftragsziel verfehlt · Wiederherstellungsvorschlag bei Teileverzug · Ausfallrisiko — erscheinen unter Vorschläge › Planung als AI-Vorschlagskarte (Ausfallrisiko nur, wenn diese Bewertung Vor-Ort aktiviert ist). Im Feld AI-Vorschlagsentscheidung der Detailansicht wird angenommen oder abgelehnt; nach Annahme wird wirksam · nicht wirksam · noch unklar hinterlegt → Vorschläge — AI-Vorschlagsentscheidung
- Annahme und Ablehnung werden nur protokolliert — Aufträge, Termine und Anlagen ändern sich dadurch nicht automatisch.
- Erkenntnisse derselben Anlage und derselben Art werden am selben Tag zu einer Karte zusammengefasst.
- Karten, deren zusammengefasste Erkenntnisse alle geschlossen sind und die niemand bearbeitet hat, verschwinden aus der Liste (die Protokollierung bleibt).
Automatische Prüfung nach der Reparatur
Wird als Ablehnungsgrund «Bereits erledigt» gewählt, misst der Server selbstständig, ob die Maßnahme gewirkt hat (finding.repair.enabled, standardmäßig aktiv).
| Ergebnis | Bedeutung |
|---|---|
| Wirkung bestätigt | Der Tag ist in den Sollbereich zurückgekehrt oder die Bedingung hat sich aufgelöst und ist nicht erneut aufgetreten |
| Keine Wirkung | Dieselbe Anomalie ist erneut aufgetreten oder der Tag liegt weiterhin außerhalb des Sollbereichs |
| Nicht beurteilbar | Es lagen zu wenige Betriebsdaten vor oder die Auflösung der Bedingung konnte nicht bestätigt werden |
Die Prüfdauer hängt von der Art ab — meist 30 Minuten Stabilisierung + 120 Minuten Prüfung, bei Datenabrissen und Lastspitzen 15 + 60 Minuten. Das Ergebnis wird als Wirkungsnachweis des Vorschlags protokolliert und überschreibt keine von Menschen gesetzten Markierungen.
Genehmigung → Entwurf
Entspricht ein Vorschlag einer Aktion in einem anderen System, erscheint auf der Karte das Feld Bei Genehmigung erzeugter Entwurf. Derzeit sind zwei Aktionen angebunden.
| Vorschlag | Was erzeugt wird | Zielsystem |
|---|---|---|
| Wiederherstellungsvorschlag bei Teileverzug | Entwurf einer Mahnungsanforderung für die Bestellposition | Supply Chain (SCM) |
| Ausfallrisiko | Instandhaltungsanforderung für die Anlage | MES |
- Der zugehörige aktive Konnektor muss im Digital Thread registriert sein. Fehlt er, bietet die Karte nur Annehmen · Ablehnen · Wirkung.
- Erzeugt wird genau ein Entwurf bzw. eine Anforderung im Zielsystem. Die Bestätigung erfolgt dort durch einen Menschen. Auch bei zweifacher Genehmigung desselben Vorschlags entsteht nur ein Entwurf.
- Genehmigungsgründe, Vier-Augen-Genehmigung und Berechtigungen siehe Vorschläge — Bei Genehmigung erzeugter Entwurf.
- Die Konnektorregistrierung erfolgt im Digital Thread der AI-Admin-Konsole → Digital Thread
Verwandte Dokumente
- Vorschläge — Prüfen · Genehmigen · Maßnahme · Ergebnis · Abschluss in der Oberfläche
- AI-Erkenntnisse und Genauigkeit
- Automatisierung — Automatisierungen, die bei neuen Incidents anlaufen (Alarmausführung)
- Copilot-Admin-Konsole — Zuständige · Systemeinstellungen · Kritikalitätsstufen von Anlagen