{"id":35921,"date":"2019-10-31T22:07:35","date_gmt":"2019-10-31T19:07:35","guid":{"rendered":"https:\/\/prohoster.info\/blog\/nemnogo-o-standartah-kosmicheskoj-svyazi\/"},"modified":"2019-10-31T22:07:35","modified_gmt":"2019-10-31T19:07:35","slug":"nemnogo-o-standartah-kosmicheskoj-svyazi","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/nemnogo-o-standartah-kosmicheskoj-svyazi","title":{"rendered":"Un peu sur les normes des communications spatiales","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Un
\nSatellite M\u00e9t\u00e9or M1
\nSource : vladtime.ru<\/i><\/p>\n

Introduction<\/h2>\n

\nL'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\u00e9velopp\u00e9es par le Comit\u00e9 Consultatif pour les Syst\u00e8mes de Donn\u00e9es Spatiales (Consultative Committee for Space Data Systems \u2013 CCSDS. Cette abr\u00e9viation sera utilis\u00e9e par la suite).<\/p>\n

Cette publication sera principalement d\u00e9di\u00e9e au niveau de la liaison, cependant, les concepts fondamentaux pour les autres niveaux seront \u00e9galement introduits. Cet article ne pr\u00e9tend en aucun cas \u00e0 une description exhaustive et compl\u00e8te des normes. Vous pouvez les consulter sur site<\/a><\/noindex> CCSDS. Cependant, elles sont tr\u00e8s difficiles \u00e0 comprendre, et pour les saisir, nous avons consacr\u00e9 pas mal de temps, c'est pourquoi je souhaite ici fournir des informations de base, ce qui facilitera grandement la compr\u00e9hension de tout le reste. Alors, commen\u00e7ons.
\n<\/a><\/noindex><\/p>\n

La noble mission du CCSDS<\/h2>\n

\nIl est possible que quelqu'un se demande pourquoi tout le monde devrait suivre des normes alors qu'il serait possible de d\u00e9velopper son propre ensemble de protocoles de communication radio (ou sa propre norme, avec du blackjack et de nouvelles fonctionnalit\u00e9s), augmentant ainsi la s\u00e9curit\u00e9 du syst\u00e8me ?<\/p>\n

Comme l'exp\u00e9rience le montre, il est plus avantageux de respecter les normes CCSDS pour plusieurs raisons :<\/p>\n

    \n
  1. Le comit\u00e9 responsable de la publication des normes comprend des repr\u00e9sentants de toutes les grandes agences spatiales du monde, apportant leur exp\u00e9rience pr\u00e9cieuse acquise au cours de nombreuses ann\u00e9es de conception et d'exploitation de diverses missions. Il serait tr\u00e8s absurde d'ignorer cette exp\u00e9rience et de recommencer \u00e0 faire les m\u00eames erreurs.<\/li>\n
  2. Ces normes sont prises en charge par l'\u00e9quipement existant sur le march\u00e9 des stations au sol.<\/li>\n
  3. Lors de la r\u00e9solution de probl\u00e8me, il est toujours possible de demander de l'aide \u00e0 des coll\u00e8gues 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\u00eamement utiles, alors examinons leurs points cl\u00e9s.<\/li>\n<\/ol>\n

    <\/p>\n

    Architecture<\/h2>\n

    \nLes normes repr\u00e9sentent un ensemble de documents refl\u00e9tant le mod\u00e8le OSI (Open System Interconnection) standard, \u00e0 l'exception du fait qu'au niveau de la liaison, la communaut\u00e9 se limite \u00e0 la s\u00e9paration entre t\u00e9l\u00e9m\u00e9trie (canal \u00ab vers le bas \u00bb \u2014 espace - Terre) et t\u00e9l\u00e9mission (canal \u00ab vers le haut \u00bb).<\/p>\n

    \"Un
    \n
    \nExaminons de plus pr\u00e8s certains niveaux, en commen\u00e7ant par le niveau physique et en remontant. Pour plus de clart\u00e9, nous allons consid\u00e9rer l'architecture du c\u00f4t\u00e9 r\u00e9cepteur. L'\u00e9metteur en est le miroir.<\/p>\n

    Niveau physique<\/h2>\n

    \n\u00c0 ce niveau, le signal radio modul\u00e9 est converti en flux binaire. Les normes ici sont principalement de nature recommandative, car il est difficile de s'abstraire de la mise en \u0153uvre mat\u00e9rielle sp\u00e9cifique \u00e0 ce niveau. Le r\u00f4le cl\u00e9 de la CCSDS \u2013 d\u00e9finir les modulations acceptables (BPSK, QPSK, 8-QAM, etc.) et donner des recommandations sur la mise en \u0153uvre des m\u00e9canismes de synchronisation symbolique, de compensation du d\u00e9calage Doppler, etc.<\/p>\n

    Niveau de synchronisation et de codage<\/h2>\n

    \nFormellement, c'est un sous-niveau du niveau de liaison, mais il est souvent consid\u00e9r\u00e9 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\u00e9l\u00e9metrie ou de t\u00e9l\u00e9commande), dont nous parlerons plus tard. Contrairement \u00e0 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\u00e9es empruntent \u00e0 ce niveau (de bas en haut) :<\/p>\n

    \"Un
    \n
    \nCependant, avant cela, il convient de dire quelques mots sur le codage. Cette proc\u00e9dure est n\u00e9cessaire pour d\u00e9tecter et\/ou corriger les erreurs de bits qui surviennent in\u00e9vitablement lors de l'envoi de donn\u00e9es par canal radio. Ici, nous ne traiterons pas des proc\u00e9dures de d\u00e9codage, mais nous recueillerons les informations n\u00e9cessaires pour comprendre la logique de fonctionnement du niveau. <\/p>\n

    Il existe des codes Bloqu\u00e9s et Continus. Les normes n'obligent pas \u00e0 utiliser un type de codage sp\u00e9cifique, mais celui-ci doit \u00eatre pr\u00e9sent. Les codes continus sont appel\u00e9s codes convolutifs. Avec eux, un flux binaire continu est cod\u00e9. Contrairement aux codes bloqu\u00e9s, o\u00f9 les donn\u00e9es sont divis\u00e9es en blocs de code, et peuvent \u00eatre d\u00e9cod\u00e9es uniquement dans le cadre de blocs intacts. Un bloc de code repr\u00e9sente les donn\u00e9es transmises et les informations Redondantes ajout\u00e9es, n\u00e9cessaires pour v\u00e9rifier la bonne r\u00e9ception des donn\u00e9es et corriger les erreurs possibles. Les codes bloqu\u00e9s comprennent les c\u00e9l\u00e8bres codes de Reed-Solomon.<\/p>\n

    Si un codage par convolution est utilis\u00e9, le flux de bits arrive au d\u00e9codeur d\u00e8s le d\u00e9part. Le r\u00e9sultat de son fonctionnement (tout cela, bien s\u00fbr, se fait en continu) est constitu\u00e9 de blocs de donn\u00e9es CADU (channel access data unit). Cette structure est n\u00e9cessaire pour la synchronisation des images. \u00c0 la fin de chaque CADU, un marqueur de synchronisation (ASM - attached synch marker) est joint. Il s'agit de 4 octets connus \u00e0 l'avance, permettant au synchroniseur de trouver le d\u00e9but et la fin du CADU. C'est ainsi que la synchronisation des images est atteinte.<\/p>\n

    L'\u00e9tape suivante, optionnelle, du niveau de synchronisation et de codage est li\u00e9e aux particularit\u00e9s du niveau physique. Il s'agit de la d\u00e9randomisation. En effet, pour atteindre une synchronisation symbolique, il est n\u00e9cessaire d'effectuer des commutations fr\u00e9quentes entre les symboles. Ainsi, si nous devions transmettre, par exemple, un kilooctet de donn\u00e9es compos\u00e9 uniquement de uns, la synchronisation serait perdue. C'est pourquoi, lors de la transmission, les donn\u00e9es d'entr\u00e9e sont m\u00e9lang\u00e9es avec une s\u00e9quence pseudo-al\u00e9atoire p\u00e9riodique afin que la densit\u00e9 de z\u00e9ros et de uns soit uniforme.<\/p>\n

    Ensuite, le d\u00e9codage des codes de bloc a lieu, et ce qui reste sera le produit final du niveau de synchronisation et de codage - la trame.<\/p>\n

    Niveau de canal<\/h2>\n

    \nD'un c\u00f4t\u00e9, le gestionnaire du niveau de canal re\u00e7oit des trames, et de l'autre, il \u00e9met des paquets. Comme la taille des paquets n'est formellement pas limit\u00e9e, il est n\u00e9cessaire de les diviser en structures plus petites - des trames - pour un transfert fiable. Ici, nous examinerons deux sous-sections : une pour la t\u00e9l\u00e9m\u00e9trie (TM) et l'autre pour les t\u00e9l\u00e9commandes (TC).<\/p>\n

    T\u00e9l\u00e9m\u00e9trie<\/h3>\n

    \nEn termes simples, ce sont les donn\u00e9es que la station au sol re\u00e7oit du satellite. Toutes les informations transmises sont divis\u00e9es en petits fragments de longueur fixe - des trames - qui contiennent les donn\u00e9es transmises et des champs de contr\u00f4le. Examinons la structure de la trame plus en d\u00e9tail :<\/p>\n

    \"Un
    \n
    \nEt commen\u00e7ons par l'en-t\u00eate principal de la trame de t\u00e9l\u00e9m\u00e9trie. Ensuite, je me permets, \u00e0 certains endroits, de traduire simplement les normes tout en donnant quelques explications.<\/p>\n

    \"Un
    \n
    \nLe champ d'identifiant du canal principal (Master Channel ID) doit contenir le num\u00e9ro de version de la trame et l'identifiant de l'appareil.<\/p>\n

    Chaque satellite, selon les normes CCSDS, doit avoir un identifiant unique, permettant de d\u00e9terminer \u00e0 quel appareil appartient un fichier donn\u00e9. Formul\u00e8rement, une demande d'enregistrement de l'appareil doit \u00eatre soumise, et son nom, accompagn\u00e9 de l'identifiant, sera publi\u00e9 dans des sources ouvertes. Cependant, les fabricants russes ignorent souvent cette proc\u00e9dure, attribuant \u00e0 l'appareil un identifiant arbitraire. Le num\u00e9ro de version du fichier aide \u00e0 d\u00e9terminer quelle version des normes est utilis\u00e9e pour lire correctement le fichier. Ici, nous examinerons uniquement la norme la plus conservatrice avec la version \u00ab0\u00bb.<\/i><\/p>\n

    Le champ d'identifiant de canal virtuel (Virtual Channel ID) doit contenir le VCID du canal \u00e0 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\u00e9cessairement num\u00e9rot\u00e9s de mani\u00e8re s\u00e9quentielle.<\/p>\n

    Il est tr\u00e8s souvent n\u00e9cessaire de multiplexer les donn\u00e9es transmises. Pour cela, il existe un m\u00e9canisme 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 \u2013 chaque couleur \u00e9tant transmise dans son propre canal virtuel sous forme de paquet distinct, bien que dans la structure de ses fichiers, il y ait quelques \u00e9carts par rapport aux normes.<\/i><\/p>\n

    Le champ de drapeau de contr\u00f4le op\u00e9rationnel doit indiquer la pr\u00e9sence ou l'absence d'un champ de contr\u00f4le op\u00e9rationnel dans le fichier de t\u00e9l\u00e9m\u00e9trie. Ces 4 octets \u00e0 la fin du fichier servent \u00e0 maintenir un retour d'information lors du contr\u00f4le de la livraison des fichiers de t\u00e9l\u00e9commandes. Nous en parlerons un peu plus tard.<\/p>\n

    Les compteurs de fichiers principal et de canal virtuel sont des champs qui s'incr\u00e9mentent d'une unit\u00e9 \u00e0 chaque envoi de fichier. Ils servent d'indicateur que aucun fichier n'a \u00e9t\u00e9 perdu.<\/i><\/p>\n

    Le statut des donn\u00e9es du fichier de t\u00e9l\u00e9m\u00e9trie est constitu\u00e9 de deux octets de drapeaux et de donn\u00e9es, parmi lesquels nous examinerons seulement certains.<\/p>\n

    \"Un
    \n
    \nLe champ de drapeau d'en-t\u00eate secondaire (Secondary Header) doit indiquer la pr\u00e9sence ou l'absence d'un en-t\u00eate secondaire dans le fichier de t\u00e9l\u00e9m\u00e9trie.<\/p>\n

    Si souhait\u00e9, un en-t\u00eate suppl\u00e9mentaire peut \u00eatre ajout\u00e9 \u00e0 chaque fichier et y placer toutes les informations \u00e0 sa convenance.<\/i><\/p>\n

    Le champ du pointeur vers le premier en-t\u00eate (First Header Pointer), lorsque le drapeau de synchronisation est \u00e0 \u00ab 1 \u00bb, doit contenir la repr\u00e9sentation binaire de la position du premier octet du premier paquet dans le champ de donn\u00e9es (Data Field) de la trame de t\u00e9l\u00e9m\u00e9trie. La position est compt\u00e9e \u00e0 partir de 0 dans un ordre croissant depuis le d\u00e9but du champ de donn\u00e9es. S'il n'y a pas de d\u00e9but de paquet dans le champ de donn\u00e9es de la trame de t\u00e9l\u00e9m\u00e9trie, alors le champ du pointeur vers le premier en-t\u00eate doit avoir pour valeur dans la repr\u00e9sentation binaire \u00ab 11111111111 \u00bb (cela peut se produire si un long paquet s'\u00e9tend sur plus d'une trame). <\/p>\n

    Si le champ de donn\u00e9es contient un paquet vide (Idle Data), alors le pointeur vers le premier en-t\u00eate doit avoir pour valeur dans la repr\u00e9sentation binaire \u00ab 11111111110 \u00bb. Ce champ est utilis\u00e9 par le r\u00e9cepteur pour synchroniser le flux. Ce champ garantit la restauration de la synchronisation m\u00eame en cas de perte de trames.<\/p>\n

    Ainsi, un paquet peut, disons, commencer au milieu de la 4\u00e8me trame et se terminer au d\u00e9but de la 20\u00e8me. Pour trouver son d\u00e9but, c'est pr\u00e9cis\u00e9ment ce champ qui est utilis\u00e9. Les paquets ont \u00e9galement un en-t\u00eate qui sp\u00e9cifie leur longueur, donc lors de la localisation du pointeur vers le premier en-t\u00eate, le gestionnaire de niveau canal doit le lire, d\u00e9terminant ainsi o\u00f9 le paquet se terminera.<\/i>
    \nSi le champ de contr\u00f4le des erreurs est pr\u00e9sent, il doit se trouver dans chaque trame de t\u00e9l\u00e9m\u00e9trie pour un canal physique sp\u00e9cifique tout au long de la mission.<\/p>\n

    Ce champ est calcul\u00e9 en utilisant la m\u00e9thode CRC. La proc\u00e9dure doit prendre n-16 bits de la trame de t\u00e9l\u00e9m\u00e9trie et ins\u00e9rer le r\u00e9sultat du calcul dans les 16 derniers bits.<\/p>\n

    T\u00e9l\u00e9commandes<\/h4>\n

    \nLa trame de t\u00e9l\u00e9commande pr\u00e9sente plusieurs diff\u00e9rences essentielles. Parmi elles :<\/p>\n

      \n
    1. Une structure d'en-t\u00eate diff\u00e9rente<\/li>\n
    2. Longueur dynamique. Cela signifie que la longueur de la trame n'est pas fix\u00e9e rigidement, comme c'est le cas dans la t\u00e9l\u00e9m\u00e9trie, mais peut varier en fonction des paquets transmis.<\/li>\n
    3. M\u00e9canisme de garantie de livraison des paquets. Cela veut dire que le satellite doit confirmer la r\u00e9ception correcte des trames, ou demander la retransmission \u00e0 partir de la trame qui a pu \u00eatre re\u00e7ue avec une erreur non corrigible.<\/li>\n<\/ol>\n

      \n\"Un
      \n
      \n\"Un
      \n
      \nDe nombreux champs sont d\u00e9j\u00e0 familiers depuis l'en-t\u00eate de la trame de t\u00e9l\u00e9m\u00e9trie. Ils ont la m\u00eame fonction, donc ici nous allons examiner uniquement les nouveaux champs.<\/p>\n

      Un bit du drapeau de contournement doit \u00eatre utilis\u00e9 pour contr\u00f4ler la v\u00e9rification des trames sur le r\u00e9cepteur. Une valeur \u00ab 0 \u00bb de ce drapeau doit indiquer que cette trame est de type A et que sa v\u00e9rification doit \u00eatre effectu\u00e9e conform\u00e9ment au FARM. Une valeur \u00ab 1 \u00bb de ce drapeau doit indiquer au r\u00e9cepteur que cette trame est de type B et doit contourner la v\u00e9rification conform\u00e9ment au FARM.<\/p>\n

      Ce drapeau informe le r\u00e9cepteur s'il doit utiliser le m\u00e9canisme de confirmation de livraison des trames appel\u00e9 FARM \u2014 M\u00e9canisme d'acceptation et de rapport des trames.<\/i><\/p>\n

      Le drapeau de commande de contr\u00f4le doit \u00eatre utilis\u00e9 pour comprendre si le champ de donn\u00e9es transporte une commande ou des donn\u00e9es. Si le drapeau est \u00ab 0 \u00bb, le champ de donn\u00e9es doit contenir des donn\u00e9es. Si le drapeau est \u00ab 1 \u00bb, le champ de donn\u00e9es doit contenir des informations de contr\u00f4le pour le FARM.
      \nLe FARM est une machine \u00e0 \u00e9tats, dont les param\u00e8tres peuvent \u00eatre configur\u00e9s.<\/i><\/p>\n

      RSVD. SPARE \u2013 bits r\u00e9serv\u00e9s.<\/p>\n

      Il semble que le CCSDS ait des plans \u00e0 leur sujet \u00e0 l'avenir, et pour la compatibilit\u00e9 descendante des versions du protocole, ces bits sont d\u00e9j\u00e0 r\u00e9serv\u00e9s dans les versions actuelles de la norme.<\/i><\/p>\n

      Le champ de longueur des trames doit contenir un nombre en repr\u00e9sentation binaire, qui est \u00e9gal \u00e0 la longueur de la trame en octets moins un.<\/p>\n

      Le champ de donn\u00e9es de la trame doit suivre imm\u00e9diatement l'en-t\u00eate sans espace et contenir un entier d'octets, dont la longueur peut aller jusqu'\u00e0 1019 octets. Ce champ doit contenir soit un bloc de donn\u00e9es de trame, soit des informations de commande. Le bloc de donn\u00e9es de la trame doit contenir :<\/p>\n