Traceability in der Zelle: Welche Daten zählen wirklich?

Nicht alle Daten sind wertvoll. Die richtige Balance zwischen Datenerfassung und wirtschaftlicher Sinnhaftigkeit ist der Schlüssel zu echter Traceability — von der Zelle bis zur IT.

Das Traceability-Dilemma

„Wir wollen Traceability!" — dieser Wunsch kommt aus Fast allen modernen Fabriken. Das ist verständlich: Qualitätsprobleme nachzuverfolgen, Haftungsfragen zu klären, Prozessoptimierungen auf Datenbasis zu treffen — das sind echte Geschäftsziele.

Aber dann kommt die Frage, die oft zu spät gestellt wird: „Welche Daten brauchen wir eigentlich?"

Viele Projekte enden damit, dass jede Sensor-Ablesung, jeder Zustandswechsel, jedes Timing ins ERP fließt. Das Ergebnis: Terabyte an Daten, die niemand analysiert. Und Performance-Probleme, weil die Datenbänke beim Speichern überlasten.

Der richtige Ansatz: Selektive Erfassung

Gute Traceability ist nicht "mehr Daten", sondern "die richtigen Daten".

Das bedeutet, zunächst zu definieren:

  1. Geschäftsziele: Was willst du mit den Daten machen? Qualität nachverfolgen? Liefersicherheit? Kostenrechnung?
  2. Kritische Punkte: Wo im Prozess entscheiden sich Qualität und Fehlerquote? Das sind deine Messpunkte.
  3. Minimale Granularität: Welche zeitliche Auflösung brauchst du wirklich? Sekunde? Minute? Job-Level?
  4. Speicherstrategie: Wie lange haltbar? Muss es live in der IT sein oder reicht Batch-Upload?

Beispiel: Schweißzelle mit Qualitätskontrolle

Angenommen, du schweißst Teile und willst eine Fehlerquote unter 0,5% halten. Was musst du tracken?

Unverzichtbar:

  • Teil-ID (Barcode oder Seriennummer)
  • Teiletyp / Variante
  • Schweißung: Start-Zeit, Ende-Zeit, Status (OK / Fehler)
  • Falls Fehler: Art des Fehlers (z.B. "Stromstärke zu niedrig", "Position außerhalb Toleranz")
  • Nachfolgender Test: Bestanden / Nicht bestanden

Nice-to-have (aber kostensparend nicht immer notwendig):

  • Jede einzelne Sensor-Ablesung während des Schweißens
  • Temperatur-Kurven im Sekundentakt
  • Spannungs- und Stromverlauf in hoher Auflösung

Die meisten Qualitätsprobleme lassen sich schon aus den unverzichtbaren Daten identifizieren. Die Sensor-Details brauchst du nur, wenn es zu einem Fehler kam — dann legst du los mit hoher Auflösung.

Datenfluss: Von der Zelle zur IT

Traceable Daten sind nur wertvoll, wenn sie auch ankommen. Also: Wie minimierst du Fehler beim Transfer?

Push oder Pull?

  • Push: Zelle sendet Daten aktiv ans ERP (z.B. REST-API nach jedem Job). Schnell, aber erfordert zuverlässige Vernetzung.
  • Pull: ERP / MES fragt die Zelle periodisch ab. Robuster, aber mit Latenz.
  • Hybrid: Normale Jobs per Batch-Update (z.B. hourly), Fehler sofort via Push (REST).

Fehlerbehandlung:

Was passiert, wenn das Netzwerk weg ist? Zelle muss Daten lokal buffern können — mindestens für 24-48h. Dann, sobald Netzwerk zurück ist, Synchronisation mit Kollisionserkennung.

Wem gehören die Daten? Format und Standards

Ein häufiges Problem: Jede Zelle sendet in einem anderen Format. JSON, XML, CSV, proprietäre Binär... Das führt zu Chaos in der IT.

Besser: Ein standardisiertes Format und ein klares Datenmodell.

  • JSON für APIs
  • Einheitliches Schema für Job-Events, Fehler, Messwerte
  • Versionierung des Schemas (v1.0, v1.1 usw.)
  • Zeit immer in UTC + lokale Zeitzone beim Event

Das ist aufwand at vorne, aber spart Abstimmung und Bugs später.

Best Practice: Event-basierte Traceability

Anstatt Rohdaten zu streamen, tracker Events:

  • „Job gestartet" mit Timestamp, Teil-ID, Variante
  • „Qualitätsprüfung bestanden" oder „Fehler: Stromstärke zu niedrig"
  • „Job abgeschlossen" mit Gesamtlaufzeit

Jedes Event ist ein diskrete Fact, the dokumentiert wird. Damit hast du full Traceability ohne Dateneflut. Und wenn nötig, kannst du an Fehler-Events ein "Detailed Logging" anfügen — volle Sensor-Historie für die Fehleranalyse.

Die wirtschaftliche Sicht

Speicherplatz, Bandweite, Datenbank-Lizenzkosten — all das hängt von Datenvolumen ab. Eine sorgfältige Auswahl der Traceability-Punkte kann Betriebskosten um 30-50% senken — ohne Qualitätsverlust.

Und wichtig: Mit weniger, dafür strukturierteren Daten wird Analyse schneller. Die IT-Teams freuen sich, die Auswertungen sind verlässlicher.

Fazit

Traceability ist eine Designentscheidung, nicht eine Datensammel-Übung.

Definiere erst, was du messen willst und warum. Dann definiere die notwendigen Events und Format. Dann implementiere zuverlässige Übertragung. Mit diesem Ansatz bekommst du Traceability, die tatsächlich hilft — ohne Chaos und Kosten-Überraschungen.