Hvad gør AI på en satellit anderledes?
Jordbaseret AI starter normalt efter målinger er blevet overført til et datacenter. Onboard AI udfører en del af denne fortolkning inde i rumfartøjet. Dette kan hjælpe, når nyttelasten producerer flere data, end det tilgængelige downlink kan bære, eller når det er nyttigt at prioritere en observation før den næste jordkontakt.
Det fjerner ikke behovet for jordbearbejdning. Træning, uafhængig evaluering, missionsplanlægning og dybere analyser forbliver normalt på stedet. Onboard-modellen er en del af en større måle- og beslutningspipeline.
En praktisk behandlingspipeline ombord
- Indhent og tid dataene. Tag billeder eller målinger med tidsstempler, instrumentindstillinger og rumfartøjskontekst.
- Forbehandle konsekvent. Anvend den kalibrering, ændring af størrelse, normalisering eller fliselægning, der forventes af modellen. Forskelle fra træningspipeline kan ændre resultatet.
- Kør inferens. Udfør den installerede model på en passende CPU, FPGA eller accelerator. Mål hele behandlingskæden, ikke kun den neurale netværkskerne.
- Anvend en beslutningspolitik. Konverter modelresultater til en køprioritet, en begivenhedsrecord eller et område af interesse. Inkluder tillidsgrænser og et defineret fallback.
- Opbevar og send. Behold de valgte data med dens metadata, og send dem under det planlagte kommunikationsvindue. Bevar nok revisionsdata til at evaluere beslutninger på stedet.
Eksempel: skyscreening før downlink
En cloud-screeningsmodel kan score billedfliser, så klare observationer får højere downlink-prioritet. Den tekniske beslutning er ikke blot, om en tegl indeholder en sky: tynd sky, sne, lyse tage og usædvanlig belysning kan skabe tvetydige sager. Missionen skal vælge, hvordan usikkerhed skal håndteres, og hvor meget ufiltreret data, der skal opbevares til evaluering.
ESAs Φsat-2 CubeSat giver et rigtigt eksempel på indbygget AI til jordobservation. Dens beskrevne applikationer omfatter skydetektion, billedkomprimering og konvertering af billeder til kort. Dette er et eksempel på en ekstern mission, ikke en Alvexis-flyvningsreference.
Kilde: ESA — Introduktion af Φsat-2
Andre nyttige anvendelsesmønstre
- Prioriter billeder, der indeholder en missionsdefineret miljøbegivenhed til jordgennemgang.
- Identificer ændringer mellem observationer og vedhæft kompakte metadata til de relevante scener.
- Overvåg instrumenttelemetri for usædvanlig adfærd og anmod om yderligere diagnostiske data.
- Komprimer eller vælg data, mens du måler effekten på den downstream videnskabelige eller operationelle opgave.
Strøm, hukommelse og kommunikationsbudgetter kommer først
Vælg en model, der passer til missionen i stedet for at starte med den største tilgængelige model. Behandlingshastighed skal tages i betragtning sammen med hukommelsesbevægelser, billedbuffere, lagerskrivninger og den energi, der bruges pr. observation. Planlægning af konklusioner kun under passende betjeningsvinduer kan have mere betydning end maksimal gennemstrømning.
Et nyttigt downlink-estimat er det tilbageholdte datavolumen divideret med den effektive kommunikationshastighed plus protokol- og planlægningsoverhead. Et nyttigt beregningsestimat måler energi og latens for den fulde pipeline ved hjælp af repræsentative data. Ingen af estimaterne kan erstattes af en accelerators annoncerede spidsoperationer pr. sekund.
Hvordan skal modellen valideres?
Brug separate trænings- og evalueringsdatasæt, herunder vanskelige årstider, belysningsforhold og sensorartefakter. Test det implementerede modelformat og den numeriske præcision på den tilsigtede processor. Mål falske alarmer, mistede hændelser, bevaret datakvalitet, latens og energi under de foreslåede driftstilstande.
AI-output skal passere gennem afgrænset applikationslogik. For rumfartøjskritiske funktioner bør en modelscore ikke omgå den uafhængigt designede kommandovalidering og fejlbeskyttelsesarkitektur. Behold versionerede modelpakker, kendte gode gendannelsesbilleder og en kontrolleret opdateringsproces.
Hvor Alvexis kan bidrage
Alvexis kan omfatte brugerdefineret nyttelastbehandlingselektronik, sensorgrænseflader, indlejret software og prototypeintegration omkring missionens datasti. Den første leverance bør være en aftalt arkitektur og en målbar prototypeplan. Flyvningskvalifikationen forbliver specifik for den valgte hardware, kredsløb og mission.
Satellitkommunikation og datareduktion om bord
Kapacitet til satellitkommunikation, kontaktmuligheder og lagring om bord påvirker, hvilke målinger der bør sendes først. Satcom og edge AI om bord kræver derfor en fælles datapolitik: bevar tilstrækkelige rådata til at vurdere behandlingsbeslutninger, identificér modelversionen, og definér håndteringen af usikre resultater.
Lokal behandling kan reducere den datamængde, der udvælges til downlink, men gevinsten skal afvejes mod strøm-, hukommelses- og temperaturbegrænsninger. Kommunikation mellem satellitter tilføjer endnu et interface og en planlægningsopgave. Missionsspecifik verifikation er stadig nødvendig; en teknisk prototype dokumenterer ikke flyvekvalifikation.