The Future of PLCs: Programming, Connectivity, Security and Virtual Controllers
On this page
PLCs change slowly. A controller installed today may run for 15 years or more, and plants value stability over novelty. Even so, the way PLCs are programmed, connected and secured has changed a lot in the last decade. This article separates the trends that are already practical from those that are emerging, and explains what each means for engineers planning new projects or upgrades.
Summary: what is mature and what is emerging
| Trend | Status (2026) | What to do now |
|---|---|---|
| Ethernet-based fieldbuses (PROFINET, EtherNet/IP, EtherCAT) | Mainstream | Default choice for new machines and lines |
| OPC UA servers in controllers | Widely available | Specify OPC UA for SCADA/MES/edge data access where supported |
| Structured, object-oriented IEC 61131-3 code | Mainstream on modern platforms | Adopt coding standards and reusable libraries |
| Version control and automated testing for PLC code | Growing adoption | Store exported code in version control; use simulation for testing |
| Security features (IEC 62443-certified controllers, secure protocols, user management) | Available on current product lines | Enable them; plan network segmentation regardless |
| MQTT / Sparkplug B from controllers or edge gateways | Growing adoption | Use via edge gateways or native support where it fits the architecture |
| Ethernet-APL for process instruments | Early deployment | Evaluate for new process plants |
| TSN (Time-Sensitive Networking) | Emerging | Watch; plan for converged networks in the long term |
| Virtual / software-defined PLCs | Early deployment by several vendors | Pilot for non-safety applications with suitable infrastructure |
| AI-assisted engineering (code generation, documentation) | Emerging | Use with review and testing; never deploy unreviewed code |
1. Programming: from ladder-only to software engineering
Ladder Diagram is still the best choice for much interlock and discrete logic because technicians can read it online. What has changed is everything around it:
- IEC 61131-3 third edition (2013) added object-oriented features such as methods, interfaces and inheritance for function blocks. Platforms that support them make it easier to build reusable equipment modules.
- Structured Text is used more for calculations, data handling and algorithms.
- Libraries and templates (a standard motor, valve or analog input block used everywhere) make large projects consistent and faster to commission. See PLC Programming Best Practices.
- Version control: exporting code to text formats (for example PLCopen XML or vendor-specific exports) lets teams use Git-style version control, compare changes and review code.
- Simulation and virtual commissioning: logic is tested against a simulated machine or process model before site work, shortening commissioning.
- IEC 61499 defines a distributed, event-driven function block model aimed at portability between devices. It has active adoption in some areas but is far less common than IEC 61131-3.
Implication for engineers: PLC programmers increasingly need software skills, including code structure, testing and version control, alongside electrical and process knowledge.
2. Connectivity: PLCs as data sources
The first job of a PLC is control, but plants now expect controller data to flow to SCADA, historians, MES and analytics.
- Industrial Ethernet has largely replaced serial fieldbuses in new installations.
- OPC UA provides a vendor-neutral, secure way to expose structured data (with information models, not just tag lists). Many current controllers include an OPC UA server; some also include a client.
- MQTT and Sparkplug B provide publish/subscribe data transfer to brokers and IIoT platforms, usually through an edge gateway, and on some controllers natively.
- Edge computing: a nearby industrial PC or edge device collects, buffers and contextualises PLC data, so that the controller is not burdened with analytics or cloud connections.
The recommended pattern is control stays in the PLC; data processing moves to edge and higher layers. See Industrial IoT (IIoT) and Industrial Communication Protocols.
3. Networks: Ethernet-APL, TSN and wireless
- Ethernet-APL (Advanced Physical Layer) brings two-wire Ethernet with power and intrinsic-safety options to field instruments in process plants, replacing many 4–20 mA and fieldbus connections over time. See Industry 4.0 and Smart Instrumentation.
- TSN is a set of IEEE 802.1 standards that allows time-critical control traffic and normal IT traffic to share one Ethernet network with guaranteed timing. Profiles for industrial automation are still maturing.
- Wireless: Wi-Fi and private 5G are used for mobile equipment, AGVs and monitoring. For deterministic, safety-relevant control, wired networks remain the norm; wireless control needs careful engineering of latency and failure behaviour.
4. Cybersecurity becomes a design requirement
Older PLCs were designed for isolated networks, often with no authentication on programming protocols. Current product lines increasingly offer:
- IEC 62443-4-2 certified components and development processes certified to IEC 62443-4-1
- User management and role-based access for engineering tools and controllers
- Secure protocol variants such as OPC UA with signing/encryption, CIP Security for EtherNet/IP and security extensions for PROFINET
- Signed firmware and protection against unauthorised program changes
- Syslog and event logging for security monitoring
Controller features are only one layer. Network segmentation, secure remote access, backups and change management remain essential. See PLC Security Concerns and Best Practices and ISA/IEC 62443.
5. Virtual and software-defined PLCs
A virtual PLC runs the controller runtime as software on industrial servers or edge computers, often in a virtual machine or container, instead of on dedicated PLC hardware. Several major vendors have released or announced such products.
Potential benefits:
- Hardware consolidation and centralised management
- Faster scaling and replacement, since hardware failures become server-level events
- Easier integration with IT tooling (deployment, monitoring, backup)
Open questions for each application:
- Deterministic timing depends on the real-time capabilities of the hypervisor, operating system and network.
- Redundancy, failover time and I/O connectivity must be engineered and tested.
- Safety functions still require certified safety controllers and architectures.
- Skills and responsibilities move between OT and IT teams.
Virtual PLCs are most suitable today for applications that tolerate the achievable cycle times and where the organisation has strong IT/OT infrastructure. Validate current product capabilities and support conditions with the vendor before committing.
6. AI in PLC engineering and operations
- Engineering assistants: several vendors and tool makers offer generative-AI features that draft code, explain existing logic or generate documentation. They can speed up routine work, but code must be reviewed, tested and simulated like any other code. Mistakes in control logic can cause equipment damage or safety incidents.
- Analytics on PLC data: anomaly detection and predictive maintenance normally run on edge or server platforms using data collected from PLCs, not inside the PLC scan.
- Inside the controller: some platforms support running trained models on dedicated modules or edge runtimes. This is still a niche compared with conventional logic.
See AI in Manufacturing for a broader and realistic view.
7. Challenges that will not disappear
- Installed base: plants have large numbers of older controllers. Migration takes years and must be planned around production. See PLC Upgrades and Migration.
- Skills: engineers need knowledge across controls, networking, security and software practices.
- Vendor ecosystems: open standards help at the integration layer, but hardware and engineering tools remain vendor specific.
- Cost justification: new features must be linked to real outcomes such as reduced downtime, faster changeovers or better data.
What this means for your next project
- Specify Ethernet-based I/O and OPC UA for data access, with a clear architecture for SCADA, historian and MES connectivity.
- Require coding standards, reusable libraries and version control.
- Include cybersecurity requirements (IEC 62443, user management, secure protocols, segmented networks) in the specification.
- Check the lifecycle status of controller families and plan spares and migrations.
- Treat virtual PLCs, TSN and AI tools as pilots until they meet your performance, support and validation requirements.
Frequently asked questions
Will PLCs be replaced by cloud or PC-based control?
Not for real-time machine and process control in the foreseeable future. Cloud platforms cannot guarantee the latency and availability that control requires. What is changing is where data processing happens and, for some applications, whether the controller runs on dedicated hardware or as software on industrial servers.
Is ladder logic becoming obsolete?
No. Ladder remains widely used for discrete logic and interlocks because it is easy to troubleshoot online. It is increasingly combined with Structured Text and function block libraries for more complex functions.
What skills should a PLC engineer learn for the future?
Structured programming and reusable libraries, industrial networking, OPC UA and MQTT, cybersecurity fundamentals (IEC 62443), version control and simulation. See the Automation Engineer Roadmap.
Key takeaways
- Ethernet, OPC UA, structured code and built-in security features are already mainstream.
- Virtual PLCs, TSN, Ethernet-APL and AI-assisted engineering are emerging and should be piloted with clear requirements.
- The architecture trend is: control stays deterministic in the controller; data processing moves to edge, historian and enterprise layers.
Related tutorials
Before you apply this in a plant: this article is for education. Always check the current edition of the relevant standards, the manufacturer's documentation for your exact product and version, and your site's procedures. Safety-related work needs qualified personnel. See our editorial policy.