🥇Trochu o standardech vesmírné komunikace

Satelit Meteor M1
Zdroj: vladtime.ru

Úvod

Provoz kosmické techniky je nemožný bez radiového spojení, a v tomto článku se pokusím vysvětlit základní myšlenky, které leží v základech standardů vyvinutých Mezinárodním poradním výborem pro kosmické systémy přenosu dat (Consultative Committee for Space Data Systems – CCSDS. Tato zkratka bude dále používána).

Tato publikace se bude zaměřovat především na kanálovou úroveň, nicméně základní pojmy pro ostatní úrovně budou také představeny. Článek si rozhodně neklade za cíl podrobně a kompletně popsat standardy. S tím se můžete seznámit na webu CCSDS. Nicméně jsou velmi obtížné na pochopení, a abychom je přehledně zvládli, strávili jsme poměrně dost času, proto zde chci uvést základní informace, jejichž znalost usnadní porozumění všemu ostatnímu. Takže začněme.

Ušlechtilá mise CCSDS

Možná se někdo ptá: proč se všichni držet standardů, když si lze vyvinout vlastní proprietární protokol pro radiové spojení (nebo svůj vlastní standard, s blackjackem a novými funkcemi), čímž zvýšíme bezpečnost systému?

Jak ukazuje praxe, je výhodnější se držet standardů CCSDS z následujících důvodů:

Do výboru, který odpovídá za publikaci standardů, vstoupili zástupci všech významných astronautických agentur světa, kteří přinesli své cenné zkušenosti získané během mnoha let navrhování a provozování různých misí. Bylo by velmi hloupé ignorovat tuto zkušenost a znovu na někoho šlápnout.
Tyto standardy podporují již existující zařízení pozemních stanic na trhu.
Při odstraňování jakýchkoli závad se vždy lze obrátit na kolegy z jiných agentur, aby s jejich pozemní stanicí provedli spojení s aparátem. Jak vidíte, standardy jsou velmi užitečné, a proto se pojďme podívat na jejich klíčové aspekty.

Architektura

Standardy představují soubor dokumentů, které odrážejí obyčejný model OSI (Open System Interconnection), s výjimkou toho, že na kanálové úrovni je obecnost omezena dělením na telemetrii (kanál "dolů" – kosmos – Země) a telecommandy (kanál "nahoru").

Podíváme se podrobněji na některé úrovně, počínaje fyzickou a postupuji výše. Pro větší názornost budeme zkoumat architekturu přijímající strany. Odesílající je jejím zrcadlovým odrazem.

Fyzikální úroveň

Na této úrovni dochází k transformaci modulované rádiové signálu na bitový tok. Standardy zde mají převážně doporučující charakter, protože na této úrovni je obtížné abstrahovat od konkrétní implementace hardwaru. Klíčová role CCSDS zde spočívá v určení přípustných modulací (BPSK, QPSK, 8-QAM atd.) a poskytnutí některých doporučení k implementaci mechanismů symbolové synchronizace, kompenzace Dopplerova posunu apod.

Úroveň synchronizace a kódování

Formálně je podúrovní kanálové úrovně, ale velmi často je vyzdvihována jako samostatná úroveň vzhledem k její důležitosti v rámci standardů CCSDS. Tato úroveň transformuje bitový tok na takzvané rámy (telemetrie nebo telecommand), o kterých si později povíme. Na rozdíl od symbolové synchronizace na fyzické úrovni, která umožňuje získat správný bitový tok, zde probíhá rámová synchronizace. Podívejme se na cestu, kterou data procházejí na této úrovni (shora dolů):

Předtím je však třeba říci několik slov o kódování. Tento proces je nezbytný k nalezení a/nebo opravě bitových chyb, které nevyhnutelně vznikají při odesílání dat přes rádiový kanál. Zde nebudeme zkoumat procedury dekódování, pouze získáme informace potřebné k pochopení další logiky práce úrovně.

Kódy bývají blokové a kontinuální. Standardy nenutí používat konkrétní typ kódování, avšak to jako takové musí být přítomno. Mezi kontinuální kódy patří konvoluční kódy. Pomocí nich je kodován kontinuální bitový tok. Na rozdíl od blokových kódů, kde jsou data rozdělena na kódové bloky (codeblock), a mohou být dekódována pouze v rámci celých bloků. Kódový blok představuje přenášená data a připojené redundantní informace potřebné k ověření správnosti přijetí dat a opravě možných chyb. Mezi blokovými kódy vynikají slavné Reed-Solomonovy kódy.

Pokud se používá konvoluční kódování, stream bitů na začátku přichází do dekodéru. Výsledkem jeho práce (to vše se samozřejmě děje kontinuálně) se stávají bloky dat CADU (channel access data unit). Tato struktura je nezbytná pro rámcovou synchronizaci. Na konci každého CADU je připojen synchronizační marker (ASM – attached synch maker). Jsou to předem známé 4 bajty, podle nichž synchronizátor najde začátek a konec CADU. Tím se dosahuje rámcové synchronizace.

Další volitelný krok na úrovni synchronizace a kódování souvisí se specifiky fyzické úrovně. To je derandomizace. Skutečnost je taková, že k dosažení symbolové synchronizace jsou potřebné časté přepínání mezi symboly. Tak, pokud bychom přenášeli například kilobajt dat tvořený výhradně jedničkami, synchronizace by byla ztracena. Proto se během přenosu vstupní data míchají s periodickou pseudonáhodnou posloupností, aby byla hustota nul a jedniček rovnoměrná.

Dále dochází k dekódování blokových kódů, a to, co zůstane, bude konečným produktem úrovně synchronizace a kódování – rámec.

Kanálová úroveň

Na jedné straně zpracovatel kanálové úrovně dostává rámce a na druhé straně vydává pakety. Protože formálně není velikost paketů omezena, pro jejich spolehlivé zasílání je třeba rozdělit je na menší struktury – rámce. Zde si projdeme dvě pododdělení: zvlášť pro telemetrii (TM) a telecommandy (TC).

Telemetrie

Jednoduše řečeno, jsou to data, která pozemní stanice dostává od kosmického aparátu. Veškeré přenášené informace se dělí na malé fragmenty pevné délky – rámce, které obsahují přenášená data a servisní pole. Podívejme se na strukturu rámce podrobněji:

A začneme prozkoumání s hlavním záhlavím rámce telemetrie. Dovolím si v některých místech pouze překládat standardy a poskytovat některá vysvětlení.

Pole identifikátoru hlavního kanálu (Master Channel ID) by mělo obsahovat číslo verze rámce a identifikátor aparátu.

Každý KA podle standardů CCSDS musí mít svůj jedinečný identifikátor, pomocí něhož lze zjistit, kterému zařízení patří. Formálně je nutné podat žádost o registraci zařízení, a jeho název spolu s identifikátorem bude publikován v otevřených zdrojích. Často však ruští výrobci tuto proceduru ignorují a přidělují zařízení libovolný identifikátor. Číslo verze snímku pomáhá určit, která verze standardů je použita k tomu, aby bylo možné správně přečíst snímek. Zde se zaměříme pouze na nejkonzervativnější standard s verzí "0".

V poli identifikátoru virtuálního kanálu (Virtual Channel ID) by měl být VCID kanálu, ze kterého byl packet zaslán. Na výběr VCID nejsou žádná omezení, zejména virtuální kanály nemusí být číslovány sekvenčně.

Označeně často vzniká potřeba multiplexovat přenášená data. K tomu existuje mechanismus virtuálních kanálů. Například satelit Meteor-M2 přenáší barevný obraz ve viditelné oblasti, přičemž je rozdělen na tři černobílé – každá barva je přenášena ve svém virtuálním kanálu jako samostatný paket, přičemž v jeho struktuře snímků je určité odchýlení od standardů.

Pole příznaku Operacional Control by mělo být indikátorem přítomnosti nebo nepřítomnosti pole Operacional Control v snímku telemetrie. Tyto 4 bajty na konci snímku slouží k udržení zpětné vazby při kontrole doručování snímků telecommands. O tom budeme hovořit později.

Čítače snímků hlavního a virtuálního kanálu jsou pole, která se zvyšují o jednu při odeslání každého snímku. Slouží jako ukazatel, že nebyl ztracen žádný snímek.

Status dat snímku telemetrie je dalších dva bajty příznaků a dat, z nichž si ukážeme pouze některé.

Pole příznaku sekundárního záhlaví (Secondary Header) by mělo být indikátorem přítomnosti nebo nepřítomnosti sekundárního záhlaví (Secondary Header) v snímku telemetrie.

Pokud se to přeje, lze k každému snímku přidat sekundární záhlaví a umístit tam jakákoliv data dle vlastního uvážení.

Pole ukazatele na první hlavičku (First Header Pointer) při hodnotě synchronizačního příznaku „1“ musí obsahovat binární reprezentaci pozice prvního oktetu prvního paketu v poli dat (Data Field) rámce telemetrie. Pozice se počítá od 0 vzestupně od začátku pole dat. Pokud v poli dat rámce telemetrie není začátek paketu, pak pole ukazatele na první hlavičku musí mít hodnotu v binární reprezentaci „11111111111“ (to může nastat, pokud se jeden dlouhý paket rozšiřuje přes více než jeden rámec).

Pokud se však v poli dat nachází prázdný paket (Idle Data), pak ukazatel na první hlavičku musí mít hodnotu v binární reprezentaci „11111111110“. Podle tohoto pole by měl přijímač provádět synchronizaci toku. Toto pole zaručuje obnovení synchronizace i v případě ztráty rámců.

To znamená, že paket může například začínat uprostřed 4. rámce a končit na začátku 20. rámce. Aby se našel jeho začátek, slouží právě toto pole. Pakety také mají hlavičku, ve které je uvedena jejich délka, takže při nalezení ukazatele na první hlavičku by měl zpracovatel úrovně kanálu tuto hlavičku přečíst, čímž určí, kde paket skončí.
Pokud je pole kontroly chyb přítomno, mělo by být obsaženo v každém rámci telemetrie pro daný fyzický kanál po celou misi.

Toto pole se vypočítává použitím metody CRC. Procedura by měla vzít n-16 bit rámce telemetrie a vložit výsledek výpočtu do posledních 16 bitů.

Telecommandy

Rámec telecommand má několik zásadních rozdílů. Mezi ně patří:

Jiná struktura hlaviček
Dynamická délka. To znamená, že délka rámce není pevně stanovena, jak je tomu u telemetrie, ale může se měnit v závislosti na přenášených paketech.
Mechanismus zajištění doručení paketů. To znamená, že CA musí po přijetí potvrdit správnost přijetí rámců nebo požádat o opětovný přenos od rámce, který mohl být přijat s neopravenou chybou.

Mnohá pole jsou nám již známa z hlavičky rámce telemetrie. Mají stejné určení, proto zde probereme pouze nová pole.

Jedno bitové pole pro obcházení by mělo být použito k řízení kontroly rámců na přijímači. Hodnota „0“ tohoto pole by měla znamenat, že tento rámec je typu A a jeho kontrola by měla probíhat podle FARM. Hodnota „1“ tohoto pole by měla informovat přijímač, že tento rámec je typu B a měl by obcházet kontrolu podle FARM.

Tento příznak informuje přijímač, zda má použít mechanismus potvrzování doručení rámců nazvaný FARM — Mechanismus přijetí a hlášení rámců.

Příznak řídicího příkazu by měl být použit k určení, zda pole dat nese příkaz nebo data. Pokud je příznak roven „0“, pole dat by mělo obsahovat data. Pokud je příznak roven „1“, pole dat by mělo obsahovat řídicí informace pro FARM.
FARM představuje konečný automat, jehož parametry lze nastavovat.

RSVD. SPARE – rezervované bity.

Zdá se, že CCSDS má na ně do budoucna plány a pro zpětnou kompatibilitu verzí protokolu si tyto bity rezervovali již v aktuálních verzích standardu.

Pole délky rámců by mělo obsahovat číslo ve formátu bitů, které je rovno délce rámce v oktetech minus jeden.

Pole dat rámce by mělo následovat bez mezer za hlavičkou a mělo by obsahovat celé číslo oktetů, které může mít maximální délku 1019 oktetů. Toto pole by mělo obsahovat buď blok dat rámce, nebo informace o řídicím příkazu. Blok dat rámce by měl obsahovat:

celé číslo oktetů uživatelských dat
hlavičku segmentu a za ní následující celé číslo oktetů uživatelských dat

Pokud je hlavička přítomna, blok dat by měl obsahovat Paket, množství Paketů nebo jeho část. Blok dat bez hlavičky nemůže obsahovat části Paketů, ale může obsahovat bloky dat vlastního formátu. Z toho vyplývá, že hlavička je potřebná, když se přenášený blok dat nevejde do jednoho rámce. Blok dat s hlavičkou se nazývá segment.

Pole příznaků o velikosti dva bity by mělo obsahovat:

„01“ — pokud první část dat je v bloku dat
„00“ — pokud prostřední část dat je v bloku dat
„10“ — pokud poslední část dat je v bloku dat
«11» — pokud nedojde k dělení a v bloku dat je umístěn celý jeden nebo více paketů.

Pole identifikátoru MAP musí obsahovat nuly, pokud nejsou použity MAP kanály.
Někdy 6 bitů vyhrazených pro virtuální kanály není dostatečné. 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.

FARM

Podívejme se podrobněji na mechanismus fungování systému kontroly doručování rámců. Tento systém předpokládá pouze práci s rámci telemetrie vzhledem k jejich důležitosti (telemetrii si lze vždy vyžádat znovu, ale KА musí jasně slyšet pozemní stanici a vždy se řídit jejími pokyny). Předpokládejme tedy, že jsme se rozhodli přeprogramovat naši družici a posíláme na její palubu binární soubor o velikosti 10 kilobajtů. Na kanálové úrovni je soubor rozdělen na 10 rámců (0, 1, …, 9), které jsou postupně odesílány nahoru. Když je přenos dokončen, KА musí potvrdit správnost přijetí paketu, nebo oznámit, na kterém rámci došlo k chybě. Tyto informace jsou odeslány do pole operativního řízení v nejbližším rámci telemetrie (A nebo KА může iniciovat přenos prázdného rámce (idle frame), pokud nemá co sdělit). Na základě přijaté telemetrie buď zjistíme, že je vše v pořádku, nebo začneme znovu odesílat zprávu. Předpokládejme, že družice neslyšela rámec č. 7. To znamená, že jí posíláme rámce 7, 8, 9. Pokud nedostaneme žádnou odpověď, paket se znovu posílá celý (a tak několikrát, dokud nezjistíme, že pokusy jsou marné).

Níže je uvedena struktura pole operativního řízení s popisem některých polí. Data obsažená v tomto poli se nazývají CLCW – Communication Link Control Word.

Jak je z obrázku možné vyvodit, účel hlavních polí je zřejmý, a na ostatní je nudné se dívat, skrývám podrobný popis pod spoiler.

Dekódování polí CLCWTyp kontrolního slova (Control Word Type):
Pro tento typ kontrolního slova by měl obsahovat 0.

Verze kontrolního slova (CLCW Version Number):
Pro tento typ kontrolního slova by měla být rovna «00» v bitovém zobrazení.

Pole stavu (Status Field):
Použití tohoto pole je určeno pro každou misi zvlášť. Může být použito pro místní zlepšení různými kosmickými agenturami.

Identifikátor virtuálního kanálu (Virtual Channel Identification):
Musí obsahovat identifikátor virtuálního kanálu, s nímž souvisí toto kontrolní slovo.

Příznak přístupu k fyzickému kanálu:
Příznak by měl poskytovat informace o připravenosti fyzické úrovně přijímače. Pokud fyzická úroveň přijímače není připravena k příjmu snímků, mělo by pole obsahovat "1", jinak "0".

Příznak selhání synchronizace:
Příznak může signalizovat, že fyzická úroveň pracuje při špatné úrovni signálu a počet odmítnutých snímků je příliš vysoký. Používání tohoto pole je volitelné, pokud je použito, mělo by obsahovat "0" při přítomnosti synchronizace, a "1" při její absenci.

Příznak blokace:
Tento bit by měl obsahovat stav blokace FARM pro každý virtuální kanál. Hodnota "1" v tomto poli by měla indikovat, že FARM je zablokován a snímky budou odmítány pro každý virtuální úroveň, jinak "0".

Příznak čekání:
Tento bit by měl být používán k indikaci toho, že přijímač nemůže zpracovat tento datový proud na určeném virtuálním kanálu. Hodnota "1" naznačuje, že všechny snímky budou odmítány na tomto virtuálním kanálu, jinak "0".

Příznak přeposlání:
Tento příznak by měl obsahovat "1", pokud byl odmítnut jeden nebo více snímků typu A nebo byly nalezeny ztráty, proto je třeba přeposlat. Příznak "0" naznačuje, že nebyly žádné odmítnuté snímky a ztráty.

Hodnota odpovědi:
Číslo snímku, který nebyl přijat. Určuje se podle čítače v hlavičce snímku telekomand.

Síťová úroveň

Trochu se dotkneme i této úrovně. Zde jsou možné dvě varianty: buď použít protokol kosmického balíčku, nebo zapouzdřit jakýkoli jiný protokol do balíčku CCSDS.

Přehled protokolu kosmického balíčku je tématem na samostatný článek. Byl vytvořen tak, aby takzvané aplikace mohly bezproblémově vyměňovat data. Každá aplikace má svou adresu a základní funkcionalitu pro výměnu dat s ostatními aplikacemi. Jsou zde také služby, které provádějí směrování provozu, kontrolují doručení atd.

S zapouzdřením je to jednodušší a srozumitelnější. Normy umožňují zapouzdřit do balíčků CCSDS jakékoli protokoly, přidáním další hlavičky.

Kde má hlavička různá významy v závislosti na délce zapouzdřeného protokolu:

Hlavním polem je délka délky. Může se pohybovat od 0 do 4 bytů. Také je v této hlavičce nutné uvést typ zapouzdřeného protokolu pomocí tabulky odsud.

Při zapouzdření IP se používá ještě další nadstavba, aby se určil typ paketu.
Je nutné přidat ještě jednu hlavičku o délce od jednoho oktetu:

Kde PID je další identifikátor protokolu, vzatý odsud

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 bylo možné vynechat. Opravdu, efektivita výsledného kanálu (až po síťovou úroveň) činí zhruba 40 %. Jakmile se však objeví potřeba implementace těchto standardů, stává se jasným, že každé pole, každá hlavička má svou důležitou misi, jejíž ignorování vede k celé řadě nejednoznačností.

Pokud se komunikační komunita projeví zájem o toto téma, budu rád, když zveřejním další články věnované teorii a praxi vesmírné komunikace. Děkuji za pozornost!