FR 2989794 A1 20131025 FR 1201199 A 20120424 PROCEDE ET DISPOSITIF DE CAPTURE DU BESOIN POUR UN SYSTEME DE PILOTAGE AUTOMATIQUE POUR AERONEF L'invention concerne le domaine des systèmes au- tomatiques embarqués sur des aéronefs et plus particulièrement un procédé et un dispositif de capture du besoin pour un système de pilotage automatique pour aéronef. Un système de pilotage automatique (PA) réalise le guidage d'un aéronef conformément aux consignes du pilote et informe l'équipage sur la situation du guidage. En gérant les modes opérationnels et les lois de guidage associées, le PA transforme des consignes de guidage en commandes de pilotage. Ces commandes permettent in fine de modifier les mouvements de l'aéronef. Le 'Pilote Automatique' (PA) est connecté à 20 plusieurs équipements électroniques de l'aéronef (capteurs, système d'alertes, système de gestion de vol, etc.). De plus, le comportement d'un PA est soumis à un certain nombre de conditions et de paramètres qui varient en fonction du besoin exprimé 25 par l'avionneur, comme par exemple le comportement des modes de guidage. Ainsi, le PA est fortement adhérent à l'aéronef et aux besoins spécifiques des avionneurs. Les systèmes embarqués tels que le PA sont 30 certifiés et leur conception ne peut donc laisser place à aucune incertitude. Tout manque ou incompréhension dans la capture du besoin lors de la mise au point du PA, pendant ou après la certification a donc des impacts importants en termes de qualité, de délai et de coût. La capture complète et intègre du besoin est essentielle. La capture du besoin pour concevoir un PA est réalisée actuellement de manière uniquement documentaire en utilisant des modèles documentaires. 10 La complétude n'est pas mesurable et n'est assurée que par un processus de revue documentaire. De plus, le besoin est exprimé en langage naturel, qui est souvent polysémique. L'expression du 15 besoin est donc sujette à interprétation. Par conséquent, rien ne garantit à priori et de manière systématique l'exactitude de l'expression de besoin, ni sa non-ambiguïté, ni sa complétude, ni l'absence de contradictions ou d'incompatibilités techniques. 20 Il existe alors le besoin d'une solution qui permette de regrouper de manière complète les besoins de conception d'un PA et permette de s'affranchir des erreurs d'interprétation. 25 La présente invention répond à ce besoin. Un objet de la présente invention est d'offrir un dispositif et un procédé pour définir de manière 30 itérative et complète les besoins de conception d'un PA et de vérifier la conformité et la complétude de la totalité de la configuration vis-à-vis du domaine de configuration. Avantageusement, la présente invention garantit 5 la complétude et l'exactitude de la capture du besoin pour la conception d'un PA. Un autre objet de la présente invention est de fournir un système adapté à l'utilisateur, qu'il soit 10 équipementier ou intégrateur avion. Avantageusement, la présente invention offre une interface homme-machine de saisie des paramètres d'un PA propre à un domaine de langage spécifique. 15 Avantageusement, la présente invention s'applique de manière dynamique à tout nouvel environnement de PA. 20 Avantageusement, la présente invention permet un accès aisé à la consultation des paramètres de configuration d'un PA. Un objet supplémentaire de la présente invention 25 est de générer automatiquement un fichier de capture du besoin d'un PA à partir d'une saisie unique de paramètres par un utilisateur. Avantageusement, la présente invention 30 s'implémentera dans le contexte de l'industrie aéronautique. Pour obtenir les résultats recherchés, un procédé, un dispositif et un produit programme d'ordinateur sont proposés. En particulier, un dispositif de capture de besoin selon un domaine de langage spécifique (DSL) pour un système de pilotage automatique (PA) pour aéronef, comprend : un module de saisie de paramètres comportemen- taux du PA ; - un module de vérification couplé au module de saisie pour vérifier la conformité des paramètres saisis au domaine de langage spécifique ; - un module de génération couplé au module de sai- sie pour générer des fichiers de capture du besoin; et un module de stockage pour stocker les fichiers de capture du besoin générés. Différentes variantes d'implémentations sont décrites. Différents aspects et avantages de l'invention 25 vont apparaitre en appui de la description d'un mode préféré d'implémentation de l'invention mais non limitatif, avec référence aux figures ci-dessous : La Figure 1 montre les briques fonctionnelles d'un 30 dispositif pour capture du besoin d'un PA selon les principes de l'invention ; La figure 2 illustre une Interface Homme-Machine (IHM) de saisie de paramètres comportementaux dans une implémentation préférentielle de l'invention La figure 3 illustre une autre Interface Homme-Machine (IHM) de saisie de paramètres comportementaux dans une 10 implémentation de l'invention La Figure 4 montre les étapes opérées par la méthode de l'invention pour capturer le besoin initial d'un PA ; 15 La Figure 5 montre les étapes opérées par la méthode de l'invention pour capturer le besoin à partir d'un existant. 20 La figure 1 illustre un environnement informatique (100) permettant d'implémenter le dispositif et d'opérer le procédé de l'invention pour capturer le besoin d'un pilote automatique ou PA. La 25 figure 1 montre un exemple des modules fonctionnels dans une implémentation préférentielle de l'invention, sans être limitatif et permettant à l'homme du métier d'implémenter des variantes. Le système 100 est composé d'un dispositif de 30 saisie 101 apte à recueillir des données pour capturer le besoin d'un pilote automatique à configurer. Le système comprend en outre un module de stockage 106 pour stocker les données relatives à la définition du domaine de configuration du PA ou « Domaine Specific Language PA » (DSL PA) 107 et une base de données 108 des fichiers de capture du besoin 112. Le DSL PA 107 exprime de manière formelle les différents concepts du domaine PA, leur signification, les paramètres et la structure qui les caractérisent, le domaine de variation de ces paramètres, les associations possibles entre les concepts, ainsi que les différentes règles et contraintes spécifiques du domaine PA (e. g. bornes sur la valeur d'un paramètre en fonction de la valeur d'un autre paramètre). Le dispositif comprend avantageusement un module de vérification 104 dont le rôle est de vérifier que l'ensemble des paramètres 102 saisis est conforme au DSL PA 107, en termes de structure, de domaine de variation et de cohérence des valeurs. Un module 105 de génération d'un fichier de capture de besoin 112 est couplé au module de vérification 104. Le contenu et la structure du fichier 112 sont garantis conformes à la saisie et au DSL PA 107. Un medium d'interaction 110 permet à 25 l'utilisateur 109 de saisir les paramètres 102. Le medium d'interaction 110 peut être par exemple un clavier d'ordinateur, un système de reconnaissance vocal, un écran tactile, ou tout autre medium d'interaction transformant une action de l'utilisateur 30 en commande du dispositif de saisie 101. Une interface homme-machine (IHM) 103 permet à un utilisateur 109 de modifier des paramètres 102 du PA conformément au DSL PA 107, et/ou de consulter et modifier une capture de besoin préalablement établie. Un medium d'affichage 111 permet à l'utilisateur 5 109 d'appréhender la valeur et la structure des paramètres 102 et d'avoir connaissance des informations préalablement saisies. Le medium d'affichage 111 peut être par exemple un écran d'ordinateur, une tablette graphique, un dispositif 10 tactile ou audio, ou tout autre medium permettant à l'utilisateur de connaître le contenu de la base de données 108. Le module de stockage 106 peut être une mémoire intégrée à un ordinateur 100, mais dans une variante 15 d'implémentation elle peut être externalisée. Cette mémoire permet le stockage de la définition du domaine de configuration 107 et de la base de données 108. La mémoire 106 peut être réalisée par exemple par un disque dur, une mémoire FLASH, un stockage USB, un CD- 20 ROM, etc. Le DSL PA 107 et la base de données 108 peuvent également être stockés dans des mémoires différentes. L'ordinateur 100 et la mémoire 106 communiquent pour permettre les échanges de données entre le module de saisie 101 et la mémoire. La 25 connexion entre ordinateur et mémoire peut être filaire (e. g. par bus électronique, câble USB, câble Ethernet, etc.) ou sans fil (e. g. Wifi, Bluetooth, etc.). Le dispositif permet en mode opératoire de 30 paramétrer entre autres les modes, les segments de consignes des modes, les scénarios d'activation des modes, les scénarios de séquencement. Le dispositif et le procédé de mise en oeuvre peuvent également permettre de paramétrer les contextes externe et opérationnel du PA (données présentes dans les contextes et logiques d'élaboration de ces données). Le dispositif s'appuie sur un DSL PA préétabli contraignant la définition de paramètres comportementaux du PA. Il définit les concepts-clés du PA de manière complète et non ambiguë. Il structure et 10 établit des règles de définition des modes de guidage. Conformément au DSL PA 107, le dispositif de saisie 101 permet de définir les paramètres comportementaux du PA 102, par exemple : une liste de modes de guidage tels que décrit dans 15 les normes internationales aéronautiques (CS25/..). Cette liste peut-être avantageusement étendue selon des nouveaux besoins ; pour chaque mode de guidage, sa logique d'activation/désactivation ; 20 pour chaque mode de guidage, ses segments de gui- dage ; pour chaque mode de guidage, ses logiques d'affichage ; pour chaque logique d'activation/désactivation, son 25 contexte d'activation/désactivation, sa requête d'activation/désactivation et son type d'activation/désactivation ; pour chaque segment de guidage, ses consignes spatiales, sa logique de séquencement, ses enveloppes 30 de protection, son mode de réversion, sa configura- tion de pilotage ; pour chaque consigne spatiale, ses caractéristiques propres ; pour chaque caractéristique propre de consigne spatiale, sa loi de guidage et ses paramètres associés, sa consigne et ses paramètres associés ; pour chaque contexte d'activation, ses conditions externes élémentaires, ses conditions opérationnelles élémentaires ; pour chaque logique d'affichage, ses caractéris- tiques propres. Les tableaux suivants fournissent un exemple de définition des paramètres comportementaux du PA. Ces tableaux, leur contenu et les intervalles sont donnés uniquement à titre d'exemple et non comme étant les contenus exhaustifs. Définition d'un mode de guidage : Concept Data Description Cardinalité Range mode de guidage référence identifiant du mode de guidage 1 1..50 logique d'activation référence de la logique d'activation d'un mode de guidage 1..5 IDT logique d'affichage référence de logique d'affichage 1..10 IDT liste de 'segment de guidage' référence de segment de guidage 1..20 IDT categorie de consignes spatiales catégrorie de consigne spatiale associée au mode de guidage. 1..6 HOR/VERT/VIT/ ROULIS/TANG/ LACET/POUSS EE Définition d'une logique d'affichage : Context Data Description Cardinalité Range identifiant de logique d'affichage de mode de guidage 1 1..20 logique d'affichage référence type d'affichage type de l'information affichée 1 MODE/LAW position couple déterminant la position (linge/colonne / pixels / ...) 1 1..100 couleur 1 GREEN / CYAN / RED clignotement A définir plus présisément selon la norme cadre A définir plus présisément selon la norme Définition d'une logique d'activation : Context Data Description Cardinalité Range logique d'activation référence identifiant de logique d'activation d'un mode de guidage 1 1..150 contexte d'activation identifiant de condition élémentaire d'activation 1..20 IDT opérateur booléen identifiant d'opérateur booléen 1..19 IDT trigger d'activation identifiant de trigger d'activation 1 IDT type d'activation type de l'activation du mode de guidage 1 ARM/ENG Définition d'un segment de guidage : Concept Data Description Cardinalité Range segment de guidage référence identifiant de segment de guidage 1 1..400 logique de séquencement référence de la logique de séquencement d'un segment 1 IDT modes de réversion référence de mode de guidage de réversion 1..3 IDT enveloppe de protection référence d'enveloppe de protection 1..10 IDT configuration de pilotage 1 ROULIS/TANGA GE/LACET/POU SSEE/COLL consigne spatiale horizontale référence de consigne 0..1 IDT consigne spatiale verticale référence de consigne 0..1 IDT consigne spatiale vitesse référence de consigne 0..1 IDT consigne spatiale attitude roulis référence de consigne 0..1 IDT consigne spatiale attitude tangage référence de consigne 0..1 IDT consigne spatiale attitude lacet référence de consigne 0..1 IDT consigne poussée référence de consigne 0..1 IDT Définition d'une logique de séquencement : Concept Data Description Cardinalité Range identifiant de logique d'activation d'un mode de guidage 1 1..150 logique de séquencement référence contexte de séquencement référence de condition élémentaire 1..20 IDT opérateur booléen référence d'opérateur booléen 1..19 IDT trigger d'activation référence de trigger d'activation 1 IDT type de séquencement type de séquencement 1 INIT/TRANS/FIN AL Définition d'une consigne spatiale : Concept Data Description Cardinalité Range identifiant de consigne spatiale 1 1..500 consigne spatiale référence categorie catégorie de consigne spatiale 1 HORNERTNI T/ROULIS/TA NG/LACET/P OUSSEE loi de guidage référence de loi de guidage 1 IDT target de guidage référence d'élaboration de target 1 IDT Définition d'une activation de loi de guidage : Concept Data Description Cardinalité Range identifiant d'activation de loi de guidage 1 1..50 activation de loi de guidage référence dynamique type de dynamique de la consigne de guidage 1 ECO / NORMAL / ACCURATE Définition d'une logique d'élaboration de consigne de guidage/pilotage : Concept Data Description Cardinalité Range 1 1..100 elaboration de consigne de guidage/pilotage référence identifiant de l'élaboration de target de guidage référence sol air 0..1 AIR / GROUND / UNCHANGED référence magnetique 0..1 MAG / TRUE / UNCHANGED référence vitesse 0..1 CAS / MACH / UNCHANGED référence altitude 0..1 BARO / RADIO / UNCHANGED source 0..1 AUTO / MAN / UNCHANGED modifiable 0..1 MODIFIABLE / FROZEN / UNCHANGED Le dispositif 100 de capture du besoin est conçu pour générer un fichier de capture du besoin 112 à partir de l'ensemble des paramètres 102 préalablement saisis par l'opérateur 109. Ce fichier peut par exemple servir de support à des revues afin de consolider la capture du besoin ou bien servir à la génération d'une base de données à destination d'un PA con- figurable. Le fichier généré est structuré conformément au DSL PA 107 et le contenu est conforme à la saisie de l'opérateur 109. Le module de génération 105 doit donc être capable d'associer chacune des saisies de l'IHM 103 avec des éléments de la structure du DSL PA 107. Par exemple, la saisie d'une nouvelle donnée du con- texte opérationnel doit correspondre au concept associé dans le DSL PA 107, i. e. une donnée booléenne avec un identifiant unique. Avantageusement, plusieurs variantes d'implémentation permettent de réaliser ce mécanisme, comme par exemple développer une IHM 103 de telle sorte que chaque champ de saisie soit dédié à l'avance 5 et de manière systématique à une structure du domaine de configuration. Une autre variante, peut être de développer une IHM 103 qui, au moment de son exécution, adapte ses champs dynamiquement à la définition du DSL PA et associe donc dynamiquement chaque champ à une 10 structure du langage spécifique du domaine PA. Avantageusement, le fichier généré 112 peut avoir différents formats : textuel, code machine, code source dans des langages de programmation tels que C, C++, Java ou bien code source dans un langage inter- 15 prété tel que XML ou XHTML. Le rôle du module 104 de vérification est de vérifier la cohérence et la conformité de l'ensemble des saisies de l'opérateur, en regard du DSL PA 107, ainsi 20 que la complétude et la non-contradiction des saisies, par exemple : - continuité des domaines d'activation ; - cohérence du comportement du PA exprimé, en regard des contraintes opérationnelles définies 25 dans le DSL PA 107 (e. g. pour un avion, une ap- proche ne peut pas être réalisée à Vmax), etc. Les figures 2 et 3 représentent des exemples d'Interface Homme-Machine (IHM) dans une 30 implémentation préférentielle de l'invention. L'interface 300 comprend avantageusement différents champs pour saisir les paramètres comportementaux du PA conformément à un domaine de configuration et d'être guidé dans cette saisie. L'interface permet aussi à un utilisateur de consulter et éditer une configuration prédéfinie. Ainsi, l'IHM peut permettre de paramétrer : les logiques d'activation 200 des modes de guidage, i. e. les scénarios d'engagement et d'armement, en spécifiant : - un événement déclencheur 300, une équation booléenne à évaluer 304. Une équation booléenne est composée d'un opérateur tel que ET logique ou OU logique associé à un opé- rande (dans le cas d'un opérateur unaire) ou plusieurs (dans le cas d'un opérateur binaire). Un opérande est soit une donnée booléenne issue d'un contexte tel que le contexte opérationnel, soit une autre équation booléenne ; - les caractéristiques de modes de guidage, entre autres : - les caractéristiques des segments de guidage 201, 202, 203 associés au mode : e. g. para- mètres d'attitude, profile de vitesse, profiles vertical et horizontal avec leur catégorie de consigne, paramètres des enveloppes de protection, etc., un scénario de séquencement des segments : évé- nement déclencheur et équation booléenne à éva- luer (fonctionnement similaire à celui des logiques d'activation des modes de guidage) ; le contexte externe, i. e. : spécifier quelles données doivent être élabo- rées, spécifier les opérations permettant d'élaborer ces données de contexte : opérations booléennes, opérations sur des valeurs énumérées, opérations numériques, référencement des don- nées externes le contexte opérationnel 302, i. e. spécifier quelles données doivent être élabo- rées, spécifier les opérations permettant d'élaborer ces données de contexte : opérations boo- léennes, opérations sur des valeurs énumérées, opérations numériques, référencement des données d'état du PA. Comme précédemment indiqué, le langage spécifique du comportement PA (DSL PA) permet de définir entre autres les scénarios d'activation 304 des modes du PA. Chaque logique, dans sa définition, référence des événements 300 et des données des contextes opérationnel et externe. Le dispositif doit donc permettre à chacune de ces données d'être référencée dans les logiques, afin d'assurer un affichage et une génération de fichier fidèle à la saisie de l'opérateur. Avantageusement, une solution consiste à associer une clé, qui sert de référence. Dans ce cas, c'est le rôle du dispositif de produire les clés de référence en garantissant leur unicité. La Figure 4 montre les étapes 400 opérées par la méthode de l'invention pour capturer le besoin initial 5 d'un PA dans une implémentation préférentielle, telle que sur un dispositif 100. Dans une première étape 401, le procédé permet de charger un fichier de définition du Domaine de Langage Spécifique afin de pouvoir être appelé par le module 10 de vérification 104 dans la suite du procédé. Les étapes suivantes 402 à 406 vont permettre de saisir les paramètres comportementaux du PA étudié. A l'étape 402, un premier paramètre est requis. Le procédé récupère 403 la définition du paramètre 15 correspondant dans le fichier DSL. L'étape suivante 404 active une routine de vérification de la validité de la saisie du paramètre requis. Si le test de l'étape suivante 405 valide la 20 saisie, le procédé continue à l'étape 406 pour tester si tous les paramètres ont été saisis. Si d'autres paramètres sont à saisir le procédé reboucle sur l'étape 402 ou bien continue à l'étape 407. Si le test de l'étape 405 ne valide pas la 25 saisie, le procédé reboucle sur l'étape 402. A l'étape 407, le procédé vérifie de manière globale la totalité des saisies de paramètres au regard du DSL. 30 Si toutes les saisies sont correctes en 408, le procédé passe à l'étape 409, ou bien reboucle sur l'étape 402. A l'étape 409, un fichier de capture du besoin, est généré à partir de l'ensemble des paramètres validés. Le fichier est enregistré et peut être stocké à l'étape 410, et le procédé s'arrête 411. La figure 5 montre les étapes 500 opérées par la méthode de l'invention pour capturer le besoin à 10 partir d'un existant. Dans une première étape, le procédé charge un fichier de capture du besoin qui est existant. Ce fichier peut être préalablement stocké sur le module mémoire du dispositif ou bien sur un média de stockage 15 externe. A l'étape suivante 502, le procédé charge un fichier de définition du domaine spécifique de langage du PA. A l'étape 503, le procédé permet d'initialiser le 20 module de saisie à partir des paramètres contenus dans le fichier existant. Puis le procédé opère les étapes 504 à 513 selon les mêmes principes que pour les étapes 402 à 411 décrites précédemment en référence à la figure 4. La 25 saisie d'un paramètre dans cette variante d'implémentation peut consister à valider le paramètre existant ou à le modifier. Ainsi la présente description illustre une 30 implémentation préférentielle de l'invention, mais n'est pas limitative. Un exemple a été choisi pour permettre une bonne compréhension des principes de l'invention, et une application concrète, mais il n'est en rien exhaustif et doit permettre à l'homme du métier d'apporter des modifications et variantes d'implémentation en gardant les mêmes principes. La présente invention peut s'implémenter à partir d'éléments matériel et/ou logiciel. Elle peut être disponible en tant que produit programme d'ordinateur 10 sur un support lisible par ordinateur. Le support peut être électronique, magnétique, optique, électromagnétique ou être un support de diffusion de type infrarouge. De tels supports sont par exemple, des mémoires à semi-conducteur (Random Access Memory 15 RAM, Read-Only Memory ROM), des bandes, des disquettes ou disques magnétiques ou optiques (Compact Disk - Read Only Memory (CD-ROM), Compact Disk - Read/Write (CD-R/W) and DVD). 20 REVENDICATIONS1. Un procédé exécuté sur un ordinateur pour capturer selon un domaine de langage spécifique (DSL) le besoin pour un système de pilotage automatique (PA) pour aéronef, comprenant les étapes de : saisir (402) des paramètres comportementaux du PA ; vérifier (404, 407) la conformité des paramètres saisis au domaine de langage spécifique ; générer (409) des fichiers de capture du besoin en réponse à l'étape de vérification; et stocker (410) les fichiers de capture du besoin générés. 2. Le procédé selon la revendication 1 l'étape de saisie comprend les étapes saisir (402) un premier paramètre; charger (401) un fichier de définition du langage spécifique ; et valider (404) la conformité du premier saisi au domaine de langage spécifique. dans lequel de : domaine de paramètre 3. Le procédé selon la revendication 1 ou 2 dans le- quel l'étape de génération de fichier de capture du besoin, consiste à générer un fichier selon l'un des formats (texte, code machine, code source). 4. Le procédé selon la revendication 3 dans lequel l'un des formats du fichier de capture de besoin généré est XML ou XHTML. 5. Le procédé selon la revendication 3 dans lequel l'un des formats du fichier de capture de besoin généré est en langage C, C++, Java. 6. Le procédé selon l'une quelconque des revendica- tions 1 à 5 comprenant avant l'étape de saisie, les étapes de : - charger un fichier de capture du besoin prédéfini ; et - charger un fichier de définition d'un domaine spécifique de langage. 7. Un dispositif de capture de besoin selon un domaine de langage spécifique (DSL) pour un système de pilotage automatique (PA) pour aéronef, le dispositif comprenant : un module de saisie 101 de paramètres comportementaux du PA ; un module de vérification 104 couplé au module de saisie pour vérifier la conformité des paramètres saisis au domaine de langage spécifique ; un module de génération 105 couplé au module de saisie pour générer des fichiers de capture du besoin; et un module de stockage 106 pour stocker les fi- chiers de capture du besoin générés. 8. Le dispositif selon la revendication 7 où le module de saisie comprend en outre une Interface Homme-Machine 103 ayant différents champs pour saisir les paramètres comportementaux du PA con- formément à un domaine de langage spécifique. 9. Le dispositif selon les revendications 7 ou 8 où le module de saisie comprend en outre des moyens d'interaction avec un utilisateur. 10.Le dispositif selon l'une quelconque des revendications 7 à 9 où le module de stockage 106 comprend un premier module 107 pour stocker un do- maine de langage spécifique et un second module 108 pour stocker les fichiers de capture du besoin générés. 11.Un produit programme d'ordinateur, ledit pro- gramme d'ordinateur comprenant des instructions de code permettant d'effectuer les étapes du procédé selon l'une quelconque des revendications 1 à 6, lorsque ledit programme est exécuté sur un ordinateur.