This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.
Within this research document we will carry out and in-depth study into Real-Time Operating Systems, some of the key considerations that we need to account for when discussing RTOS's are as follows: Typical requirements; constraints; and applications of real time operating systems. Illustrations of the typical characteristics and design requirements for RTOS exploring some issues such as real-time computing, hard real-time and soft-real-time and determinism to name a few. Finally, this paper shall cover a comparative assessment of commercially available real-time operating systems with relevant and up-to-date research.
What is a real-time operating system? Well, before we get into what a 'real-time' operating system is, let's explore what an operating system is at a very basic level.
"AnÂ operating systemÂ orÂ OSÂ is a software program that enables the computerÂ hardwareÂ to communicate and operate with the computerÂ software. Without a computer operating system, a computer andÂ softwareÂ programs would be useless"  - Reference!
From this definition we can already see that an operating systems purpose is to exploit what hardware components we have within our computers (CPU, RAM, GPU, Storage). The operating system lets each of these components work with one another. Operating systems that we may be familiar with could range from Microsofts, Windows 95, ME, XP, Vista, 7 and 8  . To other lesser known Linux based operating systems such as Ubuntu, Mint and Fedora  .
Fig 1 - Windows 8 and Ubuntu
These operating systems in Fig 1 can be described as 'General Purpose Operating Systems'.
A real time operating system is an operating system that performs tasks with very precise timing and to a high degree of reliability. They need to perform functionally and reliable for as long as realistically possible. There are two types of real time operating systems, 'hard-time' and 'soft-time'. A hard-time real time operating system is one that must complete a task or procedure and that task must be completed with zero delays, if a delay occurs then the entire system would be considered useless. An example of this would be a break system within your car. On the other hand soft-time operating systems do allow tasks to be completed late, it will not have an overall impact on the system. An example of this would be an MP3 player. 
Both of these real time operating system types use 'jitter', a hard real time system has much less jitter than a soft real time operating system. Jitter is essentially undesired deviation from true periodicity of an assume periodic signal in electronics and telecommunications - jitter could be observed as the frequency, amplitude or phase of periodic signals.  Jitter within a soft real time operating system
DO I NEED AN RTOS?
It depends entirely on the end user and the purpose of the system or application. In a GPOS, it uses a scheduler that implements 'fairness' policies, so each thread can operate when needed. The main problem with this is if a high priority thread need's to execute it can't as it needs to wait in line for the GPOS scheduler to get to it.
So what does an RTOS allow you to do?
Perform tasks within a guaranteed worst-case timeframe.
Carefully prioritize different sections of your program
Run loops with nearly the same timing each iteration (microseconds)
Detect if a loop missed its timing goal. 
However in an RTOS, threads are executed in order of their priority. If a higher thread with high priority becomes runnable, it simple tells the CPU to do a context switch and become the new runnable thread and remain running until it's task is finished - unless of course another higher thread comes in and needs to run itself. This is known as priority-based preemptive scheduling. This allows time-critical threads to meet their deadlines. 
If your system does not need this scheduling then you do not need an RTOS a GPOS would suffice for your needs.
RTOS VS GENERAL PURPOSE
Where would we use a GPOS? Any system or application that are not time critical (Or deterministic) is suitable to use a GPOS, previous mentioned GPOS' are Windows, Linux and Macs. On the other hand, we would use RTOS' for time critical systems, they can be used for when we want to give the end user a quick and predictable response. A good example to explain the difference between an RTOS and GPOS would be that your own home personal computer can view and edit word documents - once you click 'save' after editing a word document depending on the other tasks and resources the save might happen instantly - or it could take 5 minutes! Whereas in comparison, an ATM machine would use a RTOS, after you've selected how much money you would like it generally doesn't take longer than 5 seconds for the machine to dispense your card and then your money. Below are some of the key factors that set apart RTOS' from GPOS. 
Task Scheduling -Â General purpose operating systems are optimized to run a variety of applications and processes at the same time, thereby ensuring that all tasks receive at least some processing time. As a consequence, low-priority tasks may have their priority boosted above other higher priority tasks, which the designer may not want. However, RTOS uses priority-based pre-emptive scheduling, which allows high-priority threads to meet their deadlines consistently. All system calls are deterministic, implying time bounded operation for all operations and ISRs.Â This is important for embedded systems where delay could cause a safety hazard. The scheduling in RTOS is time based.Â In case of General purpose OS, like Windows/Linux, scheduling is process based.
Determinism -Â The key difference between general-computing operating systems and real-time operating systems is the "deterministic " timing behaviour in the real-time operating systems.Â "Deterministic" timing means that OS consume only known and expected amounts of time. RTOS have their worst case latency defined. Latency is not of a concern for General Purpose OS.Â
Latency issues - An issue with GPOS is that when you're running a GPOS and launch multiple applications and working on multiple pieces of work, threads are all running concurrently with one another - the GPOS doesn't care for managing them in the same sense that a RTOS would care about the management of the threads, in a RTOS threads get 'bounded' and once threads are bounded they have to execute within a specific time.
Hardware and Economical factors - RTOS need specific tailored hardware for the function that it is to carry out, for our ATM machine it would need sufficient Memory and CPU power to be able to carry out calculations and perform actions such as withdrawing cash, this ATM machine doesn't need Gigabyte's for RAM, or a CPU that has 4 cores and 2.8 Gigahertz processing speed. This ATM machine will most likely be operating with Megabytes and Megahertz to perform its function, this is cheap and is using the most appropriate components for its functionality - therefore this is economical.
Pre-emptive kernel -Â Within a GPOS, an executing thread can only be stopped using 2 methods, the first being if the thread is terminated and the second being if a thread enters a 'waiting' state. Once one of the two above criteria has been met the kernel will perform a 'context switch' which is basically telling the kernel to hand over the execution from one thread to another. The next thread that has the highest priority to run gets run. Within RTOS there is a time period defined as a 'tick' - once each tick has happened it checks if there are ready to run threads that are higher than the currently executing thread, if there is a thread that has a higher priority it will context switch to that higher thread and begin to run it, the thread that use to be running becomes pre-empted. 
Priority Inversion -Â Within GPOS, low priority threads can keep control of the CPU - there prevents higher priority threads from accessing it and completing their tasks this is known as 'priority inversion'.
Usage -Â RTOS are typically used for embedded applications, while General Purpose OS are used for Desktop PCs or other generally purpose PCs. 
2.0 EXAMPLE APPLICATIONS
We use real time operating systems every day in each of our lives, they are such an important factor it is peculiar why there isn't as much focus as other markets such as Android VS Apple OS in the mobile environment - nevertheless within the recent years certain members of the RTOS vendor market have been steadily increasing their income through this market.http://www.ghs.com/images/MarketShareGrowth10.jpg
Fig 3 - RTOS Growth 03-10
Green Hills in 2010 is the current market leader with their RTOS named 'INTEGRITY', they have embedded systems in many different markets such as aerospace and defence, consumer, industrial, medical, mobile devices, networking and telecom, software defined radio (SDR) and wireless devices. 
Other areas where we use RTOS are as follows:
Digital and analogue televisions
Set-top boxes (DVDs, VCRs, cable boxes)
Kitchen appliances (refrigerator, toasters, microwave ovens)
Global positioning systems
Robotics, controls systems for manufacturing
Why are Embedded Systems that use RTOS so important in today's age?
All of these application area's are growing markets that have massive potential to make profit some examples below are:
Fig 4 - E-Reader market Growth
E-readers, since 2008 E-readers have flourished within the market, almost replacing the book as they are convenient for people who would commute to work, travel on holiday or simple enjoy reading as a hobby within their own homes. This shows that vendors such as Freescale have taken advantage of this market and are cashing in using their i.MX508 processor to power some of the popular E-readers. 
Another market to consider that has massive growth would be the mobile market, in 3Q2012 they shipped 179.7 million units when compared to 3Q2011 shipped 123.7 million units. This is a market growth of 45.3% 
Embedded RTOS System Limitations
3.0 MAJOR COMPONENTS MAKING UP A RTOS
blahblah over shit here
Fig 5 - A basic representation of a schedule model
A scheduler is the above model in Fig 5 is concerned with certain criteria: Throughput, Latency - Turnaround time and Response time and finally the Fairness/Waiting time. Different implementations of the scheduler provide different results, some schedulers may be more concerned with throughput, other's may be concerned with the accuracy of completing the task - real time operating systems are concerned with the accuracy of completing tasks. 
There are many different types of scheduling algorithms that are used by operating system. Some of these are
First-come-first-served (FCFS); selects the process that has been waiting the longest for service.
Round-robin (RR); Use 's time slicing to limit any process to a short burst of processor time and rotate between all the ready processes.
Shortest process next (SPN); Selects the process with the shortest expected processing time and do not switch from it.
Shortest remaining time (SRT); Selects the process that has the shortest time remaining to run, this may be preempted by another process when it becomes ready.
Highest response ratio next (HRRN); Base the scheduling decision on an estimate of normalized turnaround time.
Feedback; Creates a set of scheduling queues and allocates a certain amount of time to each queue based on their usage. 
Real time operating systems are not concerned with sheer speed of completing tasks, they are concerned with the accuracy that a task has been completed.
Within real-time operating systems there are two key factors when scheduling: static and dynamic approaches.
There are different classes for real-time operating systems, the four main categories are as follows:
Static table-driven; these perform a static analysis and the results from this analysis result in a schedule (Otherwise known as a table), this is used at run-time to decide when a task must begin execution.
Static priority-driven preemptive approaches; much like the aforementioned one, no explicitly schedule is created, at run time, tasks with the highest priority are executed first.
Dynamic planning-based approaches; Unlike the previous two which create schedules based on data, a dynamic planning-based approach feasibility is checked at run time.
Dynamic best-effort approaches; with this final approach, no feasibility checking is done at run-time, the system merely tries its best to meet the deadlines and if it can't it aborts the task during execution. 
Some common RTOS scheduling algorithms are as follows:
Preemptive scheduling; this is a scheduling algorithm type that allows a task to be interrupted and finish at a later time.
Different implementations of preemptive scheduling are as follows:
Rate-monotonic scheduling; this is a static priority scheduling class. The static priority are assigned based on the cycle duration of the jobs. The shorter the cycle the higher the job's priority.
Earliest deadline first scheduling; also known as 'least time to go' This is a dynamic scheduling algorithm that creates a priority queue, whenever a scheduling event occurs it then searches the queue for the process that has the closest deadline then executes that task.
Priority-based scheduling; the scheduler executes the thread that has the highest priority task that is currently ready to execute.
There are many different RTOS vendors out there, each of them use different implementations for their schedulers, vxWorks uses a priority-based scheduling system that has 0 - 256 priority levels, whichever task is higher (0 being higher in this case), get executed on the CPU.
4.0 CHARACTERISTICS AND DESIGN REQUIREMENTS OF A RTOS.
An RTOS can help make complex applications both
predictable and reliable; in fact, the precise control
over timing made possible by an RTOS adds a form of
reliability that cannot
be achieved with a GPOS. (If a system based on a
GPOS doesn't behave correctly due to incorrect timing
behaviour, then we can justifiably say that the system is
unreliable.) Still, choosing the right RTOS can itself be
a complex task. The underlying architecture of an
RTOS is an important criterion, but so are other
factors. These include:
Flexible choice of scheduling algorithms - Does
the RTOS support a choice of scheduling
algorithms (FIFO, round robin, sporadic, etc.)?
Can the developer assign algorithms on a per thread basis, or does the RTOS force him into
assigning one algorithm to all threads in the
Time partitioning - Does the RTOS support time
partitioning, which can provide processes with a
guaranteed percentage of CPU cycles? Such
guarantees simplify the job of integrating
subsystems from multiple development teams or
vendors. They can also ensure that critical tasks
remain available and meet their deadlines, even
when the system is subjected to denial of service
(DoS) attacks and other malicious exploits.
Support for multi-core processors - The ability to
migrate to multi-core processors has become
essential for a variety of high-performance
designs. Does the RTOS support a choice of multiprocessing models (symmetric multiprocessing,
asymmetric multi-processing, bound
multiprocessing) to help developers take best
advantage of multi-core hardware? And is the RTOS
supported by system-tracing tools that let
developers diagnose and optimize the performance
of a multi-core system? Without tools that can
highlight resource contention, excessive thread
migration, and other problems common to multicore designs, optimizing a multi-core system can
quickly become an onerous, time-consuming task.
Tools for remote diagnostics - Because
downtime is intolerable for many embedded
systems, the RTOS vendor should provide
diagnostics tools that can analyze a system's
behaviour without interrupting services that the
system provides. Look for a vendor that offers
runtime analysis tools for system profiling,
application profiling, and memory analysis.
Open development platform - Does the RTOS
vendor provide a development environment based
on an open platform like Eclipse, which permits
developers to "plug in" their favourite third-party
tools for modelling, version control, and so on? Or
is the development environment based on
Graphical user interfaces - Does the RTOS use
primitive graphics libraries or does it support
multiple HMI technologies (HTML5, Qt, OpenGL
ES, etc.) and provide advanced graphics
capabilities such as multi-layer interfaces, multithreaded displays, accelerated 3D rendering, and a
true windowing system? Can the look-and-feel of GUIs be easily customized? Can the GUIs display
and input multiple languages (Chinese, Korean,
Japanese, English, Russian, etc.) simultaneously?
Can 2D and 3D applications easily share the same
Standard APIs - Does the RTOS lock developers
into a proprietary API, or does it provide certified
support for standard APIs such as POSIX and
OpenGL ES, which make it easier to port code to
and from other environments? Also, does the
RTOS offer comprehensive support for the API,
or does it support only a small subset of the
Middleware for digital media - Flexible support
for digital media is becoming a design requirement
for an array of embedded systems, including car
radios, medical devices, industrial control systems,
media servers, and, of course, consumer electronics. A system may need to handle multiple
media sources (device, streaming, etc.),
understand multiple data formats, and support a
variety of DRM schemes. By providing well designed middleware for digital media, an RTOS
vendor can eliminate the considerable software
effort needed to connect to multiple media
sources, organize the data, and initiate proper
data-processing paths. Moreover, a well-designed
middleware solution will have the flexibility to
support new data sources, such as a next generation iPod, without requiring modifications
to the user interface or to other software