Satelit Meteor M1
Zdroj: vladtime.ru
úvod
Provoz vesmírných technologií je nemožný bez rádiových komunikací a v tomto článku se pokusím vysvětlit hlavní myšlenky, které tvořily základ standardů vyvinutých Mezinárodním poradním výborem pro vesmírné datové systémy (CCSDS. Tato zkratka bude použita níže) .
Tento příspěvek se zaměří především na vrstvu datového spojení, ale budou představeny i základní pojmy pro další vrstvy. Tento článek si v žádném případě neklade za cíl být důkladným a úplným popisem standardů. Můžete si jej prohlédnout na CCSDS. Jsou však velmi obtížně srozumitelné a strávili jsme spoustu času snahou jim porozumět, proto zde chci poskytnout základní informace, díky nimž bude mnohem snazší porozumět všemu ostatnímu. Takže, začněme.
Vznešená mise CCSDS
Možná má někdo otázku: proč by měl každý dodržovat standardy, když si můžete vyvinout vlastní proprietární zásobník rádiových protokolů (nebo svůj vlastní standard s blackjackem a novými funkcemi), čímž zvýšíte bezpečnost systému?
Jak ukazuje praxe, je výhodnější dodržovat standardy CCSDS z následujících důvodů:
- Ve výboru odpovědném za vydávání norem jsou zástupci všech významných leteckých agentur na světě, kteří přinášejí neocenitelné zkušenosti získané během mnoha let projektování a provozu různých misí. Bylo by velmi absurdní tuto zkušenost ignorovat a znovu jim šlápnout na hrábě.
- Tyto standardy jsou podporovány zařízením pozemních stanic, které je již na trhu.
- Při odstraňování jakýchkoli problémů můžete vždy vyhledat pomoc od kolegů z jiných agentur, aby mohli provést komunikační relaci se zařízením ze své pozemní stanice. Jak vidíte, standardy jsou nesmírně užitečná věc, pojďme se tedy podívat na jejich klíčové body.
architektura
Standardy jsou souborem dokumentů odrážejícím nejběžnější model OSI (Open System Interconnection), kromě toho, že na úrovni datového spoje je shoda omezena na rozdělení na telemetrii (downlink - vesmír - Země) a telecommands (uplink).
Podívejme se na některé úrovně podrobněji, počínaje fyzickou a postupujeme nahoru. Pro větší přehlednost zvážíme architekturu přijímací strany. Vysílací je jeho zrcadlový obraz.
Fyzická vrstva
Na této úrovni je modulovaný rádiový signál převeden na bitový tok. Standardy zde mají převážně poradní charakter, protože na této úrovni je obtížné abstrahovat od konkrétní implementace hardwaru. Zde je klíčovou úlohou CCSDS definovat přijatelné modulace (BPSK, QPSK, 8-QAM atd.) a poskytnout některá doporučení k implementaci mechanismů synchronizace symbolů, kompenzace Dopplera atd.
Úroveň synchronizace a kódování
Formálně je to podvrstva vrstvy datového spoje, ale často je oddělena do samostatné vrstvy kvůli své důležitosti v rámci standardů CCSDS. Tato vrstva převádí bitový tok na tzv. rámce (telemetrie nebo telecommands), o kterých si povíme později. Na rozdíl od synchronizace symbolů na fyzické vrstvě, která umožňuje získat správný bitový tok, se zde provádí synchronizace snímků. Zvažte cestu, kterou se data ubírají na této úrovni (zdola nahoru):
Předtím však stojí za to říci pár slov o kódování. Tento postup je nezbytný pro nalezení a/nebo opravu bitových chyb, které se nevyhnutelně vyskytují při odesílání dat rádiovým kanálem. Zde nebudeme uvažovat o dekódovacích postupech, ale pouze získáme informace nezbytné k pochopení další logiky úrovně.
Kódy mohou být blokové nebo souvislé. Normy nevynucují použití konkrétního typu kódování, ale musí být jako takové přítomno. Spojité kódy zahrnují konvoluční kódy. Používají se ke kódování nepřetržitého bitového toku. To je na rozdíl od blokových kódů, kde jsou data rozdělena do kódových bloků a lze je dekódovat pouze v rámci celých bloků. Blok kódu představuje přenášená data a připojené redundantní informace nutné pro ověření správnosti přijatých dat a opravu případných chyb. Blokové kódy zahrnují slavné Reed-Solomonovy kódy.
Pokud je použito konvoluční kódování, bitový tok vstupuje do dekodéru od začátku. Výsledkem její práce (to vše se samozřejmě děje průběžně) jsou datové bloky CADU (channel access data unit). Tato struktura je nezbytná pro synchronizaci snímků. Na konci každé CADU je připojený synch maker (ASM). Jedná se o předem známé 4 bajty, podle kterých synchronizátor najde začátek a konec CADU. Tímto způsobem je dosaženo synchronizace snímků.
Další volitelný stupeň synchronizační a kódovací vrstvy je spojen se zvláštnostmi fyzické vrstvy. Toto je derandomizace. Faktem je, že k dosažení synchronizace symbolů je nutné časté přepínání mezi symboly. Pokud tedy přeneseme řekněme kilobajt dat sestávajících výhradně z jedniček, dojde ke ztrátě synchronizace. Proto se při přenosu vstupní data míchají s periodickou pseudonáhodnou sekvencí tak, aby hustota nul a jedniček byla rovnoměrná.
Dále se dekódují blokové kódy a zbývá finální produkt úrovně synchronizace a kódování – rámec.
Data Link Layer
Na jedné straně procesor linkové vrstvy přijímá rámce a na druhé straně vydává pakety. Jelikož velikost paketů není formálně omezena, pro jejich spolehlivý přenos je nutné je rozdělit na menší struktury - rámce. Zde se podíváme na dvě podsekce: odděleně pro telemetrii (TM) a telecommands (TC).
Telemetrie
Jednoduše řečeno, jde o data, která pozemní stanice dostává od kosmické lodi. Všechny přenášené informace jsou rozděleny na malé fragmenty pevné délky - rámce, které obsahují přenášená data a pole služeb. Podívejme se blíže na strukturu rámu:
A začněme naši úvahu hlavním záhlavím telemetrického rámce. Dále si dovolím na některých místech standardy jednoduše přeložit a cestou upřesnit.
Pole Master Channel ID musí obsahovat číslo verze rámce a identifikátor zařízení.
Každá kosmická loď musí mít podle standardů CCSDS svůj vlastní jedinečný identifikátor, podle kterého lze pomocí rámečku určit, ke kterému zařízení patří. Formálně je nutné podat žádost o registraci zařízení a jeho název spolu s identifikátorem bude zveřejněn v otevřených zdrojích. Ruští výrobci však tento postup často ignorují a přidělují zařízení libovolný identifikátor. Číslo verze rámce pomáhá určit, která verze standardů se používá pro správné čtení rámce. Zde budeme uvažovat pouze nejkonzervativnější standard s verzí „0“.
Pole ID virtuálního kanálu musí obsahovat VCID kanálu, ze kterého paket přišel. Neexistují žádná omezení pro výběr VCID, zejména virtuální kanály nemusí být nutně číslovány sekvenčně.
Velmi často vzniká potřeba multiplexovat přenášená data. Pro tento účel existuje mechanismus virtuálních kanálů. Například družice Meteor-M2 přenáší barevný obraz ve viditelném rozsahu a rozděluje jej na tři černobílé - každá barva je přenášena ve svém vlastním virtuálním kanálu v samostatném paketu, i když existují určité odchylky od standardů v struktura jeho rámů.
Pole příznaku provozního řízení musí být indikátorem přítomnosti nebo nepřítomnosti pole provozního řízení v rámci telemetrie. Tyto 4 bajty na konci rámce slouží k poskytování zpětné vazby při řízení doručování rámců dálkového ovládání. Promluvíme si o nich trochu později.
Čítače rámců hlavního a virtuálního kanálu jsou pole, která se při každém odeslání rámce zvýší o jedničku. Slouží jako indikátor toho, že se neztratil ani jeden snímek.
Stav dat telemetrického rámce je další dva bajty příznaků a dat, z nichž se podíváme jen na několik.
Pole příznaku sekundárního záhlaví musí být indikátorem přítomnosti nebo nepřítomnosti sekundárního záhlaví v rámci telemetrie.
Pokud chcete, můžete do každého rámce přidat další záhlaví a umístit tam jakákoli data podle svého uvážení.
Pole First Header Ukazatel, když je synchronizační příznak nastaven na "1", musí obsahovat binární reprezentaci polohy prvního oktetu prvního paketu v datovém poli telemetrického rámce. Pozice se počítá od 0 ve vzestupném pořadí od začátku datového pole. Pokud v datovém poli telemetrického rámce není žádný začátek paketu, musí mít ukazatel na první pole záhlaví hodnotu v binární reprezentaci „11111111111“ (k tomu může dojít, pokud je jeden dlouhý paket rozložen na více než jeden rámec ).
Pokud datové pole obsahuje prázdný paket (Idle Data), pak by ukazatel na první záhlaví měl mít hodnotu v binárním vyjádření „11111111110“. Pomocí tohoto pole musí přijímač synchronizovat stream. Toto pole zajišťuje obnovení synchronizace, i když jsou snímky zahozeny.
To znamená, že paket může, řekněme, začít uprostřed 4. snímku a skončit na začátku 20. snímku. Toto pole slouží k nalezení jeho začátku. Pakety mají také hlavičku, která specifikuje jejich délku, takže když je nalezen ukazatel na první hlavičku, procesor linkové vrstvy jej musí přečíst, čímž určí, kde paket skončí.
Pokud je přítomno pole kontroly chyb, musí být obsaženo v každém telemetrickém rámci pro konkrétní fyzický kanál během celé mise.
Toto pole se vypočítá pomocí metody CRC. Postup musí vzít n-16 bitů telemetrického rámce a vložit výsledek výpočtu do posledních 16 bitů.
televizní týmy
Příkazový rámec TV má několik významných rozdílů. Mezi nimi:
- Jiná struktura nadpisů
- Dynamická délka. To znamená, že délka rámce není nastavena pevně, jak je tomu u telemetrie, ale může se lišit v závislosti na přenášených paketech.
- Mechanismus záruky doručení paketů. To znamená, že kosmická loď musí po jejím obdržení potvrdit správnost příjmu rámce, případně požádat o předání z rámce, který mohl být přijat s neopravitelnou chybou.
Mnoho polí je nám již známé z hlavičky telemetrického rámce. Mají stejný účel, takže zde budeme uvažovat pouze o nových polích.
Jeden bit příznaku přemostění musí být použit k řízení kontroly rámců na přijímači. Hodnota "0" pro tento příznak znamená, že rám je rámem typu A a musí být ověřen podle FARM. Hodnota "1" pro tento příznak by měla přijímači indikovat, že tento rámec je rámcem typu B a měl by obejít kontrolu FARM.
Tento příznak informuje příjemce, zda použít mechanismus potvrzení doručení rámce nazvaný FARM - Frame Acceptance and Reporting Mechanism.
Příznak řídicího příkazu se musí použít k pochopení, zda datové pole přenáší příkaz nebo data. Pokud je příznak "0", pak datové pole musí obsahovat data. Pokud je příznak "1", pak datové pole musí obsahovat řídicí informace pro FARMU.
FARM je konečný automat, jehož parametry lze konfigurovat.
RSVD. SPARE – rezervované bity.
Zdá se, že CCSDS s nimi má do budoucna plány a pro zpětnou kompatibilitu verzí protokolů si tyto bity rezervuje již v aktuálních verzích standardu.
Pole délky rámce musí obsahovat číslo v bitovém vyjádření, které se rovná délce rámce v oktetech mínus jedna.
Datové pole rámce musí následovat za záhlavím bez mezer a obsahovat celý počet oktetů, který může mít délku maximálně 1019 oktetů. Toto pole musí obsahovat buď datový blok rámce, nebo informace řídicího příkazu. Datový blok rámce musí obsahovat:
- celé číslo počet oktetů uživatelských dat
- záhlaví segmentu následované celočíselným počtem oktetů uživatelských dat
Pokud je přítomna hlavička, pak datový blok musí obsahovat paket, sadu paketů nebo část paketu. Datový blok bez hlavičky nemůže obsahovat části paketů, ale může obsahovat datové bloky soukromého formátu. Z toho vyplývá, že hlavička je vyžadována, když se přenášený datový blok nevejde do jednoho rámce. Blok dat, který má záhlaví, se nazývá segment
Pole dvoubitových příznaků musí obsahovat:
- "01" - pokud je první část dat v datovém bloku
- „00“ - pokud je střední část dat v datovém bloku
- "10" - pokud je poslední údaj v datovém bloku
- „11“ - pokud neexistuje žádné dělení a jeden nebo více paketů se zcela vejde do datového bloku.
Pokud se nepoužívají kanály MAP, musí pole ID MAP obsahovat nuly.
Někdy nestačí 6 bitů přidělených virtuálním kanálům. A pokud je potřeba multiplexovat data na větší počet kanálů, použije se dalších 6 bitů z hlavičky segmentu.
HOSPODAŘIT
Podívejme se blíže na mechanismus fungování systému kontroly dodávek personálu. Tento systém umožňuje pouze práci s rámci telepříkazů vzhledem k jejich důležitosti (telemetrii lze vždy znovu vyžádat a kosmická loď musí jasně slyšet pozemní stanici a vždy poslouchat její příkazy). Předpokládejme tedy, že se rozhodneme přeformátovat náš satelit a pošleme na něj binární soubor o velikosti 10 kilobajtů. Na úrovni odkazu je soubor rozdělen do 10 snímků (0, 1, ..., 9), které jsou odesílány nahoru jeden po druhém. Po dokončení přenosu musí satelit potvrdit správnost příjmu paketu, případně ohlásit, ve kterém rámci došlo k chybě. Tato informace je odeslána do provozního řídicího pole v nejbližším telemetrickém rámci (Nebo může kosmická loď zahájit přenos nečinného snímku, pokud nemá co říci). Na základě přijaté telemetrie se buď ujistíme, že je vše v pořádku, nebo přistoupíme k opětovnému odeslání zprávy. Předpokládejme, že satelit neslyšel snímek #7. To znamená, že mu posíláme rámce 7, 8, 9. Pokud nepřijde žádná odpověď, je celý paket odeslán znovu (a tak dále několikrát, dokud si neuvědomíme, že pokusy jsou marné).
Níže je uvedena struktura pole provozního řízení s popisem některých polí. Data obsažená v tomto poli se nazývají CLCW - Communication Link Control Word.
Vzhledem k tomu, že z obrázku snadno uhodnete účel hlavních polí a na ostatní vás nudí pohled, schovávám podrobný popis pod spoiler
Vysvětlení polí CLCWTyp řídicího slova:
U tohoto typu musí řídicí slovo obsahovat 0
Verze řídicího slova (číslo verze CLCW):
U tohoto typu musí být řídicí slovo v bitové reprezentaci rovno "00".
Stavové pole:
Využití tohoto pole je určeno pro každou misi zvlášť. Může být použit pro místní vylepšení různými vesmírnými agenturami.
Identifikace virtuálního kanálu:
Musí obsahovat identifikátor virtuálního kanálu, ke kterému je toto řídicí slovo přidruženo.
Příznak fyzického přístupu ke kanálu:
Příznak musí poskytovat informaci o připravenosti fyzické vrstvy příjemce. Pokud fyzická vrstva přijímače není připravena přijímat rámce, musí pole obsahovat „1“, jinak „0“.
Příznak selhání synchronizace:
Příznak může indikovat, že fyzická vrstva pracuje na špatné úrovni signálu a počet odmítnutých rámců je příliš vysoký. Použití tohoto pole je volitelné, pokud je použito, musí obsahovat „0“, pokud je synchronizace dostupná, a „1“, pokud není.
Příznak blokování:
Tento bit musí obsahovat stav FARM lock pro každý virtuální kanál. Hodnota "1" v tomto poli by měla znamenat, že FARM je zakázána a snímky budou pro každou virtuální vrstvu vyřazeny, jinak "0".
Vlajka čekání:
Tento bit se použije k označení, že přijímač nemůže zpracovat data na specifikovaném virtuálním kanálu. Hodnota "1" znamená, že všechny snímky budou na tomto virtuálním kanálu vyřazeny, jinak "0".
Dopředný příznak:
Tento příznak musí obsahovat „1“, pokud byl jeden nebo více rámců typu A vyřazen nebo byly nalezeny mezery, takže je nutné opětovné odeslání. Příznak "0" znamená, že nebyly žádné vynechané snímky nebo přeskočení.
Hodnota odpovědi:
Číslo snímku, které nebylo přijato. Určeno čítačem v záhlaví rámce dálkového ovládání
síťová vrstva
Pojďme se této úrovně trochu dotknout. Zde jsou dvě možnosti: buď použít protokol vesmírných paketů, nebo zapouzdřit jakýkoli jiný protokol do paketu CCSDS.
Přehled vesmírného paketového protokolu je tématem na samostatný článek. Je navržen tak, aby umožňoval takzvaným aplikacím bezproblémovou výměnu dat. Každá aplikace má svou adresu a základní funkcionalitu pro výměnu dat s jinými aplikacemi. Existují také služby, které směrují provoz, řídí doručování atd.
Se zapouzdřením je vše jednodušší a jasnější. Standardy umožňují zapouzdřit jakékoli protokoly do paketů CCSDS přidáním další hlavičky.
Kde má hlavička různý význam v závislosti na délce zapouzdřeného protokolu:
Zde je hlavním polem délka délky. Může se lišit od 0 do 4 bajtů. Také v této hlavičce musíte uvést typ zapouzdřeného protokolu pomocí tabulky .
IP encapsulation používá další doplněk k určení typu paketu.
Musíte přidat ještě jedno záhlaví, jeden oktet dlouhý:
Kde PID je jiný převzatý identifikátor protokolu
Závěr
Na první pohled se může zdát, že hlavičky CCSDS jsou extrémně nadbytečné a některá pole by mohla být zahozena. Ve skutečnosti je účinnost výsledného kanálu (až na úrovni sítě) asi 40 %. Jakmile však vyvstane potřeba implementovat tyto standardy, je jasné, že každá oblast, každý okruh má své vlastní důležité poslání, jehož ignorování vede k řadě nejasností.
Pokud o toto téma projeví habrasociety zájem, rád uveřejním celou sérii článků věnovaných teorii a praxi vesmírných komunikací. Děkuji za pozornost!
zdroje
PS
Nebijte příliš silně, pokud zjistíte nějaké nepřesnosti. Nahlaste je a budou opraveny :)
Zdroj: www.habr.com