1. 1 EE514 – Real-Time Computing Basic Concepts on Real-Time Systems EE514 – Real-Time Computing Basic Concepts of Real-Time Systems Department of Electrical Engineering The Hong Kong Polytechnic University

2. 2 EE514 – Real-Time Computing Real-Time Application A real-time application is an application where the correctness of the application depends on the timeliness and predictability of the application as well as the results of computations. Real-time applications are becoming increasingly important in our daily lives and can be found in various environments such as automotive applications, medical equipment, aircraft control, nuclear plant, etc. Real-time applications provide an action or an answer to an external event in a timely and predictable manner. Basic Concepts on Real-Time Systems

3. 3 EE514 – Real-Time Computing Real-Time Application - Timeliness While many real-time applications require high-speed compute power, real-time applications cover a wide range of tasks with differing time dependencies. Timeliness has a different definition in each real-time application. What may be fast in one application may be slow or late in another. ‑ For example, a vehicle engine control needs to collect data and control actuators with microseconds accuracy, while a scientist monitoring the air pressure might need to collect data in intervals of several minutes. The success of both applications depends on well-defined time requirements. Basic Concepts on Real-Time Systems

4. 4 EE514 – Real-Time Computing Real-Time Application - Predictability The concept of predictability may vary from field of operation, but for real-time applications it generally means that a task or set of tasks can always be completed within a predetermined amount of time. Depending on the situation, an unpredictable real-time application can result in loss of data, loss of deadlines, or loss of plant production. Examples of real-time applications include process control, factory automation robotics, vehicle simulation, scientific data acquisition, image processing, built-in test equipment, music or voice synthesis, and analysis of high-energy physics. Basic Concepts on Real-Time Systems

5. 5 EE514 – Real-Time Computing Worst-case vs Average Time To have control over the predictability of an application, the programmer must understand which time bounds are significant. ‑ For example, an understanding of the average time it takes for a context switch does not guarantee task completion within a predictable timeframe. Real-time programmers must know the worst-case time requirements so that they can design an application that will always meet worst-case deadlines. ‑ It can be argued that all computing systems are real-time, because they all have limitations on the execution of a particular job. Therefore, real-time applications can be further classified as either hard or soft real-time. Basic Concepts on Real-Time Systems

6. 6 EE514 – Real-Time Computing Hard Real-Time Hard real-time applications require a response to events within a predetermined amount of time for the application to function properly. ‑ If a hard real-time application fails to meet specified deadlines, the application fails. While many hard real-time applications require high- speed responses, the granularity of the timing is not the central issue in a hard real-time application. ‑ An example of a hard real-time application is a missile guidance control system where a late response to a needed correction leads to disaster. Basic Concepts on Real-Time Systems

7. 7 EE514 – Real-Time Computing Soft Real-Time Soft real-time applications do not fail if a deadline is missed. Some soft real-time applications can process large amounts of data or require a very fast response time, but the key issue is whether or not meeting timing constraints is a condition for success. ‑ An example of a soft real-time application is an airline reservation system where an occasional delay is tolerable, but unwanted. Basic Concepts on Real-Time Systems

8. 8 EE514 – Real-Time Computing High-performance I/O (..1) Many real-time applications require high I/O throughput and fast response time to asynchronous external events. ‑ The ability to process and store large amounts of data is a key metric for data collection applications. ‑ Real-time applications that require high I/O throughput rely on continuous processing of large amounts of data. For some applications, the throughput requirements on a single channel are modest. However, an application may need to handle multiple data channels simultaneously, resulting in a high aggregate throughput. ‑ Real-time applications, such as medical diagnosis systems, need a response time of about one second while simultaneously handling data from, perhaps, ten external sources. Basic Concepts on Real-Time Systems

9. 9 EE514 – Real-Time Computing High-performance I/O (..2) Another key metric for some real-time applications is the speed at which the application responds to asynchronous external events and its ability to schedule and provide communication among multiple tasks. ‑ Real-time applications must capture input parameters, perform decision-making operations, and compute updated output parameters within a given timeframe. Some real-time applications may require a response time of microseconds while simultaneously handling data from a large number of external sources. ‑ Flight simulation program needs to acquire several hundred input parameters from the cockpit controls, compute updated position, orientation and speed, and then send several hundred output parameters to the cockpit console and a visual display subsystem. Basic Concepts on Real-Time Systems

10. 10 EE514 – Real-Time Computing Real-Time Operating System Fundamentals Embedded systems are not recognizable as computers. Instead, they are hidden inside everyday objects that surround us and help us in our lives. Real-time and embedded systems operate in constrained environments in which computer memory and processing power are limited. They often need to provide their services within strict time deadlines to their users and to the surrounding world. It is these memory, speed and timing constraints that dictate the use of real-time operating systems in embedded software. Basic Concepts on Real-Time Systems

11. 11 EE514 – Real-Time Computing Basic Concepts on Real-Time Systems What is an Operating System Anyway ? An operating system is primarily a resource manager, and the primary resource it manages is computer hardware. It provides many features including ‑ Defining the “user interface” ‑ Sharing the hardware among users ‑ Allowing users to share data among themselves ‑ Scheduling resources among users ‑ Facilitating input/output ‑ Recovering from errors It is an extended machine ‑ Hides the messy details which must be performed ‑ Presents user with a virtual machine, easier to use

12. 12 EE514 – Real-Time Computing Basic Concepts on Real-Time Systems A Computer System Consists of …

13. 13 EE514 – Real-Time Computing Basic Concepts on Real-Time Systems The Operating System Zoo Mainframe operating systems Server operating systems Multiprocessor operating systems Personal computer operating systems Real-time operating systems Embedded operating systems Smart phone/card operating systems Scale Real-time Systems

14. 14 EE514 – Real-Time Computing Basic Concepts on Real-Time Systems Real-Time / Embedded Operating Systems Hardware Operating System User Programs Typical OS Configuration Hardware Including Operating System Components User Program Typical Embedded Configuration Hardware Operating System User Programs

15. 15 EE514 – Real-Time Computing Basic Concepts on Real-Time Systems What is a Kernel? A kernel, executive or nucleus is the smallest portion of the operating system that provides for task scheduling, dispatching, and inter-task communication. In embedded systems, the kernel essentially represents the entire real-time system but the device drivers. Kernel Other layers Hardware User Programs

16. 16 EE514 – Real-Time Computing Basic Concepts on Real-Time Systems Kernel Hierarchy Users User interface shell, Networking File management, Security Operating System Memory management File and disk support Executive Inter-processor communication and synchronization Kernel Tasking schedulingMicro-kernel Thread/task control block management Nano-kernel Hardware Complexity Kernel can be further broken down into smaller modules including executive, kernel micro-kernel, nano-kernel.

17. 17 EE514 – Real-Time Computing Basic Concepts on Real-Time Systems Real-Time Kernel Here we will examine the strategies employed in the design of real-time kernel, and concentrate on the following aspects: ‑ Task scheduling and dispatching ‑ Intertask communication and synchronization ‑ Real-time memory management

18. 18 EE514 – Real-Time Computing Basic Concepts on Real-Time Systems Concept of Process and Thread One process, one thread (MS-DOS) One process, multiple threads (Java Runtime) Multiple processes, multiple threads (W2K, Solaris, Linux) Multiple processes, one thread per process (Unix) Process or task : Resource ownership Thread or Light Weight Process : Scheduling/execution process thread

19. 19 EE514 – Real-Time Computing Basic Concepts on Real-Time Systems Concept of Process and Thread (cont’) In a multithreaded environment, the followings are associated with a process: ‑ Address space to hold the process image ‑ Protected access to processors, other processes (IPC), files, and I/O resources (devices & channels) Within a process, there may be one or more threads, each with the following: ‑ A thread execution state (Running, Ready, etc) ‑ A saved context when not running – a separate program counter ‑ An execution stack ‑ Some static storage for local variables for this thread ‑ Access to memory and resources of its process, global variables.

20. 20 EE514 – Real-Time Computing Basic Concepts on Real-Time Systems Single-Threaded & Multithreaded Process Model

21. 21 EE514 – Real-Time Computing Basic Concepts on Real-Time Systems Event-Driven System (..1) Any occurrence that causes the program counter to change non-sequentially is considered a change of flow- of-control, and thus an event. In real-time systems, we have to determine the type of events that has to be executed, and the flow of these events:

22. 22 EE514 – Real-Time Computing Basic Concepts on Real-Time Systems Event-Driven System (..2) The “release” time is the time at which an instance of a scheduled task is ready to run, and is generally associated with an interrupt. In scheduling theory, the release time of a task is similar to an event. Event types: ‑ Synchronous events are those events that occur at predictable times. ‑ Asynchronous events occur at unpredictable times at regular intervals. ‑ Periodic events are those that occur at fixed intervals. ‑ Aperiodic events are irregularly timed events.

23. 23 EE514 – Real-Time Computing Basic Concepts on Real-Time Systems Polled Loop System The simplest real-time kernel – single task only Allow for fast response to single devices but can’t do much else Work well when ‑ a single processor is dedicated to handling the I/O for some fast device ‑ overlapping of events is not allowed or is kept to a minimum Pros: ‑ simple to write and debug ‑ response time is easy to determine Cons: ‑ often fail because of bursting of events ‑ not sufficient to handle complicated system ‑ inherently waste CPU time

24. 24 EE514 – Real-Time Computing Basic Concepts on Real-Time Systems Polled Loop System - Example A software system is needed to handle packets of data that arrive at a rate of no more than 1 packet per second. A flag named packet_here is set by the network, which writes the data into the CPU’s memory via direct memory access (DMA). The data are available when packet_here = 1. A polled loop can be used to handle such system. for (;;) {/* do forever */ if (packet_here)/* check flag */ { process_data();/* process data */ packet_here=0;/* reset flag */ }

25. 25 EE514 – Real-Time Computing Basic Concepts on Real-Time Systems Synchronized Polled Loop A variation on the polled loop uses a fixed clock interrupt to pause between the time when the signaling event is triggered and then reset. Such a system is used to treat events that exhibit switch bounce. ‑ Switch bounce is a phenomenon that occurs because it is impossible to build a switch that can change state instantaneously. ‑ Here is a typical response of a switch.

26. 26 EE514 – Real-Time Computing Basic Concepts on Real-Time Systems Synchronized Polled Loop - Example A polled-loop system is used to handle an event that occurs randomly, but no more than once per second. The event is known to exhibit a switch-bounce effect lasted for 20 ms. A 10 ms fixed-rate interrupt is available for synchronization. The event is signaled by an external device that sets a memory location via DMA. for (;;) {/* do forever */ if (flag)/* check flag */ { pause(20);/* wait for 20ms */ process_data();/* process data */ flag=0;/* reset flag */ } where pause (20) is a system timer call that provides a 20ms delay.

27. 27 EE514 – Real-Time Computing Basic Concepts on Real-Time Systems Cyclic Executives Cyclic executives are noninterrupt-driven systems that can provide the illusion of simultaneity by taking advantage of relatively short processes on a fast processor in continuous loop. Consider the following set of self-contained processes in a continuous loop: for (;;) { Process_1(); Process_2();... Process_N(); } In this case, a de facto cycle rate is established, which is the same for each process, as they execute in a “round-robin”.

28. 28 EE514 – Real-Time Computing Basic Concepts on Real-Time Systems Cyclic Executives (Cont’) Different rate structures can be achieved by repeating a process in the list as below: for (;;) { Process_1();check_user_input(); Process_2();do_flight_simulation(); Process_3();check_user_input(); Process_3();do_screen_update(); } where Process 3 runs twice as frequently as Process 1 and 2. The process list can be made adjustable by keeping a list of pointers to the process functions and manage by the OS as “tasks” are created and completed. Intertask synchronization and communication can be implemented via global variables or parameter lists. Example

29. 29 EE514 – Real-Time Computing Basic Concepts on Real-Time Systems State-Driven Code It uses nested if-then statements, case statements, or a finite state automata (FSA) to break up the processing of a function into discrete code segments. ‑ This allows the code segments to be temporarily suspended before completion, without loss of critical data. A good example is the network packet handler which is often broken up into phases within a communications program. For complex systems, table-driven code is more efficient and hence preferable. Often they are used in conjunction with polled loops for the testing of the first state flag.

30. 30 EE514 – Real-Time Computing Basic Concepts on Real-Time Systems State-Driven Code - Example There is a simple process consisted of 3 states. At the end state, a flag is set and the process is terminated. Upon restarting, the process resumes where it left off. switch (flag) { case 1: perform_part_1();/do state 1 processing */ flag = 2; break; case 2: perform_part_2(); /do state 2 processing */ flag = 3; break; case 3: perform_part_3(); /do state 3 processing */ flag = 1; break; }

31. 31 EE514 – Real-Time Computing Basic Concepts on Real-Time Systems Interrupt Driven Systems The various tasks in the system are scheduled via either hardware or software interrupts, whereas dispatching is performed by the interrupt-handling routines. Interrupts may occur at fixed rates (fixed-rate systems), aperiodically (sporadic systems), or both (hybrid systems). Upon switching tasks, a snapshot of the machine, called the context, must be preserved upon so that it can be restored upon reinitiating the interrupted process. The context includes: (1) registers, (2) program counter, and (3) other entities that could be altered by another process.

32. 32 EE514 – Real-Time Computing Basic Concepts on Real-Time Systems Context Switching This is the most important part of the real-time operation of the interrupt driven system. It is the process of saving and restoring sufficient information for a real-time task so that it can be resumed after being interrupted. The context is ordinarily saved to a stack data structure. Context switching time is a major contributor to response times and is a factor that we strive to minimize (i.e. save the minimum amount of information necessary to safely restore any process after it has been interrupted). Normally, interrupts are disabled during the critical context-switching period.

33. 33 EE514 – Real-Time Computing Basic Concepts on Real-Time Systems Stack Model The stack model for context switching is used mostly in embedded system where the number of real-time or interrupt-driven tasks is fixed. Context is saved by the interrupt handler. In this model, each interrupt handler is associated with a hardware interrupt and is invoked by the CPU via the interrupt vectors. The context is saved to a specially designated memory area that can be static for a single-interrupt system or a stack for a multi-interrupt system.

34. 34 EE514 – Real-Time Computing Basic Concepts on Real-Time Systems Stack Model - Example save() - saving of registers to a stack restore() - restores those registers from the stack Consider the following code for a partial real-time system consisting of a simple jump-to-self and three interrupt handlers, which saves context using the stack model.

35. 35 EE514 – Real-Time Computing Basic Concepts on Real-Time Systems Round-Robin Systems Several processes are executed sequentially to completion, often in conjunction with a cyclic executive. In round-robin systems with time-slicing, each executable task is assigned a fixed-time quantum (e.g.10ms) called a time slice in which to execute. A fixed-rate clock is used to initiate an interrupt at a rate corresponding to the time slice. The task executes until it completes or its execution time expires. If the task does not execute to completion, its context must be saved. The task is then placed at the end of the executable list. The context of the next executable task in the list is restored, and it resumes execution.

36. 36 EE514 – Real-Time Computing Basic Concepts on Real-Time Systems Round-Robin System - Time slicing of 3 tasks

37. 37 EE514 – Real-Time Computing Basic Concepts on Real-Time Systems Preemptive Priority Systems A higher-priority task is said to preempt a lower-priority task if it interrupts the lower-priority task. Systems that use preemptive schemes instead of round- robin or first-come-first-serve scheduling are called preemptive priority systems. The priorities assigned to each interrupt are based on the urgency of the task associated with that interrupt. Prioritized interrupts can be either fixed priority or dynamic priority. Preemptive priority schemes can lead to the hogging of resources by higher priority tasks – lower-priority tasks have the problem of starvation.

38. 38 EE514 – Real-Time Computing Basic Concepts on Real-Time Systems Preemptive Scheduling

39. 39 EE514 – Real-Time Computing Basic Concepts on Real-Time Systems Preemptive Priority Systems – 2 Examples Fixed priority system – the nuclear power station monitoring system. ‑ While the handling of intruder events is critical, nothing is more important than processing the core over-temperature alert. Dynamic priority system – threat-management systems of military aircrafts. ‑ Upto 6 enemy aircrafts can be tracked by dynamic-prioritized processes. The relative threat of each enemy aircraft is recomputed at fixed rate based on proximity, posture, and other factors. The priority of each process managing the individual threat is then readjusted.

40. 40 EE514 – Real-Time Computing Basic Concepts on Real-Time Systems Rate-Monotonic Systems Rate-monotonic systems are special class of fixed-rated preemptive priority interrupt driven system where the priorities are assigned so that higher the execution frequency, the higher the priority. This scheme is common in embedded applications, particular avionics systems, e.g. in aircraft navigation system: ‑ the task that gathers accelerometer data every 5 ms has highest priority ‑ The task that collects gyro data, and compensates these data and the accelerometer data every 40ms has the 2 nd highest priority. ‑ The task that updates the pilot’s display every second has lowest priority.

41. 41 EE514 – Real-Time Computing Basic Concepts on Real-Time Systems Major and Minor Cycles This is a common terminology applied to tasks which assign to run at specific frequencies (usually in periodic systems but also in noninterrupt driven cyclic executives). while (forever) do begin process_a; process_b; process_a process_c; process_a; process_b process_a; process_d; end Here, process_a runs 4 times more often than process_c or process_d and twice as often as process_b. Major cycle: abacabad Minor cycle: abac, abad, ab, ac, ad

42. 42 EE514 – Real-Time Computing Basic Concepts on Real-Time Systems Hybrid Systems Hybrid systems include interrupts that occur at both fixed rates and sporadically. ‑ The sporadic interrupts may be used to handle a critical error that requires immediate attention, and thus have highest priority. This type of system is common in embedded application. Another type of hybrid system is a combination of round- robin and preemptive systems. ‑ Tasks of higher priority can always preempt those of lower priority. If two or more tasks of the same priority are ready to run, they run in round-robin fashion.

43. 43 EE514 – Real-Time Computing Basic Concepts on Real-Time Systems Foreground/Background Systems An improvement over the interrupt-only systems in that the dummy polled loop is replaced by useful code (background process). The most common solution for embedded applications which involve a set of interrupt driven or real-time processes called the foreground and a collection if noninterrupt driven process called the background. Foreground tasks: run in round-robin, preemptive priority, or combination fashion. Background tasks: fully preemptable by any foreground task and represents the lowest priority task in the system. ‑ Anything that is not time critical, e.g. CPU load monitor. ‑ It is the lowest priority process which will always execute to completion unless the system is time-overloaded.

44. 44 EE514 – Real-Time Computing Basic Concepts on Real-Time Systems Foreground/Background Systems (cont’) All real-time solutions are just special cases of the foreground/background systems. For example ‑ Polled loop – a background only case ‑ Phase-driven code – a background only case ‑ Interrupt only system – foreground only case Foreground/background systems represent a superset of all the other real-time solutions discussed and are the solution of choice for embedded real-time systems because of their good response time with the use of hardware scheduling.

45. 45 EE514 – Real-Time Computing Basic Concepts on Real-Time Systems Full-Featured Real-Time Operating Systems The foreground/background solution can be extended to a full-featured real-time operating system adding the additional functions such as device drivers, networking support, debugging tools, etc. Using the same task scheduling approach: round-robin, preemptive priority, or a combination of both schemes. However, the task control block (TCB) model, rather than the simple stack model, is most often used because the number of real-time tasks is indeterminate and dynamic. TCB model is the most popular method for implementing commercial, full-feature, real-time operating systems because the number of real-time tasks can be variable. The main drawback is that when a large number of tasks are created, the overhead of the scheduler can become significant.

46. 46 EE514 – Real-Time Computing What makes an OS as RTOS An RTOS has to be multi-tasking and preemptible The notion of task priority has to exist The OS has to support task synchronization mechanisms A system of priority inheritance has to exist System should be deterministic Basic Concepts on Real-Time Systems

47. 47 EE514 – Real-Time Computing How to choose RTOS Factors to be considered ‑ Support of your processor of choice ‑ Portability to new processor ‑ Scalability to match varied application requirement ‑ Multiprocessor support ‑ Extended services such network support ‑ Standards/Portable Operating System Interface (POSIX) compliance ‑ Language support ‑ Development environment ‑ Licensing arrangements & price Basic Concepts on Real-Time Systems

48. 48 EE514 – Real-Time Computing Case study –Why Windows NT is not an RTOS An RTOS has to be multi-tasking and preemptible (passed) The notion of task priority has to exist ‑ But has only few level of priority, therefore the predictability is poor (failed) The OS has to support task synchronization mechanisms (passed) A system of priority inheritance has to exist (failed) System should be deterministic (failed) Basic Concepts on Real-Time Systems