La présente invention concerne le domaine des systèmes informatiques critiques, tel que par exemple les systèmes avioniques embarqués dans les aéronefs.

Par « système informatique critique » on entend un système informatique dont une panne est propre à entraîner des conséquences dramatiques, par exemple des morts ou blessés graves, des dégâts matériels importants, ou encore des conséquences graves pour l'environnement. De tels systèmes informatiques critiques sont basés sur un partitionnement strict des ressources de calcul et des ressources réseau.

Par la suite, de tels systèmes informatiques critiques correspondent à des systèmes avioniques.

Un système avionique met en œuvre des fonctions avioniques. Une fonction avionique est par exemple le calcul de paramètres de vol en fonction de signaux de mesure fournis par des capteurs, l'élaboration de signaux de commande d'actionneurs de l'aéronef en fonction de paramètres de vol et/ou de commandes de vol, l'affichage de paramètres de vol sur un afficheur, l'enregistrement de paramètres de vol pour la maintenance...

Au sein d'un système avionique plusieurs dispositifs (i.e. équipements) avioniques sont interconnectés via un réseau de communication, par exemple un réseau ARINC 664- P7 d'aéronef.

Actuellement, au sein d'un tel réseau ARINC 664-P7 d'aéronef, il n'existe pas de mécanisme de synchronisation robuste et précis. En effet, la seule heure partagée actuellement dans un aéronef est basée sur un mécanisme dont la précision est de l'ordre de la seconde alors que certaines fonctions avioniques, telles que l'accroissement de l'intégrité des réseaux, la réduction de la latence de traitement des messages dans les architectures distribuées (notamment les architectures avioniques modulaires intégrées de deuxième génération (ou « IMA-2G » pour « Intregrated Modulars Avionics - 2 ^nd Génération » en anglais)), la synchronisation de flux audio/vidéo, la détection de certaines attaques de sûreté, l'identification de la cause racine d'un dysfonctionnement du système avionique, la fusion de données de capteurs, etc. requièrent une référence horaire partagée robuste (i.e. utilisable par une fonction de niveau « catastrophique », tel que défini par le document AMJ 25.1309 de la « Joint Aviation Authorities ») et dont la précision élevée est garantie et de l'ordre de 100με au maximum. Selon l'état de l'art actuel, la garantie d'une telle précision n'est atteignable qu'en ajoutant un réseau de synchronisation parallèle au réseau ARINC 664-P7, ce qui augmente le coût, le poids et la consommation du système avionique.

Un des buts de la présente invention est de proposer un procédé de synchronisation au sein d'un système informatique critique, tel qu'un système avionique, permettant d'améliorer la robustesse et de garantir une précision élevée de la référence horaire partagée au sein d'un réseau de ce système informatique, et ce tout en évitant un mécanisme de synchronisation basé sur une mesure temporelle interne à ce même réseau, un tel mécanisme étant impropre à vérifier l'intégrité de ce réseau.

A cet effet l'invention propose un procédé de synchronisation d'un ensemble de dispositifs informatiques critiques, en particulier des dispositifs avioniques, interconnectés à un réseau de communication d'un véhicule, tel qu'un aéronef, et comprenant chacun un module de gestion de l'heure, l'ensemble de dispositifs informatiques critiques comprenant au moins une pluralité de serveurs de référence horaire, et une pluralité de clients, chaque dispositif informatique critique étant connecté à au moins un autre dispositif informatique critique par une liaison virtuelle, chaque point de terminaison d'une liaison virtuelle étant associé à une valeur minimale et à une valeur maximale de temps de transmission d'un paquet de données sur la liaison virtuelle,

le procédé de synchronisation étant mis en œuvre et réitéré périodiquement par le module de gestion de l'heure de chaque dispositif informatique critique courant et comprenant au moins:

- la réception d'au moins un message de synchronisation transmis par un serveur émetteur distinct dudit dispositif informatique critique courant, chaque message étant associé à un instant de réception et comprenant au moins une référence horaire (Href,) déterminée par le serveur émetteur,

- pour chaque message de synchronisation reçu, l'estimation de l'heure courante du serveur émetteur à partir d'un quintuplet de paramètres comprenant :

^■ la référence horaire,

^■ une valeur de l'horloge interne du dispositif informatique critique courant à l'instant courant,

■ une valeur de l'horloge interne du dispositif informatique critique courant à l'instant de réception,

la valeur minimale et la valeur maximale de temps de transmission associée à la liaison virtuelle entre le serveur émetteur et le dispositif informatique critique courant.

Suivant d'autres aspects avantageux de l'invention, le procédé de synchronisation est tel que : la période de réitération du procédé est conforme à la relation suivante :

max (G(S', S)) - max [WCTT(S', S). (D(S) + £»(s ^' ))] ^' min serveur s ^ ' serveur s

serveur s

P < min M . D(s) max Dis' )

serveur s

client

avec

- G(s',s) la différence temporelle entre les meilleur (BCTT) et pire (WCTT) temps théoriques de transmission d'un paquet transmis dans la liaison virtuelle entre deux serveurs,

- P _R une donnée de précision correspondant à l'écart maximal acceptable entre la référence horaire de deux dispositifs informatiques,

D un taux de dérive maximal de l'horloge interne d'un dispositif informatique critique ;

- M le nombre de dispositifs informatiques critiques dudit ensemble ;

- chaque dispositif informatique critique comprend également un module de gestion des panne(s) de synchronisation propre à être détectée(s) lors de la mise en œuvre dudit procédé, et dans lequel le procédé comprend, au cours d'une période courante, préalablement à la réception d'au moins un message de synchronisation et à l'estimation de l'heure courante du serveur émetteur :

- la transmission, par le module de gestion de l'heure du dispositif informatique critique courant, à son propre module de gestion des pannes, de toute information, associée à un module de gestion des pannes d'au moins un serveur émetteur distinct du dispositif informatique critique courant, et reçue au cours de la période précédente,

- l'exécution de chaque action, non encore exécutée, reçue de son propre module de gestion des pannes,

- le dispositif informatique critique courant étant un serveur courant parmi la pluralité de serveurs, chaque serveur étant connecté à chaque autre serveur et à chaque client par une liaison virtuelle de synchronisation ;

- au cours d'une phase d'initialisation, le procédé comprend, préalablement à la réception d'au moins un message de synchronisation et à l'estimation de l'heure courante du serveur émetteur:

- la détermination d'une référence horaire du serveur courant par application d'une fonction affine prédéterminée à la valeur de l'horloge interne du serveur courant à l'instant courant, la fonction affine étant associée à un facteur et à un décalage dont les valeurs sont préalablement initialisées à des valeurs initiales prédéterminées, - l'émission d'un message de synchronisation comprenant un champ d'identification représentatif de la phase d'initialisation du module de gestion de l'heure du serveur courant et comprenant la référence horaire du serveur courant ;

- successivement à l'estimation de l'heure courante du serveur émetteur mise en œuvre, pour chaque message de synchronisation reçu comprenant un champ d'identification représentatif de la phase d'initialisation d'un serveur émetteur distinct, et mise en œuvre dès qu'un premier nombre prédéterminé de messages de synchronisation reçus, est atteint, le procédé comprend :

- la détermination d'une nouvelle référence horaire correspondant à l'heure courante maximale obtenue à partir des heures courantes associées à chaque message,

- la mise à jour du facteur et du décalage de la fonction affine en fonction de ladite nouvelle référence horaire,

- le démarrage de la phase opérationnelle du module de gestion de l'heure du serveur courant.

- successivement à l'estimation de l'heure courante du serveur émetteur mise en œuvre, pour chaque message de synchronisation reçu comprenant un champ d'identification représentatif de la phase opérationnelle d'un serveur émetteur distinct, et mise en œuvre dès qu'un deuxième nombre prédéterminé de messages de synchronisation reçus, est atteint, le procédé comprend :

- la détermination d'une nouvelle référence horaire correspondant à l'heure courante moyenne obtenue à partir des heures courantes associées à chaque message,

- la mise à jour du facteur et du décalage de la fonction affine en fonction de ladite nouvelle référence horaire,

- le démarrage de la phase opérationnelle du module de gestion de l'heure du serveur courant.

- le dispositif informatique critique courant étant un serveur courant parmi la pluralité de serveurs, chaque serveur étant connecté à chaque autre serveur et à chaque client par une liaison virtuelle de synchronisation, au cours de la phase opérationnelle, le procédé comprend :

- pour chaque message de synchronisation reçu comprenant un champ d'identification représentatif de la phase opérationnelle d'un serveur émetteur distinct :

- si l'instant de réception du message est antérieur de plus de deux périodes à l'instant courant, l'émission d'une information représentative d'une anomalie au module de gestion de panne du client courant et l'arrêt du traitement du message,

- sinon ladite estimation de l'heure courante associée audit message - la détermination d'une nouvelle référence horaire correspondant à l'heure courante moyenne obtenue à partir de l'heure courante du serveur courant et des heures courantes associées à chaque message,

- la mise à jour du facteur et du décalage de la fonction affine en fonction de ladite nouvelle référence horaire, et

- l'émission d'un message de synchronisation comprenant un champ d'identification représentatif de la phase opérationnelle du serveur courant et contenant ladite référence horaire du serveur courant ;

- le dispositif informatique critique courant étant un client courant parmi la pluralité de clients, chaque client étant connecté à chaque serveur de la pluralité de serveurs par une liaison virtuelle de synchronisation, au cours d'une phase d'initialisation, successivement à l'estimation de l'heure courante du serveur émetteur mise en œuvre à partir du premier message de synchronisation reçu comprenant un champ d'identification représentatif de la phase opérationnelle d'un serveur émetteur distinct, le procédé comprend :

- la mise à jour de la référence horaire du client courant égale à l'heure courante associée audit message,

- l'initialisation des valeurs initiales de facteur et de décalage d'une fonction affine applicable à la valeur de l'horloge interne du client courant,

- le démarrage de la phase opérationnelle du module de gestion de l'heure du client courant.

- le dispositif informatique critique courant étant un client courant parmi la pluralité de clients, chaque client étant connecté à chaque serveur de la pluralité de serveurs par une liaison virtuelle de synchronisation, au cours d'une phase opérationnelle, le procédé comprend :

- pour chaque message de synchronisation reçu comprenant un champ d'identification représentatif de la phase opérationnelle d'un serveur émetteur distinct :

- si l'instant de réception du message est antérieur de plus de deux périodes à l'instant courant, l'émission d'une information représentative d'une anomalie au module de gestion de panne du client courant et l'arrêt du traitement du message, - sinon ladite estimation de l'heure courante associée audit message,

- si la valeur absolue de la différence entre, d'une part une référence horaire du client courant obtenue par application d'une fonction affine à la valeur de l'horloge interne du client courant à l'instant courant, et d'autre part l'heure courante moyenne obtenue à partir des heures courantes associées à chaque message est supérieure à un seuil prédéterminé de précision, l'émission d'une information représentative d'une anomalie au module de gestion de panne du client courant,

- détermination d'une nouvelle référence horaire correspondant à l'heure courante moyenne obtenue à partir des heures courantes associées à chaque message, et - mise à jour du facteur et du décalage de la fonction affine du client courant en fonction de ladite nouvelle référence horaire.

L'invention a également pour objet un programme d'ordinateur comportant des instructions logicielles qui, lorsqu'elles sont exécutées par un ordinateur, mettent en œuvre le procédé de synchronisation tel que défini ci-dessus.

L'invention a également pour objet un système de synchronisation d'un ensemble de dispositifs informatiques critiques, en particulier des dispositifs avioniques, interconnectés à un réseau de communication d'un véhicule, tel qu'un aéronef, et comprenant chacun un module de gestion de l'heure, l'ensemble de dispositifs informatiques critiques comprenant au moins une pluralité de serveurs de référence horaire, et une pluralité de clients, chaque dispositif informatique critique étant connecté à un au moins un autre dispositif informatique critique par une liaison virtuelle, chaque point de terminaison d'une liaison virtuelle étant associée à une valeur minimale et à une valeur maximale de temps de transmission d'un paquet de données sur ladite liaison virtuelle, le module de gestion de l'heure de chaque dispositif informatique critique courant étant propre à mettre en œuvre et à réitérer périodiquement au moins:

- la réception d'au moins un message de synchronisation transmis par un serveur émetteur distinct dudit dispositif informatique critique courant, chaque message étant associé à un instant de réception et comprenant au moins une référence horaire déterminée par ledit serveur émetteur,

- pour chaque message de synchronisation reçu, l'estimation de l'heure courante du serveur émetteur à partir d'un quintuplet de paramètres comprenant :

^■ ladite référence horaire,

^■ une valeur de l'horloge interne du dispositif informatique critique courant à l'instant courant,

■ une valeur de l'horloge interne du dispositif informatique critique courant à l'instant de réception,

la valeur minimale et la valeur maximale de temps de transmission associée à la liaison virtuelle entre le serveur émetteur et le dispositif informatique critique courant. Ces caractéristiques et avantages de l'invention apparaîtront à la lecture de la description qui va suivre, donnée uniquement à titre d'exemple non limitatif, et faite en référence aux dessins annexés, sur lesquels :

- la figure 1 est une représentation schématique d'un système de synchronisation selon l'invention;

- la figure 2 est un organigramme d'un procédé de synchronisation selon un premier mode de réalisation de l'invention où le dispositif informatique mettant en œuvre le procédé est un serveur ;

- la figure 3 est un organigramme d'un procédé de synchronisation selon un deuxième mode de réalisation de l'invention où le dispositif informatique mettant en œuvre le procédé est un client.

Le système de synchronisation 10 illustré sur la figure 1 est par exemple embarqué à bord d'un aéronef non représenté. Le système de synchronisation 10 est configuré pour échanger une référence horaire entre d'une part une pluralité de M (M≥2) dispositifs informatiques critiques correspondant ici à des dispositifs avioniques, appelé serveurs 12, tel que les trois serveurs S _A , S _B et S _c et d'autre part une pluralité de Q (Q≥2) dispositifs informatiques critiques, correspondant ici à des dispositifs avioniques, appelés clients 14 d et C ₂ .

En particulier, un dispositif avionique serveur 12 ou client 14 est un calculateur avionique propre à exécuter des logiciels, en garantissant un partitionnement spatial et temporel strict de ces logiciels. Ce partitionnement est, par exemple, mis en œuvre par un système d'exploitation conforme à la norme ARINC 653.

Selon un aspect particulier, un même dispositif avionique est propre à fonctionner à la fois comme serveur 12 (i.e. à mettre en œuvre les étapes spécifiques du procédé de synchronisation associé au type « serveur » de dispositif avionique) et comme client 14 (i.e. à mettre en œuvre les étapes spécifiques du procédé de synchronisation associé au type «client » de dispositif avionique).

Serveurs 12 et clients 14 sont connectés à un réseau de communication 16, par exemple un réseau de communication avionique conforme à la norme ARINC A664-p7, et de préférence redondé.

Plus précisément, le réseau 16 comprend une pluralité de commutateurs réseau

17.

De plus, selon une architecture prédéfinie et statique du réseau, les flux de données échangés entre les différents dispositifs avioniques serveurs ou clients sont séparés selon une ségrégation stricte. En particulier, pour chaque serveur 12, par exemple le serveur S _A , une liaison virtuelle 18 dédiée (ou VL pour « Virtual Link » en anglais), dite de synchronisation, connecte ce serveur 12, via les commutateurs réseau 17, à tous les autres serveurs 12 S _B et S _c et tous les clients Ci et C ₂ De telles liaisons virtuelles 18 de synchronisation sont propres à transporter des messages de synchronisation d'horloge.

De manière similaire, pour chaque client 14, par exemple le client d , une liaison virtuelle 20 dédiée, dite de commande, (ou VL pour « Virtual Link » en anglais) connecte ce client 14 vers tous les serveurs 12 S _A , S _B et S _c .

En particulier, via une telle liaison virtuelle de commande chaque client 14 est propre à demander le redémarrage du procédé de synchronisation selon l'invention, ou la remise à zéro de la référence horaire partagée. A chacune de ces commandes est associé l'instant, selon la référence horaire, où la commande doit être exécutée par les serveurs 12.

Selon un aspect particulier, une commande n'est prise en compte par les serveurs que si elle est confirmée par la réception d'une commande du même type envoyée par au moins un autre client dans un laps de temps prédéfini.

Selon un aspect particulier, les liaisons virtuelles 18 de synchronisation sont configurées avec un plus haut niveau de priorité que toutes les autres liaisons virtuelles mises en œuvre par le réseau 16, notamment les liaisons virtuelles 20 de commande.

De plus, chaque dispositif avionique serveur 12 ou client 14 contient au moins les éléments suivants : une horloge interne H,, un module de gestion de l'heure G_H propre à mettre en œuvre le procédé selon l'invention et correspondant au point d'origine et/ou respectivement destinataire des liaisons virtuelles de synchronisation 18 et de commande 20, un module de gestion des pannes G_P dédié à la gestion des pannes détectées lors de la mise en œuvre du procédé selon l'invention, un module d'émission réseau E dont le délai de transmission d'un message depuis la partition (au sens de la norme ARINC 653) jusqu'à son émission sur le réseau 16 est connu et fixe (pas de gigue (i.e. variation de latence)), un module de réception R réseau, dans lequel chaque paquet reçu est propre à être horodaté avec l'horloge interne H, du dispositif avionique, dès sa réception par le port d'entrée connecté au réseau 16 A664-p7.

Les modules de gestion de l'heure G_H et de gestion des pannes G_P sont par exemple implémentés, dans chacun des serveurs 12 ou client 14, par un logiciel hébergé dans une ou plusieurs partition(s).

En variante, tout ou partie des modules de gestion de l'heure G_H et de gestion des pannes G_P est propre à être mise en œuvre au moyen d'un ou de plusieurs circuit(s) logique programmable, tel qu'un FPGA (de l'anglais Field Programmable Gâte Array), ou encore sous forme d'un circuit intégré dédié, tel qu'un ASIC (de l'anglais Application Spécifie Integrated Circuit) montés sur une carte électronique embarquée sur le dispositif avionique considéré.

Selon la présente invention, un message émis sur une liaison virtuelle 18 de synchronisation comprend notamment quatre champs distincts, à savoir :

- un champ dédié à un numéro de version du protocole correspondant par exemple à un entier sur quatre bits,

- un champ d'identification du type de message selon que le procédé de synchronisation mis en œuvre dans le dispositif avionique considéré est en phase d'initialisation INIT ou en phase opérationnelle TIME, codé par exemple par un entier sur quatre bits,

- un champ notification émis par le module de gestion de pannes du serveur émetteur, par exemple S _B , à destination du module de gestion de pannes de chacun des autres serveurs par exemple les serveurs S _A et S _c , une tel champ pouvant prendre une valeur nulle représentative de l'absence de notification, ou toute autre valeur dépendant du fonctionnement interne des modules de gestion de pannes représentative de la première notification émise par le module de gestion de pannes et non encore transmise sur la dite liaison virtuelle 18 de synchronisation, codée par exemple par un entier sur un octet, et

- un champ dédié à l'insertion de la référence horaire Href calculée par le serveur qui émet le message, par exemple la référence horaire Href _B calculée par le serveur S _B , codée par exemple par un entier sur huit octets indiquant le nombre de microsecondes écoulées depuis la remise à zéro de ce compteur.

Lors de la conception du réseau de communication 16, une plateforme de configuration 22 est propre à déterminer, pour chaque point de terminaison (i.e. un serveur 12 ou un client 14) d'une liaison virtuelle 18 de synchronisation, les meilleur BCTT et pire WCTT temps théoriques de transmission d'un paquet reçu dans la liaison virtuelle considérée entre deux dispositifs avioniques que ce soit un couple de deux serveurs ou un couple comprenant un serveur et un client.

Ces paramètres BCTT et WCTT associés à une liaison virtuelle 18 donnée ainsi que d'autres données de configuration prédéterminées sont intégrées dans les fichiers de configuration de chaque dispositif avionique du système de synchronisation 10 embarqué et/ou dans un fichier stocké au sein de la plateforme de configuration 22. Parmi les autres données de configuration figurent notamment : le nombre N de serveurs 12 nécessaires pour garantir la robustesse de la référence horaire déterminée et partagée au sein du réseau 16 ARINC A664-p7, un taux D de dérive maximal de l'horloge interne H, d'un dispositif avionique 12 ou 14 considéré par rapport à une heure théorique exacte (ce taux est une donnée caractéristique des composants électroniques implantés dans le dispositif avionique), une donnée de précision P _R correspondant à l'écart maximal acceptable entre la référence horaire de deux clients par exemple, ou encore la valeur prédéterminée de la période P de synchronisation, le procédé selon l'invention étant mis en œuvre périodiquement conformément à cette période P par chaque module de gestion de l'heure G_H qu'il soit compris dans un dispositif avionique correspondant à un serveur 12 ou à un client 14, etc.

En particulier, pour garantir la fiabilité de la valeur de la donnée de précision P _R , la plateforme de configuration 22, est propre à vérifier que la période P est conforme à la relation suivante :

avec G(s',s) la différence temporelle entre les meilleur BCTT et pire WCTT temps théoriques de transmission d'un paquet transmis dans la liaison virtuelle par un serveur s' vers un serveur s.

Par ailleurs, chaque module de gestion de l'heure G_H est propre à détecter une anomalie de synchronisation, par exemple une différence entre sa propre référence horaire et celle d'un autre serveur qui soit trop importante pour garantir la précision P _R , et à la signaler au module de gestion des pannes G_P du dispositif avionique auquel les modules de gestion de l'heure G_H et de gestion des pannes G_P appartiennent tous deux.

En réponse, le module de gestion des pannes G_P est propre à indiquer au module de gestion de l'heure G_H une suite d'actions à exécuter en réaction à cette anomalie de synchronisation. La correspondance entre le type d'anomalie de synchronisation détectée et la suite d'actions à exécuter est également une donnée de configuration propre à être stockée dans un fichier de configuration de chaque dispositif avionique considéré et dépend de l'architecture de sécurité du système informatique critique global et de la ou des utilisations de la référence horaire.

Une telle action est par exemple le redémarrage du module de gestion de l'heure G_H, ou la diffusion, par le module de gestion de l'heure G_H d'une information représentative de cette anomalie, également appelée notification, aux autres serveurs 12, ou l'exclusion d'un serveur 12 à prendre en compte pour mettre en œuvre le procédé de synchronisation selon l'invention, ou l'arrêt de la mise en œuvre du procédé de synchronisation selon l'invention, etc ..

Le procédé de synchronisation mis en œuvre par chaque dispositif avionique, serveur 12 ou client 14 du système de synchronisation 10 de la figure 1 va maintenant être présenté plus en détail en référence à la figure 2, lorsque le dispositif avionique est un serveur 1 2 et en référence à la figure 3, lorsque le dispositif avionique est un client 14.

Comme décrit par la suite en relation avec la figure 2 ou la figure 3, que le dispositif avionique soit un serveur 12 ou un client 14, ces deux types de dispositifs avioniques du système de synchronisation 10 mettent en œuvre tous deux périodiquement, deux étapes essentielles, à savoir une étape de réception d'au moins un message de synchronisation transmis par un serveur 1 2 émetteur distinct (par exemple S _B ) du dispositif informatique critique courant (serveur 1 2, par exemple, S _A ou client 14, par exemple Ci), chaque message étant associé à un instant de réception t/ ^' avec / l'index du serveur émetteur et comprenant au moins une référence horaire Href _B déterminée par le serveur émetteur (par exemple S _B ), et pour chaque message de synchronisation reçu, une étape d'estimation de l'heure courante Hq du serveur émetteur (par exemple S _B ) à partir d'un quintuplet de paramètres comprenant :

^■ la référence horaire Href, avec / ^' l'index du serveur émetteur, par exemple Href _B pour le serveur émetteur S _B .

■ une valeur h _in1 _, _c _ _di de l'horloge interne du dispositif informatique di critique courant à l'instant courant te, l'instant courant te étant propre à augmenter au fur et à mesure du temps qui s'écoule et correspondant à l'instant courant de mise en œuvre d'une étape du procédé selon l'invention,

^■ une valeur h _intJLdi de l'horloge interne du dispositif informatique di critique courant à l'instant de réception t/ ^' ,

^■ la valeur minimale BCTT(Si, d,) et la valeur maximale WCTT(Si, d,) de temps de transmission associée à la liaison virtuelle VL entre le serveur émetteur S,, par exemple le serveur émetteur S _B , et le dispositif informatique critique d, courant.

De plus, que le dispositif avionique soit un serveur 1 2 ou un client 14, ces deux types de dispositifs avioniques du système de synchronisation 1 0 mettent en œuvre au cours d'une période courante, préalablement à la réception d'au moins un message de synchronisation et à l'estimation de l'heure courante Hc _B du serveur émetteur S _B :

- la transmission, par le module de gestion de l'heure du dispositif informatique critique courant, à son propre module de gestion des pannes G_P, de toute information, associée à un module de gestion des pannes G_P d'au moins un serveur émetteur distinct du dispositif informatique critique courant, et reçue au cours de la période précédente,

- l'exécution de chaque action, non encore exécutée, reçue de son propre module de gestion des pannes G_P.

En d'autres termes, la présente invention tire profit des caractéristiques spécifiques des systèmes partitionnés critiques, à savoir la configuration prédéfinie et statique du réseau de communication 16, la ségrégation stricte des flux de données échangés au sein de ce réseau de communication 16, et la maîtrise des temps de traversée du réseau en utilisant le calcul théorique mis en œuvre lors de la conception du réseau 16 pour déterminer le temps de traversée d'un paquet de donnée d'une liaison virtuelle 18, ce qui permet d'éviter l'utilisation de méthodes statistiques, telles que, par exemple, celles associées au protocole PTP (IEEE 1588) (pour « Précision Time Protocol » en anglais), impropres aux systèmes informatiques critiques tels que les systèmes avioniques, utilisant par ailleurs une ségrégation des flux au sein d'un réseau A664-P7, car la précision de l'heure ne peut être garantie de manière formelle du fait de l'approche statistique utilisée.

De plus la présente invention est basée sur l'utilisation d'une pluralité de serveurs propres à définir en commun une référence horaire précise ce qui rend robuste la synchronisation mise en œuvre selon l'invention.

En effet, l'utilisation d'un seul serveur n'est pas adaptée pour la détermination d'une référence horaire utilisable pour une fonction informatique critique telle qu'une fonction avionique.

De plus, la présente invention permet d'éviter de modifier le fonctionnement des commutateurs réseau 17, ce qui permet une mise en œuvre du procédé selon l'invention au sein de réseaux de communication existants 16.

En relation avec la figure 2, le procédé 24 de synchronisation mis en œuvre lorsque le dispositif avionique correspond à un serveur 12 est ci-après décrit.

Un tel procédé 24 de synchronisation mis en œuvre par le serveur comprend deux phases à savoir une phase d'initialisation 26 et une phase opérationnelle 28.

Dans la phase d'initialisation 26, le procédé 24 de synchronisation mis en œuvre par un serveur 12 courant, par exemple S _A comprend une première étape 30 d'initialisation de paramètres d'une fonction affine prédéterminée pour obtenir l'heure de référence Href associée au serveur 12 S _A . En particulier, pour chaque serveur S,, ces paramètres correspondent à un facteur coeffsi initialisé à un et à décalage offset _S i initialisé à l'opposé de la valeur d'horloge interne à l'instant d'initialisation -h _{int Jinit} _ _Si .

Puis pour chaque période P, selon une étape 32, le module de gestion de l'heure G_H du serveur courant S _A met en œuvre la transmission à son propre module de gestion des pannes G_P, de toute information (i.e. notification ou champs notification), associée à un module de gestion des pannes G_P d'au moins un serveur émetteur distinct du serveur courant S _A , et reçue au cours de la période précédente.

Comme indiqué précédemment cette étape 32 est suivie par l'étape 34 d'exécution de chaque action, non encore exécutée, reçue de son propre module de gestion des pannes G_P.

Une fois ces étapes 30 à 34 effectuée, le serveur en phase d'initialisation 26, met en œuvre une étape 36 de détermination de la référence horaire Href _A du serveur courant S _A par application de la fonction affine prédéterminée à la valeur de l'horloge interne du serveur courant à l'instant courant t _c , tel que :

Href _A (t _c ) = coeff _A . _in i _JC _SA + offset _A = h _{int JC} _SA

Selon l'étape 36, le serveur courant S _A émet ensuite un message de synchronisation comprenant un champ d'identification représentatif de la phase d'initialisation du module de gestion de l'heure du serveur courant S _A , à savoir par exemple INIT, et comprenant la référence horaire du serveur courant S _A , à savoir Href _A .

Puis deux variantes de la phase d'initialisation sont mises en œuvre selon le type de message de synchronisation reçu, INIT ou TIME, et en fonction du nombre de messages de synchronisation, autrement dit en fonction du nombre de serveurs distincts émetteurs de message de synchronisation.

Selon une première variante, si, selon une étape 38, le serveur courant S _A a reçu au moins un message INIT d'au moins (N - 1 ) serveurs distincts depuis l'entrée en phase d'initialisation 26, alors pour chaque dernier message INIT reçu de serveurs distincts (message reçu du serveur S, correspondant par exemple à S _B ou S _c , à l'instant t,, et contenant la référence horaire Href,), le module de gestion de l'heure du serveur courant S _A , selon une étape 40 met en œuvre l'estimation de l'heure courante du serveur émetteur, par exemple S _B , conformément à l'équation suivante à l'instant courant t _c :

Hc _B = Href _B + h _{int tc SA} - h _{int ti SA} + (BCTT(S _B ,S _A ) + WCTT(S _B ,S _A ))/2.

Puis cette étape 40, est suivie d'une étape 42 de détermination de la valeur maximale parmi les heures courantes des serveurs émetteurs estimées, par exemple en relation avec la figure 1 , la valeur maximale Hmax des heures courantes Hc _B et Hc _c associées respectivement aux serveurs émetteurs S _B et S _c .

L'étape suivante 44 a comme rôle d'utiliser la valeur Hmax comme nouvelle référence horaire NHref _A associée au serveur S _A . Pour cela, lors de cette étape 44, le module de gestion de l'heure met en œuvre la mise à jour (i.e. de correction) des nouveaux paramètres Ncoeff _A et Noffset _A de la fonction affine associée au serveur S _A selon les équations suivantes et à utiliser lors de la période P suivante:

Ncoeff _A = 1 + (NHref _A -Href _A )/P, et Noffset _A = offset _A + (coeff _A -Ncoeff _A ). h _int _ _tc _ _SA .

Une fois cette étape 44 mise en œuvre, la phase opérationnelle 28 est démarrée à la période P suivante.

Selon une deuxième variante, si, selon une étape 46, le serveur courant S _A a reçu au moins un message TIME (i.e. représentatif de la phase opérationnelle 28) d'au moins N serveurs distincts depuis l'entrée en phase d'initialisation 26, alors pour chaque dernier message TIME reçu de serveurs distincts (message reçu du serveur S, correspondant par exemple à S _B ou S _c , à l'instant t, et contenant la référence horaire Href,), le module de gestion de l'heure du serveur courant S _A , selon une étape 48 met en œuvre l'estimation de l'heure courante du serveur émetteur, par exemple S _B conformément à l'équation suivante à l'instant courant t _c :

Hc _B = Href _B + h _{int tc SA} - h _intJJ3A + (BCTT(S _B ,S _A ) + WCTT(S _B ,S _A ))/2,

sinon les étapes 32 à 38 du procédé précédemment décrites sont réitérées à la période P suivante, jusqu'à ce que la condition de l'étape 38 soit satisfaite, à savoir la réception d'au moins un message INIT d'au moins (N - 1 ) serveurs distincts depuis l'entrée en phase d'initialisation 26, ou alors que la condition associée à l'étape 46, à savoir la réception d'au moins un message TIME (i.e. représentatif de la phase opérationnelle 28) d'au moins N serveurs distincts depuis l'entrée en phase d'initialisation 26.

Puis cette étape 48, est suivie d'une étape 50 de détermination de la valeur moyenne des heures courantes des serveurs émetteurs estimées, par exemple en relation avec la figure 1 , la valeur moyenne Hmoy _s des heures courantes Hc _B et Hc _c associées respectivement aux serveurs émetteurs S _B et S _c .

L'étape suivante 52 a comme rôle d'utiliser la valeur Hmoy _s comme nouvelle référence horaire NHref _A associée au serveur S _A . Pour cela, lors de cette étape 52, le module de gestion de l'heure met en œuvre la mise à jour (i.e. de correction) des nouveaux paramètres Ncoeff _A et Noffset _A de la fonction affine associée au serveur S _A selon les équations suivantes et à utiliser lors de la période P suivante:

Ncoeff _A = 1 + (NHref _A -Href _A )/P, et Noffset _A = offset _A + (coeff _A -Ncoeff _A ). h _inUc _ _SA . Une fois cette étape 52 mise en œuvre, la phase opérationnelle 28 est démarrée à la période P suivante.

Lorsque le serveur courant S _A est en phase opérationnelle 28, à chaque période P, le procédé de synchronisation comprend une étape 54, durant laquelle le module de gestion de l'heure G_H du serveur courant S _A met en œuvre la transmission à son propre module de gestion des pannes G_P, de toute information (i.e. notification ou champs notification), associée à un module de gestion des pannes G_P d'au moins un serveur émetteur distinct du serveur courant S _A , et reçue au cours de la période précédente.

Comme indiqué précédemment cette étape 54 est suivie par l'étape 56 d'exécution de chaque action, non encore exécutée, reçue de son propre module de gestion des pannes G_P.

Puis selon une étape 58, pour chaque dernier message TIME reçu de serveurs distincts (message reçu du serveur S, correspondant par exemple à S _B ou S _c , à l'instant t,, et contenant la référence horaire Href,), le module de gestion de l'heure du serveur courant S _A en phase opérationnelle 28 met en œuvre :

- si l'instant de réception du message est antérieur de plus de deux périodes à l'instant courant, l'émission d'une information représentative d'une anomalie au module de gestion de panne du client courant et l'arrêt du traitement du message TIME reçu,

- sinon l'estimation de l'heure courante du serveur émetteur, par exemple S _B conformément à l'équation suivante à l'instant courant t _c :

Hc _B = Href _B + h _{int tc SA} - h _int _ _tLSA + (BCTT(S _B ,S _A ) + WCTT(S _B ,S _A ))/2.

Puis cette étape 58, est suivie d'une étape 60 de détermination de la valeur moyenne de h _{int tc SA} et des heures courantes des serveurs émetteurs estimées, par exemple en relation avec la figure 1 , la valeur moyenne Hmoy _s de h _{int tc SA} et des heures courantes Hc _B et Hc _c associées respectivement aux serveurs émetteurs S _B et S _c .

L'étape suivante 62 a comme rôle d'utiliser la valeur Hmoy _s comme nouvelle référence horaire NHref _A associée au serveur S _A . Pour cela, lors de cette étape 62, le module de gestion de l'heure met en œuvre la mise à jour (i.e. de correction) des nouveaux paramètres Ncoeff _A et Noffset _A de la fonction affine associée au serveur S _A selon les équations suivantes et à utiliser lors de la période P suivante:

Ncoeff _A = 1 + (NHref _A -Href _A )/P, et Noffset _A = offset _A + (coeff _A -Ncoeff _A ). h _inUc _ _SA .

Une fois cette étape 62 mise en œuvre, une étape 64 d'émission d'un message de synchronisation comprenant un champ d'identification TIME représentatif de la phase opérationnelle du serveur courant et contenant la nouvelle référence horaire NHref _A associée au serveur S _A est mise en œuvre.

En relation avec la figure 3, le procédé 66 de synchronisation mis en œuvre lorsque le dispositif avionique correspond à un client 14 est ci-après décrit.

Un tel procédé 66 de synchronisation mis en œuvre par le client comprend également deux phases à savoir une phase d'initialisation 68 et une phase opérationnelle 70.

Dans la phase d'initialisation 68, à chaque période P, le procédé 66 de synchronisation mis en œuvre par un client 14 courant, par exemple Ci comprend une première étape 72 dans laquelle le module de gestion de l'heure G_H du client courant Ci met en œuvre la transmission à son propre module de gestion des pannes G_P, de toute information (i.e. notification ou champs notification), associée à un module de gestion des pannes G_P d'au moins un serveur émetteur, et reçue au cours de la période précédente.

Comme indiqué précédemment cette étape 72 est suivie par l'étape 74 d'exécution de chaque action, non encore exécutée, reçue de son propre module de gestion des pannes G_P.

Puis selon une étape 76, si un premier message TIME (i.e. représentatif de la phase opérationnelle 28 d'un serveur émetteur) est reçu d'un serveur (message reçu du serveur S, correspondant par exemple à S _A , S _B ou S _c , à l'instant t,, et contenant la référence horaire Href,), le module de gestion de l'heure du client courant Ci met en œuvre selon une étape 78, l'estimation de l'heure courante du serveur émetteur, par exemple S _B , conformément à l'équation suivante à l'instant courant t _c :

Hc _B = Href _B + h _int _ _te _ _c1 - h _intJi _ _C1 + (BCTT SB ) + sinon les étapes 72 et 74 de transmission d'information de notification et d'exécution d'action sont réitérées à la période P suivante, jusqu'à ce qu'un message TIME soit reçu.

La valeur Hc _B est alors sélectionnée par le client courant d , selon une étape 80, comme sa nouvelle référence horaire H _C i= Hc _B . Pour cela, lors de cette étape 80, le module de gestion de l'heure met en œuvre l'initialisation de paramètres de la fonction affine applicable à la valeur de l'horloge interne du client courant Ci. Ces paramètres correspondent à un facteur coeff _d initialisé à un et à un décalage offset _d initialisé sous la forme : à l'instant courant tc de mise en œuvre de l'étape d'initialisation 80.

Une fois cette étape 80 mise en œuvre, la phase opérationnelle 70 est démarrée à la période P suivante. En phase opérationnelle 70 du client courant, le procédé 66 comprend alors à chaque période P, une première étape 82 dans laquelle le module de gestion de l'heure G_H du client courant Ci met en œuvre la transmission à son propre module de gestion des pannes G_P, de toute information (i.e. notification ou champs notification), associée à un module de gestion des pannes G_P d'au moins un serveur émetteur, et reçue au cours de la période précédente.

Comme indiqué précédemment cette étape 82 est suivie par l'étape 84 d'exécution de chaque action, non encore exécutée, reçue de son propre module de gestion des pannes G_P.

Puis, pour chaque dernier message TIME reçu par le client courant, par exemple

Ci, de serveurs distincts (message reçu du serveur S, correspondant par exemple à S _A , S _B OU Se, à l'instant t,, et contenant la référence horaire Href,), selon une étape 86, si l'instant de réception t, du message est antérieur de plus de deux périodes P à l'instant courant t _c (autrement dit si t _c -ti>2P), l'émission d'une information représentative d'une anomalie au module de gestion de panne du client courant et l'arrêt du traitement de ce message est mis en œuvre.

Sinon le module de gestion de l'heure du client courant Ci met en œuvre selon une étape 90, l'estimation de l'heure courante du serveur émetteur, par exemple S _B conformément à l'équation suivante à l'instant courant t _c :

Hc _B = Href _B + h _{int tc C1} - h _intJLC1 + (BCTTÎS _B ) + WCTTÎS _B ))^.

Puis, selon une étape 92, le module de gestion de l'heure du client courant Ci met en œuvre la détermination de la valeur moyenne Hmoy _c des heures courantes Hc _A, Hc _B et Hcc associées respectivement aux serveurs émetteurs S _A , S _B et S _c .

Selon une étape 94, si la valeur absolue de la différence entre d'une part la référence horaire Href _C i du client courant Ci obtenue par application d'une fonction affine à la valeur de l'horloge interne h _int _ _te _ _c1 du client courant Ci à l'instant courant t _c , et d'autre part l'heure courante moyenne Hmoyc est supérieure à un seuil prédéterminé correspondant à la donnée de précision P _R du fichier de configuration du client courant considéré, par exemple Ci, alors l'émission d'une information représentative d'une anomalie (i.e. panne) au module de gestion de panne G_P du client courant Ci est mise en œuvre.

Autrement dit, avec Hrefd = coeffd . h _{int te} _ci+offset _C i , si | Hmoy _c - Href _ci | > P _R , alors une panne est signifiée par le module de gestion de l'heure G_H du client courant Ci à son propre module de gestion de panne G_P. Puis, selon l'étape 96, la nouvelle référence horaire du client courant Ci NHref _d correspond alors à l'heure courante moyenne Hmoy _c et la mise à jour de nouvelles valeurs des paramètres Ncoeff _d et Noffset _d de la fonction affine associée au client courant Ci est mise en œuvre selon les équations suivantes et à utiliser lors de la période P suivante:

Ncoeffd = 1 + ( NHrefd -H ref _C i)/P, et Noffsetd = offsetd + (coeffd -Ncoeffd). h _in , _ _te _ _G1 .

Ainsi, le système de synchronisation selon la présente invention met en œuvre une pluralité de serveurs 12 qui définissent en commun une heure précise. Cette heure commune est ensuite envoyée aux clients 14. Le système selon la présente invention ne nécessite aucune fonction spécifique des commutateurs réseau ce qui permet à la fois la conservation du ou des réseau(x) existant(s), sans impact matériel ni logiciel sur les équipements de réseau déjà installés, et une amélioration de l'intégrité des réseaux, en surveillant le temps de traversée des messages.