FR 2721729 A1 19951229 FR 9506157 A 19950519 MODELE CAUSAL ET PROCEDE DE DETERMINATION DE PROBLEMES POUR SYSTEMES DE RESEAUX INFORMATIQUES LOCAUX DESCRIPTION La présente invention traite, d'un point de vue général, d'un modèle causal pour la détermination de problèmes et d'un procédé pour saisir la relation entre des causes et des messages d'erreur pour des systèmes de réseaux informatiques locaux (LAN) à gérer et à analyser, et, plus particulièrement, d'un modèle causal qui représente des connaissances de résolution de problèmes et des relations entre des causes et des messages d'erreur en appliquant une approche par limitation de fautes multiples. Le modèle causal peut être utilisé par un moteur d'inférence dans un système expert pour le raisonnement diagnostique et l'analyse et le mise en corrélation de messages d'erreur. Description de l'Art Antérieur Il est fréquent que l'exploitation de système informatiques, particulièrement de réseaux informatiques locaux (LAN), soit entachée de nombreux événements d'erreur dont la majorité nécessitent la transmission de différents messages et l'occurrence e. l'exécution de nombreuses actions différentes pour lancer la procédure de reprise. Ces erreurs résultent d'une variété de conditions, comme des erreurs de configuration, des erreurs machine et des erreurs de télécommunications. A l'heure actuelle, l'analyse d'erreurs et la résolution de problèmes sont souvent gérées manuellement par les administrateurs de LAN. Cette approche présente deux problèmes. En premier lieu, les messages d'erreur contiennent souvent des informations vagues ou incomplètes - du type "erreur de programmation interne". L'administrateur doit ensuite déchiffrer le message d'erreur ou exécuter une tâche supplémentaire pour déterminer la cause effective de l'erreur. Le second problème inhérent à la résolution manuelle des codes d'erreurs est lié au fait qu'un problème donné peut souvent générer plusieurs messages d'erreurs, spécialement dans un système LAN. L'administrateur de LAN est donc souvent enseveli sous un grand nombre de message d'erreur qui doivent être analysés. De plus, la procédure d'analyse et d'étude d'erreurs réclame de nombreuses connaissances. C'est pourquoi il s'est avéré difficile de réaliser un procédé ou un système non manuel pour gérer des messages d'erreur. On a déjà tenté à plusieurs reprises de réaliser un gestionnaire d'erreurs; ces tentatives n'ont toutefois pas été couronnées de succès du fait de la grande quantité d'informations qui doivent être mémorisées et des connaissances requises. Certains gestionnaires d'erreurs ont été réalisés sur la base d'un programme en ligne compliqué, appelé dès qu'un événement d'erreur est reconnu. D'autres modes de réalisation ont utilisés un gestionnaire d'erreur "piloté par tables". Ce système s'est toutefois révélé inefficace en termes de représentation et de mémorisation, chaque événement d'erreur pouvant avoir de nombreux codes d'action et chaque paire événement d'erreur/code d'action spécifique devant être représentée. Qui plus est, aucun de ces procédés ne prévoit un système qui permette à l'utilisateur de modifier le procédé de traitement des erreurs. La gestion des erreurs nécessite que les problèmes et les causes soient mis en corrélation de façon à pouvoir analyser et fournir des informations sur l'erreur concernée. A l'heure actuelle, la plupart des systèmes de détermination d'erreurs se basent sur le postulat de la faute unique qui prône que seule une faute unique peut exister dans un système à un instant donné et que cette faute est associée à une cause unique. Le postulat de la faute unique pourrait s'appliquer à un système de réseau ou a un système informatique complexe. D'autres systèmes complexes appliquent le postulat des fautes multiples qui implique, toutefois, un volume de calculs trop important pour un système en temps réel, et qui serait, donc, dans l'incapacité de fournir des informations d'erreurs en temps réel. RESUME DE L'INVENTION La présente invention a, donc, pour objet un procédé pour mettre en corrélation des problèmes et des causes selon un postulat de fautes multiples limitées. La présente invention a également pour objet un procédé et un système pour représenter la relation entres des messages d'erreur et des causes affectives. La présente invention a aussi pour objet de mettre en corrélation des événements ou des messages d'erreur et des causes en temps réel. La présente invention traite, donc, d'un procédé et d'un système pour représenter la relation entre des événements ou des messages d'erreur et des causes effectives en temps réel dans un système informatique, et plus particulièrement dans un système de réseau informatique local. Elle traite, en particulier, d'un procédé et d'un système pour fourni un modèle causal pour l'analyse et la mise en corrélation de messages d'erreur et de causes possibles. Elle traite, de plus, d'un procédé pour associer des problèmes à des messages d'erreur. Le procédé de la présente invention permet de détecter des fautes multiples sur un système, comme un serveur ou un demandeur, et d'associer ces fautes à différents messages d'erreur. Le procédé pour représenter la relation entre des erreurs et des causes selon la présente invention utilise une série de liens, parmi lesquelles induire, impliquer ou déclencher, qui définissent les relations entre messages et causes. BREVE DESCRIPTION DES FIGURES La Figure 1 est un schéma fonctionnel illustrant une configuration matérielle sur laquelle la présente invention peut être réalisée; La Figure 2 est un schéma illustrant un exemple de système de réseau informatique local (LAN); La Figure 3 est une vue d'ensemble à haut niveau du système de gestion d'erreurs appliqué à un système LAN; et La Figure 4 est un ordinogramme illustrant le procédé d'analyse et de mise en corrélation d'événements d'erreur en utilisant le modèle causal. DESCRIPTION DETAILLEE D'UN MODE DE REALISATION PRIVILEGIE DE LA PRESENTE INVENTION En référence aux figures annexées, et plus particulièrement à la Figure 1, on peut observer un environnement matériel représentatif qui peut être utilisé comme serveur ou demandeur dans un système LAN et sur lequel la présente invention peut être réalisée. Cet environnement matériel peut être un ordinateur individuel, comme l'Ordinateur Individuel PS/2 de International Business Machines (IBM) Corporation, ou un poste de travail, comme le Poste de Travail RS/6000 d'IBM. L'équipement comprend une unité centrale de traitement (CPU) , qui peut être un microprocesseur d'ordinateur à jeu d'instructions complexe (CISC, comme le microprocesseur Internet 386, 486 ou Pentium, ou un microprocesseur d'ordinateur à jeu d'instructions réduit (RISC) comme le microprocesseur PowerPC d'IBM. L'unité centrale 10 est connectée a un bus système 12 auquel sont couplés une mémoire à accès direct (RAM) 14, une mémoire morte (ROM) 16, un adaptateur d'entrée/sortie (E/S) 18 et un adaptateur d'interface utilisateur 22. La mémoire RAM 14 assure la temporisation temporaire du code et des données du programme d'application, tandis que la mémoire morte 16 contient généralement le code du système d'entrées/sorties de base (BIOS). L'adaptateur d'E/S 18 est connecté à un ou plusieurs dispositifs de mémorisation a accès direct (DASD) représentés ici par l'unité de disque 20. L'unité de disque 20 contient généralement le système d'exploitation (OS) de l'ordinateur et différents programmes d'application qui sont chargés sélectivement dans la mémoire RAM 14 via le bus système 12. L'adaptateur d'E/S 18 peut, par exemple, assurer le support de la norme d'interface d'électronique de périphériques intégrée (IDE) ou la norme d'interface pour petit système informatique (SCSI). Dans le premier cas, l'adaptateur d'E/S 18 assure généralement le support de deux unités de disque, désignés comme les unités "C:" et "D:". Dans le dernier cas, l'adaptateur d'E/S 18 peut assurer le support d'au plus neuf unités de disque connectées en chaine. L'adaptateur d'interface utilisateur 22 est connecté à un clavier 24, une souris 26, un haut-parleur 28, un microphone 32, et/ou d'autres éléments d'interface utilisateur comme un dispositif à écran tactile (non représenté). Ce dispositif à écran tactile pourrait être installé sur le visuel 38, représenté ici par un tube à rayon cathodiques (CRT), mais qui pourrait tout aussi bien être un afficheur à cristaux liquides (LCD). Le visuel 38 est connecté au bus système 12 via un adaptateur vidéo 34. Un adaptateur de télé!communications 34 est connecté au bus et à un réseau informatique local (LAN), comme le réseau LAN à jeton circulant d'IBM. Comme on peut le voir sur la Figure 2, un réseau informatique local est un système dans lequel des ordinateurs individuels et d'autres dispositifs informatiques sont configurés de façon à pouvoir partager des ressources et échanger des données et des informations entre eux. Comme on peut le voir, un LAN comprend généralement au moins un serveur 100, 110 et souvent plus d'un demandeur 120, 130. Les serveurs sont des dispositifs qui fournissent une interface entre des périphériques et le réseau. Il existe de nombreux types de serveurs, comme des serveurs de données, d'édition, de télécommunications, des serveurs miroirs et des passerelles. Comme illustré Figure 2, LAN-EXPERT ("système expert de réseau local") est un système de détermination de problèmes pour un réseau local (LAN). LAN-EXPERT consiste en un serveur LAN-EXPERT 100 et des agents LAN- EXPERT 110, 120, 130. Les agents sont installés sur les serveurs et les demandeurs du LAN pour contrôler leur état. Lorsque des serveurs et des demandeurs du LAN délivrent des messages d'erreur, les agents LAN-EXPERT les reçoivent et les transmettent au serveur LAN- EXPERT. Les demandeurs 120 et 130 sont des agents LAN-EXPERT. Le serveur LAN-EXPERT reçoit les messages d'erreur en provenance des agents LAN-EXPERT. Le serveur LAN-EXPERT contient le moteur d'inférence, le fonds de connaissances, ainsi que d'autres éléments comme un éditeur de fonds de connaissances et une interface utilisateur graphique. Ces éléments, qui sont décrits plus loin, exécutent l'analyse et la mise en corrélation des messages d'erreur et signal les problèmes aux utilisateurs. Comme mentionné plus haut, les télécommunications et la transmission de données entre un serveur et d'autres serveurs ou périphériques sont souvent entachées d'événements d'erreur. Le système de mise en corrélation d'événements et de détermination de problèmes est un procédé destiné à un système LAN pour le diagnostic de problèmes. Il utilise un modèle de système expert et est réalisé, de préférence, en appliquant les techniques d'intelligence artificielle. Un système expert est un système qui traite l'information et exécute des fonctions de manière identique à un humain qui est un expert dans le domaine concerné. Un système expert fait des inférences basées sur les informations contenues dans un fonds de connaissances. Un fonds de connaissances est, en général, une banque de données qui contient des informations sur l'expérience humaine concernant une application particulière et des données provenant de problèmes précédemment résolus. Un moteur d'inférence est aussi un élément d'un système expert qui sert à appliquer les principes du raisonnement pour tirer des conclusions à partir des informations mémorisées dans le fonds de connaissances. Comme illustré Figure 3, le système de mise en corrélation d'événements et de détermination de problèmes est compose d'un moteur d'inférence 140 et d'un fonds de connaissances pour traiter et évaluer des événements d'erreur 160. Le fonds de connaissances contient des relations causales entre des messages d'erreur et des causes possibles. Un utilisateur peut modifier et élargir le fonds de connaissances grâce à un éditeur de fonds de connaissances. Les relations contenues dans le fonds de connaissances sont lues par le moteur d'inférence qui les utilise pour traiter les nouveaux événements d'erreur et diagnostiquer les causes possibles. Une fois les informations traitées par le moteur d'inférence, un compterendu de problèmes est généré 170. Cette procédure est décrite dans le détail plus loin. Un modèle causal est généralement composé de trois entités: des messages d'erreur, des causes, des actions recommandées. Il contient, de plus, les relations entre les trois entités. Un modèle causal est utilisé dans le fonds de connaissances pour saisir et représenter la relation entre messages d'erreur et causes effectives. Le modèle est utilisé par le moteur d'inférence à des fins de raisonnement diagnostique en temps réel pour analyser et mettre en corrélation des messages d'erreur et proposer des causes possibles. Dans le cadre de la présente invention, un événement est un avis transmis par un dispositif, comme un serveur, un gestionnaire de banque de données ou un gestionnaire de communication, au moteur d'inférence. Un événement est composé d'au moins trois entités: un message d'erreur, une machine notificatrice et une heure de création d'événement. D'autres entités peuvent etre incluses si nécessaire. Un message d'erreur, comme indiqué plus haut, fait partie d'un événement et est délivré par un dispositif, comme un serveur ou un demandeur de LAN, lorsqu'un problème est rencontré. Les agents du dispositif, en particulier le LAN- EXPERT, reçoivent les messages d'erreur et les transmettent au serveur LAN-EXPERT. En général, un message d'erreur a une identification alphanumérique et une partie texte qui consiste en une brève description du problème. La partie texte peut aussi inclure de variables auxquelles sont attribuées des valeurs au moment de l'exécution. Un message qui contient des variables ayant des valeurs effectives est appelé message immédiatisé. Un message non immédiatisé est appelé générique. Une cause, aux termes de la présente invention, est la raison sousjacente au défaut de fonctionnement et est la partie du système qui doit être rectifié. Une cause consiste en une description verbale qui peut inclure des variables. Par exemple, une raison typique peut être: Fichier X altéré. L'identité du fichier X est déterminé au moment de l'exécution. Une cause peut atre générique ou immédiatisée. D'autre part, une cause ne contient aucune information quant à la localisation du problème. Ainsi, une cause est localisée lorsqu'elle est appariée à une machine. Enfin, un compte-rendu de problème contient des informations en provenance du diagnostiaque du moteur d'inférence incluant une ou plusieurs causes, un ensemble d'événements qui sont apparentés à la cause ou aux causes et les actions recommandées pour corriger le problème. Le modèle causal de la présente invention est utilisé pour représenter dans le fonds de connaissances une variété de relations qui peuvent exister entre messages d'erreur et causes, relations qui sont utilisées par le moteur d'inférence pour mettre en corrélation des événements et des causes. L'une de relations possibles est une relation d'induction qui signifie qu'un message d'erreur particulier résulte probablement d'une cause particulière. En d'autres termes, une cause C induit un message d'erreur E qui peut être représenté par (C*induit*E). Dans la plupart des cas, pour un message d'erreur donné E, il existe plusieurs causes possibles, et pour une cause donnée C, plusieurs messages d'erreur sont générés. Cette relation contient également une mise en correspondance entre variables de message et variable de cause qui permet l'immédiatisation de la variable de cause au moment de l'exécution dès que les variables de message sont immédiatisées. Il peut également y avoir une relation entre deux causes. Une cause CI peut impliquer une cause C2 si C1 est plus spécifique que C2. Cette relation est représentée par (Cl*implique*C2). Par exemple, si Cl énonce "la limite pour la variable X DANS LE FICHIER Y a été dépassée" et C2 énonce "la limite pour la variable X dans le fichier Y est sur le point d'être dépassée", alors on peut dire que (Cl*implique*C2). Cette relation est utile en ce que, si Ci implique C2, C2 peut alors être ignorée, et le traitement peut continuer avec Cl. Il peut également y avoir une relation entre deux messages d'erreur, o un message d'erreur El peut être considéré comme déclenchant un deuxième message d'erreur E2. Cette relation est utilisée si El et E2 peuvent être induits par la même cause et si El est plus proche du problème que E2. L'expression 'plus proche' signifie que le module qui a délivré El peut être, directement ou indirectement, appelé par le module qui a délivré E2. Ainsi, si deux messages d'erreur El et E2 sont délivrés dans un lapse de temps très courts, et El déclenche E2, E2 peut généralement être ignoré et le traitement peut continuer avec El. E2 sera cependant adjoint à l'ensemble d'événements qui est signalé avec le problème. Ces relations sont utilisées pour lier des causes ou un message d'erreur. En utilisant une représentation graphique, chaque cause ou message d'erreur peut être représentée par un noeud, les relations induire, impliquer et déclencher étant le liens entre les noeuds. Les liens impliquer et déclencher peuvent être utilisés pour former deux hiérarchies au sein des causes et des messages d'erreur, respectivement. Les liens causaux connectent les noeuds entre les deux hiérarchies. L'une des propriétés essentielles de la hiérarchie d'implication est qu'un noeud de cause peut hériter de liens causaux de ces noeuds ancêtres plus généraux. Par exemple, supposons que C1 est une cause de El, que C2 est une cause à la fois de E2 et de E3, et que C2 implique CI. Ainsi, par voie de succession, C2 est aussi une cause de El. La même propriété de succession ne s'applique par à la hiérarchie de déclenchement, puisque le fait qu'un message d'erreur El peut déclencher un autre message d'erreur E2, ne signifie pas que E2 est toujours déclenché par El. En plus des relations décrites ci-dessus, d'autres informations doivent également être prises en compte. En premier lieu, il est nécessaire de tenir compte de l'emplacement de la cause. Dans certain cas, le noeud notificateur ne sera pas le noeud défaillant, et il sera donc nécessaire de déterminer o se trouve ledit noeud défaillant. Il est donc nécessaire d'associer un paramètre d'emplacement à la relation causale pour spécifier l'emplacement de la cause. Par exemple, un demandeur peut délivrer un message indiquant qu'un service est indisponible alors que la cause peut en être une défaillance du serveur. Dans ce cas, le noeud notificateur est le demandeur, mais le noeud défaillant est le serveur. Il convient aussi de tenir compte de la condition de la relation causale puisque, dans certains cas, une cause Cl n'induit une erreur El que si un deuxième message d'erreur E2 est reçu pratiquement au meme moment. En d'autres termes, certaines associations entre message et cause ne sont vraies que si le message courant est accompagné par d'autres messages qui apparaissent à peu près au même moment. Sinon, ll Cl ne peut être la cause de El. Il est donc nécessaire d'associer un paramètre de condition aux relations d'induction, d'implication et de déclenchement. Il est également nécessaire de tenir compte de la quantité de temps qui devrait s'écouler pour une relation de déclenchement. Un message d'erreur El peut être considéré comme un message d'erreur déclencheur d'un autre message d'erreur E2 uniquement si El et E2 arrivent dans une limite de temps donnée. Cette limite de temps existe pour toutes les relations de déclenchement et est configurable par l'utilisateur. Il convient également de tenir compte des variables d'insertion qui sont associées aux messages d'erreur. Les causes doivent donc aussi avoir des variables correspondantes. Cela permet de mettre en corrélation un message d'erreur avec des variables spécifiques et une cause avec des variables correspondantes. Des variables correspondantes devront aussi être spécifiées pour les relations de déclenchement, d'implication et de condition. Il convient, enfin, de tenir compte d'une relation entre cause et action, de façon à ce que, pour une cause particulière avec certaines variables, il y ait des actions recommandées correspondantes. On envisage d'utiliser un éditeur de modèle causal pour permettre à l'utilisateur d'entrer des relations entre des causes, des messages d'erreur et des actions. Ces relations, comme décrit plus haut, seront situées dans le fonds de connaissances et utilisées par le moteur d'inférence pour analyser et lettre en corrélation des messages d'erreur et donner des causes possibles et des actions recommandées. On trouvera, ci-dessous, une description de l'utilisation du modèle causal par le moteur d'inférence pour la détermination de problèmes. Comme mentionné plus haut, le modèle causal définit le mode d'expression des connaissances quant à la détermination des problèmes du LAN et leur mode de mémorisation dans un fonds de connaissances. Le modèle causal détermine aussi comment les connaissances sont utilisées par un moteur d'inférence pour exécuter la mise en corrélation d'événements et la détermination de problèmes en temps réel. La Figure 4 représente un ordinogramme illustrant un procédé dans lequel un modèle causal est utilisé par un moteur d'inférence pour la détermination de problèmes. Comme illustré Figure 4, le moteur d'inférence reçoit tout d'abord des événements d'erreur dans l'ordre de leur arrivée, 200. Pour chaque événement d'erreur, le fonds de connaissances est appelé pour identifier le message d'erreur. Si le message d'erreur est reconnu, les informations sur ses causes possibles sont extraites et adjointes à l'événement. Ensuite, le message d'erreur arrivant est comparé aux autres événements déjà reçus pour éliminer par filtrage les messages d'erreur répétés, 210. Le message d'erreur est effacé s'il est identique et s'il est reçu dans un certain lapse de temps après la réception du message précédent. Deux messages d'erreur sont identiques s'ils ont la même identification de message d'erreur et les mêmes variables d'insertion. Les messages d'erreur peuvent, toutefois, provenir de machines différentes. Le lapse de temps est configurable par l'utilisateur. Le message d'erreur est ensuite analysé pour déterminer si le message est déclenché par un autre message, 220. Le fonds de connaissances contient des informations précisant si un message d'erreur a des messages d'erreur déclencheurs. Cette relation est définie comme décrit plus haut. Si le nouveau message d'erreur a un message d'erreur déclencheur, les messages d'erreur déjà reçus sont contrôlés par le moteur d'inférence pour déterminer si le message déclencheur est arrivé ou non. Si le message déclencheur est arrivé, le nouveau message d'erreur est alors ignoré; sinon, le moteur d'inférence attendra un lapse de temps déterminable jusqu'à ce qu'un message d'erreur soit traité comme un message d'erreur normal est traité. A ce stade, le message d'erreur arrivant est comparé à des problèmes de diagnostic existants, appelés 'groupe', pour déterminer si le message d'erreur partage des causes communes avec l'ensemble des messages d'erreur du groupe, 230. Les connaissances dans le fonds de connaissances définissent les causes apparentées au nouveau message d'erreur. Si il existe des causes communes entre un message arrivant et tout cause d'un groupe existant, le nouveau message est alors adjoint au groupe existant; sinon, un nouveau groupe est créé pour un nouveau problème de diagnostique. On trouvera, ci-dessous, une description plus détaillée de la structure d'un groupe. En plus de déterminer comment regrouper un message d'erreur, le moteur détermine si une paire message/cause porte une condition, 240. Les connaissances dans le fonds de connaissances définissent quand une cause est apparentée à un message d'erreur et si une condition est adjointe à la cause. Si c'est le cas, le traitement est alors interrompu pendant un lapse de temps configurable par l'utilisateur avant d'évaluer la condition. Ensuite, les causes d'un groupe sont évaluées pour déterminer si une cause d'un groupe implique une autre cause, 250. Le relation d'implication est définie dans le fonds de connaissances en décrite plus haut. Si une cause dans un ensemble de causes d'un groupe est impliquée par une autre cause dans l'ensemble de cause, la cause implicite est alors rejetée. Enfin, s'il ne reste plus qu'une cause entièrement immédiatisée dans le groupe, un compte- rendu de problème est généré donnant des informations sur l'ensemble des messages en corrélation dans le groupe, la cause et l'action recommandée pour corriger la cause, 260. La main repasse ensuite au pavé 200. Le moteur d'inférence examine aussi l'état des groupes. Un groupe sera conservé pendant un lapse de temps configurable par l'utilisateur, appelé 'durée_vie_problème'. A l'expiration de duréevieproblème, le groupe est rejeté de la mémoire. D'autre part, un délai maximum peut être établi pour rendre compte d'un problème. Lorsque délai_max_groupe s'est écoulé, s'il existe toujours plus d'une cause dans le groupe, un compte-rendu de problème sera généré stipulant plusieurs causes. On notera qu'un événement d'erreur peut rejoindre un groupe après la génération d'un compte-rendu de problème; cela doit, toutefois, se passer avant l'expiration de duréevieproblème. Le nouvel événement fournit des informations supplémentaires pour le problème signalé. Un autre compte-rendu de problème,le compte- rendu_dernier_problème, qui contient les informations du nouveau message d'erreur, sera alors généré. Le compte- rendu_dernierproblème aura le même numéro d'identification que le compte-rendu de problème original. REVENDICATIONS 1. Procédé pour mettre en corrélation des causes et des messages d'erreur destiné à un système pour gérer des événements d'erreur dans un système de réseau informatique local (LAN), ledit procédé comprenant les étapes consistant à: prévoir une pluralité de relations causales, chacune des relations de ladite pluralité de relations causales associant un message d'erreur à au moins une cause; prévoir au moins une relation d'implication, ladite relation d'implication représentant une première cause qui implique une deuxième cause; et prévoir au moins une relation de déclenchement, ladite relation de déclenchement associant un premier message d'erreur avec un deuxième message d'erreur si ledit premier message d'erreur et ledit deuxième message d'erreur sont associés à la même cause, et ledit premier message d'erreur peut être produit par le même élément du dit LAN que ledit deuxième message d'erreur. 2. Procédé selon la revendication 1, dans lequel chacune des dites causes de ladite pluralité de relations causales est associée à une place qui définit l'emplacement de la cause. 3. Procédé selon la revendication 1, dans lequel chacune des dites causes de ladite pluralité de relations causales est associée à une condition, ladite relation causale n'étant valide que si ladite condition est satisfaite. 4. Procédé selon la revendication 1, 2 ou 3, dans lequel ladite relation de déclenchement inclut un lapse de temps configurable par l'utilisateur au cours duquel le dit premier message d'erreur et ledit deuxième message d'erreur doivent être tous les deux recus. 5. Procédé selon l'une quelconque des revendications 1 à 4, dans lequel les dites causes et les dits messages d'erreur incluent des variables, o, pour qu'une erreur soit associée à une cause, les dites variables des dites causes et des dits messages d'erreur doivent être similairement représentées. 6. Appareil pour mettre en corrélation des causes et des messages d'erreur appliquant le procédé selon l'une quelconque des revendications 1 à 5.