Why split inference between edge and cloud?

Because doing everything in one location breaks at scale. Cloud-only inference requires continuous high-bandwidth uplink to stream raw video — impractical for rail corridors, pipelines, transmission lines, and offshore wind, all of which pass through cellular dead zones or beyond reliable LTE range. Edge-only inference can't run the deep per-asset detectors needed for procurement-grade accuracy because the on-board Jetson doesn't have enough compute for the larger model. The split is the architectural answer: edge runs a light first-pass classifier (yes/no candidate) on every frame; cloud runs the deep classifier (per-asset taxonomy, severity scoring, GPS pinning) only on the candidate frames. The combined system gets the accuracy of the deep model with the bandwidth profile of the edge model.

What runs on the edge specifically?

The Nvidia Jetson on-board the drone runs a per-asset edge classifier in real time during flight. The classifier is a lighter-weight version of the cloud-side per-asset detector — same per-asset taxonomy but optimised for inference speed on Jetson-class hardware. For each captured frame, the edge classifier produces a binary candidate-or-not decision plus a confidence score. Most frames — the routine no-anomaly-detected ones — are classified, logged for audit, and never travel further. Frames with candidate detections plus a metadata wrapper (timestamp, GPS coordinates, flight-state context) get uploaded to cloud for deeper analysis.

What runs in the cloud specifically?

The deeper per-asset detectors run cloud-side against candidate frames flagged by edge. The cloud federation includes specialised detectors per asset class (rail-fastener detector, wind-blade detector, transmission-tower detector, pipeline-weld detector, etc.) trained against the operator's labelled data. The cloud handles severity scoring (translating raw detection into operationally-meaningful priority), GPS pinning (matching detection coordinates to the operator's asset-identifier inventory), historical comparison (against previous inspections of the same asset), and the operator-handoff layer that routes detections into the operator's CMMS / asset-management workflow. The cloud-side latency budget is generous compared to edge — seconds per candidate frame rather than the milliseconds the edge runs at — which lets the deep model run at higher accuracy.

What about bandwidth in degraded environments?

Bandwidth-thin operation is the default rather than a fallback. Because edge handles every frame and only candidate frames travel to cloud, the bandwidth required to operate the system is dramatically lower than continuous video streaming. Typical deployment runs over LTE for civilian linear infrastructure (rail corridors, pipelines, transmission lines) and over satellite for offshore wind, remote critical infrastructure, and defense deployments. Even degraded RF environments — defense FOBs under contested spectrum, subterranean transit, environmental obstruction — support the system because the candidate frame volume is kilobytes per minute, not gigabytes per hour. For deployments where uplink fails entirely during a flight, the drone completes the mission with edge-only operation and uploads the accumulated candidate frames when uplink is re-established (typically when the drone returns to dock).

How does this enable sub-15-minute report latency?

By keeping the bottleneck off the cloud-side. Sub-15-minute report latency measures from drone landing to maintenance-planner dispatch of the inspection report. Three components compress simultaneously. (1) Edge first-pass — every frame classified during flight, not in post-processing. The candidate frames are uploaded continuously during flight; the cloud receives them in near-real-time, not after landing. (2) Cloud-side deep analysis — runs on a small candidate set (10s-100s of frames per inspection run, not 10,000s of frames of raw video). The deep analysis finishes within minutes of upload completion. (3) Operator handoff — annotated, severity-scored detections route directly into the operator's existing maintenance-planning stack via the integration layer. No analyst-in-the-loop review step blocks the dispatch.

How does data sovereignty work in this architecture?

Enforced by architecture rather than configuration. The edge inference happens on the drone — no telemetry leaves the device during routine flight. The candidate frames that do leave the drone travel to sovereign cloud infrastructure inside EU and US jurisdictions only. The cloud-side processing, the audit trail, the historical archive — all live inside the sovereign envelope. Operator data path is auditable end-to-end. EU NIS2 critical-infrastructure compliance, US CISA framework alignment, and defense-grade data-protection requirements all map to the architecture without configuration changes. For operators that also handle classified or export-controlled data, additional segmentation (air-gapped deployment regions, dedicated-tenant clusters, customer-managed encryption keys) is available within the sovereign envelope.

Edge + Cloud Inference for Drone-in-a-Box: The Split That Scales

The edge-and-cloud inference split is what makes drone-in-a-box deployment work at infrastructure scale. Edge-only fails on accuracy; cloud-only fails on bandwidth. The architectural split — edge first-pass on Nvidia Jetson, cloud deep-analysis on candidate frames only — is the structural answer that delivers procurement-grade accuracy at bandwidth-thin operation, sub-15-minute report latency, and sovereign data path.

This post is the architecture deep-dive for buyers, integrators, and primes evaluating the drone-in-a-box platform. It walks through what runs where, why the split is structurally necessary at scale, and what the deployment implications are across the use-case spectrum from linear-infrastructure inspection to perimeter security to defense-grade deployments.

Why neither extreme works alone

Two architectural extremes don't survive contact with deployment reality at scale.

Cloud-only inference assumes the drone streams raw imagery to cloud, where all classification happens. This works for laboratory demonstrations and for deployments with unlimited high-bandwidth uplink. It doesn't work at infrastructure scale.

Rail corridors pass through cellular dead zones. Pipelines run through worse environments. Transmission corridors traverse mountain ranges. Offshore wind sites operate beyond reliable cellular range. Defense FOBs operate under deliberate RF denial. The bandwidth required to continuously stream inspection-grade video from drone to cloud — gigabytes per hour — is not available in any of these environments at the operational scale that drone-in-a-box deployment targets.

A cloud-only architecture that fails to operate in the bandwidth environments where the deployment actually has to run isn't a procurement-grade architecture.

Edge-only inference assumes the drone's on-board compute handles all classification. This works for narrow use cases with small per-asset taxonomies and forgiving accuracy targets. It doesn't work for the deep per-asset taxonomies that procurement-grade inspection requires.

The Nvidia Jetson on-board the drone is a meaningful compute platform — multi-core CPU plus dedicated AI accelerator — but it's not enough to run the deep per-asset detectors that produce the 95%+ accuracy at deployment scale. The deeper detectors require larger model sizes, more compute per inference, and more memory bandwidth than the Jetson can supply.

An edge-only architecture that ships at lower accuracy than the deep models can achieve isn't competitive with the federation-of-deep-detectors approach that the cloud architecture enables.

The split, in detail

The Halo Cloud architecture splits inference responsibilities across three layers, with the split point calibrated for the structural properties of each layer.

Edge classifier — every frame, milliseconds

The Nvidia Jetson runs a per-asset edge classifier in real time during flight. For each captured frame:

Input: a frame from the drone's primary inspection sensor (EO/IR camera, thermal sensor, or specialised payload depending on mission profile)
Compute: ~50-200 milliseconds per frame depending on the per-asset model complexity and the Jetson SKU
Output: a binary candidate-or-not decision plus a confidence score, plus a metadata wrapper (timestamp, GPS coordinates, flight-state context, sensor configuration)

The classifier is a lighter-weight version of the cloud-side per-asset detector — same per-asset taxonomy but optimised for inference speed on Jetson-class hardware. Model architecture is typically distilled from the cloud-side teacher model: smaller layer dimensions, quantised weights, pruned connections.

The decision threshold for "candidate" is set conservatively. Borderline frames (low-confidence candidates) are flagged as candidate; the recall on the edge is high. Precision is the responsibility of the cloud-side deep analysis. Sending more candidates than strictly necessary wastes some bandwidth but ensures no real defects get filtered out at the edge.

The frames that are not flagged as candidates — the no-anomaly-detected routine frames, which are the vast majority — are logged for audit purposes (timestamp, GPS, classifier-output, model version) but the imagery itself is not retained or uploaded. The audit log is bandwidth-cheap and supports the procurement-grade audit trail.

Cloud-side deep analysis — candidate frames only, seconds

The cloud-side layer runs the deeper per-asset detectors against the candidate frames. The federation includes one specialised detector per asset class — rail-fastener detector, wind-blade detector, transmission-tower detector, insulator detector, pipeline-weld detector, port-quay-wall detector, etc. — each trained against the operator's labelled data plus synthetic supplementation for rare defect classes.

For each candidate frame from the edge:

Routing: orchestration routes the frame to the appropriate per-asset detector based on the deployment context (the operator knows which asset class they're inspecting; explicit routing is faster and more reliable than imagery-based inference)
Compute: ~1-10 seconds per candidate frame depending on detector complexity and severity-scoring depth
Output: classification result (defect class within per-asset taxonomy), severity score, GPS-pinned asset identifier (matching detection to operator's asset-inventory), historical comparison (against previous inspections of the same asset), confidence metadata

The cloud-side latency budget is generous compared to edge — seconds per candidate frame rather than the milliseconds the edge runs at — which lets the deep model run at higher accuracy. The model size, the per-asset specialisation, and the inference-time investment all combine to produce the 95%+ accuracy at deployment scale.

The cloud-side analysis runs on infrastructure inside EU and US jurisdictions only. Specific cloud regions vary per operator deployment (an EU rail operator's data stays in EU regions; a US federal-civil deployment stays in US regions). The compute resource and the data residency are tightly coupled.

Operator handoff layer — workflow integration

The third layer integrates the detections into the operator's existing maintenance-planning infrastructure. This is the layer that determines whether the technical capability becomes operationally usable.

The handoff routes detections into the operator's CMMS / EAM / asset-management platform — typically Maximo, SAP PM, IBM Asset Management, vendor-specific platforms, or custom internal systems. Format adaptation, field-mapping, alert-priority routing, and historical-context attachment all happen in this layer.

The maintenance planner sees prioritised lists of defects with severity scores, GPS coordinates, asset identifiers, historical comparison, and recommended action classes — in the planner's existing workflow, not in a separate vendor-specific console. This is the property that converts AI inspection from a vision-AI demo into a deployment the operator depends on.

Bandwidth economics in practice

The data-volume difference between cloud-only and edge+cloud is structural.

A typical drone-in-a-box inspection run captures 10-20 minutes of high-resolution sensor data at 30-60 frames per second. Raw video volume runs roughly 5-15 GB per inspection run depending on sensor resolution and codec.

Cloud-only would require uploading all 5-15 GB during or after the flight. At LTE bandwidth (~10-50 Mbps practical uplink), this takes 15-60 minutes of continuous transmission. At satellite bandwidth (typically 1-5 Mbps), it takes hours. Both timelines break the sub-15-minute latency target.

Edge+cloud reduces the uplink volume to the candidate frames only. A typical inspection run produces 10s to low 100s of candidate frames per kilometre of inspected infrastructure (varies by asset condition; a network with mostly-good condition produces fewer candidates than a network with extensive deferred maintenance). Each candidate frame is ~100 KB to ~1 MB depending on resolution and metadata. Total upload per inspection run is typically 10-100 MB — two orders of magnitude less than the raw-video equivalent.

At LTE bandwidth, 10-100 MB uploads in seconds to minutes. At satellite bandwidth, in minutes. The bandwidth budget fits inside the latency target with significant margin.

The same architecture handles degraded environments. Defense FOBs under RF denial — the drone runs the full mission with edge inference, accumulates candidate frames locally, and uploads when uplink is re-established (typically when the drone returns to dock). Subterranean transit — edge runs the entire mission; the cloud sync happens at dock. Offshore wind — similar pattern, with the dock providing the stable uplink endpoint.

Sovereign data path

The architecture enforces data sovereignty without requiring per-deployment configuration.

Edge layer: telemetry stays on the drone during routine flight. The drone connects to the operator's specified uplink endpoint only — typically a dock-mounted gateway or a direct operator-owned uplink — not to third-party cloud endpoints.

Cloud layer: processing runs on infrastructure inside EU and US jurisdictions. The specific regions depend on the operator deployment, but the architectural constraint is that no inference, storage, or audit logging passes through hyperscaler regions in adversarial jurisdictions. Cross-region data movement stays inside the sovereign envelope.

Audit trail: every detection, every reviewer decision, every model version, every flight log lives inside the sovereign envelope. Regulator-accessible reporting routes through operator-controlled or operator-approved endpoints.

EU NIS2 compliance, US CISA critical-infrastructure framework alignment, defense-grade data-protection requirements — all map to the architecture without configuration changes. For operators handling classified or export-controlled data, additional segmentation (air-gapped deployment regions, dedicated-tenant clusters, customer-managed encryption keys) is available within the sovereign envelope.

What this means for deployment buyers

For rail, energy, port, and critical-infrastructure operators — the edge+cloud architecture is what makes drone-in-a-box deployment operationally viable in your environment. Bandwidth-thin operation, sub-15-minute report latency, sovereign data path. The accuracy delivered is procurement-grade (95%+ at Deutsche Bahn-scale validation).

For defense buyers (FOB protection, base perimeter, sovereign-airspace counter-UAS, deployable C2) — the edge inference operates without uplink dependency. The drone executes its full mission and returns to dock even if uplink is denied during flight. The bandwidth-thin profile fits inside satellite-uplink budgets typical at deployed defense installations.

For primes building larger systems with drone-in-a-box as a workpackage — the edge+cloud split is reproducible inside your platform architecture. The Halo Cloud orchestration and the per-asset taxonomy federation are licensable as components, with Dronehub providing the manufactured drone-and-dock hardware under sovereign supply chain.

The Halo Cloud architecture deep-dive (asset-class-specific perspective) is at /blog/halo-cloud-architecture-deep-dive. The per-fastener detection deep-dive (showing what the cloud-side detector federation actually does) is at /blog/per-fastener-defect-detection-95-percent. The drone-in-a-box product page is at /drone-in-a-box. The Deutsche Bahn deployment that validated the architecture at national scale is at /projects/deutsche-bahn. For a deployment conversation, open the contact form.

Key facts

The Dronehub drone-in-a-box architecture splits inference between edge (Nvidia Jetson on-board the drone) and cloud (sovereign infrastructure in EU/US). Edge runs first-pass classification on every frame; cloud runs deeper per-asset analysis only on candidate frames flagged by edge.
Source · Halo Cloud architecture documentation
The edge classifier reduces the data volume crossing to cloud by approximately two orders of magnitude versus continuous video streaming — kilobytes per minute of candidate frames instead of gigabytes per hour of raw video.
Source · Halo Cloud bandwidth-economics analysis
Sub-15-minute report latency from drone landing to maintenance-planner dispatch is achievable through the edge-cloud split — the cloud-side deep analysis runs on a small set of candidate frames, not on the full inspection-run video.
Source · Halo Cloud × Deutsche Bahn deployment latency metrics
Bandwidth-thin operation works over LTE, satellite, or degraded RF — critical for linear-infrastructure deployments (rail corridors, pipelines, transmission lines, offshore wind clusters) where continuous high-bandwidth uplink is not available.
Source · Halo Cloud deployment-environment analysis
Edge inference operates without uplink dependency for the duration of the flight — the drone can execute its full inspection mission and return to dock even if uplink is denied during flight.
Source · Halo Cloud edge-architecture specifications
EU and US data sovereignty is enforced by architecture — no telemetry leaves the drone during routine flight, and the cloud-side processing runs on infrastructure inside EU and US jurisdictions only.
Source · Halo Cloud data-sovereignty topology

FAQ

Why split inference between edge and cloud?: Because doing everything in one location breaks at scale. Cloud-only inference requires continuous high-bandwidth uplink to stream raw video — impractical for rail corridors, pipelines, transmission lines, and offshore wind, all of which pass through cellular dead zones or beyond reliable LTE range. Edge-only inference can't run the deep per-asset detectors needed for procurement-grade accuracy because the on-board Jetson doesn't have enough compute for the larger model. The split is the architectural answer: edge runs a light first-pass classifier (yes/no candidate) on every frame; cloud runs the deep classifier (per-asset taxonomy, severity scoring, GPS pinning) only on the candidate frames. The combined system gets the accuracy of the deep model with the bandwidth profile of the edge model.
What runs on the edge specifically?: The Nvidia Jetson on-board the drone runs a per-asset edge classifier in real time during flight. The classifier is a lighter-weight version of the cloud-side per-asset detector — same per-asset taxonomy but optimised for inference speed on Jetson-class hardware. For each captured frame, the edge classifier produces a binary candidate-or-not decision plus a confidence score. Most frames — the routine no-anomaly-detected ones — are classified, logged for audit, and never travel further. Frames with candidate detections plus a metadata wrapper (timestamp, GPS coordinates, flight-state context) get uploaded to cloud for deeper analysis.
What runs in the cloud specifically?: The deeper per-asset detectors run cloud-side against candidate frames flagged by edge. The cloud federation includes specialised detectors per asset class (rail-fastener detector, wind-blade detector, transmission-tower detector, pipeline-weld detector, etc.) trained against the operator's labelled data. The cloud handles severity scoring (translating raw detection into operationally-meaningful priority), GPS pinning (matching detection coordinates to the operator's asset-identifier inventory), historical comparison (against previous inspections of the same asset), and the operator-handoff layer that routes detections into the operator's CMMS / asset-management workflow. The cloud-side latency budget is generous compared to edge — seconds per candidate frame rather than the milliseconds the edge runs at — which lets the deep model run at higher accuracy.
What about bandwidth in degraded environments?: Bandwidth-thin operation is the default rather than a fallback. Because edge handles every frame and only candidate frames travel to cloud, the bandwidth required to operate the system is dramatically lower than continuous video streaming. Typical deployment runs over LTE for civilian linear infrastructure (rail corridors, pipelines, transmission lines) and over satellite for offshore wind, remote critical infrastructure, and defense deployments. Even degraded RF environments — defense FOBs under contested spectrum, subterranean transit, environmental obstruction — support the system because the candidate frame volume is kilobytes per minute, not gigabytes per hour. For deployments where uplink fails entirely during a flight, the drone completes the mission with edge-only operation and uploads the accumulated candidate frames when uplink is re-established (typically when the drone returns to dock).
How does this enable sub-15-minute report latency?: By keeping the bottleneck off the cloud-side. Sub-15-minute report latency measures from drone landing to maintenance-planner dispatch of the inspection report. Three components compress simultaneously. (1) Edge first-pass — every frame classified during flight, not in post-processing. The candidate frames are uploaded continuously during flight; the cloud receives them in near-real-time, not after landing. (2) Cloud-side deep analysis — runs on a small candidate set (10s-100s of frames per inspection run, not 10,000s of frames of raw video). The deep analysis finishes within minutes of upload completion. (3) Operator handoff — annotated, severity-scored detections route directly into the operator's existing maintenance-planning stack via the integration layer. No analyst-in-the-loop review step blocks the dispatch.
How does data sovereignty work in this architecture?: Enforced by architecture rather than configuration. The edge inference happens on the drone — no telemetry leaves the device during routine flight. The candidate frames that do leave the drone travel to sovereign cloud infrastructure inside EU and US jurisdictions only. The cloud-side processing, the audit trail, the historical archive — all live inside the sovereign envelope. Operator data path is auditable end-to-end. EU NIS2 critical-infrastructure compliance, US CISA framework alignment, and defense-grade data-protection requirements all map to the architecture without configuration changes. For operators that also handle classified or export-controlled data, additional segmentation (air-gapped deployment regions, dedicated-tenant clusters, customer-managed encryption keys) is available within the sovereign envelope.