Real-Time Systems Introduction

1. Real-Time Systems Introduction Johnnie W. Baker

2. 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

3. 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

4. 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

5. 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

6. Typical Real-Time System Parts

7. 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.

8. 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.

9. Typical Pictorial Interpretation

10. Periodic Tasks 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.

11. 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.

12. 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 )

13. 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)

14. 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

15. UMA or SMP

16. 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)

17. 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 problemoccurs when an obsolete value is still stored in a processor’s cache.

18. 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

19. Distributed Multiprocessors or NUMA

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

21. 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

22. 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

23. 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.

24. Message-Passing Disadvantages • Programmers must make explicit message-passing 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.

25. 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.

26. 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

27. 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

28. 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.

29. 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.

30. 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

31. 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.

32. 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 real-time systems design. • Fast computing does not, in general, support predictability • Predictability depends on factors like architecture, implementation language, and environment

33. 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

34. 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

35. 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.

36. 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

37. 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

38. 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

39. 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

40. 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

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

42. 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

43. 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 fault-tolerance required with level of fault tolerance

44. 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.

45. 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.

46. 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

47. 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

48. 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

49. 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

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