Satellitendaten-Kalibrierungsdrift-Erkennung

Das echte Ausmaß des Problems

Satellitensensoren sind keine stabilen Geräte. Sie starten mit einem detaillierten Kalibrierungsprotokoll — im Labor geprüft, am Boden zertifiziert — und werden dann in eine Umgebung geschossen, für die kein Labor vollständig vorbereiten kann: kosmische Strahlung, Temperaturzyklen von –60 °C bis +80 °C bei jedem Erdorbit, Ausgasungseffekte von Bauteilen im Vakuum. Was am Boden stabil war, beginnt im Orbit zu driften.

Die Mechanismen sind physikalisch gut verstanden. Doch ihr kumulativer Effekt auf Datenprodukte ist schwer vorherzusagen — und noch schwerer zu erkennen, wenn er schleichend einsetzt:

• Radiation-induced Charge Transfer Inefficiency (CTI) in CCD-Arrays: Hochenergetische Protonen aus dem Van-Allen-Gürtel und Solar-Particle-Events erzeugen Kristallgitterfehler im CCD-Silizium, sogenannte Ladungsfallen (engl. charge traps). Diese Fallen verzögern die Ladungsübertragung während des Ausleseprozesses und führen zu Signalverlust in Form von Auslesefahnen hinter hellen Pixeln — und zu einem systematischen Unterschätzen der gemessenen Strahldichte. Die Effekte kumulieren sich über die Missionslaufzeit.

• Thermische Degradation optischer Komponenten: Spiegeloberflächen und Beschichtungen verändern ihre Reflektanzcharakteristik unter UV-Bestrahlung. Bei optischen Sensoren zeigt sich die Degradation typischerweise zuerst in den kurzwelligen Bändern (blau, UV) und schreitet zu längeren Wellenlängen fort.

• Diffuser-Degradation bei sonnenkalibrierenden Systemen: Viele Satelliten tragen onboard Solar-Diffuser mit, die regelmäßig für Absolutkalibrierung angefahren werden. Die Diffuser-Oberfläche selbst degradiert unter UV-Exposition — was zu einem systematischen Fehler in der onboard-Referenz führt, wenn dieser Effekt nicht eigenständig modelliert wird.

• Orbital Drift und seine indirekten Auswirkungen: Der Orbit eines Satelliten verändert sich über Zeit durch atmosphärischen Drag im niedrigen Erdorbit (LEO), Gravitationsanomalien und begrenzte Treibstoffreserven. Das MODIS-Terra-Instrument des NASA-Earth-Observing-Systems hat ab 2023 eine bekannte Kalibrierungskrise erlebt: Die Plattform driftete von ihrer Nominal-Orbitzeit von 10:30 Lokalzeit ab, was die Sonneneinstrahlung auf den Solar-Diffuser veränderte und die onboard-Kalibrierungsreferenz kompromittierte. NASA veröffentlichte im März 2024 eine Datendegradations-Notiz für alle MODIS-Ocean-Color-Produkte seit Anfang 2023 — ein negativer Bias in Chlorophyll-a-Retrievals war entstanden, der monatelang unbemerkt blieb.

Das NASA-Beispiel zeigt das strukturelle Risiko: Wenn die onboard-Kalibrierungsinfrastruktur selbst driftet, merken Standard-Qualitätschecks oft nichts — weil sie sich auf dieselbe korrumpierte Referenz stützen.

Was auf dem Spiel steht: Erdbeobachtungsdaten sind häufig Eingangsgröße für automatisierte Downstream-Systeme — Ernte-Frühwarnsysteme, Waldbrandrisiko-Indices, Küstenerosions-Monitoring, CO₂-Bilanzierung nach IPCC-Methodik. Ein Kalibrierungsfehler von 2 % in einem Vegetationsindex klingt klein. Für ein Monitoring-System, das auf Anomalien von ±1,5 % kalibriert ist, ist er eine Katastrophe.

Absolute vs. relative Kalibrierungsdrift

Bevor ein Machine Learning-System Drift erkennen kann, muss klar sein: Welche Art von Drift soll erkannt werden? Der Unterschied ist fundamental für die Systemarchitektur.

Absolute Kalibrierungsdrift bezeichnet die Abweichung zwischen dem gemessenen Sensor-Output und der physikalisch wahren Strahldichte an der Satellitenapertur (Top-of-Atmosphere Reflectance, TOA-R). Absolute Drift zu messen erfordert externe Referenzen: entweder Feldeinsätze mit radiometrisch kalibrierten Bodenmessgeräten, oder den Vergleich mit Pseudo-Invariant Calibration Sites (PICS) — geografischen Regionen mit langzeitstabilen, homogenen Reflektanzeigenschaften (s. nächster Abschnitt).

Relative Kalibrierungsdrift beschreibt die Veränderung des Sensors relativ zu seinem eigenen historischen Baseline-Verhalten. Ein Sensor kann relativ zu sich selbst stabil erscheinen — und trotzdem absolut falsch kalibriert sein, wenn die Baseline selbst falsch war. Umgekehrt kann relative Drift früher detektiert werden als absolute Drift, weil sie keinen externen Ground Truth benötigt.

In der Praxis werden beide Ansätze kombiniert:

• Kurzfristige Überwachung (wöchentlich) über relative Drift — Abweichung vom gleitenden historischen Mittelwert des Sensors selbst
• Langfristige Validierung (monatlich, quartalsweise) über PICS-basierte absolute Kalibrierung

KI-Systeme zur Drifterkennung sollten für beide Zeitskalen ausgelegt sein — mit unterschiedlichen Schwellwerten und unterschiedlichen Eskalationspfaden.

Was das KI-System konkret macht

Das System überwacht kontinuierlich mehrere Datenströme und sucht nach konsistenten Mustern, die auf Instrumentendrift hinweisen:

PICS-Kreuzvergleich: Über jede Überflugsequenz von Pseudo-Invariant Calibration Sites werden die gemessenen TOA-Reflektanzwerte mit dem historischen Erwartungswert für diesen Standort, diese Geometrie und diese atmosphärischen Bedingungen verglichen. Das ML-Modell lernt die saisonalen und geometrieabhängigen Variationen jedes PICS-Standorts und kann damit kleine systematische Abweichungen vom erwarteten Verlauf isolieren — auch wenn sie sich innerhalb der natürlichen Variabilität des Standorts bewegen. Typische PICS-Standorte für optische Sensoren: Libya 4, Algeria 3, Algeria 5, Mauritania 1 und 2, Railroad Valley Playa (Nevada).

Kreuzkalibierung gegen Referenzsatelliten: Wenn zwei Satelliten das gleiche Zielgebiet innerhalb kurzer Zeit überflogen, sollten ihre korrigierten Reflektanzwerte übereinstimmen — innerhalb der bekannten instrumentellen Unsicherheiten. Das System vergleicht automatisch koinzidente Überflüge von Sentinel-2 mit Landsat-9, oder von einem kommerziellen Sensor mit dem ESA-Referenzinstrument. Systematische Abweichungen zwischen den Sensoren, die sich über mehrere Standorte hinweg reproduzieren, sind ein zuverlässiges Signal für Drift im zu überwachenden Instrument.

Onboard-Kalibrierungsparameter-Trend-Analyse: Moderne Satelliten berichten onboard-Kalibrierungsparameter (Spiegel-Reflektanzen, Diffuser-Degradations-Koeffizienten, Detektoren-Offsets) in telemetrischen Datenstreams. Das KI-System analysiert diese Zeitreihen auf Anomalien: plötzliche Sprünge nach Orbital-Events (Solar-Particle-Events, Eklipsen), oder monotone Trends, die auf physikalische Degradation hinweisen.

Das System erzeugt automatisiert eine Drift-Scorecard pro Spektralband und Sensor, mit Trendlinie, statistischem Signifikanzniveau und Eskalationsempfehlung: “kein Handlungsbedarf”, “beobachten”, oder “Kalibrierungsparameter-Update erforderlich”.

Mit vs. ohne KI — ein ehrlicher Vergleich

Die Zahlen aus der Vergleichszeile “Zeit bis zur Drifterkennung” basieren auf dokumentierten Fällen wie dem MODIS-Terra-Degradationsfall (NASA Earthdata Forum, März 2024) und Erfahrungswerten aus USGS Landsat-Reprocessing-Dokumentationen; die KI-Seite ist ein Zielwert aus Pilotprojekten mit PICS-basiertem automatisierten Monitoring.

Einschätzung auf einen Blick

Zeitersparnis — hoch (4/5) Das manuelle Monitoring von Kalibrierungsparametern über mehrere Satelliten und Spektralbänder bindet erhebliche Spezialistenkapazität. Eine PICS-Auswertung für einen einzelnen Sensor über 12 Spektralbänder und 4 Referenzstandorte dauert manuell mehrere Stunden pro Zyklus — wöchentlich oder bei jedem Satelliten-Überflug. Bei Konstellationen mit 3–10 gleichartigen Satelliten ist das nicht mehr händelbar. Das KI-System erledigt die gleiche Auswertung in Minuten. Der echte Wert liegt aber nicht nur in der Zeiteinsparung: Automatisierung ermöglicht eine Abdeckung, die manuell schlicht nicht möglich wäre — jeder Überflug, jedes Band, täglich.

Kosteneinsparung — sehr hoch (5/5) Das ist der stärkste Kostenhebel in diesem Anwendungsfeld. Ein vollständiges Reprocessing eines Jahres Satellitendaten kostet je nach Datenmenge und Prozessorkomplexität schnell 200.000–1.000.000 Euro in Rechenkapazität, Personalaufwand und Qualitätssicherung — ohne die Downstream-Schäden bei Kunden zu berücksichtigen. Zwei Wochen frühere Erkennung kann den Reprocessing-Scope von 18 Monaten auf 2 Monate reduzieren: Faktor 9 im Rechenvolumen. Zusätzlich verringern sich Kosten für SLA-Kompensationen und Kundenkommunikation erheblich. Kein anderer Anwendungsfall in dieser Branchenübersicht hat ein vergleichbar direktes Kosten-Nutzen-Verhältnis.

Schnelle Umsetzung — niedrig (2/5) Das ist kein Tool, das man in vier Wochen einrichtet. Du brauchst: Zugang zu Level-1-Rohdaten des Satelliten (nicht immer trivial), historische Überflugdaten über PICS-Standorte (mindestens 6–12 Monate Baseline), ein Datenmodell für atmosphärische Korrekturen (weil nicht alle Variabilität Drift ist — ein Teil ist Atmosphäre), und ein Team, das die physikalische Bedeutung der ML-Ausgaben interpretieren kann. Das ML-Modell muss außerdem für jeden Sensortyp separat trainiert werden — Sentinel-2 MSI und ein kommerzieller hyperspektraler Sensor teilen keine Modellparameter. Realistisch sind 6–9 Monate bis zu einem produktiven Monitoring-System, das dem Kalibrierungsteam echten Nutzen liefert.

ROI-Sicherheit — hoch (4/5) Der ROI ist für diesen Use Case ungewöhnlich direkt messbar: Wie viele Drift-Ereignisse wurden erkannt, wie früh, wie viel Reprocessing-Volumen wurde damit eingespart? Diese Zahlen sind in der Satellitenoperations-Dokumentation nachvollziehbar und fließen in das Qualitätsberichtswesen ein. Was weniger gut messbar bleibt: der Wert der verhinderten Reputationsschäden bei Kunden, die fehlerhafte Daten nie erhalten haben. Das ist real, aber nicht bilanzierbar. ROI-Sicherheit dennoch hoch — weil der harte Teil (Rechenkosten des Reprocessings) exakt kalkulierbar ist.

Skalierbarkeit — hoch (4/5) Ein trainiertes Monitoring-Modell für einen Sensortyp lässt sich gut auf weitere Satelliten des gleichen Designs übertragen — in einer Konstellation mit mehreren identischen Satelliten ist die Übertragung fast trivial. Zwischen verschiedenen Sensortypen (z.B. vom Multispektral-Sensor auf einen SAR-Radar oder Infrarotsensor) ist eine vollständige Neuentwicklung nötig. Die Infrastruktur (Daten-Ingestion, Alerting-Pipeline, Grafana-Dashboards) lässt sich dagegen vollständig wiederverwenden. Fazit: Konstellations-Skalierung ist einfach, Sensor-Typ-Skalierung ist aufwändig.

Richtwerte — stark abhängig von Sensortyp, Datenlage und vorhandener Kalibrierungsinfrastruktur.

Pseudo-Invariant Calibration Sites: Was das bedeutet

PICS sind der Schlüsselbegriff in jedem Satelliten-Kalibrierungsprogramm und verdienen eine eigene Erklärung.

Eine ideale Kalibrierungsreferenz wäre ein Ort auf der Erde, der immer exakt gleich aussieht — keine saisonalen Veränderungen, keine Wolken, homogene Oberfläche, keine menschliche Aktivität. Der nächste Näherungswert: die großen Sahara-Sandwüsten. Wüstensand mit stabiler Mineralzusammensetzung reflektiert Sonnenlicht in einem vorhersagbaren Muster — spektral charakteristisch, zeitlich stabil auf der Jahrzehntskala.

Das Committee on Earth Observation Satellites (CEOS) hat sechs Standorte als Hauptreferenzen für Sentinel und andere optische Sensoren zertifiziert:

• Libya 4 (Libyen, 28,6°N / 23,4°E): Der am häufigsten genutzte PICS-Standort. Helle Sanddünen, sehr geringer Niederschlag, hochgradig homogen auf 100-km-Skala.
• Algeria 3 und Algeria 5 (Algerisches Hochplateau)
• Mauritania 1 und Mauritania 2 (westliche Sahara)
• Railroad Valley Playa (Nevada, USA): Trockener Salzsee, genutzt für Absolute-Kalibrierungsmessungen mit Bodenmessstationen.

Das ML-Modell muss bei jedem PICS-Überflug die gemessene Reflektanz mit dem erwarteten Wert vergleichen — korrigiert um:

• Sonne-Satelliten-Geometrie (Sonnenzenitwinkel, Betrachtungswinkel variieren von Überflug zu Überflug)
• Atmosphärische Bedingungen (Aerosolbelastung über der Sahara variiert — Sahara-Staubereignisse erhöhen die Aerosoloptische Dicke erheblich)
• Saisonale Variabilität des Standorts selbst (PICS sind pseudo-invariant, nicht perfekt-invariant)

Erst nach dieser Korrektur ist das Residuum zwischen Messung und Erwartung ein valides Signal für Sensorveränderung. Das ist die eigentliche Herausforderung für das ML-System: den Sensoranteil aus einem Signal herauszulösen, das von Atmosphäre und Geometrie dominiert wird.

Konkrete Werkzeuge — was wann passt

DIMITRI — die ESA-Referenzplattform Die Database for Imaging Multi-spectral Instruments and Tools for Radiometric Intercomparison ist das Standardwerkzeug der ESA für Copernicus-Sensormonitoring. Sie verwaltet Überflugdaten über PICS-Standorte, berechnet Kalibrierungstrends und ermöglicht Kreuzkalibierungsvergleiche zwischen Sentinel-2 MSI, Sentinel-3, MODIS und Landsat. Zugang auf Anfrage, kostenlos für qualifizierte Forschungs- und Behördenteams. Vorteil: Ergebnisse sind in ESA- und EUMETSAT-Berichten zitierfähig und kompatibel mit dem Copernicus-Kalibrierungsprotokoll. Einschränkung: Nicht für automatisiertes Echtzeit-Monitoring ausgelegt — eher für periodische Berichte und manuelle Auswertungen.

ACOLITE — offene Python-Pipeline Open-Source-Tool des Royal Belgian Institute of Natural Sciences für atmosphärische Korrektur und Batch-Verarbeitung optischer Satellitensensoren. Unterstützt Landsat 5–9, Sentinel-2/3, PlanetScope, Pléiades und weitere. Kann als Basis für einen benutzerdefinierten Kalibrierungsmonitoring-Workflow dienen: Batch-Verarbeitung historischer PICS-Überflüge, Extraktion von Band-Reflektanzwerten, Übergabe an ein eigenes Anomalieerkennungsmodell. Vorteil: frei anpassbar, aktiv gepflegt, keine Zugangsschranke. Nachteil: erfordert Python-Kenntnisse und Domänenwissen für sinnvolle Konfiguration.

Grafana + InfluxDB — Monitoring-Infrastruktur Für die operative Seite des Monitorings — die Visualisierung von Kalibrierungsparameter-Zeitreihen, Alerting-Regeln bei Schwellwertüberschreitung, und Team-Dashboards — ist die Kombination aus Grafana (Visualisierung) und InfluxDB (Zeitreihendatenbank) eine erprobte Open-Source-Lösung. Kalibrierungsparameter werden nach jeder Auswertung in InfluxDB geschrieben; Grafana zeigt Trends pro Band und Sensor, mit farbcodierten Ampeln. Alerting-Regeln senden automatisch E-Mail oder Slack-Nachricht an das Kalibrierungsteam, wenn der Trend eine definierte Abweichungsschwelle überschreitet. Beide Tools sind open-source und EU-hostingfähig.

MLflow — Modellversionierung und Experiment-Tracking Kalibrierungsmodelle müssen versioniert werden: Jede Anpassung der Modellparameter sollte nachvollziehbar sein, damit rückwirkend rekonstruiert werden kann, auf welcher Basis ein Kalibrierungsalarm ausgelöst wurde. MLflow als Open-Source-MLOps-Plattform übernimmt Experiment-Tracking, Modell-Registry und Deployment. Besonders wichtig: Wenn ein Kalibrierungsparameter-Update retroaktiv auf historische Daten angewendet wird, muss dokumentiert sein, welche Modellversion welche Drift erkannt hat — für den Qualitätsbericht und für die Rückverfolgung bei Kundenreklamationen.

scikit-learn + PyTorch — die Modell-Bibliotheken Das eigentliche ML für Zeitreihen-Anomalieerkennung auf Kalibrierungsparametern. Für die meisten Anwendungsfälle sind klassische statistische Methoden ausreichend und erklärbar: CUSUM-Tests (Cumulative Sum) für Trendbrüche, oder Isolation Forests für multivariate Anomalien über mehrere Bänder gleichzeitig. Für komplexere Szenarien — z.B. wenn atmosphärische Einflüsse nicht vollständig korrigiert werden können und das Modell diese implizit lernen soll — kommen LSTM-Netze aus PyTorch in Frage. Wichtig: Das einfachere, erklärbarere Modell hat im Kalibrierungskontext Vorrang. Ein Kalibrierungsspezialist muss jeden Alarm verstehen und vor dem Qualitätsteam verteidigen können.

Wann welcher Ansatz:

• ESA-Copernicus-Missionen mit Behördencharakter → DIMITRI als Referenz, ergänzt durch eigene Automatisierung
• Forschungsprojekte und kommerzielle Missionen ohne Behördenbindung → ACOLITE + eigene ML-Pipeline
• Operative Überwachung mit Team-Dashboards → Grafana + InfluxDB
• Modell-Versionierung und Audit-Trail → MLflow
• ML-Modellbau → scikit-learn (Einstieg), PyTorch (komplexe Modelle)

Datenschutz und Datenhaltung

Kalibrierungsdaten sind in aller Regel keine personenbezogenen Daten im Sinne der DSGVO — es geht um Sensor-Telemetrie, Reflektanzwerte und Orbit-Parameter, nicht um Informationen über natürliche Personen. Dennoch gibt es datenschutzrelevante Überlegungen:

Telemetriedaten aus militärischen oder dualen Missionen: Kalibrierungsparameter und Orbit-Telemetrie militärisch genutzter Satelliten können als exportkontrolliert oder geheimhaltungswürdig eingestuft sein. KI-Systeme, die Zugang zu diesen Daten benötigen, müssen entsprechend klassifiziert und infrastrukturell isoliert sein — kein Public Cloud Processing für klassifizierte Satellitensysteme.

Proprietäre Sensordaten kommerzieller Anbieter: Kalibrierungsparameter eines kommerziellen Erdbeobachtungssatelliten können als Geschäftsgeheimnis eingestuft sein. Drittanbieter, die Kalibrierungsmonitoring als Service anbieten, müssen entsprechende Vertraulichkeitsvereinbarungen schließen.

Infrastruktur-Empfehlung: Für Raumfahrtagenturen und Behörden gilt EU-Datenhaltung als Minimum. Die empfohlenen Tools (DIMITRI, ACOLITE, MLflow, Grafana) sind alle self-hostingfähig in einer EU- oder deutschen Cloud-Umgebung oder on-premise. Für klassifizierte Missionen ist air-gapped on-premise zwingend. Für kommerzielle Operatoren ohne Klassifizierungsanforderungen bietet Azure Machine Learning EU-Datenhaltung in der Frankfurter Azure-Region.

Keine AVV-Pflicht für reine Sensor-Telemetrie ohne Personenbezug. Bei Earth-Observation-Produkten, die als Grundlage für personenbezogene Entscheidungen genutzt werden (z.B. GPS-Genauigkeit in Navigationsanwendungen), kann indirekt DSGVO-Relevanz entstehen — zu prüfen mit dem Datenschutzbeauftragten.

Was es kostet — realistisch gerechnet

Einmalige Entwicklungskosten

Ein produktives Kalibrierungsmonitoring-System ist ein aufwändiges Datenprojekt, das spezifisches Domänenwissen voraussetzt:

• Aufbau der Dateninfrastruktur (Ingest, Storage, PICS-Überflugmanagement): 3–5 Monate Entwicklungsaufwand
• ML-Modell-Entwicklung und Training (pro Sensortyp): 2–4 Monate
• Validierung gegen bekannte Driftereignisse und historische Kalibrierungsberichte: 1–2 Monate
• Integration in operative Monitoring-Infrastruktur: 1–2 Monate

Realistischer Personalaufwand: 1–2 Vollzeit-Entwickler mit Fernerkundungshintergrund plus Kalibrierungsspezialist, über 9–12 Monate. Bei externem Beauftragen: 150.000–350.000 Euro für ein vollständiges System. In-house mit vorhandener Expertise: 100.000–200.000 Euro an Personalkosten.

Laufende Infrastrukturkosten

• Self-hosted Grafana + InfluxDB: 200–800 Euro/Monat Server
• ACOLITE Batch-Processing (Cloud): 300–1.500 Euro/Monat je nach Szenenvolumen
• MLflow (self-hosted): inkludiert in Server-Kosten
• DIMITRI: kostenlos

Gesamte Laufzeitkosten bei mittelgroßem Programm (eine Konstellation, 3–5 Satelliten): ca. 1.500–3.000 Euro/Monat.

Was du dagegenrechnen kannst

Ein vollständiges Reprocessing eines Jahres Sentinel-2-ähnlicher Daten über einem typischen Beobachtungsgebiet (Europa, Nord-Afrika) kostet in Cloud-Computing-Kosten allein 50.000–150.000 Euro — ohne Personalkosten für Validierung, Kundenbenachrichtigung und SLA-Verhandlungen. Bei einer mittelgroßen Mission mit Kunden, die auf Datenkonsistenz angewiesen sind (Klimamonitoring, Landwirtschaft, Versicherungen), entstehen bei einem unentdeckten Drift-Ereignis schnell Gesamtkosten von 300.000–1.000.000 Euro für das Nacharbeiten.

Wenn KI-Monitoring ein einziges großes Reprocessing verhindert, amortisiert sich die Entwicklungsinvestition. Das ist keine theoretische Kalkulation — es ist der dokumentierte Treiber für ESA’s laufende Investitionen in das DIMITRI-System und NASA’s Kalibrierungsprogramme.

Vier typische Einstiegsfehler

1. PICS-Variabilität mit Sensor-Drift verwechseln. Pseudo-invariante Kalibrierungsstellen sind nicht perfekt invariant. Saharastaub-Ereignisse (dust storms über Libya 4) erhöhen die Aerosoloptische Dicke temporär um das Fünf- bis Zehnfache des Normalwerts — und lassen Sensor-Reflektanzwerte scheinbar absinken. Wer atmosphärische Korrekturen nicht sorgfältig in sein Modell einbaut, bekommt False Positives bei jedem größeren Staubereignis. Das zerstört das Vertrauen des Kalibrierungsteams in das System — und das System wird abgestellt, bevor es echten Drift erkennt. Die Lösung: Atmosphärische Nebendaten (MODIS/MAIAC AOD, CAMS-Prognosen) als Feature ins Modell integrieren.

2. Nur einen Referenzstandort überwachen. Libya 4 ist der prominenteste PICS-Standort — und gleichzeitig einer der am stärksten von Staubereignissen betroffenen. Ein System, das nur auf Libya 4 basiert, hat bei jedem größeren Staubereignis blinde Flecken. Minimale Anforderung: Mindestens 3 unabhängige PICS-Standorte aus verschiedenen geografischen Regionen. Ein echter Sensor-Drift zeigt sich konsistent über alle Standorte gleichzeitig — ein atmosphärisches Ereignis betrifft maximal einen oder zwei Standorte.

3. Das Modell einmalig trainieren und nicht nachführen. Satellitensensoren driften nicht linear. Nach einem Solar-Particle-Event kann die Drift-Rate sprunghaft zunehmen. Nach einem Manöver kann sich die thermische Umgebung des Sensors verändern. Ein Modell, das auf der ersten Missionsjahreshälfte trainiert wurde, passt möglicherweise nicht mehr zum Sensor in Jahr drei. Retraining-Zyklen müssen geplant sein: mindestens nach jedem signifikanten orbitalen Ereignis, und routinemäßig jährlich.

4. Drift-Alarm ohne Eskalationsprozess. Ein KI-System, das Alarmierung ausgibt, ohne dass das Team einen definierten Eskalationsprozess hat, erzeugt Chaos. Wer entscheidet, ob ein Drift-Alarm valide ist? Wer autorisiert ein Kalibrierungsparameter-Update? Wer kommuniziert mit Datenkunden? Diese Fragen müssen vor dem ersten produktiven Alarm beantwortet sein — in einem Betriebshandbuch mit klaren Verantwortlichkeiten und Eskalationspfaden. Ohne das landet der Alarm in der Inbox der Kalibrierungsabteilung und niemand fühlt sich zuständig.

Was mit der Einführung wirklich passiert — und was nicht

Kalibrierungsteams bei Raumfahrtagenturen und kommerziellen Operatoren haben fast immer dieselbe erste Reaktion auf ein KI-Monitoring-System: skeptische Neugier, gefolgt von einem Testprojekt mit bekannten historischen Driftereignissen, gefolgt von ernsthafter Auseinandersetzung — wenn das System das bekannte Ereignis findet.

Das ist der richtige Ansatz. Kalibrierungsspezialistinnen und -spezialisten sind zu Recht konservativ: Sie tragen Verantwortung für die Gültigkeit von Datenprodukten, auf die Forschende, Regierungen und Unternehmen ihre Arbeit aufbauen. Ein False-Positive-Alarm, der zu einem unnötigen Kalibrierungsparameter-Update führt, kann selbst eine neue Instabilität erzeugen. Das Vertrauen in das System muss durch historische Validierung verdient werden — nicht durch Marketing-Claims.

Was den Rollout konkret beschleunigt:

• Retrospektive Validierung als erstes Deliverable: Bevor das System live geht, läuft es rückwirkend über historische Daten und muss dokumentierte Driftereignisse reproduzieren. Das schafft Vertrauen.
• Kalibrierungsteam einbinden: Das System soll die Experten unterstützen, nicht ersetzen. Die Kalibrierungsspezialistinnen und -spezialisten definieren die Alarm-Schwellwerte, validieren die atmosphärischen Korrekturparameter, und entscheiden über die Reaktion auf Alarme. KI liefert den Hinweis — die Fachkenntnis bleibt beim Team.
• Transparente Modell-Erklärung: Jeder Alarm sollte erklären, welche Signale ihn ausgelöst haben — welche PICS-Standorte, welche Spektralbänder, welcher statistische Signifikanzwert. Ein Black-Box-Alarm wird nicht akzeptiert.

Was nicht passiert: Ein vollautomatisches System, das ohne Zutun des Kalibrierungsteams Kalibrierungsparameter anpasst. Das ist aus gutem Grund nicht das Ziel. Der Schritt vom “Alarm auslösen” zum “Kalibrierungsparameter autonom anpassen” ist ein enormer und in den meisten Qualitätssystemen nicht vertretbarer Schritt. Das KI-System ist ein Frühwarnsystem, kein autonomer Stellantrieb.

Datenprodukt-Versionierung bei Retrokalibration

Wenn eine Kalibrierungsdrift erkannt und korrigiert wird, entsteht ein neues Problem: Was passiert mit den historischen Datenprodukten, die mit dem alten (fehlerhaften) Kalibrierungsstand erzeugt wurden?

Die Antwort in professionellen Erdbeobachtungsprogrammen ist Collection-basierte Versionierung: Alle Datenprodukte einer Mission werden in Generationen (Collections) ausgeliefert. Wenn ein Kalibrierungsparameter-Update retroaktiv angewendet wird, entsteht eine neue Collection — z.B. Landsat Collection 2 (USGS, 2020) oder MODIS-Terra R2022.0.1 (NASA, September 2024, retroaktiv ab Juli 2021 angewendet).

Für den Betrieb eines Monitoring-Systems hat das Konsequenzen:

• Downstream-Kunden müssen identifiziert werden, die auf eine bestimmte Collection-Version kalibrierte Algorithmen aufgebaut haben. Eine neue Collection macht deren Baseline-Werte invalide — ein proaktives Change-Management ist erforderlich.
• Algorithmen, die auf relativer Drift statt absoluten Werten basieren, sind robuster gegenüber Collection-Wechseln — ein Argument für relative Kalibrierung im Monitoring-Design.
• Das KI-Monitoring-System selbst braucht eine eigene Versionierungsstrategie: Welches Modell hat welche Drift erkannt? Welche Kalibrierungsparameter waren zum Zeitpunkt T korrekt? MLflow als Modell-Registry ist der natürliche Ort für diese Dokumentation.

Die Versionierungsstrategie sollte Teil des Systemdesigns sein — nicht eine nachträgliche Überlegung, wenn das erste Reprocessing ansteht.

Realistischer Zeitplan mit Risikohinweisen

Häufige Einwände — und was dahintersteckt

„Wir haben schon Qualitätsprüfungen im Prozessor — die würden Drift erkennen.” Standard-Level-1-Prozessoren prüfen auf technische Anomalien: ausgefallene Detektoren, Daten-Overflow, Telemetriefehler. Diese Prüfungen erkennen plötzliche Ausfälle — aber nicht die schleichende Drift über Monate, die die Amplitude über die normalen Qualitäts-Flag-Schwellen nie überschreitet. Das ist genau die Drift, die gefährlich ist: zu klein für Flag-basierte Erkennung, groß genug um Downstream-Produkte zu verzerren.

„Die Variabilität der PICS-Standorte ist zu groß — das Signal ist nicht sauber genug.” Das ist ein berechtigter Einwand, der in der Forschungsliteratur ausführlich diskutiert wird. Die Antwort aus der Praxis: Zuverlässige vicarious calibration über PICS erfordert 45–60 unabhängige Szenen pro Standort für statistisch robuste Ergebnisse (National Academies of Sciences, 2008). Bei modernen Sentinel-2-Revisitzeiten von 5 Tagen bedeutet das 7–8 Monate historische Daten — ein Minimum, das das System vor dem Produktivbetrieb braucht. Wer ein Jahr früher erkennen will als bisher, braucht mindestens ein Jahr Trainingsdaten. Das ist der Grund, warum dieser Use Case in der Zeitplan-Tabelle 9–12 Monate veranschlagt.

„KI kann den Kalibrierungsspezialisten nicht ersetzen.” Richtig — und das ist auch nicht das Ziel. Kalibrierungsmonitoring mit KI ist ein Frühwarnsystem für Experten, kein Autopilot. Das System erkennt Muster in Datenvolumen, die kein Mensch täglich durchsehen kann. Die Entscheidung über Reaktionsmaßnahmen — Kalibrierungsparameter-Update, Reprocessing, Kundenkommunikation — bleibt beim qualifizierten Kalibrierungsteam. Die Frage ist nicht “KI statt Kalibrierungsspezialist”, sondern “wie viele Satelliten kann ein Kalibrierungsspezialist ohne KI-Unterstützung sinnvoll überwachen?” Bei einer Konstellation von acht Satelliten mit je 13 Spektralbändern und vier PICS-Standorten ist die Antwort: deutlich weniger, als das Programm eigentlich braucht.

Woran du merkst, dass das zu dir passt

Positive Indikatoren:

• Du betreibst einen optischen Erdbeobachtungssatelliten oder eine Konstellation im kommerziellen Betrieb
• Dein Team führt heute periodische Kalibrierungsauswertungen manuell durch — quartalsweise oder seltener
• Downstream-Kunden nutzen deine Daten als Eingabe für automatisierte Analyse-Pipelines (Landwirtschaft, Klima, Infrastrukturmonitoring)
• Du hast Level-1-Archivdaten für mindestens 12 Monate und Zugang zu einem oder mehreren PICS-Referenzstandorten
• Dein Qualitätssystem enthält SLA-Verpflichtungen zur Datenkonsistenz gegenüber Kunden

Drei harte Ausschlusskriterien:

1. Zu wenige Satelliten ohne Kreuzkalibierungspartner. Ein einziger Satellit ohne verfügbaren Kreuzkalibierungspartner (ein gleichzeitig fliegender Referenzsatellit mit überlappenden Spektralbändern) kann nur über PICS kalibriert werden — und PICS allein hat die oben beschriebene Variabilitäts-Limitation. Ohne Kreuzkalibierungsmöglichkeit ist die Detektionsgenauigkeit des KI-Systems signifikant geringer. Wer sich in dieser Situation befindet, sollte zunächst in Kreuzkalibierungspartnerschaften (z.B. über CEOS WGCV-Vereinbarungen) investieren, bevor ein KI-Monitoring-System sinnvoll ist.

2. Keine stabile, dokumentierte Kalibrierungsinfrastruktur als Baseline. Ein KI-System für Drift-Erkennung setzt eine Baseline voraus — einen Zustand, gegenüber dem Abweichungen gemessen werden. Wenn die initiale On-Orbit-Kalibrierung nicht sorgfältig dokumentiert ist, wenn keine regelmäßigen PICS-Überflüge historisch vorhanden sind, und wenn keine atmosphärischen Korrekturen für historische Szenen existieren, gibt es keine Baseline. Das KI-System würde dann Drift relativ zu einem unbekannten Startpunkt messen — und hat keinen Mehrwert gegenüber einer einfachen Trendlinie.

3. Kein qualifiziertes Kalibrierungsteam zur Alarm-Interpretation. Kalibrierungsalarme sind keine IT-Tickets, die ohne Domänenwissen bearbeitet werden können. Ein Alarm bedeutet: Ist das atmosphärisch bedingt? Ist es auf ein Solar-Particle-Event zurückzuführen? Auf tatsächliche Sensor-Degradation? Welche Bänder? Wie schnell muss reagiert werden? Wer kein Kalibrierungsteam hat, das diese Fragen beantworten kann, sollte keinen automatisierten Alarm-Kanal öffnen — das erzeugt Handlungsdruck ohne Handlungskompetenz.

Das kannst du heute noch tun

Wenn dein Team bereits Kalibrierungsauswertungen über PICS-Standorte durchführt: Exportiere die Zeitreihendaten der Reflektanzwerte über Libya 4 oder Algeria 3 für die letzten 12 Monate, für alle Spektralbänder deines Sensors. Öffne eine Python-Umgebung oder Julius AI für Zeitreihenanalyse.

Dein erster Schritt ist kein KI-Modell — es ist eine visuelle Inspektion: Plotte alle Bänder übereinander. Sind die Trends parallel, oder driftet ein Band relativ zu den anderen? Ein Band, das sich von den anderen entkoppelt, ist ein starkes Signal für bandbezogene Degradation. Das kannst du heute Nachmittag herausfinden, ohne ein einziges ML-Modell zu trainieren.

Für die systematische Analyse kannst du den folgenden Prompt verwenden:

Quellen & Methodik

• MODIS Terra Calibration Degradation Notice: NASA Earthdata Forum, Beitrag vom 22. März 2024. Dokumentiert Kalibrierungsdegradation in MODIS-Ocean-Color-Produkten seit 2023 aufgrund von Orbit-Drift und kompromittierter Onboard-Kalibrierungsreferenz. URL: forum.earthdata.nasa.gov/viewtopic.php?t=5333
• USGS Landsat Collection 2: USGS Landsat Missions, Dezember 2020. Zweites großes Reprocessing des gesamten Landsat-Archivs inkl. Kalibrierungsverbesserungen. Reprocessing-Dauer: 6–8 Wochen für das gesamte Archiv (Landsat 1–9). URL: usgs.gov/landsat-missions/landsat-collection-2
• CEOS PICS und Referenzstandorte: Mehrere MDPI Remote Sensing-Publikationen (2019–2021) zum Einsatz von Pseudo-Invariant Calibration Sites (Libya 4, Algeria 3/5, Mauritania 1/2) für Satellitensensor-Kalibrierung. CEOS Working Group on Calibration and Validation (WGCV) IVOS-endorsed sites.
• DIMITRI-Tool: ESA / ARGANS / Magellium. Aktive ESA-Infrastruktur für radiometrischen Intervergleich. Zugang über dimitri.argans.co.uk (Stand April 2026).
• ACOLITE: Quinten Vanhellemont et al., Royal Belgian Institute of Natural Sciences (RBINS). Open-Source-Python-Tool für atmosphärische Korrektur und Satellitendatenverarbeitung. github.com/acolite/acolite (Stand April 2026).
• Vicarious Calibration Uncertainty: National Academies of Sciences (2008): „Issues in the Integration of Research and Operational Satellite Systems for Climate Research”. Dokumentiert, dass zuverlässige vicarious Calibration 45–60 unabhängige Szenen pro Standort erfordert.
• Physik der CCD-Strahlendegradat: Massey et al. (2014), Oxford MNRAS: „Impact of CCD Radiation Damage on Gaia Astrometry” — Analyse von Charge Transfer Inefficiency (CTI) als Folge von Protoneninteraktion mit CCD-Siliziumgitter.
• Entwicklungskosten und Laufzeitkosten: Erfahrungswerte aus Kalibrierungsmonitoring-Projekten im ESA-Ökosystem und bei kommerziellen Erdbeobachtungsanbietern (Stand April 2026). Azure ML Pricing: azure.microsoft.com/de-de/products/machine-learning/ — 100–500 EUR/Monat für kleine Trainingsworkloads (Pay-as-you-go, EU-Region, Stand April 2026).

Dein Team überwacht einen optischen Erdbeobachtungssatelliten und ihr wollt wissen, ob ein KI-basiertes Kalibrierungsmonitoring für eure Konstellation sinnvoll ist — und was der realistische erste Schritt wäre? Meld dich für ein kurzes Gespräch.