Operating System Is At Very Basic Level Computer Science

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.

1.0 INTRODUCTION

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 [] .

https://prasopensource.files.wordpress.com/2011/02/ubuntu.pnghttp://zapt0.staticworld.net/images/article/2012/11/windows20820bigger-100015343-gallery.png

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. [] 

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:

Automotive

Ignition system

Engine control

Brake system

Consumer Electronics

Mobile phones

E-Book readers

MP3 players

Digital and analogue televisions

Set-top boxes (DVDs, VCRs, cable boxes)

Kitchen appliances (refrigerator, toasters, microwave ovens)

Automobiles

Toys/games

Telephones/pagers

Cameras

Global positioning systems

Handheld calculators

Videogame consoles

Industrial Control

Robotics, controls systems for manufacturing

Sensors

Medical

Infusion pumps

Dialysis machines

Prosthetic devices

Cardiac monitors

Pacemakers

Office Automation

Fax machine

Photocopier

Printers

Monitors

Scanners [] 

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% [] 

RTOS System Limitations

When developing an RTOS there are many different technical and commercial considerations to take into account that will impact the embedded RTOS system, there are a wide range or open source, commercially available or internally developed RTOS.

Scalability - Size or memory footprint is an important factor to consider. Most RTOS is scaled so only the code required is included in the final memory footprint.

Portability - Often as a products life cycle continues the hardware may improve and the product requirements may change because of this, an RTOS with capabilities to be ported to different systems regardless of the processor architecture and product requirements is therefore desirable.

Run-Time Facilities - This refers to the services that the kernel can offer (Synchronization, scheduling, timers, interrupts, event handling and so on). Different applications have a different set of requirements, when selected an RTOS for a product the RTOS are usually compared at a kernel level to see what facilities they provide. http://graphics.thomsonreuters.com/10/GLB_ERD0510.gif

Run-Time Performance - Run-time performance is usually monitored by the interrupt latency, context switching time, latency jitter and response time.

Development Tools - A sufficient set of development tools is required for the programmers, a debugger; compiler and performance profiler will help shorten development time and improve the reliability of the code. Most commercial RTOS have sufficient development tools.

Costs - When considering an RTOS for a product there are many different vendors available to use, each of these however could cost between £50 and £25000+. Not only this, some of these RTOS keep their code closed, so you could be paying for an RTOS that has a real-time kernel, input./output manager, windows system, networking, when in reality you don't need all of this, you only need some functionality from it.

3.0 MAJOR COMPONENTS MAKING UP A RTOS

typical-realtime-system

Fig X - Components in an RTOS

The major components that make up a real time operating system is the kernel, or in some cases the micro kernel. The kernel consists of a Scheduler, Memory Management, Timers, Synchronization and other real time operating systems services.

SCHEDULING & ALGORITHMShttp://sic.ici.ro/sic2000_3/Image683.gif

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 pre-empted 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 pre-emptive 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:

Pre-emptive scheduling; this is a scheduling algorithm type that allows a task to be interrupted and finish at a later time.

Different implementations of pre-emptive 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 round robin pre-emptive scheduler with 0 - 256 levels of threads, whichever task is higher (0 being higher in this case), get executed on the CPU.

TIMERS

Real time operating systems support two types of timers: periodic and aperiodic timers.

Periodic timers are mainly used to sample events at regular intervals or performing an action every x microsecond.

Aperiodic timers, these timers are set to expire only once. Watchdog timers are a popular timer that is used extensively in real time operating systems to handle exceptions if a task misses a deadline. [] 

MEMORY MANAGEMENT

There are two main types of memory management within real time operating systems, these are stack and heap management:

Within stack management, each task that occurs in an RTOS needs to be allocated with an amount of memory for storing their contexts (Counters, volatile information, data etc), for context switching, this allocation is done using task-control block model.

With heap management, upon the completion of a program initialisation, physical memory of the MCU or MPU will usually be occupied with program code, data and system stack. The remaining memory is called heap. This memory is then used by the kernel for dynamic memory allocation of data space for tasks. This is then further separated into fixed size memory blocks which can be requested by tasks, when a task finishes it is then returned to the pool. [] 

Synchronization

Synchronisation is essential for tasks to share mutually exclusive resources and or multiple concurrent tasks to be executed. There are two different types of mechanisms that are used to synchronization, event objects and semaphores.

Event Objects - are used when task synchronization is required without resource sharing. This allows one or more tasks to keep waiting for a specific event to occur. An event object itself can exist in two states as well:

Triggered - This is when an event object indicates that a waiting task may be resumed.

Non-triggered - This is when the event object is non-triggered state, a waiting task will need to stay suspended.

Semaphores - a semaphore has an associated resource count and a waiting queue. The resource count indicates the availability of the resources available. The wait queue manages the tasks waiting for the resources from the semaphore. A semaphore functions like a key that defines whether a task has the access to other resources. A task gets access to the resources when it acruqres the semaphore, when a task acquires a semaphore the count decrements by one. Likewise, it will be incremented by one when a task released the semaphore. There are three types of semaphores:

Binary Semaphore - The semaphore has a value of 0 or 1. Either of these indicates the availability or unavailability.

Counting Semaphores - The semaphore value of 9 or greater indicated whether it can be acquired or released multiple times)

Mutually Exclusion Semaphores - The semaphore value of 0 or 1, but lock count can be 0 or greater for recursive locking. [] 

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

system?

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

proprietary technology?

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

screen?

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

defined interfaces?

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

components. [] 

When designing a real time operating system each will have their own set of design requirements and characteristics, below is some of these characteristics and design requirements that you might find in real time operating systems.

Time Constraints - Every process that happens within a real time operating system will have a task associated with it, these tasks have timing constraints, the must be completed by a certain deadline and a result must be produced, there are different types of timing constraints based on delay and duration;

1.jpg

Fig X - Delay Constraint between e1 and e2

Delay constraints, a delay constraint captures the maximum time that can elapse between two events, e1 and e1 as shown above in Fig X.

2.jpg

Fig X - Deadline Constraints between e1 and e2

Deadline constraints, a deadline constraint is when task e2 must start once task e1 has finished as shown above in Fig X.

Finally, duration constraints, when an event e1 is started it has a maximum and minimum duration, any other event must not be executed until e1 has reached its minimum duration. [] 

Correctness Criterion - A correct result within a real-time system is a different criteria from a GPOS, a correct result implies not only to be logically correct but completed within the time that it was expected to be produces, a logical result completed after a deadline would be considered incorrect.

Fig X - A Basic Representation of an Embedded RTOS.

Embedded Capabilities - As discussed before in section 2.0, a vast majority of embedded systems use real-time operating systems, a real time operating system is 'embedded' into it and controls that environment, gathering data and producing results based on it. An example would be a mobile phones accelerometer, this gathers data and controls processes based on the X axis, Y axis of the phone as well as gravity.

Safety-Criticality - Safety and reliability are two completely separate issues when it comes to real time operating systems, however in some these are so intricate to the system they need to be both considered. A safe system is a system that once it fails, it does not cause any damage even if it fails. A reliable system is a system that may operate for extended periods of times, guaranteeing no failures, therefore a safety-critical system is concerned with being highly reliable without causing any damage ever. There are a few ways to achieve this:

Error Avoidance, when developing a system using good software engineering principles and practices help reduce errors - using techniques such as CASE tools and UMLs assist with this.

Error Detection and Removal, Detecting errors that creep into code, despite using the previous avoidance techniques still occurs. Constructing and completing thorough tests and reviewing code will solve this issue.

Fault-Tolerance, finally, if a system still produces errors it must be able to handle these errors and produce correct results. [] 

Concurrency - A system may need to compute multiple parameters at a given time and give different results. An example would be a Chemical Plant Control system, this needs to monitor different parameters such as the pressure, temperature and chemical concentration. These parameters are each sampled using sensors asynchronously at different rates.

Task Criticality - Task criticality is the measure of the cost of failure of a task. If a task is fundamental to the system functioning this task will execute over a lower priority task. The higher a tasks criticality the more reliable it should be made. O

Customer Hardware - A real-time system is often implemented on devices such as MP3 players or for cars. An MP3 player's processor is very tiny, it is not like a usual CPU you would find in a desktop computer (Intel or AMD), the reason the MP3 player processor is so small is because it needs to perform its function for as long as possible and only perform a certain amount of actions, play song, skip song, shuffle to name a few. A processor within a car could have one function, to check the fuel injection rate for the most efficiency at different speeds and acceleration.

4.jpg

Fig X - Traditional Versus Reactive

Reactive - Real time operating systems can be reactive to the environment and input that they receive. Within regular systems they compute data and generate output based on some function of the input. This can be expressed as O1 = φ (I1), where φ is the output data and I is the input data. Fig X above shows an example of traditional systems (a) versus real time systems (b).

Stability - When a system is under a lot of pressure it must continue to still meet deadlines, realistically not all deadlines can be met however the most critical tasks deadlines must still be met. A general operating system would give fairness to all of the tasks it's running rather than the most important tasks.

Exception Handling - Many real time systems in the world often work with or without human operators. So the system needs to handle exceptions catastrophic situations gracefully so that the entire system does not shut down. [] 

5. 0 COMPARTIVE ASSESSMENT OF COMMERCIALLY AVAILABLE RTOS

Within this section we are going to compare commercially available operating systems, we will compare 3 major real time operating systems that are currently rising within the market as seen in Fig 2. Wind Rivers VxWorks, Microsofts Windows CE and something.

VXWORKS

VxWorks was first released in 1987 and designed as a real time operating system for use in embedded systems, because the RTOS market has been growing in recent years - Intel decided to step in and purchase Wind River systems acquiring VxWorks. VxWorks is used in a variety of different markets such as; Transport Systems, Spacecraft, Robots and Programmable Controllers, Networking and Printers to name a few.

Fig 6 - VxWorks Space Missions UsagesVxWorks was developed to be used on highly scalable systems, deterministic, hard real-time kernel, it will allow companies to optimise their run time environment from the smallest requirement to the largest performance requirement. [] This is true in many cases, as shown below VxWorks is used by NASA - most recently the Mars Science Laboratory (commonly known as the 'Curiousity rover'). This is the most recent notable system that use's VxWorks to operate, however VxWorks has been used by NASA throughout their space-exploration life-cycle, below is a table showing previous missions where NASA utilize VxWorks real time operating system. [] 

Rover Name (Mission, Year)

CPU

RAM

Flash

EEPROM

OS

CPU time available for autonomy software

Pathfinder Lander (1997)

20Mhz MFC (IBM RAD6000 Processor)

128MB

None

6MB

VxWorks

< than 75%

Spirit and Oppurtunity (Mars Exploration Rover, 2004)

20Mhz BAE RAD6000

128MB

256MB

3MB

VxWorks

< than 75%

Curiosity (Mars Science Laboratory, 2011)

133Mhz BAE RAD750

128MB

4.25GB

256KB

VxWorks

< than 75%

The current release version for VxWorks is 6.9, at this released version is supports the following features:

Backwards Compatibility - VxWorks 6.9 is backward compatible with previous versions, this allows developers the leverage they need to reuses existing projects, applications and drivers. Not only this but VxWorks supports POSIX and IPv6 networking stacking and TIPC ensuring that devices can communicate with one another.

Multi-core Support - VxWorks 6.9 supports multi-core hardware, allowing multiple SMP and AMP OS configurations, allowing customers to run multiple SMP OS's in parallel.

Powerful Development IDE's - VxWorks 5.0 used the Tornado IDE however this was scraped and replaced by the popular IDE 'Eclipse'. VxWorks 6.9 uses a workbench based of Eclipse to provide developers with a powerful IDE. [] 

64-bit Processing Support - There are many companies who use 64 bit processors in their embedded systems - now VxWorks fully supports this as well. Commercial RTOS' have not taken advantage of this, VxWorks is the first ever RTOS vendor to provide this feature. What does this mean? This means that the VxWorks OS can break the wall and access memory beyond the restricted 4GB limit.

VxWorks is an excellent RTOS as it is used by more than 1 billion systems across the globe, this figure alone shows that their RTOS is a reliable and well maintained OS. They are constantly innovating themselves to keep up with the market need and requirements (Providing the first RTOS to support 64 bit processing).

Windows CE

Windows CE is a real-time operating system that is developed by Microsoft for use within embedded operating systems, Windows CE was initially released in 1996. Up until Version 3.0, Windows 3 used a priority based scheduler that supported up to 8 levels for priority - this was rewritten when Windows CE 3.0 was released and it now support 8 to 256 priority levels and it could perform

RHEALSTONE METIC

Rhealstone metric is a popular for benchmarking, within rhealstone metric there are six parameters that are considered for real time systems, these parameters are important and are identified as following, task switching time, task pre-emption time, interrupt latency time, semaphore shuffling time, unbound priority inversion time, and datagram throughout time.

Task Switching Time - is how long it takes for one context switch among equal priority tasks. The task switching time is determined by the efficiency of the kernel data structure.

Task Pre-emption Time - Task pre-emption time is the time it takes to start execution of a higher priority task. Task pre-emption time consists of three components:

Task switching time

Time to recognise the event enabling the higher priority.

Time to dispatch it.

Interrupt Latency Time - Interrupt latency time is defined as the time it takes to start the execution of the required ISR after an interrupt occurs.

Semaphore Shuffling Time - This is defined as the time that occurs between a lower priority task releasing a semaphore and a higher priority task to start running.

Unbounded Priority Inversion Time - This is defined as the time it takes for the operating system to recognise priority inversion and run the task holding the resource.

Datagram Throughput Time - This parameter indicates the number of kilobytes of data that can be transferred between two tasks without using shared memory or pointers. [] 

However there are considerable drawbacks using the Rhealstone metric system - there is no real justification why we are considering these six measurements. As well as this the RTOS ability to meet applications deadlines with the task scheduler is also not taken into consideration.

Article name: Operating System Is At Very Basic Level Computer Science essay, research paper, dissertation