Un peu sur les normes des communications spatiales

Satellite Météor M1
Source : vladtime.ru

Introduction

L'exploitation des engins spatiaux est impossible sans radio communication, et dans cet article, je vais essayer d'expliquer les concepts fondamentaux qui ont servi de base aux normes développées par le Comité Consultatif pour les Systèmes de Données Spatiales (Consultative Committee for Space Data Systems – CCSDS. Cette abréviation sera utilisée par la suite).

Cette publication sera principalement dédiée au niveau de la liaison, cependant, les concepts fondamentaux pour les autres niveaux seront également introduits. Cet article ne prétend en aucun cas à une description exhaustive et complète des normes. Vous pouvez les consulter sur site CCSDS. Cependant, elles sont très difficiles à comprendre, et pour les saisir, nous avons consacré pas mal de temps, c'est pourquoi je souhaite ici fournir des informations de base, ce qui facilitera grandement la compréhension de tout le reste. Alors, commençons.

La noble mission du CCSDS

Il est possible que quelqu'un se demande pourquoi tout le monde devrait suivre des normes alors qu'il serait possible de développer son propre ensemble de protocoles de communication radio (ou sa propre norme, avec du blackjack et de nouvelles fonctionnalités), augmentant ainsi la sécurité du système ?

Comme l'expérience le montre, il est plus avantageux de respecter les normes CCSDS pour plusieurs raisons :

1. Le comité responsable de la publication des normes comprend des représentants de toutes les grandes agences spatiales du monde, apportant leur expérience précieuse acquise au cours de nombreuses années de conception et d'exploitation de diverses missions. Il serait très absurde d'ignorer cette expérience et de recommencer à faire les mêmes erreurs.
2. Ces normes sont prises en charge par l'équipement existant sur le marché des stations au sol.
3. Lors de la résolution de problème, il est toujours possible de demander de l'aide à des collègues d'autres agences pour qu'ils effectuent une session de communication avec le vaisseau spatial depuis leur station au sol. Comme vous le voyez, les normes sont extrêmement utiles, alors examinons leurs points clés.

Architecture

Les normes représentent un ensemble de documents reflétant le modèle OSI (Open System Interconnection) standard, à l'exception du fait qu'au niveau de la liaison, la communauté se limite à la séparation entre télémétrie (canal « vers le bas » — espace - Terre) et télémission (canal « vers le haut »).

Examinons de plus près certains niveaux, en commençant par le niveau physique et en remontant. Pour plus de clarté, nous allons considérer l'architecture du côté récepteur. L'émetteur en est le miroir.

Niveau physique

À ce niveau, le signal radio modulé est converti en flux binaire. Les normes ici sont principalement de nature recommandative, car il est difficile de s'abstraire de la mise en œuvre matérielle spécifique à ce niveau. Le rôle clé de la CCSDS – définir les modulations acceptables (BPSK, QPSK, 8-QAM, etc.) et donner des recommandations sur la mise en œuvre des mécanismes de synchronisation symbolique, de compensation du décalage Doppler, etc.

Niveau de synchronisation et de codage

Formellement, c'est un sous-niveau du niveau de liaison, mais il est souvent considéré comme un niveau distinct en raison de son importance dans le cadre des normes CCSDS. Ce niveau transforme le flux binaire en ce qu'on appelle des trames (de télémetrie ou de télécommande), dont nous parlerons plus tard. Contrairement à la synchronisation symbolique au niveau physique, qui permet d'obtenir un flux binaire correct, ici on effectue la synchronisation des trames. Examinons le chemin que les données empruntent à ce niveau (de bas en haut) :

Cependant, avant cela, il convient de dire quelques mots sur le codage. Cette procédure est nécessaire pour détecter et/ou corriger les erreurs de bits qui surviennent inévitablement lors de l'envoi de données par canal radio. Ici, nous ne traiterons pas des procédures de décodage, mais nous recueillerons les informations nécessaires pour comprendre la logique de fonctionnement du niveau.

Il existe des codes Bloqués et Continus. Les normes n'obligent pas à utiliser un type de codage spécifique, mais celui-ci doit être présent. Les codes continus sont appelés codes convolutifs. Avec eux, un flux binaire continu est codé. Contrairement aux codes bloqués, où les données sont divisées en blocs de code, et peuvent être décodées uniquement dans le cadre de blocs intacts. Un bloc de code représente les données transmises et les informations Redondantes ajoutées, nécessaires pour vérifier la bonne réception des données et corriger les erreurs possibles. Les codes bloqués comprennent les célèbres codes de Reed-Solomon.

Si un codage par convolution est utilisé, le flux de bits arrive au décodeur dès le départ. Le résultat de son fonctionnement (tout cela, bien sûr, se fait en continu) est constitué de blocs de données CADU (channel access data unit). Cette structure est nécessaire pour la synchronisation des images. À la fin de chaque CADU, un marqueur de synchronisation (ASM - attached synch marker) est joint. Il s'agit de 4 octets connus à l'avance, permettant au synchroniseur de trouver le début et la fin du CADU. C'est ainsi que la synchronisation des images est atteinte.

L'étape suivante, optionnelle, du niveau de synchronisation et de codage est liée aux particularités du niveau physique. Il s'agit de la dérandomisation. En effet, pour atteindre une synchronisation symbolique, il est nécessaire d'effectuer des commutations fréquentes entre les symboles. Ainsi, si nous devions transmettre, par exemple, un kilooctet de données composé uniquement de uns, la synchronisation serait perdue. C'est pourquoi, lors de la transmission, les données d'entrée sont mélangées avec une séquence pseudo-aléatoire périodique afin que la densité de zéros et de uns soit uniforme.

Ensuite, le décodage des codes de bloc a lieu, et ce qui reste sera le produit final du niveau de synchronisation et de codage - la trame.

Niveau de canal

D'un côté, le gestionnaire du niveau de canal reçoit des trames, et de l'autre, il émet des paquets. Comme la taille des paquets n'est formellement pas limitée, il est nécessaire de les diviser en structures plus petites - des trames - pour un transfert fiable. Ici, nous examinerons deux sous-sections : une pour la télémétrie (TM) et l'autre pour les télécommandes (TC).

Télémétrie

En termes simples, ce sont les données que la station au sol reçoit du satellite. Toutes les informations transmises sont divisées en petits fragments de longueur fixe - des trames - qui contiennent les données transmises et des champs de contrôle. Examinons la structure de la trame plus en détail :

Et commençons par l'en-tête principal de la trame de télémétrie. Ensuite, je me permets, à certains endroits, de traduire simplement les normes tout en donnant quelques explications.

Le champ d'identifiant du canal principal (Master Channel ID) doit contenir le numéro de version de la trame et l'identifiant de l'appareil.

Chaque satellite, selon les normes CCSDS, doit avoir un identifiant unique, permettant de déterminer à quel appareil appartient un fichier donné. Formulèrement, une demande d'enregistrement de l'appareil doit être soumise, et son nom, accompagné de l'identifiant, sera publié dans des sources ouvertes. Cependant, les fabricants russes ignorent souvent cette procédure, attribuant à l'appareil un identifiant arbitraire. Le numéro de version du fichier aide à déterminer quelle version des normes est utilisée pour lire correctement le fichier. Ici, nous examinerons uniquement la norme la plus conservatrice avec la version «0».

Le champ d'identifiant de canal virtuel (Virtual Channel ID) doit contenir le VCID du canal à partir duquel le paquet provient. Il n'y a aucune restriction sur le choix du VCID, en particulier les canaux virtuels ne sont pas nécessairement numérotés de manière séquentielle.

Il est très souvent nécessaire de multiplexer les données transmises. Pour cela, il existe un mécanisme de canaux virtuels. Par exemple, le satellite Meteor-M2 transmet une image couleur dans le spectre visible, la divisant en trois images noir et blanc – chaque couleur étant transmise dans son propre canal virtuel sous forme de paquet distinct, bien que dans la structure de ses fichiers, il y ait quelques écarts par rapport aux normes.

Le champ de drapeau de contrôle opérationnel doit indiquer la présence ou l'absence d'un champ de contrôle opérationnel dans le fichier de télémétrie. Ces 4 octets à la fin du fichier servent à maintenir un retour d'information lors du contrôle de la livraison des fichiers de télécommandes. Nous en parlerons un peu plus tard.

Les compteurs de fichiers principal et de canal virtuel sont des champs qui s'incrémentent d'une unité à chaque envoi de fichier. Ils servent d'indicateur que aucun fichier n'a été perdu.

Le statut des données du fichier de télémétrie est constitué de deux octets de drapeaux et de données, parmi lesquels nous examinerons seulement certains.

Le champ de drapeau d'en-tête secondaire (Secondary Header) doit indiquer la présence ou l'absence d'un en-tête secondaire dans le fichier de télémétrie.

Si souhaité, un en-tête supplémentaire peut être ajouté à chaque fichier et y placer toutes les informations à sa convenance.

Le champ du pointeur vers le premier en-tête (First Header Pointer), lorsque le drapeau de synchronisation est à « 1 », doit contenir la représentation binaire de la position du premier octet du premier paquet dans le champ de données (Data Field) de la trame de télémétrie. La position est comptée à partir de 0 dans un ordre croissant depuis le début du champ de données. S'il n'y a pas de début de paquet dans le champ de données de la trame de télémétrie, alors le champ du pointeur vers le premier en-tête doit avoir pour valeur dans la représentation binaire « 11111111111 » (cela peut se produire si un long paquet s'étend sur plus d'une trame).

Si le champ de données contient un paquet vide (Idle Data), alors le pointeur vers le premier en-tête doit avoir pour valeur dans la représentation binaire « 11111111110 ». Ce champ est utilisé par le récepteur pour synchroniser le flux. Ce champ garantit la restauration de la synchronisation même en cas de perte de trames.

Ainsi, un paquet peut, disons, commencer au milieu de la 4ème trame et se terminer au début de la 20ème. Pour trouver son début, c'est précisément ce champ qui est utilisé. Les paquets ont également un en-tête qui spécifie leur longueur, donc lors de la localisation du pointeur vers le premier en-tête, le gestionnaire de niveau canal doit le lire, déterminant ainsi où le paquet se terminera.
Si le champ de contrôle des erreurs est présent, il doit se trouver dans chaque trame de télémétrie pour un canal physique spécifique tout au long de la mission.

Ce champ est calculé en utilisant la méthode CRC. La procédure doit prendre n-16 bits de la trame de télémétrie et insérer le résultat du calcul dans les 16 derniers bits.

Télécommandes

La trame de télécommande présente plusieurs différences essentielles. Parmi elles :

1. Une structure d'en-tête différente
2. Longueur dynamique. Cela signifie que la longueur de la trame n'est pas fixée rigidement, comme c'est le cas dans la télémétrie, mais peut varier en fonction des paquets transmis.
3. Mécanisme de garantie de livraison des paquets. Cela veut dire que le satellite doit confirmer la réception correcte des trames, ou demander la retransmission à partir de la trame qui a pu être reçue avec une erreur non corrigible.

De nombreux champs sont déjà familiers depuis l'en-tête de la trame de télémétrie. Ils ont la même fonction, donc ici nous allons examiner uniquement les nouveaux champs.

Un bit du drapeau de contournement doit être utilisé pour contrôler la vérification des trames sur le récepteur. Une valeur « 0 » de ce drapeau doit indiquer que cette trame est de type A et que sa vérification doit être effectuée conformément au FARM. Une valeur « 1 » de ce drapeau doit indiquer au récepteur que cette trame est de type B et doit contourner la vérification conformément au FARM.

Ce drapeau informe le récepteur s'il doit utiliser le mécanisme de confirmation de livraison des trames appelé FARM — Mécanisme d'acceptation et de rapport des trames.

Le drapeau de commande de contrôle doit être utilisé pour comprendre si le champ de données transporte une commande ou des données. Si le drapeau est « 0 », le champ de données doit contenir des données. Si le drapeau est « 1 », le champ de données doit contenir des informations de contrôle pour le FARM.
Le FARM est une machine à états, dont les paramètres peuvent être configurés.

RSVD. SPARE – bits réservés.

Il semble que le CCSDS ait des plans à leur sujet à l'avenir, et pour la compatibilité descendante des versions du protocole, ces bits sont déjà réservés dans les versions actuelles de la norme.

Le champ de longueur des trames doit contenir un nombre en représentation binaire, qui est égal à la longueur de la trame en octets moins un.

Le champ de données de la trame doit suivre immédiatement l'en-tête sans espace et contenir un entier d'octets, dont la longueur peut aller jusqu'à 1019 octets. Ce champ doit contenir soit un bloc de données de trame, soit des informations de commande. Le bloc de données de la trame doit contenir :

• un entier d'octets de données utilisateur
• l'en-tête de segment suivi d'un certain nombre d'octets de données utilisateur

Si l'en-tête est présent, le bloc de données doit contenir un paquet, plusieurs paquets ou une partie de ceux-ci. Un bloc de données sans en-tête ne peut pas contenir des parties de paquets, mais peut contenir des blocs de données au format privé. Il s'ensuit qu'un en-tête est requis lorsque le bloc de données transmis ne peut pas tenir dans une seule trame. Un bloc de données avec en-tête est appelé segment.

Le champ des drapeaux de deux bits doit contenir :

• « 01 » — si la première partie des données se trouve dans le bloc de données
• « 00 » — si la partie médiane des données se trouve dans le bloc de données
• « 10 » — si la dernière partie des données se trouve dans le bloc de données
• «11» — s'il n'y a pas de division et qu'un ou plusieurs paquets sont entièrement placés dans le bloc de données.

Le champ d'identifiant MAP doit contenir des zéros si les canaux MAP ne sont pas utilisés.
Parfois, 6 bits attribués aux canaux virtuels ne sont pas suffisants. Et s'il est nécessaire de multiplexage des données sur un plus grand nombre de canaux, encore 6 bits de l'en-tête du segment sont utilisés.

FARM

Examinons plus en détail le mécanisme de fonctionnement du système de contrôle de livraison des trames. Ce système prévoit uniquement le travail avec les trames de télécommandes en raison de leur importance (les télémétries peuvent toujours être redemandées, tandis que le satellite doit entendre clairement la station au sol et toujours obéir à ses ordres). Supposons donc que nous avons décidé de reprogrammer notre satellite et que nous envoyons à bord un fichier binaire de 10 kilooctets. Au niveau de canal, le fichier est divisé en 10 trames (0, 1, ..., 9), qui sont envoyées une par une. Une fois la transmission terminée, le satellite doit confirmer la réception correcte du paquet ou indiquer à quelle trame l'erreur s'est produite. Cette information est envoyée dans le champ de contrôle opérationnel lors de la prochaine trame de télémétrie (où le satellite peut également initier l'envoi d'une trame vide (idle frame) s'il n'a rien à dire). À partir des télémétries reçues, nous nous assurons soit que tout va bien, soit que nous procédons au renvoi du message. Supposons que le satellite n'ait pas entendu la trame n°7. Cela signifie que nous lui envoyons les trames 7, 8, 9. Si aucune réponse ne vient, le paquet est renvoyé dans son intégralité encore une fois (et ainsi plusieurs fois, jusqu'à ce que nous comprenions que les tentatives sont vaines).

Ci-dessous est présentée la structure du champ de contrôle opérationnel avec la description de certains champs. Les données contenues dans ce champ sont appelées CLCW – Communication Link Control Word.

Comme il est assez possible de deviner la destination des champs principaux à partir de l'image, et que regarder les autres est ennuyeux, je cache la description détaillée sous un spoiler.

Décryptage des champs CLCWType de mot de contrôle (Control Word Type) :
Pour ce type de mot de contrôle, il doit contenir 0.

Version du mot de contrôle (CLCW Version Number) :
Pour ce type de mot de contrôle, cela doit être égal à «00» en représentation binaire.

Champ de statut (Status Field) :
L'utilisation de ce champ est déterminée pour chaque mission séparément. Il peut être utilisé pour des améliorations locales par différentes agences spatiales.

Identifiant de canal virtuel (Virtual Channel Identification) :
Doit contenir l'identifiant du canal virtuel associé à ce mot de contrôle.

Drapeau d'accès au canal physique :
Ce drapeau doit fournir des informations sur l'état de préparation du niveau physique du récepteur. Si le niveau physique du récepteur n'est pas prêt à recevoir des images, le champ doit contenir « 1 », sinon « 0 ».

Drapeau de perte de synchronisation :
Ce drapeau peut indiquer que le niveau physique fonctionne avec un faible niveau de signal et que le nombre d'images perdues est trop élevé. L'utilisation de ce champ est optionnelle, s'il est utilisé, il doit contenir « 0 » en cas de synchronisation, et « 1 » en son absence.

Drapeau de verrouillage :
Ce bit doit contenir le statut de verrouillage FARM pour chaque canal virtuel. Une valeur de « 1 » dans ce champ doit indiquer que le FARM est verrouillé et que les images seront rejetées pour chaque niveau virtuel, sinon « 0 ».

Drapeau d'attente :
Ce bit doit être utilisé pour indiquer que le récepteur ne peut pas traiter les données sur le canal virtuel spécifié. La valeur « 1 » indique que toutes les images seront rejetées sur ce canal virtuel, sinon « 0 ».

Drapeau de retransmission :
Ce drapeau doit contenir « 1 » si une ou plusieurs images de type A ont été rejetées ou si des pertes ont été détectées, nécessitant une retransmission. Le drapeau « 0 » indique qu'il n'y a pas eu d'images rejetées ni de pertes.

Valeur de la réponse :
Numéro de l'image qui n'a pas été acceptée. Déterminé par le compteur dans l'en-tête de la trame de télécommande.

Niveau réseau

Abordons brièvement ce niveau. Deux options sont possibles : soit utiliser le protocole de paquet spatial, soit encapsuler tout autre protocole dans un paquet CCSDS.

La présentation du protocole de paquet spatial est un sujet pour un article à part. Il a été conçu pour permettre aux applications de transférer des données de manière transparente. Chaque application a sa propre adresse et une fonctionnalité de base pour échanger des données avec d'autres applications. Il existe également des services qui assurent le routage du trafic, le contrôle de la livraison, etc.

L'encapsulation est plus simple et plus claire. Les normes permettent d'encapsuler dans des paquets CCSDS tout protocole en ajoutant un en-tête supplémentaire.

Où l'en-tête a différentes significations selon la longueur du protocole encapsulé :

Ici le champ principal est la longueur. Elle peut varier de 0 à 4 octets. Cet en-tête doit également indiquer le type de protocole encapsulé, à l'aide du tableau d'ici.

Lors de l'encapsulation IP, un autre super-ensemble est utilisé pour définir le type de paquet.
Il est nécessaire d'ajouter un autre en-tête, d'une longueur d'au moins un octet :

Où le PID est un autre identifiant de protocole, pris d'ici

Conclusion

À première vue, on pourrait penser que les en-têtes CCSDS sont extrêmement redondants et que certains champs pourraient être supprimés. En effet, l'efficacité du canal résultant (jusqu'au niveau réseau) est d'environ 40 %. Cependant, dès qu'il est nécessaire de mettre en œuvre ces normes, il devient clair que chaque champ, chaque en-tête a sa propre mission importante, dont l'ignorance entraîne une série d'ambiguïtés.

Si la communauté Habr manifeste un intérêt pour ce sujet, je serais ravi de publier encore une série d'articles consacrés à la théorie et à la pratique de la communication spatiale. Merci de votre attention !

Sources

CCSDS 130.0-G-3 — Présentation des protocoles de communication spatiale
CCSDS 131.0-B-2 — Synchronisation TM et codage de canal
CCSDS 132.0-B-2 — Protocole de liaison de données spatiales TM
CCSDS 133.0-B-1 — Protocole de paquet spatial
CCSDS 133.1-B-2 — Service d'encapsulation
CCSDS 231.0-B-3 — Synchronisation TC et codage de canal
CCSDS 232.1-B-2 Procédure d'opération en communication-1
CCSDS 401.0-B-28 Systèmes de fréquence radio et de modulation — Partie 1 (Stations terrestres et engins spatiaux)
CCSDS 702.1-B-1 — IP sur des liaisons spatiales CCSDS

P.S.
Ne frappez pas trop fort si vous trouvez des inexactitudes. Signalez-les et elles seront corrigées 🙂

Source : habr.com