KI-GESTÜTZTE DOKUMENTATION

Was möchten Sie wissen?

MES- & PLC-Integrationsmuster

Diese Seite ist die Referenz für Steuerungstechniker, wie sich die Kamera in eine reale Anlage einfügt. Sie ergänzt den Integration Builder (der die Node-RED-Flows generiert) und den IO Helper (der die Verdrahtung + die API-Aufrufsequenzen generiert).

Die Standardarchitektur

In 90 % der Installationen lautet der Pfad MES → PLC → Kamera, niemals MES → Kamera direkt.

                        Per-part decisions (ms)        Aggregate decisions (sec)
                        ------------------------       --------------------------
  Barcode scan ----+
  Operator HMI ----+--> PLC --recipe ID--> Camera
  MES work order --+    ^                    |
                        |   <--pass/fail--   |
                        |   <--defect class--+
                   Reads result,
                   fires reject gate
                   in 10-50ms                          PLC packages event
                                                       {WO, lot, serial, recipe,
                        +----------------------------> result, defect, timestamp}
                                                                  |
                                                                  v
                                                                MES
                                                       (OEE, quality, traceability,
                                                        hold-the-order decisions)
                                                                  |
                                                                  v
                                                                 ERP

Wichtige Fakten:

Die PLC trifft die teilbezogene Ausschussentscheidung. Sie muss in Millisekunden reagieren. MES kann dies nicht (zu langsam, nicht deterministisch).
Die Kamera meldet Pass/Fail an die PLC, nicht direkt an MES.
Rezeptauswahl läuft über die PLC. MES entscheidet möglicherweise, welches Rezept laufen soll, aber die PLC schreibt die Rezept-ID an die Kamera (über EtherNet/IP O.Data[4-5] oder das entsprechende PROFINET-Wort).
MES empfängt kontextualisierte Ereignisse von der PLC (Auftrag, Los, Seriennummer, Station, Rezept, Pass/Fail, Defektklasse) und trifft aggregierte Entscheidungen (Auftrag stoppen, wenn Ausschussrate Schwellwert überschreitet, Qualitätsingenieur alarmieren, OEE aktualisieren).
Ein PLC-Schieberegister synchronisiert das Inspektionsergebnis mit der nachgelagerten Auswurfposition, indexiert über Encoder-Impulse.

Die drei Muster

A. PLC meldet an MES (Standard)

Das Standardmuster. PLC verarbeitet den Echtzeit-Ausschuss. PLC verpackt das Ergebnis mit Auftragskontext und leitet es über OPC UA oder MQTT an MES weiter.

Wann verwenden: jede Produktionslinie mit PLC. Üblich in Automotive, Verpackung, Lebensmittel/Getränke, Pharma.

Endpunkt-Sequenz (einmal bei der Inbetriebnahme einrichten):

Schritt	Methode	Pfad	Zweck
1	`GET`	`/edge/download/industrial_ethernet/ethernet_ip_eds`	EDS-Datei herunterladen (firmwarekompatibel). An den PLC-Programmierer übergeben.
2	`POST`	`/edge/recipe/change_plc_recipe_id`	Kamerarezepte auf PLC-freundliche IDs (1, 2, 3...) mappen, die mit MES-SKU-Codes übereinstimmen.
3	`POST`	`/edge/environmental_variables`	Anlagenkontext (Linien-Code, MES-URL) für den Node-RED-Flow persistieren.
4	`GET`	`/edge/nodered/flow`	Den aktiven Rezept-Node-RED-Flow lesen.
5	`POST`	`/edge/nodered/flow`	Den aktualisierten Flow mit dem OPC UA / MQTT Publisher bereitstellen.

B. Kamera publiziert parallel zur PLC (modern parallel)

PLC verarbeitet weiterhin den Ausschuss. Kamera publiziert ZUSÄTZLICH eine reichhaltigere Payload (image_ref, Defektklasse, Konfidenz) direkt an MQTT oder OPC UA für den Historian, Dashboards und KI-Training. Läuft parallel zum PLC-Pfad, nicht stattdessen.

Wann verwenden: Anlagen mit einer Unified-Namespace-Initiative (HiveMQ + Ignition + Grafana, Litmus Edge, HighByte). Greenfield-Industrie-4.0-Standorte.

Endpunkt-Sequenz:

Schritt	Methode	Pfad	Zweck
1	`GET`	`/edge/nodered/flow`	Den aktiven Flow lesen.
2	`POST`	`/edge/nodered/flow`	Einen Flow mit `mqtt-out` (oder `sparkplug-out`) bereitstellen, der auf Ihren Broker zielt.
3	`GET`	`/edge/capture_result`	Optional: historische Ergebnisse während der initialen Synchronisation nachladen.
4	`GET`	`/edge/capture_result/{capture_id}/heatmap`	OV80i: Defekt-Heatmap PNG für fehlgeschlagene Inspektionen abrufen.

Die Kamera wird mit einem integrierten MQTT-Broker unter ws://{camera_ip}:9001/mqtt ausgeliefert, sodass kleine Installationen keinen externen Broker benötigen.

C. Standalone (keine PLC)

Keine Produktions-PLC. Eine Bediener-App oder Cloud-MES spricht direkt mit der Kamera über REST: holt den Auftrag, wechselt das Rezept, löst die Inspektion aus, erhält das Ergebnis. Der Bediener ist der Aktor.

Wann verwenden: Nacharbeitsplätze, Laborinspektion, Wareneingangsprüfung, Tulip-artige Cloud-MES mit Tablets, Retouren/Reverse Logistics.

Nicht empfohlen für: Hochgeschwindigkeits-Förderbänder (kein Echtzeit-Ausschuss), regulierte Umgebungen, die zertifizierte PLC-Sicherheitslogik erfordern.

Endpunkt-Sequenz (pro Inspektion):

Schritt	Methode	Pfad	Zweck
1	`POST`	`/edge/api/recipes/{plc_recipe_id}/activate`	Auf das Rezept umschalten, das dem gescannten Barcode / Auftrag entspricht.
2	`POST`	`/edge/camera/capture`	Eine einzelne Inspektion über REST auslösen.
3	`GET`	`/edge/capture_result`	Auf das neueste Ergebnis abfragen (oder MQTT für Push-Zustellung abonnieren).
4	`POST`	`/edge/v2/capture/{capture_id}/notes`	OV80i: Auftragskontext an die Aufnahme anhängen für Rückverfolgbarkeit.
5	`POST`	`/edge/camera/do`	Optional: ein Säulenleuchten-Segment aus der MES-App auslösen.

Das kanonische Inspektionsergebnis-Schema

Unabhängig von Muster oder Transport ist dies die universelle Payload. Verwenden Sie sie als Vertrag zwischen Kamera und Ihrem MES.

Feld	Typ	Erforderlich	Beispiel
`timestamp`	ISO 8601	ja	`2026-04-13T14:23:51.234Z`
`part_id`	string	ja	`SN-A7841`
`lot_id`	string	nein	`L-2026-04-13-A`
`work_order`	string	nein	`WO-78451`
`station_id`	string	ja	`STA-INSP-3`
`recipe_name`	string	ja	`Bottle 330ml v3`
`result`	enum (PASS / FAIL / INCONCLUSIVE)	ja	`PASS`
`defect_class`	string[]	nein	`["scratch", "dent"]`
`confidence`	float (0.0 bis 1.0)	nein	`0.987`
`image_ref`	URI	nein	`s3://acme-vision/2026/04/13/cap-12345.jpg`
`operator_id`	string	nein	`op.jane.doe`
`cycle_time_ms`	integer	nein	`187`

Häufige Missverständnisse

„MES teilt der Kamera mit, welches Rezept zu verwenden ist." Falsch in Standard-PLC-Architekturen. MES teilt es der PLC mit. PLC teilt es der Kamera mit. Die einzige Ausnahme ist Muster C (keine PLC).

„MES trifft die Ausschussentscheidung." Falsch. Das tut die PLC. MES trifft nur aggregierte Entscheidungen wie „Auftrag stoppen, wenn Ausschuss 2 % überschreitet."

„Die Kamera meldet direkt an MES." Falsch in Standardarchitekturen. Die Kamera meldet an die PLC. Die PLC verpackt mit Kontext und leitet an MES weiter. Die Ausnahme ist der parallele Pfad von Muster B, bei dem die Kamera ZUSÄTZLICH eine reichhaltigere Payload an MQTT/UNS für Analysen publiziert, dies läuft jedoch parallel zum PLC-Pfad.

Wie geht es weiter

Verwenden Sie den IO Helper, um Kamera + PLC + Sensoren zu verdrahten und die EDS-Datei, Bit-Mapping und MES-Integrations-Scaffolding zu generieren.
Verwenden Sie den Integration Builder, um aus einer natürlichsprachlichen Beschreibung den eigentlichen Node-RED-Flow (MQTT Publisher, OPC UA Writer, REST POST an MES usw.) zu generieren.

Was möchten Sie wissen?

Die Standardarchitektur​

Die drei Muster​

A. PLC meldet an MES (Standard)​

B. Kamera publiziert parallel zur PLC (modern parallel)​

C. Standalone (keine PLC)​

Das kanonische Inspektionsergebnis-Schema​

Häufige Missverständnisse​

Wie geht es weiter​