Real-Time Systems: Layers, Models & Key Components

TAKEAWAYS:

• Real-time systems follow a layered reference model (application → middleware → OS → hardware) to ensure predictability and meet deadlines.
• The IEEE 1520 standard defines task models (periodic, aperiodic, sporadic) and their scheduling constraints.
• Hardware components (CPUs, timers, memory) must support deterministic timing (e.g., fixed-priority scheduling).
• Middleware (e.g., RTOS kernels like FreeRTOS) bridges application tasks and hardware to enforce timing guarantees.
• Real-world applications (e.g., medical devices, autonomous vehicles) rely on this model to avoid catastrophic failures from missed deadlines.
• Performance analysis depends on understanding how each layer interacts (e.g., task deadlines vs. CPU allocation).

1. Introduction to Real-Time Systems (RTS) Reference Model

Real-time systems (RTS) are time-constrained systems where correctness depends not only on logical results but also on timing constraints (deadlines). Unlike general-purpose systems, RTS must guarantee that tasks complete within strict time bounds to avoid failures (e.g., a pacemaker missing a heartbeat or an airbag deployment delay).

Key Characteristics of RTS:

• Deterministic behavior: Output must occur within a predictable time frame.
• Hard vs. soft real-time:
  • Hard real-time: Missing a deadline is catastrophic (e.g., anti-lock braking systems).
  • Soft real-time: Missing a deadline degrades performance but doesn’t cause failure (e.g., video streaming lag).
• Timing constraints: Defined by deadlines, periods, and execution times.

Why a Reference Model?

A reference model standardizes how RTS are designed, ensuring:

• Interoperability between hardware and software.
• Predictability in timing behavior.
• Modularity for easier maintenance and upgrades.

2. Layered Architecture of Real-Time Systems

The reference model for RTS is typically layered, similar to the OSI model but tailored for timing constraints. The layers are:

How Layers Interact

flowchart TD
    A["Application Layer\n(Tasks, Deadlines)"] -->|"Sends Task Requests"| B["Middleware\n(Scheduler, Dispatcher)"]
    B -->|"Allocates CPU/Resources"| C["OS Layer\n(Process Management, Timers)"]
    C -->|"Uses Deterministic Hardware"| D["Hardware Layer\n(CPU, Memory, Timers)"]
    D -->|"Feedback on Timing"| C
    C -->|"Schedules Tasks"| B
    B -->|"Executes Tasks"| A

Key Idea:

• The middleware (e.g., an RTOS) is critical—it enforces scheduling policies (e.g., Rate-Monotonic Scheduling for periodic tasks) to meet deadlines.
• The hardware must support deterministic timing (e.g., no unpredictable interrupts).

3. IEEE 1520 Standard: Task Models

The IEEE 1520 standard defines how tasks are modeled in RTS. Tasks are classified based on their temporal behavior:

Worked Example: Periodic Task in a Pacemaker

Scenario: A pacemaker must deliver an electrical pulse to the heart every 1 second (period = 1000ms). The task must complete within 50ms (deadline).

Task Parameters:

• Period (T): 1000ms
• Execution Time (C): 20ms
• Deadline (D): 50ms

Analysis:

• If the pacemaker’s RTOS uses Rate-Monotonic Scheduling (RMS), the task’s priority is based on its period (shorter period = higher priority).
• The utilization factor (U) is calculated as: U = \frac{C}{T} = \frac{20}{1000} = 0.02 \text{ (2% CPU usage)}
• For RMS to guarantee deadlines, the total utilization must be ≤ n(2^(1/n) - 1), where n is the number of tasks. Here, since U is very low, the deadline is easily met.

Real-World Tie-In:

• Medical devices (e.g., pacemakers, insulin pumps) use this model to ensure hard real-time constraints.
• Automotive systems (e.g., Tesla’s Autopilot) rely on periodic tasks for sensor fusion (e.g., camera + radar data every 10ms).

4. Hardware Requirements for Real-Time Systems

Hardware must support deterministic timing. Key components:

A. CPU and Scheduling

• Fixed-priority preemptive scheduling: Higher-priority tasks preempt lower-priority ones.
• No unpredictable delays: Avoid dynamic frequency scaling (DFS) or power-saving modes that introduce jitter.
• Example: ARM Cortex-M microcontrollers are designed for RTS with deterministic interrupt response times.

B. Memory Management

• Static memory allocation: Avoid dynamic memory (e.g., malloc in C) to prevent unpredictable delays.
• Memory protection: Ensure critical tasks (e.g., safety-critical code) cannot be overwritten.

C. Timers and Clocks

• High-resolution timers: Required for precise deadline enforcement (e.g., Linux’s hrtimer).
• Example: A watchdog timer in an embedded system resets the CPU if a task misses its deadline.

5. Middleware: The RTOS Kernel

The Real-Time Operating System (RTOS) is the middleware that:

1. Schedules tasks based on priorities/deadlines.
2. Manages synchronization (e.g., semaphores, mutexes) to avoid race conditions.
3. Provides timing services (e.g., delays, alarms).

Popular RTOS Kernels

How an RTOS Enforces Deadlines

sequenceDiagram
    participant App as Application Task
    participant RTOS as RTOS Kernel
    participant CPU as CPU Core
    participant Timer as Hardware Timer

```figure
{"type":"timeline","events":[{"time":"0ms","label":"Task starts (P1 priority)"},{"time":"10ms","label":"First time slice (20ms allocated)"},{"time":"30ms","label":"Task preempted by higher-priority task"},{"time":"40ms","label":"Resumes execution"},{"time":"50ms","label":"Deadline met (success)"}],"caption":"Detailed timeline of task execution with preemption and deadline enforcement."}

App->>RTOS: Task created with deadline (D=50ms)
RTOS->>CPU: Assigns priority (P1)
CPU->>Timer: Sets alarm for deadline (50ms)
loop Every 10ms
    CPU->>App: Executes task slice
    App->>CPU: Returns after 20ms
end
Timer->>RTOS: Times out (50ms reached)
RTOS->>App: Checks if task completed
alt Task completed
    RTOS->>App: Success
else Task missed deadline
    RTOS->>App: Trigger watchdog reset
end

Real-World Example: Pathao’s Ride-Matching System

• Periodic Task: Updates rider locations every 2 seconds (T=2000ms, C=50ms).
• Aperiodic Task: Handles emergency ride cancellations (deadline = 100ms).
• RTOS Used: Likely a custom Linux RT patch or FreeRTOS on edge servers to ensure low-latency matching.

6. Performance Analysis and Trade-offs

A. Metrics for Real-Time Systems

B. Trade-offs in RTS Design

7. Real-World Applications of the Reference Model

A. Medical Devices: Pacemakers and Insulin Pumps

• Layer Breakdown:
  • Application: Monitors heart rate (periodic task) or blood glucose (aperiodic).
  • Middleware: RTOS (e.g., FreeRTOS) schedules tasks with hard deadlines.
  • Hardware: Low-power ARM Cortex-M with watchdog timer.
• Why It Matters: A missed deadline could mean patient harm or death.

B. Autonomous Vehicles: Tesla’s Full Self-Driving (FSD)

• Periodic Tasks:
  • Sensor fusion (camera + radar) every 10ms (T=10ms, C=5ms).
  • Path planning every 50ms (T=50ms, C=20ms).
• Aperiodic Tasks:
  • Emergency brake (deadline = 50ms).
• RTOS Used: Likely a custom Linux RT or QNX for deterministic behavior.

C. Financial Systems: NEPSE Stock Trading Platform

• Aperiodic with Deadline:
  • Order execution must complete within 10ms of submission.
• Middleware: High-performance RTOS or bare-metal scheduling.
• Hardware: FPGA-based accelerators for ultra-low-latency trading.

D. Nepalese Example: NTC’s Smart Grid Monitoring

• Periodic Task: Monitors power line voltage every 100ms (T=100ms, C=10ms).
• Aperiodic Task: Handles power outage alerts (deadline = 50ms).
• RTOS: Likely a Linux RT patch for scalability.

8. Common Pitfalls and How to Avoid Them

9. Exam Tip: How This Unit is Tested

This unit is heavily tested in TU/PU exams through:

1. Definitions and Concepts (20% weight):

   • Differentiate between hard/soft real-time, periodic/aperiodic tasks.
   • Explain the IEEE 1520 task model and layered architecture.

2. Worked Examples (30% weight):

   • Calculate utilization (U) for a set of tasks.
   • Determine if a task set is schedulable under RMS or EDF.
   • Example:

     Given tasks: T1 (T=50ms, C=10ms), T2 (T=100ms, C=20ms). Is the set schedulable under RMS? Solution: $U=0.2+0.2=0.4$. For n=2, bound is $2(2^{1/2}-1)\approx 0.828$. Since $0.4\le 0.828$, yes.

3. Real-World Applications (20% weight):

   • Relate concepts to medical devices, automotive systems, or financial trading.
   • Example:

     How does a pacemaker use the layered RTS model? Answer: Application layer = heartbeat monitoring; middleware = RTOS scheduling; hardware = ARM Cortex-M with watchdog timer.

4. Diagrams and Comparisons (20% weight):

   • Draw the layered architecture or task scheduling timeline.
   • Compare RMS vs. EDF in a table.

5. Problem-Solving (10% weight):

   • Given a scenario (e.g., a drone’s sensor task), identify task type, deadline, and scheduling policy.

Common Exam Questions:

• "Explain the role of middleware in a real-time system with an example."
• "A system has two periodic tasks: T1 (T=30ms, C=10ms) and T2 (T=50ms, C=15ms). Is it schedulable under RMS? Show calculations."
• "How would you design a real-time system for an autonomous vehicle’s braking system?"

10. Summary Checklist for Students

Before the exam, ensure you can: ✅ Define hard vs. soft real-time and give Nepalese/global examples. ✅ Draw and label the layered RTS architecture (application → middleware → OS → hardware). ✅ Classify tasks as periodic, aperiodic, or sporadic and calculate utilization (U). ✅ Explain Rate-Monotonic Scheduling (RMS) and Earliest Deadline First (EDF). ✅ Describe two real-world systems (e.g., pacemaker, Tesla FSD) using this model. ✅ Solve schedulability tests for given task sets. ✅ Identify common pitfalls (priority inversion, jitter) and their solutions.

Final Note: Real-time systems are everywhere—from life-saving medical devices to high-frequency trading. Mastering this unit means understanding how timing constraints are enforced across hardware and software layers. Focus on worked examples and real-world ties (like NTC’s smart grid or Pathao’s ride-matching) to ace the exam!