A real-time safety framework: enforcing safety inside the control loop, not after it
Most safety work happens offline, in standards, test suites, and verification done before deployment. But a learned machine acting among people fails at runtime, in situations no test anticipated. This work studies the runtime layer that monitors perception, prediction, and action while the machine operates, and intervenes within the control loop's time budget.
Offline assurance can never be complete for a learned system operating in an open world. The standards are written, the test suite is run, the verification is done, and then the machine meets a situation no one enumerated. For a fixed industrial arm that gap is small, because its world is controlled. For a general-purpose machine moving among people it is the whole problem: the failures that matter are exactly the ones the offline process did not see. Something has to carry the safety case at runtime, while the machine is acting.
A real-time safety framework is that something. It is an online layer that watches the machine's own perception, prediction, and intended actions as they happen, checks them against safety constraints, and intervenes before an unsafe action is committed. It is the runtime counterpart to the offline stack: where standards and verification ask "was this system built safely," the runtime framework asks "is this specific action, in this specific scene, safe right now." The properties that make such a layer trustworthy are demanding:
- Bounded latency: a safety decision is only useful if it arrives inside the control loop's time budget, so the monitor must be fast enough to act before the machine does
- Runtime monitoring of the machine's own confidence: it has to detect when perception or prediction has moved outside the regime where the system was validated, and treat that as a hazard in itself
- A safe fallback that is actually safe: stopping, slowing, or yielding is not automatically safe for a tall, mobile, or fast machine near people, so the fallback has to be reasoned about, not assumed
- Verifiability of the monitor itself: a runtime guard that cannot be trusted adds a failure mode rather than removing one, so the layer must be simpler and more auditable than the policy it guards
This work studies how such a framework composes with the rest of the stack. It sits on top of the perception layer and the safety world model, turning their reads and forecasts into a runtime decision, and it sits beneath the regulatory and standards layer, supplying the operational evidence a safety case needs. The central question is whether a runtime layer can be made fast enough, trustworthy enough, and well-bounded enough to carry the part of the safety burden that offline assurance structurally cannot.
What you're reading is the abstract.