FR3024567A1 - Procede de determination automatique de causes de dysfonctionnement d'un systeme compose d'une pluralite de composants materiels ou logiciels - Google Patents

Procede de determination automatique de causes de dysfonctionnement d'un systeme compose d'une pluralite de composants materiels ou logiciels Download PDF

Info

Publication number
FR3024567A1
FR3024567A1 FR1457464A FR1457464A FR3024567A1 FR 3024567 A1 FR3024567 A1 FR 3024567A1 FR 1457464 A FR1457464 A FR 1457464A FR 1457464 A FR1457464 A FR 1457464A FR 3024567 A1 FR3024567 A1 FR 3024567A1
Authority
FR
France
Prior art keywords
components
subset
model
component
execution
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
FR1457464A
Other languages
English (en)
Other versions
FR3024567B1 (fr
Inventor
Gregor Gossler
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Institut National de Recherche en Informatique et en Automatique INRIA
Original Assignee
Institut National de Recherche en Informatique et en Automatique INRIA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Institut National de Recherche en Informatique et en Automatique INRIA filed Critical Institut National de Recherche en Informatique et en Automatique INRIA
Priority to FR1457464A priority Critical patent/FR3024567B1/fr
Priority to EP15753735.8A priority patent/EP3175363A1/fr
Priority to US15/500,791 priority patent/US10437656B2/en
Priority to PCT/FR2015/052124 priority patent/WO2016016587A1/fr
Publication of FR3024567A1 publication Critical patent/FR3024567A1/fr
Application granted granted Critical
Publication of FR3024567B1 publication Critical patent/FR3024567B1/fr
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G06F11/0736—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in functional embedded systems, i.e. in a data processing system designed as a combination of hardware and software dedicated to performing a certain function
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/079—Root cause analysis, i.e. error or fault diagnosis
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3604—Software analysis for verifying properties of programs
    • G06F11/3608—Software analysis for verifying properties of programs using formal methods, e.g. model checking, abstract interpretation

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Health & Medical Sciences (AREA)
  • Biomedical Technology (AREA)
  • Software Systems (AREA)
  • Computer Hardware Design (AREA)
  • Debugging And Monitoring (AREA)

Abstract

L'invention concerne un procédé de détermination automatique de causalité nécessaire ou suffisante de dysfonctionnement d'un système composé d'une pluralité de composants matériels ou logiciels. Le procédé comporte, à partir de l'obtention (22) d'une trace d'exécution comportant une séquence d'évènements observés pendant l'exécution du système, l'obtention d'un sous-ensemble de composants testé comprenant au moins un composant dont la trace d'exécution présente (24) au moins une non-conformité avec la spécification de bon fonctionnement dudit composant, et d'un sous-ensemble de composants traité en fonction dudit sous-ensemble de composants testé ; pour un sous-ensemble de composants traité, un calcul, pour chacun des composants du système, d'un préfixe de trace d'exécution non affecté par des évènements non-conformes à la spécification observés pour les composants du sous-ensemble de composants traité, la détermination d'un modèle d'exécution contrefactuel du sous-ensemble traité, permettant de générer l'ensemble des comportements possibles, commençant par les préfixes non affectés, en l'absence de dysfonctionnement des composants du sous-ensemble de composants traité et la détermination (28, 30) de la causalité nécessaire ou suffisante des composants du sous-ensemble de composants testé pour le dysfonctionnement du système en fonction de la vérification du respect de ladite propriété globale du système par ledit modèle contrefactuel du sous-ensemble de composants traité.

Description

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/ou 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. L'article "A general trace-based framework of logical causality" de G. Gôssler et D.
Le Métayer, publié dans FACS- 10th International Symposium on Format aspects of Component Software, 2013, présente une méthode de détermination de causalité de dysfonctionnement des composants d'un système. Cette méthode nécessite le calcul de cônes d'influence entre évènements observés, et utilise un graphe d'exécution pour la mise en oeuvre. Elle est complexe d'un point de vue calculatoire et implique une sur-estimation de l'influence des défaillances de certains composants sur l'ensemble du système. De plus, cette méthode n'est pas adaptée au cas de l'analyse des causes de dysfonctionnement d'un système temps-réel. 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 causalité nécessaire ou suffisante 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, ledit dysfonctionnement étant observé sous la forme de la violation d'une propriété globale du système pendant une exécution dudit système. Le procédé est mis en oeuvre par un processeur ou un circuit programmable et caractérisé en ce qu'il comporte les étapes de : - pour chacun des composants du système, obtention d'une trace d'exécution comportant une séquence d'évènements observés pendant l'exécution du système ; -obtention d'un sous-ensemble de composants testé comprenant au moins un composant dont la trace d'exécution présente au moins une non-conformité avec la spécification de bon fonctionnement dudit composant, et d'un sous-ensemble de composants traité en fonction dudit sous-ensemble de composants testé ; - pour un sous-ensemble de composants traité, obtention d'un ensemble de préfixes de traces d'exécution, chaque dit préfixe comportant des évènements conformes à la spécification de bon fonctionnement du composant associé ; - calcul, pour chacun des composants du système, d'un préfixe de trace d'exécution non affecté par des évènements non-conformes à la spécification observés pour les composants du sous-ensemble de composants traité ; - détermination d'un modèle d'exécution, dit modèle contrefactuel du sous-ensemble traité, permettant de générer l'ensemble des comportements possibles, commençant par les préfixes non affectés, en l'absence de dysfonctionnement des composants du sous-ensemble de composants traité ; - détermination de la causalité nécessaire ou suffisante des composants du sous-ensemble de composants testé pour le dysfonctionnement du système en fonction de la vérification du respect de ladite propriété globale du système par ledit modèle contrefactuel du sous-ensemble de composants traité. Avantageusement, le procédé de l'invention permet de déterminer un ou plusieurs composants dont le dysfonctionnement est nécessaire ou suffisant pour provoquer un dysfonctionnement du système dans un système de composants pour lesquels une spécification de bon fonctionnement est connue, grâce à la génération d'un modèle contrefactuel, calculé à partir de traces d'exécution observées et apte à générer des traces d'exécution conformes aux spécifications de bon fonctionnement des composants.
Le procédé selon l'invention peut présenter une ou plusieurs des caractéristiques ci-dessous. L'étape de calcul, pour chacun des composants du système, d'un préfixe de trace d'exécution non affecté par des évènements non-conformes à la spécification observés pour les composants du sous-ensemble de composants traité comporte : - une étape de calcul, pour chacun des composants du système, d'un modèle d'extension permettant de générer ledit préfixe de trace d'exécution, et - une étape de composition des modèles d'extension calculés. Le calcul d'un modèle d'extension, pour un composant donné, permettant de générer un préfixe de trace d'exécution comporte, pour un dit préfixe de trace d'exécution comportant un nombre k d'éléments, la génération d'un modèle générateur permettant de générer les k-1 premiers éléments dudit préfixe de trace d'exécution et la combinaison dudit modèle générateur avec un modèle conforme à la spécification de bon fonctionnement dudit composant.
L'étape de calcul comporte en outre une étape de composition des modèles d'extension calculés. Le calcul d'un préfixe de trace d'exécution non affecté par des évènements non- conformes à la spécification, observés pour les composants du sous-ensemble de composants traité, utilise un résultat de la composition des modèles d'extension calculés.
La spécification de bon fonctionnement de chaque composant est modélisée sous la forme d'un modèle d'automate à états finis, les états du modèle étant liés par des transitions, lesdites transitions étant définies à partir de ladite spécification de bon fonctionnement. Les modèles d'extension et ledit modèle contrefactuel sont modélisés sous la forme d'automates à états finis. Pour déterminer la causalité nécessaire dudit sous-ensemble de composants testé, ledit sous-ensemble de composants traité est égal au sous-ensemble de composants testé et à l'étape de détermination de causalité, le sous-ensemble de composants testé est déterminé comme cause nécessaire de dysfonctionnement du système si et seulement si le modèle contrefactuel déterminé respecte ladite propriété globale du système. Pour déterminer la causalité suffisante dudit sous-ensemble de composants testé, ledit sous-ensemble de composants traité est égal au sous-ensemble de composants complémentaire audit sous-ensemble de composants testé, et à l'étape de détermination de causalité, le sous-ensemble de composants testé est déterminé comme cause suffisante de dysfonctionnement du système si et seulement si le modèle contrefactuel déterminé viole inévitablement ladite propriété globale du système. Le procédé selon l'invention s'applique notamment lorsque le système comporte des composants matériels et/ou des composants logiciels.
Selon un autre aspect, l'invention concerne un dispositif de détermination automatique de causalité nécessaire ou suffisante 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, ledit dysfonctionnement étant observé sous la forme de la violation d'une propriété globale du système pendant une exécution dudit système, comportant un processeur ou un circuit programmable. Le dispositif comporte des unités adaptées pour : - pour chacun des composants du système, obtenir une trace d'exécution comportant une séquence d'évènements observés pendant l'exécution du système ; - obtenir un sous-ensemble de composants testé comprenant au moins un composant dont la trace d'exécution présente au moins une non-conformité avec la spécification de bon fonctionnement dudit composant, et un sous-ensemble de composants traité en fonction dudit sous-ensemble de composants testé ; - pour un sous-ensemble de composants traité, obtenir un ensemble de préfixes de traces d'exécution, chaque dit préfixe comportant des évènements conformes à la spécification de bon fonctionnement du composant associé ; - calculer, pour chacun des composants du système, un préfixe de trace d'exécution non affecté par des évènements non-conformes à la spécification observés pour les composants du sous-ensemble de composants traité ; - déterminer un modèle d'exécution, dit modèle contrefactuel du sous-ensemble traité, permettant de générer l'ensemble des comportements possibles, commençant par les préfixes non affectés, en l'absence des dysfonctionnements des composants du sous-ensemble de composants traité ; - déterminer la causalité nécessaire ou suffisante des composants du sous-ensemble de composants testé pour le dysfonctionnement du système en fonction de la vérification du respect de ladite propriété globale du système par ledit modèle contrefactuel du sous-ensemble de composants traité. Selon un autre aspect, l'invention concerne un programme d'ordinateur comportant des instructions pour mettre en oeuvre les étapes d'un procédé de détermination automatique de causalité nécessaire ou suffisante de dysfonctionnement d'un système composé d'une pluralité de composants matériels ou logiciels tel que brièvement présenté ci-dessus lors de l'exécution du programme par un processeur ou un circuit programmable d'un dispositif programmable. Selon un autre aspect, l'invention concerne un support d'enregistrement d'informations, caractérisé en ce qu'il comporte des instructions pour l'exécution d'un procédé de détermination automatique de causalité nécessaire ou suffisante de dysfonctionnement d'un système composé d'une pluralité de composants matériels ou logiciels tel que présenté ci-dessus, lorsque ces instructions sont exécutées par 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 causalité nécessaire et/ou suffisante de dysfonctionnement selon un mode de réalisation de l'invention ; - les figures 3, 4 et 5 illustrent schématiquement des modèles de représentation de composants selon un exemple de mise en oeuvre ; - la figure 6 représente un exemple de trace d'exécution d'un système comportant des composants modélisés selon les modèles des figures 3 à 5 ; - la figure 7 est un organigramme d'un procédé de détermination de causalité nécessaire selon un mode de réalisation de l'invention ; - la figure 8 représente un ensemble de traces d'exécution tronquées ; - la figure 9 représente une pluralité de modèles d'extension calculés à partir des traces d'exécution tronquées de la figure 8 ; - la figure 10 représente un ensemble de préfixes d'exécution non affectés calculés en appliquant les modèles d'extension de la figure 8 ; - la figure 11 illustre schématiquement un modèle contrefactuel calculé ; - la figure 12 est un organigramme d'un procédé de détermination de causalité suffisante selon un mode de réalisation de l'invention.
L'invention sera décrite ci-après dans le cas général d'un système à multiples composants, qui sera illustré par un cas schématique de système de surveillance industrielle. 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, l'invention permet de traiter 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 composants sont considérés comme des « boîtes noires », dont seules les entrées et les sorties sont connues, ainsi qu'une spécification de bon fonctionnement, et ce sont ces informations qui sont utiles pour la détermination de causalité de dysfonctionnement. Ainsi, l'invention s'applique de manière générique à tout type de composants qui interagissent, chacun ayant une spécification de bon fonctionnement associée. Les évènements et données 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é nécessaire et/ou suffisante 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 nécessaire et/ou suffisante du système analysé.
La figure 2 illustre un mode de réalisation d'un procédé de détermination de causalité nécessaire et/ou suffisante 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 n 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 et mémorisées. En effet, le procédé de détermination de causes de dysfonctionnement selon l'invention utilise une formalisation mathématique du comportement d'un système, permettant ainsi une application à tout type de système à composants matériels ou logiciels. L'invention s'applique à tout modèle de comportement de système, mais sera décrite ci-après dans un mode de réalisation, dans lequel le comportement d'un tel système et de ses composants est modélisé par un système de transitions étiquetées (labeled transition system, LTS). Il existe des outils informatiques pour effectuer automatiquement les opérations décrites ci-dessous sur les LTS. Un LTS B = (Q,E,,q0) consiste en un ensemble d'états Q, un alphabet d'évènements E, une relation de transition notée où QxExQ et go un état initial.
On écrit q q' pour le triplet (q, a, q') qui représente une transition étiquetée par l'évènement a entre un premier état q et un deuxième état q' . Pour un système S comportant une pluralité de composants, la spécification de bon fonctionnement de chaque composant i est donnée par un LTS C, , , q(,) ) .
Le modèle de bon fonctionnement du système S est obtenu par une composition des modèles des composants du système. La composition de modèles est notée 11 . On note : C = 11C2...K = (Q1 x Q2 x , Et ,---, q'°)) Où les transitions sont définies comme suit : )) a Vi n: (a E Ei A iq;) y (a e Ei A qi = En d'autres termes, l'alphabet de la composition des modèles C, est l'union des alphabets des modèles ; C peut effectuer une transition étiquetée par a si et seulement si tous les modèles qui ont a dans leur alphabet sont prêts à faire une transition a dans leur état actuel.
Soit P une propriété globale de bon fonctionnement du système S, dont la violation constitue un dysfonctionnement, telle que si tous les composants de S satisfont leur spécification, alors P est respectée. Afin de faciliter l'explication, considérons l'exemple d'un système comprenant trois composants : une usine Plant utilisant un réacteur dont la température doit être maintenue à un certain niveau ; un composant de supervision Supervisor qui mesure la température et qui active soit un chauffage soit un refroidissement ; un composant Env qui modélise l'évolution de la température en fonction des actions du composant de supervision. Le système S est donc formé de trois composants qui sont respectivement le composant de supervision Supervisor, l'usine à réacteur Plant et le composant d'environnement Env. Les figures 3, 4 et 5 illustrent schématiquement, pour l'exemple traité, les spécifications de bon fonctionnement des composants Supervisor, Plant et un modèle d'environnement Env incluant un état indiquant une violation de propriété de bon fonctionnement, noté 1.
Le modèle de fonctionnement du composant Supervisor est illustré à la figure 3. Le composant Supervisor interagit avec le composant Env pour recueillir la température courante du réacteur dans l'état Q. .
Si la température est comprise entre des seuils prédéfinis Tmin, Tmax, notée med pour température médium, le composant Supervisor effectue une transition med vers un état Qs2, attend une durée de temporisation (transition t), et retourne dans l'état Qs1 ; aucune action auprès du composant Plant n'est requise.
Si la température captée est inférieure au seuil minimal de bon fonctionnement, le composant Supervisor effectue une transition low vers l'état Qs3 , suivie d'une transition heat vers l'état Q. Si la température captée est supérieure au seuil maximal de bon fonctionnement, le composant Supervisor effectue une transition high vers l'état Qs4 , suivie d'une transition cool vers l'état Q. Depuis l'état Qs2 la transition t effectue la temporisation et le retour à l'état Qs1 de réception de température captée. Le modèle associé au composant Plant est illustré à la figure 4, et montre les états et les transitions autorisés selon la spécification de bon fonctionnement de ce composant.
Le composant Plant est, dans un premier état VE, dans un mode où la température du réacteur augmente. Le composant Plant effectue une transition t vers l'état Qp2 d'où une transition inc, représentant une augmentation de température, permet de repasser au premier état VE. Dans le cas d'une commande cool reçue du composant Supervisor, le composant Plant effectue une transition vers l'état Q. . Dans l'état QI,' , une transition t mène vers l'état Qp4, d'où une transition dec permet de repasser à l'état Q; ; ceci modélise une diminution de la température du réacteur à chaque unité de temps. De l'état QE3 , l'état Q. peut être atteint par une commande heat reçue du composant Supervisor. Le modèle du composant Env , équipé d'un état noté 1 qui modélise une violation de fonctionnement correct, notée 1 est illustré à la figure 5. Le composant Env a six états de bon fonctionnement associés, notés VE, QE2 , Q3E , Q5E QE Les états VE et Qp4 sont associés à une température captée Temp fournie par des capteurs. Si la température Temp est dans l'intervalle de bon fonctionnement [Tmin, 'maxi, l'état QE1 est maintenu par une séquence de transitions med (transmission de la température captée au Supervisor) suivie de t. Dans le cas où la température diminue, le composant passe à l'état QE2 par une transition dec. Tant que la température captée est inférieure à Tmin, le composant reste dans les états QE2 et QE5 (transitions /ow t). Si la température augmente, une transition inc vers l'état QE1 est appliquée. Dans le cas où la température captée à l'état QE1 augmente, le composant passe de l'état QE1 à l'état QE3 par une transition inc. Tant que la température captée est supérieure à Tm', le composant reste dans les états QE3 et QE6 (transitions high ; t).
Si la température baisse, une transition dec de l'état QE3 vers l'état QE1 est appliquée. Si la température diminue davantage (transition dec) dans l'état QE2 ou si la température augmente davantage (transition inc) dans l'état QE3 , alors le système est en violation d'une propriété de bon fonctionnement et l'état noté 1 est atteint.
De retour à la figure 2, après l'étape de mémorisation préliminaire 20 de caractérisation du système, une exécution du système fournissant un journal d'exécution comprenant un ensemble de traces tr1 pour chacun des composants du système est appliquée. En effet, lors d'une exécution du système, chaque composant a un journal d'exécution associé, appelé également trace du composant et noté tr1. Le journal d'exécution comporte une séquence d'évènements observés, chaque évènement correspondant à une transition entre états du composant comme défini ci-dessus. On appelle, pour chaque composant, une première portion de la trace du composant un préfixe de ladite trace. On note qu'un préfixe d'une trace d'exécution est une troncature de la trace. Dans le mode de réalisation utilisant un modèle LTS, pour une définition formelle, considérant un système LTS B = (Q,E, qo ) , une trace d'exécution : tr a2....ak est une séquence d'évènements. Elle est acceptée par B s'il existe une séquence de transitions faisant passer B d'un état initial q à un état q' tel a2 ak que : qk-1.7' les états a E Selon un mode de réalisation, les journaux d'exécution ou traces tr, 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 ou traces tr, 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 tr, séparés sont obtenus pour chacun des composants.
Selon une variante possible, les traces d'exécution tr, 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 tr, par composant à partir d'un ou plusieurs tels fichiers enregistrant des séquences d'évènements pour plusieurs composants.
Le procédé de l'invention est utilisé lorsqu'une exécution du système est incorrecte, ou, en d'autres termes, lorsque pour l'exécution du système se produit un dysfonctionnement, qui est une non-conformité au niveau d'une ou plusieurs des propriétés globales du système P. Un exemple de journal d'exécution du système S pris en exemple, dont les modèles des composants sont illustrés aux figures 3, 4 et 5, est illustré à la figure 6. Un tableau T illustre des traces d'exécution respectives des composants Supervisor, Plant, Env, notées tr S, tr P, et tr E. Dans cet exemple, la trace d'exécution tr S du composant Supervisor comporte un évènement qui n'est pas conforme au modèle illustré à la figure 3 : il s'agit de l'évènement t entouré dans le tableau T. En effet, d'après le modèle de la figure 3, un évènement high devrait être suivi d'un évènement cool et non d'une temporisation t. De même, la trace d'exécution tr P du composant Plant comporte un évènement qui n'est pas conforme au modèle illustré à la figure 4 : il s'agit de l'évènement t entouré dans le tableau T. En effet, d'après le modèle de la figure 4, il n'est pas possible de rencontrer deux transitions t successives. Ainsi, le système S présente un dysfonctionnement et une violation de la spécification, puisque pour le composant Env, la transition high est suivie de inc, ce qui est contraire à la propriété globale de bon fonctionnement (voir figure 5).
De retour à la figure 2 , l'étape 22 d'obtention de traces d'exécution est suivie d'une étape 24 de détection de dysfonctionnement, c'est-à-dire de non-conformité avec une propriété globale P du système, qui s'applique quelle que soit la modélisation du comportement du système.
En cas de détection de dysfonctionnement à l'étape 24, cette étape est suivie d'une étape 26 de sélection d'un sous-ensemble I de composants, comportant chacun une trace d'exécution comportant un évènement non conforme au modèle. Le sous-ensemble I comporte R indices, 1, et N, N étant le nombre total de composants du système S observé.
Le sous-ensemble / de composants est le sous-ensemble dont la causalité nécessaire et/ou suffisante vis-à-vis du dysfonctionnement observé est testée, et est appelé sous-ensemble de composants testé. Le procédé analyse la causalité jointe des composants du sous-ensemble / testé. Il est à noter que la méthode de l'invention est applicable théoriquement avec un sous-ensemble / de composants ne comportant pas de non-conformité dans la trace d'exécution, mais un tel cas est sans intérêt en pratique. En effet, la méthode a pour objectif de déterminer lequel ou lesquels des composants du système étudié est la cause du dysfonctionnement observé. Ensuite, les étapes 28 de détermination de causalité nécessaire des composants du sous-ensemble / et 30 de détermination de causalité suffisante des composants du sous-ensemble / sont mises en oeuvre. Ces étapes peuvent être mises en oeuvre sensiblement simultanément ou séquentiellement. En variante, seule l'une des étapes de détermination de causalité nécessaire 28 ou de détermination de causalité suffisante 30 est mise en oeuvre pour un sous-ensemble de composants / testé. Ainsi, l'invention permet de déterminer, en testant plusieurs sous-ensembles de composants /, de manière précise, les composants dont le dysfonctionnement est nécessaire et/ou suffisant pour constater le dysfonctionnement global du système par rapport à la propriété P. La figure 7 illustre un mode de réalisation de l'étape de détermination de causalité nécessaire du sous-ensemble / de composants. Le procédé illustré schématiquement à la figure 7 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. Lors d'une première étape 32, considérant le sous-ensemble de composants /, un journal d'exécution tronqué est obtenu.
Il est à noter que pour la détermination de la causalité nécessaire du sous- ensemble de composants testé, les étapes 32 à 40 s'appliquent à ce sous-ensemble de composants, comme expliqué ci-dessous. Pour chaque composant d'indice ik E /, la trace d'exécution tri, est tronquée pour n'en retenir que le préfixe tri, conforme au modèle du composant Cik.
En pratique, le préfixe tri,' comprend la séquence d'évènements de tri, qui précède l'évènement non conforme au modèle détecté, appelé également erreur par rapport à l'exécution du composant considéré. Pour chaque composant d'indice i1 e Ic, où Ic est le sous-ensemble d'indices complémentaire de sous-ensemble /, les traces d'exécution sont inchangées : tr, =t La figure 8 illustre le journal d'exécution tronqué, représenté dans un tableau T', pour l'exemple développé et pour le sous-ensemble / comprenant le composant Supervisor. Comme on le voit sur la figure 8, le préfixe tr' _S ne comporte que les trois premiers éléments de la trace d'exécution tr _S pour le composant Supervisor, et les traces/préfixes tr` _P et tr' _E sont inchangés pour les deux autres composants. Ensuite, lors d'une étape 34 d'obtention de modèles d'extension, pour chacun des préfixes tr', du journal d'exécution tronqué, on détermine un modèle d'extension, permettant de générer l'ensemble des traces d'exécution comportant le préfixe tr', et conformes au modèle du composant Ci.
Dans le mode de réalisation utilisant un modèle LTS, pour une trace tr = a, a2....ak , on note T(tr) un modèle LTS permettant de générer exactement la trace tr , appelé modèle générateur de tr . Le modèle générateur T(tr) est défini comme suit : T(tr) = Un modèle d'extension, noté M(tr), d'une trace tr = a, a2 ....ak conforme au modèle LTS B = (Q,E,,q0) est défini à partir du modèle générateur du préfixe tr' = al. a2....ak_i et du modèle B . On note T(tr') = (Q' ) .
On note le modèle d'extension de la trace tr = ai - a2....ak Refine B(tr)=(Q",E, ) , avec : Q" Q' et {"=u 'LJ (qk-i,c1k,q) Le modèle d'extension de la trace tr = ai - a2....- ak_i - ak est obtenu par composition du modèle générateur T(trp) du préfixe trp de la trace tr , correspondant à la trace tr sans son dernier évènement ak et de l'ensemble des transitions conformes au modèle B permettant de passer de l'état qk_1 du modèle générateur T(trp) à un état q du modèle B .
Si, au contraire, un préfixe trp de la trace tr d'un composant n'est pas conforme à son modèle de bon fonctionnement, alors son modèle d'extension est égal au modèle générateur T(trp). L'obtention du modèle d'extension de trace s'applique quelle que soit la modélisation du comportement du système.
Il est à noter que l'obtention d'un modèle d'extension pour une trace tr expliquée ci-dessus est applicable de manière analogue à tout préfixe d'une trace tr , dans la mesure où un préfixe d'une trace est également une trace tronquée, comportant moins d'éléments qu'une trace tr complète. Ainsi, à l'étape 34 de génération de modèles d'extension, un modèle d'extension M t(tri') est obtenu pour chaque préfixe tr; du journal d'exécution tronqué. La figure 9 illustre les modèles d'extension Ms, Mp, ME obtenus à partir des préfixes du journal d'exécution tronqué illustré à la figure 8. Les notations sont analogues aux notations des figures 3, 4, 5 et ne sont pas ré-expliquées en détail ici.
Comme illustré à la figure 9, pour les composants respectifs Plant et Env, les modèles d'extension sont en fait les modèles générateurs des traces tr' _P et tr' _E respectives. Pour le composant Supervisor, le modèle d'extension est une combinaison du modèle générateur de la trace tr' S, privé de la dernière transition {high} (on note tr' S\{ high} ), et de la transition high vers le modèle correspondant Cs illustré à la figure 3. tr qo L'étape 34 de génération de modèles d'extension est suivie d'une étape 36 de construction d'un ensemble de préfixes non affectés par l'erreur ou les erreurs des composants du sous-ensemble I , notés {tr*,}. La construction de cet ensemble est réalisée par troncature de tous les préfixes {tri) obtenus à l'étape 32 en fonction de la combinaison des modèles d'extension calculés à l'étape 34. La combinaison des modèles d'extension g(tr;) calculés à l'étape 34 fournit un modèle : M = Mi(tri) M2 ( tr; ) . Mn(tr'n) Deux modes de réalisation sont envisagés pour l'étape 34. Selon un premier mode de réalisation, la troncature est effectuée simultanément : pour chaque i =1,...,n . On obtient tr* comme préfixe le plus long de tr' qui peut être produit par M (tr;) dans la composition : Mi (tri ) Mi-1(tr-i) T (t r) .. .11M (t r ,)1113 Où B est un modèle de comportement du système global. La combinaison avec B est optionnelle. Selon un deuxième mode de réalisation, les composants sont considérés dans un ordre prédéterminé, par exemple l'ordre croissant des indices ; après l'obtention de chaque préfixe non affecté son modèle d'extension est mis à jour dans la composition avant de calculer le préfixe non affecté de la trace suivante. La figure 10 illustre l'ensemble T* de préfixes non affectés {tr*;} obtenu dans l'exemple de réalisation, obtenu en utilisant les modèles d'extension de la figure 9 selon le premier mode de réalisation de l'étape 36 décrit ci-dessus.
L'ensemble T* obtenu est l'ensemble des préfixes de longueur maximale que l'on aurait pu observer en l'absence des erreurs d'exécution du système S. De retour à la figure 7, l'étape 36 de construction de l'ensemble de préfixes non affectés est suivie d'une étape 38 de construction d'un modèle MC(/), appelé modèle contrefactuel construit par rapport au sous-ensemble de composants I. Le modèle MC(I) est obtenu par composition des modèles d'extension de chacun des préfixes non affectés {tr;*}, fonction des modèles LTS respectifs de chacun des composants.
Pour un composant d'indice i, on note 13,(tr,*) le modèle d'extension correspondant, obtenu comme expliqué ci-dessus à l'étape 34. Le modèle contrefactuel MC(I) est la composition des modèles d'extension 13,(tr,*) avec le modèle B de comportement global du système : MC(I) = Bi (tri* ) B2(tr; )..11B'(tr: )0B En variante, le modèle contrefactuel MC(I) est la composition des modèles d'extension 13,(tr,*) sans modèle B de comportement global du système. Le modèle contrefactuel MC(I) est un modèle des traces d'exécution fictives, qui auraient pu être observées en l'absence d'erreurs des composants du sous-ensemble / considéré. Ainsi, le modèle contrefactuel du sous-ensemble traité permet de générer l'ensemble des comportements possibles commençant par les préfixes non affectés, en l'absence de dysfonctionnements des composants du sous-ensemble de composants traité. Ensuite, lors de l'étape de test du modèle contrefactuel MC(I) il est vérifié si le modèle contrefactuel satisfait la propriété P qui n'a pas été respectée lors de l'exécution du système S. Dans le mode de réalisation utilisant une modélisation LTS, une propriété P est également représentée par un modèle LTS : P = (Qp, 10,1710()) On construit un modèle d'observation de la propriété P, noté 0(P) : 0(P) = (Qp u 111E, P q°P) Avec {'pe =pe U (q, a,1) qeQActeEAVq'eQ:-1(q4 q')} Où la relation de transition est la relation de transition du modèle testé, ici MC(/). En d'autres termes, les transitions du modèle d'observation comportent les transitions définies pour le modèle de la propriété P et les transitions qui, acceptant un évènement qui n'est pas conforme à la propriété testée, aboutissent à un état d'erreur. Le modèle testé MC(/) satisfait la propriété P si et seulement si il n'existe pas d'état qe Qx tel que (q0,qp° ) *q où est la fermeture transitive de En d'autres termes, le modèle contrefactuel MC(/) satisfait la propriété P si aucune séquence d'évènements générés par le modèle n'aboutit à l'état d'erreur 1. En pratique, la satisfaction de la propriété P est vérifiée par un algorithme d'atteignabilité - tel qu'implémenté dans des logiciels de model-checking comme CADP (« Construction and Analysis of Distribution Processes » , disponible en ligne à l'adresse http://cadp.inria.fr/) , NuSMV (logiciel OpenSource disponible en ligne) et Uppaal (logiciel développé par l'Université d'Uppsala, Suède et par l'Université d'Aalborg, Danemark, disponible en ligne) - qui vérifie si l'état 1 est atteignable. En fonction du résultat de l'étape de vérification de la satisfaction de la propriété P par le modèle contrefactuel MC(/), une décision concernant la causalité nécessaire des erreurs de composants du sous-ensemble / est rendue à l'étape 42, quelle que soit la modélisation du système. Si le modèle contrefactuel MC(/) satisfait la propriété P, alors il est décidé que les erreurs des composants du sous-ensemble / sont une cause nécessaire de dysfonctionnement du système S. Si au contraire le modèle contrefactuel MC(/) généré ne satisfait pas la propriété P, alors les erreurs des composants du sous-ensemble / ne sont pas une cause nécessaire de dysfonctionnement du système S. La figure 11 illustre le modèle contrefactuel obtenu pour l'exemple développé, considérant le composant Supervisor comme sous-ensemble de composants testés. Le modèle contrefactuel est obtenu par composition des modèles d'extension. Le modèle contrefactuel obtenu satisfait la propriété P, ce qui permet de déduire que l'erreur constatée dans la trace d'exécution du composant Supervisor est une cause nécessaire du dysfonctionnement du système.
La figure 12 illustre un mode de réalisation de l'étape de détermination de causalité suffisante du sous-ensemble / de composants. Le procédé illustré schématiquement à la figure 12 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. Lors d'une première étape 50 de détermination d'un sous-ensemble complémentaire de composants, un sous-ensemble f comportant les indices des composants du système S et qui ne font pas partie du sous-ensemble / est déterminé.
Les étapes suivantes 52, 54, 56, 58 sont analogues aux étapes 32, 34, 36, 38 précédemment décrites, en considérant le sous-ensemble F comme sous-ensemble de composants traité à la place du sous-ensemble /. A l'issue de ces étapes, un modèle contrefactuel MC(f) est obtenu.
L'étape de vérification 60 consiste à vérifier si le modèle contrefactuel MC(f) viole systématiquement la propriété P, donc si toutes les traces obtenues conformément à ce modèle comportent un enchaînement d'évènements non conforme à P. Une telle vérification est effectuée par la mise en oeuvre d'un procédé systématique appelé vérification d'inévitabilité - tel qu'implémenté dans des logiciels de model-checking comme CADP, NuSMV et Uppaal - de la violation de P. Si le modèle contrefactuel MC(f) viole inévitablement la propriété P, il est déterminé à l'étape 62 que le sous-ensemble de composants / est une cause suffisante de dysfonctionnement du système. Si au moins certaines des traces qu'on peut obtenir en appliquant le modèle contrefactuel MC(f) satisfont P, alors il est déterminé à l'étape 62 que le sous-ensemble de composants / n'est pas une cause suffisante de dysfonctionnement du système. L'invention a été décrite ci-dessus plus particulièrement dans un mode de réalisation dans lequel le système est modélisé sous forme de LTS. Dans une variante, le comportement du système et de ses composants est modélisé par des automates temporisés. L'invention s'applique plus généralement à toute modélisation d'un système et de ses composants qui permet de construire des outils pour : construire un modèle T(tr) , modèle générateur d'une trace tr ; construire un modèle d'extension de la trace tr, conforme à un modèle B donné ; calculer une composition de modèles C, donnés, C = CIC211...11Cn vérifier si une trace tr peut être produite par un modèle M, et si une trace tr peut être produite par un modèle M composé avec les modèles d'autres composants ; vérifier la satisfaction d'une propriété P donnée par un modèle ; vérifier si un système viole inévitablement une propriété P donnée. Il est à noter que l'invention a été 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 /. 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- 1 0 ensemble / considéré comme susceptible d'être cause nécessaire et/ou suffisante de dysfonctionnement, ou pour une partie de ces sous-ensembles, et permet de déterminer notamment le sous-ensemble minimal de composants dont le comportement observé est une cause nécessaire et/ou suffisante pour le dysfonctionnement observé. 15

Claims (8)

  1. REVENDICATIONS1.- Procédé de détermination automatique de causalité nécessaire ou suffisante 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, ledit dysfonctionnement étant observé sous la forme de la violation d'une propriété globale du système pendant une exécution dudit 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 : -pour chacun des composants du système, obtention (22) d'une trace d'exécution comportant une séquence d'évènements observés pendant l'exécution du système ; -obtention (26) d'un sous-ensemble (/) de composants testé comprenant au moins un composant dont la trace d'exécution présente au moins une non-conformité avec la spécification de bon fonctionnement dudit composant, et d'un sous-ensemble de composants traité (/, /c) en fonction dudit sous-ensemble de composants testé ; - pour un sous-ensemble (/) de composants traité, obtention (32, 52) d'un ensemble de préfixes de traces d'exécution, chaque dit préfixe comportant des évènements conformes à la spécification de bon fonctionnement du composant associé ; -calcul (36, 56), pour chacun des composants du système, d'un préfixe de trace d'exécution non affecté par des évènements non-conformes à la spécification observés pour les composants du sous-ensemble de composants traité ; -détermination (38, 58) d'un modèle d'exécution, dit modèle contrefactuel du sous-ensemble traité, permettant de générer l'ensemble des comportements possibles, commençant par les préfixes non affectés, en l'absence de dysfonctionnement des composants du sous-ensemble de composants traité (/) ; -détermination de la causalité nécessaire (28, 40, 42) ou suffisante (30, 60, 62) des composants du sous-ensemble (/) de composants testé pour le dysfonctionnement du système en fonction de la vérification du respect de ladite propriété globale du système par ledit modèle contrefactuel du sous-ensemble de composants traité.
  2. 2.- Procédé selon la revendication 1, caractérisé en ce que l'étape de calcul (36, 56), pour chacun des composants du système, d'un préfixe de trace d'exécution non affecté par des évènements non-conformes à la spécification observés pour les composants du sous-ensemble de composants traité comporte : -une étape de calcul (34, 56), pour chacun des composants du système, d'un modèle d'extension permettant de générer ledit préfixe de trace d'exécution, et- une étape de composition des modèles d'extension calculés.
  3. 3.- Procédé selon la revendication 2, caractérisé en ce que la spécification de bon fonctionnement de chaque composant est modélisée sous la forme d'un modèle d'automate à états finis, les états du modèle étant liés par des transitions, lesdites transitions étant définies à partir de ladite spécification de bon fonctionnement.
  4. 4.- Procédé selon la revendication 3, caractérisé en ce que les modèles d'extension et ledit modèle contrefactuel sont modélisés sous la forme d'automates à états finis.
  5. 5.- Procédé selon l'une quelconque des revendications 1 à 4, caractérisé en ce que, pour déterminer la causalité nécessaire(40, 42) dudit sous-ensemble (/) de composants testé, ledit sous-ensemble de composants traité est égal au sous-ensemble (/) de composants testé et en ce qu'à l'étape de détermination de causalité, le sous- ensemble (/) de composants (/) testé est déterminé comme cause nécessaire de dysfonctionnement du système si et seulement si le modèle contrefactuel déterminé respecte ladite propriété globale du système.
  6. 6.- Procédé selon l'une quelconque des revendications 1 à 4, caractérisé en ce que, pour déterminer la causalité suffisante (60, 62) dudit sous-ensemble (/) de composants testé, ledit sous-ensemble de composants traité est égal au sous-ensemble (f) de composants complémentaire audit sous-ensemble (/) de composants testé, et en ce qu'à l'étape de détermination de causalité, le sous-ensemble (/) de composants testé est déterminé comme cause suffisante de dysfonctionnement du système si et seulement si le modèle contrefactuel déterminé viole inévitablement ladite propriété globale du système.
  7. 7.- Dispositif de détermination automatique de causalité nécessaire ou suffisante 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, ledit dysfonctionnement étant observé sous la forme de la violation d'une propriété globale du système pendant une exécution dudit système, comportant un processeur ou un circuit programmable, caractérisé en ce qu'il comporte des unités adaptées pour : -pour chacun des composants du système, obtenir une trace d'exécution comportant une séquence d'évènements observés pendant l'exécution du système ;-obtenir un sous-ensemble de composants testé comprenant au moins un composant dont la trace d'exécution présente au moins une non-conformité avec la spécification de bon fonctionnement dudit composant, et un sous-ensemble de composants traité (/, /c) en fonction dudit sous-ensemble de composants testé ; - pour un sous-ensemble (/) de composants traité, obtenir un ensemble de préfixes de traces d'exécution, chaque dit préfixe comportant des évènements conformes à la spécification de bon fonctionnement du composant associé ; -calculer, pour chacun des composants du système, un préfixe de trace d'exécution non affecté par des évènements non-conformes à la spécification observés pour les composants du sous-ensemble de composants traité ; -déterminer un modèle d'exécution, dit modèle contrefactuel du sous-ensemble traité, permettant de générer l'ensemble des comportements possibles, commençant par les préfixes non affectés, en l'absence de dysfonctionnement des composants du sous-ensemble de composants traité (/) ; -déterminer la causalité nécessaire ou suffisante des composants du sous- ensemble (/) de composants testé pour le dysfonctionnement du système en fonction de la vérification du respect de ladite propriété globale du système par ledit modèle contrefactuel du sous-ensemble de composants traité.
  8. 8.- Produit programme d'ordinateur comportant des instructions pour mettre en oeuvre les étapes d'un procédé de détermination automatique de causalité nécessaire ou suffisante de dysfonctionnement d'un système composé d'une pluralité de composants matériels ou logiciels selon l'une des revendications 1 à 6 lors de l'exécution du programme par un processeur ou un circuit programmable d'un dispositif programmable.25
FR1457464A 2014-07-31 2014-07-31 Procede de determination automatique de causes de dysfonctionnement d'un systeme compose d'une pluralite de composants materiels ou logiciels Active FR3024567B1 (fr)

Priority Applications (4)

Application Number Priority Date Filing Date Title
FR1457464A FR3024567B1 (fr) 2014-07-31 2014-07-31 Procede de determination automatique de causes de dysfonctionnement d'un systeme compose d'une pluralite de composants materiels ou logiciels
EP15753735.8A EP3175363A1 (fr) 2014-07-31 2015-07-31 Procédé de détermination automatique de causes de dysfonctionnement d'un système composé d'une pluralité de composants matériels ou logiciels
US15/500,791 US10437656B2 (en) 2014-07-31 2015-07-31 Method for automatically determining causes of the malfunction of a system made up of a plurality of hardware or software components
PCT/FR2015/052124 WO2016016587A1 (fr) 2014-07-31 2015-07-31 Procédé de détermination automatique de causes de dysfonctionnement d'un système composé d'une pluralité de composants matériels ou logiciels

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR1457464A FR3024567B1 (fr) 2014-07-31 2014-07-31 Procede de determination automatique de causes de dysfonctionnement d'un systeme compose d'une pluralite de composants materiels ou logiciels

Publications (2)

Publication Number Publication Date
FR3024567A1 true FR3024567A1 (fr) 2016-02-05
FR3024567B1 FR3024567B1 (fr) 2016-09-02

Family

ID=52450248

Family Applications (1)

Application Number Title Priority Date Filing Date
FR1457464A Active FR3024567B1 (fr) 2014-07-31 2014-07-31 Procede de determination automatique de causes de dysfonctionnement d'un systeme compose d'une pluralite de composants materiels ou logiciels

Country Status (4)

Country Link
US (1) US10437656B2 (fr)
EP (1) EP3175363A1 (fr)
FR (1) FR3024567B1 (fr)
WO (1) WO2016016587A1 (fr)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10474523B1 (en) * 2017-10-27 2019-11-12 EMC IP Holding Company LLC Automated agent for the causal mapping of complex environments
US11032152B2 (en) 2018-04-25 2021-06-08 Dell Products L.P. Machine-learning based self-populating dashboard for resource utilization monitoring in hyper-converged information technology environments

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5528516A (en) * 1994-05-25 1996-06-18 System Management Arts, Inc. Apparatus and method for event correlation and problem reporting
US6807583B2 (en) * 1997-09-24 2004-10-19 Carleton University Method of determining causal connections between events recorded during process execution
US20030121027A1 (en) * 2000-06-23 2003-06-26 Hines Kenneth J. Behavioral abstractions for debugging coordination-centric software designs
US7954090B1 (en) * 2004-12-21 2011-05-31 Zenprise, Inc. Systems and methods for detecting behavioral features of software application deployments for automated deployment management
US8069374B2 (en) * 2009-02-27 2011-11-29 Microsoft Corporation Fingerprinting event logs for system management troubleshooting
US8612377B2 (en) * 2009-12-17 2013-12-17 Oracle International Corporation Techniques for generating diagnostic results

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
GREGOR GÖSSLER ET AL: "A General Trace-Based Framework of Logical Causality", FORMAL ASPECTS OF COMPONENT SOFTWARE, LECTURE NOTES IN COMPUTER SCIENCE VOLUME 8348, 13 June 2014 (2014-06-13), pages 157 - 173, XP055186835, ISBN: 978-3-31-907602-7, Retrieved from the Internet <URL:http://rd.springer.com/content/pdf/10.1007/978-3-319-07602-7_11.pdf> [retrieved on 20150429], DOI: 10.1007/978-3-319-007602-7_11 *
WANG SHAOHUI ET AL ABDELZAHER TAREK ZAHERIOTALLINOIS EDU UNIVERSITY OF ILLINOIS AT URBANA CHAMPAIGN DEPARTMENT OF COMPUTER SCIENCE: "A Causality Analysis Framework for Component-Based Real-Time Systems", 24 September 2013, ADVANCES IN COMMUNICATION NETWORKING : 20TH EUNICE/IFIP EG 6.2, 6.6 INTERNATIONAL WORKSHOP, RENNES, FRANCE, SEPTEMBER 1-5, 2014, REVISED SELECTED PAPERS; [LECTURE NOTES IN COMPUTER SCIENCE , ISSN 1611-3349], SPRINGER VERLAG, DE, PAGE(S) 285 - 303, ISSN: 0302-9743, XP047041675 *

Also Published As

Publication number Publication date
FR3024567B1 (fr) 2016-09-02
US10437656B2 (en) 2019-10-08
EP3175363A1 (fr) 2017-06-07
US20170308424A1 (en) 2017-10-26
WO2016016587A1 (fr) 2016-02-04

Similar Documents

Publication Publication Date Title
EP2286339B1 (fr) Procédé d&#39;élaboration automatique de cas de test pour la vérification d&#39;au moins une partie d&#39;un logiciel
CA2944120C (fr) Procede et dispositif de surveillance d&#39;un parametre d&#39;un moteur de fusee
EP3665490B1 (fr) Procédé, mis en oeuvre par ordinateur, de reconstruction de la topologie d&#39;un réseau de cables, utilisant un algorithme génétique
CA2888716C (fr) Systeme de surveillance d&#39;un ensemble de composants d&#39;un equipement
EP3559767B1 (fr) Procédé de caractérisation d&#39;une ou plusieurs défaillances d&#39;un système
US20130031532A1 (en) Method, computer, and device for validating execution of tasks in adaptable computer systems
FR3035232A1 (fr) Systeme de surveillance de l&#39;etat de sante d&#39;un moteur et procede de configuration associe
EP2859421A1 (fr) Prevision d&#39;operations de maintenance a appliquer sur un moteur
FR3043463A1 (fr) Systeme et procede de surveillance d&#39;une turbomachine avec fusion d&#39;indicateurs pour la synthese d&#39;une confirmation d&#39;alarme
FR3024567A1 (fr) Procede de determination automatique de causes de dysfonctionnement d&#39;un systeme compose d&#39;une pluralite de composants materiels ou logiciels
WO2021069824A1 (fr) Dispositif, procédé et programme d&#39;ordinateur de suivi de moteur d&#39;aéronef
EP3729302B1 (fr) Procédé et système d&#39;aide au dépannage d&#39;un système complexe
FR2957170A1 (fr) Outil de conception d&#39;un systeme de surveillance d&#39;un moteur d&#39;aeronef
FR3003663A1 (fr) Procede de determination automatique de causes de dysfonctionnement d&#39;un systeme compose d&#39;une pluralite de composants materiels ou logiciels
EP1390819B1 (fr) Systeme de diagnostic predictif dans un automate programmable
Xu et al. Error diagnosis of cloud application operation using bayesian networks and online optimisation
EP2339318B1 (fr) Procédé de diagnostic d&#39;un disfonctionnement d&#39;un système mécatronique
EP2996036A1 (fr) Procédé de surveillance d&#39;une architecture applicative comportant une pluralité de services
EP2770439A1 (fr) Surveillance de mesure de performance d&#39;une infrastructure informatique
EP3343375A1 (fr) Procédé et système de surveillance de traitements par lots d&#39;applications exécutées dans une infrastructure informatique
WO2019034497A1 (fr) Procede, mis en oeuvre par ordinateur, de reconstruction de la topologie d&#39;un reseau de cables
FR3025889A1 (fr) Gestion de la recharge de la batterie d&#39;un vehicule electrique
Abdallah et al. Scenario realizability with constraint optimization
WO2019201957A1 (fr) Procédés de mise en oeuvre d&#39;algorithmes d&#39;analyse statistique de données caractérisant le comportement d&#39;un ensemble d&#39;éléments et système associé
CN116540073A (zh) 车规级芯片的安全分析方法、装置、设备及存储介质

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 2

PLSC Publication of the preliminary search report

Effective date: 20160205

PLFP Fee payment

Year of fee payment: 3

PLFP Fee payment

Year of fee payment: 4

PLFP Fee payment

Year of fee payment: 5

PLFP Fee payment

Year of fee payment: 7

PLFP Fee payment

Year of fee payment: 8

PLFP Fee payment

Year of fee payment: 9

PLFP Fee payment

Year of fee payment: 10