Brevet FR2957164A1 — publié le 20110909

La présente invention concerne la validation de configuration de système et plus particulièrement des procédés et des dispositifs de validation de configuration d'un système multiéléments complexe tel qu'un aéronef afin, notamment, de minimiser le nombre de références à vérifier lors d'un contrôle de la configuration d'un système pour réduire la durée de l'opération de contrôle et limiter les risques d'erreurs. Les aéronefs sont des systèmes complexes comprenant typiquement des éléments matériels et des éléments logiciels. A titre d'illustration, le nombre d'emplacements logiciels dans certains aéronefs est passé de 20 dans les années 1980 à environ 1,200 en 2007. Dans un souci d'amélioration, de nombreux éléments sont changés au cours de la durée de vie d'un aéronef. Ces modifications peuvent être imposées par le constructeur pour répondre, en particulier, à des problèmes de sécurité ou demandées par la compagnie aérienne exploitant l'aéronef afin d'apporter des corrections à des disfonctionnements observés et/ou à des fins d'évolution. Ainsi, pour prendre en compte ces améliorations et ces évolutions, les compagnies aériennes doivent régulièrement effectuer des modifications matérielles ou logicielles sur les aéronefs qu'elles exploitent. Concernant les modifications décrites par le constructeur d'un aéronef, via un document généralement appelé le « Service Bulletin », les compagnies aériennes doivent systématiquement vérifier la bonne application de ces modifications via un contrôle de la configuration. Un tel contrôle consiste, par exemple, à comparer un rapport de configuration généré par un système d'un aéronef avec une configuration cible attendue définie dans une documentation. La fonction de génération de rapports de configuration dans un aéronef apportant de nombreux avantages opérationnels pour les compagnies aériennes, la conception des aéronefs intègre, pour un même périmètre fonctionnel, un nombre croissant de références, aussi appelées Part Numberou P/N en terminologie anglo-saxonne, dans les rapports de configuration. Cependant, le périmètre fonctionnel des aéronefs ne cessant de croître, le nombre de références d'éléments dans les aéronefs croît également. En outre, il est observé que les éléments logiciels pouvant être changés facilement, notamment, par téléchargement, leur mise à jour suit généralement une fréquence plus élevée que celle liée au changement d'éléments matériels. Ainsi, en raison de ces effets cumulés, les compagnies aériennes doivent donc vérifier un nombre croissant de références lors des contrôles de configuration des aéronefs. L'invention permet de résoudre au moins un des problèmes exposés précédemment en réduisant notamment le nombre de vérification à effectuer lors des contrôles de configuration visant à vérifier la conformité de configurations et/ou l'identification de références non conformes. L'invention a ainsi pour objet un procédé pour ordinateur pour générer un rapport de configuration réelle d'un système permettant la vérification rapide de la configuration dudit système, ledit système comprenant une pluralité d'éléments, au moins une référence étant associée à chaque élément de ladite pluralité d'éléments, ce procédé comprenant les étapes suivantes, - calcul d'au moins une clé de vérification selon au moins une référence de chaque élément de ladite pluralité d'éléments ; et, - génération d'un rapport de configuration réelle dudit système 25 comprenant ladite au moins une clé de vérification, une erreur de configuration dudit système étant détectée si la valeur de ladite clé de vérification est différente de la valeur d'une clé de référence. Le procédé selon l'invention permet ainsi de générer un rapport de configuration d'un système, ce rapport pouvant être utilisé pour valider 30 rapidement et facilement la configuration du système selon la valeur de la clé de vérification présente dans ce rapport. L'invention a également pour objet un procédé pour ordinateur pour la vérification rapide de la configuration d'un système comprenant une pluralité d'éléments, au moins une référence étant associée à chaque élément de ladite pluralité d'éléments, ce procédé comprenant les étapes suivantes, - calcul d'au moins une clé de référence selon au moins une référence attendue de chaque élément de ladite pluralité d'éléments ; - génération d'un rapport de configuration théorique dudit système comprenant ladite au moins une clé de référence ; et, - obtention d'un rapport de configuration réelle conformément au 10 procédé décrit précédemment, une erreur de configuration étant détectée si les valeurs desdites clé de vérification et clé de référence desdits rapports de configuration réelle et théorique sont différentes. Le procédé selon l'invention permet ainsi de valider rapidement et 15 facilement la configuration d'un système selon la valeur de clés de vérification et de référence présentes dans des rapports de configuration réelle et théorique. L'invention a aussi pour objet un procédé pour ordinateur pour générer un rapport de configuration réelle d'un système permettant 20 l'identification rapide d'une référence erronée d'un élément dudit système, ledit système comprenant une pluralité d'éléments organisés hiérarchiquement par groupes, au moins un premier groupe comprenant au moins un second et un troisième groupes distincts dudit au moins un premier groupe, au moins une référence étant associée à chaque élément de ladite pluralité d'éléments, ce 25 procédé comprenant les étapes suivantes, - calcul d'au moins une première clé de vérification associée audit au moins un second groupe selon au moins une référence de chacun des éléments dudit système appartenant audit au moins un second groupe ; - calcul d'au moins une seconde clé de vérification associée audit 30 au moins un troisième groupe selon au moins une référence de chacun des éléments dudit système appartenant audit au moins un troisième groupe ; - calcul d'une troisième clé de vérification associée audit au moins un premier groupe selon au moins les valeurs desdites au moins une première et au moins une seconde clés de vérification ; et, - génération d'un rapport de configuration réelle dudit système 5 comprenant lesdites au moins une première, au moins une seconde et une troisième clés de vérification, une erreur de configuration étant détectée si la valeur de ladite troisième clé de vérification est différente de la valeur d'une troisième clé de référence, l'emplacement de ladite erreur de configuration étant localisable à l'aide 10 desdites au moins une première et au moins une seconde clés et d'au moins une première et au moins une seconde clés de référence. Le procédé selon l'invention permet ainsi de générer un rapport de configuration d'un système, ce rapport pouvant être utilisé pour valider rapidement et facilement la configuration du système selon la valeur d'un 15 nombre limité de clés de vérification présentes dans ce rapport et pour identifier rapidement et simplement l'emplacement d'une erreur de configuration. L'invention a également pour objet un procédé pour ordinateur pour l'identification rapide d'une référence erronée d'un élément d'un système comprenant une pluralité d'éléments organisés hiérarchiquement par groupes, 20 au moins un premier groupe comprenant au moins un second et au moins un troisième groupes distincts dudit au moins un premier groupe, au moins une référence étant associée à chaque élément de ladite pluralité d'éléments, ce procédé comprenant les étapes suivantes, - calcul d'au moins une première clé de référence associée audit au 25 moins un second groupe selon au moins une référence attendue de chacun des éléments dudit au moins un second groupe, d'au moins une seconde clé de référence associée audit au moins un troisième groupe selon au moins une référence attendue de chacun des éléments dudit au moins un troisième groupe et d'une troisième clé de référence associée audit au moins un premier groupe 30 selon au moins les valeurs desdites au moins une première et au moins une seconde clés de référence ; - génération d'un rapport de configuration théorique dudit système comprenant lesdites au moins une première, au moins une seconde et troisième clés de référence ; et, - obtention d'un rapport de configuration réelle conformément au 5 procédé décrit précédemment, une erreur de configuration étant détectée si les valeurs desdites troisième clé de vérification et troisième clé de référence desdits rapports de configuration réelle et théorique sont différentes, l'emplacement de ladite erreur de configuration étant localisable à l'aide desdites au moins une première et au 10 moins une seconde clés. Le procédé selon l'invention permet ainsi de valider rapidement et facilement la configuration d'un système selon la valeur d'un nombre limité de clés de vérification et de référence présentes dans des rapports de configuration réelle et théorique et d'identifier rapidement et simplement 15 l'emplacement d'une erreur de configuration. De façon avantageuse, le procédé pour la vérification rapide de la configuration d'un système comprend en outre une étape de détermination d'une configuration théorique, ladite configuration théorique comprenant au moins une référence attendue pour chacun des éléments devant être présents 20 dans ledit système. Le procédé selon l'invention permet ainsi à un opérateur de valider facilement et rapidement la configuration d'un système, sans connaissance particulière sur le système. Le procédé comprend en outre, de préférence, une étape de modification de ladite configuration théorique selon une indication de mise à 25 jour d'au moins un élément de ladite pluralité d'éléments. Il est ainsi possible de valider facilement et rapidement la configuration d'un système après une mise à jour d'un élément de ce dernier. Selon un mode de réalisation particulier, le procédé comprend en outre une étape de génération d'un ordre de travail comprenant au moins ledit 30 rapport de configuration théorique. II est ainsi possible d'indiquer une mise à jour d'un élément d'un système à un opérateur et de fournir simultanément les moyens de valider cette mise à jour. Toujours selon un mode de réalisation particulier, au moins une desdites étapes de calcul desdites clés met en oeuvre un calcul de type contrôle de redondance cyclique, somme de contrôle, code correcteur d'erreur ou fonction cryptographique de hachage. Lesdites étapes de calcul desdites clés sont avantageusement définies selon des règles prédéterminées. L'invention a également pour objet un programme d'ordinateur comprenant des instructions adaptées à la mise en oeuvre de chacune des étapes du procédé décrit précédemment lorsque ledit programme est exécuté sur un ordinateur, un dispositif comprenant des moyens adaptés à la mise en oeuvre de chacune des étapes du procédé décrit précédemment, ainsi qu'un aéronef comprenant des moyens adaptés à la mise en oeuvre de chacune des étapes du procédé pour générer un rapport de configuration réelle d'un système tel que décrit précédemment. Les avantages procurés par ce programme d'ordinateur, ce dispositif 15 et cet aéronef sont similaires à ceux évoqués précédemment. D'autres avantages, buts et caractéristiques de la présente invention ressortent de la description détaillée qui suit, faite à titre d'exemple non limitatif, au regard des dessins annexés dans lesquels : - la figure 1 illustre un exemple de rapport de configuration d'un 20 calculateur, généré ici par le calculateur lui-même, conformément à l'invention ; - la figure 2 illustre schématiquement certaines étapes pour générer un ordre de travail comprenant un état de la configuration attendue d'un système après une mise à jour d'un de ses éléments ; - la figure 3 illustre certaines étapes effectuées pour mettre à jour 25 un élément logiciel d'un équipement d'un aéronef et vérifier la configuration de cet équipement après la mise à jour ; - la figure 4 illustre certaines étapes d'un exemple d'algorithme pour vérifier la configuration d'un équipement comprenant des applications logicielles, notamment après son remplacement ou la mise à jour d'une ou de 30 plusieurs applications logicielles ; et, - la figure 5 illustre un exemple d'architecture matérielle adaptée à mettre en oeuvre l'invention ou une partie de l'invention. Dans un souci de clarté, la description suivante est essentiellement basée sur les équipements et/ou calculateurs d'un aéronef. Cependant, l'invention peut être mise en oeuvre avec d'autres éléments d'un aéronef et plus généralement avec tout élément référencé de systèmes multiéléments. De façon générale, l'invention vise à regrouper des éléments selon des critères prédéterminés, de façon hiérarchique ou non, afin de représenter un ensemble de références par une référence unique liée à chacune des références des éléments du groupe. Une telle référence unique peut alors être utilisée pour vérifier la configuration du groupe qu'elle représente. Un tel regroupement permet ainsi de grouper des ensembles de références mais également des groupes de références. A titre d'illustration, les groupes peuvent être déterminés de façon fonctionnelle, par propriétaire et/ou par chapitre ATA (sigle d'Air Transportation Association en terminologie anglo-saxonne). Selon le regroupement fonctionnel, toutes les références d'éléments logiciels d'un équipement liés à une fonction particulière sont classées dans un même groupe. Le regroupement par propriétaire a pour objet de regrouper toutes les références d'éléments logiciels d'un équipement par fournisseurs. Selon le regroupement par chapitre ATA, toutes les références d'éléments logiciels d'un équipement sont classées groupes selon leur appartenance ATA. La table 1 donnée en annexe illustre des exemples de regroupement d'éléments logiciels d'un calculateur par fonction, par fournisseur ou chapitre ATA selon un niveau hiérarchique et par fonction et fournisseur ou chapitre ATA selon deux niveaux hiérarchiques. Le niveau hiérarchique utilisé, ou la profondeur de la hiérarchie, peut être défini en fonction du nombre maximum d'éléments à analyser dans un groupe. Le classement des références des éléments en groupes est avantageusement transcrit de façon visuelle sur le rapport de configuration utilisé par un opérateur pour vérifier la configuration de l'équipement. Ainsi, il est visuellement facile de localiser une référence ou un groupe de références erronées au sein de l'ensemble des éléments contrôlés tels que des éléments logiciels hébergés par un calculateur. Une clé de vérification est ici calculée par groupe de références afin de permettre à un opérateur de vérifier la conformité de la configuration du groupe en comparant la clé de vérification du groupe avec une clé de référence, prédéterminée, fournie dans un ordre de travail. La clé de vérification de chaque groupe, appelée clé de vérification groupe (CVG), est calculée et insérée dans le rapport de configuration accompagnant l'ensemble des références des éléments vérifiés du groupe concerné. L'objet des clés de vérification et de référence étant notamment de permettre l'attestation visuelle de la configuration d'un système ou d'un sous-système, ces clés sont, de préférence, vérifiables de façon visuelle. Avantageusement, elles doivent donc être composées d'un nombre de caractères limité, par exemple, un nombre de caractères inférieur à 15. En outre, concernant les aéronefs, l'algorithme de calcul des clés de vérification doit être développé en prenant en compte les contraintes de sécurité en vol et de disponibilité opérationnelle associées à l'équipement hébergeant les éléments considérés. A titre d'illustration, une clé de vérification ou de référence peut consister en un code de type contrôle de redondance cyclique, appelé CRC (ou Cyclic Redundancy Check en terminologie anglo-saxonne), ayant une longueur de 32 bits. La clé ainsi obtenue est composée de 8 caractères hexadécimaux pouvant être facilement vérifiée de façon visuelle. En outre, les algorithmes de calcul de code de type CRC de 32 bits permettent de satisfaire les contraintes de sécurité en vol et disponibilité opérationnelle les plus contraignantes. La valeur d'un CRC est obtenue à partir d'une partition binaire donnée, en divisant son contenu, exprimé sous forme de coefficients polynomiaux, par un polynôme fixe, appelé polynôme générateur. De façon simplifiée, le reste de la division polynomiale est la valeur utilisée comme CRC. Il existe de nombreux polynômes générateurs permettant d'obtenir des CRC dont la taille, par exemple 32 bits, peut être utilisée ici. A titre d'illustration, des polynômes générateurs de taille 32 bits couramment utilisés sont les suivants, • CRC-32-IEEE 802.3, utilisé notamment dans le protocole Ethernet et dans l'algorithme de compression de vidéo MPEG-2 ; • CRC-32C (Castagnoli), utilisé notamment dans le protocole Internet iSCSI pour établir des liens entre des centres de stockage de données ; et, • CRC-32Q, utilisé dans le monde de l'aviation, par exemple dans le cadre du modèle d'échange d'information aéronautique AIXM. Comme indiqué précédemment, un calcul de CRC n'est pas le seul moyen numérique de détection des erreurs. Ainsi, à titre d'exemple, les fonctions suivantes peuvent également être utilisées, • une somme de contrôle, aussi connue sous le nom de checksum en terminologie anglo-saxonne, utilisée de façon très étendue dans le monde de l'informatique ; • un code correcteur d'erreur, par exemple un code de Reed-Solomon, utilisé notamment par les dispositifs de lecture de disques CD (sigle de Compact Disc en terminologie anglo-saxonne) pour détecter et corriger des erreurs de lecture ; et, • une fonction cryptographique de hachage, utilisée notamment pour l'authentification d'utilisateurs à travers le réseau Internet. De façon similaire, une clé de vérification peut être calculée pour un ensemble de groupes, par exemple pour tous les groupes comprenant les références d'éléments logiciels d'un calculateur. De telles clés de vérification, appelées clés de vérification équipement (CVE), peuvent également viser d'autres éléments. Ainsi, par exemple, une clé de vérification équipement peut être déterminée selon toutes les références des éléments logiciels d'un calculateur et selon la référence du calculateur lui-même. Comme les clés de vérification groupe, les clés de vérification équipement permettent à un opérateur de vérifier simplement la conformité de la configuration logicielle d'un calculateur, par comparaison visuelle de la clé de vérification équipement avec une clé de référence prédéterminée fournie dans un ordre de travail. Les contraintes de vérifiabilité visuelle, de sécurité et de disponibilité opérationnelle applicables à une clé de vérification groupe étant typiquement les mêmes que celles liées aux clés de vérification équipement, les contraintes décrites précédemment sont ici applicables. Ainsi, un algorithme de calcul de code de type CRC de 32 bits peut également être utilisé pour calculer une clé de vérification équipement. De façon avantageuse, les références modifiées depuis un événement prédéterminé sont signalées de façon particulière. Ainsi, l'opérateur, par exemple le responsable du maintien de la configuration logicielle d'un calculateur, peut repérer visuellement les références des éléments logiciels qui ont évolués depuis un instant défini par un événement particulier. Un tel événement peut notamment être défini par l'opérateur ou lié à une phase de vol, par exemple, le démarrage du premier moteur de l'aéronef comprenant le calculateur (cet événement est représentatif de l'instant à partir duquel l'opérateur de maintenance ne peut plus modifier la configuration logicielle d'un calculateur). Lorsque l'événement a eu lieu, le calculateur identifie sa configuration et mémorise toutes les modifications apportées à la configuration. Le rapport de configuration émis par le calculateur signale alors, de façon visuelle, les références des éléments qui ont évolués depuis l'événement. La figure 1 illustre un exemple de rapport de configuration 100 d'un calculateur, généré ici par le calculateur lui-même, conformément à l'invention. Comme illustré, le rapport comprend trois sections. Une première section 105 est relative à la configuration matérielle du calculateur. Elle comprend la désignation matérielle 110 du calculateur, la référence 115 du calculateur et son numéro de série 120. Une seconde section 125 est ici relative à la configuration logicielle du calculateur. Cette section comprend autant de sous-sections qu'il y a de groupe d'éléments logiciels. Elle comprend ici p sous-sections. Chaque sous- section, représentative d'un groupe d'éléments logiciels, comprend des références des éléments logiciels et, de préférence, les désignations de ces éléments. A titre d'illustration, la sous-section 130-1 correspond à un groupe comprenant n éléments logiciels. Chaque élément logiciel i est décrit par une désignation 135-1 i et une référence 140-1i. Ainsi, par exemple, le premier élément logiciel de la sous-section 130-1 est décrit par la désignation 135-11 et la référence 140-11. Comme décrit précédemment et comme l'illustre la référence 140-12, les références peuvent être présentées de façon particulière, par exemple entre les symboles « **** », lorsqu'une modification a été détectée depuis un événement prédéterminé. Une clé de vérification groupe est associée à chaque sous-section représentant un groupe d'éléments logiciels. Ainsi, la sous-section 130-1 comprend la clé de vérification groupe 145-1. Cette dernière est calculée en fonction de toutes les références des éléments logiciels appartenant à la sous-section, c'est-à-dire, ici, à partir des références 140-11 à 140-1n à l'aide, par exemple, d'un algorithme de calcul de code de type CRC. De la même façon, la sous-section 130-2 comprend les désignations 135-21 à 135-2m et les références 140-21 à 140-2m des éléments logiciels qui lui sont associés ainsi que la clé de vérification groupe 145-2. Enfin, une troisième section 150 comprend une clé de vérification équipement 155 liée à l'ensemble des références des éléments logiciels mis en oeuvre dans le calculateur ainsi qu'à la référence du calculateur lui-même. Ainsi, à titre d'illustration, la clé de vérification équipement peut être calculée selon un algorithme de calcul de code de type CRC à partir des références de tous les éléments logiciels, c'est-à-dire des références 140-ji où j représente un index de groupe variant de 1 à p et i représente un index d'éléments pour chaque groupe, et de la référence 115. De façon avantageuse, la mise en oeuvre de l'invention permet de vérifier la configuration d'un système, par exemple d'un calculateur suite à une mise à un jour d'un de ces éléments et suite à un démontage et un remontage de ce système. Typiquement, lorsqu'une mise à jour logicielle doit être effectuée sur un équipement embarqué d'un aéronef dont la configuration doit être vérifiée, la compagnie aérienne exploitant cet aéronef reçoit un bulletin de service, généralement appelé Service Bulletin en terminologie anglo-saxonne, de la part du constructeur de l'aéronef. Ce bulletin de service comprend la liste des références des éléments logiciels devant être mis à jour sur l'équipement concerné ainsi qu'un média contenant les applications logicielles associées. De façon similaire, la compagnie aérienne peut générer des mises à jour logicielles. Par ailleurs, la configuration des aéronefs est généralement gérée et tracée (ou suivie) au sol par les compagnies aériennes à l'aide d'un document de référence appelé « Référentiel de Configuration Avion » qui est enrichi à la réception de chaque bulletin de service. II est ainsi possible, à la réception d'un tel document, de préparer un ordre de travail comprenant un état de la configuration attendue après la mise à jour. La figure 2 illustre schématiquement certaines étapes pour générer un ordre de travail comprenant un état de la configuration attendue d'un système après une mise à jour d'un de ses éléments. Une première étape a pour objet d'extraire la configuration théorique d'un équipement à partir d'un référentiel de configuration 200 (étape 205). Le rapport extrait, référencé 210, est, par exemple, similaire à celui illustré sur la figure 1. II comprend la désignation de l'équipement (LRU_A), sa référence (A) et la liste des désignations (SW_B1, SW_B2, ...) et des références (BI.0, B2.0, ...) des éléments logiciels, de préférence sous forme de groupes, ainsi que, pour l'équipement et pour chaque groupe, une clé de vérification ayant un rôle de clé de référence. Les clés de référence sont ici représentées par un nom (CVG_B, CVG_C et CVE_A) et une valeur (BB1, CC1 et MI). Il convient de remarquer que les valeurs des clés de référence ne sont pas nécessairement mémorisées dans le référentiel de configuration. Elles peuvent être recalculées lors de l'extraction d'un rapport de configuration théorique ou ultérieurement. Ces clés sont calculées selon un schéma qui peut notamment être défini dans un fichier de configuration, par exemple sous forme de règles prédéterminées exprimées sous la forme de pseudo-équations telles que les suivantes, CVG_B = CRC_32(SW_B1, SW_B2, SW_B3) CVG_C = CRC_32(SW C1, SW_C2, SW C3) CVG_A = CRC_32(CVG_B, CVG_C) selon lesquelles la clé de vérification ou de référence CVG_B est égale au résultat de la fonction CRC_32 appliquée aux valeurs SW B1, SW_B2 et SW B3, la clé de vérification ou de référence CVG_C est égale au résultat de la fonction CRC_32 appliquée aux valeurs SW Cl, SW C2 et SW C3 et la clé de vérification ou de référence CVG A est égale au résultat de la fonction CRC_32 appliquée aux valeurs CVG_B et CVG_C. Il convient de remarquer ici que, du fait des dépendances entre les règles, l'ordre de ces dernières est important. En outre, il est observé que ces règles définissent implicitement l'organisation hiérarchique des éléments dont la configuration est vérifiée via leurs références. Dans une étape suivante (étape 215), le rapport de configuration théorique extrait précédemment est mis à jour à partir d'un bulletin de service (SB) 220 ou d'un document équivalent. Chaque référence de chaque élément logiciel devant être mis à jour est alors modifiée selon les instructions du bulletin de service 220. Les références du rapport de configuration théorique 225 ainsi obtenu sont alors conformes aux attentes. A titre d'illustration, la référence de l'élément appelé SW_B2 ayant la valeur B2.0 est modifiée et devient B2.1. Les autres références ne sont ici pas modifiées. Les clés de vérification ou de référence sont alors recalculées (étape 230) pour prendre en compte les nouvelles références. Comme décrit précédemment, les clés de vérification ou de référence peuvent être calculées à l'aide d'un algorithme de calcul de code de type CRC de 32 bits. Le rapport de configuration théorique obtenu après recalcul des clés de vérification ou de référence est référencé 235. Il est observé ici que la seule modification apportée à la configuration de l'équipement LRU_A concerne l'élément SW_B2 du groupe B. Par conséquent, seule la clé de vérification groupe CVG_B doit être corrigée et, en raison de cette correction, la clé de vérification équipement CVE A doit l'être aussi. La clé de vérification groupe CVG_C n'est pas modifiée. Cependant, si seules les clés associées aux éléments dont les références ont été modifiées ont besoin d'être recalculées, il est possible de recalculer l'ensemble des clés. Ainsi, comme illustré en lien avec le rapport 235, la clé de vérification groupe CVG_B est calculée à partir des références des éléments SW_B1, SW B2 et SW B3, la clé de vérification groupe CVG_C est calculée à partir des références des éléments SW C1, SW_C2 et SW_C3 et la clé de vérification équipement CVE A est calculée à partir des références de tous les éléments mis en oeuvre dans l'équipement (SW_B1, SW B2, SW_B3, SW C1, SW C2, SW C3, ...). A partir du rapport 235 il est possible de générer (étape 240) un ordre de travail 245 (WO, sigle de Working Order en terminologie anglo-saxonne) comprenant les instructions de mises à jour telles qu'indiquées dans le bulletin de service 220 ainsi que le rapport 235 lui-même qui peut être utilisé par un opérateur de maintenance comme rapport de configuration théorique pour valider la configuration de l'aéronef après la mise à jour de l'équipement considéré. L'ordre de travail ainsi que le média comprenant les mises à jour logicielles requises peuvent alors être transmis à cet opérateur de maintenance pour lui permettre d'effectuer les opérations requises. La figure 3 illustre certaines étapes effectuées pour mettre à jour un élément logiciel d'un équipement d'un aéronef et vérifier la configuration de cet équipement après la mise à jour. Pour effectuer une telle mise à jour, un opérateur de maintenance utilise un ordre de travail ainsi qu'un média comprenant les mises à jour logicielles requises tels que décrits en référence à la figure 2. A ces fins, l'opérateur de maintenance utilise un dispositif appelé dataloader en terminologie anglo-saxonne, portable ou embarqué à bord de l'aéronef, permettant de transmettre un élément logiciel à l'équipement devant être mis à jour. II utilise également un outil permettant de générer un rapport de configuration réelle de cet équipement. Comme indiqué précédemment, un ordre de travail comprend, conformément à l'invention, un rapport de configuration théorique pouvant être utilisé pour vérifier la configuration réelle d'un équipement selon un rapport de configuration réelle. Ainsi, l'ordre de travail 300 comprend le rapport de configuration théorique 305. En outre, l'ordre de travail 300 comprend les instructions nécessaires pour permettre à l'opérateur de maintenance de mettre à jour (étape 310) un élément logiciel d'un équipement, ici le LRU_A 315. A ces fins, l'opérateur de maintenance commence par vérifier que la référence de l'équipement qu'il va devoir mettre à jour correspond bien à la référence de l'équipement mentionnée sur son ordre de travail, c'est-à-dire ici vérifier que le LRU_A installé dans l'aéronef porte bien la référence A. Dans l'affirmative, il peut procéder à la mise à jour logicielle de cet équipement au moyen d'un dataloader et des media comportant les logiciels fournis avec l'ordre de travail. Ici, le logiciel SW_B2 ayant la référence B2.1, fourni sur le media, est transféré vers le LRU_A qui le reçoit et l'installe à la place du logiciel SW B2 ayant la référence B2.0. Après la mise à jour d'un de ses éléments, l'équipement calcule les nouvelles clés de vérification selon sa nouvelle configuration. Ces clés sont calculées selon le même schéma que celui utilisé pour calculer les clés de vérification du rapport de configuration théorique. La table de configuration de l'équipement est alors mise à jour. Lorsque l'équipement a été mis à jour, l'opérateur de maintenance peut ordonner la génération d'un rapport de configuration réelle (étape 320). II peut notamment s'agir d'une commande, accessible via une interface graphique de l'équipement considéré ou de l'outil de maintenance utilisé, adressée à un outil permettant de générer un rapport de configuration réelle de cet équipement. Le rapport de configuration réelle peut également être généré automatiquement après chaque modification de la configuration d'un équipement. Typiquement, un tel outil lit une table de configuration mémorisée dans l'équipement. Alternativement, les clés de vérification peuvent être calculées après l'obtention des données de configuration réelle de l'équipement considéré. Le rapport de configuration réelle ainsi généré et dans lequel les clés de vérification ont été calculées peut alors être comparé au rapport de configuration théorique. Ainsi, l'opérateur de maintenance peut procéder de façon dichotomique en commençant par comparer la clé de vérification équipement avec la clé de référence correspondante puis, si elles ne sont pas égales, les clés de vérification groupe avec les clés de référence correspondantes et, pour celles qui ne sont pas égales, les références des éléments appartenant aux groupes dont les clés de vérification sont erronées. Ce procédé permet ainsi de vérifier et valider de manière exhaustive une configuration complexe d'un équipement comprenant de nombreuses applications logicielles différentes par une simple vérification de valeurs pré-calculées au sol avec des correspondantes calculées par l'équipement ou en lien avec lui. Ainsi, selon l'exemple de la figure 3, l'opérateur de maintenance compare la clé de vérification CVE_A du rapport de configuration réelle et la clé de référence correspondante du rapport de configuration théorique. Ces valeurs étant ici égales, l'opérateur de maintenance en déduit que toutes les références de tous les éléments de l'équipement LRU A sont bonnes sans avoir besoin de les comparer une à une. Dans le cas d'une panne d'un équipement d'un aéronef, la compagnie aérienne peut procéder à une procédure de dépose et de pose d'équipements dans le but de le remplacer par un autre équipement ayant une configuration identique. Dans le cas d'un équipement hébergeant des applications logicielles téléchargeables, l'opérateur de maintenance doit non seulement garantir la cohérence de référence de l'équipement déposé avec la référence de l'équipement installé mais également garantir la cohérence des références des applications logicielles installées. La configuration théorique de l'équipement à remplacer peut être déterminée à partir d'un référentiel de configuration comme décrit en référence à la figure 2 (étape 205). Le rapport de configuration théorique, comprenant des clés de référence, peut alors être utilisé pour générer un ordre de travail visant le remplacement de l'équipement. De même, après le remplacement d'un équipement, il est possible de générer un rapport de configuration réelle comprenant des clés de vérification. Les clés de vérification de ce rapport de configuration réelle peuvent alors être comparées avec les clés de référence correspondantes du rapport de configuration théorique pour valider le remplacement de l'équipement ou identifier rapidement le ou les éléments n'étant pas en conformité avec le rapport de configuration théorique. Le procédé est ici similaire à celui décrit en référence à la figure 3. La figure 4 illustre certaines étapes d'un exemple d'algorithme pour vérifier la configuration d'un équipement comprenant des applications logicielles, notamment après son remplacement ou la mise à jour d'une ou de plusieurs applications logicielles. Une première étape (étape 400) vise ici à extraire les données de configuration d'un équipement E à partir d'un référentiel de configuration mémorisé dans la base de données 405. Ces données de configuration sont alors utilisées pour calculer des clés de référence (étape 410) selon des règles prédéterminées mémorisées ici dans la base de données 415. Ces règles sont, par exemple, similaires à celles décrites précédemment. Les données de configuration de l'équipement E et les clés de référence associées sont ensuite regroupées au sein d'un rapport de configuration théorique 425 (étape 420). Ce rapport de configuration théorique est similaire à celui illustré sur la figure 2 portant la référence 210. Un test est ensuite effectué (étape 430) pour déterminer si la configuration théorique de l'équipement E doit être modifiée ou non (étape 430), notamment pour mettre à jour certains de ses éléments. Une telle mise à jour peut être imposée par le constructeur de l'équipement ou du dispositif dans lequel il est installé, notamment via un bulletin de service, ou par l'exploitant de ce dispositif. Si une modification de la configuration théorique doit être effectuée, la configuration théorique de l'équipement E est modifiée (étape 435). La modification peut être réalisée manuellement par un opérateur ou automatiquement à partir d'un document tel qu'un bulletin de service. La modification est ici réalisée dans le rapport de configuration théorique 425 et, de préférence, dans le référentiel de configuration. Les clés de référence sont alors recalculées (étape 440) à partir des règles utilisées précédemment et définies dans la base de données 415 afin de prendre en compte les modifications effectuées. Le rapport de configuration théorique est modifié en conséquence (étape 445). Les étapes décrites précédemment (étapes 400 à 445) sont, de préférence, réalisées dans un système informatique au sol appartenant à l'exploitant du dispositif comprenant l'équipement E, à son fabriquant ou à un tiers. Si la configuration théorique de l'équipement E ne doit pas être modifiée (étape 430) ou après l'avoir modifié et avoir modifié le rapport de configuration théorique (étapes 435 à 445), la configuration réelle de l'équipement E est déterminée (étape 450). Les clés de vérification liées à la configuration réelle de cet équipement sont ensuite calculées selon des règles utilisées pour calculer les clés de référence contenues dans le rapport de configuration théorique. Ces règles sont ici mémorisées dans la base de données 415'. Les données de configuration réelle de l'équipement E et les clés de vérification associées sont alors utilisées pour générer un rapport de configuration réelle 465 (étape 460). Les étapes de détermination de la configuration réelle de l'équipement E, de calcul des clés de vérification associées et de génération du rapport de configuration réelle (étapes 450 à 460) sont, de préférence, effectuées dans l'équipement E ou dans un équipement lié localement à ce dernier (par exemple un équipement portable ou un autre équipement du dispositif comprenant l'équipement E). La configuration réelle de l'équipement E est alors vérifiée en comparant les rapports de configuration réelle et théorique (étape 470), c'est-à-dire en comparant les clés de vérification avec les clés de référence correspondantes. L'étape 470 est typiquement réalisée par un opérateur de maintenance pour des raisons légales. Cependant, cette étape peut néanmoins être automatisée pour identifier le ou les éléments dont les références ne sont pas conformes au rapport de configuration théorique. Une telle automatisation peut notamment être basée sur un algorithme d'exploration de structures hiérarchiques. La figure 5 illustre un exemple d'architecture matérielle, par exemple un serveur, un ordinateur ou un ordinateur embarqué, adaptée à mettre en oeuvre l'invention, notamment les étapes 400 à 445 et/ou les étapes 450 à 470 de l'algorithme représenté sur la figure 4. Le dispositif 500 comporte ici un bus de communication 505 auquel sont reliés : - une ou plusieurs unités centrales de traitement ou microprocesseurs 510 (CPU, sigle de Central Processing Unit en terminologie anglo-saxonne) ; - une mémoire morte 515 (ROM, acronyme de Read Only Memory 20 en terminologie anglo-saxonne) pouvant comporter les programmes (prog, prog1 et prog2) nécessaires à la mise en oeuvre de l'invention ; - une mémoire vive ou mémoire cache 520 (RAM, acronyme de Random Access Memory en terminologie anglo-saxonne) comportant des registres adaptés à enregistrer des variables et paramètres créés et modifiés au 25 cours de l'exécution des programmes précités ; et - une interface de communication 550 adaptée à transmettre et à recevoir des données. Le dispositif 500 dispose également, de préférence, des éléments suivants : 30 - une ou plusieurs unités d'affichage 525 permettant de visualiser des données et pouvant servir d'interface graphique avec l'utilisateur qui pourra interagir avec les programmes selon l'invention, à l'aide d'un clavier et d'une souris 530 ou d'un autre dispositif de pointage tel qu'un écran tactile ou une télécommande ; - d'un disque dur 535 pouvant comporter les programmes précités, des informations à traiter selon l'invention, un référentiel de configuration, un rapport de configuration théorique et/ou réelle et/ou des règles de calcul de clés de vérification ; et - d'un lecteur de cartes mémoires 540 adapté à recevoir une carte mémoire 545 et à y lire ou à y écrire des données traitées ou à traiter selon l'invention. Le bus de communication permet la communication et l'interopérabilité entre les différents éléments inclus dans le dispositif 500 ou reliés à lui. La représentation du bus n'est pas limitative et, notamment, l'unité centrale est susceptible de communiquer des instructions à tout élément du dispositif 500 directement ou par l'intermédiaire d'un autre élément du dispositif 500. Le code exécutable de chaque programme permettant au dispositif programmable de mettre en oeuvre les processus selon l'invention, peut être stocké, par exemple, dans le disque dur 535 ou en mémoire morte 515. Selon une variante, la carte mémoire 545 peut contenir des informations, notamment des informations à traiter selon l'invention, ainsi que le code exécutable des programmes précités qui, une fois lu par le dispositif 500, est stocké dans le disque dur 535. Selon une autre variante, le code exécutable des programmes et les informations à traiter selon l'invention pourront être reçus, au moins partiellement, par l'intermédiaire de l'interface 550, pour être stocké de façon identique à celle décrite précédemment. De manière plus générale, le ou les programmes ainsi que les informations à traiter selon l'invention pourront être chargés dans un des moyens de stockage du dispositif 500 avant d'être exécutés. L'unité centrale 510 va commander et diriger l'exécution des instructions ou portions de code logiciel du ou des programmes selon l'invention, instructions qui sont stockées dans le disque dur 535 ou dans la mémoire morte 515 ou bien dans les autres éléments de stockage précités. Lors de la mise sous tension, le ou les programmes qui sont stockés dans une mémoire non volatile, par exemple le disque dur 535 ou la mémoire morte 515, sont transférés dans la mémoire vive 520 qui contient alors le code exécutable du ou des programmes selon l'invention, ainsi que des registres pour mémoriser les variables et paramètres nécessaires à la mise en oeuvre de l'invention. L'invention permet de réduire le nombre de contrôle à effectuer avec un ratio de N pour détecter une erreur de configuration et un ratio en K*N/Ln(N) pour identifier la référence d'un élément non-conforme à la configuration théorique, K étant lié aux paramètres d'implémentation utilisés. Ainsi, par exemple, pour un système comprenant 1,000 références, l'invention permet de limiter le nombre de contrôles à 1 pour détecter une erreur de configuration et à 30 pour détecter une référence erronée. Naturellement, pour satisfaire des besoins spécifiques, une personne compétente dans le domaine de l'invention pourra appliquer des modifications dans la description précédente. ANNEXE Exemples de critères de Exemples de groupes Exemples d'application groupement aéronautique Groupement par fonction • Données modifiables par l'opérateur • Calculateur de gestion du logicielle (un niveau) • Bases de données aéronautiques vol (Flight Management) de navigation • Calculateur de gestion de la • Logiciels opérationnels mission Groupement par • Fonction d'alerte de l'équipage • Plate formes d'avionique propriétaire/chapitre • Fonction commandes de vol modulaire (e .g. : modules ATA/système (un niveau) • Fonction ventilation avionique CPIOM/IOM) • Fonction de maintenance • Plate formes avioniques centralisée « monde ouvert » (e .g. : Network Server System) Groupement par fonction • Paramètres de « pin programming » • Plate formes avioniques logicielle, puis par propriétaire logiciel « monde ouvert » (e .g. : / chapitre ATA (deux niveaux) o Paramètres avion Network Server System) o Gestion du vol • Plate formes d'avionique o Alerte de l'équipage modulaire (e .g. : modules o Surveillance CPIOM/IOM) o Gestion de la mission o Gestion du carburant • Plate-formes d'affichage o Gestion de l'affichage cockpit multi-application sur le • Paramètres pour la maintenance cockpit d'un aéronef (e.g. : c entralisée Centralised Display o Hydraulique System) o Commandes de vol o Gestion des eaux sanitaires o Gestion du carburant o Gestion des moteurs • Applications hébergées o Maintenance centralisée o Surveillance de la condition de l'avion o Téléchargement et rapport de configuration o Gestion de la performance décollage/atterrissage • Plate-forme partagée o Système d'exploitation o Services de base o Diagnostique des pannes Groupement par • Gestion du vol • Plate formes avioniques propriétaire/chapitre ATA, puis o Logiciels opérationnels « monde ouvert » (e .g. : par fonction (deux niveaux) o Fichiers de paramétrage Network Server System) o Bases de données de navigation • Plate formes d'avionique o Données modifiables par modulaire (e .g. : modules l'opérateur CPIOM/IOM) • Gestion des alertes équipage o Logiciels opérationnels plate-formes d'affichage o Fichiers de paramétrage multi-application sur le cockpit d'un aéronef • Gestion de la distribution (e.g. : Centralized Display électrique System) Exemples de critères de Exemples de groupes Exemples d'application groupement aéronautique o Logiciels opérationnels o Fichiers de paramétrage • Plate-forme partagée o Système d'exploitation o Services de base o Diagnostique des pannes Table 1 REVENDICATIONS1. Procédé pour ordinateur pour générer un rapport de configuration réelle d'un système permettant la vérification rapide de la configuration dudit système, ledit système comprenant une pluralité d'éléments, au moins une référence étant associée à chaque élément de ladite pluralité d'éléments, ce procédé étant caractérisé en ce qu'il comprend les étapes suivantes, - calcul (455) d'au moins une clé de vérification (155) selon au moins une référence de chaque élément de ladite pluralité d'éléments ; et, - génération (460) d'un rapport de configuration réelle dudit système comprenant ladite au moins une clé de vérification, une erreur de configuration dudit système étant détectée si la valeur de ladite clé de vérification est différente de la valeur d'une clé de référence. 2. Procédé pour ordinateur pour la vérification rapide de la configuration d'un système comprenant une pluralité d'éléments, au moins une référence étant associée à chaque élément de ladite pluralité d'éléments, ce procédé étant caractérisé en ce qu'il comprend les étapes suivantes, - calcul (410) d'au moins une clé de référence selon au moins une référence attendue de chaque élément de ladite pluralité d'éléments ; - génération (420) d'un rapport de configuration théorique dudit système comprenant ladite au moins une clé de référence ; et, - obtention d'un rapport de configuration réelle conformément à la 25 revendication précédente, une erreur de configuration étant détectée si les valeurs desdites clé de vérification et clé de référence desdits rapports de configuration réelle et théorique sont différentes. 3. Procédé pour ordinateur pour générer un rapport de configuration 30 réelle d'un système permettant l'identification rapide d'une référence erronée d'un élément dudit système, ledit système comprenant une pluralité d'éléments organisés hiérarchiquement par groupes, au moins un premier groupecomprenant au moins un second et un troisième groupes distincts dudit au moins un premier groupe, au moins une référence étant associée à chaque élément de ladite pluralité d'éléments, ce procédé étant caractérisé en ce qu'il comprend les étapes suivantes, - calcul (455) d'au moins une première clé (145) de vérification associée audit au moins un second groupe selon au moins une référence de chacun des éléments dudit système appartenant audit au moins un second groupe ; calcul (455) d'au moins une seconde clé (145) de vérification associée audit au moins un troisième groupe selon au moins une référence de chacun des éléments dudit système appartenant audit au moins un troisième groupe ; - calcul (455) d'une troisième clé (155) de vérification associée audit au moins un premier groupe selon au moins les valeurs desdites au moins une 15 première et au moins une seconde clés de vérification ; et, - génération (460) d'un rapport de configuration réelle dudit système comprenant lesdites au moins une première, au moins une seconde et une troisième clés de vérification, une erreur de configuration étant détectée si la valeur de ladite troisième clé de 20 vérification est différente de la valeur d'une troisième clé de référence, l'emplacement de ladite erreur de configuration étant localisable à l'aide desdites au moins une première et au moins une seconde clés et d'au moins une première et au moins une seconde clés de référence. 4. Procédé pour ordinateur pour l'identification rapide d'une 25 référence erronée d'un élément d'un système comprenant une pluralité d'éléments organisés hiérarchiquement par groupes, au moins un premier groupe comprenant au moins un second et au moins un troisième groupes distincts dudit au moins un premier groupe, au moins une référence étant associée à chaque élément de ladite pluralité d'éléments, ce procédé étant 30 caractérisé en ce qu'il comprend les étapes suivantes, - calcul (410) d'au moins une première clé de référence associée audit au moins un second groupe selon au moins une référence attendue de chacun des éléments dudit au moins un second groupe, d'au moins une seconde clé de référence associée audit au moins un troisième groupe selon au moins une référence attendue de chacun des éléments dudit au moins un troisième groupe et d'une troisième clé de référence associée audit au moins un premier groupe selon au moins les valeurs desdites au moins une première et au moins une seconde clés de référence ; - génération (420) d'un rapport de configuration théorique dudit système comprenant lesdites au moins une première, au moins une seconde et troisième clés de référence ; et, - obtention d'un rapport de configuration réelle conformément à la revendication précédente, une erreur de configuration étant détectée si les valeurs desdites troisième clé de vérification et troisième clé de référence desdits rapports de configuration réelle et théorique sont différentes, l'emplacement de ladite erreur de configuration étant localisable à l'aide desdites au moins une première et au moins une seconde clés. 5. Procédé selon la revendication 2 ou la revendication 4 comprenant en outre une étape de détermination (400) d'une configuration théorique, ladite configuration théorique comprenant au moins une référence attendue pour chacun des éléments devant être présents dans ledit système. 6. Procédé selon la revendication précédente comprenant en outre une étape de modification (435) de ladite configuration théorique selon une indication de mise à jour d'au moins un élément de ladite pluralité d'éléments. 7. Procédé selon la revendication précédente comprenant en outre une étape de génération d'un ordre de travail comprenant au moins ledit rapport de configuration théorique. 8. Procédé selon l'une quelconque des revendications précédentes selon lequel au moins une desdites étapes de calcul desdites clés met en oeuvre un calcul de type contrôle de redondance cyclique, somme de contrôle, code correcteur d'erreur ou fonction cryptographique de hachage. 9. Procédé selon l'une quelconque des revendications précédentes selon lequel lesdites étapes de calcul desdites clés sont définies selon des règles prédéterminées. 10. Programme d'ordinateur comprenant des instructions adaptées à la mise en oeuvre de chacune des étapes du procédé selon l'une quelconque des revendications précédentes lorsque ledit programme est exécuté sur un ordinateur. 11. Dispositif comprenant des moyens adaptés à la mise en oeuvre de chacune des étapes du procédé selon l'une quelconque des revendications 10 1 à9. 12. Aéronef comprenant des moyens adaptés à la mise en oeuvre de chacune des étapes du procédé selon la revendication 1, la revendication 3 ou l'une quelconque des revendications 8 et 9 dépendante de la revendication 1 ou de la revendication 3. 15