Un peu sur les normes de communication spatiale

Satellite Meteor M1
Source: vladtime.ru

Présentation

Le fonctionnement de la technologie spatiale est impossible sans les communications radio, et dans cet article je vais essayer d'expliquer les idées de base qui ont formé le fondement des normes élaborées par le Comité consultatif pour les systèmes de données spatiales - CCSDS. Cette abréviation sera utilisée ci-dessous.

Cette publication sera consacrée principalement au niveau du canal, cependant, des concepts de base pour d'autres niveaux seront également introduits. Devenir ne prétend en aucun cas à une description complète et complète des normes. Vous pouvez le trouver sur le site Web du CCSDS. Cependant, ils sont très difficiles à percevoir, et pour les comprendre, nous avons passé beaucoup de temps, alors ici je veux donner des informations de base, ce qui sera plus facile à gérer. Commençons donc.

La noble mission du CCSDS

Peut-être que quelqu'un avait une question: pourquoi tout le monde devrait-il adhérer aux normes si vous pouvez développer votre propre pile de protocoles de protocole propriétaire (ou votre propre norme, avec blackjack et nouvelles fonctionnalités), augmentant ainsi la sécurité du système?

Comme le montre la pratique, il est plus rentable d'adhérer aux normes CCSDS pour les séries de raisons suivantes:

1. Le comité responsable de la publication des normes comprenait des représentants de toutes les grandes agences aérospatiales du monde, apportant leur précieuse expérience acquise au cours de nombreuses années de conception et d'exploitation de diverses missions. Il serait très ridicule d'ignorer cette expérience et de marcher à nouveau sur leur râteau.
2. Ces normes sont appuyées par des équipements de station au sol déjà sur le marché.
3. Pendant le dépannage, vous pouvez toujours demander de l'aide à des collègues d'autres agences afin qu'ils puissent mener une session de communication avec l'appareil depuis leur station au sol.

L'architecture

Les normes sont un ensemble de documents reflétant le modèle OSI (Open System Interconnection) le plus courant, sauf qu'au niveau du canal, la communauté se limite à la division en télémétrie (canal "down" - espace - Terre) et télécommandes (channel "up").



Considérez certains niveaux plus en détail, en commençant par le physique et en remontant. Pour plus de clarté, nous considérerons l'architecture du côté hôte. L'émetteur est son image miroir.

Niveau physique

À ce niveau, le signal radio modulé est converti en un flux binaire. Les normes ici sont principalement de nature recommandatoire, car à ce niveau, il est difficile de s'abstraire d'une mise en œuvre spécifique du fer. Ici, le rôle clé du CCSDS est de déterminer les modulations autorisées (BPSK, QPSK, 8-QAM, etc.) et de donner quelques recommandations sur la mise en œuvre de mécanismes de synchronisation de symboles, la compensation de décalage Doppler, etc.

Niveau de synchronisation et d'encodage

Formellement, il s'agit d'une sous-couche de la couche liaison de données, mais très souvent, il est alloué en tant que couche distincte en raison de son importance dans le cadre des normes CCSDS. Ce niveau convertit le train de bits en trames dites (télémétrie ou télécommandes), dont nous parlerons plus loin. Contrairement à la synchronisation des caractères au niveau physique, qui vous permet d'obtenir le flux binaire correct, la synchronisation de trame est effectuée ici. Considérez le chemin parcouru par les données à 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 rechercher et / ou corriger les erreurs de bits qui se produisent inévitablement lors de l'envoi de données par voie hertzienne. Ici, nous ne considérerons pas les procédures de décodage, mais nous n'obtiendrons que les informations nécessaires pour comprendre la logique supplémentaire du niveau.

Les codes sont bloqués et continus. Les normes n'imposent pas l'utilisation d'un type particulier de codage, mais il doit être présent en tant que tel. Les codes continus comprennent des codes convolutionnels (colvolutionnels). En les utilisant, un flux binaire continu est codé. Contrairement aux codes de bloc, où les données sont divisées en blocs de code (bloc de code) et ne peuvent être décodées que dans le cadre de blocs entiers. Le bloc de code est constitué des données transmises et des informations redondantes jointes nécessaires pour vérifier l'exactitude des données et corriger les éventuelles erreurs. Les codes de bloc incluent les célèbres codes Reed-Solomon.

Si le codage convolutionnel est utilisé, le train de bits depuis le début va au décodeur. Le résultat de son travail (tout cela, bien sûr, se produit en continu) sont des unités de données CADU (unité d'accès aux canaux). Cette structure est nécessaire pour la synchronisation de trame. À la fin de chaque CADU est attaché un marqueur de synchronisation (ASM - fabricant de synchronisation attaché). Ce sont 4 octets connus à l'avance, par lesquels le synchroniseur trouve le début et la fin de la CADU. C'est ainsi que la synchronisation de trame est réalisée.

La prochaine étape facultative de fonctionnement de la couche de synchronisation et de codage est associée aux caractéristiques de la couche physique. C'est de la dérandomisation. Le fait est que pour réaliser la synchronisation des symboles, une commutation fréquente entre les symboles est nécessaire. Donc, si nous transférons, disons, un kilo-octet de données composé uniquement d'unités, la synchronisation sera perdue. Par conséquent, pendant la transmission, les données d'entrée sont mélangées avec une séquence pseudo-aléatoire périodique de sorte que la densité des zéros et des uns est uniforme.

Ensuite, les codes de bloc sont décodés, et ce qui restera sera le produit final de la synchronisation - niveau de codage - trame.

Niveau de canal

D'une part, le gestionnaire de couche liaison reçoit des trames et, d'autre part, il produit des paquets. Puisque formellement la taille des paquets n'est pas limitée, pour leur transmission fiable, il est nécessaire de les diviser en structures plus petites - des trames. Nous considérons ici deux sous-sections: séparément pour la télémétrie (TM) et les télécommandes (TC).

Télémétrie

Autrement dit, ce sont les données que la station au sol reçoit du vaisseau spatial. Toutes les informations transmises sont divisées en petits fragments d'une longueur fixe - des trames qui contiennent les données transmises et les champs de service. Considérez la structure du cadre plus en détail:



Et nous commencerons notre examen par le titre principal de la trame de télémétrie. De plus, je me permettrai à certains endroits de simplement traduire les normes, en donnant simultanément quelques éclaircissements.



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

Chaque vaisseau spatial, selon les normes CCSDS, doit avoir son propre identifiant unique, par lequel il est possible, avec un cadre, de déterminer à quel véhicule il appartient. Formellement, il est nécessaire de demander l'enregistrement de l'appareil, et son nom, ainsi que l'identifiant, seront publiés dans des sources ouvertes. Cependant, les fabricants russes ignorent souvent cette procédure, attribuant un identifiant arbitraire à l'appareil. Le numéro de version du cadre permet de déterminer la version des normes utilisée pour lire correctement le cadre. Ici, nous considérons uniquement la norme la plus conservatrice avec la version «0».

L'ID de canal virtuel doit contenir le VCID du canal d'où provient le paquet. Il n'y a aucune restriction sur le choix du VCID, en particulier, les canaux virtuels ne sont pas nécessairement numérotés séquentiellement.

Très souvent, il est nécessaire de multiplexer les données transmises. Il existe un mécanisme de canal virtuel pour cela. Par exemple, le satellite Meteor-M2 transmet une image en couleur dans la plage visible, la divisant en trois en noir et blanc - chaque couleur est transmise dans son propre canal virtuel dans un package séparé, bien qu'il y ait un certain écart par rapport aux normes dans la structure de ses cadres.

Le champ d'indicateur de contrôle opérationnel doit être un indicateur de la présence ou de l'absence du champ de contrôle opérationnel dans la trame de télémétrie. Ces 4 octets à la fin de la trame servent à maintenir la rétroaction lors de la surveillance de la livraison des trames de télécommande. Nous en parlerons un peu plus tard.

Les compteurs de trames des canaux principal et virtuel sont des champs qui sont incrémentés de un lorsque chaque trame est envoyée. Ils servent d'indicateur qu'aucune trame n'a été perdue.

L'état des données de trame de télémétrie est de deux octets supplémentaires d'indicateurs et de données, dont nous ne considérerons que quelques-uns.



Le champ indicateur de l'en-tête secondaire (en-tête secondaire) doit être un indicateur de la présence ou de l'absence de l'en-tête secondaire (en-tête secondaire) dans la trame de télémétrie.

Si vous le souhaitez, vous pouvez ajouter un en-tête supplémentaire à chaque cadre et y placer toutes les données à votre discrétion.

Le champ du pointeur vers le premier en-tête (First Header Pointer), avec la valeur de l'indicateur de synchronisation "1", doit contenir la représentation binaire de la position du premier octet du premier paquet dans le champ de données de la trame de télémétrie. La position est comptée à partir de 0 dans l'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, le champ du pointeur vers le premier en-tête doit avoir une valeur dans la représentation binaire "11111111111" (cela peut se produire si un long paquet s'étend sur plusieurs trames).

Si le champ de données contient un paquet vide (données inactives), le pointeur vers le premier en-tête doit avoir une valeur dans la représentation binaire "11111111110". Dans ce domaine, le récepteur doit synchroniser le flux. Ce champ garantit la restauration de la synchronisation même en cas de saut de trames.

Autrement dit, un paquet peut, supposons, commencer au milieu de la 4e trame et se terminer au début de la 20e. Pour trouver son début, ce champ ne fait que servir. Les paquets ont également un en-tête dans lequel sa longueur est enregistrée. Ainsi, lorsqu'un pointeur vers le premier en-tête est trouvé, le gestionnaire de niveau lien doit le lire, déterminant ainsi où le paquet se terminera.
Si un champ de contrôle d'erreur est présenté, il doit être contenu dans chaque trame de télémétrie pour un canal physique particulier tout au long de la mission.

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

Telecommands

La trame de télécommande présente plusieurs différences importantes. Parmi eux:

1. Structure d'en-tête différente
2. Longueur dynamique. Cela signifie que la longueur de trame n'est pas définie de manière rigide, comme cela se fait en télémétrie, mais peut varier en fonction des paquets transmis.
3. Mécanisme de garantie de livraison de colis. C'est-à-dire que l'engin spatial doit, après réception, confirmer la bonne réception des trames, ou demander le transfert de la trame qui pourrait être reçue avec une erreur non corrigible.

De nombreux champs nous sont déjà familiers depuis l'en-tête de trame de télémétrie. Ils ont le même objectif, nous ne considérons donc ici que de nouveaux domaines.

Un bit de l'indicateur de contournement doit être utilisé pour surveiller la vérification de trame au niveau du récepteur. La valeur «0» de cet indicateur doit indiquer que cette trame est une trame de type A et doit être vérifiée conformément à FARM. La valeur «1» de cet indicateur doit indiquer au récepteur que cette trame est une trame de type B et doit contourner la vérification selon FARM.

Cet indicateur indique au récepteur s'il doit utiliser le mécanisme de confirmation de remise de trame appelé FARM - Frame Acceptance and Reporting Mechanism.

L'indicateur de commande de contrôle doit être utilisé pour comprendre si le champ de données transporte la commande ou les données. Si l'indicateur est «0», le champ de données doit contenir des données. Si l'indicateur est «1», le champ de données doit contenir les informations de contrôle pour la FERME.
FARM est une machine d'état dont les paramètres peuvent être configurés.

RSVD. SPARE - bits réservés.

Il semble que CCSDS ait des plans pour eux à l'avenir, et pour la compatibilité descendante des versions de protocole, ils ont déjà réservé ces bits dans les versions actuelles de la norme.

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

Le champ de données de trame doit suivre l'en-tête sans espaces et contenir un nombre entier d'octets, qui peut être au maximum de 1019 octets. Ce champ doit contenir soit un bloc de données de trame, soit des informations provenant d'une commande de contrôle. Le bloc de données de trame doit contenir:

• octet données utilisateur entières
• en-tête de segment suivi d'un octet entier de données utilisateur

Si un en-tête est fourni, le bloc de données doit contenir un package, de nombreux paquets ou une partie de celui-ci. Un bloc de données sans en-tête ne peut pas contenir de parties de paquets, mais il peut contenir des blocs de données d'un format privé. Il en résulte que l'en-tête est requis lorsque le bloc de données transmis ne tient pas dans une trame. Un bloc de données ayant un en-tête est appelé segment.



Un champ indicateur à 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 centrale des données se trouve dans le bloc de données
• "10" - si la dernière donnée se trouve dans le bloc de données
• «11» - s'il n'y a pas de division et qu'un ou plusieurs paquets sont placés dans le bloc de données dans son ensemble.

Le champ d'identifiant MAP doit contenir des zéros si les canaux MAP ne sont pas utilisés.
Parfois, 6 bits alloués aux canaux virtuels ne suffisent pas. Et si vous avez besoin de multiplexer des données sur un plus grand nombre de canaux, 6 autres bits de l'en-tête de segment sont utilisés.

Ferme

Examinons plus en détail le mécanisme de fonctionnement du système de contrôle de la livraison du personnel. Ce système ne prévoit de travailler avec le personnel des télécommunications que compte tenu de leur importance (la télémétrie peut toujours être demandée à nouveau, et l'engin spatial doit entendre clairement la station au sol et toujours obéir à ses commandes). Supposons donc que nous ayons décidé de reflasher notre satellite et d'envoyer un fichier binaire de 10 kilo-octets à bord. Au niveau du canal, le fichier est divisé en 10 trames (0, 1, ..., 9), qui sont envoyées une par une vers le haut. Une fois la transmission terminée, l'engin spatial doit confirmer la bonne réception du paquet ou signaler sur quelle trame une erreur s'est produite. Ces informations sont envoyées au champ de contrôle opérationnel dans la trame de télémétrie la plus proche (ou l'engin spatial peut initier la transmission d'une trame vide (trame inactive) s'il n'a rien à dire). Sur la base de la télémétrie reçue, nous nous assurons que tout va bien ou nous renvoyons le message. Supposons que le satellite n'entende pas la trame n ° 7. Donc, nous envoyons les trames 7, 8, 9. S'il n'y a pas de réponse, le paquet est envoyé à nouveau complètement (et ainsi de suite plusieurs fois jusqu'à ce que nous réalisions que les tentatives sont vaines).

Voici la structure du domaine du contrôle opérationnel avec une description de certains domaines. Les données contenues dans ce champ sont appelées CLCW - Communication Link Control Word.



Puisqu'il est tout à fait possible de deviner à partir de l'image le but des champs principaux, tout en regardant les autres est ennuyeux, je cache la description détaillée sous le spoiler

Couche réseau

Une petite touche à ce niveau. Deux options sont possibles ici: soit utiliser le protocole de paquet d'espace, soit encapsuler tout autre protocole dans le paquet CCSDS.

Un examen du protocole de paquet d'espace est un sujet pour un article séparé. Il a été créé pour que les soi-disant applications puissent échanger de façon transparente des données. Chaque application a sa propre adresse et des fonctionnalités de base pour l'échange de données avec d'autres applications. Il existe également des services qui acheminent le trafic, effectuent le contrôle de livraison, etc.

Avec l'encapsulation, tout est plus simple et plus compréhensible. Les normes permettent d'encapsuler n'importe quel protocole dans des paquets CCSDS en ajoutant un en-tête supplémentaire.



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



Ici, le champ principal est la longueur longueur. Il peut varier de 0 à 4 octets. Toujours dans cet en-tête, vous devez spécifier le type de protocole encapsulé, en utilisant le tableau d'ici .

Lors de l'encapsulation IP, un autre complément est utilisé pour déterminer le type de paquet.
Vous devez ajouter un autre en-tête, à partir d'un octet de longueur:



où PID est un autre identifiant de protocole tiré d'ici

Conclusion

, CCSDS , . , ( ) 40%. , , , , , .

, , . Merci de votre attention!

Les sources

CCSDS 130.0-G-3 — Overview of the space communications protocols
CCSDS 131.0-B-2 — TM synchronization and channel coding
CCSDS 132.0-B-2 — TM Space Data Link Protocol
CCSDS 133.0-B-1 — Space packet protocol
CCSDS 133.1-B-2 — Encapsulation Service
CCSDS 231.0-B-3 — TC Synchronization and Channel Coding
CCSDS 232.1-B-2 Communications Operation Procedure-1
CCSDS 401.0-B-28 Radio Frequency and Modulation Systems — Part 1 (Earth Stations and Spacecraft)
CCSDS 702.1-B-1 — IP over CCSDS space links

PS
, . , :)