Meteor M1 műhold
Forrás: vladtime.ru
Bevezetés
Az űrtechnológia működése lehetetlen rádiókommunikáció nélkül, és ebben a cikkben megpróbálom elmagyarázni azokat a főbb gondolatokat, amelyek a Nemzetközi Űradatrendszerek Tanácsadó Bizottsága (CCSDS) által kidolgozott szabványok alapját képezték. .
Ez a bejegyzés elsősorban az adatkapcsolati rétegre összpontosít, de más rétegek alapfogalmait is bemutatjuk. Ez a cikk semmiképpen sem kívánja a szabványok alapos és teljes leírását. Megtekintheti a címen CCSDS. Azonban nagyon nehéz megérteni őket, és sok időt töltöttünk azzal, hogy megértsük őket, ezért itt szeretnék olyan alapvető információkat közölni, amelyek birtokában minden mást sokkal könnyebben megérthet. Szóval, kezdjük.
A CCSDS nemes küldetése
Lehet, hogy valakinek kérdése van: miért kellene mindenkinek ragaszkodnia a szabványokhoz, ha kifejlesztheti saját szabadalmaztatott rádióprotokoll-veremét (vagy saját szabványát, blackjack-kel és új funkciókkal), ezáltal növelve a rendszer biztonságát?
Amint a gyakorlat azt mutatja, jövedelmezőbb a CCSDS szabványok betartása a következő okok miatt:
- A szabványok közzétételéért felelős bizottságban a világ minden jelentősebb légiközlekedési ügynökségének képviselői vesznek részt, felbecsülhetetlen értékű tapasztalatokat gyűjtve a különböző küldetések tervezése és működtetése során. Nagyon abszurd volna figyelmen kívül hagyni ezt az élményt, és újra rálépni a gereblyére.
- Ezeket a szabványokat a már piacon lévő földi állomás berendezések támogatják.
- Bármilyen probléma elhárításakor mindig kérhet segítséget más ügynökségeknél dolgozó kollégáktól, hogy a földi állomásukról kommunikációt folytathassanak az eszközzel. Mint látható, a szabványok rendkívül hasznosak, ezért nézzük meg a legfontosabb pontjaikat.
építészet
A szabványok a legelterjedtebb OSI (Open System Interconnection) modellt tükröző dokumentumok, azzal a különbséggel, hogy adatkapcsolati szinten a közösség a telemetriára (lefelé irányuló kapcsolat - űr - Föld) és a teleparancsokra (uplink) való felosztásra korlátozódik.
Nézzünk meg néhány szintet részletesebben, kezdve a fizikaival és haladva felfelé. A nagyobb áttekinthetőség érdekében figyelembe vesszük a fogadó oldal architektúráját. Az átadó a tükörképe.
Fizikai réteg
Ezen a szinten a modulált rádiójel bitfolyammá alakul. A szabványok itt elsősorban tanácsadó jellegűek, mivel ezen a szinten nehéz elvonatkoztatni a hardver konkrét megvalósításától. Itt a CCSDS kulcsszerepe, hogy meghatározza az elfogadható modulációkat (BPSK, QPSK, 8-QAM, stb.) és néhány ajánlást adjon a szimbólumszinkronizációs mechanizmusok megvalósítására, a Doppler-kompenzációra stb.
Szinkronizálási és kódolási szint
Formálisan az adatkapcsolati réteg egyik alrétege, de gyakran külön rétegre osztják a CCSDS szabványokon belüli fontossága miatt. Ez a réteg alakítja át a bitfolyamot úgynevezett keretekké (telemetria vagy telecommand), amelyekről később még szó lesz. Ellentétben a fizikai réteg szimbólumszinkronizálásával, amely lehetővé teszi a megfelelő bitfolyam elérését, itt a keretszinkronizálás történik. Fontolja meg, hogy az adatok ezen a szinten milyen úton haladnak (alulról felfelé):
Előtte azonban érdemes néhány szót ejteni a kódolásról. Ez az eljárás szükséges a rádiócsatornán keresztüli adatküldés során elkerülhetetlenül előforduló bithibák megtalálásához és/vagy kijavításához. Itt nem fogjuk figyelembe venni a dekódolási eljárásokat, hanem csak a szint további logikájának megértéséhez szükséges információkat szerezzük meg.
A kódok lehetnek blokkosak vagy folyamatosak. A szabványok nem kényszerítik ki egy meghatározott típusú kódolás használatát, de ennek ilyennek kell lennie. A folyamatos kódok közé tartoznak a konvolúciós kódok is. Folyamatos bitfolyam kódolására szolgálnak. Ez ellentétben áll a blokkkódokkal, ahol az adatok kódblokkokra vannak osztva, és csak teljes blokkon belül dekódolhatók. A kódblokk a továbbított adatokat és a csatolt redundáns információkat jelenti, amelyek a fogadott adatok helyességének ellenőrzéséhez és az esetleges hibák kijavításához szükségesek. A blokkkódok közé tartoznak a híres Reed-Solomon kódok.
Ha konvolúciós kódolást használunk, a bitfolyam kezdettől fogva belép a dekódolóba. Munkájának eredménye (mindez természetesen folyamatosan történik) a CADU (channel access data unit) adatblokkok. Ez a struktúra szükséges a keretszinkronizáláshoz. Minden CADU végén található egy szinkronkészítő (ASM). Ez 4 előre ismert bájt, amivel a szinkronizáló megtalálja a CADU elejét és végét. Így érhető el a keretszinkronizálás.
A szinkronizálási és kódolási réteg következő opcionális szakasza a fizikai réteg sajátosságaihoz kapcsolódik. Ez a derandomizálás. A helyzet az, hogy a szimbólumok szinkronizálásához gyakori váltás szükséges a szimbólumok között. Tehát, ha mondjuk egy kilobájtnyi adatot továbbítunk, amely teljesen egyesekből áll, a szinkronizálás elvész. Ezért az átvitel során a bemeneti adatok egy periodikus pszeudo-véletlen sorozattal keverednek, hogy a nullák és egyesek sűrűsége egyenletes legyen.
Ezután a blokkkódokat dekódolják, és ami marad, az a szinkronizálási és kódolási szint végterméke - egy keret.
Adatkapcsolati réteg
Az egyik oldalon a linkréteg processzora fogad kereteket, a másik oldalon pedig csomagokat ad ki. Mivel a csomagok mérete formálisan nincs korlátozva, megbízható átvitelük érdekében kisebb struktúrákra - keretekre kell bontani őket. Itt két alfejezetet nézünk meg: külön a telemetriát (TM) és a távvezérlést (TC).
Telemetria
Egyszerűen fogalmazva, ezek azok az adatok, amelyeket a földi állomás kap az űrhajótól. Az összes továbbított információ meghatározott hosszúságú kis töredékekre van felosztva - keretekre, amelyek továbbított adatokat és szolgáltatási mezőket tartalmaznak. Nézzük meg közelebbről a keret szerkezetét:
És kezdjük a mérlegelést a telemetriai keret fő fejlécével. Továbbá megengedem magamnak, hogy néhány helyen egyszerűen lefordítsam a szabványokat, és közben néhány pontosítást adok.
A Master Channel ID mezőnek tartalmaznia kell a keret verziószámát és az eszköz azonosítóját.
A CCSDS szabványok szerint minden űrhajónak saját egyedi azonosítóval kell rendelkeznie, amely alapján egy keret birtokában megállapítható, hogy melyik eszközhöz tartozik. Formálisan az eszköz regisztrációjához szükséges kérelmet benyújtani, melynek neve az azonosítójával együtt nyílt forráskódban kerül közzétételre. Az orosz gyártók azonban gyakran figyelmen kívül hagyják ezt az eljárást, tetszőleges azonosítót rendelve az eszközhöz. A keret verziószáma segít meghatározni, hogy a szabvány melyik verzióját használják a keret helyes olvasásához. Itt csak a legkonzervatívabb szabványt fogjuk figyelembe venni a „0” verzióval.
A Virtual Channel ID mezőnek tartalmaznia kell annak a csatornának a VCID-jét, amelyről a csomag érkezett. Nincsenek korlátozások a VCID kiválasztására vonatkozóan, különösen a virtuális csatornák nem feltétlenül sorszámozva vannak.
Nagyon gyakran van szükség az átvitt adatok multiplexelésére. Erre a célra van egy virtuális csatornák mechanizmusa. Például a Meteor-M2 műhold színes képet továbbít a látható tartományban, három fekete-fehérre osztva - minden színt a saját virtuális csatornáján külön csomagban továbbítanak, bár van némi eltérés a szabványtól. kereteinek szerkezete.
Az Üzemeltetési vezérlés jelzőmezője az Üzemeltetési vezérlés mező meglétét vagy hiányát jelzi a telemetriai keretben. Ez a keret végén található 4 bájt visszacsatolást biztosít a távvezérlési keretek kézbesítésének vezérlésekor. Kicsit később beszélünk róluk.
A fő és a virtuális csatorna keretszámlálói olyan mezők, amelyek minden egyes keret elküldésekor eggyel nőnek. Jelzőként szolgál, hogy egyetlen képkocka sem veszett el.
A telemetriai keret adatállapota további két bájt zászló és adat, amelyek közül csak néhányat nézünk meg.
A Másodlagos fejléc jelzőmezőnek a másodlagos fejléc meglétét vagy hiányát kell jeleznie a telemetriai keretben.
Ha szeretné, minden egyes kerethez hozzáadhat egy további fejlécet, és tetszés szerint elhelyezhet ott bármilyen adatot.
Az Első fejlécmutató mező, amikor a szinkronizálási jelző "1"-re van állítva, az első csomag első oktettjének bináris reprezentációját tartalmazza a telemetriai keret adatmezőjében. A pozíciót 0-tól számítja az adatmező elejétől növekvő sorrendben. Ha a telemetria keret adatmezőjében nincs a csomag eleje, akkor az első fejléc mezőre mutató mutatónak a "11111111111" bináris ábrázolásban kell lennie (ez akkor fordulhat elő, ha egy hosszú csomag egynél több keretre van szétosztva ).
Ha az adatmező üres csomagot tartalmaz (Üresjárati adatok), akkor az első fejléc mutatójának binárisan „11111111110” értékkel kell rendelkeznie. Ennek a mezőnek a használatával a vevőnek szinkronizálnia kell az adatfolyamot. Ez a mező biztosítja, hogy a szinkronizálás akkor is helyreálljon, ha a kereteket eldobják.
Vagyis egy csomag mondjuk kezdődhet a 4. frame közepén és a 20. elején érhet véget. Ez a mező a kezdetének megtalálására szolgál. A csomagoknak van egy fejléce is, amely meghatározza a hosszát, így amikor az első fejlécre mutató mutatót találunk, a link-layer processzornak be kell olvasnia azt, ezáltal meghatározva, hogy a csomag hol fog végződni.
Ha van hibaellenőrző mező, akkor annak minden telemetriai keretben szerepelnie kell egy adott fizikai csatornához a küldetés során.
Ezt a mezőt a CRC módszerrel számítják ki. Az eljárásnak n-16 bitet kell vennie a telemetriai keretből, és be kell illesztenie a számítás eredményét az utolsó 16 bitbe.
TV csapatok
A TV parancskeretnek számos jelentős különbsége van. Közöttük:
- Eltérő címsorszerkezet
- Dinamikus hosszúság. Ez azt jelenti, hogy a keret hossza nincs mereven beállítva, mint a telemetriában, hanem a továbbított csomagoktól függően változhat.
- Csomagszállítási garancia mechanizmus. Vagyis az űrhajónak a vétel után meg kell erősítenie a képkocka vétel helyességét, vagy olyan keretről kell továbbítást kérnie, amelyet javíthatatlan hibával fogadhatott volna.
Sok mezőt már ismerünk a telemetriai keret fejlécéből. Ugyanaz a céljuk, ezért itt csak az új területeket fogjuk figyelembe venni.
A bypass jelző egy bitjét kell használni a keretellenőrzés vezérlésére a vevőnél. A jelző "0" értéke azt jelzi, hogy a keret A típusú keret, és a FARM szerint ellenőrizni kell. A jelző "1" értékének azt kell jeleznie a vevő számára, hogy a keret B típusú keret, és ki kell hagynia a FARM ellenőrzést.
Ez a jelző tájékoztatja a vevőt, hogy használja-e a FARM – keretelfogadási és jelentési mechanizmus nevű keretkézbesítési nyugtázási mechanizmust.
A vezérlőparancs jelzőt kell használni annak megértéséhez, hogy az adatmező parancsot vagy adatot szállít-e. Ha a zászló "0", akkor az adatmezőnek adatokat kell tartalmaznia. Ha a jelző "1", akkor az adatmezőnek tartalmaznia kell a FARM ellenőrzési információkat.
A FARM egy véges állapotú gép, amelynek paraméterei konfigurálhatók.
RSVD. SPARE – fenntartott bitek.
Úgy tűnik, hogy a CCSDS tervei vannak velük a jövőben, és a protokollverziók visszafelé kompatibilitása érdekében ezeket a biteket már lefoglalták a szabvány jelenlegi verzióiban.
A kerethossz mezőnek tartalmaznia kell egy olyan számot bitreprezentációban, amely egyenlő a kerethosszúsággal oktettben mínusz egy.
A keret adatmezőjének szóközök nélkül kell követnie a fejlécet, és egész számú oktettet kell tartalmaznia, amely legfeljebb 1019 oktett hosszúságú lehet. Ennek a mezőnek vagy keretadatblokk- vagy vezérlőparancs-információkat kell tartalmaznia. A keret adatblokknak tartalmaznia kell:
- a felhasználói adatok oktetteinek egész száma
- szegmens fejléce, majd egy egész számú felhasználói adat oktett
Ha van fejléc, akkor az adatblokknak tartalmaznia kell egy csomagot, egy csomagkészletet vagy egy csomag egy részét. A fejléc nélküli adatblokk nem tartalmazhatja a Packet részeit, de tartalmazhat privát formátumú adatblokkokat. Ebből következik, hogy akkor van szükség fejlécre, ha az átvitt adatblokk nem fér bele egy keretbe. A fejléccel rendelkező adatblokkot szegmensnek nevezzük
A kétbites flags mezőnek a következőket kell tartalmaznia:
- "01" - ha az adat első része az adatblokkban van
- „00” - ha az adatok középső része az adatblokkban van
- "10" - ha az utolsó adat az adatblokkban van
- „11” - ha nincs felosztás, és egy vagy több csomag teljesen belefér az adatblokkba.
A MAP ID mezőnek nullákat kell tartalmaznia, ha nem használnak MAP csatornákat.
Néha a virtuális csatornákhoz kiosztott 6 bit nem elegendő. Ha pedig több csatornára kell az adatokat multiplexelni, akkor a szegmens fejlécéből további 6 bit kerül felhasználásra.
FARM
Nézzük meg közelebbről a személyszállítás-ellenőrző rendszer működési mechanizmusát. Ez a rendszer csak a távvezérlési keretekkel való munkavégzést teszi lehetővé azok fontossága miatt (telemetria mindig újra kérhető, és az űrhajónak tisztán kell hallania a földi állomást, és mindig engedelmeskednie kell annak parancsainak). Tehát tegyük fel, hogy úgy döntünk, hogy újraindítjuk a műholdunkat, és egy 10 kilobájt méretű bináris fájlt küldünk rá. A hivatkozás szintjén a fájl 10 képkockára van osztva (0, 1, ..., 9), amelyek egyenként kerülnek felfelé. Amikor az átvitel befejeződött, a műholdnak meg kell erősítenie a csomag vétel helyességét, vagy jelentenie kell, hogy melyik kereten történt a hiba. Ezt az információt a legközelebbi telemetriai keretben lévő működési vezérlő mezőbe küldik (Vagy az űrhajó kezdeményezheti egy üresjárati keret átvitelét, ha nincs mondanivalója). A kapott telemetria alapján vagy megbizonyosodunk arról, hogy minden rendben van, vagy folytatjuk az üzenet újraküldését. Tegyük fel, hogy a műhold nem hallotta a 7. képkockát. Ez azt jelenti, hogy elküldjük neki a 7., 8., 9. keretet. Ha nem érkezik válasz, akkor a teljes csomagot újra elküldi (és így tovább többször is, amíg rá nem jön, hogy a próbálkozások hiábavalók).
Az alábbiakban a működésvezérlő mező felépítése látható néhány mező leírásával. Az ebben a mezőben található adatok neve CLCW – Communication Link Control Word.
Mivel a képről könnyen kitalálható a fő mezők rendeltetése, a többit pedig unalmas nézni, a részletes leírást spoiler alá rejtem
A CLCW mezők magyarázataVezérlőszó típusa:
Ennél a típusnál a vezérlőszónak 0-t kell tartalmaznia
A vezérlőszó verziója (CLCW verziószám):
Ennél a típusnál a vezérlőszónak "00"-nak kell lennie a bitábrázolásban.
Állapot mező:
Ennek a mezőnek a használatát minden küldetésnél külön határozzák meg. Különféle űrügynökségek helyi fejlesztésekhez használhatják.
Virtuális csatorna azonosítás:
Tartalmaznia kell annak a virtuális csatornának az azonosítóját, amelyhez ez a vezérlőszó társítva van.
Fizikai csatorna hozzáférési jelző:
A zászlónak információt kell adnia a vevő fizikai rétegének készenlétéről. Ha a vevő fizikai rétege nem áll készen a keretek fogadására, akkor a mezőnek „1”-et, ellenkező esetben „0”-t kell tartalmaznia.
Szinkronizálási hiba jelző:
A zászló azt jelezheti, hogy a fizikai réteg gyenge jelszinten működik, és az elutasított keretek száma túl magas. Ennek a mezőnek a használata nem kötelező; ha van, akkor a „0”-t kell tartalmaznia, ha elérhető a szinkronizálás, és az „1”-et, ha nem.
Blokkoló zászló:
Ez a bit minden virtuális csatorna FARM zárolási állapotát tartalmazza. A mezőben lévő „1” érték azt jelzi, hogy a FARM le van tiltva, és a rendszer eldobja a kereteket minden egyes virtuális rétegben, ellenkező esetben „0”.
Várj zászló:
Ezt a bitet annak jelzésére kell használni, hogy a vevő nem tudja feldolgozni az adatokat a megadott virtuális csatornán. Az "1" érték azt jelzi, hogy az összes képkocka el lesz dobva ezen a virtuális csatornán, ellenkező esetben "0".
Előre zászló:
Ennek a jelzőnek egy "1"-et kell tartalmaznia, ha egy vagy több A típusú keretet eldobtak, vagy hiányosságokat találtak, ezért újra kell küldeni. A „0” jelző azt jelzi, hogy nem voltak kiesett keretek vagy kihagyások.
Válaszérték:
Nem kapott keretszám. A távvezérlési keret fejlécében lévő számláló határozza meg
Hálózati réteg
Érintsük meg egy kicsit ezt a szintet. Itt két lehetőség van: vagy használja a space packet protokollt, vagy bármilyen más protokollt beépít a CCSDS csomagba.
A space packet protokoll áttekintése egy külön cikk témája. Úgy tervezték, hogy lehetővé tegye az úgynevezett alkalmazások zökkenőmentes adatcseréjét. Minden alkalmazásnak megvan a saját címe és alapvető funkciói a többi alkalmazással való adatcseréhez. Vannak olyan szolgáltatások is, amelyek irányítják a forgalmat, irányítják a kézbesítést stb.
A tokozással minden egyszerűbb és világosabb. A szabványok lehetővé teszik, hogy egy további fejléc hozzáadásával bármilyen protokollt CCSDS-csomagokba foglaljon.
Ahol a fejléc eltérő jelentéssel bír a beágyazott protokoll hosszától függően:
Itt a fő mező a hossz hossza. 0 és 4 bájt között változhat. Ebben a fejlécben is meg kell adni a beágyazott protokoll típusát a táblázat segítségével .
Az IP-beágyazás egy másik kiegészítőt használ a csomag típusának meghatározására.
Hozzá kell adnia még egy fejlécet, egy oktett hosszúságú:
Ahol a PID egy másik protokollazonosító
Következtetés
Első pillantásra úgy tűnhet, hogy a CCSDS fejlécek rendkívül redundánsak, és néhány mezőt el lehet dobni. Valójában a kapott csatorna hatékonysága (a hálózati szintig) körülbelül 40%. Amint azonban szükség van e szabványok alkalmazására, világossá válik, hogy minden területnek, minden rovatnak megvan a maga fontos küldetése, amelynek figyelmen kívül hagyása számos kétértelműséghez vezet.
Ha a habratársadalom érdeklődést mutat a téma iránt, szívesen publikálok egy egész sor cikksorozatot az űrkommunikáció elméletével és gyakorlatával kapcsolatban. Köszönöm a figyelmet!
forrás
PS
Ne üsse túl keményen, ha pontatlanságot talál. Jelentsd őket és megjavítják :)
Forrás: will.com