FR2944617A1

FR2944617A1 - Procede de chargement d'une base de donnees a bord d'un aeronef.

Info

Publication number: FR2944617A1
Application number: FR0952456A
Authority: FR
Inventors: Fabien Cases; Nicolas Fabas; Christine Gris; Jerome Treanton
Original assignee: Airbus Operations SAS
Current assignee: Airbus Operations SAS
Priority date: 2009-04-15
Filing date: 2009-04-15
Publication date: 2010-10-22
Anticipated expiration: 2029-04-15
Also published as: US8510278B2; US20100268698A1; FR2944617B1

Abstract

Dans le procédé pour charger des données à bord d'un aéronef, on charge, dans un équipement de bord (18) de l'aéronef, un ensemble de données (24) comprenant au moins: - une première version (24a) d'une base de données identique à une version déjà utilisée dans l'aéronef ; et - une deuxième version (24b) de la base de données. La base de données est de préférence relative à un système d'alarme (18) de l'aéronef.

Description

-1- L'invention concerne le chargement des données à bord des aéronefs.

Elle concerne notamment la mise à jour du contenu des procédures textuelles gérées par le système d'alarme présent en général sur un avion. Sur certains appareils, ce système est repéré par l'acronyme FWC pour l'anglais Flight Warning Computer ou l'acronyme FWA pour Flight Warning Application. Nous le désignerons ici par FWS pour Flight Warning System. Ces procédures textuelles doivent être suivies par l'équipage et sont de différents types. Il peut s'agir des check-lists, des procédures anormales ou encore des procédures supplémentaires. Les procédures anormales sont celles destinées à être mises en oeuvre en cas d'alerte. Les procédures supplémentaires sont mises en oeuvre lors de circonstances exceptionnelles qui ne sont cependant pas des circonstances d'alerte (par exemple une circonstance de grand froid). Ces procédures textuelles sont définies dans une base de données utilisée par le système d'alarme. Cette base est par exemple celle implantée par le constructeur avant la livraison de l'appareil. Néanmoins, la compagnie qui exploite l'appareil peut souhaiter appliquer des procédures différentes, par exemple modifier le texte des messages transmis lors des check-lists. Il est connu pour cela de remplacer certains messages par défaut par d'autres messages. Matériellement, ces modifications sont mises à la disposition de l'équipage à bord au moyen d'un document sur papier que l'équipage doit consulter lorsque certaines procédures viennent à être appliquées. Un tel document est par exemple connu sous l'acronyme FCOM de l'anglais Flight Crew Operating Manual. On connaît du document FR-2 915 292 une autre méthode pour modifier les procédures textuelles de base. Dans cette méthode, la compagnie aérienne crée une base de données électronique relative aux adaptations qu'elle souhaite apporter aux procédures textuelles et la charge dans le système d'alarme. Lorsqu'une procédure doit être appliquée, le système consulte cette base de données et applique par priorité la procédure telle que modifiée par cette dernière. A défaut, il applique la procédure telle que prévue dans la base de données du constructeur. Nous désignerons par base de données customisée la base de données qui répond à des souhaits de personnalisation de la compagnie exploitant l'appareil. Une telle base est par exemple connue sous l'acronyme OCED pour l'anglais Operator Customized ECAM Database. L'acronyme ECAM correspond à l'anglais Electronic Centralized Aircraft Monitoring. (L'ECAM est un ensemble de systèmes d'informations visuelles et sonores et de contrôle dans l'environnement du cockpit d'un aéronef.) La base de données ainsi chargée apporte des 2944617 -2- évolutions en relatif par rapport aux messages textuels définis par défaut dans l'application. Il s'agit ainsi d'une base de données relative. Dans ces conditions, il est possible de modifier le contenu de tout message textuel devant être affiché dans le cockpit par le calculateur d'alarme, et ce sans nécessiter le 5 développement d'un standard spécifique. En effet, par le biais de la base de données de customisation chargée dans le système d'alarme, ce dernier devient capable de modifier le contenu des messages textuels qu'il gère. Une telle base de données peut également émaner du constructeur, par exemple lorsqu'il souhaite apporter des modifications ou des perfectionnements à la base chargée 10 à l'origine, par exemple en présence d'un nouveau standard du logiciel d'alarme La base de données de customisation est produite au moyen d'un outil dédié. Elle est ensuite chargée dans le dispositif matériel désigné par l'acronyme CPIOM (pour l'anglais Core Processing and Input/Output Module) qui héberge l'application du système d'alarme.

15 La base de données de customisation de la compagnie possède une date d'applicabilité. C'est en effet à compter de cette date que les procédures modifiées doivent être mises en oeuvre. Or, une fois installée sur un aéronef dans le CPIOM cible, la nouvelle base de données est prise en compte sans délai par le système d'alarme. Idéalement, cette base de données doit donc être installée sur tous les avions de la flotte 20 à la date d'applicabilité. On comprend cependant qu'il est impossible à une compagnie possédant une flotte étendue d'effectuer une mise à jour synchronisée de l'ensemble de la flotte. En effet, les avions de la flotte sont dispersés géographiquement à la date d'applicabilité de la nouvelle base de données. De plus, la mise à jour de chaque avion engendre des coûts 25 d'immobilisation. Elle nécessite en effet un chargement de la base de données dans le CPIOM. Cette procédure d'installation de la nouvelle base à bord ne fait pas partie du domaine de compétences du pilote. Le chargement de la base de données doit donc être effectué par un opérateur de maintenance. La compagnie préfère ainsi l'effectuer à l'occasion d'une phase de maintenance programmée. Or, la date de cette dernière ne 30 correspond pas forcément à la date d'applicabilité de la nouvelle base de données. A contrario, lorsque les avions de la flotte doivent être mis à jour et appliquer la nouvelle procédure à des dates différentes, cela génère des difficultés de coordination et de gestion, en particulier au niveau de l'information et de la formation des équipages. Un but de l'invention est de pallier à ces inconvénients pour faciliter la modification 35 des bases de données prises en compte à bord des aéronefs. 2944617 -3- A cet effet, on prévoit selon l'invention un procédé pour charger des données à bord d'un aéronef, dans lequel on charge, dans un équipement de bord de l'aéronef, un ensemble de données comprenant au moins : - une première version d'une base de données identique à une version déjà utilisée 5 dans l'aéronef ; et - une deuxième version de la base de données, la base de données étant de préférence relative à un système d'alarme de l'aéronef. Ainsi, on produit une double base de données qui intègre la version déjà appliquée sur l'ensemble de la flotte ainsi que celle dont la date d'applicabilité est à venir. Chacune 10 de ces deux versions, qui sont par exemple des customisations, pourra ainsi être caractérisée par une date d'applicabilité propre reconnaissable par le système d'alarme destiné à l'exploiter. L'ensemble comprenant les deux bases peut être chargé de manière étalée dans le temps dans tous les aéronefs de la flotte. On peut ainsi prévoir que la version active est la même sur toute la flotte jusqu'à la date de transition, date jusqu'à 15 laquelle l'autre version, dite secondaire ou dormante, reste inactive. A la date de transition, la deuxième version peut devenir active tandis que la précédente devient inactive. On résout ainsi la problématique de l'installation de la nouvelle base de données de façon étalée dans le temps. Cette installation progressive pour la flotte est compatible 20 avec la mise en application de la nouvelle version de la base au même moment pour l'ensemble de la flotte. En outre, lorsque la nouvelle version doit être utilisée, il ne s'agit plus de la charger à bord mais seulement de l'activer. Or, cette opération peut être commandée sans difficulté par le pilote ou encore déclenchée de façon automatisée. Il n'est donc pas 25 nécessaire de faire intervenir un opérateur à cette fin. L'invention permet ainsi à la compagnie d'effectuer une mise à jour coordonnée de ses procédures textuelles électroniques sur l'ensemble de sa flotte à une date donnée quel que soit l'emplacement géographique de chaque appareil de cette flotte à la date considérée. On voit que l'invention permet de rendre non-concomitants le chargement à bord 30 d'une nouvelle version d'une base de données et son activation, et de tirer parti de cette mise en oeuvre dissociée des deux opérations. En outre, l'ensemble des deux bases de données mis en oeuvre dans l'invention implique la gestion d'un seul numéro de composant à bord, ce qui évite d'augmenter le nombre de ces numéros déjà très élevé pour un aéronef.

35 De préférence, on réalise un paramétrage apte à entraîner une prise en compte de l'une prédéterminée des deux versions, notamment la première, par un calculateur de 2944617 -4- l'aéronef, par exemple on enregistre dans une mémoire non-volatile de l'aéronef un identifiant de cette version. Ainsi, le calculateur est en mesure d'identifier, par exemple lors de son redémarrage, celle des deux versions qu'il doit utiliser.

5 On prévoit également selon l'invention un programme d'ordinateur présentant des instructions de code aptes à commander l'exécution des étapes du procédé de chargement selon l'invention lorsqu'il est exécuté sur un ordinateur. On prévoit également selon l'invention un support d'enregistrement de données qui comprend, sous forme enregistrée, un tel programme.

10 On prévoit aussi selon l'invention la mise à disposition d'un tel programme sur un réseau de télécommunications en vue de son téléchargement. On prévoit également selon l'invention un aéronef qui comporte un équipement de bord comprenant au moins : - une première version d'une base de données, identique à une version déjà utilisée 15 dans l'aéronef ; et - une deuxième version de la base de données, la base de données étant de préférence relative à un système d'alarme de l'aéronef. De préférence, l'aéronef comprend des moyens de bord, notamment une interface homme-machine, pour commander un paramétrage apte à entraîner une prise en compte 20 de la deuxième version par un calculateur de l'aéronef. Ainsi, une personne à bord, par exemple un membre de l'équipage, peut déclencher le basculement de l'une à l'autre des versions. Avantageusement, l'aéronef comprend des moyens automatisés pour réaliser, après la survenue d'un événement prédéterminé sans intervention humaine, par exemple 25 l'arrivée d'une date prédéterminée, un paramétrage apte à entraîner une prise en compte de la deuxième version par un calculateur de l'aéronef. Ainsi, il n'est pas besoin de prévoir une intervention humaine pour réaliser le basculement. On rend ainsi possible un basculement d'une version à l'autre convenablement synchronisé sur l'ensemble de la flotte.

30 On prévoit également selon l'invention un procédé de commande d'un aéronef selon l'invention dans lequel, l'aéronef étant paramétré pour entraîner une prise en compte de la première version par un calculateur de l'aéronef, on commande un paramétrage apte à entraîner une prise en compte de la deuxième version par le calculateur. On prévoit également selon l'invention un programme d'ordinateur présentant des 35 instructions de code aptes à commander l'exécution des étapes du procédé de commande selon l'invention lorsqu'il est exécuté sur un ordinateur. 2944617 -5- On prévoit également selon l'invention un support d'enregistrement de données qui comprend, sous forme enregistrée, un tel programme. On prévoit également selon l'invention la mise à disposition d'un tel programme sur un réseau de télécommunications en vue de son téléchargement.

5 On prévoit encore selon l'invention un procédé d'enregistrement de données, dans lequel on enregistre sur un support un ensemble comprenant au moins : - une première version d'une base de données identique à une version déjà utilisée par un équipement de bord d'un aéronef ; et - une deuxième version de la base de données, 10 la base de données étant de préférence relative à un système d'alarme de l'aéronef. On prévoit également selon l'invention un programme d'ordinateur qui comprend des instructions de code aptes à commander l'exécution du procédé d'enregistrement selon l'invention lorsqu'il est exécuté sur un ordinateur. On prévoit aussi selon l'invention un ensemble de données qui comprend au moins : 15 - une première version d'une base de données identique à une version déjà utilisée par un équipement de bord d'un aéronef; et - une deuxième version de la base de données, la base de données étant de préférence relative à un système d'alarme de l'aéronef. On prévoit encore selon l'invention un support d'enregistrement de données, qui 20 comprend, sous forme enregistrée, au moins un ensemble de données selon l'invention. On prévoit aussi selon l'invention un procédé de mise à disposition d'un ensemble de données sur un réseau de télécommunications en vue de son téléchargement, dans lequel l'ensemble est conforme à l'invention. D'autres caractéristiques et avantages de l'invention apparaîtront encore dans la 25 description suivante d'un mode de réalisation donné à titre d'exemple non limitatif en référence aux dessins annexés sur lesquels : - la figure 1 est une vue de côté d'un avion selon l'invention ; - la figure 2 est un schéma du système d'alerte de l'avion de la figure 1 ; - la figure 3 est un organigramme illustrant les étapes de mise en oeuvre du procédé 30 de l'invention en relation avec l'avion de la figure 1 ; et - les figures 4 à 8 sont des illustrations complémentaires de certaines des étapes du procédé de la figure 3. On a illustré à la figure 1 un aéronef 2 selon l'invention. Cet aéronef est en l'espèce un aérodyne et constitue ici un avion. Cet avion comprend un fuselage 4, deux ailes 6, un 35 empennage 8 et des moteurs 10, ici au nombre de quatre. 2944617 -6- L'avion 2 comprend un cockpit 11 qui sert au pilotage de l'avion par le pilote. Les équipements de l'avion comprennent des moyens d'affichage 12 de type ECAM, ainsi qu'un boîtier de commande, par exemple de type ECP pour ECAM Control Panel. Ce boîtier comprend notamment des organes de commande et un clavier.

5 L'avion comprend un système d'alarme 18 de type FWS. Le système 18 est centralisé et connecté à de nombreux autres calculateurs de l'avion et a pour mission d'informer le pilote si survient une configuration dangereuse. Dans le présent exemple, on a illustré seulement trois calculateurs 31 auxquels le système 18 est connecté. En cas d'alerte, le système 18 affiche sur un écran 14, à destination du pilote, le titre 10 de l'alerte concernée, la procédure à suivre avec les opérations à effectuer et le statut actuel de l'avion. Il existe de très nombreux types d'alertes. Il y a par exemple une alerte lorsque le système 18 détecte qu'un train d'atterrissage n'est pas sorti alors que l'avion se trouve en approche. Un autre exemple est la survenance d'un feu dans un moteur. Le système 18 est hébergé dans un dispositif de type CPIOM qui comprend 15 notamment au moins une unité centrale et une ou plusieurs mémoires. Le système 18 fait partie du domaine référencé ATA 31. Le système est commandé par un programme 20 constitué par un logiciel opérationnel. Ce programme d'ordinateur met en oeuvre à bord certaines au moins des étapes du procédé de l'invention, comme on le verra plus loin.

20 Le système 18 comprend également une base de données du constructeur 22. Cette base comprend notamment les données utilisées par défaut par le programme 20 pour la mise en oeuvre des procédures textuelles électroniques (check-lists, procédures anormales, procédures supplémentaires). Le système 18 comprend en outre un ensemble de données 24. Cet ensemble 25 comprend deux bases de données qui sont en l'espèce des bases de données de customisation de la compagnie aérienne exploitant l'appareil. Il s'agit dans le présent exemple de deux versions 24a et 24b de la base de données de customisation de la compagnie, ces versions étant différentes l'une de l'autre. La version 24b est typiquement une amélioration de la version 24a. Le logiciel 20 intègre une fonction de customisation 30 qui lui permet, en fonction des informations prévues dans la version active 24a ou 24b, de modifier lors de leur diffusion certains au moins des messages textuels définis par défaut dans le standard de la base de données 22. Le logiciel et les données 22 et 24 sont enregistrés dans des mémoires du système 18. Le logiciel, la base 22 et l'ensemble 24 constituent chacun des éléments susceptibles 35 d'être chargés à bord. (Toutefois, on prévoira de préférence que la base 22 fait partie intégrante du logiciel 20.) Chacun d'eux peut être remplacé à bord par une version 2944617 -7- modifiée ou mise à jour de ce même élément. Cette opération sera menée par un opérateur. Elle est effectuée par exemple au moyen d'un support d'enregistrement de données 26 fixe ou amovible tel qu'un disque CD-ROM ou un DVD-ROM, un dispositif à mémoire flash tel qu'une clé USB, ou un dispositif à disque dur tel qu'un repository. Par 5 exemple, le chargement a lieu en insérant un disque CD 26 dans un ordinateur de bord 27 de l'avion, servant au chargement des données à bord. Ce dernier lit le contenu du disque 26 et adresse le ou les éléments concernés vers le CPIOM hébergeant le FWS 18. En variante, le chargement de l'élément modifié peut avoir lieu à distance par une liaison sans fil, sous la forme d'un téléchargement à partir d'un réseau de télécommunications 10 28. Dans le présent exemple, l'ensemble 24 intègre donc deux bases de données de customisation 24a et 24b. Chacune de ces bases a sa propre date d'applicabilité. Elle est identifiée au moyen d'un code d'identification numérique. En variante toutefois, on pourra prévoir que ce code est constitué par la date d'applicabilité, par exemple "20090521" si la 15 date d'applicabilité est le 21 mai 2009. Après que les bases de données ont été chargées dans le module CPIOM hébergeant le système d'alarme, l'identifiant numérique de la version 24a ou 24b de la base de données à appliquer est inscrit dans une mémoire non volatile 30 du système 18. Lors d'un redémarrage du système, le logiciel peut ainsi reconnaître celle des versions qui doit être appliquée.

20 Les moyens 12 forment une interface homme-machine comprenant l'écran 14 et utilisée par le pilote pour connaître le statut de l'avion et prendre connaissance des procédures normales ou anormales à appliquer. Cette interface est ici dédiée à cette fonctionnalité. Elle permet aussi au pilote de connaître la date d'applicabilité des customisations respectivement active et dormante (pour cette dernière, la date 25 d'applicabilité est dans le futur). Cette interface permet aussi au pilote le moment venu d'échanger l'une des versions contre l'autre en tant que base de données active. On va maintenant présenter en référence aux figures 3 à 8 les différents aspects du procédé de l'invention avec leurs étapes. On suppose, en référence à la figure 4, que l'on se trouve dans la situation où 30 chaque avion 2 de la flotte comprend un ensemble 24 au sein de son système d'alarme 18. Cet ensemble inclut les deux versions 24a et 24b des bases de données dénommées respectivement "DB A" et "DB B". Ces deux versions ont pour identifiants respectifs "aaa" et "bbb". En référence à la figure 4, en considérant trois avions respectifs 2.1, 2.2 et 2.3 de la flotte, on voit qu'au même instant ces avions comprennent des ensembles 24 35 identiques. Les éléments 20 et 22 sont aussi les mêmes dans les trois avions. En outre, dans la situation de départ considérée, c'est la version DB B de la base de données de 2944617 -8- customisation de la compagnie qui est active dans le système d'alarme 18. En particulier, la référence "bbb" est enregistrée dans la mémoire non volatile 30 du système, de sorte que, si le système doit être redémarré, il prend en compte cette version comme étant la version active.

5 A l'étape 32 sur la figure 3, un bureau d'étude 33 de la compagnie met au point une nouvelle version de la base de données de customisation, version ici appelée "DB C" et ayant l'identifiant "ccc". Le bureau d'étude réalise un nouvel ensemble 24 qui comprend les versions DB B et DB C de la base de données comme illustré à la figure 5. Ce nouvel ensemble 24 se 10 voit attribuer un nouveau numéro de référencement "xxxx"". Cet ensemble comprend donc la version de la base de données de customisation actuellement prise en compte sur tous les avions de la flotte et une nouvelle version de la base de données de customisation dont la date d'applicabilité est à venir. Cette version est différente de la version actuellement utilisée et en constitue de préférence une mise à jour. L'ensemble 24 15 comprend, pour chacune des deux versions, une date d'applicabilité et un identifiant numérique. Au cours d'une étape 34, cet ensemble est enregistré sur un support d'enregistrement de données 26 produit en série, tel qu'un disque. Dans la variante relative au téléchargement à bord, l'ensemble 24 est mis à disposition sur un réseau de 20 télécommunications en vue de son téléchargement. A l'étape 36, pour un avion de la flotte, un opérateur de maintenance introduit à bord un des supports 26 et charge dans l'ordinateur 27 l'ensemble de données 24. L'ordinateur envoie cet ensemble au système 18 dans la mémoire duquel il est ensuite enregistré. Les deux versions DB B et DB C se trouvent ainsi chargées dans le calculateur d'alarme.

25 L'ensemble précédent avec ses versions DB A et DB B est écrasé. Lors de ce chargement, l'identifiant de la version à utiliser enregistré sur la mémoire 30 demeure inchangé. Il s'agit en l'espèce de l'identifiant "bbb". A l'étape suivante 40, les calculateurs de l'avion, notamment le système d'alarme 18, redémarrent. Ce dernier, tenant compte de l'identifiant enregistré dans la mémoire 30, 30 prend en compte la version DB B de la base de données de customisation. Le système d'alarme 18 fonctionne donc après le chargement et le redémarrage avec une version de la base de données de customisation identique à celle qu'il utilisait avant le chargement et le redémarrage. Ce chargement est donc transparent du point de vue opérationnel. En particulier, au cours de la suite de l'exploitation de l'avion à l'étape 42, et notamment au 35 cours de ses phases de vol, le système 18 utilise la base DB B. 2944617 -9- Une certaine plage de temps est allouée aux opérateurs pour effectuer ainsi le chargement de l'ensemble 24 dans toute la flotte. En particulier, il est permis que ce chargement ait lieu à des dates différentes pour les avions respectifs. Il est notamment possible d'attendre que l'avion revienne en maintenance pour effectuer le chargement. On 5 a ainsi illustré à la figure 6 l'état de la flotte lorsque le chargement n'a été effectué que pour une partie des avions de la flotte. Ainsi, les avions 2.1 et 2.2 ont reçu le nouvel ensemble 24 mais pas encore l'avion 2.3. Pour tous, c'est la base DB B qui est utilisée à ce moment-là. On a illustré à la figure 7 l'état de la flotte après que l'étape 42 a été atteinte pour 10 tous les avions. A ce stade, tous les avions de la flotte ont reçu le nouvel ensemble 24 mais ils utilisent tous encore la version DB B. On voit ainsi que, malgré le chargement à bord de la nouvelle version DB C, c'est encore la version DB B, toujours présente à bord, qui est prise en compte. A l'étape 44, arrive la date d'applicabilité de la version DB C. Le pilote en est averti 15 par l'interface 12. Au moyen de cette dernière, le pilote commande au système 18 d'échanger les deux versions. Précisément, il s'agit d'interrompre la prise en compte de la version DB B et de faire prendre en compte la version DB C par le système 18. En variante, on pourrait prévoir que le système 18, ou un autre dispositif, détecte la survenue de la date d'applicabilité de la version DB C et commande automatiquement la prise en 20 compte de la nouvelle version sans que le pilote ait à effectuer de commande à cet effet. Ainsi, l'échange des bases de donnés peut se faire de manière automatique si le calculateur utilise sa connaissance de la date UTC. A l'étape 46, cette commande réalise en l'espèce un paramétrage consistant à introduire dans la mémoire volatile 30 la référence "ccc" de la version DB C en lieu et 25 place de la référence "bbb". A l'étape 48, les calculateurs redémarrent, de préférence automatiquement, et le système 18 prend cette fois en compte non plus la base DB B mais la base DB C au vu de sa référence portée en mémoire 30. Le système 18 applique donc la nouvelle customisation lors de l'exploitation de l'avion, comme indiqué à l'étape 50. La figure 8 30 illustre la situation de la flotte lorsque l'étape 50 a été atteinte pour tous les avions. Le basculement d'une version à l'autre a pu avoir lieu pour toute la flotte au cours d'une période très courte, c'est-à-dire de façon quasi-simultanée. Les versions présentes à bord n'ont pas changé mais c'est cette fois la version DB C de la base de données de customisation qui est active et non plus la version DB B.

35 Tout ou partie du procédé de l'invention pourra être commandé au moyen d'un programme d'ordinateur. Ce dernier comprend des instructions de code aptes à 2944617 -10- commander l'exécution de tout ou partie des étapes de ce procédé lorsqu'il est exécuté sur un ordinateur. Ce même programme peut être enregistré sur un support de données tel qu'un CD, un DVD ou un dispositif à mémoire flash. On peut mettre à disposition ce programme sur un réseau de télécommunications en vue de son téléchargement.

5 On voit que l'invention permet une installation progressive de la nouvelle version de la base de données de customisation sur l'ensemble de la flotte tout en permettant ensuite l'activation de cette version sur une période très courte sur toute la flotte. Par exemple, on pourra prévoir que le chargement du nouvel ensemble 24 s'effectue sur plusieurs mois pour toute la flotte alors que l'activation de la nouvelle version a lieu au 10 cours d'une même journée sur toute la flotte. L'invention implique la gestion d'une seule référence de composant pour l'ensemble comprenant les deux versions de la base de données de customisation. L'opération d'échange des versions en tant que version active peut être réalisée par le pilote lui-même sans l'intervention d'un opérateur de maintenance.

15 Bien entendu, on pourra apporter à l'invention de nombreuses modifications sans sortir du cadre de celle-ci. On pourra prévoir que l'ensemble comprend trois versions de la base de données, voire davantage. La base de données pourra concerner un autre système qu'un système alarme ou 20 d'autres données que celles des procédures textuelles, par exemple les signaux sonores des alertes. On pourra prévoir que les bases de données sont enregistrées à bord dans un autre équipement que le système d'alarme 18, pourvu qu'elles soient accessibles à ce dernier. La base de données de customisation pourra être une base du constructeur de 25 l'avion. On pourra prévoir que l'avion fonctionne à la fois avec une base de données de customisation du constructeur et une base de données de customisation de la compagnie exploitante. L'invention pourra être utilisée dans le domaine ferroviaire, par exemple dans un train, ou bien dans le domaine nucléaire, par exemple au sein d'une centrale nucléaire.

Claims

REVENDICATIONS1. Procédé pour charger des données à bord d'un aéronef (2), caractérisé en ce qu'on charge, dans un équipement de bord (27, 18) de l'aéronef, un ensemble de données (24) comprenant au moins : - une première version (24a) d'une base de données identique à une version déjà utilisée dans l'aéronef ; et - une deuxième version (24b) de la base de données, la base de données étant de préférence relative à un système d'alarme (18) de l'aéronef.
2. Procédé selon la revendication précédente dans lequel on réalise un paramétrage apte à entraîner une prise en compte de l'une prédéterminée des deux versions, notamment la première (24a), par un calculateur (18) de l'aéronef, par exemple on enregistre dans une mémoire non volatile (30) de l'aéronef un identifiant de cette version.
3. Aéronef (2) caractérisé en ce qu'il comporte un équipement de bord (18) comprenant au moins : - une première version (24a) d'une base de données, identique à une version déjà utilisée dans l'aéronef ; et - une deuxième version (24b) de la base de données, la base de données étant de préférence relative à un système d'alarme (18) de l'aéronef.
4. Aéronef selon la revendication précédente qui comprend des moyens de bord, notamment une interface homme-machine (12), pour commander un paramétrage apte à entraîner une prise en compte de la deuxième version (24b) par un calculateur (18) de l'aéronef.
5. Aéronef selon l'une quelconque des revendications 3 ou 4 qui comprend des moyens automatisés (18) pour réaliser, après la survenue d'un événement prédéterminé sans intervention humaine, par exemple l'arrivée d'une date prédéterminée, un paramétrage apte à entraîner une prise en compte de la deuxième version (24b) par un calculateur (18) de l'aéronef.
6. Procédé de commande d'un aéronef selon l'une quelconque des revendications 3 à 5 dans lequel, l'aéronef étant paramétré pour entraîner une prise en compte de la première version (24a) par un calculateur (18) de l'aéronef, on commande un paramétrage apte à entraîner une prise en compte de la deuxième version (24b) par le calculateur (18).
7. Procédé d'enregistrement de données, caractérisé en ce qu'on enregistre sur un support (26) un ensemble comprenant au moins : 2944617 -12- - une première version (24a) d'une base de données identique à une version déjà utilisée par un équipement de bord (18) d'un aéronef (2) ; et - une deuxième version (24b) de la base de données, la base de données étant de préférence relative à un système d'alarme (18) de l'aéronef. 5
8. Ensemble de données caractérisé en ce qu'il comprend au moins : - une première version (24a) d'une base de données identique à une version déjà utilisée par un équipement de bord (18) d'un aéronef (2) ; et - une deuxième version (24b) de la base de données, la base de données étant de préférence relative à un système d'alarme (18) de l'aéronef. 10
9. Support d'enregistrement de données (26), caractérisé en ce qu'il comprend, sous forme enregistrée, au moins un ensemble de données selon la revendication précédente.
10. Procédé de mise à disposition d'un ensemble de données sur un réseau de télécommunications en vue de son téléchargement, caractérisé en ce que l'ensemble est conforme à la revendication 8.