×
The question isn’t who is going to let me; it’s who is going to stop me.
--Your friends at LectureNotes
Close

Note for Real Time Systems - RTS By Prakash Poudel

  • Real Time Systems - RTS
  • Note
  • 9 Topics
  • 807 Views
  • 7 Offline Downloads
  • Uploaded 9 months ago
0 User(s)
Download PDFOrder Printed Copy

Share it with your friends

Leave your Comments

Text from page-1

Real Time System - Student Hand Book RTS Unit 2: Hard Versus Soft Real time System JOBS AND PROCESSORS Each unit of work that is scheduled and executed by the system is called a job and a set of related jobs which jointly provide some system function a task. Hence, the computation of a control law is a job. So is the computation of a FFT (Fast Fourier Transform) of sensor data, or the transmission of a data packet, or the retrieval of a file, and so on. A job executes or is executed by the (operating) system. Every job executes on some resource. For example, the jobs mentioned above execute on a CPU, a network, and a disk, respectively. These resources are called servers in queuing theory literature and, sometimes, active resources in realtime systems literature. To avoid overloading this term, we call all these resources processors except occasionally when we want to be specific about what they are. Each processor has a speed attribute which determines the rate of progress a job makes toward completion. Two processors are of same type if they are functionally identical and can be used interchangeably. RELEASE TIMES, DEADLINES, AND TIMING CONSTRAINTS Response Time and Execution Time The time spent by the job actively using processor resources is its execution time. The execution time of each job instance from the same task is likely to differ. The response time for a job is the time between when it becomes active (e.g. an external event or timer triggers an interrupt) and the time it completes. Several factors can cause the response time of a job to be longer than its execution time. Release Time The release time of a job is the instant of time at which the job becomes available for execution. The job can be scheduled and executed at any time at or after its release time whenever its data and control dependency conditions are met. It may not be exact due to release time Jitter. As an example, we consider a System which monitors and controls several furnaces. After it is initialized and starts execution (say at time 0), the system samples and reads each temperature sensor every 100msec and places the sampled readings in memory. It also computes the control law of each furnace every 100msec in order to process the temperature readings and determine flow rates of fuel, air, and coolant. Suppose that the system begins the first control-law computation at time 20msec. The fact that the control law is computed periodically can be stated in terms of release times of the controllaw computation jobs J0, J1... Jk .... The release time of the job Jk in this job stream is 20 + k × 100msec, for k = 0, 1, we say that jobs have no release time if all the jobs are released when the system begins execution. Deadline The deadline of a job is the instant of time by which its execution is required to be completed. Relative Deadline: The maximum allowable response time of a job is its relative deadline. Absolute deadline Prepared by: Er. Prakash Poudel Jigyasu Page 1

Text from page-2

Real Time System - Student Hand Book RTS Absolute Deadline: The deadline of a job, sometimes called its absolute deadline, is equal to its release time plus its relative deadline. HARD AND SOFT TIMING CONSTRAINTS We call a constraint imposed on the timing behavior of a job a timing constraint. In its simplest form, a timing constraint of a job can be specified in terms of its release time and relative or absolute deadlines.  It is common to divide timing constraints into two types: hard and soft. They are based on the functional criticality of jobs, usefulness of late results, and deterministic or Probabilistic nature of the constraints. They are based on the functional criticality of jobs, usefulness of late results, and deterministic or Probabilistic nature of the constraints. A timing constraint or deadline is hard if the failure to meet it is considered to be a fatal fault. A hard deadline is imposed on a job because a late result produced by the job after the deadline may have disastrous consequences. (As examples, a late command to stop a train may cause a collision, and a bomb dropped too late may hit a civilian population instead of the intended military target.) In contrast, the late completion of a job that has a soft deadline is undesirable. However, a few misses of soft deadlines do no serious harm; only the system’s overall performance becomes poorer and poorer when more and more jobs with soft deadlines complete late. In real-time systems literature, the distinction between hard and soft timing constraints is sometimes stated quantitatively in terms of the usefulness of results as functions of the tardinesses of jobs. Tardiness: The tardiness of a job measures how late it completes respective to its deadline. Its tardiness is zero if the job completes at or before its deadline; otherwise, if the job is late, its tardiness is equal to the difference between its completion time (i.e., the time instant at which it completes execution) and its deadline. The usefulness of a result produced by a soft real-time job (i.e, a job with a soft deadline) decreases gradually as the tardiness of the job increases, but the usefulness of a result produced by a hard realtime job (i.e., a job with a hard deadline) falls off abruptly and may even become negative when the tardiness of the job becomes larger than zero. The dead- line of a job is softer if the usefulness of its result decreases at a slower rate. Sometimes, we see this distinction made on the basis of whether the timing constraint is expressed in deterministic or probabilistic terms. If a job must never miss its deadline, then the deadline is hard. On the other hand, if its deadline can be missed occasionally with some acceptably low probability, then its timing constraint is soft. HARD TIMING CONSTRAINTS AND TEMPORAL QUALITY-OF-SERVICE GUARANTEES: The timing constraint of a job is hard, and the job is a hard real-time job, if the user requires the validation that the system always meets the timing constraint. By validation, we mean a demonstration by a provably correct, efficient procedure or by exhaustive simulation and testing. On the other hand, if no validation is required, or only a demonstration that the job meets some statistical constraint suffices, then the timing constraint of the job is soft. Prepared by: Er. Prakash Poudel Jigyasu Page 2

Text from page-3

Real Time System - Student Hand Book RTS This way to differentiate between hard and soft timing constraints is compatible with the distinction between guaranteed and best-effort services]. If the user wants the temporal quality (e.g., response time and jitter) of the service provided by a task guaranteed and the satisfactions of the timing constraints defining the temporal quality validated, then the timing constraints are hard. On the other hand, if the user demands the best quality of service the system can provide but allows the system to deliver qualities below what is defined by the timing constraints, then the timing constraints are soft. SOME REASONS FOR REQUIRING TIMING GUARANTEES Many embedded systems are hard real-time systems. Deadlines of jobs in an embedded system are typically derived from the required responsiveness of the sensors and actuators monitored and controlled by it. As an example, we consider an automatically controlled train. It cannot stop instantaneously. When the signal is red (stop), its braking action must be activated a certain distance away from the signal post at which the train must stop. This braking distance depends on the speed of the train and the safe value of deceleration. From the speed and safe deceleration of the train, the controller can compute the time for the train to travel the braking distance. This time in turn imposes a constraint on the response time of the jobs which sense and process the stop signal and activate the brake. No one would question that this timing constraint should be hard and that its satisfaction must be guaranteed. Similarly, each control-law computation job of a flight controller must be completed in time so that its command can be issued in time. Otherwise, the plane controlled by it may become oscillatory (and the ride bumpy) or even unstable and uncontrollable. For this reason, we want the timely completion of all control-law computations guaranteed. HARD REAL-TIME SYSTEMS A hard real-time task is one that is constrained to produce its results within certain predefined time bounds. The system is considered to have failed whenever any of its hard real-time tasks does not produce its required results before the specified time bound. An example of a system having hard real-time tasks is a robot. The robot cyclically carries out a number of activities including communication with the host system, logging all completed activities, sensing the environment to detect any obstacles present, tracking the objects of interest, path planning, effecting next move, etc. Now consider that the robot suddenly encounters an obstacle. The robot must detect it and as soon as possible try to escape colliding with it. If it fails to respond to it quickly (i.e. the concerned tasks are not completed before the required time bound) then it would collide with the obstacle and the robot would be considered to have failed. Therefore detecting obstacles and reacting to it are hard real-time tasks. Another application having hard real-time tasks is an anti-missile system. An anti-missile system consists of the following critical activities (tasks). An anti-missile system must first detect all incoming missiles, properly position the anti- missile gun, and then fire to destroy the incoming missile before the incoming missile can do any damage. All these tasks are hard real- time in nature and the anti-missile system would be considered to have failed, if any of its tasks fails to complete before the corresponding deadlines. Prepared by: Er. Prakash Poudel Jigyasu Page 3

Text from page-4

Real Time System - Student Hand Book RTS SOFT REAL TIME SYSTEMS A system in which jobs have soft deadlines is a soft real-time system. Soft real-time tasks also have time bounds associated with them. However, unlike hard real-time tasks, the timing constraints on soft real-time tasks are not expressed as absolute values. Instead, the constraints are expressed either in terms of the average response times required. Examples of such systems include on-line transaction systems and telephone switches, as well as electronic games, multimedia system, web browsing. Normally, after an URL (Uniform Resource Locater) is clicked, the corresponding web page is fetched and displayed within a couple of seconds on the average. However, when it takes several minutes to display a requested page, we still do not consider the system to have failed, but merely express that the performance of the system has degraded. Another example of a soft real-time task is a task handling a request for a seat reservation in a railway reservation application. Once a request for reservation is made, the response should occur within 20 seconds on the average. The response may either be in the form of a printed ticket or an apology message on account of unavailability of seats. Alternatively, we might state the constraint on the ticketing task as: At least in case of 95% of reservation requests, the ticket should be processed and printed in less than 20 seconds. Let us now analyze the impact of the failure of a soft real-time task to meet its deadline, by taking the example of the railway reservation task. If the ticket is printed in about 20 seconds, we feel that the system is working fine and get a feel of having obtained instant results. As already stated, missed deadlines of soft real-time tasks do not result in system failure. Comparison of Hard and Soft RTS S.N 1. Hard Real Time System Timing constraint is hard if failure to meet it is considered a fatal error. 2. Timing constraint is hard if failure to meet the usefulness of their result falls off (or may even go negative). User can obtain the validation. Completion of task or job is deterministic. Hard-required response time. Predictable peak load performance. Controlled by environment. Autonomous error detection. Small/medium size of data files E.g-Flight control, railway signaling, robot, antimissile system, inkjet printer etc. 3. 4. 5. 6. 7. 8. 9. 10.. Prepared by: Er. Prakash Poudel Jigyasu Soft Real Time System Timing constraint is soft. Failure to meet the deadline is not considered as complete system failure but that performance is considered to be degraded. The usefulness of the result is never negative. Not always obtain the validation. Completion of task or job is probabilistic. Soft-required response time. Degraded peak load performance. Controlled by computer. User assisted error detection. Large size of data files E.g- DVD player, mobile phone, on-line transaction systems, telephone switches, electronic games, multimedia system, web browsing etc. Page 4

Lecture Notes