FR2930697A1 - Procede et dispositif de configuration dynamique d'un reseau de communication pour la simulation temps reel de l'integration de composants electroniques dans un vehicule - Google Patents

Abstract

L'invention a pour objet un procédé et un dispositif pour configurer dynamiquement un réseau de communication utilisé pour la simulation temps réel de l'intégration d'une pluralité de composants électroniques dans un véhicule, le réseau de communication comprenant un système informatique et au moins un noeud d'entrées/sorties, ledit au moins un noeud d'entrées/sorties étant connecté audit système informatique et pouvant être connecté à au moins un composant électronique de ladite pluralité de composants électroniques de véhicule, ce procédé comprenant une phase de configuration dudit au moins un noeud d'entrées/sorties, ladite phase de configuration comprenant une étape de transmission (310) dudit système informatique de simulation audit au moins un noeud d'entrées/sorties d'au moins une indication relative à la structure des messages utilisés pour transférer des données de simulation entre ledit système informatique de simulation et ledit au moins un noeud d'entrées/sorties.

Description

La présente invention concerne les réseaux de communication d'échange de données temps réel utilisés pour la simulation de l'intégration de composants électroniques dans un environnement complexe et plus particulièrement un procédé et un dispositif de configuration dynamique d'un réseau de communication pour la simulation temps réel de l'intégration de composants électroniques dans un véhicule. La simulation de l'intégration de composants dans un véhicule, en particulier dans un aéronef, est utilisée pour assurer le développement et l'intégration des systèmes électroniques et/ou informatiques embarqués dans celui-ci.

Ainsi, l'intégration de composants électroniques dans des véhicules fait l'objet de simulations selon lesquelles des dispositifs électroniques d'entrées/sorties, ou cartes d'entrées/sorties, sont utilisés comme interface entre les composants réels du véhicule, tels que, par exemple, des calculateurs, des capteurs et des actionneurs, et un environnement de simulation comprenant généralement un ou plusieurs serveurs ou ordinateurs utilisés pour simuler le comportement du véhicule ou d'une partie de celui-ci. Chaque carte d'entrées/sorties dispose d'un nombre déterminé de voies d'entrée et de voies de sortie. L'environnement de simulation est, par exemple, apte à émettre des données selon une séquence synchrone basée sur le principe requête/réponse. La complexité de l'environnement de simulation est liée à celle de l'ensemble des composants électroniques du véhicule mis en oeuvre. Dans le domaine des aéronefs, il est généralement nécessaire de faire appel à plusieurs ordinateurs ou serveurs pour simuler les différentes situations auxquelles les composants électroniques sont susceptibles d'avoir à faire face. Un réseau, permettant la communication entre les différents ordinateurs ou serveurs et les dispositifs électroniques d'entrées/sorties, est généralement utilisé. Le réseau ainsi formé est, par exemple, du type switch fabric , 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 chargés du transport de ces données. Le commutateur est chargé d'émettre en parallèle des requêtes en provenance des ordinateurs ou des serveurs à destination des cartes d'entrées/sorties et des réponses en provenance des cartes d'entrées/sorties vers les ordinateurs ou les serveurs. Une même requête et une même réponse doivent pouvoir être adressées par le commutateur à plusieurs destinataires. Par ailleurs, un même réseau de communication étant utilisé pour réaliser un grand nombre de simulations différentes, il est nécessaire, pour chaque simulation, de configurer le réseau afin de déterminer, notamment, le nombre de dispositifs électroniques d'entrées/sorties utilisés, le nombre et la nature des voies utilisées, le type de données échangées et les destinataires de ces données. Une telle configuration peut être longue et fastidieuse. Elle représente également une source potentielle d'erreurs. De façon standard, la configuration est réalisée à l'aide de spécifications prédéterminées et mémorisées, par exemple, dans des fichiers de configuration. D'autre part, pour valider les simulations, celles-ci sont avantageusement exécutées en temps réel. Ainsi, un protocole particulier, généralement propre à l'environnement de simulation, appelé protocole propriétaire, est utilisé. Cependant, une telle mise en oeuvre implique une certaine dépendance vis-à-vis du fournisseur de la solution utilisée. Elle ne permet généralement pas d'utiliser des technologies standard et ainsi de bénéficier des développements existants autour de ces technologies, tels que les outils d'aide à l'analyse et les interfaces de programmation, aussi appelées API (sigle de Application Programming Interface en terminologie anglo- saxonne). De la même façon, il n'est généralement pas possible de profiter de l'expertise de multiples fournisseurs ni de gérer efficacement une obsolescence facilitée par une offre diversifiée et un marché concurrentiel.

Alternativement, le réseau utilisé peut être basé sur un standard existant, par exemple le standard Ethernet (IEEE 802.3) qui décrit un protocole de réseau local à commutation de paquets. Cependant, un tel standard ne garantit généralement pas le respect des contraintes de temps réel.

L'invention permet de résoudre au moins un des problèmes exposés précédemment. L'invention a ainsi pour objet un procédé de configuration dynamique d'un réseau de communication pour la simulation de l'intégration d'une pluralité de composants électroniques dans un véhicule, ledit réseau de communication comprenant au moins un système informatique de simulation et au moins un noeud d'entrées/sorties, ledit au moins un noeud d'entrées/sorties étant connecté audit au moins un système informatique et pouvant être connecté à au moins un composant électronique de ladite pluralité de composants électroniques, ce procédé comprenant une phase de configuration dudit au moins un noeud d'entrées/sorties, ladite phase de configuration comprenant au moins une étape de transmission dudit au moins un système informatique de simulation audit au moins un noeud d'entrées/sorties d'au moins une indication relative à la structure des messages utilisés pour transférer des données de simulation entre ledit au moins un système informatique de simulation et ledit au moins un noeud d'entrées/sorties. Le procédé selon l'invention permet de mettre en oeuvre un apprentissage dynamique de la structure des messages d'échange de données entre les noeuds du réseau de communication utilisé. Ce procédé facilite ainsi l'évolution de l'environnement de simulation, en particulier, du nombre de noeuds d'entrées/sorties et de leur localisation pendant le cycle de développement des simulateurs d'intégration. Le procédé permet également d'optimiser la taille des messages échangés. Selon un mode de réalisation particulier, au moins deux types distincts de messages peuvent être utilisés pour transférer des données de simulation entre ledit au moins un système informatique de simulation et ledit au moins un noeud d'entrées/sorties, ladite au moins une indication comprenant au moins une information relative à un type de messages utilisés pour transférer des données de simulation entre ledit au moins un système informatique de simulation et ledit au moins un noeud d'entrées/sorties, permettant ainsi l'échange de données selon le mode requête/réponse. Ladite phase de configuration comprend en outre, avantageusement une étape de configuration d'au moins un lien entre au moins deux types distincts de messages utilisés pour transférer des données de simulation distincts afin de lier, notamment, une requête à une réponse. Le procédé selon l'invention comprend en outre, de préférence, une étape de configuration d'adresse selon laquelle une adresse de destination est associée à un type prédéterminé de messages utilisés pour transférer des données de simulation entre ledit au moins un système informatique de simulation et ledit au moins un noeud d'entrées/sorties. Les messages de réponse sont ainsi transmis directement aux bons destinataires. De façon avantageuse, ladite phase de configuration comprend en outre une étape de configuration d'adresse permettant audit au moins un système informatique de transmettre un message à une pluralité de noeuds d'entrées/sorties pour réduire le trafic des messages sur ledit réseau de communication. Selon un mode de réalisation particulier, le procédé comprend en outre une étape de détection dudit au moins un noeud d'entrées/sorties. Toujours selon un mode de réalisation particulier, le procédé comprend en outre une étape d'activation pour passer de ladite phase de configuration à une phase de simulation, ladite phase de simulation comprenant les étapes suivantes, - transmission par ledit au moins un système informatique d'un message de requête comprenant au moins une donnée de simulation à destination dudit au moins un noeud d'entrées/sorties ; et, - en réponse audit message de requête, réception par ledit au moins un système informatique d'un message de réponse comprenant au moins une donnée de simulation reçue par ledit au moins un noeud d'entrées/sorties d'au moins un composant électronique de ladite pluralité de composants électroniques. Ladite au moins une donnée dudit message de requête est, de préférence, transmise à au moins un composant électronique de ladite pluralité de composants électroniques. L'invention a également pour objet un dispositif comprenant des moyens adaptés à la mise en oeuvre de chacune des étapes du procédé décrit précédemment ainsi qu'un programme d'ordinateur comprenant des instructions adaptées à la mise en oeuvre de chacune des étapes de ce procédé. 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, 10 au regard des dessins annexés dans lesquels : - la figure 1 représente schématiquement un environnement de simulation adaptée à mettre en oeuvre l'invention ; - la figure 2 illustre un exemple de structure de message de contrôle, sous forme de trame, transmis entre les noeuds du réseau ; 15 - la figure 3 un exemple d'algorithme de détection et de configuration de l'environnement de simulation conformément à l'invention. - la figure 4 représente une partie d'un message d'échange de données utilisé durant la phase d'échange de données de simulation ; - la figure 5, comprenant les figures 5a et 5b, illustre un exemple 20 d'une partie de message comprenant des données opérationnelles selon deux simulations distinctes ; et, - la figure 6 montre un exemple de dispositif permettant d'implémenter une partie de l'invention. La figure 1 représente schématiquement un environnement de 25 simulation 100 adapté à mettre en oeuvre l'invention. Comme illustré, le dispositif de simulation 105 comprend ici deux systèmes informatiques 110-1 et 110-2, par exemple des ordinateurs ou des serveurs, ainsi que trois cartes d'entrées/sorties 115-1 à 115-3, chacun étant connecté à un commutateur réseau 120. Les cartes d'entrées/sorties 115-1 à 115-3 sont également 30 connectées aux composants réels 125-1 à 125-8 dont l'intégration est simulée.

Il convient de remarquer que, bien qu'un seul commutateur réseau soit ici représenté, les réseaux de communication utilisés pour la simulation peuvent comprendre plusieurs commutateurs réseau. Les systèmes informatiques 110-1 et 110-2 ainsi que les trois cartes d'entrées/sorties 115-1 à 115-3 forment les noeuds du réseau, les cartes d'entrées/sorties 115-1 à 115-3 étant appelées des noeuds d'entrées/sorties. Par convention, dans la suite de la description, une entrée est, dans le dispositif de simulation, une donnée produite par un composant électronique de l'aéronef et consommée par le dispositif de simulation tandis qu'une sortie est une donnée produite par le dispositif de simulation et consommée par les composants électroniques. D'une séance de simulation à une autre, la configuration peut changer. En particulier, les voies électroniques réellement utilisées ne sont pas toujours les mêmes. Pour minimiser la taille des messages opérationnels et ainsi la latence des échanges, il est donc nécessaire de prendre en compte l'utilisation des voies des noeuds d'entrées/sorties afin, notamment, de ne pas transférer de valeurs inutiles. Par conséquent, chaque noeud d'entrées/sorties doit connaître l'emplacement des données opérationnelles de chaque requête reçue pour traiter les données. Chaque noeud d'entrées/sorties doit également connaître l'emplacement des données opérationnelles de chaque réponse qu'il doit élaborer puis émettre en retour. L'invention permet de configurer dynamiquement l'environnement de simulation afin d'éviter, notamment l'utilisation de spécifications prédéterminées pouvant se présenter, par exemple, sous forme de fichiers de configuration. L'invention permet ainsi de définir une stratégie de configuration dynamique des échanges de données autorisant un protocole d'échanges opérationnels configuré dynamiquement et permettant d'optimiser la taille des données échangées avantageusement réduite, pour chaque simulation, aux seules voies électroniques effectivement utilisées. Les systèmes informatiques 110-1 et 110-2 transmettent des requêtes aux cartes d'entrées/sorties 115-1 à 115-3 qui, à leur tour, transmettent des réponses aux systèmes informatiques 110-1 et 110-2, selon le schéma maître/esclave. Ainsi, à chaque cycle d'entrée/sortie, les systèmes informatiques émettent des messages de requête, identifiés dans la suite de la description par la notation ID_req où ID est l'identifiant du message, à destination d'un ou de plusieurs noeuds d'entrées/sorties, ayant pour données applicatives les valeurs devant être générées sur les voies de sortie à destination des composants électroniques, par exemple des valeurs analogiques, des valeurs booléennes ou des messages à destination de bus d'aéronef tels que des messages à destination de bus ARINC 429 ou CAN. En réponse à une requête ID_req reçue, chaque noeud d'entrées/sorties retourne aux systèmes informatiques un message de réponse, identifié par la notation ID_resp dans la suite de la description, ayant pour données les valeurs acquises sur les voies d'entrée, provenant des composants électroniques. Dans un mode de réalisation particulier, l'échange des données entre les différents noeuds du réseau est réalisé sur des ports UDP (acronyme de User Datagram Protocol en terminologie anglo-saxonne) spécifiques 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. Le protocole ARP (acronyme d'Address Resolution Protocol en terminologie anglo-saxonne) peut être utilisé pour effectuer des conversions d'adresses entre le protocole de couche réseau et une adresse Ethernet, par exemple une adresse MAC (acronyme de Media Access Control en terminologie anglo-saxonne).

De façon avantageuse, l'usage du protocole ARP, s'il est mis en oeuvre par le réseau utilisé, est inhibé durant la phase opérationnelle afin de supprimer les trames ARP et ainsi limiter le trafic sur le réseau et le temps de traitement associé sur les noeuds. Les ports UDP sont ici utilisés de façon spécifique pour définir des priorités d'accès aux noeuds et de traitements associés. A titre d'illustration, les ports UDP peuvent être utilisés de la façon suivante, du plus prioritaire au moins prioritaire, - un port de contrôle prioritaire pour prendre en compte un dispositif de surveillance des systèmes informatiques de simulation, aussi appelé watchdog en terminologie anglo-saxonne ; - un port de gestion des messages de configuration et d'échange de données de simulation ; et, - un port de maintenance. La configuration de l'environnement de simulation est effectuée à l'initiative d'un système informatique de simulation. La détection des noeuds d'entrées/sorties du réseau peut être effectuée selon différentes méthodes : - détection statique utilisant par exemple un fichier de configuration contenant la liste des adresses IP unicast des noeuds d'entrées/sorties, c'est-à-dire les adresses IP individuelles des noeuds d'entrées/sorties, ainsi que les adresses MAC si le protocole ARP est inhibé ; - détection dynamique de tous les noeuds d'entrées/sorties en utilisant, par exemple, des messages de type multicast, c'est-à-dire des messages adressés à un ensemble prédéterminé de noeuds d'entrées/sorties, ou de type, broadcast c'est-à-dire des messages adressés à tous les noeuds d'entrées/sorties ; ou - détection dynamique par type de noeuds d'entrées/sorties, une adresse multicast étant ici définie par type de noeuds d'entrées/sorties. Conformément à l'invention, la simulation comprend deux phases, une phase de configuration et une phase opérationnelle. Dans ces phases, les messages échangés entre les noeuds du réseau sont de préférence conformes à la configuration définie dans la demande de brevet FR 2 899 050.

Plusieurs types de messages sont échangés entre les systèmes informatiques et les noeuds d'entrées/sorties : - des messages de contrôle ; et, - des messages d'échanges de données opérationnelles. Les messages de contrôle sont utilisés durant la phase de configuration pour paramétrer les noeuds d'entrées/sorties ainsi que, éventuellement, durant la phase opérationnelle pour, notamment, transmettre des données de statut et de diagnostic. Les messages d'échanges de données opérationnelles ne sont utilisés que durant la phase opérationnelle. A chaque message de contrôle, noté <ctrl>_REQ, est associé un message réponse, noté <ctrl>_RESP. Par exemple, si un message de requête visant à déterminer le statut des composants électroniques est émis sous la forme STATUS_REQ, la réponse est de la forme STATUS_RESP. Les messages de contrôle utilisés durant la phase de configuration comprennent notamment des messages de configuration des adresses d'abonnement multicast, des messages de configuration des messages d'échanges de données opérationnelles et des messages d'association des messages d'échanges de données opérationnelles. Un message de configuration des adresses d'abonnement multicast permet aux systèmes informatiques de simulation, à partir d'une base de données de configuration, d'appliquer une stratégie de regroupement des noeuds d'entrées/sorties par type d'entrées/sorties et par cycle d'entrée/sortie. Les noeuds d'entrées/sorties sont alors configurés pour qu'ils s'abonnent aux bonnes adresses multicast, adresses vers lesquelles sont émis les messages d'échanges de données générés par les systèmes informatiques de simulation durant la phase opérationnelle. Cette stratégie de regroupement permet notamment de limiter le trafic sur le réseau. Un message de configuration des messages d'échanges de données opérationnelles définit, pour chaque noeud d'entrées/sorties, les types de messages de requête, c'est-à-dire les messages opérationnels émis par les systèmes informatiques de simulation, et les réponses, c'est-à-dire les messages réponses émis par le noeud d'entrées/sorties, qu'il doit gérer, la sémantique et la structure des données de ce message. De façon avantageuse, les données sont transmises sous forme de signaux, chaque signal pouvant être représenté sous forme d'un tableau de données. L'association entre les signaux et les voies des noeuds d'entrées/sorties est effectuée par le biais de fonctions de transfert pour éviter l'échange de telles informations durant la phase opérationnelle. En d'autres termes, un message de configuration définit la valeur de l'identifiant et la structure des données opérationnelles des messages de requête. Pour chaque voie utilisée, il définit la position et la taille de la valeur de la voie dans le message de requête. Pour un noeud d'entrées/sorties, il y a autant de transmissions de messages de configuration que de types de messages opérationnels prévus pour la simulation.

Un message d'association des réponses aux messages d'échanges de données opérationnelles définit, pour chaque noeud d'entrées/sorties, les messages de réponse que ce dernier doit émettre en réponse à la réception de messages de requête, en précisant la forme des données et la sémantique utilisée. En d'autres termes, un message d'association définit un couple d'identifiants (ID_req, ID_resp) ainsi que les sémantiques associées pour des messages de requête et de réponse. Autant de messages d'association sont émis pour chaque noeud d'entrées/sorties que nécessaire. Un message d'association d'adresses aux messages de réponse d'échanges de données opérationnelles définit pour chaque noeud d'entrées/sorties et pour chaque message de réponse configuré, le couple d'adresses MAC et IP à destination duquel il doit émettre le message de réponse quand il reçoit le message de requête associé. Un message d'activation permet de passer de la phase de configuration à la phase de simulation opérationnelle. Le paramétrage électronique des noeuds d'entrées/sorties, tel que la polarisation des voies, est alors pris en compte et appliqué. La figure 2 illustre un exemple de structure de message de contrôle, sous forme de trame, transmis entre les noeuds du réseau, selon lequel la partie utile des données de simulation est encapsulée dans un message dont la configuration est propre à l'environnement de simulation, ce message étant lui- même encapsulé dans une trame standard, ici une trame Ethernet. La trame 200 comprend ici un en-tête Ethernet 205, un en-tête IP 210, un en-tête UDP 215, un message 220 dont la configuration est propre à l'environnement de simulation et des bits de contrôle 225 utilisés, par exemple, pour vérifier la validité des données transmises. Les bits de contrôle 225 sont liés au protocole utilisé, ici Ethernet/IP.

L'en-tête Ethernet 205 comprend par exemple l'adresse MAC du dispositif ayant transmis la trame UDP. L'en-tête IP 210 comprend par exemple l'adresse IP du dispositif ayant transmis la trame UDP et l'adresse IP du dispositif auquel est destinée la trame UDP.

Alternativement, les en-têtes Ethernet et IP peuvent contenir d'autres adresses que les adresses MAC et IP du dispositif ayant transmis la trame UDP, par exemple les adresses MAC et IP du dispositif auquel un message doit être envoyé en réponse à la trame 200. Ce mécanisme présente l'avantage de dissocier, dans une architecture distribuée, les dispositifs émetteurs des dispositifs récepteurs. L'en-tête UDP 215 contient notamment les ports source et destination. Le message 220 dont la configuration est propre à l'environnement de simulation comprend ici un identifiant 230 qui correspond à l'identification du message concerné, une indication de longueur 235 qui donne la taille du message en octets et des données ou paramètres de simulation 240. L'identité d'un message est utilisée pour définir le type du message et, ainsi, pour déterminer, si nécessaire, la nature du traitement qui doit être réalisé à la réception du message. Le contenu des données ou paramètres de simulation 240 est lié à l'identifiant 230. Les identifiants des messages de contrôle sont avantageusement conformes à une spécification prédéterminée. La figure 3 illustre un exemple d'algorithme de détection et de configuration de l'environnement de simulation conformément à l'invention. Après avoir déterminé les noeuds d'entrées/sorties du réseau (étape 300), de façon statique ou dynamique, un message de configuration des adresses d'abonnement multicast est transmis aux noeuds d'entrées/sorties (étape 305). Plusieurs messages d'abonnement multicast peuvent être transmis. Chaque message comprend en particulier l'adresse des noeuds d'entrées/sorties devant être groupés ainsi qu'une adresse multicast unique.

L'adresse multicast ainsi que les adresses des noeuds associés sont mémorisées dans les commutateurs afin que les messages soient ultérieurement transmis aux bons destinataires.

Les structures des messages d'échange de données sont ensuite configurées (étape 310). Cette configuration consiste, par exemple, à transmettre à chaque noeud d'entrées/sorties la liste des identifiants des messages de requête que le noeud doit traiter ainsi que la liste des identifiants des messages de réponse que le noeud doit générer avec, pour chacun de ces identifiants, la structure du message associé. Ces informations peuvent être transmises sous forme de table ayant une structure prédéterminée. Les associations entre les messages de requête et de réponse sont ensuite configurées (étape 315) en transmettant à chaque noeud d'entrées/sorties, par exemple, une liste de couples d'identifiants dont un identifiant est associé à un message de requête et l'autre est associé au message de réponse correspondant. Si la structure du message de réponse n'a pas été transmise à l'étape de configuration de la structure des messages d'échange de données, elle peut l'être ici.

Les adresses auxquelles doivent être envoyés les messages de réponse sont ensuite configurées (étape 320). Un couple d'adresses MAC et IP est par exemple transmis avec un identifiant de message de réponse à chaque noeud devant générer ce type de message de réponse. Lorsque la configuration est terminée, il est possible d'activer le 20 mode de simulation (étape 325) pour passer de la phase de configuration à la phase de simulation opérationnelle. Les étapes 300 à 325 utilisent, éventuellement, un fichier de configuration prédéterminé et mémorisé dans la base de données 330. Il convient de remarquer que les étapes 305 à 320 peuvent être exécutées dans 25 un ordre différent. Les messages d'échanges de données sont utilisés uniquement pendant la phase opérationnelle de simulation. Outre un identifiant et une indication de longueur, chaque message comprend, de préférence, un numéro de séquence utilisé pour identifier de façon unique l'occurrence du message, un 30 compteur numérique servant de référence temporelle (appelé timestamp en terminologie anglo-saxonne) utilisé pour dater l'émission du message, une indication de commande ou de statut utilisé pour déterminer la nature du message et un signal de données indiquant les données consommées et produites par l'environnement de simulation. Les identifiants des messages d'échanges de données sont définis dynamiquement pendant la phase de configuration. La sémantique est avantageusement prédéfinie par spécification, par type d'identifiant, la structure des messages étant définie par le système informatique de simulation durant la phase de configuration et apprise par les noeuds d'entrées/sorties durant le paramétrage à l'aide d'une liste dynamique d'identifiants définie pour chaque configuration de simulation en fonction des noeuds d'entrées/sorties mis en oeuvre et de leur paramétrage. Comme décrit précédemment, un message d'échange de données, de type requête ou réponse est défini par un identifiant et contient des données opérationnelles constituées des valeurs, générées en sortie ou acquises en entrée, des voies effectivement utilisées.

La figure 4 représente une partie d'un message 400 d'échange de données utilisé durant la phase opérationnelle. Comme illustré, le message 400 comprend un identifiant 405 permettant d'identifier le type de message et un ensemble de données opérationnelles 410. Chaque valeur D;i, qui représente la valeur associée à la voie j de la carte i, est générée sur une sortie ou acquise sur une entrée. Ainsi, les valeurs D11 à D1k référencées 415 sont associées à la carte 1, les valeurs D21 à D21 référencées 420 sont associées à la carte 2 et les valeurs D;1 à Di,,, référencées 425 sont associées à la carte i. Des exemples des différents types de messages utilisés durant la phase opérationnelle sont présentés ci-dessous où les types de message préfixés OUT concernent des actions relatives aux voies de sortie, les types de message préfixés IN concernent des actions relatives aux voies d'entrée, les types de message suffixés REQ indiquent qu'un acquittement doit être émis sur réception d'un tel message et les types de messages suffixés RESP sont des messages de réponse, ou d'acquittement, émis par un noeud d'entrées/sorties. Le type OUT_DATA est relatif à un message de requête indiquant à un noeud d'entrées/sorties de mémoriser les données opérationnelles contenues dans le message. Ces données concernent des valeurs à générer ultérieurement sur les voies de sortie correspondantes. Le type OUT_DATA_REQ est similaire au précédent mais se distingue de celui-ci en ce que chaque noeud d'entrées/sorties doit acquitter la réception du message par l'envoi d'un message d'acquittement, vers le système informatique de simulation, dont l'identifiant est OUT_RESP. Le type OUT_TRIGGER concerne un message de requête de déclenchement qui a pour objet d'indiquer à un noeud d'entrées/sorties de générer sur les voies de sortie configurées les données OUTPUT préalablement reçues. Le type OUT_ TRIGGER _REQ est similaire au précédent mais se distingue de celui-ci en ce que chaque noeud d'entrées/sorties doit acquitter la réception du message par l'envoi d'un message d'acquittement, vers le système informatique de simulation, dont l'identifiant est OUT_RESP.

Le type OUT_DATA_TRIGGER est relatif à un message de requête qui vise à demander à un noeud d'entrées/sorties de générer des valeurs sur les voies de sortie concernées à partir des données opérationnelles contenues dans le message. Le type OUT_DATA_TRIGGER_REQ est similaire au précédent mais se distingue de celui-ci en ce que chaque noeud d'entrées/sorties doit acquitter la réception du message par l'envoi d'un message d'acquittement, vers le système informatique de simulation, dont l'identifiant est OUT_RESP. Le type OUT_RESP concerne un message d'acquittement émis par un noeud d'entrées/sorties vers le système informatique de simulation en réponse à un message de requête concernant les sorties comprenant une demande d'acquittement. Le type IN_DATA_REQ concerne un message de requête indiquant au noeud d'entrées/sorties à qui elle est destinée de transférer ses données d'entrées, préalablement acquises. Le noeud d'entrées/sorties doit alors émettre un message de type IN_RESP en réponse. Le type IN_TRIGGER est relatif à un message de requête dont l'objet est de demander à chaque noeud d'entrées/sorties à qui elle est destinée d'acquérir les valeurs des voies d'entrée concernées et de mémoriser ces données pour qu'elles puissent être transférées ultérieurement. Le type IN_DATA TRIGGER_REQ est relatif à un message de requête dont l'objet est de demander à chaque noeud d'entrées/sorties à qui elle est destinée d'acquérir les valeurs des voies d'entrées et de transmettre ces données dans un message de type IN_RESP en réponse. Le type IN_RESP concerne un message de réponse, contenant des données d'entrées, c'est-à-dire des valeurs acquises sur des voies d'entrées, émis sur réception d'un message de requête concernant les entrées et comprenant une demande d'acquittement. Le type I0_CYCLE_REQ vise un message indiquant à un ou à plusieurs noeuds d'entrées/sorties d'effectuer un cycle d'entrées/sorties. Ce message contient les données représentant les valeurs à générer sur les voies de sortie. Sur réception de ce message, chaque noeud d'entrées/sorties doit immédiatement émettre ses données correspondant aux valeurs des voies d'entrée, préalablement acquises, via un message de réponse de type IN RESP. Les noeuds d'entrées/sorties du réseau peuvent être configurés en mode synchrone ou en mode asynchrone.

En mode synchrone, la réception par un noeud d'entrées/sorties d'un message opérationnel de type 1O_CYCLE déclenche avantageusement les événements suivants, - une émission d'un message de type IN_RESP contenant les dernières données acquises et le dernier statut du noeud, à jour et synchronisé ; - une génération des valeurs sur les voies de sortie, conformément aux données reçues ; et, - une acquisition des valeurs des voies d'entrée pour construire les données INPUTS à émettre au prochain cycle d'entrée/sortie. Il peut être remarqué ici que les données acquises possèdent alors un cycle de retard. Cela permet néanmoins d'obtenir une réponse rapide du noeud qui n'effectue qu'a posteriori la génération et l'acquisition.

En mode asynchrone, la réception par un noeud d'entrées/sorties d'un message opérationnel de type 1O_CYCLE déclenche l'émission d'un message de type IN_RESP contenant les dernières valeurs acquises des voies d'entrée et le dernier statut du noeud, non synchronisé. Les opérations d'acquisition et de génération sont effectuées de façon cyclique asynchrone. La figure 5, comprenant les figures 5a et 5b, illustre un exemple d'une partie de message comprenant des données opérationnelles selon deux simulations distinctes. Dans cet exemple, trois cartes d'entrées/sorties sont mises en oeuvre, chaque carte comprenant ici quatre voies d'entrée et quatre voies de sortie. La référence Si représente la valeur de la donnée relative à la voie de sortie i et la référence Ei représente la valeur de la donnée relative à la voie d'entrée j. Comme illustré sur la figure 5a et selon une première simulation, les quatre voies de sortie de la première carte sont mises en oeuvre tandis que seulement deux voies d'entrée sont utilisées. De même, trois voies de sortie et trois voies d'entrée sont utilisées dans la deuxième carte et deux voies de sortie et trois voies d'entrée sont utilisées dans la troisième carte. Comme illustré sur la figure 5b et selon une seconde simulation, une seule voie de sortie de la première carte est mise en oeuvre tandis que deux voies d'entrée sont utilisées. De même, deux voies de sortie et une voie d'entrée sont utilisées dans la deuxième carte et une voie de sortie et une voie d'entrée sont utilisées dans la troisième carte. La comparaison des figures 5a et 5b montre que les données relatives aux voies non utilisées ne sont pas transmises du fait de l'apprentissage de la logique des échanges et de la sémantique des données par les noeuds d'entrées/sorties lors de la configuration de la simulation. De façon avantageuse, les règles d'optimisation suivantes sont mises en oeuvre, - les messages d'initialisation et de réinitialisation de simulation 30 (RESET et REINIT) sont émis en mode broadcast ou multicast ; - le message STATUS_REQ est émis en mode unicast, multicast ou broadcast ; - les messages de configuration sont émis en mode unicast ; - les messages opérationnels émis par le système informatique de simulation sont émis en mode multicast ou unicast ; et, - les messages opérationnels de réponse émis par les noeuds d'entrées/sorties, de type INPUTS, sont émis en mode unicast ou multicast si l'architecture de simulation est une architecture distribuée comprenant plusieurs dispositifs informatiques de simulation. De même, les règles d'adressage suivantes sont, de préférence, mises en oeuvre, - une adresse multicast par défaut est définie par type de noeuds d'entrées/sorties, par exemple pour des noeuds d'entrées/sorties comprenant des ressources d'entrées/sorties discrètes et pour des noeuds d'entrées/sorties comprenant des ressources analogiques ; et, - une adresse multicast globale permet d'adresser tous les noeuds d'entrées/sorties sans avoir besoin de recourir au mode broadcast. Un dispositif adapté à mettre en oeuvre une partie de l'invention est illustré sur la figure 6. Le dispositif 600 est par exemple une station de travail, un micro-ordinateur ou un serveur. Le dispositif 600 comporte ici un bus de communication 605 auquel 20 sont reliés : - une unité centrale de traitement ou microprocesseur 610 (CPU, Central Processing Unit) ; - une mémoire morte 615 (ROM, acronyme de Read Only Memory en terminologie anglo-saxonne) pouvant comporter les programmes "Prog", 25 "Prog1" et "Prog2" ; - une mémoire vive ou mémoire cache 620 (RAM, acronyme de Random Access Memory en terminologie anglo-saxonne) comportant des registres adaptés à enregistrer des variables et paramètres créés et modifiés au cours de l'exécution des programmes précités ; et, 30 - une interface de communication 650 adaptée à transmettre et à recevoir des données. Optionnellement, le dispositif 600 peut également disposer : - d'un écran 625 permettant de visualiser des données et/ou de servir d'interface graphique avec l'utilisateur qui pourra interagir avec les programmes selon l'invention, à l'aide d'un clavier et d'une souris 630 ou d'un autre dispositif de pointage, un écran tactile ou une télécommande ; - d'un disque dur 635 pouvant comporter les programmes "Prog", "Prog1" et "Prog2" précités et des données traitées ou à traiter selon l'invention ; et, - d'un lecteur de cartes mémoires 640 adapté à recevoir une carte mémoire 645 et à y lire ou à y écrire des données traitées ou à traiter selon l'invention. Le bus de communication permet la communication et l'interopérabilité entre les différents éléments inclus dans le dispositif 600 ou reliés à lui. La représentation du bus n'est pas limitative et, notamment, l'unité centrale est susceptible de communiquer des instructions à tout élément du dispositif 600 directement ou par l'intermédiaire d'un autre élément du dispositif 600. Le code exécutable de chaque programme permettant au dispositif programmable de mettre en oeuvre les processus selon l'invention, peut être stocké, par exemple, dans le disque dur 635 ou en mémoire morte 615.

Selon une variante, la carte mémoire 645 peut contenir des données, notamment des clés de chiffrement, ainsi que le code exécutable des programmes précités qui, une fois lu par le dispositif 600, est stocké dans le disque dur 635. Selon une autre variante, le code exécutable des programmes pourra être reçu, au moins partiellement, par l'intermédiaire de l'interface 650, pour être stocké de façon identique à celle décrite précédemment. De manière plus générale, le ou les programmes pourront être chargés dans un des moyens de stockage du dispositif 600 avant d'être exécutés.

L'unité centrale 610 va commander et diriger l'exécution des instructions ou portions de code logiciel du ou des programmes selon l'invention, instructions qui sont stockées dans le disque dur 635 ou dans la mémoire morte 615 ou bien dans les autres éléments de stockage précités. Lors de la mise sous tension, le ou les programmes qui sont stockés dans une mémoire non volatile, par exemple le disque dur 635 ou la mémoire morte 615, sont transférés dans la mémoire vive 620 qui contient alors le code exécutable du ou des programmes selon l'invention, ainsi que des registres pour mémoriser les variables et paramètres nécessaires à la mise en oeuvre de l'invention. Naturellement, pour satisfaire des besoins spécifiques, une personne compétente dans le domaine de l'invention pourra appliquer des modifications dans la description précédente.

Claims (7)

1. REVENDICATIONS1. Procédé de configuration dynamique d'un réseau de communication pour la simulation temps réel de l'intégration d'une pluralité de composants électroniques dans un véhicule (125-1 à 125-8), ledit réseau de communication comprenant au moins un système informatique de simulation (110-1, 110-2) et au moins un noeud d'entrées/sorties (115-1, 115-2, 115-3), ledit au moins un noeud d'entrées/sorties étant connecté audit au moins un système informatique et pouvant être connecté à au moins un composant électronique de ladite pluralité de composants électroniques, ce procédé étant caractérisé en ce qu'il comprend une phase de configuration dudit au moins un noeud d'entrées/sorties, ladite phase de configuration comprenant au moins une étape de transmission (310) dudit au moins un système informatique de simulation audit au moins un noeud d'entrées/sorties d'au moins une indication relative à la structure des messages utilisés pour transférer des données de simulation entre ledit au moins un système informatique de simulation et ledit au moins un noeud d'entrées/sorties.
2. 2. Procédé selon la revendication 1 selon lequel au moins deux types distincts de messages peuvent être utilisés pour transférer des données de simulation entre ledit au moins un système informatique de simulation et ledit au moins un noeud d'entrées/sorties, ladite au moins une indication comprenant au moins une information relative à un type de messages utilisés pour transférer des données de simulation entre ledit au moins un système informatique de simulation et ledit au moins un noeud d'entrées/sorties.
3. 3. Procédé selon la revendication 1 ou la revendication 2 selon lequel ladite phase de configuration comprend en outre une étape de configuration d'au moins un lien (315) entre au moins deux types distincts de messages utilisés pour transférer des données de simulation distincts.
4. 4. Procédé selon l'une quelconque des revendications précédentes comprenant en outre une étape de configuration d'adresse (320) selon laquelleune adresse de destination est associée à un type prédéterminé de messages utilisés pour transférer des données de simulation entre ledit au moins un système informatique de simulation et ledit au moins un noeud d'entrées/sorties.
5. 5. Procédé selon l'une quelconque des revendications précédentes selon lequel ladite phase de configuration comprend en outre une étape de configuration d'adresse (305) permettant audit au moins un système informatique de transmettre un message à une pluralité de noeuds d'entrées/sorties.
6. 6. Procédé selon l'une quelconque des revendications précédentes 10 comprenant en outre une étape de détection (300) dudit au moins un noeud d'entrées/sorties.
7. 7. Procédé selon l'une quelconque des revendications précédentes comprenant en outre une étape d'activation pour passer de ladite phase de configuration à une phase de simulation, ladite phase de simulation comprenant 15 les étapes suivantes, - transmission par ledit au moins un système informatique d'un message de requête comprenant au moins une donnée de simulation à destination dudit au moins un noeud d'entrées/sorties ; et, - en réponse audit message de requête, réception par ledit au 20 moins un système informatique d'un message de réponse comprenant au moins une donnée de simulation reçue par ledit au moins un noeud d'entrées/sorties d'au moins un composant électronique de ladite pluralité de composants électroniques. 10. Procédé selon la revendication 7 selon lequel ladite au moins 25 une donnée dudit message de requête est transmise à au moins un composant électronique de ladite pluralité de composants électroniques. 11. Dispositif comprenant des moyens adaptés à la mise en oeuvre de chacune des étapes du procédé selon l'une quelconque des revendications précédente. 30 10. Programme d'ordinateur comprenant des instructions adaptées à la mise en oeuvre de chacune des étapes du procédé selon l'une quelconque des revendications 1 à8.