Grundlage ist DOC_Prinect API 2021.
Im Fokus stehen insbesondere:
- Job-/Workstep-Daten (
/rest/job/...,/workstep,/quality,/activity,/output) - Device-Daten (
/rest/device/...,/activity,/consumption,/output) - Event-Subscriptions (
/rest/device/action/subscription) - Ressourcen-/Verbrauchssignale
- Farb- und Qualitätsdaten
Use-Cases werden strikt entlang der API-Fähigkeiten bewertet und nach dem wirtschaftlichem Impact für eine Heidelberg XL 106 (9F + Lack) bewertet.
Produktions-Transparenz & OEE (höchster Impact)
Use Case: Rüstzeiten, Waschzeiten, Stillstände, OEE
Impact
Sehr hoch.
Typisch 3-8 % Produktivitätssteigerung durch:
- Reduktion ungeplanter Stillstände
- Verkürzung von Rüstzeiten
- Transparente Schichtvergleiche
Datenbasis
Device Activity Log
/rest/device/[deviceId]/activity
liefert:
- startTime / endTime
- goodCycles / wasteCycles
- timeTypeName (z.B. Execution time)
- costCenter
- Mitarbeiter
Status-Signale inkl. EventIDs (Washup etc.)
/rest/device/action/subscription
EventIDs (z.B.):
- @45/@46 Waschvorgang
- 8008/8009 Druckstart/-stopp
- @53/@54 Plattenwäsche
Das ist sauber maschinennahe Prozessintelligenz.
Workstep-Zeiten
/rest/job/[jobId]/workstep
liefert:
- setuptimePlanned
- prodtimePlanned
- actualTimes
Visualisierung
Nicht Soll/Ist.
Stattdessen:
- Zeitachse pro Schicht mit farbcodierten Zuständen (Run, Wash, Setup, Idle)
- Heatmap „Rüstzeit vs. Auflagenhöhe“
- Pareto-Chart: Hauptverursacher von Stillstand
- Trend „Ø Rüstzeit pro Woche“
Risiken
- API-Limit 2 Requests/Sekunde → Event-getriebene Architektur nötig.
- Definition „Rüstzeit“ muss fachlich geklärt werden (Setup-Status vs. EventIDs).
- Nur 15 Tage Output-Historie bei
/output→ eigenes Data-Warehouse nötig.
Integration
- ERP zur Auftragszuordnung
- MES-Ebene
- BI-System
Einschränkung
OEE-Berechnung ist möglich.
MTBF/MTTR nur eingeschränkt, da keine expliziten Fehlercodes über API dokumentiert sind.
Qualitäts- & Farbkontrolle (sehr hoher Impact bei 9F + Lack)
Use Case: Qualitätsverlauf, Farbdrift, Reklamationsprävention
Impact
Sehr hoch bei hochwertigen Produktionen.
Reduktion von Makulatur und Reklamationen.
Datenbasis
/rest/job/[jobId]/workstep/[workstepId]/quality
liefert:
- Dichte
- L_a_b*-Werte
- Dot Gain
- Qualitätsabweichung
- Zonenmesswerte (optional, performancekritisch)
Zusätzlich:
/rest/device/[deviceId]/output
qualityDeviation (Small, Medium, Large)
Visualisierung
- DeltaE-Verlauf über Auflage
- Zonen-Heatmap über 64 Farbzonensegmente
- Qualitätsabweichung vs. Geschwindigkeit
- Kontrollkarten (SPC)
Das ist kein simples Dashboard, sondern statistische Prozesskontrolle.
Risiken
- Qualitätsdaten nur mit Lizenz verfügbar
- Zonenwerte verlangsamen API erheblich
Integration
- Reklamationssystem
- Kundenspezifische Toleranzen
- Automatisierte Warnmeldungen
Einschränkung
API liefert Messwerte, aber keine expliziten Sollwerte.
Sollwerte müssen aus Jobticket oder externem System kommen.
Materialverbrauch (Farbe, Lack, Papier)
Use Case: Farbverbrauch & Lackverbrauch
Impact
Mittel bis hoch.
Typisch 2-5 % Einsparpotenzial bei Farbe.
Datenbasis
/rest/job/[jobId]/workstep/[workstepId]/inkConsumption
liefert:
- estimatedConsumption kg/1000 Drucke
PressSheet-Ebene:
/rest/job/[jobId]/element
liefert:
- inkConsumption pro Oberfläche
Wichtig:
Das sind geschätzte Werte, nicht reale gemessene Verbräuche.
Für reale Verbräuche:
Ressourcen-Signale
SignalRessource
→ liefert ActualAmount + MaterialID.
Visualisierung
- Verbrauch pro Auftrag vs. Auflage
- Verbrauch pro Farbe vs. Maschinenkonfiguration
- Trend „Farbverbrauch pro 1.000 Bogen“
- Abweichung geschätzt vs. real
Risiken
- InkConsumption ist kalkulatorisch.
- Lackverbrauch nicht explizit ausgewiesen → müsste über ResourceSignal kommen.
- Datenqualität abhängig von PressCenter-Konfiguration.
Integration
- ERP (Materialkosten)
- Einkauf
- Lagerbestand
Einschränkung
Ohne aktivierte ResourceSignals keine Echtverbrauchsdaten.
Vollständige Jobdefinition & Status-Tracking
Use Case: ERP-Integration, Auftragsmonitoring
Impact
Hoch für Durchlaufzeit und Transparenz.
Datenbasis
/rest/job
liefert:
- globalStatus
- milestones
- calculatedProgress
/rest/job/[jobId]
/rest/job/[jobId]/workstep
/rest/job/action/subscription
→ Event-basierte Statusmeldungen.
Visualisierung
- Gantt-ähnlicher Produktionsfahrplan
- Live-Board „Alle Jobs auf XL 106“
- Meilenstein-Fortschritt in %
Risiken
- API liefert keine harte Terminplanung.
- Parallel-Requests limitiert
Integration
- ERP
- Kundenportal
- Außendienst
Einschränkung
Kein direkter Zugriff auf strukturierte JDF empfohlen
Schichtauswertung
Impact
Mittel.
Datenbasis
/rest/employee/[employeeId]/activity
- Device Activity.
Visualisierung
- Output pro Schicht
- Makulaturquote pro Schicht
- Produktivzeit pro Bediener
Risiken
- Datenschutz
- Interpretation (Mensch vs. Maschineneffekt)
Predictive Maintenance (eingeschränkt möglich)
Faktenlage
API liefert:
- Statuswechsel
- Waschzyklen
- Speed
- TotalProductionCounter
Aber:
- Keine Sensordaten
- Keine Fehlercodes mit Tiefe
Bewertung
→ Predictive Maintenance nur heuristisch:
- Waschzyklen vs. Produktionsmenge
- Stillstandshäufigkeit
- Anomalieerkennung
Echte Condition-Based Maintenance ist mit dieser API nicht vollständig möglich.
Eigene strategische Vorschläge
Dynamisches Rüstzeit-Optimierungsmodell
Korrelation:
- Farbwechselanzahl
- Bogenformat
- Auflage
- Bediener
- Rüstzeit
Ziel:
Automatische Vorschläge zur optimalen Job-Reihenfolge.
Datenbasis: Workstep + Device Activity.
Qualitäts-Kosten-Modell
Verknüpfung:
- qualityDeviation
- Makulatur
- Farbverbrauch
- Geschwindigkeit
Ergebnis:
„Kosten pro Qualitätsabweichung“.
Das erzeugt betriebswirtschaftliche Transparenz statt technischer Zahlen.
Echtzeit-Maschinen-Digital-Twin
Mit:
- StatusSignal
- ResourceSignal
- Output
- Quality
Live-Zustandsmodell der XL 106.
Priorisierte Empfehlung für Vertriebsgespräch
- Produktions- & OEE-Transparenz
- Qualitätsmonitoring mit SPC
- Materialkosten-Transparenz
- ERP-Integration
- Schicht-Performance
- Heuristische Maintenance
Kritische offene Punkte (minimal klärungsbedürftig)
- Sind Qualitätsdaten lizenziert (siehe
/rest/job/[jobId]/workstep/[workstepId]/qualityin DOC_Prinect API 2021)?
relevant für: Qualitäts- & Farbmonitoring, SPC-/Trendanalysen von Lab*, Dichte, Dot Gain, Qualitätskosten-Analyse, Reklamationsprävention
indirekt relevant für: Makulatur-Ursachenanalyse, Korrelation Geschwindigkeit <-> Qualität - Werden im Prinect-System Ressourcensignale (z. B. Material- oder Verbrauchsdaten) erzeugt, und sind diese über eine Subscription zugänglich?
relevant für: Material- & Farbverbrauch (real vs. geschätzt), Lackverbrauch-Analyse, Verbrauchskosten pro Auftrag, Energieverbrauch-Analyse
indirekt relevant für: Deckungsbeitragsanalyse je Auftrag, Kalkulationsoptimierung - Welches ERP ist im Einsatz?
relevant für: ERP-Integration & Live-Auftragsmonitoring, Automatische Statusrückmeldungen, Kostenrückführung in Kalkulation, Materialkosten-Zuordnung
indirekt relevant für: Produktionscontrolling, Auftragsbezogene OEE-Auswertung, Kunden-Performance-Analysen - Gewünschte Historientiefe (wie lange sollen Daten verfügbar/vergleichbar sein)?
relevant für: Langzeit-OEE-Trends, Jahresvergleich Schichtleistung, Qualitätsdrift über Monate, Predictive-Ansätze, Verbrauchstrends