Portability of IEC 61499 Compliant Software

Portability of IEC 61499 compliant software

Alexander Hopsu

School of Electrical Engineering

Master’s thesis Helsinki 21.1.2019

Supervisor

Prof. Valeriy Vyatkin

Advisor

Dr Udayanto Atmojo

Aalto University, P.O. BOX 11000, 00076 AALTO www.aalto.fi Abstract of the master’s thesis

Author Alexander Hopsu Title Portability of IEC 61499 compliant software Degree programme Electronics and Electrical Engineering Major Control, Robotics and Autonomous Systems Code of major ELEC3025 Supervisor Prof. Valeriy Vyatkin Advisor Dr Udayanto Atmojo Date 21.1.2019 Number of pages 70+18 Language English Abstract This master’s thesis investigates the portability features of three different IEC 61499 standard compliant tools. Firstly, the thesis introduces the standard’s capabilities, then illustrates its use with a few example cases. The study continues by focusing on migrating the basic and composite function block types and system architecture with application networks and device configurations from one tool to another. A converter program is subsequently created using Python programming language to automate the required modification process, thus enabling the files to migrate between the compliant tools. The study takes into consideration NxtStudio, FBDK and 4DIAC software tools. In every tool, similar function blocks and system structures are created. The portability of these created elements is examined between the tools, resulting in a table that numerically evaluates the portability from one tool to another. Keywords IEC 61499 standard, portability, compliant tool, converter program, NxtStudio, FBDK, 4DIAC

Aalto-yliopisto, PL 11000, 00076 AALTO www.aalto.fi Diplomityön tiivistelmä

Tekijä Alexander Hopsu Työn nimi IEC 61499 -standardia noudattavien ohjelmistojen tietojen siirrettävyys Koulutusohjelma Elektroniikka ja sähkötekniikka Pääaine Pääaineen koodi ELEC3025 Säätötekniikka, robotiikka ja autonomiset järjestelmät Vastuuopettaja Prof. Valeriy Vyatkin Työn ohjaaja TkT Udayanto Atmojo Päivämäärä 21.1.2019 Sivumäärä 70+18 Kieli Englanti Tiivistelmä Tässä diplomityössä tutkitaan kolmen erilaisen IEC 61499 -standardia noudattavan ohjelmiston tietojen siirrettävyyttä keskenään. Työssä käydään ensin läpi standardissa olevia ominaisuuksia, ja muutama esimerkkitoteutus oikeisiin sovelluksiin tuodaan esille. Tätä seuraa tutkimus, joka keskittyy standardin perus- ja komposiittifunktiolaatikoiden sekä järjestelmän arkkitehtuurin funktiolaatikkoverkon ja laitekonfiguraatioiden siirtämiseen yhden sovellustuottajan ohjelmasta toisen sovellustuottajan ohjelmaan. Tutkimuksen tuloksiin perustuen kehitetään Python-kielinen muunnosohjelma, joka suorittaa tarvittavat muutokset eri ohjelmistoissa tehtyihin tiedostoihin, jotta ne olisivat siirrettävissä toisesta ohjelmasta toiseen ohjelmaan. Tutkielma keskittyy NxtStudio, FBDK ja 4DIAC ohjelmistoihin. Jokaisessa ohjelmistossa luodaan samanlaiset funktiolaatikot ja järjestelmät, joiden siirrettävyydestä toiseen ohjelmaan tehdään numeerinen taulukko kertoen siirrettävyyden onnistumisesta. Avainsanat IEC 61499 -standardi, siirrettävyys, noudattava ohjelmisto, muunnosohjelma, NxtStudio, FBDK, 4DIAC

Preface

I want to thank Professor Valeriy Vyatkin and my instructor Dr Udayanto Atmojo for their good guidance and effort to this work.

Helsinki, 21.1.2019 Alexander E. M. Hopsu

Contents

Abstract ...... 3 Tiivistelmä ...... 4 Preface ...... 5 Contents ...... 6 Abbreviations...... 8 1 Introduction ...... 9 2 Background ...... 11 2.1 IEC 61131 standard ...... 11 2.2 IEC 61499 standard ...... 12 2.3 Software portability ...... 14 2.4 Industrial motivations for portability ...... 15 2.5 Evolution of the IEC 61499 standard ...... 16 2.6 Case studies of using IEC 61499 standard ...... 16 2.6.1 Porting to the IEC 61499 standard: A case study of shoe manufacturing sector ...... 17 2.6.2 A case study of composing IEC 61499 application on Intelligent Mechatronic Components . 20 2.6.3 A case study on the “plug-and-play” features of the IEC 61499 function blocks ...... 21 2.6.4 Using IEC 61499 standard for “smart” digital ecosystem ...... 24 2.6.5 Smart, distributed and wireless production demo line in IEC 61499 standard ...... 28 2.6.6 Further development of the EnAS production demo line to robust and flexible ...... 30 2.7 Execution semantic issues of the IEC 61499 standard ...... 32 2.7.1 Approaches to resolve semantic ambiguities ...... 34 3 Research material and methods ...... 36 3.1 NxtStudio (version 2.1.0.0) ...... 36 3.2 FBDK (version 2.6, Version 20170616) ...... 37 3.3 4DIAC (version 1.8.4) ...... 38 3.4 ISaGRAF ...... 39 3.5 BlokIDE ...... 39 3.6 Features of the software and creation of test application ...... 40 3.6.1 NxtStudio ...... 40 3.6.2 FBDK ...... 42 3.6.3 4DIAC ...... 45 3.7 Portability of basic function blocks between tools ...... 46 3.7.1 Portability from NxtStudio to FBDK ...... 47 7

3.7.2 Portability from FBDK to NxtStudio ...... 48 3.7.3 Portability from NxtStudio to 4DIAC ...... 49 3.7.4 Portability from 4DIAC to NxtStudio ...... 50 3.7.5 Portability from FBDK to 4DIAC ...... 50 3.7.6 Portability from 4DIAC to FBDK ...... 51 3.8 Portability of composite function blocks between tools ...... 51 3.8.1 Portability from NxtStudio to FBDK ...... 52 3.8.2 Portability from FBDK to NxtStudio ...... 53 3.8.3 Portability from NxtStudio to 4DIAC ...... 53 3.8.4 Portability from 4DIAC to NxtStudio ...... 53 3.8.5 Portability from FBDK to 4DIAC ...... 54 3.8.6 Portability from 4DIAC to FBDK ...... 54 3.9 Portability of IEC 61499 systems between tools ...... 54 3.9.1 Portability from NxtStudio to FBDK ...... 57 3.9.2 Portability from FBDK to NxtStudio ...... 58 3.9.3 Portability from NxtStudio to 4DIAC ...... 59 3.9.4 Portability from 4DIAC to NxtStudio ...... 60 3.9.5 Portability from FBDK to 4DIAC ...... 60 3.9.6 Portability from 4DIAC to FBDK ...... 61 4 Results ...... 62 4.1 Portability between the IEC 61499 compliant tools ...... 62 4.2 Converter program ...... 63 5 Summary ...... 66 References ...... 67 Appendices ...... 71

Abbreviations

ECC Execution Control Chart (State machine) DCS Distributed Control System FBD Function Block Diagram (IEC 61131-3 programming language) FBDK Function Block Development Kit (IEC 61499 compliant tool) HMI Human Machine Interface IDE Integrated Development Environment IEC International Electrotechnical Commission IMC / IMS Intelligent Mechatronic Component/System IL Instruction List (IEC 61131-3 programming language) LD Ladder Diagram (IEC 61131-3 programming language) OPC Open Platform Communications OWL Web Ontology Language PLC Programmable Logic Controller RTE Runtime Environment SFC Sequential Function Chart (IEC 61131-3 programming language) ST Structured Text (IEC 61131-3 programming language) UDP User Datagram Protocol UML Unified Modeling Language XML Extensible Markup Language

1 Introduction

Automation is the heart of automated assembly lines which reduces the manufacturing costs of products, increasing the profit for the company and subsequently reduces the retail price for consumers. Programmable logic controllers (PLC) are the key elements for enabling the operation of modern automated factories in field of industry. The IEC 61131-3 standard is one of the most used software standards in industry devices [1]. Production from the manufactory production line is at the most cost-effective level when the machines are constantly running, and nothing has to be touched. However, malfunctions of the devices and reconfigurations of the assembly lines are inevitably faced at some point, as the condition of the devices decreases over the time and the demand for the present product ends. The down-time for the factory costs money and developing, configuring and installing the new assembly line set-up requires resources. The shutdown of the entire production line is usually unavoidable when a one component of the system is out of order, and the production line is based on centralized control system. Applications based on IEC 61131-3 standard are often constructed as centralized control systems. The standard does not offer an easy and comprehensive method for flexible reconfiguration of the system in different situations [2]. The IEC 61499 standard resolves these issues with the concept of application-centric, distributed control design. In a decentralized control system, break-down of one device in the system does not necessarily stop the operation of the entire production line, as the other workable components can still operate as single units. In IEC 61499, the task of the broken device can be reconfigured to run in the remining devices easily. The IEC 61499 standard uses an event driven execution model, where the parts of the software are driven only when they are invoked. This is a departure from the cyclic execution model of IEC 61131-3, which suits centralized PLC architecture. The event-driven approach of IEC 61499 enables code distribution and increases the efficiency of the code, as the resources are focused on the parts which are currently needed. The base element of the standard is a function block, which consist of event and data inputs and outputs. Each function block is activated by triggering one of its event inputs, followed usually by an event output for triggering the next function block. The design of the standard is generally a network of function blocks, which are mapped to certain devices. [3] One key goal of the IEC 61499 standard is to make the industry field hardware interoperable and the control software easily portable and reconfigurable between devices from different vendors. The vendors of the control devices have to follow the compliance profile rule strictly to enable these features. However, this is not case, as this study investigates the topic further. [4] In this master’s thesis, a short survey is made on the features of the IEC 61499 standard. It is followed by a larger section of real world examples, where the standard is applied. The thesis concentrates on three different IEC 61499 compliant tools from three different vendors and tries to solve the incompatibilities between them. The main investigation topic focuses on the portability issues of the basic and composite function blocks and the system configuration on virtual devices provided by the software on a local computer. As an outcome, a Python based converter program is created to automate the 10 required modifications for the source files to enable and increase the portability between the compliant tools. 11

2 Background 2.1 IEC 61131 standard

IEC 61131 standard has been widely used in the automation control software on industrial applications [1], [2], [5]. The third part of the standard (61131-3) consists of four programming languages, where two of them are textual languages (IL, ST) and the rest two are graphical languages (LD, FBD). The standard also contains an additional flow chart element (SFC), which is used for defining the internal structures between different programs. [6]

Figure 1. Structured Text (upper left), Sequential Function Chart (upper right) and Ladder Diagram (lower) in IEC 61131-3 compliant tool Codesys [7] from 3S-Smart Software Solutions GmbH.

The IEC 61131 standard is used mostly on centralized control systems, because its usability on decentralized control systems has certain limitations. The first part of the standard (61131-1) is not enough precise for proper decentralization use, which is seen for example as flexibility and reconfiguration issues between PLCs from different vendors. The benefits of decentralized control systems have been lately realized better, because in a centralized control system a single point of failure usually causes the whole system to be down. In decentralized control systems, the reliability of the system is at an entirely new level, as the system can still continue its operation normally even if a major failure has appeared in some part of the system. [2]

2.2 IEC 61499 standard

An entirely new IEC 61499 standard has been developed to solve the limitations of the IEC 61131 standard. The IEC 61499 standard has been especially created to support the use of distributed, decentralized control systems in industrial automation systems. The standard enables to make the automation control systems more reliable, interoperable, portable, reusable and reconfigurable. The basic concept of the standard is similar to the use of graphical function blocks in IEC 61131-3 standard, but in IEC 61499 standard the function blocks are event-driven. [2], [4], [8] In the IEC 61499 standard, each function block consists of event and data interfaces for both inputs and outputs (Figure 2, upper left). When an event signal occurs in some of the event inputs of the function block, it triggers the function block to execute a certain functional operation defined inside the function block. Each input (and output) data variable can be associated to be updated with a certain event occasion, leaving the unassociated data variables at old values. When the function block has completed its execution with respect to a certain event, the function block stays idle which saves computing resources and increases the efficiency of the software. [2], [4] The internal structure of the IEC 61499 function block consists of Execution Control Chart (ECC), which is basically a state machine (Figure 2, lower). Every ECC starts from the Start state, and the current state of the machine changes with respect to the conditions defined in the transition branches between the states. Each state (except the Start) has usually some executable internal algorithm, which can be implemented by various different programming languages (Figure 2, upper right). The implementation of the internal algorithms does not limit only to IEC 61131-3 languages such as IL, ST, LD, FBD, SFC, but also higher-level programming languages such as Java or C can be used. In addition to this algorithm, each state of the state machine has usually also an output event, which is triggered after the execution of the algorithm. The triggered output event invokes the next function block where it is attached. [2], [3]

Figure 2. IEC 61499 basic function block, internal ECC state machine and ST-language algorithm SUM implemented in NxtStudio. Numbers on the function block interface variables show that the event CALC is invoked once with data values OPER = +, VALUE1 = 3 and VALUE2 = 5, which drives the state machine from START state into SUM state. In SUM state, attached algorithm SUM is executed, which is then finished by updating the variable RESULT and the attached output event CNF invoked. Because of transition condition 1, the state machine returns to START state.

The function block described above forms the Basic function block type in the IEC 61499 standard (Figure 2). In addition to that, there are also two other function block types; Composite and Service Interface. As the network of the basic function blocks can be huge, the network can be divided into smaller pieces, where each piece of the network is encapsulated inside a composite function block. The composite function blocks have the same interfaces as the “edges” of the cropped areas of the basic function block networks, ensuring the functional operation of the network does not change. By rearranging these networks of basic and composite function blocks onto different levels of encapsulated composite function blocks, the network gains a hierarchical structure, which not only simplifies the understanding of the system, but enables also the reuse of the code better. In addition to the composite blocks, service interface function blocks are considered as black boxes, whose internal structure is not very strictly defined. They can be used for example on implementing different interfaces and protocols in communications between hardware and software. [2] The design process of an IEC 61499 standard based application can be thought to consists of two levels: applications and system configurations. The first one contains the network of the function blocks and their connections, which capture the control functionality of the application. This application can be then mapped to many different devices, creating 14 a certain system configuration. By mapping the parts of the application on certain devices, the computational resources can be used more wisely. For example, the most computationally demanding algorithm of the application is recommended to be mapped on the device which is most idle or does have more computational power than other devices. To optimize this mapping of the application parts over different devices, the European project TORERO [9] has created an automatic mechanism to define the system configuration. It takes, for example, into account the computational power required for steps of function blocks, application real-time constraints, available device memories and communication protocols of the application. Based on these, the TORERO software will also automatically create the required communication function blocks for the system configuration. [10]

2.3 Software portability

Software portability is an important feature of the software, as it enables the (parts of a) software to be reused in other software tools and/or operation environments. As the hardware in computer technologies varies and the old devices are being replaced by new (different) equipment, it is important to have a portable and reusable software. By porting the same, barely unmodified software from one environment to another, major economic savings can be achieved by dropping out the developing and modification costs of the software, which would be essential if the software is not portable. [11]-[13] For example, in the IEC 61499 standard one of the main goals of the new automation software features is to make the software portable. In the first edition of the IEC 61499 standard this was not quite achieved, because the execution semantics of the function blocks were not defined accurately enough. For example, the lifetime of an input event was not defined, which caused execution differences especially in the ECC state machine in different software tools. When the semantics are not similar with other vendors’ software, two different IEC 61499 compliant tools might in practice be non-portable with each other as the transferable content can not be used without (fundamental) modifications. [4]

Software tool FBDK 4DIAC NxtStudio ISaGRAF FBDK Full Full Partial Not applicable 4DIAC Full Full Partial Not applicable NxtStudio Partial Partial Full Not applicable ISaGRAF Not applicable Not applicable Not applicable Full

Table 1. Portability of the library elements between different IEC 61499 compliant tools. [4], [14]

In the second edition of the IEC 61499 standard, the function block semantic issues have been defined better. However, there still exist various portability issues between different IEC 61499 tools, such as Function Development Kit (FBDK), ISaGRAF Workbench, 4DIAC and NxtStudio. The storing format for saving the library elements in IEC 61499 is defined to be XML by the standard. FBDK and 4DIAC are following the guideline very strictly, which 15 makes the software parts of these two tools basically fully portable between each other. NxtStudio has some own additional library features, such as Composite Automation Type (CAT) function blocks, which include the control, visualization and plant model parts in one function block. These special blocks and other NxtStudio specific elements in the XML structure are not understandable by other tools, but with minor modifications, the software developed in NxtStudio is somehow also portable with FBDK and 4DIAC. Instead, ISaGRAF Workbench tool has a different format for storing the library elements, which makes it totally non-portable with other IEC 61499 compliant tools. [4], [14]

2.4 Industrial motivations for portability

The IEC 61499 standard has been developed for enabling the automation control systems to be more flexible especially in reconfigurability, interoperability and portability issues than in the older IEC 61131 standard. [2] To get the best value for some software (unit) by extending its lifetime, portability is an important factor for making the reuse of the (parts of a) software in some other environment possible. However, measuring of the portability might still be somehow hard, because there are not standardized, established mechanisms for measuring and specifying it. Often porting might require some handwork and ad hoc techniques, but that it can be done in some cost-effective limits, is usually the most key factor for industrial use. [15] In automation industry, the IEC 61131-3 standard is widely used. The reasons for changing it to the IEC 61499 standard are however gaining more importance, as the understanding of the benefits of decentralized control is increasing every day [16]. The use of the function blocks in the IEC 61499 standard’s architecture increases the modularity of the software significantly, which is also a key factor for improving the portability of it. As the IEC 61499 standard is designed to be as flexible, reconfigurable, interoperable, modular, portable and reusable as possible, it should be a perfect software for industrial use especially in the areas of manufacturing and logistics. For example, material handling systems are one target application for the standard, as the modularity of the IEC 61499 is high and thus the decentralization of the software can be systematically and easily done. [2] The good modularity and portability are one of the important factors in increasing the distribution features among the automation control systems. The used time and effort for building a manufacturing line can be decreased when (parts of) a software generated in one IEC 61499 compliant tool for certain device types can be transferred easily to other tools and controllers. As described in [16], [17], an experimental shoe manufacturing facility was implemented by using IEC 61499 standard with the ISaGRAF tool. The control program was created by using the function blocks of the standard and connecting them into networks and rearranging them into composite function blocks, giving a more hierarchical and modular, encapsulated structure for the program. This kind of structure increases the reusability and reconfigurability of the manufacturing line and its software significantly. Encapsulation of the software parts guarantees that there are no (hidden) dependencies between different function blocks, as the case might be relevant with (shared) variables in the IEC 61131-3 environment. [16]

2.5 Evolution of the IEC 61499 standard

The real benefits of the IEC 61499 standard and its portability are still investigated widely. Many researches from different universities all over world are trying to combine for example the UML language and the IEC 61499 standard together. Such a good (uncompleted) solution is already developed in Greece, at the University of Patras [18]. Universities in German (Universities of Halle-Wittenberg) and New Zealand (Auckland) are trying to integrate also formal analysis methods, such as NCES, in addition to the combination of UML and IEC 61499 [19]. This area is also investigated in Finland, where The Factory Automation Laboratory of the Tampere University of Technology concentrates on formal verification, implementation and modelling of the control systems on the same topic [20]. In turn, the University of Calgary in Canada have investigated the mapping of the UML-RT concept with the IEC 61499 standard [21]. [17] Despite the extensive features of the standard, it still requires further development. The current use of the IEC 61499 faces some criticism. The definitions of the execution semantics of the function blocks are not fully completed. This has led the compliant tool vendors to interpret the guidance in the developing phase of the tool and use their own definitions for the execution semantics. Naturally, this kind of developing approach causes different and ambiguous behaviours of the same code on different IEC 61499 compliant tools. [22] For example, a function block is assumed to follow the rule that the block will not start new execution on a new event input arrival when the execution invoked by a previous event input is still running. The event-driven mechanism is still somehow only an abstraction, as there are not unambiguous instructions for situations where the new events arrive repeatedly too rapidly one after the previous one. The standard does not define, should the event inputs be saved into some buffers, or just should the system just ignore them until the execution of the function block is finished. [16] Also, the architecture of the different function blocks and network connections can be seen as an executable specification, which invokes a question about the design: is it seen more as a model or as an implementation? In fact, the standard can be seen including them both, which has a negative effect on the portability of the standard, as the platform dependent service interface function blocks have to be included in particular configurations. [16]

2.6 Case studies of using IEC 61499 standard

On the next chapters, a few case studies are referenced and presented. The cases show the practical issues and problems which need to be considered when applying the IEC 61499 standard on some applications.

2.6.1 Porting to the IEC 61499 standard: A case study of shoe manufacturing sector

As mentioned earlier, an application of the IEC 61499 standard was applied to a shoe manufacturing sector in an experimental manner. The goal of this CEC-made-shoe European Project [17] was to investigate and develop new, more advanced production lines, to keep the manufacturing costs low and thus prevent the decline and moving of the shoe- manufacturing sector from Europe to cheaper production cost countries on the other side of the world. The main goal of the project was to develop an automated production line, which could manufacture custom-made shoes. One main key point of the project was to combine the use of different models, that the development of the industrial automation control system could be more practical and coherent. To achieve these functionalities, the project required some developing and defining of different elements to enable the interoperability between different software. The project team created a short questionnaire on some industrial companies. The aim of the survey was to clarify what kind of tools or other structured methodologies they are currently using in developing industrial control systems. Results revealed that the use of these techniques are literally non-existent. The specification and design of the industrial control systems are mainly listed on documents in text editor tools, which based on the code is then directly written in some IEC 61131-3 language by using some compliant tool. The created control system is then tested and verified by doing some (closed) loop simulations virtually or straight with the physical hardware. The team proposed that the development of the industrial automation system could be first started by using tools which support UML or SysML languages. The designing phase of the architectural and functional models of the control systems was planned to implement in Simulink in Matlab [23], but the results of the process model simulations were not acceptable. The project team decided to develop themselves a CEC tool in Eclipse environment [24] for importing and converting the specification created in UML language to a model with respect to the IEC 61499 standard. The tool will first send some data to the Matlab for simulating and verifying it, and separate model data to C code generator. For the IEC 61499 standard elements, the project team needed to create a new XML Metadata Interchange persistence in order to be able to refactor some functionalities satisfactorily, as the standard XML persistence is unable to carry out these functions. The basic XML format contains issues such as duplication of information, which causes problems in separation of application concerns. For applying the IEC 61499 standard architecture to be used on the manufacturing plant, normal personal computers with RTAI real time operating system were used with input/output cards provided by National Instruments [25]. The hardware worked in a normal Ethernet network, where RTnet network protocol stack was used to keep the communication deterministic. For the generated applications, the project team decided to concentrate on performance and use ANSI C language. The C language was used for enabling the CEC tool to be able to handle variabilities in the control system, because the structures and connections of different function blocks varies. 18

The implementation structure of the system consisted of three different areas: Automatically generated, Middleware and Run-time. At the Automatically generated area the elements of the IEC 61499 standard are created from the designed system by the CEC tool. The Middleware area contains files which are specific for every device but used in every generated application, such as communication and management services. At the Run-time area, there are interfaces for example to the real-time operating system, which enables the use of services such as messaging, synchronization and queuing. Also, interface to the implementations of the communication network and input/output are provided, for example making the reading and writing between the software and physical hardware more advanced. The project team had discovered that the IEC 61499 standard describes formatively the models, but gives almost free hands on the implementation and design side. The team experienced some difficulties regarding implementing device connections and resource concepts. They had to design the architecture of the device execution framework themselves. This was also not so straightforward, for example in the resource element different implementations exist in the IEC 61499 architecture. When the application is going to be ported to another platform, this can cause execution order changes in function blocks. The created IEC 61499 environment was applied to a production line of ITIA-CNR. The system consists of several stations, where the shoes are delivered, and some certain operations executed. The physical molecular structure enables the production line to be more reconfigurable, scalable and flexible. In one molecular structure (Tern), there are two rotating tables and one rotating three-arm manipulator. Each Tern controls its own modular section of the equipment. The Terns are connected to the adjacent Terns for coordinating the deliveries of the shoes. The shoes are delivered from the first Tern towards to the following Terns, either doing some operation on every Tern or skipping some of them. When there are no anymore Terns left for the shoe to be operated in, it will be delivered back to the first Tern for warehousing.

Figure 3. The production line of the shoe manufacturing sector and the implemented control application using the IEC 61499 function blocks as a network. [16]

In the IEC 61499 application, each Tern was modelled as a composite function block, and each block contained internal composite function blocks for Tern managing, including operation of the two tables and the manipulator (Figure 3). This control system of the production line was implemented by using the FBDK tool, which from the function blocks are exported as XML elements to the CEC tool, which again generates the C code. The created control system was first tested on a miniature size copy of the production line, before downloading it to the actual hardware. As a conclusion, the project was seen as a great challenge to try to exploit the features and benefits of the IEC 61499 standard on a real production line, especially compared to the older IEC 61131-3 standard. One of the clearest improvements was the increased amount of the encapsulation and modularity, which made the control system more readable, understandable and manageable by a human. Because of the modularity and portability, the already generated function blocks can be easily reused in some other control system variant in the same hardware or even on a completely different production line. This will save developing costs when the base control logics of some machines do not need to be defined again. Also, the flexibility and the reconfigurability of the line increases, when a different variant of some production procedure can be taken into action faster. However, the project team points out that semantics of the execution rules need to be taken into account, to prevent unexpected behaviours. This is based on the IEC 61499 standard’s current definitions where the implementation models are not regularised, and thus different implementations on different platforms can have some divergent effects.

2.6.2 A case study of composing IEC 61499 application on Intelligent Mechatronic Components

Primarily, the architecture of the IEC 61499 standard is designed to enable the efficient and flexible use of the automation applications. When the automation control application is going to be distributed over a network on different hardware/resource units and types, the interoperability of the system components needs to be seamless. This requires working communication protocols, right-timed synchronizations and correct data formats. The following case study goes through these features of the IEC 61499 standard’s architecture, where one application is deployed on three different hardware and software platforms. In the case scenario [26], a manufacturing machine consists of several units, called Intelligent Mechatronic Component. Each of them have their own control device, sensors, actuators and a software, which provides basic services and operations for the component unit. The units are connected to each other side by side as a network, enabling the units to communicate and interoperate with each other. The IEC 61499 application can be distributed and downloaded into many different devices, where the mapping configuration can in theory be arbitrary. The case study machine used in the scenario is a pick-and-place manipulator, which can be thought to consists of four of these intelligent mechatronic component units: one vacuum unit, one vertical cylinder and two horizontal cylinders. Each of the units has a some kind of pre-programmed functionality, which for example extracts/retracts the cylinder or starts up / shuts down the vacuum of the vacuum unit. The units contain also some sensors for detecting for example the end position of the cylinder move. At the scenario plant, there are three trays, where from the manipulator can pick up work pieces and put them into a slider. Each of the trays and the slider have a sensor for informing the existence of work pieces. The manipulator can achieve each of the plant positions by a specific combination of retracting and extracting its cylinders. The IEC 61499 control application for the pick-and-place manipulator was first designed completely in NxtStudio as a centralized application, and then it was divided into three pieces as a distributed application (Figure 4). Some communication function blocks were inserted into the network of the function blocks, enabling communication between the different devices and parts of the application. One part of the program was remained in the NxtStudio, as the two other parts were ported into ISaGRAF and BlokIDE. The porting of the parts of the application to these other IEC 61499 compliant tools was not straightforward, for example the application part belonging to the BlokIDE needed to be redeveloped. In ISaGRAF, the function blocks use SFC instead of the ECC as in NxtStudio. Also, some other function blocks still needed to be developed into the ISaGRAF to enable the publish and subscribe function blocks to operate. As a hardware setup, the NxtStudio’s nxtForte runtime was run on ADAM 6650 PLC. The visualisation part of the simulation of the application was performed on the same device. The ISaGRAF’s runtime and the C code generated by BlokIDE’s BlokSynk were both run on separate Wago 750-860 devices. As a conclusion, the notable things of the project were the different execution semantics of the three IEC 61499 compliant tools. The results revealed that while Nxtstudio 21 utilizes sequential semantics, ISaGRAF, on the other hand uses cyclic semantics and the BlokSynk of BlokIDE a synchronous execution model. In the sequential semantics, an appearing of two simultaneously event inputs or outputs is not possible, as the case is vice versa with the two other execution semantics. Even if this possible event simultaneously did not have any effect in this specific project, the phenomenon can still cause unexpected behaviours on other similar applications.

Figure 4. The control application of the pick-and-place manipulator developed in NxtStudio was divided and distributed into three devices. [26]

2.6.3 A case study on the “plug-and-play” features of the IEC 61499 function blocks

Not only limited to the environment of automation industrial applications, the benefits of the IEC 61499 standard have also been observed in the field of medical healthcare [27]. The use of Intelligent Mechatronic Systems (IMSs) is already accepted widely in the applications of the industrial field, but applying these robotic systems to the healthcare area is still an increasing challenge. The modularity and reusability of the IEC 61499 standard and its function blocks offer a great opportunity to design and simulate the whole system in a more advanced way. Provided by the standard, the possibility for distributing the application enables developing more complex system structures. These systems are easier to handle in the IEC 61499 standard than in the older centralized architectures. The use of the mechatronic devices is a rising phenomenon in the medical healthcare. These devices are already used from the simplest form of a physical movement support of the patient to a precise surgery operation. The further development and use of the devices in the present way usually face problems with the cost-effectivity, time consumption and the complexity of the design. The mechatronic devices of the medical healthcare are often developed in a centralized way and individually for a certain case, which makes the development costs of these devices and their software significantly huge. One reason for 22 that is the critical need for ensuring that the device is not only safe but also hygienic for human targeted operations. However, there is a need for more modularized use of the medical hardware and components. The “plug-and-play” type feature (no manual configuration work needed) of different devices and (software) platforms could enhance the reusability of the equipment in medical centres. The lack of standardization causes much overlapping with the available software and devices in the healthcare area, and learning how the new equipment operates is always time and resource-consuming for healthcare personnel. By creating an open standard for the medical healthcare field, benefits would be visible due to the improved easiness of using and managing the equipment, the reduced human errors and also because of the more simplified and more comprehensive interfacing that exists between different devices. These features are possible to achieve by applying the IEC 61499 architecture to an upper limb rehabilitation robot which is presented in the following sections. The goal of this case study is to design distributed, modular, reconfigurable and versatile software for the rehabilitation devices by using the function blocks of the IEC 61499 standard. The case device is an upper limb rehabilitation robot created in the University of Auckland, containing two degrees of freedom. The robot was designed to support the cost effective rehabilitation of stroke survivors with a single device. The portability, safety and light weightiness of the robot enables the device to be used more efficiently as personal home therapy equipment. The robot has an easy-reading graphical user interface, which gives feedback for the patient about his/her activities.

Figure 5. The upper limb rehabilitation device of the project. [27]

The control program of the robot before applying the IEC 61499 standard was developed in C language, which was run in one master and two slave microcontrollers. The graphical user interface for the patient was created externally in LabView [28] platform. The separation of these two application parts to different environments already shows the inconvenience for future device development, as the integration of these parts is not as coherent as it would be inside one architecture. Also, the use of expertise level programming languages like C prevents the possibility from most of the healthcare personnel to be involved in the design and development phases of the device. Because of this and hardware dependent centralized control architecture, the flexibility and scalability features of the robot are not at the most optimal level. Even if the IEC 61499 standard is mainly used in the industrial applications for solving the similar problems as described above, there are no major restrictions for applying the same architecture in the medical healthcare area also. The control designing of the mechatronic components follows roughly the same principles in every field. The architecture of the IEC 61499 standard enables more convenience use of the software for the engineers of the healthcare area. Because of the hardware independence of the architecture, the application can be already first designed and simulated in the IEC 61499 environment, and later select the suitable equipment for the real use. The application will be much easier to distribute on several medical devices in the IEC 61499 standard than in other traditional platforms. Hardware providers such as Siemens, Beckhoff, Wago and Advantech are already supporting the standard broadly. The new control system for the rehabilitation robot was created completely in the IEC 61499 compliant tool NxtStudio. With the tool it is easy to design and create the control and visualization parts both in one same environment. The benefits of the use of the modular function blocks makes the developed code more reusable and distributable, which has a direct influence on the reduced development time. The increased usability and manageability of the code allows the device to be quickly adapted to the individual needs of the patient. The control application for the robot was implemented firstly by creating the function blocks of the robot’s functionality. At this stage, the function blocks representing the hardware were also created. Then, the function blocks representing the physical components, such as DC motor, were also added to the network of the function blocks. After this, the function blocks were more specifically defined with respect to the real physical features of the robot and its parts. In addition, a control panel with relevant information of different values was inserted to make the controlling of the robot easier. When these were completed, the main control logic for the robot needed to be done. The controller needs to move and control the device in a way that it obeys the orders made by the operator. At the same time, it needs to analyse the provided information from the sensors and different software states in a way that the device is safe for the patient and will not break itself down by exceeding physical limits of the motors and other parts. The design approach for such a controller function block was done by following STEP C method, which comes from Self, Task, and Environment Perception along with Communication. This method was used for five separate function blocks in the application for simplifying the task of creating a good controller, which includes the implementation of a 24 clear structured code. By the creation of the new design with IEC 61499 standard, the application got several modifications and new functionalities, which would have been much harder and time-consuming to implement in the old architecture. For example, the device acquired new complex and customizable trajectory paths, which give the patient more advanced use of the device. Also, virtual boundaries are now possible to set for the device for not exceeding some movement limits with respect to the physical condition of the patient. When the development of the application was ready, the created application was firstly downloaded into Beckhoff CX1010 controller. The application was tested in centralized control mode, after which a part of the application was successfully distributed also into Wago 750-860 controller, using basic Ethernet work for the communicating. The conclusions of the project revealed noticeable benefits in the use of IEC 61499 standard, as it made the designing of the complex systems much easier by enabling the reusability of the modular code in a “plug-and-play” way. This reduces the used development time and effort of the engineers and other healthcare personnel who are focused on modification of the medical devices for certain cases.

2.6.4 Using IEC 61499 standard for “smart” digital ecosystem

As described in the previous case study chapters, applying the IEC 61499 standard to different (non-)industrial applications has resulted in several improvements compared to the old used techniques. The key benefits of the new standard are for example increased portability, flexibility and possibility to distribute the system on different devices. The distribution of the system is, however, usually allocated manually before deploying the software on the target devices. But an idea of a self-configuring software, which can migrate itself in the network between different devices for aiming to search the most optimal balance of the system in terms of especially performance, is investigated in [5], which is gone through in the following chapters. This kind of system approach can be seen as a biological mechanism in a virtual software world, where the adaptable software components drift into places where the need for them is the greatest. This digital ecosystem of the software components forms a dynamic environment, which can respond to disturbances and rapid changes in the states of computational load conditions of different devices and parts of the network. The described behaviour and model of the system has been tested on a baggage handling system application using IEC 61499 standard. There are few ways to enforce the migration of these adaptable software components from one device to another. The simplest method is doing it by hand, but more sophisticated way is to allow the operating systems of the devices to perform the migration. In addition to those, one method more is to give the adaptable software component itself the possibility to handle the migration of itself. For that to happen, the software component requires more available resources and services from the devices, in order to be able to investigate the situation of the network and its devices and later decide, where to move. The system architecture must support the software components to be able to freely travel in the network between the devices and let them reconfigure it. The architecture must provide some primitive reconfiguration services, so that the software components can be installed and 25 deleted on the devices. Furthermore, the information regarding the system load condition must be made available at the application level in order for the adaptable software components to drift to the most suitable position. However, at the moment there are hardly any software architectures which could provide these required features for the software components to be used in aforementioned way. One potential candidate is the IEC 61499 standard, which is one of the most suitable architectures for this kind of system environment, although it has several limitations for implementing the adaptable software concept directly. The basic concept of the adaptable software components works in a way that the distributed control application is mapped into different devices. Each device contains initially some part(s) of the control program, and the components of the program communicates with each other by a shared memory if they are located in the same device, otherwise communication occurs by message passing. During the time and the execution of the code, the computational load resources changes slowly or rapidly between the devices. When the situation achieves unacceptable conditions, some component from Device 1 decides to migrate to Device 2 (Figure 6). As the physical location of the software component changes, the communication method also changes from shared memory to message passing in the old device with respect to the migrated component and vice versa in the new device.

Figure 6. Basic concept of the adaptable software components. [5] 26

The use of this kind of approach could be extremely beneficial. In a relatively short time, the evolution of the (automation) industry has developed rapidly, as the intelligence, complexity and mass manufacturing of the production lines are increased significantly. The trend of using applications consisting of several pieces is gaining strength among the emerging use of the distributed automation systems, which has increasingly taken root from the traditional centralized control systems in the industry. Because of the globalization and growing mass customization which causes more complex control systems, the need for more dynamic systems is obvious. The digital ecosystem can take into account the constant changes of the environment, where each component can re-organize itself to a better place for improving the overall condition of themselves and the whole system. In a digital ecosystem, the computing platform is seen as an environment and the adaptable software components as interactive organisms. Unlike other distributed computing architectures, the digital ecosystem and its software components don’t have essentially well-defined roles as in multi-agent architectures. The agent concept is used more freely without strict definitions, so that the software components can themselves create the needed structures and revoke the redundant ones. When compared to a service- oriented architecture, digital ecosystems have not centralized service brokers, which would keep track of and provide some services. As a study case, a baggage handling system is taken as an example of trying to implement the digital ecosystem into it using IEC 61499 architecture in NxtStudio. The handling system is distributed on local controllers, which can only control conveyors they are responsible for. The control devices include the conveyor model, low level control and tracking control of the conveyor section, where the lastly mentioned is the adaptable software component. The functionalities of each device controller consist of mainly Transfer Manager and Load Recorder function blocks. The Transfer Manager keeps track on the reconfiguration issues of the certain device. It communicates through UDP over the network with other devices and if needed, saves the states and data of other migrated function blocks, because the migration of the function blocks themselves to another device is not currently possible in the IEC 61499 standard. The Load Recorder informs the load, such as CPU utilization and memory use, of the current device and measures the other devices’ condition via UDP. The measuring can be done periodically or the device’s state broadcasted when an overloading occurs. This information should be available to all services, that they can decide should they migrate from the overloaded device to less loaded one. If the architecture would allow, the Transfer Manager and Load Recorder could be combined as a one transparent, localized service. In the case study, the tracking control element was selected as the adaptable software component, because it is a non-essential and non-safety critical feature for the system to work. This way the possible errors with the migration processes don’t cause significant disturbances in the main system operation. However, this approach can not be basically used on some more complex systems. Usually safety is the most important factor of an automation system, which requires safe reconfiguration operations for not disturbing the ongoing processes in the system. 27

In this current application, the tracking controller works in a closed loop with the conveyor model function block and receives data from the Load Recorder function block. With the received information the tracking controller function block can decide on which device it should migrate itself, if needed. The decision is based on a vector of certain requirements, such as CPU utilizations, available amount of memories and latencies in communications between devices. The actual transfer of the tracking controller function block is handled by the Transfer Manager function block. For enabling the reconfiguration to be possible at all, the IEC 61499 standard has management service interfaces for creating, modifying and deleting the function blocks and their connections. A XML encoded DEV_MGR function block is included into each resource, which listens for commands such as start, stop and create. For example, the start and create commands are used in the deployment phase of an IEC 61499 application. In addition to those, the reconfiguration and successful migration requires also the ability of capturing and restoring the state information of the function blocks. However, this feature has been found to be lacking in the IEC 61499 standard. The problem is, that the behaviour of the function blocks is governed by their underlying ECC, which condition is not saved when the function block is migrated. One way of avoiding the problem currently is to handle the situation at the application level, but this requires extra work and causes unnecessary overhead. Also, the internal states of the function block can be for example “printed” out on some string output data variable, which can be restored in the new created similar function block by reading it. The state of the ECC needs to be saved before the migration process starts, which requires some helper function block, implemented as Transfer Manager in this study case. The distributed baggage handling system was deployed on Advantech ADAM 6650 controllers, which run NxtForte IEC 61499 runtime. It was measured briefly that the tracking control element used approximately 10% of the device’s computational power. When this adaptable software component migrated to another device, the CPU utilization of the previous device decreased. However, exact numbers of performances are currently not possible to be known by each function block using the current mechanism of the IEC 61499 standard. Despite the faced problems, the case study gave an interesting option of handling the transferring of the function blocks in a biological-inspired way, where the components migrate themselves from one place to another to increase the system performance. The goal of the project was to produce dynamically reconfigurable environment especially for strongly distributed automation control systems. The case study attempted to show that the mapping of the configurations might not be most optimal, and the situation can change always during the execution, especially in event-driven applications. The digital ecosystem might be worthless for small sized system, but for large scaled system it is probably useful, at least in sub-optimal configuration issues.

2.6.5 Smart, distributed and wireless production demo line in IEC 61499 standard

At the technical faculty of Aalto University, Finland, a group of five people decided to enhance the (cost)effectivity of automation production lines. Research revealed that the use of older system architectures in industry is widespread. Many of these systems are sensitive to a single point of failure, which can cause massive maintenance and reconfiguration costs, when the production line is stopped for a while. They approached the problem by developing a system, which consist of wireless distributed intelligent mechatronic devices [29]. In addition, the team focused on adding a smart software update feature, which could reconfigure a certain device on the fly without stopping the operation of the production line itself. The project team used FESTO EnAS demonstrator [30] as a base to build on their project. The demonstrator is rounded by a conveyor line, which makes a complete loop. The conveyor line consists of two identical parts. Both parts have a jack station equipped with a sledge and a gripper station. The jack stations are able to modify the content of the items which are moving around the conveyor line on pallets. At the gripper stations, the location of the items can be switched in the pallet or moved to another one. The conveyor line consists totally of six sectors, each one containing at least one optical sensor. The team started the project by removing the PLCs and modifying other parts which were installed originally on the EnAS demonstrator. The PLCs were replaced by six NxtDCSmini controllers, provided by NxtControl. The control software was developed using NxtStudio, first as a central control application on one device. After achieving a working, moving application with some functionality, the project team focused on distributing the application on several controllers. Firstly, the six NxtDCSmini controllers were connected to each other via Ethernet cable, where each device handled one section of the demonstrator. Corresponding mapping of the inputs and outputs of the controllers were done, and the application was distributed into them. Despite the lack of good documentation of such a new NxtStudio program, the team managed to change the control application from centralized system to distributed one quite easily as it is the purpose of the IEC 61499 standard. At the same time, the project team started to develop human machine interface (HMI) to help the team to read the status of the system on operation and enable the use of smart software update. Again, due to the poor availability of NxtStudio guidance, the team had to develop the HMI feature mainly by trying and seeing if any errors occurs during test runs. The distributed system worked well in the wired network after hours of modifications. The cable network provided a good and reliable communication, ensuring few communication problems were experienced. As the next milestone, the project team decided to move on to applying the wireless technology into the system. They used wireless VONETS dongles, which were attached into the Ethernet ports of each NxtDCSmini. The dongles were connected to a router, which in turn were connected to the computer containing NxtStudio.

Figure 7. Festo EnAS demonstrator with six NxtDCSminis in wired Ethernet network. [31] The use of the wireless network added some delays to the communications, as expected. The system worked quite normally in the lab circumstances. The latency between the devices was approximately 9 milliseconds, when with wires it was over 3 milliseconds. However, the latency problem played a much bigger role when the project team visited the SPS IPC Drives Exhibition in Germany, Nuremberg [32]. Owing to disturbances created by the amount of wireless networks in the exhibition hall, the demonstrator was forced to operate using wire connections. Following this, the team created a simulation model for the system. Solid Edge was used for developing the 3D model of the EnAS demonstrator and CIROS Studio for the actual visible visual simulation. NxtStudio was connected to the CIROS with OPC protocol, run by UaExpert. NxtStudio controls the behaviour of the simulation model in the same way as the real physical demonstrator. The simulation part turned out to be very heavy for the team to implement, as the amount of required work was huge. They faced lots of problems during the development, such as compatibility issues between the software. Despite many adversities, the team succeeded to finish the project from many perspectives. They achieved all the milestones they had set up for their project, and some real improved performance results compared to the old demonstrator formation were attained. The smart software update, which can update a certain control section of the EnAS demonstrator system, was working in real action. The OEE (Overall Equipment Effectiveness) score of the system was calculated to be much higher in the new IEC 61499 system than in the older IEC 61131-3 based system. With OEE the real productivity of the 30 production line can be measured better, as it takes into account the availability, performance and quality of the manufacturing activity. The project team achieved OEE result of 99% for the new system, which is quite theoretical. For example, the team did not consider the quality at all in their measurements. Also, the amount and variety of test runs should have been much higher, and keeping this in mind the team estimates that OEE score of 80-90% would have been a more realistic result for the system, as the usual score for real production lines is approximately 60%. The whole project documentation with all related files, pictures and videos can be found in [31].

2.6.6 Further development of the EnAS production demo line to robust and flexible

As described in the previous chapter of applying the IEC 61499 standard for the EnAS demonstrator to make the system wireless and distributed with smart update, the completed work was continued by a new project team in Aalto University, Finland. The goal of the new five students’ team was to develop the system further by adding flexible and robustness features using NxtStudio for the control application [33]. The system would be able to produce in reality some “real” products and on demand change the product to be produced on the fly. Also, by the robust feature the system would be endure to failures which could appear on the device controllers. The simulation model created with the CIROS and Solid Edge tools by the previous project group was also taken into further development. The model was intended to be updated with the new features and equipment which the new team will install into the system. To achieve the objectives for making the system flexible and robustness, the physical structure of the FESTO EnAS demonstrator was modified in a way that it would behave more like a real production line. In addition to the EnAS demonstrator described in the previous chapter, a metal slide for new items to be inserted on the pallets from outside of the system was added into the first conveyor section of the demonstrator. Also, a pneumatic rotary arm for the sixth conveyor section was constructed to enable the removing of the “ready” items from the production line. The pneumatic valves for the rotary arm were taken from the gripper station in the third section, disabling the functionality of the first gripper. Finally, the EnAS demonstrator was modified to contain two pure conveyor sections, one gripper station, one item insertion slide, one item removing rotary arm and two jack stations, where the first one acted as an installing station and second one as an uninstalling station. The production line of the demonstrator was not principally anymore a complete loop, as the items travelling on the pallets were going from first section to the last sixth section, without making a full circle in normal cases. However, because of the flexibility features, items could still go for a new round if there would be a need for such a case.

Figure 8. Sections and structure of the modified Festo EnAS demonstrator. [34]

The project team got six new nxtDCSmini controllers in addition to the already existing six ones on the EnAS demonstrator. The idea of the total 12 controllers was to construct a system where six of the devices were used as logic controllers (master terminal units, MTU), mainly one device for each section of the demonstrator. The rest of the six nxtDCSminis were used only as input and output purposes between the demonstrator’s hardware and the logical controllers (remote terminal units, RTU). The connection between the MTUs and RTUs was managed by a publish-subscribe method. The purpose of this kind of system structure was to show the robustness features of the system. If one of the MTUs would fail (power off, does not respond), one MTU of the rest five working logical controllers will take the job of the faulty one. However, the project team ended up using only four nxtDCSminis for the MTU purposes, as the co-operation of the used software tools and protocols did not support the use of more than 10 devices at a time. The goal of the project team was to make the demonstrator system as flexible and robust as possible. To achieve the maximum flexibility, the system was decided to have a central product order application with human machine interface, where the operator could make an order for a certain type of product and select the amount and of needed units. The products were determined to be blue and red discs/pucks, which were aimed to be installed inside cans. The empty cans were inserted into the production line on pallets via the metal slide in section one. In section two, the jack station installs the requested product from the corresponding stack of pucks on the sledge. The pallet is then driven onto the fifth section of the system, where the quality check is provided for the product. The second jack station checks the content of the can by visually using a USB camera, which is attached to the arm of the jack. If the content of the can seems to be normal, the pallet is driven onto the sixth section, where the gripper station and rotary arm removes the ready product out of the system. If the content of the can was recognized to be invalid (wrong colour, for example a human error made by inserting the pucks onto the wrong stack), the wrong puck in the can 32 was disassembled and the empty can was then sent to a new round for installing the right one. The colour detection of the can at the disassembling jack station at the fifth section of the EnAS demonstrator was implemented in a Python script. When the jack station has opened the cap of the can, NxtStudio invokes the script via UDP connection to use the camera for detecting the colour. When the detection has been made after several steps of image processing, the result is sent back to the NxtStudio and the demonstrator continues the operation of the product depending on the received information. In conclusion, the project team managed at least partially to finish and show the flexible and robustness features of the system by inserting manually wrong coloured pucks on the wrong stack, which the system recognized and therefore did not produce the wrong product. Also, shutting down the connection of some master terminal units did not cause disturbances to the operation of the system. The development of the central processing software further was not completed and the capabilities of the more flexible use of the demonstrator were not fully achieved due to the lack of time and resources. The CIROS simulation model was implemented to work in a way that it could replicate the physical movements of the Festo EnAS system. Although the team used many parts of the previous group’s work as a base, they also completely redeveloped various other parts. The full documentation with all related files and pictures can be found in [34].

2.7 Execution semantic issues of the IEC 61499 standard

As in earlier case studies, the ambiguous definition of the execution semantics of the IEC 61499 standard are a prominent problem in many practical situations. The lack of defining the execution semantics might lead to unexpected behaviours of the software and devices, especially with the runtime execution when the use of different IEC 61499 compliant tools and hardware devices are mixed together. The original idea of the IEC 61499 standard was to make the automated control systems more flexible, portable, distributable and robust to disturbances. However, these features might not be fully achieved as long as the semantic problem exist. The behaviour differences may require a lot of modification work before the system works as intended. [11] It is important for the automation industry that the changeability, reconfigurability, cost- effectivity and zero downtime operability is at the best possible level. Various types of different platforms, software tools and hardware are used on the production lines. Some of the different systems might be fully interoperable with each other, whereas some other devices and software fail to communicate with other (vendor’s) systems completely. This issue has been somehow already noticed in the creation of the IEC 61131-3 standard, where the modelling of the control programs is aimed to be similar. However, the interoperability between different platforms and tools were not taken into account seriously, until the issue had been taken into work by different companies and user organizations which lead to the wide use of the standard. Nowadays, the IEC 61131-3 standard faces limitations in fulfilling the increasing requirements of the new automation control systems, which are required to be more portable, interoperable, distributable and reconfigurable. The IEC 61131-3 standard 33 includes the function block diagram language, which created the idea of developing the function block model forwards to fulfil the new requirements, leading to a project of creating the IEC 61499 standard. [11] The IEC 61499 standard consists of four parts, but the third part was withdrawn as outdated after four years of existing. Part one handles the architecture structure of the standard, whereas in part two software tool requirements are defined. Subsequently, part four specifies compliance profiles for the standard. Several studies have been carried out in the lack of execution semantic definitions. Execution difficulties have been investigated in various ways, and the majority of the researches focus only on the parts of the standard elements itself. [11] In [35], several examples have been presented. One study considers about the interconnection case of the data and event association. In the standard, the associated data with certain event has been defined to be updated, when the event is triggered. For example, when some function block generates the output event, the associated output data will be updated, and the output event triggers the next function block’s event input. The associated input data will be updated to the same value as on the previous function block’s output data. However, the standard does not explicitly define, how the sampling and updating of the values is carried out when the event and data connections are across between two event sending and two event receiving function blocks (Figure 9). [35] Another example raises up the problem with the clearance of the event inputs. For example, there are three states in the function block’s ECC, and the first state has a transition containing only a Boolean condition towards the second state without event variable. The second state has similar transition to the third state, but the event variable is also included. The question is, at which state does the state machine stop (second or the third), when the first state is the starting point, and both Boolean conditions are true and an event input occurs. The definition of the life-time of the event and the execution of the function block is not clear, as the amount of going through possible true transitions is not specified. [35] In [36], the problem has been investigated from the real-time execution view. One case which has been brought up, is the situation where the device controller is overloaded. If the incoming events are sent to the device too often, it is possible the device controller is unable to process all the incoming event inputs. This can happen especially with the service interface function blocks, which can theoretically send the output events infinitely often. The controller requires always some processing time for each event input, and therefore new event inputs which are coming during the time the previous event is still being processed, might lead to blocking and discarding of the new events, causing unexpected behaviour for the application. [36]

Figure 9. Event and data variables connected across between different functions blocks. [35]

2.7.1 Approaches to resolve semantic ambiguities

Some suggestions to solve these semantics problems has been described in [37]. Several function block execution models such as non-preemptive or interrupted multithreaded resources [13], cyclic [38] or synchronous [39] models, Petri-net based [40] and other models are proposed and implemented. The differences in the semantic interpretations can be grouped into three function block implementations, which are sequential, cyclical and parallel. However, even the semantics problems are known and solved, the portability issues from one model to another are primarily not yet determined. [37] One approach to solve the portability problem between the different execution models is named as Semantic-robust design patterns (SRDP). The idea of the SRDP is to apply it on some function block application designed for certain execution model. The result of this is that the same function block application works functionally same way in some other execution model. The principle of the SRDP is divided into three steps, and the first one is concerned with the addition of new function blocks. The second one considers the change of them, and third one the modification of the interconnections between the blocks. The whole procedure including buffering of the events, interface and ECC transformations, and other related details are presented in [37]. In [41], an ontology-based design recovery method is proposed. The idea of the method is to create a platform independent ontology knowledge base by a design recover engine from some function block application, generated for example in FBDK or NxtStudio. Later from the knowledge base, the right application version for a certain platform can be then automatically generated. The base is divided into T-Box and A-Box parts, where the T- part (taxonomy box) concerns the general properties of ontological concepts. In the IEC 35

61499 field, this would mean that all the standard’s keywords/concepts such as system configuration and devices belong to the T-Box. The devices are a part of the system configuration, and therefore they are linked to it as object properties. [41]

Figure 10. Idea of the ontology-based design recovery system. [41]

The A-Box contains instances of some specific system design knowledge. Thus, the A-Box consists of instances of settings, configurations, function blocks and parameters of a certain system. The XML based source code of the applications of different IEC 61499 compliant tools is read by the design recovery engine and stored as OWL format on a specific knowledge base. The saved data is verified by syntactic checking and semantic analysis, to ensure that the application to be generated from one compliant tool to some other specific target platform is totally compliant with it. In violations, the engine gives opportunity to modify and correct the detected faults before the generation of the application. After these steps, the design recovery engine can generate XML based files for the specific IEC 61499 compliant tool. The more detailed operation of the design recovery engine is described in [41].

3 Research material and methods

The main goal of this thesis is to clarify the portability issues between the IEC 61499 compliant tools and create a basic software converter tool, which could modify the code generated in one compliant tool to be used in other compliant tool. The primary tools which are planned to be supported by the converter are NxtStudio, FBDK and 4DIAC. Other tools, such as ISaGRAF and BlokIDE, are not in sight to be included into the converter, and are thus only briefly introduced. In the development work of the converter, the earlier mentioned execution semantics problems need to be taken into account. Part 4 of the IEC 61499 standard defines the compliance profile requirements for the compliant tools, that the software produced in the different tools would be easily portable and interoperable with other vendor’s products. However, this is not fully achieved in all tools as noticed earlier. [14]

3.1 NxtStudio (version 2.1.0.0)

Figure 11. NxtStudio on Windows 10 operating system. A network of function blocks for controlling the car in an elevator application is showed in the editor window.

NxtStudio is an IEC 61499 and IEC 61131-3 compliant software tool of an Austrian company nxtControl GmbH running on Windows platform. The tool has been primarily designed for engineers to program control applications on distributed systems. The software offers an independent hardware design approach by providing the possibility to create the control program and visualization part in one single environment and simulate them. The created control application can be directly distributed and downloaded into the different device controllers from the tool’s menus. The software takes automatically care of the required 37 communications between the tool and the devices and shows the real time situation of the application in the controllers. The software tool is commercial but a free downloadable demo is available. [42], [43]

3.2 FBDK (version 2.6, Version 20170616)

Figure 12. PID controlled tank level system example application running in Java based FBDK on Windows 10 operating system.

FBDK (Function Block Development Kit) is a freely downloadable IEC 61499 compliant tool, provided by Holobloc Inc from USA. The software runs on Java platform on Windows, Linux and Raspbian operating systems. It consists of editor environment FBEditor and run-time part FBRT. The toolkit allows the user graphically to design versatile and complex, distributed control application systems by using function blocks as a network. With the software it is possible for example to create and experiment different data/resource/device types and system configurations. FBDK was one of the first IEC 61499 compliant tools, which had a huge part in spreading the standard for the audience. It was used a lot for research purposes, as the software was not designed for being actually used in the industry. [44], [45] The installation and start-up and use of the program is made simple. The whole program with its editor and runtime environments come in a zip compressed file, which is only required to be uncompressed to some location on hard disk and the software is then ready to use. Only Java must be installed on the computer before FBDK can be run on it.

3.3 4DIAC (version 1.8.4)

4DIAC is an open source IEC 61499 compliant tool running on Eclipse Integrated Development Environment (IDE). The tool is designed for creating distributed industrial control systems and process measurements and is freely downloadable. In the tool, a network of basic, composite and service interface function blocks can be structured graphically in the application editor. The software contains useful internal features such as monitoring and debugging functionalities of the code, which makes the testing phase of the application easier. The 4DIAC follows the definitions of the IEC 61499 standard, which means that the generated control application can be first finished and only afterwards define the system configuration and distribute the application on different devices. The 4DIAC comes with its own runtime environment 4DIAC-RTE (FORTE), which is designed to run in C++ in small embedded control devices. It is also possible to reconfigure the system online and watch the real-time conditions of the function blocks. [43], [46] In addition to the basic, composite and service interface function blocks, the 4DIAC comes with its own Adapter type feature, which isn’t really a function block but reminds a such. Adapters consist of socket and plug adapters, which simplify the amount of the interface elements of function blocks to one connection, which in turn enhances the reusability and handling of the code. [47], [48]

Figure 13. 4DIAC IDE running on Windows 10 platform. Control logic of the shown MechPress application example runs on FORTE runtime environment, while other visualization parts of the application are running on Java based FBRT.

Because of the idea for making the FORTE to be run on control devices, the 4DIAC doesn’t have an own visualisation feature implemented. Instead, the human machine 39 interface of 4DIAC is done by using the FBDK. The downloadable editor (versions 1.8.4 or older) comes automatically with the library elements of FBDK and its runtime FBRT for graphical user interface purposes. [49] The setup and use of the 4DIAC development environment with its FORTE runtime environment requires a bit more effort from the user when compared to NxtStudio and FBDK. In 4DIAC, the installation of the editor itself is easy, but configuration of the FORTE runtime requires a couple steps more. On Windows, additional programs such as CMake and MinGW or Cygwin are needed to be able to generate files and compile them for the FORTE runtime. [50]

3.4 ISaGRAF

ISaGRAF, created by Rockwell Automation Company, is one of the most used IEC 61499 and IEC 61131 commercial compliant tool for industrial systems. The newest version ISaGRAF 6 Workbench runs on Microsoft Visual Studio on Windows operating system. It has similar features as the previously described compliant tools, focusing on providing high- ended, crash-proofed reliability for the industrial customers. The tool has various plug-ins, such as Function Block Diagram and Tag Database editors and integrated HMI. A free version of the software can be downloaded to test some of the functionalities of the tool. [51] The biggest difference between the ISaGRAF and other IEC 61499 compliant tools is that the ISaGRAF uses its own coding for the library elements. The IEC 61499 standard defines the XML coding to be the structure of the library elements, which is not followed by the ISaGRAF tool. This way, the ISaGRAF tool accepts only data produced in other ISaGRAF software tool units, and by supposition data produced in it can not be exploited in any other software. [14] The commercial ISaGRAF is intended to be used in the industry as it is widely advertised for companies in the industry field. However, the compliance profile of the ISaGRAF has raised up some questions, is the tool following strict enough definitions of the IEC 61499 standard, or is the software just intended to be workable and sold as much as possible while carrying the name of the IEC 61499 standard. The behaviour of the tool is more similar to the execution semantics from the IEC 61131-1 standard, as the tool uses cyclic function block invocation. In ISaGRAF, the function blocks are always invoked in some fixed order and the ECC’s are evaluated in every scan. More comprehensive investigation about the semantics of the ISaGRAF tool is discussed in [45].

3.5 BlokIDE

BlokIDE is a graphical software tool, which enables creating applications according to the IEC 61499 standard. The tool runs on Microsoft Visual studio, and is freely downloadable. The BlokIDE has been developed for producing formal, deterministic applications, which can be especially used on different mathematical proving purposes and safety-critical embedded control systems. The software includes a model editor, where the user can develop application in a model-driven way. The model can be verified and debugged to check the 40 behaviour and fulfilling of safety and liveness properties by using tools which come with the software. A timing analyser can be additionally installed to the BlokIDE, to measure and detect the worst-case reaction times of the generated application and its parts. [52], [53] BlokIDE generates human readable ISO-C code with Makefile scripts, which does not require runtime environment for executing the code. The produced code is supported by many C compilers, and is usually platform-independent. In some cases, the code can be run on x86 architectures, depending of the implementation of the service interface function blocks. The software tool is equipped also with a design simulator, which allows the user to simulate the IEC 61499 function blocks by step-by-step. [52]

3.6 Features of the software and creation of test application

The storing format of the the IEC 61499 application elements is defined to be XML by the standard. As described in the chapter 2.3, the following of this definition in difference compliant tools varies a lot. The basic library structures of the different software are gone through on the following chapters. On each software tool, a basic math calculator program is being developed to be similar in all tools by its functionality and application structure.

3.6.1 NxtStudio

In NxtStudio, the storing of the project files is distributed into different subfolders. The format of the function blocks and system connections and device configurations is implemented in XML. The location of the main configurations and system contents of the project is in IEC61499 folder, where the user created basic and composite function blocks are listed as .fbt ending files and the system configuration defined inside System folder in [SystemName].sys named file. The HMI folder is contains mainly all the NxtStudio specific files relating to the visualization features of the software.

Figure 14. Contents of the main project folder in NxtStudio.

Figure 15. Contents of the IEC61499 folder, where the configuration and different elements of the project file are separated further into own subfolders.

The above folder structures are taken from a basic HMI application, where from the HMI window can be inserted two real numeric values with one certain string operator by the user. Each insertion requires pressing of the Enter button to create an event signal and transfer the data forwards from the HMI function block to the calculation function block. The calculation block returns the result of the calculation onto the HMI window:

Figure 16. HMI application where a basic mathematical calculation can be executed in NxtStudio. 42

3.6.2 FBDK

The FBDK uses similar XML storing format for the library elements as the NxtStudio in previous chapter. The function block units are saved as own .fbt file format and the application network / system configuration as .sys file extension. The user created content is stored as XML format in the src folder in the main FBDK folder of the program. The location of the content in src folder can be basically selected into any location from the pop-up saving window in the program by typing the path for the saving direction. Beside every new saving, the FBDK stores also all the older versions of the same file with .bak[number] ending for backup purposes. Before the saved XML elements can be used in FBDK, they have to be compiled by the Java compiler. This can be done at the same time during the saving process, where in the saving pop-up window can be selected all the possible choices to be done for a certain file.

Figure 17. Saving pop-up window in FBDK, where the location and (multiple) saving format(s) of the file can be selected.

As in previous chapter, a similar basic math application was attempted to create also in FBDK as in NxtStudio. The logic of the application is basically the same, as two numeric value inputs and one input for defining the operator are inserted by the user to the HMI window, which in turn transfers the data to the BasicMath function block after clicking Calculate button (Figure 21). The BasicMath function block calculates the result, which is then transferred back to the HMI window. When compared to the NxtStudio, the structure of the application differs especially on the HMI features, as the implementation of the graphical elements is software specific. Therefore, the portability of the graphical features is very restricted, especially when FBDK is Java based and NxtStudio uses C#. The creation of the similar basic math application in FBDK as in NxtStudio faces some problems, as the guard conditions between the ECC states can not seemingly be defined perfectly. The software does not accept the evaluation statement in correct form between string variable and string text written in apostrophe marks (double or single) straight into the condition field. If the condition is written without the apostrophe marks or by some other specific “tricky” way which the transition editor accepts, the Java compiler will raise an error of incorrect form in the guard condition.

Figure 18. FBDK can not handle string evaluations containing apostrophe marks in the transition editor. The condition shown in Figure 18 can be still inserted into the FBDK’s transitions by importing a similar function block file from outside into the FBDK. The single apostrophe marks are now visible on the guard conditions in the ECC of the imported function block. However, if the imported function block is saved with the Java option in the saving pop-up window (Figure 17), the Java compiler will raise an error for incomparable types of byte and char variables (Figure 19). In case of using double apostrophe marks in the guard condition for defining the strings on the function block to be imported, the FBDK will not accept the function block file at all.

Figure 19. Even if the transition editor problem in Figure 18 can been avoided by writing the guard condition straight into the source code, FBDK will raise an error for an incorrect comparison.

The compiler problem of byte and char can be avoided by modifying the content of the function block in a way that the string text (char variable in error code) tried to write straight into the transition editor will be replaced with an internal string variable, which has the 44 corresponding value. However, even if now the variables OPER and Plus (Figure 20), where the Plus has a value of ‘+’, are both now defined as string types, and the value ‘+’ is inserted for the variable OPER, the evaluation of these two strings does still not seem to work correctly by not giving a true condition and firing the transition. From the Figure 19, it can be seen that the FBDK seems to change the type of the string variables to byte[]. Even if the OPER and Plus variables are both set to string types and then presumably both converted automatically to byte[] types, the transition evaluation will not still work. The problem exists at least in versions 2.6, 3.1 and 3.3 (Version 20180902), where the latter was the newest available version during the testing of the problem [44].

Figure 20. Firing of the transitions in ECC seems not to work properly with STRING types in FBDK.

The reason for this kind of problem seems to be caused by the token-wise conversion which FBDK performs when it parses the ST code for Java syntax form. It sets some limitations, which restricts the use of TIME, STRING and WSTRING types in FBDK. [54] The problem was also personally asked via email from the developer Holobloc Inc. ([email protected]) of the FBDK, and the conversation is published in [55]. The developer stated the same fact that the condition checker of the transition editor does not accept the single or double atmosphere marks required for the STRING and WSTRING types. Even if they have been accepted, it would not help the base problem, which is that the Java generator of the FBDK is not parsing the contents of the IEC 61131- 3 standard completely in all cases for making a proper running code. [55] The developer suggested an alternative implementation based on the ECC shown in the Figure 20 by creating such a similar basic math function blocks CALC5 and CALC5TS, where the selection of the operator is done by triggering different events, and the operands of the calculation are inserted into the same variable with an event trigger between them. The function block types were inserted into the FB Navigator of the FBDK, which can be found from the student folder of the program. [55], [56] The operation of the CALC5(TS) function blocks is basically the same as on the function block intended to create in this math application example. However, because of the structure of the suggested function blocks is still quite different to the block created for example in NxtStudio, the basic math function block and application in FBDK was defined 45 to work in this test case with integer operator values 1, 2, 3 and 4, which correspond to values +, -, * and /.

Figure 21. Basic HMI calculator application implemented in FBDK.

3.6.3 4DIAC

In 4DIAC, the XML library elements and other files which are used on certain project are stored by default into the workspace folder of the software, grouped by project named folders. Function blocks are saved as .fbt ending files and system configuration by .sys ending. All the available library elements in every project are saved, even if they are not used in the actual program. Instead of using one device, the basic math application as created earlier in NxtStudio and FBDK has to be implemented in 4DIAC by using two devices types: FORTE_PC and FBRT_WINDOW. The reason for this is the visualization part, which is not supported by the FORTE. Therefore, in 4DIAC the human machine interface is realized by using the same Java implementation as in FBDK. Because of the use of two (different type of) devices, additional PUBLISH and SUBSCRIBE function blocks are needed to enable the communication between them. Conversion from the IN_ANY block, which handles the input from the user in Java window, to right data type is required by the tool, in order for the data to be sent forwards.

Figure 22. Logic of the basic math application is implemented on the FORTE device (green blocks), whereas the visualization and human machine interface is mapped onto the Java (window) device (pink blocks).

Before the application can be run and installed on the devices, the parts of the application which are intended to run on the FORTE device, such as the created BasicMath4DIAC function block, have to be first exported as a C header file (.h) and C++ file (.cpp) from the 4DIAC’s own exporter tool. Into the same directory, an additional CMakeLists.txt file has to be created that the newly created function block will be taken into the compiling phase of the FORTE. Before compiling, the FORTE binaries have to be configured and generated, which can be done for example on Windows by using CMake tool and MinGW Makefiles. After this, the FORTE runtime can be built by using make command in the binary directory via command prompt, and the FORTE will be ready to launch from 4DIAC’s deployment view. In order to start the FBRT device, it is enough that the computer has at least Java version 8 and the path to the fbrt.jar file is set in the 4DIAC’s settings. [50]

3.7 Portability of basic function blocks between tools

In this chapter, the portability of the single basic math function blocks created in NxtStudio, FBDK and 4DIAC with ST implemented algorithms is investigated.

3.7.1 Portability from NxtStudio to FBDK

Importing elements from NxtStudio to the FBDK is done by dragging the file to be transferred from the operating system’s file explorer into the FBDK Editor window. The element appears into the main view window, if the element is supported by the software. It needs to be saved separately from the saving menu in order to use the element later.

Figure 23. XML file containing elements not supported by FBDK.

To port the earlier shown basic math function block created in NxtStudio successfully into the FBDK, the basic function block file needs to be modified a bit before the FBDK can accept the file. NxtStudio uses XML elements named as Attribute in its function blocks, which needs to be removed before the FBDK can open the function block file. The Attribute elements used by NxtStudio are seemed to store some tool-specific configurations, such as the shapes of the transition arrows in ECC from one state to another.

Figure 24. NxtStudio uses extra definitions for example defining the shapes of the transitions flows.

After removing the Attribute elements from the function block created in NxtStudio, FBDK will open and show the structure of the block graphically in the editor. Despite that, the function block is not yet still operable, as the block has to be first saved and compiled. The Java compiler of the FBDK might report from errors in the definitions of the transition conditions in ECC, as they might have been implemented in the NxtStudio in a way which is not supported by the FBDK. In NxtStudio, the definitions of the required event signals and guard conditions to fire the transition can be written on one same field separated by logical operator in form of EVENT AND guard condition (Figure 25). The FBDK (or, actually FBRT and its Java compiler) does not support this form of transition definition but requires the form to be in EVENT [guard condition], which is also supported by the NxtStudio.

Figure 25. Varieties in possible guard conditions (FBDK form can be used in NxtStudio also). 48

3.7.2 Portability from FBDK to NxtStudio

Porting the library elements from FBDK to NxtStudio is not very straight forward as the other way around. The importing of new (basic function block) elements into NxtStudio is done basically by right-clicking the Basic element in NxtStudio’s project tree, selecting Import and then browsing and selecting the basic function block file to be imported. The described method would be such an easy way to import files to NxtStudio, where the files have been created in other instance of NxtStudio. But, as the case is trying to import files from FBDK to NxtStudio, the file to be imported requires some modifications and “re-settling” in order to be recognized and accepted by NxtStudio. In FBDK, the .fbt ending function block files can be only dragged and dropped into the window of the FBDK Editor. In NxtStudio, the external function block file can be also drag- and-dropped into a specific area of the software window (basically somewhere else than on the editor or the project tree area), but the file is this way only “viewable”. However, the file can be still partially modified and saved straight on the original file source, but importing the particular function block into NxtStudio’s own projects for an actual use is not possible by the drag-and-drop method. In addition to the above, importing of the external function block files can not be done directly with only the .fbt file. NxtStudio requires the (basic) function block file to be included in IEC61499 named folder, which is compressed as a zip file (with .Basic ending). In the zip file, there have to be alongside the IEC61499 folder .export ending file, which contains the information of the file type and name in IEC61499 folder to be imported into NxtStudio (Figure 26). If the importing is successful and a copy of the export file also exists in the same directory as the zip file, the export file will be removed automatically by the NxtStudio.

Figure 26. The required structure of the zip file that NxtStudio accepts (basic) function block files to be imported into the tool. Below is the content of the export file. Basically, the basic function block file is now imported from FBDK to NxtStudio successfully. The name defined in the XML structure of the imported function block is ignored and changed automatically to the filename of the block. However, the operation of the function block will not likely be correct, as the implementations of the Structured Text algorithms are missing. The reason to this is the different storing structure form of the algorithms in XML file of the function block between FBDK and NxtStudio. As seen in Figure 27, NxtStudio implements the ST algorithm as a text into the attribute Text in the ST element. FBDK uses CDATA (character data) method for indicating the software what part of the XML file is containing the structured text algorithm. The algorithm structure of the NxtStudio is 49 readable and understandable by FBDK, which converts automatically the algorithms to be saved in CDATA form. On the case of importing function block files containing the algorithms in CDATA form to NxtStudio, the tool will just ignore the algorithm content without any separate warning, leaving the algorithm fields empty.

Figure 27. Differences between NxtStudio and FBDK implementing the Structured Text algorithms into the XML file.

Because the NxtStudio accepts the importable files as a zip file, the compression method of the zip file also affects the readability of it. The function blocks which are exported from NxtStudio as a zip file, and which are not opened and recompressed by some other software, can be read by the NxtStudio without troubles. Instead, the built-in zip file compressor in the resource/file manager of Windows 10 operating system uses an algorithm that is readable and acceptable by the NxtStudio partially. The compression method differs in a way, that the zip files created by Windows 10 file manager are readable by the NxtStudio only in cases where the name of the export file included in the zip file is starting by some specific letter, which are approximately from A to H. Owing to the lack of complete error information in the unsuccessful file importing process, it might be sometimes hard to solve the reason for it. The compression method of the zip file can be unsupported type, or the information/content of the importable files might be incorrect.

3.7.3 Portability from NxtStudio to 4DIAC

Porting of the library elements from NxtStudio to 4DIAC can be simply done by copying the function block (.fbt) file from NxtStudio’s project folder into the corresponding workspace directory of the 4DIAC project. Another option is also drag and drop the same file into the desired location in the Type Manager tree. In this math application case, the 4DIAC accepts the NxtStudio’s version of the basic math function block file without any prominent error messages. After that, the file is only needed to be exported by the 4DIAC exporter tool to C++ format, if the function block is included into an existing module. The reference of the newly added file is required to be also included in the CMakeLists.txt, that the compiler will notify and compile the function block to be operated in the FORTE. 50

As the case was with FBDK, the 4DIAC (or, actually FORTE and its compiler) does not also support the NxtStudio’s additional form for the transition conditions. The form “EVENT AND guard condition” has to be changed to form “EVENT [guard condition]”, which can be done straight from the 4DIAC editor. In the 4DIAC editor, the warning message is seen on the unresolvable CALC variable in the transition editors, which however does not prevent the software to export the function block file into C++ format.

3.7.4 Portability from 4DIAC to NxtStudio

Porting of the library elements from 4DIAC environment to NxtStudio requires such similar steps as on the case from FBDK to NxtStudio. The (basic) function block files (.fbt) which are intended to import into the NxtStudio, need to be settled in a right (zip) folder structure as described in 3.7.2 and shown in Figure 26. When this is in order, the importing of the new elements is done just by right clicking the specific function block type (Basic) in the NxtStudio’s solution tree and selecting Import. After that, the directory of the zip file containing the files to be imported is needed to be defined. The XML-structured (basic) function block file (.fbt) itself created in 4DIAC does not to be modified in any way to be accepted by the NxtStudio correctly. The 4DIAC uses the same structure method for storing the ST algorithms in form as in NxtStudio. which means that conversion from CDATA form to other formats is not needed.

3.7.5 Portability from FBDK to 4DIAC

Porting of the library elements from FBDK to 4DIAC is basically done by dragging the desired function block (.fbt) file from the FBDK’s project folder into the specific location of the Type Manager tree in the 4DIAC Editor. Another option is also to copy the file straight into the workspace directory of the 4DIAC project and refreshing the folder content from the Editor to be able to see the newly added files. Before the 4DIAC accepts the file from FBDK, the ST algorithms written in the CDATA form in the FBDK’s function block file need to be changed into a form, where the algorithms are written in the value field of the Text attribute inside the ST element of the XML structure. Otherwise, the tool will not open and show any parts of the function block at all. After the modification, the 4DIAC accepts the function block, which can be further edited in the Editor. If some of the ST elements in the XML structure of the inserted function block does not have a Comment attribute included, the 4DIAC Editor seems sometimes show misleadingly incorrect content (usually empty code) for the ST algorithms. However, the problem should not prevent the use of the function blocks, as the algorithms are still existing and at intervals they appear to visible by clicking the algorithm names/contents several times. Also, if any of the VersionInfo elements in the XML structure does not contain one of the following attributes: Version, Organization, Author, Date or Remarks, the tool will not be able to open and show the content function block. Even if the 4DIAC has basically accepted the function block successfully from the FBDK after required modifications, the content of the header attribute in the CompilerInfo 51 element of the function block needs to be yet removed or at least modified, especially if it is going to be run in the FORTE environment.

3.7.6 Portability from 4DIAC to FBDK

Porting of the library elements from 4DIAC to FBDK can be simply done by going into the directory of the function block elements in the 4DIAC repository. Then, the function block file can be drag-and-dropped from the resource management window to the FBEditor window. The function block tab will appear in the FBEditor, which needs to be individually saved with XML and Java check squares to be able to use the newly imported block in FBDK. An important note which has to be considered when porting function blocks from 4DIAC to FBDK, is that the (default) event type in both compliance tools is different. The 4DIAC uses Event as an event type in every basic function block, which could be changed from the drop-down menu in the software tool, if there would be any other options for other types. Therefore, the 4DIAC inserts additional attribute Type=”Event” automatically in the field in the XML file. The default event type in FBDK is “nothing”, which is seen as an EVENT text in the function block interface view of the FBEditor, and a lacking attribute Type in the XML source file. The differences with the definitions of the event types is realized at the application network, where the imported function block from 4DIAC can not be connected with other function blocks by the event signals. The type of the event on the imported function block is required to be cleared, or vice versa the type of the events on already existing function blocks needs to be changed to the same as on the imported one.

Figure 28. None of the above function blocks can be connected to each other by the event signals in FBDK.

However, the event types “nothing” and EVENT are seen as a same text in the FBEditor, which can cause minor misunderstandings if the reason for unsuccessful event connections is not understood at first place.

3.8 Portability of composite function blocks between tools

The basic math application created in the tools in previous chapters is further developed by creating a composite function block, which has the same behaviour as the basic calculation 52 function blocks created earlier. Only the structure of the calculation function block is now different, as the operation is instead of one ECC done now by network of several (new) basic function blocks. In this chapter, the portability of the composite function blocks containing networks of other function blocks between the IEC 61499 tools is investigated.

Figure 29. Structure/Network (left) of the composite function block (right) which has the same functionality as the basic calculation function block presented in previous chapters.

The XML structure of the basic and composite function blocks is similar in some parts. Both types have an element FBType as their root element, which contain the InterfaceList as their first child element. The classification of the block to either basic or composite function type comes visible on the next child node, which is BasicFB on the basic function blocks and FBNetwork on the composite function blocks.

3.8.1 Portability from NxtStudio to FBDK

The importing of composite function block from NxtStudio to FBDK is done basically the same way as the case with basic function blocks, by dragging the function block file from the file explorer to the editor window of the FBDK. However, the FBDK does not show any visual error messages when trying to import the composite function block into the FBDK before all the related function blocks that the composite function block contains are already imported into the FBDK. Also, there are at least few unsupported elements added by NxtStudio which are required to be removed from the function block file’s XML structure before the FBDK accepts the importing of the block successfully. As the case was with the basic function blocks, the NxtStudio’s own specific configuration element Attribute exists also in the composite version, which need to be removed. Secondly, inside the FBNetwork element, NxtStudio uses also Input and Output elements to inform the software the locations of the event/data input/output variables from the interface in the function block network field area (for example, the location of the CNF and Result output variables in the Figure 29). In FBDK, these composite function block’s 53 interface variables are straight “fixed” to the network’s function blocks’ inputs, and are thus always on the same location as the function block itself. Therefore, the removal of these NxtStudio specific elements is required. In addition to the dx and dy attributes which are usually used to form the connection lines, the Connection elements in NxtStudio might have also Points elements inside them, which save the (multicurve) track/route of the line from some output to some input in some cases. However, the FBDK does not support this kind of curve definition, as it does not also recognize the AvoidsNodes elements which are included in every Connection element in NxtStudio.

3.8.2 Portability from FBDK to NxtStudio

The importing of the composite function blocks into the NxtStudio is done the similar way as with the basic ones. The right-clicking of the Composite element in the Solution Overview gives a pop-up menu, where the selection of importing (composite) function blocks can be done. The function blocks which are intended to import into the NxtStudio, need to be stored in a zip file, where the actual function block is locating in IEC61499 folder and its export file next to the folder (Figure 26). Instead of as the FBDK, the NxtStudio informs better the user of the missing function blocks which are not found in the tool’s block library but are still existing in the composite function block’s network. Therefore, the tool does not import the composite block before all the other blocks are imported. The XML structure of the composite function block itself does not have to be modified in anyway in order to NxtStudio to accept it. As the case was with basic function blocks, the name of the composite block changes also automatically to the filename of the block. Also, the export file naming twist with Windows 10 resource manager built-in zip compressor exists the same way as with the basic ones.

3.8.3 Portability from NxtStudio to 4DIAC

Composite function blocks can be imported into the 4DIAC by the same way as the basic ones; by dragging the block file into the Type Manager tree or copying it into the desired workspace location. The name of the block in the editor will be taken from the filename of it. If the composite block is ported into the 4DIAC before all the internal elements in the function block’s internal network, the tool will despite that save the file (without allowing to perform any modifications) and show in the composite network map which elements are missing. To make the imported composite block runnable in the 4DIAC, the block itself does not have to be modified in any way, but the compiling of the composite block and its internal elements must be first done before it can be run on the FORTE.

3.8.4 Portability from 4DIAC to NxtStudio

Importing the composite function blocks from 4DIAC to NxtStudio does not require any specific modifications into the XML source file itself, but for the importing process the 54 function block file (.fbt) has to be included in a specific structured zip file as described in previous chapters.

3.8.5 Portability from FBDK to 4DIAC

Composite function blocks can be imported from FBDK to 4DIAC simplest way by dragging and dropping the source file from file manager to the desired system in the Type Manager tree. The XML source file does not need to be modified in any way for to be accepted by the 4DIAC. Only the Header information of the CompilerInfo has to be removed or changed, as the compiling setup is not likely the same in different compliant tool.

3.8.6 Portability from 4DIAC to FBDK

Porting the composite function block from 4DIAC to FBDK can be done by dragging and dropping the function block file from the file manager to the FBDK editor window. All the related function blocks inside the composite function block have to be first imported into the FBDK. Otherwise, the FBDK does not accept it and not react in any way by not showing any error messages. As the case was with basic function blocks, the (default) event type might need to be changed before the imported composite function block can be connected to other function blocks which have different default event type when created in FBDK (Figure 28). Also, the FBDK does not report on all cases from incorrect connections, as it is possible to change the type of internal function blocks’ data inputs and outputs, while they are connected to the composite function block’s different types of inputs and outputs, and run the application.

3.9 Portability of IEC 61499 systems between tools

For testing a system portability between the different compliant tools, a new traffic light system was created in each software. The system consists of four traffic light units, which are run on four different devices. The operation mode unit is run on the fifth device, which controls the current selected mode of the traffic lights. Lights can be either set to run on 2 or 4 phase cycle mode, set to red, turned completely off or set to blinking mode.

Figure 30. Traffic light application implemented in NxtStudio.

In NxtStudio, the function blocks of the application can be mapped to a certain device by right-clicking the certain block, and the NxtStudio automatically handles (in this local computer host case) the needed communication configuration from one block in a certain device to another block in other device. In FBDK and 4DIAC, this is not as straight forward, as the mapping of the function blocks to different devices does not automatically create workable communication between them, and thus the use of extra communication blocks is required.

Figure 31. Traffic light application implemented in FBDK.

In FBDK, use of the PUBL and SUBL type function blocks with the same function block instance name in different resources creates automatically workable communication between them. However, connecting the mapped elements in the application level with event and data connections does not automatically connect them in the mapped resource, as in the case of NxtStudio and 4DIAC.

Figure 32. Traffic light application implemented in 4DIAC. The function blocks which have the same color are mapped to same device (right side mapped to FBRT, left side to FORTE).

In 4DIAC, the use of the “external” implementation of HMI features provided by FBDK requires using separate devices for HMI units and other code. Thus, the application in this case is distributed a total of 10 devices, where 5 of them run each of the HMI elements on Holobloc Inc’s FBRT and the remaining 5 control the logic of these each light/button unit in separate FORTE devices. Because of the large use of event transmitting instead of data in this application, each event requires basically their own publisher and subscriber in FBDK and 4DIAC, which are needed to be created manually, whereas NxtStudio handles the communication between different devices automatically. Therefore, the use of the communication blocks especially in 4DIAC with 10 devices causes major overhead into the application, as the IEC 61499 57 standard’s library does not offer simple solution to handle large amount of transmittable events with only one or few communication blocks. Additionally, the inability of modifying and compiling the FBDK’s blocks for example inside composite function block causes unnecessary extra amount of blocks to be shown in the application / device resource. The target of the system portability test is in the first place to try to transfer the application, device and communication configurations into other compliant tool as unmodified as possible, and make it runnable on the other software. The test is limited only to the default software devices which are run on the local host computer (Windows 10 in test environment). On importing the system files, the related function block files in the system are already imported before the system import.

3.9.1 Portability from NxtStudio to FBDK

Importing of the [SystemName].sys file representing the IEC 61499 system configuration can be basically done by drag-and-dropping the file from the [NxtStudio’s project folder]/IEC61499/System folder in operating system’s file manager into the editor area of FBDK. Before the system file is accepted by the software at all, the unsupported NxtStudio specific elements such as AvoidsNodes and Points need to be first removed. After that, the FBDK will accept the file and show the system and application configuration for those elements which are already imported or existing in FBDK. The tool will itself remove the NxtStudio specific attributes (for example NameSpace) from the XML elements in the system source file. To get the mappings of the function blocks from the application level to be correctly mapped into the devices’ resources, the function block name has to be included in the mapping element after the resource name within the attribute To. In NxtStudio, the default device type is NXT_RMTDEV, which includes automatically EMB_RES_ENH resource type supporting also the operation of graphical block elements responsible for HMI features. To implement human machine interface content in FBDK, a FRAME_DEVICE with PANEL_RESOURCE is exemplary device and resource type to run the graphical, human machine interface content on the local computer. Because of the different graphical implementation environment between NxtStudio and FBDK, the functions blocks related to the HMI features (SelectMode, TrafficLight[…], in Figure 30) implemented in NxtStudio cannot be transferred from it to FBDK. In other aspects, the system configuration with device and application information can be ported from NxtStudio to FBDK fairly successfully. However, if there are straight event or data connections made in the application level from one device’s function block to another device’s block in NxtStudio, the software adds own specific hidden communication blocks to enable the communication between these devices without user’s effort. This affects also onto the XML structure of the system configuration file, where the NxtStudio specific communication blocks need to be removed and replaced by some other supported method (for example by using publish and subscribe communication blocks) before the system can be made runnable and workable in FBDK.

Figure 33. NxtStudio’s specific hidden communication blocks enabling the transfer of the events and data from one device to another automatically.

3.9.2 Portability from FBDK to NxtStudio

Importing the system from FBDK to NxtStudio is not as straightforward as the other way around. If any system file (including files created in NxtStudio) is drag-and-dropped from the operation system’s file manager into the (top area of) NxtStudio’s window, the system will be only viewable with details and elements which are supported (such as device types) or existing already in the project’s library (such as function blocks). In NxtStudio, every system is linked with a solution (project) file, and to create another system, a new solution is required. The system porting between two NxtStudio instances is done actually by porting a zipped project folder, which can be handled from the built-in tool in File -> Archive/Unarchive Solution. Thus, the importing of system files from other IEC 61499 compliant tools to NxtStudio can not be done in a simple way. One way to import the system from FBDK to NxtStudio is to modify or change the XML file responsible of the system structure of the NxtStudio project in [NxtProjectsLocation]/[ProjectName]/IEC61499/System/[SystemName].sys. To get the system properly open in NxtStudio, the device and resource types have to be changed to the supported ones, such as NXT_RMTDEV and EMB_RES_ENH. Also, additional NameSpace attribute is required to be included in each function block element in the system 59 source file, with a certain value. The function blocks created by the user have the namespace value of Main, whereas (the NXT_RMTDEV) devices have value of nxtControl.Standard. The resources of the default devices have a namespace value of Runtime.Management, and the communication blocks IEC61499.Communication. The SUBL and PUBL communication blocks are not recognized in the IEC61499.Communication (Version:2.1.0.0) library, and thus need to be removed or changed for example to SUBSCRIBE and PUBLISH blocks. However, the use of the communication blocks is not necessary, as the NxtStudio can create the communication automatically between different function blocks in different devices, if the blocks are connected to each other in the application level. Before the system can be made operable, the deployment (/port) settings in either NxtStudio’s Devices tab or in the source files [SystemName].cfg and [SystemName].Device.Properties have to be defined properly.

3.9.3 Portability from NxtStudio to 4DIAC

Importing of the system files into 4DIAC editor is done via the 4DIAC’s own internal enhanced straightforward system importer tool in File -> Import -> 4DIAC -> System Import. The tool only requests the location of the system file and the folder where the files of the function blocks included in the system are located. In the importing process, the tool will notify which elements could be successfully imported and which not. As the case was with porting the system file from NxtStudio to FBDK, the NxtStudio specific communication blocks need to be removed and replaced by some other communication blocks to enable the operation of the system. 4DIAC can remove the other NxtStudio specific unsupported XML elements and their attributes from the system source file itself, such as AvoidsNodes, Attribute and NameSpace. The function blocks responsible for graphical implementation need to be replaced by other types supported by 4DIAC. The default device type NXT_RMTDEV and resource type EMB_RES_ENH of NxtStudio are required to be changed into the 4DIAC’s own ones FORTE_PC and EMB_RES to run the non-graphical content on local computer. For graphical content, the use of FBDK’s device FBRT_WINDOW with PANEL_RESOURCE is required. For some reason, in the importing process 4DIAC will add an extra empty default resource type alongside the existing resource type(s) in the devices. As with the importing from NxtStudio into FBDK, the mapping destination of the function blocks in the system source file requires also the function block name after the resource name in To attribute. However, in the importing process, 4DIAC also duplicates the mapped function block from the application level into the resource’s network, if the mapped function block is already included in the corresponding resource in the XML system source file. If the already existing mapped function block is removed from the resource before importing the system file, the connections inside the resource will not be connected to the mapped block with same name and type automatically, causing some manual work for reconnecting the connections.

3.9.4 Portability from 4DIAC to NxtStudio

Importing of the system file from 4DIAC to NxtStudio requires similar steps as in the case of importing from FBDK to it. The system file can be drag-and-dropped into the NxtStudio window only for view purpose, but for importing it, an existing NxtStudio system file has to be modified or replaced by the 4DIAC’s one. To be able to open the system structure in NxtStudio, the device and resource types have to be changed to supported ones, such as NXT_RMTDEV and EMB_RES_ENH from the 4DIAC’s FORTE_PC/FBRT_WINDOW and EMB_RES/PANEL_RESOURCE. Also, parameters which are not included in NXT_RMTDEV’s interface, needs to be removed. Every function block in application and resources has to also contain attribute Namespace with proper value, which is usually Main for user created function blocks, nxtControl.Standard for (default) devices, Runtime.Management for their resources and IEC61499.Communication for communication blocks. From other aspects, the system file structure does not need to be modified further to get the imported system operable in NxtStudio. Only definitions of the device settings (such as port settings) has to be done properly before launching and deploying the system into devices.

3.9.5 Portability from FBDK to 4DIAC

Porting the system from FBDK to 4DIAC is done in a similar way as from NxtStudio; using 4DIAC internal system importing tool. The system file of the FBDK does not need to be generally modified for 4DIAC to accept it, except for the device and resource types which need to be FORTE_PC with EMB_RES for non-graphical and FBRT_WINDOW with PANEL_RESOURCE for graphical content for local computer run. As the case was with NxtStudio, 4DIAC also adds extra resources to devices and duplicates the mapped elements from application to the resources’ function block network when importing the system file from FBDK. The clearing of the resource content from XML source file before importing the system file does not fix the problem where the connections inside the resources’ function block network are not connected to the mapped element. The use of the PUBL and SUBL communication blocks in FBDK does not work the same way in 4DIAC environment. In FBDK, the SUBL block will receive the content from the PUBL block in different device, if only the names of the block instances are identical, even without any parameter value in ID. Also, even if the 4DIAC is using the FBDK’s implementation for graphical, HMI features, all the content created in FBDK cannot be run in 4DIAC. In FBDK, the function blocks responsible for graphical content can locate for example in composite function block, which means that the composite function block cannot be compiled in either 4DIAC’s FORTE_PC because of the graphical contents, or in FBDK’s FBRT_WINDOW, because the 4DIAC has only the default library set from FBDK.

Figure 34. In the system importing process, 4DIAC adds the already existing function blocks from application level to device's resource again. If the existing function blocks are removed from the resource before system import, the connection lines between the mapped and existing resource elements (such as SUBL and PUBL communication blocks) will be broken.

3.9.6 Portability from 4DIAC to FBDK

Importing the system file from 4DIAC to FBDK can be done by drag-and-dropping the file from operating system’s file manager into the editor area of FBDK. Before FBDK accepts the file, some unsupported XML elements, such as Attribute used for example defining the colour of the devices in 4DIAC, need to be removed. After that, FBDK accepts the file without any error messages. However, to get a proper importing of the system, the device and resource types need to be changed into ones existing in FBDK, such as FRAME_DEVICE with PANEL_RESOURCE. From other aspects, the porting of the system file is quite straightforward.

4 Results

The porting test of the elements between the IEC 61499 compliant tools NxtStudio, FBDK and 4DIAC with single function block units and larger system configuration was completed. The migration from one compliant tool to another was mainly successful with either minor or greater modifications into the source code, leading to a workable component in other vendor’s software. The test was carried out by using software versions NxtStudio 2.1, FBDK 2.6 and 4DIAC 1.8.4 in Windows 10 operating system.

4.1 Portability between the IEC 61499 compliant tools

All of the above IEC 61499 compliant tools used the XML structure defined in the standard for saving the information of function blocks and system configuration. This enabled the migration of the elements between the tools to be more easily performed, as the conversion from completely different structures such as in ISaGRAF was not required. However, even if the compliant tools use the standard’s XML definitions for the source files, there is still deviation in the following of the standard, as the compliant tools are unable to read each other’s files without any modification. The biggest single remarkable portability issue between the compliant tools is the migration of the graphical HMI features. In NxtStudio, the visualization part is programmed in C#, whereas in FBDK it is implemented in Java. 4DIAC uses this same default graphical Java library from FBDK, but because in FBDK some of the graphical elements can be encapsulated inside of composite function blocks, this sets limitations of porting them into 4DIAC, as the composite function block cannot be compiled either into FORTE or FBRT. Another prominent issue in the migration process, although not affecting operational code features, is that the definitions of the horizontal and vertical locations of the function blocks in the network area differs in every compliant tool. In large applications, this might sometimes cause very messy results, as a big part of the function blocks might be piled up on top of on each other. Function blocks might also go outside of the editor area (especially on negative sides), which might be challenging to notice or transfer them back to the actual network area through the compliant tool user interface. The migration of the basic and composite function blocks requires most modifications when the files are either imported to or exported from NxtStudio. The amount of the additional features in NxtStudio is remarkable, and thus many XML elements need to be removed before FBDK accepts the function block files. 4DIAC can usually remove the unsupported elements, and save only the content which is useful and informative for it. The importing process from other compliant tools into NxtStudio is a bit more complicated, as the NxtStudio does not provide a simple enhanced way for importing the single bare source file without the encapsulating them into zip structures. From system configuration migration view, the first thing is to get the systems properly viewable in other compliant tools and to define the supported device and resource types into the source files. When importing to NxtStudio, additional namespace attributes are required for every function block in the network, so they can be recognized by the tool. Additionally, 63 the automatic communication handler between the devices in NxtStudio causes reimplementation of the communication methods into the application, when the system configuration is exported into other IEC 61499 compliant tools. Below is a table representing the portability rating between the tools based on the portability tests in chapter 3. As described in chapter 2.4, there are no standardized methods to measure the portability features of different compliant tools. The values are rough estimates based on the (1.) required amount of replaceable elements and their types inside the file (max 35 %), (2.) difficulty on replacing the element by other element or structure (such as HMI featured blocks, max 45 %), and (3.) easiness of importing elements into the tool (max 20 %). The higher the value is, the less effort in addition to the normal importing process is required by the user to get the component or system to work in other software.

Portability of IEC To 61499 compliant tools NxtStudio FBDK 4DIAC in scale of 0 – 100 % NxtStudio 100 % (35, 45, 20) 45 % (20, 10, 15) 50 % (25, 10, 15) From FBDK 45 % (25, 10, 10) 100 % (35, 45, 20) 90 % (30, 40, 20) 4DIAC 50 % (30, 10, 10) 95 % (30, 45, 20) 100 % (35, 45, 20)

Table 2. Portability of IEC 61499 compliant tools based on the investigation in chapter 3. The numbers inside the brackets refer to the evaluation aspects (1., 2., 3.) described above the table. Big part of the portability decrease between NxtStudio and other tools comes from the uncompatible HMI libraries.

4.2 Converter program

Based on the findings in the investigation in chapter 3, a Python programming language based converter was created to automate the required modification process for the compliant tools’ source files in order to make them more easily portable into other tools. The converter tool was implemented by using Python version 3.3.5 in Eclipse IDE. The converter is capable of executing almost all of the listed modifications needed for making the file work from one compliant tool to another. The converter program is running on a console window, where the user selects one (or more) action from the presented options by typing numbers on the window. In addition, the user is asked alternately to define which files are intended to be converted, where they will be written, and what elements the user wants to be replaced by some other element (for example HMI blocks). The program consists total of 9 different Python modules, listed on Table 3. It runs with the default library set of Python 3, so no additional libraries are required to be installed in order to run the program. The converter is started by running the MainProgram.py module, which is then controlled by the user from which IEC 61499 compliant tool is intended to convert some files into other compliant tool. The program can convert a single function block or system file at once, or all the functions block files in some directory with .fbt ending file name in one run. 64

Module Function MainProgram Module controlling the main program run by interacting with the user for defining the required resources to convert the source file to the target file. XML_Element Class representing one XML element of the file. XML_File Class representing the entire XML tree of the file, containing list of XML_Element objects. XML_Parser Module reading and parsing the actual source text files for constructing them as a XML_File object. XML_Modifier Module defining more specifically which functions are needed to execute from NXT, FBDK and FOURDIAC modules for the converting process. Parser_functions Minor module giving helper functions for the XML_Parser module. NXT_Functions Module containing all the related functions to convert files from NxtStudio to FBDK or 4DIAC. Contains also a zip packing manager for importing files into NxtStudio. (Python’s internal zip compression method currently not readable by NxtStudio) FBDK_Functions Module containing all the related functions to convert files from FBDK to NxtStudio or 4DIAC. FOURDIAC_Functions Module containing all the related functions to convert files from 4DIAC to NxtStudio or FBDK.

Table 3. Modules of the converter program with functionality descriptions.

Figure 35. The user interface of the Python based converter program running in Eclipse IDE console. 65

The source code of the converter includes several error handling mechanisms for situations such as invalid structure of the XML file or invalid user input. The reason of the error is presented, and the run of the program is usually terminated. In the user interface, there is occasionally given a new chance for the user to insert the already given input again, if for example the selected options do not match for the offered ones. However, the code is most likely not completely error free, as the creation of the converter is not based from all possible library elements available in different IEC 61499 compliant tools. Also, the zip compression packaging offered by the converter is not likely workable for the NxtStudio function block importing process. None of the compression types ZIP_STORED, ZIP_DEFLATED, ZIP_BZIP2 or ZIP_LZMA offered by the Python zipfile library has not workable effect on importing the function block file successfully. When converting the source file to be imported into NxtStudio, the program asks the user, if the files required for the importing process are intended to be automatically zip compressed, or only created and later compressed by the user by other methods. The Windows 10 resource manager zip compression built-in tool has also some limitations in the naming issues of the files, as described in chapter 3.7.2.

Figure 36. Error message in the function block importing process in NxtStudio when using zip compressed file created by Python zipfile library. From the error message can be seen, that the compression method is not supported. 66

5 Summary

The main purpose of this master’s thesis was to investigate the portability issues between different IEC 61499 compliant tools. The topic was first opened by introducing the features and possibilities of the IEC 61499 standard, followed by arguments explaining why the portability of the software systems and their components is important. Several examples of applying the standard into real life applications were presented and outcomes of the experiments discussed. The thesis concentrated on porting basic and composite function block files and system configurations with virtual devices from one tool to another. From the introduced compliant tools, NxtStudio, FBDK and 4DIAC were selected to be included in the investigation process of the portability features. The structures and the features of the software tools were presented, and the study elements and applications created. The first findings of the tools revealed that the test function blocks and applications could not be implemented in the same way in every tool, as it was intended. The portability of single function block units between the tools were examined and the result of the required modifications listed. One main noteworthy point on porting the single elements was that importing the files into NxtStudio requires a bit more sophisticated structure of the files in order to be accepted by the software. NxtStudio also uses a lot of its own specific types of elements in the XML structure, which is mainly not understandable by the other compliant tools. The function block file structures were itself very similar and respectable to the standard, which kept the amount of changeable elements at a low. The main incompatible issues between the NxtStudio and other tools were the completely different implementation structure of the graphical elements, which were not portable to other software at all. The portability of system architectures with applications and device configurations were also inspected and the result presented. The research revealed one significant difference in the system features between the tools, which was that the NxtStudio uses more enhanced automatic communication handling techniques, which makes the configuration and creation of the communication channels easier from the user point of view. However, this affects in a way that when porting the system into other tools, the implementation of the communication blocks and configurations needs to be basically, completely redone again. Based on the investigation, an IEC 61499 converter tool was created to automatize the modification process required for the files, so that they will be accepted and operable in other compliant tools. The program was implemented in Python, which has a user interface running on a console window. Essentially, the converter succeeds in modifying almost all the necessary contents of the files ensuring that the file created in one compliant tool is readable and workable in another.

References

[1] V. Vyatkin, "Software Engineering in Industrial Automation: State-of-the-Art Review," IEEE Transactions on Industrial Informatics, vol. 9, (3), pp. 1234-1249, 2013.

[2] W. W. Dai and V. Vyatkin, "A case study on migration from IEC 61131 PLC to IEC 61499 function block control," in Industrial Informatics, 2009. INDIN 2009. 7th IEEE International Conference On, 2009, pp. 79-84.

[3] V. Vyatkin, IEC 61499 Function Blocks for Embedded and Distributed Control Systems Design. 2007.

[4] C. Pang et al, "A portability study of IEC 61499: Semantics and tools," in Industrial Informatics (INDIN), 2014 12th IEEE International Conference On, 2014, pp. 440-445.

[5] J. Yan et al, "Adaptable software components: Towards digital ecosystems and software evolution in the industrial automation domain," in IECON 2014 - 40th Annual Conference of the IEEE Industrial Electronics Society, 2014, pp. 2512-2518.

[6] "Programmable controllers - Part 3: Programming languages," IEC 61131-3, pp. 9, 2013.

[7] (2018). Codesys [Online]. Available: https://www.codesys.com/.

[8] "Function blocks - Part 1: Architecture," IEC 61499-1, pp. 8, 2012.

[9] L. Ferrarini and C. Veber, "Control functions design and implementation of distributed automation systems for manufacturing applications," International Journal of Manufacturing Research, vol. 1, (4), pp. 442-465, 2006.

[10] V. Vyatkin et al, "Alternatives for execution semantics of IEC61499," in Industrial Informatics, 2007 5th IEEE International Conference On, 2007, pp. 1151-1156.

[11] T. Strasser et al, "Design and Execution Issues in IEC 61499 Distributed Automation and Control Systems," IEEE Transactions on Systems, Man, and Cybernetics, Part C (Applications and Reviews), vol. 41, (1), pp. 41-51, 2011.

[12] P. J. Brown, Software Portability: An Advanced Course. CUP Archive, 1979.

[13] C. Sunder et al, "Usability and interoperability of IEC 61499 based distributed automation systems," in 2006 4th IEEE International Conference on Industrial Informatics, 2006, pp. 31-37.

[14] J. H. Christensen et al, "The IEC 61499 function block standard: Software tools and runtime platforms," ISA Automation Week, vol. 2012, 2012.

[15] J. D. Mooney, "Issues in the specification and measurement of software portability," in 15th International Conference on Software Engineering, Baltimore, 1993.

[16] V. Vyatkin, "IEC 61499 as Enabler of Distributed and Intelligent Automation: State-of-the-Art Review," IEEE Transactions on Industrial Informatics, vol. 7, (4), pp. 768-781, 2011. 68

[17] M. Colla, A. Brusaferri and E. Carpanzano, "Applying the IEC-61499 model to the shoe manufacturing sector," in 2006 IEEE Conference on Emerging Technologies and Factory Automation, 2006, pp. 1301-1308.

[18] (2006). Model Integrated Mechatronics [Online]. Available: http://seg.ee.upatras.gr/MIM/index.htm.

[19] V. Vyatkin, S. Karras and T. Pfeiffer, "Architecture for automation system development based on IEC 61499 standard," in INDIN '05. 2005 3rd IEEE International Conference on Industrial Informatics, 2005. 2005, pp. 13-18.

[20] A. Lobov, J. L. M. Lastra and R. Tuokko, "Application of UML in plant modeling for model-based verification: UML translation to TNCES," in INDIN '05. 2005 3rd IEEE International Conference on Industrial Informatics, 2005. 2005, pp. 495-501.

[21] M. Fletcher et al, "A Critique on the Building of Decentralized Manufacturing Control Systems with UML Capsules," 2001.

[22] V. Vyatkin, "The IEC 61499 standard and its semantics," IEEE Industrial Electronics Magazine, vol. 3, (4), pp. 40-48, 2009.

[23] (2018). Matlab [Online]. Available: https://www.mathworks.com/products/matlab.html.

[24] (2018). Eclipse [Online]. Available: https://www.eclipse.org/.

[25] (2018). National Instruments [Online]. Available: http://www.ni.com/en-us.html.

[26] S. Patil et al, "On composition of mechatronic components enabled by interoperability and portability provisions of IEC 61499: A case study," in 2013 IEEE 18th Conference on Emerging Technologies & Factory Automation (ETFA), 2013, pp. 1-4.

[27] M. Sorouri, V. Vyatkin and S. Xie, "Distributed control design of medical devices using plug-and-play IEC 61499 function blocks," in 2012 19th International Conference on Mechatronics and Machine Vision in Practice (M2VIP), 2012, pp. 450-455.

[28] (2018). LabView [Online]. Available: http://www.ni.com/fi-fi/shop/labview.html.

[29] L. Gröhn et al, "Wireless and distributed automation system with smart update," Aalto University, Otaniemi, Espoo, 19.12.2016. 2016.

[30] Gesamtdemonstrator [Online]. Available: https://www.energieautark.com/syst/03_demo.htm.

[31] (7.3.2017). Wireless and Distributed Automation System with Smart Update [Online]. Available: https://wiki.aalto.fi/display/AEEproject/Wireless+and+Distributed+Automation+System+with+Smart+Upda te.

[32] SPS IPC Drives, Smart and Digital Automation, Nuremberg [Online]. Available: https://www.mesago.de/en/SPS/.

[33] A. Hopsu et al, "Flexible assembly line with robustness in IEC-61499 standard," Aalto University, Otaniemi, Espoo, 29.5.2017. 2017. 69

[34] (31.5.2017). Flexible assembly line with robustness in IEC-61499 standard [Online]. Available: https://wiki.aalto.fi/display/AEEproject/Flexible+assembly+line+with+robustness+in+IEC-61499+standard.

[35] V. Dubinin and V. Vyatkin, "Towards a formal semantic model of IEC 61499 function blocks," in 2006 4th IEEE International Conference on Industrial Informatics, 2006, pp. 6-11.

[36] A. Zoitl et al, Enhanced Real-Time Execution of Modular Control Software Based on IEC 61499. 2006.

[37] V. N. Dubinin and V. Vyatkin, "Semantics-Robust Design Patterns for IEC 61499," IEEE Transactions on Industrial Informatics, vol. 8, (2), pp. 279-290, 2012.

[38] P. Tata and V. Vyatkin, "Proposing a novel IEC61499 runtime framework implementing the cyclic execution semantics," in 2009 7th IEEE International Conference on Industrial Informatics, 2009, pp. 416- 421.

[39] L. H. Yoong et al, "A synchronous approach for IEC 61499 function block implementation," IEEE Trans. Comput., vol. 58, (12), pp. 1599-1614, 2009.

[40] N. Hagge and B. Wagner, "A new function block modeling language based on petri nets for automatic code generation," IEEE Transactions on Industrial Informatics, vol. 1, (4), pp. 226-237, 2005.

[41] W. Dai, V. Vyatkin and V. Dubinin, "Ontology-based design recovery and migration between IEC 61499- compliant tools," in IECON 2011-37th Annual Conference on IEEE Industrial Electronics Society, 2011, pp. 4332-4337.

[42] nxtControl GmbH. (2018). NxtStudio. Available: http://www.nxtcontrol.com/en/engineering/.

[43] T. Strasser et al, "Framework for distributed industrial automation and control (4DIAC)," in 2008 6th IEEE International Conference on Industrial Informatics, 2008, pp. 283-288.

[44] Holobloc Inc. (21.08.2018). FBDK - Function Block Development Kit. Available: http://www.holobloc.com/.

[45] V. Vyatkin and J. Chouinard, "On comparisons of the ISaGRAF implementation of IEC 61499 with FBDK and other implementations," in 2008 6th IEEE International Conference on Industrial Informatics, 2008, pp. 289-294.

[46] (03.04.2018). 4DIAC - IEC 61499 compliant development environment. Available: http://www.eclipse.org/4diac/.

[47] (12/05/2017). 4DIAC - IEC 61499 compliant development environment - Documentation - Overview [Online]. Available: https://www.eclipse.org/4diac/documentation/html/4diacIDE/overview.html.

[48] (11/11/2017). 4DIAC - IEC 61499 compliant development environment - Documentation - Advanced features [Online]. Available: https://www.eclipse.org/4diac/documentation/html/4diacIDE/advancedFeatures.html.

[49] (11/06/2017). 4DIAC - IEC 61499 compliant development environment - Documentation - Framework [Online]. Available: https://www.eclipse.org/4diac/documentation/html/before4DIAC/4diacFramework.html. 70

[50] (10/30/2017). 4DIAC - IEC 61499 compliant development environment - Documentation - Installation [Online]. Available: https://www.eclipse.org/4diac/documentation/html/installation/install.html.

[51] ISaGRAF 6 WorkBench. Available: http://www.isagraf.com/index.htm.

[52] (2016). BlokIDE. Available: http://pretzel.ece.auckland.ac.nz/#!research?project=iec61499.

[53] L. H. Yoong, Z. Bhatti and P. Roop, Combining IEC 61499 Model-Based Design with Component-Based Architecture for Robotics. 20127628.

[54] (11/02/2011). Algorithm Help Page [Online]. Available: https://www.holobloc.com/doc/fbdk/alghelp.htm.

[55] James Christensen and Holobloc Inc., "Google Group Discussions - FBDK (2.6/3.3): String guard evaluation in ECC," [Online]. 2018. Available: https://groups.google.com/forum/#!topic/fbdk/7jrXlUhCE_M.

[56] (28.08.2018). FB Navigator [Online]. Available: https://www.holobloc.com/doc/navigator.htm.

Appendices

Appendix 1. XML structure of the BasicMathFunctionBlock.fbt basic function block used in the portability test in chapter 3.7.1:

Appendix 2. XML structure of the MathCompositeNXT.fbt composite function block in portability test in chapter 3.8.1:

5 2.963543 Event 5 17.9635429 74

Data 5 32.5 Data 5 47.9635429 Data 870 182.963547 Event 870 197.963547 Data false false false false false false false false false 75

false false false false false 114.083321 40 385 40 385 270 425 270 425 269.5 470 269.5 false false false false 76

Appendix 3. XML structure of the System.sys traffic light application used in portability test in chapter 3.9.1:

false false 77

false false false false false false false false false false false false 343.21875 389.5 494.171936 389.5 494.171936 435 78

861.6719 435 861.6719 364.5 950 364.5 false 1087.39063 379.5 1100 379.5 1100 380 1115 380 1115 650 155 650 155 465 172.5 465 172.5 464.5 200 464.5 false 79

680.5833 59.5 735 59.5 735 175 895 175 895 379.5 950 379.5 false 680.5833 264.5 735 264.5 735 380 867.5 380 867.5 379.5 950 379.5 false false 80

false false false false false false false false false false false 81

false false false false false 82

false false false 83

451.901031 109.5 282.5 109.5 282.5 269.5 295 269.5 false false 85

451.901031 109.5 282.5 109.5 282.5 269.5 295 269.5 false false 86

false false 358.21875 389.5 509.171936 389.5 509.171936 435 876.6719 435 876.6719 339.5 480 339.5 false 88