Distributed Real-Time
and Real-Time Systems

E. Douglas Jensen

Worldwide Real-Time System Consulting: Requirements, Architecture,
Engineering, Performance, Technical Audits, Courses, more.

Time-Critical Technologies is a Unique Pioneer and Specialist in
Dynamic Real-Time Systems

Most interpretations of the term "real-time " refer to the traditional static type, often referred to as "hard real-time." Although there is not much of a consensus on the meanings of the terms "hard real-time" and "soft real-time," E. Douglas Jensen provides definitions, based on scientific first principles, of these and other essential terms in Introduction to Fundamental Principles of Dynamic Real-Time Systems.

Traditional static real-time computing systems presume that essentially all operational and application information, and the time evolution of the system, are known in advance. That is a very strong presumption that limits the application domains to which such systems are relevant.

Static real-time systems are an important comparatively simple special case of dynamic real-time systems--analogous to Newtonian physics being a special case of relativistic physics.

Dynamic real-time systems by definition have inherent uncertainties in their applications and operational environments--such as tasks and their arrival times, durations, resource conflicts, completion times, and timeliness constraints.

Despite these uncertainties, dynamic tasks and systems are characterized as being real-time ones in the same sense as are static real-time systems:

  • Having constraints on task timeliness and predictability of timeliness
  • Providing utility as a function of how acceptably those constraints are satisfied

Static real-time computing systems' tasks have only one allowable completion time constraint, deadlines. They provide only a binary utility depending on á priori binary predictability: either all the tasks will always meet their deadlines (acceptable); or they will not (not acceptable, often said to have failed).

In the common case when missing one or more (leaving "more" undefined) deadlines is still considered acceptable (e.g., can be statically compensated for), the system is sometimes erroneously called a "firm real-time" one. However, in fact it is a simple instance of properly defined soft real-time systems (which holds for any number of "more").

Dynamic real-time systems' tasks may have any form of task completion time constraints (including the special case of deadlines) and task completion time predictability constraints (such as probability distributions).

They provide (positive, zero, or negative) utility as some application-specific function of how well their operation satisfies those timeliness and predictability constraints, according application- and even situation-specific acceptability criteria.

Commonly found examples of dynamic real-time system task completion time constraints and predictability of task completion times, and how utility may be derived from acceptably satisfying them, include:

  • Utility based on minimizing the number of missed deadlines, or minimizing either the maximum or the mean tardiness, with (say) normally distributed probability >0.9
  • Always completing all the most important tasks, and (say) >80% of the lesser important tasks, at times which result in the highest collective utility to the application.

These examples are instances of soft real-time (as properly defined in the referenced document), and illustrate that dynamic real-time systems are soft real-time ones, and that static hard real-time systems are a special case of dynamic ones.

Unacceptable satisfaction of dynamic soft real-time timeliness and predictability of timeliness constraints may be considered a system failure (just as with static hard real-time systems).

Indeed, if a soft real-time system has an occasion of unacceptable timeliness that allows a hostile nuclear armed missile to hit a large city, that will kill and injure many more people than can die if the largest passenger aircraft crashes (even into a heavily populated area) due to missing a flight control hard deadline.

Dynamic time-constrained operations are part of virtually everyone's lives, and thus are at least implicitly obvious.

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 tardy 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 acceptable to some degree. The amount of earliness or tardiness has situation-specific kinds and degrees of acceptability, 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. Clearly, there is a window of essentially equally acceptable time, within which is the deadline. Claiming that the "real" deadline is the window's latest time just makes the scenario less realistic with less ability to accommodate dynamic circumstances. The brute force approach (used in static hard real-time computing systems) is to try figuring out the worst case transit time to the school (generally difficult), intending to arrive there early and stay there with your child until 8:00 a.m. That is an inefficient waste of excess resources, since the worst case is normally infrequent.

Consider a notional air-to-ground combat mission to destroy a moving, starting, and stopping hostile ground vehicle by guiding an interceptor missile to hit it. There are numerous inevitable uncertainties and resource access conflicts (radar time-lines, processing cycles, data links, etc.) by and among asynchronous concurrent actions involved. 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 acceptable suboptimal 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.

The presumption of deterministic (see the referenced document for a correct definition) real-time system application environment, behavior, and outcomes, on which static real-time systems are based, is not possible when dynamic uncertainties are introduced.

Fortunately, there is a vast body of theory and practice outside the real-time computing field for not just tolerating but also exploiting non-determinism in dynamic systems.

Applying and expanding such theory and practice to dynamic real-time systems is how Time-Critical Technologies successfully adds unique value to our consulting clients' products and businesses.