Time Evaluation of Technologies for Distributed ...

Time Evaluation of Technologies for Distributed Control

Integrated 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

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, 15. Sep 2016

2

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

Acknowledgement I have taken efforts in this project. However, it would not have been possible without the kind support and help of many individuals and organizations. I would like to extend my sincere thanks to all of them. I am highly indebted to Dr-Ing Thomas Hadlich for his guidance and constant supervision as well as for providing necessary information regarding the project & also for his support in completing the project. I would like to express my gratitude towards my parents & members of ‘Institut Für Automatisierungstechnik’ of ‘Otto Von Guericke Universität Magdeburg’ and ‘Institut Für Automation und Kommunikaion’ e.V, Magdeburg for their kind co-operation and encouragement which has helped me in completion of this project. My thanks and appreciations also go to my colleagues Mr. Santosh Panda, Mr.Aniket Salvi and Mr. Mainak Majumder in helping me with some useful tips during the project phase and my girlfriend, Miss Chandralekha Chatterjee, for her immense support throughout.

3

Abstract

A non functional requirement is a requirement in systems and requirement engineering, that specifies the criteria that can be used to judge the overall operation of a system, rather than specific definite behaviours, and time behaviour is one of most important non-functional requirement. There are different technologies for implementing distributed controls based on Raspberry Pi platform. The timing behaviours of four different technologies, namely, NodeRED, CoDeSys, 4DIAC and DOME, are evaluated and compared with each other in this research project. The same control task has been implemented based on these four technologies and the timing behaviours are observed, compared and a conclusion is drawn.

4

Table of Contents

Table of Figures ....................................................................................................................................... 6 1. Introduction ....................................................................................................................................... 8 2. Introduction to the Technologies ....................................................................................................... 9 2.1 NodeRED ....................................................................................................................................... 9 2.2 CODESYS ..................................................................................................................................... 11 2.3 4DIAC .......................................................................................................................................... 17 2.4 DOME ........................................................................................................................................ 25 3.

Time Characteristics In a Network ................................................................................................ 29

4.

Test Setup ..................................................................................................................................... 31 4.1 Measurement Strategy ............................................................................................................... 36

5.

Control-task Implementation for Different Technologies ............................................................ 37 5.1 NodeRED ..................................................................................................................................... 37 5.2 Codesys ....................................................................................................................................... 38 5.3 4DIAC........................................................................................................................................... 40 5.4 DOME: ......................................................................................................................................... 42

6.

Results and Comparison ............................................................................................................... 44 6.1 NodeRED: .................................................................................................................................... 44 6.2 Codesys: ...................................................................................................................................... 48 6.3 4DIAC:.......................................................................................................................................... 51 6.4 Comparison and discussion: ....................................................................................................... 54

7.

Conclusion ..................................................................................................................................... 56

8.

References .................................................................................................................................... 57

5

Table of Figures 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44

6

The basic user interface of NODE-RED The selection of nodes available All four programming languages showing same program part Codesys Programming Environment A function block type A basic function block A composite FB type Service interface function block An application distribution in 4DIAC 4DIAC-IDE basic info 4DIAC-IDE system configuration 4DIAC-IDE deployment perspective 4DIAC-IDE interface editing 4DIAC-IDE resource editor 4DIAC-FORTE CFB, BFB, SIFB 4DIAC process DOME IDE DOME Reperio Application model of DOME Compiling process of DOME Terminal-terminal reaction time from a systems theory perspective Bridge delay and line delay Control task defining all components Integrated raspberry pi-2 setup Piface digital 2 board Functional block diagram of ADG 3300 Pin diagram of ADG 3300 3.3V to 5V level translation eye diagram 5V to 3.3V level translation eye diagram Hilscher NetAnalyzer C-500 RE Measurement points Using switch of one raspberry pi to control LED of another raspberry pi Nodered flow ‘SENDER’ end Nodered flow ‘RECEIVER’ end ‘Sender’ project in Codesys IDE ‘Receiver’ project in Codesys IDE Deployed application in 4DIAC ‘Sender’ end flow in 4DIAC ‘Receiver’ end flow in 4DIAC FATAL error in DOME NODERED- transition period input NODERED- transition period output NODERED- transmission time between point 1 and point 2

9 10 14 15 18 19 19 20 20 21 22 22 23 23 24 24 25 26 27 27 28 29 30 31 32 32 33 33 33 33 34 36 37 37 38 38 39 40 40 40 41 42 42 43

45 46 47 48 49 50 51 52 53 54 55 56

7

NODERED- transmission time between point 3 and point 4 NODERED- End to end transmission time CODESYS- transition period input CODESYS- transition period output CODESYS- transmission time between point 1 and point 2 CODESYS- transmission time between point 3 and point 4 CODESYS- End to end transmission time 4DIAC- transition period input 4DIAC- transition period output 4DIAC- transmission time between point 1 and point 2 4DIAC- transmission time between point 3 and point 4 4DIAC- End to end transmission time

43 44 45 45 46 46 47 48 48 49 49 50

1. Introduction Over the years, tremendous efforts have been undertaken by engineers worldwide to present us with the way the industrial processes appear today. From 1950s, when the implementation of control system consisted of wiring of various analog devices by hand, to distributed control systems (DCS), which is ‘A type of distributed control system that is distributed throughout the machine to provide instructions to different parts of the machine’ [1], the manufacturing processes have come a long way. Distributed control systems monitor, control and manage industrial processes are that disbursed but operated as a coupled system [2]. Thus, it presents with itself the advantages- system design flexibility, ease of expansion, high degree of modularity, reliability and ease of maintenance. In simpler terms, in distributed control systems, 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. Thus, most important aspect or the backbone of these distributed systems is the communication between their various controllers or ‘intelligent devices’. Many contributions which deals with industrial communication systems, often emphasises mostly on stability and the quality of the control loop and related non-functional requirements. However, some of these contributions have also mentioned the importance of timing behaviours in networked communication systems along with different types of communication behaviours (cyclic/ event-based) [3]. Various technologies have been developed in the last few years concerning distributed control system, and the timing behaviours of four of these technologies, namely NodeRED, Codesys, 4DIAC, DOME, have been compared in this technical report. The technologies are chosen such that each of them has a different kind of execution control:    

NodeRED: Threading operations (single point cycle), Codesys: Cyclic 4DIAC: Event-driven DOME: Sequential process implementation

So, a particularly interesting comparison can be drawn out by executing the same control task on each of these four technologies and then, measuring the total reaction time from the sensor to the actuator. An abstract idea can be derived from the results about the timing behaviours for these technologies and can motivate industrial process choices

8

2. Introduction to the Technologies 2.1 NodeRED 3.1.1 Introduction Node-RED has been developed by IBM emerging technology and the open source network, as a tool for wiring the Internet of Things (IoT). The main motivation of developing NodeRED lies in making it less time-consuming for developers while writing the code to the different systems, such as accessing a serial port. So, tools are required to make it easier for developers at all levels to bring together the different streams of events, both physical and digital [Own Report]. Based on Node.js, a Node-RED server basically is a HTTP server that uses an event-driven, non-blocking I/O model. It enables interaction of physical and virtual objects together by using a graphical user interface to control data flow between modules. It comes with a large library of complimentary modules, e.g. for hardware communication (Raspberry Pi’s GPIO), interaction with social media and visualization frameworks. Thus, it can be understood that building real-time applications for running across distributed device, is very convenient with the help of Node-RED. Developing interaction of ‘Internet of Things’ is very complicated, thus Node-RED enables us to concentrate on the work flow and handle the technicalities itself. Internet of things (IoT) can be categorized as a dynamic network of ‘things’ capable of self-configuring ability and are communicate with standard communication protocols and integrated into an information network. These ‘things’ have their own identities and have attributes both physical and virtual and are incorporated into the information network [4]. The concept of IoT enables us to connect and communicate all the things around us by sensors and actuators and adopt them to our requirement, operational safety and personal wellbeing. The developed of IoT is assisted by Node Red as it avoids the need of unnecessary coding and accelerates the development of IoT. 3.1.2 User Interface and ‘Nodes’

FIGURE 1: THE BASIC USER INTERFACE OF NODE-RED

9

^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, Mustache 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

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.

3.1.4 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’[4]. 10

3.1.5 Advantages of Node-Red in various sectors Thus, in a nutshell, Node-RED provides a variety of advantages for people in different professional sectors and these are listed below [5]: 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.

2.2 CODESYS 2.2.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 [6]. 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 [7]. 11

2.2.2 Basic Idea About IEC 61131-3 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. 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

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. The major advantage of applying a standardized programming language is the positive impact that it has on the software lifecycle 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. IEC 61131-3 standard can be split into two parts: 1. Common Elements 2. Programming Languages

2.2.3 Common Elements



12

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. Its is also possible for the user to define his own datatypes, known as the derived datatypes.

The variables can be local as well as global. The local variables are normally limited to the organization unit in which thea 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. 

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 [8].

2.2.4 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. The standard languages are:

13



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



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.



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 text-

based, 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. 

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. In the next page, figure languages of IEC 61131.

shows the part of same program written in different

FIGURE 3: ALL FOUR SHOWING SAME PROGRAM PART [6]

2.2.5 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 [6].

14

2.2.6 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 4: CODESYS PROGRAMMING ENVIRONMENT

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 [9].

15

2.2.7 '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 application developed with CODESYS" [9] 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 [9].

2.2.8 Advantages Codesys provides the following competitive advantages apart from the various other advantages that has been discussed in previous sections [7]:

16



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.



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.



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.



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.

2.3 4DIAC 2.3.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" [10]. 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) [11].

2.3.2 Basic Idea of IEC 61499 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 [12]. The Internation 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 17

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 [13]. 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 [13]. Various researches are carried on by various research institutes, companies and universities to make this standard better with passing days.

2.3.3 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, apart from 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) [14]. 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.

2.3.4 IEC 61499 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." [15]. 18

FIGURE 5: A FUNCTION BLOCK TYPE

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 executed in states [7]. 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 6: A BASIC FUNCTION BLOCK

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 [6].

FIGURE 7: A COMPOSITE FB TYPE 19

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 [4]. 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 8: SERVICE INTERFACE FUNCTION BLOCK

"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"[2]. This can be compared to designing a circuit board with integrated circuits.

FIGURE 9: AN APPLICATION DISTRIBUTION IN 4DIAC

20

2.3.5 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

2.3.6 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 [16].

FIGURE 10: 4DIAC-IDE BASIC INFO [9]

The 4DIAC-IDE presents itself with the following features:

21

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 11: 4DIAC-IDE SYSTEM CONFIGURATION EDITOR [10]

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

FIGURE 12: 4DIAC-IDE DEPLOYMENT PERSPECTIVE [10]

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

22

FIGURE 13: 4DIAC-IDE INTERFACE EDITING [10]

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.

FIGURE 14: 4DIAC-IDE RESOURCE EDITOR [10]

2.3.7 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" [3]. The core functionality of 4DIAC-RTE includes the execution of IEC 61499 elements and the hardware abstraction. It supports all IEC 61131-3 elementary 23

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 [3]. 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.

FIGURE 15: 4DIAC FORTE [16]

2.3.8 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 16: (A) CFB

24

(B) BFB

(C) SIFB

[8]

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 [16].

2.3.9 4DIAC Toolchain

FIGURE 17: 4DIAC PROCESS [16]

2.4 DOME 2.4.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 [17].

25

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 [18].

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

FIGURE 18: DOME IDE [17]

26

FIGURE 19: DOME REPERIO [17]

2.4.3 Application Model

FIGURE 20: APPLICATION MODEL OF DOME [17]

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.

27

2.4.4 Compiling Process in DOME

FIGURE 21: COMPILING PROCESS IN DOME [18]

28

3. Time Characteristics In a Network This section provides the explanations of various time values that can be measured when a signal is sent through a network. To comply with stringency in scientific research and to avoid any misunderstandings, [19] is used as a reference. i.

End-end transmission time (IO response time): ΔtIORT the time period for a complete system throughput, from sensor to actuator, and the reaction time is the sum of the partial times. + Δt5 +

Device

ΔtTP,I =

Communication System

Δ

4,I

Control

Δ

5

Communication System

Δ

4,O

Device

ΔtTP,I =

FIGURE 22: TERMINAL - TERMINAL REACTION TIME FROM A SYSTEMS THEORY PERSPECTIVE [19]

ii.

Transition period: ΔtTP the transition time is defined differently for input and output direction. For input, the transitional period ΔtTP,I is the amount of time required to capture, convert and transfer data to the industrial Ethernet from the input of the field device. For outputs, the transitional period ΔtTP,O is the time required to receive, convert and provide the data from the interface with the industrial Ethernet (PHY) to the output of the field device. ΔtTP,I = Δt1,I+ Δt2,I+ Δt3,I ΔtTP,O = Δt1,O+ Δt2,O+ Δt3,O

iii.

Cycle Time: Cycle time is the time, usually measured in nanosecond s, between the start of one random access memory (RAM) access to the time when the next access can be started.

iv.

Frame length: Δtframe an Ethernet telegram is composed of user data and the Ethernet frame. The variable frame length is defined as the time required for the transmission of specific Ethernet telegram on a transmission medium. It is determined by the number of bytes in the message and the transmission rate C of the medium.

29

v.

Forwarding time (bridge delay): ΔtBD the forwarding time (bridge delay) is the time taken for a network user to forward an incoming telegram from one port to another. The forwarding time is measured from the arrival of the first byte of a telegram at the input port to the first byte of the output port (telegram beginning to telegram beginning), the limit being is the Media Independent Interface (MII). The forwarding time is given only for the network users, which transmit the telegram at the communication level from one port to another (e.g. Switches).

Sender

Receiver Cable delay

ASIC/ FPGA

M I I

PHY

PHY

PHY delay Linedelay

M I I

ASIC/ FPGA

M I I

PHY

Bridgedelay

FIGURE 23: BRIDGE DELAY AND LINE DELAY [19] vi.

vii.

30

Line delay: ΔtLD line delay is again the telegram delay that is introduced in the physical transmission medium. It is determined by the speed with which the information on the respective medium can spread and the length of the transmission path. Besides the speed (ϑ) and the length (l), the processing time of the sender ΔPHY, TX and receiver ΔPHY, RX are also taken into account. ϑ.l + ΔtPHY,RX + ΔtPHY,TX Transmission delay: ΔtTD the transmission delay is defined as “time for transmission of Ethernet framers on the medium between two devices” [21]. The period begins with the sending of the first byte and ends with the reception of the last byte of the receiver.

4. Test Setup The same open loop, discrete control task has been implemented with each of the four technologies described before and the various time properties, which have been discussed in the previous chapter, have been measured. The devices that have been used are: 1) PC with Hilscher Net-Analyzer NANL-C500-RE 2) Two Raspberry-Pi devices 3) Logic level translator/level shifter ADG3300 The control task involves control of a LED connected to one of the raspberry pi modules with the switch of the pi-face module mounted in the other raspberry pi, involving internet connectivity. Only the ON/OFF operation of the LED has been considered here, which can be further extended into much more complex distributed control application.

FIGURE 24: CONTROL TASK DEFINING ALL THE COMPONENTS INVOLVED

Raspberry- Pi: Two raspberry pi-2 devices have been used while implementing the control task. 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 Video Core IV 3D graphics core. The developments from the previous Raspberry-Pi-1 model are the inclusion of a 1 GB RAM and a 900 MHz quad-core ARM Cortex-A7 CPU.

31

FIGURE 25: INTEGRATED RASPBERRY PI-2 SETUP

As can be seen in figure 25, it is an integrated setup, mounted with piface module (www.piface.org.uk), a LED and a separate switch which is connected to one of the output pins of the piface. The first step is to setup our raspberry pi. The first steps of setting up the raspberry pi are explained properly in [22]

Piface Digital 2 Board: A Piface Digital 2 board is integrated with the raspberry pi device due to its various advantages. The Piface board has got eight input pins, which detect a connection to the ground. The ground is provided as the ninth pin. The inputs are pulled up to 5V and four tactile switches are connected in parallel to the first four input pins. There are also eight output pins, which are open collectors. Eight LEDs are connected in parallel to each of these output pins. The switch 0 and the LED 0 has been used for this test setup while implementing the control task for the different technologies.

FIGURE 26: PIFACE DIGITAL 2 BOARD [23]

Level Shifter: As can be seen in the block diagram (figure 27), a level shifter has been used to transform the voltage levels. The maximum permissible voltage in the Net-analyzer device is 3.3 V, whereas the output voltage for the integrated Piface module with the raspberry pi is 5 V. So, the level shifter, ADG3300, has been used to tackle the problem.

32

FIGURE 27: FUNCTIONAL BLOCK DIAGRAM OF ADG3300 [24]

The bidirectional level translator consists of eight bidirectional channels and functions over the range of 1.15 V to 5.5 V. One of the main reasons to use the ADG3300 was that the internal architecture allows the device to perform bidirectional logic level translation without an additional signal to set the direction [24]. The voltage from the Net-analyzer device is applied to the VCCA, which sets the logic level of the A side, whereas the voltage from the piface module of the raspberry pi is applied to the VCCY, which sets the logic level of the Y side.

FIGURE 28: PIN DIAGRAM OF ADG3300 [24]

FIGURE 29: 3.3V TO 5V LEVEL TRANSLATION EYE DIAGRAM [24]

33

FIGURE 30: 5V TO 3.3V LEVEL TRANSLATION EYE DIAGRAM [24]

Net Analyzer: The Hilscher netANALYZER NANLC-500RE is used for the purpose of timing analysis. A capture-hardware for recording the telegrams as well as graphical user software for windows with sensitive analysis functions is available with the device. The integrated Test Access Points (TAPs) ensure the absence of reaction on the Ethernet network during the measuring process. Since a TAP physically corresponds to an Ethernet cable of a few millimetres additional length. [25]

FIGURE 31: HILSCHER NETANALYZER C-500RE [25]

Communication Access: ‘An access method is a software component, operating service or network interface that handles the storage/retrieval and sending/receipt of data. Access methods provide an application programming interface (API) for programmers to perform these services, which rely on low-level, specialized instructions’ [26] Access methods include:  Internal structures to organize data as data sets  System-provided programs  Utility programs for data set processing  Error detection and correction capabilities So, in general terms, a set of rules or protocols that helps in defining how a computer puts data onto the network cable and takes data from the same is known as an access method. During the movement of the data, these methods help in the regulation of the network traffic flow. Various methods of accessing the network are mentioned below: 

34

Master/Slave: A master/slave method is a model in computer networking where one device or process, the ‘master, controls and monitors one or more devices or processes, the ‘slaves’. Each master can be assigned n number of slaves and direction of control is always from the master to the slave(s) when a connection is established. The master interrogates the slaves to which the slaves should ideally respond. The queries are mostly carried out in a cyclical fashion (polling).

35



Token Passing: In communication methods, token passing denotes channel access method where a signal, which is known as a ’token’, or series of bits is used to grant a device permission to transmit over the network [27]. So, the device, having the token is allowed to pass the data through the network. When the transmission of one device is complete, it passes the token to the next device in round-robin scheduling manner. ‘The system rules in the protocol specifications mandate how long a device may keep a token, how long it can transmit for and how to generate a new token if there isn’t one circulating’ [27]. The main advantages of this access method are the avoidance of collision between the sent packets and the complete utilization of the channel bandwidth without idle time when the demand is heavy.



Carrier Sense Multiple Access (CSMA]: CSMA is a probabilistic network access control protocol where it is first determined by a device whether the shared transmission medium is busy with another transmission or not, before it begins its transmission. Carrier sense refers to the process where a transmitter first determines whether the transmission medium is free or not, or another transmission is taking place at that instance or not, before starting the transmission. If a transmission is sensed to be taking place, the transmitter waits for it to get finished before starting its own transmission. So, basically, it abides the rules ‘sense before transmit’ or ‘listen before talk [28]. Multiple access denotes that multiple mediums may send and receive data on the medium. CSMA can be further classified into CSMA/CD (CSMACollision Detection) and CSMA/CA (CSMA-Collision Avoidance). CSMA/CD improves the performance by terminating the transmission immediately when a collision is detected, whereas in CSMA/CA, the transmission medium is first sensed, and if a transmission is taking place, the current transmission is deferred by a certain interval.



Publisher/Subscriber: The publisher/subscriber is a connectionless protocol in network communication, where the sender or the ‘publisher’ do not create messages to be sent to particular receivers. Specific classes are created and published by them, and all the interested receivers or the ‘subscribers’ can receive the specific part of the message that is of interest to them. The publisher/subscriber model can be configured in three different ways [29]: i) List-based publisher/subscriber: A list based publisher/subscriber model creates a subject and maintain a list of subscribers for that subject. When an event occurs, this subject then notifies all the subscribers in the subscription list. ii) Broadcast-based publisher/subscriber: In a broadcast-based publisher/subscriber model, a message is created by an event publisher and is broadcasted over the entire network. A receiving node then receives the message, and verifies the subject line. If the subject line matches its subscribed subject, the subscriber receives the message, else it ignores it. iii) Content based publish/subscribe: ‘ Content-based systems are more flexible as subscriptions are related to specific information content and, therefore, each combination of information items can actually be seen as a single dynamic logical channel. This

exponential enlargement of potential logical channels has changed the way to implement a pub/sub system’ [30]

4.1 Measurement Strategy: The transmission path has been broken down into four measuring points. Since, it is a distributed setup, it is of particular interest to observe the time required by the signal between these points. The end to end transmission time is thus the summation of these times. 1

2

3

4

FIGURE 32: MEASUREMENT P OINTS

Measurement Points: 

Point 1- Point2: The time required by the signal generated from the digital piface board integrated on the Raspberry Pi to reach the network.



Point 2-Point 3: The time spent by the signal on the network



Point 3- Point 4: The time required by the signal after leaving the network till it comes out of the second Raspberry Pi

Measuring Terms:

36



Transmission delay over the network



Transition period ΔTin and ΔTout



Transmission period (point1- point 2)- ΔtTP1-2



Transmission period (point3- point 4)- ΔtTP3-4



End to end transmission time: ΔtIORT



Cycle (tCT) or scan time (tST)

5. Control-task Implementation for Different Technologies The same control task has been carried out in all the four technologies. A signal is generated from the switch of the piface board integrated with the raspberry pi. This signal is sent to the other raspberry pi over the network and it controls the LED on the piface board.

FIGURE 33: USING THE SWITCH OF ONE RASPBERRY PI TO CONTROL THE LED OF ANOTHER RASPBERRY PI

5.1 NodeRED: One of the raspberry pi is considered as the ‘sender’ and the other as the ‘receiver’. In the ‘sender’ end, a flow is created such that an input can be generated when one of the piface switch is pressed. To do this, the ‘node-red-node-piface’ is first installed globally in the raspberry pi and the ‘rpi-piface’ input and output nodes will appear in the node library. The ‘rpi-piface’ input node generates a ‘msg.payload’ with either a 1 or 0 depending on the state of the input pin, and the output node will set the selected relay or LED depending on the passed in value. The input node is wired with a TCP output node, which sends a TCP request to the other raspberry pi to send it the signal. In the ‘receiving’ end, the TCP input node receives the signal from the other device and after a provided condition, it is sent to the ‘rpi-piface’ output node and the LED number is selected from the list.

FIGURE 34 : NODERED FLOW ‘SENDER’ END

37

FIGURE 35: NODERED FLOW ‘RECEIVING ’ END

5.2 Codesys: The basic steps to set up Codesys are explained in detail in [1]. Since, raspberry pi devices are being used; an additional package for raspberry pi control is installed from the Codesys store. For implementing the control tasks, two different projects have been created. The reason for creating two different projects separately for the sender end and the receiver end instead of only one, is that when only one project has been created and the sender and the receiver end devices have been implemented in that, sometimes one of the devices stopped functioning and the devices needed to be rebooted. However, this same implementation can also be done creating only one project and adding the sender and the receiver devices in it. Since a pi-face board is also attached, the input and the output control of piface board is configured in the Codesys IDE from the ‘SPI’ device tab. Any of the five IEC 61131-3 programming languages can be used in Codesys for the purpose, but Functional Block Diagram (FBD) is chosen because of its simplicity. Now, after the package has been successfully installed, it is time to start creating the projects. The goal can be reached by controlling the two devices from one single project, but it is observed that creating two different projects for ‘sender’ and ‘receiver’ is much faster and simpler and a generic error can be avoided. First, a new project is created. To do this, the cursor should be moved to ‘File’, ‘New Project’ should be clicked and a ‘Standard project’ should be chosen. This project is given the name ‘Sender’ because; the signal will be sent from this device. Next, the package ‘Codesys Control For Raspberry Pi’ is selected in the device, and for the choice of programming language, ‘Function block Diagram (FBD)’ is chosen as mentioned earlier. It is now time to make few adjustments before the switch on our piface board can be used. The first and foremost thing is to setup the device and for this, ‘Device’ should be clicked and the IP of one of the raspberry pi devices is put in and processed. Then ‘Add Device’ is selected for ‘SPI’ and ‘SPI Master’ is added. Then, after ‘SPI Master’ and ‘Add Device’ are selected, ‘Piface’ can be added. Then, a network variable should be added in our application, so that this variable can be sent over the network to control the receiving end. To do this, ‘Application’ is selected, followed by ‘Network Variable List (Sender)’. At this point, a variable must be created that will be sent to the other 38

project via the network. The name ‘Status’ is used for this variable. After implementing these steps, the POU should be set up now. To do this, the cursor should be moved to ‘PLC_PRG (PRG)’. From the ‘toolbox’, which is found on the right hand side of the screen, ‘Function Blocks’ tab should be expanded and ‘TON’ block is selected. A name can be set up for this block (optional) and a variable should be setup for this block, which is of type ‘TON’. We can now observe that the TON block has got two inputs and two outputs and we have got to assign variables in each of them. The ‘IN’ (input) should come from the switch, which is on the piface board. To do this, ‘piface.byIn.pinnumber’ should be assigned where ‘pinnumber’ should be replaced by the intented pin number on the piface board. Here, the pin number 0 is used, so the input is seen as ‘piface.byIn.0’. Next comes the ‘PT’, which is the time that should pass before the output is set. This can set this to 50ms. To do this, the value of PT should be assigned as‘t#50ms’. ‘Q’ should be assigned with the network variable. ‘EN’ denotes the time elapsed since rising edge at input. This can be checked once the project is run. Before running the project, the final step is to set the properties of the Network Variable List (NVL). To do this, NVL is right-clicked for properties ‘Export before compile’ is checked from ‘Link to file’ and e a file in our desired location is created. Now, the project is set to run. To run this, the projet is first compiled by pressing F11 Then, the device should be logged, run and F5 is pressed to start. In figure 36, the ‘sender’ project as observed, is shown.

FIGURE 36: ‘SENDER’ PROJECT IN CODESYS IDE

Once c the ‘Sender’ project has been successfully created, creating the ‘Receiver’ project is very simple. a new Codesys environment is opened and like before, a standard project is created and I gave it the name ‘Receiver’. The similar steps are followed as done while creating the ‘Sender’ project. The ‘Network Variable List (Receiver) is used and the network variable is imported from the file that we had generated. Like before, the TON block is used, 39

but this time, the input should be the ‘Status’ variable that has been imported. The time is kept the same and the output should be ‘piface.byOut.pinnumber’. Here, the LED numbered 1 is used and thus the pin number 1 is thus in this project. Now, The intended ‘Receiver’ project is projected in figure 37.

FIGURE 37: ‘RECEIVER’ PROJECT IN CODESYS IDE

After, running both the projects simultaneously, the goal could be achieved. The major problem faced while implementing the whole setup was running the two devices at the same time when created at a single project. Thus, the decision to create two different projects has been taken.

5.3 4DIAC: The same control task is carried out in 4DIAC. However, while implementing the task in 4DIAC, a major problem was faced. In the predefined function block library in 4DIAC, IX and QX function blocks are present which can be used to control the GPIO pins of a raspberry pi device. The IX and QX blocks interact directly with GPIO pins in the raspberry pi. But, integrated PiFace Digital module has been used in the setup which do not access the GPIO pins directly. So, in order to access the piFace I/Os, two new function blocks, PFIX and PFQX have been created to perform the task of IX and QX respectively. PFIX and PFQX- The basic aim of PFIX is to receive input from piFace switch and of PFQX is to provide output to the piFace output pins. In order to interact with the piFace I/Os, wiringPi library must be installed in the raspberry pi device. WiringPi library provides the function to receive input and to provide output to piFace switches and piFace output pins 40

respectively. So, wiringPi library is included in FORTE while compiling the same in raspberry pi. As shown in the figure , when the REQ event is triggered, the PFIX function block reads the input from the piFace switches according to the PARAMS data input and after the successful read, it triggers the CNF event. The data input QI acts as the input event qualifier and is always TRUE. The PFQX function block provides the OUT data input value to the piFace output pin, which is defined by the PARAMS data input when the REQ event is triggered. After the successful write of the output to the piFace pins, the CNF event is triggered and the STATUS becomes OK and the output event qualifier QO becomes TRUE. QI is the event qualifier as described above for the PFIX function block. The diagrammatic representation of both PFIX and PFQX can be found in figure 38. Overall application design: Publisher/Subscriber communication model is used for this task. Both sender and receiver ends are configured properly so that an input can be taken from one of the input switches in the Piface board of one raspberry pi and the signal can be sent to the receiving end through the network to control the LED on the Piface board of the other raspberry pi. The sender and the receiver end function blocks are being properly mapped to the individual raspberry pis and the application is deployed and downloaded. The FORTE is initiated in each of the two raspberry pi devices. The application can be monitored and the ‘Watch all’ option allows the user to watch the change in event and data at every point of the application.

FIGURE 38: DEPLOYED APPLICATION IN 4DIAC

The resources of both the devices are designed with publish and subscribe FB to provide the distributed control system. The publish and subscribe FBs use the User Datagram Protocol(UDP) for intercommunication. The Publish/Subscribe Function Blocks are provided with a multicast IP address and a port. The Publish FBs will send data over the network in this multicast IP address/port and the Subscribe FBs will listen to the same multicast IP address/port receiving any data sent by the Publish FBs. Multicast IP addresses can be picked from the range 224.0.0.0 - 239.255.255.255, while the port is arbitrary. As shown in figure 39, The single input PUBLISH function block publishes the Q of the E_SR function block. The multicast IP and port are 225.0.0.1 and 61499. The published data will be received by a single output SUBSCRIBE function block with the same IP and port number in the RECEIVER resource and will be provided to the PFQX function block as shown in figure 40.

41

FIGURE 39: ‘SENDER’ END FLOW IN 4DIAC

FIGURE 40: ‘RECEIVER’ END FLOW IN 4DIAC

5.4 DOME: In DOME-IDE, architecture of distributed system is defined in top-down manner using Processes interconnections. For execution of the same control task like in the other technologies, relevant DOME objects are created using DOME-L Language and a simple PLC_Logic object for establishing a connection with the receiver LED. The objects that are required for this control task were a pre-defined ‘Timer’ object initiating the process, a ‘Raspberry Pi-face’ object to get access to the integrated ‘piface’ board and the already mentioned PLC_Logic object. While configuring the PLC_Logic, processes for both localhostand Rpi device are formed. Inside the Rpi process, interconnections are made among the PiFace and PLC_Logic objects in order to implement the desired switching logic for distributed control. After implementation of logic in config file, HardwareConfig file is configured with Network address and compiler. The DOME files are to be compiled by 42

DOMEL Compiler creating .cxx and .h target files. These are further compiled by C++ compiler creating objects which are the linked to their respective devices and downloaded on the corresponding DOME modules. However, when all these processes were carried out, the control logic failed to work because of a specific error shown in the figure below. DOME was unable to access Piface.h file. In spite of attempting multiple times, including installing and unistalling the wiringPi file multiple times in the raspberry pi, this error could not be avoided. According to what understood, there was a problem establishing a connection between the DOME-IDE and the remote raspberry pi device and this error will hopefully be avoided when the much improved public release of DOME arrives. Unfortunately, the time measurements for DOME thus could not be observed.

FIGURE 41: FATAL ERROR IN DOME

43

6. Results and Comparison The process that has been followed to achieve the results and to generate the graphs is explained as:    

First, the results are observed from the NetAnalyzer software and files of .csv type and .pcap type have been generated by the software The .pcap files are used to analyze and observe the telegrams sent and received over the network The .csv file is used to generate the graphs The statistical tool, ‘R’ has been used to generate the graphs from the .csv files because of its simplicity in code generation, accuracy and feasibility.

6.1 NodeRED:

FIGURE 42: ΔTIN

The mean transition period input for NodeRED has been noted to be 22 µs, which can be marked in the point 22000 ns in figure 42. The standard deviation has been observed as 1.19 ms.

44

FIGURE 43: ΔTOUT

The mean transition period output for NodeRED has been noted to be 40 µs, which can be marked in the point 40000 ns in figure 43. The standard deviation has been observed as 1.9 ms Now, the transmission times between the measuring points are observed for NodeRED.

FIGURE 44: TRANSMISSION TIME BETWEEN POINT 1 AND P OINT 2

45


The mean transmission time between point 1 and point 2 has been observed to be 40.02 ms, as can be seen from the figure. The standard deviation is noted to be 72.1 ms. For the transmission between point 3 and 4, the mean time is observed to be 50.7 ms. The standard deviation is noted to be 56.653 ms.

46

End to end transmission time:

FIGURE 46: END TO END TRANSMISSION TIME

Since, this is a distributed setup, the end to end transmission time can be easily carried out by adding the time spent between the different terminals, or simply by adding the time responses observed above. If we consider the mean time in each of these transmissions as ideal, the end to end transmission time can be stated as: ΔtIORT = ΔTin + ΔTout + tST + ΔtTP1-2mean + ΔtTP3-4mean The scan-time(tST) in NodeRED was observed as 0.75 ms So, the ΔtIORT can be calculated to be: ΔtIORT= .022 ms + .040 ms + 40.02 ms + 50.7 ms + 0.75 ms ~=91.5 ms To the above calculations, the transmission delays in the transmission path have not been considered and they roughly sum up to .5 ms. So, the overall transmission time can be approximately stated to be 92 ms.

47

6.2 Codesys:

FIGURE 47: ΔTIN The mean transition period input for Codesys has been noted to be 19 µs, which can be marked in the point 19000 ns in figure 47. The standard deviation has been observed as 252 µs.

FIGURE 48: ΔTOUT,

48

The mean transition period output for Codesys has been noted to be 22 µs, which can be marked in the point 22000 ns in figure 48. The standard deviation has been observed as 1.8 m.s



49

The mean transmission time between point 1 and point 2 has been observed to be 11.5 ms. The standard deviation is noted to be 19.5 ms. For the transmission between point 3 and 4, the mean time is observed to be 25 ms. The standard deviation is noted to be 50.02 ms.


Since, Codesys utilises the cyclic execution control, the cyclic time should be considered while calculating the overall transmission time. Here, in Codesys, this cycle time (tCT) was set to be 50 ms, but, it was observed that it is not achieved perfectly and the mean cycle time came out to be 53.5 ms. So, considering the similar methodology as followed in NodeRED along with the cycle time, ΔtIORT = ΔTin + ΔTout + ΔtTP1-2mean + ΔtTP3-4mean+ 2tCT So, the ΔtIORT can be calculated to be: ΔtIORT= .019 ms + .022 ms + 11.5 ms + 25.0 ms + (2*53.5) ms ~=143.42 ms To the above calculations, the transmission delays in the transmission path have not been considered and they roughly sum up to .81 ms. So, the overall transmission time can be approximately stated to be 144.23 ms.

50

6.3 4DIAC:

FIGURE 52: ΔTIN

The mean transition period input for 4DIAC has been noted to be 8 µs, which can be marked in the point 8000 ns in figure 52. The standard deviation has been observed as 588 ns.

FIGURE 53: ΔTOUT 51

The mean transition period output for 4DIAC has been noted to be 15 µs, which can be marked in the point 15000 ns in figure 53. The standard deviation has been observed as 11.5 µs.



52

The mean transmission time between point 1 and point 2 has been observed to be 23.23 ms. The standard deviation is noted to be 13.4 ms. For the transmission between point 3 and 4, the mean time is observed to be 39.9 ms. The standard deviation is noted to be 44.52 ms.


Since, 4DIAC utilises the event-based execution control, the cyclic time should not be considered while calculating the overall transmission time.. So, considering the similar methodology as followed in NodeRED and Codesys, ΔtIORT = ΔTin + ΔTout + ΔtTP1-2mean + ΔtTP3-4mean So, the ΔtIORT can be calculated to be: ΔtIORT= .008 ms + .015 ms + 23.23 ms + 39.9 ms ~=63.153ms To the above calculations, the transmission delays in the transmission path have not been considered and they roughly sum up to .7 ms. So, the overall transmission time can be approximately stated to be 64.853 ms.

53

6.4 Comparison and discussion:

NodeRED

Codesys

4DIAC

DOME

End to end transmission Time (1-4)

92 ms

144.23 ms

64.853 ms

Could not be observed

Raspberry 1 – communication access (1-2)

40.2 ms

65 ms

23.23 ms


50.7 ms

78.5 ms

39.9 ms


Communication accessRaspberry 2 (34)

TABLE 1: COMPARISON OF TRANSMISSION TIMES FOR DIFFERENT TECHNOLOGIES

In [31], a detailed idea has been given regarding the terms scan-based (cyclic) and eventdriven execution mechanisms. But, one thing that has been agreed by all is that, the large overhead introduced by scan-based systems lead to a larger overall response time of the system.

54



In the results that have been observed in this report, it can be seen that, the overall transmission time in Codesys, which is based on IEC 61131 and utilises the scan based or cyclic execution mechanism, is greater than the overall transmission time of 4DIAC, based on IEC 61499 and using the event-driven execution mechanism.



Another important factor that has lead to the difference in the end to end transmission time calculations is the use of different communication protocols for each of these technologies. For instance, TCP is used in NodeRED, UDP in Codesys and Publisher/Subscriber methodology in 4DIAC. The network that is used during the experiments play the most important role in this time calculation and the time elapsed between sending of the packets from one end of the communication access to the other has differed in all the three technologies.



The jitter in the network for cyclically executed technologies has not been considered in the results and the jitter is expected to change the results by a fraction.



The cycle time in Codesys is provided as 50 ms, since some of the telegrams were lost if a smaller time was provided. However, this may always not be the case.

55



For IEC 61499, previously a Worst Case Execution Time (WCET) had been analyzed and explained in [32]. This can give a brief idea about the elapsed time of the telegrams in different parts of the network if we can assume the time taken by 4DIAC to process it, but there is no assured way of proving this.



With the availability of DOME public version that can be downloaded for free, the error that has been observed with DOME can be avoided. But, since the deadline of this project could not comply with the public release date, the implementation with the downloadable version could not be tried.



A very simple control task has been carried out for the experiments, and this can only give a vague idea about the actual parameters. In actual industrial applications, the control tasks are bound to involve much more number of devices and complexities and this can change the results in a great way.

7. Conclusion The main tasks of this technical project were divided into three parts- designing the control task and implementing them with the different technologies, selecting the time properties and defining a measurement strategy and executing the measurement with each technology and lastly, comparing the results with each other. Unfortunately, the control task for DOME could not be executed due to the unresolved error which has been discussed before. Apart from this, the other tasks have been carried out and the results are documented properly.

There were some specific observations that made during the execution of the tasks and the measurements. Firstly, in the latest release of Codesys and 4DIAC, great improvements have been implemented and it is much more user-friendly now. Support for raspberry pi device has been incorporated in the latest 4DIAC release, with specific function blocks. Secondly, the deployment perspective still has some bugs in 4DIAC. Sometimes, when deployed more than one time soon after another, errors stating ‘Unstable state’ creep up which are solved when the Forte is stopped and re run. Thirdly, raspberry pi device sometimes keep the switch and the LED state in its memory and even after stopping the process in any of the technologies, the control task does not cease being run.

These observed readings can be useful and can provide a basic idea for the users of these new technologies. Since the same control task were carried out for all the technologies, the observations can be compared with each other and giving a much better idea about the situation. The main goals for the project have been achieved, except for ‘DOME’ for which proper explanation is given, and every observations and tasks have been properly documented.

56

8. References [1] Distributed Control System (DCS), BusinessDictionary.com; [accessed 17 July. 2016]; http://www.businessdictionary.com/definition/distributed-control-system-DCS.html [2] GICSP EH, Assante M, Conway T. An Abbreviated History of Automation & Industrial Controls Systems and Cybersecurity 2014. [3] Thomas Hadlich, Stephan Höme, Christian Diedrich, Karin Eckert, Timo Frank, Alexander Fay, Birgit Vogel-Heuser, ‘Time as non-functional requirement in distributed control systems’, Universität Magdeburg, 06 Sep.2012 [4] Internet-of-things.eu, ‘The IoT Hub’, 2015. [Online]. Available: http://www.internetofthings.eu/introduction [5] Dave Conway-Jones, 17 March 2015, ‘NodeRED’, EclipseCon2014; (accessed 9 May 2016); https://www.eclipsecon.org/na2014/session/wiring-internet-things-node-red [6] 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/iec-61131-3-codesys-standardize-controllogic-programming/781f05f4f0.html [7] 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 [8] Real Time Automation, 'Control IEC 61131-3'; (accessed 14 May 2016), Copyright © 2015 [9] Niklas Heidloff, 02. Feb 2015 , 'What is Node-RED? How can it be used in internet of Things?'; (accessed 18 June 2016); http://heidloff.net/nh/home.nsf/article.xsp?id=21.01.2015081841NHEAL8.htm [10] 4DIAC-Consortium, October 2007, '4DIAC- Framework for Distributed Industrial Automation and Control'; www.fordiac.org [11] Alois Zoitl, 6 June 2013, '4DIAC- A Framework for Distributed Industrial Automation and Control', fortiss GmbH [12] 'IEC 61499', Wikipedia- The Free Encyclopaedia, https://en.wikipedia.org/wiki/IEC_61499 [13] Dai, Vyatkin, 'A Case Study On Migration From IEC 61131 PLC To IEC 61499 Function Block', University of Auckland [14] Gerber, Hanisch, Ebbinghaus, October 2007, 'From IEC 61131 to IEC 61499 For Distributed Systems: A Case Study', Martin-Luther Universität Halle-Wittemberg

57

[15] Christensen, Strasser, Valentini,Vyatkin, 'The IEC 61499 Function Block Standard: Overview Of the Second Edition', Automation Week 2012 [16] ‘4DIAC, Framework for Industrial Automation and Control', Eclipse, https://www.eclipse.org/4diac/en_ide.php [17]

Robert Schneckenhaus, 23 Jul. 2010, 'Debugging of distributed systems', Hochschule Magdeburg-Stendal [18] 'Distributed Object Model Environment Documentation', 31 Jan. 2008, IFAK e.V, [19] Stephan Höme, 02 Nov. 2015, ‘Analytische Modellierung des Zeitverhaltens von verteilten industriellen Steuerungssystemen‘, Otto Von Guericke Universität Magdeburg [20] IEC 61800-7-1: Adjustable speed electrical power drive systems - Part 7-1: Generic interface and use of profiles for power drive systems - Interface definition, IEC, 2007 [21] Werner, T.; Gerdelbracht, S.: Abschlussbericht zum Forschungsprojekt ‘Entwicklung einer Testmethodik zur Ermittlung der Anwendungsreaktionszeiten unter Verwendung unterschiedlicher Industrial-Ethernet-Lösungen‘. Ermittlung der Anwendungsreaktionszeiten. AiF-Forschungs-Vorhaben Nr. 14592 BR, 2009. [22] Raspberry Pi Foundation, ‘Technical documentation for using the raspberry pi’, https://www.raspberrypi.org/help/ [23] PiFace, ‘I/O Interface for Raspberry Pi’ http://www.piface.org.uk/iblog/ [24] Analog Devices, ‘Data Sheet ADG 3300’, http://www.analog.com/media/en/technicaldocumentation/data-sheets/ADG3300.pdf [25] Hilscher GmbH, ‘Ethernet Analysis Real-Time Ethernet’, www.hilscher.com/en/products/product-groups/analysis-and-data-acquisition/ethernetanalysis/nanl-b500g-re/ [26] ‘Access Method’, Techopedia, https://www.techopedia.com/definition/5835/accessmethod [27] Palappa Venkataram, ‘Introduction to Basics of Communication Protocol’, Indian Institute of Science, India. [28] ‘Carrier Sense Multiple Access’, Wikipedia- The Free Encyclopaedia, https://en.wikipedia.org/wiki/Carrier_sense_multiple_access [29] Oki, B.; M. Pfluegel, A. Siegel, and D. Skeen. ‘The Information Bus - An Architecture for Extensive Distributed Systems.’ Proceedings of the 1993 ACM Symposium on Operating Systems Principles, December 1993, [30] Baldoni, R.; M. Contenti, and A. Virgillito. ‘The Evolution of Publish/Subscribe Communication Systems’, Future Directions of Distributed Computing. Springer Verlag LNCS Vol. 2584, 2003. 58

[31] Kleanthis Thramboulidis, ‘IEC 61499 vs. 61131: A Comparison Based on Misperceptions’, Journal of Software Engineering and Applications 6(08), January 2013 [32] Jan Carlson and Luka Lednick,. ‘Timing analysis for IEC 61499’, Mälardalen University, Västeras Sweden, 2002.

59