Modular Modeling for the Diagnostic of Complex Discrete-Event Systems

IEEE TRANSACTIONS ON AUTOMATION SCIENCE AND ENGINEERING, VOL. 10, NO. 4, OCTOBER 2013 1101

Modular Modeling for the Diagnostic of ComplexDiscrete-Event Systems

Eric Gascard and Zineb Simeu-Abazi

Abstract—For the complex systems, the development of amethodology of fault diagnosis is important. Indeed, for suchsystems, an efficient diagnosis contributes to the improvementof the availability, the growth of production, and, of course, thereduction of maintenance costs. It is a key action in the improve-ment of performance of industrial feature. This paper proposesa new approach to diagnose complex systems modeled by com-municating timed automata. Each component has been modeledseparately by a timed automaton integrating various operatingmodes while the communication between the various componentsis carried out by the control module. Starting from each moduleof the complex system, a single deterministic automaton, calleda diagnoser, is constructed that uses observable events to detectthe occurrence of a failure. This modeling formalism providesmeans for formal verification of the complex system model andits diagnoser. The model-checking methods are used to checkcorrectness properties. The steps of the method are describedby an algorithm and illustrated through a batch neutralizationprocess. The implementation of the algorithm is also discussed.

Note to Practitioners—Since the 1990s, fault detection and diag-nosis of discrete-event systems have been widely studied. The evo-lution of the studied systems which become increasingly complexrequires new and adapted diagnostic methods. Moreover, the ma-jority of works do not take into account the temporal evolutionthrough the dynamics of the failure. This paper proposes amethod-ology for building automatic diagnosers of timed discrete-eventsystems. Our framework can be applied efficiently for diagnosis oflarge manufactured systems. Indeed, building by hand diagnosersfor such systems is difficult and error-prone. We use a modularmodeling and consider only permanent fault models for actuatorsand sensors and only the plant model is a timed automaton. Theserestrictions limit the application domain of our method, but oursolution proposes a general model capturing the independent andinteractive behaviors of these modules by modeling them as com-municating timed automata using the model-checking tool Uppaal,which enables us to perform formal verification of the built diag-noser. The generation of the diagnoser is made offline and is com-posed of two steps. The first step consists of building a part of theproduct of the different modules and the second step consists ofdetermining the obtained product. The algorithm is described andimplemented in a tool.

Index Terms—Diagnosers, discrete-event systems, fault detec-tion, fault diagnosis, modular modeling, software implementation,timed automaton.

Manuscript received June 29, 2012; revised September 27, 2012; acceptedNovember 06, 2012. Date of publication January 21, 2013; date of current ver-sion October 02, 2013. This paper was recommended for publication by Asso-ciate Editor M. Dotoli and Editor M. Zhou upon evaluation of the reviewers’comments.E. Gascard is with the TIMA Laboratory (CNRS-Grenoble INP-UJF), 38031

Grenoble, France (e-mail: [email protected]).Z. Simeu-Abazi is with the G-SCOP Laboratory (CNRS-Grenoble INP-UJF),

38031 Grenoble, France (e-mail: [email protected]).Digital Object Identifier 10.1109/TASE.2012.2229707

I. INTRODUCTION

T HE development of a fault diagnosis system is of prin-cipal importance for the complex systems. Indeed, for

such systems, the diagnosis plays a crucial role in maintainingthe safety and reliability. Moreover, it contributes to improvedsystem availability, the growth of production, and, of course, thereduction of maintenance costs. A good fault diagnosis systemmust be able to detect and isolate the faults with a desired per-formance level in terms of speed of detection and precision inthe localization.The problem of fault diagnosis has been extensively studied,

and a wide variety of methods have been developed. In additionto model-free methods, which do not use any explicit model ofthe system but rely only on the system variable measurements,different model-based schemes and methods for fault diagnosishave been developed in the last two decades. Among the variousmodel-based approaches one can find: 1) fault-tree analysis; 2)analytical redundancy methods; 3) expert systems and other ar-tificial intelligence model-based reasoning methods; and 4) dis-crete-event systems methods.The fault-tree analysis is a method usually used by reliability

engineers [1]. A fault-tree supplies a graphical representationof a cause–effect relationship of faults in a system. Fault-treeanalysis has several drawbacks, particularly in incorporating in-formation about ordering and timing of events in a fault-tree. Totake into account sequential relationships among events, the dy-namic fault-tree (DFT) model has been proposed [2]. There ex-ists some extension of the DFT by adding temporal dependencebetween events, e.g., [3]–[5].The quantitative methods used for continuous systems such

as the analytical redundancy methods, are based on residuals.Residuals describe inconsistencies responses between the actualsystem behavior and the model; see [6] and references thereinfor a survey. This methodology is widely used in the controlsystem community.Expert systems and artificial intelligence model-based rea-

soning approaches [7] are used for systems that are difficult tomodel. They use the experience and knowledge of domain ex-perts (stored as a set of rules) and an inference engine to diag-nose failure.For the last two decades, the model-based approaches are

being extended to dynamical systems that are based on a dis-crete-event system (DES) modeling formalism (e.g., automataor Petri nets). For complex systems, the concept of modular de-composition into subsystems/components can be applied witha centralized control. The modular conception allows a simplerrepresentation of the system and avoids the exponential growth

1545-5955 © 2013 IEEE

1102 IEEE TRANSACTIONS ON AUTOMATION SCIENCE AND ENGINEERING, VOL. 10, NO. 4, OCTOBER 2013

in the number of states [8]. Diagnosis of DESs uses the observ-able inputs and outputs of the system under supervision to de-tect the fault and isolate (locate, distinguish) the source of failureusing diagnosers. The diagnoser is a finite-state machine (FSM)built from the FSM model of the system. The diagnoser per-forms diagnostics when it observes the behavior of the system.Diagnosers can be used to perform online the monitoring anddiagnosis (called online passive diagnosis [9]) of the DES or toanalyze offline the stream of alarms. There exists another usageof diagnosers such as online active diagnosis. In online activediagnosis, input test sequences for fault diagnosis are computed,so that the diagnoser may influence the choice of inputs, see,e.g., [10].The diagnoser building can be performed online or offline.

In the first approach, online, an algorithm called interpreted di-agnoser in [11] computes directly the diagnosis from the be-havioral model of the system by simulating possible trajectories(see, e.g., [11]–[16]). The size of the diagnoser is reasonable dueto the on-the-fly computation [12], but not always applicable forall real-time systems due to considerable online computationsand communication requirements.In the second approach, offline, the compiled diagnoser is

built from the system model. However, the size of the diagnosercan be so large that they are not computable for all applications.To consider this problem, several structures of DES diagnosishave been developed: 1) centralized; 2) decentralized; and 3)distributed.The centralized approach (e.g., [9], [10], [17], and [18])

requires the construction of a global model of the systemfunction as well as a global diagnoser. The global model is builtusing a composition operation on subsystems. These relatedworks use finite automata (FA) for modeling DESs. The use ofFA is limited: its main drawback is that constructing a globalmodel is often intractable because of the complexity and theexponential state growth in complex systems. Schmidt in [19]introduced the idea of abstraction-based diagnosability forlarge complex systems in order to avoid the enumeration of theoverall system state space. However, this work concerns onlythe diagnosability verification of DESs [17], so the constructionof the associated diagnoser is not considered. In order to copewith the state explosion problem during the construction ofthe diagnoser, Petri nets were used as a modeling formalismfor DESs. Ushio et al. [20] have adapted the fault diagnosismethod given by Sampath et al. for unbounded Petri net-basedmodels. A coverability tree, similar to a diagnoser, is used forfailure diagnosis. The coverability tree is an approximation forthe reachability set. Chung et al. [21] extend Ushio’s conceptby marking some transitions to be observable. However in[20], [21], the reachability graph of the Petri nets must be com-puted for analyzing the diagnosability property of the system.Cabasino et al. (see [22] and references therein) improve theconstruction of a diagnoser for Petri nets by using the notion ofbasis markings and justifications. These concepts allow themto represent the reachability space in a compact manner.The decentralized and distributed approaches require the con-

struction of a local diagnoser at each component. Each local di-agnoser has a partial observation of the whole system to be di-agnosed. In the distributed diagnosis approach (e.g., [23]–[26]),

the local diagnosers communicate with each other. In a decen-tralized diagnosis architecture (e.g., [27]–[30]), each local diag-noser makes local diagnoses without communicating with theother local diagnosers. The local diagnoses made by the variouslocal diagnosers may (e.g., [27]) or may not (e.g., [28]–[30]) befused in order to issue a global diagnosis. The fusion can be re-alized by a coordinator.The above cited works explore diagnosis of untimed discrete-

event systems. However, the correctness of complex systems(such as nuclear power plants, avionics systems, and manufac-turing systems) depends not only on the correct logical resultsof the system behavior, but also on the time at which the resultsare produced. Thus, the fault detection and diagnosis of suchcomplex systems has been studied using timed discrete eventsystem (TDES) [31] models. The task of diagnosis of TDESshas been receiving increasing interest [24], [32]–[42].The problem considered here is that of diagnosing manu-

facturing plants by model-based diagnosis methods in the con-text of TDESs. This work is a continuation of research initiatedby Simeu-Abazi et al. in [44]–[46]: our contribution presentsa methodology for the representation and diagnosis of manu-facturing plants modeled as a network of communicating timedautomata (CTA [47]). We give algorithms for building automat-ically diagnosers of such timed discrete-event systems. The ap-proach we have used for diagnosis is based on the methodologyproposed in [17] and [18] known as the diagnoser approach.In our method, the construction of the diagnoser is made offline,and we perform online passive diagnosis. Our diagnosis methodhandles large and complex systems whose diagnoser construc-tion is difficult due to a great number of states and variablesmanipulated. This problem requires to use a modular decompo-sition of the system and to develop ad hoc algorithms to providein an automatic way the model of the diagnoser. Furthermore,to address the issue of state explosion, our approach does notexplore the whole global model: we keep only states that arerelevant to the diagnosis.This paper is structured as follows. The main ideas of our

approach are presented in Section II. Section III presents therelated works, in particular, the framework of diagnosers of[17] and [18] which has inspired our own work. The differ-ences between the proposed method and the existing ones arediscussed in this section. The timed automata with the neces-sary notation are presented in Section IV. In Sections V and VI,the diagnoser construction procedure is presented step by step.The correctness of the diagnoser is explained in Section VII. InSections VIII and IX, the implementation and two realistic casestudies are presented to illustrate our tool. Section X concludesthe paper.

II. PROPOSAL OF A NEW METHOD FOR DIAGNOSIS OF TIMEDSYSTEMS BASED ON MODULAR MODELING

This paper proposes a model-based approach for fault detec-tion and isolation of TDESs composed of a controller, a plant,actuators, and sensors. Actuators and sensors are subject to fail-ures . Batch processes are used in this paper in order to ex-plain our modular modeling methodology and our diagnoser

GASCARD AND SIMEU-ABAZI: MODULAR MODELING FOR THE DIAGNOSTIC OF COMPLEX DISCRETE-EVENT SYSTEMS 1103

Fig. 1. Diagnosis of manufacturing systems.

construction method. Our method proposes online passive di-agnosis; the interactions between components can be describedby Fig. 1.The event set is partitioned into observable events (e.g.,

sensor readings, changes in sensor readings, and commandsissued by the controller to the actuators) and unobservableevents, i.e., the events that are not directly recorded by the sen-sors attached to the system. Thus, the unobservable events areactuator readings modifying the plant behavior and commandsissued by the plant behavior to the sensors. The diagnoser hasaccess to observable events.We consider multiple failure scenarios and assume that faults

for actuators and sensors are permanent. We use the state-basedapproach formulated by [9] and [10]: with this approach, it isassumed that the state set of the system can be partitioned ac-cording to the condition of the system, which is failure status.The failure status of actuators are represented with unmeasur-able variables. Our method is effective in diagnosis multiplefaults.To model the dynamic behavior (timing constraints) of the

plant, this one is defined as a timed automaton. The othercomponents, controller, actuators, and sensors, may be rep-resented by untimed automata since their behaviors are notrelated to some time constraints. We add a supplementaryassumption: the timed guards involved in the plant’s behaviorare exclusively equality tests. Certainly, this restriction in thetiming constraints allowed in guards limits the applicationdomain of our method, but we propose in this paper a completespecification methodology of the TDES considered by our ap-proach (Section V), algorithms for the automatic constructionof diagnosers (Section VI) and as well their implementations(Section VIII).The modeling methodology chosen is based on the commu-

nicating timed automata formalism [47]. The actions performedby the controller on the actuators and the reactions of the sen-sors to the dynamic behavior of the plant are modeled by syn-chronous communication through channels. Indeed control sys-tems traditionally use dedicated, point-to-point wired commu-nication links to measurement sensors and control actuators inregulating the plant behavior, so the assumptions for controlledsystems are ideal communication channels with flawless andsynchronous communication.Our approach, described in Fig. 2 and based on two steps,

provides the user with a diagnoser of their system composed of a

Fig. 2. Principle of the diagnoser construction.

controller , a plant to be controlled, actuators ,and sensors .The first step is the automatic construction of a timed au-

tomaton, named draft diagnoser , described here.1a) We simulate the synchronous composition

to obtain a timedautomaton called partial global model. We explore thestate space of the model in a step-by-step fashion. We usethe synchronous composition of two automata

and in the usual way [31]. Due to our modelingmethodology (see Section V), during the simulation ofthe composition of automata, it may be possible thatseveral transitions can be fired simultaneously. Thesesituations come from:— first case: during a synchronization controller/actuator(respectively plant/sensor). The actuator (respectively,the sensor) proposes two available transitions: oneending in a normal state, the other ending in a faultystate. We keep these choices in our exploration.

— second case: without a synchronization. The availabletransitions come from:• the controller: the transition is composed by an un-timed guard on the status of the sensors;

• the plant: the transition is composed by an untimedguard on the status of the actuators.

In this situation, we do not explore the whole globalmodel: we choose only the controller’s transition. In-deed, the plant status is determined by the controller’s


actions. It is useless to add some states that cannot bereached. We say that we give greater priority to con-troller transitions. This regulation in the exploration ofthe global model allows us to manage partially the stateexplosion problem caused by parallel composition ofautomata.

Thus, each state of the partial global model correspondsto a vector where eachelement is a state of a component.

1b) Definition of the draft diagnoser: We keep the locationsof the partial global model computed previously, but wedelimit the transition’s labels to observable events. Thetransitions considered may be one of the following:— Synchronization controller/actuator: it is expressedas a transition composed by an untimed guard of theform , where isa variable memorizing the synchronization betweenthe controller and the actuator. We do not mentionthe unobservable status of the actuator. As we haveexplained below, there exist two available transitionslabeled by the same command performed by the con-troller on an actuator with faulty state (one ending in anormal state, the other ending in a faulty state). Thus,our computed automaton holds some nondeterministicuntimed transitions.

— Synchronization plant/sensor: it is expressed as a tran-sition composed by a timed guard of the form

where is a clock thatserves as a timer to trigger the synchronization be-tween the plant and a sensor. The clock constraint ex-presses the dynamic behavior of the plant. The vari-able reflects the status of the sensor; is the af-fected value during the sensor’s transition. These timedguards involve exclusively equality tests, so our com-puted automaton holds some deterministic timed tran-sitions (as defined in [48], “given an extended state andthe next input symbol along with its time of occurrence,the extended state after the next transition should beuniquely determined.”).

— Elementary controller transition: it is expressed as atransition composed by an untimed guard on the statusof the sensors. It is a deterministic untimed transition.

— Elementary plant transition: it is expressed as a timedguard of the form . This clock is used duringthe synchronization Plant/Sensor aforementioned. It isa deterministic timed transition.

Our draft diagnoser formed by steps 1a) and 1b) is com-posed of different type of transitions:• nondeterministic untimed transitions (due to the synchro-nization controller/actuator);

• deterministic untimed transitions (controller transitions in-volving a guard on the status of the sensors);

• deterministic timed transitions (synchronizationPlant/Sensor or elementary plant transition).

The second step is the construction of the diagnoser fromthe previous timed automaton . The diagnoser must be a de-terministic timed automaton. For this task, we need to “deter-minize” our draft diagnoser and construct if necessary new tran-

Fig. 3. Simple tank instrumentation (Example 1).

sitions for the faults isolation. The step of determinization con-cerns only nondeterministic untimed transitions, so the deter-minization is possible. In general, timed automata cannot be de-terminized [48].For the validation of the proposed method, Uppaal notation

[49] is used to illustrate communicating timed automata (CTA),knowing that our models can easily be adapted to other timedautomata tools.Timed automata (TA) are automata enriched with a set of

clock variables (declared with clock key word) that rangeover the domain of positive real numbers. All of the clocksprogress synchronously. Uppaal language extends the TAtheory by additional features and some particular notations.First, Uppaal uses communication channels denoted by thename of the synchronized actions to express synchronization.For instance, and are respectively emitted and receivedsynchronization actions on a channel . Channel is declaredas chan a. Second, Uppaal provides bounded integer vari-ables. These variables are used as in programming languages.They are read, written and are subject to common arithmeticoperations. Integer variables may be initialized during theirdeclarations, e.g., .An Uppaal model consists of a network of extended TA. Au-

tomata may communicate either via integer variables (whichin Uppaal are global) or using communication channels. Thetransitions of the automata are annotated with three types oflabels: a guard, expressing a condition on the values of clocksand integer variables that must be satisfied in order for thetransition to be taken; a synchronization action which is per-formed when the transitions are taken, and finally a numberof clock resets and assignments to integer variables denotedupdates. All three types of labels are optional. In addition, thelocations of a timed automaton may include invariants, i.e.constraints on the clock values, which influence the behaviorof the system: the TA may stay in the location as long as theinvariant is satisfied.We choose to illustrate our step of construction of the diag-

noser, a simple example. It is about the filling of a tank thanks tothe control of opening valve (hereinafter referred to as Example1; see Fig. 3).Our Uppaal model is represented in Fig. 4: the controller,

valve, flowmeter, and the plant are modeled as CTA. The con-figuration contains the global declaration of synchronization


Fig. 4. Uppaal model in Example 1. (a) Controller. (b) Valve. (c) Flowmeter.(d) Plant.

channels, clocks and global integer variables which may beinitialized.Initial states of automata are marked using a double circle.

The commands to open and close the valve are modeled as syn-chronization actions and . The real status ofthe valve is unobservable, so we use the observable variables

and for memorizing the synchroniza-tion between the controller and the valve. The tank level cap-tured by the flowmeter is expressed as an integer variable ini-tialized to 0, and updated to 1 when the level is reached. Wemodel the real state of the valve as an integer variable , initial-ized to 0. When the valve is closed, equals 0 and 1 when thevalve is opened. For the modeling of the valve, we consider thefault valve being stuck close. This means that the tank stays inthe initialized state. The physical behavior of the tank (Plant au-tomaton) is represented by a timed automaton. We use the clockto observe the filling up to the level . Knowing dimensionsof the tank and the flow of the valve, the high level is reached atthe end of 20 s. The sensor reading is modeled as the synchro-nization action .Building the draft diagnoser for Example 1: The application

of the first step of our method is the following.Through step 1a), we simulate the synchronous com-

position of the modules , ,, and . Initially, the current

location of an automaton is its initial location, so theinitial location of corresponds to the location vector

. The compu-tation of the draft diagnoser is as follows.

• From , only two transitions can be taken:— the synchronization

with ;

— the synchronization

with (we do notmention the update due to the initialization ofto 0).

The transition is currently unavail-able due to the absence of another available transition oftype .

The transition is also unavail-able, the current value of the integer variable is equal to0 ( is initialized to 0 during its declaration).So, the transitions of are:— with

;— with

.• The location vector is a deadlock state, there are nooutgoing transitions available.

• From ,only one transition can be taken.

— . Indeed, the incoming transi-tion of has the update .

The transition is cur-rently unavailable, and the current value of the integervariable is equal to 0 (L is initialized to 0 during itsdeclaration).

The transition is also currentlyunavailable due to the absence of another available transi-tion of type .

In a similar way, the transition isunavailable.So, the location vector has the transition:

— with.

• From ,only one transition can be taken:

— the synchronization with

.So, the location vector has the transition:

— with.


Fig. 5. Draft diagnoser in Example 1.

• From , only onetransition can be taken:— . Indeed the incomingtransition of has the update .

So, the location vector has the transitionwith .

• From ,only one transition can be taken: synchronization

with

.Thus, the location vector has the transition

with.

• The location vector is a deadlock state, and there areno outgoing transitions available. The construction of thepartial global model is finished.

By step 1b), we restrict the definition of the above transitionsto observable events. The draft diagnoser is an observer: we

rewrite the updates into ,

into , into

and into . We reset the variablesand to zero to take into considera-

tion a loop in the controller’s sequence.Fig. 5 shows the draft diagnoser computed for

the simple tank instrumentation. Its initial statehas two suc-

cessors andwith

the same transition (obtained by keeping onlyobservable events). These kinds of nondeterministic untimedtransitions impose a determinization step.

Fig. 6. Diagnoser in Example 1.

Fig. 6 is the diagnoser of our simple example: the draftdiagnoser is determinized, we have added a new location

for the isolation of the fault “the valveis stuck close”. We use a particular labeling of the locations:labels are composed of a prefix followed by an index

and a suffix of the form , or . is to beinterpreted as meaning “normal” (there is no failure), asmeaning “uncertain” (about whether a failure has occurred ornot), and as meaning that a failure of the type hasoccurred. Section VI will explain more precisely the diagnoserconstruction procedure.

III. RELATED WORKS

Here, we review the related works that are close to ours.We will first give a brief description of the original diagnoserapproach of Sampath et al. Second, we will consider diagnosismethods of timed discrete-event systems and classify them intocentralized, distributed, decentralized approaches and onlinealgorithms.

A. Original Diagnoser Approach

The early work on the model-based diagnosis problem hasbeen reported by Sampath et al. in [17], [18]. The system isassumed to consist of several distinct physical components.These components correspond to actuators and sensors. Eachof the component is modeled by a finite state machine (FSM)

, where is the state space, is theset of events, is the transition function, with no temporalconstraints, and is the initial state. The approach considersonly permanent failures on actuators and sensors. A failure isconsidered as permanent if, after the occurrence of the failure,the system remains in the faulty condition indefinitely. Thestates of the FSMs reflect the normal and the failed status ofthe system components while the failure events form part ofthe event set. The events are partitioned into observableand unobservable events. The observable events may beone of the following: commands issued by the controller andchanges of sensor information. The unobservable events may


be failure events or other events which change the state butthey are not recorded by sensors. The set of failure events

is partitioned into disjoint sets corresponding todifferent failure types: . In a firststep, a model of the whole system, calledcomposite model, is built using a synchronous compositionoperation on automata. In a second step, the composite modelis converted into a diagnoser: a deterministic finite state ma-chine denoted built from the modelwhere the set of events is the set of observable events of

the system . Each state of the diagnoser is of the formwhere is a state of and is

a label of the form:• : no failure;• : some failures may or may not have occurred(Ambiguous);

• : at least one failure of type hasoccurred;

• : at least one failure of typehas occurred and some other failures may or may not haveoccurred (Ambiguous).

The initial state of the diagnoser is defined to be. The transition function of the diagnoser

is constructed from the transition function of the compositemodel and the label propagation function . This functionassigns to each state its corresponding label regarding the pastevents. The assumptions of their method are that no FSM hasan unobservable cycle and the language generated by islive: there is a transition defined at each state , i.e., thecomposite model cannot reach a point at which no event ispossible.A first difference with the approach of Sampath et al. con-

cerns the model used to represent the system: we use communi-cating timed automata and we do not represent faults as unob-servable events, but as particular states of the timed automata.More precisely, our method applies the state-based approachformulated by [9] and [10]. With this approach, it is assumedthat the state set of the system can be partitioned according tothe condition of the system, failure status. The failure status ofactuators and sensors are represented with unmeasurable vari-ables. Since the system states describe the conditions of its com-ponents, diagnosing a fault can be seen as the identification inwhich state or set of states the system belongs to. However, thetransition function of our diagnoser is in part similar withSampath et al. It is based on the transition function of thecomposite model. A second difference with the Sampath et al.approach relates the ability in the isolation of faults. Indeed, weare able to distinguish faults leading to deviation of the systembehavior in term of timing constraints (indistinguishable in theuntimed approach), i.e., transitions with correct logic but faultson the firing time of the transitions.

B. Diagnostic Methods of TDESs

With the presence of real-time systems anywhere, TDES[31]) models become essential. There has been some re-search on diagnosis of timed discrete-event systems, e.g., [24],[32]–[42]. Diagnosis methods of timed DESs can be classifiedas centralized, decentralized, distributed or online.

1) Centralized Diagnosis Approaches for Timed DESs: Inone of the earlier work, Chen and Provan [32] have extendedthe work of Sampath et al. in discrete-time setting. They de-fine the notion of time diagnosability and propose necessaryand sufficient conditions for testing this property. The approachused in [32] for testing time diagnosability is to transform thetimed automaton into an untimed automaton. The temporal in-formation is represented by transitions of the special observableevent tick. Tick events are used to model the discrete evolutionof time. The Sampath diagnoser approach is applied to this un-timed automaton.Later, Zad et al. [33] propose a centralized approach of timed

systems modeled as a TDES, based on the same notion of clocktick. The authors extend their state-based approach presented in[9] by incorporating tick events.Our approach differs with these two related works on the

notion of time during the diagnoser construction. Neverless,our proposed development is quite similar with the diagnosismethod proposed by Biswas et al. in [34]. They propose adiagnostic method of real time discrete-event systems (RT-DESs). This formalism, which is similar to timed transitionmodels (TTMs) [50], allows to specify timing constraints ontransitions in terms of delay and deadline time bounds anduses a finite set of discrete variables. Their modular modelingmethodology uses a discrete time model and the state-basedapproach. The conditions corresponding to the states of eachcomponent model, failure status, are represented by unmeasur-able variables. There are some measurable variables reflectingthe controller commands and the sensors values. A transitioncan take place once it is enabled (a condition involving onlythe variables is satisfied), but only within the delay-deadlineinterval. The system is assumed to consist of many compo-nents operating concurrently and coordinating with each other.In a first step, a model of the whole system is built using asynchronous composition operation on automata. The secondstep computes the diagnoser by extending the diagnoser con-struction Sampath et al. with the consideration of delays anddeadlines. A first difference with our work is that the authorsconsider composite models which are closed systems, i.e.,the enabling condition of the transitions are always true. So,their approach considers only faults that have no change in thelogical behavior of the plant, the only changes observed are interms of timing related to delays and deadlines of the transi-tions. It is a restriction on the faults that can be diagnosed bytheir centralized diagnoser. However, their timing constraintsin terms of delay-deadline are less restrictive than ours.These previous related works fall in the discrete-time setting.

There exist some timed centralized approach for diagnosis inthe dense-time setting, e.g., [35], [36]. Depending on whetherthe time automata are dense-timed or discrete-timed, the clockstake their values in the nonnegative numbers or in the naturalnumbers.In [35], Derbel et al. propose a dense-time extension of the

Sampath et al. diagnosis approach. The diagnoser is a timed au-tomaton constructed offline. To handle the state space problem,the authors use zone representation [49] for partitioning the statespace into a set of symbolic states (zones). However no com-ment were made about the synthesis of their diagnoser.


Xu et al. [36] study the diagnosis problem of dense-time dis-crete-event systems in which time can only be measured bydigital-clocks with finite precision. The authors show that thediagnosis problem of dense-time systems with respect to bothtiming and event observation masks can be reduced to the diag-nosis problem of untimed discrete-event systems. Their notionof timing-mask captures nondeterminism of the untimed obser-vations of a timed trace as observed using a digital clock. Theypropose to apply the twin plant method [51], [52] to solve thediagnosis problem in the untimed setting.2) Distributed and Decentralized Diagnosis Approaches for

TDESs: The previous centralized approaches for timed DESrequire the computation of a global model of the system whichis not always possible with large discrete-event systems due tothe state explosion problem. To handle large timed DESs, thereexist methods relying on a decentralized (e.g., [24], [37], [38])or distributed model (e.g., [39]). In addition, these techniquestake advantage of the decomposition of modular systems.In [37], a template-based approach was developed for failure

diagnosis in timed DES in a distributed framework. A templatemodel is used to represent correct timing and sequencing rela-tionships between events. The measured event-time sequencesgenerated by the system under supervision are monitored bytemplates.Jiroveanu and Boel propose in [24] a distributed algorithm for

fault diagnosis problem of TDESs. TDESs considered in theirapproach are modeled as different time Petri net (TPN) modelsthat interact with each other. The authors propose the translationof the untimed distributed diagnosis paradigm to TPN models.Philippot et al. present in [38] a modular and distributed

model-based approach for the fault detection and isolation ofmanufacturing systems. In their modular modeling approachthe plant is divided into a set of independent plant elements(PEs). Each PE is itself divided into a set of communicating(interrelated) parts of plant (PoPs). These PoPs are modeledby classical and timed Moore automata that take into accountthe technological specifications used to produce them and thesystem dynamics evolution. The degraded and faulty behaviorsare added to each PoP model. An extrapolation of Gaussianlearning is applied to determine acceptable temporal intervalsof events after the activation of an order from the controller.However, a set of events signatures could represent severalfault candidates to return at the user. Consequently, for eachPE, a candidates’ tree is constructed based on these eventsignatures. These candidates’ trees serve as online observersfor all possible events.Sayed-Mouchaweh et al. [39] present a combination of the

diagnoser approach of Sampath et al. and the time template ap-proach of Pandalai and Holloway adapted for fault diagnosis ofmanufacturing systems. The goal of this combination is to finda remedy to the problem of synchronization of the initializa-tion between the manufacturing system and its diagnoser. Theirdecentralized approach is based on several timed-event-state-based local diagnosers that infer the fault’s occurrence usingevent sequences and time delays between events. Local diag-noses are fused by a simple coordinator based on a set of logicalrules. The method needs detailed models of the system compo-nents as well as the determination of the timed system behavior.

3) Online Diagnosis of Timed DESs: The problem of onlinefault diagnosis in the context of dense-time automata [49] hasbeen studied by Tripakis in [40]. The author shows how to con-struct a diagnoser as an online algorithm. The diagnoser in thisapproach is based on state estimation in a timed automaton with-transitions and its complexity to diagnose faults from an ob-servation is exponential in the size of the plant and in the sizeof the observation [53].Supavatanakul et al. [41] treat the problem of fault diagnosis

in TDESs which are represented by timed automata. The pro-posed online diagnostic algorithm identifies faults in the systemby comparing the input and output sequences with the timed au-tomaton. The given approach does not require any knowledgeof the initial state of the system. Their method applies the ideaof consistency-based diagnosis [54] to timed automata The ap-plication of their diagnostic method [41] focuses on the detec-tion and isolation in the DAMADICS actuators. Schullerus etal. [42] apply as well the idea of consistency-based diagnosisfor hierarchically structured timed discrete-event systems.Our positioning: Our research efforts fit in the centralized

diagnosis approaches for TDESs. We consider only permanentfaults on actuators and sensors under multiple failure scenarios.Our approach uses a modular modeling of complex systems byexploiting communicating timed automata. In this architecture,each component (actuators and sensors) is modeled separatelyvia a communicating automaton, and a control module synchro-nized with a timed automata specifying the dynamic behavior ofthe system manage the communication among the various com-ponents. We provide algorithms for automatically constructinga diagnoser, that uses observable events to detect the occurrenceof a failure. Section IV and V present the communicating timedautomata formalism and our modeling methodology.

IV. BACKGROUND ON TIMED AUTOMATA

A. Formal Syntax of a TA

A TA [49] is a finite-state machine extended with clock vari-ables. It uses a dense-time model where a clock variable eval-uates to a real number. All the clocks progress synchronously.Throughout the paper, we use Uppaal syntax to illustrate timedautomata.A TA is described by ,

with the following definitions.• is a finite set of states of the timed automaton, calledlocations.

• is the initial location.• is a set of synchronization actions which includesactions, co-actions, and internal -action. An action emitover a channel is denoted by and its co-action receiveis denoted by . The -action is an internal action suchthat there is no synchronization label.

• is the set of clocks.• is the set of integer variables.• is a setof edges (transitions) between locations with a synchro-nization action conditioned by a guard and performing a

sequence of assignments. We shall write when


. is the set of conjunctions oversimple conditions of the form or , where

, and . We useas the set of sequences of assignments of the form

, where refers to an integer vari-able or a clock and is an expression. The expressionsmust only refer to clocks, integer variables and integer

values. Assignments to clocks are limited to the regularassignment operator and only integer expressions are

allowed on the right hand side of such assignments. As-signments are performed after the guard evaluation and ina sequential manner (not concurrently). On synchronizingedges, the assignments on the!-side (the emitting side) areevaluated before the?-side (the receiving side).

• is a set of assignments that assigns theinitial values to variables.

• is function associated with each location.For each location , denotes its invariant, i.e. the TAmay stay in the location, as long as the invariant is satisfied.It is a conjunction of conditions of the form orwhere is a clock and evaluates to an integer.

B. Semantics of a Network of Timed Automata

Timed automata are often composed into a network oftimed automata over a common set of clocks, variables andsynchronization channels, consisting of timed automata

, .A location vector is a vector . Let

be the initial location vector. We compose the in-variant functions into a common function over location vectors

.We write to denote the vector where the th elementof is replaced by .A clock valuation is a function from the set of

clocks to the non-negative reals. Let be the set of all clockvaluations. Let for all .A variable valuation is a function from the set

of variables to the integers. Let be the set of all variablevaluations. Let be the initial variable valuation obtained fromthe initial assignments of each timed automaton.The semantics of a network of timed automata is defined as a

transition system , whereis the set of states called configurations (a configuration con-

sists of a location vector and the current values of the clocks andthe integer variables), is the initial configura-tion and is the transition relation between configu-rations. The transition between two configurations is called anadvancement step. There are three kinds of valid advancementsteps between two configurations, given here.• Time delay advancement step. if

for non-negativereal .

• Silent advancement step. if

there exist such that the clocks and variablesvaluation satisfies the guard , denoted , and

are obtained from the sequence assignments and.

• Synchronization advancement step.

if there exist and suchthat are obtained from the sequenceassignments and and .

V. FORMALIZATION OF THE INPUTS OF THEDIAGNOSER CONSTRUCTION

Every process plant can be unambiguously described witha process flow diagram (PFD) and a sequential function chart(SFC). Every identifiable hardware item in the flow diagram(including the controller) is treated as a component and mod-eled with an automaton. Here, we present our modeling method-ology for these kind of component. Our method can be easilyextended to consider permanent failures on pipelines and unitoperations such as storage tank. Fig. 4 illustrates our approachon the simple valve tank instrumentation (Example 1).

A. Model of the Controller (Input I1 in Fig. 2)

The controller is used for executing the sequential functionchart. As shown in Figs. 1 and 2, the controller receives as in-puts the status of the sensors and produces as outputs appro-priate commands to the actuators. In the case of a SFC withoutparallel branches as in Fig. 3, the controller model can be con-structed in a straightforward fashion according to the SFC. Thecomplete structure of steps and transitions can be reproducedby the locations and the transitions of a single communicatingautomaton. This even applies to complex SFC including nestedloops and alternative branches. However, in the case of a SFCwith parallel branches, the controller will be modeled as a set ofcommunicating automata as explained in [55]. In this paper, weconsider SFC without parallel branches. However, this frame-work can be easily extended to SFC with parallel branches byincorporating schemes described in [55].The controller model is defined as the communicating au-

tomaton . The set ofedges is formed by two kinds of transitions: or

, where is a Boolean expression onthe status of the sensors, is a synchronization channelbetween the controller and the actuator , isa variable memorizing the synchronization action over thechannel .

B. Models of the Actuators and the Sensors (Inputs I2 & I4in Fig. 2)

The automata of the actuators (respectively sensors) receiveas inputs the commands performed by the controller (respec-tively the plant) and update their status. These automata maycontain faulty states representing permanent failures, in thislatter case the update of the variable associated to the compo-nent is done by a false value. The set of edges of the th

actuator contains transitions of the form: , theset of edges of the th sensor contains transitions of the

form: .


Fig. 7. Small batch neutralization process (Example 2).

C. Model of the Plant (Input I3 in Fig. 2)

The CTA of the plant describes all possible evolutions,faultless and faulty. For the diagnosis purposes, it is neededthat the plant model covers any possible behavior and notsuch the faultless cases. The communicating timed automatonof the plant, ,receives as inputs the actuators values and produces as out-puts appropriate commands to the sensors. The set of edges

is composed by a sequence of transitions of the form:

, where is a Boolean expres-sion on the status of the actuators and serves as a timer totrigger a synchronization action over the channel whenthe clock satisfies the timed guard . In our modeling method-ology, the timed guards involve exclusively equality tests.The set of invariants contains .

D. Illustrative Example: Batch Process

Here, we will illustrate our diagnoser construction on a di-dactic example: a small batch neutralization process, referredas Example 2. The process represents a mixture of two ingredi-ents in one tank to obtain a final product. The tank is equippedby two level sensors and two input valves , c.f.Fig. 7.We model each equipment (valves and sensors), the control

sequence and the tank’s behavior as timed communicatingautomata. Filling in tank must respect the following controlsequence.• Step 0: When the process is initialized, tank should beempty.

Fig. 8. Automaton for the controller in Example 2.

• Step 1: First, valve is opened, an ingredient 1 flows intotank.

• Step 2: If level is reached then valve is closed andis opened.

• Step 3: If Level is reached then is closed.1) Automaton for the Controller (Input I1 in Fig. 2): The

commands to open and close the valves are modeled as synchro-nization actions .The states of the levels and are expressed as integervariables, initialized to 0, and updated to 1 when the level isreached. Fig. 8 describes the automaton of the controller.2) Automata for the Valves (Input I2 in Fig. 2): Wemodel the

real states of the valves and as integer variables and, initialized to 0. When the valve is opened, the associated

variable equals 1, 0 when the valve is closed. For the modelingof valve , we consider the following faults.• : Fault valve being stuck close. Practically it means,that tank stays in the initialized state. Controller waits fromevent which can not occur because of the stuck valve.

• : Fault valve being stuck open. This fault can physi-cally cause an overflow.

Fig. 9(a) describes the automaton of the valve with faultsconsideration. Valve in the faultless mode can be in the twostates: . The initial state is . The state canbe changed by the synchronization co-action and

. The description of the faulty behavior of corre-sponds to setting the variable with an incorrect value leadingto the faulty states and . Fig. 9(b) de-scribes the automaton of the valve without faults.3) Automata for the Sensors (Input I4 in Fig. 2): The real

states of the sensors and are modeled as integer vari-ables and , initialized to 0. When the level (resp. )is reached, the associated variable equals 1. For the modeling ofsensor , we consider the following fault : Sensor staysin close position. It means when the level is reached, thissensor does not indicate it. Fig. 10(a) describes the automaton ofthe sensor with faults consideration. Sensor in the fault-less mode can be in two states: . The initial state is

. The state can be changed by the synchronization co-ac-tion . The description of the faulty behavior ofcorresponds to setting the variable with an incorrect valueleading to the faulty state . Fig. 10(b) describes theautomaton of the sensor without faults.4) Timed Automaton for the Tank Behavior (Input I3 in

Fig. 2): The physical behavior of the tank is represented by aUppaal timed automaton. After building the timed automatonto represent normal behavior of the tank [Fig. 11(a)], additional


Fig. 9. Automata for the valves in Example 2. (a) Valve . (b) Valve .

Fig. 10. Automata for the sensors in Example 2. (a) Sensor . (b) Sensor .

states should then be incorporated to describe its faulty behavior[Fig. 11(b)]. For the diagnosis purpose it is needed that the tankmodel covers any possible behavior. We use two clocks, ,to observe the filling up to the level and . The evolu-tion of the dynamics is implemented using timed transitions(guards are expressed as conditions on clocks) which observethe respective clock, e.g., from state to (levelis reached by opening the valve while the valve is

still closed), the automaton reaches the state in time 20.These timed transitions produce an action corresponding to thesensor reading . For this purpose, the synchronizationaction and are used.

VI. DIAGNOSER CONSTRUCTION

Here, we fix a complex discrete-event system modeled asa network of CTA that share the following sets:• set of synchronization actions ;• set of clocks ;• set of integer variables ;• set of initial assignments .

Fig. 11. TA for the batch process in Example 2. (a) Batch process with faultlessbehavior. (b) Batch process with faultless and faulty behavior.

Our diagnoser construction procedure involves two phases.In the first phase, we construct a timed automaton named draftdiagnoser , which is the observable model of the compositionof the components. In the second phase, the diagnoser is ob-tained by "determinization" of .

A. Construction of the Draft Diagnoser (Output O1 in Fig. 2)

The algorithm for computing the draft diagnoser is given byAlgorithm 1.

Algorithm 1 Computation of the draft diagnoser

Require:

Ensure: draft diagnoser

1: Initialization: ;; ; ;

2: while do

3: ;

4: ;

5:;


6: {we partition the set of available transitions according tothe role of the controller or the plant in the transition}

7: if then

8: {we use a transition directed by the controller}

9: for all transition do

10: if then

11: ;

12: ;

13: end if

14: if then

15: {case where is a Boolean expressionon the status of the sensors}

16: ;

17: else

18: {case synchronized with

}

19: ;

20: end if

21: end for

22: else

23: {we use a transition directed by the plant}

24: for all {transition do

25: if then

26: ;

27: ;

28: end if

29: if then

30: {case where is a Booleanexpression on the status of the actuators}

31: ;

32: else

33: {case synchronized with

where is a Boolean expression on theclock }

34: ;

35: end if

36: end for

37: end if

38: end while

The interesting idea is to apply a reachability analysis on thecomposition and to limit theexploration of the state space by giving greater priority to con-troller transitions as explained in Section II.To express the composition ,

the states of are defined as tuples of states of the components(called location vectors). Thus, the initial state of , is ex-pressed as .The reachability analysis takes into account the timing con-

straints and the updates of integer variables or clocks. The func-tion computes the exact set of statesthat can be reached by a location vector and the current valuesof the clocks and the integer variables.The main data structure is a (FIFO) queue to hold

the reachable states of in postorder.Priority given to controller transitions is expressed in lines

5–7: we partition the set of available transitions according to therole of the controller (function ) and useonly these transitions, if present, for the reachability analysis.In lines 19 and 31, the real status of the actuators, unob-

servable events, do not appear as guard of the building transi-tions. However, we use some integer variablesto memorize the request on .To understand the steps in Algorithm 1, the reader is invited

to refer to detailed explanations in paragraph Building the draftdiagnoser for example 1 of Section II.Fig. 12 shows the draft diagnoser obtained by Algorithm 1

for example 2 (batch process described in Fig. 7, Section V-D),states are numbered.

B. Construction of the Diagnoser (Output O2 in Fig. 2)

The timed automaton obtained by Algorithm 1 can not beused as a diagnoser, it contains some nondeterministic untimedtransitions. Recall that its timed transitions are deterministic(see explanation Section II). So we need a step of determiniza-tion concerning the untimed transitions. Algorithm 2 presentsour determinization procedure. It is based on the subset con-struction method: the basic idea underlying the transformationis the use of sets of states of the nondeterministic automaton asstates in the corresponding equivalent deterministic automaton.The initial state of the diagnoser is formed by a singleton thatcontains the initial state in the draft diagnoser. As in Algorithm1, we use a (FIFO) queue to hold the new states of thediagnoser in postorder.

Algorithm 2 Computation of the diagnoser

Require: draft diagnoser

Ensure: diagnoser

1: Initialization: ; ; ;;

2: while do

3: ;

4:;


Fig. 12. Draft diagnoser in Example 2 constructed by Algorithm 1. The names of the states are expressed as location vectors and are numbered.

5: {we partition the set of states according to they are ornot source of transitions in

6: for all do

7: { and has some transitions in

8: ;

9: for all do

10: if such that then

11: { is present in of another state ofthe diagnoser, so it is unnecessary to create a new state}

12: ;

13: else if then

14: {there exists already a transition in the diagnoserstarting from with the same guard/assignment of transition, so we complete the subset of states with }

15: ;

16: else

17: Create new state ;

18: ;

19: ;

20: ;

21: end if

22: end for

23: end for

24: for all do

25: { and has no transition in }

26: if then

27:

28: else ifsuch that the Boolean expression is satisfied inthen

29:

30: else if then

31:

32: else

33: Create new state ;

34: ;

35: ;

36: end if

37: end for

38: end while


While there is a state of the diagnoser for which the tran-sitions have not been determined (loopWhile line 2), we do thefollowing.• According to the nature of source of transitions inthe draft diagnoser, the set of states is decomposedby the function .The set of states and

(line 4) are obtained.• From (lines 6–23), we createnew sets of states (new states in the diagnoser) com-posed by the set of destination of transitions having theirsources in and with the sameguards/assignments. We create new transitions in the di-

agnoser .• From (lines 24–37), firstlywe search to complete the set of states computed atthe previous step by using their incoming transitions of theform: empty guard or guard satisfied or transition labeledwith . If it is not possible, we createnew sets of states composed by a single state .For these later states, theirs incoming transitions labeledwith must be defined manually asthe negation of a Boolean formula composed by the dis-junction of all the others guards starting from .

Building the diagnoser for example 2: The application of Al-gorithm 2 is the following. We use sets of states of the draftdiagnoser as states in the diagnoser . Transitions in arededuced from transitions in . The initial state of , , cor-responds to a singleton that contains the initial state of (seeFig. 12). So, . The set of states of , is initializedby and its set of transitions is empty. The firststeps of Algorithm 2 are as follows:1) We partition the set of states according to theyare or not source of transitions in . From state 0 only two

transitions in can be taken: and

. We perform the following assign-ments (lines 4–8): ,

,

. States 1and 2 are not present in a state of and does not

contain a transition of the form , sowe create a new state (lines 17–18) and the

following transition in : (line19).This first computation step gives us:

and .2) We partition the set of states according tothey are or not source of transitions in . We make thefollowing assignments: ,

(line 4). Fromstate 1, only one transition in is available, so

(line 8). State 3 is not presentin a state of and does not contain a transition of

the form . We create a new state andthe following transition in . Since thisnew transition has a guard of the form , wecomplete the set of states computed above with thestate ,(line 27). This second computation step gives us:

and

.3) We partition the set of states :

and. The available

transitions are

. States 4 and 5 are not presentin the set of states of and does not containsome transition of the form

or . So, we create twonew states and and their

incoming transitions:

and . Since the statesatisfies the condition

due to the initial configurationand an absence of condition on the pathleading to state 2 (see Fig. 12), we complete the set ofstates computed above with the state 2,(line 29). This third computation step gives us:

and

.4) Analysis of state is done in a similar waywith state (see step 2 above). So, we createa new state and its incoming transition:

.5) We partition the set of states :

and. From state

19, only one transition is available

. State 20 is not present ina state of and does not contain a transition of theform . So, we create a new state

(lines 17–18) and the following transition

(line 19). Since the statedoes not satisfy the con-

dition due to the initial configurationand an absence of condition on the path leadingto state 2, we create a new state (lines 31–32)and the following transition(line 33). We substitute the guardby . This new guard is deducedby the timing constraint on its neighbor andthe value of on state 2.

6) Computation of the other states of the diagnoser is done ina similar way.


Fig. 13. Application of Algorithm 2 on the draft diagnoser of Fig. 12.


Fig. 13 shows the diagnoser construction by Algorithm 2 ap-plied to the draft diagnoser of Fig. 12.

C. Labeling the States of the Diagnoser

The diagnoser’s transitions correspond to observations andthe diagnoser’s states correspond to the system states and fail-ures that are consistent with the observations. To facilitate thedetection and isolation of faults in the system, the diagnoser’sstates are labeled with the current status of the diagnosis. Statesare labeled as follows.• When the state of the diagnoser is a singleton that con-tains an unique state of the draft diagnoser, ,the labeling of is:— , if the location vector has no failedcomponent.

— if the location vector has one or more failedcomponents. The suffix is composed by the nameof the failed components and their type of faults, e.g.,

. These informations come fromthe labeling of states of the draft diagnoser which men-tion the status of each component.

• When the state of the diagnoser is a subset oftwo or more location vectors of the draft diagnoser,

, the labeling of is given by:— if there exists one or more location vectors

which contain at least a faulty component and thereexists a location vector which has no failedcomponent. There is uncertainty: the system is normalor faulty, then nothing can be diagnosed.

— if all of the location vectors share acommon subset of faulty components described bybut the status of the remaining components are non-identical. The system is faulty but there is an ambiguityin identifying the fault. The fault scenario is partiallyknown.

— otherwise. All of the location vectors con-tain at least a faulty component, but of each locationvector are distinct from all others. There is as well anambiguity in identifying the fault.

Fig. 14 is the diagnoser of the example 2. States are renamedas explained above. Several states of the diagnoser are namedwith , or . So,the faults (valve being stuck close), (valve being


stuck open) and (sensor being stuck down) are detectedand isolated.

VII. FORMAL VERIFICATION OF THE DIAGNOSER

The construction of the diagnoser without verifying its cor-rectness is needless.Wemust prove that the diagnoser is correct,in the sense that it announces a fault scenario if and only if thefault scenario has occurred. Our verification methodology usemodel-checking techniques [56] proposed in [57] for obtainingthe formal verification of our diagnosers. Thanks to our mod-eling in Uppaal, we can use its model checker.

A. The Uppaal Model Checker

In Uppaal, a system is modeled as a network of severaltimed automata in parallel. A state of the system is definedby the locations of all automata, the clock values, and thevalues of the discrete variables. The model checking tool ofUppaal supports a fragment of the Timed Computational TreeLogic [56] (TCTL). The supported TCTL formulas consistof state formulas and path formulas. A state formula takesthe form:

. A path is a sequence of states.At each state, a state formula can be evaluated. A path for-

mula ranges over possible sequences of successive states anduses some temporal operators classified in path operators andstate operators. The path operators are the following: (“forall paths starting from the current state”) and (“there existsat least one path starting from the current state”). The state op-erators allowed in Uppaal are the following: (“eventually”)and (“always”). The TCTL formulas allowed by the Uppaalmodel checker can be classified as:• Reachability properties: these properties ask whether agiven state formula possibly can be satisfied by anyreachable state are expressed as .

• Safety properties: a state formula holds in all of the statesof an execution path, and there are two possibilities:— (always globally ): for each (all) execution path,

holds for all the state of the path;— (exists globally ): there is an execution path inwhich holds for all the states of the path.

• Liveness properties: a specific condition is guaranteed tohold eventually. There are two possibilities:— (“always eventually ): for each (all) executionpath holds for at least one state of the path;

— (abbreviated , always leadsto ): any path that “starts” with a state in which holdsreaches later a state in which holds.

B. Diagnoser Verification Methodology

In this subsection, we provide a methodology of verificationof any diagnoser built with the method described in the pre-vious Section VI. The idea of formal verification is to checkthe behavior of diagnoser according to reachable states inglobal model (composed by timed automata components,

). The proposed verifica-tion is done for every example.We formulate that an actuator or a sensor has encountered

the fault scenario as the global model reaches the state

. In a similar way, the announce of an isolable or am-biguous fault scenario by the diagnoser is formulated as thediagnoser reaches the state ( is isolated) or(we are only sure of the presence of the faults ) or( is ambiguous).To verify the correctness of the diagnoser, we are taking the

synchronous composition of the global model and the diag-noser model . We must verify:1) that there are no missed detections. If an observable faultscenario occurs then three situations can occur:a) the diagnoser must eventually lead to a state in whichit is isolated. Formally, this property is expressed bythe liveness property .

b) the diagnoser must eventually lead to a state inwhich it is detected but the fault scenario is notdistinguishable (ambiguity) from other fault sce-narios . These fault scenariosshare a common subset of faults described by

. Formally,this property is expressed by the liveness property

.c) otherwise, the diagnoser must eventually lead to astate in which it is detected but the fault scenariois not distinguishable from anothers fault scenarios

which are distinct from each others:. Formally, this property

is expressed by the liveness property .2) that there are no false result provided by the diagnoser.

a) Every diagnoser result of the form (isolationof fault scenario ) is caused by this fault scenario.Hence, this safety property is formulated as follows:

.b) Every diagnoser result of the form (am-biguity) is caused by the following fault scenarios:

withThis safety property is formulated as follows:

.c) Every diagnoser result of the form (ambi-guity) is caused by the following fault scenarios:

withThis safety property is formulated as follows:

.Given a global model and a diagnoser , for each actuator

fault and sensor fault, we instantiate these schemes of formulasand apply the Uppaal model checker to have confidence in ourconstructed diagnoser.

VIII. IMPLEMENTATION

The diagnoser software is based on two parts: the core imple-mented in C++ and the graphic interface implemented in GTK+.The core implements Algorithm 1 and Algorithm 2, generatesthe Uppaal description of the diagnoser. It is approximately5000 lines long. The diagnoser software has a friendly GUI forthe generation of the diagnoser in 3 steps (see Fig. 15).Step 1—TDES selection: The timed discrete-event system

to be diagnosed is retrieved. The Uppaal file containing the de-scription of all its components (controller, plant, actuators andsensors) is parsed (the Uppaal Timed Automata Parser Libraryis freely available at http://www.uppaal.org).


Fig. 15. Windows of the diagnoser software. (a) Selection of the TDES; (b) Se-lection of the faults; (c) Generation of the diagnoser; (d) Overview of the diag-noser characteristics.

Step 2—Faults selection: Select the faulty states in the ac-tuators and the sensors.Step 3—Generation: The user defines the filename of the

diagnoser. The diagnoser is generated.

IX. APPLICATIONS

In order to demonstrate the feasibility and the effectivenessof the proposed approach for diagnosis of timed discrete-eventsystems, two realistic case studies have been considered.

Fig. 16. Batch process with the control sequence. (a) Tank instrumentation; (b)Controller description.

A. Case Study: Complete Batch Process

In this subsection, we present the complete version of thebatch process, referred as Example 3, which is more complexthan our Example 2 in Section V-D: more equipments, automataof greater complexity and more faults are considered.The process consists in one tank that is equipped by three

level sensors ( and an overflow level sensor ) and three


Fig. 17. Automata for the Valves and Sensors in Example 3. (a) Valve . (b) Valve . (c) Valve . (d) Sensor . (e) Sensor . (f) Sensor .

valves, see Fig. 16(a). Valves as input valves, outputvalve . The possible failures considered here are:• Valves and can be stuck open or stuck close.• Sensors and can be stuck down.1) Automaton for the Controller: The automaton for

the controller, described by Fig. 16(b), can be constructedin a straightforward fashion according to the sequential func-tion chart.The production sequence is the following:• Step 0: When the process is initialized, tank should beempty.

• Step 1: First, valve is opened, an ingredient 1 flows intotank.

• Step 2: If level is reached then valve is closed andis opened.

• Step 3: If level is reached then is closed and valveis opened.

• Step 4: Level in the tank is below the mark• Step 5: When the level in the tank is below the markthen valve is closed and it is possible to start the fabri-cation of another product.

In a manner similar to Example 2, the commands to openand close the valves are modeled as synchronization ac-tions , , , , ,

.2) Automata for the Valves and the Sensors: Fig. 17 presents

the Uppaal descriptions of the faulty and faultless valves (com-ponents , and ) and the Uppaal descriptions of thefaulty and faultless sensors (components , and ).We model the real state of the valves , and as

integer variables with the same names, initialized to 0. Whenthe valve is opened, the associated variable equals 1, 0 whenthe valve is closed. The state of the valve can be changed bythe synchronization co-action and . The de-

scription of the faulty behavior of a valve corresponds to settingthe associated variable with an incorrect value.The real state of the sensors and the overflow sensoris modeled as integer variables and , initial-

ized to 0. When the level of a sensor is reached, the associatedvariable equals 1 and resetted to 0 when the level is below themark. The state of sensor can be changed by the synchroniza-tion co-action (the level is above the mark ) and(the level is below the mark ). The synchronization co-ac-tion and are used in a similar way for the sensor .The state of the overflow sensor can be changed by the synchro-nization co-action . The description of the faulty be-havior of a sensor corresponds to setting the associated variablewith an incorrect value.3) TA for the Tank Behavior: Fig. 18(b) presents the Up-

paal description of the plant (component ) which describesall possible evolutions, faultless [see Fig. 18(a)] and faulty. Forthe diagnosis purposes, it is needed that the plant model coversany possible behavior and not such that is desired, the fault-less cases. We use four clocks, , , , and , to observethe filling up to the level , the filling up to the leveland emptying the tank. The evolution of the dynamics is im-plemented using timed transitions which observe the respectiveclock. These timed transitions produce an action correspondingto the sensor reading and the overflow sensor . Forthis purpose, the synchronization actionare are used.4) Diagnosis Automaton for Example 3: Fig. 19

presents the Uppaal description of the diagnoser builtautomatically from our software. The diagnoser is com-posed of 51 states and only two guards must be de-fined. These guards ( and

) are easily deduced from theirsneighbors.


Fig. 18. TA for the complete batch process in Example 3. (a) Batch process with faultless behavior. (b) Batch process with faultless and faulty behavior.

5) Numerical Results: Table I summarizes the sizes of theautomata (number of states and number of transitions for eachtype of component) handled in this example.Our approach considers permanent faults and the multiple

fault diagnosis. Diagnosis methods can not detect and isolate allpossible multiple-failure combinations. First, a discrete-eventsystem can have faults or combination of faults which arenonobservable. These nonobservable fault scenarios createstates which are not reachable from the initial state of thecontroller automaton. Second, there may exist fault scenariosthat are detectable but not necessary isolable: two or more faultscenarios share the same symptoms, there is an ambiguity in theisolation. Consider the illustrative Example 3, the fault scenario“valve stuck closed combined with valve stuck closed”is nonobservable. If valve is stuck closed, the controller[see Fig. 16(b)] stops at the transition guard , hencethe future transition-action can not be fired. Thus,the above fault scenario is not observable.The application of our diagnostic method on Example 3

allows us to detect and isolate all observable combination of

faults. There is eleven observable scenarios of combination offaults from thirty-five possibilities, see Table II. This limitationcomes from the control sequence considered.

B. Case Study: Three-Tank Storage System

Let us consider the three-tank storage system presented inFig. 20. This problem, referred as Example 4, was studied in[58]. The flow of the inlet pipeline of tank is controlled withvalve . A pump is installed on the outline pipeline ofwhich is connected to a three-way valve . When is at theposition “ ,” the fluid in the outlet pipeline of will be trans-ferred into the tank . If is at the position “ ,” the fluid inthe outlet pipeline of will flow into the tank . Valve isused to empty the tank , while for . Tank has fourlevel sensors installed: level low ; level medium ;level high and overflow level . Tanks andare equipped by three level sensors: level low ; levelhigh and overflow level .The sequential function chart for the three-tank storage

system [Fig. 20(b)] realizes the following sequence.



TABLE ISIZES OF THE AUTOMATA IN EXAMPLE 3

• Step 0: When the process is initialized, tanks , andshould be empty. Valves and are closed. The

pump is stopped and valve is switched at position “ .”• Step 1: First, valve is opened, an ingredient flows intotank .

• Step 2: If level in is reached then valve isclosed, is switched at position “ ” and the pump starts.

• Step 3: When the level in is reached and the levelin is below the mark then the pump is stopped,

is switched at position “ ” and the pump restarts.

TABLE IIFAULT SCENARIOS IN EXAMPLE 3 AND THEIR DETECTION

: Valve can be stuck closed. : Valve can be stuck open.: Valve can be stuck closed. : Valve can be stuck open.: Sensor can be stuck down. : Sensor can be stuck down.

• Step 4: When the level in is reached and the levelin is below the mark then the pump is stopped,valves and are opened.


Fig. 20. Three-tank system (Example 4). (a) Instrumentation for three-tanksystem. (b) SFC for three-tank system.

• Step 5: When the levels in and are below the markand then valves and are closed. These

steps are supposed to be executed in sequence periodically.Table III summarizes the sizes of the automata (number of

states and number of transitions for each type of component)handled in this example. We remark that the sizes of the draft

TABLE IIISIZES OF THE AUTOMATA IN EXAMPLE 4

TABLE IVFAULT SCENARIOS IN EXAMPLE 4 AND THEIR DETECTION

: Valve can be stuck closed. : Valve can be stuck open.: Valve can be stuck at “ .” : Valve can be stuck at “ .”: Pump can be stuck off. : Pump can be stuck on.

diagnoser and the diagnoser are proportional to the complexityof the plant behavior.We have modeled and simulated in MATLAB SIMULINK the

three-tank system for fixed values of the following parameters:dimensions of the tanks, flow-rate provided by the pump andflow-rate of the valves. The simulation does not only detectevents but also considers the appearance time of each event.This knowledge of events and time is imprinted into the timedautomata of the plant behavior. The construction of the TA thatmodels the plant behavior is based on two models representingthe different modes of the system: the faultless model and thefaulty model by taking into account all failure mode of the in-strumentation (valves and pump). The possible failures consid-ered here are:• valve can be stuck closed or stuck open;• valve can be stuck at “ ” or stuck at “ ” position;• pump can be stuck off or stuck on.The performance of our diagnosis approach applied to the

three-tank system are presented in Table IV. It can be ob-served that, although all of the observable fault scenarios aredetectable, many scenarios are indistinguishable. The onlinesymptoms of twelve possible scenarios can only be classi-fied into five distinct groups ({1,2}, {5,6}, {7,8,9}, {12,13},{14,15,16}). However, our diagnosis approach provides apartial explanation of the sources of the detected failure. Theambiguities are partially explained by diagnoser’s states labeledwith when all of the faults scenarios indistinguishableshare a common subset of faulty components described by


(see explanations in Section VI-C). The fault scenarios 3, 4, 10,11, and 17 are detectable and isolable.

X. CONCLUSION AND PERSPECTIVES

This paper proposes a model-based approach to online pas-sive fault diagnosis for timed systems.We suppose the system tobe diagnosed is described as a network of communicating timedautomata with some limitations: we consider only equality testin the timing constraints. Each component describes an actuatoror a sensor or the control sequence or the process. We consideronly permanent fault models for actuators and sensors. The firstcontribution of this paper is the formalization of the systemsthat we are able to take into account. The second contribution isthe definition of a diagnoser for such systems and algorithms tobuild it are given. Our construction method involves two steps.First, we build the partial global model of the composition ofthe components, we obtain a draft version of our diagnoser: itis composed of nondeterministic untimed transitions and deter-ministic timed transitions. Thus, in a second step, we “deter-minize” it to obtain the final diagnoser. Our approach has beenimplemented and experimented on different case studies.Our numerical results (Tables I and III) might suggest that we

handle the state explosion problem: the size of the diagnoser isnot the product of the sizes of the state spaces of the individualautomaton. Indeed, our approach does not explore the wholeglobal model: we keep only states that are relevant to the diag-nosis. One future work will analyze the time and space com-plexity of our proposed approach in order to be able to compareits complexity with other related works.We have applied model-checking techniques [56] for the

formal verification of our diagnosers. The property to bechecked expresses that the diagnoser is correct if it announcesa fault if and only if the fault already exists in the systemmodel. Our current works aim to provide formal proofs for thecorrectness of ours algorithms.A perspective of this work is to extend our approach to take

into account uncertainly in task durations that appear in someprocess, for example in manufacturing systems. Another issuenot addressed in this paper is the study of the diagnosability offailures, and how to obtain necessary and sufficient conditionsfor failure diagnosability.

ACKNOWLEDGMENT

The authors would like to thank the anonymous reviewersfor their valuable and constructive comments and helpfulsuggestions which greatly improved the presentation of thismanuscript.

REFERENCES

[1] W. E. Vesely, M. Stamatelatos, J. B. Dugan, J. Fragola, J. Minarick,and J. Railsback, “Fault tree handbook with aerospace applications,”NASA Office of Safety and Mission Assurance, 2002.

[2] J. B. Dugan, S. J. Bavuso, andM. A. Boyd, “Dynamic fault-tree modelsfor fault-tolerant computer systems,” IEEE Trans. Reliab., vol. 41, no.3, pp. 363–377, Sep. 1992.

[3] G. K. Palshikar, “Temporal fault trees,” Inf. Software Technol., vol. 44,no. 3, pp. 137–150, Mar. 2002.

[4] Z. Simeu-Abazi, A. Lefebvre, and J.-P. Derain, “A methodology ofalarm filtering using dynamic fault tree,” Reliabil. Eng. Syst. Safety,vol. 96, no. 2, pp. 257–266, Feb. 2011.

[5] E. Gascard, Z. Simeu-Abazi, and J. Younes, “Exploitation of built intest for diagnosis by using Dynamic Fault Trees: Implementation inMatlab Simulink,” in Advances in Safety, Reliability and Risk Manage-ment (ESREL’11). Boca Raton, FL: CRC, Aug. 2011, pp. 436–444.

[6] S. Simani, R. Patton, and C. Fantuzzi, Model-Based Fault Diagnosis inDynamic Systems Using Identification Techniques. Berlin, Germany:Springer, 2003.

[7] M. G. Singh, Fault Detection & Reliability: Knowledge Based &OtherApproaches, ser. Int. Series on Syst. and Control. New York: Perg-amon, 1987.

[8] E. García, A. Correcher, F. Morant, E. Quiles, and R. Blasco, “Mod-ular fault diagnosis based on discrete event systems,” Discrete EventDynamic Syst., vol. 15, no. 3, pp. 237–256, Sep. 2005.

[9] S. Hashtrudi Zad, R. H. Kwong, and W. M. Wonham, “Fault diagnosisin discrete-event systems: Framework and model reduction,” IEEETrans. Autom. Control, vol. 48, no. 7, pp. 1199–1212, Jul. 2003.

[10] F. Lin, “Diagnosability of discrete event systems and its applications,”Discrete Event Dynamic Syst.: Theory Applic., vol. 4, no. 2, pp.197–212, May 1994.

[11] F. Basile, P. Chiacchio, and G. De Tommasi, “An efficient approachfor online diagnosis of discrete event systems,” IEEE Trans. Autom.Control, vol. 54, no. 4, pp. 748–759, Apr. 2009.

[12] P. Baroni, G. Lamperti, P. Pogliano, and M. Zanella, “Diagnosis of aclass of distributed discrete-event systems,” IEEE Trans. Syst., Man,Cybern. A, Syst. Humans, vol. 30, no. 6, pp. 731–752, Nov. 2000.

[13] A. Benveniste, E. Fabre, S. Haar, and C. Jard, “Diagnosis of asyn-chronous discrete-event systems: A net unfolding approach,” IEEETrans. Autom. Control, vol. 48, no. 5, pp. 714–727, May 2003.

[14] M. Dotoli, M. P. Fanti, A. M. Mangini, andW. Ukovich, “On-line faultdetection in discrete event systems by Petri nets and integer linear pro-gramming,” Automatica, vol. 45, no. 11, pp. 2665–2672, Nov. 2009.

[15] Y. Ru and C. N. Hadjicostis, “Fault diagnosis in discrete event sys-tems modeled by partially observed petri nets,” Discrete Event Dy-namic Syst., vol. 19, no. 4, pp. 551–571, 2009.

[16] A. Ramírez-Treviño, E. Ruiz-Beltrán, J. Arámburo-Lizárraga, and E.López-Mellado, “Structural diagnosability of DES and design of re-duced petri net diagnosers,” IEEE Trans. Syst., Man, Cybern. A, Syst.Humans, vol. 42, no. 2, pp. 416–429, Mar. 2012.

[17] M. Sampath, R. Sengupta, S. Lafortune, K. Sinnamohideen, and D.Teneketzis, “Diagnosability of discrete-event systems,” IEEE Trans.Autom. Control, vol. 40, no. 9, pp. 1555–1575, Sep. 1995.

[18] M. Sampath, R. Sengupta, S. Lafortune, K. Sinnamohideen, and D.Teneketzis, “Failure diagnosis using discrete-event models,” IEEETrans. Control Syst. Technol., vol. 4, no. 2, pp. 105–124, Mar. 1996.

[19] K. Schmidt, “Abstraction-based failure diagnosis for discrete eventsystems,” Syst. Control Lett., vol. 59, no. 1, pp. 42–47, Jan. 2010.

[20] T. Ushio, I. Onishi, and K. Okuda, “Fault detection based on Petri netmodels with faulty behaviors,” in Proc. IEEE Int. Conf. Syst., Man,Cybern., Oct. 1998, vol. 1, pp. 113–118.

[21] S.-L. Chung, C.-C. Wu, and M. Jeng, “Failure diagnosis: A case studyon modeling and analysis by petri nets,” in Proc. IEEE Int. Conf. Syst.,Man Cybern., Oct. 2003, vol. 3, pp. 2727–2732.

[22] M. P. Cabasino, A. Giua, M. Pocci, and C. Seatzu, “Discrete event di-agnosis using labeled Petri nets. An application to manufacturing sys-tems,” Control Eng. Practice, vol. 19, no. 9, pp. 989–1001, Sep. 2011.

[23] P. Baroni, G. Lamperti, P. Pogliano, and M. Zanella, “Diagnosis oflarge active systems,” Artif. Intell., vol. 110, no. 1, pp. 135–183, May1999.

[24] G. Jiroveanu and R. K. Boel, “A distributed approach for fault detectionand diagnosis based on time petri nets,”Math. Comput. Simulation, vol.70, no. 5–6, pp. 287–313, Feb. 2006.

[25] S. Genc and S. Lafortune, “Distributed diagnosis of place-borderedpetri nets,” IEEE Trans. Autom. Sci. Eng., vol. 4, no. 2, pp. 206–219,Apr. 2007.

[26] J. Arámburo-Lizárraga, A. Ramírez-Treviño, E. López-Mellado, andE. Ruiz-Beltrán, Advances in Robotics, Automation and Control. Vi-enna, Austria: In-Tech., 2008, ch. 5, pp. 69–84.

[27] Y. Pencolé and M.-O. Cordier, “A formal framework for the decen-tralised diagnosis of large scale discrete event systems and its applica-tion to telecommunication networks,” Artif. Intell., vol. 164, no. 1–2,pp. 121–170, May 2005.

[28] W. Qiu and R. Kumar, “Decentralized failure diagnosis of discreteevent systems,” IEEE Trans. Syst., Man, Cybern. A, Syst., Humans,vol. 36, no. 2, pp. 384–395, Mar. 2006.


[29] O. Contant, S. Lafortune, and D. Teneketzis, “Diagnosability of dis-crete event systems with modular structure,” Discrete Event DynamicSyst., vol. 16, no. 1, pp. 9–37, Jan. 2006.

[30] Y. Wang, T.-S. Yoo, and S. Lafortune, “Diagnosis of discrete eventsystems using decentralized architectures,” Discrete Event DynamicSyst., vol. 17, no. 2, pp. 233–263, Apr. 2007.

[31] B. A. Brandin and W. M. Wonham, “Supervisory control of timed dis-crete-event systems,” IEEE Trans. Autom. Control, vol. 39, no. 2, pp.329–342, Feb. 1994.

[32] Y.-L. Chen and G. Provan, “Modeling and diagnosis of timed discreteevent systems—A factory automation example,” in Proc. Amer. Con-trol Conf., 1997, pp. 31–36.

[33] S. Hashtrudi Zad, R. H. Kwong, and W. M. Wonham, “Fault diagnosisin discrete-event systems: Incorporating timing information,” IEEETrans. Autom. Control, vol. 50, no. 7, pp. 1010–1015, Jul. 2005.

[34] S. Biswas, D. Sarkar, P. Bhowal, and S. Mukhopadhyay, “Diagnosis ofdelay-deadline failures in real time discrete event models,” ISA Trans.,vol. 46, no. 4, pp. 569–582, Oct. 2007.

[35] H. Derbel, M. Yeddes, N. B. Hadj-Alouane, and H. Alla, “Diagnosis ofa class of timed discrete event systems,” in Proc. IEEE 8th Int. Work-shop Discrete Event Syst., Jul. 2006, pp. 256–261.

[36] S. Xu, S. Jiang, and R. Kumar, “Diagnosis of dense-time systems underevent and timing masks,” IEEE Trans. Autom. Sci. Eng., vol. 7, no. 4,pp. 870–878, Oct. 2010.

[37] D. N. Pandalai and L. E. Holloway, “Template languages for fault mon-itoring of timed discrete event processes,” IEEE Trans. Autom. Control,vol. 45, no. 5, pp. 868–882, May 2000.

[38] A. Philippot, M. Sayed-Mouchaweh, V. Carré-Ménétrier, and B. Riera,“Generation of candidates’ tree for the fault diagnosis of discrete eventsystems,” Control Eng. Practice, vol. 19, no. 9, pp. 1002–1013, Sep.2011.

[39] M. Sayed-Mouchaweh, A. Philippot, and V. Carré-Ménétrier, “Decen-tralized diagnosis based on Boolean discrete event models: Applicationon manufacturing systems,” Int. J. Production Res., vol. 46, no. 19, pp.5469–5490, Oct. 2008.

[40] S. Tripakis, “Fault Diagnosis for Timed Automata,” in Formal Tech-niques in Real-Time and Fault-Tolerant Systems, ser. Lecture Notes inComputer Science, W. Damm and E.-R. Olderog, Eds. Berlin, Ger-many: Springer, 2002, vol. 2469, pp. 205–221.

[41] P. Supavatanakul, J. Lunze, V. Puig, and J. Quevedo, “Diagnosis oftimed automata: Theory and application to the DAMADICS actuatorbenchmark problem,” Control Eng. Practice, vol. 14, no. 6, pp.609–619, Jun. 2006.

[42] G. Schullerus, P. Supavatanakul, V. Krebs, and J. Lunze, “Modellingand hierarchical diagnosis of timed discrete-event systems,” Math.Computer Modelling of Dynamical Syst., vol. 12, no. 6, pp. 519–542,Dec. 2006.

[43] M. Knotek, “Fault diagnostics based on temporal analysis,” Ph.D. dis-sertation, Control Instrum. Dept., Univ. Joseph Fourier and BRNOUniversity of Technology, Grenoble, France, 2006.

[44] Z. Simeu-Abazi, “Backward time analysis for the diagnosis of discreteevent systems,” in Proc. 1st IFAC Workshop Adv. Maintenance Eng.,Services and Technol., Jul. 2010, pp. 147–152.

[45] Z. Simeu-Abazi, M. Di Mascolo, and M. Knotek, “Fault diagnosisfor discrete event systems: Modelling and verification,” Reliabil. Eng.Syst. Safety, vol. 95, no. 4, pp. 369–378, Apr. 2010.

[46] Z. Simeu-Abazi, E. Gascard, and F. Chalagiraud, “Diagnosticof discrete event systems using timed automata in MATLABSIMULINK,” in Advances in Safety, Reliability and Risk Management(ESREL’11). Boca Raton, FL: CRC Press, Aug. 2011, pp. 402–409.

[47] P. Krcal and W. Yi, “Communicating timed automata: The more syn-chronous, the more difficult to verify,” in Computer Aided Verifica-tion, ser. Lecture Notes in Computer Science, T. Ball and R. B. Jones,Eds. Berlin, Germany: Springer, 2006, vol. 4144, pp. 249–262.

[48] R. Alur and D. Dill, “A theory of timed automata,” Theoret. Comput.Sci., vol. 126, no. 2, pp. 183–235, 1994.

[49] J. Bengtsson and W. Yi, “Timed automata: Semantics, Algorithms andtools,” in Lectures on Concurrency and Petri Nets, ser. Lecture Notesin Computer Science, J. Desel, W. Reisig, and G. Rozenberg, Eds.Berlin, Germany: Springer, 2004, vol. 3098, pp. 87–124.

[50] J. S. Ostroff and W. M. Wonham, “A framework for real-time dis-crete event control,” IEEE Trans. Autom. Control, vol. 35, no. 4, pp.386–397, Apr. 1990.

[51] S. Jiang, Z. Huang, V. Chandra, and R. Kumar, “A polynomial algo-rithm for testing diagnosability of discrete-event systems,” IEEE Trans.Autom. Control, vol. 46, no. 8, pp. 1318–1321, Aug. 2001.

[52] T.-S. Yoo and S. Lafortune, “Polynomial-time verification of diag-nosability of partially observed discrete-event systems,” IEEE Trans.Autom. Control, vol. 47, no. 9, pp. 1491–1495, Sep. 2002.

[53] P. Bouyer, F. Chevalier, and D. D’Souza, “Fault diagnosis using timedautomata,” in Foundations of Software Science and ComputationalStructures, ser. Lecture Notes in Computer Science, V. Sassone,Ed. Berlin, Germany: Springer, 2005, vol. 3441, pp. 219–233.

[54] , W. Hamscher, L. Console, and J. de Kleer, Eds., Readings in Model-based Diagnosis. San Mateo, CA: Morgan Kaufmann, 1992.

[55] N. Bauer, S. Engell, R. Huuck, S. Lohmann, B. Lukoschus, M.Remelhe, and O. Stursberg, “Verification of PLC programs given assequential function charts,” in Integration of Software SpecificationTechniques for Applications in Engineering, ser. Lecture Notes inComputer Science, H. Ehrig, W. Damm, J. Desel, M. Große-Rhode,W. Reif, E. Schnieder, and E. Westkäper, Eds. Berlin, Germany:Springer, 2004, vol. 3147, pp. 517–540.

[56] E. M. Clarke and B.-H. Schlingloff, “Model checking,” in Handbookof Automated Reasoning, J. A. Robinson and A. Voronkov, Eds.Cambridge, MA: Elsevier Science and MIT Press, 2001, vol. 2, pp.1635–1790.

[57] M. Knotek, Z. Simeu-Abazi, and F. Zezulka, “Fault diagnosis based ontimed automata: Diagnoser verification,” in Proc. IEEE IMACS Multi-conf. Computation Eng. Syst. Applications, Oct. 2006, pp. 889–893.

[58] M.-L. Yeh and C.-T. Chang, “An automaton-based approach to eval-uate and improve online diagnosis schemes for multi-failure scenariosin batch chemical processes,” Chem. Eng. Res. Design, vol. 89, no. 12,pp. 2652–2666, Dec. 2011.

Eric Gascard received theM.S. and Ph.D. degrees incomputer science from the Aix-Marseille University,Marseille, France, in 1997 and 2002, respectively.He is an Associate Professor with the Polytech

Department, Joseph Fourier University, Grenoble,France, where he teaches imperative programming,object-oriented programming, UNIX systems pro-gramming, theory of automata and formal languages.His research interests include diagnosis of discreteevent systems and formal verification.

Zineb Simeu-Abazi received the Ph.D. degree incomputer science and automation from the InstitutNational Polytechnique de Grenoble, Grenoble,France, in 1987, and holds an accreditation to be aresearcher and supervisor (HDR) in 1998.She is an Associate Professor with the Polytech

Department, Joseph Fourier University, Grenoble,France, where she teaches control processing, au-tomation and industrial engineering, dependability,and industrial maintenance. She has taken scientificresponsibility of French and International projects

and groups. Her research interests include modeling, control and dependability.She is particularly interested in the on line maintenance, diagnostic, recycling,and performance evaluation fields.Dr. Simeu-Abazi is a President of the scientific council of diag21 association.

Documents

Modular Modeling for the Diagnostic of Complex Discrete-Event Systems