🥇Malo o standardima svemirske komunikacije

Satelit Meteor M1
Izvor: vladtime.ru

Uvod

Eksploatacija svemirske tehnologije nije moguća bez radio veze, a u ovom članku ću pokušati objasniti osnovne ideje koje su temelj standarda razvijenih od strane Međunarodnog savjetodavnog komiteta za svemirske sustave prijenosa podataka (Consultative Committee for Space Data Systems – CCSDS. Ova kratica će se dalje koristiti).

Ova publikacija će se prvenstveno posvetiti kanalnoj razini, međutim, osnovni pojmovi za druge razine također će biti uvedeni. Članak ne pretendira na sveobuhvatno i potpuno opisivanje standarda. Možete ga pronaći na web stranici CCSDS-u. Međutim, oni su vrlo teški za razumijevanje, i da bismo ih shvatili potrošili smo dosta vremena, stoga ovdje želim navesti osnovne informacije, s kojima će biti mnogo lakše razumjeti sve ostalo. Pa, da krenemo.

Plemenita misija CCSDS

Možda se netko pita: zašto se svi trebaju pridržavati standarda, ako se može razviti vlastiti proprietarni paket protokola radio veze (ili vlastiti standard, s blackjackom i novim funkcijama), povećavajući time sigurnost sustava?

Iz iskustva pokazuje se da je isplativije pridržavati se standarda CCSDS iz sljedećih razloga:

U odbor koji je odgovoran za objavljivanje standarda uključeni su predstavnici svih važnih svemirskih agencija svijeta, koji su donijeli svoje neprocjenjivo iskustvo stečeno tijekom godina dizajniranja i eksploatacije raznih misija. Bilo bi vrlo glupo ignorirati to iskustvo i ponovo kročiti u iste zamke.
Ovi standardi su podržani već postojećom opremom zemaljskih stanica na tržištu.
Tijekom otklanjanja bilo kakvih kvarova, uvijek se može obratiti kolegama iz drugih agencija kako bi oni izveli komunikacijski sesiju s uređajem sa svoje zemaljske stanice. Kao što vidite, standardi su vrlo korisna stvar, stoga hajde da razjasnimo njihove ključne točke.

Arhitektura

Standardi predstavljaju skup dokumenata koji odražavaju najosnovniji model OSI (Open System Interconnection), osim što se na kanalnoj razini zajedništvo ograničava dijeljenjem na telemetriju (kanal 'dolje' — svemir - Zemlja) i telekomande (kanal 'gore').

Pogledajmo neke razine detaljnije, počinjući od fizičke, a zatim se penjući prema gore. Za bolju preglednost, razmatrat ćemo arhitekturu primateljske strane. Prijenosna strana predstavlja njezinu zrcalnu sliku.

Fizička razina

Na ovoj razini događa se pretvorba moduliranog radio signala u bitni tok. Standardi na ovoj razini uglavnom su preporučeni, budući da je teško odvojiti se od konkretne implementacije opreme. Ključna uloga CCSDS-a je odrediti prihvatljive modulacije (BPSK, QPSK, 8-QAM itd.) i dati neka preporučena rješenja za implementaciju mehanizama simbolne sinkronizacije, kompenzacije Dopplerovog pomaka itd.

Razina sinkronizacije i kodiranja

Formalno je podrazina kanalne razine, međutim, često se ističe kao posebna razina zbog svoje važnosti unutar CCSDS standarda. Ova razina pretvara bitni tok u takozvane okvire (telemetrije ili telekomandi), o kojima ćemo naknadno razgovarati. Za razliku od simbolne sinkronizacije na fizičkoj razini, koja omogućava dobivanje ispravnog bitnog toka, ovdje se provodi okvirna sinkronizacija. Pogledajmo put kojim podaci prolaze na ovoj razini (odozdo prema gore):

Međutim, prije toga, potrebno je reći nekoliko riječi o kodiranju. Ova procedura je neophodna za pronalaženje i/ili ispravljanje bitnih grešaka koje neizbježno nastaju prilikom slanja podataka putem radio kanala. Ovdje nećemo razmatrati procedure dekodiranja, već ćemo dobiti informacije potrebne za razumijevanje daljnje logike rada razine.

Kodovi mogu biti blokovni i neprekidni. Standardi ne zahtijevaju korištenje određenog tipa kodiranja, međutim, ono mora postojati. Neprekidni kodovi uključuju konvolucijske kodove. Uz njih se kodira neprekidni bitni tok. Za razliku od blokovnih kodova, gdje se podaci dijele na kodne blokove (codeblock) i mogu se dekodirati samo unutar cjelovitih blokova. Kodni blok sastoji se od prenesenih podataka i pridružene redundantne informacije potrebne za provjeru ispravnosti primanja podataka i ispravljanje mogućih grešaka. Blokovni kodovi uključuju poznate Reed-Solomon kodove.

Ako se koristi konvolucijsko kodiranje, bit-stream na početku odlazi u dekoder. Rezultat njegova rada (sve to, naravno, događa se kontinuirano) su blokovi podataka CADU (channel access data unit). Ova struktura je neophodna za sinkronizaciju kadrova. Na kraju svakog CADU pridružen je sinkronizacijski marker (ASM – attached synch maker). To su poznata 4 bajta prema kojima sinkronizator pronalazi početak i kraj CADU. Tako se postiže sinkronizacija kadrova.

Sljedeća opcionalna faza rada razine sinkronizacije i kodiranja povezana je s osobinama rada fizičke razine. To je derandomizacija. Naime, kako bi se postigla simbolička sinkronizacija, potrebna su česta prebacivanja između simbola. Dakle, ako budemo prenosili, pretpostavimo, kilobajt podataka koji se sastoji isključivo od jedinica, sinkronizacija će biti izgubljena. Stoga se pri prijenosu ulazni podaci miješaju s periodičnom pseudoraspršenom sekvencom kako bi gustoća nula i jedinica bila ravnomjerna.

Nakon toga dolazi do dekodiranja blokovskih kodova, a ono što preostane će biti konačni proizvod razine sinkronizacije i kodiranja – kadar.

Kanalna razina

S jedne strane, obrađivač kanalne razine prima kadrove, dok s druge strane isporučuje pakete. Budući da formalno veličina paketa nije ograničena, za pouzdanu isporuku potrebno ih je razbiti na manje strukture – kadrove. Ovdje ćemo razmotriti dva podpodjela: posebno za telemetriju (TM) i telekomande (TC).

Telemetrija

Jednostavno rečeno, to su podaci koje zemaljska stanica prima od svemirske letjelice. Svi preneseni podaci dijele se na male fragmente fiksne dužine – kadrove, koji sadrže prenesene podatke i kontrolna polja. Pogledajmo detaljnije strukturu kadra:

I započnimo razmatranje s osnovnom glavom kadra telemetrije. Kasnije ću si dozvoliti u nekim dijelovima jednostavno prevesti standarde, uz davanje nekih objašnjenja.

Polje identifikatora glavnog kanala (Master Channel ID) treba sadržavati broj verzije kadra i identifikator uređaja.

Svaki KA, prema CCSDS standardima, mora imati jedinstveni identifikator putem kojeg se može, na temelju okvira, odrediti kojem aparatu pripada. Formalno je potrebno podnijeti zahtjev za registraciju aparata, a njegovo ime, zajedno s identifikatorom, bit će objavljeno u otvorenim izvorima. Međutim, često ruski proizvođači ignoriraju ovu proceduru, dodjeljujući aparatu proizvoljan identifikator. Broj verzije okvira pomaže odrediti koja verzija standarda se koristi kako bi se ispravno pročitao okvir. Ovdje ćemo razmotriti samo najkonzervativniji standard s verzijom "0".

U polju identifikatora virtualnog kanala (Virtual Channel ID) treba sadržavati VCID tog kanala s kojeg je paket stigao. Nema ograničenja u odabiru VCID-a, posebno virtualni kanali ne moraju biti numerirani slijedno.

Veoma često se javlja potreba za multiplexiranjem prenesenih podataka. Za to postoji mehanizam virtualnih kanala. Na primjer, satelit Meteor-M2 prenosi slikovne podatke u vidljivom spektru, dijeleći ih na tri crno-bijela – svaka boja se prenosi u svom virtualnom kanalu zasebnim paketom, iako u strukturi njegovih okvira postoji određeno odstupanje od standarda.

Polje zastavice Operativne Kontrole treba biti indikator prisutnosti ili odsutnosti polja Operativne Kontrole u okviru telemetrije. Ova 4 bajta na kraju okvira služe za održavanje povratne informacije tijekom kontrole dostave okvira telekomandi. O njima ćemo govoriti malo kasnije.

Brojači okvira glavnog i virtualnog kanala – to su polja koja se povećavaju za jedan prilikom slanja svakog okvira. Služe kao indikator da nijedan okvir nije izgubljen.

Status podataka okvira telemetrije – to su još dva bajta zastavica i podataka, od kojih ćemo razmotriti samo neke.

Polje zastavice dodatnog zaglavlja (Secondary Header) treba biti indikator prisutnosti ili odsutnosti dodatnog zaglavlja (Secondary Header) u okviru telemetrije.

Ako želite, možete dodati dodatno zaglavlje svakom okviru i tamo smjestiti bilo koje podatke po svojoj želji.

Polje pokazivača na prvi naslov (First Header Pointer), kada je vrijednost oznake sinkronizacije «1», treba sadržavati binarnu reprezentaciju pozicije prvog okteta prvog Paketa u polju podataka (Data Field) telemetrijskog okvira. Pozicija se broji od 0 u rastućem redoslijedu od početka polja podataka. Ako nema početka paketa u polju podataka telemetrijskog okvira, tada polje pokazivača na prvi naslov treba imati vrijednost u binarnoj reprezentaciji «11111111111» (to se može dogoditi ako jedan dugi paket obuhvata više od jednog okvira).

Ako u polju podataka postoji prazan paket (Idle Data), tada pokazivač na prvi naslov treba imati vrijednost u binarnoj reprezentaciji «11111111110». Ovisno o ovom polju, prijemnik treba izvršiti sinkronizaciju toka. Ovo polje jamči obnavljanje sinkronizacije čak i u slučaju propuštanja okvira.

To jest, paket može, primjerice, početi u sredini 4. okvira i završiti na početku 20. Kako bi se pronašao njegov početak, služi ovo polje. Paketi također imaju naslov, u kojem je navedena njihova duljina, tako da prilikom pronalaženja pokazivača na prvi naslov, obrada kanalske razine mora ga pročitati, čime se određuje gdje završava paket.
Ako je polje kontrole grešaka prisutno, mora biti sadržano u svakom telemetrijskom okviru za određeni fizički kanal tijekom cijele misije.

Ovo polje se izračunava primjenom CRC metode. Procedura treba prihvatiti n-16 bitnog telemetrijskog okvira i umetnuti rezultat izračuna u posljednjih 16 bitova.

Telekomande

Okvir telekomandi ima nekoliko značajnih razlika. Među njima su:

Druga struktura naslova
Dinamička duljina. To znači da duljina okvira nije strogo zadana, kao što je to slučaj u telemetriji, već se može mijenjati ovisno o prenosivim paketima.
Mehanizam jamstva isporuke paketa. Dakle, KА mora potvrditi ispravnost prijema okvira nakon primitka ili zatražiti ponovnu isporuku s onog okvira koji je mogao biti primljen s neispravnom greškom.

Mnoga polja su nam već poznata iz naslova telemetrijskog okvira. Ona imaju istu namjenu, stoga ćemo ovdje razmotriti samo nova polja.

Jedan bit zastavice zaobiđite treba koristiti za kontrolu provjere okvira na prijemniku. Vrijednost "0" za tu zastavicu trebala bi označavati da je taj okvir tipa A i da se njegova provjera treba obavljati prema FARM-u. Vrijednost "1" ove zastavice trebala bi obavijestiti prijemnik da je taj okvir tipa B i da treba zaobići provjeru prema FARM-u.

Ova zastavica obavještava prijemnik treba li koristiti mehanizam potvrde isporuke okvira, poznat kao FARM — Mehanizam prihvaćanja i izvještavanja okvira.

Zastavica za kontrolu naredbi treba se koristiti za razumijevanje prenosi li polje podataka naredbu ili podatke. Ako je zastavica "0", polje podataka treba sadržavati podatke. Ako je zastavica "1", polje podataka treba sadržavati kontrolne informacije za FARM.
FARM predstavlja konačni automat čije se parametre može prilagođavati.

RSVD. SPARE – rezervirani bitovi.

Izgleda da CCSDS ima planove za njih u budućnosti, a za povratnu kompatibilnost verzija protokola rezervirali su te bite čak i u trenutnim verzijama standarda.

Polje duljine okvira treba sadržavati broj u bitnom prikazu koji je jednak duljini okvira u oktetima minus jedan.

Polje podataka okvira treba slijediti nakon zaglavlja bez razmaka i sadržavati cijeli broj okteta koji može imati maksimalnu duljinu od 1019 okteta. Ovo polje treba sadržavati ili blok podataka okvira ili informacije o kontrolnoj naredbi. Blok podataka okvira trebao bi sadržavati:

cijeli broj okteta korisnih podataka
zaglavlje segmenta i sljedećih cijeli broj okteta korisnih podataka

Ako je zaglavlje prisutno, blok podataka treba sadržavati Paket, skup Paketa ili njegov dio. Blok podataka bez zaglavlja ne može sadržavati dijelove Paketa, ali može sadržavati blokove podataka privatnog formata. Iz toga proizlazi da je zaglavlje potrebno kada se preneseni blok podataka ne može smjestiti u jedan okvir. Blok podataka s zaglavljem naziva se segment.

Polje zastavica veličine dva bita treba sadržavati:

"01" — ako je prvi dio podataka u bloku podataka
"00" — ako je srednji dio podataka u bloku podataka
"10" — ako je zadnji dio podataka u bloku podataka
«11» — ako nema dijeljenja i u bloku podataka smješten je cijeli jedan ili više paketa.

Polje identifikatora MAP mora sadržavati nule ako se MAP kanali ne koriste.
Ponekad 6 bita dodijeljenih virtualnim kanalima nije dovoljno. Ako je potrebno multiplexirati podatke na veći broj kanala, još 6 bita iz zaglavlja segmenta dolazi u igru.

FARMA

Pogledajmo detaljnije mehanizam funkcioniranja sustava kontrole isporuke kadrova. Ovaj sustav predviđa rad samo s kadrovima telekomandi zbog njihove važnosti (telemetriju uvijek možemo ponovno zatražiti, dok KА mora jasno čuti zemaljsku stanicu i uvijek se podčinjavati njenim naredbama). Pretpostavimo da smo odlučili ponovno programirati naš satelit i šaljemo mu binarni datoteku veličine 10 kilobajta. Na razini kanala datoteka se dijeli na 10 kadrova (0, 1, …, 9), koji se uzastopno šalju prema gore. Kada je prijenos završen, KА mora potvrditi ispravnost prijema paketa ili javiti na kojem je kadru došlo do greške. Ove informacije šalju se u polju operativne kontrole u najbližem kadru telemetrije (ili KА može inicirati prijenos praznog kadra (idle frame), ako nema ništa za reći). Na temelju primljene telemetrije, ili se uvjeravamo da je sve u redu, ili prelazimo na ponovni prijenos poruke. Pretpostavimo da satelit nije čuo kadar br. 7. Znači, šaljemo mu kadrove 7, 8, 9. U slučaju da odgovor nije stigao, paket se šalje u cijelosti ponovno (i tako nekoliko puta, dok ne shvatimo da su pokušaji uzaludni).

U nastavku je prikazana struktura polja operativne kontrole s opisom nekih polja. Podaci sadržani u ovom polju nazivaju se CLCW – Communication Link Control Word.

Budući da se iz slike može lako naslutiti namjena osnovnih polja, a promatranje drugih je dosadno, detaljan opis skrivam iza spoylera.

Dešifriranje polja CLCWTip kontrolnog riječi (Control Word Type):
Za ovaj tip kontrolnog riječi mora sadržavati 0

Verzija kontrolnog riječi (CLCW Version Number):
Za ovaj tip kontrolnog riječi trebala bi biti «00» u bitnom predstavljanju.

Polje statusa (Status Field):
Korištenje ovog polja određuje se za svaku misiju posebno. Može se koristiti za lokalna poboljšanja različitih svemirskih agencija.

Identifikator virtualnog kanala (Virtual Channel Identification):
Mora sadržavati identifikator virtualnog kanala s kojim je povezana ova kontrolna riječ.

Zastavica pristupa fizičkom kanalu:
Zastavica treba pružati informacije o spremnosti fizičke razine prijemnika. Ako fizička razina prijemnika nije spremna za prijem okvira, polje treba sadržavati „1“, inače „0“.

Zastavica pogreške sinkronizacije:
Zastavica može javljati da fizička razina radi pri lošoj razini signala i da je broj odbačenih okvira previsok. Korištenje ovog polja je opcionalno; ako se koristi, treba sadržavati „0“ u prisustvu sinkronizacije i „1“ u nedostatku sinkronizacije.

Zastavica blokade:
Ova oznaka treba sadržavati status blokade FARM za svaki virtualni kanal. Vrijednost „1“ u ovom polju trebala bi označavati da je FARM blokiran i da će okviri biti odbačeni za svaku virtualnu razinu, inače „0“.

Zastavica čekanja:
Ova oznaka treba se koristiti za indikaciju da prijemnik ne može obraditi podatke na navedenom virtualnom kanalu. Vrijednost „1“ ukazuje da će svi okviri biti odbačeni na ovom virtualnom kanalu, inače „0“.

Zastavica preusmjeravanja:
Ova zastavica treba sadržavati „1“ ako je jedan ili više okvira tipa A odbačeno ili su pronađeni gubici, pa je potrebna ponovna usmjeravanje. Zastavica „0“ označava da nije bilo odbačenih okvira i gubitaka.

Vrijednost odgovora:
Broj okvira koji nije prihvaćen. Određuje se brojačem u zaglavlju okvira telekomande

Mrežna razina

Malo ćemo se dotaknuti i ove razine. Ovdje postoje dvije mogućnosti: ili koristiti protokol svemirskog paketa, ili inkapsulirati bilo koji drugi protokol u CCSDS paket.

Pregled protokola svemirskog paketa – tema je za poseban članak. Stvoren je za to da se tako zvane aplikacije mogu neometano razmjenjivati podatke. Svaka aplikacija ima svoju adresu i osnovnu funkcionalnost za razmjenu podataka s drugim aplikacijama. Također postoje usluge koje obavljaju usmjeravanje prometa, kontrolu dostave itd.

S inkapsulacijom je sve jednostavnije i jasnije. Standardi omogućuju inkapsuliranje u CCSDS pakete bilo kojih protokola dodavanjem dodatnog zaglavlja.

Gdje naslov ima različita značenja ovisno o duljini inkapsuliranog protokola:

Ovdje je osnovno polje – duljina duljine. Može varirati od 0 do 4 bajta. Također, u ovom je naslovu potrebno navesti vrstu inkapsuliranog protokola, pomoću tablice odavde.

Pri inkapsulaciji IP koristi se još jedna nadogradnja za određivanje vrste paketa.
Potrebno je dodati još jedan naslov, duljine od jednog okteta:

Gdje je PID – još jedan identifikator protokola, dobiven odavde

Zaključak

Na prvi pogled može se činiti da su naslov CCSDS izuzetno suvišni i neka se polja mogu odbaciti. Uistinu, učinkovitost rezultantnog kanala (do mrežne razine) iznosi oko 40%. Međutim, čim se javi potreba za implementacijom tih standarda, postaje jasno da svako polje, svaki naslov ima svoju važnu misiju, čije ignoriranje dovodi do niza nejasnoća.

Ako zajednica pokaže interes za ovu temu, rado ću objaviti još niz članaka posvećenih teoriji i praksi svemirske komunikacije. Hvala na pažnji!