2021 alvaro lu s de smart objects para a industri a 4.0
TRANSCRIPT
Universidade de Aveiro2021
Alvaro Luıs deAmorim Vaz
Smart Objects para a Industria 4.0
Smart Objects for the Industry 4.0
Universidade de Aveiro2021
Alvaro Luıs deAmorim Vaz
Smart Objects for the Industry 4.0
Dissertacao apresentada a Universidade de Aveiro para cumprimento dosrequisitos necessarios a obtencao do grau de Mestre em EngenhariaEletronica e Telecomunicacoes, realizada sob a orientacao cientıfica doDoutor Pedro Fonseca (orientador), Professor Auxiliar do Departamentode Eletronica, Telecomunicacoes e Informatica da Universidade de Aveiroe do Doutor Paulo Pedreiras (co-orientador), Professor Auxiliar do Depar-tamento de Eletronica, Telecomunicacoes e Informatica da Universidade deAveiro
o juri / the jury
presidente / president Professor Doutor Telmo Reis CunhaProfessor Associado, Universidade de Aveiro
Arguente principal / examinercommittee
Professor Doutor Antonio Luis Ferreira MarquesProfessor Adjunto, Instituto Superior de Engenharia de Coimbra
Orientador / Mentor Professor Doutor Pedro Nicolau Faria da FonsecaProfessor Auxiliar, Universidade de Aveiro
agradecimentos /acknowledgements
Gostaria de agradecer, em primeiro lugar, aos meus orientadores ProfessorDoutor Pedro Nicolau Faria da Fonseca e o Professor Doutor Paulo BacelarReis Pedreiras, pela excelente orientacao e dedicacao que proporcionaram aolongo deste percurso. Obrigado por estarem disponıveis sempre que preciseiensinando um excelente metodo de trabalho em cada interacao.
Gostaria de agradecer a Korber Supply Chain PT pela confianca e excelenteoportunidade de desenvolver uma solucao para um dos seus prototipos.Agradeco a disponibilidade de responder as minhas questoes como a idaaos estabelecimentos para testar o trabalho desenvolvido em laboratorio.
Agradeco aos meus amigos e colegas, pela companhia na diversao comonas penosas horas na biblioteca a estudar, sem voces teria sido impossıvel.
Agradeco a minha famılia, pois todos em diferentes alturas contribuirampara que o caminho seguisse em frente, cada um a sua maneira tanto nopercurso academico como pessoal. Estou imensamente grato, sem vocesnao seria quem sou hoje. Dou especial atencao a minha irma pelo animo ealegria dado estes anos todos.
Palavras-chave Industria 4.0, Industrial Internet of Things (iIOT), Siemens IOT2050
Resumo Esta dissertacao foi desenvolvida em concordancia com o contexto atual tec-nologico, nomeadamente a Industria 4.0. A contemporanea vaga industrialesta associada a um aumento tanto da diversidade como da disponibili-dade e relevancia de novas tecnologias. Posto isto, e possıvel deduzir quea otimizacao de fabricas, atraves da disponibilizacao virtual de informacaoem tempo real, e ainda mais relevante na sociedade de hoje em dia. Noseguimento de todas as consideracoes mencionadas fez-se um trabalho depesquisa aos pontos fulcrais de um sistema que se insere na Industria 4.0tem. Os pontos principais do sistema encontrados foram a integracao de sis-temas fısicos na cloud com acesso aos dados em tempo real tendo o desafiode usar protocolos ”leves”, pois estes sistemas irao introduzir um volumegrande na rede da infraestrutura. Apos o estudo era ideal comprovar a suaaplicacao entao a empresa Korber Supply Chain PT foi contactada. Coma actividade da empresa em mente, um sistema de Industrial Internet ofThings foi proposto e testado, sistema este que permite a fabrica ter acessoa informacao virtualmente e em tempo real, estando esta informacao emdashboard.Nesta dissertacao sao abordados os processos que compoem uma rede, comespecial enfase para dois protocolos de comunicacao: MQTT e AMQP. Osprotocolos mencionados sao sujeitos aos mesmos benchmarks, utilizados nosentido de avaliar a performance e adaptabilidade ao problema proposto. Osvalores testados sao: velocidade maxima de envio, adaptacao ao acresco denodes no sistema e uso de recursos no sistema. Apos analise, conclui-se queo protocolo mais adequado para a situacao exposta e o MQTT.
Finalizando a escolha do protocolo, segue-se o layout da arquitectura. Osistema e composto por um elevador automatico composta por um PLCda Siemens acrescentando um IOT2050. O IOT2050 alberga a funcao degateway, na qual se processam os dados recebidos do PLC enviando umjson para a cloud, usando uma rede MQTT. O IOT2050 corre Node-REDe comunica com o PLC para obtencao de dados dos sensores da maquina.A leitura dos dados e feita num painel em Node-RED.
Testes de performance, realizados no contexto desta dissertacao, mostramque o Gateway consegue trabalhar em conjunto com o PLC. Os testesprovam tambem que nenhuma mensagem e perdida no envio, apesar dapossibilidade do Node-RED ter limitacoes para triggers abaixo dos 30ms.Assim, os testes mencionados permitem concluir que o sistema propostofunciona como previsto, em ambiente experimental de laboratorio.
Adicionalmente, os testes em laboratorio foram repetidos no contexto defabrica. O resultado obtido correspondeu ao resultado esperado. Todasas variaveis foram lidas corretamente e o dashboard melhorou a interfacecom a maquina. Assim, e pertinente concluir que o sistema desenhado efuncional, nao so em contexto experimental, mas tambem em contexto real.
Keywords Industry 4.0, Industrial Internet of Things (iIOT), Siemens IOT2050
Abstract This dissertation was developed in accordance with the present technologicalcontext, focusing on the Industry 4.0. The contemporary industrial waveis associated with the rise of diversity and availability of new technologies.With that said is possible to imply that industrial factory efficiency, threwthe gathering of information in real time, is even more relevant in today´ssociety.
First aproach to the this disseration was to research what composes aindustry 4.0 network the difficulties it is faced with. One of many difficultiesobserved were the integration of many of physical systems to the cloud whilemantaining a reak time feed. Also a system in the industry implies heavyloads in a network therefore there needs be added ”lightweight” protocolsto run in the system. Following these considerations the company ”KorberSupply Chain PT” was contacted. With the idea proposed of using oneof their machines a Industrial Internet of Things (IIoT) was developed andtested, aiming that the company would be able access and process machinedata in real time while plotting to a dashboard.
In this work the processes that compose a network are discussed, withspecial detail two communication protocols: Message Queuing TelemetryTransport (MQTT) and Advanced Message Queuing Protocol (AMQP).This mentioned protocols are subject to benchmarks made to prove perfor-mance and stability of the exposed problem. The parameters tested are thefollowing: maximum message rate, adaptation too node increase and re-sources used. Upon analyses it was seen that MQTT would be the protocolused.Upon protocol selection follows the system design around the IOT2050 and
a Siemens Programmable Logic Controller (PLC). The IOT will function asa Gateway, where the data received by the PLC would be processed to aJavaScript Object Notation (JSON) and then sent to the cloud via MQTT.The IOT2050 will run Node-RED instance with the appropriate flow toaccomodate these requirements.
Performance test are then made within the context of this dissertation, thatprove that the Gateway can keep up with the PLC clock cycles. They alsoprove that no message is lost between IOT and PLC, although Node-REDmay have it´s limitations in generating messages on the 30 millisecond clockcycle. Therefore in the experimental scenario it can be concluded that thesystem will function in the proposed solution
Finally the system was brought to Korber Supply Chain PT warehousewhere it was tested on their machine, having the expected results. Allvariables were read and plotted in the dashboard developed, concludingthat the system works in a real life application.
Contents
List of Figures v
List of Tables ix
1 Introduction 1
1.1 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Document Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 State of the Art 4
2.1 Digital Twins / Cyber-physical Systems . . . . . . . . . . . . . . . . . . . 5
2.2 Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3 Transport Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3.1 TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3.2 UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4.1 Securing TCP with TLS 1.3 encryption connection . . . . . . . . . 9
2.4.2 DTLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4.3 SASL Authentication . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.5 Application Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.5.1 MQTT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.5.1.1 Broker . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.5.1.2 Publishers/Subscribers . . . . . . . . . . . . . . . . . . . 15
2.5.2 AMQP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.5.2.1 AMQP 0-9-1 . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.5.2.2 Publishers . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.5.2.3 Consumers . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.5.2.4 Brokers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.5.2.5 Exchanges . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.5.3 AMQP 1.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.6 Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.6.1 Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.6.2 Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
i
2.6.3 Message Frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.6.4 Flow control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.6.4.1 Session flow control . . . . . . . . . . . . . . . . . . . . . 21
2.6.4.2 Link flow control . . . . . . . . . . . . . . . . . . . . . . . 21
2.7 Security in AMQP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.7.1 SASL in AMQP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.8 Constrained Applied Protocol (CoAP) . . . . . . . . . . . . . . . . . . . . 22
2.8.1 Representational State Transfer (REST) . . . . . . . . . . . . . . . 22
2.8.1.1 GET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.8.1.2 PUT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.8.1.3 DELETE . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.8.1.4 POST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.8.2 Message format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.8.3 Quality of Service for Message Delivery . . . . . . . . . . . . . . . 24
3 Benchmarking Protocols 25
3.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2 Testing methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2.1 Test hardware setup . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.2.2 Test 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.2.3 Test 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.2.4 Data gathering methodology . . . . . . . . . . . . . . . . . . . . . 28
3.2.5 Calculating maximum message rate in python . . . . . . . . . . . . 29
3.3 Tests with maximum message rate . . . . . . . . . . . . . . . . . . . . . . 31
3.4 Test 1 results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.4.1 CPU load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.4.2 Memory use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.4.3 Message rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.5 Test 2 results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.5.1 Message Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.5.2 CPU load and memory use . . . . . . . . . . . . . . . . . . . . . . 42
3.6 Final Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4 Use case 45
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.2 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.3 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.3.1 Main variable description . . . . . . . . . . . . . . . . . . . . . . . 47
4.4 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.4.1 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
ii
5 Implementation 49
5.1 Test configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.2 Software developed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.3 Implementation on Node red . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.3.1 Timestamp Processing . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.3.2 Incoming message . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.3.3 Heartbeat module . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.3.4 Update STK Status variable . . . . . . . . . . . . . . . . . . . . . 57
5.3.5 PLC network state . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.3.6 Sending to Azure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.4 Dashboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.5 Dashboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
6 Benchmarking system 66
6.1 Message bandwidth measurement . . . . . . . . . . . . . . . . . . . . . . . 67
6.2 Test load configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
6.3 Test 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
6.4 Message rate with/without load . . . . . . . . . . . . . . . . . . . . . . . . 70
6.4.1 Message rate without load . . . . . . . . . . . . . . . . . . . . . . . 70
6.4.2 Load environment . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
6.5 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
6.5.1 Test1 conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
6.5.2 Message rate with/without load conclusions . . . . . . . . . . . . . 78
7 Practical application 79
7.1 Stacker crane description . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
7.2 Hardware description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
7.3 Test Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
7.4 Test Enviroment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
7.5 MQTT messaging environment . . . . . . . . . . . . . . . . . . . . . . . . 82
7.6 Data interpretation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
7.6.1 Stacker Crane run . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
7.6.2 IOT2050 metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
7.6.3 MQTT messaging . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
7.7 Dashboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
7.8 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
8 Conclusions 92
8.1 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Bibliography 95
iii
Appendix A Setting up IOT2050 100A.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100A.2 Setting up Workspace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100A.3 Setting Static IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101A.4 Node-RED . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Appendix B Benchmark protocols with 756kB file 104B.1 Testing methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
B.1.1 Data gathering methodology . . . . . . . . . . . . . . . . . . . . . 104B.1.2 Test hardware setup . . . . . . . . . . . . . . . . . . . . . . . . . . 104
B.2 Message rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106B.3 CPU load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108B.4 Memory use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109B.5 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Appendix C MQTT 110C.1 Fixed header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
C.1.1 Variable header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110C.1.2 Payload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
C.2 Control Packet types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110C.2.1 Packets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111C.2.2 Store and Forward . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
C.3 Error Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112C.3.0.1 Malformed packets . . . . . . . . . . . . . . . . . . . . . . 112C.3.0.2 Error handling . . . . . . . . . . . . . . . . . . . . . . . . 112
Appendix D Software for protocol benchmarking 113D.1 MQTT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
D.1.1 Big message test . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115D.2 AMQP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
D.2.1 Maximum message rate . . . . . . . . . . . . . . . . . . . . . . . . 117D.2.2 Big message test . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Appendix E Node-RED 120E.0.1 Burst module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
E.1 Node-RED variable listing Revision 1.0 . . . . . . . . . . . . . . . . . . . 123E.2 Node-RED variable listing Revision 2.0 . . . . . . . . . . . . . . . . . . . 127E.3 Dashboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Appendix F Sensor listing for Version 1.0 and 2.0 151F.1 Factory stacker sensor list . . . . . . . . . . . . . . . . . . . . . . . . . . . 151F.2 Korber Supply Chain PT elevator sensor list . . . . . . . . . . . . . . . . 156
iv
List of Figures
2.1 OSI vs TCP/IP model layer representation . . . . . . . . . . . . . . . . . 6
2.2 TCP/IP model based ”capsules” representation . . . . . . . . . . . . . . . 7
2.3 Transmition Control Protocol (TCP) connection handshake procedure . . 8
2.4 Client key combination for obtaining Secret Common Key . . . . . . . . . 10
2.5 Residing client keys description . . . . . . . . . . . . . . . . . . . . . . . . 10
2.6 TLS 1.3 connecting procedure between client A and B . . . . . . . . . . . 10
2.7 Datagram Transport Layer Security (DTLS) placement in trasnport layer 11
2.8 DTLS Handshake procedure with failed first attempt . . . . . . . . . . . . 12
2.9 Network arquitecture of MQTT [29]. . . . . . . . . . . . . . . . . . . . . . 13
2.10 MQTT message exchange example . . . . . . . . . . . . . . . . . . . . . . 14
2.11 AMQP 0-9-1 Structure description . . . . . . . . . . . . . . . . . . . . . . 16
2.12 AMQP 0-9-1 broker description . . . . . . . . . . . . . . . . . . . . . . . . 17
2.13 AMQP Direct exchange example . . . . . . . . . . . . . . . . . . . . . . . 18
2.14 AMQP 1.0 message transfer description . . . . . . . . . . . . . . . . . . . 19
2.15 AMQP 1.0 connection description . . . . . . . . . . . . . . . . . . . . . . . 19
2.16 AMQP 1.0 session description . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.17 AMQP 1.0 unidirectional link example . . . . . . . . . . . . . . . . . . . . 20
2.18 AMQP 1.0 frame description . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.19 Constrain Application Protocol (CoAP) network description . . . . . . . . 22
2.20 Representational State Transfer (REST) GET message response is set . . 23
2.21 CoAP message frame description . . . . . . . . . . . . . . . . . . . . . . . 24
3.1 Testing methodology description . . . . . . . . . . . . . . . . . . . . . . . 27
3.2 Flow chart of the python code . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.3 AMQP 30 sample cycle time . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.4 MQTT 30 sample cycle time . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.5 MQTT maximum rate in test with maximum rate . . . . . . . . . . . . . 31
3.6 AMQP maximum rate in test with maximum rate . . . . . . . . . . . . . 31
3.7 AMQP code flowchart with delay . . . . . . . . . . . . . . . . . . . . . . . 32
3.8 MQTT code flowchart with delay . . . . . . . . . . . . . . . . . . . . . . . 33
3.9 AMQP 30 sample cycle time . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.10 MQTT 30 sample cycle time . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.11 AMQP broker CPU load with the increase of nodes . . . . . . . . . . . . . 35
v
3.12 MQTT broker CPU load with the increase of nodes . . . . . . . . . . . . 35
3.13 AMQP vs MQTT memory use with the increase of nodes . . . . . . . . . 36
3.14 AMQP vs MQTT message rate comparison . . . . . . . . . . . . . . . . . 37
3.15 RabbitMQ broker GUI graph message speed on the incremental test . . . 38
3.16 MQTT broker message rate of 1 topic . . . . . . . . . . . . . . . . . . . . 39
3.17 Message rate in Test 2 viewing from AMQP gui . . . . . . . . . . . . . . . 40
3.18 Message rate in MQTT viewing from Node-RED dashboard . . . . . . . . 41
3.19 Message rate on AMQP and MQTT . . . . . . . . . . . . . . . . . . . . . 41
3.20 CPU load in top command in AMQP . . . . . . . . . . . . . . . . . . . . 42
3.21 Memory use in top command in MQTT . . . . . . . . . . . . . . . . . . . 43
4.1 System architecture and hardware description . . . . . . . . . . . . . . . . 47
4.2 IOT2050 to Azure communication description . . . . . . . . . . . . . . . . 48
5.1 Test system configuration overview . . . . . . . . . . . . . . . . . . . . . 50
5.2 Flowchart of data processing and acquisition in the flow . . . . . . . . . . 52
5.3 Flowchart of PLC state verifier in the flow . . . . . . . . . . . . . . . . . . 52
5.4 Flow running on IOT2050 that collects PLC information and sends themto the Azure IotHub . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.5 Flow running on IOT2050 that is responsible for date processing . . . . . 56
5.6 Flow running on IOT2050 that sends incoming messages and merges pro-cessed timestamp value in object list . . . . . . . . . . . . . . . . . . . . . 56
5.7 Flow running on IOT2050 that sends messages every 60 seconds as aheartbeat of the machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.8 Flow running on IOT2050 that updates the STK Status variable in ac-cordance to the PLC activity . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.9 Flow running on IOT2050 that updates the STK Status variable in ac-cordance to the connection of the PLC in the network . . . . . . . . . . . 58
5.10 Flow running on IOT2050 that converts a object list to a JSON and sendsit to a Azute IotHub . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.11 Dashboard diagram description . . . . . . . . . . . . . . . . . . . . . . . . 59
5.12 Dashboard flow that receives json from Azure and organizes it on a dash-board function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.13 Part of the code that implements the table position, filtering, time formatand viewing of the incoming messages variable . . . . . . . . . . . . . . . 62
5.14 User view of the dashboard implemented in Node-RED . . . . . . . . . . . 63
5.15 Flow that contains the metrics generator for the user dashboard . . . . . 64
6.1 Test system description . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
6.2 Message count every 5 minutes in a 24h time frame on a 60 second messagerate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
6.3 Message count every 1 minute in a 24h time frame on a 1 second messagerate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
6.4 Message count every 15 minutes in a 24h time frame on the burst test . . 69
vi
6.5 Counter node added to the ”Send to Azure” module . . . . . . . . . . . . 706.6 Node-RED and Azure message rate with a 100 millisecond cycle . . . . . 706.7 Node-RED and Azure message rate with a 50 millisecond cycle . . . . . . 716.8 Node-RED and Azure message rate (msg/min) with a 30 millisecond cycle 716.9 Plot of maximum divergence on each time cycle . . . . . . . . . . . . . . 746.10 Node-RED and Azure message rate with a 100 millisecond cycle on a
network with load. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 756.11 Node-RED and Azure message rate with a 50 millisecond cycle on a net-
work with load. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 766.12 Node-RED and Azure message rate with a 30 millisecond cycle on a net-
work with load. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
7.1 Stacker crane picture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 807.2 Stacker Crane schematic with positions layout and laser encoder placement 817.3 Stacker crane cabinet description . . . . . . . . . . . . . . . . . . . . . . . 827.4 MQTT message sending addition to main flow with message per minute
storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 837.5 MQTT message receiver flow collecting data from local broker . . . . . . . 837.6 Position and current consumed by the crane over time . . . . . . . . . . . 847.7 Start Y level vs finish Y level . . . . . . . . . . . . . . . . . . . . . . . . . 847.8 CPU temperature for the 1 hour test . . . . . . . . . . . . . . . . . . . . . 857.9 CPU dual core usage for the 1 hour test . . . . . . . . . . . . . . . . . . . 867.10 Flow cycle time to process under the 1 hour usage . . . . . . . . . . . . . 877.11 ETH data received under the 1 hour usage . . . . . . . . . . . . . . . . . . 877.12 MQTT message sent vs message received with stacker crane messages . . 897.13 Tab 1 of the dashboard displaying the table with the information of the
plc, Central Processing Unit (CPU) usage of each core and memory anddisk usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
A.1 Window presented in Win32 Disk Imager . . . . . . . . . . . . . . . . . . 101A.2 IP configuration to access XP2 on IOT2050 . . . . . . . . . . . . . . . . . 102A.3 IOT2050 GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
B.1 Benchmark system description . . . . . . . . . . . . . . . . . . . . . . . . 105B.2 AMQP and MQTT message rate comparison . . . . . . . . . . . . . . . . 106B.3 Rabbitmq GUI graph velocities . . . . . . . . . . . . . . . . . . . . . . . . 106B.4 Node red message velocity chart . . . . . . . . . . . . . . . . . . . . . . . 107B.5 MQTT CPU load with big messaging . . . . . . . . . . . . . . . . . . . . 108B.6 AMQP CPU load with big messages . . . . . . . . . . . . . . . . . . . . . 108B.7 AMQP and MQTT memory use comparison . . . . . . . . . . . . . . . . 109
D.1 Node red flow for MQTT message receiving and counter . . . . . . . . . . 115
E.1 Burst flow module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
vii
viii
List of Tables
3.1 Table containing tests hardware and software specification . . . . . . . . . 263.2 Table containing average message rate in MQTT and AMQP . . . . . . . 303.3 Message rate generated on each protocol . . . . . . . . . . . . . . . . . . . 343.4 Test results with highest performance levels aquired . . . . . . . . . . . . 44
4.1 Table describing main variables that are in the requirements. . . . . . . . 47
5.1 Table containing hardware and software description for benchmarking thesystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.2 Timestamp byte variables order . . . . . . . . . . . . . . . . . . . . . . . . 555.3 ”Exec Node” internal command list of each node implemented . . . . . . 65
6.1 Table containing the difference between messages received, generated andSUM without load. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
6.2 Message bandwidth in each time interval with the maximum and mini-mum values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
6.3 Table containing message received vs expected from the load tests . . . . 78
7.1 Table containing the description of devices in te network of the stackercrane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
7.2 Weather forecast on the day of testing . . . . . . . . . . . . . . . . . . . . 827.3 Table containing IOT2050 system variables evaluated in this chapter. . . . 887.4 Table containing the SUM of each message sent and received . . . . . . . 89
B.1 Table containing tests hardware and software specification . . . . . . . . . 105B.2 Table containing code run time on each node . . . . . . . . . . . . . . . . 107
C.1 MQTT Fixed Packet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110C.2 MQTT packet types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111C.3 MQTT packet structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
E.1 ”S7 com” node file input variables . . . . . . . . . . . . . . . . . . . . . . 126
ix
x
Chapter 1
Introduction
Humankind has a natural urge to create, improve, and optimize, which can be roughlytranslated as the desire to out-stand preeminent limitations. Indeed, this innate desireto surpass established situations can be noticed throughout the events that have coloredthe history of industry throughout the years.
If a quick overview of the industrial reality should be considered, we can go backto the mid-17th century in Britain. The first revolution was taking place, changing thereality of factories as it introduced fast production. Some years after, Henry Ford rev-olutionized productivity by creating the emblematic assembly line system: each worker,given a specific monotonous task, was part of a fast-paced all-productive assembly line[1]. Ford is known for changing the standards of production and having an impact whichhas remarkably echoed until the reality of factories today. Moreover, the third industrialrevolution took place in the ’70s, with the introduction of microprocessors in the factorysettings. One of the inventions that emerged was the Programmable Logic Controller(PLC), a device that, requested by GM Hydramatic in 1968, was created by BedfordAssociates in 1969, unveiling the 084 model[2]. This revolutionary programmable de-vice brought many significant changes to product manufacturing and pricing; ”...Themarked drop in the relative price of producer equipment is a reflection of the high rate oftechnological progress in the producer durables sector. Specifically, technological progressenables ever-larger quantities of investment goods to be produced with a given amount oflabor and capital, a process that drives down the prices of such goods.”[3]
Industry 4.0, on the other hand, is the concept that refers to the most recent andstill ongoing industrial revolution. Many companies are already embedded in this ac-tualization of reality: some of them only glimpsing at the new possibilities that havearisen, while others are already busy restructuring and redesigning the whole dynamicof their company to make the best use of the opportunities available. The forecasts forthe future even include government plans that use Industry 4.0 to increase competitiveadvantage economically, socially, and industrially. “Programa Industria 4.0” [4], for in-stance, was a project presented in Portugal in 2017 which had Industry 4.0 at the centerof its heart. Some measures that accompanied this project included promoting, facili-tating, and financing companies’ access to experimentation with Industry 4.0 methods
1
and technologies, as well as supporting their digital transition
The industrial phase taking place currently sheds light especially on process dig-itizing. The phenomenon of process digitizing is a breathtaking turning moment forthe world of technologies, as it allowed for the first time in history for devices to beconnected to the internet in a new way. This new form of connection between devicesand the internet allowed that data relative to that same device is always updated andavailable. This connection is especially useful and fruitful as it occurs independentlyand without the need for extra human labor to interfere in order for the relation to takeplace. Indeed, the reality of factories in the future is predicted to make use of powerfulprocessing power. Micro-processors, sensors, and process simulations are the norm pre-dicted. The importance of choosing the right backbone to run the complexity of processdigitizing cannot be disregarded.
1.1 Problem Statement
The rising need for data that is easily available and updated nowadays has emergedfrom the increase in complexity witnessed in systems of the industrial sector.ComposingInternet of Things (IoT) solutions is, without a doubt, a relevant manner to addressthis rising need as it does so by connecting components with communication protocolstogether and in the cloud. The potential of IoT is yet not fully unfolded and new waysto apply and use it emerge systematically. IoT is indeed projected to be the future offactories’ realities. Some applications can sustain a high amount of data, but there isno standardization on the messaging protocol, which implies a need for development.Moreover, the process of creating a solution directed to a industrial IoT in a factorysetting that involves data-collection, testing, etc. The solution design process is a time-demanding task that involves decision-making so that suitability to context is optimized.The final solution designed will imply a decision on which software and hardware willembrace. In addition to this, the role of the manufacturer in the process cannot bedisregarded. To conclude, the main aim of this dissertation is to test protocols that aremade for the Industry 4.0 and prove that the solution developed is fitted in an Industry4.0 scenario can be successfully achieved and implemented in a factory setting.
1.2 Objectives
The main objectives of this dissertation are:
� To study and test network protocols, with a focus on the application layer, betterfitted in an Industry 4.0 environment.
� To design a solution for the case considered.
� To test the feasibility of the solution designed in a real-life scenario.
2
1.3 Document Outline
This dissertation is organized as described:
� Chapter 2: Starts by describing Cyber Physical Systems (CPS) and Digital twinsmoving towards the concept of Network and its model layers. It goes on to highlighttwo of them, Transport and Application layers, while describing some examples ofprotocols that run under them.
� Chapter 3: The benchmarks used for the two application layer protocols aredescribed, explained and applied. The protocols mentioned are AMQP and theMQTT. All procedures and tests were ran in order to successfully choose the mostsuitable solution.
� Chapter 4:The case study is explained followed by the requirements, the system’sarchitecture and the flow of information considered.
� Chapter 5: The tests relative to the solution designed are laid out in an experi-mental context. A description of the experiment is accompanied by a descriptionof the simulation environment, as well as of the code developed for the gateway.
� Chapter 6: The solution proposed is benchmarked in an experimental context,prior to implementing it in factory settings.
� Chapter 7: A report on how the solution proposed was finally tested on the realfactory setting, using the machine it was designed for, is laid out.
� Chapter 8: A conclusion on the dissertation takes place, which includes somethoughts on future research.
3
Chapter 2
State of the Art
As Henry Petroski[5], American engineer and author specialized in failure analysis,once said: “As engineers, we were going to be in a position to change the world, not juststudy it” [6]. We are witnessing a time in history where the industry is going througha significant transformation process. We find ourselves amidst Industry 4.0, an indus-trial revolution that is progressively changing the course of factory reality, informationmethods, and technologies. Indeed, the technologies emerging through this industrialmovement have undoubtedly raised the bar for the industry sector: the achievable po-tential in terms of productivity, efficiency and machine independence has never beenhigher. Some technologies that have emerged in this phase of history were the result ofwith Industrial Integration, CPS, Digital twins, IoT[7], cloud computing[8], EnterpriseArchitecture among others. The potential for this new wave of devices is colorful andbright.
For this type of technologies to arise there is a need to build good foundations, todevelop good network protocols that withstand the load that these type of integration´swill demand. Networks with heavy traffic are the norm that these protocols need to facetherefore they need to be specially designed for high message rate, low message size andbandwidth making them ideal for this type of scenarios. These protocols are MQTT,AMQP and CoAP, used world wide for simple to complex IoT solutions. In this chapterwe will now present different network protocols, their implementation on network layersand specifically MQTT, AMQP and CoAP in the transport layer.
The propose of this chapter is to elucidate and inform the reader about the differentcomponents that surrounds the industry 4.0 environment. The presented informationwill help frame the theory that will then be applied to the case studies presented furtheron.
4
2.1 Digital Twins / Cyber-physical Systems
A digital twin is a digital representation of a physical object. The copy displays theobject status, interactions and has real-time connection to the physical model, creating a”twin” of the real object in the desired network. Digital twins can have various purposes:simulation, real-world data and behavior prediction; ”A digital twin is an exact virtualrepresentation of a physical asset that looks, behaves, and can be engaged just like itsphysical counterpart”[9] By creating a virtual equal model to the physical one we caninteract with it virtually, implementing changes in real life if desired.
Assembling virtual models and applying real time data we can gather this informationand predict how one or the whole system will respond to a change. This leads to bigsavings since there’s no need to actually run the physical machines to know the finaloutcome. This process can be implemented in a factory assembly line, helping estimateand predict, by altering some parameters, how the output will turn out. This processalso saves time in the physical world to understand the system.
When mentioning digital twins it is needed to describe CPS. The term CPS was firstbrought out by Helen Gill at the National Science Foundation in the U.S and it makesthe integration of computational with physical processes, quoting , ”A physical systemis one realized in matter, in contrast to a conceptual or logical system such as softwareand algorithms”[10] ,being itself an intersection of both.
Therefore, CPS refers to embedded systems where the dynamics of physical processesare integrated with the network, software modeling and its execution. CPS uses theinput from a physical mechanism to introduce virtual response to the system and viceversa. This information can then be used to control a mechanism in the physical space;examples of CPS are medical monitoring, robotics systems, and IoT devices.[11]
It is possible to conclude, looking at the information presented, that digital twinsand CPS are intertwined. This union is essential for a Industry 4.0 integration sincefactories of the future are online and only with the right technology will this visionhappen. Therefore, industry sector has put large investment to this area by providing thenecessary tools to accommodate the demanding computational power that can supportthis systems [12][13].
2.2 Network
What does Network mean? By the definition of the Cambridge dictionary it is:”...a large system consisting of many similar parts that are connected together to allowmovement or communication between or along the parts” [14]. Therefore, it can beconclude that, in the machine world, it is through the network environment that devicescommunicate to exchange information.
Current networks are build on top of what it designated as IoT Transport layer usingsome of these protocol models: TCP/IP[15] and Open System Interconnect (OSI) [16].These protocols were first used on the internet developed by the Department of Defenseof the U.S., with all protocols being used in end-to-end communication [17].
5
Having a preset model of the network makes it easier to interconnect different hard-ware too different applications, for example: different Operating System (OS), Routers,Switches, etc. This idea can be translated to humans communicating to each other,following preset rules to understand one another.
On the OSI model 7 layers were defined, as seen in Figure 2.1. However, in theIndustry sector we can aggregate some layers into 4, as in the TCP/IP model. Thereare some advantages to this model on taking out some layers: not needing the extralayers, leading to its simplicity, and smaller overhead on messages due to the lower layerencoding. Some applications also don´t need as many layers as the OSI model. Factorydevices that use industrial buses dispose of the network layer,taking out the need fora specific layer for the network. Layer architecture of the OSI model vs TCP/IP ispresented on Figure 2.1.
Figure 2.1: OSI vs TCP/IP model layer representation
This chapter will now focus on layer 3 and 4 of the TCP/IP model which will be themodel taken in consideration from now on.
All the models exposed above work like the Russian dolls scheme, encapsulating in abottom up sequence, delivering from A to B a final encoded message. The final receivercan unwrap the layers, progressively decoding the message. The reverse process alsooccurs, and since the model is known to both parties, the decoding is already settled toeach layer. Application layer is the most ”upfront” layer to the user and data link thelast. Figure 2.2 presents how every layer is represented and delivered to it´s destinationbeing blocks in zone A the all the existent layers and in B the final format on how it isdelivered to the destination. The order of encoding, in the example, goes from 1 to 4.
6
Figure 2.2: TCP/IP model based ”capsules” representation
On the following sections we will focus on two layers, the transport and applicationlayer, and some protocols that run under it, following the TCP/IP model.
2.3 Transport Layer
Transport layer is a conceptual division of methods in a layered network stackedas the OSI model. [18] On this layer host to host communication from application isprovided. One of the most known protocols that runs on this layer is TCP 2.3.1 andUser Datagram Protocol (UDP) 2.3.2. These protocols will be presented on the sectionbelow.
2.3.1 TCP
TCP[19] is a full-duplex communication protocol so both parties can communicateon both ways and at the same time. It is commonly used on the global network andis normally complemented by the Ethernet protocol. This protocol ensures a reliablenetwork to send information by implementing sequence number to every message.
Connection is made with a 3 way handshake , establishing preliminary segments toensure connection. Therefore, it is essential to establish connection in this protocol.TCP itself is a ”heavier” protocol with an overhead header of 20 bytes. Establishingconnection between devices is a time consuming process that also needs to be taken inconsideration since it adds latency to the process. Figure 2.3 demonstrates a connectionexample of TCP.
7
Figure 2.3: TCP connection handshake procedure
With the mechanism of Acknowledgment (ACK) and sequence numbering the possi-bility of errors is reduced since the sender has to await for the recipient to confirm allthe received data.
2.3.2 UDP
UDP is a connectionless protocol where, unlike TCP, we do not have to establish ormantain a connection to the host. It´s a lightweight protocol since the headers are only8 bytes and has advantage over TCP by improving overall latency. There is no errorcorrection over the data sent, but error detection is enabled discarding all messages witherrors.
Congestion control is missing but, for some applications where data loss can bemasked, for example in audio/video streaming, the feature of unregulated and constantstream of data is ideal. The Network connection state is unknown to both parties. Datacan arrive in an unordered fashion since there is no segmented message system unlikeTCP.
2.4 Security
Having a connection to the internet can be seen as having a ”door” to the world.That ”door” needs security behind it to disable an attacker from entering. It was inMIT in 1969 that the first group ”hacked” the first computers making machines runninglike they shouldn’t. A few years later, in 1971, John Draper hacks a phone using atoy whistle from a cereal box [20]. This shows that, up from the beginning, the use
8
of Personal Computer (PC) with communications intrusion was an issue. Returningnow to 21´st century, there can be many ways to attempt unwanted data manipulation,not excluding transport protocols. In every transport protocol there are threats to thesystems which must be accountable for.
Some threats of a system can be:
� Denial of service attacks [21]
� IP spoofing [22]
� Comunication interception
� Timming atacks[23]
� Data spying in Servers and clients
Using the TCP/IP model layer 4 is the closest layer to the user. Therefore, it isalso the largest threat since poor interface design, deception and app layer securitycan lead to data theft. Some transport protocols, for example: MQTT have inbuiltsecurity using industry security standards such as National Institute of Standards andTechnology (NIST) Cyber security Framework and lightweight cryptography that ensurehigher security on the network Other protocols also include security in the transport layerusing Transport Layer Security (TLS) or DTLS.
2.4.1 Securing TCP with TLS 1.3 encryption connection
TLS operates in layer 5 (Session layer) of the OSI model which corresponds to theApplication layer in the TCP/IP model. TLS is a handshake protocol that establishesa encrypted communication between server and host. In order to use this encryptionprotocol we are required to use TCP on the transport layer, since it is the only protocolthat gives reliable communication, flow control and error handling over Internet Protocol(IP). The handshake process may be disturbed if any package is unnoticeably lost.
TLS has been updated with many versions,the most recent one being version 1.3.It´s not only the most secure but also the most efficient version, as it applies moresecure encryption methods and less communications between server and client. Thisadded efficiency comes by using the Diffie-Helman key exchange.[24]
The Diffie-Helman key exchange method was developed in 1976 by Whitfield Diffieand Martin Hellman as a mean to exchange cryptographic key. It allows entities theexchange of keys over an insecure environment, and securely obtain the common secretkey (golden key) without any prior agreement.[24] With this method we obtain the”golden key” by combining the public key, private key A and private key B, as seen inFigure 2.4
9
Figure 2.4: Client key combination for obtaining Secret Common Key
Figure 2.5 presents what each client will have before the connection occurs.
Figure 2.5: Residing client keys description
With this method each party can obtain the Secret Common Key with only 1 iterationwith each other and not putting any information on the message that could potentiallyuncover the Secret Common Key to any attacker.
Considering that the connection would start from A to B; client A will send thePublic key and the merging of the Public + Private A key to client B. Client B, mergingit´s Private B key, will then obtain the Secret Common Key. The opposite then occursand Client A will then obtain the Secret Common Key, making both parties able to sendencrypted data to each other. Figure 2.6 describes the connecting process.
Figure 2.6: TLS 1.3 connecting procedure between client A and B
10
2.4.2 DTLS
As TLS is for TCP, DTLS is for UDP. It works over UDP and is appropriate for con-strained environments. In DTLS it is implemented a TLS protocol, but with a diagramstructure.This makes the few necessary changes equivalent to a datagram protocol[25]that can handle loss or receive unordered messages. On Figure 2.7 it can be seen theposition of the DTLS protocol on the TCP/IP Model.
Figure 2.7: DTLS placement in trasnport layer
DTLS uses handshake encrypted communication as described on Section 2.4.1, mak-ing it possible to encode not only the first but also the last messages. Packet loss ishandled by a re-transmission timer that, when a specific time after a message has passed,it requests re-transmission of the last packet received. Also, to avoid having tamperedpackets inserted in the network, DTLS has a mechanism that prevents this from happen-ing by sharing a key called ”cookie”. When establishing connection, the server shares agenerated code extension (cookie) using the technique of RFC2522 [26]. This happensafter the client sends a ”Client Hello” - indicating the start of the connection. The clientwill then use the extension to send messages back to the server.
11
On Figure 2.8 shows a example of a handshake with an initial miss of a ”Client Hello”message.
Figure 2.8: DTLS Handshake procedure with failed first attempt
2.4.3 SASL Authentication
Simple Authentication and Security Layer (SASL) is a framework used to authen-ticate application protocols. This is used to prove your identity to the server whenaccessing it, by giving identification to the server of the user who is trying to establishconnection. Behind each SASL authentication there can be various mechanisms, suchas CRAM-MD5 and GSSAPI [27],
2.5 Application Layer
The application layer is the upmost layer on the TCP/IP model. Being the top layeron the OSI and TCP/IP model, it is an abstraction that refers to the direct interactionby the user with the network.
Protocols like AMQP, MQTT and CoAP run on this layer and will be the focusstudy of this dissertation.
12
2.5.1 MQTT
MQTT is lightweight protocol designed for easy IoT or Machine to Machine (M2M)applications where minimal bandwidth is used. Nodes can be turned off in intervals oftime. Due to its low message size, processing power and easy implementation, MQTTbecomes a good choice when using micro-controllers. Scalability is another advantagedue to its low resource and cluster implementations[28]. Clustering is a common termin machine learning, is also possible to deploy in MQTT since it offers solutions bymanaging different servers towards load balance and an efficient message routing.
Concerning its operation, MQTT is a topic based protocol on which each node canbe a subscriber or a publisher, directing all of the messages to a common broker. Thecenter of all communication in the system is the broker, which is responsible for storingand sending all information that subscribers or publishers request. Handling all thistraffic correlates with the fact that brokers need far more resources than the nodesitself, therefore most brokers run on PC or even micro-pc Linux environments, like theRaspberry-Pi.
Nodes can be either a subscriber or a publisher, altering their state by the typeof messages they send to the broker. In Appendix C, section C.2, the structure ofpackets that can be sent are presented in more detail. The broker then receives themessage and acts accordingly. Each parameter is described as a topic to which eachsubscriber/publisher can have access or update the value of that topic. The topicsreside in the broker’s memory and the nodes can only access it by requesting it to thebroker.
The process presented in Figure 2.9, is an example of a MQTT network with apublisher and a subscriber interacting with the broker, through message exchange.
Figure 2.9: Network arquitecture of MQTT [29].
Below in Figure 2.10 is presented a message exchange example on a MQTT network.The example below shows a node subscribing to the topic ”message” while the publishernode sends information to that topic, the broker as stated before is the center of thecommunication.
13
Figure 2.10: MQTT message exchange example
In these communication process between devices, some mechanisms assure that mes-sages are received, which is an important feature. MQTT has the Quality of Service(QoS) levels built-in, allowing the specification for each topic of the desired level. Theprotocol enables constrained devices [30] to operate on unreliable networks, due to QoSability to enable the assurance that all data will be received. This is useful since sometopics may have different grades of importance, with QoS presenting 3 different levels.
� QoS=0 : (At most once delivered) The receiver will not respond to the message,the message arrives to the receiver or not at all.
� QoS=1 : (At least once delivery) The receiver will at least receive one messagefrom the sender. This QoS sends the acknowledgment by using PUBBACK packet.
� QoS=2 : (Exactly one delivered) The receiver will receive exactly one message,this discards losses or duplicated messages.
2.5.1.1 Broker
A Broker in MQTT is the center of all message transferring. It retains all topicsand delivers/stores the data according to each request. The major point of failurein this protocol is the broker itself. If it fails, none of the messages can flow or beaccessed/stored, since this type of system is characterized by a centralized protocol.
14
There are many implementations of brokers available. The one used in this disser-tation is the Eclipse MOSQUITO [31], an open-source lightweight MQTT broker thatcan be run on PC, phones, embedded computers, and micro-controllers. Having thisalternative on implementing a broker makes it easy for integration on various systems.In the application of an Environment where the node count and incoming messages arealso high, the broker needs more resources than a node to operate.
2.5.1.2 Publishers/Subscribers
The publisher/subscriber architecture provides an alternative to traditional client-server architecture [32]. This approach decouples the node that sends(publisher) mes-sages from the node that receives(subscribers) them. Therefore, different nodes nevercontact each other or are aware of one another.
This decoupling occurs in many standards:
� Spatially: Publishers/Subscribers only need to know the hostname/IP and port ofthe broker
� By time: In most cases, MQTT messaging is done in real time, but the broker canbe set to store messages for clients that are offline.
� Runs asynchronously: since the protocol does not have tasks waiting until messagesare sent or received.
Messages exchanged between broker and publisher/subscriber can have many formsaccording to the function of the action required. In Appendix C the format and param-eters that messages can take are presented with more detail.
2.5.2 AMQP
AMQP is a network protocol operating under ISO/IEC 19464 standardized protocols[33].The network bonds micro-services with enterprise messaging serving, transporting andmessaging the protocol of a network. It easily bonds various platforms to a single pro-tocol, making it easy to implement on legacy apps. On the timeline of this protocol,various versions got launched with different description on how the protocol works. BothAMQP 0-9-1 and AMQP 1.0 versions will be presented.
2.5.2.1 AMQP 0-9-1
AMQP 0-9-1 is a messaging protocol that enables client applications to communicatewith middleware brokers. Publishers, consumers, and brokers are the basic componentsof the protocol and can be located on different machines. Figure2.11 presents a descrip-tion of a message exchange environment.
15
Figure 2.11: AMQP 0-9-1 Structure description
AMQP has similarities with MQTT from a publisher/consumer topology point ofview.However, when looked from inside the broker itself, a very different operating waycan be observed. Within the broker, the 3 different parameters that make the basiccomponents of the protocol(publishers, consumers and broker) will now be presented.
2.5.2.2 Publishers
Publishers are message broadcasters with a specific message. Simultaneously, theycan also work as a consumer. Publishers aren´t aware of consumers presence online,therefore AMQP implements acknowledgments messages to warn the publisher if theconsumer sends the acknowledgment message back to the broker.
2.5.2.3 Consumers
Consumers/Applications work as information receivers from the queues, with twoways of getting messages: ”push Application Programming Interface (API)” and ”pullAPI” With ”Push API”, the application gets the messages as the queue sends it, whereaswith ”Pull API” the consumer needs to request a specific message for the queue to sendit.
2.5.2.4 Brokers
Brokers are the ones that receive messages from publishers and route them to theright subscribers. The system uses 3 components, referred as ”entities” by the AMQPprotocol, connected in the following order: Exchange, Routes, and Queues. A real-worldexample of an exchange is a post office where the publisher sends the messages. Theroutes are the path messages take to the queues, with the queues being the house mailboxwhere they get stored. Therefore, there is no need for a queue if there are no consumer(House) messages that need to be consumed. Figure 2.12 presents a description of thesystem.
16
Figure 2.12: AMQP 0-9-1 broker description[34]
2.5.2.5 Exchanges
Exchanges reside within the broker. They receive a message and route them inqueues according to the exchange type. Depending on the exchange type different rulesof routing are used.
Specific routes and queues can be created depending on its application. The exchangeis where the route messages taken to the consumer is defined, using various exchangestypologies to implement in the broker, each with its purpose [35]:
� Direct Exchange
� Default Exchange
� Fan-out Exchange
� Topic exchange
� Headers exchange
Each message can have a specific key that bonds it to a route. This key can be useful,or not, depending on the implementation of the AMQP application.
Direct Exchanges deliver messages based on the routing key by binding a queue witha routing key waiting for a message to arrive with the same key. By using a Headerexchange it can discard the routing key and use only header information. Both theseexchanges use a ”key” to route the message, as seen in figure 2.13.
17
Figure 2.13: AMQP Direct exchange example
Even though Default Exchange also works as a Direct Exchange, the first works withroutes with no name by creating a routing key equal to a queue. This method is usedfor simple implementations and no configuration is needed. Fan-out exchanges, on theother hand, are used to a broadcast implementation where the exchange doesn´t lookfor the routing key, delivering a copy to every queue it is bound to. To a multi-casttopology, it is used the topic exchange that routes the message to one or various queues.
2.5.3 AMQP 1.0
Entering now a different version of AMQP, AMQP 1.0 [36], it is possible to see thatthe structure of the protocol has shifted from the previous version. Now, the networkconsists of Nodes connected via Links. Each link is connected to terminus which can beof two types: Targets or Sources. Messages travel from the Source to the Target in aunidirectional way and only leave the source if they meet the given criteria.
One of the advantages of this AMQP version is that no centralized broker is neededto route the messages, nodes are the ones responsible to store and deliver the messagesbetween themselves.
Containers, another element of AMQP 1.0, can house various nodes that can beidentified as Producers, Consumers or Queues.
Examples of containers are brokers and client applications. They communicatethrough full-duplex connections 2.6 with a reliable ordered sequence of frames consistingof unidirectional multiplexed channels.
Containers communicate with each other with sessions. Each container can havevarious sessions on one connection and various links on a session. Figure 2.14 presentsa description of how each entity talks amongst each other.
18
Figure 2.14: AMQP 1.0 message transfer description
2.6 Connection
To establish a AMQP process between two nodes a connection must be established.
Within the connection it can be established various channels that can be used todifferentiate/prioritize traffic, such as alerts and express traffic. Each channel is unidi-rectional and combined in paired frames that flow through them in a multiplexed order.Idle time is another parameter that can be helpful if used in different frameworks witha set interval of time as seen in Network Address Translation (NAT)[37]. Therefore,channels are unidirectional communications between two nodes that can be part of aconnection. Connection preamble dictates the transport protocol and version, with TLSand SASL security being negotiated inline 2.7.
Description of a connection is presented in Figure 2.15:
Figure 2.15: AMQP 1.0 connection description
2.6.1 Sessions
Sessions are bidirectional connections which choose two channels from the ones avail-able to communicate the sessions from. One connection can hold various concurrentsessions and each session has two channels connecting nodes. They provide the context
19
for the links to communicate2.6.2. Each session can run as many links as it wants, butonly with one link at a time.
Figure 2.16: AMQP 1.0 session description
This type of communication provides a window-based flow control model by imposinghow many transfer frames can a sender and receiver hold on its buffer at any given time.For IoT specifications, buffer control is essential, since the size of the constrained devicesmemory is, in general, small.
2.6.2 Links
Links are unidirectional and are built on top of a session, which can have variouslinks2.6.1. Communication between two nodes can be bidirectional, but two links needto be created, one for each direction. Links can have two type of messages, settled (atleast once) or unsettled(fire and forget) types. Messages come with a delivery-tag inwhich the source can track the delivery state of the message. Figure 2.17 presents anexample of a link.
Figure 2.17: AMQP 1.0 unidirectional link example
2.6.3 Message Frame
Message frame has a fixed 8 bytes of minimum size, while the other headers arevariable and depend on the type of message you send.
Figure 2.18: AMQP 1.0 frame description
20
2.6.4 Flow control
AMQP 1.0 offers greater options to define the message size to be parsed to the devices.This is called flow control and can be done over its two layers of communication. Theycan also be adjusted to our specifications on the Session layer and on the Link layer.
2.6.4.1 Session flow control
Session flow control protects the platform that is operating from excessive data ingest.Therefore, it is ideal for the applications where IoT devices have low internal memory.Messages flow in channels with different frames. These frames present different sizeswhich define the memory capacity required for a session. Only the sender can specifythis parameter.
2.6.4.2 Link flow control
Flow control on links is directed to the application-level messaging. Every link isassociated with a link-credit that represents the number of messages the receiver iswilling to accept. The receiver is the one who manipulates and increments/decrementsthe credit, controlling the link-credit and message rate. Link credit needs to be biggerthan 0 for messages to flow.
2.7 Security in AMQP
Transport-level security can be set in a 2 layered setup, TLS connection and SASL[38]authentication. Each one offers different added security levels by overlaying protocolsrequired in this version.
TLS, as described on Section 2.4.1, is a layer built on top of AMQP. In addition tothat, a SASL authentication can be agreed on to allow communication between devices.
TLS provides the security and privacy on the transport layer, while SASL authen-tication doesn´t allow unknown entities to enter via the application layer, providingall-around security on the two most top-level layers.
2.7.1 SASL in AMQP
In AMQP implements three built-in mechanisms that can be used to authenticateour connection: PLAIN, AMQPLAIN, and RABBIT-CR-DEMO[39].
� PLAIN mechanism is the default for clients and servers on RabbitMQ.
� AMQPLAIN is enabled by default on the server side and when using Python client
� RABBIT-CR-DEMO is not enabled by default and uses a challenge-response au-thentication.
21
2.8 Constrained Applied Protocol (CoAP)
CoAP is Standardized RFC 7252 which uses a similar model as Hypertext TransferProtocol (HTTP) however it machine interaction in CoAP they act as server and clientunlike HTTP. CoAP [40] is based on a REST API and is widely used for Web servicesas it can transport on ”thin” Networks.This protocol is adapted to be used on small IoTresource-constrained devices with low memory and low processors. Running over theUDP protocol it is a highly efficient protocol with low latency, can be also compared toa lightweight HTTP
One of the advantages is that the node is the center of the message transfer and not aperipheral, so a node is responsible for the transfer of information to the server. Thereforethe node can be client and the ”broker”. It can also change and delete information onthe server, using the REST commands, unlike MQTT. This offers various advantagesover data control and organization.
Figure 2.19 presents a CoAP network example, where the node is our focus deviceand the servers are our services. The Node will receive and transmit information to theservers. This topology is similar to web services.
Figure 2.19: CoAP network description
2.8.1 Representational State Transfer (REST)
REST is an architecture that provides standards between computers and the internet.It intends to implement an operation where the client and the server-side can operateindependently without known programming or iteration changes between them.
This term is described as stateless where the client and server don´t know the stateof each other. A RESTful application is a term used for the capacity of an applicationto implement REST principles. So CoAP implements them but it isn´t a REST applica-tion. On a REST based protocol there are 4 distinct commands, also present in HTTPprotocol, listed below.
� GET : Read information
� PUT: Update information
22
� POST: Create new information
� DELETE: Delete information
2.8.1.1 GET
On the GET method, the server returns the representation of the source identifiedby the request. After that, the payload must be in accordance with the HTTP content-format and must be set accordingly. Messages come with an age header, this parametertells the time in second that the object is in the proxy stack [41]. This parameter disablesreplications of the message to the client when the age is overcome the message will stopbeing replicated on the client. Presented in Figure 2.20 is a diagram of a GET response.
Figure 2.20: REST GET message response is set
2.8.1.2 PUT
PUT method is used to create or update the HTTP resource identified by the requestidentified.
2.8.1.3 DELETE
DELETE method is used to delete the HTTP resource identified by the request.Source receives a response if the delete is successful and represent a valid variable.
23
2.8.1.4 POST
POST method is used to create or update the resource identified and that the entityon the request accepts, as new subordinate, the resource identified.
PUT and POST command can be seen as equals the difference is that send POSTcommand multiple times can have the side effect of creating the resource multiple timeswhere the PUT only updates.
2.8.2 Message format
Messaging in CoAP is done with very low frame size, 4 bytes. It is transported overthe UDP or DTLS datagram on a binary format. Messages circulate using differentknown file types: XML [42], JSON [43], CBOR [44].
The frame has a 4 byte fixed header followed by a variable length optional headers:Token, Options and Payload.[40] Figure 2.21 presents the description of the messageframe in CoAP.
Figure 2.21: CoAP message frame description
The Messaging model is rather simple, the client sends messages to the server thenthe server sends an ACK as soon as it receives the messages. These types of messagescan be defined with the QoS of the protocol. As seen in the GET section all messageframes work as described in Figure 2.20.
2.8.3 Quality of Service for Message Delivery
CoAP uses a simple QoS service where the messages can be of two types
� Confirmable Messages
� Non Confirmable (fire and forget)
Confirmable messages are used since UDP, however this mechanism doesn´t guar-ante that the message arrives to the destination. Implementing a ACK messagesolves that issue. Non confirmable messages are used when non sensitive messagesare put on the network and the end user is comfortable on not knowing if themessage will be received or not
24
Chapter 3
Benchmarking Protocols
3.1 Description
In a factory network environment many challenges can arise, namely regarding thecommunication protocols of the system. For this reason, testing the protocol beforedeployment is key to achieve a conclusive idea relative to performance. The tests mustindeed comply with the standards relevant to context, including the reality of the systemand the environment. From the protocols presented in the previous chapter only MQTTand AMQP will be considered regarding the benchmarks. For the sake of complete-ness CoAP was introduced since it is a protocol aimed for constrained device but forthe implementation is not going to be studied due to the limited time frame that thedissertation takes place.
The protocols selected have undergone tests regarding message rate, big data trans-fer, node count and performance maintenance, to help settle which protocol is bestapplied, and therefore the chosen one, for the final solution developed for this disserta-tion. The tests (Test 1 and Test 2) will be described in this chapter and relevant furtherexplanations and comparisons will take place.
3.2 Testing methodology
“Test 1” was carried out to test the top message rate of the protocols, utilizing thevarious topics/queues. In addition to this, the second part of “Test 1” is constituted bysimulating and analyzing the addition of various nodes on the network, sending smallmessages to the broker. “Test 2” was designed to analyze how the protocol deals withand maintains message delivery while big messages are sent to the broker. These testsare carried using python libraries that both have implemented. The methodology ofthe tests regarding message rate, equipment and parameters evaluated was the same forevery protocol. Although being different protocols each with its library the node wasdeveloped so that both were a mirror of each other.
25
3.2.1 Test hardware setup
As the broker, a laptop, designated PC1, was used. It uses an Intel i7 running at3.4 GHz connected to a router using a TP-link Universal Universal Serial Bus (USB)dongle. On the client side a desktop PC ,designated PC2, also running i7 processor at3.4 GHz connected using the dedicated network port of the motherboard. The routerwas a standard ZON Gen3 router.
Table 3.1 depicts the hardware and software information of the setup.
PC1 PC2
OS Linux Windows 10 Pro
CPU Intel I7 (3.4Ghz) Intel I7 (3.4Ghz)
RAM 16GB 12 GB
Ehternet TP-Link USB 3.0/Gigabit Ethernet Onboard
Router Zon Gen 3 Zon Gen 3
Python x 3.8.2
Mosquitto 1.6.10 x
AQMP 3.8.5 x
Table 3.1: Table containing tests hardware and software specification
A python script was used to publish and receive messages on both protocols. TwoPC´s with cable internet connection , with Static IP, deployed the nodes and respectivebrokers. Further detail and code to each protocol can be found in appendix D.
26
The visual description of the system on Test 1 and 2 is presented in Figure 3.1.
Figure 3.1: Testing methodology description
27
3.2.2 Test 1
The message rate capabilities of the protocols were analyzed by making use of “small”messages sent to 3 different topics/queues in “Test 1”. The script aimed to send messagesat each topic/queue at the maximum rate possible.
Messages were received simultaneously from the 3 topics/queues, on a different vir-tual node. Starting with 1 node and increasing all the way to 15 nodes maximum(sequentially or until the system became unstable), the values observed with each ad-dition on the test were registered accordingly. Each node connected to 3 topics/queuesand sent each one the messages 1,2 and 3 respectively.
The published messages will be the following:
� Message 1 is a simple ”Hello World”
� Message 2 and 3 are a ”Message x:+ str(a*1)” where ”a” goes from 1 to 500.
Message 1 has a size of 12 bytes and message 2 and 3 vary from 10 bytes to 13 bytesdepending on the parameter ”a” incrementation cycle. Message 2 is designed to act asa variable value on the message string, making the variable message size a parameterthat the protocol will handle, adding a variable number that increments on each messagesend.
3.2.3 Test 2
Big data transfer regarding a file of 756kB trying to achieve heavy loads on the systemwas analysed on “Test 2”. A rate of 1ms on transfer was attempted. The tests weredone in the span of around 1h with increments of one node connected. The nodes sentthe message to the same subscriber/queue, being that each node ran the same script.
3.2.4 Data gathering methodology
Data equitation methodology was the same in both protocols. In the message ve-locity test, AMQP provides a Graphical User Interface (GUI) that plots automaticallymessage rate velocity, whereas MQTT does not. To address MQTT’s issue, a Node-redflow was created that allowed the message rate of the MQTT to be plotted on its dash-board GUI, adding a visual representation to the message rate in MQTT. To measurebrokers resource usage, a ”top” command was implemented, which displays the percent-age of CPU and memory usage in comparison to full potential capacity on each runningprogram. In order to consider all of the parameters analyzed in the tests laid out in anholistic perspective, the average values taken from each node were registered in an excelsheet, which led to the graphs drawn.
28
3.2.5 Calculating maximum message rate in python
Message rate performance depends on many factors, some being the programminglanguage and hardware used. Therefore, to know the exact average message rate gener-ated by the code, the main cycle of publishing messages needs to be timed. The codewas made using ”timeit” library in python. It generates 30 cycles that in the end of thetest prints them in the terminal.
Figure 3.2 presents a flow chart of the code used. Listings D.4 and D.1 in Annex Dpresent the code used.
Figure 3.2: Flow chart of the python code
The 30 samples per code were saved and transcribed in the following graphs presentedin Figures 3.3 and 3.4. The blue dots show the seconds that one cycle takes to occurwhile the orange dots represent the conversion of that same data but in messages persecond.
Figure 3.3: AMQP 30 sample cycle time
29
Figure 3.4: MQTT 30 sample cycle time
By analyzing the results presented above, it can be seen that some oscillations onthe rate take place. Nevertheless, when trying to achieve maximum rate, it is commonto see jitter. If the average of all samples is considered, MQTT had a message rate of3690 and AMQP of 4933. Table 3.2 presents this rates.
Average message rate
MQTT 3690
AMQP 4933
Table 3.2: Table containing average message rate in MQTT and AMQP
Therefore it can be concluded that one node can successfully run the speeds indicatedabove on Table 3.2. In spite of this, multiple node instances may cause bottlenecks inthe broker.This will be tested in the section below.
30
3.3 Tests with maximum message rate
By implementing the code on 3.2.5 that outputs the maximum rate, on both proto-cols, the message rates of this test were obtained. These rates are represented in Figure3.5 and 3.6 referring respectively to MQTT and AMQP.
Figure 3.5: MQTT maximum rate in test with maximum rate
A good progression up until node 2 was observed in MQTT. In node 3, jitter wasregistered with an amplitude of 0 to over 20000 messages a second. This indicates thatthe protocol was not able to deliver at this message rate. Figure 3.6 presents the test inAMQP protocol.
Figure 3.6: AMQP maximum rate in test with maximum rate
31
The AMQP performance was even better than MQTT, since it reached 5 nodes withstability whereas MQTT only reached 2. On the 6th node message rate performancestarted declining, with similar jitter as MQTT.
In order to guarantee accuracy and relevance to the tests considered, more nodeswere needed to be added to the system.
Therefore, parameters were put in the main loop that slowed down the loop cycletherefore slowing down message rate. The code was timed again using the same methodin Section 3.2.5. After testing the best ratio between message rate and node count, amessage rate of around 606 messages per second for MQTT and 1910 for AMQP wasverified. The code that achieved the message rates mentioned is presented on listingsD.5 and D.2 in Annex D Figure 3.7 and 3.8 presents the flow chart of the nodes withdelay in AMQP and MQTT respectively.
Figure 3.7: AMQP code flowchart with delay
32
Figure 3.8: MQTT code flowchart with delay
Message rate generated with codes described above are presented in Figures 3.9 and3.10
Figure 3.9: AMQP 30 sample cycle time
33
Figure 3.10: MQTT 30 sample cycle time
After running these new tests (layed out in Section 3.4) with the message ratespresented above, it was concluded that no bottlenecks were encountered. The instabilityverified in the first tests, which used maximum speed, was not seen in the case of Figures3.9 and 3.10. Tests 1 and 2 were done using the message rates presented in Table 3.3.
Average message rate (msg/sec)
MQTT 606
AMQP 1910
Table 3.3: Message rate generated on each protocol
34
3.4 Test 1 results
On this section Test 1 will be set following the procedures explained previously.
3.4.1 CPU load
Figures 3.11 and 3.12 show, respectively, the CPU load on each protocol: AMQPand MQTT.These figures plot the maximum and mean value during time frame of thetest.
Figure 3.11: AMQP broker CPU load with the increase of nodes
Figure 3.12: MQTT broker CPU load with the increase of nodes
35
A big difference can be noticed in the CPU load between both protocols. Whenlooking at both graphs simultaneously, namely the initial value of the CPU load axis,it is noticeable that AMQP is 55% higher than MQTT. In AMQP, CPU load increasesprogressively and almost linearly with the increase of nodes. In the last node (15) bothgraphs show a difference of 503% compared to MQTT CPU load. On the other hand,in MQTT CPU load does not increase substantially with the increase of nodes.
3.4.2 Memory use
Figure 3.13 depicts the memory use on both protocols.
Figure 3.13: AMQP vs MQTT memory use with the increase of nodes
Memory had a similar behavior to CPU usage. AMQP had a constant increase onmemory use with each node increase. In contrast, MQTT had vestigial increase withthe node count.
36
3.4.3 Message rate
The final and most important test is the message rate comparison. In Figure 3.14the average value to every node added was plotted for both protocols.
Figure 3.14: AMQP vs MQTT message rate comparison
As expected, the initial single node rate for each protocol was 1910 and 606 for AMQPand MQTT respectively. For MQTT a linear average message rate was withstood betterthen its counterpart, showing that after node 9, AMQP breaks and suffers loss in itslinearity.
37
In Figure 3.15 the graph on theAMQP GUI can be seen.
Figure 3.15: RabbitMQ broker GUI graph message speed on the incremental test
Taking Figure 3.15 into consideration, it is possible to see that until node 5 theprotocol follows a linear path, but starts to fail and demonstrate random behavior andsmaller increases in rate as the node count goes up. AMQP falls short 15% of theexpected maximum value of 28650 msg/sec when reaching 15 active nodes. In additionto that, in the 12th node, the broker decreased its ability to send messages back to thereceiver node, as shown by the green line.
38
Figure 3.16 presents the plotted graph of message rate in MQTT.
Figure 3.16: MQTT broker message rate of 1 topic
On the MQTT side, message rate per node is around 606 per second and maintainsa better constant message rate than AMQP, having a 6.7% decrease of the initial ratein the last node. However, the random rate variations are wider and more constant inAMQP, even with a smaller message rate.
39
3.5 Test 2 results
This test was started with a 756 kB file. However, after 2 nodes, the system saturated.Therefore, it was concluded that for files of that size an early saturation can be expected.The benchmark with 756kB file can be seen in Appendix B. Due to previous results,the file was switched to one 50 times bigger than the intended file (4.0kB) to send onthe implementation (see Chapter 5), resulting in a file with 200kB. Both protocols aretuned to have the same node output of 12 messages per second using the same principledescribed in Test 1 Section 3.4.
3.5.1 Message Rate
The plot of the protocol is presented in Figures 3.17 and 3.18, the message rate canbe observed while increasing the nodes. On Figure 3.17 the yellow line is the messagerate and the green one is the deliver ACK rate that the receiving node sends.
Figure 3.17: Message rate in Test 2 viewing from AMQP gui
40
Figure 3.18: Message rate in MQTT viewing from Node-RED dashboard
The results show that in this configuration, MQTT after 8 nodes is not able tosustain its stability, whereas AMQP can, achieving a predictable behavior until 8 nodesare active.
Below are the graphs that contain an average message rate, CPU load and memoryusage. Figures 3.19, 3.20 and 3.21 follow.
Figure 3.19: Message rate on AMQP and MQTT
In Figure 3.19 the linear message rate per second can be visualized on both protocols.It can be pertinent to mention that there is a break on node 8 in MQTT, which is notverified in AMQP.
41
3.5.2 CPU load and memory use
Figure 3.20 presents the CPU load while undergoing the tests.
Figure 3.20: CPU load in top command in AMQP
As seen in Test 1, AMQP uses more resources than its counterpart. CPU load inAMQP had an almost linear behavior, whereas MQTT´s load was almost non existentwith change.
42
Figure 3.21 presents the memory use while undergoing the tests.
Figure 3.21: Memory use in top command in MQTT
The most prominent result was in the memory usage. AMQP had an exponentialgrowth, starting with 5 nodes active, although the usage of memory in the end of thetest was less than 10%. MQTT only had changes with the 8 nodes active.
43
3.6 Final Conclusions
Below on Table 3.4 the tests data top values are compared side by side. On the table3.4 ”Test 1” is assigned as ”T1” and ”Test 2” by ”T2”.
Max CPU load Max Memory Use Node Rate (K/s)
AMQP (T1) 315 19 1.9
MQTT (T1) 91.6 2.4 0.67
AMQP (T2) 91 15.8 0.012
MQTT (T2) 15 3.5 0.012
Table 3.4: Test results with highest performance levels aquired
In ”Test 1”3.4, which used a small size messages, AMQP used almost double themessage rate and still maintained better stability than MQTT. Jitter is constant onboth protocols, but MQTT has far greater jitter then AMQP on both tests. The higherperformance in AMQP has the cost of high resource use a CPU and memory use. How-ever, in memory use, the findings suggest that it mostly increases when the queuescannot export the message as the rate it receives. Memory seems to work as the bufferfor stored messages. The same situation happened in ”Test 2” in AMQP. At node 5memory increased exponentially (Figure 3.21),while delivery ACK decreases with theincrease of node count (Figure 3.17). Theses factors reduce upwards scalability of thisprotocol, unlike MQTT which performs conservatively but uses far less resources.
On ”Test 2” ,section 3.5, the protocols message rate was identical while the nodecount increased. MQTT in the end became unstable when adding node 8 (Figure 3.18),whereas AMQP did not. AMQP however, although using less than 10% memory, startedto show exponential growth at node 6. It can be concluded that both protocols canhandle big data messaging at those message rate, even though MQTT failed after node8. Therefore, AMQP performed better and, as seen in ”Test 1”, had a higher resourceuse then MQTT.
Resource wise, it is odd that in MQTT almost no difference is noted in he resourceusage, but since it is a protocol for high scalability it would need to reach the thousandsof nodes to see the resource curve upward [45]. On this bench tests its not possible toreach those node counts.
Taking the information presented it is possible to conclude that, for high scalability,operating in environments with networks on heavy load, constrained devices and largedata gathering, MQTT is the protocol that should be used in the application of theIndustry 4.0 solution.
44
Chapter 4
Use case
4.1 Introduction
A use case to demonstrate that protocols, like the ones described above, can beimplemented in a factory setting is essential to support the technical strength of theapproach proposed in this dissertation. Real-life cases need to be implemented so thata solid ground to sustain our findings can be made. ”Korber Supply Chain PT” is acompany that builds automatic warehouses using automatized conveyors and stackers.This company presented a proposal to build a solution that would be fitted to one oftheir cranes.
The first talks with the company took place when the global pandemic of COVID-19started and regulations were already in place. However, even with those limitations, aproposal to build a system for another company factory warehouse stacker crane, whosename cannot be disclosed by commercial reasons, using Siemens gateways and PLC cameto place. The idea was to get information from one of their cranes and platform. Thefinal goal of the system was to do preventive maintenance and equipment supervision inreal-time. The proposal fitted perfectly the scope of the dissertation and was accepted.However, it was then transmitted that only in September the factory’s warehouse wouldbe accessible to test the implementation, due to the pandemic regulations. In the mean-time, the system using the same hardware and inputs in a virtual environment wasdeveloped.
When the time came to test in the company’s factory warehouse, in September,physical access was not allowed, due to internal regulations, but Korber Supply ChainPT provided in their establishments an elevator with the same internal system as inthe factory warehouse. Their differences are in the sensor quantity installed. Therefore,they differ only in the variables itself and quantity, but the system is the same, althoughinternet connection will not be available to the IOT2050.
Therefore, this dissertation was divided in two instances, Version 1.0 and 2.0, being1.0 the project aimed for the company factory warehouse, and 2.0 at the Korber SupplyChain PT establishments. The architecture, on both Versions, is the same. However,there will be a slight change in the flow running in the IOT2050 to accommodate the
45
Data Block (DB) information change.
The project was designed and tested in the laboratory using Version 1.0 requirementsand the findings are presented in this dissertation. Version 2.0 will be a modified versionof 1.0 since the architecture is the same on both. Therefore, all the work done for Version1.0 is still viable and usable. Version 2.0 will be meant to acknowledge if the work donein the lab is usable in real-life scenarios.
Implementation (Chapter 5), and benchmarking ( Chapter 6), will follow the require-ments of Version 1.0.
4.2 Description
Korber Supply Chain PT layed the description of the system implemented on theircranes. It is required to acquire information from a configured DB (DB2000) on aSiemens PLC. The data specification was provided as follows: format type, offsets, andnames of each variable which can be seen in the table presented in Appendix F. The otherrequirement is the gateway that receives data, which will be the SIMATIC IOT2050.
The Siemens IOT2050 is a Debian based system with an ARM processor [46]. The2 RJ45 Ethernet ports simplify the debugging process, while being connected to theGlobal network.
The PLC used will be the S7-300 CPU 315-2 PN/DP that is already in use andconfigured in the factory. It will be programmed by Korber Supply Chain PT thatcollects all the sensor data of a stacker crane located in the factories.
4.3 Requirements
The company did not impose any language for programming the IOT2050 gateway.However, some manipulations and actions that should take place in the IOT2050 werepinpointed. These points are:
� The message should only be sent to the cloud when:
- there is an actual change, not counting with the timestamp, or
- every 60 seconds, as a way of keeping a heartbeat message;
� if no updates are sent for a given pre-defined time, the equipment will be consideredoffline(STK Status ”Offline”);
� the CMD fields cannot be sent empty, when no commands were ordered;
� JSON files cannot exceed 4.0kB.
These requirements are set in accordance to some received variables. These will beassociated with main variables.
46
4.3.1 Main variable description
Appendix F describes all variables available on the Stacker Crane, although, to com-ply with the requirements, only a few need to be mentioned, which are the Timestampand STK Status . Table 4.1 presents the description of the variables used in the require-ments.
Variable Description
Timestamp Provides the current time and date on the PLC
STK Status Provides the status of the machine, if it is moving or halted.
Table 4.1: Table describing main variables that are in the requirements.
After managing the requirements, messages get processed to a JSON file sent toAzure IoT Hub. The system architecture is then ready to be developed.
4.4 Architecture
The data itself flows in a single path starting from the crane, and ending ultimatelyin the cloud.
The system consists of 5 main blocks.Thr flow is layed out as follows: Stacker Crane,PLC, IOT2050, Cloud, and finally the dashboard. In Figure 4.1 we have the diagram ofit.
Figure 4.1: System architecture and hardware description
Siemens has integrated into their devices a communication protocol called PROFINET.PROFINET can be used in parallel with an IP protocol, communicating to any deviceconnected to a router/switch.
Therefore, the PLC uses the PROFINET protocol communication to transmit to theIOT2050 and vice-versa, if needed. Configuring the IP, Sub-mask and Gateway of thespecific network will be necessary to enable the connection between each device to aRouter/Switch. This will allow the information to flow freely between devices.
Configuring the PLC and IOT2050 to the Router/Switch network will enable everySiemens hardware that supports PROFINET to be visible to any user that is connectedto the network. Using the same Ethernet port, the IOT2050 connects to the globalInternet, allowing messages to reach the cloud.
The dashboard itself can be seen as an independent system since it doesn´t need toreside on the factory network. The messages sent to the cloud are then fetch from anyPC that is running the dashboard, enabling it´s use world-wide.
47
As discussed and tested in previous chapters, MQTTis a good fit for the solutionasked by the company. Therefore, the application layer that runs between the IOT2050and the Azure Cloud uses MQTT messaging. For the firmware, the IOT will run Node-red v1.0.2, a JavaScript flow base programming platform which provides simple integra-tion with future additions as a reliable work platform. Node-red comes pre-installed inthe IOT2050 image file. Siemens uses and runs ”how-to” examples running on Node-redwhile providing support and upgrades to the nodes that are used regarding the Siemensintegration. The choice of Node-red when Versions 1.0 and 2.0 were brought up allowedan easy integration of new machines and DB. Figure 4.2 presents the communicationprotocol between the IOT and Azure cloud and the software in the IOT2050.
Figure 4.2: IOT2050 to Azure communication description
Node-red was chosen to run the dashboard, since any PC running a Node-red servicecan run it and collect the data from the Azure cloud. The dashboard is composed of oneflow that creates a GUI where the user can see the messages that arrive into the cloud.The flow will access the IoT hub repository and capture messages incoming, processingthem and then plotting them on a table-based dashboard.
4.4.1 Summary
This chapter established all architecture parameters, allowing to proceed to the im-plementation chapter.
48
Chapter 5
Implementation
After presenting the chapters concerning architecture and system design, this disser-tation will now proceed to present the implementation of the system previously described.This chapter will focus on the software part of the dissertation, describing hardware con-figuration, architecture, and a detailed description of the code implemented.
5.1 Test configuration
All the tests were made using a SIEMENS IOT2050 with the ”Example Image”provided by Siemens and a SIEMENS ET200s. In Appendix A there is a ”how-to”description on configuring IOT2050, where any configuration described regarding theIOT2050 can be found. PROFINET protocol is used to enable both devices to commu-nicate with each other while operating on top of TCP/IP, connected via Ethernet cablesto a ZON GEN 3 router [47] providing Internet access. The ZON router was chosen toproceed with this study based on availability. On every large network it is importantto attribute an ID to every machine so that machine managing becomes easier. In thisnetwork, the ID is the device IP. Therefore, every device was configured with a Static IP.The PLC was programmed using Totally Integrated Automation (TIA) Portal V11 withthe DB provided from Korber Supply Chain PT. This included its offsets and respectivedata types. TIA Portal is a work tool for integrated engineering using Siemens hard-ware, and serves many purposes, from simulation to programming the various equipmentprovided by Siemens. Figure 5.1 presents the system configuration and Table 5.1 liststhe software and hardware used.
49
Figure 5.1: Test system configuration overview
Components Version
IOT 2050
PLC ET 200S
Ehternet TP-Link USB 3.0/Gigagbit Ethernet
Router Zon Gen 3
Cloud Microsoft Azure Iot Hub
Node-RED v1.0.2
TIA Portal V11
Table 5.1: Table containing hardware and software description for benchmarking thesystem
With the system environment described, this dissertation will move on to presentsoftware development. The IOT2050 is going to run an instance of Node-red, installedby default. Node-RED[48] is a browser-based flow editing programming platform, wherean idea can be arranged using wires to connect nodes on a palette. It takes advantageof the lightweight Node.js [49] making it ideal for implementation in constrained devicesas it minimizes resource utilization.
50
5.2 Software developed
In order to simplify the software development process and facilitate its understanding,a flowchart diagram was developed, presented in Figure 5.2. The flowchart representsthe data processing workflow at the IOT2050 Node-red flow which will be described inSection 5.3. Regarding the requirements presented in Section 4.3 and nodes capabilities,the following flow was thought out.
The IOT2050 boots with the configurations done previously (Annex A presents a”how-to” guide for configuring the device and first boot) By default, the gateway imme-diately starts the last flow saved. If the specified PLC is not connected to the network,then a reference JSON message will be sent as a way of indicating that no message hasbeen sent when the IOT2050 booted, activating the heartbeat function with no values.The reference JSON message contains default values that the user can identify whenreceiving the messages that indicates that no PLC has been connected.
New messages received by the PLC are collected in the format of JavaScript objects.If a message is detected, then a series of events are triggered. If new information isdetected in one of the variables, excluding the timestamp, the flow updates the localheartbeat file and triggers the STK Status to ’R’. In parallel, another module is con-verting the Binary-Coded Decimal (BCD) information from timestamp to decimal stringformat. Lastly, the JavaScript object containing all variables is updated with the newtimestamp.
The Object content is then converted to JSON using a conversion node. This sendsthe JSON message to the Azure hub.
If no new messages arrive in 60 seconds the newest object list is sent as a heartbeatmechanism. Adding that after a user defined timeout value, the STK Status is updatedto ’F’.
The system scans every 4 seconds the network state of the PLC. A dedicated node,”node-red-contrib-isonline” [50], is used to check if the PLC is online. When detectingan offline state, STK Status is updated to ’F’. Otherwise, it maintains its state.
Therefore two parallel instances are running: the main flow and the PLC stateverifier. Figure 5.2 and 5.3 present a flowchart, respectively, of these two instances.
51
Figure 5.2: Flowchart of data processing and acquisition in the flow
Figure 5.3: Flowchart of PLC state verifier in the flow
52
5.3 Implementation on Node red
Figure 5.4 depicts the flow that receives the information, processes it and finallysends it to the Microsoft Azure IoT Hub. The flow can be subdivided into 6 moduleseach being responsible for different tasks. The system is composed by the followingmodules:
� Send immediate incoming data to IoT Hub(Incoming messages).
� Heart Beat module (HeartBeat)
� STK Status Update(Update STK Status variable)
� Timestamp processing from BCD to string(Timestamp processing)
� PLC network state verifier (PLC network state)
� Convert JavaScript object to JSON and send it to Azure Iot Hub (Send to Azure)
53
These modules compose the Node-red flow that is seen in Figure 5.4, differentiatedwith a black box with the respective tag name and number. The flowchart in Figure 5.2and 5.3 describe the flow presented in Figure 5.4.
Figure 5.4: Flow running on IOT2050 that collects PLC information and sends them tothe Azure IotHub
The flow chart in Figure 5.2 can be linked to the Node-RED flow presented above.Block 1 in the Node-RED flow is the action ”Write preset JSON”, which then goes todecision box ”Incomming messages”. Starting with the route ”No” the action of ”SendHeartbeat every 60s” is the first to appear. This action is linked to the Block number4. Down the same path decision ”Elapsed time without new variable is bigger thanpredefined time” is made in Block number 2, where, depending of the time with no newmessages/variables, the STK Status is changed.
Returning to decision box ”Incomming messages?” to path ”Yes”, it follows theinput ”Read PLC variables”. This action correlates to all S7 nodes called: ”no STKSatus”, ”no timestamp”, ”Complete message no times”, ”Complete message no times”,”Year”, ”month”, ”Day”, ”hour”, ”min”, ”sec”. The S7 nodes automatically check ifthe variables are the same or not, therefore the decision box ”New variables” correlatesto all S7 nodes. Going to the ”Yes” path, follows the action of ”Update Local File” thatis made in Block 1.
54
Action ”Reset Heartbeat timer” is made in Block 4 following action ”Process BCDtimestamp to string” and ”Merge timestamp with rest of variables” which is made re-spectively in Blocks 6 and 4. The following action ”Convert to JSON” and ”Send toAzure” is made in Block 5.
The flow chart in Figure 5.3 correlates directly with block number 7 of the Node-REDflow. A deeper look into these modules is made in the following sections.
5.3.1 Timestamp Processing
The PLC generates a timestamp variable sending it to the IOT2050. This variablecomes in BCD format and, therefore, it must be processed into a readable value. Thismodule was implemented so that the BCD value would be converted into a string. Thefollowing information is sent with the timestamp: year, month, day, hour, minute, andsecond. Each one of these parameters resides on a Byte of an 8 byte array. The year islocated in Byte 0, the following corresponding to the month value (Byte 1 = month).When reaching Byte 5, the value corresponds to seconds (Byte 5 = seconds). Theremaining 2 bytes exist to maintain the DB structure of a 4 byte grouping. Table 5.2shows the structure of the array.
Byte Variable
0 year
1 month
2 day
3 hour
4 minute
5 seconds
Table 5.2: Timestamp byte variables order
Figure 5.5 depicts the module responsible for receiving and processing the timestampfrom the PLC.
Each node ”node-red-contrib-s7” [51] represented in Figure 5.5 is called: Year, month,day, hour, min and sec, respectively. They retrieve a byte from the DB and send it tothe ”join” node. This node is responsible for aggregating n messages into an array.This array gets parsed to a function node called ”Date Joiner” where the array is read,converted to decimal format and finally converted to a string. The string then get´sparsed to a flow variable. The JavaScript code in the function node can be visualized inAnnex E.1
The timestamp then get´s merged in the JavaScript object that will form the outgoingJSON message, as discussed in Sections 5.3.2 and 5.3.3.
55
Figure 5.5: Flow running on IOT2050 that is responsible for date processing
5.3.2 Incoming message
This module receives all the variables except the timestamp, and as soon as a valuechanges on the variable list it is automatically forwarded to the ”Sending to Azure”module and the JavaScript object is updated.
The output of the ”S7 node” is connected to a ”change” function node and to the”Heartbeat” module. The ”change” node is where the Timestamp variable gets updatedwith the latest data from the flow.date variable. The Heartbeat module, addressed inSection 5.3.3, uses the data from the output to update the object list to the most recentone.
Figure 5.6 presents the module composition.
Figure 5.6: Flow running on IOT2050 that sends incoming messages and merges pro-cessed timestamp value in object list
5.3.3 Heartbeat module
Figure 5.7 presents the heartbeat flow composition.
The Heartbeat module has the functionality of maintaining a constant ”heartbeat”of the device, sending a message every 60 seconds as an indicator that the IOT2050 isonline but doesn´t have any new information from the PLC. It receives 2 inputs: onefrom the ”Immediate message”, presented in Section 5.3.2 and another from a ”inject”node containing the preset JSON. This is needed when the IOT2050 boots and no PLCis present to create the first set of variables to the heartbeat.
56
This module is composed of 2 trigger nodes and a change function node. On thetrigger node, the main one sends the last payload injected every 60 seconds, while theother one, below, is connected in a loop. This was made so that the trigger gets rearmedas soon as it detects that the other trigger sent a message. The triggers get reset afterany new message comes from the input.
Lastly, on the exit of the triggers, there is a change function node that does twothings. Firstly, it merges the most recent timestamp value with the JSON message.Secondly, it updates the STK Status variable to the most recent one using the flow.statusvariable 5.3.4.
Figure 5.7: Flow running on IOT2050 that sends messages every 60 seconds as a heart-beat of the machine
5.3.4 Update STK Status variable
This module updates the STK Status in the outgoing JSON and stores a new in-coming message to a flow.json variable using the function node ”Store json in file”.
With the same heartbeat module principle(Section 5.3.3), the flow.json variable needsto be filled with a predefined JSON as soon as the IOT2050 boots. After that, theflow.json only gets update with incoming PLC messages.
In the ”no STK Status” there is a ”S7 Com” node that is outputting every new mes-sage except the STK Status and its timestamp. These do not influence the online stateof the PLC and do not trigger the trigger node with changing values. The trigger node”Trigger Online Status” outputs a ”R”, indicating ”Ready” whenever any value changes,which then proceeds to the ”flow.status update”, updating the flow.status variable. TheJavaScript code in function node ”flow.status update” is presented in Listing E.3.
The other ”Trigger Offline Status” outputs a ”F”, indicating ”Faulty”, when thetimeout set by the user has passed without new values. The input of the trigger is a ”S7Com” node that outputs a message whenever any new value, excluding the timestamp, isupdated. This node is connected to the function node ”flow.status update”. All triggersget reset whenever a message passes through.
Figure 5.8 presents the Status update module.
57
Figure 5.8: Flow running on IOT2050 that updates the STK Status variable in accor-dance to the PLC activity
5.3.5 PLC network state
In this module, the state of the PLC is checked every two seconds. Every two seconds,the ”Trigger error” node activates the ”node-red-contrib-isonline” [52], which looks forthe configured IP in the local network. If nothing is found the device is consideredoffline, outputting a ’F’ to the change node. This node parses the inputted data to theSTK Status variable.
Figure 5.9: Flow running on IOT2050 that updates the STK Status variable in accor-dance to the connection of the PLC in the network
5.3.6 Sending to Azure
Figure 5.10 it depicts the module described. As observed in Figure 5.4 the modules”Incoming messages” and ”Heartbeat” converge to a link node that connects them tothis module. The JavaScript object that arrives is converted to a JSON file which thenis injected in the ”node-red-contrib-azure-iot-hub” [53] called ”Azure IoT Hub”. Thisnode is responsible to send the information sent to the to our IoT Hub, finalizing thecycle of information from the PLC to the cloud.
58
Figure 5.10: Flow running on IOT2050 that converts a object list to a JSON and sendsit to a Azute IotHub
This concludes the system sensors collection and parsing in the gateway. As describedbefore it was developed a Node-red dashboard that plots the messages sent in real-timeto the Azure-cloud.
5.4 Dashboard
The method developed to receive and visualize messages that are sent to the cloudis using a Node-RED dashboard. This will let the user visualize the data in real-time.Being a browser-based platform any user can visualize the dashboard, when connectedon the local network, having access to the information without being required any priorsoftware installation.
Figure 5.11 presents the diagram that shows the flow of information.
Figure 5.11: Dashboard diagram description
59
5.5 Dashboard
The dashboard was developed as a means to debug and visualize the system’s in-coming messages to Azure. The implementation is based on a project made in Node-red[54]: This project was then shaped to the needs of this implementation.
The dashboard is organized as a table with columns representing the variables androws each message received by order of arrival. It is possible to filter the results shownan act on the data as follows:
� Activate/Desactivate message recording
� Set maximum number of messages that are displayed
� Delete all information presented
� Filter key variables on each message showing only messages that have that valueon the entire table.
This implementation is possible with the use of Tabulator [55], a JavaScript library,that deploys an interactive table/graphics/charts manipulator featuring all the needs forthis dashboard. Tabulator can be integrated with the Node-RED system since it sharesthe same language.
Figure 5.12 presents the flow that deploys the dashboard.
60
Figure 5.12: Dashboard flow that receives json from Azure and organizes it on a dash-board function
The connection to the cloud is made with the node called ”Azure IoT Hub receiver”(”node-red-contrib-azure-iot-hub” [53]) used for receiving of messages from the IoT hub.From that node, all information is then processed so that the user can visualize it.Coming from the Azure Hubs comes a JSON message that is converted to a JavaScriptObject list which can be processed by the nodes upstream.
Given the flexibility of Node-RED there are some features that can be easily added orremoved. Adding more variables to the table viewer only requires modifying the ”tablehandler” node tabulator section. Adding or removing the columns section is made byinserting a section with ”title”, ”field” and ”width”. More features can be added, forexample: filters and, with a timestamp variable, the time format wanted to be displayed.The full list is available in Appendix E.3 but the example shown in Figure 5.13 providesa frame of all the configuration types examples used in the code.
61
Figure 5.13: Part of the code that implements the table position, filtering, time formatand viewing of the incoming messages variable
Deploying the flow in Figure 5.12 makes the dashboard shown in Fig. 5.13 availableto the user. The user has 4 interactive buttons and filters in some variables of thetable, up or down buttons for defining the maximum number of messages to be storedin the table, On/Off button for record toggle, and a delete button. A slider to navigatesideways and up/down on the table is available in the tabulator GUI.
62
Figure 5.14: User view of the dashboard implemented in Node-RED
63
In a factory setting there are other factors to take in consideration and only visu-alizing received messages may lead to an incomplete user experience. One of the otherparameters to take in consideration are the internal metrics of the IOT. Especially withthe new IOT2050, which can overheat when not having enough any airflow. This ver-sion deploys an aluminum body shroud that revolves all around. Therefore its crucialthat temperatures are kept between limits of 0 to 50C°when rail mounted vertically. Tomonitor those variables it will be added metric analysis to the dashboard: CPU usage,CPU temperature, memory usage, Ethernet port traffic, Reboot/Shutdown command,and recording of them all.
The flow developed is shown in Figure 5.15.
Figure 5.15: Flow that contains the metrics generator for the user dashboard
64
To acquire the internal sensor reading and parameters of the IOT2050 it is neededto implement the node ”Exec Node”. ”Exec Node” is already installed by default inNode-RED. It enables to write system commands on a flow parsing the commands likeit is done on the IOT2050 console. These values were parsed to dashboard widgets sothat the user can visualize them.
Table 5.3 lays out all the commands parsed in each ”Exec node” with its respectivename.
Node Name Command
Set Time Date timedatectl set-timezone ”Europe/Lisbon”
date date
uptime uptime -p
Get Local IP hostname -i
User whoami
CPU0 Load(grep ’cpu0 ’ /proc/stat;sleep 0.999;grep ’cpu0 ’ /proc/stat)—awk -vRS=”” ’{print ($13-$2+$15-$4)*100/($13-$2+$15-$4+$16-$5)}’
CPU1 Load(grep ’cpu1 ’ /proc/stat;sleep 0.999;grep ’cpu1 ’ /proc/stat)—awk -vRS=”” ’{print ($13-$2+$15-$4)*100/($13-$2+$15-$4+$16-$5)}’
RAMawk’/MemTotal/{t=$2}/MemAvailable/{a=$2}END{print 100-100*a/t”%”}’ /proc/meminfo
Disk df | awk ’/ \/$/{print $5}’
Reboot sudo reboot
Shutdow sudo shutdown -h now
Table 5.3: ”Exec Node” internal command list of each node implemented
Some values are static and are simply written on the dashboard. These parametersare: IP on the 2 ETH ports, Runtime, and date/time, while others are parsed on dials,ETH received and sent, MEM, RAM CPU usage and CPU temperature. In parallel, thevalues dials get stored internally on a file using the ”file” node.
Values get updated/stored in different periods following their role in the system:
� 15 min: Local IP, User,RAM and Disk
� 5 sec: CPU Core load,CPU temperature and uptime.
� 1 sec: ETH traffic both receive and send and date
Completing the dashboard flow description the system is now ready to be tested andbenchmarked in a simulated scenario, before being applied in a factory environment.
65
Chapter 6
Benchmarking system
Upon finishing designing the system, benchmarks were made to evaluate its per-formance and possible boundaries. The tests are made in accordance to Version 1.0Data block and requirements. Since this Version is more demanding than Version 2.0 itis expected that the system production will perform slightly better than seen in thesebenchmarks. The final product, that will use Version 2.0, deploys less variables, there-fore less resources are needed to run the system. Siemens PLC default clock settings runaround on the 30 millisecond mark, which will be the maximum rate that the IOT2050will output messages. These benchmarks aim to test Node-RED stability and messageloss in the network.
The first test aims to evaluate the overall system stability. The second one aims tounderstand how message transmission is affected by the network bandwidth utilization.The first test will consist in 24h runs with various messages rates. On the second testthe message rate varies, up to 30 ms cycles, with and without interfering network load,observing its influences in the system.
For the first test four 24h runs were made with different message rates sending toAzure IoT hub. The clock cycle was 60 seconds, 1 second and burst. The 60 secondcycle equals the heartbeat time expected if no activity is detected and 1 second cyclesequals to having movement on the crane. Burst simulates dynamic use of the machines,having a heartbeat mode active for 15min followed by a 1 min burst of messages spacedof 30 ms get´s deployed. This burst mode puts the system close to a dynamic real worlduse.
For the second test were carried out 30 min runs with clock cycles at 100 milliseconds,50 milliseconds and 30 milliseconds. These clocks were selected to test if with the increaseof clock cycle, message loss and network saturation would be seen. With these cyclestwo environments were tested, one without and another with additional network load.
66
6.1 Message bandwidth measurement
To measure message bandwidth it was installed ”nethogs” [56] in the IOT2050. Thissoftware enables monitoring the messages on each running instance, in this case Node-RED. Sending messages to Azure IoT Hub is the output network port therefore moni-toring that port displays the message bandwidth on each case.
6.2 Test load configuration
The test bed is the same as in the Implementation, Chapter 5 Section 5.1, but itis needed to add a network load generator. The network load was generated with thepackETH-2.0 packet generator tool [57], which allows a flexible and dynamic configura-tion of the load injected on the network. A laptop running packETH was connected tothe same router as the other devices, via an Ethernet cable and a USB Ethernet adapter.The program would then send packets to a desktop in the network creating interferingtraffic on the local network 6.1.
Figure 6.1: Test system description
The optimal load bandwidth that suited this configuration was at 10 MB/s, sinceanything higher would interrupt all Internet service and anything less would not haveany effect on the system. Before every test there would be a pause time frame so thatpossible lost messages could be delivered not interfering with the following tests
67
6.3 Test 1The first part of the test was conducted by running the flow 5.4.To run this test the
heartbeat module was modified to send the desired message rate, respectively 60 and1 messages per second. Figures 6.2 and 6.3 show the respective graphs containing themessage count every 5 minutes in a 24h time frame to the Azure cloud.
w
Figure 6.2: Message count every 5 minutes in a 24h time frame on a 60 second messagerate
Figure 6.3: Message count every 1 minute in a 24h time frame on a 1 second messagerate
68
On these two instances no message loss was detected. The bandwidth was the fol-lowing respectively, on the 60 and 1 second interval: 1.051 kB/s and 5.570 kB/s. Com-paring with the previous results experience gathered from the MQTT benchmarks doneon Chapter 3 the system behaves as expected at these message rates.
To create the burst effect a different flow was needed. A message burst module wasdesigned as seen in Appendix E.0.1, that every 15 minutes outputs a burst for 60 secondswith a message interval of 30 milliseconds. This flow was added to the ”Send to Azure”module injecting the messages directly. Running for 24h it produced the graph shown inFigure 6.4. Message bandwidth on these runs were 136.526 kB/s on the burst scenarioand 5.570 kB/s in the heartbeat mode.
Figure 6.4: Message count every 15 minutes in a 24h time frame on the burst test
Observing the overall 24h time frame it can be observed that the frame rate did notstay constant as seen in Section 3.5 having a small deviation with respect to the average.In this example the maximum deviation seen was of 0.25% from the expect value.
This observation does not affect the outcome of the test but is a remark on thesystem to take in consideration, since some implementations might need to face thesevariations
69
6.4 Message rate with/without load
Test 2 aims at evaluating the probability of successful message delivery in diversenetwork conditions.
Firstly the number of created messages is counted. To do so a counter node (node-red-contrib-message-counter [58]) was added in the input of ”Sending to Azure” node asa method to count the messages sent to the cloud. The number of generated messagesis then shown on the terminal via a debug node.
In Figure 6.5 the flow described above is presented.
Figure 6.5: Counter node added to the ”Send to Azure” module
6.4.1 Message rate without load
Following the test structure presented in the beginning of the chapter, the test beganwith 100, 50 and 30 milliseconds of interval without network load. Figures 6.6, 6.7 and6.8 plot, respectively, the number of messages generated in Node-RED versus messagesreceived in Azure with a 100 milliseconds, 50 milliseconds and 30 milliseconds cycle.
Figure 6.6: Node-RED and Azure message rate with a 100 millisecond cycle
The IOT2050 maintained an average message rate of around 585 messages perminute, being under the expected 600 messages per minute, showing some spikes anddelays on the message sent vs message received in Azure.
70
Figure 6.7: Node-RED and Azure message rate with a 50 millisecond cycle
It then follows the message rate of 50 milliseconds as Figure 6.7 show.Figure 6.7 shows the test results with a 50 milliseconds cycle.Due to the higher load it is observed a wider spread of un-synchronized spikes
throughout the test with the biggest being in the beginning, although no message losswas detected in the end. For the last test Figure 6.8 presents the test with 30 millisec-onds.
Figure 6.8: Node-RED and Azure message rate (msg/min) with a 30 millisecond cycle
71
With a message rate of 30 milliseconds bigger spikes are seen in the rate.Therefore a relation between the message rate and the jitter of the output can be
seen. As the clock-cycles decreases, the load increases which leads to a bigger jitter inthe output.
Table 6.1 presents the difference between the messages received on Azure and mes-sages generated in the device, ending at with the SUM, at the bottom of the table, of alldifferences in the 3. The difference between the messages transmitted and received oneach point is marked with a green or red color. Red indicating that Azure received lessthan it was generated and green the opposite. Figure 6.9 plots the maximum divergencepresented in each cycle of 1 minute.
72
Cycle Time
Minutes 30 ms 50 ms 100 ms
1 -2 0 0
2 2 0 0
3 1 0 0
4 -1 0 0
5 -6 -2 0
6 6 0 0
7 0 -2 0
8 0 -1 0
9 0 0 0
10 -1 2 -4
11 1 0 4
12 -9 -3 0
13 9 1 -1
14 -1 1 1
15 0 -1 0
16 1 2 -1
17 -1 -1 1
18 1 -2 0
19 1 3 0
20 -1 1 0
21 1 0 0
22 1 -4 0
23 0 0 0
24 -1 3 2
25 1 0 -2
26 0 -4 0
27 -1 2 0
28 1 -2 0
29 -1 0 0
30 -1 0 0
Total Sum 0 0 0
Table 6.1: Table containing the difference between messages received, generated andSUM without load.
73
Figure 6.9: Plot of maximum divergence on each time cycle
Looking at the figure and table above it is seen that as the clock cycle decreasesbigger set of differences are seen, as well as the biggest divergence is noticed on thehigher message rate. Therefore as the message rate goes up the stability of messagedelivery goes down. This is expected since the flow of information is greater floodingthe system. Despite this effect no message loss was detected in the end.
74
6.4.2 Load environment
The environment was configured with a 10 MB/s load using packETH-2.0.On Figure 6.10 the results of a test with a 100ms cycle time are seen. On this test
the network load was stooped at minute 19, since no internet connection was detectedafter that time frame. After message rate stabilized for 4 minutes, the flow was stopedat minute 26.
Figure 6.10: Node-RED and Azure message rate with a 100 millisecond cycle on anetwork with load.
On this test it can be seen that there are no message entering on the Azure hubuntil minute 15. After minute 18 the router stopped responding, therefore manualdisconnection of the load was made. Immediately after there was a rush of messagesinbound however, the sum of messages of that peak doesn´t reach the messages thatshould have come. It was expected to receive in the whole test 18000 messages but itwas only received 6187 which equals to a 34.92 % loss.
75
Figure 6.11 followed the same results as the test before. The network load wasstooped at minute 17 and then after message rate stabilized the flow was interrupted atminute 25.
Figure 6.11: Node-RED and Azure message rate with a 50 millisecond cycle on a networkwith load.
There was a similar effect on this cycle in minute 4 were a margin of messages camethrough. In this case only on minute 17 was the load disconnected allowing messages toreach Azure. The expected message count in the whole test should account for 36000but only received 16494, which equals to a 54.2 % loss.
76
On Figure 6.11 the network load was stooped at minute 14 and then after messagerate stabilization between 19 and 21 the flow was interrupted at minute 21.
Figure 6.12: Node-RED and Azure message rate with a 30 millisecond cycle on a networkwith load.
Lastly on the 30ms cycle test the same results were obtained having the same peakwith the disconnection of the load. With this message rate it was expected receiving60000 messages but only received 13472 messages which equals to a 77.92 percentageloss.
77
6.5 Conclusions
6.5.1 Test1 conclusions
Test1 shows that the system can reliably send messages to Azure, while operating ona standby mode and in a burst configuration. It is to note that the effect shown in theburst module needs to be taken in consideration if a high inflow of messages is expected.Table 6.2 illustrates the message bandwidth for every time interval.
Time interval (s) Max. bandwidth (kB/s) Min. bandwidth (kB/s)
60 1.051 0.089
1 5.570 5.234
Burst 136.526 5.570
Table 6.2: Message bandwidth in each time interval with the maximum and minimumvalues
6.5.2 Message rate with/without load conclusions
On the loaded network, with this setup, it wasn´t possible to get any subtle effect onthe network performance, messaging stopped abruptly or resumed as expected. Normalbehavior was experienced, as if no load was in the system or it would get total loss inthe whole network. My thoughts are that my router is unable to withstand these kind oftest so it either works or fails. With that in mind i can still take some toughs with thistest. The tests proved that on overwhelmed networks the system can store messages andrecover some information as it is visible on Figures 6.10, 6.11 and 6.12. All of them havepeaks that surpass the nominal message rate which indicates that past message injectionis made when load is taken off. Table 6.3 presents all the message loss comparison onall tests.
Cycle time Messages received Messages expected Loss (%)
100 ms 6187 15000 34.92
50 ms 16494 36000 54.2
30 ms 13472 60000 77.92
Table 6.3: Table containing message received vs expected from the load tests
It is possible to conclude that the system can send and sustain some information,varying from 58 % to 77.92% depending on the message rate, without crashing andloosing all it´s content. My considerations are that a environment with good networkrouter is needed not to suffer from the same issues felt on these tests.
78
Chapter 7
Practical application
7.1 Stacker crane description
In the Korber Supply Chain PT premises there is a prototype of a 12 meter cranedesigned to stack palettes automatically. This prototype is where the solution developedin this dissertation was tested.
On the base of the crane lies a cabinet where all the controllers, including theIOT2050, are stored. The IOT2050 will be connected to the internal network of thiscabinet, collecting all the data from the PLC. Figure 7.1 presents a picture of the pro-totype.
This crane is equipped with a vast set of sensors, which some are inactive sincethey are used when interconnected with other machines. In the test scenario the mainfocus will be on variables that are changing and presenting useful data of the machineparameters, for example: Laser encoder reading, consumed current and position. Thecrane operates between three levels, which are referred as position 1, 2 and 3. Thedistance between the top and the movable platform is read by a laser encoder. Figure7.2 presents the system schematic.
On this machine position 0 is the upper level and the value of that position is refer-enced at 0 meters. Position 3 is the floor level and describes the maximum readings ofthe encoder.
The internal network comprises a switch inside the cabinet connected to a routerthat enables wireless connection to the whole system. The IOT2050 gateway transmitsdata through this connection. The cabinet also implements a ventilation system thatcools all electronics. The experiment was carried for one hour.
7.2 Hardware description
The network environment was the same as in the lab tests previously done, addingonly a switch to handle the additional devices. On site it was established the network,seen in Figure 7.3. To connect to the stacker network there is wireless router on top ofthe cabinet, disabling the need of cable to debug the system, in this case being connected
79
Figure 7.1: Stacker crane picture
to the IOT2050. This router connects to a Siemens switch, which the IOT2050 and PLCare connected too.
The hardware description is in Table 7.1.
Name DescriptionPLC Siemens CPU 1512SP F-1 PN (6ES7512-1SK01-0AB0)Gateway IOT2050Switch Siemens 5 Ports Switch Ethernet (6GK5005-0BA00-1AB2)Router DIR-605L
Table 7.1: Table containing the description of devices in te network of the stacker crane
After establishing connection all devices were available to connect via laptop. TheNode-RED dashboard and flow can be accessed by means of a laptop connected to theLocal Area Network (LAN).
80
Figure 7.2: Stacker Crane schematic with positions layout and laser encoder placement
7.3 Test Methodology
There were two main objectives to test, test the stability of the system lookingfor issues/errors and to evaluate the MQTT messaging capabilities while operating.Therefore there were defined 2 different test scenarios: Run the machine for 1h collectingall data that the IOT2050 receives from the PLC and in the same scenario add MQTTmessaging from the IOT2050 to a MQTT broker, via wireless connection, with themessages that the PLC generated. The broker was implemented on my laptop usingeclipse MOSQUITO. The original plan to test MQTT was to use it as the protocolthat would deliver messages to Azure IoT hub. However, no Internet connection wasavailable on the site therefore no cloud implementation was possible. Instead it wascreated a MQTT broker in a Lenovo Yoga 720-15IKB laptop that the IOT2050 wouldconnect and send MQTT. Node-red was used to design a system that connects to thebroker and collect the incoming messages and stores them internally. The goal of thisdesign is to receive the messages and evaluate the message loss ratio.
81
Figure 7.3: Stacker crane cabinet description
7.4 Test Enviroment
The hardware itself is conditioned in a metal cabinet, in a rack configuration. Thecabinet itself has a fan that circulates the air inside, cooling all the electronics. Weatherforecast of the day while running these test is presented in table 7.2.
Temperature C° Humidity %
Weather 27 52
Table 7.2: Weather forecast on the day of testing
7.5 MQTT messaging environment
Changes done for accommodating MQTT messaging from the IOT2050 to the brokerresiding in a laptop were only additions to the main flow discussed on Chapter 5. Thenode used to send messages was the default installed MQTT node configured with theIP of the laptop broker and the common topic. On each device a file is stored internallyand parsed using excel after the test is done. These files are used to count how manymessages were sent and delivered by comparing each timestamp. Figure 7.4 shows thenode used for sending messages to the broker and Figure 7.5 presents the laptop flowthat receives and stores the messages.
The test runned for 30 min and all data was recorded into local log files.
82
Figure 7.4: MQTT message sending addition to main flow with message per minutestorage
Figure 7.5: MQTT message receiver flow collecting data from local broker
7.6 Data interpretation
7.6.1 Stacker Crane run
The stacker crane runned for 1h while the IOT was reading and saving the PLCmessage output.During this period the stacker repeats end-to-end movement cycles witha periodicity of 70 seconds, as shown in Figure 7.6 Looking at the data generated bythe stacker, Figure 7.6 plots the graph that correlates the encoder value with the motorcurrent consumption. Figure 7.7 presents the two variables, from the PLC, that indicatethe start and finish of Y position. The analysis of these data allows concluding that alldata matches the movement of the stacker and, as expected, current is only drawn whenthe stacker is going up. This movement correlates to going to position 0, in the otherdirection the motor doesn´t draw energy.
83
Figure 7.6: Position and current consumed by the crane over time
Figure 7.7: Start Y level vs finish Y level
84
The data shown in the Figures above correlates to what is expected, the cycle is,considering the positions in Figure 7.2: 0 → 2 → 1 → 2 → 0. Correlating to the cycleand what was said previously only when the stacker moves from 2 → 0 and 2 → 1 doesthe motor consume a current, setting it´s peak at 39 Amperes.
7.6.2 IOT2050 metrics
It will now follow the analysis of 1h of metrics on the run of the IOT2050. Thesemetrics were CPU temperature, CPU core usage, flow cycle time and bytes received inthe ETH port of the IOT2050. Starting from the CPU it can be seen its temperatureon Figure 7.8.
Figure 7.8: CPU temperature for the 1 hour test
Temperature from the IOT rose from 42C°to 44C°at the top, averaging at 42.67C°.This is the normal temperature behavior since every system needs time to reach itsstable working temperature on the given environment.
Figure 7.9 plots CPU usage over time.
85
Figure 7.9: CPU dual core usage for the 1 hour test
Although random peaks are seen on both core usage CPU average was at 16.13 % forcore 0 and 14.41% for core 1, leaving more than half the processing power for supportingother process to the IOT, if needed. The following parameter that was analyzed was thecycle time of the Node-RED flow. This cycle time is measured when a message is sentfrom the S7 node and ends in the end link that connects to the ”send to Azure” node,completing one cycle.
Figure 7.10 presents the consecutive cycle times from a 1h period on the IOT2050.
86
Figure 7.10: Flow cycle time to process under the 1 hour usage
Average cycle time in the test was 8.88 milliseconds which by comparing to thePLC standard CPU clock does not represent a bottleneck, since its lower than the 30msstandard.
Figure7.11 presents the bytes received on the Ethernet port.
Figure 7.11: ETH data received under the 1 hour usage
87
In this scenario the only data that could be received by the IOT2050 is from thePLC. It is seen that peak message was 212500 bytes, averaging on 4230 bytes per secondand a total of 28616013 bytes received on the entire run.
In Table 7.3 illustrates all the average parameters on the evaluated variables in thissection.
Variable Average
CPU temperatue 42.67°C
CPU Core 1 Usage 16.13 %
CPU Core 2 Usage 14.41%
Flow cycle time 8.85 ms
Average ETH traffic 4229.76 bytes
Total byte received 28616013 bytes
Table 7.3: Table containing IOT2050 system variables evaluated in this chapter.
Finishing this run of tests, the machine was stopped and the MQTT environmentwas set and turned on.
88
7.6.3 MQTT messaging
After establishing connection between the IOT2050 and broker, the machine was leftto run for 30 minutes. All messages generated and received were saved to enable theoutgoing message rate of the IOT2050 to be ploted to see eventual losses. The flow ofinformation was from the IOT2050 to the laptop receiving an average payload of 3.93kB per message.
Figure 7.12 depicts the messages sent vs received in the 30 min test and in Table 7.4it´s presented the SUM of each device and total loss.
Figure 7.12: MQTT message sent vs message received with stacker crane messages
Name Messages
IOT 1193
Laptop(MQTT Broker) 1179
Loss 14
Table 7.4: Table containing the SUM of each message sent and received
In Figure 7.12 it is seen that in some occasions message sent and received are differentmeaning that in some points messages could be lost or received late. By doing the sum ofall these instances it was observed that these values were different, confirming that therewas messages lost. in Table 7.4 it can be seen that 14 message´s were lost, that equalsto 1.17% of the total message sent. Wireless communication are more unpredictable
89
than cable connection. Many parameters can influence its performance and reliabilityfor example; the environment in which the network communicating. In this test thestacker is inserted in a all metal warehouse with a lot of electromagnetic interferencecoming from energy cables for AC motor, electrical motors themselves and other Wi-Finetworks on site.
My educated though is that all these interference’s might have been responsible forthe small part of messages lost.
7.7 Dashboard
The user interface used is the dashboard discussed in Chapter 5, making it possibleto visualize messages incoming to the IOT2050 on a table like environment.
In Figure 7.13 a screenshot of the information presented using the dashboard can beseen.
Figure 7.13: Tab 1 of the dashboard displaying the table with the information of theplc, CPU usage of each core and memory and disk usage
While doing both tests the dashboard was used and tested for bugs. The table formatworked as intended, being able to store all content and providing a stack organizationof messages. The gauges showed the temperatures, CPU core usage and Disk/Memoryof the system. It was done another test of simultaneous use of the dashboard by twolaptops connecting to the network and visualizing the dashboard at the same time. Inthe course of this test no interruptions were detected as well. It was thus possible toconfirm that the dashboard operates at least for a limited number of variables with cycletimes of the order of tens of millisenonds correctly with one or two users.
90
7.8 Conclusions
On arrival to Korber Supply Chain PT adding the IOT2050 was simple as it wasonly necessary connecting the Ethernet cable to the switch and configuring it to the newnetwork environment. The IOT2050 console and Node-RED made it very simple andeasy to do so.
Starting the first test, the dashboard was opened the ”Record” button was enabledand all messages started to flow in, appearing in the table as they arrived with no issues.All messages were available and if needed filtered with the programmed variable widget.Metrics were also displaying as soon on the front page of the dashboard. Log files werealso verified in between the test and no issues were detected between and after the test.It can be concluded that it was a successful test with no issues.
On the second test, in the set conditions, as observed on the data collected onsection 7.6.3, there was a message loss ratio of 1.17 %. This may result of the fact thatthe transmission of messages was wireless and inserted in a ”difficult” environment withother networks and electromagnetic interference sources.
The only set back on the system was the MQTT communication not having a 100%success rate but that can eventually be corrected using a cable connection since in thebenchmarks (Chapter 3) no message loss was detected. Despite this issue all the testswere successful and indicate that the system can work with a factory setting using thedevice intended.
91
Chapter 8
Conclusions
The fourth industrial revolution pushes data gathering to a new level, presenting theopportunity for technologies, new markets and businesses models. The incorporation ofsoftware and hardware makes developing innovative solutions possible. As such, a generalassessment of network protocols was made before benchmarking them to be selected forfinal implementation. In the benchmark scenario all protocols worked as expected, andthus the MQTT protocol is suitable for the class of applications considered in this work.
Increasingly factories deploy more sensors, actuators and logic functions which addsthe need to visualize data in real-time. The IOT2050, as many other gateways, is acheap and reliable alternative to achieve this purpose, therefore a solution surroundingthis device was created and tested in laboratory and finally in an active warehouse. Alaboratory assessment was made before being implemented with a automatic stacker,with tests showing good levels of reliability, stability and speed of the IOT2050. The re-sults show that protocol, hardware and simulation worked in a reliable manner verifyingthat the system is capable of being deployed with the stacker.
The experimental results obtained in the field trial with the actual stacker, showthat the simulation and virtual environments were correct as it worked without anyadjustments in the software. All variables were read and the dashboard visualizationwas correct. Therefore it can be concluded that the gateway could be implemented withthe stacker providing remote data gathering. This tool proved to be essential for easydata visualization, remote monitoring and if needed to easily adapt to changes in themachine, due to the flexible nature of the programming language used.
92
8.1 Future Work
Future work may include :
� API integration for custom dashboard capabilities.
� Exploring multi PLC system integration and boundaries.
� API development implementation.
93
94
Bibliography
[1] H. com Editors. Henry Ford. [Online]. Available: https://www.history.com/topics/inventions/henry-ford (Accessed 2020-08-28).
[2] Who is the Father of the PLC and Why was it invented? [Online]. Available:https://realpars.com/father-of-the-plc/ (Accessed 2020-08-23).
[3] Industrial Revolution — Definition, Facts, & Summary. [Online]. Available:https://www.britannica.com/event/Industrial-Revolution (Accessed 2020-08-19).
[4] Governo lanca estrategia para a industria 4.0. [Online]. Available: https://www.portugal.gov.pt/pt/gc21/comunicacao/noticia?i=20170130-mecon-industria-4 (Ac-cessed 2020-10-22).
[5] Henry petroski. [Online]. Available: https://cee.duke.edu/faculty/henry-petroski(Accessed 2020-10-25).
[6] Facebook, Twitter, S. m. s. options, Facebook, Twitter, LinkedIn,Email, C. L. URLCopied!, and Print. ’the essential engineer’ byhenry petroski. [Online]. Available: https://www.latimes.com/archives/la-xpm-2010-feb-21-la-ca-henry-petroski21-2010feb21-story.html (Accessed 2020-10-25).
[7] What is IoT | microsoft azure. [Online]. Available: https://azure.microsoft.com/en-us/overview/internet-of-things-iot/what-is-the-internet-of-things/ (Accessed2020-10-25).
[8] What is cloud computing? a beginner’s guide | microsoft azure. [Online]. Available:https://azure.microsoft.com/en-us/overview/what-is-cloud-computing/ (Accessed2020-10-25).
[9] Engineering simulation giant Ansys unlocks value and opportunity with AzureDigital Twins. [Online]. Available: https://customers.microsoft.com/en-us/story/795283-ansys-partner-professional-services-azure (Accessed 2020-08-23).
[10] Cyber-physical systems: A fundamental intellectual challenge.[Online]. Available: https://www.college-de-france.fr/site/gerard-berry/guestlecturer-2013-12-11-17h00.htm (Accessed 2020-08-23).
95
[11] M. Sirjani, E. A. Lee, and E. Khamespanah, “Verification of cyberphysicalsystems,” Mathematics, vol. 8, no. 7, p. 1068, Jul 2020. [Online]. Available:http://dx.doi.org/10.3390/math8071068
[12] Industry 4.0 : The heart of european investment ac-cording to plan. [Online]. Available: https://www.ibaset.com/blog/industry-4-0-heart-european-investment-according-plan/ (Accessed 2020-10-25).
[13] PricewaterhouseCoopers. Big investments with big impacts and rapid returns. [On-line]. Available: https://www.pwc.com/m1/en/publications/industry-40-survey/big-investments.html (Accessed 2020-10-25).
[14] Network — significado, definicao em dicionario ingles. [Online]. Available:https://dictionary.cambridge.org/pt/dicionario/ingles/network (Accessed 2020-08-24).
[15] D. Comer, Interligacao de Redes com TCP/IP–: Princıpios, Protocolos e Arquite-tura. Elsevier Brasil, 2016, vol. 1.
[16] S. Wang and Y. Wu, “Computer networking a topdown approach 6th edition,” in2017 International Conference on Service Systems and Service Management, Jun.2017, pp. 1–5.
[17] O TCP/IP. [Online]. Available: https://paginas.fe.up.pt/∼mrs01003/TCP IP.htm(Accessed 2020-08-24).
[18] Introducing the Internet Protocol Suite (System Administration Guide: IPServices). [Online]. Available: https://docs.oracle.com/cd/E19683-01/806-4075/6jd69oa77/index.html (Accessed 2020-08-24).
[19] B. A. Forouzan, TCP/IP Protocol Suite, 2nd ed. USA: McGraw-Hill, Inc., 2002.
[20] A brief history of hacking. Library Catalog: encyclope-dia.kaspersky.com. [Online]. Available: https://encyclopedia.kaspersky.com/knowledge/a-brief-history-of-hacking/ (Accessed 2020-07-30).
[21] What is a Distributed Denial-of-Service (DDoS) Attack? — CrowStrike.https://www.crowdstrike.com/cybersecurity-101/distributed-denial-of-service-ddos-attacks/. (Accessed 2021-2-27).
[22] What is IP Spoofing? https://www.cloudflare.com/learning/ddos/glossary/ip-spoofing/. (Accessed 2021-2-27).
[23] What is timing attack? - Definition from WhatIs.com.https://searchsecurity.techtarget.com/definition/timing-attack. (Accessed 2021-2-27).
96
[24] H. Bodur and R. Kara, “Implementing Diffie-Hellman key exchange method onlogical key hierarchy for secure broadcast transmission,” in 2017 9th InternationalConference on Computational Intelligence and Communication Networks (CICN),Sep. 2017, pp. 144–147.
[25] J. Postel. User datagram protocol. [Online]. Available: https://tools.ietf.org/html/rfc768 (Accessed 2020-10-25).
[26] P. Karn and W. Simpson. Photuris: Session-key management protocol. [Online].Available: https://tools.ietf.org/html/rfc2522 (Accessed 2020-07-12).
[27] Simple authentication and security layer (SASL) mechanisms. [Online]. Avail-able: http://www.iana.org/assignments/sasl-mechanisms/sasl-mechanisms.xhtml(Accessed 2020-05-23).
[28] What is clustering? | clustering in machine learning. [Online]. Avail-able: https://developers.google.com/machine-learning/clustering/overview?hl=pt(Accessed 2020-10-19).
[29] S. P. Mathews and R. R. Gondkar, “Protocol Recommendation for Message En-cryption in MQTT,” in 2019 International Conference on Data Science and Com-munication (IconDSC), Mar. 2019, pp. 1–5.
[30] . a. p. Posted by Nagasai on February 18 and V. Blog. Classification ofIoT devices. [Online]. Available: https://www.cisoplatform.com/profiles/blogs/classification-of-iot-devices (Accessed 2020-10-25).
[31] R. Light, “Mosquitto: server and client implementation of the mqtt protocol,”Journal of Open Source Software, vol. 2, no. 13, p. 265, 2017. [Online]. Available:https://doi.org/10.21105/joss.00265
[32] Client-server architecture | computer science. [Online]. Available: https://www.britannica.com/technology/client-server-architecture (Accessed 2020-10-25).
[33] “ISO/IEC 19464:2014.” [Online]. Available: https://www.iso.org/cms/render/live/en/sites/isoorg/contents/data/standard/06/49/64955.html
[34] “AMQP 0-9-1 Model Explained — RabbitMQ,”https://www.rabbitmq.com/tutorials/amqp-concepts.html.
[35] AMQP 0-9-1 model explained — RabbitMQ. [Online]. Available: https://www.rabbitmq.com/tutorials/amqp-concepts.html (Accessed 2020-02-29).
[36] OASIS advanced message queuing protocol (AMQP) version 1.0, part 2:Transport. [Online]. Available: http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-transport-v1.0-os.html#doc-flow-control (Accessed 2020-10-25).
97
[37] Network address translation (NAT) FAQ. [Online]. Available: https://www.cisco.com/c/en/us/support/docs/ip/network-address-translation-nat/26704-nat-faq-00.html (Accessed 2020-10-25).
[38] M. Heap and H. Morgans, “1 1 language policy and sasl: interpreters in the publicservice,” Disability and social change: A South African agenda, p. 134, 2006.
[39] Authentication, authorisation, access control — RabbitMQ. [Online]. Available:https://www.rabbitmq.com/access-control.html (Accessed 2020-05-24).
[40] Z. Shelby, K. Hartke, and C. Bormann. The constrained application protocol(CoAP). Library Catalog: tools.ietf.org. [Online]. Available: https://tools.ietf.org/html/rfc7252#page-10 (Accessed 2020-03-17).
[41] Age. Library Catalog: developer.mozilla.org. [Online]. Available: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Age (Accessed 2020-06-04).
[42] C. Chiang, “Engineering documents into xml file formats,” pp. 610–615, 2007.
[43] A. A. Abd El-Aziz and A. Kannan, “Json encryption,” pp. 1–6, 2014.
[44] C. Bormann and P. Hoffman, “Concise Binary Object Representation (CBOR),”https://tools.ietf.org/html/rfc7049.
[45] H. com Editors. Benchmark off mqtt servers. [Online]. Available: http://www.scalagent.com/IMG/pdf/Benchmark MQTT servers-v1-1.pdf (Accessed 2020-08-28).
[46] Iot2050 operating instructions en en-US.pdf - SIMATIC IOT2050 - ID: 109779016- Industry Support Siemens. [Online]. Available: https://support.industry.siemens.com/cs/document/109779016/simatic-iot2050?dti=0&lc=en-WW (Accessed 2020-07-19).
[47] Caracterısticas tecnicas do router NOS (3.0 - CVE-30360 ZON) -LANs suportam 1000 mbps? | forum NOS. [Online]. Avail-able: https://www.nos.pt/particulares/ajuda/equipamentos-servicos/internet/internet-fixa/Pages/default.aspx#tab3 (Accessed 2020-11-22).
[48] Node-RED. [Online]. Available: https://nodered.org/ (Accessed 2020-10-08).
[49] Node.js. About. [Online]. Available: https://nodejs.org/en/about/ (Accessed2020-10-27).
[50] node-red-contrib-isonline. Library Catalog: flows.nodered.org. [Online]. Available:http://flows.nodered.org/node/node-red-contrib-isonline (Accessed 2020-07-19).
[51] node-red-contrib-s7. Library Catalog: flows.nodered.org. [Online]. Available:http://flows.nodered.org/node/node-red-contrib-s7 (Accessed 2020-07-16).
98
[52] Node-red-contrib-isonline. [Online]. Available: http://flows.nodered.org/node/node-red-contrib-isonline (Accessed 2020-07-19).
[53] Node-red-contrib-azure-iot-hub. [Online]. Available: http://flows.nodered.org/node/node-red-contrib-azure-iot-hub (Accessed 2020-07-19).
[54] A Syslog Server for the Dashboard. [Online]. Available: https://discourse.nodered.org/t/a-syslog-server-for-the-dashboard/24337 (Accessed 2020-08-17).
[55] O. Folkerd. Tabulator - Interactive JavaScript Tables. [Online]. Available:http://tabulator.info/ (Accessed 2020-08-17).
[56] A. Engelen, “Raboof/nethogs,” Nov. 2020.
[57] packeth. [Online]. Available: http://packeth.sourceforge.net/packeth/Home.html(Accessed 2020-07-26).
[58] node-red-contrib-message-counter. Library Catalog: flows.nodered.org. [Online].Available: http://flows.nodered.org/node/node-red-contrib-message-counter (Ac-cessed 2020-07-25).
[59] Win32 disk imager. [Online]. Available: https://sourceforge.net/projects/win32diskimager/
[60] SIMATIC IOT2050 SD-card example image - ID: 109780231 - industry supportsiemens. [Online]. Available: https://support.industry.siemens.com/cs/document/109780231/simatic-iot2050-sd-card-example-image?dti=0&lc=en-WW
[61] iot2050 quick install guide 0116.pdf - SIMATIC IOT2050 - ID: 109778984 -industry support siemens. [Online]. Available: https://support.industry.siemens.com/cs/document/109778984/simatic-iot2050?dti=0&lc=en-WW (Accessed 2020-10-11).
[62] MQTT documentation. [Date accessed: 2013]. [Online]. Available: https://mqtt.org/mqtt-specification/ (Accessed 2020-06-11).
[63] the max size of a message in rabbitmq · issue #147 · rabbitmq/rabbitmq-server.[Online]. Available: https://github.com/rabbitmq/rabbitmq-server/issues/147(Accessed 2020-11-01).
99
Appendix A
Setting up IOT2050
A.1 Introduction
This section explains how to setup the Siemens SIMATIC IOT2050 to run Node-RED. It will explain the steps to install the image for the IOT2050 and setup networkports.
A.2 Setting up Workspace
To this day (10/10/2020) there is no ”Setting up the SIMATIC IOT2050” as theris for the 2000 series. The process is similar but the links and some commands aredifferent.
In addition to the IOT2050 gateway, it is necessary to have a micro SD card with atleast 8GB, a 12-24V DC power supply and two ETHERNET cables. Then it is necessaryto download the Win32 Disk Imager [59] and the SIMATIC IOT2050 SD-Card exampleimage [60]
Prior to insert the SD card in the IOT2050, the SD card needs to be burned withthe Win32 Disk Imager. To do so, firstly the disk image should be unzipped and then.img file selected in the Win32 Disk Imager. Next clicking on ”Write” the SD card isburned.
100
Figure A.1 presents the window of ”Win32 Disk Imager” application.
Figure A.1: Window presented in Win32 Disk Imager
After waiting for about 5 min the installation finishes and the image is installed in theSD card and it´s ready to insert on the IOT2050. Following the ”iot2050 quick install guide 0116.pdf”[61]in section 3.3 we have the location on where to insert the SD card. Connecting the PSUcable with the correct orientation we can now power ON. With the IOT2050 with animage and powered ON we can now set up our network Ports.
A.3 Setting Static IP
By default XP1 is the Dynamic Host Configuration Protocol (DHCP) port and XP2is the debug port with IP 192.168.200.1.
With a Ethernet to USB or the native Ethernet port on our PC the IOT2050 debugport enables access to configure the IOT2050.
Under Network Status → Ethernet adapter used → Properties → Internet ProtocolV ersion 4 (TCP/IPv4) → Properties there is access to the configuration window thatallows us to change to the desired network parameters.
After changing to an IP valid to the XP2 Port, as Figure A.2 exemplifies, the devicecan now be pinged in the terminal and confirm the connection.
To connect to the IOT2050 over the network ”putty” will be used. Putty is a SHHclient that allows easy connection over the network. Providing the configured IP connec-tion to the IOT2050 is provided. By default the user and password is ”root” but rightafter that it is asked to change the default password or connection get´s disconnected.
101
Figure A.2: IP configuration to access XP2 on IOT2050
Finishing the procedure navigation in the IOT2050 and its directories is now enabled.Changing the ports IP is done by typing ”iot2050setup” which will load a configurationGUI
Under Networking → Edit a connection → Wired connection → Edit we arepresented with the following parameters to set A.3. In this example it is set to the IP192.168.1.87/24 using google Domain Name System (DNS) 8.8.8.8
Scrolling down and entering ”OK” the out port XP1 is now configured for a static IP.To confirm connection ping ”www.google.com” to ensure global connection is working.
The same principle goes to configure XP2 port.
102
Figure A.3: IOT2050 GUI
A.4 Node-RED
Node-red is pre-installed on the IOT2050 and starts automatically on boot. Afterconfiguring all you have to do is put the IP and the designated port on a browser con-nected to the same network as the IOT. In this example it will be http://192.168.1.87:1880.
103
Appendix B
Benchmark protocols with 756kBfile
On this Appendix the description of MQTT and AMQP tests performed with a736kB file is present. The tests made below have the objective to assess the big datacapabilities of the described communication protocols.
B.1 Testing methodology
Test methodology comprehends one test on virtual nodes that send a 756kB filecomposed of numbers. Every 5 min a new node will be added, until 15 nodes or saturationof the system is reached. During the test it will be gathered information about systemperformance respectively: CPU load, memory use and message rate.
B.1.1 Data gathering methodology
For both protocol data collecting will be the same. In the message rate test, AMQPprovides a GUI that plots automatically message rates speed, whereas MQTT does not.To counter that inability in MQTT a Node-red flow was created that plots the messagerate of MQTT on it´s dashboard GUI, adding a visual representation to the messagerate in MQTT. To measure the broker resource usage ”top” command was used, whichdisplays the percentage of CPU and memory use, against the overall, on each runningprogram. For the data gathering of these parameters the average values on each nodeinstance were taken to an excel sheet where the information was processed.
B.1.2 Test hardware setup
As a broker, a laptop designated as PC1, was used with an Intel i7 running at 3.4 GHzconnected to a router using a TP-link USB dongle. The client was a desktop running,PC2, also with a i7 processor at 3.4 Ghz connected using the dedicated network port of
104
the motherboard. The router was a standard ZON Gen3 router. Table B.1 presents thehardware and software settings.
PC1 PC2
OS Linux Windows 10 Pro
CPU I7 (3.4GHz) I7 (3.4GHz)
RAM 16GB 12 GB
Ehternet TP-Link USB 3.0/Gigagbit Ethernet Onboard
Router Zon Gen 3 Zon Gen 3
Python x 3.8.2
Mosquitto 1.6.10 x
AQMP 3.8.5 x
Table B.1: Table containing tests hardware and software specification
Python scripts will deploy the tests on both publisher and subscriber nodes. On thebroker side, MQTT will run mosquitto [31] and on AMQP [35] will run RabbitMQ. Thetwo PC´s are connected with a cable to the network and configured with static IP´s .Figure B.1 presents the visual description of the system.
Figure B.1: Benchmark system description
105
B.2 Message rate
The test was made by adding nodes until the system saturated or the limit of nodeswere reached. Figure B.2 presents the AMQP and MQTTmessage rate comparison
Figure B.2: AMQP and MQTT message rate comparison
AMQP begins the test with a message rate higher than MQTT presenting a rate of 8messsages/sec where it´s counter part shows a rate of 5 messages/sec. Adding the othernodes both protocols oscillate on the 5 message per second mark. Looking at Figure B.3it presents the GUI of the AMQP protocol.
Figure B.3: Rabbitmq GUI graph velocities
Plotting the values of AMQP it can be seen that the message rate is constant withone node running around at 8 messages/sec. However when added more nodes randomspikes are seen. This behavior persists until the end of the test. Figure B.4 presents themessage rate graph created in Node-red´s dashboard.
106
Figure B.4: Node red message velocity chart
Comparing to AMQP, in MQTT, message rate performance is random, with widechanges. Despite that it remains with a rough average of 5 messages/sec as it can beobserved in Figure B.4
This behaviors on both protocols raised some suspicion on what was stopping themto perform better. MQTT has the limit to each message size of 268435445 bytes [62],which translates to 256 MB therefore size limitations were not the issue on the poorperformance of the message rate. In AMQP a limit of 512MB[63] which also does notgo near our message size.
It was then performed in the node code a timing of the main function to verify thatthe code itself was not slowing down the message rate of the protocols. Each test runwith no delays or prints to maximize message rate. Running the code shown in AnnexD.1.1 and Annex D.2.2, respectively in MQTT and AMQP it provides the results seenin Table B.2
Protocol Average run time (ms) Message rate (msg/sec)
MQTT 0.515 1941
AMQP 0.5 2000
Table B.2: Table containing code run time on each node
With these run times it should be expect a message rate of around 1941 and 2000messages a second on MQTT and AMQP respectively. This is not the case, since the
107
achieved rate was at maximum a 8 messages/sec.
One possible justification is that the system might be saturating on the broker side,since these protocols were designed for IoT implementation which in general are at-tributed with low data volume and low frequency.
B.3 CPU load
In Figures B.6 and B.5 plots the CPU load on the MQTT and AMQP broker.
Figure B.5: MQTT CPU load with big messaging
Figure B.6: AMQP CPU load with big messages
CPU load on the AMQP was higher then MQTT. This difference is not a surprisesince all the tests in Chapter 3 show the same difference. It´s good to notice that CPUutilization stays constant after 2 nodes. A possible cause for this behavior is that themessage rate B.2 performance did not increase after the second node forward as it can
108
be seen in Figure B.6, Figure B.5 and in Figure B.2, issuing no extra work load on thesystem.
B.4 Memory use
The amount of memory used is approximately constant and similar for both protocolslike seen in Figure B.7
Figure B.7: AMQP and MQTT memory use comparison
This behavior may be justified by the same reason as the one pointed out above forthe CPU utilization.
B.5 Conclusions
Throughout all evaluated test parameters it was seen that the values were stabilizedaround a value with the increase of nodes. The worst effect noticed was the jitter onthe message rate were after two nodes in AMQP and generally MQTT it would neverachieve stability. The system therefore cannot be used for high volume and frequency ofmessages, but since this test was designed to test a high boundary it can be taken as asuccessful and conclude that these protocols cannot achieve the intended in this environ-ment. Looking at the results in Chapter 3 Section 3.5 it can be seen that with a smallersize file, 5 times larger than the intended in the implementation of this dissertation, itcan be achieved a considerable messages rate.
109
Appendix C
MQTT
On this appendix it was developed a summary of all the most important technicaldetails on the MQTT documentation, which can be seen in [62]. It aims to support theprotocol description in Chapter 2 adding more technical detail.
C.1 Fixed header
This header is presented in all MQTT messages and is described with 2 bytes. Byte1 it contains the Control Packet type and the MQTT Flags like shown on table C.1 [29]
Byte 1 MQTT Control Packet type Flags specific to each MQTT Control Packet typeByte 2 Remaining Length
Table C.1: MQTT Fixed Packet”Remaining Length” that starts on Byte 2 describes the remaining bytes on the control
packet, excluding itself.
C.1.1 Variable header
Some MQTT messages contain a Variable header such as, PUBLISHING SUB-SCRIBING, CONNECTING etc. It resides between the fixed header and the payload.It varies depending of the message. Many of them can be a 2 byte packet identifier.
C.1.2 Payload
Like the ”Variable header” the payload is not required on every control packet. Theyare required in : CONNECT, SUBSCRIBE, SUBACK, UNSUBSCRIBE, UNSUBACK.
C.2 Control Packet types
Below,on table C.2 is the description of every control Packet types and it´s descrip-tion.
110
Name Description
CONNECT Connection request
CONNACK Connect acknowledgment
PUBLISH Publish message
PUBACK Publish acknowledgment
PUBREC Publish received
PUBREL Publish release
PUBCOMP Publish complete
SUBSCRIBE Subscribe request
SUBACK Subscribe acknowledgment
UNSUBSCRIBE Unsubscribe request
UNSUBACK Unsubscribe acknowledgment
PINGREQ PING request
PINGRESP PING response
DISCONNECT Disconnect notification
AUTH Authentication exchange
Table C.2: MQTT packet types
C.2.1 Packets
MQTT is based on exchanging control packets. Below on Table C.3 is defined theheaders. Messages have 3 distinct sections that can be exchanged in MQTT as describedon Table C.3. Required on all messages is the Fixed Header with 2 bytes of size, theother sections vary from message to message.
1 Fixed Header2 Variable header3 Payload
Table C.3: MQTT packet structure
C.2.2 Store and Forward
MQTT has this feature implemented to prevent the loss of important data if theconnection to the broker gets lost or the node is sleeping, as some low-energy solutionstake advantage of sleep capability of devices. Each node assign a specific memory spaceto store data until the connection to the broker gets reestablished. The node gathersthe data up until the connection is reestablished. Once it does the real time data getspushed and in a throttle rate back filling the past data points. Since MQTT messageshave a time-stamp, ordering is no issue.
111
C.3 Error Control
There are two main errors on MQTT Malformed Packets and Protocol Errors. Theseare then handled in the Error handling procedures within MQTT protocol[62]
C.3.0.1 Malformed packets
Any packet that is received not according to specification. It is then parsed to errorhandling procedures.
C.3.0.2 Error handling
If any packet is identified as being with an error appropriate error handling proce-dures are triggered. Whenever a client detects and error it should close the NetworkConnection by sending a DISCONNECT.
112
Appendix D
Software for protocolbenchmarking
On this Annex it is layed out all the code that was used to run the nodes in thisdissertation.
The nodes will send messages to a broker that is connected to the local network.Three different topics/queues with three different messages are trying to achieve themaximum speed possible, saturating the publish method.
D.1 MQTT
A publisher node was developed in python using the ”mqtt” library.
Listing D.1 presents the code deployed for maximum rate in MQTT.
Listing D.1: MQTT python node send code with time calculation of one cycle of messagesending
import paho.mqtt.client as mqtt #import the client1
from timeit import default_timer as timer
broker_address="192.168.1.73"
#broker_address ="iot.eclipse.org" #use external broker
client = mqtt.Client("P1") #create new instance
client.connect(broker_address) #connect to broker
i=0
a=0
total =[]
while a<30:
start = timer()
client.publish("garage/test1","Hello World")#publish.
client.publish("garage/test2","Message 1:"+str(a*1))
client.publish("garage/test3","Message 2:"+str(a*1))
end = timer()
113
total.append(end -start)
a=a+1
a=0
while a<30:
print(total[a])
a=a+1
print("End of test")
Listing D.2 shows the code used to deploy the node in benchmark.
Listing D.2: MQTT python node send code with delays
import paho.mqtt.client as mqtt #import the client1
from timeit import default_timer as timer
import time
broker_address="192.168.1.73"
#broker_address ="iot.eclipse.org" #use external broker
client = mqtt.Client("P1") #create new instance
client.connect(broker_address) #connect to broker
i=0
a=0
b=0
total =[]
while i<30:
start = timer()
client.publish("garage/test1","Hello World")#publish.
client.publish("garage/test2","Message 1:"+str(a*1))
client.publish("garage/test3","Message 2:"+str(a*1))
if a>10:
a=0
print(’x’)
while b <6800:
b=b+1
b=0
a=a+1
i=i+1
end = timer()
total.append(end -start)
a=0
while a<30:
print(total[a])
a=a+1
print("End of test")
114
To receive the messages comming from our MQTT nodes on other machine a linuxmachine running mosquitto broker and node-red was used to deploy the receiver,counterand graph display.
Using MQTT node ,”node-red-contrib-msg-speed” node and a dashboard graph nodethe following flow was composed presented in Figure D.1
Figure D.1: Node red flow for MQTT message receiving and counter
The first node is responsible to create a topic called ”garage/test1” on the mosquitobroker directing the messages directly to it. The second node ”M1” reads the outputof the MQTT node and outputs the message rate in message/sec while the dashboardfunction plots it.
D.1.1 Big message test
On this section it is shown a example of the code for a node used on the big messagetest Appendix B with the integrated code run timer. The code takes 30 samples of eachmessage sent and plots them in the terminal in the end. Listing D.3 presents the codeused in big message test
Listing D.3: MQTT python node big message publish code
import paho.mqtt.client as mqtt #import the client1
from timeit import default_timer as timer
import time
import pandas as pd
broker_address="192.168.1.82"
#broker_address ="iot.eclipse.org" #use external broker
client = mqtt.Client("P1") #create new instance
client.connect(broker_address) #connect to broker
i=0
a=0
total =[]
myfile = open("736kb.txt", "rt") # open lorem.txt for reading text
contents = myfile.read() # read the entire file into a string
myfile.close ()
while i<30:
start = timer()
client.publish("garage/test1",contents)#publish.
115
i=i+1
end = timer()
total.append(end -start)
while a<30:
print(total[a])
a=a+1
print("End of test")
116
D.2 AMQP
A AMQP sender using the ”pika” python library and 3 queues named ”hello”, ”1”and ”2” were declared on the brokers and virtual node.
D.2.1 Maximum message rate
In Listing D.4 it is presented the code used for maximum message rate in AMQP.
Listing D.4: AMQP node send code with time calculation of one cycle of message sending
#!/usr/bin/env python
import pika
from timeit import default_timer as timer
credentials = pika.PlainCredentials(username=’user’, password=’pass’)
connection = pika.BlockingConnection(
pika.ConnectionParameters(host=’192.168.1.73 ’))
channel = connection.channel ()
#Declare Queues
channel.queue_declare(queue=’hello’)
channel.queue_declare(queue=’1’)
channel.queue_declare(queue=’2’)
body=’Bye World!’
a=0
total =[]
while a<30: #30 cycle loop
start = timer()
channel.basic_publish(exchange=’amq.direct ’, routing_key=’hello ’,
body=’Hello World!’)
channel.basic_publish(exchange=’’, routing_key=’1’, body=’Message
1:’+ str(a*1))
channel.basic_publish(exchange=’’, routing_key=’2’, body=’Message
2:’+ str(a*3))
end = timer()
total.append(end -start)
a=a+1
a=0
while a<30: #Print Measurments
print(total[a])
a=a+1
print("End of test")
connection.close ()
117
The receiver node was implemented using the code on Listing D.5.
Listing D.5: AMQP python node send code with delays
#!/usr/bin/env python
import pika
from timeit import default_timer as timer
credentials = pika.PlainCredentials(username=’user’, password=’pass’)
connection = pika.BlockingConnection(
pika.ConnectionParameters(host=’192.168.1.73 ’))
channel = connection.channel ()
#Declare Queues
channel.queue_declare(queue=’hello’)
channel.queue_declare(queue=’1’)
channel.queue_declare(queue=’2’)
body=’Bye World!’
i=0
a=0
b=0
total =[]
while i<30: #30 cycle loop
start = timer()
channel.basic_publish(exchange=’amq.direct ’, routing_key=’hello ’,
body=’Hello World!’)
channel.basic_publish(exchange=’’, routing_key=’1’, body=’Message
1:’+ str(i*1))
channel.basic_publish(exchange=’’, routing_key=’2’, body=’Message
2:’+ str(i*3))
if a>10:
a=0
print(’x’)
while b <4000:
b=b+1
b=0
a=a+1
i=i+1
end = timer()
total.append(end -start)
a=0
while a<30: #Print Measurments
print(total[a])
a=a+1
print("End of test")
connection.close ()
118
D.2.2 Big message test
On this section it is shown an example of the AMQP code for a node used on thebig message test Appendix B with the integrated code run timer. The code takes 30samples of each message sent and plots them to the terminal in the end. Listing D.6presents the code used in big message test.
Listing D.6: AMQP python node big message publish code
#!/usr/bin/env python
import pika
import time
import pandas as pd
credentials = pika.PlainCredentials(username=’user’, password=’pass’)
connection = pika.BlockingConnection(
pika.ConnectionParameters(host=’192.168.1.73 ’))
channel = connection.channel ()
channel.queue_declare(queue=’1’)
myfile = open("736KB.txt", "rt") # open lorem.txt for reading text
contents = myfile.read() # read the entire file into a string
myfile.close () # close the file
print(contents)
body1=contents #store .txt file in "body1" variable
a=0
total =[]
while a<30: #loop for time measurment
start = timer()
channel.basic_publish(exchange=’’, routing_key=’1’, body=body1)
a=a+1
end = timer()
total.append(end -start)
a=0
while a<30: #Print measurments
print(total[a])
a=a+1
print("End of test")
connection.close ()
119
Appendix E
Node-RED
In this appendix it is layed out all the functions code that was used to deploy theNode-RED flows that implemented the final solution in this dissertation.
Listing E.1: Function node that processes an array of BCD data and converts it into adecimal organized string
// convertion from Dec to Hex
Systemtime_Year = msg.payload [0]. toString (16);
Systemtime_Month = msg.payload [1]. toString (16);
Systemtime_Day = msg.payload [2]. toString (16);
Systemtime_Hour = msg.payload [3]. toString (16);
Systemtime_Min = msg.payload [4]. toString (16);
Systemtime_Sec = msg.payload [5]. toString (16);
var Systemtime = flow.get("date") || 0;
//add a 0 to the string if value is <= 9
if (Systemtime_Month <=9 ) {
Systemtime_Month = "0" + Systemtime_Month;
}
if (Systemtime_Day <=9 ) {
Systemtime_Day = "0" + Systemtime_Day;
}
if (Systemtime_Hour <=9 ) {
Systemtime_Hour = "0" + Systemtime_Hour;
}
if (Systemtime_Min <=9 ) {
Systemtime_Min = "0" + Systemtime_Min;
}
if (Systemtime_Sec <=9 ) {
Systemtime_Sec = "0" + Systemtime_Sec;
}
Systemtime ="20" + Systemtime_Year + "-" + Systemtime_Month + "-" +
Systemtime_Day + " " + Systemtime_Hour + ":" + Systemtime_Min + ":"
+ Systemtime_Sec;
120
flow.set ("date",Systemtime);
msg.payload= Systemtime;
return msg;
Listing E.2: Function node receives payload and stores it on a flow.json variable
system = flow.get("file") || 0;
json= msg.payload;
// connect=msg.payload.topic ()
flow.set ("file",json);
msg.payload= json;
return msg;
Listing E.3: Function node receives payload and stores it on a flow.status variable
system = flow.get("status") || 0;
json= msg.payload;
flow.set ("status",json);
msg.payload= msg;
return msg;
121
E.0.1 Burst module
The module is composed by the flow seen in Figure E.1, and is used in Chapter 6 onSection 6.3
Figure E.1: Burst flow module
It receives a variable, from an inject node, in this case the preset JSON stored inthe flow.file every 1 second where it ramifies to two other nodes, a delay node and aswitch. The delay node generates the trigger that goes into the function node ”burst”;changing the delay on this node changes the interval of the module. The switch nodeis responsible to activate a flow variable ”flow.timeout” to one whenever it receives andinput from the inject node.
The burst function is described on Annex E.4. It is composed by two functions,one that sets the burst time and another that dictates the message rate, respectivelywaitSixty() and repeatThirty().
Listing E.4 presents the code in the function node ”burst”.
Listing E.4: Function node responsible to generate burst function
var myObj = msg.payload;
function waitSixty () {
setTimeout (()=>{
flow.set("timeout", false);
} ,60000);
}
function repeatThirty (variable) {
var interval = setInterval (()=>{
node.send({ payload:variable });
var timeout = flow.get("timeout");
if (! timeout) { clearInterval(interval) }
},30);
}
flow.set("timeout",true);
waitSixty ();
repeatThirty(myObj);
return;
122
E.1 Node-RED variable listing Revision 1.0
DB2000 R0;TimestampDB2000 S8.18;LU ID LHD1DB2000 I28;LU Type 1DB2000 S30.18;LU ID LHD2DB2000 I50;LU Type 2DB2000 C52;STK StatusDB2000 C53;STK ModeDB2000 C54;Aisle ModeDB2000 I56;Fault CodeDB2000 C58;Rcv CMDDB2000 C59;CMD StatusDB2000 C60;CMD TypeDB2000 I62;CMD Start XDB2000 I64;CMD Start YDB2000 I66;CMD Final X LHD1DB2000 I68;CMD Final Y LHD1DB2000 I70;CMD Final Z LHD1DB2000 I72;CMD Final X LHD2DB2000 I74;CMD Final Y LHD2DB2000 I76;CMD Final Z LHD2DB2000 C78;MOV TypeDB2000 B79;X MovDB2000 B79.1;Y MovDB2000 B79.2;Z1S MovDB2000 B79.3;Z1D MovDB2000 B79.4;Z2S MovDB2000 B79.5;Z2D MovDB2000 B79.6;X PosDB2000 B79.7;Y PosDB2000 B80;Z1S PosDB2000 B80.1;Z1D PosDB2000 B80.2;Z2S PosDB2000 B80.3;Z2D PosDB2000 B80.4;LU Pre LHD1DB2000 B80.5;LU Pre LHD2DB2000 B80.6;PLC RestartDB2000 B80.7;Fr Door ClDB2000 B81;Re Door ClDB2000 I82;X Act IDB2000 I84;Y Act IDB2000 I86;Z1S Act IDB2000 I88;Z1D Act IDB2000 I90;Z2S Act IDB2000 I92;Z2D Act IDB2000 DI94;X Act PosDB2000 DI98;Y Act PosDB2000 DI102;Z1S Act Pos
123
DB2000 DI106;Z1D Act PosDB2000 DI110;Z2S Act PosDB2000 DI114;Z2D Act PosDB2000 DI118;X Work HDB2000 DI122;Y Work HDB2000 DI126;Z1 Work HDB2000 DI130;Z2 Work HDB2000 DI134;X T DistDB2000 DI138;Y T DistDB2000 DI142;Z1S T DistDB2000 DI146;Z1D T DistDB2000 DI150;Z2S T DistDB2000 DI154;Z2D T DistDB2000 I158;Weight ReDB2000 I160;Weight FrDB2000 B162;Catch ONDB2000 B162.1;Y RefDB2000 B162.2;Y LimitDB2000 B162.3;Y Speed R UDB2000 B162.4;Y Speed R DDB2000 B162.5;Z2 Load OH FrDB2000 B162.6;Z2 Load OH ReDB2000 B162.7;Z2 Cent 1 FrDB2000 B163;Z2 Cent 2 ReDB2000 B163.1;Z2S Rack Full LDB2000 B163.2;Z2S Rack Full RDB2000 B163.3;Z2D Rack Full LDB2000 B163.4;Z2D Rack Full RDB2000 B163.5;Z2 Pal Cent 1200 LDB2000 B163.6;Z2 Pal Cent 1200 RDB2000 B163.7;Z2 Pal Cent 1150 LDB2000 B164;Z2 Pal Cent 1150 RDB2000 B164.1;Z2 Half Pal CentDB2000 B164.2;Z1 Load OH FrDB2000 B164.3;Z1 Load OH ReDB2000 B164.4;Z1 Cent 1 FrDB2000 B164.5;Z1 Cent 2 ReDB2000 B164.6;Z1S Rack Full LDB2000 B164.7;Z1S Rack Full RDB2000 B165;Z1D Rack Full LDB2000 B165.1;Z1D Rack Full RDB2000 B165.2;Z1 Pal Cent 1200 LDB2000 B165.3;Z1 Pal Cent 1200 RDB2000 B165.4;Z1 Pal Cent 1150 LDB2000 B165.5;Z1 Pal Cent 1150 RDB2000 B165.6;Z1 Half Pal CentDB2000 B165.7;Load OH L FrDB2000 B166;Load OH L ReDB2000 B166.1;Load OH R FrDB2000 B166.2;Load OH R ReDB2000 B166.3;Height 1750 LDB2000 B166.4;Height 1750 R
124
DB2000 B166.5;Height 1800 LDB2000 B166.6;Height 1800 RDB2000 B166.7;Max Height LDB2000 B167;Max Height RDB2000 B167.1;Z Safety LDB2000 B167.2;Z Safety RDB2000 B167.3;Dead Man CabDB2000 B167.4;Access Door CabDB2000 B167.5;Stop Reset CabDB2000 B167.6;Lamp Test CabDB2000 B167.7;Emerg CabDB2000 B168;Auto Switch CabDB2000 B168.1;Manual Switch CabDB2000 B168.2;Upright LDB2000 B168.3;Upright RDB2000 B168.4;Main Cont ONDB2000 B168.5;Emerg Chain STK SafDB2000 B168.6;Emerg Chain Aisle SafDB2000 B168.7;Emerg Chain Aisle AccessDB2000 B169;X TempDB2000 B169.1;X Brake ONDB2000 B169.2;X RefDB2000 B169.3;X Limit SwDB2000 B169.4;X Speed Red ReDB2000 B169.5;X Speed Red FrDB2000 B169.6;Y Brake ONDB2000 B169.7;Over Speed Slack RopeDB2000 B170;Over SpeedDB2000 B170.1;Auto Switch PanDB2000 B170.2;Manual Switch PanDB2000 B170.3;By passDB2000 B170.4;Emerg PanDB2000 B170.5;Manual PDB2000 B170.6;Manual NDB2000 B170.7;Manual XDB2000 B171;Manual YDB2000 B171.1;Manual Z1SDB2000 B171.2;Manual Z1DDB2000 B171.3;Manual Z2SDB2000 B171.4;Manual Z2DDB2000 B171.5;Stop Reset PanDB2000 B171.6;Lamp Test PanDB2000 B171.7;Access Door PanDB2000 B172;X Brake Res TempDB2000 B172.1;Y Brake Res TempDB2000 B172.2;Z Motors ONDB2000 B172.3;Onboard Shock Abs BDB2000 B172.4;Onboard Shock Abs FDB2000 B172.5;Smoke DetDB2000 B172.6;Aisle CB ONDB2000 B172.7;Aisle Fr Door
125
DB2000 B173;Aisle Re DoorDB2000 B173.1;Aisle Shock Abs BDB2000 B173.2;Aisle Shock Abs FDB2000 B173.3;Aisle Fr Access RemDB2000 B173.4;Aisle Re Access RemDB2000 B173.5;Aisle Fr EmergDB2000 B173.6;Aisle Re EmergDB2000 B173.7;Y InhibitDB2000 B174;X InhibitDB2000 R176;HC incl XDB2000 R180;HC incl ZDB2000 R184;Base acc xDB2000 R188;Base acc zDB2000 R192;TopMast acc xDB2000 R196;TopMast acc zDB2000 R200;HC TempDB2000 R204;HC HumDB2000 R208;Panel TempDB2000 R212;Panel HumDB2000 R216;X1 motor TempDB2000 R220;X2 motor TempDB2000 R224;Y motor TempDB2000 R228;X1 wheel wearDB2000 R232;X2 wheel wear
Table E.1: ”S7 com” node file input variables
126
E.2 Node-RED variable listing Revision 2.0
127
DB1,W0 TimestampDB1,S8.20 LU ID Real CNVDB1,I30 LU Type Real CNVDB1,S32.20 LU ID Virtual CNVDB1,I54 LU Type Virtual CNVDB1,C56 VTD StatusDB1,C57 VTD ModeDB1,C58 Aisle ModeDB1,I60 Fault CodeDB1,C62 Received CMDDB1,C63 CMD StatusDB1,C64 CMD TypeDB1,I66 CMD Start CNVDB1,I68 CMD Start YDB1,I70 CMD Final CNV Real CNVDB1,I72 CMD Final YDB1,I74 CMD Final Z Real CNV
DB1,I76CMD Final CNV Virtual CNV
DB1,I78 CMD Final Y Virtual CNVDB1,I80 CMD Final Z Virtual CNVDB1,C82 Movement TypeDB1,X83.0 CNV MovingDB1,X83.1 Y MovingDB1,X83.2 Z1S MovingDB1,X83.3 Z1D MovingDB1,X83.4 Z2S MovingDB1,X83.5 Z2D MovingDB1,X83.6 CNV PositionedDB1,X83.7 Y PositionedDB1,X84.0 Z1S PositionedDB1,X84.1 Z1D PositionedDB1,X84.2 Z2S PositionedDB1,X84.3 Z2D PositionedDB1,X84.4 LU Present Real CNVDB1,X84.5 LU Present Virtual CNVDB1,X84.6 PLC RestartDB1,X84.7 Front door closedDB1,X85.0 Rear door closedDB1,I86 CNV Actual CurrentDB1,I88 Y Actual CurrentDB1,I90 Z1S Actual CurrentDB1,I92 Z1D Actual CurrentDB1,I94 Z2S Actual CurrentDB1,I96 Z2D Actual Current
DB1,I98 CNV Actual PositionDB1,I100 Y Actual PositionDB1,I102 Z1S Actual PositionDB1,I104 Z1D Actual PositionDB1,I106 Z2S Actual PositionDB1,I108 Z2D Actual PositionDB1,I110 CNV Working HoursDB1,I112 Y Working HoursDB1,I114 Z1 Working HoursDB1,I116 Z2 Working HoursDB1,I118 CNV Total DistanceDB1,I120 Y Total DistanceDB1,I122 Z1S Total DistanceDB1,I124 Z1D Total DistanceDB1,I126 Z2S Total DistanceDB1,I128 Z2D Total DistanceDB1,I130 Load sensor rearDB1,I132 Load sensor frontDB1,X134.0 Catching Device ONDB1,X134.1 Y ReferenceDB1,X134.2 Y Limit SwitchDB1,X134.3 Y Speed Red UpDB1,X134.4 Y Speed Red DownDB1,X134.5 Z2 Load Overhang FrontDB1,X134.6 Z2 Load Overhang RearDB1,X134.7 Z2 Centered 1 FrontDB1,X135.0 Z2 Centered 2 RearDB1,X135.1 Z2S Rack Full LeftDB1,X135.2 Z2S Rack Full RightDB1,X135.3 Z2D Rack Full LeftDB1,X135.4 Z2D Rack Full RightDB1,X135.5 Z2 Pal Centered 1200 Left
DB1,X135.6Z2 Pal Centered 1200 Right
DB1,X135.7 Z2 Pal Centered 1150 Left
DB1,X136.0Z2 Pal Centered 1150 Right
DB1,X136.1 Z2 Half Pal CenteredDB1,X136.2 Z1 Load Overhang FrontDB1,X136.3 Z1 Load Overhang RearDB1,X136.4 Z1 Centered 1 FrontDB1,X136.5 Z1 Centered 2 RearDB1,X136.6 Z1S Rack Full LeftDB1,X136.7 Z1S Rack Full RightDB1,X137.0 Z1D Rack Full LeftDB1,X137.1 Z1D Rack Full Right
DB1,X137.2 Z1 Pal Centered 1200 Left
DB1,X137.3Z1 Pal Centered 1200 Right
DB1,X137.4 Z1 Pal Centered 1150 Left
DB1,X137.5Z1 Pal Centered 1150 Right
DB1,X137.6 Z1 Half Pal Centered
DB1,X137.7Load Overhang Left (Front)
DB1,X138.0 Load Overhang Left (Rear)
DB1,X138.1Load Overhang Right (Front)
DB1,X138.2Load Overhang Right (Rear)
DB1,X138.3 Height 1750 LeftDB1,X138.4 Height 1750 RightDB1,X138.5 Height 1800 LeftDB1,X138.6 Height 1800 RightDB1,X138.7 MaCNV Height LeftDB1,X139.0 MaCNV Height RightDB1,X139.1 CNV Safety LeftDB1,X139.2 CNV Safety RightDB1,X139.3 Dead-Man Button CabinDB1,X139.4 Access Door CabinDB1,X139.5 Stop Reset CabinDB1,X139.6 Lamp Test CabinDB1,X139.7 Emerg Button CabinDB1,X140.0 Auto Key Switch CabinDB1,X140.1 Manual Key Switch CabinDB1,X140.2 Upright LeftDB1,X140.3 Upright RightDB1,X140.4 Main Contactor ONDB1,X140.5 Emerg Chain VTD SafetyDB1,X140.6 Emerg Chain Aisle SafetyDB1,X140.7 Emerg Chain Aisle AccessDB1,X141.0 CNV TempDB1,X141.1 CNV Brake ONDB1,X141.2 CNV ReferenceDB1,X141.3 CNV Limit SwitchDB1,X141.4 CNV Speed Red RearDB1,X141.5 CNV Speed Red FrontDB1,X141.6 Y Brake ONDB1,X141.7 Over Speed Slack RopeDB1,X142.0 Over SpeedDB1,X142.1 Auto key Switch PanelDB1,X142.2 Manual Key Switch Panel
DB1,X142.3 By-pass Emerg ChainDB1,X142.4 Emerg Button PanelDB1,X142.5 Manual PDB1,X142.6 Manual NDB1,X142.7 Manual CNVDB1,X143.0 Manual YDB1,X143.1 Manual Z1SDB1,X143.2 Manual Z1DDB1,X143.3 Manual Z2SDB1,X143.4 Manual Z2DDB1,X143.5 Stop Reset PanelDB1,X143.6 Lamp Test PanelDB1,X143.7 Access Door PanelDB1,X144.0 CNV Brake Resistor TempDB1,X144.1 Y Brake Resistor TempDB1,X144.2 CNV Motor ONDB1,X144.3 Onboard Shock Abs BackDB1,X144.4 Onboard Shock Abs FrontDB1,X144.5 Smoke DetectionDB1,X144.6 Aisle CB ONDB1,X144.7 Aisle Front DoorDB1,X145.0 Aisle Rear DoorDB1,X145.1 Aisle Shock Abs BackDB1,X145.2 Aisle Shock Abs FrontDB1,X145.3 Aisle Front Access RemoteDB1,X145.4 Aisle Rear Access RemoteDB1,X145.5 Aisle Front Emerg buttonDB1,X145.6 Aisle Rear Emerg ButtonDB1,X145.7 Y InhibitDB1,X146.0 CNV Inhibit
E.3 Dashboard
Listing E.5: ui-table handler JavaScript code for implementation of 179 variables on thedashboard
{
"tabulator": {
"columnResized": "function(column){ var newColumn = {
title:column._column.definition.title ,field: column
._column.field , visible: column._column.visible ,
width: column._column.width , widthFixed:
column._column.widthFixed , widthStyled: column.
_column.widthStyled }; this.send({topic:this.config.
topic ,ui_control :{ callback:’columnResized ’,columnWidths:
newColumn }}); }",
"columnMoved": "columnMoved = function(column , columns){
var newColumns =[]; columns.forEach(function (column) {
newColumns.push({’field ’: column._column.definition
.field , ’title ’: column._column.definition.title}); });
this.send({topic:this.config.topic ,ui_control :{
callback:’columnMoved ’,columns:newColumns }}); }",
"groupHeader": "function (value , count , data , group) {return
value + \"<span style=’color:#d00; margin -left :10px;’>(\" +
count + \" Termostat \"+(( count >1) ? \"e\" : \"\") + \") </
span >\";}",
"columns": [
{
"title": "Time",
"field": "Timestamp",
"width": "auto",
"formatter": "datetime",
"formatterParams": {
"inputFormat": "YYYY -MM -DD HH:mm:ss.SSS",
"outputFormat": "YYYY -MM -DD HH:mm:ss",
"invalidPlaceholder": "(invalid time)"
}
},
{
"title": "STK_Status",
"field": "STK_Status",
"width": 140,
"headerFilter": "select",
"headerFilterParams": {
"values": true
}
},
{
"title": "LU_ID_LHD1",
"field": "LU_ID_LHD1",
"width": 100,
"headerFilter": "select",
"headerFilterParams": {
132
"values": true
}
},
{
"title": "LU_Type_1",
"field": "LU_Type_1",
"width": 100
},
{
"title": "LU_ID_LHD2",
"field": "LU_ID_LHD2",
"width": 100,
"headerFilter": "select",
"headerFilterParams": {
"values": true
}
},
{
"title": "LU_Type_2",
"field": "LU_Type_2",
"width": 100
},
{
"title": "STK_Status",
"field": "STK_Status",
"width": 100
},
{
"title": "STK_Mode",
"field": "STK_Mode",
"width": 100
},
{
"title": "Aisle_Mode",
"field": "Aisle_Mode",
"width": 100
},
{
"title": "Fault_Code",
"field": "Fault_Code",
"width": 100
},
{
"title": "Rcv_CMD",
"field": "Rcv_CMD",
"width": 100
},
{
"title": "CMD_Status",
"field": "CMD_Status",
"width": 100
},
{
133
"title": "CMD_Type",
"field": "CMD_Type",
"width": 100
},
{
"title": "CMD_Start_X",
"field": "CMD_Start_X",
"width": 100
},
{
"title": "CMD_Final_X_LHD1",
"field": "CMD_Final_X_LHD1",
"width": 100
},
{
"title": "CMD_Final_Y_LHD1",
"field": "CMD_Final_Y_LHD1",
"width": 100
},
{
"title": "CMD_Final_Z_LHD1",
"field": "CMD_Final_Z_LHD1",
"width": 100
},
{
"title": "CMD_Final_X_LHD2",
"field": "CMD_Final_X_LHD2",
"width": 100
},
{
"title": "CMD_Final_Y_LHD2",
"field": "CMD_Final_Y_LHD2",
"width": 100
},
{
"title": "CMD_Final_Z_LHD2",
"field": "CMD_Final_Z_LHD2",
"width": 100
},
{
"title": "MOV_Type",
"field": "MOV_Type",
"width": 100
},
{
"title": "X_Mov",
"field": "X_Mov",
"width": 100
},
{
"title": "Y_Mov",
"field": "Y_Mov",
"width": 100
134
},
{
"title": "Z1S_Mov",
"field": "Z1S_Mov",
"width": 100
},
{
"title": "Z1D_Mov",
"field": "Z1D_Mov",
"width": 100
},
{
"title": "Z2S_Mov",
"field": "Z2S_Mov",
"width": 100
},
{
"title": "Z2D_Mov",
"field": "Z2D_Mov",
"width": 100
},
{
"title": "X_Pos",
"field": "X_Pos",
"width": 100
},
{
"title": "Y_Pos",
"field": "Y_Pos",
"width": 100
},
{
"title": "Z1S_Pos",
"field": "Z1S_Pos",
"width": 100
},
{
"title": "Z1D_Pos",
"field": "Z1D_Pos",
"width": 100
},
{
"title": "Z2S_Pos",
"field": "Z2S_Pos",
"width": 100
},
{
"title": "Z2D_Pos",
"field": "Z2D_Pos",
"width": 100
},
{
"title": "LU_Pre_LHD1",
135
"field": "LU_Pre_LHD1",
"width": 100
},
{
"title": "LU_Pre_LHD2",
"field": "LU_Pre_LHD2",
"width": 100
},
{
"title": "Re_Door_Cl",
"field": "Re_Door_Cl",
"width": 100
},
{
"title": "Fr_Door_Cl",
"field": "Fr_Door_Cl",
"width": 100
},
{
"title": "Re_Door_Cl",
"field": "Re_Door_Cl",
"width": 100
},
{
"title": "X_Act_I",
"field": "X_Act_I",
"width": 100
},
{
"title": "Y_Act_I",
"field": "Y_Act_I",
"width": 100
},
{
"title": "Z1S_Act_I",
"field": "Z1S_Act_I",
"width": 100
},
{
"title": "Z1D_Act_I",
"field": "Z1D_Act_I",
"width": 100
},
{
"title": "Z2S_Act_I",
"field": "Z2S_Act_I",
"width": 100
},
{
"title": "Z2D_Act_I",
"field": "Z2D_Act_I",
"width": 100
},
136
{
"title": "X_Act_Pos",
"field": "X_Act_Pos",
"width": 100
},
{
"title": "Y_Act_Pos",
"field": "Y_Act_Pos",
"width": 100
},
{
"title": "Z1S_Act_Pos",
"field": "Z1S_Act_Pos",
"width": 100
},
{
"title": "Z1D_Act_Pos",
"field": "Z1D_Act_Pos",
"width": 100
},
{
"title": "Z2S_Act_Pos",
"field": "Z2S_Act_Pos",
"width": 100
},
{
"title": "Z2D_Act_Pos",
"field": "Z2D_Act_Pos",
"width": 100
},
{
"title": "X_Work_H",
"field": "X_Work_H",
"width": 100
},
{
"title": "Y_Work_H",
"field": "Y_Work_H",
"width": 100
},
{
"title": "Z1_Work_H",
"field": "Z1_Work_H",
"width": 100
},
{
"title": "Z2_Work_H",
"field": "Z2_Work_H",
"width": 100
},
{
"title": "X_T_Dist",
"field": "X_T_Dist",
137
"width": 100
},
{
"title": "Y_T_Dist",
"field": "Y_T_Dist",
"width": 100
},
{
"title": "Z1S_T_Dist",
"field": "Z1S_T_Dist",
"width": 100
},
{
"title": "Z1D_T_Dist",
"field": "Z1D_T_Dist",
"width": 100
},
{
"title": "Z2S_Act_Pos",
"field": "Z2S_Act_Pos",
"width": 100
},
{
"title": "Z2D_Act_Pos",
"field": "Z2D_Act_Pos",
"width": 100
},
{
"title": "X_Work_H",
"field": "X_Work_H",
"width": 100
},
{
"title": "Y_Work_H",
"field": "Y_Work_H",
"width": 100
},
{
"title": "Z1_Work_H",
"field": "Z1_Work_H",
"width": 100
},
{
"title": "Z2_Work_H",
"field": "Z2_Work_H",
"width": 100
},
{
"title": "X_T_Dist",
"field": "X_T_Dist",
"width": 100
},
{
138
"title": "Y_T_Dist",
"field": "Y_T_Dist",
"width": 100
},
{
"title": "Z1S_T_Dist",
"field": "Z1S_T_Dist",
"width": 100
},
{
"title": "Z1D_T_Dist",
"field": "Z1D_T_Dist",
"width": 100
},
{
"title": "Z2S_T_Dist",
"field": "Z2S_T_Dist",
"width": 100
},
{
"title": "Z2D_T_Dist",
"field": "Z2D_T_Dist",
"width": 100
},
{
"title": "Weight_Re",
"field": "Weight_Re",
"width": 100
},
{
"title": "Weight_Fr",
"field": "Weight_Fr",
"width": 100
},
{
"title": "Catch_ON",
"field": "Catch_ON",
"width": 100
},
{
"title": "Y_Ref",
"field": "Y_Ref",
"width": 100
},
{
"title": "Y_Limit",
"field": "Y_Limit",
"width": 100
},
{
"title": "Y_Speed_R_U",
"field": "Y_Speed_R_U",
"width": 100
139
},
{
"title": "Y_Speed_R_D",
"field": "Y_Speed_R_D",
"width": 100
},
{
"title": "Z2_Load_OH_Fr",
"field": "Z2_Load_OH_Fr",
"width": 100
},
{
"title": "Z2_Load_OH_Re",
"field": "Z2_Load_OH_Re",
"width": 100
},
{
"title": "Z2_Cent_1_Fr",
"field": "Z2_Cent_1_Fr",
"width": 100
},
{
"title": "Z2_Cent_2_Re",
"field": "Z2_Cent_2_Re",
"width": 100
},
{
"title": "Z2S_Rack_Full_L",
"field": "Z2S_Rack_Full_L",
"width": 100
},
{
"title": "Z2S_Rack_Full_R",
"field": "Z2S_Rack_Full_R",
"width": 100
},
{
"title": "Z2D_Rack_Full_L",
"field": "Z2D_Rack_Full_L",
"width": 100
},
{
"title": "Z2D_Rack_Full_R",
"field": "Z2D_Rack_Full_R",
"width": 100
},
{
"title": "Z2_Pal_Cent_1200_L",
"field": "Z2_Pal_Cent_1200_L",
"width": 100
},
{
"title": "Z2_Pal_Cent_1200_R",
140
"field": "Z2_Pal_Cent_1200_R",
"width": 100
},
{
"title": "Z2_Pal_Cent_1150_L",
"field": "Z2_Pal_Cent_1150_L",
"width": 100
},
{
"title": "Z2_Pal_Cent_1150_R",
"field": "Z2_Pal_Cent_1150_R",
"width": 100
},
{
"title": "Z2_Half_Pal_Cent",
"field": "ZZ2_Half_Pal_Cent",
"width": 100
},
{
"title": "Z1_Load_OH_Fr",
"field": "Z1_Load_OH_Fr",
"width": 100
},
{
"title": "Z1_Load_OH_Re",
"field": "Z1_Load_OH_Re",
"width": 100
},
{
"title": "Z1_Cent_1_Fr",
"field": "Z1_Cent_1_Fr",
"width": 100
},
{
"title": "Z1_Cent_2_Re",
"field": "Z1_Cent_2_Re",
"width": 100
},
{
"title": "Z1S_Rack_Full_L",
"field": "Z1S_Rack_Full_L",
"width": 100
},
{
"title": "Z1S_Rack_Full_R",
"field": "Z1S_Rack_Full_R",
"width": 100
},
{
"title": "Z1D_Rack_Full_L",
"field": "Z1D_Rack_Full_L",
"width": 100
},
141
{
"title": "Z1D_Rack_Full_R",
"field": "Z1D_Rack_Full_R",
"width": 100
},
{
"title": "Z1_Pal_Cent_1200_L",
"field": "Z1_Pal_Cent_1200_L",
"width": 100
},
{
"title": "Z1_Pal_Cent_1200_R",
"field": "Z1_Pal_Cent_1200_R",
"width": 100
},
{
"title": "Z1_Pal_Cent_1150_L",
"field": "Z1_Pal_Cent_1150_L",
"width": 100
},
{
"title": "Z1_Pal_Cent_1150_R",
"field": "Z1_Pal_Cent_1150_R",
"width": 100
},
{
"title": "Z1_Half_Pal_Cent",
"field": "Z1_Half_Pal_Cent",
"width": 100
},
{
"title": "Load_OH_R_Fr",
"field": "Load_OH_R_Fr",
"width": 100
},
{
"title": "Load_OH_R_Re",
"field": "Load_OH_R_Re",
"width": 100
},
{
"title": "Height_1750_L",
"field": "Height_1750_L",
"width": 100
},
{
"title": "Height_1750_R",
"field": "Height_1750_R",
"width": 100
},
{
"title": "Height_1800_L",
"field": "Height_1800_L",
142
"width": 100
},
{
"title": "Height_1800_R",
"field": "Height_1800_R",
"width": 100
},
{
"title": "Max_Height_L",
"field": "Max_Height_L",
"width": 100
},
{
"title": "Max_Height_R",
"field": "Max_Height_R",
"width": 100
},
{
"title": "Z_Safety_L",
"field": "Z_Safety_L",
"width": 100
},
{
"title": "Z_Safety_R",
"field": "Z_Safety_R",
"width": 100
},
{
"title": "Dead_Man_Cab",
"field": "Dead_Man_Cab",
"width": 100
},
{
"title": "Access_Door_Cab",
"field": "Access_Door_Cab",
"width": 100
},
{
"title": "Stop_Reset_Cab",
"field": "Stop_Reset_Cab",
"width": 100
},
{
"title": "Lamp_Test_Cab",
"field": "Lamp_Test_Cab",
"width": 100
},
{
"title": "Emerg_Cab",
"field": "Emerg_Cab",
"width": 100
},
{
143
"title": "Auto_Switch_Cab",
"field": "Auto_Switch_Cab",
"width": 100
},
{
"title": "Manual_Switch_Cab",
"field": "Manual_Switch_Cab",
"width": 100
},
{
"title": "Upright_L",
"field": "Upright_L",
"width": 100
},
{
"title": "Upright_R",
"field": "Upright_R",
"width": 100
},
{
"title": "Main_Cont_ON",
"field": "Main_Cont_ON",
"width": 100
},
{
"title": "Emerg_Chain_STK_Saf",
"field": "Emerg_Chain_STK_Saf",
"width": 100
},
{
"title": "Emerg_Chain_Aisle_Saf",
"field": "Emerg_Chain_Aisle_Saf",
"width": 100
},
{
"title": "Emerg_Chain_Aisle_Access",
"field": "Emerg_Chain_Aisle_Access",
"width": 100
},
{
"title": "X_Temp",
"field": "X_Temp",
"width": 100
},
{
"title": "X_Brake_ON",
"field": "X_Brake_ON",
"width": 100
},
{
"title": "X_Ref",
"field": "X_Ref",
"width": 100
144
},
{
"title": "X_Limit_Sw",
"field": "X_Limit_Sw",
"width": 100
},
{
"title": "X_Speed_Red_Re",
"field": "X_Speed_Red_Re",
"width": 100
},
{
"title": "X_Speed_Red_Fr",
"field": "X_Speed_Red_Fr",
"width": 100
},
{
"title": "Y_Brake_ON",
"field": "Y_Brake_ON",
"width": 100
},
{
"title": "Over_Speed_Slack_Rope",
"field": "Over_Speed_Slack_Rope",
"width": 100
},
{
"title": "Over_Speed",
"field": "Over_Speed",
"width": 100
},
{
"title": "Auto_Switch_Pan",
"field": "Auto_Switch_Pan",
"width": 100
},
{
"title": "Manual_Switch_Pan",
"field": "Manual_Switch_Pan",
"width": 100
},
{
"title": "By_pass",
"field": "By_pass",
"width": 100
},
{
"title": "Emerg_Pan",
"field": "Emerg_Pan",
"width": 100
},
{
"title": "Manual_P",
145
"field": "Manual_P",
"width": 100
},
{
"title": "Manual_N",
"field": "Manual_N",
"width": 100
},
{
"title": "Manual_X",
"field": "Manual_X",
"width": 100
},
{
"title": "Manual_Y",
"field": "Manual_Y",
"width": 100
},
{
"title": "Manual_Z1S",
"field": "Manual_Z1S",
"width": 100
},
{
"title": "Manual_Z1D",
"field": "Manual_Z1D",
"width": 100
},
{
"title": "Manual_Z2S",
"field": "Manual_Z2S",
"width": 100
},
{
"title": "Manual_Z2D",
"field": "Manual_Z2D",
"width": 100
},
{
"title": "Stop_Reset_Pan",
"field": "Stop_Reset_Pan",
"width": 100
},
{
"title": "Lamp_Test_Pan",
"field": "Lamp_Test_Pan",
"width": 100
},
{
"title": "Access_Door_Pan",
"field": "Access_Door_Pan",
"width": 100
},
146
{
"title": "X_Brake_Res_Temp",
"field": "X_Brake_Res_Temp",
"width": 100
},
{
"title": "Y_Brake_Res_Temp",
"field": "Y_Brake_Res_Temp",
"width": 100
},
{
"title": "Z_Motors_ON",
"field": "Z_Motors_ON",
"width": 100
},
{
"title": "Onboard_Shock_Abs_B",
"field": "Onboard_Shock_Abs_B",
"width": 100
},
{
"title": "Onboard_Shock_Abs_F",
"field": "Onboard_Shock_Abs_F",
"width": 100
},
{
"title": "Smoke_Det",
"field": "Smoke_Det",
"width": 100
},
{
"title": "Aisle_CB_ON",
"field": "Aisle_CB_ON",
"width": 100
},
{
"title": "Aisle_Fr_Door",
"field": "Aisle_Fr_Door",
"width": 100
},
{
"title": "Aisle_Re_Door",
"field": "Aisle_Re_Door",
"width": 100
},
{
"title": "Aisle_Shock_Abs_B",
"field": "Aisle_Shock_Abs_B",
"width": 100
},
{
"title": "Aisle_Shock_Abs_F",
"field": "Aisle_Shock_Abs_F",
147
"width": 100
},
{
"title": "Aisle_Fr_Access_Rem",
"field": "Aisle_Fr_Access_Rem",
"width": 100
},
{
"title": "Aisle_Re_Access_Rem",
"field": "Aisle_Re_Access_Rem",
"width": 100
},
{
"title": "Aisle_Fr_Emerg",
"field": "Aisle_Fr_Emerg",
"width": 100
},
{
"title": "Aisle_Re_Emerg",
"field": "Aisle_Re_Emerg",
"width": 100
},
{
"title": "Y_Inhibit",
"field": "Y_Inhibit",
"width": 100
},
{
"title": "X_Inhibit",
"field": "X_Inhibit",
"width": 100
},
{
"title": "HC_incl_X",
"field": "HC_incl_X",
"width": 100
},
{
"title": "HC_incl_Z",
"field": "HC_incl_Z",
"width": 100
},
{
"title": "Base_acc_x",
"field": "Base_acc_x",
"width": 100
},
{
"title": "Base_acc_z",
"field": "Base_acc_z",
"width": 100
},
{
148
"title": "TopMast_acc_x",
"field": "TopMast_acc_x",
"width": 100
},
{
"title": "TopMast_acc_z",
"field": "TopMast_acc_z",
"width": 100
},
{
"title": "HC_Temp",
"field": "HC_Temp",
"width": 100
},
{
"title": "HC_Hu",
"field": "HC_Hu",
"width": 100
},
{
"title": "Panel_Temp",
"field": "Panel_Temp",
"width": 100
},
{
"title": "Panel_Hum",
"field": "Panel_Hum",
"width": 100
},
{
"title": "X1_motor_Temp",
"field": "X1_motor_Temp",
"width": 100
},
{
"title": "X2_motor_Temp",
"field": "X2_motor_Temp",
"width": 100
},
{
"title": "Y_motor_Temp",
"field": "Y_motor_Temp",
"width": 100
},
{
"title": "X1_wheel_wear",
"field": "X1_wheel_wear",
"width": 100
},
{
"title": "X2_wheel_wear",
"field": "X2_wheel_wear",
"width": 100
149
}
],
"layout": "fitColumns",
"movableColumns": true ,
"groupBy": ""
},
"customHeight": 20
}
150
Appendix F
Sensor listing for Version 1.0 and2.0
F.1 Factory stacker sensor list
151
Name Max. Value Data Type Offset
Tstamp 1990-01-01-00:00:00 Date_And_Time 0
LU_ID_1 123456789012345678 String[18] 8
LU_Type_1 23 Int 28
LU_ID_2 123456789012345678 String[18] 30
LU_Type_2 23 Int 50
STK_Status F Char 52
STK_Mode A Char 53
Aisle_Mode R Char 54
Fault_Code 255 Int 56
Rcv_CMD L Char 58
CMD_Status R Char 59
CMD_Type R Char 60
CMD_Start_X 999 Int 62
CMD_Start_Y 999 Int 64
CMD_Final_X_LHD1 99 Int 66
CMD_Final_Y_LHD1 99 Int 68
CMD_Final_Z_LHD1 99 Int 70
CMD_Final_X_LHD2 99 Int 72
CMD_Final_Y_LHD2 99 Int 74
CMD_Final_Z_LHD2 99 Int 76
MOV_Type I Char 78
X_Mov FALSO Bool 79
Y_Mov FALSO Bool 79,1
Z1S_Mov FALSO Bool 79,2
Z1D_Mov FALSO Bool 79,3
Z2S_Mov FALSO Bool 79,4
Z2D_Mov FALSO Bool 79,5
X_Pos FALSO Bool 79,6
Y_Pos FALSO Bool 79,7
Z1S_Pos FALSO Bool 80
Z1D_Pos FALSO Bool 80,1
Z2S_Pos FALSO Bool 80,2
Z2D_Pos FALSO Bool 80,3
LU_Pre_LHD1 FALSO Bool 80,4
LU_Pre_LHD2 FALSO Bool 80,5
PLC_Restart FALSO Bool 80,6
Fr_Door_Cl FALSO Bool 80,7
Re_Door_Cl FALSO Bool 81
X_Act_I 1000 Int 82
Y_Act_I 1000 Int 84
Z1S_Act_I 1000 Int 86
Z1D_Act_I 1000 Int 88
Z2S_Act_I 1000 Int 90
Z2D_Act_I 1000 Int 92
X_Act_Pos 300000 DInt 94
Y_Act_Pos 50000 DInt 98
Z1S_Act_Pos 30000 DInt 102
Z1D_Act_Pos 30000 DInt 106
Z2S_Act_Pos 30000 DInt 110
Z2D_Act_Pos 30000 DInt 114
X_Work_H 999999 DInt 118
Y_Work_H 999999 DInt 122
Z1_Work_H 999999 DInt 126
Z2_Work_H 999999 DInt 130
X_T_Dist 1999999999 DInt 134
Y_T_Dist 1999999999 DInt 138
Z1S_T_Dist 1999999999 DInt 142
Z1D_T_Dist 1999999999 DInt 146
Z2S_T_Dist 1999999999 DInt 150
Z2D_T_Dist 1999999999 DInt 154
Weight_Re 99 Int 158
Weight_Fr 99 Int 160
Catch_ON FALSO Bool 162
Y_Ref FALSO Bool 162,1
Y_Limit FALSO Bool 162,2
Y_Speed_R_U FALSO Bool 162,3
Y_Speed_R_D FALSO Bool 162,4
Z2_Load_OH_Fr FALSO Bool 162,5
Z2_Load_OH_Re FALSO Bool 162,6
Z2_Cent_1_Fr FALSO Bool 162,7
Z2_Cent_2_Re FALSO Bool 163
Z2S_Rack_Full_L FALSO Bool 163,1
Z2S_Rack_Full_R FALSO Bool 163,2
Z2D_Rack_Full_L FALSO Bool 163,3
Z2D_Rack_Full_R FALSO Bool 163,4
Z2_Pal_Cent_1200_L FALSO Bool 163,5
Z2_Pal_Cent_1200_R FALSO Bool 163,6
Z2_Pal_Cent_1150_L FALSO Bool 163,7
Z2_Pal_Cent_1150_R FALSO Bool 164
Z2_Half_Pal_Cent FALSO Bool 164,1
Z1_Load_OH_Fr FALSO Bool 164,2
Z1_Load_OH_Re FALSO Bool 164,3
Z1_Cent_1_Fr FALSO Bool 164,4
Z1_Cent_2_Re FALSO Bool 164,5
Z1S_Rack_Full_L FALSO Bool 164,6
Z1S_Rack_Full_R FALSO Bool 164,7
Z1D_Rack_Full_L FALSO Bool 165
Z1D_Rack_Full_R FALSO Bool 165,1
Z1_Pal_Cent_1200_L FALSO Bool 165,2
Z1_Pal_Cent_1200_R FALSO Bool 165,3
Z1_Pal_Cent_1150_L FALSO Bool 165,4
Z1_Pal_Cent_1150_R FALSO Bool 165,5
Z1_Half_Pal_Cent FALSO Bool 165,6
Load_OH_L_Fr FALSO Bool 165,7
Load_OH_L_Re FALSO Bool 166
Load_OH_R_Fr FALSO Bool 166,1
Load_OH_R_Re FALSO Bool 166,2
Height_1750_L FALSO Bool 166,3
Height_1750_R FALSO Bool 166,4
Height_1800_L FALSO Bool 166,5
Height_1800_R FALSO Bool 166,6
Max_Height_L FALSO Bool 166,7
Max_Height_R FALSO Bool 167
Z_Safety_L FALSO Bool 167,1
Z_Safety_R FALSO Bool 167,2
Dead_Man_Cab FALSO Bool 167,3
Access_Door_Cab FALSO Bool 167,4
Stop_Reset_Cab FALSO Bool 167,5
Lamp_Test_Cab FALSO Bool 167,6
Emerg_Cab FALSO Bool 167,7
Auto_Switch_Cab FALSO Bool 168
Manual_Switch_Cab FALSO Bool 168,1
Upright_L FALSO Bool 168,2
Upright_R FALSO Bool 168,3
Main_Cont_ON FALSO Bool 168,4
Emerg_Chain_STK_Saf FALSO Bool 168,5
Emerg_Chain_Aisle_Saf FALSO Bool 168,6
Emerg_Chain_Aisle_Access FALSO Bool 168,7
X_Temp FALSO Bool 169
X_Brake_ON FALSO Bool 169,1
X_Ref FALSO Bool 169,2
X_Limit_Sw FALSO Bool 169,3
X_Speed_Red_Re FALSO Bool 169,4
X_Speed_Red_Fr FALSO Bool 169,5
Y_Brake_ON FALSO Bool 169,6
Over_Speed_Slack_Rope FALSO Bool 169,7
Over_Speed FALSO Bool 170
Auto_Switch_Pan FALSO Bool 170,1
Manual_Switch_Pan FALSO Bool 170,2
By_pass FALSO Bool 170,3
Emerg_Pan FALSO Bool 170,4
Manual_P FALSO Bool 170,5
Manual_N FALSO Bool 170,6
Manual_X FALSO Bool 170,7
Manual_Y FALSO Bool 171
Manual_Z1S FALSO Bool 171,1
Manual_Z1D FALSO Bool 171,2
Manual_Z2S FALSO Bool 171,3
Manual_Z2D FALSO Bool 171,4
Stop_Reset_Pan FALSO Bool 171,5
Lamp_Test_Pan FALSO Bool 171,6
Access_Door_Pan FALSO Bool 171,7
X_Brake_Res_Temp FALSO Bool 172
Y_Brake_Res_Temp FALSO Bool 172,1
Z_Motors_ON FALSO Bool 172,2
Onboard_Shock_Abs_B FALSO Bool 172,3
Onboard_Shock_Abs_F FALSO Bool 172,4
Smoke_Det FALSO Bool 172,5
Aisle_CB_ON FALSO Bool 172,6
Aisle_Fr_Door FALSO Bool 172,7
Aisle_Re_Door FALSO Bool 173
Aisle_Shock_Abs_B FALSO Bool 173,1
Aisle_Shock_Abs_F FALSO Bool 173,2
Aisle_Fr_Access_Rem FALSO Bool 173,3
Aisle_Re_Access_Rem FALSO Bool 173,4
Aisle_Fr_Emerg FALSO Bool 173,5
Aisle_Re_Emerg FALSO Bool 173,6
Y_Inhibit FALSO Bool 173,7
X_Inhibit FALSO Bool 174
HC_incl_X 180.0 Real 176
HC_incl_Z 180.0 Real 180
Base_acc_x 16000.0 Real 184
Base_acc_z 16000.0 Real 188
TopMast_acc_x 16000.0 Real 192
TopMast_acc_z 16000.0 Real 196
HC_Temp 50.0 Real 200
HC_Hum 100.0 Real 204
Panel_Temp 50.0 Real 208
Panel_Hum 100.0 Real 212
X1_motor_Temp 180.0 Real 216
X2_motor_Temp 180.0 Real 220
Y_motor_Temp 180.0 Real 224
X1_wheel_wear 8.0 Real 228
X2_wheel_wear 8.0 Real 232
F.2 Korber Supply Chain PT elevator sensor list
156
Field Type Size
Timestamp Date/time 8 bytes
LU ID Real CNV String 20 bytes
LU Type Real CNV Int 2 bytes
LU ID Virtual CNV String 20 bytes
LU Type Virtual CNV Int 2 bytes
VTD Status Char 1 byte
VTD Mode Char 1 byte
Aisle Mode Char 1 byte
Fault Code Integer 2 bytes
Received CMD Char 1 byte
CMD Status Char 1 byte
CMD Type Char 1 byte
CMD Start CNV Int 2 bytes
CMD Start Y Int 2 bytes
CMD Final CNV Real CNV Int 2 bytes
CMD Final Y Int 2 bytes
CMD Final Z Real CNV Int 2 bytes
CMD Final CNV Virtual CNV Int 2 bytes
CMD Final Y Virtual CNV Int 2 bytes
CMD Final Z Virtual CNV Int 2 bytes
Movement Type Char 1 byte
CNV Moving Bool 1 bit
Y Moving Bool 1 bit
Z1S Moving Bool 1 bit
Z1D Moving Bool 1 bit
Z2S Moving Bool 1 bit
Z2D Moving Bool 1 bit
CNV Positioned Bool 1 bit
Y Positioned Bool 1 bit
Z1S Positioned Bool 1 bit
Z1D Positioned Bool 1 bit
Z2S Positioned Bool 1 bit
Z2D Positioned Bool 1 bit
LU Present Real CNV Bool 1 bit
LU Present Virtual CNV Bool 1 bit
PLC Restart Bool 1 bit
Front door closed Bool 1 bit
Rear door closed Bool 1 bit
CNV Actual Current Int 2 bytes
Y Actual Current Int 2 bytes
Z1S Actual Current Int 2 bytes
Z1D Actual Current Int 2 bytes
Z2S Actual Current Int 2 bytes
Z2D Actual Current Int 2 bytes
CNV Actual Position Int 4 bytes
Y Actual Position Int 4 bytes
Z1S Actual Position Int 4 bytes
Z1D Actual Position Int 4 bytes
Z2S Actual Position Int 4 bytes
Z2D Actual Position Int 4 bytes
CNV Working Hours Int 4 bytes
Y Working Hours Int 4 bytes
Z1 Working Hours Int 4 bytes
Z2 Working Hours Int 4 bytes
CNV Total Distance Int 4 bytes
Y Total Distance Int 4 bytes
Z1S Total Distance Int 4 bytes
Z1D Total Distance Int 4 bytes
Z2S Total Distance Int 4 bytes
Z2D Total Distance Int 4 bytes
Load sensor rear Int 2 bytes
Load sensor front Int 2 bytes
Catching Device ON Bool 1 bit
Y Reference Bool 1 bit
Y Limit Switch Bool 1 bit
Y Speed Red Up Bool 1 bit
Y Speed Red Down Bool 1 bit
Z2 Load Overhang Front Bool 1 bit
Z2 Load Overhang Rear Bool 1 bit
Z2 Centered 1 Front Bool 1 bit
Z2 Centered 2 Rear Bool 1 bit
Z2S Rack Full Left Bool 1 bit
Z2S Rack Full Right Bool 1 bit
Z2D Rack Full Left Bool 1 bit
Z2D Rack Full Right Bool 1 bit
Z2 Pal Centered 1200 Left Bool 1 bit
Z2 Pal Centered 1200 Right Bool 1 bit
Z2 Pal Centered 1150 Left Bool 1 bit
Z2 Pal Centered 1150 Right Bool 1 bit
Z2 Half Pal Centered Bool 1 bit
Z1 Load Overhang Front Bool 1 bit
Z1 Load Overhang Rear Bool 1 bit
Z1 Centered 1 Front Bool 1 bit
Z1 Centered 2 Rear Bool 1 bit
Z1S Rack Full Left Bool 1 bit
Z1S Rack Full Right Bool 1 bit
Z1D Rack Full Left Bool 1 bit
Z1D Rack Full Right Bool 1 bit
Z1 Pal Centered 1200 Left Bool 1 bit
Z1 Pal Centered 1200 Right Bool 1 bit
Z1 Pal Centered 1150 Left Bool 1 bit
Z1 Pal Centered 1150 Right Bool 1 bit
Z1 Half Pal Centered Bool 1 bit
Load Overhang Left (Front) Bool 1 bit
Load Overhang Left (Rear) Bool 1 bit
Load Overhang Right (Front) Bool 1 bit
Load Overhang Right (Rear) Bool 1 bit
Height 1750 Left Bool 1 bit
Height 1750 Right Bool 1 bit
Height 1800 Left Bool 1 bit
Height 1800 Right Bool 1 bit
MaCNV Height Left Bool 1 bit
MaCNV Height Right Bool 1 bit
CNV Safety Left Bool 1 bit
CNV Safety Right Bool 1 bit
Dead-Man Button Cabin Bool 1 bit
Access Door Cabin Bool 1 bit
Stop Reset Cabin Bool 1 bit
Lamp Test Cabin Bool 1 bit
Emerg Button Cabin Bool 1 bit
Auto Key Switch Cabin Bool 1 bit
Manual Key Switch Cabin Bool 1 bit
Upright Left Bool 1 bit
Upright Right Bool 1 bit
Main Contactor ON Bool 1 bit
Emerg Chain VTD Safety Bool 1 bit
Emerg Chain Aisle Safety Bool 1 bit
Emerg Chain Aisle Access Bool 1 bit
CNV Temp Bool 1 bit
CNV Brake ON Bool 1 bit
CNV Reference Bool 1 bit
CNV Limit Switch Bool 1 bit
CNV Speed Red Rear Bool 1 bit
CNV Speed Red Front Bool 1 bit
Y Brake ON Bool 1 bit
Over Speed Slack Rope Bool 1 bit
Over Speed Bool 1 bit
Auto key Switch Panel Bool 1 bit
Manual Key Switch Panel Bool 1 bit
By-pass Emerg Chain Bool 1 bit
Emerg Button Panel Bool 1 bit
Manual P Bool 1 bit
Manual N Bool 1 bit
Manual CNV Bool 1 bit
Manual Y Bool 1 bit
Manual Z1S Bool 1 bit
Manual Z1D Bool 1 bit
Manual Z2S Bool 1 bit
Manual Z2D Bool 1 bit
Stop Reset Panel Bool 1 bit
Lamp Test Panel Bool 1 bit
Access Door Panel Bool 1 bit
CNV Brake Resistor Temp Bool 1 bit
Y Brake Resistor Temp Bool 1 bit
CNV Motor ON Bool 1 bit
Onboard Shock Abs Back Bool 1 bit
Onboard Shock Abs Front Bool 1 bit
Smoke Detection Bool 1 bit
Aisle CB ON Bool 1 bit
Aisle Front Door Bool 1 bit
Aisle Rear Door Bool 1 bit
Aisle Shock Abs Back Bool 1 bit
Aisle Shock Abs Front Bool 1 bit
Aisle Front Access Remote Bool 1 bit
Aisle Rear Access Remote Bool 1 bit
Aisle Front Emerg button Bool 1 bit
Aisle Rear Emerg Button Bool 1 bit
Y Inhibit Bool 1 bit
CNV Inhibit Bool 1 bit