Zeitreihen-Insight-Tools (39)

Dies sind die 39 Tools, die der Zeitreihen-Insight-Server über MCP bereitstellt (2026.10 — zu den 33 von 2026.09 kamen sechs Tools für KI-Entdeckung und Produktionsanalyse hinzu). Im Chat werden sie mit vorangestelltem insight_ aufgerufen, etwa so: insight_analyze_asset.

Nicht alle 39 sind eingeschaltet

Anfangs eingeschaltet sind 34 (2026.10 Re-Release (2026-10-20), Richtlinie des MCP Gateway). Ausgeschaltet kommen vier herein — forecast_order_completion · autonomy_status · get_oee_losses · get_spc_chart —, und das schreibende Tool trigger_feature_pipeline lässt sich nicht einschalten. Ein- und ausgeschaltet wird unter AI-Verwaltungskonsole › MCP Gateway › Tools → MCP Gateway

Auch wenn so viele eingeschaltet sind, erhält das Modell nicht bei jeder Frage alle — die Werkzeugsuche des Gateway wählt bis zu 20 zur Frage passende aus → MCP-Werkzeugkarte
Neue Tools des Zeitreihen-Insight kommen ausgeschaltet herein. Vom Administrator einmal geänderte Werte werden nicht überschrieben.
Bis Re-Release 8 hielt der Copilot Ein/Aus selbst und schaltete nur wenige wie get_attention_ranking ein. Diese Werte werden nicht übernommen.

Auswahl nach gewünschter Frage

Was Sie fragen möchten	Tool
Ist diese Anlage gerade in Ordnung	`analyze_asset` · `get_asset_health`
Warum ist etwas auffällig	`explain_asset_anomaly` · `analyze_alarm_correlation`
Gab es das schon einmal	`find_similar_anomalies` · `search_pattern`
Deutet sich ein Ausfall an	`check_failure_precursor` · `forecast_*`
Betrifft das auch andere Anlagen	`find_fleet_outlier` · `find_similar_assets`
Was misst dieser Tag	`get_asset_profile` · `get_asset_tag_relations`
Womit sollte ich heute anfangen	`get_attention_ranking` · `list_findings`
Wird dieser Auftrag rechtzeitig fertig · Warum ist die OEE niedrig	`forecast_order_completion` · `get_oee_losses` · `get_spc_chart`
Was hat die KI in letzter Zeit geändert	`autonomy_status` · `list_findings`

Anomalieerkennung · Prognose — paarweise nach Zielgröße

detect_* beantwortet „Ist es gerade auffällig?", forecast_* beantwortet „Wie wird es weitergehen?". Es gibt sechs Zielgrößen, jede mit ihrem Gegenstück.

Zielgröße	Anomalieerkennung	Prognose	Was betrachtet wird
Anlagensensoren	`detect_asset_anomaly`	`forecast_asset`	Reale Messwerte wie Temperatur · Druck · Vibration
Systemressourcen	`detect_system_anomaly`	`forecast_system`	CPU · Speicher · Festplatte
OEE	`detect_oee_anomaly`	`forecast_oee`	Verfügbarkeit · Leistung · Qualität
RAM (Zuverlässigkeit)	`detect_ram_anomaly`	`forecast_ram`	MTBF · MTTR · Ausfallrate
EMS (Energie)	`detect_ems_anomaly`	`forecast_ems`	Energieverbrauch · CO2-Ausstoß
Produktion (Arbeitsauftrag)	`detect_order_anomaly`	`forecast_order`	OEE/RAM/EMS auf Auftragsbasis

Die Zielspalte (target_columns) muss nicht angegeben werden

detect_asset_anomaly · forecast_asset suchen, wenn kein Ziel-Tag angegeben wird, selbstständig die an der Anlage hinterlegten Tags und führen die Analyse damit durch. Geben Sie nur dann ein Tag an, wenn Sie gezielt ein bestimmtes Tag betrachten möchten.

Als Basismodell dient für die Anomalieerkennung IBM Granite TSPulse, für die Prognose Granite-TTM R3 → KI-Modelle

Der Anomalie-Score für Sensoren ist ein «kalibrierter Score» — Schwellenwert standardmäßig 5.0

Der Score von detect_asset_anomaly ist kein bei jedem Aufruf auf 0–1 normierter Wert, sondern gibt an, bezogen auf den Abschnitt unmittelbar vor dem Analysefenster, „um das Wievielfache der üblichen Schwankung" abgewichen wurde (robuster z-Wert). Lässt man threshold weg, gilt 5.0. 🔴 Setzt man 0, gilt nicht mehr „automatisch", sondern es wird schon eine geringe Abweichung vom Referenzmedian als Anomalie gezählt.

Domänenspezifische detect_* wie bei OEE · RAM · EMS sind weiterhin bei jedem Aufruf auf 0–1 normierte Scores — die threshold der beiden haben unterschiedliche Skalen.

Fehlschläge bei Prognose-Tools werden anhand des Statuscodes unterschieden

Was	Antwort
Zu wenig Daten	Statt TTM wird eine einfache Extrapolation geliefert, 200 · `model_used: "NAIVE"` — Spalten, die nicht prognostiziert werden konnten, erscheinen in `dropped_columns`; scheitert alles, 422
Ziel nicht vorhanden · fehlerhafte Eingabe	404 · 422
Inferenzserver nicht erreichbar	503 + `Retry-After`
Metadaten-Speicher (PostgreSQL) nicht erreichbar	503 · `upstream: "postgres_unavailable"`
Sonstiges (Konfigurationsfehler · Laden der Gewichte fehlgeschlagen · Codefehler)	500 — wird nicht durch einfache Extrapolation überdeckt

Wurde ein Konfidenzintervall angefordert, aber nicht geliefert, erklärt bounds_reason in der Antwort den Grund → Zeitreihen-Insight

Abgleich mit der Vergangenheit — „Gab es das schon einmal?"

Diese vier bilden den Kern des Zeitreihen-Insight. Hier wird nicht der Wert betrachtet, sondern die Form des Verlaufs verglichen.

Tool	Funktion
`find_similar_anomalies`	Sucht ähnliche vergangene Anomalien zum aktuellen Verlauf (Nächste-Nachbarn-Näherung über TSPulse-Embeddings)
`search_pattern`	Nimmt den Verlauf bis zu einem angegebenen Zeitpunkt als Fenster und sucht vergangene Abschnitte mit gleicher Form
`check_failure_precursor`	Vergleicht den aktuellen Verlauf mit einer Sammlung von Verläufen unmittelbar vor ERROR-Alarmen und ermittelt einen Risikowert
`find_fleet_outlier`	Vergleicht gleichartige Anlagen mit demselben Kanal untereinander und findet die, die allein abweicht

Der Unterschied zur «Grenzwertüberschreitung»

Ein Schwellenwert zeigt nur, ob «die Linie überschritten» wurde. Die vier obigen betrachten die Form vor der Überschreitung — zeigt sich jetzt wieder die Schwankung, die stets kurz vor einem Ausfall auftrat, schlägt das Tool an, auch wenn der Wert selbst noch im Normalbereich liegt.

Eine Anlage im Gesamtbild betrachten

Tool	Funktion
`analyze_asset`	Zeigt alles auf einen Blick — Health-Score · Sensoren · Status · Alarme · OEE/RAM/EMS · Hinweise zur Ursache
`get_asset_health`	Health-Index von 0–100, der Sensoren+OEE+RAM+EMS+Alarme zusammenfasst
`explain_asset_anomaly`	Verknüpft auffällige Tags · Alarme · Statusänderungen und schätzt die Ursache
`get_asset_context`	Tägliche Gesamtanalyse-Zusammenfassung der Anlage (in LLM-freundlicher Form)
`find_similar_assets`	Findet über Kosinus-Ähnlichkeit von Embeddings ähnliche Anlagen
`list_asset_tags`	Liste der an der Anlage hinterlegten Tags

Bei Unsicherheit beginnen Sie mit analyze_asset allein. Die übrigen Tools werden genutzt, um aus diesem Ergebnis gezielt weiter einzugrenzen.

So liest man den Health-Index — Änderungen in 2026.10 Re-Release 3

Der Score von get_asset_health ergibt sich als «100 − Abzüge». In dieser Version wurden die Regeln für Abzüge und zurückgestellte Bewertungen geändert.

Stillstandsabzüge zählen nur «ungeplante» Stillstände. Einrichtung (SETUP) · geplanter Stopp · im Kalender als geplant markierte Stopps und Ruhetage · Zeiten außerhalb der Schicht werden nicht abgezogen. Wie gezählt wurde, zeigt idle.basis in der Antwort.

`idle.basis`	Bedeutung
`unplanned`	Als ungeplanter Stillstand gezählt
`all_planned`	Der gesamte Stillstand war geplant — kein Abzug
`held`	Status erst kürzlich erstmals erfasst — Bewertung zurückgestellt, kein Abzug
`plan_partial`	Kalender nicht lesbar oder kein Schichtfenster der Anlage im Kalender hinterlegt — es wird nicht von 24-Stunden-Betrieb ausgegangen, sondern nur die gelesenen geplanten Stopps werden abgezogen
`plan_unknown`	Keine Statusquelle vorhanden, daher nach alter Methode (Verfügbarkeitsquote) gezählt
`no_data`	Keine Daten vorhanden — kein Abzug

Bereiche mit kurzer Historie erhalten keine 0 Punkte, sondern gelten als «zurückgestellt». Sensorbereiche ohne kalibrierte Tags sowie OEE-, RAM- und EMS-Bereiche mit kurzer Historie werden aus dem Score ausgenommen und mit Grund (insufficient_data) in held_domains vermerkt. Wurde die Note aus den verbleibenden Bereichen gebildet, gilt grade_provisional: true, und in der Chat-Antwort erscheint „Held domains … not judged", „Grade is PROVISIONAL" — lesen Sie dies als vorläufige Note.
String-Tags (Namensschilder wie Ursachencodes · Stillstandsgründe) werden als categorical klassifiziert und aus Anomalie-Score · Prognose · Statistik ausgenommen. Der Ausschlussgrund steht in der Antwort — es handelt sich nicht um „keine Werte verfügbar". Auch in get_asset_profile erscheint die Angabe «Kategorie (String-Code — kein Ziel für numerische Analyse)».
Abschnitte im Feature Store mit weniger als 30 Datenpunkten erhalten keinen Anomalie-Score und bleiben auf insufficient_data (erster Abschnitt eines neuen Tags · Erfassungslücke). Das ist nicht gleichbedeutend mit 0 Punkten (normal).

Was ein Tag misst — Profil

Tool	Funktion
`get_asset_profile`	Für jeden Tag: was gemessen wird · Normalbereich · Zuverlässigkeit
`get_asset_tag_relations`	Tag-Paare, die sich innerhalb der Anlage gemeinsam bewegen, sowie Vorlauf-Nachlauf (Kandidaten für Kausalität)

Wenn Tag-Namen wie Code aussehen

Tag-Namen vor Ort sind oft schwer lesbar, etwa TIC_1023_PV. Da get_asset_profile aufschlüsselt, „was dieser Wert misst", wählt die KI seltener das falsche Tag für ihre Antwort.

Alarme statistisch betrachten

Tool	Funktion
`get_alarm_stats`	Häufigkeit · Prioritätsverteilung · Top-Alarmkonfigurationen · Top-Tags
`analyze_alarm_duration`	Dauer-Analyse — Erkennung von Verschlechterung, Verlauf der MTTA (mittlere Erkennungszeit)
`analyze_alarm_correlation`	Korrelation zwischen Alarmen und Sensor-Tags
`detect_alarm_anomaly`	Anomalien im zeitlichen Auftretensmuster von Alarmen
`forecast_alarm`	Prognose künftiger Muster aus dem Alarmhäufigkeitstrend

KI-Entdeckungen und Problemanlagen — Neu in 2026.10

Diese Tools lesen, was die KI selbstständig entdeckt hat. Sie berechnen nichts neu, sondern liefern vom Zeitreihen-Insight bereits vorbereitete Entdeckungen, Ranglisten und Status zurück. Es handelt sich um dieselben Daten wie im Bildschirm Zeitreihen-Insight → KI-Autonomie der Verwaltungskonsole → KI-Verwaltungskonsole

Tool	Funktion	Standard
`get_attention_ranking`	Rangliste „Welche Anlage heute zuerst ansehen" pro Standort — Aufmerksamkeits-Score (0–100) und drei Gründe, gebildet aus offenen Entdeckungen · Health-Score · 24-Stunden-Trend, sowie Rangänderung gegenüber dem Vortag	An
`list_findings`	Liste der von der KI gefundenen Entdeckungen — Anlagenanomalien · verfehlte Auftragsziele · Datenunterbrechung · Datenqualität · Kettenstopps · Ausfallrisiko · KI-Autonomie-Änderungen usw. Schweregrad · Dringlichkeit · Begründung · Status (`open` · `acked` · `closed`)	An
`autonomy_status`	Aktueller Status der selbstständigen KI-Verbesserung (Normal-Baselines · Anomalie-Bewertungsmodell) — Modus · aktiv genutzte Version · Schatten · Kandidat · pausiert	Aus

Unverifizierte Bewertungen werden nicht in den Chat geladen

list_findings liefert keine «Schatten»-Entdeckungen zurück, die noch nicht von einem Menschen bestätigt wurden. Nur das, was auch Vor-Ort gemeldet wurde, fließt in Antworten ein — würde man nur eine Markierung anhängen, könnte die KI diese beim Zusammenfassen verlieren, sodass eine unverifizierte Bewertung als Tatsache weitergegeben würde.

Entdeckungen zu verfehlten Auftragszielen öffnen erst, wenn eine Begründung vorliegt

Ab 2026.10 Re-Release 3 (Regelversion order_shortfall-3) wird die Entdeckung «Auftragsziel verfehlt» in zwei Fällen zurückgestellt und nicht geöffnet.

Wenn der Auftrag gerade erst begonnen hat — verstrichene Zeit unter 60 Minuten (höchstens die Hälfte der geplanten Dauer) (held:early)
Wenn die planmäßig bis jetzt zu erzeugende Menge unter 1 Stück liegt — etwa bei Aufträgen, bei denen ein Stück mehrere Stunden benötigt und der Fortschritt nicht über die Stückzahl gemessen werden kann (held:no_progress_evidence)

Trifft eine bereits geöffnete Entdeckung auf diese Bedingung, wird sie mit out_of_scope geschlossen. Ein großer Auftrag, der von Anfang an steht, fällt nicht unter die Zurückstellung und bleibt offen.

Produktionsanalyse

Tool	Funktion	Standard
`forecast_order_completion`	Ob ein laufender Arbeitsauftrag bis zum geplanten Ende die Zielmenge erreicht — erwartete Endmenge an Gutteilen (P10–P90) · Erreichungswahrscheinlichkeit · voraussichtlicher Fertigstellungszeitpunkt · fehlende Menge	Aus
`get_oee_losses`	Warum die OEE niedrig ist — Verlustzeiten bei Verfügbarkeit · Leistung · Qualität, die sechs großen Verluste, Stillstandsursachen (inkl. Kurzstopps), Abgleich mit der Platform-OEE. Standardmäßig letzte 24 Stunden (max. 744 Stunden)	Aus
`get_spc_chart`	Fehlerquoten-Regelkarte (p-Regelkarte, bei Überdispersion Laney p′) für Anlage · Produkt — Mittellinie · Eingriffsgrenzen · Western-Electric-Signale	Aus

forecast_order und forecast_order_completion sind unterschiedlich

forecast_order betrachtet den OEE-Trend über kommende Aufträge, forecast_order_completion prüft, ob der gerade laufende einzelne Auftrag sein Ziel erreicht. „Wie viele Stück fehlen bei diesem Auftrag" beantwortet Letzteres.

Feature Store · Status

Tool	Funktion
`get_asset_features`	Health-Score · Anomalie-Score · Alarme · Status · Produktionskennzahlen
`get_feature_status`	Liste der Scheduler-Jobs · Zeitpunkt der letzten Ausführung · Backfill-Status
`health_check`	Status des Servers und abhängiger Dienste — Event-Speicher (Cassandra) · Metadaten-Speicher (PostgreSQL) · Inferenzserver · Embeddings
`trigger_feature_pipeline`	Manuelle Ausführung der Pipeline — 🔴 Schreibzugriff, daher aus Richtliniengründen gesperrt und nicht aktivierbar

Wenn die Antwort «Keine Daten verfügbar» lautet

Die Tools für Anlagenübersicht und Ähnlichkeit nutzen im Feature Store vorab berechnete Werte. Lief der Scheduler nicht, bleibt die Antwort leer, obwohl das Tool einwandfrei angebunden ist — prüfen Sie mit get_feature_status zunächst den Zeitpunkt der letzten Ausführung.

Auswahl nach gewünschter Frage​

Anomalieerkennung · Prognose — paarweise nach Zielgröße​

Abgleich mit der Vergangenheit — „Gab es das schon einmal?"​

Eine Anlage im Gesamtbild betrachten​

So liest man den Health-Index — Änderungen in 2026.10 Re-Release 3​

Was ein Tag misst — Profil​

Alarme statistisch betrachten​

KI-Entdeckungen und Problemanlagen — Neu in 2026.10​

Produktionsanalyse​

Feature Store · Status​

Verwandte Dokumente​