libFAUDES

Sections

Types

Functions

Diagnosis PlugIn

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 ComputeDiagnoser 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, March 2006.

[D4] C. Zhou, R. Kumar, R. Sreenivas, Decentralized modular diagnosis of concurrent discrete event systems, Discrete Event Systems, International Workshop on, 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, December 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, January 2006.

libFAUDES 2.14g --- 2009-12-3 --- plugins "example synthesis observer diagnosis hiosys multitasking timed simulator iodevice luabindings"