Run-Time Assurance

RTA systems are built upon mathematically defined safety invariants—absolute rules that must never be violated, such as maintaining a minimum separation distance or staying within a geofence. These invariants are specified using formal methods like temporal logic or barrier certificates, providing a provable guarantee that the system will not enter an unsafe state regardless of what the primary autonomy controller commands.

A defining characteristic of RTA is that it operates as an independent, external monitor that does not require modification to the primary autonomy stack. The RTA sits between the autonomy controller and the actuators, passively observing proposed actions and only intervening when a violation is imminent. This separation of concerns allows complex, unverified controllers—including learned policies—to be deployed safely.

RTA commonly employs a Simplex architecture consisting of two controllers:

• High-Performance Controller: A complex, potentially unverified autonomy stack that optimizes for mission objectives
• Safety Controller: A simple, formally verified backup that guarantees safety invariants

The RTA decision logic switches from the high-performance controller to the safety controller when a violation is predicted, then returns control once the system is safe.

To predict imminent violations, RTA systems compute the forward-reachable set—the envelope of all possible future states the agent could occupy within a bounded time horizon given its current velocity, acceleration limits, and control authority. If any state in this reachable set intersects with an unsafe region, the RTA intervenes before the agent can physically enter danger.

RTA is designed to be minimally invasive, intervening only when absolutely necessary and only to the degree required to restore safety. Rather than taking full control, an RTA may apply a corrective action such as a velocity reduction or a steering adjustment that minimally deviates from the primary controller's intent while guaranteeing the safety invariant is maintained.

RTA systems must execute with hard real-time guarantees, completing their monitoring and intervention logic within a bounded worst-case execution time. This requires deterministic algorithms running on real-time operating systems or dedicated hardware, ensuring that the safety check is never delayed by garbage collection, scheduling jitter, or network latency.

A stable, safe state to which an autonomous agent must default when it encounters a failure or exits its Operational Design Domain (ODD). RTA systems are explicitly designed to enforce a transition to this state when safety invariants are violated.

• Example: A mobile robot coming to a complete stop in a designated safe zone.
• Example: A drone initiating a controlled landing at a pre-defined geofenced location.
• Key Distinction: This is not simply a power-off; it is a deliberate, verified safe posture.

The specific set of operating conditions under which a given autonomous system is designed to function safely. RTA acts as the hard boundary enforcer for the ODD.

• Includes: Environmental conditions (rain, lighting), geographical limits (geofences), and time-of-day restrictions.
• RTA Role: Continuously verifies that the agent remains within its declared ODD and triggers a Minimal Risk Condition upon violation.
• Design Implication: A narrower ODD simplifies RTA design but limits operational utility.

A design principle ensuring that a system, in the event of a failure, defaults to a condition that minimizes harm. RTA is the active mechanism that detects the failure and commands the transition to this state.

• Contrast with Fail-Operational: Fail-safe prioritizes safety over continued function; fail-operational systems attempt to maintain degraded functionality.
• Physical Examples: A robot engaging its brakes, a gripper releasing its payload, or a drone deploying a parachute.
• Software Examples: A planning module ceasing to send new waypoints and reverting to a verified holding pattern.

The time delay between an operator issuing a command and the remote agent executing it. RTA must account for this latency when a human is in the loop for Takeover Requests.

• Components: Network lag, video encoding/decoding time, and system processing overhead.
• RTA Constraint: If intervention latency exceeds the time-to-collision for a detected hazard, the RTA must autonomously trigger a safety response without waiting for human input.
• Metric: Measured in milliseconds; sub-100ms is a common target for ground vehicles.

A signal from an autonomous agent to a human operator, requesting immediate manual control due to an edge case, system uncertainty, or a detected ODD violation. RTA manages the safety envelope during this handoff.

• RTA Function: Maintains a safe holding pattern or executes a Minimal Risk Condition if the operator does not respond within a predefined timeout window.
• Interface Design: Must clearly communicate the reason for the request and the remaining time budget for a safe response.
• Data Logging: Every takeover request is a critical data point for improving the autonomy stack's edge-case handling.

A hardware or software timer that triggers a system reset or a safe-state transition if it is not periodically reset by the main control program. This is a foundational, low-level RTA mechanism.

• Mechanism: The primary control loop must 'kick the dog' at a fixed interval. If the loop hangs or crashes, the timer expires and forces a safe state.
• Independence: A true watchdog must operate on an independent clock and power domain from the main processor it is monitoring.
• RTA Hierarchy: Watchdog timers are the last-resort safety net beneath more sophisticated, logic-checking RTA modules.