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

Transcrição

1 PROPOSTA DE ARQUITETURA ORIENTADA A SERVIÇOS PARA INTEGRAÇÃO DE UM SISTEMA DE MANUTENÇÃO INTELIGENTE Anderson Antônio Giacomolli, Thiago Regal da Silva, Carlos Eduardo Pereira, Renato Ventura Bayan Henriques Departamento de Engenharia Elétrica Universidade Federal do Rio Grande do Sul (UFRGS) Av. Osvaldo Aranha, 103 Porto Alegre, RS, Brasil s: anderson.giacomolli@ufrgs.br, thiago.regal@ufrgs.br, cpereira@ece.ufrgs.br, rventura@ece.ufrgs.br Abstract The costs associated with equipments maintenance still represent a large portion of the resources available to a company. Therefore, the improvement of maintenance techniques, and development of the new ones, are growing, since they impact directly on the economic side of the companies. Thus, the current work presents a service-oriented architecture proposal for an intelligent maintenance system. The architecture intends to 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 manutenção de equipamentos ainda representa uma grande parcela dos investimentos no setor industrial. Portanto, o desenvolvimento de novas técnicas de manutenção, bem como o aperfeiçoamento das já existentes, cada vez é tido como foco nas corporações, por impactarem diretamente no fator econômico das empresas. Dessa forma, o trabalho em questão apresenta a proposta de uma arquitetura orientada para integração de sistemas de manutenção inteligente. A arquitetura tem por objetivo a integração de equipamentos e ferramentas, visando melhorar o processo de obtenção dos índices de saúde dos equipamentos. Palavras-chave Sistemas. Sistemas de Manutenção Inteligente, Arquiteturas Orientadas a Serviços, Integração de 1 Introdução Atualmente, a importância do emprego de técnicas de manutenção no âmbito industrial está em constante ascensão devido à necessidade de aumentar a disponibilidade e segurança dos equipamentos, bem como a qualidade do processo produtivo (Muller et al., 2008). Dessa forma, o desenvolvimento de novas técnicas de manutenção para uso nas mais diversas áreas e o correto planejamento dos processos de manutenção estão cada vez mais importantes, uma vez que impactam diretamente no fator econômico, alterando a disponibilidade do sistema e também a segurança (Zhao et al., 2010). Nos últimos anos, tem-se observado um crescimento no uso de um novo paradigma de manutenção denominado de manutenção inteligente (Zhang et al., 2013). Diferentemente dos métodos tradicionais, conhecidos por aplicar o conserto aos equipamento somente após a falha ou por manterem processos de manutenção agendados baseado no histórico de falhas dos componentes, o paradigma de manutenção inteligente visa predizer a condição do sistema e prevenir uma possível falha. Outra linha de pesquisa também está em constante crescimento: o uso de Service-Oriented Architecture (SOA) ou Arquiteturas Orientadas a Serviços. O uso do padrão SOA está evoluindo e está cada vez mais presente em aplicações nos mais diversos segmentos, sejam eles a nível de, na implementação de camadas de negócios ou mesmo no setor industrial, como apresentado em (Papazoglou and Heuvel, 2007), (Ragavan et al., 2012) e (Choi et al., 2010). É um conceito de arquitetura que suporta acoplamento mínimo entre componentes, possibilitando ganhos em flexibilidade e interoperabilidade. Por conseguinte, qualquer tipo de aplicação pode ser representada como um conjunto complexo s, inclusive no âmbito industrial (Bohn et al., 2006), (de Deugd et al., 2006), (Colombo et al., 2010) e (Karnouskos et al., 2010). Nesse contexto, um sistema de manutenção inteligente também pode se valer da utilização dos conceitos empregados pelo padrão SOA. Do ponto de vista da arquitetura SOA, o sistema de manutenção pode conter serviços para relatórios de saúde e falhas, informações sobre o prognóstico do tempo de operação sem necessidade de manutenção, além s de configuração de ferramentas de diagnóstico ou dos modos de operação suportados pelo equipamento. O monitoramento remoto do sistema também possibilita a integração das informações de saúde dos equipamentos em sistemas Manufacturing Execution Systems (MES) e Enterprise Resource Planning (ERP), a fim de se obter o correto gerenciamento da cadeia de suprimentos de peças de reposição (Oldham et al., 2003). 3814

2 Com base nestes aspectos, o presente artigo aborda a definição de uma arquitetura orientada para integração de diferentes componentes que fazem parte de um sistema de manutenção inteligente. Os componentes são abstraídos como entidades SOA e casos de uso ilustram diferentes cenários para a utilização da proposta. Dessa forma, este trabalho está estruturado da seguinte maneira: na seção 2 é apresentada uma análise do estado da arte, cobrindo os dois assuntos principais empregados no artigo; a seção 3 apresenta a proposta de arquitetura; na seção 4 é apresentada a implementação da proposta e resultados; e, por fim, a seção 5 apresenta as conclusões. 2 Sistemas de Manutenção Inteligente e Arquiteturas Orientadas a Serviços Nesta seção são apresentados os conceitos de sistemas de manutenção inteligente e arquiteturas orientadas, utilizados como base para a construção da arquitetura proposta. 2.1 Sistemas de Manutenção Inteligente Em uma visão geral, manutenção consiste de uma série de medidas de prevenção, correção e predição de falhas (Lee et al., 2006). Equipamentos ou máquinas tendem a deteriorar e alterar o seu padrão de funcionamento durante o uso devido a diversos fatores, como desgaste, rachaduras, corrosão ou sujeira. Nessas condições, torna-se imprescindível a restauração do sistema, a fim de evitar defeitos que podem ocasionar falhas ou indisponibilidades (Marçal and Susin, 2005). Três estratégias de manutenção são encontradas na literatura clássica: corretiva, preventiva e preditiva (Marçal and Susin, 2005). A corretiva visa reestabelecer o sistema danificado; a preventiva se objetiva a manter o sistema funcionando; e a preditiva visa monitorar o sistema, detectando falhas insipientes e fornecendo meios para o planejamento de ações preventivas ou corretivas. Uma quarta estratégia, que está ganhando força nos últimos anos, é denominada de manutenção proativa ou manutenção inteligente (Lee et al., 2009). Este novo paradigma está em acensão como substituto das estratégias de manutenção preventiva. A nova estratégia visa não somente a predição do estado do sistema, mas também o diagnóstico de falhas e a intervenção de forma automática. Dessa forma, no caso de falhas repentinas, o próprio sistema pode se ajustar para tomar decisões em relação à falha ocorrida (Gonçalves, 2011). A fim de prover uma plataforma flexível e funcional para integrar uma variedade de sistemas de software e hardware, o Open Systems Architecture for Condition-Based Maintenance (OSA-CBM) foi criado (Thurston, 2001). O padrão tem como objetivo definir uma convenção para troca de dados entre elementos. A arquitetura OSA-CBM é descrita de acordo com sete camadas funcionais, ilustradas na fig. 1 (MIMOSA, 2014). As duas primeiras camadas, aquisição e manipulação de dados, definem o modo como os dados de sensores ou transdutores são obtidos, digitalizados e quais manipulações de sinais são realizadas. A camada seguinte, identificada como detecção do estado do sistema, recebe os dados dos sensores e os compara com valores previamente definidos, gerando alertas quando os limites definidos forem ultrapassados. A camada de avaliação da saúde do sistema recebe dados da camada anterior e determina se o sistema está degradando. Na camada de prognóstico, o tempo de utilização restante do equipamento é estimado, levando em conta padrões futuros de utilização. A camada seguinte, tomada de decisão, tem por objetivo gerar ações de utilização para que os equipamentos preservem as condições de saúde até que a próxima falha ocorra, levando em conta o histórico de operações e outros indicadores. A última camada, apresentação, é responsável por prover meios de visualização dos dados obtidos 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. Vários trabalhos conduzem o desenvolvimento de técnicas e metodologias para problemas relacionados a manutenção de predição e prevenção (Jay Lee, 2003), (Lee et al., 2006), (W.J. Moore and A.G. Starr, 2006). Neste meio, o Intelligent Maintenance System Center (IMS Center) propôs uma das mais importantes ferramentas neste segmento, denominada Watchdog Agent (Djurdjanovic et al., 2003). O Watchdog Agent é um software composto por vários algoritmos para análise do desempenho do sistema, e que permite analisar diferentes partes de equipamentos, a fim de obter um indicador. É composto por módulos, estruturados de acordo com o modelo de camadas OSA-CBM. O Watchdog Agent permite a manipulação de dados e extração de padrões de sinais. O software dispõe de um conjunto de ferramentas como Transformada Rápida de Fourier, Transformada Wavelet, Regressão Logística e Reconhecimento Estatístico de Padrões (IMS CENTER, 2007). 3815

3 Combinando estas ferramentas, juntamente com dados dos sensores, é possível predizer a degradação do sistema e avaliar o estado dos equipamentos. 2.2 Arquiteturas Orientadas a Serviços Técnicas para desenvolvimento de aplicações SOA representam uma mudança de paradigma na engenharia de software, onde os componentes são definidos como serviços (Ramollari et al., 2007). Estas técnicas, inicialmente desenvolvidas para uso em ambiente gerencial e corporativo de empresas, logo teve aceitação em diversos segmentos, entre eles, a automação industrial. De forma geral, arquiteturas SOA têm como característica principal a criação e disponibilidade s, que, quando agrupados, dão origem a um sistema funcional (Josuttis, 2009). O termo serviço se refere a uma funcionalidade ou lógica que é encapsulada e oferecida ao sistema através de uma interface. Dessa maneira, outros serviços, entidades ou programas são capazes de acessá-lo e empregá-lo na resolução de determinada tarefa. Para que possam ser utilizados, os serviços necessitam de exposição, a fim de que os utilizadores os encontrem (Papazoglou and Heuvel, 2007). Portanto, uma aplicação SOA deve prover meios para que os serviços possam se comunicar e efetuar a troca de informações de forma padronizada. Dessa forma, todos os componentes da arquitetura devem obedecer a alguns conceitos, entre eles: acoplamento mínimo, a fim de minimizar a dependência de outros serviços; contrato, utilizando um mesmo padrão de comunicação; autonomia, sendo o próprio serviço responsável pelas tarefas que executa; abstração, escondendo a lógica e recursos utilizados; reuso, possibilitando a utilização da mesma funcionalidade em várias partes do sistema; composição, tendo objetivo de organizar um conjunto s para a execução de uma tarefa mais complexa; independência de estado, onde o serviço não retém informações sobre as atividades executadas; e possibilidade de descoberta, que permite a outros serviços encontrá-lo (Josuttis, 2009). A troca de informações entre os serviços normalmente ocorre utilizando o protocolo Simple Object Access Protocol (SOAP). Neste protocolo, as mensagens são codificadas no formato Extensible Markup Language (XML). O protocolo SOAP pode ser utilizado sobre diferentes protocolos de transporte, como, por exemplo, o Hypertext Transfer Protocol (HTTP). A descrição das interfaces dos serviços são realizadas utilizando Web Service Description Language (WSDL). Documentos WSDL também são baseados em XML e contém a informação necessária para utilização do serviço descrito. Nos documentos WSDL são descritas todas as operações que o serviço possibilita, bem como os tipos de dados por ele suportados. O documento também pode ser estendido, definindo novos tipos de dados para troca de mensagens. Em uma aplicação SOA, a descrição dos serviços disponíveis e o endereço para acessá-los estão disponíveis no Universal Description Discovery Integration (UDDI). O padrão UDDI define o protocolo para os serviços de diretório, ou intermediadores, onde são armazenadas as informações de cada um dos serviços da aplicação. Esta entidade é utilizada para informar aos clientes quais serviços estão disponíveis, possibilitando meios para descoberta e obtenção de. A interoperabilidade entre os componentes de uma aplicação SOA é apresentada na fig. 2. Consumidor de serviço Pesquisa Cliente Registro de serviço Conexão e invocação Registro Contrato de serviço Serviço Provedor de serviço Figura 2: Interoperabilidade entre os elementos de uma aplicação SOA. As especificações para web services normalmente seguem o padrão de grafia WS- (Candido, 2013). Porém, dentre as especificações, o Devices Profile for Web-Services (DPWS) define um conjunto mínimo de implementações que permitem a troca de mensagens, descoberta, descrição, geração de eventos e autenticação para a utilização de web services em clientes com recursos computacionais limitados (Ribeiro et al., 2008). Apesar de utilizar um conjunto mínimo de implementações, clientes que utilizam DPWS podem ser integrados a outros, com recursos mais flexíveis. O DPWS utiliza uma pilha de protocolos e especificações para consistência na conexão entre os. Dentre as especificações, destacamse o WS-Addressing, utilizado para a transferência de mensagens, o WS-Discovery, que possibilita a descoberta s em uma rede local, e o WS- Eventing, para a utilização de eventos. O DPWS utiliza os protocolos Transmission Control Protocol (TCP) e HTTP para a transmissão de dados. 3 Arquitetura proposta Um sistema de manutenção inteligente deve ser composto por a serem analisados, instrumentados para obtenção dos dados de sensores, e um analisador de dados, que irá determinar o nível de degradação dos equipamentos (Lee et al., 2006). Contudo, as técnicas utilizadas atualmente necessitam que os dados sejam obtidos e 3816

4 analisados separadamente dos equipamentos (IMS CENTER, 2007). O tempo envolvido na instrumentação do equipamento, obtenção dos dados e posterior análise, se replicado para um número elevado de, torna a análise das condições de degradação uma tarefa complexa e despendiosa. Tecnologias SOA estão cada vez mais presentes na indústria e o seu uso reflete a busca pela interconexão de distribuídos (Cannata et al., 2010). A padronização da comunicação entre componentes e a facilidade de construção de novas aplicações estão entre as principais vantagens. Portanto, esta técnica também pode ser aplicada no desenvolvimento de aplicações de manutenção inteligente. A fim de possibilitar a integração dos diversos equipamentos que fazem parte de um sistema de manutenção inteligente, uma arquitetura baseada em SOA foi definida, sendo composta por entidades de software, cada uma responsável por uma tarefa específica. As entidades são aplicativos que se comunicam por meio s e foram identificadas com base nos requisitos da aplicação. Dessa forma, a integração do sistema é realizada por um conjunto s bem definido. Esta seção apresenta a arquitetura proposta e casos de uso, ilustrando algumas situações onde o sistema pode ser empregado. 3.1 Proposta de Arquitetura Orientada a Serviços Neste trabalho, optou-se por utilizar uma arquitetura SOA para integrar de forma facilitada as entidades do sistema. A fig. 3 ilustra as entidades principais da arquitetura proposta. Cada entidade é um componente SOA, responsável por desempenhar uma tarefa específica na aplicação, sendo implementados utilizando a especificação DPWS. Neste contexto, as entidades são conectadas por serviços web. A arquitetura conta com seis entidades:, de s, de Análises, Analisador de s, Base de Dados e Repositório de Serviços. A entidade identificada por é um componente de software utilizado para abstrair um elemento físico da arquitetura proposta. O dispositivo em questão é denominado de lógico, por executar embarcado em um dispositivo físico. Pode abrigar funcionalidades relativas ao dispositivo físico ou outras, que auxiliam em alguma tarefa específica não relacionada diretamente com o hardware hospedeiro. A entidade controla o dispositivo físico, obtendo os dados de sensores e enviando para um banco de dados. O também pode apresentar, definidos como o modo de operação que o equipamento irá assumir frente às condições de degradação. O de s, como o nome Base de dados de s Analisador de Repositório s Serviços Figura 3: Arquitetura orientada proposta para integração de um sistema de manutenção inteligente. sugere, possui as ferramentas necessárias para o gerenciamento dos na rede. A obtenção da lista de e configuração de cada um deles são tarefas executadas pelo gerenciador. Como exemplo de configuração está o envio de novos para o dispositivo. O de Análises é utilizado para o gerenciamento de planos de equipamentos pelo operador do sistema. O plano é a estrutura que armazena as informações necessárias para que uma análise de degradação de um equipamento possa ser executada corretamente. O de Análises possibilita o agendamento dos planos e a definição de execuções periódicas das análises. No Analisador de s os planos são executados. A entidade opera com base nos planos criados pelo operador do sistema no de Análises. O analisador possui as ferramentas necessárias para manipulação dos dados dos equipamentos e obtenção dos indicadores de saúde. A entidade Base de Dados é utilizada como uma interface para um banco de dados. No banco de dados são armazenadas todas as informações da aplicação. Para garantir a estrutura de uma aplicação SOA, a entidade foi especificada com o intuito de abstrair os acessos ao banco através de serviços. O Repositório de Serviços armazena os lógicos e seus serviços, os quais podem ser obtidos e implantados dinamicamente em físicos. Esta entidade pode fazer parte da rede local ou remota. Dessa forma, uma nova aplicação pode ser construída com base em componentes já definidos. Com esta abordagem, também é possível o compartilhamento de uma base de dados de componentes lógicos entre diferentes aplicações. 3.2 Casos de uso para a arquitetura proposta No contexto de uma aplicação de manutenção inteligente, a arquitetura aqui proposta pode ser empregada em alguns casos de uso. Os casos 3817

5 de uso apresentados neste trabalho exemplificam a interação do operador do sistema na busca ou configuração de e na criação de planos para determinado equipamento. Da mesma forma, para a execução dos planos agendados pelo operador do sistema, foi utilizado um ator denominado de tarefa periódica. A descoberta e configuração dos é representada pelo diagrama Unified Modeling Language (UML) de casos de uso da fig. 4. No diagrama são ilustradas as interações que o operador do sistema pode realizar nos utilizando o de s. De acordo com o diagrama, o gerenciador permite a visualização dos encontrados na aplicação orientada, a busca de informações mais detalhadas, através de, bem como a sua configuração, com atualização das informações e envio de novos. Operador do sistema de análises Remover plano Criar plano Editar plano Verificar recursos disponíveis ferramentas Base de dados Remover plano Inserir plano plano 1 estado n Analisador de ferramentas Operador do sistema de Descobrir e serviços <extends> topologia dos Atualizar do dispositivo estado Atualizar 1 2 n atualização dos estado Figura 5: Diagrama de casos de uso para o gerenciamento s pelo operador do sistema. de casos de uso da fig. 6. Operador do sistema de Descobrir e serviços Enviar dados de treinamento Base de dados Inserir dados de treinamento Figura 4: Diagrama de casos de uso para descoberta e configuração de. O gerenciamento dos planos pelo operador do sistema é ilustrado no diagrama UML da fig. 5. Novos planos podem ser criados e associados a determinado equipamento, a fim de obter os indicadores de desempenho para tomada de decisão. Além das informações associado à análise, o plano também armazena as ferramentas, presentes no Analisador de s, que serão utilizadas e os que o dispositivo deve assumir dado o resultado obtido com a análise. Como, entende-se as ações realizadas pelo equipamento a fim de garantir a operação até que uma manutenção corretiva possa ser realizada. Para a obtenção dos índices de degradação, as ferramentas necessitam de dados de treinamento do equipamento. O de s dispõe de meios para o envio destes dados. O envio de dados de treinamento pelo operador do sistema é apresentado no diagrama UML Figura 6: Diagrama de casos de uso para envio de dados de treinamento para um dispositivo. A execução das análises dos é feita automaticamente por uma tarefa periódica. No plano, o operador do sistema define a frequência de execução para cada equipamento e, baseado nisso, uma tarefa periódica é executada no Analisador de s. O analisador verifica quais os planos estão ativos, os carrega e executa. Na execução, os dados do são obtidos e analisados pelas ferramentas definidas no plano pelo operador do sistema. Após finalizada a análise, e baseado no indicador de degradação obtido, o equipamento pode ser sinalizado a assumir um comportamento diferente, a fim de evitar uma maior degradação até que uma manutenção corretiva possa ser efetuada. A fig. 7 ilustra o diagrama UML de casos de uso para a execução dos planos. Relatórios de saúde dos equipamentos em análise podem ser obtidos através do de 3818

6 Anais do XX Congresso Brasileiro de Automática Analisador de planos ativos e implementada, foi escolhido um estudo de caso que consiste em um conjunto atuador ele trico e va lvula. O atuador em questa o e utilizado para o controle de fluxo em redes de distribuic a o de petro leo, permitindo abertura e fechamento dos dutos pelo movimento da haste, cujo acionamento e feito por um motor. O conjunto, modelo CSR6, fabricado pela empresa Coester Automac a o Ltda, e ilustrado na fig. 9. Por se tratar de um equipamento sujeito a degradac a o constante, foi escolhido como estudo de caso. Base de dados <extends> plano Inserir resultados da análise Carregar plano Tarefa periódica plano Executar plano Selecionar ferramenta dados brutos dados Verificar recursos disponíveis estado Figura 7: Diagrama de casos de uso para a obtenc a o e execuc a o das ana lises. s, entidade que se comporta como interface entre o operador do sistema e os que compo e a arquitetura. E possibilitado ao operador do sistema realizar a busca pelos na rede e obter os resultados das ana lises anteriores. Na arquitetura proposta, os resultados das ana lises sa o armazenados na Base de Dados. A fig. 8 apresenta o diagrama UML para obtenc a o dos relato rios de sau de de um dispositivo pelo operador do sistema. Figura 9: Atuador ele trico modelo CSR6. Neste trabalho, utilizou-se os dados de instrumentac a o obtidos nos trabalhos de (Bo esch, 2011) e (Faccin, 2011) com intuito de avaliar somente o comportamento das entidades da arquitetura proposta. Dessa forma, a entidade denominada (fig. 3) foi utilizada como um simulador a ser monitorado, utilizando os dados de sensores previamente obtidos. O atuador ele trico foi instrumentado com tre s sensores, sendo realizados seis testes, conforme tab. 1 Base de dados de relatório do dispositivo Descobrir e serviços Operador do Sistema relatório das análises Tabela 1: Situac o es definidas para coleta dos dados. 1 Figura 8: Diagrama de casos de uso para obtenc a o dos relato rios de sau de. 4 Situac a o Acionamento do freio Engrenagens bar 3 bar 1 desgastada 3 desgastadas 1 quebrada <extends> As engrenagens utilizadas nos testes, presentes no conjunto de engrenagens sate lite do atuador, sa o ilustradas na fig. 10. A da esquerda e uma engrenagem normal, a do meio desgastada e a da direita com dentes quebrados. A ana lise de degradac a o foi feita a partir dos dados de vibrac a o do atuador. Primeiramente foram extraı das as caracterı sticas dos sinais utilizando a transformada de wavelet packet. Apo s, o algoritmo de detecc a o de falhas foi treinado com o me todo da Regressa o Logı stica utilizando, para isso, dados de funcionamento normal e em falha. A fig. 11 apresenta a tela do aplicativo implementado a partir da arquitetura pro- Implementac a o e resultados Para validac a o da arquitetura proposta, as entidades descritas na sec a o 3 foram implementadas. Para a implementac a o das entidades escolheuse a linguagem de programac a o Java e a implementac a o DPWS denominada Java Multi Edition DPWS Stack (JMEDS), que faz parte do projeto WS4D (WS4D-JMEDS, 2013). As entidades sa o aplicativos de ambiente gra fico que permitem realizar as operac o es descritas nos casos de uso apresentados. Como forma de avaliar a arquitetura proposta 3819

7 Engrenagem normal Engrenagem desgastada Engrenagem quebrada Figura 10: Engrenagens utilizadas no estudo de caso. posta. Como mencionado, o aplicativo é utilizado para simular os dados de uma das seis situações apresentadas na tab. 1. Figura 13: Tela principal do Analisador de s. Neste trabalho, uma arquitetura orientada para um sistema de manutenção inteligente foi proposta, a fim de facilitar a integração entre os diferentes componentes envolvidos neste tipo de aplicação. Foram definidas e apresentadas as entidades que fazem parte da arquitetura e casos de uso onde a proposta pode ser empregada. Além disso, foi apresentada a implementação das entidades e um estudo de caso específico para validação da proposta. Referências Figura 11: Tela principal do simulador de. A definição de um plano para o dispositivo é feita no de Análises. Uma das telas do software é apresentada na fig. 12. A tela ilustra a escolha das ferramentas que serão utilizadas para determinar o nível de degradação do equipamento em análise. Figura 12: Diálogo para escolha das ferramentas utilizadas na análise. O Analisador de s, que utiliza as informações definidas no plano, realiza as análises de forma automática. A entidade verifica os planos pendentes, busca os dados necessários e obtém o nível de degradação utilizando as ferramentas definidas no plano. A fig. 13 ilustra a tela principal do Analisador de s. 5 Conclusão O monitoramento de diversos equipamentos com técnicas de manutenção inteligente ainda é dificultado pelo tipo de solução adotada para análise dos dados e pela distribuição dos. Bohn, H., Bobek, A. and Golatowski, F. (2006). Sirena service infrastructure for realtime embedded networked devices: A service oriented framework for different domains, Proceedings of the International Conference on Networking Systems and International Conference on Mobile Communications and Learning Technologies, IEEE, Mauritius, pp Böesch, K. (2011). Detecção de falhas por fusão de sensores em atuadores elétricos, Projeto de diplomação (graduação em engenharia elétrica), Universidade Federal do Rio Grande do Sul, Porto Alegre. Candido, G. (2013). Service-Oriented Architecture for device lifecycle support in industrial automation, Tese (doutorado em engenharia eletrotécnica e de computadores), Universidade Nova de Lisboa, Portugal. Cannata, A., Karnouskos, S. and Taisch, M. (2010). Dynamic e-maintenance in the era of SOA-ready device dominated industrial environments, in D. Kiritsis et al. (eds), Engineering Asset Lifecycle Management, Springer, London, pp Choi, J., Nazareth, D. and Jain, H. (2010). The impact of SOA implementation strategies on business value and agility: A systems dynamics approach, Proceedings of the 6 International Conference onadvanced Information Management and Service (IMS), IEEE, Seoul, pp

8 Colombo, A.-W., Karnouskos, S. and Mendes, J.-M. (2010). Factory of the future: A service-oriented system of modular, dynamic reconfigurable and collaborative systems, in L. Benyoucef and B. Grabot (eds), Artificial Intelligence Techniques for Networked Manufacturing Enterprises Management, Springer, London, pp de Deugd, S. et al. (2006). Soda: Service oriented device architecture, Pervasive Computing, IEEE 5(3): Djurdjanovic, D., Lee, J. and Ni, J. (2003). Watchdog agentan infotronics-based prognostics approach for product performance degradation assessment and prediction, Advanced Engineering Informatics 17(34): Faccin, F. C. (2011). Manutenção inteligente: Fusão de sensores aplicada na detecção de falhas em atuadores elétricos, Projeto de diplomação (graduação em engenharia elétrica), Universidade Federal do Rio Grande do Sul, Porto Alegre. Gonçalves, L. F. (2011). Desenvolvimento de um sistema de manutenção inteligente embarcado, Tese (doutorado em engenharia elétrica), Universidade Federal do Rio Grande do Sul, Porto Alegre. IMS CENTER (2007). Documentation of watchdog agent toolbox algorithms. Jay Lee (2003). E-manufacturing fundamental, tools, and transformation, Robotics and Computer-Integrated Manufacturing 19(6): Leadership of the Future in Manufacturing. Josuttis, N. (2009). SOA in Practice: The Art of Distributed System Design, O Reilly Media. Karnouskos, S. et al. (2010). Towards an architecture for service-oriented process monitoring and control, Proceedings of the 63th Annual Conference on IEEE Industrial Electronics Society (IECON), IEEE, Glendale, pp Lee, J. et al. (2006). Intelligent prognostics tools and e-maintenance, Comput. Ind. 57(6): Lee, J. et al. (2009). Informatics platform for designing and deploying e-manufacturing systems, in L. Wang and A. Y. C. Nee (eds), Collaborative Design and Planning for Digital Manufacturing, Springer, London, pp Marçal, R. F. M. and Susin, A. A. (2005). Detectando falhas incipientes em máquinas rotativas, Revista Gestão Industrial 1(2). MIMOSA (2014). OSA-CBM 3.3.0: Open systems architecture for condition-based maintenance, Muller, A., Suhner, M.-C. and Iung, B. (2008). Formalisation of a new prognosis model for supporting proactive maintenance implementation on industrial system, Reliability Engineering & System Safety 93(2): Oldham, J., James, P. and Shaw, B. (2003). Delivering resource productivity the service solution, Green Alliance. Papazoglou, M. P. and Heuvel, W.-J. (2007). Service oriented architectures: approaches, technologies and research issues, The VLDB Journal 16(3): Ragavan, S. V., Kusnanto, I. K. and Ganapathy, V. (2012). Service oriented framework for industrial automation systems, Procedia Engineering 41: Ramollari, E., Dranidis, D. and Simons, A. J. (2007). A survey of service oriented development methodologies, Proceedings of the 2nd European Young Researchers Workshop on Service Oriented Computing, Leicester, p. 75. Ribeiro, L. et al. (2008). A generic communication interface for DPWS-based web services, Proceedings of the 6th IEEE International Conference on Industrial Informatics (INDIN), IEEE, Daejeon, pp Thurston, M. (2001). An open standard for web-based condition-based maintenance systems, Proceedings of the IEEE Systems Readiness Technology Conference AUTOTEST- CON, IEEE, Valley Forge, pp W.J. Moore and A.G. Starr (2006). An intelligent maintenance system for continuous costbased prioritisation of maintenance activities, Computers in Industry 57(6): E-maintenance Special Issue. WS4D-JMEDS (2013). WS4D-JMEDS web services for devices, Zhang, L., Cao, Q. and Lee, J. (2013). Performance assessment for a fleet of machines using a combined method of ant-based clustering and CMAC, Advances in Mechanical Engineering Zhao, F. et al. (2010). SOA-based remote condition monitoring and fault diagnosis system, The International Journal of Advanced Manufacturing Technology 46(9-12):