Synthesis and Implementation of Distributed Supervisory Controllers with Communication Delays
R.H.J. Schouten, L. Moormann, J.M. van de Mortel-Fronczak, J.E. Rooda
aa r X i v : . [ c s . F L ] F e b Synthesis and Implementation of Distributed Supervisory Controllerswith Communication Delays
R.H.J. Schouten, L. Moormann , J.M. van de Mortel-Fronczak , and J.E. Rooda Abstract — In literature, extensive research has been donewith respect to synthesis of supervisory controllers. Suchsynthesized supervisors can be distributed for implementationon multiple physical controllers. This paper discusses a methodfor distributing a synthesized supervisory controller. In thismethod, dependency structure matrices are used to distributea system, the supervisor is then distributed accordingly, usingexisting localization theory. The existence of communicationdelays between supervisory controllers is unavoidable in adistributed application. The influence of these delays on thebehavior of a supervisor is therefore studied using delayrobustness theory. This paper introduces the use of mutexalgorithms to make the distributed supervisor delay-robust. Acase study is used to demonstrate the method and hardwarein the loop testing is used to validate the resulting distributedsupervisor.
I. INTRODUCTIONDiscrete Event Systems (DES) [1] can be found in arange of domains. Examples are manufacturing systems,infrastructural systems and logistic systems. The behavior ofsuch systems is described by discrete events, for examplea button is pushed or lamp is switched on. In order toassure only the desired behavior of the system occurs, acontroller is needed. Such a controller is called a supervisorycontroller. Ramadge and Wonham introduced SupervisoryControl Theory (SCT) in [2], which provides a method tosynthesize such a supervisory controller. This method usesa model of the uncontrolled system, which describes whatthe system can do, and a model of the requirements, whichstates what the system is allowed to do.Synthesized supervisory controllers can be implementedon a physical platform, for example a ProgrammableLogic Controller (PLC). The memory of such a PLC islimited, therefore it is sometimes not possible to control alarge scale system with a single controller. Using multiplePLCs can raise the total memory capacity, however adistributed supervisory controller is required for such animplementation. A system is then not controlled by a singleglobal controller, but by multiple local controllers that areable to communicate with one another. Using a distributedsupervisory controller implemented on multiple PLCs insteadof a supervisory controller implemented on a single PLCmight reduce PLC cycle times, as the computing powercan be increased and the size of the controller can bereduced. It should be noted, however, that in a distributed *This work was supported by Rijkswaterstaat, part of the Dutch ministryof infrastructure and water management Department of Mechanical Engineering, University of TechnologyEindhoven, The Netherlands [email protected] implementation, communication might be required, whichcan increase the total required memory and computationpower.This paper discusses a method to synthesize andimplement a distributed supervisory controller while takinginto account communication delays. The paper is structuredas follows. First the existing relevant theory from literatureis discussed concerning the topics of SCT, distributedsupervisory control, Dependency Structure Matrices (DSM),localization, and mutual exclusion algorithms which are usedto counteract the effects of communication delays on theorder in which events occur. Next, a case study is introducedin Section III. The method introduced in this paper isthen discussed in two main steps. First, DSMs are usedto distribute the uncontrolled system, i.e. the plant. Second,the acquired distribution of the system is used to distributethe supervisor for that system accordingly. In Section VI,hardware in the loop testing is used to validate the distributedsupervisor for the case study. Final remarks and conclusionsare given in Section VII.II. PRELIMINARIES
A. Supervisory Control Theory
In the context of SCT, a supervisor can be synthesizedfrom a model of the plant, i.e. the uncontrolled system, anda model of the requirements. SCT notations and definitionsas discussed in this section are taken from [1] and [3]. In thispaper, DES are modeled using Finite Automata (FA). A FAis defined by a 5-Tuple: ( X, Σ , ξ, x , X m ) . Here, X denotesa finite set of states and Σ denotes a finite set of events.Event set Σ is partitioned into two disjoint sets Σ c and Σ u ,controllable events and uncontrollable events, respectively.Controllable events may be disabled by a supervisor, whereasuncontrollable events may not. Furthermore, ξ : X × Σ → X is the transition relation for events σ ∈ Σ . x o denotes theinitial state and X m the set of marked states.The set of all finite strings of events over Σ , includingthe empty string ǫ , is denoted by Σ ∗ . The set of possiblestrings in FA G is referred to as its language L ( G ) . Formally: L ( G ) = { s | s ∈ Σ ∗ , ξ ( x , s )! } , where ξ ( x , s )! denotes thatthe string s of events leads to a state in X from the initialstate x . The set of strings leading to a marked stated isknown as the marked language of G denoted as L m ( G ) , ormore formally: L m ( G ) = { s | s ∈ Σ ∗ , ξ ( x , s ) ∈ X m } . Notethat based on the given definitions L m ( G ) ⊆ L ( G ) .A projection is a frequently used opreation in SCT. Forthe definition of projections, proposed by [1], consider eventset Σ s ∈ Σ of FA G . The projection P s , from Σ ∗ to Σ ∗ s ,eplaces all events in Σ \ Σ s by ǫ . Another frequently usedoperation is the synchronous product, denoted by || . Thesynchronous product of FAs G and G , is G || G =( X × X , Σ S Σ , ξ, ( x , , x , ) , X m, × X m, ) , where: ξ (( x , x ) , e ) := ( ξ ( x , e ) , ξ ( x , e )) if ξ ( x , e )! ∧ ξ ( x , e )!( ξ ( x , e ) , x ) if ξ ( x , e )! ∧ e / ∈ Σ ( x , ξ ( x , e )) if e / ∈ Σ ∧ ξ ( x , e )! undefined otherwise The DES discussed in this paper are composed systems. Acomposed system G is defined by the synchronous productof a set of subplants G i , with i ∈ I = (1 , , ..., n ) , i.e. G = || i ∈ I G i . A product system is defined by [4] as a composedsystem where all subplants have disjoint alphabets. In [5], theMost Refined Product System (MRPS) of a composed systemis defined as the product system with the largest number ofsubplants that do not share events. A composed system canbe transformed into a MRPS using the procedure in [6].The supervisor synthesis procedure uses a plant model anda requirement model, to derive a supervisor. This supervisordisables controllable events, to ensure the system undersupervision satisfies a number of properties. These propertiesare stated by [4] as safety, nonblockingness, controllabilityand maximal permissiveness.Safety describes that the supervisor meets all therequirements stated by the requirement model. Safety doesnot state the correctness of the requirements, it only statesthat the supervised system meets the requirements. Asupervised system that is nonblocking can always reacha marked state from any state reachable from the initialstate, or formally, any reachable state is coreachable.Nonblockingness is confirmed if the prefix closure L m ( S ) = L ( S ) [7]. Controllability means that no uncontrollable eventsare disabled by the supervisor. A maximally permissivesupervisor allows all behavior that satisfies the propertiessafety, nonblockingness and controllability.The supervisor synthesis procedure described in [2] resultsin a monolithic supervisor where all requirements arecaptured. When the complexity of the system increasesso does the computational complexity of synthesizinga monolithic supervisor. Different synthesis methods (orsupervisor architectures) have been proposed in literature todecrease the computation times of synthesizing supervisors.The first alternative to monolithic synthesis is modularsynthesis as proposed in [8]. In modular synthesis, a localsupervisor for each requirement in the requirement modelis derived. For large scale systems, synthesis of localsupervisors is computationally less complex than for a singlemonolithical supervisor. The conditions for the existenceof a nonblocking modular supervisor are stronger than fora monolithic solution, as stated by [8]. Namely to assurenonblockingness of the global supervisor, local supervisorsneed to be non-conflicting. [8] defines conditions for localsupervisors such that they are non-conflicting. If the localsupervisors are non-conflicting, the global supervisor is thesynchronous product of all the local supervisors.Decentralized supervisors, as discussed in [9], are similarto modular supervisors. Each decentralized supervisor observes a subset and controls a subset of the event set ofthe system. For a system with two supervisors, the globalobservable set is defined as Σ o = Σ o, ∪ Σ o, , where Σ o,i the set of events observable by supervisor i and the globalcontrollable set is defined as Σ c = Σ c, ∪ Σ c, , where Σ c,i theset of events controllable by supervisor i . The supervisors arefused into one supervisor using a fusion rule. The supervisorscan be fused by intersection, union or a combination of both.If local supervisors are defined such that events which arenot in their controllable event set, i.e. Σ c \ Σ c,i , are alwaysenabled, intersection is used. If these events are alwaysdisabled, union is used. If Σ c is partitioned into a set events Σ c,e that are enabled by default and a set Σ c,d that aredisabled by default, both union and intersection are used.It should be noted that a decentralized supervisor is not thesame as a distributed supervisor. A decentralized supervisoris implemented as a single supervisory controller, whereas adistributed supervisor is implemented as multiple supervisorycontrollers that are able to communicate.More recently a multilevel architecture has beenintroduced in [10]. The multilevel architecture uses aMultiLevel Discrete Event System (MLDES) which consistsof a tree-based structure. For each node in the tree, a localsupervisor that influences a set of subplants and satisfiesa subset of requirements is synthesized. The set of localsupervisors is nonblocking, safe, and controllable, however,maximal permissiveness is not guaranteed in multilevelsynthesis. B. Distributed supervisors
In literature, several contributions to the developmentof the distribution of supervisory controllers over multiplephysical controllers have been made. [11] models adistributed controller using petri nets. Petri nets are amodelling formalism alternative to FA. This controller isverified using the SESA model checker. No synthesisis done, however, the paper provides useful insights indistributing controllers and the required communicationbetween controllers. [12] discusses synchronization of eventsin DES using networked controllers. Networked controllersare similar to distributed controllers in the sense that multiplelocal controllers communicate to apply control action to aplant. However, in networked control each controller controlsa separate plant. The separate plants may have physicalcouplings. The developed method is used to enable multiplecontrollers to perform a synchronized task, for example tworobot arms picking up an object together. The controllers inthis case are autonomous and communicate with one anotherto perform the task synchronously.There have also been contributions in literature towardsacquiring distributed controllers through synthesis. [13]discusses a method for synthesizing and implementing asupervisory controller for safety PLCs. In safety PLCs, thecontroller consists of a regular and a safety controller, whichcommunicate through internal data buffers. The controllersare updated alternately, i.e. in a synchronized scan cycle. Thismethod is not used in this paper, as it is expected that thisolution is not scalable for larger numbers of controllers,because the synchronized way of updating controllers willintroduce increasingly large update delays. Moreover, thismethod of splitting a supervisor is designed specifically fora system with a set of regular and safety requirements. It isunclear how to translate this to a more general distributedsynthesis method.[14] introduces an aggregative method for synthesizing adistributed supervisor. There is no need for synthesizing aglobal supervisor (i.e. a supervisor for the entire plant andall its requirements) in this method, as local supervisors aresynthesized right away. Computation times can therefore berelatively low. This is a great advantage in the scalabilityof the method. In order to achieve global nonblockingness,abstractions of other local supervisors are used during thesynthesis of a local supervisor. Therefore the order in whichlocal supervisors are synthesized is important for both thecomputational complexity of the supervisor as well as forthe existence of a supervisor. [14] gives some guidelines tochoose an efficient ordering, however, it is unclear how tofind an optimal ordering. Moreover, the computations thatare needed are relatively complex.In contrast to the bottom-up approach of aggregatesynthesis, supervisor localization as done by [7] is a top-down approach to acquiring distributed supervisors. Firsta global supervisor for the entire plant is synthesized.A localized version of this global supervisor is thenimplemented for each component or component group. Theprovided method is a relatively simple way of obtaininga distributed supervisor. The behavior of this distributedsupervisor is equal to that of the global supervisor. Theconcept of localization is further discussed in Section II-D.Both the aggregative method of [14] and the localizationmethod of [7] do not discuss the effects of communicationdelays between local supervisors. [15] introduces asynthesis method for (non-distributed) supervisors witha known delay on its inputs and outputs. The effectsof communication delays can be similar for distributedsupervisors, therefore [15] gives some useful insights inthe effects of communication delays. In [16], a distributedsupervisor synthesis method is proposed which takes intoaccount the effects of communication delays. [16] statesthat more research is needed to reduce the amount ofcommunication required. This method is therefore not usedin this paper. [17] gives further insight in the effects ofcommunication delays for distributed supervisors created bylocalization. This topic is further discussed in Section V-B.
C. Dependency Structure Matrix
Dependency Stucture Matrices (DSM), as introduced by[18], provide a means to give insight in the dependencieswithin a process or system. A DSM is a square matrixwhere the components of a system are the elements ofboth the horizontal and vertical axis. Each entry in thematrix denotes a dependency between two components. [19]shows that DSMs can be used for DES, to give insight inthe dependencies between components within DES. A plant model and a requirement model are needed for the creationof such a DSM. The components of the plant model arelisted on the axes of the DSM. Through requirements in therequirement model, different components depend on eachother. These dependencies are shown in the DSM. Othertypes of dependencies, for example spatial dependencies, canalso be shown in a DSM.In a DSM, clusters of closely connected components canbe identified. When clustering components in a DSM, theorder in which the components are placed on the axesis changed and components within a cluster are grouped.The aim is to identify clusters in such a way that thenumber of dependencies between components within acluster is maximized and dependencies between componentsof different clusters is minimized. In literature, extensiveresearch has been done to provide efficient clusteringalgorithms as K-means [20] or spectral clustering [21], orby using more general optimization methods, for examplegenetic algorithms [22] or simulated annealing [23].Clustering DSMs can also be done using Markovclustering, which is shown by [24]. Markov clusteringcan create multiple hierarchical levels and can detect buselements. Bus elements are elements in the DSM that havea large number of dependencies. Markov clustering is arelatively complex algorithm that uses the four clusteringparameters α , β , µ and γ to tune the clustering of a DSM.Parameter γ is a threshold value for the number of detectedbus elements, increasing γ decreases the number of buselements. β and µ are both used to tune the cluster size andthe number of hierarchical levels. α has less influence on theclustering results [25]. [24] shows that Markov clustering isa scalable and versatile solution for clustering DSMs. D. Localization
Supervisor localization is introduced by [26] for FA. Ittakes a global supervisor
SUP = ( X, Σ , ξ, x , X m ) , whichis defined for a global plant G = ( Y, Σ , η, y , Y m ) . Plant G consists of component agents G k defined over disjointalphabets Σ k , k ∈ K with K an index set, where Σ =
S (cid:8) Σ k | k ∈ K (cid:9) . The global supervisor SUP is localizedinto local supervisors
LOC k for component agents G k . LOC k is a copy of SUP , where the controllable event set isadjusted to Σ kc = Σ c T Σ k . Events Σ \ Σ kc are uncontrollablein LOC k . All events in Σ c are controllable in exactlyone local supervisor. The observable event set of LOC k is not adjusted, i.e. a local supervisor can observe eventsthat are controlled by another local supervisor. Therefore,multiple local supervisors might interact to observe these socalled shared events. LOC k is defined such that it observesevents in Σ k directly from the plant. Events Σ \ Σ k arenot observed directly from the plant, but can be observedin other local supervisors through communication betweenlocal supervisors. In [26], it is assumed no communicationdelays occur.Using a monolithic global supervisor as a starting point forlocalization is often suboptimal as localization has to be donefor a relatively large supervisor. [27] shows that for largecale systems it is possible to use a more efficient method.In [27], a global supervisor is synthesized in a decentralizedmanner as discussed in [28], i.e. the global supervisoris the synchronous product of a number of decentralizedsupervisors and coordinators for nonblockingness. Instead oflocalizing the global supervisor for each component agent,only the decentralized supervisors that control events for acomponent agent are localized for that agent. It is possiblethat multiple decentralized supervisors control events in acomponent agent. In this case each of these supervisorsis localized. It is also possible that one decentralizedsupervisor disables events in multiple component agents,in that case the decentralized supervisor is localized foreach of those agents. The resulting local supervisors imposeglobal nonblockingness, safety, and controllability, if theoriginal global decentralized supervisor also imposed thesame properties.Similar to a decentralized supervisor, a multilevelsupervisor can be used. A supervisor obtained by multilevelsynthesis as described in [19], consists of a number ofsupervisors that disable events in subsets of agents. Foran example plant G consisting of 4 component agents G k ( k = 1 , , , , with a requirement model consistingof 8 requirements R i ( i = 1 , , ..., , multilevel synthesisis performed. The resulting MLDES tree is given in Fig. 1.The global multilevel supervisor is given by S = || i Sup i ,with i = 1 , , ..., . Note tat Sup does not contain anyrequirements, any requirements that refer to component G are already in Sup and Sup . (cid:127)€(cid:129)‚ (cid:127)€(cid:129) || (cid:129)(cid:127) (cid:129) || (cid:129)!€(cid:129) || (cid:129)! (cid:127)€(cid:129) (cid:127)€(cid:129) || (cid:129)(cid:127)"(cid:129) || (cid:129)!"(cid:129) || (cid:129)! (cid:127)€(cid:129)! (cid:127) (cid:129) || (cid:129)(cid:127) || (cid:129)!$ (cid:127)€(cid:129)" (cid:127)€(cid:129) || (cid:129)!%(cid:129) (cid:127)€(cid:129) (cid:127)"(cid:129) || (cid:129)!& (cid:127)€(cid:129)$ (cid:127) (cid:127)€(cid:129)% (cid:127) || (cid:129)!' Fig. 1: Multilevel supervisor exampleThe multilevel supervisor can now be localized formultiple component agents or groups of component agents.If for example a distribution of two agent groups is chosen,group 1 containing G and G and group 2 containing G and G , it is not necessary to localize the entire multilevelsupervisor. As group 1 is only controlled by supervisors Sup , Sup , Sup and Sup as depicted in Figure 1, onlythese supervisors need to be localized. Local supervisor LOC is the set of localized versions of supervisors Sup , Sup , Sup and Sup . Similarly, local supervisor LOC ,for group 2, is the set of localized versions of supervisors Sup , Sup , Sup and Sup . LOC now controls agents G and G while observing G , whereas LOC nowcontrols agents G and G while observing G .In [7], a localization algorithm is presented that createsan abstraction of the local supervisors, with the aim of reducing the complexity of the local supervisors such thatonly behavior relevant to the corresponding componentagent is observed. Creating the abstraction improves thelocal supervisors in the sense that the statespace of thesupervisor reduced. Moreover, the number of shared eventsand therefore the required amount of communication isreduced. In this paper, the algorithm is not used, as the localsupervisors derived from a multilevel supervisor, are alreadyrelatively small. The unabstracted local supervisors are usedinstead. E. Mutual exclusion algorithms
Mutual exclusion algorithms pose a solution to theproblem in concurrent programming where multipleprocesses try to enter a, so-called, ‘critical section’ of theirprogram simultaneously, while this is not allowed. Manysolutions have been proposed since the presentation of theDijkstra’s algorithm in [29]. [30] first introduced a solutionto the distributed mutual exclusion problem, where theprocesses do not share any memory.In most applications, mutual exclusion algorithms mustensure liveness, safety, and nonblockingness, as discussed in[31]. Liveness, sometimes referred to as starvation freedom,implies that a process requesting to enter its critical sectionis eventually allowed to do so. Safety implies that no twoprocesses can enter their critical section simultaneously. Analgorithm is nonblocking if it is deadlock free. Deadlock isthe situation where, in the algorithm, no action can be takenanymore, from the first moment of deadlock onward. Notethat the definitions of nonblockingness for mutual exclusionalgorithms and FA are similar, but not fully the same. Analgorithm is considered fair, if the first process to requestaccess is granted access the first. Some algorithms are ableto prioritize one process over another. Most algorithms aimto reduce the amount of communication, i.e. the number ofmessages required to get access to a critical section.Distributed mutual exclusion algorithms typically followeither a token-based (as for example in [32]) or a permission-based approach (as for example in [33]). Token-basedalgorithms, as defined in [34], use a mobile object, referredto as the token, which travels from process to process.The process in possession of the token is allowed toenter its critical section. As there is only one token,only one process is allowed to enter its critical sectionsimultaneously. Different network structures have beenproposed, as discussed in [31], in efforts to reduce theamount of communication. In permission-based algorithms, aprocess requests permission to enter its critical section fromall other processes or from a subgroup of other processescalled a quorum or coterie. [31] states that generally token-based algorithms need less communication than permission-based algorithms. Permission-based algorithms are generallymore suited for implementation of fairness or prioritization.A simple implementation for a mutual exclusion algorithmis a home-based token algorithm as discussed in [34]. Inthis algorithm, there exists one home process and a numberof other processes. The token normally resides at the home e q u e s t t o k e n R e q u e s t t o k e n R e t u r n t o k e n R e t u r n t o k e n R e c e i v e t o k e n R e c e i v e t o k e n Process 2Process 1 (Home)Process 3 TimeCritical section allowedToken not available Critical section allowed
Fig. 2: Home-based token passing mutual exclusionprocess. Any process can request the token from the homeprocess and the home process will then send the token therequesting process. When the requesting process leaves thecritical section it returns the token to the home process. Ifa process requests the token while the token is already inuse by some other process, the requesting process will beadded to a queue in the home process. This queue is a simpleFIFO queue. The home process will always send the token tothe first process in the queue as soon as possible. A processcannot enter the queue again if it is already in the queue. Thisalgorithm requires little communication as each process onlycommunicates with the home process. The process becomesinefficient if a large number of processes has to use the tokenoften and for a short amount of time, as the token needs tobe returned to the home process after every use instead ofmoving to the next process right away.Figure 2 shows an example case for a home-based tokenpassing algorithm. Process 1 is the home process whichinitially holds the token. Process 3 requests the token fromthe home process and receives it. Process 3 is now allowed toenter the critical section. Next process 2 requests the token,the token however is not available as the token is held byprocess 3. Process 1 adds process 2 to the queue. As process3 finishes using the critical section it returns the token to thehome process. The home process now checks the queue andsends the token to process 2. Process 2 is now allowed toenter the critical section and returns the token afterwards.III. C
ASE STUDY : P
UMP - CELLAR SYSTEM FOR TUNNELS
Throughout the remainder of this paper a case study isused to show an implementation of the discussed method.The case study concerns a pump-cellar system which is usedin traffic tunnels to collect rain water. In this case, the systemcontains 3 cellars and each of these cellars is equipped with2 pumps and 5 sensors, as depicted in Fig. 3. The 5 sensorsindicate when the water in the cellar has reached a certainlevel and the pumps are used to transfer water out of thepump-cellar. There are 2 main pump-cellars, which can pumpwater out of the system and 1 middle pumpceller, which canpump water to either of the 2 main pump-cellars. The CIF3[35] modeling language is used to model the system.
Pump 1
Sensors:level 1level 2level 3level 4level 5
Pump 2
Fig. 3: Pump cellar
A. Plant model
Each pump-cellar has a mode in which it operates, themode can be
Store , Empty or Off . Based on the mode ofthe tunnel the pumps should be on or off at certain waterlevels. The mode of the tunnel can be changed manuallyor automatically. Manual control is done through the useof 3 buttons. Automatic changes can be made based onthe state of the tunnel. The tunnel consists of 2 tubes,for which the automaton is shown in Fig. 8 (event namesare abbreviated here). Each of these tubes normally is inthe state Operational . In case of an emergency, due tofor example a car crash or fire, the state of each of thesetubes can be changed to
Emergency . After the emergencyis solved the state is changed to
Recovery and finally back to
Operational . Finally, the control mode, automatic or manual,is changed using 2 buttons.
Off Onc onc off
Fig. 4: Pump automaton
Off Onu onu off
Fig. 5: Sensor automatonIn Fig. 4 and 5, the automata of the models for thepumps and sensors are shown. Initial states are denotedby an arrow which does not originate in another state,double circles denote marked states, dashed and solid arrows ain 1 Main 2c MP2c MP1
Fig. 6: Pump direction automatondenote uncontrollable and controllable events, respectively.The pump direction of the middle pump-cellar is modeledas shown in Fig. 6, in state
Main1 water is pumped towardsmain pump-cellar 1 and in state
Main2 water is pumpedtowards main pump-cellar 2. The mode model is shown inFig. 7, event names are omitted here.
Empty StoreOff c s t o r e c e m p t y c o ff ce m p t y c o ff c s t o r e Fig. 7: Mode automaton
Operational EmergencyRecovery c e m . c r ec . ce m . c op . Fig. 8: Traffic tube automatonEach button is modeled as shown in Fig. 9, with a singleevent u push . Additionally for each set of buttons a monitorautomaton is created. There are for example 3 buttonscontrolling the mode of a pump-cellar:
ButtonEmpty , ButtonStore and
ButtonOff . The monitor automaton forthese 3 buttons is shown in Fig. 10. In this automaton, thebutton events are observed. The requirements are stated suchthat
Mode events are allowed when the button monitor is inthe relevant state. Event c done is only allowed when
Mode has reached the relevant state. Other button sets are modeledin a similar fashion. u push
Fig. 9: Button
IdleEmptyPushed StorePushedOffPushedEmpty.u push c doneStore.u pushc doneOff.u pushc done
Fig. 10: Button monitor automaton
B. Requirement model
A set of requirements is created to describe what behaviorthe controller should allow. For each pump-cellar, a number of requirements states when the pumps are allowed to turnon or off. When the
Mode of the pump-cellar is
Empty ,pump 1 is allowed to turn on when sensor level 2 is on andoff when sensor level 1 is off. Pump 2 is allowed to turn onwhen sensor level 3 is on and off when sensor 1 is off. In
Mode Store , pumps 1 and 2 can both turn on when sensorlevel 5 is on and can both turn off when sensor level 4 isoff. In
Mode Off the pumps can only turn off. The middlepump-cellar initially pumps water towards main pump-cellar1, the pump direction can be changed to main pump-cellar 2when in main pump-cellar 1 sensor level 5 is turned on andcan be changed back to main pump-cellar 1 if sensor level4 is off.All pump-cellars that are in automatic control mode areallowed to change their mode to
Store when a traffic tubeis in state
Emergency or Recovery and to
Empty whenboth traffic tubes are in state
Operational . All pump-cellarsthat are in manual control mode, should change their modeaccording to the buttons.The requirements are stated as event conditions. Notethat, these requirements can also be written as FA. Anexample of such a requirement is:requirement
Pump1.c on needs not
Mode.Off ;This requirement states that event
Pump1.c on is onlyenabled if the
M ode automaton in not in the state Off . Therequirements discussed in this section are all formulated inthis manner. Note that, for 1 event, multiple requirementsmay exist.IV. STEP 1: D ISTRIBUTING THE SYSTEM
The first step in acquiring a distributed supervisor isdistributing the system into clusters. For each cluster alocal supervisor can then be derived. Clusters can consistof for example events or requirements. In this paper,clusters of components are used, as this enables the useof multilevel synthesis based on this component clustering.The multilevel supervisor can then be localized to acquirelocal supervisors for each cluster of components. Moreover,clustering on component level gives the option of using amost refined product system (MRPS). Using the MRPS as abasis for clustering ensures that components that are closelyconnected, namely through shared events, are always in thesame cluster.After creating the MRPS for the system, a DSM is createdfor that MRPS. Different types of dependencies can beshown in a DSM. Dependencies can, for example, be definedbased on the fysical location of components or electricalconnections. Alternatively, a DSM can be created based oncontrol relations, which is done in this paper, following[19]. This minimizes the amount of communication neededbetween local supervisors. To create such a DSM firstDomain Mapping Matrices (DMM) P and P are created,which are rectangular matrices, see [24]. These DMMsshow relations between plant components and requirementsin the system. In the CIF3 language, requirements aresually stated as follows:requirement event needs condition ;Here, the event is some event in the system and condition is a boolean expression which can, for example, refer to oneor more states of one or more automata. P i,j = 1 whenrequirement j refers to an event of component i and P i,j =0 otherwise. P i,j = 1 when the condition of requirement j refers to an automaton of component i and P i,j = 0 otherwise. The DSM P can then be computed using P = P · P T .The acquired DSM can be clustered. Section II-Cdiscusses a number of clustering methods. Each of theseclustering methods can be used for clustering DSMs,however a number of characteristics of clustering algorithmsare desirable. Firstly, control over the number of createdclusters is needed, as for each cluster, a local supervisorwill be synthesized. Secondly, the size of the createdclusters needs to be controlled as this determines thenumber of components that need to be controlled by eachlocal supervisor. Lastly, the algorithm must be able tocluster systems with a large number of components anddependencies.In K-means clustering, the number of clusters can bedirectly controlled, however the cluster size cannot becontrolled. In spectral clustering, there is some control overthe number of clusters, however creating a specific numberof clusters can be inconvenient as the algorithm has tobe used iteratively. The optimization methods are quiteversatile, as control over the number of clusters and clustersize can be implemented. However, when analyzing largesystems, control parameters of the algorithms need to betuned very carefully. As the number of possible clusteringsincreases exponentially with the number of components, thecomputation times of the optimization algorithms increasesgreatly with the number of components. Markov clusteringhas been shown to be a scalable solution, where cluster sizeand the number clusters can be easily controlled throughtuning the clustering parameters α , β , µ and γ [24]. In thispaper, therefore, Markov clustering is used. A. Case study: Pump-cellar system
A DSM is created for the pump-cellar system introducedin Section III. First, the MRPS of the pump-cellar systemis derived resulting in a system with 27 components and37 requirements. This system is used to create DMMs P and P . The resulting DSM is depicted in Fig. 11. The27 components are listed at both axes as components G i .Markov clustering is used to cluster the components in thisDSM, with parameter tuning α = 2 , β = 2 . , µ = 2 . , and γ = 30 . For the application of localization, it is not desirableto isolate bus elements in a single cluster. Therefore, thechosen value for γ is relatively high, as this eliminatesthe detection of bus elements. The resulting clustering ismanually adjusted to the DSM depicted in Fig. 12. G1G2G3G4G5G6G7G8G9G10G11G12G13G14G15G16G17G18G19G20G21G22G23G24G25G26G27 G G G G G G G G G G G G G G G G G G G G G G G G G G G Fig. 11: Unclustered pump-cellar DSMAs the distributed supervisor is to be implemented on twoPLCs, two local supervisors, and therefore two main clustersare required. The first cluster (outlined by the green squarein Fig. 12) contains two subclusters, with the componentsof the middle pump-cellar and of the main pump-cellar 1,respectively. The second cluster (outlined by the blue square)contains the two traffic tubes and a cluster containing thecomponents of main pump-cellar 2.V. STEP 2: DISTRIBUTING THE SUPERVISORAfter distributing the system, the second step isdistributing the supervisor. First, multilevel synthesis isdone according to [19], using a plant model, a requirementmodel and the acquired distribution of the system. The treestructure, that is created in multilevel synthesis, is basedon this distribution. Distributing the supervisor consists ofthree parts: the supervisor is localized, a delay-robustnesscheck is done and, if needed, mutual exclusion algorithmsare implemented.
A. Supervisor Localization
The acquired multilevel supervisor consists of a set ofsupervisors similar to the example of Fig. 1. For each maincluster k , the set of relevant supervisors is taken as localsupervisor LOC k . This local supervisor can only disableevents in the controllable alphabet Σ kc of the componentsin its cluster. LOC k is adjusted such that all other events in Σ \ Σ kc are always enabled, which is done as follows. LOC k generally consists of a number of plant automata,requirements and one or more supervisor automata. First,requirements in the supervisor that disable events in Σ \ Σ kc are removed from the supervisor. Next, any guards thatdisable events in Σ \ Σ kc are removed. All plant automataof components outside of cluster k , that LOC k no longer G G G G G G G G G G G G G G G G G G G G G G G G G G G (cid:127)€(cid:129)‚ƒ(cid:127)€„‚ƒ(cid:127)…†‚ƒ(cid:127)…€‚ƒ(cid:127)……‚ƒ(cid:127)… ‚ƒ(cid:127)…!‚ƒ(cid:127)…"(cid:127)(cid:129)‚ƒ(cid:127)€†‚ƒ(cid:127)€€‚ƒ(cid:127)€…‚ƒ(cid:127)€ ‚ƒ(cid:127)€!‚ƒ(cid:127)€"‚ƒ(cid:127)€ (cid:127)…"‚ƒ(cid:127)… %&'ƒ€ %&'ƒ…%&'ƒ…… %&'ƒ %&'ƒ€…%&'ƒ… %&'ƒ!(%&'ƒ ƒ(%&'ƒ Main cluster 1 Main cluster 2
Fig. 12: Multilevel supervisor tree and clustered pump-cellar DSMrefers to in its requirements or supervisor automata, areremoved from
LOC k . If, after the adjustments, the supervisorautomata or requirements in LOC k refer to events or statesof automata that are not part of components in cluster k .Than that automaton is not removed from LOC k , and it thispaper, such a automaton is referred to as an observer. Theevents of observers in LOC k are not controlled by LOC k .For example, a requirement of LOC k refers to the stateof an example automaton A , which is part of cluster l . Asautomaton A is not in cluster k , A is an observer in LOC k .The occurrence of events of automaton A , is observed by LOC k in LOC l , such that every time an event of A happensin LOC l , it is communicated to LOC k . Note that, dueto communication delays, events in observers are delayed.Events of A are referred to as shared events. B. Delay-Robustness
The local supervisors, derived by localization of the globalsupervisor, only impose globally correct behavior in theabsence of communication delays. Communication delaysmight change the order in which events are observed inlocal supervisors. If, in the example local supervisor of Fig.13, event b is delayed, the order in which events a and b occur might change. Due to this, event c might be enabledwhere it should be disabled. Hence, communication delaysmight cause the localized supervisors to be globally unsafe,blocking, or uncontrollable.As communication delays are unavoidable, distributedsupervisors need to be adjusted to cope with these delays.[17] proposes a method to check if the distributed supervisoris delay robust with respect to events that are shared amonglocal supervisors. A number of requirements is stated, for adistributed supervisor to be delay robust, i.e. a supervisor inwhich the behavior is not critically altered by communication Fig. 13: Example local supervisordelays. Within these requirements, equality of the languagesof a supervisor with zero delay and a supervisor with finitedelay, is guaranteed. In the CIF3 modeling language, guardsand requirements often refer to the state of an automaton.Therefore, the requirements for delay robustness are defined,in this paper, such that local supervisors eventually reachthe same state after delayed events. Definitions from [17], inEquations 1, 2, 3 and 4 and Fig. 14, are used to define theserequirements.A global supervisor
SUP is defined by n local supervisors: SUP = || i LOC i , where i = 1 , , ..., n . To check for delayrobustness for a shared event in the supervisor, first, thisshared event is renamed. Say event r is shared between localsupervisors LOC and LOC . Event r occurs in LOC andis observed by LOC . r is now renamed to r ′ in LOC creating LOC ′ . r , in LOC , is referred to as a channeledevent and r ′ is referred to as a delayed event. Next a channelis defined. Since r is communicated from LOC to LOC ,this channel is named CH (1 , r, and is defined as in Fig.14.Using the channel and local supervisors both SUP and
SUP ′ can be defined as in Equations 1 and 2. SUP canbe seen as the distributed supervisor, whereas
SUP ′ ishe distributed supervisor where communication delays aremodeled. rr’ Fig. 14: CH (1 , r, SUP = || ( LOC , LOC ) (1) SUP ′ = || ( LOC , CH (1 , r, , LOC ′ ) (2)For n local supervisors with multiple shared events, thedefinitions of Equations 1 and 2 are adjusted. For each sharedevent, a channel, CH ( i, r, j ) is defined, where i is the indexof the local supervisor where shared event r is controlledand j the index of the local supervisor which observes event r from local supervisor i . If multiple channels exist for onechanneled event, each channel has its own delayed event.The following definitions from [17] are used: SUP = || ( LOC j | j ∈ N ) (3) SUP ′ = || ( LOC ′ j , CH ( i, r, j ) | r ∈ Σ ch ( i, j ) , i ∈ I j , j ∈ N ) (4)Above, N = { , , ..., n } , I j is the set of indexes of allsupervisors from which LOC j observes events. Σ ch ( i, j ) isthe set of all events which LOC j observes from LOC i and LOC ′ j is LOC j with all events in Σ ch ( i, j ) renamed. Notethat if I j = ∅ for LOC j , i.e. if LOC j does not observe anyevents from other local supervisors, LOC ′ j = LOC j .In this paper, sufficient conditions are defined to checkif a distributed supervisor defined by FA is delay robustwith respect to its shared events. First, the definitions ofindependence and mutual exclusivity, as defined by [36], aregiven.Two events are called independent when they are enabledsimultaneously and after the execution of either event, theother event is still enabled and either order reaches the samestate. An example of this is shown in Fig. 15, where events a and b are independent. If two events are not enabledsimultaneously, as shown in Fig. 16 they are called mutuallyexclusive. a ab b Fig. 15: Independence a when x > b when x < Fig. 16: Mutual exclusiveness A number of assumptions is done in this paper, beforedefining the sufficient conditions for delay robustness. Firstly,it is assumed that communication occurs with a finite delayand can be modeled by a FIFO (First In First Out) queue.Secondly, it is assumed that an event r is always followedby its delayed event r ′ before a second occurrence of event r , as is modeled by the channels. Proposition 1:
If every delayed event in
SUP ′ is either mutually exclusivewith respect to all other events in SUP ′ or independent withrespect to all other simultaneously enabled events in SUP ′ ,the distributed supervisor SUP is delay robust with respectto all its delayed events.
A proof of Proposition 1 is provided in Appendix A. Adistributed supervisor is said to be delay robust with respectto a single delayed event, if proposition 1 holds only for thatevent.In [36], a test is provided to check if a supervisoris confluent. Confluence is proven if, among otheroptions, event combinations are independent or mutuallyexclusive. The existing checks for independence and mutualexclusiveness are used to check if delayed events aremutually exclusive or independent with all other events in
SUP ′ , if this is the case the distributed supervisor SUP isdelay robust.It should be noted that communication channels areassumed to be FIFO queues, therefore if multiple eventsare communicated between two local supervisors, their orderis preserved. Moreover, delayed versions of these eventsare mutually exclusive. Event combinations of two delayedevents for which the original event is controlled by the samelocal supervisor, therefore need not be checked.
C. Mutual Exclusion
If a supervisor is not delay robust with respect to a delayedevent, this event is denoted a delay-critical event. A delay-critical event is not independent and not mutually exclusivewith one or more events. The combinations of each ofthese events with the delay-critical event, are called delay-critical event combinations. When a distributed supervisorcontains delay-critical event combinations, nonblockingness,safety, controllability cannot be guaranteed. Therefore thesupervisor needs to be adjusted. There are two options,the first is to change the model of the system such thatthe distributed supervisor no longer contains delay-criticalevent combinations. This option is only possible in specificsituations. Currently, no guidelines have been developed toidentify such situations. The second option is in general lessdesirable, but it is always possible. Using mutual exclusionalgorithms (mutex), it is possible to enforce the mutualexclusiveness of the delay-critical event combinations inthe global supervisor
SUP as defined by equation 3. Thisthen also implies that the event combinations are mutuallyexclusive in
SUP ′ and therefore the event combinations areno longer delay critical.It should be noted that mutex algorithms cannot be usedfor uncontrollable events as it is not possible to disablencontrollable events. Delay-critical event combinationscontaining uncontrollable events can currently not behandled. The pump-cellar case study, does not contain suchevent combinations.An implementation of a mutex algorithm is referred to asa mutex lock. A delay-critical event combination of events r ′ and a , can be made mutually exclusive by implementinga mutex lock for events r and a . Event r is controlled bya different local supervisor than event a . Each mutex locktherefore contains two processes, which are local supervisorsin this implementation. Events r and a are always disabledby the corresponding local supervisor, unless it has enteredthe critical section. Therefore, r and a are mutually exclusiveand consequently r ′ and a are mutually exclusive. Note thatthis is only true under the assumption that communicationchannels are FIFO queues. A home-based token passingalgorithm, as discussed in Section II-E, is used, as this is asimple mutex algorithm, which is efficient for low numbersof processes.For each mutex lock, a home process and an away processare defined. The mutex on the away process (referred to asprocess 2) is modeled using 3 automata and a number ofrequirements (Table I). The first automaton (Fig. 17) modelswhen the token is present, the second (Fig. 18) models thecritical section and the third (Fig. 19) models the tokenrequesting procedure. The requirement of Fig. 20 requiresthe token to be returned every time after using the criticalsection, this is done to prevent starvation of other processes.Requirements 5 and 7 contain a request condition and areturn condition. Depending on the event ( critical event )that is to be made mutually exclusive, these conditions statewhen the event is available (and therefore needs the token)and when the event has occurred (and therefore no longerneeds the token), respectively.TABLE I: Requirements away process to home needs CS.Idle to home needs
Requester.Received to cs needs
T oken.Here to cs needs
Requester.Received to idle needs
ReturnCondition request needs not
T oken.Here request needs
RequestCondition received needs
T oken.Here return needs not
T oken.Here
10 requirement critical event needs
CS.Active
NotHere Hereto hereto home
Fig. 17: Token
Idle Activeto csto idle
Fig. 18: Critical Section (CS)The home process (process 1) consists of two automataand 5 requirements. The first automaton is the token tracker,as shown in Fig. 21. This automaton tracks if the token isat the home or the away process. The second is the critical
Idle RequestedReceived r e q u e s t r ece i ve d r e t u r n Fig. 19: Requester
AB CD t oh e r e to cs t o i d l e to home Fig. 20: Req. automatonsection automaton, which is the same as the critical sectionautomaton of the away process shown in Fig. 18. An inputboolean R is true if the away process is requesting thetoken, i.e. R is set to true if the away process Requester automaton is in the state
Requested . The requirements of thehome process are listed in Table II. The requirements statethat the home process can enter the critical section when thetoken is at the home process and the
RequestCondition istrue. Note that, different from the away process, the tokendoes not need to be requested first. This implementation ofa home-based token passing algorithm is not starvation free.The home process can keep entering the critical section whilethe away process is requesting the token. A queue automatoncan be added to acquire starvation freedom, however, thisincreases the statespace of local supervisors. In this paper,such a queue automaton is not used, with the aim of reducingthe statespace of local supervisors.
Home AwaytoAwaytoHome
Fig. 21: Token TrackerTABLE II: Requirements home process token to Away needs
CS.Idle token to Away needs R to cs needs T racker.Home to cs needs
RequestCondition to idle needs
ReturnCondition
As a mutex lock is implemented for each delay-criticalevent combination, it is possible that an event is the criticalevent in multiple mutex locks. [37] states that deadlock canoccur if multiple mutex locks are used with an overlappingcritical section. When two processes contain two mutexlocks, mutex lock A and mutex lock B , deadlock occurswhen process 1 contains the token of lock A and requires thetoken of lock B and process two contains the token of lock B and requires the token of lock A . To prevent deadlock,the mutex locks are ordered such that a process can onlyacquire tokens from mutex locks in that order, as discussedby [37]. The order in which tokens are acquired is controlledby adjusting the condition RequestCondition , such that aock can only be acquired if relevant locks earlier in the orderare already acquired.Using mutex locks increases the statespace of localsupervisors. In order to lower the statespace, it is possible touse a slightly different implementation of the mutex locks.The choice can be made to use the mutex locks, as describedin this section, for two sets of events instead of using itfor two events. Instead of using one critical event in eachprocess of the mutex, a critical event set for each process isused. All events of the home process critical event set arethen mutually exclusive with all events of the away processcritical event set.
D. Case study: Pump-cellar system
In Section IV, a clustering for the pump-cellar systemis determined. Based on this clustering multilevel synthesisis done. The multilevel tree is depicted in Fig. 12. Thetree contains supervisors for each cluster, as well asa supervisor for each individual component. For everysupervisor in the tree, the relevant components are shown,the requirements are omitted, to keep te figure simple.The resulting multilevel supervisor consists of a set of 33supervisors. Note that supervisor 2 does not contain anycomponents or requirements. Due to the chosen clustering,there are no requirements that refer to components of boththe subclusters of main cluster 1. Therefore, all requirementsthat only refer to components of main cluster 1, are in
Sup or Sup . The advantage of using multilevel synthesis as abasis for localization, is that only supervisor Sup refers tocomponents of both the main clusters, all other supervisorsonly refer to components of one of the main clusters.The first step in distributing this multilevel supervisor islocalization. As the distributed supervisor is implementedon two PLCs, two local supervisors, LOC and LOC , arecreated. LOC is created using the set of supervisors 1-21,where Sup is the only supervisor that needs to be adjusted. LOC is created using supervisors 1 and 22-33, where againonly Sup needs to be adjusted. Sup adjusted for LOC isreferred to as Sup a and Sup adjusted for LOC is referredto as Sup b . LOC is the set of supervisors 2-21 and theadjusted supervisor Sup a . LOC is the set of supervisors22-33 and the adjusted supervisor Sup b .When Sup is adjusted to Sup a , the requirements andguards that disable events in components G and G areremoved. The adjusted supervisor does not disable any eventsfrom component G and G . The remaining requirementsstill refer to components G and G , therefore G and G are not removed from Sup a . For clarity, theyare renamed, such that it is clear the automata of thesecomponents are observers.To create Sup b , all requirements and guards in Sup that disable events in components G and G are removed. Sup b does not refer to components G and G , thereforethese components are removed from Sup b .Now that the supervisors are localized, the next step isto check for delay robustness. As LOC contains observercomponents G and G , the events of these components are delayed events in LOC . The delay robustness checkdiscussed in Section V-B is used to check if the distributedsupervisor is delay robust with respect to these delayedevents. The check indicates a set of 36 event combinationswhich are neither independent nor mutually exclusive.The final step in creating a distributed supervisor is settingup mutexes for of these 36 event combinations. A numberof event sets is chosen such that the 36 event combinationscan be made mutually exclusive, using 4 mutex locks.An example of a delay-critical event combination is event c operational ′ in the first traffic tube component ( G )and event c store in the M ode automaton of the middlepump-cellar ( G ). Event c operational is controlled by LOC and event c store by LOC . Event c operational is in the critical event set of the home process of mutexlock 1 and c store is in the critical event set of the awayprocess of mutex lock 1. Therefore, these events are nowmutually exclusive. For each of the 36 event combinationsa mutex lock is used in a similar fashion. The resultingdistributed supervisor is delay robust, nonblocking, safe andcontrollable.VI. H ARDWARE IN THE L OOP TESTING
A Hardware in the Loop (HIL) setup was used to test thedistributed supervisor. Before implementing the supervisoron a PLC, some adjustments need to be made. [38] denotesthree properties that a supervisor needs to adhere to when acontroller is derived from that supervisor. These propertiesare confluence, finite response, and nonblockingness undercontrol. In CIF3 checks are developed to verify if asupervisor has each of these properties.Confluence is defined as follows by [39]. Whenever acontroller can choose between two controllable events, eachof these events can be extended by a string of controllableevents such that both paths end up in the same state. Acontroller has finite response when it does not contain aninfinite sequence of controllable events. Finally, [39] definesnonblockingness under control. From every reachable statein a controller, a sequence of events, which prioritizescontrollable events over uncontrollable event, is enabledand reaches a marked state. Moreover, in this marked stateno controllable events are enabled. If this is the case, thecontroller is nonblocking under control. [38] discusses theseproperties and the developed checks in more detail.The controller checks are performed for the pump-cellarsystem. Some changes are required to achieve the threecontroller properties. Initially the sensors of each pump-cellar are modeled as individual sensors with no physicalrelations. This model is changed to one sensor automatonfor all sensors in a pump-cellar. The automaton is givenin Fig. 22, the event and state names in this figure areabbreviated. In the initial model, the assumption that, forexample, sensor level 1 would never be off if sensor level2 is on. In the adjusted model, this is incorporated. A newdistributed supervisor is acquired for the adjusted model, inthe same way as is described earlier. The resulting supervisorhas the three controller properties. ff L 1 L 2 L 3 L 4 L 5s1 ons1 off s2 ons2 off s3 ons3 off s4 ons4 off s5 ons5 off
Fig. 22: Adjusted sensors automatonThe statespace of the supervisors is given in Table III.A significant reduction of the statespace is achieved bydistributing the supervisor.TABLE III: Statespace of supervisors
Statespace % of globalGlobal multilevel supervisor . ∗ . ∗ . ∗ The distributed supervisor is implemented on twoPLCs, which communicate using industrial ethernet. Beforeimplementing the distributed supervisor, a hardware mappingis created, which maps events to input and output variables.The pump-cellars are simulated using Ignition InductiveAutomation software, which is also used to create a graphicaluser interface consisting of all the buttons and a visualizationof sensor values. A set of scenarios is defined to validate thebehavior of the controlled system.VII. CONCLUDING REMARKSIn this paper, a method for developing distributedsupervisory controllers is proposed. The resulting distributedsupervisor is delay robust, nonblocking, controllable andsafe. The method is demonstrated by developing a supervisorfor a pump-cellar system. The developed supervisor is testedusing simulation and a HIL-setup, validating the behavior ofthe controlled system.The statespace of the local supervisors is significantlylower than the statespace of the global supervisor. Whichindicates that the distributed supervisor will require lessmemory and can achieve lower cycle times, than the globalmultilevel supervisor.The proposed method uses the top-down approach oflocalization, for which synthesis of a global supervisor isrequired. For large scale systems this might prove to beimpossible. Therefore, more research is needed to investigatebottom-up methods, as for example has been proposed by[14].In the method of this paper, the statespace of thesupervisor is greatly increased by the implementation ofmutex locks. One of the reasons for using distributedsupervisory controllers, is being able to control large scalesystems, which cannot be controlled by other supervisorycontrollers. The increase of the statespace by mutex lockscounteracts the ability to control large-scale systems, usingthe method of this paper.. Using a lower number of mutexlocks is a solution to the statespace problem, but it is unclearwhat the effects are of using a single mutex lock for a large set of events. Therefore, more research is needed to moreefficiently deal with delay-critical event combinations.R
EFERENCES[1] C.G. Cassandras and S. Lafortune.
Introduction to Discrete EventSystems , volume 2. Springer, 2008.[2] P.J.G. Ramadge and W.M. Wonham. Supervisory Control of DiscreteEvent Processes.
Lecture Notes in Control and Information Sciences ,39:202–214, 1982.[3] W.M. Wonham.
Supervisory control of discrete event systems .University of Toronto, 2019. Lecture notes.[4] P.J.G. Ramadge and W.M. Wonham. The Control of Discrete EventSystems.
Proceedings of the IEEE , 77:81–98, 1989.[5] M.H. De Queiroz and J.E.R. Cury. Modular Supervisory Control ofLarge Scale Discrete Event Systems.
Discrete Event Systems, SECS ,569:103–110, 2000.[6] M.H. De Queiroz and J. E. R. Cury. Modular Control of ComposedSystems.
Proceedings Of The American Control Conference , pages4051–4055, 2000.[7] K. Cai and W. M. Wonham. Supervisor localization: A top-downapproach to distributed control of discrete-event systems.
AIPConference Proceedings , 1107(March 2009):302–308, 2009.[8] W.M. Wonham and P.J.G. Ramadge. Modular supervisory control ofdiscrete event systems.
Mathematics of Control, Signals, and Systems ,1:13–30, 1988.[9] T. Yoo and S. Lafortune. A General Architecture for DecentralizedSupervisory Control of Discrete-Event Systems.
Discrete EventDynamic Systems: Theory and Applications , 12:335–377, 2002.[10] J. Komenda, T. Masopust, and J.H. Van Schuppen. Control ofan engineering-structured multilevel discrete-event system. In ,pages 103–108, 2016.[11] H.M. Hanisch and V. Vyatkin. Modeling and verification of distributedcontrol systems. In
Design, Analysis, and Simulation of DistributedSystems Symposium, DASD‘05 , pages 79–85, 2005.[12] M. Zgorzelski and J. Lunze. A method for the synchronisation ofnetworked discrete-event systems. In , pages 444–451. IEEE, 2016.[13] F.F.H. Reijnen, T.R. Erens, J.E. Rooda, and J.M. Van de Mortel-Fronczak. Supervisory Control Synthesis for Safety PLCs. In
Proceedings of the 15th Workshop on Discrete Event Systems, IFAC ,page In press, 2020.[14] R. Su, J. H. Van Schuppen, and J. E. Rooda. Aggregative synthesisof distributed supervisors based on automaton abstraction.
IEEETransactions on Automatic Control , 55:1627–1640, 2010.[15] A. Rashidinejad, M.A. Reniers, and L. Feng. Supervisory Control ofTimed Discrete-Event Systems Subject to Communication Delays andNon-FIFO Observations.
IFAC-PapersOnLine , 51:456–463, 2018.[16] G. Kalyon, T. Le Gall, H. Marchand, and T. Massart. Synthesisof Communicating Controllers for Distributed Systems. In , pages 1803–1810, 2011.[17] R. Zhang, K. Cai, Y. Gan, and W.M. Wonham. Distributed supervisorycontrol of discrete-event systems with communication delay.
DiscreteEvent Dynamic Systems: Theory and Applications , 26(2):263–293,2016.[18] S.D. Eppinger and T.R. Browning.
Design Structure Matrix Methodsand Applications . MIT press, January 2012.[19] M.A. Goorden, J.M. Van De Mortel-Fronczak, M.A. Reniers, and J.E.Rooda. Structuring multilevel discrete-event systems with dependencystructure matrices. In
IEEE 56th Annual Conference on Decision andControl, CDC 2017 , pages 558–564, 2018.[20] J.B. MacQueen. Some methods for classification and analysis ofmultivariate observations. In , pages 281–297, Oakland, 1967.[21] A. Capocci, V. D.P. Servedio, G. Caldarelli, and F. Colaiori. Detectingcommunities in large networks.
Physica A: Statistical Mechanics andits Applications , 352:669–676, 2005.[22] T.L. Yu, A.A. Yassine, and D.E. Goldberg. An information theoreticmethod for developing modular architectures using genetic algorithms.
Research in Engineering Design , 18:91–109, 2007.[23] R.E. Thebeau. Knowledge Management of System Interfaces andInteractions for Product Development Processes, 2001. MassachusetsInstitute of Technology.24] T. Wilschut.
System specification and design structuring methodsfor a lock product platform . PhD thesis, Eindhoven University ofTechnology, 2018.[25] S. van Dongen. Graph clustering via a discrete uncoupling process.
SIAM Journal on Matrix Analysis and Applications , 30:121–141, 2008.[26] K. Cai. Supervisor Localization : A Top-Down Approach toDistributed Control of Discrete-Event Systems, 2008. University ofToronto Department of Electrical and Computer Engineering.[27] K. Cai and W.M. Wonham. Supervisor localization for large discrete-event systems : Case study production cell.
International Journal ofAdvanced Manufacturing Technology , 50:1189–1202, 2010.[28] L. Feng, K. Cai, and W. M. Wonham. A structural approach to the non-blocking supervisory control of discrete-event systems.
InternationalJournal of Advanced Manufacturing Technology , 41(11-12):1152–1168, 2009.[29] E. W. Dijkstra. Solution of a Problem in Concurrent ProgrammingControl.
Communications of the ACM , 8:569, 1965.[30] L. Lamport. Time, Clocks, and the Ordering of Events in a DistributedSystem.
Communications of the ACM , 21:558–565, 1978.[31] S. Kanrar, N. Chaki, and S. Chattopadhyay.
Concurrency Control inDistributed System Using Mutual Exclusion . Springer Nature, 2018.[32] K. Raymond. A Tree-Based Algorithm for Distributed MutualExclusion.
ACM Transactions on Computer Systems (TOCS) , 7:61–77,1989.[33] G. Ricart and A. K. Agrawala. An optimal algorithm for mutualexclusion in computer networks.
Communications of the ACM ,24(1):9–17, 1981.[34] M. Raynal.
Distributed Algorithms for Message-Passing Systems .Springer-Verlag Berlin Heidelberg, Rennes, 2013.[35] D.A. Van Beek, W.J. Fokkink, D. Hendriks, A. Hofkamp, J.M. VanDe Mortel-Fronczak, and M.A. Reiniers. CIF 3 : Model-BasedEngineering of Supervisory Controllers. In
Tools and algorithmsfor the construction and analysis of systems : 20th InternationalConference, TACAS 2014, Proceedings , pages 575–580, 2014.[36] F.F.H. Reijnen, A.T. Hofkamp, J.M. Van De Mortel-Fronczak, M.A.Reniers, and J.E. Rooda. Finite response and confluence of state-basedsupervisory controllers. In
IEEE 15th International Conference onAutomation Science and Engineering (CASE) , pages 509–516, 2019.[37] A. Silberschatz, P.B. Galvin, and G. Gagne.
Operating system concepts8th edition . John Wiley & Sons, Inc., 2009.[38] F.F.H. Reijnen.
Putting supervisor synthesis to work, Controllersoftware generation for infrastructural systems . PhD thesis, EindhovenUniversity of technology, 2020.[39] P. Malik.
From Supervisory Control to Nonblocking Controllers forDiscrete Event Systems . PhD thesis, Universit ¨ at Kaiserslautern, 2003. APPENDIX A
Proof of proposition 1:
Recall proposition 1:
If every delayed event in
SUP ′ is either mutually exclusivewith respect to all other events in SUP ′ or independent withrespect to all other simultaneously enabled events in SUP ′ ,the distributed supervisor SUP is delay robust with respectto all its delayed events.
Recall that, in a channel, r is referred to as the channeledevent and r ′ is referred to as the delayed event. Furthermore, SUP = ( X, Σ , ξ, x , X m ) and SUP ′ = ( X ′ , Σ ′ , ξ ′ , x ′ , X ′ m ) .Firstly, note that by definition of SUP ′ , in a state reachedby channeled event r , delayed event r ′ is always enabled.Secondly, if r ′ is mutually exclusive or independent withall other events in Σ ′∗ , it is said that r ′ is independent withits simultaneously enabled events.Thirdly, note that an event r is only enabled after a string s ∈ L ( SUP ) ′ , if for every event r in s , s contains an event r ′ , due to the definition of the channels. Subsequently, r is only enabled after s if s contains the same number ofevents r and r ′ .Fourthly, note that ( ∀ s ∈ L ( SUP ′ )) in which everychanneled event is directly followed by its delayed event, P ( s ) ∈ L ( SUP ) . This is true, as essentially no delay hasoccurred on any event. Such a string s is referred to asa delay-free string, denoted by subscript s df . Similarly, ( ∀ s ∈ L m ( SUP ′ )) in which every channeled event isdirectly followed by its delayed event, P ( s ) ∈ L m ( SUP ) .Fifthly, note that for any string s , where any channeledevent is at some point followed by its delayed event, thereexists a string s df such that P ( s ) = P ( s d f ) , moreover, ξ ′ ( x , s ) = ξ ′ ( x , s df ) . This is true as any delayed eventis independent with its simultaneously enabled events. Forexample, consider a string ( s rs r ′ s ∈ L ( SUP ′ ) | s ∈ Σ ∗ , s ∈ Σ ∗ , s ∈ Σ ∗ ) .Note that P ( s rs r ′ s ) = s rs s = P ( s rr ′ s s ) ,moreover, as r ′ is independent with its simultaneouslyenabled events, ξ ′ ( x , s rs r ′ s ) = ξ ′ ( x , s rr ′ s s ) . Here, s rr ′ s s is a delay free string as any channeled event,i.e. r , is directly followed by its delayed event, in this case r ′ . SUP is said to be delay robust with respect to its channeledevents if the following 5 conditions, defined by [17], hold:
P L (cid:0)
SUP ′ (cid:1) ⊆ L ( SUP ) (5) P L m (cid:0) SUP ′ (cid:1) ⊆ L m ( SUP ) (6) P L (cid:0)
SUP ′ (cid:1) ⊇ L ( SUP ) (7) P L m (cid:0) SUP ′ (cid:1) ⊇ L m ( SUP ) (8) ( ∀ a ∈ Σ ′∗ ) ( ∀ c ∈ Σ ∗ ) a ∈ L (cid:0) SUP ′ (cid:1) & P ( a ) .c ∈ L m ( SUP ) ⇒ ( ∃ b ∈ Σ ′∗ ) P ( b ) = c & a.b ∈ L m (cid:0) SUP ′ (cid:1) (9)Each of these conditions is proven in this appendix,therefore condition 1 holds. A. Condition 1 (equation 5)
It is proven by induction that: ( ∀ s ∈ L ( SUP ′ )) P s ∈ L ( SUP ) .Base step: ǫ ∈ L ( SUP ′ ) and ǫ ∈ L ( SUP ) , trivially.Inductive step: suppose t ∈ L ( SUP ) ′ , P ( t ) ∈ L ( SUP ) and t.a ∈ L ( SUP ′ ) , we must prove that P ( t.a ) ∈ L ( SUP ) .Two possible cases are identified:1) t contains a delayed event for every occurrence of achanneled event. (i.e. no delayed event is enabled in ξ ′ ( x , t ) .)) t does not contain a delayed event for every occurrenceof a channeled event. (i.e. at least one delayed eventis enabled in ξ ′ ( x , t ) .)In case 1), ( ∃ t df ∈ L ( SUP ′ ) | ξ ′ ( x , t df ) = ξ ′ ( x , t )) ,where t df is a delay free string. In this case, a cannot bea delayed event, as every delayed event is disabled by itschannel, i.e. t.a / ∈ L ( SUP ′ ) . If a is a channeled event, t df .a.a ′ ∈ L ( SUP ′ ) is again a delay free string as everychanneled event is directly followed by its delayed event.Now, P ( t.a ) = P ( t df .a ) = P ( t df .a.a ′ ) ∈ L ( SUP ) . If a isnot a channeled event, t df .a is a delay free string. Therefore, P ( t.a ) = P ( t df .a ) ∈ L ( SUP ) .In case 2), t.a can be extended with a string of delayedevents d , such that the string t.a.d ∈ L ( SUP ′ ) contains adelayed event for every occurrence of a channeled event.Therefore, P ( t.a.d ) = P ( t.a ) and ( ∃ t df ∈ L ( SUP ′ ) | ξ ′ ( x , t df ) = ξ ′ ( x , t.a.d )) , where t df isa delay free string. Now, P ( t.a ) = P ( t.a.d ) = P ( t df ) ∈ L ( SUP ) .In both the cases, ( ∀ a ∈ Σ ′ | t.a ∈ L ( SUP ′ )) it is proventhat P ( t.a ) ∈ L ( SUP ) , therefore condition 1 of equation 5holds. Condition 2 (equation 6)
Condition 2 holds if: ( ∀ s ∈ L m ( SUP ′ )) P ( s ) ∈ L m ( SUP ) .Any string s contains a delayed event for every occurrenceof a channeled event, by definition, otherwise s doesnot reach a marked state due to the definition of thechannels. Therefore, ( ∀ s ∈ L m ( SUP ′ )) ( ∃ s df | ξ ′ ( x , s df ) = ξ ′ ( x , s )) , where s df is a delay free string. P ( s ) = P ( s df ) ∈ L m ( SUP ) by definition of delay-free strings. Condition 3 (equation 7)
Condition 3 holds if: ( ∀ s ∈ L ( SUP )) s ∈ P L ( SUP ′ ) For any string s , a delay free string s df ∈ L ( SUP ′ ) canbe created by replacing any channeled event in s by thechanneled event directly followed by its delayed event. Forexample, if s contains a channeled event r , create s df byreplacing every occurrence of r by rr ′ . By definition, SUP ′ must allow such a delay free string.As s df ∈ L ( SUP ′ ) , it must hold that s = P ( s df ) ∈ P L ( SUP ′ ) . Condition 4 (equation 8)
Condition 4 holds if: ( ∀ s ∈ L m ( SUP )) s ∈ P L m ( SUP ′ ) .For any string s , a delay free string s df ∈ L m ( SUP ′ ) canbe created by replacing any channeled event in s by thechanneled event directly followed by its delayed event, as isdone for Condition 3. By definition, SUP ′ must allow such a delay free string.As s df ∈ L m ( SUP ′ ) , it must hold that s = P ( s df ) ∈ P L m ( SUP ′ ) . Condition 5 (equation 9)
Two possible cases are defined: • a contains a delayed event for every occurrence of achanneled event. (i.e. no delayed event is enabled in ξ ′ ( x , t ) .) • a does not contain a delayed event for every occurrenceof a channeled event. (i.e. at least one delayed event isenabled after in ξ ′ ( x , t ) .)In case 1), due to the independence of delayedevents with their simultaneously enabled events, ( ∃ a df ∈ L ( SUP ′ ) | ξ ′ ( x , a df ) = ξ ′ ( x , a )) , where a df is a delay free string. Next, for any string c a delay freestring c df can be created as is done for Condition 3. Let b = c df , then P ( b ) = c . Moreover, as a df .b is a delay freestring and P ( a df .b ) = P ( a ) .c ∈ L m ( SUP ) , it must holdthat a df .b ∈ L m ( SUP ′ ) ⇒ a.b ∈ L m ( SUP ′ ) .In case 2), a can be extended with a string of delayedevents d , such that the string a.d ∈ L ( SUP ′ ) contains adelayed event for every occurrence of a channeled event.For a.d it must hold that ( ∃ a df ∈ L ( SUP ′ ) | ξ ′ ( x , a df ) = ξ ′ ( x , a.d )) , due to theindependence of delayed events with their simultaneouslyenabled events. Next, for any string c a delay free string c df can be created as is done for Condition 3. Let b = d.c df , then P ( b ) = c . Due to the independence ofdelayed events with their simultaneously enabled events, ( ∃ f df ∈ L ( SUP ′ ) | ξ ′ ( x , f df ) = ξ ′ ( x , a df .c df ) = ξ ′ ( x , a.d.c df ) . As f df is a delay free string and P ( f df ) = P ( a ) .c ∈ L m ( SUP ) , it must hold that f df ∈ L m ( SUP ′ ) ⇒ a.b ∈ L m ( SUP ′ ))