AI for aerospace: where telemetry anomalies get lost
The onboard stream runs continuously across hundreds of channels, and its density exceeds the throughput capacity of the ground shift.
The operator sees aggregated summaries and triggered thresholds, not the signal itself — between raw measurements and the decision to intervene sits manual review, which physically cannot keep up with the reception rate.
Some frames are also lost during compression and reassembly, so the picture in analytics is inherently poorer than what was onboard.
Rare deviation almost never looks like crossing a boundary: it is a slow drift of one channel against the background of compensating behavior of neighboring channels, slight time-stamp desynchronization, a short dip that noise in the streaming data masks as ordinary variance.
Threshold rules are tuned for coarse triggers — they stay silent where sensitivity is needed and trigger on interference.
Missing rare failures here is not a configuration error but an architectural property: the detector compares a value with a constant, not with the expected behavior of the system in the current mode.
The cost of such a miss accumulates: an anomaly surfaces in post-flight analysis, when telemetry cannot be restored, and the cause is already blurred in accumulated statistics.
If the cycle repeats, downtime grows, as does the volume of unplanned checks and the share of failures found "on the ground" instead of "in flight."
This is addressed by shifting analysis to the stream: a normal-behavior model is built from historical runs and modes, and the detector works on the residual — the difference between expected and actual signal, accounting for correlations between channels.
Then telemetry anomalies stand out against noise, and decisions in AI for aerospace are made before, not after, the event. Let's break down how this works.
Measurable effects: early detection instead of post-flight analysis
The numbers that change during implementation are known in advance: the share of missed events, the share of false alarms, the number of signals per operator per shift, and the time from the appearance of a sign to the response of the duty shift.
We calculate the baseline on the telemetry archive — this is the reference point against which we later compare the result.
Approaches to anomaly detection in telemetry largely grew out of NASA practice, and the same place developed the habit of measuring the quality of alarms, not just their quantity.
| Approach | What it delivers in numbers | Limitations |
|---|---|---|
| Threshold rules on telemetry | Instant response when a parameter crosses a boundary, fully explainable triggering | Misses slow drifts; when operating mode changes, produces a stream of false alarms |
| Deviation model trained on normal modes | Early detection of incipient failures, reduced share of misses on smooth processes | Requires mode labeling and drift monitoring, otherwise error grows unnoticed |
| Hybrid: rules, model, and expert review | Combines explainability and sensitivity, keeps the false alarm rate at an acceptable level longer | Requires priority tuning and a decision log for reviewing disputed cases |
Prioritization is a separate job. If the model produces hundreds of equivalent signals, the operator stops reacting to them, and early failure detection turns into noise.
Therefore we reduce the output to a short list with a criticality score and a reference to the telemetry section where the sign appeared: the operator sees not "an anomaly in general" but a specific section and confirms or rejects the hypothesis in seconds.
The operator's workload decreases not by disabling checks but by merging them: several signs of one process are collected into a single event with history. Time to response shrinks because the duty shift receives ready context instead of a set of disconnected notifications.
After launch, we recalculate metrics on the same archive — this shows what each block contributed and which thresholds should be revisited.
Model operating modes: onboard, on the ground, hybrid
The place of computation is determined not by convenience but by constraints: channel bandwidth, required decision latency, platform compute budget, and flight autonomy.
The same model can run in three loops, and the choice determines what the system manages to do without communication with the ground.
| Scheme | When it fits | Limitations |
|---|---|---|
| Onboard data processing | A decision is needed faster than the signal can reach the ground and return: failure detection, mode change, collision avoidance | Compute budget and power are limited, the model is made lighter; weights are updated only during a communication session |
| Ground analysis loop | Heavy tasks: telemetry recovery, anomaly analysis, planning, training on accumulated data | There is telemetry delivery latency; in a communication shadow the loop is unavailable |
| Hybrid processing scheme | Both fast response and deep analytics are needed: onboard reacts, ground refines and retrains | Requires consistent model versioning and decision exchange |
The difference between schemes shows up when communication is lost. At that moment the ground loop loses observability, while onboard processing continues to work with the version of the model loaded onboard.
That is why a hybrid is built this way: critical decisions remain onboard, and everything deferred goes to the ground.
The compatibility condition is a unified input and output format and one model version across all loops: updating weights does not break the onboard side, and autonomous decisions are reproducible and reviewable at the next session.
Step-by-step implementation: audit, scheme, tuning, validation
Order matters more than speed here. If you start with the model rather than the data, you get a beautiful metric on a shuffled sample and a useless result in real operation.
Therefore the first stage is an audit of data and processes: we look at what is actually written to the archive, at what interval, where there are gaps and sensor outliers, and how failures are recorded in logs.
Then the work proceeds in iterations — from labeling to handing the solution over to the operating team. Below is the sequence we follow for such projects.
- Data and process audit. We review the telemetry archive and logs: which channels are live, where recording gaps are, how failure marks are formatted. The output is a data map and a list of limitations.
- Rare event labeling. Target anomalies are few and far between, so we agree the label dictionary and rules with operations engineers, and review disputed cases separately — otherwise the model learns from contradictory examples.
- Solution scheme and baseline. We fix the target metric — detection recall at an acceptable false positive rate — and assemble a simple reference variant against which we compare everything further.
- Tuning on historical data. We split history by time, not randomly: training on earlier segments, validation on later ones. This prevents future data from leaking into training.
- Validation on a held-out sample. We run the solution on data it has not seen: another period, another vehicle, or operating mode. We separately examine behavior on rare events and on noise.
- Solution handover. We provide documentation, a periodic retraining procedure, drift monitoring, and team training — the system continues to operate without our involvement.
Handover package: configurations, schemes, procedures, reports
The handover package is not a keepsake archive but a working kit your team can use to operate and develop the system without our involvement. We assemble it throughout the project, not in the final week, and hand it over together with access and the deployed loop.
- Model passport: purpose, modes on which it was trained and validated, and an honest list of conditions where the output is invalid.
- Integration scheme: connection points to onboard and ground systems, exchange formats, degradation order when a channel is lost, and the operator's manual mode.
- Configurations: parameter files for data preparation, training, and inference with a description of which parameter affects what and how to change it safely.
- Response procedure: what to do during input data drift, going beyond applicability limits, and unit failure — with trigger thresholds and roles.
- Validation reports: verification methodology, test sets, quality metrics by event class, and analysis of erroneous triggers.
- Logs and reproducibility: how to rebuild the same result from source data and obtain comparable quality.
- Shift instructions: a reference for typical situations, diagnostics, and escalation.
We finish the handover with a joint review: we go through each item, answer your engineers' questions, and record what we refine and what remains on your side. If another team later develops the solution, the logic won't have to be reconstructed from the code.
Case study: how anomaly misses in telemetry were reduced
The implementation case began with an archive audit: the customer had accumulated hundreds of flights with already analyzed incidents, and on this data two approaches could be fairly compared on the same sample.
Before that, telemetry monitoring relied on threshold rules — boundaries were set for each channel, and anything that crossed them went into the review queue.
Before: thresholds and their blind spots
Thresholds catch sharp outliers well but miss slow degradation spread across dozens of parameters. On the Orbita archive, measurement showed that about a third of confirmed anomalies did not cross any boundary and were found post factum, during flight data analysis.
At the same time, up to 60% of triggers turned out to be false — engineers spent a shift checking nominal modes.
After: model on the same archive
We trained a model on the joint behavior of channels: it estimates how much the current parameter vector deviates from the typical one for a given flight mode and highlights not a single value but a group discrepancy.
On the same held-out sample, anomaly misses dropped from 31% to 7%, the false alarm rate fell by about half, and degradation that used to be noticed tens of minutes after onset is raised by the model in the first minutes — the decision to abandon a maneuver is made before resource loss.
We did not remove threshold rules: they remained a fast loop and a clear constraint. The model works on top of them, and each trigger is accompanied by channel contributions — the engineer sees the cause, not a "black box."
What to do if thresholds are already implemented for aerospace?
Threshold rules do not need to be discarded — they remain a safety loop that catches parameters going beyond acceptable limits and works independently of the model.
The model takes on slow trends: degradation of a unit over tens of hours, which the threshold records only when already at the edge of failure. Therefore we first delineate areas of responsibility rather than switching over control.
Integration with the existing loop goes through an advisory mode: the model does not issue shutdown commands or change control logic. It forms a state estimate with a confidence level, and the decision is made by whoever is responsible for the vehicle according to procedure. Model events are written to the same log as threshold triggers.
Retraining starts with the archive.
We do not draw labels manually: maintenance events — unit replacements, failures — are linked to telemetry records and we obtain labels retroactively; where our own cases are few, we supplement with open datasets on engine diagnostics published by NASA. Training is offline, on features available in flight.
Validation on the archive is a mandatory stage before inclusion in the loop. A retro-run shows how many failures the model caught in advance, how long before the event, and how many false alarms it produced per flight hour.
We compare with the existing thresholds on the same data: until the model wins on these metrics, it does not go into operation.
Next comes shadow mode on the live stream: predictions are calculated but affect nothing, and disagreements with thresholds are visible without risk. Procedures and responsibility remain in place — only the depth of warning changes.
Technical concerns: data, false alarms, autonomy
Concerns before starting an AI for aerospace project are almost always the same: telemetry failures are rare, labeling is incomplete, the onboard compute budget is tight, and the result must be reproduced a year later by another team. Below is how we address each of them.
Failures are few per thousands of flights — what do we train the model on?
A small sample of rare events is supplemented by a physical model of the unit: emergency modes are computed rather than waiting for a real case.
Real-world recordings remain the reference — we use them to check that synthetic data does not bias the decision, and we calibrate the trigger threshold by the cost of a miss and a false alarm.
Labels exist for only part of the telemetry — will the model even train?
Usually less than half of the records are labeled. We work with weak labeling: the model trains on confident examples, an expert engineer additionally labels disputed sections, and disagreements between labelers are counted as a separate quality metric.
How does the model coexist with onboard constraints?
The network is compressed to the compute budget via distillation and quantization, but the loop remains hybrid: when tolerances are exceeded, a deterministic controller takes over control. This removes the question of what happens if the network errs.
Can the result be reproduced six months later?
We fix versions of data, weights, hyperparameters, and environment, write runs to an experiment registry, and do not change control sets. The same input yields the same result — this is an acceptance condition, not a promise.
Let's discuss your task and come back with an estimate and plan
For the conversation to be substantive rather than general talk about artificial intelligence, basic inputs about your task are enough. Presentations and a formalized technical specification are not needed — describe the area and attach what you already have at hand.
- Process or area: telemetry analysis, assembly control, unit diagnostics — how it runs now and where manual work becomes a bottleneck.
- Data: telemetry, images, logs, operator recordings. Format, volume, frequency, and period — this shows whether there is enough material.
- Access and storage: file export, stream, or a closed loop without external access. This determines where the model is trained and runs.
- Decisions based on the result and who makes them: operator, engineer, or automation — this determines the form of the system's response.
- Which error is more expensive: a miss, a false alarm, or a delay. Different error classes set tuning and acceptance.
- Constraints and acceptance: placement requirements, industry procedures, and metrics by which you will say "it works."
In response we send a work plan, not general considerations: a scheme of the pilot area, what we calculate on your data, acceptance criteria with numbers — share of missed defects, share of false alarms, response time — and an estimate of timelines and team composition. Describe the task — we will come back with an estimate and a plan.
