A simple centralised diagnosis problem from A to Z

Yannick Pencolé

This tutorial illustrates the way to generate a diagnosis problem and to solve it. Please notice that this document is just a draft but it contains all the required information.

1  Model generation

First, in order to generate the diagnosis problem, a random model is generated with help of the command dd-des-generate.

Usage:  dd-des-generate
  --help |
  [--topo topologyFileName.topo]
  [--seed randomSeed]
  [--evtMin nbEvtMin]
  [--evtMax    nbEvtMax]
  [--obsMin nbObsMin]
  [--obsMax    nbObsMax]
  [--stateMin  nbStateMin]
  [--stateMax  nbStateMax]
  [--latex  latexFileName]
  [--outputdir dirName]
  [--obsInteractionMin nbObsIntMin]
  [--obsInteractionMax nbObsIntMax]
  [--nodeBehaviour node=file.descomp ci=ej ck=el ...]]
  [--outputDegreeMax outDeg]

The command dd-des-generate randomly generates a distributed discrete-event system that has the topology defined in the file topologyFileName.topo. The generator uses a random generator of number that can be initialised with the seed randomSeed. If not provided, the seed is the starting time of each run of the program. As far as the behaviour of a component is concerned, the number of generated states is between nbStateMin and nbStateMax. The number of event is between nbEvtMin and nbEvtMax as long as it is compatible with the topology. The number of observable events is between nbObsMin and nbObsMax. The generated model consists of a set of files written in the directory dirName. The model generator also generates a document in latex format for documentation purposes (if the option is set). The parameters --obsInteractionMin and --obsInteractionMax states the possible numbers of observable interactions. The --nodeBehaviour parameters states that one (and only one) of the node called node has the predefined behaviour described in file.descomp. Constraints like ci=sj assert that the component ’node’ implements the connection ci of the topology with the iteractive event sj. The option --outputDegreeMax rules the maximal number of transitions (i.e. events) that are the output of one state.

In this tutorial, the generated model is monolithic (no topology provided):

dd-des-generate --evtMin 400 --evtMax 400 --obsMin 350 --obsMax 350 --stateMin 3000 --stateMax 3000 --outputDegreeMax 3

In this example, the system contains 3000 states and 400 event types. Among the 400 events, 350 are observable. Each state maximally contains between 1 and 3 output transitions. It creates a file n0.des_comp in the default directory model_generator_directory. To get information about the generated model you can run dd-component-info as follows:

2  Problem generation

Once the model has been defined, it is necessary to define a scenario, that is a set of faults and a sequence of observations: this is the role of dd-simulate.

Usage:  dd-simulate
  --help |
  model1.des_comp [model2.des_comp ... sync.rules]
  [--seed randomSeed]
  [--noevent e3 e4 ....]
  [--obsMin nbObsMin]
  [--obsMax nbObsMax]
  [--timeMin minSeconds]
  [--timeMax maxSeconds]
  [--generateFaults]
  [--xml simulation.xml]

The command dd-simulate writes an observable scenario on the standard output based on the model that contains at least one occurrence of the event e1, e2 and that does not contain the events e3 e4. The generated scenario contains [nbObsMin,nbObsMax] observations. If set, the delay between two event occurrences is in [minSeconds,maxSeconds]. Optionally, a xml file can be generated with option --xml. The option --generateFaults randomly selects unobservable events in the model that will be considered as fault in the generated scenario.

In this tutorial, the generated scenario contains exactly 1000 observations.

dd-simulate n0.des_comp --obsMin 1000 --obsMax 1000 --generateFaults --xml scenario.xml

The file scenario.xml contains two parts: one is the effective scenario that was generated by simulation on the model n0.des_comp (that is the sequence of events, observable and not observable). The second part is the observable projection of the previous sequence which thus corresponds to the sequence of observation to diagnose. With the option --generateFaults, dd-simulate suggested in this example that only n0.e162 n0.e358 n0.e115 n0.e30 n0.e236 n0.e277 n0.e123 are faulty events in this diagnostic problem.

3  Diagnosis Problem Solving

To summarize this tutorial, the file n0.des_comp contains the behavioural description of a discrete-event system. With help of dd-simulate, the set of faults is also set up (that is here n0.e162 n0.e358 n0.e115 n0.e30 n0.e236 n0.e277 n0.e123) as well as the sequence of observations to diagnose (contained in scenario.xml). After these two previous steps, a diagnosis problem is fully (randomly) defined and can now be solved. The command dd-diagnose will now solve the problem.

Usage:  dd-diagnose --help
  diagnose [--statistics]  [--faults evt1 evt2]  file1.des_comp file2.des_comp  [file3.des_comp...] sync.rules scenario.xml
  diagnose [--statistics]  [--faults evt1 evt2]  file1.des_comp  scenario.xml
  diagnose [--statistics]  [--faults evt1 evt2]  file.des_comp file.abstraction scenario.xml
  diagnose [--statistics]  [--faults evt1 evt2]  file.diagnoser scenario.xml

dd-diagnose diagnoses the sequence of observations given in the scenarios. Print on the standard output the final diagnosis. The events listed after the --faults option are considered as faults. If the input models are a set of models, dd-diagnose uses a component-based algorithm. If the input model is a global one, dd-diagnose uses a global model algorithm. If the input model is a diagnoser, dd-diagnose uses a diagnoser algorithm. The option --statistics write some statistics in a file output.statistics (not complete yet).

In this tutorial, the running algorithm is the centralised one that only involves a component and a scenario.

./dd-diagnose --faults n0.e162 n0.e358 n0.e115 n0.e30 n0.e236 n0.e277 n0.e123 n0.des_comp scenario.xml

In this example, output.statistics contains:

/* Result are in microseconds */
Mean time:8.56
Max  time:22
Min  time:6
Variance: 6.6264

The meaning of this output depends on the type of algorithm. This one diagnoses the sequence one observation after another in the order of the sequence. The min/max time is the minimal/maximal time to provide a diagnosis update after each observation. In this example, as the sequence of observations is 1000 it means that the overall process took less than 22 * 1000 = 2.2 seconds.

Finally the result for this problem is output as follows:

Final Diagnosis:
Candidates: { [ (1268,{ n0.e115 n0.e30 }) ] [ (1697,{ n0.e115 n0.e30 }) ] [ (2683,{ n0.e115 n0.e30 }) ] }
Underlying belief state:{ 2683 } { 1268 } { 1697 } 
Fault candidates: { { n0.e115 n0.e30 } }

Got the full story? Try and enjoy yourself.

This document was translated from LATEX by HEVEA.