An Overview of the VxWorks Real-Time Operating System (RTOS)

Peter Williams and Katrina Kowalczuk

Abstract
This paper will first provide an overview of the VxWorks real time operating system. We will focus our discussion on how VxWorks handles power, process, and memory management. Information about the supported VxWorks applications will also be provided.

Introduction
A Real-Time Operating system is a functioning operating system that has been specifically developed for use within real time situations, more typically for embedded applications. Embedded systems are often not recognisable as computers. Instead they exist within objects, which are present throughout our day-to-day lives. Real time and embedded systems often operate within constrained environments where processing power and memory are limited. They often have to perform to strict time deadlines where performance is critical to the operation of the system. VxWorks is an example of a real time operating system, and it has a good track record for providing the basis of many complex systems. These systems include 30 million devices ranging from network equipment, automotive and aerospace systems, life-critical medical systems and even space exploration. VxWorks was developed from an old operating system VRTX. VRTX did not function properly as an operating system so Wind River acquired the rights to re-sell VRTX and developed it into their own workable operating system VxWorks (some say this means VRTX now works). Wind River then went on to develop a new kernel for VxWorks and replaced the VRTX kernel with this. This enabled VxWorks to become one of the leading operating systems created for the purpose of real time applications.

Memory Management in VxWorks

VxWorks memory management system does not use swapping or paging. This is because the system allocates memory within the physical address space without the need of swapping data in and out of this space due to memory constraints. VxWorks assumes that there is enough physical memory available to operate its kernel and the applications that will run on the operating system. Therefore VxWorks does not have a directly supported virtual memory system. 1 The amount of memory available to a VxWorks system is dependent upon the platforms hardware and the memory management units imposed constraints. This amount is usually determined dynamically by the platform depending on how much memory is available, but in some architectures it is a hard coded value. This value is returned by the sysMemTop() method which will set the amount of memory available to the operating system for this session.
1

There is an extra virtual memory support component available, The VxVMI Option, which is an architectureindependent interface to the MMU. It is packaged separately as an add-on.

0xFFF Routines which provide an interface to the system-level functions (most of the kernel) are loaded into system memory from ROM and are linked together into one module which cannot be relocated. This section of the operating system is loaded into the bottom part of the memory, starting at address 0. The rest of the available memory is known as the System Memory Pool and essentially is the heap available to the application developer and the dynamic memory routines for manipulating the heap. Dynamic Partition Dynamic Partition

System Memory Pool

Kernel
0

In most cases, the VxWorks memory model is flat and the operating system has just the limits of the available physical memory to work with. When memory needs to be allocated, the dynamic memory management routines use the ANSI standard C function malloc(), a first-fit algorithm. It searches for the first available block of memory that the program requires, splits the correct amount of memory required for the task, and leaves the rest. When the memory needs to be freed up, the ANSI-C function free() is used. Using the first-fit method can lead to the fragmentation of all of the memory very quickly, and obviously if lots of different sized tasks are loaded into memory between lots of free spaces this can lead to no space being available at all when the next allocation request is given. Also, searching through many fragments of memory will take longer when trying to find space for allocation. It is advised to reduce fragmentation that the dynamic partition sizes are allocated on system initialisation dependent on the size of the tasks/task data. Another way to reduce fragmentation in all of the system memory is to partition the memory off into two or more sections at start-up and ask the offending tasks to use the other partitions.

Processes in VxWorks
A feature of a real-time operating system like VxWorks is that the programmer developing applications for the operating system can control the process scheduling. This means that the programmer is in control of how and when the processes run rather than leaving the operating system to work it out. In terms of other operating systems a VxWorks task is similar to a thread, with the exception that VxWorks has one process in which the threads are run. In a RTOS, these tasks must endeavor to appear to run concurrently when obviously with only a single CPU this cannot happen, so clever scheduling algorithms must be enforced. Pre-emptive Task Scheduling VxWorks schedules processes using priority pre-emptive scheduling. This means that a priority is associated with each task, ranging from 0 to 255, (0 being the highest priority and 255 being the lowest). The CPU is allocated the task with the highest priority and this task will run until it completes or waits, or is pre-empted by a task with a higher priority.

There are different factors which the programmer should take into consideration when assigning priorities to processes: 1. Priority is a method of ensuring continuity of tasks in the system and preventing a specific task from hogging the CPU while other important tasks are waiting. Therefore, priority levels are not a method of synchronisation (making tasks run in a specific order). 2. Tasks that have to meet strict deadlines should be assigned a high priority and the number of high priority tasks should be kept to a minimum. This is because if there are lots of high priority tasks they will all be competing for CPU time and the lower priority tasks may be left out. 3. Tasks that are CPU intensive should be assigned a lower priority. If these tasks need to perform to deadlines and need a higher priority, task locking can be used as described below. 4. VxWorks kernel tasks must be of a higher priority to application tasks in order to ensure continuity of the core operating system processes. Round Robin Scheduling There is another (optional) method of process scheduling which is used when a task (or a set of tasks) of equal priority is competing for CPU time. Round Robin scheduling is where each task is given a small piece of CPU time to run, called a quantum, and then allow the next task to run for its quantum. VxWorks will provide this time-slicing mechanism to a number of processes until a process completes, and then pass the next process (or set of processes with the same priority) to the CPU. The only problem with frequently relying on Round Robin scheduling is that if higher priority tasks are consuming all of the CPU time, the lower priority tasks would never be able to access the CPU. Inter-process Communication (IPC) with VxWorks As with processes in all operating systems tasks in VxWorks often need to communicate with one another, and this is known as IPC. A typical synchronisation problem encountered while processes are communicating is a race condition. This is basically where the result of shared data is determined by its timing but the timing has gone wrong. The OS must avoid these race conditions and must achieve mutual exclusion to ensure a process is not accessing shared data (while a process is in its critical region) at the same time as another. VxWorks makes use of a data type called Semaphores to achieve mutual exclusion. This works by providing an integer variable which counts waiting processes, resources or anything else that is shared. There are three types of semaphore available to the VxWorks programmer. 1. The binary semaphore This only has two states, full or empty. The empty variable either waits until a give command is made, and a full semaphore waits for the take command. Binary semaphores are used with Interrupt Status Registers, but are not advanced enough to handle mutual exclusion. 2. The counting semaphore This variable starts at 0, which indicates that nothing is waiting, and a positive integer above 0 indicates the number of things waiting. This is generally used where there are fixed numbers of resources but multiple requests for the resources. 3. The mutual exclusion (mutex) semaphore This is an advanced implementation of the binary semaphore which has been extended further to ensure the critical region of a task is not interfered with. A key difference with Mutex semaphores is that it protects against

priority inversion, a problem which can be encountered at some point when using a priority pre-emptive scheduler, as explained below. Shared memory (e.g. in the form of a global information bus) is also used to pass information to other tasks, as are message queues which are used when the tasks are both running. Priority Inversion A quick note on priority inversion, which although is rare, can mean success or failure for a real time operating system. Consider this: A low priority task holds a shared resource which is required by a high priority task. Pre-emptive scheduling dictates that the high priority task should be executed, but it is blocked until the low priority task releases the resource. This effectively inverts the priorities of the tasks. If the higher priority process is starved of a resource the system could hang or corrective measures could be called upon, like a system reset. VxWorks experienced a real problem with priority inversion when the operating system was used for the NASAs Mars Pathfinder Lander in 1997. A high priority information management task moved shared data around the system ran frequently. Each time something was moved, it was synchronised by locking a mutex semaphore. A low priority meteorological data gathering task would publish data to the information management bus, again acquiring a mutex while writing. Unfortunately an interrupt would sometimes cause the medium priority communications task to be scheduled. If this was while the higher priority task was blocked from running because it was waiting for the lower priority task to finish, the communications task would stop the lower priority task but preventing the higher priority task from running at all. This caused a timeout, which was recognised by a safety algorithm. This in turn caused system resets which appeared random to the supervisors back on Earth. Information Bus

Mutex Semaphore High Priority Bus Management Task

3
Medium Priority Communications Task

Low Priority

1 `

4
1. 2. 3. 4.

Meteorological Publishing Task

Low priority meteorological task is scheduled. High priority bus management task blocks to wait for the meteorological task. The communications task runs and precedes the low priority meteorological task. Because the high priority bus task was blocked by the meteorological one it is forgotten thus essentially inverting its priority. It is forgotten about and safety measures time out.
Figure demonstrating the priority inversion problem in the Pathfinder Lander.

Power Management
Operating systems have to deal with the power management of its resources within the system they are operating. The operating system controls all of the devices within the system and thus has to decide which ones need to be switched on and operating and which ones are not currently needed and should be sleeping or switched off. It is entirely possible for the operating system to shut down a device, which will be needed again quickly, and this can cause a delay while the device restarts. However it is also possible for a device to be kept on too long and it will be wasting power. The only way around this issue is to use algorithms which enable the operating system to make appropriate decisions about which device to shut down and what conditions dictate when it should be powered up again. Examples of such management are slowing disks down during periods of inactivity, and reducing CPU power during idle periods. This is called dynamic power management. The problem now however is that the processors are now very power efficient and therefore are not likely to be the primary consumer of energy in systems. This now means that dynamic power management is becoming outdated and a new method of power management will need to be introduced into the operating system to tackle those system devices, which are still inefficiently consuming energy. Footnote on Power Management The information provided above is general to most operating systems but not specifically VxWorks. Dynamic device power management in a RTOS is essential, however, especially in an embedded system that for instance runs on batteries or needs to be economical with regard to heat output. Usually the operating system uses routines that are part of the architecture, for instance Intels ACPI interfaces. VxWorks can make use of the built-in interfaces on specific PowerPC architectures.

Conclusion
VxWorks is a versatile Real-Time Operating System which offers the developer a great deal of control over synchronisation and scheduling of tasks. This is definitely a stronger point of the operating system and in a RTOS this is essential in order to make sure things happen when they should and that they dont interfere with one another, i.e. with a safety-critical system in aerospace or healthcare. Allocation of memory in VxWorks is one of the weaker points with fragmentation common because of the first-fit algorithm used to allocate memory space. Although there are ways to get around the fragmentation I believe something to compact the memory at a specific point would be helpful but this may bring about its own problems with finding the correct time to do this if it takes time it may interfere with deadlines of critical tasks in the RTOS.

References
The VxWorks Cookbook. (2003). Retrieved, April 18, 2005 from, http://www.bluedonkey.org/cgibin/twiki/bin/view/Books/VxWorksCookBook Daleby, A., Ingstrom, K. (2002). Dynamic Memory Management in Hardware. Retrieved, April 21, 2005 from, http://www.idt.mdh.se/utbildning/exjobb/files/TR0142.pdf What really happened on Mars? (1997). Retrieved April 27, 2005 from, http://research.microsoft.com/~mbj/Mars_Pathfinder/Mars_Pathfinder.html Wikipedia. (2005) VxWorks. Retrieved May 02, 2005 from, http://en.wikipedia.org/wiki/VxWorks