FR3038751A1 - Procede d'integration d'une application d'optimisation de route (s) sous contraintes dans un systeme embarque avionique a architecture ouverte de type client serveur - Google Patents

Abstract

Un procédé d'intégration d'une application d'optimisation de route(s) d''un aéronef sous contraintes est mis en œuvre dans un système embarqué avionique comportant un calculateur de cœur DAL+ et un calculateur périphérique DAL- de gestion de l'application. Le procédé d'intégration détermine (212) une répartition fonctionnelle et physique optimale des fonctions élémentaires OPT_RTE_FU(i) de l'application au sein du système avionique embarqué sur l'ensemble des répartitions possibles qui rend minimal un critère de coût global CG, fonction de plusieurs paramètres dont au moins le coût de développement supplémentaire des fonctions élémentaires intégrées au sein du calculateur numérique de cœur DAL+, et réalise (214) l'intégration de l'application.

Description

Procédé d’intégration d’une application d’optimisation de route(s) sous contraintes dans un système embarqué avionique à architecture ouverte de type client serveur

La présente invention concerne un procédé d’intégration d’un service ou application d’optimisation d’une ou plusieurs routes d’un aéronef sous contraintes dans un système embarqué avionique à architecture ouverte de type client-serveur.

La présente invention concerne également l’architecture d’intégration du système embarqué à architecture ouverte intégrant le service d’optimisation de route(s) sous contraintes.

La présente invention concerne encore la mise en oeuvre du service d’optimisation de route(s) sous contraintes intégré dans le système avionique embarqué. L’invention se situe dans le domaine des systèmes embarqués, et plus particulièrement celui des systèmes avioniques qui mettent en oeuvre un calculateur de navigation embarqué, tel que le système de gestion de vol FMS (en anglais Flight Management System).

De manière classique, chaque système avionique temps réel est architecturé et développé pour répondre à des exigences de performances en termes de taux de panne (reset) et de Qualité de Service (QoS) fonctionnelle notamment, dans un cadre d’emploi défini.

Les systèmes avioniques embarqués sont qualifiés, avec un niveau de performance démontré, pour un environnement donné et ont des niveaux de développement logiciel différents, plus ou moins coûteux, correspondant à des exigences de sécurité ou criticité différents. En effet, ces niveaux de développement logiciel sont issus de l’analyse de risque avion FHA (en anglais Functional Hazard Analysis), dite « analyse de sûreté de fonctionnement », selon les normes internationales RTCA D0178C (USA) ou ED-12C (équivalent européen de l’EUROCAE). Cette analyse de risque établit la contribution de chaque fonction dans la chaîne opérationnelle de l’avion pour déterminer quel niveau maximal de panne (en anglais failure level) doit être atteint. Afin d’atteindre l’objectif en question, la norme contraint la qualité requise du matériel et du logiciel qui embarque et met en œuvre la fonction. Ces niveaux de qualité de développement sont appelés « DAL » (en anglais Development Assurance Level).

Les architectures avioniques actuelles sont le résultat d’une l’histoire, dans laquelle des considérations économiques ont joué un rôle important. Ainsi, pour des questions de « crédit de certification » ou de qualification incrémentale, mais aussi pour des raisons de coût de câblage concernant les interfaces, les nouvelles fonctions de navigation ont été systématiquement intégrées au sein d’un seul calculateur, parmi le système de gestion de vol FMS (en anglais Flight Management System), le système de roulage TAXI ou le Pilote Automatique PA.

De même, des fonctions de surveillance sont systématiquement intégrées au sein d’un seul calculateur selon ce qui est surveillé : TCAS (en anglais Traffic Collision Avoidance System), TAWS (en anglais Terrain Awareness System), WMS (en anglais Weather Management System), la CMU (en anglais « Communication Management Unit », contraintes liées à l’espace aérien), l’EFB (en anglais « Electronic Flight Bag », contraintes opérationnelles de la compagnie).

De même, la surveillance des états de l’aéronef est centralisée dans des calculateurs de type FWS (Flight Warning Systems) et OMS (Onboard Maintenance Systems).

Actuellement, le pilote automatique PA est développé en niveau DAL A qui correspond au niveau de sécurité le plus élevé, et le FMS est selon les avions développé en niveau DAL B ou C, avec une tendance à passer au niveau de développement DAL B compte tenu de son utilisation croissante dans les procédures. Le TCAS est développé quant à lui en niveau DAL C ou DAL D, et agit comme un filet de sauvegarde en n’étant pas utilisé pour guider l’appareil mais pour prévenir d’un danger lorsque les autres systèmes ont failli.

Or à iso-fonctionnel, c'est-à-dire pour un même service rendu opérationnellement, on peut estimer que chaque changement de niveau de développement DAL multiplie par dix le coût de développement. En effet, lorsque le niveau de développement logiciel augmente de D vers A en passant par C et B, l’exigence de sécurité augmente, ce qui se traduit par une augmentation de la complexité de l’algorithme et du degré de validation de ce dernier.

Ainsi, une fonction d’aide visuelle pour de la navigation, dont l’analyse de risque FHA requiert un niveau D, est actuellement intégrée dans l’un des calculateurs existants, FMS ou PA, de niveau A à C, ce qui a engendré un coût de développement dix à cent fois supérieur à celui qu’il aurait coûté dans un environnement matériel de niveau D.

En supplément de ce coût de développement, l’insertion de nouvelles fonctions ou services dans une architecture existante conduit fréquemment à des solutions complexes entre les systèmes, qui génèrent une charge d’apprentissage (en anglais training) pour les équipages et pour les équipes de maintenance, et augmente le risque d’erreur de manipulation des équipements pour réaliser la fonction.

Des solutions sont actuellement proposées dans une première demande de brevet français publiée sous le numéro FR3012880 et une deuxième demande de brevet français déposée le 16 mai 2014 et enregistrée sous le numéro de dépôt 14/01108 visant à intégrer dans un système avionique, comportant un module cœur et un module périphérique, des fonctionnalités supplémentaires sans nécessiter de modifier les éléments logiciels du module cœur et n’utilisant de ce dernier que des services génériques offerts. Ainsi, l’impact de l’intégration de nouveaux services ou fonctionnalités sur un module cœur de niveau de développement élevé tel qu’un FMS et/ou un PA est minimisé.

Toutefois, l’insertion d’un nouveau matériel, de type périphérique et de niveau de développement inférieur à celui d’un module cœur, dans les architectures existantes dites « Legacy », et supportant des nouvelles fonctionnalités de niveau de développement compatible, a lui-même un coût de développement rédhibitoire en termes notamment de reprise du câblage de milliers d’avions, de l’intégration matérielle du nouveau calculateur dans la soute pour son interfaçage avec d’autres équipements, de son alimentation électrique.

Ainsi, le problème technique de définir une architecture d’un système embarqué avionique, plus souple, plus adaptable, et permettant d’assurer l’intégration de nouvelles fonctions de navigation à coût minimum, tout en garantissant aux clients le niveau de DAL de l’ensemble reste posé.

Ainsi, ce besoin existe particulièrement lorsqu’il s’agit de définir une architecture de navigation au sein d’un système de navigation embarqué à architecture ouverte de type serveur-client qui permette d’intégrer un service d’optimisation de route(s) d’un aéronef sous contraintes.

Il est à remarquer que les optimiseurs puissants de routes sous contraintes actuels qui sont opérationnellement intéressants sont développés à partir de techniques logicielles non certifiables, très gourmandes en temps de calcul et en mémoire, et inadaptées aux calculateurs avioniques existants. De même, des fonctions de modélisation de contraintes externes (acquisition et détourage du trafic, de la météo ou du terrain) sont effectuées par des calculateurs spécialisés et non intégrables dans un système de calcul de route « optimale » actuel de type FMS.

Il s’agit donc de redéfinir des collaborations et fonctions entre systèmes avions qui permettent de calculer une route optimale sous contraintes de divers types (trafic, terrain, météo, état avion, espace aérien, opérations) opérationnelle, qui minimisent les coûts d’intégration dans un système de navigation à architecture ouverte ayant pour cœur un calculateur de type FMS et/ou PA de DAL élevé et au moins un calculateur périphérique de DAL moindre, qui minimisent les coûts de formation de personnel et de maintenance, et qui minimisent plus particulièrement l’impact sur les calculateurs de criticité élevé (en particulier le FMS dont le coût de développement est actuellement parmi les plus élevés de l’avion en raison de sa taille et de sa criticité).

Le problème technique est de proposer un procédé d’intégration opérationnelle, fonctionnelle et physique d’un service ou application d’optimisation de routes sous diverses contraintes (trafic, terrain, météo, état avion, espace aérien, opérations) dans un système avionique embarqué de type « client-serveur », qui minimise les moyens de développement de l’intégration de l’application en termes d’ajout de matériel, d’interface et de logiciel, de reprise de matériel, d’interface et de logiciel, de nombre de tâches et de temps de qualification matérielle et logicielle, et qui minimise les moyens d’exploitation de l’application en termes de maintenance et de temps de formation du personnel, tout en garantissant au client le niveau de DAL de l’ensemble avion.

Le problème technique est également de fournir une application d’optimisation de route(s) d’un aéronef sous diverses contraintes (trafic, terrain, météo, état avion, espace aérien, opérations), intégrée opérationnellement, fonctionnellement et physiquement dans une architecture ouverte d’un système avionique embarqué de type « client-serveur », et qui minimise les moyens de développement de l’intégration de l’application en termes d’ajout de matériel, d’interface et de logiciel, de reprise de matériel, d’interface et de logiciel, de nombre de tâches et de temps de qualification matérielle et logicielle, et qui minimise les moyens d’exploitation de l’application en termes de maintenance et de temps de formation du personnel, tout en garantissant au client le niveau de DAL de l’ensemble avion.

Le problème technique est encore de fournir un système avionique embarqué intégrant à architecture ouverte de type « client-serveur » qui intègre opérationnellement, fonctionnellement et physiquement une application d’optimisation de routes sous diverses contraintes (trafic, terrain, météo, état avion, espace aérien, opérations) en minimisant les moyens de développement de l’intégration de l’application en termes d’ajout de matériel, d’interface et de logiciel, de reprise de matériel, d’interface et de logiciel, de nombre de tâches et de temps de qualification matérielle et logicielle, et qui minimise les moyens d’exploitation de l’application en termes de maintenance et de temps de formation du personnel, dans le respect du niveau de DAL de l’ensemble avion. A cet effet, l’invention a pour objet un procédé d’intégration fonctionnelle et physique d’une application d’optimisation de route(s) d”un aéronef sous contraintes dans un système embarqué avionique, le système embarqué avionique comportant : un calculateur de cœur numérique DAL+, ayant un premier niveau de criticité DAL+, intégré dans une architecture initiale de calculateurs périphériques et de bases de données ayant des deuxièmes niveaux de criticité DAL-, inférieurs ou égaux au premier niveau de criticité DAL+, et servant de serveur en hébergeant une première pluralité de services ouverts génériques Serv_DAL+(j) ; et .- un calculateur périphérique DAL- de gestion de l’application d’optimisation de route(s) sous contraintes, ayant un deuxième niveau de criticité DAL-, inférieur ou égal au premier niveau de criticité DAL+, et servant de client en envoyant des requêtes de services au calculateur de cœur numérique DAL+ et/ ou aux calculateurs périphériques et de bases de données de l’architecture initiale au travers d’un réseau de communications ; caractérisé en ce que le procédé d’intégration fonctionnelle et physique de l’application d’optimisation de route(s) sous contraintes comporte les étapes consistant à : décomposer fonctionnellement l’application d’optimisation de route(s) sous contraintes OPT_RTE en une deuxième pluralité de fonctions élémentaires OPT_RTE_FU(i) ; et à partir de la deuxième pluralité des fonctions élémentaires OPT_RTE_FU(i) déterminer une première liste des fonctions élémentaires pouvant être exécutées en partie ou entièrement par au moins un service ouvert générique, et pour chaque fonction élémentaire une première sous-liste de service(s) ouvert(s) génériques ; et déterminer une répartition fonctionnelle et physique optimale des fonctions élémentaires OPT_RTE_FU(i) au sein du système avionique embarqué sur l’ensemble des répartitions possibles qui rend minimal un critère de coût global CG, fonction de plusieurs paramètres dont au moins le coût de développement supplémentaire des fonctions élémentaires intégrées au sein du calculateur numérique de cœur DAL+ ; et réaliser l’intégration de l’application d’optimisation de route(s) sous contraintes en implémentant effectivement les fonctions élémentaires et leur ordonnancement suivant la répartition fonctionnelle et physique optimale déterminée au sein du système avionique embarqué dans l’étape précédente de détermination de la répartition fonctionnelle et physique optimale des fonctions élémentaires.

Suivant des modes particuliers de réalisation, le procédé dTintégration fonctionnelle et physique de l’application d’optimisation de routes sous diverses contraintes comprend l’une ou plusieurs des caractéristiques suivantes : la répartition fonctionnelle et physique optimale des fonctions élémentaires OPT_RTE_FU(i) au sein du système avionique embarqué sur l’ensemble des répartitions possibles est déterminée pour rendre minimale un premier critère CG1 de coût global qui prend seulement en compte le coût de développement supplémentaire des fonctions élémentaires intégrées au sein du calculateur numérique de cœur DAL+; et l’intégration de l’application d’optimisation de route(s) sous contraintes est réalisée en implémentant effectivement les fonctions élémentaires et leur ordonnancement suivant la répartition fonctionnelle et physique optimale déterminée au sein du système avionique embarqué en utilisant le premier critère CG 1 ; la répartition fonctionnelle et physique optimale des fonctions élémentaires OPT_RTE_FU(i) au sein du système avionique embarqué sur l’ensemble des répartitions possibles est déterminée pour rendre minimale un deuxième critère de coût global CG2 qui prend également en compte le coût de développement des interfaces de communication entre le calculateur de cœur DAL+ et les calculateurs périphériques, le coût en temps de réponse et le coût de maintenabilité pour minimiser les échanges de communication ; et l’intégration de l’application d’optimisation de route(s) sous contraintes est réalisée en implémentant effectivement les fonctions élémentaires et leur ordonnancement suivant la répartition fonctionnelle et physique optimale déterminée au sein du système avionique embarqué en utilisant le deuxième critère CG2 ; la répartition fonctionnelle et physique optimale des fonctions élémentaires OPT_RTE_FU(i) au sein du système avionique embarqué sur l’ensemble des répartitions possibles est déterminée pour rendre minimale un troisième critère de coût global CG3 qui prend également en compte le développement de certaines pièces de code de niveau de DAL faible dans le calculateur de cœur DAL+ pour minimiser la complexité de l’ensemble dans une optique de maintenance et d’évolution; et l’intégration de l’application d’optimisation de route(s) sous contraintes est réalisée en implémentant effectivement les fonctions élémentaires et leur ordonnancement suivant la répartition fonctionnelle et physique optimale déterminée au sein du système avionique embarqué en utilisant le troisième critère CG3 ; la répartition fonctionnelle et physique optimale des fonctions élémentaires OPT_RTE_FU(i) au sein du système avionique embarqué sur l’ensemble des répartitions possibles est déterminée pour rendre minimale un quatrième critère de coût global CG4 qui prend également en compte l’utilisation de librairies de code de niveau DAL+ dans le calculateur périphérique de niveau DAL- pour minimiser l’utilisation des ressources du calculateur de cœur DAL+ ; et l’intégration de l’application d’optimisation de route(s) sous contraintes est réalisée en implémentant effectivement les fonctions élémentaires et leur ordonnancement suivant la répartition fonctionnelle et physique optimale déterminée au sein du système avionique embarqué en utilisant le quatrième critère CG4 ; le procédé d’intégration fonctionnelle et physique de l’application d’optimisation de route(s) d’un aéronef sous contraintes comprend en outre une étape supplémentaire, exécutée après avoir déterminé une répartition fonctionnelle et physique optimale des fonctions élémentaires OPT_RTE_FU(i) au sein du système avionique embarqué, et consistant en ce que les performances de application d’optimisation de route(s) sous contraintes sont vérifiées et évaluées par émulation ou simulation, et/ou les performances des services initiaux mis en œuvre sur le calculateur de cœur et les calculateurs périphériques sont vérifiées ; le calculateur de cœur numérique DAL+ héberge des services Serv_DAL+(j) de calculs de plan de vol, de trajectoire latérale et de prédictions temporelles selon un mode de guidage spécifié, utilisés pour la mise en œuvre d’une partie des fonctions élémentaires formant l’application d’optimisation de route(s) sous contraintes ; et le calculateur de cœur numérique DAL+ est couplé à des calculateurs de pilotage de l’aéronef ; la première pluralité de services génériques Serv_DAL+(j) comporte les services suivants: calcul de la localisation de l’aéronef, insertion/Modification de plan de vol, calcul de trajectoire latérale, calcul de trajectoire verticale, calcul de performances de l’aéronef, guidage latéral, guidage vertical, guidage en vitesse, consultation de base de donnée de navigation, consultation de base de donnée de performance avion, consultation de base de données de configuration, consultation de base de données de déclinaison magnétique, affichage de la route et de la trajectoire, affichage des éléments de base de données ; l’application d’optimisation de route(s) d’un aéronef sous contraintes comporte les fonctions élémentaires suivantes :

Une première fonction élémentaire OPT_RTE_FU(1) de sélection d’un « route cible » ;

Une deuxième fonction élémentaire OPT_RTE_FU(2) de calcul des prédictions le long du plan de vol et de la trajectoire

Une troisième fonction élémentaire OPT_RTE_FU(3) de sélection des contraintes à appliquer ;

Une quatrième fonction élémentaire OPT_RTE_FU(4) de sélection d’un espacement minimal à respecter ;

Une cinquième fonction élémentaire OPT_RTE_FU(5) d’affichage de la route et des contraintes vers un opérateur ;

Une sixième fonction élémentaire OPT_RTE_FU(6) de détection de conflit entre la route actuelle et les contraintes ;

Une septième fonction élémentaire OPT_RTE_FU(7) d’affichage des éléments de navigation issus des bases de données autour de la trajectoire et/ou autour des contraintes ;

Une huitième fonction élémentaire OPT_RTE_FU(8) de calcul d’évitement pour résoudre le conflit entre la route et la contrainte ;

Une neuvième fonction élémentaire OPT_RTE_FU(9) d’intégration de l’évitement dans la route actuelle, destinée à être réutilisée par la deuxième fonction élémentaire OPT_RTE_FU(2) pour déterminer le nouveau plan de vol, la nouvelle trajectoire) ;

Une dixième fonction élémentaire OPT_RTE_FU(10) d’exécution de la nouvelle route

Une onzième fonction élémentaire OPT_RTE_FU(11 ) de monitoring de l’évolution des contraintes à intervalle régulier ; les fonctions élémentaires OPT_RTE_FU(2), OPT_RTE_FU(5), OPT RTE FU(7), OPT_RTE_FU(7) et OPT_RTE_FU(10) sont allouées au et implémentées dans le calculateur de cœur numérique DAL+, tandis que les fonctions élémentaires restantes sont allouées et implémentées dans un calculateur périphérique DAL- du système intégrant l’application d’optimisation de route(s) sous contraintes ; la fonction élémentaire FIM_FU(10) qui correspond au service Serv_DAL+(4) pour le mode de guidage et l’élément de navigation sélectionnés est allouée au et implémentée dans le calculateur de cœur numérique 4 DAL+, tandis que les fonctions élémentaires restantes sont allouées et implémentées dans un calculateur périphérique DAL- du système intégrant l’application d’optimisation de route(s) sous contraintes ; les fonctions élémentaires OPT_RTE_FU(2), OPT_RTE_FU(5), OPT_RTE_FU(7), OPT_RTE_FU(7), OPT_RTE_FU(8) et OPT_RTE_FU(10) sont allouées au et implémentées dans le calculateur de cœur numérique DAL+ , tandis que les fonctions élémentaires restantes sont allouées et implémentées dans un calculateur périphérique DAL- du système intégrant l’application d’optimisation de route(s) sous contraintes ; la première fonction élémentaire OPT_RTE_FU(1) consiste à sélectionner une « route cible » définie par un des éléments suivants : un aéroport cible, une route de référence cible, une portion de route de référence cible, une trajectoire de référence, un ensemble de points de passage définis par le pilote, un ensemble de points de passage et de balises de navigation sélectionné dans la base de données de navigation ; la deuxième fonction élémentaire OPT_RTE_FU(2) calcule des prédictions le long du plan de vol et de la trajectoire, incluant notamment la position prédite en 3D et éventuellement en temps de l’aéronef le long de la trajectoire, la position prédite en temps permettant de gérer les contraintes dynamiques ou évolutives ; la troisième fonction élémentaire OPT_RTE_FU(3) sélectionne des contraintes à appliquer, ces contraintes étant définies par des formes géométriques géographiques ou des représentations visuelles brutes telles que des volumes modélisant notamment des nuages, des espaces aériens 3D et des obstacles), des surfaces en 3D notamment de terrain, des surfaces en 2D notamment des frontières et des changements d’espaces aériens. L’invention a également pour objet un système embarqué avionique configuré pour mettre en œuvre une application d’optimisation de route(s) d’un aéronef sous contraintes et l’intégrer fonctionnellement et physiquement, le système embarqué avionique comportant : un calculateur de cœur numérique DAL+, ayant un premier de criticité DAL+, intégré dans une architecture initiale de calculateurs périphériques et de bases de données ayant des deuxièmes niveaux de criticité DAL-, inférieurs ou égaux au premier niveau de criticité DAL+, et servant de serveur en hébergeant une première pluralité de services ouverts génériques Serv_DAL+(j) ; et un calculateur périphérique DAL+ de gestion de l’application d’optimisation de route(s) sous contraintes, ayant un deuxième niveau de criticité DAL- , et servant de client en envoyant des requêtes de services au calculateur de cœur numérique DAL+ et/ou aux calculateurs périphériques et bases de données périphériques de l’architecture initiale au travers d’un réseau de communications ; l’application d’optimisation de route(s) sous contraintes OPT_RTE étant décomposée en une pluralité de fonctions élémentaires OPT_RTE_FU(i) réparties physiquement entre le calculateur de cœur numérique DAL+ et le calculateur périphérique de gestion DAL- suivant un schéma de répartition optimal déterminé par le procédé d’intégration défini ci-dessus, et le calculateur périphérique de gestion (6) DAL- étant configuré pour supporter une application parmi : une IHM, une IHS intégrée, une CMU, un TCAS, un TAWS, un EFB, une tablette, un TRAFFIC COMPUTER, une partition générique dédiée ; et le calculateur de cœur numérique (4) DAL+ étant configuré pour supporter une application parmi : un système de gestion de vol FMS, un Pilote Automatique (PA), un système FMGS combinant les fonctions FMS et PA. L’invention sera mieux comprise à la lecture de la description de plusieurs formes de réalisation qui va suivre, donnée uniquement à titre d’exemple et faite en se référant aux dessins sur lesquels : - la Figure 1 est une vue d’un système de gestion de vol de type FMS pour un aéronef, configuré pour mettre en œuvre la fonction d’optimisation de route(s) sous contrainte, ladite application étant intégrée selon un procédé d’intégration de l’invention ; la Figure 2 est une vue de l’architecture d’un calculateur de cœur DAL+ supportant les fonctionnalités FMS ; - La Figure 3 est une vue de la structure arborescente de la bibliothèque de services génériques offerts par le calculateur de niveau DAL+ supportant les fonctionnalités génériques FMS et agissant comme serveur ; - La Figure 4 est un ordinogramme d’un procédé selon l’invention d’intégration de la fonction d’optimisation de route(s) d’un aéronef sous contraintes entre le calculateur de cœur FMS de niveau DAL+ et le calculateur périphérique DAL- de gestion de l’application d’optimisation de la route sous contraintes ; - La Figure 5 est un ordinogramme de l’exécution de la fonction d’optimisation de route(s) sous contraintes intégrée selon le procédé d’intégration de l’invention de la Figure 4 ; - La Figure 6 est une vue d’une surface tridimensionnelle 3D, approximée par des facettes et utilisée de manière particulière dans une étape de l’exécution de la fonction d’optimisation de route(s) sous contraintes intégrée de la figure 5 ; - La Figure 7 est une vue d’une configuration envisagée dans l’algorithme de la fonction d’optimisation de route sous contraintes OPT_RTE dans lequel une facette de la surface 3D croise la trajectoire prédite de l’avion ; - La Figure 8 est une vue d’une première route d’un aéronef prédite initialement en l’absence d’aléa météorologique et d’une deuxième route, prédite par l’application d’optimisation de route sous contrainte et qui gère un aléa météorologique également représenté sur la Figure.

Suivant la Figure 1, un système embarqué de navigation 2 comprend au moins deux calculateurs dont un calculateur de cœur numérique de navigation 4 et au moins un calculateur périphériques, ici cinq calculateurs périphériques 6, 8, 10, 12, 14 et un réseau de communications 20 reliant le calculateur de cœur numérique 4 et l’au moins un périphériques 6, 8, 10, 12, 14, ledit réseau de communications 20 étant représenté seulement de manière fonctionnelle sur la Figure 1.

Par calculateur, on entend de manière générale une chaîne de calcul matérielle et logicielle. Un calculateur peut être constitué de plusieurs boîtiers et/ou cartes matériels et/ou de plusieurs partitions logicielles. La redondance, la dissimilarité, la surveillance et le suivi (en anglais monitoring) d’un calcul par une deuxième chaîne ou tout autre procédé de diversification connu de l’homme de l’art entrent dans définition de ce terme.

Le système de navigation 2 est configuré pour mettre en œuvre une application OPT_RTE d’optimisation de routes sous diverses contraintes (trafic, terrain, météo, état avion, espace aérien, opérations).

Un des calculateurs périphériques, ici le calculateur 6, est une tablette ou un EFB (en anglais Electronic Flying Bag), configuré pour gérer ou coordonner les tâches de l’application OPT_RTE et désigné par calculateur de gestion. Le calculateur périphérique de gestion 6 de l’application OPT_RTE est connecté au travers du réseau de communication 20 au calculateur de cœur numérique 4 DAL+ et aux quatre autres calculateurs périphériques 8, 10, 12, 14 pour échanger diverses requêtes et réponses fonctionnelles.

Le calculateur de cœur numérique 4 est configuré pour supporter les fonctionnalités FMS et/ou PA tandis que les calculateurs périphériques 8, 10, 12, 14 sont configurés pour supporter respectivement les fonctionnalités TAWS(en anglais Terrain Awareness and Warning System), TCAS (en anglais Traffic Collision Avoidance System), WMS (en anglais Weather Management System) et CMU (en anglais Communications Management Unit).

Le calculateur périphérique 6 de gestion ou coordination des tâches de l’application OPT_RTE comporte une interface d’entrées/sorties 24 pour échanger des requêtes et des réponses opérationnelles avec un environnement opérateur formé 26 par exemple par un pilote, une station sol AOC (en anglais Airline Operational Communications) ou ATC (en anglais Air Traffic Control).

Le calculateur de cœur numérique 4 est configuré pour fonctionner notamment comme un serveur hébergeant une première pluralité de services ouverts génériques Serv_DAL+(j), j étant un indice de pointage du service générique, et possède un premier niveau sécuritaire de développement logiciel ou de criticité DAL+.

Les calculateurs périphériques 6, 8, 10, 12, 14 possèdent un deuxième niveau sécuritaire de développement logiciel DAL- , inférieur ou égal au premier niveau sécuritaire de développement logiciel DAL+, et parmi eux au moins le calculateur périphérique 6 de gestion de l’application d’optimisation OPT_RTE est configuré pour fonctionner comme un client vis-à-vis du serveur 4.

Chaque calculateur du système embarqué est architecturé et développé pour répondre à des exigences de performances, notamment en termes de taux de panne (reset) et de Qualité de Service (QoS) fonctionnelle), dans un cadre d’emploi défini. Les systèmes embarqués sont qualifiés, avec un niveau de performance démontré, pour un environnement donné.

Ces calculateurs ont des niveaux de développement logiciel différents, et plus ou moins coûteux : Ces niveaux de développement logiciel sont issus de l’analyse de risque avion FHA (en anglais Functional Hazard analysis), dite « analyse de sûreté de fonctionnement », selon les normes internationales RTCA D0178C (USA) ou ED-12C (équivalent européen de l’EUROCAE). L’analyse de sûreté de fonctionnement établit la contribution de la fonction dans la chaîne opérationnelle avion pour déterminer quel niveau maximal de panne (en anglais failure rate) doit être atteint. Afin d’atteindre l’objectif en question, la norme contraint la qualité requise du matériel et du logiciel qui embarque la fonction.

Cinq niveaux de développement logiciel sont distingués et existent, du plus critique (niveau A) au moins critique (niveau E) dans les normes RTCA D0178C et ED-12C : • Niveau A : Un défaut du système ou sous-système étudié peut provoquer un problème catastrophique - Sécurité du vol ou atterrissage compromis - Crash de l'avion • Niveau B : Un défaut du système ou sous-système étudié peut provoquer un problème majeur entraînant des dégâts sérieux voire la mort de quelques occupants • Niveau C : Un défaut du système ou sous-système étudié peut provoquer un problème sérieux entraînant un dysfonctionnement des équipements vitaux de l'appareil • Niveau D : Un défaut du système ou sous-système étudié peut provoquer un problème pouvant perturber la sécurité du vol • Niveau E : Un défaut du système ou sous-système étudié peut provoquer un problème sans effet sur la sécurité du vol

Ces niveaux de développement sécuritaire logiciel sont appelés « DAL » (en anglais Development Assurance Level). La contrainte en terme matériel et logiciel est fixée aux valeurs suivantes : • Niveau A : un taux de panne maximum de 10’9 / FH (FH = Flight Hours = heures de vol) • Niveau B : un taux de panne maximum de 10'7 / FH (FH = Flight Hours = heures de vol) • Niveau C : un taux de panne maximum de 10‘5 / FH (FH = Flight Hours = heures de vol) • Niveau D : un taux de panne maximum de 10'3 / FH (FH = Flight Hours = heures de vol) • Niveau E : un taux de panne maximum de 10‘1 / FH (FH = Flight Hours = heures de vol)

Le calculateur périphérique 6 DAL- de gestion de l’application est un calculateur périphérique configuré pour supporter une application parmi : une IHM, une IHS intégrée, une CMU un TCAS un TAWS un EFB une tablette un TRAFFIC COMPUTER une partition générique dédiée

Le calculateur de cœur numérique 4 DAL+ est configuré pour supporter une application parmi : un système de gestion de vol FMS, un Pilote Automatique (PA) un système FMGS combinant les fonctions FMS et PA.

Dans cette implémentation, une fonction d’allocation et d’enchaînement de fonctions élémentaires OPT_RTE_FU(i) réalisant l’application d’optimisation opérationnelle OPT_RTE peut être mise en œuvre dans le procédé d’intégration par un calculateur indépendant du système avionique embarqué 2, ou hébergé dans l’une des applications (par exemple dans un EFB ou tablette pour le dialogue avec pilote ou membre d’équipage, dans une CMU pour le dialogue avec le sol (compagnie, centres de contrôle) ou dans le calculateur de cœur 4 DAL+ qui agit comme filtre dans ce cas.

Suivant la Figure 2 et un exemple d’architecture fonctionnelle, un calculateur de cœur numérique 4 DAL+ supportant une application FMS standard 50 selon la norme ARINC 702A (Advanced Flight Management Computer System, Dec 1996), est configuré pour assurer tout ou partie des fonctions de : ❖ Navigation LOCNAV 52 pour effectuer la localisation optimale de l’aéronef en fonction des moyens de géo-localisation (GPS, GALILEO, balises radios VHF, centrales inertielles) ; ❖ Plan de vol FPLN 54 pour saisir les éléments géographiques constituant le squelette de la route à suivre (procédures de départ et d’arrivée, points de passages (waypoints), airways) ; ❖ Base de donnée de navigation NAVDB 56 pour construire des routes géographiques et des procédures à partir de données incluses dans les bases (points, balises, legs d’interception ou d’altitude...) ; ❖ Base de données de performance, PRF DB 58, contenant les paramètres aérodynamiques et moteurs de l’appareil. ❖ Trajectoire latérale TRAJ 60 pour construire une trajectoire continue à partir des points du plan de vol, respectant les performances avion et les contraintes de confinement (RNP) ; ❖ Prédictions PRED 62 pour construire un profil vertical optimisé sur la trajectoire latérale ; ❖ Guidage GUIDANCE 64 pour guider dans les plans latéraux et verticaux l’aéronef sur sa trajectoire 3D, tout en optimisant la vitesse ; ❖ Liaison de données numériques DATALINK 66 pour communiquer avec les centres de contrôle et les autres aéronefs.

Un des rôles du FMS est de localiser l’avion en utilisant ses senseurs 67 (centrales à inertie, GPS, balises radioélectriques). C’est la partie LOC N AV 52. A partir des informations géographiques contenues dans la base de donnée de navigation NAV DB 56, le pilote peut construire sa route, appelée plan de vol et comportant la liste de points de passage dénommés « waypoints ». C’est le rôle de la partie FPLN 54. Le FMS peut gérer plusieurs plans de vol. L’un d’entre eux, connu sous l’acronyme « Active » (pour Actif) dans l’ARINC 702A désigne le plan de vol sur lequel l’avion est guidé. Il existe des plans de vol de travail (parfois appelés « plans de vol secondaires » ou « inactifs »), ainsi que des plans de vol transitoires (plans de vol temporaires).

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), par la partie TRAJ 60.

Sur cette trajectoire latérale, le FMS 50 optimise une trajectoire verticale (en altitude et vitesse), passant par des contraintes éventuelles d’altitude, de vitesse, de temps, en utilisant une modélisation des performances aérodynamiques et moteurs contenue dans le PERF DB 58.

Connaissant la localisation de l’avion et la trajectoire 3D, le FMS 50 peut asservir l’avion sur cette trajectoire. C’est la partie GUIDANCE 64. L’ensemble des informations entrées ou calculées par le FMS 50 est regroupée sur des écrans d’affichages IHM 70 (pages MFD, visualisations NTD et PFD, HUD ou autre).

La communication avec le sol (compagnie, contrôle aérien) est réalisée par la partie DATALINK 66.

Il est à remarquer que dans la terminologie FMS, on utilise le vocable « révision » pour caractériser une insertion/modification/effacement de données du système FMS et que le mot « Edition » est également couramment utilisé.

Dans les architectures actuelles et quel que soit l’avion, la partie « Flight Planning » et « trajectoire optimisée » est en général incluse dans un calculateur dédié appelé « FMS » pour « Flight Management System » (ou calculateur de gestion du vol). Ces fonctions constituent le cœur de métier FMS. Ce système peut héberger également une partie de la « Localisation » et du « Guidage ». Afin d’assurer sa mission, le FMS est connecté à de nombreux autres calculateurs (une centaine).

Suivant la Figure 3, les services ouverts génériques Serv_DAL+(j) d’un calculateur DAL+ supportant l’ensemble 50 des fonctionnalités FMS forment un serveur 80 FMS et sont classés en trois catégories.

Une première catégorie 82 de services ouverts génériques concerne les services de consultation de données géographiques 84 et déclinaison magnétique 86 (en anglais navigation data & dynamic magnetic variation) qui permettent aux clients de rechercher et manipuler des informations géographiques (NAV DB) ou de déclinaison magnétique (MAG VAR) sur un point du globe, lia plupart des procédures se référant encore au nord magnétique.

Une deuxième catégorie 88 de services ouverts génériques concerne les services de consultation des performances de l’avion (en anglais aircraft characteristics & performances) faisant intervenir TRAJ, PRED et PERF DB.

Les services de la deuxième catégorie 88 fournissent : o des bornes caractéristiques de l’avion comme par exemple les masses minimale et maximale, le plafond d’altitude certifié ; les vitesses de décollage et atterrissage, dites vitesses caractéristiques ; des calculs d’enveloppe de vol (vitesses maximales, vitesses de décrochage, roulis maximal ...) o des calculs d’intégration selon des modes avions choisis (montée d’un certain nombre X de pieds à poussée constante, descente à pente air déterminée et vitesse figée, virage à angle imposé ...), des calculs de forfaits (pour certains FMS, des calculs de performance simplifiés peuvent être définis dans la PERF DB, là où la précision requise est plus faible).

Une troisième catégorie 90 de services ouverts génériques concerne les services « gestion du vol » (en anglais flight management) que sont : o la consultation de l’état de l’avion 92 (position, vitesse, états des systèmes connectés au FMS, comme l’état moteurs, les modes engagés au pilote automatique, etc ...) ; o la consultation et la modification 94 de plan de vol et de trajectoire 5D ; o la consultation et la modification des données d’initialisation du vol (saisie des vitesses de décollage, de l’altitude de croisière, de la météo prévue, des modes de consommation carburant...) o les services de prédictions sur un horizon de temps donné selon des modes de conduite du vol (guidage) et d’état avion définis, comme par exemple dans les cas : d’un pilote automatique souhaitant connaître le taux de montée moyen sur 2000 ft d’évolution d’altitude avec 1 moteur en panne, d’un calculateur de carburant souhaitant comparer la consommation moyenne avec les prédictions FMS de consommation... d’un calculateur TCAS souhaitant connaître l’évolution horizontale (ou 3D) de l’avion selon un mode de guidage latéral et de guidage en vitesse déterminés.

Certaines requêtes de services ouverts génériques, dites élémentaires peuvent correspondre à des demandes unitaires de services génériques comme 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 Préparation » de la figure ci-dessus • 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 (vitesses min et max par exemple) correspond à un service unitaire Get_flight_envelope offert par la partie « Flight envelope Computation ») D’autres requêtes plus complexes peuvent être réalisées par une succession de requêtes élémentaires sous forme de groupes (en anglais batchs) de commandes, comme typiquement, 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éfinis dans les normes ARINC 702A pour AOC et D0258 pour ATC. L’insertion d’un plan de vol complet est une requête « INSERT FPLN » qui comporte en général les paramètres suivants, définis dans les normes en questions, que sont : o Des éléments permettant de calculer la route à suivre : o Des aéroports (départ, arrivée, alternate) o Des procédures de décollage (connues sous le nom de departure runway, SID ...) o Des procédures de croisière (connues sous le nom d’airways) o Des procédures d’arrivée (connues sous le nom d’arrival runway, STAR, VIA ...) o Des procédures de remise de gaz (connues sous le nom de Missed Approach) o Des procédures de dégagement à l’arrivée vers un aéroport d’appui (connues sous le nom d’alternate) o Des points de passages en plus des procédures o Des balises de navigation o Des contraintes d’altitude, de vitesse, de temps sur les points issus des procédures ci-dessus ou sur les points de passage o Des éléments d'initialisation du plan de vol, permettant en sus de réaliser les calculs de trajectoire et prédictions que sont : o Le Niveau de croisière o La Masse prévue au décollage o L’indice de performance (connu sous l’acronyme Cost Index) o La position initiale au décollage o Des éléments d’environnement sur le plan de vol : o Météo prévue le long du plan de vol sous forme de données de vent et température sur les points issus des procédures ci-dessus ou sur les points de passage o Calage barométrique prévu au départ et à l’arrivée Suivant la Figure 4, un procédé 202 OPEN_OPT_RTE d’intégration, fonctionnelle et physique, d’une application d’optimisation de route(s) sous contraintes dans un système embarqué avionique 2, d’architecture ouverte telle que définie dans la Figure 1, comporte un ensemble de première, deuxième, troisième, quatrième, cinquième, sixième, septième étapes 204, 206, 208, 210, 212, 214, 216.

Dans la première étape 204, la compatibilité du niveau de criticité de la fonction OPT_RTE d’optimisation de route(s) sous contraintes avec le niveau de développement du calculateur de cœur DAL+ est vérifiée. Après avoir déterminé le niveau de criticité associé à la fonction OPT_RTE, celui-ci est comparé au niveau de criticité du calculateur de cœur DAL+. Si le niveau de la fonction OPT_RTE est inférieur ou égal à celui du calculateur de cœur DAL+, la fonction est candidate à être implémentée en partie sur un calculateur DAL- de niveau moindre au sens large. Sinon la fonction OPT_RTE doit être exécutée en reprenant l’architecture du système pour y inclure un calculateur de niveau de criticité supérieur à celui du calculateur de cœur numérique DAL+ prévu initialement.

Une fonction opérationnelle de proposition d’alternative de route pour anticiper une ou plusieurs contraintes, non immédiates, pourra être de niveau faible (par exemple de niveau de criticité D ou E) et correspondre à :

Un aléa ou danger (en anglais hazard) météo prévu à plusieurs dizaines de minutes ou plusieurs heures devant l’avion, voire à l’arrivée ;

Un aléa ou danger terrain/obstacle non immédiat, par exemple un changement de route au sein d’un terrain montagneux encore devant l’avion ou la présence d’espaces aériens restreints en fonction des horaires ;

Un aléa ou danger de trafic lointain, par exemple un engorgement prévu dans un espace aérien suite à des restrictions de trafic, ou des grèves ;

Un aléa compagnie, par exemple un besoin de dérouter pour des raisons de connexion (hub), ou pour embarquer des passagers d’un aéroport intermédiaire ;

Un aléa aéroportuaire lointain, par exemple une fermeture de piste, des pistes verglacées, un problème au débarquement ;

Un aléa interne à l’avion de faible gravité, par exemple la panne d’un calculateur non critique ;

Ou tout ensemble de contraintes de ce type. Notons qu’une accumulation de contraintes peut augmenter le niveau de criticité : typiquement un aléa terrain lointain (zone montagneuse) couplé à une limitation aéronef nécessitant de voler en dessous d’un certain plafond (dépressurisation, problème médical à bord lié à la pression) vont devoir générer une route claire du terrain, de manière plus fiable.

Une fonction opérationnelle de proposition d’alternative de route pour anticiper une contrainte plus forte pourra être de niveau moyen (par exemple de niveau de criticité C ou D) et correspondre à :

Un aléa ou danger météo en cours de constitution à quelques dizaines de minutes ou moins devant l’avion, par exemple une formation de cumulonimbus, une arrivée dans une zone de nuages givrants etc ;

Un aléa ou danger terrain/obstacle à moyen terme, par exemple un changement de route au sein d’un terrain montagneux actuellement suivi ou activation de restriction d’espaces aériens dans quelques dizaines de minutes ou moins ;

Un aléa trafic à moyen terme, par exemple une arrivée dans un espace aérien chargé, un conflit à moyen terme détecté avec d’autres appareils en approche ;

Un aléa compagnie, par exemple un besoin de dérouter pour des raisons plus critiques (une urgence médicale), pour embarquer des passagers lors d’une évacuation d’un pays ;

Un aléa aéroportuaire plus proche, par exemple une fermeture de piste, des pistes verglacées, un problème au débarquement ;

Un aléa interne à l’avion de gravité plus importante, par exemple la panne d’un calculateur critique, une dépressurisation de la cabine, une panne de moteur.

Puis, dans la deuxième étape 206, les services génériques offerts par les capacités de calcul du calculateur de navigation à architecture ouverte et de cœur numérique DAL+ sont répertoriés et classifiés suivant une bibliothèque de services Serv_DAL+(1), ..., Serv_DAL+(j), ...Serv_DAL+(n_Serv), ces services génériques résultant des concepts d’architecture ouverte qui commencent à voir le jour dans les calculateurs critiques tel que par exemple le FMS.

Le classement général de ces services Serv_DAL+(j) dans cas d’un calculateur de cœur numérique supportant les fonctionnalités FMS est décrit dans la Figure 3 et le texte de description qui s’y rapporte.

Dans le cas de l’optimisation de route sous contraintes OPT_RTE, la deuxième étape 206 utilisera les requêtes de modification (ou de redéfinition) de plan de vol, de calcul de trajectoire latérale, de calcul des prédictions verticales sur un horizon de temps, des modes de conduite du vol (ou guidage) vertical prédits.

Ainsi pour un calculateur de cœur 4 DAL+ supportant les fonctionnalités FMS et disposant d’une architecture ouverte, les services suivants sont listés :

Des services de consultation Serv_DAL+_CONSULT parmi lesquels : .- des services Serv_DAL+_CONSULT(1) de consultation de bases de données géographiques du FMS (NAVDB, MAGVAR, BDD (base de données) aéroportuaire, base des données pilote) ; .- des services Serv_DA+L_CONSULT(2) de consultation de base de données de performance avion du FMS (PERFDB) ; .- des services Serv_DAL+_CONSULT(3) de consultation de base de données ou d’éléments de configuration avion (AMI, PinProg) ;

Des services de modification de plan de vol Serv_DAL+_PDV parmi lesquels : des services Serv_DAL+_PDV(1) d’insertion/modification d’éléments de procédures, et éléments des bases de données de navigation identifiés ci-dessus (aéroports, procédures de décollage, d’atterrissage, de croisière, de saisie de points de passages, de remise de gaz ...) ; des services Serv_DAL+_PDV(2) d’insertion/modification des données d’initialisation avion (masse, niveau de croisière, Cost Index) ; des services Serv_DAL+_PDV(3) d’insertion/modification de l’environnement avion (vents, températures et pressions prédites le long du vol) ;

Des services de calcul de trajectoires (latérale, verticale) Serv_DAL+ _TRAJ parmi lesquels : des services Serv_DAL+_TRAJ(1) de calcul de la trajectoire latérale et verticale selon le plan de vol défini et les caractéristiques liées au plan de vol définies dans les services Serv_DAL+_PDV ; des services Serv_DAL+_TRAJ(2) de calcul d’une portion de trajectoire latérale de l’aéronef selon des modes latéraux imposés parmi : .* Acquisition et Tenue de cap (mode Heading) .* Acquisition et Tenue de Route (mode Track ou Course) .* Suivi de trajectoire FMS (mode LNAV pour Latéral Navigation) .* Suivi de faisceau radioélectrique (VOR, DME, LOC...)

Ces modes sont considérés à titre d’exemples, d’autres modes classiques de l’avion pouvant être ajoutés comme la tenue de roulis. des services Serv_DAL+_TRAJ (3) d’intégration temporelle en vue d’obtenir des prédictions selon un Mode de guidage vertical parmi : .* Montée à poussée fixe et consigne en vitesse longitudinale (CAS, TAS, MACH ou GS) ; mode dit Open Climb’ dans la terminologie classique ; .* Montée à consigne en vitesse longitudinale et consigne en vitesse verticale (V/S) ; mode dit « CLIMB VS/SPEED » dans la terminologie classique ; .* Montée à consigne en vitesse longitudinale et consigne en pente (FPA) ; mode dit « CLIMB FPA/SPEED » dans la terminologie classique.

Ces modes sont considérés à titre d’exemples, les autres modes classiques de l’avion peuvent être ajoutés, comme la tenue d’assiette et la tenue d”incidence. Les mêmes modes correspondant à la Descente tels que OPEN DES, ...pourront également être considérés. .- le service Serv_DAL+_TRAJ(4) concernant l’intégration de la météo, sous forme de mesures et de modèle météo, sur les différents niveaux ; .- le service Serv_DAL+_TRAJ(5) concernant la sélection forcée de configuration(s) particulière(s) comme paramètres d’entrée en vue d’une simulation tels que par exemple : le nombre de moteurs en panne, un coefficient de dégradation moteur (perf factor, usure) ou aérodynamique (coefficient de traînée ou en anglais drag factor).

Les services génériques Serv_DAL+_TRAJ(4) et Serv_DAL+_TRAJ(5) peuvent être ajoutés avantageusement dans la liste des services offerts par le calculateur de cœur DAL+, et permettront d’affiner le calcul des services génériques Serv_DAL+(1), Serv_DAL+(2) ou Serv_DAL+(3).

Des services d’affichages Serv_DAL+_IHM parmi lesquels : un service Serv_DAL+_IHM(1) d’envoi sur les écrans d’affichage de la route (plan de vol, trajectoire) ; .- un service Serv_DAL+_IHM(2) d’envoi sur les écrans d’affichage d’éléments de la base de donnée de navigation (NAVDB, BDD aéroport) ;

Des services de calcul position avion Serv_DAL+_LOC : le FMS (ou le PA) propose de gérer la position avion par : .- un service Serv_DAL+_LOC(1 ) de calcul du vecteur avion (position, vitesse) en fonction des capteurs (inerties, GNSS, radiobalises de navigation ...);

Des services de calcul de trajectoires (latérale, verticale) Serv_DAL+_GUID parmi lesquels : .- un service Serv_DAL+_GUID(1) d’envoi des consignes de guidage latérales aux automatismes de l’avion pouvant être utilisé par le procédé 202 ; .- un service Serv_DAL+_GUID(2) d’envoi des consignes de guidage verticales aux automatismes de l’avion pouvant être utilisé par le procédé ; .- un service Serv_DAL+_GUID(3) d’envoi des consignes de guidage en vitesse aux automatismes de l’avion pouvant être utilisé par le procédé 202 ; et que le FMS (ou le PA) proposent de gérer le guidage latéral et/ou vertical de l’avion selon un mode désiré ;

Des services de d’administration de plans de vol trajectoire et guidage Serv_DAL+_ADMIN parmi lesquels : un service Serv_DAL+_ADMIN(1) permettant de gérer les plans de vol, de les insérer, les permuter, les copier/coller... ; .- un service Serv_DAL+_ADMIN(2) permettant de gérer les trajectoires, de les insérer, les permuter, les copier/coller... ; .- un service Serv_DAL+_ADMIN(3) permettant de gérer les automatismes de pilotage comme l’engagement/le dégagement de modes de guidage.

Cette liste est donnée à titre d’exemple ; elle n’est ni exhaustive ni limitative, certains calculateurs de navigation type FMS ne réalisent qu’une sous partie de ces services, d’autres en réalisent davantage comme la concentration de pannes pour d’autres systèmes, la communication numérique avec les stations sol de contrôle aérien (ATC pour « Air Traffic Control ») ou de la compagnie (AOC pour Airline Operational Communications).

Ensuite dans la troisième étape 208, une analyse fonctionnelle de la fonction ou application d’optimisation de route(s) sous diverses contraintes OPT_RTE est effectuée en décomposant ladite fonction en une deuxième pluralité de fonctions élémentaires OPT_RTE_FU(1), .... OPT_RTE_FU(i), ...OPT_RTE_FU(n_OPT_RTE_FU), i désignant un pointeur des fonctions élémentaires de 1 au nombre total n_OPT_RTE_FU de fonctions élémentaires.

Par la suite, on désignera « OPT_RTE AIRCRAFT » l’avion qui embarque la fonction d’optimisation de route sous contraintes OPT_RTE et qui calcule une route optimisée dudit avion en respectant un jeu de contraintes externes (e.g. trafic, terrain, météo, pannes, opérations ...).

Les fonctions élémentaires OPT_RTE_FU(1), ..., OPT_RTE_FU(i), ...OPT_RTE_FU(n_OPT_RTE_FU) dans leur ordre d’enchaînement de la manœuvre d’optimisation de route sous contraintes OPT_RTE sont les suivantes :

Une première fonction élémentaire OPT_RTE_FU(1) de sélection d’une « route cible » défini parmi un des éléments suivants : .- un aéroport cible : dans le cas d’une diversion vers une nouvelle destination, l’avion quitte son plan de vol, et définit un nouvel aéroport de destination ; la route sur laquelle le procédé s’appliquera est alors seulement constituée de deux éléments : la position courante avion, et le nouvel aéroport ; une route de référence cible : dans le cas d’une route prédéfinie et en cours de vol, on définira cette route (plan de vol) comme « route cible » pour chercher la trajectoire optimale ; une portion de route de référence cible : dans le cas d’une diversion à partir d’un point du plan de vol pour rejoindre un nouvel aéroport de destination ou un autre point de la route en aval ou un autre point défini, la « route cible » est constitué de la portion de plan de vol initiale et de l’aéroport/point cible ; une trajectoire de référence : dans le cas d’une optimisation de la trajectoire, libre des éléments de plan de vol (points de passages (en anglais waypoints), couloirs aériens (en anglais airways), procédures de décollage et atterrissage, la route cible est constituée de la trajectoire de référence ; un ensemble de points de passage définis par le pilote : dans le cas d’une sélection manuelle d’évitement, par exemple sur un EFB ou une tablette, le pilote sélectionne un point de passage par lequel l’avion doit passer. Ce nouveau élément est créé dans la base pilote ; un ensemble de points de passage et des balises de navigation sélectionnés dans la NAVDB : dans le cas d’une sélection manuelle d’évitement, par exemple sur un EFB ou une tablette, le pilote sélectionne une zone par laquelle l’avion doit passer. Au lieu de créer un nouvel élément dans la base pilote, on utilise des points déjà existants dans la NAVDB se trouvant dans la zone sélectionnée. Cela permet de faciliter un futur accord ATC, de ne pas créer un point dans une zone interdite à la navigation, d’optimiser les échanges entre équipements DAL- et DAL+ en ne récupérant qu’un nombre restreint d’éléments autour de la sélection du pilote. Ce type de sélection permet d’être plus précis sur la construction du déroutement par rapport à une sélection manuelle sur un écran EFB ou tablette (vibrations, échelle d’affichage). La sélection d’un point de passage appartenant à une procédure permettra de poursuivre le déroutement via l’utilisation de procédure (insertion d’une airway par exemple) ;

Une deuxième fonction élémentaire OPT_RTE_FU(2) de calcul des prédictions le long du plan de vol et de la trajectoire, incluant notamment la position prédite en 3D et éventuellement en temps de l’aéronef le long de la trajectoire, la position prédite en temps permettant de gérer les contraintes dynamiques ou évolutives ; • Une troisième fonction élémentaire OPT_RTE_FU(3) de sélection des contraintes à appliquer, ces contraintes pouvant être définies par des formes géométriques géographiques ou des représentations visuelles brutes telles que des volumes (nuages, espaces aériens 3D, obstacles), des surfaces en 3D (terrain), des surfaces en 2D (frontières, changements d’espaces aériens) ;

Une quatrième fonction élémentaire OPT_RTE_FU(4) de sélection d’un espacement minimal à respecter ;

Une cinquième fonction élémentaire OPT_RTE_FU(5) d’affichage de la route et des contraintes vers un opérateur ; cette fonction permet à l’opérateur de contrôler la problématique de croisement entre la route et les contraintes ;

Une sixième fonction élémentaire OPT_RTE_FU(6) de détection de conflit entre la route actuelle et les contraintes, cette fonction étant soit statique soit dynamique si les contraintes sont évolutives. Elle détecte les croisements géométriques entre la route et les contraintes, à moins de l’espacement minimal à respecter ;

Une septième fonction élémentaire OPT_RTE_FU(7) d’affichage des éléments de navigation, issus des bases de données, autour de la trajectoire et/ou autour des contraintes, cette fonction pouvant être automatique, ou manuelle par « sélection » d’une zone par l’opérateur, demandant l’affichage des éléments de navigation ;

Une huitième fonction élémentaire OPT_RTE_FU(8) de calcul d’évitement pour résoudre le conflit entre la route et la contrainte ; il est à remarquer qu’il existe de nombreux optimiseurs (en anglais « solvers ») de route sous contraintes sur le marché ; cette fonction peut être réalisée également manuellement par saisie (ou création de points pilotes) d’éléments de navigation ou par création à la volée d’une trajectoire d’évitement ;

Une neuvième fonction élémentaire OPT_RTE_FU(9) d’intégration de l’évitement dans la route actuelle, qui sera réutilisée par la deuxième fonction élémentaire OPT_RTE_FU(2) pour déterminer le nouveau plan de vol, la nouvelle trajectoire ;

Une dixième fonction élémentaire OPT_RTE_FU(10) d’exécution de la nouvelle route ;

Une onzième fonction élémentaire OPT_RTE_FU(11) de surveillance et suivi de l’évolution des contraintes à intervalle régulier.

Puis dans la quatrième étape 210, pour chaque fonction élémentaire OPT_RTE_FU(i) déterminée dans la troisième étape 208, il est déterminé si la fonction élémentaire OPT_RTE_FU(i) peut être effectuée en partie ou entièrement par un service générique Serv_DAL+(j) du calculateur de navigation 4 DAL+ existant. Ainsi il est déterminé à partir de la deuxième pluralité des fonctions élémentaires OPT_RTE_FU(i) une première liste des fonctions élémentaires pouvant être exécutées en partie ou entièrement par au moins un service ouvert générique, et pour chaque fonction élémentaire OPT_RTE_FU(i) une première sous-liste de service(s) ouvert(s) générique(s). En d’autres termes, une table de correspondance (ou en anglais un mapping) est établie entre les fonctions élémentaires OPT_RTE_FU(i) de l’application de calcul d’une route optimisée sous contraintes OPT_RTE et les services ouvert(s) générique(s) utilisables par chacune d’entre elles.

Ainsi, il est déterminé que le calculateur de cœur 4 DAL+ peut prendre en charge :

La deuxième fonction élémentaire OPT_RTE_FU(2) de calcul de la trajectoire prédite le long du plan de vol, qui correspond aux services génériques Serv_DAL+_FPLN(1 ) et Serv_DAL+_TRAJ(1)

La cinquième fonction élémentaire OPT_RTE_FU(5) pour la partie affichage de la route (plan de vol, trajectoire) qui correspond au service Serv_DAL+_IHM(1)

La septième fonction élémentaire OPT_RTE_FU(7) d’affichage des éléments de navigation autour de la route et des contraintes qui correspond au service Serv_DAL+_IHM(2) ;

La neuvième fonction élémentaire OPT_RTE_FU(9) d’intégration de la modification de route dans la route avion, qui correspond aux services Serv_DAL+_ADMIN(1) et Serv_DAL+_ADMIN(2)

La dixième fonction élémentaire OPT_RTE_FU(10) d’exécution de la route qui correspond aux services Serv_DAL+_GUID(1), Serv_DAL+_GUID(2) et Serv_DAL+_GUID(3).

Puis dans la cinquième étape 212, un critère de coût global CG est pris en compte pour déterminer une répartition fonctionnelle et physique optimale des fonctions élémentaires OPT_RTE_FU(i) au sein du système avionique embarqué 2 sur l’ensemble des répartitions possibles qui rend minimale ledit critère de coût global CG.

De manière générale, le critère de coût global « CG » est fonction de plusieurs paramètres dont au moins le coût de développement d’une fonction élémentaire dans le calculateur de cœur DAL+.

Selon un premier mode de réalisation CG1 du critère global CG, le critère de coût global CG1 est fonction seulement du coût de développement de fonctions élémentaires au sein du calculateur de cœur DAL+ et/ou de librairie de code de niveau DAL+

Les autres paramètres qui peuvent être pris en compte sont : le coût de développement des interfaces de communication entre les deux calculateurs 4 DAL+ et 6 DAL-, le coût en temps de réponse , le coût estimé de la maintenance, le coût de training, le coût de maintenabilité et d’évolutivité de la fonction, et éventuellement d’autres coûts à définir par le concepteur.

Selon un deuxième mode de réalisation CG2 du critère de coût global CG, il peut être globalement plus intéressant de développer certaines pièces de code de niveau de DAL faible, dans le calculateur DAL+ pour minimiser les échanges qui sont coûteux en temps de réponse, en mise en place d’interfaces de communication, et en maintenabilité.

Selon un troisième mode de réalisation CG3 du critère de coût global CG, il peut être globalement plus intéressant de développer certaines pièces de code de niveau de DAL faible, dans le calculateur DAL+ pour minimiser la complexité de l’ensemble, dans une optique de maintenance et d’évolution.

Selon un quatrième mode de réalisation CG4 du critère de coût global CG, il peut être globalement plus intéressant d’utiliser des librairies de code de niveau DAL+, dans le calculateur de DAL faible, pour minimiser l’utilisation des ressources du calculateur de cœur 4 DAL+.

Ensuite, dans la sixième étape 214, il est procédé à l’implémentation des calculs, des interfaces et de l’enchaînement des calculs entre les deux calculateurs 4 DAL+ et 6 DAL- suivant la répartition fonctionnelle et physique optimale des fonctions élémentaires OPT_RTE_FU(i) qui minimise le critère de coût global CG.

Dans le cas où le premier mode de réalisation CG1 du critère global CG est considéré, c'est-à-dire si seul le coût de développement supplémentaire du calculateur de cœur DAL+ est intégré, le procédé 202 allouera au calculateur de cœur DAL+ les fonctions élémentaires OPT_RTE_FU(2), OPT_RTE_FU(5), OPT_RTE_FU(7), OPT_RTE_FU(9) et OPT_RTE_FU(10). Les autres fonctions ne correspondant pas au périmètre fonctionnel critique d’un système de gestion de vol FMS ou d’un pilote automatique PA, ces fonctions ont plutôt vocation à être intégrées dans un calculateur DAL-.

Dans le cas où le deuxième mode de réalisation CG2 du critère global CG est considéré, c'est-à-dire seul le coût de développement d’interfaces est ajouté au coût supplémentaire de développement du calculateur DAL+, le procédé 202 décide de n’allouer au calculateur de cœur DAL+ que la dixième fonction élémentaire OPT_RTE_FU(10), la commande des automatismes correspondant à cette fonction étant critique pour l’avion, et devant rester gérée par un calculateur de haut niveau de DAL, c'est-à-dire DAL+. Il est à remarquer que dans ce cas le calcul de route et l’intégration de la trajectoire des autres fonctions élémentaires OPT_RTE_FU(2), OPT_RTE_FU(5), OPT_RTE_FU(7), OPT_RTE_FU(9) sera sans doute de moins bonne qualité et fiabilité si elle est développée dans un calculateur DAL- de DAL plus faible. Des procédures opérationnelles de réduction du risque devront être mises en place pour pallier ce défaut comme une surveillance graphique de l’écart, un calcul par le pilote, une confirmation par un calculateur au sol.

Si le niveau de criticité d’un moteur logiciel d’optimisation ou optimiseur (en anglais « solver ») de calcul de route sous contraintes est élevé, ou si pour des raisons d’interfaces ou de maintenabilité, il est souhaitable d’avoir une continuité dans le calcul de l’évitement, le procédé 202 pourra décider dans un troisième mode de réalisation d’allouer au calculateur 4 DAL+ la huitième fonction élémentaire OPT_RTE_FU(8) en plus des cinq autres, ce qui permettra d’avoir l’enchaînement des calculs des fonctions élémentaires OPT_RTE_FU(7), OPT_RTE_FU(8), OPT_RTE_FU(9) et OPT_RTE_FU(10) dans une même calculateur.

Enfin dans la septième étape 216, la fonction d’optimisation de route(s) sous contraintes, intégrée de manière optimale dans le système de navigation en minimisant le critère global CG est exécutée en couplant le calculateur de cœur DAL+ et l’au moins un calculateur périphérique DAL-.

Ainsi, le procédé 202 OPEN_OPT_RTE permet de garantir le niveau de développement strictement minimum de la fonction d’optimisation de routes sous contraintes tout en minimisant le coût de développement, d’intégrer dans le critère de coût les facteurs humains tel que le temps de prise en main de la fonction, le temps d’apprentissage et de formation du personnel (training), du temps de gestion des panne (i.e. temps de maintenance), de découpler les évolutions des deux calculateurs DAL+ et DAL-, et d’améliorer la maintenabilité (un étalement dans le temps des déploiements des différentes fonctions sans remise en cause des éléments clef structurants des systèmes que sont les « DAL+ »), et d’utiliser au mieux les concepts d’architecture ouverte qui commencent à voir le jour dans les calculateurs « DAL+ » tel que par exemple le FMS.

Suivant la Figure 5 et un mode d’implémentation de la fonction OPT_RTE intégrée selon le procédé d’intégration optimisée de la Figure 4, la fonction d’optimisation de route(s) sous contraintes 302 comprend, lorsqu’elle est exécutée par le système avionique embarqué intégrant un ensemble d’étapes.

Dans une première étape 304 et suivant un premier mode de réalisation, la sélection de l’élément de navigation qui correspond à l’exécution de la première fonction élémentaire OPT_RTE_FU(1 ) est mise en œuvre par le calculateur 6 DAL-. Cette sélection est réalisée par une interface avec l’opérateur, ici le pilote, qui manipule le calculateur 6 DAL- et choisit la route ou la portion de route ou de trajectoire sur laquelle il veut que le procédé d’optimisation OPT_RTE se déroule. Cela suppose que le calculateur 6 DAL- est abonné aux publications de route (plan de vol, trajectoire) du calculateur DAL+.

Dans une alternative, cette étape 304 est réalisée par le calculateur DAL+ qui dispose en effet déjà de la route et des prédictions, mais n’a pas forcément accès aux autres affichages (terrain, consignes compagnies ...)

En sortie de la première étape 306, une « route cible », constituée d’éléments de plan de vol ELT_PDV(1).... ELT_PDV(N_pdv), est fournie.

Eventuellement, la route cible contient également des éléments simplifiés de trajectoire ELT_TRAJ_SIMP(1) .. ELT_TRAJ_SIMP(N_traj), la trajectoire étant représentée par des éléments horizontaux (latéraux) et verticaux simplifiés puisque le calculateur DAL- ne dispose pas des services SERV_DAL+_PDV et SERV+_DAL_TRAJ permettant de calculer de manière fiable cette trajectoire.

Puis, dans une deuxième étape 306 et suivant le premier mode de réalisation, le calcul du plan de vol/trajectoire qui correspond à l’exécution de la deuxième fonction élémentaire OPT_RTE_FU(2) est mis en oeuvre par le calculateur de cœur 4 DAL+.

Dans une alternative, le calculateur périphérique 6 DAL- exécute cette deuxième étape 306.

On dispose ainsi en sortie de cette deuxième étape 306 d’un ensemble de N_traj éléments de trajectoire complets et de N_PDV éléments de plan de vol, comprenant leur position géographique en 2D au moins. Avantageusement, les prédictions en altitude, temps, météo et carburant sont liés à ces éléments. Si l’on fusionne ces éléments en une notion d’éléments intermédiaires « ELTJNT » (au nombre de N = N_traj + N_PDV), on obtient par exemple le tableau 1 ci-dessous suivant :

Tableau 1

Ensuite dans une troisième étape 308 et suivant le premier mode de réalisation, l’extraction des contraintes le long de la route cible qui correspond à l’exécution de la troisième fonction élémentaire OPT_RTE_FU(3) est mise en œuvre par le calculateur périphérique 6 DAL-.

Pour cela, connaissant les positions des éléments qui constituent la route, et éventuellement les temps de passage prédits pour les aléas dynamiques, le calculateur 6 DAL- vérifie si des éléments géométriques issus des calculateurs d'aléas et correspondent à des aléas ou dangers (en anglais hazards) tels que notamment des aléas météo, des aléas de terrain, des aléas de trafic, et des aléas de fermeture d’espaces aériens, sont rencontrés le long de cette route.

Ces aléas peuvent être représentés dans le calculateur par : des champs de vecteurs (vents par exemple ou trafics avions environnants) ; des champs de scalaires : température, balises de navigations, pistes (en anglais tracks) océaniques ; champs de surfaces : isobare, iso-givrage, fronts, pays traversés, terrain ; des champs de volumes : nuages, jet streams, zones de turbulences, espaces aériens, couloirs aériens (en anglais airways) à horaires.

Ces champs ont éventuellement une validité temporelle et les champs dont les coordonnées géographiques (et éventuellement temporels) sont à moins d’un seuil donné de la route seront extraits des calculateurs qui les déterminent.

Par exemple si la donnée est de type champs de surfaces, il s’agit de déterminer si un polygone représentant un élément de type surface croise la trajectoire dans le créneau horaire déterminé.

Prenons par exemple la surface définie par la couche d’atmosphère à 0° où le risque de givrage peut se produire en cas de traversée de cette couche dans une zone humide type nuage. Cette surface est constituée de points, désignés ici par SURF(lat, long, ait, heure) pour le givrage par exemple.

Suivant la Figure 6, la surface est composée de facettes contigües, chaque facette étant ici un triplet de points SURF. Il existe des fonctions classiques dans l’état de l’art qui déterminent une matrice de facettes approximant une surface.

Dans l’exemple de la Figure 7 et dans la troisième étape 308, il est déterminé si la facette, définie par le triplet [SURF(lat1,long1,Alt1) ; SURF(lat2,long2,Alt2) ; SURF(lat3,long3,Alt3) ] et décrite dans la Figure 6, croise le point TRAJ(i) qui correspond à un élément ELTJNT(k) dans le corridor traits pointillés de rayon R (déterminé par l’opérateur ou par configuration), et éventuellement dans le créneau horaire déterminé par [Prédicted_time(k) - Start Time ; Predicted_Time(k) + End Time], les variables Start_Time et end_Time étant configurables et permettant de ne considérer que les aléas ou dangers qui se produiront quand l’avion traversera temporellement l’aléa.

Ainsi, les distances (euclidiennes par exemple) entre chacun des trois points de chaque facette, et le point TRAJ(i) sont calculées.

Si au moins un des points de la facette se trouve à une distance du point TRAJ(i) inférieure à la borne du corridor (ici le rayon de la boule de rayon R centrée sur TRAJ(i)), alors la surface candidate est retenue, si l’heure d’occurrence des points candidats est dans la tranche horaire par [Heure(TRAJ(i)) + Start Time ; Heure(TRAJ(i)) + End Time].

Le procédé 302 retient toute la surface car on ne présente pas un « morceau » de nébulosité, mais la nébulosité entière dans le cas d’un nuage dangereux par exemple.

On dispose ainsi en sortie de N_CST éléments de contraintes CST(1) .. CST(NJnt).

Puis dans une quatrième étape 310 et selon le premier mode de réalisation, la mise en forme de la trajectoire pour affichage qui correspond à l’exécution de la quatrième fonction élémentaire OPT_RTE_FU(4) est mise en œuvre par le calculateur de cœur 4 DAL+.

Ensuite dans une cinquième étape 312 et selon le premier mode de réalisation, le calcul des espacements prédit et leur affichage qui correspondent à la cinquième fonction élémentaire OPT_RTE_FU(5) est mis en œuvre par le calculateur périphérique 6 DAL-.

Dans le premier mode de réalisation, il s’agit d’un espacement spatial, issu d’une discrétisation plus fine de la trajectoire en éléments ELTJNT, comparés aux contraintes.

On obtient ainsi un deuxième tableau discrétisé plus fin de N_fin éléments ELT_INT_FIN de trajectoire et leur distance « Spacing » par rapport aux différentes contraintes, présentes à moins de la distance R d’extraction comme décrit par le tableau 2 ci-dessous :

Tableau 2

Puis dans une sixième étape 314 et suivant le premier mode de réalisation, la fonction de « détection de conflit » entre un élément ELTJnt_Fin(m) et une contrainte CST(k) qui correspond à la sixième fonction élémentaire OPT_RTE_FU(6) est mise en œuvre par le calculateur 6 DAL-. Cette fonction de détection utilise par exemple l’algorithme suivant : Boucle de m = 1 à N_ELT_Fin sur les éléments ELT_INT_Fin(m)

• Pour tout k entre 1 et N_CST o Si || Spacing(m,CST(k)) || < Tolérance_spacing alors

Conflit détecté(m.k) = vrai o Sinon

Conflit détecté(m.k) = faux o Finsi • Fin boucle sur k

Fin Boucle sur m

Tolérance_Spacing sera une valeur gérée par DAL-.

Dans une alternative, la détection de conflit est effectuée en intégrant un critère temporel.

Dans le cas où un conflit est détecté, c'est-à-dire si Conflit détecté(m.k) = vrai, la trajectoire a un espacement prédit trop faible par rapport à une contrainte CST(k).

Dans une implémentation manuelle, les conflits seront affichés selon une symbologie particulière, et il sera laissé à l’opérateur le soin d’altérer la route cible pour s’éloigner de la contrainte.

Dans une implémentation automatisée, une septième étape 316 de résolution du conflit est mise en oeuvre par le calculateur périphérique 6 DAL- en exécutant des algorithmes classiques connus de l’état de l’art comme par exemple le parcours du tableau et l’éloignement des éléments ELT_INT_Fin(k) de la contrainte avec une valeur au moins égale au seuil.

Dans un mode de réalisation, cet éloignement sera fait sur la base de sélection d’éléments de la base de données de navigation (NAVDB) disponibles pour l’opérateur ou pour le système par l’exécution de la septième fonction élémentaire OPT_RTE_FU(7).

Dans un autre mode de réalisation, l’éloignement peut être réalisé en créant des points de plan de vol directement via leurs coordonnées géographiques.

Dans un autre mode de réalisation encore, l’éloignement peut être réalisé en déformant directement la trajectoire horizontale ou verticale, manuellement ou automatiquement, i.e. en déplaçant les éléments intermédiaires ELT_INT_fin.

Ces considérations sont également valides pour des espacements temporels en ralentissant/accélérant l’avion. Elles correspondent à l'exécution de la huitième fonction élémentaire OPT_RTE_FU(8).

On dispose ainsi en sortie de cette septième étape 316 d’une nouvelle « route cible » et un branchement est effectué sur la deuxième étape en utilisant la nouvelle « route cible ».

Dans le cas où suffisamment de conflits voire tous les conflits sont résolus et où la nouvelle « route cible » convient à l’opérateur, ce dernier pourra activer une huitième étape 318 d’exécution par le calculateur de cœur 4 DAL+ de la neuvième fonction élémentaire OPT_RTE_FU(9)).

Une validation par l’opérateur dans le système DAL+ sera effectuée après vérification des prédictions et de la résolution des conflits (passage dans le plan de vol dit « actif » de guidage de l’avion) via la dixième fonction élémentaire OPT_RTE_FU(10).

Cette nouvelle route cible fera l’objet d’une surveillance et suivi par le calculateur 6 DAL- en exécutant la onzième fonction élémentaire OPT_RTE_FU(11 ).

Avantageusement, le fait de n’effectuer dans le calculateur de navigation existant que le strict nécessaire à la fonction permet de maîtriser les performances de ce dernier en termes de temps de réponse.

Il permet aussi de préserver les capacités d’évolution du calculateur périphérique de mission (en termes de CPU / RAM / ROM) afin d’être en mesure d’adresser d’autres nouvelles fonctions.

Suivant la Figure 8 et une application du procédé 302 d’optimisation de route sous contraintes OPT_RTE, une carte géographique 402 de la France est représentée avec un aléa météorologique 404 sur le Sud Ouest. Une première route 412 d’un aéronef correspondant à un plan de vol prévu initialement est tracée sur la carte 402 comme devant croiser l’aléa météorologique 404. Le système embarqué de l’aéronef intégrant la fonction 302 d’optimisation de route(s) sous contraintes décrite dans la Figure 5 propose au pilote une deuxième route 414 de contournement de l’aléa 404 en affichant ladite deuxième route 414 sur la carte 402.

Claims (12)

1. REVENDICATIONS .1 Procédé d’intégration fonctionnelle et physique d’une application d’optimisation de route(s) d”un aéronef sous contraintes dans un système embarqué avionique, le système embarqué avionique comportant un calculateur de cœur numérique (4) DAL+, ayant un premier niveau de criticité DAL+, intégré dans une architecture initiale de calculateurs périphériques (6, 8, 10, 12, 14) et de bases de données ayant des deuxièmes niveaux de criticité DAL-, inférieurs ou égaux au premier niveau de criticité DAL+, et servant de serveur en hébergeant une première pluralité de services ouverts génériques Serv_DAL+(j), et un calculateur périphérique DAL- de gestion (6) de l’application d’optimisation de route(s) sous contraintes, ayant un deuxième niveau de criticité DAL- , inférieur ou égal au premier niveau de criticité DAL+, et servant de client en envoyant des requêtes de services au calculateur de cœur numérique (4) DAL+ et/ ou aux calculateurs périphériques (8, 10, 12, 14) et de bases de données de l’architecture initiale au travers d’un réseau de communications (20), caractérisé en ce que le procédé d’intégration fonctionnelle et physique de l’application d’optimisation de route(s) sous contraintes comporte les étapes consistant à : .- décomposer fonctionnellement (208) l’application d’optimisation de route(s) sous contraintes OPT_RTE en une deuxième pluralité de fonctions élémentaires OPT_RTE_FU(i) ; et .- à partir de la deuxième pluralité des fonctions élémentaires OPT_RTE_FU(i) déterminer (210) une première liste des fonctions élémentaires pouvant être exécutées en partie ou entièrement par au moins un service ouvert générique, et pour chaque fonction élémentaire une première sous-liste de service(s) ouvert(s) génériques ; et .- déterminer une répartition fonctionnelle et physique optimale (212) des fonctions élémentaires OPT_RTE_FU(i) au sein du système avionique embarqué sur l’ensemble des répartitions possibles qui rend minimal un critère de coût global CG, fonction de plusieurs paramètres dont au moins le coût de développement supplémentaire des fonctions élémentaires intégrées au sein du calculateur numérique de cœur DAL+ ; et réaliser (214) l’intégration de l’application d’optimisation de route(s) sous contraintes en implémentant effectivement les fonctions élémentaires et leur ordonnancement suivant la répartition fonctionnelle et physique optimale déterminée au sein du système avionique embarqué dans l’étape précédente de détermination de la répartition fonctionnelle et physique optimale des fonctions élémentaires.
2. 2. Procédé d’intégration fonctionnelle et physique d’une application d’optimisation de route(s) sous contraintes selon la revendication 1, dans lequel la répartition fonctionnelle et physique optimale (212) des fonctions élémentaires OPT_RTE_FU(i) au sein du système avionique embarqué sur l’ensemble des répartitions possibles est déterminée pour rendre minimale un premier critère CG1 de coût global qui prend seulement en compte le coût de développement supplémentaire des fonctions élémentaires intégrées au sein du calculateur numérique de cœur DAL+; et l’intégration de l’application d’optimisation de route(s) sous contraintes est réalisée (214) en implémentant effectivement les fonctions élémentaires et leur ordonnancement suivant la répartition fonctionnelle et physique optimale déterminée au sein du système avionique embarqué en utilisant le premier critère CG1. .3 Procédé d’intégration fonctionnelle et physique d’une application d’optimisation de route(s) sous contraintes selon la revendication 1, dans lequel la répartition fonctionnelle et physique optimale (212) des fonctions élémentaires OPT_RTE_FU(i) au sein du système avionique embarqué sur l’ensemble des répartitions possibles est déterminée pour rendre minimale un deuxième critère de coût global CG2 qui prend également en compte le coût de développement des interfaces de communication entre le calculateur de cœur DAL+ et les calculateurs périphériques, le coût en temps de réponse et le coût de maintenabilité pour minimiser les échanges de communication ; et l’intégration de l’application d’optimisation de route(s) sous contraintes est réalisée (214) en implémentant effectivement les fonctions élémentaires et leur ordonnancement suivant la répartition fonctionnelle et physique optimale déterminée au sein du système avionique embarqué en utilisant le deuxième critère CG2. .4 Procédé d’intégration fonctionnelle et physique d’une application d’optimisation de route(s) sous contraintes selon l’une quelconque des revendications 1 et 3, dans lequel la répartition fonctionnelle et physique optimale (212) des fonctions élémentaires OPT_RTE_FU(i) au sein du système avionique embarqué sur l’ensemble des répartitions possibles est déterminée pour rendre minimale un troisième critère de coût global CG3 qui prend également en compte le développement de certaines pièces de code de niveau de DAL faible dans le calculateur de cœur DAL+ pour minimiser la complexité de l’ensemble dans une optique de maintenance et d’évolution; et l’intégration de l’application d’optimisation de route(s) sous contraintes est réalisée (214) en implémentant effectivement les fonctions élémentaires et leur ordonnancement suivant la répartition fonctionnelle et physique optimale déterminée au sein du système avionique embarqué en utilisant le troisième critère CG3. .5 Procédé d’intégration fonctionnelle et physique d’une application d’optimisation de route(s) sous contraintes selon l’une quelconque des revendications 1 et 3 à 4, dans lequel la répartition fonctionnelle et physique optimale (212) des fonctions élémentaires OPT_RTE_FU(i) au sein du système avionique embarqué sur l’ensemble des répartitions possibles est déterminée pour rendre minimale un quatrième critère de coût global CG4 qui prend également en compte l’utilisation de librairies de code de niveau DAL+ dans le calculateur périphérique de niveau DAL- pour minimiser l’utilisation des ressources du calculateur de cœur DAL+ ; et .- l’intégration de l’application d’optimisation de route(s) sous contraintes est réalisée (214) en implémentant effectivement les fonctions élémentaires et leur ordonnancement suivant la répartition fonctionnelle et physique optimale déterminée au sein du système avionique embarqué en utilisant le quatrième critère CG4. .6 Procédé d’intégration fonctionnelle et physique d’une application d’optimisation de route(s) d’un aéronef sous contraintes selon l’une quelconque des revendications 1 à 5, comprenant en outre une étape supplémentaire, exécutée après avoir déterminée une répartition fonctionnelle et physique optimale des fonctions élémentaires OPT_RTE_FU(i) au sein du système avionique embarqué (2), et consistant en ce que les performances de application d’optimisation de route(s) sous contraintes sont vérifiées et évaluées par émulation ou simulation, et/ou Les performances des services initiaux mis en oeuvre sur le calculateur de cœur et les calculateurs périphériques sont vérifiées.
3. 7. Procédé d’intégration fonctionnelle et physique d’une application d’optimisation de route(s) d’un aéronef sous contraintes selon l’une quelconque des revendications 1 à 6, dans lequel le calculateur de cœur numérique (4) DAL+ héberge des services Serv_DAL+(j) de calculs de plan de vol, de trajectoire latérale et de prédictions temporelles selon un mode de guidage spécifié, utilisés pour la mise en œuvre d’une partie des fonctions élémentaires formant l’application d’optimisation de route(s) sous contraintes ; et le calculateur de cœur numérique (4) DAL+ est couplé à des calculateurs de pilotage de l’aéronef.
4. 8. Procédé d’intégration fonctionnelle et physique d’une application d’optimisation de route(s) d’un aéronef sous contraintes selon l’une quelconque des revendications 1 à 7, dans lequel la première pluralité de services génériques Serv_DAL+(j) comporte les services suivants: .- Calcul de la localisation de l’aéronef .- Insertion/Modification de plan de vol .- Calcul de trajectoire latérale .- Calcul de trajectoire verticale .- Calcul de performances de l’aéronef Guidage latéral Guidage vertical Guidage en vitesse Consultation de base de données de navigation Consultation de base de données de performance avion Consultation de base de données de configuration Consultation de base de données de déclinaison magnétique Affichage de la route et de la trajectoire Affichage des éléments de base de données.
5. 9. Procédé d’intégration fonctionnelle et physique d’une application d’optimisation de route(s) d’un aéronef sous contraintes selon l’une quelconque des revendications 1 à 8, dans lequel application d’optimisation de route(s) d’un aéronef sous contraintes comporte les fonctions élémentaires suivantes : Une première fonction élémentaire OPT_RTE_FU(1) de sélection d’un « route cible » ; Une deuxième fonction élémentaire OPT_RTE_FU(2) de calcul des prédictions le long du plan de vol et de la trajectoire Une troisième fonction élémentaire OPT_RTE_FU(3) de sélection des contraintes à appliquer ; Une quatrième fonction élémentaire OPT_RTE_FU(4) de sélection d’un espacement minimal à respecter ; Une cinquième fonction élémentaire OPT_RTE_FU(5) d’affichage de la route et des contraintes vers un opérateur ; Une sixième fonction élémentaire OPT_RTE_FU(6) de détection de conflit entre la route actuelle et les contraintes ; Une septième fonction élémentaire OPT_RTE_FU(7) d’affichage des éléments de navigation issus des bases de données autour de la trajectoire et/ou autour des contraintes ; Une huitième fonction élémentaire OPT_RTE_FU(8) de calcul d’évitement pour résoudre le conflit entre la route et la contrainte ; Une neuvième fonction élémentaire OPT_RTE_FU(9) d’intégration de l’évitement dans la route actuelle, destinée à être réutilisée par la deuxième fonction élémentaire OPT_RTE_FU(2) pour déterminer le nouveau plan de vol, la nouvelle trajectoire) ; Une dixième fonction élémentaire OPT_RTE_FU(10) d’exécution de la nouvelle route Une onzième fonction élémentaire OPT_RTE_FU(11) de monitoring de l’évolution des contraintes à intervalle régulier.
6. 10. Procédé d’intégration fonctionnelle et physique d’une application d’optimisation de route(s) d’un aéronef sous contraintes selon la revendication 9, dans lequel les fonctions élémentaires OPT_RTE_FU(2), OPT_RTE_FU(5), OPT_RTE_FU(7), OPT_RTE_FU(7) et OPT_RTE_FU(10) sont allouées au et implémentées dans le calculateur de cœur numérique DAL+ , tandis que les fonctions élémentaires restantes sont allouées et implémentées dans un calculateur périphérique DAL- du système intégrant l’application d’optimisation de route(s) sous contraintes.
7. 11. Procédé d’intégration fonctionnelle et physique d’une application d’optimisation de route(s) d’un aéronef sous contraintes selon la revendication 9, dans lequel .- la fonction élémentaire FIM_FU(10) qui correspond au service Serv_DAL+(4) pour le mode de guidage et l’élément de navigation sélectionnés est allouée au et implémentée dans le calculateur de cœur numérique 4 DAL+, tandis que les fonctions élémentaires restantes sont allouées et implémentées dans un calculateur périphérique DAL- du système intégrant l’application d’optimisation de route(s) sous contraintes.
8. 12. Procédé d’intégration fonctionnelle et physique d’une application d’optimisation de route(s) d’un aéronef sous contraintes selon la revendication 9, dans lequel les fonctions élémentaires OPT_RTE_FU(2), OPT_RTE_FU(5), OPT_RTE_FU(7), OPT RTE FU(7), OPT_RTE_FU(8) et OPT_RTE_FU(10) sont allouées au et implémentées dans le calculateur de cœur numérique DAL+ , tandis que les fonctions élémentaires restantes sont allouées et implémentées dans un calculateur périphérique DAL- du système intégrant l’application d’optimisation de route(s) sous contraintes.
9. 13. Procédé d’intégration fonctionnelle et physique d’une application d’optimisation de route(s) d’un aéronef sous contraintes selon l’une quelconque des revendications 9 à 12, dans lequel la première fonction élémentaire OPT_RTE_FU(1 ) consiste à sélectionner une «route cible» définie par un des éléments suivants : un aéroport cible, une route de référence cible, une portion de route de référence cible, une trajectoire de référence, un ensemble de points de passage définis par le pilote, un ensemble de points de passage et de balises de navigation sélectionné dans la base de données de navigation.
10. 14. Procédé d’intégration fonctionnelle et physique d’une application d’optimisation de route(s) d’un aéronef sous contraintes selon l’une quelconque des revendications 9 à 13, dans lequel la deuxième fonction élémentaire OPT_RTE_FU(2) calcule des prédictions le long du plan de vol et de la trajectoire, incluant notamment la position prédite en 3D et éventuellement en temps de l’aéronef le long de la trajectoire, la position prédite en temps permettant de gérer les contraintes dynamiques ou évolutives.
11. 15. Procédé d’intégration fonctionnelle et physique d’une application d’optimisation de route(s) d’un aéronef sous contraintes selon l’une quelconque des revendications 9 à 14, dans lequel la troisième fonction élémentaire OPT_RTE_FU(3) sélectionne des contraintes à appliquer, ces contraintes étant définies par des formes géométriques géographiques ou des représentations visuelles brutes telles que des volumes modélisant notamment des nuages, des espaces aériens 3D et des obstacles), des surfaces en 3D notamment de terrain, des surfaces en 2D notamment des frontières et des changements d’espaces aériens.
12. 16. Système embarqué avionique configuré pour mettre en œuvre une application d’optimisation de route(s) d’un aéronef sous contraintes et l’intégrer fonctionnellement et physiquement, le système embarqué avionique comportant un calculateur de cœur numérique (4) DAL+, ayant un premier de criticité DAL+, intégré dans une architecture initiale de calculateurs périphériques (6, 8, 10, 12, 14) et de bases de données ayant des deuxièmes niveaux de criticité DAL- , inférieurs ou égaux au premier niveau de criticité DAL+, et servant de serveur en hébergeant une première pluralité de services ouverts génériques Serv_DAL+(j), et un calculateur périphérique DAL+ de gestion (6) de l’application d’optimisation de route(s) sous contraintes, ayant un deuxième niveau de criticité DAL-, et servant de client en envoyant des requêtes de services au calculateur de cœur numérique (4) DAL+ et/ou aux calculateurs périphériques (8, 10, 12, 14) et bases de données périphériques de l’architecture initiale au travers d’un réseau de communications (20), l’application d’optimisation de route(s) sous contraintes OPT_RTE étant décomposée en une pluralité de fonctions élémentaires OPT_RTE_FU(i) réparties physiquement entre le calculateur de cœur numérique DAL+ et le calculateur périphérique de gestion DAL- suivant un schéma de répartition optimal déterminé par le procédé d’intégration défini selon l’une quelconque des revendications 1 à 15, le calculateur périphérique de gestion (6) DAL- étant configuré pour supporter une application parmi : une IHM, une IHS intégrée, une CMU un TCAS un TAWS un EFB une tablette un TRAFFIC COMPUTER une partition générique dédiée, et le calculateur de cœur numérique (4) DAL+ étant configuré pour supporter une application parmi : un système de gestion de vol FMS, un Pilote Automatique (PA) un système FMGS combinant les fonctions FMS et PA.