Brevet FR2834091A1 — publié le 20030627

informatique considéré. Des systèmes électroniques compliqués, tels que des architectures de serveurs, incluent de façon typique un logiciel du système d' exploitation et des processeurs, des dispositifs programmables, des fichiers de micrologiciel, des étages de commande d'entrée/sortie, des capteurs électroniques et des contrôleurs (désignés collectivement comme étant les "entités"). La gestion de ces entités est une tâche difficile, en particulier pendant le développement de l' architecture sous-jacente. De façon typique, pendant l'intégration de l' architecture, chacune des entités est analysoe séparément par des techniciens ou des ingénieurs pour déterminer un fonctionnement approprié et la santé globale du système. Au niveau du système, dans le cas d'une défaillance ou d'un problème généré par l'une quelconque des entités on doit en effectuer le suivi jusqu'à la source, processus qui prend du temps. La figure 1, annexce à la présente demande, représente une architecture 10 d'un système de l'art anté- rieur, qui peut fonctionner en tant que serveur connu sous le sigle UNIX comportant de multiples cel]ules de traite- ment 12A-12D. L' architecture 10 peut générer des événements se présentant fréquemment sous la forme "d'enregistrements de châssis" - à partir d'entités internes pour spécifier la santé du système pendant l'initialisation et le fonctionne ment; de telles entités peuvent par exemple inclure des processeurs internes locaux 14A-14D, des processeurs addi- tionnels 16, 17, 20, 22 et des étages d'attaque ou de com- mande d'entrée/sortie (I/O) 24A-D. Les enregistrements de châssis sont constitués en général par série d'un ou de plusieurs petits messages (déaignés sous l'expression "codes de châssis"). Lors de l'initialisation de l' architecture 10, des enregistrements de châssis sont générés par les cellules 12 et envoyés à un processeur de service 30. Un accès à ces enregistrements de châssis peut être effectué à partir du processeur de service 30 par l'intermédiaire d'un lien de communication, comme par exemple respectivement une connexion RS232 et une connexion LAN 32, 34. Collectivement, les événements (par exemple des enregistrements de châssis) générés par des entités de l' architecture 10 ne sont pas aisément évalués. Par consé- quent, les ingénieurs qui sont familiers de la conception de l' architecture 10, sont en général les seuls respons able s pour de s opérations de débogage impl iquant la santé globale de l' architecture 10. De façon spécifique, si cela est nécessaire, ces ingénieurs peuvent décoder les enregistrements de châssis et les codes de châssis à partir de toutes les entités de manière à isoler un problème; cependant, ceci requiert une série d'étapes difficiles et qui prennent du temps, comme par exemple: - fonctionnement de l' architecture jusqu'à ce qu'un pro blème soit détecté, - évaluation du problème, - contrôle des remises à zéro de puissance et des horloges, - obtention d'enregistrements de châssis, examen pratique des enregistrements de châssis et compa raison des enregistrements à des séquences de codes, - synthèse des problèmes et solutions possibles. C'est pourquoi il est nécessaire de réduire et/ou d'éliminer ces étapes pour réaliser un débogage rationnel et/ou une évaluation rationnelle d'événements (par exemple des enregistrements de châssis) à partir du micrologiciel et du logiciel du système. C'est pourquoi un but de l' invention est de fournir des procédés pour extraire des événements, séparer des événements d'entités, filtrer des événements et transformer des événements en d'autres formats. Un autre but de l' invention est de fournir un procédé pour traiter des événements transformés selon un protocole de communication largement compris. D'aures buts de l' invention apparaîtront dans le cadre de la description qui va suivre. Selon un aspect, l' invention fournit une méthodo- logie et des procédés qui permettent d'extraire, de sépa rer, de filtrer et/ou de transformer les événements générés de façon interne et dérivant d' architectures électroniques telles que des systèmes de serveurs. Les événements générés de façon interne peuvent par exemple inclure des enregistrements de chassis associés à une ou plusieurs entités dans l' architecture électronique. La méthodologie à cet égard sera quelquefois désignée ici sous le sigle "getcc". Selon un aspect particulier, la méthodologie getcc fournit une série de sous-programmes convenant pour extraire, séparer, filtrer etiou transformer des enregistrements de châssis et des codes de châssis. De préférence la méthodologie getcc sépare les enregistrements de châssis en fonction de l'entité générant l'événement. La méthodologie getcc transforme également de préférence des enregistrements de châssis (de façon typique sous forme binaire) en une chaîne de texte. Selon un aspect, ces chaînes de texte définissent un ou plusieurs problèmes de l' architecture électronique. Ces chaînes de texte sont de préférence analysées selon d'autres aspects de l' invention. A titre d'exemple, les chaînes de texte sont introduites dans une série d'analyseurs correspondant aux séries d'entités situces dans l' architecture. Selon un autre aspect, les chaînes de texte dé fini s sent un fichier de dét ail s de problèmes et une séquence de codes de châssis chaînée à des questions (par exemple des problèmes ou la santé du système) à l'intérieur de l' architecture. Selon un autre aspect, l' invention inclut un sys- tème d'outil d' extraction qui est connecté à l' architecture électronique pour extraire et analyser des événements géné rés de façon interne. A titre d'exemple, le système d'outil d' extraction inclut des modules de traitement pour traiter les fonctions getcc de manière à extraire, séparer, filtrer et transformer des enregistrements de châssis. Selon un aspect, le système d'outil d' extraction est couplé à l' architecture électronique et ensuite extrait des enregis- trements de chassis, sépare les enregistrements de chassis en fonction des entités, filtre les enregistrements de chassis et convertit une version binaire de l'enregistrement de chassis en une chaine de texte. Selon un autre aspect, l' invention fournit une méthodologie pour analyser les chaines de texte générées par la méthodologie getcc, et pour produire des instruc tions de langage représentatives d'un ou de plusieurs codes de chassis. A titre d'exemple, les instructions de langage peuvent se présenter sous la forme d' instructions en anglais fournissant une explication des problèmes apparaissant dans l' architecture électronique et/ou dans les entités individuelles. Selon un autre aspect, l' invention fournit un système d'analyse. Le système d'analyse est couplé au sys- tème d'outil d' extraction pour analyser les chaînes de texte et générer des instructions (par exemple des instruc- tions en langue anglaise) indiquant des problèmes ou des questions concernant la santé du système et associés à l' architecture électronique. Selon un aspect, le système d'analyse réalise un examen minutieux au moyen de codes de châssis et localise des erreurs; il peut également produire une explication en anglais de ces erreurs et un contexte pour ces erreurs. L' invention fournit des avantages utiles. Un ingénieur familier de l' architecture électronique peut décoder les flux binaires représentant des codes de châssis et, d'une manière associée à des entités internes, pour solutionner des problèmes. Cependant, grâce à l' invention, un technicien non familier de l' architecture électronique peut recevoir des instructions en anglais concernant les problèmes de manière à évaluer la santé du système et effectuer des opérations de débogage appropriées. L'inven- tion est utilisable notamment lors des révisions de contrôle du logiciel ou du micrologiciel installées dans l' architecture électronique. De façon plus précise l' invention concerne un procédé pour traiter des événements provenant d'une archi- tecture électronique, l'architecture du type comportant une ou plusieurs entités générant les événements, comprenant les étapes consistant à: extraire les événements de l'architecture, séparer les événements conformément aux entités, et transformer les événements en une ou plusieurs chaînes de texte. Selon une autre caractéristique, le procédé com- prend en outre l'étape de filtrage des événements. Selon une autre caractéristique, l'étape d'extraction des événements comprend l'extraction d'enregistrements de châssis, que l'étape de séparation des événements comprend la séparation des enregistrements de châssis et que l'étape de transformation d'événements com- prend la transformation des enregistrements de châssis en chaînes de texte. Selon une autre caractéristique, le procédé com- prend en outre l'étape consistant à coupler un outil d'extraction getcc à l'architecture. Selon une autre caractéristique, le procédé com porte en outre l'étape consistant à analyser les chaînes de texte et à produire une instruction interprétable par l'homme et résumant au moins l'un des événements associés aux chaînes de texte. Selon une autre caractéristique, le procédé comporte en outre l'étape consistant à commander une ou plusieurs étapes d'extraction, de séparation et de trans- formation par l'intermédiaire d'une ou de plusieurs options de lignes de commande. L' invention concerne en outre un procédé pour analyser des chaînes de texte associées à des événements provenant d'une architecture électronique, l' architecture étant du type comportant une ou plusieurs entités générant les événements, caractérisé en ce qu'il comprend les étapes consistant à: traiter les chaînes de texte, et transformer les chaînes de texte en des instruc- tions interprétables par 1'homme et résumant au moins 1'un des événements associés aux chaînes de texte. Selon une autre caractéristique, l'étape de transformation des chaînes de texte comprend la transforma- tion des chaînes de texte en une instruction en anglais signalant un ou plusieurs problèmes et la santé du système d' architecture. Selon une autre caractéristique, le procédé com prend l'envoi par messagerie électronique automatique d'au moins une partie de l' instruction à une destination de mes- sagerie automatique. Selon une autre caractéristique, le procédé com- porte en outre l'étape consistant à acquérir les chaînes de texte à partir d'un outil d'extraction couplé à l' architecture, l'outil séparant les événements en fonction des entités, et transformer les événements en une ou plu- sieurs chaînes de texte. D'autres caractéristiques et avantages de la pré sente invention ressortiront de la description donnce ci- après prise en référence aux dessins annexés, sur les- quels: - la figure 1, dont il a déjà été fait mention, représente une architecture électronique de l'art antérieur qui produit des événements associés à des entités internes; - la figure 2 est un schéma-bloc d'un outil d' extraction et d'un système d'analyse agencés conformément à l' invention; - les figures 3A et 3B illustrent un organigramme de fonctionnement pour getcc, conformément à l' invention; et - les figures 4A et 4B illustrent un organigramme de fonctionnement pour un analyseur représenté sur la figure 2, conformément à l' invention. La figure 2 représente un outil d' extraction et système d'analyse 100 agencés conformément à l'invention. La section de traitement de la fonction ou méthadologie getcc 102 est le coeur du système 100 Le système 100 commence à fonctionner en acquérant des événements générés de façon interne à partir d'une architecture électronique connoctée 104. A titre d'exemple, les événements générés de façon interne prennent la forme d'enregistrements de châssis produits par une ou plusieurs entités à l'intérieur de l' architecture 104. Dans une autre configuration, le système 100 permet d'obtenir les enregistrements de châssis à partir d'un fichier d'enregistrements 106. Une copie des événements émanant de l' architecture 104 ou du fichier d'enregistrements 106 peut être mémorisée dans le fichier d'enregistrements 109. La section de traitement de la fonction getcc 102 peut être configurée au moyen de différentes options de lignes de commande 108 pour commander le traitement d'événements (par exemple des enregistrements de châssis) de l' architecture 104. La section 102 utilise également de préférence un fichier de configurations 110 pour déterminer des options que l'utilisateur désirerait introduire dans la ligne de commande. Les figures 3A et 3B représentent un organigramme 200 illustrant des étapes de fonctionnement exécutées par la section 102 de traitement de getcc. Le traitement par la section de traitement de getoc 102 com mence (pas 202) par ltanalyse de la ligne de commande pour déterminer les options de lignes de commande sélectionnées par l'utilisateur. Les options de lignes de commande don- nées à titre représentatif et sans caractère limitatif pour la section 102 de traitement de getcc sont indiquces dans le tableau 1. Le traitement effectué par la section 102 de traitement de getcc se poursuit avec le traitement du fichier de configurations (pas 204). Tableau 1: Options de lignes de commande représentatives, de paramètres et description associée pour getcc Option Paramètres Description -1 Nom de fichier Fichier d'enregistrements de --log, codes de châssis. Le fichier --logfile) est créé, une écriture en sur inscription y est faite ou le fichier est annexé en fonction d'autres paramètres. --config Nom de fichier Spécifie le trajet et le nom du (--configufichier de configuration. S' il ration) n'est pas spécifié, un nom implicite (par exemple getcc Config.rc) peut être référencé. -c(--cell) Numéro de Spécifie les codes de châssis cellule provenant de la cellule d' ar chitecture devant être traitée. Cette option peut être utilisée - plus d'une fois dans la ligne de commande. Si elle est omise, alors tous les codes de cel lules sont traités. --proc Nombre de Spécifie que des codes de châs processeurs sis provenant à partir du nombre de processeur dans chaque cellule spécifiée doi vent être traités. Cette option peut être utilisée de multiples fois pour permettre la sélec tion de codes de châssis à par tir de plus d'un processeur. --decodecc N/A Divise le code de châssis en éléments. Le fichier de confi guration spécifie l'algorithme. -p N/A Imprlme les codes de châssis dans le fichier de sortie stan dard. S'il est omis, alors le signal de sortie provenant de l'analyseur est la seule sortie écrite pour la sortie standard (soumise à dautres options modifiant ce qui a été écrit pour la sortie standard). --default [[Entity:] Conduit à ignorer le châssis de Version] la version et la suite impli cite spécifiée devant être uti lisoe en tant que version pour l'entité spécifiée. La version est utilisée pour déterminer le fichier associé à des codes de conversion de châssis pour des chaînes de texte. N/A Spécifie que des fichiers de (--append) sortie doivent être ouverts dans le mode d'ajout. -raw Spécifie que les codes de châs sis doivent être écrits dans le fichier spécifié avant le fil trage. -i Spécifie que le fichier spéci (-f,--file) fié est utilisé pour accéder aux codes de châssis. --makeconfig [Filename] Spécifie qu'un fichier de con figuration implicite doit être créé avec le nom de fichier spécifié. Si le nom de fichier est omis, un fichier implicite (par exemple getccConfig.rc) est créé (ou est écrit en surinscription si le fichier existe). -x N/A Ecrit tous les codes de châssis filtrés pour une sortie stan dard. Par défaut, tous les codes de châssis filtrés ne sont pas convertis en une chaîne de texte. -v (--version) N/A Imprime la version du programme sur une sortie standard et sort du programme. --nonet N/A Spécifie l' invalidation des caractéristiques de mise à jour automatique. -h(--help) N/A Recense toutes les options de lignes de commande pour une sortie standard et sort du pro gramme. Le fichier de configuration du tableau 1 peut étre utilisé pour spécifier des options de lignes de com- mande et une autre information ou d'autres actions qui ne sont pas introduites aisément dans la ligne de commande. Si un fichier de configuration n'est pas spécifié, un fichier implicite (par exemple getccConfig.rc) est considéré en tant que fichier d'entrée de configuration. De façon typique, le fichier de configuration spécifie un emplace ment de l' architecture pour des mises à jour, un port désigné sous le sigle telnet pour accéder à des logiques de châssis, et des options pour chaque entité, comme par exemple l'enregistrement de châssis de révision, fichier d'enregistrements de chassis, fichier de décodage et masque d'enregistrements de chassis. Le tableau 2 indiqué ci-après recense des caractéristiques préférées et non limitatives de la configuration de fichiers: Tableau 2: Caractéristiques représentatives du fichier de configurations pour Getcc Commande Paramètres Description server auquel l'accès doit étre réa lisé par getcc pour réaliser les mises à jour, décoder des fichiers et réaliser l'analyse de fichiers. location Spécifie le répertoire conte nant les fichiers getcc dans le serveur. ccport numéro de port Pour accéder à une machine, getcc réalise une commande telnet de la machine en utilisant le numéro de port spécifié. revcc Code de châssis qui spécifie la révision d'une entité. revmask Spécifie un masque qui est pour détecter si un revcc est détecté. decodefile Spécifie le fichier de décodage qui contient la conversion du numéro de code de châssis en la chaîne de texte. script Spécifie l'outil d'analyse uti lisé par une entité pour détec ter des problèmes avec le sys tème, tous les codes de châssis pour l'entité spécifiée sont transférés au programme tel que détecté. Le programme (file name, c'est-à-dire nom de fi chier) est téléchargé du ser veur au répertoire de travail local, si non disponible. machine l'accès doit être réalisé en utilisant le systme telret pour collecter des codes de Ch5BBi B. ccmask SpAcifie un masque (XOR) qui est appliquA chaque code de chAssis partir de l'entit spAcifie avant le traitement du code de chAssis. detault Lorsqu'une entit modifie des changent Agalement. Normale ment, un code de chAs B i 8 est dAlivr par l'entit pour spA cifier la version. La version est utilise pour dAterminer quel fichier est utilisA pour convertir les codes de chAssis en des chalnes de texte. Cette option rend prioritaire la ver sion en temps rel par rapport l'entit comportant la ver sion spAcifie, pour (viter le 2s tamponnage des codes de chAssis partir d'une entit jusqu'A ce que des codes de chAssis de la version soient dAtects. physYcal Les codes de chAssis dAlivrent location Agalement des donnes. Les codes de chAssis peuvent spAci fier le type de donnes. Un type est dsignA come Atant 3s 1'emplacement physique. Ce type spécifie que les données iden tifient un élément remplagables dans la machine. Ces options spécifient un emplacement phy sique valable et la chaîne du texte d'identification. Après que la section getcc 102 a traité la ligne de commande des fichiers de configuration (pas 202, 204), la section getcc 102 contrôle l' architecture 104 (comme cela est spécifié dans le fichier de configuration) pour apporter des mises à j our à lui-même. (pas 206). S'il existe une mise à jour, l'utilisateur est averti (pas 208) du fait que la section getcc 102 doit être ou non mise à 1S j our sur la dernière révision. Les révisions peuvent être sauvegardées, et un logiciel mis à j our pour la section getcc 102 peut être à nouveau exécuté sur la base d'un choix de conception (pas 210). Une fois configuré, le flux d'entrce de code de châssis provenant de l' architecture 104 (ou du fichier d'enregistrements 106) est ouvert (pas 212). A titre d'exemple, le flux d'entrée peut produire (a) un fichier 106 qui a été utilisé pour mémoriser des codes de châssis, ou (b) une session telnet pour l' architecture 104. Si on utilise une session telnet, la section getcc 102 peut inci- ter l'utilisateur à donner un mot de passe pour accéder à l' architecture 104. Si un utilisateur du système 100 a demandé un enregistrement de codes de châssis (pas 214), alors un ou plusieurs fichiers d'enregistrements 109 sont ouverts (pas 216). Il peut y avoir plus d'un type de fichiers d'enregis trements 109. Un premier type est un fichier d'enregistre ments de codes de châssis brut. La section getcc 102 prend les codes de châssis tels qu'ils sont reçus de l'architec ture 104 et les écrit dans le fichier d'enregistrements 109 sans traitement. Une telle sortie se compose en général d'un code de chassis par ligne, avec les donnces brutes en notation hexadécimale ASCII. Un second type de fichier d'enregistrements est formé par des données de codes de châssis traités, qui contiennent des codes de chassis fil trés, les donnces hexadécimales brutes, le nom de l'entité et des conversion de chaines de texte. Conformément à une opération typique, un utilisateur enregistre les données brutes pour conserver l'ordre d'enregistrement de chassis à partir du système, et la section getcc 102 traite ensuite les donnces pour créer un second type de fichier d'enregistrements, comme cela est nécessaire. Comme pour une opération de détection de "fin de fichier", on peut lire des codes de chassis (pas 218) un par un à partir du flux d'entrée jusqu'à ce que le flux d'entrée ne contienne plus aucun code de chassis (pas 220). S'il n'existe aucun code de chassis, des versions impli cites des codes de chassis peuvent être utilisés (pas 222). S'il existe un code de chassis, le traitement suivant s'applique. 1) Si l'enregistrement brut est validé (pas 224), le code de chassis décrit dans le fichier d'enregistrements 109 (pas 226) pour conserver les données brutes et ordonner les codes de chassis lus à partir du flux d'entrée. 2) L'entité du code de chassis est extraite du code de chassis (pas 228). 3) Un contrôle est effectué pour déterminer si l'utilisa teur a demandé que l'entité spécifiée par le code de chas sis soit traitée (pas 230). Ceci peut étre réalisé par exemple dans le fichier de configurations par spécification d'un fichier de décodage pour l'entité. Si l'entité est invalidée, alors un contrôle est effectué (pas 232) pour déterminer si l'utilisateur a demandé l'impression de tous les codes de chassis dans le fichier d'enregistrements à partir de la ligne de commande. Si c'est le cas, alors le code de châssis est enregistré (pas 234). Sinon, le code de châssis est rejeté et le code de châssis suivant est lu à partir du flux d'entrée. Si l'entité spécifiée par le code de châssis doit être traitée (pas 230) le numéro de cellule est extrait du code de châssis (pas 236) si l'entité existe dans une cel- lule. Si la cellule (ou le processeur dans la cellule) n'est pas validée (par l'intermédiaire de la ligne de com- mande, pas 238), le code de châssis est resté et le nouveau code de chassis est lu à partir du flux d'entrée. Sinon, si un code de chassis a déjà été reçu de la part de l'entité qui a spécifié la révision (pas 240), le code de châssis est traité (pas 402) et le code de chassis suivant est lu à partir du flux d'entrée. Si la révision pour l'entité n'est pas connue (pas 240), le code de chassis est évalué au moyen de son code de chassis et de révision (pas 244). S'il n'existe aucun code de châssis de révision, le code de châssis est tamponné (pas 246) et la section getac attend le code de châssis de révision. Cependant si c'est le code de châssis de révision, le code de châssis de révision est mémorisé temporairement (pas 248) et le fichier de décodage est extrait de l' architecture (si le fichier de décodage n'est pas disponible, pas 250); chaque code de châssis est ensuite traité et tamponné pour l'entité spécifiée (pas 252). Les codes de châssis peuvent prendre la forme de deux nombres à 64 bits (un nombre détaillant l' information du système, et un nombre définissant l' information sensible au contexte). Conformément à des formes de réalisation pré- férées, le traitement des codes de châssis (code 252) inclut de préférence les étapes suivantes: 1) Masquage du code de châssis brut avec la valeur ccmask. 2) Conversion du code de châssis en une suite hexadéci male. 3) Enregistrement du code de châssis - si un enregistre- ment filtré est autorisé. 4) Envoi du code de châssis et de la chaîne de texte à l'analyseur associé à l'entité. La figure 2 représente plusieurs analyseurs 120 pour diffé- rentes entités à l'intérieur de l' architecture 44. A titre d' exemple, l' analyseur 120A analyse les chaînes de texte provenant de la section getoc 102 et associces à une entité micrologicielle (par exemple un processeur 20, figure 1) située dans l' architecture 104; l'analyseur 120B analyse des chaînes de texte qui proviennent de la section getcc 102 et sont associées à des entités de commande I/O (c'est- à-dire des étages de commande ou d'attaque I/O 24, figure 1) situées dans l' architecture 104; l'analyseur 120C analyse de s chaînes de texte qui proviennent de la sect ion getcc 102 et sont associées à une entité de processeur de service (par exemple le processeur de service 30, figure 1) dans l' architecture 104i l'analyseur 120D analyse les chaî nes de texte provenant de la section getcc 102 et associée avec un contrôle de modules de l' architecture 104; l'analyseur 120E analyse des chaînes de texte provenant de la section getcc 102, qui sont associées à un contrôleur de puissance de l' architecture 104; et un analyseur 120F ana lyse les chaînes de texte provenant de la section getcc 102 et associées à des quantités de processeurs de serveur local (par exemple des processeurs 14, figure 1) dans l' architecture 104. ) Si "decodecc" (tableau 1) est spécifié dans la ligne de commande, il divise le code de châssis en les différentes parties et les imprime pour une délivrance standard. Conformément à des formes de réalisation préfé- rée, il n'existe plus aucun code de châssis, les étapes suivantes sont exécutées: 2834Q91 1) Si une entit n'a pas dAlivrA un code de chAssis qui spAcifie la versicn de l'entit4, alors la conversion de ce code de chssis en texte ne seproduit pas. Dans l'attente du code de chAssis de la veraion, tous les codes de chAssis pour cette entit sonL mAmoriss temporairement. Si la fin des codes de chAssis est dAtecte avant qu'un code de chAs- sis de version soit trouvA, la version implicite pour entit est otilise pour spAcitier le fichier de conver- sion. 2) Etant donnA que 1'arrAt du flux d'entrde implique qo'il n'existe plus aucun code de chAssis, chaque entit est contrle pour dAterminer s'il existe un quelconque code de chAssis mmoris temporairement. Si c' est le cas, la version implicite pour cette entit est suppose et chaque code de chAssis est trait comme dAcrit prAcAdemment par converaion du code de chAssis en une chalne de texte, une transmission du code de chAssis l'analyseur de l'entit et enregistrements de donnes spAcifies. En outre, en rapport avec la figure 1, une inter face d'utilisateur graphique peut Atre connecte des connexions 122 pour faciliter et comander 1'entre dans le systAme lQO. [a connexion 122A permet par exemple de connecter la section getcc 102; la connexion 122B peut par exemple Atre connacte chaque analyseur 120. La connexion 122A peut par exemple faciliter 1'accs des destinat10ns de messagerie Alectronique, avec lesquelles le syGtme 100 peut transmettre des problAmes isolAs par la section getcc 102 et n'importe quel analyseur 120. La figure 4A et la figure 4B reprAsentent un organigra_ e 300, qui illustre des pas opArationnels limi tatifs effectuAs par un analyseur 120 sur la figure 2. [e pseuJo -code indiquA plus lo in faci l it e en out re la comprA hension de la figure 2, de la figure 4A et de la figure 4B. L'organigramme 300 commence au niveau du pas 302. Les para 3s mtres introduits dans l'analyseur (pas 304) incluent un fichier de détails de problèmes associé au code de châssis pour l'entité associée. Le fichier de codes de châssis est analysé (pas 306) pour le chargement en mémoire de la base de données de problèmes à partir d'un fichier. Tous les pointeurs des codes de châssis de problèmes sont ensuite supprimés (pas 308); tous les pointeurs de séquences de problèmes sont positionnés à O (pas 308). Le code de châssis suivant est alors extrait (pas 310); et ce code est comparé au code de châssis actuel suivant à partir d'un détail de problème (pas 312). Si une concordance apparait, le code de châssis est mémorisé dans le tampon de détails de problèmes et le pointeur de séquence avance (pas 314)i si aucune concordance n'apparait, le code de chassis suivant avance (pas 310). L'analyseur détermine ensuite si le code de chas sis a été le dernier code dans une séquence de quelconques détails de problèmes (pas 316). Si ce n'est pas le cas, l'analyseur détermine si le code de châssis interrompt une séquence au niveau d'un quelconque détail de problème (pas 318). Si la réponse est oui, les pointeurs de séquence sont ramenés à zéro (pas 320) pour le détail de problème particulier. Si ce n'est pas le cas, le détail de problème est exploré par balayage pour des séquences additionnelles (pas 322). Si une autre séquence existe dans le fichier de problèmes, le pointeur de séquence avance jusqu' au début de la séquence suivante (pas 324). Si aucune autre séquence n'existe, il existe un problème qui satisfait aux critères, et un résumé écrit, qui décrit le problème, est préparé (pas 326). Le détail de problème est ensuite exploré par balayage pour une information particulière concernant le problème (pas 328). Si aucun détail n'existe, un programme dédié peut exister pour l'exécution; le programme dédié est exécuté avec le code de châssis en tant qu' argument (pas 330). Une extraction illustrative avec un pseudo-code d'un détail de problème, incluant l'exécution du programme dédié, peut être représentée de la manière suivante (et tant qu'il existe des lignes dans le fichier de pro- blèmes): 1: ProblemDetail:=1 2: Examen du fichier concernant un jeton " PROBLEM xxxx" 3: Position du nom de problème ProblemDetail sur xxxx 4: SequenceID:=1 : Examen du fichier concernant un jeton " SEQUENCE " 6: CCID:=1 7: CC[SequenceID][CCID]:= ligne entière suivante du fichier 8: If : CCID:=CCID + 1 11: go to 7 12: CCDETAIL == CCDETAIL + 13: If !=" PDETAIL " then go to : NOPDETAIL:=NO 16: PDETAIL:=PDETAIL + 17: If En ce qui concerne le pseudo-code indiqué ci- dessus, "CC" désigne le code de châssisi "CCDETAIL" désigne le détail de test dont l'affichage est souhaitable pour un utilisateur du système 100; et "PDETAIL" désigne un programme (par exemple un fichier exécutable) adapté pour effectuer une analyse en profondeur du détail de problème et des codes de châssis. La syntaxe ProblemDetail inclut des éléments tels que " PROBLEM xxxx>>, données pour fournir une analyse plus sophistiquée du pro- blème. "END" termine le détail du problème. L' invention fournit certains avantages par rap port à l'art antérieur. Tout d'abord getcc agit de manière à réaliser une détection automatique de problèmes connus. En second lieu étant donné que getcc travaille de préfé rence avec des programmes logiciels, on peut accroître le niveau du système de l'outil d' extraction. En troisième lieu des problèmes détectés peuvent être détaillés pour leur examen par des personnes relativement peu entraînées. En quatrième lieu, des fichiers d'Enregistrement peuvent être examinés à distance ou être transmis à des machines à distance. Par conséquent l' invention atteint les objectifs indiqués précédemment, parmi les objectifs apparaissant dans la présente description. Etant donné que certaines modifications peuvent être apportées aux procédés et sys tèmes indiqués précédemment sans sortir du cadre de l' invention, l'ensemble des éléments de la description et des dessins annexés doit être interprété à titre d' illustration et non en un sens limitatif. LEGENDES DES FIGURES Figure 1: 30. Processeur de service 14A, 14B, 14C, 14D. Processeur de service local 16, 18, 20, 22. Processeurs (SW & OS) Prior art = Art antérieur Figure 2: 102. Section de traitement de getcc 106. Fichier d'enregistrement 122A. Sortie standard 109. Fichier d'enregistrement 110. Fichier de configuration 12OA. Analyseur progiciel 12OB. Analyseur des étages de commande I/O C. Analyseur du processeur de service D. Analyseur de puissance 12OE. Analyseur de module F. Analyseur de service local 122B. Sortie standard Figure 3A 202. Traitement d'options de lignes de commande 204. Traitement du fichier de configurations 206. Mise à j our de getcc ? 208. L'utilisateur désire la mise à j our ? 210. Mise à j our de getcc et sortie 212. Ouverture du flux d'entrée d'enregistrements de châs sis 214. Enregistrement ? 216. Ouverture de fichiers d'enregistrements 218. Obtention du code de châssis 220. CC supplémentaires ? 224. Enregistrement de données brutes ? 228. Détermination du fait que l'entité envoie le CC 222. Traitement de codes de châssis dans des piles non vides en utilisant des versions implicites 226. Ecriture du code de châssis dans le fichier d'enregis trements bruts Sur cette figure remplacer YES par OUI et NO par NON. Fiqure 3B: 232. Filtrage autorisé ? 230. L'entité est-elle autorisée ? 234. Enregistrement du code de châssis 236. Détermination du numéro de cellule de l'entité 242. Traitement du code de châssis avec le fichier de déco dage 238. La cellule et le processeur sont-ils autorisés ? 240. Révision connue ? 244. Mise en place du code de châssis sur la pile 246. Révision de CC ? 252. Traitement de la pile de codes de châssis 250. Obtention du fichier de décodage pour une version de l'entité 248. Application du code de châssis sur la pile Sur cette figure remplacer YES par OUI et NO par NON. Fiqure 4A: 302. Départ 304. Les paramètres connus sont: 1. Fichier de détails de problèmes 2. Flux de codes de châssis provenant d'une seule entité 306. Analyse du fichier de code de châssis. Ceci provoque le chargement de la base de données de problèmes d'un fichier vers la mémoire 308. Suppression de tous les pointeurs CC de codes de châs- sis de problèmes. Positionnement de tous les pointeurs de séquences de problèmes sur 0. 310. Passage au code de châssis suivant à partir du flux. 312. Le code de châssis concorde-t-il avec le code de châs- sis suivant à partir d'un quelconque détail de problème ? 314. Enregistrement de ce code de châssis dans le tampon de code de châssis de détails de problèmes et avance du poin teur de séquence 316. Etait-ce le dernier code de châssis dans une séquence d'un détail de problème queleonque ? 320. Annulation de tous les pointeurs de séquences pour ce détail de problème 318. Ce code de châssis a-t-il interrompu une séquence dans un quelconque détail de problème ? Sur cette figure remplacer YES par OUI et NO par NON. Fiqure 4B: 322. Existe-t-il une autre séquence dans ce détail de pro- blème ? 324. Avance du pointeur de séquence jusqu'au début de la séquence suivante. 326. Nous avons découvert un problème qui satisfait aux critères. Sortie imprimée de la description générale du problème (les contenus de CCDETAIL dans l'algorithme précé- dent) 328. NOPDETAIL = oui pour ce problème ? 330. Il existe un programme d'analyse intégrée présent dans ce détail de problème. L' exécution de ce problème (c' est dans PDETAIL) avec le code de châssis de séquences en tant qu' argument. Sur cette figure remplacer YES par OUI et NO par NON. REVENDICATIONS 1 Procédé pour traiter des événements provenant d'une architecture électronique (10,104), l' architecture (10,104) du type comportant une ou plusieurs entités (14,16,18,20,22,24,30) générant les événements, comprenant les étapes consistant à: extraire les événements de l' architecture (10, 104), séparer les événements conformément aux entités (14,16,18,20,22,24,30), et transformer les événements en une ou plusieurs chaînes de texte. 2. Procédé selon la revendication 1, caractérisé en ce qu'il comprend en outre l'étape de filtrage des évé nements. 3. Procédé selon la revendication 1, caractérisé en ce que l'étape d' extraction des événements comprend l' extraction d'enregistrements de châssis, que l'étape de séparation des événements comprend la séparation des enre gistrements de châssis et que l'étape de transformation d'événements comprend la transformation des enregistrements de châssis en chaînes de texte. 4. Procédé selon la revendication 1, caractérisé en ce qu'il comprend en outre l'étape consistant à coupler un outil d' extraction dit "getcc" (102) à l' architecture (10, 104). 5. Procédé selon la revendication 1, caractérisé en ce qu'il comporte en outre l'étape consistant à analyser les chaînes de texte et à produire une instruction inter prétable par l'homme et résumant au moins l'un des événe- ments associés aux chaînes de texte. 6. Procédé selon la revendication 1, caractérisé en ce qu'il comporte en outre l'étape consistant à comman- der une ou plusieurs étapes d' extraction, de séparation et de transformation par l'intermédiaire d'une ou de plusieurs options de lignes de commande. 7. Procédé pour analyser des chaînes de texte associces à des événements provenant d'une architecture électronique (10,104), l' architecture (10, 104) étant du type comportant une ou plusieurs entités (14,16,18,20,22, 24,30) générant les événements, caractérisé en ce qu'il comprend les étapes consistant à: traiter les chaînes de texte, et transformer les chaînes de texte en des instruc tions interprétables par 1'homme et résumant au moins 1'un des événements associés aux chaînes de texte. 8. Procédé selon la revendication 7, caractérisé en ce que l'étape de transformation des chaînes de texte comprend la transformation des chaînes de texte en une ins truction en anglais signalant un ou plusieurs problèmes et la santé du système d' architecture. 9. Procédé selon la revendication 7, caractérisé en ce qu' il comprend l' envoi par messagerie électronique automatique d'au moins une partie de l' instruction à une destination de messagerie automatique. 10. Procédé selon la revendication 7, caractérisé en ce qu'il comporte en outre l'étape consistant à acquérir les chaînes de texte à partir d'un outil d' extraction (102) couplé à l' architecture, l'outil séparant les événements en fonction des entités, et transformer les événements en une