Real-Time Systems and RTOS

Introduction and Context

A mechatronic system combines mechanical components, sensors, actuators, electronics, and software. In such systems, producing the correct result is only part of correctness: the result must often be produced before a specified time. A motor controller that computes an accurate torque command after the motor has already moved may be functionally wrong. A collision-avoidance controller that responds too late may be unsafe even if its algorithm is mathematically correct.

A real-time system is therefore a system whose correctness depends on both logical results and their timing. Real-time computing is not synonymous with “fast computing.” A slow system can be real-time if its timing is predictable and satisfies all deadlines; a very fast system can fail to be real-time if execution delays are unpredictable.

This chapter develops the principles required to analyze and design embedded real-time systems. It examines timing constraints, latency, jitter, deadlines, worst-case execution time, scheduling, interrupts, synchronization, resource sharing, queues, semaphores, and real-time operating systems (RTOSs). The emphasis is on practical engineering decisions in mechatronics.

Learning Objectives

After studying this chapter, the reader should be able to:

1. Distinguish hard, firm, and soft real-time requirements.
2. Analyze periods, deadlines, latency, response time, and jitter.
3. Estimate and validate worst-case execution time (WCET).
4. Apply rate-monotonic and earliest-deadline-first scheduling concepts.
5. Explain task states, preemption, interrupts, context switching, and tick timers.
6. Select and correctly use queues, mutexes, binary semaphores, counting semaphores, and event flags.
7. Identify priority inversion and apply priority inheritance or ceiling protocols.
8. Design a small RTOS-based mechatronic application and evaluate its limitations.

1. Real-Time Requirements

1.1 Hard, firm, and soft real time

A hard real-time task must meet every deadline. Missing one deadline can cause system failure, equipment damage, or unacceptable safety risk. Examples include an emergency braking command or an overcurrent shutdown.

A firm real-time task produces no useful result after its deadline, although an occasional miss may not destroy the system. A machine-vision result used to guide a pick-and-place operation may be firm real time: a late image is discarded and the next image is processed.

A soft real-time task remains useful after its deadline, but its value decreases with delay. Examples include a graphical display, diagnostic logging, or noncritical network communication.

These categories describe consequences, not processor speed. A design may contain all three types simultaneously.

1.2 Important timing terms

• Release time: the instant at which a task becomes ready.
• Arrival time: a general term for the time an event or job enters the system.
• Execution time: processor time required by a task instance.
• WCET: a safe upper bound on execution time under specified hardware and software conditions.
• Relative deadline: maximum permitted time from release to completion.
• Absolute deadline: the actual clock time by which completion is required.
• Period: time between releases of a periodic task.
• Response time: elapsed time from release until completion.
• Latency: delay between an event and the beginning, or sometimes completion, of its response. The definition must be stated explicitly.
• Jitter: variation in a timing quantity, such as release time, sampling interval, or response time.
• Slack: time remaining between completion and the deadline.

For a task with release time r, completion time f, and absolute deadline d, response time is:

and slack is:

Both R and S have units of time. A task meets its deadline when f ≤ d, equivalently when R ≤ d − r.

1.3 Sources of delay

A control response can be delayed by sensor conversion, communication, interrupt recognition, a higher-priority task, a disabled-interrupt section, operating-system overhead, cache or memory effects, actuator communication, and the control algorithm itself. A useful timing budget is therefore:

This is a budgeting model, not a universal identity. The terms must represent non-overlapping delays; if two activities overlap, simple addition may be conservative or inaccurate. Each term should be measured or bounded under stated operating conditions.

2. Execution Time, WCET, and Jitter

2.1 Why average execution time is insufficient

Suppose a task usually executes in 0.8 ms but occasionally requires 1.7 ms because of a communication retry. Designing with the average value can produce an apparently satisfactory system that fails intermittently. Real-time analysis uses an upper bound, not merely an average.

WCET is difficult because execution depends on branches, loop bounds, interrupts, compiler optimization, processor pipelines, caches, memory wait states, and input data. WCET analysis may be measurement-based, static, or hybrid.

Measurement-based analysis records many executions, including stress tests. It cannot prove that an unobserved path is impossible. Static analysis examines program paths and hardware behavior, but may be conservative and technically demanding. A defensible engineering estimate documents hardware configuration, compiler version, optimization, input assumptions, and measurement method.

If a periodic task has WCET C and period T, its utilization is:

C and T must use the same units, such as milliseconds. U is dimensionless and represents the fraction of one processor occupied by that task when it executes once each period.

2.2 Jitter

If periodic releases occur at times r₁, r₂, …, their intervals may not equal the nominal period. Release jitter can arise from interrupt timing, clock drift, communication, and preemption. Sampling jitter changes the effective sampling instant and can degrade a control loop, especially when the plant is fast or lightly damped.

A system should specify whether jitter is measured as maximum deviation from nominal timing, peak-to-peak variation, or worst-case response-time variation. These definitions are not interchangeable.

2.3 Timing budget example

Consider a position-control loop with a 2 ms period and a 1.5 ms deadline relative to sensor sampling. The measured bounds are:

The total is 1.35 ms. The remaining slack is:

The loop satisfies the stated budget only if each bound is credible and the components do not hide additional blocking or interference. The unused 0.15 ms is not automatically a guarantee; it is margin against modeled variation.

3. Scheduling Theory

A scheduler selects which ready task executes. Scheduling policy must be considered together with task priorities, preemption, resource blocking, interrupt activity, and timing assumptions.

3.1 Task models

A common periodic-task model represents task i by:

where Cᵢ is WCET, Tᵢ is period, and Dᵢ is relative deadline. The simplest analyses assume independent tasks, fixed execution times bounded by Cᵢ, negligible context-switch cost, and a single processor. Real systems often violate these assumptions, so overhead and blocking must be included.

For n periodic tasks, total utilization is:

For a single processor, U_total > 1 means the processor demand exceeds capacity under the model and deadlines cannot all be met indefinitely. U_total ≤ 1 does not by itself prove schedulability, because task priorities, deadlines, blocking, and release patterns also matter.

3.2 Rate-monotonic scheduling

Rate-monotonic (RM) scheduling assigns higher fixed priority to tasks with shorter periods. It is appropriate for many independent periodic tasks with deadlines equal to periods. A classic sufficient utilization bound for n tasks is:

This bound guarantees schedulability under the classical assumptions; it is sufficient but not necessary. As n approaches infinity, the bound approaches ln 2, approximately 0.693. For two tasks, the bound is approximately 0.828.

A task set can exceed this bound and still be schedulable; failing the test means that a more detailed analysis is required, not that the system definitely fails.

3.3 Earliest-deadline-first scheduling

Earliest-deadline-first (EDF) is dynamic priority scheduling: the ready task with the earliest absolute deadline executes first. Under ideal single-processor assumptions, independent preemptive tasks with deadlines equal to periods are schedulable when U_total ≤ 1. Practical systems must account for overhead, blocking, release jitter, nonpreemptive sections, and deadline variations.

3.4 Response-time analysis

For fixed-priority tasks, a widely used response-time recurrence is:

Here Rᵢ is the worst-case response time of task i, Cᵢ is its WCET, Bᵢ is its maximum blocking time, hp(i) is the set of higher-priority tasks, Tⱼ is the period of higher-priority task j, and ⌈x⌉ is the ceiling function. Start with Rᵢ⁽⁰⁾ = Cᵢ + Bᵢ and iterate until the value converges or exceeds Dᵢ. The equation assumes a single processor, fixed priorities, bounded execution, and a specified model of interference.

Worked example. Two tasks have priorities determined by period:

For τ₁, with no higher-priority task and no blocking, R₁ = 1 ms, so its 4 ms deadline is met.

For τ₂, assume B₂ = 0. Start with R₂⁽⁰⁾ = 2 ms:

Next:

The result converges at 3 ms, which is less than D₂ = 10 ms. The task set is schedulable under the stated assumptions. Context switches, interrupt execution, and timer overhead would need to be added to the appropriate bounds in a real implementation.

4. Interrupts, Tasks, and RTOS Operation

An interrupt is a hardware- or software-generated event that requests processor attention. An interrupt service routine (ISR) should normally acknowledge the source, capture essential data, clear or defer the event, and notify a task. Lengthy computation, blocking calls, dynamic allocation, and complex protocol processing generally belong in a task rather than an ISR.

Important interrupt metrics include:

• Interrupt latency: time from interrupt assertion to the first ISR instruction.
• ISR execution time: processor time spent in the ISR.
• Scheduling latency: delay before a notified task runs.
• Context-switch time: time to save one execution context and restore another.

An ISR may place a sensor sample into a buffer and release a high-priority processing task. This “deferred interrupt processing” keeps interrupt latency bounded and makes substantial work visible to the scheduler.

An RTOS typically provides a scheduler, task management, timers, synchronization objects, inter-task communication, and memory services. A task commonly moves among states:

1. Running: currently using the processor.
2. Ready: able to run but waiting for processor selection.
3. Blocked: waiting for time, data, an event, or a resource.
4. Suspended: deliberately removed from scheduling until resumed.

A preemptive RTOS can interrupt a running lower-priority task when a higher-priority task becomes ready. A cooperative RTOS relies on tasks to yield or block, which can reduce overhead but makes timing depend strongly on task behavior.

The RTOS tick provides a time base for delays and timeouts. Tick-based delays have finite resolution and may introduce phase or release jitter. Hardware timers and deadline-aware notification mechanisms are preferable when microsecond-level precision is required.

5. Synchronization and Resource Sharing

5.1 Queues and buffers

A queue transfers discrete messages between execution contexts. It provides ownership transfer and usually supports blocking send and receive operations. Queues are appropriate for sensor samples, commands, and structured events.

A ring buffer is efficient for streams such as serial data. Its design must define full and empty conditions, overwrite policy, and concurrent-access rules. A queue does not automatically solve data-rate mismatch: if the producer’s long-term rate exceeds the consumer’s rate, the buffer eventually overflows.

5.2 Semaphores and event flags

A binary semaphore represents an available/unavailable event or resource, but its meaning should be explicit. An ISR can give a binary semaphore to wake a task. A counting semaphore represents multiple identical units, such as free buffer slots.

A mutex is specifically a mutual-exclusion lock. Unlike a general binary semaphore, a mutex normally has ownership: the task that locks it must unlock it. This supports priority-inheritance protocols.

Event flags represent combinations of conditions, such as “ADC complete” and “communication ready.” They are useful when a task must wait for one or several events.

5.3 Critical sections and atomicity

A critical section is a region that must not be interleaved with conflicting access. Very short sections may disable interrupts or use atomic processor instructions. Excessive disabling increases interrupt latency and can cause missed deadlines. A shared variable should be protected according to its access pattern, data width, memory model, and concurrency model—not merely declared volatile.

5.4 Priority inversion

Priority inversion occurs when a high-priority task waits for a resource held by a low-priority task while medium-priority tasks execute. The high-priority task is indirectly delayed by the medium-priority tasks. Priority inheritance temporarily raises the lock-holder’s priority to that of the highest-priority waiter. A priority-ceiling protocol assigns a resource ceiling and can limit blocking and prevent some deadlock patterns.

Deadlock requires conditions such as mutual exclusion, hold-and-wait, no preemption, and circular wait. Consistent lock ordering, short ownership duration, bounded timeouts, and avoiding nested locks reduce risk.

6. Designing an RTOS-Based Mechatronic Controller

A disciplined design begins with requirements rather than with API calls.

Step 1: Identify events and consequences

List sensor events, control updates, communications, diagnostics, safety actions, and actuator commands. Mark each deadline as hard, firm, or soft.

Step 2: Define timing parameters

For every task, estimate period or minimum inter-arrival time, deadline, WCET, priority, blocking bound, and acceptable jitter. Include ISR and RTOS overhead.

Step 3: Assign responsibilities

Use ISRs for time-critical capture and immediate hardware service. Use tasks for algorithms, filtering, communication stacks, and logging. Separate safety functions from noncritical functions so that diagnostics cannot block protective action.

Step 4: Select communication mechanisms

Use queues for messages, mutexes for shared resources, semaphores for event notification, and event flags for combinations of conditions. Prefer static allocation in safety- or reliability-critical systems when the RTOS supports it.

Step 5: Analyze and test

Perform utilization and response-time analysis, then measure execution times and latency under worst credible load. Test queue overflow, task starvation, timer wraparound, communication loss, sensor faults, and overload recovery.

Example architecture

A small robotic joint controller may contain:

The encoder ISR should not perform floating-point trajectory planning or wait for a mutex. It can write a sample to a carefully protected buffer and notify the control task. The control task validates freshness, computes the command, and updates the actuator through a bounded interface. A hardware safety path should remain capable of disabling power even if the RTOS is overloaded.

7. Illustrative Case Study: Conveyor Pick-and-Place Cell

Background

This illustrative case concerns a conveyor carrying parts to a robotic pick station. An optical sensor detects each part, an encoder estimates belt position, and a servo moves the gripper. The controller uses a microcontroller and an RTOS.

Problem

The system initially uses a low-priority polling loop for sensor processing. Under heavy network traffic, the position estimate is sometimes delayed. The gripper then moves to a stale position and misses a part. Average CPU utilization is only 45%, but response-time variation is large.

Analysis

The relevant requirement is not average utilization; it is the maximum interval between detection and the corresponding actuation command. The design team measures:

• sensor-to-ISR latency: up to 40 μs;
• sample-transfer and scheduling delay: up to 110 μs;
• tracking computation: WCET 260 μs;
• actuator command transfer: up to 90 μs;
• required total response: 600 μs.

The modeled worst-case total is:

This leaves 100 μs of nominal margin. However, the network task can block the computation because both use a shared bus mutex, and the logger occasionally holds the mutex for 180 μs. Thus the true bound can become 680 μs, violating the requirement.

Approach and solution

The team applies four changes:

1. The sensor ISR captures a timestamp and posts a compact event to a queue.
2. A high-priority tracking task performs the position calculation.
3. Bus access is redesigned so the tracking task uses a bounded transaction; the logger is prevented from holding the bus during the control window.
4. The mutex uses priority inheritance, and a hardware timer supervises the actuation deadline.

The design is then tested with maximum network traffic, worst-case part arrival patterns, and deliberately slow logging. Trace instrumentation records release, start, completion, and deadline times for every tracking job.

Outcome

The measured worst-case response becomes 545 μs, below the 600 μs requirement. The system also rejects stale events using timestamps rather than processing them late. The safety supervisor stops the conveyor if the tracking task misses its deadline repeatedly.

Learning points

The case demonstrates that low average utilization does not guarantee real-time behavior. Blocking time, queue policy, priority assignment, and deadline monitoring can dominate performance. It also shows why safety functions should not depend solely on ordinary task scheduling.

8. Verification, Safety, and Professional Practice

Real-time verification combines analysis, measurement, and fault testing. Useful tools include trace analyzers, logic analyzers, cycle counters, deadline monitors, and hardware-in-the-loop test benches. Measurements should be made with instrumentation overhead characterized; otherwise the measurement can distort the timing being measured.

A watchdog should have a clear failure policy. Blindly resetting a machine may be unsafe if actuators remain energized. Watchdog recovery should place the system in a defined safe state and record diagnostic evidence.

Safety-related mechatronic systems may be governed by standards such as IEC 61508, ISO 13849, IEC 62061, or domain-specific standards. The applicable standard depends on the product and jurisdiction. Standards do not replace engineering judgment: they require traceable requirements, hazard analysis, validation, configuration control, and evidence of systematic process.

Security also affects timing. Denial-of-service traffic, malformed packets, or resource exhaustion can create deadline misses. Authentication, bounded parsing, rate limiting, privilege separation, and secure update procedures should be considered without allowing security mechanisms to create uncontrolled blocking.

Dynamic memory allocation can introduce fragmentation and unbounded allocation time. For critical tasks, static allocation or fixed-size memory pools are often preferable. Floating-point operations, cache behavior, and library calls must be included in WCET assessment rather than assumed negligible.

9. Contemporary Developments and Best Practices

Modern microcontrollers increasingly provide hardware timers, DMA, multicore processors, memory protection, and hardware-assisted tracing. These features improve capability but complicate timing analysis. DMA may reduce CPU load while introducing bus contention. Multicore systems require analysis of shared caches, interconnects, memory bandwidth, and interprocessor communication.

Machine-learning inference is appearing in vision and predictive-maintenance systems. Its execution time may vary with hardware acceleration, memory movement, and workload. A safety-critical control loop should not depend on an unbounded inference operation unless its timing and failure behavior are controlled. A practical architecture often isolates inference as a lower-criticality task and uses deterministic fallback control.

Best practices include:

• write explicit timing requirements and define measurement points;
• use WCET bounds rather than averages for hard deadlines;
• keep ISRs short and bounded;
• avoid blocking in high-priority tasks unless blocking is analyzed;
• use a documented priority assignment;
• bound queue lengths and define overflow behavior;
• protect shared resources with an appropriate protocol;
• prefer monotonic clocks for elapsed-time measurement;
• include RTOS, interrupt, communication, and instrumentation overhead;
• test overload, faults, startup, shutdown, and recovery;
• separate safety-critical and noncritical functions;
• record assumptions so that timing claims remain valid after hardware or software changes.

Chapter Summary

Real-time systems must satisfy both functional and temporal requirements. Hard, firm, and soft deadlines express different consequences of lateness. Period, execution time, WCET, response time, latency, jitter, and slack provide the vocabulary for timing analysis.

Scheduling analysis begins with task models and processor utilization but must also consider priorities, blocking, preemption, interrupts, overhead, and resource sharing. Rate-monotonic scheduling uses fixed priorities based on period; EDF selects the earliest absolute deadline. Utilization bounds are useful screening tests, while response-time analysis provides a more detailed fixed-priority calculation.

An RTOS organizes tasks, interrupts, timers, communication, and synchronization. Queues transfer messages, semaphores signal events or count resources, mutexes protect shared resources, and event flags represent conditions. Priority inversion, deadlock, queue overflow, and excessive critical sections are major hazards.

Reliable mechatronic designs establish timing budgets, use bounded operations, measure worst-case behavior, monitor deadlines, and provide safe responses to overload and failure. RTOS technology is valuable not because it automatically makes a system real time, but because it provides mechanisms through which predictable timing can be engineered and verified.

Key Terms

Real-time system: A system whose correctness depends on logical results and their timing.

Hard real time: A timing regime in which missed deadlines are unacceptable.

Firm real time: A regime in which late results have no value, but occasional misses may be tolerated.

Soft real time: A regime in which late results retain reduced value.

Deadline: The latest permitted completion time.

Period: Time between releases of a periodic task.

WCET: A safe upper bound on task execution time.

Response time: Time from task release to task completion.

Latency: Delay between an event and a specified response point.

Jitter: Variation in a timing quantity.

Slack: Time between completion and deadline.

Preemption: Suspension of one execution context so another can run.

ISR: Interrupt service routine that responds to an interrupt.

RTOS: Operating system providing real-time task, timing, and synchronization services.

Mutex: An ownership-based mutual-exclusion lock.

Semaphore: A synchronization object used for signaling or counting.

Priority inversion: Delay of a high-priority task caused indirectly by lower-priority resource ownership.

Rate-monotonic scheduling: Fixed-priority scheduling in which shorter-period tasks have higher priority.

Earliest-deadline-first: Dynamic scheduling that favors the ready task with the earliest deadline.

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

Review Questions

Short Answer Questions

1. Why is average execution time insufficient for proving a hard real-time deadline?
2. Distinguish latency from jitter.
3. What is the primary difference between a mutex and a binary semaphore?
4. Why should lengthy computation generally be moved out of an ISR?
5. What does priority inheritance accomplish?

Long Answer Questions

1. Explain the task model used in fixed-priority scheduling and discuss its assumptions.
2. Compare rate-monotonic scheduling with earliest-deadline-first scheduling.
3. Describe how queues, semaphores, mutexes, and event flags support communication in an RTOS.
4. Explain the sources of response-time variation in a mechatronic control loop.
5. Develop a verification strategy for an RTOS-based robotic actuator controller.

Analytical / Application Questions

1. A controller has three periodic tasks with C₁ = 0.5 ms, T₁ = 2 ms, C₂ = 1 ms, T₂ = 5 ms, and C₃ = 1 ms, T₃ = 10 ms. Calculate total utilization and discuss why utilization alone does not prove schedulability.
2. A high-priority control task is blocked by a low-priority logging task while a medium-priority communication task runs. Identify the scheduling problem and propose two remedies.
3. Design an RTOS task and interrupt architecture for a servo axis with an encoder, current sensor, network command interface, watchdog, and diagnostic logger. State priorities, communication objects, and timing risks.

Multiple Choice Questions with Answers

Question 1

Which statement best defines a hard real-time requirement?

A. The task should normally execute quickly but may be delayed indefinitely.

B. Every specified deadline must be met for the system to remain acceptable.

C. Late results are always useful at reduced quality.

D. The processor must operate at its maximum clock frequency.

Correct Answer: B. Every specified deadline must be met for the system to remain acceptable.

Question 2

A task has WCET 2 ms and period 8 ms. What is its utilization?

A. 0.16

B. 0.25

C. 4

D. 6 ms

Correct Answer: B. 0.25

Question 3

Under rate-monotonic scheduling, which task receives the higher priority?

A. The task with the longest execution time

B. The task with the shortest period

C. The task with the largest deadline

D. The task released most recently

Correct Answer: B. The task with the shortest period

Question 4

What is the principal purpose of a mutex?

A. To protect a shared resource through mutual exclusion

B. To store an unlimited stream of messages

C. To replace all interrupt handlers

D. To increase processor clock frequency

Correct Answer: A. To protect a shared resource through mutual exclusion

Question 5

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

A. Capturing a hardware timestamp

B. Acknowledging the interrupt source

C. Performing lengthy blocking communication

D. Notifying a waiting task

Correct Answer: C. Performing lengthy blocking communication

Question 6

A task completes at 1.2 ms after release and its relative deadline is 2 ms. What is its slack?

A. 0.8 ms

B. 1.2 ms

C. 2.0 ms

D. 3.2 ms

Correct Answer: A. 0.8 ms

Question 7

What problem is addressed by priority inheritance?

A. Queue overflow

B. Priority inversion caused by resource ownership

C. Clock drift in a crystal oscillator

D. Incorrect analog-to-digital conversion

Correct Answer: B. Priority inversion caused by resource ownership

Question 8

Which scheduling policy dynamically selects the ready task with the earliest absolute deadline?

A. First-come, first-served

B. Rate-monotonic scheduling

C. Earliest-deadline-first scheduling

D. Round-robin without priorities

Correct Answer: C. Earliest-deadline-first scheduling

Question 9

What is a suitable use of a queue in an RTOS?

A. Transferring structured sensor events from an ISR-associated context to a task

B. Guaranteeing that an overloaded producer never loses data

C. Replacing WCET analysis

D. Preventing all forms of deadlock automatically

Correct Answer: A. Transferring structured sensor events from an ISR-associated context to a task

Question 10

If total processor utilization exceeds 1 on a single processor under a periodic task model, what follows?

A. All deadlines are guaranteed because priorities can always fix it

B. The processor demand exceeds capacity under that model

C. The system must use EDF and will necessarily succeed

D. Jitter becomes exactly zero

Correct Answer: B. The processor demand exceeds capacity under that model