Time-utility function

[1][2] TUFs and their utility interpretations (semantics), scales, and values are derived from application domain-specific subject matter knowledge.

The various researcher and practitioner definitions of firm and soft real-time can also be represented as special cases of the TUF model.

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.

The TUF/UA paradigm was originally created to address certain action timeliness, predictability of 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 dynamically timeliness-critical systems not having deadlines) and load resilience (e.g., for systems subject to routine action overloads).

[26] TUFs and their utility interpretations (semantics), scales, and values are derived from domain-specific subject matter knowledge.

[b] A framework for á priori assigning static utility values subject to strong constraints on system models has been devised,[8] 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.

More generally, a TUF allows downward (and upward) step functions to have any pre- and post-critical time utilities.

Tardiness[32] 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.

Thus, TUFs provide a rich generalization of traditional action completion time constraints in real-time computing.

[f] These adaptations ordinarily occur at discrete events—e.g., at an application mode change such as for ballistic missile flight phases.

[35][36][g] Multiple actions in a system may contend for access to sequentially exclusively[h] shared resources—physical ones such as processors, networks, exogenous application devices (sensors, actuators, etc.

The instance's contending actions are dispatched for resource access sequentially in order from the front of the schedule.