# AI for Kepware KEPServerEX: Linking Shop-Floor Tags to ERP Work Orders, Read-Only > Source: https://netray.co/erp-ai/kepware-kepserverex-ai-integration > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: AI for ERP ## Short answer AI for Kepware KEPServerEX reads machine data that the server already exposes through OPC UA, MQTT or logged SQL tables and joins it to ERP work orders, routings and downtime reasons, so engineers can ask why a line stopped or which jobs ran slow. The AI is read-only toward the plant floor and runs on-prem inside your network. ## Kind platform ## Erp Family mfg-systems ## Erp Products - Kepware KEPServerEX ## Industries - Manufacturing - Aerospace - Defense - Electronics - Automotive ## Region Global ## Persona Controls Engineer ## Eyebrow Kepware + shop-floor AI ## Intro KEPServerEX is the connectivity layer many plants use to turn PLC and machine protocols into something the rest of the business can consume. Channels and devices speak Allen-Bradley, Siemens, Modbus, Fanuc and many other drivers; tags are published to OPC UA clients, historians, MES and, through the IoT Gateway, to MQTT or REST consumers. The gap is usually between that stream of tag values and the ERP. The ERP knows the work order, routing operation, planned run rate and scrap codes. Kepware knows that machine 14 stopped at 02:13 and its cycle counter climbed more slowly all week. Joining the two usually means a custom historian query or a spreadsheet an engineer maintains. AI is useful for the analysis between them, not for control. A model can read logged tag data, match it against work order and routing data, and answer questions such as which jobs ran below standard rate, what the stoppage pattern looked like, or whether a new tag mapping makes sense. It should not write to a tag or send a command to any machine. This page describes a safe pattern for that, what Kepware features it uses, and the security boundaries that matter in a plant, including defense and aerospace sites where the network is segmented or air-gapped. ## Pain Points ### Tag data and work orders live apart **Detail:** Machine counters and states sit in Kepware, a historian or SQL; the work order, routing and standard hours sit in the ERP. Reconciling them is manual and often done once a month. ### Downtime reasons are inconsistent **Detail:** Operators select reasons in an MES or on a panel, but codes are inconsistent. Without a way to read free text and states together, root cause reporting is thin. ### Tag configuration grows messy **Detail:** Large projects accumulate channels, devices, tag groups and scaling settings built over years. Naming conventions drift and nobody is certain which tags are still used. ### Security rules restrict cloud analytics **Detail:** Plants following IEC 62443 style zoning, or defense sites with controlled networks, cannot send machine data to a public AI service. ### Controls staff are stretched **Detail:** The same few engineers handle commissioning, connectivity, and requests for reports. Ad hoc analysis competes with maintenance work. ## Use Cases ### Work order run-rate review **Description:** Compare actual cycle counts and run states from logged tags with the ERP work order, planned rate and quantity completed. **Erp Objects:** Work order and routing operation tables, planned run time and standard rate, production reporting entries; Kepware Data Logger tables **Outcome:** Slow jobs and unreported downtime become visible weekly instead of at month-end. ### Downtime narrative **Description:** Ask what happened on a machine last shift and get a timeline from state tags, alarms and operator reasons. **Erp Objects:** State, alarm and counter tags via OPC UA or logged SQL; ERP work order in progress **Outcome:** Faster shift handover and root cause meetings, with evidence attached. ### Tag configuration review **Description:** Analyze exported project files and the Configuration API output for duplicate tags, inconsistent names and unused groups. **Erp Objects:** Kepware channels, devices, tag groups and scaling settings; ERP work center and machine master naming **Outcome:** A clean-up list that engineers review; a more consistent project for future ERP mapping. ### Machine to work center mapping **Description:** Propose mappings between device names in Kepware and work centers in the ERP for engineer approval. **Erp Objects:** Kepware device names, ERP work center and resource master **Outcome:** A reviewed mapping table created in an hour rather than a day of cross-checking. ### Scrap and quality correlation **Description:** Look for relationships between process tags such as temperature or pressure and scrap codes recorded against the work order. **Erp Objects:** Process tags, ERP scrap and rework transactions, inspection results **Outcome:** Candidate relationships for process engineers to test; not an automatic conclusion. ### OEE questions in plain English **Description:** Ask for availability, performance and quality by machine and period, with the calculation shown. **Erp Objects:** Run state tags, counters, ERP quantity good and scrap **Outcome:** OEE reports built from the same data sources and shown with their formula, easy for engineers to challenge. ### Commissioning documentation **Description:** Generate a plain description of a Kepware project: devices, protocols, tag counts and what each group represents. **Erp Objects:** Project file export, device lists, ERP asset records **Outcome:** Handover documents for sites where the original integrator has gone. ## Architecture **Overview:** Data moves one way, from Kepware outward. Logged tags land in a SQL table or an MQTT consumer inside the plant network, the AI layer reads from there and from the ERP, and no path leads back to controllers. **Layers:** #### Kepware data paths **Detail:** Existing outputs: OPC UA server endpoints, the IoT Gateway for MQTT or REST, or the Data Logger writing to a database over ODBC. #### Plant data store **Detail:** A time-series or SQL store inside the plant network holding tag history, kept separate from controller networks. #### ERP read access **Detail:** Read-only access to work order, routing, resource and scrap data via views or API. #### Private model serving **Detail:** Open-weight models on a GPU node in the plant or site data center, with no outbound internet requirement. #### Analysis interface **Detail:** Natural-language questions answered with the underlying query and time window displayed, and configuration review produced as reports. ## Deployment Options ### Air-gapped plant node **Fit:** Defense, aerospace and sites with segmented networks **Detail:** Model and data store inside the plant zone; updates delivered by controlled media; no internet dependency. ### Site data center **Fit:** Multi-line plants with IT-managed servers **Detail:** Model hosted beside the historian and ERP replica, reachable only from approved subnets. ### Configuration review only **Fit:** Teams wanting low-risk first steps **Detail:** Analyze exported Kepware project files and documentation without live tag data. ## Compliance ### Data flows outward through a controlled conduit; the AI node sits above the control zone and has no path to controllers. **Framework:** IEC 62443 and zone and conduit design ### Read-only design, minimal access and logged queries align with its recommendations for industrial networks. **Framework:** NIST SP 800-82 guidance ### Running entirely in your enclave keeps technical and production data inside the boundary you already control. **Framework:** ITAR, EAR and CUI environments ### The AI is never part of a safety function and cannot write to any tag or command any equipment. **Framework:** Safety systems separation ## Integration Notes - Prefer data already produced by Kepware: the Data Logger for SQL history, the IoT Gateway for MQTT, or the OPC UA server for live reads. - The OPC UA server typically listens on a configured endpoint; use a read-only UA user and certificate trust lists, never anonymous write access. - The Configuration API is useful for exporting project structure; give it a read-only role and restrict it by network. - Use consistent tag naming such as plant, line, machine, signal, so joins to ERP work centers are mechanical. - Log timestamps in UTC and record the time zone of the ERP for the join; shift boundaries cause most reconciliation errors. - Do not expose write-enabled tags to the analysis path. Use tag-level access controls to enforce read-only at the source. ## Product Fit ### DataRay **Why:** Chat with logged tag data, SQL tables and engineering documents on-prem without sending them out. ### ERPray **Why:** Joins production data to work orders and routings in the ERP, with query transparency. ### Custom build **Why:** Site-specific OEE definitions, mappings and alert logic. ## Engagement ### Site survey **Duration:** 1-2 weeks **Deliverables:** - Map of Kepware channels, devices and outputs - Network zone review with IT and controls - Selection of machines and work centers for a pilot ### Data bridge **Duration:** 2-4 weeks **Deliverables:** - Plant data store fed from Kepware - Machine to work center mapping reviewed by engineers - Read-only ERP access set up ### Analysis pilot **Duration:** 3-4 weeks **Deliverables:** - Private model on a plant node - Run-rate and downtime questions on pilot machines - Comparison against existing manual reports ### Handover **Duration:** 2 weeks **Deliverables:** - Runbook for controls and IT - Security review sign-off - Expansion plan for further lines ## Buyer Questions - Is there any path from the AI system back to controllers or tags? - Does the system need internet access, or can it run air-gapped? - Which Kepware outputs do you use, and do they require extra licensed features? - How do you reconcile time zones and shift boundaries with the ERP? - Who validates the machine to work center mapping? - How are OEE or downtime figures calculated, and can we inspect the formula? - How is the model updated in a segmented network? ## Faq ### Can the AI write values to PLCs through Kepware? **Answer:** No, and it should not. The design is read-only: data flows out of Kepware to a plant data store, and there is no write path from the AI to tags or controllers. Enforce this with read-only OPC UA credentials and tag access settings at the source. ### Which Kepware features does it rely on? **Answer:** Usually the Data Logger for SQL history, the IoT Gateway for MQTT or REST, or the OPC UA server for live reads. Some features may need separate licensing, so we confirm what your installation already has before designing a data path. ### Does this replace an MES or historian? **Answer:** No. It adds natural-language analysis on top of data they or Kepware already collect. If you already have an MES with good OEE and downtime reporting, you may not need anything more. ### Can it run in an air-gapped plant? **Answer:** Yes. Open-weight models run locally on a GPU node, with the data store and ERP replica inside the same zone. Updates arrive by controlled media under your change process. ### How does it link a machine to an ERP work order? **Answer:** Through a reviewed mapping between device or tag names and ERP work centers, then by time window against the work order in progress. Engineers approve the mapping because errors there corrupt every later answer. ### Is machine data used to train a model? **Answer:** No. Retrieval happens at question time over your data. Any fine-tuning on plant data would be a separate decision, scoped and approved by you. ### How much data history is needed? **Answer:** Useful answers about recent shifts need only days of history. Pattern analysis such as scrap correlation is better with several months. Storage depends on tag count and logging rate, which we size in the site survey. ## Search terms Kepware KEPServerEX AI, KEPServerEX ERP integration, OPC UA data to ERP, Kepware Data Logger SQL, Kepware IoT Gateway MQTT, shop floor data ERP work order, OEE from OPC UA tags, air-gapped manufacturing AI, Kepware configuration API, machine downtime analysis AI, IEC 62443 manufacturing AI --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json