Paper deep dive
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
Intelligence
Status: succeeded | Model: Gemma-4-26B-A4B | Prompt: intel-v1 | Confidence: 92%
Last extracted: 8/24/2026, 4:05:40 AM
Summary
This paper proposes a safety-driven architectural framework for fail-operational UAV swarms in critical missions, addressing the certification gap between deterministic airworthiness standards and non-deterministic swarm coordination. The framework utilizes a hardware-isolated Safety Monitor (Run-Time Assurance) to enforce formal safety contracts based on Health Vectors derived from Functional Hazard Assessment (FHA). This decouples the flight-critical core from the swarm manager, enabling fail-operational task reallocation while maintaining SAIL IV compliance. Markov reliability modeling demonstrates that a hazardous failure rate of 10^-7 per flight hour is achievable if the Safety Monitor coverage exceeds 0.9991.
Entities (10)
Relation Signals (7)
Framework → applies → SAE ARP4754B
confidence 95% · This paper proposes a mixed-criticality architectural framework that applies SAE ARP4754B methods to swarm reconfiguration.
Safety Monitor → implements → Run-Time Assurance
confidence 95% · First, a hardware-isolated Safety Monitor functions as a Run-Time Assurance (RTA) gateway
Framework → targetscompliancewith → JARUS SORA
confidence 94% · As the primary regulatory framework for civil UAVs, the JARUS Specific Operations Risk Assessment (SORA) imposes quantitative reliability targets.
Safety Monitor → enforces → Safety Contracts
confidence 93% · Second, the monitor enforces formal safety contracts based on agent Health Vectors
Health Vector → derivedfrom → Functional Hazard Assessment
confidence 92% · agent Health Vectors derived systematically from a Functional Hazard Assessment (FHA)
Framework → enables → Fail-Operational Task Reallocation
confidence 91% · enabling intelligent swarm behaviors without compromising flight-critical isolation... trigger fail-operational task reallocation
Safety Monitor → hasrequiredcoverage → 0.9991
confidence 90% · provided the Safety Monitor meets C_monitor > 0.9991
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
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^{-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.
Tags
Links
- Source: https://arxiv.org/abs/2608.20906v1
- Canonical: https://arxiv.org/abs/2608.20906v1
Trouble viewing inline? Open PDF directly →
Full Text
59,428 characters extracted from source content.
Expand or collapse full text
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ü, and Håkan Forsberg Affiliation: Mälardalen University Västerås, Sweden Email: luiz.giacomossi@mdu.se 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−710^-7 failures per flight hour Hazardous target is theoretically achievable for our SAIL IV scenario, provided the Safety Monitor meets Cmonitor>0.9991C_monitor>0.9991, consistent with DAL B CMD/MON implementations. Index Terms: Fail-Operational Systems, UAV Swarms, Safety-Driven Architecture, Swarm Resilience, Safety-Critical Systems I Introduction Unmanned Aerial Vehicle (UAV) swarms in safety-critical missions, such as Search and Rescue (SAR), require operational authorization based on formal design assurance [6, 12, 11]. While coordinated multi-agent systems offer increased area coverage over single agents, their non-deterministic emergent behaviors pose a certification challenge. As the primary regulatory framework for civil UAVs, the JARUS Specific Operations Risk Assessment (SORA) imposes quantitative reliability targets. Our reference scenario, a Beyond Visual Line of Sight (BVLOS) search over a sparsely populated area, corresponds to medium-risk SAIL IV. At this level, SORA mandates compliance with recognized airworthiness standards; we therefore adopt civil aviation severity targets, where a Hazardous condition (e.g., an uncontrolled crash) must remain below 10−710^-7 per flight hour [14]. Achieving this target requires a verifiable link between system architecture and operational safety [13]. An architectural gap exists between single-agent avionics and multi-agent robotics. The fault-tolerant systems community prioritizes deterministic, fail-safe designs using redundant hardware and time-triggered buses to mitigate failures [24]. Conversely, swarm robotics research focuses on collective resilience. Recent works have proposed ”health-aware” coordination strategies [25, 1]. However, these approaches typically optimize for mission performance (e.g., energy efficiency) rather than design assurance. They lack the formal isolation required to prevent a non-deterministic replanning algorithm from violating safety constraints. This creates a mixed-criticality integration problem: safety-critical flight control laws must coexist with complex, unverified swarm logic, requiring a high-integrity mediator to guarantee isolation [2]. This paper proposes a safety-driven architectural framework toward fail-operational drone swarms. We apply the SAE ARP4754B systems engineering methodology, the civil aviation guideline for aircraft and systems development assurance, to derive a Run-Time Assurance (RTA) mechanism aligned with ASTM F3269-17, a standard practice for safely bounding the behavior of UAV with complex functions [2], that bounds swarm behavior. The contributions of this work are: 1. A verifiable health-aware architecture that bridges ad-hoc swarm resilience and formal safety standards. Unlike traditional approaches using software self-reporting, we introduce a hardware-isolated Safety Monitor to enforce the accuracy of the health state, guaranteeing the swarm’s reconfiguration is based on trusted data. 2. A systematic derivation of agent health states from Functional Hazard Assessment (FHA), with traceability from component faults to swarm reconfiguration behaviors. 3. A quantitative reliability analysis using Markov modeling to identify the Safety Monitor coverage requirements necessary to satisfy the 10−710^-7 probability of failure target for hazardous operations. While the framework is illustrated via a SAR mission under SORA SAIL IV, the architectural principles for isolating monitoring from planning apply to any safety-critical multi-agent system with mixed-criticality partitioning. This paper presents a conceptual framework and a theoretical safety argument. The evaluation relies on systems engineering methods appropriate for this design phase: architectural traceability, Markov reliability modeling, and a ConOps scenario walkthrough. Hardware implementation, formal software verification, and flight-test validation are future work and remain outside this contribution’s scope. I Related Work The design of dependable systems for regulated airspace relies on established principles of fault tolerance through redundancy [13]. Our work connects fault-tolerant avionics, resilient swarm coordination, and RTA for complex systems. Architectures for fault-tolerant UAVs traditionally focus on fault containment within a single platform. These designs employ hardware replication, such as Triple-Modular Redundancy (TMR) [23], or analytical redundancy through robust control. Approaches range from controllers that maintain stability after actuator failures [16, 15] to energy management systems optimizing component longevity [9]. While these methods provide a rigorous foundation for fail-safe agents, they inherently treat the individual UAV as the system boundary. In these architectures, if a fault exceeds the local recovery capability, the agent typically executes a solitary emergency landing. In a SAR context, this creates an unmitigated coverage gap, as the remaining agents are unaware of the safety-critical state change. Multi-agent systems research focuses on collective resilience, ensuring mission completion despite agent loss. Strategies include centralized replanning to restore connectivity [5, 10] or distributed self-healing for communication repair [22]. Recently, ”health-aware” strategies have emerged, where swarm behavior adapts to specific health metrics. For instance, Zhao et al. [25] present a path planner that recalculates flight parameters after actuator faults, while Alamdar and Petrović [1] propose connectivity maintenance based on battery depletion. However, these approaches are primarily performance-driven. Crucially, they introduce a dependency on the very software layer that may be compromised. They operate under the assumption that the degraded agent can still reliably execute complex negotiation algorithms. If a physical fault is accompanied by a software anomaly (e.g., thread deadlock), the health propagation fails. They lack a formal safety assessment to guarantee that the reconfigured behavior does not violate airspace safety constraints, rendering them difficult to certify under deterministic standards like ARP4754B. To certify non-deterministic algorithms on UAVs (or other systems not typically certified under traditional aircraft guidance regulations), the avionics community has adopted Run-Time Assurance (RTA) architectures [21, 2]. This concept is grounded in the logical Simplex Architecture [17], which wraps complex, untrusted functions (e.g., AI planners) with a verifiable safety monitor. Bak et al. extended this to the System-Level Simplex [3], moving the safety monitor to isolated hardware (e.g., FPGA) to protect against Operating System (OS) failures. While these architectures successfully protect single UAVs from software faults, their application to multi-agent systems remains unexplored. Existing RTA frameworks enforce local “fail-safe” maneuvers (e.g., hover or terminate) but lack the mechanisms to propagate hardware-verified safety states to the collective for “fail-operational” reconfiguration. A gap exists between these domains. System-Level Simplex [3] provides rigorous hardware isolation but lacks swarm awareness. Health-aware swarm strategies [25] provide flexibility but lack determinism. Our work addresses this by proposing a hardware-enforced, compliance-driven architectural framework. We extend the System-Level Simplex concept by treating the Swarm Coordination Module as an ”Untrusted Complex Function.” We use the SAE ARP4754B safety process to derive a formal interface between the agent’s isolated safety monitor and the collective logic, establishing a traceable chain of resilience from component-level faults to mission-level reconfiguration. I Safety-Driven Design Methodology The proposed architecture is derived from a systematic safety assessment to support certification. Our methodology adapts SAE ARP4761A [19], the civil aviation guideline for safety assessment of airborne systems, and ARP4754B [18] to the constraints of mixed-criticality swarms. Unlike traditional single-aircraft processes, we explicitly analyze the propagation of faults originating in the physical agent and impacting the collective behavior, as seen in Fig. 1. Fig. 1: Data flow of the Verifiable Health-Aware Framework. The architecture acts as a Hardware Isolation Boundary between physical and logical domains. (1) Physical Layer: Component faults (e.g., a propulsion degraded motor failure) are detected by the Safety Monitor. (2) Safety Monitor: The FMU uses a “Lock and Filter” mechanism to constrain control and filter fault data. (3) Swarm Logic: The resulting “Health Vector” (e.g., ⟨NOMINAL,DEGRADED,NOMINAL⟩ ,DEGRADED,NOMINAL , Eq. 1) is broadcast to the collective, triggering autonomous reallocation of mission tasks to healthy neighbors (icons show logical transfer). To define the architectural components and interfaces shown in Fig. 1, the design process follows a top-down hierarchy: 1) Hazard Identification (HazID) to establish swarm-level safety bounds; 2) Functional Hazard Assessment (FHA) to map functions to Design Assurance Levels (DAL); and 3) Formal Interface Definition, applying Contract-Based Design principles [4] to mathematically derive the health states required to contain the identified hazards. I-A Hazard Analysis and Risk Class A Preliminary Hazard Identification (HazID) established the top-level safety constraints. We align our severity classifications with the JARUS Specific Operations Risk Assessment (SORA) [14]. We assume a Search and Rescue mission in a sparsely populated environment, corresponding to SAIL IV (Specific Assurance and Integrity Level 4). In this context, the uncontrolled crash of a single drone (H-02) is classified as a Hazardous event (Target Prob. <10−7<10^-7/hr). Although the immediate ground risk in sparse areas is low, a Loss of Control event in a Beyond Visual Line of Sight (BVLOS) swarm allows the agent to deviate from its operational geofence, potentially infringing on civil airspace or threatening the remaining fleet (precursor to H-01). Thus, a Hazardous integrity target is required for containment. Table I summarizes critical hazards and probability targets. TABLE I: System-Level Hazards (Aligned with JARUS SORA SAIL IV) ID Hazard Description Severity Target Prob. H-01 Mid-air or terrain collision of multiple drones. Catastrophic <10−9<10^-9/hr H-02 Uncontrolled crash of a single drone. Hazardous <10−7<10^-7/hr H-03 Failure to detect the search target (Mission Failure). Minor <10−3<10^-3/hr H-06 Loss of Command and Control (C2) link. Major <10−5<10^-5/hr H-07 Unauthorized control of the swarm. Catastrophic <10−9<10^-9/hr I-B Functional Hazard Assessment (FHA) The FHA maps top-level hazards to specific functional failures and assigns a Design Assurance Level (DAL) to each (Table I). This partitions the mixed-criticality system: while top-level flight hazards require DAL B integrity, the use of dual-channel redundancy allows the flight control modules to be developed at DAL C (see Tab. I-footnote a). The Safety Monitor (FMU) is assigned to DAL B consistent with its Hazardous failure classification, and non-deterministic swarm functions are assigned to DAL D. The FHA includes the failure modes of the Fault Management Unit (FMU) to evaluate the integrity requirements of the Run-Time Assurance (RTA) gateway against Hazardous safety targets. TABLE I: Functional Hazard Assessment (FHA) with Calibrated Design Assurance Levels (DAL) Function Failure Condition Effect on System/Mission Severity Target FDAL F1: Safety Monitoring (FMU) Loss of isolation, missed fault detection, or spurious contract enforcement Uncontained swarm faults propagate to flight core; risk of uncontrolled crash (H-02). Hazardous DAL B F2: Flight & Navigationa Loss of ability to determine state (position/attitude) Uncontrolled descent; potential crash (H-02). Hazardous DAL B F3: Target Detection Failure to detect valid target (False Negative) Reduced search effectiveness (H-03). Minor DAL D F4: Swarm Coord. Broadcastb Transmission of corrupted trajectory data Risk of inter-agent collision (H-01) if not validated. Hazardous DAL D (B with monitor) F5: Power Management Incorrect State of Charge (SoC) reporting Unexpected depletion and crash (H-02). Major DAL C a Although total navigation loss constitutes Hazardous condition, it requires the simultaneous failure of two independent channels. With each channel developed to λch≈10−4 _ch≈ 10^-4/hr, the probability of simultaneous dual-channel failure is λch2≈10−8 _ch^2≈ 10^-8/hr, one order of magnitude below Hazardous (10−710^-7/hr), satisfying the requirement at the system level. Partial navigation degradation (single-channel loss) is handled by the navC_nav contract (Section I-C), which forces a controlled landing before total state loss can occur, preventing the fault from progressing to the Hazardous condition in practice. b F4 is DAL D because the DAL B Safety Monitor validates all trajectory commands via the Safety Contract (Section I-C), containing the effect of corrupted swarm data. The residual probability of F4 causing H-01 is P(H-01∣F4)≤λF4⋅(1−Cmonitor)P(H-01 4)≤ _F4·(1-C_monitor). With Cmonitor>0.9991C_monitor>0.9991, this is below the 10−710^-7/hr Hazardous threshold, supporting DAL D per ASTM F3269 [2]. While ASTM F3269 supports monitoring of unassured functions (DAL E), ARP 4754B [18] specifies that DAL E functions do not require a structured development process; therefore, we do not consider this level for any subsystem. General Note: The FHA covers functions directly relevant to the proposed mixed-criticality architecture. DAL A (Catastrophic single-point failure) is absent because Catastrophic hazards (e.g., H-01) are mitigated via architectural redundancy, reducing subsystem requirements to DAL B/C. I-C Formal Derivation of Safety Contracts To decouple the DAL B Safety Monitor and the deterministic Flight Core (DAL C) from the non-deterministic Swarm Coordinator (DAL D), the architecture employs Contract-Based Design (CBD) [4]. This formalism establishes a set of Safety Contracts =nav,prop,commC=\C_nav,C_prop,C_comm\ that bound the permissible behavior of the swarm. A contract C for a component M is defined as a pair (A,G)(A,G), where A represents the Assumptions regarding the environment and inputs, and G denotes the Guarantees provided by the component. Component M satisfies C if it behaves according to G whenever the environment satisfies A. Hierarchical Fault Abstraction and Health Vector To prevent the swarm algorithms processing hardware-specific fault data, the architecture implements a three-tier hierarchical abstraction: 1. Atomic Level: Physical sensors detect localized hardware errors (e.g., motor RPM deviation, battery voltage VbattV_batt drop, GNSS dilution, packet loss). 2. Functional Level: The FMU evaluates atomic errors against predefined safety thresholds, mapping them to a discrete functional state σ∈NOMINAL,DEGRADED,FAILEDσ∈\NOMINAL, , \. 3. Aggregated Level: The functional states of subsystem categories are aggregated into the Health Vector HiH_i for agent i: Hi(t)=⟨σnav,σprop,σcomm⟩H_i(t)= _nav, _prop, _comm (1) TABLE I: Hierarchical Mapping of Atomic Faults to Health Vector States Atomic Signal Threshold Condition Functional State (σ) Health Vector Component RPM mismatch |RPMcmd−RPMmeas|>ϵRPM|RPM_cmd-RPM_meas|> _RPM DEGRADED σprop _prop Battery voltage Vbatt≤VcritV_batt≤ V_crit DEGRADED σprop _prop GNSS HDOP HDOP>HDOPmaxHDOP>HDOP_max FAILED σnav _nav Heartbeat timeout t−tlast_hb>τtimeout-t_last\_hb> _timeout FAILED σcomm _comm SNR SNR<SNRminSNR<SNR_min FAILED σcomm _comm For the ConOps analysis (Section V-D), HiH_i is instantiated for specific agents by substituting the agent identifier, e.g., HD(t)H_D(t) for the faulted agent D. Timing and Latency Bounds To guarantee temporal determinism for the RTA gateway, the Health Vector update is bounded by strict timing constraints. The FMU evaluates Hi(t)H_i(t) at a fixed update frequency fupdatef_update. Upon the occurrence of an atomic fault at t=0t=0, the total latency for fault detection (τdetect _detect) and subsequent contract enforcement (τenforce _enforce) must satisfy the maximum latency bound τmax _max: τdetect+τenforce≤τmax _detect+ _enforce≤ _max (2) The bound τmax _max is derived from the vehicle’s time-to-divergence under a worst-case fault. For a hexacopter with a single-motor winding fault producing a thrust asymmetry ΔF F, the resulting uncompensated angular acceleration is ϕ¨fault=ΔF⋅larm/Ixx φ_fault= F· l_arm/I_x, where larml_arm is the motor arm length and IxxI_x is the roll-axis moment of inertia. The time to reach the maximum recoverable attitude deviation Δϕmax _max (nominally 30∘30 for a hexacopter before loss of controllability [15]) is: τmax=2⋅Δϕmaxϕ¨fault _max= 2· _max φ_fault (3) For representative platform parameters (e.g., 1010 kg mass, larm=0.5l_arm=0.5 m, maximum thrust asymmetry ΔF=60 F=60 N, and Ixx≈0.25I_x≈ 0.25 kg⋅·m2), this yields τmax _max in the range of 80–150 ms, supporting the 100 ms design target used throughout this work. The specific value is a conservative platform-level requirement to be verified during hardware integration. Contract Instantiation The contracts mathematically formalize the mapping of atomic faults into functional degradation. The Propulsion Contract (propC_prop) restricts actuation authority when an actuator fault or a critical power degradation is detected: prop:A:FMU Powered∧Sensors ActiveG:((|RPMcmd−RPMmeas|>ϵRPM)∨(Vbatt≤Vcrit))⟹…(σprop←DEGRADED)∧(‖cmd‖≤vsafe)C_prop: casesA:FMU Powered Active\\ G:((|RPM_cmd-RPM_meas|> _RPM) (V_batt≤ V_crit)) …\\ ( _prop ) (\|v_cmd\|≤ v_safe) cases (4) where ϵRPM _RPM is the kinematic error threshold, VbattV_batt is the telemetry provided by the Battery Management System (BMS), VcritV_crit is the minimum voltage threshold to prevent brownout during high-thrust transients, and vsafev_safe is the resulting velocity limit imposed. The Navigation Contract (navC_nav) mandates a fail-safe transition upon sensor uncertainty: nav:A:FMU Powered∧Sensors ActiveG:(GNSSHDOP>HDOPmax)⟹…(σnav←FAILED)∧(Mode←LAND)C_nav: casesA:FMU Powered Active\\ G:(GNSS_HDOP>HDOP_max) …\\ ( _nav ) (Mode ) cases (5) where HDOP is the Horizontal Dilution of Precision (a standard metric for GNSS positioning quality), and HDOPmaxHDOP_max is the threshold for safe navigation. Finally, the Communication Contract (commC_comm) addresses Link Loss (H-06) by monitoring the telemetry heartbeat and Signal-to-Noise Ratio (SNR): comm:A:FMU Powered∧COM Hardware ActiveG:((t−tlast_hb>τtimeout)∨(SNR<SNRmin))⟹…(σcomm←FAILED)∧(Mode←RTB)C_comm: casesA:FMU Powered Hardware Active\\ G:((t-t_last\_hb> _timeout) (SNR<SNR_min)) …\\ ( _comm ) (Mode ) cases (6) where tlast_hbt_last\_hb is the timestamp of the last valid heartbeat from the swarm mesh, τtimeout _timeout is the maximum allowable communication delay, and SNRminSNR_min is the threshold for link integrity. If the condition is met, the FMU enforces a Return-To-Base (RTB) maneuver. Contract Coverage: The three contracts jointly provide necessary coverage of the failure paths leading to H-02 at the component fault level. propC_prop addresses propulsion-related faults (actuator anomalies) and power anomalies (F5) through combined RPM mismatch and VbattV_batt monitoring, the latter fed directly from the BMS to the FMU, as defined in Section IV. navC_nav addresses navigation state degradation (F2) by gating on GNSS quality and transitioning to a controlled landing before total state loss. commC_comm addresses link loss (H-06) by enforcing RTB before communication failure can lead to uncontrolled flight. Coverage of compound failures—simultaneous multi-subsystem faults—is addressed at the architectural level through hardware redundancy in the Flight-Critical Core and is analyzed in the FTA (Section V-A). The contracts represent necessary but not sufficient conditions for system safety; sufficiency at the implementation level requires formal verification of the FMU logic, identified as future work. This formulation defines the Guarantee (G) of each contract as a direct algebraic link between physical anomalies and the resulting discrete state σ, satisfying the hierarchical abstraction requirement while preserving traceability to the DAL B hardware monitors. I-D System Safety Requirements (SSRs) Based on the FHA and Safety Contracts, we derive the following SSRs that drive the architectural design: • [SSR-FLT-01] The Flight Critical Core shall maintain DAL C integrity for attitude estimation and control. • [SSR-FTR-01] The system shall implement a hardware-isolated Safety Monitor of DAL B integrity to enforce the Safety Contract defined in Sec. I-C. The monitor shall achieve a diagnostic coverage Cmonitor>0.9991C_monitor>0.9991 for flight-critical faults, as derived in Section V-B. • [SSR-FTR-02] No single point of failure in the DAL D Swarm Coordination Module (after validation by the Safety Monitor) shall cause a hazardous or catastrophic event. • [SSR-MSN-02] The swarm logic shall autonomously re-allocate tasks when an agent reports a σ≠NOMINALσ state. • [SSR-SEC-01] All health vector transmissions shall be authenticated to prevent unauthorized access (H-07). IV Fail-Operational Architecture To satisfy the SSRs, we propose a multi-level fail-operational architecture that addresses fault tolerance at two layers: the individual agent and the collective swarm. This hierarchy provides local fault containment while the swarm maintains mission continuity. IV-A Individual Agent Architecture The foundation of the swarm relies on the integrity of each agent. Assuming a physical platform with actuator redundancy (e.g., a hexacopter), the logical architecture partitions into two subsystems with distinct DALs to maintain fault containment. Two complementary architectural views illustrate this split in Fig. 2 and Fig. 3. Fig. 2: Functional Control Architecture. Logical view of safety hierarchy and DAL boundaries. The FMU is a high-integrity Run-Time Assurance (RTA) gateway (DAL B). To prevent untrusted DAL D Mission Tasks from violating constraints, the FMU applies a “Lock and Filter” mechanism (denoted by the padlock symbol): Supervisory Commands override mission inputs in the FCS if a safety contract breaches. Bidirectional links enable FMU subsystem monitoring and broadcast the aggregated Health Vector to the swarm. As shown in Fig. 2, the functional architecture enforces a Command/Monitor relationship. This logic is physically mapped in the conceptual architecture shown in Fig. 3. The first subsystem is the Flight-Critical Core (DAL C), which contains all modules essential for safe flight. To achieve fault tolerance, these functions execute on a dual-channel redundant flight computer. The second subsystem is the Mission and Perception System, which handles non-deterministic swarm coordination. A single-channel mission computer hosts this system and is treated as a fail-silent component. This hierarchical partitioning prevents propagation of software faults in the mission system to the flight core. Fig. 3: Conceptual block diagram of the proposed fault-tolerant architecture. The system partitions into a Flight-Critical Core (DAL C) and a Mission and Perception System (DAL D , fail-silent). Redundancy includes dual-channel power and flight computers. The supervisory Safety Monitor (FMU) (DAL B) uses a Command/Monitor (CMD/MON) architecture to enforce safety contracts via the Safety Monitor Interface (SMI). The SMI is shown at top and bottom for layout clarity; both represent the same logical hardware channel isolating safety traffic from redundant CAN buses. The logic modules within these subsystems are: • Fault Management Unit (FMU): The hardware implementation of the RTA Safety Monitor. It receives health vectors from all modules and enforces Safety Contracts (Sec. I-C). To protect against OS or middleware failures, the FMU is an independent hardware-isolated unit, extending the System-Level Simplex concept [3]. Its logic is verifiable and deterministic. The FMU is assigned DAL B, consistent with the Hazardous classification of F1 in the FHA. The required hardware integrity (λmonitor_hw≈10−8 _monitor\_hw≈ 10^-8/hr) is achieved using a CMD/MON architecture, reducing common-mode software faults and improving reliability beyond DAL C. • Navigation System (NAV): Is a DAL C software module executed on the dual-channel flight computers. To satisfy [SSR-FLT-01], it fuses data from redundant IMUs and GNSS receivers to produce a high-integrity state estimate. Its internal Kalman filter provides a final layer of fault detection and exclusion to prevent H-02. • Flight Control System (FCS): The core DAL C software module that computes actuator commands. It runs on the flight computer within a partitioned RTOS (implementing ARINC 653 concepts for temporal and spatial isolation). Accepts supervisory commands from the FMU, such as switching to a degraded control allocation matrix. • Motor Control (MC): The interface between abstract FCS commands and physical actuators. It translates thrust commands into PWM signals and handles switching to degraded control maps under FCS direction. • Power Management (PM): A DAL C component providing power through a dual-redundant architecture. It includes the Battery Management System (BMS) that feeds telemetry (VbattV_batt) directly to the FMU for contract evaluation. • Swarm Coordination Module (SCM): The primary DAL D component for mission-level tasks. It executes non-deterministic swarm algorithms. The FMU monitors the SCM via a heartbeat mechanism. A fault in the SCM (e.g., software crash, missed heartbeat) causes the FMU to declare it failed and command the flight-critical core to a safe contingency state, satisfying [SSR-FTR-02]. The SCM receives the aggregated Health Vector from the FMU to broadcast to the swarm mesh. • Object Detection & Collision Avoidance (OD-&CAS): This DAL D module runs on the mission computer. Outputs are untrusted and bounded by the FMU. • Communications (COM): Redundant D2D/D2GCS radios. Powered by PM for availability, logically interfaced with the Mission System. All channels use authenticated encryption to mitigate H-07. The Swarm Mesh Hub is an optional ground relay extending D2D mesh coverage for large-area SAR. It is treated as an untrusted infrastructure component; failures are handled by commC_comm, which enforces RTB on mesh loss, whether due to radio faults or hub unavailability. IV-A1 Safety Monitor Communication The system safety relies on the isolation of the FMU achieved via the Safety Monitor Interface (SMI), a dedicated physical channel. This prevents failures on the primary DUAL CAN BUS—such as a message flood—from blocking safety commands. Communication on the SMI is bidirectional: • From Modules to FMU: Critical modules report their health vector (HiH_i), based on internal monitoring (e.g., voltage levels, RPM mismatch, watchdog timeouts, error counters). • From FMU to Modules: The FMU issues high-priority, overriding commands to enforce the Safety Contract. For example, consider a healthy FCS with an actuator fault: 1. The FCS detects a persistent kinematic error and reports this raw atomic data to the FMU via the SMI. 2. The FMU evaluates this data against the Propulsion Contract (propC_prop), identifies the breach, and transitions the internal state to σprop←DEGRADED _prop . 3. The FMU simultaneously sends an override command (e.g., ENFORCE_SAFE_ENVELOPE) back to the FCS and propagates the updated HiH_i to the SCM. This creates a fault management loop that remains operational even if the primary data network fails. IV-B Swarm-Level Coordination and Resilience While the individual agent architecture handles internal faults, swarm-level resilience manages the failure or loss of entire agents. The swarm coordination logic is directly responsive to the health status provided by each drone’s FMU. The behavior of each agent is governed by the Finite State Machine (FSM) shown in Fig. 4. The FSM design separates the Nominal Mission Flow and the Fault Handling Logic. Upon a “Critical Fault” event triggered by its internal FMU, an agent transitions from any nominal state to the Execute Contingency Plan state. Based on the severity of the fault reported by the FMU, one of two paths is chosen: • Return to Base (RTB) Possible: If the FMU indicates the agent retains sufficient navigation and control capability, the FSM transitions to the Return Base state for a controlled recovery. • RTB Impossible: If the fault is too severe for a controlled return (e.g., loss of navigation), the FSM transitions to an Emergency Land state to minimize risk. The agent broadcasts its degraded status to the swarm to enable a coordinated collective response. Fig. 4: Finite State Machine (FSM) for an individual agent. Any fault in a nominal state triggers transition to Fault Handling Logic. This FSM-driven fault handling enables a two-tiered swarm response that satisfies the SSRs: 1. Graceful Degradation: If a drone enters a contingency state but is capable of controlled flight (e.g., the “RTB Possible” path), it remains a usable asset. The swarm coordination module re-tasks it to a less critical role, such as a high-altitude communication relay. 2. Agent Loss Response: If a drone executes an emergency landing or ceases communication entirely (detected via heartbeat timeout), the swarm coordination module removes it from the active roster. To satisfy [SSR-MSN-02], the module initiates a task re-allocation protocol, redistributing the lost agent’s search area among the remaining healthy agents. A low-battery condition detected during RTB triggers a controlled transition to mission termination. This transition is managed by the propC_prop contract via VbattV_batt monitoring and does not constitute a hazardous event, provided the agent maintains controlled flight to landing. To mitigate collision risks during a simultaneous swarm-wide return, the Return Base state executes a static deconfliction strategy, assigning pre-allocated altitude corridors to each agent based on their ID. IV-C Swarm-Level Interface: The Cost Function To demonstrate that the architecture is agnostic to specific planning algorithms, we define a standard interface for task allocation based on a cost minimization function. We assume a generic planner (e.g., Market-Based) where agent i bids a cost JijJ_ij to perform task j. The Swarm Manager (DAL D) receives the Health Vector HiH_i from the Safety Monitor and incorporates it into the cost function to satisfy [SSR-MSN-02]. We formulate the cost JijJ_ij as: Jij=wd‖pi−ptaskj‖+(Hi,TaskTypej)J_ij=w_d||p_i-p_task_j||+P(H_i,TaskType_j) (7) where p denotes position vectors, wdw_d is a distance weight, and P is the architectural penalty function enforced by the interface. The penalty function translates the discrete states of the Health Vector into the continuous planning domain: =0if Hi=NOMINAL∞if Hi=DEGRADED∧Taskj∈Agilityλdegif Hi=DEGRADED∧Taskj∈RelayP= cases0&if H_i=NOMINAL\\ ∞&if H_i=DEGRADED _j \\ _deg&if H_i=DEGRADED _j cases (8) where λdeg>0 _deg>0 is a finite mission penalty assigned to degraded agents performing relay tasks, reflecting their reduced operational capability. The specific value of λdeg _deg is a tuning parameter of the swarm planner. It is set such that a degraded agent remains competitive for relay tasks but is systematically deprioritized relative to healthy agents (λdeg≪∞ _deg ∞). Its calibration is a planner-level design decision outside the scope of this architectural framework. This mathematical interface results in a “Degraded” agent being priced out of high-agility tasks (infinite cost) while remaining competitive for static relay tasks (finite penalty λdeg _deg). This realizes fail-operational behavior without complex rule-based logic. The cost function operates within the DAL D Swarm Coordination Module and is therefore bounded by the DAL B Safety Monitor. A failure of the cost function to correctly penalize degraded agents is treated as an F4-class failure (Table I) and is contained by the FMU’s trajectory validation prior to execution. V Architectural Analysis Given the conceptual design phase of this work, the framework is assessed through three complementary systems engineering methods: (1) Architectural Traceability Analysis, to verify that each identified hazard is mitigated by a specific architectural control; (2) Markov Reliability Modeling, to establish the theoretical compliance boundary and derive the Safety Monitor coverage requirement; and (3) a ConOps Scenario Walkthrough, to verify the logical consistency and timing of the fault response chain. V-A Traceability and Qualitative Analysis A primary requirement of ARP4754B is the traceability of hazards to architectural mitigations. Table IV demonstrates this link. Every hazard identified in the FHA (Section I) is mapped to a specific hardware or software control. TABLE IV: Traceability of Hazards to Architectural Mitigations Hazard ID Mitigating Architectural Features (from Section IV) H-01 Collision Layered Defense: Swarm planner (DAL D) provides strategic deconfliction; Reactive OD&CAS (DAL D) provides tactical avoidance; Flight Core (DAL C) enforces geofencing limits. H-02 Crash Hardware Isolation: Dual-redundant Flight Core (DAL C); Independent Safety Monitor (FMU, DAL B) prevents SCM from commanding unsafe states via the Safety Contract. H-03 Mission Fail Swarm Reconfiguration: Task re-allocation logic (SSR-MSN-02) triggered by Health Vector Hi(t)H_i(t) updates via SMI. H-06 Link Loss Diversity: Redundant D2D/D2GCS radios. Loss of GCS triggers mesh-based autonomous replanning; Loss of Mesh (D2D) triggers independent ’Return-to-Base’. H-07 Unauth. Access Encryption: Authenticated encryption on all SMI and COM links (SSR-SEC-01). To verify defenses against swarm-emergent hazards, Fig. 5 shows the Qualitative Fault Tree Analysis (FTA) for a mid-air collision (H-01). The logic demonstrates the architecture’s functional redundancy. The top-level OR gate partitions the hazard into ’Intra-Swarm Collision’ and ’External Collision’. For an intra-swarm collision to occur, an AND gate dictates that drones must be on a collision course concurrently with a ’Collision Avoidance Fails’ event. Furthermore, an AND gate confirms that both the High-Level Avoidance (Cooperative Swarm Planning) and Low-Level Avoidance (Reactive Sensors/FCS) must fail simultaneously. Fig. 5: Qualitative Fault Tree Analysis (FTA) for the ’Mid-Air Collision’ (H-01) swarm-emergent hazard. The tree demonstrates the system’s multi-layered safety architecture for intra-swarm collision, requiring failures in both high-level (cooperative) and low-level (reactive) avoidance layers. V-B Quantitative Reliability Analysis To demonstrate compliance with the Hazardous safety target (<10−7<10^-7 per flight hour for H-02), we model the system dynamics using a Continuous Time Markov Chain (CTMC). Unlike static Fault Trees, this model explicitly captures the architecture’s dependence on the Safety Monitor’s diagnostic coverage (CmonitorC_monitor). The state space, in Fig. 6, consists of: • State 0 (Nominal): All systems functional. The Swarm Coordinator (DAL D) manages the mission. • State 1 (Degraded/Safe): A hardware fault occurred, but the Safety Monitor (FMU) detected it and enforced a contingency (e.g., Hex-to-Quad control allocation or RTB). This represents a fail-operational state, as the system maintains controlled flight and swarm coordination. • State 2 (Hazardous): Uncontrolled crash. This occurs if the Monitor fails to cover the fault (Lack of Coverage) or if the hardware fails without redundancy. S0S_0startS1S_1SHazS_HazλFC⋅Cmonitor _FC· C_monitorλFC(1−Cmonitor) _FC(1-C_monitor)λsafe _safeNominalSafe/DegradedHazardous Fig. 6: Markov Chain model of the architecture. S0S_0: Nominal operation. S1S_1: Successfully contained fault (Fail-Operational). SHazS_Haz: Uncontained failure. System safety depends on Monitor Coverage (CmonitorC_monitor). λsafe _safe is the secondary failure rate from degraded state S1S_1. During short RTB recovery, this transition is dominated by λFC _FC and bounded as described in the text. The probability of a Hazardous state is dominated by the Coverage Factor (CmonitorC_monitor) of the Safety Monitor. The flight computer operates in a Command/Monitor (CMD/MON) configuration, so the CMD channel generates actuator commands while the MON channel verifies their correctness in parallel. An undetected hazardous failure requires the CMD to produce an error that propagates to the actuators, the rate of which is captured by λFC _FC, rather than either channel independently failing. Using a first-order approximation for rare events, the steady-state hazard rate λhaz _haz is formulated as: λhaz≈λFC⋅(1−Cmonitor)+λmonitor_hw _haz≈ _FC·(1-C_monitor)+ _monitor\_hw (9) Where: • λFC≈10−4 _FC≈ 10^-4/hr is adopted as a conservative parametric estimate for a single-channel flight computer. This value is consistent with failure rate ranges for aerospace-grade embedded processors [7] and is used here as a bounding assumption. The sensitivity of the compliance result to this parameter is analyzed in Table V. • λmonitor_hw≈10−8 _monitor\_hw≈ 10^-8/hr represents the undetected hardware failure rate for the FMU under its DAL B assignment. A hazardous FMU failure requires both a hardware fault in the FMU and a failure of the internal CMD/MON monitor to detect it. This value corresponds to the integrity target achievable with a CMD/MON processor architecture [20], and is treated here as a design requirement rather than a measured value. The transition from the degraded state S1S_1 to the hazardous state SHazS_Haz via secondary failure (λsafe _safe) is omitted from the bounding approximation, justified as follows: upon entering S1S_1, the FMU enforces the Safety Contract, restricting the agent to a reduced velocity envelope and initiating a Return-to-Base maneuver. The exposure time in S1S_1 is bounded by the RTB maneuver duration tRTBt_RTB, which for SAR platforms operating at SAIL IV distances is on the order of minutes. The probability of a secondary hazardous failure during this window is bounded by λFC⋅tRTB _FC· t_RTB. For λFC=10−4 _FC=10^-4/hr and tRTB≤10t_RTB≤ 10 min =1/6=1/6 hr, this yields Psecondary≤1.7×10−5P_secondary≤ 1.7× 10^-5, which is below the Hazardous threshold and confirms the omission does not affect the bounding result. Communication failure is architecturally bounded by the commC_comm contract (Section I-C), which enforces a deterministic Return-to-Base maneuver upon link degradation, preventing communication loss from directly inducing an uncontrolled crash (H-02). For the overall hazard rate to remain dominated by CmonitorC_monitor rather than λcomm _comm, the redundant communication subsystem must satisfy the design requirement λcomm≪λFC=10−4 _comm _FC=10^-4/hr. This is a system-level specification to be verified during hardware selection and is consistent with the reliability targets achievable by redundant mesh radio architectures in the UAV domain. Rather than assuming a coverage value, we solve for the minimum required coverage to satisfy the Hazardous failure-condition target (Pfail<10−7P_fail<10^-7). Solving Eq. 9 for CmonitorC_monitor: 10−4⋅(1−Cmonitor)+10−8<10−7⇒Cmonitor>0.999110^-4·(1-C_monitor)+10^-8<10^-7 C_monitor>0.9991 (10) TABLE V: Sensitivity of Required Safety Monitor Coverage to Flight Computer Failure Rate λFC _FC λFC _FC (per flight hour) Required CmonitorC_monitor Achievable Implementation 10−310^-3 >0.99991>0.99991 DAL A CMD/MON architecture 10−410^-4 >0.9991>0.9991 DAL B CMD/MON architecture 10−510^-5 >0.991>0.991 DAL C architecture (e.g. lockstep strategy for detecting random faults) 10−610^-6 >0.91>0.91 Software monitor sufficient Table V demonstrates that the architecture remains compliant across a range of flight computer reliability assumptions. For the baseline assumption of λFC=10−4 _FC=10^-4/hr, a DAL B CMD/MON implementation of the FMU satisfies the coverage requirement. If higher-integrity flight computers are used (λFC≤10−5 _FC≤ 10^-5/hr), the coverage requirement relaxes, permitting less costly monitoring implementations. By enforcing this requirement through strict hardware isolation, the architecture derives its safety assurance from verifiable physical properties rather than probabilistic software behavior. V-C Comparative Analysis Table VI compares our framework against both traditional fault-tolerant control and modern RTA standards. TABLE VI: Comparative Analysis of Architectures Criterion Single-Agent FTC [16] Std. RTA (ASTM F3269) Proposed Architecture Scope Single Drone Only Single Drone Only Swarm & Agent Safety Mechanism Algorithmic Redundancy (Kalman Filters) Simplex Monitor (Switch to Safe Controller) Hardware Monitor + Swarm Reconfiguration Response to Fault Adjust Control Laws (Local) Terminate / Loiter (Local) Propagate Health Vector Hi(t)→H_i(t)→ Global Replan Mixed-Criticality No (All software is critical) Yes (Monitor vs. Complex) Yes (DAL B Monitor / DAL C Flight Core / DAL D Swarm) SWaP & Scope Low (any platform) Low-Medium (any platform) High - targets >10>10 kg MTOW; excludes micro-UAVs The comparison shows that while ASTM F3269 provides the safety monitor concept, it lacks the mechanism to propagate the cause of the switch to the swarm. Our architecture fills this gap by turning the RTA monitor into a source of health data for the collective. This architectural cost is a design trade-off: the SWaP (Size, Weight, and Power) overhead of hardware isolation and redundancy is the mechanism by which DAL B integrity is achieved without software-only assurance. V-D ConOps Verification: Actuator Degradation Figure 7 illustrates the sequence during a runtime fault. The specific timing and signal propagation of a partial motor failure event are traced to verify compliance with the SSRs. Fig. 7: Operational Sequence of the Verifiable Health-Aware Framework. (t0) Nominal operation: Swarm executes search under AI control. (t1) Fault Detection: Upon hardware fault detection (e.g., motor loss), the Safety Monitor isolates the Agent D into a safety envelope (v≤vsafev≤ v_safe) and broadcasts a degraded Health Vector HD(t)H_D(t). ’Shield’ denotes the enforcement of the Safety Contract by the FMU. (t2) Reconfiguration: The swarm updates the distributed Cost Function (Eq. 7), penalizing Agent D and re-allocating its search sectors to healthy neighbors (e.g., Agents A and C). 1. Fault Onset (t=0t=0): Motor 5 on Agent D suffers a winding short, reducing thrust by 40%. 2. Detection (t≤50t≤ 50 ms): Based on the vehicle’s time-to-divergence (see τmax _max derivation in Section I-C), the FMU correlates the yaw rate divergence (FCS) and current spike (BMS) within 50 ms. 3. Isolation (t≤100t≤ 100 ms): The FMU enforces the Propulsion Contract (propC_prop). It commands the FCS to switch to the ”Hex-to-Quad” degraded control allocation matrix and enforces the velocity restriction (v≤vsafev≤ v_safe). It updates the Agent Health Vector: HD(t)=⟨NOMINAL,DEGRADED,NOMINAL⟩H_D(t)= ,DEGRADED,NOMINAL . This sequence satisfies the timing constraint of Eq. 2: τdetect+τenforce=50+50=100 _detect+ _enforce=50+50=100 ms ≤τmax≤ _max. 4. Propagation (t≤200t≤ 200 ms): The SCM reads the updated Health Vector HD(t)H_D(t) via the Safety Monitor Interface (SMI) and broadcasts it to the swarm mesh network. 5. Transient Kinematic Safety (200≤t<500200≤ t<500 ms): During replanning, inter-UAS spacing is maintained by the Reactive OD&CAS layer of trailing agents, operating independently of the global swarm planner. Satisfies the design requirement: the detection-to-avoidance latency τOD _OD must be less than the time-to-collision tTTCt_TTC at minimum operational separation, i.e., τOD≪dmin/vrel_max _OD d_min/v_rel\_max, where dmind_min is the minimum inter-agent separation distance and vrel_maxv_rel\_max is the maximum relative approach velocity at the onset of fault. This requirement is a platform-level specification that must be verified during integration and flight testing. 6. Decentralized Reallocation (t≤500t≤ 500 ms): The Swarm Coordination Modules on neighbor drones (Agents A,B,CA,B,C) receive the vector HD(t)H_D(t). Executing a decentralized consensus algorithm, they identify that Agent D can no longer hold its precise search trajectory in high wind due to its degraded propulsion state. 7. Mission Adaptation (t>500t>500 ms): Healthy neighbors adjust their flight paths (indicated by blue arrows in Fig. 7) to cover the operational gap. Agent D transitions to a static relay node role. Altitude deconfliction during simultaneous RTB is handled by the pre-allocated corridor strategy described in Section IV-B. This trace illustrates how the Safety Monitor Interface couples hardware faults (millisecond-scale) with mission adaptation (second-scale), supporting SSR-MSN-02 while maintaining DAL C functional isolation. VI Discussion The presented approach maps hazards to architectural mitigations to establish a verifiable basis for design assurance. The hierarchical fault management framework enables the swarm to reallocate tasks to degraded resources rather than treating a partially failed drone as a complete loss. This reallocation executes graceful degradation during autonomous operations. The architecture partitions subsystems by criticality. The DAL B Safety Monitor provides the highest integrity layer to enforce hardware-isolated containment of DAL D failures. Flight-critical modules (PM, NAV, FCS) at DAL C utilize hardware redundancy, whereas the mission-critical SCM operates within a monitored-simplex design at DAL D. The integration of a physically isolated FMU, dual-redundant flight computers, and redundant data buses introduces a measurable payload penalty. Consequently, this architecture targets payload-capable UAVs (e.g., platforms >10>10 kg MTOW) operating in SAIL IV environments. Strict SWaP constraints preclude hardware replication in micro-UAV swarms. In the event of an SCM failure, the FMU enforces safe state transitions independent of mission objectives. VI-A Design Assumptions and Limitations This work acknowledges limitations based on its current Technology Readiness Level (TRL). First, the quantitative reliability results (Section V-B) are model-based. The evaluation that the Hazardous failure-condition target is theoretically achievable for our SAIL IV scenario relies on the assumption that the Safety Monitor achieves a diagnostic coverage of Cmonitor>0.9991C_monitor>0.9991. While this metric aligns with DAL A/B CMD/MON hardware implementations, verifying this coverage in practice requires targeted fault injection campaigns outside the scope of this architectural proposal. Second, the model assumes independence between the Safety Monitor and the Mission Computer. In a physical implementation, shared resources (such as power buses or clock lines) introduce the potential for Common Cause Failures (CCF). To transition this theoretical framework into a practical Proof-of-Concept (PoC), future work targets the Hardware-in-the-Loop (HIL) verification of the FMU using representative FPGA hardware to verify the timing guarantees of the Safety Monitor Interface (SMI) under saturation conditions. Finally, while this framework defines the formal interface (the Cost Function) between agent health and swarm logic, the effectiveness of the reconfiguration depends on the convergence speed of the distributed planner. The verification and validation (V&V) of non-deterministic replanning algorithms remains an open research challenge [8]. VII Conclusion This paper introduced a verifiable health-aware architectural framework for autonomous swarms. Applying the ARP4754/ARP4761 framework derived a mixed-criticality architecture where a hardware-isolated Safety Monitor (DAL B) enforces formal safety contracts on non-deterministic swarm logic (DAL D). Integrating Run-Time Assurance (RTA) with swarm reconfiguration links flight-critical component reliability (DAL C) to multi-agent resilience. Markov analysis establishes that the Hazardous failure-condition target (Pfail<10−7P_fail<10^-7/hr) is theoretically achievable for our SAIL IV scenario if the Safety Monitor achieves Cmonitor>0.9991C_monitor>0.9991. This requirement is consistent with DAL B hardware architectures, such as CMD/MON architectures (∼10−7 10^-7/hr). By defining boundaries between flight-critical systems and complex swarm algorithms, the framework supports the certification of autonomous operations. Future work targets Hardware-in-the-Loop verification of the Safety Monitor using representative FPGA hardware. This verification focuses on the timing guarantees of the Safety Monitor Interface (SMI) and the fault injection response relative to Safety Contract bounds. acknowledgment This research was funded by the Horizon Europe research and innovation program of the European Union and the Chips Joint Venture under GA No. 101194287, NexTArc (Next Generation Open Innovations in Trustworthy Embedded AI Architectures for Smart Cities, Mobility, and Logistics). References [1] K. G. Alamdar and T. Petrovic (2025) Decentralized battery-aware connectivity maintenance for multi-uav missions. IEEE Access. Cited by: §I, §I. [2] ASTM International (2017) ASTM F3269-17: Standard Practice for Methods to Safely Bound Flight Behavior of Unmanned Aircraft Systems containing Complex Functions. ASTM International, West Conshohocken, PA. External Links: Document Cited by: §I, §I, §I, TABLE I. [3] S. Bak, D. Chivukula, O. Adekunle, M. Sun, M. Caccamo, and L. Sha (2009) The system-level simplex architecture for improved real-time embedded system safety. p. 99–107. External Links: Document Cited by: §I, §I, 1st item. [4] A. Benveniste, B. Caillaud, D. Nickovic, R. Passerone, J. Raclet, P. Reinkemeier, A. Sangiovanni-Vincentelli, W. Damm, T. A. Henzinger, K. G. Larsen, et al. (2018) Contracts for system design. Foundations and Trends® in Electronic Design Automation 12, p. 124–400. Cited by: §I-C, §I. [5] A. Caregnato-Neto, M. R. Maximo, and R. J. Afonso (2022) Resilient robust connectivity for multiagent systems with line of sight using mixed-integer programming. Journal of Control, Automation and Electrical Systems 33 (1), p. 129–140. Cited by: §I. [6] S. Chung, A. Paranjape, P. Dames, S. Shen, and V. Kumar (2018) A survey on aerial swarm robotics. IEEE Transactions on Robotics 34 (4), p. 837–855. External Links: Document Cited by: §I. [7] Department of Defense (1991) MIL-hdbk-217f: reliability prediction of electronic equipment. Washington, DC. Cited by: 1st item. [8] H. Forsberg, J. Lindén, J. Hjorth, T. Månefjord, and M. Daneshtalab (2020) Challenges in using neural networks in safety-critical applications. In Proceedings of the 2020 AIAA/IEEE 39th Digital Avionics Systems Conference (DASC), p. 1–7. External Links: Document Cited by: §VI-A. [9] Q. Gao, T. Lei, W. Yao, X. Zhang, and X. Zhang (2023) A health-aware energy management strategy for fuel cell hybrid electric uavs based on safe reinforcement learning. Energy 283, p. 129092. Cited by: §I. [10] L. Giacomossi, A. Haglund, C. Namatovu, E. Zainali, E. Målqvist, Y. M. Beyene, I. Tomasic, B. Çürüklü, and H. Forsberg (2026) Market-based replanning for safety-critical uav swarms in search and rescue missions. External Links: 2606.01970, Link Cited by: §I. [11] L. Giacomossi, M. R. O. A. Maximo, N. Sundelius, P. Funk, J. F. B. Brancalion, and R. Sohlberg (2024) Cooperative search and rescue with drone swarm. In International Congress and Workshop on Industrial AI and eMaintenance 2023, U. Kumar, R. Karim, D. Galar, and R. Kour (Eds.), Cham, p. 381–393. External Links: ISBN 978-3-031-39619-9 Cited by: §I. [12] L. Giacomossi, F. Souza, R. G. Cortes, H. Mirko Montecinos Cortez, C. Ferreira, C. A. C. Marcondes, D. S. Loubach, E. F. Sbruzzi, F. A. N. Verri, J. C. Marques, L. A. Pereira, M. R. O. A. Maximo, and V. V. Curtis (2021) Autonomous and collective intelligence for uav swarm in target search scenario. In 2021 Latin American Robotics Symposium (LARS), Vol. , p. 72–77. External Links: Document Cited by: §I. [13] B. Johnson (1984) Fault-Tolerant Microprocessor-Based Systems . IEEE Micro 4 (06), p. 6–21. External Links: ISSN 1937-4143, Document, Link Cited by: §I, §I. [14] Joint Authorities for Rulemaking on Unmanned Systems (2024) JARUS guidelines on Specific Operations Risk Assessment (SORA). Guidelines Technical Report JAR-DEL-SRM-SORA-MB-2.5, JARUS. Note: Version 2.5 Cited by: §I, §I-A. [15] M. W. Mueller and R. D’Andrea (2014) Stability and control of a quadrocopter despite the complete loss of one, two, or three propellers. In IEEE International Conference on Robotics and Automation (ICRA), p. 45–52. External Links: Document Cited by: §I, §I-C. [16] N. P. Nguyen, N. X. Mung, and S. K. Hong (2019) Actuator fault detection and fault-tolerant control for hexacopter. Sensors 19 (21). External Links: Document Cited by: §I, TABLE VI. [17] J. G. Rivera, A. A. Danylyszyn, C. B. Weinstock, L. R. Sha, and M. J. Gagliardi (1996) An architectural description of the simplex architecture. Technical report Technical Report CMU/SEI-96-TR-006, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA. Note: ESC-TR-96-006 Cited by: §I. [18] S-18 Aircraft and Sys Dev and Safety Assessment Committee (2023) ARP4754B: guidelines for development of civil aircraft and systems. SAE International, SAE International. Note: SAE Aerospace Recommended Practice (ARP) External Links: Document, Link Cited by: TABLE I, §I. [19] SAE International (2023) ARP4761A, Guidelines and Methods for Conducting the Safety Assessment Process on Civil Airborne Systems and Equipment. Aerospace Recommended Practice SAE Intern.. Cited by: §I. [20] Texas Instruments (2018) TMS570LS31x/21x 16/32-bit risc flash microcontroller safety manual. Note: Literature Number: SPNU511D Cited by: 2nd item. [21] C. Torens, P. Nagarajan, S. Schirmer, J. Dauer, J. E. Baumeister, F. Kohn, B. Finkbeiner, G. Manfredi, and F. Löhr (2024) Certification aspects of runtime assurance for urban air mobility. In AIAA SciTech 2024 Forum, p. 1464. Cited by: §I. [22] V. Varadharajan, D. St-Onge, B. Adams, and G. Beltrame (2020) Swarm relays: distributed self-healing ground-and-air connectivity chains. IEEE Robotics and Automation Letters 5 (4), p. 5347–5354. External Links: Document Cited by: §I. [23] C. -H. Wu, T. -J. Chen, T. -Y. Hsu, S. -H. Tsai, and H. -P. Chang (2017) Design of applying flexray-bus to federated archiectecture for triple redundant reliable uav flight control system. In 2017 IEEE International Conference on Dependable, Autonomic and Secure Computing (DASC), p. 73–78. External Links: Document Cited by: §I. [24] X. Zhang and X. Zhao (2021) Architecture design of distributed redundant flight control computer based on time-triggered buses for uavs. IEEE Sensors Journal 21 (3), p. 3944–3954. External Links: Document Cited by: §I. [25] J. Zhao, C. Yang, G. Liu, W. Wang, T. Qie, C. Xiang, and H. Liu (2024) A flight-fault-aware path planning strategy for vtol intelligent air-ground vehicle using game learning approach. IEEE Transactions on Intelligent Vehicles. Cited by: §I, §I, §I.