embeddedtaskschedulerrtos

What happens if a hard realtime task exceeds its deadline?

I want to understand the concept underlying a hard realtime system more specifically by using an RTOS. By the definition of an RTOS it guaranties the realtime tasks will never exceed their deadlines. 

void RT_task1(void *params)
{
    do_inits();
    while (true)
    {
         ... // Do the job whatever it is in realtime.
         Delay(20); // Wait for 20 ms.
    }
 }

This is a simple structure of task based realtime system in an RTOS. In this point, I wonder these issues;

1) What is the "DEADLINE" which is mentioned by the definition of RTOS in this code block. Is it the "Delay" time 20 ms or something else determined by "Do Job" part?

2) What happens if the deadline is exceeded? I know it is guaranteed by RTOS, but in a "what if case": do we define a catastrophic error procedure?

3) How can RTOS guarantee the deadlines? I mean, I can run a lot of RT task so CPU resource may not be enough or a badly programmed task consumes too much time over other RT tasks? Where is the "guarateed" part?

I know the key difference between an RTOS and conventional OS is the scheduler. RTOS uses a deterministic way to give scheduling guarantee to user. However, this information is not fully satisfy me to understand the whole system.

Thanks.

Solution

  • @System Coder wrote:

    By the definition of an RTOS it guaranties the realtime tasks will never exceed their deadlines.

    That is not true. By definition an RTOS guarantees deterministic scheduling of tasks. Whether a task meets its deadline is entirely dependent on the design and implementation of your application, not least how you partition tasks, how they are triggered and how you assign the priorities.

    What happens if a hard realtime task exceeds its deadline?

    A more appropriate question would be how does your application behave if a task fails to meet its deadlines? The question is entirely application dependent. An RTOS will not intrinsically detect failed deadlines, because it has no knowledge of your application. The aim with an RTOS is to design the scheduling and priority assignment in such a way that deadlines can never be exceeded. If a deadline is exceeded, it is your design that is flawed, not a failure of the RTOS.

    Your code fragment is rather too simplistic; real-time applications normally have to respond to external events (other than just time), if the aim of the loop is that the task is performed every 20 OS ticks (milliseconds according to the comment), then it will fail that goal if the code before the delay takes any longer than 1 tick. Moreover the initial execution will be asynchronous to the RTOS tick, and the time between the first and second loop execution will be less deterministic in any case (somewhere between 19 and 20 ticks).

    The delay in a loop is fine for tasks that do not have hard deadlines; for say a PID loop for example it is a poor design. Instead in your example you should use an RTOS timer (as opposed to a delay); that way the loop body only needs to complete within 20ms rather than 1ms. If there are higher priority tasks and interrupts preempting this one, even if the code comes well withing 1ms on its own, it may miss that deadline if preempted and delayed by other code; so having 20ms to complete its task is obviously beneficial.

    1. What is the "DEADLINE" which is mentioned by the definition of RTOS in this code block. Is it the "Delay" time 20 ms or something else determined by "Do Job" part?

    The deadline is whatever is necessary for your application to succeed in meeting its requirements; it is not defined by the RTOS, it is defined by your requirements. As described above your example may not be a good design for real-time tasks, unless it and all possible preempting tasks can complete in less than 1ms. In any event it is not very scalable, and a design that meets deadlines initially may no longer do so following maintenance, new code or priority reassignment.

    1. What happens if the deadline is exceeded? I know it is guaranteed by RTOS, but in a "what if case": do we define a catastrophic error procedure?

    As I said; it is not guaranteed by the RTOS and the consequences of failure depend on your application. If nothing bad happens, perhaps the deadline was false and unnecessarily tight. If it fails you need to rethink the schedulability of your system.

    1. How can RTOS guarantee the deadlines? I mean, I can run a lot of RT task so CPU resource may not be enough or a badly programmed task consumes too much time over other RT tasks? Where is the "guarateed" part?

    It can't; it can guarantee deterministic scheduling; the highest priority "ready" task will run immediately (within the constraints of the context switch time) - simple as that, no more. You can still render scheduling non-deterministic even in an RTOS by poor interrupt handler design. They need to be deterministic also - each executing in a bounded and ideally constant time. The maximum delay to task execution is the sum of the execution times of all higher priority tasks and interrupts; as a general rule of thumb delays are minimised by assigning the highest priority to the tasks with the shortest execution time. Tasks with non-deterministic or widely variable execution time should be given lower priority. Other application specific factors also come into play such as the how a task interacts, communicates or synchronises with other tasks.