FR2918233A1

FR2918233A1 - Procede et dispositif d'echange de donnees de diagnostic pour la simulation de reseaux d'ordinateurs d'aeronefs

Info

Publication number: FR2918233A1
Application number: FR0756130A
Authority: FR
Inventors: Franck Dessertenne
Original assignee: Airbus Operations SAS
Current assignee: Airbus Operations SAS
Priority date: 2007-06-28
Filing date: 2007-06-28
Publication date: 2009-01-02
Anticipated expiration: 2027-06-28
Also published as: US8300645B2; FR2918233B1; US20090010174A1

Abstract

L'invention a pour objet un procédé et un dispositif d'échange de données de diagnostic pour la simulation de réseaux d'ordinateurs d'aéronefs. L'échange de données de diagnostic est réalisé dans un réseau entre un noeud du réseau et un terminal de diagnostic connecté au réseau. Le noeud du réseau est apte à recevoir des commandes de simulation en temps réel et des commandes de diagnostic. Selon l'invention, le noeud du réseau est apte à recevoir des commandes de simulation selon au moins une période de temps prédéterminée, une ségrégation temporelle étant réalisée pour l'émission des données de diagnostic par rapport au traitement des commandes de simulation.

Description

La présente invention concerne un procédé et un dispositif d'échanges de

données de diagnostic sur un réseau, notamment sur un réseau de type switch fabric . Un réseau de type switch fabric est basé sur une architecture commutée, c'est-à-dire que les équipements terminaux chargés de l'émission et de la réception des données s'organisent autour des commutateurs ( switch en terminologie anglo-saxonne) chargés du transport de ces données, à N entrées et N sorties. La communication est réalisée par l'envoi et la réception de paquets, ces derniers étant émis en parallèle. De manière plus générale, l'invention concerne, dans un réseau de simulation de composants d'un aéronef en temps réel, le diagnostic de ces composants. La simulation de composants d'un aéronef est utilisée pour assurer le développement et l'intégration des systèmes électroniques et informatiques embarqués dans les aéronefs, en particulier avant le premier vol.

L'architecture de simulation comprend une pluralité de terminaux aussi appelés noeuds du réseau, chacun de ces terminaux réalisant des calculs de simulation ou constituant une interface électronique permettant de vérifier le fonctionnement des équipements réels de l'aéronef. Ainsi, cette architecture comprend notamment un terminal de simulation apte à échanger des données selon une séquence synchrone en utilisant le principe requête / réponse. Les noeuds du réseau désignent le noeud de calcul principal ou les cartes d'entrée / sortie d'interfaces électroniques. L'échange des données entre les différents noeuds du réseau est réalisé sur un port UDP ( User Datagram Protocol en terminologie anglo-saxonne) spécifique et en temps réel, c'est-à-dire que la simulation des comportements des équipements est réalisée à la vitesse de leur déroulement réel. Elle s'appuie en particulier sur un protocole Ethernet standard.

En transposant la topologie AFDX ( Avionics Full DupleX en terminologie anglo-saxonne) où deux réseaux sont mis en oeuvre en parallèle, dans une optique de redondance, au contexte de simulation sur réseau standard, une solution consiste à envisager une topologie à deux réseaux commutés garantissant une ségrégation des flux : - un réseau dédié simulation ; et, - un réseau dédié diagnostic. Cette solution présente toutefois de réels inconvénients : encombrement et coût plus élevé car tout doit être doublé (commutateurs réseau, câbles réseau, interfaces réseau des noeuds, ressources de traitement numérique des noeuds) Ainsi, la présente invention a pour objet de remédier à au moins un des inconvénients des techniques et processus de l'art antérieur décrit. Pour ce faire, l'invention propose notamment un procédé et un dispositif d'échanges de données de diagnostic entre les noeuds du réseau commuté en respectant les contraintes fortes telles que la non perturbation du déroulement en temps réel de la simulation et des transferts de données associés. L'invention a ainsi pour objet un procédé d'échange de données de diagnostic dans un réseau entre des noeuds clients du réseau et un noeud serveur, encore appelé terminal de diagnostic, connecté au réseau, chaque noeud client du réseau étant apte à recevoir des commandes de diagnostic et des commandes de simulation en temps réel selon au moins une période de temps prédéterminée, le procédé comprenant une ségrégation temporelle pour l'émission des données de diagnostic par rapport au traitement des commandes de simulation. Le procédé selon l'invention permet ainsi de ne pas perturber l'exécution en temps réel d'un procédé de simulation. Selon un mode de réalisation particulier, le procédé comprend les étapes suivantes pour déterminer la période durant laquelle des données de diagnostic peuvent être émises par les noeuds clients pour limiter les perturbations de simulation : 3 - détermination de la date de la fin du traitement d'une commande de simulation ; - détermination de la date de la prochaine réception d'une nouvelle commande de simulation en fonction de ladite au moins une période de temps prédéterminée ; - détermination d'un intervalle de temps entre la date de la fin du traitement d'une commande de simulation et la date de la prochaine réception d'une nouvelle commande de simulation ; et - émission des données de diagnostic via le réseau durant l'intervalle de temps ainsi déterminé. Avantageusement, le procédé comprend en outre une étape de réduction de l'intervalle de temps d'une durée déterminée pour limiter les risques d'interférence entre les fonctions de simulation et de diagnostic. Toujours selon un mode de réalisation particulier, l'émission de données de diagnostic n'est réalisée par les noeuds clients que si la largeur de la fenêtre d'émission est suffisante, c'est-à-dire supérieure à un seuil prédéterminé, pour prendre en compte le temps durant lequel le réseau est utilisé par la fonction de diagnostic. L'invention a aussi pour objet un programme d'ordinateur chargeable dans un système informatique, ledit programme contenant des instructions permettant la mise en oeuvre du procédé d'échange de données de diagnostic dans un réseau entre un noeud du réseau et un terminal de diagnostic connecté au réseau tel que décrit précédemment, lorsque ce programme est chargé et exécuté par un système informatique.

L'invention a également pour objet un dispositif d'échange de données de diagnostic dans un réseau entre des noeuds clients du réseau et un noeud serveur (terminal de diagnostic) connecté au réseau, chaque noeud client du réseau étant apte à recevoir des commandes de diagnostic et à recevoir des commandes de simulation en temps réel selon au moins une période de temps prédéterminée, le dispositif comprenant des moyens de ségrégation temporelle pour l'émission des données de diagnostic par rapport au traitement des commandes de simulation.

Le dispositif selon l'invention permet ainsi de ne pas perturber l'exécution en temps réel d'un procédé de simulation. Selon un mode de réalisation particulier, le dispositif comprend les moyens suivants pour déterminer la période durant laquelle des données de diagnostic peuvent être émises pour limiter les perturbations de simulation : - moyens pour déterminer la date de la fin du traitement d'une commande de simulation ; - moyens pour déterminer la date de la prochaine réception d'une nouvelle commande de simulation en fonction de ladite au moins une période 10 de temps prédéterminée ; - moyens pour déterminer un intervalle de temps entre la date de la fin du traitement d'une commande de simulation et la date de la prochaine réception d'une nouvelle commande de simulation ; et - moyens pour émettre des données de diagnostic via le réseau 15 durant l'intervalle de temps. De façon avantageuse, le dispositif comprend en outre des moyens pour réduire la largeur de la fenêtre de d'émission d'une durée déterminée pour limiter les risques d'interférence entre les fonctions de simulation et de diagnostic. 20 Avantageusement, les moyens pour émettre des données de diagnostic comprennent des moyens pour comparer l'intervalle de temps à un seuil prédéterminé, les moyens pour émettre des données de diagnostic étant adaptés à émettre les données de diagnostic si la largeur de la fenêtre d'émission est supérieure à un seuil prédéterminé afin de prendre en compte le 25 temps durant lequel le réseau est utilisé par la fonction de diagnostic. L'invention a également pour objet un noeud réseau comprenant le dispositif d'échange de données de diagnostic tel que décrit précédemment. D'autres avantages, buts et caractéristiques de la présente invention ressortent de la description détaillée qui suit, faite à titre d'exemple non limitatif, 30 au regard des dessins annexés dans lesquels : - la figure 1 illustre une architecture réseau de simulation intégrant un terminal de diagnostic conformément à l'invention ; et - la figure 2 présente un chronogramme illustrant les fenêtres d'émission pour un noeud du réseau déterminé conformément à l'invention. Conformément à l'invention, le diagnostic d'un réseau de simulation de composants, notamment de composants avioniques, est centralisé et 5 intégré. Cette simulation est basée sur des contraintes temps réel fortes, de sorte que celle-ci ne doit nullement être perturbée afin de simuler au mieux le comportement réel des composants. Les fonctionnalités du diagnostic sont notamment les suivantes : - détermination des noeuds réseau qui sont présents, notamment de façon centralisée, c'est-à-dire sans utiliser une connexion point à point entre un outil de diagnostic et chacun des noeuds d'entrée sortie; surveillance en temps réel avec la possibilité de déporter l'interface graphique de surveillance et de diagnostic ; - établir la cartographie des noeuds du réseau et leur configuration, notamment la liste des équipements du réseau et des logiciels ; - consulter ou modifier le paramétrage des noeuds du réseau ; - surveiller les paramètres internes et élaborer des statistiques ; - forcer des voies d'entrée/sortie et d'autres paramètres ; - enregistrer en temps réel des paramètres, notamment en mémoire volatile ; - enregistrer des contextes de panne, notamment en mémoire non volatile ; - obtenir des tables de paramétrage, de configuration, de contextes de panne et d'enregistrement ; et, - gérer des statistiques avancées, telles que la durée de traitement des messages de simulation, de la pile IP ( Internet Protocol en terminologie anglo-saxonne) et de la pile de messages. Selon l'invention, le système de diagnostic est intégré au réseau de simulation et une seule connectique réseau est nécessaire. En outre, la fonction diagnostic est centralisée. 6 Conformément à l'invention, il n'y a pas de charge des terminaux supplémentaires et l'investigation est réalisée en mode opérationnel sans déconnecter les noeuds. Pour ce faire, selon un mode de réalisation de l'invention, le réseau de simulation, illustré en figure 1, comprend un ensemble de noeuds réseau aptes à fonctionner ensemble afin de réaliser la simulation de l'environnement réel non présent et son interface électronique avec l'environnement réel présent comprenant par exemple des calculateurs avioniques, les actuateurs et des capteurs.

Ainsi, chacun des noeuds 10 du réseau 5 est connecté à un commutateur principal 15. Ces noeuds 10 sont notamment des noeuds de calcul, des cartes d'entrée / sortie, des noeuds intermédiaires et des concentrateurs. A ce réseau 5 sont connectés un calculateur principal de simulation 20 (host en terminologie anglo-saxonne) sur le commutateur principal 15 et un équipement de diagnostic 25. Afin de respecter au mieux le temps réel, le réseau est un réseau haut débit, par exemple un réseau de 100 Mbits/s ou de 1 Gbits/s. Conformément à l'invention, il y a ségrégation spatiale et temporelle, c'est-à-dire un partitionnement, des fonctions de simulation et de diagnostic. En effet, il y a ségrégation spatiale par serveurs, notamment en ayant un terminal de simulation et un terminal de diagnostic distincts. Il y a également ségrégation temporelle des données, puisque des périodes de temps, appelées fenêtres d'émission , sont mises en place pour la communication des messages des noeuds clients du réseau vers le terminal serveur de diagnostic. Ces fenêtres d'émission sont notamment obtenues par un algorithme synchronisé mis en oeuvre dans les noeuds clients du réseau. Ainsi, conformément à l'invention, les données de diagnostic sont insérées à l'intérieur du flux de données temps réel contenant des données de simulation véhiculée, par exemple, via un protocole propriétaire de maintenance (surcouche UDP).

En outre, sur chacun des noeuds clients du réseau, notamment sur les noeuds de type interface électronique , une gestion par service (simulation ou diagnostic) est réalisée en s'appuyant sur un port UDP spécifique pour véhiculer les données de simulation et d'un autre port UDP spécifique pour véhiculer les données de diagnostic. De plus, différents processus d'exécution légers ( thread en terminologie anglo-saxonne), ou tâches, s'exécutent sur les noeuds du réseau, de manière à gérer chacun des services, donc chacun des ports, notamment un processus d'exécution léger pour l'exécution de la simulation et un processus d'exécution léger pour l'exécution du diagnostic. Ainsi, chaque noeud réseau comprend un programme (appelé plugin en terminologie anglo-saxonne) qui interagit avec un logiciel principal, appelé programme hôte, pour lui apporter de nouvelles fonctionnalités. Ce programme est un programme de diagnostic intégré à l'applicatif opérationnel de chaque noeud de l'interface électronique. Le diagnostic peut être réalisé selon un mode synchrone ou un mode asynchrone (aussi appelé mode TRAP en terminologie anglo-saxonne). Selon un mode de réalisation synchrone, une requête de diagnostic permet de lancer un traitement spécifique sur un noeud ou un ensemble de noeuds donnés, tel que la récupération de tables de paramétrage, d'enregistrement, le lancement, l'arrêt d'enregistrement, le forçage, la modification de configuration, etc.. La réponse est émise par le ou les noeuds sollicités à l'issue du traitement. Selon un mode de réalisation asynchrone, le diagnostic est activé au moyen d'une requête unicast, c'est-à-dire en mode point à point, ou d'une requête multicast, c'est-à-dire par une requête destinée à un groupe de noeuds réseau. L'obtention des données / statuts du diagnostic est alors réalisée périodiquement et automatiquement selon une période programmable. Conformément à l'invention, l'équipement de diagnostic connecté au réseau doit respecter un certain nombre de règles afin d'éviter de perturber la simulation réalisée en temps réel. En effet, il est préféré l'émission de données en mode unicast, voire en mode multicast, mais l'émission en mode broadcast, 8 c'est-à-dire à tout le monde, est à éviter de manière à ne pas inonder le réseau de messages. Ensuite, les noeuds clients du réseau ne doivent pas non plus être perturbés par un flux trop important de requêtes de diagnostic. Pour ce faire, l'émission par le noeud serveur de données à destination d'un noeud client ne peut être réalisée que par intervalle bien défini, par exemple toutes les 10 ms, dans le cas d'une simulation (si 10 ms est le cycle minimal de réception d'une commande de simulation). En premier lieu, une requête spécifique d'identification d'adresses MAC (acronyme de Medium Access Control en terminologie anglo-saxonne), identifiant physique stocké dans une carte réseau ou une interface réseau, utilisée pour attribuer mondialement une adresse unique au niveau de la couche de liaison, émise par le terminal de diagnostic avant tout autre échange de diagnostic, permet la constitution des couples adresse MAC / adresse IP des noeuds du réseau à partir des réponses d'identification. Le système de diagnostic positionne ainsi des entrées statiques dans sa mémoire tampon ARP (acronyme de Address Resolution Protocol en terminologie anglo-saxonne). Cette requête permet en outre de positionner, au niveau des noeuds 20 du réseau, une entrée statique dans la table ARP correspondant au couple adresse MAC / adresse IP du système de diagnostic. De même, au niveau des différents noeuds du réseau, ceux-ci doivent respecter un certain nombre de règles. En effet, la fragmentation des messages de diagnostic à l'émission 25 est interdite au niveau IP. Elle doit être réalisée au niveau de la couche message afin de minimiser la latence induite sur les échanges de données de simulation (les noeuds ne possèdent qu'une seule interface réseau par laquelle transitent les données temps réel de simulation et les données non temps réel de diagnostic). 30 En outre, durant la phase de configuration, il est utilisé le protocole IGMP (acronyme de Internet Group Management Protocol en terminologie 9 anglo-saxonne) pour configurer la table de redirection du commutateur permettant la gestion des adresses IP multicast. De plus, les noeuds d'interface électronique du réseau doivent respecter les fenêtres d'émission pour émettre les réponses et les envois de 5 messages en mode asynchrone. Enfin, l'émission de données en mode unicast doit être privilégiée. Il est maintenant décrit un algorithme utilisant la fenêtre d'émission des données de diagnostic. Cet algorithme est exécuté par la tâche de diagnostic des noeuds clients. 10 Chaque message de données de simulation est caractérisé par un couple comprenant un identifiant (ID) et une période de temps (T) en millisecondes ainsi que par un format de données applicatives. Prédéfinie au préalable à toute simulation, une table de séquencement comprenant un ensemble de couples ayant un identifiant et une 15 période de temps est fournie par le terminal de simulation à chaque noeud du réseau lors de la phase de configuration. Ainsi, chaque noeud du réseau possède une table spécifique de séquencement. A partir de cette table, chaque noeud client doit dès lors travailler par échantillonnage temporel ( time siot en terminologie anglo-saxonne). 20 Selon un mode de réalisation, la période d'échantillonnage est de une milliseconde. Lors de la réception du premier message d'échange de données en temps réel possédant l'identifiant Idko, chaque noeud client doit, d'une part, opérer un recalage temporel, c'est-à-dire une initialisation temporelle (t=0) et, 25 d'autre part, initialiser une table de compteurs C tel que décrit ci-dessous : C~ = TI, C2=T2,...,CN = TN Chacun de ces compteurs Ck indique dès lors le nombre de millisecondes restant pour chaque identifiant IDk avant la prochaine réception d'une requête simulation notée REQ[Idk]. 30 Ensuite, à chaque milliseconde, le noeud du réseau effectue une mise à jour du compteur Ck, pour tout k. Si la valeur du compteur Ck est strictement supérieur à 0 (Ck > 0) alors la valeur de ce compteur est décrémenté de la valeur 1 (Ck = Ck û 1). A chaque réception d'une requête de simulation (REQ[Idk]), une requête étant par définition reçue toutes les périodes Tk ms, l'algorithme, d'une part, réinitialise le compteur Ck à la valeur de la période Tk (Ck = Tk) et, d'autre part, gère des statistiques relatives aux messages d'échanges de données de simulation. Ces statistiques, utilisées par la fonction diagnostic, permettent d'analyser les délais entre les instants de réception théorique et les instants de traitement effectif des requêtes de simulation REQ[Idk].

A l'issue de cette opération, une fenêtre d'émission est disponible, pour tout k, dès que le compteur CK est supérieur à un seuil déterminé Amin (Ck > Amin). Durant cette fenêtre d'émission, il est permis à chaque noeud d'interface électronique du réseau d'émettre des données de diagnostic vers le terminal de diagnostic et d'effectuer les traitements de diagnostic, sans toutefois perturber la simulation temps réel en cours. De plus, cet algorithme garantit ainsi de minimiser la latence induite par la fonction de diagnostic dans le séquencement des données temps réel de simulation (accès concurrent sur une unique interface réseau). Le seuil déterminé Amin doit être ajusté notamment en prenant en compte les éléments suivants. Tout d'abord, le seuil tient compte de la valeur absolue d'un décalage ( glitch en terminologie anglo-saxonne) négatif maximal du calculateur principal émettant les messages de simulation. Cette valeur est déterminée par l'avance au démarrage maximale des émissions de ce calculateur principal. Ce phénomène peut en effet survenir lors de tout cycle suivant un retard : phénomène de rattrapage du système d'exploitation sur interruption de temps. En outre, le seuil doit tenir compte du temps de traitement de l'émission d'une réponse de diagnostic RESP[IDdiagnostio] opérée par le noyau du système d'exploitation utilisé sur le noeud réseau. En effet, le noeud réseau comprend en général une seule interface réseau dédiée au double rôle de simulation et de diagnostic, ce qui implique l'utilisation d'un mécanisme d'exclusion mutuelle (appelé mutex pour Mutuel Exclusion en terminologie anglo-saxonne) dans la pile de protocole UDP/IP pour la synchronisation, afin de garantir qu'une ressource partagée ne soit pas utilisée en même temps par deux tâches distinctes.

Enfin, le seuil doit tenir compte du délai de commutation du système d'exploitation lors du basculement du processus d'exécution léger en charge du diagnostic vers le processus d'exécution léger en charge de la simulation. Il est illustré en figure 2 un chronogramme illustrant les fenêtres d'émission pour un noeud du réseau déterminé.

Selon cet exemple, le noeud réseau reçoit des données ou des commandes de simulation ID1 toutes les 10 ms, des données de simulation ID2 toutes les 3 ms et des données de simulation ID3 toutes les 5 ms. Le chronogramme illustre donc, sur l'échelle de temps, par des traits épais, le moment de réception des données ou des commandes de simulation, le temps de traitement de ces données et l'émission de la réponse associée. Entre ces traits, le noeud réseau est apte à traiter et à émettre des données de diagnostic vers le terminal serveur de diagnostic. Ainsi, les fenêtres d'émission étant définies par le temps disponible entre deux réceptions et traitements de données de simulation, diminuée de manière à garder de la marge de sécurité avant toute autre réception des données de simulation en temps réel, la réception et le traitement des données de simulation ne sont pas perturbés. En outre, il est, par là même, évité des problèmes d'inversion de priorité (en raison du mutex inévitable sur l'interface réseau) si des données ou des commandes de simulation et de diagnostic arrivent sur le port UDP du noeud de réseau de manière très rapprochée. Selon l'exemple considéré, la largeur de chaque fenêtre d'émission correspond donc à l'intervalle de temps entre deux réceptions et traitements de données de simulation diminué d'une milliseconde, la fenêtre d'émission démarrant après l'émission des données de simulation. Conformément à l'invention, l'aspect intrusif du diagnostic est négligeable et maîtrisé dans le processus de simulation en temps réel.

Selon ce système, il est maintenant déterminé le temps de latence induit dans le système. Ainsi ce temps At[requéte diagnostic]induit relatif à la réception d'une requête de diagnostic qui s'insérerait juste avant une requête de simulation comprend le temps de transfert physique sur le lien du noeud réseau, le temps de traitement de la pile UDP/IP lors de la réception de la requête et le temps de commutation de la tâche simulation vers la tâche diagnostic. Selon un mode de réalisation, le temps de transfert physique sur le lien du noeud réseau est de 15 ps, le temps de traitement de la pile UDP/IP lors de la réception de la requête est de 400 ps et le temps de commutation des processus d'exécution légers est de 10 ps. La latence induite par le traitement de cette requête de diagnostic At[traitement requête diagnostic] est nulle du fait qu'elle est gérée par une tâche de priorité inférieure à celle de simulation.

De même, la latence induite par l'émission de la réponse de diagnostic At[réponse diagnostic] est nulle du fait que l'algorithme détermine et utilise les fenêtres d'émission adéquates pour émettre les réponses. Ainsi, selon ce mode de réalisation, la latence induite par le diagnostic sur toute requête de simulation est approximativement égale au temps de traitement de la pile UDP/IP lors de la réception de la requête, soit environ 400 ps, ce qui est négligeable par rapport au cycle minimal de la simulation, c'est à dire le délai le plus petit séparant les messages de simulation, qui est ici de 10ms. Ainsi, l'aspect intrusif du diagnostic dans le système de simulation en temps réel est négligeable.

Bien entendu, de nombreuses modifications peuvent être apportées aux exemples de réalisation décrits précédemment sans sortir du cadre de l'invention.

Claims

REVENDICATIONS

1. Procédé d'échange de données de diagnostic dans un réseau (5) entre un noeud (10) du réseau et un terminal de diagnostic (25) connecté au réseau, le noeud du réseau étant apte à recevoir des commandes de simulation en temps réel et des commandes de diagnostic, caractérisé en ce que le noeud du réseau est apte à recevoir des commandes de simulation selon au moins une période de temps prédéterminée, le procédé comprenant une ségrégation temporelle pour l'émission des données de diagnostic par rapport au traitement des commandes de simulation.

2. Procédé d'échange de données de diagnostic selon la 15 revendication 1, caractérisé en ce que le procédé comprend les étapes suivantes : -détermination de la date de la fin du traitement d'une commande de simulation ; - détermination de la date de la prochaine réception d'une nouvelle 20 commande de simulation en fonction de ladite au moins une période de temps prédéterminée ; - détermination d'un intervalle de temps entre la date de la fin du traitement d'une commande de simulation et la date de la prochaine réception d'une nouvelle commande de simulation ; et, 25 - émission des données de diagnostic via le réseau durant l'intervalle de temps déterminé.

3. Procédé d'échange de données de diagnostic selon la revendication 2, caractérisé en ce qu'il comprend en outre une étape de réduction de l'intervalle de temps d'une durée déterminée. 30

4. Procédé d'échange de données de diagnostic selon la revendication 2 ou la revendication 3, caractérisé en ce que l'émission dedonnées de diagnostic est réalisée si l'intervalle de temps est supérieur à un seuil prédéterminé.

5. Programme d'ordinateur chargeable dans un système informatique, ledit programme contenant des instructions permettant la mise en oeuvre du procédé d'échange de données de diagnostic dans un réseau entre un noeud du réseau et un terminal de diagnostic connecté au réseau selon l'une quelconque des revendications 1 à 4, lorsque ce programme est chargé et exécuté par un système informatique.

6. Dispositif d'échange de données de diagnostic dans un réseau (5) entre un noeud (10) du réseau et un terminal de diagnostic (25) connecté au réseau, le noeud du réseau étant apte à recevoir des commandes de simulation en temps réel et des commandes de diagnostic, caractérisé en ce que le noeud du réseau est apte à recevoir des commandes de simulation selon au moins une période de temps prédéterminée, le dispositif comprenant des moyens de ségrégation temporelle pour l'émission des données de diagnostic par rapport au traitement des commandes de simulation.

7. Dispositif d'échange de données de diagnostic selon la revendication 6, caractérisé en ce que le dispositif comprend les moyens suivants : -moyens pour déterminer la date de la fin du traitement d'une commande de simulation ; - moyens pour déterminer la date de la prochaine réception d'une nouvelle commande de simulation en fonction de ladite au moins une période de temps prédéterminée ; - moyens pour déterminer un intervalle de temps entre la date de la fin du traitement d'une commande de simulation et la date de la prochaine réception d'une nouvelle commande de simulation ; et, - moyens pour émettre des données de diagnostic via le réseau durant l'intervalle de temps déterminé.

8. Dispositif d'échange de données de diagnostic selon la revendication 7, caractérisé en ce qu'il comprend en outre des moyens pour réduire l'intervalle de temps d'une durée déterminée.

9. Dispositif d'échange de données de diagnostic selon la revendication 7 ou la revendication 8, caractérisé en ce que les moyens pour émettre des données de diagnostic comprennent des moyens pour comparer l'intervalle de temps à un seuil prédéterminé, les moyens pour émettre des données de diagnostic étant adaptés à émettre les données de diagnostic si l'intervalle de temps est supérieur à un seuil prédéterminé.

10. Noeud de réseau comprenant le dispositif d'échange de données de diagnostic selon l'une quelconque des revendications 6 à 9.10