How to integrate AI vision with your MES or ERP system
Five machines. Five OEMs. Five tag naming conventions. The AI vision system was inspecting every part by day three. Six months later, the MES still had no quality records from three of those five lines because nobody had agreed what to call a surface scratch in the MES taxonomy. The vision system called it "surface_scratch_class_B." The MES expected "NC_CODE_0047." The ERP wanted "Quality Notification Type B." Three names. One event. Zero automatic reconciliation. And no one team owned the reconciliation work.
The system catches defects. The data goes nowhere. This is not a protocol problem. It is an ownership problem.
The data stalls at the edge
Most AI vision deployments hit the same wall. Not the detection wall. Accuracy rates are not where these projects fail. The wall is in the twelve inches between the edge device that holds the inspection result and the MES that needs to record it.
"5 machines from 5 OEMs with 5 tag standards. Vision easy; integration nightmare." That is a controls engineer who built five custom translation solutions instead of one scalable product. The vision system worked. The naming convention negotiation did not.
The aspiration layer wants AI, analytics, and quality dashboards. The floor layer is running on serial communications, manual entry, and inspection records that are, in a significant share of facilities, pencil-whipped. Between the aspiration and the reality: a gap that is not a technology problem.
Controls owns the machine and treats "machine running" as mission accomplished. IT owns the network and treats data security as the primary criterion. MES administration is a third team, often understaffed. ERP owners report to Finance, in a different building. The data model mapping exercise that connects these systems requires all four teams to agree on field definitions before any code is written.
That negotiation does not happen automatically. Most AI vision integration projects stall here. Not at the protocol layer. At the "who is responsible for this mapping and who has authority to sign off?" question.
Step 0: assign the owner before you configure anything
Before you define the data contract, before you select a protocol, before you write the translation layer: put one person's name on the integration outcome.
Not Controls. Not IT. Not the MES admin. Someone whose success criterion is specifically "quality data flows accurately from the vision system to the ERP record for every part inspected." Someone with organizational authority to convene Controls, IT, MES, and ERP when the mapping breaks.
"There isn't one team/person that owns the process end to end." That absence is the primary failure mode. When the data contract meeting is called without a designated owner, it produces a shared spreadsheet. Controls fills in the vision output fields. The MES admin fills in the NC code fields. The ERP representative fills in the quality notification field. Nobody is responsible for maintaining it. Three months post-go-live, when the vision system adds a new defect class, nobody knows whose job it is to update the map.
"ERP implementation is a business project NOT an IT project." The same principle applies to vision system integration. It is a business alignment project that requires technical execution. Without the right owner, the technical layers get built in isolation and never connect.
Three technical layers, named and sequenced
Once an owner is assigned and accountable, the technical work follows a clear sequence:
Layer 1: Part-level output (data contract). Every vision system result must emit a structured object: part ID, timestamp, result, defect class, location, confidence score. The field names in this output are the fields that Controls, MES, and ERP must agree on. Writing the data contract requires the people who own each system in the same meeting, with an outcome owner, not just attendees. "80% of AI readiness is just having clean timestamps and consistent naming conventions." That is the entire requirement for Layer 1, stated as plainly as possible.
Layer 2: Communication protocol. Protocol selection follows infrastructure, not preference. OPC-UA is the correct default for shop floor systems, native to most modern PLCs and MES platforms. REST API works for cloud ERP targets (SAP S/4HANA, Oracle Cloud). Message queues (MQTT, Kafka) handle high-throughput lines where buffering is required.
The organizational reality: OPC-UA in production requires monitoring, error handling, and someone who responds when the connection drops. "If the OPC UA server connection dropped? Nightmare. Error handling? Minimal. Monitoring? Forget it." The protocol configuration is one afternoon. The monitoring and failure-response plan is an ongoing operational commitment. It needs an owner and a runbook, not a shared inbox.
Layer 3: Data model mapping. Three names, one event, zero automatic reconciliation. The translation layer is the most important and least glamorous integration task. It is not unglamorous because it is boring. It is unglamorous because it requires negotiation with people who have different terminologies, different system constraints, and different levels of interest in quality data accuracy.
The data model map is not a one-time deliverable. Every time a new defect class is added to the vision system, the map needs an update. Without an owner, it becomes stale within 90 days of go-live. Stale maps produce unmapped fields. Unmapped fields produce null records. Null records produce ERP data that looks complete and is not. "Averaging garbage data produces confident garbage output and the ERP looks fine until someone actually checks."
Four failure modes, reordered by actual frequency
Failure Mode 0: Nobody owns it. The system is installed. The vendor leaves. The Kepware server renews its license until one year it does not. "Until the day the license renewal was missed by admin. Suddenly, a critical data link was just dead." A year of quality data, gone. Nobody knew the link existed until it failed completely. Defense: assign an owner, write a runbook, build monitoring with active alerts to a person, not a distribution list.
Failure Mode 1: Clock synchronization drift. Vision system timestamps and MES timestamps diverge by seconds or minutes. Part records become impossible to match. Fix: NTP sync across all systems, checked daily, alerted on deviation greater than 500ms. Validate that edge device, gateway, and MES timestamps are synchronized before parallel operations begin.
Failure Mode 2: Part ID mismatch. The vision system scans a barcode the MES does not yet know exists. Result: orphaned inspection records. This is particularly common in facilities transitioning from manual inspection, where work orders were created when the part arrived at inspection, not at the press. AI vision fires at the press, before the work order exists. The process sequence must change, not just the integration.
Failure Mode 3: Network resilience failures. A 4-second network drop loses 60 inspections on a fast line. Fix: local caching on the edge device, sync on reconnect. An alert that fires when the buffer overflows must create an automatic investigation task, not an inbox item. "Alerts land in maintenance tech's email, get added to backlog, machine fails anyway 3 weeks later."
Failure Mode 4: Over-integration. Connecting vision output to 6 systems simultaneously because "everything could use quality data" creates a brittle web where one downstream failure cascades. Keep initial integration to 2 systems maximum. Expand after the first pipeline is stable and monitored.
Platform-specific notes
SAP ME: Use Plant Connectivity (PCo) for OPC-UA bridging. Do not write directly to SAP tables from external systems. Plex: REST APIs for quality data via Inspection Results endpoint. Confirm field-level permissions before testing. Siemens Opcenter: Native OPC-UA. Use Integration Framework. Define Non-Conformance types before connecting. Oracle Cloud SCM: REST APIs only, OAuth 2.0. Test token refresh behavior under long shifts. Custom MES: Build an integration microservice. Never let the vision system write directly to production databases.
Three integration readiness questions
1. Who is the named integration owner, and what is their success criterion?
If the answer is "the integration team" or "Controls and IT jointly," the answer is nobody. One person, one success criterion: accurate quality data flows from the vision system to the ERP record for every part inspected.
2. Has your data model map been reviewed and approved by Controls, MES, and ERP?
Not drafted by one team and sent to the others. Reviewed, contested, amended, and signed off by all three. If three teams have not agreed in writing on the mapping between the vision taxonomy and the MES/ERP field definitions, the integration has not started.
3. What happens when the integration breaks at 2am on a Sunday?
Who gets the alert? What is the first action? Is there a runbook? Is local caching configured so inspection records survive the recovery window? If the answer is "we'll figure it out," the integration is not ready for production.
One additional framing to expect: when AI vision data starts flowing to ERP, quality records will initially look worse. "An ERP migration exposes the areas of your business that were succeeding by accident." Vision data flowing to ERP does not just add a quality data layer. It replaces pencil-whipped inspection records with accurate ones. The ERP will tell the truth about quality for the first time. That is not a sign of integration failure. It is the integration working.
The technology is ready. The integration work is not automatic.
HyperQ AI Vision connects directly to common MES and ERP platforms via PROFINET, EtherNet/IP, and OPC-UA without a bridging layer. No middleware project at deployment. No custom translation layer to maintain. Inspection results (defect classification, dimensional data, batch ID, serial number) enter production workflows in real time with sub-1-second latency from inspection event to MES record. For facilities that need the integration to work on day one, we build the data contract into the deployment scope. Talk to us about your integration challenge.