Raciocínio Baseado em Casos Aplicado a um Sistema de Diagnóstico Remoto

Silvio Luiz Plotegher Marcio Merino Fernandes

Universidade Metodista de Piracicaba Campus Taquaral - Piracicaba - SP

splotegher@romi.com.br, mmfernan@unimep.br

Abstract. This paper describes an industrial Remote Diagnostic System(RDS) applied to machine tools. Such a system targets current platforms of Computerized Numerical Control (CNC) machines , combining the RDS with Case Based Reasoning (CBR) techniques in order to minimize the maintenance costs and machine idle time. Practical studies were conducted in order to propose a communication link between the technical service staff and the shopfloor. The results has shown a considerable reduction in maintenance costs and machine idle time when using the existing knowledge base.

Resumo. Este artigo descreve um Sistema de Diagnóstico Remoto (SDR) para ambiente industrial aplicado em máquinas-ferramenta (MF). Este sistema baseia-se nas atuais arquiteturas do Comando Numérico Computadorizado (CNC), combinado o SDR com o uso do método de Raciocínio Baseado em Casos (RBC), objetivando reduzir os tempos e custos de manutenção e assistência técnica, aumentando a disponibilidade das máquinas em operação. Foram utilizados estudos práticos para propor uma arquitetura de comunicação entre o pessoal da assistência técnica e chão de fábrica. Os resultados obtidos mostraram reduções consideráveis nos custos de manutenção e de máquinas parada.

XXXII SEMISH 1716

1. Introdução Sistemas industriais modernos são constituídos por uma combinação de dispositivos avançados de hardware e software, os quais freqüentemente trabalham de forma colaborativa a fim de atingir seus objetivos finais. Esse modelo indiscutivelmente aprimora a qualidade e estende a capacidade de produção. Todavia, o gerenciamento desse modelo constitui-se uma tarefa complexa, uma vez que a manutenção e configuração de sistemas complexos interagindo entre si não é trivial. Procedimentos de manutenção em particular são críticos uma vez que podem exigir a paralisação de um ou mais setores da empresa. Logo, minimizar o tempo para diagnosticar e corrigir um dado defeito possui alta prioridade, o que infelizmente nem sempre é conseguido. Por outro lado é comum um determinado problema de manutenção repetir-se diversas vezes, seja em um mesmo dispositivo, ou em similares localizados em algum outro lugar. Infelizmente o conhecimento gerado para a resolução de tais problemas não é armazenado de forma estruturada a fim de ser utilizado eficientemente no futuro. Nesse contexto, este artigo apresenta um sistema para diagnóstico remoto (SDR) utilizando o método de raciocínio baseado em casos (RBC). O SDR, em sua versão inicial, é voltado para diagnóstico em máquinas do tipo comando numérico computadorizado (CNC). Porém, a arquitetura e funcionamento do sistema pode ser facilmente adaptada para outros domínios de aplicações. Considerando a complexidade dos ambientes industriais, principalmente das máquinas a CNC e, a escassez de trabalhos relacionados, o sistema proposto adapta os recursos da computação, dentro da sua universalidade, contribuindo de forma inovadora, como meio de atender as diferentes necessidades presentes nestes ambientes.

O restante deste artigo está organizado da seguinte forma: a próxima seção (2) apresenta alguns trabalhos relacionados com a tarefa de diagnóstico remoto de sistemas complexos. A seção seguinte (3) descreve a arquitetura do SDR, seguindo-se a apresentação da implementação do protótipo correspondente (4). Na seção (5) são apresentados alguns resultados experimentais obtidos através da utilização do protótipo em um ambiente industrial. Finalmente, a seção (6) traz as conclusões deste artigo.

2. Trabalhos Relacionados Diversas abordagens podem ser encontradas na literatura para a construção de sistemas de diagnóstico remoto, conforme descrito a seguir.

[LEE e HSU 2002] descreve um sistema de monitoramento como um componente importante na automação dos sistemas de manufatura, monitorando processos, detectando anormalidades, dentre outras. Na abordagem apresentada por [MANSOR et al 2000] as redes de comunicação, no campo da engenharia, podem ser usadas para o desenvolvimento de sistemas de monitoramento remoto e controle. [INOUE et al 2002], apresenta um modelo de atualização de programas e algoritmos em uma arquitetura mais complexa de computadores. No que denomina de “Método Convencional”, isto é, em uma arquitetura remota, os programas precisariam ser atualizados, parametrizados e instalados previamente nos computadores. Um sistema para aquisição de dados de vibração em máquinas rotacionais é descrito por

XXXII SEMISH 1717

[BELLAMINE et al 2003]. Este modelo procura integrar uma metodologia para, remotamente, monitorar e diagnosticar máquinas em um ambiente industrial.

A arquitetura de monitoramento e controle proposta por [HUNG et al 2004] é denominada de WEB-Services-Based (WSB)1. É uma arquitetura de monitoramento e controle com a capacidade de proteger os dispositivos sob monitoração. [RENTON et al 2002] apresenta uma arquitetura que permite integrar softwares avançados de simulação em processos de usinagem com máquinas controladas por Comando Numérico Computadorizado (CNC). Estas máquinas são equipadas com o que o autor classifica de sistema de monitoramento remoto de máquinas, objetivando criar um ambiente de otimização virtual dos processos de manufatura, ou seja, dos processos de usinagem de peças. Numa abordagem que descreve um experimento específico aplicado na área de automação industrial. [TAN e WANG 2002] apresenta uma proposta a qual baseia-se no uso da INTERNET para implementar um sistema de monitoramento remoto e diagnóstico de falhas em equipamento localizado, no que o autor denomina de, longa distância.

Sistemas de diagnóstico remoto e monitoramento ultrapassam a barreira de aplicações industriais. Constata-se nas literaturas, várias aplicações na área médica, por exemplo. As diferenças básicas notadas estão quase sempre ao nível do que se pretende monitorar, ou seja, tratamento de sinais elétricos, tipos de dados, dentre outros. No entanto, a conceituação de comunicação remota se aplica em ambos. Um exemplo disso é o sistema descrito em [JANNETT et al 2002], abordando um modelo de diagnóstico remoto para pacientes que apresentam problemas pulmonares ou passaram por transplantes de pulmão. Sua arquitetura constitui o que a autora chama de Sistema de Telemedicina Inteligente. [DUMER et al 2002] descreve um sistema denominado como RMED – Remote Medical Evaluation and Diagnostics (Sistema Remoto para Avaliação e Diagnóstico Médico) o qual combina as capacidades de um monitoramento remoto com tecnologia inteligente de suporte a decisão.

Comparativamente, observa-se nas diversas abordagens, uma preocupação com modelos determinísticos e pouco adaptáveis a outros domínios de aplicação. Nestas abordagens nota-se uma preocupação maior com o meio físico da comunicação remota do que com o aspecto computacional, motivando dessa forma, a proposta da arquitetura do SDR.

3. Arquitetura Proposta do SDR O SDR proposto neste artigo consiste de uma arquitetura principal, conforme ilustra a Figura 1, que se convencionou chamar de Arquitetura 1, ou Arquitetura Básica2. A comunicação da MF com o computador, que está especificado na arquitetura, deve significar que, através de um meio físico apropriado, seja possível conectar o CNC de uma MF a um computador, cuja localização geográfica seja diferente da localização

1 Serviço Baseado em uma Arquitetura WEB, posto que o autor considera a INTERNET como meio físico de comunicação de seu modelo proposto e, segundo, sua proposta, seu modelo foi testado em um sistema de Monitoramento e Controle de Residências. 2 Arquitetura, neste caso, deve significar o método e as tecnologias envolvidas cujo uso e aplicação permitam a comunicação entre uma MF e um computador.

XXXII SEMISH 1718

geográfica de uma MF sob monitoração. A escolha desta arquitetura básica, baseou-se principalmente, nos seguintes aspectos:

• Inexperiência anterior em diagnosticar remotamente as máquinas-ferramenta com CNC. Comunicação via linha telefônica teriam menor impacto no ambiente industrial e na própria configuração dos CNC;

• Algumas das plataformas de CNC usadas na automação não dispõem de meios de conexão através de Ethernet. Configurações com redes Ethernet envolveriam um custo inicial alto, exigindo atualizações de hardware e software. No entanto, onde possível, sinais de vídeo via WEB foram considerados;

• Desconhecimento de como o cliente iria reagir pelo fato de ter seu equipamento sob monitoração, devido a um problema de ordem cultural, abordado inclusive por [NEMES et al 2003];

• Propor uma arquitetura que trouxesse o menor impacto de custos na implementação.

Figura 1. Arquitetura do SDR

Central de Atendimento Ambiente Industrial

Chão de Fábrica 1

Máquina 1

Máquina n

MODEM

MODEM

Chão de Fábrica n Máquina

1

Máquina n

MODEM

MODEM

MODEM

MODEM

MODEM

MODEM

Servidor

BD

Aquisição e Tratamento de

Dados

Internet

Seleção / Comunicação

BC RBC

XXXII SEMISH 1719

Esta arquitetura, ilustrada na Figura 1, sumariza o modelo proposto do SDR. O modelo apresenta dois blocos principais, os quais foram denominados de Central de Atendimento e Ambiente Industrial. No bloco denominado de Ambiente Industrial ficam localizadas as máquinas, objetos da monitoração remota, cujas máquinas se comunicam com a Central de Atendimento via Modem. No bloco denominado de Central de Atendimento fica localizada a parte computacional e operacional do SDR. Neste, o bloco Seleção/Comunicação é responsável por selecionar qual máquina deve ser monitorada, estabelecendo a comunicação Servidor – Máquina. O bloco Aquisição e Tratamento de Dados filtra os dados recebidos da máquina, observando-se o protocolo de comunicação. O bloco RBC executa o processamento dos dados, comparando-os com a Base de Casos (BC). O módulo BD constitui o Banco de Dados do sistema. O bloco denominado de Internet não participa da comunicação de dados, mas possibilita, onde há disponibilidade de um meio WEB, transmitir sinais de vídeo. Estes sinais de vídeo objetivam auxiliar na análise de problemas mecânicos, ou seja, poder verificar aquelas particularidades que não se pode transmitir via dados digitais.

3.1. Protocolo de Comunicação

A comunicação com a máquina CNC segue um protocolo específico, ilustrado pela Figura 2, definido a partir da configuração dos dados disponibilizados pelo próprio CNC. Baseia-se basicamente em duas palavras de 32 bits (double-word), sendo uma de comando e uma de dados.

Status Checksum Comando Comando Status Checksum Dado Dado

Figura 2. Protocolo – Comunicação em Double-Word

Através do SDR , o protocolo proposto permite acessar uma série de dados do CNC tais como, Histórico de Erros; Corretores de Ferramentas3; Programas de Usinagem; Parâmetros de Configuração; Telas4 do CNC, etc.

3.2. Raciocínio Baseado em Casos (RBC)

Considerando que o SDR pretende ser parte de uma ferramenta de aprendizado, ou seja, oferecer a representação do conhecimento, aplica-se nesta proposta o RBC, o qual, segundo [WANGENHEIM 2003] estabeleceu-se nos últimos anos como uma das tecnologias mais populares e disseminadas para o desenvolvimento de sistemas baseados em conhecimento podendo ser aplicável de forma simples e direta a um amplo espectro de tarefas.

A descrição de um problema corrente gera um novo caso, que é usado para recuperar, da base de casos, um ou mais casos similares ao problema corrente. A solução apresentada pelos casos recuperados é, então, combinada com o novo caso através da reutilização, gerando uma solução proposta para o problema inicial.. O uso de

3 Os Corretores de Ferramentas são valores numéricos usados para se definir as dimensões geométricas das ferramentas de usinagem utilizadas nas MF. 4 Normalmente, um CNC é configurado com inúmeras telas ou páginas de operação. Essas são construídas de forma a estabelecer um comunicação amigável entre a máquina e o operador.

PC CNC CNC PC

XXXII SEMISH 1720

conhecimento geral do domínio normalmente faz parte do ciclo, sendo suportado pelos processos RBC dentro do SDR.

• Recuperação do caso, ou casos, mais similares e aqueles que mais se aproximam do caso atual;

• Reuso da informação e conhecimento presente no caso para solucionar o problema atual;

• Revisão da solução proposta, se necessário. Readaptá-la a uma nova realidade;

• Retenção ou armazenamento de parte da experiência obtida nos processos, de modo a ser útil na solução de problemas futuros.

Os mecanismos envolvidos em RBC podem ser representados, de modo geral, por um ciclo formado por quatro processos, conforme ilustra a Figura 3.

3.3. Representação de Casos

Um caso, conforme ilustra a Figura 3, segundo [WANGENHEIM 2003] é uma peça de conhecimento contextualizado e que representa uma experiência ou episódio concreto, contendo a lição passada, que é o conteúdo do caso e o contexto em que a lição pode ser usada.

Apesar do que se observa, nos casos, é que este pode ser encontrado sob muitas formas e tamanhos, há que se observar, segundo ainda que duas medidas pragmáticas podem ser consideradas de forma geral para determinar o que deve ser representado pelos casos, a saber, a funcionalidade e a facilidade de aquisição da informação.

Figura 3. Representação do ciclo de RBC – Caso N

Descrição do Problema: Breve descrição textual do problema; Tipo de problema; Modelo do Equipamento: Tipo do equipamento; Sintomas: Registro dos sintomas para aquele problema; Diagnósticos: Registro dos diagnósticos; Probabilidade dos Diagnósticos: Cálculo das probabilidades em função do histórico de problemas; Ação: Lista de ações sugeridas em função dos diagnósticos; Similaridade Global: Cálculo da similaridade global; Similaridade Local: Cálculo da similaridade local;

CASO N

Base de Casos

Solução Adaptada

Solução Confirmada

Caso Armazenado RECUPERAÇÃO

REUSO

REVISÃO

Problema (Novo Caso)

RETENÇÃO

Casos Similares

XXXII SEMISH 1721

Dessa forma, tomando-se estas premissas, um caso no SDR é composto tipicamente do problema, o qual descreve o problema propriamente dito e uma solução, que, neste caso, postula a solução derivada para aquele dado problema, podendo a solução ser uma ação ou plano ou ainda uma informação útil ao usuário.

4. Implementação do Protótipo Num modelo convencional de diagnóstico de problemas, a comunicação de um problema normalmente ocorre somente a nível de pessoas. Neste, o problema é reportado, porém, não há um meio físico de comunicação entre o equipamento e o técnico de serviço. O técnico de serviço baseia sua pesquisa do problema somente nos dados passados pelo chão de fábrica.

Através de uma verificação no banco de dados atual, onde é registrada toda intervenção, constata-se haver uma relação histórica destes problemas em forma codificada. Constata-se também que esta codificação é usada pelo técnico de serviço somente na conclusão da assistência técnica e não como meio de pesquisa ou auxílio antes da execução do trabalho solicitado.

Considerando a abordagem proposta por [NEMES et al 2003], o SDR aplicou os conhecimentos de especialistas como forma de fornecer subsídios importantes e conduzir os usuários destes sistemas alcançarem melhores resultados em suas análises. Associando a isto, tem-se o RBC o qual é capaz de utilizar conhecimento específico de soluções de problemas concretos, experimentados anteriormente. Foi a existência desta base de conhecimentos que motivou a aplicação do RBC dentro do SDR.

Estes dados estão atualmente dispostos em uma matriz de X Defeitos x Y Conjuntos. Representativamente, esta matriz é a seguinte:

Matriz = M [ Defeito ; Conjunto ]

Onde: Defeito = d, Conjunto = c

Observa-se, no entanto, que a dimensão X x Y da matriz pode variar em função dos elementos que compõem um subconjunto e do número de defeitos. Localizado o código do defeito, os dados são transferidos como parte do relatório final do técnico de serviço, não sendo, entretanto, usado como meio de auxílio nas próximas assistências. Como exemplo desta palavra-chave, temos o CNC. Esses elementos foram classificados como conectores elétricos, bateria, fonte de alimentação, parâmetros de configuração de softwares, módulos de CPU, etc.

d1c1 d1c2 d1c3 d1c4 d1c5 ...........d1cn d2c1 d2c2 d2c3 d2c4 d2c5 ...........d2cn d3c1 d3c2 d3c3 d3c4 d3c5 ...........d3cn

dnc1 dnc2 dnc3 dnc4 dnc5 ............dncn

�����

XXXII SEMISH 1722

Tomando-se o modelo apresentado na Figura 3 e a discussão em 3.3 sobre representação de casos, adaptaram-se os conceitos do RBC para o sistema de diagnóstico remoto, tendo como objetivo o aprendizado e a construção de uma base de casos para uma MF, podendo-se definir as partes como segue:

O SDR baseia-se em um estrutura de codificação hierárquica similar a abordado por [WANG 1999], codificando todas as áreas de um CNC em códigos, servindo-se desta estrutura para a criação de uma base de dados, considerando entretanto, a dificuldade em coletar dados confiáveis do campo devido à falta de um adequado sistema de registro de falhas e de manutenção.

Dessa forma, na apresentação desta proposta, verifica-se a existência de uma extensa base de dados, a qual foi sendo construída por vários anos, servindo os mais diversos equipamentos no chão de fábrica. A base de dados atual será então utilizada no desenvolvimento do RBC, apresentando-se como uma das grandes vantagens que o sistema atual pode legar ao modelo proposto.

A base de dados existente foi esquematizada, por exemplo, tomando-se uma MF e dividindo-a em diversas áreas. A divisão por área objetiva permitir uma melhor identificação de um problema ou, no mínimo indicar qual a área mais provável da ocorrência do problema.

Esta divisão é uma representação através de redes semânticas, a qual se traduz em forma gráfica, como forma de representar o conhecimento. Dessa forma, foi criada uma estrutura tipo árvore, que permite aprofundar-se até o nível de detalhe desejado e que esta se ajuste à medida que se aprofunda na análise e no conhecimento do próprio equipamento sob investigação.

O SDR aborda uma MF com CNC consistindo de uma série de componentes físicos interrelacionados tais como motores, unidade hidráulica, ferramentas, dispositivos, componentes de controle do CNC, dentre outros. O primeiro nível, ou nível básico, é aquele que define as partes principais da máquina. A Figura 4 pode ser usada para ilustrar as partes básicas de uma MF.

Figura 4. Estrutura tipo árvore de uma MF - Divisão por áreas - Nível Básico

Conjunto Mecânico

Conjunto Eletro-

Eletrônico

MF Hidráulica Lubrificação

Torre

Pneumática

Motorização

XXXII SEMISH 1723

O nível seguinte de divisão, conforme ilustra a Figura 5 é aquele em que os diversos dispositivos que compõem a MF passam a ser identificados. Entretanto, para efeito de estudo e demonstração da estrutura tipo árvore a ser modelada pelo RBC, somente no ramo derivado do CNC será considerado.

Figura 5. Segundo nível de divisão

O terceiro nível, ilustrado pela Figura 6, será usado para identificar as principais partes que formam o CNC.

Figura 6.Terceiro nível de divisão

A divisão nos três níveis acima foi proposta com base na distribuição atual existente no banco de dados. Mesmo considerando que estes níveis contemplem outras áreas que compõem uma MF, será escopo desta proposta modelar somente a parte referente ao CNC.

Portanto, a partir da série de dados já existentes (legado do sistema atual), no ramo pertencente ao CNC, construiu-se a Tabela 4.1 de prognóstico de ocorrências. Esta tabela apresenta para cada caso (C1,C2,...,Cn), um certo número de ocorrências (Noc1,Noc2,...,Noc3n). Assim, isto indica, para um dado problema registrado, o número

CNC

Teclado

Interface com os Acionamentos Display

Interface Digital

Memórias

Funções de Programação

Comunicação

Personalização de software

Bateria Parametrização

Interface Digital

Torre

CNC

Controle dos Motores

(Acionamentos)

Conjunto Eletro-

Eletrônico

XXXII SEMISH 1724

de vezes de ocorrência daquele problema. A tabela considera ainda que, para cada caso, pode haver a ocorrência de, no mínimo, um sintoma (S1,S2,S3,...Sn).

Adotou-se também para o modelamento, um nota de atribuição ou Pontuação. A pontuação é usada como indicativo da solução mais provável para aquele dado problema. Esta pontuação tem valor de 0 a 10, Os valores de pontuação que tendem a 10 indicam um prognóstico de probabilidade maior de acerto na solução proposta pelo sistema, enquanto que valores de pontuação que tendem a 0 indicam um prognóstico de probabilidade menor. A regra usada para a pontuação segue o seguinte:

0 ≤≤≤≤ Pontuação ≤≤≤≤ 10

A pontuação dos demais sintomas se aplica aos sintomas com ocorrências > 0.

Portanto, temos que:

Os casos (C1,C2,...,Cn) devem ser retirados da base de dados já existente e devem, a partir da aplicação deste modelo, permitir sua constante atualização como forma de enriquecer o conhecimento. Os casos (C1,C2,...,Cn) definem os problemas apresentados pelo equipamento. Para cada caso conhecido, há um número de ocorrência associado. O número de ocorrência (Noc1,Noc2,...,Nocn) indica a quantidade de vezes que aquele caso ocorreu, enquanto que os sintomas (S1,S2,...,Sn) indicam as manifestações mais prováveis apresentadas pelo equipamento na presença de um problema. Dessa forma, tomando-se os dados já existentes, e considerando a matriz acima, tem-se a árvore de prognósticos de acordo com a Figura 7.

d1c1 d1c2 d1c3 d1c4 d1c5 ...........d1cn d2c1 d2c2 d2c3 d2c4 d2c5 ...........d2cn d3c1 d3c2 d3c3 d3c4 d3c5 ...........d3cn dnc1 dnc2 dnc3 dnc4 dnc5 ............dncn

�����

1

No. Total de Sintomas - 1 Pontuação Anterior

Pontuação dos demais Sintomas =

Pontuação do Sintoma Atual + 1 Pontuação do Sintoma Atual =

XXXII SEMISH 1725

Esta estrutura tipo árvore pode então ser tomada e, a partir dela, representar estas situações em diversas matrizes.

Figura 7. Estrutura árvore de prognósticos

A primeira matriz é a matriz ÁREA x CASO, a qual denota que cada área A pode apresentar vários casos C .

A1C1 A1C2 A1C3 A1C4 A1C5 ...........A1Cn A2C1 A2C2 A2C3 A2C4 A2C5 ...........A2Cn A3C1 A3C2 A3C3 A3C4 A3C5 ...........A3Cn AnC1 AnC2 AnC3 AnC4 AnC5 ............AnCn

�����������

Prognóstico

Sintoma Sintoma Sintoma Sintoma

Caso Caso

Área

Prognóstico

Prognóstico

Prognóstico

Prognóstico

Prognóstico

Prognóstico

Prognóstico

Noc1

Nocn

Nocn1

Nocnn

Noc1

Nocn

Nocn1

Nocnn

XXXII SEMISH 1726

A segunda matriz é a matriz CASO x SINTOMA, a qual denota que cada caso C pode apresentar, no mínimo, um sintoma S.

A terceira matriz é a matriz SINTOMA x PONTUAÇÃO. Nesta, cada sintoma S

recebe um valor de pontuação P, segundo a regra estabelecida para tal.

A combinação destas matrizes podem ser representadas conforme a Tabela 1 a seguir.

Tabela 1. Tabela para prognóstico de ocorrências - simplificada

S1 S2 S3 S4 S5 S6 S7 S8 S9 S10 S11 S12 S13 Sn Pontuação 10 9 8 7 7 6 5 5 4 3 2 2 1 1

Casos Número de Ocorrências

C1 Noc1 10 8 5 0 0 0 0 0 0 0 0 0 0 0 C2 Noc2 C3 Noc3 C4 Noc4 C5 Noc5 Cn Nocn

S1P1 S1P2 S1P3 S1P4 S1P5 ...........S1Pn S2P1 S2P2 S2P3 S2P4 S2P5 ...........S2Pn S3P1 S3P2 S3P3 S3P4 S3P5 ...........S3Pn SnP1 SnP2 SnP3 SnP4 SnP5 ............SnPn

���������

C1S1 C1S2 C1S3 C1S4 C1S5 ...........C1Sn C2S1 C2S2 C2S3 C2S4 C2S5 ...........C2Sn C3S1 C3S2 C3S3 C3S4 C3S5 ...........C3Sn CnS1 CnS2 CnS3 CnS4 CnS5 ............CnSn

����������

XXXII SEMISH 1727

4.1 Consulta ao RBC

Esta consulta deve acessar a base de casos e, a partir do histórico de problemas (casos), apresentar ao técnico, para aquele dado problema e naquele dado equipamento, um prognóstico para solução e ação. As áreas, considerando-se somente o CNC e conforme discutido em 4.7, foram definidas como:

5. Avaliação e Resultados Experimentais Como resultado direto, os dados ilustrados pela Tabela 2, após a implementação do SDR, permite-nos concluir que o sistema trouxe benefícios para ambos, usuário do equipamento e para o fabricante. Estes benefícios podem ser traduzidos em redução considerável nos custos de manutenção e redução do tempo de indisponibilidade dos equipamentos. Além disso, ocorre também um aumento na taxa de acertos na solução dos problemas, quando comparado aos métodos convencionais utilizados para a solução dos mesmos. Outro benefício adicional que pode ser descrito é que os usuários do sistema, neste caso os técnicos de serviço, passaram a usar o SDR para fazer simulações de problemas como forma de auto-treinamento, permitindo assim aprimorar ainda mais a base de casos.

Tabela 2. Comparativo de Assistência - Método Convencional x SDR

Método Convencional SDR Local Problema TL-MC TD-MC Despesas

(US$) TL-SDR TD-SDR Despesas

(US$) México P1 28 horas 1 1.346,00 0 1 14,00 Coréia P2 56 horas 3 3.100,00 0 4 * 265,35 Itália P3 30 horas 9 ** 2.246,00 0 2 74,79 Recife P4 13 horas 9 *** 486,62 0 3 36,76 P1 = Problema = Alarme 200 gerado quando programando rotação; P2 = Problema = Instalar nova função de software; P3 = Problema = Alarme 930 gerando quando em programação; Onde : TL-MC é o tempo de locomoção no Método Convencional TD-MC é o tempo de diagnóstico e solução no Método Convencional TL-SDR é o tempo de locomoção no SDR TD-SDR é o tempo de diagnóstico e solução no SDR (*) Tempo foi maior devido as dificuldades com o idioma; (**) Problema era de característica intermitente; (***) Problema também de característica intermitente;

Funções de Programação Memórias Teclado Display Interface com Acionamentos Interface Digital Comunicação Personalização de Software Bateria Outros

Área Definida =

XXXII SEMISH 1728

6. Conclusão Este artigo apresentou uma arquitetura para um sistema de diagnóstico remoto utilizando a técnica de raciocínio baseado em casos. Um protótipo dessa arquitetura foi implementado, e encontra-se em operação em uma empresa fabricante de máquinas do tipo CNC. Resultados experimentais demonstraram que o sistema é eficaz na resolução de problemas, o que se deve a sua capacidade para identificar casos anteriores, fazer adaptações quando necessário, e armazená-los para uso futuro. Comprovou-se assim a adequação dessa tecnologia para este domínio de aplicações. Acredita-se que a arquitetura proposta também possa ser utilizada para diagnóstico de sistemas de outras áreas, o que deverá ser feito em um trabalho futuro. Pretende-se também estudar a viabilidade de substituir o meio de comunicação dedicado por um sistema baseado na tecnologia de Serviços Web, o que aumentaria a flexibilidade no uso do SDR.

Referencias Bibliográficas Azevedo, D. F. G., Moura, E. P., DeCastro, M. C. F., DeCastro, F. C. C., Rocha, M. F.

da (2003) “Telemedicine: Remote Monitoring of Cardiac Patients”.

Bellamine, Moez, Abe, Norihiro, Tanaka, Kazuaki, Chen, Peng, Taki, Hirokazu (2003) “Design of a Remote Diagnosis System for Rotating Machinery Using Virtual Reality and Fuzzy Pattern Matching”.

Castro, D., Presedo, J., Delgado-Fernández, M., Barro, S. (2002) “Patient Telemonitoring at Home”.

Dumer, John, Hanratty, Timothy, Bodt, Barry, Perry, H. Mitchel, Carmody, Sharon E. (2002) “Remote Medical Evaluation and Diagnostics (RMED) – A Testbed for Hypertensive Patient Monitoring”.

Hung, Mil-Hsiung, Chen, Kuan-Yii, Lin, Shih-Sung (2004) “Development of a WEB-Services-Based Remote Monitoring And Control Architecture”.

Inoue, Takeshi, Hino, Yasutaka, Hayashi, Kouji, Narukawa, Masanori (2002) “A Dynamic Pair-Program Sending Architecture for Industrial Remote Operations”.

Jannett, Thomas C., Prashanth, Sridharan, Mishra, Suchit, Ved, Vishal, Mangalvedhekar, Ashvini, Deshpande, Jatin (2002) “An Intelligent Telemedicine System for Remote Spirometric Monitoring”.

Lee, Jin-Shyan, Hsu, Pau-Lo (2002} “Design of Remote Environment Monitoring Systems”.

Nemes, L., Mo, J. P. T. (2003) “Sample Layout for Design of Information Infrastructure Systems for Manufacturing Conference”.

Renton, P., Bender, P., Veldhuis, S., Renton, D., Elbestawi, M. A. (2002) “Internet-Based Manufacturing Process Optimization and Monitoring System”.

Tan, K. K., Wang, K. N. (2002) “Mechatronic Experiment Via the Internet”.

Wangenheim, Christiane Gresse von, Wangenheim, Aldo von (2003) “Raciocínio Baseado em Casos”. Editado por Editora Manole Ltda – Brasil.

XXXII SEMISH 1729