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
