FR 2655443 A1 19910607 FR 9015042 A 19901130 La présente invention a pour objet un procédé et appareil pour retrouver des cas appropriés de façon justifiée dans une bibliothèque de cas dans le but de résoudre un problème Plus précisément, l'invention a pour objet un système de raisonnement à base de cas d'intelligence artificielle qui trouve des cas stockés qui sont appropriés à un problème présenté au système de raisonnement, ces cas retrouvés apportant une solution au problème présenté. Arrière-plan de l'invention Le raisonnement à base de cas est une technique i 5 d'intelligence artificielle mise en oeuvre avec un ordinateur qui accepte la description d'un problème et qui utilise une base de données de cas antérieurs dans le but de trouver une solution au problème posé Le terme 'cas' se réfère à une expérience de résolution d'un problème. Un système de raisonnement à base de cas a comme composants un "récupérateur" de cas,' un "raisonneur" de cas et une bibliothèque de cas Le récupérateur de cas retrouve un ou plusieurs cas qui sont stockés dans la bibliothèque de cas à chaque fois qu'un nouveau problème a besoin d'être résolu Le raisonneur de cas obtient ces cas à partir du récupérateur de cas et présentera la solution à l'utilisateur, ou bien il modifiera les solutions des cas retrouvés, selon les besoins, dans le but de résoudre le nouveau problème. Un système de raisonnement à base de cas connu s'applique dans le domaine des diagnostics médicaux. Dans ce système, chaque cas comporte les symptômes d'un patient, le diagnostic de son problème et une thérapie. Le système retrouve les cas qui semblent appropriés au problème qu'il est en train d'essayer de résoudre, et il utilise les connaissances du domaine dans le but de "justifier' que chaque cas retrouvé était vraiment approprié Cependant, ce système connu n'est pas capable d'apprendre les résultats d'une tentative de justification dans le but d'utiliser ces résultats pour justifier ou invalider d'autres cas qui sont retrouvés initialement En outre, ce système suppose que les cas retrouvés sont appropriés, et également que les cas qui sont retrouvés ne sont pas nombreux En faisant ces suppositions, ce système de raisonnement à base de cas de diagnostics médicaux se concentre sur la façon de modifier la thérapie qui est associée au cas retrouvé, au lieu de s'assurer que les cas retrouvés sont appropriés de façon justifiée. Un autre système de raisonnement à base de cas a été décrit pour le diagnostic et la réparation des tondeuses à gazon Chaque cas de la bibliothèque de cas consiste en un diagnostic d'un problème particulier de tondeuse à gazon et en la réparation qui résout le problème Dans ce système, on suppose que seule une série de cas apparentés serait retrouvée, chose qu'il n'est pas toujours possible de -garantir Afin de justifier chaque cas retrouvé, le système utilise ce qui est connu sous le nom de règles de chaînage inverse Utiliser ces règles empêchera le système de grandir d'échelle, (en augmentant la taille des règles pour augmenter la profondeur du système) étant donné que pour une base de données réaliste le nombre de règles de chaînage inverse peut être considérablement grand Dans ce système, les résultats du processus de justification ne sont pas appris et en conséquence, ils ne peuvent pas être utilisés dans la justification d'autres cas retrouvés de la série de cas apparentés qui sont retrouvés initialement. D'autres systèmes de raisonnement à base de cas existants font essentiellement deux hypothèses La première hypothèse est que les composants de récupération des cas retrouveront un seul cas dans la bibliothèque de cas à chaque fois qu'un nouveau problème devra être résolu La seconde hypothèse est que le cas retrouvé sera un cas approprié de façon justifiée Les systèmes existants, par conséquent, se concentrent sur la façon de modifier la solution qui est associée à un cas retrouvé dans le but de résoudre un nouveau problème Afin de garantir qu'un seul cas est retrouvé dans la bibliothèque de cas, ces systèmes existants utilisent différents procédés pour organiser la bibliothèque de cas, et reposent sur des techniques heuristiques afin de déterminer la meilleure façon de chercher dans la bibliothèque de cas Toutefois, ils ne vérifient pas si le cas retrouvé est véritablement (ou de'façon justifiée) approprié En d'autres termes, ils ne vérifient pas au-delà des similudes apparentes com- munes au cas retrouvé et au nouveau problème. -Un utilisateur humain devrait être uniquement confronté à des cas qui sont appropriés de façon justifiée dans le but de réduire le temps nécessaire à la résolution du problème présenté au système La présentation d'un grand nombre de cas appropriés sans justification obligera l'utilisateur à essayer un nombre de solutions qui seront sans rapport avec le nouveau problème Il existe, par conséquent, un besoin d'un système de raisonnement à base de cas dans lequel seuls les cas qui sont appropriés de façon justifiée sont retrouvés et présentés à un raisonneur de cas et en dernier à l'utilisateur du système. Résumé de l'invention Un composant de récupération de cas, qui peut être utilisé en lui-même ou conjointement avec un système de raisonnement à base de cas, qui renvoie les cas qui sont appropriés de façon justifiée à un problème, est fourni par la présente invention qui comprend un procédé pour effectuer un raisonnement à base de cas avec un système de raisonnement à base de cas Le système utilise une bibliothèque de cas, un J récupérateur de cas et un raisonneur de cas Le procédé comprend l'obtention' des symptômes d'un nouveau problème, et la récupération d'une série de cas stockés dans une bibliothèque de cas fondés sur les symptômes du problème Chaque cas a des symptômes, une c explication causale et une solution Il est ensuite déterminé si un cas et la série de cas qui est retrouvée sont appropriés de façon justifiée au problème fondé sur l'explication causale du cas Ces cas,qui ont été déterminés comme étant appropriés de façon justifiée au problèmesont ensuite renvoyés à un utilisateur du système de raisonnement à base de cas ou à un raisonneur de cas Dans certaines réalisations, il existe une étape supplémentaire qui consiste à apprendre si d'autres cas de la série de cas retrouvés sont appropriés de façon justifiée au problème Cela se fait d'après les informations obtenues pendant l'étape de détermination. La présente invention fournit un système de récupération de cas qui effectue une récupération initiale de cas à partir d'une bibliothèque de cas fondés sur les caractéristiques ou les symptômes apparents d'un problème Cependant, la présente invention examine cette série de cas retrouvés pour déterminer si chaque cas est approprié de façon justifiée au problème Elle effectue cela d'après l'explication causale du cas De cette manière, seuls les cas appropriés de façon'justifiée seront envoyés à un utilisateur, de sorte que l'utilisateur ne perdra pas de temps à essayer d'appliquer une solution inexacte à un problème. Brève description des dessins La figure 1 est un schéma de principe d'un système de raisonnement à base de cas construit conformément à une réalisation de la présente invention. La figure 2 est un schéma de principe illustrant une application du système de raisonnement à base de cas de la figure 1 pour résoudre les problèmes relatifs au système d'exploitation d'un ordinateur. La figure 3 est une représentation schématique d'un modèle causal utilisé dans le système de raisonnement à base de cas de la figure 1. La figure 4 est un diagramme schématique d'une explication causale utilisée dans le système de raisonnement à base de cas de la figure 1. Description détaillée Un système de raisonnement à base de cas est montré dans la figure 1 et est désigné par la référence numérique 10 Le système 10 peut être utilisé dans de nombreuses applications, tel que l'analyse de logiciel, l'analyse de matériel, la conception de programme, etc. A ce titre, une présentation générale du système 10 et de son fonctionnement sera tout d'abord décrite. Toutefois, pour des raisons explicatives et de clareté, une description plus détaillée du fonctionnement du système 10 sera donnée en se reportant à une application spécifique du système 10 La description de l'application spécifique du système 10 devrait rendre plus clairs certains termes décrivant l'invention, mais l'invention -ne se limite pas à cette application spécifique. Le système 10 montré dans la figure 1 a une bibliothèque de cas 12 dans laquelle un certain nombre de cas sont stockés Dans la présente invention, un cas est une entrée de base de données qui, comporte les symptômes du problème, la cause d'un problème et une solution au problème Lorsqu'un nouveau problème est présenté au système 10, les informations (ou symptômes) relatives au nouveau problème sont entrées dans un récupérateur de cas 14 Le nouveau problème est examiné par le récupérateur de cas 14 afin de déterminer les caractéristiques les plus importantes du nouveau problème En utilisant ces caractéristiques les plus importantes, le récupérateur de cas 14 interroge la bibliothèque de cas et retrouve les cas qui sont jugés initialement appropriés au nouveau problème. Le récupérateur de cas 14 met en forme l'interrogation (c'est-à-dire détermine les caractéristiques qui sont les plus importantes) en utilisant les connaissances sémantiques stockées dans une base de données de connaissances sémantiques 18 Le terme 'connaissances sémantiques" se réfère à ce qui peut être considéré comme connaissances générales r comprenant les attributs et les rapports qui existent entre ces attributs du domaine spécifique ou de l'application pour laquelle le système 10 est utilisé. Cela sera encore plus clair lorsque les réalisations spécifiques données en exemple seront décrites. Une fois que le récupérateur de cas 14 a retrouvé les cas dans la bibliothèque de cas 12 en utilisant les connaissances sémantiques contenues dans la base de données de connaissances sémantiques 18, le récupérateur de cas 14 effectue alors une justification pour chacun des cas qui a été retrouvé Cette justification comprend la réalisation d'une des deux actions La première action est l'acceptation d'un cas retrouvé parce qu'il est approprié de façon justifiée au problème à résoudre, ce qui entraîne l'acceptation automatique des autres cas retrouvés qui sont jugés de la même façon appropriés au problème en suspens Cette acceptation automatique des autres cas retrouvés sera fondée sur les informations qui sont apprises pendant la justification du cas que le récupérateur de cas 14 est en train d'examiner et elle sera décrite plus en détails plus loin. La seconde action est le rejet d'un cas retrouvé parce qu'il n'est pas approprié, avec le rejet automatique des autres cas retrouvés qui sont également jugés inappropriés au problème en suspens Ce rejet automatique sera également fondé sur les informations qui seront apprises pendant la justification du cas que le récupérateur de cas 14 est en train d'examiner. Cet "apprentissage" au cours de la justification d'un cas est un premier type d'apprentisgage effectué par le système de raisonnement _ à base de cas de la présente invention Un second type d'apprentissage se produit une fois que le nouveau problème a été résolu (ou non résolu), les informations acquises pendant la session de résolution du problème étant stockées dans un nouveau cas, dans la bibliothèque de cas 12 Ce second type d'apprentissage peut être considéré comme un type permanent d'apprentissage comparé au premier type, qui est supprimé après la session de résolution du problème - La justification s'effectue en essayant de faire correspondre au nouveau problème une "explication causale" qui est incluse dans le cas retrouvé qui est justifié Cette correspondance comprend la réalisation de tests sur le nouveau problème et l'interprétation des résultats de chaque test par rapport aux résultats correspondants du cas dont l'explication causale est utilisée Si la correspondance réussit, alors le cas retrouvé est considéré comme étant approprié de façon justifiée parce qu'il peut expliquer ce qui aurait pu causer le nouveau problème Les composants d'une explication causale sont: la cause du problème; les étapes causales qui soutiennent la validité de la cause (désormais connues comme étape de soutien); et la manifestation du problème. Il existe une correspondance de l'explication causale d'un cas retrouvé avec un nouveau problème lorsque les deux conditions suivantes sont satisfaites. La première condition est que la manifestation du problème,dans le cas retrouvé,corresponde exactement à la manifestation du nouveau problème L'autre condition qui doit être satisfaite pour assurer une correspondance est que les étapes de soutien de l'explication causale du' cas retrouvé expliquent exactement ce qui a causé le nouveau problème, ou bien qu'elles puissent être modifiées de sorte que les étapes de soutien fournissent l'explication. La correspondance d'une explication causale nécessite que le récupérateur de cas 14 ait accès à ce is qui est connu comme "modèle causal" Un modèle causal est utilisé pour produire l'explication causale asso- ciée au cas retrouvé qui est en train d'être justifié Avoir accès à ce modèle causal permet au récupérateur de cas 14 d'interpréter les résultats du processus de correspondance et de déterminer quelles étapes de soutien de l'explication causale peuvent être modifiées Un modèle causal est défini comme une représentation d'un comportement et d'une structure de dispositif Une description plus détaillée d'un modèle causal sera fournie plus loin en référence à une réalisation spécifique de l'invention. En outre, le récupérateur de cas 14 utilisera également le modèle causal du nouveau problème afin d'accepter ou de rejeter automatiquement les autres cas qui ont déjà été retrouvés Par l'intermédiaire du modèle causal, le récupérateur de cas 14 est en mesure de déter iner les implications de chaque nouvelle information qui est apprise pendant la justification d'un cas particulier C'est le premier type d'apprentissage que le système de raisonnement à base de cas effectue, comme cela a été décrit précédemment. Les modèles causals sont stockés dans une base de données de modèles causals 20, reliée au récupérateur de cas 14. Comme cela a été expliqué auparavant, chaque explication causale a ce qui est connu comme étapes de soutien Chaque étape de soutien est essentiellement une contrainte violée Afin de pouvoir faire correspondre l'explication causale d'un cas retrouvé à un nouveau problème, chaque étape de soutien d'une explication causale de ce cas retrouvé désignera l'étape du modèle causal (une "étape de modèle causal") ayant fourni une valeur que la contrainte viole En d'autres termes, les étapes de modèle causal fournissent des valeurs,et une étape de soutien d'une explication causale désignera cette étape de modèle causal ayant eu une valeur pour laquelle il y a eu une violation de contrainte De cette manière, tous les cas retrouvés sont "attachés" à une étape de modèle causal. Chaque étape de modèle causal est associée à un test. Une étape de modèle peut avoir plusieurs tests associés à elle-même. Dans le second processus, le processus de justification, le récupérateur de cas 14 place initialement tous les cas qui ont été renvoyés, d'après les symptômes du nouveau problème, dans une série appelée "la série retrouvée" Un cas est sélectionné parmi la série retrouvée, ce cas sélectionné étant appelé "le cas candidat" La première étape de soutien du cas candidat est invoquée Cela provoque l'exécution du test associé à l'étape de modèle causal que l'étape de soutien désigne sur le nouveau problème l'exécution de ce test entraîne l'acquisition de la donnée qui correspond à la contrainte associée à l'étape de soutien invoquée. Si la valeur acquise est identique à celle de l'étape de soutien, alors tous ces cas retrouvés de la série retrouvée, attachés à la même étape de modèle causal, sont placés par le récupérateur de cas 14 dans une série appelée "la série active" La série active est ainsi une sous-série de la série retrouvée et contient les cas que le raisonneur de cas 14 essaye activement de justifier Chaque cas de la série active est un candidat au cas approprié de façon justifiée. Si la valeur acquise n'est pas identique à celle de l'étape de soutien, alors le récupérateur de cas 14 doit déterminer si la valeur acquise invalide le cas candidat ou si l'étape de soutien du cas candidat peut être adaptée Lorsque l'étape de soutien ne peut pas être adaptée telle que déterminée par l'intermédiaire des connaissances du modèle causal, alors l'explication causale et par conséquent le cas candidat est rejeté En outre, tous les cas avec des étapes de soutien identiques sont automatiquement rejetés également,, c'est-à-dire, supprimés de la série active. S'il y a d'autres étapes de soutien à examiner, alors le récupérateur de cas retourne au processus d'invocation d'autres étapes de soutien du cas candidat, d'exécution du test compris dans les étapes de modèle causal désignées et d'acquisition d'une valeur Les étapes de soutien sont invoquées dans l'ordre exact dans lequel elles existent au sein d'une explication causale. Lorsqu'il n'y a plus d'étapes de soutien à justifier à partir du cas condidat, le cas candidat, ainsi que tous les cas de la série active qui n'ont plus d'étapes de soutien à justifier, sont placés dans ce qui est connu comme étant la "série justifiée" Les cas de la série justifiée sont une sous-série de cas de la série active et sont considérés comme étant appropriés de façon justifiée Les cas restant dans la série active ont une explication causale qui sont des super-séries de l'explication causale du cas candidat - Un des cas qui reste dans la série active devient maintenant le nouveau cas candidat Le I.:: récupérateur de cas 14 se remet à invoquer les étapes de soutien, etc. Une fois que tous les cas de la série active sont finalement soit transférés vers la série justifiée soit rejetés, le récupérateur de cas 14 recommence le processus mentionné ci-dessus, en commençant par la sélection d'un autre cas candidat parmi la série retrouvée. Lorsque la série retrouvée et la série active sont vides, et que la série justifiée ne l'est pas, les cas de la série justifiée sont transférés au raisonneur de cas 16 du système 10 Si, toutefois, les deux séries justifiées et les séries retrouvées sont vides, la commande est renvoyée à l'utilisateur du système. 1-5 Ce qui suit est une description d'une application spécifique du système 10 qui rendra plus clair le fonctionnement et les termes qui sont utilisés ci-dessus pour décrire le système 10 en général. L'application spécifique décrite est celle d'un système de raisonnement à base de cas qui résout un problème se produisant dans un système d'exploitation d'ordinateur. Un système d'exploitation d'ordinateur est une collection intégrée de programmes qui contrôle l'exécution de programmes informatiques et le matériel informatique. Un système d'exploitation est en mesure de déceler les erreurs internes et d'émettre des drapeaux qui codifient chaque erreur en fonction de son type. Lorsqu'une erreur interne est sérieuse au point que les opérations normales ne peuvent pas continuer, le système d'exploitation tombe en panne et émet un état connu d'erreur fatale Si cela se produit, le système d'exploitation s'arrête de façon ordonnée En accomplissant cela, il sauvegarde dans un fichier de décharge d'incident le contenu de tous les registres de l'unité centrale, les piles et les tampons, ainsi que le contenu de la mémoire physique au moment ou l'état d'erreur interne fatale est déclenchée. Chacun des différents codes d'état d'erreur fatale correspond à un type d'erreur particulier La cause sous-jacente d'une erreur peut être, par exemple, des défaillances de matériel ou des erreurs dans le système d'exploitation. Chaque fichier de décharge d'incident a une en- tête qui contient des informations importantes pour comprendre la panne Ces informations, connues comme étant soit des symptômes soit des caractéristiques apparentes, comprennent la valeur du compteur de programme, le nom du processus qui était en train de se dérouler lorsque la panne s'est produite et la version du système d'exploitation présent dans l'ordinateur, par exemple. La figure 2 montre une configuration dans laquelle le système 10 de la présente invention est capable de résoudre les problèmes se produisant dans le système d'exploitation d'un ordinateur 30 Un analyseur de décharge du système classique 32 est relié entre le système 10 de la présente invention et l'ordinateur 30 qui connaît des problèmes Cet analyseur de décharge du système 32,, sous le* contrôle d'n utilisateur, analysera le fichier de 'décharge d'incident contenu dans l'ordinateur 30 et il enverra les informations analysées au récupérateur de cas 14. Comme première étape, le récupérateur de cas 14 examine le fichier de décharge d'incident de la panne actuelle et extrait un code d'état et un compteur de programme En examinant le'compteur de programme, le récupérateur de cas 14 peut déterminer la partie du logiciel (un "module du logiciel") o la panne s'est produite A partir de l'emplacement de ce module du logiciel et des connaissances sémantiques du système d'exploitation contenues dans la base de données de connaisances sémantiques 18 (décrites de façon plus détaillée ci-après), lerécupérateur de cas 14 est en mesure d'identifier le type de module du logiciel Les types de module du logiciel dans un système d'exploitation peuvent comprendre un programme de gestion de périphériques, une unité de gestion de mémoire, etc Le récupérateur de cas 14 diffusera ensuite, à la bibliothèque de cas 12,un message qui contenant le code d'état et le type de module o la panne s'est produite Il diffusera également d'autres informations (telles que le type d'UC) à chaque fois que cela aidera à réduire le nombre de cas appropriés proposés pour résoudre le nouveau problème. Comme cela a été mentionné ci-dessus, la base de données de connaissances sémantiques 18 est utilisée lorsqu'on effectue la récupération initiale des cas et elle contient ce qui est appelé les "connaissances dossier" générales concernant le système d'exploitation. Ces connaissances sont utilisées par le récupérateur de cas 14 en interprétant les symptômes (caractéristiques apparentes) qui décrivent une panne, tels qu'obtenus par l'analyseur de décharge du système 32 Comme exemple de connaissances sémantiques, supposons que si le chiffre de poids fort d'une adresse est 8, il est connu que l'adresse appartient à un certain espace de la mémoire de l'ordinateur Ainsi, si le compteur de programme de la panne actuelle désigne une adresse dont le chiffre de poids fort est 8, alors d'après les connaissances sémantiques, il est connu que la panne s'est produite dans un certain espace de la mémoire virtuelle Certaines des connaissances sémantiques stockées dans la base de données de connaissances sémantiques 18 comprendront la structure en couches du système d'exploitation, l'espace d'adresse virtuelle et les codes d'état associés à chaque erreur. Le processus mentionné ci-dessus décrit la récupération initiale par le récupérateur de cas 14 d'une collection de bibliothèque de cas 12 qui semblent être appropriés à la solution de problème qui a provoqué la panne Cependant, comme cela est décrit en termes généraux auparavant, un second processus, processus de justification, est utilisé dans la présente invention dans le but de "raisonner uniquement les cas qui , sont appropriés de façon justifiée au problème à résoudre. Ce processus comprend l'utilisation d'un modèle approprié issu de la base de données de modèles causals conjointement avec une explication causale -de chacun des cas apprîpriés afin d'expliquer la cause de la panne actuelle (c'està-dire, le nouveau problème) Les cas retrouvés dont l'explication causale peut être utilisée avec succès pour résoudre un problème sont renvoyés à l'utilisateur ou au raisonneur de cas. La base de données de modèles causals 20 contient des modèles de fonctionnement des différentes parties du système d'exploitation Par exemple, en ce qui concerne le programmateur, le dispositif de recherche de personnes, les programmes de gestion de périphériques, etc du système d'exploitation, chacun d'eux a ses propres modèles de fonctionnement qui comprennent les structures de données qui sont accessibles par ces composants du système d'exploitation Ces modèles sont décrits dans divers livres et manuels et sont codés dans la base de données de modèles causals 20. De façon plus générale, un modèle causal peut être considéré comme une représentation d'un comportement et d'une structure de programme de gestion Pour un modèle causal spécifique, les valeurs, qu'un programme de gestion peut produirepeuvent être dérivées en utilisant le modèle causal du programme de gestion et une série d'entrées vers le programme de gestion Dans un système d'exploitation, le modèle causal d'un composant du système d'exploitation comporte les divérs modules qui comprennent le composant, les programmes qui mettent en oeuvre les opérations d'un module particulier, les étapes de fonctionnement que chaque programme effectue, les préconditions et les résultats de chaque étape, ainsi que l'étape suivante qui est impliquée par chaque étape antérieure, et l'étape antérieure qui a causé chaque étape suivante. Comme cela a été mentionné auparavant, un modèle causal peut s'affiner au fur et à mesure que la compréhension d'un expert du fonctionnement du dispositif s'accroit Par exemple, lorsqu'on a un expert du domaine dans la constitution des premiers modèles du programme de gestion de la base de données de modèles causals 20 d'un système d'exploitation, le modèle peut être constitué de quatre étapes prétraitement, traitement, posttraitement et livraison AST Si l'expert du domaine apprend plus tard que l'étape de prétraitement elle-même comporte plusieurs étapes, le modèle initial peut être affiné pour incorporer ces étapes, à condition que l'incorporation donne un modèle cohérent. Un modèle causal a deux types de composants. Les composants actifs mettent en oeuvre la fonction du dispositif qui est en train d'être modélisé et les composants passifs (structures de données) stockent les résultats du traitement qui est effectué par lès composants actifs Dans le domaine des systèmes d'exploitation, les composants actifs sont les morceaux de code qui constituent le système d'exploitation Dans la présente invention, les composants actifs sont représentés par les étapes de modèle causal Les composants passifs des modèles sont représentés par les structures de données du système d'exploitation. Outre les composants actifs et passifs respectivement représentés par les étapes de modèle causal et les structures de données du système d'exploitation, quatre types de relations et deux types de hiérarchies sont définis pour représenter la structure et la fonction du modèle causal Les relations sont "précondition", "sortie", "implication" et "causal", alors que les hiérarchies sont "constitué de" et "partie de" Chacune d'elles sera traitée séparément ci-après et décrite par rapport à l'exemple montré dans la figure 3 du modèle causal d'un programme de gestion de périphériques (Un programme de gestion de périphériques est un programme qui assure une communication entre une machine telle qu'une imprimante lignes et un système d'exploitation) La figure 3 montre un modèle causal avec quatre ô 2655443 étapes de modèle causal étape de prétraitement 41; étape de traitement 42; étape de post-traitement 43; et étape de livraison 45 Chaque étape d'un modèle causal accepte une ou plusieurs entrées et, après les avoir traitées, livre une ou plusieurs sorties Ces entrées sont stockées dans les composants passifs du modèle, qui, dans l'exemple donné, sont les structures de données 38 Sans ses entrées nécessaires, une étape ne peut pas s'exécuter En d'autres termes, les entrées d'une étape de modèle causal en tant que "préconditions" doivent être satisfaites avant que l'étape de modèle causal soit capable de s'exécuter. Une relation de précondition est utilisée afin de connecter un composant actif à un composant passif, c'est-à-dire une partie de code avec une structure de de données Par exemple, une structure de données 38 qui est utilisée pendant le fonctionnement d'un prograimme de gestion de périphériques d'un système d'exploitation est "le progiciel demandeur d'entrée/sortie" (IRP) Dans un modèle à quatre modules de l'exploitation du programme de gestion de périphériques du système d'exploitation, la structure de données 38 par l'IRP est reliée à l'étape de traitement 42 via une relation de précondition 46, * étant donné que l'IRP doit être défini afin que l'étape de traitement s'exécute Un IRP est défini au cours de l'étape de prétraitement 41. La sortie de chaque étape de modèle causal 41,42, 43, 44 est stockée dans un composant passif, l'une des structures de données 38 de cet exemple Une relation "sortie" relie un composant actif (c'est-à- dire, un zrorceau de code) à la structure de données appropriée 38 Par exemple, la définition de la structure de données 38 (à savoir, la spécification de certains de ses champs) est la sortie de l'étape de prétraitement 41 du modèle causal du programme de gestion de périphériques Cela est exprimé par la relation de sortie 48 La sortie d'une étape peut servir d'étape de précondition à une autre étape, par exemple, la structure de données 38 (la sortie de l'étape de prétraitement) servira d'entrée à l'étape de traitement 42. Les troisième et quatrième relations du modèle causal sont les relations "implique" et "causales". Lorsque la précondition d'une étape de modèle causal 41-44 n'a pas été satisfaite, l'étape 41-44 ne peut pas s'exécuter Pour cette raison, l'étape de modèle causal qui peut satisfaire cette précondition doit être trouvée En d'autres termes, l'étape dont la sortie sert d'entrée à l'étape en cours doit être trouvée et exécutée Dans le but d'identifier cette étape de modèle causal, une relation implique doit être définie entre deux étapes de modèle causal, indiquant que l'exécution de la première étape de modèle causal implique que la seconde étape de modèle causal a déjà été exécutée Comme exemple, il existe une relation implique 50 depuis l'étape de traitement 42 jusqu'à l'étape de prétraitement 41 du modèle de programme de gestion des périphériques indiquant que l'exécution de l'étape de traitement 42 implique que l'étape de prétraitement 41 a déjà été exécutée. L'inverse de la relation implique est la relation "causale" C'est une relation qui relie deux étapes du modèle causal Cependant, au lieu de relier une étape à une autre qui doit être exécutée avant la première, la relation implique, la relation causale relie une étape de modèle causal à une autre qui doit être exécutée une fois que la première étape de modèle causal a été exécutée En d'autres termes, la relation causale indique que l'exécution réussie de la première étape entraîne l'exécution de la seconde étape Comme exemple, une relation causale 52 indique que l'exécution réussie de l'étape de prétraitement 41 entraîne l'exécution de l'étape de traitement 42 En définissant ces relations (causale et impliquée) entre deux étapes quelconque, on peut identifier la séquence des étapes de modèle causal qui a besoin d'être exécutée entre deux étapes de modèle causal spécifiées appartenant au modèle causal. Il existe deux hiérarchies différentes dans le modèle causal La hiérarchie "constituée de" concerne les améliorations qui sont associées à un modèle causal d'origine Par exemple, l'étape de prétraitement 41 peut être affinée en quatre sous-étapes 41 a, 41 b, 41 c, 41 d Par exemple, l'étape de prétraitement 41 peut consister en sous-étapes mettre en fonction IPL ( 41 a); déterminer le compte d'octets ( 41 b); attribuer IRP ( 41 c); et incrémenter le compte dlentrée/sortie ( 41 d) Le système 10 de la présente invention, tout en rassemblant davantage d'informations sur ce qui a pu provoquer la panne, utilisera cette hiérarchie dans le but d'avoir accès à un modèle causal plus détaillé que celui spécifié dans l'explication causale du cas retrouvé. La hiérarchie "fait partie de" est le contra-ire de la hiérarchie "constituée de" La hiérarchie "fait partie de" relie un modèle causal inférieur plus détaillé à un modèle causal équivalent, plus abstrait Par exemple, les étapes 41 a-41 d qui sont effectuées pendant l'étape de prétraitement 41 d'une opération du programme de gestion de périphériques peuvent être trop spécifiques pour être utiles à l'explication de la panne Cela peut se produire si un cas explique une panne en termes de modèle causal inférieur qui intègre de nombreuses étapes, mais il n'est pas possible d'obtenir assez d'informations à partir du fichier de décharge d'incident de la panne actuelle pour expliquer la panne actuelle en utilisant le modèle causal inférieur Si cela se produit, alors la relation fait partie est utilisée pour avoir accès au modèle causal de niveau supérieur suivant (plus abstrait) Ce modèle causal de niveau supérieur suivant sera un modèle dans lequel l'opération du programme de gestion de périphériques est considérée comme étant constitué de quatre étapes uniquement ( 41-44), et ce modèle causal supérieur est utilisé conjointement avec S un autre cas retrouvé qui explique une panne en termes de ce modèle causal supérieur dans le but de trouver la cause de ce nouveau problème. Outre le fait de relier les -modèles causals soit à un modèle plus affiné soit à un modèle plus abstrait, les hiérarchies constituées de sont également capables d'être utilisées avec les composants passifs du modèle causal En particulier, la hiérarchie constituée de est utilisée pour relier une structure de données à ses champs individuels ou à des parties plus petites de la structure de données elle-même La hiérarchie fait partie de relie un champ ou une partie d'une structure de données à la structure de données à laquelle elle appartient En établissant ces liaisons, le système 10 peut obtenir certaines relations entre les structures de données Par exemple, si une structure de données désigne un processus nul, alors un composant de cette structure de données désignera également un processus nul Ces relations sont utilisées au cours du processus différé de l'explication causale, décrit plus loin - Comme cela a été mentionné auparavant, les explications causales sont utilisées dans le processus de justification de sorte que seuls les cas appropriés de façon justifiée sont présentés à l'utilisateur du système 10 Une explication causale est une annotation ou un résumé, fait par le technicien ou l'utilisateur qui a introduit un cas dans la bibliothèque de cas 12. Cette annotation est la chaîne causale complète qui explique la cause de la panne décrite dans le cas. Un exemple d'une explication causale est montrée dans la figure 4 Dans cette figure, une explication causale 56 est montrée pour être constituée des étapes de soutien 58,60 Chaque étape de-soutien 58,60 est associée au moins à une contrainte 62,64 et exprime une des deux relations qui appartient à la panne décrite dans le cas, la relation "implique" et la relation "cause" La relation implique 66 est utilisée pour exprimer une contrainte 62 dont la violation a provoqué la panne qui est décrite La relation cause 68, en revanche, exprime la violation de contrainte qui a provoqué la panne. Chaque relation implique 66 a deux contraintes 62,64 associées à elle La relation implique 66 exprime que la première contrainte 62 implique la seconde contrainte 64 Une contrainte comprend: un opérateur, une entité et une valeur L'entité se réfère au -composant passif d'un modèle causal L'opérateur décrit les relations qui existent entre l'entité et la valeur. Par exemple, la contrainte "PCB-NULLH indique que la structure de données PCB désigne un processus nul La relation "PID = 0 implique PCB-NULL" peut par conséquent être interprétée comme suit -le PID étant égal à zéro implique que la PCB désigne un processus nul Par conséquent, en se référant à la figure 4, la première contrainte 62 est PID = 0, qui implique la seconde contrainte 64, PCB-NULL. La relation provoque 68 associe une contrainte 64 à un code d'état 70 qui a été émis par le système d'exploitation lorsque la panne s'est produite Par exemple, la relation "PCB-NULL provoque une violation d'accès" 'peut être interprétée comme suit une violation d'accès est provoquée par le PCB désignant un processus nul Dans la figure 4, la seconde contrainte 64 est PCB-NULL, qui est associée par la relation 1 S provoque 68 au code condition 70, qui dans cet exemple est une violation d'accès. Est associée à chaque contrainte 62,64 l'étape de modèle causal 43 issue du modèle causal particulier qui a été utilisé pour l'explication du cas C'est par l'intermédiaire de cette association que le processus de récupération de cas est capable de vérifier si l'hypothèse qui est proposé par l'explication causale du cas, est valide Le processus le fait en exécutant les tests associés à l'étape de modèle 43 et en vérifiant si une contrainte 62,64 est violée. Comme cela a été décrit auparavant, dans le processus de récupération, un certain nombre de cas auront été initialement récupérés en utilisant les symptômes du nouveau problème A ce stade, la justification a utilisé les cas récupérés initialement dans le but de renvoyer uniquement les cas appropriés de façon justifiée Le processus de justification comprend la correspondance des cas récupérés avec le nouveau problème Cela est fait en interprétant l'explication causale d'un cas récupéré dans le contexte du nouveau problème. L'interprétation de l'explication causale comprend l'exécution du test de l'étape de modèle désignée par chaque étape de soutien 58,60 qui est incluse dans une explication causale -56, et le fait de déterminer si chacune des contraintes 62,64 associées à chaque étape de soutien 58,60 rentre dans le contexte du nouveau problème Afin d'obtenir la nouvelle valeur de l'entité incluse dans chaque contrainte 62,64, le récupérateur de cas 14 exécute le test à l'étape qui est associée à l'étape de soutien Dans l'environnement des systèmes d'exploitation de l'ordinateur, le test est exécuté sur le fichier de décharge d'incident du nouveau problème pour obtenir les données appropriées Dans l'exemple de la figure 4, l'étape de modèle causal associée aux étapes de soutien 58,60, est l'étape de post-traitement 43, si bien que c'est l'étape de modèle causal qui est exécutée. Dans le processus d'exécution de l'étape de modèle causal, le récupérateur de cas 14 peut également devoir exécuter une ou plusieurs étapes du modèle causal, afin de satisfaire les préconditions des étapes de modèle causal prescrites A cette fin, le récupérateur de cas 14 utilise les relations implique et causale qui ont été établies entre les étapes de modèle causal individuelles 41-44. Les explications causales 56 qui sont comprises dans chaque cas jouent le rôle d'annotations de l'explication causale complète de la panne qui est décrite dans le cas auquel elles appartiennent. Cependant, la plupart des experts ne comporteront pas l'explication causale complète dans chaque cas de la bibliothèque de cas 12 Les annotations qu'ils incluent conjointement avec le modèle causal du programme, permettent à un expert de recréer toute la chaîne causale De la même manière, en exécutant les étapes du modèle causal dans le but d'obtenir les préconditions de l'étape spécifiée par une contrainte, le système 10 de la présente invention peut créer la chaîne causale complète dont l'annotation est contenue dans l'explication causale du cas considéré Dans le processus, le système 10 détermine les structures de données ainsi que les valeurs des champs de structures de données particuliers qui n'ont pas été spécifiées dans l'explication causale associée au cas récupéré. En exemple, afin d'obtenir la valeur du PID (le "processus ID"), le système doit avoir l'adresse de début de l'IRP Par conséquent, outre les caractéristiques telles que PID, et PCB, qui ont été mentionnées explicitement dans l'explication causale (en particulier, dans les contraintes associées à chaque étape de soutien), le récupérateur de cas 14 peut utiliser les caractéristiques (structures de données et champs de structures de données) qui sont révélées pendant la retransmission de l'explication causale Ces caractéristiques révélées nouvellement peuvent ensuite être utilisées comme indices afin de sélectionner une sous-série de cas qui est jugée appropriée à la résolution du nouveau problème. Un exemple de sélection d'une sous-série de cas est le suivant: si une des contraintes de l'explication causale d'un cas est PCB-NULL et le processus d'exécution d'étape de modèle révèle que cette contrainte ne tient pas, cela implique que tous les cas qui ont été retrouvés auparavant et qui comportent également cette contrainte peuvent être rejetés En outre, étant donné que la violation de la contrainte mentionnée ci-dessus implique que le HPCB ne désigne pas un processus nul (parce que le HPCB "fait partie" de la PCB) tous les cas retrouvés qui avaient la contrainte PCB-NULL peuvent également être rejetés. Bien que la description précitée d'une application spécifique de l'invention destinée à résoudre les problèmes d'un système d'exploitation d'ordinateur devrait être claire à l'homme de l'art, un autre exemple d'une application du système de récupération de cas de la présente invention va être décrit L'exemple est pris dans le domaine des réparations automobiles. Un mécanicien automobile, utilisant le système de raisonnement à base de cas de la présente invention, utilisera les caractéristiques apparentes afin de retrouver dans la bibliothèque de cas 12 une série de cas qui semblent initialement appropriés au problème de la voiture (le nouveau problème) Dans ce domaine, les caractéristiques apparentes sont les suivantes: marque de la voiture, année du modèle, type du moteur, nombre de kilomètres au compteur et une rapide description du problème. Pour cet exemple, le nouveau problème a les caractéristiques apparentes suivantes NOUVEAU PROBLEME MARQUE: X MODELE: 626 ANNEE DU MODELE 1985 TYPE DU MOTEUR 2,OL, Injection MILES: 40 000 PROBLEME Le moteur ne démarre pas Ce nouveau problème est entré dans le récupérateur de cas 14, qui utilise les caractéristiques apparentes pour retrouver les cas dans la bibliothèque de cas 12 Ces cas sont placés dans la série retrouvée C'est la première partie du processus de récupération des cas appropriés de façon justifiée. s La seconde partie du processus, le processus de justification, doit maintenant être effectuée. Supposons que le récupérateur de cas 14, utilisant' les caractéristiques apparentes signalées du nouveau problème ci-dessus, retrouve initialement trois cas dans la bibliothèque de cas 12 et qu'il met ces cas dans la série retrouvée Supposons que les trois cas de la série retrouvée ont les informations suivantes: CAS 1 MARQUE: X MODELE: 626 ANNEE DU MODELE: 1988 TYPE DU MOTEUR: 2,0 L, Injection MILES: 10 000 PROBLEME: Le moteur ne démarre pas CAUSE: L'injecteur de carburant SOLUTION: était bouché et ne pouvait donc pas introduire le carburant nécessaire à l'allumage du moteur, ce qui ëmpêchait le moteur de démarrer. Nettoyer l'injecteur de carburant. CAS 2 MARQUE: MODELE': ANNEE DU MODELE: TYPE DU MOTEUR: MILES: PROBLEME: CAUSE: SOLUTION: X 2,0 L, aspiration normale 60.000 Le moteur ne démarre pas La pompe à essence de la voiture est défaillante si bien que le moteur ne reçoit pas du tout de carburant, ce qui l'empêche de démarrer. Remplacer la pompe à essence CAS 3 MARQUE: MODELE: ANNEE DU MODELE: TYPE DU MOTEUR: MILES: PROBLEME: CAUSE: X 1,8 L, aspiration normale 20.000 Le moteur ne démarre pas Une fuite existait dans le réservoir d'essence et l'essence tombait sur le sol si bien qu'aucun carburant n'arrivait au moteur par la conduite de carburant et la voiture ne démarrait pas. SOLUTION Réparer la fuite du réservoir à essence. La comparaison des caractéristiques apparentes des cas 1-3 avec -le nouveau problème montre une correspondance de la plupart des caractéristiques apparentes Une des caractéristiques apparentes, le type du moteur, a été ignorée pour les besoins de la récupération initiale de sorte que les types de moteur à aspiration normale, à la fois les 1,8 litre et les 2,0 litres, soient retrouvés pour avoir une série de récupération assez grande. Le récupérateur de cas 14 doit maintenant déterminer lequel ou lesquels des trois cas de la série retrouvée sont appropriés de façon justifiée au nouveau problème Le récupérateur de cas 14 examine le premier cas, le cas 1, qui devient maintenant le cas candidat. L'explication causale du cas candidat est examinée pour déterminer dans quelle mesure l'explication causale correspond à la situation du nouveau problème. La première étape de soutien du cas candidat est invoquée Cela entraîne l'exécution, dans le nouveau problème, du test de l'étape de modèle que l'étape de soutien désigne La contrainte est "injecteur de carburant bouché" L'étape de modèle est que l'injecteur de carburant fournit du carburant pour l'allumage du moteur Cette action provoque l'acquisition de la valeur qui correspond à la relation associée à l'étape de soutien invoquée Dans cet exemple, le test est effectué par le mécanicien Si le cas 1 est le cas candidat, le mécanicien effectuera une vérification pour voir s'il y a de l'essence dans le petit réservoir qui fournit de l'essence à l'injecteur de carburant Cela déterminera si l'injecteur de carburant a un problème Supposons que ce test révèle qu'il y a de l'essence dans le réservoir Le récupérateur de cas 14 apprendra le résultat de ce test par le mécanicien C'est le premier type d'apprentissage, mentionné auparavant, qui est effectué parla présente invention En se référant au modèle de la voiture contenu dans la base de données de modèles causals du composant 20, le récupérateur de cas 14 détermine si ce type de réservoir existe également dans les voitures à moteurs à aspiration normale. En passant à l'étape de soutien suivante ("ne pouvait pas introduire de carburant"), le récupérateur de cas 14 indique au mécanicien de vérifier le conduit qui fournit le carburant du réservoir à l'injecteur de carburant dans une voiture qui présente le nouveau problème Supposons que le conduit n'est pas bouché En conséquence, l'explication causale du cas 1 ne s'appplique pas au nouveau problème En outre, étant donné que le cas 14 a appris qu'il y a de l'essence dans le petit réservoir, donc qu'il y a du carburant dans le moteur et que ce réservoir peut également se trouver dans les moteurs aspiration normale, le récupérateur de cas 14 conclut avec un degré élevé de certitude que l'explication causale du cas 2 ne s'applique pas au nouveau problème C'est pourquoi l'explication causale du cas 2 indique explicitement que la pompe à essence défaillante fait que le moteur ne reçoit pas du tout de carburant C'est l'exemple d'un second cas qui est rejeté et supprimé de la série retrouvée d'après les informations apprises pendant la justification d'un premier cas. Etant donné que les cas 1 et 2 ont été supprimés de la série active, un nouveau cas candidat est examiné Ce sera le cas 3, que le récupérateur de cas 14 essaiera de justifier Le récupérateur de cas 14 invoque l'étape de soutien suivante ("une fuite existait dans le réservoir d'essence") pour laquelle le mécanicien effectue les tests nécessaires afin de déterminer s'il y a une fuite dans le conduit dé carburant de la voiture présentant le nouveau problème. Le mécanicien regarde d'abord la jauge à essence du tableau de bord de la voiture pour déterminer si elle indique que le réservoir est vide Supposons que la jauge indique qu'il reste du carburant dans le réservoir Le mécanicien vérifiera ensuite le conduit de carburant et là, supposons qu'il trouve une fuite. L'explication causale du troisième cas ne s'appliquera pas exactement Cependant, elle peut expliquer partiellement la cause du problème Le récupérateur de cas 14 adapte ensuite les parties de l'explication du cas 3 qui ne correspond pas à la situation du nouveau problème, si bien qu'elle peut expliquer le nouveau problème exactement Le mécanicien remplace le conduit de carburant et résout le nouveau problème. A ce stade, le mécanicien automobile, c'est-à- dire, l'utilisateur, prend une décision de stocker le nouveau problème comme un cas dans la bibliothèque de cas 12 Le nouveau cas sera complet avec une explication causale et une solution Cette addition d'un nouveau cas dans la bibliothèque de cas 12 est le second type d'apprentissage qui est effectué par le système de raisonnement à base de cas. En utilisant l'appareil et le procédé de la présente invention, seuls les cas appropriés de façon justifiée seront renvoyés à l'utilisateur, de sorte que la solution d'un problème peut être rapidement établie. Bien qu'une application spécifique du système de récupération de cas de la présente invention ait été décrite, l'application de ce système à d'autres domaines est envisagée Par exemple, le système peut être utilisé dans la conception de programmes ou dans le dépannage des machines, le dépannage des logiciels, les diagnostics médicaux, l'exploitation, l'étude de procédé, l'analyse de crédit, les investissements bancaires et il ne se limite pas à la réparation des systèmes d'exploitation des ordinateurs. REVENDICATIONS 1 Procédé de réalisation de la récupération de cas dans un système de raisonnement à base de cas ayant une bibliothèque de cas, un récupérateur de cas et un raisonneur de cas, comprenant l'obtention des symptômes d'un problème; la récupération d'une série de cas stockés dans une bibliothèque de cas fondés sur les symptômes dudit problème, chacun desdits cas comportant des symptômes, une explication causale et une solution; la détermination pour chaque cas dans ladite série de cas si ce cas est approprié de façon justifiée audit problème fondé sur l'explication causale du cas; le renvoi à un utilisateur dudit système de raisonnement à base de cas, des cas qui ont été déterminés comme étant appropriés de façon justifiée audit problème. 2 Procédé selon la revendication 1, comprenant en outre le fait d'apprendre si d'autres cas dans ladite série de cas sont appropriés de façon justifiée audit problème fondé sur les informations obtenues au cours de ladite étape de détermination, et l'acceptation d'autres cas appris comme étant appropriés de façon justifiée et le rejet d'autres cas appris comme étant non appropriés de façon justifiée sans faire correspondre explicitement leurs explications causales audit problème. 3 Procédé selon la revendication 2, comprenant en outre le stockage des symptômes dudit problème, une explication causale et une solution audit problème dans ladite bibliothèque de cas une fois que ledit problème est résolu. 4 Procédé selon la revendication 3, dans lequel ladite étape de détermination comprend la tentative d'essayer de faire correspondre une explication causale d'un cas retrouvé audit problème. Procédé selon la revendication 4, dans lequel l'étape de tentative de faire correspondre une explication-causale comprend le fait de se reporter à un modèle causal sur lequel l'explication causale est fondée. 6 Disposition visant à apporter des solutions à un problème d'un système d'exploitation informatique d'un ordinateur, comprenant: un analyseur de décharge de système conçu pour être relié à un ordinateur, ledit analyseur de décharge de système obtenant des informations issues d'un ordinateur concernant une panne de système d'exploitation un système de raisonnement à base de cas relié à l'analyseur de décharge de système, ledit système de raisonnement à base de cas comprenant une bibliothèque de cas et un ré&upérateur de cas relié à la bibliothèque de cas, récupérateur de cas qui utilise les informations obtenues par l'analyseur de décharge de système pour récupérer les cas appropriés de façon justifiée, lesdits cas appropriés de façon justifiée contenant les solutions à un problème du système d'exploitation informatique. 7 Disposition selon la revendication 6, dans laquelle le système de raisonnement à base de cas comprend en outre une base de données de connaissances sémantiques reliée au récupérateur de cas, une base de données de modèles causals de composants reliée au récupérateur de cas, et un raisonneur de cas relié au récupérateur de cas.