FR3030805A1 - Qualite de service d'un systeme de gestion de vol - Google Patents

Abstract

Il est divulgué un procédé mis en oeuvre par ordinateur dans ou pour un système de gestion de vol ou FMS, comprenant les étapes consistant à recevoir des requêtes émises par des clients; déterminer une correspondance entre les requêtes et des services unitaires prédéfinis exécutables par au moins un serveur associé audit FMS; enfiler les services unitaires déterminés dans une ou plusieurs files d'attente; déterminer un temps de réponse associé à chaque requête; et notifier au moins un client du temps de réponse à sa requête. Des développements décrivent le traitement de files d'attente, la gestion de priorités, l'existence de forfaits, des mécanismes de mises en cache, des interruptions de files d'attente, des annulations de requêtes, des mécanismes de vote, etc. Les services unitaires en particulier peuvent être des services avioniques de type ATA (acronyme de «Air Transport Association»). Des aspects de systèmes et de logiciels sont décrits. 150 mots

Description

QUALITE DE SERVICE D'UN SYSTEME DE GESTION DE VOL Domaine de l'invention L'invention concerne de manière générale des procédés et des systèmes pour la gestion du vol d'un aéronef, notamment en matière de détermination ou de prédiction de trajectoires. L'invention concerne en particulier les systèmes embarqués dans les systèmes avioniques.

Etat de la Technique Chaque système avionique temps réel est architecturé et développé pour répondre, dans un cadre d'emploi défini, à des exigences de performances (par exemple en matière de RAM, de ROM, de taux de panne ou reset, de charge CPU et de Qualité de Service ou QoS fonctionnelle. Les systèmes embarqués sont qualifiés, avec un niveau de performance démontré, pour un environnement donné. Les interactions entre systèmes embarqués sont définies a priori lors de l'élaboration de l'architecture de l'avion, et ces systèmes embarqués sont développés et ajustés pour répondre strictement aux besoins identifiés. En se plaçant dans une perspective client-serveur, selon laquelle un ensemble de systèmes dits «CLIENTS» effectuent des requêtes vers un ou des systèmes particuliers fournisseurs de services dit «SERVER», il se pose notamment le problème technique consistant à garantir auxdits clients un certain niveau de qualité de service, par exemple en matière de précision et de temps de réponse tels qu'attendus par les clients attendent, et de garantir le bon fonctionnement de l'ensemble de l'architecture «N clients et M serveurs» au fur et à mesure des mises à jours des différents systèmes (i.e. en gérant une variabilité et des cycles de développement différents). Les évolutions d'un système (client ou serveur) ne doivent pas donner lieu à une remise en cause de l'ensemble des systèmes connectés. De plus, dans un environnement temps réel embarqué, dans lequel les sous-systèmes ont un niveau de criticité différent, il est souhaitable de modifier le moins possible les systèmes critiques officiant comme serveurs, compte tenu des coûts et des risques de dégradation desdits systèmes. Ces problèmes techniques ne sont actuellement pas résolus et une requalification est obligatoire pour l'ajout de tout nouveau système qui veut se connecter à un système existant. Une nouvelle certification ou recertification de l'avion est généralement requise, engendrant des surcoûts substantiels. De fait, ces aspects systémiques (impliquant des reprises de l'architecture des serveurs et de leurs interfaces et donc des coûts de requalification) brident actuellement l'évolution des opérations avion. Dans la pratique par exemple, si un client a besoin d'une Qualité de Service (QoS) d'un certain niveau (comme par exemple un temps de réponse limite attendu), et que le serveur a besoin de plus de temps pour effectuer son calcul, la conséquence qui s'ensuit est que le client devra attendre. Dans certaines configurations alternatives, le serveur peut décider d'annuler la requête du client si le temps de calcul nécessaire est supérieur au temps de réponse demandé par le client. Ce type de configuration n'est toutefois pas acceptable dans certaines situations, notamment dans le cas de systèmes temps réels embarqués qui nécessitent une réponse dans les temps impartis pour assurer leur bon fonctionnement. Par exemple, notamment dans le cadre d'architectures «ouvertes» où un nombre a priori inconnu de client se connecte de manière asynchrone et aléatoire à un serveur aux capacités de calcul limitées, les solutions existantes vont dans le meilleur des cas rejeter de trop nombreuses requêtes, ou dans le pire des cas répondre trop souvent et/ou trop tardivement, mettant en péril l'architecture globale du système. Les approches connues dans l'État de la technique consistent généralement à requalifier les équipements touchés ou impactés par une 5 nouvelle connexion (même à fonctionnalités constantes), afin de vérifier la tenue en matière de performances. Les architectures avioniques sont donc définies statiquement, lors de la conception du système avion. La littérature brevet ne fournit pas de solution satisfaisante au problème technique. Par exemple, le document de brevet US8832302 intitulé 10 "System and method for a priori scheduling of network services" décrit un système pour des réseaux ad hoc comprenant des mécanismes de reconnaissance de services. Cette approche structurée par services et non pas par données présente des limitations. Il existe un besoin industriel de procédés et de systèmes correspondants 15 à des architectures flexibles et adaptables permettant notamment d'assurer l'évolutivité des différents systèmes clients et serveurs de manière indépendante, tout en garantissant aux clients un niveau de qualité de service qui soit garanti. Résumé de l'invention 20 II est divulgué un procédé mis en oeuvre par ordinateur dans (e.g. «intégré à») et/ou pour («associé à») un système de gestion de vol ou FMS, comprenant les étapes consistant à recevoir des requêtes émises par des clients; déterminer une correspondance entre les requêtes et des services unitaires prédéfinis exécutables par au moins un serveur associé 25 audit FMS; enfiler les services unitaires déterminés dans une ou plusieurs files d'attente; déterminer un temps de réponse associé à chaque requête; et notifier au moins un client du temps de réponse à sa requête. Des développements décrivent le traitement de files d'attente, la gestion de priorités, l'existence de forfaits, des mécanismes de mises en cache, des interruptions de files d'attente, des annulations de requêtes, des mécanismes de vote, etc. Les services unitaires en particulier peuvent être des services avioniques de type ATA (acronyme de «Air Transport Association»). Des aspects de systèmes et de logiciels sont décrits.

Selon un aspect du procédé selon l'invention, le fournisseur de services est segmenté ou séparé ou délimité en trois sous parties: a) le coeur numérique de calcul appelé «CORE», qui offre des services unitaires de calcul ; b) un «SEP SERVER» pour «Separated Server» comprenant un «SERVER CORE» qui est une couche de transcription des requêtes des CLIENTS en services unitaires du coeur et c) un «SERVER FRONT END» qui est une couche de dialogue avec les «CLIENTS», gérant notamment les requêtes des différents clients (logique d'acceptation, priorité, filtrage ...).

Selon un aspect de l'invention, le serveur (le «SERVER FRONT END») va permettre de découpler les aspects de gestion de la QoS pour des «CLIENTS» dans un environnement évolutif tout en s'appuyant sur un coeur «CORE» stable qui supporte de base la capacité de gérer un nombre quelconque de clients (limité uniquement par les ressources disponibles) tout en continuant à remplir sa mission de base en tenant les exigences de performances associées. De cette manière, les problèmes de variabilité des CLIENTS sont isolés de ceux concernant le CORE. La robustesse du CORE reste garantie puisque le code de gestion des clients, et de la variabilité des interfaces est géré par les «SERVER FRONT END» et «SERVER CORE». Dans certains modes de réalisation, le système «SEP SERVER» adaptatif mentionné précédemment est configurable au démarrage («at start time» en anglais) voire lors de l'exécution («at runtime» en anglais, i.e. configuration dynamique lors de l'exécution). Par exemples, au démarrage, le système lit une table de configuration qui décrit la topologie des clients présents et la liste des services «CORE» disponibles, avec leurs caractéristiques. Le «SEP SERVER» système s'auto-configure alors pour réserver les ressources nécessaires. Selon un aspect de l'invention, un mode de réalisation du procédé crée 5 un «SEP SERVER» isolé du «CORE», et configure ce ((SEP SERVER» en établissant i) les caractéristiques en termes de qualité de service unitaire des services offerts par le «CORE» ; ii) la correspondance entre les requêtes des «CLIENTS» et les services unitaires du ou des «CORE» aptes à les exécuter ; iii) la correspondance entre les résultats des 10 services unitaires du «CORE» et les résultats attendus par le client ; iv) l'ordonnancement des requêtes des différents «CLIENTS» sur le ou les «CORE» aptes à les traiter. Avantageusement, un mode de réalisation du procédé selon l'invention permet de découpler les évolutions des fournisseurs de services «CORE» 15 et des clients «CLIENTS», ce qui assure la compatibilité ascendante et la maîtrise de la requalification de l'ensemble des systèmes. Avantageusement, un mode de réalisation du procédé selon l'invention permet de conserver les performances intrinsèques du «CORE» sans devoir connaître a priori les clients extérieurs, tout en garantissant aux 20 clients en question un résultat de calcul avec la qualité de service requise. Avantageusement, un mode de réalisation du procédé selon l'invention permet de Page : 5 mettre en place des mécanismes de mutualisation et/ou de caches fonctionnels sur historisation et d'optimisation des appels aux services 25 core. Cet aspect permet notamment de gérer l'obsolescence des données du cache à déterminer versus le temps de recalcul des données. La notion de cache est d'autant plus pertinente qu'il s'agit de consulter des grosses données ou sous-ensemble de grosses données (par exemple FPLN actif et sa trajectoire associée pour un Flight Management System ou FMS ou système de gestion de vol) Avantageusement, un mode de réalisation du procédé selon l'invention, via la création d'un système «intermédiaire», permet d'ajuster au mieux la distribution des requêtes des clients aux fournisseurs de services «CORE», par exemple en fonction de la configuration chargée (e.g. nombre, type et performances des services). Avantageusement, un mode de réalisation du procédé selon l'invention permet de minimiser le taux de refus de requêtes clients.

Avantageusement, un mode de réalisation du procédé selon l'invention permet de maîtriser l'allocation du temps de calcul à des clients tiers de manière garantie. Avantageusement, un mode de réalisation du procédé selon l'invention permet de pouvoir toujours (ou pratiquement toujours) donner une réponse préalable fiable d'acceptation et/ou de refus de prise en charge de la requête, accompagnée optionnellement d'une notification de statut sur la Qualité de service (e.g. temps de réponse, précision, fiabilité) qui découlera du calcul. Dans une variante de réalisation, un serveur FRONTAL peut être implémenté sur un des coeurs, tandis que les autres coeurs ont une partition équivalente qui héberge une ressource de calcul (par exemple serveur FRONTAL sur FMC1 et NAVDB SERVER sur FMC2). Selon une autre variante, il est également possible de mettre en oeuvre un seul FRONTAL; le serveur frontal pouvant interrompre le calcul d'un client pour en faire passer un autre (e.g. mécanisme de pause/reprise ou «Pause/Resume» en anglais), afin de gérer les priorités (par exemple vis à vis des deadlines). Avantageusement, selon certaines mises en oeuvre de l'invention, le cache fonctionnel peut permettre de «lisser» la charge des coeurs CORE; il peut s'agir de prédictif (facultativement) mais aussi de cache fonctionnel sur historisation. L'isolation dans une ou plusieurs partitions différentes permet de faire évoluer ces processus de mise en cache pour les rendre de plus en plus «intelligents» (confer des mécanismes de remplissage automatique ou «auto-completions»).

Avantageusement, les procédés selon l'invention sont généralement compatibles avec la notion d'AID (pour «Agent d'Interaction Domaine»). En lieu et place de clients disséminés qui s'adressent directement au système «serveur», une interface peut concentrer les demandes et effectuer les requêtes aux services proposés par le «serveur».

Le procédé selon l'invention détermine ou délimite ou crée ou spécifie ou définit un «SEP SERVER», lequel est un modulé séparé fonctionnellement du «CORE». Pour chaque service, il est déterminé une fonction de «temps de calcul» du service. Lorsque ledit service est sollicité par un client pour effectuer un calcul, le procédé détermine le temps de calcul CPU nécessaire «sans ajustement» et le compare à un objectif de temps de réponse. Un objectif de temps de calcul est déterminé de façon à pouvoir répondre aux clients un temps de réponse donné (le serveur pouvant être appelé par de multiples clients, et pouvant effectuer lui aussi ses propres calculs). Ledit objectif de temps de réponse peut être déterminé par le client et/ou être déterminé par le serveur. Dans certaines variantes, le client a la capacité de confirmer ou d'annuler sa requête. De manière facultative, un mode de réalisation du procédé selon l'invention peut gérer l'historique des commandes ou requêtes récurrentes (i.e. mise en cache fonctionnelle).

Avantageusement, un mode de réalisation du procédé selon l'invention permet de découpler les évolutions des fournisseurs de services «CORE» et des clients «CLIENTS», ce qui assure la compatibilité ascendante et la maîtrise de la requalification de l'ensemble des systèmes. Les problèmes de variabilité des CLIENTS sont donc isolés de ceux concernant le CORE. Les clients n'ont pas besoin de connaître l'architecture système globale, la liste des coeurs disponibles ou la liste des services unitaires et leur ordonnancement pour réaliser une requête. Tout est pris en charge par la couche intermédiaire «SEP SERVER». Avantageusement, un mode de réalisation du procédé selon l'invention permet de gérer la variabilité du «système de systèmes». Par exemple concernant la gestion des clients: les priorités étant gérées par le «SERVER FRONT END», des algorithmes différents peuvent être implémentés selon les besoins des clients. Avantageusement, un mode de réalisation du procédé selon l'invention permet de conserver les performances intrinsèques du «CORE» sans devoir connaître a priori les clients extérieurs, tout en garantissant aux clients en question un résultat de calcul avec la qualité de service requise. Par l'expression «performances intrinsèques» il est entendu ou désigné les performances en matière de CPU et de RAM/ROM ainsi qu'en matière de fiabilité (qu'un système donné doit remplir dans le cadre d'une architecture posée a priori pour répondre aux exigences de sécurité et assurer une opération globale). Cette architecture étant définie a priori (i.e. avec des services identifiés et/ou des échanges de données identifiés), il devient possible d'ajouter de nouvelles interactions sans avoir à modifier ces services et données. La robustesse du «CORE» reste garantie puisque les algorithmes - parfois complexes de gestion des clients et des correspondances d'interfaces - sont gérés en dehors du «CORE», i.e. par le «SEP SERVER». Avantageusement, l'invention est applicable à toute architecture de systèmes temps réels embarqués (aéronautique, automobile, médical ...) faisant intervenir une pluralité de clients, une ou plusieurs applications logicielles (par exemple de gestion de vol) et une pluralité d'unités fournissant des services (par exemple des «coeurs» numériques).

Avantageusement, le système distribué selon l'invention permet l'ajout de nouvelles connexions (i.e. de nouveaux «CLIENTS») au système temps réel fournisseur de services appelé «SERVER», en leur garantissant une qualité de service correspondant aux attentes du système client. 5 Généralement un bon fonctionnement du système global est permis, lequel ne dégrade pas ses performances et ne donne pas lieu à modifications logicielles ou matérielles dudit «SERVER». L'ajout d'un nouveau client, d'un nouveau fournisseur de services, ou d'une nouvelle connexion ou d'un client, ne donne alors lieu qu'à une requalification des 10 autres clients/serveurs. La performance du système de systèmes est maintenue conforme aux exigences initiales. Description des figures Différents aspects et avantages de l'invention vont apparaitre en appui de 15 la description d'un mode préféré d'implémentation de l'invention mais non limitatif, avec référence aux figures ci-dessous : La figure 1 illustre l'environnement technique global de l'invention; La figure 2 illustre schématiquement la structure et les fonctions d'un système de gestion de vol de type FMS connu; 20 La figure 3 illustre la structuration d'un système de systèmes selon la norme ATA; La figure 4 illustre un exemple d'architecture ATA; La figure 5 montre un exemple d'architecture selon un mode de réalisation du procédé selon l'invention; 25 La figure 6 illustre des exemples d'étapes du procédé selon l'invention; La figure 7 illustre schématiquement la structure et les fonctions d'un système de gestion de vol de type FMS; La figure 8 illustre des exemples de variantes de réalisation de l'invention.

Description détaillée de l'invention Certains termes et environnements techniques sont définis ci-après. Le pilote d'un aéronef ou avion utilise les informations de plan de vol dans plusieurs contextes: au sein des équipements avioniques au moyen du FMS (Flight Management System) et/ou au moyen d'un "EFB" (Electronic 10 Flight Bag), par exemple de type tablette. L'acronyme ou sigle EFB correspond à la terminologie anglaise "Electronic Flight Bag" et désigne des librairies électroniques embarquées. Généralement traduit par "sac de vol électronique" ou "sacoche de vol électronique" ou "tablette de vol électronique", un EFB 15 est un appareil électronique portable et utilisé par le personnel navigant (par exemple pilotes, maintenance, cabine..). Différentes classes de matériel EFB existent. Les EFB de classe 1 sont des appareils électroniques portatifs (PED), qui ne sont normalement pas utilisés durant le décollage et les opérations de débarquement. Cette classe d'appareil 20 ne nécessite pas un processus administratif de certification ou d'autorisation particulière. Les appareils EFB de classe 2 sont normalement disposés dans le cockpit, e.g. montés dans une position où ils sont utilisés durant toutes les phases de vol. Cette classe d'appareils nécessite une autorisation d'utilisation préalable. Les appareils de classe 25 1 et 2 sont considérés comme des appareils électroniques portatifs. Des installations fixes de classe 3, telles que des supports informatiques ou des stations d'accueil fixes installées dans le cockpit des aéronefs exigent généralement l'approbation et une certification de la part du régulateur. 3030 805 11 L'acronyme ou sigle FMS correspond à la terminologie anglaise "Flight Management System" et désigne les systèmes de gestion de vol des aéronefs. Lors de la préparation d'un vol ou lors d'un déroutement, l'équipage procède à la saisie de différentes informations relatives au 5 déroulement du vol, typiquement en utilisant un dispositif de gestion de vol d'un aéronef FMS. Un FMS comprend des moyens de saisie et des moyens d'affichage, ainsi que des moyens de calcul. Un opérateur, par exemple le pilote ou le copilote, peut saisir via les moyens de saisie des informations telles que des RTA, ou "waypoints ", associés à des points de cheminement, c'est-à-dire des points à la verticale desquels l'aéronef doit passer. Les moyens de calcul permettent notamment de calculer, à partir du plan de vol comprenant la liste des waypoints, la trajectoire de l'aéronef, en fonction de la géométrie entre les waypoints et/ou des conditions d'altitude et de vitesse.

L'acronyme IHM correspond à Interface Homme-Machine (HMI en anglais, Human Machine Interface). La saisie des informations, et l'affichage des informations saisies ou calculées par les moyens d'affichage, constituent une telle interface homme-machine. De manière générale, les moyens IHM permettent la saisie et la consultation des informations de plan de vol, des données de pilotage, etc. La figure 1 illustre l'environnement technique global de l'invention. Des équipements avioniques ou des moyens aéroportuaires 100 (par exemple une tour de contrôle en lien avec les systèmes de contrôle aérien) sont en communication avec un aéronef 110. Un aéronef est un moyen de transport capable d'évoluer au sein de l'atmosphère terrestre. Par exemple, un aéronef peut être un avion ou un hélicoptère (ou bien encore un drone). L'aéronef comprend une cabine de pilotage ou un cockpit 120. Au sein du cockpit se trouvent des équipements de pilotage 121 (dits équipements avioniques), comprenant par exemple un ou plusieurs calculateurs de bord (moyens de calcul, de mémorisation et de stockage de données), dont un FMS, des moyens d'affichage ou de visualisation et de saisie de données, des moyens de communication, ainsi que (éventuellement) des moyens de retours haptiques. Un EFB 122 peut se trouver à bord, de manière portative ou intégrée dans le cockpit. Ledit EFB peut interagir (communication bilatérale 123) avec les équipements avioniques 121. L'EFB peut également être en communication 124 avec des ressources informatiques externes, accessible par le réseau (par exemple informatique en nuage ou "Cloud computing" 125. En particulier, les calculs peuvent s'effectuer localement sur l'EFB ou de manière partielle ou totale dans les moyens de calculs accessibles par le réseau. Les équipements de bord 121 sont généralement certifiés et régulés tandis que l'EFB 122 et les moyens informatiques connectés 125 ne le sont généralement pas (ou dans une moindre mesure). Cette architecture permet d'injecter de la flexibilité du côté de l'EFB 122 en s'assurant d'une sécurité contrôlée du côté de l'avionique embarquée 121. La figure 2 représente un FMS disposant de fonctions décrites dans la norme ARINC. De manière générique, un FMS désigne tout système ou ensemble de systèmes permettant de gérer la route/trajectoire d'un avion/aéronef (indépendamment des variantes d'implémentation physique). Un système de gestion de vol au sens de l'invention FMS peut correspondre à différentes implémentations matérielles et/ou logicielles. Dans l'état de la technique connu, un FMS désigne actuellement un calculateur précis, dont le périmètre est illustré à la figure 2. Cependant, d'autres architectures sont tout à fait possibles: un FMS peut correspondre à un seul serveur ou bien à une pluralité de serveurs (travaillant de manière centralisée et/ou de manière distribuée). L'expression «au moins un serveur associé au FMS» désigne donc de manière générale l'accès aux ressources hardware et/ou software de l'entité permettant d'assurer les fonctions présentement décrites.

Un système de type FMS 200 est généralement disposé dans le cockpit 120. Le FMS est associé à des moyens avioniques 121 et à une ou plusieurs interfaces homme-machine 220 comprenant des moyens de saisie, par exemple formés par un clavier, et des moyens d'affichage, par exemple formés par un écran d'affichage, ou bien simplement un écran d'affichage tactile. Un FMS comprend généralement fonctions suivantes: - Navigation (LOCNAV) 201, pour effectuer la localisation optimale de l'aéronef en fonction des moyens de géolocalisation 230 tels que le géo- positionnement par satellite ou GPS, GALILEO, les balises de radionavigation VHF, les centrales inertielles. Ce module communique avec les dispositifs de géolocalisation précités ; - Plan de vol (FPLN) 202, pour saisir les éléments géographiques constituant le "squelette" de la route à suivre, tels que les points imposés par les procédures de départ et d'arrivée, les points de cheminement, les couloirs aériens, communément désignés "airways" selon la terminologie anglaise. - Base de données de navigation (NAVDB) 203, pour construire des routes géographiques et des procédures à partir de données incluses 20 dans les bases relatives aux points, balises, legs d'interception ou d'altitude, etc; - Base de données de performance, (PERFDB) 204, contenant les paramètres aérodynamiques et moteurs de l'appareil ; - Trajectoire latérale (TRAJ) 205, pour construire une trajectoire continue 25 à partir des points du plan de vol, respectant les performances de l'aéronef et les contraintes de confinement (RNP) ; - Prédictions (PRED) 206, pour construire un profil vertical optimisé sur la trajectoire latérale et verticale et donnant les estimations de distance, heure, altitude, vitesse, carburant et vent notamment sur chaque point, à chaque changement de paramètre de pilotage et à destination, qui seront affichées à l'équipage. Les procédés et des systèmes décrits affectent ou concernent principalement cette partie du calculateur. - Guidage (GUID) 207, pour guider dans les plans latéraux et verticaux l'aéronef sur sa trajectoire tridimensionnelle, tout en optimisant sa vitesse, à l'aide des informations calculées par la fonction Prédictions 206. Dans un aéronef équipé d'un dispositif de pilotage automatique 210, ce dernier peut échanger des informations avec le module de guidage 207; - Liaison de données numériques (DATALINK) 208 pour échanger des informations de vol entre les fonctions Plan de vol/Prédictions et les centres de contrôle ou les autres aéronefs 209. - un ou plusieurs écrans, notamment les écrans dits FMD, ND et VD. A partir du plan de vol défini par le pilote (liste de points de passage appelés «waypoints»), la trajectoire latérale est calculée en fonction de la géométrie entre les points de passage (appelés couramment LEG) et/ou les conditions d'altitude et de vitesse (qui sont utilisées pour le calcul du rayon de virage). Sur cette trajectoire latérale, le système de gestion de vol FMS optimise une trajectoire verticale (en altitude et vitesse), passant par des contraintes éventuelles d'altitude, de vitesse, de temps. La figure 3 illustre la structuration d'un système de systèmes selon la norme ATA (acronyme de «Air Transport Association»), selon les pratiques des avionneurs. Chaque système avionique temps réel est architecturé et développé pour répondre à des exigences de performances (en matière de RAM, ROM, taux de panne, CPU et QoS fonctionnelle) déterminées dans un cadre d'emploi défini. Dans cette architecture, chaque système est connecté à d'autres systèmes. Chaque système consomme des données et services mis à disposition par ces autres systèmes et produit des données et services pour les autres systèmes. Ces interactions systémiques sont généralement définies de manière statique lors de l'élaboration de l'architecture globale du «système de systèmes», i.e. lors de l'allocation des fonctions opérationnelles aux différents systèmes physiques composant le système global. Ainsi, il est fréquent dans le monde avionique d'avoir plusieurs dizaines de systèmes répondant à l'ensemble des fonctions avion. Typiquement, des opérations avion sont allouées aux systèmes selon une structuration logique, définie dans le document normatif de l'»Air Transport Association» (ATA). Le système ATA 300 comprend des chapitres 310 qui permettent de regrouper les systèmes aéronautiques dans des rubriques. La figure 3 fournie des exemples de tels chapitres 310 ainsi que leur dénomination en anglais 320 et en français 330. Les différentes dénominations sont communes pour les différents acteurs de l'aéronautique tels que l'ingénierie, la maintenance et l'entretien, les pilotes ainsi que pour les manuels de vol (et ce généralement pour tous les avionneurs). Ainsi, l'architecture avion se décline en systèmes avioniques collaboratifs, chacun ayant une fonction bien déterminée, et des interactions avec les autres systèmes pour rendre le service opérationnel attendu. Ces fonctions sont réparties sur plusieurs calculateurs physiques, selon les choix spécifiques des différents avionneurs, afin de garantir les performances. Les systèmes embarqués sont qualifiés, avec un niveau de performance démontré, pour un environnement donné. La garantie du fonctionnement global du «système de systèmes découle en général d'un analyse dite «worst case» (les systèmes sont chargés au maximum et le fonctionnement de l'opération est vérifié vis à vis d'exigences opérationnelles). Des techniques statistiques peuvent également être utilisées. Dans ces techniques, des analyses de type «boîte noire» peuvent être conduites concernant par exemple l'effet des temps de réponses de chaque système sur la performance opérationnelle globale, en visant une probabilité d'échec inférieure à un ou plusieurs seuils prédéfinis. En matière aéronautique sont par exemple visées des seuils d'occurrence d'une opération ayant des conséquences catastrophiques (i.e. avec pertes de vies humaines) à 10^-9 par heure de vol. Ces techniques probabilistes permettent d'affecter à chaque système des exigences en matière de temps de réponse et de probabilité de tenue de ces exigences, afin de ne pas dépasser la probabilité seuil de 10^-9.

La figure 4 illustre un exemple d'architecture ATA. Différents ATA sont répartis sur des systèmes physiques (calculateurs), par exemple 411, 412 et 413. Les interactions entre systèmes sont définies a priori lors de l'élaboration de l'architecture générale, et les systèmes sont développés et ajustés pour répondre au strict besoin des interactions, i.e. les clients d'un système sont bien identifiés, les industriels développent les fonctions allouées à leur système, lesquelles sont conformes aux performances attendues dans le cadre d'emploi strict défini a priori : en d'autres termes, tous les clients sont connus et aucun nouveau client ne peut interagir avec le système sans requalification de l'ensemble. Dans ce cadre systémique, la probabilité de non-tenue des performances de chaque système est spécifiée, afin de garantir que la probabilité de non-tenue de la performance globale reste en deçà d'un seuil de sécurité prédéfini. Les boîtes de type 400 sont des concentrateurs réseaux (appelés «switchs» dans la version dite ARINC653 du réseau avion). Tous les calculateurs (par exemple 411 et 412) sont connectés à un «switch» (e.g. généralement avec de la redondance des raisons de disponibilité) et dialoguent avec les autres calculateurs sur le réseau (par exemple 413). Un problème technique qui se pose réside dans le fait que l'ajout d'un nouveau système à un «système de systèmes» donné peut engendrer une requalification coûteuse (il est nécessaire de démontrer à nouveau la tenue de la performance opérationnelle globale et de réallouer les performances des systèmes «serveurs»), et ce, même lorsqu'aucun nouveau service n'est attendu par le système «serveur».

La figure 5 montre un exemple d'architecture selon un mode de réalisation du procédé selon l'invention. Dans l'exemple qui est illustré le fournisseur de services «SERVER» scindé en deux : a) un «SEP SERVER» 510 intermédiaire entre les systèmes clients appelés «CLIENTS» (501, 502, 503) et un ou plusieurs systèmes ou coeurs de calcul de services unitaires appelé(s) «CORE» (522,524). Les coeurs de calcul de services unitaires visent à garantir les performances intrinsèques du «CORE» (i.e. à faire en sorte de préserver la mission du «CORE» hors des «CLIENTS»), tout en accordant aux clients des ressources de calcul avec une qualité de service garantie et en garantissant également l'indépendance des cycles de développement entre les «CLIENTS» et le «CORE». Le système «SEP SERVER» 510 est un système adaptatif, selon différents schémas. Il peut être configurable «at design time» at «start time» et/ou «at runtime». L'expression «at design time» signifie que le nombre de clients, les temps ainsi que les services associés sont déterminés au moment de la conception. Cette approche présente des limitations en termes de possibilités de maintenance et d'évolutivité. L'expression «at start time» signifie qu'au démarrage le système lit une table de configuration, par exemple «SERVER BDD» qui décrit la topologie de clients présents, et lit la liste des services «CORE» disponibles (avec leurs caractéristiques). L'expression «at runtime» signifie que le procédé comporte en outre une ou plusieurs étapes visant à satisfaire un ou plusieurs clients et/ou les mécanismes d'adaptation associés (par exemple en temps réel).

Dans une variante de réalisation, afin de garantir les performances intrinsèques du système «CORE», il peut être défini un «Domaine d'usage» dans lequel la configuration peut être autorisée. De manière générale, le «SEP SERVER» est un système qui s'auto5 configure afin de réserver les ressources nécessaires. Dans des modes de réalisation particuliers, la configuration du «SEP SERVER» peut résulter d'actions externes. Selon un aspect de l'invention, un ((SEP SERVER» est isolé du «CORE» et ce «SEP SERVER» est configuré en établissant notamment l'une et/ou 10 l'autre des analyses suivantes : i) les caractéristiques en termes de qualité de service unitaire des services offerts par le «CORE», ii) la correspondance entre les requêtes des «CLIENTS» et les services unitaires du ou des «CORE» aptes à les exécuter ; iii) la correspondance entre les résultats des services unitaires du «CORE» et les résultats 15 attendus par le client ; iv) l'ordonnancement des requêtes des différents «CLIENTS» sur le ou les «CORE» aptes à les traiter ; y) la gestion d'un cache fonctionnel pour conserver les résultats estimés comme potentiellement réutilisables sur une longue durée. Dans une variante de réalisation (optionnelle), le «SEP SERVER» 510 20 comporte deux éléments séparés: 1) un «SERVER FRONT END» 513 (qui peut également être appelé «FRONTAL») ; ce serveur gère les flux entrants de requêtes des clients (priorité, filtrage, faisabilité du calcul dans la QoS souhaitée) et sollicite le «SERVER CORE» ou le «CORE» et 2) un «SERVER CORE» 514 (qui peut également être appelé 25 «WRAPPER»); ce serveur, dans le cas de requêtes complexes, transforme les requêtes en «batchs» de services IDD (521 pour le CORE 1 522) du «CORE» et commande l'exécution desdits services IDD sur le «CORE». L'avantage de cette variante de réalisation réside dans le fait d'isoler la variabilité entre la technologie de «priorisation» des clients (qui peuvent faire appel à des logiques et algorithmes complexes) et la partie «gestion des interfaces». Dans les situations où les clients utilisent directement la liste des services du «CORE», ce «SERVER CORE» n'est pas nécessaire.

Dans l'exemple de la figure 5, un client 1 501 formule une requête 5011 laquelle est reçue par le serveur FRONTAL 513 puis transmise au SERVER CORE 514 (après vérification de son éligibilité par exemple via une base de données 515, laquelle consolide des données comprenant par exemple : le temps CPU des services unitaires (incluant le Server), une matrice ou tableaux requête / batch de services, une matrice de formatage des données service, une liste des ressources d'exécution (e.g. par requête, avec précédence, indépendance, parallélisation, etc), une ou plusieurs priorités clients, etc). Le SERVER CORE 514 adresse ensuite de manière appropriée un ou plusieurs services IDD (par exemple le «service 1» 5211 lequel sollicite le CORE 1 522 par exemple via un accès à la liste des services unitaires IDD 521). En sortie, la réponse du Service 1 5221 est retournée au SEP SERVER (tout d'abord les réponses CORE 512 puis les réponses du FRONTAL 511) et enfin la réponse 1 est retournée au client 1 501.

La figure 6 illustre des exemples d'étapes du procédé selon l'invention. Dans une première étape 610, les coeurs (CORE) sont configurés. De manière générale, cette étape consiste à structurer l'élément «SERVER BDD» 515. La configuration peut être faite de manière préalable ou «Offline» par un opérateur (par exemple selon la configuration coeurs CORE et Clients, tels que connue de l'architecture globale du système). Dans variantes de réalisation «Plug and play», le «SEP SERVER» peut lire au démarrage, par exemple sur le réseau du système embarqué, la liste des coeurs «CORE» et leurs caractéristiques en terme de qualité de service (QoS), afin de structurer en temps réel le fichier de configuration du «SERVER BDD». Dans une première sous étape 6.1, le procédé peut créer une première table «T_CORE» contenant la liste des coeurs numériques «CORE» «Ki» (i = 1 .. nb_core) fournisseurs de services. Dans un mode de réalisation particulier, nb_core peut être égal à la valeur 1. Dans d'autres modes de réalisation la variable nb_core est strictement supérieure à la valeur 1. Dans une seconde sous-étape, pour chaque «CORE» Ki, le procédé peut créer une deuxième table «T_Ki_Services» contenant la liste des services unitaires «S(Ki, j) offerts par le coeur Ki, j = 1 .. nb_services(Ki). Dans une variante de réalisation, une matrice peut être déterminée, laquelle matrice comporte les coeurs Ki selon une dimension et les services S selon une autre dimension. D'autre formalisation mathématique sont possibles.

Dans une troisième sous étape, pour chaque service S(Ki,j), le procédé crée une table QoS «Qualité de service» T_Qos_S(Ki,j), dudit service unitaire S(Ki,j), fonction des capacités du coeur Ki. Par exemple, ladite table peut contenir les caractéristiques CPU du coeur tel que le temps disponible par MIE pour le service S(ki,j). De manière optionnelle, la table QoS peut comprendre les caractéristiques Mémoire RAM/ROM du coeur pour le service S(ki,j). De manière optionnelle, la table QoS peut comprendre les caractéristiques en matière de précision de calcul pour le service S(ki,j) (comprenant par exemple le nombre d'itérations pour les calculs itératifs, le pas d'intégration pour les intégrations numériques, les seuils pour les calculs à tolérances, la qualité des librairies mathématiques de base, la précision des flottants utilisés, etc). Ces caractéristiques peuvent être figées (statiques) ou paramétrables (la QoS est alors variable). De manière optionnelle, la table QoS peut comprendre des caractéristiques relatives à la fiabilité du calcul (comme par exemple le niveau de développement du calculateur hébergeant le «CORE»). Pour des systèmes temps réel embarqués, cette fiabilité peut par exemple se matérialiser sous l'acronyme «DAL» défini par la norme RTCA D01 78B, qui permet de connaître la probabilité de défaillance d'une chaîne de calcul (ex : niveau C = 10A-5 / heure, niveau = 10^-7, niveau B = etc). La fiabilité peut s'exprimer comme la probabilité de calcul erroné pour chaque service S(Ki,j). Par ailleurs, les services des «CORE» accessibles aux clients étant qualifiés puisqu'ils font généralement partie du code embarqué, la Qualité de service peut être définie a priori notamment pour les aspects de précision et de fiabilité des calculs (profondeur des intégrations, ...), pour les aspects associés aux temps de réponse et pour les aspects associés à la mémoire disponible pour le client (nombre d'éléments calculés). Dans une deuxième étape 620, les requêtes des «CLIENTS» sont configurées. Dans une première sous étape, le procédé crée une table des requêtes clients «T_requêtes» qui factorise les requêtes R(k) (k= 1, nb_requêtes) des différents clients C(m) (m = 1 .. nb_clients). Cette étape peut être réalisée de manière préalable offline, par un opérateur, par exemple après analyse des différentes requêtes demandées par les clients. Dans une alternative «Plug and play» le «SEP SERVER» peut lire au démarrage, sur le réseau du système embarqué, la liste des clients «CLIENTS» et leurs caractéristiques en terme de requêtes afin de structurer en temps réel le fichier de configuration du «SERVER BDD». Dans un premier mode de réalisation, la table contient les requêtes R(k) indépendamment de la structure des clients. Un nouveau client peut alors avantageusement se connecter et utiliser les requêtes existantes, sans modifier le fichier de configuration SERVER BDD. Dans une variante de réalisation, pour chaque requête R(k), la table peut associer les clients C(m) qui l'utilisent. Une matrice peut être déterminée, par exemple.

Avantageusement, le SEP SERVER connaît statiquement au démarrage la liste des clients potentiels, et donc toutes les requêtes possibles; il peut également gérer des priorités et «forfaits» variables selon les clients. Dans une seconde sous-étape, pour chaque requête, le procédé crée une matrice de correspondance Req_Serv, entre les requêtes opérationnelles clients et un batch de services unitaires «S(*,j)» offerts par les fournisseurs de service «CORE» (la notation «*» indique que la correspondance ne dépend pas du coeur mais de la typologie des services unitaires). Dans un environnement «mono-cceur», la matrice contient donc la correspondance entre chaque requête complexe client R et la succession de services S(K1,j) à exécuter pour réaliser la requête. Dans un environnement «multi-cceur», la requête pourra avantageusement être distribuée sur plusieurs coeurs, pour profiter du parallélisme, par exemple, ou des coeurs les plus rapides. La matrice S contient aussi l'ordre d'exécution des services pour réaliser la requête R(k). Pour chaque requête R(k), le procédé détermine les commandes COM(S(*,j), n) n = 1 pour le service à exécuter en premier. Dans un mode de réalisation, une valeur de «n» identique pour 2 services d'une requête signifie qu'ils sont parallélisables. Dans un mode de réalisation particulier, la matrice ne contient qu'une liste de requêtes «simples» correspondant aux services unitaires (bijection). Cela permet aux CLIENTS d'accéder aux services unitaires du coeur directement. Dans un mode de réalisation, la matrice contient la liste de requêtes «simples» correspondant aux services unitaires et la liste des requêtes complexes correspondant à un batch de services unitaires. Cette variante permet aux CLIENTS d'accéder aux services unitaires du coeur et d'effectuer des requêtes complexes. Cette variante est avantageusement flexible. Pour les services unitaires simples, les «CLIENTS» utilisent eux-mêmes les services unitaires disponibles via la première étape pour gérer leurs requêtes, non pas par appel direct du service (i.e. pour gérer la variabilité des coeurs) mais par appel d'une requête intermédiaire reformatée grâce à la matrice REQ_SERV. Pour les requêtes complexes, le serveur connaît et exécute le «batch» de services unitaires. Cette approche évite plusieurs désavantages et limitations (pas de mise à jour du code des clients lorsque les services unitaires varient ; pas de nécessité de connaître le fonctionnement des coeurs (i.e. de ce qui réalise exactement fonctionnellement le service) pas plus que de la dynamique du fonctionnement de ces coeurs (i.e. quel est l'enchaînement autorisé des services unitaires, quelles sont les données à réutiliser/modifier d'un appel de service unitaire vers un autre appel, etc).

Dans une troisième sous-étape, pour chaque requête, Le procédé crée une matrice de structure de réponse au client T_Rep(R(i)), contenant la liste des valeurs attendues en sortie. Dans un mode de réalisation, les données unitaires (issues du batch de commande de la deuxième sous-étape) sont simplement filtrées et mises en forme (unités, format du flottant, arrondis ...). Dans un mode de réalisation, les données unitaires issues du batch de commandes sont traitées mathématiquement pour reconstituer la réponse. Le traitement peut inclure des opérateurs arithmétiques, trigonométriques, fonctionnels ou logiques. Ces règles seront utilisées ultérieurement pour formater la réponse au client. Dans une variante de réalisation, le procédé crée une matrice comportant les coeurs Ki sur une dimension et les services S sur une autre dimension et la QoS sur les autres dimensions, et la matrice de correspondance sur d'autres dimensions. D'autres formalisation mathématique sont possibles (fonctions au lieu de tables par exemple).

Dans une troisième étape 630, le «SEP SERVER» traite les requêtes émanant des «CLIENTS». Dans une première sous-étape, une requête R(i) d'un «CLIENT» C(k) est reçue par le «SEP SERVER». Le «SEP SERVER «(ou sa partie «SERVER FRONT END») analyse la prise en charge de la requête. Si elle ne fait pas partie de la liste des requêtes gérées, stockée dans la table T_Requêtes du «SERVER BDD» 515 alors un message d'erreur peut être communiqué ainsi qu'une notification de rejet de la requête du client. Optionnellement, si le client n'est pas déclaré ou si la requête n'est pas autorisée pour ce client, la requête peut être rejetée, par exemple dans le cadre d'une table T_requêtes contenant les requêtes et les clients. Optionnellement, une variante de réalisation peut implémenter un mécanisme de «forfait» client (e.g. par exemple analogue au fonctionnement d'un forfait téléphonique bloqué): si un client a consommé toutes ses requêtes sur un temps donné, une notification de rejet peut être émise. Optionnellement, une variante de réalisation peut implémenter un mécanisme de filtrage des clients sur-consommateurs de service en considération d'un ou de plusieurs seuils prédéfinis). Par exemple, si un client effectue plus de N requêtes sur un intervalle de temps donné, une ou plusieurs notifications de rejet peuvent être émises. Optionnellement, dans une variante de réalisation, si le nombre maximum de requêtes gérables ou manipulables par le «SEP SERVER» est atteint (pile de requêtes R1, Rmax), la requête R(i) peut être rejetée (sinon, la requête sera acceptée).

Dans une première sous-étape alternative (variante de réalisation), il est fait usage de la consultation du»cache fonctionnel»: si la donnée attendue par le client est disponible et toujours valide, les autres étapes ne sont pas réalisées et le procédé se poursuit directement à la cinquième étape. Le cache fonctionnel peut être un «cache prédictif» : il contient des données calculées périodiquement par le «SEP SERVER» (i.e. sans sollicitation client, par exemple en fonction de l'analyse des requêtes récurrentes). Le cache fonctionnel peut également être un «cache d'historisation» : il peut conserver en mémoire certains résultats de requêtes déjà exécutées, tant qu'elles ne sont pas obsolètes, pour pouvoir immédiatement retourner le résultat à un client qui effectuerait la même requête un peu plus tard. Dans une seconde sous-étape, le «SEP SERVER» (ou sa partie «SERVER FRONT END») interroge le «SERVER BDD» pour déterminer la correspondance ou «mapping» en anglais entre la requête R(i) et le batch de services unitaires du/des coeur(s) «S(*,j) grâce à la matrice REQ_SERV. Dans une troisième sous-étape, le «SEP SERVER» (ou sa partie «SERVER FRONT END)>) interroge le SERVER BDD pour connaître la liste des coeurs «CORE 1» ... «CORE N» qui sont aptes à exécuter au moins un des services (et/ou il peut être fait usage de la consultation du cache fonctionnel (selon des modalités identiques à celles décrites précédemment). dans une quatrième sous-étape, le «SEP SERVER» (ou sa partie «SERVER FRONT END») interroge le SERVER BDD pour connaître la Qualité de Service (en particulier le temps de réponse de chaque coeur pour chaque service). Il en déduit le temps de réponse de la requête qui est la somme des temps de réponse des services unitaires sur le coeur Tu(S(k,j), K(k)), et du temps de traitement du «SEP SERVER» Tu(R(i),SEP SERVER) lui-même après avoir décompté également le temps de réponse des requêtes déjà en attente sur ce coeur. Optionnellement, pour les services parallélisables dans un environnement «multi-cceurs», le temps de réponse calculé retranche les temps de réponse des services parallélisables (pour 2 services parallélisables, le temps du service le plus long est sélectionné). Dans une variante de réalisation, le «SERVER CORE» se charge de réduire le temps de réponse en procédant à la parallélisation des calculs lors de l'exécution. Optionnellement, dans un environnement «multi-cceurs», le «SERVER FRONT END» peut optimiser le temps de réponse en choisissant les coeurs qui répondent le plus vite, par exemple selon la Qualité de Service en temps de réponse requis. Dans une variante de réalisation, le «SERVER CORE» se charge de réduire (e.g. encore plus) le temps de réponse en choisissant les coeurs, lors de l'exécution. Optionnellement, dans un environnement «monocoeur», si la QoS des services est paramétrable, le FRONTAL peut déterminer une QoS unitaire pour répondre à une QoS globale de la requête (en matière de précision, fiabilité, temps de réponse limite, etc.). En fonction des résultats (i.e. par comparaison de la QoS réalisable et de la QoS requise), le «SERVER FRONT END» peut accepter ou rejeter la requête. Dans une cinquième sous étape (optionnelle), le «SEP SERVER» (ou sa partie «SERVER FRONT END») peut reconsidérer les requêtes en cours présentes dans la pile de traitement, pour prendre en compte une requête dont le temps de réponse ne rentre pas (ou ne rentre plus) dans les temps limites, pourvu que cette reconsidération ne contrevienne pas aux temps limites associés aux autres requêtes. Dans une variante de réalisation, la gestion du traitement des requêtes peut prévoir, par exemple pour gérer une requête RI, si du temps et/ou des ressources sont disponibles, l'insertion d'une requête R2 dans la file de traitement (à condition que le temps d'exécution limite de R1 soit respecté). Dans une sixième sous-étape (optionnelle), si le «SERVER FRONT END» est distinct du «SERVER CORE», le «SEP SERVER» (ou sa partie «SERVER FRONT END))) transmet la requête R(i) au «SERVER CORE». Dans une variante de réalisation, les six sous-étapes de la troisième étape 630, le «SERVER FRONT END» gère la correspondance requête/services et l'exécution des services vers le FMS en lieu et place du «SERVER CORE». Dans cette option, le «SERVER FRONT END», le «SERVER CORE» et le «SEP SERVER» corresponde à une seule et même entité. Dans une septième sous-étape (optionnelle), le «SEP SERVER» peut interagir avec le cache fonctionnel. De la sorte, une partie des sous-étapes sont réalisés de manière autonome (et rapidement) pour un certain nombre de requêtes, par exemple du fait de la mise à disposition de données récurrentes et/ou souvent demandées par les clients. Une surveillance des requêtes peut être effectuée au démarrage, ou bien en capitalisant les requêtes qui sont appelées au cours du temps. Si une requête est fréquemment demandée (ou demandée par plusieurs clients), la septième sous étape effectue alors d'elle-même ladite requête, soit périodiquement, soit sur événement du CORE. Les données sont mises à disposition dans la cinquième étape et les CLIENTS abonnés peuvent être avertis de la mise à jour. Dans un mode de réalisation, la périodicité de la requête, en l'absence d'évènements, peut s'effectuer selon un critère d'obsolescence des données. De tels paramètres d'obsolescence peuvent être embarqués dans la «SERVER BDD» pour chaque service unitaire et peuvent se traduire par une durée («timer») ou un autre paramètre physique métier (comme l'évolution de l'altitude ou de la distance parcourue pour un avion). La caractéristique de cache fonctionnel peut être appliquée à d'autres services, par exemple aux consultations de bases de données (éventuellement assortie d'opérations de tri et de filtrage de données). Dans une quatrième étape, le «SEP SERVER» commande les coeurs «CORE» pour exécuter les requêtes. Dans une première sous-étape, le «SEP SERVER» (ou sa partie «SERVER CORE») appelle les différents coeurs K(k) identifiés avec leurs services unitaires S(k,j) sous forme d'un batch de commandes COM(S(k,j), n). Optionnellement, pour des services parallélisables en environnement multi-coeur, le temps de réponse calculé retranche les temps de réponse des services parallélisables (pour deux services parallélisables, le temps du service le plus long est sectionné).

Dans une variante de réalisation, le «SERVER FRONT END» qui se charge de déterminer la parallélisation, et transmet alors l'ordre des calculs et la liste des coeurs sous forme COM(S(k,j), n) au «SERVER CORE». Optionnellement, en environnement «multi-cceurs», le «SERVER CORE» optimise le temps de réponse en choisissant les coeurs qui répondent le plus vite, selon la Qualité de Service en temps de réponse requis. Dans une variante de réalisation, le «SERVER FRONT END» se charge de réduire le temps de réponse en choisissant les coeurs lors de l'exécution. Dans une seconde sous-étape, le «SERVER CORE» récupère les structures de données issues des réponses Rep_unitaire(S(K,j), n) et les stocke dans un moyen de stockage Rep_CORE 512. Dans une troisième sous-étape, le «SERVER CORE» avertit le «SERVER FRONT END» lorsque le batch de commandes COM est terminé et met à disposition le résultat des commandes dans Rep_CORE.

Dans une cinquième étape, le «SEP SERVER» traite le résultat des requêtes. Page : 28 Dans le cas de l'utilisation d'un cache fonctionnel, une partie des étapes peuvent être évitées (en particulier, par copie d'un ou de plusieurs résultats précédents). Dans une variante de réalisation, un résultat peut être associé à une date de péremption (ou pas). dans une première sous-étape, le «SEP SERVER» (ou sa partie «SERVER FRONT END») récupère les structures mises à disposition par la troisième sous étape de la quatrième étape, dans la base Rep_Core 512. Dans une deuxième sous-étape, le «SEP SERVER» (ou sa partie «SERVER FRONT END») récupère les structures de réponses attendues par le client pour la requête R(i) dans la table T_Rep. dans une troisième sous-étape, le «SEP SERVER» (ou sa partie «SERVER FRONT END») calcule les réponses au format «Client» Rep(R(i)) en appliquant les règles de la troisième sous-étape de la deuxième étape. Dans une quatrième sous-étape, le «SEP SERVER» (ou sa partie «SERVER FRONT END») remplit la structure de donnée «Réponse Server pour Ri» 511 et avertit le client de la disponibilité des données de la réponse. Dans une cinquième sous-étape, le «SEP SERVER» (ou sa partie «SERVER FRONT END») est averti par le client que la requête a fini d'être traitée. Si plusieurs clients sont abonnés à la requête, ils sont avertis. Dans une sixième sous- étape, le «SEP SERVER» 510 (ou sa partie «SERVER FRONT END)) 513) demande la réinitialisation de la base du WRAPPER 514 et de la structure de donnée «Réponse Server pour Ri» 511. La figure 7 illustre schématiquement la structure et les fonctions d'un 5 système de gestion de vol de type FMS («Flight Management System»). Le procédé selon l'invention s'applique avantageusement au dit FMS. Le FMS peut être considéré comme un «SERVER». Selon l'architecture ATA, la «gestion du vol» ou FMS fait partie de la «navigation» et concerne les chapitres ATA 22 et ATA 34. 10 Au sens aéronautique, les systèmes de navigation considèrent et assurent la localisation (e.g. position, état, vitesse, etc), le «Flight Planning» (e.g. route de référence, procédures terminales, waypoints, roulage, etc), la trajectoire, le guidage, le pilotage ( algorithmes permettant d'optimiser la mission ; choix d'aéroports de déroutement, 15 etc) La figure 7 représente schématiquement un FMS. Afin d'assurer sa mission, le FMS est connecté à de nombreux autres calculateurs (une centaine). Dans l'architecture selon le procédé, le FMS tel que décrit ci-dessus comporte un «FMS CORE» qui met à disposition une liste de 20 services unitaires de consultation/modification et un «FMS SERVER» qui réalise les tâches du «SEP SERVER» du procédé (e.g. mapping des requêtes, isolation du FMS CORE, pilotage de l'exécution des services du FMS CORE», traitement des résultats etc). Le serveur FMS 710 comprend par exemple des services FMS unitaires 25 qui peuvent être classés en trois catégories principales de service (norme AEEC ARINC 702A) : 1) les services de consultation de données géographiques 720 («navigation data & dynamic magnetic variation»), par exemple NAV DB 721 et MAG VAR 722, qui permettent aux clients de rechercher des informations géographiques (NAV DB) ou de déclinaison magnétique sur un point du globe ; 2) les services de consultation des performances de l'avion 730 («aircraft characteristic & performances») faisant intervenir TRAJ, PRED et PERF DB 731 par exemple ; et 3) les services de «gestion du vol» 740 («flight management») par exemple la 5 consultation de l'état de l'avion 741 (e.g. position, vitesse, états des systèmes connectés au FMS, comme l'état moteurs, etc), la consultation et modification de plan de vol et de trajectoire 742 et la consultation et modification des données d'initialisation du vol 743 (e.g. saisie des vitesses de décollage, de l'altitude de croisière, de la météo prévue, des 10 modes de consommation carburant, etc) Des exemples de requêtes «CLIENTS» sont décrits ci-après. Les opérations futures dans l'avion nécessitent (de plus en plus) que des systèmes tiers interagissent avec le FMS, en utilisant des services publics existants et/ou en utilisant des services privés existants (à rendre public 15 i.e. visibles) et/ou utilisant de nouveaux services à implémenter dans le FMS. A titre d'exemple de tels système tiers, il est possible de citer par exemple a) l'initialisation du plan de vol FMS par un calculateur externe (de type tablette tactile ou EFB pour «Electronic Flight Bag»), b) l'intégration du «plan de vol» du FMS avec le «plan de roulage» du 20 calculateur de roulage sol ; c) l'optimisation de la mission (par exemple appelée par un client sol (e.g. outil compagnie par exemple) ou à bord (e.g. tablette, EFB) via des requêtes de calcul FMS (alternatives de plans de vol FPLN de diversion, alternatives de paramètres d'optimisation du FMS, alternatives de paramètres d'initialisation du FMS e.g. test de 25 masses au décollage) ; d) la mise à jour du logiciel FMS (en particulier ses bases de données de Navigation, à cycle de 28 jours) par un équipement tiers (tablette, outil de maintenance, EFB) ; e) l'utilisation de requêtes FMS par un système de surveillance du terrain du trafic, de la météo pour filtrer des alertes, ou les confirmer, ou optimiser des 30 ajustements latéraux et verticaux (ex : évitement d'une masse nuageuse mobile détectée par un Radar Météo) par des systèmes tels que TCAS , TAWS , GPWS, WxR ou WIMS ; f) l'utilisation de requêtes FMS pour aider au déclenchement d'évènements sur un système tiers (e.g. RMS) ; g) la vérification de conformité de la trajectoire latérale et/ou verticale 5 calculée par le FMS, par rapport aux cartes aéronautiques numérisées fournies à l'équipage (stockées dans une tablette, un EFB par exemple) ; h) l'utilisation du système FMS pour connaitre des prédictions sur un horizon de temps donné selon des modes de conduite du vol (guidage) et d'état avion définis ; i) l'interaction avec le FWS (Flight Warning System) ; 10 j) les passagers connectés via leur interface cabine (IFE pour In Flight Entertainment), souhaitant connaître les prédictions en temps, vitesse pour leur destination ; k) l'utilisation du FMS via un AID (Agent d'Interaction Domaine) ou une IHS (Interface Homme Système) intégrée qui concentre et organise les échanges entre calculateurs ; I) l'utilisation 15 du FMS par un des clients quelconques ci-dessus, y compris IHM et DATALINK pour connaître les données géographiques locales ou prédites (points de passage, aéroports, balises de radionavigation) ; m) les interactions avec IHM et DATALINK, etc. Ainsi, une grande diversité de nouveaux clients sont susceptibles 20 d'interagir avec le FMS (EFB, WIMS, TCAS, TAWS, WxR, PA, FQMS, IFE), soit la plupart des systèmes selon les différents ATA. De plus, deux catégories supplémentaires de clients interagissent habituellement avec le système FMS: les interfaces Homme Machine (HMI) qui permettent aux opérateurs (équipage) d'interagir avec le FMS et l'interface dite CMU 25 (pour «Communication Management Unit») qui permet à un opérateur sol (compagnie, contrôle aérien) d'interagir avec le FMS. Ce calculateur CMU est par exemple un client des données FMS et il peut demander la modification de la mission (i.e. insérer des «révisions» dans le FMS). Par le terme «interaction», il est entendu l'envoi d'une requête au FMS, 30 avec un retour attendu, par opposition au terme «information» qui correspond au fait des systèmes tiers s'abonnent aux données émises périodiquement - ou sur événement - par le FMS. Certaines requêtes correspondent à des services unitaires (« en 1 pour 1»). Par exemple: une requête de récupération des aéroports autour de l'avion, correspondant à un service unitaire «Get_Airport» du service de consultation de la navigation database ; une requête d'insertion d'une Route compagnie au format AEEC ARINC 424 par exemple, pour un client est également un service unitaire «INSERT_COROUTE» offert par la partie «Flight Preparation» ; une requête de consultation de l'état avion (carburant courant par exemple) correspond à un service unitaire Get_current_Fuel offert par la partie «Aircraft States») ; une requête de consultation de l'enveloppe de vol courant de l'avion correspond à un service unitaire Get_flight_envelope offert par la partie «Flight envelope Computation» Des requêtes plus complexes peuvent générer des «batchs» (ou séquences ou ensembles ou collections, ordonnées ou non, priorisées ou non) de requêtes. Par exemple une requête «INSERT FPLN» d'insertion d'un plan de vol par éléments séparés, telle qu'effectuée actuellement par les services DATALINK pour les compagnies (AOC) et centres de contrôles (ATC), définies dans les normes ARINC 702A pour AOC et D0258 pour ATC peut comprendre ou correspondre à une pluralité de requêtes et/ou de paramètres associés à ces requêtes. L'insertion d'un plan de vol complet peut correspondre à une requête «INSERT FPLN» qui comporte généralement les paramètres suivants : a) des éléments permettant de calculer la route à suivre (e.g. aéroports, procédures de décollage, etc) b) des éléments d'initialisation du plan de vol, permettant en sus de réaliser les calculs de trajectoire et prédictions (e.g. niveau de croisière, masse prévue au décollage, etc) et c) des éléments d'environnement sur le plan de vol (e.g. météo prévue le long du plan de vol, calage barométrique etc). La requête client INSERT FPLN peut comprendre un ensemble de paramètres, parfois de manière indifférenciée. Le rôle du SERVER va être alors de déterminer les services unitaires pour répondre à la requête et l'ordre dans lequel les commandes doivent être traitées.

Dans un FMS classique, des contraintes existent en matière d'ordonnancement des différents services unitaires (e.g. insertion de la procédure de départ seulement après avoir inséré l'aéroport de départ). Certains FMS, de par leur architecture et leur conception, ont des règles contre-intuitives (certains FMS autorisent par exemple des services unitaires d'insertion d'un aéroport de départ seul, puis l'insertion d'autres éléments tandis que d'autres FMS encore imposent d'insérer l'aéroport de départ ET l'aéroport d'arrive en préalable à toute autre insertion d'élément latéral et vertical, etc). De même, certains FMS autorisent la saisie d'éléments d'initialisation sans avoir saisi de route, alors que d'autres l'imposent préalablement. Certains FMS permettent d'enchaîner des services unitaires d'insertion des airways, et réalisent automatiquement la gestion des croisements entre deux airways successifs tandis que d'autres l'interdisent, etc... Avantageusement, le SEP SERVER permet d'adapter et de gérer les commandes unitaires dans le bon ordre, afin de répondre aux requêtes. Le SEP SERVER peut également effectuer des comparaisons entre les différentes d'alternatives, à des fins d'optimisation. Par exemple, une requête complexe peut consister à comparer les alternatives de déroutement le long du plan de vol. Chaque «déroutement» constitue un plan de vol à part entière. Le rôle du SEP SERVER sera alors d'enchaîner les requêtes de ce type en requêtes de type «INSERT FPLN» pour chaque alternative de déroutement, chaque requête de type «INSERT FPLN» donnant lieu à un batch de services unitaires tel que proposé dans l'exemple précédent. En sortie, la cinquième sous-étape de la quatrième étape peut utiliser des opérateurs logiques pour effectuer de telles comparaisons (par exemple heure et le carburant prédits pour l'arrivée, recherche de meilleur niveau de vol en fonction de la météo, etc). La mise à jour périodique d'informations sous forme de cache fonctionnel 5 peut prendre en compte la position de l'avion (mise à jour quand cette position évolue selon des seuils prédéfinis) et/ou à intervalle temporel prédéfinis (réguliers, périodiques, etc) La figure 8 illustre des exemples de variantes de réalisation de l'invention. Les interactions entre les éléments de l'architecture peuvent être 10 unidirectionnelles ou bidirectionnelles. Les différents graphes correspondants aux différentes architectures possibles peuvent être orientés, ordonnés, ouverts, fermés, cycliques, acycliques, connexes etc. En particulier, les différents serveurs frontaux et/ou les coeurs de calcul peuvent être en interaction de différentes manières, par exemple de 15 manière directe ou de manière indirecte. Dans une variante de réalisation particulière, un serveur FRONTAL C AB 800 peut appeler un autre serveur FRONTAL AB 811, lequel peut ensuite adresser plusieurs coeurs 812 et 813 par exemple. Le FRONTAL C AB 800 adresse donc indirectement les coeurs 812 et 813. Le frontal C AB 800 peut également 20 être en interaction directe avec un CORE C 820. Dans une variante de réalisation, un serveur FRONTAL peut être commun à plusieurs coeurs. Inversement, dans une variante de réalisation, un même coeur peut être adressé par plusieurs serveurs de type FRONTAL. Plus généralement encore, des parties du graphe ou des circuits peuvent être redondants, de 25 manière à obtenir des systèmes distribués robustes et ou/réactifs. Dans un mode de réalisation, un SERVER comprend une plusieurs entités ou applications choisies parmi la liste comprenant FMS, IHM, IHS, AID, CMU, TCAS, TAWS, WIMS, WxR , EFB, tablette, FQMS, PA, FWS, IFE, TAXI ou une partition générique dédiée et un CLIENT peut comprendre une entité ou une application autre que le (i.e. différente du) SERVER. Dans un mode de réalisation, un SERVER peut comprendre une ou plusieurs des applications choisies parmi NAV DB, PERF DB, FPLN, TRAJ, PRED, GUID, LOCNAV, DATALINK ou l'IHM et un CLIENT peut comprendre une entité ou une application autre que le (i.e. différente du) SERVER.

Des modes de réalisation sont décrits ci-après. Il est divulgué un procédé pour la gestion du vol d'un aéronef mis en oeuvre par ordinateur au sein d'un système de gestion de vol ou FMS, le procédé comprenant les étapes consistant à recevoir une requête émise par au moins un client; déterminer une correspondance entre la requête et un ou plusieurs services unitaires prédéfinis exécutables par au moins un serveur associé audit FMS; enfiler le ou les services unitaires déterminés dans une ou plusieurs files d'attente; déterminer un temps de réponse associé à la requête; et notifier ledit au moins un client du temps de réponse.

Le procédé selon l'invention définit un système consistant à segmenter une requête en plusieurs parties ou portions ou sous-requêtes ou requêtes unitaires (e.g. avec ou sans recouvrement) correspondant chacune à des services unitaires de gestion de vol (e.g. services ATA, confer ci-après). Les services unitaires sont parallélisés, i.e. font l'objet de mises en file d'attente. A partir de ce système distribué, un temps de réponse associé à la requête du client est déterminé (selon différentes techniques, confer ci-après). Le client est notifié ou informé de traitement de sa requête selon différentes modalités (e.g. existence effective du traitement et/ou durée prédictible et/ou durée effective et/ou durée et niveau de qualité de service etc).

La définition de services unitaires (i.e. granularité terminale, niveau «atomique») permet généralement de mutualiser et/ou fusionner et/ou de simplifier et/ou d'agréger des requêtes émanant de différents clients. Dans ce cas, les calculs en aval sont de fait optimisés ou au moins optimisables (e.g. les mises en cache peuvent réduire les calculs). Il est généralement possible de mutualiser les ressources de traitement et/ou les entrées. En d 'autres termes, il est possible de mutualiser l'offre i.e. les ressources de calcul tout aussi bien que de mutualiser la demande i.e. en assimilant des requêtes, en tout ou partie. Concrètement, les requêtes peuvent être allouées de manière optimale sur les ressources matérielles à disposition (e.g. différents coeurs de calcul), par exemple de manière à lisser ou répartir la charge. Dans un développement, l'étape consistant à déterminer un temps de réponse comprend une étape consistant à déterminer le temps de 15 traitement de chaque service unitaire, le temps de traitement d'un service unitaire étant fonction de l'occupation d'une ou de plusieurs files d'attente. Dans un mode de réalisation, un temps théorique ou simulé peut être calculé ou simulé. Dans un mode de réalisation, le temps de réponse effectif, i.e. découlant de mesures conduites sur les coeurs de calcul peut 20 être déterminé. En fonction des modes de réalisation, la détermination du temps de réponse peut être différente. Par exemple, le temps de réponse peut être fonction du i) le temps de traitement des services unitaires Sj (par exemple récupéré du «SERVER BDD») et de ii) l'occupation de la file de traitement T par des requêtes en cours d'exécution. Plus 25 généralement, au sein d'un système distribué (éléments mis en oeuvre en parallèle), l'estimation du temps de réponse peut dépendre de la file de traitement des requêtes en cours d'exécution. Dans une variante, le «SERVER FRONT END» calcule le temps de réponse de la requête sur la base du temps de traitement des services unitaires Sj (récupéré du 30 «SERVER BDD») et de l'occupation de la file de traitement T par des requêtes en cours d'exécution. Le «SERVER CORE» reçoit les services à exécuter S(i,j) du FRONTAL et leur file de traitement associée, et les coeurs K sur lesquels exécuter les services Si. Dans un développement, le procédé comprend en outre une étape 5 consistant à exécuter lesdits services unitaires déterminés. Le «SEP SERVER» peut commander l'exécution des «Services» S(i,j) au «CORE», sur ladite file de traitement T, via les commandes COM(S(i,j),n) Dans un développement, le procédé comprend en outre une étape consistant à communiquer une réponse à un client, ladite réponse 10 comprenant les résultats de l'exécution des services unitaires. Dans un développement, au moins un client est associé à une priorité de traitement. Des schémas de QoS peuvent exister avec ou sans la gestion de priorités associées aux clients. Des clients peuvent présenter des priorités 15 prédéfinies, par exemple par défaut, d'autres peuvent ne jamais être associés à de telles priorités, d'autres encore peuvent se voir allouer des priorités au cours du temps (par exemple, en fonction des attentes déjà écoulées, en fonction de la criticité du client dans la perspective systémique globale, etc). 20 Dans un développement, l'étape consistant à déterminer une correspondance entre ladite requête et un ou plusieurs services unitaires prédéfinis et/ou l'étape consistant à enfiler le ou les services unitaires déterminés dans une ou plusieurs files d'attente et/ou l'étape consistant à exécuter lesdits services unitaires déterminés est fonction de la priorité 25 associée audit client. Le cas échéant, la priorité associée à un client (e.g. prédéfinie, déterminée ou allouée) peut influencer un certain nombre d'étapes du procédé: une priorité peut par exemple modifier le traitement au sein d'une file d'attente (e.g. requête en «doublant» une autre ou en interrompant une autre etc). Alternativement ou cumulativement, une priorité peut piloter ou influencer l'exécution d'un ou de plusieurs services unitaires (e.g. niveau de précision plus ou moins étendu). En particulier, l'ordonnancement d'exécution des services unitaires peut être contrôlé (en totalité ou partiellement) par des paramètres de priorité associés aux clients (le cas échéant). Toujours alternativement ou cumulativement, une priorité peut déterminer ou influencer la partition d'une requête initiale en un faisceau de requêtes unitaires (la granularité peut optionnellement être fonction de la criticité du client dans le système global, cette criticité étant partiellement reflétée ou «contextualisée» via le niveau de priorité, au moins dans certains modes de réalisation). Dans un développement, une priorité est dynamique. Les paramètres de priorité peuvent être prédéfinis en totalité ou en partie.

Ils peuvent être statiques (c'est-à-dire par exemple invariants au cours du temps) ou dynamiques (c'est-à-dire par exemple fonction de la charge globale du système de systèmes, fonction de l'arrivée de nouveaux clients etc). Dans un mode de réalisation, le «SEP SERVER», par exemple implémentant la détermination des services unitaires en correspondance avec la requête initialement reçue et les mises en file d'attente, est configuré en établissant notamment l'une et/ou l'autre des analyses suivantes : i) les caractéristiques en termes de qualité de service unitaire des services offerts par le «CORE», ii) la correspondance entre les requêtes des «CLIENTS» et les services unitaires du ou des «CORE» aptes à les exécuter ; iii) la correspondance entre les résultats des services unitaires du «CORE» et les résultats attendus par le client ; iv) l'ordonnancement des requêtes des différents «CLIENTS» sur le ou les «CORE» aptes à les traiter ; y) la gestion d'un cache fonctionnel pour conserver les résultats estimés comme potentiellement réutilisables sur une longue durée. Dans un développement, une priorité associée à un client est en outre associée à un nombre de requêtes maximal absolu et/ou un nombre de requête maximal pour un intervalle de temps prédéfini et/ou des paramètres en matière de précision et/ou de fiabilité d'exécution des services unitaires. La gestion de la qualité de service (vue au moyen de la transformation de la requête initiale en une pluralité de service unitaire, de la gestion des files d'attente, etc) peut être statique mais également dynamique (c'est-à-dire évoluant au cours du temps). Par ailleurs, cette qualité de service peut être contrôlée ou contrôlable selon diverses modalités (elle peut notamment être configurée et/ou configurable). Selon un aspect de l'invention, la gestion de la qualité de service peut être affinée selon différentes modalités. Par exemple, dans le cadre de la priorisation de certains clients par rapport à d'autres, peuvent être pris en compte un certain nombre de paramètres additionnels. Par exemple et de manière optionnelle, la gestion de la QoS (par exemple au travers de la gestion d'une table ou matrice définissant ou associée à cette QoS) peut prendre en compte les caractéristiques (ou paramètres) en matière de mémoire RAM/ROM et de charge processeur (par exemple du coeur pour un service S(ki,j). Toujours de manière optionnelle, une telle table de QoS peut comprendre les caractéristiques en matière de précision de calcul, ou bien encore de caractéristiques relatives à la fiabilité du calcul Selon un autre aspect de l'invention, le «SEP SERVER» comporte un moyen de stockage (SERVER BDD), laquelle détermine le nombre de requêtes «R max» acceptable en entrée, une liste de requêtes «R(i)», la structure de réponse Rep(R(i)) pour chaque requête R(i), le temps de réponse requis (deadline) «T_R(i)» par requête «R(i)», la liste des coeurs «K(i)» attaquables par le serveur, la liste des services «S(*,j)» offerts, la typologie des services offerts (liste des coeurs qui offrent le service, parallélisables, séquentiels, ordre), la QoS de chaque service unitaire du coeur et les temps d'exécution du CORE k(i) : Tu(Si, Kj), et du server 5 SERVER: Tu(Ri, Server) (formatage des données, temps de traitements internes au server ...). Le SERVER BDD comprend la matrice de correspondance REQ_SERV des services unitaires correspondant à chaque Requête. Le SERVER BDD détermine une correspondance entre les temps de traitements des Services S(*,j) et les temps de traitement 10 des requêtes R(i), sur la base de la table de correspondance REQ_SERV. Il est souligné que le calcul T(Ri) = f(T(S1), T(Sn)) n'est pas une simple somme (compte tenu des traitements parallélisables). Selon un aspect de l'invention, il peut être implémenté un mécanisme de «forfait» client (e.g. par exemple analogue au fonctionnement d'un forfait 15 téléphonique bloqué): si un client a consommé toutes ses requêtes sur un temps donné, une notification de rejet peut être émise. Optionnellement, une variante de réalisation peut implémenter un mécanisme de filtrage des clients sur-consommateurs de service en considération d'un ou de plusieurs seuils prédéfinis). Par exemple, si un client effectue plus de N 20 requêtes sur un intervalle de temps donné, une ou plusieurs notifications de rejet peuvent être émises. Optionnellement, dans une variante de réalisation, si le nombre maximum de requêtes gérables ou manipulables par le «SEP SERVER» est atteint (pile de requêtes R1, Rmax), la requête R(i) peut être rejetée. 25 Dans certains modes de réalisation, le système «SEP SERVER» 510 est un système adaptatif, selon différents schémas. Il peut être configurable «at design time» at «start time» et/ou «at runtime». L'expression «at design time» signifie que le nombre de clients, les temps ainsi que les services associés sont déterminés au moment de la conception. Cette 30 approche présente des limitations en termes de possibilités de maintenance et d'évolutivité. L'expression «at start time» signifie qu'au démarrage le système lit une table de configuration, par exemple «SERVER BDD» qui décrit la topologie de clients présents, et lit la liste des services «CORE» disponibles (avec leurs caractéristiques).

L'expression «at runtime» signifie que le procédé comporte en outre une ou plusieurs étapes visant à satisfaire un ou plusieurs clients et/ou les mécanismes d'adaptation associés (par exemple en temps réel). Dans un développement, la requête et/ou une ou plusieurs files d'attente est associées à une ou plusieurs mises en cache.

Selon un mode de réalisation, la mise en cache peut intervenir avant ou après la mise en files d'attente. La mise en cache peut concerner la requête (initiale) du client et/ou les requêtes unitaires dérivées de ladite requête initiale (la granularité de la mise en cache peut être variable). La mise en cache peut également concerner l'exécution des services unitaires. Il peut exister une pluralité de caches (par exemple de natures différentes ou bien de même nature pour des raisons de redondance et de rapidité d'accès). Dans un mode de réalisation, le «SERVER FRONT END» effectue des requêtes au «SERVER CORE» en l'absence de demande client, pour gérer un cache fonctionnel.

Dans un développement, la mise en cache est prédictive. Il peut être fait usage de la consultation d'un «cache fonctionnel»: si la donnée attendue par le client est disponible et toujours valide, les autres étapes ne sont pas réalisées et le procédé peut se poursuivre directement.

Dans un mode de réalisation, le cache fonctionnel est un «cache prédictif»: il contient des données calculées périodiquement par le «SEP SERVER» (sans sollicitation client, i.e. en l'absence d'une requête client, par exemple en fonction de l'analyse des requêtes récurrentes).

Dans un développement, le cache (la mise en cache) est d'historisation. Le cache fonctionnel peut être un «cache d'historisation»: il peut conserver en mémoire certains résultats de requêtes déjà exécutées, tant qu'elles ne sont pas obsolètes, pour pouvoir immédiatement retourner le résultat à un client qui effectuerait la même requête un peu plus tard. En d'autres termes, les résultats d'une requête sont mémorisés dans une certaine mesure au cas où un autre client (ou le même) refasse une requête équivalente, et que les résultats soient toujours valides. En fonction du contexte, les données manipulées dans le cache pourront par exemple être des données comprenant des requêtes récurrentes de même type (offline ou online), des données relatives à la phase du vol, des données relatives aux équipements connectés, des données relatives à la dynamique de l'avion, des données relatives à l'état des systèmes, des données relatives à l'obsolescence de ces mêmes données etc.

Dans un développement, le traitement d'une ou de plusieurs files d'attente peut être interrompu et/ou repris. Dans un aspect de l'invention, les traitements des requêtes par le CORE sur une file de traitement T peuvent être interrompus puis repris («Pause/Resume»). Le déclenchement de telles interruptions ou reprises dans les files d'attente peut être contrôlé par diverses entités. Dans un mode de réalisation, le contrôle est centralisé (e.g. par une ou plusieurs files d'attente, cad une unité en charge de l'ordonnancement des calculs). Dans d'autres modes de réalisation, le contrôle est distribué : le modèle client-serveur (e.g. «maître-esclave») peut être rendu plus sophistiqué dans la mesure où au moins certains clients peuvent interagir entre eux (compétition, coopétition, etc), par exemple via les files d'attente et/ou la gestion des priorités. Des modes de réalisation enfin peuvent être hybrides et comprendre par parties des contrôles centralisés tandis que d'autres contrôles résultent de l'émergence de parties du système en interaction les unes avec les autres. Les critères fondant ou causant ces interruptions et reprises peuvent également être divers ; ils peuvent notamment prendre en compte les priorités associées aux clients ou être commandés par un «dispatcheur» opérant selon des règles prédéfinies.

Dans un développement, la réponse à la requête d'un client est formatée selon un format adapté pour ledit client depuis les formats associés aux services unitaires. La réponse à la requête comprend les résultats de l'exécution des services unitaires. Ces services unitaires étant «isolés» ou découplés de l'évolution des clients, les données brutes fournies par les services «core» doivent généralement être retraités (ou modifiés ou traduits ou manipulés ou transformés ou complémentés ou filtrés) afin de répondre aux besoins des clients. Selon un aspect de l'invention, le «SERVER FRONT END» peut formater 15 ou «reformater» i.e. «traduire» la réponse Rep(Ri) à la requête R(i), à partir des structures Rep_unit(S(*,j)) récupérées du «SERVER CORE» lors de l'exécution des services S(Ï) L'opération de «reformatage» ou plus généralement de «traduction» peut notamment comprendre diverses opérations logiques (e.g. des 20 conversions d'unités ou de données, des fusions de données, des opérations arithmétiques, l'application d'algorithmes ou de règles etc) Par exemple, un EFB (client) peut souhaiter connaître la meilleure route parmi un jeu de N routes, avec comme critères le carburant consommé et le temps nécessaire pour atteindre la destination connue. Le client EFB 25 interroge le «CORE» FMS via le «SERVER» en envoyant ses N Routes. Le «SERVER FRONT END» prend en compte sa requête. Le «SERVER CORE» utilise les services du «CORE» et renvoie N routes utilisant le service «FLIGHT PREPARATION»; ce service permet d'insérer une route dans le FMS. Puis pour chacune des routes, le «SERVER FRONT END» récupère dans la «Réponse Core» la réponse brute du service dans le format du «CORE», à savoir une trajectoire 3D contenant les segments 2D (trace sol) et les prédictions en altitude, vitesse, heure de passage, météo et carburant sur chaque élément de la route. Afin de permettre au client de comparer les alternatives (e.g. classement des routes par carburant et temps), le «SERVER FRONT END» extrait les données pour chacune des routes, et crée un tableau contenant pour chaque route le carburant consommé et le temps pour atteindre la destination. Dans un développement, une requête est associée à un objectif de temps 10 de réponse et/ou un temps de réponse limite. La requête émise par un client peut être accompagnée d'une information relative à la contrainte de traitement (e.g. «ce que le client souhaite», délai optimal) et/ou à l'acceptabilité future d'une réponse (e.g. «ce que le client accepte en retour», délai maximum). De manière générale, selon un 15 aspect de l'invention, l'acceptabilité d'une nouvelle requête R(i) peut être déterminée, sur la base des temps de réponse de la requête R(i), comparé à un objectif de temps de réponse. Dans un mode de réalisation, en déterminant un ou plusieurs temps de réponse inférieurs (ou supérieurs) à un ou plusieurs seuils prédéfinis, il est également possible 20 de traiter efficacement les «petites « files d'attente» (par exemple si les priorités sont équivalentes). Un objectif de temps de calcul est déterminé de façon à pouvoir répondre aux clients un temps de réponse donné (le serveur pouvant être appelé par de multiples clients, et pouvant effectuer lui aussi ses propres 25 calculs). Ledit objectif de temps de réponse peut être déterminé par le client et/ou être déterminé par le serveur. Dans un développement, plusieurs requêtes reçues sont déterminées comme étant au moins partiellement identiques.

Les requêtes en entrée peuvent être totalement identiques (requêtes identiques ou quasi-identiques) ou partiellement redondantes (considérant les services unitaires en correspondance). Des requêtes peuvent être déterminées comme identiques (e.g. copie binaires), similaires (e.g. identiques en ce qui concerne leurs caractéristiques essentielles, i.e. différentes sur des points non-critiques), «équivalentes» (i.e. interprétées comme telles selon un modèle prédéfini, e.g. fonctionnellement équivalentes). Dans certains modes de réalisation très particuliers, il peut cependant 10 parfois arriver qu'une même requête soit transformée en des ensembles de services unitaires qui peuvent être différents. Par suite, les possibilités de mutualisation de plusieurs requêtes peuvent se trouver modifiées. Dans un développement, la priorité associée à un client résulte d'un mécanisme de vote. 15 Dans un mode de réalisation, les clients et/ou les serveurs se comportent comme un réseau de poste-à-poste («peer-to-peer» ou pair à pair). En particulier, la priorité allouée à chaque noeud peut «émerger» à la suite de négociations conduites dans et par le réseau. Dans un développement, une ou plusieurs files d'attente sont des files 20 d'attente réparties. Dans un mode de réalisation, la gestion d'une file d'attente s'effectue selon le principe de "Premier arrivé, premier servi" ( "First In, First Out" (FIFO)). En matière de file d'attente, des architectures distribuées peuvent également être implémentées (e.g. «files d'attente réparties»). Les règles 25 d'ordonnancement peuvent alors comprendre des algorithmes de «priority queuing» (priorité à certains types de trafic, en ne laissant passer du trafic de faible priorité que s'il n'y a plus de trafic de forte priorité), de «custom queuing» (selon des algorithmes de Round-Robin pondérés, visant par exemple à faire passer des requêtes de client, tour à tour, en laissant plus de temps aux paquets prioritaires) ou bien encore de «fair queuing» (e.g. attribuer successivement et équitablement une possibilité aux clients de faire passer leurs requêtes), etc... Dans un développement, au moins un client peut annuler une requête.

Dans un mode de réalisation, un client peut contribuer à l'économie des services core s'il s'avère qu'il n'a plus le besoin d'un résultat (e.g. il peut volontairement alléger les calculs en aval et les services core peuvent être adaptés à la reconnaissance de telles commandes de fin ou de retrait de requêtes).

Dans un développement, un client peut s'authentifier (e.g. authentification forte). Dans un mode de réalisation sécurisé de l'invention, les accès aux services core peuvent être chiffrés et/ou authentifiés. Dans un développement, le serveur est associé à un système de gestion de vol ou FMS.

Le FMS SERVER comporte un «SERVER CORE» lequel reçoit les requêtes du FRONTAL et leur file de traitement associée, et les coeurs K sur lesquels exécuter les services Sj. Le «SERVER CORE» associe à chaque requête client, la liste de «FM services», sur la base de la table de correspondance entre une requête client et une liste de «FM SERVICES». Le «SERVER CORE» commande l'exécution des «FM Services» COM(S(*,j), n) au «FM CORE» sur ladite file de traitement T. Le «SERVER CORE» fournit au «SERVER FRONT END» les résultats Rep_init(S(1)) de l'exécution des «FM SERVICES». Dans un développement, un service unitaire étant un service avionique de 25 type ATA (caractéristique de système et de méthode). Il est divulgué un produit programme d'ordinateur, ledit programme d'ordinateur comprenant des instructions de code permettant d'effectuer une ou plusieurs étapes du procédé lorsque ledit programme est exécuté sur un ordinateur. Il est divulgué un système avionique de gestion du vol d'un aéronef comprenant des moyens pour exécuter une ou plusieurs des étapes du 5 procédé. Dans un développement, le système comprend au moins un serveur (CORE) associé au système de gestion de vol FMS et au moins un serveur de clients (SEP SERVER), ledit au moins un serveur (CORE) associé au FMS comprenant des unités de calcul ou coeurs, chaque unité 10 de calcul ou coeur pouvant exécuter une pluralité de services unitaires, et ledit au moins un serveur de clients (SEP SERVER) pouvant recevoir une ou plusieurs requêtes émises par un ou plusieurs clients. Dans un développement, le serveur de clients (SEP SERVER) comprend un serveur frontal (FRONTAL) recevant les services unitaires et 15 déterminant les files de traitement des services unitaires et comprenant en outre un serveur de calcul (CORE) pour exécuter lesdits services unitaires. Dans un développement, ledit serveur (CORE) interroge un serveur de base de données (SERVER BDD) lequel comprend la liste des services 20 unitaires par unité de calcul. Dans un développement, un service unitaire est un service avionique de type ATA. La présente invention peut s'implémenter à partir d'éléments matériel et/ou logiciel. Elle peut être disponible en tant que produit programme 25 d'ordinateur sur un support lisible par ordinateur. Le support peut être électronique, magnétique, optique ou électromagnétique. Les moyens ou ressources informatiques peuvent être distribués ("Cloud computing").

Claims (27)

1. REVENDICATIONS1. Procédé pour la gestion du vol d'un aéronef mis en oeuvre par ordinateur au sein d'un système de gestion de vol ou FMS, comprenant 5 les étapes consistant à: - recevoir une requête émise par au moins un client; - déterminer une correspondance entre la requête et un ou plusieurs services unitaires prédéfinis exécutables par au moins un serveur associé audit FMS; 10 - enfiler le ou les services unitaires déterminés dans une ou plusieurs files d'attente; - déterminer un temps de réponse associé à la requête; et notifier ledit au moins un client du temps de réponse. 15
2. 2. Procédé selon la revendication 1, l'étape consistant à déterminer un temps de réponse comprenant une étape consistant à déterminer le temps de traitement de chaque service unitaire, le temps de traitement d'un service unitaire étant fonction de l'occupation d'une ou de plusieurs files d'attente. 20
3. 3. Procédé selon l'une quelconque des revendications précédentes, comprenant en outre une étape consistant à exécuter lesdits services unitaires déterminés. 25
4. 4. Procédé selon la revendication 3, comprenant en outre une étape consistant à communiquer une réponse à un client, ladite réponse comprenant les résultats de l'exécution des services unitaires.
5. 5. Procédé selon l'une quelconque des revendications précédentes, au 30 moins un client étant associé à une priorité de traitement.
6. 6. Procédé selon la revendication 5, l'étape consistant à déterminer une correspondance entre ladite requête et un ou plusieurs services unitaires prédéfinis et/ou l'étape consistant à enfiler le ou les services unitaires déterminés dans une ou plusieurs files d'attente et/ou l'étape consistant à exécuter lesdits services unitaires déterminés étant fonction de la priorité associée audit client.
7. 7. Procédé selon la revendication 5, une priorité étant dynamique. 10
8. 8. Procédé selon la revendication 5, une priorité associée à un client étant en outre associée à un nombre de requêtes maximal absolu et/ou un nombre de requête maximal pour un intervalle de temps prédéfini et/ou des paramètres en matière de précision et/ou de fiabilité d'exécution des 15 services unitaires.
9. 9. Procédé selon l'une quelconque des revendications précédentes, la requête et/ou une ou plusieurs files d'attente étant associées à une ou plusieurs mises en cache.
10. 10. Procédé selon la revendication 9, une mise en cache étant prédictive.
11. 11. Procédé selon la revendication 9, une mise en cache étant d'historisation.
12. 12. Procédé selon l'une quelconque des revendications dépendantes, le traitement d'une ou de plusieurs files d'attente pouvant être interrompu et/ou repris. 30
13. 13. Procédé selon la revendication 4, la réponse à la requête d'un client étant formatée selon un format adapté pour ledit client depuis les formats associés aux services unitaires. 20 25
14. 14. Procédé selon l'une quelconque des revendications précédentes, une requête étant associée à un objectif de temps de réponse et/ou un temps de réponse limite.
15. 15. Procédé selon l'une quelconque des revendications précédentes, plusieurs requêtes reçues étant déterminées comme étant au moins partiellement identiques.
16. 16. Procédé selon la revendication 5, la priorité associée à un client 10 résultant d'un mécanisme de vote.
17. 17. Procédé selon l'une quelconque des revendications précédentes, une ou plusieurs files d'attente étant des files d'attente réparties. 15
18. 18. Procédé selon l'une quelconque des revendications précédentes, un client pouvant annuler une requête.
19. 19. Procédé selon l'une quelconque des revendications précédentes, un client pouvant s'authentifier. 20
20. 20. Procédé selon l'une quelconque des revendications précédentes, le serveur étant associé à un système de gestion de vol ou FMS.
21. 21. Procédé selon l'une quelconque des revendications précédentes, un 25 service unitaire étant un service avionique de type ATA.
22. 22. Produit programme d'ordinateur, ledit programme d'ordinateur comprenant des instructions de code permettant d'effectuer les étapes du procédé selon l'une quelconque des revendications 1 à 21, lorsque ledit 30 programme est exécuté sur un ordinateur.
23. 23. Système avionique de gestion du vol d'un aéronef comprenant des moyens pour exécuter une ou plusieurs des étapes du procédé selon les revendications 1 à 21.
24. 24. Système selon la revendication 23, comprenant au moins un serveur (CORE) associé au système de gestion de vol FMS et au moins un serveur de clients (SEP SERVER), ledit au moins un serveur (CORE) associé au FMS comprenant des unités de calcul ou coeurs, chaque unité de calcul ou coeur pouvant exécuter une pluralité de services unitaires, et ledit au moins un serveur de clients (SEP SERVER) pouvant recevoir une ou plusieurs requêtes émises par un ou plusieurs clients.
25. 25. Système selon la revendication 24, le serveur de clients (SEP SERVER) comprenant un serveur frontal (FRONTAL) recevant les services unitaires et déterminant les files de traitement des services unitaires et comprenant en outre un serveur de calcul (CORE) pour exécuter lesdits services unitaires.
26. 26. Système selon la revendication 25, ledit serveur (CORE) interrogeant 20 un serveur de base de données (SERVER BDD) lequel comprend la liste des services unitaires par unité de calcul.
27. 27. Système selon l'une quelconque des revendications 23 à 26, un service unitaire étant un service avionique de type ATA. 25