Brevet FR3003663A1 — publié le 20140926

Procédé de détermination automatique de causes de dysfonctionnement d'un système composé d'une pluralité de composants matériels ou logiciels La présente invention concerne un procédé de détermination automatique de causes de dysfonctionnement d'un système composé d'une pluralité de composants matériels ou logiciels et un dispositif associé. L'invention se situe dans le domaine de l'analyse des dysfonctionnements des systèmes comportant plusieurs composants logiciels ou matériels, ou combinant composants logiciels et matériels, qui interagissent. Diverses applications utilisent des composants matériels et logiciels interconnectés, répartis sur plusieurs sous-systèmes, et éventuellement embarqués. Par exemple, dans le domaine des appareils médicaux, des systèmes de traitement sont composés d'appareils interconnectés, par exemple les pacemakers ou les perfuseurs connectés à des systèmes de surveillance. Dans le domaine du transport, de nombreux systèmes de contrôle et de surveillance mettent en oeuvre des composants interconnectés, comme par exemple les régulateurs de vitesse. Dans de tels systèmes complexes, il est important, en cas de dysfonctionnement du système, d'identifier automatiquement la cause du dysfonctionnement, c'est-à-dire le ou les composants du système responsables du dysfonctionnement, afin de prendre des mesures adéquates, par exemple pour rétablir la sécurité d'utilisation du système, pour identifier les composants à rappeler en usine ou pour déterminer les responsabilités des parties impliquées. En effet, dans certains systèmes comme les systèmes médicaux ou de contrôle et de surveillance de véhicule, un dysfonctionnement peut avoir de graves conséquences et il est utile d'en déterminer la cause automatiquement. Dans les systèmes distribués et complexes, comprenant plusieurs composants matériels et logiciels, il arrive fréquemment, en cas de dysfonctionnement du système, de constater le dysfonctionnement de plusieurs composants. Dans ce cas, la détermination du ou des composants qui sont effectivement la cause du dysfonctionnement est d'autant plus difficile. Le problème de la détermination de la cause d'un dysfonctionnement dans un système informatique a notamment été abordé pour des systèmes transformationnels. La demande de brevet W003/023615 décrit une méthode de détermination de source d'erreur dans l'entrée d'un programme informatique. Cette méthode s'applique en partant de l'entrée et du programme informatique qui doit être disponible, en exécutant le programme avec des variantes de l'entrée. Dans un cas plus général dans lequel les composants du système ne sont décrits que par leurs entrées/sorties, la méthode décrite dans W003/023615 ne permet pas de déterminer les sources des dysfonctionnements. D'autres méthodes de détermination de sources de dysfonctionnement basées sur une analyse de la causalité ont été proposées. De telles méthodes sont basées sur un modèle qui représente explicitement la causalité entre les événements d'un système. Ce modèle doit être connu ou construit à partir d'un échantillon de séquences d'exécution enregistrées ou traces d'exécution. Dans ce dernier cas, la fiabilité du modèle dépend de la taille de l'échantillon. Les méthodes connues qui utilisent cette approche nécessitent en général un nombre important de telles séquences d'exécution. Afin de remédier aux inconvénients des méthodes existantes, l'invention propose, selon un premier aspect, un procédé de détermination automatique de causes de dysfonctionnement d'un système composé d'une pluralité de composants matériels ou logiciels, chaque composant ayant une spécification de bon fonctionnement associée, le procédé comportant, pour chaque composant, la mémorisation d'une séquence d'événements observés, les événements observés étant relatifs au comportement dudit composant pendant une phase de fonctionnement du système. Le procédé est mis en oeuvre par un processeur ou un circuit programmable et comporte les étapes de : -détermination d'un ensemble d'événements, dit événements racine, chaque événement racine étant associé à un composant, chaque événement racine étant non conforme à la spécification de bon fonctionnement du composant associé, -pour au moins un événement racine traité parmi les événements racine déterminés, détermination d'un sous-ensemble de dépendance, comportant des événements temporellement dépendants dudit au moins un événement racine traité parmi l'ensemble des séquences d'événements observés, ledit sous-ensemble de dépendance comportant au moins une sous-séquence de dysfonctionnement de séquences d'événements mémorisées, - utilisation dudit sous-ensemble de dépendance pour déterminer si au moins une partie des événements de ladite au moins une sous-séquence de dysfonctionnement est une cause nécessaire et/ou suffisante dudit dysfonctionnement du système. Avantageusement, le procédé de l'invention permet de déterminer un ou plusieurs composants ayant causé un dysfonctionnement du système dans un système de composants pour lesquels une spécification de bon fonctionnement est connue, en fonction des séquences d'événements d'une phase de fonctionnement, donc pour une seule ou un petit nombre d'exécutions. De plus, le procédé de l'invention s'applique pour des systèmes à composants distribués, les séquences d'événements associées aux composants pouvant être mémorisées indépendamment. Enfin, la mise en oeuvre de sous-ensembles de dépendance permet d'améliorer la précision de la détermination de causes de dysfonctionnement. Le procédé selon l'invention peut présenter une ou plusieurs des caractéristiques ci-dessous : -l'utilisation du sous-ensemble de dépendance comporte les étapes de : -substitution d'au moins une partie des événements dudit sous-ensemble de dépendance par des événements hypothétiques conformes à la spécification de bon fonctionnement des composants associés, et vérification de la présence dudit dysfonctionnement, - en cas de vérification négative, détermination de ladite partie des événements substitués comme cause nécessaire dudit dysfonctionnement du système ; -le procédé comporte en outre les étapes de : - détermination d'un ensemble de dépendance complémentaire, comportant des événements temporellement dépendants des événements racine autres que le au moins un événement racine traité, -substitution d'au moins une partie des événements dudit sous-ensemble de dépendance complémentaire par des événements hypothétiques conformes à la spécification de bon fonctionnement des composants associés, et vérification de la présence dudit dysfonctionnement, -en cas de vérification positive, détermination de ladite au moins une sous-séquence de dysfonctionnement comme cause suffisante dudit dysfonctionnement du système ; - une dite sous-séquence de dysfonctionnement est constituée des événements de la séquence d'événements correspondante à partir d'un premier événement de ladite séquence d'événements correspondante déterminé comme temporellement dépendant d'au moins un événement racine de dysfonctionnement et la partie des événements comporte au moins une desdites sous-séquences ; - ladite partie des événements comporte l'ensemble desdites sous-séquences ; - le procédé comporte une étape de représentation de ladite phase de fonctionnement du système par un graphe d'exécution comportant une pluralité de noeuds connectés par des transitions, chaque noeud correspondant à un état du système, et chaque transition correspondant à un événement observé, ledit graphe étant obtenu à partir de l'ensemble des séquences d'événements observées, ledit graphe d'exécution représentant toutes les compositions possibles à partir des séquences d'événements observées entre un état initial et au moins un état final du système ; - le procédé est mis en oeuvre après une phase de fonctionnement du système ; - le procédé est mis en oeuvre pendant une phase de fonctionnement du système ; - lesdites séquences d'événements observés pour chaque composant sont extraites d'une séquence d'événements unique produite pendant la phase de fonctionnement du système ; - lesdits composants communiquent entre eux par l'intermédiaire d'un protocole de communication prédéterminé ; - lesdits composants communiquent entre eux par envoi de messages ; - lesdits composants communiquent entre eux par variables partagées. Le procédé selon l'invention s'applique notamment lorsque la pluralité de composants du système comporte des composants matériels et des composants logiciels. Selon un deuxième aspect, l'invention concerne un dispositif de détermination automatique de causes de dysfonctionnement d'un système composé d'une pluralité de composants matériels ou logiciels, chaque composant ayant une spécification de bon fonctionnement associée, comportant des moyens de mémorisation d'une séquence d'événements observés pour chaque composant, les événements observés étant relatifs au comportement dudit composant pendant une phase de fonctionnement du système, le dispositif comportant un processeur ou un circuit programmable apte à mettre en oeuvre des modules de : -détermination d'un ensemble d'événements, dit événements racine, chaque événement racine étant associé à un composant, chaque événement racine étant non conforme à la spécification de bon fonctionnement du composant associé, -pour au moins un événement racine traité parmi les événements racine déterminés, détermination d'un sous-ensemble de dépendance, comportant des événements temporellement dépendants dudit au moins un événement racine traité parmi l'ensemble des séquences d'événements observés, ledit sous-ensemble de dépendance comportant au moins une sous-séquence de dysfonctionnement de séquences d'événements mémorisées, - utilisation dudit sous-ensemble de dépendance pour déterminer si au moins une partie des événements de ladite au moins une sous-séquence de dysfonctionnement est une cause nécessaire et/ou suffisante dudit dysfonctionnement du système. Le dispositif selon l'invention a des avantages analogues aux avantages du procédé de détermination automatique de causes de dysfonctionnement d'un système rappelés ci-dessus. Le dispositif de détermination automatique de causes de dysfonctionnement d'un système comporte des moyens de mise en oeuvre de l'ensemble des caractéristiques du procédé de détermination automatique de causes de dysfonctionnement d'un système rappelées brièvement ci-dessus. Selon un troisième aspect, l'invention concerne un programme d'ordinateur de détermination automatique de causes de dysfonctionnement d'un système composé d'une pluralité de composants matériels ou logiciels, comportant des instructions pour mettre en oeuvre les étapes d'un procédé de détermination automatique de causes de dysfonctionnement d'un système tel que brièvement décrit ci-dessus lors de l'exécution du programme par un processeur d'un dispositif programmable. D'autres caractéristiques et avantages de l'invention ressortiront de la description qui en est donnée ci-dessous, à titre indicatif et nullement limitatif, en référence aux figures annexées, parmi lesquelles : -la figure 1 est un exemple de système mettant en oeuvre l'invention ; -la figure 2 est un organigramme d'un procédé de détermination de causes de dysfonctionnement selon un mode de réalisation de l'invention ; -la figure 3 illustre schématiquement un ensemble de séquences d'événements associées aux composants dans un scénario application de l'invention ; - la figure 4 illustre schématiquement un graphe d'exécution relatif à l'exemple de la figure 3 ; -les figures 5, 6 et 7 illustrent schématiquement deux cônes d'influence et leurs substitutions relatifs à l'exemple de la figure 3. L'invention sera décrite ci-après pour un système distribué, dont les composants sont des unités de calcul, comportant des moyens de communication selon un protocole de télécommunications prédéfini. Il est entendu que l'invention ne se limite pas à cet exemple d'application, et peut s'appliquer à tout type de système à base de composants aptes à communiquer entre eux selon un modèle de communication donné. L'invention trouve des applications notamment dans les systèmes d'appareils médicaux intégrant des composants logiciels, dans les systèmes embarqués dans des véhicules ou des trains, dans l'aéronautique et l'aérospatiale, dans les centrales électriques, dans les réseaux de distribution d'énergie et dans les services web. L'invention peut être appliquée pendant ou après l'exécution d'un système. Elle peut aussi être appliquée au moment de la validation d'un système ; dans ce cas elle permet d'identifier les composants qui ont causé les dysfonctionnements observés lors de tests. Dans une application particulière, l'invention peut être appliquée en cours d'exécution d'un système lorsqu'un dysfonctionnement est observé, permettant ainsi une identification du ou des composants ayant causé le dysfonctionnement. La figure 1 illustre un système 1 mettant en oeuvre l'invention, comportant un système de communication 2 à trois composants 4, 6, 8, qui sont aptes à communiquer entre eux par des messages de communication, représentés par des flèches sur la figure. Le nombre de composants est limité à trois dans la figure 1 pour faciliter l'explication, mais en pratique, le procédé supporte un nombre quelconque de composants. De plus, bien que les composants 4, 6 et 8 illustrés à la figure 1 soient tous connectés les uns aux autres par des connexions émission/réception, une telle architecture n'est pas nécessaire, les composants pouvant être seulement partiellement connectés entre eux. Pour chacun des composants, une séquence d'événements est mémorisée dans un journal d'exécution stocké dans un fichier respectif 10, 12, 14. Dans l'exemple de la figure 1, chaque composant a un journal d'exécution associé, mémorisé séparément. En variante, un seul journal d'exécution est mémorisé pour l'ensemble ou un sous-ensemble des composants du système 2. Les événements mémorisés dans les journaux d'exécution portent par exemple sur les communications, c'est-à-dire les messages envoyés et reçus, sur des appels de fonctions, sur l'écriture et la lecture de variables partagées, et/ou sur un résumé de pas de calcul internes comme par exemple les fonctions exécutées avec les valeurs des paramètres et les valeurs de retour. Les journaux d'exécution mémorisés, comportant les séquences d'événements observés pour chaque composant, sont ensuite utilisés dans un dispositif 16 de détermination automatique de causes de dysfonctionnement. Le dispositif 16 met en oeuvre un procédé de détermination de causalité selon l'invention, et indique en sortie 18 un ou plusieurs composants défaillants parmi tous les composants du système. Le dispositif 16 est un dispositif programmable et comporte notamment un processeur ou un circuit programmable apte à mettre en oeuvre des modules de détermination automatique de causes de dysfonctionnement du système analysé. La figure 2 illustre un mode de réalisation d'un procédé de détermination de causes de dysfonctionnement d'un système selon l'invention, dans le cas où un dysfonctionnement est observé, en cours d'exécution du système ou après exécution du système. Le procédé est mis en oeuvre par un dispositif programmable tel un ordinateur, comportant notamment un circuit programmable ou un processeur apte à exécuter des instructions de programme de commande lorsque le dispositif est mis sous tension et des moyens de stockage d'informations, aptes à stocker des instructions de code exécutable permettant la mise en oeuvre de programmes aptes à mettre en oeuvre le procédé selon l'invention. Pour un système S comportant une pluralité de composants d'indices i, i E {1,...,n}, dans une étape préliminaire 20 de caractérisation du système, des spécifications du système sont obtenues. En effet, le procédé de détermination de causes de dysfonctionnement selon l'invention repose sur une formalisation mathématique, permettant ainsi une application à tout type de système à composants matériels ou logiciels. Le comportement d'un tel système et de ses composants peut être représenté de manière générale par un système de transitions étiquetées (labeled transition system, LTS). Un LTS consiste en un ensemble d'états Q, un alphabet d'événements E, un ensemble de transitions entre états et un ou plusieurs états initiaux. Chaque état du LTS est représentatif d'un état d'un ou plusieurs composants du système, avant ou après un événement mémorisé dans un journal d'exécution. Pour un système S comportant une pluralité de composants, la spécification de fonctionnement correct de chaque composant i est représentée par un LTS Si dont l'alphabet d'événements est E,. Le système S est représenté par l'ensemble des spécifications Si des composants, un alphabet E dont les éléments sont des sous ensembles d'événements des composants qui peuvent se produire simultanément (se synchroniser), et une relation de causalité immédiate p entre événements des composants telle que (el, e2) est dans p si e2 dépend directement de el (si el déclenche e2 ou transmet de l'information reçue par e2). Soit P une propriété de fonctionnement correct de S dont la violation constitue un dysfonctionnement. Afin de faciliter l'explication, considérons l'exemple du système de communication 2 de la figure 1, qui est un système à trois composants : le composant 4 est le composant d'indice 1, le composant 6 est le composant d'indice 2 et le composant 8 est le composant d'indice 3. Chaque composant a un alphabet d'événements E, associé et une spécification Si associée. Une spécification Si associée à un composant définit les séquences autorisées d'événements appartenant à E,. Ainsi, un composant, indexé i, a une signature associée CF(E,,, Si). Par exemple, dans un scénario d'application, le composant 4 est un client d'une base de données, le composant 6 un serveur apte à servir des données de la base de données et le composant 8 un système de mise en forme des données. Dans cet exemple, le composant 4 a un alphabet d'événements associé E ={ a, m!, ml où a est un événement interne qui est dans cet exemple l'omission d'authentification de l'utilisateur, m! est l'envoi d'une requête m portant sur des données à accès restreint et m"! est l'envoi d'une authentification m" de l'utilisateur qui requiert des données de la base de données. La spécification S1 est donnée par la séquence de deux transitions étiquetées par les événements m"! ; Le composant 6 a un alphabet d'événements associé E,2={m?,m1,x,m"?} où m? représente la réception de m et x un événement interne qui constitue un dysfonctionnement du système. Le composant 6 est donc apte à recevoir des requêtes m portant sur des données à accès restreint et des authentifications m", à envoyer des requêtes m' de transfert pour la mise en forme des données. La spécification S2 accepte les séquences d'événements m"? ; m? ; mi et m? ; ; x : l'omission de l'authentification est détectée a posteriori et produit l'événement x. Le composant 8, ayant un alphabet d'événements associé E,3={b, m'?}, est apte à recevoir les requêtes m' de mise en forme. L'événement b est un événement interne, qui est par exemple l'indisponibilité temporaire du logiciel de mise en forme. La spécification S3 accepte simplement un nombre quelconque d'événements m'?. La relation de causalité immédiate entre événements est définie par les paires d'émission/réception de messages m, m' et m" :p = {(m! , m?) , (ni! , m' ?) ,(m" ! , m" ?)} . En d'autres termes, un composant du système ne peut influencer un autre composant que par envoi d'un message reçu par ce dernier. De retour à la figure 2, des journaux d'exécution pour l'ensemble des composants sont obtenus dans une étape d'obtention de journaux d'exécution 22, les journaux d'exécution étant notés logi...logn. Selon un mode de réalisation, les journaux d'exécution log, sont mémorisés au fil d'une exécution du système et sont lus dans une mémoire du dispositif programmable mettant en oeuvre l'invention. Selon une variante, les journaux d'exécution log, sont utilisés en cours d'exécution du système. Lorsque l'analyse de causalité est effectuée en cours d'exécution, les séquences d'événements qui se sont produits jusqu'au moment de l'analyse sont utilisées. Dans ce mode de réalisation, des journaux d'exécution séparés sont obtenus pour chacun des composants. Selon une variante possible, les séquences d'événements d'exécution sont enregistrées dans un même fichier pour tous les composants ou pour des groupes de composants. Dans ce cas, l'étape 22 comprend l'extraction des journaux d'exécution log, par composant à partir d'un ou plusieurs tels fichiers enregistrant des séquences d'événements pour plusieurs composants. Dans chaque journal d'exécution, chaque événement a un indice d'événement associé. Le procédé de l'invention est utilisé lorsqu'une exécution du système est incorrecte, donc un dysfonctionnement, qui est une non-conformité au niveau des propriétés globales du système P, se produit. Dans un scénario de dysfonctionnement d'un exemple de système tel que décrit ci-dessus, les journaux d'exécution schématiquement représentés en figure 3 sont observés. Le journal d'exécution du composant 4 est noté log1, le journal d'exécution du composant 6 est noté loge et le journal d'exécution du composant 8 est noté log3. Chaque journal d'exécution comporte une séquence d'événements, ordonnée temporellement, pour un composant donné, ce qui est représenté par des flèches en trait plein sur la figure 3, et il est possible d'associer un indice d'événement à chaque événement selon sa position dans le journal d'exécution. Ainsi, dans le journal log1, on associe l'indice d'événement 1 à l'événement a et l'indice d'événement 2 à l'événement m!, dans le journal loge on associe l'indice d'événement 1 à l'événement m?, l'indice d'événement 2 à l'événement mi et l'indice d'événement 3 à l'événement x, et dans le journal log3, on associe l'indice d'événement 1 à l'événement b et l'indice d'événement 2 à l'événement m'?. De plus, les liens temporels de causalité entre événements sont représentés par des flèches en trait pointillé sur la figure. Typiquement, dans l'exemple de scénario, l'envoi d'une requête de demande de données m a lieu avant la réception d'un tel message par le serveur de données, et de même pour l'envoi et la réception des requêtes de mise en forme de données. Cependant, le procédé selon l'invention n'exige pas un ordonnancement temporel complet des séquences d'événements. Ainsi, par exemple, l'ordre temporel des événements a et b n'est pas connu. L'exemple de la figure 3 montre un dysfonctionnement du système. En effet, la présence de l'événement a n'est pas conforme à la spécification S1, la présence de b n'est pas conforme à la spécification S3. La présence de x témoigne d'un comportement incorrect du système dans son ensemble, car les données à accès restreint ont été fournies sans authentification préalable. La présence de x constitue un dysfonctionnement du système. On note log=(logi,..., loge) l'ensemble des journaux d'exécution obtenus pour un système à n composants à l'étape 22. Un graphe d'exécution GE(log) est ensuite construit lors d'une étape de construction de graphe d'exécution 24. Un graphe d'exécution est un LTS qui représente toutes les exécutions possibles du système qui donnent lieu aux journaux d'exécution observés, permettant d'aboutir à un état final cohérent avec les observations partant d'un état initial, dans lequel les noeuds représentent des états et les transitions des événements observés. Notons qu'on peut associer à chaque état du graphe d'exécution un ensemble d'indices d'événements, chaque indice d'événement étant représentatif d'une position atteinte dans la séquence d'événements associés à un composant, donc dans l'exécution d'un composant. La figure 4 illustre le graphe d'exécution GE(log) obtenu à partir de log,, loge, et log3 de la figure 3. Ce graphe d'exécution GE(log) comporte quatorze états notés q0 à q13, q0 étant l'état initial et q13 étant l'état final. Comme expliqué ci-dessus, ce graphe prend en considération toutes les séquences possibles des événements observés aboutissant à un état final de dysfonctionnement. Ainsi, le graphe GE(log) représente le fait que l'événement b peut se produire avant a (état q6), après a, après l'envoi de m, après réception de m, après envoi de m'ou après émission de x. Le graphe GE(log) est généré automatiquement à partir de l'ensemble des journaux d'événements observés. Pour ce faire, d'abord chaque journal d'événements est représenté par un LTS. Ainsi, log, = a,,, a,,2, ; a,,k est représenté par le LTS L, avec l'alphabet E,,, l'ensemble d'états Ob -1 = {q;,0, -11,05 - 011 0,15 - - -Iq;,k} et l'ensemble de transitions (q,,,_,, q,,,) pour j=1,...,k. GE(log) est le produit synchronisé des LTS sous l'alphabet E. En d'autres mots, c'est le LTS avec l'alphabet E, l'ensemble d'états Q1 x x Qn , et l'ensemble de transitions ((q1, q2, a, (q1', q2', q,-,')) telles que a est un événement dans E et pour chaque composant i=1,...,n, (q,, a,, q,') est une transition de L, et a contient a,, ou il n'y a aucun événement de E, dans l'événement a et q,'=q,. Un ou plusieurs composants peuvent être considérés pour l'analyse de la causalité et donc pour la détermination du composant ou du sous-ensemble de composants responsables du dysfonctionnement. Suite à la construction d'un graphe d'exécution, à l'étape 26 sont déterminés des dysfonctionnements racine RF des divers composants à partir des événements observés non-conformes aux spécifications des composants. Pour cela, des événements dits événements racine de dysfonctionnement sont déterminés, qui sont des événements non-conformes à la spécification correspondante d'un composant. Dans le graphe d'exécution GE(log), les états pour lesquels un dysfonctionnement d'un composant d'indice i vient d'arriver sont identifiés. Les dysfonctionnements racine correspondants sont définis sous forme d'un tuple (q,i) où q est un état du graphe d'exécution et i un indice de composant. Pour un sous-ensemble de composants indexés par I, RF(log, I) est l'ensemble des dysfonctionnements racine (q, i) tels que i est un élément de I. Par exemple, dans le graphe de la figure 4, les dysfonctionnements racine sont : RF(log, {1})={(q1,1),(q7,1)} pour le premier composant, et RF(log, {3}) = {(q6,3), (q7, 3), (q8, 3), (q9, 3), (q10, 3), ( q11, 3)} pour le troisième composant. L'analyse de causalité est ensuite effectuée pour un sous-ensemble de composants I de l'ensemble des composants, ce sous-ensemble pouvant être réduit à un seul composant, défini à l'étape 28. Pour le sous-ensemble I du ou des composants sélectionné(s), l'ensemble de dysfonctionnements racine RF(log, I) est considéré. A l'étape 30 de détermination d'un sous-ensemble de dépendance, un sous- ensemble de dépendance D(log, I) est défini pour l'ensemble I, les dysfonctionnements racine RF(log, I) et pour l'ensemble log de séquences d'événements observées. Le sous-ensemble de dépendance comporte des événements de tous les journaux d'événements observés qui sont temporellement dépendants d'un événement racine de dysfonctionnement considéré pour un des composants du sous-ensemble I. Selon un mode de réalisation, le sous-ensemble de dépendance comprend l'ensemble des événements des séquences mémorisées qui peuvent avoir été impactés par les dysfonctionnements racine de composants du sous-ensemble I sauf les événements relatifs à un composant ne faisant pas partie du sous-ensemble d'analyse, et suivant un événement non-conforme à la spécification ou dysfonctionnement de ce composant. On note I* le sous-ensemble de composants du système qui ne font pas partie du sous-ensemble traité I, appelé sous-ensemble complémentaire, ayant un sous-ensemble de dépendance associé, dit sous-ensemble de dépendance complémentaire, noté D(log, I*). Dans le mode de réalisation préféré, l'ensemble de dépendance est calculé sous forme d'un cône d'influence C(log, I) qui est défini à partir d'un ensemble de séquences d'observations log et pour un sous-ensemble de composants I. Dans ce mode de réalisation, le cône d'influence C(log, I) est défini par un ensemble de n indices c,, n étant le nombre de composants du système, chaque indice c, étant l'indice dans le journal d'événements log, du composant i à partir duquel les événements du journal log, font partie du cône d'influence. Par définition, si un indice c, est supérieur à l'indice maximal d'événement observé dans un journal d'exécution log], aucun événement du journal d'événements log, ne fait partie du cône d'influence C(log, I). Le cône d'influence est calculé à partir du graphe d'exécution GE(log), par le calcul d'une fonction booléenne g qui définit pour chaque état q du graphe d'exécution et pour chaque composant i du système si le composant i dans l'état q appartient ou non au cône d'influence C(log, I). Si c'est le cas, g,(q)=T, sinon g,(q)=F. On note : g :Q Les valeurs respectives g,(q) pour tous les états q du graphe d'exécution GE(log) sont, dans un mode de réalisation, calculées de manière récursive, selon un parcours du graphe d'exécution déterminé par les dépendances entre états. Selon un mode de réalisation, les valeurs des fonctions g,(q) pour tous les états q du graphe d'exécution sont initialisées à F. Lors d'une première étape, pour chaque état q correspondant à un dysfonctionnement racine du composant d'indice i, où i E I ,la fonction g, correspondante est mise à vrai : g i(q) =T si (q , e RF (I) Ensuite, les opérations suivantes sont répétées : (1) La mise à vrai de la fonction g, pour le composant i est propagée à tous les états q' qui sont atteignables d'un état q dans le graphe d'exécution pour lequel g,(q)=T. (2) Une propagation entre composants est mise en oeuvre, la propagation s'effectuant selon la relation de dépendance causale immédiate p entre événements dans le système. Plus précisément, g,(qk)=T si les conditions suivantes sont satisfaites : - (A) il existe une séquence d'événements cei....ak, donc un chemin correspondant dans le graphe d'exécution passant par des états 011 -105-1011 15 - - - I qk, et -(B) il existe un état ql parmi les états traversés sur ce chemin pour lequel la fonction g,(q1)=T pour un composant j, et -(C) il existe un tuple (a,b) dans p tel que les événements a et b appartiennent aux composants j et i respectivement et se produisent sur le chemin entre ql et qk tels que a précède b ou a et b se produisent simultanément, et -(D) l'état qk est atteint de manière conforme à la spécification Si du composant i. En effet, selon un mode de réalisation il est considéré que si, pour un composant i, un état q est atteint après un dysfonctionnement interne au composant, c'est-à-dire un événement non-conforme à la spécification Si de ce composant i, la dépendance causale immédiate par rapport à un autre composant j ne doit pas être propagée à l'état q pour le composant j. En d'autres termes, un dysfonctionnement antérieur d'un composant est considéré comme ayant une influence plus importante sur le comportement ultérieur du composant qu'un dysfonctionnement externe à ce composant. Selon un autre mode de réalisation, le cône est calculé sans tenir compte des dysfonctionnements antérieurs, ou en en tenant compte seulement pour un sous- ensemble de composants. Les étapes (1) et (2) sont répétées jusqu'à la convergence des fonctions g,. Finalement, tous les états q du graphe d'exécution ont un ensemble de valeurs {gl(q), ...,g,(q)} associé, chaque valeur g,(q) ayant une valeur parmi un ensemble à deux éléments, notés {T,F}. A partir de ces ensembles de valeurs, on calcule, pour chaque composant i de l'ensemble des composants du système un indice c, égal au nombre minimal d'événements de c, à partir de l'état initial du graphe d'exécution qc, jusqu'au premier état q tel que g,(q)=T. S'il n'existe pas d'état pour lequel g,(q)=T, alors ci = 1ogi +1 (la longueur de log, +1). Le cône d'influence C(log, I) est alors représenté par le tuple (cl, ..., cn). Nous appelons, pour chaque composant, la séquence des c,-1 premiers événements le préfixe de son journal d'exécution log,. Nous appelons, pour chaque composant dans l'ensemble I, la séquence d'événements qui commence à son dysfonctionnement racine (s'il en existe un) le suffixe erroné du journal d'exécution log,. Un suffixe erroné du journal d'exécution d'un composant est, en d'autres termes, une sous-séquence d'événements, dite sous-séquence de dysfonctionnement associée à ce composant. La sous-séquence de dysfonctionnement pour un composant est donc la partie de la séquence d'événements correspondant à ce composant, qui peut être la séquence d'événements en entier ou un ensemble vide, à partir du premier événement de cette séquence d'événements inclus dans l'ensemble de dépendance. La figure 5 illustre schématiquement, pour l'exemple de scénario traité, par des traits pointillés, le cône d'influence calculé à partir des dysfonctionnements racine du composant d'indice 1, noté C(log, {1}) dans la figure 5 et le cône d'influence calculé pour les composants d'indices 2 et 3, qui est complémentaire par rapport au cône d'influence calculé pour le composant d'indice 1, noté C(log, {2,3}) dans la figure. Le cône d'influence C(log, {1}) est défini par l'ensemble d'indices d'événements dans les séquences d'événements respectives log1, loge, log3 par : C(log, {1})=(1,1,3). Le cône d'influence C(log, {1}) comprend la totalité de la séquence d'événements du journal d'événements log1, ce qui est indiqué par l'indice d'événement 1, qui est le premier indice dans cette séquence d'événements, la totalité de la séquence d'événements du journal d'événements loge, et aucun événement du journal d'événements log3, ce qui est indiqué par l'indice d'événement 3 qui dépasse la longueur de la séquence d'événements de log3. Les divers cônes d'influence ou ensembles de dépendance calculés permettent une analyse plus précise et plus fine de la causalité, permettant d'éviter des décisions erronées, appelés faux-positifs, comme explicité en détail ci-après. Le procédé met en oeuvre la détermination de causalité nécessaire et/ou suffisante de dysfonctionnement relative au sous-ensemble I de composants et aux événements racine RF(log,l) considérés. Ainsi, dans le mode de réalisation préféré, le sous-ensemble de dépendance déterminé à l'étape 30 est le cône d'influence C(log, I) tel que défini ci-dessus. L'étape 30 est suivie d'une étape 32 de substitution d'événements dans le sous-ensemble de dépendance D(log, I). Plus précisément, les événements de l'ensemble de dépendance sont supprimés et remplacés par des séquences d'événements hypothétiques acceptables selon les spécifications des composants, dans toutes les parties de journaux d'exécution comprises dans l'ensemble de dépendance. Ainsi, comme illustré à la figure 6 pour l'exemple détaillé, l'événement a relatif au premier composant est remplacé par l'événement conforme à la spécification envoi de m" (m"!), et la réception correspondante d'un événement m" (m"?) par le deuxième composant est également introduite. Les journaux d'exécution comportant des séquences d'événements observés log, comportant des événements faisant partie de l'ensemble de dépendance D(log, I) sont remplacés par des journaux d'exécution log', dans lesquels les séquences d'événements sont remplacés par des séquences d'événements conformes aux spécifications des composants. Avantageusement, cela permet de vérifier une hypothèse de causalité qui est : « quel serait le comportement lors de l'exécution du système sans l'occurrence des suffixes erronés du sous-ensemble de composant défini par I ?». Grâce à l'utilisation des dépendances, un ensemble d'exécution hypothétique cohérent est obtenu. A l'étape suivante de décision 34 il est déterminé si le dysfonctionnement se produit encore dans le graphe d'exécution construit à partir des journaux d'exécution obtenus après la substitution dans le sous-ensemble de dépendance D(log, I). Dans l'exemple traité, comme illustré à la figure 6, lorsque les journaux d'exécution log, et log2 du cône d'influence C(log, {1}) sont remplacés par log', et log'2, l'événement x de dysfonctionnement global du système ne se produit plus. Si le dysfonctionnement ne se produit plus, il est conclu à l'étape 38 que le ou les suffixes erronés du sous-ensemble de composants I sont nécessaires pour que le dysfonctionnement observé du système se présente. Ainsi, les non-conformités des composants du sous-ensemble I sont des causes nécessaires au dysfonctionnement observé, lorsque les autres composants fonctionnent de la manière observée. Selon une variante, il est conclu que les suffixes erronés du sous-ensemble de composants I sont une cause nécessaire pour le dysfonctionnement observé si après substitution le dysfonctionnement ne se produit plus dans les exécutions où au moins les préfixes sont observés. Dans l'exemple traité, le dysfonctionnement x ne se produisant plus, il peut être conclu à la nécessité de l'événement non-conforme a pour l'observation du dysfonctionnement x. Ensuite la causalité suffisante du ou des événements racine du sous-ensemble de composants I est examinée. Le sous-ensemble de dépendance complémentaire pour le sous-ensemble de composants I*, noté D(log, I*), est déterminé à l'étape 36 de détermination d'un sous- ensemble de dépendance complémentaire. La détermination du sous-ensemble de dépendance complémentaire est analogue à celle du cône de dépendance décrite ci-dessus. Dans le mode de réalisation préféré, le sous-ensemble de dépendance complémentaire est le cône d'influence calculé à partir des dysfonctionnements racine des composants appartenant à I*. A l'étape 38 de substitution d'événements dans le sous-ensemble de dépendance complémentaire D(log, I*), ce sont les événements du sous-ensemble de dépendance complémentaire D(log, I*) qui sont supprimés et remplacés par des séquences d'événements hypothétiques conformes à la spécification des composants du sous-ensemble complémentaire I*. La substitution est effectuée de manière analogue et ce sont des événements dans l'ensemble de dépendance D(log, I*) du sous-ensemble de composants I* qui sont remplacés par des séquences d'événements conformes, et les autres parties des journaux d'exécution sont laissées inchangées. Pour l'exemple traité, le journal d'exécution log3 est remplacé par un journal log'3 qui comporte uniquement l'événement de réception du message m', noté m'?. Comme illustré à la figure 7, le dysfonctionnement x du système se produit malgré ce remplacement. L'étape suivante de décision 40 détermine si le ou les suffixes erronés du sous- ensemble de composants I sont suffisants pour le dysfonctionnement observé du système. A l'étape 40 il est d'abord vérifié si le dysfonctionnement d'exécution se produit encore après la substitution effectuée dans le sous-ensemble de dépendance complémentaire. Si la vérification est positive, donc si le dysfonctionnement se produit encore, alors il est décidé que les suffixes erronés du sous-ensemble de composants I sont des causes suffisantes pour le dysfonctionnement observé du système. En effet, il est constaté que si les composants du sous-ensemble complémentaire ont un fonctionnement conforme à la spécification, le dysfonctionnement du système se produit néanmoins. Selon une variante, il est conclu que les suffixes erronés du sous-ensemble de composants I sont une cause suffisante pour le dysfonctionnement observé si après substitution le dysfonctionnement se produit toujours dans les exécutions où au moins les préfixes sont observés. Dans le cas de l'exemple traité, le dysfonctionnement x se produisant même après remplacement de log3 par log'3, il peut être conclu que le dysfonctionnement a du premier composant est suffisant pour observer le dysfonctionnement x du système. Cela signifie que le dysfonctionnement b du troisième composant n'est pas une cause du dysfonctionnement x du système. Ainsi, le procédé de l'invention permet de vérifier si un événement non-conforme d'un composant est une cause nécessaire et/ou suffisante pour qu'un dysfonctionnement global du système se produise. Il est à noter que les étapes 30, 32, 34 et 36, 38, 40 peuvent être effectuées dans un ordre différent, ou simultanément. En effet, il est envisageable d'analyser la causalité suffisante avant la causalité nécessaire, ou d'analyser la causalité nécessaire et la causalité suffisante en parallèle. Selon une variante, seulement la détermination de causalité nécessaire ou seulement la détermination de causalité suffisante sont mises en oeuvre. Il est à noter qu'avec un système classique différent de l'invention qui remplace uniquement les événements non-conformes à l'intérieur d'un journal d'exécution d'un composant donné sans prise en compte des dépendances, l'analyse peut donner lieu à de faux positifs. Ainsi, dans le cas de l'exemple traité, si seul l'événement a est remplacé dans le journal d'exécution log, par un événement d'envoi d'un message m" (m"!) sans étendre la substitution au journal du composant 2, l'erreur x persiste à se produire. Il en est de même lorsque le journal l'exécution log3 est remplacé par log'3. Sans la prise en compte des dépendances telle que proposée par l'invention, les événements racine a et b seraient jugés comme causes du dysfonctionnement x à parts égales, ce qui est manifestement incorrect dans l'exemple traité. Il est à noter que l'invention a été décrite dans sa généralité mais illustrée par un exemple simple, afin d'en faciliter la compréhension. L'invention s'applique néanmoins à des systèmes complexes à composants multiples, et permet de déterminer automatiquement et systématiquement des causes de dysfonctionnement nécessaires et/ou suffisantes dans ces systèmes complexes. Le procédé décrit ci-dessus en référence à la figure 2 a été décrit pour l'analyse d'un sous-ensemble des composants défini par des indices I. De manière générale, le procédé est utilisable dans une recherche systématique de causalité, dans laquelle tous les événements ou séquences d'événements susceptibles d'être causes d'un dysfonctionnement parmi les événements observés sont analysés. Dans cette utilisation, le procédé décrit est mis en oeuvre pour chaque sous- ensemble I considéré comme susceptible d'être cause nécessaire et/ou suffisante de dysfonctionnement, et permet de déterminer notamment le sous-ensemble de composants dont le comportement observé est une cause nécessaire et suffisante pour le dysfonctionnement observé.15 REVENDICATIONS1.- Procédé de détermination automatique de causes de dysfonctionnement d'un système composé d'une pluralité de composants matériels ou logiciels, chaque composant ayant une spécification de bon fonctionnement associée, le procédé comportant, pour chaque composant, la mémorisation d'une séquence d'événements observés, les événements observés étant relatifs au comportement dudit composant pendant une phase de fonctionnement du système, le procédé étant mis en oeuvre par un processeur ou un circuit programmable et caractérisé en ce qu'il comporte les étapes de : -détermination (26) d'un ensemble d'événements, dit événements racine, chaque événement racine étant associé à un composant, chaque événement racine étant non conforme à la spécification de bon fonctionnement du composant associé, -pour au moins un événement racine traité parmi les événements racine déterminés, détermination (30, 36) d'un sous-ensemble de dépendance, comportant des événements temporellement dépendants dudit au moins un événement racine traité parmi l'ensemble des séquences d'événements observés, ledit sous-ensemble de dépendance comportant au moins une sous-séquence de dysfonctionnement de séquences d'événements mémorisées, - utilisation (32, 34, 38, 40) dudit sous-ensemble de dépendance pour déterminer si au moins une partie des événements de ladite au moins une sous-séquence de dysfonctionnement est une cause nécessaire et/ou suffisante dudit dysfonctionnement du système. 2.- Procédé selon la revendication 1, caractérisé en ce que l'utilisation du sous- ensemble de dépendance comporte les étapes de : -substitution (32) d'au moins une partie des événements dudit sous-ensemble de dépendance par des événements hypothétiques conformes à la spécification de bon fonctionnement des composants associés, et vérification de la présence dudit dysfonctionnement, - en cas de vérification négative, détermination (34) de ladite partie des événements substitués comme cause nécessaire dudit dysfonctionnement du système. 3.- Procédé selon l'une quelconque des revendications 1 ou 2, caractérisé en ce qu'il comporte en outre les étapes de :- détermination (36) d'un ensemble de dépendance complémentaire, comportant des événements temporellement dépendants des événements racine autres que le au moins un événement racine traité, -substitution (38) d'au moins une partie des événements dudit sous-ensemble de dépendance complémentaire par des événements hypothétiques conformes à la spécification de bon fonctionnement des composants associés, et vérification de la présence dudit dysfonctionnement, -en cas de vérification positive, détermination (40) de ladite au moins une sous-séquence de dysfonctionnement comme cause suffisante dudit dysfonctionnement du système. 4.- Procédé selon l'une quelconque des revendications 1 à 3, caractérisé en ce qu'une dite sous-séquence de dysfonctionnement est constituée des événements de la séquence d'événements correspondante à partir d'un premier événement de ladite séquence d'événements correspondante déterminé comme temporellement dépendant d'au moins un événement racine de dysfonctionnement et en ce que ladite partie des événements comporte au moins une desdites sous-séquences. 5.- Procédé selon la revendication 4, caractérisé en ce que ladite partie des événements comporte l'ensemble desdites sous-séquences. 6.- Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il comporte une étape de représentation (24) de ladite phase de fonctionnement du système par un graphe d'exécution comportant une pluralité de noeuds connectés par des transitions, chaque noeud correspondant à un état du système, et chaque transition correspondant à un événement observé, ledit graphe étant obtenu à partir de l'ensemble des séquences d'événements observées, ledit graphe d'exécution représentant toutes les compositions possibles à partir des séquences d'événements observées entre un état initial et au moins un état final du système. 7.- Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il est mis en oeuvre après une phase de fonctionnement du système. 8.- Procédé selon l'une quelconque des revendications 1 à 6, caractérisé en ce qu'il est mis en oeuvre pendant une phase de fonctionnement du système. 9.- Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que lesdites séquences d'événements observés pour chaque composant sont extraites d'une séquence d'événements unique produite pendant la phase de fonctionnement du système. 10.- Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que lesdits composants communiquent entre eux par l'intermédiaire d'un protocole de communication prédéterminé. 11.- Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que lesdits composants communiquent entre eux par envoi de messages. 12.- Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que lesdits composants communiquent entre eux par variables partagées. 13.- Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que ladite pluralité de composants comporte des composants matériels et des composants logiciels. 14.- Dispositif de détermination automatique de causes de dysfonctionnement d'un système composé d'une pluralité de composants (4,6,8) matériels ou logiciels, chaque composant ayant une spécification de bon fonctionnement associée, comportant des moyens de mémorisation (10, 12, 14) d'une séquence d'événements observés pour chaque composant, les événements observés étant relatifs au comportement dudit composant pendant une phase de fonctionnement du système, le dispositif comportant un processeur ou un circuit programmable apte à mettre en oeuvre des modules de : -détermination d'un ensemble d'événements, dit événements racine, chaque événement racine étant associé à un composant, chaque événement racine étant non conforme à la spécification de bon fonctionnement du composant associé, -pour au moins un événement racine traité parmi les événements racine déterminés, détermination d'un sous-ensemble de dépendance, comportant des événements temporellement dépendants dudit au moins un événement racine traité parmi l'ensemble des séquences d'événements observés, ledit sous-ensemble de dépendance comportant au moins une sous-séquence de dysfonctionnement de séquences d'événements mémorisées,- utilisation dudit sous-ensemble de dépendance pour déterminer si au moins une partie des événements de ladite au moins une sous-séquence de dysfonctionnement est une cause nécessaire et/ou suffisante dudit dysfonctionnement du système. 15.- Programme d'ordinateur de détermination automatique de causes de dysfonctionnement d'un système composé d'une pluralité de composants matériels ou logiciels comportant des instructions pour mettre en oeuvre les étapes d'un procédé de détermination automatique de causes de dysfonctionnement d'un système selon l'une des revendications 1 à 13 lors de l'exécution du programme par un processeur d'un dispositif programmable.