Institutionen för systemteknik

Transcription

1 Institutionen för systemteknik Department of Electrical Engineering Examensarbete Automatic Generation of Control Code for Flexible Automation Examensarbete utfört i Elektroteknik vid Tekniska högskolan vid Linköpings universitet av Andreas Svensson LiTH-ISY-EX-ET--12/0400--SE Linköping 2012 Department of Electrical Engineering Linköpings universitet SE Linköping, Sweden Linköpings tekniska högskola Linköpings universitet Linköping

2

3 Automatic Generation of Control Code for Flexible Automation Examensarbete utfört i Elektroteknik vid Tekniska högskolan vid Linköpings universitet av Andreas Svensson LiTH-ISY-EX-ET--12/0400--SE Handledare: Examinator: Fredrik Danielsson ptc, Högskolan Väst Johan Löfberg isy, Linköpings universitet Linköping, 4 oktober 2012

4

5 Avdelning, Institution Division, Department Avdelningen för reglerteknik Department of Electrical Engineering SE Linköping Datum Date Språk Language Svenska/Swedish Engelska/English Rapporttyp Report category Licentiatavhandling Examensarbete C-uppsats D-uppsats Övrig rapport ISBN ISRN LiTH-ISY-EX-ET--12/0400--SE Serietitel och serienummer Title of series, numbering ISSN URL för elektronisk version Titel Title Automatgenerering av kod för flexibel automation Automatic Generation of Control Code for Flexible Automation Författare Author Andreas Svensson Sammanfattning Abstract In order to quickly adapt the production on a production line to the demand, there is a need for flexibility. A tool designed for this purpose, p-sop, has been developed at University West. This thesis deals with implementation of p-sop in a demonstrator, and development of a framework for priority policies as well as a graphical user interface to p-sop. The priority policies evaluated in the demonstrator did note give an increased efficiency, and the graphical user interface is shown to be well suited for the demonstrator and p-sop in general. Nyckelord Keywords Flexible automation, Autogenerated control code, P-SOP

6

7 Sammanfattning Det finns ett behov av flexibel automation för att kunna anpassa produktionen i en industriell produktionsanläggning till efterfrågan. Ett verktyg avsedd för detta ändamål, p-sop, har utvecklats vid Högskolan Väst. I den här uppsatsen behandlas implementeringen av en demonstrator till p-sop, utvecklingen av ett ramverk för prioritsregler samt utvecklingen av ett grafiskt användargränssnitt till p-sop. De prioritetsregler som utvärderas i demonstratorn ger ingen ökad effektivitet, och det grafiska användargränssnittet visar sig vara väl lämpat för demonstratorn och p-sop i allmänhet. iii

8

9 Abstract In order to quickly adapt the production on a production line to the demand, there is a need for flexibility. A tool designed for this purpose, p-sop, has been developed at University West. This thesis deals with implementation of p-sop in a demonstrator, and development of a framework for priority policies as well as a graphical user interface to p-sop. The priority policies evaluated in the demonstrator did note give an increased efficiency, and the graphical user interface is shown to be well suited for the demonstrator and p-sop in general. v

10

11 Acknowledgments Thanks to Production Technology Center and University West for letting me do this project, and thanks to everyone who has helped me: Fredrik, Johan and Bo for the supervision and proofreading and Anders, Anders, Fredrik and Kjell who kindly helped a lost theoretician on the job shop floor with all practical issues. I have learned a lot! Linköping, October 2012 Andreas Svensson vii

12

13 Contents Notation xi 1 Introduction Flexible industrial automation Related work The FLEXA project Other related work Problem formulation Thesis outline Demonstrator project Working process for the implementation Description of the demonstrator Results Discussion and concluding remarks on the demonstrator project Further work Distributed priority policies Need for priority policies Framework for priority policies in P-SOP Related work Design choices Implementation issues Results Discussion and concluding remarks on the priority policies On the demonstrator experiment results On priorities in P-SOP in general Further work Graphical user interface Framework for a P-SOP GUI Related work and research Previous work ix

14 x CONTENTS 4.3 Design choices for the GUI Results Discussion and concluding remarks on the GUI Further work Results and summary 31 6 Concluding remarks Further work A The P-SOP language 35 A.1 Concept idea A.2 Compilation into IEC ST A.3 Limitations of P-SOP B Technical details 39 B.1 Production simulator at PTC C Graphical user interface implementation 41 Bibliography 45 Index 47

15 Notation General abbreviations Abbreviation gui iec st plc p-sop Meaning Graphical User Interface A standard (IEC [2003]) defined by International Electrotechnical Commission for programming of PLCs. Structured Text, a programming language for plc defined in the standard iec (IEC [2003]). Programmable Logic Controller, a programmable realtime system widely used for control purposes in industry. A programming language for production lines developed at University West, compatible with iec xi

16 xii Notation Terms within production Term Part or Product Piece Process Buffer Source Sink Carrier Task Sequence Path Operator Meaning An item produced by a production line. A single part. A station on a production line where value, in some sense, is added to a piece. Usually a machine. A station on a production line where parts can be stored. The entrance for new parts into a production line. The exit for parts manufactured by the line. A robot (or similar) used for moving parts between buffers, processes, sources and sinks on the production line. The movement of a part performed by a carrier. A set of tasks defining all tasks allowed to be performed with a part. A subset of a sequence, where all tasks are possible to perform in a consecutive order with a single piece. A person working at the line with, e.g., maintenance and supervision.

17 1 Introduction 1.1 Flexible industrial automation This thesis deals with some issues within flexible automation, and this section will be an introduction to the subject. An idea of what flexible 1 automation can be about is given in Example Example: An idea of flexible automation Figure 1.1 shows an example of a flexible production line. The line contains an hammer, a drill, a screwdriver, a station for visual inspection, some buffers, and some boxes serving as source and sink for the line. For instance, the line could produce two different part types. Part A, a piece with three screws and one nail, and Part B, a piece with only two nails. Before assembling the screw as well as the nail, a hole must be drilled. After hammering, the piece has to be inspected to ensure the nail was not bent. If the nail was bent, the part has to be placed in the recycling box and a human operator is noted, who will untack the nail and replace the piece in the buffer next to the green robot. It is not trivial to plan the flow of pieces and program each individual robot to achieve the desired production. There are many challenges with this line, for example: The sequences of the different parts share many resources, e.g., the drill and the hammer. 1 The term flexible focuses throughout this thesis on the possibility to re-plan the sequences for parts produced by the line. Similar terms sometimes used are flexible routing and flexible manufacturing cell. Hence, it focuses on flexibility in the interaction between different resources and the product flow through the line, rather than, e.g., flexibility in a single operation performed by a robot. 1

18 2 1 Introduction Figure 1.1: An example of a flexible production line. The blue robot can reach one box with processed pieces, one box with unprocessed pieces, one box named recycling and one buffer. The red robot can reach the drill, screwdriver, inspection station, the buffer at the blue robot, the buffer at the green robot and the buffer at the left end of the rail. The green robot can reach the hammer, the buffer at the red robot and the buffer left of it. A human operator (not shown) can reach all buffers. There is a risk of causing deadlock situations. The flow is not deterministic, since it depends on the outcome of the inspection. The drill is used for screws as well as nails and may therefore be a bottleneck for the entire production. Hence, it is probably important to achieve a high utilization of the drill. In addition, and this is where flexible production comes into play, there may be a need for adapting to different production goals (e.g. 20% part A one day, and 70% part A another day). In addition, there may later appear a need for a new type of part, with, e.g., four screws and one nail. These changes are preferably to be introduced seemless online as the production is runnning, to minimze downtime of the line. And, finally, the production of parts without screws has to continoue even if the screwdriver breaks down, and vice versa. The line is controlled by several plcs. plcs are common in industry for, e.g., control of robots and other resources. A standard for programming plcs is the iec However, iec programs quickly becomes rather extensive, and a typical plc program in industry today consists of several thousands of code lines. The control could also be distributed to several plcs. Albeit the control program may run faultless, the introduction of changes and extensions might be

19 1.2 Related work 3 a rather hard task. One way to handle the challenges mentioned in 1.1 is to create a virtual model of the line as well as the production demand, and then use a computer-aided specialized tool with general algorithms to generate control code adapted to the current production demand. The principles illustrated in Example 1.1 exists in industry, especially in industries with relatively short product series, such as the aerospace industry. The best indication of the industrial needs is probably the participation of several companies in the flexa project (described in Section 1.2), a project including this topic. 1.2 Related work The FLEXA project In 2008, the project flexa Advanced Flexible Automation Cell 2 was started. Several universities and companies 3 took part in the project, and it was co-founded by the the European Seventh Framework Programme. Its main objective was (flexa-fp7.eu [2012]): To create the tools, methods and technologies needed to define, prepare and validate an automated flexible cell that can manufacture a generic process chain allowing for safe human interaction and deliver quality assured parts for the European aero space industry. As a part of this project, work has been carried out at University West in Trollhättan within automatic generation of control code for a flexible production line. A high-level language for production lines, named p-sop 4, has been developed, and a brief description is given in Appendix A. The related work also includes: An attempt to a graphical user interface (gui) for p-sop based on Power- Point and Visual Basic 5 (see Section 4.2.1). A study on a simulation-based optimization approach for production lines combined with a non-hierarchical distribution of the control code (Danielsson et al. [2012]). 2 Grant Agreement University West (SE), Chalmers University of Technology (SE), Avio S.p.A (IT), Hermes Reply S.R.L (IT), MTU Aero Engines GmbH (DE), BCT Steuerungs- und DV-Systeme GmbH (DE), Skytek Ltd (IE), Rolls Royce plc (UK), University of Nottingham (UK), Wytwornia Sprzetu Komunikacyjnego PZL - Rzeszow SA (PL), Universita di Pisa (IT), Zenon S.A. Robotics and Informatics (GR), University of Sheffield (UK) (ec.europa.eu [2012]) 4 Originally an abbreviation for Product-oriented Sequence of Operation Planning 5 Software packages from Microsoft,

20 4 1 Introduction A study on inclusion of human operators as processes or carriers in a production line as well as a smaller demonstrator for this, with distributed control code (He et al.). An idea for automatic generation of a discrete event system model from p-sop code for simulation purposes is presented in Carlsson et al. [2011] Other related work A related work relevant to mention here is the standard iec (IEC [2005] and iec61499.de [2012]), a standard compatible with iec for distributed control for, e.g., production lines. This standard shares some ideas with p-sop, but p-sop is however not compatible with iec The work carried out in Pichler and Wogerer [2011] is also of relevance for the p-sop concept, with the flexibility and human interaction. However, the focus is rather on single robots than entire lines, and hence not very relevant for the work within this thesis, which mainly will focus on planning and programmning of an entire line. Some related work and research are also discussed in connection with the respective theme in the subsequent chapters. 1.3 Problem formulation The aim of this thesis is to contribute to the development of the p-sop concept. This means to implement a demonstrator for p-sop, introduce the concept of priority to p-sop and contribute to the development of a gui. 1.4 Thesis outline This thesis is basically divided into three main chapters. The first chapter (Chapter 2) deals with the demonstrator, the second (Chapter 3) with the investigation of distributed priority, and the third (Chapter 4) with the development of a graphical user interface to p-sop. The results as well as comments and discussion for each part are presented separately in their respective chapter. The results are thereafter summarized in a separate chapter (Chapter 5), and appended with concluding remarks on the entire project and suggestions for further work in Chapter 6. At the end, the thesis is appended by three appendicies. Appendix A contains a brief description of the p-sop language, Appendix B contains some technical details about the production line used for the demonstrator, and Appendix C contains some details on the gui implementation.

21 2 Demonstrator project The first part described in this thesis is the implementation of a demonstrator of the p-sop concept. Hence, the demonstrator relies on a lot of work previously done by other persons involved in the project as well as some new features developed within this thesis. 2.1 Working process for the implementation The development of the demonstrator was done iteratively, with one feature developed and tested at a time. The well-defined interfaces for each module defined by p-sop were used as a structure for this work, e.g., once a human carrier was developed and fulfilled the p-sop interface, it could be treated as any carrier and would not be affected by future developments. A more detailed review of the actual work done is found in Section 2.2. A certain amount of time, beside programming, had to be used for adressing mechanical problems caused by, e.g., physical collisions or wear Description of the demonstrator A description of the implemented demonstrator for the p-sop language is given below, with all its features. 1 The production line used for the demonstrator is indeed well equipped, but there is a lack of sensors for confirming that, e.g., gripping is performed (which, due to physical tardiness, is not always the case), which in a later case may cause a collision. Even some software bugs occurred during the development phase and caused some situations with mechanical difficulties, as well as some issues due to lacking robustness in the communication between a plc and a robot. 5

22 6 2 Demonstrator project Figure 2.1: A layout sketch of the production line at PTC Figure 2.2: The production line at PTC

23 2.2 Description of the demonstrator 7 Physical facilities The demonstrator was implemented on a production line mainly used for education and research purposes, located at Production Technology Center (ptc), Trollhättan. The line contains four units: one cell with an abb robot and a conveyor for loading and unloading raw materials and produced parts, two cells with an abb robot and a cnc machine 2 each, and one portal robot for transportation between the cells. Each station is controlled by a plc, and there is also a master plc with commmunication with each station. A schematic overview of the production line is given in Figure 2.1 and a picture is shown in Figure 2.2. Between each cell, there is a buffer for storing pieces, and the buffers can be reached by the portal robot as well as the abb robots. In addition, there are buffer places which only the portal robot can reach. Some technical details on the demonstrator can be found in Appendix B. Flexible programming Each resource, i.e., machine and robot, is encapsulated into a function block with a well-defined and standardized interface supported by p-sop. A good portion of this work had already been done in earlier projects, but some extensions and development was needed. All physical resources, except the conveyor used for loading and unloading, was encapsulated into separate function blocks. Hence, the line can be programmed in p-sop with arbitrary product sequences, although the physical construction of the line suggests that some sequences make more sense than others. Due to a smart usage in p-sop of different variable types in iec , the entire line can be re-programmed, in principle, during ongoing production. Support for multiple part types The p-sop language supports different part types on the same line, and the demonstrator was therefore able to produce parts of different types at the same time, with shared resources such as buffer places etc. Since the demonstrator only contained two physically different product plates, there was in practice a limitation to two different part types, although there was no technical limitation. GUI for programming A general Graphical User Interface for programming in p-sop was developed, based on Microsoft PowerPoint and Visual Basic. It is in principle possible to sketch the flow of one or more products through the demonstrator in the gui, press the Generate p-sop code button, compile the generated p-sop code and download it into the plc, and hence reprogram the entire production without manually writing a single line of code. A more detailed description is given in Chapter 4. 2 cnc stands for Computer Numerical Control. In this case, it is a milling and a turning machine.

24 8 2 Demonstrator project Human inspection The demonstrator contains a station for manual inspection of, e.g., processed parts, with an interface for the operator to feedback if the part was OK or not. An interface for p-sop was written, and the usage of the station was hence fully supported by the p-sop language. Alternative routes The route through the line for a product part does not have to be linear, but the sequence may contain branching as well as convergences of paths. This allows the use of optional intermediate buffers, e.g., the portal may be used as a buffer. Error-handling p-sop contains support for conditional alternative routes. For instance, if a machine gives an eror signal (meaning that an error possibly have occurred in the processing), it is possible to send this particular piece to an inspection station. Depending on the outcome of the inspection, the piece may either, e.g., be sent back to the process once again, passed to a bin or be considered OK and passed further in the production. Human carrier An interface for requesting the human operator (instead of a robot) to carry a part was designed and encapsulated as a human carrier. This feature makes it possible to use the operator to add extra capacity and flexibility to the line, e.g., to use the human carrier to get rid of bottlenecks or to perform unusual movements for which no robot has been installed. This idea has been investigated in He et al. Visualization for supervision The demonstrator contains a graphical interface for supervision of the line, developed in CoDeSys 3 and displayed on a big screen placed close to the line. It seems, however, not to be a good idea to auto-generate such a visualization from p-sop code since an intuitive visualization of a line probably include some information about the line not supported in p-sop, such as the approximate physical orientation of the line. The visualization is nevertheless fully compatible with the auto-generated code, since the variable names in p-sop generated code is predictable. Hence, the visualization works even if the entire line is re-programmed with new sequences. An impression of the visualization is shown in Figure 2.3. Priority A general framework for assigning individual priorities for each task in the p-sop language was developed and showed to work in the demonstrator. A few different principles for priority policies were investigated, implemented and tested. A more detailed description of this is given in Chapter 3. com 3 A software package from 3S-Smart Software Solutions GmbH,

25 2.3 Results 9 Figure 2.3: The visualization for supervision of the demonstrator 2.3 Results The demonstrator worked as intended, which shows that the p-sop concept is possible to implement and use for, at least, this demonstrator. 2.4 Discussion and concluding remarks on the demonstrator project It has now been shown that the concept works as a whole and is also implementable and manageable in practice for a real production line of this scale, with several industrial robots etc. However, the theoretical concepts have been clear since previous work and some of the individual parts have been tested separately before, but this implementation is something new since it spans all the way from the gui to the physical robots and machines on the production line. It is also interesting to note that during the work with the demonstrator (as indicated in Section 2.1) the well defined interface between the function blocks and the auto generated p-sop code was an advantage in the sense that it provided a useful structure for the work, and did probably prevent many potentially software bugs Further work During the work with the demonstrator, some shortcomings in p-sop became clear, which are mentioned in Section 6.1. An even more advanced demonstrator with more features of p-sop would probably reveal some more shortcomings. However, it would probably be even more interesting if the next implementation is for real industrial needs.

26

27 3 Distributed priority policies As a second part of this thesis, a framework for a priority policy within p-sop was developed and evaluated, as well as some specific policies. As the chapter name suggests, the main theme for the chapter is distributed policies. This notation is inspired by Lu and Kumar [1991], and a distributed policy is here defined as follows. 3.1 Definition (Priority policy and distributed priority policy). In a situation when there is more than one possible task for a carrier to perform, the rule for making the decision which one to perform is called a priority policy. If it fullfills the following two requirements 1. The rule is possible to implement separately for each carrier on the line 2. The rule uses only information about the adjacent items (buffers, processes, sinks, sources,... ) it is called a distributed priority policy. 3.1 Need for priority policies Whenever a situation where a carrier can choose between two different tasks, a decision has to be taken. This decision may impact the flow of products through the production line, and impact, e.g., the production rate and the utilization grade of the line. Two examples where this becomes clear are discussed in Example 3.2 and

28 12 3 Distributed priority policies 3.2 Example: Possible influence of a priority policy I Consider a process with two part types. Suppose that every twelfth minute 1, one piece of type A and one piece of type B arrive to a buffer outside a process (e.g. a machine). This gives the following situation: One piece of type A and one of type B are waiting for being moved to a process, and no other pieces are relevant to consider for this decision. Suppose the processing of A takes 10 minutes, while B only takes 2 minutes. If the carrier picks part A first, and B thereafter, B will have to wait for ten minutes and the average time for these parts (including waiting) for this process will be (10 + (10 + 2))/2 = 11 minutes. On the other hand, if the carrier takes B before A, B will only have to wait for two minutes and the average time will be only (2 + (2 + 10))/2 = 7 minutes. 3.3 Example: Possible influence of a priority policy II Consider a production line where the same carrier is used for picking parts from the source as well as leaving parts to the sink, as illustrated in Figure 3.1 Figure 3.1: Schematical sketch of the situation in Example 3.3 Suppose a choice emerge between either feeding a new part into the line or taking a finished piece and leave to the sink. Which one is the best to do first? Although we do not have to consider the risk of causing a deadlock (since p-sop prohibits such tasks), one choice may still be better than the other. If the consecutive process for the part loaded from the source is idle, and the part waiting for the sink does not block anything nor is in a hurry to be delivered, it would seem obvious to give the highest priority to pick the part from the source. For the opposite situation, the optimal priority is also quite simple to figure out, but it quickly becomes trickier for all combinations of situations in between. These examples illustrate the need for priority policies, as well as the limitations with a distributed policy (i.e. each decision has to be made at each individual carrier, without any information regarding the situation for the rest of the line). 1 Although this example is not very realistic, its purpose is rather to illustrate the importance and influence of priority decisions in different situations, than give a detailed analysis of a specific situation.

29 3.2 Framework for priority policies in P-SOP 13 Even without an explicit priority policy, a decision will be made if the line is controlled by p-sop generated code. This decision will be made by the order of the tasks in the iec st code. Such an implicit priority policy would indeed work, but the order of the task written in the p-sop language (which is the same as the order in the st code) is not intended to affect the performance and hence not desired. 3.2 Framework for priority policies in P-SOP A rather advanced approach to a simulation-based optimization for p-sop is presented in Danielsson et al. [2012]. It is from the previous examples clear that the optimization is rather tricky, and it seems very hard (if not impossible) to develop a general optimal policy for priorities without including simulation. However, the simulation-based optimization would of course require a simulation model able to run online, and a much simpler priority policy is sought in this thesis. There are some relevant limitations in the p-sop language, which gives a framework for this work: 1. The present implementation offers no possibility to manage (and, hence, prioritize between) individual pieces, but only to distinguish between different part types. 2. There is an overall idea that p-sop should be possible to run in a nonhierarchical distributed way on several plc s (e.g. one plc per carrier). 2 Limitation 2 raises some questions. Although there must be no hierarchical decision structure, the information available for the decision may either be all available information (i.e. the state of the entire production line), or only local available information (that is, for each carrier only the parts in and the state of the adjacent buffers, processes etc is known). It is reasonbly desired to take an optimal decision in the active decision making, i.e., proritize. However, it is not very clear what the goal for the optimization is. The goal will therefore remain as only a rather vague desire of high utilization of the production line, and a deliver of the parts as expected. 3.3 Related work The priority policy problem in p-sop is of a rather general nature, since p-sop itself puts almost no restrictions on the sequences. A well-studied similar, although more specific, problem is flowshop scheduling. A good overview of the research, as well as a problem definition, is given in Gupta 2 This is by definition no limitation, but nonetheless relevant to consider in the development of priority policies. However, this principle will in Section 3.4 be interpreted as a preference for distributed policies, which is a limitation, hence the alignment as a limitation.

30 14 3 Distributed priority policies and Stafford [2006]. According to Gupta and Stafford [2006], a flowshop is characterized by more or less continuous and uninterrupted flow of jobs through multiple machines in series. In such a shop, the flow of work is unidirectional since all jobs follow the same technological routing through the machines.. This coincide with the problem arising from the priority problem within p-sop, except the unidirectionality. Unidirectional means that the order in which jobs are processed on various machines is the same for all n jobs and is specified, which does not necessarily have to be true in p-sop. Nonetheless, the research about the flowshop problem may be used as inspiration for ad hoc-policies for p-sop. A listing of some interesting and relevant approaches and results follows: 1. For the priority decisions between different part types waiting for the same process, Perkins and Kumark [1989] gives some very interesting suggestions for distributed priority policies, suitable even for rather general production lines with nonacyclic and non-unidirectional sequences. The idea here is to always choose a piece of the part type of which there are most waiting, or some generalization thereof. 2. Seidman [1994] raises a warning finger regarding lack of stability 3 for such a simple policy as First come, first served (also known as First in, first out ) in nonacyclic flows. The practical implications of these results on the work within p-sop and this thesis remains however rather unclear. 3. Lu and Kumar [1991] indicate that two good distributed policies, although not necessarily optimal, are the Least Slack (LS) policy and the Last Buffer First Served (LBFS), at least for the specific case they studied. The idea with the LS policy is to assign every piece a demanded delivering time, and in some way provide an estimation of the remaining processing for each piece when each decision is made. The piece with the highest expected delay (or, if there are no delays, the smallest margin to delivering time) are always chosen in each decision. This policy tends to minimize the variance in processing times. The LBFS relies on the idea to give higher priority to a piece the shorter it has to the sink. A similar idea is mentioned in Haupt [1989], named Fewest Number of Operations Remaining (FOPNR). As an alternative, the priorities may be inversed and the First Buffer First Served (FBFS) or Greatest Number of Operations Remaining (GOPNR) is obtained. In the simulations performed in Lu and Kumar [1991], the performance of FBFS are shown to be rather poor, while the performance of the LBFS are of the same magnitude as LS, but minimizing the mean of the processing time rather than the variance of it. 4. In Real-Time Operating Systems, priority inversion is an issue occurring when an high priority task H has to wait for the release of a shared resource, currently occupied (i.e. blocked) by a low priority task L. Suppose task L 3 In short, a policy is considered as stable if there exists an upper bound on the process time for each piece, roughly a guarantee that a piece will not get stuck in the line for an indefinite time.

31 3.4 Design choices 15 is interrupted, or in some way blocked, by a task M with medium priority. The result of this situation will be that task M is executing instead of task H. Hence, this causes a situation where the high priority of task H in practice is replaced by the low priority of task L, usually a undesired phenomena named priority inversion. A possible solution to this issue is to use priority inheritance. In this case, it would mean that task L inherits the (high) priority of task H as soon as task H claims to use the same shared resource as task L. Task L will hence not be interrupted by task M as long as it inherits the (high) priority from task H, and task H will, as desired, be executed as soon as possible and not affected by task M. A more detailed description is given in Renwick and Renwick [2004]. Different research papers use different goal functions for measuring the performance of the priority. For example, Lu and Kumar [1991] evaluates different policies against the mean processing time per piece, the standard deviation of processing times per piece as well as a linear combination thereof. None of the approaches referenced above uses any explicit time intervals for the decisions, which is a common approach in some simulation software. 3.4 Design choices The limitation 2 in Section 3.2 needs some further addressing, and a choice according to the discussion in Section 3.2 about which information is supposed to be available has to be made. One of the intentions behind limitation 2 is the avoidance of single point of failure, i.e., a part in a system which causes the entire system to stop if this (single) part is failing. A priority policy where all information about the entire line is required to make a decision would make all communication links single points of failure. The idea of using all available information when available (but not causing failure when not available) has already been exploited in Danielsson et al. [2012], and is not what is sought here. From this, the design choice is made that each priority decision must be made only with the information of parts waiting for being served by the carrier. This coincides with the definition of a distributed priority policy. In p-sop there are no priority decisions made right at the entrance of a process, but when the carrier outside the process chooses which task to perform. In most research referenced above, the priority decisions are treated as they are made at the entrance of each process. However, as long as there are no more than one robot loading each machine, the situations seems to be comparable and the results are assumed to still be applicable. From the referenced research, the LBFS policy (mentioned in 3 in Section 3.3) seems to be a good first start, since it becomes rather simple to implement. As the p-sop code is built up out of tasks, the LBFS policy corresponds to give a static priority to each task depending on its distance to the sink.

32 16 3 Distributed priority policies 3.4 Definition (Static priority). A priority is called static if it is time-independent. Within the idea of last buffer first served, some variations are possible to do. The version of the policy used in this thesis is described in definition 3.5 below, and illustrated with Example Definition (LBFS Policy). All tasks in all sequences are assigned a priority, and in every situation when a decision which task to perform has to be made, the one with the highest priority is chosen.the priorities are assigned according to the following rule, for each sequence at a time: Suppose the sequence contains no indefinite loops (although it may contain the same buffer, process etc a finite times), and the longest path in the sequence is finite and contains n tasks. Let P 0, P 1,, P n 2 be a decreasing sequence of real numbers such that P i > P j if i < j. The priority of task T is then P k, where k is the number of tasks in the longest path from task T. 3.6 Example: LBFS Policy This example gives an example of the LBFS policy. Consider the sequence defined by the flowchart in Figure 3.2. According to definition 3.5, the priorities will be as shown in Figure 3.3. The same principle is used for each sequence (i.e., the flow for each part type) in the entire program. Note that no considerations about which robot performing which task has to be taken into account. It is also worth to note that this policy will mostly give preference to the shortest path through the sequence. One possible evolution of the LBFS policy, mentioned in Haupt [1989], would be to assign priority not depending on the number of remaining steps, but on the total time of the remaining steps. (I.e., if a carrier can choose between moving part A or part B, part A will be preferred if the total remaining processing time of part A is less than the total remaining processing time of part B, although there may be fewer steps left for part B.) Such a policy would, obviously, require some information about processing times, for which the present version of p-sop lacks support. The priorities in LBFS are static while they are time-dependent in the LS policy (mentioned in 3 in Section 3.3). Inspired by the LS policy, a policy with timedependence was also developed. Since there is no possibility to assign individual priorities to single parts directly in the language (due to principle 1 above) as done in LS, the approach to assign variable priorities to different part types came up. This idea was combined with the LBFS idea, and the policy was named Variable Part Priority (VPP) to reflect the non-static priorities. The policy is described in definitions 3.7.

33 3.5 Implementation issues 17 Figure 3.2: A flowchart defining a sequence. A block with a P represent a processes, B a buffer, So a source, Si a sink, and the arrows are the tasks. Figure 3.3: The same sequence as in Figure 3.2, but with priorities according to the LBFS principle. The priority is proportional to the thickness of the line. If, for instance, all tasks (movements of pieces between the boxes ) are performed by the same robot, this tells the robot to always prioritize the piece nearest the sink. 3.7 Definition (VPP Policy). Suppose there is an expectation that X i % of the produced parts delivered to sink S should be of part type i, and suppose Y i % of the actual delivered parts delivered to source S are of part type i. Each task is assigned a priority P = P LBFS + P P ART (i), where i is an index for the present part types. P LBFS is calculated as a LBFS priority according to definition 3.5. P P ART (i) is treated online as a control signal to control Y to be kept as close as possible to the setpoint X. The VPP policy does not fulfill the definition of a distributed priority policy, since the P P ART (i) is a signal needed to be communicated online through the entire system. However, if the implementation of the priority is done in a way that P P ART is treated as equal to 0 if the values for some reason are not available at the decision moment, the policy boils down to the LBFS policy in those cases, which is a distributed policy. 3.5 Implementation issues This section deals with the question how to implement a priority policy in iec st code. As shown in the example in listing A.1, the auto generated p- sop code is divided into separate blocks, each block corresponding to a task in the p-sop code, which makes it quite manageable and readable. The readability of the auto-generated code must not be affected.

34 18 3 Distributed priority policies Hence, a straightforward solution is to exploit this structure, instead of changing it. To make a decision, it must be known which possible tasks there are to perform, as well as the priority of each task. This proposes an algorithm with in 3 steps: 1. Gather information about tasks ready for execution 2. Decide, per carrier, which task to execute 3. Start to execute the chosen task (if still applicable) and start from 1 again One possible way to implement this in iec st is to use the structure shown in listing 3.1. IF NOT PriorityCheck THEN PriorityCheck := TRUE; ELSE ( Find t h e t a s k with h i g h e s t p r i o r i t y ready f o r e x e c u t i o n ) j := 0 ; FOR i := 1 TO ( Upper bound o f B l u e R o b o t P r i o r i t y A r r a y ) BY 1 DO IF BlueRobotPriorityArray [ i ]. Request AND j = 0 THEN BlueRobotPriorityArray [ i ]. Allow := TRUE; j := i ; ELSIF BlueRobotPriorityArray [ i ]. Request AND BlueRobotPriorityArray [ i ]. Prio >= BlueRobotPriorityArray [ j ]. Prio THEN BlueRobotPriorityArray [ j ]. Allow := FALSE ; BlueRobotPriorityArray [ i ]. Allow := TRUE; j := i ; END_IF BlueRobotPriorityArray [ i ]. Request := FALSE ; END_FOR PriorityCheck := FALSE ; END_IF ( Repeat f o r each c a r r i e r ) (... ) ( S t a r t c o n d i t i o n f o r PSOP s e q u e n c e s t e p : ) ( 1 : BlueRobot BoxWithUnprocessedPieces ( 1) > F i r s t B u f f e r ( 1) ) IF Buffer1. in. ProductToLeave IF ( s t a r t c o n d i t i o n f o r t a s k ) THEN IF PriorityCheck THEN BlueRobotPriorityArray [ Taskindex ]. Request := TRUE; BlueRobotPriorityArray [ Taskindex ]. Prio := ( For example ) ; ELSIF BlueRobotPriorityArray [ Taskindex ]. Allow THEN BlueRobotPriorityArray [ Taskindex ]. Allow := FALSE ; ( s t a r t t o e x e c u t e t a s k ) END_IF END_IF IF ( Task i s running ) IF (NOT PriorityCheck ) AND ( Order i s performed ) THEN ( R e s e t r o b o t and c l e a n up ) END_IF END_IF (... ) Listing 3.1: Implementation idea for priority policies in iec st. Cf. listing A.2.

35 3.6 Results Results The structure for making priority decisions was implemented in the demonstrator with a test program of more than code lines, and worked as intended. A few experiments with different policies were carried out at the demonstrator, and presented below. The program which was used was similar to the example in Section 4.4. The results are discussed in Section LBFS policy Three experiments 4 were carried out to test the performance of the lbfs policy. In each experiment, the time until the demonstrator had produced 10 pieces was measured. One experiment was performed with the lbfs policy (accoording to definition 3.5), and two experiments were performed with priorities given with a random number generator insted of the lbfs algorithm. The results are presented in Table 3.1. Policy LBFS Random Random Time Table 3.1: Result of different experiments VPP policy A program with a production of two different part was used, and the production complexity of the different parts types was comparable. A total of 40 pieces were produced, in the beginning with only the lbfs priority policy, thereafter changed to the vpp policy with a demanded ratio of 0.5/0.5, and thereafter with a demanded ratio of 0.8/0.2. The result is shown in Figure 3.4. A simple PID controller with ad hoc-parameters was used to generate the control signal P P ART. 3.7 Discussion and concluding remarks on the priority policies On the demonstrator experiment results LBFS policy What can be said from Table 3.1 is that there exists priority policies that outperform the lbfs policy. It also indicates that the lbfs policy is not very useful for 4 The rather low number of experiments was due to mainly two reasons. First, as will be seen in the discussion in Section 3.7.1, the situation in the demonstrator is of a rather low interest for the kind of priority policies developed here. Secondly, in a fourth experiment, a mechanical accident occured (unrelated to the p-sop program and the priorities) which caused a breakdown for a couple of weeks for the line.

36 20 3 Distributed priority policies Figure 3.4: The experiment with the vpp policy in the demonstrator. In the beginning, the lbfs policy was used. Therafter, after 8 produced parts, the vpp policy was introduced online, with a demanded ratio of 0.5/0.5. After 16 produced parts, the demanded ratio was changed to 0.8/0.2. The dashed line shows the expected difference between the produced number of part of type 1 and part of type 2 if the demanded ratio was delivered as expected. The continous line is the difference between the actual number of produced part types. The dotted line is the control signal generated with a PID controller taking the actual production as an output and the expected production as a reference signal. the demonstrator 5. However, based on the impression when studying the demonstrator performing the experiments, an explanation of the results is that the demonstrator is a system where rather few priority decision have to be made, and the influence of those are rather limited 6. Hence, there are no big possible performance improvements to gain. VPP policy Since both the source and the sink in the demonstrator use the same conveyor, they affect each other. The current version of p-sop lacks support for this tricky 5 Actually, the results indicates a worse performance for the demonstrator with the lbfs policy than a randomized priority. The differences are in the magnitude of 5%. However, the total time for producing ten pieces is only one performance measure out of several possible, and a more significant difference would be needed to make a stronger statement about the performance of the different policies. With these results, a more careful investigation and evaluation of different performance measures would be needed to make a stronger statement. 6 The only shared resources that seems in practice to bound the performance is the conveyor belt and the portal robot. The conveyor belt is, as discussed later, not controlled by the priority decisions. The portal robot is operating rather fast, and is therefore not limiting the production that much

37 3.7 Discussion and concluding remarks on the priority policies 21 interdependence between the load and unload, hence it is not controlled by p-sop. The problem of developing an algorithm for optimizing the load and unload of the conveyor was not addressed further, since the focus with the demonstrator project was to make a demonstration of the p-sop concept, and the focus in the priority policy development was to manage the general situations emerging in a p-sop auto generated code. Instead, an ad-hoc algorithm was used to manage the loading and unloading of the conveyor. 7 The loading of new parts onto the conveyor was simply done in the experiments by just letting the produced parts delivered to the sink, i.e., the conveyor, stay on the conveyor and be produced again. This, together with the tricky interdependence between the source and sink caused by the conveyor, gives the priority decisions a very limited influence on the decision on which part types that enter the line. Of course it is crucial to control which pieces enter the line to affect the proportion of produced part types, and hence the influence of the VPP priority policy was limited. If the source had been designed in a way which made it possible to explicitly choose between different part types from the source with priorities assigned on p-sop level, the policy would probably have a bigger influence. It is also important to note that the program in the experiments uses different machines to process different part types, and the only shared resources between the part types are in practice the robots performing some of the moves of the pieces. This also gives a rather limited influence by the VPP policy, since there are only a few task to prioritize between. However, this is a feature of the demonstrator, not the p-sop language in general. A closer look at Figure 3.4: As can be seen, the influence of the demanded ratio on the produced ratio is rather poor when it differs from 0.5/0.5 (i.e. after 16 delivered pieces). However, as can be noted by looking at the first 8 produced parts, even in the abscense of this active control, the demonstrator produces products with ratio 0.5/0.5. When the demanded ratio is changed after 16 pieces, the difference between the number of produced parts of different types increases, but seems to run into some saturation, and remain rather constant. What probably happens is that the accumulated buffers are emptied on parts of one type, but when these are emptied, the influence of the policy is rather limited, and the production is in practice determined by the loading conveyor, as discussed above. Conclusions The conclusions here must be that the demonstrator is not well suited for these priority policies. The lbfs policy does not increase the efficiency of the demonstrator, and the VPP policy does not have any big influence on the production in the demonstrator neither. However, the shortcomings of the LBFS and the VPP policies in the experiments 7 However, if the p-sop language is extended to be able to handle such situations with rather complicated interdependence between different items on the line, the idea of priority inheritance, mentioned as point 4 in Section 3.3, would maybe be fruitful.

38 22 3 Distributed priority policies can be explained by the demonstrator setup. Therefore, no statement can be done for production lines in general, but only for lines similar to the demonstrator 8. The results reflect rather the challenge of finding a distributed priority policy that works well in all cases, and indicates the need for a global optimization, and motivates the optimization approach proposed in Danielsson et al. [2012] On priorities in P-SOP in general The lacking support of geometry in p-sop gives some shortcomings. For priority decisions, one relevant aspect (which became clear when performing the experiments) is that two different carriers are blocked from interacting with the same buffer at the same time, for the sake of collision avoidance. This means, e.g., that when robot A picks one part from a buffer, robot B is blocked from picking another part from the same buffer until robot A has left its part. The effect of this blocking is not investigated, but when observing the flow in the demonstrator as the experiments were performed, the intuition was that this blocking messed up the situations in a non-optimal way Further work Most of all, the result pinpoints the need of a simulation tool for p-sop. Due to the generality in the language, it seems to be very hard to find a good priority policy meaningful for all possible sequences. Even if the idea with a wizard holon 9 proposed in Danielsson et al. [2012] is not implemented in full, a simulation model would probably still be useful for in advance picking the most promising policy out of the policies mentioned or suggested in Section 3.3 and 3.4. A simulation model would also make it possible to generate a custom priority policy, with, e.g., high static priorities for critical task, so called bottlenecks. An idea for automatic generation of such a model directly from the p-sop language is given in Carlsson et al. [2011], and an interesting framework for the offline optimization is found in Svensson [2012]. 8 In, e.g., Lu and Kumar [1991], the lbfs policy is shown to improve performance in simulations of a production line for semiconductors. It seems probable that this result would be valid also for such a line controlled with p-sop, and it is at least not disproved with this experiment. 9 In short, a supervisor of the line giving recommendations to the carrier what decision to make in complex situations.

39 4 Graphical user interface The third part of this thesis deals with the development of a Graphical User Interface (gui) for p-sop. It builds on an earlier attempt, named version 1.0, and the version developed within this thesis is named version Framework for a P-SOP GUI The overall idea behind the development of p-sop is to simplify the planning and re-planning of an entire production line. This means, for instance, that only rather limited programming skills should be needed. The simplicity of the p-sop language is a step in that direction, although it still is a text-based tool 1. Ideally, the gui should be an equivalently powerful tool as the text-based p-sop code, hence contain the same features. From this, the following goals for the gui are derived: Contain all p-sop features Auto-generate readable and correct p-sop-code 1 A text-based tool is not by definition either harder or easier to use than a graphical tool. However, as will be shown, a graphical tool can be designed so that it seems to become an attractive alternative to a text-based tool. 23

40 24 4 Graphical user interface 4.2 Related work and research Previous work A first attempt to a gui has been made in previous projects at University West. For simplicity, this attempt is hereby denoted version 1.0. In version 1.0, it was possible to sketch some basic p-sop program and autogenerate p-sop code which was not entirely correct and hence not possible to compile. Although it was of no practical use, it was in some sense defining the style and the level of ambition for a p-sop gui. Some relevant research Petre [1995] points out that graphical programming (which a gui to p-sop probably can be considered as) is not necessarily better than text based programming. It is also stressed that the layout, patterns etc. have to make sense. Otherwise there is a risk of misunderstanding for inexperienced users, e.g., it contains patterns which by coincidence seems to be symmetric, and hence misleads the user in the interpretation of the program. 4.3 Design choices for the GUI Ideas kept from version 1.0 A fundamental idea in the p-sop language is the focus on the product flow through the line. In the gui context, this was represented by arrows (representing possible task, movements, of parts) between different blobs (representing processes, buffers, sinks, sources, etc.) in version 1.0. In lack of better terms, the names arrows and blobs will be used in this chapter. It was an idea in version 1.0 that it should be possible to sketch the sequences with a layout similar to the physical layout of the line. This idea probably stems from an intuitive answer to the question how to make a gui easy and simple to use?, and it seems to coincide with what is called second notation Petre [1995] (such as spaces and layout not bounded by the compiler rules) and the stressing of a meaningful use of it. Version 1.0 was implemented in Microsoft PowerPoint with Visual Basic 2. This may not be the very most suitable environment for this kind of program, and a change of environment (to, e.g., Microsoft Visio) was considered but rejected. The advantage of PowerPoint is that it is rather well known, which gives the gui a low threshold for new users. Design choices for version 2.0 One explicit restriction on the possibility to sketch the product sequence similar to the physical sequence on the real line was decided in version 2.0: it is not 2 Software packages from Microsoft,

41 4.4 Results 25 allowed to sketch any loops in the gui. A loop in this context means a path in a sequence returning to the very same blob in the gui. In the case of a product flow returning to the same physical item on the line, this item has to be sketched twice as two separate blobs (but with the same name) in the gui. An example can, e.g., be found in Figure 4.3. There are two reasons for this limitation. First, to avoid possible unclear and ambiguous notation in the gui when to leave a loop. Second, for the sake of simplicity of the underlying algorithms when, e.g., setting priorities (see Example 3.6 for an example). The current version of the p-sop compiler generates iec st code that cannot distinguish between a piece before and after a process, which gives rise to problems, e.g., when a part visits the very same buffer twice during the flow through the line with a process in between. This problem will probably be fixed in coming p-sop versions, but there is a need for a fix for this problem for the demonstrator. The fix used to get rid of this problem is a convention that the id number is increased by 100 for every process passed. The convention is implemented in the function blocks in the demonstrator, and in the code generation in the gui. This is however rather complicated to implement, since the gui allow branchings and convergences within sequences. Some kind of items (buffers and carriers) was decided to have explicit declarations in the gui, which means a blob, declearing the existence of the item, on a separate slide. The reason for this was that there were some information needed for writing correct p-sop code, which were rather unintuitive to ask for somewhere else than in a declaration. The other kind of items consequently has implicit declarations, which may be a questionable design choice in the aspect of user friendliness. Since the demonstrator project was implemented as a parallel work to the development of the gui, the features used in the demonstrator project was given the highest priority, and not all features in p-sop are implemented in the gui version Results The Graphical User Interface was developed and shown able to produce correct and readable p-sop code. A review of the functionality developed is found in this section, as well as a detailed example. An impression of the gui environment is shown in Figure 4.1. Functionality in the GUI The gui contains the following features: Graphical user dialogs for simple generation of new blobs with accurate settings as well as for changing settings of existing blobs Graphical user dialogs for simple generation of new arrows as well as changing settings of existing arrows

42 26 4 Graphical user interface Figure 4.1: An impression of the gui environment Automatic generation of correct p-sop code Features in automatic code generation to handle some shortcomings in the present version of p-sop mentioned in 4.3 Validation of the sketched program, to ensure the current program is correct (e.g. no illegal use of arrows or blobs) before generating p-sop code Explicit declaration of buffers, carriers and parts Implicit declaration of processes, sources, sinks and via -locations Graphical user dialog for setting priorities according to two different priority policies (described in detail in Chapter 3), as well as a feature for manually setting the priorities Graphical user dialog for giving conditions for tasks (e.g. for error handling) The gui is programmed in Microsoft Visual Basic for Application (VBA) and Power Point The VBA code interprets and manipulates the blobs and arrows in Power Point as sequences, tasks, definitions etc., to achieve the funtionality listed above. The VBA code consist of approximately 2000 lines. An idea of the code implementation can be found in Appendix C.

43 4.4 Results 27 Figure 4.2: The definition slide in the gui Figure 4.3: The sequence for product MillingPart Example of a program Buffers and carriers are defined on a separate slide, as shown in Figure 4.2. Here, there are five carriers and six buffers declared. To each of these definition blobs

44 28 4 Graphical user interface there is a unique integer assigned, defining the order they will be listed in the p-sop code (which later affects the iec code). The buffer blobs also each have an integer assigned representing the number of storage places in the buffer. The color of the arrows is the way to assign a carrier to a task. For instance, the green color of the arrow from BufferSTN400(1) to BufferSTN200(3) means that this task will be performed by the portal robot, since the portal robot is defined as green on the definition slide. Figure 4.4: The sequence for product TurningPart The sequences are declared on the subsequent slides, one per slide, see Figure 4.3 and 4.4. Each arrow corresponds to a task in p-sop. With a simple click on the button Generate p-sop code in the gui, the code shown in listing 4.1 is automatically generated. Due to the issues with separating processed and unprocessed parts discussed in Section 4.3, the sequences are divided into different parts, where the id number of the part is increased with 100 after each process. / Generated with P SOP f o r PowerPoint V2. 0 / CONFIGURATION NAME PTC_LINE ; CONFIGURATION USER ANDREAS_SVENSSON; CONFIGURATION REV V0. 1 ; #DEADLOCKAVOIDANCE / D e c l a r a t i o n s e c t i o n / PROCESS { MillingSTN200, TurningSTN300 } ; CARRIER { RobotSTN200, RobotSTN300, RobotSTN400, RobotSTN500, HumanCarrier } ; SOURCE { STN400Load } ; SINK { STN400Unload } ; BUFFER { BufferSTN200 [ 3 2 ], BufferSTN300 [ 9 ], BufferSTN400 [ 9 ], TableSTN300 [ 1 ], TableSTN200 [ 1 ], P o r t a l B u f f e r [ 1 0 ] } ; PART { MillingPart0 [ 1 ], MillingPart1 [ 101], TurningPart0 [ 2 ], TurningPart1 [102] } ;