Les tests et vérifications

A simulação seguinte pretende demonstrar o modo de recolha e processamento dos dados provenientes dos sensores, neste caso utilizando um sensor de temperatura. A demonstração presente nesta secção tem como objetivo retratar a aplicação das tecnologias mencionadas inicialmente, mas aplicadas a um pequeno caso de estudo.

Este caso de estudo é constituído por um circuito eléctrico que engloba um motor, um display, uma luz LED, um sensor de temperatura, uma breadboard, um arduino, um raspberry e uma pilha de 9 volts. Este circuito permite a recolha dos dados gerados pelo sensor de temperatura passando estes para o arduino, sendo encaminhados para o raspberry este que envia a telemetria para a plataforma. Caso haja um controlo das rotações do motor, então o fluxo funcionará exatamente ao contrário passando da plataforma para o raspberry, deste para o arduino e do arduíno para o motor. A figura abaixo representa o circuito montado englobando todos os dispositivos utilizados.

134

Figura 68 - Circuito Eléctrico montado para a simulação

Para implementação foram definidos três módulos, o módulo do arduino (que incluí o circuito eléctrico), o módulo do raspberry e da plataforma.

O arduíno funciona como um controlador que recebe os dados provenientes do sensor de temperatura e envia para o raspberry. Este dispositivo possui dois módulos de comunicação Input/Output intrínsecos que surgem no formato digital e analógico, o primeiro rege-se apenas por dois valores 0 ou 1, ou seja, funciona como um interruptor, ou está ligado, ou está desligado, só recebendo dois tipos de valores. O módulo analógico permite receber dados com amplitude entre 0 e 1023, sendo este o mais indicado para a receção dos valores da temperatura. Ligado ao arduino está obviamente o sensor de temperatura, o motor, o display e a luz LED. O sensor de temperatura encontra-se ligado ao motor e o display indica a temperatura e as rotações por minuto do mesmo. A luz LED é também indicativa da temperatura, quando esta atinge os valores mínimos aparece a cor verde, quando a temperatura do motor sobe aparece a cor vermelha.

O módulo do raspberry encontra-se conectado ao arduíno por USB recebendo desta forma os dados de telemetria provenientes deste último. Este módulo comunica com a plataforma através do protocolo MQTT desempenhando o papel de publisher e também de subscriber. O raspberry funciona

Motor Display LED Arduino Raspberry Breadboard Pilha 9V

135

como publisher na medida em que este é que publica os dados de telemetria para a plataforma, é também considerado subscriber quando a plataforma envia dados para este dispositivo, nomeadamente ordens de controlo. Este dispositivo pode ser considerado um cliente dado que acede à plataforma tanto com o intuito de armazenamento de dados como com o objetivo de receber ordens de controlo.

A plataforma utilizada designa-se de thingsboard34, esta foi selecionada pelo facto de ser uma

ferramenta open source, de utilização simplificada e utilizada para testes semelhantes a este. Esta plataforma é apenas aplicada para esta prova de conceito, visto que possibilitou a simplificação da implementação devido à sua excelente documentação. Dado o tempo disponível para a execução destes testes a thingsboard representou a melhor opção dado que esta simulação é de pequenas dimensões gerando uma quantidade mais reduzida de dados. Esta plataforma pretende ilustrar por meio de dashboards a variação da temperatura do motor podendo também controlar a velocidade de rotação do mesmo. Os dados da temperatura do motor são armazenados nesta plataforma dado que esta disponibiliza uma base de dados para desenvolvimento de protótipos e além disso, proporciona a gestão dos dados de telemetria. Assim sendo, esta framework disponibiliza um conjunto de serviços extremamente úteis para a monitorização e controlo do motor.

De forma a identificar os dispositivos conectados à thingsboard, sempre que é criado um device (neste caso um raspberry), é-lhe atribuído um ACCESS_TOKEN, desta forma a plataforma irá saber que deve recolher os dados que vierem com esta identificação. A figura seguinte ilustra os dashboards criados na thingsboard, os dois gráficos de cima possibilitam a visualização da temperatura sempre que esta sofre alterações e o terceiro permite controlar a velocidade das rotações do motor. Assim sendo, quanto maior for o número de rotações por minuto, maior será a temperatura e quanto menor for o número de rotações por minuto do motor, menor será a temperatura.

34 Consultar em: https://thingsboard.io/

136

4.5 Conclusões

Partindo da arquitetura estabelecida por meio da interoperabilidade entre os modelos de referência IIRA e RAMI da secção anterior, este capítulo abordou dois dos seus domínios, sendo eles o Asset e o Operation Domain. A figura seguinte pretende ilustrar muito sucintamente o resultado do estudo desses mesmos domínios.

O primeiro domínio conduziu a uma abordagem ao cenário industrial, este que ilustra a linha de produção do caso de demonstração do projeto PRODUTECH SIF. Nesta secção é efetuada uma primeira elucidação do funcionamento do sistema demonstrando o modo de recolha de dados provenientes das máquinas bem como o software utilizado. Numa segunda abordagem, é ilustrado o processo de negócio através da representação de um BPMN, este que engloba a demonstração das tarefas executadas

137

sequencialmente. A descrição destas tarefas assim como o tipo de dados gerado encontram-se descritas em anexo, dado o grande número de atividades do processo.

O estudo anteriormente efetuado permite, numa fase seguinte, o levantamento de requisitos para a construção da plataforma, este estudo reúne as necessidades da plataforma face ao problema exposto inicialmente. O processo de levantamento de requisitos foi passando por diversas fases, dentro das quais se inclui a definição de grupos de expectativas de alto nível, o estabelecimento das prioridades de cada requisito, chegando também à construção de use cases. Os use cases estão diretamente relacionados com as expectativas e grupos de expectativas estabelecidos anteriormente, posto isto, é viável associar a cada expectativa, um use case e seu ator correspondente. Ainda dos use cases, constam dois cenários exemplificativos, o cenário real e o ideal. O que distingue estes dois cenários é a possibilidade de controlo das máquinas, dado que, no cenário real apenas é implementado o sistema de notificações do production manager e no cenário ideal, para além do sistema de notificações, é também incluída a possibilidade de controlo, ou seja, execução de ações conforme a anomalia detetada. Estes cenários pretendem efetuar uma demonstração do impacto da plataforma nas tarefas pertencentes ao chão de fábrica, pois com esta implementação é possível reduzir o número de atividades executadas pelos operadores para além de que a resolução de anomalias pode ser executada de forma automática e imediata.

Os modelos de referência estudados no terceiro capítulo mencionam a necessidade de execução de uma arquitetura SOA, posto isto, numa penúltima secção foi construída uma representação elucidando a estratégia utilizada para a interoperabilidade entre o chão de fábrica e as restantes plataformas. Esta arquitetura foi definida com base nas normas de interoperabilidade semântica abordando também os protocolos de comunicação entre os sistemas.

Por último surge a simulação da implementação do sistema por meio da construção de um circuito eléctrico. O objetivo da simulação centra-se na demonstração da monitorização e controlo de um motor simples, representando assim um circuito exemplificativo das potencialidades da implementação das tecnologias mencionadas no chão de fábrica. Posto isto, conclui-se que existem inúmeras vantagens em englobar a plataforma na linha de produção, porque, para além da redução do número de atividades executadas manualmente, é proporcionada uma monitorização em tempo real de todos os dispositivos podendo também programar ações a executar conforme o alerta gerado. Da mesma forma que a simulação se centra na avaliação da temperatura do motor, muitas outras variáveis podem ser estudadas criando a possibilidade de implementação de inúmeras ações conforme os dados a monitorizar.

139

5. CONCLUSÕES

Este último capítulo tem como finalidade mencionar a síntese do trabalho realizado no decorrer da produção da presente dissertação, apresentar os resultados obtidos, as dificuldades e limitações que possam ter causado impacto no desenvolvimento e o trabalho futuro que poderá surgir ainda no tema explorado.