Mission Ready Anomaly Detection for Spacecraft Telemetry on CubeSats

Which machine-learning methods actually work for spacecraft telemetry?

There is no universal algorithm that can span all telemetry channels on a spacecraft. Slow-drift, high-forgiveness thermal sensors. Fast-spiking, punishing attitude control channels. The real art is in mapping method to signal, and to the mission's compute budget.

Out-of-limits thresholding continues to be the most commonly used method for well-characterised channels. It's cheap, interpretable, and still snags most gross failures. Its main weakness is contextual anomalies. A voltage reading that's "normal" in isolation, but wrong given the spacecraft's current mode, won't cross a static limit.

Clustering methods, such as streaming k-means variants, cluster multivariate state vectors and flag outlying points that don't belong to well-established clusters. Clustering methods require no labelled anomalies, which is significant considering how sparse confirmed anomaly labels are in flight data. Clustering methods degrade gracefully on edge hardware because centroid updates are computationally inexpensive.

Forecasting and threshold approaches (LSTM, TCN) forecast the next expected value per channel and detect deviation from that value. NASA's open LSTM-based Anomaly Detection System for Spacecraft Telemetry is a representative example of this class. It is designed to work with multivariate, high-cardinality telemetry streams like spacecraft create. These methods are good at detecting drift and gradual degradation, but they require useful training history per channel.

Graph Convolutional Networks and Temporal Convolutional Networks can capture cross-channel dependencies that simpler models would miss. A review of anomaly detection methods in spacecraft telemetry found that GCN and TCN architectures have achieved precision in the mid-90s on benchmark datasets. That's impressive, but it's at the cost of much heavier training-data and compute requirements than most flight computers can absorb unassisted.

A rough selection matrix:

• Edge hardware constrained, not labelled anomalies: streaming clustering, lightweight forecasting, bounded thresholds.
• Abundant ground compute, retrospective analysis: GCN/TCN ensembles for deep pattern discovery.
• Labelled anomaly history available: supervised classifiers layered on top of unsupervised screening.
• Mixed fleet, heterogeneous channels: ensemble scoring that blends thresholding, clustering, and forecasting outputs.

The common theme here: bespoke, modular pipelines always beat a single detector run alone.

How does streaming analytics enable near-real-time SOH detection?

State-of-health telemetry, and the housekeeping data associated with power, thermal, and attitude systems, also sees a disproportionate benefit from streaming architectures, since SOH degradation is often gradual and multivariate. Waiting for a ground-based batch job to process a full pass window often means losing hours, sometimes an entire orbit, before an operator is aware of a developing fault.

Streaming methods address this by updating their internal model incrementally rather than retraining it from scratch. The adaptive streaming k-means ensemble for example operates in three continuous steps:

1. Online / incremental updates: each new telemetry sample only shifts the closest cluster centroid instead of initiating a complete re-fit.
2. Dynamic normalisation: feature scales are recalculated on a rolling basis so that a slow orbital thermal cycle doesn't get misread as a fixed baseline.
3. Feature-distance weighted ensemble scoring: multiple cluster models vote on how far a new point is from expected behaviour, weighted by the contributing features to that distance.

Findings from streaming analytics for satellite state-of-health telemetry confirm that this adaptive k-means ensemble style enables online multivariate SOH estimation at significantly less computational expense than batch deep-learning methods, yet with nearly real-time detection and an interpretable mapping back to features driving each anomaly score.

Streaming is not optional where the fault can propagate before the next downlink. This includes attitude control glitches, pre-thermal runaway, power bus dips, and similar fast-moving issues. It's more of a design decision for slow drift, such as solar panel efficiency degradation where a daily or per-pass batch read is often adequate and less expensive to execute.

Forecasting plus thresholding versus classification and reconstruction: which wins?

Forecasting-and-threshold detectors extrapolate the next value a channel is likely to take and alarm if the next value falls outside of a tolerance band. Classification and reconstruction methods (autoencoders, supervised classifiers) instead learn what “normal” should look like across the entire feature space and alarm if the incoming feature vector diverges from that learned representation. Both will detect anomalies. They will fail differently, and that difference should guide your architecture choice.

Forecasting methods are more sensitive to gradual drift and trend breaks because they're explicitly modelling temporal continuity. They also produce fewer false positives on channels with strong periodicity like thermal cycling because the forecast naturally accounts for the cycle. Their weakness shows up on channels with irregular but legitimate behaviour changes such as payload mode switches where the model hasn't seen enough examples of the new normal.

Reconstruction and classification-based methods are more intuitive for multivariate, cross-channel anomalies, because they are natively built to represent the complete state vector at a time. The benefit comes at the cost of required training data size: autoencoders require a significant nominal-operation history to form a baseline reconstruction model, while supervised classifiers require labelled anomaly examples, which are chronically in short supply in flight archives.

• Event-wise sensitivity: forecasting wins on trend and drift; reconstruction wins on multivariate pattern breaks.
• Labelling burden: forecasting and clustering need none; supervised classifiers need confirmed anomaly labels.
• Compute and inference time: forecasting models tend to be lighter at inference; GCN-based reconstruction models are more expensive per pass.
• False positive profile: predictions are less noisy on periodic channels; reconstructions are less noisy on cross-channel correlation breaks.

For CubeSats and other SWaP-constrained platforms, predicting and dynamic thresholding are generally the pragmatic default. For GEO comms satellites with plentiful power and multi-year operating histories, a hybrid of running lightweight predicting onboard and infrequent GCN reconstruction on the ground during contact windows can cover both regimes. For payload experiments producing entirely new data patterns with no baseline history, unsupervised clustering with initially wide tolerance bands, tightened as the mission builds history, can prevent early false alarms from overwhelming operators.

What does a working anomaly detection pipeline actually look like?

The pipeline is a sequence of small, swappable stages, not a monolithic model. The modularity is what allows you to swap a detector without having to retrain the entire pipeline. It's also a practical application of the “no universal detector” principle that keeps reappearing in the literature on pipeline tailoring for anomaly detection.

Preprocessing:

1. Irregular telemetry can be downsampled, meaning resampled at a more consistent cadence. Choose a resampling cadence that is as fast as the quickest event you need to track.
2. Always deal with missing or corrupted samples explicitly using forward-fill with staleness flag or model-based interpolation. Never zero-fill silently.
3. Remove long-term trend and seasonal components such as orbital thermal cycles and battery ageing curves so the detector scores residual behaviour, not the expected cycle itself.

Feature engineering:

• Rate-of-change and second-derivative features, which catch sudden onset faults that raw values miss.
• Spectral features such as FFT band energy for channels that show periodic signatures of interest, used to detect changes in the frequency of vibration or thermal cycling.
• Cross-channel ratio and correlation features, which reflect faults that manifest as a relationship breaking, rather than the abnormal movement of a single sensor.

Scoring and thresholding:

Normalise scores from individual detectors onto a common scale before fusing them; an ensemble that blindly attempts to average a 0 to 1 clustering score with an unbounded forecasting residual will silently discard one of them. Dynamic thresholding, recalculating the alert threshold from a rolling percentile of recent scores instead of a fixed static value, makes for an adaptive detector that can accommodate slow baseline shifts without a full retrain. Documentation for ADTK on modular detector, transformer, and aggregator design directly informs this approach, and its own pragmatic user notes advocate that runtime control over sensitivity, meaning percent alert, delivers greater operational value day-to-day than frequent model retraining.

Post-processing:

Fuse near-simultaneous alerts from across channels into one diagnostic event instead of overwhelming the operator console. Score every alert with a confidence and top contributing channels before it reaches human eyes.

How do you make anomaly detectors flight-ready on constrained hardware?

Ground-trained models are almost invariably too large to run on the onboard flight computer. Shrinking the model to a size that will fit is often the real bottleneck between an interesting research finding and an operational asset.

Three compression techniques do most of the work:

• Quantisation, the process of reducing the bit-precision of a model's weights from 32-bit floats to 8-bit integers, reduces the memory footprint by a significant factor with very little loss in accuracy for the majority of forecasting architectures.
• Pruning, which cuts weights with low contributions and connections, further reduces a network in size once quantisation is no longer enough.
• Knowledge distillation, or training a small model to reproduce the outputs of a larger model, allows you to deploy a small forecasting model that approximately replicates the decision boundary of a larger GCN or Transformer.

Recent edge-oriented research, deep learning-based anomaly detection on edge devices, has found that architecture optimisation and compression are able to maintain good detection F-scores while slashing RAM requirements to the point where onboard detection can be deployed even on CubeSat-class flight computers. If a compressed neural model is still too large to fit, symbolic distillation, which extracts closed-form rules from a trained model, provides a lower-fidelity fallback that can run on a microcontroller with none of the runtime overhead of a neural network.

Verification has to bridge ground and flight environments deliberately:

• Synthetic anomaly injection (SLOP) into real telemetry streams and verification that the detector fires on known fault signatures prior to launch.
• Downlink-simulated contact windows, running the entire pipeline under the actual latency and downlink bandwidth limitations that the mission will have.
• Regression testing against every previous mission's validated anomaly repository, so that updating a model doesn't stealthily cease to detect a type of fault it was previously finding.

Anyone who's seen this form of edge deployment before for datacentre hardware constraints will recognise the pattern: the constraint isn't the algorithm, it's the silicon it has to run on.

How do you turn an anomaly score into something an operator can act on?

A raw anomaly score indicates to the operator that “something” is wrong. It does not tell them what, or where to look first, and it is in that gap where trust in an automated detection system starts to break down.

Per-channel attribution fixes that. Score decomposition, meaning how to break an ensemble's score into each participating channel's contribution, and SHAP-style explanations both transform an opaque score into a ranked list of “these three sensors are driving this alert.” The open-source telemetry-anomdet toolkit hard-codes exactly this in, providing stacking-ensemble detectors with per-channel attribution hooks baked into the scoring layer rather than bolted on afterwards.

A handful of practices, time and again, distinguish an alarm operators trust and one they learn to ignore:

• Prioritize channels contributing to the issue, rather than simply marking a spike as anomalous, so that the first diagnostic step is clear.
• Assign a confidence score based on ensemble agreement, so that operators can triage a dozen alerts by severity rather than each being of equal importance.
• Show the profile of the closest historical cluster to which the anomalous point is similar; a fault that appears to be a known, previously validated thermal anomaly has a very different sense of urgency than one that does not.
• Recommend the next diagnostic check explicitly, linked to the dominant contributing channel, instead of forcing the operator to draw that inference.
• Treat negative feedback from operators as sensitivity overrides, rather than silent dismissals. If you had a false alarm this week, the natural reaction is to simply close the alarm and move on. Instead, make sure that your system learns from false alarms, such that a closed false alarm this week will adjust the sensitivity for that sensor next week.

That last point is actually more important than it may seem. Flight model retraining is a time-consuming, high-risk activity. Modifying a runtime percentile threshold according to operator input is quick, reversible, and the process by which we ensure that a detection system remains matched to a spacecraft's changing behaviour over a multi-year mission.

Which datasets and toolkits should you prototype with?

Benchmarking on public datasets is the quickest way to validate a new detector before real telemetry has been seen. SMAP and MSL, NASA's Soil Moisture Active Passive and Mars Science Laboratory telemetry sets, remain the most widely used spacecraft anomaly benchmarks in the literature, and OPSSAT-AD provides a more recent, mission-specific anomaly dataset drawn from ESA's OPS-SAT experimental platform. Each has known limitations for cross-mission transfer; a detector tuned on SMAP's channel structure won't automatically generalise to a different spacecraft's sensor layout, so take benchmark scores as a starting point, not a guarantee.

ADTK has a one-stop API for detectors, transformers, and aggregators. It's a good first stop for trying out threshold and rule-based approaches before investing in a heavier-weight model. For ensembling and explainability out-of-the-box, telemetry-anomdet does the stacking and per-channel attribution work directly.

A short reproducible-experiment checklist worth running before any pilot:

• Set your evaluation data split in stone before you ever touch the model; never tune thresholds to test data.
• Report precision, recall, and detection latency separately. A fast detector that has no precision and a slow detector with perfect precision fail operationally in different ways.
• Repeat the same experiment with another dataset, ideally SMAP and OPSSAT-AD, to verify that the result is not a product of one mission's channel structure.

How PODTECH approaches deployable anomaly detection for mission-critical telemetry

PODTECH has completed over 250 projects for critical infrastructure domains, and the take-away that applies directly to spacecraft telemetry analysis is this: a detector that performs well on a benchmark dataset is a different engineering challenge than a detector that makes it through an encounter with real hardware.

PODTECH's path through this kind of pilot includes: historical telemetry analysis first, to zero in on which family of method is going to best fit the channels and constraints the mission has; an edge prototype next, which gets vetted against the real hardware budget, not a development workstation; interfacing with existing monitoring infrastructure, including the PODVIEW monitoring philosophy in place across other critical-infrastructure projects; and finally SLA-backed production support, with 99.9% uptime commitment all the way to operational turnover.

What the research actually tells us to prioritise

Traditional wisdom on this errs on the side of model accuracy and underestimates explainability, and the experiments confirm it. Per-channel attribution is not a "nice to have"; it's the difference between a system operators trust and one they route around.

The second miscalibration is an obsession with the “best” algorithm instead of the pipeline around it. Forecasting vs. reconstruction, LSTM vs. GCN, all of these decisions are far less important than whether your preprocessing accounts for missing data properly or whether your thresholds can adapt without having to do a full retrain cycle. ADTK's documentation makes this argument implicitly through its own design: it's structured as a set of composable stages precisely because there was never going to be a single detector that could give the whole answer.

If there is one thing to prioritise first, let it be runtime sensitivity control. Enabling operators to retune alert thresholds without a model retrain buys more operational trust, more quickly, than any accuracy gain from a heavier architecture.

— Harry

Ready to move from prototype to production telemetry monitoring?

Training a detector to work in a notebook is the easy half. Getting it to run reliably on flight or edge hardware, feed operators explainable diagnostics, and hold up under an SLA is where most in-house efforts stall. PODTECH builds exactly that bridge: custom machine-learning development work that takes a research-stage detection approach and hardens it into a deployable pipeline, tuned to your telemetry channels and your hardware budget rather than a generic benchmark.

Whether you're looking to explore streaming clustering for state-of-health monitoring or you just need BMS/PMS integration work to pipe detector outputs into your existing ops console, the conversation starts the same way. Submit a request for a technical evaluation on PODTECH's machine-learning development services page and come to the initial call armed with your historical telemetry archive.

Sources

• Streaming analytics for enhancing anomaly detection in satellite state-of-health telemetry (IEEE, 2024)
• LSTM-based Anomaly Detection System for Spacecraft Telemetry (NASA software)
• Anomaly Detection Toolkit (ADTK) documentation
• telemetry-anomdet (GitHub)

Recommended

• PODVIEW Datacenter Monitoring Platform
• Top telemetry tools for UK enterprise infrastructure in 2026
• Datacenter Mobilisation: Why Monitoring Teams Must Be Involved from Day One
• Unique Hardware Challenges Supporting DCIM in the Datacenter