RealTime Systems Introduction Johnnie W Baker What is

Real-Time Systems Introduction Johnnie W. Baker

What is a Real-Time System • Correctness of the system depends not only on the logical results, but also on the time in which the results are produced. • Works in a reactive and time-constrained environment • Examples § Real-time temperature control of a chemical reactor § Space mission control system § Nuclear power generator system § Many safety-critical systems 2

Parts of Typical Real-Time System • Controlling System Ø Computer system acquires information about the environment through sensors Ø Performs computations on data Ø Activates the actuators through some controls • Controlled System • Operating Environment 3

Example – Car Driver • Mission Ø Reach destination safely • Controlled System Ø Car • Operating Environment Ø Road Conditions and other cars • Controlling System Sensors Ø Human driver: eyes and ears Ø Computer: Camera, Infrared receiver, Laser telemeter • Controls Ø Accelerator, Steering wheel, Break Pedal • Actuators Ø Wheels, Engine, Brakes 4

Example – Car Driver (Cont. ) • Critical Tasks Ø Steering and Braking • Non-critical Tasks Ø Turning on the radio • Performance Ø A measure of the goodness of outcome, relative to the best outcome possible under the given circumstances • Reliability (of driver) Ø Fault-tolerance is a must 5

Typical Real-Time System Parts 6

Tasks and Jobs • Jobs are units of work that are scheduled and executed by the systems. • The set of related jobs that can be solved by the same algorithm are called a task. Ø A job is an instance of a task. Ø Use of “instance” is same as in complexity theory • Not all books distinguish between tasks & job. • In some situations, it is awkward to maintain a distinguish between these two concepts. Ø However, it is important in some situations to understand the differences between these two concepts. 7

Type of Deadlines • A deadline d is a time at which a task/job must be complete. • A hard deadline means that it is vital for the safety that this deadline always be met. • A soft deadline means that it is desirable to finish executing the task/job by the deadline, but that no catastrophe occurs if completion is late Ø Some soft tasks only require that the task be completed as soon as possible. • A firm deadline means there is no value in completing the task after its deadline. 8

Typical Pictorial Interpretation 9

Periodic Tasks are activated regularly at fixed rates. • These tasks are time-driven • Example: Monitoring temperature of a patient • The length of time between to successive activations is called the period. • In many practical cases, a periodic task can be characterized by its computation time C and its deadline D. Ø Often the deadline is set equal to the period. • Consists of a sequence of identical “jobs” or “instances” of the task. 10

Aperiodic Tasks • Aperiod tasks are tasks which are activated irregularly at some unknown and possibly unbounded rate. Ø Event driven Ø Example – Activated when condition of patient changes. • Sporatic tasks are tasks that are activated with some known and bounded rate. Ø Necessary to bound the workload generated by such tasks. 11

Some Task/Job Parameters • Arrival Time (or Release time): The time r at which a job becomes ready for execution • Computation Time: The time C necessary for the processor to execute the task without interruptions. • Absolute Deadline : The time d before which a task should be completed to avoid damage (if hard) or system degradation (if soft). • Start Time: The time s at which a job starts its execution • Finish Time: The time f at which a job finishes its execution. • Response Time: The time R between the finish time and the request time (i. e. , R = f – r ) 12

Some Task/Job Parameters (cont. ) • Criticalness: A parameter related to the consequence of missing the deadline Ø Usually hard, soft, firm • Lateness: A parameter L giving the delay of the task completion with regard to its deadline. (L = f – d) • Laxity (or Slack time): The maximum time X that a task can be delayed on its activation and still complete within its deadline. (X = d – r – C) 13

Computing Systems Considered • Uniprocessor • Multiprocessor Systems Ø Called MIMD Computers in Parallel Architecture § Multiprocessors (shared memory systems) – UMA or SMP (Symmetric Multiprocessors) – NUMA § Multicomputers (Message Passing Systems) Ø Traditional in Real-Time Systems & Complexity theory to refer to MIMD systems as multiprocessors • Distributed Systems 14

UMA or SMP 15

UMA or SMP • • Straightforward extension of uniprocessor Add CPUs to bus All processors share same primary memory Memory access time same for all CPUs Ø Uniform memory access (UMA) multiprocessor • Processors communicate using shared memory • Also called a symmetrical multiprocessor (SMP) 16

Problems Associated with Shared Data with SMP/UMA The cache coherence problem • Replicating data across multiple caches reduces contention among processors for shared data values. • But how can we ensure different processors have the same value for same address? • The cache coherence problem occurs when an obsolete value is still stored in a processor’s cache. 17

Distributed Multiprocessor or NUMA • Distributes primary memory among processors • Increase aggregate memory bandwidth and lower average memory access time • Allows greater number of processors • Also called non-uniform memory access (NUMA) multiprocessor Ø Local memory access time is fast Ø Non-local memory access time can vary Ø Distributed memories have one logical address space 18

Distributed Multiprocessors or NUMA 19

Multicomputers • Distributed memory multiple-CPU computer • Same address on different processors refers to different physical memory locations • Processors interact through message passing 20

Typically, Two Flavors of Multicomputers • Commercial multicomputers Ø Custom switch network Ø Low latency (the time it takes to get a response from something). Ø High bandwidth (data path width) across processors • Commodity clusters Ø Mass produced computers, switches and other equipment Ø Use low cost components Ø Message latency is higher Ø Communications bandwidth is lower 21

Multicomputer Communication • Processors are connected by an interconnection network • Each processor has a local memory and can only access its own local memory • Data is passed between processors using messages, as dictated by the program • Data movement across the network is also asynchronous Ø A common approach is to use MPI to handling message passing 22

Multicomputer Communications (cont) • Multicomputers can be scaled to larger sizes much easier than multiprocessors. • The data transmissions between processors have a huge impact on the performance Ø The distribution of the data among the processors is a very important factor in the performance efficiency. 23

Message-Passing Disadvantages • Programmers must make explicit messagepassing calls in the code • This is low-level programming and is error prone. • Data is not shared but copied, which increases the total data size. • Data Integrity Ø Difficulty in maintaining correctness of multiple copies of data item. 24

Message-Passing Advantages • No problem with simultaneous access to data. • Allows different PCs to operate on the same data independently. • Allows PCs on a network to be easily upgraded when faster processors become available. 25

Real-Time System Size & Coordination • Currently, in most real-time systems, either Ø The entire system code is loaded into memory or Ø Else there are well-defined phases and each phase is loaded just prior to its execution. • These options may not be practical for the larger systems that will arise in the next generation • In many applications, subsystems are highly independent of each other & little coordination is needed. Ø Simplifies many aspects of building & analyzing system • Increasing system size and/or task coordination give rise to many problems and complicate providing predictability 26

Environments • The environment in which a real-time system operates plays a large role in the design of the system • Many environments are well-defined and “deterministic”. Ø Give rise to small static real-time systems Ø Characteristics of all tasks known in advance Ø All deadlines can be guaranteed to be met. • Other environments may be complicated, and less controllable. Ø Many future applications expected to be more complex, distributed, non-deterministic, & dynamic. • Systems to handle these complex environments are expected to require dynamic real-time systems • Observe: It does not follow from above that either Ø static real-time systems have to be small and uncomplicated Ø Complex systems have to be dynamic 27

Predictability • One of the most important properties that a hard real-time system should have. • The system should be able to predict the evolution of tasks and guarantee in advance that all critical timing constraints will be met. • The reliability of this guarantee depends on a number of factors which involve Ø The architectural features of the computer hardware Ø For uniprocessors, the policies adopted in the kernel Ø Programming language used to implement the application. 28

Predictability & Types of Systems • In a static system where characteristics of tasks are known in advance, guarantees can be given at design time that all their timing constraints will be met. • For dynamic systems, characteristics of all tasks are not known in advance. • Generally accepted for dynamic systems that Ø Essentially no guarantees can be given at design time Ø Guarantees can only be given at run time using an online schedulability analysis approach. 29

Predictability Redefined • The online schedulability analysis approach to provide guarantees: Ø Determines whether a given task can be completed by its deadline without jeopardizing other tasks. Ø If constraints can not be met, task is rejected and system may invoke some type of recovery action. • Predictability for dynamic real-time systems is reinterpreted to mean that Ø Once a task (or job? ) is admitted into a system, its deadline guarantee is never violated as long as the assumptions under which it was admitted hold. Ø See Reference 6 in Murthy & Manimaran on page 18 30

Determining Task Performance • Difficult to obtain specific information on task characteristics for dynamic real-time systems • For schedulability analysis, worst-case analysis is assumed Ø Possibly derived by extensive simulation, testing, etc. Ø Values used may not be true worst-case values Ø Actual values may exceed these “worst-case” values on rare occasions. § Called a specification violation § Real-time systems are supposed to monitor such events and take recovery action when they occur. Ø See Reference [2] pg 18 in text for more information. 31

Common Misconceptions about RTS • Real-time computing is equivalent to fast computing. Ø Belief is that a sufficiently fast computer will solve problem Ø Predictability, not speed, is the foremost goal in realtime systems design. Ø Fast computing does not, in general, support predictability Ø Predictability depends on factors like architecture, implementation language, and environment 32

Common Misconceptions about RTS (cont) • Real-time computing is assembly coding, priority interrupt programming, and writing device drivers Ø To meet stringent timing requirements, current practices rely heavily on these techniques. Ø Are labor intensive, difficult to trace, and a major source of bugs. Ø A primary objective in RTS is to automate the production of highly efficient code 33

Common Misconceptions about RTS (cont) • Real-time systems operate in a static environment. Ø A real-time system will have to satisfy different timing constraints at different times. § E. g. , in ATC the takeoff, high altitude flight, landing Ø The environment is usually nondeterministic, resulting in aperiodic tasks § Claims these demands require a dynamic system 34

Common Misconceptions about RTS (cont) • The problems in real-time systems have all been solved in other areas of computer science. Ø RTS present unique problems that have not been addressed in other areas § Deadline requirements, tasks are periodic or aperiodic, task have synchronization or resource constraints, etc. Ø Assumptions in other areas may make results useless § These areas include operation research, databases, & software engineering § Real Time Databases has different set of problems than traditional databases. 35

Overview of Issues in RTS • Resource Management Ø Scheduling, resource reclaiming, fault-tolerance, communications Ø This is focus of text • Architecture issues Ø Processor architecture, network architecture, I/O architecture • Software Ø Specification and verification of real time systems Ø Programming Languages Ø Databases 36

Task Scheduling Overview • Involves allocation of processors, resources, and time in way that performance requirements are met. • Scheduling algorithms must satisfy timing, resource, and precedence constraints • Must provide predictable intertask communication 37

Preemptive vs Non-preemptive Scheduling • Non-preemptive scheduling, Ø once a task starts execution, it executes to completion Ø Has less ability to produce a schedule Ø Has less overhead because of less context switching • Preemptive scheduling Ø Task can be preempted and resumed later Ø Allows arriving tasks with higher priority to move ahead of lower priority tasks already executing Ø Greater overhead due to context switching. Ø Provides greater ability to produce a schedule § Preempted tasks frequently redo earlier computation Ø Task may not resume computing on same processor 38

Task-Scheduling Paradigms • Static table-driven approaches Ø Perform static schedulability analysis Ø Resulting schedule is usually stored in a table and controls when a task will start executing. • Static priority-driven preemptive approaches Ø Perform schedulabilty analysis but does not create table Ø Tasks executed in a highest-priority-first basis 39

Task-Scheduling Paradigms (cont) • Dynamic planning-based approach Ø Schedulability of task is checked at run time § Arriving tasks is accepted for execution if it is found to be schedulable. Ø Once scheduled, a task is guaranteed to meet performance requirements. • Dynamic best-effort approaches Ø No schedulability check is done Ø Systems does its best to meet requirements of task Ø Task may be aborted during execution 40

Performance Metrics • RT Systems Metric Ø Schedulabilty: Ability to schedule tasks to meet their deadlines. • Non-RT System Metrics Ø Throughput, response time, minimizing schedule length. 41

Resource Reclaiming • Problem of reclaiming unused time processor and resource time due to Ø Task executing in less time than worst-case Ø Task being deleted from current schedule 42

Fault Tolerance • RT systems must be able to deliver the expected performance, even in presence of faults. • Fault tolerant is an inherent requirement of any real-time system. • Basic principle of fault tolerance is redundancy. Ø Costs both time and money Ø System design must trade off amount of faulttolerance required with level of fault tolerance 43

Real Time Communication • Any type of communication in which the messages involved have timing constraints. • Two categories Ø Periodic messages are generated in communicating periodic tasks. § If periodic task encounters a delay longer than its period, it is considered lost. § Often used for sending sensor data Ø Aperiodic messages are generated in communicating aperiodic tasks § Arrival pattern is stochastic in nature § Has end-to-end deadline and is considered lost if it fails to reach destination before this deadline. 44

Architecture Issues • Needs predictability in Ø Ø • • instruction execution time memory Memory access Context switching Interrupt handling Avoids caches, virtual memory, superscalar features. Fast & predictable I/O systems required Support for fast and reliable communications Support for error handling Support for scheduling algorithms Support for real-time operating system Support for a RT language features. 45

Software Engineering Issues: Requirements, Specification, Verification • Functional requirements: Operation of the system and their effects Ø Address logical correctness • Non-functional requirements: Timings, constraints • F & NF requirements need to be precisely defined and used together to construct the specification of the system • A specification is an abstract mathematical statement of properties to be exhibited by system. Ø It is checked for conformity with the requirements Ø Its properties can be examined independent of the way it is implemented Ø Should not enforce any decisions about the structure of software, the programming language to be used, or system architecture 46

Software Engineering (cont. ) • Usual process for specifying computing system behavior involves Ø Enumerating events or actions that the system participates in Ø And describing the order in which they can occur. • Not well understood how to extend such approaches for real-time constraints 47

Real-Time Languages • Some desirable features a real-time language should support are Ø Language constructs for expressing timing constraints and keeping track of resource utilization. Ø Support for schedulability analysis, with the goal of being able to perform schedulability checks at compile time. Ø Support for reusable real-time software modules using object-oriented methodology. Ø Support for predicting the timing behavior of real-time programs in distributed systems • A few formal languages that support timing constraints have been developed. Ø Used to specify & verify small scale systems Ø Do not adequately address fundamental RT problems 48

Real-Time Databases • Most conventional database systems are disk-based • They use transaction logging and two-phase locking protocols to ensure transaction atomicity and serializability • While these preserve data integrity, they result in relatively slow and unpredictable response times. • Important real-time database systems issues include Ø Transaction scheduling to meet deadlines Ø Explicit semantics for specifying timing and other constraints Ø Checking the database system’s ability of meeting transaction deadlines during initialization of application 49

Additional Basic Concepts from Stankovic & Buttazzo From Chapter 2 of each Book

Goals of Additional Slides • In the previous slides, we covered the concepts in Chapter 1 of text by Murthy and Manimaran. • Before moving on to scheduling, we add in some additional preliminary material covered in Ch. 2 of book by Stankovic et. al. or in Ch. 2 of book by Buttazzo. • Some of this was mentioned earlier, but not covered completely. • Since it is available at our website, Chapter 2 in Stankovic is added to our list of reading & study assignments. 51

Deadlines and Release Times Ref: Stankovic, page 16 -17 • The deadline time for one instance of a periodic task is usually the release time of its next instance. Ø ri, j = (j-1)Ti Ø Here, r is the release time, i denotes the i-th task, j indicates the j-th instance of a task, and T denotes the period (or interarrival time of a task) • Equivalently, the release time for one instance of a periodic task is usually the deadline time for the preceding instance of this task. Ø Note di, j = ri, j + Ti = j. Ti 52

Deadlines and Release Times • For sporadic tasks, we assume that the release time of two consecutive instances must be separated at least by their minimal interarrival time. Ø Symbolically, ri, j ≥ ri, j-1 + Ti • The deadline of a sporadic task is often assumed to be equal to the earliest possible release time of the next instance. Ø Symbolically, di, j = ri, j + Ti • Review the chart & discussion on pg 17. 53

Initial Assumptions for Scheduling Liu & Layland (Ref 9 in Ch 2 of Stankovic) • A 1: All hard tasks are periodic • A 2: Jobs are ready to run at their release time • A 3: Deadlines are equal to periods • A 4: Jobs do not suspend themselves • A 5: Jobs are independent in that Ø No synchronization is required between them Ø Jobs do not have shared resources, other than the CPU. Ø There is no relative dependencies or constraints on release times or completion times. • A 6: There is no overhead costs for preemption, scheduling, or interrupt handling. • A 7: Processing is fully preemptable at any point. 54

Assumptions for Scheduling (Cont) • The preceding assumptions are initially made in Ch. 3 of Stankovic • However, these are not practical for most actual systems. • See pg 18 -19 of Stankovic for possible relaxations of some of these initial assumptions. 55

Static, Dynamic, & Offline Scheduling Ref: Stankovic, pg 19 -22. • Static Scheduling refers to the fact that the scheduling algorithm has complete knowledge about the task set and its constraints such as deadlines, computation times, etc. • Static scheduling is viewed as realistic for many real-time systems, such as simple process control applications. • Dynamic Scheduling Algorithms (in this book) has complete knowledge of the currently active tasks, but new arrivals may occur in the future that are not known to the algorithm at the time the current set of activities are being scheduled. 56

Static, Dynamic, & Offline Scheduling (cont) • Off-line scheduling: is done prior to the design of the scheduler. Ø In particular, off-line scheduling is not the same as static scheduling. Ø In static real-time scheduling, an off-line schedule is found that meets all deadlines. § The designer must identify a maximum set of tasks and their worst case assumptions Ø The off-line analysis is sometimes used to produce a static set of priorities that is used to drive the schedule that is produced. • If a real-time system is operating in a more dynamic environment , then it is not feasible to meet assumptions of static scheduling (where everything is not known a priori) 57

Schedulability Ref: Buttezzo pg 22 -23, Stankovic, pg 23 -24, • Uniprocessor: Given a set of tasks, a schedule is an assignment of tasks to the processor so that each is executed to completion. • Multiprocessor: Given sets of tasks, processors, and resources, a schedule is an assignment of processors and resources to tasks so that all tasks are completed. • A schedule is said to be feasible if all tasks can be completed according to a set of specified constraints. Ø Stankovic suggests that tasks might be restricted to hard tasks. • A set of jobs is schedulable if all there exists at least one algorithm that can produce a feasible schedule. 58

Optimality of Algorithms Ref: Stankovic, pg 23 -24 • An optimal real-time scheduling algorithm is one which may fail to meet a deadline only if no other scheduling algorithm can meet this deadline. Ø This definition of “optimal” is the typical one used in real-time scheduling. • The usual non-real-time definition of optimal says an algorithm is optimal if it minimizes (maximizes) some cost function. Ø Running time for uniprocessors and cost = (running time nr processors) for parallel. • Another metric sometime used is to maximize the number of task arrivals that meet their deadline. 59