Satelliittikuvien sisäänluvun pipeline puolustukselle: raakakuvasta tilattuun analyysiin

Satelliittikuva-alue ei ole tiedustelua. Se on raakadataa: pakattu rasteri pikseliarvoja koodattuna omistusoikeudelliseen formaattiin, merkittynä koordinaattireferenssijärjestelmällä, liitettynä sensorin telemetriatiedostoon ja käärittynä turvaluokitussäiliöön, joka määrää kuka saa koskea siihen. Tuon raakatoimituksen ja kohteistusanalyytikon työasemalleen vastaanottaman käyttökelpoisen ortorektifioidun kuvan välissä on sisäänluvun pipeline -- sarja automatisoituja käsittelyvaiheita, joita useimmat GEOINT-ohjelmat aliarvioivat, kunnes se rikkoutuu kello 0200 kiireellisellä keräysvaatimuksella. Tämä artikkeli erittelee jokaisen vaiheen puolustuksen satelliittikuvien sisäänluvun pipelinessa: miten kuva-alueen tehtävänanto liittyy satelliittioperaattorien API:hin ja kansallisten teknisten keinojen (NTM) pyyntöjärjestelmiin, mitä esikäsittelypino tekee raakakuvalle ennen kuin se pääsee katalogiin, miksi formaattivalinnoilla on operatiivista merkitystä, miten spatiaaliset katalogit mahdollistavat nopean kuva-alueiden haun miljoonien arkistoitujen kuva-alueiden yli, ja miten reitityslogiikka yhdistää vasta sisäänluetun kuvan hyödyntämistyökaluihin ja analyytikkojonoihin, jotka sitä tarvitsevat.

Satelliittikuvapipeline: laajuus ja operatiiviset vaatimukset

Puolustuksen kuvien sisäänluvun pipeline kattaa kolme toiminnallista aluetta: hankinta (kuva-alueen tuominen satelliitilta tai toimittajalta pipelineen), käsittely (raakakuva-alueen muuntaminen kalibroiduksi, georeferoiduksi, kataloiduksi tuotteeksi) ja hyödyntämisreititys (oikean kuva-alueen toimittaminen oikealle työkalulle tai analyytikolle oikeaan aikaan). Jokaisella alueella on omat latenssi-, läpäisy- ja luotettavuusvaatimuksensa, jotka muovaavat arkkitehtuurivalintoja. Rutiinikeräykselle, joka tukee pitkäsyklistä tiedustelutuotantoa, päästä päähän -latenssi kuva-alueen hankinnasta katalogin saatavuuteen useita tunteja on hyväksyttävä. Aikakriittisille tiedusteluvaatimuksille (TSI) -- taistelutuhon arviointi, joukkojen seuranta tai dynaaminen kohteistus -- saman pipelinen on puristettava tuo latenssi alle 30 minuuttiin, ja joissakin arkkitehtuureissa alle 10:een.

Operatiiviset vaatimukset asettavat rajoitteita, joita kaupalliset kuvapipelinet eivät kohtaa. Turvaluokituksen käsittely tarkoittaa, että eri turvallisuustasoilla olevat kuva-alueet eivät voi jakaa käsittelyinfrastruktuuria ilman akkreditointia, tai ne on käsiteltävä eristetyissä enklaaveissa tiukoilla tasojenvälisillä tiedonsiirtokontrolleilla. Jäljitysketjun kirjaaminen -- tallentaen kuka tilasi keräyksen, mitä käsittelyalgoritmeja sovellettiin, mikä analyytikko vastaanotti tuotteen ja mitä hyödyntämistoimia tehtiin -- on pakollista valmiille tiedustelulle, jolla on oikeudellinen ja operatiivinen vastuuvelvollisuus. Saatavuusvaatimukset aktiivista toimintaa tukeville kuvapipelineille ovat tyypillisesti korkeammat kuin rauhanajan tuotantojärjestelmille, edellyttäen redundantteja käsittelysolmuja, automatisoitua vikasietoa ja heikennetyn tilan toimintasuunnitelmia siltä varalta, että ensisijainen kaupallinen laskeutumisreitti tai pilvikäsittely-ympäristö on käytettävissä.

Pipelinen on myös oltava suunnittelultaan monilähteinen. Puolustuksen sotanäyttämö ei luota yhteen satelliittikonstellaatioon. Kaupalliset toimittajat (Maxar WorldView Legion, Planet SuperDoves, Airbus Pleiades Neo, Satellogic), synteettisen apertuurin tutkan (SAR) toimittajat (Capella Space, ICEYE, Umbra) sekä koalitio- tai NTM-kuvat saapuvat kaikki eri toimitusmekanismien kautta erilaisilla formaattikäytännöillä, metatietoskeemoilla ja lisensointirajoitteilla. Sisäänluvun pipeline abstrahoi nämä erot yhteisen sisäisen skeeman taakse, jotta alavirran käsittely-, katalogi- ja hyödyntämistyökalut toimivat normalisoidulla esityksellä lähteestä riippumatta.

Kuva-alueen tilaaminen ja tehtävänanto: integrointi satelliittioperaattorien API:hin ja NTM-pyyntöjärjestelmiin

Satelliitin tehtävänanto alkaa vaatimuksesta: maantieteellinen kohdealue (AOI), keräysikkuna, resoluutiovaatimus ja tiedusteluprioriteetti. Puolustusorganisaatiossa vaatimukset muotoillaan pysyväisvaatimuksiksi (STANREQ) tai ad hoc -tehtäväkäskyiksi, joita hallitaan vaatimustenseurantajärjestelmässä. Sisäänluvun pipelinen tehtävänantomoduuli lukee aktiiviset vaatimukset ja kääntää ne keräyskäskyiksi, jotka lähetetään jokaiselle asiaankuuluvalle satelliittioperaattorille tai NTM-välittäjälle. Kaupallisten toimittajien osalta tämä tarkoittaa REST-tehtävänanto-API:n kutsumista: AOI-monikulmion, keräysikkunan, tuotetason määrittelyn ja autentikointitunnusten lähettämistä. Maxar SecureWatch API, Planet Orders API ja Airbus Intelligence Access API noudattavat kaikki laajasti samanlaisia malleja -- POST-tilaus, tilan kysely ja kuva-aluepaketin lataus allekirjoitetusta URL:stä, kun keräys on vahvistettu.

NTM-integraatio noudattaa erilaista mallia, jota ohjaavat turvaluokitellut pyyntöprotokollat. Kaupallisen REST-API:n sijaan NTM-pyynnöt kulkevat kontrolloitujen jakelujärjestelmien läpi käyttäen viestiformaatteja kuten STANAG 4559 (NATO-standardi kuvapyynnöille ja -toimituksille) tai Yhdysvaltain IC-kohtaisia protokollia. Sisäänluvun pipelinen NTM-rajapintamoduuli hoitaa autentikoinnin asiaankuuluvaa välitysjärjestelmää vasten, lähettää pyynnöt vaaditussa skeemassa, monitoroi toimitusilmoituksia ja noutaa kuva-aluepaketit valtuutetun siirtoreitin kautta. Keskeinen arkkitehtuuriperiaate on, että NTM- ja kaupallinen tehtävänanto on hoidettava erillisillä rajapintamoduuleilla, joilla on eristetyt tunnusvarastot, vaikka ne syöttäisivät samaan alavirran käsittelyjonoon, koska niiden turvaluokitus-, käsittely- ja jäljitysvaatimukset eroavat.

Tilausten hallinta edellyttää paikallista tilakonetta jäljittämään jokaisen keräyspyynnön elinkaarta: lähetetty, toimittajan kuittaama, kerätty (satelliittiylilento tapahtui), laskettu, toimittajan käsittelemä ja toimitettu pipelinen sisäänlukupäätepisteeseen. Toimittajan puolen käsittelyvirheet, pilvisyys keräyshetkellä ja satelliitin tehtävänantokonfliktit kaikki edellyttävät käsittelylogiikkaa -- uudelleenaikataulutus, eskalaatio korkeamman prioriteetin vaihtoehtoiselle toimittajalle tai vaatimuksen merkitseminen täyttämättömäksi manuaalista tarkastelua varten. Tehtävänantomoduulin tulisi ylläpitää historiallista tietuetta kaikista pyynnöistä ja tuloksista tukeakseen keräystehokkuusraportointia ja toimittajien suorituskykyanalyysiä.

Raakakuvan esikäsittely: ortorektifiointi, ilmakehäkorjaus ja pilvimaskaus

Kaupallisen toimittajan tasolla 1B (radiometrisesti korjattu, sensorin geometria) toimittama kuva-alue ei ole valmis hyödyntämiseen tai katalogointiin puolustuksen kuvajärjestelmässä. Ennen kuin se pääsee spatiaaliseen katalogiin, se on ortorektifioitava -- geometrisesti korjattava poistaakseen sensorin asentovirheet ja maaston siirtymä -- ja radiometrisesti normalisoitava johdonmukaiselle pintaheijastusasteikolle. Nämä vaiheet eivät ole valinnaisia hienosäätöjä; ne ovat edellytyksiä kuvan peittämiselle vektorikarttojen päälle, muutoksentunnistuksen suorittamiselle aiempia keräyksiä vasten ja kohteiden mittaamiselle riittävän tarkasti sotilastiedustelutarkoituksiin.

Ortorektifiointi käyttää kuva-alueen mukana niputettuja rationaalisia polynomikertoimia (RPC) ja digitaalista korkeusmallia (DEM) projisoidakseen jokaisen pikselin sensorin geometriasta karttaprojektioon. SRTM 1-kaarisekunti (noin 30 m vaakaresoluutio) on perustason DEM useimmille näyttämötason pipelineille; korkearesoluutioisille keräyksille (0,3--0,5 m maanäytteenottoetäisyys), joissa alle metrin geopaikannustarkkuus on tärkeää, tarvitaan näyttämökohtainen korkearesoluutioinen DEM, joka on johdettu stereosatelliittikeräyksistä tai ilmaperäisestä lidarista. RPC-pohjainen malli saavuttaa 3--8 m ympyrätodennäköisen virheen (CEP) ilman maastonkontrollia; harvan joukon GPS-mitattuja maastonkontrollipisteitä (GCP) lisääminen RPC-ratkaisun tarkentamiseksi parantaa tarkkuuden 1--2 m CEP:hen jälkikäsitellyille tuotteille. Tehtäville, joissa absoluuttinen geopaikannustarkkuus on kriittistä -- esimerkiksi kohdekoordinaattien mensuraatio -- pipelinen on integroitava GCP-tietokanta ja sovellettava RPC-tarkennusvaihetta automaattisesti.

Ilmakehäkorjaus muuntaa ilmakehän huipun (TOA) säteilyn pintaheijastukseksi, poistaen molekyylisironnan, aerosolien absorption ja auringonvalon geometrian vaikutukset. Tämä vaihe on välttämätön monispektriselle muutoksentunnistukselle: kaksi eri ilmakehäolosuhteissa kerättyä kuva-aluetta näyttävät näennäisiä radiometrisia eroja jokaisessa kaistassa, vaikka maanpinta ei olisi muuttunut, tuottaen vääriä hälytyksiä. Säteilynsiirtomallit kuten MODTRAN tai 6S laskevat korjauskertoimet annetuilla ilmakehäparametreilla (aerosolin optinen syvyys, vesihöyry, otsonipatsas), jotka saadaan samanaikaisista MODIS-noudoista tai mallianalyysikentistä. Pilvien ja pilven varjojen maskaus käyttää laatuarviointialgoritmia (FMask, S2cloudless tai koulutettu CNN) merkitäkseen jokaisen pikselin selkeäksi, pilveksi, varjoksi tai lumeksi/jääksi. Pilvimaski tallennetaan kumppanikaistana käsitellyn kuva-alueen rinnalle ja etenee kaikkien alavirran käsittelyvaiheiden läpi -- muutoksentunnistusalgoritmien on esimerkiksi suljettava pilvimaskatut pikselit tilastoistaan.

Formaattimaisema: NITF, GeoTIFF, JPEG 2000 ja niiden puolustuskäyttötapaukset

Puolustuksen kuvapipelinen on hallittava useita rinnakkaisia formaatteja, koska mikään yksittäinen formaatti ei tyydytä kaikkia käyttötapauksia puolustusorganisaatiossa. NITF 2.1 (National Imagery Transmission Format) on arvovaltainen säiliö tiedustelukuville Yhdysvaltain ja liittolaisten järjestelmissä. Se kantaa kuvadatan jäsenneltyjen metatietokenttien rinnalla, joita mikään muu formaatti ei natiivisti tue: turvaluokitus- ja käsittelymerkinnät tiedoston otsikossa, PIAIMC (Profile for Imagery Access) -tekniset laajennustietueet, jotka kuvaavat sensoriparametreja ja keräysgeometriaa, SENSRB (Sensor Data Records) tarkalle sensorin telemetrialle, sekä IGEOLO-kulmakoordinaatit ja karttaprojektiotiedot. NITF:n rakenne sallii myös useita kuvasegmenttejä yhdessä tiedostossa, mahdollistaen pankromaattisen kaistan, monispektripinon ja pan-terävöidyn tuotteen rinnakkaiselon yhdessä säiliössä jaetulla metatieto-otsikolla.

GeoTIFF -- ja erityisesti Cloud-Optimized GeoTIFF (COG) -- on työjuhtaformaatti verkkopohjaiselle visualisoinnille, GEOINT-alustan visualisointikerroksille ja tekoäly-/koneoppimiskäsittelytyönkuluille. COG-tiedostot organisoivat sisäisen ruutu- ja yleiskuvarakenteen niin, että HTTP-aluepyynnöt voivat noutaa vain kartan nykyisellä zoomaustasolla näkyvän osan kuvasta, mahdollistaen verkkokarttapalvelun kuvavirran suoratoiston oliotallennuksesta ilman ruutupyramidien esigeneroitia. Tekoälymallin päättelylle -- muutoksentunnistus, kohteentunnistus, piirteiden poiminta -- GeoTIFF GDAL-luettavin metatiedoin on vakiosyöteformaatti Python-pohjaisille geospatiaalisille koneoppimiskehyksille. Pipeline generoi COG-johdannaiset NITF-masterista rinnakkaisena tulostevaiheena, kirjoittaen ne oliotallennuskerrokseen, joka on verkkopalvelujen ja koneoppimispäättelysolmujen käytettävissä.

JPEG 2000 sijoittuu tiettyyn lokeroon puolustuksen kuvissa: se on NITF-tiedostojen sisällä upotettu pakkausformaatti korkearesoluutioisille tuotteille, joissa häviötön tai visuaalisesti häviötön pakkaus 4:1--8:1 -suhteilla vaaditaan, ja se on monissa vanhoissa liittouman kuvanvaihtostandardeissa käytetty formaatti. JPEG 2000:n aallokepohjainen pakkaus päihittää JPEG:n korkeilla pakkaussuhteilla samalla säilyttäen hienon yksityiskohdan piirteet, jotka ovat kriittisiä hyödyntämiselle (ajoneuvojen tunnistus, laitosanalyysi, toiminnan kuvioiden tunnistus). Pipelinen tulisi pystyä lukemaan ja kirjoittamaan JPEG 2000 -virtoja sekä itsenäisinä tiedostoina että kuvasegmenttidatana NITF-säiliöiden sisällä, käyttäen yhteensopivaa kirjastoa kuten OpenJPEG tai Kakadu. Monilähteistä kuvaa käsitteleville puolustuksen datafuusiopipelineille kaikkien lähteiden normalisointi johdonmukaiseen sisäiseen formaattiin ennen katalogin indeksointia eliminoi formaattikohtaisen käsittelyn alavirran työkaluissa.

Katalogin indeksointi: spatiaalinen ja ajallinen indeksointi nopeaan kuva-alueiden hakuun

Spatiaalinen katalogi on kuvapipelinen operatiivinen muisti. Jokainen käsitelty kuva-alue on indeksoitava ennen kuin se on hyödyllinen: oliotallennuksessa istuva ortorektifioitu NITF, josta mikään katalogi ei tiedä, on käytännössä näkymätön analyytikoille ja hyödyntämistyökaluille. SpatioTemporal Asset Catalog (STAC) -spesifikaatiosta on tullut vakioskeema puolustuksen ja kaupallisille kuvakatalogeille, koska se määrittelee yhteisen JSON-rakenteen kuva-alueen metatiedoille -- jalanjäljen geometria, hankinta-aika, sensori- ja alustatunnisteet, kaistakuvaukset, varolinkit -- joka on luettavissa kasvavalle katalogiasiakkaiden, haku-API:en ja visualisointityökalujen ekosysteemille ilman räätälöityä integraatiotyötä.

STAC API:n alla PostGIS-pohjainen PostgreSQL-tietokanta tallentaa Item-tietueet ja niiden GeoJSON-jalanjälkigeometriat. Spatiaaliset kyselyt -- "kaikki tämän monikulmion leikkaavat kuva-alueet, kerätty viimeisten 14 päivän aikana, alle 15 % pilvisyydellä, 0,5 m tai paremmalla resoluutiolla" -- suoritetaan PostGIS-spatiaalisina leikkauskyselyinä komposiitti-indeksein jalanjälkigeometriasarakkeelle, hankinta-aikasarakkeelle sekä pilvisyys- ja resoluutionumerokentille. 10 miljoonan kuva-aluetietueen katalogille tämä kyselyrakenne palauttaa tulokset alle 500 ms:ssa, jos indeksit ylläpidetään ja kyselysuunnitelmat optimoidaan. Pipelinen indeksointivaihe lisää jokaisen uuden STAC Item -tietueen heti NITF:n kirjoittamisen ja sen metatietojen validoinnin jälkeen, joten kuva-alue on kyseltävissä sekunneissa käsittelyn valmistumisesta.

Ajallinen indeksointi on yhtä tärkeää kuin spatiaalinen indeksointi muutoksentunnistustyönkuluille. Analyytikot ja automatisoidut palvelut kyselevät usein "kaikki tämän AOI:n aiemmat keräykset" muodostaakseen perustason kuva-aineiston muutoksentunnistukselle tai toiminnan kuvioiden analyysille. Indeksi hankinta-aikasarakkeelle B-puurakenteella tukee alueellisia kyselyitä (kaikki keräykset päivämäärän A ja B välillä) tehokkaasti, mutta hyödyllisin ajallinen pääsymalli -- "kaikki jalanjäljen X leikkaavat kuva-alueet hankintapäivämäärän mukaan järjestettynä" -- edellyttää yhteistä spatiaalis-ajallista kyselyä, joka hyötyy geometria- ja aikasarakkeet yhdistävästä peittävästä indeksistä. Samat spatiaalisen indeksoinnin periaatteet, joita käytetään sensoridatan normalisointipipelineissa pätevät tässä: skeema on suunniteltava niille kyselymalleille, joita hyödyntämistyökalut tosiasiallisesti antavat, ei pelkästään skeeman normalisointia varten.

Reititys hyödyntämiseen: kuvien jonotus asianmukaisille analyysityökaluille ja analyytikon työasemille

Vasta kataloitu kuva-alue on ehdokas toimitettavaksi useille alavirran kuluttajille samanaikaisesti: automatisoitu muutoksentunnistuspalvelu, tekoälypohjainen kohteentunnistusmalli, ihmisanalyytikko ja raportoinninlaatimisjärjestelmä. Reititysmoottori on komponentti, joka sovittaa jokaisen uuden kuva-alueen rekisteröityjä vaatimuksia vasten ja määrittää, mitkä kuluttajat sen vastaanottavat, missä prioriteettijärjestyksessä ja minkä toimitusmekanismin kautta. Useimmissa puolustuksen kuvajärjestelmissä käytetty reititysmalli perustuu nimettyjen kohdealueiden (NAI) tilauksiin yhdistettynä pysyväisvaatimuksiin (STANREQ), jotka määrittävät suodatuskriteerit -- minimiresoluutio, maksimipilvisyys, keräyspäivämäärän ikkuna, sensorityyppi -- ja kohdejärjestelmän tai analyytikkojonon.

Kun indeksointivaihe kirjoittaa uuden STAC Itemin, reititysmoottori arvioi sen kaikkia aktiivisia tilauksia vasten. Tilaukset toteutetaan spatiaalisina kyselyinä NAI-monikulmiokirjastoa vasten: jos kuva-alueen jalanjälki leikkaa rekisteröidyn NAI:n, moottori soveltaa tilauksen suodatuskriteerit. Kaikki kriteerit läpäisevä kuva-alue generoi toimitusilmoituksen määritetylle kohteelle. Tekoälyhyödyntämispalveluille ilmoitus kantaa kuva-alueen NITF-tallennus-URI:n ja julkaistaan työjonoon (RabbitMQ, AWS SQS tai vastaava viestivälittäjä), jota palvelun työntekijäprosessit kuluttavat. Analyytikon työasemille ilmoitus päivittää analyytikon tehtäväjonon kuvienhyödyntämisjärjestelmässä (SOCET GXP, RemoteView tai FADE/MIST) uudella tehtävätietueella, joka osoittaa kuva-alueeseen. Aikakriittisille tiedusteluvaatimuksille reititysmoottori soveltaa prioriteettikorotusta, joka syrjäyttää matalamman prioriteetin kohteet, jotka ovat jo hyödyntämisjonossa.

Turvaluokitustenvälinen reititys edellyttää erityistä huolellisuutta. Analyytikon perusakkreditointia korkeammalla turvaluokitustasolla kerättyä kuva-aluetta ei voi reitittää heidän vakiotyöasemajonoonsa; se on reititettävä asianmukaisesti akkreditoidun enklaavin työasemalle. Reititysmoottorin on kyseltävä analyytikon turvallisuusselvitys- ja akkreditointitietue identiteetinhallintajärjestelmästä ennen minkään toimitusilmoituksen lähettämistä. Automatisoidut tekoälypalvelut, jotka käsittelevät kuvaa useilla turvaluokitustasoilla, on akkreditoitava korkeimmalle käsittelemälleen datatasolle, ja niiden tulostuotteiden on kannettava kuluttamansa kuvan lähdeturvaluokitusmerkinnät. Pipelinen suunnittelijat, jotka lykkäävät näitä kontrolleja "myöhemmin lisättäviksi", huomaavat poikkeuksetta, että turvaluokitustietoisen reitityksen jälkiasentaminen olemassa olevaan viestinvälitysarkkitehtuuriin on kalliimpaa ja häiritsevämpää kuin sen rakentaminen sisään alusta alkaen.

Pipelinen suorituskyky: läpäisy, latenssi ja tallennusvaatimukset operatiivisessa mittakaavassa

Keskikokoinen puolustuksen kuvapipeline, joka tukee yksittäistä operaationäyttämöä, käsittelee tyypillisesti 50--150 satelliittikuva-aluetta päivässä useista kaupallisista ja valtiollisista lähteistä. 0,5 m resoluutiolla vakiomuotoinen kaupallinen keräysleveys kattaa 15--30 km leveän ja 100--200 km pitkän alueen, tuottaen ortorektifioituja kuva-alueita 1--4 GB kukin GeoTIFFinä ja 2--8 GB pakkaamattomana NITF:nä. Päivittäinen sisäänlukumäärä tässä mittakaavassa on 150--600 GB uutta kuva-aluedataa, plus esikäsittelyn välituotteet, jotka voivat kaksin- tai kolminkertaistaa työtallennusvaatimuksen aktiivisen käsittelyn aikana. Korkearesoluutioinen koko näyttämön ryntäys -- kattava peitto laajan kiistanalaisen alueen yli -- voi nostaa päivittäiset sisäänlukumäärät useisiin teratavuihin, edellyttäen esikäsittelyklustereita, jotka skaalautuvat vaakasuoraan latenssin SLA:iden täyttämiseksi.

Käsittelylatenssi on suorituskykyrajoite, joka vaikuttaa suorimmin operatiiviseen hyödyllisyyteen. TSI-työnkuluille tavoite on alle 30 minuuttia kuva-alueen toimituksesta katalogin saatavuuteen; rutiinituotannolle alle 4 tuntia on hyväksyttävää. Ortorektifiointivaihe on laskennallisesti intensiivisin vaihe: täysresoluutioinen 0,3 m pankromaattinen kuva-alue RPC-tarkennuksella ja DEM-projektiolla vie 5--20 minuuttia yhdellä modernilla laskentasolmulla. Rinnakkaistaminen kuva-alueruutujen yli ja useiden kuva-alueiden ajaminen samanaikaisesti 8--16 solmun klusterilla saavuttaa TSI-latenssitavoitteet tyypillisille kuva-aluemäärille. Ilmakehäkorjaus on laskennallisesti kevyempi (1--3 minuuttia per kuva-alue) mutta edellyttää pääsyä samanaikaiseen ilmakehäparametridataan NWP-mallianalyysistä tai satelliittijohdetuista aerosolituotteista, mikä tuo dataresurssiriippuvuuden, joka voi viivästyttää käsittelyä, jos lisädatan pipeline ei ole esitäytetty.

Tallennusarkkitehtuuri noudattaa porrastettua pääsymallia, joka on linjassa hyödyntämismallien kanssa. Aktiivinen työtallennus (NVMe-pohjainen lohko- tai korkean suorituskyvyn oliotallennus) pitää viimeisimmät 30--60 päivää ortorektifioituja kuva-alueita täysresoluutiolla, tukien alle sekunnin katalogikyselyitä ja nopeaa kuva-alueiden hakua aktiiviseen hyödyntämiseen. 6--18 kuukauden aktiiviarkistokerros käyttää oliotallennusta (S3-yhteensopiva) sekuntien tai minuuttien hakulatenssilla, mikä on riittävä historialliselle analyysille ja muutoksentunnistuksen perustasoille. Yli 18 kuukauden pitkäaikaissäilytys siirtyy kylmään oliotallennukseen tai nauhaan, hakulatenssilla tunteja -- hyväksyttävää historiallisille tietuevelvoitteille mutta ei aktiiviselle hyödyntämiselle. STAC-katalogitietokanta pitää aina täydellisen metatiedon kaikille kerroksille; tallennus-URI jokaisessa katalogitietueessa osoittaa asianmukaiseen kerrokseen, ja hakukerros hoitaa kerrosläpinäkyvän pääsyn, jotta hyödyntämistyökalujen ei tarvitse tietää, millä tallennuskerroksella pyydetty kuva-alue sijaitsee.