Figure 2: A graphical management tool is used to allocate existing PC resources to the operating systems.

© acontis

The processor cores can be shared in different ways: In shared core operation, Windows and Linux share a core, whereby Linux has the higher priority for real-time reasons and can be activated immediately by real-time interrupts. Windows, on the other hand, only receives computing time if Linux voluntarily surrenders the computing time of the shared core - for example after an interrupt or in the idle task. This operating mode works on x86 single-core processors and also on multi-core processors without hardware virtualization support from any manufacturer, which is usually not possible with other real-time virtualization solutions available on the market.

If additional cores are available, these can be used either by Windows or Linux in a configurable manner (Fig. 2). With a quad-core processor, two cores can be assigned to Windows and the other two cores to Linux. One core for Windows and three cores for Linux or vice versa are further options for dividing up the processor cores.

Figure 3: Devices and their interrupts are easy to manage.

© acontis

If hard real-time with maximum jitter down to the microsecond range is to be achieved, certain processor properties such as throttling and other energy-saving measures or hyperthreading should be switched off - usually in the BIOS.
In addition to two timers (system and auxiliary), the real-time virtual machine provides Linux with interrupt management. This is used to log on, log off and process real-time interrupts that are triggered by PCIe devices. The latency times of interrupt and thread handling are very short under the real-time Linux operating system, which enables low cycle times down to the 50 µs range.

In addition to the shared resources, it is also possible to define exclusive resources. These are usually PCI/PCIe devices that are controlled either only by Linux or only by Windows. The exclusive resources for Linux are controlled by direct HW access in the same way as if Linux were running on the PC alone. This means that all device drivers that exist for Linux can also be used within the VM without modification. The management and configuration of these exclusive resources is handled by the so-called Real Time Device Management within the RTVM. Dummy drivers are installed under Windows for the devices that Linux is to control (Fig. 3). These do nothing under Windows, but only ensure that the Windows Plug&Play mechanism is satisfied and that the device resources are kept free by Windows.

The communication

With the features mentioned, the combination of Linux and Windows is basically functional. However, something crucial is still missing for daily practice: Communication between Windows and Linux. The RTVM offers several mechanisms for this: TCP/IP communication, access to the Windows file system, data exchange via shared memory, events, pipes and message queues.

TCP/IP communication is realized by network drivers on both operating system sides, which work on a common shared memory instead of controlling a real Ethernet controller. The network driver for Windows and the Linux-specific driver are part of the LxWin product. This virtual network can be used for all types of UDP and TCP/IP communication at application level, as well as for online debugging of Linux applications using Visual Studio or Eclipse under Windows (Fig. 4).

Figure 4: In addition to Eclipse, Microsoft Visual Studio can also be used under Windows for Linux software development.

© acontis

Communication across several shared memory areas can be configured in terms of size and access rights. Through corresponding API calls on both the Windows and Linux side, applications at user level receive direct pointers into the shared memory and can exchange data via it. This is supported by interlocks to synchronize access to shared memory areas (spinlocks) and by bidirectional events, i.e. asynchronous messages that are sent from one operating system to the other. This enables an application to signal to its counterpart on the other operating system that data has changed in the shared memory. There are also mechanisms for more complex types of communication between Linux and Windows, such as pipes, message queues or real-time sockets, which are all based internally on shared memory and events. Access to the Windows file system from Linux is also possible.

The use of the optional VT-x hardware virtualization technology in Intel CPUs opens up further options. For example, more than 4 GB of memory can be made available to Linux if 32-bit Linux is used. This is done by mapping any memory areas into the Linux address space.

With 64-bit Linux, VT-x is required to share individual cores with Windows. Windows is only activated when Linux has nothing more to do and has reached the idle loop. Windows thus runs in the idle loop of Linux, so to speak.

Another capability made possible by VT-x is to intercept a fatal Linux crash so that Windows continues to run completely undisturbed. Linux enters Virtual Monitor mode instead of rebooting the entire system. Activating VT-x is very simple and is done via the graphical interface of the supplied system manager tool.

Combination with Ethercat, TSN and OPC UA

A real-time-capable IPC-based control system is only useful if the corresponding sensors and actuators can be controlled in real time. Today, this is usually done via fieldbuses. If a standard Ethernet controller is exclusively available for Linux, the Ethercat Master Stack from Acontis can operate this Ethernet controller in hard real-time and control external Ethercat slaves via it. This enables cycle times down to 50 µs. The next generation of real-time network communication in the form of TSN with OPC UA Pub/Sub connection is already under development.

Author: Heinrich Munz is a silent partner of Acontis Technologies from Ravensburg, Germany