• No results found

Automatic Generation of Control Code for Flexible Automation

N/A
N/A
Protected

Academic year: 2021

Share "Automatic Generation of Control Code for Flexible Automation"

Copied!
65
0
0

Loading.... (view fulltext now)

Full text

(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 tekniska högskola

Linköpings universitet Linköpings universitet

(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: Fredrik Danielsson

ptc, Högskolan Väst

Examinator: Johan Löfberg

isy, Linköpings universitet

(4)
(5)

Avdelning, Institution Division, Department

Avdelningen för reglerteknik Department of Electrical Engineering SE-581 83 Linköping Datum Date 2012-10-04 Språk Language Svenska/Swedish Engelska/English   Rapporttyp Report category Licentiatavhandling Examensarbete C-uppsats D-uppsats Övrig rapport  

URL för elektronisk version

http://www.ep.liu.se

ISBN — ISRN

LiTH-ISY-EX-ET--12/0400--SE Serietitel och serienummer Title of series, numbering

ISSN —

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 pri-ority 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 gen-eral.

Nyckelord

(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.

(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 demon-strator 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.

(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

(12)
(13)

Contents

Notation xi

1 Introduction 1

1.1 Flexible industrial automation . . . 1

1.2 Related work . . . 3

1.2.1 The FLEXA project . . . 3

1.2.2 Other related work . . . 4

1.3 Problem formulation . . . 4

1.4 Thesis outline . . . 4

2 Demonstrator project 5 2.1 Working process for the implementation . . . 5

2.2 Description of the demonstrator . . . 5

2.3 Results . . . 9

2.4 Discussion and concluding remarks on the demonstrator project . 9 2.4.1 Further work . . . 9

3 Distributed priority policies 11 3.1 Need for priority policies . . . 11

3.2 Framework for priority policies in P-SOP . . . 13

3.3 Related work . . . 13

3.4 Design choices . . . 15

3.5 Implementation issues . . . 17

3.6 Results . . . 19

3.7 Discussion and concluding remarks on the priority policies . . . . 19

3.7.1 On the demonstrator experiment results . . . 19

3.7.2 On priorities in P-SOP in general . . . 22

3.7.3 Further work . . . 22

4 Graphical user interface 23 4.1 Framework for a P-SOP GUI . . . 23

4.2 Related work and research . . . 24

4.2.1 Previous work . . . 24

(14)

x CONTENTS

4.3 Design choices for the GUI . . . 24

4.4 Results . . . 25

4.5 Discussion and concluding remarks on the GUI . . . 29

4.5.1 Further work . . . 30

5 Results and summary 31 6 Concluding remarks 33 6.1 Further work . . . 33

A The P-SOP language 35 A.1 Concept idea . . . 35

A.2 Compilation into IEC 61131-3 ST . . . 36

A.3 Limitations of P-SOP . . . 37

B Technical details 39 B.1 Production simulator at PTC . . . 39

C Graphical user interface implementation 41

Bibliography 45

(15)

Notation

General abbreviations

Abbreviation Meaning

gui Graphical User Interface

iec 61131-3 A standard (IEC [2003]) defined by International

Elec-trotechnical Commission for programming of PLCs.

st Structured Text, a programming language for plc

de-fined in the standard iec 61131-3 (IEC [2003]).

plc Programmable Logic Controller, a programmable

real-time system widely used for control purposes in indus-try.

p-sop A programming language for production lines

devel-oped at University West, compatible with iec 61131-3.

(16)

xii Notation

Terms within production

Term Meaning

Partor

Product An item produced by a production line.

Piece A single part.

Process A station on a production line where value, in some

sense, is added to a piece. Usually a machine.

Buffer A station on a production line where parts can be

stored.

Source The entrance for new parts into a production line.

Sink The exit for parts manufactured by the line.

Carrier A robot (or similar) used for moving parts between

buffers, processes, sources and sinks on the produc-tion line.

Task The movement of a part performed by a carrier.

Sequence A set of tasks defining all tasks allowed to be

per-formed with a part.

Path A subset of a sequence, where all tasks are possible to

perform in a consecutive order with a single piece.

Operator A person working at the line with, e.g., maintenance

(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 flexible1automation can

be about is given in Example 1.1.

1.1 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.

1The 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 manu-facturing 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.

(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 inspec-tion.

• The drill is used for screws as well as nails and may therefore be a bottle-neck 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 61131-3. However, iec 61131-3 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 indus-tries with relatively short product series, such as the aerospace industry. The best indication of the industrial needs is probably the participation of several com-panies in the flexa project (described in Section 1.2), a project including this topic.

1.2

Related work

1.2.1

The FLEXA project

In 2008, the project flexa– Advanced Flexible Automation Cell2 was started.

Several universities and companies3took 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 pro-cess 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 Troll-hättan within automatic generation of control code for a flexible production line.

A high-level language for production lines, named p-sop4, 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 Basic5(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 (Daniels-son et al. [2012]).

2Grant Agreement 213734

3University 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])

4Originally an abbreviation for ‘Product-oriented Sequence of Operation Planning’ 5Software packages from Microsoft, http://www.microsoft.com

(20)

4 1 Introduction

• A study on inclusion of human operators as processes or carriers in a pro-duction 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-sopcode for simulation purposes is presented in Carlsson et al. [2011].

1.2.2

Other related work

A related work relevant to mention here is the standard iec 61499 (IEC [2005] and iec61499.de [2012]), a standard compatible with iec 61131-3 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 61499.

The work carried out in Pichler and Wogerer [2011] is also of relevance for the

p-sopconcept, 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 respec-tive 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 (Chap-ter 2) deals with the demonstrator, the second (Chap(Chap-ter 3) with the investigation of distributed priority, and the third (Chapter 4) with the development of a graph-ical 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 Ap-pendix 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 devel-oped within this thesis.

2.1

Working process for the implementation

The development of the demonstrator was done iteratively, with one feature de-veloped 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.1

2.2

Description of the demonstrator

A description of the implemented demonstrator for the p-sop language is given below, with all its features.

1The 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.

(22)

6 2 Demonstrator project

Figure 2.1:A layout sketch of 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 educa-tion and research purposes, located at Produceduca-tion Technology Center (ptc), Troll-hä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

abbrobot and a cnc machine2each, and one portal robot for transportation

be-tween the cells. Each station is controlled by a plc , and there is also a master

plcwith commmunication with each station. A schematic overview of the

pro-duction 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 exten-sions 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 61131-3 , the entire line can be re-programmed, in principle, during ongo-ing production.

Support for multiple part types

The p-sop language supports different part types on the same line, and the demon-strator 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 con-tained 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.

(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-sopcontains support for conditional alternative routes. For instance, if a

ma-chine 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,

de-veloped in CoDeSys3 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-sopcode since an intuitive visualization of a line probably include some

infor-mation 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 pre-dictable. 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.

3A software package from 3S-Smart Software Solutions GmbH, http://www.3s-software.

(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 imple-mentable 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 indi-cated 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 soft-ware bugs.

2.4.1

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 demonstra-tor 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 de-cision has to be taken. This dede-cision 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 3.3.

(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 minute1, 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).

1Although 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 61131-3 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 pre-sented 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 frame-work for this frame-work:

1. The present implementation offers no possibility to manage (and, hence, prioritize between) individual pieces, but only to distinguish between dif-ferent part types.

2. There is an overall idea that p-sop should be possible to run in a non-hierarchical distributed way on several plc s (e.g. one plc per carrier).2 Limitation 2 raises some questions. Although there must be no hierarchical deci-sion structure, the information available for the decideci-sion may either be all able information (i.e. the ‘state’ of the entire production line), or only local avail-able 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

2This is by definition no limitation, but nonetheless relevant to consider in the development of

pri-ority 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 char-acterized by more or less continuous and uninterrupted flow of jobs through mul-tiple 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 co-incide with the problem arising from the priority problem within p-sop, except the unidirectionality. Unidirectional ‘means that the order in which jobs are pro-cessed 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 flow-shop 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 stability3for 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 deliv-ering 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 mar-gin 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

3In short, a policy is considered as stable if there exists an upper bound on the process time for

(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 perfor-mance 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 ac-cording 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 infor-mation 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 3.6.

3.5 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 P0, P1, · , Pn−2be a decreasing sequence of real numbers such that Pi > Pj if

i < j. The priority of task T is then Pk, 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 defi-nition 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 time-dependence 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 Vari-able 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 Xi% of the

produced parts delivered to sink S should be of part type i, and suppose Yi% of

the actual delivered parts delivered to source S are of part type i.

Each task is assigned a priority P = PLBFS+ PP ART(i), where i is an index for the

present part types. PLBFSis calculated as a LBFS priority according to definition

3.5. PP 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 PP 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

PP 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

61131-3 stcode. As shown in the example in listing A.1, the auto generated

p-sopcode 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 per-form, 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 61131-3 st is to use the structure shown in listing 3.1.

IF NOT P r i o r i t y C h e c k THEN P r i o r i t y C h e c k := 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 B l u e R o b o t P r i o r i t y A r r a y [ i ] . Request AND j = 0 THEN B l u e R o b o t P r i o r i t y A r r a y [ i ] . Allow := TRUE ;

j := i ;

ELSIF B l u e R o b o t P r i o r i t y A r r a y [ i ] . Request AND B l u e R o b o t P r i o r i t y A r r a y [ i ] . P r i o >= B l u e R o b o t P r i o r i t y A r r a y [ j ] . P r i o THEN B l u e R o b o t P r i o r i t y A r r a y [ j ] . Allow := FALSE ; B l u e R o b o t P r i o r i t y A r r a y [ i ] . Allow := TRUE ; j := i ; END_IF B l u e R o b o t P r i o r i t y A r r a y [ i ] . Request := FALSE ; END_FOR P r i o r i t y C h e c k := 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 sequence s t e p : * ) (* 1 : B l u e R o b o t B o x W i t h U n p r o c e s s e d P i e c e s ( 1) −> F i r s t B u f f e r ( 1) * ) IF B u f f e r 1 . i n . 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 P r i o r i t y C h e c k THEN

B l u e R o b o t P r i o r i t y A r r a y [ Taskindex ] . Request := TRUE ;

B l u e R o b o t P r i o r i t y A r r a y [ Taskindex ] . P r i o := 0.8249606 (* For example * ) ;

ELSIF B l u e R o b o t P r i o r i t y A r r a y [ Taskindex ] . Allow THEN B l u e R o b o t P r i o r i t y A r r a y [ Taskindex ] . Allow := FALSE ;

(* s t a r t to e x e c u t e t a s k * )

END_IF END_IF

IF (* Task i s running * )

IF (NOT P r i o r i t y C h e c k ) 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 61131-3 st. Cf. listing A.2.

(35)

3.6 Results 19

3.6

Results

The structure for making priority decisions was implemented in the demonstra-tor with a test program of more than 10 000 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 3.7.1.

LBFS policy

Three experiments4 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 22’55” 21’35” 22’10”

Table 3.1:Result of different experiments

VPP policy

A program with a production of two different part was used, and the produc-tion 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 PP ART.

3.7

Discussion and concluding remarks on the

priority policies

3.7.1

On the demonstrator experiment results

LBFS policy

What can be said from Table 3.1 is that there exists priority policies that outper-form the lbfs policy. It also indicates that the lbfs policy is not very useful for

4The 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

vpppolicy 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 demonstrator5.

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 limited6. 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

5Actually, 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.

6The 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-sopauto 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 interde-pendence 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 pri-ority 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 influ-ence.

It is also important to note that the program in the experiments uses different ma-chines 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 de-livered 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 dif-ference 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 pro-duction 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 demon-strator, 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

7However, if the p-sop language is extended to be able to handle such situations with rather

com-plicated interdependence between different items on the line, the idea of priority inheritance, men-tioned 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 demonstrator8. 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].

3.7.2

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 experi-ments) 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 an-other 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.

3.7.3

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 holon9 pro-posed 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 auto-matic 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].

8In, 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.

9In short, a supervisor of the line giving recommendations to the carrier what decision to make in

(39)

4

Graphical user interface

The third part of this thesis deals with the development of a Graphical User In-terface (gui) for p-sop . It builds on an earlier attempt, named version 1.0, and the version developed within this thesis is named version 2.0.

4.1

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 tool1. 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

1A 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.

(40)

24 4 Graphical user interface

4.2

Related work and research

4.2.1

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 prob-ably 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 pat-terns 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 possi-ble 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 Basic2. 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

(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 61131-3 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 imple-mented 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 declara-tions’ 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 some-where else than in a declaration. The other kind of items consequently has ‘im-plicit 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 devel-opment 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 2.0.

4.4

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 chang-ing settchang-ings of existchang-ing 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 cor-rect (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 pri-ority 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 han-dling)

The gui is programmed in Microsoft Visual Basic for Application (VBA) and Power Point 2010. The VBA code interprets and manipulates the blobs and ar-rows in Power Point as sequences, tasks, definitions etc., to achieve the funtional-ity 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-sopcode (which later affects the iec 61131-3 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 un-processed 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 NAMEPTC_LINE ; CONFIGURATION USERANDREAS_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 ] } ;

(45)

4.5 Discussion and concluding remarks on the GUI 29

SEQUENCE( M i l l i n g P a r t 0 ) {

1 : RobotSTN400 STN400Load −> BufferSTN400 ( 1 ) ; 2 : RobotSTN500 BufferSTN400 ( 1 ) −> BufferSTN200 ( 3 ) ; 3 : RobotSTN200 BufferSTN200 ( 3 ) −> TableSTN200 ( 1 ) ; 4 : RobotSTN200 TableSTN200 ( 1 ) −> MillingSTN200 ; 5 : RobotSTN500 BufferSTN400 ( 1 ) −> P o r t a l B u f f e r (* ) ; 6 : RobotSTN500 P o r t a l B u f f e r (* ) −> BufferSTN200 ( 3 ) ; 7 : RobotSTN200 BufferSTN200 ( 3 ) −> TableSTN200 ( 1 ) ; 8 : RobotSTN200 TableSTN200 ( 1 ) −> MillingSTN200 ; } ;

SEQUENCE( M i l l i n g P a r t 1 ) {

1 : RobotSTN200 MillingSTN200 −> TableSTN200 ( 1 ) ; 2 : RobotSTN200 TableSTN200 ( 1 ) −> BufferSTN200 ( 5 ) ; 3 : RobotSTN500 BufferSTN200 ( 5 ) −> BufferSTN400 ( 1 ) ; 4 : RobotSTN400 BufferSTN400 ( 1 ) −> STN400Unload ; 5 : RobotSTN200 MillingSTN200 −> TableSTN200 ( 1 ) ; 6 : RobotSTN200 TableSTN200 ( 1 ) −> BufferSTN200 ( 5 ) ; 7 : RobotSTN500 BufferSTN200 ( 5 ) −> BufferSTN400 ( 1 ) ; 8 : RobotSTN400 BufferSTN400 ( 1 ) −> STN400Unload ; } ;

SEQUENCE( TurningPart0 ) {

1 : RobotSTN400 STN400Load −> BufferSTN400 ( 1 ) ; 2 : RobotSTN500 BufferSTN400 ( 1 ) −> BufferSTN300 ( 4 ) ; 3 : RobotSTN300 BufferSTN300 ( 4 ) −> TableSTN300 ( 1 ) ; 4 : RobotSTN300 TableSTN300 ( 1 ) −> TurningSTN300 ; 5 : RobotSTN500 BufferSTN400 ( 1 ) −> P o r t a l B u f f e r (* ) ; 6 : RobotSTN500 P o r t a l B u f f e r (* ) −> BufferSTN300 ( 4 ) ; 7 : RobotSTN300 BufferSTN300 ( 4 ) −> TableSTN300 ( 1 ) ; 8 : RobotSTN300 TableSTN300 ( 1 ) −> TurningSTN300 ; } ;

SEQUENCE( TurningPart1 ) {

1 : RobotSTN300 TurningSTN300 −> TableSTN300 ( 1 ) ; 2 : RobotSTN300 TableSTN300 ( 1 ) −> BufferSTN300 ( 6 ) ; 3 : RobotSTN500 BufferSTN300 ( 6 ) −> BufferSTN400 ( 1 ) ; 4 : RobotSTN400 BufferSTN400 ( 1 ) −> STN400Unload ; 5 : RobotSTN300 TurningSTN300 −> TableSTN300 ( 1 ) ; 6 : RobotSTN300 TableSTN300 ( 1 ) −> BufferSTN300 ( 6 ) ; 7 : RobotSTN500 BufferSTN300 ( 6 ) −> BufferSTN400 ( 1 ) ; 8 : RobotSTN400 BufferSTN400 ( 1 ) −> STN400Unload ; } ;

Listing 4.1:Automatically generated p-sop code from the gui

4.5

Discussion and concluding remarks on the GUI

The gui indeed offers some advantages. Although the majority of the job with the auto generated iec 61131-3 st code is done by the p-sop compiler, and not the gui, the gui is nonetheless an eye-opener for the compactness and powerful-ness of the p-sop concept. With only a few manipulations from a human, the behaviour of the entire line can easily be changed in the desired manner.

Besides being an eye-opener for the concept, it can also be a useful tool for pro-grammning. With a well-designed graphical interface, the process of re-planning

(46)

30 4 Graphical user interface

can be made rather intuitive, and the threshold for re-planning of the production probaly lowered.

4.5.1

Further work

The gui is developed for being an interface to p-sop demonstrating the possi-bilites, but not to be a market-ready product. Therefore, the user-friendliness are not the very best in menus, notations etc. This area would definitely be necessary to develop if p-sop one day would be a commercial product. The underlying algo-rithms to manage, validate and generate p-sop code are possibly not optimal, and the complexity will probably increase rather fast with long product sequences. Some functions in p-sop are still not implemented in the gui, which also could be a direction of future work.

An interesting question thar arose during the work is if it would be possible to de-velop a function for generating a graphical view out of p-sop code. It is however unclear what the use of such a function would be in practice.

The idea for developing a gui is, as mentioned in Section 4.1, to simplify the planning and re-planning of production lines. However, of advantages over a text-based tool (as the p-sop language) is basically based on personal experiences from industry among the involved persons. Although no reasons for question-ing this conclusion was raised durquestion-ing the work with this thesis, there is to the authors knowledge no research supporting this conclusion. Hence, it would be interesting to evaluate a gui, with fully implemented functionality, against the text-based p-sop language.

(47)

5

Results and summary

In this chapter, the results from this different parts of the thesis are once again mentioned and summarized.

• It has been shown that the p-sop concept is possible to, at least, implement and use as intended for the demonstrator described in Chapter 2.

• The proposed structure for implementing priority decisions in iec

61131-3 stwas shown to work. The proposed priority policies did not gave any

noteworthy difference in the performance of the demonstrator.

• The Graphical User Interface was developed and shown able to produce correct and readable p-sop code.

(48)
(49)

6

Concluding remarks

The work done within this thesis, together with the entire p-sop concept in gen-eral, is probably of industrial interest. It offers an implemented concept for flex-ible automation on the level of production lines, and is not only a theoretical framework, but also an implemented concept more or less ready to use in prac-tice. The advantages has become quite obvious when working at the job shop floor with the implementation of the demonstrator project – it is indeed possible to re-program the production on an entire line in a few minutes with minimal pro-gramming knowledge, although the underlying code may contain far more than 10 000 lines. Altogether, p-sop appears to be a rather powerful and efficient tool for programming an entire production line. Although there are many options for further work and some issues with the current implementation, p-sop seems to be a subject for a future commercial product. Accordingly, one may question if the future development is more well suited for a commercial environment.

6.1

Further work

There are some themes which need addressing in the further development of

p-sop. Some issues have a rather practical nature while other requires wider

de-velopment of new concepts. During this work, it has been clear that the following themes are of relevance:

• Development of the automatic generation of simulation models from the

p-sopcode, as proposed in Carlsson et al. [2011]. Such a model would in

the first step be used to get a (rough) estimation of the performance of the system with different priority settings etc., and could in the next step be used for e.g. optimization.

References

Related documents

When the students have ubiquitous access to digital tools, they also have ubiquitous possibilities to take control over their learning processes (Bergström &amp; Mårell-Olsson,

How could the findings concerning characteristics of people with mild dementia and difficulties of using technology be used to facilitate the graphical user interface design of

A small distance indicates that a gene tree is similar to the species tree and that the gene sequence has an evolutionary history that matches the order of speciation suggested by

The proposed method extracted and created the same metadata elements like the previous webpage 1 language, rights, keywords and description metadata that will be

minimising force losses, but generally speaking at the expense of less lifetime and control. A common optimisation is choosing different wheels for the trailer and for the truck. The

Against that background the thesis asks “how can a web-based graphical user inter- face for IPTV set-top boxes, such as that of TeliaSonera, be improved and prepared for future

Figure 12 shows the main window of the graphical user interface, when the client is con- nected to the controller program on the tractor.. 4.4.4 Component Description of the

o Select node: This method is represented with a list of nodes that are not operating at the desired level, and when the cursor is over the specific node, it will present