VxWin: Running VxWorks and Windows on One Industrial PC

VxWin: Running VxWorks and Windows on One Industrial PC

Industrial automation, robotics, motion control, and other mission-critical systems often need two very different computing environments.

The control side requires hard real-time determinism: predictable scheduling, bounded interrupt latency, direct hardware access, and isolation from non-real-time workloads. At the same time, modern industrial systems increasingly require sophisticated HMIs, data logging, visualization, databases, diagnostics, and connectivity to enterprise systems.

Historically, engineers addressed this split with two separate computers: one running a real-time operating system such as Wind River VxWorks, and another running Microsoft Windows.

VxWin takes a different approach by allowing VxWorks and Windows to run concurrently on a single x86-based PC while maintaining isolation between the real-time and general-purpose environments.

Originally pioneered by KUKA Roboter in the 1990s and subsequently developed and maintained by acontis technologies as part of its real-time virtualization portfolio, VxWin provides a practical way to consolidate real-time control and Windows-based applications onto one industrial computer.

🧩 What Exactly Is VxWin?

#

VxWin is a software-based real-time virtualization platform designed to host VxWorks and Windows concurrently on the same physical machine.

The fundamental architecture separates the two operating environments:

• VxWorks handles deterministic control loops, real-time I/O, motion control, fieldbus communication, and other time-critical workloads.
• Windows handles HMIs, visualization, databases, diagnostics, enterprise applications, and general-purpose networking.
• CPU cores, memory, interrupts, and devices can be partitioned between the environments.
• Inter-process communication mechanisms allow the two operating systems to exchange data without requiring a second physical computer.

This architecture allows existing VxWorks applications and conventional Windows software to coexist while maintaining a strong separation between their execution environments.

The exact capabilities depend on the VxWin release, VxWorks version, Windows version, processor platform, and BSP configuration. Production systems should therefore be validated against the corresponding acontis compatibility documentation.

🏗️ VxWin Architecture and Resource Partitioning

#

At the center of the architecture is the acontis real-time virtualization framework, which provides the infrastructure required to execute the real-time environment alongside Windows.

A typical deployment contains several major components:

1. Real-time virtualization layer provides the execution environment and resource management.
2. VxWorks BSP adapts VxWorks to the VxWin virtualized hardware environment.
3. Windows operates as the general-purpose operating system.
4. Resource partitioning assigns CPU cores, memory regions, interrupts, and devices.
5. IPC mechanisms provide communication between VxWorks and Windows.

The key architectural objective is to prevent Windows activity from introducing unbounded latency into VxWorks execution.

CPU core assignment

#

Multi-core processors make this separation particularly practical.

For example, a system can dedicate one or more CPU cores to VxWorks while assigning the remaining cores to Windows.

A simplified configuration might look like this:

+------------------------------------------------------+
|                    Physical x86 PC                   |
+------------------------------------------------------+
|             Real-Time Virtualization Layer           |
+-----------------------------+------------------------+
|          VxWorks            |        Windows         |
|                             |                        |
|  Dedicated CPU Core(s)      |  Remaining CPU Cores   |
|  Real-Time Tasks            |  HMI / GUI             |
|  EtherCAT / I/O             |  Database              |
|  Motion Control             |  Networking            |
|  Deterministic Timers       |  Diagnostics           |
+-----------------------------+------------------------+
|              Shared Hardware / IPC Resources         |
+------------------------------------------------------+

Dedicated cores reduce contention between real-time and general-purpose workloads. Additional tuning may still be required because processor topology, interrupt routing, firmware behavior, cache architecture, and power-management features can all affect real-time latency.

Hardware virtualization

#

Modern processors provide virtualization extensions such as Intel VT-x and AMD-V.

VxWin can use hardware virtualization capabilities where supported to strengthen isolation and improve the virtualization architecture. Exact requirements and supported processor features depend on the specific VxWin version and target platform.

The important distinction is that VxWin is designed around real-time resource control, rather than simply running VxWorks inside an ordinary desktop virtual machine.

⏱️ Determinism and Real-Time Isolation

#

The primary reason to use VxWin is to preserve predictable real-time behavior while Windows executes concurrently on the same hardware.

A conventional Windows application can experience scheduling delays caused by background processes, drivers, interrupts, power management, or other operating-system activity.

Those delays are acceptable for most desktop applications but can be problematic for motion-control loops or tightly timed industrial I/O.

VxWin isolates the real-time environment from much of this non-deterministic activity.

Reported configurations can achieve microsecond-scale interrupt latency, although actual worst-case latency depends heavily on the processor, BIOS configuration, peripheral devices, interrupt topology, and system tuning.

Windows failures and real-time operation

#

One of the important architectural properties of the separation is that a Windows failure does not necessarily terminate VxWorks execution.

If Windows experiences a system crash, the real-time environment can remain operational because it is isolated from the Windows execution environment.

This behavior is particularly useful when Windows is responsible for non-critical visualization or enterprise connectivity while VxWorks controls the actual machine.

The safety implications depend on the complete system architecture. A system should never assume that software isolation alone satisfies functional-safety requirements.

🔄 Communication Between VxWorks and Windows

#

Running two operating systems on one computer is only useful if they can exchange data efficiently.

VxWin provides several mechanisms for communication between the environments.

Virtual networking

#

A virtual network interface can connect VxWorks and Windows through a software-based network path.

This allows applications to use familiar TCP/IP socket interfaces and is useful for:

• Diagnostics.
• Configuration.
• Debugging.
• Control interfaces.
• Higher-level application communication.

The trade-off is that a network-oriented communication path generally has more overhead than direct shared-memory exchange.

Shared memory

#

For higher-performance communication, shared memory can be used to exchange data directly between the two environments.

A common architecture is to reserve a shared memory region containing structured data:

VxWorks                           Windows
   |                                |
   |  Write control/status data     |
   +------------+-------------------+
                |
                v
        +---------------+
        | Shared Memory |
        +---------------+
                ^
                |
   +------------+-------------------+
   |  Read status / write commands  |
   |                                |

Synchronization primitives such as events and interlocked operations can coordinate access.

This approach is particularly useful when large amounts of data must move between the real-time controller and Windows HMI or analytics applications without introducing unnecessary network-stack overhead.

Debugging and console access

#

VxWin deployments can also provide mechanisms for accessing the VxWorks target shell and debugging the real-time environment from the host system.

This allows developers to maintain familiar VxWorks development and diagnostic workflows while the RTOS is executing on the same physical machine as Windows.

🏭 Key Benefits of VxWin

#

Hardware consolidation

#

The most obvious benefit is eliminating a separate computer for the real-time controller and another for the HMI.

Instead of:

+-------------+       Network       +-------------+
| VxWorks PC  | <-----------------> | Windows PC  |
| Control     |                     | HMI / IT    |
+-------------+                     +-------------+

the architecture can become:

+-------------------------------------------+
|              Single Industrial PC         |
|                                           |
|  +---------------+   +----------------+   |
|  |    VxWorks    |   |    Windows     |   |
|  | Real-Time     |   | HMI / IT       |   |
|  | Control       |   | Applications   |   |
|  +---------------+   +----------------+   |
+-------------------------------------------+

This can reduce system size, cabling, power consumption, and the number of physical components that must be maintained.

Software reuse

#

A major advantage for existing VxWorks installations is the ability to preserve established application architectures.

Existing VxWorks software can continue to handle:

• Motion-control loops.
• PLC-style control.
• Real-time I/O.
• Industrial Ethernet.
• Device communication.
• Deterministic data acquisition.

Meanwhile, Windows can host conventional applications developed using familiar tools and frameworks.

This separation allows each environment to remain specialized instead of forcing real-time workloads into Windows or requiring the HMI to be implemented entirely inside the RTOS environment.

Development efficiency

#

Developers can use established toolchains for each operating system.

The real-time side can use the appropriate Wind River development and debugging tools, while Windows applications can be developed using Microsoft Visual Studio and the broader Windows ecosystem.

This also makes it possible to prototype parts of the integrated architecture before the final industrial hardware is available, provided the target BSP and hardware dependencies are properly accounted for.

📡 Typical Industrial Applications

#

VxWin is particularly relevant to systems that require both deterministic control and sophisticated general-purpose software.

Typical applications include:

• Industrial automation: PLC-style control, machine control, and supervisory interfaces.
• Motion control: Servo control, trajectory generation, and synchronized motion.
• CNC systems: Real-time machine control combined with rich operator interfaces.
• Industrial robotics: Real-time robot control combined with visualization and diagnostics.
• Data acquisition: Deterministic sampling combined with Windows-based logging and analysis.
• Medical equipment: Precise device control combined with visualization and user interfaces.
• Enterprise-connected machines: Real-time machine operation combined with MES, ERP, database, and remote-management connectivity.

The architecture is particularly useful when an existing VxWorks application already represents a significant software investment and Windows functionality needs to be added without introducing another physical computer.

🧰 Technical Features at a Glance

#

A typical VxWin deployment can provide several capabilities relevant to industrial systems.

The exact implementation and availability of these features depend on the VxWin release and target configuration.

⚙️ System Tuning and Real-Time Performance

#

A real-time hypervisor does not eliminate the need for system-level tuning.

The BIOS and firmware configuration can have a significant effect on worst-case latency. Features designed to improve average power efficiency or desktop responsiveness can introduce additional latency or timing variability.

Depending on the target platform, engineers may need to evaluate:

• CPU C-states.
• Turbo or dynamic-frequency behavior.
• Simultaneous multithreading.
• Processor power-management policies.
• Interrupt routing.
• PCIe device behavior.
• Timer configuration.
• BIOS virtualization settings.
• Windows background activity.
• Hardware Management Interrupts (SMIs).

On Windows-based systems, additional platform security and virtualization features can also interact with the real-time virtualization layer.

Features such as Virtualization-Based Security (VBS), Core Isolation, and certain DMA-protection mechanisms may conflict with particular hypervisor configurations and therefore need to be evaluated against the supported VxWin deployment requirements.

These settings should not be disabled indiscriminately. The correct configuration depends on the required security model, hardware platform, Windows version, and VxWin release.

Latency is a system property

#

A frequently misunderstood aspect of real-time virtualization is that the hypervisor alone does not determine worst-case latency.

A more useful model is:

where each component can contribute to the final worst-case response.

Consequently, latency measurements should be performed on the actual production hardware and firmware configuration, under representative worst-case workloads.

🔐 Isolation, Safety, and Reliability Considerations

#

VxWin provides strong execution isolation between VxWorks and Windows, but virtualization isolation should not automatically be equated with functional safety.

For safety-related systems, engineers must consider the complete architecture, including:

• Failure detection.
• Safe-state behavior.
• Hardware watchdogs.
• Emergency-stop circuits.
• Independent safety controllers where required.
• Safety-certified components.
• Fault propagation paths.
• Applicable industry standards.

The ability of VxWorks to continue executing when Windows fails can improve system resilience, but whether that behavior satisfies a particular safety requirement depends on the application and certification framework.

🕰️ Historical Context and Evolution

#

VxWin traces its roots to the mid-1990s, when KUKA developed technology for running a real-time control environment alongside Windows on commodity x86 hardware.

The approach was particularly relevant to industrial robotics, where a controller needed deterministic execution while also benefiting from increasingly capable general-purpose PC software.

Over time, the technology evolved alongside Windows and x86 hardware, supporting successive Windows generations and newer multi-core processors.

acontis technologies subsequently continued development of the technology as part of its broader real-time virtualization portfolio, alongside solutions such as LxWin for real-time Linux and RTOS32Win.

The evolution reflects a broader industry trend: rather than dedicating an entire physical machine to a single operating system, modern industrial computers increasingly use virtualization and hardware partitioning to consolidate workloads while preserving real-time requirements.

🧭 VxWin Versus Other Real-Time Virtualization Architectures

#

VxWin is designed specifically around the coexistence of VxWorks and Windows.

For projects with different requirements, other virtualization architectures may be more appropriate.

A Type-2 real-time hypervisor architecture operates in conjunction with a host operating system, while a Type-1 hypervisor operates directly on the hardware and manages multiple guest environments.

For green-field systems requiring multiple independent guest operating systems or a more general hardware-level virtualization architecture, a Type-1 solution such as acontis RTOSVisor may be considered.

The appropriate architecture depends on the required guest operating systems, real-time guarantees, hardware assignment model, certification requirements, and software legacy.

📋 Practical Deployment Checklist

#

Before deploying VxWin on production hardware, validate the following:

• VxWorks version: Confirm that the required VxWorks release has a compatible VxWin BSP.
• Windows version: Verify support for the exact Windows edition and build.
• CPU: Confirm processor and virtualization-extension compatibility.
• Core allocation: Reserve sufficient CPU resources for real-time workloads.
• Interrupt routing: Assign critical interrupts carefully.
• PCIe devices: Verify ownership and real-time accessibility of required hardware.
• BIOS: Configure firmware according to the real-time performance requirements.
• Power management: Measure the effect of C-states, frequency scaling, and related features.
• Security features: Verify compatibility with VBS, Core Isolation, DMA protection, and other Windows security mechanisms.
• IPC: Select shared memory, virtual networking, or another mechanism based on latency and bandwidth requirements.
• Latency: Measure worst-case behavior on production hardware.
• Failure handling: Test Windows crashes and other host-side failure scenarios.
• Safety: Validate the complete system against applicable safety requirements.
• Licensing: Confirm VxWin licensing and BSP availability for the selected VxWorks and hardware configuration.

🧠 Conclusion

#

VxWin addresses a practical problem that remains common in industrial computing: how to combine deterministic real-time control with the rich software ecosystem of Windows without requiring two physical computers.

Its architecture allows VxWorks to remain responsible for time-critical control while Windows handles visualization, databases, diagnostics, enterprise connectivity, and other general-purpose workloads.

The main engineering value comes from resource partitioning and isolation. Dedicated CPU resources, controlled hardware access, real-time scheduling, and low-latency IPC allow the two environments to coexist on the same x86 platform.

For organizations with an existing VxWorks investment, this approach can simplify hardware architecture while preserving the real-time application environment. For new designs, however, the decision should be based on the required real-time guarantees, Windows integration, security model, hardware lifecycle, and long-term software strategy.

VxWin is therefore best viewed not simply as a way to run two operating systems on one PC, but as an industrial real-time consolidation architecture in which deterministic control and general-purpose computing can coexist under carefully controlled hardware and software boundaries.

For production deployment, always validate the exact VxWin version, VxWorks release, Windows build, BSP, processor platform, device configuration, and real-time latency requirements against the current vendor documentation and support resources.