A Safety-Driven Architectural Framework for Fail-Operational Drone Swarms in Critical Missions

Abstract: The certification of Unmanned Aerial Vehicle (UAV) swarms for safety-critical operations requires verifiable design assurance. Airworthiness standards demand deterministic reliability, whereas multi-agent coordination algorithms execute non-deterministic models. This paper proposes a mixed-criticality architectural framework that applies SAE ARP4754B methods to swarm reconfiguration. First, a hardware-isolated Safety Monitor functions as a Run-Time Assurance (RTA) gateway, decoupling the flight-critical core from the non-deterministic Swarm Manager. Second, the monitor enforces formal safety contracts based on agent Health Vectors derived systematically from a Functional Hazard Assessment (FHA). Third, the framework propagates these Health Vectors to the collective planner to trigger fail-operational task reallocation, enabling intelligent swarm behaviors without compromising flight-critical isolation. Markov reliability modeling demonstrates that the $10<sup>{-7}$ failures per flight hour Hazardous target is theoretically achievable for our SAIL IV scenario, provided the Safety Monitor meets $C_{monitor}&gt;0.9991$, consistent with DAL B CMD/MON implementations.

• The paper introduces a safety-driven architectural framework for fail-operational drone swarms, featuring a hardware-isolated Safety Monitor and quantitative Markov analysis to ensure a failure probability below $10^{-7}$ per flight hour for critical missions.
• The framework employs a dual-channel redundant Flight-Critical Core, a fail-silent Mission and Perception System, and a finite state machine for swarm-level fault management, facilitating graceful task reallocation among healthy agents.
• The comparative study of Software Development Assurance Level (DAL) assignments optimizes software reliability, arguing for reduced assurance for bounded functions provided monitoring reaches certain coverage thresholds.

Problem statement and motivation

Certifying UAV swarms for safety-critical operations such as Beyond Visual Line of Sight (BVLOS) search and rescue requires reconciling two fundamentally different engineering traditions. Airworthiness standards demand deterministic, verifiable reliability targets, while multi-agent coordination algorithms are inherently non-deterministic and resist formal assurance. The paper frames this as a mixed-criticality integration problem: safety-critical flight control laws must coexist with complex, unverified swarm logic under a regulatory regime—JARUS SORA at SAIL IV for a sparsely populated SAR scenario—that imposes a Hazardous failure probability below $10^{-7}$ per flight hour (e.g., uncontrolled single-drone crash) and $10^{-9}$ per flight hour for Catastrophic conditions such as multi-vehicle collision or unauthorized swarm control.

The authors identify an architectural gap between fault-tolerant avionics, which treats the individual platform as the system boundary and defaults to solitary emergency landing on unrecoverable faults, and health-aware swarm robotics research, which optimizes mission performance but depends on the very software layer that may be compromised and lacks the formal isolation needed for certification. Existing Run-Time Assurance (RTA) frameworks based on the Simplex Architecture enforce only local fail-safe maneuvers without propagating verified health states to the collective.

Contributions

The paper makes three claims of contribution:

1. Hardware-isolated Safety Monitor: unlike software self-reporting approaches, a hardware-isolated FMU enforces the accuracy of health state, guaranteeing reconfiguration decisions rest on trusted data.
2. Systematic derivation of agent health states from FHA, providing traceability from component-level faults to swarm reconfiguration behaviors.
3. Quantitative Markov analysis deriving the Safety Monitor diagnostic coverage required to satisfy the $10^{-7}$ per flight hour target.

The evaluation is explicitly conceptual: it relies on architectural traceability, Markov modeling, and a ConOps walkthrough; hardware implementation, formal software verification, and flight testing are declared out of scope.

Safety-driven methodology

Following ARP4754B/ARP4761A adapted to multi-agent systems, the design proceeds through Preliminary HazID, FHA with DAL assignment, and Contract-Based Design to derive formal interfaces. The FHA partitions the system: the Safety Monitor (FMU) is assigned DAL B consistent with its Hazardous classification; navigation, flight control, and power management operate at DAL C using dual-channel redundancy (dual-channel failure probability $\lambda_{ch}^2 \approx 10^{-8}$/hr, one order below the Hazardous threshold); non-deterministic swarm coordination functions are assigned DAL D because the DAL B monitor validates all trajectory commands via safety contracts. Notably, the paper argues F4-class failures (corrupted swarm broadcast) can be developed at DAL D provided monitor coverage exceeds 0.9991—an explicit claim that monitoring permits reduced development assurance for the bounded function, per ASTM F3269.

Faults propagate through a three-tier abstraction: atomic signals (RPM mismatch, battery voltage, GNSS HDOP, heartbeat timeout, SNR) map via thresholds to discrete functional states $$\sigma \in \{\text{NOMINAL}, \text{DEGRADED}, \text{FAILED}\}$$, aggregated into a Health Vector:

$$H_i(t) = \langle \sigma_{nav}, \sigma_{prop}, \sigma_{comm} \rangle$$

Three contracts bound agent behavior: $\mathcal{C}_{prop}$ restricts velocity on actuator or power anomalies; $\mathcal{C}_{nav}$ forces controlled landing on GNSS degradation; $\mathcal{C}_{comm}$ triggers Return-to-Base on link loss. Timing bounds are derived physically: for a representative hexacopter with worst-case thrust asymmetry, time-to-divergence yields $\tau_{max}$ in the range of 80–150 ms, supporting the 100 ms detection-plus-enforcement design target. The authors state plainly that these contracts provide necessary but not sufficient conditions for system safety; sufficiency requires formal verification of FMU logic, which remains future work. Coverage of compound multi-subsystem failures is deferred to architectural redundancy and qualitative FTA rather than handled in the contracts themselves.

Fail-operational architecture

At the agent level, the architecture separates a dual-channel redundant Flight-Critical Core (DAL C) executing on partitioned RTOS infrastructure from a fail-silent Mission and Perception System (DAL D), mediated by the FMU—a hardware-isolated RTA gateway extending System-Level Simplex (2608.20906). Communication flows over a dedicated Safety Monitor Interface (SMI), a physical channel distinct from the dual CAN buses so that primary-bus failures (e.g., message floods) cannot block safety commands. The FMU applies a "Lock and Filter" mechanism: supervisory overrides take precedence over mission inputs when contracts are breached, while the aggregated Health Vector is broadcast outward to inform collective behavior.

At the swarm level, a finite state machine routes any critical fault into either RTB (if control capability is retained) or emergency landing. This enables a two-tiered response: degraded agents are gracefully retasked to low-agility roles such as communication relay, while lost agents trigger task reallocation among healthy peers. The planner interface is deliberately algorithm-agnostic: a cost function $10^{-9}$0 prices degraded agents out of agility tasks (infinite penalty) but keeps them competitive for relay tasks via a finite penalty $10^{-9}$1. The authors concede $10^{-9}$2 calibration is a planner-level decision outside their framework's scope, and a cost-function malfunction is itself treated as an F4-class failure contained by FMU trajectory validation.

Quantitative reliability results

The central quantitative result comes from a CTMC model with three states: nominal, contained-failure (fail-operational), and hazardous. Using a first-order rare-event approximation,

$10^{-9}$3

with $10^{-9}$4/hr as a bounding estimate for a single-channel flight computer and $10^{-9}$5/hr as a design requirement for the FMU, solving for compliance against $10^{-9}$6/hr yields the headline result:

$10^{-9}$7

consistent with DAL B CMD/MON implementations. A sensitivity analysis shows the requirement scales with assumed flight computer reliability—from $10^{-9}$8 (DAL A territory) at $10^{-9}$9 down to $10^{-7}$0 (software monitor sufficient) at $10^{-7}$1—so the architecture remains compliant across a broad range of assumptions. Secondary failures during the bounded RTB exposure window contribute at most $10^{-7}$2, justifying omission from the bounding approximation. Communication-induced hazards are architecturally excluded by the deterministic RTB enforcement in $10^{-7}$3, conditional on the design requirement $10^{-7}$4, which the paper flags as needing verification during hardware selection.

A ConOps walkthrough traces a motor winding short on Agent D end-to-end within timing budgets: detection by correlating yaw divergence and current spike within 50 ms, contract enforcement (Hex-to-Quad allocation, velocity restriction) completing at 100 ms, Health Vector propagation by 200 ms, and decentralized task reallocation by 500 ms—with transient inter-agent spacing delegated to the reactive ODCAS layer under the requirement $10^{-7}$5, again deferred to integration-time verification.

Limitations and open questions

The authors are explicit about several dependencies. First, all quantitative results are model-based: the compliance claim rests entirely on achieving $10^{-7}$6, which has not been demonstrated and would require targeted fault-injection campaigns. Second, the model assumes independence between the Safety Monitor and the Mission Computer; shared power buses or clock lines introduce common-cause failure potential not analyzed here. Third, the framework defines the interface between health states and planning but does not address convergence speed of the distributed replanner, and V&V of non-deterministic algorithms remains an acknowledged open problem. Fourth, SWaP overhead from hardware isolation and redundancy confines applicability to payload-capable platforms above roughly 10 kg MTOW, excluding micro-UAV swarms. Finally, the latency bound ($10^{-7}$7), the ODCAS timing requirement, and the communication subsystem reliability target are all stated as platform-level specifications pending hardware verification.

Conclusion

This paper contributes a traceable, standards-aligned path from component faults to certified swarm reconfiguration: a DAL B hardware-isolated Safety Monitor enforcing formally derived safety contracts, a hierarchical Health Vector abstraction decoupling swarm logic from hardware specifics, and a Markov-derived coverage requirement establishing theoretical feasibility of the SORA SAIL IV Hazardous target. Its principal strength is the explicit coupling between certification artifacts (FHA, DAL assignments, SSRs) and runtime mechanisms (SMI, contract enforcement, penalty-based reallocation). Its principal weakness is that every quantitative claim is conditional on undemonstrated monitor coverage and independence assumptions; HIL verification of the FMU with FPGA hardware, including fault injection relative to contract bounds, is the identified next step before the theoretical argument can be considered validated.