Protótipo 2 Envio de defeitos da UPE para o Sistema de Ma-

Conforme discutido na seção “5.2.3 - Extração dos Dados de Sensores”, nem sempre é possível processar todos os defeitos em campo, diretamente pelos equi-

pamentos embarcados ou transportados pelo portador. Isso pode ocorrer por conta do requisito de processamento, incompatível com o disponível naUnidade de Pro- cessamento Móvel (UPM), ou por ausência de conectividade da plataforma com redes móveis ou corporativas. Por conta disso, a Unidade de Processamento Ex- terna (UPE) é responsável por realizar o processamento que não pôde ser execu- tado na UPM. Ainda que, fisicamente, esteja separada dos componentes operando em campo, a UPE é considerada uma parte integrante da Plataforma de Inspeção.

O processamento automático de defeitos é de extrema importância, já que é a partir dele que o processo de inspeção e monitoramento dos rolos com uma Plata- forma de Inspeção móvel passa a ser viável. Como resultado deste processamento, os defeitos identificados devem ser enviados para o Sistema de Manutenção (ou CMMS, do inglêsComputerized Management Maintenance System). Ele é responsá- vel por todo o processo de gestão da manutenção, que envolve as fases de Pla- nejamento, Programação e Execução, onde as necessidades são registradas em notas e ordens. A partir delas, as equipes responsáveis programam a execução de serviços corretivos ou preventivos, incluindo a substituição de rolos defeituosos. Diante disso, é essencial que defeitos identificados em campo pela Plataforma de Inspeção sejam reportados e registrados no CMMS o quanto antes, com informa- ções precisas sobre o rolo defeituoso, permitindo a continuidade dos procedimentos para reparo.

Desta forma, com o objetivo de validar a integração da UPE com o Sistema de Manutenção, foi desenvolvida uma integração utilizando o padrão de interação Request-Response, que permite a criação de Notas de Manutenção no CMMS a partir do processamento realizado pela UPE. Assim, o presente protótipo foi desen- volvido para suportar os seguintes requisitos funcionais:

1. Permitir o envio de defeitos identificados pela Plataforma de Inspeção para o CMMS, usando serviço já existente;

2. Habilitar a comunicação entre a Plataforma de Inspeção e o CMMS de forma independente de conectividade, ou seja, não restringir a comunicação à rede corporativa;

3. Permitir que o componente de envio possa ser reaproveitado pela UPM ou mesmo por outras aplicações.

As próximas subseções apresentam um descritivo dos componentes principais. Já a seção “6.2 - Protótipo 2” descreve os testes realizados e discute seus resulta- dos.

5.4.2.1 Componentes da Unidade de Processamento Externa

A primeira parte da UPE para este protótipo é um conjunto de algoritmos de processamento que permite identificar defeitos em imagens térmicas de rolos de transportadores de correia. Os algoritmos não serão detalhados, pois fazem parte do trabalho de outro autor, mas de forma resumida, eles são executados no MA- TLAB e conseguem ler arquivos de imagens em um diretório local. A partir disso, aplicam um método para identificar os rolos nas imagens (regiões de interesse) e obter o valor de temperatura apenas nessas regiões para cada um dos rolos encon- trados. As temperatura é comparada com limites pré-estabelecidos, onde avalia-se se representam situações normais, defeitos em andamento ou falhas críticas. Fi- nalmente, quando é identificado algum problema, a posição GNSS registrada no arquivo de imagem é avaliada para identificar em um mapa qual a posição do de- feito.

Assim, a saída dos algoritmos em questão é a informação de cada um dos defei- tos, o que inclui a temperatura registrada e a posição do rolo defeituoso (latitude e longitude). Tendo como base essas informações de entrada, foi desenvolvida uma função na linguagem Python que permite formatar uma mensagem em JSON e enviá-la para uma API REST, desenvolvida para suportar a criação de notas de manutenção no CMMS, melhor explicada na próxima subseção. Além de encap- sular detalhes da integração com o CMMS, como a URI a ser chamada, chave de acesso e outras questões, esta função é importante pois também realiza tratamento dos dados, complementando as informações e permitindo que o algoritmo no MA- TLAB resuma-se a identificar os defeitos e acioná-la. Assim, ela se encarrega da comunicação com a API REST, retornando ao algoritmo chamador o status de pro- cessamento, seja ele o número da nota de manutenção criada ou uma mensagem de erro do CMMS ou dos componentes da integração.

É importante destacar que a função desenvolvida emPythoné independente e, por conta disso, pode ser usada por outras aplicações. Isso permite, por exemplo, incorporá-la diretamente à UPM, caso ela consiga avaliar os defeitos de forma em- barcada. Esta abordagem simplifica a evolução da Plataforma de Inspeção, uma vez que uma única função pode ser usada para enviar qualquer tipo de defeito ao CMMS, tendo sido ele identificado pela UPM ou pela UPE, com base em qualquer tipo de sinal (térmico, acústico ou vibração) capturado por algum dos sensores. Isso também reforça os motivadores da escolha da linguagem Pythonpara essa função, já que ela é simples, robusta, compatível com algunsframeworksde robótica, como o ROS, e facilmente integrável a outras aplicações e pacotes de mercado, como o MATLAB.

Outra questão que facilita o reuso é a própria definição das APIs eweb services para comunicação com o CMMS. Esse tipo de abordagem, bem como o papel de facilitador realizado pela camada de Integração, é explicado na seção a seguir. 5.4.2.2 Componentes de Integração

Conforme explicado na subseção “5.2.4 - Integração”, quanto maior a comple- xidade embutida nesta camada, mais simples se torna a comunicação entre as aplicações e sua integração. Parte disso vem dos conceitos de Arquitetura Orien- tada a Serviços (SOA), apresentados na subseção “4.3.1 - Arquitetura Orientada a Serviços”, onde é possível expor funções de negócios por meio de serviços que podem ser reusados por diferentes aplicações. A outra parte que justifica a afirma- ção anterior é que a camada de integração, por meio de Barramentos de Integração (Brokersou Enterprise Service Bus- ESB), traz pra si a responsabilidade de absor- ver diferenças entre as aplicações, como linguagem de programação, protocolos de comunicação distintos e mesmo algumas questões de conectividade.

Dessa forma, a Figura 63 apresenta uma visão geral do protótipo. Do lado es- querdo, encontra-se a camada de Extração de Dados dos Sensores, com a UPE desempenhando o papel descrito na subseção anterior de detecção de defeitos e acionamento de uma API para envio. No lado direito, está posicionado o CMMS, que é o Sistema Corporativo que necessita receber os defeitos para dar prossegui- mento ao processo de manutenção. Ele possui um serviço deCriação de Notas de Manutenção, que permite que outros sistemas reportem defeitos.

Figura 63 – Papel da camada de Integração para viabilizar a conectividade da Pla- taforma de Inspeção e conversão REST x SOAP. Fonte: autor

tro, é composta por duas ferramentas distintas que se combinam para endereçar aspectos inicialmente incompatíveis entre as pontas. O primeiro deles é a conec- tividade, uma vez que a Plataforma de Inspeção está em campo e, muitas vezes, em áreas sem cobertura da rede corporativa de TI. O segundo aspecto refere-se à adaptação de protocolos para viabilizar a comunicação. O serviço já existente no CMMS utiliza o protocolo SOAP, que é muito comum na comunicação entre apli- cações corporativas, dada sua robustez. Por sua vez, a Plataforma de Inspeção, é baseada no estilo de arquitetura REST, mais simples e leve, que utiliza o proto- colo HTTP para transporte. Assim, cabe às ferramentas da camada de Integração

cuidar destes aspectos e viabilizar a conectividade e adaptação de protocolos. Uma destas ferramentas, oTIBCO Business Works2, é utilizado na empresa para expor os web services SOAP, promovendo o reuso e facilitando a administração, além de outros aspectos já abordados na seção “4.3.2 - Barramento de Integração”. Dessa forma, os principais serviços disponíveis nos Sistemas Corporativos são expostos neste Barramento de Integração para que possam ser consumidos por outras aplicações. Porém, o TIBCO Business Worksestá localizado dentro da rede corporativa de TI e, atualmente, sua comunicação com aplicações externas, via internet, é limitada ao protocolo SOAP.

Por conta disso, uma segunda ferramenta foi utilizada, oAPI Management3, dis- ponível na plataforma de computação em nuvem da Microsoft, aAzure. Além de ser acessível via internet, essa ferramenta possui conectividade com a rede corporativa de TI por meio de uma rede privada (VPN, do inglêsVirtual Private Network), o que viabiliza a comunicação de aplicações externas com sistemas internos. Isso é feito por meio de APIs, que tornam acessíveis serviços publicados em um Barramento de Integração, como oTIBCO Business Works, ou diretamente pelos Sistemas Cor- porativos.

Tendo como base oAzure’s API Management, foi criada uma nova API em REST para expor o serviço (ou web service) já existente para Criação de Notas de Ma- nutenção. Esta ferramenta permite ainda converter o protocolo SOAP do serviço original para o estilo REST. Assim, a Figura 64 apresenta, em alto nível, como essa conversão é feita. Na parte superior, é possível ver que a URI do Recurso em REST é convertida em uma URL da operação SOAP, parte do cabeçalho da mensagem. Além disso, como o web service SOAP existente é baseado em XML, na figura é possível perceber algumas etapas que reescrevem o corpo da mensagem (body) de JSON para XML. Por fim, na parte inferior, é realizado o processo reverso, onde 2 https://www.tibco.com/products/tibco-businessworks

3 https://docs.microsoft.com/en-us/azure/api-management/api-management- key-concepts

a resposta recebida do web service é reescrita de XML para JSON.

Figura 64 – Macroetapas da conversão de protocolos e de formato (XML x JSON) realizada no API Management. Fonte: autor

Assim, com o uso desse ferramental, foi possível construir um processo de inte- gração no estilo Request-Responseque viabiliza a comunicação da Plataforma de Inspeção com o CMMS para envio dos defeitos identificados. É importante lembrar que essa abordagem vale para qualquer tipo de serviço existente, alterando-se ape- nas o ferramental envolvido e, evidentemente, os sistemas. Portanto, a subseção “6.2 - Protótipo 2” apresenta os testes e discute os resultados deste protótipo.

5.5 Simulação

Conforme discutido no capítulo Metodologia, a simulação é uma parte impor- tante do trabalho, particularmente nos casos de uso que envolvem um portador do tipo VANT. Por conta disso, as próximas subseções apresentam como ela foi utilizada. O texto da seção foi organizado da seguinte forma: