Certified BVLOS Delivery Drone
A European commercial-drone OEM (~150 staff, ~40 engineers) is taking a Wingcopter-198-class fixed-wing eVTOL (25 kg MTOW, 4–6 kg payload, 90–110 km range) into urban parcel delivery. The autopilot is PX4 on a Pixhawk FMUv6X — an STM32H753 Cortex-M7 at 480 MHz with three isolated ICM-45686 IMU domains, so the EKF2 estimator can vote out a failed or spoofed sensor mid-flight. To fly beyond visual line of sight over a mixed-density corridor, the operation must clear EASA's Specific category via SORA 2.5 and lands at SAIL III–IV, which triggers High-robustness Operational Safety Objectives and, at SAIL IV, a mandatory EASA Design Verification Report. Five engineers carry the safety and certification load.
Illustrative scenario — representative figures, not a customer result.
OSO & containment evidence authoring
auto-mapped, model-checked & regenerated
Design Verification Report pack generated
- Systems safety & certification lead (owns the OSO and containment case)
- Flight-control / autopilot team (PX4 control loops, EKF2, failsafe state machine)
- GNSS & security engineer (Galileo OSNMA, C2 link integrity)
- Safety-mechanisms engineer (flight-termination system, witnessed ASTM F3322 tests)
- Regulatory affairs (interfaces the national authority — LBA / DGAC / AESA — and EASA)
- Independent V&V / review board
- PTC Codebeamer / Jama — Requirements & OSO traceability
- PX4 · QGroundControl — Autopilot firmware & ground station
- Hand-built FTA / FMEA sheets — OSO integrity & containment argument (manual)
- ParaZero FTS + ASTM F3322 tests — Flight termination, witnessed deployments
- SCADE (evaluated, not bought) — Deemed unaffordable at this scale
SORA 2.5 (JARUS Main Body, adopted by EASA) lands the ConOps at SAIL III–IV. That forces the 17 OSOs to be argued at Not-Required / Low / Medium / High robustness, each with both an integrity (design) and an assurance (evidence) case, plus a now-SAIL-dependent containment level (Low / Medium / High) that must prove the aircraft cannot breach the minimum 5 km adjacent area. The C2 link must meet a Required Link Performance budget under EASA's MoC to OSO#6. Almost all of this is authored by hand — a comparable Spanish team spent roughly a year getting a first urban SAIL III authorization past AESA under the new SORA 2.5 MoC.
Containment is argued by narrative, not proof
Annex E containment requires showing no single failure lets the aircraft leave the ground-risk buffer or breach the adjacent area. Today that is FTA spreadsheets plus flight logs — re-authored by hand every time the operational volume or a no-fly polygon changes.
GNSS spoofing has no clean answer
Galileo OSNMA (operational as an Initial Service since July 2025) authenticates the navigation message — but it is spoofing detection, not prevention, gives no jamming protection, and carries an inherent ~30 s TESLA key-disclosure delay. The autopilot must dead-reckon on IMU/baro and decide within a bounded window — a timing property nobody verifies formally.
OSO integrity is unaffordable rigor
OSO#05 at SAIL IV maps to roughly DAL-C software integrity, but a full SCADE toolchain is out of budget for a 150-person OEM — so integrity ends up argued informally rather than demonstrated.
Every ConOps change restarts the paperwork
A new route or population overlay re-opens the whole OSO and containment case as a manual re-review — the assurance case never stops being rebuilt.
Roughly a year of hand-authored OSO, containment and C2-link evidence for one SAIL III–IV authorization — re-done from scratch on every ConOps change.
One coherent flow, applied to this system.
-
01Requirements Structure the ConOps against the SORA 2.5 step tree and auto-seed the threat library.
Dextra ingests the ConOps / Detailed Operational Information (SORA 2.5 Annex A templates) and structures it against the step tree — final GRC, residual ARC, SAIL. The threat library automatically adds GNSS spoofing/jamming, C2 link-loss and containment breach, mapping each to the 17 OSOs and the required robustness level.
Output Structured requirement + threat set, traced to every applicable OSO. -
02Behaviour Encode failsafe, containment and link-loss logic as timed automata.
The geocage-breach → flight-termination path, the OSNMA-divergence → dead-reckon → declare-spoof path, and the C2 link-loss timer (hold → RTL → terminate) are captured as timed automata. TCTL properties are derived directly — the behavioural contract the rest of the pipeline is built on.
Output Timed-automaton behavioural contract + derived TCTL properties. -
03Formal verification Model-check the containment and link-loss deadlines under worst-case latency and single failures.
Model checking proves the containment reaction and link-loss escalation hold under worst-case link latency and any single failure — discharging the OSO#05 integrity argument that is a narrative FMEA today, and mapping to the High-integrity failure-probability targets (catastrophic ≤ extremely improbable) SAIL IV demands.
Output Machine-checked proof feeding the OSO integrity + Annex E containment evidence. -
04Design-space exploration Sweep redundancy vs mass, power and cost against the delivery mission.
A Pareto sweep over single/dual/triple IMU, standard GNSS vs an OSNMA-capable receiver, and single vs dual-bearer C2 — each configuration re-checked against the timing and containment properties and scored on the payload the delivery mission still needs. Adding a third IMU buys OSO#05 reliability but costs payload.
Output Pareto frontier of certifiable, mission-viable configurations. -
05Platform selection Fix the hardware/software platform, with containment on an independent partition.
The selected point puts the containment and flight-termination logic in an independent monitoring partition on a DAL-A RTOS (Green Hills INTEGRITY-178 tuMP, ARINC 653-style time-and-space partitioning), separated from the DAL-C PX4 navigation stack — the independence SAIL IV's High containment robustness requires.
Output Fully specified HW/SW platform with partitioned monitoring channel. -
06Certification artifacts Emit verified code to a qualified backend and generate the SORA evidence pack.
Verified code is emitted to a qualified backend (SPARK Ada, with proof of absence of run-time errors), and a per-OSO + Annex E evidence pack is generated, formatted for the SORA 2.5 submission and the SAIL IV Design Verification Report — regenerated automatically on any ConOps change. (Honest note: formal proof supplements, not replaces, the required on-target testing; earning full credit needs the generator/checker qualified.)
Output SORA / OSO evidence package + verified flight-termination code.
AG(geocage_breach → AF≤T_term flight_termination)
From any state, a containment breach forces flight termination within the bounded reaction time, so debris stays inside the ground-risk buffer.
AG(gnss_unauthenticated → AF≤T_dr imu_dead_reckon)
An unauthenticated Galileo message triggers IMU/baro dead-reckoning within bound — bridging the OSNMA key-disclosure delay before a spoof is declared.
AG(c2_lost → AF≤T_ll (hold ∧ then RTL ∧ then terminate))
Loss of the command link deterministically escalates through hold, return-to-launch and termination within the required link-performance deadline.
An interactive Pareto frontier for this system — every point a valid, formally checked configuration. Hover any point to inspect the full hardware-software specification.
Modeled, conservative and sourced — see the full ROI methodology.
The evidence-authoring bottleneck — not the aircraft — is what compresses. Containment and OSO integrity become machine-checked and regenerable, the SAIL IV Design Verification Report is met with a traceable pack instead of a year of spreadsheets, and a ConOps change re-runs the proofs automatically. Modeled ROI: ~304%, payback in about three months.
See how the pipeline works.
From requirements to certified artifacts, in six stages.