WO2016016587A1 - Procédé de détermination automatique de causes de dysfonctionnement d'un système composé d'une pluralité de composants matériels ou logiciels - Google Patents

Procédé de détermination automatique de causes de dysfonctionnement d'un système composé d'une pluralité de composants matériels ou logiciels Download PDF

Info

Publication number
WO2016016587A1
WO2016016587A1 PCT/FR2015/052124 FR2015052124W WO2016016587A1 WO 2016016587 A1 WO2016016587 A1 WO 2016016587A1 FR 2015052124 W FR2015052124 W FR 2015052124W WO 2016016587 A1 WO2016016587 A1 WO 2016016587A1
Authority
WO
WIPO (PCT)
Prior art keywords
components
subset
model
component
execution
Prior art date
Application number
PCT/FR2015/052124
Other languages
English (en)
Inventor
Gregor GÖSSLER
Original Assignee
Inria Institut National De Recherche En Informatique Et En Automatique
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 Inria Institut National De Recherche En Informatique Et En Automatique filed Critical Inria Institut National De Recherche En Informatique Et En Automatique
Priority to US15/500,791 priority Critical patent/US10437656B2/en
Priority to EP15753735.8A priority patent/EP3175363A1/fr
Publication of WO2016016587A1 publication Critical patent/WO2016016587A1/fr

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

Definitions

  • the present invention relates to a method for automatically determining causes of malfunction of a system composed of a plurality of hardware or software components and an associated device.
  • the invention lies in the field of malfunction analysis of systems comprising several software or hardware components, or combining software components and hardware, which interact.
  • interconnected hardware and / or software components distributed over several subsystems, and possibly embedded.
  • treatment systems are composed of interconnected devices, for example pacemakers or infusors connected to surveillance systems.
  • control and monitoring systems use interconnected components, such as speed controllers.
  • This method requires the computation of cones of influence between observed events, and uses an execution graph for the implementation. It is complex from a computational point of view and implies an over-estimation of the influence of the failures of some components on the entire system. Moreover, this method is not adapted to the case of the analysis of the causes of malfunction of a real-time system.
  • the invention proposes, according to a first aspect, a method of automatically determining the necessary or sufficient causality of malfunction of a system composed of a plurality of hardware or software components, each component having a specification of associated smooth operation, said malfunction being observed in the form of violation of a global property of the system during execution of said system.
  • obtaining a subset of tested components comprising at least one component whose execution trace has at least one nonconformity with the specification of the proper functioning of said component, and a subset of components processed according to said subset of components tested;
  • each prefix comprising events compliant with the functional specification of the associated component
  • the method of the invention makes it possible to determine one or more components whose malfunction is necessary or sufficient to cause a malfunction of the system in a system of components for which a specification of good operation is known, thanks to the generation of a Counterfactual model, calculated from observed execution traces and able to generate traces of execution in accordance with the specifications of good operation of the components.
  • the method according to the invention may have one or more of the features below.
  • the step of computing, for each of the system components, an execution trace prefix not affected by non-specification-compliant events observed for components of the processed component subset includes:
  • the calculation of an extension model, for a given component, for generating an execution trace prefix comprises, for a said execution trace prefix comprising a number k of elements, the generation of a model generator for generating the first k-1 elements of said execution trace prefix and the combination of said generator model with a model according to the specification of good operation of said component.
  • the calculation step further comprises a step of composing the calculated extension models.
  • the calculation of a non-conforming event trace prefix not affected by the specification, observed for components of the processed subset of components, uses a result of the composition of the calculated extension models.
  • each component is modeled as a finite state machine model, the states of the model being linked by transitions, said transitions being defined from said performance specification.
  • extension models and the counterfactual model are modeled as finite state machines.
  • said processed subset of components is equal to the tested subset of components and at the causality determination step, the tested subset of components is determined as the cause. necessary to malfunction of the system if and only if the counterfactual model determined respects said overall property of the system.
  • said treated subset of components is equal to the subset of components complementary to said tested subset of components, and to the causality determination step, the subset of components set of components tested is determined as the cause sufficient dysfunction of the system if and only if the determined counterfactual model inevitably violates said overall property of the system.
  • the method according to the invention applies in particular when the system comprises hardware components and / or software components.
  • the invention relates to a device for automatically determining necessary or sufficient causality of malfunction of a system composed of a plurality of hardware or software components, each component having an associated performance specification, said dysfunction being observed. in the form of the violation of a global property of the system during an execution of said system, comprising a processor or a programmable circuit.
  • the device comprises units adapted to:
  • obtaining a subset of tested components comprising at least one component whose execution trace has at least one nonconformity with the specification of good operation of said component, and a subset of components processed according to said subset tested components;
  • each prefix comprising events compliant with the specification of the functioning of the associated component
  • the invention relates to a computer program comprising instructions for implementing the steps of a method for automatically determining the necessary or sufficient causality of malfunction of a system composed of a plurality of hardware components or software such as briefly presented above when executing the program by a processor or a programmable circuit of a programmable device.
  • the invention relates to an information recording medium, characterized in that it comprises instructions for executing a method for automatically determining the necessary or sufficient causality of malfunction of a compound system. of a plurality of hardware or software components as presented above, when these instructions are executed by a programmable device.
  • FIG. 1 is an example of a system implementing the invention
  • FIG. 2 is a flowchart of a necessary and / or sufficient method of determining causality of malfunction according to one embodiment of the invention
  • FIGS. 3, 4 and 5 schematically illustrate models of representation of components according to an example of implementation
  • FIG. 6 represents an exemplary execution trace of a system comprising components modeled according to the models of FIGS. 3 to 5;
  • FIG. 7 is a flowchart of a necessary causality determination method according to an embodiment of the invention.
  • FIG. 8 represents a set of truncated execution traces
  • FIG. 9 represents a plurality of extension models calculated from the truncated execution traces of FIG. 8;
  • FIG. 10 represents a set of unassigned execution prefixes calculated by applying the extension models of FIG. 8;
  • FIG. 11 schematically illustrates a calculated counterfactual model
  • FIG. 12 is a flowchart of a sufficient causality determination method according to one embodiment of the invention.
  • the invention is not limited to this example of application and can be applied to any type of system based on components able to communicate with each other according to a given communication model.
  • the invention finds applications in particular in medical device systems integrating software components, in embedded systems in vehicles or trains, in aeronautics and aerospace, in power plants, in distribution networks. energy and in web services.
  • the invention can be applied during or after the execution of a system. It can also be applied when validating a system; in this case it identifies the components that caused the malfunctions observed during tests.
  • the invention can be applied while running a system when a malfunction is observed, thereby allowing identification of the component (s) causing the malfunction.
  • FIG. 1 illustrates a system 1 embodying the invention, comprising a three-component communication system 2, 4, 6, 8, which are able to communicate with one another by means of communication messages, represented by arrows in the figure.
  • the number of components is limited to three in Figure 1 for ease of explanation, but in practice, the invention makes it possible to process any number of components.
  • the components 4, 6 and 8 shown in Figure 1 are all connected to each other by transmitting / receiving connections, such an architecture is not necessary, the components can be only partially connected to each other.
  • an event sequence is stored in an execution log stored in a respective file 10, 12, 14.
  • each component has an associated execution log, stored separately. .
  • only one execution log is stored for all or a subset of system components 2.
  • the components are considered as "black boxes", of which only the inputs and outputs are known, as well as a specification of good operation, and it is this information that is useful for the determination of causality of malfunction.
  • the events and data stored in the execution logs relate for example to the communications, that is to say the messages sent and received, on function calls, on the writing and reading of shared variables, and / or on a summary of internal calculation steps such as the functions executed with parameter values and return values.
  • the stored execution logs, including the observed event sequences for each component, are then used in a device 16 for automatically determining causes of malfunction.
  • the device 16 implements a necessary and / or sufficient causality determination method according to the invention, and indicates at the output 18 one or more failed components among all the components of the system.
  • the device 16 is a programmable device and comprises in particular a processor or a programmable circuit capable of implementing modules for automatically determining causes of necessary and / or sufficient malfunction of the analyzed system.
  • FIG. 2 illustrates an embodiment of a method for determining the necessary and / or sufficient causality of dysfunction of a system according to the invention, in the case where a malfunction is observed, during the execution of the system or after system execution.
  • the method is implemented by a programmable device such as a computer, comprising in particular a programmable circuit or a processor capable of executing control program instructions when the device is powered up and information storage means capable of storing executable code instructions allowing the implementation of programs capable of implementing the method according to the invention.
  • a programmable device such as a computer, comprising in particular a programmable circuit or a processor capable of executing control program instructions when the device is powered up and information storage means capable of storing executable code instructions allowing the implementation of programs capable of implementing the method according to the invention.
  • the method for determining causes of malfunction according to the invention uses a mathematical formalization of the behavior of a system, thus allowing application to any type of system with hardware or software components.
  • the invention applies to any model of system behavior, but will be described hereinafter in one embodiment, in which the behavior of such a system and its components is modeled by a system of labeled transitions (labeled transition). system, LTS).
  • LTS labeled transition
  • An LTS B (Q, ⁇ , - » q 0 ) consists of a set of states Q, an event alphabet ⁇ , a transition relation denoted by -», where -> ç gx ⁇ xg and 0 a state initial.
  • q ⁇ q ' for the triplet (q, a, q') e-> which represents a transition labeled by the event a between a first state q and a second state q '.
  • the model of good operation of the system S is obtained by a composition of the models of the components of the system.
  • the composition of models is noted II.
  • the alphabet of the composition of the C models is the union of the alphabets of the models; C can make a transition labeled a if and only if all the models that have in their alphabet are ready to make a transition in their current state.
  • P be a global property of good functioning of the system S, the violation of which constitutes a dysfunction, such that if all the components of S satisfy their specification, then P is respected.
  • a system comprising three components: a plant plant using a reactor whose temperature must be maintained at a certain level; a supervisor supervisory component that measures the temperature and activates either heating or cooling; an Env component that models the evolution of the temperature according to the actions of the supervision component.
  • the system S is thus formed of three components which are respectively the Supervisor supervisory component, the Plant reactor plant and the Env environment component.
  • Figures 3, 4 and 5 schematically illustrate, for the example discussed, the performance specifications of the Supervisor, Plant components and a Env environment model including a state indicating a violation of property of operation, noted _L.
  • the Supervisor component interacts with the Env component to collect the current reactor temperature in the Q state. If the temperature is between preset thresholds T m in, T ma x, denoted med for medium temperature, the Supervisor component performs a med transition to a Ql state, waits for a delay time (transition t), and returns to the state Q; no action with the Plant component is required.
  • the Supervisor component performs a low transition to the Q S 3 state , followed by a beat transition to the Q 2 state.
  • the Supervisor component makes a high transition to the Q S A state , followed by a cool transition to the Q 2 state.
  • the transition f carries out the delay and the return to the received temperature reception state Q.
  • the Plant component is, in a first state Q p l , in a mode where the temperature of the reactor increases.
  • the Plant component makes a transition f to the state Q P 2 from which a transition inc, representing an increase in temperature, makes it possible to go back to the first state Q p l .
  • the Plant component transitions to the Q p state.
  • a transition f leads to the state Q p , from where a transition dec makes it possible to return to the state Q p ; this models a decrease in the temperature of the reactor at each unit of time.
  • the state Q p l can be reached by a beat command received from the Supervisor component.
  • the component Env has six associated operating states, denoted Q E 1 , Q 2 ,
  • the states Q E 1 and Q E A are associated with a temperature sensed Temp provided by sensors. If the temperature Temp is in the operating range [T m in, Tmax], the state Q is maintained by a sequence of med transitions (transmission of the temperature sensed to the Supervisor) followed by f.
  • the component goes to the state Q E 2 by a transition T.
  • the component remains in the states Q E 2 and Q E 5 (transitions low; t).
  • the component passes from the state Q E I to the state Q by a transition inc. As long as the sensed temperature is greater than T ma x, the component remains in states Q and Q E 6 (high transitions; t).
  • an execution of the system providing an execution log comprising a set of traces tn for each of the system components is applied.
  • each component has an associated execution log, also called component trace and noted tn.
  • the execution log includes a sequence of events observed, each event corresponding to a transition between states of the component as defined above.
  • a first portion of the component trace is called a prefix of said trace.
  • a prefix of an execution trace is a truncation of the trace.
  • tr ⁇ ⁇ ⁇ a 2 - ... a k is a sequence of events. It is accepted by B if there exists a sequence of transitions passing B from an initial state q to a state q 'such that: ⁇ , ⁇ ... ⁇ q k _ y -, the states q l , .. ., _ q k l e Q.
  • the execution logs or traces tn are stored during a system execution and are read into a memory of the programmable device implementing the invention.
  • the execution logs or tn traces are used while the system is running.
  • the causality analysis is performed while running, the event sequences that occurred up to the time of analysis are used.
  • step 22 includes extracting the component-by-component tn logs from one or more such files storing event sequences for multiple components.
  • the method of the invention is used when an execution of the system is incorrect, or, in other words, when for the execution of the system there is a malfunction, which is a nonconformity at one or more overall properties of the P system.
  • FIG. 3 An exemplary exemplary system execution log S, the component models of which are illustrated in FIGS. 3, 4 and 5, is illustrated in FIG.
  • a table T illustrates respective execution traces of the Supervisor, Plant, Env components, denoted tr_S, tr_P, and tr_E.
  • the trace trace tr_S Supervisor component includes an event that does not conform to the model shown in Figure 3: it is the event f surrounded in Table T.
  • the execution trace tr_P of the Plant component comprises an event that does not conform to the model illustrated in FIG. 4: it is the event f surrounded in the table T.
  • the system S has a malfunction and a violation of the specification, since for the Env component, the high transition is followed by inc, which is contrary to the overall property of good operation (see Figure 5).
  • the step 22 for obtaining execution traces is followed by a step 24 of detecting a malfunction, that is to say of non-conformity with a global property P of the system. which applies regardless of the modeling of the behavior of the system.
  • step 26 In case of detection of malfunction in step 24, this step is followed by a step 26 of selecting a subset / components, each having an execution trace including an event not conforming to the model.
  • the subset / ⁇ ' 1 .., ⁇ ⁇ ⁇ has R indices, R> 1, and R ⁇ N, where N is the total number of components of the system S observed.
  • the subset / of components is the subset whose necessary and / or sufficient causality with respect to the observed dysfunction is tested, and is called subset of tested components.
  • the method analyzes the joint causality of the subset / tested components. It should be noted that the method of the invention is theoretically applicable with a subset / of components having no nonconformity in the execution trace, but such a case is of no interest in practice. Indeed, the method aims to determine which of the components of the studied system is the cause of the observed dysfunction.
  • the invention makes it possible to determine, by testing several subsets of components /, accurately, the components whose malfunction is necessary and / or sufficient to find the overall malfunction of the system with respect to the property P.
  • Fig. 7 illustrates an embodiment of the necessary causality determination step of the subset / components.
  • the method illustrated schematically in FIG. 7 is implemented by a programmable device such as a computer, notably comprising a programmable circuit or a processor able to execute control program instructions when the device is powered up and storage means information, able to store executable code instructions allowing the implementation of programs capable of implementing the method according to the invention.
  • a programmable device such as a computer, notably comprising a programmable circuit or a processor able to execute control program instructions when the device is powered up and storage means information, able to store executable code instructions allowing the implementation of programs capable of implementing the method according to the invention.
  • a truncated execution log is obtained.
  • steps 32 to 40 apply to this subset of components, as explained below.
  • the execution trace tr. is truncated to retain only the prefix tr. conform to the Qk component model.
  • the prefix comprises the sequence of events tr t above the non-conforming to the detected event model, also called error relative to the performance of the component concerned.
  • Figure 8 illustrates the truncated execution log, shown in a table T, for the developed example and for the subset / including the Supervisor component.
  • the tr'_S prefix comprises only the first three elements of the tr_S execution trace for the Supervisor component, and the tr'_P and tr'_E traces / prefixes are unchanged for both. other components.
  • an extension model is determined, making it possible to generate all the execution traces comprising the prefix tr) and conform to the model of the component Ci.
  • T (tr) an LTS model making it possible to generate exactly the trace tr, called the generator model of tr.
  • the generator model T (tr) is defined as follows:
  • T (tr) ( ⁇ q 0 , ..., q k ⁇ , ⁇ a,, ..., a k q 0 )
  • T (tr ') (Q', ⁇ ', ⁇ ', q 0 ).
  • the trace extension model tr is obtained by composition of the generator model T (tr p ) of the prefix tr p of the trace tr, corresponding to the trace tr without its last event a k and of the set of conformal transitions to model B making it possible to pass from the state q k _ x of the generating model T (tr p ) to a state q of model B.
  • B the behavioral model of the component of index i
  • S its model of good functioning (thus, the behaviors of S, are included in those represented by B,).
  • the extension model M (tr p ) of tr is calculated as Refine_Si (tr p ) when tr p is according to S,; M (tr p ) is calculated as Refine_Bi (tr p ) when tr p is not consistent and a behavioral model B is available; M (tr p ) is calculated as T (tr p ) when tr is not compliant and no behavioral model of component i is known.
  • the obtaining of the trace extension model applies regardless of the modeling of the behavior of the system.
  • an extension model. (.) is obtained for each prefix of the truncated execution log.
  • Figure 9 illustrates the extension templates Ms, MP, ME obtained from the prefixes of the truncated execution log illustrated in Figure 8.
  • the extension models are in fact the generator models of the respective tr'_P and tr'_E traces.
  • the extension model is a combination of the tr'_S trace generator model, deprived of the last transition ⁇ high ⁇ (we note tr'_S ⁇ ⁇ high ⁇ ), and the high transition to the corresponding model Cs shown in FIG.
  • the step 34 of generating extension models is followed by a step 36 of constructing a set of prefixes not affected by the error or the errors of the components of the subset /, denoted ⁇ tr * i ⁇ .
  • this set is performed by truncation of all prefixes ⁇ tr. in step 32 as a function of the combination of extension models calculated in step 34.
  • extension models M ⁇ tr The combination of extension models M ⁇ tr) computed in step 34 provides a model:
  • step 34 Two embodiments are envisaged for step 34.
  • the combination with B is optional.
  • the components are considered in a predetermined order, for example the increasing order of the indices; after obtaining each unassigned prefix its extension model is updated in the composition before calculating the unassigned prefix of the next trace.
  • FIG. 10 illustrates the set T * of unassigned prefixes ⁇ tri ⁇ obtained in the exemplary embodiment, obtained by using the extension models of FIG. 9 according to the first embodiment of step 36 described above. above.
  • the set T * obtained is the set of prefixes of maximum length that could have been observed in the absence of the execution errors of the system S.
  • step 36 of constructing the set of unassigned prefixes is followed by a step 38 of constructing an MC (I) model, called a counterfactual model constructed with respect to the subset of components.
  • the MC (I) model is obtained by composing the extension models of each of the unaffected prefixes (tri), which depend on the respective LTS models of each of the components.
  • B * tr * denotes the corresponding extension model, obtained as explained above in step 34.
  • Counterfactual model MC (I) is the composition of extension models
  • the counterfactual model MC (I) is the composition of the extension models B ⁇ tr * ) without model B of the overall behavior of the system.
  • the counterfactual model MC (I) is a model of the fictitious execution traces, which could have been observed in the absence of errors of the components of the subset / considered.
  • the counterfactual model of the treated subassembly makes it possible to generate all the possible behaviors starting with the unassigned prefixes, in the absence of malfunctions of the components of the subset of components processed.
  • a property P is also represented by an LTS model:
  • the transitions of the observation model include the transitions defined for the model of the property P and the transitions which, accepting an event that does not conform to the property tested, lead to an error state. .
  • the tested model MC (I) satisfies the property P if and only if there is no state egx jl ⁇ such that (q 0 , q °) -> * q where -> * is the transitive closure of -> .
  • the counterfactual model MC (/) satisfies the property P if no sequence of events generated by the model results in the error state _L.
  • step 42 Based on the result of the property satisfaction check step P by the counterfactual model MC (/), a decision on the necessary causality of the subset / component error is returned to step 42, which that is the modeling of the system.
  • Figure 11 illustrates the counterfactual model obtained for the example developed, considering the Supervisor component as a subset of tested components.
  • the counterfactual model is obtained by composing the extension models.
  • the counterfactual model obtained satisfies the property P, which makes it possible to deduce that the error found in the execution trace of the Supervisor component is a necessary cause of the malfunction of the system.
  • Fig. 12 illustrates an embodiment of the sufficient causality determination step of the subset / components.
  • the method illustrated schematically in FIG. 12 is implemented by a programmable device such as a computer, notably comprising a programmable circuit or a processor capable of executing control program instructions when the device is powered up and storage means being used. information, able to store executable code instructions allowing the implementation of programs capable of implementing the method according to the invention.
  • a subset I e comprising the indices of the components of the system S and which are not part of the subset / is determined.
  • steps 52, 54, 56, 58 are analogous to steps 32, 34, 36, 38 previously described, considering the subset I e as a subset of components processed in place of the subset /.
  • the verification step 60 consists of checking whether the counterfactual model MC (/ C ) systematically violates the property P, therefore if all the traces obtained according to this model comprise a chain of events that does not conform to P.
  • step 62 If the counterfactual model MC (/ C ) inevitably violates the property P, it is determined in step 62 that the subset of components / is a sufficient cause of system malfunction.
  • step 62 If at least some of the traces that can be obtained by applying the counterfactual model MC (/ C ) satisfy P, then it is determined in step 62 that the subset of components / is not a sufficient cause of malfunction. of the system.
  • the behavior of the system and its components is modeled by timed automata.
  • the invention applies more generally to any modeling of a system and its components that makes it possible to construct tools for:
  • the invention nonetheless applies to complex systems with multiple components, and makes it possible to automatically and systematically determine the causes of dysfunction that are necessary and / or sufficient in these complex systems.
  • the method can be used in a systematic search for causality, in which all the events or sequences of events that may cause a malfunction among the events observed are analyzed.
  • the method described is implemented for each subset / considered as likely to be a necessary and / or sufficient cause of dysfunction, or for a part of these subsets, and makes it possible to determine in particular the sub-assembly. minimal set of components whose observed behavior is a necessary and / or sufficient cause for the observed dysfunction.

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 œuvre 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 gênerai trace-based framework of logical causality" de G. Gôssler et D. Le Métayer, publié dans FACS- 10th International Symposium on Formai 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 œuvre. 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 œuvre 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 œuvre 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 œuvre 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 œuvre ;
- 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 1 1 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 œuvre 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 œuvre 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 œuvre 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 œuvre 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 œuvre de programmes aptes à mettre en œuvre le procédé selon l'invention.
Pour un système S comportant une pluralité de n composants d'indices i, z' e {l,...,«} , 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,∑,— », q0 ) consiste en un ensemble d'états Q, un alphabet d'événements ∑, une relation de transition notée — » , où ->ç g x∑x g et 0 un état initial. On écrit q→q' pour le triplet (q,a, q') e— > 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. = ((¾ ,∑. ,— > . , °) .
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 II .
On note :
Figure imgf000010_0001
les transitions— » sont définies comme suit :
Figure imgf000010_0002
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é _L .
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 Ql , attend une durée de temporisation (transition t), et retourne dans l'état Q ; 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 QS 3 , suivie d'une transition beat vers l'état Q2 .
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 QS A , suivie d'une transition cool vers l'état Q2 .
Depuis l'état Q2 la transition f effectue la temporisation et le retour à l'état Q 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 Qp l , dans un mode où la température du réacteur augmente. Le composant Plant effectue une transition f vers l'état QP 2 d'où une transition inc, représentant une augmentation de température, permet de repasser au premier état Qp l .
Dans le cas d'une commande cool reçue du composant Supervisor, le composant Plant effectue une transition vers l'état Qp .
Dans l'état Qp , une transition f mène vers l'état Qp , d'où une transition dec permet de repasser à l'état Qp ; ceci modélise une diminution de la température du réacteur à chaque unité de temps.
De l'état Qp , l'état Qp l peut être atteint par une commande beat reçue du composant Supervisor.
Le modèle du composant Env , équipé d'un état noté _L qui modélise une violation de fonctionnement correct, notée _L est illustré à la figure 5.
Le composant Env a six états de bon fonctionnement associés, notés QE l , Q2 ,
Ql Ql Ql Ql
Les états QE l et QE A 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, Tmax] , l'état Q est maintenu par une séquence de transitions med (transmission de la température captée au Supervisor) suivie de f.
Dans le cas où la température diminue, le composant passe à l'état QE 2 par une transition dec. Tant que la température captée est inférieure à Tmin, le composant reste dans les états QE 2 et QE 5 (transitions low ; t).
Si la température augmente, une transition inc vers l'état QE l est appliquée.
Dans le cas où la température captée à l'état QE l augmente, le composant passe de l'état QE l à l'état Q par une transition inc. Tant que la température captée est supérieure à Tmax, le composant reste dans les états Q et QE 6 (transitions high ; t).
Si la température baisse, une transition dec de l'état QE vers l'état QE l est appliquée.
Si la température diminue davantage (transition dec) dans l'état QE 2 ou si la température augmente davantage (transition inc) dans l'état QE , alors le système est en violation d'une propriété de bon fonctionnement et l'état noté _L 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 tn 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é tn.
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,∑,→,q0) , 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 que : ^ , ^ ... ^ qk_y— , les états ql ,...,qk_l e Q . Selon un mode de réalisation, les journaux d'exécution ou traces tn 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 œuvre l'invention.
Selon une variante, les journaux d'exécution ou traces tn 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 tn séparés sont obtenus pour chacun des composants.
Selon une variante possible, les traces d'exécution tn 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 tn 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 f 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 f.
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 f 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 f 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 / de composants, comportant chacun une trace d'exécution comportant un événement non conforme au modèle.
Le sous-ensemble / = {ζ' 1 ..,ζΛ } comporte R indices, R > 1 , et R< 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 œuvre.
Ces étapes peuvent être mises en œuvre 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 œuvre 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 œuvre 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 œuvre de programmes aptes à mettre en œuvre 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.
II 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 i, e l , la trace d'exécution tr. est tronquée pour n'en retenir que le préfixe tr. conforme au modèle du composant Qk. En pratique, le préfixe
Figure imgf000015_0001
comprend la séquence d'événements de trt 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 il e lc , où Ie est le sous-ensemble d'indices complémentaire de sous-ensemble /, les traces d'exécution sont inchangées : tr. = tr. .
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 = αλ · α2 · ...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) = ({q0 ,...,qk }, {a, ,...,ak
Figure imgf000015_0002
q0)
Nous notons M(tr) le modèle d'extension d'une trace tr = ax - a2 ■ ...ak .
Selon un mode de réalisation, le modèle d'extension d'une trace tr = ax - a2 ■ ...ak conforme au modèle LTS B = (Q,∑,→,q0) est défini par le modèle d'extension obtenu à partir du modèle générateur du préfixe tr'= αγ · a2 ■ ...ak_l et du modèle B . On note T(tr') = (Q',∑',→' , q0 ) .
On note le modèle d'extension de la trace tr = ax - a2 - ...ak et du modèle B
Refme_5(» = (Q",∑,→" , q0 ) , avec :
Q"= Q ^ et
Figure imgf000016_0001
Le modèle d'extension de la trace tr = 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_x 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 ) .
Pour certains composants un modèle comportemental, qui représente tous les comportements possibles, corrects et erronés du composant, peut être connu. Soit B, le modèle comportemental du composant d'indice i, et S, son modèle de bon fonctionnement (donc, les comportements de S, sont inclus dans ceux représentés par B,). Selon un autre mode de réalisation que celui présenté ci-dessus, le modèle d'extension M(trp) de tr est calculé comme Refine_Si(trp) lorsque trp est conforme à S, ; M(trp) est calculé comme Refine_Bi(trp) lorsque trp n'est pas conforme et un modèle comportemental B, est disponible ; M(trp) est calculé comme T(trp) lorsque tr n'est pas conforme et aucun modèle comportemental du composant i n'est connu.
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 . ( . ) est obtenu pour chaque préfixe 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.
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 / , notés {tr*i}.
La construction de cet ensemble est réalisée par troncature de tous les préfixes {tr. } 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 M^tr ) calculés à l'étape 34 fournit un modèle :
M = M1(ir1 ')||M2(^)||...||Mil(iri;)
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 = Ι,.,.,η .
On obtient tr* comme préfixe le plus long de tr. qui peut être produit par M^tr ) dans la composition :
Figure imgf000017_0001
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 {tri} 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(I) , appelé modèle contrefactuel construit par rapport au sous-ensemble de composants /. 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 B^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
Β; (ί ) avec le modèle B de comportement global du système : MC(I) = B^tr' ^tr^.^^
En variante, le modèle contrefactuel MC(I) est la composition des modèles d'extension B^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 ,∑,→p , qp° )
On construit un modèle d'observation de la propriété P, noté O(P) :
0(P) = (Qp v {±},∑,→' p ,qp° )
Avec (q, a, e Q :— (q→q')
Figure imgf000019_0001
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(I) satisfait la propriété P si et seulement si il n'existe pas d'état e g x jl} tel que (q0 , q ° )— > *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 _L .
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 _L 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 1 1 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 œuvre 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 œuvre de programmes aptes à mettre en œuvre 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 Ie 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 Ie comme sous-ensemble de composants traité à la place du sous-ensemble /.
A l'issue de ces étapes, un modèle contrefactuel MC(/C) est obtenu.
L'étape de vérification 60 consiste à vérifier si le modèle contrefactuel MC(/C) 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 œuvre 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(/C) 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(/C) 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 G donnés, C Q . c, 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 œuvre pour chaque sous- 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é.

Claims

REVENDICATIONS
'\ - 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 œuvre 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é (/, Ie) 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é (I) ;
-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.- 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. - Procédé selon la revendication 2, caractérisé en ce que ladite étape de calcul d'un modèle d'extension permettant de générer ledit préfixe de trace d'exécution dépend de la correspondance entre ledit préfixe de trace d'exécution et une spécification de bon fonctionnement du composant correspondant, et/ou d'un modèle comportemental du composant correspondant.
4. - Procédé selon la revendication 2 ou 3, 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.
5. - Procédé selon la revendication 4, 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.
6. - Procédé selon l'une quelconque des revendications 1 à 5, 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.
7. - Procédé selon l'une quelconque des revendications 1 à 5, 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 (/c) 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.
8.- 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és 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é (/, Ie) 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é (I) ;
-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é.
9.- Produit programme d'ordinateur comportant des instructions pour mettre en œuvre 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 à 7 lors de l'exécution du programme par un processeur ou un circuit programmable d'un dispositif programmable.
PCT/FR2015/052124 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 WO2016016587A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
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
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

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1457464 2014-07-31
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 (1)

Publication Number Publication Date
WO2016016587A1 true WO2016016587A1 (fr) 2016-02-04

Family

ID=52450248

Family Applications (1)

Application Number Title Priority Date Filing Date
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

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
US8001527B1 (en) * 2004-12-21 2011-08-16 Zenprise, Inc. Automated root cause analysis of problems associated with software application deployments
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 (3)

* Cited by examiner, † Cited by third party
Title
G. GÔSSLER; D. LE MÉTAYER: "A general trace-based framework of logical causality", FACS- 10TH INTERNATIONAL SYMPOSIUM ON FORMAL ASPECTS OF COMPONENT SOFTWARE, 2013
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
FR3024567A1 (fr) 2016-02-05
US20170308424A1 (en) 2017-10-26
US10437656B2 (en) 2019-10-08
FR3024567B1 (fr) 2016-09-02
EP3175363A1 (fr) 2017-06-07

Similar Documents

Publication Publication Date Title
EP3123139B1 (fr) Procédé d&#39;estimation du caractère normal ou non d&#39;une valeur mesurée d&#39;un paramètre physique d&#39;un moteur d&#39;aéronef
EP3126659B1 (fr) Procédé et dispositif de surveillance d&#39;un paramètre d&#39;un moteur de fusée
FR3016218A1 (fr) Procede, dispositif et systeme d&#39;estimation de l&#39;etat de sante d&#39;une batterie d&#39;un vehicule electrique ou hybride en condition d&#39;utilisation, et procede de construction d&#39;un modele pour une telle estimation
EP3665490A1 (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
EP3559767B1 (fr) Procédé de caractérisation d&#39;une ou plusieurs défaillances d&#39;un système
WO2017077247A1 (fr) Système et procédé de surveillance d&#39;une turbomachine avec fusion d&#39;indicateurs pour la synthèse d&#39;une confirmation d&#39;alarme
FR3035232A1 (fr) Systeme de surveillance de l&#39;etat de sante d&#39;un moteur et procede de configuration associe
WO2016016587A1 (fr) Procédé de détermination automatique de causes de dysfonctionnement d&#39;un système composé d&#39;une pluralité de composants matériels ou logiciels
WO2011117528A1 (fr) Procede, programme d&#39;ordinateur et dispositif de validation d&#39;execution de taches dans des systemes informatiques evolutifs
EP2677454B1 (fr) Calculateur, ensemble de communication comportant un tel calculateur, système de gestion ferroviaire comportant un tel ensemble, et procédé de fiabilisation de données dans un calculateur
CA2837523A1 (fr) Systeme de prescription de maintenance d&#39;un moteur d&#39;helicoptere
FR2997774A1 (fr) Procede, dispositif et programme d&#39;ordinateur de placement de taches dans un systeme multi-cœurs
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
FR3099830A1 (fr) Procédé et système de surveillance d’un réseau de câbles, par analyse en composantes principales
FR3003663A1 (fr) Procede de determination automatique de causes de dysfonctionnement d&#39;un systeme compose d&#39;une pluralite de composants materiels ou logiciels
FR2944117A1 (fr) Procedes et dispositifs de gestion d&#39;evenements lies a la securite des systemes informatiques d&#39;aeronefs
WO2019034497A1 (fr) Procede, mis en oeuvre par ordinateur, de reconstruction de la topologie d&#39;un reseau de cables
EP3265915B1 (fr) Dispositif de simulation
EP2686768B1 (fr) Dispositif et méthode de filtrage de maintien sur un flux d&#39;entrées/sorties codé
FR3025889A1 (fr) Gestion de la recharge de la batterie d&#39;un vehicule electrique
WO2017108924A1 (fr) Procédé de détection de problèmes de testabilité d&#39;un module informatique
EP4379486A1 (fr) Procédé de maintenance prédictive frugale, produit programme d&#39;ordinateur et support lisible par ordinateur correspondants
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é
WO2023144488A1 (fr) Procede de controle d&#39;un systeme comportant un post-traitement d&#39;une commande predictive

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 15753735

Country of ref document: EP

Kind code of ref document: A1

REEP Request for entry into the european phase

Ref document number: 2015753735

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 15500791

Country of ref document: US