Master s Thesis - Nard Hoefnagels 420519

8/12/2019 Master s Thesis - Nard Hoefnagels 420519

1/126

Supervisory machine control based onState Tree Structures for the paintfactory model

L.J.E. Hoefnagels (Nard)

SE 420519

Masters Thesis

Supervisor: Prof. dr. ir. J.E. RoodaCoach: Dr. ir. J.M. van de Mortel-Fronczak

Eindhoven University of Technology

Department of Mechanical Engineering

Systems Engineering Group

Eindhoven, Februari 2008


2/126


3/126

Preface

The report youre holding contains the result of my final assignment to become aMaster of Science. This thesis finishes my study at the Department of Mechanical

Engineering of the Eindhoven University of Technology. The last years of my study Ispent with the Systems Engineering Group.

Beside studying I did have some so called studie ontwijkend gedrag. This concernsliving with other students, joining ESMG Quadrivium, and doing multiple committees.With ESMG Quadrivium Ive performed several nice and big concerts. Especially theconcert trip to Tuscany I will always remember as a once of a lifetime experience.My stay at the Politecnico di Milano for my internship was also a great experience. Thedifferences in the cultures made me realize what special and agreeable relation existsbetween students and staff. Nevertheless, I had a great time and I would recommendit to everyone.

The last year was on this masters project, which I did with great pleasure. In myproject I was coached by dr. ir. Asia van de Mortel whom I would like to thank veryfor all the support. Also I would like to thank prof. dr. ir. Rooda for supervisingthis research project and for providing the necessary means to make sure my stay atthe Systems Engineering group was a pleasant one. My fellow students I would like tothank for giving me feedback on my project, giving me insight in theory and providingthe SE-group with a good tool.

Last, but certainly not least, I would like to thank my family and my girlfriend Eefje.My family supported me my entire study and did not limit me in all my activities. I

would like to thank Eefje for the patience with me during the last episode of this thesisand for giving me good feedback on my report. I hope youre all proud of me, thanksto you all!

Eindhoven, Februari 2008

Nard Hoefnagels

i


4/126

ii Preface


5/126

Assignment


6/126

iv Assignment


7/126

Summary

Nowadays, a lot of attention is paid to the design and development processes ofadvanced systems. With a reduction of the design process and the advancing of the

test phases, time can be saved. This means an improvement of the quality of thesystem and also a reduction in costs. The current approach must be adapted to thenew demands of the development, faster and better. To achieve this, the SupervisoryControl Theory of Wonham could be used. In the SCT a supervisor is synthesizedfrom several component automata.

More recently, SCT has been extended to State Tree Structures allowing for explicitspecification of hierarchy and concurrency. The STS theory is blocking free, meaningthat it is always possible to reach an end state. In this report it is shown how STScan be compared to other supervisory control methods. In this comparison it can bestated that STS is a good method compared to the other available methods. A big

benefit of STS is that it uses BDDs which represents the states in a very compactway. In the STS method, the requirements can be modeled by automata and logicalexpressions. Logical expressions are rather new for defining requirements in the SCTframework. Therefore, research is done of how these logic expressions are integratedinto the supervisor and what consequences they have on the way the automata of thecomponents are to be defined. Modeling rules are formulated to be able to use thelogical expressions at any time.

TThe first purpose of this research is to investigate the applicability of the super-visor synthesis method based on State Tree Structures for complex systems. Tothis end, a mock-up of a paint factory which is designed and built in the lab of

Systems Engineering is used as a case study. It is chosen to divide the mock-upinto its subsystems to get a good overview of how the separate subsystems work,by modeling this way it should also be possible to test each subsystem separately.The components of the subsystems are defined by automata using the formulatedmodeling rules. Subsequently the requirements are defined by automata and logicalexpressions. The synthesized supervisor of the mock-up is validated whether thecorrect design is defined and verified if it satisfies the requirements. Satisfying therequirements means for example that after a pipe is used by a color it needs tobe cleaned before another color can go through. Not only the pipes need to becleaned, also the vessels which store a mixed fluid need to be cleaned. Of course

v


8/126

vi Summary

the cleaning fluid may not go to a cup and paint may not go directly to a waste location.

The second purpose was to propose a setting for the analysis and implementation ofthe controllers synthesized according to the STS method. A proof of concept should bedelivered for the case study chosen. In this report the synthesized correct supervisoris connected to the resource controllers of the mock-up. In order to proof that theseresource controller define the correct behavior of the mock-up a simulation model hasbeen used. In this simulation model the resources are visualized using Labview. Anadditional controller is added for scheduling the tasks and defining the amount of paintthe flow sensors have to count each time. This controller uses an eager schedulingalgorithm, meaning that an event is performed as soon it can be done. The simulationmodel is checked whether the resource controllers act as desired. After the simulation

model is made, suggestions are given of how this can be implemented on the mock-upand how the optimal scheduler can be implemented in the control system. For definingan optimal schedule for the available orders the supervisor defined in this report canbe used.


9/126

Samenvatting

Tegenwoordig wordt er veel aandacht besteed aan het ontwerp en ontwikkelingsprocesvan geavanceerde machines. Met het reduceren van het ontwerp proces en het

avanceren van de testfase kan tijd bespaard worden. Dit betekend een verbetering vande kwaliteit van het systeem en kosten reductie. De huidige aanpak moet aangepastworden op de nieuwe ontwikkel vraag, sneller en beter. Om dit te bereiken kan deSupervisory Control Theorie (SCT) van Wonham gebruikt worden. In de SCT wordteen supervisor gesynthetiseerd van verschillende component automaten.

Meer recentelijk is de SCT uitgebreid naar State Tree Structures welke gebruik makenvan expliciete specificaties en een horizontale en verticale structuur van modelleren.In dit verslag is een vergelijk gemaakt tussen STS en andere SCT methoden. Uitdeze vergelijking is gebleken dat STS een goede methodiek is ten opzichte van andereSCT methodieken. Een groot voordeel van STS is dat het gebruik maakt van BDDs

welke de toestanden in een heel compacte manier weergeven. In de STS methodiekkunnen de beperkingen worden gemodelleerd middels automaten en middels logischeexpressies. Logische expressies zijn nieuw een nogal nieuwe manier om beperkingente definieren in het SCT raamwerk. Daarom is er onderzoek gedaan naar hoe dezelogische expressies gentegeerd worden in de supervisor en welke consequenties dit heeftvoor het modelleren van de component automaten. Gebaseerd op dit onderzoek zijn ermodelleer regels geformuleerd zodat (bijna) altijd logische expressies gebruikt kunnenworden.

Het eerste deel van dit onderzoek is te analyseren of middels STS een supervisor gesyn-thetiseerd kan worden voor complexe systemen. Om dit te doen is een schaalmodel van

een verf fabriek, welke is ontworpen en gebouwd in het lab van Systems Engineeringgebruikt als studie casus. Er is voor gekozen om het schaalmodel in te delen in deverschillende subsystemen om een goed overzicht te krijgen in de afzonderlijke functies,deze manier van zou het ook mogelijk moeten maken de verschillende subsystemen af-zonderlijk te testen. The componenten van de subsystemen zijn gedefinieerd middelsautomaten, waarbij gebruik is gemaakt van de modelleerregels die eerder zijn opgesteld.Vervolgens zijn de beperking gedefinieerd middels automaten en logische expressies. Degesynthetiseerde supervisor van het schaalmodel is getest, daar de juiste componentenzijn gedefinieerd en aan alle beperkingen voldaan wordt. Het voldoen aan een beperk-ing betekend bijvoorbeeld dat nadat een kleur door een leiding is gegaan, deze leiding

vii


10/126

viii Samenvatting

gereinigd dient te worden alvorens een andere kleur erdoor kan. Niet alleen de leidingen

moeten gereinigd worden, ook de vaten die een gemengde kleur kunnen bevatten dienennaderhand gereinigd te worden. Natuurlijk mag de schoonmaakvloeistof niet naar eenverfblik gaan en mag de verf niet rechtstreeks naar een afval locatie.Het tweede deel van het onderzoek is om een voorstel te maken van een opstelling voorde analyse en implementatie van de controllers gesynthetiseerd met de STS methodiek.Een conceptueel bewijs dient geleverd dat de studie casus (het schaalmodel) werktzoals verlangd wordt. In dit verslag is de gesynthetiseerde supervisor aangesloten aande resource controllers van het schaalmodel. Om te bewijzen dat de resource controllershet correcte gedrag definieren voor het schaalmodel is er simulatiemodel gemaakt. Indit simulatiemodel worden de resources gevisualiseerd middels Labview. Een extracontroller is toegevoegd om de volgorde van de acties te bepalen en te bepalen welke

hoeveelheid verf de vloeistof sensoren moeten meten. Deze controller voert een actie uitzodra de resource controllers zeggen dat dit mogelijk is. Dit simulatiemodel is gechecktdaar het gewenste gedrag beschreven wordt door de resource controllers. Nadat hetsimulatiemodel is gemaakt zijn er suggesties gegeven hoe dit model gemplementeerdkan op het schaalmodel en hoe een optimale regelstrategie in het geheel gemplementeerdkan worden. Om een optimale regel strategie te bepalen voor de beschikbare orders kande supervisor worden gebruikt.


11/126

Contents

Preface i

Assignment iii

Summary v

Samenvatting vii

1 Introduction 11.1 STS and other methods . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2 SCT Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.3 The STS basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.4 Verification tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2 Defining requirements 192.1 Automata as requirements . . . . . . . . . . . . . . . . . . . . . . . . . . 212.2 Automata and logical expressions as requirements . . . . . . . . . . . . 232.3 Logical expressions as requirements . . . . . . . . . . . . . . . . . . . . . 272.4 Modeling rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3 Case Study: The Paint Factory 333.1 The Paint factory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.2 The modeling of the Paint Factory . . . . . . . . . . . . . . . . . . . . . 363.3 Preparations for implementation . . . . . . . . . . . . . . . . . . . . . . 403.4 Implementation suggestions . . . . . . . . . . . . . . . . . . . . . . . . . 47

4 Conclusions and recommendations 514.1 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514.2 Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

Bibliography 55

A STS model 57A.1 All subsystems defined . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57A.2 Input files for STS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

ix


12/126

x Contents

B Chimodel of the mock-up with supervisor 89

B.1 The processes explained . . . . . . . . . . . . . . . . . . . . . . . . . . . 89B.2 The model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

C Python script 107

D Comparison of STS with other methods 113


13/126

Chapter 1

Introduction

The last decennia the complexity of machines has been increased enormously. For exam-ple a photo-camera, it used to be a rather big and expensive machine, with a restrictedfunctionality. Nowadays however, there are digital cameras which can zoom, adjust thelightning and shutter-time, view the photos, etcetera. Not only the photo-camera hasgone through such development, it can be seen in many other machinery. Through thisincrease in functionality and due to the fact that each new feature can also interfere withother features, the control of machinery has also become much more complex. Imaginehow complex the control of machines like a MRI scanner or a wafer scanner is. To beable to control such machinery, a control system consisting of several layers of controlis used. In the control system, a supervisor plays an important role. The supervisordefines the behavior of the system. The supervisor can send commands to the resourcecontrollers, which control the actuators. An overview of the components of a controlsystem can be found in Figure 1.1. For complex machinery a supervisor can becomevery big and complex. A way to define such supervisor is by the synthesizes of DiscreteEvent systems (DES). A DES is discrete in time and in state space and event-drivenrather than time-driven [Ma05]. Take the control of a lift, for example. With a DES,the commands for the lift can be like go up and go down. When such a signal is givenand the lift arrives at a position, a sensor can return a signal to the supervisor sayingthat the lift is at a certain position. If the supervisor is not a DES but a time-drivensupervisor, then the commands can be: go up for 30 seconds, then wait for 40 seconds.A DES can describe the behavior of a component and can be represented by an automa-ton. The Supervisory Control Theory (RW SCT), developed by Ramadge and Wonham[Ram81], can be used to automatically synthesize a supervisor that restricts the behav-ior of a plant such that the given specifications are fulfilled as much as possible. Eachplant component is modeled by an automaton. Additional requirement automata areused to define the behavior of the system. An automaton contains states and transi-tions. An automaton is always in a certain state, the transitions give the possibilities togo from one state to another. These transitions can be divided into 2 types, controllableand uncontrollable. Only the controllable can be controlled and thus be disabled by the

1


14/126

2 Chapter 1. Introduction

supervisor. By disabling the right transitions, a correct (which does the right things) su-

pervisor can be made. This disabling of events is done to avoid blocking and to fulfill allthe requirements. Blocking is explained in this chapter. It is often of interest to obtainan optimal supervisor. In the SCT optimal means that only those events are dis-abled necessary to fulfill the requirements and to be non-blocking. After the supervisoris synthesized, it has to be validated to make sure the supervisor does the right things.The automata are made intuitively and are not always correct, therefore the supervisorhas to be validated to check if automata define the desired behavior. This validationhas to be done on state combinations but also on the transitions. The number of statesin a supervisor depends on the automata and the requirements and grows exponentiallywith the number of components. As a consequence of the state explosion, the calcula-tion time to synthesize the supervisor will also increase exponentially. This means that

the calculation time of all states is exponential in the number of system components[Ma05]. To be able to synthesize the supervisor, economical compact representations ofstate sets are used. To be able to have an automaton in multiple states, Statecharts areused [Har87]. On the basis of Statecharts, State Tree Structures (STS) are introducedby Wang [Wan95]. STS consist of several layers of AND and OR superstates. At thebottom of a tree, dynamical modules can be found. These dynamical modules are thestates of the automata and represent, for example that a valve is open.First a short comparison of STS with other methods is given, what other methods can bedefined and how they relate with eachother. Afterward the basics of SCT are explainedbecause of the relation of SCT with STS. In that section, the properties of a supervisorare explained. Since STS is used for synthesizing a supervisor, an explained on this

method is given. The basics behind the compact representation in STS is explainedwith an example. Finally some tools that can be used for checking if the supervisordefines the correct behavior are explained.

1.1 STS and other methods

In this report the method of Ma and Wonham [Ma05] called STS is explained and usedfor a case study. Before all properties are explained it is shown how STS is relatedto other methods for supervisory machine control. Globally there are two methods ofdesigning a supervisor:

1. Synthesizing a supervisor based on component models and requirements.

2. Constructing a candidate supervisor and verifying the requirements it has to sat-isfy by means of a model checker.

For the last design method, the UPPAAL [Beh04] tool can be used for the verificationof a supervisor. A report of UPPAAL in which a supervisor is made for the paintfactory can be found in [Tri06]. The tool is developed at the University of Aalborg(Denmark) and the university of Uppsala (Sweden). The tool can check whether


15/126

1.2. SCT Basics 3

certain properties hold for the defined automata and supervisor. Note that UPPAAL

cannot synthesize a supervisor itself, it can only check whether certain properties hold.The model-check engine of UPPAAL is based on the Computational Tree Logic [Hut04]which is a branching-time logic that besides the connectives of propositional logic (,,, ) also temporal logic connectives possesses.

In the first design method two types are considered. Troncis method and the theory ofWonham, both of them use models for synthesizing a supervisor. Troncis method usesBoolean First-Order Logic (BFOL) to model the components and the requirements.These boolean functions are represented by BDDs which are used to synthesize a su-pervisor for the system. The supervisor in Troncis method is defined by one BDDrepresenting all states and the transitions between them. Troncis method uses only

controllable events, while Wonham uses also uncontrollable events. Another differenceis their definition for an optimal supervisor. Troncis definition for an optimal super-visor is the shortest path (in number of transitions) to reach an end state. Wonhamdefines the optimal supervisor as the least restrictive state space with respect to therequirements. The BSP tool supports Troncis method. This tool is basically a sym-bolic model checker which can verify and validate its synthesized supervisor. A proofof concept of Troncis method can be found in [Rob08].Based on the theory of Wonham two tools have been developed, the first one is TCT(Toy Control Theory). This tool was given the name Toy because of its limited abilityto deal with large scale systems [Saa04]. In the tool all components and requirementsare defined by automata. The synthesized supervisor is non-blocking, satisfies the con-trollability condition and is represented by an automaton. The second tool is develop byMa and Wonham [Ma05] and is based on STS. It uses BDDs to represent the supervisor.These BDDs represent the states in a very compact way, therefore the STS tool shouldbe capable of handling more states. Both the supervisor of STS and TCT is optimalmeaning that it is minimally restrictive (it only blocks those events needed to fulfill therequirements and the non-blocking and controllability condition). A short overview ofthe properties of some of the supervisory methods can be found in Appendix D.

1.2 SCT Basics

The basic idea behind the Supervisory Control Theory is that a supervisor is automati-cally synthesized from component automata and requirements. The supervisor restrictsthe behavior such that the given specifications are fulfilled. A specification for examplecould be: after a lift is up, a pusher needs to extract. The supervisor however is justone component for the control of a system (although a very important one). In Figure1.1, a schematic view is shown of how the supervisory controller (supervisor) can beseen as part in the control of a system. In this scheme the supervisory controller receivesorders from the user and translates them into tasks for the resource controllers. Alsoother schemes can be used for the control, as can be seen in Chapter 3. However in all


16/126


of them the supervisory controller determines what may happen when, so it disables

events (tasks) to get the desired behavior. In the scheme, resource controllers receivetasks from the supervisory controller and translate them into actions for the resources.For example, in the supervisory controller a task to the resource controller could bepump a certain fluid, the resource controller translates this into the actions: open avalve and turn on a pump. The resource controller will then send actions commandsto the actuators of the system.

User

Supervisory Controller

Resource Controllers

actuators sensors

System

tasks

resources

Figure 1.1: Schematic control of a system

For the synthesizes of the supervisor, Discrete Event Systems are used to model the sys-tem components. Beside the components also the requirements can be defined by DES.These components give a certain order of events to occur and therefore exclude certainother orders of events. Another option, which can be used in STS and is explained laterare logical expressions.

DES Basics

In this subsection, the basic idea of DES is given. An automaton, which models a DES,can describe the behavior of a simple machine or components of a bigger system.The set of states in a DES is called the state space Q. From one state to another canbe done by a transition. A transition always has a state from which it starts, an eventwhich occurs and a state in which the transition ends. The set of possible events is called, which are used in the set of transition functions . An event can be controllable oruncontrollable, in other words: it can be chosen (controllable) or occur spontaneously(uncontrollable). The initial state is q0, q0 Q. The final states are called markerstates, QmQ. An automaton can have one or more marker states. A quintuple can


17/126

1.2. SCT Basics 5

describe the automaton:

G= (Q, , ,q o, Qm) (1.1)To clarify the use of an automaton, next an example is shown of a machine representedby an automaton.

Example of a machine Consider a single machine with 3 states, seeFigure 1.2. From the initial stateI(Idle) the machine can make a transition to the state W (Working). The event means starting a task or taking aproduct out of the upstream buffer and start producing it. The transitionfrom I to W is a controllable event, this is shown in the figure by a filledline. The transition from W back to I is uncontrollable as well as thetransition to the down state D, this is shown by a dashed line. Thetransition means that the product is finished and put in the output binor the downstream buffer. If transition occurs, the machine breaks down,the product in question is not finished. In D the system is down or brokenand has to be repaired. The transition is again controllable and returnsto I. The system is repaired and can start its work cycle again. Thisautomaton can be defined as:

M= ( {I,W,D} (the states), {,,,} (the events)

, {(I , , W ), (W,,I), (W,,D), (D,,I)} (the transitions), I (the initial state), {I} (the marker state (s)))

The events are either controllable or uncontrollable:

c ={, } (controllable) (1.2)

u ={, } (uncontrollable) (1.3)

synchronization Multiple automata can be synchronized. In the SCT the events inthe automata are synchronized based on their name. Which means that if event A occursin two automata, event A can only be done when it can be done in both automata. Thesynchronous product couples automata by synchronizing the events based on the nameof the events.


18/126


I

W

Di

i

i

i

Figure 1.2: Schematic representation of automaton M

Supervisor properties

A supervisor meets certain criteria next to system properties. In the next paragraphs,these criteria are discussed. To visualize what these criteria are, an automaton is shownon which these criteria are applied step by step. This automaton is an abstract example.Normally the criteria are examined on more automata after they are synthesized, herehowever only one automaton is used to visualize the criteria. The automaton can beseen in Figure 1.3. The criteria which are explained and how they are fulfilled by theSTS tool are: Controllability, Reachability and Blocking.

0

1

9

2 3

45

6

7 8

desired behavior states to be blocked

Figure 1.3: Automaton to explain criteria

Controllability The controllability criterion means that all states which are not al-lowed, have to be avoided. This can only be done by blocking controllable events. Inother words, controllability implies uncontrollable events invariance, only controllableevents can eb blocked. In the automaton of Figure 1.3 it can be seen that state 8 is notallowed according to some constraints on the system. To avoid that the system gets into


19/126

1.2. SCT Basics 7

this state, the event which leads to that state has to be blocked. However this event is

dashed which means that it is uncontrollable and therefore it cannot be blocked. So toavoid state 8, the event from state 3 to 7 has to be blocked. Now all states that canoccur fulfill the controllability criterion.

Reachability Reachability at itself is not a criterion in the SCT. However, to explainwhat blocking is, first the reachability of a state has to be explained. Each state thatis can be reached by transitions from the initial state is called reachable. Co-reachablemeans from a state it is possible to reach a marker state (end state). If again theautomatan of Figure 1.3 is considered it can be seen that state 9 is not reachable. TheSTS tool removes the states which cannot be reached from the initial state. After thesetwo criteria the automaton looks like Figure 1.4.

0

1 2 3

45

6


Figure 1.4: Automaton after some criteria

The reachability property is defined by:

Definition (Reachability predicate, R(G, P) ) Let G =(ST ,H, , , P0, Pm) be an ST S then the reachability predicate R(G, P)

contains all basic state trees that can be reached from the root state ofGvia state trees satisfying predicate P. A basic state tree b is in R(G, P) if:

1 IfP P0= false then R(G, P) =false.

2 Ifb0|=P P0 then b0|=R(G, P).

3 If b |= R(G, P), , (b, ) = , (b, ) |= P Then (b, ) |=R(G, P).

4 No other basic state trees satisfy R(G, P).


20/126


Nonblocking Next the blocking criterium is examined on this automaton. Blocking

means that a state or a group of states can be reached where it is not possible to reacha marker state. It can be seen as a sort of dead end in the state space. It is possibleto get there, but it is impossible to leave. Blocking can be divided into two groups,deadlock and livelock. Livelock is a case where a group of states is reached from whichit is not possible to reach a marker state, however transitions remain possible betweenthose states. Deadlock happens if a state is reached where no exit transition is possible.If the blocking criterium is applied on the automaton of Figure 1.4, it can be seen thatstate 3 can be reached from the initial state but it is impossible to reach a marker state.There is no transition leaving from state 3 so this is a deadlock. To avoid this stateto occur again a controllable event has to be blocked. In this automaton state 3 canonly be avoided to occur by blocking the transition going from state zero to state two.

By applying this criterium again the previous criteria have to be examined. Applyingagain all the criteria leads to the supervisor of Figure 1.5.

0

1

5

6


Figure 1.5: The supervisor

It can be seen that the final supervisor is much smaller than the automaton beforethe criteria are applied. An algorithm for this can be found in [Mat87], which uses afunction for detection of resource conflicts, deadlocks and unsafe regions. The definitionof nonblocking is defined by:

Definition (Nonblocking)LetG= (ST ,H, , , P0, Pm) be anST SandR(G, P) and CR(G, P) be the reachable and co-reachable predicates ofP,respectively. Then predicateP is non-blocking if: R(G, P) C R(G, P). Inother words, P is nonblocking if all states in P that are reachable are alsoco-reachable.


21/126

1.3. The STS basics 9

1.3 The STS basics

State Tree Structures (STS) is a method which uses the the supervisory control theory,in this section some principles of STS are explained. First statecharts and automata areexplained, statecharts are used as a basis in STS. Afterwards, the supervisor generatedby STS is explained by an example.

Statecharts and automata

STS uses statecharts of Harel [Har87]. In a State Tree (which is a statechart) it is definedhow all components are connected with eachother. In the statecharts it is possible to

use OR and AND components in a tree structure. It offers a compact representation ofhierarchy (vertical) and concurrency (horizontal) structure in finite state machines. Avertical structure can be used for more details. A state working example can have twosub states, representing the different working speed or the needed resources for working.In Figure 1.6, a State Tree of two machines and a buffer can be seen. The machines arerepresented as M1 and M2 and have components Idle, Working and Down. The statesB, M1 and M2 are coupled as AND components which can be seen by the X betweenthe states B, M1 and M2. This means that the superstate of them, in this case thesystem is an AND superstate. Therefore a state of the system must have a componentof each AND component. The component B is an OR superstate, this can be seen bythe sign between the two states below B . This means that the component B has one

active state, B 1 or B 2. A state of the system for example could be (I2, B1, I1).

System

B

B1 B2

M1

I1 W1 D1

M2

I2 W2 D2

XX

Figure 1.6: STS of 2 machines and a buffer

The State Tree is only the structure in which the separate components are coupled.The state Tree does not say anything about the possible transitions that can be done.For the transitions the automata are needed. The STS of Figure 1.6, describes that thesystem consists of three components which work in parallel. In Figure 1.7 the actualsystem can be seen. Here it can be seen that Machine 1 fills the buffer and Machine2 receives products from this buffer. In this system the buffer is assumed to have only


22/126


one place available, so the buffer can contain 1 or no product.

The automata of Machine 1 and 2 and the buffer can be seen in Figure 1.8 and 1.9.

Machine1 Buffer Machine2b1 a2a1 b2

Figure 1.7: The 2 machines with a buffer

In all automata the initial state is indicated with an arrow towards a state (no startingstate). A marker state with an arrow leaving the state without going to another state.In these figures, the filled lines are the controllable events and the dashed lines are theuncontrollable events. A machine has states Working, Idle and Down, the event b1going from the Working to the Idle state in machine 1 is also present in the buffer. Inthe buffer this event changes the state from the buffer from B1 to B2, which meansthat the buffer is going from the empty state to the filled state. Since these events havethe same name, STS synchronizes them. So for defining a system, the automata haveand the State Tree must be defined.

I1

W1 D1

b1

a1

l1

m1

I2

W2 D2

b2

a2

l2

m2

Figure 1.8: Machine 1 and 2

B1 B2

b1

a2

Figure 1.9: The buffer of the 2 machines

The Binary Decision Diagram

In order to represent the supervisor in a compact way the STS tool uses logical expres-sions. Logical expressions are used to express what states are possible and in what statethe system must be in to perform a certain controllable event. Only the controllableevents of the system are represented by these logical expressions because they can be


23/126

1.3. The STS basics 11

controlled by the supervisor. Uncontrollable events only occur when the system is in

the right state and the supervisor cannot influence them. These logical expressions areexpressed by Binary Decision Diagrams (BDDs). BDDs are used because they canrepresent states in a compact way, writing all possible states in a table requires muchmore space and thus more memory. First an example of a BDD is examined for a simplelogical expression. After that a BDD is defined for one automaton.

Example BDDImagine the logical expressionX1 X2. Which means that this expressionis true if one of the two components is true. So X1 and X2 are a boolean,which can be true or false. If now the true and false are represented bya type of line this expression can be graphically represented. For the true

value a filled line is chosen and for a boolean being false a dashed line. Nowthe logical expressionX1 X2 can be represented by Figure 1.10.

Figure 1.10: X1 or X2 with a BDD

However, the states of a machine for example are not a boolean, therefore the statesare numbered binary. So if we number the states of for example machine 1 of Figure1.8 in a binary way, the three states are numbered 00 01 and 10. Since it is numberedbinary a number can only be one or zero. This way again the two line types can beused to represent a binary number. However, for representing a binary number notonly the number is needed. As we can see the number one or zero also has a position,the position is numbered from the back to the front starting with 0. So if we take thebinary number 10 this can be represented by a dashed line with corresponding position0 and a filled line with corresponding position number 1. As can be seen in previousexample, information can be stored in the nodes (the X1 and X2). In the BDDs usedin STS the nodes contain the name of an automaton and the position number. So if wetake again automaton M1, it can be represented by Figure 1.11.

Actually the STS tool does not represent the states as a BDD but as a Reduced OrderedBinary Decision Diagram. A BDD isOrdered(OBDD) if on all paths through the graphthe variables respect a linear order A < B < Cmeaning that a node for machine A is


24/126


Figure 1.11: M1 represented by a BDD

always above a node from machine B in the BDD. The order in the BDDs generatedby the STS is alphabetically, meaning the top automaton in the BDD comes earlier inthe alphabet then the second. Using another ordering method leads to another BDDgiving the same states. It can be imagined that the calculation time depends of theordering of the automata.A (O)BDD is Reduced if [And97]:

(uniqueness) no two distinct nodes u and v have the same variable name andlow and high successors.

(non-redundant tests) no variable nodeuhas identical low and high successors.

These requirements for the BDD to be non redundant and unique can also be representedby the automata of Figure 1.12. If a BDD is mentioned in this report it is actually aROBDD.

X X Y

Figure 1.12: Example of uniqueness (left) and redundant (right)

Requirements in STS In order to control the system, requirements can be added.In STS, this can be done in 2 ways:

Describe the requirements with logical expressions.

Describe the requirements with automata.


25/126

1.4. Verification tools 13

Of course also a combination of these two can be used for defining requirements. When

describing the requirements with logical expressions there are two types available inSTS:

A state exclusion, the system may not be in a certain state combination.

A state transition exclusion, when the system is in a state, a certain transition isnot allowed to happen.

1.4 Verification tools

Different tools are used to check whether the intuitively defined automata define thedesired behavior. The automata are made intuitively so it needs to be checked whetherthe intuition of the person who modeled it is correct. Especially the requirementautomata need extra attention, because they are based on a path and can have sideeffects. In this section, several verification tools are discussed and their advantages anddisadvantages are explained.

Diagraphica [Pre06] can be used to verify the correctness of the supervisor. Thismeans that it can be used to check whether the automata which are defined intuitivelydefine the desired behavior. The desired behavior is how the system should behave, thisbehavior needs to defined by the supervisor. For using Diagraphica the BDDs cannotbe used directly, they need to be translated into a table with all state combinationsand a list of the events between those states. This input file requires much more spacethan the BDDs which are the control functions. Since this input file is much bigger,the program runs out of memory when using large models. This is a disadvantageof Diagraphica, a solution could be to read the BDDs directly, unfortunately this isnot possible yet. In Figure 1.13, the example of the 2 machines, 1 buffer is shown inDiagraphica. In the top right block the states with the transitions are shown. In thedown right box, the transitions can be chosen in order to step through the system.In the left down box, a visualization can be seen. The visualization can be made bychoosing edit mode in the mode tab. In the left top box, the automata can be chosenwhich are clustered. The advantage of this is that you can check whether there exist acertain state combination without having all automata defined in which state they are.

In Diagraphica it is possible to view all valid states and the events that occur. Thestates are be shown by circles or other shapes and can differ in color or position. Theadvantage of Diagraphica is that it is possible to get a good overview of all possiblestates and transitions. Another good option is the possibility to do the transitions andstepping through the supervisor. This way it can be seen which paths can be taken.


26/126


Figure 1.13: The 2 machine, 1 buffer system in Diagraphica

The STS simulator [Zee07] is developed to check whether the supervisor generated

by STS defines the desired behavior. In other words: are the automata correct definedsuch that the desired behavior is defined by the supervisor. So actually it is used tocheck whether the intuition for modeling the automata that way is correct. In Figure1.14, a picture is shown of the two machine, 1 buffer example explained earlier.The python script uses the automata from the input file to search what controllableand uncontrollable events could occur using the current state. So it checks in eachautomaton what event can occur in that state and what events are blocked becausethe automaton is not in the correct state. The BDDs generated by the STS are thecontrol functions, they determine in which states a certain controllable event can occur.The possible controllable events according to the automata are checked on their controlfunctions. When defining a system, two types of automata can be defined, component

automat and requirement automata. The requirement automata are used to definea certain behavior. In the python script these requirement automata can be set asrequirements by. (File, set Requirements) By setting certain automata as requirementsin the STS simulator it can be seen which events are blocked by these automata. In thefigure of the STS simulator, at the top three boxes can be found.

The left box gives all the possible events according to the automata.

The middle box gives the events that are blocked by their control function. Acontrol functions can block an event to ensure that the supervisor satisfies the


27/126


Figure 1.14: The 2 machine, 1 buffer system using python

nonblocking condition and the logical expressions.

The right box gives all events that are being blocked by the requirement automata(to be defined in the STS simulator).

The advantage of using this validation method is that it uses the BDDs of STS, thereforeit is capable of handling very large systems. A disadvantage is that it is not possibleto get a good overview of the state combinations of the separate automata, which ispossible with Diagraphica. A good addition to the STS simulator could be to checkwhether a certain combination of states is present. However to do so the state for each

automaton has to be defined, while in Diagraphica certain automata could be clusteredto see what combination of those automata occur in the supervisor. So it is difficultto check whether for example automaton A in state 1 with automaton B in state 2 isa valid combination without having to defined other automaton of the system. Alsothe building of a canvas (visual representation of the states) is a bit more complicatedthan using Diagraphica. A manual of this python script and the script are available onseweb.se.wtb.tue.nl/sewiki


28/126


Labview (Laboratory Virtual Instrumentation Engineering Workbench) can be

used when the supervisor is connected to its resource controllers. In Labview it canbe checked if the resources act as desired. Labview can be used instead of the realhardware, this way it is possible to simulate the behavior instead of applying directly onthe hardware. Labview uses the signals the resource controllers send to the actuatorsand receive from the sensors. This tool can be considered as the low-level check. InFigure 1.15, a picture is shown of Labview with a Paint Factory which is used as a casestudy in this report. The supervisor that is checked can be more abstract than thereal hardware, therefore the commands of the supervisor can be translated into tasksfor the resources. Also time or certain values can be added. For example, lift receivesthe command go up. At what time the lift is up needs to be defined because no realhardware is used. Also values for example for a flow sensors need to be defined. In

Labview the control of the valves, pumps etc. is shown using the resource controllersfor the control. The resource controllers receive their commands from the supervisor.

Figure 1.15: The Paint Factory represented in Labview

Generally the STS simulator is best suited to check whether the automata are definedin such a way that the correct behavior is defined by the supervisor. Diagraphica canbe used when part of a model is defined and needs to be verified. Diagraphica gives agood overview of all state combinations and can also step through the different states.


29/126


Labview be used to check the behavior of the system at a more low-level. So actually

Labview is the last tool to use before the resource controllers are connected to the realhardware.


30/126



31/126

Chapter 2

Defining requirements

In this chapter, an example is used to explain the different methods of defining therequirements. Also the effects of the different ways of defining is explained. Finally amethod for modeling is formulated, this method is used in the case study of the paintfactory. In this chapter an example of a lift, a pusher and a product holder is used.This system is shown in Figure 2.1.

LIFT

PRODUCT HOLDER

PUSHER

PRODUCT

STORAGE LOCATION

Figure 2.1: The pusher, lift product holder example

Three different ways of modeling the components and the constraints of this system arecompared. First the way of modeling from the lectures of Supervisory Machine Control[Mor05] is considered, where the requirements are defined by automata. Subsequentlysome of the requirement automata are replaced by logical expressions. As a consequencethe automata that describe the machine must be changed. Finally, all requirements aredefined by logical expressions. The requirements have to constrain the system in such

19


32/126

20 Chapter 2. Defining requirements

a way that the system behavior fulfills the following specification:

A product may only be put on if the product holder is empty, the lift is down andthe pusher is retracted.

The lift may only go up when the pusher is retracted and there is a product onthe product holder.

The lift may go down when there is no product on the product holder and thepusher is not extending.

The pusher may only push the product out, if the lift is up.

This way the pusher, lift and product holder act in such a way that at the down positiona product can be put on. When a product is put on, the lift can move up where theproduct is pushed of by the pusher. After the product is pushed of, the lift can movedown to get a new product. These actions can be repeated forever.The automata used to model the lift, the pusher and the product holder are shown inFigures 2.2 through 2.4. A controllable event is indicated with a filled arrow and anuncontrollable event is indicated with a dashed arrow.

2 0 1

Lrd0 Lwc1

Lrd1Lwc0

0 = Idle1 = Going Up2 = Going Down

Figure 2.2: The lift with 3 states

2 0 1

Prd0 Pwc1

Prd1Pwc0

0 = Idle1 = Extending2 = Retracting

Figure 2.3: The pusher with 3 states

0 Pr0 = Idle

Figure 2.4: The productholder

Using these automata in STS, the structure of how these automata are coupled in STScan be seen in Figure 2.5. In the State Tree, the three automata are coupled as AND


33/126

2.1. Automata as requirements 21

components of the system. They are all part of the system, thats why they are located

directly underneath the system in the State Tree. A state of the system must nowcontain three arguments, one of each automaton. STS determines the state space andthe control functions. These control functions determine when a controllable event canoccur.

System

Productholder

P

Pusher

Idle Ex Re

Lift

Idle Gu Gd

XX

Lift Idle = Lift is not movingLift Gu = Lift going UpLift Gd = Lift going DownPusher Idle = Pusher is not movingPusher Ex = Pusher extendingPusher Re = Pusher RetractingP = Product holder

Figure 2.5: STS of the lift, pusher and product holder

In the next three sections the requirements on these components of the system aredefined into different ways. First the automata requirement of the lecture notes areconsidered. Subsequently some of the components are modeled in a different way suchthat some of requirements can be defined by logical expressions. The effect of the logicalexpressions on the size of the BDDs is examined. Suggestions are made to be able todefine all requirements by logical expressions. In last section where the requirementsare evaluated, all requirements are defined by logical expressions. In the last sectionmodeling rules are formulated based on the evaluation of how requirements can bedefined and what is needed for this.

2.1 Automata as requirements

Previously the lift and pusher with their corresponding automata are introduced anddescribed. In these automata, the lift and the pusher have an idle state, and 2 statesin which they are moving in a certain direction. Using the transition from the movingdirection to the idle state will give the system information where the lift or pusher is.The component automata are modeled very compact, meaning that not all physical


34/126


positions are described. In the example of the lecture notes, all requirements are set

by automata. In this first examination of the requirements this is also done. Thecomponent automata (lift, pusher and product holder) together with the require-ment automata of Figures 2.6 and 2.7 are used define a correct supervisor for the system.

0 1

Pr

Lwc1

0

1

2

Pwc0 Pwc1

Lrd1

Figure 2.6: Requirements 1 (left) and 2 (right)

0 1

Prd1

Lwc0

0

1

2

3

Prd0 Lrd0

Pr

Prd0Lrd0

Figure 2.7: Requirement 3 (left) and 4 (right)

Requirement 1 constrains the model in such a way that the lift only can go up ifthere is a product on the productholder.

Requirement 2 constrains the model in such a way that after going up, the pusherhas to go out and in.

Requirement 3 constrains the model in such a way that after the pusher is extended

the lift goes down.

Requirement 4 constrains the model in such a way that before a product can beplaced on the productholder, the pusher must be retracted and the lift must bedown.

The requirements defined in terms of automata appear in the BDD of the state spaceand in the control function (also BDDs) as can be seen in Figure 2.8. In this exampleall requirements are represented by automata. Automata can appear in the BDDs.This depends whether they restrict that event. This means that the the number of


35/126

2.2. Automata and logical expressions as requirements 23

nodes increase in the BDDs. In Figure 2.9 the BDD of the state space is given. The

control functions for each controllable event are the supervisor of the system. The statespace BDD is used to check whether the initial state is correct.

0 1

PS_0

PS_1

R2_0

R2_1

0 1

R2_1

Figure 2.8: The state conditions for the controllable transition P wc1

The two BDDs of Figure 2.8 give the states in which the controllable event P wc1 maybe done. The left is the eligible state condition, it is the physical condition togetherwith the condition of the memory. The right BDD is the enabled function; here allmemory functions and states as a consequence of the logical expressions are present.

As can be seen in the state space BDD, which can be seen in Figure 2.9 the requirement

automata do appear. The number of nodes in this case is 37. The number of states thatare represented by this automaton is 13, which corresponds to the number of states insupervisor defined in the lecture notes. Also the transitions match the supervisor of thelecture notes. This supervisor can be seen in Figure 2.10.

2.2 Automata and logical expressions as requirements

In the previous model, the states of the lift and the pusher automaton differ in motiondirection but there is no difference in state for the different positions of those compo-nents. To be able to replace a requirement automaton by a state exclusion it must beknown in which position those components are. So a state must represent a physicalstate. In the used automata this was not the case. So in order to replace a require-ment automaton with a state exclusion with logical expressions, the automata of thecomponents have to be modified. For this reason the lift and pusher are defined by theautomata of Figures 2.11 and 2.12. In these automata the idle state is split into twostates which are the two positions at which the components can stop.

Using the automata of Figures 2.11 and 2.12 to model the system, some requirementscan be defined in terms of state exclusions. Since the product holder is not changed and


36/126


37/126

2.2. Automata and logical expressions as requirements 25

1

2

3

0

LWc1LRd1

LWc0LRd0

0 = Going Down1 = Down (idle)2 = Going Up3 = Up (idle)

Figure 2.11: The lift using 4 different states

1

2

3

0

PWc1

PRd1

PWc0PRd0

0 = Retracting1 = Retracted (idle)2 = Extending3 = Extended (idle)

0 Pr0 = Idle

Figure 2.12: Model of the pusher with 4 states and the productholder with 1 state

there is only one state in the product holder, while there are two physical states, therequirement automata which have an event from the product holder cannot be definedby logical expressions. In the next section the automaton of the product holder will bechanged in such a way that all requirements can be defined as state exclusions or statetransition exclusions. The requirements of previous section which could be changedbecause the automata of the pusher and lift changed, are requirement automaton 2 and3. These automata restrict the system in such a way that:

The pusher has to extend after the lift is up.

After the pusher is extended the lift goes down.

The lift may not go up when the pusher is extended.

These requirements can be defined by the following logical expressions which are stateexclusions on the system:

1 Lift down - Pusher Extending2 Lift going up - Pusher Extending3 Lift going up - Pusher Extended4 Lift going up - Pusher Retracting5 Lift going down - Pusher extending


38/126


0 1

LS_0

LS_1 LS_1

PH

PH

PHPH

PS_0

PS_0 PS_1

R1

R1

R4_1

R4_0

PS_1

PS_0PS_0

PS_1 PS_1

R1

R1

R1

R4_0

R4_1

PS_1

Figure 2.13: The system state space with requirements in terms of automata and logicalexpressions

The first two state exclusions constrain the system in such a way that the pusher canonly extend if the lift is up. It is not possible for the pusher to extend when the lift is

going down because. This automatically blocked because an uncontrollable event fromthis state leads to a state (pusher extending and lift down) which is blocked by thespecifications. This is known as the controllability condition which is explained in theprevious chapter. The state exclusions three and four, constrain the system in such away that the lift can only go up if the pusher is retracted. The last state exclusionprevents the lift from going down when the pusher is extending. So the lift can onlygo down after the pusher is extended. An advantage of modeling the system this wayis that the BDD size reduces. A disadvantage is that defining the logical expressions ismore difficult than using automata for the requirements. Using these requirements thenumber of nodes required to define the state space is reduced from 37 nodes in Figure2.9 to 25 nodes in Figure 2.13.

By using both automata and logical expressions for requirements there is more choicein the way the requirements can be defined. Although in this case the requirementautomata are replaced with logical expressions, it is still possible to use them. So bymodeling the physical state of the components it is possible to define the requirementsin different ways. The use of logical expressions decreases the number of nodes in theROBDDs. This does not say anything about the calculation time, more on the memoryused for storing the nodes.In the next section the product holder is also modeled by its physical states, then allrequirements can be defined by logical expressions.


39/126

2.3. Logical expressions as requirements 27

2.3 Logical expressions as requirements

In last section the pusher and lift are modeled by their physical states. In this sectionalso the product holder is defined as its physical states. This is done to be able todefine all requirements by logical expressions. For this reason the product holder isdefined by two states, which are:

0 = there is no product on the product holder1 = there is a product on the product holder

Using these states, the automaton defines the physical states of the product holder.The automaton of the product holder is shown in Figure 2.14.

0 1

PWc1

Pr

1 = Product0 = No Product

Figure 2.14: Model of the productholder with 2 states

For the lift and the pusher, the models of the previous section are used. Whendescribing each physical position as a state, for this case it is possible to define therequirements by logical expressions. These logical expressions can constrain the pusher,the lift and the product holder in such a way that a correct supervisor can be derived.As already mentioned in the first chapter there are two types of logical expressionsthat can be used in STS:

1 A state exclusion, requiring that the system cannot be in certain statesof different components at the same time.

2 A state-transition exclusion, excluding a transition in a certain state.In the case of the lift pusher problem, both are needed to define the requirements. Todefine that a new product can only be put on the productholder when the lift is downand the pusher is retracted, can only be done by a state-transition exclusion. Thetransition that is done is putting on a new product. The transition changers the productholder from having no product into having a product on. This transition should onlytake place when the lift is down. For the movement directions this is not a problem.

The lift can only move up with a product and down without one. If the lift is up, theproduct holder can have a product, but it can also already been pushed of. Thereforethe transition of putting on a new product has to be excluded when the lift is up.The state exclusion expressions, together with the state transition exclusions have toconstrain the system in the same way as the automata of Section 2.1 and are defined by:

State exclusion


40/126


Lift going up - - No product

Lift going up - Pusher extending - ProductLift going up - Pusher extended - ProductLift going up - Pusher retracting - ProductLift going down - - ProductLift Down - Pusher extending -

The combination of the lift going up without a product on the productholder isexcluded. Therefore the lift can only go up with a product on the product holder.This puts restrictions on the pusher. It is only allowed to be in the retracted position,which explains the next three state exclusions. After the lift has gone up the producthas to be removed, so the state in which the lift goes down with a product on it isexcluded. It is not important in which sequence the lift is going down and the pusher

is retracting. What is relevant is that the pusher is not allowed to extend again whenthe lift is down, this explains the last state exclusion. Otherwise the supervisor thinksthat the product is removed by the fact that event P wc1 occurred, while the productmay only be removed when the lift is up. The state transition exclusions are definedas:

State-transition exclusionLift Up - Putting on a productPusher Extended - Putting on a productPusher Extending - Putting on a productPusher Retracting - Putting on a product

The first state transition exclusion one excludes putting on a product when thelift is up. Which is already explained. Another constraint is that the product mayonly be put on the product holder when the pusher is retracted. For this reason, thelast 3 state-transition exclusions are defined. Applying these logical expressions to thecomponent automata of Figure 2.11, 2.12 and the product holder of Figure 2.14 givesthe BDD of the state space of Figure 2.15.

As can be seen in Figure 2.15, the state combinations that are possible are representedby only 8 nodes. This can be explained by the fact that the requirements are now setas logical expressions and not by automata which appear in the BDDs. It is not said

that all of the states in the state space actually occur. This depends on the transitionsbetween the states, the program does not check whether a state is reachable. It onlydetermines the states which are allowed according to the requirements and can reacha marker state and do not have an uncontrollable event leading to a undesired state.By deleting the states which are not reachable, the supervisor as defined in the lecturenotes can be defined.In Figure 2.16 the BDDs of transition P wc1 are given. The left one represents theautomata at which that transition is in, the right one is a consequence of the constraintsadded to the system.


41/126

2.3. Logical expressions as requirements 29

0 1

LS_0

LS_1

LS_1PHPH

PS_0PS_0

PS_1

Figure 2.15: The ROBDD of the system using state exclusion

0 1

PH

PS_0

PS_1

0 1

LS_0

LS_1

Figure 2.16: The BDD of transition Pwc1

If the states that are not reachable are deleted and the control functions are applied to

the controllable events, an automaton can be made representing the supervisor of thesystem. This is the same supervisor as defined in the lecture notes and can be seen inFigure 2.17.

For more complex cases this is not an appropriate method since the size of the automatonand its required space will increase enormously. Therefore it is recommended to use thecontrol functions for the supervisor. In the next section modeling rules are formulatedsuch that the it is possible to define the requirements using the logical expressions.


42/126


104

7

3

1

92

0

8

12

5

6

Lrd0

Pwc0

Pwc0

Pwc0

Prd0

Lrd0

Prd0

Prd0Lrd0

P

Lwc1

Pwc1

Prd1

Lrd1

Lwc0

11

Lwc0

Lwc0

Figure 2.17: The automaton of the supervisor

2.4 Modeling rules

As was seen in the previous sections, there are different ways of defining the require-ments. The consequences of defining the requirements are also described. Logical ex-pressions do not occur in the BDDs, however they need a more precise state descriptionfor the component automata. The states must be defined more exactly with the physicalposition they represent. Requirement automata are useful for defining a certain orderin events, the disadvantage is that they occur in the BDD. A disadvantage of occurringin the BDD is that the BDD size increases unnecessary. Both types of defining therequirements have advantages and disadvantages. In order to use both possibilities thefollowing rulesare formulated for modeling the components.

Transitions in a component automaton order to go into a different state.

Transitions can be controllable or uncontrollable.

Only a state can take time.

Each state differs in position or moving direction.


43/126

2.4. Modeling rules 31

These rules for defining the automata ensure that it is possible to define the require-

ments by logical expressions. Requirements can often be divided into two groups: stateexclusions and sequential requirements. The first group can easily be formulated usinglogical expressions. The second group can be formulated by automata. So instead ofusing only one way of defining the requirements, both types are used.


44/126



45/126


46/126

34 Chapter 3. Case Study: The Paint Factory

to be cleaned. It forms the bottleneck of the machine. To be able to use the mixing

vessel in a more optimal way, buffer vessels are installed. This way the mixed paintcan be stored in a buffer vessel before it is sent to the filling station. Also the buffervessels need to be cleaned after they are used for a mixed color. For the cleaning, avessel with cleaning fluid is installed. The distribution of the fluids is done by pumpswhich are installed underneath each vessel. Finally, the colors from the primary colorvessels and the buffer vessels can be injected into the desired amount of cups at thefilling station. The filling station can choose which input it opens, from the primarycolor vessels or from one of the buffers. So mixed colors cannot be sent directly fromthe mixing vessel to the filling station.

In Figure 3.1, the schematic layout of the mock-up is given. In the upper left corner, the

three primary vessels (P c1, P c2and Pc3) are drawn. The cleaning vessel (C) is placednext to the primary vessels. All subsystems are connected to the cleaning vessel, so alleach the subsystems can be cleaned. The mixing vessel (M) is connected to the primaryvessels and drawn in the lower left corner. The three buffer vessels (B1, B2 and B3)are at the top right. There is a slide (Bm) which can move to a waste location and tothe buffer locations to send the liquid to the right position. The other slide (F m) canmove from the filling station to a waste location. In the mock-up several waste locationsare present, each location leads the fluid to the waste vessel. The waste produced bythe system is drained away to a large waste vessel (W) below the system. The vesselsand waste locations are connected by pipes and valves. The filling station consists of aturntable (T) with 12 cups.


47/126


48/126


Figure 3.2: A picture of the Paint Factory

The supervisor for the mock-up should be able to produce paint in different colors andnumber of cups. To be able to do this, the supervisor should be able to control thevalves, pumps, slides etc. This control must be done in such a way that colors only gothrough a cleaned pipe and no multiple colors use a pipe at the same time. The amountof fluid sent to a location is measured by flow sensors. A flow sensor (is assumed to) givea signal to the supervisor when the desired quantity is reached. This quantity dependson the proportion and the number of cups that are desired for a certain color. Sincethe proportion and the number of cups can differ also the amount of fluid that may gotrough can differ each time.

3.2 The modeling of the Paint Factory

In the SCT, a supervisor is synthesized from several automata. These automata canbe based on the function in the system or the orders which have to be made. So formodeling the mock-up choices have to be made on which the automata have to bebased. When a supervisor is defined it needs to control the components of the system.Therefore the choice is made to model automata based on the function in the mock-up. Components can be valves, pumps, slides etc. However, modeling the componentsthis way, many constraints are needed. Therefore it is wise to consider some valves


49/126

3.2. The modeling of the Paint Factory 37

or pumps together as one component. Another thing that can be done to reduce the

number of states is to model components in a more abstract way. This could be done forexample by leaving the pumps out the supervisor and controlling them together withtheir corresponding valves. To get a better overview of the components, the mock-up isdivided into different subsystems. The subsystems and their requirements are definedseparately. All models defining the subsystems are then synthesized to a supervisor forthe mock-up. In this section, a short description of the subsystems is given. Thesesubsystems, as already mentioned, differ in function in the factory. Of course otherchoices can be made for modeling. An argument for splitting the system up in this wayis that each subsystem can be implemented separately. This could be very helpful whenbuilding the system step by step (subsystem by subsystem). Based on the separatefunctions, the mock-up (Figure 3.1) is divided into the following subsystems:

The primary color subsystem: the components involved in the distribution of thepaint from their primary color vessels to the mixing vessel or to the filling station.

The cleaning subsystem: the components needed to clean the pipes and vessels(the valves and pump of the cleaning system).

The buffer subsystem: the buffer vessels and the components needed to distributefluid from and to the buffer vessels.

The mixing vessel subsystem: the mixing vessel with the components to send thefluid to a buffer vessel or waste location and the valve for letting the fluid in.

The filling station subsystem: the components needed to distribute the fluid toits end location, waste or cup location. It also involves the moving of the cups.

The flow sensors: the sensors that register the flow of the paint and determinewhen a valve needs to be closed.

Since the subsystems are chosen on their function, their complexity can vary. A moreprecise description of the subsystems and the components that are included in thesubsystems can be found in Appendix A. For all subsystems models are defined andmotivated using the modeling rules. Additionally the constraints on the subsystems aredefined. In the next example the slide above the buffer is modeled, the considerationsmade in the modeling proces are described.

Example: the slide above the buffers is part of the buffer subsystemand can be seen in Figure A.8. The slide is located above the buffer vesselsand determines where the fluid goes to, a buffer or the waste location.The slide moves valve Bv4 in every position. When it is assumed that thecommands that can be given to the slide are move left/right and stop, theautomaton describing the behavior of the slide can be defined as shown in


50/126


Figure 3.3: The buffer subsystem

Figure 3.4.In the automaton, no sensors are taken into account. This can be done

0 12

Move to right

Stop movingMove to left

Stop moving

0 = Idle1 = Moving to right2 = Moving to left

Figure 3.4: Proposition for the slide automaton

separately, the consequence is that the slide can stop at every location,which is not desired. So additional constraints have to be added, such thatthe slide can only stop at a buffer or waste location. Also the modelingrules state that for each position where the buffer stops a state must bedefined. If the slide and the sensors are considered as one component, theycan be defined as the automaton of Figure 3.5. In this automaton thesensors are integrated, such that signals that occur when moving from onelocation to another are known by the supervisor. This way it should bepossible to stop at the correct locations. However, if the supervisor acts

to slow the slide can overshoot a location. Also the control might not beoptimal. For an optimal control it could be desired that the speed of theslide decreases near the desired location such that overshoot is avoided anda higher average speed can be realized.


51/126

3.2. The modeling of the Paint Factory 39

po1 po2 po3 po4

t1r p2r t2r p3r t3r p4r

p1l t2l p2l t3l p3l t4l

Sb30Sb20Sb10

Sw10 Sb10 Sb20

right

stop

right

stop

right

stopleft

stop

left

stop

left

stop

Sb01 Sb10 Sb02 Sb20 Sb03

Sb02Sb20Sb01Sb10Sw01

Figure 3.5: The automaton describing the slide with sensors

po1 = The slide is stopped at the waste locationpo2 = The slide is stopped at vessel 1po3 = The slide is stopped at vessel 2po4 = The slide is stopped at vessel 3pir= The slide arrives at positioniand is moving to the rightpil= The slide arrives at position iand is moving to the lefttil= The slide has left position i and is moving to the lefttir= The slide has left positioni and is moving to the right

A supervisor is supposed to control the system controls behavior. This doesnot mean that the supervisor has to control every component. The controlof this slide can also be done at a lower level. This low-level controllercould be a PID controller or another sort of other low-level controllerensuring that the slide goes as fast as possible to the desired location. Thecommands that the supervisor can give to that low-level controller are: goto location i where i represents the position. The supervisor then receivesan event that the slide arrived. The supervisor leaves the control of theslide to the low level controller, it only has the information if it is moving

to a certain location or present at a certain location. The behavior for theslide can then be represented by the automaton shown in Figure 3.6.

The supervisor which is synthesized from the models of the subsystems is checkedwhether it specifies the correct behavior for the mock-up. This check on the supervisedsystem whether only the correct events can be done in each state, is done with theSTS simulator [Zee07] which is explained in Chapter 1. In the simulator it is checkedwhether the supervisor defines the desired design and respects the requirements. After


52/126


1a 2a 3a 4a

1

2 3

4

Arrive

Arrive

Arrive

Arrive

G22G23

G24

G21

G23

G24

G21

G22

G24

G21

G22G23

ia = Stopped at pos. ii = Moving to pos. i

Figure 3.6: The used automaton for slide B m

this is done the realization can be started. The realization starts in this case with asimulation. In the simulation, the resource controllers are connected to the supervisorand visualized with Labview to show that they behave as desired and that with theevents the correct resource is controlled.

3.3 Preparations for implementation

In the previous chapters an overview is given of what the properties of a supervisor are.In Appendix A the automata and requirements for the supervisor of the mock-up aredefined. However, as was already mentioned in the first chapter and as can be seen inFigure 3.7 not only a supervisor is required for controlling a system. In this section,preparations are taken for implementing the supervisor. Therefore the other controlcomponents are defined.

User interface for the mock-up

To be able to control the mock-up, jobs that have to be done are send to the supervisorby the user. In this subsection the jobs a user can give are explained. Additionalautomata are defined to be able to translate the jobs into a sequence of events for thesupervisor. These automata are implemented in the supervisor and a new schematiccontrol scheme is defined.As can be seen in Figure 3.7, a user sends commands to the supervisor which jobs haveto be performed. In the supervisor only commands for the valves and slides are defined.The supervisor can, as defined at this moment, only take events for the components in


53/126

3.3. Preparations for implementation 41

User

Supervisory Controller


actuators sensors

System

tasks

resources

Figure 3.7: Schematic view of control

the mock-up. If the user gives an optimal schedule of events (commands for the valvesand pumps), this can be sent to the supervisor. However, the purpose of this researchis not to define an optimal schedule for the mock-up, but to give a proof of concept forsupervisory control based on STS. For this proof, the mock-up is chosen as a case study.The user for the mock-up can be considered as a person giving orders like: 5 cups ofpurple. To be able to translate these orders into events for the supervisor, additional

automata have to be defined. These automata give a certain sequence of events tomake a specified color. Since the mock-up can do tasks in parallel, automata have tobe defined defining the parallel processes of the colors. An automaton which definesthe paths of the colors to the mix vessel and to the buffer vessels. Another automatawhich defines the filling of the cups. It defines the paths from the the primary colorvessels and the buffer vessels to the filling station. The process of cleaning the buffercan also take place in parallel with these automata. This is not defined because the userwould not give orders like: clean buffer 1. Of course these automata do not excludethe events for cleaning, so it can still be done in parallel.

The mixed colors are made in the mixing vessel. It is assumed that primary vessels1 through 3 contain respectively red, yellow and blue paint. In the automaton of Figure3.8 the color green is defined, the other mixed colors are not shown due to the complexityof the automaton. In this automaton it can be seen that for the green color, the primaryvessels 2 and 3 are used (valvesP v2band P v3bare opened). Due to constraints definedearlier it is not possible to have two primary colors going to the mixing vessel at thesame time. Also the constraint that the emptying of the mixing vessel can only bedone after the filling is ready is defined earlier.

After a mixed color is sent to the buffer vessel (state 4), the mixing vessel will be cleaned


54/126


0

1 2

3

4

5

Open Cv 1b

Open C v1b

Open Cv 1b

Green

Open P v2b

Open P v3b

Open P v3b

Open P v2b

Open Mv

Open M v

0 = Idle1 = Start making green2 = Yellow to mix vessel3 = Blue to mix vessel4 = Green in mix vessel5 = Green in buffer vessel

Figure 3.8: Produce a mixed color

(Open Cv1b). After the mixing vessel is filled with cleaning fluid, it sends the fluid tothe waste location next to the buffers. In this automaton it is not defined to whichbuffer the mixed color is sent. In this automaton, the event green is new and neededfor the orders from the user. The other events are already defined in the automata forthe components and can be found in Appendix A.

The primary colors and the buffers send their fluid to the filling station. Only

one fluid at a time can go to the filling station. Because of this, all supplies to the fillingstation are combined into one automaton which defines the supply to the filling station.In Figure 3.9, the automaton is defined which defines the paths for the red color andbuffer 1. As can be seen this is a complex automaton, therefore the other colors andbuffers are not shown.

0 = Idle1 = Start making Red2 = Cleaning pipeP pi1 and the pipe in the filling station3 = Sending red to filling station4 = Filling station received red5 = Start emptying the buffer6 = Cleaning pipeP pi1 and the pipe in the filling station7 = Sending fluid from buffer 1 to filling station8 = Filling station received fluid from buffer 19 = Pipe underneath the buffers can be cleaned

As can be seen in the automaton, after the buffer contents is sent to the filling stationthe pipe underneath is cleaned. While after a primary color is sent, the pipe is notcleaned. This can be explained by the fact that after a red color is sent, another orderfor a red color can follow. After a green color is send from a buffer only the same green


55/126


56/126


Scheduling the mock-up

In Figure 3.7 it can be seen that in the original control schema the user sendscommands to the supervisor. Previously it is suggested that the user sends thedesired amount of cups to an extra controller. Even more tasks have to be per-formed by this controller. For example, it also chooses what event is done. If thecontroller receives all the information from the user and uses the supervisor to verifywhat events can be done, the new control schema can be defined as shown in Figure 3.10.

User Supervisor

Controller


actuators sensors

System

tasks

resources

Figure 3.10: New schematic view of control

In this figure the controller determines what event is performed, based on the user andthe supervisor. The controller receives from the supervisor a list of possible events.The controller chooses what event and sends event that is done to the supervisor.The controller also receives tasks that can be performed by the resources from theresource controllers. An event can be done if the resource controllers can perform thetasks corresponding to that event. The events with their corresponding tasks can befound in Appendix C. Based on this information the controller chooses an event withthe corresponding tasks for the resources. The choice that is made is based on the

available resources and the possible events. The scheduling the controller performs canbe described by performing an event as soon as possible. Sometimes it is better to waitfor some possible actions instead of sending an event. This is explained in the nextexample.

Example of scheduling Imagine there are three machines, called A, B and C. Onthese machines two jobs have to be performed:

Job 1: A3, B10, A2


57/126

3.3. Preparations for implementation 45

Job 2: C4, B1, C11

Job 1 has 3 subsequent tasks to perform: A for 3 time units, B for 10 time units andA for 2 time units. Scheduling the jobs by allocating the tasks as soon as possible to amachine leads to the schedule of Figure 3.11.

If the second job of the first order is not applied instantly but swapped with the second

Figure 3.11: Schedule of jobs as soon as possible strategy is applied

task of the second job the schedule is defined by Figure 3.12. Of course this is not alwaysthe case. In order to have an optimal schedule, for each possible schedule its durationmust be calculated. For cases with numerous jobs and tasks the number of schedulesto consider is very large.

Figure 3.12: Optimal schedule for the 2 jobs

For the control of the mock-up also a scheduling strategy is needed. Although it is notoptimal the strategy as soon as an event can be performed it is performed is chosen.It is beyond the scope of this project to apply an optimal schedule. Considering thechosen strategy for the mock-up, additional attention must be paid to the slide abovethe buffers. The slide can move to a certain location without a fluid can be send to thatlocation. For example, the slide is above buffer 1 and that buffer is filled. Now the slidecan move to another location, what is needed is that the slide goes to a buffer and notto the waste location. To avoid that the slide goes to a buffer which is filled or moves

without a fluid is send to that location, a scheduler is made.

Scheduling the buffer slide

Buffers can contain different fluids. To avoid the slide above the buffers moving to abuffer which is filled, different things can be done. It is possible to exclude the transitiongoing to a buffer location if that buffer is filled. Another option could be to give a certainorder of filling and cleaning the buffers. This way the supervisor can define te correctpaths which fill the buffers in a fixed order. The first option is rather difficult. In the


58/126


first option stil a choice can be made when multiple buffers are empty. This on itself

is not a problem. However, if no fluid is send and the slide starts moving again, it canoccur that a fluid is ready to be send while the slide is moving. Therefore the secondoption, defining an automaton which gives the filling order, is chosen. This automatonis implemented in the supervisor. In Figures 3.13 and 3.14 two automata are definedwhich ensure a certain order in which the buffers are filled and cleaned. As was alreadymentioned this schedule is not always optimal. This scheduling automaton ensuresthat the slide does not move unnecessary. When an optimal schedule is defined

Master s Thesis - Nard Hoefnagels 420519

Documents

Transcript of Master s Thesis - Nard Hoefnagels 420519