Runtime Assurance (RTA)

The Primary Controller is the high-performance, often complex, algorithm responsible for the agent's nominal operation. This can be a learning-based system (e.g., a neural network policy), a sophisticated optimization-based planner, or any controller where formal verification of its safety under all conditions is intractable.

• Role: Executes the main task, such as navigation or manipulation.
• Characteristics: May be adaptive and high-performing but not provably safe in all edge cases.
• Example: A deep reinforcement learning agent trained for efficient path planning in a warehouse.

The Safety Monitor (or Safety Shield) is a formally verified, simpler component that runs in parallel with the primary controller. Its sole function is to predict whether the primary controller's commanded actions will violate a predefined safety property (e.g., "maintain a minimum distance from all obstacles") within a finite time horizon.

• Verification: Its logic is simple enough to be formally verified or exhaustively tested.
• Output: A binary permit/override signal.
• Critical Requirement: Must have a bounded and guaranteed Worst-Case Execution Time (WCET) to ensure timely intervention.

The Verified Safe Controller is a backup control law that is guaranteed to keep the system within its safe operating envelope. It is typically conservative and simple (e.g., a stopping maneuver, a gradient-following controller). When the Safety Monitor issues an override, this controller's commands are executed instead of the primary controller's.

• Design Principle: Simplicity and verifiability over performance.
• Common Forms: Emergency stop, follow a pre-computed safe trajectory, or execute a formally verified control barrier function (CBF).
• Guarantee: Provides a Minimal Risk Condition (MRC) when the primary controller is unsafe.

The Switching Logic is the deterministic mechanism that arbitrates between the primary controller and the verified safe controller based on the Safety Monitor's output. This component must be logically and temporally sound to prevent glitches or race conditions.

• Function: Executes a clean, instantaneous switch between control authorities.
• Key Consideration: Must account for system dynamics during the switch to avoid introducing instability.
• Certification: This logic is often a critical part of the system's safety case for standards like ISO 26262 (automotive) or DO-178C (aerospace).

The Formal Safety Specification is the unambiguous, mathematical definition of the system's safe operating conditions. It is the foundational requirement against which the Safety Monitor and Verified Safe Controller are designed and verified.

• Expression: Often written as invariants (e.g., distance(agent, obstacle) > d_min) or using temporal logic.
• Purpose: Provides the "ground truth" for what constitutes a safety violation.
• Example: "For all times t, the robot shall not be inside any inflated obstacle region as defined by the occupancy grid."

The Real-Time Execution Platform is the hardware and operating system that guarantees the deterministic, timely execution of the entire RTA loop. This includes sensor ingestion, monitor computation, and control switching within a hard deadline.

• Requirements: Predictable scheduling, bounded interrupt latency, and time-synchronized processes.
• Enabling Technology: Real-time operating systems (RTOS) or carefully configured Linux kernels with PREEMPT_RT patches.
• Importance: A theoretically perfect safety monitor is useless if its "unsafe" signal arrives after a collision has already occurred.

A Safety Monitor is a verified software component that continuously observes the state of a system and the commands from its primary controller. Its sole purpose is to detect violations of predefined safety properties (e.g., "maintain minimum distance from all obstacles"). Upon detecting an imminent violation, it can trigger an override or a safety intervention. In an RTA architecture, the safety monitor is the core decision-making element that authorizes or vetoes actions from a complex, potentially unverifiable controller (like a neural network).

A Control Barrier Function (CBF) is a mathematical formalism used to synthesize safety filters. It defines a safe set of system states (e.g., all positions outside a collision zone). The CBF condition, when enforced by the controller, guarantees the system state will remain within this safe set for all future time. In RTA, a CBF-based safety filter can be the override controller, providing a formally proven corrective action that is minimally invasive to the primary controller's intent while ensuring hard safety guarantees.

The Simplex Architecture is a foundational design pattern for runtime assurance where a complex, high-performance advanced controller (AC) operates in tandem with a simple, verifiable base controller (BC). A decision module (the safety monitor) checks the AC's outputs. If they are deemed unsafe, control is switched to the BC. This provides a fail-operational capability. RTA is a generalization of this pattern, where the override mechanism can be more sophisticated than a simple switch, potentially applying corrective actions before reverting to a base controller.

Formal Verification is the process of using mathematical logic to prove or disprove the correctness of a system with respect to a formal specification. For RTA, the critical components that must be formally verified are:

• The safety monitor's logic (to ensure it correctly identifies all unsafe states).
• The safety controller's dynamics (to prove its corrective actions will keep the system safe).
• The switching logic (to ensure timely and deterministic intervention). This verification provides the highest level of assurance, distinguishing RTA from heuristic-based safety systems.

Run-Time Verification (RTV) is a broader field that RTA falls under. RTV involves checking system behavior against formal specifications during execution. While RTV is primarily a monitoring and detection discipline, RTA adds the critical layer of automatic mitigation. Think of RTV as a diagnostic tool that raises an alarm, while RTA is a closed-loop control system that both diagnoses and treats the problem in real-time to prevent a safety violation.

A Minimal Risk Condition (MRC) is a safe state a system must enter upon a failure or when its operational limits are exceeded. In the context of RTA, if the safety monitor cannot find a safe override command that allows progress toward the goal, its final action is to command a transition to the MRC. For a mobile robot, this is often a controlled stop in its current lane. Defining the MRC is a key system-level safety requirement, and the RTA architecture must guarantee the system can reach it from any unsafe state.