When a Correct Braking Decision Is 2 s Late: Real‑Time, RTOS, and Watchdog Basics

An automotive braking controller may compute the correct decision, but if the actuation occurs two seconds later the system is deemed a failure because embedded systems must produce correct results within a prescribed deadline.

Embedded systems are special‑purpose computers that tightly couple information processing with physical actions and are constrained by real‑time, limited CPU/memory/power, cost, size, reliability, and safety requirements. These six attributes form the core exam focus.

Typical exam keywords that signal an embedded‑system question include: device control, sensors and actuators, timing constraints, limited resources, low power, configurability, safety‑critical, host and target machines, and hardware‑software co‑design.

The modern embedded stack is often described as five layers, illustrated below:

┌─────────────────────────┐
│ Application Layer:      │
│   risk assessment,      │
│   braking strategy      │
├─────────────────────────┤
│ Middleware Layer:        │
│   communication, DB,   │
│   graphics, etc.       │
├─────────────────────────┤
│ OS Layer (RTOS):         │
│   tasks, clocks,        │
│   interrupts, resources│
├─────────────────────────┤
│ Abstraction Layer:      │
│   HAL, BSP, drivers     │
├─────────────────────────┤
│ Hardware Layer:         │
│   processor, sensors,   │
│   I/O, watchdog circuit │
└─────────────────────────┘

The hardware layer provides the processor, memory, timers, I/O interfaces, buses, sensors, actuators, and a watchdog circuit. Sensors convert the physical world into inputs, while actuators turn computation results into real actions. For example:

Radar measures distance
   ↓
Controller judges collision risk
   ↓
Brake actuator engages

The abstraction layer hides board‑specific differences. HAL (Hardware Abstraction Layer) offers a uniform API for hardware capabilities, and BSP (Board Support Package) contains board‑level initialization and driver code. Changing to a different board typically only requires updating the BSP and drivers, leaving the upper‑level braking logic untouched.

Both HAL and BSP isolate hardware variations to improve software portability.

The RTOS manages resources and provides deterministic behavior. Its core responsibilities include task scheduling, interrupt handling, clock/timer management, inter‑task communication/synchronization, and memory/device resource management.

Middleware supplies reusable services such as communication, messaging, embedded databases, graphics, and device‑interconnect. Simple controllers may omit a distinct middleware layer.

The application layer implements domain‑specific functions: risk assessment, braking strategy, fault diagnosis, status display, and alarm handling.

Real‑time correctness has two dimensions: logical correctness (the result is right) and temporal correctness (the result appears before the deadline). Consider two systems for a 30 ms braking deadline:

System A: average 2 ms, occasional 500 ms spikes
System B: consistently 15–20 ms

Although System A is faster on average, its worst‑case latency makes it unsuitable for safety‑critical braking; System B is preferred because its response is predictable.

Strong (hard) real‑time systems cannot miss a deadline without severe consequences (e.g., airbags, brakes, flight control), whereas weak (soft) real‑time systems tolerate occasional overruns with only degraded user experience (e.g., video playback).

Ask: "What happens if a deadline is missed?" – that is the decisive question.

RTOS is not a processor or sensor; it is system software that runs on the processor. It provides predictable scheduling for urgent tasks. For instance, when a display task runs and a sensor interrupt arrives:

Display task refreshing screen
   ↓
Sensor interrupt generated
   ↓
RTOS wakes high‑priority brake task
   ↓
Brake task pre‑empts display task
   ↓
After brake calculation, display task resumes

Key RTOS properties are higher priority for urgent tasks, timely handling of events, and bounded scheduling/interrupt latency.

Common RTOS misconceptions

Using an RTOS automatically guarantees real‑time performance.

This is false; improper priority design, long‑running CPU‑bound sections, resource contention, or algorithms with excessive worst‑case execution time can still cause deadline misses.

All embedded systems must run an RTOS.

This is also false; very simple, fixed‑function controllers can run bare‑metal code. An RTOS becomes valuable when tasks multiply, concurrency grows, or strict timing is required.

Soft‑hardware co‑design decides which functions are implemented in hardware and which in software, considering timing, computational load, flexibility, power, cost, size, reliability, safety, and development schedule.

Performance & determinism – hardware usually offers higher and more stable performance.

Flexibility – software changes are easier than hardware redesign.

Development cost – dedicated hardware incurs higher upfront cost.

Power – specialized hardware can be more efficient.

Time‑to‑market – software iterations are generally faster.

In the braking controller, hardware handles sensor sampling, timers, interrupts, bus communication, actuator output, and the watchdog. The RTOS schedules high‑priority tasks for acquisition, risk assessment, braking, communication, and logging. Application software performs data fusion, collision judgment, vehicle‑specific strategies, and fault diagnosis.

The watchdog is a timer that must be periodically “fed”. Normal operation resets the counter; if the program hangs, the counter expires, fault information is saved, and a reset or interrupt is triggered.

Normal operation:
   Program feeds watchdog → counter reset → system runs
Program hangs:
   No feed → counter expires → fault info saved → reset/reboot

Watchdog cannot detect logical errors that keep the program running; therefore it does not replace input validation, sensor cross‑checking, fault diagnosis, redundancy, or safety‑state design.

Reliability vs. Safety

Reliability: completing required functions within specified conditions and time.
Safety: ensuring that failure does not cause unacceptable harm.

For example, a brake controller that runs without failure demonstrates reliability, while disabling actuation on a faulty sensor to avoid dangerous motion demonstrates safety.

Embedded development uses two environments: the host machine (developer’s PC) for writing, compiling, and debugging, and the target machine (the actual device) for execution. The workflow is cross‑compilation followed by downloading the binary to the target.

Host writes code → cross‑compiler produces target binary → download via network/serial/JTAG → target runs → host continues debugging

Exam case study: an automatic emergency braking controller must sample radar and speed every 10 ms, issue a brake command within 30 ms, operate under limited CPU/memory/power, run continuously, tolerate sensor faults, recover from hangs, and be configurable for different vehicle models. The answer classifies the system as a resource‑constrained, safety‑critical, strong‑real‑time embedded system and describes the five‑layer architecture, RTOS task priorities, soft‑hardware partitioning, watchdog usage, and verification methods such as worst‑case latency testing and fault‑injection.

In summary, embedded systems are not merely “small computers”. They integrate tightly with physical processes, obey strict real‑time and safety constraints, and are organized into hardware, abstraction, OS, middleware, and application layers. Proper use of HAL/BSP, RTOS, soft‑hardware co‑design, and watchdog timers ensures deterministic behavior and reliable recovery, while cross‑development bridges the host‑target divide.