MoLde - a workflow language for the modelling of manufacture systems

(1)

UNIVERSIDAD DE LOS ANDES FACULTAD DE INGENIER´IA

Departamento de Sistemas y Computaci ´on

Grupo de construcci ´on de software

MoLde: A workflow language for the modelling

of manufacture systems

Jaime Andr ´es Romero

Thesis presented to acquire the title of Mag´ıster in System and Computing Engineering of

Universidad de los Andes

August, 2014

Advisor: Prof. Dr. Rubby Casallas Prof. David Mendez

(2)

(3)

Resumen

En este documento se presenta un lenguaje de dominio espec´ıfico para mode-lar sistemas de manufactura (MoLde) con el objetivo de facilitar el proceso de modelaje que incurre un ingeniero industrial. Un sistema de manufactura es un proceso (conjunto de tareas) que tiene como objetivo la creación de un producto o terminar un conjunto de trabajos. Este conjunto de tareas tiene un flujo de control, recursos que se necesitan para llevarlo acabo(maquinaria, trabajadores, herramientas) y restricciones adicionales que involucran la relación tarea-recurso, o la relación trabajo-tarea. Actualmente un ingeniero industrial cuando quiere estudiar un sistema de este tipo escoge una de las diferentes estructuras de mod-elamiento y algoritmos definidos sobre esta estructura. El problema con este enfoque es que la mayor´ıa de estas estructuras son de ”bajo nivel” (conceptos no cercanos al mundo del problema) es por esta razón que el modelador tiene que hacer una traducción del mundo del problema al mundo de la estructura de datos que implica que el proceso consuma tiempo, se necesite de conocimiento de la estructura y que el modelador incurra a errores. Una de las estructuras más usadas para el modelamiento de sistemas de manufactura son las redes de Petri debido a que mediante el uso de esta se puede modelar un gran conjunto de los eventos presentes en este tipo de sistemas. YAWL es un lenguaje de control de flujo usado para describir procesos de negocio, su sintaxis está basada en los conceptos de la red de petri. Este lenguaje nos permite expresar muchas de las restricciones de control de flujo presentes en un sistema de manufactura. Pero no nos permite expresar los recursos del sistema y las restricciones que involucran la relación tarea-recurso y la relación trabajo-tarea. MoLDe es una extesión a YAWL, nosotros incorporamos nuevos conceptos y cambiamos algunos conceptos existentes en YAWL para poder expresar un sistema de manufactura completo. En este trabajo se presenta este lenguaje y como se puede usar mediante el uso de algunos ejemplos.Tambien se describe un esquema de transformacioń a redes de Petri que tiene como objetivo el uso de algoritmos definidos sobre esta estruc-tura. Mostramos las herramientas de software desarrolladas en el proyecto. Y por último se incluye el proceso de validación del lenguaje.

(4)

Abstract

This document presents a domain specific language to model manufacture sys-tems (MoLde) aimed to make easier the modelling process of an industrial en-gineer. A manufacture system is a process (set of tasks) with the objective of creating a product or to finish a set of jobs. The set of tasks has restrictions of control flow, resources that are needed to perform a certain task (machinery, worker, tools) and other restrictions among the relationship between resource-task and among the relationship between job-resource-task. Now a days an industrial engineer when he want to study this type of systems he use different modelling structures and algorithms defined over this structures. The problem with this approach is that this structures are ”low level” (concepts not close to the ones present in the world of the manufacture systems) making the modelling process difficult, time consuming, and susceptible to mistakes. One of the most used modelling structures is the Petri-net because it let express a big set of events present in the world of the problem. YAWL is language with a syntax based on Petri-net that lets us express the control flow of manufacture systems. But concepts like resources, restrictions among tasks and resources, and restrictions among jobs and tasks can not be expressed using this language. MoLde is an extension to YAWL, adding concepts that let the modeler express resources and additional restrictions present in the world of the manufacture systems. In this work we present the language syntax and how to use the language to model some specific examples. Also we present a transformation schema of the con-cepts of MoLde to Petri-net, to be able to use the related work and some of the algorithms implemented over this structure. We show the software tools imple-mented for this project. And for the last part we include the validation process of the language.

(5)

Acknowlegements

This work was supported by the PyLO (Production and Logistics) and TICSw (Information Technologies and Software Construction) research groups of the School of Engineering of the Universidad de los Andes. Also was specially sup-ported by Prof. Dr. Rubby Casallas, Prof. Juan Pablo Caballero and Prof. David Mendez.

(6)

(7)

1

Introduction

Real world systems are complex, hard to study, hard to manipulate and when an enterprise decide to change the real system implies costs that not always make the system more efficient and productive. This is the situation where modelling is appealing to the enterprise for studying the system and its behaviour throughout changes over the model. This is applied also to manufacture systems.

A manufacture system is a process or a sequence of tasks with the purpose to produce a variety of products. This products are made using a set of limited resources and usually have a designated time to be delivered. Specifically, a flexible manufacture system (FMS) gives certain flexibility to a manufacture system in terms of resources (Can perform different tasks), in terms of product (Produce different types of products), in terms of routes (Different possible routes for the same type of product) among others[19].

In the literature we found different approaches to represent and solve manu-facture systems in [6] the author discusses the different modelling methodologies such as queuing networks, activity cycle diagrams, Petri-nets, IDEF0, object oriented modelling, and so on. Many ways of representing this problem means that the solutions can not be reused.

Among many authors Caballero proposes in [4] that is able to represent a big range of manufacture systems using Petri-nets. A Petri-net is a graphical and mathematical modelling tool that let us represent the activities, resources and restrictions of a manufacture system[13]. The petri nets are also a promising tool to describe concurrent, asynchronous, distributed, parallel, non determin-istic and/or stochastic systems[16]. Some of this characterdetermin-istics present on the flexibility of FMS making this structure suitable for representing them.

Despite the great utility of the Petri-nets, this representation has two prob-lems. First, this data structure has a low level of abstraction this makes that the concepts of a FMS are not near to the concepts of the Petri-nets. This makes that modelling with this representation consumes a lot of time and susceptible to mistakes of the modeller. Second, when modelling a small FMS, the associated Petri-net is complex, difficult to manipulate and hard to visualize.

This article has as main objective to find a representation with a higher level of abstraction that let us model FMS in a more easy way, with concepts closer for

(12)

4

the two domains. As a second objective we want to build equivalences between the proposed language and the Petri-nets to be able to use the solution methods found in the literature, specifically the one proposed by Caballero in [4].

The main contributions of this work are: first a domain specific language where we extend the YAWL language described in [7] to model FMS (MoLde). MoLde let us express the main characteristics found in a manufacture systems, the control flow among tasks, the dependence of tasks with resources and restric-tions between jobs-tasks, and between tasks-resources. Second a transformation schema that let us pass from the concepts of MoLde to concepts of a Petri-net. Third, model checking of the generated Petri-net using tools that run analysis over this structure, in this project we used TINA tool box. Fourth, the use of the solution method proposed in [4] to give solution to the scheduling problem. The validation process for MoLde was first to check the expressive capability of the language by means of different examples. Also we ask for the help of some industrial engineers (PyLO research groups) to use the proposed language with the develop tools to be able to have external retrospective over the solution. This process help us improve the tools and the proposed language. Second we check the transformation rules to the Petri-net with the purpose of checking the formation of the resulting Petri-net. For this part of the process we receive help of experts(PyLO research groups) in Petri-nets.

The rest of the document is structured as follows: Chapter 2 we introduce the reader to some basic concepts to help the audience understand the rest of the article. Chapter 3 we describe the problem we want to attack with this project and the objectives we pursue. Chapter 4 we present to the audience some related research in the context of languages for representing a FMS and how our solution differ from them. Chapter 5 we present the solution strategy. Chapter 6 we introduce the proposed workflow language its abstract and concrete syntax, some restrictions over the syntax, and the transformations rules we use to transform it to Petri-net. Chapter 7 we give a series of examples to teach the modeller how to use the language. Chapter 8 we describe the tool built to concrete the solution described in the paper and how to use it. Chapter 9 we talk about the validation process of the proposed language. Chapter 10 we talk about some conclusions and future work to guide the project.

(13)

2

Basic Concepts

2.1 Flexible Manufacture Systems

A manufacture system is a set or sequence of tasks to produce a certain product using a finite set of resources. A flexible manufacture system gives the following characteristics to a manufacture system:

• M achinef lexibility refers to the various types of operations or tasks that a certain machine can perform without requiring effort in switching from one operation to another.

• P rocessf lexibility is the ability to change between the production of dif-ferent products with minimal delay

• P roductF lexibility is the ability to change the mix of products in current production

• Routingf lexibility is the ability to vary the path of a part may take through the manufacture system

• V olumef lexibilityis the ability to vary the operation production volumes.

• Expansionf lexibility is the ability to expand the capacity of the system as needed, easily and modularly.

• Operationf lexibility is the ability to interchange sequence of the manu-facturing operations for a given part.

• P roductionf lexibility is the universe of part types that the manufacture system is able to make.

While the increased flexibility of a FMS provides a greater number of choices of resources and routes, and allows greater productivity. The challenge is to allo-cate the given set of resources to different processes or tasks required in making each product and the scheduling of the sequence of activities to accomplish the best efficiency.

(14)

6 2.2. Petri-nets

2.1.1 Formal definition for the FMS:

Indexes

iworks,j operations,k machines,estations

Sets

M machines,E stations,J jobs,

Me machines in the stations e

Oi,e operations of the work ithat has to be processed in the statione

P arameters

ai,j,k: time that takes an operationj in job j in machine kto be ready

dj: delivery date

pj,i,k: processing time of the operationj of the jobiin the machine k

A FMS is composed by a set of machines M and a set of jobs J that are go-ing to be scheduled. Each machine belongs to a unique subset Me of machines depending on the functionality of the station. Each job i is composed by a set of operations Oi,e. Each of this operations has to be done in the station e. The processing time pj,i,k of the operations can change depending one the machine where it is scheduled.

2.1.2 Assumptions

• Each jobj has a delivery date

• A job can pass through a station several times

• The machines in an stations are not necessarily equal, this means that they can have different processing times for an specific job

• Each machine is available since time zero.

• Machines do not have failures

• The processing of an operation can not be interrupted.

• There are no more jobs entering the system different from the ones known.

• The time for a machine to be ready is equal for the ones that belong to the same station

2.2 Petri-nets

A Petri-net is a particular kind of directed graph, together with an initial state called the initial marking, M0. The underlying graph is a directed, weighted,

bipartite graph. It has two kinds of nodes, called places and transitions. Arcs are either from a place to a transition or from a transition to a place.

(15)

Basic Concepts 7

A marking (state) assigns to each place a non negative integer. When a marking (non negative integer k) is assigned to a place p, it means that the place is marked with k tokens.

The marking is denoted M, an m-vector, where m is the total number of places in the graph. The element with the pth position denoted M(p), is the number of tokens in the place p.

2.2.1 Formal definition

A Petri net is a 5-tuple, P N = (P, T, F, W, M0)

• P ={p0, p1, p2, ..., pm}finite set of places

• T ={t0, t1, t2, ..., tm}finite set of transitions

• F ⊆(P×T)∪(T ×P) set of arcs

• W :F → {1,2,3, ...}weight function

• M0:F → {1,2,3, ...} initial marking

• P∩T =∅and P ∪T =∅

2.2.2 Modeling with Petri-net

In modelling, a transitions represent events and places conditions. A transition has a certain number of input and out places representing pre-conditions and post-conditions of the event. The presence of a token in a place can be interpreted as if the conditions is achieved. Another interpretation k tokens indicate k data items or resources available.

In order to simulate the dynamic behaviour of a system, a state or marking is changed according to the following rules:

• A transition t is said to be enabled if each input placep of t is market at leastw(p, t) tokens(weight).

• An enabled transition may or may not fire (depending on whether or not the event actually takes place)

• A firing of an enabled transition tremoves w(p, t) tokens from each input place pof t, and addsw(t, p) tokens to each output placep oft.

2.3 REPAG- Petri-net and Genetic Algorithms

REPAG is an genetic algorithm using the Petri-net structure to obtain the factible schedules for the problem in an specific manufacture system.This al-gorithm can be summarized in the following steps:

1. Create a initial population generated randomly. Then calculate the value of adaptation with the criteria of weighted tardiness of the jobs, J.

(16)

8 2.3. REPAG- Petri-net and Genetic Algorithms

2. If there arekidentical individuals, the value of adaptation is penalize with

k−l of them with a high value so that the dominant genes can not cause early convergence.

3. Assign the probability to be choose to every individual in the population. 4. Select pair of individuals in the population by the probabilities of step 3. Apply the strategy of reproduction and calculate the adaptation value with the criteria of weighted tardiness.

5. Choose the best individuals between father and sons, the ones with better adaptation values.

6. Choose the genes of the individuals that are going to go through the process of mutation.

7. If the number of generations is reached the algorithm finish and return the actual population, in the other case go to step 2.

(17)

3

Problem

Real world systems are complex, hard to study, hard to manipulate and when an enterprise perform changes over the real system implies costs that not always make the system more efficient and productive. This is the situation where modelling is appealing to the enterprise for studying the system and its behaviour throughout changes over the model. This is applied also to manufacture systems. In the literature we found different forms for modelling a flexible manufac-ture system. In [6] the author discusses some of modelling methodologies used. Having different ways for the representation of the same problem makes that the solution found can not be reused, this means that a solution in an specific repre-sentation can only be compared to another solution(different reprerepre-sentation) by means of the value of the objective function. The concepts in each representation are different and sometimes are not equivalent. This makes relevant to find a representation where we can model a big range of manufacture systems.

Among other authors in [4] the author proposes that this representation is the Petri-net. We discuss in the last section some of the great characteristics that this representation has and that make it suitable for the representation and solution of this kind of systems. But this representation has two big problems, first its low level of abstraction this means there is a gap between the concepts of a flexible manufacture system and the concepts of a Petri-net, and the equivalence between them is not intuitive. This makes the process of modelling a manufacture system time consuming and susceptible to mistakes. The second problem is the complexity of the structure, for a small instance of a manufacture system the associated Petri-net is complex, hard to manipulate and hard to visualize.

Although we don’t want to use the Petri-nets for the modelling of manufac-ture systems; we want to include the solution schema of [4] to solve the scheduling problem. This means the problem is to create a high level language to help with the modelling of a flexible manufacture system. With an associated chain of transformation to Petri-net with the purpose of using the solution schema pro-posed in [4] using this representation and be able to study the system in a more appealing way for the modeller and the enterprise.

If we give a modeller a more intuitive language to express the desire system, this means an improvement in the process of modelling making it faster and less

(18)

10 3.1. Objectives

susceptible to mistakes.

3.1 Objectives

• Improve the modelling process of a industrial engineer when he wants to study a manufacture system by means of a domain specific language.

• Search for work-flow languages that let us express some of the character-istics present in manufacture systems to help us define a domain specific language.

• Define transformation rules over the proposed language to be able to gen-erate a Petri-net that contains the information expressed in the language.

• Include the solution schema of [4], based on a genetic algorithm over the Petri-net to give a good solution to the scheduling problem for the desire system.

• Validate the proposed language with real manufacture system examples.

• Validate the proposed transformation schema with experts in Petri-net and integrate tools for checking the generating net.

(19)

4

Related Work

4.1 Modelling Representations and Algorithms

Flexible manufacture systems is an interesting topic in industrial engineering. That’s why many authors have been modelling them with alternative represen-tations and some of them solving the scheduling problem with algorithms over the proposed representation. In [6] the author discusses about the current modelling methodologies used in flexible manufacture systems, such as queuing networks, activity cycle diagrams, IDEF0, Petri-nets, object-oriented methodologies, and so on.

4.1.1 Activity cycle diagram

An activity cycle diagram represents the changes of system status in a graphical manner, whereby taking advantage of the understanding and analysing manu-facturing system. However, the activity cycle diagram does not represent the relationship between conditions and events in the discrete events dynamic sys-tem.

4.1.2 IDEF0

IDEF0 is a modelling methodology for designing and documenting a hierarchic, layered, modular system. The IDEF0 methodology has been widely used [9]. The building block of this modelling approach is the activity box. The activity box defines a specific activity in the organization that is being modelled. Four types of arrows are associated with an activity box. They are input, output, control and mechanism, respectively. Inputs are items (e.g. material, information) that are transformed by the activity. Outputs are the results of the activity acting on the inputs. A control is a condition that governs the performance of the activity. A mechanism is the means by which an activity is realized. An activity box can be further broken down into several sub-activities. Nevertheless, the disadvantage of IDEF0 methodology is its static nature, that is, it can only represent the static behaviour of a system.

(20)

12 4.2. TimeNET

4.1.3 Petri-net

Petri-nets are a formal graphical model for the description and analysis of systems that exhibit asynchronous, concurrent properties. Petri-nets and their variations, such as coloured Petri-nets and timed Petri-nets, have been widely applied to model, control and analyse the system’s dynamic behaviours due to the char-acteristics of the graphical representation and mathematical analysis of control logic. A large number of Petri-net approaches to modelling and control of dis-crete manufacturing systems have been described in the literature, including [21], [11], [22], [13], [4], [5], among many others.

4.1.4 Object-oriented modelling

Object-oriented (O-O) technology is a new paradigm for modelling manufactur-ing systems and it has become widely used in application software development [12] [18]. The O-O modelling technique provides a one-to-one correspondence between the entities in a real system and the objects in its model that represent them. It possesses high modularity, maintainability, and reusability.

4.1.5 Heuristics

Flexible manufacture system and its associated scheduling problem has been extensively studied with different approaches, exact and heuristic approaches. This approaches changes in the representation the author use and the heuristic approach to solve the scheduling problem. Some of them use permutation vector with tabu search (with variations in the heuristic) [1], [15], [3], [8], [25], other use simulated annealing [8], [25] and [24]. Other representation are graphs and the authors use different methods of the graph theory with other heuristics to attack the scheduling problem [14], [2] and [10].

4.2 TimeNET

TimeNET is a software tool for the modeling and performability evaluation using stochastic Petri-nets. Its two main characteristics are the evaluation of models with non exponentially distributed firing delays and the ability to model and evaluate complex colored stochastic Petri-nets [26].

Although TimeNet is an amazing tool to evaluate stochastic and colored Petri-nets and incorporates an editor to make the process of modelling easier, as we discussed earlier the Petri-net representation has a low abstraction level that makes the modelling process time consuming and susceptible to errors. Other issue of this tool is that the solution approach(solution method that we want to include) proposed in [4] don’t use stochastic Petri-nets for the problem representation. And also this tool evaluates certain characteristics of the Petri-net that is another complex problem that we don’t want to solve with this work.

4.3 YAWL

YAWL is a open-source work-flow system with its own work-flow language def-inition that captures all sorts of flow dependencies between tasks. YAWL is

(21)

Related Work 13

based on Petri-nets but extended with additional features to facilitate the mod-elling of complex work-flows. This system is used a tool to model or represent business process. The author exposes different patterns in [7] to illustrate the ”expressiveness” of the proposed work-flow language.

Although YAWL is a very develop language in the business process man-agement and also can be represented in a Petri-net, when we begin modelling manufacture systems with this language we find different problems or limitations in the concepts of the language that didn’t let us represent the desire systems. Between the issues found are: the association of resources to the tasks, the as-sociation processing times to the tasks, multiple instances tasks with different times and resources, triggers to other nets, among others. This make us think that YAWL language is a good start point but its concepts most be extended to represent the object of our study (flexible manufacture systems).

Van der Aalts base his language on Petri-nets with timed transitions as we discussed earlier we integrate the work of [4] to the proposed solution but he based his solution on Petri-nets with timed places, what makes us restructure the transformations to Petri-nets that Van der Aalts made for his language.

(22)

(23)

5

MoLde: Proposed Language

5.1 Strategy

Through out the bibliographic revision we found that the concepts present in the work-flow languages let us describe the flow restrictions among tasks present in a manufacture system. Among those work-flow languages we find BPMN and YAWL. Although BPMN is one of the most used workflows language to describe business process, and have a lot of tools the helps with the model and execution of the model, we decide to use YAWL(Yet another workflow language) in this project because is a well develop language, it´s syntax is based on Petri-nets, and some the patterns described by Van der Aalts in [20] are present in manufacture systems. The main issue with this language is that doesn’t represent all the concepts and restrictions present in a flexible manufacture system.

This is the reason why our strategy consists in extending the YAWL work-flow language with the concepts that are needed to express a complete manufacture system. Change the transformation rules in YAWL to Petri-net to incorporate the new concepts. And be able to construct tools to model the desire system, validate the constructed diagram, transform it to a Petri-net, and check the generated Petri-net. In this section, we will talk about the proposed language, its abstract and concrete syntax.

5.1.1 Abstract Syntax

In Figure 1 we can see the abstract Syntax of the proposed language. Here we explain each of the concepts in of the language:

• System: Represent the manufacture system. A manufacture system typi-cally has some resources and some sub-nets.

• Sub−net: Represent a set of tasks to produce a certain type of product. A sub-net has certain elements and transitions over this elements.

• Resource: Represent a person or machine that is needed to perform a set of tasks.

(24)

16 5.1. Strategy

• Element: Represent either a task or condition that is needed on a sub-net.

• T ransition: Represent a connection between to elements.

• Condition: Represent a condition to be able to perform a task.

• InputCondition: Represent a initial condition for a sub-net to begin. A trigger can call the condition to the begin the sub-process.

• T rigger: Represents a start for other sub-nets (input conditions) that can be done in parallel after an specific task.

• OutputCondition: Represent a final condition for a sub-net to finish.

• T ask: Represent an operation or set of operations that are needed in the process to create a type of product.

• Atomic T ask: Represent a single operations in the process to create a type of product. An atomic task needs a resource to be done. The task can have a processing time that is the duration of the operation. This operation can have a setup time associated to the resource that is using and this setup time can be done before or after the job arrives. And also it can have a percent of completion the language, this means that is not necessary to finish all the task to let the process continue.

• M ultiple Instance T ask: Represent a single operations that can be per-formed in parallel. This means that the manufacture system has the capa-bility to perform this operation with a set of resources (Different Instances).

• Instance: Represent a specific instance of the multiple instance task. Each instance has a processing time, setup times, percent of completion and an associated resource where it is performed.

• Composite T ask: Represent a set of operations in the process to create a type of product. A composite tasks has a associated sub net that specifies the order and transitions of the set of operations.

• AN DJ oin: It can be used with any task concept. Represent that the task have to wait all the task that are connected to it to finish to start.

• AN DSplit It can be used with any task concept except. Represent that the task activate a series of tasks.

• XORJ oin It can be used with any task concept. Represent that the task can begin whenever one of the tasks connected to it finish.

• XORSplit It can be used with any task concept. Represent that the task can activate some of the following tasks.

• LagRepresent a processing time that has to be done between two elements of the system.

(25)

MoLde: Proposed Language 17

Figure 5.1 Language Metamodel

5.1.2 Concrete Syntax

In Figure 2 we can see the concrete syntax of the abstract syntax explained in last section. Its based on the elements present in YAWL editor developed by Van der Aalts[7].

We can clarify that a system is represented by a box with two sections. The first section is for the resources of the system. And the second section is for the sub nets of the system. A sub-net is another box with only one section, this section is for the different tasks, conditions and transitions between them. In the figure is not clear that the transitions between elements are arrows between them.

The tasks have different properties between them is the processing time and the resource that is going to perform the task. This characteristics are not represented visually, are present in the section of properties of the editor of the specific element. In the section of tools we talk more about the editor.

The only particular task that is different from the other elements is the multiple instance task where the instances are represented with small boxes around the figure that represent the main concept.

5.1.3 Example

In figure 3 we can see an example which illustrates the concrete syntax with a process of a company that makes bread, is a simplify version of the system with only one type of product. This example is taken from [17]. The general production system can be explained in the nest steps:

1. F ormulation: The process begins when the worker in charge of the mixture add the raw material and the special ingredients of the type of bread that they are going to produce.

2. M ixture: At the end of step 1 the mixture process begin, as a result of this process we obtain a raw mass. The processing time of this operation

(26)

18 5.2. Syntax Restrictions

Figure 5.2 Concrete Syntax

depends on the type of mass.

3. M ass growth: The raw mass is put to rest for 30 min, the objective of this step is for the mass to grow.

4. M ass f latten: In this step a machine gives the final texture required for the mass. The processing time of this step is of 6 minutes.

5. Cut and bread f orm: In this step the mass is cut and depending on the type of bread they are making they give a certain form. Depending on the type this process is manual or automatic. For the purpose of this example we considered an automatic approach.

6. Bread Growth: In this step the bread is taken to a room with an special environment to let it grow.

7. Baked: In this step the bread is baked in one of the ovens that the company has.

8. Cooling: In this step they wait 30 minutes for the bread to cool down. 9. Bread P acking: In this step the bread is packed and stored.

5.2 Syntax Restrictions

This language have the following restrictions in the use of its concepts. 1. A sub-net most have one input condition element.

(27)

Figure 5.3 Example

3. A input condition can not have input arcs. 4. A input condition most have one output arc. 5. An atomic task most have one input arc. 6. An atomic task most have one output arc.

7. A multiple instance task most have one input arc. 8. A multiple instance task most have one output arc. 9. A composite task most have one input arc.

10. A composite task most have one output arc. 11. A lag task most have one input arc.

12. A lag task most have one output arc. 13. A trigger most have one input arc. 14. A trigger most have one output arc.

15. An and join can have more than one input arc. 16. An and join most have one one output arc. 17. A xor join can have more than one input arc. 18. A xor join most have one one output arc. 19. An and split most have one input arc.

20. An and split can have more than one output arc. 21. A xor split most have one input arc.

22. A xor split can have more than one output arc. 23. Is not allowed a transition between two xor splits. 24. Is not allowed a transition between two xor joins.

(28)

20 5.3. Transformations Rules

25. Is not allowed a transition between two and split. 26. Is not allowed a transition between two and joins.

27. Is not allowed a transition having an input condition at the end of it. 28. Is not allowed a transition with an output condition at the beginning of it. 29. Is not allowed a transition between an and split and a xor join.

30. Is not allowed a transition between an and split and a xor split. 31. Is not allowed a transition between an and split and an and join. 32. Is not allowed a transition between a xor join and an and split. 33. Is not allowed a transition between a xor join and an and join. 34. Is not allowed a transition between a xor join and a xor split. 35. Is not allowed a transition between a xor split and a xor join. 36. Is not allowed a transition between a xor split and an and split. 37. Is not allowed a transition between a xor split and an and join. 38. Is not allowed a transition between an and join and an and split. 39. Is not allowed a transition between an and join and a xor split. 40. Is not allowed a transition between an and join and a xor join.

5.3 Transformations Rules

One of our objectives of this work is to use the solution schema worked on Petri Nets. Specifically the work of Juan Pablo caballero [4] where he give a factible solution to the scheduling problem by means of a genetic algorithm on the Petri net. This is the reason to create some transformation rules from the work-flow concepts defined in our proposed language to the petri net concepts. In the following section we will explain this rules of transformation in more detail.

5.3.1 Independent Input Condition

In figure 4 we can see the transformation of an independent input condition to Petri net concepts. It consists in a timed place (place with time zero or different depending on the release time) with 0 to n initial tokens (number of initial parts), connected with a transition (where it receive the tokens from triggers) and the transition connected with another immediate place.

(29)

5.3.2 Output Condition

In figure 5 we can see the transformation of an output condition to Petri net concepts. It consists in a transition, a immediate place with no tokens and an arc between them.

Figure 5.5 Transformation for Output Condition

5.3.3 Resource

In figure 6 we can see the transformation of a resource to Petri net concepts. It consists in a place with one token.

Figure 5.6 Transformation for Resource

5.3.4 Atomic Task - Setup Time = 0 and Percent Completion

= 100

In figure 7 we can see the transformation of an atomic task with a setup time of zero and a percent of completion of 100 to Petri net concepts. It consists in a transition connected with a timed place (place with time different to zero), this timed place connected with another transition and this transition connected with an immediate place (place with time zero) .

Figure 5.7 Transformation for Atomic Task

In figure 8 we can see the transformation of a the same atomic task with an associated resources. It consists in the two transformations of resource and atomic task with two additional transitions. The first one from the place of the resource to the initial transition of the atomic task. The second one from the final transition of the atomic task to the place of the resource.

(30)

5.3.5 Atomic Task - Setup Time = 0 and Percent Completion<

100

In figure 9 we can see the transformation of an atomic task with a setup time of zero and a percent of completion below 100 to Petri net concepts. It consists in a transition connected with a timed place (place with time of the percent of completion times the processing time - PART A), this timed place connected with another transition. This transition connected with an immediate final place (place with time zero) and connected with another timed place that corresponds with the rest of the processing time (PART B). And this last timed place is connected to a transition(connected to the resource) and this transition to a immediate place.

Figure 5.9 Transformation for a Atomic Task - Setup Time = 0 and Percent Completion

<100 with resource

5.3.6 Atomic Task - Non Anticipated Setup Time > 0 and

Per-cent Completion = 100

In figure 10 we can see the transformation of an atomic task with a non antici-pated setup time different from zero and a percent of completion equals to 100. It consists in a transition connected with a timed place (place with setup time), this timed place connected with another transition. This transition connected with another timed place that corresponds with the processing time of the task. And this last timed place is connected to a transition (connected to the resource) and this transition to a immediate final place.

Figure 5.10 Transformation for a Atomic Task - Non Anticipated Setup Time>0 and Percent Completion = 100 with resource

5.3.7 Atomic Task - Non Anticipated Setup Time > 0 and

Per-cent Completion < 100

In figure 11 we can see the transformation of an atomic task with a non antici-pated setup time different from zero and a percent of completion equals to 100. It consists in a transition connected with a timed place (place with setup time), this timed place connected with another transition. This transition connected

(31)

with another timed place that corresponds with the processing time times the percent of completion (PART A) of the task. The timed place is connected to a transition that is connected with an immediate final place (place with time zero) and connected with another timed place that corresponds with the rest of the processing time (PART B). And this last timed place is connected to a transition(connected to the resource) and this transition to a immediate place.

Figure 5.11 Transformation for a Atomic Task - Non Anticipated Setup Time>0 and Percent Completion <100 with resource

5.3.8 Atomic Task - Anticipated Setup Time > 0 and Percent

Completion = 100

In figure 12 we can see the transformation of an atomic task with an anticipated setup time and a percent of completion equals to 100. It consists in a transition connected with a timed place (processing time), this time is connected with a transition and then with a immediate place. The setup time is represented with the transition and timed place that are connected with the place of the resource. As we can see the setup time can be done before the task begins.

Figure 5.12 Transformation for a Atomic Task - Anticipated Setup Time>0 and Percent Completion = 100 with resource

5.3.9 Atomic Task - Anticipated Setup Time > 0 and Percent

Completion < 100

In figure 13 we can see the transformation of an atomic task with an anticipated setup time different from zero and a percent of completion below 100 to Petri net concepts. It consists in a transition connected with a timed place (place with time of the percent of completion times the processing time - PART A), this timed place connected with another transition. This transition connected with an immediate final place (place with time zero) and connected with another timed place that corresponds with the rest of the processing time (PART B). And this last timed place is connected to a transition(connected to the resource) and this transition to a immediate place. The setup time is represented with the transition and timed place that are connected with the place of the resource.

(32)

Figure 5.13 Transformation for a Atomic Task - Anticipated Setup Time>0 and Percent Completion<100 with resource

5.3.10 Transition

The transition transformation consists in making an arc between the last place of the transformation of the source object and the first transition of the trans-formation of the target object. As we can see in figure 14.

Figure 5.14 Transformation for a Transition

As an example in figure 15 we can see the transformation of transition be-tween two Atomic Task connected with a transition. As we can see the last place of the first atomic task is joined with an arc with the first transition of the second atomic task.

Figure 5.15 Transformation for a Transition between two Atomic Task

5.3.11 Trigger

In figure 16 we can see the transformation of a trigger. It consists in in a transition, a immediate place with no tokens and an arc between them. The place is connected (arcs) with all the transitions of the input conditions that this element has associated. This connection consists in an arc that connects the transition of the trigger transformation with the first place of the transformation of the input condition.

(33)

5.3.12 Multiple Instance task

In figure 17 we can see the transformation of a multiple instance task, this element only has two instances. It consists in transition connected with a immediate place. This place is connected with all the initial transitions of the instance of the task. For every instance we have a initial transition connected with a timed place, and the timed place connected with a final transition. And each of the final transition of the instance of task is connected to a final immediate place. Each instance can have a different processing time, a different resource, a setup time (anticipated or non anticipated) and a percent of completion.

Figure 5.17 Transformation for a multiple instance

5.3.13 And Join

In figure 18 we can see the transformation of an and join, the transformation of the and join is basically a transition connected with a non timed place. To connect this transformation with a previous elements like B and C we have to draw an arc from the last place of the transformation of B to the transition of the and join, and from the last place of the transformation of C to the transition of the and join. And to connect this transformation with a posterior element like A we have to connect an arc from the place of the and join to the first transition of the transformation of A.

Figure 5.18 Transformation for and join

5.3.14 And Split

In figure 19 we can see the transformation of an and split, the transformation is basically a transition. To connect this transformation with a previous element like A we have draw an arc from the last place of A with the transition of the and split. And to connect this transformation with posterior elements like B or C we have to draw an arc from transition of the and split to a new place(simultaneous start) and then draw another arc from this place to the first transition of the

(34)

transformation of B. And the same thing with C draw an arc from the transition of the and split to a new place(simultaneous start) and then draw another arc from this place to the first transition of the transformation of C.

Figure 5.19 Transformation for and split

5.3.15 Xor Join

In figure 20 we can see the transformation of a xor join, the transformation is basically a non-timed place. To connect this transformation with previous elements like B and C, we draw an arc from the last place of B to a new transition (only one task needs to finish to start the next one) and then draw another arc from this transition to the place of the xor join. And the same thing with C draw an arc from the last place of C to a new transition (only one task needs to finish to start the next one) and then draw another arc from this transition to the place of the xor join. To connect this transformation with a posterior element like A we have to draw an arc from the place of the xor join to the first transition of the transformation of A.

Figure 5.20 Transformation for xor join

5.3.16 Xor Split

In figure 21 we can see the transformation of the xor split, the transformation is basically a transition connected with a non-timed place. To connect this transformation with a previous element like A we have to draw an arc from the last place of the transformation of A to the transition of the xor split. To connect this transformation with posterior elements like B and C we have to draw an arc from the place of the xor split to the first transition of the transformation of B and also and we draw an arc from the place of the xor split to the first transition of the transformation of C.

(35)

Figure 5.21 Transformation for xor split

5.3.17 Lag

In figure 22 we can see the transformation of the lag task, the transformation consist in a transition connected with a timed place. The lag is a time that no resource process, the input parts are how many parts pass through the lag, in the transformation the input parts are the weight of the arcs that comes to the transition of the transformation and the arc that goes from the transition to the timed place.

Figure 5.22 Transformation for lag task

5.3.18 Composite Task

The composite concept is a phantom concept, it doesn’t have an actual trans-formation. The only transformation are the arcs that this concept has with a previous element and with a posterior element. The arc with the previous ele-ment corresponds to an arc between the last place of the transformation of the previous element and the first transition of the transformation of the input task of the sub-net which the composite task references. And the arc with the poste-rior element corresponds to an arc between the last place of the transformation of the output condition of the sub-net which the composite task references and the first transition of the transformation of the posterior element.

(36)

(37)

6

Case Style

This chapter is divided in different sections, in each of them we introduce a series of concepts of the proposed language, we illustrate how to use this concepts to represent a specific manufacture system and how they are transformed to a Petri-net.

6.1 Sequential manufacture systems

6.1.1 Process to manufacture a shovel

Assume in this example that we have all the parts that are needed to manufacture a shovel. The tasks of manufacturing process are:

1. Support of the handgrip assembly: This task is made by a worker and is made in a period of 15 minutes. This task is independent from others. 2. HandGrip assembly: This task is made by a worker and it consists in

putting together the support of the handgrip with the handgrip. This task is made in a period of 15 minutes. Before performing this task is necessary to finish the assembly of the support of the handgrip.

3. Scoop assembly: This task is made by a worker and it consists in putting together the parts that conform the scoop of the shovel. This task is made in a period of 20 minutes. This task is independent from others.

4. Shovel assembly: This task is made by a worker and consists in putting together the handgrip and the scoop. Before performing this task is nec-essary to finish the handgrip assembly and the scoop assembly. This task is made in a period of 20 minutes

6.1.2 Simple sequence

Lets assume that we only have a worker and we have to make the process, each task after the other (1-2-3-4). The associated representation using the proposed language is shown in Figure 7.1.

(38)

30 6.1. Sequential manufacture systems

Figure 6.1 Simple Sequence Process

Taking into account the transformation rules of the last chapter, the associ-ated Petri-net of this process is shown in Figure 7.2.

Figure 6.2 Transformation for a Sequential Process

6.1.3 And Join/Split

Now lets assume that we have another worker and we can make tasks in parallel. In the process of making the shovel the only task that can be performed in parallel is the scoop assembly because it is independent from others. The handgrip assembly goes always after the assembly of its support. And the shovel assembly go after all the operations. The associated representation for this process is shown in Figure 7.3.

Figure 6.3 Parallel Process

As we can see the element and split let us start a series of tasks in parallel, and the and join let us wait for a series of tasks to finish before beginning the next task. In this case the shovel assembly depend of both the scoop and the handgrip assembly. Taking into account the transformation rules of the last chapter, the associated Petri-net of this process is shown in Figure 7.4.

6.1.4 Xor Join/Split

Lets add a new task to our manufacture process P aint the shovel, this task is made by a worker and consist in painting the shovel with a determined color

(39)

Case Style 31

Figure 6.4 Transformation for Parallel Process

(red, blue or yellow). But a shovel only can be painted with one color, therefore exists three different tasks P aint the shovel blue, P aint the yellow and P aint the shovel red. The shovel only passes for one of this tasks. This task can only be performed after the shovel assembly.

With this new addition the associated representation for this process is shown in Figure 7.5

Figure 6.5 Optional Process Example

As we can see the element xor split let us start one of a series of tasks, and the xor join let us wait for only one of the previous tasks to begin with the next task. In this particular case when one of the painting process finish the manufacture system ends. Taking into account the transformation rules of the last chapter, the associated Petri-net of this process is shown in Figure 7.6.

Figure 6.6 Transformation for Optional Process Example

6.2 Resources

As we expect each of this tasks have a resource (machine or person) that perform the specific activity. Lets return to the example of Figure 7.1 where exist only one resource that is shared among the 4 tasks. The complete diagram that represent this system is shown in figure 7.7. The link between the task and the resource is done in the properties of the task where we can choose over the resources of the system. As we can see the system is separated in two the first part is form the resource of the system and the second parts are for the sub-nets that represent the different processes of the system.

(40)

32 6.3. Multiple instance tasks

Figure 6.7 Resource Example

Taking into account the transformation rules of the last chapter, the associ-ated Petri-net of this process with the addition of the resource is shown in Figure 7.8.

Figure 6.8 Resource Transformation Example

6.3 Multiple instance tasks

In this section we will introduce a new type of task, the multiple instance task. Lets return to the example of the section 7.1, lets assume that the system has two workers and that the task Hand Grip Assembly and Shovel Assembly can be made by either one of them, but we now that the worker 1 can finish the Hand Grip Assembly in 20 minutes and the worker 2 in 15 minutes. For the Shovel Assembly the the two workers performed it in 20 minutes. To represent this kind of tasks we can use the xor join/split of section 7.1.4 or we can use the multiple instance task(compact and easier form). A multiple instance task can have several instances and for each of this ones we can specify the resource and the processing time. The diagram for this manufacture system is shown in Figure 7.9. As we can see the instances are the little boxes beneath the task.

Taking into account the transformation rules of the last chapter, the associ-ated Petri-net of this manufacture system is shown in Figure 7.10.

(41)

Case Style 33

Figure 6.9 Multiple Instance Example

Figure 6.10 Multiple Instance Example Transformation

6.4 Subprocesses

In this section we will introduce two concepts to reference another process. The composite task and the trigger, the composite task let us express that a process is composed of smaller processes that are linked together in an other, for example if we have to manufacture a pen, first we have to manufacture the ink then the body and then the head of the pen. Lets assume that making the body is more complex and has associated a manufacture process, with this concept we can express this.

The trigger let us express that in a step of the manufacture we can start in parallel another process. For example in making bread after taking the bread out of the oven we can pack the bread but also we can star with the next type of bread. This means that the process of making the next type of bread can be done in parallel with the packing of the previous type of bread.

(42)

34 6.4. Subprocesses

6.4.1 Composite Task

Lets return to the example of Figure 7.1 where exist only one resource that is shared among the 4 tasks. Lets assume that the Hand Grip Assembly is a more complex process that consist in the following tasks:

• J oin support and hand grip with nails: This task is made by a worker, it takes among 7 minutes to finish it.

• Apply Glue: This task is made by a worker, it takes among 5 minutes to finish it. This task goes after the joining the support and the hand grip with nails.

• Dry of the piece: This tasks is made by a worker, it takes among 7 minutes to finish. This task goes afters applying the glue.

The diagram for this manufacture system taking into account this new process for the hand grip assembly is shown in Figure 7.11. In the figure is not clear how the relationship between the sub-nets, in the properties are for the composite task there is a reference to a sub-net, and this is where we specify the subprocess.

Figure 6.11 Composite Example

Taking into account the transformation rules of the last chapter, the as-sociated Petri-net of this manufacture system is shown in Figure 7.12. The transformation of the box represents the transformation for the subprocess.

6.4.2 Triggers

Lets return to the example of Figure 7.1 where exist only one resource that is shared among the 4 tasks. Lets assume between the scoop assembly task and the shovel assembly we can perform in parallel the assembly of other kind of shovel the following three steps(with another worker specialized to make this kind of shovel):

(43)

Case Style 35

Figure 6.12 Composite Example Transformation

• Scoop Assembly: Different from the other type of shovel, the hand grip is made from plastic and we don’t need to build it up. This tasks is made by a worker and consists in putting together the parts that conform the scoop of the shovel. This task is made in a period of 25 minutes.

• Shovel Assembly: This task is made by a worker and consists in putting together the handgrip and the scoop of the shovel.This task is made in a period of 15 minutes.

• Chrome painting: This task is made by a machine and consists in painting the shovel with a chrome ending.This task is made in a period of 15 minutes The diagram for this manufacture system taking into account this new type of shovel is shown in Figure 7.13. In the properties of the trigger concept we can add various input conditions that we want to start in the desire point of the system.

Figure 6.13 Trigger Example

Taking into account the transformation rules of the last chapter, the associ-ated Petri-net of this manufacture system is shown in Figure 7.14.

(44)

36 6.4. Subprocesses

(45)

7

Implementation

In this chapter we describe the different tools we implemented for this work (set of plugins for eclipse IDE).

7.1 Language and editor

The metamodel of the proposed language was develop in EMF. We define syntax restrictions for this metamodel with OCL (for more information go to chapter 2) to help the modeler verify what he can do with the language. The editor for this language was develop with Eugenia, Eugenia let use generate plugins for the editor, language and tests over them. The figures used on the editor that represent each of the concepts defined on the concrete syntax are implemented in another plugin of eclipse.

7.2 Transformation

For the transformation from the MoLde concepts to the Petri-net concepts was implemented in ATL. We also develop a plugin that adds an option to the eclipse IDE menu to execute this transformation and generate the model of the Petri-net in the eclipse selected workspace.

7.3 Other generated files

In the plugin that executes the transformation we develop a function that receives as input the generated model of the Petri-net and generate two files. The first file is a file for a toolkit of Petri-nets (TINA) that lets us visualize the generated Petri net, execute some structural analysis and use a step simulation in the Petri net. We can clarify that all the characteristics of the generated Petri-net are not present in the tina file, in specific the times of the transitions because this toolkit don’t support this characteristic. The second file is a CSV file with a matrix representation of the generated Petri-net. This file is structured as follows

(46)

38 7.4. How to use the plugins?

This CSV file is used as input for the genetic algorithm defined by Juan Pablo caballero in [4].

7.4 How to use the plugins?

1. Create an empty project en eclipse. Name the new project.

Figure 7.1 Create Empty Project

(47)

Implementation 39

2. Create a manufacture system diagram. Name the new diagram.

Figure 7.3 Create New Diagram

Figure 7.4 Name New Diagram

(48)

40 7.4. How to use the plugins?

3. Model the desire manufacture system with the proposed language.

Figure 7.6 Model Manufacture System

4. Validate syntax of the diagram.

Figure 7.7 Validate Syntax

5. Execute the transformation.

Figure 7.8 Execute Transformation

(49)

Implementation 41

Figure 7.9 Result Transformation

6. Check the generated Petri-net with TINA.

Figure 7.10 Open TINA file

(50)

(51)

8

Validation

In this chapter we describe the validation process that consists in two parts. The first part is to check the transformation rules to the Petri-net with the purpose of checking the formation of the result Petri-net. This first part of the process we receive help of an expert in Petri-nets.

The second part was to model a set of manufacture systems with the proposed language to see the expressive capability of the concepts. In this section of this chapter we show a couple of examples. And at last we ask help of some industrial engineers (PyLO research groups) to use the proposed language with the develop tools to be able to have external retrospective over the solution. This process help improve the tools and the proposed language.

8.1 Transformation Rules Validation

In this part of the validation we consult an expert on Petri-nets to extend the transformation rules for the new concepts we want to include in the language. After the implementation of this new rules we created basic examples with the proposed language, this examples had a valid syntax so we can execute the transformation rules. Then we took the Tina file generated and use the tools of TINA to make structural analysis, step simulations, and check visually the Petri-net. We make a lot of this iterations validation different rules, rules for concepts or rules for the arcs between them.

8.2 Language Expressiveness Validation

In this section we introduce two examples that we use two validate the expres-siveness of the language. The first example was used at the beginning of the project to look for new concepts, and see the transformation rules of the basic ones. The second example was used at the end of the project, its described in [23]. This last one is a really complex manufacture system because of the amount of restrictions are present in it.

(52)

44 8.2. Language Expressiveness Validation

Figure 8.1 TINA Petri-net

Figure 8.2 TINA TINASimulator

8.2.1 Fabrication of injection moulds

For the first part of the project we choose among the diversity of complex man-ufacturing systems, the ones whose main goal is the production of tools for the fabrication processes in other industries. Such is the case of the fabrication of injection moulds, which is a support industry for almost all companies that use injected components either as final product or as semi-finished products. In [5] the authors uses Petri-nets and genetic algorithms to describe and optimise the production environment.

We validate the proposed solution with the one of the authors of [5]. We begin modeling a small instance of the manufacture system that fabricates injection moulds with a Petri-Net. The result is shown in the figure 15.

(53)

Validation 45

The next step was to model the same instance with the proposed language, to test the expressive capability of the proposed languages. The result is shown in figure 16.

Figure 8.4 Problem instance using proposed language

In this point we can see the benefits of the proposed language, is really simple to model a system with this language. The result representation is simple and easy to manipulate.

Then next step was to validate the generated Petri-net with the original one(figure 15). The generated Petri-net is shown in figure 17.

Figure 8.5 Generated Petri Net

Although the associated Petri-net is bigger than the original one, the two nets are equivalent and we are not changing the behaviour of the original system. In the transformation we add some transitions and places to make it easier to define the transformation rules. During this process we add the concept trigger.

8.3 Ceramic Tile production

8.3.1 Case of Study

This case of study deals with a specific scheduling system in the Spanish ceramic tile sector. The fist step of the process is the molding where the atomized clay

(54)

46 8.3. Ceramic Tile production

powder is loaded into molds (here is where the fluidity of the atomized clay plays an important role) and it is pressed by large hydraulic presses to form what is called the bisque. This process is very important as all further operations depend on the correct formation of the tile. The physical dimensions of the tile, often referred to as the format of the tile, depend on the characteristics of the mold employed. Additionally, the visible side of the tile might not be entirely flat as it might have a ‘stone-like’ pattern. This is determined by the plate of the mold. Right after molding, the bisques are quite fragile and should undergo further drying. This process is usually carried out in either vertical or horizontal dryers (small kilns). After drying, the bisque is hardened to what resembles a chocolate bar and therefore, can withhold further processing operations. The bisque or ceramic tile is then decorated in the glazing lines. Some specific products are not glazed, however, this is not very common. In a glazing line, tiles move over conveyor belts and different applications, decorations and other operations are performed over them. The most basic operation is the application of the base glaze by simple bell or waterfall machines to advanced random rotary decora-tions, referred to as rotocolors. Modern glazing equipment includes ‘printers’ which can basically print ceramic tiles with a large array of colours, patterns and decorations. Glazing lines can contain more than 50 different machines and can be up to 50m long, sometimes even more. The different glaze applications determine the style, colour, surface and characteristics of the tile.

Decorated bisques are stored in big boxes or ‘roller stillages’ that contain many roller planes where bisques are fed into, stored and extracted from at later stages. The big boxes are transported from the glazing lines to an intermediate storage area by automated guided vehicles (AGVs).

The central stage of the production process is the single kiln firing. Ceramic kilns are large horizontal ovens with usually a single plane of rollers that move in one direction, advancing the glazed bisques through the different stages. Each type of clay and tile follows a different temperature curve inside the kiln. This temperature might be also affected by the physical size or format of the tile. A number of physical and chemical reactions undergo inside the kiln to form a hardened and finished tile. Most notably, the glaze fuses and hardens on top of the tile, conferring most known and desired characteristics of ceramic tiles.

Summary

We can summary the stages of this manufacture system in 3.

1. Mold and Drying: Have two machines that can perform this task. 2. Glaze: Have two machines that can perform this task.

3. Single kiln firing Have two machines that can perform this task.

Additional Restrictions for the stages

• Each stage has m parallel machines that are unrelated. Meaning that the processing time for a job depends on the machine it has been assigned to.

• Stages has setup times (time to prepare the machine an depends on the job the machine is assigned to). An example of this is when the production of a given ceramic tile with a format of 33 × 33 cm. is finished, a very