Satelita Meteor M1
Źródło: vladtime.ru
Wprowadzenie
Działanie technologii kosmicznej nie jest możliwe bez komunikacji radiowej, dlatego w tym artykule postaram się wyjaśnić główne idee, które stały się podstawą standardów opracowanych przez Międzynarodowy Komitet Doradczy ds. Systemów Danych Kosmicznych (CCSDS. Skrót ten będzie używany poniżej) .
W tym poście skupimy się przede wszystkim na warstwie łącza danych, ale zostaną wprowadzone także podstawowe pojęcia dotyczące innych warstw. Artykuł ten w żaden sposób nie stanowi dokładnego i pełnego opisu standardów. Można go obejrzeć pod adresem CCSDS. Są one jednak bardzo trudne do zrozumienia i spędziliśmy dużo czasu próbując je zrozumieć, więc tutaj chcę podać podstawowe informacje, dzięki którym znacznie łatwiej będzie zrozumieć wszystko inne. Zacznijmy więc.
Szlachetna Misja CCSDS
Być może ktoś ma pytanie: po co każdy miałby trzymać się standardów, skoro można opracować własny, autorski stos protokołów radiowych (lub własny standard, z blackjackem i nowymi funkcjami), zwiększając w ten sposób bezpieczeństwo systemu?
Jak pokazuje praktyka, bardziej opłaca się przestrzegać standardów CCSDS z następujących powodów:
- W skład komitetu odpowiedzialnego za publikację standardów wchodzą przedstawiciele wszystkich liczących się agencji lotniczych i kosmicznych na świecie, wnosząc bezcenne doświadczenie zdobyte przez wiele lat projektowania i obsługi różnych misji. Zignorowanie tego doświadczenia i ponowne nadepnięcie na ich grabie byłoby bardzo absurdalne.
- Standardy te są obsługiwane przez urządzenia stacji naziemnych już dostępne na rynku.
- Podczas rozwiązywania problemów zawsze możesz zwrócić się o pomoc do kolegów z innych agencji, aby mogli przeprowadzić sesję komunikacyjną z urządzeniem ze swojej stacji naziemnej. Jak widać standardy są niezwykle przydatną rzeczą, dlatego przyjrzyjmy się ich kluczowym punktom.
Architektura
Standardy stanowią zbiór dokumentów odzwierciedlających najpopularniejszy model OSI (Open System Interconnection), z tą różnicą, że na poziomie łącza danych podobieństwo ogranicza się do podziału na telemetrię (downlink – przestrzeń – Ziemia) i telekomendacje (uplink).
Przyjrzyjmy się niektórym poziomom bardziej szczegółowo, zaczynając od fizycznego i przechodząc w górę. Dla większej przejrzystości rozważymy architekturę strony odbiorczej. Ten nadawczy jest jego lustrzanym odbiciem.
Warstwa fizyczna
Na tym poziomie zmodulowany sygnał radiowy jest przetwarzany na strumień bitów. Standardy mają tu głównie charakter doradczy, gdyż na tym poziomie trudno abstrahować od konkretnej implementacji sprzętu. Tutaj kluczową rolą CCSDS jest zdefiniowanie akceptowalnych modulacji (BPSK, QPSK, 8-QAM itp.) i podanie pewnych zaleceń dotyczących implementacji mechanizmów synchronizacji symboli, kompensacji Dopplera itp.
Poziom synchronizacji i kodowania
Formalnie jest to podwarstwa warstwy łącza danych, ale często jest wydzielona na odrębną warstwę ze względu na jej znaczenie w standardach CCSDS. Warstwa ta konwertuje strumień bitów na tzw. ramki (telemetrię lub telepolecenia), o czym porozmawiamy później. W przeciwieństwie do synchronizacji symboli w warstwie fizycznej, która pozwala na uzyskanie prawidłowego strumienia bitów, tutaj odbywa się synchronizacja klatek. Rozważ ścieżkę, jaką podążają dane na tym poziomie (od dołu do góry):
Zanim jednak to nastąpi, warto powiedzieć kilka słów o kodowaniu. Ta procedura jest konieczna, aby znaleźć i/lub skorygować błędy bitowe, które nieuchronnie występują podczas przesyłania danych kanałem radiowym. Tutaj nie będziemy rozważać procedur dekodowania, a jedynie uzyskamy informacje niezbędne do zrozumienia dalszej logiki poziomu.
Kody mogą być blokowe lub ciągłe. Standardy nie narzucają stosowania określonego typu kodowania, ale jako takie musi ono występować. Kody ciągłe obejmują kody splotowe. Służą do kodowania ciągłego strumienia bitów. Inaczej jest w przypadku kodów blokowych, gdzie dane są podzielone na bloki kodu i mogą być dekodowane jedynie w ramach całych bloków. Blok kodu reprezentuje przesyłane dane i załączoną do nich nadmiarową informację niezbędną do sprawdzenia poprawności otrzymanych danych i skorygowania ewentualnych błędów. Kody blokowe obejmują słynne kody Reeda-Solomona.
Jeśli stosowane jest kodowanie splotowe, strumień bitów wchodzi do dekodera od początku. Efektem jego pracy (wszystko to oczywiście dzieje się w sposób ciągły) są bloki danych CADU (channel access data unit). Struktura ta jest niezbędna do synchronizacji ramek. Na końcu każdego CADU znajduje się generator synchronizacji (ASM). Są to 4 znane z góry bajty, dzięki którym synchronizator znajduje początek i koniec CADU. W ten sposób osiągana jest synchronizacja klatek.
Kolejny opcjonalny etap warstwy synchronizacji i kodowania jest związany ze specyfiką warstwy fizycznej. To jest derandomizacja. Faktem jest, że aby osiągnąć synchronizację symboli, konieczne jest częste przełączanie pomiędzy symbolami. Jeśli więc prześlemy, powiedzmy, kilobajt danych składający się wyłącznie z jedynek, synchronizacja zostanie utracona. Dlatego podczas transmisji dane wejściowe są mieszane z okresową sekwencją pseudolosową, dzięki czemu gęstość zer i jedynek jest jednolita.
Następnie kody blokowe są dekodowane i pozostaje końcowy produkt poziomu synchronizacji i kodowania – ramka.
Warstwa łącza danych
Z jednej strony procesor warstwy łącza odbiera ramki, a z drugiej wysyła pakiety. Ponieważ wielkość pakietów nie jest formalnie ograniczona, dla ich niezawodnej transmisji konieczne jest rozbicie ich na mniejsze struktury - ramki. Tutaj przyjrzymy się dwóm podsekcjom: oddzielnie dla telemetrii (TM) i telepoleceń (TC).
Telemetria
Mówiąc najprościej, są to dane, które stacja naziemna otrzymuje od statku kosmicznego. Wszystkie przesyłane informacje dzielone są na małe fragmenty o ustalonej długości – ramki zawierające przesyłane dane i pola usług. Przyjrzyjmy się bliżej konstrukcji ramy:
Zacznijmy nasze rozważania od głównego nagłówka ramki telemetrycznej. Ponadto w niektórych miejscach pozwolę sobie po prostu przetłumaczyć standardy, podając przy okazji pewne wyjaśnienia.
Pole Master Channel ID musi zawierać numer wersji ramki oraz identyfikator urządzenia.
Każdy statek kosmiczny, zgodnie ze standardami CCSDS, musi posiadać swój własny, unikalny identyfikator, dzięki któremu mając ramkę, można 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 rosyjscy producenci często ignorują tę procedurę, przypisując urządzeniu dowolny identyfikator. Numer wersji ramki pomaga określić, która wersja standardów jest używana w celu prawidłowego odczytania ramki. Tutaj rozważymy tylko najbardziej konserwatywny standard z wersją „0”.
Pole Virtual Channel ID musi zawierać VCID kanału, z którego przyszedł pakiet. Nie ma ograniczeń co do wyboru VCID, w szczególności kanały wirtualne nie muszą być numerowane sekwencyjnie.
Bardzo często zachodzi potrzeba multipleksowania przesyłanych danych. W tym celu istnieje mechanizm kanałów wirtualnych. Przykładowo satelita Meteor-M2 transmituje obraz kolorowy w zakresie widzialnym, dzieląc go na trzy czarno-białe – każdy kolor transmitowany jest w swoim własnym wirtualnym kanale w osobnym pakiecie, choć występują pewne odstępstwa od standardów w konstrukcję swoich ram.
Pole flagi Kontroli Operacyjnej będzie wskaźnikiem obecności lub braku pola Kontroli Operacyjnej w ramce telemetrycznej. Te 4 bajty na końcu ramki służą do zapewnienia informacji zwrotnej podczas kontrolowania dostarczania ramek telepoleceń. Porozmawiamy o nich nieco później.
Liczniki ramek kanału głównego i wirtualnego to pola, które są zwiększane o jeden przy każdym wysłaniu ramki. Służy jako wskaźnik, że ani jedna klatka nie została utracona.
Status danych ramki telemetrycznej to kolejne dwa bajty flag i danych, z których przyjrzymy się tylko kilku.
Pole flagi nagłówka dodatkowego musi wskazywać obecność lub brak nagłówka dodatkowego w ramce telemetrycznej.
Jeśli chcesz, możesz dodać do każdej ramki dodatkowy nagłówek i umieścić tam dowolne dane według własnego uznania.
Pole wskaźnika pierwszego nagłówka, gdy flaga synchronizacji jest ustawiona na „1”, będzie zawierać binarną reprezentację pozycji pierwszego oktetu pierwszego pakietu w polu danych ramki telemetrycznej. Pozycja jest liczona od 0 w kolejności rosnącej od początku pola danych. Jeżeli w polu danych ramki telemetrycznej nie ma początku pakietu, to wskaźnik do pierwszego pola nagłówka musi mieć wartość w reprezentacji binarnej „11111111111” (może się tak zdarzyć, jeśli jeden długi pakiet jest rozłożony na więcej niż jedną ramkę ).
Jeżeli pole danych zawiera pusty pakiet (Idle Data), wówczas wskaźnik do pierwszego nagłówka powinien mieć wartość w reprezentacji binarnej „11111111110”. Korzystając z tego pola, odbiorca musi zsynchronizować strumień. To pole zapewnia przywrócenie synchronizacji nawet w przypadku utraty klatek.
Oznacza to, że pakiet może, powiedzmy, zaczynać się w środku czwartej ramki i kończyć na początku dwudziestej. To pole służy do znalezienia jego początku. Pakiety mają również nagłówek określający jego długość, więc gdy zostanie znaleziony wskaźnik do pierwszego nagłówka, procesor warstwy łącza musi go odczytać, ustalając w ten sposób, gdzie zakończy się pakiet.
Jeśli obecne jest pole kontroli błędów, musi ono być zawarte w każdej ramce telemetrycznej dla określonego kanału fizycznego podczas całej misji.
Pole to obliczane jest metodą CRC. Procedura musi pobrać n-16 bitów ramki telemetrycznej i wstawić wynik obliczeń do ostatnich 16 bitów.
Zespoły telewizyjne
Ramka poleceń telewizora ma kilka istotnych różnic. Pomiędzy nimi:
- Inna struktura nagłówków
- Długość dynamiczna. Oznacza to, że długość ramki nie jest ustalona sztywno, jak ma to miejsce w telemetrii, ale może się różnić w zależności od przesyłanych pakietów.
- Mechanizm gwarancji dostarczenia pakietu. Oznacza to, że statek kosmiczny po jej odebraniu musi potwierdzić poprawność odbioru ramki lub zażądać przesłania ramki, która mogła zostać odebrana z niemożliwym do naprawienia błędem.
Wiele pól znamy już z nagłówka ramki telemetrycznej. Mają ten sam cel, więc tutaj rozważymy tylko nowe pola.
Jeden bit flagi obejścia musi zostać użyty do kontrolowania sprawdzania ramki w odbiorniku. Wartość „0” dla tej flagi wskazuje, że ramka jest ramką typu A i musi zostać zweryfikowana zgodnie z FARM. Wartość „1” dla tej flagi powinna wskazywać odbiornikowi, że dana ramka jest ramką typu B i powinna ominąć sprawdzanie FARM.
Flaga ta informuje odbiorcę, czy ma używać mechanizmu potwierdzania dostarczenia ramki zwanego FARM – Mechanizm akceptacji i raportowania ramki.
Aby zrozumieć, czy pole danych przesyła polecenie, czy dane, należy użyć flagi polecenia sterującego. Jeśli flaga ma wartość „0”, wówczas pole danych musi zawierać dane. Jeśli flaga ma wartość „1”, wówczas pole danych musi zawierać informacje sterujące dla FARM.
FARM jest maszyną o skończonych stanach, której parametry można konfigurować.
RSVD. SPARE – bity zarezerwowane.
Wygląda na to, że CCSDS ma plany co do nich na przyszłość i dla kompatybilności wstecznej wersji protokołów zarezerwowali te bity już w obecnych wersjach standardu.
Pole długości ramki musi zawierać liczbę w reprezentacji bitowej równą długości ramki w oktetach minus jeden.
Pole danych ramki musi następować po nagłówku bez spacji i zawierać całkowitą liczbę oktetów, która może mieć maksymalnie 1019 oktetów. To pole musi zawierać albo blok danych ramki, albo informację o poleceniu sterującym. Blok danych ramki musi zawierać:
- całkowita liczba oktetów danych użytkownika
- nagłówek segmentu, po którym następuje całkowita liczba oktetów danych użytkownika
Jeśli występuje nagłówek, wówczas blok danych musi zawierać pakiet, zestaw pakietów lub część pakietu. Blok danych bez nagłówka nie może zawierać części pakietów, ale może zawierać bloki danych w formacie prywatnym. Wynika z tego, że nagłówek jest wymagany, gdy transmitowany blok danych nie mieści się w jednej ramce. Blok danych posiadający nagłówek nazywany jest segmentem
Pole flag dwubitowych musi 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 w bloku danych znajduje się ostatnia część danych
- „11” - jeśli nie ma podziału i jeden lub więcej pakietów mieści się w całości w bloku danych.
Pole MAP ID musi zawierać zera, jeśli kanały MAP nie są używane.
Czasami 6 bitów przydzielonych kanałom wirtualnym nie wystarczy. A jeśli konieczne jest multipleksowanie danych na większą liczbę kanałów, wykorzystywanych jest kolejnych 6 bitów z nagłówka segmentu.
GOSPODARSTWO ROLNE
Przyjrzyjmy się bliżej mechanizmowi działania systemu kontroli dowozu personelu. System ten przewiduje pracę jedynie z ramkami poleceń zdalnych ze względu na ich znaczenie (telemetrię zawsze można zażądać ponownie, a statek kosmiczny musi wyraźnie słyszeć stację naziemną i zawsze wykonywać jej polecenia). Załóżmy więc, że zdecydujemy się na ponowne flashowanie naszego satelity i wyślemy do niego plik binarny o rozmiarze 10 kilobajtów. Na poziomie łącza plik jest dzielony na 10 ramek (0, 1, ..., 9), które są przesyłane jedna po drugiej w górę. Po zakończeniu transmisji satelita musi potwierdzić poprawność odbioru pakietu lub zgłosić, na której ramce wystąpił błąd. Informacje te są przesyłane do pola kontroli operacyjnej w najbliższej ramce telemetrycznej (lub statek kosmiczny może zainicjować transmisję bezczynnej ramki, jeśli nie ma nic do powiedzenia). Na podstawie otrzymanej telemetrii albo upewniamy się, że wszystko jest w porządku, albo przystępujemy do ponownego wysłania wiadomości. Załóżmy, że satelita nie usłyszał ramki nr 7. Oznacza to, że wysyłamy mu ramki 7, 8, 9. W przypadku braku odpowiedzi cały pakiet zostaje wysłany ponownie (i tak kilka razy, aż zorientujemy się, że próby są daremne).
Poniżej znajduje się struktura pola kontroli operacyjnej wraz z opisem niektórych pól. Dane zawarte w tym polu nazywane są CLCW – Słowo Sterujące Łączem Komunikacyjnym.
Ponieważ z obrazka łatwo domyślić się przeznaczenia głównych pól, a oglądanie pozostałych jest nudne, szczegółowy opis ukrywam pod spoilerem
Objaśnienie pól CLCWTyp słowa sterującego:
W przypadku tego typu słowo kontrolne musi zawierać 0
Wersja słowa sterującego (numer wersji CLCW):
W przypadku tego typu słowo sterujące musi być równe „00” w reprezentacji bitowej.
Pole stanu:
Wykorzystanie tego pola ustalane jest dla każdej misji odrębnie. Może być stosowany do lokalnych ulepszeń przez różne agencje kosmiczne.
Identyfikacja kanału wirtualnego:
Musi zawierać identyfikator kanału wirtualnego, z którym jest powiązane to słowo kontrolne.
Flaga dostępu do kanału fizycznego:
Flaga musi informować o gotowości warstwy fizycznej odbiornika. Jeżeli warstwa fizyczna odbiornika nie jest gotowa do odbioru ramek, wówczas pole musi zawierać „1”, w przeciwnym razie „0”.
Flaga niepowodzenia synchronizacji:
Flaga może wskazywać, że warstwa fizyczna działa na słabym poziomie sygnału i liczba odrzuconych ramek jest zbyt duża. Użycie tego pola jest opcjonalne, jeżeli jest używane, musi zawierać „0”, jeśli synchronizacja jest dostępna, i „1”, jeśli nie jest.
Flaga blokująca:
Bit ten będzie zawierał stan blokady FARM dla każdego kanału wirtualnego. Wartość „1” w tym polu powinna wskazywać, że FARM jest wyłączona i ramki będą odrzucane dla każdej warstwy wirtualnej, w przeciwnym razie „0”.
Flaga oczekiwania:
Bit ten będzie używany do wskazania, że odbiornik nie może przetwarzać danych na określonym kanale wirtualnym. Wartość „1” oznacza, że wszystkie ramki zostaną odrzucone na tym kanale wirtualnym, w przeciwnym razie „0”.
Flaga do przodu:
Flaga ta będzie zawierać cyfrę „1”, jeśli odrzucono jedną lub więcej ramek typu A lub znaleziono luki, w związku z czym konieczne jest ponowne wysłanie. Flaga „0” wskazuje, że nie było żadnych porzuconych ani pominiętych klatek.
Wartość odpowiedzi:
Numer ramki, który nie został odebrany. Określane przez licznik w nagłówku ramki telepoleceń
Warstwa sieci
Dotknijmy trochę tego poziomu. Istnieją dwie możliwości: albo użyć protokołu pakietu kosmicznego, albo zawrzeć dowolny inny protokół w pakiecie CCSDS.
Przegląd protokołu pakietów kosmicznych to temat na osobny artykuł. Został zaprojektowany, aby umożliwić tzw. aplikacjom płynną wymianę danych. Każda aplikacja ma swój własny adres i podstawową funkcjonalność wymiany danych z innymi aplikacjami. Istnieją również usługi, które kierują ruchem, kontrolują dostarczanie itp.
Dzięki enkapsulacji wszystko jest prostsze i wyraźniejsze. Standardy umożliwiają enkapsulację dowolnych protokołów w pakietach CCSDS poprzez dodanie dodatkowego nagłówka.
Gdzie nagłówek ma różne znaczenia w zależności od długości enkapsulowanego protokołu:
Tutaj głównym polem jest długość długości. Może wynosić od 0 do 4 bajtów. Również w tym nagłówku należy wskazać typ protokołu enkapsulowanego, korzystając z tabeli .
Enkapsulacja IP wykorzystuje inny dodatek do określenia typu pakietu.
Musisz dodać jeszcze jeden nagłówek o długości jednego oktetu:
Gdzie PID jest kolejnym pobranym identyfikatorem protokołu
wniosek
Na pierwszy rzut oka może się wydawać, że nagłówki CCSDS są niezwykle redundantne i niektóre pola można pominąć. Rzeczywiście wydajność powstałego kanału (do poziomu sieci) wynosi około 40%. Jednak gdy tylko pojawi się potrzeba wdrożenia tych standardów, staje się jasne, że każda dziedzina, każdy nagłówek ma swoją ważną misję, której ignorowanie prowadzi do szeregu niejasności.
Jeśli środowisko habrasowe wykaże zainteresowanie tym tematem, z przyjemnością opublikuję całą serię artykułów poświęconych teorii i praktyce komunikacji kosmicznej. Dziękuję za uwagę!
Źródła informacji
PS
Nie uderzaj zbyt mocno, jeśli znajdziesz jakieś nieścisłości. Zgłoś je, a zostaną naprawione :)
Źródło: www.habr.com