Real-Time Systems and RTOS

Introduction and Context

An embedded system is real-time when the correctness of its operation depends not only on the logical value of its output but also on the time at which that output is produced. A temperature controller that eventually switches a heater may be functionally correct in an ordinary computing sense; it may be unsafe in an industrial process if the switching decision arrives 200 ms late. Real-time computing therefore treats time as a correctness constraint.

Real-time systems are central to IoT and embedded systems. Sensors generate events, processors execute control algorithms, communication networks transport data, and actuators affect the physical environment. These activities must often be coordinated under deadlines while the system operates with limited processor, memory, energy, and communication resources. A real-time operating system (RTOS) supplies scheduling, synchronization, timing, communication, and resource-management mechanisms for this purpose.

The term real-time does not mean “fast.” It means predictably timely. A slower system with a bounded and acceptable response time may be more suitable than a faster system with unpredictable delays.

Learning Objectives

After completing this chapter, the learner should be able to:

1. Distinguish hard, firm, and soft real-time requirements.
2. Model tasks, jobs, events, deadlines, periods, and response times.
3. Explain interrupt handling, context switching, scheduling, and priority inversion.
4. Analyse schedulability using utilization and response-time methods.
5. Compare major RTOS kernel services and design choices.
6. Develop a robust task architecture for an IoT-enabled embedded product.
7. Evaluate timing, safety, security, energy, and maintainability trade-offs.

1. Foundations of Real-Time Computing

1.1 Temporal correctness

A real-time task is a recurring or event-triggered computation. A job is one execution instance of a task. Important timing parameters include:

A task is schedulable when every job completes by its deadline under the stated workload, hardware, operating-system, and interference assumptions. The basic condition is:

Here, R and D must be measured from the same release event and expressed in the same time unit. This condition is necessary for deadline compliance, but calculating R requires an appropriate scheduling model.

1.2 Classes of real-time systems

Hard real-time: Missing a deadline can cause unacceptable failure, such as an airbag deployment decision or a protection relay trip.

Firm real-time: A late result has no value, although an occasional missed deadline may be tolerated. A stale sensor sample in a motion-control loop may be discarded.

Soft real-time: Late results reduce quality but do not usually cause catastrophic failure, as in video streaming or a cloud dashboard.

These categories describe consequences, not processor speed. A soft real-time system may still require low average latency, while a hard real-time system must demonstrate bounded worst-case behaviour.

1.3 Event latency and timing chain

End-to-end latency includes more than task execution. A useful decomposition is:

The terms represent sensing, interrupt recognition, task release, queueing, computation, network, and actuation delays. This is a system-level model rather than a universal identity: terms must be defined for the particular architecture, and some may overlap or be absent. The units must be consistent, and worst-case rather than average values are required for hard guarantees.

For a distributed IoT control loop, a locally schedulable controller can still violate its deadline because of wireless retransmissions, gateway buffering, clock drift, or cloud-service delay. Safety-critical control should therefore avoid dependence on unbounded cloud latency.

2. RTOS Architecture and Kernel Services

An RTOS is a software layer that manages processor time and system resources in a manner intended to provide deterministic or sufficiently predictable timing. Common components are:

• Scheduler: selects the runnable task.
• Task or thread manager: creates, suspends, resumes, and terminates execution contexts.
• Interrupt subsystem: responds to hardware events.
• Inter-task communication (IPC): provides queues, mailboxes, event flags, and notifications.
• Synchronization: provides mutexes, semaphores, and atomic operations.
• Time services: provide ticks, timers, delays, and timeouts.
• Memory management: controls stacks, pools, heaps, and buffers.
• Device and network services: integrate drivers and protocol stacks.

A typical RTOS is preemptive: a higher-priority ready task can interrupt a lower-priority task. A cooperative RTOS switches tasks only when a task yields, blocks, or explicitly invokes the scheduler. Preemption generally improves response to urgent events, but increases context-switch overhead and synchronization complexity.

2.1 Interrupt service routines

An interrupt service routine (ISR) should acknowledge the hardware, capture essential data, record a timestamp if necessary, and signal a task. Lengthy computations, blocking operations, dynamic allocation, and complex protocol processing should normally be performed in task context. This division reduces interrupt latency and makes timing analysis more tractable.

The top half/bottom half pattern expresses this division: the top half is the short ISR, while the bottom half is a deferred task or handler. An ISR-to-task notification can be faster and more deterministic than placing all processing in an interrupt routine.

2.2 Context switching

A context switch saves the state of the current task—such as registers, stack pointer, and program counter—and restores another task’s state. Its cost depends on processor architecture, floating-point state, cache effects, memory protection, and RTOS implementation. Context-switch time must be included in timing analysis when it is significant.

2.3 Tasks, states, and priorities

A task commonly moves among these states:

1. Running: currently executing.
2. Ready: eligible to execute but waiting for the processor.
3. Blocked: waiting for an event, message, resource, or timeout.
4. Suspended: excluded from scheduling until explicitly resumed.

Priority is a scheduling attribute, not a measure of business importance alone. It should reflect timing urgency and the consequences of delay. A low-priority logging task must not share a priority with a safety-critical control task merely because both are functionally important.

2.4 Communication and synchronization

A queue transfers data and usually provides buffering. A binary semaphore is commonly used for event signaling, although its exact semantics depend on the RTOS. A mutex protects ownership of a shared resource and can support priority inheritance. Event flags represent one or more conditions, while a direct task notification can efficiently signal a particular task.

Shared data should be protected by an appropriate mechanism. Disabling interrupts for long periods is not a general synchronization strategy because it increases interrupt latency and can cause missed events. Lock-free or wait-free structures may be appropriate, but they require careful memory-ordering and atomicity analysis.

3. Scheduling Theory

3.1 Processor utilization

For n independent periodic tasks on one processor, utilization is:

where C_i is the WCET and T_i is the period of task i. C_i/T_i is dimensionless because both quantities have time units. This expression assumes one processor, periodic releases, and that execution demand is represented by C_i.

If U > 1, the processor demand exceeds capacity and the task set cannot be schedulable on one processor under the stated model. However, U ≤ 1 does not guarantee schedulability because deadlines, priorities, blocking, release jitter, and overhead also matter.

3.2 Rate Monotonic Scheduling

Rate Monotonic (RM) scheduling assigns higher priority to tasks with shorter periods. For n independent periodic tasks with implicit deadlines (D_i = T_i), fixed priorities, preemption, negligible overhead, and suitable release assumptions, the Liu–Layland sufficient bound is:

As n approaches infinity, the bound approaches approximately 0.693. The bound is sufficient, not necessary: a task set exceeding it may still be schedulable.

For two tasks, the bound is approximately 0.828. Consider C₁ = 1 ms, T₁ = 5 ms, C₂ = 2 ms, and T₂ = 10 ms. Then:

Since 0.6 ≤ 0.828, the task set passes the sufficient RM test. This result does not eliminate the need to account for RTOS overhead, non-periodic work, and actual deadlines.

3.3 Earliest Deadline First

Earliest Deadline First (EDF) dynamically assigns the highest priority to the ready job with the earliest absolute deadline. Under ideal assumptions for independent preemptive tasks on one processor with deadlines equal to periods, the utilization condition is:

EDF can achieve higher processor utilization than fixed-priority scheduling, but its implementation and overload behaviour may be less straightforward in a small embedded RTOS. Many commercial microcontroller RTOS designs use fixed priorities because they simplify analysis and certification.

3.4 Fixed-priority response-time analysis

For a task i under fixed-priority preemptive scheduling, a common iterative response-time equation is:

Here, hp(i) is the set of higher-priority tasks, B_i is the maximum blocking time, and k indexes iterations. Start with R_i^(0) = C_i + B_i and iterate until the value stops changing or exceeds D_i. The task is schedulable if the converged R_i ≤ D_i.

This analysis assumes known WCETs, a defined priority order, preemptive scheduling, bounded blocking, and a workload model compatible with the equation. Context-switch, interrupt, release-jitter, and other overheads must be incorporated into C_i, B_i, or additional terms.

For example, let task 1 have C₁ = 1 ms and T₁ = 5 ms, and task 2 have C₂ = 2 ms, T₂ = 10 ms, with task 1 higher priority and no blocking. For task 2:

• R₂⁽⁰⁾ = 2 ms.
• R₂⁽¹⁾ = 2 + ⌈2/5⌉×1 = 3 ms.
• R₂⁽²⁾ = 2 + ⌈3/5⌉×1 = 3 ms.

Thus R₂ = 3 ms. If D₂ = 10 ms, task 2 meets its deadline in this simplified model.

3.5 Aperiodic and sporadic work

A periodic task executes at regular intervals. A sporadic task has a minimum inter-arrival time but irregular releases. An aperiodic task has no known minimum interval. Servers such as periodic, polling, or sporadic servers regulate aperiodic execution so that it cannot indefinitely interfere with periodic tasks.

4. Resource Sharing and Priority Inversion

Priority inversion occurs when a high-priority task waits for a resource held by a low-priority task, while one or more medium-priority tasks prevent the low-priority task from running and releasing the resource. This can produce unbounded or unexpectedly long blocking.

Two important protocols are:

• Priority inheritance: the resource-holding task temporarily inherits the priority of the highest-priority blocked task.
• Priority ceiling: a task accessing a resource executes at a predefined ceiling priority, subject to protocol rules.

Priority inheritance limits inversion but does not automatically prove that all deadlocks are impossible. Mutexes should be acquired in a consistent global order, held briefly, and never used around unbounded I/O. Resource access time contributes to B_i in response-time analysis.

5. Time, Clocks, and Determinism

RTOS time is often represented by periodic clock ticks. With tick frequency f_tick, the nominal tick interval is:

If f_tick = 1 kHz, T_tick = 1 ms. A tick-based delay may have quantization error and may be affected by when the delay request occurs relative to a tick boundary. Tickless operation suppresses unnecessary ticks during idle periods, improving energy efficiency, but requires accurate hardware timers and careful wake-up programming.

A monotonic clock measures elapsed time and must not move backward when calendar time is adjusted. A real-time clock (RTC) maintains civil time but may be corrected by synchronization services. Control deadlines should normally use a monotonic clock, whereas timestamps for records may use synchronized civil time.

Clock drift matters in distributed IoT systems. If two devices have different oscillator frequencies, their local clocks gradually diverge. Timestamping, synchronization protocols, bounded communication delay, and time-triggered designs must be selected according to the required accuracy.

6. Memory, Reliability, and Security

Dynamic memory allocation can introduce fragmentation and unbounded allocation time. Safety-oriented systems commonly use static allocation, fixed-size memory pools, bounded queues, and compile-time stack sizing. Stack overflow detection, guard regions, high-water marks, and runtime assertions are valuable diagnostics.

A real-time design must distinguish average performance from worst-case performance. Cache misses, flash wait states, bus contention, interrupt nesting, DMA transfers, and thermal frequency scaling can all change execution time. WCET estimation may combine measurement with static analysis; measurement alone cannot prove a maximum unless operating conditions are comprehensively bounded.

Security is also a timing concern. Cryptographic operations, secure boot, authentication, and key storage consume processor time and memory. Conversely, an attacker may exploit timing, resource exhaustion, priority abuse, or malformed packets to cause deadline misses. Secure design should authenticate firmware, isolate privileges, validate inputs, rate-limit network activity, and reserve resources for critical tasks.

A useful architectural principle is mixed-criticality separation. Safety-critical control, non-critical logging, and network-facing services should be isolated through priorities, memory protection, partitions, watchdog policies, and controlled communication paths. A compromised dashboard task should not be able to overwrite actuator commands.

7. RTOS Design Process for IoT Devices

A disciplined design process is more effective than assigning priorities informally.

Step 1: Define requirements and deadlines

For each function, specify trigger, data age, deadline, consequence of lateness, execution demand, and allowable jitter. Requirements should be stated at the system boundary—for example, “the valve command shall be updated within 20 ms of a valid pressure sample”—rather than only as implementation details.

Step 2: Build a timing and resource model

List periodic, sporadic, and aperiodic tasks. Estimate WCET under documented hardware conditions. Identify shared resources, interrupt sources, communication paths, and maximum packet or burst rates.

Step 3: Select task boundaries

A task should represent a coherent activity with a clear triggering event and timing requirement. Excessive task fragmentation creates context-switch overhead and synchronization complexity; excessively large tasks make responsiveness and testing difficult.

Step 4: Assign priorities and analyse schedulability

Use RM, deadline-based reasoning, or a formal response-time analysis. Include blocking and operating-system overhead. Recalculate after changes to drivers, protocol stacks, clock frequency, or compiler settings.

Step 5: Implement bounded communication

Prefer fixed-size buffers and bounded queues for critical paths. Define what happens when a queue is full: discard oldest data, discard newest data, overwrite safely, apply backpressure, or enter a fault state. This policy is part of system behaviour, not merely an implementation detail.

Step 6: Measure and verify

Use trace tools, GPIO timing markers, cycle counters, logic analysers, and RTOS statistics to measure response distributions. Test maximum interrupt rates, full queues, simultaneous events, communication loss, brownouts, and recovery. Stress tests reveal problems; formal analysis and documented assumptions support guarantees.

8. Applied Case: Illustrative Smart Irrigation Controller

Background

Consider an illustrative IoT irrigation controller for a greenhouse. A microcontroller reads soil moisture, controls a pump and valve, detects leaks, and periodically reports data through a gateway. Cloud analytics recommend long-term watering schedules, but immediate safety decisions remain local.

Problem

The initial prototype performs sensor reading, MQTT communication, display updates, logging, and pump control in a single loop. During wireless retransmission, the loop delays leak detection. A blocked network call can therefore allow the pump to run beyond its safe interval.

Analysis

The system is decomposed into the following activities:

Ignoring overhead temporarily, utilization is:

The processor demand is approximately 8.3 percent under the stated nominal model. This low utilization does not by itself prove safety; interrupt bursts, sensor-driver delays, queue blocking, and worst-case communication processing must still be bounded.

Approach and solution

The leak sensor ISR records the event and notifies the leak-monitor task. The task immediately closes the valve and disables the pump through a protected actuator interface. Pump control uses a periodic task and a watchdog timeout. Telemetry places data in a bounded queue; the network task can drop non-critical reports when the queue is full. The cloud may modify a schedule only after local validation of limits.

The actuator interface uses a mutex with priority inheritance, and all tasks acquire shared resources in the same order. Network operations are non-blocking or executed in the low-priority network task. The watchdog is serviced only by a supervisory task after critical tasks report healthy execution, rather than being refreshed unconditionally by any loop.

Outcome

The architecture prevents a delayed MQTT transaction from directly delaying leak response. Trace measurements verify interrupt-to-valve-command latency under sensor, logging, and network stress. The design also provides a clear degraded mode: if communication fails, local control continues with the last validated schedule and conservative safety limits.

Learning points

1. Local safety actions should not depend on cloud availability.
2. Low average utilization does not replace worst-case analysis.
3. Bounded queues require an explicit overflow policy.
4. Watchdogs are most useful when they monitor system progress rather than merely processor activity.
5. RTOS structure should express safety and timing requirements directly.

9. Contemporary Developments and Critical Evaluation

Modern microcontrollers increasingly provide memory protection units, multiple cores, hardware security modules, low-power timers, and real-time communication peripherals. Some RTOS platforms support symmetric or asymmetric multicore operation, but multicore analysis introduces shared-cache, bus, memory, and inter-core-interrupt interference. Simply adding a second core does not guarantee better deadline compliance.

Time-sensitive networking, deterministic Ethernet, and industrial wireless standards seek bounded communication latency, although the guarantee depends on configuration, traffic shaping, redundancy, and environmental conditions. Edge computing reduces cloud round-trip time and improves data privacy, but edge nodes still require local scheduling and fault management.

AI inference at the edge is increasingly used for anomaly detection and predictive maintenance. Inference execution time, accelerator contention, model updates, and confidence failures must be treated as bounded resources. A machine-learning prediction should not replace a deterministic safety interlock unless the complete safety argument supports it.

Standards and governance depend on application domain. Automotive, medical, aviation, industrial, and consumer products have different assurance expectations. Relevant engineering practice includes requirements traceability, hazard analysis, configuration control, independent verification, secure update procedures, and documented evidence of timing assumptions. Compliance with a standard cannot be claimed merely because an RTOS is marketed as “real-time.”

Challenges and Limitations

Real-time analysis is limited by uncertain WCET, asynchronous events, hardware variability, network nondeterminism, and incomplete workload models. Wireless links may experience interference and retransmissions. Garbage collection, dynamic memory, uncontrolled logging, and unbounded loops can undermine deterministic behaviour. Priority analysis can also become invalid when tasks change execution modes.

A practical engineering solution is to identify assumptions explicitly, measure representative worst cases, impose resource bounds, isolate critical functions, and define safe behaviour when assumptions fail. Determinism is achieved by architecture, implementation discipline, verification, and operational monitoring—not by the RTOS label alone.

Best-Practice Checklist

• Specify deadlines and consequences of misses.
• Use monotonic time for elapsed-time decisions.
• Keep ISRs short and defer substantial work.
• Estimate and document WCET and blocking times.
• Avoid unbounded dynamic allocation in critical paths.
• Use mutexes for ownership and semaphores or notifications for events.
• Analyse priority inversion and deadlock risks.
• Bound queues, retries, packet sizes, and execution loops.
• Separate safety-critical control from network-facing code.
• Test overload, communication failure, power interruption, and recovery.
• Treat security controls and firmware updates as timing and resource concerns.
• Maintain traceable evidence from requirements through verification.

Chapter Summary

Real-time systems require temporal as well as logical correctness. Hard, firm, and soft real-time classifications express the consequences of deadline misses. RTOS kernels support task scheduling, interrupts, synchronization, communication, timing, and memory management, but they do not automatically guarantee determinism.

Utilization provides an initial workload measure, while RM, EDF, and response-time analysis provide increasingly informative schedulability reasoning under stated assumptions. Priority inversion, blocking, interrupt latency, context-switch overhead, clock behaviour, memory allocation, communication delay, and security events must be included in a credible design argument. In IoT systems, local control should remain safe despite cloud or network failure. A successful RTOS architecture combines bounded implementation, formal or semi-formal analysis, measurement, fault handling, and lifecycle governance.

Key Terms

Real-time system: A system whose correctness depends on both result and timing.

RTOS: An operating system designed to provide predictable services for time-constrained applications.

Hard real-time: A system in which unacceptable consequences may follow a missed deadline.

Firm real-time: A system in which a late result is useless, although occasional loss may be tolerated.

Soft real-time: A system in which lateness degrades performance or quality.

Task: A schedulable computational activity.

Job: One execution instance of a task.

WCET: Worst-case execution time under defined assumptions.

Deadline: Latest acceptable completion time relative to job release.

Response time: Time from job release until completion.

Jitter: Variation in release, completion, or communication timing.

Preemption: Temporarily interrupting one task to execute another.

ISR: Interrupt service routine that responds to a hardware event.

Mutex: Mutual-exclusion mechanism providing ownership of a shared resource.

Priority inversion: Delay of a high-priority task due to lower-priority resource ownership.

Priority inheritance: Protocol that temporarily raises a resource holder’s priority.

Schedulability: Ability of a workload to meet all specified timing constraints.

Utilization: Fraction of processor capacity demanded by tasks.

Monotonic clock: An elapsed-time clock that does not move backward.

Mixed criticality: Architecture combining functions with different assurance and timing requirements.

Review Questions

Short Answer Questions

1. Why is a real-time system not necessarily a fast system?
2. Distinguish a task from a job.
3. What is the purpose of a mutex?
4. Why should lengthy processing usually be deferred from an ISR?
5. What does processor utilization indicate, and what does it fail to prove?

Long Answer Questions

1. Explain RTOS architecture and discuss the roles of the scheduler, interrupt subsystem, IPC, synchronization, and time services.
2. Derive and interpret the fixed-priority response-time analysis equation, including the assumptions required for its use.
3. Compare Rate Monotonic and Earliest Deadline First scheduling in terms of priority assignment, utilization, implementation, and overload behaviour.
4. Discuss priority inversion, priority inheritance, priority ceiling, and deadlock prevention in embedded systems.
5. Design an RTOS architecture for an IoT actuator system that must remain safe during network failure. Justify task boundaries, priorities, communication, and verification methods.

Analytical / Application Questions

1. Three independent periodic tasks have (C, T) values of (1 ms, 10 ms), (2 ms, 20 ms), and (3 ms, 50 ms). Calculate utilization and determine whether the task set passes the asymptotic RM sufficient bound for three tasks. State why the result is not a complete proof.
2. A high-priority control task is delayed by a low-priority logging task holding a shared mutex, while a medium-priority communication task repeatedly executes. Analyse the priority inversion and propose a corrected synchronization design.
3. For a connected medical sensor, identify which functions should remain local rather than cloud-dependent. Construct an end-to-end latency budget and explain how you would validate it under worst-case network and processor load.

Multiple Choice Questions with Answers

Question 1

Which statement best defines a hard real-time system?

A. It always uses the fastest available processor.

B. A missed deadline can produce unacceptable system failure.

C. It processes only periodic tasks.

D. It never uses interrupts.

Correct Answer: B. A missed deadline can produce unacceptable system failure.

Question 2

For a single processor, what does U = ∑ C_i/T_i represent?

A. Memory fragmentation

B. Network throughput

C. Processor utilization

D. Clock drift

Correct Answer: C. Processor utilization

Question 3

Under Rate Monotonic scheduling, which task receives higher priority?

A. The task with the shortest period

B. The task with the longest period

C. The task with the largest stack

D. The task released most recently

Correct Answer: A. The task with the shortest period

Question 4

What is the principal purpose of priority inheritance?

A. To reduce sensor noise

B. To prevent all interrupts

C. To increase network bandwidth

D. To limit priority inversion caused by resource sharing

Correct Answer: D. To limit priority inversion caused by resource sharing

Question 5

For f_tick = 1 kHz, what is the nominal tick interval?

A. 0.001 ms

B. 0.1 ms

C. 1 ms

D. 1000 ms

Correct Answer: C. 1 ms

Question 6

Which operation is generally inappropriate inside a time-critical ISR?

A. Acknowledging the interrupt source

B. Recording essential status

C. Performing an unbounded network transaction

D. Signalling a waiting task

Correct Answer: C. Performing an unbounded network transaction

Question 7

In the response-time equation, B_i most commonly represents:

A. Blocking due to lower-priority resource use

B. The task’s period

C. The processor clock frequency

D. The number of input bytes

Correct Answer: A. Blocking due to lower-priority resource use

Question 8

Why is a monotonic clock preferred for measuring task elapsed time?

A. It automatically encrypts timestamps.

B. It does not move backward when civil time is adjusted.

C. It always has nanosecond accuracy.

D. It eliminates execution-time variation.

Correct Answer: B. It does not move backward when civil time is adjusted.

Question 9

A task has C = 2 ms and T = 10 ms. Its utilization is:

A. 0.02

B. 0.2

C. 2

D. 20

Correct Answer: B. 0.2

Question 10

In the illustrative irrigation controller, why is telemetry placed in a bounded queue?

A. To make cloud latency zero

B. To guarantee unlimited storage

C. To provide an explicit, controlled response when reports accumulate

D. To eliminate the need for task priorities

Correct Answer: C. To provide an explicit, controlled response when reports accumulate