notes 3510 Typical Real-T ime Applications A real-t ime systems is required to complete i ts work and deliver its services on a t imely basis. Examples : Digital control Command and control Signal processing Telecommunications systems.
Digital Control Many real time systems are embedded in sensors and actuators and function as d igital controllers. The plant in block diagram refers to a controlled system, for example an engine, a brake, an aircraft, a patient. The state of the plant is monitored by sensors and can be changed by actuators. The real-t ime (computing) estimates f rom the sensor readings the current state of the plant and computes a control output based on the difference between current state and desired state.
We can implement it as an infinite timed loop : set t imer to inter rupt periodically with period T at each t imer in ter rupt; do do analog-to-digital conversion to get y compute control output u output u and do digital-to-analog conversion end do; Some examples of digital controller: Embedded control systems
automotives robots aircraft medical devices Guidance and Cont rol This type of controller performs guidance and path planning functions to achieve a h igher level goal. I t t r ies to find one of the most desirable t rajectories among all t rajectories that meet the constraints of the system. As an example, a f l ight management system. Real-time Command and Cont rol The controller at the highest level of a control hierarchy is a command and control system. An Air Traffic Control (ATC) system is an excellent example. Signal processing Most signal processing applications have some kind of real-t ime requirements. Response t imes are under a few milliseconds to a few seconds. Examples are digital f il tering, video and voice compression A signal processing application is typically a part of a larger system. For example a radar signal processing and t racking system. M ultimedia Applications A multimedia application may process, store, t ransmit, and display any number of v ideo streams, audio streams, images, graphics, and text. Without compression, the s torage space and t ransmission bandwidth required by a video are enormous. T herefore, a video stream, as well as the associated audio stream, is invariably compressed as soon as i t is captured. Types of real-time applications Real t ime applications into the following four types according to their t iming a tt ributes: 1. Purely cyclic: E very task executes periodically. Digital controller. F light control system and real-time monitors. 2. Mostly cyclic Most tasks execute periodically. The system must also respond to some external events. Example: modern avionics and process control systems. Asynchronous a nd somewhat predictable: mul timedia communication, radar signal processing, and t racking. 3. Asynchronous and unpredictable: Reacts to asynchronous events and have tasks with high run-t ime complexity. Ha rdwa re Requi rement
Some of the real-t ime applications run on one or a few microprocessors, even on hand-held devices, while others run on tens and hundreds of computer. They are l abeled as unip rocessor, multip rocessor or distributed systems.
Overview: Hard vs. Soft Real Time
Timing parameters for RT systems Timing parameters: Release Time (r): time when job becomes available for execution. - Completion Time (f): time when job finishes execution. - Response Time: (f r) Deadline (d): time when execution must be completed (f d in R-T systems). Relative Deadline (D): maximum response time (D = d r). Execution time (e): (e f r) equals response time when processor is kept continuously busy. Feasible interval of a job: time interval from r to d. Without - parameters are (usually) known to the scheduler before jobs are released, with - are known only after the job has finished execution. Other timing parameters: Lateness (L): L = f d (L > 0 if deadline is not met) Tardiness (E): E = max{L, 0} (E = 0 if deadline is met) Laxity (Slack): S(t) = d t erem In the feasible interval of a job: - at time t, S(t) indicates the remaining time before the deadline (d t) minus the remaining execution time (erem).
Slack time (laxity)
S(t) = d t erem the slack of a job is function of time defined in its feasible interval - at the release time r, S(r) = D e = d r e - S(t) remains constant when the job is executing - S(t) decreases with t when the job is not executing - if becomes S(t) negative, the deadline will be missed.
Hard vs. soft timing constraints
Common definitions are based on: functional criticality: - soft: meeting the constraints (deadlines) is desirable, but a few misses do no serious harm, - hard: missing a deadline is a fatal fault; usefulness of late results: - soft: usefulness decreases gradually with tardiness, - hard: usefulness drops to zero or becomes negative when tardiness is larger than zero; deterministic or probabilistic nature of constraints: - soft: deadlines can be missed occasionally, with low probability, - hard: deadlines must never be missed.
Hard vs. Soft deadlines
Hard Deadline: Late result may be a fatal flaw, useless, or cause disastrous consequences Soft Deadline: Timely completion desirable. Late results useful to some degree Quantitative measure: Overall system performance as function of tardiness of jobs.
Operational Definition: A job has a hard deadline whenever the system designer must prove that the job never misses its deadline.
- soft real time systems Definition: A real-time system is a soft-real-time
system when jobs have soft deadlines.
Non-stringent timing requirements on-line transaction system telephone switches More stringent timing requirements Stock price quotation system Stringent timing requirements Multimedia Requirements often specified in probabilistic terms; validation is done by simulation, trial use.
- hard real time systems Definition: A real-time system is hard-real-time when a large portion of the deadlines is hard. Examples: - Embedded systems (e. g. automatically controlled train: braking action on red signal) - Recovery procedures in high-availability systems (e. g. must complete within 60 seconds) Does real-time mean fast ? Need for verification: certification that deadlines are met. Why requirements to meet deadlines 100% of the time? - it is difficult to validate probabilistic timing requirements. - it is difficult to assess compound effect of missed deadlines with other factors. Hard vs. soft Real-Time Systems
9
All the definitions are compatible with the distinction between: - guaranteed service - best-effort service guaranteed service is required for hard RT systems best-effort service may be appropriate for soft RT systems Timing Constraints Timing constraints can be specified in different terms: 1. deterministic constraints (e.g. response time 50 ms) 2. probabilistic constraints (e.g. probability that response time > 50 ms less than 0.1) 3. in terms of some usefulness function (e.g. usefulness function 0.8) In practice hard timing constraints are of the first type: specified as deterministic constraints (easier to validate than the latter two types). CPU utilization
Determining CPU Utilization: Suppose a system has n 1 periodic tasks, each with an execution period of pi, and hence, execution frequency is: fi = 1/pi (i = 1 to n) If task Ti is known to have (or has been estimated to have) a maximum (worst case) execution time of ei, then the utilization factor, ui, for task Ti is:
ui = ei /pi Then the overall system utilization is: The (CPU) utilization factor U, is a measure of the percentage of non-idle processing.
Typical response times
Response times or deadlines of several real-time applications. Steps in validating timing constraints 1. Verify that in each component of the system the timing constraints are specified correctly: ensure that the timing constraints of each component are: mutually consistent, consistent with the high-level RT requirements. 2. Verify the feasibility of each component with the available HW and SW resources: ensure that each component in the system can meet its timing constraints if: it executes alone, and has all the required resources. 3. Verify that the whole system behaves as specified: ensure that, when scheduled together with some scheduling algorithm, the timing constraints of all components
(competing for the available resources) are always met
How to validate timing constraints 1. To verify that in each component of the system the timing constraints are specified correctly: use formal methods. 2. To verify the feasibility of each component with the available HW and SW resources: use performance analysis. 3. To verify that a scheduling algorithm can meet the timing constraints of all components, competing for the available resources, is the subject of this course.