Soft Real-Time is the General and Most Common Case
Only very rarely is “a miss is as good as a mile” (and the converse). Endless contrary examples come readily to mind, of real-time actions where lateness (in the technical sense—i.e., earliness, tardiness) is integral to the logic of an action having a deadline. Informally speaking, these are soft real-time actions—that term is precisely and correctly defined below, contrary to surprisingly ubiquitous misconceptions. “Surprisingly,” because such examples are universal in everyone’s personal and professional lives, and they are immediately obvious. (The examples anticipate the subsequent discussion of real-time and dynamic real-time systems.)
Consider that you are taking your child to school. She is supposed to be at school by the deadline of 8:00 a.m. Many circumstances (at home, traffic, weather, etc.) make it very unlikely in general that you will leave her at the school at exactly 8:00 a.m. Leaving her at the school too early before 8:00 a.m. may expose her to potential risks, depending on the earliness. Leaving her at the school too late after 8:00 a.m. also may expose her to potential risks, depending on the tardiness. Even arriving at the school exactly at the 8:00 a.m. deadline may or may not be preferable to some degree. The amount of lateness (earliness or tardiness) has situation-specific kinds and degrees of preferences, such as allowing her some appropriate socialization time with other students, preventing her being subject to potential harm from others by being alone without protection, avoiding tardiness penalties, etc. Consider the similar case with altered preferences when you are picking your child up from school. Consider analogous cases that involve deadlines for the actions of arriving at meetings with your managers or business clients, etc., despite traffic, telephone calls, over-run meetings, etc.
The majority of real-time actions in automated systems are not hard real-time ones in either the researchers’ exact sense or practitioners’ various confused senses discussed above. A small minority are, but most actions having deadlines are real-time in the general sense where lateness is integral to their logic.
Consider a notional (but realistic) air-to-ground combat mission to destroy a moving (or starting and stopping) hostile ground vehicle by guiding an interceptor missile to hit it (an actual classified application for which the principles explained in my book and previewed here have been successfully used). There are numerous inevitable uncertainties and resource access conflicts (radar time-lines, processing cycles, access to data links, etc.) by and among asynchronous concurrent actions. In an ideal scenario, interceptor missile guidance updates would be transmitted at times that result in a direct interceptor strike on, and the destruction of, the hostile vehicle. In reality, these dynamic resource conflicts and other factors in “the fog of war” typically can create a diversity of more or less preferable sub-optimal outcomes. For example, there may be either a near enough miss that the hostile vehicle is operationally disabled to some degree, or a far enough miss that the vehicle is unharmed.
Such an interception is only part of an encompassing dynamic real-time combat mission. The mission typically can be partially depicted with a construct known as a battle management kill chain, as illustrated in a simplified way below.
A very simple mission instantiation might be thought of as traversing the kill chain stages sequentially from left to right in the figure.
In many cases, multiple (even all the) stages are being performed concurrently and asynchronously—e.g., for seeking new, and tracking detected, targets, and doing multiple engagements of individual target/interceptor pairs.
All the stages contend for access to a variety of resources shared among the stages (and other elements of the mission), such as one or more sensors, communication links, computational resources, weapons, etc. Each of these resources is subject to partial or complete failures, and additional resources can become available.
Dynamically and adaptively sequencing all the dynamic real-time actions in each of the kill chain stages to have situation-specific acceptable timeliness (action completion times, and predictability of completion times) is exceptionally challenging (and, obviously, mission- and safety-critical to an extreme).
Moreover, there are cases in which multiple kill chains co-exist concurrently on shared resources.
There is more than ample proof that attempting to employ traditional (e.g., static, periodic, etc.) real-time concepts and techniques drastically complicates and restricts the operation and effectiveness of these missions.
The principles summarized in my book have successfully been applied to such complex dynamic systems and missions.
It is primarily soft, not the hard special case of, real-time actions that determine the degree of mission effectiveness in the vast majority of time-constrained systems. Complex time-constrained systems often do have a mix of hard (typically at the lowest levels of the system) and soft actions.
Such general real-time cases, where lateness is an unavoidable critical aspect of actions having deadlines, are ubiquitous in military, civilian industrial, and almost all other non-trivial automated and human contexts.
Some in the conventional real-time computing field might mistakenly claim that only hard real-time actions (in whatever sense they interpret hard) are truly real-time ones—that the general case of actions involving lateness is soft (or even non) real-time in one of the numerous vague and contradictory ways soft is ordinarily used. The only rationale for restricting the term real-time to a minuscule subset of the general case is that a simple subset of general case theory and practices can be used.
Another misunderstanding commonly held in the conventional real-time computing field is that soft real-time actions which miss their deadlines will result only in some relatively insignificant (e.g., “que sera, sera”) degradation compared with that due to hard real-time actions which miss their deadlines.
Certainly a relatively small percentage of correctly defined hard real-time cases exist, such as aircraft flight control and the others mentioned earlier. However, the general real-time actions in the military scenarios above exemplify the central and dominant roles of soft real-time actions (as simply and informally but correctly defined here). In that sense they typify the great majority of real-time cases. They reveal that insufficiently preferable action completion times in terms of lateness (too early or too tardy) can (and do) result in as much or more damage, such as loss of many human lives, as might the hard real-time special case of an action meeting or missing a deadline. Unacceptable satisfaction of a soft real-time action can be a major disaster, and conversely missing a hard real-time action deadline can be inconsequential and recoverable. A sufficiently early or tardy action that allows a hostile (especially nuclear armed) missile to hit a large city will kill and injure many more people than can die in the largest passenger aircraft if it crashes (even into a heavily populated area) due to missing a flight control hard deadline.
Although conventional real-time computing principles and practices are almost exclusively limited to that hard real-time niche, a long history and vast body of research on, and application of, the whole general topic of real-time actions and systems exists in fields other than real-time computing. These fields include formal theory per se—such as stochastic scheduling theory, queuing theory, various probability theories, planning and decision making theories, genetic algorithms, fuzzy sets and related theories, to list just a few [ ]—and specific applications—such as military combat and logistics, industrial automation and process control, transportation, telecommunication, to list just a few [ ]. Almost none of this extensive theory and successful experience has been even noted by either researchers or practitioners of conventional real-time computing—they neither exploit any of it, nor contribute anything to it.
Designing and implementing a system having one or more such dynamic real-time actions is clearly more complex than doing so for conventional special case systems in which all—or what are deemed to be the only or most important— actions must (or are presumed to) be hard real-time ones in either the precise research or the various ill-considered practitioner senses. This complexity is necessary for cost-effective and even viable complex dynamic real-time systems, as opposed to unnecessary artifactual complexity introduced by trying to use the wrong tools—i.e., traditional static real-time concepts and techniques for dynamic real-time systems.
“If all you have is a hammer, everything looks like a nail.”
— Abraham Maslow, The Psychology of Science
(and many other sources and versions)
Obviously traditional real-time computing concepts and technologies are either inadequate or usually counter-productive for creating and evaluating dynamic real-time actions, much less systems having multiple concurrent ones.
The limited concepts and lexicon of traditional static “hard real-time”
are analogous to dealing with the color spectrum as binary,
consisting of black (in the paint, as opposed to light, sense)
and not-black (all other colors),
without the concepts and lexicon for describing and using the not-black colors.
The expressiveness of action earliness and tardiness is limited by the fact that they are one-dimensional and linear. Thus, they cannot relate early and tardy action completion times to corresponding significance—that must be specified with some other mechanism, whose syntax must be added to the sequencing criterion. Reasoning about these dynamic real-time actions (and their systems, to be discussed in a later chapter) requires a richer perspective and formalism that can express the dynamic real-time action completion times, preferences, and consequences. One approach is briefly introduced next.