MES & PLC Integration Patterns

This page is the controls engineer's reference for how the camera fits into a real plant. It pairs with the Integration Builder (which generates the Node-RED flows) and the IO Helper (which generates the wiring + the API call sequences).

The standard architecture

In 90% of installs, the path is MES → PLC → Camera, never MES → Camera directly.

                        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

Key facts:

• The PLC makes the per-part reject decision. It must respond in milliseconds. MES cannot do this (too slow, non-deterministic).
• The camera reports pass/fail to the PLC, not directly to MES.
• Recipe selection flows through the PLC. MES may decide which recipe should run, but the PLC writes the recipe ID to the camera (via EtherNet/IP O.Data[4-5] or the equivalent PROFINET word).
• MES receives contextualized events from the PLC (work order, lot, serial, station, recipe, pass/fail, defect class) and makes aggregate decisions (hold the order if scrap rate exceeds threshold, alert the quality engineer, update OEE).
• A PLC shift register synchronizes the inspection result with the downstream reject gate position, indexed by encoder pulses.

The three patterns

A. PLC reports to MES (standard)

The default pattern. PLC handles real-time reject. PLC packages the result with work order context and forwards it up to MES via OPC UA or MQTT.

When to use: any production line with a PLC. Common in automotive, packaging, food/beverage, pharma.

Endpoint sequence (set up once during commissioning):

Step	Method	Path	Purpose
1	GET	/edge/download/industrial_ethernet/ethernet_ip_eds	Download EDS file (firmware-matched). Give to PLC programmer.
2	POST	/edge/recipe/change_plc_recipe_id	Map camera recipes to PLC-friendly IDs (1, 2, 3...) that match MES SKU codes.
3	POST	/edge/environmental_variables	Persist plant context (line code, MES URL) for the Node-RED flow.
4	GET	/edge/nodered/flow	Read the active recipe Node-RED flow.
5	POST	/edge/nodered/flow	Deploy the updated flow with the OPC UA / MQTT publisher.

B. Camera publishes alongside PLC (modern parallel)

PLC still handles the reject. Camera ALSO publishes a richer payload (image_ref, defect class, confidence) directly to MQTT or OPC UA for the historian, dashboards, and AI training. Runs alongside the PLC path, not instead of it.

When to use: plants with a Unified Namespace initiative (HiveMQ + Ignition + Grafana, Litmus Edge, HighByte). Greenfield Industry 4.0 sites.

Endpoint sequence:

Step	Method	Path	Purpose
1	GET	/edge/nodered/flow	Read the active flow.
2	POST	/edge/nodered/flow	Deploy a flow with mqtt-out (or sparkplug-out) targeting your broker.
3	GET	/edge/capture_result	Optional: backfill historic results during initial sync.
4	GET	/edge/capture_result/{capture_id}/heatmap	OV80i: pull the defect heatmap PNG for failed inspections.

The camera ships with a built-in MQTT broker on ws://{camera_ip}:9001/mqtt, so small deployments do not need an external broker.

C. Standalone (no PLC)

No production PLC. An operator app or cloud MES talks directly to the camera over REST: pulls work order, switches recipe, triggers inspection, gets result. The operator is the actuator.

When to use: rework benches, lab inspection, incoming inspection, Tulip-style cloud MES with tablets, returns/reverse logistics.

Not recommended for: high-speed conveyor lines (no real-time reject), regulated environments needing certified PLC safety logic.

Endpoint sequence (per inspection):

Step	Method	Path	Purpose
1	POST	/edge/api/recipes/{plc_recipe_id}/activate	Switch to the recipe matching the scanned barcode / work order.
2	POST	/edge/camera/capture	Trigger a single inspection via REST.
3	GET	/edge/capture_result	Poll for the latest result (or subscribe to MQTT for push delivery).
4	POST	/edge/v2/capture/{capture_id}/notes	OV80i: attach work-order context to the capture for traceability.
5	POST	/edge/camera/do	Optional: fire a stack-light segment from the MES app.

The canonical inspection result schema

Regardless of pattern or transport, this is the universal payload. Use it as the contract between the camera and your MES.

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

Common misconceptions

"MES tells the camera which recipe to use." Wrong in standard PLC architectures. MES tells the PLC. PLC tells the camera. The only exception is Pattern C (no PLC).

"MES makes the reject decision." Wrong. The PLC does. MES only makes aggregate decisions like "hold the order if scrap exceeds 2%."

"The camera reports directly to MES." Wrong in standard architectures. The camera reports to the PLC. The PLC packages with context and forwards to MES. The exception is Pattern B's parallel path, where the camera ALSO publishes a richer payload to MQTT/UNS for analytics, but this runs alongside the PLC path.

Where to go next

• Use the IO Helper to wire the camera + PLC + sensors and generate the EDS file, bit mapping, and MES integration scaffolding.
• Use the Integration Builder to generate the actual Node-RED flow (MQTT publisher, OPC UA writer, REST POST to MES, etc.) from a natural-language description.