Embedded Computing and Real-Time Systems

Introduction and Context

A cyber-physical system (CPS) combines computation, communication, sensing, and actuation with a physical process. Embedded computing is the computational foundation of such systems. Unlike general-purpose desktop computing, embedded computing is usually designed around a specific function, constrained resources, predictable timing, low power consumption, and close interaction with hardware.

In a robotic arm, for example, embedded processors acquire encoder measurements, execute control algorithms, communicate with drives, and generate actuator commands. Correctness therefore has two dimensions: the computed result must be logically correct, and it must be produced at the required time. A late braking command may be functionally correct but physically unsafe. This requirement leads to the study of real-time systems.

A real-time system is one in which the timing of computation is part of the system specification. A hard real-time deadline must not be missed; a missed deadline can cause failure or danger. In a soft real-time system, occasional deadline misses reduce performance but do not necessarily cause catastrophic failure.

Learning Objectives

By the end of this chapter, the reader should be able to:

• distinguish processors, microcontrollers, microprocessors, and embedded computers;
• explain the roles of memory, peripherals, buses, timers, and communication interfaces;
• compare bare-metal software with operating-system-based embedded software;
• describe tasks, threads, processes, interrupts, and interrupt service routines;
• analyze periodic scheduling and basic timing constraints;
• explain concurrency, synchronization, and common race conditions;
• evaluate hardware–software partitioning in a CPS;
• identify design, safety, security, and verification issues in real-time embedded systems.

1. Embedded Computing Platforms

1.1 Processor, microprocessor, and microcontroller

A processor is a digital device that interprets and executes instructions. A microprocessor generally contains the central processing unit (CPU) but relies on external memory and peripheral devices. A microcontroller (MCU) integrates a CPU core, memory, timers, digital input/output, communication interfaces, and often analog-to-digital converters on one chip.

Microcontrollers are widely used in mechatronics because they provide deterministic peripheral access at low cost and power. Microprocessors, often combined with external memory and sophisticated operating systems, are preferred when substantial computation, graphical interfaces, networking, or artificial intelligence is required.

A system-on-chip (SoC) integrates multiple components, possibly including CPU cores, graphics processors, programmable logic, memory controllers, and communication subsystems. A heterogeneous SoC may contain different cores optimized for control, signal processing, and high-level application software.

1.2 Principal hardware elements

A typical embedded platform includes:

• CPU core: performs instruction execution and manages registers, arithmetic, control flow, and exceptions.
• Program memory: stores firmware, commonly in flash or read-only memory.
• Data memory: stores variables, stacks, buffers, and dynamic data, commonly in SRAM or DRAM.
• Timers and counters: generate periodic events, measure intervals, and produce pulse-width-modulated signals.
• Digital I/O: interfaces with switches, relays, sensors, and actuators.
• ADC and DAC: convert between analog signals and digital representations.
• Communication peripherals: support interfaces such as UART, SPI, I²C, CAN, Ethernet, and industrial fieldbuses.
• Direct memory access (DMA): transfers data between peripherals and memory with limited CPU involvement.
• Watchdog timer: resets the system if software fails to provide a periodic service signal.

The selection of a platform is an engineering trade-off involving computational load, memory capacity, timing determinism, energy, cost, development tools, safety requirements, and product lifetime.

1.3 Memory and execution

When a program runs, instructions and data are placed in memory. The stack typically stores function-call information, local variables, and interrupt context. A heap, if used, supports dynamic allocation but can introduce fragmentation and unpredictable execution time. Safety-critical real-time systems often avoid uncontrolled dynamic allocation after startup.

Caches improve average execution speed by storing frequently used instructions and data close to the CPU. However, cache misses produce variable execution times. Consequently, cache behavior must be considered when establishing a reliable worst-case execution-time estimate.

2. Embedded Software Architectures

2.1 Bare-metal systems

In a bare-metal system, application code executes directly on the hardware without a general-purpose operating system. A common structure is an initialization routine followed by a cyclic executive:

initialize hardware
initialize variables
while true:
    read inputs
    execute control logic
    update outputs
    perform background diagnostics

Bare-metal software has low overhead and can be highly deterministic. It is suitable for small applications with a limited number of activities. Its weaknesses include poor modularity, difficult scaling, and the risk that one long operation delays all others.

2.2 Operating systems and kernels

An operating system (OS) manages hardware resources and provides services to application software. In embedded systems, an OS may be a small real-time operating system (RTOS) or a larger system such as embedded Linux.

A kernel commonly provides:

• task or thread management;
• scheduling;
• timers and clocks;
• inter-task communication;
• synchronization primitives;
• device drivers;
• memory protection and fault handling.

An RTOS does not necessarily make every operation instantaneous. Its defining purpose is to provide bounded and analyzable behavior for relevant services. A system may use a general-purpose OS for user interfaces and networking while assigning time-critical control to a microcontroller or real-time core.

2.3 Processes, threads, and tasks

A process normally owns an address space and system resources. A thread is an independently schedulable execution path within a process. In RTOS terminology, the word task is often used for a schedulable thread with its own stack and state.

A task can be in states such as running, ready, blocked, suspended, or terminated. A blocked task is waiting for an event, such as a timer, message, semaphore, or peripheral completion. Blocking avoids wasting CPU time through continuous polling.

3. Interrupts and Timing

3.1 Interrupt operation

An interrupt is a hardware or software event that temporarily transfers processor control to an interrupt service routine (ISR). Sources include timer expiry, received communication data, ADC completion, encoder transitions, faults, and external emergency signals.

A typical sequence is:

1. hardware asserts an interrupt request;
2. the processor completes or suspends the current instruction according to its architecture;
3. processor context is saved;
4. the interrupt vector identifies the ISR;
5. the ISR acknowledges the event and performs urgent work;
6. context is restored and interrupted execution resumes, or a higher-priority task is scheduled.

An ISR should be short, deterministic, and free of unnecessary blocking. A common design is to capture data and set an event flag, then perform substantial processing in a task.

Important timing quantities include:

• interrupt latency: time from event occurrence to the start of ISR execution;
• ISR execution time: time required by the ISR;
• scheduling latency: time from a task becoming ready to its execution;
• response time: time from an external event to the required system response;
• jitter: variation in the timing of nominally periodic events.

For a simple response path, an approximate upper-bound model is:

Here, R is response time, L_i is interrupt latency, C_i is ISR execution time, L_s is task scheduling latency, and C_t is task computation time. All quantities must use the same time unit. The expression applies only when the path contains these components and does not include additional blocking, communication, or preemption delays.

3.2 Periodic sampling

Control systems often execute periodically. If a task has period T, its nominal frequency is:

where f is frequency in hertz and T is period in seconds. For example, a 1 ms sampling period corresponds to 1000 Hz.

The sampling period must be selected in relation to process dynamics, sensor characteristics, computational capacity, and communication delay. Excessively slow sampling can destabilize or degrade control; excessively fast sampling increases processor load and may amplify measurement noise or leave insufficient time for computation.

4. Real-Time Scheduling

4.1 Scheduling concepts

A scheduler selects which ready task executes. Scheduling policies include:

• First-come, first-served: tasks execute in arrival order; simple but potentially poor for urgent work.
• Fixed-priority scheduling: each task has a priority that remains constant; rate-monotonic scheduling assigns higher priority to shorter-period periodic tasks.
• Dynamic-priority scheduling: priorities change according to deadlines or other rules; earliest-deadline-first (EDF) is a major example.
• Preemptive scheduling: a higher-priority task can interrupt a running lower-priority task.
• Non-preemptive scheduling: a running task continues until it blocks or completes.

A task is commonly characterized by execution time C, period T, and relative deadline D. The utilization of a periodic task is:

where U_i is the fraction of processor capacity consumed by task i. For n independent periodic tasks, total utilization is:

The sum is dimensionless because both execution time and period have units of time. This calculation is a necessary capacity check, not by itself a complete proof of schedulability. Interrupts, context switches, blocking, release jitter, deadlines, and shared resources must also be considered.

4.2 Rate-monotonic analysis

For idealized independent periodic tasks with fixed priorities, deadlines equal to periods, negligible overhead, and preemption allowed, a sufficient utilization bound for rate-monotonic scheduling is:

Here, n is the number of tasks. As n becomes large, the bound approaches approximately 0.693. The test is sufficient but not necessary: a task set exceeding the bound may still be schedulable. Exact response-time analysis is more informative when assumptions are not ideal.

For a higher-priority task set, a basic response-time recurrence for task i is:

Here, R_i is the worst-case response time, C_i is its execution time, B_i is blocking time, hp(i) is the set of higher-priority tasks, and C_j and T_j are the execution time and period of higher-priority task j. The ceiling term counts possible interference releases during the response interval. The recurrence is iterated from an initial estimate, commonly R_i^(0) = C_i + B_i, until it converges or exceeds the deadline. It assumes fixed-priority preemptive scheduling and must be extended for release jitter and other overheads.

4.3 Worked scheduling example

Consider three independent periodic tasks on one processor:

The total utilization is:

For three tasks, the rate-monotonic sufficient bound is approximately 0.780. Since 0.55 ≤ 0.780, the task set passes this sufficient test under the stated assumptions. This conclusion does not guarantee implementation success if, for example, an ISR consumes significant time or a shared bus introduces blocking.

5. Concurrency and Synchronization

Concurrency occurs when multiple activities make progress during overlapping intervals. On a single CPU, concurrency may be achieved through interleaving; on multicore hardware, tasks may execute simultaneously.

5.1 Race conditions

A race condition occurs when the result depends on the timing or order of concurrent accesses. Suppose an ISR increments a shared counter while a task reads and clears it. If the read-modify-write sequence is interrupted, an increment may be lost.

Protection mechanisms include:

• disabling interrupts for a very short critical section;
• atomic processor instructions;
• mutexes for mutually exclusive access;
• binary and counting semaphores;
• message queues and mailboxes;
• lock-free or wait-free data structures where justified.

A mutex should generally be owned by one task at a time. A semaphore is primarily a signaling or counting mechanism and does not necessarily express ownership.

5.2 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 resource holder’s priority; priority ceiling protocols provide another mitigation. These protocols reduce unbounded blocking but require disciplined resource design.

5.3 Deadlock

Deadlock can occur when tasks hold resources while waiting for one another. Four conditions are traditionally associated with deadlock: mutual exclusion, hold and wait, no preemption, and circular wait. Consistent lock ordering, short critical sections, timeouts, and message-passing architectures reduce risk.

6. Hardware–Software Co-Design

Hardware–software co-design treats the physical platform and software architecture as a coupled design problem. The central question is not merely which processor is fastest, but which functions should be implemented in software, dedicated hardware, programmable logic, or a combination.

A control loop may be implemented in a microcontroller for flexibility and low cost. A high-rate digital filter may be moved to FPGA logic to obtain deterministic parallel execution. A vision algorithm may use a CPU, GPU, or neural-processing accelerator. The choice depends on:

• required latency and jitter;
• throughput and parallelism;
• numerical precision;
• energy and thermal limits;
• development time and maintainability;
• unit cost and production volume;
• safety certification and verification effort.

Hardware acceleration can reduce execution time, but it introduces interfaces, data-transfer delays, specialized verification, and possible vendor dependence. Software is easier to update, but timing may be less deterministic.

A practical co-design workflow is:

1. specify physical behavior, deadlines, accuracy, and failure responses;
2. model computation and communication flows;
3. estimate worst-case execution and data-transfer times;
4. partition functions among sensors, MCU, CPU, FPGA, and cloud systems;
5. prototype critical timing paths;
6. verify functional, temporal, safety, and security requirements;
7. measure the implemented system under normal and worst-case conditions.

7. Illustrative Case: Conveyor-Based Part Sorting Cell

Background

Consider an automated conveyor that identifies products using a camera and ejects defective items with a pneumatic actuator. An encoder measures conveyor position. The system contains a real-time microcontroller for motion and safety functions and a Linux-based computer for image processing.

Problem

The ejector must activate when a defective part reaches a fixed location. Image classification is computationally intensive and has variable execution time. The controller must tolerate communication delay and must not eject a good part.

Analysis

The high-level computer classifies each image and sends a result with a timestamp or encoder position. The microcontroller performs encoder counting, safety checks, timing, and actuator control. If the conveyor speed is v and the remaining distance is d, the nominal travel time is:

The units must be consistent—for example, metres and metres per second produce seconds. The available timing margin is the travel time minus sensing, classification, communication, scheduling, and actuator delays. Because speed may vary, position-based triggering is generally more reliable than a fixed time delay.

Approach and solution

The microcontroller uses a timer or encoder event to maintain position. A message from the vision computer contains the classification and target position. A real-time task checks whether the target position has been reached, while a higher-priority safety task monitors emergency-stop inputs and actuator limits. Communication failure causes the system to enter a defined safe state rather than relying on stale commands.

The image computer is not permitted to directly energize the ejector. This separation limits the consequences of operating-system delays and simplifies safety analysis. A watchdog supervises both computing units, and diagnostic counters detect lost, late, or duplicated messages.

Outcome

The architecture combines flexible high-level computation with deterministic low-level control. The key performance measure is not the average classification time but the worst-case end-to-end delay and its margin relative to the physical process.

Learning points

• Separate variable-time computation from safety-critical actuation.
• Use physical position when speed is variable.
• Analyze complete timing paths, not isolated task execution times.
• Define behavior for missing, late, or inconsistent data.
• Treat communication and operating-system behavior as part of the control problem.

8. Verification, Safety, Security, and Professional Practice

Real-time correctness must be demonstrated through analysis and measurement. Useful techniques include code review, static analysis, unit testing, hardware-in-the-loop testing, timing instrumentation, fault injection, stress testing, and requirements traceability.

Worst-case execution time is difficult to establish on modern processors because of caches, pipelines, interrupts, speculative execution, and shared buses. Engineers should document assumptions, measure representative workloads, and add justified margins. Average timing is not an adequate substitute for worst-case analysis in hard real-time functions.

Safety engineering requires hazard identification, risk reduction, independent protective mechanisms, and fail-safe or fault-tolerant behavior. Applicable standards depend on the domain, such as industrial machinery, automotive, medical devices, railways, or aerospace. Engineers must consult the relevant current standards rather than assuming that one standard applies universally.

Cybersecurity is inseparable from CPS design. Threats include malicious firmware, unauthorized commands, denial of service, compromised updates, and manipulation of sensor data. Good practices include secure boot, authenticated updates, least privilege, network segmentation, cryptographic key protection, logging, vulnerability management, and recovery planning. Security controls must themselves be assessed for timing and resource overhead.

Artificial intelligence is increasingly placed in embedded systems for perception and predictive maintenance. AI inference may have variable execution time and uncertain behavior outside its training distribution. Safety-critical decisions should therefore include confidence handling, monitoring, fallback logic, and clearly defined authority boundaries. An AI classifier should not silently override a deterministic safety interlock.

Design Best Practices

1. State timing requirements explicitly, including deadlines, jitter, and allowable lateness.
2. Distinguish average performance from worst-case behavior.
3. Keep ISRs short and move lengthy work to schedulable tasks.
4. Minimize shared mutable state and document every synchronization mechanism.
5. Avoid unbounded blocking and uncontrolled dynamic memory allocation in critical paths.
6. Measure interrupt, communication, scheduling, and end-to-end latency.
7. Design watchdogs and fault responses as engineered safety mechanisms, not patches.
8. Partition functions according to timing, safety, computational, and update requirements.
9. Test overload, communication loss, sensor faults, resets, and corrupted data.
10. Maintain traceability from physical requirements to software and hardware verification.

Chapter Summary

Embedded computing provides the sensing, computation, communication, and actuation capabilities required by cyber-physical systems. Microcontrollers integrate processing with timers and peripherals, whereas microprocessors and SoCs support more demanding operating systems and applications. An RTOS organizes tasks, interrupts, timers, communication, and synchronization while attempting to provide bounded behavior.

Real-time systems are defined by temporal correctness as well as logical correctness. Execution time, interrupt latency, scheduling latency, response time, jitter, utilization, and blocking are essential engineering quantities. Fixed-priority scheduling and response-time analysis provide useful tools, but their assumptions must be checked against the actual implementation.

Concurrency introduces races, priority inversion, and deadlock; disciplined synchronization and resource design are therefore essential. Hardware–software co-design assigns functions to appropriate computational resources based on timing, throughput, energy, safety, cost, and maintainability. Finally, verification, cybersecurity, and safety engineering must address complete end-to-end behavior under normal, overloaded, and faulty conditions.

Key Terms

Embedded system: A computer-based system designed for a specific function within a larger product.

Microcontroller: An integrated chip containing a processor, memory, and peripheral interfaces.

Microprocessor: A processor-centric chip that commonly uses external memory and peripherals.

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

Hard real-time: A system in which missing a deadline can cause unacceptable failure.

Soft real-time: A system in which deadline misses degrade performance but are tolerated to some extent.

Interrupt: An event that transfers processor control to an interrupt service routine.

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

Task: An independently schedulable unit of execution in an RTOS.

Scheduler: A mechanism that selects the next ready task to execute.

Preemption: Suspension of a running task so another task can execute.

Jitter: Variation in the timing of an event relative to its nominal timing.

Worst-case execution time: An upper estimate of the time required by a computation under stated assumptions.

Utilization: The fraction of processor capacity consumed by a task set.

Race condition: Incorrect or variable behavior caused by unsynchronized concurrent access.

Mutex: A mutual-exclusion mechanism that protects a shared resource.

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

Deadlock: A state in which tasks wait indefinitely for resources held by one another.

Hardware–software co-design: Joint optimization and verification of hardware and software functions.

Watchdog timer: A timer that initiates recovery when software fails to operate as expected.

Review Questions

Short Answer Questions

1. What distinguishes a microcontroller from a general-purpose microprocessor?
2. Define interrupt latency and jitter.
3. Why should an interrupt service routine usually be short?
4. What is the purpose of a mutex?
5. State the difference between hard and soft real-time systems.

Long Answer Questions

1. Explain the architecture and major services of a real-time operating system.
2. Compare bare-metal cyclic executives with RTOS-based designs, including advantages and limitations.
3. Explain fixed-priority scheduling and the meaning of processor utilization.
4. Describe race conditions, priority inversion, and deadlock, and propose mitigations.
5. Discuss the major criteria used in hardware–software partitioning for a cyber-physical system.

Analytical / Application Questions

1. A control task executes for 0.8 ms every 4 ms, while a diagnostic task executes for 2 ms every 20 ms. Calculate total utilization and discuss what additional factors must be checked before declaring the system schedulable.
2. Design a timing architecture for a motor controller that must react to an encoder event within a bounded time while also communicating over a network. Identify suitable interrupt, task, priority, and synchronization mechanisms.
3. For the conveyor sorting case, analyze the consequences of a late image classification, a lost communication message, and a false defect classification. Propose safe and operational responses for each condition.

Multiple Choice Questions with Answers

Question 1

Which characteristic most directly distinguishes a real-time system from an ordinary computing system?

A. It always uses a microcontroller.

B. Its correctness depends partly on meeting timing requirements.

C. It cannot use an operating system.

D. It must consume very little power.

Correct Answer: B. Its correctness depends partly on meeting timing requirements.

Question 2

What is the primary purpose of an interrupt service routine?

A. To handle an event requiring processor attention

B. To permanently replace the operating system

C. To allocate all dynamic memory

D. To increase the clock frequency

Correct Answer: A. To handle an event requiring processor attention

Question 3

A task executes for 2 ms every 10 ms. Its processor utilization is:

A. 0.02

B. 0.10

C. 0.20

D. 5.00

Correct Answer: C. 0.20

Question 4

Which scheduling policy assigns higher priority to tasks with shorter periods?

A. First-come, first-served

B. Rate-monotonic scheduling

C. Random scheduling

D. Round-robin without priorities

Correct Answer: B. Rate-monotonic scheduling

Question 5

What is a race condition?

A. A hardware failure caused by excessive speed

B. A condition in which results depend on the timing of concurrent accesses

C. A guaranteed deadline violation

D. A method for measuring processor frequency

Correct Answer: B. A condition in which results depend on the timing of concurrent accesses

Question 6

Which mechanism is primarily used to ensure mutual exclusion for a shared resource?

A. Mutex

B. ADC

C. Watchdog timer

D. DMA controller

Correct Answer: A. Mutex

Question 7

What is priority inversion?

A. A low-priority task permanently receives the highest priority

B. A high-priority task is delayed because a lower-priority task holds a needed resource

C. All tasks execute in reverse numerical order

D. The processor changes from digital to analog operation

Correct Answer: B. A high-priority task is delayed because a lower-priority task holds a needed resource

Question 8

For a conveyor moving at 2 m/s, a part is 0.6 m from the ejector. Ignoring other delays, the travel time is:

A. 0.12 s

B. 0.30 s

C. 1.20 s

D. 3.33 s

Correct Answer: B. 0.30 s

Question 9

Why can cache behavior complicate worst-case execution-time analysis?

A. Caches eliminate all timing variation.

B. Cache misses can produce variable execution times.

C. Caches prevent interrupts from occurring.

D. Caches convert software into hardware.

Correct Answer: B. Cache misses can produce variable execution times.

Question 10

Which is a sound hardware–software co-design practice?

A. Assign every function to the fastest processor without analysis.

B. Ignore communication delay because it is outside the software.

C. Partition functions using timing, safety, energy, cost, and maintainability requirements.

D. Place all safety functions in a variable-time cloud service.

Correct Answer: C. Partition functions using timing, safety, energy, cost, and maintainability requirements.