FR 2653245 A1 19910419 FR 8913450 A 19891013 La présente invention a pour objet un procédé de test du fonctionnement d'un système informatique. Elle trouve notamment son application dans le domaine médical pour le test des processeurs d'images. Elle peut néanmoins trouver son application dans d'autres systèmes informatiques. Elle est plus particulièrement intéressante lorsque l'architecture du matériel mis en oeuvre est importante. On connaît dans le domaine médical les processeurs d'images. Les processeurs d'images sont chargés d'éditer des images que l'on visualise ultérieurement sur un moniteur de télévision. Les images â représenter sont les images des structures internes du corps humain, étudiées selon des protocoles d'investigation de type tomodensitométrîque, RMN, scintigraphique, ou ultrasonore. Dans ces protocoles d'investigation on acquiert une connaissance en volume du corps humain étudié.Ceci signifie qu'après un calcul de reconstruction, on dispose, dans la mémoire du système informatique, d'un volume numérique dont les éléments de volume, les voxels, représentent par leur adresse (leur place dans la mémoire) des éléments de volume du corps humain, et qui sont chargés d'une information représentative du phénomène physique étudié (tomodensitométrie, RMN, scintigraphie, ultrasons). Lorsqu'on veut visualiser une partie du corps, on peut choisir de visualiser des coupes. Dans ce cas, on accède directement à des pages de la mémoire, et ces pages sont transférées à une mémoire d'images elle-même lue par le système de lecture du moniteur. Une page mémoire est un ensemble de cellules mémoires qui ont en commun des mêmes valeurs d'un ou de plusieurs moments d'adresse. Par contre, lorsqu'on désire visualiser des organes comme si les tissus alentour avaient été disséqués, en particulier en induisant des effets supplémentaires de perspective, le problème de la représentation est bien plus compliqué. On connaît des méthodes de visualisation, par exemple de type Octree ou de type lancer de rayon, qui permettent ainsi d'avoir accès à des vues des organes examinées, et non pas à des coupes de ces organes. La complexité de ces opérations de visualisation est encore augmentée par le fait qu'on cherche à représenter des images mobiles : on cherche à faire "tourner" les organes en face du praticien qui regarde 11 écran de télévision. Ces traitements impliquent alors des calculs très importants. En effet, chaque élément d'image, pixel, des images visualisées doit être calculé en luminosité, en oItbrage, en chrominance en fonction de l'investigation du volume numérique, et tout cela, à un rythme de 25 images par seconde. On comprend alors que les processeurs d'image sont des outils informatiques très compliqués dans leur conception. On peut ainsi admettre, pour simplifier, qu'un processeur d'images comporte couramment une carte éléctronique unité centrale dite CPU, une carte électronique d'interface disque dur dite SCSI, une carte d'acquisition dite ACQ, une ou deux cartes électroniques visualisation dites GEL (pour le gel de l'image), une ou deux cartes électroniques de mémoire dites IMPAS, à accès séquentiel, et enfin, une carte électronique de traitement dite TRAIT. Si on veut faire un test du fonctionnement du système entier, la complexité de l'interaction de ces cartes, et des liaisons qui interviennent entre elles, conduisent normalement à un logiciel de test inextricable. En effet, on aboutit normalement à une gestion arborescente de menus de tests qui interfèrent entre eux de manière incohérente. Le diagnostic, c'est-à-dire la localisation d'un élément en panne, est alors imprécis et peut conduire à des erreurs qui nuisent à la réalisation et à la maintenance du système. En effet, les tests normalement concevables s'apparentent aux utilisations du système informatique, du processeur d'images. Dans une approche alors fonctionnelle, on utilise des tests qui ne permettent pas de diagnostiquer avec précision et méthode quelle carte électronique ou quel circuit intégré est défectueux dans une carte électronique. Par exemple, une fonction dite zoom pourra utiliser dans un processeur d'images, à la fois : la mémoire d'images, un générateur d'adresse, les bus séquentiels et une mémoire de sortie (qui est la mémoire d'images lue par le moniteur de visualisation). Une autre fonction pourra utiliser certaines de ces cartes et d'autres cartes.Le résultat de tests pratiqués sur ces deux fonctions mène à une indétermination du diagnostic. Dans l'invention, pour remédier à ces inconvénients, on a abandonné l'approche fonctionnelle et on a procédé à un découpage du système informatique, du processeur d'images, en des objets testables indépendamment les uns des autres. Ces objets sont appelés ressources électroniques. Un diagnostic précis est ainsi devenu possible Cependant, les problèmes d'incohérence se sont maintenus tant qu'on n'avait pas procédé avec méthode. Pour éviter de telles incohérences, on a alors dressé la matrice de transfert régissant la correspondance entre des instructions de test et les ressources électroniques que ces instructions de test impliquent. On s'est rendu compte alors qu'il fallait que la matrice de test soit de type triangulaire, pour d'une part, conduire à la cohérence, et d'autre part, permettre une exécution la plus rapide possible des tests. En effet, lorsqu'une panne a été détectée, et quand on est arrivé à déterminer la carte électronique qui était impliquée, on effectue la réparation. Il est rare cependant que le résultat de la réparation conduise directement à un bon fonctionnement de l'ensemble. En effet, on a en général au moment de cette réparation, remplacé un composant par un autre, sa fonctionnalité eu égard à un besoin peut avoir été restaurée mais peut nécessiter, pour d'autres fonctionnalités, des réglages supplémentaires Autrement dit, après avoir fait la réparation, on est amené à retester la carte électronique réparée. Il faut alors relancer le programme de tests, là encore d'une manière cohérente, en effectuant par ailleurs le moins d'opérations de tests possible pour ne pas perdre de temps.On peut admettre en pratique que l'opération de tests est ainsi lancée une vingtaine de fois au moment de l'intervention sur une carte électronique. Aussi, même si les tests en eux-mêmes peuvent être de durée courte, le fait de les réitérer très souvent peut conduire à une grande perte de temps d'attente de l'opérateur chargé de la réparation. Le procédé de tests de l'invention permet de remédier à cet inconvénient. Dans ces conditions, l'invention a pour objet un procédé de test du fonctionnement d'un système informatique , -ce procédé comportant l'exécution d'instructions de test, -chaque instruction de test mettant en oeuvre des ressources électroniques particulières du système, -ce procédé étant destiné à détecter, par le résultat de l'exécution des instructions, celles des ressources de ce système qui seraient déficientes, -les instructions de test étant exécutées les unes après les autres dans un certain ordre jusqu'à ce qu'on trouve, si c'est le cas, celle de ces ressources qui serait déficiente, caractérisé en ce qu'il comporte les phases suivantes:: -on dresse la matrice de transfert régissant la correspondance entre les instructions de test et les ressources que ces instructions de test impliquent, -cette matrice de transfert étant une matrice dont les termes sont situés à des intersections de colonnes relatives aux instructions et de lignes relatives aux ressources, -cette matrice, de type binaire, comportant pour des termes , correspondant à l'intersection d'une ressource donnée et-d'une instruction donnée de test, une réponse oui quand cette ressource donnée est effectivement exploitée par cette instruction de test donnée, et une réponse non dans les autres cas, -on organise cette matrice de telle façon qu'elle se présente sous une forme triangulaire, et on en déduit des rangs croissants des ressources et des instructions de test, l'instruction de rang le moins élevé étant celle qui met en oeuvre le moins grand nombre de ressources, -une des ressources parmi celles appartenant à ce moins grand nombre étant dite la ressource de rang le moins élevé, -on détermine l'ordre d'exécution des instructions de test en choisissant d'exécuter d'abord l'instruction de test de rang le moins élevé, suivi par l'exécution des instructions de rangs immédiatement supérieurs et ainsi de suite jusqu'à ce qu'on trouve une ressource déficiente, si c'est le cas. L'invention sera mieux comprise à la lecture de la description qui suit et à l'examen des figures qui l'accompagnent. Celles-ci ne sont données qu'à titre indicatif et nullement limitatif de l'invention. Les figures montrent - Figure 1 : la représentation schématique d'une matrice de tests d'un processeur d'images organisé conformément à l'invention - Figure 2 : la représentation schématique d'une matrice de tests des sous-ressources d'une ressource. La figure 1 montre une matrice de transfert M régissant la correspondance entre des instructions de test : TEST CPU, TEST CONIO, TEST ACQ, TEST IMPAS, TEST GEL, TEST TRAIT, et des ressources que ces instructions de test impliquent au moment du test : CPU, CONIO, ACQ, IMPAS, GEL et TRAIT. Ces tests et ces ressources sont relatifs à un processeur d'image mais on comprend qu'ils pourraient concerner n'importe quel système informatique. Les termes de la matrice sont situés aux intersections de colonnes relatives aux instructions et de lignes relatives aux ressources. Cette matrice est de type binaire, elle comporte pour ses termes une réponse oui, ou "0" quand une ressource donnée est effectivement exploitée par une instruction de test donnée, et une réponse non, représentée par des blancs, dans un autre cas.Au début de l'élaboration de la matrice de transfert, celle-ci ne se présente pas sous une allure triangulaire. En effet, on imagine les tests et on regarde les ressources qu'ils impliquent. On écrit alors la matrice de la manière naturelle : en décrivant les tests les uns après les autres. Ensuite on réarrange la matrice en déplaçant les unes par rapport aux autres les instructions de test, et également les unes par rapport aux autres les ressources électroniques impliquées. On la réarrange pour qu'elle soit triangulaire. Au besoin on supprime ou on ajoute des tests dans ce but. On remarque que la matrice présentée sur la figure 1 n'est pas triangulaire, puisque le test CPU met aussi en oeuvre la ressource CONIO située dans la partie inférieure gauche de la matrice. Pour l'instant, on va ignorer cette situation et on va considérer que la forme triangulaire a été obtenue. Elle permet de déduire des rangs croissants des ressources et surtout des rangs croissants des instructions de test. Ainsi l'instruction de test CPU recevra un rang 1, l'instruction de test CONIO, un rang 2, etc... l'instruction de test TRAIT recevra un rang 6. De même, les ressources reçoivent également un rang : la ressource CPU reçoit le rang 1, etc... la ressource TRAIT reçoit le rang 6. On donne le rang le moins élevé à l'instruction qui met en oeuvre le moins grand nombre de ressources. Ce serait le cas de l'instruction TEST CPU si la ressource CONIO était absente de son action. Un système de ressources est testable si les tests dont il est muni ne conduisent à aucune indétermination. Autrement dit il faut que, si un test quelconque est mauvais, on arrive par le jeu des autres tests à une conclusion unique. On va montrer que pour que ce système soit testable, il faut et il suffit que la matrice M soit triangulaire. On va ainsi démontrer que si la matrice n'est pas triangulaire, le système n'est pas testable et que par contre, si elle l'est, le système est testable. On va effectuer cette démonstration pour un nombre de ressources n quelconque. Prenons d'abord le cas de n = 2. Il concerne par exemple les ressources CPU et les ressources CONIO. La matrice élémentaire concernant les deux tests TEST CPU et TEST CONIO et ces deux ressources n'est pas triangulaire : elle est carrée. Il est évident que si les résultats des deux tests, TEST CPU et TEST CONIO signalent une anomalie, on est incapable de savoir quelle est la ressource CPU ou CONIO qui est impliquée. Il en est de même si un seul de ces deux tests signale une anomalie. En conséquence, cette matrice non triangulaire conduit à une indétermination. Par contre, en supposant que le test TEST CPU n'utilise pas la ressource CONIO, on voit qu'en lançant successivement les opérations TEST CPU et TEST CONIO, on peut savoir quelle est la ressource qui est impliquée au premier chef. En effet, si TEST CPU signale une anomalie, la ressource CPU est impliquée dans le défaut. Par contre, si le test TEST CPU ne signale rien et si le TEST CONIO signale une anomalie, la ressource CONIO, dans ce cas, est impliquée. On peut généraliser en passant à chacun des tests qui suivent le test TEST CONIO, c'est-à-dire par exemple, le test TEST ACQ, le test TEST IMPAS, le test TEST GEL et le test TEST TRAIT. On remarque par exemple que si, par hypothèse supplémentaire, le test TEST CONIO utilisait en partie la ressource ACQ, le résultat du test TEST ACQ et du test TEST CONIO conduiraient à une indétermination en ce qui concerne la ressource qui serait défectueuse. A l'opposé, dans la situation où la matrice est triangulaire (comme sur la figure 1), on ne lance un test, par exemple le test TEST ACQ, que si on a pu vérifier que pour tous les tests précédents , on avait obtenu des réponses ne signalant aucun défaut. En conséquence, le nouveau test qui met en oeuvre une nouvelle ressource désigne, s'il signale une anomalie, un défaut dans cette nouvelle ressource.Le caractère triangulaire de la matrice M est donc primordial. On voit donc que le caractère triangulaire de la matrice est le moyen qui permet de déduire l'organisation des tests les uns par rapport aux autres, compte tenu des ressources que ces tests impliquent. La construction de la matrice nous a montré dans l'exemple étudié qu'il y a une indétermination en ce qui concerne la ressource CPU et la ressource CONIO. Il peut ne pas être possible, pour diverses raisons, de séparer des objets testables d'une manière indépendante les uns des autres. Dans ce cas, on les regroupe en une ressource commune, par exemple CPU-CONIO, que l'on teste en exécutant un test unique : ici les tests TEST CPU et TEST CONIO ensemble. Ceci revient à trigonaliser la matrice M. Une fois que l'on a réussi à déterminer quelle était la carte électronique, correspondant à une ressource, qui était impliquée par un défaut, on peut chercher dans cette carte, de la même manière, quelles sont les sous-ressources qui sont défectueuses. Par exemple, sur la figure 2, on a représenté la carte GEL par une matrice M' qui implique 12 ressources que l'on teste par 12 tests T1 à T12. Cette carte comporte essentiellement ici des mémoires, telles que les ressources LUT, CARACTERE, MASQUE, BUFFER M. La mémoire CARACTERE sert à afficher des caractères sur l'écran. La mémoire BUFFER M est la mémoire gel d'image elle-même. Le basculement est un circuit qui permet de passer de l'option acquisition à l'option visualisation. Autrement dit, la carte GEL est en relation avec le traitement pour être chargée de l'image à représenter, puis est en relation avec le moniteur de visualisation pour que celui-ci puisse y prélever les informations d'images à montrer. Des bus d'adresses et de données permettent d'organiser la lecture et l'écriture des cellules mémoires de la carte GEL. Des sous-ressources particulières, le bus ACQ-GEL et le bus IMPAS-GEL, désignent des sous-ressources permettant à la carte d'échanger des informations avec les ressources ACQ d'une part ou IMPAS d'autre part. On a représenté par en-dessous de la matrice M' de transfert régissant la correspondance entre les instructions T1 à T12 et les 12 ressources de la carte GEL, les interactions nécessaires des opérations de test avec ces autres ressources du système informatique. En effet, pour tester le bus ACQ-GEL, il est tout à fait nécessaire d'utiliser également la ressource ACQ. Bien que par un précédent test on ait pu obtenir la conviction que la ressource ACQ était en bon état, il importe cependant de signaler que cette ressource interfère dans le test. La matrice M' est triangulaire et par conséquent l'exécution successive des tests T1 à T12 renseigne sur la sous-ressource de la carte GEL qui est en mauvais état. Les réitérations de détection de panne sont, par exemple, nécessaires lorsqu'après avoir changé le bus de données N à cause d'un signal de panne délivré par le test T 8, on est ultérieurement également obligé d'intervenir sur le BUFFER N à cause d'un signal délivré par le test 10. Ares être intervenu sur le BUFFER N, il importe de recommencer les tests T1 à T12 pour savoir si à nouveau, par exemple, le bus de données N n'est pas déréglé, compte tenu des changements intervenus sur le BUFFER N. Dans ces conditions, la procédure de test, après intervention sur une ressource donnée, par exemple BUFFER N, comportera l'exécution du test qui avait permis de déterminer que cette ressource, où cette sous-ressource était impliquée. Ici par exemple, après être intervenu sur le BUFFER N, on relance l'opération test 10. Si le test 10 signale une panne, on réintervient sur la ressource BUFFER N. Par contre, si le test 10 ne signale pas de panne, on remarque que le test 10 met en oeuvre les ressources BUS DE DONNEES N, BUS D'ADRESSE N et BUFFER N.Par conséquent, on lance la séquence des tests à partir du test, ici il s'agit du test T8, qui est l'instruction de test d'un rang le moins élevé possible parmi celles des instructions de test de rang inférieur (au test T10) qui mettent en oeuvre au moins une des ressources impliquées dans l'exécution de cette instruction de test particulière (l'instruction de test T10). Si le test T8 ne signale aucune erreur, on effectue à la suite le test Tg, Tlo, et on termine par les tests T11 et T12 qui n'avaient jusqu'à présent jamais été testés, compte tenu de la découverte de la panne sur le BUFFER N.Lorsque tout semble en ordre et qu'on a définitivement le sentiment qu'on a trouvé la panne et qu'on y a remédié, on relance un test général : le test général lance pour chaque ressource, dans l'ordre indiqué, les tests de toutes les sous-ressources et une fois que ces tests des sous-ressources se sont avérés positifs, on teste l'ensemble des ressources conformément à la matrice M. Le caractère diagonal de la matrice donne comme caractéristique aux instructions de tests que ces instructions de tests sont indépendantes, au sens des espaces vectoriels, des instructions de tests de rang inférieures à elles. Par exemple, l'instruction de test T6 qui met en oeuvre, seul, le BUFFER M est indépendante des autres instructions de test puisque ces autres instructions de test sont incapables d'intervenir sur le BUFFER M. En ayant ainsi des instructions de test indépendantes, on obtient une base d'instructions de test qui est, au sens des espaces vectoriels, minimale. Ceci est la preuve qu'en agissant ainsi le nombre des instructions de test est donc réduit au minimum : les tests sont donc exécutés plus rapidement que dans n'importe quelle autre solution où les tests n'auraient pas été indépendants et où il y aurait eu en définitive redondance. En ce qui concerne les ressources qui ont dû être combinées, par exemple les ressources CPU et CONIO de la matrice M vue précédemment, il convient de les tester l'une et l'autre en fonction de leurs sous-ressources a chacune. Cependant, un des effets de l'invention est de conduire les concepteurs de matériel à une indépendance des fonctions qu'ils réalisent, de manière à ce que ces situations se présentent le moins souvent possible. En appliquant la méthode ainsi inventée, on a par exemple été amené à modifier des rebouclages de bus, à choisir d'autres chemins pour véhiculer les informations, parce que ces autres chemins, tout en étant équivalents à ceux initialement retenus, présentaient l'avantage que les ressources étaient indépendantes les unes des autres la réparation, et aussi la mise au point des matériels en sont facilitées. Une autre conséquence de l'utilisation de la méthode est l'élaboration relativement aisée d'un système expert. En effet, tel qu'on vient de le voir, la méthode de test désigne d'une manière très rapide non seulement les tests qu'il faut faire les uns à la suite des autres, mais, en cas d'apparition d'un signal de défaut, quelle est la ressource qui est impliquée dans le défaut. En conséquence, dans un exemple, on a réalisé une organisation hiérarchique comprenant des tests généraux, comme ceux indiqués dans la matrice M ayant pour corrolaire l'exécution de tests de type M', comme ceux représentés sur la figure 2. Un système de déclenchement automatique des tests permet facilement de dégager l'information "BUFFER N - carte GEL" sans intervention d'un quelconque opérateur qualifié. La conception elle-même de ce système expert est très simple, il suffit de lui faire afficher le nom de la dernière ressource et de la dernière sous-ressource testée au moment de l'apparition du défaut dans la séquence des tests. En pratique, on a mis en oeuvre dans ce système expert, 500 règles manipulant 100 tests et 100 ressources et aboutissant à un diagnostic satisfaisant pour la production et la maintenance. REVENDICATIONS 1- Procédé de test du fonctionnement d'un système informatique -ce procédé comportant l'exécution d'instructions de test, -chaque instruction de test mettant en oeuvre des ressources électroniques particulières du système, -ce procédé étant destiné à détecter, par le résultat de l'exécution des instructions, celles des ressources de ce système qui seraient déficientes, -les instructions de test étant exécutées les unes après les autres dans un certain ordre jusqu'à ce qu'on trouve, si c'est le cas, celle de ces ressources qui serait déficiente, caractérisé en ce qu'il comporte les phases suivantes:: -on dresse la matrice de transfert régissant la correspondance entre les instructions de test et les ressources que ces instructions de test impliquent, -cette matrice de transfert étant une matrice dont les termes sont situés à des intersections de colonnes relatives aux instructions et de lignes relatives aux ressources, -cette matrice, de type binaire, comportant pour des termes correspondant à l'intersection d'une ressource donnée et d'une instruction donnée de test une réponse oui quand cette ressource donnée est effectivement exploitée par cette instruction de test donnée, et une reponse non dans les autres cas, -on organise cette matrice de telle façon qu'elle se présente sous une forme triangulaire, et on en déduit des rangs croissants des ressources et des instructions de test, l'instruction de rang le moins élevé étant celle qui met en oeuvre le moins grand nombre de ressources, -une des ressources parmi celles appartenant à ce moins grand nombre étant dite la ressource de rang le moins élevé, -on détermine l'ordre d'exécution des instructions de test en choisissant d'exécuter d'abord l'instruction de test de rang le moins élevé, suivi par l'exécution des instructions de rangs immédiatement supérieurs et ainsi de suite jusqu'à ce qu'on trouve une ressource déficiente, si c'est le cas. 2- Procédé selon la revendication 1, caractérisé en ce, pour vérifier le bon fonctionnement d'une ressource particulière, -on exécute une instruction de test particulière, d'un rang le moins élevé possible, mettant en oeuvre cette ressource particulière, et, en cas d'echec du test, -on recherche les instructions de rang inférieur au rang de cette instruction de test particulière et qui mettent en oeuvre au moins une des ressources mise en oeuvre par cette instruction de test particulière, -on exécute l'instruction de test d'un rang le moins élevé possible parmi celles de ces instructions de test de rang inférieur qui mettent en oeuvre au moins une des resources impliquées dans l'exécution de cette instruction de test particulière, et, en cas de succès de ce test, -on exécute en suivant les instructions de test de rangs supérieurs jusqu'à trouver la première instruction de test qui n'est pas exécutée avec succès, -et on en déduit la ressource dont l'état est déficient. 3- Procédé selon la revendication 1 ou la revendication 2, caractérisé en ce que -chaque instruction de test donnée est indépendante des instructions de test de rang supérieur ou inférieur à celui de cette instruction de test donnée 4- Procédé selon l'une quelconque des revendications 1 à 3, caractérisé en ce que -chaque ressource est décomposée en sous ressources, -le test des sous ressources est entrepris en provoquant l'exécution d'instructions de test élémentairesr -et en ce que ces instructions de test élémentaires sont également organisées de telle façon que leur matrice de transfert soit triangulaire 5- Procédé selon l'une quelconque des revendications 1 à 4, caractérisé en ce que -les instructions de test sont organisées en menus hiérarchisés à plusieurs niveaux (M, M') intervenant pour tester différents niveaux correspondant des fonctions électroniques mises en oeuvre par les ressources ou les sous ressources, -les instructions d'un niveau du menu étant exécutées dans l'ordre croissant des rangs de ces instructions dans ce niveau du menu, -les instructions des différents niveaux du menu étant exécutées en remontant la hiérarchie.