Distributed Control System Technologies

1

Distributed Control System Technologies

Non-Technical Project by

Aranya Sarkar

Institüt für Automatisierungstechnik Faculty of Electrical Engineering and Information Technology Otto Von Guericke Universität Magdeburg

Supervisor:

Dr.-Ing. Thomas Hadlich

2

3

Statutory declaration

I, hereby, assure that I wrote this non-technical project independently and did not use any other means than the indicated sources and aids

Magdeburg, 18. Nov 2015

-----------------------

4

5

Abstract Distributed Control Systems are powerful assets in the new and modernized world of industrial automation. Various technologies have emerged in this field in order to make it simpler, more feasible and efficient. In this report, four such technologies, namely NodeRED (IBM; Codesys (IEC 61131); 4DIAC (IEC 61499) and DOME (IFAK e.V), have been discussed and compared based on literature review and in addition to that, laboratory work, that has been conducted based on Raspberry Pi, have been noted.

6

Contents List of Figures

1. Introduction

8

9

2. NodeRED 2.1 Introduction

10

2.2 User Interface and 'Nodes'

11

2.3 Passing Data Between Nodes

12

2.4 Advantages of NodeRED In Various Sectors

14

3. IEC 61131-3 3.1 Introduction

15

3.2 Motive

15

3.3 Technology Overview

16

3.4 Common Elements

16

3.5 Programming Languages

17

3.6 Advantages

18

3.7 Factors

18

4. CoDeSys 4.1 Introduction

19

4.2 Codesys Structure

19

4.3 Codesys- The Programming Environment

20

4.4 Codesys Control- The Runtime

21

4.5 Advantages Toolkit

21

7

5. IEC 61499 5.1 Introduction

22

5.2 Differences between IEC 61131 and IEC 61499

22

5.3

23

Architecture

6. 4DIAC 6.1 Introduction

26

6.2 4DIAC Users

26

6.3 Contents of 4DIAC

27

6.4 4DIAC-IDE

27

6.5 4DIAC-RTE (FORTE)

30

6.6

4DIAC Funtion Block Library

31

6.7

4DIAC Toolchain

31

7. DOME 7.1 Introduction

32

7.2 DOME Components and User Interface

32

7.3 Application Model

33

7.4

35

Compiling Process in DOME

8. Laboratory Implementations 8.1 Raspberry-Pi-2

36

8.2 NodeRED

37

8.3 CoDeSys

38

8.4 4DIAC

40

8.5 DOME

41

9. Summary

43

10. References

45

8

List of Figures 1. The Basic Interface of NodeRED

11

2. The Selection of Nodes Available

11

3.

Inserting 'Inject' Node

12

Inserting 'Debug' Node

12

4.

5. 'Inject' and 'Debug Node Connected

13

6. Configuring the 'Inject' Node

13

7. Output shown in Debug Node

13

8. IEC 61131-3 Programming Languages

18

9. 'CoDeSys'- The Programming Environment

21

10. A Basic Function Block

24

11. A Composite Function Block

25

12. Service Interface Function Block Type

25

13. An Application Distribution

26

14. 4DIAC-IDE Basic Information

28

15. 4DIAC-IDE System Configuration Editor

29

16. 4DIAC-IDE Deployment Perspective

29

17. 4DIAC-IDE Interface Editing

30

18. 4DIAC-IDE Resource Editor

30

19. 4DIAC-FORTE

32

20. CFB,BFB. SIFB

32

21. 4DIAC Process

34

22. DOME IDE

34

23. DOME Reperio

35

24. Application Model of DOME

36

25. Compiling Process of DOME

37

26. Raspberry Pi-2 Kit

38

27. NodeRED Laboratory Implementation

40

28. CodeSys Laboratory Implementation

42

29. 4DIAC

43

Laboratory Implementation

30. DOME Laboratory Implementation

44

9

1. Introduction

The technical definition of Distributed Control System (DCS) is"A type of automated control system that is distributed throughout a machine to provide instructions to different parts of the machine"[1]. In simpler terms, in DCS, instead of having a centrally located device that is controlling the entire machine, each part of the machine is being assigned its own controller(one or more), that is controlling its operation. The entire system of controllers is connected by networks for communication and monitoring. DCS is a very broad term used in a variety of industries for monitoring and the control of distributed equipment. The most common utilization of DCS is manufacturing equipment. A DCS utilizes input and output protocol to control the distributed equipments. The elements of a DCS can be directly connected to a physical equipment (controller) or to Human Machine Interface (HMI). Having the capacity for processing a large number of I/O ports and networking capabilities that are useful for business management, the importance of DCS systems is bound to increase, specially due to the global competitive dynamics in food and beverage, speciality metals, pulp and paper, pharmaceutical and fire chemical processing. There are various types of DCS available, i.e Conventional DCS (a 'process only' control system), PLC-based DCS (network of PLC used to perform the task of a conventional DCS and programmable functionality when required), Hybrid DCS (for both process and sequential control) and Open DCS System (Field Bus Control) [2]. The major advantages of DCS include high reliability, improved response time, it improves operator interface to plant, improved accessibility of plant data to engineering and management personnel and historical storage and retrieval system. Various new technologies have come up in the field of DCS and four such technologies are discussed in the next sections. At first, an introduction and working of the four technologies: NodeRED, CoDeSys, 4DIAC and DOME are being discussed and then some results, which were obtained while using the technologies in the laboratory, are given.

10

2. NodeRed

2.1 Introduction Internet of Things is defined as a network of physical objects or 'things' embedded with electronics, software, sensors etc. For the various applications of Internet of things, pulling together different hardware devices, APIs and online services in new ways are required. A lot of time is wasted in writing the code to the different systems, such as accessing a serial port. Therefore, tools are required to make it easier for developers at all levels to bring together the different streams of events, both physical and digital. "Node-RED is a visual tool for wiring the Internet of Things" [8], but can also be used for other types of applications to quickly assemble flows of services. It is developed by IBM emerging technology and the open source network. The basic idea behind the development of Node-RED was to build a toolbox of reusable codes that people could use to wire together software and hardware systems, that will develop into useful systems[5]. It is an event processing engine, built on Node.js that makes the job of software and hardware hackers easier. It does not take away the requirement of coding altogether, but reduces it to quite an extent. It allows the developers to visually construct flows by connecting simple 'nodes'. The 'nodes' represent reusable pieces of code and logic and make the job of developing an application way simpler. Node-RED is a open source project and the community around Node-RED is constantly evolving and more and more number of Node-RED nodes are being developed. The fact that it can run on low- cost hardware or in the cloud certainly works in the favour of Node-RED.

11

2.2 User Interface and 'Nodes'

Figure 1: The basic user interface of Node-RED [6]

Node-RED user interface consists of three panels: I. II. III.

Node Panel Sheets Panel Info and debug panel

Various selection of nodes are available for the user to choose and use for a specific task: a. b. c. d. e.

Transform: JS Functions, Moustache Templates Network: HTTP, TCP, UDP, MQTT Social: Twitter, Twilio, Email, IRC, XMPP Hardware: Raspberry Pi, BeagleBone Black Storage: Filesystem, MongoDB,MySQL,PostgreSQL

Figure 2: The selection of nodes available [5]

12

The user can select a node and view the information about the function of the node and how it can be used, in the information tab. It is possible to drag and drop the nodes onto the sheet which, in figure 1 is labelled as 2. The nodes can be configured from the configuration settings of the node, which opens when the nodes are double clicked in the sheet. The nodes can be connected by clicking the connector and dragging it to the connector of another node.

2.3 Passing Data Between Nodes and An Example Flow JSON objects are used to pass data between nodes in Node-RED. This object is known as 'msg' in NodeRED, which maintains its state throughout the entire flow. The data is placed in the property 'payload' of most of the nodes. One important thing that the user should keep in mind is that the nodes overwrite the previous values in the 'msg' object. Thus, in order to save the value that the user needs, he/she should save it to another property of the 'msg' object. The nodes may also accept 'parameters' via the properties of the 'msg' object, e.g any valid URL can be set as the value to 'msg.url'. An example of a simple flow is pictorially shown below to make the basic ideas discussed so far, a bit clearer.

Step 1:

Figure 3: Inserting 'Inject' Node [6]

Step 2:

Figure 4: Inserting 'Debug' Node [6]

13

Step 3:

Figure 5:'Inject' and 'Debug' Node Connected [6]

Step 4:

Figure 6: Configuring the 'inject' node [6]

Step 5:

Figure 7: 'Output' shown in Debug tab [6]

14

2.4 Advantages of Node-Red in various sectors Node-RED provides a variety of advantages for people in different professional sectors and these are listed below [7]: a. New Developers and education: It provides a short learning curve, ease of use and a low barrier to entry for new developers and for educational purposes b. App Developers: The main benefit of professional app developers from Node-Red is its rapid prototyping, Also, it is easy to integrate with existing tools and applications and it is easy to extend with richer/bespoke functionality. c. Community Developers: The Node-RED is open source and anyone can share his/her flow with the entire community and help in enhancing the flow library and other Node-red features. Thus, being flexible is a major advantage for Node-RED d. Hardware Hackers: The Node-RED can run on hardware platforms like Raspberry Pi, Beaglebone and few other low power devices. It works well with Arduino as well and it is pretty easy to add new devices. Node-RED can make it very easy to collect data from these devices and process it. This provides a major advantage for hardware hackers.

15

3. IEC 61131-3 3.1 Introduction IEC 61131 is the first vendor independent standardized programming language for industrial automation . Due to the worldwide support, it is independent of any single company. It is established by the Electrotechnical Commission (IEC), which is a worldwide standard organization founded in 1906 [18]. IEC 61131 standard is already popular in Europe and is rapidly gaining recognition all over the world. IEC 61131-3 is the third part of the IEC 61131 family. This consists of:       

Part 1: General Overview Part 2: Hardware Part 3: Programming Languages Part 4: User Guidelines Part 5: Communication Part 6: Fuzzy Logic Part 7: Application Guidelines

3.2 Motive The main reason behind the introduction of the IEC 61131 is due to the increasing software complexity of control and automation requirements. As a vendor independent standard, IEC 61131 can have a major impact on the time required to create, labour cost and the maintainability of control software [17]. The major advantage of applying a standardized programming language is the positive impact that it has on the software life-cycle that includes requirements analysis, design, construction, testing (validation), installation, operation and maintenance. The major impact lies in the maintenance part, since a software maintenance, including upgrades, is generally 2-4 times the labour of the initial programming.

16

3.3 Technology Overview IEC 61131-3 standard can be split into two parts: 1. Common Elements 2. Programming Languages

3.4

Common Elements



Data Typing and variables: Data types defines the type of parameters that the user is going to use and it is used to avoid any types of unnecessary mistakes, like dividing a date by an integer etc. The main purpose of data typing is avoid any kinds of mistakes, early on in the development cycle. Most common Datatypes are Boolean, Integer, Real, Byte, Word, Date, Time_of_Day and String. It is also possible for the user to define his own datatypes, known as the derived datatypes [17]. The variables can be local as well as global. The local variables are normally limited to the organization unit in which they are declared, so that their names can be reused in other parts without any conflict. This takes care of another source of errors. The global variables should be defined as VAR_GLOBAL and the parameters can be assigned an initial value at start-up.



3.5

Program Organization Units (POUs): In IEC 61131-3, the POUs consist of programs, function blocks and functions. Function blocks are required to represent a level of more detailed control. In IEC 61131-3 includes defined standard function instances, e.g. ADD, ABS, SQRT, SIN and COS. The user can create a custom function as well and can call that customized function block as many number of times as they want [17].

Programming Languages

Part 3 of the IEC 61131 deals with five standard programming languages, of which two are graphical, two textual and the other one is a sequential one [19]. The standard languages are: 

Ladder Diagram (LD): The most widely used graphical controller programming language. The main advantage of LD is that even a non-programmer with an electrical background can follow the program for troubleshooting purposes. But, with growing complexity of PLC functionalities, LD has failed to meet the advances. Another

17

challenge is that, when the size of program grows, ladder becomes very difficult to flow. 

Function Block Diagram (FBD): FBD is the second most widely used programming language after Ladder Diagram. In this method, the various have to be wired together and thus it is very easy to follow functional block diagrams, since one just have to follow the path. However, FBDs are not ideal for large programs using special I/O and functions. Upfront preparation is also very important before starting with the program, since it is very difficult to edit a flawed program [19].



Instruction List(IL): Instruction Lists contain many lines of codes, where each line is represented by exactly one operation. Being a low-level language, the entry time and the execution time of IL is very fast, compared to the graphical languages. But a major disadvantage of Instruction Lists are that they are less visual and it is really difficult to find out the errors. Also, the advantages of speed and compactness become less relevant, given the processor speed and memory available in modern PLCs [19].



Structured Text (ST): Structured Text is a high level programming language like C,PASCAL etc. It is undoubtedly the greatest among the languages in case of adoption and best tackles the growing complexity of PLC programming. Being textbased, non-graphical in nature, Structured Text is definitely much faster than the graphical ones(LD,FBD). Programmers often encapsulate an ST program inside an instructor, which is then embedded in a Ladder program [19].



Sequential Function Chart(SFC): Sequential Function Chart resembles a flowchart like structure, where an initial 'action box' is followed by a series of transition and action steps. The necessary conditions of a particular step should be made, before the program moves to the next step. The main problems with SFC is not suitable of every applications and add unnecessary complications. Another major disadvantage is that, unlike others, it is not possible to convert SFC into other languages [19]. In the next page, figure languages of IEC 61131.

shows the part of same program written in different

Figure 8: All four showing same program part [19]

18

3.6 Advantages The major advantages that can be seen in IEC 61131-3 can be listed as: a. The standard provides multiple language support within a control program. The control program developer can select the language that is best suited to a specific task. Thus, it greatly increases productivity. Moreover, the standardized programming interface is completely independent of the hardware platform, and that leads the user to greatly reduce the maintenance of the program and training across company-wide automation applications. b. The IEC-61131-3 standard, combined with new powerful Free-scale chip architectures enables an entire controller to be delivered in an embedded device. Control programs can run distributed and independently, rather than concentrated in large controllers [18]. c. Being hardware-independent, the ability to transport automation solutions to other platforms is vastly improved over PLC applications offering users and System Integrators major reusability. It increases the efficiency and the speed of implementing new automation solutions by using readily available control components developed on other projects and outside developers.

3.7

Factors:

There are certain factors that should be considered before choosing a certain programming language[19]. Considering the high level benefits of each language, proper decision should be taken before implementing a certain language. Few of the factors are: I. II.

Ease of maintenance of the end user Universal Acceptance of the language

III.

Speed of execution by the PLC

IV.

Ease of changing the codes

V. VI. VII.

Ease of implementing complex mathematical operations Applications mainly using digital I/O and basic processing Applications with repeating or concurrent processes

19

4. CODESYS 4.1 Introduction The standardization of control logic programming has the advantages of interoperability within products from different vendors and in the process saves a lot of time for the engineers. As seen in the previous chapter, IEC 61131-3 has greater efficiency through reduced development and training costs, enabling flexibility and providing the user the option to select the device based on their needs and not depending on the supplier. Based on IEC 61131-3, Codesys, a comprehensive open software tool for industrial automation, is designed which allows to create controller applications without hardware and programming as a common platform [9]. It is one of the most powerful IEC 61131-3 programming tool for controllers, supporting all five PLC programming languages (Ladder Diagram, Structured Text, Instruction List, Function Block Diagram and Sequential Function Chart). Moreover, the combination of advanced programming languages, such as C or Pascal makes the handling and operational functions of PLC programming systems much easier [10].

4. 2 Codesys Structure Codesys consists of two parts: a. The programming system 'CoDeSys Development System', which is the common IEC 61131-3 programming tool b. The runtime system 'CoDeSys Control System', which is used to convert any intelligent automation device into an IEC 61131-3 controller, programmable with Codesys. As can be seen with the structure, Codesys is designed such that it can easily adapt from one vendor device to another and this helps the control engineer to incorporate multiple vendor devices into one common programming environment or move from the programming environment of one CoDeSys controller to another, without retaining. Also, since the file formats are common, programs can be automatically imported [9].

20

4.3 CoDeSys- The Programming Environment The 'CoDeSys Development System' programming environment provides the user with a simple interface which is show in the image below. In the image, the following labels are used: A. Window for POUs, Devices, Data Types, Visualizations and Resources B. Declaration and Instruction Window C. Tool Library D. Message Window

Figure 9: 'CoDeSys Programming Environment [10]

Numerous security features is provided for the protection of source codes and for the safeguarding the operation of the controller is provided. The projects can be configured through the wizard and input assistance for inputs and configuration data are provided. The programming is fairly simple and user friendly and the controller performance is optimized by the integrated compilers for many different CPU platforms. The most important features are the adaptation of the user interface for the different programmable devices from different manufacturers and the transparent internal structures of the development tool and the available components [11].

21

4.4 'CoDeSys Control'- The Runtime Toolkit 'The CODESYS Control Runtime Toolkit is a comprehensive software development kit to help you implement the PLC Runtime System CODESYS Control on your hardware. The kit is responsible for the execution of the programmed IEC 61131-3 code and the debugging of the applicaions developed with CODESYS'. [11]. For the users, all the devices in the CODESYS directory is provided with the runtime system, and they do not require the runtime toolkit separately, but the manufacturers require it to fit the most different platforms and requirements. Thus, a customized industrial controller with necessary functionalities can be developed, which will then be programmable with the 'CoDeSys Development System'. The base runtime system depending on the vendor 'target' system is provided as object or source code, along with tool-guided configuration of the required base components and addon components. Various training and adaption workshops are also provided by the Codesys experienced engineers to the manufacturers and the manufacturers can also benefit from the comprehensive documentation on the runtime system integration and adaption to the target system [11].

4.5 Advantages Codesys provides the following competitive advantages apart from the various other advantages that has been discussed in previous sections [10]: a. The runtime system, programming system and the code generation are perfectly coordinated and uses time very efficiently and it is able to complete a test adaption (including online functionality) on any standard processor hardware within two days. b. Codesys requires a very low number of resources, ensuring fast and efficient work. Moreover, the functions like Autodeclare, Autoformat and a context-sensitive input assistance greatly simplify the use of Codesys. c. The optimal use of control system is ensured by native code generators, which is there for all common processors. Intelligent algorithms are provided in Codesys, such as Incremental compile. These make the compilation of huge projects in a very short time span and increase efficiency. d. Codesys supports almost all data-types specified in IEC 61131-3 and other functionalities like offline simulations and powerful online functions, e.g breakpoints, single stepping, power flow, sampling trace and online change ensures the high performance of Codesys.

22

5. IEC 61499 5.1 Introduction The IEC 61499 standard, which is developed to provide a common reference architecture for the use of software objects, called FBs (Function Blocks), was published in 2005, though the development was started in 1992 [22]. The International Electrotechnical Committee (IEC) developed the IEC 61499 to make the automation system interoperable, reconfigurable and portable. This is because, the need for decentralized control is gaining more and more importance each day, due to reasons like flexibility and reliability, and PLCs are not good enough for implementing distributed control. The IEC 61499 is still new in the industry, and it has a huge future scope. The factors of modularity and reusability are of prime importance in the field of PLC programming, and the IEC 61499 standard provides a heavy advantage in these fronts. Being modular in structure, the IEC 61499 ensures more efficiency and greater productivity for a company. Again, since the IEC 61499 use function blocks, they are reusable and the small or medium companies can build their customized function blocks, save them in their components library and re-use them in future. This ensures huge leap in efficiency and productivity as well [21]. The major problem that has now drawn the attention of the researchers is the migration from the IEC 61131 standard to the IEC 61499 standard. This is because, a migration path from one standard to another is much more feasible and can save lots of efforts, rather than adopting a new standard and this is much more attractive to the industry [21]. Various researches are carried on by various research institutes, companies and universities to make this standard better with passing days. Few examples include [21],[22] and [23].

5.2

Difference between IEC 61311 and IEC 61499 a. In IEC 61499, the use of high-level languages like C, Java, Delphi etc are possible for the creation of control algorithms, besides the IEC 61131 standard programming languages- Ladder Diagram (LD), Structured Text (ST), Sequential Function Chart (SFC), Function Block Diagram (FBD) and Instruction List (IL). b. It is possible to describe an IEC 61131 configuration by using the defined software model of IEC 61499. The differences between both are the new system layer, the modified function block interface and the recently introduced execution control chart (ECC) [24].

23

c. The execution control in IEC 61499 is changed from cyclic to an event-driven mechanism and this helps in minimizing the computing time and reduces the communication bandwidth to a necessary minimum. d. Furthermore, the advantages of reusability and modularity are already discussed.

5.3

Architecture

In this section, the basic working concepts and architecture of IEC 61499 is discussed in brief. "IEC 614991 defines the function block type as the basic unit for encapsulating and reusing Intellectual Property (IP="knowhow"). In object-oriented terms, this is a class defining the behaviour of (possibly) multiple instances. As shown in Figure 1, it includes event inputs and outputs as well as the more traditional data inputs and outputs, to provide for synchronization between data transfer and program execution in distributed systems." [20]. There are three types of function blocks : i. Basic ii. Composite iii. Service Interface. i.

Basic: The fundamental element of IEC 61499 is the basic function block. It should consist of a Execution Control Chart (ECC), which is defined as a state machine with conditional branches and corresponding algorithms executed0 in states [21]. The basic FB type can be compared to 'atom' out of which 'molecules' can be constructed. The software developers can encapsulate IP in the form of algorithms in any of the IEC 61131-3 programming languages or other high level languages, like C, Java etc.

Figure 10: A Basic Function Block [20]

ii.

Composite: A composite function block is developed from a basic function block, by specifying the event and data interfaces of the composite type, and filling it with a diagram showing how the internal function blocks are connected. The execution of algorithms in the component function blocks is controlled by the flow of events from one component to another [20].

24

Figure 11: A composite FB Type[20]

iii.

Service Interface: The Service Interface Function Blocks (SIFBs) are known as the 'black box' and are destined for wrapping the hardware dependencies of the applications. The SIFB is defined by defined by a number of event sequence specifications which describes the interaction between the hardware and the function blocks [21]. Some of the services include graphical user interface elements (slider, knob etc), communication services, interfaces to hardware (temperature sensor, motor speed controller, control valve, room light intensity controller).

Figure 12: Service Interface Function Block[20]

"A network of basic and composite FBs forms an application. System configuration combines the application logic with device topology, abstract definition of communication networks and exact mapping of function blocks to devices"[21]. This can be compared to designing a circuit board with

25 integrated

circuits.

Figure 13: An Application Distribution[21]

26

6. 4DIAC

6.1 Introduction "The general aim of the 4DIAC initiative is to provide an open, IEC 61499 standard compliant framework, that gives the opportunity to establish an automation and control environment as well as to provide a reference implementation (i.e. provide a reference for an advanced execution model for IEC 61499) based on targets portability, configurability and interoperability" [12]. This description of 4DIAC gives an overall idea about the initiative, which finds its use in development, industrial application and research of IEC 61499. It is leveraging the industrial use of IEC 61499 with more research and development coming up at a steady pace. It is founded in July 2007 by a joint venture of PROFACTOR GmbH and the Automation and Control Institution (ACIN) of the Vienna University of Technology. The initial work for this project was completed by two Austrian funded research projects- µCrons and εCEDAC, which were funded by the FIT-IT: Embedded Systems program, an initiative of the Austrian federal ministry of transport, innovation and technology (bm:vit) [13].

6.2 4DIAC Users a. Industrial Users i) nxtControl: FORTE with own tool ii) Bachmann: evaluation iii) Voigt+Wipp Engineers: evaluation iv) ABB: Use in internal research projects b. Universities and research institutes in Austria, Germany, Spain, Italy, New Zealand, Canada etc c. Application Domains: Building Automation, process industries, laboratory automation, smart grids, machine, control, sequence co-ordination etc.

27

6.3 Contents of 4DIAC

The 4DIAC initiative provides four major tools to the user to work with: a. b. c. d.

4DIAC-IDE : The development environment 4DIAC-RTE (FORTE) : Small real-time capable runtime environment 4DIAC-LIB : Function Block Library 4DIAC-SYS : Example projects

6.4 4DIAC-IDE Based on Eclipse Open Tool Framework, 4DIAC-IDE provides an engineering environment for modelling distributed control applications with IEC 61499, allowing the modelling of control hardware and its interconnections through networks. Being based on Eclipse framework, easy integration of other plug-ins to the 4DIAC-IDE is possible, which provides new or extended functionality. In IEC 61499, the systems follow application centric design, that is the application of the overall system is created at first. For creating the application, the desired function blocks (FB) are interconnected in terms of a function block network (FBN). When the hardware structure of the project is known, the application can be added to a project's system configuration and then distributed onto the available devices [14].

Figure 14: 4DIAC-IDE Basic Info [12]

28

The 4DIAC-IDE presents itself with the following features: a. System Editor: Manage IEC 61499 projects, consisting of applications; providing

support for sub-applications; specification and parameterization of automation by modelling of IEC 61499 devices.

Figure 15:

4DIAC-IDE System Configuration Editor [12]

b. Deployment: Support for different profiles; selective download of applications to their corresponding resources.

Figure 16: 4DIAC-IDE Deployment perspective [12]

29

c. Type Editors: Creation of Basic FBs (BFB), Composite FBs (CFB), Service Interface FBs (SIFB), and Adapters.

Figure 17: 4DIAC-IDE Interface Editing [12]

d. Testing, Monitoring and Debugging: Testing FBs on target device both manually and using automated unit tests; watch and force the values of interface elements as well as trigger events.

Figure18:

4DIAC-IDE Resource Editor [12]

30

6.5 4DIAC-RTE (FORTE) "The 4DIAC runtime environment (4DIAC-RTE, FORTE) is a small portable implementation of an IEC 61499 runtime environment targeting small embedded control devices (16/32 Bit), implemented in C++. It supports online-reconfiguration of its applications and the real-time capable execution of all function block types provided by the IEC 61499 standard" [14]. The core functionality of 4DIAC-RTE includes the execution of IEC 61499 elements and the hardware abstraction. It supports all IEC 61131-3 elementary data types, structures and arrays and provides a scalable architecture. The applications may consist of all IEC 61499 elements, i.e. the basic FBs (BFBs), composite FBs (CFBs), service interface function blocks (SIFBs), adapters and sub-applications. For connections between function blocks FORTE uses automatic and save castings (e.g., INT -> REAL). FORTE provides a flexible communication infrastructure via communication layers [14]. The supported communication layers are FBDK ASN:1 encoding, ethernet (TCP/UDP), modbus TCP client, OPC DA client, MQTT, RS232, Eclipse SCADA, Ethernet Powerlink. The supported operating systems are Windows, Linux, NET +OS 7, eCos. The supported boards are Digi Connect ME (ARM7), Lego Mindstorms nxt (ARM7), KIPR's CBC v2 robot controller, Raspberry Pi, BeagleBone Black. [14]

Figure 19: 4DIAC FORTE

[14]

31

6.6 4DIAC Function Block Library As discussed before, The IEC 61499 provides three types of function blocks: Basic Function Blocks (BFBs), Composite Function Blocks (CFBs) and Service Interface Function Blocks (SIFBs).

Figure 20: (a) CFB

(b) BFB

(c) SIFB

[14]

There are two grouping elements present: adapters and subapplications. The adapters group the interface elements within an adapter group, to reduce the number of connections, whereas the subapplications group the FBs, leading to FBNs. 4DIAC function library functions contain BFBs, CFBs, SIFBs and can be grouped as events, io, net, rtevents, reconfiguration, utils, FBRT, IEC 61131-3, OSCAT, powerlink, be-m1, CBC, Devices, Resources and Segments [14].

6.7 4DIAC Toolchain

Figure 21: 4DIAC Process [14]

32

7. DOME 7.1 Introduction DOME is the abbreviation for Distributed Object Model Environment. It is developed by the 'Institut für Automation und Kommunikation' e.V (ifak). It is a new software environment that can be used to create distributed applications in automation area in an easy and convenient way. It is designed as a middleware, offering a range of capabilities for an automation specific object-oriented application [15]. The motivation behind the development of DOME lies in few important issues that requires attention. Firstly, the Function Block (FB) scheduler, which is responsible for the activation of FBs in an application, is not defined in any of the previously mentioned (IEC 61131 and IEC 61499) standards. This should be standardized, since they are now vendor or system specific. Another major issue is the introduction of an explicit method ,i.e. the possibility of command driven architecture which can be very useful. This is because, an implicit method invocation by combining an event and several data inputs is very difficult, and that leads to a differentiation in event and data connections,, where only a data exchange is possible. Lastly, the software quality management, including the development and maintainance of the software is a major issue and standards that describe the software life cycle and the product quality should be considered [16].

7.2 DOME Components and User Interfaces The DOME consists of three main components: a. DOME Integrated Development Environment (IDE) b. Reperio c. DOME Runtime

33

Figure 22: DOME IDE [16]

Figure 23 : DOME Reperio [16]

34

7.3 Application Model

Figure 24: Application Model of DOME [15]

A DOME application consists of one or more network nodes, that are represented by 'DOME Managers'. These managers are responsible for administrating all the running processes on a specific computer or network node. A 'Process' in turn controls the 'groups',' classes' and 'ports' in DOME. A process is a stand-alone application can be realized in two ways- as a C++ application that contains a class that derives from the class dome: Object Manager Instance; and by using the application dome-instance.exe with a DOME module and a config file to specify 'links' and 'object instances'. The 'Groups' in DOME are execution contexts that are logically separated. They consists of child objects like 'local links' and 'class objects' and they administrate the same. Each group has a separate execution context. The user-defined components of a DOME process are known as 'Class Objects'. They provide I/O ports and methods that are user-defined. 'Links' establish the communication interfaces between the 'class objects' and the I/O ports of the object are also connected by them. These 'Class objects' can also be called as the brain of the DOME, since all main logic of a DOME application is embedded in them and their communication within themselves. The ports are used to communicate with other class objects.

35

7.4 Compiling Process in DOME

Figure 25: Compiling Process of DOME [15]

36

8. Laboratory Implementations In the laboratory, all the technologies were implemented and tested based on Raspberry Pi-2 device. A brief description of the Raspberry Pi-2 device is provided below:

8.1 Raspberry Pi 2:

Figure 26: A Raspberry-Pi-2 Kit [4]

The Raspberry-Pi-2 is a single board computer, developed in UK, by the Raspberry Pi foundation. This is a credit card sized computer, which can perform multiple functions, that a normal PC does, such as playing videos, running software, processing word and spreadsheets. The raspberry-Pi-2 contains 4 USB ports, 40 GPIO pins, HDMI port, Ethernet port, 3.5 mm audio jack, Camera interface (CSI), Display interface (DSI), Micro SD card slot and VideoCore IV 3D graphics core. The developments from the previous Raspberry-Pi-1 model is the inclusion of a 1 GB RAM and a 900 MHz quad-core ARM Cortex-A7 CPU. All the four technologies that are discussed in this report, has been tested and the functions were implemented based on this device and the details of the those have followed in the next sections. The Raspberry Pi-2 was connected using the USB port and a data connection was given by the Ethernet port.

37

8.2 NodeRED Transmission control protocol was used to connect two Raspberry-Pi-2 : 'Aranya Pi' and 'Aniket' by using NODERED. An inject node was dragged into the palette then a TCP output node was connected to it to send the request from Aranya Pi to Aniket by using the IP address and port number (Figure 27).

Figure: 27

Then in 'Aniket' a TCP input node was dragged to the palette and the same port number was given to it which was given in the TCP output node of the 'Aranya Pi' (Figure 28)

Figure: 28

38

Then a function node has been added to check the message payload to buzz the Raspberry Pi2. When the message payload is start then the buzzer will be on and when it is stop then the buzzer will stop respectively. The message is first introduced in the inject node in the Raspberry-1. The function for the function node to perform the task. if(msg.payload=='start') msg.payload=1; else if (msg.payload=='stop') msg.payload=0; return msg; Then the Raspberry Pi Node has been added to buzz it. if the value is 1 then it will buzz and when the value is 0 it will be stopped (Figure 29)

Figure: 29

8.3 Codesys The main object of the programme is to maintain a connectivity to Raspberry-Pi and buzz it by giving input from CoDeSys. First, the Raspberry-Pi IP address has been provided in the CodeSys application through Network Variable List (NVL). Then a Program is created under the POU list of the created project (Figure 30). Then to implement the programme a Timer ON Function Block is dragged into the editor.

39

Figure: 30

Then the input port and output port are assigned to the TON FB. The Raspberry Pi ports are defined as input and output variables under the SPI Master. The input ports are PiFace.byIn.0 and a time variable with value TIME#1000ms. The output port is the global variable STATUS_1 and the buzzer which is defined as PiFace.byOut.1.

Figure: 31

The PiFacebyIn.0 variable is assigned to IN input which accepts BOOLEAN input and the time is assigned to PT input which defines the delay after how much time Q will be set to true after IN was made TRUE. Q the BOOLEAN output is assigned to PiFace.byOutput.1 and also to STATUS_1 variable. ET is the elapsed time (Figure 32).

40

Figure: 32

8.4 4DIAC A SR Flip-flop application has been used with 4DIAC as a switching logic, which reset the value of the output in every 500 milliseconds. A new project under new system has been created, along with a new application, named 'FlipFlopApplication'.. The Ethernet is used for the communication segment. Then the MGR_ID is configured with the IP address of Raspberry Pi with a port number. Then the created Application is opened to implement the Function Blocks to create the SR Flip-flop. Application will be created with the group of Function Blocks. E_CYCLE is added to activate the Flip-flop every 500 ms. Then E_CYCLE and E_RS are added to toggle the output. The data needs to have inputs as well, either a constant value of its type or a connector input from a data output variable of another Function Block. For constant values type the desired value next to the data input variable. Then the output of E_CYCLE is given to E_SWITCH. And output of E_SWITCH i.e. EQ0 and EQ1 are given to the inputs of E_RS i.e. R and S. Then the output of the E_SR is given to the QX Function Block. QX_1. The "PARAMS" data input in the QX FB define which pin should be used on the RaspberryPi. Then the application is mapped to the device which was created earlier. Within the System Manager by double clicking on the desired Resource. Within the editor, the Application can be seen mapped to this Resource. The COLD and the WARM start events of the E_RESTART Function Block should be connected to the Application’s first event, which is E_CYCLE.START event. The COLD event is sent on system startup whereas the WARM starts from last known state and values. After this the system has been deployed and run respectively. In the second part two devices are used as sender and receiver respectively to establish a connection between two Raspberry Pis. So the SUBSCRIBE and PUBLISH FB is used to implement the application. The SUBSCRIBE FB is implemented in

41

Sender device and PUBLISH FB in receiver device. The IP and Port number of the sender Raspberry Pi is provided to both SUBSCRIBE and PUBLISH FB (Figure 33). Then the application is carried according to the first application.

Figure 33: 4DIAC Lab Implementation

8.5 DOME For using DOME, in the software 'Dialysis', a new project 'Raspberry 2' was created. The main motive was to control the buzzer or LED in the Raspberry Pi from the local PC. Two processes are created. In 'Process', the IP of the local PC is configured, while in the other 'Process0' the IP of the Raspberry Pi is configured, along with a function block configuring the output as a PLC Logic Interpretation, the function of which is shown in figure 34.

Figure 34: PLC Logic Interpretation

The proper connections were made and the intended result was obtained and the entire setup is shown in figure 35.

42

Figure 35: DOME Setup

After achieving this, two Raspberry-Pis were connected and data was sent between them and they controlled each other. The proper connections were made, which are shown in figure 36 and the motive was achieved

Figure 36: Connecting two Raspberry Pis

43

9. Summary

The non technical project dealt with four different technologies (NodeRED, Codesys, 4DIAC and DOME) that have been developed recently. The main goal was to give a brief idea on all four technologies, based on literature review and also provide the results of them when implemented in the laboratory. The main advantage with all these technologies, as noticed, were the ease with which they could be understood and implemented. This is because os the simple GUI and most of them using the drag and drop concept. However, there when we were trying to buzz our RaspberryPi-2 toolkits using NodeRED, we could see a great delay when we were connecting two kits through TCP. Also, Codesys had the same problem of being slow. These are the areas more development and research are required in the near future. DOME is still in its development process and there were left with a challenge, since the 'Help' document in DOME is not quite detailed and properly organized. However, the main goals were achieved and I have been able to provide, in this report, a basic idea about all the technologies and their laboratory implementations.

44

10. References [1] Distributed Control System (DCS), BusinessDictionary.com; [accessed 17 Nov. 2015]; http://www.businessdictionary.com/definition/distributed-control-system-DCS.html, [2] Austin Scott, 03. June 2014, 'What is a Disributed Control System (DCS)', Cimation;{accessed 17 Nov 2015]; http://blog.cimation.com/blog/bid/198186/What-is-a-Distributed-Control-System-DCS [3] Niklas Heidloff, 02. Feb 2015 , 'What is Node-RED? How can it be used in internet of Things?'; [accessed 9 Nov 2015]; http://heidloff.net/nh/home.nsf/article.xsp?id=21.01.2015081841NHEAL8.htm [4} Stacey Higginbetham, 27. Sep 2013, 'Meet Node-RED, An IBM Project That Fulfils The Internet Of Things Missing Link'; Gigaom;[accessed 9 Nov 2015]; https://gigaom.com/2013/09/27/meet-node-redan-ibm-project-that-fulfills-the-internet-of-things-missing-link [5[ Nick Health, 13. March 2014, 'How IBM NodeRED is hacking together the Internet of Things', TechRepublic; [accessed 9 Nov 2015]; http://www.techrepublic.com/article/node-red/ [6] NodeRED, IBM: [accessed 9 Nov 2015]; https://www304.ibm.com/connections/blogs/et/entry/node-red [7] Dave Conway-Jones, 17 March 2015, 'NodeRED', EclipseCon2014;[accessed 9 Nov 2015]; https://www.eclipsecon.org/na2014/session/wiring-internet-things-node-red [8] NodeRED, nodered.org; [accessed 9 Nov 2015]; www.nodered.org [9] Richard C.Harwell, Kerry L.Sparks, 01. March 2011, 'IEC 61131-3, Codesys Standardized Control Logic Programming'; [accessed 11 Nov 2015]; http://www.plantengineering.com/single-article/iec61131-3-codesys-standardize-control-logic-programming/781f05f4f0.html [10] Smart Software Solutions, 'User Manual for PLC Programming With Codesys 2.3'; http://www.wago.com/wagoweb/documentation/759/eng_manu/333/m07590333_00000000_1en.pdf [11] CODESYS, Codesys; [accessed 11 Nov 2015]; https://www.codesys.com/products/codesysruntime/runtime-toolkit.html [12] 4DIAC-Consortium, October 2007, '4DIAC- Framework for Distributed Industrial Automation and Control'; www.fordiac.org [13] Alois Zoitl, 6 June 2013, '4DIAC- A Framework for Distributed Industrial Automation and Control', fortiss GmbH [14] 4DIAC, 'Framework for Industrial Automation and Control', Eclipse, https://www.eclipse.org/4diac/en_ide.php [15] Robert Schneckenhaus, 23 Jul. 2010, 'Debugging of distributed systems', Hochschule Magdeburg-Stendal [16] 'Distributed Object Model Environment Documentation', 31 Jan. 2008, IFAK e.V, [17] Real Time Automation, 'Control IEC 61131-3'; [accessed 14 Nov 2015], Copyright © 2015 [18] PLC-Open, 'PLC Open on IEC 61131-3'; [accessed 14 Nov 2015], http://www.plcopen.org/pages/tc_standards/iec61131-3/index.htm

45 [19] Ted Thayer, 30 Jan. 2009, 'Speaking in Tongues: Understanding the IEC 61131-3 Programming Languages'; http://www.controleng.com/single-article/speaking-in-tongues-understanding-the-iec61131-3-programming-languages/4123b0e66c3f2cb8bdd60d3cb20f944d.html [20] Christensen, Strasser, Valentini,Vyatkin, 'The IEC 61499 Function Block Standard: Overview Of the Second Edition', Automation Week 2012 [21] Dai, Vyatkin, 'A Case Study On Migration From IEC 61131 PLC To IEC 61499 Function Block', University of Auckland [22] 'IEC 61499', Wikipedia- The Free Encyclopaedia, https://en.wikipedia.org/wiki/IEC_61499 [23] International Electrotechnical Commission, 'IEC International Standard IEC 61131-3 Programmable Controllers, Part 3: Programming Languages', IEC,2003 [24] Gerber, Hanisch, Ebbinghaus, October 2007, 'From IEC 61131 to IEC 61499 For Distributed Systems: A Case Study', Martin-Luther Universität Halle-Wittemberg