A real-time embedded system is defined not by speed, but by guarantees: the correct result, delivered too late, is just as wrong as an incorrect result. This lecture formalizes exactly what "in time" means - from the sensor-decision-actuator chain and the temporal parameters of a task, to the states of an RTOS task, context switching, and two classic scheduling algorithms (Rate Monotonic and Earliest Deadline First) with their schedulability tests.
1The subject and structure of the lecture6 min
"Real-time system" does not mean "fast system" - it means a system whose guarantees are temporal, not merely logical. A very fast system, but with no guarantee at all about the worst case possible, is not a real-time system; a slow system, but with a demonstrated maximum limit that is always respected, is.
- Hard real-time systems: missing the deadline produces failure or danger
- Firm real-time systems: missing it occasionally reduces performance, without failure
- Soft real-time systems: delays affect the quality of service, not the operation
Learning outcomes
- To distinguish the logical from the temporal correctness of a system
- To break down the end-to-end latency of a sensor-decision-actuator chain into its components
- To describe the temporal parameters of a task (C, T, D, J) and its states in an RTOS
- To compute processor utilization and apply the Liu-Layland bound for RMS
- To apply EDF and explain the difference from fixed-priority scheduling
- To estimate the cost of context switching and its impact on CPU utilization
2Logical and temporal correctness10 min
correctness = logical_correctness + temporal_correctness. Logical
correctness shows that the algorithm produces the desired result; temporal correctness shows that the
result is produced within the interval in which it is still useful.A command computed perfectly correctly, but applied with a delay Δt, becomes
u_applied(t) = u_computed(t - Δt) - if Δt exceeds the limit accepted by the process being
controlled, the operation may become unstable or dangerous, however "correct" the computation was.
T_execution ≤ T_execution,max and
R_i ≤ D_i (the response time under the relative deadline) - not merely a good average time.
The average time is useful for general performance, but it does not demonstrate that the deadline is
met.A control function runs 1000 times. In 999 cases, R = 0.5 ms; in a single case, R = 25 ms. The average
is (999×0.5 + 25)/1000 ≈ 0.5245 ms - very good. If the deadline is 5 ms, that single value of
25 ms missed the deadline, however good the average looks. Temporal analysis has to be done for the
most unfavourable credible scenario, not for the average case measured during development.
Typical sources of temporal variation: interrupt latency, the time spent blocked on shared resources, the context-switching time, the interference produced by higher-priority activities, and the variation introduced by hardware (cache, branch prediction) and software.
3The reactive system and the sensor-decision-actuator chain10 min
Real-time embedded systems are, almost always, reactive systems: they do not carry out an isolated computation, but respond continuously to changes in the physical environment, through a chain: the physical process → sensors → acquisition and conditioning → estimation/decision/control → actuators → feedback to the process.
T_end-to-end = T_sensor + T_acquisition + T_communication + T_waiting +
T_computation + T_actuatorD_control = D_sensor + D_transfer + D_software + D_actuator + margin.A robot detects an obstacle at d = 0.5 m, at a speed of v = 1 m/s. The ideal time available until
impact: T_available = d/v = 0.5 s. From that interval must be subtracted the braking time, the
delay of the actuator, the acquisition of the sensor and the safety margin - the software does not
have the whole half second in which to take the decision.
The events that trigger a reactive system may be periodic (a control loop every 10 ms), sporadic (the occurrence of an error), aperiodic (a command from the user) or synchronous/asynchronous with respect to the processor clock - the type of activation directly influences the software architecture and the scheduling method chosen, the subject of the following sections.
4Fields of application and verifiable requirements6 min
The level of criticality and the consequences of delays differ radically between fields: in automotive (braking, engine control, airbag), a delay may cost lives; in multimedia applications, occasionally missing a deadline produces only the loss of a visible frame, with no safety consequences.
"The system must respond quickly" cannot be verified. "For every activation of the protection function, the actuator command must be generated within a maximum of 2 ms, under all the operating conditions defined" can - it states the start event, the end event, the temporal limit, the operating conditions and the behaviour when the limit is exceeded.
Always state temporal requirements quantitatively, verifiably - "fast enough" is not a specification, it is an intention.
5The temporal parameters of a task10 min
A real-time software activity is modelled formally as a task τᵢ, with four basic parameters:
τᵢ = (Cᵢ, Tᵢ, Dᵢ, Jᵢ), where:Cᵢ = the execution time in the worst case (WCET);
Tᵢ = the period, or the minimum interval between activations;
Dᵢ = the relative deadline;
Jᵢ = the activation jitter.
| Term | Meaning |
|---|---|
| Determinism | the guarantee that the system meets a known temporal limit, not merely "usually" |
| Latency | the time between an event and the system's reaction to it |
| Jitter | the variation of the latency between successive activations of the same activity |
6The role and structure of a real-time operating system8 min
An RTOS (Real-Time Operating System) offers the application a level of abstraction over the hardware: tasks, synchronization, inter-task communication, management of time and of interrupts - without the developer having to reimplement those mechanisms from scratch for every project.
Three central components of an RTOS:
- The kernel - the core that manages the tasks, the memory and the synchronization; it offers the basic primitives (creating a task, semaphores, message queues, timers).
- The scheduler - decides which task runs, at each decision moment, on the basis of the scheduling policy (the central subject of this lecture).
- The dispatcher - actually carries out the context switch, applying the decision of the scheduler: it saves the context of the current task, restores the context of the new task, resumes execution.
Not every real-time embedded system needs an RTOS - for simple applications, with few concurrent activities, a bare-metal main loop (superloop), with interrupts for the urgent events, can meet the temporal requirements perfectly, at a far lower complexity. An RTOS becomes advantageous when the number of concurrent activities, with different priorities and periods, grows enough that managing them by hand becomes fragile.
7The states of a task and context switching11 min
A task does not run permanently - it passes through several states during its existence.
| State | Meaning |
|---|---|
| Running | the task is executing instructions on the processor (at most one, on a single core) |
| Ready | ready to run, but the processor is occupied by another task |
| Blocked | waiting for an event (a message, a semaphore, data, a timer, a resource) |
| Suspended | explicitly excluded from scheduling - resuming requires a dedicated operation, not merely a timeout |
The transition Running → Blocked occurs when the task requests an operation that cannot be
completed immediately. When the awaited event occurs, Blocked → Ready - but not
automatically into Running: the unblocked task joins the list of ready tasks, and its execution depends on
priority. If the priority of the unblocked task exceeds that of the current one
(p_unblocked > p_current), a pre-emptive scheduler can interrupt the current task at
once.
A task waiting for an event should, almost always, use a timeout as well - blocking indefinitely is
not acceptable if the awaited event may never arrive (a lost message, a faulty peripheral). Just as
important: a task must not wait actively for an event in a loop
(while(!data_available()){}) - that keeps it Ready/Running, consuming processor time and
blocking tasks of equal or lower priority, exactly the opposite of the purpose for which the Blocked
state exists.
Context switching and its cost
A context switch saves the complete state of the current task (registers, program counter, stack pointer, status register) and restores it for the newly selected task - a real cost, which executes no useful functionality of the application.
U_switch = N_switch × C_switch / TA system makes 5000 context switches per second, each lasting 5 µs. What fraction of the processor is lost purely on the switching overhead?
See the solution
T_switch_total = 5000 × 5 µs = 25 ms per second.
U_switch = 25 ms / 1000 ms = 2.5%
2.5% of the capacity of the processor is lost exclusively on context switching, before counting the time spent in the scheduler and in handling interrupts. Reducing the number of excessively fragmented tasks, avoiding over-small time slices and grouping activities reduce that loss directly - but not at the expense of the clarity of the architecture or of the isolation of critical functionality.
8Concurrency, parallelism and pre-emption6 min
Three concepts often confused: concurrency (several activities logically active in the same interval, whether or not they run at the very same moment), parallelism (execution at the very same moment, on different cores) and pre-emption (a task being forcibly interrupted by the scheduler, in favour of one with a higher priority).
On a single-core microcontroller, the tasks are concurrent, but not parallel - the illusion of simultaneity comes from switching rapidly between them. Pre-emption is the mechanism that makes meeting deadlines possible: without it, a low-priority task, once started, would block critical, higher-priority tasks until it finished.
9Scheduling strategies9 min
The scheduling policy decides, at every relevant moment, which Ready task becomes Running.
| Strategy | Principle | Suited to |
|---|---|---|
| Priority scheduling (fixed) | the Ready task with the highest priority runs | systems with clearly differentiated criticality |
| Round Robin | tasks of the same priority take turns, each with a fixed time slice | fairness between similar tasks |
The overhead of the scheduling itself (the time spent by the scheduler in deciding, not merely in switching the context) has to be included in any rigorous analysis - a scheduling algorithm that is "optimal" on paper, but too costly to run, may be impractical on a microcontroller with limited resources. The relevant design criteria: predictability, the ease of formal analysis, the implementation overhead and the behaviour under overload (what exactly happens when the system can no longer meet all the deadlines).
10The task model, utilization and the hyperperiod4 min
For a set of n periodic tasks Γ = {τ1,...,τn}, each with a utilization
Uᵢ = Cᵢ/Tᵢ, the total utilization is U = Σ Uᵢ.
U ≤ 1 is necessary for any set of independent periodic tasks on a single processor - but it is
not sufficient for every scheduling algorithm. A set with U = 0.5 is not automatically schedulable -
it depends on the scheduling policy used, exactly the subject of the next two sections.The interval after which the pattern of activations repeats completely is the hyperperiod:
H = lcm(T1,...,Tn) - useful for constructing a complete scheduling diagram on small examples,
but it quickly becomes impractical when the periods are numerous or are not multiples of one another.
11Rate Monotonic Scheduling and the Liu-Layland bound11 min
Rate Monotonic Scheduling (RMS) is a fixed-priority strategy: the smaller the period of a
task, the higher its priority (Tᵢ < Tⱼ ⟹ pᵢ > pⱼ). Under the assumptions of the classic
model (independent periodic tasks, a single processor, pre-emptive scheduling, deadline = period,
negligible kernel costs), RMS is optimal among fixed-priority algorithms: if a set can be scheduled
by any assignment of fixed priorities, it can be scheduled by Rate Monotonic as well.
U ≤ n(2^(1/n) - 1). For
n → ∞: U_LL → ln 2 ≈ 69.3%.| Number of tasks | U_LL |
|---|---|
| 1 | 100.0% |
| 2 | 82.8% |
| 3 | 78.0% |
| 4 | 75.7% |
| 5 | 74.3% |
| ∞ | 69.3% |
τ1=(1,5,5), τ2=(2,10,10), τ3=(4,40,40). Is the set guaranteed schedulable by RMS?
See the solution
U = 1/5 + 2/10 + 4/40 = 0.2 + 0.2 + 0.1 = 0.5
U_LL(3) = 3(2^(1/3) - 1) ≈ 0.780
Since 0.5 < 0.780, the set is guaranteed schedulable by RMS, under the assumptions of the
classic model.
Experiment by raising C₁ in the widget until U exceeds the Liu-Layland bound for 3 tasks (0.780) - watch whether τ3 (the lowest priority) starts missing deadlines.
12Earliest Deadline First10 min
Earliest Deadline First (EDF) uses dynamic priorities: at every decision moment, the Ready
task with the nearest absolute deadline runs - J* = argmin(dᵢ,ₖ). The priority of a task can
change from one instance to the next, because absolute deadlines evolve over time.
U ≤ 1. EDF can use
theoretically 100% of the capacity of the processor for that model - a clear advantage over the
~69.3% bound of RMS.The simple condition U ≤ 1 is not sufficient for all variants of EDF - if the deadlines are shorter than the periods (D < T), a finer analysis of the processor demand over intervals is needed, beyond the scope of this introductory lecture.
13Frequent mistakes5 min
- "A good average execution time means a correct real-time system." False - a system may have an excellent average and still occasionally miss critical deadlines. The analysis has to be done for the worst case, not for the average. Always ask for the WCET (Worst-Case Execution Time), not merely a measured average time.
- "U ≤ U_LL (RMS) and U ≤ 1 (EDF) are conditions of equivalent strength." They are not - U_LL is only sufficient (conservative) for RMS; U ≤ 1 is necessary and sufficient for EDF, in the classic model. EDF can schedule sets that the simple RMS test rejects, although both may be schedulable by RMS after a finer analysis. Do not compare the two thresholds directly without stating what each of them tests.
- "A task blocked in a while(!condition){} saves complexity compared with using a semaphore/message." Active waiting keeps the task Ready/Running, consuming the processor uselessly and possibly blocking tasks of equal or lower priority - exactly the opposite of the intention. Use the blocking mechanisms offered by the RTOS (semaphores, message queues, with a timeout) instead of busy-waiting loops.
14Summary and glossary5 min
Temporal correctness is as important as logical correctness, and the guarantees have to be demonstrated for the worst case, not for the average. A task is modelled by (C, T, D, J), passes through the states Running/Ready/Blocked/Suspended, and context switching has a real, measurable cost. Rate Monotonic Scheduling offers simple fixed priorities, with a conservative schedulability test (the Liu-Layland bound, ~69.3% for many tasks); Earliest Deadline First offers dynamic priorities, with the optimal test U ≤ 1, but with less predictable behaviour under overload. Choosing between them is, as always in this field, a compromise between simplicity/predictability and maximum theoretical utilization.
15Self-check questions6 min
- What is the difference between the logical and the temporal correctness of a system?
- List the components of the end-to-end latency of a sensor-decision-actuator chain.
- What are the four main states of a task and the transitions between them?
- Why is active waiting (busy-waiting) not recommended in an RTOS task?
- What is the sufficient schedulability condition (Liu-Layland) for RMS with 4 tasks?
- What do "dynamic priorities" mean in the context of EDF?
- Why can EDF theoretically use 100% of the processor, unlike RMS?
16Where to go next2 min
The next lecture continues directly along this thread: how tasks that share resources are synchronized (semaphores, mutexes), what priority inversion is and what a real RTOS such as FreeRTOS or Zephyr looks like at kernel level.
All the concepts of this lecture - task states, context switching, RMS, EDF - become real code running on hardware in Laboratory 03, where you configure an RTOS on an open-source watch with PineTime and InfiniTime.