🥇Trochę o standardach komunikacji kosmicznej

Satelita Meteor M1
Źródło: vladtime.ru

Wprowadzenie

Eksploatacja technologii kosmicznej jest niemożliwa bez łączności radiowej, a w tym artykule postaram się wyjaśnić podstawowe założenia, które stały się fundamentem standardów opracowanych przez Międzynarodowy Komitet Doradczy ds. Systemów Przesyłania Danych w Kosmosie (Consultative Committee for Space Data Systems – CCSDS. W dalszej części artykułu używana będzie ta skrócona nazwa).

Niniejsza publikacja będzie głównie poświęcona warstwie kanałowej, jednak podstawowe pojęcia dotyczące innych warstw również zostaną przedstawione. Artykuł nie ma na celu pełnego i wyczerpującego opisu standardów. Można z nimi zapoznać się na stronie CCSDS. Niemniej jednak są one bardzo trudne do przyswojenia, a my poświęciliśmy sporo czasu, aby je zrozumieć, dlatego chciałbym przedstawić podstawowe informacje, które ułatwią zrozumienie wszystkich pozostałych. Zaczynajmy.

Szlachetna misja CCSDS

Możliwe, że ktoś zada sobie pytanie: po co wszystkim trzymać się standardów, skoro można opracować własny, proprietarny zestaw protokołów łączności radiowej (lub własny standard, z blackjackiem i nowymi funkcjami), tym samym zwiększając bezpieczeństwo systemu?

Jak pokazuje praktyka, korzystniej jest przestrzegać standardów CCSDS z kilku powodów:

W komisji odpowiedzialnej za publikację standardów zasiadają przedstawiciele wszystkich dużych agencji kosmicznych na świecie, wnosząc swoje bezcenne doświadczenie zdobyte przez lata projektowania i eksploatacji różnych misji. Ignorowanie tego doświadczenia i ponowne potykanie się o te same przeszkody byłoby bardzo nierozsądne.
Te standardy są wspierane przez już istniejący na rynku sprzęt stacji naziemnych.
W przypadku usuwania jakichkolwiek usterek zawsze można zwrócić się o pomoc do kolegów z innych agencji, aby przeprowadzili sesję łączności z urządzeniem ze swojej stacji naziemnej. Jak widać, standardy to niezbędny element, dlatego przyjrzyjmy się ich kluczowym aspektom.

Architektura

Standardy stanowią zbiór dokumentów odzwierciedlających zwykły model OSI (Open System Interconnection), z wyjątkiem tego, że na warstwie kanałowej wspólność ogranicza się do podziału na telemetrię (kanał 'w dół' – kosmos – Ziemia) i telekomendy (kanał 'w górę').

Przyjrzyjmy się szczegółowo niektórym poziomom, zaczynając od poziomu fizycznego i przesuwając się w górę. Dla lepszej przejrzystości rozważymy architekturę strony odbierającej. Strona nadająca jest jej lustrowym odbiciem.

Poziom fizyczny

Na tym poziomie następuje konwersja modulowanego sygnału radiowego na strumień bitów. Standardy tutaj mają głównie charakter zalecający, ponieważ na tym poziomie trudno jest abstrahować od konkretnej realizacji sprzętu. Kluczową rolą CCSDS jest określenie dopuszczalnych modulacji (BPSK, QPSK, 8-QAM itd.) oraz udzielenie pewnych wskazówek dotyczących realizacji mechanizmów synchronizacji symboli, kompensacji przesunięcia Dopplera itp.

Poziom synchronizacji i kodowania

Formalnie jest podpoziomem poziomu kanału, jednak często wyodrębnia się go jako osobny poziom ze względu na jego znaczenie w ramach standardów CCSDS. Poziom ten przekształca strumień bitów w tzw. ramki (telemetrii lub telekomend), o których opowiemy później. W odróżnieniu od synchronizacji symboli na poziomie fizycznym, która pozwala uzyskać poprawny strumień bitów, tutaj odbywa się synchronizacja ramek. Przyjrzyjmy się temu, jak dane przechodzą na tym poziomie (od dołu do góry):

Jednak przed tym warto powiedzieć kilka słów o kodowaniu. Procedura ta jest niezbędna do wykrywania i/lub poprawiania błędów bitowych, które nieuchronnie pojawiają się podczas przesyłania danych przez kanał radiowy. Nie będziemy tutaj rozważać procedur dekodowania, a jedynie uzyskamy informacje potrzebne do zrozumienia dalszej logiki działania poziomu.

Kody mogą być blokowe i ciągłe. Standardy nie wymuszają stosowania konkretnego typu kodowania, jednak musi ono występować. Kody ciągłe obejmują kody konwolucyjne. Dzięki nim kodowany jest ciągły strumień bitów. W przeciwieństwie do kodów blokowych, gdzie dane dzieli się na bloki kodowe i mogą być dekodowane tylko w ramach całych bloków. Blok kodowy reprezentuje przesyłane dane i dołączoną informacje redundantną, potrzebną do weryfikacji poprawności otrzymania danych i poprawiania możliwych błędów. Do kodów blokowych należą słynne kody Reed-Solomona.

Jeśli używane jest kodowanie konwolucyjne, strumień bitów na początku trafia do dekodera. Wynikiem jego pracy (wszystko to dzieje się oczywiście nieprzerwanie) są bloki danych CADU (jednostki dostępu do kanału). Ta struktura jest niezbędna do synchronizacji klatek. Na końcu każdego CADU dołączony jest znacznik synchronizacji (ASM – dołączony znacznik synchronizacji). To znane wcześniej 4 bajty, na podstawie których synchronizator znajduje początek i koniec CADU. Tak osiąga się synchronizację klatek.

Kolejny opcjonalny etap pracy na poziomie synchronizacji i kodowania związany jest z cechami działania poziomu fizycznego. To deryandomizacja. Polega to na tym, że dla osiągnięcia synchronizacji symboli potrzebne są częste przełączenia między symbolami. Tak więc, jeśli będziemy przekazywać, powiedzmy, kilobajt danych składających się wyłącznie z jedynek, synchronizacja zostanie utracona. Dlatego podczas transmisji dane wejściowe mieszają się z okresową sekwencją pseudolosową, aby gęstość zer i jedynek była równomierna.

Następnie zachodzi dekodowanie kodów blokowych, a to, co pozostanie, będzie finalnym produktem poziomu synchronizacji i kodowania – klatką.

Poziom kanałowy

Z jednej strony, procesor poziomu kanałowego odbiera klatki, a z drugiej strony wydaje pakiety. Ponieważ formalnie rozmiar pakietów nie jest ograniczony, do ich niezawodnego przesyłania konieczne jest dzielenie ich na mniejsze struktury – klatki. Tutaj omówimy dwa podrozdziały: oddzielnie dla telemetrii (TM) i telekomend (TC).

Telemetria

Mówiąc prościej, są to dane, które stacja naziemna otrzymuje od satelity. Cała przesyłana informacja dzielona jest na małe fragmenty o stałej długości – klatki, które zawierają dane przesyłane oraz pola pomocnicze. Przyjrzyjmy się szczegółowo strukturze klatki:

Zaczniemy od podstawowego nagłówka klatki telemetrii. Pozwolę sobie w niektórych miejscach po prostu tłumaczyć standardy, jednocześnie udzielając pewnych wyjaśnień.

Pole identyfikatora głównego kanału (Master Channel ID) powinno zawierać numer wersji klatki oraz identyfikator aparatu.

Każdy KA, zgodnie ze standardami CCSDS, musi mieć unikalny identyfikator, dzięki któremu można, mając ramkę, określić, do jakiego urządzenia należy. Formalnie konieczne jest złożenie wniosku o rejestrację urządzenia, a jego nazwa, wraz z identyfikatorem, zostanie opublikowana w otwartych źródłach. Jednak często rosyjscy producenci ignorują tę procedurę, przypisując urządzeniu dowolny identyfikator. Numer wersji ramki pomaga określić, która wersja standardów jest używana, aby prawidłowo odczytać ramkę. Tutaj omówimy tylko najbardziej konserwatywny standard z wersją „0”.

W polu identyfikatora wirtualnego kanału (Virtual Channel ID) powinien znajdować się VCID kanału, z którego nadeszła paczka. Nie ma żadnych ograniczeń co do wyboru VCID, w szczególności wirtualne kanały nie muszą być numerowane w sposób ciągły.

Bardzo często pojawia się potrzeba multipleksowania przesyłanych danych. W tym celu istnieje mechanizm wirtualnych kanałów. Na przykład, satelita Meteor-M2 przesyła kolorowy obraz w zakresie widzialnym, dzieląc go na trzy czarno-białe – każdy kolor jest przesyłany w swoim wirtualnym kanale jako oddzielna paczka, chociaż w strukturze jego ramek występuje pewne odchylenie od standardów.

Pole flagi sterowania operacyjnego powinno być wskaźnikiem obecności lub braku pola sterowania operacyjnego w ramce telemetrii. Te 4 bajty na końcu ramki służą do utrzymania informacji zwrotnej przy kontrolowaniu dostarczania ramek telekomend. O tym porozmawiamy nieco później.

Liczniki ramek głównego i wirtualnego kanału to pola, które zwiększają się o jeden przy wysyłaniu każdej ramki. Służą jako wskaźnik, że żadna ramka nie została utracona.

Status danych ramki telemetrii to kolejne dwa bajty flagów i danych, z których omówimy jedynie wybrane.

Pole flagi dodatkowego nagłówka (Secondary Header) powinno być wskaźnikiem obecności lub braku dodatkowego nagłówka (Secondary Header) w ramce telemetrii.

W razie potrzeby można dodać do każdej ramki dodatkowy nagłówek i umieścić tam dowolne dane według własnego uznania.

Wskaźnik na pierwszy nagłówek (First Header Pointer), przy wartości flagi synchronizacji „1”, powinien zawierać binarne przedstawienie pozycji pierwszego bajtu pierwszego pakietu w polu danych (Data Field) ramki telemetrii. Pozycja jest liczona od 0 w porządku rosnącym od początku pola danych. Jeżeli nie ma początku pakietu w polu danych ramki telemetrii, wskaźnik na pierwszy nagłówek powinien mieć wartość w binarnym przedstawieniu „11111111111” (może się to zdarzyć, jeśli jeden długi pakiet rozciąga się na więcej niż jedną ramkę).

Jeżeli pole danych zawiera pusty pakiet (Idle Data), wskaźnik na pierwszy nagłówek powinien mieć wartość w binarnym przedstawieniu „11111111110”. Na podstawie tego pola odbiornik powinien synchronizować strumień. To pole gwarantuje przywrócenie synchronizacji nawet w przypadku pominięcia ramek.

Oznacza to, że pakiet może, na przykład, zaczynać się w połowie 4. ramki i kończyć na początku 20. Aby znaleźć jego początek, to pole jest właśnie do tego służy. Pakiety również mają nagłówek, w którym zapisana jest ich długość, dlatego przy znajdowaniu wskaźnika na pierwszy nagłówek, procesor na poziomie łącza danych powinien go przeczytać, tym samym określając, gdzie zakończy się pakiet.
Jeżeli pole kontroli błędów jest obecne, powinno ono być zawarte w każdej ramce telemetrii dla konkretnego fizycznego kanału przez cały okres misji.

To pole oblicza się przy pomocy metody CRC. Procedura powinna przyjąć n-16 bitów ramki telemetrii i wstawić wynik obliczenia w ostatnie 16 bitów.

Telekomendy

Ramka telekomend ma kilka istotnych różnic. Wśród nich:

Inna struktura nagłówków
Dynamiczna długość. Oznacza to, że długość ramki nie jest określona sztywno, jak ma to miejsce w telemetrii, lecz może się zmieniać w zależności od przesyłanych pakietów.
Mechanizm gwarancji dostarczenia pakietów. Oznacza to, że KA po odebraniu musi potwierdzić poprawność odbioru ramek lub zażądać ponownej wysyłki od tej ramki, która mogła zostać odebrana z nieodwracalnym błędem.

Wiele pól jest już nam znanych z nagłówka ramki telemetrii. Mają one takie samo przeznaczenie, dlatego tutaj rozważymy tylko nowe pola.

Jeden bit flagu bypassu powinien być używany do kontroli weryfikacji ramek na odbiorniku. Wartość „0” tego flagu powinna wskazywać, że dana ramka jest ramką typu A, a jej weryfikacja powinna być przeprowadzana zgodnie z FARM. Wartość „1” tego flagu powinna informować odbiornik, że dana ramka jest ramką typu B i powinna pominąć weryfikację zgodnie z FARM.

Ten flag informuje odbiornik, czy należy użyć mechanizmu potwierdzania dostarczania ramek, który nazywa się FARM – Mechanizm Akceptacji i Raportowania Ram.

Flaga polecenia sterującego powinna być używana do określenia, czy pole danych transportuje komendę, czy dane. Jeśli flaga wynosi „0”, pole danych powinno zawierać dane. Jeśli flaga wynosi „1”, pole danych powinno zawierać informacje kontrolne dla FARM.
FARM to automat stanowy, którego parametry można konfigurować.

RSVD. SPARE – zarezerwowane bity.

Wygląda na to, że CCSDS ma na to plany w przyszłości, a dla zachowania zgodności z wersjami protokołu zarezerwowali te bity już w obecnych wersjach standardu.

Pole długości ramek powinno zawierać liczbę w postaci binarnej, która odpowiada długości ramki w oktetach minus jeden.

Pole danych ramki powinno znajdować się zaraz po nagłówku bez przerw i zawierać liczbę całkowitą oktetów, która może wynosić maksymalnie 1019 oktetów. To pole powinno zawierać albo blok danych ramki, albo informacje polecenia sterującego. Blok danych ramki powinien zawierać:

całkowitą liczbę oktetów danych użytkownika
nagłówek segmentu i następującą po nim całkowitą liczbę oktetów danych użytkownika

Jeśli nagłówek jest obecny, to blok danych powinien zawierać Pakiet, wiele Pakietów lub jego część. Blok danych bez nagłówka nie może zawierać części Pakietów, ale może zawierać bloki danych w formacie prywatnym. Oznacza to, że nagłówek jest wymagany, gdy przesyłany blok danych nie mieści się w jednej ramce. Blok danych mający nagłówek nazywa się segmentem.

Pole flag zawierające dwa bity powinno zawierać:

„01” — jeśli pierwsza część danych znajduje się w bloku danych
„00” — jeśli środkowa część danych znajduje się w bloku danych
„10” — jeśli ostatnia część danych znajduje się w bloku danych
„11” — jeśli nie ma podziału, a w bloku danych znajduje się cały jeden lub kilka pakietów.

Pole identyfikatora MAP powinno zawierać zera, jeśli kanały MAP nie są używane.
Czasami 6 bitów przeznaczonych na kanały wirtualne jest niewystarczające. Jeśli konieczne jest multiplikowanie danych na większą liczbę kanałów, wykorzystuje się dodatkowe 6 bitów z nagłówka segmentu.

FARM

Przyjrzyjmy się bliżej mechanizmowi działania systemu kontroli dostarczania ramki. System ten przewiduje tylko pracę z ramkami telekomend ze względu na ich istotność (telemetrię zawsze można zażądać ponownie, a KA musi wyraźnie słyszeć stację naziemną i zawsze stosować się do jej poleceń). Załóżmy, że postanowiliśmy przeprogramować nasz satelita i wysyłamy na jego pokład plik binarny o wielkości 10 kilobajtów. Na poziomie kanału plik jest dzielony na 10 ramek (0, 1, …, 9), które są kolejno wysyłane w górę. Po zakończeniu transmisji KA musi potwierdzić poprawność odbioru pakietu lub zgłosić, na której ramce wystąpił błąd. Informacja ta jest wysyłana w polu operacyjnej kontroli w najbliższej ramce telemetrii (lub KA może zainicjować przesyłanie pustej ramki (idle frame), jeśli nie ma nic do powiedzenia). Na podstawie uzyskanej telemetrii albo upewniamy się, że wszystko jest w porządku, albo przystępujemy do ponownego przesyłania komunikatu. Załóżmy, że satelita nie usłyszał ramki nr 7. W takim razie wysyłamy mu ramki 7, 8, 9. Jeśli nie otrzymamy odpowiedzi, pakiet jest wysyłany w całości jeszcze raz (i tak kilka razy, aż zrozumiemy, że próby są daremne).

Poniżej przedstawiona jest struktura pola operacyjnej kontroli z opisem niektórych pól. Dane zawarte w tym polu nazywają się CLCW – Communication Link Control Word.

Jak można zgadnąć po obrazku, główne pola mają swoje przeznaczenie, a inne są nudne, więc szczegółowy opis ukrywam pod spoilerem.

Rozszyfrowanie pól CLCWTyp kontrolnego słowa (Control Word Type):
Dla tego typu kontrolnego słowa powinien zawierać 0.

Wersja kontrolnego słowa (CLCW Version Number):
Dla tego typu kontrolnego słowa powinna być równa "00" w postaci bitowej.

Pole statusu (Status Field):
Wykorzystanie tego pola jest określane dla każdej misji oddzielnie. Może być wykorzystywane do lokalnych ulepszeń przez różne agencje kosmiczne.

Identyfikator kanału wirtualnego (Virtual Channel Identification):
Powinien zawierać identyfikator kanału wirtualnego, do którego to kontrolne słowo jest przypisane.

Flaga dostępu do kanału fizycznego:
Flaga powinna dostarczać informacji o gotowości fizycznego poziomu odbiornika. Jeśli fizyczny poziom odbiornika nie jest gotowy do odbioru ramek, pole powinno zawierać „1”, w przeciwnym razie „0”.

Flaga błędu synchronizacji:
Flaga może przesyłać informację, że fizyczny poziom działa przy słabym poziomie sygnału i liczba odrzuconych ramek jest zbyt wysoka. Użycie tego pola jest opcjonalne, jeśli jest używane, powinno zawierać „0” przy obecności synchronizacji i „1” przy jej braku.

Flaga blokady:
Ten bit powinien zawierać status blokady FARM dla każdego kanału wirtualnego. Wartość „1” w tym polu powinna wskazywać, że FARM jest zablokowany i ramki będą odrzucane dla każdego wirtualnego poziomu, w przeciwnym razie „0”.

Flaga oczekiwania:
Ten bit powinien być używany do wskazania, że odbiornik nie może przetworzyć danych na wskazanym wirtualnym kanale. Wartość „1” oznacza, że wszystkie ramki będą odrzucane na tym wirtualnym kanale, w przeciwnym razie „0”.

Flaga przekazywania:
Ta flaga powinna zawierać „1”, jeśli jedna lub więcej ramek typu A została odrzucona lub wykryto braki, dlatego konieczne jest przekazywanie. Flaga „0” oznacza, że nie było odrzuconych ramek ani braków.

Wartość odpowiedzi:
Numer ramki, która nie została przyjęta. Określane na podstawie licznika w nagłówku ramki telekomendy.

Poziom sieciowy

Nieco dotkniemy także tego poziomu. Są dwa warianty: albo użyć protokołu pakietu kosmicznego, albo enkapsulować dowolny inny protokół w pakiet CCSDS.

Przegląd protokołu pakietu kosmicznego to temat na osobny artykuł. Został stworzony, aby umożliwić tak zwanym aplikacjom bezproblemową wymianę danych. Każda aplikacja ma swój adres oraz podstawowe funkcje wymiany danych z innymi aplikacjami. Są także usługi, które realizują trasowanie ruchu, kontrolę dostawy itd.

Z enkapsulacją jest prościej i jasniej. Standardy pozwalają na enkapsulację w pakietach CCSDS dowolnych protokołów, dodając dodatkowy nagłówek.

Gdzie nagłówek ma różne znaczenia w zależności od długości protokołu enkapsulującego:

Główne pole to długość długości. Może się wahać od 0 do 4 bajtów. W tym nagłówku należy również podać typ protokołu enkapsulującego za pomocą tabeli stąd.

Podczas enkapsulacji IP używana jest jeszcze jedna nakładka, aby określić typ pakietu.
Należy dodać jeszcze jeden nagłówek o długości od jednego oktetu:

Gdzie PID to kolejny identyfikator protokołu, pobrany stąd

Podsumowanie

Na pierwszy rzut oka wydaje się, że nagłówki CCSDS są niezwykle nadmiarowe, a niektóre pola można by pominąć. Rzeczywiście, efektywność resulting channel (do poziomu sieciowego) wynosi około 40%. Jednak gdy tylko pojawi się potrzeba wdrożenia tych standardów, staje się jasne, że każde pole, każdy nagłówek ma swoje ważne zadanie, ignorowanie którego prowadzi do szeregu niejednoznaczności.

Jeśli społeczność Habr wykazuje zainteresowanie tym tematem, z przyjemnością opublikuję jeszcze szereg artykułów poświęconych teorii i praktyce komunikacji kosmicznej. Dziękuję za uwagę!