Time-utility function

A Time/Utility Function ("TUF"), née "Time/Value Function", specifies the application-specific "utility" that an "action" (e.g., task, mechanical movement) yields depending on its completion time. TUFs and their utility interpretations (semantics), scales, and values are derived from application domain-specific subject matter knowledge. An example interpretation of utility is an action's relative "importance," which is independent of its "timeliness". The traditional deadline represented as a TUF is a special case—a downward step of values from 1 to 0 at the deadline time—i.e., timeliness without importance. A TUF is more general—it has a "critical time," with application-specific shapes and values on each side, after which it does not increase. 
The optimality criterion for scheduling multiple TUFs has historically in the literature been only maximal "utility accrual" ("UA")—e.g., a (perhaps expected) weighted sum of the individual actions' completion utilities. This thus takes into account timeliness with respect to critical times. Additional criteria (e.g., energy, predictability), constraints (e.g., dependencies), system models, scheduling algorithms, and assurances have been added as the TUF/UA paradigm and its use cases have evolved. More expressively, TUF/UA allows accrued utility, timeliness, predictability, and other scheduling criteria to be traded off against one another for the schedule to yield situational "application QoS"—as opposed to only timeliness per se.
Various published examples of civilian TUF/UA applications are included in the References.
Time/Utility Functions.
The TUF/UA paradigm was originally created to address certain timeliness- and "application QoS"-based scheduling needs of various military applications for which traditional real-time concepts and practices are not sufficiently expressive (e.g., for timeliness-critical systems not having deadlines) and resilient (e.g., for systems subject to routine overloads). An example class of such applications is ballistic missile defense (notionally).
Subsequently, numerous variations on the original TUF model, the TUF/UA paradigm's system model, and thus scheduling techniques, have been studied in the academic literature—e.g.,—and applied in civilian contexts.
Some examples of the latter include: cyber-physical systems, AI, multi-robot systems, drone scheduling, autonomous robots, intelligent vehicle-to-cloud data transfers, industrial process control, transaction systems, high performance computing, cloud systems, heterogeneous clusters, service-oriented computing, networking, and memory management for real and virtual machines. A steel mill example is briefly described in the Introduction of Clark's Ph.D. thesis. Information about any commercial or military instances of the paradigm may be publicly inaccessible (proprietary or classified, respectively).
TUFs and their utility interpretations (semantics), scales, and values are derived from domain-specific subject matter knowledge. A historically frequent interpretation of utility is actions' relative "importance." A framework for á priori assigning static utility values subject to strong constraints on system models has been devised, but subsequent (like prior) TUF/UA research and development have preferred to depend on exploiting application-specificity rather than attempting to create more general frameworks. However, such frameworks and tools remain an important research topic.
By traditional convention, a TUF is a concave function, including linear ones. See the depiction of some example TUFs.
TUF/UA papers in the research literature, with few exceptions, e.g., are for only either linear or piecewise linear (including conventional deadline-based) TUFs because they are easier to specify and schedule. In many cases, the TUFs are only monotonically decreasing.
A constant function represents an action's utility that is not related to the action's completion time—for example, the action's constant relative importance. This allows both time-dependent and time-independent actions to be scheduled coherently.
A TUF has a global "critical time", after which its utility does not increase. If a TUF never decreases, its global critical time is the first time when its maximum utility is reached. A constant TUF has an arbitrary critical time for the purpose of scheduling—such as the action's release time, or the TUF's termination time. The global critical time may be followed by local critical times—for example, consider a TUF having a sequence of downward steps, perhaps to approximate a smooth downward curve.
TUF utility values are usually either integers or rational numbers.
TUF utility may include negative values. (A TUF that has negative values in its range is not necessarily dropped from scheduling consideration or aborted during its operation—that decision depends on the scheduling algorithm.)
A conventional deadline time (d) represented as a TUF is a special case—a downward step TUF having a unit penalty (i.e., having utility values "1" before and "0" after its critical time).
More generally, a TUF allows downward (and upward) step functions to have any pre- and post-critical time utilities.
Tardiness represented as a TUF is a special case whose non-zero utility is the "linear" function C - d, where C is the action's completion time—either current, expected, or believed. More generally, a TUF allows non-zero earliness and tardiness to be "non-linear"—e.g., increasing tardiness may result in non-linearly decreasing utility, such as when detecting a threat.
Thus, TUFs provide a rich generalization of traditional action completion time constraints in real-time computing. 
Alternatively, the TUF/UA paradigm can be employed to use timeliness with respect to the global critical time as a means to a utility accrual end—i.e., application-level Quality of Service (QoS)—instead of timeliness per se being an end in itself .
A TUF (its shape and values) may be dynamically adapted by an application or its operational environment, independently for any actions currently either waiting or operating. 
These adaptations ordinarily occur at discrete events—e.g., at an application mode change such as for ballistic missile flight phases. 
Alternatively, these adaptations may occur continuously, such as for actions whose operational durations and TUFs are application-specific functions of when those actions are either released or begin operation. The operation durations may increase or decrease or both, and may be non-monotonic. This continuous case is called "time-dependent scheduling". Time-dependent scheduling was introduced for (but is not limited to) certain real-time military applications, such as radar tracking systems.
Utility Accrual Scheduling.
Multiple actions in a system may contend for access to sequentially exclusively shared resources—physical ones such as processors, networks, exogenous application devices (sensors, actuators, etc.)—and logical ones such as synchronizers, data.
The TUF/UA paradigm resolves each instance of this contention using an application-specific algorithmic technique that creates (or updates) a "schedule" at "scheduling events"—e.g., times (such as action arrival or completion) or states. The instance's contending actions are dispatched for resource access sequentially in order from the front of the schedule. Thus, action UA sequencing is not greedy.
The algorithmic technique creates a schedule based on one or more application-specific "objectives" (i.e., optimality criteria).
The primary objective for scheduling actions having TUFs is maximal "utility accrual" ("UA"). The accrued utility is an application-specific polynomial sum of the schedule's completed actions' utilities. When actions have one or more stochastic parameters (e.g., operation duration), the accrued utility is also stochastic (i.e., an expected polynomial sum).
Utility and accrued utility are generic, their interpretations (semantics) and scales are application-specific.
An action's operation duration may be fixed and known at system configuration time. More generally, it may be either fixed or stochastic but not known (either with certainty or in expectation) until it either arrives or is released. 
An operation duration may be an application-specific function of the action's operation starting time—it may increase or decrease or both, and may be non-monotonic. This case is called "time-dependent scheduling".
[More goes here soon...]