Overview of Fundamental Real-Time Concepts and Terms "All great truths begin as blasphemies" --George Bernard Shaw This

is a 1-page synopsis of my formulation of the most fundamental yet almost universally misunderstood concepts and terms of real-time computing. This formulation is elaborated on the pages listed in the right hand Outline column. This formulation has been demonstrated to greatly facilitate the cost-effective construction of real-time computing systems that are far more complex (e.g., dynamic, adaptive, distributed) than can be constructed using traditional ill-defined real-time concepts. Real-time computing is about satisfying time constraints acceptably well with acceptable predictability according to application- and situation-specific acceptability criteria, given the current circumstances. Thus, there are two fundamental factors involved in what "real-time," "hard real-time," and "soft real-time" mean: time constraints on individual activities; criteria for using those time constraints to achieve system timeliness that is acceptably optimal with acceptable predictability. Very often when people discuss what "real-time," "hard real-time," and "soft real-time" mean, they focus on the first factor and largely overlook the second this results in serious misunderstandings. Time Constraints Most systems (not just those that are commonly considered "real-time" ones) include activities that have time constraints i.e., activities that each have utility to the system as a function of when that activity completes. Such activities could be the conspicuous cornerstone of a time-critical targeting application [insert your own example here]), or they could be buried inconspicuously inside device drivers for a desktop PC operating system. The most familiar example of a time constraint is a deadline, which is (properly but not popularly) defined as a time until which the activity's completion has more utility to the system, and after which the activity's completion has less utility. A hard deadline is the special case where utility is the binary set {1,0}: completing the activity by the deadline results in the system receiving all the utility possible from that activity, and completing the activity after the deadline results in zero utility (i.e., resources consumed by the activity were wasted, such as when a message is transmitted from a satellite after it has dropped below the horizon [insert your own example here]) or some negative value of utility (i.e., the activity was counter-productive, such as when an incoming missile is intercepted by an anti-missile missile from its target when it is only 20 meters away [insert your own example here]). The general case of a deadline (which is a soft deadline) has utility measured in terms of lateness (completion time minus deadline), tardiness (positive lateness), or earliness

(negative lateness). Larger positive values of lateness or tardiness represent lower utility, and consequently larger positive values of earliness represent greater utility. The significance of more or less utility in both the hard deadline and soft deadline cases is a system- or application- or situation-specific decision, and (contrary to popular mis-usage) is not part of the proper definitions of hard and soft deadlines. Missing a hard deadline may be either relatively insignificant (e.g., a sensor data sample is missed [insert your favorite example here]) or relatively significant (e.g., a torpedo alert is missed [insert your own example here]). Any given value of tardiness may be either relatively insignificant (e.g., affecting the battery power needed to transmit from a satellite as it declines toward the horizon [insert your own example here]) or relatively significant (e.g., affecting the circular error probability of kill [insert your own example here]). Deadlines are not intrinsically short; they may be from microseconds to megaseconds, depending on the activity, application, and system. The magnitude of a deadline (how soon it is) is independent of the significance of meeting or missing it some short deadlines are relatively insignificant, and some long deadlines are safety-critical. Beyond deadlines are more general time constraints e.g., specifying an activity's utility to the system as any function of when it completes. A hard deadline is the special case of a binary unit-valued downward step function, and a soft deadline is the special case of a particular 2-segment linear function. There are also other forms of time constraints. For simplicity and brevity on this page, we will confine our attention to the popular special cases of hard and soft deadlines. Additional information is provided on subsequent pages of this web, beginning with the time constraints page. Scheduling Optimality Criteria A system typically includes a multiplicity of actions; at any particular time, some of these actions are ready to execute. In a uniprocessor computer (assumed here for simplicity), only one action can execute at a time, so the action executions need to be sequenced (scheduled or dispatched; the distinction is outside the scope of this page). Usually some sequences of action executions are considered better than others, according to some goal; the goal is formally called the "sequencing optimality criterion". When the actions have deadlines, the ideal goal is for the system to always meet all of its actions' hard and soft deadlines (the goal normally has other factors also, such as satisfying precedence constraints and resolving resource conflicts, which we disregard here for simplicity). Circumstances may make meeting that goal either not cost-effective, or not possible at all. Frequent examples of such circumstances include: the combination of the actions' deadlines and execution durations; conflicts among the actions for shared resources; the failure of some resources. Given those circumstances, the goal becomes to meet the deadlines as best as possible. For hard deadlines, "as best as possible" means always meet all the hard deadlines if possible, otherwise change the hard deadline actions in some way to make it possible this is normally done statically by a' priori analysis and scheduling of the actions, or by execution time action admission control. For soft deadlines, "as best as possible" often means minimize the number of missed soft deadlines or the mean tardiness of the soft deadlines (there are many other possible and popular sequencing goals for soft real-time actions, but we limit ourselves on this page to

these two for brevity and simplicity) this may be done either statically a' priori, or dynamically at execution time. Sequencing goals have two components. The first component is to meet all the hard deadlines, and/or to minimize the number of missed, or the mean tardiness of, the soft deadlines; this is the optimality component of the goal. The second component is how much can be known about that optimality (number of missed deadlines, etc.) before the activities execute; this is the predictability component of the goal. If the sequencing optimality that will be attained is known exactly, in advance of all the activities completing execution, then the optimality is deterministic this applies both to hard deadlines (it is known in advance that all deadlines will always be met) and soft deadlines (it is known in advance what the number of missed deadlines or the mean tardiness will be). Otherwise, the predictability of the optimality is non-deterministic (usually considered to be stochastic). Deterministic timeliness requires deterministic characteristics of the actions, the system, and the execution environment. Dynamic uncertainties in those characteristics necessitate non-deterministic sequencing optimality. Predictability is a continuum, with determinism being the maximum predictability end-point. The minimum predictability end-point is that nothing is known a' priori about the optimality which will be attained. (There are various predictability models with analytical measures, but these are outside the scope of this page, and are discussed on a subsequent page.) System-, application-, and situation-specific acceptable sequencing optimality, and acceptable predictability of that optimality, are essential to the correctness of a system's real-time (i.e., time-constrained) actions. Such timeliness is integral to the logic of the application. This is equally true for actions with hard or soft deadlines. Systems with nonreal-time (i.e., non-time-constrained) actions have sequencing goals for those actions (usually focused on system throughput and fairness) with optimality and predictability components but those goals are only for performance rather than for correctness, they are not integral to the logic of the application. A system having only actions with hard deadlines, and a sequencing goal of always meeting all those hard deadlines (i.e., deterministic maximum sequencing optimality), is a hard realtime system. Many systems have mixtures of hard and soft deadlines, and thus their sequencing goals are that all hard deadlines be met deterministically, and that the number of missed (or tardiness of) the soft deadlines be acceptably low and have acceptably high predictability. Such systems can be said to be hard real-time systems to the degree that they have hard versus soft deadlines. The theory and techniques employed to guarantee that hard deadlines will always be met are much simpler and more commonly understood than the theory and techniques employed (a' priori or at execution time) to assure that soft deadlines will attain acceptable sequencing optimality and predictability of that optimality. In other words, "Hard real-time is hard, but soft real-time is harder." For this reason, the soft deadlines that are intrinsic to most systems are usually transformed into artificial hard deadlines. This results in the need for increased resources (because the requirement for deterministic characteristics of the activities, system, and environment requires resources to be reserved for the worst cases); consequently, the system is less adaptable to changes.

Hard and Soft Real-Time An understanding of time constraints (especially as expressed with time/utility functions), and of the two timeliness factors in a sequencing criterion (the optimality of timeliness and the predictability of that optimality), leads to more general and precise definitions of hard and soft real-time than are usual in the real-time computing field. These enable greatly improved perception of, and cost-effective satisfaction of, system timeliness requirements. Recall from the Time Constraints page, in our timeliness model, a hard deadline is not necessarily one that cannot be missed - that is a widespread confusion between the purpose of a time constraint and the purpose of a sequencing timeliness criterion. Rather, a hard deadline simply specifies that the action is untimely if the deadline is missed - it deliberately does not specify the (system-, application-, and situation-specific) consequences of that untimely action. Those consequences are a principal basis for specifying the sequencing timeliness criterion. A hard real-time system is one whose sequencing timeliness factors (there also may be non-timeliness factors) are optimality is the binary case that meeting all hard deadlines is optimal and otherwise is suboptimal (in some system-, application-, or situation-specific way) predictability of optimality is deterministic. These are the only hard real-time sequencing timeliness factors, and a hard real-time system has only these timeliness factors in its sequencing criterion. In the sequencing timeliness criterion 2-dimensional space of optimality and predictability of optimality, hard real-time is at the maximum optimality/maximum predictability corner point; the two factors are not traded off. This definition corresponds to the consensus within the real-time computing research community that hard real-time means all hard deadlines are always met. (The real-time computing practitioner (user, vendor) community has no consensus on the meanings of "hard real-time" and "soft real-time," they use these terms in many different ill-defined ways.) It is relatively unusual for a computing system to be intrinsically hard real-time. Most nontrivial real-time systems have execution entities with a mixture of hard deadlines and softer time constraints, such as deadlines and the equivalent of time/utility functions (although not usually understood and expressed that explicitly), plus execution entities that have no time constraints (but are subject to non-timeliness sequencing factors). Hard real-time systems typically arise as follows: either all the execution entities having hard deadlines are gathered together to form a hard real-time system (usually a "front end" subsystem at the device level) paired with a soft real-time, or (usually) non-real-time, "back end" system (for human interface, database, etc.), because the soft/non-real-time system is a given and can't support hard deadlines or the system designers/implementers don't know how to accommodate mixed time constraints in a single system

or all the time constraints are artificially forced to be hard deadlines because the system, or its designers/implementers/users, can't deal with any other kind of time constraints. Partitioning a computing system into a hard real-time "front end" and a non-real-time "back end" can be a natural and effective approach in some cases. But in many other cases it limits the effectiveness of front end computing, by restricting it to hard deadlines and the hard real-time sequencing timeliness factors, or of back end computing by preventing it from employing time-constraint driven resource management. Forcing all time constraints to be hard deadlines often limits the system's flexibility and adaptability, while increasing the hardware resource requirements and lowering the hardware resource efficiency. It is possible to build computing systems that can concurrently support actions having mixtures of hard deadlines, deadlines, soft time constraints, and no time constraints. Usually deadline-based sequencing approaches (in the real-time computing research literature - such approaches are uncommon in practice, as has been explained earlier) allow actions without hard deadlines to be sequenced in any manner that does not interfere with meeting the hard deadlines; only a small fraction of these approaches are secondarily concerned with the timeliness of actions without hard deadlines. A soft real-time system is one that is not the hard real-time special case, and is thus the general case. The sequencing timeliness optimality factor may be anything - examples of factors used very widely (outside the traditional real-time computing community) are "minimize the number of missed deadlines," and "minimize total tardiness." The predictability of optimality is non-deterministic, and is often modeled stochastically. Very common examples (outside the traditional real-time computing community) of sequencing timeliness criteria in terms of both factors are "minimize the expected number of missed deadlines," and "minimize the mean total tardiness." In the sequencing timeliness criterion 2-dimensional space of optimality and predictability of optimality, soft real-time is the entire space except for the hard real-time corner point. A system can be considered to be a hard real-time one to the degree that it has hard deadlines and a sequencing timeliness factor that includes always meeting all the hard deadlines. Some soft real-time systems are non-stochastically non-deterministic. They have properties that are so asynchronous - in the sense of intermittent, irregular, either interdependent or competitive - that stochastic models of predictability for them are either unknown or computationally intractable. Reasoning about the sequence timeliness of such systems is typically performed using simulation models or extensional (rule-based) and other models from fields such as artificial intelligence, decision theory, etc. Hard real-time systems must have at least some actions with hard deadlines. But the converse is not true - soft real-time systems may have actions with hard deadlines. Those systems are soft real-time because they do not employ the hard real-time sequencing timeliness criterion, they employ soft real-time ones such as "minimize the expected number of missed deadlines," regardless of whether the deadlines are hard or soft. It is clear that in the technical sense defined here (as opposed to popular misusage by practitioners), soft real-time systems are considerably more difficult to create than are hard real-time ones. Some of this disparity is the intrinsically greater complexity of soft real-time

applications, systems, and execution environments. But some is only a transient artifact both theory and practice of real-time computing systems have historically focused primarily on hard real-time, and that is necessarily changing. Note that "hard real-time" and "soft real-time" apply only to a "system," because their definitions are based on sequencing. In this sense, a system is any resource management facility that includes sequencing (of threads, only by our convention in this document), anywhere from the hardware up through the OS and middleware to the application(s).

Sequencing Algorithms and Heuristics When a sequence timeliness optimality criterion has been established - e.g., always meet all deadlines, minimize the expected number of missed deadlines, minimize mean tardiness, maximize the expected sum of utilities, etc. - an algorithm or heuristic must be selected or devised to satisfy that criterion. Sequencing in general is an NP-hard problem, and almost all interesting sequencing problems in particular are either known to be NP-hard or are unsolved.