modelo de tcc para o curso de ciência da computação da univalisiaibib01.univali.br/pdf/paulo...
TRANSCRIPT
i
UNIVERSIDADE DO VALE DO ITAJAÍ
CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
DESENVOLVIMENTO DE UM SMART GATEWAY PARA O
MONITORAMENTO DE MÁQUINAS INDUSTRIAIS
Paulo Henrique da Silva
Orientadora: Michelle Silva Wangham, Dra.
Co-Orientador: Marlon C. Domenech.
São José, Novembro / 2014
ii
UNIVERSIDADE DO VALE DO ITAJAÍ
CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
DESENVOLVIMENTO DE UM SMART GATEWAY PARA O
MONITORAMENTO DE MÁQUINAS INDUSTRIAIS
Paulo Henrique da Silva
São José, Novembro / 2014
Orientadora: Michelle Silva Wangham, Dra.
Co-Orientador: Marlon C. Domenech.
Área de Concentração: Internet das Coisas
Linha de Pesquisa: Sistemas Distribuídos
Palavras-chave: Internet das Coisas, Web das Coisas, Smart Gateway, Monitoramento Remoto.
Número de páginas: 85
RESUMO
O gerenciamento eficiente de plantas industriais depende da capacidade da cobertura de
monitoramento dos equipamentos que a compõe. Isto pode ser feito através da coleta contínua dos
dados gerados por estes equipamentos, dados que podem ser desde a hora de início de um determinado
processo até o número de intervenções realizadas no equipamento que está sendo monitorado. Porém,
em muitos casos, esses equipamentos não possuem conectividade de rede ou quando possuem utilizam
diferentes tecnologias de comunicação. Esta heterogeneidade onera e, por vezes, inviabiliza o processo
de criação de soluções para integrar e monitorar remotamente esses equipamentos. Este trabalho teve
como objetivo prover o monitoramento remoto de máquinas industriais através da Internet, utilizando
o conceito de Internet das Coisas. Para tanto, foi realizada uma modelagem da solução proposta que
contou com a participação de colaboradores de uma fabricante de máquinas têxteis industriais que
auxiliaram no processo de elicitação dos requisitos da solução de monitoramento remoto. Como
resultado deste trabalho foi desenvolvido (i) uma API e serviços RESTful que foi embarcada em um
hardware com restrições computacionais (Smart Gateway) e (ii) uma aplicação chamada de Monitor. O
Smart Gateway tem como objetivo abstrair a camada de comunicação e possibilitar a integração de
dispositivos heterogêneos entre si e com sistemas na Internet. O Monitor é uma aplicação modular que
é acoplada (plug-in) ao Smart Gateway para adicionar a capacidade de interação do Smart Gateway
com diferentes interfaces como Zigbee, Bluetooth e Ethernet. Neste trabalho, o Monitor foi
desenvolvido para prover a interação do Smart Gateway com os sistemas supervisórios (SCADA) das
iii
máquinas industriais. O Smart Gateway foi implementado em uma plataforma de hardware aberto que
disponibiliza, por meio de serviços web RESTful, os recursos da máquina industrial monitorada. Isto
permite que aplicações para dispositivos móveis e outros Smart Gateways possam consumir os
recursos disponibilizados pela máquina industrial e possam monitorá-la. O Smart Gateway possui
ainda uma aplicação cliente que envia, periodicamente, os dados de monitoramento para um serviço
web RESTFul de recebimento de dados em uma nuvem privada de dados. Após a fase de
desenvolvimento, foram realizados testes com informações reais de uma máquina (logs do SCADA) e
com o serviço web de recebimento de dados, além disso, também foram realizados testes funcionais,
não funcionais e de desempenho que confirmam a viabilidade da solução.
iv
ABSTRACT
The efficient management of industrial plants relies on the ability of the monitoring coverage of
equipment that compose it. This can be done through the continuous collection of data generated by
such equipment, provided data that can be the start time of a particular process until the number of
interventions performed on the equipment being monitored. However, in many cases, these devices do
not have network connectivity or when they have use different communication technologies. This
heterogeneity costly and sometimes impedes the process of creating solutions to integrate and monitor
these devices remotely. This study aimed to provide remote monitoring of industrial machinery via the
Internet, using the concept of Internet of Things. For this, a model of the proposed solution with the
participation of employees of a manufacturer of industrial textile machines that assisted in the
elicitation of the requirements of remote monitoring solution process was carried out. As a result of
this work was (i) an API and RESTful services that was embedded in a hardware computational
constraints (Smart Gateway) and (ii) an application called Monitor. Smart Gateway aims to abstract
the communication layer and enable integration of heterogeneous devices among themselves and with
systems on the Internet. The Monitor is a modular application that is coupled (plug-in) to the Smart
Gateway to add the ability to interact with the Smart Gateway different interfaces as Zigbee, Bluetooth
and Ethernet. In this paper, the Monitor was developed to provide interaction with the Smart Gateway
supervisory systems (SCADA) of industrial machines. The Smart Gateway was implemented in
hardware that provides an open, through RESTful web services, resources industrial monitored
machine. This allows applications to mobile devices and other Smart Gateways can consume the
resources provided by the industrial machine and can monitor it. The Gateway also has a Smart Client
application that periodically sends monitoring data to a web service RESTFul receiving data in a
private cloud data. After the development phase testing with actual information from a machine
(SCADA logs) and with the web service receiving data were performed, in addition, functional, non-
functional and performance tests that confirm the feasibility of the solution were also performed.
v
LISTA DE QUADROS
Quadro 1 Comparação entre serviços WS-* e serviços RESTful. .......................................................... 28 Quadro 2. Comparação entre os 10 hardwares selecionados .................................................................. 32 Quadro 3. Comparativo dos trabalhos relacionados com o trabalho proposto. ...................................... 37 Quadro 4. Detalhamento do Caso de Uso UC01. Inserir URL do Smart Gateway ................................ 44 Quadro 5. Detalhamento do Caso de Uso UC02. Alterar URL do Smart Gateway .............................. 45
Quadro 6. Detalhamento do Caso de Uso UC03. Selecionar arquivo de log monitorado. ..................... 45 Quadro 7. Detalhamento do Caso de Uso UC04. Alterar o arquivo de log monitorado. ........................ 45 Quadro 8. Detalhamento do Caso de Uso UC05. Iniciar monitoramento............................................... 46 Quadro 9. Detalhamento do Caso de Uso UC06. Parar monitoramento. ............................................... 46
Quadro 10. WADL do Smart Gateway recuperado pelo navegador. ...................................................... 49 Quadro 11: Detalhamentos do caso de teste CT 01 ................................................................................ 52 Quadro 12: Retorno do recurso "/history" para o CT01 ......................................................................... 52 Quadro 13: Detalhamentos do caso de teste CT 02 ................................................................................ 53
Quadro 14: Retorno do recurso "/history" para o CT02 ......................................................................... 53 Quadro 15: Detalhamentos do caso de teste CT 03 ................................................................................ 54 Quadro 16: Retorno do recurso "/history" para o CT03 ......................................................................... 54
Quadro 17: Detalhamentos do caso de teste CT 04 ................................................................................ 55 Quadro 18: Retorno do recurso "/history" para o CT04 ......................................................................... 56 Quadro 19: Detalhamentos do caso de teste CT 05 ................................................................................ 58
Quadro 20: Detalhamentos do caso de teste CT 06 ................................................................................ 59 Quadro 21: Retorno do recurso "/history" para o CT06 ......................................................................... 60
Quadro 22: Detalhamentos do caso de teste CT 07 ................................................................................ 61
Quadro 23: Retorno do recurso "/history" para o CT07 ......................................................................... 61
Quadro 24: Detalhamentos do caso de teste CT 08 ................................................................................ 63 Quadro 25: Retorno do recurso "/history" para o CT08 ......................................................................... 63
Quadro 26: Detalhamentos do caso de teste CT 09 ................................................................................ 64 Quadro 27: Retorno do recurso "/history" para o CT09 ......................................................................... 64 Quadro 28: Detalhamentos do caso de teste CT 10 ................................................................................ 64 Quadro 29: Retorno do recurso "/history" para o CT010 ....................................................................... 65
Quadro 30: Detalhamentos do caso de teste CT 11 ................................................................................ 65 Quadro 31: Retorno do recurso "/history" para o CT011 ....................................................................... 66 Quadro 32: Detalhamentos do caso de teste CT 12 ................................................................................ 66 Quadro 33: Retorno do recurso "/history" para o CT012 ....................................................................... 67 Quadro 34. Detalhamento do Caso de Teste de desempenho CT01 ....................................................... 67
Quadro 35. Resultado do caso de teste CT01 ......................................................................................... 68
Quadro 36. Detalhamento do Caso de Teste de desempenho CT02 ....................................................... 68
Quadro 37. Resultados do caso de teste de desempenho CT02 ............................................................. 69 Quadro 38. Detalhamento do Caso de Teste de desempenho CT03 ....................................................... 69 Quadro 39. Resultado do CT03 - Uso de recursos computacionais........................................................ 70 Quadro 40. Resultado do CT03 - Tempo de Envio e Recebimento de mensagens ................................ 70 Quadro 41. Detalhamento do Caso de Teste de desempenho CT04 ....................................................... 70
Quadro 42. Resultados do caso de teste de desempenho CT04 .............................................................. 71 Quadro 43. Detalhamento do caso de teste CT05 ................................................................................... 71 Quadro 44. Resultados do caso de teste desempenho CT05 ................................................................... 71 Quadro 45. Detalhamento do caso de teste CT06 ................................................................................... 72
vi
Quadro 46. Resultados do caso de deste de desempenho CT06 ............................................................. 72
Quadro 47: Retorno do recurso "/history" para o CT05 ......................................................................... 81
vii
LISTA DE ABREVIATURAS E SIGLAS
API Application Programming Interface
CFM Célula Flexível de Manufatura
COD Code On Demand
CPU Central Processing Unit
CRUD Create, Read, Update e Delete
EUA Estados Unidos da America
HMI Human Machine Interface
HTML Hypertext Markup Language
HTTP Hypertext Transfer Protocol
IHM Interface Homem-Máquina
IoT Internet of Things
IP Internet Protocol
ITU International Telecommunication Union
JavaEE Java Enterprise Edition
JAX-RS Java API for RESTful Services
JSON JavaScript Object Notation
JSR-311 Java Specification Requests
LAN Local Area Network
M2M Machine to Machine
NFC Near Field Communication
NIC National Intelligence Council
ONU Organização das Nações Unidas
RAM Random Access Memory
REST REpresantational State Transfer
RFID Radio Frequency Identification
ROA Resource Oriented Architecture
ROM Read Only Memory
RPC Remote Procedure Call
SCADA Supervisory Control and Data Acquisition
SOAP Simple Object Access Protocol
TCC Trabalho de Conclusão de Curso
TIC Tecnologia da Informação e Comunicação
UNIVALI Universidade do Vale do Itajaí
URI Universal Resource Identifier
WADL Web Application Description Language
WOT Web Of Things
WSDL Web Service Description Language
XML eXtensible Markup Language
viii
LISTA DE FIGURAS
Figura 1. Visões da Internet das Coisas ............................................................................................. 21 Figura 2. Integração Direta e Indireta na Web das Coisas ................................................................. 25 Figura 3. Os 10 principais hardwares................................................................................................. 30
Figura 4. Principal uso do hardware adquirido .................................................................................. 31 Figura 5. Arquitetura da aplicação em três camadas. ........................................................................ 35 Figura 6. Cliente/ Servidor em três camadas ..................................................................................... 37 Figura 7. Visão geral do uso do Smart Gateway no ambiente industrial ........................................... 40 Figura 8. Diagrama de Casos de Uso da aplicação Monitor .............................................................. 44
Figura 9. Ciclo de vida da aplicação Monitor .................................................................................... 47
Figura 10. Integração Monitor, Smart Gateway e Serviços Externos ................................................ 47 Figura 11. API REST do Smart Gateway. ......................................................................................... 48
Figura 12. Beagle Bone Black ........................................................................................................... 50 Figura 13. Diagrama de classe da aplicação Monitor ........................................................................ 80
9
SUMÁRIO
INTRODUÇÃO ........................................................................................ 11
1.1 PROBLEMA DE PESQUISA........................................................................... 13
1.1.1 Solução Proposta ............................................................................................. 14
1.1.2 Delimitação de Escopo .................................................................................... 15
1.1.3 Justificativa ...................................................................................................... 15
1.2 OBJETIVOS ...................................................................................................... 16
1.2.1 Objetivo Geral ................................................................................................. 16
1.2.2 Objetivos Específicos ...................................................................................... 16
1.3 METODOLOGIA .............................................................................................. 16
1.3.1 Metodologia da Pesquisa ................................................................................ 16
1.3.2 Procedimentos Metodológicos ........................................................................ 17
2 FUNDAMENTAÇÃO TEÓRICA ...................................................... 18
2.1 MONITORAMENTO REMOTO DE MÁQUINAS INDUSTRIAIS ........... 18
2.2 INTERNET DAS COISAS ............................................................................... 19
2.3 WEB DAS COISAS ........................................................................................... 23
2.4 REST ................................................................................................................... 26
2.4.1 Representação dos Recursos com JSON ....................................................... 28
2.5 PLATAFORMA DE HARDWARE ABERTO ............................................... 29
3 TRABALHOS RELACIONADOS .................................................... 33
3.1 IOT@WORK ..................................................................................................... 33
3.2 WEB BASED INTERFACE TO SCADA SYSTEM ...................................... 34
3.3 PROPOSTA DE ARQUITETURA ORIENTADA A RECURSOS PARA
SCADA NA WEB ...................................................................................................... 35
3.4 AN INTERNET BASED DITRIBUTED CONTROL SYSTEM: A CASE
STUDY OF OIL REFINERIES ............................................................................... 36
3.5 ANÁLISE COMPARATIVA............................................................................ 37
4 DESENVOLVIMENTO ...................................................................... 39
4.1 LEVANTAMENTO INICIAL.......................................................................... 39
4.2 VISÃO GERAL DA SOLUÇÃO PROPOSTA ............................................... 39
4.3 ANÁLISE DE REQUISITOS ........................................................................... 41
4.3.1 Análise de Requisitos ...................................................................................... 42
4.4 MODELAGEM DO SISTEMA ........................................................................ 43
4.4.1 Diagramas de Sequência ................................................................................. 46
4.4.2 WADL do Smart Gateway ............................................................................... 48
4.5 TECNOLOGIAS UTILIZADAS ..................................................................... 49
4.5.1 Beagle Bone Black ........................................................................................... 50
4.5.2 Oracle Java Standard Edition Embedded .................................................... 50
10
4.5.3 Jersey Framework ........................................................................................... 51
4.6 AVALIAÇÃO E RESULTADOS ..................................................................... 51
4.6.1 Casos de Teste .................................................................................................. 51
4.6.2 Casos de Teste de Desempenho ...................................................................... 67
5 CONCLUSÕES .................................................................................... 74
5.1 TRABALHOS FUTUROS ................................................................................ 74
REFERÊNCIAS BIBLIOGRÁFICAS ................................................... 76
APÊNDICE A – DIAGRAMA DE CLASSES ...................................... 80
APÊNDICE B – RETORNO DO RECURSO “/history” REFERENTE
AO CT05 ................................................................................................... 81
11
INTRODUÇÃO
Um assunto de grande importância para a indústria é o monitoramento remoto das máquinas
e equipamentos industriais. Segundo Ramamurthy, Bhargavi e Shashikumar (2010), o controle,
monitoramento remoto e a manutenção inteligente são alguns dos mais importantes mecanismos
para o aumento da produção e da disponibilidade nesse ambiente e, recentemente, tem havido muito
interesse das empresas por implantá-los.
Uma forma de permitir a comunicação entre dispositivos heterogêneos garantindo também o
seu monitoramento remoto é utilizando o conceito de Internet das Coisas (Internet of Things - IoT).
Segundo Atzori, Iera e Morabito (2010), a ideia básica deste conceito é a presença generalizada de
uma variedade de coisas ou objetos, como etiquetas RFID (Radio Frequency Identification),
sensores, atuadores e telefones celulares. Esses objetos são capazes de interagir uns com os outros
utilizando mecanismos de endereçamento único e protocolos de comunicação padronizados, de
modo a cooperar com seus vizinhos (outros objetos) para alcançar objetivos comuns.
Atzori, Iera e Morabito (2010) estimam que uma grande quantidade de objetos estarão
conectados à Internet, sendo que estes se tornarão os maiores emissores e receptores de tráfego da
rede. Segundo CERP-IoT (2010), em 2010, havia aproximadamente 1,5 bilhão de computadores
pessoais e mais de 1 bilhão de celulares com acesso à Internet e é esperado para 2020 algo entre 50
e 100 bilhões de dispositivos conectados à Internet. Uma pesquisa realizada pela NIC (2008) prevê
que em 2025 todos os objetos do cotidiano estarão conectados a Internet. Estes podem ser quaisquer
objetos, tais como eletrodomésticos, sensores, atuadores, celulares, tablets e computadores, que
possam ser identificados e interligados à Internet para trocar informações e tomar decisões para
atingir objetivos comuns.
Um relatório do ITU (International Telecommunication Union) apontou que na Internet das
Coisas qualquer objeto capaz de ser conectado em rede poderá se comunicar a qualquer tempo e em
qualquer lugar (ITU, 2005). Contudo, a perfeita integração das “coisas” com a Internet é um
desafio. Os maiores obstáculos que tornam complexa esta integração são as restrições de
conectividade, fontes de energia, segurança, fatores geográficos e custo de instalação e operação
(MAHALLE et al., 2010).
12
Com estas restrições alguns dispositivos não suportam diretamente a conectividade com a
Internet por meio do protocolo IP (Internet Protocol), dificultando sua integração. Segundo De
França et al. (2011), quando o protocolo IP não é suportado é necessário utilizar um padrão de
integração diferente. Nessas situações, é possível utilizar um dispositivo intermediário entre o
objeto e sistemas finais na Internet chamado Smart Gateway. Este dispositivo receberá os dados
fornecidos pelos objetos e os interpretará a fim de direcioná-los para um banco de dados, um
servidor ou outro nó da rede que processe as informações de forma mais especializada. Da mesma
forma, o Smart Gateway enviará dados aos objetos permitindo configurações, atualizações,
monitoramento, etc. O Smart Gateway também poderá receber e enviar dados para um software
externo que pode ser uma aplicação Web, aparelhos celulares, tablets ou até mesmo outro Smart
Gateway.
Para facilitar o desenvolvimento de aplicações para esses dispositivos que permita que os
serviços e os dados dos dispositivos sejam utilizados em diferentes aplicações, é necessário o uso de
uma linguagem em comum. Uma abordagem proposta para o uso de uma linguagem comum no
desenvolvimento de aplicações de Internet das Coisas é a Web das Coisas (Web of Things - WoT)
(GUINARD et al., 2009).
A WoT objetiva a interação entre dispositivos de IoT através do uso de protocolos Web já
difundidos na Internet atual, facilitando assim a troca de mensagens entre dispositivos e entre estes
e outras aplicações da Internet, promovendo assim uma maior interoperabilidade entre estes. Na
WoT, a integração dos dispositivos ocorre no nível de aplicação, acima da conectividade de rede.
Com isso, a WoT agrega valor às informações geradas pelos objetos físicos através da utilização
dos recursos da Web, o que ajuda a concretizar a visão da Internet das Coisas (GUINARD et al.,
2009).
No contexto da WoT, uma metodologia para a criação de aplicações em linguagem comum
para os dispositivos é o REST (REpresentational State Transfer). O REST é um estilo de
arquitetura de software que pode ser aplicado no desenvolvimento de sistemas denominados
RESTful. (DE FRANÇA et al., 2011, p. 110).
O REST tem o intuito de aumentar a interoperabilidade entre as partes de uma aplicação
distribuída através da reutilização de padrões da Web e utiliza características inerentes do protocolo
HTTP (Hipertext Transfer Protocol), como autenticação, autorização, criptografia, compressão e
caching. Além disso, os princípios REST podem ser mapeados nos métodos básicos do protocolo
HTTP (GET, POST, PUT e DELETE) para criar sistemas CRUD (Create, Read, Update, Delete) de
13
uma aplicação RESTful. Os recursos dos serviços RESTful são identificados e encapsulados por um
URI (Uniform Resource Identifier). Essas características fazem do REST a opção mais adequada
para construção de APIs (Application Programming Interface) Web para acesso a objetos do mundo
real (GUINARD et al., 2009).
Segundo De França et al. (2011), o Smart Gateway atua como uma ponte entre a Web e os
dispositivos inteligentes ao fornecer uma interface Web RESTful de acesso aos recursos e
subrecursos dos dispositivos e ao se comunicar com tais dispositivos através de suas APIs
específicas. O Smart Gateway tem um endereço IP e compreende os protocolos proprietários dos
diferentes dispositivos conectados através do uso de controladores (drivers) dedicados. Assim,
requisições vindas da Internet para acesso a algum dispositivo irão passar pelo Smart Gateway, que
irá redirecionar a requisição através do protocolo específico.
Dentro deste contexto, este trabalho visa contribuir com área de controle e monitoramento
remoto de máquinas industriais por meio da Web das Coisas.
1.1 PROBLEMA DE PESQUISA
A tomada de decisão faz parte do dia a dia das empresas. Logo, informações acerca do
processo que se está analisando são cada vez mais importantes. Na indústria, dados como o estado
de sensores de temperatura, energia elétrica e tempo de funcionamento da máquina são tão
importantes quanto a velocidade com que estas informações são disponibilizadas para os gestores.
Uma dificuldade nesse cenário é lidar com máquinas que não foram projetadas para comunicação
M2M (Machine-to-Machine) ou que não possuem suporte ao protocolo IP. Portanto, existe a
necessidade de uma solução que possa ser agregada às máquinas sem suporte ao M2M, evitando o
custo de redesenhar uma máquina para disponibilizar uma interface para comunicação.
Segundo Kirubashankar, Krishnamurthy e Indra (2009), as máquinas industriais integram
um vasto número de sistemas embarcados, conectados ou não a uma rede de comunicação. Estas
máquinas podem ter sensores e atuadores que possibilitam operações de monitoramento e controle.
Atualmente, a maioria das máquinas disponíveis no mercado de vestuário restringe sua operação e
monitoramento ao ambiente da rede local da indústria. Nestes ambientes industriais também é
restrita a interoperabilidade entre máquinas de diferentes fabricantes.
14
De acordo com De França et al. (2011), o Smart Gateway é uma das possíveis soluções para
garantir a integração de objetos em redes quando os dispositivos não possuem conectividade com a
Internet através do protocolo IP. O Smart Gateway será uma appliance (hardware e software
embarcado) que utilizará uma plataforma de hardware aberto.
As seguintes questões de pesquisa foram consideradas durante o desenvolvimento deste
trabalho:
Como agregar o serviço de monitoramento remoto às máquinas industriais de uma
empresa do setor do vestuário por meio de um Smart Gateway?
Quais plataformas de hardware aberto de baixo custo podem ser utilizadas para a
solução de monitoramento remoto de máquinas industriais e qual o mais adequado?
Quais os impactos da solução proposta na operação das máquinas e na infra-estrutura de
rede de um ambiente industrial?
1.1.1 Solução Proposta
Este trabalho visou contribuir para o monitoramento remoto de máquinas industriais por
meio da WoT, com o objetivo de conceber ambientes industriais inteligentes (smart). Durante este
trabalho foi desenvolvido um sistema de monitoramento remoto (via Internet) para máquinas
industriais sob a plataforma de hardware aberto Beagle Bone Black compondo desta forma o Smart
Gateway que faz a ponte entre os consumidores e os recursos. Os consumidores podem ser usuários,
sistemas e até outras máquinas através de seus próprios Smart Gateways.Os recursos representam os
sensores, atuadores e outros componentes de uma máquina. Logo, o Smart Gateway representa
virtualmente uma máquina industrial.
O Smart Gateway é responsável por disponibilizar os recursos monitorados através de
serviços Web RESTful para os usuários e para outras aplicações na Internet, além de interfacear
com cada recurso monitorado na máquina, através da linguagem específica de cada um. Portanto,
além de ter o papel de ponte entre recursos e usuários ou aplicações na Internet, a solução proposta
abstrai os recursos presentes na máquina para usuários ou aplicações que precisam acessá-los.
15
1.1.2 Delimitação de Escopo
Este trabalho realizou um estudo sobre as possíveis plataformas de hardware aberto
disponíveis no mercado que atendam os requisitos funcionais e não funcionais elencados durante a
modelagem da API.
Por ser um intermediador de objetos na rede com capacidade de interpretar protocolos,
podendo assim determinar o destino de pacotes, foi realizado um estudo avaliando os impacto do
Smart Gateway no ambiente de rede industrial para demonstrar sua viabilidade. Experimentos
foram realizados com as próprias máquinas industriais de forma a avaliar a aplicabilidade da
solução proposta. Os experimentos quantificaram os impactos no uso de recursos computacionais
na plataforma de hardware aberto e se basearam nas métricas de: (i) consumo de memória, (ii)
consumo de CPU (Central Processing Unit) e (iii) espaço de armazenamento utilizado. Testes
funcionais e não funcionais foram realizados visando avaliar o software desenvolvido.
1.1.3 Justificativa
A necessidade de informação sobre as máquinas industriais é de extrema importância para
que os gestores das empresas possam tomar ciência do cenário corrente de seu chão de fábrica.
Ramamurthy, Bhargavi e Shashikumar (2010) afirmam que o controle e monitoramento remotos e a
manutenção inteligente são alguns dos mais importantes mecanismos para o aumento da produção e
da disponibilidade nesse ambiente e que, recentemente, tem havido muito interesse das empresas
por implantá-los.
Segundo Kirubashankar, Krishnamurthy e Indra (2009), isto ocorre porque a manutenção
inadequada causa o colapso e o atraso na identificação de causas de falhas tornam unidades
industriais inutilizáveis. Segundo Ramamurthy, Bhargavi e Shashikumar (2010), tais problemas
podem ser resolvidos por meio do monitoramento constante da planta industrial e das condições
ambientais a partir de uma localização remota. Tal necessidade pode esbarrar em máquinas
obsoletas ou que simplesmente não foram projetadas para disponibilizar uma interface que permita
a interconexão. Nesses casos, segundo De França et al. (2011), é possível utilizar um dispositivo
intermediário entre o objeto e sistemas finais na Internet chamados Smart Gateway.
16
1.2 OBJETIVOS
Esta seção formaliza os objetivos do trabalho, conforme descrito a seguir.
1.2.1 Objetivo Geral
Prover o monitoramento e controle remoto de máquinas industriais por meio do de um
Smart Gateway conectado à Internet.
1.2.2 Objetivos Específicos
1. Levantar, junto à (Empresa X)1 os problemas e necessidades de assistência e suporte
técnico de suas máquinas, de forma a identificar quais variáveis e estados devem ser
monitorados nas máquinas e os requisitos funcionais e não funcionais do Smart
Gateway;
2. Desenvolver os serviços Web RESTful do Smart Gateway a serem embarcados em uma
plataforma de hardware aberto para prover o serviço de monitoramento de máquinas
industriais; e
3. Avaliar os impactos do uso do Smart Gateway, em termos de desempenho da rede e uso
de recursos computacionais dos dispositivos, considerando a aplicação de
monitoramento remoto.
1.3 METODOLOGIA
1.3.1 Metodologia da Pesquisa
Para o desenvolvimento da pesquisa, foi aplicado o método hipotético-dedutivo. A pesquisa
buscou gerar conhecimentos para o desenvolvimento de aplicação para a solução de um problema
específico, seguindo assim a natureza de pesquisa aplicada. Em relação à abordagem do problema, a
pesquisa é em parte qualitativa e em parte quantitativa. Qualitativa porque avaliou a qualidade do
1 Devido a requisitos de segredo industrial, durante o texto deste projeto será utilizado o termo “Empresa X” para
representar a empresa do setor têxtil utilizada para pesquisas e experimentos. A empresa real utilizada nesse projeto
prefere manter sigilo de seus estudos de Pesquisa e Desenvolvimento (P&D).
17
projeto utilizando métodos de engenharia de software e quantitativa porque mensurou o impacto
que a utilização do Smart Gateway provocou quando aplicado em um estudo de caso.
1.3.2 Procedimentos Metodológicos
Para o alcance dos objetivos deste trabalho foram realizados quatro procedimentos, pesquisa
bibliográfica, modelagem da solução proposta, implementação e avaliação:
Pesquisa bibliográfica: a pesquisa bibliográfica consistiu em pesquisar conceitos para a
definição exata do problema. A pesquisa concentrou-se em obter um melhor
entendimento dos conceitos envolvidos com o projeto, estudando arquiteturas de APIs
tipo REST e ferramentas para auxiliar o desenvolvimento das mesmas; e
Modelagem da solução proposta: Modelagem do Smart Gateway e da aplicação Monitor,
incluindo a análise de requisitos funcionais e não funcionais, a descrição dos casos de
uso e diagramas de sequência;
Implementação: Utilizando os conceitos estudados e a modelagem, foram desenvolvidas
dois principais softwares: a aplicação Monitor e o software embarcado do Smart
Gateway.
Avaliação: A avaliação foi realizada com base no entendimento sobre as regras de
negócio o que possibilitou a validação e verificação dos requisitos funcionais e não
funcionais construídos, além disso, também foi avaliado o desempenho da solução por
meio da execução de casos de testes específicos para esse fim.
18
2 FUNDAMENTAÇÃO TEÓRICA
Este capítulo é composto por alguns tópicos necessários para obter o conhecimento teórico
suficiente para o desenvolvimento de um Smart Gateway para o monitoramento de máquinas
industriais, tais como o Monitoramento Remoto de Máquinas Industriais, a Internet das Coisas, a
Web das Coisas, REST e Plataforma de Hardware Aberto.
2.1 MONITORAMENTO REMOTO DE MÁQUINAS INDUSTRIAIS
A visibilidade do chão de fábrica, obtida por meio do monitoramento de máquinas
industriais, é de suma importância para que gestores e administradores do ambiente monitorado
consigam compreender a real situação dos estados de seus equipamentos e possam então definir
prioridades, tomar decisões ou planejá-las. Segundo Chiavenato (2010) tomar decisões é identificar
e selecionar um curso de ação para lidar com um problema específico ou extrair vantagens em uma
oportunidade.
Para tanto, a obtenção de indicadores se torna um requisito fundamental. Kligerman (2006)
afirma que os indicadores são desenvolvidos pela necessidade de tratar a informação para entender
fenômenos complexos, “[...] tornando-os quantificáveis e compreensíveis de maneira que possam
ser analisados, utilizados e serem transmitidos [...]”.
Uma abordagem comumente utilizada é a adoção de sistemas SCADA. Segundo (BAILEY;
WRIGHT, 2003), aplicativos SCADA são utilizados na supervisão e controle de processos.
Segundo Polônia (2011), no contexto de aplicações de automação industrial os sistemas SCADA
possuem um papel importante, que é o de fornecer os dados de chão de fábrica para outras
aplicações, além de receberem comandos de controle das mesmas tendo desta forma um papel mais
operacional.
No contexto da proposta deste trabalho, esses indicadores podem ser, por exemplo, a
quantidade de intervenções realizadas nas máquinas que, quando combinados com outros dados
como datas e horários dessas intervenções e comparados com o comportamento de outras máquinas,
podem indicar uma situação atípica produzindo assim informação necessária para o apoio às
decisões.
19
Para realizar a coleta e transmissão desses indicadores, o monitoramento constante do chão
de fábrica em conjunto com a Internet podem ser grandes aliados. Ramamurthy, Bhargavi e
Shashikumar (2010) afirmam que o controle, monitoramento remoto e a manutenção inteligente são
alguns dos mais importantes mecanismos para o aumento da produção e da disponibilidade nesse
ambiente e que, recentemente, tem havido muito interesse das empresas por implantá-los. Uma
justificativa para tal comportamento é descrita por Kirubashankar, Krishnamurthy e Indra (2009),
quando afirmam que a manutenção inadequada causa um colapso e o atraso na identificação de
causas de falha tornam unidades industriais inutilizáveis. Segundo Ramamurthy, Bhargavi e
Shashikumar (2010), tais problemas podem ser resolvidos através do monitoramento constante da
planta industrial e das condições ambientais a partir de uma localização remota
2.2 INTERNET DAS COISAS
Segundo Xiang e Li (2009), a Internet das Coisas (IoT) é considerada como a terceira onda
da indústria da informação e atrai atenção crescente por causa das perspectivas de aplicações
industriais. Atzori, Iera e Morabito (2010) afirmam que a ideia básica da IoT é a presença
generalizada de uma variedade de coisas ou objetos, como etiquetas RFID (Radio Frequency
Identification), sensores, atuadores e telefones celulares, os quais, por meio de esquemas de
endereçamento único, são capazes de interagir uns com os outros e cooperar com seus vizinhos para
alcançar objetivos comuns.
Miorandi et al. (2012) definem essas coisas ou dispositivos inteligentes como sendo
entidades que possuem as seguintes características:
Um conjunto mínimo de funcionalidades de comunicação, tais como a capacidade de
ser descoberto e capacidade para aceitar requisições e produzir respostas;
Possuir um identificador único dentro de seu contexto (por exemplo, Internet e
Intranet);
Estar associada a pelo menos um nome e um endereço. O nome é uma descrição
legível do objeto podendo ser usada de forma intuitiva. O endereço é uma cadeia de
caracteres legíveis, que pode ser usado para comunicar-se com o objeto;
20
Possuem algumas capacidades básicas de computação. Isto pode variar desde a
capacidade de responder um sinal recebido (como etiquetas RFID passivas) até a
capacidade de executar operações bastante complexas, incluindo a descoberta de
serviço e as tarefas de gestão da rede; e
Pode possuir meios para detectar os fenômenos físicos (por exemplo, temperatura e
nível de radiação eletromagnética de luz) ou para desencadear ações que têm um
efeito sobre a realidade física (por exemplo, acionar a luz de emergência quando a
temperatura alcançar valores configurados).
Segundo Miorandi et al. (2012), a IoT está emergindo como uma das principais tendências
que moldam o desenvolvimento de tecnologias no setor das TIC (Tecnologia da Informação e
Comunicação) em geral. É a mudança da Internet usada para interconexão de dispositivos de
usuário final para a Internet usada para interligação de objetos físicos que comunicam entre si e/ou
com seres humanos, a fim de oferecer um determinado serviço.
O NIC (National Intelligence Council) dos EUA classifica a IoT como uma das seis
tecnologias civis mais promissoras, com impactos potenciais sobre o futuro das pessoas e o poder
dos EUA. O NIC prevê ainda que por volta de 2025 as coisas do cotidiano como embalagens de
alimentos, móveis e documentos podem estar integrados através da IoT. Além disto, o NIC destaca
também as oportunidades que surgirão, a partir de demandas populares combinadas com os avanços
da tecnologia, as quais podem alavancar uma difusão generalizada da IoT, e que consequentemente,
como a atual Internet, pode contribuir para o desenvolvimento econômico (NIC,2008).
Os dispositivos inteligentes que fazem parte da IoT possuem restrições computacionais,
como memória RAM (Random Access Memory) ou ROM (Read Only Memory) e poder de
processamento e de energia (HUMMEN et al., 2013). Além disto, os mecanismos de comunicação
de alguns dispositivos, na maioria das vezes sem fio, possuem baixa potência de transmissão e
baixa taxa de dados (MAHALLE et al., 2010). Segundo Atzori, Iera e Morabito (2010) existe
também uma grande quantidade de dispositivos heterogêneos que necessitam estar integrados, o que
demanda uma preocupação com relação à interoperabilidade e integração dos mecanismos de
comunicação.
21
De acordo com Atzori, Iera e Morabito (2010), a IoT pode ser orientada em três principais
visões: visão orientada a “Coisas”, visão orientada à “Internet” e visão orientada a “Semântica”.
Essas visões podem ser percebidas analisando o próprio termo “Internet das Coisas”, onde
“Internet” remete a rede mundial de computadores e “coisas” remete à objetos genéricos. Quando as
duas palavras são interligadas assumem um significado que rompe barreiras e introduz um nível de
inovação ainda não percebido pelas TICs (Tecnologia de Informação e Comunicação).
Semanticamente, de acordo com Atzori, Iera e Morabito (2010), a "Internet das Coisas"
significa uma rede mundial de objetos interligados, endereçáveis, capazes de armazenar
informações e com o poder de trocá-las, criando um ambiente mais desafiador. A Figura 1 detalha
as três visões citadas pelos autores.
Figura 1. Visões da Internet das Coisas
Fonte: Atzori, Iera e Morabito (2010)
22
As três visões são descritas a seguir:
Visão orientada a coisas: Considera as coisas como itens simples, por exemplo,
etiquetas RFID, porém, não somente estas coisas simples. Trata de aspectos como
endereçamento único e global (para acesso direto às coisas por meio da Internet) e da
identificação unívoca das coisas. Um dos pontos relevantes dessa visão é que, para a
efetiva concretização da IoT, constata-se a necessidade de aumentar a inteligência
das coisas;
Visão orientada à Internet: Responsável pelos protocolos necessários e como esses
devem ser adaptados para permitir a troca de informações entre as coisas na IoT.
Nessa visão, estão as pesquisas e padrões que tratam da adaptação do protocolo IP
para o ambiente de IoT; e
Visão orientada à Semântica: A quantidade de coisas conectadas à rede (Internet do
Futuro) está destinada a ser muito alta. Nesta visão incluem questões como
representação, armazenamento, busca e organização da grande quantidade de dados
gerados na IoT. Neste contexto, as tecnologias semânticas deverão desempenhar um
papel fundamental, pois serão usadas para modelagem das coisas, para extração do
conhecimento dos dados, para o raciocínio sobre os dados gerados na IoT, para
criação de ambientes de execução semânticos e para definição da arquitetura que irá
acomodar os requisitos da IoT.
Xiang e Li (2009) afirmam que objetos inteligentes conectados na IoT podem ser utilizados
nos mais diversos ambientes, como plataformas de petróleo, mineração, ambientes florestais, túneis,
oleodutos, etc. Além disso, em situações de perigo como terremotos, incêndios, inundações, zona de
radiação e assim por diante. Nessas situações os objetos dessa infraestrutura poderiam descobrir um
ao outro, aproveitar recursos um do outro para obter e utilizar dados entre si e entre o mundo,
aumentando assim o alcance e a confiabilidade dos serviços.
23
2.3 WEB DAS COISAS
Inspirado na ideia da IoT surgiu um paradigma de desenvolvimento de aplicações conhecido
como a Web das Coisas (do inglês, Web of Things – WoT). Esse conceito propõe a adoção de
padrões Web a fim de oferecer plataforma comum para que diferentes tipos de dispositivos possam
ser beneficiados pelas tecnologias existentes na Web, além de facilitar o desenvolvimento de
aplicativos para tais dispositivos (DE FRANÇA et al., 2011).
O objetivo da WoT é alavancar a visão de conectividade entre o mundo físico e o mundo
digital, fazendo com que a Web atual passe a englobar também objetos do mundo físico, objetos
esses os quais passarão a ser tratados da mesma forma que qualquer outro recurso Web (DE
FRANÇA et al., 2011).
Porém, muitos objetos estão conectados à Internet utilizando softwares e interfaces distintas,
ou seja, desenvolvendo a interface de seus dispositivos sem respeitar um padrão em comum. Isso
dificulta a integração de dados e serviços entre estes dispositivos (GUINARD, 2010).
O uso das linguagens, protocolos e interfaces específicas de cada tipo de dispositivo faz com
que o desenvolvimento de aplicativos para os mesmos seja uma tarefa complexa, pois é necessário
que o desenvolvedor possua conhecimento especializado para cada dispositivo utilizado no projeto.
Dessa forma, para facilitar o desenvolvimento de serviços no topo desses dispositivos, permitindo
também que os serviços e os dados dos mesmos sejam compostos em diferentes aplicações, é
necessário utilizar uma linguagem comum a diferentes dispositivos (GUINARD, 2010).
A integração dos dispositivos à Web ocorre no nível de aplicação (GUINARD, 2010). Tal
integração permite que ferramentas e técnicas da Web (por exemplo, navegadores, ferramentas de
busca e sistemas de cache), linguagens da Web (por exemplo, HTML e JavaScript) e técnicas de
interação com o usuário (por exemplo, navegação, vinculação e bookmarking) possam ser aplicadas
para objetos do mundo real (GUINARD, 2010). Desta forma, de acordo com Guinard et al. (2009),
a WoT possibilita a agregação de valor às informações providas pelos objetos físicos através da
utilização de todos os recursos disponíveis na Web, o que por sua vez alavanca a concretização da
visão da IoT.
24
A WoT preconiza que qualquer objeto físico possa enviar seus dados para pontos
descentralizados e esses dados podem ser utilizados e reutilizados em diferentes aplicações
(GUINARD, 2010).
Segundo Guinard et al. (2009), a extensão da Web proposta pela WoT é realizada através da
adoção do protocolo HTTP como protocolo de aplicação. Isso significa que esse protocolo deve ser
utilizado como interface base para realizar toda a interação com os recursos disponíveis e não
apenas para transportar passivamente as mensagens trocadas.
Segundo De França et al. (2011), a realização da visão da WoT requer, portanto, que a Web
atual seja estendida de modo que objetos do mundo real e dispositivos embarcados possam ser
incorporados a ela de forma transparente. Essa extensão é obtida através da utilização do protocolo
HTTP e dos princípios REST na criação de APIs (do inglês, Application Programming Interface),
contudo, como a W3C atesta, existem dois grandes paradigmas de serviços web:
Serviços Web REST também chamados de serviços web RESTful, (Fielding &
Taylor 2002); e
Serviços web arbitrários (comhecidos como WS*), (GROUP 2004).
O objetivo principal dos serviços web RESTful é manipular os recursos da web usando um
conjunto uniforme de operações sem estado. Já nos serviços web arbitrários, são utilizados um
conjunto arbitrário de operações. Ambos os paradigmas podem ser adotados por Smart gateways.
Guinard et al. (2009) descrevem duas maneiras de integrar os objetos na WoT: a primeira é
embarcando um servidor web diretamente no dispositivo que se deseja integrar a web, e a segunda,
para dispositivos com recursos limitados, propões o uso de um intermediador que interprete as
requisições feitas pelos dispositivos. Segundo Zeng, Guo e Cheng (2011), este intermediador entre
os dispositivos e a Web é chamado de Smart Gateway. A Figura 2 ilustra esse cenário, no qual
alguns dispositivos se conectam diretamente à Web e outros que não possuem recursos suficientes
precisam de um intermediador para interpretar suas requisições e enviá-las à Web.
Segundo Guinard et AL (2009), os Smart Gateways tem como objetivo principal abstrair
protocolos de comunicação ou APIs de dispositivos embarcados e disponibilizar suas
funcionalidades por meio de uma API REST.
25
Figura 2. Integração Direta e Indireta na Web das Coisas
Fonte: Wangham, Domenech e Mello (2013).
Além disso, é possível disponibilizar através de middlewares, serviços web que facilitem a
composição de recursos, criando assim aplicações de valor agregado denominadas mashups físicos
(GUINARD et al., 2009).
Guinard (2011) apresenta um modelo de arquitetura para implementação da Web das Coisas
que possui quatro camadas:
Acessibilidade ao dispositivo: Esta camada é onde é implementada a lógica de acesso ao
dispositivo inteligente, tornando este dispositivo visível e disponível ao acesso pela
aplicação. O propósito dessa camada é integrar as “coisas” com o ambiente Web tornando-
as entidades reais neste ambiente, como por exemplo, as páginas Web;
26
Endereçamento: Nesta camada é definido o modelo de implementação para os serviços de
busca e endereçamento para os dispositivos inteligentes. Essa camada define como encontrar
os serviços providos pelos dispositivos e integrá-los dentro das aplicações;
Compartilhamento: Nesta camada são definidas as políticas e como ocorrerá o
compartilhamento dos recursos nos dispositivos inteligentes, considerando aspectos de
segurança, facilidade de utilização, modelos de confiança, interoperabilidade e integração
com aspectos de marketing e propagandas; e
Composição: Aqui é definida a fronteira da WoT para com os desenvolvedores, facilitando
a criação de aplicações Web compostas no topo dos dispositivos inteligentes e possibilitando
um modelo mais flexível e customizável para o desenvolvimento dessas aplicações.
2.4 REST
Segundo Mayer (2010), uma abordagem que está sendo bastante utilizada juntamente com
protocolo HTTP na criação de sistemas distribuídos na Web é o estilo arquitetural REST (do inglês,
REpresentational State Transfer). Esse estilo arquitetural pode ser empregado para desenvolver
sistemas que seguem uma arquitetura orientada a recursos (ROA, do inglês Resource Oriented
Architecture) (MAYER, 2010). O REST define um conjunto de princípios que ao serem adotados
dão origem a sistemas RESTful. Segundo Guinard et al. (2009) os sistemas RESTful são menos
acoplados, mais leves, eficientes e flexíveis do que os sistemas Web baseados em serviços web
arbitrários (WS-*) e podem ser facilmente reutilizados. Os princípios REST podem ser mapeados
nos métodos básicos do protocolo HTTP (GET, POST, PUT e DELETE) para criar sistemas CRUD
(Create, Read, Update, Delete) de uma aplicação RESTful. Os recursos dos sistemas RESTful são
identificados e encapsulados por uma URI.
Segundo Fielding e Taylor (2002) a característica central que distingue o estilo de
arquitetura REST de outros estilos é sua ênfase em uma interface uniforme entre os componentes,
no qual os recursos devem estar disponíveis com uma semântica de interação bem definida, como
por exemplo, o protocolo HTTP. Os métodos das requisições HTTP (GET, PUT, DELETE ou
POST) são utilizados para indicar ao provedor do recurso a ação que deve ser realizada. Assim,
cada método representa uma ação específica sobre o recurso, conforme descrito a seguir:
27
GET: é utilizado para recuperar a representação do recurso;
PUT: é utilizado para atualizar o estado de um recurso existente ou utilizado para
criar um recurso por meio de um identificador fornecido;
DELETE: é utilizado para remover um recurso; e
POST: é utilizado para criar um novo recurso.
Fielding e Taylor (2002) afirmam que para obter uma interface REST uniforme é necessário
seguir quatro regras:
Identificação de recursos: A Web se baseia no mecanismo de URI para identificar
seus recursos e assim links para estes recursos podem ser estabelecidos por meio de
um esquema de identificação conhecido;
Manipulação de recursos por meio de representações: A representação consiste em
dados e metadados que descrevem estes dados. Dependendo dos dados de controle
da mensagem, uma determinada representação pode indicar o estado atual do recurso
solicitado, o estado desejado para o recurso solicitado, ou o valor de algum outro
recurso;
Mensagem auto-descritiva: Todas as informações necessárias para processar uma
solicitação em um recurso estão contidas na própria solicitação permitindo assim que
os serviços não tenham monitoração de estado; e
Hipermídia como o motor do estado do aplicativo: os clientes dos serviços RESTful
são condicionados a utilizar links para encontrar os serviços e interagir com os
recursos providos por estes. Isto permite a um cliente explorar um serviço sem a
necessidade de conhecer o formato do mesmo. Além disso, o cliente pode utilizar
uma padronização de identificadores e processos bem definidos para descoberta de
tipos e mídias oferecidos pelos serviços.
A utilização do protocolo HTTP como protocolo de aplicação admite que os recursos
possuam várias representações e permite que os clientes selecionem, dentre as representações
disponíveis, aquela que for mais adequada às necessidades da aplicação (SANDOVAL, 2009).
28
Segundo Guinard et al. (2009), tais características fazem do estilo REST a melhor opção para
construção de APIs Web para acesso a objetos do mundo real.
De acordo com Dal Moro, Dorneles e Rebonatto (2011), o REST possui a vantagem de que
suas mensagens são transportadas diretamente através do protocolo HTTP, diferente dos serviços
WS-*, que trabalham com envelopes SOAP (Simple Object Access Protocol) envolvidos por
pacotes HTTP. Com isso o desempenho também é afetado, pois os pacotes SOAP devem ser
interpretados antes de os dados serem utilizados. O Quadro 1 apresenta uma comparação entre
serviços WS-* e serviços RESTful.
Quadro 1 Comparação entre serviços WS-* e serviços RESTful.
Fator de Comparação Web services WS-* Web services REST
Tamanho
de Pacote
HTTP
WS lista
produtos por
categoria
584 bytes 399 bytes
WS lista
produtos 1567 bytes 1412 bytes
WS lista
fabricantes 572 bytes 431 bytes
WS lista
categorias 864 bytes 747 bytes
Armazenamento de estados Permite Stateless
Abordagem de design Baseado em operações ou
verbos
Baseado em recursos ou
substantivos (URIs)
Interface Interface não uniforme Interface uniforme – GET,
POST, UPDATE, DELETE.
Code on demand (COD) Não é voltado a COD
Permite que o código originado
da requisição ao servidor seja
executado no lado do cliente.
Representação de dados XML (eXtensible Markup
Language) Aberto
Descritor WSDL (Web Service
Description Language) WSDL/WADL/Nenhum
Fonte: Dal Moro, Dorneles e Rebonatto (2011).
2.4.1 Representação dos Recursos com JSON
JSON (JavaScript Object Notation) é um formato de troca de dados de fácil leitura, escrita e
de fácil análise e geração para máquinas, além disso, JSON é um formato de texto que é
29
completamente independente de idioma e usa convenções que são familiares aos programadores
(JSON, 2014).
JSON está constituído em duas estruturas:
Uma coleção de pares nome e valor. Em várias linguagens, isto é caracterizado como
um object, record, struct, dicionário, hash table, keyed list, ou arrays associativas;e
Uma lista ordenada de valores. Na maioria das linguagens, isto é caracterizado como
uma array, vetor, lista ou sequência.
Estas são estruturas de dados universais. Virtualmente todas as linguagens de programação
modernas as suportam. É aceitável que um formato de troca de dados que seja independente de
linguagem de programação se baseie nestas estruturas (JSON, 2014).
No caso dos dispositivos inteligentes, sugere-se a utilização do JSON uma vez que é um
padrão mais leve se comparado ao XML, principalmente levando em consideração o tamanho das
mensagens e o tempo de validação das mesmas. Nurseitov et al., (2009) afirmam que JSON é mais
rápido e utiliza menos recursos computacionais que XML (eXtensible Markup Language) quando
utilizados para troca de mensagens. Além disto, este padrão é nativamente processado pelo
JavaScript, o que o torna ideal para integração com Web mashups e, consequentemente, para a
criação dos mashups físicos (GUINARD, 2011).
2.5 PLATAFORMA DE HARDWARE ABERTO
Existem diversos hardwares que podem ser utilizados para embarcar serviços web RESTful,
cada qual com suas vantagens. A escolha do hardware que servirá como base para o
desenvolvimento dos serviços deve atender alguns requisitos mínimos como suporte para software
open source, interface de rede e armazenamento interno.
Pesquisa realizada pela The Linux Foundation em conjunto com LinuxGismos.com elenca
as 10 principais plataformas de hardware aberto utilizados no desenvolvimento de aplicações com
hardware embarcado (BROWN, 2014). Estes estão ilustrados na Figura 3. Esta classificação partiu
do total de 32 hardwares e serviu como ponto de partida para a escolha da plataforma de hardware
30
aberto que será utilizado neste trabalho. A pesquisa questionava quais características listadas à
seguir eram levadas em consideração na hora da escolha do hardware a ser adquirido.
Suporte para software open source;
Suporte da comunidade;
Informações do hardware (documentação);
Interface de rede wireless;
Baixo custo;
Interfaces de entrada e saída, tais como USB e serial;
Baixo consumo de energia;
Armazenamento no dispositivo;
Performance gráfica;
Controladores de entrada e saída; e
Modularidade.
Figura 3. Os 10 principais hardwares
Fonte: Bronw (2014)
A pesquisa também apontou o objetivo para o qual o hardware era adquirido. A Figura 4
mostra esta classificação.
31
Figura 4. Principal uso do hardware adquirido
Fonte: Bronw (2014)
O Quadro 2 apresenta um detalhamento técnico sobre os 10 principais hardwares escolhidos
na pesquisa e, apesar de alguns possuírem algumas configurações de hardwares mais performáticas
que outras, todos são capazes de embarcar um servidor Web. Um outro ponto que influencia na
escolha do hardware é o suporte a sistemas open source, característica que está presente em todos os
candidatos.
Um ponto importante não tratado nesta pesquisa é a questão de ser uma plataforma de
hardware aberto. Segundo Stallman (1999), ideia principal de hardware aberto, é que deve ser livre,
no sentido de que esteja livremente disponíveis seus, esquemas, data-sheets e drivers para
especificação do hardware, a fim de permitir a criação e a melhoria do mesmo.
Neste trabalho, escolheu-se o Beagle Bone Black por este ser uma plataforma de hardware
aberto que atende todos os requisitos de projeto da solução proposta e pela disponibilidade na
UNIVALI de kits dessa placa para empréstimo.
32
Quadro 2. Comparação entre os 10 hardwares selecionados
Hardware CPU RAM Armazenamento USB Ethernet Wi-Fi Bluetooth Hardware
aberto
Custo $
Raspberry Pi Model B ARM11 @700 MHz 512 MB Não 2X2.0 10/100 Não Não Não $172.69
Beagle Bone Black ARM Cortex-A8 @1 GHz 512 MB Interno: 2GB Flash 1X2.0 10/100 Não Não Sim $54.95
Odroid-U3 4x ARM Cortex-A9 @1.7
GHz
2 GB Módulo Emmc 3X2.0 10/100 Não Não Sim $65.00
CubieTruck Cortext-A7 Dual-Core 2GB Interno: 8GB Flash
Externo: microSD
2X2.0 10/100/1000 Sim Sim Sim $99.00
Banana Pi 2x ARM Cortex-A7 @1
GHz
1 GB Externo: SD 2x2.0 10/100/1000 Não Não Sim $29.99
Parallella Dual-core ARM A9 1GB Externo: MicroSD 2X2.0 10/100/1000 - - Sim $119.00
Cubieboard2 2x ARM Cortex-A7 @1
GHz
1 GB Interno: 4GB 1X2.0 10/100 Não Não Sim $64.99
A10-OlinuXino-Lime A10 1GHz Cortex-A8 512 MB Interno:4GB Flash
Externo: MicroSD
2x2.0 10/100 - - Sim $40.90
Galileo Intel® Quark X1000 –
single core
256 MB Interno: 8MB Flash
Externo: SD Card
2x2.0 10/100 Não Não Sim $67.00
Udoo Quad 2x, or 4x ARM Cortex-A9
@1 GHz
1GB Não 1X2.0 10/100/1000 Sim Não Sim $135.00
33
3 TRABALHOS RELACIONADOS
Neste capítulo, são descritos alguns trabalhos que possuem objetivos semelhantes aos deste
trabalho. Ao final do capitulo os trabalhos relacionados são comparados considerando
características como, (i) o provimento de uma API REST para disponibilizar acesso aos estados da
máquina monitorada, (ii) a comunicação entre máquinas (M2M - Machine to Machine), (iii) o uso
do ambiente Web, (iv) a possibilidade do controle remoto das máquinas industriais, (v) o uso da
nuvem e (vi) uso de Smart Gateway na resolução de restrições de conectividade.
3.1 IOT@WORK
O IoT@Work é um projeto da União Européia liderado pela Siemens. O projeto tem como
foco o domínio das tecnologias da Internet das Coisas em ambientes industriais e de automação
para desenvolver o conceito de “plug&work”. A ideia deste conceito é tornar os equipamentos
industriais capazes de se configurar de forma automática. O dispositivo é conectado em qualquer
lugar na rede e a rede se encarrega do resto, até que o dispositivo se torne operacional, podendo
cooperar com os outros dispositivos, se adaptar a mudanças como novas demandas e possíveis
falhas (IoT@Work, 2010).
A principal motivação do desenvolvimento do IoT@Work é o histórico das dificuldades que
os projetistas de sistemas de automação industrial sempre enfrentaram durante a configuração da
rede de comunicação e de subsistemas de segurança. Este esforço caro e muitas vezes manual é
fundamental, a fim de evitar falhas que podem levar a interrupções de produção dispendiosas ou
mau funcionamento que podem colocar em risco os seres humanos envolvidos. Dentre as
tecnologias desenvolvidas destacam-se Imtiaz et al. (2013):
O serviço de diretório unificado, que permite aos dispositivos descobrir e acessar outros
dispositivos/serviços da rede por meio de uma API RESTful, viabilizando também seu
monitoramento remoto;
O serviço de notificação de eventos, que é um middleware que atua como um
conector entre geradores e consumidores de eventos, permitindo a troca de
informações eficiente entre os dispositivos;
34
O Processamento de Eventos Complexos, o qual permite o processamento inteligente
de mensagens para suportar o gerenciamento automatizado da planta industrial
(dados monitorados disparam processos automatizados de atuação).
Contudo, apesar de ser focado em ambientes industriais e permitir a comunicação M2M, o
projeto não aborda a publicação de dados dos dispositivos em uma plataforma na Nuvem por meio
de Smart Gateways.
3.2 WEB BASED INTERFACE TO SCADA SYSTEM
A proposta deste trabalho é a utilização da Web como meio de acesso aos dados
disponibilizados por sistemas SCADA (Supervisory Control and Data Acquisition). A motivação
surgiu de um cenário em que usuário trabalhando em diferentes departamentos de uma companhia
elétrica precisa obter os dados de um sistema SCADA. O objetivo é conectar a intranet da empresa
ao sistema SCADA e dar acesso fácil aos usuários em tempo real e aos dados históricos através de
uma única solução por meio de um cliente web (ZECEVIC, 1998).
A Figura 5 ilustra as três camadas que compõe o fluxo da solução proposta. A solução
possibilita que usuários, por meio de um cliente web realizem uma requisição de dados somente do
SCADA. Essa requisição passa pelo ambiente de intranet da empresa e, ao chegar ao servidor de
intranet, essa requisição é processada para capturar os dados solicitados e, processar e criar uma
resposta, a qual é enviada ao cliente contendo os dados do sistema SCADA que foi solicitado, dessa
forma, o sistema permite apenas que sejam capturados dados e não prevê o controle das máquinas
que estão sendo monitoradas.
35
Figura 5. Arquitetura da aplicação em três camadas.
Fonte: Zecevic (1998).
3.3 PROPOSTA DE ARQUITETURA ORIENTADA A RECURSOS PARA
SCADA NA WEB
Este trabalho descreve uma proposta de arquitetura de software para aplicações típicas de
sistemas SCADA, utilizando a Web como plataforma. Segundo Polônia (2011), o objetivo é
mostrar como os requisitos característicos de aplicações SCADA podem ser incorporados em uma
arquitetura condizente com os princípios arquiteturais que fundamentam a Web, dado que as
arquiteturas comumente propostas para SCADA, baseadas em RPC (Remote Procedure Call),
apresentam problemas de forte acoplamento, manutenção de estado e interfaces especializadas, que
dificultam uma integração plena com a Web para tanto, uma arquitetura foi projetada utilizando
como cenário uma CFM (Célula Flexível de Manufatura), ambiente característico de um sistema
SCADA, uma Arquitetura Orientada a Recursos que englobou as funcionalidades geralmente
oferecidas por aplicações SCADA:
Aquisição de dados;
Controle em nível de supervisão;
Configurações;
36
Históricos;
Alarmes; e
IHMs (Interface Homem-Máquina).
Este cenário, utilizando as tecnologias da Web (HTTP, URI e tipos de mídia) de acordo com
seus princípios de arquitetura configura uma solução muito semelhante com a proposta deste
trabalho, porém, apesar de possível, o autor não deixa clara a integração M2M e a solução se
restringe aos sistemas tipo SCADA, não permitindo a comunicação entre máquinas heterogêneas,
além disso, a solução não dispõe de uma integração com a Nuvem, contudo, é importante destacar o
interesse do autor em sua conclusão por um estudo aprofundado sobre Web das Coisas.
3.4 AN INTERNET BASED DITRIBUTED CONTROL SYSTEM: A CASE
STUDY OF OIL REFINERIES
Neste trabalho é proposto um sistema distribuído com base na internet para o controle e
monitoramento em tempo real de plantas industriais. Utilizando a web de cada DSC (Data System
Control), conectando os DSC´s a um servidor WEB central e daí então possibilitando o acesso via
um cliente Applet incorporado à uma página Web com intuito de interpretar os dados vindos do
servidor e atualizar o HMI (Human Machine Interface) correspondente, o qual se encarrega de
atualizar os sensores que sofreram mudanças. Devido à utilização de Applets a proposta não
possibilita a comunicação M2M, além disto, como o intuito é realizar o monitoramento em tempo
real, não há a persistência dos dados para análise posterior. A Figura 6 apresenta uma visão geral
sobre a arquitetura que é proposta para o desenvolvimento desse trabalho.
37
Figura 6. Cliente/ Servidor em três camadas
Fonte: Mahmood e Al-Naima (2011)
3.5 ANÁLISE COMPARATIVA
Os trabalhos relacionados apresentados nesse capítulo possuem características semelhantes à
proposta deste trabalho, as quais são destacadas no Quadro 3.
Quadro 3. Comparativo dos trabalhos relacionados com o trabalho proposto.
Zecevic
(1998)
Polônia
(2011)
Mahmood e
Al-Naima
(2011)
IoT@Work
2013
Este Trababalho
API REST Não Sim Não Sim Sim
M2M Não - Não Sim Sim
Ambiente Web Sim Sim Sim Sim Sim
Controle Remoto Não Sim Sim Sim Sim
Uso de Nuvem Não Não Não Não Sim
Uso de Smart Não Sim Não Não Sim
38
Gateway
Nenhum dos trabalhos relacionados prevê o uso de Nuvem para a persistência dos dados
monitorados e o provimento de aplicações web que possibilitem o controle remoto de dispositivos
em um ambiente industrial.
Deste modo, o diferencial deste trabalho é possuir todas as características, utilizando Smart
Gateway para contornar as restrições de conectividade e realizar a comunicação entre máquinas
heterogêneas, disponibilizando seus estados na Web via API Rest, a qual possui dentre suas
premissas a possibilidade de atualização transparente dos dados, o que viabiliza o controle remoto
dessas máquinas, além disso, o uso da Nuvem como ambiente de persistência possibilita que os
dados sejam analisados posteriormente.
39
4 DESENVOLVIMENTO
Este capítulo detalha as etapas do desenvolvimento deste trabalho. Primeiramente, é
apresentado um levantamento inicial e uma visão geral dos componentes envolvidos, seguida pela
análise de requisitos e pela modelagem do sistema, com os casos de uso e diagramas de sequência
que auxiliaram na concepção da solução. Em seguida, é apresentada uma avaliação do
desenvolvimento que contempla requisitos funcionais, não funcionais e de desempenho. Por fim,
são apresentadas as tecnologias utilizadas no processo de desenvolvimento.
4.1 LEVANTAMENTO INICIAL
Esta etapa do trabalho teve como objetivo entender quais os reais problemas enfrentados
pela equipe de suporte da Empresa X, isto para que fosse possível identificar necessidades e
destacar os requisitos primordiais que o sistema deveria atender, nesta etapa foi obtido o
entendimento do funcionamento da máquina industrial. Para tanto foram realizadas reuniões com a
equipe de engenharia e com a diretoria da empresa além de visitas à fábrica com o intuito de
entender quais as necessidades mais latentes com relação ao monitoramento das máquinas. Como
resultado dessas interações, foi adquirido conhecimento para gerar alguns artefatos essenciais para o
desenvolvimento da solução proposta entre eles estão o (i) diagrama de máquina de estados, (ii)
diagrama de classe, (iii) análise de requisitos e (iv) casos de teste.
4.2 VISÃO GERAL DA SOLUÇÃO PROPOSTA
A Figura 7 apresenta uma visão geral do sistema que envolve o Smart Gateway, uma
máquina industrial e uma aplicação de recebimento de dados que visa persistir os dados em uma
nuvem computacional.
40
Figura 7. Visão geral do uso do Smart Gateway no ambiente industrial
A solução proposta possui dois principais componentes: uma aplicação (chamada Monitor)
que monitora logs de uma máquina industrial e o Smart Gateway, que possui uma API RESTful que
disponibiliza, por meio de serviços web, os recursos da máquina industrial monitorada.
A máquina industrial em questão possui um sistema SCADA (Supervisory Control and Data
Acquisition), o qual atualiza e disponibiliza um arquivo de log com informações dos estados da
máquina (arquivo texto). Deste modo, quando a máquina está executando alguma tarefa, esse
arquivo é constantemente atualizado com informações de timestamp e tipo de operação que a
máquina está realizando. Os logs indicam quando os processos da máquina ocorrem, como por
exemplo, o corte de um tecido. A aplicação Monitor consulta constantemente o arquivo de log que é
atualizado pelo sistema SCADA. Sempre que o Monitor detecta uma alteração no arquivo este
captura a atualização. Por ser um cliente REST do Smart Gateway, sempre que o Monitor captura
estas atualizações do arquivo de log este as mantém em memória e as envia quando estabelece uma
conexão com o Smart Gateway. Portanto, a aplicação Monitor é um meio de enviar as atualizações
dos estados da máquina para o Smart Gateway e foi desenvolvida para adequar o Smart Gateway
proposto ao cenário disponibilizado pela Empresa X. Apesar da aplicação Monitor ter sido
41
desenvolvida para coletar as atualizações do arquivo de log gerado pelo SCADA para o envio ao
Smart Gateway, também é possível que ela colete dados de outra fonte de dados e as envie ao
monitor utilizando o mesmo padrão de mensagens, bastando apenas que a máquina monitorada
disponibilize tal meio.
O Smart Gateway é composto por um servidor web embarcado, o qual possui uma aplicação
dividida basicamente em duas camadas, (i) um camada que representa virtualmente a máquina que
esta sendo monitorada e uma camada que (ii) implementa a arquitetura REST, a camada (i) tem
seus estados sendo constantemente atualizados e a camada (ii) disponibiliza o acesso à recursos que
permitem o acesso a dados desta máquina representada virtualmente, como a camada também (ii)
implementa um cliente REST, este envia os estados desta máquina virtual à um serviço em Nuvem
periodicamente. Os drivers proprietários dão mais flexibilidade à solução, possibilitando por
exemplo que haja comunicação direta com o Smart Gateway através de protocolos como I2C e SPI.
Todos os elementos citados acima foram embarcados em uma plataforma de hardware
aberto, com o principal objetivo de representar virtualmente uma máquina industrial. A aplicação
executada dentro do servidor web mantém os estados da máquina, atualizando-os por meio de
mensagens que são enviadas pela aplicação Monitor. Para disponibilizar estas propriedades, bem
como os estados de sensores e atuadores, de modo que dispositivos e usuários possam acessá-las, o
Smart Gateway provê, através do servidor web, uma API RESTful. Desta forma, qualquer
dispositivo que possua acesso à Internet e autorização poderá consumir os recursos disponibilizados
no formato JSON. Além disto, o Smart Gateway também é um cliente REST, o que permite que o
próprio Smart Gateway, utilizando seu histórico de atualizações, envie-as periodicamente para
outros serviços que estejam configurados, como serviços em Nuvem e outros Smart Gateways.
4.3 ANÁLISE DE REQUISITOS
De modo a apresentar o funcionamento do sistema, as próximas seções mostram,
respectivamente, os requisitos funcionais e não funcionais que delimitam as regras de negócio do
sistema.
42
4.3.1 Análise de Requisitos
A seguir encontram-se listados os requisitos funcionais dos dois principais componentes
abordados neste trabalho: O Smart Gateway e a Aplicação Monitor.
Requisitos funcionais do Smart Gateway
RF01: O sistema deve prover uma API que permita o acesso aos recursos da máquina monitorada;
RF02: O sistema deve prover um serviço web que permita a configuração de serviços externos que
receberão os dados da máquina industrial;
RF03: O sistema deve prover um serviço web que permita o recebimento de atualizações dos
estados da máquina monitorada através das mensagens de log;
RF04: O sistema deve realizar a interpretação de mensagens de log e atualizar os estados e
propriedades que representam sensores e atuadores;
RF05: O sistema deve manter um histórico temporário dos estados da máquina para posterior envio
à Nuvem; e
RF06: O sistema deve enviar periodicamente os estados da máquina para os serviços externos
configurados.
Requisitos Funcionais da Aplicação Monitor
RF01: O sistema deve permitir ao usuário inserir a URL de um Smart Gateway;
RF02: O sistema deve permitir ao usuário alterar a URL do Smart Gateway;
RF03: O sistema deve permitir ao usuário inserir o caminho do arquivo de log da máquina
monitorada;
RF04: O sistema deve permitir ao usuário alterar o caminho do arquivo de log da máquina
monitorada;
RF05: O sistema deve permitir ao usuário iniciar e parar o monitoramento do arquivo de log; e
RF06: O sistema deve enviar as alterações detectadas no arquivo de log para o Smart Gateway.
Requisitos não funcionais do Smart Gateway
RNF01: O sistema deve ser implementado utilizando a linguagem de programação Java 7;
43
RNF02: O sistema deve ser desenvolvido aplicando os conceitos da arquitetura REST;
RNF03: O sistema deve disponibilizar os recursos da máquina no formato JSON e XML;
RNF04: O sistema deve reenviar as atualizações para os serviços externos configurados em caso de
falha de comunicação; e
RNF05: O sistema deve ser desenvolvido sobre a plataforma Oracle Java SE Embedded.
Requisitos não funcionais da Aplicação Monitor
RNF01: O sistema deve utilizar soluções de tecnologias e plataformas para desenvolvimento open
source; e
RNF02: O sistema deve reenviar as atualizações do arquivo de log em caso de falha na
comunicação com o Smart Gateway.
4.4 MODELAGEM DO SISTEMA
Nesta seção são apresentadas as informações referentes à modelagem do sistema, bem como
os casos de uso e os diagramas de sequência, os diagramas de classe bem como uma descrição das
principais classes encontram-se no Apêndice A. A Figura 8 apresenta o diagrama de casos de uso da
aplicação Monitor.
44
Figura 8. Diagrama de Casos de Uso da aplicação Monitor
Nos quadros a seguir são apresentados os casos de uso expandidos. Nesta expansão
encontram-se detalhadas as seguintes informações: descrição, atores, pré e pós-condições, fluxos
principal e alternativos e exceções.
Quadro 4. Detalhamento do Caso de Uso UC01. Inserir URL do Smart Gateway
Nome do caso de uso UC01. Inserir URL do Smart Gateway
Descrição O Usuário pode inserir o endereço URL do Smart Gateway que
receberá as atualizações detectadas pela aplicação Monitor.
Atores Usuário
Pré-condições Aplicação Monitor iniciada
Fluxo principal 1. O usuário clica com o botão direito no ícone da aplicação
Monitor;
2. O sistema apresenta um menu;
3. O usuário clica na opção “Configurar Smart Gateway”;
4. O sistema apresenta um campo de entrada;
5. O usuário adiciona a URL do Smart Gateway e clica no botão
“Salvar”.
Fluxo alternativo e exceções 1. Caso o usuário insira uma URL inválida sistema apresenta uma
mensagem de “URL Inválida”.
Pós-condições N/A
45
Quadro 5. Detalhamento do Caso de Uso UC02. Alterar URL do Smart Gateway
Nome do caso de uso UC02. Alterar URL do Smart Gateway
Descrição O Usuário pode alterar a URL do Smart Gateway que receberá as
atualizações detectadas pela aplicação Monitor.
Atores Usuário
Pré-condições UC01. Inserir URL do Smart Gateway
Fluxo principal 1. O usuário clica com o botão direito no ícone da aplicação Monitor;
2. O sistema apresenta um menu;
3. O usuário clica na opção “Configurar Smart Gateway”;
4. O sistema apresenta um campo de entrada com a URL atual;
5. O usuário altera a URL do Smart Gateway e clica no botão
“Salvar”.
Fluxo alternativo e exceções 1. Caso o usuário insira uma URL inválida, o sistema apresenta uma
mensagem de “URL Inválida”.
Pós-condições N/A
Quadro 6. Detalhamento do Caso de Uso UC03. Selecionar arquivo de log monitorado.
Nome do caso de uso UC03. Selecionar arquivo de log monitorado
Descrição O Usuário pode selecionar o arquivo de log do sistema SCADA que é
atualizado com as informações da máquina.
Atores Usuário
Pré-condições Aplicação Monitor iniciada
Fluxo principal 1. O usuário clica com o botão direito no ícone da aplicação Monitor;
2. O sistema apresenta um menu;
3. O usuário clica na opção “Escolher Arquivo de Log”;
4. O sistema apresenta uma tela para o usuário escolher o arquivo;
5. O usuário seleciona o arquivo de log e clica em “Abrir”.
Fluxo alternativo e exceções 1. Caso o usuário insira um arquivo inválido o sistema apresenta uma
mensagem de “Arquivo Inválido”.
Pós-condições N/A
Quadro 7. Detalhamento do Caso de Uso UC04. Alterar o arquivo de log monitorado.
Nome do caso de uso UC04. Alterar o arquivo de log monitorado.
Descrição O Usuário pode alterar o arquivo de log do sistema SCADA que é
atualizado com as informações da máquina.
Atores Usuário
Pré-condições UC03. Selecionar arquivo de log monitorado
Fluxo principal 1. O usuário clica com o botão direito no ícone da aplicação Monitor;
2. O sistema apresenta um menu;
3. O usuário clica na opção “Escolher Arquivo de Log”;
4. O sistema apresenta uma tela para o usuário escolher o arquivo;
5. O usuário seleciona o arquivo de log e clica em “Abrir”.
Fluxo alternativo e exceções 1. Caso o usuário insira um arquivo inválido, o sistema apresenta uma
mensagem de “Arquivo Inválido”.
Pós-condições N/A
46
Quadro 8. Detalhamento do Caso de Uso UC05. Iniciar monitoramento.
Nome do caso de uso UC05. Iniciar monitoramento
Descrição O Usuário iniciar o monitoramento do arquivo de log.
Atores Usuário
Pré-condições UC03. Selecionar arquivo de log monitorado e UC01. Inserir URL do
Smart Gateway
Fluxo principal 1. O usuário clica com o botão direito no ícone da aplicação Monitor;
2. O sistema apresenta um menu;
3. O usuário clica na opção “Iniciar Monitoramento”.
Fluxo alternativo e exceções 1. Caso a aplicação Monitor não consiga realizar leitura do arquivo de
log uma mensagem informando o problema na leitura do arquivo de
log será apresentada.
Pós-condições UC06. Parar monitoramento
Quadro 9. Detalhamento do Caso de Uso UC06. Parar monitoramento.
Nome do caso de uso UC06. Parar monitoramento
Descrição O Usuário pode parar o monitoramento do arquivo de log.
Atores Usuário
Pré-condições UC05. Iniciar monitoramento.
Fluxo principal 1. O usuário clica com o botão direito no ícone da aplicação Monitor;
2. O sistema apresenta um menu;
3. O usuário clica na opção “Parar Monitoramento”.
Fluxo alternativo e exceções N/A
Pós-condições N/A
4.4.1 Diagramas de Sequência
A Figura 9 apresenta o diagrama de sequência da aplicação Monitor.
47
Figura 9. Ciclo de vida da aplicação Monitor
A Figura 10 apresenta o diagrama de sequência da integração entre a aplicação Monitor, o
Smart Gateway e serviços externos.
Figura 10. Integração Monitor, Smart Gateway e Serviços Externos
48
A Figura 11 apresenta o diagrama de sequência que representa os recursos que são
disponibilizados pelo Smart Gateway através da API REST.
Figura 11. API REST do Smart Gateway.
4.4.2 WADL do Smart Gateway
O Quadro 10 apresenta os recursos disponibilizados pelo Smart Gateway, os quais podem
ser visualizados por meio de um documento WADL (Web Application Description Language)
gerado após a inicialização da aplicação no servidor web. O WADL é responsável por apresentar os
recursos disponíveis no Smart Gateway, facilitando o consumo desses recursos por outras
aplicações.
49
Quadro 10. WADL do Smart Gateway recuperado pelo navegador.
4.5 TECNOLOGIAS UTILIZADAS
As subseções a seguir descrevem as principais tecnologias e frameworks que foram
utilizados no desenvolvimento deste trabalho.
50
4.5.1 Beagle Bone Black
Beagle Bone Black é uma plataforma de hardware aberto de baixo custo que possui uma
vasta comunidade de desenvolvedores e entusiastas, dentre os seus recursos podemos destacar o
processador AM335x ARM Cortex de 1GHz, memória 512MB, conectividade via Ethernet e USB
(BEAGLEBOARD,2014). Neste trabalho o Beagle Bone Black é componente obrigatório servindo
como base para o desenvolvimento da aplicação que junto com ele formam o Smart Gateway, a
Figura 12 é uma imagem do Beagle Bone Back.
Figura 12. Beagle Bone Black
Fonte: (BEAGLEBOARD,2014)
4.5.2 Oracle Java Standard Edition Embedded
Java SE Embedded é um framework disponibilizado pela Oracle que possui todo o ambiente
necessário para criação e execução de aplicações Java como a JVM (Java Virtual Machine) e o
Compilador Java.
Para o desenvolvimento do Smart Gateway foi necessário utilizar uma versão do Java
Standard Edition Embedded específica para a arquitetura ARM (Advanced RISC Machine), isto
51
devido a escolha da plataforma de hardware aberto Beagle Bone Black que possui uma arquitetura
ARM.
4.5.3 Jersey Framework
Jersey é um framework open source, considerado uma implementação de referência da
especificação JAX-RS (JSR 311 e JSR 339) e é composto por utilitários e recursos que possuem o
intuito de facilitar o desenvolvimento de aplicações tipo RESTFul (JERSEY,2014). Neste trabalho
o Jersey serve como um facilitador para o desenvolvimento da camada da API RESTful tanto como
servidor quanto como cliente.
4.6 AVALIAÇÃO E RESULTADOS
Para avaliar a solução desenvolvida neste trabalho, experimentos foram realizados com logs
de processos reais das próprias máquinas industriais de forma a avaliar a aplicabilidade da solução
proposta. Os experimentos quantificaram os impactos no uso de recursos computacionais na
plataforma de hardware aberto e se basearam nas métricas de: (i) consumo de memória, (ii)
consumo de CPU e (iii) espaço de armazenamento utilizado. Testes funcionais e não funcionais
foram realizados visando à validação e verificação do software desenvolvido.
4.6.1 Casos de Teste
A seguir são apresentados os casos de teste de software e os resultados de sua execução no
Smart Gateway. Para cada caso de teste foi preparado um arquivo “A” contendo a sequência de
mensagens exigidas pelo caso de teste em questão, e um outro arquivo “B” vazio, onde as
mensagens do arquivo “A” são copiadas uma a uma até que não haja mais mensagens a serem
copiadas. Feito isto, é inicializada a aplicação Monitor que “escuta” o arquivo “B” e percebe
quando uma nova mensagem é escrita. Para cada mensagem nova copiada para o arquivo “B” a
aplicação Monitor a envia para o Smart Gateway onde é possível verificar se o estado atribuído é o
estado esperado pelo caso de teste por meio do recurso do Smart Gateway “/state” e se o atributo
que a mensagem se refere recebeu o valor correspondente. Ao final das transferências entre
arquivos, o recurso “/history” é invocado para verificar se todas as transições entre os estados foram
as esperadas, vale ressaltar que por se tratarem de logs de processos reais, o estado “Ocioso”
aparece entre transições de estados as quais tiveram diferença entre as transições maiores que 1ms.
52
O Quadro 11 apresenta o detalhamento do caso de teste CT01.
Quadro 11: Detalhamentos do caso de teste CT 01
Tipo de teste Funcionalidade
Descrição Testar se o fluxo de troca de estados é executado corretamente.
Pré-condições O sistema estar devidamente instalado, com um arquivo de log vazio.
Entrada de dados 1. A seguinte sequência de mensagens deve ser inserida no log: 2013-10-09 19:24:42:833;Aplicação iniciada;
2013-10-09 19:24:42:833;Versão 2.1.33;
2013-10-09 19:24:47:544;Iniciada remissão a zero;
2013-10-09 19:25:03:008;Terminada remissão a zero;
2013-10-09 19:25:52:534;Documento
aberto;C:\Corte\150x150.txt;150;150;
2013-10-09 19:25:52:877;Propriedade alterada;Vibração
da faca;Anterior:0;Novo:8;
Resultados esperados - O sistema deve finalizar a execução do arquivo com sucesso.
- Ao finalizar, deve estar no estado OCIOSO. A sequência de troca de
estados realizada deve ser a seguinte:
- Estado Inicial
- Iniciada Remissão a Zero
- Terminada Remissão a Zero
- Ocioso
- Propriedade Alterada
- Ocioso
Resultados do teste: Para cada transferência de mensagem foram verificados que os atributos de
estado e a propriedade referenciada receberam os valores esperados. O Quadro 12 apresenta o
retorno do recurso “/history” executado ao final das transferências das mensagens.
Quadro 12: Retorno do recurso "/history" para o CT01
Ordem de processamento
(Timestamp)
Estado
1412129578964 ESTADO_INICIAL
1412129578964 OCIOSO
1412129581650 OCIOSO
1412129582646 INICIADA_REMISSAO_A_ZERO
1412129583646 TERMINADA_REMISSAO_A_ZERO
1412129583646 OCIOSO
1412129584647 OCIOSO
1412129585647 PROPRIEDADE_ALTERADA
53
1412129585647 OCIOSO
O Quadro 13 apresenta o detalhamento do caso de teste CT02.
Quadro 12: Detalhamentos do caso de teste CT 02
Tipo de teste Funcionalidade
Descrição Testar se a aplicação consegue passar de um estado final para um estado
inicial.
Pré-condições O sistema estar devidamente instalado, com um arquivo de log qualquer.
Entrada de dados 1. A aplicação deve processar um arquivo de log qualquer, que
termine com as seguintes mensagens (deve-se estar atento ao
horário das mensagens): 2013-10-09 19:23:33:849;Aplicação finalizada com
sucesso;
2013-10-09 19:25:43:057;Aplicação iniciada;
2013-10-09 19:25:43:073;Versão 2.1.33;
2013-10-09 19:26:02:994;Iniciada remissão a zero;
2013-10-09 19:26:21:938;Terminada remissão a zero;
Resultados esperados - O sistema deve fazer a transição para o ESTADO FINAL;
- Após ler a mensagem Aplicação iniciada a aplicação deve fazer
uma transição para o ESTADO INICIAL e em seguida para o estado
OCIOSO;
- A aplicação deve interpretar as demais mensagens e fazer as transições
de estado necessárias, terminando a execução no estado OCIOSO.
Resultados do teste: Para cada transferência de mensagem foram verificados que os atributos de
estado e a propriedade referenciada receberam os valores esperados. O Quadro 14 apresenta o
retorno do recurso “/history” executado ao final das transferências das mensagens e apresenta a
troca do estado final para o estado inicial.
Quadro 13: Retorno do recurso "/history" para o CT02
Ordem de processamento (Timestamp) Estado
1412130086606 ESTADO_FINAL
1412130089282 ESTADO_INICIAL
1412130089282 OCIOSO
1412130090280 OCIOSO
1412130093280 INICIADA_REMISSAO_A_ZERO
1412130095279 TERMINADA_REMISSAO_A_ZERO
54
1412130095279 OCIOSO
O Quadro 15 apresenta o detalhamento do caso de teste CT03.
Quadro 14: Detalhamentos do caso de teste CT 03
Tipo de teste Funcionalidade
Descrição Testar se a aplicação consegue executar corretamente a Sequência de Log 01.
Pré-condições O sistema estar devidamente instalado e ter um arquivo .txt que contenha
apenas a Sequência de Log 01.
Entrada de dados 1. A aplicação deve processar um arquivo de log que contenha a Sequência
de Log 01.
Resultados
esperados - Ao processar a mensagem 2013-10-09 19:15:28:171;Propriedade
alterada;Vibração da faca;Anterior:0;Novo:9; a aplicação deve voltar
ao estado de MANUTENÇÃO;
- Ao processar a mensagem 2013-10-09 19:15:38:121;Caibração da
faca/laser/furador iniciada; a aplicação deve assumir que o estado
anterior ao de CALIBRAÇÃO DE FACA/LASER/FURADOR é o estado de
MANUTENÇÃO, mesmo que uma mensagem do tipo Aberta área de
manutenção não tenha sido inserida no log;
- Ao processar a mensagem 2013-10-09 19:16:00:120;Caibração da faca/laser/furador
confirmada;KnifeToDrillDistance;Point2D[14,26, -
0,0600000000000023];KnifeToLaserDistance;Point2D[6,85, 10,15]; a
aplicação deve voltar ao estado MANUTENÇÃO;
- Ao processar a mensagem 2013-10-09 19:18:28:321;Caibração da faca/laser/furador confirmada;KnifeToDrillDistance;Point2D[14,3,
-0,0199999999999818];KnifeToLaserDistance;Point2D[6,85, 10,18];
a aplicação deve ir para o estado de MANUTENÇÃO;
- Ao processar a mensagem 2013-10-09 19:19:32:982;Aplicação
iniciada; a aplicação deve ir para o estado OCIOSO, assumindo que houve
algum erro que fez com que a aplicação não fosse finalizada corretamente.
Resultado dos testes: O teste foi executado com sucesso, as transições convergiram para o estado
esperado no caso de teste e o arquivo foi processado até o final com sucesso. O Quadro 16
apresenta o retorno do recurso “/history” executado ao final das transferências das mensagens.
Quadro 15: Retorno do recurso "/history" para o CT03
Ordem de processamento
(Timestamp)
Estado
1412130402566 ESTADO_INICIAL
1412130402567 OCIOSO
1412130409247 OCIOSO
55
1412130414243 INICIADA_REMISSAO_A_ZERO
1412130418246 TERMINADA_REMISSAO_A_ZERO
1412130418246 OCIOSO
1412130419243 MANUTENCAO
1412130427245 PROPRIEDADE_ALTERADA
1412130427245 OCIOSO
1412130430245 MANUTENCAO
1412130430245 OCIOSO
1412130433242 MANUTENCAO
1412130438244 PROPRIEDADE_ALTERADA
1412130438244 OCIOSO
1412130440243 MANUTENCAO
1412130442240 MANUTENCAO
1412130442240 OCIOSO
1412130444242 MANUTENCAO
1412130447243 MANUTENCAO
1412130449244 MANUTENCAO
1412130451245 ESTADO_INICIAL
1412130451245 OCIOSO
1412130454244 ESTADO_FINAL
O Quadro 17 apresenta o detalhamento do caso de teste CT04.
Quadro 16: Detalhamentos do caso de teste CT 04
Tipo de teste Funcionalidade
Descrição Testar se a aplicação consegue executar corretamente a Sequência de Log
02.
Pré-condições O sistema estar devidamente instalado e ter um arquivo .txt que contenha
apenas a Sequência de Log 02.
Entrada de dados 1. A aplicação deve processar um arquivo de log que contenha a
Sequência de Log 02.
56
Resultados esperados - Após processar a mensagem 2013-10-09 19:34:40:300;Terminada
espera pelo nível correto de vacuo; a aplicação deve ir para o
estado OCIOSO, em função do tempo que leva para que outra mensagem
apareça;
- Após processar a mensagem 2013-10-09 19:34:57:913;Terminado
corte da última peça; a aplicação deve ir para o estado OCIOSO;
- Após processar a mensagem 2013-10-09 19:35:14:371;Tecido
alterado;CutParams.InitialKnifeVibrationSpeed;7; a aplicação
deve ir para o estado OCIOSO;
- Após processar a mensagem 2013-10-09 19:35:19:144;Tecido
alterado;CutParams.InitialKnifeVibrationSpeed;8; a aplicação
deve ir para o estado OCIOSO;
- Após processar a mensagem 2013-10-09 19:35:35:384;Terminada
espera pelo nível correto de vacuo; a aplicação não deve ir para o
estado OCIOSO, mas sim para o estado MOVIMENTAÇÃO DA
ESTEIRA, pois a mensagem seguinte é 2013-10-09 19:35:35:384;Começou a mover a esteira;
- Após processar a mensagem 2013-10-09 19:35:53:449;Terminou de
mover esteira; a aplicação deve ir para o estado OCIOSO;
- Não deve haver transição ao processar a mensagem 2013-10-09 19:35:53:449;Corte terminado;
Resultado dos testes: O teste foi executado com sucesso, as transições convergiram para o estado
esperado no caso de teste e o arquivo foi processado até o final com sucesso. O Quadro 18
apresenta o retorno do recurso “/history” executado ao final das transferências das mensagens.
Quadro 17: Retorno do recurso "/history" para o CT04
Ordem de
processamento
(Timestamp)
Estado
1412130869018 ESTADO_INICIAL
1412130869018 OCIOSO
1412130870660 OCIOSO
1412130874658 INICIADA_REMISSAO_A_ZERO
1412130884659 TERMINADA_REMISSAO_A_ZERO
1412130884659 OCIOSO
1412130891659 OCIOSO
1412130900660 PROPRIEDADE_ALTERADA
1412130900660 OCIOSO
1412130906660 SETANDO_VALOR_INICIAL
57
1412130907656 SETANDO_VALOR_INICIAL
1412130909658 SETANDO_VALOR_INICIAL
1412130911658 SETANDO_VALOR_INICIAL
1412130913658 SETANDO_VALOR_INICIAL
1412130915658 SETANDO_VALOR_INICIAL
1412130916658 SETANDO_VALOR_INICIAL
1412130918658 SETANDO_VALOR_INICIAL
1412130921657 SETANDO_VALOR_INICIAL
1412130923660 SETANDO_VALOR_INICIAL
1412130925657 SETANDO_VALOR_INICIAL
1412130927658 SETANDO_VALOR_INICIAL
1412130929658 SETANDO_VALOR_INICIAL
1412130931657 SETANDO_VALOR_INICIAL
1412130933658 SETANDO_VALOR_INICIAL
1412130936658 SETANDO_VALOR_INICIAL
1412130938657 SETANDO_VALOR_INICIAL
1412130941657 SETANDO_VALOR_INICIAL
1412130943657 ESPERA_PELO_NIVEL_CORRETO_DE_VACUO
1412130947657 ESPERA_PELO_NIVEL_CORRETO_DE_VACUO_TERMINADO
1412130947657 OCIOSO
1412130950657 CORTE
1412130953657 CORTE_DE_PAGINA
1412130954657 ESPERA_PELO_NIVEL_CORRETO_DE_VACUO
1412130956657 ESPERA_PELO_NIVEL_CORRETO_DE_VACUO_TERMINADO
1412130956657 OCIOSO
1412130957657 CORTANDO_PECA
1412130961657 CORTANDO_PECA
1412130962657 TERMINADO_C0RTE_PAGINA
1412130963657 OCIOSO
1412130964657 PROPRIEDADE_ALTERADA
1412130964657 OCIOSO
1412130969658 OCIOSO
1412130971658 PROPRIEDADE_ALTERADA
58
1412130971658 OCIOSO
1412130973658 OCIOSO
1412130975657 ESPERA_PELO_NIVEL_CORRETO_DE_VACUO
1412130976656 ESPERA_PELO_NIVEL_CORRETO_DE_VACUO_TERMINADO
1412130976656 OCIOSO
1412130978664 MOVIMENTACAO_ESTEIRA
1412130980657 OCIOSO
1412130982657 OCIOSO
1412130987656 OCIOSO
1412130989657 ESTADO_FINAL
O Quadro 1819 apresenta o detalhamento do caso de teste CT05.
Quadro 18: Detalhamentos do caso de teste CT 05
Tipo de
teste
Funcionalidade
Descrição Testar se a aplicação consegue executar corretamente a Sequência de Log 03.
Pré-
condições
O sistema estar devidamente instalado e ter um arquivo .txt que contenha apenas a
Sequência de Log 03.
Entrada de
dados
1. A aplicação deve processar um arquivo de log que contenha a Sequência de
Log 03.
59
Resultados
esperados - Ao processar a mensagem 2013-08-28 05:05:24:095;Iniciada remissão a
zero; a aplicação deve passar do estado de ERRO para o estado OCIOSO e então
para o estado REALIZANDO REMISSÃO A ZERO;
- Ao processar as mensagens 2013-08-28 05:07:19:092;Esteira movida fora de hora: 0,01 -> 3,99;
2013-08-28 05:07:19:812;Esteira movida fora de hora: 3,99 -> 11,38;
2013-08-28 05:07:20:562;Esteira movida fora de hora: 11,38 -> 18,65;
a aplicação deve ir, em cada uma, do estado OCIOSO para MOVIMENTAÇÃO DA
ESTEIRA FORA DE HORA e, de novo, para OCIOSO;
- Após processar cada uma das mensagens 2013-08-28 05:21:36:205;Propriedade alterada;Percentual da
velocidade de corte;Anterior:100;Novo:30;
2013-08-28 05:21:40:065;Propriedade alterada;Percentual da
velocidade de corte;Anterior:30;Novo:100; a aplicação deve voltar para o estado SIMULAÇÃO DE CORTE;
- Após processar a mensagem 2013-08-28 05:22:35:945;Terminada espera
pelo nível correto de vacuo; a aplicação deve ir para o estado OCIOSO;
- Após processar a mensagem 2013-08-28 05:24:57:898;Tecido
alterado;CutParams.OvercutInPatternOutsideCornersStart;0,21; a
aplicação deve voltar para o estado CORTE:CORTE DE PÁGINA:CORTANDO;
- O processamento da mensagem 2013-08-28 05:24:57:901;Tecido alterado;CutParams.SpeedReductionParameters;org.pescuma.ModelSharp.L
ib.ObservableList`1[9A298ADC94864A675075DE0B98171310.1E8C36AAC69CBB8
FAB7E3FD23F3B9679]; não deve gerar transição de estado;
- Ao processar cada uma das mensagens 2013-08-28 05:33:49:148;Esteira movida fora de hora: 518,44 ->
521,3;
2013-08-28 05:33:49:978;Esteira movida fora de hora: 521,3 ->
529,56; a aplicação deve ir do estado OCIOSO para o estado MOVIMENTAÇÃO DA
ESTEIRA FORA DE HORA e, em seguida, voltar para o estado OCIOSO.
Resultado dos testes: O teste foi executado com sucesso, as transições convergiram para o estado
esperado no caso de teste e o arquivo foi processado até o final com sucesso, no apêndice B
encontra-se o retorno do recurso “/history” executado ao final das transferências das mensagens. O
Quadro 19 apresenta o detalhamento do caso de teste CT06.
Quadro 19: Detalhamentos do caso de teste CT 06
Tipo de teste Funcionalidade
Descrição Testar se a aplicação consegue executar corretamente a Sequência de
Log 04.
Pré-condições O sistema estar devidamente instalado e ter um arquivo .txt que contenha
apenas a Sequência de Log 04.
Entrada de dados 1. A aplicação deve processar um arquivo de log que contenha a
Sequência de Log 04.
60
Resultados esperados - Ao processar a mensagem 2013-08-28 06:57:22:063;Esteira
movida fora de hora: 931,7 -> 931,8; a aplicação deve ir para o
estado MOVIMENTAÇÃO DA ESTEIRA FORA DE HORA e, logo em
seguida, voltar para o estado CORTE:CORTANDO PEÇA;
- O último estado do teste deve ser CORTE:CORTE DE
PÁGINA:CORTANDO.
Resultado dos testes: O teste foi executado com sucesso, as transições convergiram para o estado
esperado no caso de teste e o arquivo foi processado até o final com sucesso. O Quadro 20
apresenta o retorno do recurso “/history” executado ao final das transferências das mensagens.
Quadro 20: Retorno do recurso "/history" para o CT06
Ordem de
processamento
(Timestamp)
Estado
1412131941483 ESTADO_INICIAL
1412131941483 OCIOSO
1412131943131 OCIOSO
1412131947128 OCIOSO
1412131950130 SETANDO_VALOR_INICIAL
1412131956130 SETANDO_VALOR_INICIAL
1412131959130 SETANDO_VALOR_INICIAL
1412131971130 SETANDO_VALOR_INICIAL
1412131974130 SETANDO_VALOR_INICIAL
1412131979128 CORTE
1412131984127 CORTE_DE_PAGINA
1412131986129 ESPERA_PELO_NIVEL_CORRETO_DE_VACUO
1412131988128 ESPERA_PELO_NIVEL_CORRETO_DE_VACUO_TERMINADO
1412131988128 OCIOSO
1412131991128 CORTANDO_PECA
1412131993129 MOVIMENTACAO_ESTEIRA_FORA_DE_HORA
1412131993129 OCIOSO
1412131995128 CORTANDO_PECA
1412131997130 CORTANDO_PECA
1412132002125 CORTE_DE_PAGINA
61
O Quadro 21 apresenta o detalhamento do caso de teste CT07.
Quadro 21: Detalhamentos do caso de teste CT 07
Tipo de teste Funcionalidade
Descrição Testar se a aplicação consegue executar corretamente a Sequência de Log
05.
Pré-condições O sistema estar devidamente instalado e ter um arquivo .txt que contenha
apenas a Sequência de Log 05.
Entrada de dados 1. A aplicação deve processar um arquivo de log que contenha a
Sequência de Log 05.
Resultados esperados - Ao processar as mensagens 2013-08-15 09:18:23:948;Propriedade alterada;Vibração da faca;Anterior:2;Novo:3;
2013-08-15 09:18:23:948;Tecido
alterado;CutParams.InitialKnifeVibrationSpeed;3; a aplicação
deve ir para o estado PROPRIEDADE ALTERADA, em seguida para
TECIDO ALTERADO e, em seguida, voltar para CORTE:CORTANDO
PEÇA. O mesmo deve ocorrer ao processar os pares de mensagens 2013-08-15 09:18:24:869;Propriedade alterada;Vibração da
faca;Anterior:3;Novo:5;
2013-08-15 09:18:24:869;Tecido
alterado;CutParams.InitialKnifeVibrationSpeed;5; e 2013-08-15 09:18:25:789;Propriedade alterada;Vibração da
faca;Anterior:5;Novo:7;
2013-08-15 09:18:25:789;Tecido
alterado;CutParams.InitialKnifeVibrationSpeed;7;
e 2013-08-15 09:18:26:709;Propriedade alterada;Vibração da
faca;Anterior:7;Novo:8;
2013-08-15 09:18:26:709;Tecido
alterado;CutParams.InitialKnifeVibrationSpeed;8;
Resultado dos testes: O teste foi executado com sucesso, as transições convergiram para o estado
esperado no caso de teste e o arquivo foi processado até o final com sucesso. O Quadro 22
apresenta o retorno do recurso “/history” executado ao final das transferências das mensagens.
Quadro 22: Retorno do recurso "/history" para o CT07
Ordem de
processamento
(Timestamp)
Estado
1412132270777 ESTADO_INICIAL
1412132270777 OCIOSO
1412132272437 OCIOSO
1412132275434 INICIADA_REMISSAO_A_ZERO
62
1412132277434 TERMINADA_REMISSAO_A_ZERO
1412132277434 OCIOSO
1412132279434 OCIOSO
1412132284433 SETANDO_VALOR_INICIAL
1412132286433 SETANDO_VALOR_INICIAL
1412132295435 SETANDO_VALOR_INICIAL
1412132299436 SETANDO_VALOR_INICIAL
1412132300434 PROPRIEDADE_ALTERADA
1412132300434 OCIOSO
1412132301433 OCIOSO
1412132303433 OCIOSO
1412132304432 PROPRIEDADE_ALTERADA
1412132304432 OCIOSO
1412132305434 OCIOSO
1412132306433 CORTE
1412132312433 CORTE_DE_PAGINA
1412132314434 ESPERA_PELO_NIVEL_CORRETO_DE_VACUO
1412132315433 ESPERA_PELO_NIVEL_CORRETO_DE_VACUO_TERMINADO
1412132315433 OCIOSO
1412132318433 CORTANDO_PECA
1412132319432 PROPRIEDADE_ALTERADA
1412132319432 TECIDO_ALTERADO
1412132319433 CORTANDO_PECA
1412132321434 PROPRIEDADE_ALTERADA
1412132321434 TECIDO_ALTERADO
1412132322434 CORTANDO_PECA
1412132323433 PROPRIEDADE_ALTERADA
1412132323433 TECIDO_ALTERADO
1412132324433 CORTANDO_PECA
1412132325434 PROPRIEDADE_ALTERADA
1412132325434 TECIDO_ALTERADO
1412132327433 CORTANDO_PECA
63
O Quadro 23 apresenta o detalhamento do caso de teste CT08.
Quadro 23: Detalhamentos do caso de teste CT 08
Tipo de teste Funcionalidade
Descrição Testar se a aplicação consegue executar corretamente a Sequência de
Log 06.
Pré-condições O sistema estar devidamente instalado e ter um arquivo .txt que
contenha, inserido junto com alguma outra sequência de log, a Sequência
de Log 06.
Entrada de dados 1. A aplicação deve processar um arquivo de log que contenha
mensagens de log em que a Sequência de Log 06 está presente.
Resultados esperados - Ao processar a mensagem 2013-08-15 10:26:08:526;Esteira
movida fora de hora: 1378,78 -> 1378,89; a aplicação deve sair
do estado OCIOSO e ir para o estado MOVIMENTAÇÃO DE
ESTEIRA FORA DE HORA. Logo após, deve voltar ao estado
OCIOSO.
Resultado dos testes: O teste foi executado com sucesso, as transições convergiram para o estado
esperado no caso de teste e o arquivo foi processado até o final com sucesso. O Quadro 24
apresenta o retorno do recurso “/history” executado ao final das transferências das mensagens.
Quadro 24: Retorno do recurso "/history" para o CT08
Ordem de
processamento
(Timestamp)
Estado
1412132604867 CORTE_DE_PAGINA
1412132606489 ESPERA_PELO_NIVEL_CORRETO_DE_VACUO
1412132621487 ESPERA_PELO_NIVEL_CORRETO_DE_VACUO_TERMINADO
1412132621487 OCIOSO
1412132623490 MOVIMENTACAO_ESTEIRA_FORA_DE_HORA
1412132623490 OCIOSO
1412132625485 CORTANDO_PECA
64
O Quadro 25 apresenta o detalhamento do caso de teste CT09.
Quadro 25: Detalhamentos do caso de teste CT 09
Tipo de teste Funcionalidade
Descrição Testar se a aplicação consegue executar corretamente a
Sequência de Log 07.
Pré-condições O sistema estar devidamente instalado e ter um arquivo .txt que
contenha, inserido junto com alguma outra sequência de log, a
Sequência de Log 07.
Entrada de dados 1. A aplicação deve processar um arquivo de log que
contenha mensagens de log em que a Sequência de Log
07 está presente.
Resultados esperados - Ao processar a mensagem 2013-08-15
11:05:22:759;Fechada área de manutenção; a aplicação
deve sair do estado ERRO e ir para o estado MANUTENÇÃO,
indo em seguida para o estado OCIOSO.
Resultado dos testes: O teste foi executado com sucesso, as transições convergiram para o estado
esperado no caso de teste e o arquivo foi processado até o final com sucesso. O Quadro 26
apresenta o retorno do recurso “/history” executado ao final das transferências das mensagens.
Quadro 26: Retorno do recurso "/history" para o CT09
Ordem de processamento
(Timestamp)
Estado
1412132744630 MANUTENCAO
1412132746291 ERRO
1412132749288 ERRO
1412132750287 MANUTENCAO
1412132750287 OCIOSO
O Quadro 27 apresenta o detalhamento do caso de teste CT10.
Quadro 27: Detalhamentos do caso de teste CT 10
Tipo de teste Funcionalidade
Descrição Testar se a aplicação consegue executar corretamente a Sequência de Log
08.
Pré-condições O sistema estar devidamente instalado e ter um arquivo .txt que contenha,
inserido junto com alguma outra sequência de log, a Sequência de Log 08.
Entrada de dados 1. A aplicação deve processar um arquivo de log que contenha
mensagens de log em que a Sequência de Log 08 está presente.
65
Resultados esperados - Ao processar a mensagem 2013-08-15 13:21:26:454;Emergência
liberada; a aplicação deve sair do estado ERRO e ir para o estado
EMERGÊNCIA, indo em seguida para o estado OCIOSO.
Resultado dos testes: O teste foi executado com sucesso, as transições convergiram para o estado
esperado no caso de teste e o arquivo foi processado até o final com sucesso. O Quadro 28
apresenta o retorno do recurso “/history” executado ao final das transferências das mensagens.
Quadro 28: Retorno do recurso "/history" para o CT010
Ordem de processamento
(Timestamp)
Estado
1412132978910 CORTANDO_PECA
1412132980514 PROPRIEDADE_ALTERADA
1412132980514 OCIOSO
1412132981516 CORTANDO_PECA
1412132983518 CORTANDO_PECA
1412132985516 ERRO
1412132986517 ERRO
1412132988517 EMERGENCIA
1412132988517 OCIOSO
O Quadro 29 apresenta o detalhamento do caso de teste CT11.
Quadro 29: Detalhamentos do caso de teste CT 11
Tipo de teste Funcionalidade
Descrição Testar se a aplicação consegue executar corretamente a Sequência de Log
09.
Pré-condições - O sistema estar devidamente instalado e ter um arquivo .txt que
contenha, inserido junto com alguma outra sequência de log, a Sequência
de Log 09.
- A aplicação estar no estado OCIOSO.
Entrada de dados 1. A aplicação deve processar um arquivo de log que contenha
mensagens de log em que a Sequência de Log 09 está presente.
Resultados esperados - Ao processar a mensagem 2013-08-15 15:03:02:406;Documento
fechado; a aplicação deve sair do estado ERRO e ir para o estado
OCIOSO.
66
Resultado dos testes: O teste foi executado com sucesso, as transições convergiram para o estado
esperado no caso de teste e o arquivo foi processado até o final com sucesso. O
Quadro 30 apresenta o retorno do recurso “/history” executado ao final das transferências das
mensagens.
Quadro 30: Retorno do recurso "/history" para o CT011
Ordem de processamento (Timestamp) Estado
1412133181502 OCIOSO
1412133183119 ERRO
1412133185116 ERRO
1412133193118 OCIOSO
1412133198116 ESTADO_FINAL
O Quadro 31 apresenta o detalhamento do caso de teste CT12.
Quadro 31: Detalhamentos do caso de teste CT 12
Tipo de teste Funcionalidade
Descrição Testar se a aplicação consegue executar corretamente a Sequência de Log
10.
Pré-condições - O sistema estar devidamente instalado e ter um arquivo .txt que contenha,
inserido junto com alguma outra sequência de log, a Sequência de Log 10.
Entrada de dados 1. A aplicação deve processar um arquivo de log que contenha
mensagens de log em que a Sequência de Log 10 está presente.
Resultados esperados - Após (e apenas após) processar as mensagens 2013-08-15 15:45:05:739;Tecido
alterado;CutParams.SharpenerParameters.IdealSharpDistanceInte
rval;10;
e 2013-08-15 15:45:05:741;Tecido
alterado;CutParams.SpeedReductionParameters;org.pescuma.Model
Sharp.Lib.ObservableList`1[9A298ADC94864A675075DE0B98171310.1
E8C36AAC69CBB8FAB7E3FD23F3B9679]; a aplicação deve voltar ao estado
CORTE PAUSADO.
Resultado dos testes: O teste foi executado com sucesso, as transições convergiram para o estado
esperado no caso de teste e o arquivo foi processado até o final com sucesso. O Quadro 32
apresenta o retorno do recurso “/history” executado ao final das transferências das mensagens.
67
Quadro 32: Retorno do recurso "/history" para o CT012
Ordem de processamento
(Timestamp)
Estado
1412133490269 CORTE_PAUSADO
1412133491905 CORTE_PAUSADO
1412133492902 CORTE_PAUSADO
1412133493902 CORTE_DE_PAGINA
4.6.2 Casos de Teste de Desempenho
Os casos de teste de desempenho foram executados utilizando o mesmo arquivo de log. O
cenário de execução dos testes é composto pela aplicação Monitor instalada em um notebook, a
aplicação do Smart Gateway instalada em um BeagleBone Black e uma terceira aplicação, a qual
chamamos de SSCADA. Esta aplicação tem o objetivo de escrever em um arquivo que a Aplicação
Monitor monitora constantemente, simulando assim o repositório onde o supervisório SCADA real
persiste os logs. Todas essas aplicações foram conectadas no momento dos testes à mesma rede, que
possui a topologia estrela, capacidade de transmissão de 100 megabits por segundo e uma saída para
Internet de 10 megabits por segundo.
O Quadro 33 apresenta o detalhamento do caso de teste de desempenho CT01.
Quadro 33. Detalhamento do Caso de Teste de desempenho CT01
Tipo de teste Desempenho
Descrição Mensurar o custo computacional do Sistema Operacional (SO) no Beagle
Bon Black (footprint) sem nenhuma aplicação rodando.
Pré-condições O SO deve estar devidamente instalado no Beagle Bone Black.
Entrada de dados -
Resultados esperados - A quantidade de memória RAM ocupada pelo SO;
- A quantidade de memória ROM ocupada pelo SO;
- A porcentagem de CPU utilizada pelo SO.
Execução dos testes: Para a execução desse caso de teste foi executado o comando top no sistema
operacional do Beagle Bone Black e feita uma coleta da saída correspondente ao uso da CPU e
memória durante 5 minutos, também foi executado o comando du para obter o espaço em disco
utilizado.
68
Resultado dos testes: Ao término da coleta de dados foi realizada uma análise sobre os as 150
leituras realizadas e foi calculado a média e desvio padrão dos resultados. O resumo desta análise é
apresentado no
Quadro 34.
Quadro 34. Resultado do caso de teste CT01
Uso da CPU pelo SO Uso de memória pelo SO Uso de espaço em disco Média 0,46% 173,32 Mb 1.3Gb
Desvio padrão
0,30 0,12 -
O Quadro 35 apresenta o detalhamento do caso de teste de desempenho CT02
Quadro 35. Detalhamento do Caso de Teste de desempenho CT02
Tipo de teste Desempenho
Descrição Mensurar o custo computacional do SO junto com o container web e com a
aplicação do Smart Gateway no Beagle Bone Black, quando a aplicação
estiver estática (sem troca de mensagens).
Pré-condições O SO deve estar devidamente instalado no Beagle Bone Black.
A aplicação do Smart Gateway deve estar devidamente instalada no
container web escolhido.
Entrada de dados -
Resultados esperados - A quantidade de memória RAM ocupada pelo SO, container web e
aplicação Smart Gateway;
- A quantidade de espaço e disco utilizado pelo SO, container web e
aplicação Smart Gateway;
- A porcentagem de CPU utilizada pelo SO, container web e aplicação
Smart Gateway;
Execução dos testes: Para a execução desse caso de teste foi executado o comando top no sistema
operacional do Beagle Bone Black, inicializado o container web juntamente com a aplicação do
Smart Gateway e feita a coleta da saída correspondente ao uso da CPU e memória durante 5
minutos, também foi executado o comando du para obter o espaço em disco utilizado.
Resultado dos testes: O Quadro 36 apresenta os resultados obtidos após análise. Nele é possível
verificar um desvio padrão da média do uso da CPU com o valor de 30,00. Este cenário ocorreu,
possivelmente, devido a inicialização do container web juntamente com a aplicação, o que
provocou um outlier no uso da CPU o qual teve uma variação nesse período de 93,4 à 95,7 por
69
cento do uso de CPU o que fez com que a média do uso do CPU fosse de 12,78%. Porém,
considerando este um comportamento isolado e excluindo esses valores considerados como outliers
obtemos uma média de uso da CPU* com o valor de 1,10% e com desvio padrão de 0,28.
Quadro 36. Resultados do caso de teste de desempenho CT02
Média de uso
da CPU
Média de uso da
CPU*
Média de uso
de memória
Uso de espaço em disco
Média 12,78% 1,10% 265 Mb
1,33 Gb
Desvio Padrão
30,00 0,28
4,68
0
O Quadro 37 apresenta o detalhamento do caso de teste de desempenho CT03
Quadro 37. Detalhamento do Caso de Teste de desempenho CT03
Tipo de teste Desempenho
Descrição Mensurar o custo computacional da aplicação Smart Gateway e do container
web em relação ao envio e recebimento de mensagens pelo monitor.
Pré-condições O SO deve estar devidamente instalado no Beagle Bone Black.
A aplicação do Smart Gateway deve estar devidamente instalada no
container web escolhido.
A aplicação Monitor deve estar devidamente instalada e deve ser capaz de
enviar mensagens para a aplicação Smart Gateway.
A aplicação SSCADA deve estar devidamente instalada e deve estar
configurada para escrever com intervalo de 1 segundo no repositório que a
aplicação Monitor monitora.
A ferramenta JConsole deve estar devidamente configurada para uma análise
remota do BEAGLE BONE BLACK
Entrada de dados O Monitor deve enviar mensagens ao Smart Gateway, a qual deve conter
uma nova mensagem que foi inserida no arquivo de log a cada 1 segundo.
Resultados esperados - A quantidade de memória RAM consumida pelo container web e pela
aplicação durante o recebimento das mensagens;
- A porcentagem de CPU consumida pela aplicação e pelo container web
durante o recebimento das mensagens;
- O tempo que a aplicação Monitor levou para enviar cada uma das
mensagens e receber a respectiva resposta.
Execução dos testes: Para este teste foi utilizada a ferramenta JConsole para análise da JVM. A
ferramenta foi utilizada com seus valores padrão, o que fez com que a leitura dos valores de CPU e
de Memória RAM ocorresse a cada 4 segundos. Foram enviadas 160 mensagens do monitor para o
Smart Gateway com um intervalo de 1 segundo e analisadas de acordo com o caso de teste CT03.
70
Resultado dos testes: O Quadro 38 apresenta a média e desvio padrão das leituras realizadas pela
ferramenta JConsole, que devido ao intervalo de leitura de 4 segundos correspondem ao uso de
memória e CPU para um bloco de 4 mensagens. O Quadro 39 apresenta os resultados obtidos
referentes ao envio e o recebimento de mensagens pela aplicação Monitor e pode-se perceber que
há um desvio padrão alto no resultado do envio e recebimento por mensagem que considerou os
outliers, resultado apresentado na coluna com “*”. Isto ocorreu, provavelmente, devido à
necessidade inicial de se instanciar a classe responsável pelo envio da mensagem via Client REST,
a qual demorou cerca de 221ms. Quando excluímos os valores considerados outliers (como o
exemplo mencionado), o desvio padrão baixa consideravelmente e o tempo médio de envio e
recebimento diminui em aproximadamente 21,82%.
Quadro 38. Resultado do CT03 - Uso de recursos computacionais.
Uso da CPU pelo container e
aplicação
Uso de memória pelo container e
aplicação Média 23,20% 20,84 Mb
Desvio Padrão
16,69 3.01
Quadro 39. Resultado do CT03 - Tempo de Envio e Recebimento de mensagens
Envio e Recebimento por
mensagem
Envio e Recebimento por mensagem*
Média(ms) 37,01 58,98
Desvio Padrão 20,81 196,07
O Quadro 40 apresenta o detalhamento do caso de teste de desempenho CT04
Quadro 40. Detalhamento do Caso de Teste de desempenho CT04
Tipo de teste Desempenho
Descrição Mensurar o tempo praticado pela aplicação Smart Gateway e container web
quando a aplicação faz a interpretação de uma mensagem recebida (enviada
no CT03).
Pré-condições O SO deve estar devidamente instalado no BEAGLE BONE BLACK.
A aplicação do Smart Gateway deve estar devidamente instalada no servidor
de aplicação/container web escolhido.
Entrada de dados - O Monitor deve enviar uma mensagem ao Smart Gateway, a qual deve
conter uma nova mensagem que foi inserida no arquivo de log.
Resultados esperados - O tempo que a aplicação levou para fazer a interpretação da mensagem
enviada pelo Monitor.
71
Execução dos testes: Estes testes usaram os logs processados pelo caso de teste CT03. Foram
distribuídos nos códigos da aplicação do Smart Gateway trechos de códigos estratégicos que geram
logs da aplicação para indicar o inicio e o fim do processo que faz a interpretação das mensagens
enviadas pela aplicação Monitor.
Resultado dos testes: Assim como no caso de teste CT03, acredita-se que o resultado deste caso de
teste tenha sofrido influência da necessidade do container instanciar a classe responsável por
interpretar as mensagens, uma vez que, do mesmo modo, quando retiramos esses outliers, a média e
o desvio padrão dos processos de interpretação diminui consideravelmente. O Quadro 41 apresenta
o resultado da execução do caso de teste CT04, onde se pode perceber que a coluna Interpretador* a
qual inclui esses outliers nos cálculos possui valor bem discrepante em relação à coluna
Interpretador, principalmente com relação ao desvio padrão.
Quadro 41. Resultados do caso de teste de desempenho CT04
Interpretador Interpretador* Média (ms) 6,31 7,66
Desvio Padrão 3,39 17,25
O Quadro 42 apresenta o detalhamento do caso de teste CT05.
Quadro 42. Detalhamento do caso de teste CT05
Tipo de teste Desempenho
Descrição Mensurar o tempo de resposta do envio de estados atualizados para
aplicação na Nuvem.
Pré-condições O SO deve estar devidamente instalado no Beagle Bone Black.
A aplicação do Smart Gateway deve estar devidamente instalada no servidor
de aplicação/container web escolhido.
Alterações de estados da máquina industrial devem estar pendentes de envio
para a Nuvem.
A aplicação na Nuvem deve estar funcionando corretamente
Entrada de dados - As alterações realizadas na imagem virtual que o Smart Gateway mantém
da máquina industrial.
Resultados esperados - Tempo de resposta de mensagens enviadas à aplicação na Nuvem
Resultado dos testes: O Quadro 43 apresenta os resultados do caso de teste de desempenho CT05.
Quadro 43. Resultados do caso de teste desempenho CT05
Envio para a Nuvem Média (ms) 496
72
Desvio Padrão 0,068
O Quadro 44 apresenta o detalhamento do caso de teste CT06
Quadro 44. Detalhamento do caso de teste CT06
Tipo de teste Desempenho
Descrição Mensurar o tempo de resposta à uma solicitação a um recurso disponível no
Smart Gateway.
Pré-condições - O SO deve estar devidamente instalado no Beagle Bone Black.
- A aplicação do Smart Gateway deve estar devidamente instalada no
container web escolhido.
-O recurso solicitado deve ter sido inicializado.
Entrada de dados Uma solicitação de um cliente web RESTful.
Resultados esperados - O tempo que a aplicação levou para responder à solicitação do cliente.
Execução dos testes: Para este caso de teste foi utilizado o navegador Google Chrome versão
39.0.2171.71 com o plugin Advanced REST client 3.1.7 para realizar as requisições. Foram
realizadas 28 requisições ao recurso “smartgateway/maquinax/tecido”.
Resultado dos testes: O Quadro 45 apresenta a média em milissegundos e o desvio padrão dessas
requisições, a coluna que possui um “*” representa os resultados cujo nos cálculos foram incluídos
os valores considerados outliers.
Quadro 45. Resultados do caso de deste de desempenho CT06
Tempo de resposta ao cliente Tempo de resposta ao cliente*
Média (ms) 24,04 26,84
Desvio Padrão 9,51 22,60
Para medir a qualidade da solução desenvolvida, foram realizados dois tipos de testes: (i)
testes que validaram a solução e (ii) testes de desempenho. Os doze casos de teste de validação da
solução utilizaram como entrada de dados logs reais e visaram garantir que semânticas específicas
dos processos de operação da máquina industrial estavam sendo corretamente reproduzidos, o que
foi constatado ao final dos testes. Os testes de desempenho tiveram o intuito de verificar se a
solução é viável em termos de (i) consumo de memória, (ii) consumo de CPU, (iii) utilização do
espaço em disco, (iv) tempo de envio e recebimento de logs e (v) o tempo de interpretação de cada
mensagem. Para tanto, foi preciso identificar a freqüência de geração de mensagens do SCADA e
verificou-se que a quantidade de mensagens geradas por segundo pelo SCADA não é
determinística, sendo necessário fazer uma aproximação por meio de uma função de densidade de
73
probabilidade. Para isso, foram geradas 2040 mensagens de log de operações reais do SCADA e foi
extraída a quantidade ocorrências da geração de mensagens por segundo. Desconsiderando os
espaços de tempo em que nenhuma mensagem é gerada, percebeu-se que em 79,29% dos casos o
SCADA gerava 1 mensagem/s e que, em 14,53% dos casos, eram geradas 2 mensagens/s. Assim,
em 93,82% das vezes,eram geradas entre 1 e 2 mensagens/s.
Considerando os recursos disponíveis pelo Beagle Bone Black apresentados no Quadro 2 e
os utilizados pela solução desenvolvida, é possível perceber que o uso de memória pela aplicação é
na média pouco mais de 4% e o uso do processador pela aplicação é de também na média é de
23,20% para um conjunto de 4 mensagens, uma vez que para cada mensagem, considerando o
processo de interpretação, o tempo de processamento é de na média 37,01ms é possível perceber,
considerando a aproximação por meio da uma função de densidade de probabilidade que aponta que
em 93,82% das vezes são geradas entre 1 e 2 mensagens/s, a viabilidade da aplicação desenvolvida.
74
5 CONCLUSÕES
Como apresentado neste trabalho, o interesse das empresas pelo monitoramento remoto vem
crescendo. Do mesmo modo, o entendimento e adoção das tecnologias da Internet das Coisas (IoT)
no cotidiano das pessoas e das empresas está cada vez mais recebendo destaque. A necessidade de
monitoramento junto com as facilidades alcançadas pelos conceitos da IoT tornam viáveis o uso de
IoT para o monitoramento remoto. Contudo, em alguns equipamentos são encontradas restrições
que impedem a conectividade direta com a Internet. Foi neste cenário que se concentrou a maior
parte deste trabalho, no qual foi desenvolvido o Smart Gateway para a integração desses
equipamentos a Internet por meio de serviços web RESTful.
Outra parte deste trabalho, percebida como necessária durante o processo de elicitação de
requisitos e modelagem da solução, foi a necessidade de comunicação com equipamentos que
possuem protocolos heterogêneos sem comprometer a abstração criada para o Smart Gateway. Esta
necessidade acabou por gerar a adição de um outro componente o qual chamamos de Monitor, o
qual foi imprescindível para que os objetivos fossem atingidos diante do cenário de avaliação
disponível e criou possibilidades de trabalhos futuros.
Após o desenvolvimento das soluções propostas, foram realizados testes funcionais e não
funcionais para avaliar a qualidade da solução desenvolvida. Também foram realizados testes de
desempenho, de modo a garantir a viabilidade da solução em um ambiente de produção real.
Por fim, podemos considerar o Smart Gateway como um produto que inova ao resolver
restrições de conectividade de máquinas industriais, permitir a comunicação entre máquinas com
protocolos heterogêneos, utilizar os conceitos de IoT e computação em Nuvem para disponibilizar
seus dados e possibilitar o controle remoto dessas máquinas.
5.1 TRABALHOS FUTUROS
Como trabalho futuro sugere-se a evolução da aplicação Monitor, que neste trabalho teve
como objetivo a captura dos logs gerados pelo sistema SCADA. Essa evolução deve permitir que o
Monitor possa também prover uma interação com outras tecnologias de comunicação, como Zigbee,
Bluetooth e Ethernet. Outro trabalho relacionado com a aplicação Monitor seria adicionar a
capacidade de interagir com as máquinas monitoradas através de seus atuadores, funcionalidade
esta que permitiria, além da monitoria dos equipamentos, também o controle remoto dos mesmos.
75
Alguns trabalhos podem ser vislumbrados devido à grande quantidade de dados
disponibilizados pelo Smart Gateway por meio da sua API, desenvolvendo novas soluções para
representar, comparar e interpretar os dados do equipamento monitorado pelo Smart Gateway,
como trabalhos que abordam as tecnologias de mineração de dados e big data.
Outro trabalho recomendado é um aprimoramento dos testes de desempenho do Smart
Gateway utilizando um intervalo de leitura da ferramenta JConsole de 1 segundo o que faria que
tivéssemos mais precisão no apontamento do consumo de recursos. Os testes também poderiam
contemplar a latência, vazão da rede, consumo de energia e uma função de densidade de
probabilidade para se aproximar mais do cenário real, além de avaliar o envio simultâneo e
seqüencial de mensagens considerando as seguintes configurações de rede:
Sem limitação de banda (Sabendo qual a banda na origem e destino);
Com limite de 1Mbps (Limitado em uma das pontas); e
Com limite de 56kbps (Limitado em uma das pontas).
76
REFERÊNCIAS BIBLIOGRÁFICAS
ATZORI, L.; IERA, A.; MORABITO, G. The internet of things: A survey. Computer Networks,
Elsevier, v. 54, n. 15, p. 2787–2805, 2010.
BAILEY, D.; WRIGHT, E. Practical SCADA for industry. [S.l.]: Newnes, 2003. ISBN
0750658053. Disponível em:
<http://mycourses.ntua.gr/courses/ECE1254/document/Practical_SCADA_for_Industry.pdf>
Acessado em: 12 de Novembro de 2014.
BEAGLEBOARD. BeagleBone Black. Disponível em < http://beagleboard.org/black> Acesso em
27 de novembro de 2014.
BROWN, E. Top 10 Open Source Linux and Android SBCs. Em:
<http://www.linux.com/news/embedded-mobile/mobile-linux/773852-top-10-open-source-linux-
and-android-sbcs>. Acesso em: 29 de junho de 2014.
CERP-IoT Vision and challenges for realizing the internet of things. 2010 Disponível em <
http://www.theinternetofthings.eu/sites/default/files/Rob%20van%20Kranenburg/Clusterbook%202
009_0.pdf>
CHIAVENATO, I. Administração nos novos tempos. 2.ed. Rio de Janeiro: Elsevier, 2010.
DAL MORO, T.; DORNELES, C.F; REBONATTO, M.T. Webservices WS-* versus Web Services
REST In: REIC - Revista de Iniciação Cientifica, v1, n1, 2011.
DAVENPORT, T.; PRUSAK, L. Ecologia da informação: por que só a tecnologia não
basta para o sucesso na era da informação. São Paulo: Futura, 2001. 316p.
DE FRANÇA, T. C.; PIRES, P. F.; PIRMEZ, L.; DELICATO, F. C.; FARIAS, C. Minicurso 3:
Web das Coisas: Conectando Dispositivos Físicos ao Mundo Digital. In: XXIX SIMPÓSIO
BRASILEIRO DE REDES DE COMPUTADORES E SISTEMAS DISTRIBUÍDOS – SBRC,
2011, Campo Grande. Anais... Campo Grande: SBRC, 2011. p. 10-150.
DUQUENNOY, S.; GRIMAUD, G.; VANDEWALLE, J. The Web of Things: interconnecting
devices with high usability and performance. In: INTERNATIONAL CONFERECES ON
EMBEDDED SOFTWARE AND SYSTEMS – ICESS, 2009, HangZhou, China. Proceedings...
Los Alamitos: IEEE Computer Society, 2009. p. 323-330.
FIELDING, R. T.; TAYLOR, R.T. Principled Design of the Modern Web Architecture in: ACM
Transactions on Internet Technology, v. 2, n. 2, 2002, p. 115–150.
FISCHER, K.; GEBNER, J.; FRIES, S. Secure Identifiers and initial credential bootstrapping
for IoT@Work In: Sixth International Conference on Innovative Mobile and Internet Services in
Ubiquitous Computing, Proceedings… 2012.
77
GIL, A. C. Métodos e Técnicas de Pesquisa Social, 6ª Ed. São Paulo, 2008. Disponível em:
<http://mba.eci.ufmg.br/downloads/metodologia.pdf>
GROUP, W. W. Web services architecture, 2004. Disponível em: <http://www.w3.org/TR/ws-
arch/>. Acessado em: 12 de Novembro de 2014.
GUINARD, D. A. Web of Things Application Architecture – Integrating the Real-World into
the Web, 2011. Tese (Doctor of Computer Science) - ETH Zurich. Zurich. 2011.
GUINARD, D. Towards Opportunistic Applications in a Web of Things. In: IEEE
INTERNATIONAL CONFERENCE ON PERVASIVE COMPUTING AND
COMMUNICATIONS WORKSHOPS – PERCOM, 2010. Manheim. Proceedings... Manheim:
IEEE Computer Society Press, April 2010. p. 863-864.
GUINARD, D. Towards Opportunistic Applications in a Web of Things. In: IEEE
INTERNATIONAL CONFERENCE ON PERVASIVE COMPUTING AND
COMMUNICATIONS WORKSHOPS – PERCOM, 2010. Manheim. Proceedings... Manheim:
IEEE Computer Society Press, April 2010. p. 863-864.
HUMMEN, René; ZIEGELDORF, Jan H; SHAFAGH, Hossein; RAZA, Shahid; WEHRLE, Klaus.
Towards viable certificate-based authentication for the internet of things. In: 2ND ACM
WORKSHOP ON HOT TOPICS ON WIRELESS NETWORK SECURITY AND PRIVACY.
Proceedings of. [S.l.], 2013. p. 37–42
Imtiaz, J., D urkop, L., Trsek, H., Givehchi, O., Wisniewski, L., Shrestha, G. M., Zanella,A., Vivo,
G., Rotondi, D., Piccione, S., Comolli, M., Corvino, F., Houyou, A., Fischer,K., Hans-Peter, H.,
Joachim, W., J., C., Periorellis, P., Kloukinas, C., Mahbub, K., eKrotsiani, M. (2013). Iot@work -
d2.5 – integrated secure plug&work framework.
IOT@WORK. Project Overview 2010. Disponível em: <https://www.iot-at-work.eu/>. Acesso em
29 de novembro de 2014.
ITU. The Internet of Things. 2005. Disponível em:
http://www.itu.int/wsis/tunis/newsroom/stats/The-Internet-of-Things-2005.pdf>. Acesso em 07 de
novembro de 2014.
JERSEY. About. Disponível em < https://jersey.java.net/> Acesso em 10 de novembro de 2014.
JSON. Introducing JSON. Disponível em <http://json.org/> Acesso em 16 de junho de 2014.
KIRUBASHANKAR, R.; KRISHNAMURTHY, K.; INDRA, J. Remote monitoring system for
distributed control of industrial plant process. Journal of Scientific and Industrial Research, v.
68, n. 10, 2009, p. 858.
78
KLIGERMAN, D. C., Sistemas de indicadores de saúde e ambiente em instituições de saúde. Rio
de Janeiro: Revista Ciência & Saúde Coletiva da Associação Brasileira de Pós-Graduação em
Saúde, 2006.
MAHALLE, Parikshit; BABAR, Sachin; PRASAD, Neeli R; PRASAD, Ramjee. Identity
management framework towards internet of things (iot): Roadmap and key challenges. In: Recent
Trends in Network Security and Applications. [S.l.]: Springer, 2010. p. 430–439
MAHMOOD, M.K.; AL-NAIMA, F.M. An Internet Based Distributed Control Systems: A Case
Study of Oil Refineries In: Energy and Power Engineering, 2011 v.3. p. 310-316
MAYER, S. Deployment and Mashup Creation Support for Smart Things, Institute for
Pervasive Computing Departament od Computer Science ETH Zurich, 2010. Disponível em:
<http://www.vladtrifa.com/files/publications/Mayer10.pdf>. Acessado em 02 de dezembro de 2010.
MEGHANATHAN, N.; BOUMERDASSI, S.; CHAKI, N.; NAGAMALI, D. In: Recent Trends in
Network Security and Applications. Chennai: Springer, 2010. p. 430-439.
MIORANDI, Daniele; SICARI, Sabrina; PELLEGRINI, Francesco De; CHLAMTAC, Imrich.
Internet of things: Vision, applications and research challenges. Ad Hoc Networks, Elsevier, v. 10,
n. 7, p. 1497–1516, 2012.
NIC (National Intelligence Council), Disruptive Civil Technologies – Six Technologies with
Potential Impacts on US Interests Out to 2025 – Conference Report CR 2008-07, 2008
Disponivel em <http://fas.org/irp/nic/disruptive.pdf>
NURSEITOV, Nurzhan; PAULSON, Michael; REYNOLDS, Randall; IZURIETA, Clemente.
Comparison of json and xml data interchange formats: A case study. CAINE 2009, v. 9, p. 157–
162, 2009.
POLÔNIA, P. V. Proposta de Arquitetura Orientada a Recursos para SCADA na WEB, 2011.
Disponível em <https://repositorio.ufsc.br/bitstream/handle/123456789/95678/299173.pdf>
RANANURTHY, B.; BHARGAVI, S.; SHASHIKUMAR, R. Development of a Low-Cost GSM
SMS-Base Humidity Remote Monitoring and Control system for Industrial Application.
International Journal of Advanced Computer Science and Applications, v. 1, n. 4, 2010.
RESTful web services in Java. Packt Publishing BIRMINGHAM – MUMBAI 2009, p. 20-81.
SANDOVAL, J. RESTful Java Web Services, Master core REST: concepts and create RESTful
web services in Java Mumbai: Packt Publishing 2009.
STALLMAN, R. Richard Stallman – On “Free Hardware” in: Linux Today, 1999 Disponível
em: < http://www.linuxtoday.com/infrastructure/1999062200505NWLF>. Acessado em 27 de
junho de 2014.
WANGHAM, M.S.; DOMENECH, M.C.; DE MELO, E.R. Infraestruturas de Autenticação e de
Autorização para Internet das Coisas, In: XIII SIMPÓSIO BRASILEIRO EM SEGURANÇA DA
79
INFORMAÇÃO E DE SISTEMAS COMPUTACIONAIS – SBSEG, 2013,Manaus. Anais...
Manaus: Minicursos SBSeg, 2013. p. 156-205
XIANG, C.; LI,X. General Analisys on Architecture and Key Technologies about Internet of
Things. In: Software Engineering and Service Science (ICSESS), 2012 IEEE 3rd International
Conference on. Proceedings… 2012. p. 325-328.
XU,K.; ZHANG, X; SONG,M.; SONG,J. Mobile Mashup: Architecture, Challenges and
Suggestions. In: Management and Service Science, p. 1 – 4.
Zecevic, G. (1998). Web based interface to scada system. In Power System Technology, 1998.
Proceedings. POWERCON ’98. 1998 International Conference on, volume 2, pages 1218–1221
vol.2.
ZENG, D.; GUO, S.; CHENG, Z. The Web of Things: A Survey, 2011 (Invited Paper). Journal of
Communications, v.6, n.6,p. 424-438, sep. 2011
80
APÊNDICE A – DIAGRAMA DE CLASSES
O diagrama de classes da aplicação Monitor é apresentado na Figura 13. A classe Monitor
possui as principais configurações e métodos utilizados para manipular o Monitor, enquanto que a
Classe Leitor é responsável quando é instanciada é responsável por verificar constantemente as
atualizações nos arquivos de log e enviar para o Smart Gateway.
Figura 13. Diagrama de classe da aplicação Monitor
81
APÊNDICE B – RETORNO DO RECURSO “/HISTORY”
REFERENTE AO CT05
Quadro 46: Retorno do recurso "/history" para o CT05
Ordem de
processamento
(Timestamp)
Estado
1412131335791 ESTADO_INICIAL
1412131335791 OCIOSO
1412131337448 OCIOSO
1412131338446 ERRO
1412131339446 INICIADA_REMISSAO_A_ZERO
1412131341446 TERMINADA_REMISSAO_A_ZERO
1412131341446 OCIOSO
1412131344446 OCIOSO
1412131345445 SETANDO_VALOR_INICIAL
1412131347446 SETANDO_VALOR_INICIAL
1412131349446 SETANDO_VALOR_INICIAL
1412131350444 SETANDO_VALOR_INICIAL
1412131353442 SETANDO_VALOR_INICIAL
1412131354444 PROPRIEDADE_ALTERADA
1412131354444 OCIOSO
1412131357445 OCIOSO
1412131358445 OCIOSO
1412131362447 SETANDO_VALOR_INICIAL
1412131363446 SETANDO_VALOR_INICIAL
1412131366445 SETANDO_VALOR_INICIAL
1412131368446 SETANDO_VALOR_INICIAL
1412131371444 ESPERA_PELO_NIVEL_CORRETO_DE_VACUO
1412131373444
ESPERA_PELO_NIVEL_CORRETO_DE_VACUO_TERMINADO
1412131373444 OCIOSO
1412131375446 MOVIMENTACAO_ESTEIRA_FORA_DE_HORA
82
1412131375446 OCIOSO
1412131376445 MOVIMENTACAO_ESTEIRA_FORA_DE_HORA
1412131376445 OCIOSO
1412131379446 MOVIMENTACAO_ESTEIRA_FORA_DE_HORA
1412131379446 OCIOSO
1412131380444 ESPERA_PELO_NIVEL_CORRETO_DE_VACUO
1412131382445
ESPERA_PELO_NIVEL_CORRETO_DE_VACUO_TERMINADO
1412131382446 OCIOSO
1412131383443 OCIOSO
1412131384445 PROPRIEDADE_ALTERADA
1412131384445 OCIOSO
1412131385453 PROPRIEDADE_ALTERADA
1412131385453 OCIOSO
1412131387445 OCIOSO
1412131388445 CORTE
1412131389445 CORTE_DE_PAGINA
1412131390445 ESPERA_PELO_NIVEL_CORRETO_DE_VACUO
1412131393445
ESPERA_PELO_NIVEL_CORRETO_DE_VACUO_TERMINADO
1412131393446 OCIOSO
1412131394445 CORTANDO_PECA
1412131401448 CORTANDO_PECA
1412131403448 CORTANDO_PECA
1412131406446 CORTANDO_PECA
1412131408446 CORTANDO_PECA
1412131409445 CORTANDO_PECA
1412131411445 CORTANDO_PECA
1412131412445 CORTANDO_PECA
1412131413445 CORTANDO_PECA
1412131414445 TERMINADO_C0RTE_PAGINA
1412131415445 ESPERA_PELO_NIVEL_CORRETO_DE_VACUO
1412131415446
ESPERA_PELO_NIVEL_CORRETO_DE_VACUO_TERMINADO
83
1412131415446 OCIOSO
1412131417445 MOVIMENTACAO_ESTEIRA
1412131419445 OCIOSO
1412131420445 CORTE_DE_PAGINA
1412131421445 ESPERA_PELO_NIVEL_CORRETO_DE_VACUO
1412131422443
ESPERA_PELO_NIVEL_CORRETO_DE_VACUO_TERMINADO
1412131422443 OCIOSO
1412131423444 CORTANDO_PECA
1412131426445 CORTANDO_PECA
1412131430445 TERMINADO_C0RTE_PAGINA
1412131432444 ESPERA_PELO_NIVEL_CORRETO_DE_VACUO
1412131433445
ESPERA_PELO_NIVEL_CORRETO_DE_VACUO_TERMINADO
1412131433445 OCIOSO
1412131435445 MOVIMENTACAO_ESTEIRA
1412131435446 OCIOSO
1412131436445 MOVIMENTACAO_ESTEIRA_FORA_DE_HORA
1412131436445 OCIOSO
1412131437445 MOVIMENTACAO_ESTEIRA_FORA_DE_HORA
1412131437445 OCIOSO
1412131439445 CORTE_DE_PAGINA
1412131440445 ESPERA_PELO_NIVEL_CORRETO_DE_VACUO
1412131441445
ESPERA_PELO_NIVEL_CORRETO_DE_VACUO_TERMINADO
1412131441445 OCIOSO
1412131442445 CORTANDO_PECA
1412131443445 CORTANDO_PECA
1412131443446 TERMINADO_C0RTE_PAGINA
1412131444445 OCIOSO
1412131445446 MOVIMENTACAO_ESTEIRA_FORA_DE_HORA
1412131445446 OCIOSO
1412131445447 MOVIMENTACAO_ESTEIRA_FORA_DE_HORA
1412131445447 OCIOSO
84
1412131446445 OCIOSO
1412131447445 OCIOSO
1412131448445 SETANDO_VALOR_INICIAL
1412131448446 SETANDO_VALOR_INICIAL
1412131449445 ESPERA_PELO_NIVEL_CORRETO_DE_VACUO
1412131450444
ESPERA_PELO_NIVEL_CORRETO_DE_VACUO_TERMINADO
1412131450445 OCIOSO
1412131451445 ESPERA_PELO_NIVEL_CORRETO_DE_VACUO
1412131451446
ESPERA_PELO_NIVEL_CORRETO_DE_VACUO_TERMINADO
1412131451446 OCIOSO
1412131452445 OCIOSO
1412131453445 PROPRIEDADE_ALTERADA
1412131453445 OCIOSO
1412131454445 PROPRIEDADE_ALTERADA
1412131454445 OCIOSO
1412131455445 OCIOSO
1412131457445 OCIOSO
1412131457446 OCIOSO
1412131459445 SETANDO_VALOR_INICIAL
1412131460445 SETANDO_VALOR_INICIAL
1412131461444 ESPERA_PELO_NIVEL_CORRETO_DE_VACUO
1412131462444
ESPERA_PELO_NIVEL_CORRETO_DE_VACUO_TERMINADO
1412131462445 OCIOSO
1412131464444 ESPERA_PELO_NIVEL_CORRETO_DE_VACUO
1412131465445
ESPERA_PELO_NIVEL_CORRETO_DE_VACUO_TERMINADO
1412131465445 OCIOSO
1412131467445 OCIOSO
1412131470445 PROPRIEDADE_ALTERADA
1412131470446 OCIOSO
1412131478447 PROPRIEDADE_ALTERADA
85
1412131478447 OCIOSO
1412131478448 OCIOSO
1412131480447 CORTE
1412131482445 CORTE_DE_PAGINA
1412131483445 ESPERA_PELO_NIVEL_CORRETO_DE_VACUO
1412131484445
ESPERA_PELO_NIVEL_CORRETO_DE_VACUO_TERMINADO
1412131484445 OCIOSO
1412131489445 CORTANDO_PECA
1412131490446 CORTANDO_PECA
1412131491445 CORTANDO_PECA
1412131491446 CORTANDO_PECA