Bachelor De gree Project CLOUD-BASED MONITOR AND
CONTROL OF INDUSTRIAL ROBOTS
Bachelor Degree Project in Automation Engineering Bachelor Level 30 ECTS
Spring term 2021 Ander Biain Galdos Iñaki Ordoki Oiarbide Supervisor: Victor Igelmo Examiner: Anna Syberfeldt
2 Abstract
Nowadays, interconnectivity is becoming increasingly important. According to industry, the Industrial Internet of Things (IIoT) is the core technology of Industry 4.0. Connectivity between different processes or components in the industry makes one process aware of each other, making systems more intelligent and self-sufficient. This thesis proposes various ways to control and monitor an industrial process with the cloud, explaining step by step the connections between the industrial equipment and the cloud. Furthermore, this thesis's one sub-objective is to make an industrial process, which was previously PLC-based, entirely cloud-based. For the latter work, simulation software is used to create a production line, as there is a lack of equipment. Consequently, it will also test the flexibility of the system to move between the virtual and the real environment, which is another challenge of Industry 4.0 and digitalisation.
In the discussion part, the thesis talks about the shift from PLC-based to PC-based systems in the industry, mentioning the limitations and advantages.
Keywords: Cloud-based systems, Industrial Internet of Things, Industry 4.0.
3 Acknowledgements
First and foremost, we would like to thank our supervisor Victor Igelmo for always being willing to help and motivate us during the project.
On the other hand, we also wanted to thank the University of Skövde for giving us a working place like ASSAR with all the facilities and equipment we needed.
Finally, thanks to our families and friends who have been there within good and bad moments.
Skövde, June 2021
Ander Biain Galdos and Iñaki Ordoki Oiarbide
4 Certificate of Authenticity
This thesis has been submitted by Ander Biain Galdos and Iñaki Ordoki Oiarbide to the University of Skövde as requirement for the degree of Bachelor of Science in Production Engineering.
The undersigned certifies that all the material in this thesis that is not my own has been properly acknowledged using accepted referencing practices and, further, that the thesis includes no material for which I have previously received academic credit.
Ander Biain Galdos Iñaki Ordoki Oiarbide
5 Abbreviations
AGV Automatic Guided Vehicle
AR Augmented Reality
ASCII American Standard Code for Information Interchange
AWS Amazon Web Services
CIP Common Industrial Protocol
CM Cloud Manufacturing
CSP Cloud Service Providers Ethernet/IP Ethernet Industrial Protocol
IIoT Industrial Internet of Things IoT Internet of Things
IT Information Technology
LAN Local Area Network
PLC Programmable Logic Controller
RTU Remote Terminal Unit
SDK Software Development Kit TCP Transmission Control Protocol
UDP User Datagram Protocol
VR Virtual Reality
XMLRPC Extensible Markup Language Remote Procedure Call
6 Table of Contents
1. INTRODUCTION ... 11
1.1 Background ... 11
1.2 Problem Description ... 12
1.3 Aim and Objectives ... 12
1.4 Extent and delimitations ... 13
1.5 Sustainability ... 13
1.6 Methodology ... 14
2. THEORETICAL FRAMEWORK ... 17
2.1 PLC ... 17
2.2 Industrial Communication Protocols ... 18
2.2.1 ETHERNET IP ... 18
2.2.2 MODBUS ... 19
2.2.3 OPC UA... 19
2.3 Collaborative Robots ... 19
2.4 IIoT ... 21
3. LITERATURE REVIEW ... 23
3.1 Cloud Computing ... 23
3.1.1 Levels of Cloud ... 23
3.1.2 Cloud Deployment Models ... 24
3.1.3 Differences of On-premises vs. Cloud. ... 25
3.1.4 Benefits of Cloud Computing ... 25
3.2 Cloud Manufacturing ... 26
3.3 Cloud Robotics ... 27
3.4 Conclusions ... 27
4. SYSTEM ARCHITECTURE ... 29
7
4.1 PLC-Based or PC-Based system ... 30
4.2 PC-Based System ... 32
4.3 PLC-Based control and PC-Based monitor and data analytics ... 33
5. LAB EQUIPMENT ... 35
5.1 Stations ... 35
5.2 Configuration of fieldbuses for the devices ... 36
6. CLOUD PLATFORM ... 39
6.1 Software ... 39
6.2 Data Modelling ... 39
6.3 Monitorisation ... 44
6.3.1 Mashups IRMA ... 44
6.4 Control ... 46
7. SIMULATION SOFTWARE ... 50
8. DISCUSSION ... 54
9. CONCLUSIONS ... 56
9.1 General conclusions ... 56
9.2 Future work ... 56
10. REFERENCES ... 58
Appendix A: Connecting industrial equipment variables to ThingWorx ... 62
Appendix B: MODBUS addresses for UR robots and the inverter ... 67
Appendix C: Widget’s definition and functionalities for mashups in THX ... 68
8 Table of Figures
Figure 1: Venn diagram for sustainability. (Wikipedia) ... 13
Figure 2: Methodology diagram. (Saltuk et Kosan, 2014). ... 15
Figure 3: Basic automated system. ... 17
Figure 4: PLC System. (Bolton, 2006) ... 17
Figure 5:Collaborative robots working in a system ... 20
Figure 6: Worker and the robot working at the same ... 21
Figure 7: Worker having support on the robot for installing a heavy piece. (WEVOLVER, 2020) ... 21
Figure 8: Services of cloud computing. (Azure, 2021) ... 23
Figure 9: System general architecture. ... 29
Figure 10: PLC-Based or PC-Based system Architecture. ... 31
Figure 11: PC-Based system Architecture. ... 32
Figure 12: PLC-Based control and PC-Based monitor and data analytics system Architecture. ... 33
Figure 13: IRMA data model... 43
Figure 14: Menu mashup for IRMA. ... 45
Figure 15: Mashup for the conveyor at IRMA. ... 45
Figure 16: Mashup for the robots at IRMA. ... 46
Figure 17: Previous Sensor Data Change ... 48
Figure 18: Conveyor Sensor Data Change ... 49
Figure 19: Next Sensor Data Change ... 49
Figure 20: Transfer Done Data Change ... 50
Figure 21: Visual Components Model. ... 53
Figure 22: Properties of the THX window in a Kepware project. ... 62
Figure 23: Channels and Devices in Kepware for IRMA. ... 63
Figure 24: Defining the IP Address of a Modbus device. ... 63
Figure 25: Defining the IP Address of the OPC UA server. ... 64
Figure 26: Tag generation in a Modbus device. ... 65
Figure 27: Tag generation in an OPC UA device. ... 65
Figure 28: Connect variables from Kepware to THX. ... 66
9
Figure 29: Button widget. ... 68
Figure 30: Clicked function in the button widget. ... 68
Figure 31: Gauge widget. ... 69
Figure 32: Data function in the gauge widget. ... 69
Figure 33: Toggle button widget. ... 70
Figure 34: State function when Toggle button is working as a LED. ... 70
Figure 35:State function when Toggle button is working as a switch... 70
10 Index of Tables
Table 1: Parameters group number 51 of the inverter ... 36
Table 2: Parameters group number 11 of the inverter ... 37
Table 3: Things and their properties in THX ... 40
Table 4: Thing Shapes, Thing Templates and Things of the UR Robots ... 41
Table 5: Thing Shapes, Thing Templates and Things of the Conveyor ... 42
Table 6: Thing Shapes, Thing Templates and Things of the Sensors ... 42
Table 7: SWOT Analysis of Simumatik ... 51
Table 8: SWOT Analysis of Visual Components ... 51
11 1. INTRODUCTION
In this chapter, the topic that has been worked on in the project will be introduced. First, mentioning the background of this project and the problems that have been encountered to carry out this thesis. In addition, the objectives and the extent and delimitation of this project will be defined. Finally, the project will be analysed from a sustainability point of view and the methodology followed for its execution will be explained.
1.1 Background
During the last years, the world has witnessed a revolution called industry 4.0. The changing dynamics of global production, such as more complex and automated processes, high-level competitiveness, and emerging technologies, have paved the way for a new generation of goods, products, and services. Furthermore, companies are more conscious about the value of the data their processes and products generate (Ustundag and Cevikcan, 2018), as data is fundamental for them to optimise processes or reduce waste. Therefore, such trends will require the convergence of mobile and social devices, the cloud, and Big Data analytics to be successful (Gilchrist, 2016).
Regarding cloud computing, which is one of the topics to be addressed in this thesis, allows organisations to eliminate the capital expense of buying hardware, software and setting up and running on-site datacenters. In contrast, “cost increases with the racks of servers, the round-the- clock electricity for power and cooling, and the IT experts for managing the infrastructure”
(Microsoft, 2016). On the one hand, cloud computing with a public cloud means that users do not have to worry about maintenance and data integrity. According to on-premises configuration, resources are implemented internally and within a company's IT infrastructure.
On the other hand, companies can access services whenever they want and from anywhere with the internet. Finally, computing resources can be scaled as is needed.
Regarding today’s industry, the number of sensors, machines, or smart connected devices is growing in automated systems, so the Internet of Things (IoT) is becoming one of the key enablers in digital transformation. However, there is a term called Industrial Internet of Things (IIoT) at the company level. IoT aims to meet the needs of the general public using electronics that can be integrated into standard devices. Its “essential capabilities are at the level of connectivity and network management, device management, data acquisition, processing
12
analysis and visualisation, application enablement, integration and storage” (i-SCOOP, 2018).
IIoT, on the other side, is the set of sensors, instruments, and autonomous devices connected via the internet to industrial applications. Unlike IoT, it focuses on increasing safety and efficiency at production sites. It provides remote access to machinery and all the data of these machines. Therefore, this concept is closely related to Industry 4.0. Some of the benefits of IIoT are increasing efficiency as there is the ability to automate operations. Besides, it allows companies to do Big Data and data analytics, optimising their operating efficiency, reducing errors and costs as the company get more knowledge. Also, it offers predictive maintenance capabilities, consistently monitoring the machinery and improving safety monitoring the workplace (Mendoza, 2020).
1.2 Problem Description
The current rapidly changing market is causing an exponential complexity to increment of manufacturing lines. With new features such as Augmented Reality (AR) or Virtual Reality (VR), flexible solutions are becoming more important to allow companies and institutions to catch up with customer requirements. In those new technologies, the virtual environment and the real one are connected. The use of the cloud makes the relationship between both more flexible. There are still automated processes controlled classically. All the industrial components are connected to a central controller. Data is not accessible in the cloud, so it cannot be accessed remotely. This can lead to a lack of flexibility. Also, the data exchange between both environments is not as fast and flexible.
Regarding virtual environments, “virtualisation helps companies work more efficiently compared to traditional workflows” (Khulna University of Engineering & Technology, 2018).
For that reason, cloud-based systems are suitable for the described systems.
1.3 Aim and Objectives
This project aims to design, test, and demonstrate cloud-based control using an IIoT platform.
To achieve this aim, some objectives have been defined:
- Demonstrate the capabilities of IIoT platforms to reliably monitor and control low-level industrial processes.
- Design and create reliable mashups (web-based visualisation and control) for each robot and the manufacturing line.
13
- Implement certain functionalities difficult to carry to implement using traditional automation systems.
1.4 Extent and delimitations
The lab equipment available for the project is of natural reasons limited. To overcome this limitation simulation software will be used to evaluate more complex systems. In addition, the learning process of these simulation software and the design of virtual models for for the evaluation of more complex systems will take time, so will limit all the work around the IIoT platform.
1.5 Sustainability
Sustainable development is the idea that human societies should live and meet their needs without compromising the ability of future generations to meet their own needs. Sustainable development is a way of organizing society so that it can exist in the long term. Considering both present and future imperatives, such as the preservation of the environment and natural resources or social and economic equity (Youmatter, 2021).
To get the balance, the social, environmental, and economical sustainability have been analysed.
Figure 1: Venn diagram for sustainability. (Wikipedia)
- Environmental sustainability: From an environmental point of view, sustainable development aims to achieve a balance between the consumption of human resources and the regeneration of natural resources (IISD, 2021).
14
When it comes to an engineering project, you need to use as few resources as possible to avoid unnecessary waste. In this thesis, the PLC controllers and the I/O modules would be removed, so less material will be used in this kind of systems.
- Economic sustainability: As the name says it, this type of sustainability has its focus on the capital. Its aim is to ensure that the resources are conserved for future generations.
The way of achieving this is by having a slower or equal rate of consumption than the production and regeneration of resources.
First, to use IoT platforms all components have to be smart, enabling the connection to it. So, if the components are not smart, a change is required in the company. In addition to that, the IoT platform has a big cost that have to be invested in the beginning of the change. However, thanks to the Big Data, the power consumption will be analysed, and it would be easier to lower the consumption cost.
- Social sustainability: The main objective of the social sustainability should be the constant research of a future liveable community.
This thesis will be developed in a way that the basic social values are respected, by the evasion of any type of information that is believed to be harmful for ethnical, economic, social, gender related or sexual reasons.
1.6 Methodology
The project's general goal is to create a system that controls and monitors a manufacturing line composed of three robots and a conveyor belt through the cloud. To achieve this goal, several steps have been followed. In this chapter, the reader can find the research methodology used to address the dilemma that has inspired the present study. The guidelines required to achieve the objectives of this project will be provided by the proposed method in the following paragraphs.
Oates (2005) explained that a research strategy called Design and Create is often followed for IT product development. Any researcher following this strategy aims to develop a product as a contribution to knowledge. The method consists of five main steps: awareness, suggestions, development, evaluation, and conclusion. All these steps had to be completed to achieve the objectives. Besides, none of them could be omitted until the previous one was completed. As an iterative and fluid system, being one of the steps already completed, it could be repeated if
15
the process was not done correctly or if the research could be improved. In this way, the thesis has been looking for constant improvement. Figure 2 shows the used method diagram.
Figure 2: Methodology diagram. (Saltuk et Kosan, 2014).
In the “Awareness” stage, the problem is recognised. This can be translated into the study and development of the Theoretical Framework and Literature Review, obtaining a better understanding of the different research fields covered by this project.
Once the “Awareness” step has been completed, it is time to develop the “Suggestions” step.
This step is based on deciding how the project can be managed. It is essential to conduct brainstorming to generate as many ideas as possible. Once all the proposals are on the table, a tentative design is made. This is to see if it is possible to develop the whole project. So, this stage has decided what device or process will be controlled and monitored in this project. But also, which is going to be the level of them for each. In addition, industrial communication protocols that might be used are going to be named.
The “Development” stage begins when the tentative idea is demonstrated to be feasible and consists of implementing this idea into a proposed computing artefact. This project means that once the control and monitoring idea is shown to be possible for the cloud software and industrial communication protocols, it is then studied in detail and implemented for the final solution in the Development stage.
16
Next comes the “Evaluation” of the artefact. This step analysed the results established at the beginning of the research once the artefact is built. So, it proved if the system could control and monitor the process at the level that was defined previously. Also, get information from all the results obtained for the discussion. Then, a validation of the project can be made. Everything tested individually or at a lower level will be tested thoroughly in this stage.
The “Conclusion” stage covers all the knowledge gained at the end of this research. This stage is where the results are consolidated, and future work is identified for future research.
17 2. THEORETICAL FRAMEWORK
In this chapter, all the theory that has been used in the thesis will be explained.
2.1 PLC
In every automated system, it can be distinguished four types of components: sensors, actuators, industrial controllers, and the process or system. A PLC is the most frequent type of industrial controller implemented in automated processes. “It is a special form of microprocessor-based controller that uses programmable memory to store instructions and implement functions such as logic, sequencing, timing, counting and arithmetic to control machines and processes”
(Bolton, 2006). Therefore, PLC’s primary purpose is to manage the signals obtained from the sensors, do some functions according to the implemented logic and then send instructions to the actuators.
Figure 3: Basic automated system.
“Typically, a PLC system has the basic functional components of processor unit, memory, power supply unit, input/output interface section, communications interface and the programming device” (Bolton, 2006).
Figure 4: PLC System. (Bolton, 2006)
18 2.2 Industrial Communication Protocols
In today's industry, automation systems use different industrial communication protocol solutions. Referring to fieldbuses in factory automation, these can be divided into traditional (PROFIBUS, MODBUS-RTU…), Industrial Ethernet (ETHERNET IP, PROFINET, MODBUS-TCP…) and to a lesser extent Wireless technology (Bluetooth, Wi-Fi…). Besides,
“Industrial Ethernet has been growing faster than traditional fieldbuses for several years and has now overtaken fieldbuses” (Anybus, 2018).
A traditional fieldbus is a digital data bus that enables real-time connection and communication of controllers, sensors, and actuators. It could be considered as the means to create a network between the different devices. Already in the early 1970s, the first fieldbuses were installed and used. However, standardisation work did not begin until the mid-1980s (Felser, 2002).
To meet the needs of the industrial environment, “Industrial Ethernet essentially uses special industrial protocols encapsulated within the Ethernet protocol in a way that ensures the correct information is sent and received when and where it is needed to perform a specific operation”
(FlukeNetworks, 2018). Compared to the commercial Ethernet LAN, the speed of Industrial Ethernet is much lower. However, the cables are more robust to withstand the harsh conditions of a production plant.
On the other hand, OPC UA works alongside the protocols mentioned above regarding the connectivity between different networks. Apart from communication between field devices and controllers, it focuses also on different network communication.
After an overview of communication protocols, three of the most popular ones will be explained: ETHERNET IP, MODBUS, and OPC UA.
2.2.1 ETHERNET IP
It is the finished product of four organisations that joined forces in its development and dissemination for industrial automation applications: The Open DeviceNet Vendor Association (ODVA), the Industrial Open Ethernet Association (IOANA), Control Net International (CI), and the Industrial Ethernet Association (IEA). The exchange of information is carried over TCP or UDP. The application layer is represented by CIP, which “provides standards services for device control via network messages” (Mallet Ribeiro et al., 2014).
19 2.2.2 MODBUS
Now known as Schneider Electric, Modicon created this standard industrial protocol in the late 1970s for communication between PLCs. It is an optimised protocol that guarantees fast Ethernet data transmission. A manufacturer-independent data structure enables the communication between devices from different manufacturers. In addition, it is based on a master/slave or client/server architecture (WAGO, 2020).
The operational modes of data transmission are as follows:
- Modbus TCP: Ethernet TCP/IP communication based on client/server model.
- Modbus RTU: Establishes serial master/slave communication via RS-232 or RS-485.
- Modbus ASCII: Similar to RTU protocol except for a different data format; relatively little used.
2.2.3 OPC UA
Open Platform Communication (OPC) is a standard for securing information in industrial automation and other industries. And when among other things, as new safety regulations came in, OPC Unified Architecture (UA) was created.
“The OPC UA, released in 2008, is a platform-independent service-oriented architecture that integrates all the functionality of the individual OPC Classic specifications into one extensible framework. It provides the necessary infrastructure for interoperability across the enterprise, from machine-to-machine, machine-to-enterprise, and everything in-between” (OPC Foundation, 2021).
Apart from that, “Innovative technologies, and methodologies such as new transport protocols, security algorithms, encoding standards, or application-services can be incorporated into OPC UA while maintaining backwards compatibility for existing products” (OPC Foundation, 2021).
2.3 Collaborative Robots
Robots are programmable automatic machines capable of performing certain operations autonomously and replacing human beings in specific tasks, particularly heavy, repetitive, or dangerous ones. They can be equipped with sensors, which enable them to adapt to new situations. Depending on the characteristics and requirements of the process, different types of
20
robots can be used in the industry. In this case, the three robots to be adapted to cloud-based monitoring and control are collaborative robots. Universal Robots (UR) is the manufacturer of these robots, and the models used are UR3, UR5, and UR10e. These robotic arms have six joints, and the number in the name of each robot indicates the maximum load, in kilograms, it can carry.
Universal Robots' robotic arms can work in two ways to perform tasks:
- By communicating with other equipment, peripherals, or controllers: Robots share tasks with other robots, external equipment, and peripherals involved within the production process (PLC, CNC, conveyor belts, etc.). The communication methods used by UR are PROFINET, ETHERNET IP, TCP/IP, XMLRPC, and MODBUS.
Figure 5:Collaborative robots working in a system with other equipment. (Esemanal, 2019)
- Collaborating with workers: The modes of collaboration can be very diverse, from working together in the same product where the robot carries out ergonomically unfavourable tasks using the robotic arm to support installing heavy parts. Collaborative robots are designed to work alongside people thanks to their certified safety systems.
21
Figure 6: Worker and the robot working at the same part in the same product. (WEVOLVER, 2020)
Figure 7: Worker having support on the robot for installing a heavy piece. (WEVOLVER, 2020)
Robots can be programmed in two ways: online or offline. The first consists of programming the robot physically. This way is usually used to make small changes to the code, as production is stopped during this time. On the other hand, offline programming is carried out in the virtual environment. The latter is used to make different simulations of the process, some more significant changes, or experiment with the robot.
2.4 IIoT
IIoT is the integration of machine sensors, middleware, software, cloud computing, and storage systems in the industrial process of companies, (Hernandez-de-Menendez, Escobar Díaz and Morales-Menendez, 2020). This technology generates multiple production-related data points
22
to the company, so it can be used for analytics or support for decision-based operations. IIoT platforms can also increase efficiency and connectivity through automation operations.
“The IIoT refers to the extension and use of IoT in industrial sector or applications. With a strong focus on machine-to-machine (M2M) communications, big data, and machine learning, IIoT enables industries and enterprises to have better efficiency and reliability in their operations. The IIoT encompasses industrial applications, including robotics, medical devices, and software-defined production processes” (TrendMicro, 2021). IIoT can do this thanks to the internet connection, which allows the machines to connect between them to get data for various tasks, such as optimization and maintenance.
An advantage of this technology is that it can interact with an object within a specific environment and immediately answer if a change happens. IIoT has the potential to give more efficiency, productivity and to reduce costs (Hernandez-de-Menendez, Escobar Díaz and Morales-Menendez, 2020).
Talking about the IIoT, it is important to define what a Thing is. The IIoT describes the industrial network of physical objects, Things, that "are embedded with sensors, software, and other technologies for the purpose of connecting and exchanging data with other devices and systems via the Internet" (Oracle, 2021).
23 3. LITERATURE REVIEW
In this chapter, a search of different papers related to the topic of this project has been made and recent research has been identified.
3.1 Cloud Computing
The first time that the cloud appeared was with John McCarthy when in 1960, he wrote a paper.
He said that the internet and cloud would be as essential as electricity (McCarthy, 1960). In 2002, Amazon Web service started providing storage and computation. In 2007 companies like Google or IBM began researching cloud technology, and in 2009, Google started to provide cloud computing services. Nowadays, everybody is using cloud computing services in their daily life. Examples of this are Google Drive, OneCloud, or iCloud (Srivastava and Khan, 2018).
3.1.1 Levels of Cloud
There are three different levels of the cloud: Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS) (Azure, 2021).
Figure 8: Services of cloud computing. (Azure, 2021)
- IaaS: It is an instant computing infrastructure, provisioned and managed over the internet. IaaS quickly scales up and down with demand, only letting pay for what use.
It helps avoid the expense complexity of buying and managing your physical servers and other data centre infrastructure. Each source is offered as a separate service component, and only need to rent a particular one for as long as your need it (Azure, 2021).
24
- PaaS: “It is a complete development and deployment in the cloud, with resources that enable to deliver everything from simple cloud-based apps to sophisticated, cloud- enabled enterprise applications. With this serves the customers purchase the resources they need from a cloud service provider on a pay-as-you-go basis and access them over a secure Internet connection. The user manages the application and services they develop, and the cloud service provider typically manages everything else” (Azure, 2021).
- SaaS: “SaaS allows users to connect to and use cloud-based apps over the internet. The user rents the use of an app for their organisation, and connect to it over the internet, usually with a web browser. All the underlying infrastructure, middleware, app software, and app data are in the service provider’s data centre. The service provider manages the hardware and software. SaaS allows the organisation to get up and running quickly with an app, at minimal upfront cost” (Azure, 2021).
3.1.2 Cloud Deployment Models
There are three main cloud environments, also known as cloud deployment models. Businesses can choose to run applications on public, private or hybrid clouds, depending on their applications:
- Public Cloud: The entire computing infrastructure is located on the Cloud Service Providers (CSP) premises that offer “cloud services over the internet. This is the most economical option for those individuals/organisations that do not wish to invest in IT infrastructure. In a Public Cloud environment, the resources are shared between multiple users called ‘Tenants’”. The cost of using Cloud services is determined by using IT resources consumed, so they have to pay only for their consumed services. (Kale, 2021).
- Private Cloud: Individuals/organisations choosing Private Cloud get dedicated infrastructure that any other individual/organisation does not share. “The security and control level are highest while using a private network. The costs are born by an individual/organisation and are not shared with any other individual/organisation.
Private Cloud management is taken care of by the user, and the CSP does not provide any Cloud management services” (Kale, 2021).
25
- Hybrid Cloud: “The cloud deployment model includes Public Cloud and Private Cloud characteristics. Hybrid Cloud allows the sharing of data and applications between Public and Private Cloud environments”. Organisations mainly use Hybrid Cloud when their On-Premises infrastructure needs more scalability, so they use scalability on Public Cloud to meet fluctuating business demand. “Organisations can keep their sensitive data on their Private Cloud when reaping the power of the Public Cloud” (Kale, 2021).
3.1.3 Differences of On-premises vs. Cloud.
There are several differences between On-premise and the cloud. One select depends on your needs and what you are looking for your situation (Hughes, 2021).
Deployment
- On premises: In a on-premises environment, resources are deployed in-house and within a company's IT infrastructure. An enterprise is responsible for maintaining the solution and all its related processes.
- Cloud: Including the different levels of cloud deployment, in a public cloud domain, resources are distributed across the service provider's premises, while enterprises can access their resources.
Cost:
- On premises: For companies that deploy software on-premises, they are responsible for the costs of running server hardware, power consumption and space.
- Cloud: Companies that choose to use a cloud computing model only pay for the resources used, without the costs of maintenance and preservation, and the price is adjusted accordingly or below the amount consumed.
3.1.4 Benefits of Cloud Computing
Regarding the benefits of cloud computing, three are the main advantages: Cost saving, flexibility, and the enhanced security (Srivastava and Khan, 2018).
26
- Cost-saving: With this technology, the customers only have to pay for the services they use. Apart from that, the maintenance of this technology is very cheap (Herhalt, J;
Cochrane, 2012).
- Flexibility: When doing operations for the companies, a lot of changes come into view.
Sometimes more processes are needed, but other times less. It is essential to have the ability to be changeable, and this happens with cloud computing, changing hardware and resources adjustment.
- Enhanced security: Cloud computing has very high security using strong access controls, key management, security intelligence, and data encryption.
3.2 Cloud Manufacturing
The main objective of controlling and monitoring systems is to increase industrial processes' precision, quality, and performance. Due to rapid technological advances, computerised production control has become a significant player in manufacturing and production companies.
To achieve these goals, implementing the cloud in the industry has been decisive because, to begin with, cloud computing, your work is wherever you have an internet connection. In addition, storage can be unlimited, and it is more secure when saving data. The first mention of the term cloud manufacturing (CM), as Ren et al. (2015) made mention in their research, was created by Li et al. (2010). Ren et al. (2015), explained CM is based on cloud computing, IoT, Cyber-Physical Systems, service-oriented manufacturing, virtual manufacturing, and virtual enterprise.
In more recent research, Ren et al. (2017) cited key characteristics and applications of CM. It states that there are mainly three different users in CM: cloud provider, cloud customer or consumer, and cloud operator. Apart from that, they discuss an example of a cloud manufacturing system under the management of a cloud operations centre. Which is composed of dozens of sub-companies, each involved in a product lifecycle ranging from the overall design, subsystem design, simulation, production, assembly, testing, experimentation, maintenance, project management, etc. Apart from that, Andres et al. (2021) comment that partner companies can exchange information with the help of CM, “irrespective of its origin
27
and nature”. In their research, they introduce a data model for collaborative manufacturing environments.
3.3 Cloud Robotics
The first application integrating the cloud into robotics was for remotely located students to develop and run robots from university labs (Bohus et al., 1996). The authors commented that students could not gain practical experience when they were not at the laboratory in the past.
However, with this new idea, students could be anywhere. Some years later, Jordán et al. (2013) commented a swarm of simple robots and robotic devices would join a Cloud Robotics network, exploiting the advantage of cloud technologies. Besides, they said, “society shall witness the rise of distributed intelligence in robotics that allows the creation of a global database for navigation, mapping, planning task execution and beyond.” They sum up highlighting “the increasing number of robots with up-to-date knowledge will become a true helping hand for humans.”
After this, many robot applications have been developed for different backgrounds and with various purposes. For instance, Wu et al. (2015) built up an application where robots were controlled remotely with the cloud. The remote-control applications running on the cloud server were developed in Microsoft Azure. Besides, some technologies were used to design the human-machine interface. In another cloud robot application, Peake et al. (2016) combines visual cloud-based analysis of a robot environment and derived actions of robots. Employing hand gestures, it interacts with robots using commented cloud-based services. Artificial Intelligence used for the hand gestures is connected to the cloud, and the robot, as it is in the cloud, receives all that information without needing any other connection between them. On the other hand, more recent research commented that this technology was already widely used.
However, it still had a place in the more complex future industry and “may have an important role in the future as a technology which is directed linked to the human, capable of solving society’s problems” (Vojić, 2019).
3.4 Conclusions
Cloud computing has been used for the last years and it is a very useful technology in our daily life. The cloud has enormous strengths, which are scalability and the ability of doing
28
decentralized processes. But in on-premises services, the company must take care of the structure of the cloud and not a third party.
What is very important in the industry is that upgrades are needed, and the problems will appear at any time. For example, it is advantageous to track the maintenance of a machine or a system.
With the cloud, it would be possible to know when to do predictive maintenance from anywhere, not just from the machine screen. This notification could be sent to any computer or even tablet or mobile phone.
Apart from that, connectivity is one of the most important features of cloud computing. It gives the user and the customer the possibility of connecting in real-time to any service or device.
Regarding the costs, one of the most exciting features of the cloud is that the customers only pay for what is using, so if more resources are needed, the only thing to do is roll out more resources and keep working. In contrast, there is a difference in on-premises: the enterprise must be aware of the cost of storage and power consumption. The way of working would not change, but the internal structure necessary to develop the work is not the same.
Within CM, most literature presents the remarkable ease with which the cloud can exchange data either within a company between different processes or between other companies.
Cloud robotics has been used in different areas of industry. Within robotics, apart from control and monitoring the robot, it can control, for example, the vision part.
Finally, most of the literature reviewed agrees that data management in both society and industry will be cloud-based in the future.
29 4. SYSTEM ARCHITECTURE
In any industrial process, it is necessary to decide the level of control, monitoring, and data analytics, if existing, required for the system. In this case, we propose using the cloud at different levels to provide flexibility in the three aspects mentioned.
The system proposed in this project is defined in the following image, where a virtual model in simulation software is at the top, the cloud platform named ThingWorx (THX) in the middle, and below all the actual equipment and process. Apart from that, communication through these levels will be bidirectional, achieving a flexible and complete system. Besides, meeting all the requirements of Industry 4.0 and digitalisation simultaneously.
Figure 9: System general architecture.
As mentioned above, there are different parts in this system, composed of different software and hardware. So, to communicate them, specific interfaces are required, which can read the
30
information and translate it so that the other party can understand it. In this case, there are two interfaces: Kepware and a python script.
Kepware is an industrial gateway that connects the cloud with industrial equipment. It has different drives to transmit information via communication buses like MODBUS, ETHERNET IP, PROFINET or OPC UA. On the other hand, python is used to connect the cloud with the simulation software. For this, first, a REST API is used that can transmit information with THX.
“REST API is an application programming interface that conforms to the constraints of REST architectural style. Where, An API is a set of definitions and protocols for building and integrating application software” (RedHat, 2021).
Regarding simulation software, in the case of Simumatik, as the REST API provides having all the data from THX in python, and Simumatik has an internal python controller, the communication between python and Simumatik is done automatically. The python controller works with industrial UDP protocol. The only thing that has to be modified is the data structure.
As Simumatik works with bytes, all the data got from THX has to be organised in bytes. In contrast, the information that comes in byte form from Simumatik must be split to transmit to the cloud. In the case of Visual Components, it can work as an OPC UA client. Therefore, an OPC UA server is created in python, and information is transmitted to the cloud.
Once the general architecture has been defined, three different ways of controlling, monitoring, and analysing data via the PLC and the cloud are proposed. In this thesis, only the control and monitor part has been studied. But this chapter mentions where data analysis would go in this system. In the first proposal, the option is given to do it both ways, controlling some processes with the cloud and others with the PLC. The same goes for monitoring and data analytics. The second aim is to eliminate the PLC and control monitor and analyse data with the cloud. And finally, the third proposal involves the total control with the PLC and the part of monitoring and data analytics with the cloud. It should also be said that their controller controls the robots, as the robots’ joints angles cannot be accessed from a fieldbus, only visualise them. The control only sends them the information to do the right job in each case.
4.1 PLC-Based or PC-Based system
In this first proposal, the system can be controlled and monitored by the PLC and the cloud, depending on the complexity of each process. In this way, giving an option, if desired,
31
controlling mainly with the PLC, but at the same time keeping all the information of the PLC in the cloud so that it can be used for data analytics, and using Big Data optimise the system.
Total control of the PLC via the cloud is always possible.
Figure 10: PLC-Based or PC-Based system Architecture.
In this proposal, all the equipment is connected to the PLC. In addition, through the OPC UA driver that Kepware has, the PLC is connected to the cloud. So, as the PLC has limited inputs and outputs, it is impossible to store unlimited data.
In IRMA, the inverter that controls the conveyor and the three robots are connected via ETHERNET IP with the PLC, using EDS files (Electronic Data Sheet). All the accessible variables of these components can be read and written from the PLC with EDS files. In this system, the PLC is programmed in CODESYS, automation software for engineering control systems.
32 4.2 PC-Based System
This second proposal is about doing all the control and monitoring with the cloud. In this way, the IIoT platform will replace the PLCs. This option will give flexibility to the system, giving control and monitoring the system wherever you are. For this option, the components must be smart components, with the ability to be connected to the cloud. To connect these IoT components to the cloud, Kepware is still required. This software has different drivers to communicate with some industrial communication protocols.
This option will enable data analytics, too, as all the information will be on the cloud. In this way, companies will have the chance to do Big Data and data analysis, managing power consumption. They will also have the ability to change the production speed as well as the production quantity.
Figure 11: PC-Based system Architecture.
33
Transferring this option to the IRMA demonstrator regarding the industrial connections did not appear any problem as Kepware has MODBUS TCP and OPC UA drivers. So, UR robots, the inverter, and the sensors were rapidly connected to the cloud.
4.3 PLC-Based control and PC-Based monitor and data analytics
As mentioned before, nowadays it is too complicated to develop an automation of an industrial plant on the cloud. So, the easiest and the most efficient way to do an automation is via PLC as it has been done for the last years. The cloud it is useful in the monitoring environment. The strengths of the cloud are the monitoring and data analytics. For this all, the modularity, scalability, and flexibility are key points. The main idea is to have the ability to access to the industrial equipment either from the cloud and the PLC. In this way, being controlled from the PLC and, at the same time, being connected to the cloud to monitor and analyse data.
Figure 12: PLC-Based control and PC-Based monitor and data analytics system Architecture.
34
As mentioned in the first option, the connection between the PLC and the industrial equipment would be the same. The connection between the industrial equipment and the cloud is the same as the one mentioned in the second option.
In this thesis is proven that this is the best option. It isn't easy to perform an automation with the cloud. At least, it is challenging for the developers of this thesis to develop as efficient logic as can be designed with PLC.
35 5. LAB EQUIPMENT
This thesis has been developed at ASSAR Innovation Arena, located in Skövde, a city of Sweden. The thesis has been done in an industrial manufacturing line demonstrator called intelligent reconfigurable manufacturing line (IRMA). This line is based on a real car manufacturing process. It simulates an operation in which the valve hood of an engine and a circuit board are placed.
There are three different stations in this line, each one with a collaborative robot from Universal Robots.
5.1 Stations
- Kitting Station: The small components needed to assemble the circuit board arrive at this station. They will be sorted and placed on a pallet on a conveyor belt. They can be transported and used in the next station. Universal Robot’s UR3 robot and Qbrobotic’s SoftHand work autonomously to perform the task.
- Circuit Board Assembly Station: Using the components on the conveyor belt, an operator assembles the circuit board and places it into the final product. Universal Robot’s UR5 robot and Robotics’ 2F85 gripper work together to perform the task.
- Valve Hood Assembly Station: The finished valve bells arrive at this station. They will be positioned and screwed by an operator onto the final product. Universal Robot’s UR10e robot and OnRobot’s VG10 vacuum gripper work together to perform the task.
The main product used in this line is a 16L truck engine, which is static due to practical reasons.
A simplified version of it is used to simulate the movement of the main product along the time.
In manufacturing mode, the product initially goes to the circuit board assembly station. Once this is assembled, it goes to the valve hood assembly station. The process is reversed when disassembly is required.
The simplified version of the main product is mounted in a custom automated guided vehicle (AGV) to perform the movements between the circuit board assembly station and the valve hood assembly station.
36 5.2 Configuration of fieldbuses for the devices
According to the robots, if they have to be connected to the PLC, they must have the ETHERNET IP communication fieldbus enabled. So that later through EDS files for having all the robots’ variables in the PLC.
In contrast, for the robots directly connected with Kepware, MODBUS TCP fieldbus has been used. For being enabled this fieldbus, it is not necessary to activate anything. As these robots always have it enabled. However, the variables that have to be exchanged from this fieldbus must be created and configurated. The configuration is done in the tech pendant of the robot, in the MODBUS window. For the configuration of these variables, it is necessary to know what type of variable it is and its location in the internal MODBUS server. Then, for searching these variables from Kepware, the correct address is needed, which is better explained in Appendix B: MODBUS addresses for UR robots and the inverter.
These robots can monitor everything as joint angles or robot tool information and control the robot controller inputs. The only thing that cannot be controlled via the fieldbuses is the angles of the joints, but it is possible to monitor them.
Furthermore, apart from communicating with these two fieldbuses, these robots can communicate through the PROFINET fieldbus.
On the other hand, for the inverter to communicate via fieldbuses, an adapter is needed. In this case, the inverter model is ACS355 from ABB, and the adapter it needs is the FENA-01. The adapter is from the same brand as the inverter. With the adapter, the inverter can be connected to ETHERNET IP and MODBUS TCP fieldbuses.
First, different parameters from the inverter must be configured. For the configuration of the fieldbus, parameters from group number 51 have been defined as follows:
Table 1: Parameters group number 51 of the inverter
Address Value Description
01 Ethernet For establishing communication
37
02 2 (MODBUS TCP)
100 (ETHERNET IP)
With these two values, ETHERNET IP or MODBUS TCP can be selected as communication fieldbus
03 0 (Auto negotiate) COOM rate
04 0 (Static) Type of IP Address: Static or Dynamic
05-08 192.168.1.120 IP Address
09 24 (255.255.255.0) Mask
10-13 192.168.1.4 Gateway Address
27 Refresh/Done If any change has been done, with
refresh the changes are saved
Once the fieldbus and addresses have been configured as said in These robots can monitor everything as joint angles or robot tool information and control the robot controller inputs. The only thing that cannot be controlled via the fieldbuses is the angles of the joints, but it is possible to monitor them.
Furthermore, apart from communicating with these two fieldbuses, these robots can communicate through the PROFINET fieldbus.
On the other hand, for the inverter to communicate via fieldbuses, an adapter is needed. In this case, the inverter model is ACS355 from ABB, and the adapter it needs is the FENA-01. The adapter is from the same brand as the inverter. With the adapter, the inverter can be connected to ETHERNET IP and MODBUS TCP fieldbuses.
First, different parameters from the inverter must be configured. For the configuration of the fieldbus, parameters from group number 51 have been defined as follows:
, to control the speed of the motor via the fieldbus, these properties have been defined in parameter group 11:
Table 2: Parameters group number 11 of the inverter
Address Value Description
38
02 EXT1 The REF1 is connected to EXT1
03 COMM Defining the speed reference from the
fieldbus
Apart from configuring the fieldbus, defining the start-up data so that the drive is coupled to the system's motor is necessary. For this, there is group 99, where motor-specific parameters are defined. Besides, in the first group, variables such as speed, torque, or drive temperature can be monitored when the inverter is operating.
Finally, for exchange variables with the PLC, using ETHERNET IP, or directly with Kepware, MODBUS TCP, it must be done the same as the robots.
39 6. CLOUD PLATFORM
In this chapter, it is going to explain the used IoT platform, and the features of the cloud developed in this thesis.
6.1 Software
To develop this thesis some software were needed. Two of them from PTC, ThingWorx (THX) and Kepware. THX is the cloud data base, in which the variables are and where the automation is done programming in JavaScript. On the other hand, Kepware is the software that communicates between the industrial equipment and the cloud. That connection to the industrial equipment can be done in different industrial communication protocols. The communication protocol depends on the equipment, not all the equipment has all the protocols.
There are several alternatives to PTC ThingWorx, like Microsoft Azure or Amazon Web Services (AWS) for the cloud platform. In this thesis THX is the software that had been used.
Regarding to security and Built-In Analytics all of them are quite similar. But when it starts comparing IoT Commitment, Developer Tools and VR and AR Expertise THX is better.
In this thesis, MODBUS TCP has been used to connect the UR collaborative robots and the cloud. Also, to connect the inverter and control some variables of it. OPC UA has been used to connect the sensors of the conveyor. If someone wants to connect the PLC, OPC UA was used due to the simplicity and efficiency of the communication.
To do the virtual simulation of the conveyors Simumatik and Visual Components have been used. All the control was done via cloud, so an OPC UA server was required to connect both systems. To create the server has been created with a REST API, this have been done in a Python Script and for that Visual Studio Code has been used.
6.2 Data Modelling
Data modelling is an option that THX provides developers for having all the data in a scalable and well-structured way. All the data can be organised at different levels using three entities: Things, Thing Templates, and Thing Shapes, where each of them has its properties, services, events, and subscriptions. At the highest level would be the so-called Thing, which would be the virtual representation of each principal component of the process. Then, at the next level, there are the Thing Templates. Suppose there are similar components in the system that share data. In that case, it is enough to create them once in a Thing Templates and have the
40
Things inherit these properties, services, events, and subscriptions. To make the system even more scalable, there are Thing Shapes, and they work in the same way as the Thing Templates.
It is essential to underline that only one Thing Template can be associated with a Thing or Thing Template. However, the number of Thing Shapes that can be connected to a Thing or Thing Template is unlimited.
IRMA has six main components: the three robots (UR3, UR5, and UR10e), the conveyor, and the sensors, each one on one side of the conveyor. However, to create the data model, it has been considered that the number of these components could be higher in the future. So, the data model has been created with scalability in mind. So, the configuration of new similar elements, being much easier and faster.
To begin with, it is necessary to define the properties of each Thing to compare what they have in common.
Table 3: Things and their properties in THX
THING PROPERTIES
UR3 Base_Angle, Shoulder_Angle, Elbow_Angle, Wrist1_Angle, Wrist2_Angle, Wrist3_Angle, Base _Temperature, Shoulder _Temperature, Elbow
_Temperature, Wrist1_Temperature, Wrist2_Temperature,
Wrist3_Temperature, RobotFinished, RobotReady, Gripper State, Gripper Width, GripperTorque, PowerOn, Running
UR5 Base_Angle, Shoulder_Angle, Elbow_Angle, Wrist1_Angle, Wrist2_Angle, Wrist3_Angle, Base _Temperature, Shoulder _Temperature, Elbow
_Temperature, Wrist1_Temperature, Wrist2_Temperature,
Wrist3_Temperature, RobotFinished, RobotReady, Gripper State, Gripper Width, GripperTorque, PowerOn, Running
UR10e Base_Angle, Shoulder_Angle, Elbow_Angle, Wrist1_Angle, Wrist2_Angle, Wrist3_Angle, Base _Temperature, Shoulder _Temperature, Elbow
_Temperature, Wrist1_Temperature, Wrist2_Temperature,
Wrist3_Temperature, RobotFinished, RobotReady, Vacuum State, Vacuum Pressure, PowerOn, Running
41
Conveyor Actual Speed, Speed Reference, Forward, Reverse, Max Speed, Min Speed, Drive Temperature, Control Word, Status Word
Sensor_UR3 Status Sensor_UR5 Status
As shown in Table 3, all the robots have six joints, so the angles and temperatures of the joints can be taken to a Thing Template, and at the same time, the angles and temperatures can be Thing Shapes. The gripper properties can be taken to another Thing Shape and the vacuum properties to be added to each robot for the tool. This would look like presented in Table 4.
Table 4: Thing Shapes, Thing Templates and Things of the UR Robots
THING SHAPE (TS) PROPERTIES
JointValues Base_Angle, Shoulder_Angle, Elbow_Angle, Wrist1_Angle, Wrist2_Angle, Wrist3_Angle
JointTemperatures Base _Temperature, Shoulder _Temperature, Elbow _Temperature, Wrist1_Temperature, Wrist2_Temperature, Wrist3_Temperature
GripperTool Gripper State, Gripper Width, GripperTorque
VacuumTool Vacuum State, Vacuum Pressure
THING TEMPLATE (TT)
6DoFRobotArm JointValues (TS), JointTemperatures (TS), RobotFinished, RobotReady
THING
UR3 6DoFRobotArm (TT), GripperTool (TS)
UR5 6DoFRobotArm (TT), GripperTool (TS)
UR10e 6DoFRobotArm (TT), VacuumTool (TS)
For the Thing conveyor, since an inverter controls it, a Thing Template will be made for this specific model. A Thing Shape will be associated to it, which has general properties that an inverter usually has. Thus, when a new inverter will be added, it will only have to define its specific properties when associating the Thing Shape. The Thing Template of the inverter will
42
be connected to another Thing Template that will have the control of the conveyor, and this last one will be connected to the conveyor (Thing) of the system:
Table 5: Thing Shapes, Thing Templates and Things of the Conveyor
THING SHAPE (TS) PROPERTIES
FrequencyInverter Actual Speed, Speed Reference, Forward, Reverse, Max Speed, Min Speed, Drive Temperature
THING TEMPLATE (TT)
ACS355 FrequencyInverter (TS), Control Word, Status Word
ConveyorControl ACS355 (TT)
THING
Conveyor ConveyorControl (TT)
Finally, to scale the sensors and similarly to what has been done with the inverter, a Thing Shape will be created with the most common properties of the inductive sensors. Then, this Thing Shape will relate to the Thing Template of these specific sensors and finally this Thing Template with both sensors (Things):
Table 6: Thing Shapes, Thing Templates and Things of the Sensors
THING SHAPE (TS) PROPERTIES
InductiveSensor Status
THING TEMPLATE (TT)
IFC205 InductiveSensor (TS)
THING
Sensor_UR3 IFC205 (TT)
Sensor_UR5 IFC205 (TT)
After scaling everything up, the overall picture of the data model of this system would look like this:
43
Figure 13: IRMA data model.
Once the entire IRMA data model has been created in the cloud, it is time to connect each property to its variable. These are in robot controller’s logic, the inverter, or, in the case of sensors, in the PLC. For that, THX has so-called Industrial Things, and these special Things, at the same time, are connected to an Industrial Connector, which is the gateway to devices on the industrial automation factory floor.
This is where Kepware comes in, which acts as an interface between the cloud and IRMA. To connect variables from industrial equipment to THX using Kepware, see all the steps in Appendix A: Connecting industrial equipment variables to ThingWorx.
44 6.3 Monitorisation
The Human Machine Interface (HMI) is the interface between the process and the operator.
Also, it is the instrument used to monitor and control, for example, industrial operations. The HMI receives variables of all kinds and translates them into valuable and actionable information.
“Displaying near real-time operational information is the domain of the HMI. Visual process graphics give meaning and context to a motor and valve status, tank levels, and other process parameters. HMIs give operational insight into the process and enable control and optimisation by regulating production and process targets” (Wonderware, 2016).
For building HMIs, there are different ways. On the one hand, PLCs software can create its HMI, and depend on the brand, high- or low-quality HMIs can be made. These HMIs have the advantage of being already implemented in the PLCs. On the other hand, there are independent software only focused on HMIs, to create advanced interfaces. This type of HMIs, at the end of the process, have to be connected to the systems.
In THX, HMIs are called Mashups, where different widgets like buttons or LEDs can be added.
For reading and writing data from properties, some services must be called, either internal to THX or created by the user. By calling these services, scripts that go inside it can be executed or also trigger an event that runs a subscription. As a result, they work differently, and their implementation is different compared to traditional HMI software.
However, THX can be connected to specific HMI software. So that lack of functionality it has, according to HMIs, complements it by offering this kind of connectivity.
In THX, widgets are called to those components that are used for the creation of Mashups.
Widgets have lots of different information that must be filled in for them to work. The widgets and some of the most common functionalities they provide can be found in Appendix C:
Widget’s definition and functionalities for mashups in THX.
6.3.1 Mashups IRMA
For IRMA, different mashups have been made both to control and monitor the system. First, a mashup has been created as a menu to navigate through other mashups that contain process information.
45
Figure 14: Menu mashup for IRMA.
To begin with, the conveyor has a mashup where you can manually control it in both directions, increase or decrease speed, or monitor its speed and specific inverter information.
Figure 15: Mashup for the conveyor at IRMA.
46
In the case of the robots, each one has a different Mashup, but they all contain similar information. On the one hand, there is an indicator for visualising if the robot is switched on.
Then, it is possible to tell manually to the robots to do their job or stop doing it. And finally, for robots that have a gripper as a tool, the width of the gripper can be constantly monitored.
Figure 16: Mashup for the robots at IRMA.
During the implementation of the Mashups, it has become clear that THX still does not have many widgets to create a complete and attractive Mashup. However, depending on the function they are used for, they are sufficient.
6.4 Control
Comparing to the classical PLC control, the cloud-based control is completely different. Using PTC ThingWorx, the programming is done via code (JavaScript), but this is not the only difference. To program in ThingWorx some subscriptions must be done. The subscriptions are scripts which are going to be executed when an event is triggered. The events are what are going to execute the subscription. The most used event in this thesis is called Data Change, and the user decides which data. So, when that data is changing the subscription is going to execute.
The most used properties in this project are Booleans and this data change can be detected on both rising and falling edges.
In this thesis a conveyor line has been automated, in this line as many conveyors as wanted or required can be modelled. Also, a system in which a two-way conveyor and two UR robots are
47
involved. This second automation has been done for IRMA, to program the real equipment which the authors of the thesis have been working with.
To automate the conveyors some handshakes have been used. The handshakes are variables that connect the conveyors. Each conveyor is receiving information from the pervious and next one. For example, if a conveyor is moving, if it has a product waiting etc. This is very important for the correct functionality of the conveyors, only to move them when is needed and not to have any conflict with the commands. Each conveyor has a sensor in the middle of it, so the others will where the piece is in every moment.
To use the mashups, some services are needed. Each service sets or resets the variables that the user has written in. When one of those variable changes value, the appropriate subscription shall be executed.
Using THX the automation cannot be stopped in the middle of a branch. It does all the branch, or it waits until one of the main data is changing: “PrevSensor”, “ConvSensor”, “NextSensor”
or “TransferDone”. These variables are the ones that allow conveyors to know if the previous, next or itself is detecting/moving a product or not.
In the Figure 17 can be seen that when the data change is in a rising edge, as the previous sensor has to be in 1, there are two options. If the conveyor itself is not moving a product and it is not detecting a product, it starts moving the product. But, if the conveyor itself is moving or it is detecting a product, set the variable “ProductWaiting”.
48
Figure 17: Previous Sensor Data Change
In the Figure 18 can be seen that when the data change is in a falling edge, it sets “Transfering”
variable, and resets “TransferDone”. “Transfering” means that it is moving a product and
“TransferDone”, that a product has arrived from the previous conveyor.
If the data change is in a rising edge two options can happen. If the next conveyor is not transferring a product and it is not detecting a product, the conveyor itself starts moving. But, if the next conveyor is transferring or detecting a product, the command is to stop the conveyor.
49
Figure 18: Conveyor Sensor Data Change
In the Figure 19 can be seen that when the data change is in a rising edge, it sets the
“TransferDone” variable to 1 and resets “Transfering” variable. But, if it is previously said that the next conveyor is the last of the line, and actual conveyor does not have a product waiting the command is to stop the actual conveyor.
Figure 19: Next Sensor Data Change
50
In the Figure 20 can be seen that when the data change is in a rising edge. The actual conveyor has a product waiting to receive, the command is to move the actual conveyor as well as the previous one. This action also resets “TransferDone” and “ProductWaiting” variables.
Figure 20: Transfer Done Data Change 7. SIMULATION SOFTWARE
In recent years, simulation software has become increasingly important in the industry. It provides the opportunity to train and improve the system in a virtual environment without stopping production. Furthermore, depending on the quality of the system created in this software, it is possible to see in advance how the system will behave, anticipating faults and reducing set-up times. On the other hand, implementing the processes in this software can take days, weeks, or even months, depending on the complexity of each system.
Different software can be found in the market dedicated to this task, and each has its advantages and disadvantages. In this project, two have been analysed: Simumatik and Visual Components.
The SWOT method has been used to make a comparison between these two software. This method is based on defining the strengths, weaknesses, opportunities, and threats of each product. Some of the points described in this analysis are based on the experience of the authors of this thesis.
