SYSTEME AUTOMATISE AUX TEMPS DE REPONSE DETERMINISTES La présente
invention se rapporte à un système automatisé ou semi-automatisé, en particulier un système de navigation, aux temps de réponse déterministes. La part croissante de l'automatisation depuis vingt-cinq ans dans l'aéronautique tant civile que militaire, conduit de plus en plus l'équipage à utiliser des systèmes électroniques, et de moins en moins à influer directement sur les commandes primaires de pilotage de l'aéronef. Cette tendance s'est accentuée ces quinze dernières années avec la généralisation des systèmes de gestion du vol (FMS : Flight Management System) embarqués. Un système de gestion du vol est constitué de différents composants fonctionnels qui permettent à l'équipage de programmer un vol à partir d'une base de données de navigation.
Le système calcule alors une trajectoire latérale et verticale permettant de rejoindre la destination du plan de vol à partir des caractéristiques de l'aéronef et des données fournies par l'équipage et l'environnement du système. Les fonctions de positionnement et de guidage collaborent pour aider le pilote à rester sur cette trajectoire. Les fonctions d'interface avec l'équipage et avec le sol permettent de mettre l'homme dans la boucle de la navigation car il est seul responsable du déroulement du vol. On a représenté en figure 1 le synoptique d'un FMS. Il comporte essentiellement les fonctions suivantes : HMI (interfaces homme-machine), GUIDANCE (guidage), LOC (localisation), PRINTER (imprimantes), PRED (prédictions), NAVDB (bases de données de navigation), DATALINK (liaison numérique sol-air), TRAJ (définition de trajectoire), FPLN (plan de vol), IO (entrées et sorties), DUAL (gestion de redondance) et SPARE , fonction existant dans certains FMS, mais avec une fonctionnalité différente de celle du SPARE de l'invention, et qui a donc été représentée à l'extérieur du FMS proprement dit, et qui est décrite ci-dessous en référence à l'invention. Un système de gestion du vol concentre un grand nombre de données : - issues de capteurs (IRS, GPS, VHF) pour la navigation, - issues de bases de données (bases de données de navigation NAVDB) pour élaborer le plan de vol électronique, - issues de bases de données de performances pour élaborer les prédictions le long du plan de vol, - issues d'entrées manuelles effectuées par l'équipage (en général pour initialiser les calculs) ou d'entrées automatiques par liaison de données numériques sol/bord (Datalink) venant de la compagnie ou de centres de contrôle (ATC) Un système de gestion du vol est donc extrêmement complexe, en particulier de par la quantité d'informations qu'il traite. Dans le cas particulier des informations venant de l'équipage, beaucoup de celles-ci servent à modifier le plan de vol de référence. Ces modifications sont de natures très 10 différentes mais obéissent à un même schéma directeur. On a représenté en figure 2 le bloc-diagramme simplifié des différentes étapes de révision d'un plan de vol. Les principales fonctions mises en oeuvre sont représentées en haut de la figure, mais il est bien entendu que d'autres fonctions peuvent être mises en oeuvre. Ces fonctions sont : une interface homme-machine HMI, le calculateur de plan de vol FPLN (qui 15 est un sous-ensemble du calculateur FMS), la base de données de navigation NavDB, et la prédiction de trajectoire TRAJ/PRED. On va expliciter les différentes étapes principales d'un processus de révision d'un plan de vol en référence à la figure 2, en la considérant de haut en bas, à savoir dans l'ordre chronologique. Lorsque le pilote P désire effectuer une révision, il entre un ordre (P1) sur son 20 interface IHM, qui le transmet à FPLN (1). Ce dernier envoie une requête (2) à la base de données NavDB, qui effectue une recherche dans ses données (3) et lui envoie le résultat (4). FPLN effectue un chaînage de la modification dans le plan de vol (5). Si la modification est achevée correctement, FPLN envoie une information correspondante Statut OK (6) à l'interface HMI pour affichage au pilote. D'autre part, FPLN communique au système de 25 prédiction TRAJ/PRED le nouveau plan de vol (7), c'est-à-dire le plan de vol incorporant la modification correspondant à l'ordre de révision 1. Ce système de prédiction calcule ses prédictions à court terme (8) et en communique le résultat (9) à l'interface HMI. Cette dernière affiche la mise à jour (10).Le temps mis pour effectuer les étapes 1 à 10 est le temps de réponse du système FMS pour effectuer une révision du plan de vol. 30 En outre, la fonction TRAJ/PRED calcule les prédictions de trajet à long terme, jusqu'à la destination du vol en cours (11). Une fois ce calcul effectué, la fonction TRAJ/PRED envoie (12) à l'interface HMI la version disponible des prévisions de vol à long terme (tenant compte de la révision en question). Enfin, l'interface HMI effectue la mise à jour de l'affichage des informations de prévision à long terme (13). Le temps mis pour effectuer les étapes 10 à 13 est le temps de mise à jour de l'affichage. Les quatre actions 3, 5, 8 et 10 identifient les parts variables dans la famille des opérations de révision du plan de vol. La première (3), qui correspond à une recherche en base de données de navigation, consomme un temps dépendant du type de donnée recherchée et de la taille de la base de données. La seconde (5), qui correspond à la prise en compte réelle de la modification demandée par le pilote, dépend du type de modification et de la taille des données reçues de la base de données. La troisième (8), qui correspond au calcul de la trajectoire de référence et des prédictions à court terme de vitesse, d'altitude, de vitesse, de temps, de fuel, de température, de vent,... ) jusqu'à une distance proche de l'aéronef (quelques points ou dizaines de miles nautiques), dépend de la géométrie du plan de vol et du contexte de l'aéronef. La quatrième (10), qui correspond à la mise à jour des informations affichées sur les écrans de l'opérateur, dépend principalement des informations qu'a choisi d'afficher l'opérateur et de la taille du plan de vol.
Les deux étapes 11 et 13 identifient les parts variables lors de la mise à jour de la trajectoire et des prédictions. La première (11), qui correspond au calcul de la trajectoire de référence et des prédictions jusqu'à la destination du plan de vol, dépend de la distance à couvrir ainsi que du nombre d'opérations procédurales à effectuer jusqu'à celle-ci. Pour chacune des parts variables, du fait que certains sous-systèmes du FMS sont périodiques (c'est-à-dire qu'ils réalisent une mise à jour de leurs données de façon répétitive), le temps pris réellement par les sous-systèmes non périodiques n'est pas déterministe (ce temps est tout de même borné). Lorsque la séquence de mise à jour de l'affichage comportant les étapes 11 à 13 est très rapide, on arrive à l'effet bien connu de clignotement de l'affichage.
Selon l'art antérieur, la démonstration des capacités d'évolution du système était faite à partir du développement d'un consommateur de ressources centralisé dédié (appelé SPARE dans la présente description), qui était adapté au fur et à mesure de l'ajout de nouvelles fonctionnalités. Certaines ressources n'étaient pas utilisées car la démonstration de leur disponibilité était un résultat explicite des outils de développement. Rien n'était fait pour augmenter le déterminisme du système (à part des solutions réglées au cas par cas, sans démarche globale) ni pour supprimer l'effet de clignotement .
La présente invention se rapporte à un système automatisé, en particulier un système assurant des fonctions vitales, tel qu'un FMS, ce système se composant de plusieurs sous-systèmes fonctionnels dont le temps de traitement d'ordres extérieurs est variable, ce système pouvant être sujet à des évolutions, et elle a pour objet un dispositif permettant de déterminer quel(s) est (sont), dans ce système, le(s) sous-ensemble(s) qui l'empêche(nt) d'être déterministe, en vue de corriger le comportement de ce(s) sous-système(s) et de sécuriser ce système. Le système automatisé conforme à l'invention, du type comportant plusieurs sous-systèmes dont le temps de traitement d'informations extérieures est variable, mais doit être limité dans sa durée, est un système dont le temps de réponse à une même sollicitation est indépendant du volume de données internes et externes manipulées et des évolutions fonctionnelles à venir, et il est caractérisé en ce qu'il comprend dans chacun de ses sous-systèmes à temps de traitement variable et/ou susceptibles d'évoluer un sous-système consommateur explicite de ressources simulant un temps de traitement dont la durée est au moins égale à la différence entre la durée de traitement maximale prévisible en fin de vie du sous-système qui l'incorpore et la durée de traitement actuelle, et un sous-système de chronométrage déclenché par un ordre de traitement dont la durée de chronométrage est au moins égale au temps de traitement actuel dudit ordre augmentée du temps déterminé par le sous-système consommateur explicite de ressources . . La présente invention sera mieux comprise à la lecture de la description détaillée d'un exemple de mise en oeuvre, pris à titre d'exemple non limitatif et illustré par le dessin annexé, sur lequel : la figure 1, déjà partiellement décrite ci-dessus, est un bloc-diagramme d'un système de gestion de vol FMS, et comportant le dispositif de l'invention, la figure 2, déjà décrite ci-dessus,, est un chronogramme des différentes étapes mises en oeuvre pour prendre en compte un ordre de révision d'un plan de vol, et la figure 3 est un chronogramme similaire à celui de la figure 2, mais avec intervention des sous-systèmes SPARE et TIMER conformément à l'invention. L'invention est décrite ci-dessous en référence à son application à un système de navigation d'aéronef (FMS), mais il est bien entendu qu'elle n'est pas limitée à cette seule application, et qu'elle peut être mise en oeuvre dans tout système automatisé ou semiautomatisé comportant plusieurs sous-systèmes fonctionnels dont le temps de traitement d'ordres extérieurs est variable, et qui peut être sujet à des évolutions. Comme représenté en figure 1, le dispositif de l'invention comporte, outre le FMS, un sous-système SPARE consommateur explicite des ressources, ce sous-système SPARE étant combiné avec un sous-système TIMER . Le service TIMER est un service commun dans un système embarqué, mais son utilisation pour maîtriser les temps de réponse du FMS est une caractéristique importante de l'invention.. Le sous-système SPARE est paramétrable pendant le développement du système FMS pour consommer le temps de calcul prévisible à à l'échéance fin de vie du système dont il est chargé de déterminer le temps de traitement des ordres extérieurs. Selon la présente invention, ce sous-système SPARE est réparti dans chacun des autres sous-systèmes du FMS qui sont susceptibles d'évoluer, afin que, pendant toute la durée de vie du FMS, son temps de réponse soit le même quelles que soient ces évolutions. . Cela permet en particulier de rendre le système FMS plus déterministe et de sécuriser son comportement à la certification et non pas seulement lors des livraisons intermédiaires de ces sous-ensembles. Le sous-système TIMER du dispositif de l'invention est un dispositif de chronométrage déterminant un certain laps de temps (typiquement de l'ordre de 1 seconde) à l'écoulement duquel il envoie un signal au sous-système SPARE pour l'autoriser à répondre aux informations incidentes, ce qui permet de ne pas ralentir en conditions normales d'exploitation le système FMS en lançant des actions devant de toute façon être annulées (effet dit de clignotement ). Lorsque le laps de temps surveillé par le TIMER est écoulé et que les sous-systèmes concernés par ce laps de temps n'ont pas réagi, une information dédiée peut être sauvegardée par le système FMS, permettant a posteriori de comprendre le contexte du dépassement afin de le reproduire pour investigation et correction éventuelle. Cette procédure s'appuie sur une technologie d'investigation propriétaire active ou passive selon le contexte d'utilisation. Les deux sous-systèmes du dispositif de l'invention (SPARE et TIMER) permettent d'analyser de façon générique le comportement du FMS en cours de développement et de suivre le temps de calcul non consommé lors d'un scénario. Pour utiliser les résultats de ces analyses, on classe les scénarios opérationnels en familles cohérentes de l'utilisation qu'en fait l'opérateur. Il est alors possible de suivre un sous-ensemble des scénarios pour contrôler la pertinence des allocations de ressources et la conformité de la réalité avec ces allocations. Le sous-système SPARE est appelé dans le contexte du sous-système devant avoir un comportement déterministe (par exemple le gestionnaire de base de données de navigation mentionné dans l'exemple décrit ci-dessus en référence à la figure 2). Ce sous-système est capable de consommer un temps précis, en fonction du contexte de la plate-forme. Le degré de précision est de l'ordre d'un cycle du système (un temps de réponse typique à une action du pilote est de l'ordre de la seconde, alors que le temps de cycle est de l'ordre de 50 ms). Le sous-système SPARE représente globalement les capacités d'évolution des différents sous-systèmes synchrones à un degré de précision plus important, car ils consomment un temps largement inférieur au temps d'un cycle. Cette précision est de l'ordre de 1% d'un cycle. Le sous-système TIMER est, dans un premier temps, lancé à l'appel d'une séquence de traitement relativement court, par exemple de l'ordre de quelques centaines de millisecondes (tel que celui décrit ci-dessus en référence à la figure 2). Si le laps de temps qu'il chronomètre n'est pas consommé à la fin du traitement, la fourniture du résultat de cette séquence attend que la durée soit écoulée. Pendant ce temnps, des traitements plus longs sont lancés, par exemple de plusieurs secondes. Si ces traitements longs sont achevés au moment identifié comme la fin de la séquence, l'affichage du résultat de cette séquence courte sera plus complet, sinon les résultats intermédiaires sont présentés, mais le pilote dispose d'un temps de réponse déterministe. Si le service TIMER ne supprime pas tous les clignotements possibles (le temps de réponse attendu par le pilote étant inférieur au temps nécessaire au calcul complet) il les supprime dans la phase la plus critique d'un vol commercial : la phase d'approche.
Si la séquence de traitement n'est pas terminée lorsque le laps de temps du TIMER est achevé, l'information de cette anomalie est enregistrée, car c'est un problème devant être investigué par les équipes de développement. En conclusion, la solution de l'invention propose d'harmoniser les temps de réponse du système FMS entre les différents scénarios d'une même famille, au fur et à mesure des évolutions du produit et de son contexte d'utilisation. L'opérateur (le pilote en l'occurrence) dispose ainsi d'un système qui répond de façon complètement déterministe aussi bien dans l'opération la plus simple mettant en oeuvre une base de données de navigation que dans des opérations plus complexes de versions ultérieures, par exemple avec une base de données ayant doublé de taille. L'équipe de développement du produit n'a pas à suivre tous les cas possibles pour maîtriser les performances du produit, car il lui suffit de relever les dépassements des temps de réponse des différents sous- systèmes du FMS, pris chacun séparément (cas où l'échéance du TIMER arrive avant la fin du traitement), et y remédier le cas échéant. Sur le chronogramme de la figure 3, établi de la même façon que celui de la figure 2, lorsque le pilote P désire effectuer une révision, il actionne (21) l'IHM qui envoie simultanément un ordre d'armement (21A) au TIMER et un ordre de révision (21B) à FPLN.
L'ordre d'armement envoyé au TIMER est destiné à lui faire décompter un temps suffisant pour permettre au sous-système TRAJ/PRED d'effectuer un calcul de prédictions à long terme. Dès réception de l'ordre 21B, FPLN envoie une requête (22) à NavDB dont la sous-fonction SPARE commence par décompter un laps de temps SPARE-1 destiné à tenir compte des évolutions fonctionnelles de NavDB. Au bout de ce laps de temps, la base de données NavDB effectue une recherche dans ses données (23), puis son sous-système SPARE décompte un autre laps de temps SPARE-2 (destiné à tenir compte de l'évolution prévisible de la taille de la base de données) et envoie le résultat (24) à FPLN qui effectue un chaînage du plan de vol (25) pour intégrer les données que vient de lui envoyer NavDB dans le plan de vol courant. On notera qu'en variante, les laps de temps SPARE-2 et SPARE-3 peuvent être regroupés en en laps de temps unique, prenant place avant ou après l'étape 23 de recherche. La sous-fonction SPARE de FPLN décompte alors un laps de temps SPARE-3 destiné à tenir compte des temps de réponse entre différents types de révisions. Si la modification du plan de vol est achevée correctement, FPLN envoie une information correspondante Statut OK (26) à l'interface HMI pour affichage au pilote de ce statut. D'autre part, FPLN communique au système de prédiction TRAJ/PRED le nouveau plan de vol (27), c'est-à-dire le plan de vol incorporant la modification correspondant à l'ordre de révision 21B. Le sous-système SPARE intégré au système de prédiction décompte un laps de temps SPARE-4 , puis TRAJ/PRED effectue un calcul de prédictions à court terme (28) et signale (29) à HMI qu'il dispose d'un nouveau projet de plan de vol mis à jour à court terme. Toutefois, l'interface HMI attend l'écoulement d'un laps de temps TIMER-1 tenant compte de l'écoulement de tous les laps de temps des différents sous-systèmes SPARE (seuls les laps des temps relatifs aux sous-systèmes FPLN, NavDB et TRAJ/PRED sont mentionnés en figure 3). Au bout de ce laps de temps TIMER-1, le sous-système TIMER signale (30) à HMI qu'il peut libérer l'affichage des prédictions à court terme (qui lui ont été communiquées en 29). HMI affiche donc alors ces prédictions à court terme. (31). De façon typique, le laps de temps entre l'envoi de l'ordre 21/21A et l'affichage 31 est de l'ordre de 1 seconde. Entre-temps, à la suite du calcul 28, le sous-système SPARE du sous-système TRAJ/PRED déclenche une autre temporisation SPARE-5 avant d'entamer les calculs de prédictions à long terme (32). On notera que dans l'exemple de la figure 3, l'ordre de libération d'affichage 30 est émis après le début du calcul 32, mais il peut aussi bien être émis avant ce début. Le calculateur de HMI, après avoir débuté l'affichage des prédictions à court terme, envoie un ordre (33) au TIMER pour que celui-ci entame le décompte d'un laps de temps TIMER-2 (d'environ 3 secondes, par exemple) destiné à supprimer l'effet de clignotement précité. Pendant le décompte de ce laps de temps, à la fin du calcul 32, le sous-système TRAJ/PRED envoie à HMI (34) la version à long terme des calculs de prédictions. A l'écoulement de TIMER-2, le sous-système TIMER envoie un signal (35) à l'interface HMI, l'autorisant à afficher les prédictions à long terme, qui sont alors effectivement affichées (36).15