FR2962619A1 - Dispositif d'acces a des donnees a bord d'un aeronef - Google Patents

Abstract

L'invention concerne un dispositif (100) d'accès à des données par des clients (101) à bord d'un aéronef, chacun des clients (101) étant associé une application avionique (102). Chacun des clients (101) comporte une façade (103) permettant l'accès aux données stockées sur le serveur aux applications avioniques (102) La façade (103) comprend : - des moyens pour la souscription d'une application avionique (102) à un abonnement à une modification d'une donnée, - des moyens pour filtrer les notifications émises par le serveur de données en fonction des abonnements de l'application avionique (102), et pour avertir l'application avionique (102) d'une modification d'une donnée à laquelle elle est abonnée.

Description

Dispositif d'accès à des données à bord d'un aéronef L'invention concerne l'accès à des bases de données à bord d'un aéronef. Selon l'art connu, le stockage de données à bord d'un aéronef est réalisé sur différentes bases de données embarquées. Chaque système avionique est responsable des données qu'il exploite. Cette répartition des données simplifie la conception de chaque système, mais a pour inconvénients : la multiplication des bases de données, la duplication des données entre différents systèmes avec des risques d'incohérences, une consommation importante de l'espace de stockage sans possibilité de factorisation et une complexification des opérations de mise à jour de ces bases de données. On connaît déjà des dispositifs de type DDS (pour Data Distribution Service) permettant de communaliser les bases de données pour les mettre en partage (gain en cohérence, facilité de maintenance et de développement des applications, optimisation dans l'utilisation des bases de données, etc.). Ces dispositifs permettent une indépendance des applications clientes vis-à-vis de la fourniture des données et de leur localisation. Cependant, de tels dispositifs sont mis en application uniquement au sol, car ils ne répondent pas aux contraintes spécifiques du domaine avionique. En effet les réseaux avioniques, par exemple de type AFDX (pour Avionics Full DupleX), ne sont pas conçus pour du transactionnel, mais plutôt adaptés au « broadcast » c'est-à-dire à la diffusion d'informations depuis un émetteur vers plusieurs récepteurs. Ceci pose problème en particulier pour la gestion des accès à des données semi- statiques, c'est-à-dire des données pouvant être modifiées. L'utilisation directe d'un dispositif de type DDS au domaine avionique n'est donc pas envisageable. L'invention vise à pallier les problèmes cités précédemment en proposant un dispositif d'accès à des données, en particulier des données semi-statiques, à bord d'un aéronef par des applications avioniques indépendamment de la localisation du stockage des données et avec des qualités de service étendues telles que la tolérance aux pannes ou la répartition de la charge.

A cet effet, l'invention a pour objet un dispositif d'accès à des données par des clients à bord d'un aéronef, chacun des clients étant associé une application avionique, lesdites données étant stockées sur au moins un serveur de données embarqué à bord de l'aéronef, lesdites données étant accessibles en écritures et pouvant être modifiées, caractérisé en ce que le serveur comporte des moyens pour notifier à l'ensemble des clients des modifications sur les données qu'il stocke, et en ce que chacun des clients comporte une façade permettant 10 l'accès aux données stockées sur le serveur aux applications avioniques, ladite façade comprenant : des moyens pour la souscription d'une application avionique à un abonnement à une modification d'une donnée, des moyens pour filtrer les notifications émises par le serveur de données 15 en fonction des abonnements de l'application avionique, et pour avertir l'application avionique d'une modification d'une donnée à laquelle elle est abonnée. L'invention a pour avantage d'être plus adapté à un réseau AFDX utilisant notamment des canaux virtuels (Virtual Link) c'est-à-dire comportant 20 un émetteur et plusieurs récepteurs. Cette solution tire donc partie de la capacité de diffusion (ou multicast) de l'AFDX. Le serveur diffuse une notification à chaque modification de la base semi-statique. Les façades ont en charge de traiter ces notifications et de ne remonter que celles pertinentes (c'est-à-dire correspondant aux abonnements) vers le client applicatif. 25 Ceci a aussi pour avantage de décharger les serveurs de la gestion des abonnements qui traitent uniquement de la publication des évènements. Ainsi, les serveurs ne sont pas surchargés avec un algorithme de filtrage d'émission des événements, ni de gestion des abonnements. Ceci a aussi pour avantage de simplifier, au niveau des serveurs, 30 le traitement lors du redémarrage d'un client applicatif. Au démarrage, une application s'abonne auprès d'une façade aux changements d'état des données semi-statiques auxquelles elle s'intéresse. Ces abonnements sont conservés et gérés uniquement au niveau de la façade. Le choix de conserver les abonnements seulement au niveau des façades évite de devoir 35 traiter au niveau du serveur les cas de relance de clients applicatifs. En effet, si les abonnements étaient gérés au niveau du serveur, il serait nécessaire de répercuter la disparition de chaque client dans la base des abonnements. De plus en cas de réplicas de serveurs, il serait nécessaire de dupliquer les abonnements sur les différents serveurs et d'en vérifier la cohérence. En cas de relance d'un client applicatif, la façade perd l'ensemble des abonnements. Au redémarrage, le client s'abonne à nouveau auprès de la façade. L'utilisation d'un intermédiaire (une façade) entre une application avionique et les serveurs (dans le cas où les données sont réparties sur plusieurs serveurs) permet de masquer à cette application avionique la localisation physique des données. Cette solution est compatible avec l'utilisation de serveurs redondants qui garantissent un accès aux données contre un certain niveau de panne. Selon un mode de réalisation préféré de l'invention, les façades sont réparties entre au moins un premier et un deuxième groupe, le premier groupe recevant directement les notifications de modifications sur les données émises par le serveur, les façades appartenant au premier groupe comportant en outre des moyens pour émettre lesdites notifications de modifications de données aux façades appartenant au deuxième groupe, l'émission des notifications vers les façades du deuxième groupe étant effectuée après que lesdites notifications ont été filtrées et transmises aux applications avioniques associées aux clients des façades du premier groupe. Le premier groupe a pour mission de retransmettre les notifications vers un deuxième groupe et ainsi de suite en cascade vers d'éventuels autres groupes.

Cette caractéristique a pour avantage de protéger le dispositif selon l'invention contre un message tueur. Un message tueur est une notification comportant une anomalie qui a pour conséquence, lorsqu'elle est reçue et traitée par une application cliente, de provoquer un dysfonctionnement voire un arrêt complet de celle-ci. Une diffusion massive d'un tel message est donc très préjudiciable aux systèmes de vol utilisant les applications avioniques. En ne diffusant pas les notifications vers toutes les façades en même temps, mais seulement à destination d'un premier groupe, on limite l'impact néfaste du message. En cas de message tueur, le premier groupe de façade tomberait, mais sans contaminer les groupes suivants.

L'invention sera mieux comprise et d'autres avantages apparaîtront à la lecture de la description détaillée faite à titre d'exemple non limitatif et à l'aide des figures parmi lesquelles : La figure 1 représente un exemple de mise en oeuvre du dispositif 5 d'accès aux données selon l'invention. La figure 2 représente le fonctionnement interne d'une façade. La figure 3 représente un exemple du déroulement d'une mise à jour d'une donnée avec le dispositif selon l'invention. La figure 4 représente un exemple du déroulement d'une mise à 10 jour d'une donnée dans un mode de réalisation préféré de l'invention. Dans le dispositif d'accès à des données à bord d'un aéronef selon l'invention, les données sont stockées sur des bases de données centralisées hébergées sur au moins un serveur (ADBS1). Pour satisfaire aux contraintes avioniques, ce serveur est 15 matériellement redondé par un ou deux répliquas. Le serveur héberge des données, dites semi-statiques, pouvant être modifiées. Autrement dit, les bases de données sont ouvertes non seulement à la lecture, mais aussi à l'écriture. La figure 1 représente un exemple de mise en oeuvre du dispositif 20 d'accès aux données selon l'invention. Le dispositif comprend un premier serveur ADBS1 et un second serveur ADBS2 répliquant les données du premier serveur ADBS1 pour assurer une redondance. Le dispositif comprend aussi au moins un client 101. Chacune des applications nécessitant un accès aux données est associée à un client 101 qui lui est 25 propre. Un client 101 comporte une façade 103 qui est un intermédiaire entre une application avionique 102 et un (ou des) serveur(s) pour l'accès aux données. Une application avionique 102 nécessite un accès en lecture et/ou en écriture aux données stockées sur le serveur par exemple des données de navigation aérienne, de plan de Vol, de Météo ou des NOTAMs. Le rôle 30 de la façade 103 est donc d'offrir un accès aux données à l'application avionique 102. Les clients et les serveurs dialoguent par le biais d'une couche logiciel de communication dite middleware. Selon une variante de réalisation de l'invention, les clients sont regroupés par familles. Ces familles sont, par exemple, au nombre de trois : 35 (i) LocalClient, pour le client colocalisé avec un serveur de données (Pattern « Database Server on Favored Client ), (ii) AvionicClient, pour les clients avioniques et (iii) OWClient, pour les clients de la partie avionique dite « monde ouvert » (Open World). Dans ce cas, la famille à laquelle appartient le client émetteur est 5 indiquée par la façade dans la requête. Cette caractéristique a pour avantage de permettre de fournir des qualités de service différentes en fonction des applications clientes. Les deux serveurs ADBS1, ADBS2 présentent une structure similaire. Un serveur comprend : un point d'entrée (ou Front End) 104.1, 10 104.2 pour gérer les requêtes émises par les clients, un ensemble (ou Pool) de gestionnaires de requêtes 106.1, 106.2, au moins une base de données 107.1, 107.2 et un éditeur (ou « publisher ») 108.1, 108.2. Le rôle de l'ensemble de gestionnaires de requêtes 106.1, 106.2 est de traiter les requêtes. Le rôle d'un gestionnaire de requête est de traiter une seule 15 requête à la fois. Le point d'entrée 104.1, 104.2 comprend une pile 105.1, 105.2 pour stocker des requêtes en attente. L'éditeur 108.1, 108.2 permet de publier des modifications d'une donnée à destination des clients. L'éditeur contribue à la mise en oeuvre d'un service de publication et d'abonnement aux modifications des données qui est détaillé plus loin dans la description. 20 Le point d'entrée 104.1, 104.2 du serveur est chargé de la gestion des requêtes émises vers lui par les clients. La gestion des requêtes comprend : - la récupération des requêtes émises par les clients, - la vérification de la pile 105.1, 105.2 de requêtes en attente pour contrôler 25 qu'elle n'est pas saturée (contrôle de flux), la validation des droits d'accès du client émetteur (contrôle d'accès), - la vérification que l'émetteur n'a pas dépassé son quota de requêtes en attente (contrôle de flux), - le stockage des nouvelles requêtes dans la pile 105.1, 105.2 des requêtes 30 en attente de traitement, - l'horodatage de chaque requête pour permettre une surveillance du traitement de chaque requête, la surveillance du bon déroulement de l'ensemble de gestionnaires de requêtes 106.1, 106.2.

Le point d'entrée collecte régulièrement les requêtes dans les couches inférieures de communication avant que celles-ci ne soient saturées (en cas d'affluence par exemple). Avantageusement, un serveur comprend plusieurs piles de requêtes en attente de traitement, chacune des piles étant dédiée à une famille de client, les requêtes étant des requêtes en lecture de données émises par les façades des clients. Dans le cas où les clients sont regroupés par familles, le point d'entrée 104.1, 104.2 comprend plusieurs piles de requêtes en attente de traitement. Chacune des piles est dédiée à une famille de client. Ceci permet de contingenter les éventuelles saturations de la pile de requêtes. Par exemple, on peut dédier une pile aux requêtes venant de l'OW (les clients de la partie avionique dite « monde ouvert » ou Open World). En cas d'affluence de demandes provenant de l'OW, seule la pile dédiée à l'OW est saturée.

Dès lors, le serveur refuse toutes nouvelles requêtes venant de l'OW mais continue d'empiler les demandes provenant d'équipements avioniques. Ce principe de pile dédiée permet de se protéger par exemple d'application 0W dysfonctionnant en émettant des requêtes en continu. Selon le même schéma, on peut aussi intégrer une pile pour les requêtes d'un client privilégié. Dans le pattern d'architecture où le serveur est colocalisé avec un client privilégié (NavDB et FMS) on peut envisager de protéger les demandes de ce client privilégié grâce à une pile dédiée. Cette option n'a de sens que dans le cas ou le client privilégié et le serveur fonctionnent sur un même calculateur.

Cette option n'est pas envisageable pour le traitement des requêtes d'écriture, car elle ne permet pas de garantir la conservation de l'ordre des requêtes. Le rôle du point d'entrée dans la surveillance de l'ensemble de gestionnaires de requêtes est basé sur : - sur l'horodatage local (et distant) des requêtes, - sur le nombre de prises en compte de chaque requête (pour se protéger du message tueur (« killing message »), - sur le taux de remplissage de la (ou des) pile(s) de requêtes en attente de traitement.

Ces informations sont utilisées pour alimenter des statistiques dans le cadre d'un mécanisme de répartition de charge entre les serveurs (ou Joad-balancing) permettant de déterminer le niveau de disponibilité de chaque serveur.

Le rôle du point d'entrée est de gérer la pile des requêtes en attente de traitement. Il n'a pas en charge l'exécution de la requête à proprement parlé. Ce travail est délégué à des processus dédiés : les gestionnaires de requête. Ces processus effectuent l'opération de lecture ou d'écriture dans la base de données correspondante.

Chaque serveur comprend plusieurs gestionnaires de requête regroupés en un ensemble dénommé ensemble ou « pool » de gestionnaires de requêtes 106.1, 106.2. Chaque gestionnaire de requêtes a pour mission de traiter une requête à la fois. Il vient prélever la première requête en attente de traitement dans la pile 105.1, 105.2 gérée par le point d'entrée 104.1 104.2. Les gestionnaires de requêtes ne doivent pas contenir des données rémanentes au-delà du traitement de chaque requête. Ces gestionnaires de requêtes sont dits sans états (ou « Stateless »). Cette caractéristique permet d'éviter le stockage d'état intermédiaire. En cas d'arrêt d'un gestionnaire de requêtes, celui-ci redémarre immédiatement sans devoir initialiser un état préalable. La requête qui était en cours de traitement lors de l'arrêt d'un gestionnaire de requêtes est reprise par un autre gestionnaire de requêtes. Un gestionnaire de requêtes redémarrant après un arrêt vient prendre en charge la première requête en attente de traitement dans la pile.

L'ensemble de gestionnaires de requêtes contient un minimum de trois instances de processus de traitement afin de pallier au problème du message tueur (« killing message »). En effet, si le traitement d'une requête entraîne l'arrêt de deux gestionnaires de requêtes consécutivement, alors le traitement de cette requête est interrompu afin d'éviter de tuer la totalité des gestionnaires de l'ensemble. Dans le cas où les clients sont regroupés par familles, chaque gestionnaire de requêtes est associé à une priorité afin favoriser une famille de clients. Tout comme pour le point d'entrée, il est possible d'exploiter l'information donnant la famille à laquelle appartient le client à l'origine de la requête.

Par exemple, un gestionnaire de requêtes avec des allocations de ressources supérieures peut être réservé au client local afin de favoriser les temps de réponse pour ces requêtes. Cette option n'a de sens que dans le cas du client privilégié. De même, on peut cantonner les requêtes 0W vers un seul gestionnaire de requêtes avec une allocation de ressource plus faible que la moyenne. Cette option n'est pas envisageable pour le traitement des requêtes d'écriture, car ne permet pas de garantir la conservation de l'ordre des requêtes. La figure 2 représente un exemple de fonctionnement interne 10 d'une façade 103. Le rôle d'une façade est d'offrir un accès aux données hébergées sur les serveurs à une application avionique 102. La connaissance des serveurs à utiliser se trouve côté client. Afin de masquer la localisation des bases de données aux applications avioniques, la façade joue le rôle d'intermédiaire entre le client et l'accès aux serveurs. La façade 15 comprend : une interface 301.1,301.2 d'accès aux données (API) des bases en assurant une certaine compatibilité ascendante des différentes versions d'interface, des moyens 302 pour la localisation du (ou des) serveur(s) hébergeant la 20 donnée demandée par le client, des moyens 303 pour la réception des messages de vie des serveurs pour en connaître la disponibilité, des moyens pour le renvoi d'une requête au serveur de sauvegarde (ou backup) en cas de panne du serveur principal, 25 des moyens 304 pour la gestion des abonnements du client aux changements des données semi-statiques, ces moyens comprenant : - des moyens pour la réception des notifications émises par un éditeur 108.1, 108.2 pour les données semi-statiques. - des moyens pour la souscription d'une application avionique 30 102 à un abonnement à une modification d'une donnée, - des moyens pour filtrer les notifications émises par le serveur de données en fonction des abonnements de l'application avionique 102, et pour avertir l'application avionique 102 d'une modification d'une donnée à laquelle elle est abonnée.

Une façade est conçue de manière modulaire pour s'adapter aux besoins du client auquel elle est destinée. La façade n'embarque que les interfaces 301.1,301.2 requises par le client. En effet, il n'est pas utile de fournir des accès à l'ensemble des bases de données gérées par le dispositif à l'ensemble des clients. Ce principe de modularité de la façade permet de la même manière de fournir plusieurs versions 301.1, 301.2 d'une même interface. En effet, il est nécessaire de pouvoir faire évoluer le dispositif sans imposer la modification d'une application métier cliente. La façade utilise le niveau le plus récent d'échanges en interne avec les serveurs, mais assure la conversion avec la version d'interface utilisée. La façade comprend aussi un gestionnaire 310 de requêtes pendantes. Ce gestionnaire a pour mission essentielle de gérer les requêtes émises à destination des serveurs composant le service de base de données et toujours pendantes (c'est-à-dire : dont la façade n'a pas encore reçu la réponse). Le traitement générique d'une requête comprend les étapes suivantes : le marquage de la requête avec l'heure courante, en cas de demande de lecture, la recherche préalable dans une mémoire cache interne 312 (stockage local à la façade), pour une lecture et si la donnée est disponible dans la mémoire cache 312, la réponse au client, sinon la détermination du serveur gérant la base concernée, la construction d'un message de requête et l'envoi à destination du serveur, la mise dans une file d'attente 312 (« pending queue ») de la requête en cours de traitement, le déclenchement d'un timer de surveillance de cette requête, le traitement de la réponse comprenant des étapes consistant à : o en cas de succès : dépiler la requête en attente et répondre à l'applicatif et mettre éventuellement le cache à jour, o en cas d'échec : appliquer la politique choisie de tolérance aux fautes pour une ré-émission éventuelle o à la fin des tentatives remonter l'erreur définitive à l'application.

La ré-émission de la requête vers un autre serveur en cas d'échec, dépend de plusieurs critères : - La cause de l'échec précédent si un retour a été renvoyé par le serveur. Il est inutile de renvoyer un message « qui tue » détecté au niveau du serveur. La politique de tolérance aux fautes (« fault tolerance ») (un ou plusieurs réplicas), La disponibilité d'un « réplica » selon son état de service. Avantageusement, la façade comprend des moyens 305 pour l'envoi d'une requête au serveur le moins chargé. Les applications émettent des requêtes à destination des serveurs pour accéder aux données. Ces moyens 305 sont utilisés dans le cas d'une mise en oeuvre d'une fonction de répartition de la charge (ou « Joad balancing ») entre les serveurs. Cette caractéristique permet donc d'éviter qu'un serveur soit surchargé par des requêtes alors qu'un autre est pratiquement inutilisé. Ces moyens 305 utilisent par exemple le taux de remplissage de la (ou des) pile(s) de requêtes en attente de traitement des serveurs pour déterminer le serveur le moins chargé. Le dispositif d'accès à des données selon l'invention permet d'informer de la modification d'une donnée semi-statique un ensemble de clients abonnés sans que le serveur hébergeant les données ne connaisse cet ensemble de clients de manière figée et préalable. Cette fonction a pour avantage de réduire le couplage entre le serveur et les clients utilisateurs des données semi-statiques. Ceci permet de construire un système plus flexible.

L'information de la modification d'une donnée semi-statique est une fonction événementielle. Les clients abonnés ne sont prévenus que lors de la survenance d'un changement d'état d'une donnée. Cette fonction comprend un mécanisme de filtrage. En effet, les abonnés ne reçoivent que le sous ensemble d'événements auxquels ils se sont abonnés. Il est du ressort de chaque abonné de traiter ou non les événements reçus. La figure 3 représente un exemple du déroulement d'une mise à jour d'une donnée avec le dispositif selon l'invention. En pratique, une application s'abonne auprès d'une façade. Par exemple, l'application représentée s'abonne aux modifications sur une donnée B. Le serveur publie, sous la forme d'événements, des changements d'état de données auprès du gestionnaire d'événements. La façade informe l'application avionique si celle-ci est abonnée aux modifications de la donnée. Dans l'exemple, lors de la modification d'une donnée A la façade reçoit une notification publiée par le serveur, mais ne la transmet pas à l'application qui n'est pas abonnée pour cette donnée. Mais lors de la modification de la donnée B, la façade reçoit une notification publiée par le serveur et la transmet à l'application qui est abonnée pour cette donnée. Les changements d'états publiés par l'éditeur 108.1,108.2 sont par exemple une modification d'une donnée, une création d'une donnée ou une 10 destruction d'une donnée. Un événement comprend : des références de la donnée permettant de l'identifier, un type d'événement (modification, création, destruction), un horodatage (ou « timestamp ») de l'occurrence de l'événement, des références du serveur ayant effectué la publication.

15 Les moyens la souscription d'une application avionique 102 à un abonnement à une modification d'une donnée permettent différents types d'abonnements par exemple : sur l'ensemble des événements, sur un type d'événement, sur l'ensemble d'une base de données, sur une famille de données (par exemple : Waypoints, Plans de Vol, NOTAMs), sur une donnée 20 particulière. La publication est à la charge du serveur maître hébergeant les données semi-statiques. Il pourra d'ailleurs y avoir plusieurs types de bases de données semi-statiques hébergées ou non sur un même serveur. Après la réussite d'une requête d'écriture, le serveur diffusera sur 25 un canal virtuel AFDX dédié l'information d'une nouvelle valeur de donnée semi-statique à l'ensemble des façades. A charge pour ces façades de déterminer si cette signalisation intéresse l'application cliente en fonction des abonnements réalisés à l'origine. Selon un mode de réalisation préféré de l'invention, les façades 30 103 sont réparties entre au moins un premier et un deuxième groupe. La figure 4 représente le déroulement d'une mise à jour d'une donnée dans ce mode de réalisation préféré de l'invention. Le premier groupe (Façade 1) reçoit directement les notifications de modifications sur les données émises par le serveur. Les façades appartenant au premier groupe comportent en 35 outre des moyens pour émettre lesdites notifications de modifications de données aux façades appartenant au deuxième groupe (Façade 2). Cependant, l'émission des notifications vers les façades du deuxième groupe n'est effectuée qu'après que lesdites notifications ont été traitées et éventuellement transmises aux applications avioniques associées aux clients des façades du premier groupe (appelé traitement local sur la figure). Le principe de la publication est basé sur la diffusion à l'ensemble des façades des événements intervenues sur les données semi-statiques. Ce choix présente le risque d'un message de notification qui ferait tomber l'ensemble des façades. Pour protéger le dispositif d'un message tueur, une solution est de ne plus diffuser les notifications vers toutes les façades, mais seulement à destination d'un sous-groupe de premier niveau. Ce premier groupe aurait pour mission de retransmettre les notifications vers un second groupe et ainsi de suite en cascade. En cas de message tueur, le premier groupe de façade tomberait, mais sans contaminer les groupes suivants.15

Claims (6)

1. REVENDICATIONS1. Dispositif (100) d'accès à des données par des clients (101) à bord d'un aéronef, chacun des clients (101) étant associé une application avionique (102), lesdites données étant stockées sur au moins un serveur de données embarqué à bord de l'aéronef, lesdites données étant accessibles en écritures et pouvant être modifiées, caractérisé en ce que le serveur comporte des moyens (108.1,108.2) pour notifier à l'ensemble des clients des modifications sur les données qu'il stocke, et en ce que chacun des clients (101) comporte une façade (103) 10 permettant l'accès aux données stockées sur le serveur aux applications avioniques (102), ladite façade (103) comprenant : des moyens pour la souscription d'une application avionique (102) à un abonnement à une modification d'une donnée, des moyens pour filtrer les notifications émises par le serveur de données 15 en fonction des abonnements de l'application avionique (102), et pour avertir l'application avionique (102) d'une modification d'une donnée à laquelle elle est abonnée.
2. 2. Dispositif selon la revendication 1, dans lequel les façades 20 (103) sont réparties entre au moins un premier et un deuxième groupe, le premier groupe recevant directement les notifications de modifications sur les données émises par le serveur, les façades (103) appartenant au premier groupe comportant en outre des moyens pour émettre lesdites notifications de modifications de données aux façades (103) appartenant au deuxième 25 groupe, l'émission des notifications vers les façades (103) du deuxième groupe étant effectuée après que lesdites notifications ont été filtrées et transmises aux applications avioniques associées aux clients (101) des façades (103) du premier groupe. 30
3. 3. Dispositif selon l'une des revendications 1 ou 2, dans lequel, les applications émettant des requêtes à destination des serveurs pour accéder aux données, la façade comprend des moyens (305) pour l'envoi d'une requête au serveur le moins chargé.
4. 4. Dispositif selon l'une des revendications précédentes, dans lequel les clients sont regroupés par familles, la famille à laquelle appartient un client étant indiquée à un serveur par la façade dans une requête.
5. 5. Dispositif selon la revendication 4, dans lequel un serveur comprend plusieurs piles de requêtes en attente de traitement, chacune des piles étant dédiée à une famille de client, les requêtes étant des requêtes en lecture de données émises par les façades des clients.
6. 6. Dispositif selon l'une des revendications précédentes, dans lequel, le dispositif comportant une pluralité de serveur, la façade comprend des moyens (305) pour l'envoi d'une requête au serveur le moins chargé en requêtes.