Source-linked AI summary
A Safety-Driven Architectural Framework for Fail-Operational Drone Swarms in Critical Missions
Luiz Giacomossi, Zafer Yigit, Marwan Shakarna, Shoaib Saleemi, Ivan Tomasic, Baran Çurüklü, Håkan Forsberg
TL;DR
Safety-critical UAV swarms need design assurance that accommodates non-deterministic coordination without compromising deterministic flight safety. The paper proposes a mixed-criticality architecture using a hardware-isolated RTA Safety Monitor, FHA-derived Health Vectors, and formal safety contracts. Markov analysis indicates that the Hazardous target is theoretically achievable for the SAIL IV scenario when Cmonitor > 0.9991, but the result remains model-based and depends on independence and coverage assumptions.
Problem
UAV swarm certification must reconcile deterministic airworthiness requirements with non-deterministic multi-agent coordination in safety-critical missions.
Method
The framework uses ARP4754B-based mixed-criticality design, hardware-isolated monitoring, FHA-derived Health Vectors, formal safety contracts, and planner-facing task reallocation.
Results
Cmonitor > 0.9991 theoretically supports the 10^-7/hr Hazardous target for the SAIL IV scenario under the modeled architecture.
Takeaways & Limitations
The architecture links flight-critical reliability with collective resilience while isolating non-deterministic swarm logic behind verifiable monitoring and contracts.
Takeaways & Limitations
The reliability result is model-based and assumes Safety Monitor coverage above 0.9991 plus independence from the Mission Computer; practical verification remains future work.
Abstract
from arXiv · showhide
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^{-7}$ failures per flight hour Hazardous target is theoretically achievable for our SAIL IV scenario, provided the Safety Monitor meets $C_{monitor}>0.9991$, consistent with DAL B CMD/MON implementations.
I. INTRODUCTION
The paper addresses the certification gap between deterministic flight-critical avionics and non-deterministic swarm coordination by proposing a safety-driven, mixed-criticality architecture. It combines hardware isolation, formal safety assessment, and reliability modeling while remaining a conceptual, theoretically evaluated framework.
- Motivation: Multi-agent swarms improve area coverage but introduce non-deterministic emergent behavior that complicates formal certification for safety-critical missions.The reference case is a BVLOS search over a sparsely populated area classified as SAIL IV.
- Research Gap: Existing fault-tolerant avionics contain failures within individual aircraft, while health-aware swarm methods generally prioritize mission performance over design assurance.These domains leave an integration gap between deterministic fault containment and collective resilience.
- Approach: The proposed framework applies SAE ARP4754B and RTA principles to bound swarm behavior while preserving separation between trusted flight functions and complex swarm logic.The approach aligns its RTA mechanism with ASTM F3269-17.
- Contributions: A hardware-isolated Safety Monitor validates health information and supports trusted swarm reconfiguration rather than relying on software self-reporting.The architecture establishes traceability from component faults to swarm reconfiguration behaviors through FHA-derived health states.
- Scope: The framework extends to safety-critical multiagent systems beyond the illustrated SAIL IV search-and-rescue mission, provided mixed-criticality isolation is applicable.The paper explicitly presents the framework as conceptual and its safety argument as theoretical.
III. SAFETY-DRIVEN DESIGN METHODOLOGY
The methodology adapts aviation safety-assessment processes to define hazards, assurance levels, interfaces, and health-aware data flow for a mixed-criticality swarm. It uses formal contracts to connect physical faults with bounded collective behavior.
- Architecture: The architecture separates DAL B monitoring, DAL C flight control, and DAL D swarm coordination through hardware isolation and contract-based interfaces.Safety contracts bound permissible swarm behavior using assumptions and guarantees.
- Safety Assessment: HazID establishes swarm-level safety bounds, FHA assigns functions to DALs, and formal interface definition derives health states needed to contain identified hazards.These steps form a top-down design hierarchy.
- Hazard Analysis: The SAIL IV search-and-rescue scenario treats uncontrolled single-drone crashes as Hazardous events with a target probability below 10^-7/hr.The scenario assumes BVLOS operation in a sparsely populated environment.
Hierarchical Fault Abstraction and Health Vector:
The architecture converts sensor-level anomalies into discrete health states through FMU thresholds, bounded updates, and safety contracts that drive containment and recovery actions.
- Hierarchical abstraction: Atomic sensors detect localized faults, the FMU maps them to NOMINAL, DEGRADED, or FAILED states, and subsystem states aggregate into each agent’s Health Vector Hi.The hierarchy separates physical detection, functional evaluation, and agent-level aggregation.
- Timing and latency bounds: The Health Vector update must complete detection and contract enforcement within τmax, which is derived from the vehicle’s worst-case time to attitude divergence.For a hexacopter, τmax depends on thrust asymmetry, arm length, roll-axis inertia, and the maximum recoverable attitude deviation.
- Timing and latency bounds: 80–150 ms is the representative τmax range, supporting the 100 ms design target for the stated platform parameters.The 100 ms value remains a conservative platform-level requirement requiring hardware-integration verification.
- Safety contracts: The propulsion and navigation contracts translate RPM, battery, and GNSS conditions into restricted actuation or fail-safe navigation responses.The propulsion contract uses RPM mismatch or low battery voltage, while the navigation contract responds to excessive GNSS HDOP.
- Safety contracts: The communication contract monitors heartbeat timeout and SNR, enforcing Return-To-Base when link integrity falls below its safe condition.The three contracts provide necessary component-level coverage, while compound-failure coverage relies on flight-core redundancy and implementation-level sufficiency remains future work.
- Reliability implication: 10^-8/hr is reported for the analyzed catastrophic contribution, below the 10^-7/hr Hazardous threshold when Cmonitor > 0.9991.The paper presents this as a system-level theoretical result tied to Safety Monitor coverage.
D. System Safety Requirements (SSRs)
The SSRs partition responsibilities across flight control, monitoring, swarm coordination, task reallocation, and authenticated health-state communication.
- Flight-critical control: The Flight Critical Core shall maintain DAL C integrity for attitude estimation and control.This requirement is identified as SSR-FLT-01.
- Safety monitoring: The hardware-isolated DAL B Safety Monitor shall enforce the Safety Contract and achieve Cmonitor > 0.9991 diagnostic coverage for flight-critical faults.The coverage target is derived in the paper’s reliability analysis.
- Swarm coordination: No single point of failure in the validated DAL D Swarm Coordination Module shall cause a hazardous or catastrophic event.The requirement applies after Safety Monitor validation of the module’s behavior.
- Mission continuity: The swarm logic shall autonomously reallocate tasks when an agent reports a non-NOMINAL health state.This requirement connects agent health reporting to collective mission behavior.
- Communication security: All health-vector transmissions shall be authenticated to prevent unauthorized access.The requirement addresses threat H-07.
IV. FAIL-OPERATIONAL ARCHITECTURE
The proposed fail-operational architecture addresses fault tolerance at both the individual-agent and collective-swarm levels, combining local containment with mission continuity.
- IV. FAIL-OPERATIONAL ARCHITECTURE: The architecture uses two fault-tolerance layers: individual-agent containment and collective-swarm resilience.This hierarchy is intended to let the swarm maintain mission continuity while local faults are contained.
A. Individual Agent Architecture
The individual-agent architecture partitions flight-critical and mission functions across assurance levels, using an isolated DAL B FMU to contain non-deterministic swarm logic and monitor health.
- Architecture: The architecture separates a dual-channel DAL C Flight-Critical Core from a fail-silent DAL D Mission and Perception System.This hierarchical partitioning prevents mission-system software faults from propagating to the flight core.
- Safety Monitor: The hardware-isolated DAL B FMU implements the deterministic RTA Safety Monitor and enforces safety contracts using monitored health vectors.Its CMD/MON architecture protects against OS or middleware failures and supports the required hardware integrity of λmonitor hw ≈10^-8/hr.
- Flight-Critical Core: The NAV module uses redundant IMUs and GNSS receivers with a Kalman filter to produce a high-integrity state estimate and detect navigation faults.It is implemented as a DAL C software module on dual-channel flight computers.
- Flight-Critical Core: The FCS accepts FMU supervisory commands, including switching to a degraded control allocation matrix, while motor control applies degraded control maps to actuators.The FCS runs in a partitioned RTOS providing temporal and spatial isolation.
- Mission Functions: The SCM executes non-deterministic mission-level swarm algorithms while the FMU monitors its heartbeat and commands a safe contingency state after failure.The SCM receives the aggregated Health Vector for broadcast to the swarm mesh.
1) Safety Monitor Communication:
The communication and fault-handling design isolates safety traffic, converts module observations into FMU decisions, and propagates agent degradation to swarm-level contingency responses.
- Safety Monitor Communication: A dedicated bidirectional SMI isolates FMU safety commands from redundant CAN buses, preventing failures such as message floods from blocking them.Modules report health vectors to the FMU, which issues high-priority overriding commands to enforce safety contracts.
- Safety Monitor Communication: An actuator fault is reported as raw data, evaluated against the propulsion contract, and converted into a degraded state and safe-envelope override.The sequence connects module-level detection to deterministic FMU enforcement.
- Fault Handling: The individual-agent FSM separates nominal mission flow from fault handling and sends any critical fault into contingency planning.The reported fault severity determines whether the agent returns to base or performs an emergency landing.
- Fault Handling: An agent with sufficient navigation and control capability follows the RTB path, whereas a more severe fault triggers emergency landing and degraded-status broadcast.These paths preserve controlled recovery when possible and support coordinated collective response otherwise.
- Swarm Response: The swarm re-tasks controllable degraded drones to less critical roles and reallocates lost agents’ search areas among remaining healthy agents.Heartbeat timeout removes a lost agent from the active roster; low battery during RTB can trigger controlled mission termination through the propulsion contract.
C. Swarm-Level Interface: The Cost Function
The cost-function interface injects FMU-provided health information into algorithm-agnostic task allocation, assigning degraded agents selectively according to task suitability.
- Cost Function: The generic planner minimizes agent-task cost Jij by combining distance and a Health Vector-dependent penalty.The Swarm Manager receives Health Vector Hi from the Safety Monitor through the defined interface.
- Cost Function: The penalty function translates discrete Health Vector states into continuous planning costs, distinguishing nominal and degraded-agent assignments.This interface lets the architecture remain agnostic to the specific planning algorithm.
- Penalty Function: λdeg > 0 is a finite penalty for degraded agents performing relay tasks, calibrated so they remain competitive for relay tasks but are deprioritized relative to healthy agents.Its calibration is a planner-level design decision outside the framework’s scope.
- Penalty Function: Degraded agents incur infinite cost for high-agility tasks but finite λdeg for static relay tasks, realizing fail-operational behavior within the bounded DAL D module.A cost-function failure that mispenalizes degraded agents is treated as an F4-class failure.
V. ARCHITECTURAL ANALYSIS
The architecture is evaluated through traceability, fault-tree, and Markov analyses linking identified hazards to controls and quantifying Safety Monitor coverage requirements. The model yields a theoretical compliance boundary for the Hazardous target under stated reliability assumptions.
- Analysis Methods: Three complementary methods assess the design: architectural traceability, qualitative fault-tree analysis, and Continuous Time Markov Chain reliability modeling.The analyses respectively verify hazard-control links, defenses against swarm-emergent hazards, and the coverage requirement for the Hazardous target.
- Traceability: Every FHA hazard is mapped to a specific hardware or software architectural control.This traceability satisfies a primary ARP4754B design-assurance requirement.
- Reliability Model: 10^-7 per flight hour is the Hazardous target modeled for H-02 using a CTMC that explicitly captures Safety Monitor diagnostic coverage.The model includes nominal, degraded/safe, and hazardous states.
- Assumptions: Communication redundancy must satisfy λ_comm ≪ λ_FC = 10^-4/hr so the hazard rate remains dominated by Safety Monitor coverage.The C_comm contract deterministically initiates Return-to-Base upon link degradation.
- Coverage Requirement: C_monitor > 0.9991 is required when 10^-4·(1−C_monitor)+10^-8 < 10^-7.The requirement is derived by solving the model’s failure-condition inequality for monitor coverage.
- Sensitivity: A DAL B CMD/MON FMU satisfies the coverage requirement at λ_FC = 10^-4/hr, while λ_FC ≤10^-5/hr relaxes the monitoring requirement.The architecture’s compliance remains across the flight-computer reliability assumptions considered in Table V.
C. Comparative Analysis
The comparison positions the framework as extending RTA monitoring with health-data propagation to collective swarm planning. This adds SWaP overhead, but hardware isolation and redundancy provide the stated path to DAL B integrity.
- Comparative Analysis: ASTM F3269 provides the Safety Monitor concept but does not propagate the cause of a safety switch to the swarm.The framework addresses this by making the RTA monitor a source of health data for collective planning.
- Comparative Analysis: The framework’s health-data propagation connects Safety Monitor decisions with collective swarm reconfiguration.This is the architectural distinction identified in the comparison with existing RTA standards.
- Design Tradeoff: Hardware isolation and redundancy impose SWaP overhead, but that overhead is the mechanism used to achieve DAL B integrity without software-only assurance.The comparison presents this as a design tradeoff rather than a cost-free extension.
D. ConOps Verification: Actuator Degradation
The ConOps walkthrough traces a partial motor-failure response from detection and isolation through degraded control and swarm reallocation. The architecture’s scope and validation boundaries remain tied to model-based assumptions and future verification.
- ConOps Verification: Figure 7 traces a runtime fault sequence to verify timing and signal propagation against the system safety requirements.The sequence covers fault detection, isolation, and subsequent swarm response.
- Fault Detection and Isolation: A 40% thrust reduction from a motor winding short is detected within 50 ms using correlated yaw-rate and current-spike signals.The FMU then isolates the fault and commands Hex-to-Quad degraded control allocation by 100 ms.
- Timing Requirement: τ_OD ≪ d_min/v_rel max is required so detection-to-avoidance latency remains below the time to collision.This platform-level specification must be verified during integration and flight testing.
- Swarm Reallocation: By 500 ms, neighboring coordination modules receive the degraded Health Vector and reallocate tasks around the affected agent.This implements graceful degradation rather than treating the partially failed drone as a complete loss.
- Scope Boundary: The architecture targets payload-capable UAVs above 10 kg MTOW because hardware isolation and redundancy impose a measurable payload penalty.Strict SWaP constraints preclude hardware replication in micro-UAV swarms.
- Validation Boundaries: The reliability result is theoretical: confirming C_monitor > 0.9991 requires fault-injection campaigns, while planner effectiveness depends on convergence speed.Hardware-in-the-loop verification of the FMU and Safety Monitor Interface is future work.