Master Thesis Se420492 - j.hamer

8/12/2019 Master Thesis Se420492 - j.hamer

1/121

Model Based Engineering of a PaintFactory with Supervisory ControlTheory

J. Hamer (Jorn)

SE 420492

Masters Thesis

Coaches: Prof. dr. ir. J.E. RoodaIng. H.W.A.M. van Rooy

Eindhoven University of Technology

Department of Mechanical Engineering

Systems Engineering Group

Eindhoven, April 2007


2/121


3/121

Preface

You are reading the result of the work of my final assignment to become a Master ofScience. This thesis finishes a five year curriculum at the Department of Mechanical

Engineering of the Eindhoven University of Technology. The final years I spent withthe Systems Engineering Group. The choice for this group was pretty obvious for me;the second year course Modeling of Industrial Systems and the overall research themeof this group appealed very much to me.

Fortunately, I was wise enough to explore all facets of the student life during my study.Becoming a graduate does not only mean follow the lectures and pass the exams, youcan learn a lot more than that. My student life included also living with other studenthousemates in Huize Bondstreet, visiting many get-togethers and parties, undertakingstudy related activities and most importantly joining the study association W.S.V. Si-mon Stevin and Rhetoricadispuut Tau. My membership of the 45th board of Simon

was a valuable experience, having contact with a lot of fellow-members, working hardin a team and organizing a lot of activities.

My stay for an internship at the Politecnico di Milano in Italy was also a great expe-rience. The differences between the cultures made me realize that not all things areso obvious. The moment I came back at my university, I realized what special andagreeable relation exists between students and staff. Nevertheless, it was a great timeand I enjoyed it very much.

All the above things also made sure I stretched the five year curriculum with a coupleof years, but for my benefit, I am convinced of that.

The last episode of my study was the masters project. With the professional help ofHenk van Rooy and professor Rooda, I completed a full year of research. With ups anddowns I reached my goals. I would like to thank them for coaching this research projectand for providing the necessary means to make sure that my stay at the Systems Engi-neering Group was a pleasant one. Also the help of many other staff members is muchappreciated. Some other thanks go out to all fellow students and PhD students at theSE-lab. Many of them pleasantly distracted me from my work with non-study relateddiscussions and activities, like the playing soccer outside (and sometimes inside the lab).

i


4/121

ii Preface

Last, but certainly not least, I would like to thank my family. They supported me my

entire study and did not limit me in my activities. I hope you can be proud of me,thanks to you all!

Eindhoven, April 2007

Jorn Hamer


5/121

FINAL ASSIGNMENT

EINDHOVEN UNIVERSITY OF TECHNOLOGY November 2006

Department of Mechanical Engineering

Systems Engineering Group

Student J. Hamer

Supervisor Prof.dr.ir. J.E. Rooda

Advisor Ing. H.W.A.M. van Rooy

Start December 2005

Finish December 2006

Title Model Based Engineering of a Paint Factory with Supervisory Control

Theory

Subject

The Systems Engineering Group is developing means and methods to design and to implement super-

visory control systems. To this end, the path of Model Based Engineering (MBE) has been chosen,

in which a complete system is developed, modeled, and tested by gradually replacing models of sub-

systems by real subsystems. This makes it possible to predict more accurately the performance or the

system at hand in a very early stage: simulation and testing can be done from scratch throughout the

complete development cycle.

A scaled down version of a paint factory is located in the laboratory. It has been created to serve as a

test and research environment for MBE.

AssignmentCreate a model to understand the dynamic behavior of the paint factory.

One of the ways to design and to develop the control system for a machine is to apply Supervisory

Control Theory (SCT). The possible states of the individual components are described by automata. The

required states of the system to be controlled are also described by automata. With these descriptions a

supervisory controller can be calculated.

Specify and design a supervisory controller for the paint factory. Apply Model Based Engineering as

the design method. Investigate the usefulness of SCT and the currently available development tools for

such systems. Make suggestions for further improvement of these tools.

Prof.dr.ir. J.E. Rooda Ing. H.W.A.M. van Rooy

Systems

Engineering Department of Mechanical Engineering


6/121

iv Assignment


7/121

Summary

Nowadays, a lot of attention is paid to the design and development processes of advancedsystems. 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 the system and also areduction in costs. The current approach must be adapted to the new demands of thedevelopment, faster and better. To achieve this, Model Based Engineering is developedat the Systems Engineering Group of the Department of Mechanical Engineering at theEindhoven University of Technology.

Model Based Engineering focusses on design in components. First, a set of require-ments for the system is created. From these requirements the design of the systemcan be made. The system is divided into components, for example the hardware, theresource controllers and the supervisor. If the requirements are set, the design can becreated. Essential is the use of formal methods. With formal models and formal require-

ments, a model can be validated and verified. These models are based on software, atthis moment there is no implementation of the models. If the models are validated withrespect to the design and verified with respect to the requirements, the realization canbe started. The components are realized separately. Each realization of a componentis tested with the models of the other components. With this method, failures can bedetected in an early stage of the development before the total system is realized and thesystem can be tested on bad weather behaviour. If all components are tested correctly,validated and verified with respect to the design and requirements, the system can betested.

As modeling language for the several components automata theory is chosen. With use

of the Supervisory Control Theory of Wonham the components can be modeled andsynthesized to obtain the supervisor of the system. The resources of the system canbe modeled intuitively as simple automata. By combining the different resources anunordered behaviour of the plant arises. All transitions of the system are possible andthe size of the state space is large. To reduce the size of the state space and eliminatethe unordered behaviour specifications can be added. A specifications can regulate thesequence of transitions. By adding the right specifications a supervisor can be synthe-sized. Only the desired behaviour remains.

Usually, small models are taken as examples to illustrate theories. For this research a

v


8/121


9/121

Samenvatting (Dutch)

Tegenwoordig wordt er veel aandacht besteed aan de ontwikkeling en het ontwerppro-ces van geavanceerde systemen. Door het verkorten van het ontwerp proces en het

verschuiven van de test fases kan tijdwinst geboekt worden. Dit is ter bevordering vande kwaliteit van het systeem en brengt ook een kostenreductie met zich mee. Van belangis dus om de huidige aanpak aan te passen aan de nieuwe wensen van de ontwikkeling,sneller en beter. Voor deze aanpak is de Model Based Engineering methode ontwikkeldbinnen de vakgroep Systems Engineering aan de faculteit Werktuigbouwkunde van deTechnische Universiteit Eindhoven.

Model Based Engineering spitst zich toe op het ontwerpen in componenten. Allereerstwordt van het systeem een eisenpakket opgesteld. Van deze eisen wordt vervolgens eenontwerp gemaakt van het systeem. Het systeem kan worden opgesplitst in componenten,bijvoorbeeld de hardware, de resource controllers en de supervisor. Als de componenten

gedefinieerd zijn, worden de eisen voor elke component opgesteld. Deze eisen moeten ineen formele taal uitgedrukt worden. Door de formele modellen en de formele eisen, kanhet model gevalideerd en geverifieerd worden. Deze modellen zijn software-matig, er isnog geen realisatie aan te pas gekomen. Als de modellen gevalideerd zijn op het ontwerpvan de component en geverifieerd op het eisenpakket, kan er worden begonnen met hetrealiseren van het component. Deze stappen gebeuren bij ieder component apart. Bijde realisatie van de componenten begint ook de integratie fase. Ieder component wordtapart getest met de andere modellen van het systeem. Fouten kunnen op deze manierin een vroeg stadium ontdekt worden voordat het gehele systeem gerealiseerd is en opdeze manier is het mogelijk om slecht weer gedrag te simuleren. Als alle componentengetest zijn en voldoen aan de gestelde eisen kan het gentegreerde systeem getest worden

op het ontwerp en de eisen van het systeem.

Als modelleertaal voor de afzonderlijke componenten is gekozen voor automaten theo-rie. Met behulp van de Supervisory Control Theory van Wonham kunnen de afzonder-lijke onderdelen van het systeem gecombineerd worden en kan een supervisor berekendworden. Alle verschillende onderdelen worden in een simpele en intutieve automaatbeschreven. Door het combineren van de verschillende onderdelen ontstaat er een onge-ordend gedrag. Alle transities in het systeem zijn nog mogelijk en de toestandsruimte isgroot. Om deze toestandsruimte te verkleinen en het ongewenste gedrag te elimineren,kunnen specificaties worden toegevoegd. Specificaties leggen volgordes van transities

vii


10/121

viii Samenvatting (Dutch)

vast. Door het toevoegen van de juiste specificaties kan een supervisor van het systeem

gesynthetiseerd worden. Enkel het gewenste gedrag blijft over.

Veelal worden kleine modellen als voorbeeld genomen voor het uitwerken van theorien.Voor dit onderzoek is een groter model gebruikt, de Verf Fabriek. De Verf Fabriek is eenopstelling in het laboratorium van de sectie Systems Engineering. Het is een schaalmodelmet verschillende onderdelen. De Verf Fabriek is ontworpen voor het parallel uitvoerenvan verschillende taken. De bedoeling is om voor de Verf Fabriek een optimale aan-sturing te ontwerpen om een orderpakket uit te voeren. Bij een volledige uitvoeringvan alle onderdelen is de gebruikte software (nog) niet toereikend genoeg om de totaletoestandsruimte te berekenen. Door toepassing van abstractie van het model is hetmogelijk om een supervisor te creeren van het systeem en kan er geoptimaliseerd wor-

den naar het minst aantal transities. In een later stadium kan deze supervisor wordentoegepast op het werkelijke systeem in het lab.


11/121

Contents

Preface i

Assignment iii

Summary v

Samenvatting (Dutch) vii

1 Introduction 1

2 Model Based Engineering 32.1 The V-Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.2 Paradigm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.3 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.4 ModelingM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.5 RealizationZ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.6 Overview MBE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.7 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3 Supervisory Control Theory 173.1 DES Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.2 Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.3 Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.4 Marker State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.5 Supervisor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.6 TTCT Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.7 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4 Case Study: Paint Factory 314.1 The Paint Factory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314.2 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344.3 Creating Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.4 Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.5 Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454.6 Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

ix


12/121

x Contents

4.7 Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.8 Integration and Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 474.9 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

5 Results 515.1 Supervisor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515.2 From Supervisor to Controller . . . . . . . . . . . . . . . . . . . . . . . . 525.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

6 Conclusions 55

7 Recommendations 57

Bibliography 61

A Visualization 63A.1 .tds Conversion to .ats . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63A.2 Dot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64A.3 FSM Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66A.4 Noodleview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66A.5 Diagraphica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

B Python scripts 71B.1 ads2stm.py . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71B.2 ads2fsm.py . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74B.3 ttct functions.py . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77B.4 run.py . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81B.5 specs.py . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82B.6 mutex.py . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

C A model for the Paint Factory in 1.0 85C.1 The processes explained . . . . . . . . . . . . . . . . . . . . . . . . . . . 85C.2 The model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

D Task-resource overview 95D.1 Conflicting tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

D.2 Conversion from TTCT integers to strings . . . . . . . . . . . . . . . . . 98

E Resources and Specifications of the Paint Factory 101E.1 Pumps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101E.2 Valves . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103E.3 Motors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105E.4 Description of the Mixer Specification . . . . . . . . . . . . . . . . . . . 106E.5 Description of the Buffer 1 Specification . . . . . . . . . . . . . . . . . . 106E.6 Description of a Task to Mix 2 Colors . . . . . . . . . . . . . . . . . . . 109


13/121

Chapter 1

Introduction

Nowadays, the economy is changing faster and faster. Manufacturing companies contin-uously need to make important decisions in order to remain competitive and to improvetheir market position. The success and continuity of industrial firms depend on theirperformance. The design of technologically advanced systems is becoming an increas-ingly complicated task. The products are becoming qualitatively better, the productionenvironments are becoming more complex, the total costs must be reduced and the timeto market must be shortened. All these requirements demand a lot of todays compa-nies, they seem to be paradoxes, but in fact a combination of these requirements brings

an optimal solution. To achieve the optimal solution a lot of research is done.One of these researches is the method ofModel Based Engineering(MBE). Model BasedEngineering is developed at the Systems Engineering Group of the Department of Me-chanical Engineering at the Eindhoven University of Technology. An embedded systemis a system in which the computer is completely encapsulated by or dedicated to thedevice or system it controls. When developing embedded systems, several phases withinthe development process can be distinguished, such as designing the system, integratingthe controller with the hardware, testing the behaviour, etcetera. These phases are of-ten organized in a certain process model, in order to indicate the order of, and relationsbetween, the different phases. By optimizing the process models, development phasescan be executed in parallel in order to reduce the lead time and development costs.

The Supervisory Control Theory (SCT) of Wonham is used as a method for automati-cally synthesizing supervisors that restrict the behaviour of a plant such that as muchas possible of given specifications or conditions are fulfilled. The plant is assumed tospontaneously generate events. The events are in either one of the following two cat-egories controllable or uncontrollable. The supervisor is part of the operating system,that regulates the flow of work. It observes the sequence of events generated by theplant and might prevent the plant from generating a subset of the controllable events.However, the supervisor has no means of forcing the plant to generate an event. Theformalism used in SCT describes Discrete Event Systems (DES).

1


14/121

2 Chapter 1. Introduction

DES encompass a wide variety of physical system that arise nowadays in technology.

These include many kinds of systems, such as manufacturing systems, traffic systems orlogistic systems. In most researches the focus is on small or theoretical examples. In thisstudy a larger and more complex system is investigated by the method of MBE,the PaintFactory. The Paint Factory is a mock-up in the laboratory of Systems Engineering. Themock-up consists of multiple resources which can be used for performing tasks in parallel.In the modeling process, the Paint Factory is considered a deterministic, discrete eventsystem. The main goal for this research is to specify and design a supervisory controllerfor the Paint Factory and apply Model Based Engineering as a design method.

Outline of this report

The structure of this report is as follows. First in Chapter 2, the path of Model BasedEngineering is introduced and explained. Chapter 3 describes how the SupervisoryControl Theory is used to design and to create a supervisor for a system. The casestudy and results are presented in Chapter 4 and Chapter 5. Finally, the conclusionsare discussed in Chapter 6 and recommendations are given in Chapter 7.


15/121


16/121

4 Chapter 2. Model Based Engineering

MBIT reduces realization costs and effort. In this approach the realization is

taken out of the testing and redesigning-loop. The realization is only done, afterthe model is tested and considered correct. Therefore, if the realization matchesthe model, the realization is correct the first time. Note, that the model is onlycorrect for the modeled aspects, so a bad or incomplete model increases the riskof errors in the realization.

The complete engineering path from scratch till realization is called Model Based En-gineering (MBE) and outlined in Figure 2.1. In this chapter the method of MBE isexplained step by step. In Section 2.3 the basics of Model Based Analysis are shown.In Section 2.4 the modeling of the components is described and in Section 2.5 theintegration and testing phases are explained.

Define

Define

Define

Design

Design

Design

Model

Model

Integrate

Integrate

Realize

Realize

Rs

R1

Rn

Ds

D1

Dn

M1

Z1

Mn

Zn

I 1...n

Figure 2.1: A Schematic Overview of the Model Based Engineering Method

In Figure 2.1 the phases of development are shown. A box in the figure, denotes adocument or realization and an arrow denotes the action that is taken in order to createthe next box. At the left end of the figure the development process initiates with thefirst R, the requirements of the system. The D, M and Z represent respectively thedesign, modeling and the realization. If the requirements are set and the design is madefor the system, the system can be divided into components. Now, for the individualcomponents the requirements and design can be made as well. Between those blocks

arrows are drawn. The labels of the arrows symbolize the actions that must be fulfilled.In the next sections the phases and actions are explained further.

2.1 The V-Model

The system development process is subdivided into multiple concurrent componentdevelopment processes. Subsequently the components are integrated into the system.The integration is a time consuming process. If failures are discovered in this stage


17/121

2.1. TheV-Model 5

User Requirements

System

Requirements

Requirements

System Design

Component

Component

Component Realization

Component Testing

Acceptance Testing

Integration andDesign

Design

System Integrationand Testing

Testing PhasesPhases

Figure 2.2: Rooks V-model

of engineering, the corresponding component has to be redesigned or redeveloped. Acommonly used process model for developing systems, is Rooks V-model [Roo86].

An example of a V-model is shown in Figure 2.2. The Vshows the typical sequence ofdevelopment activities on the left-hand (downhill) side and the corresponding sequenceof test execution activities on the right-hand (uphill) side. The model uses boxes todepict development phases. The start of the process in time is on the upper left partof the figure, the end is in the upper right part. The left side of theV-model denotesthe requirements, design and realization phases of multi-disciplinary (e.g. mechanical,electrical, software) components. The right side of theV-model denotes the integrationand test phases from realizations on component level to a complete system.

Rook emphasizes that no strict time flow is intended by the arrows and that, in fact,iterations between the activities are common practice. The approach of Rook is com-monly used in current system development and reveals integration and test problemsduring a late stage of the development process. The costs to repair errors are substan-tially high in the end of the development process, when components have already beenrealized. Moreover, when realizations are integrated, errors in components can have agreat impact on other components. For this reason it is important to detect errors asearly as possible in the system development process.

The complexity of the system is another reason for problems. A complex system is hard


18/121


Define

Define

Define

Design

Design

Design

Integrate

Integrate

Realize

Realize

Rs

R1

Rn

Ds

D1

Dn

Z1

Zn

Zs

I 1...n

Testing System Zs

Testing Component Z1

Figure 2.3: Current System Development Process

to understand completely. Many engineers develop a system together and only know apart of the system well. Integration tests that include the integration of two componentsare often done well, because the involved engineers can have an overview of the system.The complexity of the testing and integration phase remains small. But when the testincludes the integration of subsystems and therefore many different components, thetest engineers might not have detailed knowledge of the components they integrate. Inthis case it is hard to detect and solve integration problems.

Where most of the current research focusses on the phases in the left leg of the V-model, the MBE method focusses on the complete V. As shown in Figure 2.2, the leftleg remains the same as in RooksV-model. The right leg, so the integration and testingphases, are executed according to MBIT. Instead of testing the realization, with MBEthe models of the components are tested first. At the end, if all components are testedcorrectly, the total system can be integrated and tested. The development process MBEconsists of several phases. These phases are described in the following sections.

2.2 Paradigm

Philosopher of science Kuhn [Kuh96] gave the word paradigm its contemporary meaningwhen he adopted it to refer to the set of practices that define a scientific discipline duringa particular period of time. In his book Kuhn defines a scientific paradigm as:

what is to be observed and scrutinized,

the kind of questions that are supposed to be asked and probed for answers inrelation to this subject,

how these questions are to be structured,


19/121

2.3. Analysis 7

how the results of scientific investigations should be interpreted,

how is an experiment to be conducted, and what equipment is available to conductthe experiment?

The paradigm is the set of exemplary experiments that are likely to be copied or emu-lated. The prevailing paradigm often represents a more specific way of viewing reality,or limitations on acceptable programs for future research, than the much more generalscientific method.

In this definition, the paradigm of MBE can be described as follows:

Complex manufacturing systems that exhibit concurrent and consecutive behaviourare observed and scrutinized.

Optimize, analyse, design and implement these systems in a better way.

Quantitative methods and timed/hybrid process algebra and automata (mathe-matics) are used to model these concurrent processes.

The formal quantitative methods provide a better insight and allow the use offormal analysis techniques.

Tooling for simulation, validation, verification and optimization has been exam-

ined or developed.

This definition is explained in more detail by explaining the concurrent behaviour ofmanufacturing systems, the mathematics and the tooling.

2.3 Analysis

The design process starts with the set up of the requirements and the design specifica-tions of the system. First the requirements of the system are captured in a document,

from which a detailed system design is made. Next the system is split up into compo-nents, each with its own requirements and design specifications.

Requirements R

So, first of all the requirements of the system must be set. In MBE different kinds ofsystem requirements can be defined. Requirements for safety reasons or reachabilityfor example. In an overview the requirements can be subdivided into the followingcategories:


20/121


Figure 2.4: A Liveness Example Figure 2.5: A Reachability Example

Safety: Prevent damage to the system itself or the environment of the system.Possibly two moving components of the system could collide with each other.Even external events, such as an operator, could cause danger to the system.

Liveness: Liveness requirements demand that something will eventually happen.For example, the final state can always be reached, no matter what path is taken.An example of liveness is shown in Figure 2.4. The encircled states are the final

states. They all can be reached from the initial state. No matter what path ortransition sequence is taken, one of the final states can be reached.

Reachability: All desired options of the system must be reachable. For example,the final state of the system can be reached in a certain transition sequence. Anexample of a reachability requirement is shown in Figure 2.5. The encircled statesare not reachable from the initial state.

Deadlock avoidance: The system could end in a deadlock state. The systemis locked because it cannot do anything. A state is reached from which no otherstates can be reached. Even livelock is not desired. It is similar to deadlock exceptthat the state of the processes involved in the livelock could change, but with no

processing. If the system is badly designed such states could occur. It is importantto avoid this behaviour. In Figure 2.6 a deadlock situation is given. All stateshave an outgoing transition. The encircled one has none. The system cannot do anew transition if it is in that state. An example of a livelock occurrence is shownin Figure 2.7. If the encircled states are reached a livelock has occurred. In factthere are outgoing transition possible, but there is no progress.

As can be seen in Figure 2.1 requirements are made for both the total system and thecomponents. The left two blocks are the requirements and the design of the system.The division into different components is shown in branches. One branch represents


21/121

2.3. Analysis 9

Figure 2.6: A Deadlock Example Figure 2.7: A Livelock Example

a component Ci of the system. The development process in MBE of a componentCiconsists of a requirements definition phase, a design phase and a realization phase.

Furthermore the Model Based Analysis techniques help in clarifying and improving theoften difficult decomposition of requirements and design of the system (usually clearand certain) into the requirements and designs of all components (usually unclear andbased on assumptions). These improved insights in the system decomposition eventuallyimprove the quality of the system realization.

Design D

From the requirements of the system, the design can be made. Afterwards the modelsmade from the design can be checked whether or not they fulfil the requirements whichare set in the beginning of the process.

Normally the components are systems for the hardware and control systems for the

hardware. Depending on the complexity of the hardware, the hardware and controllerscan consist of one or multiple components. If, for example, parts of the hardware aredeveloped externally, it is desirable to define these parts as separated components, toavoid dependency on the realization of these parts in the testing phase.

The exact function of each component must be well defined. It must be clear what theinput of a component is and from what component this is received. The same holdsfor the output. This is not only the functionality during normal behaviour, but also ifsomething undesired happens. The safety requirements must be fulfilled at all times,regardless of where the errors occur.


22/121


23/121

2.4. ModelingM 11

Hardware components can easily be described intuitively by the condition of a com-

ponent. For example, a pump can be on or off. Because the main interest is thesequence of these states and the events that cause a component to switch from onestate to another, a language is needed which describes the states and the transitionsbetween those states. The automata formalism describes discrete event systems (DES),in a simple but powerful manner. The main advantages of automata are [Cas01]:

Intuitive modeling. The different states from hardware components and controllerscan easily by translated into a DES.

Easy to validate. The sequence of transitions can easily be visualized to check ifthe behaviour of the automata is desired.

Easy to verify. Because automata is a formal defined language, properties can bechecked easily.

Ease of building up larger models from small components. Basic automata oncomponent level, can be combined to describe the behaviour of the system.

This last advantage can also become a disadvantage. The combined automata can causean exponential growth of the total state space of the system. In Section 3.1 the basicsof automata language and DES are explained.

For each component a model is made. This is not yet a realization of the component,

but a simulation model that can be executed. In a later stadium the models are realized.

Validation and Verification

Only two types of system level analysis can be applied. One is that the consistency canbe checked between requirements and designs on components and on system level. Thismeans for the requirements R versus for example R1, R2 and D versus D1, D2 for thedesigns. The second one is that the integrated system realization can be tested againstthe system requirements and design.

Once satisfied that the simulation model is programmed correctly, the model can bevalidated. The question arises: is this a valid model? By definition, a valid model givesa good representation of reality [Kle92]. In other words, we ask: are we building theright model?

The formulation of the question can also be changed slightly into: are we buildingthe model right? This new question demands a more formal answer. The method ofmodeling is formally checked. This is called verification.

These two questions simply explain the difference between validation and verification.Validation can be done instinctively and verification must be done by formal approaches.


24/121


Define

Define

Define

Design

Design

Design

Model

Model

Integrate

Integrate

Realize

Realize

Rs

R1

Rn

Ds

D1

Dn

M1

Z1

Mn

Zn

Verification Model M1

Validation Model M1

I 1...n

Figure 2.9: Validation and Verification of the Components

2.5 Realization Z

Code generation

Realization of the models can be done by replacing the code of the software models withthe firmware and constructing the real hardware itself. Models of the real hardware aretransposed to realtime controllers. Each model of a component has its own counterpart.Model M1 and realization Z1 are comparable in function, but the first is a model andthe second is a realization.

Integration

The method allows to integrate executable models of system components with availablerealizations of other components. The combination of models and realizations is thenused for early analysis of the integrated system by means of validation, verification andtesting. This analysis could early detect and prevent problems that would otherwise

occur in real integration. This late discovery of problems could result in an increaseof the effort invested in the real integration and test phases. The final result of thismethod is to reduce the integration and test effort.

Testing

During model based component testing, a realization of a component is tested againstits model that is generated from the components design, see Figure 2.9. During thesetests, a possible simulation run of the model, is compared to the behaviour of the


25/121

2.5. Realization Z 13

Define

Define

Define

Design

Design

Design

Model

Model

Integrate

Integrate

Realize

Realize

Rs

R1

Rn

Ds

D1

Dn

M1

Z1

Mn

Zn

MS

Verification SystemMS

Validation SystemMS

I 1...n

Figure 2.10: Validation and Verification of the System

realization. When the behaviour of the realization differs from the simulation of themodel, the reason for this difference needs to be investigated and the difference needs tobe solved. The difference indicates that there is an error in the realization or that thedesign was multi-interpretable. It can also indicate that there is an error in the model,but when the models have been subject to Model Based Analysis, this is not plausible.In this phase it is also possible to test deviant behaviour. In case of bad weather

testing, the component can be tested on specific conditions. Because the componentis tested with other simulation models, any dangerous situations can be simulated in asafe environment without causing damage to other hardware.

Define

Define

Define

Design

Design

Design

Model

Model

Integrate

Realize

Realize

Rs

R1

Rn

Ds

D1

Dn

M1

Z1

Mn

Zn

Model BasedComponent Testing

I 1...n

Figure 2.11: Testing the Components

During component testing, the realization of a component is tested against its model,which has been implemented from the components design. For testing the system, arealization replaces its component model in the system model, forming a model based


26/121


Define

Define

Define

Design

Design

Design

Model

Model

Integrate

Integrate

Realize

Realize

Rs

R1

Rn

Ds

D1

Dn

M1

Z1

Mn

Zn

Model Based System Testing

I 1...n

Figure 2.12: Testing the System

integrated system with both models and realizations.

A model based integrated system with both models and realizations is shown in Fig-ure 2.12, where both M and Z are connected to the infrastructure. This system isverified to the system requirements. One of the challenges of system testing is to finda good infrastructure that is able to integrate both models and realizations into onesystem. It depends on the discipline of the realizations and the models, to determinewhat kind of infrastructure is suitable. When the models are part of another discipline

than the realizations, it is difficult to find a good infrastructure. For instance when themodels consist of software and the realizations are hardware, the infrastructure shouldbe able to translate the software commands to hardware signals and backwards.

2.6 Overview MBE

In Table 2.1 an overview is given of the steps that are taken in Model Based Engineering[Tri06]. In the following enumeration the steps are outlined.

1. Define the requirements for the systemRS.

2. From these requirements, make a design for the systemDS.

3. Divide the system into n components. Components can involve different disci-plines (e.g. mechanical, electrical or software) or different aspects within onediscipline (e.g. different levels of control). All components together form thesystem.

4. For each component 1, . . . , n, the requirements Ri need to be defined, so a set ofrequirementsR1, . . . , Rn is needed.


27/121

2.6. Overview MBE 15

# Action Section

1 Define RS 2.32 Make DS 2.33 SplitS into {C1, . . . , C n} 2.34 Define R1, . . . , Rn 2.35 Make D1, . . . , Dn 2.36 Create M1, . . . , M n 2.47 Validate {M1 D1}, . . . ,{Mn Dn} 2.48 Verify {M1 R1}, . . . , {Mn Rn} 2.49 Validate {MSDS} 2.410 Verify {MSRS} 2.411 Create Z1, . . . , Z n 2.5

12 Check {Z1 M1}, . . . , {Zn Mn} 2.513 Check integrations{M1, Zn} 2.5

Table 2.1: Overview Model Based Engineering

5. From the requirements Ri of a component i, create a design Di, resulting in theset D1, . . . , Dn. At the time the requirements of each component and the designcriteria following to these requirements are defined, a model is created. Next, theintegration and testing phase can start.

6. For each componenti, create a model Mi, based on the design Di.7. For each componenti, validate whether the model Mi satisfies the design criteria

Di. In Figure 2.9 this is shown for component 1. M1 D1 answers the questionAre we building the right model. If this is not satisfied, return to step 5.

8. For each component i, verify whether the model Mi fulfils the requirements Ri(Are we building the model right). M1 R1 (Figure 2.9) is verified and whennot satisfied, return to step 4.

9. At the time all the models of the components are validated, the models are con-nected through an infrastructure I1...n to form the system model MS. The vali-

dation of the system model (MS DS) is shown in Figure 2.10. If the systemmodel does not satisfy the design criteria of the system DS, return to step 2.

10. The system model must now be verified (MSRSin Figure 2.10) and when notsatisfied, return to step 1.

11. For each component i, the design Di is realized (Zi), resulting in the set of real-izations {Z1, . . . , Z n}.

12. The testing is commenced, first each component realization is tested against themodel of the same component as is shown in Figure 2.11 for component 1: Z1


28/121


M1. In this way it is checked whether the realization has the same behaviour as

the model and therefore if the realization meets the in step 9 proven design.

13. The integration of each realization with the system model is tested, soM1, . . . , M nintegrated withZ1, . . . , Z n. For example the integrations{M1, Zn},{Mn, Z1}and{Z1, Zn} are tested. From these tests it is checked whether the predeterminedrequirements of the system are met, as can be seen in Figure 2.12. Each realizationcan replace its model, as soon as the realization is available. Therefore tests withthe available realized components can be performed before the other realizationsare available. This decreases the time needed for the testing phases and thereforedecreases the lead time.

2.7 Summary

In this chapter the full path of Model Based Engineering is discussed. In Table 2.1an overview of MBE is given. It makes it possible to predict more accurately theperformance of the system at hand in an early stage. In small steps from the scratchtill throughout the complete development the method can be applied. The benefit ofthis method is that the testing effort and the total costs are reduced. This results in ashorter time to market and an improving system quality. In the next chapter, Chapter 3,the conversion from design into models is outlined. The models are made with the useof automata theory [Cas01] and the Supervisory Control Theory of Wonham [Won06].

The approach is applied on a case study which is discussed in Chapter 4.


29/121

Chapter 3

Supervisory Control Theory

In order to convert the design of the components into models, a modeling language isneeded. To do this, the Supervisory Control Theory (SCT) of Wonham [Won06] is used.SCT is a method for automatically synthesizing supervisors that restrict the behaviourof a plant such that the given specifications are fulfilled. In this chapter the basics ofthe theory are explained. The next sections are used to describe step by step the wayof creating a supervisor.

NB: In this chapter a lot of figures of Discrete Event Systems are given. To keep thefigure surveyable, transitions to the same state (selfloops) are most of the time skipped

in the figure.

3.1 DES Basics

The basic elements of the theory of Wonham are automata [Cas01], [Mid04]. Automataare Discrete Event Systems (DES), discrete in time and in state space. They consistof a set of nodes, representing the states. In theoretical computer science, automatatheory is the study of abstract machines and problems they are able to solve. Automatatheory is closely related to formal language theory, properties of the automata theory

can formally be proven.The set of states is called the state space Q. Between two states a transition can bemade. A transition is drawn as an arrow with a corresponding label and contains anevent that occurs. A set of possible events is called , which can be expressed in aset of transitions . An event can be controlled or uncontrolled, in other words; it canbe from an external input or spontaneously generated. The initial state is called q0,q0 Q. The final states are called marker states, Qm Q. An automaton can haveone or more desired marker states. A quintuple now describes the full automaton G,

G= (Q, , ,q o, Qm) (3.1)

17


30/121

18 Chapter 3. Supervisory Control Theory

With a small example of a machine the theory is clarified.

Example 3.1.1. Consider an example of a single machine. The machine has 3 states,see Figure 3.1. The initial state isI, idle. From the initial state it can make a transition to state W, the working state. The transition means starting a tasks or take aproduct out of the upstream buffer and start producing it. The transition from idle towork is a controllable event. On the other hand the transition from W back to I isuncontrollable as well as the transition to state D. The transitionmeans that the

product is finished and put in the output bin or the downstream buffer. If transition occurs, the machine breaks down, the product in question is not finished. In D thesystem is down or broken and has to be repaired. The transition is again controllableand returns to I. The system is repaired and can start its work cycle again. In thisexample the set of states Q is {I,W,D}, the set of events is {,,,}. The initialstate q0 is the idle state I. Because this system is a cyclic automaton, the idle state isalso the final state or marker state Qm. This automaton can be written as:

M = ( {I,W,D}

, {,,,}

, {(I , , W ), (W,,I), (W,,D), (D ,,I)}, I

, {I}

) (3.2)

The alphabet ofMis the set of all transitions that occur. The partition for the alphabetis:

= cu (3.3)

where the disjoint subset c and u compromise respectively the controllable and un-

controllable events. In a transition graph a controllable event may be indicated by anoptional tick on its transition arrow. For machineM, c = {, } and u = {, }.The mode of operation of a DES, of which machine M is typical, may be pictured asfollows. Starting from state I, machine Mexecutes a sequence of events in accordancewith its transition graph. Each event is instantaneous in time. The events occur atquasi-random time instants. Upon occurrence of an event, the event label is emittedto an external process. In this way machineMgenerates a string of event labels overthe alphabet . At a state such asW from which more than only one transition canoccur, machineMwill be considered to select just one of the possibilities. It is assumedthat the labeling of events is deterministic in the sense that distinct events exiting from


31/121

3.2. Synchronization 19

a given state always carry distinct labels. In general it may happen that two or more

events exiting from distinct states may carry the same label.

I

W D

Figure 3.1: Schematic Representation of Automaton M

3.2 Synchronization

With several small simple automata a larger combined automaton can be constructed

by synchronization. Interaction between the simple automata is represented in a morecomplex automaton. In this section the ways of combining several DES into a single,more complex DES are discussed. The technique is standard for the specification ofcontrol problems involving the coordination or synchronization of several DES together.

Synchronous Products

Two DES can be synchronized together. Automata can be concurrent, which means thatall the transitions with the same event take place at the same time. The synchronousproduct couples two DES together by synchronizing any shared events. In the followingexample it is explained how the synchronization can be done. LetL1

1

, L2 2

,assumed that 12 = . Let = 12. Define

Pi: i (i= 1, 2) (3.4)

according to

Pi() =

Pi() = if = i

if i

Pi(s) = Pi(s)Pi() s ,


32/121


The action ofPi on a strings is just to erase all occurrences of such that = i. Pi

is the natural projection of

onto

i . Let

P1i :P wr(

i ) P wr() (3.5)

be the inverse image function ofPi, namely for H,

P1i (H) :={s |Pi(s) H} (3.6)

For L1 1, L2

2 the synchronous product L1L2 can be defined according

to

L1L2:= P11 L1 P

12 L2 (3.7)

Thus s L1L2 if and only if P1(s) L1 and P2(s) L2. If L1 = Lm(G1) andL2 = Lm(G2), one can think of G1 and G2 as generating L1L2 cooperatively byagreeing to synchronize those events with labels which they posses in common.

1= {, } Lm(G1)

Figure 3.2: DES 1

2= {, } Lm(G2)

Figure 3.3: DES 2

Lm(G1)Lm(G2)

Figure 3.4: The Synchronous Product of DES 1 and DES 2

The synchronization between the two systems G1 and G2 is G where

Lm(G) =Lm(G1)Lm(G2), L(G) =L(G1)L(G2) (3.8)


33/121


34/121


I

W D

i

i

i

i

Figure 3.6: Schematic Representation of Automaton Mi

M2 operates similarly as M1 but it takes a work piece from the buffer and, after com-pletion, deposits it in an infinite output bin. The output bin is not considered anymore.

Uncontrolled behaviour of the line is given by:

F =M1M2

The unordered behaviour of the production line is shown in Figure 3.7. As can be seeneach event or action can happen in every state in random order. There is no regula-tion of a sequence of desired events. To reduce the state space of the factory and toregulate the events, this uncontrolled behaviour can be restricted by the use of speci-

fications. Applying a sequence of tasks will eliminate undesired behaviour of the factory.

2

2

2

2

2 2

1

1 1

1 1

1

2 2

11 1 1

1

1

2

2

22

Figure 3.7: Schematic Representation of Automaton F


35/121

3.3. Specifications 23

3.3 Specifications

In order to restrict the random behaviour of synchronous products as created in Sec-tion 3.2 some specifications have to be made. A specification can be a small automatonto control, for example, two occurring events and determine the sequence.

Example 3.3.1. Consider the two machines of Example 3.2.1. First the buffer betweenthe two machines must not overflow or underflow. Specification B is created to preventthis behaviour, see Figure 3.8.

2

1 selfloop{1, 1, 1, 2, 2, 2}

Figure 3.8: Schematic Representation of Automaton B

MachineM1 completes its work cycle and deposits the work piece in the buffer, action1. Before machine M1 can complete another work cycle, machine M2 has to take thework piece from the buffer, action 2. This specification expresses the requirement that1 and 2 must occur alternately, with 1 occurring first. In other words, Machine

M2 has to take the product out of the buffer and start processing the product beforemachine M1 can produce a new product. The capacity of the buffer is limited to 1.This rule is shown in Figure 3.8.

The Example 3.3.1 has only one specification, the specification to control the buffersize. It is obvious that more specifications can be added to the factory. More complex


36/121


specifications can be built from simpler ones by intersection.

Example 3.3.2. Consider again the two machines of Example 3.2.1. Both machinescan break down. In case that both machines are broken down at the same time, it isassumed that machine M2 has a higher priority and must be repaired before machineM1 is repaired. This rule is specified in Figure 3.9.

1

2

2 selfloop{1, 1, 1, 2, 2}

Figure 3.9: Schematic Representation of Automaton R

As can be seen in Figure 3.9 machine 2 can break down (2). If this happens machine

M2 has to be repaired first (2) before machine M1 can be repaired (1).

In each case, selfloops must be adjoined to account for all events that are irrelevant tothe specification, but which may be executed in the plant. If events are not added tothe specification, they will be blocked in the supervisor.

The unordered behaviour of the line must be controlled. The two specifications can becombined in one Sby:

S=B meet R

The automaton of S is shown in Figure 3.10.

In each case selfloops must be adjoined to account for all events that are irrelevant tothe specification but which may be executed in the DES of the unordered behaviour. Ifnot added, these event are blocked in the controlled DES.


37/121

3.4. Marker State 25

1 1

2 2

1

1

2

1

2

1

selfloop{1, 1, 2}

Figure 3.10: Schematic Representation of Automaton S

3.4 Marker State

Normally, a DES consists of one or more states. A few states of the systems have specialconditions. There exits one state which is the initial state, from where the DES starts.If there is a starting state, there also exist ending states. This can be one or more statesin the system. These states are called marker states. Often in cyclic DES, the initialstate is also the marker state. In non-cyclic DES the marker states can be at the endor even in the middle.

The marker states are essential in the synchronization of the plant. At the time the plantis synchronized, new marker states arise. If the single automata have a marker stateand those two states are synchronized the new state is a marker state. In Figure 3.11an example is given.

In Figure 3.11 an example is given of the creation of marker states. In the left automatonthe initial is not the marker state. The second state is in this case the marker state,indicated by the outgoing arrow. The middle automaton has a marker state in the samestate as the initial state. These two automata are synchronized, the solution is given inthe right automaton. The state lower left is in the synchronized automaton the markerstate, the end state.

3.5 Supervisor

Finally, the goal is to derive a DES A, the supervisor, that would represent productionline F under control. In this section the way of combining the DES of the exampleto create the supervisor is described. The combined specifications are enforced onthe unordered behaviour. This will find the supervisor while otherwise permitting thesynchronous product of the resources maximal freedom of behaviour.


38/121


=

Figure 3.11: Creation of Marker States

3.6 TTCT Information

With the theory of SCT a tool called Timed Toy Control Theory (TTCT) is written

[Won06]. TTCT is a program for the synthesis of supervisory controls for DiscreteEvent Systems. The tool can be used for timed automata. Since the time function onlyadds an extra ticker to the automaton to control the time, it is redundant for most ofthe problems. Generators and recognizers are represented as standard DES in the formof a 5-tuple

[Size, Init,M ark, V oc, T ran],

where Size is the number of states (the standard state set is {0, . . . , S i z e 1}), Initis the initial state (always taken to be 0), Mark lists the marker states, Voc the vocal

states andTranthe transitions. A vocal state is a pair [I, V] representing positive inte-ger output V at state I. A transition is a triple [I , E , J ] representing a transition fromthe exit state I (source) to the entrance state J (target) and having transition labelE. E (previously mentioned ) is an odd or even nonnegative integer, depending onwhether the corresponding event is controllable or uncontrollable. The next subsectionsexplain what controllable and uncontrollable events are.

All DES transition structures must be deterministic: distinct transitions from the sameexit state must carry distinct labels.


39/121

3.6. TTCT Information 27

11

1

1

1

2

1

1

2

2

1

2

2

12

2

2

2

1 2

1

1

1

1

Figure 3.12: Schematic Representation of Supervisor S U P


40/121


Create DES

First of all, the resources of the system must be created. With a notepad editor, theDES can be written. In the tool, the textual description of the DES is converted into a.tds file.

This can also be done by the TTCT tool.

Controllable Events vs Uncontrollable Events

The theory of Wonham uses two kinds of events, controllable and uncontrollable. They

are called respectively actions and events. A controllable event (action) is from an ex-ternal input and an uncontrollable event is spontaneously generated. Events must beentered as integers between 0 and 999, where controllable events are odd and uncon-trollable events are even.

Sync

Assume temporarily that 12 =. With L1 and L2 as before the syncproduct ofL1L2 is defined to be the synchronous product for this case. Thus, the synchronousproduct of the two languagesL1andL2over disjoint alphabets is the language consisting

of all possible interleavings of strings of L1 with strings of L2. One can think of G1and G2 as generating L1L2 by independent and synchronous generation ofL1 and L2respectively.

Meet

The proceduremeetis the special case of synchronization procedure sync correspondingto the assumption of a common alphabet 1 2. Namely all events are consideredshared. In particular, meetwill block any event whose label does not occur in both G1

and G2. Note thatLm(G) may be a proper sublanguage ofL(G), even when G1 andG2 is trim. G is a structure that is capable of tracking strings that can be generatedbyG1 and G2 in common, when each starts at its initial state.

Supcon

To complete the description of the plant, the TTCT procedure condat returns thecontrol pattern at each state of the plant and computes a trim representation of it.Specifically, it returns the minimal set of controllable events that must be disabled.


41/121

3.7. Summary 29

Supervisor Reduction

The supervisor calculated with thesupconcommand is not optimal. A lot of optional le-gal transition are possible. The supervisor can be simplified. With the use of proceduresminstate and supreducethe supervisor can be simplified and reduced.

Condat

With the command condat data can be subtracted from the supervisor. Only control-lable events that are strictly required to be disabled appear in the data. In practice itis rarely necessary to implement an optimal supervisor by explicit representation of thelanguage supC(Lm(G) E).

3.7 Summary

In this chapter the basics of the Discrete Event Systems are explained. The requiredresources are modeled in automata and synchronized into a state space of the totalsystem. To reduce the unordered state space some rules or specifications are designed.With the use of Supervisory Control Theory of Wonham these rules can be applied onthe unordered behaviour and a supervisor can be synthesized. In the next chapter theSCT is applied on a case study, the Paint Factory. In Chapter 5 the results of the

research are outlined. Finally, some conclusions are drawn and recommendations aregiven.


42/121



43/121

Chapter 4

Case Study: Paint Factory

In Chapter 2 the full path of Model Based Engineering (MBE) is discussed, from drawingthe requirements till integrating the components. This method is used to draw theoverview of the modeling procedure. With small examples of pipes and valves themethods and theories are explained. These small examples are a part of a larger system,the Paint Factory. Where most studies of supervisory machine control focus on smallersubsets and examples, this case consists of an existing mock-up with multiple resourceswhich are used for performing multiple tasks. The Paint Factory is modeled as a DiscreteEvent System (DES). Furthermore, the behaviour of the Paint Factory in this case is

considered as deterministic, so the stochastic behaviour is not included.The Supervisory Control Theory (SCT) of Wonham [Won06] is shown in Chapter 3 andused to model the system. With this tool a supervisor of the system is synthesized.Every resource is written in an automaton. These constructed automata together formthe supervisor of the system. In a few steps is explained how an automaton is built andhow the automata of the resources can be combined to construct the supervisor of thesystem. In this chapter the case study is described. In the next chapter the results arediscussed.

4.1 The Paint Factory

A mock-up of a Paint Factory is designed and built in the lab of Systems Engineering[Roo05]. This machine is a mixing device and is able to fill several cups with differentcolors. Three primary vessels are the input of the system. It can be filled with water,lemonade, paint or any other colored liquid. Since it is normally used for colored water,it is called the Paint Factory. For generating more different colors than only the primarycolors, a mixing resource is added. Two or three liquids can be pumped into the samevessel, the mixing vessel. After the mixing phase, the liquid can be pumped to one ofthe storage vessels. Finally, it can be injected into the desired amount of cups in the

31


44/121

32 Chapter 4. Case Study: Paint Factory

filling station. It is not necessary to mix the liquid before injecting it into the cups.

Primary colors also can be filled directly into the cups.In Figure 4.1 the schematic layout of the Paint Factory is given. In the upper left cornerthe three primary vessels (P c1, P c1 and P c3) are drawn. Next to the primary vessels,the cleaning vessel is shown (C). The complete system is connected to the cleaningvessel, so each part of the system can be cleaned. The mixing vessel (M) is connectedto the primary vessels and drawn in the lower left corner. The three buffer vessels (B1,B2 and B3) are at the back at the right side behind the slides with the outlet. Oneof these slides (Bm) can move to a waste location and to the buffer locations to injectliquid into those vessels. The other slide (F m) can move above the filling station andthe waste next to the filling station. The filling station consists of a turntable ( T) with12 cups. The waste produced by the system is drained away to a large waste vessel

(W) below the system. The vessels and wastes are connected with pipes and valves. Apicture of the mock-up is shown in Figure 4.2.


45/121

T

Tm

Bm

Fm

Pc1

Pc2

Pc3

C

M

W

B1

B2

Pp1

Pp2

Pp3

Bv1

Bv2

Fv1

Fv2

Pv1b

Pv2b

Pv3b

Pv4

Cp

Mpi

Mv

Cv2

Bv4

Bp1

Bp2

ST1

SC

Bpi

Fpi

Cv1a

Pv2a

Pv3a

ST2

Ppi1

Ppi2

Bpi1

Pv1a

Cv1b

Cv3

SW

Cpi

Wpi1 Wpi2

Wpi3

Mp

SB1

SB2

Lsb0

SF2

SF1

Lsf0

SBL1

SBL2

SML

Fs0

Fs1

Fs2

SWL

Figure 4.1: The Layout of the Paint Factory


46/121


Figure 4.2: The Realization of the Paint Factory

The Paint Factory should produce paint in different colors and different quantities in

the most efficient way. This mock-up is used as a case study for the research of MBEwith SCT. In the next sections several ways of modeling the Paint Factory with the useof SCT are explained.

4.2 Analysis

In the very beginning the Paint Factory must be analyzed. What kind of system is itand what are the different operating functions? To get an impression of the resources,the multi purpose parts of the system, a model is made. The full model is given inAppendix C. With this first impression of the system, the necessary requirements and

design as described in Chapter 2 can be created. The fact that the resources of thesystem are used in different tasks means that a tasks dispatcher must come forward toregulate the claims on resources by different tasks.

Requirements

In an overview the requirements can be subdivided into the following categories:

Safety requirements


47/121


48/121


Design

Taken the requirement into account, a design of the system can be made. Normally, thecomponents are levels of control systems and one or more systems for the hardware. Inmultidisciplinary systems a component of a specific part of the system can be split intomore components. It depends on the complexity of the system and the need to designit at, for example, different companies. It also avoids dependency on the realization ofthese parts in the test phase.

4.3 Creating Components

The Paint Factory is divided into four components; the hardware, the resource con-trollers, the task dispatcher and the supervisor. In the next sections the design andmodeling of the components is described.

4.4 Modeling

The Paint Factory is described in several ways. Since the most intuitive way, as de-scribed in the next subsection, does not seem to be sufficient, other approaches aretried. These approaches are based on discrete modeling or continuous modeling. The

next subsections are used to give an overview of the used approaches.

Resources in Discrete Modeling

The most intuitive way of modeling is describing all components of the system. Theadvantage of using the automata theory when modeling a large system like the PaintFactory, is that each resource can be modeled one by one and be combined in the end. Inthis way the models are kept simple and easy to construct. Therefore all the controllablehardware components (valves, pumps and motors) are modeled as separate automata.An example of a valve is shown in Figure 4.3. The parts of the system, modeled in

automata, can be synchronized with the TTCT tool, as described in Chapter 3.In order to design a proper automaton for each resource, every condition a resource canbe in is modeled in a state. For example, a valve can be opened or closed. This meansthat the DES consists of two states. The initial state must be chosen. In Figure 4.3 thevalve P v4 above the mixing vessel is drawn. The intuitive way of modeling is used foreach part of the machine. All automata combined represent the uncontrolled behaviourof the Paint Factory. All parts of the machine can be used independently. The numberof states Nin the state space after synchronizing all resources can be calculated as:

N = 2v+p+m,


49/121

4.4. Modeling 37

Closed

Opened

OpenClose

Figure 4.3: Automaton of Valve P v4

where v is the number of valves, p is the number of pumps and m is the number ofmotors in the Paint Factory.

As shown in Example 3.3.1 in Chapter 3 some specifications have to be designed toreduce the state space of the unordered and undesired behaviour of the Paint Factory.These are sequences to open and close valves in order to fulfill the given task. InFigure 4.4 such a specification to fix a sequence is shown. This specification is a sequenceof events in order to pump the liquid from primary vessel 1 (P c1) to the mixer (M).

openP v1b

turn on P p1 open P v4

turn offP p1

close P v4close P v1b

selfloops

Figure 4.4: Automaton of Specification P1M

In Figure 4.4 each action is labeled. For example, openPv4 means opening the valveabove the mixer and turnon Pp1 turning on the pump of primary vessel 1. Since eachpart of the machine can be used by different tasks a specification cannot claim a resource.Claiming means that the resource can only be used by a specific task and no other. In


50/121


case of the Paint Factory, every resource can be used by multiple tasks. To prevent this

claiming, selfloops can be created.Actions used in the specification have to be described in selfloops at the initial state.The result of this is that the action can also be executed by other specifications. Forexample, opening valve P v4 is ordered by the specification shown in Figure 4.4, P1M.If this specification is in the initial state and another specification tries to open thisvalve, it is possible because the specification P1Mhas a selfloop of action P v4 at theinitial state. At this way all events are available for all specifications.

Since all actions are described in selfloops, all actions can still happen in the initialstate of the total state space. This is the ma jor disadvantage of this way of modeling.More specifications have to be designed to prevent this behaviour. An example of an

extra specification is shown in Figure 4.5.

P v1a closeP v1a open

Cv1a open, P v2a open, P v3a open

Figure 4.5: Automaton of Specification 1

The specification shown in Figure 4.5 is used to prevent opening conflicting valves. Atthe time one vessel is pumping to, for example, the filling station, the other vessels arenot allowed to pump to the filling station as well. Preventing opening the connectedvalves is sufficient. Opening the similar valves is excluded with this specification, thiscan only happen in the initial state. If the valve in action is closed again (and theautomaton is in the initial state), the other valves can be opened. This automaton canbe created for similar valves as well.

In small steps the state space is extended to larger sizes. Each time a new valvewith 2 states is added to the factory (unordered behaviour) the state space is doubled.After synchronization the constructed state space has twice the amount of states as theoriginal had. When an automaton with two states is added, the resulting state spaceconsists of roughly two parts. One part in which the added automaton is in the firststate and the second part in which the added automaton is in the second state. Thisprocedure of adding more automata to the existing state space causes an exponentialgrowth of the system. In unfavourable cases the TTCT is not sufficient to calculate


51/121

4.4. Modeling 39

those large spaces. It is not the fact the the virtual memory of the computer is too low,

but the TTCT tool cannot handle very large state spaces (more than 10 million states).So, a more abstract approach with less states is needed.

Resources in Continuous Modeling

An other way of modeling the Paint Factory can be done by describing the pipes of thefactory. Since the previous approach was not sufficient, the model is tackled at a higherlevel of abstraction. The valves connected to a certain pipe are skipped in the model,they are not really necessary to implement in the model. The pipe can only be usedin a specific combination of the positions of the valves. This method means that the

research is at a more abstract level than the method described in the previous section.The resources are not considered at the basic lowest level anymore.

Each pipe between two or more valves is described in a small automaton. An exampleof such a pipe is shown in Figure 4.6.

0

Use

1 Release 2

Clean

3

Stop cleaning

Clean

Figure 4.6: Automaton of Pipe P pi2

In Figure 4.6 the DES ofP pi2is described. P pi2is the pipe between the primary vesselsand the mixing vessel. The state space of the automaton consists of 4 states. The initialstate 0 is idle and clean. If the pipe is going to be used, it enters state 1, in use anddirty. The fluid is now flowing through the pipe. After some while the task is done andthe pipe enters state 2, idle and dirty. The only way to return to the initial state iscleaning the pipe (action Stop cleaning). From the initial state the pipe can also becleaned. After completing this task it enters the initial state again.

Parallel to this research the Paint Factory has also been modeled in another automatatool, UPPAAL [Beh04], [Tri06]. The automata described in this tool are translated to


52/121


the SCT.

Caveats

In order to achieve the final solution a lot of steps and approaches are made. Not inthe first time the optimal path was chosen. Working with the tool and models caveatswere discovered. In this section different kinds of discomforts are described.

Continuous modeling

The main difference between the small example in Chapter 3 and the automata of thePaint Factory is the description of the automata. It can be easily shown in an exampleof the knock-on effect. Take a set of dominoes and put them in a long row. If youpush the first one, it collapses against the second that will fall and so on. The holeline will fall down in a small amount of time. In case of the Wonham example it worksthat way, one action or event follows from the previous one. In case of the continuousdescription of the Paint Factory the dominoes have to collapse at the same instant. Ifa color starts flowing in a trajectory, all pipes in that trajectory must be in the statein use instantaneously and simultaneously. This could work in small examples.

Normal machines in small examples of the Wonham theory have sequential tasks. If aproduct is produced on a machine, it has to go to the following process in line. Thesemachines (or buffers) are not influencing each other. Pipes in the Paint Factory however,do influence each other. They have to operate simultaneously.

Multiple starts, one finish

There are a lot of ways to model the resources of the system. Since the normal way

of modeling is not sufficient, a reduction must be applied. One way is a method witha reduction of the transitions. The finish transitions are combined. In Figure 4.7 anexample of the pump of the cleaning vessel is shown. As can be seen in the figure moretasks can be started. Only one transition returns to the initial state, the finish of thetask. In theory, it only reduces the transitions of the state space and maybe also thesize of the supervisor, because less transitions are modeled. In practice however, theresult is not so promising. Since the label of the action is the same in different tasks, alot of selfloops must be added. So, an attempt to reduce the transitions of the systemturns into an increase of the transitions. A reduction is not achieved, the same problemexists.


53/121

4.4. Modeling 41

1234

Figure 4.7: Multiple Inputs - Single Output

Shortage of Memory

More approaches failed for the same reason. The reason was a shortage of memory inthe tool. The detailed level of modeling causes large amounts of different states. A newor different approach works till a certain level. In the end stadium of the procedures ofsynchronizing resources the shortage will show. The state space becomes too large andthe tool is not able to calculate it. This is the reason that the state space reduction hasto be quite drastic. A lot of details must be skipped, so an abstract representation of

the system remains.

Specifications

According to MBE the component of the resources and the corresponding controllersare designed. After this, in order to apply some sequences and rules to the factory,specifications have to be designed. As described in Chapter 3 the specifications limitthe uncontrolled behaviour of the plant. The controlling state space can be visualizedin a pyramid. It is an hierarchical structure. From bottom till top the pyramid iscomposed of components. The lowest layer is the set of resources. Above the resources

a layer of resource controllers is placed. A schematic representation of the pyramid isshown in Figure 4.8. The two top layers are the actual supervisor of the system. Thefirst layer is the control layer and the second layer is the set of tasks to be fulfilled, seeFigure 4.9.

Since the top of the pyramid is only used to describe the Paint Factory, the specificationsare also simplified. The specifications are applied to the mixing and storage vessels. Thespecification to regulate the behaviour of the mixing vessel is shown in Figure 4.10.

In Figure 4.10 the specification of the mixing vessel is shown. The initial state is state0. Before the mixing vessel can be used, it must be cleaned (action 889). This indicates


54/121


SV

Rules (Tasks)

Resource controllers

Discrete HW

Figure 4.8: The Hierarchical Structureof the State Space

SV

Rules (Tasks)

Resource controllers

Discrete HW

Figure 4.9: The Topped Pyramid

the action to pump from the cleaning vessel to the mixing vessel. It is a solid line whichis meant for controllable events. The event after it is the release event, the subtaskis finished. The dashed line indicates that it is an uncontrollable event (label 891).Pumping cleaning liquid to the mixing vessel means that the vessel is filled and must beemptied. The vessel is drained by actions 885 and 886. If the mixing vessel is initiated(cleaned and drained), the colored liquids can be mixed. At least one color must bepumped to the vessel before the contents of the mixing vessel may be pumped to thestorage vessels. But obviously more than one color can be mixed.

A specification is also made for the storage vessels. The same sequence like the mixingvessel is taken; cleaning before filling.

Supervisors

With the use of the TTCT the supervisor can be synthesized. Applying the specifi-cations to the plant results in the supervisor of the system. In this DES all desiredcombinations are possible. Actually, it is not fixed which combination or recipe mustbe taken first. To regulate this order other specifications are created.

The supervisor consists of desired actions. Actions that must happen in a certain order.For example, if the mixing vessel is used to mix more than one color it is not fixed


55/121


56/121


which color is used. It can still be one of the three primary colors. The difference

between mixing two or three colors is also not fixed. So, to the constructed supervisoran additional specification is added. In Figure 4.11 an example is given of a predefinedorder of a color that can be mixed in the mixing vessel.

P1M

P2M P1M

P2M

P3M

P3M

P3M

M B1

M B2

M B3

B1F

B2F

B3F

Figure 4.11: Specification of Mixing Color 1 and Color 2

Every state in Figure 4.11 has selfloops. Because the figure would become unclear if allselfloops were drawn, they are not drawn in this figure. The left lozenge in the figurerepresents the pump actions of the necessary colors to the mixing vessel. In this casecolor 1 and color 2 are mixed. Either color 1 or color 2 can be pumped first, P1M andP2M or the other way around. If the third color is added (P3M) before the mixingvessel is drained, which is in this case undesired, the specification is returning to theinitial state. The task to mix color 1 and color 2 is not fulfilled. This could happen if

other colors must be mixed in the same order. means one of the tasks M B1, M B2 orM B3. If one of these tasks happens, the mixing vessel is drained and a new color canbe mixed. The specification returns to the initial state. If, in the desired case, the rightcolors are in the mixing vessel, the mixed color can be pumped to one of the buffers.The right lozenge in the figure represents the pump actions from the mixing vessel tothe storage vessels and from the storage vessel to the filling station. One of the 3 buffervessels can be chosen, so 3 paths can be taken. If these pump actions are done, thetask is fulfilled and the specification ends in a marker state. Because the end state ofthis specification has a selfloop of all other events can happen. In other words, ifthere are more colors to produce or to mix it is still possible to do. In Appendix E the


57/121

4.5. Validation 45

complete automaton with added selfloops is given.

4.5 Validation

If the model is created out of the designs, the model must be validated and verified.To validate a model the question must be marked Are we building the right model?.The validation is mostly done by checking the model visually. Try to find out if themodel is behaving as expected. The confidence of the user that the model is a goodrepresentation of the reality is an important fact with model validation. With help ofthe visualization tool described in Appendix A the validation is done. So, with thelack of formal or logical theories, it is sometimes hard to correctly validate a model and

make sure that the validation is reproducible.

4.6 Verification

After the validation, the verification is needed to check the model of the component.Is the model behaving correctly with respect to the requirements set in the beginning.The question is asked Are we building the model right?.

The requirements given in Section 4.2 can be checked at different ways. The verificationof each requirement is outlined in this section.

Reachability

The reachability of a state space or smaller DES can be verified using the trim procedureof TTCT. The trimprocedure ensures that marker states always remain reachable. Itcuts off all redundant states in the state space by eliminating any non-coreachablestates. Comparing the input to the output gives the result of the reachability. If thestate space of the input differs from the state space of the output, some states were cutoff. The fact that states could be cut off, proves that there are non-reachable statesin the system. Normally, if the state spaces are constructed correctly, there are nonon-reachable states.

Deadlock

The deadlock avoidance is verified by the Diagraphica tool, see Appendix A. For theinput of this visualization tool a detailed description of the state space is needed. Everynode in the system is evaluated. The condition of each resource is stored and the numberof incoming and outgoing transition is also stored. If a node has no outgoing transition,a deadlock is present. The deadlock of the final states is desired. So, they are not takeninto account.


58/121


Lifelock

To verify the state space for the occurrence of lifelock the same verification is used asthe reachability check. The procedure trimof TTCT is used to eliminate redundantstates. States with lifelock are also redundant states and are removed by this procedure.Checking the sizes of the state spaces shows the presence of lifelock.

4.7 Optimization

Synthesizing the supervisor results in a state space where all desired options are avail-able. The size of such a state space is more or less 20.000 states. The undesired

behaviour is eliminated. This does not mean that only the shortest and optimal pathis left over. All useful and possible paths are available in the state space. In order toreach the marker states with the least steps another specification is added. An exampleof such a specification is shown in Figure 4.12.

. . .

01 2 n 1 n

Master Thesis Se420492 - j.hamer

Documents

Transcript of Master Thesis Se420492 - j.hamer