I often get asked how to add modern AI capabilities to a brownfield plant without ripping out the PLCs that keep production running. In practice, the most practical and least risky path is to introduce a vendor‑agnostic edge layer that sits between your PLCs and the cloud, normalizes data, and provides a place to run models, orchestrate logic, and export only the insights you need. I’ve built this pattern multiple times across automotive and food lines, and in this article I’ll walk through the architecture, protocols, engineering decisions, and deployment checklist that make these projects succeed.
Why an edge layer, and why vendor‑agnostic?
From day one I treat brownfield integration as an exercise in risk management. PLCs are deterministic machines designed for safety and availability; touching ladder logic or replacing control hardware is costly and risky. An edge layer lets you:
Keep legacy PLCs and their control logic untouched.Aggregate and normalize data from multiple PLC brands and protocols.Run inference and light pre‑processing locally to meet latency, bandwidth, and resiliency requirements.Present a consistent API to downstream systems (MES, historian, cloud) so apps and AI models are vendor‑agnostic.Vendor‑agnostic means you can swap PLCs, change cloud providers, or adopt new analytics tools without a forklift overhaul of your integration layer. It also prevents vendor lock‑in and simplifies lifecycle management.
Core components of a vendor‑agnostic edge layer
A practical, production‑ready edge architecture typically includes the following components. I focus on minimalism—only what you need to be reliable and maintainable in an industrial environment.
Protocol adapters / collectors: OPC UA servers/clients, Modbus TCP/RTU gateways, Ethernet/IP scanners, and MQTT bridges. These adapters read PLC tags and expose data to the local edge runtime.Data normalization: A semantic layer that maps raw PLC addresses to named signals, units, and metadata. This is the glue that makes your edge vendor‑agnostic.Local historian / buffer: A lightweight time‑series store (e.g., InfluxDB, SQLite with time indexing, or file‑backed circular buffer) for resilience against network outages.Edge compute runtime: A containerized or modular runtime to host preprocessing, control logic, and ML inference (examples: Docker, Kubernetes K3s, Azure IoT Edge, AWS IoT Greengrass—but you can remain cloud‑neutral).Model management & inference: Support for ONNX, TensorFlow Lite, or other portable runtime formats so you can deploy models created offline without tying to a single vendor.Northbound connectors: MQTT, AMQP, HTTPS, or OPC UA Pub/Sub to push events, metrics, and model outputs to MES, cloud, or visualization tools.Security & device management: TLS, mutual auth, secure boot, a remote agent for configuration and software updates, and role‑based access controls.Protocols: what to connect and how
My rule is: speak native to the PLC, and normalize immediately. For modern PLCs, OPC UA is ideal because it carries metadata and supports secure channels. For older PLCs, you’ll typically use Modbus, EtherNet/IP, PROFINET (with gateways), or even serial RTU. A couple of practical tips:
Use dedicated protocol gateways or industrial routers when you can’t install a collector on the same network segment as the PLC.Prefer read‑only access where possible. If you need writebacks, isolate them and add operator approvals in the control room.Keep polling rates reasonable. High frequency for control signals, lower frequency for slow telemetry. Think about what the AI model actually needs—many models thrive on aggregated or windowed features rather than raw high‑frequency samples.Data normalization and semantic mapping
Raw PLC tags are noisy: addresses, bit masks, vendor naming conventions. I always create a semantic mapping layer as part of the edge configuration. This includes:
a stable signal name (e.g., line1_stn3_temp)units and scaling (°C vs raw ADC counts)quality flagssource metadata (PLC model, slot, address)Store this mapping in a versioned configuration file (YAML/JSON) or a small local database. It’s the single most valuable asset for long‑term maintainability: when someone replaces PLC hardware, you only change the mapping, not all your analytics rules or dashboards.
Running AI at the edge: models, formats, and lifecycles
Edge model deployment is less exotic than it sounds. I take a pragmatic approach:
Train models in the cloud or on-premise using historical data from your historian or data lake.Export models to portable formats like ONNX or TensorFlow Lite so they run on different runtimes.Use a small inference runtime on the edge device. For CPU inference, tools like ONNX Runtime or TensorRT (for NVIDIA hardware) work well.Keep models simple. Interpretability and robustness matter more than squeezing out a small accuracy gain with a massive model that will be hard to update.Operational considerations:
Version models and tag them with metadata (training data window, hyperparameters, expected input schema).Shadow mode before control: run the model in read‑only mode to compare predictions vs ground truth before you trust it to act.Monitor inference drift and model performance metrics at the edge and upstream.Architectural patterns I use
These are patterns that have proven reliable in production:
Gateway pattern: A hardened Linux/industrial PC running collectors and a local runtime. Exposes normalized API to the plant network and to the cloud.Microservices on edge: Break functionality into small services: collector, normalizer, inference, local historian, uploader. This makes updates safer.Event-driven streams: Use MQTT or OPC UA Pub/Sub for near‑real‑time alerts, and time‑series exports for batch analytics.Dual path for data: Keep a fast path (alerts, model outputs) and a slow path (bulk telemetry uploads) to optimize bandwidth.Security, reliability and change control
Nothing undermines a deployment faster than a security incident or an untested change that tripped the PLCs. My recommendations:
Network segmentation: Put edge devices in their own VLAN and use industrial firewalls. Limit northbound access.Mutual TLS and certificate rotation for all connections.Principle of least privilege: collectors should not have write access to PLCs unless absolutely necessary.Automated backups of mappings and configurations, and a tested rollback plan for new edge software versions.Change management and a maintenance window policy. Treat edge software updates like PLC firmware—test in a staging environment before pushing to production.KPIs and validation for an edge+AI rollout
Before I deploy, I define success criteria with operations and quality teams. Useful KPIs include:
Model accuracy / false positive rate on production data.End‑to‑end latency (sensor -> inference -> action).Uptime of the edge node and data completeness during network outages.Reduction in reaction time to quality events or improvement in yield.Run a pilot on a single line or cell. I rely on A/B testing or shadow mode comparisons for at least two production weeks to gather robust statistics before scaling.
Common pitfalls and how I avoid them
Over the years I’ve seen recurring mistakes. Here’s how I mitigate them:
Too much data, too soon: Start with the signals you know are useful. Add more once you’ve proven the pipeline.Assuming network availability: Design with intermittent connectivity in mind. Local buffering and graceful degradation are non‑negotiable.Vendor lock‑in: Use open formats and portable model runtimes.Skipping operations buy‑in: Involve operators early. If a system is opaque to the people running the line, it will be ignored or disabled.Quick implementation checklist
| Phase | Essential actions |
| Discovery | Inventory PLCs/protocols, identify critical signals, collect sample data |
| Design | Define mapping schema, choose edge hardware, select inference format |
| Pilot | Deploy on one cell, run models in shadow, measure KPIs |
| Scale | Harden security, automate deployment, roll out to other lines |
| Operate | Monitor model drift, rotate certificates, maintain mapping repository |
If you’re starting this journey, begin with a focused pilot that preserves existing PLCs and proves value quickly. Use a semantic mapping layer and portable model runtimes to keep the design vendor‑agnostic. And importantly, collaborate with your operations team from day one—technical elegance alone won’t win the day unless it fits seamlessly into the plant’s operational reality.
