2021-dis-ircbranco

Prévia do material em texto

UNIVERSIDADE FEDERAL DO CEARÁ
CENTRO DE CIÊNCIAS E TECNOLOGIA
DEPARTAMENTO DE ENGENHARIA ELÉTRICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA ELÉTRICA
MESTRADO ACADÊMICO EM ENGENHARIA ELÉTRICA
ITALO CASTELO BRANCO
TECNOLOGIAS WEB APLICADAS NA AUTOMAÇÃO INDUSTRIAL
UTILIZAÇÃO EM UM SISTEMA DE VARREDURA AÉREO
FORTALEZA
2021
ITALO CASTELO BRANCO
TECNOLOGIAS WEB APLICADAS NA AUTOMAÇÃO INDUSTRIAL
UTILIZAÇÃO EM UM SISTEMA DE VARREDURA AÉREO
Dissertação apresentada ao Curso de Mes-
trado Acadêmico em Engenharia Elétrica do
Programa de Pós-Graduação em Engenharia
Elétrica do Centro de Ciências e Tecnologia da
Universidade Federal do Ceará, como requisito
parcial à obtenção do título de mestre em
Engenharia Elétrica. Área de Concentração:
Engenharia Elétrica
Orientador: Prof. Dr. Fabrício Gonzalez
Nogueira
FORTALEZA
2021
Dados Internacionais de Catalogação na Publicação 
Universidade Federal do Ceará
Biblioteca Universitária
Gerada automaticamente pelo módulo Catalog, mediante os dados fornecidos pelo(a) autor(a)
C345t Castelo Branco, Italo Rosse Alves.
 Tecnologias web aplicadas na Automação Industrial : utilização em um sistema de varredura aérea / Italo
Rosse Alves Castelo Branco. – 2021.
 73 f. : il. color.
 Dissertação (mestrado) – Universidade Federal do Ceará, Centro de Tecnologia, Programa de Pós-
Graduação em Engenharia Elétrica, Fortaleza, 2021.
 Orientação: Prof. Dr. Fabrício Gonzalez Nogueira.
 1. Automação Industrial. 2. Arquitetura em microsserviços. 3. API REST. 4. Serviços RESTFul. I. Título.
 CDD 621.3
ITALO CASTELO BRANCO
TECNOLOGIAS WEB APLICADAS NA AUTOMAÇÃO INDUSTRIAL
UTILIZAÇÃO EM UM SISTEMA DE VARREDURA AÉREO
Dissertação apresentada ao Curso de Mes-
trado Acadêmico em Engenharia Elétrica do
Programa de Pós-Graduação em Engenharia
Elétrica do Centro de Ciências e Tecnologia da
Universidade Federal do Ceará, como requisito
parcial à obtenção do título de mestre em
Engenharia Elétrica. Área de Concentração:
Engenharia Elétrica
Aprovada em:
BANCA EXAMINADORA
Prof. Dr. Fabrício Gonzalez Nogueira (Orientador)
Universidade Federal do Ceará (UFC)
Prof. Dr. Bismark Claure Torrico
Universidade Federal do Ceará (UFC)
Prof. Dr. Pedro Pedrosa Rebouças Filho
Universidade Federal do Ceará (UFC)
Prof. Dr. Thiago Damasceno Cordeiro
Universidade Federal de Alagoas (UFAL)
À minha mãe, por ter acreditado e investido em
mim. À minha família, por me suportar nos
momentos difíceis.
AGRADECIMENTOS
Ao Prof. Dr. Fabrício Gonzalez, por me orientar durante a trajetória do mestrado.
Aos professores do Departamento de Engenharia Elétrica, pela difusão do conheci-
mento.
Aos colegas do Grupo de Pesquisa em Automação, Controle e Robótica (GPAR),
que contribuíram com suas experiências e disponibilidade.
Aos colegas que participaram do projeto ISAA, pelas discussões e trabalho árduo.
Ao Doutorando em Engenharia Elétrica, Ednardo Moreira Rodrigues, e seu assistente,
Alan Batista de Oliveira, aluno de graduação em Engenharia Elétrica, pela adequação do template
utilizado neste trabalho para que o mesmo ficasse de acordo com as normas da biblioteca da
Universidade Federal do Ceará (UFC).
Ao trabalho, empenho e dedicação de minha mãe, Maria Gorete Alves Castelo
Branco, que hoje descansa em paz.
E à EDP Brasil, EDP Pecém e ao programa de Pesquisa e Desenvolvimento Tecnoló-
gico do Setor de Energia Elétrica da ANEEL por todo apoio recebido durante a elaboração e
execução do projeto PD-07267-0016/2018.
“Não podemos resolver nossos problemas com
o mesmo pensamento que tínhamos quando os
criamos.”
(Albert Einstein)
RESUMO
Este trabalho apresenta o desenvolvimento de uma plataforma web para suporte operacional de
um sistema de volumetria aérea e gerenciamento de inventário de carvão mineral. O sistema é
composto por um Veículo Aéreo Não Tripulado equipado com um sensor de alta precisão que
realiza o mapeamento dimensional das pilhas de minério e um aplicativo web, que é responsável
pelo gerenciamento e monitoramento das informações coletadas. A plataforma web foco deste
documento, atua de forma a oferecer serviços de persistência de dados, disponibilização de
leituras e integração com o sistemas automatizados já existentes na planta. Sua construção foi
baseada em uma arquitetura em microsserviços e a troca de informações é realizada por meio de
uma API REST integrada. Para avaliação do desempenho foram determinados parâmetros de
referência com base na quantidade esperada de usuários que utilizará a plataforma, executados
ensaios nos comandos de leitura, criação, atualização e exclusão de dados e coletados os
resultados para posterior comparação. Os resultados obtidos mostraram que o código foi capaz
de trabalhar de forma satisfatória, operando com tempos de resposta inferiores aos estipulados
e atendendo um número de requisições superior ao esperado. Ao final, são discutidas as
contribuições, pontos de melhoria e trabalhos futuros.
Palavras-chave: Automação. Arquitetura em microsserviços. API REST. Serviços RESTFul.
ABSTRACT
This work presents a web platform that supports the operation of an aereal volumetry and
coal stock manegement system. This system is composed by a drone equipped with a LiDAR
sensor for geometric mapping of stockpiles and a web application, responsable for monitoring
and management of acquired information. The proposed web platform acts offering data
persistence services, providing several measurements and implementing integration with other
plant automation systems. It’s implementation was based on microservices architecture and data
exchange is done by a integrated REST API. For performance evaluation, comparation between
previosialy defined reference parameters and read, creation, update and exclusion data tests
were performed. The results were promising, indicating acceptable code performance. Finally,
contributions, improvement points and future works were discussed.
Keywords: Automation. Microservices architecture. REST API. RESTFul services.
LISTA DE FIGURAS
Figura 1 – Visão geral - Transportador de Correia de Longa Distância (TCLD) . . . . . 19
Figura 2 – Balança dinâmica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Figura 3 – Fotogrametria: em objeto (esquerda) e aérea (direita) . . . . . . . . . . . . 22
Figura 4 – Modicon 084 (esquerda) e CLPs modernos (direita) . . . . . . . . . . . . . 25
Figura 5 – IHM: gráfica (esquerda) e textual (direita) . . . . . . . . . . . . . . . . . . 25
Figura 6 – Arranjo clássico de rede industrial . . . . . . . . . . . . . . . . . . . . . . 27
Figura 7 – Arquitetura típica de um sistema automatizado . . . . . . . . . . . . . . . . 27
Figura 8 – Primeiro navegador e página web . . . . . . . . . . . . . . . . . . . . . . . 30
Figura 9 – Linguagens mais utilizadas durante os anos . . . . . . . . . . . . . . . . . . 31
Figura 10 – Modelo tradicional x modelo Ajax . . . . . . . . . . . . . . . . . . . . . . 32
Figura 11 – Exemplo de Application Programming Interface (API) Representational State
Transfer (REST) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Figura 12 – Número total de pessoas utilizando a internet . . . . . . . . . . . . . . . . . 34
Figura 13 – Máquina real executando máquinas virtuais . . . . . . . . . . . . . . . . . 34
Figura 14 – Máquina real executando containers . . . . . . . . . . . . . . . . . . . . . 35
Figura 15 – Arquitetura simplificada do sistema proposto . . . . . . . . . . . . . . . . . 38
Figura 16 – Sistema de varredura aérea . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Figura 17 – Arquitetura inicial do backend . . . . . . . . . . . . . . . . . . . . . . . . 42
Figura 18 – Arquitetura final do backend do Interface do Sistema Aéreo Automático
(ISAA): baseada em microsserviços . . . . . . . . . . . . . . . . .. . . . . 43
Figura 19 – ISAA DB Server: Diagrama de esquema do banco de dados . . . . . . . . . 45
Figura 20 – ISAA DB Admin: Detalhe do phpMyAdmin . . . . . . . . . . . . . . . . . 45
Figura 21 – ISAA Modbus: Integração com automação existente . . . . . . . . . . . . . 47
Figura 22 – Aplicativo web lendo dados do ISAA DB Manager . . . . . . . . . . . . . 49
Figura 23 – Histórico de missões - visão do aplicativo web . . . . . . . . . . . . . . . . 54
Figura 24 – Arranjo empregado nos ensaios . . . . . . . . . . . . . . . . . . . . . . . . 57
Figura 25 – Tempos médios de execução: método GET . . . . . . . . . . . . . . . . . . 58
Figura 26 – Tempos médios de execução: método POST . . . . . . . . . . . . . . . . . 60
Figura 27 – Tempos médios de execução: método PUT . . . . . . . . . . . . . . . . . . 61
Figura 28 – Tempos médios de execução: método DELETE . . . . . . . . . . . . . . . 62
Figura 29 – Configurações de rede do CLP . . . . . . . . . . . . . . . . . . . . . . . . 71
Figura 30 – Configurações de dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Figura 31 – Alterações de lógica 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Figura 32 – Alterações de lógica 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Figura 33 – Alterações de lógica 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Figura 34 – Alterações de lógica 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
LISTA DE TABELAS
Tabela 1 – ISAA DB Server: Tabelas e suas funcionalidades . . . . . . . . . . . . . . 44
Tabela 2 – ISAA Modbus: Métodos HTML disponíveis . . . . . . . . . . . . . . . . . 47
Tabela 3 – ISAA Modbus: Conteúdo de "station.json" . . . . . . . . . . . . . . . . . . 47
Tabela 4 – ISAA DB Manager: Serviços disponíveis . . . . . . . . . . . . . . . . . . . 48
Tabela 5 – massDataByUser: Métodos HTML disponíveis . . . . . . . . . . . . . . . 49
Tabela 6 – massDataByUser: Descrição dos parâmetros . . . . . . . . . . . . . . . . . 49
Tabela 7 – massDataByPile: Métodos HTML disponíveis . . . . . . . . . . . . . . . . 50
Tabela 8 – massDataByPile: Descrição dos parâmetros . . . . . . . . . . . . . . . . . 51
Tabela 9 – pointCloudData: Métodos HTML disponíveis . . . . . . . . . . . . . . . . 52
Tabela 10 – pointCloudData: Descrição dos parâmetros . . . . . . . . . . . . . . . . . . 53
Tabela 11 – droneData: Métodos HTML disponíveis . . . . . . . . . . . . . . . . . . . 54
Tabela 12 – Parâmetros de referência . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Tabela 13 – Requisições por segundo: leitura . . . . . . . . . . . . . . . . . . . . . . . 59
Tabela 14 – Requisições por segundo: criação . . . . . . . . . . . . . . . . . . . . . . . 59
Tabela 15 – Requisições por segundo: atualização . . . . . . . . . . . . . . . . . . . . . 61
Tabela 16 – Requisições por segundo: exclusão . . . . . . . . . . . . . . . . . . . . . . 62
LISTA DE ABREVIATURAS E SIGLAS
TCLD Transportador de Correia de Longa Distância
API Application Programming Interface
REST Representational State Transfer
ISAA Interface do Sistema Aéreo Automático
CIPP Complexo Industrial e Portuário do Pecém
UTE usina termelétrica
SIN Sistema Interligado Nacional
CSU Continuous Ship Unloader
TT torres de transferência
STR Stacker & Reclaimer
ONS Operador Nacional do Sistema Elétrico
VANT Veículo aéreo não tripulado
PID Proporcional, Integral e Derivativo
CLP Controlador Lógico Programável
IHM Interface Homem-Máquina
HMI Human Machine Interface
DCS Distributed Control System
SCADA Supervisory Control and Data Aquisition
ERP Enterprise Resource Planning
CERN Conselho Europeu de Pesquisa Nuclear
HTML HyperText Markup Language
URI Uniform Resource Identifier
HTTP HyperText Transfer Protocol
W3C World Wide Web Consortium
CSS Cascading Style Sheets
XML Extensible Markup Language
SSL Secure Sockets Layer
AJAX Asynchronous JavaScript e XML
SOA Service Oriented Architecture
ESB Enterprise Service Bus
GPS Global Positioning System
VM Virtual Machine
SO Sistema Operacional
UG unidades de geração
GPAR Grupo de Pesquisa Automação, Controle e Robótica
UFC Universidade Federal do Ceará
LiDAR Light Detection and Ranging
IMU Inertial Measurement Unit
ROS Robot Operating System
RDBMS Relational Database Management System
BD banco de dados
SUMÁRIO
1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.1 Motivações e justificativa do trabalho . . . . . . . . . . . . . . . . . . . . 17
1.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.3 Divisão do trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2 O SISTEMA DE TRANSPORTE DE CARVÃO E SUAS NECESSIDADES 19
2.1 O sistema de transporte de carvão . . . . . . . . . . . . . . . . . . . . . 19
2.2 A necessidade de monitorar o pátio de carvão . . . . . . . . . . . . . . . 20
2.2.1 Balanças dinâmicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.2.2 Fotogrametria aérea . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3 FUNDAMENTAÇÃO TEÓRICA . . . . . . . . . . . . . . . . . . . . . . 23
3.1 A indústria e a Automação Industrial . . . . . . . . . . . . . . . . . . . . 23
3.1.1 Sistemas automatizados - o estado da arte . . . . . . . . . . . . . . . . . . 24
3.2 Tecnologias, arquiteturas e serviços web . . . . . . . . . . . . . . . . . . 29
3.2.1 O JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.2.2 Arquitetura baseada em serviços e serviços RESTful . . . . . . . . . . . . 31
3.2.3 Tecnologia de containers e aplicações web . . . . . . . . . . . . . . . . . . 33
4 METODOLOGIA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.1 A solução de monitoramento proposta . . . . . . . . . . . . . . . . . . . 37
4.2 Sistema de varredura aérea . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.3 Servidor de aplicação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.4 Serviços back-end do sistema de volumetria aérea . . . . . . . . . . . . . 40
4.5 ISAA DB Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.6 ISAA DB Config . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.7 ISAA Modbus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.8 ISAA DB Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.8.1 massDataByUser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.8.2 massDataByPile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.8.3 pointCloudData . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.8.4 droneData . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5 RESULTADOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.1 Metodologia de ensaios . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.1.1 Resultados: comandos de leitura . . . . . . . . . . . . . . . . . . . . . . . 58
5.1.2 Resultados: comandos de criação . . . . . . . . . . . . . . . . . . . . . . 59
5.1.3 Resultados: comandos de atualização . . . . . . . . . . . . . . . . . . . . 60
5.1.4 Resultados: comandos de exclusão . . . . . . . . . . . . . . . . . . . . . . 62
6 CONCLUSÕES E TRABALHOS FUTUROS . . . . . . . . . . . . . . . 64
REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
APÊNDICES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
APÊNDICE A–ISAA MODBUS: ALTERAÇÕES NO CLP EXISTENTE 71
16
1 INTRODUÇÃO
Desde o advento da Revolução Industrial, a necessidade de consumo humano fez
com que máquinas e processos produtivos passassem por diversas evoluções e transformações,
tanto no campo conceitual quanto no estrutural. Para que todas essas adequações fossem factíveis,
a automatização de componentes era inevitável. Nesse ensejo, surgiu a Automação Industrial,
que combinandosensores, CLPs, IHMs, redes industriais e sistemas SCADA ditaram por vários
anos o padrão de como o ambiente do "chão de fábrica" deveria ser controlado, monitorado e
supervisionado. Contudo, existem aplicações que, mesmo necessitando também de controle e
aquisição de dados, não operam de forma satisfatória quando são empregados esses "pacotes
de ferramentas clássicas" na sua construção. Um exemplo para esse caso particular, é o sistema
de volumetria aérea desenvolvido para uma usina termelétrica instalada em São Gonçalo do
Amarante no Ceará. É uma plataforma completamente automática, responsável pelo cálculo
de volume e gestão de inventário do carvão mineral estocado no pátio de operações da usina.
A aquisição de informações é realizada por um drone e pela instrumentação local existente e
a visualização ocorre por meio de um aplicativo web. Dada a variedade de equipamentos e
linguagens diferentes envolvidas em seu desenvolvimento, era pouco provável que uma solução
comercial genérica atendesse aos requisitos desejados.
Considerando essa problemática, foi desenvolvida uma API REST capaz de adquirir,
persistir, disponibilizar, gerenciar e integrar todas as informações geradas e consumidas pelos
diferentes módulos e tecnologias presentes na plataforma. Além disso, visando a máxima dispo-
nibilidade operacional da solução, foi implantada uma arquitetura baseada em microsserviços,
onde cada módulo funcional pode ser executado em um ambiente dedicado e independente.
Ao contrário dos sistemas de automação comerciais, essa abordagem permite que qualquer
aplicativo ou dispositivo que possua suporte para o protocolo HTTP envie e receba informações.
Outras vantagens que merecem destaque são a possibilidade de realizar um escalonamento
horizontal da aplicação, a capacidade de implantar uma política de replicação de serviços e a
total independência de sistemas operacionais proprietários.
17
1.1 Motivações e justificativa do trabalho
Dado o alto custo da tonelada de carvão mineral (EIA, 2021) aliada a confirmação
de forte elevação no preço desta commodity 1 no mercado internacional (BUSINESSINSIDER,
2021), é simples inferir que os processos de aquisição, transporte e manejo desse insumo são
cruciais para a saúde financeira e a correta operação de uma planta térmica de geração de energia
elétrica. Seguindo esse raciocínio, foi explorada a tarefa de acompanhamento e geração de
inventário de estoque de produto, tarefa essa que hoje é essencialmente manual no local foco do
estudo e que possui suas informações de entrada e saída de produto com várias incertezas e erros
de medição intrínsecos ao processo. Com isso, após análise da questão por parte da equipe de
projeto, foi proposta uma solução completamente automática para o gerenciamento do inventário
de carvão - o sistema de varredura aéreo. Com necessidade de integrar os diversos módulos,
tecnologias e aplicativos que compõem esta solução, surgiu a proposta de criação da plataforma
auxilar tema deste trabalho.
1.2 Objetivos
Este trabalho visa o desenvolvimento de uma estrutura de software auxilar que
permita adquirir, persistir, disponibilizar, gerenciar e integrar os diferentes módulos e tecnolo-
gias presentes no sistema de varredura aérea automática. Além disso, os seguintes objetivos
específicos também são considerados:
– Promover integração entre diferentes tecnologias e linguagens de programação;
– Permitir execução multiplataforma
– Implantar acesso ao banco de dados de forma “transparente”
– Aquisitar dados de automação existente
– Disponibilizar informações adquiridas de forma simples e padronizada
– Desenvolver solução automatizada industrial capaz de operar em sistema operacional
Linux
1 Bem em estado bruto, de origem agropecuária ou de extração mineral ou vegetal, produzido em larga escala
mundial e com características físicas homogêneas, seja qual for a sua origem, destinado ao comércio externo
(OXFORD, 2021).
18
1.3 Divisão do trabalho
O documento inicia com uma apresentação do local de implantação da plataforma
em questão - o sistema de transporte de carvão mineral e o pátio de estocagem - e os desafios e
necessidades deste. Em seguida, uma revisão bibliográfica sobre o estado da arte dos sistemas de
automação tradicionais e dos sistemas web é realizada. Na sequência, o detalhamento da solução
proposta é apresentada, juntamente com os ensaios a que foi submetida e resultados obtidos. Por
fim, são realizadas as considerações finais e propostas para trabalhos futuros.
19
2 O SISTEMA DE TRANSPORTE DE CARVÃO E SUAS NECESSIDADES
Nesta seção será apresentado o pátio de armazenamento de carvão mineral e seus
sistemas auxiliares.
2.1 O sistema de transporte de carvão
A EDP Pecém, sediada no Complexo Industrial e Portuário do Pecém (CIPP) da
cidade de São Gonçalo do Amarante do estado no Ceará, é uma usina termelétrica (UTE)
composta por duas unidades geradoras que totalizam 720 MW de potência disponibilizada para
o Sistema Interligado Nacional (SIN). Interligando a usina e o porto do Pecém, um sistema de
transportadores de correias foi criado com o objetivo de deslocar carvão mineral, o principal
insumo do empreendimento, entre píer e o pátio de estocagem (ou pátio de carvão) da UTE.
Esse sistema de transporte possui aproximadamente 13 km de extensão sendo conhecido como
TCLD. A Figura 1 mostra um diagrama simplificado do sistema de transporte.
Figura 1 – Visão geral - TCLD
Fonte: Autor (2021).
Chegando no porto, o carvão mineral é retirado dos porões dos navios por um
equipamento especializado chamado de Continuous Ship Unloader (CSU), que descarrega
o produto na primeira correia de um conjunto de sete transportadores tubulares, conhecidos
simplesmente por "TCs" numerados de 01 à 07. O carvão então é movido entre os transportadores
e suas respectivas torres de transferência (TT). Chegado na última correia, a TC07, o carvão é
depositado em pilhas no pátio por máquinas empilhadeiras/retomadoras chamadas de Stacker &
Reclaimer (STR) e assim permanecem até que seja necessário manejo ou utilização.
20
2.2 A necessidade de monitorar o pátio de carvão
Considerando um despacho típico solicitado pelo Operador Nacional do Sistema
Elétrico (ONS), com os dois geradores operando em carga nominal vinte e quatro horas por
dia e sete dias por semana e considerando também que o pátio de carvão esteja completamente
abastecido, a usina possui uma autonomia máxima de sessenta e dois dias corridos de operação.
A princípio, esse intervalo oferece condições favoráveis para adequações em estratégias de
negócio (aquisições baseadas em melhor preço, cancelamento/solicitação de cargas e longos
tempos fora de operação por exemplo), porém, um fator limitante torna esses trâmites mais
pragmáticos: o tempo médio entre a solicitação de carga de navio na mina e a descarga deste
no porto do Pecém, leva sessenta dias em média. Dito isso, é possível deduzir que falhas nas
estimativas de consumo de carvão e atrasos nas solicitações e entregas de matéria-prima causados
por uma quantificação ineficiente podem levar a cenários operacionais críticos (BRANCO et al.,
2020), que podem variar desde uma redução de carga não planejada até a perda total da geração
por falta de insumo. Dada a elevada quantidade de matéria envolvida no processo, é crucial
para as operações desse tipo de negócio a utilização de um sistema de manejo de matéria-prima
eficiente e eficaz, que permita fornecer a máxima quantidade de minério exigida pela produção
de energia e a mínima aquisição combustível sólido para ser estocado. Para que esse “balanço de
massa” ocorra de forma financeiramente satisfatória, são necessárias informações precisas sobre
a quantidade de material que entra e que sai do pátio de armazenamento. Esses dados possuem
várias incertezas e imprecisões, de forma que erros na consolidação de um inventário de um
pátio de carvão podem variar de algumas centenas de toneladas até milhares delas, a dependerde diversos fatores como métodos de medição empregados, periodicidade entre as medições,
calibração de instrumentos e até mesmo a quantidade de umidade absorvida pelo carvão. Dessa
forma, para que seja possível reduzir esse tipo de incerteza, um acompanhamento assertivo do
estoque disponível deve ser realizado.
Considerando as metodologias mais comuns empregadas nesse mercado (e também
na usina), pode-se destacar a medição de vazão mássica de consumo por balança integradora e a
fotogrametria aérea.
21
2.2.1 Balanças dinâmicas
As balanças dinâmicas são dispositivos aplicados na medição contínua de sólidos a
granel em transportadores de correia (GAO; PANG, 2009). Um diagrama esquemático pode ser
visto na Figura 2.
Figura 2 – Balança dinâmica
Fonte: coalhandlingplants (2021).
O funcionamento do aparato é simples: uma estrutura dotada de células de carga,
instalada na face inferior da correia, cria uma zona capaz de monitorar a quantidade de massa
que por ela atravessa. Essa informação é enviada para uma unidade eletrônica, onde é combinada
com o sinal de velocidade linear para obter a taxa de variação da massa no tempo. A unidade
eletrônica integra então todas essas medidas obtidas, o que confere o adjetivo "integradora" ao
equipamento.
Mesmo existindo modelos de balanças que ofereçam erros máximos de 0,5% ou e
até 0,25% do valor lido, é comum que este tipo de instrumento não ofereça esse dado dentro dos
padrões que afirmam seus fabricantes. As fontes desses desvios são variadas e trabalhos como
os de (ZHAO; COLLINS, 2002) e (GAO; PANG, 2009) propõem tratativas para as variações
de saturação em motores de tração, ruídos nos sensores e alterações de temperatura. Erros
de calibração e desvios em ajustes mecânicos como variação da tensão mecânica da correia e
desalinhamento de cavaletes (CONTROLSYSTEMS, 2020) também influenciam negativamente
na medição.
2.2.2 Fotogrametria aérea
Outra metodologia de medição usual consiste na realização de um mapeamento
em três dimensões da região ou objeto de interesse. Nesse quesito, vale apontar uma técnica
bastante difundida: a fotogrametria. A fotogrametria é uma alternativa que pode ser considerada
22
simples e de baixo custo, pois necessita basicamente de uma câmera fotográfica (item padrão dos
aparelhos celulares atuais) e um aplicativo capaz de compor as imagens e reconstruir a superfície
fotografada (diversas opções grátis e suporte multiplataforma). Além disso, a fotogrametria é
extremamente flexível, pois pode ser empregada em aplicações como a prototipagem rápida de
peças (BOCANET et al., 2017), na preservação de artefatos históricos e culturais (MOUSSA,
2014) e no mapeamento e cálculo de pilhas em pedreiras (RAEVA et al., 2016). Em resumo, a
fotogrametria é uma técnica que permite reconstruir a posição, orientação, forma e tamanho dos
objetos a partir de fotografias (VERMEER; AYEHU, 2018). A Figura 3 ilustra o processo.
Figura 3 – Fotogrametria: em objeto (esquerda) e aérea (direita)
Fonte: Esquerda: PixPro (2021) e direita: Leão (2019).
Considerando o caso particular da fotogrametria aérea, uma câmera fotográfica
acoplada a um veículo aéreo permite o mapeamento de grandes áreas, sendo este um recurso
muito aplicado nas ciências geodésicas como a Cartografia e a Topografia. Contudo, a perda de
qualidade e detalhes nas imagens podem ocorrer como consequência da refração atmosférica
causada pelas longas distâncias do solo (VERMEER; AYEHU, 2018) durante a aquisição das
imagens. Nesse caso, caso sejam necessárias fotografias mais precisas do local, é comum o
emprego de um Veículo aéreo não tripulado (VANT) para desempenhar a tarefa.
23
3 FUNDAMENTAÇÃO TEÓRICA
Neste capítulo serão abordados o histórico, a evolução e o estado da arte dos sistemas
de Automação Industrial, bem como o surgimento, crescimento e as tecnologias aplicadas aos
sistemas web.
3.1 A indústria e a Automação Industrial
Entre os séculos XVIII e XIX a fabricação de produtos essenciais, como peças
de vestuário por exemplo, era essencialmente artesanal. As peças produzidas eram rústicas,
possuíam qualidade extremamente variável e a quantidade produzida era limitada. Considerando
a necessidade de atendimento de uma demanda cada vez maior por melhores produtos, o
aumento da produção (e dos lucros por consequência) era uma condição inevitável. Pensando
nessa problemática, os empresários europeus da época (especialmente os resididos na Inglaterra,
país que possuía uma burguesia rica e uma privilegiada localização geográfica que propiciava
condições favoráveis para a exploração do comércio marítimo) investiram no desenvolvimento de
novas máquinas e processos que fossem capazes de atingir esses objetivos. Nessa busca, surgiu
o conceito conhecido atualmente como "indústria de manufatura" e, dado o impacto que este
evento causou na sociedade, o período ficou marcando na história humana com a "Revolução
Industrial"(BRITANNICA, 2021).
Com o passar dos anos, a necessidade de consumo por produtos industrializados
foi crescendo e fez com que a importância da indústria, dentro de um contexto global, também
crescesse na mesma proporção. Esses produtos, de uma forma geral, ofereciam comodidade e
entretenimento. Aliado a isso, descobertas realizadas em áreas como Medicina e Engenharia
também foram materializadas pela indústria, propiciando assim melhorias significativas na
condição de vida das pessoas. Essas melhorias permitiram uma maior longevidade ao ser humano,
que descobriu que o seus bens mais valiosos são o seu tempo livre e bem-estar (CHADEEV;
ARISTOVA, 2017).
Mesmo a indústria oferecendo um suporte essencial para a evolução da sociedade
e dispondo de máquinas e linhas de produção automáticas, muitas atividades desenvolvidas
no chão de fábrica são extremamente dependentes de intervenção humana e é inegável que
os processos fabris possuam ambientes e situações perigosas que oferecem riscos das mais
variadas naturezas e níveis. Esse tipo de situação já tinha sido ludicamente retratada no filme
24
"Tempos Modernos" de Charles Chaplin. Como resultado, esse cenário forneceu subsídios
para uma escalada na quantidade de acidentes de trabalho do setor (MONTHLYLABOR, 1951).
Considerando a preservação da saúde dos trabalhadores sem causar interferências negativas nos
níveis de produção (e nos lucros adquiridos por consequência), melhorias que garantissem que a
exposição de pessoas a tarefas repetitivas e perigosas deveriam ser implantadas. Surgia assim o
cenário para o desenvolvimento da Automação Industrial, nos moldes que é conhecida hoje.
3.1.1 Sistemas automatizados - o estado da arte
Na década de 1950, os controladores automáticos (pneumáticos, hidráulicos, mecâ-
nicos e elétricos) estavam completamente integrados em vários nichos da atividade industrial.
Eram controladores simples e que atuavam em uma única variável, porém, eram poderosos
o bastante para implementar uma lógica de controle com o princípio Proporcional, Integral e
Derivativo (PID) nos sistemas que controlavam. Contudo, foi apenas em 1959 que os primeiros
exemplares completamente eletrônicos foram amplamente fabricados e aceitos pelo mercado.
Além de possuírem todas as funções implementadas pelas suas contrapartes eletromecânicas já
existentes, os novos dispositivos possuíam habilidades mais aprimoradas como a capacidade de
executar soma, multiplicação, potenciação e outras operações matemáticas diversas (BENNET,
2000).
Mesmo sendo totalmente possível controlar plantas inteiras com esse tipo de equipa-
mento, a combinação dessa abordagem com a dificuldade em implementar alterações na lógica
funcional dos processos (originária do emprego de longas e complexas cadeias de circuitos
de relés), elevavam os custos de produção e do produto final, pois requisitavam mais tempo
de trabalho e uma maior quantidade de material para concluir até as mais simples mudanças.
Além disso, essas tecnologias não conseguiam suprir o nível de segurança mínimoconsiderado
adequado para as pessoas. Dessa forma, ao final da década de 1960 surgiu o Controlador Lógico
Programável (CLP), um dispositivo baseado em semicondutores que permitia que complexas
mudanças físicas fossem substituídas por simples alterações lógicas, desenvolvidas em um tipo
de linguagem que todo especialista em eletrônica na indústria conhecia e utilizava bem (SAN-
VER et al., 2018) - o Ladder. Dada essa flexibilidade, foi possível reduzir custos e automatizar
tarefas que colocavam em risco a integridade física dos operários, tornado o CLP como padrão
de facto para sistemas de controle automatizados. A Figura 4 mostra o Modicon 084, o primeiro
CLP já produzido, ao lado de suas contrapartes modernas.
25
Figura 4 – Modicon 084 (esquerda) e CLPs modernos
(direita)
Fonte: Esquerda: Ferraz (2018) e direita: Schneider (2021), Siemens
(2021) e Alibaba (2021).
Com os avanços tecnológicos ocorridos nos ramos da Eletrônica e da Computação,
dispositivos cada vez mais poderosos e uma maior diversidade de acessórios permearam a área
produtiva, possibilitando a expansão das funcionalidades e capacidades dos CLPs. Um dos
acessórios que merece destaque é a Interface Homem-Máquina (IHM) 1, que é um equipamento
que disponibiliza uma interface gráfica capaz de conectar pessoas a máquinas (INDUCTIVEAU-
TOMATION, 2018). Nessa interface é apresentada uma reconstrução animada do processo como
forma de facilitar o controle e simplificar a identificação de falhas ou outras condições adversas
indesejadas. Nos modelos mais modernos, versões simplificadas de sistemas operacionais,
funcionalidades de data logger 2 e notificações por email também estão disponíveis. A IHM
típica é ilustrada na Figura 5.
Figura 5 – IHM: gráfica (esquerda) e textual (direita)
Fonte: Esquerda: AUTOMATIONDIRECT (2020) e direita: Esis (2021).
1 Human Machine Interface (HMI) em língua inglesa
2 Data logger é um instrumento que monitora e registra alterações em condições ao longo do tempo (OMEGA,
2018).
26
Aplicações que empregam um dueto composto de CLP e IHM são extremamente
simples e funcionais e podem ser consideradas como "base" para qualquer sistema automatizado.
Contudo, esse tipo de solução cria "ilhas" de controle e informação, pois requer que o controlador
seja instalado próximo ao sistema controlado ao custo de "confinar" os dados gerados nas
imediações do processo local. Além disso, os modelos mais simples e antigos de IHM eram
monocromáticas e apresentavam apenas informação textual. Isso reduz o tempo de reação
dos operadores no caso de eventos de falha pois textos necessitam do sistema cognitivo e da
memória, ao contrário dos estímulos visuais que operam no nível do sistema perceptual humano
(MUNZNER, 2014). Nesse caso, painéis sinóticos poderiam ser empregados, porém, mesmo
com um elevado número de fios no painel (a depender do número de sensores envolvidos) a
quantidade de dados era mínima e a qualidade rudimentar (BAILEY; WRIGHT, 2003). Esse foi
o mote para a criação dos fieldbuses.
O barramento de campo, ou fieldbus, foi a solução encontrada para esse problema.
Por meio de combinação entre camadas processamento de software e interfaces físicas interco-
nectadas, era possível criar uma rede de dados capaz transportar informações entre os vários
CLPs distribuídos pela fábrica e estender a distância existente entre um controlador e sua IHM.
Classicamente, a camada física era formada por interfaces elétricas RS-485 e as ligações empre-
gavam cabos de pares trançados ou fibras ópticas (a depender da distância envolvida) conectadas
em "linha" ou "barra", garantindo o nome "barramento" ao arranjo. Já para a troca de dados,
foram desenvolvidos protocolos de comunicação industriais. Esses protocolos podiam ser abertos
(pode ser implementado por qualquer pessoa, sem custos) ou proprietários (desenvolvidos ou
geridos por uma organização, necessário pagar licença). Dentre os mais populares é possível
citar o Modbus, Profibus, AS-i e o Hart. Nos últimos anos, a interface Ethernet despontou como
novo padrão elétrico e as conexões sem fio são cada vez mais aplicadas no chão de fábrica. A
Figura 6 mostra um arranjo clássico de uma rede industrial.
Mesmo após todos os avanços e novas tecnologias, o desafio do gerenciamento da
informação criada no chão de fábrica ainda permanecia presente. Respostas para as perguntas:
com que velocidade o produto "x" é fabricado ou qual é o nível de perda da máquina "y" são
cruciais para o desenvolvimento de um plano de investimento assertivo, capaz de maximizar
lucros e minimizar perdas. Nesse sentido, utilizando os barramentos de campo e seus protocolos
de comunicação, surgiram os Distributed Control System (DCS) 3 e os Supervisory Control
3 Plataforma automatizada que combina IHM, solucionadores lógicos, historiador, gerenciamento de alarmes,
banco de dados e aplicativos de engenharia em ambiente único (YOKOGAWA, 2021)
27
Figura 6 – Arranjo clássico de rede industrial
Fonte: Autor - adaptado de Reynders et al. (2005).
and Data Aquisition (SCADA) 4, formando a base dos sistemas automatizados disponíveis na
atualidade. Apesar de apresentarem propostas funcionais diferentes, ambas plataformas aplicam
o princípio de aquisição de dados como a característica mais relevante do sistema pois, além de
eliminar a necessidade de coletar manualmente as informações da planta, reduz o tempo para
que sejam criadas correlações entre essas informações coletadas. Essa situação cria condições
para remover gargalos e atingir substanciais ganhos de produção (MACKAY et al., 2004). A
Figura 7 ilustra uma arquitetura típica dos sistemas de automação modernos.
Figura 7 – Arquitetura típica de um sistema automatizado
Fonte: Electrical4U (2020).
Na ilustração, é possível identificar que todos os equipamentos responsáveis pelo
4 É um tipo de sistema de controle que a arquitetura utiliza computadores, troca de dados via rede e interfaces
gráficas que permitem controle e gerenciamento de alto nível em processos industriais (MUTHUKRISHNAN,
2021)
28
controle do processo fabril estão na base: sensores, atuadores e controladores. Esses dispositivos
estão distribuídos dentro da planta e todas as informações oriundas deste nível são transportadas
pelas redes de dados de controle - fieldbuses - compostas por enlaces cabeados empregando
protocolos de comunicação como: Modbus, Profibus, Profinet e Ethernet/IP. No nível inter-
mediário, estão alocados os servidores de aplicação, os servidores de bancos de dados e os
sistemas SCADA. Todo o gerenciamento de alarmes, histórico de eventos e controle remoto
de processos é realizado neste nível. Vale destacar uma característica comum das plataformas
SCADA comerciais utilizadas neste nicho: a falta de interoperabilidade entre componentes. Essa
situação dificulta e por vezes inviabiliza a troca de dados nesse nível. O topo da hierarquia está
relacionado com o nível gerencial. Neste ponto, as informações adquiridas do campo e salvas no
controle de processo, podem ser replicadas em sistemas do tipo Enterprise Resource Planning
(ERP) e utilizadas para acompanhar a saúde financeira do negócio ou como fator de decisão para
o desenvolvimento de novos planos de investimento, quer estes sejam de curto, médio ou longo
prazo.
Mesmo o conjunto formado por SCADA, redes, CLP e sensores sendo a configuração
padrão dos sistemas industriais modernos, as necessidades geradas a partir das constantes mu-
danças nas percepções humanas requerem que novos tipos de abordagem sejam incluídas nessas
tecnologias. Dentre essas necessidades, é possível citar a disponibilização das informações
oriundas do processo de produção em dispositivos e plataformas variadas (computadores, tablets,
telefones móveis, aplicativos web, etc) e a inclusão de realidade aumentada. Nesse sentido,
os grandes fabricantes mundiais enfrentam dificuldades pois, além do elevado investimento
financeiro envolvido, a adoção de um modelo de negócio que dependade menos aplicativos ou
equipamentos proprietários gera menos receita. Com isso, evoluções mais lentas são presencia-
das.
Contudo, pesquisadores independentes continuam a desenvolver trabalhos para esses
casos: (NICOLA et al., 2018) apresenta uma aplicação que democratiza os dados de processo
pela integração entre servidores web e sistemas de controle industriais via protocolo OPC
e (BYVALTSEV, 2020) discute os avanços, aspectos e impactos da utilização de realidade
aumentada na indústria.
29
3.2 Tecnologias, arquiteturas e serviços web
Em 1989, o pesquisador do Conselho Europeu de Pesquisa Nuclear (CERN) Tim
Berners-Lee escreveu um documento intitulado "Information Management: A Proposal". Esse
documento continha uma abordagem para um problema crescente dentro do centro de pesquisa
nessa período: a constante perda de informação de seus projetos. De acordo com o texto, a
causa raiz para essa falha era a frequente troca de pessoas nos times de pesquisa. No geral,
não era a total inexistência de documentação a maior preocupação, mas sim a dificuldade em
identificar onde essa documentação estava guardada, já que eventualmente esses arquivos eram
encontrados. Outro fator que contribuía para o problema era que o CERN funcionava como
uma grande "teia de aranha", onde suas interconexões evoluíam com o tempo (BERNERS-LEE,
1989) e as pessoas novas que entravam também precisavam de algum tempo para se habituarem
e entenderem onde poderiam encontrar as informações e os recursos que necessitavam para
desenvolver seus trabalhos. Mesmo rejeitando inicialmente a ideia e escrevendo a nota "vago mas
excitante" na capa do documento, em Setembro de 1990 o chefe de Tim, Mike Sendall, autorizou
que seu subordinado trabalhasse no assunto. Como resultado do trabalho, em Outubro do mesmo
ano, Tim desenvolveu os três conceitos fundamentais que formam a base dos sistemas web
atuais: a linguagem HyperText Markup Language (HTML), o identificador Uniform Resource
Identifier (URI) e o protocolo HyperText Transfer Protocol (HTTP). Além disso, ele escreveu
também o primeiro navegador (chamado de WorldWideWeb) e o primeiro servidor web (o httpd)
(WEBFOUNDATION, 2021). Seguindo no projeto, em Novembro de 1990 a primeira página
web foi posta em operação (CAILLIAU, 1995). A Figura 8 mostra uma imagem do navegador e
da página criada.
Esses eventos formam o prelúdio da grande e interligada rede de computadores
conhecida apenas como internet hoje. Com a criação do World Wide Web Consortium (W3C)
em 1994, uma comunidade totalmente dedicada ao desenvolvimento de padrões abertos para a
web, as tecnologias criadas por Tim Berners-Lee (que lidera até hoje a organização) puderam ser
abertas ao público geral que rapidamente encontrou formas de expandir essas ideias, criando
novas tecnologias que permitiam melhorar a experiência das pessoas durante a navegação,
tornando-a mais rica e interativa. Nasciam assim as sucessivas revisões do HTML e a criação
do Cascading Style Sheets (CSS), Extensible Markup Language (XML), Secure Sockets Layer
(SSL), JavaScript, Flash, Asynchronous JavaScript e XML (AJAX) e outros que incluíram uma
gama de conteúdos, funcionalidades e serviços (EVOLUTIONOFTHEWEB, 2012).
30
Figura 8 – Primeiro navegador e página web
Fonte: Cailliau (1995).
3.2.1 O JavaScript
Inicialmente, os portais da web eram construídos em puro HTML, o que tornava
todo o conteúdo destas páginas estático. Isso quer dizer que para alterar ou atualizar qualquer
característica de uma página que já estava apresentada na tela do computador cliente (cor,
formato, texto, figura ou até uma nova página), era necessária uma nova interação com a máquina
servidora, pois um novo documento HTML com o formato desejado deveria ser enviado e
processado. Esse excesso de interações entre cliente e servidor elevava o tempo necessário para
realizar algumas tarefas simples (como preencher um formulário) e reduzia a responsividade
dos portais da internet, quando comparados com os aplicativos desenvolvidos para desktop.
Considerando a necessidade de aprimorar essa experiência do usuário, em Novembro de 1995 a
equipe desenvolvedora do Netscape Navigator criou uma nova linguagem chamada de LiveScript
para seu navegador. Essa linguagem possuía dois propósitos básicos: fornecer subsídios para que
administradores web gerenciassem seus servidores e conectassem suas páginas a outros serviços
(bancos de dados por exemplo) e permitir que os desenvolvedores de portais incluíssem novas
funcionalidades do lado do cliente que reduzissem a necessidade de troca de dados entre este e o
servidor (GOODMAN, 2001). Em Dezembro de 1995, o LiveScript foi renomeado e lançado
publicamente como JavaScript.
O JavaScript é uma linguagem leve, interpretada, que possui funções de primeira
classe (MDN, 2020) e que se tornou o padrão de facto na criação de sites para a web. De
acordo com a pesquisa de 2020 realizada pelo portal Stack Overflow, 67,7% das pessoas que
31
participaram do processo afirmaram que utilizam JavaScript de forma regular. Esse resultado
garantiu pelo oitavo ano seguido a hegemonia do JavaScript como linguagem de programação
mais comum da web (STACKOVERFLOW, 2020). Um resultado semelhante também pode ser
visto na plataforma colaborativa GitHub, como pode ser visto na Figura 9.
Figura 9 – Linguagens mais utilizadas durante os anos
Fonte: GitHub (2020).
Mesmo sendo o "padrão da web" da atualidade, o JavaScript enfrentou muitos desa-
fios de aceitação, dada sua natureza prolixa e problemas de incompatibilidade entre navegadores
(DEGROAT, 2019). Foi então que em 2005, Jesse James Garrett apresentou uma proposta de
abordagem utilizando múltiplas tecnologias, onde o JavaScript possuía um papel fundamental na
integração de todos estes aplicativos. O artigo foi intitulado de "Ajax: A New Approach to Web
Applications" e descrevia um modelo que permitia que páginas da web trocassem informação
com servidores de forma assíncrona, ou seja, sem a necessidade de atualização do que está sendo
apresentado e contrastando com o modelo síncrono tradicional ou clássico empregado até aquele
momento. Com um interesse renovado sobre o assunto, a comunidade de desenvolvedores criou
frameworks (como o JQuery) e bibliotecas que facilitavam o uso da linguagem e a criação de
portais interativos. A Figura 10 mostra um comparativo entre os dois modelos abordados.
3.2.2 Arquitetura baseada em serviços e serviços RESTful
Como comentado na seção 3.2.1 e ilustrado na Figura 10, a arquitetura clássica
utilizada em sistemas web consiste na utilização de um aplicativo conhecido como navegador
(ou browser em inglês) instalado na máquina cliente que solicita páginas, programas ou mídias a
uma máquina servidora, que por sua vez responde as requisições do cliente com as informações
ou arquivos desejados. Essa arquitetura é simples e funcional, porém, quando aplicada nesse
32
Figura 10 – Modelo tradicional x modelo Ajax
Fonte: Garrett (2005).
contexto enfrenta dificuldades quanto a escalabilidade e o desenvolvimento e integração de
componentes (FIELDING, 2000). Essas dificuldades ocorrem devido a aplicação ser monolítica,
ou seja, os componentes da aplicação são logicamente separados, porém são implementados
como um único grande programa e essa abordagem torna mais difícil para substituir ou adaptar
componentes sem afetar todo o sistema (TANENBAUM; STEEN, 2007), em especial quando
considerados os sistemas de grande porte como os bancários ou industriais. Estas limitações
de performance e usabilidade levaram ao desenvolvimento do Service Oriented Architecture
(SOA), um estilo arquitetural destinado à construção de soluções empresariais baseadas em
serviços (ROSEN et al., 2008). Contudo, o SOA possui uma forte tendência de ser dependente de
Enterprise Service Bus (ESB) (RIZKI et al., 2020) ou outras tecnologias, sendo elas proprietárias
em vários casos.
Essas dificuldades e limitações levaram Roy Thomas Fielding apropor em sua tese
de doutorado um novo estilo arquitetural que possuía a capacidade para tratar essas condições
indesejadas: o REST. Essa metodologia definia claramente os papéis de clientes e servidores
dentro desse contexto e reforçava a separação das tarefas em serviços independentes, que por sua
vez eram integrados de uma forma simples e familiar para os desenvolvedores, pois empregava
uma formatação padronizada de URI e o HTTP como protocolo de transporte (mesmo sem ter
sido criado para este fim), em detrimento de outras tecnologias proprietárias. Outra vantagem
dessa abordagem estava no fato de ser possível criar uma API para a rede, pois disponibilizaria um
conjunto de pontos de entrada (entry points) e seus respectivos conjuntos de símbolos/parâmetros
33
associados, de tal sorte que um programador pudesse utilizar o código de outro, desde que
fossem respeitadas as restrições criadas (FIELDING, 2000). Quando existe uma combinação
dessas duas metodologias, ou seja, uma API REST, o resultado é chamado de serviço RESTful.
A Figura 11 mostra um diagrama simplificado de uma API REST.
Figura 11 – Exemplo de API REST
Fonte: adaptado de Massé (2012).
Na figura, é interessante apontar que estão sendo disponibilizados vários serviços
independentes. Esses serviços podem estar contidos em um mesmo servidor ou distribuídos em
servidores diferentes, dentro da estrutura de backend. Mesmo operando com apenas um único
servidor, é possível obter a individualização dos serviços, de forma que falhas ou alterações
em um deles não comprometa a funcionalidade dos demais. Dentro deste escopo, é possível
considerar duas alternativas: a virtualização de hardware e software através de máquinas virtuais
ou a utilização de containers, opção que será discutida na seção 3.2.3.
3.2.3 Tecnologia de containers e aplicações web
Com as sucessivas melhorias e avanços tecnológicos que os dispositivos eletrônicos
sofreram nas últimas décadas, sistemas computacionais começaram a despontar como solução
para diversos tipos de problemas enfrentados. O sistema de localização geográfica por Global
Positioning System (GPS), os sistemas de controle industriais com CLPs e aplicativos SCADA e
a própria internet com seus variados tipos de serviços podem ser citados como exemplos. No
caso particular da internet, de acordo com a Figura 12 extraída do portal ourworldindata.org, em
2016 já existiam 3,4 bilhões de pessoas com acesso a rede mundial de computadores, sendo este
valor aproximadamente 46% da população total do planeta nesse mesmo ano (WORLDBANK,
2021).
Considerando o contexto do atendimento dessa demanda sempre crescente por
34
Figura 12 – Número total de pessoas utilizando a internet
Fonte: adaptado de Roser et al. (2015).
recursos, é simples concluir que a escalabilidade é uma característica fundamental para o sucesso
de uma plataforma web. Um sistema é dito escalável caso ele permaneça funcional quando
ocorrer um aumento expressivo no número de recursos e no número de usuários (COULOURIS
et al., 2012). Porém, independente do fato de ter sido implantado um conceito escalabilidade
vertical (servidor com mais poder de processamento e maior capacidade) ou horizontal (mais
servidores atendendo requisições de uma mesma tarefa), existe um custo financeiro envolvido
que é diretamente proporcional a capacidade que se deseja dar ao sistema. Com isso, duas
alternativas foram desenvolvidas: a virtualização e o emprego de containers.
Virtualização na computação normalmente se refere a uma abstração de um compo-
nente físico em um objeto lógico (PORTNOY, 2016). Isso quer dizer que uma máquina física
pode ter todas as suas características de hardware e sistema operacional guardados em um único
arquivo denominado de imagem, que por sua vez pode ser posteriormente executado por um
aplicativo especial, comumente chamado de máquina virtual ou Virtual Machine (VM). A Figura
13 mostra um diagrama de um computador real executando máquinas virtuais.
Figura 13 – Máquina real executando máquinas virtuais
Fonte: Autor (2021).
De acordo com a figura, é possível perceber que máquinas virtuais possuem uma
35
cópia digital de todas as partes que as máquinas reais possuem. É interessante notar também a
existência do hypervisor, um aplicativo instalado no sistema operacional hospedeiro (host OS)
responsável pelo gerenciamento das VMs e o acesso aos recursos físicos do computador. Esse
tipo de abordagem permite a criação de diversas máquinas virtuais completamente funcionais e
independentes dentro de uma única máquina real. Porém, é simples concluir que a capacidade de
processamento da máquina real é um fator que limita fortemente a quantidade de máquinas virtu-
ais que podem ser disponibilizadas para execução simultânea, dado o fato que cada virtualização
possui sua cópia particular de um conjunto de hardware e sistema operacional.
Nesse âmbito, outra tecnologia semelhante às VMs que merece atenção são os
containers. Containers são instâncias executáveis de uma imagem, que nesse caso específico,
possuem uma versão reduzida de um sistema operacional e todas as dependências necessárias
para executar uma dada aplicação (POULTON, 2018), porém, sem a necessidade de integrar
as informações de hardware. O controle e o gerenciamento dos containers é realizado por um
aplicativo chamado de container engine. A Figura 14 ilustra o diagrama de blocos simplificado
do processo.
Figura 14 – Máquina real executando containers
Fonte: Autor (2021).
Como pode ser visto na figura, as imagens dos containers possuem idealmente o
aplicativo que se deseja executar e suas dependências. Esse fato, reforçado pela cópia seletiva
do Sistema Operacional (SO) convidado, garantem que menos espaço no disco rígido seja
utilizado. Outra vantagem que merece destaque é a menor dependência de elevadas capacidades
de memória e processamento da máquina real. A combinação dessas características pode ser
entendida como menor investimento por aplicação específica disponibilizada.
Essa situação de menor custo por plataforma específica forma uma condição ideal
para o desenvolvimento e disponibilização de sites da web. Dentre as várias opções disponíveis, o
36
Docker tem sido uma opção bastante difundida e empregada pelos desenvolvedores na atualidade,
sendo suportado por grandes empresas como a Amazon, Google e RedHat (BELAGATTI, 2020).
Por esses motivos e por possuir uma versão sem restrições de uso sem necessidade de custos
extras, o Docker foi escolhido como uma das soluções que compõem este trabalho.
37
4 METODOLOGIA
Neste capítulo será apresentada metodologia utilizada para tratar o problema da área
alvo, bem como a metodologia aplicada no desenvolvimento da plataforma proposta.
4.1 A solução de monitoramento proposta
De acordo com o exposto nas seções 1.1 e 2, fica clara a necessidade de um acompa-
nhamento cuidadoso do estoque contido no pátio de carvão da EDP Pecém. Atualmente, esse
inventário é realizado combinando as informações do laudo de arqueação 1 oficial do navio (como
entrada de estoque) e as leituras das balanças dinâmicas instaladas nas correias transportadoras
internas (como saídas de estoque). Esses dados fornecem insights da dinâmica de consumo
diário das unidades de geração (UG). Ao final de cada mês, ocorre uma consolidação de todo
esse acompanhamento: são realizadas uma fotogrametria aérea e uma densimetria das pilhas no
pátio de carvão, a fim de determinar a quantidade real de insumo restante. Da comparação de
todas essas informações e da previsão de despacho do ONS, é gerado um relatório que norteia a
estratégia de compra de carvão. Dito isso, é simples perceber que esse método é excessivamente
manual e possui fontes variadas de erros, que podem ser resumidas basicamente por problemas
na instrumentação, falhas nos apontamentos dos dados de entrada e saída de material e elevado
intervalo de tempo entre cada fotogrametria. Para os piores casos, em alguns fechamentos anuaispodem ser detectadas divergências de milhares de toneladas.
Com essa problemática em mente, o Grupo de Pesquisa Automação, Controle e
Robótica (GPAR) da Universidade Federal do Ceará (UFC), propôs uma solução para essa
situação: o desenvolvimento de uma plataforma automática de coleta e gerenciamento dos dados
do pátio de carvão. A arquitetura simplificada do sistema é apresentada na Figura 15.
Como pode ser visto na figura, a plataforma é formada basicamente por um sistema
aéreo de varredura e um servidor de dados. Nas próximas seções, serão discutidos com mais
detalhes cada um dos componentes.
1 Cálculos hidrostáticos para determinação da quantidade de carga embarcada ou desembarcada de um navio
(LOPES, 2017).
38
Figura 15 – Arquitetura simplificada do sistema proposto
Fonte: Autor (2021).
4.2 Sistema de varredura aérea
O sistema de varredura aéreo, apresentado na Figura 16, possui como principal
função a captura da geometria das pilhas de carvão. Com essa geometria bem definida, é
possível estimar o volume contido no pátio que, ao ser combinado com os dados fornecidos pela
densimetria, torna simples o cálculo da quantidade de matéria armazenada. Esse módulo de
aquisição é composto por um VANT, um computador embarcado e um sensor Light Detection
and Ranging (LiDAR). Esse sensor, que é um dispositivo capaz de medir distâncias até um objeto
emitindo feixes de laser e processando a onda refletida (AMANN et al., 2001), foi selecionado
pela equipe de projeto por possuir uma alta a capacidade de mapeamento, oferecendo uma nuvem
de pontos 2 de alta densidade, capaz de reproduzir as mais tênues variações do terreno, mesmo
na existência de interferências como poeira e gotículas de água suspensas no ar (SICK, 2021).
Para a aplicação em questão, foi utilizado o sensor 3D LD-MRS de fabricação SICK AG.
O computador embarcado (ASUS Tinker Board) faz a fusão das informações da
nuvem de pontos, da Inertial Measurement Unit (IMU) e do GPS, de forma que esses pontos sejam
georreferenciados. Além disso, métodos matemáticos como os filtros de Kalman e operações
2 Trata-se basicamente de um conjunto de pontos em um sistema 3D de coordenadas, normalmente definidos por
coordenadas x, y, e z (SCIENCEDIRECT, 2021).
39
Figura 16 – Sistema de varredura aérea
Fonte: Autor (2021).
com quatérnions para normalização, translação e rotação dos pontos foram implantados por
(FORTE, 2018) e (SANTOS et al., 2019) respectivamente. Outra função desse computador é
estabelecer comunicação com a instrumentação interna do VANT, com o LiDAR via Robot
Operating System (ROS) e com o servidor de aplicação. O ROS é um sistema de código aberto e
meta operacional 3 que disponibiliza ambientes de desenvolvimento especializados diversos para
o desenvolvimento de aplicações robóticas (PYO et al., 2017).
Para o controle e acompanhamento do Wind 4 (quadricóptero de fabricação DJI)
durante as missões de varredura, um aplicativo Android foi desenvolvido para trocar dados com
o VANT por um link especial disponibilizado pelo controle remoto da aeronave. É interessante
apontar que informações como umidade relativa do ar e velocidade do vento, sinais provenientes
da estação meteorológica integrante da automação existente no local, são consideradas para a
liberação de decolagem da aeronave.
4.3 Servidor de aplicação
No servidor de aplicação estão alocados uma série aplicativos essenciais para o
completo funcionamento do sistema automatizado proposto. O ambiente ROS comunica com
sua contraparte para adquirir os dados de instrumentação e as nuvens de pontos adquiridas pelo
VANT. Em seguida, as nuvens passam por um pré-processamento automático onde os pontos
3 Um sistema que executa processos como agendamento, carga, monitoramento e gerenciamento de erros utilizando
uma camada de virtualização entre as aplicações e os recursos computacionais distribuídos (PYO et al., 2017).
40
são filtrados e segmentados, são criados os sólidos e calculados os volumes das pilhas. Como
opção, ferramentas em Python foram criadas para permitir que um usuário edite as nuvens de
forma manual, caso seja desejado.
Outra funcionalidade consiste em hospedar o servidor da ISAA, aplicativo web
desenvolvido como plataforma de gestão dos dados do pátio de carvão (SOUSA, 2020).
Por fim, estão instalados também um aplicativo responsável por comunicar com a
estação meteorológica, parte integrante do sistema de automação existente na usina, os serviços
web, que fornecem dados para todas as diferentes necessidades e interfaces do sistema proposto
e o servidor de bancos de dados, que possui a tarefa de salvaguardar todas as informações
provenientes de todas as fontes que chegam ao servidor. Todas essas últimas funcionalidades
citadas, serão tratados com mais detalhes nas seções a seguir.
4.4 Serviços back-end do sistema de volumetria aérea
Como pôde ser visto na seção 4.1, o sistema de volumetria aéreo é composto
por variados componentes e tecnologias, quer estes sejam de hardware ou software. Essa
diversificação é oriunda dos desafios enfrentados por cada equipe de desenvolvimento e os
objetivos finais que estas pretendiam alcançar. Contudo, era mandatória a necessidade de
integração dessas entidades, visto que todas as informações deveriam ser reunidas de forma que
fossem facilmente acessadas pelos usuários finais. Nesse aspecto, as soluções SCADA comerciais
não poderiam ser empregadas pois não oferecem suporte direto para esse tipo de condição mais
específica de diversidade. Além disso, outro agravante para a adoção de um sistema automação
comercial reside no fato de esses aplicativos são, em sua grande maioria, desenvolvidos para
o SO Microsoft Windows, ao contrário do sistema proposto que é completamente baseado em
Linux.
Uma possível solução para essa questão consistia em construir um middleware 4
dedicado para esse contexto. Esse programa poderia ser mais abrangente como proposto por
(BLAGA, 2007) ou mais simplista e direto como o de (SCHOLL; ROCHA, 2016). Dado fato que
todos os componentes da aplicação possuírem capacidade de comunicar via HTTP e do ISAA
ser um aplicativo web, um direcionamento mais alinhado com a primeira opção foi adotado.
Para o caso específico dos dados adquiridos, criados ou consumidos pelos compo-
4 É um software que fornece serviços e recursos comuns a aplicações (REDHAT, 2021), criando uma camada que
mascara a heterogeneidade existente entre redes, hardware, sistemas operacionais e linguagens de programação
(COULOURIS et al., 2012).
41
nentes do sistema de volumetria aérea, ocorre que uma grande parcela dessas informações não é
utilizada no exato momento que é gerada. Com isso, o sistema deve oferecer um mecanismo de
persistência que seja suportado por diferentes linguagens e que garanta que os dados julgados
como importantes não sejam perdidos. Dada a característica web da aplicação outrora discutida,
uma alternativa clássica trata da implantação de um sistema de banco de dados relacional ou
Relational Database Management System (RDBMS) na lingua inglesa. Esse tipo de programa
permite que o usuário crie, atualize e administre bases de dados de forma que estas sejam
facilmente acessíveis (CODECADEMY, 2021). Contudo, a presença das diferentes linguagens
de programação envolvidas (C++, Python, Java e Javascript) requerem soluções individuais e
particulares para o acesso ao banco de dados (BD). Essa situação cria dificuldades extras tanto
para o desenvolvimento quanto para a manutenção da plataforma automatizada, pois exige que
o desenvolvedor incorpore em seu código as requisições e respostas enviadas ao BD e que o
mantenedor seja mais especializado para executar a sua tarefa.
Considerando essa problemática, foi criado um serviço RESTful para permitir que
a plataforma ISAA tivesse acesso ao banco de dados. Essa abordagem garante uma completa
abstração do BD, não sendo necessário assim qualquer tipo de conhecimento prévio sobre
as particularidades deste e permitindoainda que qualquer linguagem que opere com simples
métodos HTTP troque mensagens, independente se estas sejam de leitura ou de escrita. Esse
tipo de aplicação é semelhante às proposições de (MEDRANO et al., 2018) e (HIRANKITTI,
2019). Dada a flexibilidade promovida pelo estilo arquitetural adotado, a solução foi expandida
para outros aplicativos que habitam no backend da plataforma de aquisição, dentre eles é
interessante apontar o código que implementa a interface de comunicação com a automação
existente, o de recepção, guarda e busca de nuvens de pontos, a lógica que recebe e salva os
sinais oriundos da instrumentação interna do VANT e os aplicativos de configuração e controle
do banco de dados. Nessa condição, mesmo considerando a existência de diversos serviços
completamente independentes, a aplicação ainda possuia um forte alinhamento monolítico, dadas
as interdependências entre os blocos que a compõem. Um diagrama ilustrativo é apresentado na
Figura 17.
Mesmo sendo uma opção completamente funcional, a operação da plataforma nessa
configuração pode se tornar instável quando ocorrer a concorrência por recursos de proces-
samento e memória durante períodos de elevada utilização. Esses eventos podem levar a um
colapso que gere a perda total de funcionalidade, nos piores casos.
42
Figura 17 – Arquitetura inicial do backend
Fonte: Autor (2021).
Dessa forma, visando promover uma maior tolerância às falhas e a outras condições
operacionais restritivas, quer estas sejam adversas ou planejadas, foi incorporada a tecnologia
de containers na plataforma. Encapsulando os módulos funcionais auxiliares e de serviço
em ambientes virtuais que exijam um baixo custo computacional, é possível garantir uma
completa independência entre todas as partes. Além disso, é possível mover completamente
um serviço qualquer de uma máquina física para outra sem a necessidade de realizar nenhuma
configuração extra, pois o ambiente contido já está completamente preparado. Outra vantagem
dessa abordagem consiste na possibilidade de replicar um mesmo serviço quantas vezes forem
necessárias, a depender da capacidade computacional da máquina hospedeira. Essa estratégia
pode ser implementada em uma mesma máquina ou em várias máquinas diferentes, permitindo
elevar a disponibilidade individual de cada componente e a velocidade final de resposta do portal,
sendo que mais instâncias de um mesmo serviço estarão disponíveis para atender as solicitações
dos usuários. Para a aplicação em questão, foi empregado o Docker para a tarefa de gerenciar e
controlar os containers criados. A Figura 18 mostra a arquitetura final proposta.
Com isso, é possível afirmar que uma arquitetura baseada em microsserviços foi
instituída. As seções a seguir descreverão com mais detalhes cada módulo funcional apresentado.
43
Figura 18 – Arquitetura final do backend do ISAA: baseada em microsserviços
Fonte: Autor (2021).
4.5 ISAA DB Server
Dada a quantidade de dados criada e consumida por todos os módulos funcionais,
aliado ao fato de que esse consumo pode ocorrer de forma assíncrona e dependente eventos, quer
estes sejam disparados automaticamente ou pelos usuários, mostrou que a aplicação possuía a
necessidade de promover a implantação de um mecanismo capaz de salvaguardar e recuperar
essas informações quando fosse desejado. Em aplicações industriais e web, é comum aplicar um
banco de dados relacional para desempenhar esse papel. No sistema de aquisição proposto, o
BD escolhido foi o MariaDB.
A escolha do MariaDB como servidor de banco de dados foi fundamentada nas
suas características: é um aplicativo de código aberto, sem custos de utilização ou licenças
(para o caso em questão) e é suportado por diversos provedores de serviços web, incluindo a
Amazon Web Services e o Google Cloud Platform. Além disso, o MariaDB foi criado pelos
mesmos desenvolvedores do MySQL (MARIADB, 2021), o que confere compatibilidade entre
plataformas e uma sólida base de conhecimento sobre o assunto. Outro fator contribuinte, foi a
utilização desse tipo de servidor pelo sistema SCADA atualmente utilizado pelos transportadores
44
de correia.
O esquema do banco de dados é apresentado na Figura 19. As tabelas foram criadas
de forma a atender as necessidades gerais de cada aplicativo, com as informações organizadas de
forma simples e intuitiva. A função de cada tabela é apontada na Tabela 1.
Tabela 1 – ISAA DB Server: Tabelas e suas funcionalidades
Nome Função
types list Lista contendo tipos de registro enviados pelo ISAA
status list Lista de estados de validade da varredura do drone
pcd Dados adquiridos pelo drone durante missão de varredura
drone data Dados gerais do drone e das missões
volume Volume das pilhas calculado pelo aplicativo de tratamento de nuvem de pontos
density Densidade declarada/medida das pilhas de carvão
mass Dados de massa diários gerados de forma manual ou automática
masss totalized Massa das pilhas totalizadas automaticamente (regime diário)
last mass reference Massa considerada como "última referência válida"
last density reference Densidade considerada como "última referência válida"
latest register Listagem de registros gerados/declarados para consultas rápidas do ISAA
Fonte: Autor (2021).
4.6 ISAA DB Config
Outra parte de extrema importância para a construção da plataforma era a implantação
de um ambiente de desenvolvimento que permitisse a criação de forma simples e prática das
tabelas, elementos e condições necessárias para que o BD que suportasse a lógica do negócio.
No caso mais específico do MariaDB, não existe uma ferramenta de administração oficial que
ofereça uma interface gráfica, entretanto, muitas opções de aplicativos, quer estes sejam pagos
ou não, estão disponíveis no mercado. Aproveitando a condição de compatibilidade existente
entre o MariaBD e o MySQL comentada na seção 4.5, foi adotado o phpMyAdmin, aplicativo
completamente sem custos, criado para web e contando com mais de quinze anos de experiência,
sendo empregado no desenvolvimento dos mais variados projetos web (PHPMYADMIN, 2021).
No backend do ISAA, foi utilizada a versão Docker da citada aplicação. A Figura 20 mostra
uma ilustração do aplicativo.
A existência da imagem pronta para criação de container foi um fator determinante
para a escolha do phpMyAdmin, pois facilitou o processo de criação e disponibilização de um
módulo auxiliar alinhado com o contexto da aplicação ofertada. Outras vantagens consistem
na existência das seguintes ferramentas: árvore com hierarquia de bancos e tabelas existentes
no servidor, gerenciamento de usuários e senhas e importação/exportação de backups em di-
45
Figura 19 – ISAA DB Server: Diagrama de esquema do banco de dados
Fonte: Autor (2021).
Figura 20 – ISAA DB Admin: Detalhe do phpMyAdmin
Fonte: Autor (2021).
versos formatos. Essas características são extremamente interessantes também nas tarefas de
manutenção futura da plataforma.
46
4.7 ISAA Modbus
Para um correto funcionamento e manutenção da vida útil do sistema de volumetria,
o conhecimento da situação climática no momento da varredura aérea torna-se essencial e
mandatório. Mesmo contando com características industriais como a capacidade de enfrentar
ventos com velocidade de 10 m/s e IP56 5 (DJIARSMADRID, 2020), devido a proximidade da
usina com a região litorânea oeste do estado do Ceará, é comum a ocorrência de rajadas de vento
com velocidades acima desse limite, bem como a existência de altos níveis de umidade com
chuvas repentinas no pátio de carvão, especialmente durante o período da quadra chuvosa da
região. Avaliando a questão funcional da plataforma de captura, variações bruscas de velocidade
reduzem a qualidade da nuvem de pontos coletada, provocando maiores erros na estimação de
volume e, por consequência, provocando distorções no valor final da quantidade de matéria
contida nas pilhas.
Considerando essa dificuldade, foi prevista a verificação regular dos parâmetros
climáticos locais.Essas informações seriam então utilizadas como sinais "permissivos" para a
liberação de voo do drone. Para que isso fosse possível, era necessário estabelecer uma integração
entre a aplicação proposta e a estação meteorológica existente, item que pertence a rede de
automação local do pátio de carvão. Essa tarefa foi implementada pelo serviço ISAA Modbus. A
Figura 21 apresenta a arquitetura da rede após incluída a conexão com o citado módulo.
O módulo desenvolvido em JavaScript, comunica com o CLP do sistema de aspersão
das pilhas de carvão via protocolo Modbus TCP (com o auxílio da biblioteca modbus-serial)
como servidor, com o objetivo de receber os dados que este coleta da estação meteorológica.
Essa conexão indireta foi implantada devido a característica "mestre - escravo" intrínseca do
Modbus (cliente - servidor para a vertente TCP), que permite a existência de apenas um único
elemento "ativo"6 na rede e essa função já estava delegada ao controlador da asperão. Com isso,
alterações na lógica do CLP foram realizadas, de forma a compatibilizar o serviço proposto com
a condição operacional do conjunto. As configurações necessárias e as lógicas inseridas são
mostradas no Apêndice A.
Pelo lado da API REST, foram criados os comandos descritos na Tabela 2.
O comando retorna um arquivo JSON contendo as variáveis climáticas monitoradas
pela estação meteorológica e o estado dos links de dados estabelecidos entre o módulo de
5 Metodologia que define o nível de proteção de um equipamento contra a entrada de objetos sólidos estranhos,
como poeira, e água (LEGRAND, 2017).
6 No caso do Modbus, "ativo" pode ser interpretado como mestre para o RTU e cliente para o TCP.
47
Figura 21 – ISAA Modbus: Integração com automação existente
Fonte: Autor (2021).
Tabela 2 – ISAA Modbus: Métodos HTML disponíveis
Método Comando Descrição
GET http://<host>:<port>/assets/station.json Retorna arquivo JSON com grandezas climáticas
POST - -
PUT - -
DELETE - -
Fonte: Autor (2021).
aquisição e o CLP e entre o CLP e a estação. A lista de variáveis é mostrada na Tabela 3.
Tabela 3 – ISAA Modbus: Conteúdo de "station.json"
Variável Faixa Unidade Descrição
plcComms false:offline - true:online - Estado da comunicação: módulo e CLP
stationComms false:offline - true:online - Estado da comunicação: CLP e estação
intVoltage 7 - 16,17 V Tensão interna da fonte da estação
intTemperature -40 - +85 ◦C Temperatura interna da estação
intHumidity 0 - 100 % Umidade relativa do ar interna da estação
extTemperature -40 - +85 ◦C Temperatura externa
extHumidity 0 - 100 % Umidade relativa do ar externa
extPressure 490 - 1090 hPa Pressão barométrica
solarRadiation 0 - 1539 W/m2 Radiação solar
windVelocity 0 - 30 m/s Velocidade do vento
windDirection 0 - 359 graus Direção do vento
Fonte: Autor (2021).
Com os dados sendo continuamente coletados (ciclos de 1 segundo), a interface de
controle da missão de varredura possui plenas condições de realizar uma liberação assertiva de
48
voo, garantindo assim as condições mínimas de conservação do equipamento, pois a decisão é
baseada em informações em tempo real da situação climática do pátio de carvão.
4.8 ISAA DB Manager
O ISAA DB Manager é o principal módulo de serviços do ISAA. Ele fornece total
abstração do banco de dados, não sendo necessário o conhecimento prévio dos desenvolvedores
dos outros aplicativos da plataforma de aquisição sobre o funcionamento interno do servidor ou
sobre a linguagem SQL utilizada na programação do BD. Para viabilizar a troca de requisições
entre essas diferentes aplicações, foram padronizadas mensagens HTML onde cada serviço
possui endpoints que disponibilizam ações dedicadas, criadas de acordo com os dados contidos
no BD e as necessidades específicas de cada aplicativo que utilizará essas informações. A divisão
e descrição dos serviços é mostrada na Tabela 4 e um exemplo de leitura de dados (interface web
ISAA) é ilustrada pela Figura 22.
Tabela 4 – ISAA DB Manager: Serviços disponíveis
Serviço Endpoint Descrição
massDataByUser massDataByUser Troca registros organizados por usuário
massDataByPile
formData
Troca registros organizados por pilhalatestRegisterssearchRegisters
closingData
pointCloudData pointCloudData Troca registros e arquivos de nuvem de pontos
droneData droneData Troca registros de dados de instrumentação do VANTdeltaData
Fonte: Autor (2021).
Uma descrição mais detalhada de cada serviço será realizada na sequência.
4.8.1 massDataByUser
O serviço massDataByUser troca mensagens contendo dados de massa das pilhas,
totalizadas por usuário do pátio de carvão. Essa condição permite que o ISAA extraia e apresente
em qualquer tempo e de forma simples e intuitiva um resumo dos quantitativos atuais e passados
do estoque de insumo. Os comandos criados são apresentados na Tabela 5.
As respostas das requisições são retornadas em forma de texto no formato JSON e
os parâmetros e seus respectivos formatos são indicados na Tabela 6. É interessante notar que as
datas são representadas por textos que respeitam o formato interno do MariaDB.
49
Figura 22 – Aplicativo web lendo dados do ISAA DB Manager
Fonte: SOUSA (2020).
Tabela 5 – massDataByUser: Métodos HTML disponíveis
Método Comando Descrição
GET http://<host>:<port>/massDataByUser
Retorna massa totalizada por usuário
dos últimos 9 dias
http://<host>:<port>/massDataByUser?
initDate=<date1>&endDate=<date2>
Retorna massa totalizada por usuário
para o período especificado
POST - -
PUT - -
DELETE - -
Fonte: Autor (2021).
Tabela 6 – massDataByUser: Descrição dos parâmetros
Parâmetro Formato/Tipo Descrição
host IPv4 inteiro 32 bits Nome ou endereço IP do servidor
port Inteiro sem sinal 16 bits Número da porta TCP no servidor
date1 yyyy-mm-dd hh:mm:ss Data inicial do período desejado
date2 yyyy-mm-dd hh:mm:ss Data final do período desejado
Fonte: Autor (2021).
4.8.2 massDataByPile
O massDataByPile é o serviço que trata das leituras e escritas de informações
relacionadas com as entradas e saídas de material das pilhas. Isso permite que o ISAA monitore
e intervenha (caso necessário) em todas movimentações de carvão, fazendo com que o inventário
do pátio seja efetivamente realizado. No caso particular das intervenções manuais, dados de
massa e densidade podem ser enviados. Os registros de densidade são combinados com o volume
calculado a partir da nuvem de pontos (oriundo do serviço pointCloudData) para determinar a
massa contida. Já os registros de massa manuais são utilizados para as situações onde não foi
50
possível realizar a varredura com o aparato de mapeamento aéreo (manutenção ou condições
climáticas adversas) ou quando são necessários pequenos ajustes de estoque. Os comandos
disponíveis são apresentados na Tabela 7.
Tabela 7 – massDataByPile: Métodos HTML disponíveis
Método Comando Descrição
GET
http://<host>:<port>/latestRegisters
Retorna registros do dia atual
criados pelos usuários
http://<host>:<port>/searchRegisters?
initDate=<date1>&endDate=<date2>
Retorna registros criados para o
período solicitado
http://<host>:<port>/closingData?
initDate=<date1>&endDate=<date2>
Retorna registros de massa totalizados
por dia para o período solicitado
POST
http://<host>:<port>/formData
+
bodyData: {
mdate:<mdate>,
type:<type>,
created_by:<userID>,
stp_1a:<stpValue>,
stp_1b:<stpValue>,
stp_2a:<stpValue>,
stp_1b:<stpValue>,
stp_2c:<stpValue>,
stp_2d:<stpValue>,
stp_3a:<stpValue>,
stp_3b:<stpValue>,
}
Cria registros de entrada e saída
de material e densidade
PUT
http://<host>:<port>/latestRegisters
+
bodyData: {
id:<id>,
mdate:<mdate>,
changed_by:<userID>,
destination:[
{stockpile:"1A",qtdd:<stpValue>},
{stockpile:"1B",qtdd:<stpValue>},
{stockpile:"2A",qtdd:<stpValue>},
{stockpile:"2B",qtdd:<stpValue>},
{stockpile:"2C",qtdd:<stpValue>},
{stockpile:"2D",qtdd:<stpValue>},
{stockpile:"3A",qtdd:<stpValue>},
{stockpile:"3B",qtdd:<stpValue>},
]}
Altera registros de entrada e saída
de material e densidade vinculados
a um ID existente no