Supervisory Control for the Linear Cluster tool mock-up

Transcription

1 Supervisory Control for the Linear Cluster tool mock-up Daniël Veldman SE Bachelor Final Project (4W099) Advisors: Dr. Ir. J.M. van de Mortel-Fronczak Ing. H.W.A.M. van Rooy Eindhoven University of Technology Department of Mechanical Engineering Systems Engineering Group Eindhoven, May 2012

2

3

4

5 Summary Cluster tools are used in semiconductor industry to process wafers. Wafers are processed according to predefined routing sequences. A cluster tool consists of process modules, transport modules and cassette modules. The transport modules transport wafers according to predefined recipes to the different process modules. The cassette modules are used to store wafers that have to be processed or that have been processed. In previous projects a mock-up of a linear cluster tool has been designed. The transport module and the cassette module are built. The goal of this project is to create a control layer for the linear cluster tool mock-up. This control layer is designed using supervisory control theory. Supervisory control theory provides a method to synthesize controllers for discreteevent systems. To synthesize a controller, models of the plants and requirements are needed. Requirements describe the desired behavior of the plants. Both the plants and the requirements are modeled as automata. To model the plants, some knowledge about the mock-up is needed. It is important to know which sensors and actuators are available and what the effects of the actuators on the sensors is. This analysis showed that the current mock-up does not contain all the hardware that is needed to control the mock-up. The next step consists of modeling the actual modeling of the plants (the mock-up) and requirements as automata. This is done in three phases. In the first phase, only the radial and vertical movement of the wafer platform on the transport module are modeled. In the second phase, this model is further extended to include the rotation of the transport module. In the last phase, also the process stations and the input/output stations are modeled. This division makes the designing more structured and easier to understand. These parts are chosen in such a way that the aggregative distributed technique can be used to synthesize the supervisor. This technique is used because it guarantees that when the supervisors for the subproblems exist, the combination of these supervisors is a supervisor for the whole plant. This is also needed to reduce the time it takes to compute the supervisor. Although the theory asserts the the supervisor for the modeled plants satisfies all requirements, the supervisor should be i

6 ii Summary verified. The verification is needed to assure that the models of the plants and requirements are correct. This verification is done by untimed and timed simulation of the supervised plants. The verification shows that the plants and requirements are modeled correctly, and that the supervised plants show indeed the desired behavior. The conclusion is that the goal of this project is reached. The supervisory control layer has been synthesized for the linear cluster tool mock-up. The behavior of the supervised plants is verified by untimed and timed simulation, and found to be correct. In the analysis of the sensors and actuators available, it was found some extra sensors are needed to control the mock-up. The supervisory control layer can subsequently be implemented and tested on a real-time platform.

7 Samenvatting Cluster tools zijn machines die worden gebruikt om wafers te bewerken. Wafers worden bewerkt in een van te voren vastgestelde volgorde. Een cluster tool bestaat uit process modules, transport modules and cassette modules. De transport modules transporteren wafers in de vastgestelde volgorde naar de verschillende process modules. The cassette modules bevatten wafers die nog bewerkt moeten worden en wafers die al bewerkt zijn. In voorgaande projecten is een testopstelling van een linear cluster tool ontworpen. The transport module en de cassette module zijn gebouwd. Het doel van dit project is een besturing voor deze testopstelling te ontwerpen. Deze besturing is ontworpen met behulp van supervisory control theorie. Supervisory control theorie beschrijft een methode om een supervisor voor discreteevent systemen te synthetiseren. Om een supervisor te synthetiseren zijn modellen van de plants en requirements nodig. Requirements beschrijven het gewenste gedrag van de plants. De plants en de requirements worden gemodeleerd als automaten. Om de modellen van de plants te maken, is eerst de testopstelling bestudeerd. Met name is van belang welke sensoren and actuatoren er zijn, en wat de invloed van de actuatoren op de sensoren is. Hierbij is duidelijk geworden dat de huidige testopstelling nog niet hardware bevat die nodig is om deze te kunnen besturen. De volgende stap bestaat uit het modeleren van de plants en de requiements als automaten. Dit is gedaan in drie fasen. De eerste fase bestaat uit het modeleren van de radiale en verticale beweging van het wafer platform op de transport module. In de tweede fase is dit model uitgebreid met de rotatie van de transport module. De laatste fase bestaat uit het modeleren van de process modules en de cassette module. Deze onderverdeling maakt het mogelijk om de aggregatieve gedistribueerde techniek te gebruiken om de supervisor te synthetiseren. Voor deze techniek is bewezen dat als de supervisors voor elk van de deelproblemen bestaan, de combinatie van deze supervisor een supervisor is voor de hele probleem. Het is noodzakelijk een gedistribueerde techniek te gebruiken om de duur van de synthese te verkorten. Na de synthese moet de supervisor worden geverifiëerd. Alhoewel de gesynthetiseerde supervisor aan alle iii

8 iv Samenvatting requirements voldoet, is verificatie van de supervisor noodzakelijk om aan te tonen dat de plants en de requirements correct zijn gemodeleerd. Voor de verificatie is gebruikt gemaakt van untimed en timed simulatie. Deze verificatie toont aan de plants en requirements correct zijn gemodeleerd. Daarmee is het doel van dit project bereikt. De control layer voor testopstelling van de linear clustertool is ontworpen met behulp van supervisory control theorie. De verificatie toont aan dat de modellen van de plants en de requirements correct zijn. Enkele uitbreidingen van de huidige testopstelling zijn nodig om de control layer ook real-time te kunnen testen.

9 Contents Summary Samenvatting i iii 1 Introduction 1 2 Theory Discrete-event system (DES) Operations on DES Supervisor synthesis Distributed supervisor synthesis Description of the mock-up 17 4 The model The linear guide and the lift Transport module The full plant Synthesis and verification Supervisor synthesis Verification v

10 vi Contents 6 Conclusion and recommendations 51 Bibliography 53 A Models and requirements 55 B Overview of events and initial states 61 B.1 Events B.2 Initial states B.3 Untimed simulation results C Timed simulation results 69 C.1 Specified time steps C.2 Results

11 Chapter 1 Introduction Cluster tools are used in semiconductor industry to process wafers. Wafers are processed according to predefined routing sequences [11]. A cluster tool consists of process modules, transport modules and cassette modules. The transport modules transport wafers according to predefined recipes to the different process stations. The cassette modules are used to store wafers that have to be processed or that have been processed. Linear cluster tools (LCT) are built up out of links. One link consists of one transport module, around which there are four positions where process modules, cassette modules or a next link can be placed. Multiple links can be lined up, as shown in Figure 1.1. Supervisory control theory provides a method to synthesize controllers for discrete-event systems [10]. Discrete-event systems are systems that are described by a finite number of states and the transitions between them. The state of these systems changes at discrete points in time. When the plants and requirements for the system are modeled as discrete even systems, supervisory control theory provides a method to synthesize a supervisor for the system. This supervisor makes the system behave according to the prescribed requirements. For large systems, the time it takes to compute the supervisor becomes an issue. Therefore, techniques have been developed to reduce the computational time [5, 6, 7, 8, 9]. In previous projects [2, 3], a 1-link linear cluster tool mock-up is designed. The transport module and the cassette module (input/output station) have been realized. The purpose of this project is to design and evaluate a control layer for the mock-up. The control layer is created using supervisory control theory. To use supervisory control, the plants and requirements need to be modeled as discrete-event systems. With these models, a supervisor can be synthesized. To reduce the computational time, the total problem is divided into three subproblems. After the synthesize of the supervisor, it 1

12 2 Chapter 1. Introduction Figure 1.1: A linear cluster tool consisting of multiple links. The large blocks with a square are process modules, blocks with circles are transport modules, the block on the left is a cassette module. Between the transport modules are buffers. The red rectangle indicates one link. should be verified that the models and requirements are modeled correctly. The report is structured as follows. In Chapter 2, the basics of supervisory control theory are described. In Chapter 3, the created mock-up is described. Specifically, the sensors and actuators available to control the mock-up are investigated. In Chapter 4, the modeling of the plants and the requirements is discussed. The total problem is split up in three subproblems, that can be solved separately. In Chapter 5 the synthesis and verification are discussed. Because of the size of the model, a distributed technique is used to synthesize the supervisor. The supervisor and the models of the plant components are verified by untimed and timed simulation. The report ends with a conclusion and recommendations.

13 Chapter 2 Theory This chapter describes basics of the theory of supervisory control for discrete-event systems, based on [10]. First a discrete-event system and its automaton representation are defined. Operations on automata are discussed. After that a supervisor is defined and two distributed techniques of [5, 9, 8] to synthesize a supervisor are shortly viewed. 2.1 Discrete-event system (DES) The characteristic of a discrete-event system (DES) represented by an automaton is that it is a system that can be in a finite number of states. Usually, the set of all states of a system is denoted by Q. Some of these states are marked states. Marked states are special states. For instance a marked state can be a state in which the system can safely terminate. The set of marked states is denoted by Q m Q. Certain events can occur. The set of all possible events is called the alphabet and is denoted by Σ. Events can be controllable or uncontrollable. Controllable events are events that can be controlled by a supervisor. When an event occurs the state of the system changes. The next state depends on previous state and the event that occurred. To put it formally, there is a partial function δ : Q Σ Q that assigns to the previous state and an event, the next state. Function δ is called the transition function. Note that there can be states in which a certain event cannot take place, so that δ is not defined on the full set Q Σ. A DES has also an initial state q 0. This is the state in which the system starts. A state q is reachable when there is a sequence of events that leads from the initial state q 0 to q. States that are not reachable do not have to be modeled, because the system can never get in such state. A state q is co-reachable when there is a sequence of events from q to 3

14 4 Chapter 2. Theory Figure 2.1: Example of the model of a machine. a marked state. (Every marked state is co-reachable). So a DES or an automaton G consists of a set of states Q, an alphabet Σ, a transition function δ, an initial state q 0 and a set of marked states Q m. This is denoted by G = (Q, Σ, δ, q 0, Q m ). Example 1 Consider the machine in Figure 2.1. The machine has three states: Idle, Working and Done. So the set Q = { Idle, Working, Done } In the state Idle a product can be placed in the machine. This is indicated by the event Place. The supervisor can control when the product is placed in the machine, so Place is controllable. In the state Working, the machine is working on a product. When the machine has finished working, the event Ready occurs. The supervisor can not determine when the machine has finished working, and therefore the event Ready is uncontrollable. In the state Done, there is a finished product that can be picked (event Pick). Pick is a controllable event, because the supervisor can control when a product is picked. Note that uncontrollable events are printed in red and italics in the figures, and that controllable events are printed in blue. So the alphabet of this plant Σ = { Place, Ready, Pick }. For this example it is also clear that the transition function δ is not defined on the full set Q Σ. In this case it is only defined on { (Idle, Place), (Working, Ready), (Full, Pick) }. The system can only safely shut down when the machine is in the state Idle, so this is the only marked state (marked states have a bold edge in the figures). Initially, there is no product at the machine, so Idle is also the initial state (the initial state is colored green in the figures).

15 2.2. Operations on DES 5 A state can be blocking. This means that from this state there is no sequence of events by which a marked state can be reached. There are two types of blocking: deadlock and livelock. In a deadlock situation, the system can perform no action at all. In a livelock situation, events can still occur, but the system can never reach a marked state. Blocking states or states from which a blocking state can be reached by an uncontrollable event are called forbidden states [4]. A subset of all possible sequences of events from the alphabet Σ that start in the initial state and can be generated according to the transition function, is the language of the system. The language of a system G is denoted by L(G). The subset of all sequences of L(G) that make the system end in a marked state is called the marked language L m (G). 2.2 Operations on DES Given two DESs, G 1 = (Q 1, Σ 1, δ 1, q 01, Q m1 ) and G 2 = (Q 2, Σ 2, δ 2, q 02, Q m2 ) the synchronous product G 1 G 2 is a new automaton G = (Q, Σ, δ, q 0, Q m ). The state set Q contains all reachable states of {(q 1, q 2 ) q 1 Q 1, q 2 Q 2 }. The alphabet of this new automaton contains all events that can occur in G 1 or G 2, Σ = Σ 1 Σ 2. For the transition function δ((q 1, q 2 ), σ), there are four different cases: 1. The event σ is in both Σ 1 and Σ 2 and δ 1 (q 1, σ) and δ 2 (q 2, σ) are defined. Then δ((q 1, q 2 ), σ) = (δ 1 (q 1, σ), δ 2 (q 2, σ)). 2. The event σ is in both Σ 1 and Σ 2 and δ 1 (q 1, σ) or δ 2 (q 2, σ) are not defined. Then δ((q 1, q 2 ), σ) is not defined. 3. The event σ is not in the alphabet Σ 1 of G 1. Because σ Σ 1 Σ 2, this means that σ Σ 2. Then Then δ((q 1, q 2 ), σ) = (q 1, δ 2 (q 2, σ)). 4. The event σ is not in the alphabet Σ 2 of G 2. Because σ Σ 1 Σ 2, this means that σ Σ 1. Then Then δ((q 1, q 2 ), σ) = (δ 1 (q 1, σ), q 2 ). The initial state of G is determined by the initial states of G 1 and G 2, so q 0 = (q 01, q 02 ). Similarly, also Q m = {(q 1, q 2 ) q 1 Q m1, q 2 Q m2 }. Example 2 Consider the model of a transport module in Figure 2.2 that can pick products from or place products at a buffer (by the events PlaceBuffer and PickBuffer) or the machine from Figure 2.1. The transport module has two states. The car can

16 6 Chapter 2. Theory Figure 2.2: Model of a transport module that can pick and place wafers at a buffer or at a machine. Figure 2.3: The synchronous product of the automatons in Figure 2.1 and 2.2

17 2.2. Operations on DES 7 carry a product (state Full) or be empty (state Empty). Initially, the car has no product. The synchronous product of these two automata is shown in Figure 2.3. The car can initially only perform Pick or PickBuffer. When the machine is Idle, Pick is not possible. This shows that the only possible transition in the initial state is PickBuffer. Note that PickBuffer is not disabled by the machine, because PickBuffer is not in the alphabet of the machine. Now the combined state is considered, where the transport module is in state Full and the Machine is in state Idle. In this state the car allows Place and PlaceBuffer. These are also both allowed by the machine. PlaceBuffer leads back to the initial state, while Place leads to a new state. In this new state, the transport module is in state Empty and the machine is working. In a similar way the rest of the automaton in Figure 2.3 can be constructed. Another operation is the projection of a language L with alphabet Σ on a set of events Σ Σ. For each sequence of events in the language, the events that are not in Σ are removed. The resulting language can also be represented by an automaton, as shown by Example 3. A disadvantage of the projection is that in general information about blocking is lost. Blocking is an important property in Supervisory Control Theory, and therefore another operation is introduced in [9]. An automaton abstraction of a DES G with alphabet Σ, with abstraction alphabet Σ Σ is similar to a projection. The difference is that states from which a blocking situation can be reached by a sequence of events not in Σ, are separated from states for which this is not possible. Note that this means that an automaton abstraction can contain states from which there are multiple edges labeled with the same event (the resulting automaton in non-deterministic). This is also further illustrated by the following example. Example 3 This example shows the difference between projection and abstraction. The automaton in Figure 2.4 is considered. In the projection of this automaton on the set { tau, b }, information about the event a is lost, so it cannot be determined whether the plant is in state1 or state2. Similarly, when the event b occurs in state1 or state2, the new state can be either state3, state4, state5 or state6. This explains the automaton shown in Figure 2.5a. The abstraction on the set { tau, b } the information about blocking states is preserved. This means that state1 and state2 cannot be considered as one. From state1 the blocking state state6 can be reached, but from state2 no blocking state reached (without the event b occurs). Both state1 and state2 are reached with the event tau. So there are two edges from state0 with label tau. state3 and state4 can be considered as one,

18 8 Chapter 2. Theory Figure 2.4: Automaton which is projected and abstracted in Example 3. (a) Projection (b) Abstraction Figure 2.5: Projection and abstraction on the set {tau, b } of the automaton in Figure 2.4

19 2.3. Supervisor synthesis 9 because from neither of these states a blocking state can be reached. Continuing this reasoning, the automaton in Figure 2.5b is obtained. 2.3 Supervisor synthesis A supervisor is the largest sublanguage of a system that satisfies the defined requirements and prevents forbidden states. A supervisor for a DES can disable only the controllable events of the system to satisfy the requirements. Uncontrollable events are always enabled. A control pattern describes what controllable events are enabled, based on the state of the system. So the supervisor itself cannot perform any event. However in the implementation of the supervisor, enabled controllable events are performed. When more than one controllable event is enabled, one of them is performed. To develop a supervisor, the following steps are taken [5]: 1. System analysis 2. Supervisory control problem identification and modeling 3. Derivation of the supervisor 4. Model-based validation of the supervised system 5. Incorporation of the implemented supervisor in a real-time environment Before a supervisor can be synthesized, the system should be analyzed. Based on this analysis, a model of the system is made. This model is called the plant, it consists of one or more plant components. Also the requirements for the supervisor should be defined. Requirements describe the desired behavior of the plants. Note that requirements are also modeled as automata. Based on the model of the plant and the requirements, a supervisor is synthesized. A way to determine this language is to first compute intersection of the synchronous product of all plant components and the synchronous product of all requirements. The language now obtained is called the total admissible behavior. Note that this language does not prevent blocking states, and therefore is not a supervisor. To obtain a supervisor, the states that are forbidden have to be removed from the admissible behavior. Because a model of the plant is made already, the supervised plant can be tested. Testing is necessary to verify that the models of the plant and requirements are made correctly. Supervisory control theory assures that the supervisor synthesis is always

20 10 Chapter 2. Theory Figure 2.6: Requirement for the transport module in Figure 2.2 Figure 2.7: Synchronous product of the automatons from Figure 2.2 and Figure 2.3 correct. When these tests show the desired behavior, the supervisor can also be implemented in a real-time environment. Example 4 Consider again the Machine from Figure 2.1 and the transport module from Figure 2.2. In Example 2, the synchronous product of these two automata was computed (shown in Figure 2.3). As can be seen, it is possible that the car picks a product from the buffer and places it immediately back. This is not productive, and this behavior should therefore be prevented. Therefore, the requirement in Figure 2.6 is imposed. The synchronous product of this requirement with the plant from Figure 2.3 is shown in Figure 2.7. Note that this automaton is not a supervisor, because it does not prevent forbidden states. Since there are no events leading from the state Done Full, this state is blocking. Therefore, the supervisor should prevent that this state is reached. Note also that Done Full can be reached from the state Working Full by the uncontrollable event Ready. This means Working Product is forbidden and should also be removed from the supervisor. The resulting supervisor is shown in Figure 2.8.

21 2.4. Distributed supervisor synthesis 11 Figure 2.8: Supervisor for the Machine from Figure 2.1 and the car from Figure 2.2 that satisfies the requirement Distributed supervisor synthesis The computational costs to compute a supervisor form a problem for large plants. A large plant is often obtained when it is the product of many small plant components. To overcome this problem new techniques have been developed, like the state-based framework instead of the event based framework. In the state-based framework, problems of states can be handled [7]. Within the event-based framework is used, the interfacebased framework. In the interface-based framework, the system is decomposed into one or more subsystems that can only communicate by an DES called the interface. In the interface-based framework, problems up to can be handled [6]. In this project, we use the event based framework. To keep computational times short, instead of the monolithic approach described in Section 2.3 a distributed supervisor synthesis is used. In distributed supervisor synthesis, different supervisors are synthesized, each dealing with a part of the total problem. These supervisors are called partial supervisors. Two methods for distributed supervisor synthesis are described below. In aggregative distributed synthesis [1, 8], the model of the plant is split in n components G 1, G 2,... G n, with requirements H 1, H 2,... H n. First the supervisor S 1 for G 1 with requirements H 1 is computed. Then the synchronous product of G 1 S 1 is computed of which an abstraction W 1 is made. Now a supervisor S 2 for the plant G 2 W 1 under the requirements H 2 is computed. Then an abstract W 2 of the supervised plant (G 2 W 1 ) S 2 is created. Continuing this process results in n supervisors S 1, S 2,... S n. When all S i are non-empty, the supervisor for the total plant is given by S 1 S 2... S n. A schematic overview of the aggregative synthesis can be found in Figure 2.9. In coordinated distributed synthesis [1, 5], the model of the plant is again split up in

22 12 Chapter 2. Theory Figure 2.9: Schematic overview of the aggregative distributed supervisor synthesis. components G 1, G 2,... G n, with requirements H 1, H 2,... H n, H. First the supervisors S i for the plants G i under requirements H i are computed. Then abstractions W i of G i S i are created. Then a supervisor S for W 1 W 1... W n under the requirement H is computed. This supervisor is called the coordinator. Finally, S 1 S 2... S n S is a supervisor for the total plant. This is visualized in Figure Note that for both synthesis procedures, there is no instruction about how the alphabet for abstraction should be chosen. The alphabet is chosen as small as possible to keep also the abstractions small. On the other hand, the alphabet should contain the events that are used in requirements for plants in which the abstraction is used. A general guide line is that this alphabet should contain all controllable events of the plant. In this project, the aggregative distributed supervisor synthesis technique is used. For the aggregative synthesis, it is proved in [8] that when all partial supervisors are nonempty, the product of these supervisors is a supervisor for total plant that satisfies all requirements. The coordinated distributed technique does not guarantee that when all partial supervisors exist, the total supervisor also exists. Also, the aggregative technique reflected the structure of the model better than the coordinated technique. Therefore the aggregative technique is chosen. Example 5 In this example, the aggregative distributed technique is illustrated. Consider the plants G1, G2 and G3 in Figure 2.11 and Figure 2.12 with the requirements H1 and H2 in Figure To use the aggregative technique, first the supervisor S1 for the plant G1 is computed. Since there is no explicit requirement which contains only events in the alphabet of G1, the supervisor only prevents forbidden states. In this case state3 is forbidden, and S1 is the automaton in Figure The alphabet of the abstraction W1 should contain all events that that are both in the alphabet of G1 and in the alphabet of G2, G3, H1 or H2. Since the event tau is in the alphabet of all plants and requirements, and the event c1 is both in G1 and H1, the alphabet for abstraction is chosen {tau, c1 }. Now the abstraction W1 and W1 G2 can be computed. The supervisor for W1 G2 with the requirement H1 is shown in Figure 2.15a. Note that

23 2.4. Distributed supervisor synthesis 13 Figure 2.10: Schematic overview of the coordinated distributed supervisor synthesis. Figure 2.11: Plant G1 of Example 5. c1 is disabled in W1 G2 and that the state2 in H1 is therefore blocking, so that c2 is also disabled by S2. The alphabet of the abstraction W2 should contain all events that are both in the alphabet of W1 G2 and in the alphabet of G3 or H3. Therefore, the alphabet is chosen {tau, c2}. Now similarly W2 can be computed, and the supervisor S3 for W2 G3 under the requirement H2 can be computed. This supervisor is shown in Figure 2.15b. In this chapter, the theory that forms the basis for supervisor synthesis has been discussed. In the next chapter, step one of the supervisor synthesis is discussed. In this step, the system is analyzed. This analysis will form the basis for the models that are needed for supervisor synthesis (in step 2).

24 14 Chapter 2. Theory (a) Plant G2 of Example 5. (b) Plant G3 of Example 5. Figure 2.12: Plants G2 and G3 of Example 5. (a) Requirement H1 of Example 5. (b) Requirement H2 of Example 5. Figure 2.13: Requirements of Example 5. Figure 2.14: First partial supervisor of Example 5.

25 2.4. Distributed supervisor synthesis 15 (a) Second partial supervisor of Example 5. (b) Third partial supervisor of Example 5. Figure 2.15: Plants G2 and G3 of Example 5.

26 16 Chapter 2. Theory

27 Chapter 3 Description of the mock-up In previous projects [2, 3], a mock-up of the linear cluster tool is created. In this chapter, important aspects of the mock-up are discussed, such as the sensors and actuators available. Also some recommendations and assumptions are made about extra sensors that are needed. Based on the results of this chapter, a model of the setup can be made. The basis of the design is a rotating disc, with a linear guide mounted on top (see Figure 3.1). The linear guide can move in and outward, and also up and down. In this way, wafers can be picked or placed. The position where the linear guide picks or places a wafer can be changed by the rotating table. The input/output module consists of a cassette that can be moved up or down to change the position where a wafer is picked or placed. In the current setup, two sensors are mounted at the endpoints of the linear guide. It is needed that the linear guide decelerates before the endpoints. With two sensors it is impossible to determine when deceleration should start. Therefore, four sensors that measure the position of the linear guide are modeled. Two of these sensors are positioned at the endpoints. The other two mark the positions where the deceleration should start. These positions are indicated in Figure 3.2. The width of the cart that moves over the rails of the linear guide is almost half the length of the rail. This means that when the cart is at Sensor 1, Sensor 2 measures the cart also. So Sensor 2 is always on when Sensor 1 is on. The same holds for Sensor 3 and 4. It is assumed that the gap between Sensor 2 and 3 is larger than the width of the cart. So Sensors 2 and 3 cannot be on simultaneously. The height of the linear guide can be changed by a lifting mechanism. Due to the construction of the lifting mechanism, the motor rotates only one way. When the motor is on, the position of the lift changes between up and down. To measure the lifting 17

28 18 Chapter 3. Description of the mock-up Figure 3.1: Basic design of the linear clustertool mock-up

29 19 Figure 3.2: Sensor positions on the linear guide position two sensors indicate whether the lift is up or down. There are four sensors installed on the rotating table, numbered from 1 to 4 (see Figure 3.1). When the linear guide is pointing to one of the four positions in Figure 3.1, the sensor mounted on that position detects that. The wiring of the components on the rotating disc limits the rotation. It therefore required that the rotation never exceeds 360. For security, an emergency-sensor is installed. When this sensor detects the rotating table the power to the motor of the rotating table is switched off. The power can not be switched on by the supervisor. This sensor is located between position 2 and 3 in Figure 3.1. The linear guide, lift and rotating table are powered by DC engines. In the models, it is assumed that the supervisor can set the direction and the speed of these motors. For the lift and the rotating table only one speed level is used. For the deceleration of the linear guide also another half speed level is needed. The input/output station consists of cassette that has 10 positions that can contain a wafer. The position where a wafer can be picked or placed can be changed. In the current setup, there is a sensor that measures whether this position contains a wafer or not. It is assumed that the motor that changes this position is controlled in such a way that it can move precisely one position up or down. Further, it is assumed that there are two sensors that indicate that the highest or lowest position in the cassette are searched. In the operation of the mock-up, the cassette should be replaced to bring new wafers in the system and remove the processed wafers. Replace is not always allowed, for example when the linear guide extends at the input/output station. Therefore and that a lamp and a switch are needed. The lamp is used to indicate whether replace is possible, and the switch is used to indicate that a replace is taking place. The process stations have not been realized yet. For the models a only basic properties are assumed. When a wafer is placed at a process station, the process station starts working on that wafer. When the station has finished working and the wafer can be picked again, it sends some signal to the supervisor.

30 20 Chapter 3. Description of the mock-up In this chapter, the sensors and actuators at the mock-up were studied. The analysis shows that some extra hardware is needed before the mock-up can be properly controlled. More specifically, the linear guide needs four sensors and a lamp and a switch are needed for the replacement of the cassette. The results from this chapter form the basis for the models in the next chapter.

31 Chapter 4 The model In this chapter, the modeling of plants and requirements is discussed. All components in Figure 3.1 are modeled and suitable requirements are imposed. An overview of all events can be found in Appendix B. This appendix contains also a list of the initial states of all components. In the modeling of the plants it is assumed that the hardware is ideal. So hardware can not break down, and sensors do always detect objects when these move in front of the sensor. This assumption is not very realistic, but is used to reduce the size of the supervisor. Due to this assumption, plant models can be kept relatively simple and intuitive. Further it is assumed that there is no delay in the communication between hardware and the supervisor, and that actuators do not move once they are turned off. A consequence of this assumption is that when an actuator is turned off, the sensor that monitors that actuator can not change anymore. For sensor values the convention is used that SensorOn means that these is something in front the sensor. In the actual hardware, sensor can have both positive and negative logic, so for some sensors the SensorOn might mean a high signal and for other sensors a low signal. This can be corrected in the implementation of the supervisor. The structure of this chapter is as follows. In Section 4.1, a model is developed for the linear guide and the lifting mechanism of the transport module. The result of this section is that when event (LG Fullspeed) is enabled the linear guide will extend, the lifting mechanism will change its position and the linear guide will retract again. The end of this cycle is marked by another event (LG Extend). In Section 4.2 these results are extended to include also the rotating table. This means 21

32 22 Chapter 4. The model that the whole transport module is modeled. Events that make the transport module pick or place a wafer at the desired position are introduced, to simplify the control of the total mock-up in the next subsection. In Section 4.3 the whole mock-up is considered. Simple models are introduced for the process stations. Also a more detailed model for the input/output station is introduced. Also the replacement of the cassette of the input/output station is handled. Most of the figures referred to are placed in this section. Some models and requirements, similar to ones included in the main text, can be found in Appendix A. The numbers of these figures start with A (for example Figure A.1). 4.1 The linear guide and the lift In this section, the plants and requirements are modeled for the linear guide and the lift. Also the coordination of linear guide and the lift is handled. The linear guide The direction and the speed of the motor that powers the linear guide can be set independently. The direction can be extend or retract and is changed by the events LG Extend or LG Retract. The sensors of the linear guide are numbered as in Figure 3.2. Further the speed of the motor is set by the events LG Fullspeed, LG Halfspeed and LG Off. When the direction of the motor and the position of the cart are known, there is only one sensor that can change. For example, when the cart is between Sensor 3 and 4 and the motor state is extend, only Sensor 4 can go on. This behavior is shown by the automaton in Figure 4.1. Further, the motor speeds full speed, half speed and off have to be included in the model. When the motor is off the linear guide is not moving, so none of the sensor values can change. On the other two speed levels half speed and full speed the sensor values can change. This can be modeled with the automaton in Figure 4.2. It shows that the state of the motor can be changed by the events LG Fullspeed, LG Halfspeed and LG Off. This completes the model of the linear guide. The supervisor for the linear guide should make the cart move between the two endpoints. It should also set the motor two half speed at sensor before the endpoints. Only necessary changes in the direction and speed of the motor are allowed.

33 4.1. The linear guide and the lift 23 Figure 4.1: First part of the model of the linear guide. Direction of the motor determines which sensor values can change.

34 24 Chapter 4. The model Figure 4.2: Second part of the model of the linear guide. When the motor is, sensor values can not change. The first requirement on the linear guide is that the motor is only turned off at the endpoints (Sensor 1 and 4). This is done by the requirement in Figure 4.3. Further, it is required that the direction of the motor is only changed when the motor is off (Requirement in Figure 4.4a). However, with these two requirements it is still possible that the motor goes on at an endpoint before the direction actually has been changed. Therefore it is also required that the motor may only go on after the direction has been changed. This is one of te consequences of the requirement in Figure 4.11b. After the motor is turned on, it is meant to leave the endpoint. This means that it should not be turned off immediately. So when the motor is turned on, Sensor 1 or 4 should go off before the motor may be turned off again. This is also accomplished by the requirement in Figure 4.4b. Note that the combination of these three requirements makes that linear guide stops at the endpoints, and changes direction there. After that the motor is turned on and the linear guide moves (without stopping) to the other endpoint. The next problem is that the motor should only go half speed when an endpoint is almost reached. Since the direction of the motor can only change at the endpoints, an endpoint is almost reached precisely when Sensor 2 or 3 goes on. So LG Halfspeed may only happen when Sensor 2 is on and Sensor 1 has not gone on (for endpoint 1) or when Sensor 3 is on and Sensor 4 has not gone on yet (for endpoint 4). This is the requirement shown in Figure 4.5. Note that when the motor is set to half speed, the event LG Fullspeed is also enabled. This means that with the current requirements the speed can change between half speed and full speed near the endpoints. To prevent

35 4.1. The linear guide and the lift 25 Figure 4.3: First requirement for the linear guide. The motor may only be turned off at the endpoints. (a) Second requirement for the linear guide. The(b) Third requirement for the linear guide. Direction motor may only change direction when it is off. should be changed at the endpoints and the motor is not turned off when leaving the endpoint Figure 4.4: Requirements for the linear guide. Requirements for setting the direction of the motor. this, it is required that after the motor is set to half speed, it should go off and cannot go back to full speed (Requirement in Figure 4.6). This is the last requirements for the linear guide alone. Lift The lift consists of two sensors that that detect whether the up (Sensor Lift SenUp) or down (Sensor Lift SenDown). The lift can also be between these two sensors, so that both sensors do not detect the lift. The lift is powered by a motor that rotates only one way, with only one speed level. So the motor can only be turned on (Event Lift Run) of off (Event Lift Off). When the motor is on, the lift is moves between the upper and lower position. Be-

36 26 Chapter 4. The model Figure 4.5: Fourth requirement for the linear guide. when an endpoint is almost reached. Motor may only go half speed Figure 4.6: Fifth requirement for the linear guide. Motor cannot go from half speed to full speed.

37 4.1. The linear guide and the lift 27 Figure 4.7: Model of the lift cause the motor rotates in only one direction, the only possible order of events is Lift SenDownOff, Lift SenUpOn, Lift SenUpOff, Lift SenDownOn, Lift SenDownOff,.... When the motor is off, the sensor values can not change. This is modeled with the automaton in Figure 4.7. The first requirement is that the lift should only stop when it is at an endpoint. More specifically, this means that Lift Off is only enabled when the Lift SenUp or Lift SenDown is on. This requirement is shown in Figure 4.8. With this requirement alone, the lift can still stop at the same position as where it started. To solve this, it is required that when the lift is turned on at Lift SenDown, the lift can only go off at Lift SenUp (Requirement in Figure 4.9). A similar requirement assures that when the lift is turned on at Lift SenUp, it can only go off at Lift SenDown. These two requirements make that when the lift is turned on, it changes its position.

38 28 Chapter 4. The model Figure 4.8: First requirement for the lift. Lift stops only at endpoints. Figure 4.9: Second requirement for the lift. When the lift is turned on at Lift SenDown, it can only go off at Lift SenUp. A similar requirement is used to make sure that when the lift is at Lift SenUp, it can only go off at Lift SenDown.

39 4.2. Transport module 29 (a) First requirement for the lift and linear guide. Lift can only go on when the linear guide is off. (b) Second requirement for the lift and linear guide. Linear guide can only go on when the lift is off. Figure 4.10: Requirements for the linear guide and lift. Linear guide and lift should not move simultaneously. Combining the linear guide and the lift The lift only moves to pick or place a wafer, so the lift should only move when the linear guide is fully extended. Since the linear guide will always extend to pick or place a wafer, this also means that the lift should always change its position before the linear guide retracts again. First off all, it is required that the lift and the linear guide do not move simultaneously. This means that the lift should not go on when the linear guide is moving (Requirement in Figure 4.10a) and that the linear guide does not go on when the lift is moving (Requirement in Figure 4.10b). Further, it is required that when the linear guide is fully extended (at Sensor 4), the lift should change its position (Lift Run should occur) before the linear guide leaves. This is assured by the requirement in Figure 4.11a. The last requirement is that the lift is not used when the linear guide is retracted (at Sensor 1). This requirement is shown in Figure 4.11b. With the requirements in this section it is assured that every time the linear guide extends, the lift will change its position. When the linear guide is retracted, the lift will not change its position. In the next section, this behavior is used to create a supervisor for the whole transport module. 4.2 Transport module In this section, the other requirements that are needed to control the transport module (consisting of the linear guide, lift and rotating table) are discussed. The results from

40 30 Chapter 4. The model (a) Third requirement for the lift and linear guide. Lift must change before linear guide leaves Sensor 4. (b) Forth requirement for the lift and linear guide. Lift does not change at Sensor 1. Figure 4.11: Requirements for the linear guide and lift. Lift should change position when the linear guide is extended. Section 4.1 are extended to control also the rotating table. After that a controller is introduced, so that with one event the transport module can pick or place a wafer at a desired position. Whether a pick or place action occurs, depends on the current position of the lift. The rotating table The position of the rotating table is measured by four sensors. The numbering of these sensors is as in Figure 3.1. The rotating table is powered by a DC engine, so the direction (events RT CW and RT CCW) and the speed (events RT On and RT Off)can be set separately. Because of the emergency switch between Sensor 2 and 3, the rotating table cannot directly move from 2 to 3. Just as with the model of the linear guide, there is only one sensor that can go on or off when the position and direction of the rotating table are known. The difference with the linear guide is that there is at most one sensor on. The relationship between the direction and the sensor values is modeled with the automaton in Figure A.1. Further, a sensor can only change its value when the motor is on (Figure A.2). Also, two events without a meaning in hardware are introduced. The events RT SetDirCW and RT SetDirCCW are used to check that the direction of the rotating table is correct, before it is turned on. The first requirement is that the direction can only be changed when the motor is off. So all events concerning the direction (RT CW, RT CCW, RT SetDirCW, RT SetDirCCW) are not enabled when the motor is on (Requirement in Figure A.3). Further, every time before the rotating table goes on, it should be checked that its direction is correct (so either RT SetDirCW of RT SetDirCCW should occur). This means that after the motor has gone on, RT SetDirCW of RT SetDirCCW should occur before the motor may go on again. This is modeled by the requirement in Figure The next requirement

41 4.2. Transport module 31 Figure 4.12: Second requirement for the rotating table. Motor can only go on after the direction has been set. assures that the direction of the rotating table is set according to the RT SetDirCW and RT SetDirCCW (Requirement in Figure 4.13). The first requirement for the rotating table is shown Figure It shows that the rotating table can only go off after a sensor value has changed. This requirement prevents that the rotating table is turned off before any real change in position has occured. But this requirement has a second effect. It assures that the rotating table changes direction at the emergency switch. This is illustrated by the following example. Consider the situation that the rotating table at Sensor 3 (see Figure 3.1) and that the motor is off. It is not wanted that the rotating table moves further clockwise, because then it will hit the emergency switch. Suppose therefore that the direction of the motor is clockwise and that the motor is turned on. This is state is blocking and therefore the supervisor prevents that this state is reached. To see that the state is blocking, note that to change the direction of the motor, the motor should go off again (by the requirement in Figure A.3). But when the rotating table moves further clockwise, there is no sensor that can go on. It might seem natural to require that the rotating table may only stop when one of the sensors is on (like is done for the linear guide in Figure 4.3). This is not a good requirement in this situation, because it will make the supervisor prevent that the motor is turned on at all. Since all the events that concern the sensors on the rotating table are uncontrollable, the supervisor can not force that RT Off occurs when a new sensor is reached. This means that the supervisor can not prevent the rotating table from reaching the outer positions (left from Sensor 3 or above Sensor 2 in Figure 3.1). In these outer positions it would not be allowed to turn the motor off, so a change of direction is impossible. Since this state is blocking, the supervisor should prevent that this state is reached. This means that the motor can not be turned on.

42 32 Chapter 4. The model Figure 4.13: Third requirement for the rotating table. The events RT SetDirCW and RT SetDirCCW assure that the direction is set correctly. Figure 4.14: Forth requirement for the rotating table. The motor can only go off when a sensor has gone on.

43 4.2. Transport module 33 Figure 4.15: First requirement for the rotating table in combination with the linear guide and lift. Linear guide can only go on when rotating table is off. Figure 4.16: Second requirement for the rotating table in combination with the linear guide and lift. Linear guide extends only when the rotating table is at a sensor. To make the rotating table work with the linear guide and the lift, it is required that the linear guide should only extend when the rotating table is off (Requirement in Figure 4.15) and when the rotating table is at one of the four sensors (Requirement in Figure 4.16). In the next section it is also assured that the rotating table does not go on when the linear guide or the lift are working. The controller A typical action of the transport module consists of the rotating table moving to a certain position where the linear guide extends and the lift changes position. After this the linear guide retracts. In this section, a controller is obtained that makes the transport module perform a such typical action. The position to which the rotating table has to move will be determined in the next section 4.3. For each position a GoTo-event is introduced. When an action is finished the event GoToReady will occur. Note that

44 34 Chapter 4. The model these events have no meaning for the actual hardware. Only one GoTo-action can be happening at the same time. This is reflected in the plant that introduces the GoTo events in Figure A.4. The following two requirements couple the GoTo-events to the linear guide and the lift. The first requirement regulates the occurrence of the GoToReady event. This event should occur after a sequence of the linear guide and the lift from section 4.1. This sequence is started when the motor of the linear guide is turned on (LG Fullspeed). After the linear guide has reached the endpoint and starts retracting the motor is turned on again. When the linear guide is retracted and has stopped the direction of the motor is set to extend (LG Extend). After this the GoToReady event should occur, to mark the end of an action of the transport module. This is assured by the requirement in Figure Further, the linear guide can only extend when the sensor to which the transport module is going is reached. This is assured by four requirements, for each sensor of the rotating table one. The requirement sensor 1 is shown in Figure This requirement shows that when the transport module is going to sensor 1, but is not at sensor 1 yet, the linear guide can not extend. Also when the rotating table is at sensor 1 and is not going to sensor 1, the linear guide can not extend there. There are two requirements that make the rotating table move efficiently to the desired position. The first requirement for this purpose is that the rotating table should not move when no GoTo event has happened. To prevent the rotating table from moving, it is sufficient to disable the events RT SetDirCW and RT SetDirCCW, since one of these should happen before the motor is turned on. The requirement is shown in Figure 4.19 For the second requirement it is used that the direction that the rotating table should go to depends only on which sensor was most recently on. When this sensor was Sensor 2 or Sensor 3 (which are close to the emergency switch), then the direction of the rotating table is already determined by the requirement in Figure So there are only requirements needed for the case that the sensor that was most recently on is Sensor 4 or Sensor 1. Consider for example the requirement for the case that Sensor 4 was most recently on. This requirement is shown in Figure When the rotating table was last at Sensor 4 and is going to Sensor 3, the direction should be counter clockwise. When the rotating table is going to 1 or 2, the direction is set to clockwise. The models and requirements from this section and Section 4.1 result in a supervisor for the transport module that can be controlled by the GoTo events. When such event takes place, the transport module will (depending on the current position of the lift)

45 4.2. Transport module 35 Figure 4.17: Requirement for the GoToReady event. This event occurs once after the linear guide has retracted. Figure 4.18: Requirement for the GoTo1 event. The linear guide may only extend at Sensor 1, when going to Sensor 1. Similar requirements are used for GoTo2, GoTo3 and GoTo4.

46 36 Chapter 4. The model Figure 4.19: Requirement for the GoTo events. The rotating table can only move after a GoTo event has occurred. Figure 4.20: Requirement to make the rotating table efficiently chose direction when the sensor that was last on was Sensor 4. A similar requirement is used for Sensor 1.

47 4.3. The full plant 37 pick or place a wafer at the desired position. In the next section the model will extended with the input/output station. 4.3 The full plant Now the transport module can be controlled easily by the GoTo events, the other components in the mock-up can be modeled. In Subsection 4.3, models of the process stations are discussed, and events are introduced for picking or placing a wafer from the current process station. In Subsection 4.3, the model of the input/output station is made and requirements for searching the cassette described. In Subsection 4.3, the model of the input/output station is extended so that a cassette can be replaced. The process stations In this section, the models of the process stations are discussed, and the GoTo-events from 4.2 are coupled to the events of the process stations. To determine whether a wafer can be placed or not, the current status of the process stations should be known. The process stations are numbered as in Figure 3.1. The model of Process station 1 is Figure 4.21a. The models of the other process stations are similar. Initially, the process station is waiting for a wafer to be placed. In this situation the event PS Place can occur, which means that the transport module is starting to place a wafer at the current process station. When the wafer is really placed at the process station, the state of the process station is changed by the event PS isplaced. From now on the event PS Ready can occur. This means that the process station has finished working on the wafer and that the wafer can be picked. The event PS isplaced is added to the model because otherwise PS Ready could occur before the wafer was really placed at the workstation. The right timing for the event PS isplaced is obtained by the requirement in Figure This requirement shows that when a PS Pick event for the current process station has occurred, the event PS isplaced should occur after lift has gone off (event Lift Off), but before the linear guide begins to retract (event LG Fullspeed). The input/output station is modeled as a special workstation. Because the input/output station can search for a wafer or an empty place, a wafer can always be picked or placed. 1 To make the input/output station fit in the same framework as the process stations, events IO Pick (meaning that a wafer is going to be placed at the input/output station) 1 At this stage it is assumed that a wafer or an empty spot can always be found, but in section 4.3 a mechanism is introduced that allows replacing the cassette when the desired spot can not be found.

48 38 Chapter 4. The model (a) Model of a normal process station (b) Part of the model of the input/output station that is similar to that of a process station. Figure 4.21: Requirements for the linear guide and lift. Lift should change position when the linear guide is extended. and IO Place (meaning that a wafer is going to be picked at the input/output station) are introduced. These are also shown in Figure 4.21b. It is required that after a pick event, a place event occurs and after a place event a pick event (Requirement in Figure A.5). Since it is assured in section 4.1 that every time the lift is turned on it changes its position, GoTo events result in picking or placing a wafer in exactly the same order. So further it is only required that after a pick or place event, the GoTo event for the right position occurs. To be more specific, after each pick or place event only one GoTo event may occur (requirement in Figure A.6), and this GoTo event should be the GoTo event at the right position. This second property is attained by the requirements like Figure A.7. For the other positions similar requirements are used. The input/output station In this section, the model of the input/output station is discussed and requirements for searching are introduced. The input/output station consists of a cassette that can move up or down, to change the position where a wafer can be picked or placed. There are two sensors (IO SenDown and IO SenTop) that detect the cassette when the lowest resp. highest position of the cassette is searched (Model is shown in Figure A.8). The motor controller supports

49 4.3. The full plant 39 Figure 4.22: Requirement to time the PS isplaced event. events that make the current place in the cassette move one place up (IO MotorInc) or down (IO MotorDec). When such action is completed the (uncontrollable) event IO MotorReady occurs. The only way that the sensors that indicate the lowest and highest position can change is when the motor is on. The model of the motor is shown in Figure A.9. There is also a sensor that detects whether current position in the cassette contains a wafer or not. This sensor value can change in three ways. The first way is that the cassette changes position. The second way is that total cassette is replaced. The third way is that the transport module picks or places a wafer. These three ways are also shown in the model of this sensor, that is shown in Figure It is chosen to explicitly specify the cases in which the current place sensor can change its value. This is used in the specification of the searching procedure. This means that when a correct spot is found in the cassette (after has stopped moving), this spot cannot change unless the supervisor allows a change (the supervisor can prevent that the cassette changes its position or that it is replaced). So when a correct spot is found, a wafer can be picked or placed, and it will not be necessary to search again. The input/output station should search for an empty spot when a wafer is going to be placed, so when the event IO Place occurs. Also, when a wafer is going to be picked (so when IO Pick occurs) the input/output station should search for a wafer. A spot is found when the sensor that detects the current place in the cassette has the right value at the moment that the motor goes off (IO MotorReady occurs). This behavior is attained by the requirement in Figure Note that this only works when there is always a wafer and a free spot in the cassette. When such place is not in the cassette, this requirement never stops searching. This problem is solved in the next section 4.3.

50 40 Chapter 4. The model Figure 4.23: Model of the sensor that detects whether there is a wafer at the current place in the cassette. There are three ways in which this sensor can change.

51 4.3. The full plant 41 Figure 4.24: Requirement for searching the cassette until the desired spot is found. Figure 4.25: Requirement that fixes the direction in which the cassette is searched. Note that this requirement does not specify whether the motor searches one place up or one place down. A simple requirement that fixes the direction in which is searched is shown in Figure Initially, the cassette is in the lowest possible position. Then the place that is searched in the cassette moves up until highest position is searched (IO SenTopOn). Then the place that is searched moves down until the lowest position is reached (IO SenDownOn). Replacing the cassette In this section, the model of the input/output station is extended so that a cassette can be replaced.