What happens when an OTee Virtual PLC is deployed?

When a compatible device is onboarded, OTee installs the local components required to deploy and operate the Virtual PLC.

By default, the components are deployed as isolated containers on the industrial device. This allows different services such as runtimes to operate independently while sharing the resources of the same host.

Docker is used in OTee’s standard installation process, but the architecture is not dependent on a specific container runtime. Alternative container and orchestration environments, such as Podman, can also be supported.

Inside the device, three components are particularly important.

1. The OTee Agent

The Agent connects the local device to the OTee platform.

Its responsibilities include:

• Registering and identifying the device

• Receiving authorized deployment instructions

• Reporting device and service status

• Supporting runtime deployment and lifecycle operations

• Maintaining the management connection between the device and the platform

The Agent is part of the device-management architecture. It does not execute the IEC 61131-3 control application and it is not an AI agent.

The separation is important: the Agent manages communication with the platform, while the Virtual PLC runtime remains responsible for local control execution.

2. The NATS publish/subscribe data layer

OTee includes NATS as a lightweight publish/subscribe communication layer.

Rather than forcing every application to build a separate point-to-point connection to the Virtual PLC, control data can be published into a common messaging layer. Authorized systems and services can then subscribe to the information they require.

Also, OTee follows an event-driven publishing model, where data is distributed when values change rather than continuously retransmitting unchanged information. This reduces unnecessary network traffic and allows available bandwidth to be used more efficiently, enabling larger numbers of variables to be monitored or published at higher update rates when required. 

This supports functions such as:

• Streaming live variables to the browser-based engineering environment

• Sharing data between local software services

• Making selected control data available to SCADA and other systems

• Connecting operational data to applications through standard interfaces

• Reducing the need for repeated, custom point-to-point integrations

OTee can expose and consume information through interfaces such as OPC UA, MQTT, and REST, allowing other industrial and software systems to consume the same underlying data more consistently.

3. The Virtual PLC runtime

The Virtual PLC runtime is where the automation logic executes.

Each runtime runs an IEC 61131-3 control application locally on the industrial device. It communicates with connected field equipment or remote I/O through supported industrial protocols.

Depending on the application, this may include communication with:

• Sensors

• Variable-frequency drives

• Valves

• Motors

• Pumps

• Remote I/O modules

• Other industrial controllers

• Process equipment

The control application executes locally on the device with a configurable control cycle that can be adapted to the requirements of the process. Depending on the application, the execution interval may range from fast cyclic tasks for time-critical control to slower cycles for less demanding workloads. 

Once deployed, the control application operates independently of the engineering environment. An active browser session or continuous cloud connectivity is not required for the controller to continue executing the application and communicating with field devices.

Can several Virtual PLCs run on the same device?

Yes. Multiple Virtual PLC runtimes can be deployed on the same compatible host device.

Each runtime can:

• Execute a different control application

• Use its own configuration

• Connect to field devices through its own industrial protocol configuration, such as Modbus TCP, EtherNet/IP, or EtherCAT

• Be deployed and updated independently

• Remain logically isolated from other runtimes

• Serve a separate machine, process, or control function

This allows organizations to consolidate several control applications onto suitable industrial computing hardware where the architecture, resource requirements and operational risk assessment support it.

It also creates a different scaling model from the conventional relationship of one proprietary PLC CPU to one control application.

OTee’s platform supports multiple Virtual PLC runtimes on one device and centralized visibility across devices, versions and deployment states.

Optional OT services can run beside the controller

The industrial device does not need to contain only the Virtual PLC runtime.

Additional services can be deployed alongside the control application from the OTee platform, including services such as:

• OPC UA servers

• MQTT brokers

• REST API 

• Data-connectivity services

• Protocol adapters

• Application-specific software components

This makes it possible to place control and selected data services on the same industrial device while keeping them as distinct software components.

For example, one service can execute the IEC 61131-3 control program while another exposes selected operational variables to SCADA, an analytics application, or an industrial data platform.

The control runtime still remains responsible for the control application.

AI and Third-Party Integrations

The service-oriented architecture makes it straightforward to expose operational data to AI applications and third-party software without affecting the control application. Process variables, alarms, events, and historical data can be securely shared through standard interfaces such as OPC UA, MQTT, or other data-connectivity services, allowing external systems to consume real-time industrial data.

This enables machine learning models running at the edge or in the cloud to support applications such as predictive maintenance, anomaly detection, quality prediction, energy optimization, and process optimization. The same architecture also simplifies integration with MES, SCADA, historians, digital twins, enterprise platforms, or custom applications.

AI models can also provide optimized process parameters back to the control application. For example, a process optimization model may continuously calculate the optimal temperature, pressure, or flow setpoint based on current operating conditions. The IEC 61131-3 application can then validate and apply these values according to the programmed control strategy, ensuring that deterministic control remains under the responsibility of the Virtual PLC while AI contributes higher-level optimization and decision support.

Why this architecture matters beyond one device

Understanding what runs inside the Virtual PLC is useful technically. The larger value becomes visible when the same architecture is applied across devices, assets, and sites.

More choice at the hardware layer

The control application is not tied to one proprietary PLC CPU family.

OTee Virtual PLC runtimes can be deployed on compatible x86 or ARM industrial hardware running a supported Linux operating system, giving organizations more flexibility in how control computing is selected and refreshed.

A consistent engineering and deployment workflow

Teams can use the same browser-based engineering, device onboarding, deployment, and version management workflow across different installations.

This can reduce the operational fragmentation created when every site or equipment type requires a separate engineering toolchain and lifecycle process.

Central visibility without centralizing the control loop

Operations and engineering teams can see what versions and deployments are running across a fleet while control continues to execute locally.

Updates can be rolled out to selected devices, verified and rolled back without treating every site as an isolated control asset.

Control and operational data are no longer locked into separate integrations

In many conventional architectures, each system that needs PLC data requires its own connection, protocol configuration, and integration logic.

With OTee, selected variables can be published through the local NATS data layer and consumed by multiple authorized services. This separates control execution from data consumption and provides a more consistent path for connecting SCADA, monitoring applications, software services, and industrial data platforms.

For an IT/OT architect, this means the control runtime can remain focused on the process while operational data becomes available to the wider system architecture through clearly defined interfaces.

Adoption can start with one application

Adopting a Virtual PLC does not require replacing the existing control system or committing to a full migration.

An OTee Virtual PLC can be introduced:

• In a new control application

• During an equipment or controller upgrade

• Alongside an existing PLC environment

• As an additional control or data layer

• On one device before expanding across a fleet

The practical starting point is not necessarily a complete migration. It can be one application with clear technical and operational success criteria.