Banner
Accueil | Tous les Documents
 
Sommaire
page gauche
page droite
page précédente

bag212
  page 1


ETNA – le traitement des données

Après analyse et réflexion, nous avions donc choisi la norme HDLC qui était un protocole orienté sur les bits et qui, en outre, présentait des caractéristiques techniques et stratégiques intéressantes:

- la transparence intégrale des données: il n'y avait aucune ambiguïté entre les données et le caractère de délimitation de bloc; ce qui conduisait à une synchronisation précise, rapide et non équivoque (après une perte de transmission due à un trou de réception, la resynchronisation était immédiatement effective),

- la cohérence dans la transmission grâce au caractère (16 bits) de contrôle de redondance cyclique (CRC – vérification de bloc),

- la démocratisation du protocole lui-même dont les applications étaient nombreuses et l'exploitation facilitée grâce à la disponibilité matérielle de circuits VLSI adaptés à la gestion du protocole.

Trama HDLC

 

 

Le concept arrêté, il restait à mettre en pratique notre choix.

 

 

 

 

Le principe consistait à appliquer la technique de l'accès multiple à répartition dans le temps.

Il s'agissait donc de réaliser, d'une part, l'acquisition de données (informations TM à bord ou instructions TC au sol) issues de plusieurs sources (qui seraient scrutées) à caractère numérique et, d'autre part, leur concentration (compression et sérialisation) sur un canal unique de transmission (TM ou TC): on obtenait ainsi un multiplexage temporel.

Accés Multiple


 

Le résultat du traitement se présentait alors sous la forme d'un message série composé de trames (ou paquets), elles-mêmes conditionnées sous une enveloppe de type HDLC.
Après émission, la redistribution des données consistait à repérer, dans le message global, l'origine de chacune des donnés sources: c'était l'opération de démultiplexage.


La scrutation des voies en entrée du multiplexeur (ou concentrateur) de TM était ordonnée en rapport avec les débits des différentes sources; plus le débit d'une source était élevé, plus celle-ci serait scrutée (ou prélevée) fréquemment. Aucun protocole d'échange n'existait entre les entrées d'un multiplexeur de TM et les sources; ainsi, le système était toujours prêt à acquérir les données présentes sur ses entrées, que celles-ci soient émises de façon continue (informations synchrones) ou intermittente (bouffées ou informations asynchrones).
Toutefois, sachant que les transmissions radioélectriques n'étaient pas exemptes de perturbations dans leurs liaisons et que nous disposions d'un moyen de contrôler la qualité des trames grâce au CRC (dans le démultiplexeur sol), nous avions prévu de fournir à l'expérimentateur un signal d'état de la trame (bonne ou mauvaise) qui lui permettrait d'effectuer le tri parmi son flot de données.
Les mêmes règles de base étant appliquées aux deux fonctions (TM et TC), leur matériel était donc en tous points identiques. Mais, comme il était indispensable d'assurer le service de TC avec efficacité et sécurité, des différences apparaissaient toutefois dans la gestion des données (incidence logicielle).
Si, dans l'application de la fonction TM, on s'en remettait à l'utilisateur pour qu'il fasse ou non, lui-même, le tri parmi ses données pour en extraire celles erronées, le fonctionnement de la TC était, quant à lui, entièrement et automatiquement géré par le système.

Synoptique des transmissions
Ensemble des équipements embarqués et du matériel correspondant en station