Major Components Making Up A Rtos

Published Date: 02 Nov 2017

1.0 INTRODUCTION TO REAL-TIME OPERATING SYSTEMS.

1.1 What is a Real-Time Operating System?

It is important to look at what an operating system is before looking at what a real-time operating system. An operating system provides a set of basic services to interact with the hardware. The core of any operating system is the kernel; it is the bridge between applications and the actual processing done at hardware level. The following image shows the basic structure of an operating system.

Fig.1 - Basic structure of an operating system

An operating system typically provides the following, resource allocation, task management and scheduling, hardware abstraction, I/O interface, time control and error handling.

A Real-Time Operating system has the same basic structure as an Operating System however it has additional mechanisms to allow for real time scheduling of tasks.

What is meant by Real-Time? The use of the word "Real" indicates that the operating system can react to external events that occur; time would indicate that the correctness of the system would depend on not only the logical results but also on the time taken for the results to be produced.

Real-time operating systems are systems used to serve real-time application requests. Typically sensors bring data to the computer. The computer must be able to analyse data as it comes in and possibly adjust controls to modify the sensors input, typically without buffering delays, this allows it to respond predictability to unpredictable events.

A real-time system has well-defined, fixed time constraints(Deterministic), processing must be done within the defined constraints; these are measured in tenths of seconds or shorter, no memory swapping is typically allowed, if it is not processed within the defined time the system will fail.

1.2 Do I need a RTOS?

Not all systems will require an Operating System let alone a Real-Time Operating system, for example a washing machine does not require an Operating System, instead a program code for a micro controller can be written to enable it to perform various control and/or monitoring functions. A Real-Time Operating System will only be necessary if your device has to guarantee deadlines will be met under all circumstance.

Why do we even need Real-Time Operating Systems given the speed of the high-performance processors and real time patches being introduced on General Purpose Operating Systems, such as Linux and Ubuntu? They are mainly needed if embedded devices are manufactured in large volumes. By using an ultra-low power processer instead of the latest i3/i5/i7 that is within a typical GPOS, profit savings can be made on each unit; this is a massive economic advantage.

After deciding if a real-time operating system was required, there are multiple options to choose from on the RTOS's market. After looking at the market share, I realised VxWorks is currently the market leader for RTOS's, with more than 25% of the market share, VxWorks is primariliry used within larger firms more than small companies. Tied in second place is Windows XP and Windows CE, they took avantage of where VxWorks was weakest in and focused on that area (Industrial and computer-related applications). The rest of the competiotrs within this market are still viable options for any company who need the use of a RTOS.

1.3 How do RTOSs differ from GPOSs?

General Purpose Operating Systems such as Microsoft’s Windows or Linux are an excellent platform for developing and running non-critical measurement and control applications, however they are unable to offer precise timming or extended up-time's that a real-time operating system can offer. The main differences between RTOS and GPOS is as follows:

Determinism

Real-Time Operating Systems and a General Purpose Operating Systems such as Linux or Microsoft NT is the need for "deterministic" timing behaviour in the real time operating system. This means that Real-Time Operating Systems operations can be prioritised so that the critical areas of the application can get control of the processor when needed for the known and expected amounts of time.

Task Scheduling

General operating system is so that they can run a variety of applications and process simultaneously, this ensures that all the tasks receive some processing time. This may allow for low-priority processes to have more processing time than higher priority processes. In a real-time operaing systems priority-based preeemptive scheduling is used, this allows for high-proorpty threads to meet all their deadlines consistently.

Interrupt Latency

Interrupt latency is the ammount of time a device generates and interrrupt and when the devices is serviced. Real-time operating systems have a worst case latency defined, where they guarantee that all interrupts will be serviced within a certain period of time; latency is not a concern for a GPOS.

Memory Management

Memory management is a vital part within an RTOS; some embedded systems will run for years without being rebooted. If a convential memory-managment scheme to control memory was , the memory can become fragmented which would take up valuable time defragmenting as tasks are time-sensitive. GPOS are unable to offer this service.

2.0 EXAMPLE APPLICATIONS

Real-Time Operating Systems are being used in an ever increasing amount of appliances, each year there are different conferences with the market leaders showcasing there new products that use Real-Time Operating Systems. The main one held each year is the Embedded World Conference which is hosted in Germany.

A vast amount of different sectors now depend on real-time operating systems, these include:

- Defence/Aerospace

-Communications

-High-End Instrumentation

-Life Sciences

-Financial

There are different classifications of Real-Time Operating Systems; Hard or Soft;

Hard Real-Time Operating Systems are needed where deadlines for tasks cannot be missed; if a deadline is missed consequences could lead to a catastrophic effect, an example of this would be air bags within a vehicle not being released on time which could cause a life. Pace makers, car engine control system or surgical robots are other examples that would require a hard real-time: missing several beats with a pacemaker could cause someone to drop dead.

Soft Real-Time Operating System would be used within the likes of cameras and mobile phones, where a delay of a few milliseconds is acceptable as only a few people will notice this.

Generally speaking the difference between what makes a hard real-time system and a soft real-time system is the time scales involved in the system. Typically hard time tasks are monitored to the micro second accuracy whilst soft real-time tasks are to the millisecond accuracy Assuming that time is the only factor that separates these would be incorrect, an example of this would be that a digital camera could be more hard real time than a e-commerce server in the sense of being "deterministic", as an e-commerce server will take longer to finish it's process than a digital camera.

Fig.2 - Soft RT to Hard RT Transition

Major Components Making Up A RTOS

There are many components that make up a real-time operating system; the major ones I will be talking about are as follows.

Protocols

Hardware

Scheduling

Memory Allocation

Semaphores

Protocols

Protocols are the building blocks on what components are required to make up a RTOS, POSIX (Portable Operating System Interface) is a set of standards the IEEE have implemented for operating systems, these standards where introduced to improve the portability, maintenance and reuse of application code which relies on operating system services. Real-Time Operating systems have to follow POSIX 1003.lb.

The following abstraction is from the International Journal of Computer Information Systems, vol.2, no.1, 2011, which highlights the exact standards that RTOS have to follow.

Asynchronous I/O: The ability to overlap application processing and application initiated I/O operations.

Synchronous I/O: The ability to assure return of the interface procedure when the I/O operation is completed.

Memory locking: The ability to guarantee memory residence by storing sections of a process that were not recently referenced on secondary memory devices.

Semaphores: The ability to synchronize resource access by multiple processes.

Shared memory:

Shared memory: The ability to map common physical space into independent process specific virtual space.

Execution scheduling: Ability to schedule multiple tasks. Common scheduling methods include round robin and priority-based pre-emptive scheduling.

Timers: Timers improve the functionality and determinism of the system. A system should have least one clock device (system clock) to provide good real-time services. The system clock is called CLOCK_REALTIME when the system supports Real-time POSIX.

Inter-process Communications (IPC): IPC is a mechanism by which tasks share information needed for a particular application. Common RTOS communication methods include mailboxes and quests.

Real-time files: The ability to create and access files with deterministic performances.

Real-time threads: Real-time threads are schedulable entities of a real-time application that have individual timeless constraints and may have collective timeliness constraints when belonging to a runnable set of threads.

Hardware

All real-time operating systems have a KERNEL, which is the core supervisory software that provides minimal logic, scheduling, and resource management algorithms. Every RTOS has a KERNEL. On the other hand, a RTOS can be a combination of various modules including the KERNAL, a file system, networking protocols stacks, and other components required for a particular application. Normally most of the RTOS kernels contain the following components; scheduler is contained within each KERNEL and allows a set of algorithms that determines which takes executers when. Some common examples of scheduling algorithms including round robin and pre-emptive scheduling. Objects are special kernels constructs that help developers create applications for real time embedded system, common KERNEL objects include takes semaphores and message queues. Services are operations that the kernel performs on an object or generally operations such as timing interrupt handling, and resource management.

Fig.1 – Real-time operating system architecture

Design considerations have to be made when creating a real-time operating system. You have to take into consideration memory management, I/O Management, Time handling and limited resources considerations.

Task Synchronization & Interask Communication

http://ijltet.org/wp-content/uploads/2013/01/1.pdf

Scheduling

Real-time task scheduling refers to determining the order in which various tasks are to be taken up for execution by the operating system. Each real-time operating system relies on one or more task schedulers that prepare the schedule of execution. Each scheduler has its own unique algorithm in which it uses to schedule.

Each real time task is assigned a priority and a deadline. The real time tasks are of 3 types. If a task needs to be executed after regular time interval then it is called a periodic task. If a task’s relative activation time is not known then it is non-periodic task. A non-periodic task with a hard dead line is called sporadic task.

Task scheduling can be either performed pre-emptively or non-pre-emptively and either statically or dynamically. For small applications, task execution times can be estimated prior to execution and the preliminary tasks schedules statically determined. Two common constraints in scheduling are resource requirements and the preference of execution of tasks.

There are three broad types of RT scheduling algorithms:

Clock Driven

-Table-driven

-Cyclic

Event Driven

-Simple-priority based

-Rate Monotonic analysis(RMA)

-Earliest Deadline First(EDF)

Hybrid

-Round-robin

Clock driven schedulers make their scheduling decisions regarding which task to run next at the clock interrupt points. Clock driven schedulers have also got the name "offline schedulers" as they are able to fix the schedule before the system starts to run. Cyclic schedulers are very efficient, however it is very hard to determine a suitable frame size as well as a feasible schedule when the number of tasks increases. This leads to processing time being wasted wasted in almost every frame (as the frame size is larger than all task execution times). The use of an event driven scheduler can overcome these problems, event driven schedulers can handle aperiodic and sporadic tasks more efficiently. However, even-driven schedulers are less efficient as more advanced scheduling algorithms are used. In hybrid schedulers, the scheduling points are defined in both the clock interrupts and and the event occurrence.

Memory Allocation

Memory allocation is more critical in an RTOS than in other operating systems.

First, for stability there cannot be memory leaks, as RTOS are time sensative. The device should work indefinitely, without ever a need for a reboot. Instead of using dynamic memory allocation, memory is allocated at run time. Secondly, speed of allocation is important. A standard memory allocation scheme scans a linked list of indeterminate length to find a suitable free memory block. This is unacceptable in an RTOS since memory allocation has to occur within a certain amount of time. The simple fixed-size-blocks algorithm works quite well for simple embedded systems because of its low overhead.

4.0 CHARACTERISTICS AND DESIGN REQUIREMENTS OF A RTOS.

Real-time operating systems can be characterised as having five unique requirements.

Deterministic

Determinism is concerned with the time it takes, delay time, for an operating system to acknowledge an interrupt. An Operating system is said to be deterministic when it perform operations at, fixed predetermined times or within the predetermined time intervals.

Fail-soft operation

This characteristic allows a system to fail so that it is able to preserve as much capability and data as possible. Typically when a UNIX system detects corrupted data within the kernel, a failure message on the system console is displayed, it then dumps the memory contents to disk for later failure analysis, and terminates execution of the system. Real-time system will attempt either to correct the problem or minimize its effects while continuing to run. Typically, the system notifies a user or user process that it should attempt corrective action and then continues operation perhaps at a reduced level of service. In the event a shut-down is necessary, an attempt is made to maintain file and data consistency.

User Control:

In real-time operating systems, the users have find-grained control over scheduling task priority. The user must have a complete understanding between hard and soft tasks and to specify relative priorities within each class. Several characteristics may be available for the user to specify in these systems, such as, the use of paging or process swapping, what processes must always be resident in main memory, what disk transfer algorithms are to be used, the various processes' priority bands, etc.

Reliability

Reliability for Real-Time Operating Systems is very important since the system is reacting to in real time events. If a RTOS was to fail for even the shortest period of time there could be catastrophic effects, for example a car air bag failing which could cause a death. Non-real-time systems may experience a transient or multi-processor failure this is typically solved by rebooting the system or repairing/replacing the processor.

Responsive

Because they have perform operations at, fixed predetermined times or within the predetermined time intervals

Two of the most common designs for a RTOS are:

Event-driven which switches tasks only when an event of higher priority needs servicing, called preemptive priority, or priority scheduling.

Time-sharing designs switch tasks on a regular clocked interrupt, and on events, called round robin.

Time-sharing designs switch tasks more often than strictly needed, but give smoother multitasking, giving the illusion that a process or user has sole use of a machine.

5.0 COMPARATIVE ASSESSMENT OF COMMERCIALLY AVAILABLE RTOS

I am now going to review some of the most popular RTOS to identify their salient features, that make them suitable for different embedded real-time applications. I have obtained a QNX journal that compares QNX RTOS V6.1, VxWorks AE 1.1 and Windows CE.NET.

QNX RTOS v6.1

+QNX RTOS v6.1 has a true client-server based architecture, QNX adopts the approach of implementing a micro-kernel surrounded and optional cooperating processes.

+Every process including the device driver has its own virtual memory space. The system can be distributed over several nodes.

+Fast and predictable system.

+Good platform support (supports Intel processors)

-Documentation is bad.

Windows CE .NET

+Extensive platform support

+Good real time performance

+Windows CE .NET is an Operating system rich in features and is available for a variety of hardware platforms.

+The system is robust and no memory leak occurs even under stressed conditions.

+ CR uses virtual memory protection to protect itself against faulty applications.

-Documentation insufficient for such a complex system, though APIs are well documented.

VxWorks (Wind River System)

+VxWorks now also provides memory protection by means of protection domains.

+Three highly integrated components are included with VxWorks: a high performance scalable real-time operating system which executes on a target processor; a set of powerful cross-development tools; and a full range of communications software options such as Ethernet or serial line fore the target connection to the host.

-Quality of documentation is below satisfactory

-Major bug in x86 that prevents interrupt nesting

-Slow worst-case reaction to external interrupts (x86 platform)

- Poor TCP/IP network performance (socket-related bug)

6.0 CONCLUSION

In conclusion, real-time operating systems play a vital part of a company where time critical or safety critical deadlines must be met.

7.0 Useful links

http://ugpro143.blogspot.co.uk/2008/12/real-time-operating-systems-rtos.html

http://www.electro.fisica.unlp.edu.ar/temas/p7/HRT/Chapter11.pdf

http://www.cis.upenn.edu/~lee/06cse480/lec-RTOS_RTlinux.pdf

http://www.docstoc.com/docs/71701183/PAPER-3

http://www.scribd.com/doc/58421404/Ebooksclub-org-Real-Time-Systems-Modeling-Design-and-Applications-Amast-Series-in-Computing

http://www.docstoc.com/docs/21498489/RTOS-Realtime-and-Embedded-Guide

Journal Support

http://www.scribd.com/doc/60970040/rtos-book

http://www.docstoc.com/docs/44726874/Real-Time-Operating-Systems-(RTOS)

//Journal

http://www.ijerd.com/paper/vol4-issue8/A04080104.pdf

http://www.google.co.uk/search?hl=en&q=memory+management+RTOS&bav=on.2,or.r_qf.&biw=1280&bih=910&wrapid=tlif136440293391910&um=1&ie=UTF-8&tbm=isch&source=og&sa=N&tab=wi&ei=4UBTUZ7HBcLS0QXZ_YGADA#imgrc=upCYObbht6Mi6M%3A%3BjVL_XpJWTfesrM%3Bhttp%253A%252F%252Fimg.docstoccdn.com%252Fthumb%252Forig%252F21097659.png%3Bhttp%253A%252F%252Fwww.docstoc.com%252Fdocs%252F21097659%252FMemory-Management-in-VxWorks%3B1240%3B1754

uni good one

http://www.docstoc.com/docs/44726874/Real-Time-Operating-Systems-(RTOS)

//Do I need a RTOS

http://support7.qnx.com/download/download/8090/qnx_rtos_when.pdf/download/download/8090/qnx_rtos_when.pdf