Most Australian factories have Programmable Logic Controllers (PLCs) and SCADA systems running their operations. These systems have been collecting data for years—often decades.

Now AI applications want that data. But connecting traditional automation to modern AI isn’t always straightforward.

I’ve helped numerous manufacturers work through this integration. Here’s what I’ve learned.

The data sitting in your automation systems

PLCs and SCADA systems capture a wealth of operational data:

Process variables: Temperatures, pressures, flow rates, levels, speeds. The fundamental measurements of your process.

Equipment states: Motor running, valve open, alarm active. What’s happening right now.

Setpoints and commands: What operators and control systems are telling equipment to do.

Event logs: Alarms, state changes, operator actions. What happened and when.

Batch data: For batch processes, records of each run—parameters used, times, results.

This data can feed AI applications for predictive maintenance, process optimisation, quality prediction, energy management, and more.

But getting it out isn’t always easy.

Why integration is harder than it sounds

Proprietary protocols

Older PLCs often use proprietary communication protocols. Connecting requires vendor-specific drivers or converters.

Even within brands, protocol versions vary. A 15-year-old PLC might not speak the same language as modern IT systems.

Network isolation

Industrial networks are (rightly) isolated from business and internet networks. Security requirements mean you can’t just connect an AI platform to the SCADA network.

Designing secure data paths that protect operations while enabling analytics takes thought.

Data volume and frequency

Some processes generate data every millisecond. That’s 86 million data points per day from a single sensor.

Not all of this needs to reach AI systems. But deciding what to send, at what frequency, and how to aggregate requires understanding both the process and the AI application.

Context and metadata

Raw PLC data is just numbers and states. Making it meaningful requires context.

What does Tag123 represent? Is that temperature in Celsius or Fahrenheit? Which machine is this data from? What product was running?

Mapping and enriching raw data into something AI can use takes work.

Integration architectures

Edge-based approach

Deploy a computing device at the edge (near the PLCs/SCADA) that:

• Collects data from automation systems
• Performs initial processing and filtering
• Buffers data to handle network outages
• Sends data to cloud or enterprise AI systems

This is increasingly common. Edge devices handle real-time collection while cloud systems handle heavy analytics.

SCADA/Historian extension

If you have a historian (like OSIsoft PI, Wonderware Historian, or AVEVA) already collecting SCADA data, extend it to feed AI systems.

Historians are designed for exactly this—collecting, storing, and providing industrial data. Adding a connector to AI platforms is often simpler than starting from scratch.

Direct cloud connection

Modern PLCs and edge gateways can send data directly to cloud platforms (AWS, Azure, GCP).

This works for smaller deployments or where security architecture permits. For larger operations, edge aggregation is usually still needed.

Middleware platforms

Products like Ignition, KEPServerEX, or CloudRail specialise in industrial data collection and distribution.

They handle protocol translation, data buffering, and security—providing a unified interface for AI applications.

Protocol options

OPC-UA

The modern standard for industrial data exchange. Most current automation systems support OPC-UA. AI platforms generally can consume OPC-UA data.

If your systems support OPC-UA, this is usually the cleanest path.

MQTT

A lightweight messaging protocol popular in IoT. Many edge gateways can publish automation data to MQTT brokers, which AI applications can subscribe to.

Good for high-volume, real-time data streams.

REST APIs

Web-style interfaces. Not every automation system supports these natively, but middleware or edge devices can provide REST access to automation data.

Easy for IT/data science teams to work with.

Legacy protocols

Older systems might only support Modbus, older OPC (OPC-DA), or proprietary protocols. Gateways and middleware can translate these to modern standards.

Security considerations

Connecting production automation to AI systems creates security risks. Take them seriously.

Network segmentation

Never connect PLCs directly to the internet or business networks. Use properly configured firewalls and DMZ architectures.

Data should flow through secure gateways that enforce access controls and monitor traffic.

Read-only connections

AI systems reading data is one thing. AI systems writing to control systems is another entirely.

For most applications, the connection should be strictly one-way—data out, nothing in. Any write capability requires rigorous security review.

Authentication and encryption

Data in transit should be encrypted. Access should require authentication. These are basic IT security practices, but industrial environments sometimes lag.

Change management

Document integration points. Test changes before deploying. Have rollback plans. Treat automation connectivity with the same discipline as control system changes.

Practical implementation steps

Step 1: Inventory your systems

What PLCs do you have? What versions? What protocols do they support?

What SCADA system? What historian? What connectivity options exist?

You can’t plan integration without knowing what you’re integrating.

Step 2: Define data requirements

What data does your AI application need?

Be specific. “Process data” is too vague. “Temperature readings from reactor 1 at 5-second intervals, with associated batch context” is actionable.

Work backwards from AI requirements to source systems.

Step 3: Design the architecture

Based on your systems and requirements, design how data will flow.

Consider:

• Collection points (edge devices, historians, direct connections)
• Protocols and interfaces
• Security architecture
• Buffering and reliability
• Scaling as data needs grow

Step 4: Start with a pilot

Don’t try to connect everything at once. Start with one process area, one AI application.

Prove the architecture works before scaling.

Step 5: Build operational processes

Integration isn’t just technology. It’s also:

• Monitoring for failures
• Updating configurations as processes change
• Troubleshooting issues
• Managing access and security

Build these operational capabilities alongside the technical implementation.

Common pitfalls

Underestimating network and security complexity

IT and OT integration is hard. Security requirements, network architecture, change management—these often take longer than the technical data connection.

Ignoring data quality issues

Just because data is in the historian doesn’t mean it’s right. Sensors fail, calibrations drift, tags get misconfigured. Data validation is essential.

Moving too much data

It’s tempting to extract everything. But unnecessary data creates cost, complexity, and potential security exposure.

Extract what you need, not everything you can.

Not involving operations

Control engineers and operators understand what the data means and how processes work. Involve them in defining what data to extract and how to interpret it.

IT and data science teams can’t do this alone.

When to get help

PLC/SCADA to AI integration sits at the intersection of multiple technical disciplines—industrial automation, IT infrastructure, data engineering, cybersecurity.

Few organisations have all these skills in-house. Working with specialists who’ve done it before can significantly accelerate implementation and avoid costly mistakes.

Team400 and similar AI consulting firms work with manufacturers on exactly these integrations, bridging the gap between traditional automation and modern AI.

The investment is worth it

Yes, connecting legacy automation to AI takes effort. But the data sitting in your PLCs and historians is valuable.

Predictive maintenance can reduce downtime and maintenance costs. Process optimisation can improve yield and quality. Energy management can cut costs.

These benefits depend on getting the data out. The integration investment is the foundation for everything that follows.

Start with a clear use case, plan the architecture carefully, and get help where you need it. The payoff from AI consultants Melbourne and their expertise in this specific area often exceeds the cost many times over.

Your automation systems have been collecting data for years. It’s time to put that data to work.