Automatic Generation of Control Code for Flexible Automation

Institutionen för systemteknikDepartment of Electrical Engineering

Examensarbete

Automatic Generation of Control Code for FlexibleAutomation

Examensarbete utfört i Elektroteknikvid 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ögskolaLinköpings universitet Linköpings universitetSE-581 83 Linköping, Sweden 581 83 Linköping

Automatic Generation of Control Code for FlexibleAutomation

Examensarbete utfört i Elektroteknikvid Tekniska högskolan vid Linköpings universitet

av

Andreas Svensson


Handledare: Fredrik Danielssonptc, Högskolan Väst

Examinator: Johan Löfbergisy, Linköpings universitet

Linköping, 4 oktober 2012

Avdelning, InstitutionDivision, Department

Avdelningen för reglerteknikDepartment of Electrical EngineeringSE-581 83 Linköping

DatumDate

2012-10-04

SpråkLanguage

� Svenska/Swedish

� Engelska/English

�

�

RapporttypReport category

� Licentiatavhandling

� Examensarbete

� C-uppsats

� D-uppsats

� Övrig rapport

�

�

URL för elektronisk version

http://www.ep.liu.se

ISBN

—

ISRN


Serietitel och serienummerTitle of series, numbering

ISSN

—

TitelTitle

Automatgenerering av kod för flexibel automation

Automatic Generation of Control Code for Flexible Automation

FörfattareAuthor

Andreas Svensson

SammanfattningAbstract

In order to quickly adapt the production on a production line to the demand, there is a needfor flexibility. A tool designed for this purpose, p-sop, has been developed at UniversityWest. This thesis deals with implementation of p-sop in a demonstrator, and developmentof 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 thegraphical user interface is shown to be well suited for the demonstrator and p-sop in gen-eral.

NyckelordKeywords Flexible automation, Autogenerated control code, P-SOP

http://www.ep.liu.se

Sammanfattning

Det finns ett behov av flexibel automation för att kunna anpassa produktioneni en industriell produktionsanläggning till efterfrågan. Ett verktyg avsedd fördetta ändamål, p-sop, har utvecklats vid Högskolan Väst. I den här uppsatsenbehandlas implementeringen av en demonstrator till p-sop, utvecklingen av ettramverk för prioritsregler samt utvecklingen av ett grafiskt användargränssnitttill p-sop. De prioritetsregler som utvärderas i demonstratorn ger ingen ökadeffektivitet, och det grafiska användargränssnittet visar sig vara väl lämpat fördemonstratorn och p-sop i allmänhet.

iii

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 beendeveloped at University West. This thesis deals with implementation of p-sop ina demonstrator, and development of a framework for priority policies as well asa 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 isshown to be well suited for the demonstrator and p-sop in general.

v

Acknowledgments

Thanks to Production Technology Center and University West for letting me dothis project, and thanks to everyone who has helped me: Fredrik, Johan and Bofor the supervision and proofreading and Anders, Anders, Fredrik and Kjell whokindly helped a lost theoretician on the job shop floor with all practical issues. Ihave learned a lot!

Linköping, October 2012Andreas Svensson

vii

Contents

Notation xi

1 Introduction 11.1 Flexible industrial automation . . . . . . . . . . . . . . . . . . . . . 11.2 Related work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2.1 The FLEXA project . . . . . . . . . . . . . . . . . . . . . . . 31.2.2 Other related work . . . . . . . . . . . . . . . . . . . . . . . 4

1.3 Problem formulation . . . . . . . . . . . . . . . . . . . . . . . . . . 41.4 Thesis outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Demonstrator project 52.1 Working process for the implementation . . . . . . . . . . . . . . . 52.2 Description of the demonstrator . . . . . . . . . . . . . . . . . . . . 52.3 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.4 Discussion and concluding remarks on the demonstrator project . 9

2.4.1 Further work . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3 Distributed priority policies 113.1 Need for priority policies . . . . . . . . . . . . . . . . . . . . . . . . 113.2 Framework for priority policies in P-SOP . . . . . . . . . . . . . . . 133.3 Related work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.4 Design choices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.5 Implementation issues . . . . . . . . . . . . . . . . . . . . . . . . . 173.6 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.7 Discussion and concluding remarks on the priority policies . . . . 19

3.7.1 On the demonstrator experiment results . . . . . . . . . . . 193.7.2 On priorities in P-SOP in general . . . . . . . . . . . . . . . 223.7.3 Further work . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4 Graphical user interface 234.1 Framework for a P-SOP GUI . . . . . . . . . . . . . . . . . . . . . . 234.2 Related work and research . . . . . . . . . . . . . . . . . . . . . . . 24

4.2.1 Previous work . . . . . . . . . . . . . . . . . . . . . . . . . . 24

ix

x CONTENTS

4.3 Design choices for the GUI . . . . . . . . . . . . . . . . . . . . . . . 244.4 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254.5 Discussion and concluding remarks on the GUI . . . . . . . . . . . 29

4.5.1 Further work . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

5 Results and summary 31

6 Concluding remarks 336.1 Further work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

A The P-SOP language 35A.1 Concept idea . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35A.2 Compilation into IEC 61131-3 ST . . . . . . . . . . . . . . . . . . . 36A.3 Limitations of P-SOP . . . . . . . . . . . . . . . . . . . . . . . . . . 37

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

C Graphical user interface implementation 41

Bibliography 45

Index 47

Notation

General abbreviations

Abbreviation Meaning

gui Graphical User Interfaceiec 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.

xi

xii Notation

Terms within production

Term Meaning

Part orProduct 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 betweenbuffers, 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

and supervision.

1Introduction

1.1 Flexible industrial automation

This thesis deals with some issues within flexible automation, and this sectionwill be an introduction to the subject. An idea of what flexible1 automation canbe about is given in Example 1.1.

1.1 Example: An idea of flexible automationFigure 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, andsome boxes serving as source and sink for the line.

For instance, the line could produce two different part types. Part A, a piecewith three screws and one nail, and Part B, a piece with only two nails. Beforeassembling 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, whowill 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 toachieve the desired production. There are many challenges with this line, forexample:

• The sequences of the different parts share many resources, e.g., the drilland the hammer.

1The term ‘flexible’ focuses throughout this thesis on the possibility to re-plan the sequences forparts 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 theproduct flow through the line, rather than, e.g., flexibility in a single operation performed by a robot.

1

2 1 Introduction

Figure 1.1: An example of a flexible production line. The blue robot canreach one box with processed pieces, one box with unprocessed pieces, onebox named ‘recycling’ and one buffer. The red robot can reach the drill,screwdriver, inspection station, the buffer at the blue robot, the buffer at thegreen robot and the buffer at the left end of the rail. The green robot canreach the hammer, the buffer at the red robot and the buffer left of it. Ahuman 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 ahigh utilization of the drill.

In addition, and this is where flexible production comes into play, there may be aneed 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 typeof part, with, e.g., four screws and one nail. These changes are preferably to beintroduced seemless online as the production is runnning, to minimze downtimeof the line. And, finally, the production of parts without screws has to continoueeven 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 theiec 61131-3. However, iec 61131-3 programs quickly becomes rather extensive,and a typical plc program in industry today consists of several thousands of codelines. The control could also be distributed to several plcs. Albeit the controlprogram may run faultless, the introduction of changes and extensions might be

1.2 Related work 3

a rather hard task.

One way to handle the challenges mentioned in 1.1 is to create a virtual modelof the line as well as the production demand, and then use a computer-aidedspecialized tool with general algorithms to generate control code adapted to thecurrent 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 bestindication of the industrial needs is probably the participation of several com-panies in the flexa project (described in Section 1.2), a project including thistopic.

1.2 Related work

1.2.1 The FLEXA project

In 2008, the project flexa– Advanced Flexible Automation Cell2 was started.Several universities and companies3 took part in the project, and it was co-foundedby the the European Seventh Framework Programme. Its main objective was(flexa-fp7.eu [2012]):

To create the tools, methods and technologies needed to define, prepareand validate an automated flexible cell that can manufacture a generic pro-cess chain allowing for safe human interaction and deliver quality assuredparts 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-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 Basic5 (see Section 4.2.1).

• A study on a simulation-based optimization approach for production linescombined with a non-hierarchical distribution of the control code (Daniels-son et al. [2012]).

2Grant Agreement 2137343University 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), SkytekLtd (IE), Rolls Royce plc (UK), University of Nottingham (UK), Wytwornia Sprzetu KomunikacyjnegoPZL - Rzeszow SA (PL), Universita di Pisa (IT), Zenon S.A. Robotics and Informatics (GR), Universityof Sheffield (UK) (ec.europa.eu [2012])

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

http://www.microsoft.com

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 distributedcontrol code (He et al.).

• An idea for automatic generation of a discrete event system model fromp-sop code 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 distributedcontrol 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 thep-sop concept, with the flexibility and human interaction. However, the focus israther on single robots than entire lines, and hence not very relevant for the workwithin this thesis, which mainly will focus on planning and programmning of anentire 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 ofpriority 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 (Chapter 3) with the investigationof 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 foreach part are presented separately in their respective chapter. The results arethereafter summarized in a separate chapter (Chapter 5), and appended withconcluding remarks on the entire project and suggestions for further work inChapter 6. At the end, the thesis is appended by three appendicies. AppendixA contains a brief description of the p-sop language, Appendix B contains sometechnical details about the production line used for the demonstrator, and Ap-pendix C contains some details on the gui implementation.

2Demonstrator project

The first part described in this thesis is the implementation of a demonstrator ofthe p-sop concept. Hence, the demonstrator relies on a lot of work previouslydone 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 definedby p-sop were used as a structure for this work, e.g., once a human carrier wasdeveloped and fulfilled the p-sop interface, it could be treated as any carrier andwould not be affected by future developments. A more detailed review of theactual work done is found in Section 2.2.

A certain amount of time, beside programming, had to be used for adressingmechanical 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 givenbelow, with all its features.

1The production line used for the demonstrator is indeed well equipped, but there is a lack ofsensors for confirming that, e.g., gripping is performed (which, due to physical tardiness, is not alwaysthe case), which in a later case may cause a collision. Even some software bugs occurred during thedevelopment phase and caused some situations with mechanical difficulties, as well as some issuesdue to lacking robustness in the communication between a plc and a robot.

5

6 2 Demonstrator project

Figure 2.1: A layout sketch of the production line at PTC

Figure 2.2: The production line at PTC

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 Production Technology Center (ptc), Troll-hättan. The line contains four units: one cell with an abb robot and a conveyorfor loading and unloading raw materials and produced parts, two cells with anabb robot and a cnc machine2 each, and one portal robot for transportation be-tween the cells. Each station is controlled by a plc , and there is also a masterplc with 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. Betweeneach cell, there is a buffer for storing pieces, and the buffers can be reached by theportal robot as well as the abb robots. In addition, there are buffer places whichonly the portal robot can reach. Some technical details on the demonstrator canbe found in Appendix B.

Flexible programming

Each resource, i.e., machine and robot, is ‘encapsulated’ into a function blockwith a well-defined and standardized interface supported by p-sop. A goodportion of this work had already been done in earlier projects, but some exten-sions and development was needed. All physical resources, except the conveyorused 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 makemore sense than others. Due to a smart usage in p-sop of different variable typesin 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 limitationto 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 tosketch 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 anddownload it into the plc , and hence reprogram the entire production withoutmanually writing a single line of code. A more detailed description is given inChapter 4.

2cnc stands for Computer Numerical Control. In this case, it is a milling and a turning machine.

8 2 Demonstrator project

Human inspection

The demonstrator contains a station for manual inspection of, e.g., processedparts, 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 fullysupported by the p-sop language.

Alternative routes

The route through the line for a product part does not have to be ‘linear’, but thesequence may contain branching as well as convergences of paths. This allowsthe 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 ma-chine gives an eror signal (meaning that an error possibly have occurred in theprocessing), 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 sentback to the process once again, passed to a bin or be considered OK and passedfurther in the production.

Human carrier

An interface for requesting the human operator (instead of a robot) to carry apart was designed and encapsulated as a ‘human carrier’. This feature makes itpossible to use the operator to add extra capacity and flexibility to the line, e.g., touse the human carrier to get rid of bottlenecks or to perform unusual movementsfor 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. Itseems, however, not to be a good idea to auto-generate such a visualization fromp-sop code since an intuitive visualization of a line probably include some infor-mation about the line not supported in p-sop, such as the approximate physicalorientation of the line. The visualization is nevertheless fully compatible withthe 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-programmedwith 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-soplanguage was developed and showed to work in the demonstrator. A few differentprinciples for priority policies were investigated, implemented and tested. Amore detailed description of this is given in Chapter 3.

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

http://www.3s-software.com

http://www.3s-software.com

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 ispossible to implement and use for, at least, this demonstrator.

2.4 Discussion and concluding remarks on thedemonstrator 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, withseveral industrial robots etc. However, the theoretical concepts have been clearsince previous work and some of the individual parts have been tested separatelybefore, but this implementation is something new since it spans all the way fromthe 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 andthe auto generated p-sop code was an advantage in the sense that it provided auseful 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 becameclear, 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 implementationis for real industrial needs.

3Distributed priority policies

As a second part of this thesis, a framework for a priority policy within p-sopwasdeveloped and evaluated, as well as some specific policies. As the chapter namesuggests, the main theme for the chapter is distributed policies. This notationis inspired by Lu and Kumar [1991], and a distributed policy is here defined asfollows.

3.1 Definition (Priority policy and distributed priority policy). In a situationwhen there is more than one possible task for a carrier to perform, the rule formaking the decision which one to perform is called a priority policy. If it fullfillsthe 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 decision may impact the flow of products through theproduction line, and impact, e.g., the production rate and the utilization gradeof the line. Two examples where this becomes clear are discussed in Example 3.2and 3.3.

11

12 3 Distributed priority policies

3.2 Example: Possible influence of a priority policy IConsider a process with two part types. Suppose that every twelfth minute1, onepiece of type A and one piece of type B arrive to a buffer outside a process (e.g. amachine). This gives the following situation: One piece of type A and one of typeB are waiting for being moved to a process, and no other pieces are relevant toconsider for this decision. Suppose the processing of A takes 10 minutes, while Bonly takes 2 minutes. If the carrier picks part A first, and B thereafter, B will haveto 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 thecarrier takes B before A, B will only have to wait for two minutes and the averagetime will be only (2 + (2 + 10))/2 = 7 minutes.

3.3 Example: Possible influence of a priority policy IIConsider a production line where the same carrier is used for picking parts fromthe 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 takinga finished piece and leave to the sink. Which one is the best to do first? Althoughwe do not have to consider the risk of causing a deadlock (since p-sop prohibitssuch tasks), one choice may still be ‘better’ than the other. If the consecutiveprocess for the part loaded from the source is idle, and the part waiting for thesink does not block anything nor is in a hurry to be delivered, it would seemobvious to give the highest priority to pick the part from the source. For theopposite situation, the optimal priority is also quite simple to figure out, but itquickly becomes trickier for all combinations of situations in between.

These examples illustrate the need for priority policies, as well as the limitationswith a distributed policy (i.e. each decision has to be made at each individualcarrier, 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 importanceand influence of priority decisions in different situations, than give a detailed analysis of a specificsituation.

3.2 Framework for priority policies in P-SOP 13

Even without an explicit priority policy, a decision will be made if the line iscontrolled by p-sop generated code. This decision will be made by the orderof the tasks in the iec 61131-3 st code. Such an implicit priority policy wouldindeed work, but the order of the task written in the p-sop language (which isthe same as the order in the st code) is not intended to affect the performanceand 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 theoptimization is rather tricky, and it seems very hard (if not impossible) to developa general optimal policy for priorities without including simulation. However,the simulation-based optimization would of course require a simulation modelable 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 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 decision may either be all avail-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 theadjacent 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-sopitself 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 distributedpolicies, which is a limitation, hence the alignment as a limitation.


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 sinceall jobs follow the same technological routing through the machines.’. This co-incide with the problem arising from the priority problem within p-sop, exceptthe 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 doesnot 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 listingof some interesting and relevant approaches and results follows:

1. For the priority decisions between different part types waiting for the sameprocess, Perkins and Kumark [1989] gives some very interesting suggestionsfor distributed priority policies, suitable even for rather general productionlines with nonacyclic and non-unidirectional sequences. The idea here is toalways choose a piece of the part type of which there are most waiting, orsome generalization thereof.

2. Seidman [1994] raises a warning finger regarding lack of stability3 for sucha simple policy as ‘First come, first served’ (also known as ‘First in, firstout’) in nonacyclic flows. The practical implications of these results on thework within p-sop and this thesis remains however rather unclear.

3. Lu and Kumar [1991] indicate that two good distributed policies, althoughnot necessarily optimal, are the Least Slack (LS) policy and the Last BufferFirst 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 remainingprocessing for each piece when each decision is made. The piece withthe highest expected delay (or, if there are no delays, the smallest mar-gin to delivering time) are always chosen in each decision. This policytends to minimize the variance in processing times.

• The LBFS relies on the idea to give higher priority to a piece the shorterit has to the sink. A similar idea is mentioned in Haupt [1989], namedFewest 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 performanceof FBFS are shown to be rather poor, while the performance of theLBFS are of the same magnitude as LS, but minimizing the mean ofthe processing time rather than the variance of it.

4. In Real-Time Operating Systems, priority inversion is an issue occurringwhen 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 foreach piece, roughly a guarantee that a piece will not get stuck in the line for an indefinite time.

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 practiceis replaced by the low priority of task L, usually a undesired phenomenanamed ‘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 astask H claims to use the same shared resource as task L. Task L will hencenot be interrupted by task M as long as it inherits the (high) priority fromtask H, and task H will, as desired, be executed as soon as possible and notaffected by task M. A more detailed description is given in Renwick andRenwick [2004].

Different research papers use different goal functions for measuring the perfor-mance of the priority. For example, Lu and Kumar [1991] evaluates differentpolicies against the mean processing time per piece, the standard deviation ofprocessing times per piece as well as a linear combination thereof.

None of the approaches referenced above uses any explicit time intervals for thedecisions, 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 tobe available has to be made. One of the intentions behind limitation 2 is theavoidance of ‘single point of failure’, i.e., a part in a system which causes theentire system to stop if this (single) part is failing. A priority policy where allinformation about the entire line is required to make a decision would make allcommunication links single points of failure. The idea of using all available infor-mation when available (but not causing failure when not available) has alreadybeen exploited in Danielsson et al. [2012], and is not what is sought here. Fromthis, the design choice is made that each priority decision must be made only withthe information of parts waiting for being served by the carrier. This coincideswith 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 mostresearch referenced above, the priority decisions are treated as they are madeat the entrance of each process. However, as long as there are no more thanone robot loading each machine, the situations seems to be comparable and theresults 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. Asthe p-sop code is built up out of tasks, the LBFS policy corresponds to give astatic priority to each task depending on its ‘distance’ to the sink.


3.4 Definition (Static priority). A priority is called static if it istime-independent.

Within the idea of ‘last buffer first served’, some variations are possible to do. Theversion of the policy used in this thesis is described in definition 3.5 below, andillustrated 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, theone with the highest priority is chosen.The priorities are assigned according tothe following rule, for each sequence at a time:

Suppose the sequence contains no indefinite loops (although it may contain thesame buffer, process etc a finite times), and the longest path in the sequence isfinite and contains n tasks.

Let P0, P1, · , Pn−2 be a decreasing sequence of real numbers such that Pi > Pj ifi < j. The priority of task T is then Pk , where k is the number of tasks in thelongest path from task T.

3.6 Example: LBFS PolicyThis 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) inthe entire program. Note that no considerations about which robot performingwhich task has to be taken into account. It is also worth to note that this policywill mostly give preference to the shortest path through the sequence.

One possible evolution of the LBFS policy, mentioned in Haupt [1989], would beto assign priority not depending on the number of remaining steps, but on thetotal time of the remaining steps. (I.e., if a carrier can choose between movingpart A or part B, part A will be preferred if the total remaining processing time ofpart A is less than the total remaining processing time of part B, although theremay be fewer steps left for part B.) Such a policy would, obviously, require someinformation about processing times, for which the present version of p-sop lackssupport.

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 individualpriorities to single parts directly in the language (due to principle 1 above) asdone in LS, the approach to assign variable priorities to different part types cameup. 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 describedin definitions 3.7.

3.5 Implementation issues 17

Figure 3.2: A flowchart defining a sequence. A block with a P represent aprocesses, 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 accordingto the LBFS principle. The priority is proportional to the thickness of theline. If, for instance, all tasks (movements of pieces between the ‘boxes’)are performed by the same robot, this tells the robot to always prioritize thepiece nearest the sink.

3.7 Definition (VPP Policy). Suppose there is an expectation that Xi% of theproduced parts delivered to sink S should be of part type i, and suppose Yi% ofthe 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 thepresent part types. PLBFS is calculated as a LBFS priority according to definition3.5. PP ART (i) is treated online as a control signal to control Y to be kept as closeas possible to the setpoint X.

The VPP policy does not fulfill the definition of a distributed priority policy, sincethe PP ART (i) is a signal needed to be communicated online through the entiresystem. However, if the implementation of the priority is done in a way thatPP ART is treated as equal to 0 if the values for some reason are not available at thedecision moment, the policy boils down to the LBFS policy in those cases, whichis a distributed policy.

3.5 Implementation issues

This section deals with the question how to implement a priority policy in iec61131-3 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 inthe p-sop code, which makes it quite manageable and readable. The readabilityof the auto-generated code must not be affected.


Hence, a straightforward solution is to exploit this structure, instead of changingit. 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 3steps:

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 structureshown in listing 3.1.

IF NOT Prior i tyCheck THENPrior i tyCheck := 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 1DO

IF BlueRobotPrior i tyArray [ i ] . Request AND j = 0 THENBlueRobotPrior i tyArray [ i ] . Allow := TRUE ;j := i ;ELSIF BlueRobotPrior i tyArray [ i ] . Request AND BlueRobotPrior i tyArray [ i ] . Pr io >=

BlueRobotPrior i tyArray [ j ] . Pr io THENBlueRobotPrior i tyArray [ j ] . Allow := FALSE ;BlueRobotPrior i tyArray [ i ] . Allow := TRUE ;j := i ;END_IF

BlueRobotPrior i tyArray [ i ] . Request := FALSE ;END_FORPrior i tyCheck := 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 BoxWithUnproces sedPieces ( 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 Prior i tyCheck THENBlueRobotPrior i tyArray [ Taskindex ] . Request := TRUE ;BlueRobotPrior i tyArray [ Taskindex ] . Pr io := 0.8249606 ( * For example * ) ;

ELSIF BlueRobotPrior i tyArray [ Taskindex ] . Allow THENBlueRobotPrior i tyArray [ 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 Prior i tyCheck ) AND ( * Order i s per formed * ) 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.

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 examplein 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 wasmeasured. One experiment was performed with the lbfs policy (accoording todefinition 3.5), and two experiments were performed with priorities given with arandom number generator insted of the lbfs algorithm. The results are presentedin Table 3.1.

Policy LBFS Random RandomTime 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 pieceswere produced, in the beginning with only the lbfs priority policy, thereafterchanged to the vpp policy with a demanded ratio of 0.5/0.5, and thereafter witha demanded ratio of 0.8/0.2. The result is shown in Figure 3.4. A simple PIDcontroller with ad hoc-parameters was used to generate the control signal PP ART .

3.7 Discussion and concluding remarks on thepriority 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 thediscussion in Section 3.7.1, the situation in the demonstrator is of a rather low interest for the kindof 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 weeksfor the line.


Figure 3.4: The experiment with the vpp policy in the demonstrator. In thebeginning, the lbfs policy was used. Therafter, after 8 produced parts, thevpp policy was introduced online, with a demanded ratio of 0.5/0.5. After 16produced parts, the demanded ratio was changed to 0.8/0.2. The dashed lineshows the expected difference between the produced number of part of type1 and part of type 2 if the demanded ratio was delivered as expected. Thecontinous line is the difference between the actual number of produced parttypes. The dotted line is the control signal generated with a PID controllertaking the actual production as an output and the expected production as areference signal.

the demonstrator5.

However, based on the impression when studying the demonstrator performingthe experiments, an explanation of the results is that the demonstrator is a systemwhere rather few priority decision have to be made, and the influence of those arerather limited6. Hence, there are no big possible performance improvements togain.

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 policythan a randomized priority. The differences are in the magnitude of 5%. However, the total time forproducing ten pieces is only one performance measure out of several possible, and a more significantdifference would be needed to make a stronger statement about the performance of the differentpolicies. With these results, a more careful investigation and evaluation of different performancemeasures would be needed to make a stronger statement.

6The only shared resources that seems in practice to bound the performance is the conveyor beltand 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

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 ofthe conveyor was not addressed further, since the focus with the demonstratorproject was to make a demonstration of the p-sop concept, and the focus in thepriority policy development was to manage the general situations emerging in ap-sop auto generated code. Instead, an ad-hoc algorithm was used to manage theloading and unloading of the conveyor. 7

The loading of new parts onto the conveyor was simply done in the experimentsby just letting the produced parts delivered to the sink, i.e., the conveyor, stayon the conveyor and be ‘produced’ again. This, together with the tricky interde-pendence between the source and sink caused by the conveyor, gives the prioritydecisions a very limited influence on the decision on which part types that enterthe line. Of course it is crucial to control which pieces enter the line to affectthe 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 madeit possible to explicitly choose between different part types from the source withpriorities 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 thepart 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 onlya 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 ratioon 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 productswith 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, butseems to run into some saturation, and remain rather constant. What probablyhappens is that the accumulated buffers are emptied on parts of one type, butwhen 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 thesepriority 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 inthe 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.


can be explained by the demonstrator setup. Therefore, no statement can be donefor production lines in general, but only for lines similar to the demonstrator8.The results reflect rather the challenge of finding a distributed priority policythat 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 prioritydecisions, one relevant aspect (which became clear when performing the experi-ments) is that two different carriers are blocked from interacting with the samebuffer at the same time, for the sake of collision avoidance. This means, e.g., thatwhen 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 thisblocking is not investigated, but when observing the flow in the demonstrator asthe 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 thegenerality in the language, it seems to be very hard to find a good priority policymeaningful 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 modelwould probably still be useful for in advance picking the most promising policyout of the policies mentioned or suggested in Section 3.3 and 3.4. A simulationmodel 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 inCarlsson et al. [2011], and an interesting framework for the offline optimizationis found in Svensson [2012].

8In, e.g., Lu and Kumar [1991], the lbfs policy is shown to improve performance in simulations ofa production line for semiconductors. It seems probable that this result would be valid also for sucha 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 incomplex situations.

4Graphical 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, andthe 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 planningand re-planning of an entire production line. This means, for instance, that onlyrather limited programming skills should be needed. The simplicity of the p-soplanguage 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 arederived:

• 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 alternativeto a text-based tool.

23

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 waspossible to sketch some basic p-sop program and autogenerate p-sop code whichwas not entirely correct and hence not possible to compile. Although it was of nopractical use, it was in some sense defining the style and the level of ambition fora 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. Otherwisethere 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 userin 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 throughthe 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 namesarrows and blobs will be used in this chapter.

It was an idea in version 1.0 that it should be possible to sketch the sequenceswith a layout similar to the physical layout of the line. This idea probably stemsfrom an intuitive answer to the question ‘how to make a gui easy and simple touse?’, 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 stressingof a meaningful use of it.

Version 1.0 was implemented in Microsoft PowerPoint with Visual Basic2. Thismay not be the very most suitable environment for this kind of program, anda 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 guia low threshold for new users.

Design choices for version 2.0

One explicit restriction on the possibility to sketch the product sequence similarto the ‘physical’ sequence on the real line was decided in version 2.0: it is not

2Software packages from Microsoft, http://www.microsoft.com

http://www.microsoft.com

4.4 Results 25

allowed to sketch any loops in the gui. A loop in this context means a path ina sequence returning to the very same blob in the gui. In the case of a productflow returning to the same physical item on the line, this item has to be sketchedtwice 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, toavoid 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., settingpriorities (see Example 3.6 for an example).

The current version of the p-sop compiler generates iec 61131-3 st code thatcannot distinguish between a piece before and after a process, which gives riseto problems, e.g., when a part visits the very same buffer twice during the flowthrough the line with a process in between. This problem will probably be fixedin coming p-sop versions, but there is a need for a fix for this problem for thedemonstrator. The fix used to get rid of this problem is a convention that the idnumber 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 inthe gui. This is however rather complicated to implement, since the gui allowbranchings 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 aseparate slide. The reason for this was that there were some information neededfor 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 ofuser 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 thehighest priority, and not all features in p-sop are implemented in the gui version2.0.

4.4 Results

The Graphical User Interface was developed and shown able to produce correctand readable p-sop code. A review of the functionality developed is found in thissection, as well as a detailed example. An impression of the gui environment isshown in Figure 4.1.

Functionality in the GUI

The gui contains the following features:

• Graphical user dialogs for simple generation of new blobs with accuratesettings as well as for changing settings of existing blobs

• Graphical user dialogs for simple generation of new arrows as well as chang-ing settings of existing arrows


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 thepresent version of p-sopmentioned 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 formanually 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) andPower 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 ofthe code implementation can be found in Appendix C.

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


there is a unique integer assigned, defining the order they will be listed in thep-sop code (which later affects the iec 61131-3 code). The buffer blobs also eachhave 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, thegreen color of the arrow from BufferSTN400(1) to BufferSTN200(3) means thatthis task will be performed by the portal robot, since the portal robot is definedas 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 Figure4.3 and 4.4. Each arrow corresponds to a task in p-sop. With a simple clickon the button ‘Generate p-sop code’ in the gui, the code shown in listing 4.1is automatically generated. Due to the issues with separating processed and un-processed parts discussed in Section 4.3, the sequences are divided into differentparts, 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 { Mi l l ingPart0 [ 1 ] , Mi l l ingPart1 [ 1 0 1 ] , TurningPart0 [ 2 ] , TurningPart1 [102] } ;

4.5 Discussion and concluding remarks on the GUI 29

SEQUENCE( Mil l ingPart0 ){

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( Mil l ingPart1 ){

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 withthe auto generated iec 61131-3 st code is done by the p-sop compiler, and notthe 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, thebehaviour 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


can be made rather intuitive, and the threshold for re-planning of the productionprobaly 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 arenot the very best in menus, notations etc. This area would definitely be necessaryto 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, andthe complexity will probably increase rather fast with long product sequences.Some functions in p-sop are still not implemented in the gui, which also couldbe 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 howeverunclear 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 theplanning and re-planning of production lines. However, of advantages over atext-based tool (as the p-sop language) is basically based on personal experiencesfrom industry among the involved persons. Although no reasons for question-ing this conclusion was raised during the work with this thesis, there is to theauthors knowledge no research supporting this conclusion. Hence, it would beinteresting to evaluate a gui, with fully implemented functionality, against thetext-based p-sop language.

5Results and summary

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

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

• The proposed structure for implementing priority decisions in iec 61131-

3 st was shown to work. The proposed priority policies did not gave anynoteworthy difference in the performance of the demonstrator.

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

31

6Concluding 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 theoreticalframework, 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 shopfloor with the implementation of the demonstrator project – it is indeed possibleto 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 than10 000 lines. Altogether, p-sop appears to be a rather powerful and efficient toolfor programming an entire production line. Although there are many options forfurther work and some issues with the current implementation, p-sop seems tobe a subject for a future commercial product. Accordingly, one may question ifthe 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 ofp-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 followingthemes are of relevance:

• Development of the automatic generation of simulation models from thep-sop code, as proposed in Carlsson et al. [2011]. Such a model would inthe first step be used to get a (rough) estimation of the performance of thesystem with different priority settings etc., and could in the next step beused for e.g. optimization.

33

34 6 Concluding remarks

• Support for a wider range of product lines, as discussed in Section A.3

• Further development of the compiler:

– Implementation of the structure for priority decision proposed in Chap-ter 3.

– A more advanced interface between the function blocks and the autogenerated iec 61131-3 st code. In the current version, p-sop waitsuntil a function block buffer says ‘Ready’. However, in the situationswith, e.g., the conveyor and the human carrier, it would be useful tonotice the function block ‘There is an incoming piece awaiting you’, sothe conveyor can hold a plate and the operator knows whether she isrequested or if she can continue the coffee break.

– A solution to the problem with confusing processed and unprocessedpieces mentioned in Section 4.3.

There are also some more thoughts and disucssion about further work in Section2.4.1, 3.7.3, and 4.5.1

AThe P-SOP language

A.1 Concept idea

In the framework of the FLEXA project, a high-level language for productionlines named p-sop has been developed. p-sop is developed in a research context,and the focus of the language is hence rather to adress some research questionsthan being a market-ready product.

p-sop is defined in a language specification (Danielsson [2011]), and is appendedby a compiler for compiling the p-sop code into iec 61131-3 st code. iec 61131-3is a standard for languages for plcs, and the compiled code is ready for download-ing to a plc controlling the line. p-sop is a product oriented language, and theuser defines the flow (i.e. sequence) of each product through the production line.Listing A.1 gives an example of a p-sop program related to Example 1.1.

/ * C o n f i g u r a t i o n s e c t i o n * /CONFIGURATION NAME PSOP ;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 { Dr i l l , Screwdriver , Hammer, Inspect ion } ;CARRIER { RedRobot , BlueRobot , GreenRobot , HumanCarrier } ;SOURCE { BoxWithUnprocessedPieces } ;SINK { BoxWithProcessedPieces } ;BUFFER { F i r s t B u f f e r [ 5 ] , SecondBuffer [ 1 0 ] , ThirdBuffer [ 3 ] , FourthBuffer [ 1 0 ] ,

Recycl ing [ 1 0 ] } ;LOCATION { HumanUntacking } ;PART { PieceWithOneScrew [ 1 ] , PieceWithOneNail [ 2 ] } ;

/ * Sequence s e c t i o n * /SEQUENCE( PieceWithOneScrew )

{1 : BlueRobot BoxWithUnprocessedPieces −> F i r s t B u f f e r ( 1 ) ;

35

36 A The P-SOP language

2 : RedRobot F i r s t B u f f e r ( 1 ) −> D r i l l ;3 : RedRobot D r i l l −> SecondBuffer ( * ) ;4 : RedRobot SecondBuffer ( * ) −> Screwdriver ;5 : RedRobot D r i l l −> Screwdriver ;6 : RedRobot Screwdriver −> F i r s t B u f f e r ( 2 ) ;7 : BlueRobot F i r s t B u f f e r ( 2 ) −> BoxWithProcessedPieces ;

} ;

SEQUENCE( PieceWithOneNail ){

1 : BlueRobot BoxWithUnprocessedPieces −> F i r s t B u f f e r ( 3 ) ;2 : RedRobot F i r s t B u f f e r ( 3 ) −> D r i l l ;3 : RedRobot D r i l l −> ThirdBuffer ( * ) ;4 : GreenRobot ThirdBuffer ( * ) −> Hammer ;5 : GreenRobot Hammer −> ThirdBuffer ( * ) ;6 : RedRobot ThirdBuffer ( * ) −> Inspect ion ;7 : RedRobot Inspect ion −> IF (NOT iwInspectionOK ) F i r s t B u f f e r

( 5 ) ;8 : BlueRobot F i r s t B u f f e r ( 5 ) −> Recycl ing ( * ) ;9 : HumanCarrier Recycl ing −> FourthBuffer ( * ) VIA HumanUntacking ;10: GreenRobot FourthBuffer ( * ) −> Hammer ;11: RedRobot Inspect ion −> IF ( iwInspectionOK ) F i r s t B u f f e r ( 4 ) ;12 : BlueRobot F i r s t B u f f e r ( 4 ) −> BoxWithProcessedPieces ;

} ;

Listing A.1: An example of p-sop code related to Example 1.1

A.2 Compilation into IEC 61131-3 ST

The compiler generates readable iec 61131-3 st code, which will avoid deadlocksituations to occur for all possible routes. Its structure is illustrated by listingA.2.

( * 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 : * )( * PieceWithOneScrew ( 1) * )( * 1 : BlueRobot BoxWithUnproces sedPieces ( 1) −> F i r s t B u f f e r ( 1) * )IF BoxWithUnprocessedPieces . in . ProductToLeaveAND ( BoxWithUnprocessedPieces_Id [ 1] = 1)AND NOT BoxWithUnprocessedPieces . out . CarrierPerformsOrderAND BlueRobot . in . ReadyToTakeNewOrderAND NOT BlueRobot . out . PerformOrderAND F i r s t B u f f e r . in . ProductToGetAND ( F i r s t B u f f e r _ I d [ 1] = 0)AND NOT F i r s t B u f f e r . out . CarrierPerformsOrder

THENBoxWithUnprocessedPieces . out . carr ierPerformsOrder := TRUE ;BlueRobot . out . PerformOrder := TRUE ;BlueRobot . out . IdNo := 1 ;BlueRobot . out . FromProcess := 0 ;BlueRobot . out . FromBuffer := 0 ;BlueRobot . out . FromSource := 1 ;BlueRobot . out . FromStorage := 1 ;BlueRobot . out . ToProcess := 0 ;BlueRobot . out . ToBuffer := 1 ;BlueRobot . out . ToSink := 0 ;BlueRobot . out . ToStorage := 1 ;BlueRobot . out . ViaLocation := 0 ;F i r s t B u f f e r . out . idNo := 1 ;F i r s t B u f f e r . out . Storage := 1 ;F i r s t B u f f e r . out . carr ierPerformsOrder := TRUE ;BlueRobotTaskID1Op0_001101010 := TRUE ;

END_IF( * Running * )IF BlueRobotTaskID1Op0_001101010 THEN

A.3 Limitations of P-SOP 37

IF BlueRobot . in . ProductPicked AND NOT BoxWithUnprocessedPieces . out . ProductPickedTHEN

BlueRobot_Id [ 1] := BoxWithUnprocessedPieces_Id [ 1 ] ;BlueRobot_Operation [ 1] := BoxWithUnprocessedPieces_Operation [ 1 ] ;BoxWithUnprocessedPieces_Id [ 1] := 0 ;BoxWithUnprocessedPieces_Operation [ 1] := 0 ;

END_IFBoxWithUnprocessedPieces . out . ProductPicked := BlueRobot . in . ProductPicked ;IF BlueRobot . in . ProductLeaved AND NOT F i r s t B u f f e r . out . ProductLeaved THEN

F i r s t B u f f e r _ I d [ 1] := BlueRobot_Id [ 1 ] ;F i r s tBuf fer_Operat ion [ 1] := BlueRobot_Operation [ 1 ] ;BlueRobot_Id [ 1] := 0 ;BlueRobot_Operation [ 1] := 0 ;

END_IFF i r s t B u f f e r . out . ProductLeaved := BlueRobot . in . ProductLeaved ;( * Stop running * )IF BlueRobot . in . OrderPerformed OR BlueRobot . in . CancelOrder THEN

BoxWithUnprocessedPieces . out . ProductPicked := FALSE ;F i r s t B u f f e r . out . ProductLeaved := FALSE ;BoxWithUnprocessedPieces . out . carr ierPerformsOrder := FALSE ;BlueRobot . out . PerformOrder := FALSE ;BlueRobot . out . IdNo := 0 ;BlueRobot . out . FromProcess := 0 ;BlueRobot . out . FromBuffer := 0 ;BlueRobot . out . FromSource := 0 ;BlueRobot . out . FromStorage := 0 ;BlueRobot . out . ToProcess := 0 ;BlueRobot . out . ToBuffer := 0 ;BlueRobot . out . ToSink := 0 ;BlueRobot . out . ToStorage := 0 ;F i r s t B u f f e r . out . carr ierPerformsOrder := FALSE ;BlueRobotTaskID1Op0_001101010 := FALSE ;

END_IFEND_IF

Listing A.2: Automatically generated iec 61131-3 st code for the p-sop task‘1: BlueRobot BoxWithUnprocessedPieces -> FirstBuffer(1);’

A.3 Limitations of P-SOP

The design of p-sop makes some implicit assumptions about the line. For in-stance, a carrier is supposed to move only one piece at a time, there is alwayssome kind of buffer inbetween two carriers, and there is no support in p-sop forthe kind of interdependency that occurs for the conveyor in the demonstrator dis-cussed in Section 3.7.1. Hence, p-sop is not a general language for all possibleproduction lines, but a high-level language suitable for some cases.

BTechnical details

B.1 Production simulator at PTC

Some technical details on the production simulator used for implementing thedemonstrator can be found in table B.1.

39

40 B Technical details

STN100(master)

STN200 STN300 STN400 STN500

plc for thecell

abbAC500

abbAC500

abbAC500

abbAC500

abb AC500

Programminglanguage

iec61131-3

iec61131-3

iec61131-3

iec61131-3

iec 61131-3

Programminginterface

CoDeSysV2.3

CoDeSysV2.3

CoDeSysV2.3

CoDeSysV2.3

CoDeSysV2.3

Robot abbIrb2400

abbIrb1500

abbIrb1400

Portal robotdeliveredby Binarand con-trolled bya BinarBRSC1 PLC

Programminglanguage

rapid rapid rapid iec 61131-3

Programminginterface

Handhelddevice

Handhelddevice

Handhelddevice

BiSoft 1131

Machine JohnfordVMC650

StorebroSTM2000

Conveyor

Table B.1: Technical details on the demonstrator

CGraphical user interface

implementation

A few lines from the implementation of the gui in VisualBasic for Application.

Listing C.1: Snippets from two functions used for interpreting the blobs inPowerPoint and writing the p-sop code

’’ C r e a t e s a P−SOP header with c o n f i g v a l u e s and

d e c l a r a t i o n s’Sub CreateHeader ( FileName As String )

Dim MachineNames , RobotNames , SinkNames , BufferNames ,PartNames , PartNamesExt ( ) , SourceNames , ViaNames AsVariant

Dim i , j , k , n As IntegerDim Name, Vers ionStr As StringDim posl , posr As IntegerDim num As Integer

Open FileName For Output As #1

’ . . .

’ P r i n t headerPrint #1 , " �/*�Generated�with�P−SOP� for �PowerPoint�V2. 0 �*/ "

Print #1 , "CONFIGURATION�NAME� " ; Name ; " ; "Print #1 , "CONFIGURATION�USER� " ; UserName ; " ; � "Print #1 , "CONFIGURATION�REV�� " ; Vers ionStr ; " ; "

41

42 C Graphical user interface implementation

Print #1 , " #DEADLOCKAVOIDANCE"Print #1 , " "Print #1 , " /*�Declarat ion � s e c t i o n � */ "Close

’ Generate p r o c e s s s e c t i o nMachineNames = FindItemsOnAllSlides (ITEM_PROCESS , True )Call PrintAl l I tems ( MachineNames , ITEM_PROCESS , FileName )

’ Generate c a r r i e r s e c t i o nRobotNames = FindItemsOnAllSlides (ITEM_CARRIER , True )Call PrintAl l I tems ( RobotNames , ITEM_CARRIER , FileName )

’ . . .

CloseEnd Sub

’’ Find a l l t y p e s on a l l s l i d e s and r e t u r n them as an array’Function FindItemsOnAllSlides ( ItemType As Integer , C r i t i c a l

As Boolean ) As VariantDim ItemNames ( ) As StringDim NumberOfItems , j , i , a , k As IntegerDim ItemNamesTemp ( ) As StringDim Done As BooleanDim s As ShapesDim Exist , Ok As Boolean

NumberOfItems = 0’ For a l l s l i d e sFor a = 1 To Act ivePresenta t ion . S l i d e s . Count

Set s = Act ivePresenta t ion . S l i d e s ( a ) . ShapesWith sFor i = 1 To . Count

’ Check i f i t i s a p r o c e s sI f ItemType = ITEM_PROCESS Then

’ i f p r o c e s s box c o n t a i n s a c o l o r i t i s ok , i fnot assume i t i s pure comment t e x t

I f . Item ( i ) . AutoShapeType = ITEM_PROCESS And .Item ( i ) . F i l l . V i s i b l e <> msoFalse Then

Ok = TrueElse

Ok = FalseEnd I f

43

E l s e I f . Item ( i ) . AutoShapeType = ItemType ThenOk = True

ElseOk = False

End I f

’ I f a v a l i d i tem was foundI f Ok Then

’ Save Item nameDim Name$Name = . Item ( i ) . TextFrame . TextRange . Text

I f . Item ( i ) . AutoShapeType = ITEM_BUFFER Then ’Add t h e []− t h i n g t o t h e b u f f e r namesName = Name + " [ " + . Item ( i ) . tags (

PLACES_TAG) + " ] "End I f

’ Check i f t h e i tem a l r e a d y e x i s t in t h e l i s tE x i s t = FalseI f NumberOfItems > 0 Then

For j = 0 To NumberOfItems − 1I f ItemNamesTemp ( 0 , j ) = Name Then

E x i s t = TrueEnd I f

NextEnd I f

’ I f a new item then add i t t o t h e l i s tI f Not E x i s t Then

ReDim Preserve ItemNamesTemp(0 To 1 , 0 ToNumberOfItems )

ItemNamesTemp ( 0 , NumberOfItems ) = NameI f . Item ( i ) . tags (INDEX_TAG) = " " Then

ItemNamesTemp ( 1 , NumberOfItems ) = " 0 "Else

ItemNamesTemp ( 1 , NumberOfItems ) = . Item ( i ) .tags (INDEX_TAG)

End I fNumberOfItems = NumberOfItems + 1

End I fEnd I f

NextEnd With

Next

44 C Graphical user interface implementation

I f NumberOfItems = 0 ThenReDim Preserve ItemNames (0 To 1)

Else ’ s o r t in a s c e n d i n g index o r d e rReDim ItemNames (0 To NumberOfItems − 1)For i = 0 To NumberOfItems − 1

ItemNames ( i ) = ItemNamesTemp ( 0 , i )Next ii = 0j = 0While NumberOfItems − j > 0 And j < 1000

For k = 0 To NumberOfItems − 1I f ItemNamesTemp ( 1 , k ) = CStr ( i ) Then

ItemNames ( j ) = ItemNamesTemp ( 0 , k )j = j + 1

End I fNext ki = i + 1

WendEnd I f

FindItemsOnAllSlides = ItemNames

I f NumberOfItems = 0 And C r i t i c a l ThenDim TypeName As StringTypeName = GetItemTypeName ( ItemType )MsgBox "No� " + TypeName + " � items�found ! "End

End I fEnd Function

Bibliography

H. Carlsson, J. Nilsson, F. Danielsson, and B. Lennartson. Automated generationof discrete event system simulation models for flexible automation. In FlexibleAutomation and Intelligent Manufacturing (FAIM), 21nd International Con-ference on, pages 852–832, 2011. Cited on pages 4, 22, and 33.

F. Danielsson. P-sop language description 1.4. Technical report, University WestSweden, Engineering Science, Electro and automation technology, 2011. Citedon page 35.

F. Danielsson, H. Xing, and B. Svensson. A simulation-based optimization ap-proach for holonic manufacturing systems. In Flexible Automation and Intel-ligent Manufacturing (FAIM), 22nd International Conference on, 2012. Citedon pages 3, 13, 15, and 22.

ec.europa.eu. Advanced flexible automation cell - transport - research andinnovation - european commission. http://ec.europa.eu/research/transport/projects/items/flexa_en.htm, 08 2012. Cited on page 3.

flexa-fp7.eu. FLEXA – Advanced Flexible Automation Cell. http://www.flexa-fp7.eu/objectives.htm, 08 2012. Cited on page 3.

J.N.D. Gupta and E.F. Stafford. Flowshop scheduling research after five decades.European Journal of Operational Research, 169(3):699–711, 2006. Cited onpages 13 and 14.

R. Haupt. A survey of priority rule-based scheduling. OR spectrum, 11(1):3–16,1989. Cited on pages 14 and 16.

J. He et al. Integration of human operator into a robot-based multi-agent holonicsystem. To be published. Cited on pages 4 and 8.

IEC. IEC 61131-3 ed2.0 Programmable controllers - Part 3: Programminglanguages. International Electrotechnical Commission, Geneva, Switzerland,2003. Cited on page xi.

IEC. IEC 61499. International Electrotechnical Commission, Geneva, Switzer-land, 2005. Cited on page 4.

45

http://ec.europa.eu/research/transport/projects/items/flexa_en.htm

http://ec.europa.eu/research/transport/projects/items/flexa_en.htm

http://www.flexa-fp7.eu/objectives.htm

http://www.flexa-fp7.eu/objectives.htm

46 Bibliography

iec61499.de. IEC61499 - International Standard for Distributed System. http://www.iec61499.de, 08 2012. Cited on page 4.

S.H. Lu and PR Kumar. Distributed scheduling based on due dates and bufferpriorities. Automatic Control, IEEE Transactions on, 36(12):1406–1416, 1991.Cited on pages 11, 14, 15, and 22.

J.R. Perkins and PR Kumark. Stable, distributed, real-time scheduling of flex-ible manufacturing/assembly/diassembly systems. Automatic Control, IEEETransactions on, 34(2):139–148, 1989. Cited on page 14.

M. Petre. Why looking isn’t always seeing: readership skills and graphical pro-gramming. Communications of the ACM, 38(6):33–44, 1995. Cited on page24.

A. Pichler and C. Wogerer. Towards robot systems for small batch manufacturing.In Assembly and Manufacturing (ISAM), 2011 IEEE International Symposiumon, pages 1–6. IEEE, 2011. Cited on page 4.

K. Renwick and B. Renwick. How to use priority inheritance. Embedded SystemsProgramming, 2004. Cited on page 15.

T.I. Seidman. ‘first come, first served’ can be unstable! Automatic Control, IEEETransactions on, 39(10):2166–2171, 1994. Cited on page 14.

B. Svensson. A Simulation-Based Optimisation Method for PLC Systems. PhDthesis, Chalmers University of Technology, 2012. Cited on page 22.

http://www.iec61499.de

http://www.iec61499.de

Index

alternative route, 8

bottleneck, 2buffer, xii

carrier, xii

deadlock, 2, 36demonstrator, 5–9, 19–22, 31, 39distributed control code, 4distributed priority policy, 11

error-handling, 8

FLEXA, 3, 35flexible manufacturing cell, 1flexible routing, 1flowshop scheduling, 13function block, 7, 9, 34

goal function, 15Graphical User Interface (gui), xi, 3, 7,

23–31

human carrier, 8human inspection, 8

IEC 61131-3, xi, 4, 7, 17, 35, 39IEC 61499, 4inspection, 1, 2, 8

Last Buffer First Served Priority Policy(LBFS), 14–21

Least Slack Priority Policy (LS), 14

multiple part types, 7

operator, xii, 1, 2, 4, 8

P-SOP, xi, 3, 5, 7, 9, 13, 21, 22, 31, 33,35–37

part, xiipart type, xiipath, xiiPLC, xi, 7, 35, 39priority, 8, 11–22, 31priority inheritance, 15, 21problem formulation, 4process, xiiproduct, xiiProduction Technology Center, 7

sequence, xiisimulation-based optimization, 3single point of failure, 15sink, xiisource, xiiST, xistability (for priority policies), 14static priority, 16static priority policy, 16

task, xiitechnical details, 39

unidirectional, 14

Variable Part Priority Policy (VPP), 17–21

visualization for supervision, 8

47

48 Index

Upphovsrätt

Detta dokument hålls tillgängligt på Internet — eller dess framtida ersättare —under 25 år från publiceringsdatum under förutsättning att inga extraordinäraomständigheter uppstår.

Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner,skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat för icke-kommersiell forskning och för undervisning. Överföring av upphovsrätten viden senare tidpunkt kan inte upphäva detta tillstånd. All annan användning avdokumentet kräver upphovsmannens medgivande. För att garantera äktheten,säkerheten och tillgängligheten finns det lösningar av teknisk och administrativart.

Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsmani den omfattning som god sed kräver vid användning av dokumentet på ovanbeskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådanform eller i sådant sammanhang som är kränkande för upphovsmannens litteräraeller konstnärliga anseende eller egenart.

För ytterligare information om Linköping University Electronic Press se förla-gets hemsida http://www.ep.liu.se/

Copyright

The publishers will keep this document online on the Internet — or its possi-ble replacement — for a period of 25 years from the date of publication barringexceptional circumstances.

The online availability of the document implies a permanent permission foranyone to read, to download, to print out single copies for his/her own use andto use it unchanged for any non-commercial research and educational purpose.Subsequent transfers of copyright cannot revoke this permission. All other usesof the document are conditional on the consent of the copyright owner. Thepublisher has taken technical and administrative measures to assure authenticity,security and accessibility.

According to intellectual property law the author has the right to be men-tioned when his/her work is accessed as described above and to be protectedagainst infringement.

For additional information about the Linköping University Electronic Pressand its procedures for publication and for assurance of document integrity, pleaserefer to its www home page: http://www.ep.liu.se/

© Andreas Svensson

http://www.ep.liu.se/

http://www.ep.liu.se/

Documents

Automatic Generation of Control Code for Flexible Automation