Designing Fault-Tolerant Autonomous Systems with Adaptive Supervisory Control

Reggie Davidrajuh Electrical and Computer Engineering

University of Stavanger Stavanger, Norway

E-mail: reggie.davidrajuh@uis.no

Abstract— This paper presents a new approach for designing fault-tolerant systems using adaptive supervisory control. By this approach, firstly, a systemic study of the probable failures is conducted. Secondly, for every probable failure, the corrective measures (supervisory controllers) are synthesized. Thirdly, when the system is running, an adaptive controlled system is proposed where the supervisor chooses the most appropriate controller if any system failures happen. The approach proposes use of Petri net based supervisory controllers. A case study is also presented that shows how the proposed approach can be used to design adaptive supervisory control using the tool GPenSIM; the case study is about a fault-tolerant car washing facility.

Keywords- Fault-tolerant systems; Supervisory control; Petri net; discrete event systems; GPenSIM

I. INTRODUCTION

As ever increasing number of autonomous computing and communications systems become integral part of our lives, it has become necessary to evaluate the safety and security of these systems. Though these autonomous systems offer many benefits such as faster service, cheaper, safer and more secure, systems failures do cause human lives and material damages.

There is a great deal of research done on fault-tolerant systems, adaptive systems, intelligent systems, and so on, to minimize material damages and to save human lives if and when system failures occur. In this work, a new approach is proposed that takes a holistic view, starting from the system analysis for any probable failures, and finalizing with the adaptive controller that chooses appropriate control actions based on the situation.

This work proposes an approach for design of fault-tolerant systems that consists of many stages: first, a holistic systemic study of the probable failures is conducted. Second, for every probable failure, the corrective measures are synthesized; supervisory control based controllers are used as the corrective measures. Third, when the system is running, an adaptive controlled system is proposed where the supervisor chooses the most appropriate controller if any system failures happen.

In this work: section-II introduces the basics issues like Petri nets, supervisory control, fault-tolerance and total system shutdown. Section-III presents the new approach. Section-IV presents a case study showing the proposed approach can be put into action; the case study is about fault-tolerant control of a simple car washing facility.

II. BACKGROUND

This section introduces the following basic issues: Petri nets, supervisory control, fault-tolerant systems, and total system shutdown. Due to brevity, only brief introduction to these basic issues are given. Interested readers wanting more in-depth knowledge are referred to the references indicated in the following subsection.

A. Petri Nets Petri net is widely used as a tool for modeling, simulation

and analysis of discrete event systems. Petri net is widely used both in the research and in the industrial setting, due to the fact that Petri net is easy to use and comes with a handful of mathematical tools for analysis that are also easy to use.

Petri net is a bipartite graph, consisting of two types of elements: places which represent passive elements (e.g. buffers) and transitions which represent active elements (e.g. production machines). Transitions consumer input tokensfrom input places and deposits output tokens into output places. In addition to the places and transitions, ordinary P/T Petri net also defines arcs [1-2]; arcs connect places to transitions and vice versa. The connections between the elements can be represented by a matrix D known as the incidence matrix; incidence matrix is essential for computing supervisory controllers.

B. Supervisory Control Supervisory control is a methodology for automatic

control of discrete event systems. Despite its simple mathematical background and closeness of its models to the real-life systems, acceptance of supervisory control as a feedback control technique is low; studies point out that the main reason for this low acceptance is the lack of tools that are easy to use [3]. In the case study done at the end of this paper, a Petri net simulator known as GPenSIM is used to synthesize supervisory controllers for discrete event systems.

This work uses Petri nets based supervisory control techniques only; references [4-5] present Petri nets based supervisory control in detail. There are supervisors based on other methodologies too, like finite automata based supervisors. Finite automata based supervisors that have been devised and successfully applied for some industrial control systems [6-7]. However the fact that models based on automata can easily grow to infinite size makes this approach impractical for many practical problems [5]. Unlike automata, Petri nets do not suffer from the infinite model size. Petri net models present simple graphical view for the

2012 UKSim-AMSS 6th European Modelling Symposium

978-0-7695-4926-2/12 $26.00 © 2012 IEEE

DOI 10.1109/EMS.2012.73

174

2012 UKSim-AMSS 6th European Modelling Symposium

978-0-7695-4926-2/12 $26.00 © 2012 IEEE

DOI 10.1109/EMS.2012.73

174

2012 UKSim-AMSS 6th European Modelling Symposium

978-0-7695-4926-2/12 $26.00 © 2012 IEEE

DOI 10.1109/EMS.2012.73

185

user and also simple linear algebraic tools for computations; hence, Petri net are more suitable for developing supervisory control of discrete event systems [5].

C. Fault-Tolerance and Total System Shutdown Figure-1 shows the modes of operation of a fault-tolerant

system. Figure-1 depicts that there are three modes of operations: normal operating mode, auxiliary operating mode, and total system shutdown.

Let’s assume that system is running on the normal operating mode, in which everything is working as expected. When the system detects changes in the environment e.g. some failures, it will determine whether it should change the controller accordingly in order to face the challenges; if there is a controller suitable for the new situation, then it will be used and the system enters into auxiliary mode of operation. If no controller is available to tackle the failures, then the system enters into shutdown mode. If the system shutdown is the only possibility, then before entering the shutdown mode, the system may activate a number of activities like sending warning signals to the appropriate channels, recording the environmental inputs (failures) and the current status, etc. [8].

A system in shutdown mode may be switched back to normal operating mode, either by itself (by monitoring the environment and resuming operation when the signals from the environment suggest so) or by an external triggering event. When a wake-up signal occurs, the system will perform recovery procedures, such as data restoring, and then resume the normal operating mode [8].

III. THE NEW APPROACH

The approach proposed in this section for designing

fault-tolerant autonomous systems with adaptive supervisory control. The proposed approach consists of the following four stages:

1. Modeling the discrete event system with Petri nets: This stage is about construction of a Petri net model for the discrete event system. In the resulting Petri net model, transitions represent active devices that can cause failures

2. Failure identification: in this stage, the sources for all the possible failures are identified and classified

3. Building the depository of supervisory controllers: for all the possible failures identified in the previous stage, supervisory controllers are built, if possible

4. Implementation stage: the controlled system will be equipped with a bank of controllers to face any eventual failures

The stages are explained in the following subsections.

A. Model Building: The Petri net model of the Discrete Event System Usually, building a Petri net model of a discrete event

system is straightforward [9]. For example, figure-4 shows the Petri net model of the discrete system ‘automatic washing facility’ depicted in figure-3. The only requirement in the Petri net model building is that the elements that can cause failures must be represented as transitions in the Petri net model; otherwise (if active elements are represented by places as some Petri net simulators allow), it will be not possible to develop supervisory controllers to tackle the failure.

B. Learning Process: Taking Holistic view on System Failures

Signals from the environment

Normal Operating

Mode

Total System

Shutdown

Auxiliary Operating

Mode

some fai

lures

detect

ed:cha

nge

ofcon

troller

failur

esare

fixed:

load the

defaul

t contr

oller

adverse failures detected:

no controller available

more system failures:no controller available

Resumption/reactivation:

load defaul t cont roller

some failuresfixed:load relevant controller

Fig.1: The modes of operation of fault-tolerant systems

175175186

This stage is the most important stage as all the sources for failure will be identified. Some of the sources strike alone and some others fail as a group. For example, in the automatic washing facility shown in figure-3, one of the entrances can fail to open (or close), two or more of these can fail, and sometimes, all the entrances can also fail. It is important to list all the possibilities for failure so that when developing the controllers all these failures will be accounted for.

C. Realization of a Bank of Supervisory Controllers For each system failure identified in the previous

subsection, a set of conditions will be established to recover from the failure. These conditions will be used as ‘constraints’ to develop the relevant supervisory controller.

In the terminology of supervisory control, there are two types of failures:

1. Uncontrollable events: one can observe these events (like the door is opened), but cannot control them (opened door cannot be closed)

2. Unobservable events: these failures are of more serious nature as we don’t have any information about the event; for example, due to system failure, we don’t know whether the door is opened or closed. Unobservable events are also uncontrollable; however, the reverse is not necessarily true

Developing supervisory controllers to confront system failure is easy, if we know which events are causing the malfunction:

New controller = function of (current state of the system + information about the malfunctioning events) �� Current state of the system refers to the tokens in

different places of the Petri net model �� Information about the malfunctioning events can be

broken into two groups: set of uncontrollable events, and set of unobservable events

When developing supervisory controllers for each failure identified in the previous subsection, there are three types of controller results:

1. For normal operating mode (with the assumption that everything works normally), the default controller will be used.

2. When some failures occur, some specific controllers will be required to tackle the situation.

3. For some failures, there will be no controller that can tackle the situation. In this case, total system shutdown should be evaluated.

D. Implementing Adaptive Supervisory Control During the final stage, the controller will be put into

practice. When the controlled system is up and running, whenever a system failure occurs, appropriate controller will be loaded into the control unit; this can be done in two modes: 1) online mode, and 2) off-line mode; see figure-2.

In off-line mode, all the controllers are already developed and available in the controller bank. In the online mode, the controller will be developed only when a situation necessitate a new controller. Of course, for on-line mode, the embedded processor that is running the control system and

the software on it should be capable of developing a new controller whenever it becomes necessary. GPenSIM is a real-time controller that is capable of developing supervisory controllers online [10; 11]. GPenSIM is used in the case study given in the next section.

1. Decide the appropriate contrtoller

A) Off-line controller implementation

Control unit

Supervisor Environmental inputs

Bank of pre-compiled Controllers

2. Load the contrtoller

Compile the appropriate contrtoller and load into

the control unit

A) Online controller implementation

Control unit

Supervisor Environmental inputs

Fig.2: Implementing adaptive supervisory controllers

IV. CASE STUDY

The case study is about an automatic car washing system where four cars can be washed at a time (figure-3). Though most of the mechanisms are controlled by an automatic controller, a few functionalities have their own controller circuits; e.g. the main exist and the exits from individual wash bays are equipped with automatic doors that open for any approaching vehicles by themselves; they don’t need to be controlled by the automatic controller system.

Some characteristics of this automatic car washing system (figure-3):

1. Arrival of vehicles: It is assumed that the arrival of vehicles in front of the wash area is arbitrary. The vehicles queue up outside the main entrance of the wash area.

176176187

2. Entering the wash area: There are four wash bays available. Even if the four wash bays are occupied, up to four more vehicles will be allowed to enter into the wash area and wait in the designated area until any wash bay become free

3. Entering the wash bay: on seeing an empty wash bay, a vehicle can drive up to the bay entrance, which will be opened for an approaching car, only if the bay is not occupied

4. Washing: washing starts immediately after occupation of the bay by a vehicle

5. Leaving the wash bay: A vehicle in the wash bay area can only leave the bay through the exit door; the exit door will always open for an approaching vehicle, even if the washing cycle is not complete

6. Leaving the wash area: A vehicle can leave the wash area through the main exit door, which will always open for an approaching vehicle

Main Exit

Wait area for max. 4 cars

Main entrance

Wash Bay – 1

Wash Bay – 2

Wash Bay – 3

Wash Bay – 4

entrance -1 entrance -2 entrance -3 entrance-4

exit-1 exit-2 exit-3 exit-4

Car wash queue

Figure-3: Automatic car washing facility

Figure-4 shows the Petri net model of the automatic car washing system with four wash bays. Table-I explains the places and the transitions involved in the model.

TABLE I. INTERPRETATION OF PLACES AND TRANSITIONS

Label Explanation tARR Arrival of vehicles before main door pARR Vehicles have arrived at the door tENT Entering through the main door pENT Vehicles entered into wash area tOBi Vehicle occupying bay-ipOBi Bay-i is occupied & washing going-on tLBi Vehicle leaving bay-ipEXT About to leave the wash area tEXT Leaving the wash area pDEP Departed from wash area

In order to evoke the synthesis of the controller, one needs to define the following:

1. The set of constraints, 2. The set of uncontrollable transitions, and 3. The set of unobservable transitions

tEXT

pDEP

tARR

pARR

Parking lottENT

pENT

tOS1

pOS1

tLS1

pEXT

tOS2

pOS2

tLS2

tOS3

pOS3

tLS3

tOS4

pOS4

tLS4

Fig.4: Petri net model of the automatic car washing system

A. The Constraints The code shown below as figure-5 presents the five

constraints: constraints-1 to -4 restricts only vehicle each in wash bays 1-4 (physical constraints); constraints-5 allows a maximum of four vehicles to wait inside the wash area when all the four spaces are occupied (physical constraint).

Fig.5: Defining the constraints

% Constraints constr1.l = {'pOB1',1}; constr1.b = 1;constr2.l = {'pOB2',1}; constr2.b = 1;constr3.l = {'pOB3',1}; constr3.b = 1;constr4.l = {'pOB4',1}; constr4.b = 1;constr5.l = {'pENT',1}; constr5.b = 4;constraints = [constr1, constr2, constr3, constr4, constr5];

177177188

B. The Uncontrollable Transitions Uncontrollable transitions represent the events that

cannot be controlled by the supervisor. For example: it is already stated that the arrival of vehicles outside the wash area is arbitrary; thus, the transition tARR representing this event is uncontrollable. Similarly, vehicle are allowed to exit the wash area freely, thus the transition representing this event tEXT is thus uncontrollable. Hence, the set of uncontrollable transitions can be defined as follows:

set_of_uncontrollables = {‘tARR’, ‘tEXT’}

Process

tENT

tOB1

tLB1

tOB2

tLB2

tOB3

tLB3

tOB4

tLB4

Controller

slack3

slack1 slack2

slack4

slack5

Fig.6: The controller A for normal operation (the places of the process are not shown here)

C. The Unobservable Transitions Unobservable transitions represent the events that cannot

be monitored (hence cannot be controlled either) by the supervisor. For example, if the detection sensor at the gate malfunctions, it will be not possible to detect the arrival of vehicles outside the wash area. Thus, tENT becomes unobservable.

Let us assume, for the time being, that all the transitions except tARR and tEXT are observable. Thus, the set of unobservable transitions can be defined as follows:

set_of_unobservables = {‘tARR’, ‘tEXT’}

D. The Controller for Normal Operation Once the constraints, the set of uncontrollable transitions

and the set unobservable transitions are defined, synthesis of the controller becomes straightforward. In GPenSIM, one have to pass the following parameters to the function ‘supervisor’: 1) static Petri net graph (‘png’), 2) the initial dynamics (‘dyn’) like initial tokens, expected firing times of transitions, etc. 3) the sets of constraints, 4) the set of uncontrollable transitions, and 5) the set of unobservable transitions; the code below evokes the synthesis of the controller:[png1,dyn1,ok] = supervisor(png, dyn,

constraints, set_of_uncontrollables, set_of_unobservables)

The output of the function is the controller given as a pair (png1, dyn1), where png1 is the controlled system consisting of both the process and the controller unit, and ‘dyn1’ is the initial tokens of the controller. The third output parameter ‘ok’ is the status of the synthesis indicating whether the synthesis was successful (‘ok’ is true) or not (‘ok’ is false). Figure-6 shows the controller (controller ‘A’) for normal operations when no system failure occurs; the internal places of the process (pOB1 - pOB4) are not shown in figure-6. Controller A consists of five slack places; slacki, i = 1:4, with one initial token each controls the bay-i so that there will be at most one vehicle inside the bay at any time. Slack5 with four initial tokens controls the wait area so that there will a t most four vehicles in the wait area.

E. The Controllers when failures occur There are a total of eleven transitions in the Petri net

model: �� Two of the transitions tARR and tEXT are special as

they are inherently uncontrollable and are assumed to unobservable.

�� Transition tENT is common for all vehicles entering into the wash area

�� Transitions tOBi and tLBi are relevant for wash bay-‘i’ only.

The table-II below shows the possibilities for any of the transitions to become uncontrollable or unobservable.

TABLE II. INTERPRETATION OF PLACES AND TRANSITIONS

CaseNumber

Uncontrollable Transitions

Unobservable Transitions

Controller

1 - - A2a tENT - (not possible) 2b - tENT (not possible) 3 any one tOBi - B4 - any one tOBi C5a more than one

tOBi- (not possible)

5b - more than one tOBi

(not possible)

6 one or more tLBi

- A

7 - any one tLBi D (limited functionality)

8 - more than one tLBi

(not possible)

There are a total of eight cases identified in the table-II: Case-1 is the normal operation of the cash wash, in which

only tARR and tEXT are unobservable (thus uncontrollable too). For case-1, controller-A (shown in figure-6) is suffice for normal operation. In case-6 too, controller A will do the job. In case-6, one or more of the tLBi become uncontrollable; even with this failure, controller A will do the job as the control mechanism does not depend on the controllability of any tLBi. In all other six cases, in addition to tARR and tEXT, one or more transition will be assumed

178178189

as either uncontrollable or unobservable, demanding new controller for that case.

In case-2, transition tENT becomes either uncontrollable or unobservable. For this situation, no controller can be made to satisfy the constraints; thus, total system shutdown is the only appropriate action. Similarly, total system shutdown is the only appropriate action for the following cases too: in case-5 where more than one tOBi becomes uncontrollable or unobservable, and in case-8 where more than one tLBibecomes unobservable.

In case-3, if any one of the tOBi becomes uncontrollable, a new controller (controller-B) is needed. Similarly, case-4 in which any one of the tOBi become unobservable necessitates the use of a new controller-C.

Case-7 is special: if any one of tLBi becomes unobservable, a new controller (controller-D) is needed. Though controller-D satisfies all the five constrains, if offers only a limited functionality: the controller-D may shutdown completely any wash bay that has malfunctioning events, even shutdown the wash facility completely, effectively performing total system shutdown.

F. The Results: System Shutdown proposed for the following situation: From table-II, one can be easily concluded that if any one

of the following situations occurs, then total system shutdown should be considered for human safety and for minimization of material damage:

�� tENT is uncontrollable or unobservable: the sensor attached to the main entrance is defective (unobservable) and/or the main door cannot be opened (uncontrollable)

�� more than one tOBi become uncontrollable or unobservable: the sensors and the door mechanism is malfunctioning at one or more of the wash bays

�� more than one tLBi become unobservable: more than one of the exits of the wash bays malfunctions

In addition, total system shutdown may be considered when any one tLBi becomes unobservable, as the controller-D only provides a limited functionality in this case.

V. CONCLUSION

This work proposes a new approach for designing fault-tolerant discrete event system with adaptive supervisory control. The approach consists of the four stages: 1) creating a Petri net model of the discrete event system, where transitions represent active devices that can cause failures, 2) failure identification stage in which all the possible failures are identified and classified, 3) developing a set of supervisory controllers, one controller for each possible failures identified in the previous stage, and 4) implementation stage in which the controlled system will be put into action, equipped with a bank of controllers to face any eventual failures.

This work also gives emphasis to total system shutdown; though it may sound unconstructive, in many situations, system shutdown becomes the only option to avoid the

potential to harm humans and cause material damages when the system fails to perform, or perform incorrectly.

There are several works on Petri net based supervisory control; nearly all of them use structural invariants, more specially – place invariants – for developing the control module. Specifically, ‘generalized mutual exclusion constraints (GMEC)’ is a simple and straight-forward approach for developing supervisors [12]. In this paper, the treatment of supervisory control theory and its application for controller synthesis basically follows the approach proposed by the following works: [4-5].

The case study uses a Petri net simulator known as GPenSIM for realizing the adaptive supervisory control system; due to brevity, the GPenSIM implementation is not shown in this paper; interested readers are encouraged to look into implementation (program code) at the link given as [13].

Limitations of this work: this work does not propose a general methodology for identifications of failures in the second stage of the proposed approach. The case study presented in this work is also crude and does not discuss real-time issues like recover-time, latency-time, etc.

REFERENCES

[1] T. Murata. “Petri Nets: Properties, Analysis, and Applications”. Proceedings of the IEEE, 77 (4), pp. 541-580, 1989

[2] M. Silva, E. Teruel, and J. M. Colom. “Linear Algebraic Techniques for the Analysis of P/T Net Systems”. In Lectures in Petri Nets I: Basic Models. Springer, 1998

[3] J. M. Colom. “Some suggestions for future research”. L20 – Lecture notes for the PhD course on Petri nets, UPC, Barcelona, 14-25 May 2012

[4] M. V. Iordache and P. J. Antsaklis. Supervisory control of concurrent systems: a Petri net structural approach. Boston: Birkhauser, 2006

[5] J. O. Moody and P. J. Antsaklis. Supervisory Control of Discrete Event Systems Using Petri Nets. Springer verlag, 1998

[6] P. Ramadge and W. Wonham. “The control of discrete event systems. In Discrete event dynamic systems”, Proceedings of the IEEE. v77 i1. 81-98, 1989

[7] W. Wonham and P. Ramadge. “On the supermal controllable sublanguage of a given language”, SIAM Journal on Control and Optimization, v.25 n.3, p.637-659, May 1, 1987

[8] C. Hwang and A. Wu. “A Predictive System Shutdown Method for Energy Saving of Event-Driven Computation”. ACM Transactions on Design Automation of Electronic Systems, Vol. 5, No. 2, April 2000

[9] R. Davidrajuh and B. Lin. “Exploring Airport Traffic Capability Using Petri Net based Model”, Expert Systems With Applications (ESWA), 38 (2011) pp. 10923-10931

[10] R. Davidrajuh. “Extending a Petri Net Simulator as a Real-Time Control Simulator”. IEEE International Conference on Control System, Computing and Engineering (ICCSCE 2011), Penang, Malaysia, November 25-27, 2011

[11] GPenSIM user Manual. Available at: http://davidrajuh.net/gpensim [12] A. Giua, F. DiCesare, and M. Silva. “Petri net supervisors for

generalized mutual exclusion constraints”. Proc. 12th IFAC World Congress, Sidney, Australia, 1993, pp. I: 267-270

[13] R. Davidrajuh. “Case study on adaptive supervisory control”. Available: http://davidrajuh.net/gpensim/2012-adaptive-supervisors

179179190