UNIVERSIDADE DO ESTADO DE SANTA CATARINA UDESC CENTRO DE CIÊNCIAS TECNOLÓGICAS CCT BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO GUILHERME AUGUSTO GALLINA

Transcrição

1 UNIVERSIDADE DO ESTADO DE SANTA CATARINA UDESC CENTRO DE CIÊNCIAS TECNOLÓGICAS CCT BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO GUILHERME AUGUSTO GALLINA SISTEMA DE APOIO À DECISÃO BASEADO NA MÉTRICA OEE PARA CONTROLE E GERENCIAMENTO DE FLUXO PRODUTIVO JOINVILLE SC 2013

2 1 GUILHERME AUGUSTO GALLINA SISTEMA DE APOIO À DECISÃO BASEADO NA MÉTRICA OEE PARA CONTROLE E GERENCIAMENTO DE FLUXO PRODUTIVO Trabalho de conclusão apresentado ao curso de Bacharelado em Ciência da Computação do Centro de Ciências Tecnológicas, da Universidade do Estado de Santa Catarina, como requisito para a obtenção do grau de Bacharel em Ciência da Computação. Orientador: Roberto Silvio Ubertino Rosso Jr. Co-orientadora: Izabel Cristina Zattar JOINVILLE SC 2013

3 2 GUILHERME AUGUSTO GALLINA SISTEMA DE APOIO À DECISÃO BASEADO NA MÉTRICA OEE PARA CONTROLE E GERENCIAMENTO DE FLUXO PRODUTIVO Trabalho de conclusão apresentado ao curso de Bacharelado em Ciência da Computação do Centro de Ciências Tecnológicas, da Universidade do Estado de Santa Catarina, como requisito para a obtenção do grau de Bacharel em Ciência da Computação. Banca Examinadora Orientador: Co-orientadora: Membro: Membro: Dr. Roberto Silvio Ubertino Rosso Jr. UDESC Universidade do Estado de Santa Catarina Dra. Izabel Cristina Zattar UFPR Universidade Federal do Paraná Dr. Claudio Cesar de Sá UDESC Universidade do Estado de Santa Catarina Dr. Fabiano Baldo UDESC Universidade do Estado de Santa Catarina JOINVILLE SC (Junho de 2013)

4 A todas as pessoas mais importantes para mim, aos meus amigos e orientadores, que acreditaram e contribuíram para a realização desse trabalho. 3

5 4 AGRADECIMENTOS Primeiramente a Deus, por fazer com que eu chegasse até aqui. Agradeço à minha família, Simone Teresinha Rambo Gallina, Ademir Gallina, Tracy Laura Gallina e Pâmela Spiecker Gasparin, aos meus amigos e orientadores.

6 5 RESUMO Uma empresa que tem seu fluxo de produção acompanhado por software de controle tem um rendimento diferenciado, bem como uma maior facilidade de gerenciamento de grande massa de dados. O objetivo deste trabalho é integrar um módulo de apoio à decisão ao SOEE desenvolvido no LARVA, para gerenciamento de processos e acompanhamento do fluxo produtivo de modo a auxiliar o usuário a tomar decisões dentro da companhia com base nas métricas do OEE (Overall Equipment Effectiveness). A métrica OEE está sendo cada vez mais utilizada em fábricas para controlar a qualidade da linha de produção. O trabalho apresenta uma fundamentação teórica dessa métrica, que aplica os conceitos do TPM, metodologia que visa aumentar os lucros e a eliminação de perdas. A utilização de sistemas de apoio à decisão em organizações proporciona uma economia de dinheiro investido, pois mostra com mais precisão o gargalo da eficiência na linha de produção, bem como uma facilidade em se tomar decisões. Alguns conceitos de métodos de apoio à decisão são descritos na fundamentação teórica do trabalho, bem como conceitos da Inteligência Artificial, com aprofundamento em Sistemas Especialistas, para construir o módulo que auxilie os gestores mais experientes da organização e também os que não possuem um conhecimento aprimorado no domínio do OEE. Neste trabalho é apresentada uma solução de implementação do módulo com base em sistemas especialistas. Foi utilizada a ferramenta JESS para simular o conhecimento do especialista através de uma interface integrada que interpreta regras e fatos. O resultado do JESS e do SOEE foram submetidos a testes quantitativos de desempenho com os mesmos casos de entrada e analisados. Palavras-chave: Métrica OEE, Apoio à decisão, Sistemas Especialistas, regras e fatos, SOEE.

7 6 ABSTRACT A company that has its production flow accompanied by control software has a distinguished yield and an easier management of large amounts of data. The objective of this work is to integrate a module for decision support to the OEE software, developed at LARVA, for process management and monitoring production flow, in order to help users to make decisions inside company, based on OEE (Overall Equipment Effectiveness) metrics. The OEE metric is being increasingly used in factories to control the quality of production line. This work presents a theoretical foundation of this metric which applies the concepts of TPM, methodology that aims to increase profits and elimination of losses. The use of decision support systems in the organizations provides a saving of invested money, because it shows more accurately the bottleneck of the lack of efficiency in the production line, as well as it eases to make decisions. Some methods of decision support are described in the theoretical foundation, as well as concepts of Artificial Intelligence, with an approach in Expert Systems to build the module that helps expert managers in the company, and especially new users in the domain of OEE. In this work, it is presented the implementation of a module, based on an Expert Systems. The JESS tool was used to simulate the expert s knowledge through a shell which interprets facts and rules. The results of JESS implementation was submitted to quantitative tests of performance with SOEE outputs, test and validate based on the same input cases. Key-words: OEE metric, Decision support, Expert systems, rules and facts, OEE Software.

8 7 LISTA DE ILUSTAÇÕES Figura 1 - Os oito pilares do TPM Figura 2 - Relação entre perdas dos equipamentos e os indicadores OEE Figura 3 - Esquema lógico dos blocos de um Sistema Especialista Figura 4 - Tela de distribuição de níveis de permissão do SOEE Figura 5 - Diagrama de classes reduzido do SOEE Figura 6 - Diagrama de interação do sistema com o módulo de apoio à decisão Figura 7 - Regras do indicador de Qualidade Figura 8 - Regras do indicador de Disponibilidade Figura 9 - Regras do indicador de Performance Figura 10 - Diagrama de Casos de uso para o sistema em geral Figura 11 - Arquitetura do SOEE com o módulo de apoio à decisão Figura 12 - Diagrama de sequência do módulo com análise do SOEE Figura 13 - Tela de interface do módulo de apoio à decisão Figura 14 - Resultado do teste da análise JESS Figura 15 - Resultado do teste da análise SOEE-JRA Figura 16 - Tela de explicação da análise JESS... 68

9 8 LISTA DE QUADROS Quadro 1 As doze etapas do programa de desenvolvimento do TPM Quadro 2 Legenda das siglas para o cálculo do OEE Quadro 3 Relação das seis perdas com as estratégias de redução e prevenção Quadro 4 Definição de Templates em JESS Quadro 5 Definição de variáveis de controle no JESS Quadro 6 Regras de disponibilidade em JESS Quadro 7 - Comparação quantitativa entre as ferramentas desenvolvidas... 69

10 9 LISTA DE ABREVIATURAS API G-SAPO IA IHM JESS JIPM JRA JVM LARVA OEE PDF SAD SGBD SOEE SQL TPM Application Programming Interface Grupo de Desenvolvimento de Sistemas de Apoio à Decisão Inteligência Artificial Interface Humano-Máquina Java Expert System Shell Japan Institute of Plant Maintenance Java Robust Analysis Java Virtual Machine LAboratory for Research on Visual Applications Overall Equipment Effectiveness Portable Document Format Sistema de Apoio à Decisão Sistema de gerenciamento de Banco de Dados Software OEE Structured Query Language Total Productive Maintenance

11 10 SUMÁRIO 1 INTRODUÇÃO JUSTIFICATIVA PARA A PROPOSTA DO TRABALHO DELIMITAÇÕES DO PROBLEMA OBJETIVOS Objetivo geral Objetivos específicos ESTRUTURA DO TRABALHO FUNDAMENTAÇÃO TEÓRICA O INDICADOR DE QUALIDADE OEE Toyotismo Manutenção Produtiva Total Eficiência Geral De Equipamento SISTEMAS DE APOIO À DECISÃO Introdução à sistemas de apoio à decisão Árvore de decisões INTELIGÊNCIA ARTIFICIAL Conceitos Sistemas especialistas Estrutura de um Sistema Especialista A base de conhecimento O motor de inferência Memória de trabalho Aquisição de conhecimento CONCLUSÃO DO CAPÍTULO FERRAMENTAS UTILIZADAS O SOEE Níveis de autorização Arquitetura Camada de Apresentação Camada de Fachada Camada de Persistência dos dados A FERRAMENTA JESS... 40

12 A linguagem Memória de trabalho do JESS TRABALHOS CORRELATOS RESUMO DO CAPÍTULO ESPECIFICAÇÕES DO MODELO DESENVOLVIDO O PROBLEMA RESOLVIDO Interação de componentes do sistema Os problemas de pontos de vista diferentes SOLUÇÃO DO PROBLEMA Descrição da regra de negócio Arquitetura do sistema A comunicação SOEE/JESS Definição das regras DESAFIO COMPUTACIONAL: O GARGALO A extração do conhecimento do especialista CONCLUSÕES DO CAPÍTULO RESULTADO DO MÓDULO DE APOIO À DECISÃO A BASE DE DADOS RESULTADOS OBTIDOS CONCLUSÕES E TRABALHOS FUTUROS TRABALHOS FUTUROS REFERÊNCIAS APÊNDICE A DEFINIÇÃO DOS TEMPLATES E VARIÁVEIS COM JESS APÊNDICE B DEFINIÇÃO DAS REGRAS COM JESS APÊNDICE C SCRIPT DE INSERÇÃO DE REGISTROS DA BASE DE DADOS... 90

13 10 1 INTRODUÇÃO A preocupação com a qualidade da linha de produção é um ponto com extrema importância nas fábricas modernas. Cada vez mais os gestores das organizações optam por um processo com produtividade, por parte dos produtos, qualidade de vida dos funcionários e rapidez. Para que todo esse processo ocorra de uma maneira eficaz, é necessário ao longo do caminho se tomar algumas decisões importantes por parte dos gestores para o futuro do empreendimento. Tais decisões deveriam ser tomadas por um especialista na área em que atua, para que apresentem maior rendimento e confiabilidade. Porém, esse é um cenário que nem sempre é visto nas empresas. Algumas pequenas e médias empresas não dispõem de uma pessoa qualificada na área para tomar decisões importantes podendo assim serem prejudicadas por decisões sem conhecimento. Com base neste problema, um módulo de apoio à decisão utilizando Sistemas Especialistas foi implementado para oferecer sugestões de decisões aos gestores que buscam maior produtividade. O módulo desenvolvido teve suas regras geradas a partir da métrica OEE (Overall Equipment Effectiveness, ou em Português, Eficiência Global de Equipamentos), sendo esta a mesma regra de negócio do software SOEE (Software OEE) que foi desenvolvido no perído de iniciação científica. O software, ao qual o módulo de apoio à decisão foi acoplado, foi desenvolvido a partir de um projeto de iniciação científica realizado na UDESC com parceria da UFPR e apoio financeiro da Fundação Araucária. O software do projeto foi construído na linguagem de programação Java, devido à sua portabilidade e facilidade de extensão e reuso de código oferecido pela linguagem. O intuito deste trabalho consiste em desenvolver um módulo de apoio à decisão que receba como entrada os dados de registro de paradas e produções do SOEE e com base nessas entradas gere como resposta ao usuário, utilizando como premissas as seis grandes perdas dos equipamentos, qual é a melhor decisão a ser tomada na organização. O sistema utiliza a abordagem de interação de encadeamento para frente, e

14 11 dispõe de um engenheiro de conhecimento que faz a aquisição de conhecimento do especialista. Essa aquisição foi feita manualmente por meio de entrevistas com os dois atores para o levantamento de requisitos. O módulo implementado consiste de duas análises distintas, a análise JESS e a análise SOEE, que aqui será intitulada análise SOEE-JRA (sigla para Java Robust Analysis). 1.1 JUSTIFICATIVA PARA A PROPOSTA DO TRABALHO Como está descrito com mais detalhes no capítulo 2, o índice OEE é uma métrica que aplica os conceitos do TPM (Total Productive Maintenance, ou em Português, Manutenção Produtiva Total) em uma fábrica para medir o desempenho da produção, com base nos três apontadores: Qualidade, Disponibilidade e Performance. Baseando-se nos valores individuais desses três índices e na porcentagem resultante, os decisores especialistas na área avaliam quais medidas devem ser tomadas para evitar o máximo de perdas, melhorando a produtividade da organização. O OEE representa de uma forma quantitativa os dados coletados do chão-defábrica para serem analisados, ou seja, mostra utilizando números e porcentagens o gargalo da eficiência. O público alvo da aplicação desenvolvida são desde os gestores e decisores experientes no domínio do OEE até as pessoas que não possuem conhecimento aprimorado do funcionamento da métrica OEE, como pode ocorrer em algumas pequenas e médias empresas. Com a ajuda de um módulo de apoio à decisão integrado ao SOEE, as pessoas que não tem conhecimento sobre o conceito poderão tomar decisões com maior certeza. Da mesma forma, os colaboradores decisores da organização, que possuem certo grau de conhecimento do índice OEE poderão ter uma ajuda extra do software quando chegar a hora de se tomar decisões importantes.

15 DELIMITAÇÕES DO PROBLEMA A partir do momento que a computação aceita os desafios de auxiliar na avaliação de manutenção e ciclo produtivo, algumas metas podem ser definidas. Conforme Zattar, Rudek, Turquino (2010), o índice OEE pode ser considerado mais do que uma ferramenta para identificar perdas especificamente na produção, mas também um apontador que auxilia na decisão de como reagir às avarias recorrentes. No conjunto de registros das paradas e produtividade das máquinas, podem-se encontrar alguns padrões que caracterizam as perdas de produtividade. Assim, medidas poderão ser tomadas de modo a minimizar os problemas encontrados. Desse modo, o próprio programa analisa os dados e, ao perceber certos casos de perdas, dá sugestões e dicas de prováveis soluções àquelas questões encontradas, auxiliando a tomada de decisão no âmbito empresarial (MENDES; GALLINA, 2011). O escopo desse trabalho se define em: a) Receber as saídas do SOEE, como paradas programadas e nãoprogramadas, quebras de máquinas, quantidade de peças refugo/retrabalho por lote, diminuição da velocidade de máquina, e utilizá-las como dados de entrada para o módulo, b) Analisar os dados obtidos com base nos dados fornecidos pelo SOEE, c) Criar regras de produção através da forma de aquisição de conhecimento manual e baseada em entrevistas. d) Aplicar a inferência de padrões através de Sistemas Especialistas, utilizandose o modo de encadeamento para frente. e) Informar ao usuário uma resposta de quais decisões tomar para ajudar a melhorar os três indicadores da métrica OEE. 1.3 OBJETIVOS Objetivo geral Desenvolver um módulo de apoio à decisão que analise as saídas do SOEE e

16 13 auxilie os usuários a tomar decisões na organização com base na métrica OEE Objetivos específicos a) Fazer uma fundamentação teórica na área sobre a métrica OEE. b) Fazer uma fundamentação teórica sobre métodos de apoio à decisão e Inteligência Artificial. c) Definir as especificações do sistema que será implementado. d) Definir como será a comunicação entre o módulo de apoio à decisão e o SOEE. e) Desenvolver um protótipo da arquitetura do sistema, como interação com sequência de tempo e funcionalidades, e implementar o módulo. f) Testar e validar o módulo de apoio à decisão com base em um caso de teste. g) Realizar uma comparação quantitativa de desempenho entre as análises implementadas. 1.4 ESTRUTURA DO TRABALHO Este trabalho está dividido em capítulos e seções para melhorar a compreensão do leitor. O capítulo 1 apresenta a introdução do trabalho, justificativa, objetivo geral e específicos e a proposta de trabalho. No capítulo 2 são descritos os conceitos de TPM, que é o fundamento da métrica de OEE. O OEE é um termo importante utilizado ao longo do trabalho e que servirá de base para o módulo de apoio à decisão. Da mesma forma, serão descritas introduções sobre Sistemas de apoio à decisão e Inteligência Articifial e, dentro da última, um levantamento dos conceitos sobre Sistemas Especialistas. O capítulo 3 apresenta as duas ferramentas que foram utilizadas no projeto: as especificações mais importantes do SOEE, que foi desenvolvido durante uma bolsa de iniciação científica pela Fundação Araucária e que servirá de base para o módulo assim como a ferramenta JESS. No capítulo 4 são apresentadas as especificações do projeto, sua limitações e visões de pontos de vista em diferentes domínios. São apresentados diagramas que

17 14 ajudam o leitor a visualizar e compreender a comunicação e interação das funcionalidades do sistema. Os testes efetuados com a ferramenta são mostrados no Capítulo 5 e, por fim, o Capítulo 6 aborda as considerações finais deste trabalho, seguido das referências bibliográficas e apêndices.

18 15 2 FUNDAMENTAÇÃO TEÓRICA Neste capítulo são abordados três conteúdos para a revisão da literatura do trabalho: indicador de qualidade OEE, SAD (Sistemas de Apoio à Decisão) e IA (Inteligência Artificial). Os conceitos de TPM, sua fundamentação e pilares, o OEE, aplicabilidade e vantagens dessa métrica, e a principal ideia que motivou a criação de ambos, o Toyotismo, são descritos no item 2.1. Uma introdução e conceitos de Sistemas de Apoio à decisão são vistos no item 2.2. Os conceitos de Inteligência Artificial, suas aplicações e a técnica de Sistemas Especialistas são descritos no item 2.3. Por fim, faz-se uma conclusão desse capítulo com uma discussão das vantagens e desvantagens da utilização de Sistemas Especialistas, bem como uma definição das suas especificações. 2.1 O INDICADOR DE QUALIDADE OEE Toyotismo Com a crise do petróleo nos anos 70, o Japão começou a se reerguer economicamente, algumas empresas se mostraram um passo a frente dos concorrentes do mundo inteiro. A empresa que mais se destacou foi a Toyota Motors Company, pois sua produção sobre um sistema flexível ao passar dos anos se tornou referência no mundo todo devido ao sucesso das fábricas que utilizaram esse modelo. O Toyotismo tem sua base em cima da eliminação completa de perdas, tendo o Just in Time e a Autonomação como suas colunas de sustentação (GHINATO, 1996). O sistema de produção da Toyota tem como fundamento uma metodologia de produção e entrega mais rápidas e precisas que o Fordista e Taylorista, associada justamente à manutenção de uma empresa flexível e enxuta. Isso era obtido pela focalização no produto principal, gerando subcontratação de empresas que passavam a fornecer e desenvolver atividades e produtos, utilizando uma força de trabalho

19 16 polivalente. Essa força de trabalho agrega a cada operário atividades de execução, controle de qualidade, limpeza, manutenção e operação a vários equipamentos simultaneamente (PINTO, 2010) Manutenção Produtiva Total O termo TPM foi usado pela primeira vez nos anos 60, pela empresa Nippondenso, fornecedora da Toyota da época. No decorrer dos anos outras técnicas foram criadas no Japão, como manutenção para melhoria, manutenção corretiva e prevenção da manutenção. Conforme Diniz e Távora (2004 apud MENDES; GALLINA, 2011), a Toyota adotou uma estratégia de inversão determinante para a importância de evitar perdas: o mercado determina o preço do produto, e não o preço resulta da soma do custo e do lucro pretendido. Neste último, denotado por Princípio do Custo, o preço era imposto ao mercado e o fabricante não se interessava em reduzir perdas e desperdícios, menos ainda em aumentar a eficiência de seu processo, para aumento do lucro. Ou seja, os custos adicionais da fabricação eram repassados para os consumidores. Aumentando a exigência dos consumidores por variedade e preços acessíveis, a lógica tradicional é invertida, originando o Princípio do Não Custo, onde o lucro vem da diferença entre o preço estipulado e o custo total de produção. Assim, este princípio torna-se um mecanismo de perseguição a perdas. Perdas estas tão ocultas no processo manufatureiro. Portanto, para aumento do lucro, o foco deixa de ser o investimento em mais equipamentos, mas torna-se aumento da eficiência dos que já estão na empresa (DINIZ; TÁVORA, 2004 apud MENDES; GALLINA, 2011). A prevenção da manutenção, por ser orientada para reforma e aquisição de novos equipamentos, como para engenharia de confiabilidade, engenharia de manutenibilidade e engenharia econômica, acabou originando, como expõe Chiaradia (2004), um novo método chamado Manutenção Produtiva. O TPM surgiu da adaptação das técnicas americanas de manutenção a estas técnicas japonesas (NAKAJIMA, 1989). Conforme Chiaradia (2004), o TPM é uma metodologia de gestão industrial que

20 17 busca eliminar perdas sendo inicialmente introduzida no mercado global por Seiichi Nakajima. Com a publicação de dois livros que abordam o processo de implementação da metodologia TPM (TPM Tenkai, em 1982, TPM Nyumon, em 1984), Nakajima descreve os conceitos da técnica. O TPM é um processo gerencial que revitaliza o ambiente de trabalho, reduz significativamente paradas no processo fabril e garante qualidade fazendo uma integração humano-máquina que juntos, aumentam a lucratividade da organização (SUZUKI, 1998 apud RODRIGUES, 2006). O TPM é uma ferramenta que auxilia na redução de reparos feitos em máquinas, muitas vezes realizados pelo próprio operador, por meio da manutenção autônoma, aumentando a eficiência dos equipamentos (ZATTAR, RUDEK, TURQUINO, 2010). Conforme definido pelo JIPM em 1971, o TPM tem como objetivo cinco itens básicos: Maximizar a eficiência dos equipamentos, Estabelecer um sistema que engloba toda vida útil do equipamento, Envolver todos os departamentos (planejamento, projeto, manutenção) na sua implementação, Promover atividades que agreguem desde os funcionários do chão de fábrica até a gerência e, Promover atividades em pequenos grupos autônomos visando motivação gerencial. Segundo Nakajima (1989), os resultados esperados da aplicação da metodologia TPM são obtidos após três anos, que é o tempo para que as 12 etapas da metodologia estejam completamente implementadas. Essas 12 etapas são descritas no Quadro 1, que está agrupado por itens. O primeiro item é a fase composta pelos itens Preparação para a introdução, Início da introdução, Implementação e Consolidação. Cada uma dessas fases possui uma ou mais etapas, que são ordenadas por ordem de acontecimento.

21 18 Quadro 1 As doze etapas do programa de desenvolvimento do TPM Fases Etapas Pontos principais Preparação para a introdução Início da introdução Implementação Consolidação 1. Manifestação da alta direção sobra a decisão de introduzir o TPM 2. Campanha de divulgação e treinamento para introdução do TPM 3. Estrutura para implantação do TPM 4. Estabelecimento de diretrizes básicas e metas para o TPM 5. Elaboração do plano diretor para implantação do TPM 6. Início do programa de TPM 7. Aperfeiçoamento individualizado nos equipamentos para melhorar rendimento operacional 8. Estruturação da manutenção por iniciação própria 9. Estruturação da manutenção programada pelo departamento de manutenção 10. Treinamento para melhora do nível de capacitação da operação e da manutenção 11. Estruturação do controle da fase inicial de operação dos equipamentos 12. Execução total do TPM e elevação do nível geral Fonte: (WYREBSKI, 1997). Essa manifestação deve acontecer num encontro interno da empresa sobre TPM, e deve ser publicada num boletim interno da empresa Executivos: realizam estudos em grupo, conforme os cargos que ocupam. Funcionários em geral: passam por seções orientados por projeção de slides ou outros recursos Comissão ou grupos de estudo por especialidade. Secretaria Benchmark e metas: previsão dos resultados Desde os preparativos para introdução até os detalhes da implantação Convites: - clientes - empresas relacionadas - empresas colaboradoras Seleção de um equipamento modelo: organização de uma equipe de projetos Método de evolução passo a passo, diagnóstico e aprovação Manutenção periódica, manutenção preditiva, controle de construções, peças sobressalentes, ferramentas e desenhos Treinamento concentrado dos líderes: treinamento das outras pessoas envolvidas Projeto MP: controle de flutuação na fase inicial: LCC Recebimento do prêmio PM: busca de maior desafio através de objetivos cada vez mais ambiciosos Shirose (2000) cita que na segunda etapa aplicam-se os oito princípios do desenvolvimento do TPM, conhecidos também como pilares, como ilustrado na Figura 1. Os princípios são: Wyrebski (1997) cita que o TPM implementa oito atividades conhecidas como Os oito pilares de sustentação do TPM para lidar com as seis perdas de equipamentos (essas perdas serão melhor descritas no item 2.1.3).

22 19 Esses oito pilares são: 1. Manutenção autônoma, 2. Melhoria específica, 3. Manutenção planejada, 4. Educação e treinamento, 5. Controle inicial, 6. Manutenção da qualidade, 7. Aumento da eficiência das áreas administrativas, 8. Controle de segurança, saúde e meio ambiente. Figura 1 - Os oito pilares do TPM Fonte: (CHIARADIA, 2004) Eficiência Geral De Equipamento O índice de Eficiência Geral de Equipamentos, ou Overall Equipment Effectiveness (OEE) em inglês, é uma métrica para medida de desempenho de máquinas em um chão de fábrica. O OEE surgiu no final da década de 80 e começo de 90. Primeiramente era muito próximo ao TPM e foi visto como uma definição vaga do

23 20 TPM. Porém, quanto mais o OEE era usado como uma métrica e defendido em artigos e seminários, mais era visto como uma ferramenta para medir a eficiência com base nos seus indicadores de disponibilidade, qualidade e eficiência (HANSEN, 2001). Conforme Godfrey (2002), a medida OEE é um bloco básico da abordagem de melhoria de produção da metodologia TPM. Este tenta alcançar dois objetivos principais quando recebe operações para medir desempenho do equipamento em um nível mais detalhado: usar o OEE para atingir as melhorias priorizadas e usar as atividades de melhoria para aumentar os níveis do operador proprietário que utiliza o equipamento. O OEE é um índice em porcentagem que é formado pelo cálculo de três indicadores: Disponibilidade, Qualidade e Performance. De uma forma mais clara, a fórmula da métrica OEE pode ser descrita como: (1) OEE (%) = TPB TPP ᵡ DR DD ᵡ TRP TDP Onde as siglas são mostradas no Quadro 2. Quadro 2 Legenda das siglas para o cálculo do OEE Sigla Significado TPB Total Peças Boas TPP Total peças Produzidas DR Desempenho Real DD Desempenho Desejável TRP Tempo Real de Produção TDP Tempo Disponível para Produção Fonte: Adaptado de Mendes e Gallina (2011). Segundo Mendes e Gallina (2011), o indicador de disponibilidade é o equivalente as horas em que uma máquina fica disponível para produção, ou seja, que ela utiliza o tempo para produzir efetivamente, sem paradas programadas e não-programadas. O valor do indicador de disponibilidade é obtido pela divisão do tempo real pelo tempo total disponível para produção. O indicador de qualidade, como o nome já diz, define a qualidade das unidades

24 21 produzidas, podendo ser boas, retrabalho ou refugo. As peças são classificadas como Retrabalho caso ocorra um problema e essa peça saia da linha de produção com propriedades não compatíveis com a especificação original, mas que com um trabalho adicional pode se tornar utilizável. As peças Refugo são as que são produzidas com uma não-conformidade que comprometem a utilização/qualidade que não são passíveis de retrabalho, tornando elas inutilizáveis e, por fim, peças boas são as que saem da linha de produção sem nenhum problema, ou seja, dentro da especificação (MENDES; GALLINA, 2011). O indicador de performance mede o desempenho de uma máquina com base na velocidade de produção das peças. Uma máquina tem uma velocidade nominal já definida pelo fabricante, porém, na grande maioria dos casos, essa velocidade máxima de operação não pode ser atingida constantemente, pois existem fatores influenciam na perda desse rendimento, como paradas e queda de velocidade da máquina sobre a velocidade teórica (NAKAJIMA, 1989). A métrica OEE objetiva o acompanhamento da produtividade da uma fábrica, considerando a utilização simultânea dos equipamentos, sua produtividade e qualidade do produto final (ZATTAR; RUDEK; TURQUINO, 2010). O resultado dessa fórmula é uma porcentagem e significa a produtividade da máquina. Baseando-se nesse valor, podem ser aplicadas medidas conforme a necessidade encontrada, seja problemas de produção de peças refugo/retrabalho excessivos, se ocorreram muitas paradas e o equipamento não obteve uma velocidade de produção boa ou até mesmo se não atende ao desempenho nominal estipulado pelo fabricante. Ou seja, os indicadores apontam problemas em diferentes partes da produção e os separa para serem tratados individualmente. Um exemplo de caso é: um fábrica que trabalha 12 horas por dia, incluindo finais de semana, nos turnos da manhã, tarde e noite. Então, em uma semana tem-se 12 horas multiplicadas por 7 dias da semana, totalizando 84 horas de trabalho por semana. Dessas 84 horas totais que a fábrica está funcionando, apenas 63 horas são destinadas à produção de peças, descontando-se o tempo de paradas programadas e nãoprogramadas. Supõe-se também uma máquina que tenha uma velocidade nominal de produção estipulada pelo fabricante de 100 peças por hora. Porém, essa máquina

25 22 sofreu perdas de velocidade devido a um setup mal executado e sua velocidade caiu para 85 peças/hora. Essa mesma máquina produziu 6500 peças no período de sete dias, e desse total, apenas 6120 são peças boas, as outras são refugo e retrabalho. Considerando-se esse exemplo, o cálculo do indicador OEE para esses sete dias observado é: (2) OEE = ᵡ ᵡ OEE 0, OEE 60, 02 % Hansen (2006) separou os possíveis resultados do OEE em diferentes classificações de níveis de eficiência. Abaixo de 65% de eficiência, significa um péssimo aproveitamento dos recursos dos equipamentos e torna-se necessário verificar com urgência a situação da máquina. Se o resultado obtido for entre 65% e 75% então é aceitável apenas se as tendências do trimestre forem positivas. Entre 75% e 85% é considerado bom, mas é aconselhado continuar a melhoria da produção para alcançar níveis mais elevados e se aproximar mais da excelência. O resultado entre de 85% a 90%, este é tomado como referência entre as empresas da mesma área. Acima de 90% é considerado ótimo, sendo que empresas mundialmente conhecidas possuem esse resultado. Portanto, no exemplo, o valor obtido durante os sete dias é considerado um valor muito baixo, retratando um péssimo aproveitamento dos recursos disponíveis. Uma relação entre os componentes do índice OEE e as principais perdas podem ser vistas na Figura 2, onde as perdas no item disponibilidade representadas por quebras ou falhas e setup ou regulagens. No item performance, pela perda de velocidade do equipamento ou paradas curtas não-programadas e, por último, na qualidade, são representadas por peças refugo e retrabalho.

26 23 Figura 2 - Relação entre perdas dos equipamentos e os indicadores OEE Fonte: (Nakajima, 1989). Segundo Johnson e Lesshammar (1999 apud DAL; TUGWELL; GREATBANKS, 2000) essas perdas, ou distúrbios, na linha de produção são classificadas como crônicas e esporádicas de acordo com a frequência de ocorrência. As crônicas são geralmente pequenas, discretas e complicadas porque são o resultado de várias causas em simultâneo. As perdas esporádicas são mais evidentes, já que ocorrem irregularmente e com mais frequência, provocando um desvio do estado normal e possui efeitos que podem levar a problemas mais graves. Com base nessas perdas, são identificados seis principais e grandes problemas que uma fábrica pode possuir. Como descrito em Nakajima (1988 apud DAL; TUGWELL; GREATBANKS, 2000), essas seis perdas são: 1. Quebra ou falha de equipamentos. Essas perdas são categorizadas como tempo perdido quando a produtividade é reduzida, e perdas quantidade são causadas por produtos defeituosos. 2. Tempo de setup e ajustes. Refletem em perdas de tempo de paradas e produtos defeituosos que ocorrem quando a produção de uma peça termina e o equipamento é ajustado para dar continuidade em outra peça.

27 24 3. Inatividade e perdas menores de parada. Ocorrem quando a produção é interrompida por um problema temporário ou quando a máquina está inativa. 4. Perdas por redução de velocidade. Referem-se à diferença entre velocidade normal do equipamento e velocidade de operação atual. 5. Redução de rendimento. Ocorre nas fases iniciais de start-up até inicialização da máquina. Tempo que o equipamento fica aguardando a regulagem inicial para começar a operar. 6. Retrabalho e defeitos de qualidade. Essas perdas ocorrem no índice de qualidade causadas por um mal funcionamento de equipamentos de produção. As primeiras duas perdas são conhecidas como perda no tempo e são usadas para calcular a disponibilidade de uma máquina. A terceira e quarta são perdas de velocidade que determinam o desempenho de uma máquina, ou seja, as perdas que ocorrem como uma consequência operacional menor das condições ótimas. As duas últimas perdas são consideradas relativas a defeitos, ou seja, quanto maior a quantidade de defeitos, menor a taxa de qualidade das peças dentro da fábrica. As informações coletadas pelo módulo de apoio à decisão são os dados das seis perdas mostrados na Figura 2 pelo fato de propiciar ao módulo uma informação mais precisa de cada índice da fórmula geral do OEE. Cada uma das seis perdas dos equipamentos possui uma forma de se prevenir e uma estratégia de redução. Conforme Silva ( ), essas relações são para tomar decisões sobre melhorias e ações corretivas se baseando nos dados fornecidos como entrada e para dar prioridade às ações que num trarão resultados mais rapidamente no futuro. O Quadro 3 descreve essas ações como base nas seis perdas de equipamentos. A primeira coluna representa cada perda, a coluna de Estratégias de Redução e Eliminação descreve qual ação deve ser tomada para amenizar a perda e a terceira coluna descreve quais são as prevenções possíveis para a perda.

28 25 Perdas Quebras/Falhas Quadro 3 Relação das seis perdas com as estratégias de redução e prevenção Estratégias de Redução e Eliminação Reparação mais rápida Detectar e corrigir as causas das avarias Estratégias de prevenção Manutenção preventiva Manutenção Preditiva Manutenção autônoma Setup/Regulagens Reduzir o tempo Conceber ou afetar equipamentos incorporando técnicas SMED Equipamentos Monoproduto (sem necessidade de mudança) Trabalho padronizado Lições de tema único Pequenas perdas Eliminação das perdas de paragens Manutenção centrada na fiabilidade Modificar equipamentos para alimentação contínua Formação e treino Perda de velocidade Refugos e retrabalhos Balanceamento das linhas de produção Detecção e correção das causas dos problemas de qualidade Aplicação da engenharia da fiabilidade Manutenção de qualidade Ações preventivas Autonomação Perdas de arranque Detecção e correção das causas das perdas Fonte: (SILVA, ). Estudar e implementas as condições ideais de arranque Modificar equipamentos e ferramentas O item 2.2 aponta os métodos de apoio à decisão que foram estudados como base para a concretização das ferramentas de uso. 2.2 SISTEMAS DE APOIO À DECISÃO O estudo e desenvolvimento de sistemas que auxiliam o usuário a tomar decisões importantes em uma organização fazem parte de uma área relativamente recente. Nesse capítulo são abordados conceitos dos Sistemas de Apoio à Decisão (SAD) e como podem ajudar no aperfeiçoamento do software de controle de fluxo produtivo. O item traz uma introdução à sistemas de apoio à decisão para esclarecer alguns pontos importantes para o trabalho.

29 Introdução à sistemas de apoio à decisão Sistemas de apoio à decisão são ferramentas poderosas em sistemas que transmitem ao usuário algum tipo de informação útil para a vida real, ou que uma decisão a ser tomada venha a depender do resultado obtido. O processo decisório sempre envolve riscos e leva a consequências. Dependendo do grau de importância, uma decisão pode proporcionar estresse aos decisores e geralmente, após se tomar decisões importantes, acontece um relaxamento nos organismos dos mesmos (PEREIRA & FONSECA, 1997). Revisando o histórico dos sistemas de apoio à decisão, como apresenta Power (2002 apud HEINZLE; GAUTHIER; FIALHO, 2010), por volta dos anos 60, pesquisadores começaram a estudar modelos e formulações para aplicar a computação na resolução de problemas do mundo real. Nessa época, esses sistemas eram vistos como sistemas computacionais interativos cuja funcionalidade era unir problemas não estruturados ao processo decisório. Conforme Power (2002), as primeiras tentativas de se usar técnicas de IA para aumentar a capacidade dos sistemas de apoio à decisão foi no final dos anos 80. A partir dos anos 90, várias técnicas de IA foram pesquisadas e com base nesses conhecimentos até então novos, é que a capacidade do processamento e consistência da resposta dos sistemas de apoio à decisão foi viabilizada (HEINZLE; GAUTHIER; FIALHO, 2010). Bispo (1998) faz um aprofundamento em três técnicas que obtiveram mais destaque: Data Mining, Data Warehouse e OLAP, mas também defende a ideia de que os métodos mais antigos vão continuar sendo usados e aperfeiçoados, tendo seu espaço garantido entre os desenvolvedores. No item é apresentada uma revisão dos conceitos de Árvores de Decisões, que serão utilizadas no desenvolvimento das regras de negócio do sistema especialista Árvore de decisões Para a construção das regras pelo engenheiro de conhecimento através do

30 27 especialista são usadas Árvores de Decisões, como podem ser vistas na Figura 7 do item Árvores de decisões, dentro do contexto de Sistemas Especialistas, são usadas para se definir um conjunto de regras e suas respectivas sugestões. Conforme Rezende (2003), uma árvore de decisão é uma estrutura cuja definição de dados é feita recursivamente utilizando-se os dois itens: Um nó folha representando uma classe ou, Um nó de decisão para validação de algum atributo. Um nó de decisão contém testes de atributos. Utilizando essa recursividade, pode-se construir uma árvore de decisões onde, para cada nó de decisão cujo teste seja válido, existe uma subárvore que contém a mesma recursão. O item 2.3 faz uma introdução à Inteligência Articifial e aos os conceitos de Sistemas Especialistas. 2.3 INTELIGÊNCIA ARTIFICIAL Este item aborda a última parte da fundamentação teórica, a de Inteligência Artificial. O item faz uma breve introdução à Inteligência Artificial, seguido de uma abordagem da técnica de Sistemas Especialistas Conceitos A Inteligência Artificial pode ser entendida como um ramo da ciência que estuda maneiras de uma máquina imitar o comportamento humano, e que essas máquinas possam ajudar o homem a resolver problemas, pensar de uma forma mais ampla e eficiente, e ainda mais do que isso, ter a capacidade de realizar coisas que os humanos fazem melhor atualmente. A Inteligência Artificial é um campo cujos conhecimentos oferecem modelos de apoio à decisão e ao controle, levando em consideração fatos reais e conhecimentos específicos mesmo que seja apoiado em dados incompletos (SELLITTO, 2002). Inteligência é a demonstração de princípios coerentes em escala de tempo verificável, a natureza é inteligente em escala de tempo inverificável para seres

31 28 humanos (CONAI, 1994). A Inteligência Artificial é definida como a capacidade de uma máquina controlada por um robô de realizar ordens associadas a processos superiores, que é característica dos seres humanos, capacidade de raciocinar, generalizar e aprender com experiências passadas. Usa-se esse termo para se referir a área da ciência da computação que tem o objetivo de desenvolver sistemas com tais capacidades (ENCYCLOPAEDIA BRITANNICA, 2001 apud DWYER, 2001). As pesquisas na área da Inteligência Artificial interessam à comunidade científica há muito tempo, porém, apenas recentemente, com os computadores modernos, a IA ganhou um impulso na aplicação desses estudos, em várias áreas como visão computacional, análise de sons, resolução do jogo de xadrez, lógica difusa, redes neurais artificiais, sistemas especialistas, raciocínio baseado em casos e outros. O cientista da computação Alan Turing, pela sua publicação chamada Computing Machinery and Intelligence em 1950, propôs o famoso Teste de Turing, que consistia em, um juiz humano conversar com outra pessoa e uma máquina em linguagem natural, sem saber a identidade de ambos. Caso o juiz não soubesse identificar qual é a máquina e qual é o humano, então a máquina passou no teste, sendo que essa conversa era feita apenas por texto, ou seja, o resultado não dependia da habilidade da máquina em renderizar áudio, apenas texto. Porém, sabe-se hoje que já existem ferramentas que fazem com que o computador interaja com o ser humano de forma natural em diferentes línguas, ou seja, que passam no teste de Turing. O item aborda o conceito de Sistemas Especialistas como parte da fundamentação teórica Sistemas especialistas Um ramo da Inteligência Artificial que demonstra ampla utilização em software de apoio à decisão são Sistemas Especialistas. Segundo Barreto (1997), Sistemas Especialistas são sistemas que apresentam uma forma de resolver um problema semelhante a um ser humano especialista em certo domínio. Esses sistemas abrangem um domínio de problemas restrito, mas apresentam um desempenho bom nesse campo

32 29 específico onde atuam. Especificam suas ações através de regras de raciocínio, que simulam o conhecimento do ser especialista. Os Sistemas Especialistas fazem parte de um ramo da Inteligência Artificial que são os Sistemas baseados em Conhecimento. Esses sistemas são programas de computador que resolvem problemas utilizando o conhecimento de forma explicita e manipulando-o com inteligência (REZENDE, 2003) Estrutura de um Sistema Especialista Conforme Barreto (1997), o conhecimento de um sistema especialista é alcançado a partir de dois tipos: fatos sobre o problema e regras que definem como o ser especialista raciocina para chegar a uma conclusão. Para se construir um sistema especialista é necessário: Dispor de uma fonte de conhecimento, que é o ser especialista, Extrair o conhecimento do ser especialista, convertendo-o em forma de regras para serem armazenadas no computador, Dispor de um mecanismo que gera explicações sobre como o ser especialista chegou a uma conclusão. Isso é necessário porque pode haver casos em que o usuário não concorda com a resposta do sistema, e quer ver qual a lógica usada para chegar à determinada resposta (BARRETO, 1997). Os dois primeiros itens são exercidos pelo Engenheiro do Conhecimento, o qual usa técnicas de psicologia. São usadas principalmente no início de atividade do sistema especialista, mas são de suma importância durante o ciclo de vida do sistema, pois atualizam o conhecimento. A Figura 3 mostra a estrutura padrão dos sistemas especialistas e a interação entre os componentes e o usuário. Destaca-se que o bloco Mecanismo de aprendizado não foi utilizado no trabalho, pois não faz parte da proposta do mesmo.

33 30 Figura 3 - Esquema lógico dos blocos de um Sistema Especialista Fonte: adaptado de Barreto (1997). O bloco de interface e explicação é responsável pela comunicação com o usuário através de linha de texto, interface gráfica, multimídia ou até realidade virtual. Também verifica se a resposta ao problema não está na Base de Conhecimento. Caso não esteja dá a resposta diretamente e, caso esteja na base de conhecimento, ativa o Motor e Inferência para que possa trabalhar em cima da Base para obtenção da resposta. O Engenheiro de Conhecimento se comunica com a Base de Conhecimento a fim de inserir nela as experiências dos seres especialistas, e monitora o funcionamento do sistema para efetuar ajustes na Base de Conhecimentos, que é de suma importância na fase inicial do ciclo de vida do sistema (BARRETO, 1997). Os fatos ficam guardados na Memória de Trabalho, que é uma memória volátil responsável por armazenar provisoriamente os dados que o usuário disponibiliza. O Motor de Inferência faz as deduções e alterar a Memória de Trabalho com novos fatos. Um ponto importante para o sistema é que, passado um certo tempo da fase inicial de aplicação, ele não dependa mais do ser especialista para fazer o processamento, ou seja, que ele deixe se comportar estaticamente e passe a se

34 31 atualizar sozinho, ou dinamicamente. Isso se torna mais importante para casos em que o ser especialista dá respostas diferentes para o mesmo problema (BARRETO, 1997). Características mais detalhadas da base de conhecimento, do motor de inferência, da memória de trabalho e da aquisição de conhecimento são discutidas nos itens que seguem nesse capítulo A base de conhecimento Para se implementar uma base de conhecimentos, dispõe-se de alguns métodos para representação do conhecimento: Representação do conhecimento por Regras de Produção, por Frames, Redes Semânticas e outros. As regras de produção se baseiam em condições que disparam eventos, ou seja, semelhante a um IF < premissas > THEN < conclusões > DO < ações > da maioria das linguagens de programação, onde IF verifica se todas as condições das premissas são satisfeitas e se forem as dispara, o THEN acrescenta as conclusões na memória de trabalho do Sistema Especialista e o DO executa as ações dessa premissa (REZENDE, 2003). As redes semânticas são implementadas como um grafo onde os nós são os objetos e as arestas são relações entre os objetos. Objetos que forem complexos podem ser separados em objetos mais simples (REZENDE, 2003). A base de conhecimento em Frames utiliza estruturas com slots, ou atributos, para representar os objetos e métodos que fazem a utilização dos atributos para a comunicação com outras Frames. Essas estruturas são caracterizadas como classes em programação orientada a objetos, por possuírem atributos e métodos. Os Frames fazem uma descrição mais detalhada do conhecimento (FILHO, 1995) O motor de inferência O motor de inferência de um sistema especialista é a peça que faz efetivamente o processamento dos dados armazenados, sendo responsável por fazer a inferência das regras sobre os fatos. Para fazer essa inferência, os Sistemas Especialistas utilizam em seu

35 32 mecanismo de inferência dois modos de controle: encadeamento para frente e encadeamento para trás. Esses dois tipos não dependem de uma base de conhecimento diferente para atuarem (FILHO, 1995). O tipo de encadeamento para frente faz uma verificação começando pelos fatos e aplicando-os sobre as regras da base de conhecimento. Se todas as premissas forem satisfeitas, é ativada uma ou mais consequências. O encadeamento para trás é o contrário do encadeamento para frente. O motor de inferência busca regras para provar os fatos que estão na memória de trabalho e, por último, tenta provar as premissas (FILHO, 1995). A diferença encontrada dos dois tipos de encadeamento é que o encadeamento para frente parte de um tempo presente seguindo a um tempo futuro para encontrar soluções com base nas regras e fatos. O encadeamento para trás parte de um tempo presente voltando a um tempo passado para achar os fatos a partir das deduções já feitas Memória de trabalho A memória de trabalho é uma área do Sistema Especialista que armazena os fatos registrados pelo usuário ou pelo engenheiro de conhecimento. Se os fatos são obtidos pelos usuários, faz-se uso do componente Interface e Explicação da Figura 3 para capturar os fatos do usuário. Entre as funções da Interface e Explicação, uma delas é não permitir que o usuário insira a mesmo fato mais de uma vez, outra é apresentar um log do raciocínio realizado ao longo da execução do Sistema Especialista para se chegar a uma conclusão. Essa memória é dita volátil, pois guarda informações momentaneamente, podendo ser modificada e reiniciada após a execução do Sistema Especialista (REZENDE, 2003) Aquisição de conhecimento Conforme discorre Mastela (2004 apud COSTA E SILVA, 2005), a aquisição do conhecimento é o primeiro e mais difícil passo para a construção de um Sistema

36 33 Especialista, sendo reconhecido como o gargalo da implementação. Esse gargalo é consequência da não existência de uma metodologia de comunicação eficiente entre os atores do cenário. Com isso, foram formalizadas três formas que melhoram o aproveitamento e reduzem esse gargalo da eficiência, que são classificadas em manuais, semi-automáticas e automáticas. A forma manual pode ser de dois tipos: baseada em acompanhamento ou entrevistas. O método de acompanhamento consiste em o engenheiro de conhecimento acompanhar o raciocínio do especialista sobre casos reais. O método de entrevista consiste na realização de entrevistas com o engenheiro de conhecimento fazendo perguntas do domínio ao especialista. As formas semi-automática e automática consistem em se utilizar ferramentas que possam auxiliar o engenheiro de conhecimento a formular as regras e, fazer a indução automática de casos de entrada através do aprendizado de máquina, respectivamente (COSTA; SILVA, 2005). O método de aquisição de conhecimento que utilizado foi o manual do tipo baseado em entrevistas. As formas semi-automáticas e automáticas não foram utilizadas, pois fogem do escopo da proposta. 2.4 CONCLUSÃO DO CAPÍTULO Neste capítulo foram descritos alguns conceitos sobre Sistemas de Apoio à Decisão e sobre Inteligência Artificial. Verificou-se que os sistemas especialistas demonstraram pontos positivos em relação ao tipo da aplicação a ser desenvolvida porque simulam o conhecimento do ser especialista em um domínio, o OEE, através de regras e fatos. Eles reduzem a dependência da organização em relação à pessoa que toma decisão, quando este não se faz presente ou às vezes a organização está temporariamente sem decisor. Os sistemas especialistas também podem servir para treinamento de pessoal. A desvantagem dos mesmos é o gargalo da aquisição de conhecimento do especialista, a dificuldade de se extrair o conhecimento do especialista de uma forma proveitosa, o que se torna um desafio computacional. O modo de interação usado foi o de encadeamento para frente, para analisar os dados de entrada do SOEE e gerar uma solução com base nesse caso de teste. Como

37 34 desafio computacional dessa técnica tem-se o gargalo da aquisição de conhecimento, que foi tratado pelo método de aquisição manual baseado em entrevistas. Para a construção do módulo, necessita-se conhecer o software ao qual essa nova parte foi adicionada. O capítulo 3 fará uma descrição das ferramentas que foram utilizadas para a construção do módulo utilizando sistemas especialistas.

38 35 3 FERRAMENTAS UTILIZADAS Nesse capítulo são descritas informações sobre o SOEE, sistema ao qual o módulo de apoio à decisão atuará, e uma ferramenta para comparação quantitativa, o JESS (JESS, 2008). O item 3.1 aborda as características mais importantes do SOEE para a implantação do módulo de suporte aos usuários, como modelo computacional e arquitetura. O item 3.2 descreve a ferramenta JESS que foi utilizada como outra parte do módulo, para comparar os resultados gerados pelo módulo com os resultados gerados pelo interpretador JESS O item 3.3 traz trabalhos relacionados ao trabalho, seguido do item 3.4, que faz uma conclusão desse capítulo, apresentando um reforço nos temas que foram vistos. 3.1 O SOEE O SOEE, software ao qual foi incorporado o módulo de apoio à decisão neste trabalho, é resultante do projeto de duas bolsas de iniciação científica pela Fundação Araucária, intitulado Sistema para Gerenciamento de Processos e Acompanhamento do Fluxo Produtivo em Pequenas e Médias Indústrias (ZATTAR, 2009). O projeto tem origem no laboratório G-SAPO, da UFPR, em parceria com o LARVA, da UDESC. O sistema foi desenvolvido pelos bolsistas Clayton Ivan Mendes e Guilherme Augusto Gallina, alunos de graduação do curso de Bacharelado em Ciência da Computação da UDESC. Esse sistema é orientado a objetos e foi desenvolvido sobre o modelo computacional cliente/servidor, onde uma máquina armazena o banco de dados, e as demais máquinas atualizam esse banco através de uma rede local. Segundo Renaud (1994 apud DOERNER, 2004), cliente/servidor é um modelo computacional para interação entre processos de software que executam de uma maneira concorrente. A metodologia cliente/servidor foi criada com o objetivo de possibilitar que as aplicações de máquinas diferentes troquem informações entre si de forma independente. Essa metodologia visa estabelecer um paradigma que permite o

39 36 processamento de dados entre a máquina cliente e a servidora. Ao mesmo tempo, objetiva fornecer recursos para sincronização desses processos de forma que a perda dessa sincronização não acarrete na perda de informações relevantes ao banco de dados (DOERNER, 2004). A linguagem de programação usada no projeto foi o Java, por dois motivos: a) Por ser baseada em software livre e, b) Por possuir uma grande portabilidade, dessa forma, permitindo que o software seja multi-plataforma. O software pode ser utilizado em qualquer plataforma (sistema operacional) em que esteja instalada uma máquina virtual Java (JVM). O sistema foi dimensionado de forma a atender pequenas e médias empresas de diferentes domínios produtivos (ZATTAR, 2009), que eram requisitos do projeto Níveis de autorização O sistema possui quatro níveis de autorização, que concedem acesso a diferentes telas aos usuários: Administrador, Supervisor, Operador e Visitante. O administrador tem acesso a todas as funções do sistema menos a de operador, e é o único com permissão para inserir, alterar ou apagar os tipos de dados em que o sistema se apoia. Por exemplo, somente o administrador pode cadastrar turnos, funcionários, máquinas, peças, clientes, fornecedores e motivos de paradas. O supervisor tem acesso a todas as telas menos a tela de configuração, conforme a Figura 4. A função principal do supervisor é cadastrar novas ordens de fábrica, que consiste em atrelar peças a um pedido. Um exemplo seria associar, para um pedido com código Montadora ABC, uma peça Bloco de motor 1600 cm³. O operador é quem opera as máquinas e somente tem acesso à tela de chão de fábrica. Essa tela possui duas opções, registrar uma parada e cadastrar uma nova produção. Uma parada pode ser de natureza programada ou não-programada. Quando se cadastra uma nova produção são solicitados dados como a ordem de fábrica, a máquina, quantidade de peças produzidas e horário da produção do lote. Por último, o visitante possui apenas acesso à tela de relatórios. Nessa tela são

40 37 gerados os relatórios dos três índices de desempenho descritos no capítulo 2: Qualidade, Disponibilidade e Performance. Os relatórios são mostrados em forma de gráficos e também disponibilizam a opção de exportação para documento PDF. Figura 4 - Tela de distribuição de níveis de permissão do SOEE Fonte: Autor do trabalho Arquitetura O software foi desenvolvido no ambiente NetBeans IDE, devido a maior facilidade em se montar as janelas gráficas. Possui a arquitetura em três camadas: a) Apresentação ou interface com o usuário: contém as telas e implementa funções locais como contadores de tempo e gerador de relatórios. b) Fachada ou lógica de negócio: faz a ligação da camada de apresentação com a camada de persistência de dados através de interfaces. Implementa funções como conversão de tipos de dados, cálculos sobre tempo de paradas e verificação de formatos de horas. c) Persistência de dados: faz a conexão com o banco de dados e executa as funções de cadastro, alteração, exclusão e seleção dos dados. Nessa camada é que são montados os comandos SQL que serão executados pelo

41 38 banco. A arquitetura em três camadas é uma forma de se obter um grau de abstração que proporciona segurança ao sistema, bem como uma organização quanto à distribuição de tarefas, através do uso de interfaces entre as classes. A utilização dessa arquitetura com orientação a objetos proporciona o reuso de código. A Figura 5 mostra o diagrama de classes do SOEE de uma forma genérica, ou seja, uma representação conceitual das classes e suas relações, e também a visualização da divisão das três camadas. Figura 5 - Diagrama de classes reduzido do SOEE Fonte: Autor do trabalho.

42 39 O sistema utiliza quatro bibliotecas principais para gerar os gráficos, documentos PDF e calendários. São elas: jfreechart (JFREECHART, 2000), itext 1.3 (ITEXT, 2011), jcalendar 1.4 (JCALENDAR, 2011) e jcommon (JCOMMON, 2011) Camada de Apresentação A camada de apresentação ou interface com o usuário trata das telas do SOEE. As telas possuem a característica de acesso individual, ou seja, o usuário só pode usar uma tela por vez. Essa camada usa imagens contidas no pacote Imagens e também implementa funções de criação dos gráficos e relatórios em PDF. A comunicação com a camada lógica ou fachada é feita através da implementação de interfaces do Java. Todo dado que deve ser guardado, alterado ou resgatado da camada de persistência através da camada de apresentação, passa pela camada lógica. As três camadas se comunicam com o pacote To, representado na Figura 5, que armazena as classes que representam as tabelas do banco de dados. é instanciando essas classes que o sistema faz inserções, alterações e exclusões da base de dados Camada de Fachada A camada de Fachada é a camada intermediária entre a apresentação ao usuário e a persistência dos dados. Possui uma interface própria, a FacadeI, que é implementada pela classe Facade e instanciada pela camada de apresentação. Ela se comunica com a camada de persistência de dados através da interface DAOI. A camada de Fachada também disponibiliza funções que fazem verificações genéricas para a camada de apresentação, como verificação de horários, datas e tempo de paradas, fazendo consultas à base de dados. As principais funções implementadas nessa camada são as funções de cálculo dos indicadores da métrica OEE, como total de horas de produção por máquina.

43 Camada de Persistência dos dados O banco de dados usado para a persistência das informações é o PostgreSQL (), que disponibiliza várias operações que garantem a integridade do banco. Uma das operações que esse banco disponibiliza é a verificação de exclusão de chaves estrangeiras. Uma vez que o usuário tentar excluir um registro de uma tabela cuja chave primária é chave estrangeira de outra tabela, o banco retornará um aviso e não completará a transação. Outra operação que o PostgreSQL oferece é o controle de acesso simultâneo ao banco, ou seja, o próprio banco trata a inserção, alteração e exclusão de dados que os usuários estejam alterando concorrentemente. Contudo, a opção de utilização do bando de dados PostgreSQL foi tomada pela robustez que o software demonstra, pelo volume de dados suportado por tabela ser suficientemente grande para o escopo do projeto e pelo fato de o PostgreSQL ser Open Source e de uso livre quando destinado a fins educacionais e pesquisa. A possibilidade de substituição da base de dados é válida, desde que sejam feitas pequenas alterações no código-fonte do SOEE. Mais especificamente, na camada de persistência dos dados, onde está localizado o código que faz a conexão com o banco. 3.2 A FERRAMENTA JESS Esse item faz uma abordagem na ferramenta e linguagem de programação para sistemas especialistas JESS (Java Expert System Shell) (JESS, 2008). O JESS foi criado no estado de Califórnia, nos Estados Unidos da América, por Ernest Friedman- Hill no Laboratório Nacional Sandia. O item descreve conceitos básicos da linguagem, como o motor de inferência, tipos de dados e sintaxe e, o item demonstra a criação de regras e inserção de fatos no JESS A linguagem O JESS possui uma máquina de inferência baseada em regras escrita na

44 41 linguagem de programação Java. O propósito dessa linguagem é oferecer ao usuário um sistema especialista com a base de conhecimento baseada em regras e fatos. O JESS disponibiliza duas formas de usá-lo: através de uma Shell que a linguagem oferece, onde as inserções de regras e fatos são feitas por linha de comando, ou pra uma API (Application Programming Interface) que pode ser usada dentro de classes e métodos da linguagem Java (JESS, 2008). Conforme Cardoso (2007 apud ZATTAR, 2008), o aumento da utilização sistemas que são baseados em agentes e da linguagem Java, o JESS passou a ser visto como uma ferramenta de apoio à decisão implementada sobre um paradigma declarativo. O motor de inferência da linguagem usa uma versão aperfeiçoada do algoritmo Rete para fazer a inferência das regras armazenadas na base de conhecimento. Esse algoritmo eficiente de reconhecimento de padrões foi proposto por Charles L. Forgy na sua publicação intitulada Rete: A fast algorithm for the many pattern match problem, em 1982 (JESS, 2008). O algoritmo Rete faz o casamento de padrões usando uma rede de fluxo de dados construída partindo-se do lado esquerdo das regras, ou o lado do IF, que valida todas as premissas. Essa rede é composta de nós, que são representados por operações abstratas que vão ser realizadas na fase de match (casamento das premissas), e por arestas, que passam tokens pelos nós. Esses tokens consistem em uma referência a uma lista de elementos da memória de trabalho (PIZZOL, 2001). A sintaxe do JESS é baseada na linguagem de programação funcional LISP, e desta, herda o conceito de cálculo Lambda e também permite a declaração de regras e fatos para fazer a inferência automática do conhecimento (JESS, 2008). A base da linguagem é o uso de listas, que contém um cabeçalho e um ou mais operadores. O uso dessas listas é de forma hierárquica, ou seja, como uma árvore de vários filhos. A ordem de precedência é feita através dos nós dessa árvore, ou, do aninhamento das listas. Um exemplo de cálculo matemático no JESS é ( + ( 5 8 ) ( 2 4 ) ), onde os operadores de multiplicação e adição são o cabeçalho da lista. Conforme o aninhamento das listas, a ordem de execução para esse exemplo são as duas

45 42 multiplicações e, posteriormente, a adição. Atribuições feitas a variáveis são feitas por uma lista com cabeçalho bind: (bind? teste valor de uma string ), onde a variável teste recebe uma string. Uma função que retorna o quadrado de um número pode ser escrita como: (deffunction square (? num1? num2) (return (? num1? num2))), onde a palavra reservada deffunction declara a função Memória de trabalho do JESS As regras atuam sobre a memória de trabalho do JESS, podendo agir sobre fatos que foram inseridos, alterados ou excluídos. Os fatos podem ser puramente criados no JESS ou exportados de um programa Java. Todo fato possui um template que é um modelo que compreende nome e slots para armazenar variáveis. Os templates são como uma tabela de um banco de dados: os slots são como os campos dessa tabela (JESS, 2008). Um exemplo de template pode ser escrito como um cadastro de um cliente em uma loja, que possui nome, telefone e endereço. A criação desse modelo é feita através da palavra reservada deftemplate: (deftemplate cliente (slot nome) (slot telefone) (slot idade)). Para esse modelo podem ser feitas inserções de fatos na memória de trabalho do JESS. Essa associação é feita pelo uso do assert: (assert (cliente (nome Pedro) (telefone ) (idade 23) )) em que os valores são atribuídos por meio de listas. As regras do JESS são como a afirmação IF <premissas> THEN <ação> de linguagens procedurais, a diferença é que não são executadas de uma forma procedural. Em linguagens procedurais, essas afirmações são executadas em um lugar específico do código, em que o programador sabe quando elas são verificadas. No JESS essas afirmações são executadas sempre que a parte esquerda, ou o IF <premissas>, é satisfeita. Essa imprevisibilidade de quando a regra é satisfeita faz com que o JESS seja menos determinística que linguagens procedurais (JESS, 2008). Para o exemplo do cliente, pode-se definir uma regra em que a string cliente menor de idade é exibida pela Shell caso a idade de um cliente seja menor que 18

46 43 anos. Uma regra é criada pela palavra reservada defrule: (defrule verificaidade (cliente *idade < 18+) => (printout t Você é menor de idade)) Com o comando (run) o JESS começa a tentar fazer o casamento das premissas com as regras cadastradas. O item 3.3 descreve trabalhos relacionados à este trabalho. 3.3 TRABALHOS CORRELATOS Como descrito em Oliveira & Helleno (2012), os sistemas de apoio à decisão entram cada vez mais no mercado oferecendo maior agilidade na análise e apresentação dos dados. Dessa forma, o autor traz revisão de conceitos de indicadores de eficiência operacional e faz um estudo de caso da aplicação de um sistema comercial em uma indústria eletroeletrônica, utilizando um sistema de apoio à decisão para apoiar a gestão na tomada de decisão. O sistema implantado para o estudo de caso foi o software PCP Master MES 1 que faz o controle de gestão da produção em tempo real para que possam ser tomadas decisões ou ações de maneira mais rápida. O sistema PCP Master MES utiliza uma IHM (Interface Humano-Máquina) acoplada a uma rede local wireless cuja função é monitorar o estado da máquina em tempo real e sem a interrupção do funcionário operador (OLIVEIRA; HELLENO, 2012). Tal sistema possui a funcionalidade de dar sugestões aos gestores para a tomada de decisões dentro da organização partindo de dados coletados por um hardware acoplado às maquinas. Os dados coletados das máquinas são submetidos à análise utilizando regras cadastradas em uma base de dados. Tais regras são levantas através de um mapeamento de problemas possíveis a cada máquina pelos gestores juntamente com funcionários que enfrentam esses problemas constantemente. Os motivos de problemas são codificados numericamente e adicionados à base de dados utilizada pelo sistema. Através dessa verificação do status da máquina com as regras cadastradas na base de dados, a IHM mostra para o usuário informações em tempo real sobre os indicadores da métrica OEE e possíveis soluções para o problema, de 1

47 44 acordo com as regras inseridas na base (OLIVEIRA; HELLENO, 2012). O sistema é online e pode ser utilizado em uma rede durante qualquer período, mesmo com o servidor temporariamente indisponível, pois as centrais IHM tem capacidade de memória para registrar dados de aproximadamente 24 horas (EGA, 2012). O item 3.4 finaliza o capítulo apresentando um resumo do que foi descrito. 3.4 RESUMO DO CAPÍTULO O objetivo desse capítulo foi mostrar os pontos mais importantes do SOEE desenvolvido no laboratório LARVA pelo projeto de pesquisa em parceria com a UDESC e UFPR, e da ferramenta JESS para sistemas especialistas. Os itens abordados do SOEE são relevantes para a compreensão e implementação do módulo de apoio à decisão, como o modelo computacional base cliente/servidor, a arquitetura do software em camadas, a linguagem de programação Java e os níveis de autorização. Fez-se uma revisão nos princípios da linguagem JESS, que foi desenvolvida internamente na linguagem Java. O motor de inferência do JESS tem fundamento no algoritmo Rete de casamento de padrões, que proporciona uma implementação eficiente de busca. O desenvolvimento do módulo de apoio à decisão usando Sistemas Especialistas que foi adicionado ao SOEE é descrito no capítulo 4, bem como especificações abstratas da regra de negócio que padronizará as inserções de regras na base de conhecimento do sistema especialista.

48 45 4 ESPECIFICAÇÕES DO MODELO DESENVOLVIDO A proposta deste trabalho é dar continuidade ao projeto de pesquisa realizado em 2011 que foi suportado pela Fundação Araucária, incorporando um módulo de apoio à decisão no sistema já desenvolvido, como discutido no capítulo introdutório do trabalho. Esse módulo dispõe de duas análises: uma análise do SOEE e outra da ferramenta JESS. O intuito desse módulo é analisar os dados de saída do SOEE, propondo uma resposta ao usuário de como ele deve agir dentro da organização, e o informando qual a decisão mais favorável a se tomar. O item 4.1 desse capítulo aborda os principais problemas que foram enfrentados no desenvolvimento desse módulo de apoio à decisão. O item 4.2 mostra as especificações da construção do módulo, seguido do item 4.3 que fala do desafio computacional observado com o desenvolvimento do trabalho e por último, as conclusões desse capítulo. 4.1 O PROBLEMA RESOLVIDO Como descrito no preâmbulo do capítulo, esse item faz uma introdução ao que foi desenvolvido apresentando a interação entre os componentes do sistema no item e os principais problemas enfrentados de diferentes pontos de vista no item Interação de componentes do sistema Os componentes do sistema interagem entre si utilizando instâncias de classes e criando telas. Para invocar a análise SOEE-JRA, o sistema instancia a classe ModuloSE passando os parâmetros de busca, e esta cria as classes usadas na análise como a EngineBase e MemoryWork. Caso a organização tenha necessidade de alterar a estrutura da análise SOEE-JRA, bastaria a mudança de classes do pacote específico à análise SOEE-JRA, mantendo a interface de ligação. Para realizar a análise, as classes do sistema SOEE utilizam os dois

49 46 componentes implementados, a análise JESS e a análise SOEE-JRA. Essas, por sua vez, usam classes específicas e distintas a cada implementação. Em outras palavras, as classes utilizadas na análise JESS não são usadas na análise SOEE-JRA. Uma visualização da interação do sistema com o módulo de apoio à decisão pode ser vista na Figura 6. Essa figura mostra a interação do sistema SOEE com os tipos de análise implementados e suas ligações com o banco de dados. Figura 6 - Diagrama de interação do sistema com o módulo de apoio à decisão Fonte: Autor do trabalho. Pela Figura 6 tem-se uma visão geral e abrangente do sistema que foi implementado e como se comunica com a base de dados. O ponto mais relevante a ser considerado é que cada análise faz comunicação independetemente com a base, não dependendo de dados provenientes do sistema, mas somente dos dados já cadastrados no banco de dados. Outra observação é que as setas de interação da análise SOEE-JRA e JESS são

50 47 unidirecionais e a seta que liga as classes e telas do sistema SOEE com a base de dados é bidirecional, ou seja, na seta bidirecional o sistema resgata dados do banco e os modifica, e nas setas unidirecionais, somente há consulta ao banco de dados, sem modificar qualquer dado já inserido. As análises JESS e SOEE-JRA estão demonstradas na Figura 6 em níveis de detalhamento como uma lupa, desde a criação das instâncias das classes Rete e ModuloSE até o call dos métodos respectivos. Tais métodos podem fazer consultas à base de dados Os problemas de pontos de vista diferentes O principal problema observado pelo ponto de vista da aplicação é a definição de como e quando os dados seriam armazenados no banco para a análise do módulo de apoio à decisão. Em outras palavras, o desafio é coletar os dados que o software gerou de modo a transmiti-los ao módulo. Para isso, o esquema lógico relacional entre o SOEE e o módulo deve compreender a grande maioria das informações contidas nas tabelas, ou seja, os campos mais importantes, para que a análise seja mais detalhada. Outro problema observado do ponto de vista da aplicação é da interface de comunicação entre o módulo de apoio à decisão e o SOEE. Essa interface deve garantir o tráfego seguro dos dados e organizá-los de modo a garantir uma maior facilidade na sua manipulação dentro do módulo, respeitando a lógica da arquitetura em camadas. Como descrito por Nakajima (1988 apud DAL; TUGWELL; GREATBANKS, 2000), as seis grandes perdas de uma fábrica estão distribuídas dentro dos três índices do indicador de qualidade OEE, que são a Disponibilidade, Performance e Qualidade. O problema do ponto de vista da Inteligência Artificial para o domínio do OEE é a aprendizagem de máquina, representado pelo mecanismo de aprendizado na Figura 3, na qual o desafio é fazer com que o sistema especialista aprenda de uma maneira autônoma mesmo quando o ser especialista, que é o engenheiro de conhecimento, não está mais atualizando a base de conhecimento. Contudo, o mecanismo de aprendizagem por máquina não faz parte do escopo do trabalho.

51 48 Os problemas do ponto de vista do usuário são que o usuário primeiramente deve entender o funcionamento do sistema. Onde está localizada cada tela, qual sua funcionalidade, como gerar os relatórios baseado nos filtros, entre outros. O software deve tratar todos os possíveis erros que possam aparecer na execução. Por exemplo, deve tratar campos de texto como datas, nome, quantidades e lotes. Qualquer digitação que o usuário faça que não seja a correta, deve ser prevista pelo sistema a fim de corrigi-la, evitando que essa informação com erro chegue até o banco de dados. Portanto, os dois principais problemas do ponto de vista do usuário que foram percebidos são: a) A facilidade do usuário em saber usar cada tela: o usuário saber a funcionalidade da tela que está executando, exigindo assim uma interface amigável das telas do sistema. b) Uma boa documentação do software: o usuário exige que o sistema disponibilize documentação completa das funcionalidades que oferece, bem como um manual do usuário. 4.2 SOLUÇÃO DO PROBLEMA Nesse item são apresentados os diagramas que mostram as funcionalidades pretendidas com a implementação do módulo de apoio à decisão. O item descreve como é a associação das perdas de máquinas observadas nas deduções que o módulo faz e o item descreve a interação do usuário final do sistema com as funcionalidades deste através de diagramas de classes, sequência, casos de uso e de atividades. O item define um modelo de regras usadas para implementação do módulo e para servirem de modelo no interpretador do JESS Descrição da regra de negócio O módulo se comunica com o SOEE através de uma interface, para garantir segurança nos dados. Essa interface liga a camada de persistência dos dados ao

52 49 módulo e, é através dela que as classes do pacote de apresentação vão mostrar os dados processados pelo módulo para o usuário. A base dos cálculos do módulo são as seis grandes perdas de uma fábrica, como descrito na Figura 2 do item Essas seis grandes perdas representam genericamente os problemas apresentados, ou seja, podem existir outros problemas distintos internos a cada um dos seis itens. No funcionamento normal de uma fábrica, podem ocorrer situações em que essas seis perdas se tornem consequências umas das outras. Por exemplo, caso um problema de parada seja registrado, a qualidade das peças do lote em que essa máquina está atuando pode ser prejudicada devido a essa parada. As regras de inferência foram levantadas pelo método de entrevista entre o engenheiro de conhecimento e o especialista. Essas regras foram adicionadas no módulo interno do SOEE e no JESS. O domínio de implementação das regras foi baseado em um estudo de caso realizado em Oliveira e Silva (2011), orientado pela Professora Dra. Izabel Zattar, do Departamento de Engenharia de Produção da UFPR, em uma empresa de laticínios chamada Laticínios Carolina localizada na cidade de Ribeirão Claro Paraná. A máquina utilizada para os testes é uma envasadora com tampador. A Figura 7 mostra um exemplo de conjunto das regras para o Indicador de Qualidade cadastradas na base de conhecimento. Pode-se perceber através da Figura 7 que uma série de perguntas são feitas para se designar que ação sugerir ao usuário. A primeira pergunta é se o lote parcial em questão está acima do limiar. O limiar é definido pelo usuário por meio dos filtros da tela no momento da consulta. Por padrão esse valor é de 75%, podendo o usuário alterá-lo se achar necessário. Caso o lote parcial analisado apresentar qualidade acima do limiar, é mostrada a mensagem Qualidade OK e a análise deste é encerrada e o fluxo de execução analisa a próxima entrada. Caso não esteja acima do limiar, é feita uma nova pergunta: se o lote possui garrafas com quantidade de líquido menor que o especificado. Se possuir, é tomado como refugo e sugerido ao usuário realizar o ajuste da máquina, senão, vai para a próxima pergunta.

53 50 Figura 7 - Regras do indicador de Qualidade Fonte: Autor do trabalho. Na terceira pergunta, caso a resposta seja sim, então a sugestão é de verificar a qualidade da matéria-prima, verificar o alimentador de tampas e fazer ajuste no tampador. Caso negativo é feita a próxima pergunta: se o lote foi feito com tampas erradas. Se o lote apresentar erro nas tampas, então é sugerido erro do operador e enviá-lo para treinamento. Por fim, é feita a última pergunta se falta rótulo, caso positivo o lote é tomado como retrabalho e a sugestão é verificar o alimentador de rótulo e matéria-prima e, caso negativo, o problema ocorrido não foi levantado e são mostradas as sugestões correspondentes. A Figura 7 remete-se à uma árvore de decisões, pois está dividida em níveis hierárquicos. A memória de trabalho do JESS trabalha a cada nível da árvore que seja acessado, através da definição assert da linguagem. Para as regras do indicador de disponibilidade não foi usada representação em árvore, mas sim uma tabela que relaciona os motivos de paradas das máquinas às sugestões. A Figura 8 apresenta essa relação entre o problema que ocasionou a parada da máquina envasadora e a

54 51 sugestão dada. Tais motivos de parada foram disponibilizados pela Professora Izabel Zattar por meio de uma planilha contendo a relação de paradas e motivo de paradas. Figura 8 - Regras do indicador de Disponibilidade Fonte: Adaptado de OLIVEIRA E SILVA (2011). Como mostrado na Figura 8, a relação entre o problema e a sugestão de solução é de 1:1, ou seja, para cada problema tem-se uma sugestão. As paradas contidas na Figura 8 são do tipo não-programadas. Como descrito no item 2.1.3, o índice de Performance é obtido pelo quociente da produtividade real em itens/peças por unidade de tempo e a produtividade real, que é fornecida pela fabricante da máquina.

55 52 No contexto do sistema SOEE, a modelagem da base de dados define duas tabelas principais para entrada de dados de produção pelo operador: a tabela de peças produzidas e de paradas registradas. Conforme especificação das tabelas da base de dados, a obtenção do percentual do indicador de performance é feita com base nos indicadores de qualidade e disponibilidade, ou seja, o indicador de performance está diretamente relacionado aos outros dois, pois utiliza os dados de produções e paradas para efetuar o cálculo. Em outras palavas, quanto menos paradas e produção de lotes com peças refugo ou retrabalho ocorrerem, melhores serão os índices de disponibilidade e qualidade respectivamente e, por consequência, melhor será também o índice de performance. Portanto, as regras de performance podem ser ditas como as regras de qualidade e disponibilidade, pois, melhoras nesses dois índices produzirão melhoras no índice de performance. A Figura 9 mostra as regras de Performance definidas pelo engenheiro de conhecimento. Figura 9 - Regras do indicador de Performance Fonte: Autor do trabalho. Para este indicador, apenas uma pergunta é feita: se o índice de performance apresentado no período buscado satisfaz o limiar definido pelo usuário. Caso positivo, a mensagem de Performance OK é exibida como resultado e, caso contrário, a sugestão de realizar ajuste na máquina é mostrada Arquitetura do sistema Nesse item são apresentados diagramas que descrevem o módulo em diferentes

56 53 visões. O primeiro diagrama é o de Casos de Uso e representa a interação dos usuários com as funcionalidades do sistema. Esse diagrama pode ser visto na Figura 10, onde se mostra o cenário da interação do usuário final com o sistema pelas duas formas de análise. Figura 10 - Diagrama de Casos de uso para o sistema em geral Fonte: Autor do trabalho. A Figura 10 mostra o sistema geral de uma maneira mais formal, demonstrando as funcionalidades oferecidas em um tempo não sequencial. Essas funcionalidades representam esse formalismo. Os símbolos representados pela Figura 10 de uma pessoa são os Atores, ou seja, as pessoas que interagem com o sistema. Esses atores interagem com as funcionalidades que o sistema oferece, representadas pelos balões com uma descrição dentro indicando a funcionalidade. A funcionalidade Solicita sugestão SOEE interage com a funcionalidade de

57 54 Acionar o Motor de Inferência através de uma ligação << include >>, ou seja, sempre que a funcionalidade de solicitação de sugestão for ativada o acionamento do Motor de Inferência também será ativado, representando uma obrigatoriedade. A funcionalidade Solicita sugestão JESS interage com a funcionalidade Acionar o Motor de Inferência fazendo a análise pela ferramenta JESS. Os atores Engenheiro, que é o Engenheiro de Conhecimento, e o Especialista realizam a entrevista para fazer a aquisição de conhecimentos. Essa entrevista gera uma saída, que é o conhecimento absorvido e representado em forma de regras de produção, que é adicionada na Base de Conhecimento do Sistema Especialista. O atributo << extends >> representa uma ligação que pode ou não ser ativada, ou seja, sempre quando for realizada uma entrevista, não necessariamente são adicionadas regras de produção à Base de Conhecimento. Para se ter uma visão das classes e pacotes utilizadas no sistema, gerou-se um diagrama de Classes. Esse diagrama representa a arquitetura usada no módulo de apoio à decisão, que é apresentado na Figura 11. Foi acrescentado um novo pacote Java analisesoee no módulo SOEE cuja interface ModuloSEI faz a ligação entre as classes EngineBase, MemoryWork e ModuloSE. No pacote de apresentação foi adicionada a tela de interface frmtelamodulo, que é a parte externa de um sistema especialista, como mostrado na Figura 3 do item O módulo comunica-se com a base de dados para buscar as informações através da interface FacadeI da camada lógica. A implementação do módulo interno ao SOEE é feita de uma maneira sequencial, ou seja, não possui uma simulação de não-determinismo como a ferramenta JESS. A modelagem do sistema permite a integração com cenários variados de produção, como exemplo, máquinas de torno automático ou mecânico, máquinas frezadoras ou robôs industriais. Para realizar essa mudança na regra de negócio basta realizar a inferência das regras para a área desejada com o engenheiro de conhecimento juntamente com o especialista. Todas as regras estão dispostas na classe EngineBase, dessa forma, a alteração das regras pela análise SOEE-JRA ficam restritas a uma classe ou arquivo, dificultando

58 55 a expansão do negócio conforme os padrões da orientação a objetos. Figura 11 - Arquitetura do SOEE com o módulo de apoio à decisão Fonte: Autor do trabalho. A regra de negócio utilizada pelo módulo é composta pelos indicadores OEE que estão relacionados com as seis grandes perdas de uma fábrica. É com base nesses seis indicadores de perdas que foram construídas as regras para o sistema especialista. A Figura 12 apresenta o diagrama de sequência da ordem de execução do módulo de apoio à decisão com análise do SOEE, onde o ator se comunica com o sistema através de chamadas de funções. A função btnanalisar() inicia a interface ModuloSEI através do acionamento do botão situado na tela do módulo. Essa interface cria o motor de inferência que obtém os fatos através da busca no banco de dados.

59 56 Figura 12 - Diagrama de sequência do módulo com análise do SOEE Fonte: Autor do trabalho. Após a busca ao banco, a interface ModuloSEI executa a função run() do motor de inferência, que faz o casamento das regras, gerando um resultado em texto. O casamento das regras na análise SOEE-JRA é feita sobre os comandos IF <premissas> THEN <ação>, ou seja, sempre que as premissas forem satisfeitas dentro de um comando IF, então as ações serão executadas. Na análise do SOEE, a execução é feita utilizando laços de repetição quando necessário. As regras contidas no SOEE fazem o controle de variáveis e geram os resultados em uma variável de texto global do tipo String, que é mostrada ao usuário que solicitou a análise. O item mostra a arquitetura e como é feita a troca de mensagens entre o SOEE e a ferramenta JESS A comunicação SOEE/JESS A comuniação entre o SOEE e a ferramenta JESS é feita utilizando-se a biblioteca de funções do JESS. Em outras palavras, como o JESS foi feito sobre a

60 57 plataforma Java, disponibiliza métodos análogos aos da linha de comando que podem ser utilizados por programas Java. Para utilizá-los, bastou criar uma biblioteca no ambiente de programação NetBeans e importá-la para o projeto. Essa API do JESS disponibiliza várias classes e métodos. Uma das classe mais importantes, porém, que a API oferece e que foi amplamente utilizada no projeto é a classe Rete. Essa classe oferece métodos importantes para o funcionamento da ferramenta, como definição de modelos, inserção de regras, inserção de fatos, método de explicação, o método run, entre outros. A fim de fornecer uma maneira visualmente mais limpa de apresentação dos dados para o usuário, optou-se em usar a biblioteca do JESS que disponibiliza classes e métodos dentro do ambiente SOEE, uma vez que a mesma oferece integração com o Java. A Figura 13 mostra a tela de interface do módulo de apoio à decisão. A tela apresenta dois botões principais que fazem a análise pelo JESS e pelo SOEE. Quando a análise pelo JESS é selecionada, há possibilidade de se definir um valor limiar para índices OEE, ou seja, o valor que será interpretado como separador entre análise com situação satisfeita e insatisfeita. Por padrão o valor do limiar é de 75%. A caixa de seleção ao lado do limiar significa o modo de visualização da explicação da análise. No modo de Visualização Compacto, a resposta será uma sugestão para cada apontador da métrica OEE e, no modo de Visualização Estendido, a resposta será gerada considerando cada lote produzido e parada registrada separadamente. O usuário tem a possibilidade de escolher entre análise pelo JESS ou SOEE e visualizar a explicação das ativações das regras e fatos correspondentes através do botão Ver Explicação. A função usada para explicação é (watch <all rules facts activations>), padrão do JESS. A tela de explicação contém uma árvore de decisões, ou seja, é a árvore de disparos de regras, inserção de fatos na base de conhecimento e modificações na memória de trabalho. A árvore é organizada nos níveis fatos iniciais e disparos, e para cada um desses níveis são mostrados os eventos correspondentes na ordem em que

61 58 eles aconteceram. Pelo botão Editar Regras, localizado na parte direita da tela, o usuário administrador terá a possibilidade de editar o arquivo contendo as regras diretamente do sistema, sem necessidade de recompilar o código-fonte, apenas fazendo uma nova consulta. Figura 13 - Tela de interface do módulo de apoio à decisão Fonte: Autor do trabalho. Como padrão de todas as telas do consulta do sistema, há campos de filtros por máquina e período, obrigatórios para realização da consulta. O item mostra as regras que foram usadas pelas duas formas de análise dos dados, JESS e SOEE, e uma explicação sobre elas.

62 Definição das regras As regras inseridas na base de conhecimento do JESS para se fazer o teste são as mesmas inseridas na base do conhecimento do Sistema Especialista implementado no SOEE, porém, com algumas formas de mostrá-las ao usuário diferentes. Para a construção das regras e templates dos JESS, o esquema conceitual foi o mostrado na Figura 7, Figura 8 e Figura 9. A definição dos templates do JESS usa a modelagem com base nas seis perdas dos equipamentos. Esse protótipo da definição de alguns templates pode ser demonstrado no Quadro 4: Quadro 4 Definição de Templates em JESS (deftemplate dados-producao (slot id (type INTEGER)) (slot datahora-producao (type STRING)) (slot boa (type INTEGER)) (slot refugo (type INTEGER)) (slot retrabalho (type INTEGER)) (slot causa-refugo) (slot causa-retrabalho) (slot causa-envase) (slot turnoid (type INTEGER)) (slot maquinaid (type INTEGER))) (deftemplate lote-conforme (slot id-lote)) (deftemplate excesso-material (slot id-lote)) (deftemplate medidas-abaixo (slot id-lote)) (deftemplate rugosidade (slot id-lote)) (deftemplate dados-disponibilidade (slot paradasplanejadas (type INTEGER)) (slot paradasnaoplanejadas (type INTEGER)) (slot disponivel (type INTEGER)) (slot producao (type INTEGER)) (slot total (type INTEGER))) (deftemplate dados-parada (slot id (type INTEGER)) (slot motivoid (type INTEGER)) (slot maquinanm (type STRING)) (slot maquinaid (type INTEGER)) (slot datahora-inicial) (slot datahora-final) (slot turnoid (type INTEGER))) (deftemplate dados-motivo-parada (slot id (type INTEGER)) (slot descricao (type STRING)) (slot tipo (type STRING)) (slot duracao) (deftemplate dados-performance (slot maquinaid (type INTEGER)) (slot maquinanm (type STRING)) (slot produtividade-standard (type FLOAT)) (slot tempo-disponivel (type FLOAT)) (slot total-produzido (type FLOAT))) Fonte: Autor do trabalho.

63 60 Esses templates criam os moldes para as regras e fatos que o JESS reconhece (Apêndice A). Foram criados treze modelos conforme a definição da regra de negócio exemplificada na Figura 7, Figura 8 e Figura 9 e para controle de variáveis globais. Para controle de execução das regras foram usadas variáveis dentro do JESS conforme mostrado no Quadro 5. Quadro 5 Definição de variáveis de controle no JESS (set-reset-globals FALSE) (defglobal?*totalboas* = 0) (defglobal?*totalrefugo* = 0) (defglobal?*totalretrab* = 0) (defglobal?*totalqualidade* = 0) (defglobal?*disparadasqualidade* = 0) (defglobal?*totaldisp* = 0) (defglobal?*disparadasdisp* = 0) (defglobal?*limiar* = (call (fetch LIMIAR) tostring)) (defglobal?*collapsed* = (call (fetch COLLAPSED) tostring)) (defglobal?*disp_disponivel* = (call (fetch DISP) tostring)) (defglobal?*ht* = (new java.util.hashmap)) (defglobal?*totalmotivo* = 0) (defglobal?*disparadasmotivo* = 0) (defglobal?*maior_disp* = 0) (defglobal?*descricao_motivo_maior* = "") (defglobal?*ht_qual* = (new java.util.hashmap)) (defglobal?*maior_qual* = 0) /* quantas vezes a sugestão que mais ocorreu */ (defglobal?*disparadas_qual_maior* = 0 (defglobal?*descricao_qual_maior* = "") (defglobal?*total_qual_maior* = 0) (deffunction reseta() (bind?*totalboas* 0) (bind?*totalrefugo* 0) (bind?*totalretrab* 0) (bind?*totalqualidade* 0) (bind?*disparadasqualidade* 0) (bind?*totaldisp* 0) (bind?*disparadasdisp* 0) (reset)) (defrule incrementa-qualidade (declare (salience 10010)) (dados-producao (boa?good) (refugo?ref) (retrabalho?retrab)) => (bind?*totalboas* (+?*totalboas*?good ) ) (bind?*totalrefugo* (+?*totalrefugo*?ref ) ) (bind?*totalretrab* (+?*totalretrab*?retrab) ) (bind?*totalqualidade* (+?*totalqualidade* 1 ))) (defrule incrementa-disponibilidade (declare (salience 10000))?parada <- (dados-parada) => (bind?*totaldisp* (+?*totaldisp* 1 ) )) Fonte: Autor do trabalho. O Quadro 5 mostra a declaração de variáveis globais com o comando defglobal, criação de algumas funções para incrementar essas variáveis e definição regras para fazer o controle da quantidade de regras de qualidade e disponibilidade disparadas

64 61 (Apêndice A). O Quadro 6 mostra algumas regras formuladas pelo autor, conforme entrevista com especialista e coleta de informações. Quadro 6 Regras de disponibilidade em JESS (defrule falta-energia (dados-motivo-parada {tipo == "Nao Programada" && descricao == "Falta de energia"} (id?id-motivo) (descricao?descricao))?parada <- (dados-parada (motivoid?id-parada &:(eq?id-motivo?id-parada)) ) => (if (=?*collapsed* 0) then (printout t "parada: "?parada.datahora-inicial " ate "?parada.datahorafinal " -> Verificar fornecimento de energia." crlf) (if (eq (call?*ht* get?descricao) nil) then (call?*ht* put?descricao 1) (assert (lista-disp (descricao-motivo?descricao))) (call?*ht* put?descricao (+ (call?*ht* get?descricao) 1)) ) ) (bind?*disparadasdisp* (+?*disparadasdisp* 1)) ) (defrule perda-velocidade-arranque (dados-motivo-parada {tipo == "Nao Programada" && descricao == "perda de velocidade de arranque"} (id?id-motivo) (descricao?descricao))?parada <- (dados-parada (motivoid?id-parada &:(eq?id-motivo?id-parada)) ) => (if (=?*collapsed* 0) then (printout t "parada: "?parada.datahora-inicial " ate "?parada.datahorafinal " -> Configurar start-up de maquina." crlf) (if (eq (call?*ht* get?descricao) nil) then (call?*ht* put?descricao 1) (assert (lista-disp (descricao-motivo?descricao))) (call?*ht* put?descricao (+ (call?*ht* get?descricao) 1)) ) ) (bind?*disparadasdisp* (+?*disparadasdisp* 1)) ) Fonte: Autor do trabalho. As regras do Quadro 6 possuem restrições pelo tipo de parada não-programada e pela descrição do motivo da parada. Caso o usuário não selecione a opção Visualização Compacta, as regras sugerem uma solução por parada ao usuário, na proporção 1:1. Para a formulação de regras com a Visualização Compacta foi necessária a elaboração de heurística. A necessidade do uso de heurística provém de qual sugestão mostrar ao usuário que melhor represente a situação no momento, ou seja, qual a

65 62 sugestão que tem a maior chance de aumentar os índices OEE quando o usuário colocá-las em prática. A heurística utilizada parte do princípio de prioridade e esta é dada ao problema que mais se repetiu durante o período pesquisado. Então tem-se uma separação dos problemas e o que mais persistiu é o que será mostrado ao usuário juntamente com a sugestão correspondente. No caso do apontador de qualidade, a causa de refugo e retrabalho que mais aparecerem serão as escolhidas. Já para a disponibilidade, o motivo de parada que mais foi observado será o selecionado para aparecer no relatório. Algumas regras geram outros fatos através da operação assert do JESS. Essa inserção de fatos, por sua vez, modifica a memória de trabalho da ferramenta, podendo disparar novas regras (Apêndice B). O item 4.3 aborda o desafio computacional da solução proposta do trabalho e como foi feita a entrevista do engenheiro de conhecimento com o especialista para aquisição de conhecimento e definição das regras e modelos. 4.3 DESAFIO COMPUTACIONAL: O GARGALO Nesse item é abordado o tratamento do gargalo de eficiência dos Sistemas Especialistas: a aquisição do conhecimento A extração do conhecimento do especialista A técnica utilizada para fazer a aquisição de conhecimento foi a manual e baseada em entrevistas. A aquisição do conhecimento se deu com base no domínio do estudo de caso realizado pela Profa. Izabel Zattar da empresa Laticínios Carolina. As entrevistas que foram feitas entre o engenheiro de conhecimento e o especialista para se formular as regras, utilizaram perguntas pertinentes ao domínio e utilizando anotações como forma de documentação. As perguntas foram com base nos três indicadores da métrica OEE. As respostas obtidas através das entrevista foram anotadas em documentos

66 63 como papéis e documento eletrônico, nas formas escritas e principamente diagramas, para ajudar a melhorar o entendimento do engenheiro do conhecimento na formulação das regras de produção. 4.4 CONCLUSÕES DO CAPÍTULO Nesse capítulo foram apresentadas as características do módulo de apoio à decisão implementado para o SOEE. O item 4.1 abordou a interação entre os componentes do sistema desenvolvidos e os principais problemas observados de diferentes pontos de vista. Foram mostrados diagramas que facilitam a visualização das funcionalidades do sistema e a forma de interação do sistema com o usuário final, o engenheiro de conhecimento e o especialista. O diagrama de classes mostra a relação entre as classes e a arquitetura em três camadas. Os diagramas de sequência e atividades fazem uma abordagem dessa interação de uma forma sequencial no tempo, das operações externa e internas, respectivamente. O diagrama de caso de uso mostra as funcionalidades do sistema de uma maneira mais formal, independente do tempo. As regras de produção propostas foram baseadas nas seis grandes perdas dos equipamentos. Mostrou-se a implementação no JESS, com a definição de regras e fatos, que utilizam as templates para modelar o tipo dos dados. Por fim, mostrou-se a forma de interação do engenheiro de conhecimento com o especialista a fim de diminuir o gargalo da aquisição de conhecimento. Essa interação foi feita manualmente e através de entrevistas. O capítulo 5 apresenta os resultados dos testes feitos com as análises do SOEE e JESS, utilizando uma planilha de dados de entrada.

67 64 5 RESULTADO DO MÓDULO DE APOIO À DECISÃO Este capítulo mostra o teste feito com o sistema SOEE através de uma base de dados disponibilizada pelo especialista. O item 5.1 descreve os dados da base de dados que foi utilizada para o teste e o item 5.2 mostra os resultados. 5.1 A BASE DE DADOS A base de dados utilizada foi disponibilizada pela especialista no domínio do OEE, a Prof. Izabel Zattar, com base no estudo de caso na empresa Laticínios Carolina. Tal base também serviu para teste durante período de bolsa de iniciação científica. A base possui aproximadamente 150 registros de paradas não-programadas, 30 registros de motivos de parada e 170 registros de produção de lotes em um período de um mês. A máquina utilizada na base é uma máquina de envase de recipientes com tampador, com uma produtividade de 220 frascos de 900ml por minuto. A planilha usada como teste recebeu algumas modificações, mas sem refletir consequências na análise. As modificações são no ano de produção dos lotes, passado de 2011 para 2012 e a quantidade de peças retrabalho e refugo, que estavam com valores nulos, foram gerados valores fictícios para que houvesse a sugestão do indicador de Qualidade. As datas iniciais e finais selecionadas na busca compreendem 30 dias, de 01/06/2012 a 30/06/2012, período que os registros de paradas e produções foram feitos. Os scripts de inserção dos dados dessa base incluem o cadastro de registros nas tabelas Parada, Motivoparada e Pecaproduzida (Apêndice A). O SGBD (Sistema de Gerenciamento de Banco de Dados) utilizado nos testes foi o PostgreSQL na versão RESULTADOS OBTIDOS Após o clique nos dois botões Iniciar Análise SOEE e Iniciar Análise JESS, o

68 65 sistema realiza primeiramente a busca à base e posteriormente transporta os resultados para a função de análise correspondente para serem manipulados. Com a utilização do timer da linguagem Java é possivel ver quanto tempo demandou a busca pelas informações da base de dados e o processamento das informações. O tempo de processamento das regras e templates por parte do SOEE e JESS se mostraram eficientes, chegando a ordem de um décimo de segundo. A Figura 14 mostra que o resultado da análise do JESS foi executada em aproximadamente 0,1 segundo em uma máquina com processador Intel (R) Core (TM) 2 Duo, modelo E7200, arquitetura de 32 bits e com frequência de 2,53 GHz e memória RAM total de 4,00 GB com arquitetura DDR2, sendo que apenas 3,25 GB são reconhecidos pelo sistema operacional Windows 7. Figura 14 - Resultado do teste da análise JESS Fonte: Autor do trabalho. A Figura 14 mostra o resultado da análise feita no período especificado e com Visualização Compacta das sugestões. Para a análise do SOEE o indicador de qualidade é mostrado fazendo-se uma distinção entre as peças boas, retrabalho e refugo, e o problema de qualidade que mais ocorreu e a quantidade de ocorrências. Como o modo de Visualização Compacto está ativado, a análise retorna somente uma sugestão para cada métrica OEE. Para o índice de performance, a sugestão dada pelo sistema foi realizar manutenção na máquina buscada pelo usuário, em seguida o

69 66 total de paradas encontradas no período e o índice de disponibilidade. A sugestão para a disponibilidade no modo de Visualização Compacto é dada utilizando-se a heurística do motivo de para que mais ocorreu. Portanto, é apresentado o motivo, o número de ocorrências e a sugestão para aquele motivo de parada, que é a mesma sugestão para o modo de Visualização Estendido correspondente. Na sequência, o total de peças boas, peças refugo e retrabalho, o índice de qualidade, a causa de refugo e retrabalho que mais ocorreram e por fim a sugestão. A Figura 15 mostra os resultados obtidos da análise com SOEE utilizando a Visualização Compacta. Figura 15 - Resultado do teste da análise SOEE-JRA Fonte: Autor do trabalho. Na análise SOEE-JRA mostrada na Figura 15 pode-se observar que a forma de exibição do resultado é distinta a análise JESS. Na saída é mostrado o total de lotes produzidos, a quantidade de peças boas, refugo e retrabalho, seguido de sugestões de qualidade. O formato da saída do apontador de qualidade para modo de Visualização

70 67 Compacto é da mesma forma que na análise JESS, utilizando a heurística do problema que mais ocorreu. Portanto, é mostrada a descrição do problema, seguido do número de vezes que se repetiu e a sugestão correspondente. Em seguida é mostrado o resultado da análise para o apontador de disponibilidade. Caso a opção Visualização Compacta esteja selecionada, será gerada uma única sugestão para esse apontador e, pelo contrário, a resposta será uma sugestão para cada parada encontrada no período buscado. Como a opção de Visualização Compacta foi selecionada, o resultado é o motivo de parada que mais se repetiu, a quantidade de ocorrências e a sugestão. No apontador de performance é mostrada a porcentagem obtida através do cálculo da métrica OEE, e, caso esse valor fique abaixo do limiar definido na busca, é mostrada a sugestão. Por fim, o tempo de consulta das informações ao banco e o tempo de processamento são exibidos. Na análise JESS, ao final de cada linha de qualidade é mostrada a porcentagem de peças boas produzidas seguido da sugestão para este lote, caso o checkbox Visualização Compacta não estiver selecionado. Se estiver selecionado, será mostrada uma única sugestão para o apontador de qualidade. Da mesma forma que a qualidade, o apontador de disponibilidade somente mostrará uma sugestão caso o checkbox esteja selecionado. Caso o usuário queria fazer uma análise mais detalhada do período, basta selecionar essa opção. Através dela é possível ver como seria a sugestão para cada parada registrada. Por fim, o resultado do apontador de performance é mostrado, seguido do tempo de consulta e processamento. A análise JESS gera um arquivo log de todas as modificações feitas na memória de trabalho, e é através dela que a resposta é gerada na tela do módulo do sistema SOEE e também para a tela de explicação. A saída em arquivo em JESS é feita utilizando-se a função addoutputrouter("t", new FileWriter("out_analysis_Jess. txt")), onde o primeiro parâmetro é o modo de saída e o segundo o nome do arquivo a ser gerado e, logo após, rete. setwatcrouter("t") torna padrão esse modo de saída. A Figura 16 mostra a tela de explicação com a árvore de disparos executados em ordem para a análise JESS. O objetivo da criação dessa tela e apresentação em

71 68 formato de árvore é a melhor visualização dos disparos de regras para facilitar a leitura do usuário. Figura 16 - Tela de explicação da análise JESS Fonte: Autor do trabalho. Conforme a Figura 16, cada nó da árvore de explicação selecionado mostrará no campo de texto na parte direita da tela um detalhamento. Nesse exemplo a regra faltatampa-rule foi disparada pelos fatos f-469 e f-92 e gerou um novo fato f-470. Para a análise SOEE-JRA, essa tela permanece praticamente igual, apenas distinguindo-se na forma de exibir os dados em cada nó da árvore e no detalhamento. Pode-se perceber que os valores das porcentagens dos indicadores das duas análises foram praticamente iguais, sendo diferenciados apenas nas casas decimais mais distantes. De um modo geral, a execução das regras não se tornou um gargalo de tempo no sistema, sendo que a operação que mais demonstrou demora foi a de busca ao banco de dados. Estabeleceu-se um conjunto de métricas quantitativas para obtenção de uma comparação das análises implementadas. O intuito desta comparação quantitativa é analisar qual implementação destaca-se em termos de desempenho em um âmbito empresarial, muitas vezes com recursos de hardware de máquina limitados. O teste quantitativo realizado usa como comparativo um conjunto de métricas de