What is WCET and why is it central to hard real-time?

WCET is the Worst-Case Execution Time, the longest a piece of code can possibly take to run, accounting for the worst-case control path, worst-case input data, cache misses, pipeline stalls, and interference from interrupts. It's central to hard real-time because guaranteeing a deadline requires knowing the maximum time a task can consume; you can't prove a task always finishes within its deadline without an upper bound on how long it runs, and schedulability analysis (does the whole task set fit?) is built entirely on each task's WCET and period. The difficulty is that WCET is genuinely hard to obtain: the true worst case may be a rare path or data pattern that almost never appears in testing, so a measured maximum can underestimate it; and modern CPU features, caches, branch prediction, deep pipelines, speculative execution, make timing data- and history-dependent, so the same instruction sequence varies in duration depending on machine state. Approaches include static WCET analysis tools that bound the longest path, exhaustive measurement with safety margin, and, most robustly, designing code whose timing is inherently bounded and simple (no dynamic allocation, no data-dependent unbounded loops, simple deterministic cores). Because of this difficulty, hard real-time systems often favor simpler, more predictable processors over high-performance ones with hard-to-bound timing. WCET is the foundation: no WCET, no guarantee.