Contents

1. Introduction 2. Need for Rate Monotnic Scheduler and introduction to Embedded Systems 3. Characteristics of REAL TIME EMBEDDED SYSTEMS 4. Applications of REAL TIME EMBEDDED SYSTEMS 5. Real Time Operation 6. Need for REAL TIME OPERATING SYSTEMS 7. Features of REAL TIME OPERATING SYSTEMS 8. Architecture of REAL TIME OPERATING SYSTEMS 9. Tasks and Schedulers 10. Need for a Scheduler 11. Types of schedulers 12. Terminolgies 13. Rate Monotonic Scheduler 14. Schedulability Conditions 15. Utilization Bounds 16. Liu and Layland Condition 17. Liu and Lehockzy Completion time theorem 18. Implementation of RATE MONOTONIC SCHEDULER 19. Advantages of Rate Monotonic Scheduler 20. References

Introduction
Rate-monotonic scheduling is a scheduling algorithm used in real-time operating systems with a static-priority scheduling class. The static priorities are assigned on the basis of the cycle duration of the job: the shorter the cycle duration is, higher is the job's priority. These operating systems are generally preemptive and have deterministic guarantees with regard to response times. Rate monotonic analysis is used in conjunction with those systems to provide scheduling guarantees for a particular application. If you've got a lot of tasks to do, and tight dead-lines to meet, what's the best way to prioritize them? A technique called Rate Monotonic Scheduling guides the way. The scheduler or the scheduling algorithm you choose depends on your goals. Different algorithms yield different results. Let's suppose you're given ten jobs and each will take a day to finish. In ten days, you will have all of them done. But what if one or more has a deadline? If the ninth task given to you has a deadline in three days, then doing the tasks in the order you receive them will cause you to miss that deadline. The key question is what scheduling policy should be used to get the best performance from the system? A major issue in the design of real-time multitasking systems is that of timing correctness. Signal sampling, control calculations, output commands, etc. all must be done in a deterministic way to ensure systems meet their performance objectives. In recent years one technique Rate Monotonic Scheduling (RMS) - has frequently been promoted as a way of attaining these goals. The purpose of a rate monotonic scheduler is to ensure that critical timing constraints, such as deadlines and response time, are met. When necessary, decisions are made that favor the most critical timing constraints, even at the cost of violating others. Real-time scheduling is also used to allocate processor time between tasks in soft real-time embedded systems.

Need for Rate Monotnic Scheduler and Introduction to Embedded Systems

The rate monotonic schedulers are critically used in real time systems. Many real-time systems use preemptive multitasking, especially those with an underlying real-time operating system (RTOS). Hence a rate monotonic scheduler is one such preemptive multitasking scheduler with a primary goal of priority assignment and timing correctness, a deterministic way to ensure that the real time system meet their performance objective.

What is real time?

Real time is a quantitative notation of time.Whenever we quantify time using a physical clock, we deal with real time. An example use of this quantitative notation of time can be observed in a description of an automated chemical plant.consider this when the temperature of the chemical reaction chamber attains a certain predetermined temperature ,say 250o C ,the system automatically switches off the heater within a predetermined time interval ,say within 30milli seconds .In this description of a part of the behavior of a chemical plant ,the time value that was referred to denoted the reading of some physical clock present in the automation system. A system is called a real-time system, when we need quantitative expresssion of time i.e. in real time to describe the behavior of the system. Due to technological advancements embedded systems are the emerging trend that are now vastly outnumbering traditional computing.These are real time systems. Definition: A Real Time Embedded System (RTES) is precisely the union of subsystems to discharge a specific task coherently. Hence forth we call them as RTES. RTES as a generic term may mean a wide variety of systems in the real world. An embedded system is a computer system designed for specific control functions within a larger system, often with real-time computing constraints. It is embedded as part of a complete device often including hardware and mechanical parts. By contrast, a general-purpose computer, such as a personal computer (PC), is designed to be flexible and to meet a wide range of end-user needs. Embedded systems control many devices in common use today. In general, an Embedded System:

Is a system built to perform its duty, completely or partially independent of human intervention. Is specially designed to perform a few tasks in the most efficient way. Interacts with physical elements in our environment, viz. controlling and driving a motor, sensing temperature, etc.

Most embedded systems are time critical applications meaning that the embedded system is working in an environment where timing is very important: the results of an operation are only relevant if they take place in a specific time frame. An autopilot in an aircraft is a time critical embedded system. If the autopilot detects that the plane for some reason is going into a stall then it should take steps to correct this within milliseconds or there would be catastrophic results. Embedded systems contain processing cores that are typically either microcontrollers or digital signal processors (DSP). The key characteristic, however, is being dedicated to handle a particular task. Since the embedded system is dedicated to specific tasks, design engineers can optimize it to reduce the size and cost of the product and increase the reliability and performance. Some embedded systems are mass-produced, benefiting from economies of scale.

Physically, embedded systems range from portable devices such as digital watches and MP3 players, to large stationary installations like traffic lights, factory controllers, or the systems controlling nuclear power plants. Complexity varies from low, with a single microcontroller chip, to very high with multiple units, peripherals and networks mounted inside a large chassis or enclosure.

Why surge in embedded applications?

Embedded systems are small, fast, and very powerful tools, gadgets and equipments which have become part of our everyday life. Design and Efficiency
o

The central processing core in embedded systems is generally less complicated, making it easier to maintain. The limited function required of embedded systems allows them to be designed to most efficiently perform their functions.

Reduced Computing Cost

o

The streamlined make-up of most embedded systems allows their parts to be smaller less expensive to produce.

Maintenance
o

Embedded systems are easier to maintain because the supplied power is embedded in the system and does not require remote maintenance.

Redundancies
o

Embedded systems do not involve the redundant programming and maintenance involved in other system models.

Operates in harsh environment The design should take care of the operating conditions of the area where the system is going to implement. For example, if the system needs to be deployed in a high temperature zone, then all components of the system should be high temperature grade. Distributed The term distributed means that embedded systems may be part of a larger system. Many numbers of such distributed embedded systems form a single large embedded control unit. Each of them are independent units but work together to perform overall function.

Small Size and Weight Most of the embedded systems are designed for compactness and light weight for example Mobile devices, digital camera etc.This is a great advantage of embedded systems. Reduced Power Consumption Low power consumption compared to general purpose computing systems.

Characteristics of an RTES
Single-Functioned

The RTES is usually meant for very specific functions. These operations are monitored and controlled by an operating system called as Real Time Operating System (RTOS) which has much simpler complexity but more rigid constraints as compared to the conventional operating systems.
Tightly Constrained

The constraints on the design and marketability of RTES are more rigid than their non-real-time non-embedded counter parts.
Reactive and Real Time

Many embedded systems must continually react to changes in the systems environment and must compute certain results in real time without delay. In contrast a desktop computer system typically focuses on computations, with relatively infrequent reactions to input devices. In addition, a delay in those computations, while perhaps inconvenient to the computer user, typically does not result in a system failure. In contrast to thetraditional computation of the output as a simple function of the input data, realtime systems do not produce any output data but enter into an on-going interaction with their environment.In each interaction step, the results computed are used to carry out some actions on the environment.The reaction of the environment is sampled and is fed back to the system. Therefore the computations in a real-time system can be considered to be non-tetminating.This reactive nature of real-time systems is schematically shown in the Fig below

Stability Underoverload conditions, real-time systems need to continue to meet the deadlines of the most critical tasks, though the deadlines of non-critical tasks may not be met.This is in contrast to the requirement of fairness for traditional systems even under overload conditions.

Operation of Real Time Systems

Figure shows a simple model of a real-time system in terms of its important functional blocks. Unless otherwise mentioned, all our subsequent discussions would implicitly assume such a model .Observe that in Fig the sensors are interfaced with the input conditioning block, which in turn is connected to the input interface . The outpu interface, output conditioning, and the actuator are interfaced in a complementary manner.The following are the roles of the different functional blocks of the real time systems. Sensor: A sensor converts some physical characteristic of its environment into electrical signals .An example of a sensor is a photo-voltaic cell which converts light energy into electrical energy.

Actuator: An actuator is any device that takes its inputs from the output interface of a computer and converts these electrical signals into some physical actions on its environment The physical actions may be in the form of motion, change of thermal, electrical, pneumatic, or physical characteristics of some objects.For example a motor is a popular example of a actuator. Signal Conditioning Units: The electrical signals produced by a computer can rarely be used to directly drive an actuator.The computer signals usually need conditioning before they can be used by the actuator. This is termed output conditioning.Similarly input conditioning is required to be carried out on sensor signals before they can be accepted by the computer.For example, analog signals generated by a photo-voltaic cell are normally in the milli volts range and need to be conditioned before they can be processed by a computer The following are some important types of conditioning carried out on raw signals generated by sensors and digital signals generated by computers: Voltage amplification Voltage level shifting Frequency range shifting and filtering Signal mode conversion Interface Unit: Normally commands from the CPU are delivered to the actuator through an output interface. An output interface converts the stored voltage into analog form and then outputs this to the actuator circuitry.In an output interface, in order to produce an analog output, the CPU selects a data register of the output interface and writes the necessary data to it. The interface takes care of the buffering and the handshake control aspects .Analog to digital conversion is frequently deployed in an input interface. Similarly, digital to analog conversion is frequently used in an output interface

Real Time Operations

A Real Time Embedded System is always required to perform certain Real Time Operations. Definition: Real Time Operation An operation within a larger dynamic system is called a real-time operation if the combined reaction- and operation-time of a task operating on current events or input, is no longer than the maximum delay allowed, in view of circumstances outside the operation. The task must also occur before the system to be controlled becomes unstable.

A real time operation is generated in response to an event. Events in real time Systems An event may be generated either by the system or its environment. An event may either be instantaneous or may have certain duration. Based on these considerations, events can be classified as following Stimulus Events: Stimulus events are generated by the environment and act on the system. These events can be produced asynchronously. Response Events: Response events are usually produced by the system in response to some stimulus events. Response events can either be periodic or aperiodic.

Types of Real Time Operations

We have already seen that a real-time task is one for which quantitative expressions of time are needed to describe its behavior.This quantitative expression of time usually appears in the form of a constraint on the time at which the task produces results.The most frequently occurring timing constraint is a deadline constraint which is used to express that a task is required to compute its results within some deadline.
A real-time operation/task can be classified into hard, soft, or firm real-time task depending on the consequences of a task missing its deadline.

Hard Real-Time Operations: A hard real-time task is one that is constrained to produce its results within certain predefined time bounds .The system is considered to have failed whenever any of its hard real-time tasks does not produce its required results before the specified time bound. An example of a system having hard real-time tasks is a robot .The robot cyclically carries out a number of activities including communication with the host system, logging all completed activities, sensing the environment to detect any obstacles present, tracking the objects of interest, path planning, effecting next move, etc Now consider that the robot suddenly encounters an obstacle.The robot must detect it and as soon as possible try to escape colliding with it. If it fails to respond to it quickly (i.e. the concerned tasks are not completed before the requiredtime bound) then it would collide with the obstacle and the robot would be considered to have failed. Therefore detecting obstacles and reacting to it are hard real-time tasks. Applications having hard real-time tasks are typically safety-critical.This means that any failure of a real-time task, including its failure to meet the associated deadlines, would result in severe consequences.

Firm Real-Time Operations: Every firm real-time task is associated with some predefined deadline before which it is required to produce its results. However, unlike a hard real-time task, even when a firm real-time task does not com- plete within its deadline, the system does not fail. The late results are merely discarded In other words; the utility of the results computed by a firm real-time task becomes zero after the deadline. Firm real-time tasks typically abound in multimedia applications.The following is an examples of firm real-time tasks: Video conferencing: In a video conferencing application, video frames and the accompanying audio are converted into packets and transmitted to the receiver over a network. However, some frames may get delayed at different nodes during transit on a packet-switched network due to congestion at different nodes. This mayresult in varying queuing delays experienced by packets travelling along different routes. Even when packets traverse the same route, some packets can take much more time than the other packets due to the specific transmission strategy used at the nodes.When a certain frame is being played, if some preceding frame arrives at the receiver, then this frame is of no use and is discarded.Due to this reason, when a frame is delayed by more than say one second, it is simply discarded at the receiver-end without carrying out any processing on it. Soft Real-Time Tasks: Soft real-time tasks also have time bounds associated with them. However, unlike hard and firm real-time tasks, the timing constraints on soft real-time tasks are not expressed as absolute values Instead, the constraints are expressed either in terms of the average response times required. An example of a soft real-time task is web browsing.Normally, after an URL (Uniform Resource Locater) is clicked, the corresponding web page is fetched and displayed within a couple of seconds on the average. However, when it takes several minutes to display a requested page, we still do not consider the system to have failed, but merely express that the performance of the system has degraded. These real time operations are monitored and controlled by an operating system called as Real Time Operating System (RTOS) which has much simpler complexity but more rigid constraints as compared to the conventional operating systems.

REAL TIME OPERATING SYSTEMS

If you look at the software structure of embedded microsystems of early days, certain consistent patterns emerge. Routine low-level activities were performed by a continuous single-loop background task, all other activities being controlled by interrupts. These included functions executed at regular time intervals (synchronous or periodic tasks) and those done on demand (asynchronous or aperiodic tasks). Examples of periodic tasks include control loop calculations, data monitoring functions, display refreshing, etc. Aperiodic tasks are generally used to deal with events whose occurrences are unpredictable (from a time point of view that is), and, most important, require a fast response. Examples include handling push-button commands (e.g. bomb release), dealing with alarm functions (fuel tank flame detection, for instance) and protecting machinery systems (e.g. machinery running and safety guard lifted). In developing the software for these systems the designer was presented with two major objectives. First, the system had to satisfy its functional objectives, i.e. functional correctness. Second, it had to meet its timing requirements, that is, timing or temporal correctness. In older (and in particular smaller) embedded designs it wasnt especially difficult to achieve functional correctness (this doesnt imply that it was by any means easy, however). Timing aspects, similarly, didnt usually produce major problems - provided the CPU had adequate spare processing capacity (a most important proviso). The success of real-time embedded processor systems during the 70s and 80s speaks for itself. However, in recent years, the trend in embedded systems is that software has become larger, more complex and team-based. As a way of coping with this, developers have increasingly turned to the use of multitasking techniques in place of simple interrupt-driven structures. This, without a doubt, certainly simplified the task of implementing large, complex systems; it also made it easier to produce designs which are

functionally correct. Unfortunately, the same cannot be said for timing correctness; if anything the reverse is true. And that can raise serious problems for the designer of embedded systems, especially the hard/fast ones. A software designer faced with developing a new, technicallychallenging, system which has significant performance (time) demands. Hence, it has been decided to base this on the use of a real-time operating system. Real-Time Operating system (RTOS) is an operating system (OS) intended to serve real-time application requests.A Real-Time Operating System is a computing environment that reacts to input within a specific time period. A real-time deadline can be so small that system reaction appears instantaneous. Many embedded systems require software to respond to inputs and events within a defined short period of time. Such systems can be categorised as hard real-time, where missing a response deadline is unacceptable (for example an anti-lock braking system), and soft real-time, where hitting a deadline is desirable but not critical. In both types of system, a degree of determinism is important. RTOSes are designed to control an embedded system, and to deliver the real-time resposiveness and determinism required by the controlled device. Applications run under the control of the RTOS, and their allocated CPU time is scheduled by the RTOS kernel. A Real Time Operating System basically contains schedulers such as a rate monotonic scheduler which schedules these real time tasks based on the priorities in real time when stimulated by the external environment.

Features of REAL TIME OPERATING SYSTEMS

An operating system is considered real-time if it invariably enables its programs to perform tasks within specific time constraints, usually those expected by the user. To meet this definition, some or all of the following methods are employed: The RTOS performs few tasks, thus ensuring that the tasks will always be executed before the deadline. The RTOS drops or reduces certain functions when they cannot be executed within the time constraints ("load shedding"). The RTOS monitors input consistently and in a timely manner. The RTOS monitors resources and can interrupt background processes as needed to ensure real-time execution. The RTOS anticipates potential requests and frees enough of the system to allow timely reaction to the user's request.

The RTOS keeps track of how much of each resource (CPU time per timeslice, RAM, communications bandwidth, etc.) might possibly be used in the worst-case by the currentlyrunning tasks, and refuses to accept a new task unless it "fits" in the remaining un-allocated resources. In modern systems, a RTOS consists not only of a real-time kernel, but also higher-level functions such as device management (USB, UART, Ethernet, LCD etc), file systems, protocol stacks (CAN, TCP/IP, HTTP etc) , graphical user interfaces (GUI) , interfacing wide range of standard I/O devices and security and power management.

Figure. Basic features of a RTOS

Architecture of REAL TIME OPERATING SYSTEMS

The heart of a real-time OS (and the heart of every OS, for that matter) is the kernel. A kernel is the central core of an operating system, and it takes care of all the OS jobs: 1. Booting 2. Task Scheduling 3. Standard Function Libraries
An embedded system, frequently the kernel will boot the system, initialize the ports and the global data items. Then, it will start the scheduler and instantiate any hardware timers that need to be started. After all that, the Kernel basically gets dumped out of memory (except for the library functions, if any), and the scheduler will start running the child tasks. The core mechanism in a multitasking structure is the real-time kernel of the operating systems.

Kernel is that part of an operating system that provides the most basic services to application software running on a processor. Kernel services typically include:

Scheduling for application software tasks Communication and synchronization between tasks Dynamic allocation of RAM Timer services

Basic kernel services

Figure. Basis services provided by a real-time operating system kernel

The most basic category of kernel services is task management or scheduling. The main RTOS service in this category is the scheduling of tasks as the embedded system is in operation. The task scheduler controls the execution of application software tasks, and can make them run in a very timely and responsive fashion. The second category of kernel services is intertask communication and synchronization. These services make it possible for tasks to pass information from one to another, without danger of that information ever being damaged. They also make it possible for tasks to coordinate, so that they can productively cooperate with one another. RTOS kernels provide dynamic memory allocation services. This category of services allows tasks to borrow chunks of RAM memory for temporary use in application software. Often these chunks of memory are then passed from task to task, as a means of quickly communicating large amounts of data between tasks. Many (but not all) RTOS kernels also provide a device I/O supervisor category of services. These services, if available, provide a uniform framework for organizing and accessing the many hardware device drivers that are typical of an embedded system. In addition to kernel services, many RTOSs offer a number of optional add-on operating system components for high-level services such as file system organization, network communication, network management, database management, and user-interface graphics.

Tasks and Schedulers

Task Instance: Each time an event occurs, it triggers the task that handles this event to run. In other words, a task is generated when some specific event occurs. Real time tasks therefore normally recur a large number of times at different instants of time depending on the event occurance times. It is possible that real time tasks recur at random instants. However, real time tasks recur with fixed periods. For example, a temperature sensing task in a chemical plant might recur indefinitely with a certain period because the temperature is sampled periodically, where as a task handling a device interrupt might recur at random instants. Each time a task recurs, it is called an instance of the task. The first time a task occurs, it is called the first instance of the task.The next occurance of the task is called its second instance, and so on. The jth instance of a task Ti would be denoted as Ti( j ). Each instance of the real time task is associated with a deadline by which it needs to complete and produce results. Absolute & Relative Deadlines of a Task: The absolute deadline of a task is the absolute time value (counted from time 0) by which the results from the task are expected. Thus absolute deadline is equal to the interval of the time between the time 0 and the actual instant at which the deadline occurs.Whereas, relative deadline is the time interval between the start of the task and the instant at which the deadline occurs Response time: The response time is the time duration from the occurance of the event generating the task to the time the task produces its result.

Types of Real-Time Tasks and Their Characteristics

Based on the way real-time tasks recur over a period of time, it is possible to classify them into three main categories: periodic, sporadic, and aperiodic tasks. Periodic Tasks: A periodic task is one that repeats after a certain fixed time interval. The precise time instants at which periodic tasks recur are usually demarcated by clock interrupts. For this reason, periodic tasks are sometimes referred to as clock-driven tasks. The fixed time interval after which a task repeats is called the period of the task. If Ti is a periodic task, then the time from 0 till the occurrence of the first instance of Ti (i.e. Ti( l )) is denoted by i; and is called the phase of the task .The second instance (i.e. Ti( 2 )) occurs at i +pi . The third instance (i.e. Ti( 3 )) occurs at i + 2 *pi and so on. Formally, a periodic task can be represented by a 4 tuple (i, pi, ei, di) where pi is the period of task, ei is the worst case execution time of the task, and di is the relative deadline of the task.

To illustrate the above notation to represent real-time periodic tasks, let us consider the track correction task typically found in a rocket control software .Assume the following characteristics of the track correction task.The track correction task starts 2000 rnilli seconds after the launch of the rocket, and it periodically recurs every 50 milli seconds, then on. Each instance of the task requires a processing time of 8 rnilli seconds and its relative deadline is 50 milli seconds. Since the phase of a task is defined by the occurrence time of the first instance of the task.Therefore, the phase of this task is 2000 milli seconds. This task can formally be represented as (2000 mSec, 50 rnSec,8 mSec, 50 mSec).This task is pictorially shown in figure.

Sporadic Task: A sporadic task is one that recurs at random instants. A sporadic task Ti can be is represented by a three tuple:

Ti = (ei, gi, di)

Where ei is the worst case execution time of an instance of the task, gi denotes the minimum separation between two consecutive instances of the task, di is the relative deadline. The minimum separation (gi) between two consecutive instances of the task implies that once an instance of a sporadic task occurs, the next instance cannot occur before gi time units have elapsed.That is, gi restricts the rate at which sporadic tasks can arise. Aperiodic Task. An aperiodic task is in many ways similar to a sporadic task.An aperiodic task can arise at random instants.However, in case of an aperiodic task, the minimum separation gi between two consecutive instances can be 0. That is, two or more instances of an aperiodic task might occur at the same time instant. Also, the deadline for aperiodic tasks is expressed as either an average value or is expressed statistically.

Real Time Schedulers

A real time scheduler is a operating system module that controls, schedules and manages real time tasks according to priorities assigned by the scheduling algorithm. The need for a scheduler arises from the requirement for most modern systems to perform multitasking and multiplexing. Real time task schedulers determine the order in which various tasks are to be taken up for execution by the operating system. Every operating system relies on one or more task schedulers to prepare the schedule of execution of various tasks it needs to run. Each task scheduler is charecterized by the scheduling algorithm it employs. A scheduler is concerned mainly with: Throughput- number of processes that complete their execution per time unit. Latency, specifically: Turnaround - total time between submission of a process and its completion. Response time - amount of time it takes from when a request was submitted until the first response is produced Fairness / Waiting Time - Equal CPU time to each process

Figure: Schematics of a Scheduler

Figure above shows a schematic of a scheduler. All requests waiting to be serviced are kept in a list of pending requests. An arriving request is added to this list. Whenever scheduling is performed, the scheduler examines the pending request and selects one for servicing. This request is handed over to the server. A request leaves the server when it completes or when it is preempted by the scheduler, in this case it is put back into the list of the pending requests. In either situation the scheduler performs scheduling to select the next request to be serviced. Thus four events related to scheduler are arrival, scheduling, preemption and completion. Most RTOSs do their scheduling of tasks using a scheme called priority-based pre-emptive scheduling. Each task in a software application must be assigned a priority, with higher priority values representing the need for quicker responsiveness. Very quick responsiveness is made possible by the preemptive nature of the task scheduling. Preemptive means that the scheduler is allowed to stop any task at any point in its execution, if it determines that another task needs to run immediately. The basic rule that governs priority-based preemptive scheduling is that at every moment in time, the highest priority task that is ready to run will be the task that must be running. In other words, if both a low-priority task and a high-priority task are ready to run, the scheduler will allow the high-priority task to run first. The low-priority task will only get to run after the high-priority task has finished with its current work. What if a low-priority task has already begun to run, and then a higher-priority task becomes ready? This might occur because of an external world trigger such as a switch closing. A priority-based preemptive scheduler will behave as follows: it will immediately stop the execution of the low-priority task, and allow the higher-priority task to run. After the higher-

priority task has finished its current work, the low-priority task will be allowed to continue running.

Figure. Timeline for priority-based preemptive scheduling

Of course, while the higher-priority task is running, an even higher-priority task might become ready. In that case, the running task would be preempted (stopped temporarily) to allow the even-higher-priority task to run. When this task has finished its current work, the preempted task would be allowed to continue. And thus in this case, both higher-priority tasks would complete their work before a low-priority task would be allowed to continue running. This scenario might be called nested preemption. Each time the priority-based preemptive scheduler is alerted by an external world trigger or a software trigger (such as a message arrival), it must go through the following 5 steps: Determine whether the currently running task should continue to run. If not Determine which task should run next. Save the environment of the task that was stopped (so it can continue later). Set up the running environment of the task that will run next. Allow this task to run. These 5 steps together are called task switching.

Types of Real-Time Schedulers

A hard real-time system must execute a set of concurrent real-time tasks in such a way that all time-critical tasks meet their specified deadlines. Every task needs computational and data resources to complete the job. The scheduling problem is concerned with the allocation of the resources to satisfy the timing constraints. Figure given below represents a taxonomy of realtime scheduling algorithms.

Real-Time scheduling can be categorized into hard vs soft. Hard real-time scheduling can be used for soft real-time scheduling. Hard real-time scheduling can be broadly classifies into two types: static and dynamic. In static scheduling, the scheduling decisions are made at compile time. A run-time schedule is generated off-line based on the prior knowledge of task-set parameters, e.g., maximum execution times, precedence constraints, mutual exclusion constraints, and deadlines. So run-time overhead is small. On the otherhand, dynamic scheduling makes its scheduling decisions at run time, selecting one out of the current set of ready tasks. Dynamic schedulers are flexible and adaptive. But they can incur significant overheads because of run-time processing. Preemptive or nonpreemptive scheduling of tasks is possible with static and dynamic scheduling. In preemptive scheduling, the currently executing task will be preempted upon arrival of a higher priority task. In nonpreemptive scheduling, the currently executing task will not be preempted until completion. Static Scheduling Schedulers In static scheduling, scheduling decisions are made during compile time. This assumes parameters of all the tasks is known a priori and builds a schedule based on this. Once a schedule is made, it cannot be modified online. Static scheduling is generally not recommended for dynamic real time systems. Applications like process control can benefit from this scheduling, where sensor data rates of all tasks are known before hand. There are no explicit static scheduling techniques except that a schedule is made to meet the deadline of the given application under known system configuration. Most often there is no notion of priority in static scheduling. Based on task arriaval pattern a time line is built and embedded into the program and no change in schedules are possible during execution. Dynamic Scheduling Schedulers Schedulability tests are often used by dynamic schedulers to determine whether a given set of ready tasks can be scheduled to meet their deadlines. Different schedulers and their schedulability criteria is explained below. Rate Monotonic Scheduler (RMS) Rate monotonic is a dynamic preemptive scheduler based on static priorities. The rate monotonic algorithm assigns static priorities based on task periods. Here task period is the time after which the tasks repeat and inverse of period is task arrival rate.

Ealriest Deadline-First (EDF) Scheduler: EDF algorithm is an optimal dynamic preemptive algorithm based on dynamic priorities. In this after any significant event, the task with the earliest deadline is assigned the highest dynamic priority. A significant event in a system can be blocking of a task, invocation of a task, completion of a task etc. The processor utilization can up to 100% with EDF, even when the task periods are not multiples of the smallest period. The dispatcher operates in the same way as the dispatcher for the rate monotonic algorithm. The Priority Ceiling Protocol: The priority ceiling protocol is used to schedule a set dependant periodic tasks that share resources protected by semaphores. The shared resources, e.g., common data structures are used for interprocess communication. The sharing of resources can lead to unbounded priority inversion. The priority ceiling protocols were developed to minimize the priority inversion and blocking time.

Terminolgies
Valid Schedule: A valid schedule for a set of tasks is one where at most one task is assigned to a processor at a time, no task is scheduled before its arrival time, and the precedence and resource constraints of all tasks are satisfied. Feasible Schedule: A valid schedule is called a feasible schedule, only if all tasks meet their respective time constraints in the schedule. Optimal scheduler: A real time scheduler is called an optimal scheduler, if it can feasibly schedule any task that can be feasibly scheduled by any other scheduler. If an optimal scheduler can not schedule some task set, then no other scheduler should be able to produce a feasible schedule for that task set.

Scheduling Points: The scheduling points of a scheduler are the points on the time line at which the scheduler makes decisions regarding which task is to be run next. Based on this schedulers can be classified as Clock driven: In Clock Driven Schedulers, the scheduking points are defined by interrupts from a periodic timer. Event driven: In Event Driven Schedulers, the scheduking pointsdefined by task completion and event generation/arrival.

Preemptive Scheduler: A preemptive scheduler is one in which, when a higher priority task arrives, it suspends any lower priority task that may be executing and takes up the arrived higher priority task for execution.A preempted task can resume its execution only when no higher priority task is ready. Utilization: The Processor Utilization or just Utilization of a task is the average time for which it executes per unit time interval. For a periodic task Ti ,the utilization Ui is the ratio of execution time ei to the period of tasks pi.

For a set of n periodic tasks { Ti}, the total utilization due to all tasks is given as

It is the objective of any good scheduler to feasibly schedule even those tasks sets that have high utilization i.e. utilization approaching 1. On a uniprocessor it is not possible to schedule task sets having utilization more than 1.

Rate Monotonic Scheduler

Definition: Rate Monotonic Scheduler

A Rate monotonic scheduler is a event driven scheduler for real time operating systems. It is a scheduling algorithm with a static-priority scheduling class. The static priorities are

assigned on the basis of the cycle duration of the job, the shorter the cycle duration is, the higher is the job's priority. Rate Monotonic Scheduler is a simple, practical mathematically sound way to guarantee schedulability in real-time systems. RMS can guarantee if a system is schedulable with a given set of requirements. Thus this result means that the tasks will always meet their deadlines (a deterministic scheduler), regardless of how and when the system schedules the task. Its an optimal uniprocessor static priority scheduler. The Rate monotonic Scheduler is based on the use of a priority pre-emptive task scheduling policy. Task priorities (P) are set according to task periods (Tp), as follows: P = 1 / Tp Thus the task with the shortest period has highest priority, followed by the task having the second shortest period; following this is the one with the third shortest period, and so on to the end one. Hence the priority of the task increases monotonically with respect to its rate or frequency.hence the name rate monotonic scheduler.

Figure: Priority assignment by Rate Monotonic Scheduler

Schedulability Conditions for Rate Monotonic Schedulers

The Schedulability conditions or tests are the conditions which determine if a set of tasks can be effectively scheduled by the scheduler without missing any of the deadlines of the tasks set.

Necessary and sufficient schedulability test

The following criteria are assumed to determine the basic schedulability conditions of rate monotonic scheduler. i. Task switching is instantaneous. ii. Tasks account for all processor execution time. iii. Task interactions are not allowed. iv. Tasks with shorter periods are assigned higher priorities; no other criteria are considered for priority assignment. v. Task execution is always consistent with rate monotonic priority: a lower priority task never executes when a higher priority task is ready. The schedulability of a rate monotonic scheduler is defined by its utilization bounds which is a function of the number of tasks in the periodic task set.

Utilization Bound
The utilization bound is the maximum utilization of the processor that can be achived for a set of tasks that can be fesabily scheduled by the scheduler. Necessary Condition (First Utilization Bound): A set of periodic real-time tasks would not be Rate Monotonic Scheduler schedulable unless they satisfy the following necessary condition:

where ei is the worst case execution time and Pi is the period of the task Ti, n is the number of tasks to be scheduled, and Ui is the CPU utilization due to the task Ti.This test simply expresses the fact that the total CPU utilization due to all the tasks in the task set should be less than 1. But this condition is not sufficient to describe the schedulability of scheduler to schedule a set of tasks. The sufficient condition to determine the schedulability of the rate monotonic scheduler is given by the Liu & Layland condition .

Liu and Layland Condition