This “Product How-To” article focuses how to use a certain product in an embedded system and is written by a company representative.
There are a lot of real-time operating systems (RTOS) in the field.However, the number of applications for those RTOSs is even bigger.Often, the real-time appliances are running stand alone on hardwareplatforms like x86 based PCs.
With new virtualization software from KUKA it is possible to run acustomer's RTOS in real time together with Microsoft Windows. Theadaptation of the RTOS can be done by the customer.
But why do this? What is the benefit of having real timeapplications together with Windows on the same PC? In 1996, KUKAintroduced the world's first industrial robot controller that was basedjust on an industrial PC.
Some of the reasons for KUKA's subsequent commercial success are thewell-known and accepted Human Machine Interface (HMI) of Windowstechnology and the flexibility and cost effectiveness of the PCtechnology.
The controlling of the robot movement in hard real time is done bythe RTOS Wind River VxWorks, which runs together with Windows on theindustrial PC of the robot controller. An earlier version of the newKUKA virtualization software makes this possible.
Besides the controlling of a machine, there can be other meaningfulreasons for the combination of an RTOS and Windows. For example, onewants to run the RTOS software that is running on a controller on alaptop for simulation, training or presentation purposes. It also canbe useful for the developers to have the control software available ona Windows PC.
Until now with KUKA's Windows real time extension software it waspossible to run only one instance of VxWorks or Windows CE in hard realtime beside Windows. The reason that there haven't been other RTOSsupported lies in the fact that new RTOS could be adapted by KUKA only.
Now, with “RTOS-VM,” the restrictions of the previous KUKA real-timeextension versions are gone. In this “RTOS Virtual Machine” the oldversion has been enhanced in a way that not only VxWorks or Windows CEcan be used as the RTOS, but virtually any x86 RTOS.
In addition not only one instance of the RTOS can be run but ” on amulti core processor ” several of them or a multi core-able RTOS canmake usage of several cores.
With the included documentation and sample applications, theadaptation of the RTOS can simply be made by the customer. For lesscomplex requirements it is also possible not to use an RTOS at all, butto develop simple real-time software like real-time interrupt handlersby using the included sample source code.
The virtual machine consists of a framework (Figure 1, below ) offering somefunctions which can be called up by the developer instead of directlyprogramming the hardware.
|Figure1: The KUKA VMF allows the coexistence of Windows and the RTOS bymanaging devices, memory, processor cores and other hardware resources.The RTOS and the VMF are loaded by a Windows application using theUploader DLL. TCP/IP communication is provided by virtual networkdrivers on the Windows and the RTOS side, direct shared memory accessis supported by the RTOS Library|
Those functions can easily be called by C-function calls via abinary jump table ” no linking of the RTOS and the VM necessary. By themeans of this mechanism, the VMF manages all resources which are sharedbetween the RTOS and Windows. The resources managed by the so called”BASIC VMF” (Figure 2 below )are:
* Processor Cores
The memory management allows it to assign a configurable size ofmemory to the RTOS. After the next booting of Windows, Windows will belacking this memory.
|Fig.2: The BASIC VMF is the central management part of RTOS-VM. It iscontrolled by the RTOS Board Support Package (BSP) via a simple JumpTable and manages Memory, processor cores, devices, interrupts, timers,etc.|
The processor cores can be shared in different ways. Within the socalled Shared Core mode, Windows and the RTOS are sharing one core,wherein the RTOS gains higher priority than Windows and can beactivated by real-time interrupts immediately.
Windows only receives computing power when the RTOS, voluntarilyyields it. This mode already is known from the previous versions of theKUKA software. This mode works especially well on single coreprocessors ” a feature which often is missing by other real timevirtualization solutions.
If there are further cores, those can be configured to be used byWindows or by the RTOS. Windows can use several cores in SMP mode(Symmetric Multi Processing), while the RTOS can operate on each singecore have one instance per core (AMP, Asymmetric Multi Processing) orone instance of the RTOS could manage several cores in SMP mode.
|Figure3: The RTOS exclusive devices are installed with dummy drivers underWindows|
Within the so called Exclusive Core mode (Figure 3 above ), Windows and theRTOS can be configured to use a defined number of cores. The RTOS againcan be run in AMP or SMP mode.
Because in the Exclusive Mode each OS uses its cores exclusively,there are no compromises regarding real-time-ability and performance.Especially in this mode, Windows always gets the full computing powerof its exclusive cores and does not have to share it with the RTOS.
Beside two timers (System und Auxiliary), the VMF offers the RTOS apowerful interrupt management. This is needed for enabling, disablingand handling of real-time interrupts.
In addition to the shared resource management, there is thepossibility to define exclusive resources. Usually those resources arePCI- or PCI Express Devices which are controlled by Windows or the RTOSexclusively by directly controlling the hardware of those devices.
This is done in the same manner as if the RTOS is run stand alone onthe hardware. Because of this, all device drivers existing for the RTOScan also be used within the VM.
The management and the configuration of those exclusive devices aredone by the so called “Real Time Device Management” within the VMF. Forthose devices being controlled by the RTOS, so called “RtosPnp-Drivers”have to be installed under Windows.
These drivers are making sure that only the Windows Plug&Playmechanism is satisfied and that the device resources are reserved underWindows.
Everything mentioned before would be enough to just have the RTOS runbeside Windows. However, this would not be sufficient for daily workbecause something very important would still be missing: Thecommunication between Windows and the RTOS.
RTOS-VM offers two different possibilities for this: TCP/IP basedcommunication via a virtual network between the two OSs and directaccess into a common shared memory.
The TCP/IP communication is realized by network drivers. Instead ofcontrolling real existing Ethernet devices, the drivers are workinginto a shared memory.
While the NDIS driver for Windows is part of the product, the RTOSspecific driver has to be developed by the customer. This task is veryeasy because the VMF offers some simple functions for network packettraffic.
The second method of communication consists of direct access intoanother shared memory, which can be configured in its size. Viaexisting API-calls on the Windows side as well as on the RTOS side,applications on user mode level can achieve direct memory pointers intothe shared memory to manipulate and transfer data from one side to theother.
This is supported by bidirectional events which one application cansend to the application on the other side to signal that it has changeddata.
Heinrich Munz is a product managerfor the KUKAReal-Time product family. In 1985 he co-founded the German basedcompany LP Elektronik, where he developed and marketed Windowsreal-time products. In 2001 LP Elektronik was acquired by KUKA Roboter,which since 1996 has used the combination of Windows and VxWorks”VxWin” in all of their robot controllers.