Some Misconceptions Regarding Rtos

Published Date: 02 Nov 2017

ABSTRACT

In this paper we have discussed the reasons behind the emergence of RTOS and its contributions to the embedded world. RTOS is an OS, which is in small words "cannot afford to be late". It has to perform critical tasks on priority basis keeping the context switching time minimum. It is often associated with few misconceptions and has also thrown some light on its clarifications. Along with its numerous features, it also has to strive hard to reduce memory and energy footprints. Since last 20 years, RTOS is undergoing continuous evolution and has resulted into generation of many commercial RTOS products. We have selected few commercial RTOS of different categories of real-time applications and have discussed its real-time features. A comparison of the commercial RTOSs’ is also presented. We have also tried to focus on the future scope of RTOS.

INTRODUCTION

Last few years have seen the remarkable rise in the demand of embedded systems in human affairs. It has made its mark in every field ranging personal home affairs, business, process automation in industries, communications, entertainment and defense. As we know, embedded system is a combination of hardware and software and perhaps other mechanical parts designed to perform a specific function. . We realize its contribution in making our life comfortable and safe, for that it has to satisfy time and memory constraints. The performance of these systems depends on the OS which are used. Most of these systems require RTOS for such a precise task.

The first RTOS was produced more than 20 years ago by DEC for the PDP family of machines, which then undergone the process of evolution. Real time operating system (RTOS), as the name suggests provides a deadline associated with tasks and an RTOS adheres to this deadline as missing a deadline can cause affects ranging from undesired to catastrophic. RTOS must be deterministic and pre-emptive. An RTOS is effective and allows the real-time applications to be designed and expanded more easily whilst meeting the performances required.

RTOS’s are broadly classified into three categories, namely: Hard real time, firm real time and soft real time as described below:

Hard RTOS: These types of RTOS strictly adhere to the deadline associated with the tasks. These systems can’t tolerate any delay, otherwise the system will break. For ex, break system in automotives, pacemakers.

Firm RTOS: These types of RTOS are also required to adhere to these deadlines because missing a deadline may not cause a catastrophic affect but could cause undesired affects, like a huge reduction in quality of a product which is highly undesired.

Soft RTOS:  In these types of RTOS, missing a deadline is acceptable. These systems can tolerate delay. For ex, on-line Databases.

In addition, they are further classified according to the types of hardware devices (e.g. 8-bit, 16-bit, 32-bit MPU) supported.

An operating system generally consists of two parts: kernel space and (kernel mode) and user space (user mode). The basic part of any OS and which acts as a bridge between applications and the actual data processing at the hardware level, is a kernel. A kernel can provide the lowest-level abstraction layer for the resources (especially processors and I/O devices).

http://upload.wikimedia.org/wikipedia/en/thumb/8/87/Kernel-simple.png/170px-Kernel-simple.png

types of kernel

Monolithic Kernel :-

• Monolithic systems are often known as "The Big Mess" or spaghetti code.

• This type of kernel was prominent in the early days.

• Here, the system is a collection of procedures.

• Each module calls any other module.

• No information hiding (as opposed to

modules, packages, classes which are used now )

This type of OS has the problem of being difficult to debug. If one module has to be changed, then the impact on other modules may be substantial. If one module is fixed, other bugs in other modules may show up.

Monolithic designs have some inherent problems

that affect their reliability

. With millions of lines of code (LoC) and 1-16 bugs per 1000 LOC monolithic systems are likely to contain many bugs. From a high-level reliability perspective, a monolithic kernel is unstructured. The kernel may be partitioned into domains but there are no protection barriers enforced between the components.

Monolithic kernel

Micro-kernel :-

Here, code moves as much as possible from the kernel into "user" space.

Communication takes place between user

modules using message passing

• Benefits:

- easier to extend a microkernel

- easier to port the operating system to new architectures

- more reliable (less code to run in kernel mode)

- more secure (a server crashing in user space)

Eg. Mach, QNX, NT, L4

Micro-kernel

Monolithic vs. Microkernel :-

• Monolithic: tend to be easier to design, therefore faster

development cycle and more potential for growth

(see Linux)

• Monolithic: tend to be more efficient due to use of shared kernel memory (instead of IPC)

– However, very efficient micro kernels have been

designed in research and laboratory settings

• Microkernel: tend to be used for embedded systems (e.g., robotic, medical etc.)

• In Microkernel: Many OS components reside in their own, private protected address space (not possibly in

Monolithic designs).

Exo-kernel : -

• Traditionally

– Kernel hides hardware from application

– Based on conceptual model (files systems, virtual

address space, schedulers, sockets)

• Generally, this eases application development

• Sometimes problematic (e.g., security / privacy of

stored data upon deletion)

– Security-oriented application requires file system to

delete data

– Reliability-oriented application requires file system to

keep data for failure recovery purposes

• Kernel allocates physical resources to

application

• Application decides what to do with the

resources

– Application can link to a libOS to emulate a

conventional OS

– Application uses resources as it wishes

• Exo-kernel could emulate several OSs, one

for each application it runs.

RTOS’s are broadly classified into three categories, namely: Hard real time, firm real time and soft real time as described below:

Hard RTOS: These types of RTOS strictly adhere to the deadline associated with the tasks. These systems can’t tolerate any delay, otherwise the system will break. For ex, break system in automotives, pacemakers.

Firm RTOS: These types of RTOS are also required to adhere to these deadlines because missing a deadline may not cause a catastrophic affect but could cause undesired affects, like a huge reduction in quality of a product which is highly undesired.

Soft RTOS:  In these types of RTOS, missing a deadline is acceptable. These systems can tolerate delay. For ex, on-line Databases.

In addition, they are further classified according to the types of hardware devices (e.g. 8-bit, 16-bit, 32-bit MPU) supported.

Some misconceptions regarding RTOS:

RTOS should be fast: This is not true. An RTOS should have a deterministic behavior in terms of deadlines but its not true that the processing speed of an RTOS is fast. This ability of responsiveness of an RTOS does not mean that they are fast.

All RTOS are same: As already discussed we have three types of RTOS (Hard, firm and soft).

RTOS cause considerable amount of CPU overhead: Well, again this is not true. Only 1%-4% of CPU time is required by an RTOS.

There is no science in RTOS system design but most good science grew out of attempts to solve practical problems.

RTOS always consumes lot of energy, whereas current RTOS products have got very less energy footprints.

Features of RTOS

An RTOS must be designed in a way that it should strike a balance between supporting a rich feature set for development and deployment of real time applications and not compromising on the deadlines and predictability.

i. Multitasking and Pre-emptibility

An RTOS must be multi-tasked and pre-emptible to support multiple tasks in real-time applications. The scheduler should be able to preempt any task in the system and allocate the resource to the task that needs it most even at peak load.

ii. Task Priority

Preemption defines the capability to identify the task that needs a resource the most and allocates it the control to obtain the resource. In RTOS, such capability is achieved by assigning individual task with the appropriate priority level. Thus, it is important for RTOS to be equipped with this feature.

iii. Reliable and Sufficient Inter Task Communication Mechanism

For multiple tasks to communicate in a timely manner and to ensure data integrity among each other, reliable and sufficient inter-task communication and synchronization mechanisms are required.

iv. Priority Inheritance

To allow applications with stringent priority requirements to be implemented, RTOS must have a sufficient number of priority levels when using priority scheduling.

v. Predefined Short Latencies

An RTOS needs to have accurately defined short timing of its system calls. The behavior metrics are:

• Task switching latency: The time needed to save the context of a currently executing task and switching to another task is desirable to be short.

• Interrupt latency: The time elapsed between execution of the last instruction of the interrupted task and the first instruction in the interrupt handler.

• Interrupt dispatch latency. The time from the last instruction in the interrupt handler to the next task scheduled to run.

vi. Control of Memory Management

To ensure predictable response to an interrupt, an RTOS should provide way for task to lock its code and data into real.

Preemptive multithreading. In a preemptive environment, control could be moved from one process to another process at any given time. The process that was "preempted" would not even know that anything had happened, except maybe there would be a larger than average delay between 2 instructions. Preemptive multithreading allows for programs that do not voluntarily give up control, and it also allows a computer to continue functioning when a single process hangs.

Synchronization: It is a series of tools provided by the preemptive multithreaded operating system to ensure that these problems are avoided. Synchronization tools can include timers, "critical sections," and locks. Timers can ensure that a given process may be preempted, but only for a certain time.

Some misconceptions regarding RTOS:

RTOS should be fast: This is not true. An RTOS should have a deterministic behavior in terms of deadlines but its not true that the processing speed of an RTOS is fast. This ability of responsiveness of an RTOS does not mean that they are fast.

All RTOS are same: As already discussed we have three types of RTOS (Hard, firm and soft).

RTOS cause considerable amount of CPU overhead: Well, again this is not true. Only 1%-4% of CPU time is required by an RTOS.

There is no science in RTOS system design but most good science grew out of attempts to solve practical problems.

RTOS always consumes lot of energy, whereas current RTOS products have got very less energy footprints.

Limitations of RTOS:

It can be Costly.

RTOS are generally complicated and can consume a non-trivial amount of processor cycles.

RTOS doesn’t support multitasking with absence of round-robin scheduling.

PERFORMANCE ANALYSIS PARAMETERS

3.1.1 Scalability

Size or memory footprint is an important consideration. Most RTOS are scalable in which only the code required is included in the final memory footprint. Looking for granular scalability in an RTOS is a worthwhile endeavor, as it minimizes memory usage.

3.1.2 Portability

Often, a current application may outgrow the hardware it was originally designed for as the requirements of the product increases. An RTOS with such a capability can therefore be ported between processor architectures and between specific target systems.

3.1.3 Run-time facilities

Run-time facilities refer to the services of the kernel (i.e. intertask communication, task synchronization, interrupts and events handling, etc). Different application systems have different sets of requirements. Comparison of RTOSs is frequently between the kernel-level facilities they provided.

3.1.4 Run-time performance

Run-time performance of an RTOS is generally governed by the interrupt latency, context switching time and few other metric of kernel performance. This consideration is useful if the performance assessment of the application on a given RTOS is to prototype its performance-critical aspects on standard hardware.

3.1.5 Development tools

A sufficient set of development tools including debugger; compiler and performance profiler might help in shortening the development and debugging time, and improve the reliability of the coding. Commercial RTOSs usually have a complete set of tools for analyzing and optimizing the RTOSs’ behavior whereas Open-Source RTOSs will not have

Comparison of few commercial RTOS

RTOS

Initial Release

Programmed

in

Kernel

Supported platforms

1. QNX

2. RTLinux

C

Microkernel

3.Windows CE

16 November 1996; 16 years ago

C

Monolithic

x86, MIPS, ARM

4.VxWorks

1987; 26 years ago

Ada, C, C++, Java

Monolithic

x86, x86-64, MIPS, PowerPC, SH-4, ARM, SPARC Version 8 (V8)

Vxworks is a real time operating system designed by wind works systems California.

Basic Rtos properties

Rtos uses a critical priority scheduler as scheduling which can range from MFLQ(Multi level feedback queue) to round robin scheduling.

Rtos generally doesn’t support multitasking.

Upgradation in Vxworks

They used the semaphores and the mutual exclusion properties, to counter the Critical section problem.

Using the round robin process scheduling, many of the properties were enhanced and limitations removed.

The context switching was made faster, i.e. it will switch to the next task faster due to the time slice quant.

The problem of infinite loop was solved using the preemptive property of the RR scheduling.

Multitasking in Vxworks

Multitasking in Vxworks wonks on the concept of priority scheduling, it concentrates on keeping the lowest turnaround time, RTOS doesn’t generally support multitasking without proper preemptive scheduling algorithms. The SMP (symmetric Multiprocessing) in it supports the process of executing two or more symmetrical processes at the same time, in a single processor. As VxWorks has a single 64 bit processor, (supports x84 processes), it can deal with the multiprocessing problems, it’s a multi core processor. They have a single shared memory which works as both the main memory and the auxiliary memory. Multitasking, is also supported though the Round robin scheduling which assigns a time quant to processes which gives the user an impression the all the processes are being executed simultaneously. It executes all the same level priority processes almost simultaneously, and switches between them high speed, keeping the average waiting time for each process to be minimum, and least for the critical processes, the multitasking in VxWorks also includes executing several critical tasks simultaneously, due to the process scheduling. The most important part of multitasking include the kernel level multitasking, and as it is at the level of the kernel, it has nothing to do with the user level processes and the user level threads can execute independently without any interrupt from the system which speeds up the context switching time.

Protocols in VxWorks:

The VxWorks operating system used the updated IPv6 protocol system which can support approximately 3.4 x 1038 systems compared to the 7.8 x 1028 in IPv4. And unlike the IP address of IPv4 which used the 8 hex digits IPv6 uses 8 groups of hexadecimal digits which allows the no of addressing and the no of IP addresses to be increased. For eg:-

0245:1ae6:f3a5:128d:845c:1273:049b:9593, this is the example of a normal IPv6 IP address.

The advantages of using the ipv6 protocol is that it can connect to all the satellites and technical on this earth simultaneously.

File systems in VxWorks:

File system in VxWorks works on the basis of reliability more rather than speed. The files saved should be saved in the aux memory on a reliable basis rather than on the speed of operating system base, where generally the RTOS lacks, but Vxworks catched it and covered the limitation.

One major use of VxWorks was in the ‘Curiosity’ Mars rover, where the RTOS was used to set the body-clock of the rover according to the time of the planet, it is used generally in important planes like the airbus, which needs to take some critical decisions fast but should also work as a normal operating system.

CONCLUSION

RTOS is an OS, which is in small words "cannot afford to be late". It has to perform critical tasks on priority basis keeping the context switching time minimum, and trying not to enter an infinite loop. One of the main problem with RTOS is that it can go into an infinite loop without proper measures, and that it doesn’t support multitasking. RTOS has commercial uses in the field of defence, in trains, traffic control, and where ever the OS has to perform critical tasks on priority RTOS needn’t be supporting a lot of multitasking but in some cases where the lower priority or even the high priority tasks need to be excess, together, works on RTOS is used in these fields and also used in network to stay in touch in others.