Joint scheduling of periodic and aperiodic tasks

Classification of tasks found in practical systems.

• Periodic tasks

  • Suitable e.g. to applications where it is required sampling regularly a given physical entity (e.g. acquire an image, a temperature, pressure, torque, speed), actuate regularly on the system, etc.

  • kth task instance activated at ak = k · Tk + Φk. Worst-case is well defined

• Aperiodic and Sporadic tasks

  • Suitable to scenarios where the event activation instants cannot be forecast, e.g. alarms, human-machine interfaces, external asynchronous interrupts.

    • Sporadic tasks

      • In worst-case it behaves as a periodic task , with period = mit.
    • Aperiodic tasks

      • Only characterizable via probabilistic methods.

      • How to bound the interference on periodic tasks?

      • How to guarantee an acceptable/best possible quality of service (QoS)?
• Hybrid systems

  • Applications which contain both types of tasks.

  • Many (most?) real systems contain naturally both periodic and aperiodic events/tasks.

Background execution

A simple way of combining both task types is giving higher priority to the periodic/sporadic tasks than to the aperiodic ones.

Thus the aperiodic tasks only execute when there are no ready periodic/sporadic tasks.

Aperiodic tasks are executed in background with respect to the periodic/sporadic ones – background execution.

The background execution is very easy to implement and does not interfere directly with the periodic system/tasks.

• However, interference may still occur indirectly, via ISR, non-preemptive system calls, etc.

On the other hand, aperiodic tasks may suffer big delays, depending on the periodic load.

• This delay may be upper-bounded considering the aperiodic tasks as the lowest priority task.

The performance is poor for aperiodic tasks that have some level of real-time requirements, tough it can be acceptable to the ones that don’t have such requirements.