🥇Puțin despre standardele comunicațiilor spațiale

Satelit Meteor M1
Sursă: vladtime.ru

Introducere

Exploatarea tehnicii spațiale nu este posibilă fără comunicații radio, iar în acest articol voi încerca să explic ideile de bază care au stat la baza standardelor dezvoltate de Comitetul Consultativ Internațional pentru Sistemele Spațiale de Transmisie a Datelor (Consultative Committee for Space Data Systems – CCSDS. Această abreviere va fi utilizată în continuare).

Această publicație va fi dedicată în principal nivelului de canal, totuși conceptele de bază pentru celelalte niveluri vor fi, de asemenea, introduse. Articolul nu își propune în niciun fel să pretindă o descriere completă și detaliată a standardelor. Acestea pot fi studiate pe site CCSDS. Cu toate acestea, ele sunt foarte dificil de înțeles, iar pentru a le înțelege am petrecut mult timp, așa că aici vreau să prezint informații de bază, având care va fi mult mai ușor să înțelegem restul. Așadar, să începem.

Misiunea nobilă CCSDS

Poate că unii s-ar putea întreba: de ce ar trebui să ne supunem standardelor, dacă putem dezvolta propriul nostru stivă proprietară de protocoale de comunicație radio (sau propriul standard, cu blackjack și funcții noi), crescând astfel securitatea sistemului?

Așa cum arată practica, este mai avantajos să respectăm standardele CCSDS din următoarele motive:

Comitetul responsabil pentru publicarea standardelor include reprezentanți de la toate agențiile aerospațiale majore din lume, aducându-și experiența prețioasă acumulată pe parcursul multor ani de proiectare și operare a diferitelor misiuni. Ar fi foarte absurd să ignorăm această experiență și să călcăm din nou pe aceeași greblă.
Aceste standarde sunt susținute de echipamentele deja existente pe piața stațiilor terestre.
În cazul rezolvării unor probleme, este întotdeauna posibil să solicităm ajutor colegilor din alte agenții pentru a efectua o sesiune de comunicare cu aparatul de la stația lor terestră. Așa cum vezi, standardele sunt extrem de utile, așa că să analizăm aspectele lor cheie.

Arhitectură

Standarde reprezintă un ansamblu de documente, care reflectă modelul normal OSI (Open System Interconnection), cu excepția faptului că la nivelul canalului, comunitatea se limitează la împărțirea în telemetrie (canal „în jos” - spațiu - Pământ) și telecomenzi (canal „în sus”).

Să discutăm despre unele niveluri mai în detaliu, începând cu cel fizic și continuând cu cele superioare. Pentru o mai bună ilustrație, ne vom concentra asupra arhitecturii părții receptor. Partea transmisă reprezintă reflexia sa în oglindă.

Nivelul fizic

La acest nivel are loc conversia semnalului radio modulată într-un flux de biți. Standardele de aici sunt în principal de recomandare, deoarece este dificil să ne abatem de la realizarea specifică a hardware-ului. Rolul esențial al CCSDS este de a defini modulațiile acceptabile (BPSK, QPSK, 8-QAM etc.) și de a oferi unele recomandări privind implementarea mecanismelor de sincronizare simbolică, compensarea deplasării Doppler etc.

Nivelul de sincronizare și codificare

Este formal un subnivel al nivelului de canal, însă, adesea, este evidențiat ca un nivel separat datorită importanței sale în cadrul standardelor CCSDS. Acest nivel convertește fluxul de biți în așa-numitele cadre (telemetrie sau telecomenzi), despre care vom discuta mai târziu. Spre deosebire de sincronizarea simbolică la nivel fizic, care permite obținerea unui flux de biți corect, aici se realizează sincronizarea cadrelor. Să analizăm parcursul pe care datele îl fac la acest nivel (de jos în sus):

Cu toate acestea, înainte de aceasta, merită spus câteva cuvinte despre codificare. Această procedură este necesară pentru a identifica și/sau corecta erorile de biți, care apar inevitabil în timpul transmisiei datelor prin canalul radio. Nu ne vom axa pe procedurile de decodare aici, ci doar vom obține informațiile necesare pentru a înțelege logica ulterioară a funcționării acestui nivel.

Codurile pot fi blocate sau continue. Standardele nu impun utilizarea unui anumit tip de codificare, însă aceasta trebuie să existe. Codurile continue se referă la codurile convoluționale. Acestea codifică un flux de biți continuu. Spre deosebire de codurile blocate, unde datele sunt împărțite în blocuri de cod (codeblocks) și pot fi decodificate doar în cadrul blocurilor complete. Un bloc de cod reprezintă datele transmise și informațiile redundante atașate, necesare pentru verificarea corectitudinii primirii datelor și corectarea posibilelor erori. Codurile blocate includ celebrele coduri Reed-Solomon.

Dacă se utilizează codificarea convoluțională, fluxul de biți de la început ajunge la decodor. Rezultatul muncii sale (toate acestea, desigur, se întâmplă continuu) sunt blocuri de date CADU (unitate de acces la datele canalului). Această structură este necesară pentru sincronizarea cadrelor. La sfârșitul fiecărui CADU este atașat un marker de sincronizare (ASM - marker de sincronizare atașat). Acestea sunt 4 octeți cunoscuți anterior, pe baza cărora sincronizatorul găsește începutul și sfârșitul CADU. Astfel se realizează sincronizarea cadrelor.

Următoarea etapă opțională a procesului de sincronizare și codificare este legată de specificul funcționării nivelului fizic. Aceasta este deraandomizarea. Problema este că pentru a obține sincronizarea simbolică sunt necesare schimbări frecvente între simboluri. Astfel, dacă vom transmite, de exemplu, un kilobyte de date constând exclusiv din biți de 1, sincronizarea va fi pierdută. Prin urmare, în timpul transmiterii, datele de intrare sunt amestecate cu o secvență pseudoaleatorie periodică, pentru ca densitatea de zerouri și unități să fie uniformă.

Apoi are loc decodarea codurilor pe blocuri, iar ceea ce rămâne va fi produsul final al nivelului de sincronizare și codificare - un cadru.

Nivelul canalului

Pe de o parte, procesorul nivelului canalului primește cadre, iar pe de altă parte, emite pachete. Deoarece dimensiunea pachetelor nu este formal limitată, pentru a le trimite în siguranță este necesar să le împărțim în structuri mai mici - cadre. Aici vom analiza două subsecțiuni: separat pentru telemetrie (TM) și telecomenzi (TC).

Telemetrie

Pe scurt, acestea sunt datele pe care stația terestră le primește de la satelit. Toate informațiile transmise sunt împărțite în fragmente mici de lungime fixă - cadre, care conțin datele transmise și câmpuri de control. Să analizăm mai în detaliu structura cadrului:

Și vom începe analiza cu antetul principal al cadrului de telemetrie. Ulterior, îmi voi permite să traduc standardele în unele locuri, oferind în același timp câteva explicații.

Câmpul identificatorului canalului principal (Master Channel ID) trebuie să conțină numărul versiunii cadrului și identificatorul aparatului.

Fiecare KA, conform standardelor CCSDS, trebuie să aibă un identificator unic, care să permită, având cadru, să se stabilească la ce aparat aparține. Formal, este necesar să se depună o solicitare pentru înregistrarea aparatului, iar denumirea acestuia, împreună cu identificatorul, va fi publicată în surse deschise. Totuși, adesea, producătorii ruși ignoră această procedură, atribuind aparatului un identificator aleatoriu. Numărul versiunii cadrului ajută la determinarea versiunii standardelor utilizate pentru a citi corect cadrul. Aici vom analiza doar cel mai conservator standard cu versiunea „0”.

În câmpul identificatorului canalului virtual (Virtual Channel ID) trebuie să fie inclus VCID-ul canalului de la care a fost primit pachetul. Nu există nicio restricție asupra alegerii VCID-ului, în special canalele virtuale nu trebuie să fie numerotate în mod secvențial.

Foarte des apare necesitatea de a multiplexa datele transmise. Pentru aceasta există un mecanism de canale virtuale. De exemplu, satelitul Meteor-M2 transmite o imagine color în intervalul vizibil, împărțindu-l în trei canale alb-negru – fiecare culoare este transmisă în canalul său virtual sub formă de pachet separat, deși în structura cadrelor sale există o anumită deviație de la standarde.

Câmpul indicatorului Control Operațional trebuie să fie un indicator al prezenței sau absenței câmpului Control Operațional în cadrul telemetriei. Aceste 4 octeți de la sfârșitul cadrului servesc pentru a menține un feedback în controlul livrării cadrelor de telecomandă. Despre acestea vom vorbi puțin mai târziu.

Contorii cadrelor canalului principal și al canalului virtual sunt câmpuri care se cresc cu o unitate la trimiterea fiecărui cadru. Acestea servesc ca indicator că niciun cadru nu a fost pierdut.

Starea datelor cadrului de telemetrie constă în alți doi octeți de indicatori și date, dintre care vom analiza doar câțiva.

Câmpul indicatorului antetului secundar (Secondary Header) trebuie să fie un indicator al prezenței sau absenței antetului suplimentar (Secondary Header) în cadrul telemetriei.

Dacă se dorește, se poate adăuga un antet suplimentar fiecărui cadru și se pot plasa acolo orice date la discreția proprie.

Câmpul pointer-ului la primul header (First Header Pointer), atunci când valoarea indicatorului de sincronizare este „1”, trebuie să conțină o reprezentare binară a poziției primului octet al primului Pachet în câmpul de date (Data Field) al cadrului de telemetrie. Poziția este numărată de la 0 în ordine crescătoare de la începutul câmpului de date. Dacă nu există un început al pachetului în câmpul de date al cadrului de telemetrie, atunci câmpul pointer-ului la primul header trebuie să aibă valoarea în reprezentare binară „11111111111” (acest lucru poate apărea dacă un pachet lung se extinde pe mai multe cadre).

Dacă în câmpul de date există un pachet gol (Idle Data), atunci pointer-ul la primul header trebuie să aibă valoarea în reprezentare binară „11111111110”. După acest câmp, receptorul trebuie să efectueze sincronizarea fluxului. Acest câmp garantează restaurarea sincronizării chiar și în cazul în care cadre sunt pierdute.

Asta înseamnă că pachetul poate, să zicem, să înceapă în mijlocul cadrului 4 și să se termine la începutul cadrului 20. Pentru a găsi începutul său, acest câmp servește. Pachetele au, de asemenea, un header, în care este specificată lungimea acestuia, astfel că, la găsirea pointer-ului la primul header, procesorul la nivelul canalului trebuie să-l citească, determinând astfel unde se va termina pachetul.
Dacă câmpul de control al erorilor este prezent, acesta trebuie să fie inclus în fiecare cadru de telemetrie pentru un anumit canal fizic pe tot parcursul misiunii.

Acest câmp este calculat prin aplicarea metodei CRC. Procedura trebuie să primească n-16 biți ai cadrului de telemetrie și să includă rezultatul calculului în ultimii 16 biți.

Telecomenzi

Cadrele de telecomenzi au câteva diferențe esențiale. Printre acestea:

O structură diferită a headerelor
Lungime dinamică. Asta înseamnă că lungimea cadrului nu este fixă, așa cum este cazul în telemetrie, ci poate varia în funcție de pachetele transmise.
Mecanism de garantare a livrării pachetelor. Asta înseamnă că CA trebuie, după primire, să confirme corectitudinea recepției cadrelor sau să solicite retransmiterea de la cadrul care ar fi putut fi primit cu o eroare corectabilă.

Multe câmpuri sunt deja familiare din headerul cadrului de telemetrie. Ele au aceeași funcție, prin urmare, aici vom examina doar câmpurile noi.

O bit al flagului de ocolire trebuie să fie utilizat pentru a controla verificarea cadrelor la receptor. Valoarea „0” a acestui flag ar trebui să indice că acest cadru este de tip A și verificația sa trebuie realizată conform FARM. Valoarea „1” a acestui flag ar trebui să indice receptorului că acest cadru este de tip B și trebuie să fie ocolit în verificarea conform FARM.

Acest flag informează receptorul dacă trebuie să utilizeze mecanismul de confirmare a livrării cadrelor, denumit FARM – Mecanismul de Acceptare și Raportare a Cadrelor.

Flagul comenzii de control trebuie să fie utilizat pentru a înțelege dacă câmpul de date transportă o comandă sau date. Dacă flagul este „0”, atunci câmpul de date trebuie să conțină date. Dacă flagul este „1”, atunci câmpul de date trebuie să conțină informații de control pentru FARM.
FARM reprezintă un automat finit, ale cărui parametrii pot fi personalizate.

RSVD. SPARE – biți rezervați.

Se pare că CCSDS are planuri pentru acestea în viitor, și pentru a asigura compatibilitatea versiunilor protocolelor, au rezervat deja acești biți în actualele versiuni ale standardului.

Câmpul de lungime al cadrelor trebuie să conțină un număr în reprezentare binară, care este lungimea cadrului în octeți minus unu.

Câmpul de date al cadrului trebuie să urmeze după antet fără lacune și să conțină un număr întreg de octeți, care poate avea o lungime maximă de 1019 octeți. Acest câmp trebuie să conțină fie un bloc de date al cadrului, fie informații de control al comenzii. Blocul de date al cadrului trebuie să conțină:

un număr întreg de octeți de date utilizator
antetul segmentului și numărul următor de octeți de date utilizator

Dacă antetul este prezent, atunci blocul de date trebuie să conțină un Pachet, un set de Pachete sau o parte din acesta. Un bloc de date fără antet nu poate conține părți din Pachete, dar poate conține blocuri de date în format privat. Din aceasta rezultă că antetul este necesar atunci când blocul de date transmis nu se încadrează într-un singur cadru. Un bloc de date având un antet este numit segment.

Câmpul de flags de dimensiune de doi biți trebuie să conțină:

„01” — dacă prima parte de date se află în blocul de date
„00” — dacă partea medie de date se află în blocul de date
„10” — dacă ultima parte de date se află în blocul de date
«11» — dacă nu există divizare și în blocul de date este plasat întreg un sau mai multe pachete.

Câmpul identificator MAP trebuie să conțină zerouri, dacă canalele MAP nu sunt utilizate.
Uneori, 6 biți alocați canalelor virtuale nu sunt suficienți. Dacă este necesar să se multiplexer datele pe un număr mai mare de canale, se folosesc încă 6 biți din antetul segmentului.

FERMĂ

Să analizăm mai în detaliu mecanismul de funcționare al sistemului de control al livrării cadrelor. Acest sistem prevede doar lucrul cu cadrele de telecommandă datorită importanței lor (telemetria poate fi solicitată din nou, dar CA trebuie să audă stația terestră clar și întotdeauna să se supună ordinelor acesteia). Așadar, să presupunem că am decis să reprogramăm satelitul nostru și trimitem pe bordul său un fișier binar de 10 kilobiți. La nivel de canal, fișierul este împărțit în 10 cadre (0, 1, …, 9), care sunt trimise succesiv. Când transmiterea se finalizează, CA trebuie să confirme corectitudinea primirii pachetului sau să comunice pe care cadru a avut loc eroarea. Această informație este trimisă în câmpul de control operațional în cel mai apropiat cadru de telemetrie (sau CA poate iniția transmiterea unui cadru gol (idle frame) dacă nu are nimic de spus). Din telemetria primită ne asigurăm fie că totul este bine, fie începem să retransmitem mesajul. Să presupunem că satelitul nu a auzit cadrul nr. 7. Asta înseamnă că îi trimitem cadrele 7, 8, 9. Dacă nu avem răspuns, pachetul este trimis din nou integral (și așa mai departe, de câteva ori, până înțelegem că încercările sunt zadarnice).

Mai jos este structura câmpului de control operațional cu descrierea unor câmpuri. Datele conținute în acest câmp sunt denumite CLCW – Communication Link Control Word.

Deoarece din imagine se poate deduce destinația principalelor câmpuri, iar privirea asupra altora este plictisitoare, ascund descrierea detaliată sub un spoiler.

Decodarea câmpurilor CLCWTipul cuvântului de control (Control Word Type):
Pentru acest tip de cuvânt de control trebuie să conțină 0

Versiunea cuvântului de control (CLCW Version Number):
Pentru acest tip de cuvânt de control trebuie să egaleze „00” în reprezentarea binară.

Câmpul de status (Status Field):
Utilizarea acestui câmp este determinată pentru fiecare misiune în parte. Poate fi utilizat pentru îmbunătățiri locale de diferite agenții spațiale.

Identificatorul canalului virtual (Identificarea canalului virtual):
Trebuie să conțină identificatorul canalului virtual asociat cu acest cuvânt de control.

Flamul de acces la canalul fizic:
Flamul trebuie să ofere informații despre disponibilitatea nivelului fizic al receptorului. Dacă nivelul fizic al receptorului nu este pregătit pentru a primi cadre, câmpul trebuie să conțină „1”, altfel „0”.

Flamul de pierdere de sincronizare:
Flamul poate indica faptul că nivelul fizic funcționează într-un condiții slabe de semnal și că numărul de cadre respinse este prea mare. Utilizarea acestui câmp este opțională; dacă este utilizat, trebuie să conțină „0” în prezența sincronizării, și „1” în absența acesteia.

Flamul de blocare:
Această biți trebuie să conțină statutul de blocare FARM pentru fiecare canal virtual. O valoare „1” în acest câmp trebuie să indice că FARM este blocat și cadrele vor fi respinse pentru fiecare nivel virtual, altfel „0”.

Flamul de așteptare:
Această biți trebuie utilizat pentru a indica că receptorul nu poate procesa acest cadru pe canalul virtual specificat. O valoare „1” indică că toate cadrele vor fi respinse pe acest canal virtual, altfel „0”.

Flamul de retransmisie:
Acest flam trebuie să conțină „1” dacă unul sau mai multe cadre de tip A au fost respinse sau au fost detectate pierderi, necesitând astfel retransmisie. Flam „0” indică că nu au existat cadre respinse sau pierderi.

Valoarea răspunsului:
Numărul cadrului care nu a fost acceptat. Determinat de contorul din antetul cadrele telecomenzii.

Nivelul de rețea

Să ne referim puțin și la acest nivel. Aici sunt posibile două variante: fie utilizarea protocolului pachetului spațial, fie încapsularea unui alt protocol în pachetul CCSDS.

O prezentare generală a protocolului pachetului spațial este un subiect pentru un articol separat. Acesta este creat pentru a permite aplicațiilor denumite să schimbe date fără probleme. Fiecare aplicație are propria adresă și funcționalitatea de bază pentru schimbul de date cu alte aplicații. De asemenea, există servicii care efectuează rutarea traficului, asigurând controlul livrării etc.

Cu încapsularea, totul este mai simplu și mai clar. Standardele oferă posibilitatea de a încapsula în pachetele CCSDS orice protocoale, adăugând un antet suplimentar.

Unde titlul are semnificații diferite în funcție de lungimea protocolului încapsulat:

Aici câmpul principal este lungimea. Aceasta poate varia de la 0 la 4 octeți. De asemenea, în acest header trebuie să specificați tipul protocolului încapsulat, folosind tabela de aici.

În timpul încapsulării IP se folosește un alt header pentru a determina tipul pachetului.
Trebuie să adăugați un alt header, cu o lungime de un octet:

Unde PID este un alt identificator de protocol preluat de aici

Concluzie

La prima vedere, ar putea părea că header-urile CCSDS sunt extrem de redundante, iar unele câmpuri ar putea fi omise. Într-adevăr, eficiența canalului rezultat (până la nivelul rețelei) este de aproximativ 40%. Cu toate acestea, atunci când devine necesară implementarea acestor standarde, devine evident că fiecare câmp, fiecare header are propria sa misiune importantă, ignorarea căreia duce la o serie întreagă de ambiguități.

Dacă comunitatea Habr va manifesta interes pentru acest subiect, voi fi bucuros să public o serie de articole dedicate teoriei și practicii comunicațiilor spațiale. Vă mulțumesc pentru atenție!