PROPOSTA DE ARQUITETURA ORIENTADA A SERVICO˘ S … · PROPOSTA DE ARQUITETURA ORIENTADA A SERVICO˘ S PARA INTEGRAC˘AO~ DE UM SISTEMA DE MANUTENC˘AO INTELIGENTE~ Anderson Ant^onio

PROPOSTA DE ARQUITETURA ORIENTADA A SERVICOS PARA INTEGRACAODE UM SISTEMA DE MANUTENCAO INTELIGENTE

Anderson Antonio Giacomolli∗, Thiago Regal da Silva∗, Carlos Eduardo Pereira∗,Renato Ventura Bayan Henriques∗

∗ Departamento de Engenharia EletricaUniversidade Federal do Rio Grande do Sul (UFRGS)

Av. Osvaldo Aranha, 103Porto Alegre, RS, Brasil

Emails: [email protected], [email protected], [email protected],

[email protected]

Abstract— The costs associated with equipments maintenance still represent a large portion of the resourcesavailable to a company. Therefore, the improvement of maintenance techniques, and development of the newones, are growing, since they impact directly on the economic side of the companies. Thus, the current workpresents a service-oriented architecture proposal for an intelligent maintenance system. The architecture intendsto integrate equipments and degradation analysis tools, improving the health estimation process.

Keywords— Intelligent Maintenance Systems, Service-Oriented Architectures, Systems Integration.

Resumo— O custo empregado na manutencao de equipamentos ainda representa uma grande parcela dosinvestimentos no setor industrial. Portanto, o desenvolvimento de novas tecnicas de manutencao, bem como oaperfeicoamento das ja existentes, cada vez e tido como foco nas corporacoes, por impactarem diretamente nofator economico das empresas. Dessa forma, o trabalho em questao apresenta a proposta de uma arquiteturaorientada a servicos para integracao de sistemas de manutencao inteligente. A arquitetura tem por objetivo aintegracao de equipamentos e ferramentas de analise, visando melhorar o processo de obtencao dos ındices desaude dos equipamentos.

Palavras-chave— Sistemas de Manutencao Inteligente, Arquiteturas Orientadas a Servicos, Integracao deSistemas.

1 Introducao

Atualmente, a importancia do emprego de tecni-cas de manutencao no ambito industrial esta emconstante ascensao devido a necessidade de au-mentar a disponibilidade e seguranca dos equipa-mentos, bem como a qualidade do processo produ-tivo (Muller et al., 2008). Dessa forma, o desenvol-vimento de novas tecnicas de manutencao para usonas mais diversas areas e o correto planejamentodos processos de manutencao estao cada vez maisimportantes, uma vez que impactam diretamenteno fator economico, alterando a disponibilidade dosistema e tambem a seguranca (Zhao et al., 2010).

Nos ultimos anos, tem-se observado um cres-cimento no uso de um novo paradigma demanutencao denominado de manutencao inteli-gente (Zhang et al., 2013). Diferentemente dosmetodos tradicionais, conhecidos por aplicar oconserto aos equipamento somente apos a falha oupor manterem processos de manutencao agenda-dos baseado no historico de falhas dos componen-tes, o paradigma de manutencao inteligente visapredizer a condicao do sistema e prevenir uma pos-sıvel falha.

Outra linha de pesquisa tambem esta emconstante crescimento: o uso de Service-OrientedArchitecture (SOA) ou Arquiteturas Orientadasa Servicos. O uso do padrao SOA esta evo-luindo e esta cada vez mais presente em aplica-

coes nos mais diversos segmentos, sejam eles a nı-vel de dispositivos, na implementacao de camadasde negocios ou mesmo no setor industrial, comoapresentado em (Papazoglou and Heuvel, 2007),

(Ragavan et al., 2012) e (Choi et al., 2010). E umconceito de arquitetura que suporta acoplamentomınimo entre componentes, possibilitando ganhosem flexibilidade e interoperabilidade. Por conse-guinte, qualquer tipo de aplicacao pode ser repre-sentada como um conjunto complexo de servicos,inclusive no ambito industrial (Bohn et al., 2006),(de Deugd et al., 2006), (Colombo et al., 2010) e(Karnouskos et al., 2010).

Nesse contexto, um sistema de manutencaointeligente tambem pode se valer da utilizacao dosconceitos empregados pelo padrao SOA. Do pontode vista da arquitetura SOA, o sistema de ma-nutencao pode conter servicos para relatorios desaude e falhas, informacoes sobre o prognosticodo tempo de operacao sem necessidade de manu-tencao, alem de servicos de configuracao de ferra-mentas de diagnostico ou dos modos de operacaosuportados pelo equipamento. O monitoramentoremoto do sistema tambem possibilita a integra-cao das informacoes de saude dos equipamentosem sistemas Manufacturing Execution Systems(MES) e Enterprise Resource Planning (ERP), afim de se obter o correto gerenciamento da cadeiade suprimentos de pecas de reposicao (Oldhamet al., 2003).

Anais do XX Congresso Brasileiro de Automática Belo Horizonte, MG, 20 a 24 de Setembro de 2014

3814

Com base nestes aspectos, o presente artigoaborda a definicao de uma arquitetura orientadaa servicos para integracao de diferentes componen-tes que fazem parte de um sistema de manutencaointeligente. Os componentes sao abstraıdos comoentidades SOA e casos de uso ilustram diferen-tes cenarios para a utilizacao da proposta. Dessaforma, este trabalho esta estruturado da seguintemaneira: na secao 2 e apresentada uma analise doestado da arte, cobrindo os dois assuntos princi-pais empregados no artigo; a secao 3 apresenta aproposta de arquitetura; na secao 4 e apresentadaa implementacao da proposta e resultados; e, porfim, a secao 5 apresenta as conclusoes.

2 Sistemas de Manutencao Inteligente eArquiteturas Orientadas a Servicos

Nesta secao sao apresentados os conceitos de siste-mas de manutencao inteligente e arquiteturas ori-entadas a servicos, utilizados como base para aconstrucao da arquitetura proposta.

2.1 Sistemas de Manutencao Inteligente

Em uma visao geral, manutencao consiste de umaserie de medidas de prevencao, correcao e predicaode falhas (Lee et al., 2006). Equipamentos ou ma-quinas tendem a deteriorar e alterar o seu padraode funcionamento durante o uso devido a diversosfatores, como desgaste, rachaduras, corrosao ousujeira. Nessas condicoes, torna-se imprescindıvela restauracao do sistema, a fim de evitar defei-tos que podem ocasionar falhas ou indisponibili-dades (Marcal and Susin, 2005).

Tres estrategias de manutencao sao encontra-das na literatura classica: corretiva, preventiva epreditiva (Marcal and Susin, 2005). A corretivavisa reestabelecer o sistema danificado; a preven-tiva se objetiva a manter o sistema funcionando;e a preditiva visa monitorar o sistema, detectandofalhas insipientes e fornecendo meios para o pla-nejamento de acoes preventivas ou corretivas.

Uma quarta estrategia, que esta ganhandoforca nos ultimos anos, e denominada de manu-tencao proativa ou manutencao inteligente (Leeet al., 2009). Este novo paradigma esta em acen-sao como substituto das estrategias de manuten-cao preventiva. A nova estrategia visa nao so-mente a predicao do estado do sistema, mas tam-bem o diagnostico de falhas e a intervencao deforma automatica. Dessa forma, no caso de fa-lhas repentinas, o proprio sistema pode se ajus-tar para tomar decisoes em relacao a falha ocor-rida (Goncalves, 2011).

A fim de prover uma plataforma flexıvel e fun-cional para integrar uma variedade de sistemas desoftware e hardware, o Open Systems Architecturefor Condition-Based Maintenance (OSA-CBM) foicriado (Thurston, 2001). O padrao tem como ob-

jetivo definir uma convencao para troca de dadosentre elementos. A arquitetura OSA-CBM e des-crita de acordo com sete camadas funcionais, ilus-tradas na fig. 1 (MIMOSA, 2014). As duas pri-meiras camadas, aquisicao e manipulacao de da-dos, definem o modo como os dados de sensoresou transdutores sao obtidos, digitalizados e quaismanipulacoes de sinais sao realizadas. A camadaseguinte, identificada como deteccao do estado dosistema, recebe os dados dos sensores e os com-para com valores previamente definidos, gerandoalertas quando os limites definidos forem ultrapas-sados. A camada de avaliacao da saude do sistemarecebe dados da camada anterior e determina seo sistema esta degradando. Na camada de prog-nostico, o tempo de utilizacao restante do equipa-mento e estimado, levando em conta padroes futu-ros de utilizacao. A camada seguinte, tomada dedecisao, tem por objetivo gerar acoes de utilizacaopara que os equipamentos preservem as condicoesde saude ate que a proxima falha ocorra, levandoem conta o historico de operacoes e outros indica-dores. A ultima camada, apresentacao, e respon-savel por prover meios de visualizacao dos dadosobtidos nas camadas anteriores.

Apresentação

Tomada de decisão

Prognóstico

Avaliação da saúde do sistema

Detecção do estado do sistema

Manipulação dos dados

Aquisição dos dados

Figura 1: Camadas do modelo OSA-CBM.

Varios trabalhos conduzem o desenvolvimentode tecnicas e metodologias para problemas relacio-nados a manutencao de predicao e prevencao (JayLee, 2003), (Lee et al., 2006), (W.J. Moore andA.G. Starr, 2006). Neste meio, o Intelligent Main-tenance System Center (IMS Center) propos umadas mais importantes ferramentas neste segmento,denominadaWatchdog Agent (Djurdjanovic et al.,2003). O Watchdog Agent e um software com-posto por varios algoritmos para analise do de-sempenho do sistema, e que permite analisar dife-rentes partes de equipamentos, a fim de obter umindicador. E composto por modulos, estruturadosde acordo com o modelo de camadas OSA-CBM.

O Watchdog Agent permite a manipulacao dedados e extracao de padroes de sinais. O soft-ware dispoe de um conjunto de ferramentas comoTransformada Rapida de Fourier, TransformadaWavelet, Regressao Logıstica e ReconhecimentoEstatıstico de Padroes (IMS CENTER, 2007).


3815

Combinando estas ferramentas, juntamente comdados dos sensores, e possıvel predizer a degrada-cao do sistema e avaliar o estado dos equipamen-tos.

2.2 Arquiteturas Orientadas a Servicos

Tecnicas para desenvolvimento de aplicacoes SOArepresentam uma mudanca de paradigma na enge-nharia de software, onde os componentes sao defi-nidos como servicos (Ramollari et al., 2007). Es-tas tecnicas, inicialmente desenvolvidas para usoem ambiente gerencial e corporativo de empresas,logo teve aceitacao em diversos segmentos, entreeles, a automacao industrial.

De forma geral, arquiteturas SOA tem comocaracterıstica principal a criacao e disponibilidadede servicos, que, quando agrupados, dao origem aum sistema funcional (Josuttis, 2009). O termoservico se refere a uma funcionalidade ou logicaque e encapsulada e oferecida ao sistema atravesde uma interface. Dessa maneira, outros servicos,entidades ou programas sao capazes de acessa-loe emprega-lo na resolucao de determinada tarefa.

Para que possam ser utilizados, os servicos ne-cessitam de exposicao, a fim de que os utilizado-res os encontrem (Papazoglou and Heuvel, 2007).Portanto, uma aplicacao SOA deve prover meiospara que os servicos possam se comunicar e efe-tuar a troca de informacoes de forma padronizada.Dessa forma, todos os componentes da arquite-tura devem obedecer a alguns conceitos, entre eles:acoplamento mınimo, a fim de minimizar a de-pendencia de outros servicos; contrato de servico,utilizando um mesmo padrao de comunicacao; au-tonomia, sendo o proprio servico responsavel pe-las tarefas que executa; abstracao, escondendo alogica e recursos utilizados; reuso, possibilitandoa utilizacao da mesma funcionalidade em variaspartes do sistema; composicao, tendo objetivo deorganizar um conjunto de servicos para a execu-cao de uma tarefa mais complexa; independen-cia de estado, onde o servico nao retem informa-coes sobre as atividades executadas; e possibili-dade de descoberta, que permite a outros servicosencontra-lo (Josuttis, 2009).

A troca de informacoes entre os servicos nor-malmente ocorre utilizando o protocolo SimpleObject Access Protocol (SOAP). Neste proto-colo, as mensagens sao codificadas no formato Ex-tensible Markup Language (XML). O protocoloSOAP pode ser utilizado sobre diferentes protoco-los de transporte, como, por exemplo, o HypertextTransfer Protocol (HTTP).

A descricao das interfaces dos servicos sao re-alizadas utilizando Web Service Description Lan-guage (WSDL). Documentos WSDL tambem saobaseados em XML e contem a informacao neces-saria para utilizacao do servico descrito. Nos do-cumentos WSDL sao descritas todas as operacoes

que o servico possibilita, bem como os tipos dedados por ele suportados. O documento tambempode ser estendido, definindo novos tipos de dadospara troca de mensagens.

Em uma aplicacao SOA, a descricao dos servi-cos disponıveis e o endereco para acessa-los estaodisponıveis no Universal Description Discovery In-tegration (UDDI). O padrao UDDI define o pro-tocolo para os servicos de diretorio, ou interme-diadores de servico, onde sao armazenadas as in-formacoes de cada um dos servicos da aplicacao.Esta entidade e utilizada para informar aos clien-tes quais servicos estao disponıveis, possibilitandomeios para descoberta e obtencao de metadados.A interoperabilidade entre os componentes de umaaplicacao SOA e apresentada na fig. 2.

Registro deserviço

Conexão einvocação

Consumidor deserviço

Cliente

Provedor deserviço

Contrato deserviço

Serviço

Pesquisa Registro

Figura 2: Interoperabilidade entre os elementos deuma aplicacao SOA.

As especificacoes para web services normal-mente seguem o padrao de grafia ”WS-” (Candido,2013). Porem, dentre as especificacoes, o DevicesProfile for Web-Services (DPWS) define um con-junto mınimo de implementacoes que permitem atroca de mensagens, descoberta, descricao, gera-cao de eventos e autenticacao para a utilizacao deweb services em clientes com recursos computaci-onais limitados (Ribeiro et al., 2008). Apesar deutilizar um conjunto mınimo de implementacoes,clientes que utilizam DPWS podem ser integradosa outros, com recursos mais flexıveis.

O DPWS utiliza uma pilha de protocolos e es-pecificacoes para consistencia na conexao entre osdispositivos. Dentre as especificacoes, destacam-se o WS-Addressing, utilizado para a transferenciade mensagens, o WS-Discovery, que possibilita adescoberta de servicos em uma rede local, e o WS-Eventing, para a utilizacao de eventos. O DPWSutiliza os protocolos Transmission Control Proto-col (TCP) e HTTP para a transmissao de dados.

3 Arquitetura proposta

Um sistema de manutencao inteligente deve sercomposto por dispositivos a serem analisados, ins-trumentados para obtencao dos dados de senso-res, e um analisador de dados, que ira determi-nar o nıvel de degradacao dos equipamentos (Leeet al., 2006). Contudo, as tecnicas utilizadas atu-almente necessitam que os dados sejam obtidos e


3816

analisados separadamente dos equipamentos (IMSCENTER, 2007). O tempo envolvido na instru-mentacao do equipamento, obtencao dos dados eposterior analise, se replicado para um numero ele-vado de dispositivos, torna a analise das condicoesde degradacao uma tarefa complexa e despendi-osa.

Tecnologias SOA estao cada vez mais presen-tes na industria e o seu uso reflete a busca pela in-terconexao de dispositivos distribuıdos (Cannataet al., 2010). A padronizacao da comunicacao en-tre componentes e a facilidade de construcao denovas aplicacoes estao entre as principais vanta-gens. Portanto, esta tecnica tambem pode seraplicada no desenvolvimento de aplicacoes de ma-nutencao inteligente.

A fim de possibilitar a integracao dos diver-sos equipamentos que fazem parte de um sistemade manutencao inteligente, uma arquitetura ba-seada em SOA foi definida, sendo composta porentidades de software, cada uma responsavel poruma tarefa especıfica. As entidades sao aplicati-vos que se comunicam por meio de servicos e foramidentificadas com base nos requisitos da aplicacao.Dessa forma, a integracao do sistema e realizadapor um conjunto de servicos bem definido. Estasecao apresenta a arquitetura proposta e casos deuso, ilustrando algumas situacoes onde o sistemapode ser empregado.

3.1 Proposta de Arquitetura Orientada a Servi-cos

Neste trabalho, optou-se por utilizar uma arqui-tetura SOA para integrar de forma facilitada asentidades do sistema. A fig. 3 ilustra as entidadesprincipais da arquitetura proposta. Cada entidadee um componente SOA, responsavel por desem-penhar uma tarefa especıfica na aplicacao, sendoimplementados utilizando a especificacao DPWS.Neste contexto, as entidades sao conectadas porservicos web. A arquitetura conta com seis enti-dades: Dispositivo, Gerenciador de Dispositivos,Gerenciador de Analises, Analisador de Dispositi-vos, Base de Dados e Repositorio de Servicos.

A entidade identificada por Dispositivo e umcomponente de software utilizado para abstrairum elemento fısico da arquitetura proposta. Odispositivo em questao e denominado de logico,por executar embarcado em um dispositivo fısico.Pode abrigar funcionalidades relativas ao dispo-sitivo fısico ou outras, que auxiliam em algumatarefa especıfica nao relacionada diretamente como hardware hospedeiro. A entidade controla o dis-positivo fısico, obtendo os dados de sensores e en-viando para um banco de dados. O Dispositivotambem pode apresentar comportamentos, defini-dos como o modo de operacao que o equipamentoira assumir frente as condicoes de degradacao.

O Gerenciador de Dispositivos, como o nome

Repositóriode serviços

Basede dados

Gerenciadorde dispositivos

Gerenciadorde análises

Analisador dedispositivos

Dispositivo

Dispositivo

Dispositivo

Serviços

Figura 3: Arquitetura orientada a servicos pro-posta para integracao de um sistema de manuten-cao inteligente.

sugere, possui as ferramentas necessarias para ogerenciamento dos dispositivos na rede. A obten-cao da lista de dispositivos e configuracao de cadaum deles sao tarefas executadas pelo gerenciador.Como exemplo de configuracao esta o envio de no-vos comportamentos para o dispositivo.

O Gerenciador de Analises e utilizado para ogerenciamento de planos de analise de equipamen-tos pelo operador do sistema. O plano de analise ea estrutura que armazena as informacoes necessa-rias para que uma analise de degradacao de umequipamento possa ser executada corretamente.O Gerenciador de Analises possibilita o agenda-mento dos planos e a definicao de execucoes pe-riodicas das analises.

No Analisador de Dispositivos os planos saoexecutados. A entidade opera com base nos planoscriados pelo operador do sistema no Gerenciadorde Analises. O analisador possui as ferramentasnecessarias para manipulacao dos dados dos equi-pamentos e obtencao dos indicadores de saude.

A entidade Base de Dados e utilizada comouma interface para um banco de dados. No bancode dados sao armazenadas todas as informacoesda aplicacao. Para garantir a estrutura de umaaplicacao SOA, a entidade foi especificada com ointuito de abstrair os acessos ao banco atraves deservicos.

O Repositorio de Servicos armazena os dis-positivos logicos e seus servicos, os quais podemser obtidos e implantados dinamicamente em dis-positivos fısicos. Esta entidade pode fazer parteda rede local ou remota. Dessa forma, uma novaaplicacao pode ser construıda com base em com-ponentes ja definidos. Com esta abordagem, tam-bem e possıvel o compartilhamento de uma basede dados de componentes logicos entre diferentesaplicacoes.

3.2 Casos de uso para a arquitetura proposta

No contexto de uma aplicacao de manutencao in-teligente, a arquitetura aqui proposta pode serempregada em alguns casos de uso. Os casos


3817

de uso apresentados neste trabalho exemplificama interacao do operador do sistema na busca ouconfiguracao de dispositivos e na criacao de pla-nos de analise para determinado equipamento. Damesma forma, para a execucao dos planos agen-dados pelo operador do sistema, foi utilizado umator denominado de tarefa periodica.

A descoberta e configuracao dos dispositivose representada pelo diagrama Unified ModelingLanguage (UML) de casos de uso da fig. 4. Nodiagrama sao ilustradas as interacoes que o ope-rador do sistema pode realizar nos dispositivos uti-lizando o Gerenciador de Dispositivos. De acordocom o diagrama, o gerenciador permite a visua-lizacao dos dispositivos encontrados na aplicacaoorientada a servicos, a busca de informacoes maisdetalhadas, atraves de metadados, bem como asua configuracao, com atualizacao das informacoese envio de novos comportamentos.

Operadordo sistema


Descobertade serviço

Dispositivo 1

Aplicação orientadaa serviços


Dispositivo 2

Dispositivo n

Serviço deatualização dos

metadados

Obterestado


<uses>

<uses>

<uses>

<extends>

<uses>

<uses>

<uses>

Obter topologiados dispositivos

Obtermetadados

Descobrirdispositivose serviços

Atualizarmetadados do

dispositivo

Obter estadodo dispositivo

Serviço decomportamentos

<uses>Atualizar

comportamentosdo dispositivo

Figura 4: Diagrama de casos de uso para desco-berta e configuracao de dispositivos.

O gerenciamento dos planos de analise pelooperador do sistema e ilustrado no diagrama UMLda fig. 5. Novos planos de analise podem ser cri-ados e associados a determinado equipamento, afim de obter os indicadores de desempenho paratomada de decisao. Alem das informacoes do dis-positivo associado a analise, o plano tambem ar-mazena as ferramentas, presentes no Analisadorde Dispositivos, que serao utilizadas e os compor-tamentos que o dispositivo deve assumir dado oresultado obtido com a analise. Como comporta-mentos, entende-se as acoes realizadas pelo equi-pamento a fim de garantir a operacao ate que umamanutencao corretiva possa ser realizada.

Para a obtencao dos ındices de degradacao,as ferramentas de analise necessitam de dados detreinamento do equipamento. O Gerenciador deDispositivos dispoe de meios para o envio destesdados. O envio de dados de treinamento pelo ope-rador do sistema e apresentado no diagrama UML

Gerenciador deanálises

Obterestado

Dispositivo 1


Dispositivo n

Operadordo sistema Serviço de

metadados


Base de dados

Obterplano

Inserirplano

Removerplano

<uses>

<uses>

<uses>

<uses>

<uses>

<uses>

<uses>

<uses>

<uses>

Verificarrecursos

disponíveis

Criar planode análise

Editar planode análise

Obtercomportamentos

do dispositivo

Remover planode análise


Obterferramentasde análise

Obterferramentasde análise

<uses>

<uses>

Figura 5: Diagrama de casos de uso para o geren-ciamento de analises pelo operador do sistema.

de casos de uso da fig. 6.

Operadordo sistema



Dispositivo

Serviço demetadados


Base de dados

Inserirdados de

treinamento


Enviar dadosde treinamento

<uses>

<uses>

<uses>

Figura 6: Diagrama de casos de uso para envio dedados de treinamento para um dispositivo.

A execucao das analises dos dispositivos efeita automaticamente por uma tarefa periodica.No plano de analise, o operador do sistema de-fine a frequencia de execucao de analise para cadaequipamento e, baseado nisso, uma tarefa perio-dica e executada no Analisador de Dispositivos.O analisador verifica quais os planos de analiseestao ativos, os carrega e executa. Na execucao,os dados do dispositivos sao obtidos e analisa-dos pelas ferramentas definidas no plano de ana-lise pelo operador do sistema. Apos finalizada aanalise, e baseado no indicador de degradacao ob-tido, o equipamento pode ser sinalizado a assumirum comportamento diferente, a fim de evitar umamaior degradacao ate que uma manutencao corre-tiva possa ser efetuada. A fig. 7 ilustra o diagramaUML de casos de uso para a execucao dos planosde analise.

Relatorios de saude dos equipamentos em ana-lise podem ser obtidos atraves do Gerenciador de


3818


Tarefaperiódica

Base de dados

Inserirresultadosda análise

Obter dadosbrutos

Obterplano

Obterestado

Dispositivo



Serviço decomportamentos

<uses>

Obtercomportamentos

do dispositivo

Obter dadosdo dispositivo

<uses>

<uses>

<uses>

<uses>

<uses>

<uses>

<uses>

<uses>

<uses>Verificarrecursos

disponíveis

<extends>

Carregar planode análise

Obter planode análise

Obter planosde análise

ativos

Selecionarferramentade análise

Executar planode análise

Figura 7: Diagrama de casos de uso para a obten-cao e execucao das analises.

Dispositivos, entidade que se comporta como in-terface entre o operador do sistema e os dispositi-vos que compoe a arquitetura. E possibilitado aooperador do sistema realizar a busca pelos dispo-sitivos na rede e obter os resultados das analisesanteriores. Na arquitetura proposta, os resultadosdas analises sao armazenados na Base de Dados.A fig. 8 apresenta o diagrama UML para obten-cao dos relatorios de saude de um dispositivo pelooperador do sistema.

Operadordo Sistema

Base de dados

Obterrelatório das

análises

Dispositivo 1





<extends>

<uses>

<uses>

<uses>

<uses>

Obtermetadados


Obterrelatório dodispositivo

Figura 8: Diagrama de casos de uso para obtencaodos relatorios de saude do dispositivo.

4 Implementacao e resultados

Para validacao da arquitetura proposta, as enti-dades descritas na secao 3 foram implementadas.Para a implementacao das entidades escolheu-se a linguagem de programacao Java e a imple-mentacao DPWS denominada Java Multi EditionDPWS Stack (JMEDS), que faz parte do projetoWS4D (WS4D-JMEDS, 2013). As entidades saoaplicativos de ambiente grafico que permitem rea-lizar as operacoes descritas nos casos de uso apre-sentados.

Como forma de avaliar a arquitetura proposta

e implementada, foi escolhido um estudo de casoque consiste em um conjunto atuador eletrico evalvula. O atuador em questao e utilizado parao controle de fluxo em redes de distribuicao depetroleo, permitindo abertura e fechamento dosdutos pelo movimento da haste, cujo acionamentoe feito por um motor. O conjunto, modelo CSR6,fabricado pela empresa Coester Automacao Ltda,e ilustrado na fig. 9. Por se tratar de um equi-pamento sujeito a degradacao constante, foi esco-lhido como estudo de caso.

Figura 9: Atuador eletrico modelo CSR6.

Neste trabalho, utilizou-se os dados de instru-mentacao obtidos nos trabalhos de (Boesch, 2011)e (Faccin, 2011) com intuito de avaliar somente ocomportamento das entidades da arquitetura pro-posta. Dessa forma, a entidade denominada Dis-positivo (fig. 3) foi utilizada como um simuladordo dispositivo a ser monitorado, utilizando os da-dos de sensores previamente obtidos. O atuadoreletrico foi instrumentado com tres sensores, sendorealizados seis testes, conforme tab. 1

Tabela 1: Situacoes definidas para coleta dos da-dos.Situacao Acionamento do freio Engrenagens

1 – –2 1 bar –3 3 bar –4 – 1 desgastada5 – 3 desgastadas6 – 1 quebrada

As engrenagens utilizadas nos testes, presen-tes no conjunto de engrenagens satelite do atua-dor, sao ilustradas na fig. 10. A da esquerda euma engrenagem normal, a do meio desgastada ea da direita com dentes quebrados.

A analise de degradacao foi feita a partir dosdados de vibracao do atuador. Primeiramente fo-ram extraıdas as caracterısticas dos sinais utili-zando a transformada de wavelet packet. Apos, oalgoritmo de deteccao de falhas foi treinado como metodo da Regressao Logıstica utilizando, paraisso, dados de funcionamento normal e em falha.

A fig. 11 apresenta a tela do aplicativo Dispo-sitivo implementado a partir da arquitetura pro-


3819

Engrenagem normal Engrenagem desgastada Engrenagem quebrada

Figura 10: Engrenagens utilizadas no estudo decaso.

posta. Como mencionado, o aplicativo e utilizadopara simular os dados de uma das seis situacoesapresentadas na tab. 1.

Figura 11: Tela principal do simulador de dispo-sitivos.

A definicao de um plano de analise para o dis-positivo e feita no Gerenciador de Analises. Umadas telas do software e apresentada na fig. 12. Atela ilustra a escolha das ferramentas que seraoutilizadas para determinar o nıvel de degradacaodo equipamento em analise.

Figura 12: Dialogo para escolha das ferramentasutilizadas na analise.

O Analisador de Dispositivos, que utiliza asinformacoes definidas no plano de analise, realizaas analises de forma automatica. A entidade veri-fica os planos pendentes, busca os dados necessa-rios e obtem o nıvel de degradacao utilizando asferramentas definidas no plano. A fig. 13 ilustra atela principal do Analisador de Dispositivos.

5 Conclusao

O monitoramento de diversos equipamentos comtecnicas de manutencao inteligente ainda e difi-cultado pelo tipo de solucao adotada para ana-lise dos dados e pela distribuicao dos dispositivos.

Figura 13: Tela principal do Analisador de Dispo-sitivos.

Neste trabalho, uma arquitetura orientada a ser-vicos para um sistema de manutencao inteligentefoi proposta, a fim de facilitar a integracao entreos diferentes componentes envolvidos neste tipo deaplicacao. Foram definidas e apresentadas as en-tidades que fazem parte da arquitetura e casos deuso onde a proposta pode ser empregada. Alemdisso, foi apresentada a implementacao das entida-des e um estudo de caso especıfico para validacaoda proposta.

Referencias

Bohn, H., Bobek, A. and Golatowski, F. (2006).Sirena – service infrastructure for real-time embedded networked devices: A ser-vice oriented framework for different do-mains, Proceedings of the International Con-ference on Networking Systems and Interna-tional Conference on Mobile Communicati-ons and Learning Technologies, IEEE, Mau-ritius, pp. 43–43.

Boesch, K. (2011). Deteccao de falhas por fusaode sensores em atuadores eletricos, Projetode diplomacao (graduacao em engenharia ele-trica), Universidade Federal do Rio Grandedo Sul, Porto Alegre.

Candido, G. (2013). Service-Oriented Architecturefor device lifecycle support in industrial auto-mation, Tese (doutorado em engenharia ele-trotecnica e de computadores), UniversidadeNova de Lisboa, Portugal.

Cannata, A., Karnouskos, S. and Taisch, M.(2010). Dynamic e-maintenance in the era ofSOA-ready device dominated industrial envi-ronments, in D. Kiritsis et al. (eds), Engine-ering Asset Lifecycle Management, Springer,London, pp. 411–419.

Choi, J., Nazareth, D. and Jain, H. (2010). Theimpact of SOA implementation strategies onbusiness value and agility: A systems dy-namics approach, Proceedings of the 6 In-ternational Conference onAdvanced Informa-tion Management and Service (IMS), IEEE,Seoul, pp. 1–6.


3820

Colombo, A.-W., Karnouskos, S. and Mendes,J.-M. (2010). Factory of the future: Aservice-oriented system of modular, dynamicreconfigurable and collaborative systems, inL. Benyoucef and B. Grabot (eds), ArtificialIntelligence Techniques for Networked Manu-facturing Enterprises Management, Springer,London, pp. 459–481.

de Deugd, S. et al. (2006). Soda: Service ori-ented device architecture, Pervasive Compu-ting, IEEE 5(3): 94–96.

Djurdjanovic, D., Lee, J. and Ni, J. (2003). Wat-chdog agentan infotronics-based prognosticsapproach for product performance degrada-tion assessment and prediction, AdvancedEngineering Informatics 17(34): 109–125.

Faccin, F. C. (2011). Manutencao inteligente: Fu-sao de sensores aplicada na deteccao de fa-lhas em atuadores eletricos, Projeto de diplo-macao (graduacao em engenharia eletrica),Universidade Federal do Rio Grande do Sul,Porto Alegre.

Goncalves, L. F. (2011). Desenvolvimento deum sistema de manutencao inteligente em-barcado, Tese (doutorado em engenharia ele-trica), Universidade Federal do Rio Grandedo Sul, Porto Alegre.

IMS CENTER (2007). Documentation of watch-dog agent toolbox algorithms.

Jay Lee (2003). E-manufacturing – funda-mental, tools, and transformation, Robo-tics and Computer-Integrated Manufacturing19(6): 501–507. Leadership of the Future inManufacturing.

Josuttis, N. (2009). SOA in Practice: The Art ofDistributed System Design, O’Reilly Media.

Karnouskos, S. et al. (2010). Towards an ar-chitecture for service-oriented process moni-toring and control, Proceedings of the 63thAnnual Conference on IEEE Industrial Elec-tronics Society (IECON), IEEE, Glendale,pp. 1385–1391.

Lee, J. et al. (2006). Intelligent prognos-tics tools and e-maintenance, Comput. Ind.57(6): 476–489.

Lee, J. et al. (2009). Informatics platform for de-signing and deploying e-manufacturing sys-tems, in L. Wang and A. Y. C. Nee (eds), Col-laborative Design and Planning for DigitalManufacturing, Springer, London, pp. 1–35.

Marcal, R. F. M. and Susin, A. A. (2005). Detec-tando falhas incipientes em maquinas rotati-vas, Revista Gestao Industrial 1(2).

MIMOSA (2014). OSA-CBM 3.3.0: Open systemsarchitecture for condition-based mainte-nance, http://www.mimosa.org/?q=resour-ces/specs/osa-cbm-330.

Muller, A., Suhner, M.-C. and Iung, B. (2008).Formalisation of a new prognosis model forsupporting proactive maintenance implemen-tation on industrial system, Reliability Engi-neering & System Safety 93(2): 234–253.

Oldham, J., James, P. and Shaw, B. (2003). De-livering resource productivity – the servicesolution, Green Alliance .

Papazoglou, M. P. and Heuvel, W.-J. (2007). Ser-vice oriented architectures: approaches, te-chnologies and research issues, The VLDBJournal 16(3): 389–415.

Ragavan, S. V., Kusnanto, I. K. and Ganapathy,V. (2012). Service oriented framework for in-dustrial automation systems, Procedia Engi-neering 41: 716–723.

Ramollari, E., Dranidis, D. and Simons, A. J.(2007). A survey of service oriented develop-ment methodologies, Proceedings of the 2ndEuropean Young Researchers Workshop onService Oriented Computing, Leicester, p. 75.

Ribeiro, L. et al. (2008). A generic communicationinterface for DPWS-based web services, Pro-ceedings of the 6th IEEE International Con-ference on Industrial Informatics (INDIN),IEEE, Daejeon, pp. 762–767.

Thurston, M. (2001). An open standard forweb-based condition-based maintenance sys-tems, Proceedings of the IEEE Systems Rea-diness Technology Conference AUTOTEST-CON, IEEE, Valley Forge, pp. 401–415.

W.J. Moore and A.G. Starr (2006). An intelli-gent maintenance system for continuous cost-based prioritisation of maintenance activi-ties, Computers in Industry 57(6): 595–606.E-maintenance Special Issue.

WS4D-JMEDS (2013). WS4D-JMEDS web ser-vices for devices, http://ws4d.e-technik.uni-rostock.de/jmeds.

Zhang, L., Cao, Q. and Lee, J. (2013). Per-formance assessment for a fleet of machinesusing a combined method of ant-based clus-tering and CMAC, Advances in MechanicalEngineering 2013.

Zhao, F. et al. (2010). SOA-based remote condi-tion monitoring and fault diagnosis system,The International Journal of Advanced Ma-nufacturing Technology 46(9-12): 1191–1200.


3821

Documents

PROPOSTA DE ARQUITETURA ORIENTADA A SERVICO˘ S … · PROPOSTA DE ARQUITETURA ORIENTADA A SERVICO˘ S PARA INTEGRAC˘AO~ DE UM SISTEMA DE MANUTENC˘AO INTELIGENTE~ Anderson Ant^onio