Generative programming in industrial crane applications

(1)

Mika Raudaskoski

GENERATIVE PROGRAMMING IN INDUSTRIAL CRANE APPLICATIONS

Information Technology and Communication Sciences

Master of Science thesis

February 2021

(2)

ABSTRACT

MIKA RAUDASKOSKI: Generative programming in industrial crane applications Master of Science thesis

Tampere University

Master of Science in Electrical Engineering February 2021

Time, resources and cost are being optimized in programming by using premade programs or by using parts of these programs. This reuse of premade programs or parts of premade program still needs manual work which comes from the need to build main program frame and adding premade program parts to the program. This raises the question, is it possible to automate creation of programs if these programs are for similar systems?

This thesis’ purpose is to answer that question from industrial overhead cranes programmable logic controller perspective. In this thesis generative programming possibilities from three different programmable logic controller vendors are studied. These vendors are Siemens, ABB and Beckhoff. After study one vendor will be chosen and this vendors technology will be tested to generate industrial overhead cranes programmable logic controller project.

Result from this thesis is summary of each vendors possibility to generate programmable logic controller program and proof of concept generative program which is made with chosen vendors technology.

Keywords: Generative programming, PLC, Siemens, ABB, Beckhoff

(3)

TIIVISTELMÄ

MIKA RAUDASKOSKI: Generative programming in industrial crane applications Diplomityö

Tampereen yliopisto

Sähkötekniikan diplomi-insinöörin tutkinto-ohjelma Helmikuu 2021

Ohjelmoinnissa aikaa, resursseja ja kustannuksia pyritään optimoimaan uusiokäyttämällä aikaisemmin tehtyjä ohjelmia tai näiden osia. Tämä ohjelmien tai ohjelmaosien uusiokäyttäminen kuitenkin vaatii manuaalista työtä itse ohjelmarungon teossa ja ohjelmien tai ohjelmaosien liittämiseen koodissa. Tästä herääkin kysymys, pystytäänkö ohjelman luominen automatisoimaan, jos ohjelmat tulevat saman kaltaisiin järjestelmiin?

Tässä diplomityössä on tarkoituksena tutustua teollisuusnosturin ohjelmoitavien logiikkojen kannalta tähän edellä mainittuun kysymykseen. Tässä työssä tullaan tutustumaan kolmeen eri logiikka valmistajan (Siemens, ABB, Beckhoff) mahdollisuuteen automatisoida teollisuusnosturiohjelman luominen heidän ohjelmoitavalle logiikalleen. Lopuksi yksi valmistajista valitaan ja tämän valmistajan laitteelle luodaan esimerkki ohjelma, joka pystyy luomaan teollisuusnosturin ohjaukseen käytettävän logiikkaohjelman.

Tuloksena diplomityöstä on yhteenveto jokaisen valmistajan mahdollisuudesta automatisoida ohjelmoitavan logiikan ohjelman luonti ja esimerkki valitun valmistajan teknologialla tehdystä automatisoidusta ohjelman luonnista.

Avainsanat: generoiva ohjelmointi, ohjelmoitava logiikka, Siemens, ABB, Beckhoff

(4)

PREFACE

Writing of the master’s thesis alongside with work isn’t that easy task as it first seems, but I’m grateful that my manager Tommi Turku gave me opportunity for this. What comes to subject of the thesis I would like to thank Juha-Pekka Suomela for giving interesting subject and being supervisor from Konecranes side and giving help, advice, and feed- back during this thesis. I also thank Sami Repo for supervising.

Hyvinkää, 31.1.2021

Mika Raudaskoski

(5)

LIST OF FIGURES

Figure 1. Different movements of a simple overhead crane [1]... 2

Figure 2. Waste to energy crane with auxiliary hoist [1]... 3

Figure 3. Charging crane [1]. ... 4

Figure 4. Example of ladder programming language. ... 7

Figure 5. Example of function block diagram programming language. ... 8

Figure 6. Example of sequential function chart programming language. ... 8

Figure 7. Risk reduction: general principle [7]. ... 11

Figure 8. PLC Project, Executable program and Hardware configuration. ... 12

Figure 9. Hardware configuration in Siemens automation software. ... 13

Figure 10. Remote I/O station with different input modules (Siemens automation software). ... 13

Figure 11. Drive with different telegram modules (Siemens automation software). ... 14

Figure 12. Executable program and hardware configuration dependence (Siemens automation software). ... 15

Figure 13. ABB’s functional safety PLC “module” implemented with normal PLC [20]. ... 16

Figure 14. Simple POU which writes input to output. ... 21

Figure 15. Example of two different hardware configurations. ... 24

Figure 16. Example of two different executable programs that must be able to be made ... 26

Figure 17. Relationships between TIA Portal and Openness object models [15 p.1038]. ... 29

Figure 18. ABB’s Automation Builder Software. ... 32

Figure 19. TwinCAT 3 XAE and Automation Interface test software... 34

Figure 20. Areas which presented interfaces control. ... 35

Figure 21. TIA Portal, Creating hardware device from global library... 41

Figure 22. DIF as data exchange format between PLC project and electrical drawing. ... 43

Figure 23. How TIA Portal Openness access PLC tags in TIA Portal [15, p.52]. ... 44

Figure 24. Online protection levels in TIA Portal ... 45

Figure 25. One variation of industrial overhead crane automation system. ... 47

Figure 26. First approach configurator UI. ... 48

Figure 27. First approach configurator TIA Portal generated hardware configuration. ... 49

Figure 28. Second approach configurator TIA Portal copied hardware and executable program from Global libraries. ... 50

Figure 29. Needed data and how these are implemented. ... 51

(8)

ABBREVIATIONS

PLC Programmable logic controller

WTE Waste to energy

POU Programming organization unit

HMI Human-machine interface

CPF Communication profile family

CP Communication profile

DP Distributed peripheral

PA Process automation

GSD General station description

CC Conformance Class

I/O input/output

API Application programming interface

XML Extensible Markup Language

AML AutomationML

GSDML General station description Markup Language DLL Dynamic-link libraries

CoDeSys Controller Development System XAE eXtended Automation Engineering

IP Internet Protocol

TCP Transmission Control Protocol

IPC Industrial PC

GVL Global Variable List

UI User Interface

GSD general station description TIA Totally Integrated Automation DIF Data Interchange Format

(9)

1. INTRODUCTION

This chapter presents background and aim of the thesis and basic information regarding industrial overhead cranes. First background and aim of the thesis is presented. Sec- ondly overhead cranes are presented with two different crane type examples to create understanding of how different cranes can be.

1.1 Background and Aim of the thesis

Programmable logic controllers (PLC) are used in different industries to simplify electrical system and to achieve functionalities that are not possible with classical relay-controlled system. In overhead cranes PLC’ main task is to control crane movement with help of field devices and functionalities that are built in the PLC program. Sway control (stabili- zation of the load during bridge and/or trolley travel motions) is good example of one of these features which is harder to implement without PLC.

Aim of the thesis is to create proof of concept configurator that can generate crane PLC project with given input variables. Configurators idea is that user needs to give general variables such as number of movements, wanted functionalities and application as input.

Configurator would then generate PLC project skeleton which can be used in crane which falls into input variables given by user.

At the starting point of thesis automation pre-engineering (creating PLC project) takes around 20-40 hours of automation engineers time. This manual programming also intro- duces possible programming errors made by automation engineer which affects automation program quality. With the configurator automation pre-engineering phase and human error are wanted to be minimized as much as possible. This will lower automation engineer’s workload through crane delivery and reduces cost of automation engineering in each project.

Before making proof of concept configurator, survey regarding different PLC vendors possibilities for generative programming with vendor specific software and devices must be made. This is done to ensure that it is possible to generate PLC project with the technologies of the evaluated vendors. After survey one of the vendors will be chosen and with that vendor’s technology proof of concept configurator will be made.

(10)

1.2 Overhead crane

Overhead crane is a type of crane found in industrial environments. These cranes are used to lift and move objects and material. These cranes consist of three main movement types, bridge, trolley and hoist (Figure 1). Bridge movement means movement in building runway, Trolley movement means movement in bridge runway and hoist movement means hoisting and lowering movement.

Figure 1. Different movements of a simple overhead crane [1].

There are as many different overhead crane types as there are customers from different industries. Therefore, Waste To Energy (WTE) and steel industries charging cranes are presented to give good understanding of different complexity levels of cranes.

WTE cranes (Figure 2) are used in waste to energy powerplants as waste or ash pro- cessing cranes. On the waste side in WTE powerplant WTE cranes handle incoming waste and cranes feed waste to boilers, which keeps the power generating process going. On the other end of WTE powerplant ash cranes handle by-product of the process, ash. These cranes move by-product ash to trucks and trucks thereafter takes ash to paying customer. Ash from WTE powerplant can be used as ingredient of asphalt and concrete, for example.

(11)

Figure 2. Waste to energy crane with auxiliary hoist [1].

WTE cranes usually are fully autonomous meaning that they don’t need operators to work, but they still need someone to watch over them in case of system fault or if some- thing unexpected happens. These cranes usually only have three movements, one trolley, one bridge and one hoist. WTE cranes can also have auxiliary hoist intended for opening clogged boiler infeed hopper if necessary. This additional hoist will add one more movement to total picture.

Steel cranes are used in steel industry and that is why there are wide variety of different crane types under steel cranes. One example of steel cranes is charging crane (Figure 3). These cranes are used to transport scrap metal and liquid metal to a furnace. Charg- ing cranes usually have semiautomatic functionalities meaning that crane operation needs always crane operator, but there are some automatic functionalities in use for example crane can drive autonomously to selected target (for example to the furnace).

(12)

Figure 3. Charging crane [1].

Charging cranes often have one bridge, two trolleys and two hoists. These cranes have two trolleys and two hoists because unloading of the scrap metal and liquid metal is done by tilting pot or container where material is in. Main hoist and auxiliary hoist both take care of the lifting, but the tilting of pot or container is done by lifting auxiliary hoist.

(13)

2. PLC PROGRAMMING

This chapter’s purpose is to create basic understanding of PLC programming and present example of current way of making PLC project for industrial overhead crane. First basics of PLCs is presented to give all necessary knowledge that are needed for creating a PLC project. Secondly a PLC project is presented to give understanding what PLC project contains and what things should be possible with each vendors technology for generative programming. Thirdly ways of making PLC project for industrial overhead cranes is presented to create deeper understanding of crane automation engineering.

2.1 Basics of PLC

For generative programming and for some of the functionalities of generative programming it is mandatory to understand the basics of PLC, standardized programming languages, fieldbuses and functional safety. These listed things can and will affect the way that the program is generated, and, in some cases, syntax of the generative programming files changes due of different programming language used in PLC program.

2.1.1 Programmable logic controller

PLC is specifically designed computer for industrial automation which controls automation system. These computers can control large complex factories or parts of the factory.

This sets demand for high reliability for these computers. Downtime of these computers can mean big financial losses, and, in some cases, downtime can put others in risk.

PLC-systems have their own standard series International Electrotechnical Commission 61131, which defines all necessary functionalities of the PLC-system [2]. This standard scatters PLC to smaller functionality parts which represent all necessary basic functionalities that every PLC should have to be capable to control industrial automation systems.

These functionalities are:

Power-supply functions provide correct supply voltage for PLC-system and electrical isolation between PLC-system and main supply. This functionality in other words isolates power electronic from centralized processing unit and other critical components.

Interface functions to sensors and actuators are functions that are connected to ma- chine or process that PLC control. These functions convert input signals to appropriate signal levels for processing and convert output signals to appropriate signal levels for

(14)

field devices. For example, in cranes there can be 4-20mA analogical and 230V/24V digital signals which must be converted to appropriate signal level for processor to handle and understand.

Programming, debugging, testing and documentation functions provide necessary functionalities for programming, debugging, testing and documenting. This functions purpose is to enable PLC vendors automation software to communicate with the PLC and give listed functionalities within that communication.

Communication function provides possibility to exchange data between different sys- tems. These systems in crane application can be for example another PLC, PC or fieldbus devices.

Human-machine interface (HMI) functions provide necessary information for operator and possibility for operator to interact with automation system. These functions are used in cranes when HMI panel is installed from which user can monitor and control crane.

Signal processing functions contains functions and data storages to run created PLC program. These functions and data storages are:

Data storage provides memory locations where it is possible to store image of I/O and data structures.

Application programme storage provides memory location for user made pro- gram which contains series of instructions of periodic or event-driven execution.

This storage also provide location for initial values for application program data.

Operating system functions provide functions to manage internal PLC-system interdependent functions. These functions can be for example configuration control, memory management or application programme execution management.

Application programme functions provide functions for executing application program.

2.1.2 Programming languages and Programming organization units

For PLC programming there are in total five different standardized programming languages [3, p.9]. Out of these, two are textual languages and three are graphical languages. Textual programming languages as the name says are text-based programming languages which are usually powerful programming languages for mathematical operations and calculations. Graphical programming languages are on the other hand much

(15)

more used due to simplicity and they are easier understood than standard textual programming languages.

Instruction list is textual list type programming language where every line contains one instruction. These instructions contain operation (operator) and what data is affected of operation (operand). Example of instruction list programming language is given in Code 1.

//Copying Example 1 to Example 2 in instruction list 2 A #Example1

= #Example2

Code 1. Example of instruction list programming language

Even though instruction list is still listed as standard PLC programming language, it is still outdated and that is why instruction list will not be contained in next edition of PLC programming languages standard. [2, p.195]

Structure text is textual programming language which is derived from Pascal program- ming language. This programming language is very powerful when used for mathematical functions or processing data. Example of structure text programming language is given in Code 2.

//Copying Example 1 to Example 2 in structure text 2 Example2 := Example1;

Code 2. Example of structure text programming language.

Ladder diagram is graphical programming language which gets its name by resembling like the structure of ladder. This programming language consist of contacts (inputs), coils (outputs) and other packed functions. Example of ladder diagram programming language is given in Figure 4.

Figure 4. Example of ladder programming language.

(16)

Function block diagram is graphical programming language which gets its name by using blocks to represent functions. Example of function block diagram is given in Figure 5.

Figure 5. Example of function block diagram programming language.

Sequential function chart is graphical programming language where functionality is presented as steps and conditions, which needs to be reached before next function can be executed. Example of sequential function chart is given in Figure 6.

Figure 6. Example of sequential function chart programming language.

These programming languages are used inside programming organization units (POU) which are defined as functions, function blocks, classes or programs [2, p.58]. Purpose of these POUs is to slice program to smaller well-defined portions which furthermore increases modularization of the code. PLC program can sometimes even have hundreds of POUs which all can use any of the presented programming languages and every POU can be called multiple times in program cycle. This information is important in generative programming, since POUs manipulation syntax can vary depending of the POUs programming language. Also, because PLC program runs in cycles it is necessary to add calls for created POUs to get the functionality that the POU is made for.

2.1.3 Fieldbuses

Automation system usually is complex system where distances between PLC and field devices can be significant. In crane this significant distance can be seen for example

(17)

when PLC is in floor level and there are fieldbus position measurement devices in bridge and trolley. This significant distance between field devices and PLC can mean without fieldbuses high amount of cabling, which is impracticable, expensive and hard to main- tain due the amount of cabling. Therefore, fieldbuses are used to move more data only by using singular cable.

Fieldbuses have their own standard series in which all much used communication profile families (CPF) and communication profiles (CP) are listed and furthermore each of the CPFs have their own standard. In total there are twenty standardized CPFs if CPF 7 isn’t taken in account due to lack of market relevance [4, p.21]. In crane applications CPF 3 is most relevant and that’s why only CPF 3 is introduced in this thesis. CPF 3 is communication profile family which contains both PROFIBUS and PROFINET IO [4, p.21].

Under this CPF there is total of five different communication profiles.

PROFIBUS

PROFIBUS is electrically based on RS485 standard in which data moves through two wires and connections to devices are made with RS485 adapters. PROFIBUS is split up to two different communication profiles and these are PROFIBUS distributed peripheral I/O (DP) and PROFIBUS Process Automation (PA) [5, p.17]. Out of these two PROFI- BUS DP is designed for normal usage and PA is designed to be used in hazardous areas (Ex zones 0 and 1).

PROFIBUS system consists of master and slaves. Master in PROFIBUS network controls fieldbus and define communications. Slaves on the other hand only do what master requests. Both types of devices are furthermore identified by PROFIBUS address. These addresses are given to devices either by physically dialling address to device or with help of programming tool. This address can vary from 1-125 and each given address should be unique in that PROFIBUS network.

When PLC project is being made these PROFIBUS addresses will be needed to be added to hardware configuration with correct hardware device. This enables PROFIBUS communication between PROFIBUS devices and master can monitor PROFIBUS devices if any problems occur.

PROFINET IO

PROFINET IO is Ethernet-based automation standard which enables stations to access the network at any time. PROFINET system consists of IO-Controller which controls the automation task, IO-Devices which are field devices and IO-Supervisor which can monitor IO-Devices. PROFINET system enables simultaneous data transfer of several

(18)

nodes. PROFINET IO being an Ethernet-based automation standard enables real-time communication and topology information.

PROFINET IO is split to three different classes. These classes are PROFINET IO Con- formance Class A (CC-A), PROFINET IO CC-B and PROFINET IO CC-C where A class is the most basic while C is the most advanced class. Simplest CC-A provides real time and acyclic real time, support for standard Transmission Control Protocol / Internet Pro- tocol (TCP/IP) and topology support. CC-B has same functions as CC-A, but it also adds simple network management protocol. CC-C on other hand has all functionalities from CC-B, but it adds support for real-time data exchange with cycle times down to 31.25µs [6].

PROFINET IO devices are identified in PROFINET network with PROFINET names.

PROFINET name is unique name for every field device by which IP addresses will be assigned to a PROFINET devices. These names can be assigned with PROFINET name assigning tool. When PLC project is being made these PROFINET names and IP addresses must be added to hardware configuration with correct hardware device. PLC will use these PROFINET names to find corresponding PROFINET device and will assign the IP addresses to PROFINET devices. This way PLC can communicate with PROFINET device.

2.1.4 Functional safety

Functional safety in general means is design feature or practice where in case of failure or unexpected behaviour processes are driven down or to safe state to minimize hazards. For this practice there is standard series, which gives information and requirements for functional safety [7] and for process industry there is additional standard series regarding safety of automation system [8]. These two standards combined then provide all needed information and requirements for process industries safety automation system.

In process industry sector there are many hazards that can lead to impact on health, safety, environment and plant assets. Processes safety is best achieved by using inherently safe processes, but in some cases when this isn’t option will process requirements for protective system be determined with Hazard and Risk Assessment. Functional safety can be implemented to non-inherently safe processes with different technologies that can be mechanical, chemical, pneumatic, hydraulic, electric, electronic or programmable electronic. In cranes functional safety can be example mechanical, electrical or programmable electronic.

(19)

Machines also have their own safety related machinery standard [9] which will determine more specifically how to determine safety level of the machine and how safety can be improved. Risk reduction idea is presented in Figure 7 in which total risk is being reduced by adding different functional safety implementations.

Figure 7. Risk reduction: general principle [7].

2.2 PLC project

PLC project is concept of whole program that is later downloaded to PLC. This project consists of hardware configuration and executable program. In Figure 8 PLC project is shown in one of the vendors (Siemens) automation software. With some vendors functional safety is directly implemented to hardware configuration and executable program, but some vendors create separated slot to PLC project where functional safety devices and software will be handled.

(20)

Figure 8. PLC Project, Executable program and Hardware configuration.

2.2.1 Hardware configuration and executable program

Hardware configuration means part of the PLC project where automation systems physical devices and connections are presented and configurated. There are two different ways to build hardware configuration. One approach for standardized products is that every possible variation of different hardware device is presented in hardware configuration. In this approach excess devices that are not needed in that project will be deactivated from executable program. This way of making hardware configuration is easy parametrization, but this will affect the size of the project. Another way of making hardware configuration is to make it exactly as the physical automation system is. This way there will be more work doing hardware configuration, but project will be lighter.

Devices in hardware configuration can vary from PLC to HMI or from remote I/O station to motor drives. Figure 9 shows one example of possible hardware configuration in which CPU 1516F-3 presents PLC, TP900 Comfort presents HMI panel, SINAMICS G120 devices present drives and IM151-3PN devices present remote I/O. These all devices are connected with Profinet fieldbus (PN/IE_1). It is good to keep in mind that the hardware configuration can be presented differently in different vendor automation software.

(21)

Figure 9. Hardware configuration in Siemens automation software.

Some of the hardware devices can also have modules which can be added to this device to enable communication or to add functionality. For example, modules in remote I/O devices mean input or output cards by which it is possible to monitor and control automation system (Figure 10). In drives modules can determine communication profile and how much data is transferred between PLC and drive (Figure 11). All presented devices and even individual modules are possible to be deactivated from executable program in case if these devices or modules are not present or used.

Figure 10. Remote I/O station with different input modules (Siemens automation soft- ware).

(22)

Figure 11. Drive with different telegram modules (Siemens automation software).

After hardware configuration has been made it is possible to start working on executable program. Executable program is program which PLC runs cyclically and drives all needed functionalities. Executable program is dependent of hardware configuration because hardware configuration gives I/O addresses for each device. Therefore, hardware configuration should be made correctly and while making executable program program- mer should be sure that used I/O addresses correspond to wanted I/O in physical world.

I/O address dependence to hardware configuration is shown if Figure 12 in which IO device_1 has one digital input module and one digital output module. Hardware configuration gives I/O addresses to each IO device_1 module from which physical world data can be either read or controlled. In executable program part of the figure, digital input information is forwarded straight to digital output. In physical world this would mean that when first or second input in input module gets 24-volt signal, it would turn on 24-volt digital output on the output module.

(23)

Figure 12. Executable program and hardware configuration dependence (Siemens automation software).

2.2.2 Functional safety in PLC project

When functional safety is implemented to PLC project, it will bring many changes for hardware configuration and executable program. Firstly, if functional safety specified devices are used, will there be need for functional safety PLC device. This functional safety PLC can be same device that runs normal program, fully separated PLC which only runs functional safety or module/PLC which is implemented to same PLC project as normal PLC. Figure 13 shows ABB’s solution for functional safety where functional safety PLC is separate module connected to same rack where normal PLC is. Second from left (SM560-S module) is functional safety PLC and third from left is normal PLC (AC500-S)

(24)

Figure 13. ABB’s functional safety PLC “module” implemented with normal PLC [20].

Functional safety PLC itself brings some new features to PLC programming. One thing that functional safety PLC enables is redundant input monitoring. This means that if functional safety input module is used it is possible to monitor two inputs and confirm that these two inputs change states at the same time. There is also possibility to have redundant system in which one fault doesn’t cause process or machine to shut down. This would mean that there need to be two more functional safety inputs in use and more wiring to field devices. Functional safety PLC also enables use of functional safety POUs which is meant to be used to control functional safety field devices and functional safety I/O. Functional safety POUs can differ from standard POUs by disabling some features that can be used in normal executable program. These disabled features can be limiting programming languages, functions or data types that can be used in these POUs.

Functional safety PLC also enables in systems which use CPF 3, PROFIsafe fieldbus communication. PROFIsafe is functional safety communication for PROFI- BUS/PROFINET IO fieldbuses. PROFIsafe differs from PROFIBUS/PROFINET IO by adding “black channel” between devices when PROFIsafe communication is created.

Black channel is detection mechanism in PROFIsafe communication which will detect transmission rate and built-in errors. Purpose of the black channel is to reduce probability of undetected errors in fieldbus communication and thus ensure safe communication between functional safety devices.

(25)

2.3 Automation engineering in industrial crane applications

Pre-engineering phase of automation engineering for cranes consists of risk analysis from automation point of view, getting to know what special features customer wants and how these might affect crane automation and lastly creating necessary programs (PLC and/or HMI) for the crane. This whole pre-engineering phase can be time consuming and that’s why manual programming is wanted to be minimized.

2.3.1 Risk analysis and customer specific features

Each crane automation project starts by getting to know customers crane layout, check- ing possible needs for functional safety and getting to know what features customer wants for their crane. The need of automation functional safety is usually determined regarding of what kind of crane is delivered. For example, semiautonomous and fully autonomous cranes always have automation related functional safety added to ensure safety of other persons that might enter cranes operation area. This is usually handled by making cranes’ operation area closed and all entrances to cranes’ operation area is monitored. There also can be demand from customer side to reach certain safety level and this can affect for example position measurement of the crane.

2.3.2 Making automation project

After all requirements have been mapped out and electrical designing is ready, automation programming can be started. Depending on the product, there can be different ways of making automation project.

Standardized product

If product is standardized automation project making can be parametrization. This way the PLC project will have all possible combinations already built in. These features and devices will be then activated or deactivated depending on required features.

Non-standardized product

If product is non standardized there will be need for building whole automation project from scratch or by using somehow similar products automation project as template. After the decision hardware configuration must be checked within electrical drawings that the hardware configuration has all necessary automation devices and I/O cards. At this stage it is also necessary to check all connections with field devices that they are using correct protocols and they have correct communication addresses.

(26)

Hardware configuration also has all functional safety settings which must be checked if project has automation functional safety. Functional safety settings can be for example input cards dual input monitoring which can be used in earlier mentioned operation area door monitoring. Monitoring of operation area door could have two different switches in which one of them could be with normal open contact and the other one could be with normal closed contact. PLC would monitor if these two inputs change states at the same time and they don’t give same input value to input card. If these two inputs don’t switch states at the same time or if both inputs have same value will input card will inform PLC about monitoring error and PLC would stop the crane after receiving this information.

After looking up hardware configuration, symbol table must be updated. Symbol table is table where all I/O:s are listed and named with symbolic names, which makes PLC program much easier to understand. When symbol table has been updated it is time to start programming of the executable program. In this stage PLC program will be modified to fit projects needs and all needed functionalities will be programmed. Functional safety program will also be modified for project needs if there is functional safety automation needed.

Almost standardized product

Almost standardized products are made by using both standardized product and non- standardized products procedures. Depending on how standardized the product is there will be more or less manual programming.

(27)

3. GENERATIVE PROGRAMMING SOLUTIONS

This chapter explains what generative programming is, what are the benefits and what techniques there are for generative programming in PLC programming. First general information regarding generative programming is presented with information about benefits and challenges. Secondly different techniques are presented for generative programming.

3.1 Generative program

Generative program in this thesis means program that can make PLC project with help of vendor specific generative programming solutions for their automation software. For generating PLC project there can be application programming interface (API), scripts or eXtensible Markup Language (XML) exchange by which vendor has enabled generative programming in their automation software.

3.1.1 Benefits

Benefits of generative programming in industrial crane applications are decreased automation engineers pre-engineering time and cost. This will furthermore enable possibility to focus automation engineer resources to crane commissioning phase or to projects which need customization.

For cost and time wise savings that can be made are markable. For example, basic WTE project could have around 20-40 hours of pre-engineer programming, which contains PLC project making including HMI program. Knowing time that goes to pre-engineer programming and how large company Konecranes is, it is sure that this will lead to major financial savings and lower the workload in pre-engineering phase.

From program perspective generative programming will also improve program quality.

Meaning that bugs caused by manual programming and configuration steps in automation pre-engineering decreases. This furthermore means that all industrial crane programs can be brought to general solution, in which person working in other crane application can understand another crane applications functionality much easier. Program maintainability is also affected from generative programming. This is since created programs or POUs can be easily reused and this way size of maintained program will be smaller.

(28)

3.1.2 Challenges

Challenges of generative programming in industrial crane applications are needed flexibility and modularity. Generative program that generates PLC project should be easy to use and new devices should be easy to implement afterwards. Major challenge comes from vendor side. These challenges are life span of vendors automation software (each vendor has their own automation software by which they program their PLCs) and what functionalities vendor provides for generative programming. Generative program, which isn’t locked to certain vendors specific automation software version would be ideal out- come, but it is hard to foresee if this will be possible. Best scenario would be generative program which could generate PLC project despite which vendors PLC is in use, but this is not possible since every vendor has their own automation software and devices.

3.2 Generative programming solutions in PLC programming

Generative programming in industrial automation is quite new thing and some manufacturers have started making public API for their automation software to enable user made programs to control automation software. Even though all manufacturers don’t have public API it doesn’t mean that generative programming with that manufacturer’s PLC is impossible. There still possibility to mimic mouse and keyboard inputs with additional scripting software.

3.2.1 Application programming interface

“API is an interface that is defined in terms of a set of functions and procedures, and enables a program to gain access to facilities within an application.” [10]

Some automation manufacturers have public API for their automation software. This system enables commanding of the automation software and thus gives more flexibility to use manufacturers automation software at full potential with self-made software. Even though public API gives more flexibility it is still dependent on how manufacturer has implemented it to the automation software and thus some of the important functionalities can be missing from API.

3.2.2 PLCOpen XML and AutomationML

PLCOpen XML is XML based data exchange standard which focus is to accomplish project, program and library transfer from one development environment to another without much additional work [11]. Even though this data transfer has been standardized it doesn’t mean that every manufacturer should implement import/export function for

(29)

PLCOpen XML standardized XML file. Therefore, some vendors have their own specific XML schemas which they use to represent projects, programs or libraries in XML format.

This format can furthermore be translated to PLCOpen XML standardized XML file by using other programs and vendor specific XML schema.

In generative programming main advantage of PLCOpen XML and XML files are that they enable editing of POUs, hardware configuration and project just by editing XML text file. Even though PLCOpen XML and XML format is good way to modify project, libraries and program, it still doesn’t itself enable generative programming because it needs to be imported to automation software. Also writing program in XML format can be hideous process due of how large these XML Files can be for simple POU which moves input to output. Figure 14 shows this simple POU in automation software and appendix 1 shows this POU as Siemens’ XML exchange format.

Figure 14. Simple POU which writes input to output.

AutomationML (AML) is another XML based exchange format in PLC projects. AML was developed to enable data exchange between different design engineers. This will in automation engineering mean that, it is possible to get some parts of the hardware configuration from the AML file generated from electrical drawings. AML file works by repre- senting devices in electrical drawing for example as order numbers. These devices then have information regarding I/O and fieldbus connections in AML XML scheme. This then is decoded in automation software to represent same hardware structure as electrical drawing has. AML can also represent executable program, but this is only possible with sequential function chart programming language [12 p.28].

XML exchange and AML are not ideal data exchange between vendor specific automation software and generative program because amount of data in these files are huge.

Unfortunately, these data exchanges are in some cases only possibilities to manipulate PLC project and in some cases this data exchange can be AML standardized, PLCOpen XML standardized or vendors specific XML schema.

(30)

3.2.3 Controlling mouse and keyboard

Lastly one option is to control with additional program mouse and keyboard movement and this way to have full control of the automation software. This option is needed, if vendor doesn’t have public API or they haven’t implemented all needed functionalities to their API. In these situations, it is necessary to mimic mouse and keyboard usage.

This solution has some pros and cons, pros are that there aren’t any limitations of what can be done but drawback in this option is that there are way too many variables on play and exceptions are hard to handle. Using this method as only method to control automation software would lead to large development and everything would be fractal even if small changes are made to user interface (UI) (If shortcuts can’t be applied). Even though controlling mouse and keyboard isn’t the ideal option it can be needed even if vendor has good possibilities to generate PLC project.

(31)

4. VENDOR SPECIFIC SOLUTIONS

In this chapter requirements for vendors are presented and vendors own solution for generative programming is presented. First all requirements are presented with detail information what things should be possible. Secondly Siemens, ABB and Beckhoff are presented with additional knowledge about their solutions for generative programming.

4.1 Requirements

4.1.1 Hardware configuration

Possibility to create and manipulate hardware configuration is one of the key elements that is needed from chosen vendor. Need for manipulation of the hardware configuration comes from the fact that every crane doesn’t have all the same I/O devices and field devices.

For generating hardware configuration which represents physical hardware devices it must be possible to add new devices and add modules to devices. It should be possible to import new devices and modules from vendors own device catalogue or by using General Station Description (GSD) or General Station Description Markup Language (GSDML) file. GSD and GSDML files are descriptions of I/O devices provided by the device manufacturer [13], which enable adding these devices to hardware configuration and configuration of these devices. These GSD and GSDML files are standardized and can be used by every vendor to enable communication between their PLC and third- party device.

Devices and modules that are added to hardware configuration should also be possible to be parametrized even if the module or device is functional safety device or module.

Lastly communication fieldbus between field devices must be possible to be created and all connected device interfaces must be possible to be configurated if needed. Figure 15 shows example of two different hardware configurations which both should be able to be generated with same generator software. Hardware configuration example 1 consists of functional safety PLC (left side), one PROFIBUS remote I/O station (middle) and one PROFINET drive (right side). Second configuration consists of non-functional safety PLC (left side), two PROFIBUS remote I/O stations (bottom middle) and two PROFINET drives (up right).

(32)

Figure 15. Example of two different hardware configurations.

Requirement of hardware configuration manipulation is achieved when specific vendor has all listed functionalities in their generative programming solution. Another way to achieve this is if vendor has some other way to add devices to hardware configuration which can be for example library items, which can be imported to project. In other words, it should be possible to create working hardware configuration for every crane no matter what I/O devices, field devices or fieldbus crane has.

4.1.2 Symbolic naming of I/O

Symbolic naming of I/O should be possible with chosen vendors generative programming solution. This need comes from changing hardware configuration which means that in some cases there will be different I/O devices and changing amount of I/O with different functionalities. Symbolic names should be possible to be imported by using any kind XML exchange format.

Requirement for symbolic naming of I/O is achieved when it is possible to update symbolic names of I/O with XML exchange.

(33)

4.1.3 Executable program

Possibility to create and manipulate both functional safety program and normal program is needed from chosen vendor. Executable program creation and manipulation need comes from the fact that different types of cranes have different functionalities which will need to be added to PLC program. For example, if crane has two hoists with drives, drives must be added to hardware configuration and then both drives controls must be built into PLC program.

For standard and functional safety program it should be possible to import premade POUs and POU calls should be possible to be made with vendor specific solution. Ma- nipulation of POUs is also necessary due to the changing hardware configuration and different I/O:s used. With vendor specific solution it should be possible to generate different number of functions and to manipulate POUs as seen in Figure 16 where two different POUs are shown.

(34)

Figure 16. Example of two different executable programs that must be able to be made

In this figure (left side) Main [OB1] and Drive control [FB20] present POUs. Drive con- trol_DB [DB1] and Drive control_DB_1 [DB2] present instance databases for Drive control POU. In this figure Main [OB1] has two different scenarios. In executable program example 1 scenario automation system only has one drive which must be controlled and executable program example 2 scenario shows what same POU would look like if there were two drives in automation system.

(35)

This requirement is achieved when it is possible to manipulate standard executable program and as well functional safety program with vendor specific solution. Even though PLC programming languages are standardized it doesn’t mean that vendors generative programming interface work similarly.

4.1.4 Protection of the project

Possibility to add password protection to generated PLC project is needed from chosen vendor. This protection can be for example adding of password which will be needed if any changes are wanted to be made. Idea of this password protection is to restrict all unauthorized people to make changes to PLC project.

This requirement is achieved when it is possible to add different access levels to PLC project which will restrict opportunities for different users to make changes to PLC project.

4.1.5 Automation software control

Possibility to control automation software should be possible with chosen vendors solution. Meaning that vendor should enable by providing API or other methods to control their automation software. This is needed since all previous requirements would be meaningless if it is not possible to create new project or open existing project, check errors from the program, compile project and to save the project at the end.

This requirement is met when it is possible to start new instance of the vendor specific automation software, create new project, handle errors, compile program and in the end to save project.

4.2 Siemens

Siemens has long history in PLC market. Their first SIMATIC controller came out in 1958 and from that point onwards Siemens has expanded its SIMATIC family. Nowadays Sie- mens has four different SIMATIC series that are used widely in different industries, these are S7-300, S7-400, S7-1200 and S7-1500, out of these S7-1500 is newest series (introduced in 2013) and it also has most computing power out of these four. Each of the series also have multiple different versions which includes functional safety PLCs, PLCs with different fieldbus connections and more computing power. Siemens also has Indus- trial PCs (IPC) which with PLC software controllers can run same PLC program with small changes to hardware configuration.

(36)

4.2.1 Totally Integrated Automation Portal

Totally Integrated Automation (TIA) Portal is Siemens’ automation software which com- bines all Siemens’ programmable/configurable automation devices to one software. With TIA Portal it is possible for example to create PLC program, design HMIs, configurate networks and field devices and parametrize Siemens drives. Newest version of TIA Por- tal while making this thesis was V16.

TIA Portal has included API interface TIA Portal Openness with STEP 7 (PLC) and WinCC (HMI and SCADA) delivery from V13 SP1 onwards [14]. TIA Portal Openness is API interface for WinCC and STEP 7, which means third-party software can command TIA Portal through TIA Portal Openness to create PLC program or design HMI. TIA Portal Openness works by providing Dynamic-link libraries (DLL) via which it is possible to access TIA Portal platform. These DLLs are based on .NET Framework 4.6.1.

4.2.2 TIA Portal Openness

TIA Portal Openness has five different areas that it can access to TIA Portal [15 p.37].

These are:

Portal data which consists of tasks for commanding TIA Portal. These tasks can be for example creating new project, compiling project and saving project.

Project data which consists of tasks that are mainly used for accessing projects and project data. These tasks can be for example adding and deleting devices, adding fieldbuses and manipulation of device parameters.

PLC data which contains tasks for commanding TIA Portal to access PLC software and manipulating PLC device.

HMI data which contains tasks for commanding TIA to access PLC software and tasks to control HMI screen making. This is only for Siemens HMI panels.

Drive data which contains tasks for commanding TIA to access Siemens’ drives and these tasks can for example configurate Siemens drives. Currently other vendor drives are not possible to configurate with TIA Portal Openness

These areas can be accessed through object models provided by Openness. In Figure 17 some of the relationships between TIA Portal and Openness object models are shown. From this figure it is shown that project (project data) contains hardware configuration (device items), and these device items can be accessed depending on device either with PLC data (PLC software) or HMI data (HMI target).

(37)

Figure 17. Relationships between TIA Portal and Openness object models [15 p.1038].

In TIA Portal project which can have PLC or/and HMI project index is shown in left side.

Underneath this project there is devices & networks section in which hardware configuration and where all devices will be parametrized. When project has PLC there will be new section added (PlcSoftware) in which executable program, symbolic names of I/O and some executable program parameters are stored. If on the other hand HMI is added to hardware configuration there will be new section (HmiTarget) in which HMI program is stored.

With TIA Portal Openness it is possible to generate PLC project by using library items, XML exchange or by using Openness functions. XML exchange in TIA Portal is done in hardware configuration level with AML [15 p.936] and on executable program level with Siemens’ own XML schema. This means that if executable program done in Siemens’

software is wanted to be used in another vendors device, XML file must be converted to PLCOpen XML standardized format.

Hardware configuration with Siemens’ solution is possible to be made with many dif- ferent approaches. Siemens enables adding of devices and modules with use of their own device catalogue, GSD/GSDML files, XML (AML) exchange or by using library items

(38)

which are users own created and saved items. Out of these adding of devices from library is easiest way since all library items can be preconfigured and configuration through API isn’t needed even though it is possible. Siemens also enables adding of functional safety devices with all listed device adding methods.

What comes to communications, it is possible to create new fieldbus subnets to hardware configuration and furthermore connect devices to that subnet. After devices have been connected to subnet it is possible to configurate communication interfaces for every device.

Symbolic names of I/O on TIA Portal are located under PLC tags of PLC project. With Openness it is possible to export and import PLC tag tables with XML exchange. Tag table import and export can be done by using AML or Siemens’ own XML exchange schema. Difference between these two import and export XML exchange possibilities are that, what else is going to be imported or exported. When tag table is going to be imported with help of AML it will create new PLC device and I/O corresponding tags under this PLC device [15 p.1007]. On the other hand, when using Siemens’ own XML schema for tag import/export it is possible to import tag tables and single tags to already existing PLC [15 p.886].

Executable program with TIA Portal Openness can be created and manipulated with help of Siemens’ own XML exchange schema or library items. XML exchange on Open- ness enable modification of individual POUs and library items enable storing premade POUs that doesn’t need to be modified. TIA Portal Openness version 16 also enable importing and exporting of functional safety POUs and thus it is possible to manipulate functional safety POUs in XML format [15, p.868]. Manipulation of the POU in practise mean changing of the POUs functionality.

Protection of the project is possible with TIA Portal Openness to some extent. TIA Portal has five different access levels for online protection which are from highest to lowest: full access including fail-safe (fail-safe means functional safety in Siemens systems), full access, read access, HMI access and no access. Normal access level can be chosen from TIA Portal Openness and password can be given to higher access levels if wanted. This access can for example deny downloading fail-safe or normal software to PLC. Offline password cannot be changed from TIA Portal Openness. This means that PLC project itself can’t be protected from unauthorized users.

Control of automation software with TIA Portal Openness it is possible to control TIA with portal data and project data area functions. These enable all necessary functions to create new project, check errors, compile and saving project.

(39)

Addition to PLC project generation it is possible to use TIA Portal Openness for generating HMI programs with HMI data functions and to configurate Siemens’ drives with drive data. These functionalities might help automating HMI making and parametrization of Siemens’ drives if they are used. These are good additions for required PLC project generation if in the future for example HMI making is wanted to be automatized.

4.2.3 Summary of Siemens’ solution

Siemens has enabled good amount of TIA Portal functionalities in their API interface.

These functionalities enable generating PLC program with help of library items and XML exchange. One concern regarding Siemens is that how often they release new versions of TIA Portal and TIA Portal Openness. Currently Siemens has released new version of TIA Portal almost every year. This dense version updating will affect lifetime of crane configurator and configurator maintainability. This is since some of the features or functionalities can be changed in upcoming versions and this means generative program should be updated as well.

Overall Siemens’ solution to enable generative programming is good. Good addition also is that, it is possible to create HMI programs through Openness. This enables possibility to automate making of HMI in the future.

4.3 ABB

ABB is Swiss-Swedish multinational corporation which is specialized to different sectors of electrical engineering and automation technology. For industrial automation ABB has one PLC series, AC500. AC500 has four different CPUs in AC500 series, which are AC500 (basic model), AC500-eCo (Eco model), AC500-S (Safety model) and AC500- XC (Condition model).

4.3.1 Automation Builder and Controller development system

Automation builder (Figure 18) is ABB’s automation software for configurating, programming, debugging and maintaining automation projects [16]. Automation builder is hardware configurating tool where devices can be added and fieldbus connections to devices can be made for normal and functional safety devices. For PLC programming ABB uses controller development system (CoDeSys) which is implanted to their Automation Builder software. Automation Builder version at the time of making this thesis was 2.2.3.

CoDeSys itself is made by CODESYS Group which is used by many different automation

(40)

manufacturers as programming tool. CoDeSys is made to fit PLC programming language standard.

At the time of making this thesis ABB doesn’t have API or any kind of interface by which it would be possible to control Automation Builder. This lack of automation software control will lead to need for mimicking mouse and keyboard inputs if generative programming is done with ABB’s devices.

Figure 18. ABB’s Automation Builder Software.

In Automation Builder on the left side is the project which has possibility for panel project or PLC project. Underneath PLC device (PLC_AC500V2) there is executable program editor (Application) and hardware configuration. In Figure 17 IO_Bus and Extension_Bus devices are modules which are connected to PLC_AC500.

4.3.2 Generative programming in Automation Builder and CoDeSys

With Automation builder it is possible to use PLCOpen XML standardized XML files to create hardware configuration and executable program. At the time of making this thesis there is still some problems with hardware configuration import [17], which will probably be fixed in the future. CODESYS on the other hand has CODESYS UML and CODESYS

(41)

Application composer, which could be used for generating executable program, but ABB hasn’t implemented these to Automation Builder [17].

Hardware configuration on ABBs Automation builder should be done by mimicking mouse and keyboard inputs even if there would be working PLCOpen XML import for hardware configuration. This means that PLC project generator software would be fractal to small changes done in UI. ABB doesn’t have similar library functionality as Siemens has.

Symbolic naming of I/O could be done with PLCOpen XML import if it works. At the time of making this thesis only possibility to name I/O:s is by mimicking mouse and keyboard inputs.

Executable program on ABBs solution would be possible to be generated with help of PLCOpen XML for now. This can change in the future if ABB chooses to implement CODESYS UML and CODESYS Application composer to their Automation builder.

4.3.3 Summary of ABB’s solution

ABB’s possibilities for generative programming are narrow. This is due of the fact that hardware configuration import doesn’t yet work correctly and only possibility to generate PLC program is with PLCOpen XML. This can change in the future if ABB will create their own interface to control Automation builder. Even if ABB wouldn’t create their own interface, implementing of CODESYS UML and CODESYS Application composer would increase possibility to automate some parts of PLC project making.

4.4 Beckhoff Automation

Beckhoff Automation is German multinational corporation which has specialized to automation technology. Beckhoff Automation was founded in 1980 and from that point on Beckhoff Automation has expanded its product range with IPC systems, I/O devices, motion solutions and HMI panels. Beckhoff has wide range of different Embedded PCs and IPCs for different applications which run PLC software controller.

4.4.1 TwinCAT 3 – eXtended Automation Engineering

TwinCAT 3 – eXtended Automation Engineering (XAE) (Figure 19) is Beckhoff’s automation software by which it is possible to program their IPC:s. This automation software is implemented to Microsoft Visual Studio [18]. TwinCAT XAE works at the same time as

(42)

hardware configuration tool and programming tool for both normal devices and functional safety devices. Version of the TwinCAT at the time of making this thesis was 3.1.

Since TwinCAT V2.11 Beckhoff has implemented Automation Interface for their Twin- CAT automation software, with which it is possible to manipulate TwinCAT XAE projects.

Automation interface communicates with TwinCAT XAE via Component Object Model (COM) and thus all COM-capable programming languages can be used [19 p.9].

Figure 19. TwinCAT 3 XAE and Automation Interface test software

In TwinCAT 3 XAE on the left side is the project which has subfolders for different systems. In this thesis PLC, SAFETY and I/O subfolders are most meaningful. PLC subfolder holds PLC executable programs and variable tables. SAFETY subfolder holds functional safety standardized executable program and some parameters which are relevant for functional safety. I/O subfolder holds all hardware devices regardless if it is functional safety or not.

On right side excluded MainWindow application there is editor view. in this section depending on where you are on project there can be accessible parameters or code editor like shown in Figure 18. In code editor view upper section is for determining used variables and bottom part is for the executable code. Programming language shown in figure is structure text.

(43)

4.4.2 Automation Interface

Automation Interface can be split up to two levels in which level 1 interface enables nav- igation and referencing of the objects in TwinCAT configuration and level 2 interface enables further manipulation of objects that are referred by level 1 interface [19 p.103- 104]. Figure 20 presents areas that each of the interfaces control.

Figure 20. Areas which presented interfaces control.

Level 1 interface contains two interfaces from which one of them is ITcSysManager and another one is ITcSmTreeItem. ITcSysManager interface is the main interface of the TwinCAT Automation interface and this interface enables basic operations to configurate TwinCAT 3 XAE. These basic operations can be for example creating of new project, search of tree items in project or save project. ITcSmTreeItem interface on the other hand enables interactions with so called tree items, which are devices which are in the project. ITcSmTreeItem gives functionalities for creating these tree items and deleting them. In some parts of the project ITcSmTreeItem also can import and export XML files of the tree item.

Level 2 interface on the other hand has fourteen helper interfaces which are used to- gether with level 1 interfaces. Level 2 interfaces are focused for enabling manipulation to PLC section of the project. With level 2 interface it is possible to create new PLC project with PLC code. PLC POUs are possible to be created directly by using interfaces or they can be created by importing PLCOpen XML file exchange or by using library items.

Hardware configuration with Automation Interface is possible to be done by creating new devices with Automation Interface by using GSD or GSDML file, TwinCAT catalogue or importing XML file of the device. Added devices can be either functional safety or regular devices and these devices I/O configuration can be made through Automation Interface. Beckhoff has separated functional safety settings and moved them under safety section of the project. At the time of making this thesis there is only possibility to

Generative programming in industrial crane applications

Mika Raudaskoski