Messwerte, Analyse und fachliche Prüfung

KI-Datenanalyse in der Produktion: Auffälligkeiten erkennen und Hinweise prüfen

KI-Datenanalyse kann helfen, auffällige Muster in Produktionsdaten zu erkennen. Dieser Beitrag betrachtet Messwertverläufe einer angebundenen Prozessgröße: Welche Daten und Vergleichsmaßstäbe braucht die Auswertung, wo läuft sie, und wie wird aus einem auffälligen Ergebnis ein fachlich geprüfter Hinweis?

SystemwissenAutor: Hannes SchubertVeröffentlicht: Aktualisiert:

Eine Auffälligkeit benennt zunächst weder ihre Ursache noch die richtige Maßnahme.

Was KI-Datenanalyse an Messwertverläufen untersucht

Beim maschinellen Lernen werden Modellparameter anhand von Daten oder Erfahrungen angepasst. Das trainierte Modell ist das Ergebnis dieses Trainings; es kann anschließend neue Eingabedaten verarbeiten und daraus eine Ausgabe berechnen. Training und Anwendung sind unterschiedliche Vorgänge: Das Auswerten eines neuen Messwertverlaufs bedeutet nicht automatisch, dass das Modell dabei weiterlernt.[2]

Als fiktives Beispiel dient der Temperaturverlauf während der Haltephase eines definierten Prozessschritts. Für jede Charge wird genau diese Phase als Zeitfenster betrachtet. Die Analyse soll ungewöhnliche Verläufe zur Prüfung markieren; sie soll weder die Ursache diagnostizieren noch eine Charge freigeben. Das Beispiel beschreibt eine mögliche Architektur, kein Produktangebot.

Dafür muss bekannt sein, welches Gerät gemessen hat und zu welcher Charge und Prozessphase das Fenster gehört. Ein zeit- und zustandsbezogener Kontext lässt beispielsweise Aufheizen und Halten unterscheiden, bevor ein Vergleichsmaßstab gewählt wird. Das Signal lässt sich auch ohne diese Zuordnung statistisch untersuchen; seine prozessbezogene Bedeutung bleibt dann jedoch offen.

Auch die Übergabe der Messdaten gehört zur Betrachtung: Zeitstempel und Status einer Gerätemeldung helfen, einen Verlauf vor der Auswertung einzuordnen. Eine Lücke im Zeitfenster ist zunächst eine Lücke in den verfügbaren Daten und noch kein nachgewiesener Temperaturabfall.

Grenzwert, Regelkarte oder trainiertes Modell?

Nicht jede Auswertung braucht ein trainiertes Modell. Eine festgelegte Temperaturgrenze, eine statistische Regelkarte und ein Modell für ungewöhnliche Verläufe beantworten unterschiedliche Fragen. Sie bilden keine Rangfolge von einfacher zu besserer Analyse; maschinelles Lernen und statistische Verfahren sind zudem keine trennscharfen Gegenwelten.[3][4]

AnsatzFrage im BeispielGrenze der Aussage
Festgelegter GrenzwertÜberschreitet die Temperatur eine für diesen Schritt vorgegebene Grenze?Die Einhaltung erklärt weder den gesamten Verlauf noch die Ursache einer Überschreitung.
Statistische RegelkarteZeigt die ausgewählte Prozesskenngröße ein Signal gegen den festgelegten statistischen Maßstab?Ein Signal ist ein Untersuchungsanlass; statistische Kontrollgrenzen sind nicht mit Produktspezifikationen gleichzusetzen.
Trainiertes AnomaliemodellWie auffällig ist das betrachtete Fenster gegenüber dem erlernten Vergleichsbild?Das Ergebnis hängt unter anderem von Trainingsdaten, Eingaben und Entscheidungsschwellwert ab.

Eine Regelkarte stellt eine ausgewählte Qualitätsgröße oder eine daraus berechnete Kenngröße über Stichproben oder Zeit dar. NIST beschreibt eine Mittellinie sowie obere und untere Kontrollgrenzen. Nicht nur Punkte außerhalb der Grenzen können Anlass zur Untersuchung geben: Auch ein nichtzufälliges Muster innerhalb der Grenzen kann gegen einen beherrschten Prozess sprechen.[3]

Für den Temperaturfall wäre deshalb zuerst festzulegen, welche Größe die Regelkarte verfolgt und wie vergleichbare Stichproben entstehen. Eine gemeinsame Haltephase grenzt den Vergleich ein, stellt seine Eignung aber nicht allein sicher. Die Wahl der Regelkarte und ihre statistischen Voraussetzungen müssen zur Datenstruktur passen.

Chandola, Banerjee und Kumar unterscheiden einzelne auffällige Beobachtungen, kontextabhängige Auffälligkeiten und auffällige Gruppen zusammenhängender Beobachtungen. Bei der letzten Form kann die Folge auffällig sein, obwohl einzelne Punkte für sich genommen unauffällig erscheinen.[4] Auf unser Beispiel übertragen könnte ein Temperaturanstieg beim Aufheizen erwartbar, während einer Haltephase aber prüfbedürftig sein; ob das tatsächlich gilt, bestimmt die konkrete Prozessaufgabe.

Welche Daten Training und Anwendung benötigen

Für den weiteren Beispielfall nehmen wir ein Verfahren an, das aus fachlich als normal eingeordneten Haltephasen ein Vergleichsbild lernt. Das ist eine gewählte Trainingsannahme, keine Beschreibung aller Anomalieerkennung: Der Survey unterscheidet Verfahren mit normal und anomal markierten Daten, Verfahren mit normal markierten Trainingsdaten und Verfahren ohne solche Trainingsvorgaben.[4]

Die Auswahl dieser Fenster ist eine fachliche Aufgabe. Die spätere Freigabe einer Charge allein sagt noch nicht, ob ihr Temperaturverlauf ein geeignetes Normalbeispiel für die beabsichtigte Analyse ist. Für unser Modell wären etwa Prozessphase, Datenvollständigkeit und bekannte Besonderheiten des Verlaufs vor der Aufnahme in den Trainingsbestand zu beurteilen.

Das Modell muss außerdem an Daten geprüft werden, die nicht bereits seine Anpassung bestimmt haben. ISO/IEC 22989 unterscheidet Trainings-, Validierungs- und Testdaten; der Testbestand bleibt vom Training und von der Abstimmung des Modells getrennt. Für die Systemprüfung nennt die Norm Testdaten, die für die erwarteten Eingaben repräsentativ sind.[2]

Im laufenden Beispiel erhält das festgelegte Modell anschließend ein neues Haltephasenfenster oder daraus berechnete Merkmale. Welche Eingaben verwendet und wie sie vorverarbeitet werden, gehört zur Modellkonfiguration. Training erzeugt oder verändert das Modell; die Anwendung berechnet zunächst nur das Ergebnis für dieses Fenster.[2]

KI On-Premise oder extern: Wo laufen Analyse und Datenverarbeitung?

Für den Temperaturfall lassen sich drei Betriebsfälle gegenüberstellen. Die folgende Einteilung ist eine eigene Architekturbetrachtung; sie ist weder ein Produktangebot noch eine Übernahme der Cloud-Bereitstellungsmodelle von NIST. Für jeden Fall sind Training und spätere Anwendung gesondert zu betrachten.

A – Verarbeitung in eigener Infrastruktur: Messwertablage, Datenvorbereitung, Training und Anwendung liegen im angenommenen Fall auf der eigenen Infrastruktur am Unternehmensstandort. Das ist hier mit On-Premise gemeint. Daraus folgt noch nichts über Fernzugriffe oder zusätzliche externe Verbindungen; diese wären gesondert zu klären.

B – Dedizierter Dienstleisterbetrieb: Die ausgewählten Fenster werden für Training und Anwendung in eine für das Unternehmen vorgesehene Umgebung beim Dienstleister übertragen. Die Daten befinden sich damit außerhalb des Unternehmensstandorts, auch wenn eigene Beschäftigte die Umgebung administrieren. Wer Daten, Modelle und Protokolle einsehen oder verändern kann, bleibt eine eigene Betriebsfrage.

C – Externe Analyse über eine Schnittstelle: Ablage und Vorbereitung bleiben im Unternehmen; der externe Dienst erhält die vereinbarten Eingaben. Für einen dort ausgeführten Trainingslauf könnten dies ausgewählte historische Fenster samt Kontext sein, für eine einzelne Anwendung das aktuelle Fenster oder dessen Merkmale. Welche Daten den Betrieb tatsächlich verlassen, ergibt sich aus dieser Festlegung – nicht aus dem Wort „API“.

Die Fälle lassen sich kombinieren, etwa externes Training mit interner Anwendung. „Hybrid“ bezeichnet hier diese Kombination und nicht automatisch eine Hybrid Cloud im Sinne von NIST. Auch Private Cloud und On-Premise sind nicht gleichbedeutend: NIST lässt eine Private Cloud innerhalb oder außerhalb des Unternehmensstandorts und durch eigene oder fremde Betreiber zu. Eine Modellschnittstelle allein ist dort kein eigenes Bereitstellungsmodell.[1]

Drei Betriebsfälle mit getrennten Datenwegen für Training und Modellanwendung
Eigene schematische Darstellung der Architekturbeispiele A–C. In C verlassen die vereinbarten Eingaben das Unternehmen: historische Zeitfenster für ein dort ausgeführtes Training, aktuelle Zeitfenster oder Merkmale für die Anwendung. Das Ergebnis bleibt fachlich zu prüfen.

Änderungen und Betriebsaufwand klären

Die Betriebsentscheidung umfasst mehr als den Rechnerstandort. Für unser Beispiel wäre festzulegen, wer Trainingsdaten auswählt, wer Modell und Vorverarbeitung versioniert und wer Änderungen in die Anwendung übernimmt. Beim externen Dienst ist zu klären, welche Änderungen das Unternehmen selbst steuert und wie es von Änderungen des Anbieters erfährt.

ISO/IEC 22989 beschreibt Nachtraining als Aktualisierung eines trainierten Modells mit anderen Trainingsdaten und nennt unter anderem Data Drift und Concept Drift als mögliche Anlässe. Daraus folgt für die Praxis keine Regel, jede beobachtete Veränderung sofort nachzutrainieren.[2] Im Temperaturbeispiel wäre zunächst zu prüfen, ob sich der Prozess, die Messung oder die Datenaufbereitung verändert hat und welche Folgen dies für den bisherigen Vergleichsmaßstab hat.

Ein während der Anwendung unverändertes Modell ist von kontinuierlichem Lernen zu unterscheiden. Bei kontinuierlichem Lernen finden laufende Modellanpassungen im Betrieb statt; die Norm verknüpft damit eine zusätzliche kontinuierliche Validierung. Diese besondere Beschreibung darf nicht unterschiedslos auf jedes eingesetzte Modell übertragen werden. Betrieb und Überwachung behandelt die Norm auch unabhängig davon.[2]

Für die Planung des Betriebs helfen drei Fragen:

  • Wer betreut Datenvorbereitung, Modell und technische Umgebung im laufenden Betrieb?
  • Welche Rechenleistung, Speicherkapazität und Bearbeitungszeit braucht der vorgesehene Trainings- und Anwendungslauf?
  • Wer prüft Änderungen und auffällige Ergebnisse, und welche Arbeitszeit ist dafür eingeplant?

Diese Fragen sind eine Planungshilfe, keine Kalkulation. Ob eigene Infrastruktur oder ein externer Dienst besser zur Aufgabe passt, lässt sich aus dem Begriff KI allein nicht entscheiden. Zur betrachteten Leistung gehört auch die Bearbeitung der Hinweise nach der Berechnung.

Einen auffälligen Hinweis prüfen

Ein Anomalieverfahren kann einen Score ausgeben, also eine Bewertung der Auffälligkeit. Wird daraus eine Markierung abgeleitet, muss ein Schwellwert festgelegt werden. Chandola und Kollegen beschreiben sowohl solche Bewertungen als auch direkte Normal-/Anomalie-Zuordnungen.[4] Der Score ist damit nicht automatisch eine Wahrscheinlichkeit für eine bestimmte Fehlerursache.

Bei unveränderter Berechnung und der Regel „höherer Score = auffälliger“ lässt ein niedrigerer Schwellwert mehr Fenster als auffällig gelten. Damit können zusätzliche tatsächlich auffällige Fenster erfasst, aber auch zusätzliche normale Fenster markiert werden. Ein höherer Schwellwert reduziert die Markierungen, kann jedoch auffällige Fenster übersehen. Welche Fälle betroffen sind, muss an fachlich beurteilten Daten geprüft werden; der Survey weist ausdrücklich auf die unscharfe Grenze zwischen normalem und anomalem Verhalten hin.[4]

Für unser Haltephasenbeispiel könnte ein Prüfprotokoll die folgenden Angaben zusammenführen. Die Liste ist ein eigener Gestaltungsvorschlag, keine Vorgabe der zitierten Quellen.

  • Gerät, Charge, Prozessschritt, Haltephase und untersuchtes Zeitfenster;
  • verwendete Messdaten und bekannte Lücken oder Statushinweise;
  • Versionen von Vorverarbeitung und Modell sowie der verwendete Schwellwert;
  • berechnetes Ergebnis und der für die Prüfung herangezogene Vergleichsmaßstab;
  • fachliche Beurteilung, verantwortliche Person und daraus folgende Handlung.

Eine Markierung ist – wie jedes Lernsignal – zunächst ein Ausgangspunkt für die Untersuchung. Im Beispiel wäre zu unterscheiden, ob ein Messproblem, ein ungeeigneter Vergleich oder eine tatsächliche Prozessveränderung vorliegt; die Markierung allein entscheidet das nicht.

Damit menschliche Aufsicht wirksam bleibt, muss die prüfende Person die relevanten Daten und den Handlungsspielraum erhalten. Ein sprachlich formulierter Hinweis könnte diese Prüfung unterstützen; im hier gewählten Aufbau ersetzt seine Formulierung weder die Analyse noch die fachliche Entscheidung. Entscheidend ist, welcher Befund zu welcher begründeten Handlung geführt hat.

Primärquellen und weiterführende Literatur

[1] Mell, Peter; Grance, Timothy: The NIST Definition of Cloud Computing. NIST Special Publication 800-145, 2011, Abschnitt 2, S. 2–3. Originalquelle.

[2] ISO/IEC 22989:2022: Information technology — Artificial intelligence — Artificial intelligence concepts and terminology. Insbesondere 3.3.5–3.3.16, 5.11.7–5.11.9 und 6.2.4–6.2.7. Kostenpflichtige Norm. Originalquelle.

[3] NIST/SEMATECH: e-Handbook of Statistical Methods, Abschnitte 6.3.1, What are Control Charts?, und 6.1.6, What is Process Capability? Abgerufen am 7. Oktober 2026. Originalquelle.

[4] Chandola, Varun; Banerjee, Arindam; Kumar, Vipin: Anomaly Detection: A Survey. Technical Report TR 07-017, University of Minnesota, 2007, insbesondere Abschnitte 1.2 und 2.2–2.4. Originalquelle.