Real Time Operating System

8/20/2013

Contents

What is a Real Time Operating System? Difference between RTOS & other common OS? Characteristics of a good RTOS? Hard RTOS. Soft RTOS. The Scheduler. Task & Task States. RTOS existing in market. Introduction to RTLinux. Writing RTLinux Modules. Soft & Hard Interrupts. Applications of RTLinux. Conclusion.

8/20/2013

What is a Real Time Operating System?

Real Time In OS : The ability of OS to provide a required level of service in a bounded response time.
RTOS : Has a well defined, fixed time constraint. : Processing must be done within the define constraints or the system will fail. : Real Time system is considered to function correctly only if it returns the correct result within any time constraint. : Real Time system is one in which correctness of computations not only depends on logical correctness of the computation but also upon the time at which the result is produced. : If timing constraints of the system are not met , system failure is said to have occurred.

8/20/2013

What is the difference between RTOS & other common system?

Most RTOS are actually different from desktop operating systems such as windows & Unix. Firstly, other operating systems takes control as soon as system is turned on and lets you start your applications.Also compilation & linking of application is done separately from operating system. Whereas in case of RTO, at boot time, your application usually gets control first and then it starts the RTOS. So here we link the RTOS with our application. Secondly, many RTOS do not protect themselves as carefully from application as do other desktop operating systems. Finally, RTOS typically includes just the services that you need for your embedded system and no more.This feature of RTOS enables it to save memory

8/20/2013

Characteristics of a good RTOS.

Saving Memory : One special consideration if you use an RTOS is that each task needs memory space for its stack. Therefore you should ensure that your system allocates only as much stack memory as is needed.So the method for determining how much stack space a task needs is to examine your code.Each function call , function parameter and local variable takes up certain number of bytes on the stack.Then you must add space for the worst case I.e nesting of interrupt routines and some space for RTOS itself. The Interrupt Latency : For every system call, the maximum time it takes should be predictable & independent of number of objects in the system. System Interrupt Level : A good RTOS should have a good documentation, should be delivered with good tools to develop and tune your application. So a RTOS supporting many devices will have more advantageous than a simple very good nano - Kernel.

8/20/2013

Hard RTOS

Hard RTOS guarantees critical task will complete in a given amount of time.For this all delays in the system must be bounded. If a process completes correctly but takes longer than given amount of time, the process fails. The Scheduler plays an important role in Hard RTOS. The Scheduler either admits the process, guaranteeing that the process will complete on time, or it rejects the request if it is impossible.

8/20/2013

Soft RTOS

Soft RTOS are less restrictive than Hard RTOS. In Soft RTOS critical tasks are given priority over non critical tasks. Here also, like Hard RTOS, delays need to be bounded so that critical task do not wait for ever, but these are not as severe as in Hard RTOS. In this if a process completes correctly, but takes longer than its given amount of time, the result may still be useful. Like in Hard RTOS, Scheduler plays an important role in Soft RTOS also. Important aspects of implementing Soft RTOS are : 1) The system must have priority scheduling and the real time process must have highest priority. 2) The dispatch latency must be small.The smaller the latency, the faster the real time process can start executing once it is runnable.

8/20/2013

The Scheduler

The Scheduler keeps the track of state of each task and decides which one should go into running state. It looks at the priorities you assign to the tasks and among the tasks that are not in block state, the one with the highest priority runs and the rest of them waits in the ready state.The lower priority tasks just have to wait. How does the scheduler know when a task has to become Blocked or Unblocked? The RTOS provides a collection of functions that tasks can call to tell the scheduler, what events they want to wait for and to signal those events, which have happened. What happens if all the tasks are blocked ? If all the tasks are blocked then the Scheduler will spin in some tight loop inside of the RTOS, waiting for something to happen. What if two tasks of same priority are ready? It depends on the RTOS that you use. Many systems solve this problem by making it illegal to have same tasks of same priority. Some RTOS have employed the concept of time slicing between two tasks.

8/20/2013

Tasks & Task States

The basic building blocks of software written under an RTOS is the task.Each task in an RTOS is always in one of the three states : 1). Running : Which means that the microprocessor is executing the instruction that make up this task. Unless yours is a multiprocessor system, there will be only one task, which will be in running state at any given time. 2). Ready : Which means that this task is ready for execution but since some other task is undergoing execution presently, this task is waiting for its turn.Any number of tasks can be in this state. 3). Blocked : Which means that this task hasnt got anything to do right now, even if the microprocessor becomes available. Tasks get into this state because they are waiting for some external event to happen.Any number of tasks can be in this state as well.

8/20/2013

RTOS Existing In Market

Wind River Systems VxWorks. Integrated Systems pSOS. QNX Systems QNX. FSM Labs RTLinux. Kodaks AMX. Microtecs VRTX. Microwares OS/9. Accelerated Technologys Nucleus.

8/20/2013

Real Time System

A system is said to be Real Time if it is required to complete its work & deliver its services on time. Example Car Driver

All tasks in that system must execute on time.

8/20/2013

Example - Car Driver

Mission: Reaching the destination safely. Controlled System: Car. Operating environment: Road conditions and other cars. Controlling System - Human driver: Sensors - Eyes and Ears of the driver.

8/20/2013

Example - Car Driver

Controls: Accelerator, Steering wheel, Break-pedal. Actuators: Wheels, Engines, and Brakes Critical tasks: Steering and breaking.

Non-critical tasks: Turning on radio.

Performance is not an absolute one. It measures the goodness of the outcome relative to the best outcome possible under a given circumstance.

8/20/2013

Example - Car Driver

Cost of fulfilling the mission Efficient solution. Reliability of the driver Fault-tolerance is a must

8/20/2013

Hard and Soft Real Time Systems

Hard Real Time System

Failure to meet deadlines is fatal example : Flight Control System

Late completion of jobs is undesirable but not fatal. System performance degrades as more & more jobs miss deadlines Online Databases

Soft Real Time System

8/20/2013

Terms and Concepts

A real-time system is a system with performance deadlines on computations and actions; that is, system correctness depends on the timeliness of results. An embedded system is a system that exists within a larger system. A job is a unit of work that is scheduled and executed by the system (Ji,k ). A task is a set of related jobs that provide some system function i = { Ji,1, Ji,2, ... , Ji,n }.

8/20/2013

Latency

The latency (or tardiness) of a task is the difference between the instant of time on which the task should have started (or finished) and the instant of time on which it actually did.

8/20/2013

Latencies are due to several factors:

the timing properties of processor, bus, memory (on-chip cache, off-chip RAM and ROM) and peripheral devices the scheduling properties of the operating system the preemptive ness of its kernel the load on the system (i.e., the number of tasks that want to be scheduled concurrently), and

8/20/2013

Deadlines

The release time (or arrival time) of a job is the time at which the job becomes available for execution ( ri or Ri ). The response time of a job is the length of time between the release time of the job and the time instant when it completes. The relative deadline of a job is the maximum allowable response time of a job ( Di ).

8/20/2013

Deadlines

The absolute deadline of a job is the time at which a job must be completed ( di = ri + Di ).

8/20/2013

Scheduler

A scheduler assigns jobs to processors. A schedule is an assignment of all jobs in the system on available processors (produced by scheduler). The execution time (or run-time) of a job is the amount of time required to complete the execution of a job once it has been scheduled ( ei or Ci ).

8/20/2013

Feasible Schedule

A valid schedule is a feasible schedule if every job meets its timing constraints; e.g., completes execution by its deadline. A set of jobs is schedulable according to a scheduling algorithm if (when) using the algorithm (the scheduler) always produces a feasible schedule. The lateness of a job is the difference between its completion time and its deadline. If the job completes early, its lateness will be negative

8/20/2013

Periodic Task

A periodic task i = { Ji,1, Ji,2, ... , Ji,n } is a sequence

of jobs with identical parameters with: a period ( pi or Ti ) equal to the minimum length of time between the release times of consecutive jobs, an execution time ( ei or Ci ) equal to the maximum execution time of any job in the task, and a phase ( i ) equal to the release time of the first job in i.

8/20/2013

Role of an OS in Real Time Systems

Standalone Applications

Micro controller based Embedded Systems

Some Real Time Applications are huge & complex

Multiple threads Complicated Synchronization Requirements File system / Network / Windowing support

8/20/2013

Features of RTOSs

Scheduling. Resource Allocation. Interrupt Handling. Other issues like kernel size.

8/20/2013

Scheduling in RTOS

More information about the tasks are known

No of tasks Resource Requirements Release Time Execution time Deadlines

Being a more deterministic system better scheduling algorithms can be devised.

8/20/2013

Scheduling Algorithms in RTOS

Clock Driven Scheduling Weighted Round Robin Scheduling Priority Scheduling

8/20/2013

Scheduling Algorithms in RTOS (contd)

Clock Driven

All parameters about jobs (release time/ execution time/deadline) known in advance. Schedule can be computed offline or at some regular time instances. Minimal runtime overhead. Not suitable for many applications.

8/20/2013

Scheduling Algorithms in RTOS (contd)

Weighted Round Robin

Jobs scheduled in FIFO manner Time quantum given to jobs is proportional to its weight Not suitable for precedence constrained jobs.

Job A can run only after Job B. No point in giving time quantum to Job B before Job A.

8/20/2013

Scheduling Algorithms in RTOS (contd)

Priority Scheduling

Processor never left idle when there are ready tasks Processor allocated to processes according to priorities Priorities

static - at design time Dynamic - at runtime

8/20/2013

Priority Scheduling

Earliest Deadline First (EDF)

Process with earliest deadline given highest priority

slack = relative deadline execution left For periodic tasks Tasks priority inversely proportional to its period

Least Slack Time First (LSF)

Rate Monotonic Scheduling (RMS)

8/20/2013

Resource Allocation in RTOS

Resource Allocation

The issues with scheduling applicable here. Resources can be allocated in

Weighted Round Robin Priority Based

Some resources are non preemptible

Example : semaphores

Priority Inversion if priority scheduling is used

8/20/2013

Priority Inversion Problem

Priority inversion is an undesirable situation in which a higher priority task gets blocked (waits for CPU) for more time than that it is supposed to, by lower priority tasks. Example: Let T1 , T2 , and T3 be the three periodic tasks with decreasing order of priorities. Let T1 and T3 share a resource S.

8/20/2013

Priority Inversion -- Example

T3 obtains a lock on the semaphore S and enters its critical section to use a shared resource. T1 becomes ready to run and preempts T3. Then, T1 tries to enter its critical section by first trying to lock S. But, S is already locked by T3 and hence T1 is blocked. T2 becomes ready to run. Since only T2 and T3 are ready to run, T2 preempts T3 while T3 is in its critical section.

8/20/2013

Priority Inversion -- Example

Ideally, one would prefer that the highest priority task (T1) be blocked no longer than the time for T3 to complete its critical section. However, the duration of blocking is, in fact, unpredictable because task T2 got executed in between.

8/20/2013

Solutions to Priority Inversion

Priority Inheritance

The thread holding a resource inherits the priority of the thread blocked on that resource

8/20/2013

Priority Inheritance Protocol

Priority inheritance protocol solves the problem of priority inversion. Under this protocol, if a higher priority task TH is blocked by a lower priority task TL, because TL is currently executing critical section needed by TH, TL temporarily inherits the priority of TH. When blocking ceases (i.e., TL exits the critical section), TL resumes its original priority. Unfortunately, priority inheritance may lead to deadlock.

8/20/2013

Other RTOS issues

Interrupt Latency should be very small

Kernel has to respond to real time events Interrupts should be disabled for minimum possible time

For embedded applications Kernel Size should be small

Should fit in ROM No Virtual Memory

Sophisticated features can be removed

8/20/2013

Linux for Real Time Applications

Scheduling

Priority Driven Approach

Optimize average case response time Aim to reduce response times of processes

Interactive Processes Given Highest Priority

Real Time Processes

Processes with high priority No notion of deadlines

Resource Allocation

No support for handling priority inversion

8/20/2013

Other Problems with Linux

Processes are non preemptible in Kernel Mode

System calls like fork take a lot of time High priority thread might wait for a low priority thread to complete its system call Context switch takes several hundred microseconds

Processes are heavy weight

8/20/2013

RTLinux
Real Time Kernel at the lowest level Linux Kernel is a low priority thread

Executed only when no real time tasks

Interrupts trapped by the Real Time Kernel and passed onto Linux Kernel

Software emulation to hardware interrupts

Interrupts are queued by RTLinux

8/20/2013

RTLinux (contd)
Real Time Tasks Non Real Time Tasks are developed in Linux Communication

Queues Shared memory

8/20/2013

RT Linux - Approach
RT Linux uses VM concept limited to interrupt emulation. It slips a small, simple, RT OS underneath Linux. Linux becomes an idle task for this OS

8/20/2013

8/20/2013

RTLinux Framework

8/20/2013

RT Linux Approach(Cont..)
A layer of emulation software between Linux kernel and interrupt controller hardware. Prevents disabling of interrupts by Linux

8/20/2013

RT Linux Tasks

Initial Design Each RT task executed in its own address space. High overhead of context switching as TLB had to be invalidated. High overhead of system calls. Now all RT tasks run in the same address space (in the kernel space) and at the highest privilege level.

8/20/2013

RT Linux Tasks (Contd.)

RT tasks run as kernel modules. Can be dynamically added. Tasks have integer context for faster context switching (unless FP context is explicitly requested). Hardware context switching provided by x86 is not used. Task resources should be statically allocated (kmalloc etc. should not be used within an RT task).

8/20/2013

RT Linux Scheduling
RT Linux is module based the scheduler is itself a loadable kernel module. Default A simple preemptive priority based scheduler where the tasks are statically assigned priorities. The highest priority task ready to run is scheduled.

8/20/2013

RT Linux Scheduling (Cont.)

Alternate scheduling policies

Earliest Deadline First (EDF) A dynamic priority scheduler in which the task with the nearest deadline is scheduled. Rate Monotonic (RM) A static priority scheduler for periodic tasks where the task with the smallest period is assigned the highest priority. This is provably the optimal policy.

8/20/2013

Inter-Process Communication (IPC)

Linux kernel may be preempted by an RT task even during a system call, so no Linux routine can be safely called from real-time tasks. RT fifos used for communication between RT tasks and Linux user processes. RT fifo buffers are allocated in kernel address space.

8/20/2013

Other RTOSs (contd)

VxWorks

Monolithic Architecture Real Time Posix compliant Object Oriented OS

pSOS

8/20/2013

Introduction To RTLinux

Developed by FSMLabs Inc. in 1995 in New Mexico. It is a Hard RTOS that co-exists with Linux OS. With RTLinux it is possible to create Real Time POSIX.1b Threads that will run at precisely specified moments of time. WARNING : Real Time programs in RTLinux are executed in Kernel space and have little or no protection against bugs in users code. Special care must be taken when programming real time tasks because programming errors may bring the system down. For this RTLinux supplies a debugger within its source tree under the directory debugger. So use of debugger is strongly recommended to reduce the risk of to reduce the risk of system crashes. For those who are primarily interested in hard real time control and not particularly interested in learning how to use RTLinux itself,can take a look at FSM Labs RTiC-Lab at www.rtic-lab.org . RTiC-Lab is a front end to RTLinux that greatly simplifies hard real time control implementation, monitoring and tuning. For those who are interested in running RTLinux on an industry standard PC-104 board or other type of minimal or embedded system,can refer to FSMLabs MiniRTL project , found www.rtlinux.org/ minirtl.html. MiniRTL fits on a single floppy disk and provides full RTLinux capabilities.

8/20/2013

Linux Kernel

8/20/2013

RTLinux Kernel

8/20/2013

Writing RTLinux modules.

Understanding an RTLinux Program : In RTLinux, programs are modelled as modules which are loaded into the Linux kernel space. A Linux module is nothing but an object file, usually created with the -c flag argument to gcc. The module itself is created by compiling an ordinary C language file in which the main () function is replaced by a pair of init/cleanup functions: int init_module(); void cleanup_module(); init_module() function is called when the module is first loaded into the kernel. It should return 0 on success and returns negative value on failure. cleanup_module() is called when module is unloaded. For example :If we assume that a user has created a C file named my mo-dule. c, the code can be converted into a module by typing the following: gcc -c {SOME-FLAGS} my_module.c This command creates a module file named my module.o, which can now be inserted into the kernel. To insert the module into the kernel, we use the insmod command. To remove it, the rmmod command is used.

8/20/2013

The Basic API

A real time application is usually composed of several threads of execution. Threads are light-weight processes which share a common address space. Conceptually, Linux kernel control threads are also RTLinux threads (with one for each CPU in the system). In RTLinux, all threads share the Linux kernel address space. To create a new real time thread, we use the pthread create(3) function. This function must only be called from the Linux kernel thread (i.e., using init module()): #include <pthread.h> int pthread_create(pthread_t * thread, pthread_attr_t * attr, void *(*start_routine)(void *), void * arg); The thread is created using the attributes specified in the attr thread attributes object. If attr is NULL, default attributes are used. The ID of the newly created thread is stored in the location pointed to by thread. The function pointed to by start routine is taken to be the thread code. It is passed the arg argument. To cancel a thread, use the POSIX function: pthread cancel(pthread thread);

8/20/2013

Time Facilities

RTLinux provides several clocks that can be used for timing functionality, such as as referencing for thread scheduling and obtaining timestamps. Here is the general timing API: #include <rtl_time.h> int clock_gettime(clockid_t clock_id, struct timespec *ts); hrtime_t gethrtime(void); struct timespec { time_t tv_sec; /* seconds */ long tv_nsec; /* nanoseconds */ }; To obtain the current clock reading,we use the clock_gettime(3) function where clock_id is the clock to be read and ts is a structure which stores the value obtained. The hrtime_t value is expressed as a single 64-bit number of nanoseconds. Thus, clock_gethrtime(3) is the same as clock_gettime, but returns the time as an hrtime_t rather than as a timespec structure.

8/20/2013

Scheduling Threads

RTLinux provides scheduling, which allows thread code to run at specific times. RTLinux uses a pure priority-driven scheduler, in which the highest priority (ready) thread is always chosen to run. RTLinux uses the following scheduling API: int pthread_setschedparam(pthread_t thread, int policy, const struct sched_param *param); int pthread_make_periodic_np(pthread_t thread, hrtime_t start_time,hrtime period); int pthread_wait_np(void); int sched_get_priority_max(int policy); int sched_get_priority_min(int policy);

8/20/2013

A Simple Program In RTLinux

This program will execute two times per second, and during each iteration it will print the message: Im here, my arg is 0 Program for hello.c : #include <rtl.h> #include <time.h> #include <pthread.h> pthread_t thread; void * start_routine(void *arg) { struct sched_param p; p . sched_priority = 1; pthread_setschedparam (pthread_self(), SCHED_FIFO, &p); pthread_make_periodic_np (pthread_self(), gethrtime(), 500000000); while (1) { pthread_wait_np(); rtl_printf("Im here; my arg is %x\n", (unsigned) arg); } return 0;
8/20/2013

A Simple Program In RTLinux (contd.)

} int init_module(void) { return pthread_create (&thread, NULL, start_routine, 0); } void cleanup_module(void) { pthread_cancel (thread); pthread_join (thread, NULL); }

8/20/2013

Compiling and Executing hello .c

In order to execute our program, we must first do the following: 1. Compile the source code and create a module. We can normally accomplish this by using the Linux GCC compiler directly from the command line. To simplify things, however, well create a Makefile. Then well only need to type make to compile our code. 2. Locate and copy the rtl.mk file. The rtl.mk file is an include file which contains all the ags needed to compile our code. For simplicity, well copy it from the RTLinux source tree and place it alongside of our hello.c file. 3. Insert the module into the running RTLinux kernel. The resulting object binary must be plugged in to the kernel, where it will be executed by RTLinux. We begin by creating the Makefile that will be used to compile our hello.c program. Type the following into a file called Makefile and put it in the same directory as your hello.c program: hello.o: hello.c gcc $(CFLAGS) hello.c Now, type the following: make -f rtl.mk hello.o This compiles the hello.c program and produces an object file named hello.o.

8/20/2013

Compiling and Executing hello .c(Contd.)

We now need to load the RTLinux modules. rtlinux start hello You can check the status of your modules by typing the command: rtlinux status hello For more information about the usage of the rtlinux command: rtlinux help You should now be able to see your hello.o program printing its message twice per second. To stop the program, we need to remove it from the kernel. To do so, type: rtlinux stop hello

8/20/2013

Soft And Hard Interrupts

There are two types of interrupts in RTLinux: Soft and Hard. Soft Interrupt: 1). Soft interrupts are normal Linux kernel interrupts. 2). They have the advantage that some Linux kernel functions can be called from them safely. 3). However, for many tasks they do not provide hard real time performance; they may be delayed for considerable periods of time. Hard Interrupt: 1). Hard interrupts (or real time interrupts), on the other hand, have much lower latency. 2). However, just as with real time threads, only a very limited set of kernel functions may be called from the hard interrupt handlers.

8/20/2013

Application of RTLinux
In

Education :

The Center for Experimental Research in Computer Systems (CERCS) at Georgia Institute of Technology uses RTLinux for real-time system instruction and research. The Software Engineering Graduate Program at Mercer University's School of Engineering uses RTLinux in teaching real-time embedded programming.

8/20/2013

Application of RTLinux (Contd.)

In Aviation and Aerospace :
Pratt and Whitney uses RTLinux to test jet engines for the Joint Strike Fighter project. Pratt and Whitney uses RTLinux to simulate and test weapon systems for the Comanche attack helicopter. The University of Alabama uses RTLinux on Unmanned Aerial Vehicles.

NASA's FlightLinux uses RTLinux for onboard spacecraft control and management.

8/20/2013

Application of RTLinux (Contd.)

In Science :
The CRL millimeter-wave radiometer uses RTLinux to monitor stratospheric ozone, aerosols and other trace gases in the atmosphere of the Canadian high arctic and Alaska. The Hungarian Automated Telescope, HAT, uses RTLinux to perform entirely automated surveys of the sky. The 12-Meter Radio Telescope and Heinrich Hertz 10 Meter Radio Telescope use RTLinux for critical data collection and antenna control tasks at the Kitt Peak Observatory.

RTLinux provides hard real-time decisions on optical profiles of microscopic objects in the Union Biometrica COPAS analyser and dispenser .
8/20/2013

Application of RTLinux (Contd.)

In Multimedia :
The Jim Henson Company uses RTLinux to control animatronic machines to bring life to the muppets, robots and animals in movies. Vladimir Pajkovski uses RTLinux to reserve bandwidth for audio and video media applications.

8/20/2013

Application of RTLinux (Contd.)

In Telecommunications :

B.M. Ledvina uses RTLinux to do most of the work of a GPS receiver, thus reducing parts count and cost of the whole unit. Cornell University uses RTLinux in Cascade, a software based GPS receiver. Yan Shoumeng uses RTLinux for remote monitoring and surveillance to avoid exposing humans to dangerous environments.

8/20/2013

Application of RTLinux (Contd.)

In Robotics :
The Tokyo University of Agriculture and the University of Karlsruhe use RTLinux to control a robotic hand for disabled people. RTLinux is used for the collision avoidance, trajectory planning and data interpretation applications. Fujitsu Automation Limited and Fujitsu Laboratories uses RTLinux to control their bipedal 48cm tall robot, HOAP. RTLinux is used along with COTS parts to build a demining robot to detect and dispose of landmines. The Humanoid Robot uses RTLinux to control a 3-foot tall bipedal robot. 8/20/2013

Application of RTLinux (Contd.)

In Control & Measurement :
Uses RTLinux to control a 60 MegaWatt Tokamak generator for high energy physics research. The Rotating Machinery and Controls Laboratory at the University of Virginia uses RTLinux to control magnetic bearings. RT-Lab is a GUI based system for control and data-acquisition that uses RTLinux for hard realtime control of experiments.

8/20/2013

Application of RTLinux (Contd.)

In Art :

RTLinux is used in musical research to simulate the behavior of a bow on a violin.

8/20/2013

Application of RTLinux (Contd.)

In Industry and Manufacturing :
Karl Rentsch uses RTLinux to do testing of networks in automobiles. The Enhanced Machine Controller project from the National Institute of Standards and Technology uses RTLinux to control machine tools, robots and coordinate measuring machines. The hexapod machine project from John Storrs uses RTLinux to control a milling machine to produce parts to specification.

8/20/2013

Application of RTLinux (Contd.)

In Medicine :

The Units of Intensive Care in the Hospitals of Peru use RTLinux to do centralized monitoring of patient lung ventilators.
RTLinux is used to control biological experiments at the Cornell University Cardiac Electrodynamics Lab.

8/20/2013

Application of RTLinux (Contd.)

In UnderWater :

Virginia Tech uses RTLinux to control autonomous underwater vehicles.

The University of Washington uses RTLinux in their humanpowered submarine.

8/20/2013

Conclusion

RT Linux has achieved hard real-time performance by making minimal changes to a freely available Operating System. Provides an alternative to proprietary real-time systems which may be prohibitively expensive. As Linux develops, RT Linux will also ride the wave of its development. Unlike other RT systems, no separate support for RT Linux is needed since support for Linux is already widely available.

8/20/2013

8/20/2013

8/20/2013