Master’s Thesis · Master’s Thesis Master: Mechanical Engineering Department: Mechanical...

Component-wise Supervisory Controller Synthesis usingexisting plant models in a client/server structure

Master’s Thesis

Master: Mechanical Engineering

Department: Mechanical Engineering

Research Group: Control Systems Technology

In association with: ASML

Student: R. Loose

Identity number: 0771575

TU/e supervisors: dr.ir. M.A. Reniers

ir. L.J. van der Sanden

External supervisor: dr.ir. R.R.H. Schiffelers

Date: 9 October 2017

Abstract

ASML is a worldwide leader in the field of high-end lithography systems for the semi-conductorindustry. With great complexity and ever-increasing demands on performance and time-to-market,it is essential to keep improving the control software and the development thereof. LOPW (LotOperations, Process Wafer) is the part of ASML’s control software that is in charge of the logist-ical process within a wafer scanner. It makes sure that wafers are inputted, processed lot-wiseand outputted while scheduling and requesting conditioning and maintenance actions, all in anoptimal way. LOPW can be thought of as a supervisory controller; it only tells other componentswithin a wafer scanner what to do and when to do it, not how to do it.

In order to increase comprehensibility and to reduce scalability issues, LOPW is divided intomany controllers that together form a hierarchical structure. Currently, these controllers aremanually designed using Analytical Software Design (ASD). To this end, high-level, informal re-quirements the system has to satisfy, are implemented in an ASD model as a number of low-levelbehavioural decisions. Another way to obtain these controllers is by using Supervisory ControlTheory. This framework can be used to synthesise correct-by-construction controllers from thespecified requirements and the plants that describe the behaviour of the uncontrolled components.By not having to manually design the controllers, the chance at implementing incorrect behaviourwith respect to the requirements is diminished and the time and effort it takes to understand andapply changes to LOPW could be significantly reduced. The goal of this research is to investigateto what extent supervisory controller synthesis can be applied to the components of LOPW.

CIF is an automaton-based modelling language and accompanying toolset that supports syn-thesising controllers for discrete-event systems. To be able to apply SCT to the existing compon-ents of LOPW, part of the logic of the existing ASD models needs to be manually transformedinto CIF plant models. Additionally, requirements need to be formally specified in terms of in-variants or automata. These requirements are partly given in the LOPW design documentation,and others will have to be extracted from the existing controllers. As requirements are formallymodelled as such, there will be a close relation between the informal requirements and their formalimplementation in CIF. Traceability of the informal requirements is thereby increased.

The goal of applying synthesis is to generate supervisors that satisfy the requirements theASML software engineers want them to satisfy. This means that achieving equivalence betweenthe existing controllers and the synthesised ones is not necessarily a prerequisite. A large numberof requirements is listed in the design documentation. However, when only implementing those andapplying synthesis, it seems more requirements are needed to be able to obtain a supervisor thatdoes what is desired. This means that the design documentation on LOPW could be expanded byadding requirements. As there are other causes for differences, it will take domain knowledge toassess whether or not a part of the behaviour of an existing controller is a requirement that canbe added to the documentation.

Possible problems regarding scalability when applying synthesis are greatly alleviated by theexisting division of LOPW into many, smaller components. However, some issues might still occurand these will be examined. In order to validate the manual transformation into plant automataand the implementation of requirements, a comparison is made between the existing controllersand the synthesised supervisors. After some pre-processing steps, branching bisimulation can beachieved between the two. Assuming the existing controllers satisfy the informal requirementslisted in the LOPW design documentation, this proves that SCT can be used to synthesise su-pervisors for LOPW that satisfy the given requirements. Knowing this facilitates the choice for

3

4

ASML as to whether or not they want to turn to SCT for obtaining the components of LOPW.

Samenvatting (Dutch)

ASML is een wereldwijde leider als het gaat om lithografiesystemen voor de halfgeleiderin-dustrie. Vanwege toenemende complexiteit, prestatie-eisen en tijdsdruk is het essentieel om decontrol software en de ontwikkeling daarvan te blijven verbeteren. LOPW (Lot Operations, Pro-cess Wafer) is het deel van ASML’s control software dat het logistieke proces binnen een waferscanner regelt. Het zorgt ervoor dat wafers de machine in- en uit gaan, per lot worden verwerkten dat conditionerings- en onderhoudsacties worden gepland en aangeroepen. LOPW kan wordengezien als een supervisor; het vertelt andere componenten alleen wat ze moeten doen en wanneer,niet hoe ze het moeten doen.

Om het begrijpelijker te maken en om schaalbaarheidsproblemen te voorkomen, bestaat LOPWuit een groot aantal controllers die samen een hierarchische structuur vormen. Deze controllersworden momenteel handmatig ontworpen met behulp van Analytical Software Design (ASD).Abstracte, informele requirements waaraan het systeem moet voldoen, worden handmatig ge-ımplementeerd in ASD als meerdere beslissingen op een lager niveau. Een alternatieve manierom aan deze controllers te komen is door Supervisory Control Theory (SCT) te gebruiken. SCTkan worden gebruikt om controllers te synthetiseren/genereren uit de gespecificeerde requirementsen de plants die beschrijven hoe het ongecontroleerde systeem zich gedraagt. Doordat ze nu nietlanger handmatig hoeven te worden ontworpen, wordt de kans op het implementeren van incorrectgedrag ten opzichte van de requirements verkleind en de tijd en moeite die het kost om verande-ringen toe te passen op LOPW kan worden verminderd. Het doel van dit onderzoek is om uit tezoeken in hoeverre supervisory controller synthese toegepast kan worden op de componenten vanLOPW.

CIF is een modelleertaal en toolset gebaseerd op automaten die het synthetiseren van control-lers voor discrete-tijd systemen ondersteunt. Om SCT toe te passen op de logica van de bestaandecontrollers van LOPW, moet een deel van de ASD modellen worden handmatig gevangen in CIFplant modellen. Ook moeten de requirements formeel gespecificeerd worden in de vorm van inva-rianten of automaten. Een deel van deze requirements is gegeven in de documentatie van LOPWen een deel van de requirements zal uit de bestaande modellen moeten worden gehaald. Doordatrequirements als zodanig formeel worden gemodelleerd, is er veel samenhang tussen de informelerequirements en hun formele implementatie in CIF. Daarmee zijn de informele requirements beterte traceren in de implementatie dan voorheen.

Het hoofddoel bij het toepassen van synthese is om supervisors te genereren die aan de juisterequirements voldoen. Dit betekent dat het behalen van equivalentie tussen het gedrag van debestaande controllers en de gesynthetiseerde supervisors niet per se een vereiste is. Veel require-ments staan in de documentatie van LOPW. Echter, als alleen die worden geımplementeerd waarnasynthese wordt toegepast, blijkt dat er meer requirements nodig zijn om het gewenste gedrag tebehalen. Dit betekent dat de documentatie over LOPW kan worden uitgebreid door requirementstoe te voegen. Omdat er meerdere oorzaken zijn voor de verschillen tussen de controllers is erdomeinkennis nodig om te beoordelen of een deel van het gedrag van een bestaande controller eenrequirement is die toegevoegd kan worden aan de documentatie, of niet.

Mogelijke problemen met schaalbaarheid tijdens het toepassen van synthese worden sterk ver-licht door de bestaande verdeling van LOPW in kleinere componenten. Toch kunnen er nogproblemen optreden en die zullen worden onderzocht. Om de transformatie naar plant automatenen de implementatie van requirements te valideren, is een vergelijking gemaakt tussen de bestaandemodellen en de gesynthetiseerde supervisors. Na enkele voorbereidingsstappen kan branching bi-

5

6

simulatie worden behaald tussen de twee. Als wordt aangenomen dat de bestaande controllersvoldoen aan de informele requirements uit de LOPW design documentatie, bewijst dit dat SCTkan worden gebruikt om supervisors te synthetiseren die aan de gegeven requirements voldoen.Met deze kennis kan ASML gemakkelijker de keuze maken of ze wel of niet over willen stappen opSCT voor het verkrijgen van de componenten van LOPW.

Preface

This thesis marks the end of a great nine-month experience at ASML. During my master I’vefaced many challenges and met many interesting people. I would like to thank some of thesepeople for making it all possible.

First of all, I would like to thank my TU/e supervisors Michel Reniers and Bram van derSanden. After many weekly meetings I have learned to take a step back and judge my work froma different perspective. Michel, thank you for creating this opportunity for me, for making mefocus on the goal of my research, for being critical of my work, and for always helping me outquickly. Bram, thank you for your invaluable feedback and for your continued enthusiasm andinterest in the project, which has deeply motivated and inspired me.

Thank you Ramon Schiffelers, for having me at ASML and for pointing me in the right direc-tion with respect to my project. Furthermore, I would like to thank Dennis Hendriks, Ruben Jonk,Rolf Theunissen and Sven Weber for your help during this project. Your expertise on everythingrelated to ASD, CIF, Eclipse, LOPW and mCRL2 has been a great help for me.

Angelique, thank you for always having faith in me and for making me a better person. Icouldn’t have done it without you. Papa and mama, thanks for enabling me to get an academiceducation and for always being supportive of me and my plans in life.

7

Contents

1 Introduction 11.1 Problem setting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Research objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.4 Structure of this thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.5 Related work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.6 Key aspects of this research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Analytical Software Design 72.1 Analytical Software Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2 Models of an ASD component . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.3 Action types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.4 ASD semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.5 Verification of ASD models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.6 Single-threaded and multi-threaded execution models . . . . . . . . . . . . . . . . . 14

3 LOPW 153.1 The logistical process of a wafer scanner . . . . . . . . . . . . . . . . . . . . . . . . 153.2 Models of LOPW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4 Supervisory Control Theory 174.1 Supervisory Control Theory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174.2 Compositional Interchange Format . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.3 Supervisory Control Theory in CIF . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

5 Supervisory Control Theory for LOPW 235.1 SCT and ASD components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235.2 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245.3 Application of synthesis on ASD components . . . . . . . . . . . . . . . . . . . . . 29

6 Example component: WH Clean 35

7 Formal validation of the application of synthesis 397.1 Model verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397.2 mCRL2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407.3 Pre-processing of the models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407.4 Behavioural equivalence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467.5 Proving equivalence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

8 Scalability of supervisory controller synthesis 498.1 Scalability of component-wise synthesis on LOPW . . . . . . . . . . . . . . . . . . 498.2 Remedies for scalability issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

9 Conclusions and recommendations 559.1 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 559.2 Recommendations for future research . . . . . . . . . . . . . . . . . . . . . . . . . . 56

10 Reference list 57

9

10 Contents

A Pre-processing steps mCRL2 models 59

B Python scripts 65

C CIF specification 67

1. Introduction

In this chapter, the problem setting is introduced, after which the research objectives are posed.Then the approach for this research is explained, followed by the structure of this thesis. Finally,work related to this research is discussed and compared to the novelties this research introduces.

1.1 Problem setting

ASML is a worldwide leader in the field of high-end lithography systems for the semi-conductorindustry. They design, develop and produce their machines with great care and precision. Withgreat complexity and increasing demands on performance and time-to-market, the developmentof software has become a big challenge in the semi-conductor industry. In this project, the part ofASML’s software stack that describes and controls the logistical process of wafer scanners is ex-amined. This part of the software is called LOPW: Lot Operations, Process Wafer. It is designedusing ASD (Analytical Software Design [4]), a modelling technology by Verum. This technologyallows for formal modelling and model verification, as well as the division of a large system intosmaller components. By constructing LOPW using ASD, the industrial-sized model can be mod-elled in terms of a number of manageable components that can interact with one another in ahierarchical manner.

All 279 ASD components of LOPW are currently manually designed. However, under ever-increasing complexity, understanding and updating the models can be quite time-consuming. Bydesigning the controllers this way, changes in the system requirements or the system design cancause the software engineers to have to remodel part of LOPW, while it might not be that clearwhat needs to change and how. Furthermore, manually adjusting the models could result in re-dundant complexity, making it harder for software engineers to understand and to adapt. Finally,because informal requirements must be manually transformed into a number of low-level decisionsin ASD, the implementation can be considered somewhat disconnected from the requirements theengineers at ASML want the system to meet as specified in documentation on LOPW.

It could be interesting to examine the possibilities of using Supervisory Control Theory (SCT)to try and solve the problems mentioned above. SCT can help synthesise a model of a controller(or supervisor) based on models of the possible behaviour (plants) and the desired behaviour (re-quirements). A synthesis algorithm is applied to the components of LOPW to obtain a controllerfor each of the individual components. The main reason for using synthesis is that the controllersno longer have to be designed manually. An advantage of using this method is that, becausethe controllers are correct-by-construction, the requirements that describe the behaviour it shouldsatisfy, are automatically met. Furthermore, the resulting controllers are non-blocking. Whenthe controllers are generated instead of manually designed, updates with respect to the design ofthe system or its functions can potentially be carried out with less difficulty. Due to the formalspecification of requirements that is needed to apply synthesis, the models will be more closelyrelated to the informal requirements, which could make it easier for people at ASML to understandthe models of LOPW and to adjust them. Lastly, new components can be designed more easily,because they can be generated using the plant behaviour and requirements modelled in a reusableway.

In this thesis, the applicability of Supervisory Control Theory to the components of ASML’sLOPW, is examined. This research could ensure that a viable decision can be made as to whetheror not Supervisory Control Theory shows enough potential for ASML to invest in applying it. In

1

2 Introduction

order to facilitate this choice, it would be welcome to answer several research questions:

1. How can Supervisory Control Theory be used to obtain controllers for LOPW and how dothese relate to the existing controllers?

2. To what extent can Supervisory Control Theory be applied to all components of LOPW?

These research questions can be answered by completing the research objectives in the followingsection.

1.2 Research objectives

To be able to answer the first research question, a correct manual transformation must be cre-ated from the logic in ASD models to a modelling language that supports controller synthesisfor discrete-event systems. Additionally, requirements must be extracted from the LOPW designspecification document and the current component models. It is desired to identify patterns inthe models in order to specify requirements in a reusable way. This will facilitate the specificationof requirements for each individual component. A supervisor obtained by using synthesis mustsatisfy the informal requirements given in the LOPW design documentation. In order to provethat it does, it can be compared to the behaviour of its ALIAS counterpart. This constitutes thefirst research objective:

1. To obtain a correct specification of plant models and formal requirements in a languagesupporting controller synthesis for discrete-event systems. Additionally, applying synthesis to thisspecification results in a supervisor that displays behaviour that is close to (or equal to) the be-haviour of the ALIAS component. The supervisor must at least satisfy the informal requirementsgiven in the LOPW design documentation.

Since LOPW comprises of several hundred components, it must be examined to what extentsupervisory control theory can be applied throughout LOPW. As explained above, it is desiredto identify patterns in the models. By doing so and implementing certain aspects of models andrequirements in a reusable way, applying synthesis to numerous components may take less time.Furthermore, certain components might lead to difficulties in the implementation, because they areeither complex compared to other components, or they have features in them that are difficult tomanually transform into an event-based representation. Finally, difficulties might be encounteredwhen trying to synthesise a supervisor for large components. This leads to the second objective:

2. To assess the applicability of SCT throughout LOPW. This includes investigating reusabil-ity of specifications and looking into possible scalability issues.

After completing these research objectives, the main objective of this research can be com-pleted: assessing the viability of applying supervisory controller synthesis to LOPW. In the nextsection, it is explained how these research objectives can be achieved.

1.3 Approach

Before being able to extract and capture the requirements implemented in LOPW, one needs tobe familiar with ASD and how ASML uses this modelling technology for LOPW. Therefore, thesemantics of ASD and LOPW features are investigated. After that, the ASD plant models needto be translated to a modelling language supporting controller synthesis. The language of choiceis CIF [10], a modelling language and accompanying toolset developed at the Mechanical Engin-eering department of the Eindhoven University of Technology. CIF is a suitable choice, becauseit supports synthesis and because it allows plants and requirements to be modelled in a reusable

1.4. Structure of this thesis 3

way. This means that a definition for a plant can be specified and that an instance of that plantcan be created easily.

After obtaining a supervisor, it must be checked whether or not it satisfies the informal re-quirements presented in the documentation for LOPW. In order to do this, it will be comparedto the existing ASD model of the controller. Assuming the existing ASD model for the controllermeets the requirements, proving equivalence will also prove that those requirements are met by thesynthesised supervisor. Before being able to compare the models, some transformations and otheractions are required. More on validation of the synthesis procedure can be found in Chapter 7.By performing this comparison, it can be shown that using supervisory controller synthesis, equalcontrollers can be generated and more importantly, that the synthesised supervisor can satisfy theinformal requirements.

Once it is shown that supervisory controller synthesis can be used to obtain controllers thatsatisfy the given requirements, the possibilities of applying SCT across LOPW are explored. Thisis done by examining what features of ASD components can be considered difficult to extractrequirements from. By doing so, it can be assessed whether or not there are a lot of componentswithin LOPW that require more attention in order to apply synthesis to them. Apart from that,the requirements of a number of components are examined, both those listed in the LOPW designdocumentation and those extracted from the existing models. Patterns in these models and theirrequirements are identified so that these can be implemented in a reusable way. By doing this, theimplementation of the ASD models and requirements takes less effort, hopefully making it easierto apply synthesis to more components of LOPW.

Scalability is usually an issue for supervisory controller synthesis. For small use cases, super-visors can be generated almost instantaneously, but when looking at an industrial system, thenumber of states explodes and the time and memory it takes to synthesise a controller increasesdramatically. Fortunately, the components of this industrial sized system have a limited numberof states and therefore, scalability will not be as much of an issue during this project. However, itwill be investigated whether or not scalability forms a problem. Should any issues occur, researchwill be conducted on how memory usage and synthesis time can be influenced.

In the next section, the outline of this thesis is explained.

1.4 Structure of this thesis

The modelling technology used by ASML to model LOPW (Analytical Software Design), is ex-plained in Chapter 2. After that, the logistical process LOPW is in charge of, is explained inChapter 3, along with a discussion on the architecture of LOPW. In Chapter 4, SupervisoryControl Theory is explained and a modelling language supporting synthesis is introduced. Afterintroducing supervisory controller synthesis, Chapter 5 aims to explain how it can be useful forthe components of LOPW. The methods that are explained, are taken to practice in an examplecomponent in Chapter 6. The supervisory controllers obtained through synthesis are formallyvalidated in Chapter 7. After validating the synthesised supervisors, scalability of the methodsused in this research is examined. Finally, conclusions are drawn and recommendations for futureresearch are given.

In the next section, research related to this project is discussed.

4 Introduction

1.5 Related work

In [23], Starke has proposed a framework for modelling industrial-sized systems as extended finiteautomata (EFA). This is done by modelling plants and categorised requirements and applyingsynthesis to those. ASML’s LOPW was used as a test case to verify the framework. Supremicawas used to apply synthesis, which was not very successful in the end. The work provides a cleardescription of how requirements could be modelled as EFAs, or formally expressed. However,neither the ASD models of LOPW, nor CIF are mentioned in the research.

Michels [16] has researched the application of synthesis to the uncontrolled system and therequirements of LOPW. Multiple existing methods have been examined and synthesis was appliedusing the method deemed most suitable. Verification was done using Uppaal and mCRL2. Inthis thesis, the translation from ASD models to EFAs is discussed extensively. However, Michelsstumbled upon blocking situations that could not be solved at the time, and the case study dis-cussed in the report is about a relatively small logistics controller (29 components) compared tothe one examined in this report (279).

Both Michels and Starke refer to Zeelen [30], who explored the possibilities of applying synthesisto ASML software. Zeelen has demonstrated the applicability of Supervisory Control Theory forrelatively small controllers (a small part of LOPW).

Sahagun [21] has complemented the translation methodology proposed by Michels. The ex-isting methods are clearly explained and extended. CIF is mentioned as a modelling languageso that a comparison between traces of ASD models and EFSMs can take place. However, thetranslation does not touch upon any CIF specification.

As discussed above, some research has been conducted on the formal documentation of require-ments and the application of synthesis to the logistical controllers of ASML wafer scanners. Thetranslation from ASD to EFAs has been examined by multiple students individually, increasingthe reliability of their findings. However, none of the works mentioned above discussed any specificexample component or CIF specification.

Jonk [13] has looked into transforming ALIAS models into mCRL2 models. ALIAS is a model-ling framework created at ASML that is very similar to ASD. mCRL2 [6] is a formal specificationlanguage and model checker that can be used, among others, to create and analyse labelled trans-ition systems, developed at the Eindhoven University of Technology. Jonk has transformed 126ALIAS components into mCRL2 models and checked the validity of this transformation. If thetranslation is assumed to be correct and we assume that the ALIAS models behave the same waythe ASD models do, the mCRL2 models can be used to validate the manual translation fromASD to CIF and the synthesis step. CIF has a built-in translation to mCRL2, which means thatthe models could be compared to one another after some model adjustments. Furthermore, theextensive discussion of ALIAS semantics combined with the fact that ALIAS semantics are verysimilar to the semantics of ASD, means that this work could help to gain insight in the semanticsto be captured.

Finally, Janssen [11],[12], has conducted research on component-wise synthesis of supervis-ory controllers. ASD models are manually transformed into plant models and requirements thecomponent should satisfy, are added. Then, a supervisor is synthesised that is non-blocking andthat automatically meets the requirements that are specified. The supervisor that is generated,is translated back to ASD in order to obtain the design model for the component. The approachto component-wise synthesis used in Janssen’s work is quite similar to the approach used in thisresearch, but the components examined are very simple and synthesis is only used for verificationpurposes. Nevertheless, Janssen’s research can be valuable for this research.

1.6. Key aspects of this research 5

In the next section, the things that make this research innovative and unique, are presented.

1.6 Key aspects of this research

As quite some research has been conducted on this subject in the past, it is important to stresswhy this research is innovative and different from other research. First of all, the use case isunique. The component-wise synthesis on LOPW has not been done before. Secondly, relevantaspects to capture LOPW and ASD induced behaviour in CIF plant automata are explained. Incontrast with other research, ASD models and CIF specifications are discussed on a more detailedlevel, as is the semantic mapping.

Additionally, the component-wise manual transformation from ASD to CIF, the specificationof requirements and the synthesis step are formally validated in this research. By having formalvalidation and not just a trace comparison or manual simulation verification, the methods usedduring this project can be considered correct with greater certainty.

Finally, where other research does not address the problem of scalability, it is examined in thisthesis. Although many of the scalability issues are alleviated because of the division into smallercomponents, some still remain and have to be investigated and hopefully solved.

In the next chapter, the modelling technology currently used by ASML to model LOPW, isdiscussed.

2. Analytical Software Design

In this chapter, ASD, the modelling technology used by ASML to model LOPW, is explained.In Section 2.1, ASD is introduced. In Section 2.2, the different parts of an ASD component areexplained and more detailed information is given on the capabilities of these components. Thedifferent action types ASD models can have are explained in Section 2.3 and the semantics of anASD model are discussed in Section 2.4. Finally, the properties a verified ASD model has are listedin Section 2.5 and a distinction between single-threaded and multi-threaded execution models ismade in Section 2.6.

2.1 Analytical Software Design

ASD (Analytical Software Design) is a component-based modelling technology by Verum [4] thatis used as a control specification language. This means that it is used to create technology in-dependent control models. The models determine what the components are supposed to do andwhen (they can command the components), and not how it must be done (the components them-selves are in charge of executing the commands). This allows the behaviour of the models to bespecified independent of any specific implementation. The models that are created using ASD canbe implemented by generating code in the desired implementation language such as Java or C++.This way, the semantics of the models are maintained and a correct and flexible implementationis enabled.

A hierarchical structure can be created in ASD, where one component (the client) can use theservices of other components (the used components). This is schematically depicted in Figure 2.1,where the Client requires services that Used component 1 and Used component 2 can provide.A client can be a used component to other components, and a used component can be a clientto other components, which results in multiple layers. Moreover, any component can provide itsservice to multiple different clients. This way, a large and complex system can be divided into anumber of smaller components, which greatly reduces the complexity of each component.

Client

Used component 1 Used component 2

Do A

Do BOK

NOK

Figure 2.1: Schematic view of a hierarchical structure between components

ASD models are created in an environment called ASD:Suite, which is also used for verificationof the models. In the verification step, all possible event interactions are mathematically checkedfor any possible errors or deadlocks, which are indicated in a message sequence chart where pos-sible solutions to the problem are given. An example of such a message sequence chart is given inFigure 7.5, where X, Y and Z are component names and every arrow represents an event between

7

8 Analytical Software Design

those components. These verification tools make debugging less of a tedious task, possibly result-ing in a shorter time-to-market. In case some components are too complex to model in ASD, orif third party legacy code is involved, foreign components can be connected to the existing ASDmodels as well. These foreign components regulate the interaction between ASD components andthe outside world and make sure only behaviour that complies with ASD is enabled [29].

X Y Z

Event B

Call C

VoidReply

True

Call A

Yes

Figure 2.2: Example of a message sequence chart

2.2 Models of an ASD component

Every ASD component consists of an interface model (IM) and a design model (DM). The in-terface model specifies the externally visible behaviour of the component to its client. It will bespecified in the IM which responses can occur after a certain call to the component. A designmodel specifies the inner workings of a component, the actual behaviour. In the DM, it is stillspecified which responses can follow a certain call, but in addition to that, it is modelled whichresponse should occur and when. The difference between the two can be seen by looking at Fig-ures 2.3 and 2.4. In the IM of Figure 2.3, a Call A results in either NOK or OK. The DM ofFigure 2.4 specifies that Call A still results in NOK or OK. Additionally, the choices made andthe actions taken to get to a specific response, are modelled. Note that Call B and Call C arerequests to used components of the component and that Yes, No, True and False are responsesfrom those used components. The implementation of the behaviour of Figure 2.4 is just one ofmany possible implementations that comply with the same interface model. This means that evenwithin the same system, multiple unique design models can comply with the same interface model.

Call A

NOK

OK

Figure 2.3: Example of the behaviour specified in an interface model

The interface model of a component can be thought of as an abstraction of the behaviourof all underlying components. Many events can result from a single call, but ultimately, one of

2.2. Models of an ASD component 9

Call A Call B

No

Yes

NOK

Call C

False

True OK

Figure 2.4: Example of the implemented behaviour as specified in a design model

the responses specified in the IM, is returned. Every design model in ASD must comply withits interface model [29]. This means that the behaviour specified in the DM can only result ina response that satisfies the behaviour specified in the IM. On the other hand, the design modelcan be thought of as a refinement of the interface model. It follows the behaviour of the interfacemodel, but in addition to that, interaction with used components is specified. Finally, it must benoted that interface models are not used during run time. They are present for verification of theinteraction between components and do not actually receive or process events when a system isprocessing.

Design models and interface models are defined in ASD by Sequence-Based Specifications(SBSs). An SBS consists of a number of rule cases, each of which represents the specification ofa transition in the component. In such a rule case, multiple things must be defined:

• The interface indicates the interface that the incoming event comes from.

• A Trigger or Event is needed that tells the component that an action should occur. Atrigger is the result of an incoming Call, Valued Reply or Notification event; this means thatmultiple triggers can occur at the same time, but only one is executed at a time. Call eventsare events from an interface of a higher level (a client) that invoke an action of the componentitself. Notification events come from a used interface at a lower level (a used component).A final type of event is the modelling event. These are events internal to interface modelsand cannot be defined in design models. More information on modelling events is given inSection 2.2.2).

• A Guard (optional) corresponds to a Boolean that can either allow the actions correspondingto the rule case or prevent them from happening. Constraints can be imposed on a componentthrough these guards, because for example, one can specify that a certain event should onlyyield a response if a variable is equal to 0. The guard must hold true in order for the actionsspecified in the rule case to be performed.

• Action defines what happens after the trigger and, if applicable, the guard yields true.Actions can be notifications or replies to higher level components, or calls to lower levelcomponents and every action can be void or valued. If the action is void, a void reply isexpected that simply indicates that the action was performed. A valued action will resultin one of the specified valued replies, which are replies that imply a message (like Yes orTrue). One rule case (one trigger) can cause multiple actions to occur in sequence. Moreinformation on actions is given in Section 2.3.

• In case there is a state variable, a state variable update (optional) can be defined in therule case that assigns a new value to the state variable. State variables are variables thatare used in a component, either of a built-in type like integer or Boolean or a user-definedtype.

• A Target state defines the state the component is going to be in after the actions andupdates are completed. This can be the state the component was already in, indicating aself-loop.


An example of a rule case is given in Figure 2.5. On the interface ITimerCB of componentTimer, an event Timeout comes in that when x < 2, triggers TurnOn in component Siren andupdates the state variable x. After that, the ASD model switches to state Activated AlarmMode.

Figure 2.5: Example of a rule case in ASD

The final column of a rule case suggests that there can be multiple states. In different states,behaviour corresponding to the same event can be very different. More information on states isgiven in Section 2.2.1.

Most events in ASD occur synchronously, they are triggered in the client and used componentat the same time. Notification events are exceptions as they can be processed asynchronously [29].A notification is an event brought up by a used component which is sent to the client. The eventis stored in a queue where it waits to be processed by the client. New notifications can only beadded to the queue by the same used component, after which the notifications will be processedin FIFO ordering. Other used components cannot send a notification to a client until its queueis empty again. Once the client enters a normal state (see Section 2.2.1), the notification event istriggered and with that, removed from the queue. Triggering a notification can result in sendinga notification to the client, sending a call to a used component, or doing nothing. Note that whenentering a normal state, notifications will be triggered before any call from a client is processed.

2.2.1 Design models

As explained earlier, the design models in ASD specify the inner workings of a component. Inaddition to state variables (discussed in Section 2.2), design models can have data variables aswell. In the case of LOPW, data variables are used to store data on machines, wafers and lots inthe form of tuples. It must be noted that data variables do not actually affect the behaviour ofASD models. An ASD model cannot read a data variable and can only send the data to othercomponents, ultimately sending it to a component outside of LOPW, where it is processed. Datavariables are exclusively used in design models and cannot be modelled in an interface model.Since they do not directly influence the behaviour of an ASD system, data variables will not betaken into consideration during this project.

More complex design models can be divided into a main machine and one or more sub ma-chines, the behaviour of each of those is specified by an SBS. Every sub machine of a design modelcan communicate with the main machine through their individual transfer interface, which arenot visible to the user. All sub machines are inactive until the main machine calls one of the submachines. Then, all other sub machines as well as the main machine become inactive until theactivated sub machine replies to the call from the main machine. In ASD, this level of abstractionis limited to one, meaning that sub machines cannot have their own sub machines and thus cannotenter a super state.

There are five different types of states a design model can be in:

• The main machine of a model starts off in the Initial state. The initial state is a Normalstate and can be chosen at will out of the normal states (see the final bullet point).

• Super states are states in the main machine in which a sub machine is active. While inthis state, all triggers must be blocked except for the transfer reply events corresponding tothe active sub machine.

2.2. Models of an ASD component 11

• The initial state of a sub machine is the state in which a sub machine resides when it isnot active (the main machine is not in the corresponding super state). All triggers will beblocked except for the transfer call event corresponding to the sub machine.

• Synchronous return states are states that follow a valued action where the design modelis waiting for a valued reply from a used component. All triggers must be blocked exceptfor the reply events corresponding to the called used service.

• All other states are called Normal states. None of the external calls or notifications canbe blocked. The actions for certain events can be set to illegal when no action is allowed orpossible for these triggers. On the other hand, all valued reply events should be blocked innormal states, because there is no call event to any used services active, nor is any of thesub machines active.

Design models must be deterministic before the model can be marked valid. Non-determinismin ASD generally occurs when the same trigger within the same state, but on different rule cases,has different guards that can both be true at the same time. Non-determinism in ASD models iselaborated on in Section 2.2.2.

An action sequence is a sequence of events that results from a single trigger on a componentthat resides in a normal state. The action sequence ends after a transition to a normal state, whichcan be different from where it started. Action sequences are not equal to rule cases, because in anaction sequence, the component can enter one or more synchronous return states and after a reply,leave this state again before ending the action sequence. An action sequence can therefore consistof multiple rule cases and can even cover a sub machine. Any call from a client or a notificationevent from a used interface can start an action sequence. While processing an action sequence,calls from clients are blocked.

2.2.2 Interface models

As discussed earlier, ASD interface models specify the behaviour of the component as visible toother components. Because they are abstractions of their design models, interface models aregenerally less complex and smaller in terms of state space than design models. Consequently, onlynormal states (including an initial state) can be used in IMs. However, modelling events areunique to interface models. Modelling events are events internal to the interface model that caneither be optional or inevitable. An inevitable event (and its rule case) will always oc-cur if no other events are triggered and optional events (and their rule case) can possibly occurif no other events are triggered. In the verification step of an ASD component (see Section 2.5),the optional events are not assumed to occur, whereas the inevitable events are assumedto always occur if no other event is triggered. These modelling events are solely used to modelnotification events, which can occur asynchronously.

Interface models can only have normal states, because they only consist of a main machineand there are no synchronous return states. Furthermore, non-determinism is allowed in interfacemodels. Multiple definitions for non-determinism exist when it comes to discrete-event systems. Insome cases, non-determinism means that triggering the same event can have different outcomes.This is illustrated in Figure 2.6a. In other cases, non-determinism simply means that after acertain event is triggered, a choice must be made between follow-up events. Without havinganything to base that choice on, it can be considered non-deterministic or random. Figure 2.6bshows this type of non-determinism. Since an interface model is only an abstraction of the servicesit provides, when receiving a call, it has no knowledge on what reply to send and why. The choicecan therefore be considered non-deterministic. Non-deterministic interface models take on theform as illustrated in Figure 2.6b. ASD design models must be deterministic, because every replysent to a client is based on knowledge of the replies received from used components.


Call A Call A

OK NOK

(a)

Call A

OK NOK

(b)

Figure 2.6: Two types of non-determinism in discrete-event systems

2.3 Action types

Triggers or events tell a component that an action should be performed. These actions can be oneof the following types:

• If the event is allowed to occur and one or more actions should be triggered because of it,they will be named actions. It is possible that in a rule case, one event results in a sequenceof named actions. The action Siren:ISire.TurnOn of Figure 2.5 is a named action. Theseare the actions that specify most of the behaviour of an ASD model.

• When a trigger is allowed, but should not result in performing any actions, the action iscalled a no operation action (or NoOp). This essentially means to do nothing in responseto the event.

• When an action in a rule case is illegal, the corresponding trigger event is not allowed tohappen in the current state. For instance, the event turn light off would be illegal inthe state light is off. If an ASD model is successfully verified, an illegal action willnever occur. Note that illegal events can be specified in both interface models and designmodels.

• Blocked actions can only occur in design models. When an action in a rule case is blocked,the corresponding trigger event will not and cannot occur due to ASD semantics. Forexample, when a component has sent a call event to another component, it can only seethe synchronous reply event and will therefore not be able to receive any other triggers.To preserve the run-to-completion semantics (see Section 2.4), other call events cannot beprocessed by the design model and the component cannot handle notification events as well.These are therefore blocked by the design model.

• Disabled actions are only used for modelling events in interface models (inevitable andoptional). It is a design choice that the implementing component should not perform theinternal behaviour corresponding to the modelling event in a certain state of an interfacemodel.

Note that these actions cannot be combined with other types of actions in the same rule case(so Illegal and NoOp is not allowed in the same rule case), but that a rule case can have multiplenamed actions as a response to a single trigger.

2.4. ASD semantics 13

2.4 ASD semantics

In this section, the semantics of ASD is described. Since an interface model is only an abstractionof a design model, these will be ignored when discussing semantics and only the design models areconsidered in this section.

ASD operates under Call and Reply semantics, which means that every request of service(Call event), must be accompanied by an explicit Reply event that tells the caller that the requesthas been processed. Replies can be of type void, or valued. In case there is a notification interface,notification events can be sent to the design model that do not have a corresponding reply event.

ASD’s run-to-completion semantics specify that when an event is triggered, its correspond-ing action sequence (see Section 2.2.1) must be processed completely, before new triggers can bereceived. Client calls are blocked while still processing the actions sequence that can cover multiplestates.

The Monitor semantics of ASD tell us that a new client request is delayed until a previousrequest has been completed (its entire rule case). A request is completed in this sense when theclient has received a reply event that corresponds to the call event.

In ASD, models are created that are complete, meaning that in every state, the actions res-ulting from every possible incoming event or notification, must be specified. In many cases, theseactions are illegal, disabled or blocked. If a guard is present for a certain event, the actions to beperformed when the guard yields false must also be defined, even if there are none. An exampleis given in the ASD specification of Figure 2.7, modelling a light and two buttons. In this model,the event turn on will update the state variable light is off only if it is currently true. Thekeyword otherwise specifies all other possibilities for that event. In this case, it does nothing(NoOp, or No Operation) when light is off is false.

Figure 2.7: Example of the completeness semantics in ASD

Since the response to every single event of every single component or interface involved, mustbe defined, ASD specifications can have unnecessarily large numbers of rule cases. It can happenthat a component uses the services of a component that can give a hundred different responsesaccording to its specification, while it only uses and expects one of these responses. Still, everyone of these responses must have a corresponding action specified in its design model, even whenthe action is blocked or illegal.

2.5 Verification of ASD models

In ASD, model verification is used to show that a design model together with its used interfacemodels, correctly implements the specified behaviour. Only when a component is verified, can itbe referenced by other components. When all verification checks are successful, the componentwill have the following properties:


• The design model is deterministic. As explained in Section 2.2, interface models in ASD areallowed to describe non-deterministic behaviour, but design models are not. The behaviourof the component must be predictable and fully specified. This means that a designer willhave to define the order in which events should occur, even if the order is irrelevant to them.The resulting design model will be more restrictive than the designer requires it to be.

• The component does not contain modelling errors. This means that:

– The guards are complete, see Section 2.4.

– Illegal behaviour is absent. This means that events that have illegal as their action,will not be triggered by another component.

– State variable ranges are not violated. State variables should be within specified boundsand when a state variable update violates these constraints, the model is incorrect.

– State invariants are not violated. A state invariant limits the values that a state variablecan have when entering the state. If the state can be entered while not satisfying astate invariant, this will be indicated during the verification as a modelling error.

– Every occurrence of a call event will result in exactly one matching reply event, be it avoid reply or a valued reply event.

• Notification queues do not overflow. Notification queues must have their maximum sizespecified. If this size can be exceeded during runtime, the Queue Overflow Error Checkreports an error.

• The design model complies with the possible behaviour as specified in the interface mod-els. Other components have to know by looking at the interface model, what response thedesign model can give. On the other hand, the design model itself should only be expectingresponses from serving components that can actually occur. Those responses will be definedin the interface models of used components.

• The component is deadlock-free as well as livelock-free. A deadlock is a situation where noevents can occur in the component. This commonly occurs when a component is waitingfor an event that fails to occur. In a livelock situation, events are still happening within thecomponent, but a reply to a client will never occur.

The verification is applied to one ASD component at a time. After a component is verifiedand was found complying with its interface model, the interface model can be used by its client asa proper abstraction of this component. This way, computational effort required for verificationis limited, as opposed to checking a system as a whole. Unfortunately, cyclic behaviour acrossmultiple components can still be modelled (which is not desired) and this would not be indicatedby the tool.

2.6 Single-threaded and multi-threaded execution models

ASD supports two different process execution models. These are the single-threaded and themulti-threaded (standard) execution models [28]. The main difference between the two lies inthe handling of notifications. In single-threaded as well as the multi-threaded execution models,notifications are decoupled and placed in a queue. However, in multi-threaded models, there is aseparate thread for handling notifications. In single-threaded execution models, the same thread isused for processing calls and replies, and notifications. These types of models are recommended incase of a thread constrained environment or when a large number of components is instantiated.The latter is the case for LOPW, which is why all ASD models of LOPW are single-threadedexecution models. Therefore, only these types of models and their interaction will be consideredin this report. In the next chapter, LOPW, the logistical controller deployed in ASML’s waferscanners, is explained and its general structure is discussed.

3. LOPW

In this chapter, the tasks of LOPW (Lot Operations, Process Wafer) and its general structureare explained. In Section 3.1, the logistical process LOPW is in charge of, is described. After that,in Section 3.2, the ASD models that are used to model LOPW are analysed.

3.1 The logistical process of a wafer scanner

The ASML wafer scanners are used for the exposure of wafers, to imprint the desired imagesonto them. The logistical process of this step in the semi-conductor production is schematicallydisplayed in Figure 3.1, and described below.

After pre-processing a lot (a batch of wafers on which the same image should be imprinted),a wafer enters the machine from the track (TR) (or wafer storage), which represents a systemthat hands the machine the wafers. From the track, the wafer enters the wafer handler (WH)and is placed on the LOPW input path where it is prealigned with the Prealignment Unit (PU).Once the wafer is correctly prealigned (both location and rotation are correct), it is placed onto aso-called chuck at the measure side (CM) in the Wafer Stage (WS). There, the wafer is measuredin three dimensions so that a height map is created. After measuring, the chucks at the measureside and the expose side (CE) swap positions so that the wafer can be exposed and the desiredimage is imprinted on it. After exposure, the chucks with the wafers on them swap again, so thatthe exposed wafer can be unloaded from its chuck. The Discharge Unit (DU) moves the wafer outof the machine, back onto the track.

In addition to these processing steps, LOPW is in charge of scheduling and invoking multipletypes of maintenance and conditioning actions. The wafers of a lot must be processing in FIFOordering and the throughput is optimised. It is important to emphasise that LOPW is only asupervisor. It will tell its used components to perform certain tasks in a certain order and it willnot perform these tasks itself.

TR

LOAD

UNLOAD

IN

OUT

Figure 3.1: Schematic view of the logistical process of ASML’s wafer scanner

15

16 LOPW

3.2 Models of LOPW

Since LOPW’s task is very complex, an immense supervisor is required that can be laborious andchallenging to construct. Therefore, ASML has constructed LOPW from over two hundred far lesscomplex supervisors, or components, each of which is comprehensible. This causes new or alteredfunctionality to be added to LOPW with far less difficulty. If LOPW was comprised of one singlesupervisor, it would have been a tedious task to identify and alter the correct part of the modelwithout affecting any other behaviour. By modelling it as many smaller, decoupled supervisors,only one or a few components of LOPW will have to be adjusted or added.

Due to the division into smaller components, the ASD models are not too complex; the largestdesign models have twenty to fifty states, where the average number of states is around eight. Thelargest interface models of LOPW have about twenty states, but many of them only have one.Note that these numbers are about the ASD specifications of the components of LOPW and arenot necessarily related to the state space size of the components.

Even though the individual models are generally not very complex, all these components com-bined result in a complex, industrial-sized system. In order to gain more insight into this system,Python [8] was used to parse the given models and extract useful information. An analysis hasbeen performed of the number of states, unique events, state variables, and the presence of submachines of the given design models. The script that was used to perform the analysis, can befound in Listing B.1. Of these properties, the number of states and the number of rule caseswith named actions turned out to be the most useful for identifying the complexity of the indi-vidual components. As explained in Section 2.4, the number of rule cases of a component can bemuch larger than strictly needed. The number of rule cases with named actions in them thereforerepresents the complexity of a component more accurately than the total number of rule casesdoes, since it shows how many rule cases have at least been actively modelled by the designers.Analysis of the components of LOPW showed that only roughly ten percent of all rule cases havenamed actions in them. The other rule cases generally have illegal or blocked actions thatare automatically filled out depending on the named actions that are specified.

The least complex components are most suited for developing and testing an interface repres-entation in CIF, the formalisation of requirements and the application of synthesis, simply becausethey are more comprehensible. The analysis of the 279 design models of LOPW showed that theaverage number of ASD states is 7.9. The average number of rule cases with named actions inthem is 48 and the mean number of state variables in these models is 2.2. It was found that onaverage, the models concerning logistics and lot processing are the most complex in terms of ASDspecification. The LOPW component with the largest specification has 58 states, 367 rule caseswith named actions in them and 16 state variables in its design model. This shows the size theLOPW models can attain.

These results can be used to distinguish smaller components from larger ones without havingto look at them first. Later on, these results can be used to assess the applicability of component-wise synthesis on LOPW. If a correct supervisor for a certain component has been synthesised, anapproximation may be made of the time and memory it would take to synthesise a supervisor forthat component. In the next chapter, Supervisory Control Theory is explained.

4. Supervisory Control Theory

In this chapter, Supervisory Control Theory and a specification language that supports it, willbe explained. Section 4.1 introduces Supervisory Control Theory as a framework for synthesisingsupervisory controllers. After that, CIF is introduced as a modelling and simulation languagesupporting supervisor synthesis. Finally in Section 4.3, a description is given on how CIF can beused to apply Supervisory Control Theory.

4.1 Supervisory Control Theory

As explained in [20, p.63-72], supervisory control theory (SCT) is used to synthesise correct su-pervisors for discrete-event systems. Formal models of the uncontrolled system together withrequirements the supervised/controlled system must meet, are used to generate a supervisor. Theuncontrolled system is modelled in terms of plant automata that contain one or multiple states(locations) and transitions triggered by events. In these automata, a distinction is made betweencontrollable events and uncontrollable events. The controllable events can be enabled or disabledby the supervisor (for example, a command to an actuator), whereas the uncontrollable eventscannot be prevented directly (for example, user input, error alerts or replies to certain checks).This distinction is important as it greatly influences the behaviour of the resulting supervisor; itwill only be able to disable controllable events. If the supervisor would want to prevent an un-controllable event form happening, it could indirectly do so by disabling controllable events thatwould lead to a state where the uncontrollable event can occur [25].

Requirements can, for instance, be used to specify that certain behaviour is not allowed, or thatcertain events should occur in a given order. After performing synthesis on the plant automataand the requirements, the resulting supervisor will ensure that the controlled system meets the re-quirements while following the behaviour as specified in the plants. For example, if a requirementsays that a certain uncontrollable event is not allowed to occur in a specific state, the supervisorwill ensure that that state cannot be reached.

While ASD does not have the notion of marker states, in supervisory control theory, they playa significant role. From its current state, the system must always be able to reach a marker state.In such a state, every automaton is in a marked state and every state variable has a marked value.Every plant and every variable must have at least one marker state for synthesis to be applied.

In SCT, there can be undesired states from which no marker state can be reached. The super-visor prevents the system from reaching these blocking states by disabling the right controllableevents and enabling others. To illustrate this, the interaction between a supervisor and a plantis displayed in Figure 4.1. The plant sends triggers to the supervisor and the supervisor sendsthe events that are allowed/enabled back to the plant. It must be noted that one supervisor caninteract with multiple plants and enable or disable events in all of them (be it directly or indirectly).

Because events that are not allowed due to the requirements, are disabled by the supervisor,the requirements will be met when using the synthesised controller (the system will be safe).Furthermore, the controlled plant will be deadlock-free, which means that the system will keepdoing its work as desired, without ending up in a dead state where no events can occur. If thesupervised plant does not show the desired behaviour, the plants or requirements were incorrectlyspecified.

17

18 Supervisory Control Theory

Plant

Supervisor

Events triggered by the plant Events enabled by the supervisor

Figure 4.1: Schematic view of the interaction between plant and supervisor

Aside from being deadlock-free and meeting the requirements, the synthesised supervisor res-ults in the controlled system having the following properties, if the plants and requirements aremodelled properly [20, p.65]:

• The supervised system is non-blocking or trim/proper, which means that from everystate, a sequence of events can lead to a marked state. A non-blocking supervised systemimplies that it is both deadlock-free and livelock-free. Note that the definition of livelock isnot entirely the same for ASD and SCT. This is explained in Section 5.3.6.

• The supervised system is controllable, which means that only controllable events can bedisabled by the supervisor while the uncontrollable events are always enabled.

• The output of the supervisor only depends on observable outputs of the plant. In thecase of LOPW, all plant outputs are observable because no physical signals or responses arepresent in its components.

• The plant under supervision is maximally permissive, which means that the supervisorwill only prevent transitions from happening when they do not satisfy the requirements, or ifthe controllability or non-blocking properties of the supervised system would be jeopardisedby those transitions. All other transitions will be allowed by the supervisor. This propertyensures that the supervisor is unique.

The specification of what the controlled system is supposed to do, is very important as has beenconfirmed in many projects over the past decades. Many design errors and budget overruns arecaused by incorrectly modelled requirements [20, p.75]. Therefore, a precise and formal methodfor specifying the requirements is highly recommended. Most requirements are specified usingautomata, but sometimes it is easier to express requirements by using state-based expressions(invariants).

Synthesising a supervisor can be difficult, because as the number of states and variables in asystem increases, the size of the state space of the system and with that, the time and memoryit takes to synthesise a supervisor, grows exponentially. This is referred to as the state explosionproblem [14]. Much research has been conducted on this subject to address the problem. Thisissue might be alleviated during this research as the industrial-sized system comprises of manysmaller, less complex components. Synthesis is applied to these components individually, whichmeans that the state explosion problem does not occur as quickly. The state explosion problem isfurther addressed in Section 8.1.

In the next section, a modelling and simulation language with accompanying toolset thatsupports supervisory controller synthesis, is explained.

4.2. Compositional Interchange Format 19

4.2 Compositional Interchange Format

The supervisory controller synthesis for this research will be performed using the CompositionalInterchange Format (CIF) [10], a modelling language and accompanying toolset based on auto-mata that is used to specify discrete-event, continuous time and hybrid systems. The technologyhas been created in the Systems Engineering group within the Mechanical Engineering departmentof the Eindhoven University of Technology. CIF supports, among others, supervisory controllersynthesis and simulation-based verification and visualisation, which makes it an excellent choicefor the controller synthesis that will be performed in this project. Moreover, specifications canbe made in a compositional way. This means that an automaton can be modelled once andthen be instantiated multiple times without having to model the automaton again. This adds tothe evolvability of systems that are modelled using CIF. Finally, transformations to verificationlanguages such as UPPAAL [27] and mCRL2 [9], are readily available. CIF is built around the su-pervisory control theory framework, which is why notions like controllability of events and markerstates are present in the toolset.

CIF uses a flat model, meaning that all automata are at the same level of importance and thatthere are no clients and used components. If one would like to create a hierarchical structure in themodels using CIF (like the one implemented with ASD), the architecture has to be constructed byhand. In the past, some research has been conducted on the translation from LOPW componentsin ASD to CIF ([3], [16], [21]) and on component-wise synthesis using CIF [12]. In the next section,it will be explained how CIF can be used to perform synthesis.

4.3 Supervisory Control Theory in CIF

In CIF, the required elements for the synthesis of a supervisor are specified as plant andrequirement automata. The plant automata specify the possible behaviour of the system,while each of the requirements limit a portion of that behaviour. All requirements together en-sure that only the desired behaviour will be enabled by the supervisor. An example of a plantautomaton as explained in [20, p.63] is as follows:

Listing 4.1: Example of a plant automaton in CIF as used in SCT

plant M1:

controllable start_M1, repair_M1;uncontrollable end_M1, breakdown_M1;

5

location Idle:initial; marked;edge start_M1 goto Processing;

10 location Processing:edge end_M1 goto Idle;edge breakdown_M1 goto Down;

location Down:15 edge repair_M1 goto Idle;

end

Note that there is a distinction between controllable and uncontrollable events, and that amarked location is specified.

Aside from plant and requirement automata, monitor automata can be used in combinationwith requirement invariants to limit the behaviour of the synthesised supervisor. These monitorscan be modelled like regular plant automata, except they do not block any behaviour themselves.Monitors are especially useful when constraining the behaviour of one plant depending on the stateof another. The following example describes how a monitor can be used to facilitate requirement

20 Supervisory Control Theory

specification.

Example 4.3.1: Consider two plant automata: InputPath and Queue. InputPath can, amongothers, receive wafers and send them off to the next subsystem. The Queue automaton deliversthe wafers to the input path. The monitor automaton M InputPath keeps track of the availabilityof the input path. It must be emphasised that the monitor allows all events to happen in everystate (not the case for plant or requirement automata), which means that wafer leaves is stillpossible, even if the monitor is in state Empty. A requirement invariant specifies that Queue canonly send a wafer to the input path, if it is empty. The monitor M InputPath and accompanyingrequirement invariant can be modelled in CIF as follows:

plant M_InputPath:monitor;location Empty:initial; marked;edge InputPath.wafer_enters goto Full;

location Full:edge InputPath.wafer_leaves goto Empty;

end

requirement Queue.send_wafer needs M_InputPath.Empty;

Note that the requirement invariant does not introduce states on its own. By specifying re-quirements this way, the resulting supervisor can disable certain events depending on events andlocations of other plants. Another way to specify requirements is by using requirement automata.An example of such an automaton is given below.

Example 4.3.2: Suppose an informal requirement states that whenever a wafer enters theinput path (InputPath.wafer_enters), the output path must be notified (OutputPath.notify_wafer_enters), after which the input path sends a void reply to its client. Thisrequirement can be modelled as an automaton with the following CIF specification:

Listing 4.2: CIF implementation of a requirement automaton

requirement R_1:location Idle: initial; marked;edge InputPath.wafer_enters goto NotifyOutput;

location NotifyOutput:edge OutputPath.notify_wafer_enters goto Void;

location Void:edge InputPath.VoidReply goto Idle;

end

In contrast with monitor automata, requirement automata can prevent events from happening.In the example, the events OutputPath.notify wafer enters and InputPath.VoidReplywill only be possible if the requirement automaton is in state NotifyOutput and Void, respect-ively.

After the plants and requirements are modelled in CIF, the synthesis algorithm can be started.CIF supports event-based and data-based synthesis where the event-based approach is not meantto model systems with variables in them. It is possible to model state variables for event-basedsynthesis by modelling every value the variable can attain as a state of an automaton, but thiscan make the models unnecessarily large and complex. Data-based synthesis does allow for theuse of state variables, making it the right choice for this project. More information on data-basedsynthesis is given in the next section.

4.3.1 Data-based synthesis

CIF’s data-based synthesis tool will be used for this research to perform the synthesis step on thespecified plants and requirements. However, this synthesis method comes with a few restrictions,

InputPath.wafer_enters

OutputPath.notify_wafer_enters

OutputPath.notify_wafer_enters

4.3. Supervisory Control Theory in CIF 21

some of which also apply to event-based synthesis:

• As opposed to event-based synthesis, state variables are allowed to be included in the auto-mata in data-based synthesis, preventing the models from becoming unnecessarily large.However, in the current version of CIF, not all types of variables can be used in a plantto synthesise a supervisor. The state variables that are currently allowed are discrete andof type Boolean, ranged integer or enumeration. This means that continuous and algebraicvariables are not (yet) supported. If an integer is used, its range must be specified alongwith it. For more detailed restrictions to state variables and their operations, see [20, p.98].

• Only events that are defined as controllable or uncontrollable are supported.

• Non-determinism between controllable events is not allowed in the plant automata. Thismeans that if a single event in the same location has multiple outgoing edges with overlappingguards, the tool will not generate a supervisor. This type of non-determinism is illustratedin Figure 2.6a.

• Automata must always have one initial location that cannot be conditional (for example:initial x<3 is not allowed). The automata also require at least one marked location.

During a pre-processing step, multiple transformations are applied in order to increase thenumber of specifications for which a supervisor can be synthesised. After these pre-processingsteps, the synthesis algorithm can be started. A supervisor automaton is then generated thattogether with the requirements form the supervisor that can be used to control the plants. Therequirements specify what behaviour is allowed and what is not and the supervisor automatonprevents blocking situations that could be caused by these requirements from occurring. CIF’sdata-based synthesis algorithm is based on a paper by Ouedraogo et al. [18]. In the next chapter,the application of supervisory controller synthesis on LOPW is elaborated on.

5. Supervisory Control Theory for LOPW

Now that it has become clear what the capabilities and restrictions of supervisory controllersynthesis and CIF are, the methods used to perform synthesis on the existing components ofLOPW, will be explained. Section 5.1 aims to explain what Supervisory Control Theory can dofor ASD components. When using SCT, requirements come into play, as explained in Section 5.2.Finally in Section 5.3, a detailed discussion of how to apply synthesis on existing ASD components,is given.

5.1 SCT and ASD components

As explained in Chapter 2, the interface model of an ASD component represents its possibleexternal behaviour. This means that an interface model can be seen as an uncontrolled plant.The design model of an ASD component specifies which of the possible events should occur andwhen. A design model can therefore be thought of as a supervisor that enables or disables eventstriggered by a plant. This is schematically displayed in Figure 5.1. It is important to emphasisethat in the left representation of the system, the interface models (IM) are not used to generatecode used during runtime and that they are only there for verification and abstraction purposes.On the right-hand side however, the plants and the supervisors (Sup) are used to generate codethat will be used at runtime. The top plant can trigger an event and based on that, the underlyingsupervisor will allow one or more events to occur in the top and bottom plants. In turn, theircorresponding supervisor will enable certain events of their underlying plants.

IM

DM

IM IM

DM DM

Sup

Plant

Plant Plant

Sup Sup

Figure 5.1: Schematic view of ASD components and a corresponding SCT representation

Applying supervisory controller synthesis on a component of LOPW means performing thefollowing steps:

1. The interface models are manually transformed into plant models.

2. Formal requirements are specified that help to enable or disable the right events at the righttime. Each requirement defines a part of the total behaviour the controlled system shouldsatisfy. These formal requirements are based on informal requirements listed in the designdocumentation of LOPW.

23

24 Supervisory Control Theory for LOPW

3. Synthesis can then be applied in order to obtain a supervisor. This supervisor satisfies therequirements as desired if the transformation of IMs and the specification of requirementswas performed correctly.

This procedure can be performed for multiple components of LOPW, resulting in many differ-ent supervisors. It is currently not in the interest of ASML to restructure the division of LOPWinto smaller components. Furthermore, a lot of thought and effort went into designing it, whichis why the interface models and with that, the possible behaviour of every component, is kept asit currently is. As the interface models are given, they only need to be manually transformed intoplant automata and the requirements need to be formalised to be able to perform synthesis andobtain a supervisor. This is explained in the next section.

The goal is to apply synthesis to all components of LOPW and to completely construct it fromgenerated supervisors, instead of manually designed ones. The main advantage of this is thatthe controllers do not have to be designed manually any more. Currently, the high-level informalrequirements in the LOPW design documentation have been implemented as multiple low-leveldecisions. As this is done manually, there is a chance of implementing incorrect behaviour withrespect to the requirements, which can be difficult to identify. By performing synthesis, the high-level, requirements are formalised and then implemented as individual requirements. This way,there is a clearer mapping from informal requirements to formal, implemented requirements. Anychanges to the requirements can then easily be applied to LOPW, because it should be clear whereeach one is being implemented.

In the next section, the types of requirements needed for synthesis to be applied, are described.

5.2 Requirements

The requirements needed for synthesis to be applied, can come from two sources. Part of themcome from the LOPW design documentation, and other requirements need to be extracted fromthe existing design model using reverse engineering. Since some requirements are added in asimilar way in multiple different components, they can be modelled in a reusable way in CIF.

5.2.1 LOPW design documentation

Many requirements are given in the LOPW design specification document (Element Performanceand Design Specification or EPDS [26]). These informal requirements have been implementedas low-level decisions in the design models of LOPW and should therefore be formalised so thatthey can be implemented and used for synthesis. However, formalising these requirements is notalways straightforward, because they are not listed per component and they can be difficult totrace. Furthermore, a number of ASD components do not have requirements on them listed in thedocumentation. Many requirements involve events from LOPW’s used components or client andnot components of LOPW itself. An example of such a requirement is:

LOPW shall notify used component1 when starting to process a lot by calling used_component1:processing. A lot is processing when the lot was started at LOPW (Client1:start lot).

This requirement is about events that are not present in any of the ASD models of LOPW,but it is still about a function of LOPW. An example of a requirement that illustrates the effortit can take to formalise the given requirements, is the following:

If the wafer handler must be cleaned for a lot, the lot shall not be reported as finished until theclean wafer handler action is finished.

used_component1:processing

used_component1:processing

5.2. Requirements 25

Even if there was an LOPW component called CleanWaferHandler, this requirement might notbe traceable to it. Instead, it could restrict the behaviour of another component. Furthermore,it does not specify which event is constrained, or which variables are involved. This exampleemphasises that formalising the requirements given in the LOPW design documentation shouldnot be taken lightly.

After modelling the formalised requirements obtained from the design documentation, thebehaviour of the synthesised supervisor can be compared to that of the existing design model. As-suming the plants are correctly modelled in CIF, there can be several causes for possible differencesbetween the two:

1. One or multiple requirements are incorrectly formalised or specified. Checking the require-ments and adjusting their implementation in CIF can resolve this.

2. A number of requirements are not listed in the LOPW design documentation, but can bespecified as such. The ASML engineers who constructed the components of LOPW couldperhaps have assumed it was unnecessary to list certain requirements in the documenta-tion. In that case, the requirements can be added to the LOPW design documentation andthe extracted requirements must be added to the CIF specification. More on requirementextraction from the design models is given in the following section.

3. The behaviour of the design model differs because of ASD semantics that is not present inCIF. Requirements can be added to the CIF specification in order to achieve equivalence, butthat is not necessary if the ASD semantics need not be present in the synthesised supervisor.

4. Some freedom remains between the existing design model and the synthesised supervisor,even though all requirements have been implemented correctly, including those that areadded because of points 2 and 3. This could be caused by the design model being morerestrictive than necessary.

It takes domain knowledge to distinguish differences caused by requirements that are missing(2) from differences caused by ASD semantics (3) or freedom remaining even though all require-ments have been implemented correctly (4). That is why in the future, domain experts will haveto look at the models to decide what requirements can be added to the documentation and theformal specification. Finally, implementing the informal requirements given in the EPDS insteadof prioritising equivalence, will make sure that the supervisor actually does what ASML wants,and not just what the existing design models do.

5.2.2 Extraction from design models

If the informal requirements listed in the LOPW design documentation have been formally spe-cified and differences are observed between the synthesised supervisor and the existing designmodel, additional requirements can be extracted from the existing DM. As mentioned earlier,some of these requirements could be added to the LOPW design documentation, and others canbe added because of ASD’s semantics. By iteratively adding extracted requirements, applyingsynthesis and comparing the two models, the gaps between the synthesised supervisor and theexisting design model can (at least partly) be filled.

In Figure 5.2, the places where requirements are applied, are indicated. It shows that therequirements listed in the EPDS for LOPW are transformed into low-level decisions for the designmodels, and formal requirements for the synthesis procedure. Furthermore, requirements are ex-tracted from the existing design model and added to the specification used to apply synthesis.

In ASD design models, the order in which actions of a single rule case are triggered, must bespecified and cannot be left to chance. As explained in Section 2.2.2, interface models are allowed


IM

DM

IM IM

DM DM

Sup

Plant

Plant Plant

Sup Sup

Low-leveldecisions

Formalrequirements

Manuallyextracted requirements

Figure 5.2: Schematic view of the synthesis procedure with requirements indicated

to be non-deterministic, but design models are not. This means that designers have to define anordering of events without having a reason to choose any particular order. The following exampleexplains this statement:

Example 5.2.1:Suppose a certain event X should cause two events to be triggered: A and B. Then there can

be a requirement that states:

After an event X, LOPW shall trigger A and B before continuing lot processing.

Even though this requirement does not state the order in which the resulting actions should beexecuted, it will have to be defined in the design model for it to pass the determinism check of theverification. The difference that can be observed between a requirement and its implementationis illustrated in Figure 5.3. Figure 5.3a shows the behaviour of the requirement that is to beimplemented. The two possible ways to actually implement this in ASD are shown in Figure 5.3band Figure 5.3c.

X

AB

BA

(a) Example of a requirement

X

A

B

(b) Implementation ofthe requirement

X

B

A

(c) Another implement-ation

Figure 5.3: An example of a requirement and its implementation due to non-determinism notbeing allowed in a DM

5.2. Requirements 27

This example shows that the implementation of behaviour in an ASD model is not always theresult of requirements that specify that behaviour. When trying to achieve equivalence between anexisting design model and a synthesised supervisor, this kind of requirement must be implemented.However, when synthesising a supervisor for a component of LOPW that should only satisfy theinformal requirements of the design documentation (without achieving formal equivalence with thedesign model), requirements of this sort will not necessarily have to be implemented and the lessrestrictive type (Figure 5.3a) can be implemented instead. Depending on whether or not domainexperts think the order of certain events was deliberately chosen that way, the more restrictiverequirements (Figure 5.3b and 5.3c) may or may not be implemented in the specification used forsynthesis.

Note that the requirement of Figure 5.3a has a larger state space than the ones shown in figures5.3b 5.3c, and will also have a larger CIF specification. This shows that having more freedom ina model can result in a larger supervisor, especially if the order of more than two events is to bedefined. The time and memory it takes for the synthesis algorithm to compute a supervisor willbe increased when increasing the state space size.

While examining components of LOPW, it was discovered that many components have re-quirements that can be added to the specification. Most of these can be modelled in a reusableway because they ensure the same behaviour in multiple different components, as explained inthe next section. Other requirements not listed in the design documentation are mostly aboutwhat action should follow what responses to a call and what service must be invoked when aclient call comes in. If synthesis is to be applied to all components of LOPW, the EPDS shouldfirst be expanded by adding more informal requirements. In the next section, more requirementsare given that are not there because of design choices, but because of ASD semantics or behaviour.

5.2.3 Reusability of requirements

If ASML is to apply supervisory controller synthesis on all components of LOPW, it might be in-teresting to see how the same requirements can be adapted to different components. CIF supportsdefining requirement automata and then instantiating those in different components. Further-more, requirement invariants could be generated using any coding language (for example Python)by using the names of the components that are involved. In this section, the reusability of require-ments is explored.

A set of requirements that is needed because of the semantics of ASD models are those thatimpose the monitor semantics discussed in Section 2.4, on the plants. Monitor semantics statethat a component can only process one call at a time. Used components of a component are notallowed to trigger events while another used component is busy and the client itself is not allowedto receive a call or send a response. The following specification presents an example of how this canbe modelled in a requirement without adding any states to the state space size of the controlledsystem:

requirement UsedComp1.Busy or UsedComp2.Busy disables {UsedComp1.call_A, UsedComp2.call_B, Client.response, Client.call};

Both used components and the client cannot issue calls when any of the used components arebusy. Moreover, the client can also only send a response once both its used components are nolonger busy. Another type of requirement that can be added because of the way ASD models areconstructed, is caused by the hierarchical structure that needs to be constructed in CIF. Usedcomponents to a component can only be called if the component itself asked for it. Therefore,while the client is in a normal state, calls to used components are disabled. An example of arequirement invariant that ensures this behaviour is satisfied, is the following:


requirement Client.Initial or Client.Idle disables {UsedComp1.call_A, UsedComp2.call_B};

When implementing the hierarchical structure in CIF, it will also follow that the client canonly send its void reply after a used component has sent its void reply. This can be modelled usinga requirement automaton of the following form:

requirement R_VoidReplies:location Idle: initial; marked;

edge UsedComp1.VoidReply goto ClientVoid;location ClientVoid:

edge Client.VoidReply goto Idle;end

Since the hierarchical relation between client and used component is present for every ASDcomponent, requirements involved can be modelled in a reusable way and adapted to every com-ponent by simply providing the names of the client and the used components for that component,and their event names. The aforementioned types of reusable requirements are not unique toLOPW, but apply to any system that is modelled in ASD and needs to be translated to a trans-ition system this way. It can be argued that these do not have to be specified in CIF, becausethey are only a result of the way ASD models are constructed. However, it is desired to maintainthe hierarchical structure and call/reply style of component interaction and by modelling theserequirements for every plant, that is achieved.

Additionally, there are some requirements that are less general and more specific to LOPW.These are also not listed in the documentation, but they do occur in multiple components ofLOPW and therefore, need to be extracted from the existing design models where applicable.

• In many components, call events or notifications need to be forwarded to the component’sused components and clients, respectively. Sometimes the requirements needed to imposethis behaviour on the component, are not listed in the design documentation. That is whythey need to be extracted from the existing design models where applicable. For example,several components have to be initialised before normal processing can be started. Many ofthose components will forward the initialisation to its used components. The requirementthat specifies that initialisation is forwarded to a number of used components, is not listedin the design documentation and therefore needs to be added to the CIF specifications,preferably in a reusable way.

• Foreign components can tell LOPW that an error occurred by notifying the componentthat can request a service from that foreign component. There are several ways LOPWcan respond to an error. Mostly, this error notification is forwarded to components higherup in LOPW. The components themselves enter an error state where no state transitionsoccur until production is stopped. The requirements involving error handling are generallynot listed in the design documentation and will therefore be added during requirementspecification.

• Whenever unexpected behaviour is detected, a violation is reported using the Logger com-ponent. Especially armouring components make great use of this, but other components doso as well. This violation detection is not included in the LOPW design documentation. Amonitor automaton can be used to keep track of violations that are detected. If a violationhas been detected, requirements should insist that only the event that reports the violationto the Logger, is enabled. The cases in which a violation is detected, is different for everycomponent. However, the response to it is approximately the same for many componentsand therefore, requirements involving violation detection could be modelled in a reusableway.

Most of the requirements listed in the LOPW design documentation are too unique to modelas reusable requirements. The rest of this chapter is about explaining how supervisory controllersynthesis can be applied to ASD components.

5.3. Application of synthesis on ASD components 29

5.3 Application of synthesis on ASD components

The idea is to apply data-based synthesis as discussed in Section 4.3 to the individual componentsof LOPW. What we need are plant automata specifying the possible behaviour of the system,and requirements that constrain this behaviour such that only the desired behaviour is enabled.Therefore, the possible, uncontrolled behaviour of the interface models will be modelled as plantsin CIF. After that, the requirements given in the design documentation, and those manually ex-tracted from the existing ASD design model, will be formally modelled in CIF. As was shown inFigure 5.1, the interface models of the component itself, but also of all its used components, willbe manually transformed from ASD to CIF.

If the plant automata and requirements have been modelled correctly, the synthesis tool willgenerate a supervisor that resembles the design model. The supervisor can be simulated to checkif its behaviour is as desired or expected. Unfortunately, ASD does not allow for simulation ofcomponents, which impedes manual verification of the supervisor. If there are differences dis-covered between the ASD design model and the synthesised supervisor, requirements will have tobe changed and most likely added (assuming the IMs have been correctly transformed from ASDto CIF). After simulation, formal validation (see Chapter 7) will be performed to show whetheror not both models display equivalent behaviour under the same circumstances.

The rest of this section is dedicated to explaining the differences between ASD and CIF (orSCT in general), and how these can be overcome when manually transforming interface modelsinto plant automata and formalising requirements.

5.3.1 State transitions

Transitions in an ASD model can be represented by a sequence of events, whereas in CIF, atransition is only represented by a single event (and possible state variable updates). This meansthat pseudo-states must be introduced to correctly manually translate ASD models into CIFmodels. The addition of pseudo-states and pseudo-events is explained in the following example.

Example 5.3.1: Consider the rule case of Table 5.1. After the guard evaluates to true, thetrigger Call A results in two actions (VoidReply A and Call B), a state variable update and astate transition to X2.

Table 5.1: Example of a rule case in ASD

Current state Trigger Guard Actions Updates Target state

X1 Call A a > 0 VoidReply A; Call B a = 0 X2

Figure 5.4 shows the ASD implementation as visible to the user where all tasks are performedon one transition. In Figure 5.5, the CIF implementation of the rule case is schematically dis-played. Note that three pseudo-states and one reply event have been introduced.

In CIF, this rule case could be modelled as in Listing 5.1. In this listing, ... indicatesadditional behaviour that occurs when state X2 is reached, which is outside the scope of thisexample. Furthermore, the initial value of the state variable is set to zero, as given in the ASDmodel.

It must be noted that implicitly, these reply events and pseudo-states are present in the ASDmodels, but are just not visible to the user in the ASD:Suite modelling environment, for claritypurposes.


X1 X2

Call A[a > 0]

- - - - - -VoidReply A; Call B

a = 0

Figure 5.4: ASD implementation of the rule case of Table 5.1

X1 ps1 ps2 ps3 X2

Call A[a > 0] Call B VoidReply B

VoidReply Aa = 0

Figure 5.5: CIF implementation of the rule case of Table 5.1, where pseudo-states are introduced

5.3.2 Controllability of events

As mentioned before, a distinction must be made between controllable and uncontrollable events.This means that all events that can occur in the component, must be categorised as either con-trollable or uncontrollable in the CIF specification, before synthesis can be performed. This cat-egorisation is rather easy to obtain, because all incoming events are uncontrollable to the designmodel and all outgoing events are controllable. This is displayed in Figure 5.6 where the uncon-trollable events are dashed and the controllable events are shown as normal arrows. This samecategorisation can be used when modelling the plants in CIF.

However, in order to model the monitor semantics imposed by ASD, the incoming calls from aclient (from A to DM in Figure 5.6) must be prevented while a used component is busy processing aservice invocation. Therefore, these calls will be modelled as controllable in the CIF specificationsused to apply synthesis. Simulating the supervised system showed that the desired behaviour canstill be achieved.

A

DM

B C

Figure 5.6: Schematic view of controllable (normal arrows) and uncontrollable events (dashedarrows)

The implicit void replies as discussed in the previous section also adhere to the same categor-isation. This means that void replies to calls from Interface A in Figure 5.6 will be controllableand void replies to calls to Interfaces B and C (to their individual design models below them) areuncontrollable.

An interesting observation is that the controllability of events changes as the perspectivechanges. The replies a component sends to its client are controllable to itself. However, tothe used component receiving these replies, they are uncontrollable.


Listing 5.1: CIF specification of a plant automaton with pseudo-states

plant Example:controllable VoidReply_A, Call_B, Call_A;uncontrollable VoidReply_B;

5 disc int a = 0;

location X_1: initial; marked;edge Call_A when a > 0 goto Ps_1;

10 location Ps_1:edge Call_B goto Ps_2;

location Ps_2:edge VoidReply_B goto Ps_3;

15

location Ps_3:edge VoidReply_A do a := 0 goto X_2;

location X_2:20 ...

...end

5.3.3 Notification events

Regular events in ASD are synchronous, meaning that a call or reply event occurs in the clientand the used component at the same time. Asynchrony occurs in terms of notifications (alsocalled callback events and often indicated as cb in LOPW), which are events that occur in a usedcomponent first, and are then processed by the client. Notifications can occur in two ways:

• As shown in the Message Sequence Chart of Figure 5.7a, notification events can be triggeredafter a synchronous call was followed by a reply. This is called a solicited notification, itis expected. Before the notification is triggered, the client can perform other tasks, it doesnot have to wait for the notification event. An example could be that the call-reply coupleinquired a certain process and the notification marks the end of that process. Solicitednotifications can be linked to the inevitable modelling event discussed in Section 2.2.2.

• Notifications can also be unsolicited or spontaneous. They can be triggered without aspecific call event having occurred. An example is an error message; the component mustbe notified whenever an error occurs, regardless of which events were triggered in the past.This type of notification is shown in Figure 5.7b. Unsolicited notifications can generally belinked to the optional modelling event discussed in Section 2.2.2.

Notification events are decoupled and can be placed in a queue, even if the client receiving thenotification is waiting for a reply event. This means that a component can send a notificationevent, while the component receiving the notification can postpone processing the notificationuntil later. After the client receives the reply it was waiting for, the notification queue is emptiedand all corresponding actions are executed. Unlike synchronous events, asynchronous events arenot triggered in the client and the used component at the same time. Because asynchrony cannotbe modelled in CIF, a queue must be created in terms of an automaton so that the Notificationscan be represented as a sequence of synchronous events [21, p.18]. A state space representationof a queue automaton that can be used for both notification types as discussed above, is given inFigure 5.8. More information on notifications in ASD is given in the ASD runtime guide [28].

A notification queue automaton starts in state E where call events can be triggered (indicatedby Call). Once Notification occurs in Comp, no new calls or notifications from other componentsare allowed to be triggered before the notification event is actually processed (indicated by trig-ger Notification) and the queue automaton returns to its initial state. By modelling a notification


Queue Client Component

Call a

Reply a

Notification a

Blocked

Not blocked

(a) MSC of a solicited notification

Queue Client Component

Notification a

(b) MSC of an unsolicited notification

Figure 5.7: Message sequence charts for both ASD notification types

E F

Comp.Notification

trigger Notification

Comp.Call

Figure 5.8: Schematic view of a notification queue automaton. E stands for Empty and F standsfor Full.

queue this way and correctly specifying the events that are allowed and those that are not, repliescan still come in while queuing notifications and call events are blocked until the queue is emptied.

Notification queues are modelled as automata with an accompanying requirement that preventsevents from happening while a queue is full (representing the self loop Call in Figure 5.8). Anexample of such an automaton and requirement in CIF is:

plant Q_Notification:controllable trigger_Notification;

location Empty: initial; marked; // Abbreviated to Eedge Comp.Notification goto Full;

location Full: // Abbreviated to Fedge trigger_Notification goto Empty;

endrequirement Comp.Call needs Q_Notification.Empty;

As stated before, multiple notifications can be placed in one queue as long as they come fromthe same component. The notification queue automaton can therefore be expanded so that it cancontain more than one notification at a time. However, as the number of possible notificationsthan can enter a queue grows, the complexity grows too. A queue automaton that can hold twonotifications from the same used component at once is shown in Figure 5.9, where a and b are theincoming notifications and A and B represent the triggering of those notifications.

5.3.4 Special action types

As discussed in Section 2.3, there are several different action types besides the regular NamedAction. These special action types are mostly related to the completeness semantics explainedin Section 2.4. Since it represents performing no action after an event, the NoOp action can bemodelled in CIF as simply doing nothing after the event occurs. A self-loop is introduced tomodel this behaviour, which means that the event occurs, but there are no accompanying state


ab

b

a

AB

A

B

Calls

Figure 5.9: Example of a notification automaton with a size of two

transitions.

As they are not allowed or designed to occur and CIF does not have completeness semantics,the Blocked, Disabled and Illegal actions can simply be left out in the CIF specification by notmodelling their triggers in specific states. Named actions can be modelled in CIF as discussed inSection 5.3.1.

5.3.5 Internal events and state variables

The supervisor obtained through synthesis can only use events that have been specified before,which means that if the design model contains events that are not present in any of its interfacemodels, these will have to be defined before starting the synthesis procedure. This is the case fortransfer events, the events that mark a transition from main machine to sub machine and back.Fortunately, only 10% of the design models are comprised of sub machines in addition to the mainmachine. Moreover, this will only be a problem when trying to achieve equivalence between theexisting components and the synthesised supervisors. Since the goal instead is for the supervisorsto meet the given requirements, sub machines will not be present in the specification of plantsand requirements. Other events internal to a design model have not been encountered in the ASDmodels of LOPW. Furthermore, the synthesis procedure cannot come up with variables out ofthin air, so if there are state variables present in the ASD models, these have to be specified alongwith their corresponding updates and checks. This can be done by adding extra automata andrequirements. Again, this is only needed if the synthesised supervisor must behave the same asthe existing design model.

5.3.6 Marker states

As explained in Section 4.1, in CIF, certain states can be defined as marker states, while there areno marker states defined in ASD models. During the manual translation of an ASD component,this does not matter, because no marker states have to be defined. However, when modellingplant automata for a synthesis problem, at least one marker state has to be specified for everyautomaton. The correct states will have to be picked as marker states. These states can be foundby looking at the definitions of livelocks in SCT and in ASD. The definition of a livelock in SCT isa situation where events can still occur, but no marked state can be reached. A livelock in ASD isa situation in which events can occur indefinitely, but the component will never serve its clients,it will not send a reply. If one was to align these definitions, the only conclusion to be drawn, isthat any state an ASD component arrives in after serving its client, is a marked state. This meansthat any normal state of an ASD interface model is a marked one. As a result, any pseudo-statesthat are introduced are not marked. The initial state of a component that involves initialisationis a normal state, but can not always be reached after sending a reply to a client. However, itwill still be marked, because it is the initial state and because a marked state does not have to be


reachable after the state is left, as long as any other marked state is reachable.

Automata that are introduced in addition to the plants for the interface models, must all haveat least one marked state as well. These are requirement, queuing and monitor automata. Markingof the correct states for these automata is performed as follows:

• Requirement automata are often used to specify a certain chain of events that have to betriggered in the correct order. After this chain of events has been executed, it will alwaysreturn to its initial state. Therefore, only the initial state of such requirement automata willhave to be marked. Note that in other requirement automata, more states may have to bemarked.

• Queuing automata make sure that only one specific trigger is possible after a used componentproduces a notification. This trigger must occur before any other events can happen. Afterthe trigger, the queuing automaton returns to its initial state. Again, only the initial stateof these automata will be marked.

• Since monitor automata should not directly influence the behaviour of the controlled systemin any way, all states of a monitor must be marked. This way, the monitor is allowed toremain in any state.

Finally, variables can be marked so that the system should always be able to return it to somespecific value. However for livelocks, according to ASD, it only matters whether the componentcan serve its clients. Since this is independent of the value of state variables, all values will bemarked. By default if no values are marked for a state variable in the CIF specification, all ofthem will become marked.

5.3.7 Property checking

Important systemic properties of logistics systems like deadlock freeness and liveness can be formu-lated as the non-blocking property [7]. In ASD, the verification step makes sure that a componentis non-blocking. However, this is limited to a single component, which means that the system as awhole could arrive in a blocking state where it cycles events between several components withoutever sending a reply to a client, while the individual components do not [16, p.60].

Generally in SCT, for larger systems, it can be difficult to guarantee non-blockingness or toverify whether a system is non-blocking because of the state explosion problem. Because of thecomponent-wise approach used in this research, the size of the state space will not explode.

6. Example component: WH Clean

In this chapter, a small, fictional component will be examined closely. The given and extractedrequirements are explained, the state space that represents the component’s behaviour is shownand the application of synthesis to this component is elaborated on. It must be noted that theevent names of the ASD model are abbreviated to improve readability. The original names arestill shown in the ASD specification of the design model of Figure 6.3.

The component WH Clean is a simple component that allows LOPW to check if the waferhandler needs to be cleaned by requesting two services from its used components. A schematicview of the components involved with WH Clean is given in Figure 6.1.

WH Clean

WH Clean

DataStore1 DataStore2

Figure 6.1: Schematic view of components involved with WH Clean

The behaviour specified in the design model is as follows:

1. Upon a call clean needed (abbreviated to clean), trigger DataStore2.is_cleaning_option_enabled (abbreviated to option).

2. When this check responds positively (enabled), trigger DataStore1.wafer_present,which is abbreviated to wafer. If it responds negatively (disabled), return no to theclient.

3. If the check for a wafer being present responds negatively (False), meaning that there isno wafer present, return yes. Otherwise, respond to the client with no.

This behaviour is schematically displayed in Figure 6.2 and the ASD specification of its designmodel is shown in Figure 6.3, where the guards and state variable updates column are left out,because there are no state variables for this component. note that in this specification, the rulecase numbers are not continuous, because there are a lot of illegal and blocked events presentthat are hidden. There are three interfaces involved with this component: WH Clean.im, Data-Store2.im and DataStore1.im. These will have to be manually transformed from ASD to CIF plantautomata. State space representations of the behaviour relevant to WH Clean of these interfacemodels, can be found in Figure 6.4.

In the design documentation, no requirements are given on this component. Since the interfacemodel only specifies that a trigger clean needed results in yes or no with no events in between,one or multiple requirements must be added to achieve the behaviour listed above. It transpiresthat the behaviour can be constrained by two requirements:

35

DataStore2.is_cleaning_option_enabled

DataStore2.is_cleaning_option_enabled

DataStore1.wafer_present

36 Example component: WH Clean

clean- - - - -option

disabled- - - - -

no

enabled- - - - -wafer

True- - - - -

no

False- - - - -

yes

Figure 6.2: WH Clean.dm as it is modelled in ASD

Figure 6.3: ASD specification of the design model of WH Clean

• Upon receiving a call clean needed, check if cleaning option is enabled on the ma-chine and if a wafer is present. If the cleaning option is enabled and there is no wafer present,reply with yes. If any test fails, do not perform the other test and reply with no.

• Perform the check on cleaning option before checking if a wafer is present.

Looking at the requirements of multiple components of LOPW showed that there are manyways to define requirements, even when doing it formally. In this case, the first requirement couldbe split up into three requirements by decoupling the responses yes and no from it. This tells usthat one must be careful not to become inconsistent when defining requirements for the compon-ents of LOPW.

Interestingly, the second requirement was added simply because ASD design models do notallow non-determinism in them. In reality, the ordering of the checks is confirmed by an ASMLengineer to be irrelevant. This was discussed before, in Section 5.2.2. The behaviour as allowed bythe engineers, is shown in Figure 6.5. This is the way the component would behave if the secondrequirement was left out.

In addition to the three interface models, one requirement automaton that combines both re-quirements, was added to the CIF specification to model the behaviour. The CIF listing with theplant and requirement specifications can be found in Listing C.1. Data-based synthesis has beenapplied to this system and a supervisor automaton was obtained. Through simulation, it wasshown that the controlled system consisting of the supervisor and the plants, behaves the same asthe ASD design model does. The CIF specification of the supervisor automaton generated by thesynthesis algorithm is as given in Listing 6.1.

37

clean needed yes no

(a) WH Clean.im

wafer True False

(b) DataStore1.im

option enabled disabled

(c) DataStore2.im

Figure 6.4: State space representations of the interface models involved with WH Clean withcontrollability with respect to the design model indicated

clean

option

disabled- - - - -

no

enabled- - - - -wafer

False- - - - -

yes

True- - - - -

no

wafer

True- - - - -

no

False- - - - -option

enabled- - - - -

yes

disabled- - - - -

no

Figure 6.5: WH Clean.dm as it could be modelled if non-determinism was allowed

The state space representation of the supervisor automaton resulting form the synthesis al-gorithm is given in Figure 6.6. It must be noted that the supervisor itself is represented by thecombined behaviour of the supervisor automaton and the requirement. Together with the plantautomata, the supervisor represents the controlled system that behaves as shown in Figure 6.7.The fact that the supervisor automaton only has one state with simple guards shows that it doesnot disable a lot of behaviour in the plants and that in this case, most of the behaviour thatis allowed, is specified by the requirement. However, without the guards the supervisor auto-maton imposes on the plants, blocking situations could have occurred. For example: the require-ment automaton specifies that a response to DataStore1.wafer can only occur after receivingDataStore2.enabled. Since this is an uncontrollable event, it might never occur, which wouldcause the plant DataStore1 to reside in an unmarked state indefinitely had DataStore1.waferbeen triggered. The supervisor automaton ensures that DataStore1.wafer is only triggeredafter DataStore2.enabled has been received, preventing a livelock from occurring.

To demonstrate how the number of states of the ASD specification can differ from the sizeof the state space, Figure 6.7 is a representation of the same system as shown in Figure 6.2, butdisplayed as a labelled transition system with only one event per transition. As can be seen, themodel with three states leads to a state space representation that has seven states. This showsthat the number of states the model has, is not entirely related to the size of the state space ofthe supervisor.

38 Example component: WH Clean

Listing 6.1: CIF specification of the synthesised supervisor automaton

supervisor automaton sup:alphabet WH_Clean.yes, WH_Clean.no, DataStore2.option, DataStore1.wafer;location:initial; marked;edge WH_Clean.no when true;edge WH_Clean.yes when true;edge DataStore1.wafer when WH_Clean.Response and R1.Reply2;edge DataStore2.option when

DataStore1.Operational and (WH_Clean.Response and R1.Reply1);end

no, yes

wafer whenWH Clean.Response ∧

R1.Reply2

option whenDataStore1.Operational ∧WH Clean.Response ∧

R1.Reply1

Figure 6.6: State space representation of the synthesised supervisor

clean

option

enabledwafer

False

yes

disabled

True

no

Figure 6.7: The state space representation of WH Clean.dm

7. Formal validation of the applicationof synthesis

In order to show that applying supervisory controller synthesis to the components of LOPWcan be useful for ASML, it must first be shown that it can at least be used to generate correctcomponents with the same behaviour as the existing components. Most importantly, that will en-sure that representing ASD interface models in CIF plants, and the formalisation of requirementsis done properly. The means to show this, are explained in this chapter.

In Section 7.1, the properties a verified ASD component satisfies should also hold for a synthes-ised supervisor. Then in Section 7.2, mCRL2, the verification language used for this research, isintroduced. The pre-processing steps required to be able to compare the existing design models tothe synthesised supervisors, are explained in Section 7.3. After that, several notions of equivalenceare described in Section 7.4 and a suitable choice for this research is made. Finally in Section 7.5,formal equivalence is checked between several supervisors that have been synthesised and theirALIAS counterpart.

7.1 Model verification

After a supervisor is generated, the controlled system must attain the same properties as theexisting design model does, listed in Section 2.5. In this section, all these properties and whetheror not they are satisfied, are discussed.

• The supervisor will be deterministic, because as given in [10], the synthesis algorithm doesnot allow non-determinism between controllable events.

• The controlled system should not contain modelling errors:

– The guards must be complete. Guards in CIF act different from guards in e.g. ASD.This is because in CIF, an event with a guard can only occur if the guard holds true.In ASD, the guard is checked after the event occurred and therefore, completenesssemantics tell us that all possibilities for a guard must be modelled. Because this is notnecessary in CIF, the guards do not have to be complete.

– Since CIF does not have completeness semantics, events that are illegal in specific statesare simply not modelled, instead of marked illegal. This automatically ensures thatillegal behaviour cannot occur.

– State variable ranges will not be violated, because the ranges of variables are specifiedin CIF. Events will be disabled whenever the transition would make a variable exceedits range.

– State invariants should not be violated. In ASD, state invariants can be used to indic-ate that a state variable is not allowed to have a specific value (specified in the stateinvariant) in that state. If it is able to attain that value in that state, the ASD verific-ation will throw an error. In CIF, state invariants can be added as requirements andtherefore, if these are modelled correctly, the state invariants are never violated.

– Every occurrence of a call event must be accompanied by exactly one matching replyevent, be it a void reply or a valued reply event. This requirement will be automaticallymet, because this behaviour is specified in the interface models, which are translatedto CIF.

39

40 Formal validation of the application of synthesis

• Because of the way notification automata are specified in CIF, notification queues will notoverflow. New notifications can only be added to the queue after another was removed.

• The supervisor must comply with the possible behaviour as specified in the interface models.Compliance of the supervisor with the interface models will always be achieved, because theinterface model of a component is used as a plant and the supervisor can only trigger ordisable events that satisfy the behaviour modelled in that IM. The component will alwaysbe a refinement of the interface model it complies with.

• The supervisor resulting from the synthesis algorithm will be deadlock-free and livelock-freeas a result of the synthesis algorithm.

7.2 mCRL2

mCRL2 [9] is a formal verification language and an associated toolset [6] developed at the de-partment of Mathematics and Computer Science of the Eindhoven University of Technology, incollaboration with The University of Twente and CWI (Center for Mathematics and ComputerScience). The toolset contains tools that support simulations, state-space explorations and othersystem behaviour analyses.

This toolset will be used to validate whether using supervisory controller synthesis can resultin components that behave the same way the existing LOPW models do. Jonk [13] has designeda transformation that was used to convert 126 ALIAS models into mCRL2 models. The ALIASmodels that are transformed, describe the same behaviour as their ASD counterparts and there-fore, these models can be very useful for this research. However, there are some steps that needto be performed on the mCRL2 models, before they can be used for this research. These areexplained in the next section of this chapter.

If the controllers obtained through synthesis are to be compared to the given mCRL2 models,the CIF models of supervisors have to be translated to mCRL2 as well. CIF has a built-in featurethat performs this translation after a pre-processing step. However, some CIF constructs are notsupported by this translation, even after the pre-processing step. Therefore, additional tasks needto be performed in order to obtain correct mCRL2 models. These are explained in Section 7.3.2.

Figure 7.1 positions the current work within the relevant technologies of ASML, and ASD.The ASD interface models are manually captured in CIF plants and requirements are specified.Synthesis is applied in order to obtain a supervisor, which is then translated to LTS via mCRL2.On the other side, the LOPW models have been translated to ALIAS models, which in turn havebeen transformed into labelled transition systems. Both sets of LTSs can be compared to oneanother to see if they are equivalent.

7.3 Pre-processing of the models

Before an equivalence check can be performed, some pre-processing steps are required. Somesteps are performed on the models obtained using the translation from ALIAS to mCRL2, whileother steps are performed on the CIF specifications obtained by applying supervisory controllersynthesis. Some steps are essential for the validation step: mCRL2 models need to be transformedinto Linear Process Specifications (LPSs) and those LPSs must be transformed into LabelledTransition Systems (LTSs). Both these steps are part of the mCRL2 toolset. If two modelsare in the LTS format, equivalence checks can be performed in order to formally validate thesynthesis procedure. In addition to these steps, some other steps have to be performed to facilitateequivalence checking. These are explained in the next subsections.

7.3. Pre-processing of the models 41

ASD Current work

ASML

IM DM

ALIAS

LTSEquivalence?

LTS

mCRL2

CIF plant CIF req.

Supervisor

mCRL2

Synthesis

Figure 7.1: Positioning the current work with respect to ASML and ASD technologies

7.3.1 Pre-processing ALIAS models

There are 126 ALIAS models of LOPW components available that can be used for validationof the component-wise supervisory controller synthesis applied to LOPW. After examining themodels obtained through the existing translation from ALIAS to mCRL2, some changes had to bemade to this translation and pre-processing actions have been performed on the resulting mCRL2models. These are explained below.

Elimination of certain events

In single-threaded execution models, only one process thread can be active at a time. However,the models resulting from the transformation from ALIAS to mCRL2, have a thread for the in-terface model and another for the design model active at the same time. In order to simulatethe single-threaded execution style of the models, locking events were introduced. Whenever acall comes in, an event lockQ is triggered as a dual action and after a reply was received (beit a valued or a void reply), the event unlockQ is triggered. Since this is only part of Jonk’simplementation of the single-threaded execution style and not present in ASD nor in ALIAS,these events can be eliminated from the mCRL2 specifications. This elimination step is visualisedin Figure 7.2 with on the left the existing set of actions and on the right, the reduced set of actions.

In addition to the locking events, there is another event that can be eliminated from the spe-cifications of Jonk’s mCRL2 models. During the transformation from ALIAS to mCRL2, an eventis introduced that is not specified in the ASD models. While in a synchronous return state (seeSection 2.2.1), the event valuedTrigger will be triggered after a valued reply, and before the actioncorresponding to that reply. In Figure 7.3, an example is given that shows where this event is intro-duced (left) and how it is specified in ASD (right). This event was introduced, because in ALIASa synchronous return state does not contain a trigger on its own while in ASD, it does. Since thistrigger is already present in the ASD model, the event can be eliminated from the mCRL2 models.

In order to eliminate the aforementioned events from the mCRL2 models, they have been re-named to internal/unobservable τ events using Python. After transforming to labelled transitionssystems, branching bisimilarity reduction can be applied to eliminate all τ events and correspond-ing states from the models while maintaining the rest of the behaviour. Elimination of theseevents is demonstrated in Figure 7.2. On the left, the system before elimination is shown and on


Call XlockQ

Action A

Reply A

unlockQ

Call X

Action A

Reply A

Figure 7.2: Example of a τ -reduction with on the right the reduced model

the right, the reduced system is displayed. A Python script has been written that turns the rightevents into τ events in the mCRL2 specification of every component. This Python script can befound in Listing B.2.

Elimination of anonymous event names

In the existing translation, call events from a client to the component were indistinguishable fromone another (all are named internalTrigger). This means that by looking at the specification,one cannot identify which client sent the call, or which call event it is. In other words, the callevents are anonymous. Therefore, the translation has been adjusted so that the original eventnames are maintained. The difference between the two is illustrated in Figure 7.4 with on theleft, a model with anonymous events (internalTrigger) and on the right, the corrected model withdistinguishable events.

Location of void replies

If multiple actions are listed in one rule case in ASD, they are performed in the order that they arespecified. However, VoidReply is an exception to this rule. Even if VoidReply is the first actionlisted in the rule case, it will be executed after all other actions have been performed in the orderin which they were specified. When Call A is triggered in the rule case of Table 7.1, Call B willbe triggered, then Do C and finally VoidReply.

Table 7.1: Example of a rule case in ASD with multiple actions

Current state Trigger Guard Actions Updates Target state

X1 Call A a > 0 VoidReply; Call B; Do C X2

In the translation from ALIAS to mCRL2, VoidReply was not treated as an exception to therule of action ordering. Therefore, VoidReply always followed the call directly, instead of at theend of the action sequence. This has led to a change in the translation. This is illustrated inFigure 7.5, with on the left the ordering of events that occurs in the mCRL2 model obtained by


Call X

OK

valuedTrigger

Response1

NOK

valuedTrigger

Response2

Call X

OKNOK

Response1 Response2

Figure 7.3: Example of event valuedTrigger (left) and how it is specified in ASD (right)

internalTrigger internalTrigger

C D

A B

C D

Figure 7.4: Elimination of anonymous call event names

using the existing translation from ALIAS to mCRL2, and on the right the ordering of eventsas specified in ASD. After the translation was changed, the ordering of events is as it is in ASD(Figure 7.5b).

Non-determinism

In Jonk’s work [13], non-determinism of the first type (shown in Figure 2.6a) is present in therepresentation of the design models after transforming from ALIAS to mCRL2, while the spe-cification of the design models in ASD must be deterministic. An example of non-determinism asfound in the mCRL2 specifications, can be seen in Figure 7.6a. The behaviour as specified in theASD design model is shown in Figure 7.6b. In these figures, Call is a service invocation from thecomponent to one of its used components and OK and NOK are the uncontrollable responses.

In this research, the interface models are modelled as plants without the first form of non-determinism (Section 2.2.2) in them, because the synthesis algorithm does not accept that type ofnon-determinism between controllable events. Therefore, the supervisors resulting from synthesis,


A B C

Call B

Call C

Reply C

VoidReply

Call A

VoidReply

(a) Resulting from translation from ALIAS to mCRL2

A B C

Call B

Call C

Reply C

VoidReply

Call A

VoidReply

(b) As defined in ASD

Figure 7.5: Message sequence charts explaining the correct and incorrect ordering of void replies

Call Call

OK NOK

(a) Non-determinism

Call

OK NOK

(b) Determinism

Figure 7.6: Non-deterministic behaviour and its deterministic counterpart

will be deterministic. When comparing a deterministic system to a non-deterministic one, traceequivalence (see Section 7.4) is the strongest form of equivalence that can be achieved.

By determinising the mCRL2 models obtained through translation of ALIAS models, behaviouras in Figure 7.6b is obtained. Doing so will allow strong bisimilarity to be the strongest notionof equivalence that can be achieved. The models can be determinised when they are in the LTSformat. All these pre-processing steps are illustrated by means of an example in Appendix A.

Event renaming

Jonk’s mCRL2 models contain event names with parentheses in them, to indicate what kind ofevent they are. These parentheses occur in the names of all reply events and events regardingnotifications. Some examples of these event names are: sendReply(MachineStore TRUE)and triggerNotification(UnloadReticle unload finished cb). These event namesare troublesome for comparison, as parentheses are not allowed in the event names in CIF spe-cifications. Fortunately, mCRL2 supports applying renaming files to LPSs that rename specific


events while maintaining the structure of the system. Renaming files have been generated usingPython to rename the events to something that does not contain parentheses. The Python scriptcan be found in Listing B.3 in the appendix. The generated renaming files have been applied tothe LPS models. An example of a renaming file is as follows:

Listing 7.1: Example of a renaming file

act % Defining the new actionsA_REPLY1;B_REPLY1;B_NOTIFICATION1;

5 rename % Renaming the desired eventsoutwardReply(A_REPLY1) => A_REPLY1;sendReply(B_REPLY1) => B_REPLY1;raiseNotification(B_NOTIFICATION1) => B_NOTIFICATION1;triggerNotification(B_NOTIFICATION1) => trigger_B_NOTIFICATION1;

10 outwardNotification(C_NOTIFICATION) => C_NOTIFICATION;

Because of the asynchrony of notifications, the same notification is first raised by a used inter-face (raiseNotification) and then triggered by the component itself (triggerNotification).Therefore, these events must be distinguishable from one another after renaming the events in themCRL2 models. That is why after renaming, the notification trigger event name is preceded bytrigger . In the next section, the pre-processing steps performed on the synthesised supervisors,are described.

7.3.2 Pre-processing CIF supervisors

The CIF specifications of systems controlled by synthesised supervisors, must be transformed intolabelled transition systems before their correctness can be validated. In order to do this, the CIFmodels must be transformed into mCRL2 models. In turn, those models are transformed intoLPSs and finally into LTSs.

Unfortunately, the CIF tooling that converts CIF specifications into mCRL2 specifications,does not support all models. For this research, the following restrictions are of importance:

• Supervisory automata are ignored (automata of type supervisor and monitor).

• Invariants are not supported.

• Location/state references are not supported (used in requirement invariants).

However, monitors are eliminated by the tooling during the transformation step. This leavesthe invariants and location references as issues. These issues can be resolved by applying CIF toCIF transformations before transforming to mCRL2. The transformation elim-locs-in-exprseliminates location references in expressions and the elim-state-evt-excl-invs transform-ation eliminates state/event exclusion invariants. After applying these transformations, the CIFspecification can be transformed into an mCRL2 specification. Unfortunately, applying the CIFto CIF transformations (to eliminate certain CIF constructs) can lead to mCRL2 models withundesired behaviour, even if the transformed CIF specification displays the desired behaviour.The transformations introduce self-loops and other events that are not part of the behaviour asmodelled in the CIF specification. A tooldef has been used that helps to eliminate these self-loopsfrom the mCRL2 model, again resulting in the desired behaviour.

After the CIF models of the supervisors have been successfully transformed to mCRL2, theycan be transformed into Linear Process Specifications. In order to achieve any form of equivalence,the event labels must be the same for both models. That is why action renaming is applied to theLPS. This will ensure that the synthesised supervisor will have the same event names as the pre-processed mCRL2 models Jonk provided do. The LPS with renamed actions is then transformedinto a labelled transition system that can be used for equivalence checking.


7.4 Behavioural equivalence

After the aforementioned pre-processing steps have been performed correctly, a model-to-modelcomparison can be performed to check whether the models exhibit the same behaviour. However,there are many notions of equivalence that can be achieved, one much stronger than another. Forthis research, a suitable choice must be made. A number of equivalence checks can be appliedin mCRL2. The most prevalent forms of equivalence that can be checked for in mCRL2, aredescribed below, where for the formal definition, we refer to [9].

• Trace equivalenceTwo labelled transition systems are trace equivalent if and only if they can perform the samesequences of actions starting from their respective initial states. However, this might leadto false positives on behavioural equivalence, as is shown in the example of Figure 7.7 whichshows two sets of trace equivalent systems that are quite different.

• Weak trace equivalenceWeak trace equivalence is very similar to regular trace equivalence, but there is a slightdifference between the two. When checking for equivalence, weak trace equivalence skips τactions that are present on the traces. These τ actions are also called internal or unobservableactions and can be considered quiet or unnamed. When present on the traces of one of thetwo systems, the systems cannot be trace equivalent, but can be weakly trace equivalent.

• Strong bisimulation equivalenceStrong bisimulation equivalence is a more strict notion of equivalence than trace equivalence.When two systems are strongly bisimulation equivalent, they cannot be distinguished bynormal behavioural observations. It is an attractive equivalence, because the algorithms forchecking bisimulation equivalence are efficient. Two states of different systems are relatedif all actions that can be performed in one state, can also be performed in the other. It issaid that the second state simulates the first state. The resulting states after these actions,must be related in this way as well. If the initial state of both systems possess this property(implying all following states do as well), the labelled transition systems are said to bestrongly bisimilar. Systems can be trace equivalent and not bisimilar at the same time. InFigure 7.8, two bisimulation equivalent systems are shown that do have different behaviour.

• Weak bisimulation equivalenceSimilar to weak trace equivalence, weak bisimulation ignores τ events when checking forequivalence. Weak bisimulation equivalence can still be achieved when τ events are presentin one labelled transition system, and absent in another.

• Branching bisimilarityThis definition of equivalence is much like that of strong bisimulation. The difference is thatfor branching bisimulation, instead of a single action simulating a single action, an actioncan be simulated by a sequence of internal actions (τ), followed by that single action. Anexample of a pair of LTSs that are branching bisimilar but not strongly bisimilar, is shown inFigure 7.9. Branching bisimilarity is weaker than strong bisimilarity, meaning that any pairof LTSs that is strongly bisimilar, will also be branching bisimilar. The converse does notalways hold. On the other hand, it is stronger than weak bisimilation, since the branchingstructure is maintained for branching bisimilarity.

• IsomorphismIn process theory, isomorphism is a very strong form of equivalence, because if two labelledtransition systems are isomorphic, their structure is exactly the same. Isomorphic LTSs areonly allowed to differ from each other in the labels of their states.

It must be noted that any deterministic system that is trace equivalent to another deterministicsystem, will always be strongly bisimulation equivalent as well. Similarly, any pair of deterministic

7.5. Proving equivalence 47

aaa

a a

b c b

a

b c

Figure 7.7: Two pairs of trace equivalent systems

a a

b b

a

b b

Figure 7.8: Two bisimulation equivalent systems

systems that is strongly bisimulation equivalent, is also trace equivalent.

For this project, it is important to decide upon a notion of equivalence that is desired to beachieved, that suits the needs of ASML. Both sets of mCRL2 models were obtained through verydifferent routes and therefore, the form of equivalence should allow some freedom between the twosystems. On the other hand, it should not be too loose, because that could result in undesireddifferences that go unnoticed. For this reason, trace equivalence is not the equivalence definitionof choice. As can be seen in Figure 7.7, trace equivalent systems can still be quite different fromeach other. Strong bisimilarity and isomorphism are considered to be too strict, because τ eventsare introduced during the pre-processing steps and these should not prevent an equivalence checkfrom returning a positive reply. Therefore, branching bisimilarity will be used to test if two modelsare equivalent. This notion is slightly stronger than weak bisimilarity, but still allows τ events tobe present. In addition to weak bisimilarity, it also preserves the branching structure of the model.

7.5 Proving equivalence

Out of the 126 given design models that were transformed from ALIAS to mCRL2, seven wereused for formal equivalence checking. These components are chosen either because they werequite simple, or because they were deemed difficult to model by an ASML engineer while stillmaintaining a manageable size. The simpler components were used to develop and test the meth-ods for modelling plants and requirements in CIF. The other components were used to examinehow synthesis would be applied to more complex components. For all seven of these components,branching bisimilarity has been proven to exist between the synthesised supervisors and the designmodels that were transformed via ALIAS to mCRL2.


τ a

a b

bτ

ba

Figure 7.9: Two branching bisimilar labelled transition systems

This shows that it is possible to use supervisory controller synthesis to obtain supervisors thatbehave as the existing design models do. It can be concluded that the our CIF plant automata incombination with the extracted and formalised requirements are correct, at least for these sevencomponents. Again, it must be stressed that the main goal when applying synthesis is to obtain asupervisor that satisfies certain informal requirements and that formal equivalence will not alwaysbe achieved in that case.

In the next chapter, the scalability of the methods designed during this research, is examined.The seven components investigated here are relatively small in terms of their specification. Thequestion is whether supervisors can still be synthesised for larger components, and what can bedone to alleviate possible scalability issues.

8. Scalability of supervisory controller syn-thesis

Scalability is generally an issue for supervisory controller synthesis. For small use cases, su-pervisors are generated in an instant, but for industrial cases such as LOPW, this might not beso easy. The number of states of the supervisor will explode and the synthesis algorithm will berunning for hours, perhaps days, or, more likely, the system will run out of memory. Obviously,that would not be an efficient way to obtain a supervisor, as small changes will result in havingto synthesise the entire supervisor again, if a supervisor can be synthesised at all. Fortunately,LOPW is constructed from a large number of components, which makes each individual compon-ent much smaller. This alleviates a lot of the problems with scalability, but some might still occur.The scalability of component-wise supervisory controller synthesis is examined in Section 8.1 andpossible solutions to problems related to it, are proposed in Section 8.2.

8.1 Scalability of component-wise synthesis on LOPW

Because LOPW consists of many components, each individual component will not by far be ascomplex as the whole system. That is why for most components, scalability will not be an issuewhen applying component-wise synthesis on the components of LOPW. In order to assess whatscalability problems do occur, multiple steps can be taken:

1. See if synthesis can successfully be applied within a reasonable amount of time (severalminutes) for one or two of the most complex components of LOPW.

2. Find a way to predict with a reasonable amount of certainty, how long and how muchmemory it will take to synthesise a supervisor for complex components. This prediction willbe based on the supervisor computation time and memory usage for smaller, less complexcomponents.

3. Apply synthesis to all components of LOPW.

The first option means that a component with many states must be chosen. As explained inChapter 6, the number of states in the ASD specification is not necessarily a good representationof the complexity of the system. The size of the state space might be a more effective way of tellingwhich components are the most likely to take the most time or memory to compute a supervisorfor. The models obtained through the translation from ALIAS to mCRL2 can be used for thispurpose, because these include complex components. Several metrics have been calculated forthe 126 given components and the components with the largest state space have been identified.Because of their relatively large amount of state variables, these are armouring components. Eventhough they only have a limited number of states (three or less), the generated state space sizeis very large, over ten thousand. However, these numbers give the size of the state space of thesupervisor, and not of the possible state space. If the possible state space is taken into account,these numbers can increase severely, because all combinations of all states and variables must beconsidered. For example, consider a system with three plants and two requirement automata, eachwith four states in them. This will result in a possible state space size of 43+2 = 1024. On themachine provided by ASML, synthesis fails due to memory shortage for components with about1e15 or more different possible states. However, by using a system with more memory, supervisorscan be synthesised for larger components. More research will have to be conducted to be ableto draw accurate conclusions on what part of LOPW components is too complex for supervisory

49

50 Scalability of supervisory controller synthesis

controller synthesis to be applied as is.

Option 2 insists that a data set is created that helps to predict the synthesis time or memoryusage for more complex components. Synthesis will have to be applied to multiple componentsof LOPW and a relation must be found between some variable and the synthesis time/memory.This variable can be related to the ASD specification, the resulting state space or the possiblestate space size. However, the problem with this approach is that without being able to checkthe predictions on complex components, they might be very inaccurate for larger components ofLOPW. A trend can be observed for simple to average components, while it does not hold at allfor complex components with much more behaviour. In order to overcome this, several complexcomponents will have to be examined. Another problem is that for small components, the syn-thesis time and memory usage can be greatly influenced by effects such as computational powerfluctuations and coding style, which would result in unreliable predictions. Finally, the synthesistime might not be a reliable property for a component, as running out of memory is usually thething preventing a supervisor from being obtained, not the time.

A problem the first two options have in common (should they yield acceptable results) is thatthere can always be outliers that take a very long time or an incredible amount of memory toperform synthesis on. Even if a very large and complex supervisor can be synthesised with ease,there is no guarantee that it will work on a different, equally complex component. The same holdsfor the second approach, where outliers could occur that do not follow the predictions at all. Thefinal option would circumvent this issue, because synthesis would be performed on all individualcomponents of LOPW to see if any issues with synthesis occur. However, should scalability trulybe an important issue, one would like to know beforehand and act accordingly, instead of afterhaving applied synthesis on many components first.

The first two options have been combined and the synthesis time and memory usage whenperforming synthesis have been logged and relations between them and properties like size of theASD specification, state space size of the resulting supervisor and state space size of the CIFspecification (plants and requirements), were sought for the components to which synthesis hasbeen applied. The peak memory usage during synthesis (minus the steady level of memory usage)and the synthesis time have been plotted against the state space size of the resulting supervisorin Figure 8.1. In Figure 8.2, the same metrics have been plotted against the possible state spacesize.

In Figure 8.1, it can be observed that there is no clear relation between the size of the statespace of the synthesised supervisor and the peak memory or time used during synthesis. Figure8.2a shows that there is also no clearly observable relation between the memory usage and thepossible state space size. Finally, when looking at the time it takes for the main synthesis loop tocomplete its task and its relation to the possible state space size (Figure 8.2b), a linear relationcan be observed with quite large uncertainty bounds. However, because any prediction based onthe given data is so uncertain and because memory usage is expected to be the bottleneck for thismethod and not synthesis time, this data cannot be used to draw conclusions on the scalability ofthe methods developed in this research.

In the next section, possible actions to undertake when scalability issues do occur, are discussed.

8.2 Remedies for scalability issues

During this research, it was discovered that the state space size of a component can be severelydecreased by changing the way requirements are specified. First of all, using requirement invariantsinstead of requirement automata can be of service against large state spaces. The following example

8.2. Remedies for scalability issues 51

(a) (b)

Figure 8.1: Memory usage and synthesis time plotted against the state space size of the supervisor

demonstrates this:

Example 8.2.1: Suppose there are three components (A, B and C), each of which is onlyallowed to be called when all others are inactive (Idle) at the time. In order to capture thesemonitor semantics in a requirement, an automaton can be used in the following way:

requirement R_MonitorSemantics:location Operational: initial; marked;

edge A.Call, B.Call, C.Call goto Busy;location Busy:

edge A.Reply, B.Reply, C.Reply goto Operational;end

Because of this requirement, A.Call, B.Call and C.Call will be disabled when one of thecomponents is busy processing a call. However, this requirement introduces two states, effectivelydoubling the maximum state space size of the specification. By writing this requirement as aninvariant, no states are added:

requirement not A.Idle or not B.Idle or not C.Idle disables {A.Call, B.Call, C.Call};

Another way to greatly reduce the state space size is to combine multiple plant automata thatdo not represent ASD interface models into one automaton. These automata can be requirementautomata or plant automata representing notification queues. The following example illustrateshow this can be useful:

Example 8.2.2: Consider three very similar requirements on event ordering that act on thesame component :

• If A occurs, trigger X.

• If B occurs, trigger Y.

• If C occurs, trigger Z.

These requirements can be modelled by the automata shown in Figure 8.3a. However, by combin-ing their initial states into the same state, the combined requirement automaton of Figure 8.3bis obtained. This will implement the exact same behaviour, only with fewer states. Where the

52 Scalability of supervisory controller synthesis

(a) (b)

Figure 8.2: Memory usage and synthesis time plotted against the possible state space size

individual automata have a combined state space of 23 = 8, the combined one will only have fourstates.

This strategy can be used to reduce the state space size from 2n (assuming the individualautomata have two states), where n is the number of automata, to n + 1. For instance, for tenautomata, the state space size can be reduced from 210 = 1024 to 11. Due to going from anexponential relation to a linear one, the relative reduction that can be achieved becomes largeras the number of similar automata increases. This means that for larger components, applyingthis technique is more effective in reducing the state space than it is for smaller components withfewer of the same automata. It must be stressed that great caution is advised when applying thisreduction, as it can not be applied in all cases. This method can only be correctly applied if thecall events (A, B and C) are only enabled in the initial states of each automaton. Additionally,the relation between the informal requirements and the formalised requirements, will become lessclear after combining multiple requirement automata into one.

By applying both these techniques on the specification of plants and requirements for one ofLOPW’s largest components, the total size of the state space has been reduced from 3.3 · 1025 to1.5 ·1011. Where synthesis failed for the larger state space due to a memory shortage, a supervisorwas generated in under five seconds for the specification with decreased state space size. Evid-ently, the way requirements are specified, makes a great difference when it comes to the memoryand time it takes for the synthesis algorithm to be applied. More optimal ways of specifyingrequirements that could potentially increase the set of LOPW components on which synthesis canbe successfully applied, might remain undiscovered. That is why more research is required on thesubject.

CIF provides several options for its data-based synthesis algorithm that can potentially im-prove performance severely. One of these settings ensures the state space is represented usingBinary Decision Diagrams (BDDs) [5], which can greatly reduce the computational effort it takesto synthesise a supervisor, especially for larger and more complex components. Since the effectthe other settings have on performance, is quite case specific, we refer to [10] for more information,and not elaborate on them here.

8.2. Remedies for scalability issues 53

A

X

B,C

B

Y

A,C

C

Z

A,B

(a) Three requirement automata

A

X

BY

C

Z

(b) Combined requirement automaton

Figure 8.3: State space reduction by combining automata

If scalability is still an issue after applying these reductions and adjusting synthesis settings,different synthesis algorithms might be explored. In order to reduce the size of the state space ofsynthesised supervisors, abstraction [24] or a symbolic representation [17] might be used. Further-more, problems with computational power can be mitigated by identifying an appropriate subsetof the plants to perform synthesis on (modular synthesis [1]). The idea behind this is to graduallyincrease the set of plants and uncontrollable events considered during synthesis. It is currentlyunknown how well these algorithms can be applied to the components of LOPW and to whatextent they may reduce the computational effort synthesising a supervisor takes. Furthermore,these forms of synthesis are not integrated into CIF and will have to be modelled separately.

9. Conclusions and recommendations

In this chapter, the conclusions that are drawn from this research are listed and based on that,recommendations for future research are given.

9.1 Conclusions

In this thesis, component-wise supervisory controller synthesis on existing models has been ex-amined. Its applicability on LOPW, the supervisor in charge of processing wafers through a waferscanner, was assessed. To this end, ASD, the modelling technology used to model LOPW, andLOPW itself, were explained. After that, Supervisory Control Theory (SCT) was introduced as atheory for synthesising correct-by-construction supervisors based on plant and requirement models.Methods have been developed for applying SCT to the components of LOPW and these meth-ods have been put to the test by synthesising supervisors for multiple components and showingthat the resulting controlled systems show behaviour equal to that of the existing design models.Finally, scalability of the synthesis procedure has been investigated and methods for alleviatingpossible issues related to scaling, were applied.

By proving that equivalence can be achieved between the existing design models and the syn-thesised supervisors, it was shown that SCT can be used to obtain supervisors that satisfy therequirements listed in the LOPW design documentation. However, many requirements neededto be added to the specification in order to achieve equivalence. This implies that the LOPWdesign documentation can be expanded by adding requirements domain experts deem correct.Furthermore, a number of requirements was added to retain the hierarchical structure and theASD semantics. It can be argued that at least some of the requirements introduced to retain ASDsemantics, can be left out of the specification if equivalence is not the goal. Doing so will resultin supervisors that are less restrictive than the existing design models are. Nevertheless, it wasshown that the controllers of LOPW can be generated by using supervisory controller synthesis.The main advantage of that is that the controllers no longer have to be constructed manually,making the controllers less prone to containing errors. Additionally, the specification will be moreclosely related to the informal requirements listed in the design documentation. This could facil-itate applying changes in the requirements to the models of LOPW. However, no conclusion canbe drawn on this as of yet.

To be able to design LOPW, it has been divided into many, smaller components, each ofwhich is currently manually designed and implemented. This division is very convenient as theabstractions of all components (represented by the interface models) can be used straight away,without having to restructure them. Moreover, it alleviates scalability problems and allows for aclear overview of how LOPW works. However, some scalability issues were still encountered forlarge components of LOPW. These were examined and remedies for these issues were developedand successfully applied. There might be more ways to reduce the time and memory the synthesisalgorithm takes. These will have to be investigated in the future.

During this research, it was discovered that there are many ways to define a requirement, bothinformally, and in the implementation. The way these requirements are defined, greatly influencesthe relation between the requirements and the behaviour of the resulting controlled system, andthe performance. For consistency purposes, it would be wise to maintain a uniform style for de-fining informal requirements. These can then be consistently formalised as well, leading to moreunderstandable specifications.

55

56 Conclusions and recommendations

It can be concluded that using supervisory controller synthesis is a viable alternative to auto-matically create LOPW components from formal requirement specifications. By using the divisioninto components that is currently present and adding requirements to that, supervisors can beobtained that behave as desired. Several of these requirements can be modelled in a reusable wayso that new components may be easier to create. However, before it can be applied, more researchis required on several subjects. Recommendations for future work are given in the next section.

9.2 Recommendations for future research

The goal of this research was to determine the applicability of component-wise supervisory con-troller synthesis on LOPW. After determining that supervisors can be generated that are formallyequivalent to the existing components, it is important to examine the possible advantages and dis-advantages of using synthesis. One of these advantages could be that by using synthesis, changesto the existing components can be made with greater ease. Partly because of reusability of re-quirements and partly because of a closer relation between the informal requirements and theirimplementation. This can be examined empirically by looking at certain components that havechanged relatively often in the past. A comparison can be made between how the changes areapplied manually and how they would be applied using synthesis. Of course the work needed de-pends greatly on the knowledge on and the experience with either method. Still, researching thisshould give some insight into the effect this has on the changes made to the existing components.

For engineers to formally capture requirements, different ways and forms of requirement mustbe examined and assessed and after that, a survey among designers could be conducted to findout how the requirements can best be specified.

In addition to the advantages, the disadvantages of synthesis must be examined. As explainedin Chapter 8, scalability might be a problem for supervisory controller synthesis. Memory issueswere encountered for larger components of LOPW. In the future, the scalability of the developedmethods could be investigated more closely by trying to synthesise a supervisor for large com-ponents and seeing how different ways of implementing requirements affects the performance ofthe algorithm. Furthermore, it was found that the hardware on which the synthesis algorithm isstarted, can influence its performance as well. Therefore, it might be interesting what is left ofthese issues when synthesising on a more powerful machine. Finally, different synthesis algorithms(introduced in Section 8.2) can be investigated to see how scalability of the procedure might befurther improved.

In order to prevent using the existing design model as a requirement, domain knowledge isrequired to distinguish actual requirements from behaviour that is added because of ASD’s re-strictions or other sources. As stated before, the LOPW design documentation can be expandedby the requirements that are implemented in the design models. Since it will then be much clearerwhat each component should do, the application of synthesis to the components of LOPW willbecome easier.

10. Reference list

[1] K. Akesson, H. Flordal, and M. Fabian. Exploiting modularity for synthesis and verificationof supervisors. 15th IFAC World Congress on Automatic Control, 2004.

[2] Marco Alonso. Introducing ALIAS. In Confidential ASML presentation introducing ALIAS,2015. Accessed on 20-01-2017.

[3] M. Borm. Timing analysis of the logistics controller of an ASML wafer scanner. EindhovenUniversity of Technology, 11 2014. Internship report.

[4] G.H. Broadfoot and P.J. Hopcroft. Analytical Software Design, 2003.

[5] R. Bryant. Symbolic Boolean manipulation with ordered binary decision diagrams. ACMComputing Surveys, 1992.

[6] S. Cranen, J.F. Groote, A Keiren J, J, F.P.M. Stappers, E.P. de Vink, J. W. Wesselink, andT.A.C. Willemse. An Overview of the mCRL2 Toolset and Its Recent Advances. TACAS,2013.

[7] L. Feng, K. Cai, and W.M. Wonham. A structural approach to the non-blocking supervisorycontrol of discrete-event systems. International Journal of Advanced Manufacturing Techno-logy, 2008.

[8] Python Software Foundation. Python official website. https://www.python.org/. Ac-cessed on 07-02-2017.

[9] J.F. Groote and M.R. Mousavi. Modeling and analysis of communicating systems. The MITpress, 2014.

[10] D. Hendriks. CIF website. http://cif.se.wtb.tue.nl/index.html. Accessed on12-09-2017.

[11] T.M.W. Janssen. Design of the supervisory control layer for electron microscopes. Master’sthesis, Eindhoven University of Technology, 12 2012.

[12] T.M.W. Janssen, J.M. van de Mortel-Fronczak, M.J.A.M. van Gerwen, and M.A. Reniers.Synthesis of Discrete-Event Controllers from Sequence-Based Specifications. Conference onDecision and Control, 2015.

[13] R.J.W. Jonk. The semantics of ALIAS defined in mCRL2. Master’s thesis, Eindhoven Uni-versity of Technology, 8 2016.

[14] R.J. Leduc, B.A. Brandin, W.M. Wonham, and M. Lawford. Hierarchical Interface-basedSupervisory Control: Serial Case. 40th IEEE Conference on Decision and Control, 2001.

[15] A. MacCormack, J. Rusnak, and C.Y. Baldwin. The Impact of Component Modularity onDesign Evolution: Evidence from the Software Industry. Harvard Business School, 12 2007.

[16] J.W.M. Michels. Supervisory Control of ASML Wafer Scanners. Master’s thesis, EindhovenUniversity of Technology, 11 2012.

[17] S. Miremadi, K. Akesson, and B. Lennartson. Symbolic computation of reduced guards insupervisory control, volume 8. IEEE Transactions on Automation Science and Engineering,2011.

57

https://www.python.org/

http://cif.se.wtb.tue.nl/index.html

58 Reference list

[18] L. Ouedraogo, R. Kumar, R. Malik, and K. Akesson. Nonblocking and Safe Control ofDiscrete-Event Systems Modeled as Extended Finite Automata, volume 8. IEEE Transac-tions on Automation Science and Engineering, 3rd edition, 2011. Pages 560-569.

[19] P.J. Ramadge and W.M. Wonham. Supervisory control of a class of discrete event systems,volume 25. SIAM Journal on Control and Optimization, 1987.

[20] M.A. Reniers and J.M. van de Mortel-Fronczak. Model-Based Systems Engineering. Eind-hoven University of Technology, 2015. Lecture notes.

[21] E.R. Sahagun. Translation of ASD Single-threaded Execution Models to EFSM. EindhovenUniversity of Technology, 8 2014. Internship report.

[22] E.R Sahagun. Specification of Timed Service Contracts in Component Based Architectures.Master’s thesis, Eindhoven University of Technology, 6 2015.

[23] M.J. Starke. Supervisory control using extended finite automata for ASML wafer scanners.Master’s thesis, Eindhoven University of Technology, 3 2013.

[24] M. Teixeira, R. Malik, J.E.R. Cury, and M.H. de Queiroz. Supervisory control of DES withextended finite-state machines and variable abstraction, volume 60. IEEE Transactions onAutomatic Control, 2015.

[25] M.H. ter Beek, M.A. Reniers, and E.P. de Vink. Supervisory Controller Synthesis for ProductLines using CIF3. Eindhoven University of Technology, 2016. ISoLA conference.

[26] I. ter Horst and S. Weber. EPDS LOPW. ASML, 2016. Confidential design specificationdocument for LOPW.

[27] Uppsala Universitet and Aalborg University. UPPAAL website. www.uppaal.org.

[28] Verum. ASD Runtime Guide. http://community.verum.com/documentation/runtime_guide.aspx/9.2.7/asd_execution_semantics/singlethreaded_execution_model/singlethreaded_semantics#_Ref263258255. Accessed on15-07-2017.

[29] Verum. ASD:Suite User Manual. http://community.verum.com/Files/ASD_Suite_User_Manual/ASD_Suite_Release_4_v9.2.7_User_Manual.pdf, 2014. Release 4 v9.2.7.

[30] F.J.W. Zeelen. Supervisory machine control of ASML wafer scanners. Master’s thesis, Eind-hoven University of Technology, 11 2007.

www.uppaal.org

http://community.verum.com/documentation/runtime_guide.aspx/9.2.7/asd_execution_semantics/singlethreaded_execution_model/singlethreaded_semantics#_Ref263258255



http://community.verum.com/Files/ASD_Suite_User_Manual/ASD_Suite_Release_4_v9.2.7_User_Manual.pdf

http://community.verum.com/Files/ASD_Suite_User_Manual/ASD_Suite_Release_4_v9.2.7_User_Manual.pdf

A. Pre-processing steps mCRL2 models

In this appendix, the pre-processing steps that are performed on the mCRL2 models for themto be compared to the synthesised supervisors, are illustrated by means of an example. The reasonsfor these steps to be taken, are described in Section 7.3.1. It must be noted that (un)controllabilityis not indicated in this appendix.

Consider a simple component with two different incoming calls. After one of the calls (X ),a used component is requested by triggering Call A, which responds with either True or False.In case True is received, the component will respond to its client with NOK. In case False isreceived, OK will be the response to the component’s client. If the other of the calls (Y ) isreceived, another service will be invoked by triggering Call B, whose response will only be a voidreply. If the component described here would be modelled in ASD, translated to ALIAS and thento mCRL2, the state space representation would look like the one shown in Figure A.1. As can beseen in the figure, there are quite some events present that are not part of the behaviour describedabove. Therefore, several pre-processing steps will be applied to it:

1. The first pre-processing step is transforming certain events into internal or unobservable τevents. These events are unlockQ, lockQ and valuedTrigger. By doing this, the state spacerepresentation of Figure A.2 will be obtained. In order to increase the readability of thisrepresentation, the τ events are eliminated from it, leaving us with a system as shown inFigure A.3.

2. The anonymous client call events are then made distinguishable by using their original namesX and Y, which results in Figure A.4.

3. After that, the void reply to the client call is placed after the void reply from the usedcomponent, which leads to the state space representation of Figure A.5.

4. The final pre-processing step is making the model deterministic, as explained in Chapter 7.

The state space representation of the fully pre-processed component is shown in Figure A.6. Ifsupervisory control synthesis would be applied to the component described above, strong bisim-ulation equivalence can be achieved between the synthesised supervisor and the model shown inFigure A.6. However, if the internal events were not eliminated from the specification, but left asτ events, branching bisimulation is the strongest notion of equivalence to be achieved.

59

60 Pre-processing steps mCRL2 models

internalTriggerlockQ

Call ACall A

False

unlockQ

lockQvaluedTrigger

NOK

unlockQ

True

unlockQ

lockQvaluedTrigger

OK

unlockQ

internalTriggerlockQ

VoidReplyY

Call B

VoidReplyB

unlockQ

Figure A.1: Example component before pre-processing steps

61

internalTrigger

Call ACall A

False

τ

τ

NOK

τ

True

τ

τ

OK

τ

internalTrigger

VoidReplyY

Call B

VoidReplyB

τ

Figure A.2: Example component after turning certain events into internal ones


internalTrigger

Call ACall A

False

NOK

True

OK

internalTrigger

VoidReplyYCall B

VoidReplyB

Figure A.3: Example component after turning certain events into internal ones, with eliminatedinternal events

X

Call ACall A

False

NOK

True

OK

Y

VoidReplyYCall B

VoidReplyB

Figure A.4: Example component after turning certain events into internal ones, with eliminatedinternal events and distinguishable client call events

63

X

Call ACall A

False

NOK

True

OK

Y

Call BVoidReplyB

VoidReplyY

Figure A.5: Example component after turning certain events into internal ones, with eliminatedinternal events, distinguishable client call events and improved void reply ordering

X

Call A False

NOK

True

OK

Y

Call BVoidReplyB

VoidReplyY

Figure A.6: Example component after turning certain events into internal ones, with eliminatedinternal events, distinguishable client call events and improved void reply ordering made de-terministic

B. Python scripts

Listing B.1: Python script used to examine the complexity of all components of LOPW

items = 7 # number of properties calculated# Returns the number of states and events for the given design modeldef count_string_occurence_DM(path):

f = open(path)5 data = f.read()

f.close()model_name = os.path.basename(path)[:-3] # Stores only the name of the model# Again finding the number of occurences of every string (but more now) in XML filestates = data.count("<State ID=") # states

10 events = data.count("Event ID=") # eventsstate_vars = data.count("<StateVariable ID=") # state variablesdat_vars = data.count("<DataVariable ID=") # data variablessub_machines = data.count("<SubMachine ID=") # sub machines

15 return (model_name, states, events, state_vars, dat_vars, sub_machines)

matrix_DM = [[0]*(items)]*DM_count # Creating an empty matrixcount = 0

20 # Examine all design models in the (sub-)directory and store in a matriximport osfor subdir, dirs, files in os.walk("."):

for filename in files:filepath = subdir + os.sep + filename

25 if filepath.endswith(".dm"):matrix_DM[count] = count_string_occurence_DM(filepath)count = count + 1

# Printing the column identifiers and the matrix with all DM data30 print "Model;Rule cases;Events;State Variables; Data variables; Sub machines"

for x in matrix_DM:print ";".join(str(e) for e in x)

Listing B.2: Python script used to turn queueing events into τ events in Jonk’s mCRL2 models

def rename_Q(filepath):TextToSearch1 = "init allow "TextToReplace1 = "init hide ({unlockQ, internalTrigger, lockQ}, allow "TextToSearch2 = " ;"

5 TextToReplace2 = " ) ;"SplitString = "hide ({"

with open(filepath, ’r’) as file:filedata = file.read() # Store file in a string

10 if "init hide ({" in filedata: # Only do it if not done beforepass

else:filedata = filedata.replace(TextToSearch1, TextToReplace1) # Insert hiding of eventsfiledata1 = filedata.split(SplitString,1)[0] # Split it up

15 filedata2 = filedata.split(SplitString,1)[1] # To only change file after the splitfiledata2 = filedata2.replace(TextToSearch2, TextToReplace2) # Insert )filedata = filedata1 + SplitString + filedata2 # Recombine stringswith open(filepath, ’w’) as file:

file.write(filedata) # Write new string to old file20

import osfor subdir, dirs, files in os.walk(’.’): # Loop over all .dm files in current directory

65

66 Python scripts

for file in files:filepath = subdir + os.sep + file

25 if filepath.endswith(".dm.singlethreaded.mcrl2"):rename_Q(filepath)

Listing B.3: Python script used to generate renaming files that remove parentheses

def generate_renaming(filepath):with open(filepath, ’r’) as file:filedata = file.read() # Store file in a string

the_file = "act \n" # To define new action names5 # Store notificaiton and reply events in two lists

string1 = filedata.split("sort Notification = struct ",1)[1]stringNots = string1.split(" ; sort Enumeration = struct ",1)[0]string2 = string1.split(" ; sort Enumeration = struct ",1)[1]stringEnums = string2.split(" ; act",1)[0]

10 Notifications = stringNots.split(" | ")Enumerations = stringEnums.split(" | ")

# Adding the action names one by onefor idx, val in enumerate(Notifications):

15 the_file = the_file + " " + Notifications[idx] + ";\n"the_file = the_file + " trigger_" + Notifications[idx] + ";\n"

for idx, val in enumerate(Enumerations):the_file = the_file + " " + Enumerations[idx] + ";\n"

# Renaming specifications (with separation between notifications and replies)20 the_file = the_file+"rename \n"

for idx, val in enumerate(Notifications):the_file = (the_file + " " + "raiseNotification("+ Notifications[idx] + ") => " + Notifications[idx] + ";\n")the_file = (the_file + " " + "triggerNotification("

25 + Notifications[idx] + ") => trigger_" + Notifications[idx] + ";\n")the_file = (the_file + " " + "outwardNotification("+ Notifications[idx] + ") => " + Notifications[idx] + ";\n")

for idx, val in enumerate(Enumerations):the_file = (the_file + " " + "sendReply("

30 + Enumerations[idx] + ") => " + Enumerations[idx] + ";\n")the_file = (the_file + " " + "outwardReply("+ Enumerations[idx] + ") => " + Enumerations[idx] + ";\n")

new_file = filepath[:-6] + "_renaming.mcrl2" # Filepath of the renaming file35 with open(new_file, ’w’) as file:

file.write(the_file) # Storing the generated string in the renaming file

import osmodels = "C:\Localdata\LOPW_per_comp_new"

40 for subdir, dirs, files in os.walk(models): # Loop over all files in the directoryfor file in files:filepath = subdir + os.sep + fileif filepath.endswith(".dm.singlethreaded.mcrl2"): # Only take single-threaded DMs

print "Current model: ", file45 generate_renaming(filepath)

C. CIF specification

Listing C.1: CIF implementation of WH Clean interfaces and requirement automaton

plant WH_Clean:uncontrollable clean;controllable yes, no;

5 location Operational: initial; marked;edge clean goto Response;

location Response: // pseudo stateedge yes, no goto Operational;

10 end

plant DataStore1: // Used componentuncontrollable True, False;controllable wafer;

15

location Operational: initial; marked;edge wafer goto Response;

location Response: // pseudo state20 edge True, False goto Operational;

end

plant DataStore2: // Used componentuncontrollable enabled, disabled;

25 controllable option;

location Operational: initial; marked;edge option goto Response;

30 location Response: // pseudo stateedge enabled, disabled goto Operational;

end

requirement R1: // Ensures both checks are performed after receiving the call35 // Also allows only the correct response (yes/no)

location Operational: initial; marked;edge WH_Clean.clean goto Reply1;

location Reply1:40 edge DataStore2.enabled goto Reply2;

edge DataStore2.disabled goto No;

location Reply2:edge DataStore1.True goto Yes;

45 edge DataStore1.False goto No;

location Yes:edge WH_Clean.yes goto Operational;

50 location No:edge WH_Clean.no goto Operational;

end

67

Master’s Thesis · Master’s Thesis Master: Mechanical Engineering Department: Mechanical...

Documents

Transcript of Master’s Thesis · Master’s Thesis Master: Mechanical Engineering Department: Mechanical...