Diagnosis

This plug-in concerns the failure diagnosis for discrete event systems, where failures are either modelled as unobservable failure events that correspond to an undesired system behaviour or by a language specification that characterizes the correct system behavior.
The functionality of the plug-in comprises two main tasks. On the one hand, it is verified if a given system is diagnosabie, i.e., each considered failure can be determined after the occurrence of a finite number of events. On the other hand, diagnoser automata are designed in order to monitor the on-line behaviour and to detect or estimate the occurrence of failures.

Part of the diagnosis plug-in was developed in the scope of Tobias Barthel's diploma thesis. The thesis discusses known methods for event-diagnosis and languaga-diagnosis from the literature [D1,D2,D3,D4,D5,D6] as well as extentions for modular diagnosis. The user reference is organized as follows:


Copyright (c) 2009, Tobias Barthel.
Copyright (c) 2009, Klaus Schmidt, Thomas Moor.

Example

We illustrate the overall design of a monolithic diagnoser by the "very simple machine" example from the Synthesis reference. However, we extend the nominal behaviour by considering a possible failure when the machine is busy. The failure shows in an erroneous beta event that may occur even if the machine did not finish to process the work-piece. We model this failure by an unobservable event f followed by the erroneous sensor reading beta event.

Very Simple Machine G with unobservable failure f

The interpretation of the event f as a failure event is encoded the following FailureTypeMap. It defines the failure-type F to be associated with the occurence of event f: 

<FailureTypes>
"F"          
<FailureEvents>"f"</FailureEvents>
</FailureTypes>

With the above input data, the function EventDiagnoser is used to synthesise a Diagnoser:

Diagnoser for the very simple machine with failure type F

Each diagnoser state has an attribute attached that summarizes diagnosic information for the original system G. The initial state 1N indicates that G is in state 1 and that no failure occured so far. After the first occurrence of beta, the diagnoser takes the transition to the ambiguous state 1N 2F. Now, G could be in state 1 with no failure occurred (1N) or it could be in state 2 after the occurrence of the failure type F, indicated 2F. Only when beta occured twice in a row, the failure can be unambiguously detected. Since in the presence of the failure the second beta must indeed occur, the system is diagnosable.

Literature

[D1] M. Sampath, R. Sengupta, S. Lafortune, K. Sinnamohideen, and D. Teneketzis : Diagnosability of discrete-event systems , IEEE Transactions on Automatic Control, 40(9):1555-1575 , Sep. 1995 .

[D2] S. Jiang, Z. Huang, V. Chandra, and R. Kumar : A polynomial algorithm for testing diagnosability of discrete-event systems , IEEE Transactions on Automatic Control, 46(8):1318-1321, Aug. 2001 .

[D3] W. Qui and and R. Kumar : Decentralized failure diagnosis of discrete event systems , IEEE Transactions on Systems, men and cybernetics. Part A: Systems and Humans, 36(2):384-395 , Mar. 2006 .

[D4] C. Zhou, R. Kumar, R. Sreenivas : Decentralized modular diagnosis of concurrent discrete event systems , International Workshop on Discrete Event Systems pp. 388-393 , May 2008 .

[D5] T.-S. Yoo, H. E. Garcia : Diagnosis of behaviors of interest in partially observed discrete-event systems , System & Control Letters, 57(12):1023-1029 , Dec. 2008 .

[D6] O. Contant, S. Lafortune and D. Teneketzis : Diagnosability of Discrete Event Systems with Modular Structure , Discrete Event Dynamic Systems, 16(1):9-37 , Jan. 2006 .

libFAUDES 2.32b --- 2024.03.01 --- with "synthesis-observer-observability-diagnosis-hiosys-iosystem-multitasking-coordinationcontrol-timed-simulator-iodevice-luabindings-hybrid-example-pybindings"

>>