APPLICATION DESIGN ISSUES - Hard Real-Time Computing Systems: Predictable Scheduling Algorithms and Applications - page 402

If meeting a given deadline is critical for the system operation and may cause catas-
trophic consequences, the task must be treated as a hard task. If meeting time con-
straints is desirable, but missing a deadline does not cause any serious damage, the
task can be treated as a soft task. In addition, activities that require regular activation
should be handled as periodic tasks.

From the operating system point of view, a periodic task is a task whose activation is
directly controlled by the kernel in a time-driven fashion, so that it is intrinsically guar-
anteed to be regular. Vice versa, an aperiodic task is a task that is activated by other
application tasks or by external events. Hence, activation requests for an aperiodic
task may come from the explicit execution of specific system calls or from the arrival
of an interrupt associated with the task. Note that even though the external interrupts
arrive at regular intervals, the associated task should still be handled as an aperiodic
task by the kernel, unless precise upper bounds on the activation rate are guaranteed
for that interrupt source.

If the interrupt source is well known and interrupts are generated at a constant rate, or
have a minimum interarrival time, then the aperiodic task associated with the corre-
sponding event is said to be sporadic and its timing constraints can be guaranteed in
worst-case assumptions - that is, assuming the maximum activation rate.

Once all application tasks have been identified and time constraints have been speci-
fied (including periodicity and criticality), the real-time operating system supporting
the application is responsible for guaranteeing that all hard tasks complete within their
deadlines. Soft and non-real-time tasks should be handled by using a best-effort strat-
egy (or optimal, whenever possible) to reduce (or minimize) their average response
times.

In the rest of this section we illustrate a few examples of control systems to show how
time constraints can be derived from the application requirements even in those cases
in which they are not explicitly defined by the user.

11.2.1 OBSTACLE AVOIDANCE

Consider a wheel-vehicle equipped with range sensors that has to operate in a certain
environment running within a maximum given speed. The vehicle could be a com-
pletely autonomous system, such as a robot mobile base, or a partially autonomous
system driven by a human, such as a car or a train having an automatic braking system
for stopping motion in emergency situations.