FR2967517A1 - Banc de developpement d'application logicielle aeronautique comportant une interface graphique interactive - Google Patents

Abstract

Le domaine général de l'invention est celui des bancs de développement d'application logicielle aéronautique comprenant au moins un atelier logiciel " graphique " qui comporte des moyens informatiques traitant des outils logiciels servant à créer, simuler ou intégrer des fonctions graphiques ou " widget " au niveau d'un équipement de visualisation et un atelier logiciel " traitement de logique " qui comporte des moyens informatiques traitant des outils logiciels servant à créer, simuler ou intégrer des fonctions logiques permettant de modifier le contenu des fonctions graphiques en fonction d'événements entrants au niveau du même équipement de visualisation. Le banc selon l'invention comporte une interface fonctionnelle comportant des " plugs " fonctionnels, c'est-à-dire des données d'entrée ou de sortie, à chaque " plug " fonctionnel est associé d'une part, un paramètre d'une fonction graphique et d'autre part un paramètre d'une fonction logique.

Description

Banc de développement d'application logicielle aéronautique comportant une interface graphique interactive Le domaine de l'invention est celui des bancs de développement d'application logicielle aéronautique comportant une interface graphique interactive. Les cockpits d'aéronefs modernes comportent un ensemble de dispositifs de visualisation interactifs qui permettent de visualiser, de commander et de modifier l'ensemble des paramètres nécessaires au pilotage, à la navigation et plus généralement à l'accomplissement de la mission. Le nombre de paramètres à gérer est considérable et il existe une multitude de représentations graphiques possibles de ces paramètres.

L'application logicielle aéronautique est réalisé sur un banc de développement informatique dans un environnement informatique de type « PC ». Le banc de développement informatique comprend deux « ateliers logiciels» principaux. On désigne par atelier de génie logiciel ou « AGL » un ensemble de programmes informatiques permettant eux-mêmes de produire des programmes informatiques de manière industrielle. Le banc de développement comprend deux ateliers logiciels qui sont : - Atelier logiciel « graphique » qui traite des outils logiciels servant à créer, simuler ou intégrer des fonctions graphiques au niveau d'un équipement de visualisation ; Atelier logiciel « traitement de logique » qui traite des outils logiciels servant à créer, simuler ou intégrer des fonctions logiques au niveau d'un équipement de visualisation. Le développement d'une application logicielle aéronautique avec interface graphique interactive se réalise en deux étapes : - Création de l'aspect « statique » d'une « page » graphique. On entend par page graphique un écran d'affichage ou une partie d'écran d'affichage. L'atelier logiciel « graphique » permet de placer des « widgets » sur cette page et de définir ses propriétés d'initialisation. On entend par widget une unité logicielle associée à une représentation graphique et un comportement permettant à l'équipage soit de recevoir des informations, soit au moyen d'une interface homme-machine ou « IHM » de donner des instructions.

D'un point de vue logiciel, chaque widget propose des interfaces techniques de type « clic clown », « clic up », « change color »...permettant la production d'événements et la modification de ce widget ; Développement logiciel de la logique de traitement permettant de modifier le contenu de la page en fonction d'événements entrants. Cette logique de traitement est généralement réalisée en code manuel. Le développeur utilise les interfaces techniques du widget pour modifier l'apparence graphique de la page.

Les figures 1 et 2 illustrent le périmètre d'un banc de développement d'application logicielle aéronautique avec interface graphique interactive. Sur la figure 1, on a représenté le banc de développement fonctionnant sur micro-ordinateurs de type PC. Il est à noter que sur cette figure 1, les moyens matériels de type PC ont été représentés par deux PC autonomes et séparés. II s'agit bien entendu d'une représentation symbolique. Les moyens matériels peuvent être un même micro-ordinateur ou une pluralité de micro-ordinateurs. Il comporte un atelier logiciel graphique ou ALG et un atelier de traitement de logique ou ATL, ces deux ateliers générant du code exécutable ou CODEX. Dans un second temps, ce code exécutable est implanté dans un calculateur EU qui envoie les paramètres d'affichage des pages numériques P à un écran de visualisation D et reçoit des notifications d'événements des interfaces homme-machine de cet écran de visualisation D. Ce calculateur est interfacé avec l'ensemble du système avionique CDS et des interfaces homme-machine IHM représentées par une « souris » informatique sur la figure 2.

Lorsque le client final reçoit le système de visualisations, l'interface Homme-Machine fournie peut ne pas correspondre aux attentes soit parce que les spécifications initiales étaient imprécises ou erronées, soit parce qu'elles ont évolué en fonction des remarques et des retours d'expérience des utilisateurs. Le client modifie alors ses spécifications, ce qui implique un second développement des pages d'IHM. Or, toute évolution de la définition statique des pages graphiques a un impact sur le code.

En effet, chaque widget possède un identifiant. Pour modifier le paramètre d'un widget, le logiciel doit indiquer l'identifiant du widget et l'identifiant du paramètre modifié. Si l'identifiant du widget change dans la définition des pages d'IHM, on doit également modifier cet identifiant dans le code du logiciel qui dialogue avec l'IHM. De la même façon, si on souhaite changer le type du widget utilisé, la logique de traitement qui utilise ce widget doit utiliser d'autres interfaces qui sont celles du nouveau widget. Bien entendu, ces changements ont un impact sur le code de la logique de traitement.

Pour résumer, le code de la logique de traitement dépend donc fortement de l'interface technique de l'atelier logiciel « graphique ». Par conséquent, dans les systèmes actuels, il est nécessaire de modifier simultanément les pages graphiques et la logique de traitement. Cette façon de faire présente plusieurs défauts exposés ci-dessous : Multiplication du nombre de lignes de code modifiées, sources de régressions fonctionnelles et d'erreurs ; Impact sur l'architecture fonctionnelle. Le design initial n'était peut-être pas prévu pour respecter les nouvelles contraintes imposées dans les spécifications. L'impact sur l'architecture du système peut alors être important, ainsi que l'effort de développement logiciel pour modifier ce design ; Surcoûts importants. Chaque modification peut engendrer des coûts importants liés aux activités de certification de code qui sont fondamentales dans le domaine aéronautique.

Le banc selon l'invention permet de pallier à ces différents inconvénients. L'invention repose essentiellement sur deux principes techniques qui sont : Remplacer le code manuel de la logique de traitement par un atelier 30 logiciel générant du code automatique à partir d'une modélisation de cette logique ; Coupler l'atelier logiciel « graphique » avec l'atelier logiciel « traitement de logique » par un dialogue fonctionnel et non pas technique. Ce couplage est indépendant des interfaces techniques de 35 chaque atelier logiciel. Ce couplage est réalisé grâce à des « plugs » fonctionnels introduits aux frontières des deux ateliers logiciels pour leur permettre de dialoguer suivant un langage commun. Dans la suite de la description, le terme de « plug » désigne une donnée d'interface d'entrée ou de sortie.

Plus précisément, l'invention a pour objet un banc de développement d'application logicielle aéronautique comprenant au moins un, atelier logiciel « graphique » qui comporte des moyens informatiques traitant des outils logiciels servant à créer, simuler ou intégrer des fonctions graphiques ou « widget » au niveau d'un équipement de visualisation et un atelier logiciel « traitement de logique » qui comporte des moyens informatiques traitant des outils logiciels servant à créer, simuler ou intégrer des fonctions logiques permettant de modifier le contenu des fonctions graphiques en fonction d'événements entrants au niveau du même équipement de visualisation, caractérisé en ce que le banc comporte une interface fonctionnelle comportant des « plugs » fonctionnels, c'est-à-dire des données d'entrée ou de sortie, à chaque « plug » fonctionnel est associé d'une part, un paramètre d'une fonction graphique et d'autre part un paramètre d'une fonction logique. Avantageusement, le banc comporte également : des moyens informatiques permettant de créer le code graphique et le code logique ainsi que les différentes interfaces de programmation permettant de créer et de modifier les fonctions graphiques ; une interface de couplage comportant une structure de variables d'échange basée sur les noms des « plugs », ces variables étant manipulées à la fois par le code logique et par le code graphique.

L'invention sera mieux comprise et d'autres avantages 30 apparaîtront à la lecture de la description qui va suivre donnée à titre non limitatif et grâce aux figures annexées parmi lesquelles : La figure 1 représente le banc de développement d'application logicielle aéronautique avec interface graphique interactive selon l'art antérieur ; La figure 2 représente un système avionique comportant le code exécutable développé selon l'art antérieur ; La figure 3 représente l'ensemble du banc de développement d'application logicielle aéronautique selon l'invention ; La figure 4 représente les liaisons existant au sein du banc de développement d'application logicielle aéronautique selon l'invention.

Les figures 3 et 4 représentent l'ensemble du banc de développement d'application logicielle aéronautique selon l'invention. Il comporte un atelier logiciel « graphique » ou ALG et un atelier de « traitement de logique » ou ATL, ces deux ateliers générant du code exécutable ou CODEX sur les figures. Sur la figure 4, on a représenté le banc de développement fonctionnant sur micro-ordinateurs de type PC. II est à noter que sur cette figure 4, les moyens matériels de type PC ont été représentés par deux PC autonomes et séparés. Il s'agit bien entendu d'une représentation symbolique. Les moyens matériels peuvent être un même micro-ordinateur ou une pluralité de micro-ordinateurs. Le dialogue entre l'atelier logiciel « graphique » ou ALG et l'atelier de « traitement de logique » ou ATL est assurée au moyen d'une interface fonctionnelle ou « IF », la liaison entre les codes exécutables étant assurée au moyen d'une interface technique ou « IT ». L'interface fonctionnelle est définie en fonction des besoins utilisateurs et non plus en fonction des objets. Lorsqu'il définit son interface homme-machine ou IHM, le designer donne des noms « fonctionnels » aux paramètres de ses objets interactifs. Un nom fonctionnel est unique et correspond donc à un couple « identifiant de widget, identifiant de paramètre ». La dépendance technique disparaît au profit de cette interface fonctionnelle. Si la fonction du message reste la même, on peut alors changer de widget ou changer de paramètre, ceci n'a aucun impact sur le logiciel développé, qui ne reçoit que des messages fonctionnels. L'atelier logiciel « graphique » génère le code d'interface des widgets de chaque page affichée. Ce code est purement technique et permet de modifier les paramètres de chaque widget comme la palette de couleurs, la position, les labels utilisés...

L'atelier logiciel « graphique » positionne des « plugs » sur chaque paramètre de chaque widget. Un plug correspond à un nom unique. Ainsi, chaque événement fonctionnel peut être positionné sur n'importe quel widget. C'est son rôle fonctionnel qui importe, et non pas l'objet qui l'a produit. Les plugs positionnés sont utilisés par le générateur de code pour produire ces événements fonctionnels, en entrée ou en sortie du code graphique en gérant la correspondance avec l'interface technique. L'atelier logiciel « traitement de la logique » permet de modéliser les algorithmes des pages d'interface homme-machine au travers de diagrammes d'états/transitions. Les événements d'entrée de l'atelier logiciel « traitement de la logique » portent le même nom que ceux définis dans l'atelier logiciel graphique. Le couplage entre l'atelier logiciel « graphique » et l'atelier logiciel «traitement de la logique » permet donc de définir des lois d'animation logiques pour l'évolution graphique de la spécification en réagissant aux différents évènements. L'interface fonctionnelle ou de couplage met en place une structure de variables d'échange basée sur les noms des plugs. Ces variables sont manipulées à la fois par le code logique et par le code graphique qui met à jour les attributs des différents widgets. Pour mettre en place ce couplage, la règle suivante doit être respectée : les valeurs d'entrée du projet « logique » et respectivement les valeurs de sortie doivent avoir les mêmes noms que les « outputs » de la spécification graphique de l'atelier logiciel « graphique » et respectivement les inputs. II est alors possible de générer l'interface de couplage Cette interface de couplage comporte notamment deux structures qui sont : ensemble de variables portant les noms des outputs de l'atelier logiciel « graphique » ; ensemble de variables portant les noms des inputs de l'atelier logiciel « graphique ». Un code exécutable est ensuite généré, cet exécutable contenant : - Le code graphique ; Le code logique ; Les différentes interfaces de programmation d'application ou « API » , Les variables d'échange de l'interface de couplage ; Un point d'entrée pour l'utilisateur.

Un exemple simple permet de mieux faire comprendre le fonctionnement de l'invention. On souhaite spécifier un bouton de commande portant l'identifiant « 28 » de façon que, lorsque l'on « clique » dessus, l'action intitulée 10 « REQUEST RUNWAY LENGTH » soit traitée. Dans les bancs selon l'art antérieur, on doit : Côté atelier logiciel graphique, spécifier un bouton avec un identifiant «28» ; Côté atelier logiciel « Traitement de la logique », traiter l'action 15 « REQUEST_RUNWAY LENGTH ». Ceci se traduit par la spécification et l'implémentation de l'événement « CLIC » du bouton « 28 » auquel on associe un traitement. Les problèmes soulevés sont les suivants: incohérence des interfaces ; 20 dépendance totale graphique/logique ; double définition du bouton ; maintenance plus difficile ; Evolutions de la définition complexes. Dans les bancs selon l'invention, on doit simplement : 25 Côté atelier logiciel graphique, spécifier un bouton, peu importe l'identifiant puis associer au bouton un événement nommé « REQUEST_RUNWAY LENGTH » qui correspond à l'action « CLIC » du bouton ; Côté atelier logiciel traitement de la logique, importer l'événement 30 REQUEST RUNWAY LENGTH et l'associer au traitement. Les problèmes cités précédemment n'existent plus puisque : il existe une définition unique du bouton côté graphique et la cohérence des interfaces est assurée dès la spécification ; La maintenance et l'évolution sont simplifiées grâce à 35 l'indépendance graphique/logique.

Claims (2)

1. REVENDICATIONS1. Procédé de mise en oeuvre d'un logiciel exécutable dans un dispositif de visualisation, ledit procédé comportant : une première étape de réalisation dudit logiciel par un banc de développement d'application logicielle aéronautique comprenant au moins un atelier logiciel « graphique » qui comporte des moyens informatiques traitant des outils logiciels servant à créer, simuler ou intégrer des fonctions graphiques ou « widget » au niveau dudit équipement de visualisation et un atelier logiciel « traitement de logique » qui comporte des moyens informatiques traitant des outils logiciels servant à créer, simuler ou intégrer des fonctions logiques permettant de modifier le contenu des fonctions graphiques en fonction d'événements entrants au niveau du même équipement de visualisation, une seconde étape d'implantation dudit logiciel dans ledit dispositif de visualisation, caractérisé en ce que le banc de développement d'application logicielle comporte une interface fonctionnelle permettant le dialogue entre l'atelier logiciel « graphique » et l'atelier logiciel « traitement de logique », ladite interface fonctionnelle comportant des « plugs » fonctionnels, c'est-à-dire des données d'entrée ou de sortie, à chaque « plug » fonctionnel est associé d'une part, un paramètre d'une fonction graphique et d'autre part un paramètre d'une fonction logique.
2. 2. Procédé de mise en ceuvre d'un logiciel exécutable dans un dispositif de visualisation selon la revendication 1, caractérisé en ce que le 25 banc de développement d'application logicielle comporte : des moyens informatiques permettant de créer le code graphique et le code logique ainsi que les différentes interfaces de programmation permettant de créer et de modifier les fonctions graphiques ; 30 - une interface de couplage comportant une structure de variables d'échange basée sur les noms des « plugs », ces variables étant manipulées à la fois par le code logique et par le code graphique.