🥇Néhány szó a űrkommunikációs szabványokról

Meteor M1 műhold
Forrás: vladtime.ru

Bevezetés

A űrtechnika üzemeltetése nem lehetséges rádiókapcsolat nélkül, és ebben a cikkben megpróbálom elmagyarázni azokat az alapelveket, amelyek a Nemzetközi Űridőközlési Rendszerek Tanácsadó Bizottsága (Consultative Committee for Space Data Systems – CCSDS) által kidolgozott szabványok alapját képezik. A továbbiakban ezt az rövidítést fogom használni.

Ez a publikáció főként a csatorna szintjével foglalkozik, azonban más szintek alapvető fogalmait is be fogom mutatni. A cikk semmilyen módon nem igényli a szabványok teljes körű és részletes bemutatását. Azokkal itt lehet megismerkedni weboldalon CCSDS. Azonban ezek nehezen érthetőek, és hogy megértsük őket, sok időt töltöttünk el, ezért itt szeretném bemutatni az alapvető információkat, amelyek birtokában sokkal könnyebb lesz az összes többi részletet megérteni. Kezdjük.

A CCSDS nemes küldetése

Lehet, hogy valakiben felmerült a kérdés: miért kellene mindenkinek betartania a szabványokat, ha lehet kifejleszteni egy saját, szabadalmazott rádiókapcsolati protokollt (vagy részletesebb szabványt, új funkciókkal), így javítva a rendszer biztonságát?

A gyakorlat azt mutatja, hogy előnyösebb a CCSDS szabványaihoz tartani magunkat az alábbi okok miatt:

A szabványok kiadásáért felelős bizottság tagjai a világ összes jelentős űrügynökségéből származnak, és hozták magukkal a különböző küldetések tervezéséből és üzemeltetéséből szerzett felbecsülhetetlen tapasztalataikat. Nagyon ostobaság lenne figyelmen kívül hagyni ezt a tapasztalatot, és újra a régi hibákra lépni.
Ezek a szabványok már létező földi állomásokkal kompatibilisek.
Bármilyen probléma esetén mindig lehet segítséget kérni más ügynökségek kollégáitól, hogy végezzenek egy kapcsolatfelvételi próbát a műholdon a saját földi állomásukról. Mint látjátok, a szabványok rendkívül hasznosak, így nézzük meg a kulcsfontosságú pontjaikat.

Architektúra

A szabványok egy dokumentumokból álló gyűjteményt alkotnak, amelyek a legszokványosabb OSI (Open System Interconnection) modellt tükrözik, azzal a kivétellel, hogy a csatornaszinten a közösség az telemetriára (lefelé irányuló csatorna – űr–Föld) és a távírászati parancsokra (felfelé irányuló csatorna) való felosztásra korlátozódik.

Nézzük meg részletesebben a különböző szinteket, kezdve a fizikai szinten, majd felfelé haladva. A jobb érthetőség érdekében a fogadó fél architektúráját fogjuk vizsgálni. A küldő a tükörképét képezi.

Fizikai réteg

Ez a szint a modulált rádiójelet bitfolyammá alakítja. Itt a szabványok túlnyomó része ajánlás jellegű, mivel ezen a szinten nehéz leválni a konkrét hardver megvalósításáról. A CCSDS kulcsszerepe itt a megengedett modulációk (BPSK, QPSK, 8-QAM stb.) meghatározása és néhány ajánlás megfogalmazása a szimbolikus szinkronizálás, a Doppler-elmozdulás kompenzálása stb. megvalósításáról.

Szinkronizálási és kódolási szint

Formálisan ez a csatornaszint alábbi szintje, azonban gyakran kiemelik külön szintként a CCSDS szabványok keretein belüli jelentősége miatt. Ez a szint a bitfolyamot úgynevezett keretekké (telemetriai vagy teleparancs) alakítja, amelyeket később tárgyalni fogunk. Ellentétben a fizikai szinten végzett szimbolikus szinkronizálással, amely lehetővé teszi a helyes bitfolyam megszerzését, itt keretrendezési szinkronizálás történik. Nézzük meg, milyen úton haladnak az adatok ezen a szinten (alulról felfelé):

De előtte érdemes egy-két szót szólni a kódolásról. Ez a folyamat szükséges a flash: bithibák keresésére és/vagy javítására, amelyek elkerülhetetlenül felmerülnek az adatok rádiós csatornán történő küldésekor. Itt nem foglalkozunk a dekódolási eljárásokkal, csupán azokat az információkat kapjuk meg, amelyek szükségesek a szint további logikájának megértéséhez.

A kódok lehetnek blokk- és folyamatos kódok. A szabványok nem kötelezik annak használatát, hogy meghatározott típusú kódolást alkalmazzunk, azonban a kódolásnak jelen kell lennie. A folyamatos kódok közé tartoznak a konvolúciós kódok. Ezekkel a folyamatos bitfolyamot kódolják. A blokk kódokkal ellentétben, ahol az adatokat kódblokká (codeblock) osztják, és csak egész blokkok keretein belül dekódolhatók. A kódblokk az átadott adatokat és a helyes adatátvitel ellenőrzéséhez és esetleges hibák javításához szükséges fölösleges információt tartalmaz. A blokk kódokhoz tartoznak a híres Reed-Solomon kódok.

Ha konvolúciós kódolásról van szó, a bitfolyam az elejétől a dekóderhez érkezik. A munka eredménye (ez persze folyamatosan zajlik) a CADU (csatorna hozzáférési adat egység) adatblokkok. Ez a struktúra szükséges a keret szinkronizálásához. Minden CADU végén egy szinkronizáló marker (ASM – csatolt szinkronizáló jel) van. Ezek előre ismert 4 bájt, amelyek alapján a szinkronizáló megtalálja a CADU elejét és végét. Így érhető el a keret szinkronizálás.

A következő opcionális lépés a szinkronizáló és kódoló szint munkájában a fizikai szint működésének sajátosságaival függ össze. Ez a derandomizálás. Az a helyzet, hogy a szimbolikus szinkronizáláshoz gyakori váltásokra van szükség a szimbólumok között. Például, ha egy kilobájtnyi adatot, amely kizárólag egyesekből áll, továbbítunk, a szinkronizálás elveszik. Ezért a bemeneti adatokat egy rendszeresen ismétlődő pszeudo-véletlen sorozattal keverjük össze, hogy a nullák és egyesek sűrűsége egyenletes legyen.

Ezt követően történik a blokk kódok dekódolása, és ami megmaradt, az a szinkronizáló és kódoló szint végterméke – a keret.

Csatorna szint

Egyrészt a csatorna szint kezelője kereteket kap, másrészt csomagokat ad ki. Mivel formálisan a csomagok mérete nincs korlátozva, a megbízható továbbításhoz ezeket kisebb struktúrákra – keretekre – kell bontani. Itt két részterületet vizsgálunk: külön a telemetria (TM) és teleparancsok (TC) számára.

Telemetria

Egyszerűbben fogalmazva, ezek azok az adatok, amelyeket a földi állomás a műholdtól (KA) kap. A továbbított információt kis, rögzített hosszúságú darabokra – keretekre – osztják, amelyek az átvitt adatokat és segédmezőket tartalmaznak. Vizsgáljuk meg a keret struktúráját részletesebben:

És kezdjük a telemetriai keret fő fejlécével. A továbbiakban néhány helyen egyszerűen fordítani fogom a szabványokat, közben néhány magyarázatot is adva.

A főcsatorna azonosító mezőnek (Master Channel ID) tartalmaznia kell a keret verziószámát és az eszköz azonosítóját.

Minden KA-nak, a CCSDS szabványai szerint, egyedi azonosítóval kell rendelkeznie, amely alapján a kerettel rendelkezve meg lehet határozni, hogy melyik eszközhöz tartozik. Formálisan be kell nyújtani a berendezés regisztrálására vonatkozó kérelmet, és ennek a neve, a azonosítóval együtt, nyilvános forrásokban közzétételre kerül. Gyakran azonban az orosz gyártók figyelmen kívül hagyják ezt az eljárást, és önkényesen hozzárendelnek egy azonosítót az eszközhöz. A keret verziószáma segít meghatározni, hogy melyik szabvány verzióját használják, hogy a keretet helyesen lehessen olvasni. Itt csak a legkonzervatívabb, „0” verziójú szabványt vizsgáljuk.

A virtuális csatorna azonosítójának (Virtual Channel ID) tartalmaznia kell annak a csatornának a VCID-ját, ahonnan a csomag érkezett. Nincs korlátozás a VCID kiválasztására vonatkozóan, különösen a virtuális csatornák nincsenek kötelezően sorba számozva.

Nagyon gyakran felmerül a szükséglet az átvitt adatok multiplexelésére. Erre a virtuális csatornák mechanizmusa létezik. Például a Meteor-M2 műhold színes képet küld a látható spektrumban, három fekete-fehérre osztva azt – minden szín külön csomagban kerül átkonvertálásra a saját virtuális csatornáján, bár a kereteinek struktúrája bizonyos eltéréseket mutat a szabványoktól.

A működési vezérlés mezőnek (Operational Control) a telemetriai keretben található működési vezérlés mező jelenlétét vagy hiányát kell jelölnie. Ezek a 4 byte a keret végén a vezérlési visszajelzés fenntartására szolgálnak a telecommand keretek kézbesítésének ellenőrzése során. Erről később beszélünk.

A fő és a virtuális csatornák keretszámlálói olyan mezők, amelyeket minden egyes keret elküldésekor egy egységgel növelnek. Ezek jelzik, hogy egyetlen keret sem veszett el.

A telemetriai keret adatainak státusza még két byte flaget és adatot tartalmaz, melyekből csak néhányat vizsgálunk meg.

A másodlagos fejléc mezőnek (Secondary Header) a telemetriai keretben található másodlagos fejléc jelenlétét vagy hiányát kell jelölnie.

Igény szerint minden kerethez hozzá lehet adni egy másodlagos fejlécet, és ott bármilyen adatot elhelyezhet.

Az első fejléc mutató (First Header Pointer) mező, ha a szinkronizálási jelző értéke „1”, tartalmaznia kell az első csomag első oktettje pozíciójának bináris ábrázolását a telemetriai keret adatmezőjében (Data Field). A pozíció a 0-ról kezdődik növekvő sorrendben az adatmező elejétől. Ha a telemetriai keret adatmezőjében nincs csomag eleje, akkor az első fejléc mutató mezőnek a bináris ábrázolás „11111111111” értéket kell adnia (ez előfordulhat, ha egy hosszú csomag több mint egy keretre terjed ki).

Ha az adatmező üres csomagot (Idle Data) tartalmaz, akkor az első fejléc mutatónak a bináris ábrázolás „11111111110” értéket kell adnia. Ezen mező alapján a vevőnek szinkronizálnia kell a folyamatot. Ez a mező garantálja a szinkronizálás helyreállítását akkor is, ha képkihagyás történik.

Ezért a csomag például a 4. keret közepén kezdődhet, és a 20. elején végződhet. E mező éppen arra szolgál, hogy megtalálja a kezdőpontot. A csomagoknak is van fejlécük, amely tartalmazza a hosszát, ezért a fejléc mutató megtalálásakor a csatorna szintű feldolgozónak azt el kell olvasnia, ezáltal meg kell határoznia, hogy hol végződik a csomag.
Ha a hibaellenőrző mező jelen van, akkor minden telemetriai keretben meg kell lennie egy adott fizikai csatorna esetében a teljes küldetés során.

Ez a mező a CRC módszer alkalmazásával számítódik. A folyamatnak el kell fogadnia az n-16 bit telemetriai keretet, és a számítási eredményt a legutolsó 16 bitbe kell beillesztenie.

Távvezérlők

A távvezérlő keretnek számos lényeges eltérése van. Ezek közé tartozik:

Más fejléc struktúra
Dinamikus hossz. Ez azt jelenti, hogy a keret hossza nem rögzítve van, mint a telemetriában, hanem a továbbított csomagok függvényében változhat.
A csomagok kézbesítési garanciájának mechanizmusa. Ez azt jelenti, hogy a KÁ-nak a képek átadásának megerősítését el kell végeznie, vagy kérnie kell a visszaküldést azon a kereten, amely esetleg hibásan érkezett.

Sok mező már ismerős számunkra a telemetriai keret fejlécéből. Ezeknek ugyanaz a feladata, ezért itt csak az új mezőket fogjuk áttekinteni.

A kikerülési jelző egy bitje a képkockák ellenőrzésének vezérlésére szolgál a vevőn. A jelző "0" értéke azt jelzi, hogy a képkocka A típusú, és az ellenőrzését a FARM szerint kell végezni. A jelző "1" értéke azt jelzi a vevőnek, hogy a képkocka B típusú, és meg kell kerülnie az ellenőrzést a FARM szerint.

Ez a jelző tájékoztatja a vevőt arról, hogy szükség van-e a keretek átvitelének megerősítési mechanizmusának, azaz a FARM – Keretelfogadási és Jelentési Mechanizmus – használatára.

A vezérlési jelző a mezőadatok azt jelzi, hogy parancsot vagy adatokat szállít-e. Ha a jelző "0", a mezőadatoknak adatokat kell tartalmazniuk. Ha a jelző "1", a mezőadatoknak ellenőrzési információt kell tartalmazniuk a FARM számára.
A FARM egy állapotautomata, amelynek paraméterei beállíthatók.

RSVD. SPARE – fenntartott bitek.

Úgy tűnik, hogy a CCSDS-nek tervei vannak e bitekkel a jövőben, és a protokollverziók visszamenőleges kompatibilitása érdekében már a jelenlegi szabványverziókban fenntartották ezeket a biteket.

A keretek hossza mezőnek egy, a keret hosszát byte-okban mínusz egy kifejező számot kell tartalmaznia.

A keret adatmezőjének a fejléc után kell következnie, üresen és egy egész számnyi byte-t kell tartalmaznia, amely legfeljebb 1019 byte hosszú lehet. Ez a mező vagy a keret adatblokkot, vagy vezérlési információt kell tartalmaznia. A keret adatblokkot a következőképpen kell tartalmaznia:

a felhasználói adatok egész számú byte-jait
a szegmens fejlécét és az azt követő felhasználói adatok egész számú byte-jait

Ha a fejléc jelen van, akkor az adatblokk egy Csomagot, több Csomagot vagy annak egy részét kell tartalmaznia. Az adatblokk, amelynek nincs fejléc, nem tartalmazhat Csomagok részeit, de tartalmazhat magánformátumú adatblokkakat. Ebből következik, hogy a fejléc szükséges, amikor a továbbítandó adatblokk nem fér el egy képkockában. A fejlécet tartalmazó adatblokkot szegmensnek nevezik.

A két bit hosszú jelzőmezőnek a következőket kell tartalmaznia:

„01” — ha az adat első része az adatblokkban található
„00” — ha az adat középső része az adatblokkban található
„10” — ha az adat utolsó része az adatblokkban található
"11" — ha nincs osztás, és az adatok között teljes egészében egy vagy több csomag található.

A MAP azonosító mezőnek nullákat kell tartalmaznia, ha a MAP csatornák nem kerülnek felhasználásra.
Néha a virtuális csatornákra fenntartott 6 bit nem elegendő. Ha több csatornára kell multiplexálni az adatokat, akkor a szegmens fejlécéből további 6 bit kerül felhasználásra.

FARM

Nézzük meg részletesebben a keretátviteli ellenőrző rendszer működését. Ez a rendszer kizárólag a teleparancs képek kezelésére van tervezve, mivel ezek fontosak (a telemetria mindig újra kérhető, de a KÁ-nak világosan kell hallania a földi állomást, és mindig engedelmeskednie kell a parancsainak). Tegyük fel, hogy úgy döntöttünk, hogy újra programozzuk a műholdunkat, és egy 10 kilobyte méretű bináris fájlt küldünk fel. Az adatátviteli szinten a fájl 10 képre (0, 1, …, 9) van bontva, amelyeket sorban küldenek fel. Amikor az átadás befejeződik, a KÁ-nak meg kell erősítenie a csomag fogadásának helyességét, vagy meg kell mondania, hogy melyik képnél történt hiba. Ezt az információt a legközelebbi telemetriai kép operatív ellenőrző mezőjébe küldjük (vagy a KÁ kezdeményezheti egy üres kép (idle frame) továbbítását, ha nincs mondanivalója). A kapott telemetria alapján vagy megbizonyosodunk róla, hogy minden rendben van, vagy elkezdjük az üzenet újraküldését. Tegyük fel, hogy a műhold nem hallotta a 7-es képet. Ezért a 7, 8, 9 képeket küldjük neki. Ha nem érkezik válasz, a csomagot teljes egészében újra elküldjük (és így többször, amíg meg nem értjük, hogy a próbálkozások hiábavalóak).

Az alábbiakban bemutatjuk az operatív ellenőrző mező struktúráját, néhány mező leírásával. Ebben a mezőben található adatok neve CLCW – Communication Link Control Word.

Mivel a képen jól látható, hogy az alapmezők milyen célt szolgálnak, míg a többi unalmas nézni, részletes leírást rejtettem el egy spoiler alatt.

A CLCW mezők dekódolásaA kontroll szó típusa (Control Word Type):
Ehhez a kontroll szó típushoz 0-t kell tartalmaznia.

A kontroll szó verziója (CLCW Version Number):
Ehhez a kontroll szó típushoz "00"-nak kell lennie bitképű formátumban.

A státusz mező (Status Field):
E mező használatát a missziók egyedileg határozzák meg. Különféle űrhivatalok számára helyi fejlesztésekre használható.

Virtuális csatorna azonosító (Virtual Channel Identification):
Tartalmaznia kell a virtuális csatorna azonosítóját, amelyhez a jelen ellenőrző szó kapcsolódik.

Hozzáférési jel a fizikai csatornához:
A jelnek információt kell adnia a vevő fizikai szintjének készenlétéről. Ha a vevő fizikai szintje nem készenlétben van a képkockák fogadására, a mezőnek "1"-et kell tartalmaznia, különben "0"-t.

Szinkronizációs hiba jelző:
A jel tájékoztathat arról, hogy a fizikai szint gyenge jel mellett működik, és a visszautasított képkockák száma túl magas. E mező használata opcionális, ha használják, akkor "0"-t kell tartalmaznia a szinkronizálás esetén, és "1"-et a szinkronizálás hiányában.

Zárolási jelző:
Ez a bit a FARM zárolásának státuszát kell tartalmaznia minden virtuális csatornához. A "1" érték ennek a mezőnek arra utal, hogy a FARM zárolva van, és a képkockákat el fogják dobni minden virtuális szinten, különben "0".

Várakozási jelző:
Ez a bit arra szolgál, hogy jelezze, hogy a vevő nem tudja feldolgozni az adott virtuális csatornán a megadott adatokat. A "1" érték jelzi, hogy az összes képkockát el fogják dobni ezen a virtuális csatornán, különben "0".

Átkapcsolási jelző:
Ez a jel "1"-et kell tartalmaznia, ha egy vagy több A típusú képkockát eldobtak vagy hiányosságot találtak, így átkapcsolás szükséges. A "0" jelző azt mutatja, hogy nem voltak eldobott képkockák és hiányosságok.

Válasz értéke:
Az a képkocka száma, amelyet nem fogadtak el. A teleparancs fejlécében található számláló alapján határozzák meg.

Hálózati szint

Röviden érintjük ezt a szintet is. Itt két lehetőség van: vagy a űrpakk protokollt használjuk, vagy bármilyen más protokollt CCSDS csomagba enkapszulálunk.

A űrpakk protokoll áttekintése - külön cikk témája. Arra lett kifejlesztve, hogy a különböző alkalmazások zökkenőmentesen tudjanak adatokat cserélni. Minden alkalmazáshoz tartozik egy cím, és van egy alapvető funkció, amely az adatcserét más alkalmazásokkal lehetővé teszi. Emellett vannak szolgáltatások, amelyek a forgalom irányítását, a kézbesítés ellenőrzését stb. végzik.

Az enkapszuláció sokkal egyszerűbb és érthetőbb. A szabványok lehetővé teszik, hogy bármilyen protokollt CCSDS csomagokba enkapszuláljunk egy további fejléc hozzáadásával.

A fejlécek eltérő jelentéseket hordoznak a beágyazott protokoll hosszától függően:

Itt a fő mező a hosszúság hossza. Ez 0 és 4 byte között változhat. Ezen a fejlécen meg kell adni a beágyazott protokoll típusát is, a táblázat segítségével. innen.

IP beágyazásakor egy másik réteget is használnak a csomag típusának meghatározására.
Egy újabb fejlécet is hozzá kell adni, amely legalább egy oktett hosszú:

Ahol a PID – egy másik protokoll azonosító, amelyet az alábbiak szerint veszünk innen

Zárás

Első pillantásra úgy tűnhet, hogy a CCSDS fejléc rendkívül redundáns, és egyes mezők elhagyhatók. Valóban, a kimeneti csatorna hatékonysága (a hálózati szinten) körülbelül 40%. Azonban, amikor a szabványok megvalósítása szükségessé válik, egyértelművé válik, hogy minden mezőnek, minden fejlécnek megvan a maga fontos szerepe, amelynek figyelmen kívül hagyása számos félreértéshez vezet.

Ha a közösség érdeklődést mutat e téma iránt, örömmel publikálnék egy sor további cikket, amely a űrváltó kommunikáció elméletére és gyakorlatára összpontosít. Köszönöm a figyelmet!