From PLC-Centric Control to Software-Defined Automation
Industrial automation is moving beyond the traditional model of dedicated PLCs, microcontrollers, and fixed-function machines. Modern systems increasingly combine PLC-based control with high-performance MPUs and SoCs to handle HMI, machine vision, edge analytics, connectivity, digital twins, and AI workloads.
This evolution does not make traditional control architectures obsolete. Instead, it creates a layered architecture in which PLCs can continue handling deterministic field-level control while higher-performance computing platforms execute supervisory, analytical, visualization, and AI functions.
From an engineering perspective, the important issue is not simply adding computing capacity. The real challenge is ensuring that these additional workloads cannot compromise the timing, availability, or integrity of established control functions.
Physical AI Introduces a New Automation Challenge
The introduction of Physical AI makes system architecture more demanding because AI-generated information can influence physical equipment and operational decisions.
An AI model may identify an abnormal machine condition, detect a visual anomaly, support predictive inspection, or identify an operator-related condition. However, an AI inference result is only one part of the complete automation chain.
The system still needs to acquire sensor information, execute the AI model, validate the operating context, apply predefined control policies, and communicate the resulting condition to the appropriate application or operator.
My view is that industrial AI should therefore be treated as a decision-support or controlled-response workload rather than an isolated intelligence layer. The surrounding automation platform determines whether AI information can be processed and acted upon within the required timing and safety boundaries.
Mixed-Criticality Workloads Require Real Isolation
Modern multicore processors make it possible to consolidate functions that previously required separate hardware platforms. A single computing system may now host hard real-time control, HMI services, networking, diagnostics, event logging, machine vision, analytics, and AI inference.
These workloads do not have identical requirements.
A hard real-time control task may have a strict execution deadline. An HMI can tolerate different timing characteristics, while an AI inference process may require substantial CPU resources. Network services also introduce external communication paths that should not have unrestricted access to critical resources.
Consequently, simply placing multiple applications on a multicore processor does not automatically create a resilient architecture.
The operating environment must provide mechanisms for temporal separation, memory protection, resource control, and fault containment.
Hardware Consolidation Does Not Equal Resilience
Hardware consolidation can reduce the number of computing platforms, simplify wiring, and increase integration. However, it also creates a potential common failure point.
If unrelated workloads share the same processor and operating environment, a defective driver, runaway application, memory fault, or compromised service could affect other functions unless the software architecture establishes appropriate boundaries.
This is one of the most important considerations when modernizing legacy automation.
The objective should not simply be to put more functions onto fewer processors. The objective should be to consolidate workloads without creating unacceptable dependencies between them.
The Operating System Becomes an Enforcement Layer
In a software-defined automation architecture, the operating system is no longer merely a platform on which applications execute.
It determines how processes are scheduled, how memory is protected, how hardware resources are accessed, and how individual services interact with one another. These mechanisms directly influence the ability of the system to maintain operation when an individual component fails.
A resilient architecture should therefore be able to isolate a failed service and, where the system design permits, recover that service without restarting unrelated applications.
This approach is particularly relevant to industrial systems where a complete system reboot can interrupt control, visualization, communication, or production operations.
Why Microkernel Architecture Matters
A conventional monolithic operating system typically places many services, drivers, filesystems, and networking components within a highly privileged kernel environment.
A microkernel takes a different architectural approach. It keeps a smaller set of fundamental functions in the kernel while allowing many drivers, protocol stacks, filesystems, and system services to execute as separate processes in protected address spaces.
For industrial automation, this architecture can provide several useful properties:
- Fault containment: A defective driver or service can be isolated from unrelated processes.
- Controlled recovery: Individual services may be restarted without necessarily rebooting the complete system.
- Reduced privileged code: Fewer components need to operate with the highest system privileges.
- Memory isolation: Protected address spaces help prevent one application from directly interfering with another.
- Mixed-criticality support: Real-time control tasks can coexist with HMI, networking, analytics, and AI workloads.
- Lifecycle maintenance: Modular services can simplify maintenance and component-level updates.
A microkernel does not eliminate software defects or cybersecurity vulnerabilities. Its value lies in establishing architectural boundaries that can limit the consequences of individual failures or compromises.
Real-Time Determinism Remains a Fundamental Requirement
Industrial modernization should not allow AI and high-performance computing requirements to overshadow deterministic control requirements.
For control applications, the question is not simply how much processing power is available. The system must also provide predictable scheduling behavior and bounded response characteristics for functions with defined timing requirements.
This is particularly important when AI or analytics workloads consume significant computing resources.
In my assessment, the practical architecture is therefore not "AI replacing control," but rather deterministic control operating alongside higher-level intelligence under controlled resource boundaries.
Cybersecurity Must Extend Across the Product Lifecycle
Technical isolation is only one part of cyber resilience.
Industrial manufacturers also need processes for identifying software components, monitoring vulnerabilities, validating updates, controlling software delivery, and maintaining products throughout their operational life.
The ISA/IEC 62443 series provides a lifecycle-oriented framework specifically relevant to industrial automation and control systems. Other standards, including ISO/SAE 21434, demonstrate how structured cybersecurity risk management can extend from development through operation, maintenance, and decommissioning.
The European Cyber Resilience Act also increases the importance of lifecycle cybersecurity management for products within its scope.
For industrial equipment manufacturers, this means cybersecurity cannot reasonably be treated as a final-stage certification activity. Software composition, vulnerability response, update mechanisms, supplier management, and product maintenance need to be considered during system development.
Security Architecture Should Support Recovery, Not Only Prevention
Traditional cybersecurity discussions often focus on preventing unauthorized access. Industrial resilience requires a broader perspective.
A compromised or defective component may still occur despite preventive controls. The architecture must therefore limit the component's ability to affect critical functions and provide a defined recovery path.
This creates three complementary engineering objectives:
- Prevent unauthorized or unintended behavior.
- Contain failures and compromised components.
- Recover affected services while maintaining unaffected operations.
For industrial automation, this combination is more practical than relying on prevention alone.
QNX as a Foundational Real-Time Platform
QNX provides a hard real-time microkernel-based operating system architecture intended for systems where predictable execution, process isolation, and controlled resource access are important.
Within an industrial automation architecture, QNX can provide the foundational execution environment for applications, drivers, protocol stacks, and filesystems operating in protected address spaces. Priority-based scheduling can support workloads with different timing requirements.
This architecture can complement PLC-based control rather than replace it.
A practical system may retain PLCs for established field-level control while using MPU- or SoC-based computing platforms running a real-time operating system for HMI, machine vision, connectivity, analytics, supervisory functions, and AI-related workloads.
A Practical Architecture for Industrial Modernization
A modern industrial system can therefore be viewed as several cooperating layers:
- Field layer: Sensors, actuators, drives, and other physical equipment.
- Control layer: PLCs and controllers performing deterministic automation.
- Computing layer: MPU/SoC platforms providing additional processing capacity.
- Intelligence layer: Machine vision, analytics, AI inference, and other computational workloads.
- Supervisory layer: HMI, diagnostics, event management, and operational applications.
- Connectivity layer: Industrial networks and external communication services.
- Foundational software layer: Real-time operating system, isolation, scheduling, resource management, and recovery mechanisms.
The key engineering requirement is to define the boundaries between these layers rather than treating the entire computing environment as one undifferentiated application space.
Modernization Should Preserve Existing Control Investments
Industrial equipment often remains operational for many years. Replacing established PLC-based control simply because new computing capabilities are available is not always technically or economically justified.
A more practical modernization strategy is to preserve proven control functions while adding computing resources around them.
MPU- and SoC-based platforms can provide the processing capacity required for modern HMI, AI, analytics, visualization, and connectivity while existing PLCs continue performing deterministic control.
This approach allows manufacturers to introduce new capabilities without unnecessarily disturbing established control architectures.
My Engineering Perspective: Resilience Starts With Architecture
The most important lesson from this transition is that resilience cannot be added after the system has already been consolidated.
When control, networking, HMI, analytics, and AI share computing resources, isolation and recovery mechanisms need to be part of the original architecture.
A powerful processor does not by itself create a resilient automation system. Likewise, an AI model does not make an automation system intelligent unless the surrounding platform can acquire data, execute the model, validate its output, enforce predefined policies, and respond within the required operational boundaries.
The next generation of industrial automation will therefore depend not only on higher computing performance, but on how effectively software architecture controls the interaction between workloads.
Conclusion
Industrial automation is entering an architecture in which PLCs, high-performance processors, AI, connectivity, and software-defined functions increasingly operate together.
This creates substantial opportunities for modernization, but it also introduces new dependencies and failure modes.
A resilient architecture must combine deterministic execution, process isolation, memory protection, controlled resource access, fault containment, cybersecurity lifecycle management, and defined recovery mechanisms.
Microkernel-based real-time operating systems such as QNX represent one architectural approach to these requirements. Used alongside existing PLC and controller technologies, such platforms can provide the software foundation needed to integrate modern computing workloads while maintaining clear boundaries around critical automation functions.
