Real-Time Embedded System Design

Introduction and Context

A real-time embedded system is a computer system designed to monitor and control a physical process while meeting specified timing constraints. Its correctness depends on both the value produced and the time at which that value is produced. A temperature controller that eventually switches off a heater may be functionally correct, but unsafe if it responds several seconds after an over-temperature condition. Similarly, a motor controller must generate control signals at predictable intervals, not merely perform the required calculations at some unspecified time.

Real-time systems are common in motor drives, industrial automation, automotive control, medical instruments, network equipment, robotics, security devices and consumer products. Microcontrollers are particularly suitable because they integrate a processor core, memory, timers, interrupt controllers and peripheral interfaces in a compact and energy-efficient device.

This chapter develops practical methods for designing such systems. It examines polling and interrupts, finite-state machines, timing and latency analysis, scheduling, reliability, and introductory real-time operating-system (RTOS) concepts.

Learning Objectives

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

1. Distinguish hard, firm and soft real-time requirements.
2. Select between polling, interrupt-driven and hybrid designs.
3. Construct a finite-state machine for an embedded controller.
4. Calculate basic execution time, response time, utilization and timing margins.
5. Explain cooperative, pre-emptive and priority-based scheduling.
6. Identify interrupt-latency sources and reduce timing uncertainty.
7. Describe the roles of tasks, queues, semaphores, mutexes and timers in an RTOS.
8. Apply defensive and reliability-oriented design practices to a real-time application.

1. Real-Time Requirements

1.1 Correctness in time

A real-time requirement specifies a deadline, period, maximum response time or minimum service rate. Important terms include:

• Event: A change or occurrence requiring software action, such as a sensor threshold crossing.
• Release time: The instant at which a job becomes ready to execute.
• Execution time: The processor time needed by a job under stated conditions.
• Deadline: The latest acceptable completion time.
• Period: The interval between releases of a periodic task.
• Response time: The elapsed time from release to completion.
• Jitter: Variation in the timing of an event or task relative to its intended time.
• Latency: Delay between an event and the corresponding software or hardware response.

For a periodic task, the deadline is often equal to the period, but this is not mandatory. A task may execute every 10 ms while having a deadline of 5 ms or 20 ms, depending on the application.

1.2 Hard, firm and soft real time

In a hard real-time system, missing a deadline can cause unacceptable failure or danger. Examples include an airbag controller and a protection relay. In a firm real-time system, a result delivered after its deadline has little or no value, although an occasional miss may not destroy the system. A machine-vision inspection result is often firm real time. In a soft real-time system, late results remain useful but reduce quality, as in audio playback or a network display.

The distinction affects design assurance. Hard real-time systems require conservative timing analysis, fault handling and often independent safety mechanisms. Soft systems may accept statistical performance measures such as average latency, provided worst-case degradation is controlled.

1.3 Requirements specification

A useful real-time specification identifies:

Requirements should state measurement conditions, clock tolerance, interrupt priorities, allowable jitter and behavior during overload. “Fast response” is not an adequate engineering requirement.

2. Timing and Latency Analysis

2.1 Basic timing quantities

For a processor clock frequency f_CPU in hertz, the clock period is:

Here, T_clk is in seconds. If an instruction or routine requires N clock cycles, its ideal execution time is:

This assumes a fixed cycle count and no wait states, cache effects, bus contention or interrupt interference. Real microcontrollers may require a range rather than a single value.

A practical response-time decomposition is:

The terms represent detection delay, waiting for service, software dispatch, execution and output-device delay. A design satisfies a deadline D when:

The worst-case condition is more important than the average condition in hard real-time applications.

2.2 Polling latency

In a polling loop, the processor repeatedly tests a condition. If the time between successive tests is T_poll, an event arriving at a uniformly arbitrary instant has an average waiting time of approximately T_poll/2, while the maximum waiting time approaches T_poll. This assumes a regular polling interval and negligible variation in test execution. Additional processing and blocking operations can make the actual maximum larger.

Polling is attractive when events are frequent, timing is relaxed and the loop is simple. It becomes unsuitable when a low-frequency event requires rapid response while other tasks consume substantial processor time.

2.3 Interrupt latency

Interrupt-driven systems replace repeated testing with hardware notification. Interrupt latency is the time from the interrupt request to the start of the interrupt-service routine (ISR). It may include:

1. Completion of the currently executing instruction.
2. Hardware recognition and context stacking.
3. Masking or higher-priority interrupt delays.
4. Vector lookup and entry code.
5. Software prologue before application action.

An ISR should normally perform only urgent, bounded work: capture a timestamp, read a peripheral register, clear the interrupt source and place data in a buffer or queue. Lengthy calculations should be performed by a task or main-loop function.

2.4 Utilization and timing margin

For independent periodic tasks, a simple processor-utilization estimate is:

where C_i is the worst-case execution time of task i, T_i is its period, and the sum covers all periodic tasks. Both quantities must use the same time unit. U is dimensionless.

If U is close to 1, little capacity remains for interrupts, aperiodic work, measurement error or execution-time variation. A useful engineering margin is:

This is a capacity indicator, not a universal schedulability proof. Priority, deadlines, blocking, release offsets and pre-emption affect actual feasibility.

Worked Example: Periodic Task Loading

A controller has three periodic tasks:

The utilization is:

U = 0.20/1 + 0.60/5 + 2/100

U = 0.20 + 0.12 + 0.02 = 0.34

Thus the estimated periodic workload is 34%, leaving 66% before accounting for interrupts, operating-system overhead and variation. This result suggests capacity, but does not by itself prove that every deadline will be met.

3. Polling, Interrupts and Hybrid Designs

3.1 Polling architecture

A typical super-loop is:

initialise hardware
initialise software state
while true:
    read inputs
    process urgent conditions
    execute periodic work when due
    update outputs
    service communication

The design is easy to debug and has low software overhead. However, a long function can delay every activity after it. Blocking delays are especially harmful because they prevent unrelated events from being serviced.

Polling is appropriate when:

• the number of inputs is small;
• response deadlines are relatively long;
• work is short and bounded;
• timing is predictable;
• simplicity and low memory use are priorities.

3.2 Interrupt-driven architecture

An interrupt controller transfers execution to an ISR when a peripheral signals an event. Common sources include timer compare events, ADC completion, UART reception, external pins and communication controllers.

Good ISR practice includes:

• keep execution short and deterministic;
• avoid unbounded loops and blocking calls;
• avoid dynamic memory allocation;
• protect shared data correctly;
• clear the interrupt source according to the device reference manual;
• record overflow or missed-event conditions;
• defer non-urgent processing.

A shared variable modified by an ISR and read by foreground code may require atomic access or a critical section. On a processor where a multi-byte read is not atomic, the foreground program can observe a partially updated value. Declaring a variable volatile tells the compiler that its value may change unexpectedly; it does not by itself make an operation atomic or provide mutual exclusion.

3.3 Hybrid design

Most professional microcontroller systems use both methods. A timer interrupt may maintain a system tick, while the main loop performs scheduled tasks. A UART ISR may place received bytes into a ring buffer, and a foreground task parses complete messages. This arrangement combines prompt event capture with manageable application logic.

4. Finite-State Machines

A finite-state machine (FSM) represents a controller as a finite set of states, input-dependent transitions and state actions. It is valuable when behavior depends on history rather than only on current input.

A state-machine model can be described by:

• a set of states;
• a set of input events;
• transition rules;
• actions on entry, during the state or on exit;
• a defined response to invalid events.

For example, a motor controller may contain the states OFF, READY, RUNNING, FAULT and STOPPING. A start command moves READY to RUNNING only when safety interlocks are valid. An over-current event moves RUNNING immediately to FAULT. Reset does not necessarily mean “resume”; it may require an explicit inspection and re-arming step.

4.1 Moore and Mealy models

In a Moore-style machine, outputs depend primarily on the current state. This often makes outputs stable and easier to verify. In a Mealy-style machine, outputs depend on both state and input, allowing rapid reactions but potentially producing output changes whenever inputs change. Embedded controllers may use a mixture: state-based operating modes with event-triggered actions.

4.2 FSM design method

1. List externally observable modes.
2. Identify events and guard conditions.
3. Define legal transitions.
4. Define entry, activity and exit actions.
5. Define startup and recovery behavior.
6. Define invalid-event handling.
7. Test every state-event combination.

State actions should be bounded. If a state contains a long blocking operation, it is usually better to split the activity into substates and advance it through events or scheduled steps.

5. Scheduling Approaches

5.1 Cooperative scheduling

In cooperative scheduling, tasks run until they voluntarily return control. A simple dispatcher may examine ready flags and call the corresponding functions. It is easy to implement and has low context-switch overhead. Its main weakness is that one task that fails to yield delays all others.

Cooperative design works well when tasks are short, non-blocking and carefully bounded. A coding rule such as “no task runs longer than 100 μs” can make response analysis practical.

5.2 Pre-emptive scheduling

In pre-emptive scheduling, the system can suspend a running task and execute a higher-priority ready task. This improves response to urgent work but introduces context-switch overhead, shared-data hazards and more complex timing analysis.

A common policy is fixed-priority scheduling: each task receives a priority, and the highest-priority ready task executes. Priority assignment must reflect deadlines and dependencies rather than simply assigning the highest priority to the most computationally intensive task.

5.3 Rate-monotonic intuition

For a set of periodic tasks with fixed priorities, rate-monotonic assignment gives higher priority to tasks with shorter periods. Under ideal assumptions—independent tasks, fixed priorities, pre-emption, deadlines equal to periods and negligible overhead—this policy has strong theoretical guarantees. Real microcontroller systems violate some assumptions, so the result should guide analysis rather than replace measurement and testing.

5.4 Priority inversion

Priority inversion occurs when a high-priority task waits for a resource held by a low-priority task, while a medium-priority task prevents the low-priority task from running. Priority inheritance temporarily raises the holder’s priority, reducing this problem. Mutexes supplied by an RTOS may implement priority inheritance; simple binary flags usually do not.

6. Introductory RTOS Concepts

An RTOS provides structured services for concurrent real-time software. Typical components are:

• Task or thread: An independently schedulable execution context.
• Scheduler: Selects the next task to run.
• Tick or timer service: Provides time-based wake-up and timeout functions.
• Semaphore: A synchronization or event-counting mechanism.
• Mutex: A mutual-exclusion lock, often with priority-inheritance support.
• Message queue: A bounded FIFO for transferring data between tasks.
• Event flags: Bits representing one or more conditions.
• Watchdog: A timer that resets or signals the system if software fails to service it.

An RTOS does not automatically make a system deterministic. Its kernel overhead, interrupt behavior, memory allocation, queue lengths and scheduling policy must be included in timing analysis.

A typical architecture separates functions into tasks:

A queue is preferable to sharing complex mutable data directly. For example, a UART ISR can enqueue received bytes while a communication task assembles complete frames. The queue must have a bounded capacity, and overflow behavior must be defined.

7. Reliability and Defensive Design

Real-time reliability includes both timing reliability and functional reliability. Useful practices include:

• use watchdogs, but diagnose why they expire rather than treating reset as normal operation;
• validate sensor ranges, checksums and sequence numbers;
• use explicit safe states for actuator failure;
• detect missed deadlines and queue overflows;
• design startup, brownout and reset behavior;
• avoid unbounded recursion and uncontrolled dynamic allocation;
• measure worst-case execution time on representative hardware;
• record faults with timestamps and reset causes;
• perform fault injection and overload testing.

A safety response should be independent where practical. For example, a software task may command a motor off, while a hardware comparator independently disables the gate driver if current exceeds a critical threshold.

Security also affects real-time behavior. Malformed network messages, authentication operations or denial-of-service traffic can consume processor and queue capacity. Input validation, bounded parsing, rate limiting and separation of safety-critical control from non-critical communications reduce this risk.

8. Applied Case: Illustrative Conveyor Motor Controller

Background

Consider an illustrative packaging conveyor controlled by a 32-bit microcontroller. The system reads a proximity sensor, drives a motor, monitors motor current and communicates production counts to a supervisory computer.

Problem

The original design used a polling loop containing a 50 ms blocking delay. At high conveyor speed, a jam sensor could remain active for longer than the required 5 ms shutdown deadline. Communication bursts also caused missed sensor transitions.

Analysis

The safety event requires a rapid response, whereas display and communication work are less urgent. The blocking delay creates an upper-bound detection delay near 50 ms, already exceeding the requirement before output actuation time is included. The design also has no explicit recovery state and cannot distinguish a transient communication error from a motor fault.

Approach and solution

The redesigned controller uses:

1. An external interrupt for the jam sensor. The ISR records the event, disables the motor-enable output through a bounded action and posts a safety event.
2. A 1 ms timer interrupt that releases the control task.
3. A finite-state machine with OFF, READY, RUNNING, STOPPING and FAULT states.
4. A ring buffer for communication reception.
5. A high-priority safety task and lower-priority communication and reporting tasks.
6. A watchdog serviced only after essential tasks report successful completion.
7. A hardware current comparator as an independent over-current shutdown.

The ISR does not parse messages or calculate production statistics. Those functions are deferred to tasks. Every queue has a defined overflow response, and a missed safety event is treated as a fault rather than silently discarded.

Outcome

Under measured worst-case conditions, the safety path responds within the required 5 ms, while communication bursts no longer prevent sensor capture. The state machine makes fault recovery explicit: the operator must acknowledge the fault and verify the safety interlock before the controller can return to READY.

Learning points

The case demonstrates that real-time improvement does not necessarily require a faster processor. Removing blocking delays, separating urgent from non-urgent work, using bounded event capture and defining states can produce a more predictable system. Timing claims must nevertheless be verified with hardware measurements, including interrupt contention and worst-case communication load.

9. Verification and Measurement

Timing analysis should be supported by measurement. A GPIO pin can be set at event detection and cleared at action completion; an oscilloscope or logic analyzer then measures latency and jitter. Trace instrumentation can record task start and finish times, but instrumentation overhead must be considered.

Test categories include:

• nominal functional tests;
• maximum-rate event tests;
• simultaneous interrupt tests;
• queue and buffer overflow tests;
• deadline-miss tests;
• power interruption and brownout tests;
• invalid-input and communication-flood tests;
• long-duration soak tests.

The test environment should identify clock frequency, compiler settings, optimization level, peripheral configuration and input rates. A timing result obtained under light load is not evidence of worst-case compliance.

10. Design Best Practices and Limitations

A disciplined design process begins with measurable timing requirements, followed by task decomposition and resource analysis. Each task should have a known trigger, maximum execution time, priority and deadline. Shared resources should be minimized and protected with mechanisms appropriate to the scheduling model.

The principal limitation of simple utilization calculations is that they hide interference. A system with low average utilization can still miss a deadline if a high-priority task is blocked, an ISR is too long or several jobs arrive simultaneously. Conversely, a system with utilization above a simple theoretical bound may remain schedulable under its actual task set. Therefore, use worst-case reasoning, schedulability analysis where applicable, measurement and stress testing together.

AI-assisted code generation can help produce test scaffolding or documentation, but generated ISR, synchronization and safety code must be reviewed against the microcontroller reference manual and project standards. An AI tool does not establish timing bounds, hardware correctness or safety compliance. Traceability from requirement to implementation and test remains a professional responsibility.

Chapter Summary

Real-time embedded systems must produce correct results within defined timing constraints. Hard, firm and soft real-time classifications determine the required level of assurance. Polling is simple but can create long and variable detection delays; interrupts capture urgent events promptly but require short, bounded service routines. Hybrid designs commonly use interrupts for capture and tasks or foreground code for processing.

Finite-state machines provide a clear structure for mode-dependent behavior, including startup, operation, stopping and faults. Timing analysis uses execution time, periods, response-time components, utilization and timing margins, but utilization alone is not a schedulability proof. Cooperative scheduling is simple and efficient when tasks yield quickly, whereas pre-emptive scheduling improves responsiveness at the cost of synchronization and analysis complexity.

RTOS mechanisms such as tasks, queues, mutexes, semaphores and timers support structured concurrency, but they do not remove the need for bounded execution, priority design and measurement. Reliable systems define safe states, handle overload and faults, validate inputs, use watchdogs appropriately and verify worst-case behavior on real hardware.

Key Terms

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

Hard real time: A timing regime in which missing a deadline is unacceptable.

Soft real time: A regime in which late results retain some value but reduce performance.

Deadline: The latest acceptable completion time for a job.

Period: The interval between releases of a periodic task.

Execution time: Processor time required by a task or routine.

Response time: Time from job release or event occurrence to completion or action.

Latency: Delay between an initiating event and the resulting response.

Jitter: Variation around an intended timing value.

Polling: Repeated software testing of a device or condition.

Interrupt service routine: A routine executed in response to an interrupt request.

Finite-state machine: A model consisting of states, events, transitions and actions.

Cooperative scheduling: Scheduling in which tasks voluntarily yield control.

Pre-emption: Suspending a running task so another ready task can execute.

Priority inversion: A condition in which a high-priority task is delayed by lower-priority work.

Mutex: A mutual-exclusion synchronization object.

Semaphore: A synchronization or event-counting mechanism.

Message queue: A bounded mechanism for passing messages between execution contexts.

Watchdog: A timer that detects software failure through failure to service it.

Worst-case execution time: The maximum execution time assumed for timing analysis.

Review Questions

Short Answer Questions

1. What makes a system real time rather than merely fast?
2. State two differences between polling and interrupt-driven design.
3. Why should an ISR normally be short and bounded?
4. What is the purpose of a finite-state machine?
5. What is priority inversion?

Long Answer Questions

1. Explain hard, firm and soft real-time systems, giving one application example for each.
2. Describe how to design and test a finite-state machine for a motor controller.
3. Explain cooperative and pre-emptive scheduling, including their principal advantages and risks.
4. Discuss the purpose of queues, semaphores and mutexes in an RTOS.
5. Describe a complete timing-verification strategy for a microcontroller-based control system.

Analytical / Application Questions

1. A system contains tasks with execution times and periods of 0.1 ms/1 ms, 0.5 ms/5 ms and 1 ms/20 ms. Calculate utilization and explain why the result is not, by itself, a schedulability proof.
2. A polling loop tests an emergency input every 8 ms. Estimate the average and maximum polling wait under the regular-polling assumption, and recommend a design change if the required response is below 2 ms.
3. Design the states, critical events and fault response for a battery-powered robotic vehicle that must stop when its obstacle sensor is active or its battery voltage is too low.

Multiple Choice Questions with Answers

Question 1

Which statement best defines a hard real-time system?

A. It always uses an RTOS.

B. It must meet critical deadlines; a missed deadline may be unacceptable.

C. It has the highest processor clock frequency.

D. It performs only integer calculations.

Correct Answer: B. It must meet critical deadlines; a missed deadline may be unacceptable.

Question 2

What is the ideal execution time for a routine requiring 2,000 cycles on a 20 MHz processor, ignoring overhead?

A. 10 μs

B. 50 μs

C. 100 μs

D. 1 ms

Correct Answer: C. 100 μs

Question 3

Which operation is most appropriate for a short interrupt-service routine?

A. Parsing a complete network protocol

B. Executing an unbounded search

C. Capturing data and posting an event for later processing

D. Waiting for a peripheral with a blocking delay

Correct Answer: C. Capturing data and posting an event for later processing

Question 4

A periodic task executes for 0.2 ms every 1 ms. What is its utilization?

A. 2%

B. 5%

C. 20%

D. 200%

Correct Answer: C. 20%

Question 5

What is the main danger of a long blocking delay in a polling loop?

A. It increases available CPU capacity.

B. It can delay the detection and servicing of unrelated events.

C. It automatically raises interrupt priority.

D. It guarantees lower jitter.

Correct Answer: B. It can delay the detection and servicing of unrelated events.

Question 6

In a finite-state machine, a transition normally specifies movement between states in response to:

A. An event or condition

B. A compiler optimization

C. A memory address alone

D. A fixed screen resolution

Correct Answer: A. An event or condition

Question 7

Which RTOS object is primarily intended to provide mutual exclusion for a shared resource?

A. Mutex

B. ADC

C. Timer capture register

D. Watchdog reset vector

Correct Answer: A. Mutex

Question 8

What is priority inversion?

A. A high-priority task is delayed by a lower-priority task holding a needed resource.

B. A processor changes from binary to decimal arithmetic.

C. An ISR always runs after every low-priority task.

D. A queue reverses all message bits.

Correct Answer: A. A high-priority task is delayed by a lower-priority task holding a needed resource.

Question 9

For a regular polling interval of 10 ms, what is the approximate average waiting time for an event arriving at a random instant?

A. 0 ms

B. 2 ms

C. 5 ms

D. 10 ms

Correct Answer: C. 5 ms

Question 10

Which statement about the C volatile qualifier is correct?

A. It guarantees atomic multi-byte access.

B. It prevents all race conditions.

C. It informs the compiler that a value may change unexpectedly, but does not itself provide synchronization.

D. It disables all interrupts permanently.

Correct Answer: C. It informs the compiler that a value may change unexpectedly, but does not itself provide synchronization.