UPTEC F 16029
Examensarbete 30 hp Juni 2016
System collaboration and information sharing using DDS technology
Emil Eriksson
Teknisk- naturvetenskaplig fakultet UTH-enheten
Besöksadress:
Ångströmlaboratoriet Lägerhyddsvägen 1 Hus 4, Plan 0
Postadress:
Box 536 751 21 Uppsala
Telefon:
018 – 471 30 03
Telefax:
018 – 471 30 00
Hemsida:
http://www.teknat.uu.se/student
Abstract
System collaboration and information sharing using DDS technology
Emil Eriksson
Just as the Internet of Things is set to change how devices are being used and connected in society in general, the Industrial Internet of Things will change the industries. In an industrial production line there are often many heterogeneous devices, and the requirements on the real-time properties of the communication between them are often strict. Creating a communication solution for the different devices, that also meet such requirements, is difficult. The traditional way for industrial devices to communicate is directly with each other or via a central point, but this communication solution is inflexible and difficult to scale up.
One possible way to make communication and information sharing between devices easier is to use a dedicated middleware to handle the communication. One
middleware standard is the Data Distribution Service (DDS) defined by the Object Management Group. In this thesis a DDS middleware from a specific vendor (vendor name is removed due to company confidentiality) is implemented and evaluated.
The middleware is evaluated based on (1) an implementation in a prototype which shows how the middleware performs in a real-life industrial context, and (2) a simulation that showcases the potential of the technology.
The DDS middleware was shown to function with a specific set of existing industrial hardware and software. The real-time properties of the communication system were studied and found to be around 3.5 times slower, when using the prototype setup, than those of the replaced communication solution. However, the round trip latency was still only 2 ms on average and 4.1 ms maximum when using the preferred settings.
The simulation showed that there is potential for the DDS technology to be used in more advanced scenarios and that it should be investigated further.
POPUL AR SCIENTIFIC SUMMARY IN SWEDISH
Teknikens utveckling med mer datorkraft till lägre pris i mindre format och snabbare överförings- hastigheter har gjort att fler och fler "saker" kopplas ihop och kopplas upp mot internet. Det är detta som kallas Internet of Things (IoT) och det finns många idéer om hur det kan användas. Till exempel skulle en tvättmaskin kunna starta sig själv när elpriset är som lägst, en kyl meddela ägaren på dennes telefon om vilka vanliga ingredienser som saknas, eller blomkrukor skicka data om fukthalt i jorden.
Det här har stor potential att ändra apparaters förmågor samt hur de används och industrins intresse för detta ökar.
Den industriella delen av IoT kallas Industrial Internet of Things (IIoT) och har ett lite annat fokus än IoT. I IIoT är det industriella maskiner som kommunicerar och fokuset är på automation, säker- het och produktionsanalys. Man skulle kunna tänka sig att i framtidens fabriker är alla maskiner och sensorer är ihopkopplade och reagerar snabbt utan interaktion från männsikor på förändringar i pro- duktionen. Dessa maskiner och sensorer skulle också med lätthet meddela övervakande operatörer om status och statistik.
För att en sådan vision ska fungera så måste kommunikationen mellan de olika maskinerna vara intelligent och väldefinierad. Det finns flera olika sätt att göra maskin-till-maskin kommunikation.
Ett sätt är att ha en central dator, med vilken alla maskiner är ihopkopplade, som agerar mellanhand och styr kommunikationen. Detta kan jämföras med posten; om man vill skicka information (ett brev) så skriver man adressen på kuvertet och lägger det i brevlådan, och så ser posten (mellanhan- den) till att det kommer fram till rätt person. Ett annat sätt är att koppla ihop maskinerna direkt så de kan skicka information mellan varandra. Det är jämförbard med att bo nära den man vill skicka ett brev till och själv lämnar brevet direkt i brevlådan. Ett tredje sätt kallas "publish/subscribe". Där är programmen i maskinerna inte medvetna vilka andra maskiner som sänder och tar emot infor- mation utan det finns en kommunikationsmjukvara i varje maskin som ser till att informationen hamnar rätt. En liknelse skulle kunna vara en nyhetshemsida (kommunikationsmjukvaran) där man anonymt kan lägga upp nyheter (publish) och välja vilka nyheter man vill se (subscribe). Till exempel skulle man kunna välja att man vill ha nyheter om fotboll och därigenom få nyheter från personer utan att man vet vilka de är och utan att de vet att man har fått deras nyhet, men nyheten hamnar likväl rätt tack vare hemsidan.
I tidigare industriella sammanhang där maskiner ska kopplas ihop har oftast det första eller andra sättet att kommunicera på använts. Dessa system är ganska lätta att skapa när det är få maskiner som ska kopplas ihop. Om man däremot vill kunna utvidga systemet med fler maskiner av olika sorter blir ett sådant system svårt att skala upp. Det blir svårt för att man måste programmera om maskinerna och se till att de kan kommunicera med varandra även fast det innehåller olika hårdvara och mjukvarulösningar. Om man istället använder en kommunikationsmjukvara som sköter kom- munikationen kan det blir lättare att utvidga systemet och få maskinerna att samarbeta bättre.
Det här arbetet har två huvdsakliga mål. Det första är att undersöka och utvärdera hur en mjuk- vara som följer en standard för distribuerad (alltså utspridd) kommunikation, som använder pub- lish/subscribe som sin kommunikationsmodell, kan användas med existerande industriell hårdvara och mjukvara. Det andra målet är att diskutera framtida möjliga tillämpningar av IIoT och visa på att delar av tillämpningarna kan fungera i en simulering.
Den första slutsatsen av arbetet är att den specifika kommunikationsmjukvaran som har studer- ats fungerar tillsammans med existerande insdustriell hårdvara och mjukvara, men att den är lite långsammare än den ersatta kommunikationen. Den andra slutsatsen är att simuleringen visar att mjukvaran har potential för mer avancerade tillämpningar och att den borde undersökas vidare.
ACKNOWLEGEMENTS
Many thanks to my collaboration partner Erick Vieyra, my supervisor at ABB Hongyu Pei-Breivold, and the rest of the team at the industrial IoT group at ABB: Larisa Rizvanovic, Marko Lehtola, Saad Azhar, and Kristian Sandström. Thanks are also due to Thiemo Voigt, my subject reader at Uppsala University.
Emil Eriksson, June 23, 2016.
CONTENTS
List of Figures vii
List of Tables viii
Abbreviations ix
1 Introduction 1
1.1 Problem statement and objective . . . . 1
1.2 Method . . . . 1
1.3 Alternative approaches . . . . 1
1.4 Collaborative work . . . . 2
1.5 Summary of results . . . . 2
1.6 Thesis structure . . . . 2
2 Related work 3 3 Background 4 3.1 The Internet of Things . . . . 4
3.2 Data Distribution Service . . . . 4
3.2.1 Global Data Space . . . . 4
3.2.2 Domain and DomainParticipant . . . . 5
3.2.3 Topic and DDS types . . . . 5
3.2.4 Publish/Subscribe . . . . 6
3.2.5 Publishers and DataWriters . . . . 6
3.2.6 Subscribers and DataReaders . . . . 6
3.2.7 Quality of Service policies . . . . 6
3.3 Real-time systems . . . . 6
3.4 Machine learning . . . . 7
3.4.1 Support vector machine algorithm . . . . 7
3.5 Hardware . . . . 8
3.6 Software . . . . 8
3.6.1 Robot Studio . . . . 8
3.6.2 DDS middleware . . . . 8
3.6.3 Robot controller operating system . . . . 9
4 Design and implementation 10 4.1 Prototype design and implementation . . . . 10
4.1.1 Functional requirements . . . . 10
4.1.2 Non-functional requirements . . . . 10
4.1.3 Hardware setup . . . . 10
4.1.4 Software design . . . . 11
4.2 Future scenario simulation design and implementation . . . . 12
4.2.1 Future scenarios . . . . 13
4.2.2 Requirements . . . . 13
4.2.3 Simulation overview . . . . 13
4.2.4 Simulation design and setup . . . . 14
5 Evaluation 17
5.1 Prototype performance experiment . . . . 17
5.1.1 Prototype performance experiment setup . . . . 17
5.1.2 Prototype performance measurements . . . . 20
5.1.3 Evaluation of the first prototype . . . . 31
5.2 Future scenario simulation test . . . . 32
5.2.1 Simulation test setup . . . . 32
5.2.2 Simulation measurements . . . . 32
5.2.3 Evaluation of the simulation . . . . 35
6 Conclusions and future work 36 6.1 Conclusions . . . . 36
6.2 Future work . . . . 36
References 37
LIST OFFIGURES
3.1 Global data space . . . . 5
3.2 Overview of DDS entities . . . . 5
3.3 Cost functions for support vector machines. . . . 7
4.1 Prototype hardware setup . . . . 11
4.2 Prototype software design . . . . 11
4.3 Dimensions of the boxes . . . . 14
4.4 Simulation created in RobotStudio . . . . 15
4.5 Overview of the communication in the future scenario simulation . . . . 15
5.1 Steps in the socket measurement . . . . 17
5.2 Steps in the DDS measurement . . . . 19
5.3 Measurement of the latency (round trip time) for the socket-based communication be- tween two RCs for different sizes of the messages. . . . 20
5.4 Measurements of the latency for messages, of size varying from 1 to 1000 bytes, sent from one RC via DDS-based communication with a reliable QoS to the other RC and back. . . . 21
5.5 Comparison of the latency measurements between DDS-based communication and direct socket communication. . . . 22
5.6 Comparison of the latency measurements for DDS-link and internal socket. . . . 23
5.7 Measurement of the latency for the DDS-based communication between two robot controllers for different sizes of the messages and reliable vs unreliable communica- tion. . . . 24
5.8 Measurement values from an experiment with a Listener call. . . . 25
5.9 Measurement values from an experiment with a Listener call, zoomed in. . . . 26
5.10 Average latency in the system when more subscribers are added. . . . 27
5.11 Average latency in the system when more subscribers are added on one and two com- puters. . . . 28
5.12 Comparison of the latency measurements when using unreliable and reliable QoS and having extra subscribers. . . . 29
5.13 Comparison of the latency measurements when flooding and not flooding the network. 30 5.14 Plot of the samples and decision boundaries in the xy-plane. . . . 33
5.15 Plot of the samples and decision boundaries in the xz-plane. . . . 33
5.16 Plot of the samples and decision boundaries in the yz-plane. . . . 34
5.17 Plot of the samples and decision boundaries for detection of the faulty boxes in class 1 boxes in the xy-plane. . . . 35
LIST OFTABLES
4.1 Sizes of the different classes of boxes . . . . 13
5.1 Comparison of the DDS-based and the direct socket based communication strategies. . 22
5.2 Comparison of the DDS-link and internal socket. . . . 23
5.3 Comparison between the reliable and unreliable QoS policies. . . . 24
5.4 Comparison of experiment results between the Listener and WaitSet call. . . . 26
5.5 Change in system performance with more subscribers added. . . . 27
5.6 Change in system performance with more subscribers added on one and two computers. 28 5.7 Comparison of the effect of QoS policy on latency when having extra subscribers. . . . . 29
5.8 Comparison of the effect on latency of flooding the network. . . . 31
ABBREVIATIONS
DDS Data Distribution Service GDS Global Data Space
IIoT Industrial Internet of Things IoT Internet of Things
OMG Object Management Group RC Robot Controller
RTT Round Trip Time
SVM Support Vector Machine
1 INTRODUCTION
The Internet of Things (IoT) is the infrastructure that enables advanced services by interconnecting physical (and virtual) things. IoT is a hot topic and this is captured by the Gartner research firm in its latest hype cycle (August 2015)[1] where it can be found at the top of the hype curve. At ABB the Industrial Internet of Things (IIoT), which is the industrial part of the IoT, is seen as an interesting emerging field that will play an important role in the company in the future. Today, however, there are not many industrial machine which have been connected in an IIoT and there are several reasons for this. Among the reasons are security and data privacy concerns and concerns regarding commu- nication interoperability between different existing systems. However since IIoT has so much to offer, companies cannot afford to ignore it[2].
One area where an IIoT with smarter communication and information sharing solutions would be useful is robot collaboration. Robot collaboration has already begun to be tested at ABB in an on- going research project. In the research project the machines share data with each other via direct socket-based communication. This sort of direct connections or connections via a centralized point is how communication between robots is traditionally handled. While this works on a small scale, difficulties arise when there is need to expand or alter the system. Then large parts of the system need to be reprogrammed and there is little intelligence in the system which makes it easy. For this reason ABB wants to test the use of Data Distribution Service (DDS), a distributed information shar- ing middleware, in their machine-to-machine communication. ABB is also interested in researching the potential future uses of DDS in IIoT.
1.1 PROBLEM STATEMENT AND OBJECTIVE
In essence the problem is that the traditional way of connecting and sharing information between industrial robots either directly or via a central point is not easily altered or scalable.
The first objective of this thesis is thus to study the DDS standard and implement a specific DDS middleware in a robot collaboration prototype showcasing some possibilities of using DDS. The ob- jective is also to measure and evaluate real time properties of the communication solution in the prototype. The second objective is to research some possible future scenarios for IIoT, with focus on DDS and industrial robots, and create a proof of concept for one of the future scenarios specifically utilizing the power of machine learning.
1.2 METHOD
The method used is an experimental method. The DDS middleware protocol and a specific middle- ware is studied and two experiments are designed. The first experiment is an implementation of the DDS middleware in a robot collaboration scenario prototype. The real-time characteristics of the DDS network are measured and analysed under different conditions. The second experiment is a simulated proof of concept based on machine communication and machine learning.
1.3 ALTERNATIVE APPROACHES
In this thesis the focus is on a specific DDS middleware utilizing the publish/subscribe messaging pattern. Another approach would be to try some other DDS middleware, protocol (such as MQTT or AMQP), or messaging pattern (such as request-reply). Another alternative approach that has already been tested by Grubisic and Marsic[3] is a theoretical approach.
1.4 COLL ABORATIVE WORK
This work has been performed at ABB Corporate Research in Västerås in collaboration with Erick Vieyra (student at Mälardalens Högskola). However, for the future scenario simulation, I was re- sponsible for the machine learning implementation and Erick was responsible for the RobotStudio simulation.
1.5 SUMMARY OF RESULTS
The specific DDS middleware was shown to function with a set of existing industrial hardware and software. The real-time properties of the communication system were studied and found to be around 3.5 times slower, when using the prototype setup, than those of the replaced communica- tion solution. However, the round trip latency was still only 2 ms on average and 4.1 ms maximum when using the preferred settings. The future scenario simulation showed that there is potential for the DDS technology to be used in more advanced scenarios and that it should be investigated further.
1.6 THESIS STRUCTURE
The remaining part of the thesis is structured as follows. In chapter 2 related work is presented. In chapter 3 some background necessary to understand the thesis is explained. In chapter 4 you will find the the design and implementation of both the first prototype and the proof of concept simulation. In chapter 5 the measurements of the real time properties of the prototype are presented and evaluated.
In chapter 6 some final conclusions are stated and future work suggested.
2 REL ATED WORK
In 2012 Yang studied the application of DDS in industrial automation[4]. He states that industrial automation systems are usually complex distributed systems with large volumes of data. He tested whether DDS was a good replacement to the traditional socket-based communication that could decrease the complexity of the system. To test this he made a model of a DDS system and evaluated its performance. The conclusion was that DDS was a good solution to reduce complexity in distributed systems.
In 2015 Didic and Nikolaidis studied cloud computing and industrial control systems[5]. They wanted to research how a control system would be affected by having parts of the closed control loop executed in the cloud with its unpredictable latencies. They created a prototype simulating a server with varying levels of latencies. The conclusion was that low levels of latencies, such as those found in a connection to a local cloud server, do not have large adverse effects on a closed control loop.
However a remote cloud server does not offer good performance and should not be used for critical real-time tasks even with some proposed latency mitigation algorithms.
Also in 2015 Grubisic and Marsic looked at system collaboration and information sharing[3]. Their approach on the subject was to do a systematic research review to see which IoT solutions were avail- able. They then created a demonstrator to show that system collaboration and information sharing was possible using DDS software.
Surveys have been made both regarding standards for real-time distribution middleware[6], re- garding cloud robotics and automation[7], and regarding the IoT in industries[8].
In January 2015 the World Economic Forum gave out a technology report discussing the IIoT and its effect on the industry[2]. Their conclusion was that the IIoT is going to transform the industry in a very dramatic way. They suggest four main benefits to the IIoT; improved operational efficiency, closer collaboration between robots and humans, new connected ecosystems where different com- panies easily and more closely cooperate with each other, and emergence of an outcome economy (where the selling points are moved from the product itself to things the products are supposed to achieve). They show that the two main perceived challenges to the IIoT are security concerns and interoperability problems.
The real-time performance of three different open source middlewares has been tested by Rizano et al.[9]. They studied them using an experiment based on a case-study about a distributed system in an assistant robot walker. The three middlewares studied were OpenDDS, ZeroMQ, and ORTE.
The sensor in the walker that had the shortest update-time had an update-time of 10ms. The exper- iments showed that (the most lightweight and not DDS standard compliant) ZeroMQ delivered the best performance with both an average and a worst case latency of less than 10ms. OpenDDS and ORTE did not deliver a worst case latency of less than 10ms but the average latency was less than 10ms.
In 2014 Pérez and Gutiérrez studied which effect the Quality of Service(QoS) parameters of DDS have on a model of an event-driven application[10].
Hakiri et al. have studied the end-to-end QoS [11]. There are several QoS policies available in the OMG DDS standard but they are not made for wide area networks. Hakiri et al. try to solve this by making a framework for supporting end-to-end QoS in heterogeneous networks.
There are several studies where machine learning has been used in an industry environment. In [12] and [13] they study the use of machine learning for quality control in the plastic moulding indus- try. In [14] they use machine learning for weld quality monitoring. As a last example machine vision and machine learning has been used to detect and classify errors in percussion cap production in [15].
3 BACKGROUND
In this chapter background knowledge regarding the Internet of Things, DDS, machine learning, and the software and hardware used is explained.
3.1 THEINTERNET OFTHINGS
The Internet of Things (IoT) is the infrastructure that enables advanced services by interconnecting physical (and virtual) things[16]. The idea behind IoT is that the lives of people would become easier and better with the help of connected sensors and devices. For example a person could be notified that they forgot to close a window, or the fridge could sense which groceries need to be bought to make a specific recipe.
The Industrial Internet of Things (IIoT) is the the subset of the IoT where the connected things are industrial devices and that focuses more on automation and analysis of production[17]. The idea is that sensors and network connectivity added to the means of production could provide data for anal- ysis and control which would increase productivity but also to help find new business opportunities[18].
Considering how large the amount of data could be, computers would have to analyse the data to find relevant information and trends. Big data analysis and machine learning is therefore going to be crucial to find and use new business models and ways of increasing productivity and uptime[19][20].
A big challenge when it comes to IoT in general and IIoT in particular is to make heterogeneous devices share information[8]. To solve this challenge different middlewares standards (of which DDS is one) have been created.
3.2 DATADISTRIBUTIONSERVICE
Data Distribution Service (DDS) is a data sharing middleware protocol and API standard defined by the technology standards consortium Object Management Group (OMG)[21]. It is a data-centric standard, this means that the middleware (which means software that links different pieces of soft- ware to each other) is aware of the contents of the data that is being sent. This awareness enables effective data-filtering. DDS is also made to be used in real-time applications. To support this ex- tensive quality of service (QoS) policies are available. DDS is a fully distributed standard, this means that there is no central mediator or broker of information that can fail and crash the entire system.
In the following subsections the main parts of the DDS standard are explained.
3.2.1 GLOBALDATASPACE
The Global Data Space (GDS) can be thought of as a distributed “cloud” of information (see Figure 3.1). The user applications on the nodes connected to this GDS are not aware of each other. They only know what information they are interested in getting and what information they are interested in sharing. The middleware then takes care of connecting the nodes to each other in a transparent peer-to-peer network and makes sure that the information in the GDS is propagated correctly. The good thing about this rather than using a central information broker is that there is no single point of failure.
Figure 3.1: Global data space
3.2.2 DOMAIN ANDDOMAINPARTICIPANT
A DDS Domain can be thought of as an abstract network (inside the GDS) of nodes that can share data with each other. Data that is shared within a Domain cannot be accessed by a node outside of the Domain unless that data is passed on from a node within the Domain. A node is active within the Domain with the help of a DomainParticipant. A node can have several DomainParticipants and thus be a part of several Domains, and several Domains can exist at the same time on the same network (see Figure 3.2).
Figure 3.2: Overview of DDS entities
3.2.3 TOPIC ANDDDSTYPES
A Topic in a DDS Domain is a unique (within the Domain) identifier associated with a specific data type (structure). When data is shared within a DDS Domain it always has to belong to a specified
Topic and the data has to be formatted to fit the data type of the Topic. An example could be a Topic called "Temperature" that is of the data type "TemperatureData" defined by
s t r u c t TemperatureData { i n t id ; //@key s t r i n g <10> temp ; } ;
Instances of a Topic (differentiated by a key or ID) can be shared within a Domain with nodes that already are aware of the name of the Topic and its associated data type at compile time.
3.2.4 PUBLISH/SUBSCRIBE
When an application in a node wants to share data on a Topic it does so by publishing it. The infor- mation is then passed on by the middleware to applications that have subscribed to that Topic. The way the middleware in the first node knows to send the information to the second node is that the middleware on the second node earlier had sent a message to all the middlewares in the domain.
This message contained information about which Topics the node wanted to subscribe and publish to.
3.2.5 PUBLISHERS ANDDATAWRITERS
When an application has a DomainParticipant and thus is a part of a Domain and it wants to publish data it needs a DataWriter entity. This entity is connected to a single Topic and the application can publish data to the Domain using the DataWriter. The DataWriter is connected to a Publisher that is responsible for distributing the data. The Publisher can be used by many DataWriters that it groups together so that a common Quality of Service policy (see Section 3.2.7) can be applied to all of them.
3.2.6 SUBSCRIBERS ANDDATAREADERS
When a node wants to read data being published in a Domain it needs a DataReader entity. This entity does not necessarily only read a single Topic, it can use MultiTopics or FilteredTopics. Just as a Publisher can be used to group DataWriters together, a Subscriber can group DataReaders together with a common Quality of Service policy.
3.2.7 QUALITY OFSERVICE POLICIES
The Quality of Service (QoS) policies are the set of rules defining how communication is handled. For example how much data should be stored, if it should be sent reliably, or how long a message should stay valid in a specific communications channel.
3.3 REAL-TIME SYSTEMS
Real-time systems are systems that require a response to an input to be available within a certain and finite time-frame without fail[22]. For example a breaking system in a car is a real-time system;
the breaks have to respond to the breaking pedal within a certain very small time-frame otherwise a crash can happen. Industrial robots are also real time systems. They have to be able to perform their tasks in the production within a given time-frame, otherwise the production can be held up.
Latency is an important concept in real-time systems that relates to how fast an action gives a response. Latency can be defined in different ways depending on the system that is discussed. In this thesis latency is defined to be the round trip time (RTT) from when a message is sent by node A
to a node B to when the message, being echoed at node B, is received by node A again. Maximum jitter is defined as the difference between the maximum and minimum latency of a communications channel.
3.4 MACHINE LEARNING
The scientific field of machine learning is the field that studies computer programs which get auto- matically better at performing a task by analysing data regarding the task or experience from per- forming the task instead of being explicitly programmed how to perform the task[23].
3.4.1 SUPPORT VECTOR MACHINE ALGORITHM
The support vector machine (SVM) algorithm is a supervised machine learning algorithm. Super- vised machine learning is when the learning algorithms starts out with labelled data for that it anal- yses so that it can fit new data to the labels as well as possible. In principle what the SVM algorithm does is that it takes a training set of data (with features, for example data regarding birthmarks) and labels (for example malignant cancer or non-malignant). The labels are first translated to numbers, for example 1 for malignant cancer and 0 for non-malignant cancer. Then the algorithm minimizes a function of the samples in the set over a parameter vectorθ. The function a linear support vector machine minimizes is:
minθ C
m
X
i =1
hy(i )cost1(θTx(i )) + (1 − y(i ))cost0(θTx(i ))i +1
2
n
X
j =1
θ2j (3.1)
where C is a constant, m is the number of samples in the training set,θ is the parameter vector, y(i ) is the label for sample i , x(i )is the feature vector of sample i , n is the number of parameters, and the cost functions can be seen in Figure 3.3.
Figure 3.3: Cost functions for support vector machines.
Using the calculated values ofθ and Equation 3.2 the label of a new sample can be estimated.
y =
(0, if θTx ≥ 0
1, if θTx < 0 (3.2)
Often samples cannot be separated by a linear classifier. To solve this problem another set of fea- tures can be used. Instead of using the features x, features f that measure the similarity between the features x of a test sample and certain points, lets call them l , in the data space can be used. These points are chosen as the feature points x of the samples in the training set. The similarity feature f can be thought of as a measure of the distance between x and l in the data space. The similarity fea- tures f can be calculated in different ways and is called a kernel. One common kernel is the Gaussian kernel. It is calculated as
fi= exp µ
−||x − l(i )||2 2σ2
¶
(3.3) The formula for calculating the parameter vector is then altered to become
minθ C
m
X
i =1
h
y(i )cost1(θTf(i )) + (1 − y(i ))cost0(θTf(i ))i +1
2
n
X
j =1
θ2j (3.4)
and the label estimated using
y =
(0, if θTf ≥ 0
1, if θTf < 0 (3.5)
3.5 HARDWARE
The hardware used was two industrial robots with respective controllers, a network switch, and 3 PCs.
3.6 SOFTWARE
In this section the software is presented.
3.6.1 ROBOTSTUDIO
Robot Studio is a simulation tool and offline programming environment made by ABB for their robots.
It can simulate both the robots themselves and the robot controllers. It can also be used to simulate communication with programs outside of the simulation environment. It was used extensively to simulate the prototype and was also used in the future scenario simulation.
3.6.2 DDSMIDDLEWARE
The DDS middleware used in this thesis work is the [REDACTED] middleware made by [REDACTED].
It is a middleware created to make communication in complex systems easier. It is made to be ro- bust, scalable, and flexible because it works on many different hardwares and using many different programming languages.
3.6.3 ROBOT CONTROLLER OPERATING SYSTEM
The robot controllers run the VxWorks operating system. VxWorks is an embedded real time oper- ating system made by WindRiver. VxWorks was first released in 1987 and is now the most widely deployed real time operating system. It is used in embedded systems in industries that require secu- rity, determinism, and real time performance.
4 DESIGN AND IMPLEMENTATION
In this chapter the design and implementation of the prototype and the future scenario simulation are explained.
4.1 PROTOTYPE DESIGN AND IMPLEMENTATION
In this section the requirements on the prototype are first stated and then the design and implemen- tation are explained.
4.1.1 FUNCTIONAL REQUIREMENTS
The prototype system should be able to do the following:
1. There should be one robot that picks up a box at a predefined position and puts it down at a random position within a collaboration area.
2. The robot should move back to its starting position and communicate the new position of the box to another robot.
3. The other robot should then perform the same task and send the new position of the box back to the first robot.
The robots should also be able communicate position of the box and the time it takes to perform one cycle to an external application.
4.1.2 NON-FUNCTIONAL REQUIREMENTS
The non-functional requirements were taken from a requirements report made by ABB. Two of the requirements were:
• The communication between the robots should be reliable.
• The RTT latency should be less than 1000ms.
There were more requirements but they are removed from this thesis due to company confiden- tiality.
4.1.3 HARDWARE SETUP
Two industrial robots were placed facing each other on a table (see Figure 4.1). Between them was a marked area called the collaboration area and a box called the work object. The robots were con- nected to industrial robot controllers (RCs) and the RCs in turn were connected to a switch. Also connected to this switch was a PC.
Figure 4.1: Prototype hardware setup
4.1.4 SOFTWARE DESIGN
Three different programs were developed. The software architecture can be seen in Figure 4.2. Two programs were developed for the RCs. The reason behind this was that to control the robots a pro- gramming language developed by ABB called RAPID had to be used. However there was no support for that language in the specific DDS middleware. Thus there was one program written in RAPID that controlled the robots. This program then exchanged information, via a socket connection, with a second program in the RC written in a language that the middleware had an API for (C++). A third program, a supervising program, was developed for the PC connected to the same network that the RCs were connected to. This program communicated with the RCs by using the DDS middleware.
The point of the supervising program was to display information that the RCs were sending.
Figure 4.2: Prototype software design
The program written in RAPID to control the robot was called the "robot control program". When it was started it initialized a socket communication (for which it was the server) with the "DDS module"
(the program written in C++ handling the DDS communication). Then, if it was the robot control program in the robot that was supposed to start the work cycle, it controlled the robot to pick up the work object. It then moved the work object to a random location in the collaboration area and sent the coordinates (and cycle time) to the DDS module. When that was done the robot control program waited for the DDS module to pass on new coordinates of the work object that it had received from the other RC. The robot control programs on the two different RCs were the same except for the small difference that one of them were changed so that it picked up the work object first at the start position and sent the cycle time whereas the other started by waiting for coordinates and sent no cycle time data.
The DDS module had to be started manually after the robot control program started. When the DDS module was started it initialized the socket communication with the robot control program.
It also initialized the DDS communication. It then waited for coordinates from the robot control program. When it got the coordinates it published them to a Topic called "RobotXY" that was of a type defined as
s t r u c t robotXY {
long id ; //@key s t r i n g <128> x ; s t r i n g <128> y ; } ;
where the id was a unique id for each robot. The DDS modules also subscribed to the same Topic but used a filtered Topic. This enabled the DDS modules to only subscribe to the coordinate data that was being published by the robot it was collaborating with, and not its own.
The DDS module in the RC that started handling the work object also expected a cycle time value to be sent from the robot control program. When the module got the cycle time value it published it to a Topic called "CycleTime" that was of a type defined as
s t r u c t cycleTime {
s t r i n g <1024> key ; //@key s t r i n g <1024> value ; } ;
where the name "Robotgroup 1" was used as the key and the cycle time was the value. When the DDS module had received and published all data from the robot control program, it waited for data to be published by the DDS module in the other RC.
The third program was a supervising program. It was written in C# to make integration with cloud services easier. It could be started and shut down without affecting the other two programs. When it started it set up DDS subscribers to subscribe to both the "RobotXY" Topic and the "CycleTime"
Topic. It then opened a console window and presented the data that was being published by the DDS modules.
4.2 FUTURE SCENARIO SIMUL ATION DESIGN AND IMPLEMENTATION
Part of the goal of this thesis was to study how DDS and IIoT could be used in the future. In this section some possible future scenarios are first described. Then parts of the underlying requirements of one chosen future scenario are presented. Lastly the design and implementation of a simulation based on these requirements are described.
4.2.1 FUTURE SCENARIOS
Presently, most industrial robots are not collaborating or sharing information in a larger capacity.
Data from robots installed in the factories is usually not collected and aggregated by robot manu- facturers. In the future when the industrial robots are connected to more sensors, each other, and the internet, and data they produce collected and analysed, many new possibilities arise. One future scenario could be:
• Improved data storage and analysis: The cloud could be used to store, analyse, and share large amounts of data.
9 more scenarios were suggested to ABB but are removed in this report due to company confidential- ity.
4.2.2 REQUIREMENTS
The "Improved data storage and analysis" scenario was chosen to be partially implemented as a proof of concept in a simulation. The resulting requirements were that:
1. the simulation should provide added analysing capabilities.
2. the analysis should be performed in the cloud or a local server.
4.2.3 SIMUL ATION OVERVIEW
To showcase the required capabilities a simulation of an end stage of a production line was created.
The earlier stages in the production line had created boxes. There were three different classes of boxes where each class of box had different dimensions (see Table 4.1 and Figure 4.3).
Table 4.1: Sizes of the different classes of boxes
Class x-length [mm] y-length [mm] z-length [mm]
1 250 200 280
2 180 360 150
3 400 290 210
Figure 4.3: Dimensions of the boxes
The earlier stages in the production line had also introduced a variance in the box dimensions. If any of the dimensions was 10 mm larger or smaller than the defined size of the class the box belonged to, it was said to deviate too much in size and thus be faulty.
What the simulation of end stage of the production line was then supposed to do was to scan arriving boxes and and put them on different pallets depending on which class they belonged to and whether they were good or faulty.
To fulfil the improved analysis requirement it was decided to implement a machine learning algo- rithm. The machine learning algorithm was to be implemented in an application running on a local server and to communicate with the rest of the simulation using DDS.
4.2.4 SIMUL ATION DESIGN AND SETUP
The simulation was designed in RobotStudio. In the simulation (see Figure 4.4) there was a conveyor belt where the boxes came out of a machine at one end. The boxes then passed a scanner which scanned the box (this could simulate scanning the box itself or scanning a smart tag attached to the box) and published (see Figure 4.5) the size and weight data of the box to a Topic called "PalletData"
of type called palletData which looked as follows:
s t r u c t palletData { long id ; //@key
s t r i n g <255> product_type ; double x_length ;
double y_length ; double z_length ; double weight_g ; double t o x i c i t y ; } ;
Figure 4.4: Simulation created in RobotStudio
Figure 4.5: Overview of the communication in the future scenario simulation
On a second computer another program subscribed to that data. This program had implemented a machine learning algorithm using the python module scikit-learn [24]. The algorithm was trained on a generated set of 33000 examples of good and faulty boxes before the start of the simulation. When the program received data regarding a box it calculated which class the box belong to and whether it was faulty or not. When the box had been classified the program published data to a Topic called
"BoxTopic" and was of a boxData type which looked as follows:
s t r u c t boxData {
long id ; //@key long c l a s s ; long good ; double box_no ; } ;
A palletizing control program in the first machine subscribed to both the "BoxTopic" Topic and the
"PalletData" Topic. This program was run outside of the simulation running on the same computer.
However, because of its design it did not need to run on the same computer and could thus be re- garded as running on a "local server" for the purpose of this proof of concept. This program checked the data regarding the boxes that had been received from both the scanner in the simulation and the machine learning program. If a box was labelled as faulty by the machine learning program, the palletizing program controlled one of the robots to put it on one of three pallets depending on the class of the box. If the box on the other hand was labelled as good the palletizing program controlled the other robot to put it on one of set of pallets for faulty boxes.
5 EVALUATION
In this chapter the experiments and measurements of the prototype and the simulation are presented and evaluated.
5.1 PROTOTYPE PERFORMANCE EXPERIMENT
In this section the experiment setup, measurements of real-time characteristics, and evaluation of the prototype are presented.
5.1.1 PROTOTYPE PERFORMANCE EXPERIMENT SETUP
The setup of the experiment was similar to the setup of the prototype (which can be seen in Figures 4.1 and 4.2). The difference was that in the performance experiment no instructions were sent from the robot controller to the robot itself since only the communication between the robot controllers were of interest. The robot controllers were connected to the switch with ethernet cables. When the direct socket communication was measured, the robot control programs communicated directly with each other and the DDS modules were not used. When measuring the latency of the original direct socket-based communication as a reference to the DDS communication, the following were the steps (see Figure 5.1) in getting the measurements
1. A timer (using clk-functions in the RAPID API) was started in the robot control program on one of the robot controllers (RC1).
2. A message of a specified size was then sent from RC1 to the other robot controller (RC2) via socket-based communication.
3. RC2 echoed the message back to the RC1.
4. Steps 2 and 3 were repeated 10 times.
5. After the last message was received at RC1 the timer was stopped and the time recorded.
6. Steps 1-5 were repeated 1000 times each for sizes of the messages varying from 1 to 1000 bytes in 10-byte steps (101000 times total).
Figure 5.1: Steps in the socket measurement
The reason for sending of the message 10 times in step 4 was because the resolution of the timer was 1ms and a round trip took roughly 0.5ms for a 1 byte message and thus the resolution is too low to measure single latencies with any accuracy. Since this measurement only gives an average of 10 messages, no worst case latency can be found. The reason behind the choice in message size was that the maximum variable size in RAPID is 1024 bytes. The variable type used was rawbyte data type and the reason behind using this is that the maximum size of a string in RAPID is 80 bytes.
When the socket-based communication had been replaced with a DDS-based communication the latencies could be recorded in the DDS module which had access to a more accurate clock. Because of this there was no need to record 10 latencies at the time and thus accurate worst case (maximum) latencies could be found. The Topic used to communicate the data was of a type defined by:
s t r u c t stringType {
s t r i n g <1024> key ; //@key s t r i n g <1024> value ; } ;
where the id of the robots were stored in the key variable so that the DDS modules could filter the Topic on the id of the robot. The payload was stored in the value variable.
Disturbances were introduced to show how the DDS-based communication reacted to scaling and stress to the system. The disturbances (flooding the system with messages and having an increasing amount of subscriber to the information the robots publish) were added to the system by two com- puters connected to the switch. The steps in the measurements (see Figure 5.2) for the DDS-based communication were as follows:
1. A timer (using vxworks sysTimestamp functions) was started in the DDS communication mod- ule on one of the robot controllers (RC1).
2. A message of a specified size was then published via DDS by the communication module in RC1 and received by the subscribing communication module on the other robot controller (RC2).
3. Then the message was passed on to the robot control program in RC2 via direct socket com- munication.
4. The message was then echoed back to the communication module.
5. When the communication module in RC2 received the echoed message it published it to the data space.
6. The communication module in RC1, having subscribed to a filtered topic with RC2’s id as filter, received the message and passed it to the robot control program in RC1.
7. The robot control program echoed the message back to the communication module.
8. When the communication module in RC1 received the message the timer was stopped and the time recorded.
9. Steps 1-8 were repeated 1000 times each for sizes of the messages varying from 1 to 1000 bytes in 10-byte steps (101000 times total).
Figure 5.2: Steps in the DDS measurement
5.1.2 PROTOTYPE PERFORMANCE MEASUREMENTS
The resulting measurements of the prototype experiment can be found in the following graphs and tables.
MEASUREMENT OF THE SOCKET-BASED COMMUNICATION
The original direct socket communication was measured first as a baseline. The reason for this was that it was the communication strategy that was currently used and was going to replaced. The mea- surement values and a least-squares fitted line can be found in Figure 5.3. In the figure it can be seen that it takes roughly 0.6ms to send and receive a message using direct socket-based communica- tion. It can also be seen that the latency increases by 25% when increasing message size 1000 times.
The reason there are quantized steps of measurements is because of the low resolution of the RAPID timer. An increase in latency with message size is also to be expected since there simply is more data that needs to be transferred.
Figure 5.3: Measurement of the latency (round trip time) for the socket-based communication between two RCs for different sizes of the messages.
MEASUREMENT OF THEDDS-BASED COMMUNICATION
Next the DDS-based communication was studied. The quality of service (QoS) policy used was a reliable policy set to save the most recent sample at each publisher. The reason why this experiment was important was that these were the settings that were going to be used for the information sharing in the prototype. That is because it is crucial that no information sent from one robot to the other gets lost, so the information transfer has to be reliable. The measurements and a least-squares fitted
line can be seen in Figure 5.4. The average latency can be seen to be around 2ms but varies between roughly 1.5ms and 3.5ms.
Figure 5.4: Measurements of the latency for messages, of size varying from 1 to 1000 bytes, sent from one RC via DDS-based communication with a reliable QoS to the other RC and back.
COMPARISON BETWEEN THEDDS-BASED AND SOCKET-BASED COMMUNICATION
Figure 5.5 and Table 5.1 have been constructed to highlight the differences between the original di- rect socket communication and the replacement DDS-based communication. It can be seen that the average latency of the DDS communication is roughly 3.5 times as large as the one for the direct socket communication. The standard deviation in measurement values is also much larger for the DDS communication. Part of this is probably due to the measured latencies of the socket communi- cation being an average over 10 messages sent, whereas every DDS measurement is a single RTT, and the deviation is naturally lower for an average. Part of the reason could also be that the DDS message is passed through a longer path with extra layers where the wait sometimes is longer and sometimes shorter, which also leads to larger jitter. Jitter is bad when dealing with a real time systems because it increases worst case response time and decreases maximum utilization.[25][26]
Figure 5.5: Comparison of the latency measurements between DDS-based communication and direct socket communication.
Table 5.1: Comparison of the DDS-based and the direct socket based communication strategies.
Communication strategy
Average latency [ms]
Standard deviation [ms]
Minimum latency [ms]
Maximum latency [ms]
Maximum jitter [ms]
Socket-based 0.590 0.083 0.4 1.1 0.7
DDS(reliable QoS) 2.069 0.400 1.470 4.119 2.649
COMPARISON OF THEDDS-LINK AND THE INTERNAL SOCKET
In the DDS-based communication experiment there were four programs running, two in each robot controller(see Figure 4.2). The DDS-link between the DDS modules, and the internal socket com- munication between the robot control program and the DDS module in a single RC, are measured separately to locate where most of the delay occurred. This can be seen in Figure 5.6 and Table 5.2. It can be seen that on average the internal socket has a lower latency but it has a larger standard devia- tion and a higher maximum latency. The lower average latency is expected because the information does not have to go via the network to another machine. It is speculated that the larger maximum latency could be due to two possible reasons. The first reason is that the internal socket communi- cation might have a lower priority, and is thus pre-empted by a larger number of tasks. The second reason is that since the internal socket was quicker on average than the DDS-link there might be a
buffer gets full and thus slows down a message. It also has to be taken into account that when send- ing information from one robot control program to the other the DDS-link is only used once whereas there is one internal socket used in each of the RCs. This means that the internal socket communi- cation takes more time in total than when the message is sent over the network via DDS-link.
Figure 5.6: Comparison of the latency measurements for DDS-link and internal socket.
Table 5.2: Comparison of the DDS-link and internal socket.
Communication strategy
Average latency [ms]
Standard deviation [ms]
Minimum latency [ms]
Maximum latency [ms]
Maximum jitter [ms]
Only internal
socket 0.637 0.592 0.232 3.640 3.408
Only DDS-link 0.858 0.356 0.520 3.016 2.495
COMPARISON BETWEEN A RELIABLE AND AN UNRELIABLEQOSPOLICY
The next experiment was a comparison between a reliable and an unreliable QoS policy. The reason it is interesting to look at an unreliable form of communication even though it should not be used for crucial information is that it could still be used to send information to systems where it is not neces- sary to always have the latest information. For example if an information system displays how many items are created by a robot, and the robot creates new items very fast, it does not matter if an update
is missed since a new message will be sent soon and the system only serves to give an overview of number of items finished. In Figure 5.7 and Table 5.3 a comparison between the measurements for unreliable and reliable QoS can be found. It can be seen that the average latency of the reliable com- munication is slightly higher which is to be expected since the reliability gives some added overhead.
It can also be seen that the standard deviation is higher in the reliable case. This is also to be expected since the unreliable communication just sends the messages off but the reliable communication has to take care that sometimes it has to resend messages and sometimes not. However in this system, with few disturbances and where messages are seldom lost, the difference between unreliable and reliable communication is small.
Figure 5.7: Measurement of the latency for the DDS-based communication between two robot controllers for dif- ferent sizes of the messages and reliable vs unreliable communication.
Table 5.3: Comparison between the reliable and unreliable QoS policies.
Communication strategy
Average latency [ms]
Standard deviation [ms]
Minimum latency [ms]
Maximum latency [ms]
Maximum jitter [ms]
DDS(reliable QoS) 2.069 0.400 1.470 4.119 2.649
DDS(unreliable
QoS) 1.937 0.207 1.509 4.026 2.516
