FR3079695A1 - Analyse et filtrage de donnees dans un systeme de transmission de donnees - Google Patents
Analyse et filtrage de donnees dans un systeme de transmission de donnees Download PDFInfo
- Publication number
- FR3079695A1 FR3079695A1 FR1852888A FR1852888A FR3079695A1 FR 3079695 A1 FR3079695 A1 FR 3079695A1 FR 1852888 A FR1852888 A FR 1852888A FR 1852888 A FR1852888 A FR 1852888A FR 3079695 A1 FR3079695 A1 FR 3079695A1
- Authority
- FR
- France
- Prior art keywords
- data
- frame
- module according
- unit
- module
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000001914 filtration Methods 0.000 title claims abstract description 26
- 230000005540 biological transmission Effects 0.000 title claims abstract description 22
- 238000004458 analytical method Methods 0.000 title description 2
- 238000012545 processing Methods 0.000 claims abstract description 50
- 230000015654 memory Effects 0.000 claims abstract description 26
- 238000007405 data analysis Methods 0.000 claims abstract description 4
- 230000006870 function Effects 0.000 claims description 7
- 238000004364 calculation method Methods 0.000 claims description 5
- 230000001960 triggered effect Effects 0.000 claims description 4
- 230000001360 synchronised effect Effects 0.000 claims description 3
- 238000005538 encapsulation Methods 0.000 description 20
- 238000004891 communication Methods 0.000 description 11
- 230000009471 action Effects 0.000 description 8
- 238000007726 management method Methods 0.000 description 6
- 238000012795 verification Methods 0.000 description 6
- 125000004122 cyclic group Chemical group 0.000 description 5
- 238000000034 method Methods 0.000 description 5
- 238000010586 diagram Methods 0.000 description 3
- 230000008569 process Effects 0.000 description 3
- 230000002123 temporal effect Effects 0.000 description 3
- 230000006399 behavior Effects 0.000 description 2
- 230000007246 mechanism Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000010926 purge Methods 0.000 description 2
- 238000011282 treatment Methods 0.000 description 2
- 238000011144 upstream manufacturing Methods 0.000 description 2
- 101100120298 Rattus norvegicus Flot1 gene Proteins 0.000 description 1
- 101100412403 Rattus norvegicus Reg3b gene Proteins 0.000 description 1
- 230000006978 adaptation Effects 0.000 description 1
- 230000032683 aging Effects 0.000 description 1
- 230000004075 alteration Effects 0.000 description 1
- 238000013475 authorization Methods 0.000 description 1
- 230000001276 controlling effect Effects 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 238000001514 detection method Methods 0.000 description 1
- 230000009977 dual effect Effects 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 239000000284 extract Substances 0.000 description 1
- 238000000605 extraction Methods 0.000 description 1
- 235000003642 hunger Nutrition 0.000 description 1
- 230000007257 malfunction Effects 0.000 description 1
- 238000011084 recovery Methods 0.000 description 1
- 230000001105 regulatory effect Effects 0.000 description 1
- 238000011160 research Methods 0.000 description 1
- 238000005070 sampling Methods 0.000 description 1
- 238000000638 solvent extraction Methods 0.000 description 1
- 238000010561 standard procedure Methods 0.000 description 1
- 230000037351 starvation Effects 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/004—Arrangements for detecting or preventing errors in the information received by using forward error control
- H04L1/0056—Systems characterized by the type of code used
- H04L1/0061—Error detection codes
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/004—Arrangements for detecting or preventing errors in the information received by using forward error control
- H04L1/0045—Arrangements at the receiver end
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/50—Queue scheduling
- H04L47/52—Queue scheduling by attributing bandwidth to queues
- H04L47/528—Minimum bandwidth guarantee
Abstract
La présente invention se rapporte à un module d'analyse et de filtrage de données pour un système de transmission de données comportant : - une unité de réception de trame de données, - une unité de mémoire pour les stocker au fur et à mesure, - au moins une unité de traitement, le résultat dudit traitement étant destiné à être utilisé dans la gestion de la retransmission des données, et - une unité de commande pour déclencher le chargement de données depuis au moins l'un parmi ladite unité de réception et de l'unité de mémoire vers ladite au moins une unité de traitement, ledit chargement et ledit traitement étant réalisés pendant la réception de ladite trame au fur et à mesure du stockage des données dans ladite mémoire.
Description
Analyse et filtrage de données dans un système de transmission de données.
DOMAINE DE L’INVENTION
La présente invention concerne le domaine des télécommunications.
Plus particulièrement, la présente invention concerne le transport de données de manière fiable et déterministe.
ARRIERE-PLAN TECHNOLOGIQUE
Dans un réseau de télécommunications, le transport de données se fait de manière habituelle sous forme de trames de données établies selon un protocole prédéfini. Pour transporter une trame entre un émetteur de données (ou producteur) et un récepteur (ou consommateur), on utilise habituellement un commutateur réalisé à partir d’unités de traitement contrôlées par un logiciel. Un exemple classique de commutateur réseau est le commutateur Ethernet.
Ce type de commutateur ne permet pas de garantir de façon sûre ni la délivrance effective de la trame de données ni un délai maximal de transmission de cette trame. L’utilisation de tels commutateurs dans les systèmes dits « critiques >> ou la fiabilité totale des transmissions est nécessaire n’est donc pas possible. En outre, ce type de commutateur est généralement limité à une utilisation selon un protocole de communication physique et logique unique.
Ainsi, il existe un besoin pour un système de communication de données permettant la communication de données de manière intègre et dans un délai maximal garanti, sans limitation d’utilisation d’un protocole particulier.
La présente invention s’inscrit dans ce contexte.
RESUME DE L’INVENTION
Selon un aspect de l’invention, il est prévu un module d’analyse et de filtrage de données pour un système de transmission de données comportant :
- une unité de réception de trame de données à retransmettre,
- une unité de mémoire pour stocker lesdites données de ladite trame au fur et à mesure de leur réception par l’unité de réception,
AD/3030525/vl
- au moins une unité de traitement pour réaliser un traitement sur au moins une donnée stockée dans ladite unité de mémoire, le résultat dudit traitement étant destiné à être utilisé dans la gestion de la retransmission des données, et
- une unité de commande pour déclencher le chargement de données depuis au moins l’un parmi ladite unité de réception et de l’unité de mémoire vers ladite au moins une unité de traitement, ledit chargement et ledit traitement étant réalisés pendant la réception de ladite trame au fur et à mesure du stockage des données dans ladite mémoire.
Un module selon le premier aspect permet une parallélisation maximale de l’arrivée d’une trame, de son décodage et de son filtrage ce qui augmente les performances (vitesse de traitement).
Un module selon le premier aspect permet une compatibilité multiprotocoles.
Il peut aussi permettre une augmentation de la sécurité intrinsèque du traitement de données car son implémentation entièrement matérielle ne permet pas de modification de son comportement et que ses capacités à fonctionner plus rapidement que l’arrivée de toute donnée assure sa disponibilité permanente.
Selon des modes de réalisation le fonctionnement du module est synchrone. Par exemple, l’unité de commande est une machine à états finie.
Par exemple encore, l’unité de mémoire comporte un ensemble de registres. Selon des modes de réalisation, le chargement de données est déclenché en fonction de la disponibilité desdites données dans un registre donné.
Selon des modes de réalisation, le module comporte une unité de traitement permettant le contrôle d’intégrité de ladite trame en cours de réception.
Par exemple, le contrôle d’intégrité porte sur une donnée chargée depuis ladite unité de réception.
Selon des modes de réalisation, le module comporte une unité de traitement qui permet le contrôle de la validité de ladite trame en cours de réception.
Par exemple, l’unité de traitement permettant le contrôle de la validité de ladite trame en cours de réception opère un traitement dichotomique de ladite trame.
Selon des modes de réalisation, l’unité de traitement permettant le contrôle de la validité de ladite trame en cours de réception comporte une pluralité d’étages en série.
Selon des modes de réalisation, au moins un étage de l’unité de traitement comporte une pluralité de sous-étages parallèles.
AD/3030525/vl
Par exemple, le module comporte une unité de traitement (503) permettant la réalisation de calculs spécifiques pour alimenter au moins l’un parmi un étage et un sous-étage de ladite unité de traitement permettant le contrôle de la validité de ladite trame en cours de réception.
Selon des modes de réalisation, l’unité de commande permet en outre de commander l’unité de réception en fonction d’information reçue de ladite au moins une unité de traitement.
Par exemple, le module est configuré pour générer une sortie indiquant une anomalie de réception de ladite trame en fonction d’information reçue de ladite au moins une unité de traitement.
Par exemple encore, le module est configuré pour générer une sortie indiquant le contenu de ladite unité de mémoire en fonction d’information reçue de ladite au moins une unité de traitement.
Selon des modes de réalisation, le module est configuré pour générer un pointeur en sortie par au moins une unité de traitement pointant vers un espace mémoire du système contenant une structure de données pour encapsuler ladite trame de données à retransmettre.
Selon des modes de réalisation, le module est réalisé dans un circuit programmable ou un circuit intégré propre à une application (ASIC).
BREVE DESCRIPTION DES FIGURES
D’autres caractéristiques et avantages de l’invention apparaîtront à la lecture de la présente description détaillée qui suit, à titre d’exemple non limitatif, et des figures annexées parmi lesquelles:
- la figure 1 illustre un système selon des modes de réalisation;
la figure 2 illustre la transmission d’une donnée selon des modes de réalisation,
- les figures 3a-3b illustrent la réception d’une donnée (ou message) par un module d’échange selon des modes de réalisation,
- la figure 4 illustre le traitement d’une trame conforme au standard IEEE 802.3 selon des modes de réalisation,
- la figure 5 est un schéma illustrant un module de filtrage selon des modes de réalisation.
AD/3030525/vl
DESCRIPTION DETAILLEE DE L’INVENTION
Un système selon des modes de réalisation est décrit en référence à la figure 1.
Le système représenté sur cette figure est réalisé de manière matérielle, c’est-à-dire qu’il n’est pas contrôlé de manière logicielle. Le système est par exemple réalisé sous forme de circuit de type FPGA (acronyme de « Field-Programmable Gâte Array >>).
Le système comporte un ou plusieurs modules d’échange de données 100 (ComSet) et un ou plusieurs modules de base de données 101 (Station de base).
Chaque base de données permet le stockage de données échangées entre les modules d’échange. Le nombre de modules d’échange est égal au nombre de ports de communication souhaités pour le système. Ces ports de communication sont connectés
Les modules d’échange 100 peuvent être connectés à une base de données 101 au moyen d’une interface standardisée, c’est-à-dire que l’interface est la même pour tous les modules de communication. L’interface standard comporte autant de bus de transport de données que de modules en communication directe avec la base de données.
Par exemple, un module 112 est en charge d’encapsuler des trames de données reçues et à traiter au sein du système. Ce module communique avec la base de données via un bus dédié 102. Un module 113 est par exemple en charge de la génération de commandes à destination de la base de données pour extraire une donnée à retransmettre. Ce module communique avec la base de données via un bus dédié 103. Un module 115 est en charge de recevoir des trames encapsulées de la part de la base de données et de les traiter pour une retransmission. Ce module communique avec la base de données via un bus dédié 105. Un module 114 est en charge de gérer les émissions de la part de la base de données indiquant certains évènements tel que le stockage de trames encapsulées. Cette gestion inclut par exemple la coordination des modules 113 et 115. Ce module communique avec la base de données via un bus dédié 104. Un module d’horloge 116 est en charge de de réceptionner les mises à jour de l’heure générale du système depuis la station de base. Par ailleurs, il fournit l’heure à tous les modules du système de transmission de données qui doivent soit marquer les données, soit vérifier les délais de transmission de celles-ci. Le module d’horloge peut aussi générer les évènements pour la fourniture des signaux de synchronisation au processus qui en ont fait la demande. Il peut en outre prévenir les modules d’émission
AD/3030525/vl de données du moment de l’envoi de données lorsqu’elles sont définies comme cycliques par le paramétrage. Le module d’horloge communique avec la base de données via un bus dédié 106.
Les bus de communication sont par exemple basés sur des mémoires à double accès qui permettent une indépendance de fonctionnement des modules amonts et avals. Ils permettent une latence minimale et ont une bande passante très supérieure au débit maximal de chaque transmission et peuvent donc fonctionner en mode famine.
Les données échangées par un module d’échange sont reçues et envoyées au travers d’une interface 107 configurée en fonction du protocole utilisé à l’extérieur du système. Des exemples de protocoles avec lesquels le système peut être interfacé sont Ethernet, CAN, ARINC 664P7 ou autres. Le module 107 peut communiquer avec les autres modules du système via des interfaces asynchrones dédiées.
La communication entre les différents sous-modules 112, 113, 114, 115 de chaque module d’échange avec les interfaces avec les bus de communication respectifs 102, 103, 104, 105 se fait via des dispositifs 108, 109, 110, 111 permettant de garantir l’indépendance des sous-modules en termes de fréquence d’accès et d’espace de stockage. Par exemple, il s’agit de dispositifs de type DAM (acronyme de « Dual Access Memory >>).
Le module 117 est un module de traitement des trames de données reçues avant leur encapsulation par le module 112. Il est décrit plus en détails dans la suite.
A l’inverse, le module 118 permet de des-encapsuler une trame encapsulée reçue du module 115.
Un module de gestion de statut 119 est en charge de garder les états de fonctionnement courant de chacun des modules du système de transmission de données si le paramétrage le demande. De plus tous les modules sont conçus pour transmettre tout incident de fonctionnement à ce module de gestion de statut qui met alors à jour sa base d’information et génère un évènement d’erreur immédiatement si le paramétrage le demande vers le système de transmission de données destiné à cet effet.
En référence à la figure 2, on décrit la transmission d’une donnée (ou message) par un module d’échange 200.
Le message 201 est reçu au niveau du module d’interface 202. Ce module d’interface est en charge du dialogue avec les composants responsables de la gestion physique des signaux du protocole lié au système de transmission de données. Il récupère l’information des trames reçues via ces composants et les transmet octet par
AD/3030525/vl octet au module suivant. Le message 201 est ensuite transmis au module 203 en charge de l’analyse et du filtrage du message (fonctionnement décrit plus en détail dans ce qui suit).
Le module 203 vérifie l’intégrité du message et vérifie aussi que le message est autorisé, par configuration, à être reçu par le module d’échange 200. En d’autres termes, le module 203 extrait les informations de la trame entrante afin de s’assurer que l’adresse IP source et le port source du message ainsi que sa taille sont bien tels que le paramétrage les a définis. D’autre part le calcul du CRC permet de vérifier que la trame reçue est bien intègre.
Le message est ensuite encapsulé dans un module d’encapsulation 204. Une fois encapsulé, le message est traité indépendamment du protocole utilisé pour le transporté à l’extérieur du système. Le message encapsulé est ensuite transmis à la base de données 205, via le bus 206, pour stockage en mémoire.
Le message encapsulé peut être stocké en prenant en compte différents paramètres. Il s’agit par exemple d’éviter la duplication d’information en mémoire. L’enregistrement d’un message est unique même si il possède plusieurs destinataires. Chaque destinataire et prévenu de l’arrivée de la donnée ainsi que de son emplacement. Les destinataires sont alors autorisés à venir l’y chercher pour transmission. L’heure d’arrivée de la donnée fait aussi partie des données d’encapsulation afin que les récepteurs de l’information puissent contrôler la validité temporelle de celle-ci. Il s’agit par exemple encore de tenir compte du vieillissement du message. Il s’agit par exemple encore de gérer les méthodes d’accès au message qui définissent les adresses des objets en mémoire (on peut par exemple citer les méthodes dites de « Sampling », « Queuing », « Flip/Flop » qui sont des méthodes standard.
En référence aux figures 3a-3b, on décrit la réception d’une donnée (ou message) par un module d’échange 300.
A la suite du stockage du message encapsulé dans la base de données 205 décrite ci-dessus en référence à la figure 2, une donnée de type « évènement >> est envoyée au module 300 à qui le message 201 est destiné via le bus 304. Une donnée de type « évènement >>. Une donnée de type « évènement >> est un objet au format d’encapsulation commun dont l’objet et de prévenir le module destinataire soit du comportement d’un autre module soit d’une action à accomplir pour ce dernier.
La base de données 205 (commune aux modules 200 et 300) génère et gère les évènements relatifs à l’émission d’un message encapsulé. La base de données cadence aussi les moments de transmission des données de type « évènement >> aux
AD/3030525/vl modules d’échange qui doivent émettre le message encapsulé concerné par la donnée. Le module d’émission est prévenu par message que la donnée à émettre est disponible et où aller la chercher.
La donnée de type « évènement >> est ensuite reçue par un module 301 de gestion des émissions cycliques et événementielles en charge de la réception de ces données. Sur réception d’une telle donnée le module 301 envoie une demande de commande à destination du module de génération de commandes 302.
Le module de génération de commandes 302 envoie ensuite une commande à destination de la base de données afin que l’objet encapsulé soit envoyé vers le module d’échange 300.
En parallèle, le module 301 envoie une demande de mise en mode attente du message encapsulé au module 303 de génération de données à émettre.
Le module 302 joue ainsi un rôle de gestion du cycle (en particulier de la fréquence) d’envoi des messages.
La base de données envoie ensuite le message encapsulé via le bus 305 au module 303 qui désencapsule le message pour en faire un message conforme au protocole de l’équipement connecté sur le port physique du module d’échange 300.
Le message ainsi desencapsulé est transmis via un module 306 de contrôle de l’émission et le module d’interface 307. Ce module de contrôle après une dernière vérification de l’intégrité de la donnée à l’aide du code de contrôle (CRC) vérifie aussi que les informations contenues correspondent bien à tous les critères définis par le paramétrage du port de sortie.
Dans ce qui suit, on décrit les opérations réalisées par le module d’analyse et de filtrage d’un module d’un module d’échange.
Le filtrage intervient entre la réception d’une trame et son encapsulation. Le filtrage a pour objectif de vérifier que la trame reçue est bien une trame connue, attendue et bien formée. Si ce n’est pas le cas, la trame est rejetée et un message d’erreur est généré. Le filtrage a aussi pour objectif de fournir, si la trame et acceptée, l’information des emplacements où les données nécessaires à l’encapsulation de la trame peuvent être récupérées.
D’une manière générale, le filtrage, dans le domaine des réseaux, est l’opération qui consiste à vérifier l’intégrité et la validité d’une trame en réception.
La vérification de l’intégrité de la trame permet de s’assurer qu’une trame reçue respecte des propriétés liées à sa structure.
AD/3030525/vl
Parmi les vérifications effectuées on trouve par exemple les altérations au niveau logique élémentaire (bit ou ensemble de bits). La vérification est réalisée grâce à un code détecteur d’erreurs du type contrôle de redondance cyclique ou CRC (acronyme de « Cyclic Redundancy Check »).
On trouve aussi parmi les vérifications effectuées le fait que l’arrivée de deux trames successives doit respecter un délai minimum (on parle d’IFG, acronyme de « InterFrame Gap >>). Si ce délai n’est pas respecté, la trame est considérée corrompue.
D’autres vérifications sont possibles comme par exemple les intervalles de longueur de la trame, notés [LMAX, LMIN] qui peuvent dépendre des protocoles. Une trame peut avoir une taille fixe (c’est par exemple le cas dans le protocole Arinc 429) ou une taille variable bornée en valeurs inférieure et supérieure (par exemple le protocole Ethernet 802.3). En plus des restrictions normatives, l’utilisateur peut durcir les conditions sur les tailles. Quand la trame ne respecte pas les contraintes de taille, elle est considérée corrompue.
La vérification de la validité permet de s’assurer qu’une trame reçue à un point de réception donné est bien autorisée à être reçue à cet endroit (le vocable « endroit >> sous-entend « port de communication >> dans la terminologie réseau). La prise de décision de l’autorisation se base sur les données d’encapsulation de la trame. Si on prend l’exemple des trames de type IP (acronyme de « Internet Protocol >>), respectant le standard IEEE 802.3, les données d’encapsulation sont à récupérer des champs de la pile protocolaires tels que : « IP sources », « EtherType », « MAC source », « MAC destination », etc.
Chaque trame qui passe par le module de filtrage provoque une prise de décision binaire, donc avec deux états stables et aucune indécision possible : la trame passe le filtrage ou la trame ne passe pas le filtrage. Toute violation d’intégrité et/ou de validité de la trame provoque son rejet (trame ne passe donc pas le filtrage).
Deux actions sont alors déclenchées. Une première action est la suppression (purge) de la trame du module de filtrage. Une deuxième action est une levée d’un statut d’erreur par le contrôle du module de gestion du statu évoqué ci-avant. Les statuts peuvent être gérés de différentes manières. Par exemple, il est possible de choisir l’envoi d’une information d’état de façon cyclique et ce, avec une périodicité paramétrable, ou d’émettre un évènement dès la survenance d’un évènement particulier vers le module et le système de transmission de données paramétrés à cet effet. Les statuts peuvent être actifs et donc pris en compte ou masqués et donc ignorés.
AD/3030525/vl
Dans le cas où aucune violation des règles d’intégrité et de validité n’est détectée, la trame est acceptée dans le système, autrement dit, la trame passe le filtrage.
Deux actions sont alors déclenchées. Une première action est la fourniture de la trame au module suivant (c’est-à-dire le module d’encapsulation). Une deuxième action est la génération d’un pointeur vers les tables d’encapsulation qui permet de trouver, dans les mémoires internes, les données de certains champs d’encapsulation objet (sur-encapsulation de la trame).
L’encapsulation d’une trame est en fait une sur-encapsulation. Une trame est déjà une encapsulation des données utiles par des champs propres au protocole. Ici, il s’agit d’ajouter d’autres champs. Il est alors possible de parler de sur-encapsulation. Certains champs sont calculés et chargés en mémoire par un configurateur en mode hors-ligne (avant le démarrage de la phase opérationnelle) et d’autres champs sont calculés par le composant en mode en-ligne (pendant la phase opérationnelle).
Une particularité du module de filtrage, outre le fait qu’il soit conçu pour une implémentation exclusivement matérielle, est la garantie d’une performance très élevée comparativement aux systèmes existants sur le marché. L’aspect « implémentation matérielle >> ici fait opposition à une mise en oeuvre logicielle basée sur un schéma type Von Neumann. Le module de filtrage, comme le module d’échange de données auquel il appartient est implantable dans des circuits programmables type FPGA (acronyme de « Field-Programmable Gâte Array » ou ASIC (acronyme de « application-specific integrated circuit »). La performance allie à la fois débit élevé et déterminisme temporel.
Le fonctionnement du module de filtrage comporte une base de registres de réception des trames, des modules de dichotomie, et une machine d’état de contrôle.
Tout le mécanisme du module de filtrage est cadencé par une machine d’état de contrôle qui pousse dans une structure de registres la trame au fur et à mesure qu’elle est reçue, et, à des moments opportuns, charge des données particulière et/ou fait des calculs sur certaines de ces données.
Avant même la fin de la réception de la trame, le filtrage, qui utilise des tables de dichotomie pour la recherche des informations et actions à effectuer, est déjà lancé car toutes les informations nécessaires sont rendues disponibles.
Au besoin, il est possible d’arrêter l’opération, et de purger le module si, par exemple, une corruption de donnée est détectée via les mécanismes de protection (tels que le CRC (acronyme de « Cyclic redundancy check » ou les sommes de contrôle « checksum » en anglais).
AD/3030525/vl
Dans ce fonctionnement, plusieurs traitements son parallélisés. En effet, quand l’arrivée d’une trame est détectée, celle-ci est dé-sérialisée au fil de son arrivée. A chaque fois qu’un nombre suffisant de bits est correctement reçu, la machine d’état remplit un registre de réception dans la base de registres prévue à cet effet. Chaque registre est clairement identifié. Ainsi, en fonction du protocole de la trame en cours de réception, il est possible de récupérer à la volée des informations particulières pour les besoins, soit de traitement, soit de passage de paramètres pour une fonction donnée.
L’exemple d’une trame conforme au standard IEEE 802.3 est décrit en référence à la figure 4.
Dans l’exemple d’une telle trame, les 6 premiers octets reçus sont l’adresse MAC destination, les 6 octets suivants sont l’adresse MAC source, les 2 octets suivants sont le champ EtherType. Si pour les besoins du filtrage, le module nécessite les deux derniers octets de l’adresse MAC de destination (numéro du « Virtual Link » dans la norme Arinc 664P7), et si la base de registre est constituée de registres de 32 bits (4 octets) alors la réception du second registre, noté « Reg2 >> dans la figure 4, déclenche une récupération des octets 1 et 2 pour les besoins du traitement (identification du « Virtual Link »).
L’opération de réception et de stockage, en plus des tâches de récupération des paramètres pendant la réception, assure la vérification de l’intégrité des trames : vérification de l’enveloppe de la trame, de l’IFG, de la taille, du CRC, etc.
Les informations récupérées de l’encapsulation (parfois après un traitement dessus) sont utilisées pour s’assurer de la validité de la trame. En d’autres termes, vérifier si la trame est bien autorisée à passer dans la suite du système. Cette activité est prise en charge par les « tables de dichotomie >> appelées aussi « tables de filtrage >>.
Pour une optimisation des performances, le schéma de la dichotomie est divisé en plusieurs étages dont chaque étage peut être lui-même subdivisé en plusieurs parties. Le principe de partitionnement en « étages >> et « parties >> obéit aux deux règles suivantes. Les « étages >> sont « pipelinés >>, c’est-à-dire, les sorties d’un « étage >> d’ordre n-1 sont des entrées pour l’étage d’ordre n. L’exécution de toutes les « parties >> dans un même « étage >> est parallélisée.
Dans un exemple de mise en oeuvre, la dichotomie est organisée en deux étages dont le premier est lui-même subdivisé en deux parties. Chronologiquement, les recherches du premier étage sont parallélisées. Les sorties du premier étages constituent des entrées pour le second étage qui, en sortie, fournit un pointeur vers des
AD/3030525/vl structures mémoires qui permettent au module d’encapsulation de sur-encapsuler de la trame reçue.
La figure 5 est un schéma illustrant un module de filtrage selon des modes de réalisation.
Le fonctionnement global de ce module est synchrone. Ce module utilise une horloge unique distribuée. Il est en outre géré par une machine à états finie 501 (FSM acronyme de « Final State Machine »). L’intérêt de cette manière de faire est de pouvoir maîtriser le déclanchement et la durée de chaque opération ce qui induit une garantie d’un temps de traitement borné et connu, et donc, une garantie de déterminisme temporel.
La trame en réception est dé-sérialisée dans le module d’entrée 500 « DataJN >> qui la stocke au fur et à mesure de son arrivée dans une base de registres 507. Dès la disponibilité d’informations pertinentes dans cette dernière, celles-ci sont récupérées pour être exploitées. Dans l’exemple de la figure 5, le premier octet du premier registre peut être mis à disposition, dès sa réception, du module 502 pour la recherche dichotomique de l’étage 1 partie 2, notée E1P2. Le lancement du bloc 502 nécessite une commande de la machine 501 ainsi que des données complémentaires (notées « data externes >> telle que l’enveloppe de trame et l’horloge).
En parallèle, la réception de la trame continue et d’autres informations sont prélevées à la volée soit pour alimenter les recherches dichotomiques, soit pour alimenter une unité 503 de calcul spécifiques qui alimente par la suite les recherches dichotomiques. L’unité 503 permet de traiter certaines informations d’encapsulation qui ne sont pas utilisables dans leur état brut et/ou doivent être combinées entre elles pour qu’elles soient exploitables par la suite. Par exemple, le module 502 ne peut être lancé qu’après extraction directe de l’octet 2 du registre 2 et mise à disposition d’un résultat de traitement de l’unité 503 basé sur l’octet 1 du registre 2. Le lancement du module 504 comprenant l’étage 2 de la dichotomie, noté E2, ne peut se faire qu’une fois les traitements de l’étage 1 complétés. En effet, les résultats des modules 502 (E1P1) et 505 (la partie 1 de l’étage 1 notée E1P2) sont injectés comme entrées dans le module 504. De plus, ces entrées ne sont pas exclusives. Chaque étage peut avoir besoin d’entrées complémentaires (en plus de celle de l’étage amont). Dans l’exemple de la figure 5, le module 504 nécessite le dernier octet de l’avant-dernier registre ainsi qu’un résultat fourni par l’unité 503.
En parallèle de tous ces traitements, une unité 506 de contrôle d’intégrité vérifie que la trame en réception ne comporte pas d’anomalie. Les vérifications portent
AD/3030525/vl sur plusieurs paramètres tel que par exemple le CRC, la longueur, l’IFG, ou autre. Cette unité informe la machine 501 du statut de la réception en cours et lève une anomalie le cas échéant.
Tout au long du fonctionnement, des statuts sont générés et échangés afin de prévenir tout dysfonctionnement et détecter toute anomalie.
Les sorties du modules de filtrage peuvent être au nombre de un ou trois selon l’état final de la machine d’état de contrôle. Une sortie est un mot de statut contenant l’état final de la machine d’état avec, le cas échéant, une indication (communément appelée drapeau ou « flag » en anglais) à propos de l’anomalie constatée. Si le traitement s’est correctement déroulé, alors le module de filtrage fournit en plus le contenu de la base de registres qui n’est autre que la trame reçue et un pointeur, issu du dernier étage de la dichotomie, sur les structures mémoires permettant de créer l’objet issu de l’encapsule de la trame.
La présente invention a été décrite et illustrée dans la présente description détaillée en référence aux figures jointes. Toutefois la présente invention ne se limite pas aux formes de réalisation présentées. D’autres variantes, modes de réalisation et combinaisons de caractéristiques peuvent être déduits et mis en oeuvre par la personne du métier à la lecture de la présente description et des figures annexées.
Pour satisfaire des besoins spécifiques, une personne compétente dans le domaine de l’invention pourra appliquer des modifications ou adaptations.
Dans les revendications, le terme “comporter” n’exclut pas d’autres éléments ou d’autres étapes. L’article indéfini « un >> n’exclut pas le pluriel. Une ou plusieurs autres unités peuvent être utilisées pour mettre en oeuvre l’invention. Les différentes caractéristiques présentées et/ou revendiquées peuvent être avantageusement combinées. Leur présence dans la description ou dans des revendications dépendantes différentes, n’exclut pas en effet la possibilité de les combiner. Les signes de référence ne sauraient être compris comme limitant la portée de l’invention.
Claims (17)
1. Module d’analyse et de filtrage de données (117, 203) pour un système de transmission de données comportant :
- une unité de réception (500) de trame de données à retransmettre,
- une unité de mémoire (507) pour stocker lesdites données de ladite trame au fur et à mesure de leur réception par l’unité de réception,
- au moins une unité de traitement (505, 502, 504) pour réaliser un traitement sur au moins une donnée stockée dans ladite unité de mémoire, le résultat dudit traitement étant destiné à être utilisé dans la gestion de la retransmission des données, et
- une unité de commande (501) pour déclencher le chargement de données depuis au moins l’un parmi ladite unité de réception et de l’unité de mémoire vers ladite au moins une unité de traitement, ledit chargement et ledit traitement étant réalisés pendant la réception de ladite trame au fur et à mesure du stockage des données dans ladite mémoire.
2. Module selon la revendication 1, dans lequel le fonctionnement du module est synchrone.
3. Module selon l’une des revendications précédentes, dans lequel ladite unité de commande est une machine à états finie.
4. Module selon l’une des revendications précédentes, dans lequel ladite unité de mémoire comporte un ensemble de registres.
5. Module selon la revendication 4, dans lequel le chargement de données est déclenché en fonction de la disponibilité desdites données dans un registre donné.
6. Module selon l’une des revendications précédentes, comportant une unité (506) de traitement permettant le contrôle d’intégrité de ladite trame en cours de réception.
7. Module selon la revendication 6, dans lequel le contrôle d’intégrité porte sur une donnée chargée depuis ladite unité de réception.
8. Module selon l’une des revendications précédentes, comportant une unité de traitement qui permet le contrôle de la validité de ladite trame en cours de réception.
9. Module selon la revendication 8, dans lequel ladite unité de traitement permettant le contrôle de la validité de ladite trame en cours de réception opère un traitement dichotomique de ladite trame.
10. Module selon l’une des revendications 8 à 9, dans lequel ladite unité de traitement permettant le contrôle de la validité de ladite trame en cours de réception comporte une pluralité d’étages en série (505, 502, 504).
11. Module selon la revendication 10, dans lequel au moins un étage de l’unité de traitement comporte une pluralité de sous-étages parallèles (502, 505).
12. Module selon l’une des revendications 10 et 11, comportant une unité de traitement (503) permettant la réalisation de calculs spécifiques pour alimenter au moins l’un parmi un étage et un sous-étage de ladite unité de traitement permettant le contrôle de la validité de ladite trame en cours de réception.
13. Module selon l’une des revendications précédentes, dans lequel ladite unité de commande (501) permet en outre de commander l’unité de réception (500) en fonction d’information reçue de ladite au moins une unité de traitement (505, 502, 504).
14. Module selon l’une des revendications précédentes, configuré pour générer une sortie indiquant une anomalie de réception de ladite trame en fonction d’information reçue de ladite au moins une unité de traitement.
15. Module selon l’une des revendications précédentes, configuré pour générer une sortie indiquant le contenu de ladite unité de mémoire en fonction d’information reçue de ladite au moins une unité de traitement.
16. Module selon la revendication 15, configuré pour générer un pointeur en sortie par au moins une unité de traitement pointant vers un espace mémoire du système contenant une structure de données pour encapsuler ladite trame de données à retransmettre.
17. Module selon l’une des revendications précédentes réalisé dans un circuit programmable ou un circuit intégré propre à une application (ASIC).
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR1852888A FR3079695B1 (fr) | 2018-04-03 | 2018-04-03 | Analyse et filtrage de donnees dans un systeme de transmission de donnees |
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR1852888 | 2018-04-03 | ||
| FR1852888A FR3079695B1 (fr) | 2018-04-03 | 2018-04-03 | Analyse et filtrage de donnees dans un systeme de transmission de donnees |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| FR3079695A1 true FR3079695A1 (fr) | 2019-10-04 |
| FR3079695B1 FR3079695B1 (fr) | 2022-11-18 |
Family
ID=63294313
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR1852888A Expired - Fee Related FR3079695B1 (fr) | 2018-04-03 | 2018-04-03 | Analyse et filtrage de donnees dans un systeme de transmission de donnees |
Country Status (1)
| Country | Link |
|---|---|
| FR (1) | FR3079695B1 (fr) |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO1997031455A1 (fr) * | 1996-02-23 | 1997-08-28 | Allied Telesyn International Corporation | Procede et appareil de commutation de paquets sur un reseau de donnees |
| US6032190A (en) * | 1997-10-03 | 2000-02-29 | Ascend Communications, Inc. | System and method for processing data packets |
| US6647528B1 (en) * | 2000-11-02 | 2003-11-11 | Computer Network Technology Corporation | Fiber channel CRC for internal error checking on a switching platform |
-
2018
- 2018-04-03 FR FR1852888A patent/FR3079695B1/fr not_active Expired - Fee Related
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO1997031455A1 (fr) * | 1996-02-23 | 1997-08-28 | Allied Telesyn International Corporation | Procede et appareil de commutation de paquets sur un reseau de donnees |
| US6032190A (en) * | 1997-10-03 | 2000-02-29 | Ascend Communications, Inc. | System and method for processing data packets |
| US6647528B1 (en) * | 2000-11-02 | 2003-11-11 | Computer Network Technology Corporation | Fiber channel CRC for internal error checking on a switching platform |
Also Published As
| Publication number | Publication date |
|---|---|
| FR3079695B1 (fr) | 2022-11-18 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP2793431B1 (fr) | Méthode distribuée d'acquisition de données dans un réseau afdx | |
| EP2885899B1 (fr) | Dispositif et procédé de transfert unidirectionnel de données | |
| FR3039023A1 (fr) | Dispositif et procede d'exploitation d'un systeme | |
| FR3011958A1 (fr) | Reseau de transmission de donnees pour aeronef | |
| FR2867338A1 (fr) | Procede et dispositif de commutation entre des agents | |
| EP2923461B1 (fr) | Dispositif et procédé de retransmission de données dans un commutateur réseau | |
| FR2925191A1 (fr) | Architecture de traitement numerique a haute integrite a multiples ressources supervisees | |
| FR3011999A1 (fr) | Reseau de transmission de donnees pour aeronef | |
| FR2824434A1 (fr) | Procede de diffusion d'un paquet de donnees au sein d'un reseau commute, base sur un calcul optimise de l'arbre de recouvrement | |
| EP3123330A1 (fr) | Composant electronique a reponse deterministe | |
| WO2020109733A2 (fr) | Gestion des données pour le stockage de trames de données dans la mémoire d'un système de transmission de données | |
| FR3071118A1 (fr) | Dispositif electronique et procede de reception de donnees via un reseau de communication rebonde, systeme de communication et programme d'ordinateur associes | |
| FR3079695A1 (fr) | Analyse et filtrage de donnees dans un systeme de transmission de donnees | |
| WO2020089558A1 (fr) | Système de transmission de données | |
| FR3030162A1 (fr) | Procede d'echange de trames de donnees numeriques et systeme de communication associe | |
| EP3654613B1 (fr) | Protocole de transmission d'un flux de données transitant entre un ordinateur hôte et un client distant | |
| EP3637645B1 (fr) | Dispositif électronique et procédé de réception de données via un réseau de communication redondé, système de communication et programme d'ordinateur associés | |
| EP2740039B1 (fr) | Dispositif pour echanger des donnees entre au moins deux applications | |
| EP3748935B1 (fr) | Procédé de stockage de fichiers numériques mis en oeuvre par un réseau avionique déterministe et à routage prédéterminé, et système de communication avionique associé | |
| WO2021105262A1 (fr) | Système de gestion des données partagées | |
| EP4027619A1 (fr) | Système d extrémité pour un système de communication avionique et système de communication avionique associé | |
| WO2016185143A1 (fr) | Système de traitement de données numériques multimedia | |
| EP3005625B1 (fr) | Composant et procede de gestion de communication | |
| FR3001311A1 (fr) | Interface reseau d'un soc comportant un controleur de communication ameliore | |
| EP2929657A1 (fr) | Dispositif d'entrées sorties transférant et/ou recevant des données à un dispositif de contrôle |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EXTE | Extension to a french territory |
Extension state: PF |
|
| PLSC | Publication of the preliminary search report |
Effective date: 20191004 |
|
| PLFP | Fee payment |
Year of fee payment: 2 |
|
| ST | Notification of lapse |
Effective date: 20191206 |
|
| PLFP | Fee payment |
Year of fee payment: 4 Year of fee payment: 3 |
|
| RN | Application for restoration |
Effective date: 20200429 |
|
| FC | Decision of inpi director general to approve request for restoration |
Effective date: 20200504 |
|
| PLFP | Fee payment |
Year of fee payment: 4 |
|
| PLFP | Fee payment |
Year of fee payment: 5 |
|
| TP | Transmission of property |
Owner name: CETRAC.IO, FR Effective date: 20230307 |
|
| PLFP | Fee payment |
Year of fee payment: 6 |
|
| PLFP | Fee payment |
Year of fee payment: 7 |