Introduction to Real Time Systems

IntroductiontoReal Time Systems Akos Ledeczi EECE 6354, Fall 2017 Vanderbilt University

Disclaimer • Some of the material/slides are adapted from various presentations found on the internet: • Johnnie W. Baker • Ian Sommerville • Alan Burns and Andy Wellings • Others • And Prof. Kopetz’s Real Time Systems book

Embedded vs. Real Time Systems • Embedded system: is a computer system that performs a limited set of specific functions. It often interacts with its environment. • RTS: Correctness of the system depends not only on the logical results, but also on the time in which the results are produced. Real Time Systems Embedded Systems Examples?

Examples • Real Time Embedded: • Nuclear reactor control • Flight control • Basically any safety critical system • GPS • MP3 player • Mobile phone • Real Time, but not Embedded: • Stock trading system • Skype • Pandora • Embedded, but not Real Time: • Home temperature control • Sprinkler system • Washing machine, refrigerator, etc. • Blood pressure meter

Characteristics of RTS • Event-driven, reactive. • High cost of failure. • Concurrency/multiprogramming. • Stand-alone/continuous operation. • Reliability/fault-tolerance requirements. • Predictable behavior.

Time now past future instant instant time line event event duration digital clock tick granule

Definitions • Hard real-time — systems where it is absolutely imperative that responses occur within the required deadline. E.g. Flight control systems. • Soft real-time — systems where deadlines are important but which will still function correctly if deadlines are occasionally missed. E.g. Data acquisition system. • Real real-time — systems which are hard real-time and which the response times are very short. E.g. Missile guidance system. • Firm real-time — systems which are soft real-time but in which there is no benefit from late delivery of service. A single system may have all hard, soft and real real-time subsystems. In reality many systems will have a cost function associated with missing each deadline

Control systems Man-Machine Interface Instrumentation Interface • Man-machine interface: input devices, e.g. keyboard and output devices, e.g. display • Instrumentation interface: sensors and actuators that transform between physical signals and digital data • Most control systems are hard real-time • Deadlines are determined by the controlled object, i.e. the temporal behavior of the physical phenomenon Operator Real-Time Computer System Controlled Object

Control system example Example: A simple one-sensor, one-actuator control system. rk reference input r(t) A/D uk control-law computation D/A yk A/D y(t) u(t) sensor actuator plant Outside effects The system being controlled

Control systems cont’d. Pseudo-code for this system: set timer to interrupt periodically with period T; at each timer interrupt do do analog-to-digital conversion to get y; compute control output u; output u and do digital-to-analog conversion; end do T is called the sampling period. T is a key design choice. Typical range for T: seconds to milliseconds.

Reliability and Safety • Reliability: probability that the system will provide the specified service for a given time period. (Also see Failure Rate or Mean Time To Failure: MTTF) • Safety: reliability regarding critical failure modes • Fail-safe system: if the system has a guaranteed safe state that can be reached in case of a critical failure. It is a property of the controlled object and not the computer system. • Watchdog: external device that gets periodic life sign from the computer system. If it does not get it, it forces the controlled object into a safe state. • Fail-operational system: no such safe state exists, so the computer system must provided (limited) functionality in case of failures to avoid a catastrophic failure. • Alarm monitoring. • Primary event • Secondary alarms. Temporal order is very important. Alarm shower • Rare events

Taxonomy of Real-Time Systems

Taxonomy: Static • Task arrival times can be predicted • Static (compile-time) analysis possible • Allows good resource usage (low idle time for processors).

Taxonomy: Dynamic • Arrival times unpredictable • Static (compile-time) analysis possible only for simple cases. • Processor utilization decreases dramatically. • In many real systems, this is very difficult to handle. • Must avoid over-simplifying assumptions • e.g., assuming that all tasks are independent, when this is unlikely.

Taxonomy: Soft Real-Time • Allows more slack in the implementation • Timings may be suboptimal without being incorrect. • Problem formulation can be much more complicated than hard real-time • Two common and an uncommon way of handling non-trivial soft real-time system requirements • Set somewhat loose hard timing constraints • Informal design and testing • Formulate as an optimization problem

Taxonomy: Hard Real-Time • Creates difficult problems. • Some timing constraints are inflexible • Simplifies problem formulation.

Taxonomy: Periodic • Each task (or group of tasks) executes repeatedly with a particular period. • Allows some static analysis techniques to be used. • Matches characteristics of many real problems • It is possible to have tasks with deadlines smaller, equal to, or greater than their period. • The later are difficult to handle (i.e., multiple concurrent task instances occur).

Periodic • Single rate: • One period in the system • Simple but inflexible • Used in implementing a lot of wireless sensor networks. • Multi rate: • Multiple periods • Should be harmonics to simplify system design

Taxonomy: Aperiodic • Are also called sporadic, asynchronous, or reactive. • Creates a dynamic situation • Bounded arrival time interval are easier to handle • Unbounded arrival time intervals are impossible to handle with resource-constrained systems.

Example: Adaptive Cruise Control • Demo video • Control system • Hard Real Time • Multi-rate periodic • Camera • GPS • Low-speed mode for rush hour traffic United States Patent 7096109

Data Acquisition and Signal-Processing Systems • Examples: • Video capture. • Digital filtering. • Video and voice compression/decompression. • Radar signal processing. • Response times range from a few milliseconds to a few seconds. • Typically simpler than control systems

Other Real-Time Applications • Real-time databases. • Examples: stock market, airline reservations, etc. • Transactions must complete by deadlines. • Main dilemma: Transaction scheduling algorithms and real-time scheduling algorithms often have conflicting goals. • Data is subject temporal consistency requirements. • Multimedia. • Want to process audio and video frames at steady rates. • TV video rate is 30 frames/sec. HDTV is 60 frames/sec. • Telephone audio is 16 Kbits/sec. CD audio is 128 Kbits/sec. • Other requirements: Lip synchronization, low jitter, low end-to-end response times (if interactive).

Are All Systems Real-Time Systems? • Question: Is a payroll processing system a real-time system? • It has a time constraint: Print the pay checks every two weeks. • Perhaps it is a real-time system in a definitional sense, but it doesn’t pay us to view it as such. • We are interested in systems for which it is not a priori obvious how to meet timing constraints.

The “Window of Scarcity” • Resources may be categorized as: • Abundant: Virtually any system design methodology can be used to realize the timing requirements of the application. • Insufficient: The application is ahead of the technology curve; no design methodology can be used to realize the timing requirements of the application. • Sufficient but scarce: It is possible to realize the timing requirements of the application, but careful resource allocation is required.

Example: Interactive/Multimedia Applications Requirements (performance, scale) The interesting real-time applications are here sufficient but scarce resources insufficient resources Interactive Video High-quality Audio Network File Access abundant resources Remote Login 2000 1990 1980 Hardware resources in year X

User Program Including Operating User Programs Operating Hardware Hardware System Components System Typical Embedded Configuration OS or not? Typical OS Configuration

Foreground/Background Systems • Task-level, interrupt level • Critical operations must be performed at the interrupt level (not good) • Response time/timing depends on the entire loop • Code change affects timing • Simple, low-cost systems

RTS Programming • Because of the need to respond to timing demands made by different stimuli/responses, the system architecture must allow for fast switching between stimulus handlers. • Because of different priorities, unknown ordering and different timing requirements of different stimuli, a simple sequential loop is not usually adequate. • Real-time systems are therefore usually designed as cooperating processes with a real-time kernel controlling these processes. Concurrent programming

Real Time Java? • Java supports lightweight concurrency (threads and synchronized methods) and can be used for some soft real-time systems. • Java is not suitable for hard RT programming but real-time versions of Java are now available that address problems such as • Not possible to specify thread execution time; • Uncontrollable garbage collection; • Not possible to access system hardware; • Etc. • Real-Time Specification for Java • Sun Java Real-Time System Requires a Real Time OS underneath (e.g., no Windows support)

Classification of Scheduling Algorithms All scheduling algorithms dynamic scheduling (or online, or priority driven) static scheduling (or offline, or clock driven) dynamic-priority scheduling static-priority scheduling

Scheduling strategies • Non pre-emptive scheduling • Once a process has been scheduled for execution, it runs to completion or until it is blocked for some reason (e.g. waiting for I/O). • Pre-emptive scheduling • The execution of an executing processes may be stopped if a higher priority process requires service. • Scheduling algorithms • Round-robin; • Rate monotonic; • Shortest deadline first; • Etc.

Real-time operating systems • Real-time operating systems are specialised operating systems which manage the processes in the RTS. • Responsible for process management and resource (processor and memory) allocation. • Do not normally include facilities such as file management. 14

Operating system components • Real-time clock • Provides information for process scheduling. • Interrupt handler • Manages aperiodic requests for service. • Scheduler • Chooses the next process to be run. • Resource manager • Allocates memory and processor resources. • Dispatcher • Starts process execution.

Interrupt servicing • Control is transferred automatically to a pre-determined memory location. • This location contains an instruction to jump to an interrupt service routine. • Further interrupts are disabled, the interrupt serviced and control returned to the interrupted process. • Interrupt service routines MUST be short, simple and fast.

What’s Important in Real-Time Metrics for real-time systems differ from that for time-sharing systems. • schedulability is the ability of tasks to meet all hard deadlines • latency is the worst-case system response time to events • stability in overload means the system meets critical deadlines even if all deadlines cannot be met

Introduction to Real Time Systems