Worst-case timing analysis traditionally begins with estimating the worst-case execution time (WCET) of individual tasks using either static analysis or measurement-based techniques. To derive worst-case response times (WCRTs), engineers typically compose these WCETs with bounds on preemption and operating system overheads. However, WCRTs depend on complex system-level interactions, including task communication, OS behavior, and asynchronous events. Compositional analysis often overestimates, assuming that worst-case conditions across components coincide, admitting infeasible global control-flow paths. whole-system Static techniques refine this by modeling the system holistically but require platform-specific tailoring or extensive annotations. A dynamic equivalent has been missing. We present Fret, the first dynamic whole-system approach for estimating WCRTs. Fret employs feedback-guided fuzzing to uncover timing-critical dependencies, including inter-task communication, task/OS interactions, and interrupt effects, without requiring prior knowledge of inputs or states. Implemented using LibAFL and evaluated on FreeRTOS with realistic benchmarks, FRET consistently outperforms state-of-the-art fuzzing strategies in estimating accurate response times. Although not sound, Fret delivers more than timing estimates: it produces actionable artifacts-worst-case inputs, interrupt schedules, and intertask program-flow information-that complement static analyses and support system validation, runtime monitoring, and robust mixed-criticality scheduling.

The widespread adoption of cyber-physical systems in the safety-critical (hard real-time) domain is accompanied by a rising degree of code-reuse up to actual software product lines spanning different hardware platforms. Nevertheless, the dominant tools for static worst-case execution-time (WCET) analysis operate on individual, specific system instances at the binary level, further depending on machine-code–level annotations for precise analysis. Thus, this timing verification is neither portable nor reusable.

The static timing analysis of universal real-time operating systems (RTOS) with generically implemented services requires application and system-context-specific knowledge (e.g., number of currently active tasks) to bound overheads. However, due to the missing notion of OS semantics, contemporary timing analysis tools are unable to exploit such information, resulting in failing or overly pessimistic analysis. To tackle this issue, we present our System-wide WCET Analyses framework (SWAN). SWAN's heart is Platina, a parametric source-level annotation language that facilitates the expression and propagation of context information from the application over the OS down to the machine-code level. Through the expression of semantic interdependencies in a unified and reusable way, analysis pessimism is significantly reduced, as we demonstrate by case studies on FreeRTOS, Linux, and a real-world flight-control system. Just as important as our system-aware timing analysis is the tool support for its practical usability. Therefore, we augmented SWAN by a powerful interactive visualization and annotation environment. This enables developers to quickly identify context-dependent spots that require annotation and thus to cope with large implementations associated with universal RTOSs. Eventually, SWAN allows determining if a generically implemented system is real-time capable and thus timeliness is guaranteed.

Soft errors are a challenging and urging problem in the domain of safety-critical embedded systems. For decades, checking schemes have been investigated and improved to mitigate soft-error effects for the class of control-flow faults, with current industrial standards strongly recommending their use. However, reality looks different: Taking a systems perspective, we implemented four representative Control-Flow Checking (CFC) schemes and put them through their paces in 396 fault-injection campaigns. In contrast to previous work, which typically relied on probability-based vulnerability metrics, we accounted for the influence of memory and time overheads on the fault-space dimensions and applied those in full-scan fault injections. This change in procedure alone severely degraded the perceived effectiveness of CFC. In addition, we expanded the perspective to data-flow faults and their influence on the overall susceptibility, an aspect that so far has been largely ignored. Our results suggest that, without accompanying measures, any improvement regarding control-flow faults is dominated by the increase in data faults caused by the increased attack surface in terms of memory and runtime overhead. Moreover, CFC performance less depended on the detection capabilities than on general aspects of the concrete binary compilation and execution. In conclusion, incorporating CFC is not as straightforward as often assumed and the vulnerability of systems with hardened control-flow may in many cases even be increased by the schemes themselves.