Requirements Scheduling in Real-Time Systems

Chapter 15 Special System Types

15.1 Real-Time Systems

15.1.1 Requirements

Real-time systems are different from general-purpose systems. The two most common types of real-time behavior are • Processes with deadlines, that is, processes that must complete their computa- tion by a given time. For example, if a sensor on an autonomous vehicle indicates that it is going to crash into a wall, this condition has to be handled before it ac- tually crashes. The deadline may be hard, as in the example above, or soft, in which case missing it is undesirable but not catastrophic. • Periodic processes, that need to do some computation repeatedly at given inter- vals. For example, a program that analyzes music and adds drums to it must sample its input at a given rate, so as not to miss a beat. A recent story about the importance of real-time scheduling comes from Mars: NASA’a little rover there shut itself down after missing important deadlines. The cause was determined to be an unimportant weather monitoring routine which didn’t complete fast enough. The metrics are different The most important metric in real-time systems is being on time. Therefore an im- portant metric for hard real-time scheduling is the percentage of processes that miss their deadlines. An additional metric for soft real-time systems is the average late- ness of processes. Metrics like response time are not important in this context. 246

15.1.2 Scheduling in Real-Time Systems

Schedulability analysis determines whether the tasks can indeed meet their deadlines By definition, a real-time system is required to make guarantees about the execution of processes. In order to be able to make such guarantees, the system must have precise information about the computational needs of the processes. This forms a contract between the user and the system: the user guarantees that once the process is started, it will complete within a certain time, and the system guarantees that it will be started in time. Once the information is available, it is possible to determine whether a new task can be scheduled in time, under the constraints posed by tasks already in the system. For example, consider a system that has to schedule a number of periodic tasks. Each task i computes for a duration c i in each period of t i . Obviously, one requirement is that c i ≤ t i if equal, it means that this task alone uses up all the system’s CPU time. When multiple tasks are present, an additional requirement is that X i c i t i ≤ 1 This is because c i t i is the fraction of time used by task i, and all the tasks together need to share a single CPU. Thus if a new task would cause this sum to exceed 1, the new task is rejected. A good algorithm is to schedule the most urgent task The most difficult type of real-time scheduling is trying to schedule dynamic aperi- odic tasks, meaning that tasks arrive at unpredictable times and need to be handled. Given a set of waiting real-time tasks, it then seems prudent to schedule the most urgent one first. This is known as “earliest deadline first” scheduling. However, this algorithm does not take into account the actual processing time re- quired. It may be that the task with the nearest deadline actually needs very little processing, and therefore can suffer some delay. An alternative algorithm is to sched- ule the task with the least laxity first, where laxity is the difference between the required processing and the time till the deadline. Rate monotonic scheduling is used for periodic tasks With periodic tasks, a popular algorithm is rate monotonic scheduling. With this algo- rithm, the priority of a task is proportional to the rate with which it is invoked that is, it is inversely proportional to its period. The tasks become available according to their periodicity, and whenever a task terminates, and waiting task with the shortest period is selected for execution. 247 Bibliography 248

15.2 Mobile Systems