The best AI model in the world is useless if it cannot reach the machine. That is the reality in many manufacturing plants: there are impressive algorithms for quality control, predictive maintenance, or process optimization. But between the Python script on the server and the PLC on the machine, there is a gap that causes many projects to fail.

In this post, I explain how OPC-UA and AI integration works, what alternatives exist, and what production managers should consider before starting an AI project.

The problem: AI without machine connectivity is worthless

I see this regularly: a company invests in an AI model, trains it on historical data, achieves good results in testing. Then comes the question that brings everything to a halt: how do live data get from the machine into the model? And how does the result get back?

Without a clean machine connection, AI remains a lab experiment. The connectivity piece is not a side project. It is the central technical challenge in any industrial AI application. Underestimate this part and you lose months.

What is OPC-UA and why is it the standard?

OPC-UA (Open Platform Communications Unified Architecture) is a vendor-independent communication protocol for industry. It was specifically designed to provide machine data in a secure and structured way.

The key advantages:

Vendor-independent: Works with Siemens, Beckhoff, B&R, Rockwell, and many others
Structured data: Not just raw values, but semantic information models with data types, units, and descriptions
Security: Encryption and authentication are built in from the start
Platform-independent: Runs on Windows, Linux, embedded systems
Widely adopted in European manufacturing: Most modern PLC systems have OPC-UA already integrated

For machine connectivity in Austrian and Central European manufacturing, OPC-UA is the de facto standard. In practical terms, this means I can access machine data directly from a Python-based AI model without proprietary drivers or expensive middleware.

The bridge: from PLC to AI model and back

The typical data flow when connecting a PLC to an AI system looks like this:

Step 1 - PLC provides data: The controller (for example a Siemens S7-1500 or Beckhoff TwinCAT) exposes process data through its built-in OPC-UA server. These are temperatures, pressures, speeds, piece counts, error codes, and status information.
Step 2 - OPC-UA client reads data: An OPC-UA client on an edge device or server reads this data cyclically or event-driven. In Python, I use the opcua-asyncio library for this, which allows asynchronous access to the OPC-UA server.
Step 3 - AI model processes: The data flows into the AI model. This can be a trained neural network, an anomaly detector, a classical machine learning algorithm, or even a rule-based system with AI support.
Step 4 - Result goes back: The result is returned. Either as a visualization on a dashboard, as an alert to the operator, or - after approval - as a write command back to the PLC.

With Siemens and Beckhoff, the OPC-UA server is usually already built into the controller. For Siemens, I activate the server in the TIA Portal. For Beckhoff, it runs as a TwinCAT module. Configuration typically takes a few hours, not days.

Real-time requirements: not every application needs milliseconds

A common misconception: many people think industrial AI always needs to run in hard real-time. That is only true for a small fraction of applications.

Monitoring and predictive maintenance: Sampling rates of one to ten seconds are perfectly sufficient. A machine does not wear out in milliseconds. Here, reliability matters more than speed.
Quality control with camera systems: Here I need cycle times in the range of a few hundred milliseconds, depending on production pace. OPC-UA can deliver that.
Direct control interventions in the process: Here I need to get below the PLC cycle time. With standard OPC-UA alone, that is often not possible. For these cases, there is OPC-UA PubSub combined with TSN (Time-Sensitive Networking), or I work directly on the PLC.

The good news: the vast majority of AI applications in manufacturing fall into the first two categories. OPC-UA is well suited for those.

Alternatives to OPC-UA: when which protocol makes sense

OPC-UA is not always the best or only sensible choice. Depending on the situation, I also use other protocols:

MQTT: Lightweight, ideal for IoT scenarios with many distributed sensors. Combines well with OPC-UA via Sparkplug B. Particularly strong when data needs to be collected across multiple sites.
Modbus TCP: Simple, widely used with older machines. No semantic structure, but fast to implement. Often the most pragmatic solution for brownfield installations.
Digital I/O: For simple signals (pass/fail, start/stop), sometimes the fastest and most reliable solution. No configuration, no network issues.
REST/HTTP: When data already exists in an MES or historian, an API call can make more sense than direct PLC access.

In practice, I often use a combination: OPC-UA for core data from the PLC, MQTT for additional sensor data, REST for historical data from existing systems.

Practical challenges: IT versus OT

The biggest hurdle in machine connectivity is rarely the technology. It is the organization.

Firewalls between IT and OT networks: OPC-UA uses port 4840 by default. This port needs to be opened, which in many companies requires a change request and multiple rounds of coordination.
Access to the PLC: Production managers and machine operators are rightfully cautious. Nobody wants an external connection to disrupt production or, in the worst case, shut it down.
Different responsibilities: IT manages the network, OT manages the machines. AI projects need both sides at the table, and they often speak different languages.
Missing documentation: With older equipment, PLC documentation is often incomplete or nonexistent. What variables are available? What do they mean? Which data block are they in? This takes time and requires collaboration with machine operators.

I recommend addressing these topics early. Not when the AI model is finished and waiting for data.

My approach: non-invasive, step by step

With every project, I follow a clear principle: start non-invasively.

Phase 1 - Read only: I connect to the PLC in read-only mode. No write access, no intervention in the control system. This minimizes risk to practically zero and builds trust.
Phase 2 - Validate data: I check whether the data being read is plausible, whether the OPC-UA server runs stably, whether the network connection is reliable. Often, valuable process insights emerge already at this stage.
Phase 3 - Connect the AI model: Only when data quality is confirmed do I connect the AI model. Results initially go only to a dashboard or a log file.
Phase 4 - Controlled write-back: If desired and validated, I write results back to the PLC. Always with approval from the machine operator, never automatically without safeguards.

This approach has proven effective because it builds trust. Production staff can see that nothing happens before they approve it.

What production managers should know before getting started

If you are considering AI in production, here are my concrete recommendations:

Check PLC type and firmware: Does the controller have an OPC-UA server? With Siemens S7-1500 and Beckhoff TwinCAT 3, this is standard. With older systems like the S7-300, you may need a gateway.
Involve IT early: Network permissions and firewall rules need lead time. Plan at least two to four weeks for this.
Prepare a variable list: The better documented it is which process data are available and what they mean, the faster the integration goes.
Start small: Begin with a single data point and a simple analysis. Not with the entire system.
Set realistic expectations: Machine connectivity is often the most time-consuming part of an AI project. Not the model training, not the algorithms. The connection to the real world.

The bridge between PLC and AI is not rocket science. But it requires care, coordination between departments, and a step-by-step approach. Get that right and you have the best foundation for a successful AI project in manufacturing.

OPC-UA and AI: How Machines Talk to Algorithms