Projeto Jidoka: Desenvolvimento de uma Aplicao para Controle de Parada de Mquina

Rafael Brito dos Santos1 1Escola Superior de Tecnologia Universidade do Estado do Amazonas (EST-UEA)

CEP 69.065-020 Manaus AM Brasil britorafael@gmail.com.br

Abstract. This meta-paper describes the Jidoka Project development, which aims to realize the Stop Machine Control alerting their responsible about each occurrence. Here also described the technologies and tools used to develop the Project and also methodology applied (FDD Feature Driven Development) along with each of its processes applied. Resumo. Este meta-artigo descreve o desenvolvimento do Projeto Jidoka, que tem como propsito realizar o Controle de Paradas de Mquinas de uma Indstria alertando seus responsveis sobre cada ocorrncia. Aqui tambm ser descrito as tecnologias e ferramentas utilizadas para o desenvolvimento do Projeto e ainda a metodologia de desenvolvimento aplicada (FDD Feature Driven Development) juntamente com cada um de seus processos aplicados.

1. Introduo Durante o processo produtivo composto por mquina sempre existem as chamadas paradas de mquinas seja por motivo de manuteno, seja para troca de algum molde, por exemplo, ou at mesmo por razo de algum problema que possa ocorrer durante a execuo da mquina gerando uma parada de linha e por conseguinte parada na produo. Contudo nem sempre a soluo destes empecilhos se d de forma eficiente, principalmente no que diz respeito comunicao entre as reas envolvidas e ou responsveis, bem como departamentos de Engenharia, Manuteno Tcnica entre outros, levando a um tempo de parada maior do que o que poderia ocorrer e em algumas situaes levando a um no cumprimento no que tange a entrega de uma quantidade de peas baseado em um determinado pedido de um cliente podendo chegar at a situao de o fornecedor ter de arcar com as despesas do cliente e/ou pagamento de multa. Pensando nisso algumas empresas passaram a adotar o conceito do Jidoka em seus processos produtivos.

1.1. Jidoka O Jidoka teve sua origem ligada automao da mquina de tear fabricada por Sakichi Toyoda (1867-1930), fundador da Toyota Automatic Loom Works, considerado um dos dez maiores inventores da histria contempornea do Japo e inventor da mquina de tear automtica.

O problema do tear automtico era de que; - A mquina continuava funcionando mesmo diante de um fio rompido e; - O defeito s era detectado quando o processo estivesse concludo, tendo produzido muito tecido defeituoso. Em tal situao, se um fio rompesse, a mquina produziria tecido com defeito! E para evitar produzir defeito, havia a necessidade de ter um operador tomando conta da mquina como se fosse um vigia e, diante de qualquer anomalia, deveria parar a mquina. A soluo que Sakichi inventou e colocou em prtica em 1924 foi uma mquina de tear dotada de dispositivo que parava a mquina quando: - detectava o rompimento da linha; - detectava o fim da linha; - detectava a quantidade programada atingida. Utilizando-se desses recursos, Sakichi pde liberar o operador de ficar como vigia tomando conta das mquina espera de ocorrncia de anomalia. Eis o que Jidoka! Dotar a mquina com dispositivos ou recursos que ao detectar qualquer anomalia faz a mquina parar evitando desta maneira produzir a no qualidade como descrito acima. Mas isto s uma parte. o Jidoka que envolve mquina automtica. Nem todas as atividades so realizadas pelas mquinas, como por exemplo, as atividades de uma linha de montagem, que tem uma intensa participao de atividades manuais. Nets caso como funciona o Jidoka? o operador quem pra a atividade quando descobre qualquer anormalidade. Na Toyota, operador tem obrigao e o direito de parar a operao quando ele descobrir alguma anomalia e a mesma no for solucionada dentro do tempo takt (tempo disponvel para a produo dividido pela demanda do mercado, se uma fbrica trabalha 9 horas/dia, equivalente a 540 minutos, e a demanda do mercado de 180 unidades/dia, o takt de 3 minutos). Isto faz parte do comprometimento de no passar para operao ou processo seguinte pea ou trabalho com anomalia e isto constitui em uma das regras fundamentais do TPS (Toyota Production System) a qualidade construda dentro do processo. A parada seguida de um alerta ou sinalizao emitida pelo operador atravs do acionamento de cordes (ou botes) dispostos ao longo da linha de montagem ao alcance dos operadores. At aqui foi visto que o Jidoka pode ser tanto aplicado em mquina, como foi a sua origem, assim como para atividades que envolvam somente intervenes humanas. O objetivo, em ambas as situaes detectar qualquer defeito ou anomalia e fazer parar a operao ou processo para evitar a produo da no qualidade.

1.2. Objetivo Desenvolver uma aplicao utilizando a linguagem de programao Visual Basic .NET juntamente com um Banco de Dados SQL Server 2008 para fazer o controle de paradas

de mquina em funo do disparar de tal ocorrncia por parte de um operador em uma estao de trabalho (PC) gerando um escalonamento de paradas por solucionar e ativando o envio de mensagens via E-mail e SMS (atravs de Web Service) para os respectivos responsveis.

1.2.1. Especficos Dentre este esto:

- Adquirir conhecimento e desenvolver a habilidade de trabalhar com Web Services na plataforma .NET; - Enviar os SMSs atravs de Web Service; - Propor a utilizao da aplicao desenvolvida na empresa em que trabalho; - Concluir a graduao em Engenharia de Computao.

1.3. Justificativa No meio corporativo muito se fala em produtividade e qualidade, o desenvolvimento da aplicao proposta trs implicitamente a tratativa destas duas questes uma vez que se prope a controlar as paradas de mquinas em prol de se poder identificar os motivos que levaram a parada de tal mquina e a possvel reincidncia do problema levando os responsveis atravs da repetio do problema a conseguirem resolv-los cada vez mais rpido ou ainda a buscarem solues definitivas, evitando defeitos em peas, aumentando assim a produtividade e a qualidade. Atravs do envio de mensagens instantneas, sobretudo SMS a comunicao do pessoal da produo com a equipe tcnica se dar em tempo real, agilizando assim o processo de soluo da parada e retomada de produo da mquina em questo. Uma vez que a equipe gerencial de uma empresa tenha em mos uma soluo como esta proposta, ter uma relevante ferramenta para tomada de deciso, podendo assim definir prioridades de manuteno preventiva de mquina, troca de maquinrio por outro mais novo ou te tecnologia mais avanada e etc.

1.4. Metodologia Para realizao do projeto em questo sero feitas pesquisas atravs de livros tcnicos e em contedos disponveis na Internet, como fruns para retirada de dvidas, apostilas, artigos. Especificamente na parte prtica, desenvolvimento do aplicativo, tambm ser necessrio a consulta em livros tcnicos e material da Internet, assim como a utilizao de um servio (Web Service) prestado por uma empresa privada para que seja feito o envio de SMS para os devidos destinatrios. Sero necessrias tambm para desenvolvimento da aplicao algumas ferramentas de desenvolvimento, bem como Visual Studio e SQL Server, no caso em questo ambos na verso 2008.

1.5. Descrio das prximas sees: Abaixo so mostradas as sees posteriores:

Teoria do Problema Desenvolvimento Concluso Referncias

2. Teoria do Problema O Projeto Jidoka surgiu a partir da necessidade de se registrar e controlar melhor as Paradas de Mquina dentro de uma empresa industrial. O conceito de Jidoka pode-se resumir na palavra Autonomao que significa um controle que eu chamaria de semi-automtico uma vez que no necessariamente o controle realizado totalmente automatizado, pois o mesmo durante o mesmo pode exigir a interveno humana. A aplicao desenvolvida tem como propsito realizar um controle das paradas de mquina ocorridas durante o processo de produo de uma indstria onde atravs da interveno de um usurio (colaborador) o mesmo cadastrar cada parada ocorrida com suas devidas informaes pertinentes, acionando, automaticamente, as pessoas responsveis por solucion-la. Por fim permitindo um gerenciamento das paradas atravs de relatrio, permitindo tomada de decises mais rpidas como aes preventivas atacando problemas recorrentes por exemplo. Para o desenvolvimento da aplicao foi determinado como metodologia gil a ser aplicada a FDD - Feature Driven Development (Desenvolvimento Guiado por Funcionalidades). E como ferramentas para anlise e desenvolvimento tm-se: - Erwin 3.5; - Visual Studio 2008; - SQL Server 2008; Como linguagem de programao, a utilizada foi o Visual Basic .NET.

2.2. Erwin O Erwin Data Modeler, normalmente referido apenas por Erwin uma ferramenta de software utilizada para a modelao de sistemas de informao. Pertence ao conjunto de programas de apoio ao desenvolvimento de software normalmente designados por Ferramentas CASE. Atravs desta ferramenta, o desenvolvedor de um sistema de informao pode especificar os dados envolvidos, as suas relaes e os requisitos de anlise. A ferramenta permite depois a criao da bases de dados e dos mecanismos de sincronizao de dados necessrios, bem como o processo inverso ([Engenharia reversa]).

2.3. Visual Studio 2008 O Microsoft Visual Studio um pacote de programas da Microsoft, para desenvolvimento de software, especialmente dedicado, ao Framework .NET e s

linguagens Visual Basic (VB), C , C++, C# (C Sharp) e J# (J Sharp). Tambm um grande produto de desenvolvimento na rea web, usando a plataforma do ASP.NET. As linguagens com maior freqncia nessa plataforma so: VB.NET (Visual Basic .NET) e o C# (l-se C Sharp). Foi lanada em Fevereiro de 2007, junto com as verses finais dos softwares Windows Server 2008 e o SQL Server 2008. O Microsoft Visual Studio 2008 cumpre a viso da Microsoft de aplicativos clientes permitindo que os desenvolvedores criem com muita rapidez aplicativos que so passveis de proporcionar experincias de usurio com a mais alta qualidade e riqueza. O Visual Studio 2008, junta ferramentas com as quais as organizaes sentiro maior facilidade em capturar e analisar informaes, o que significa a melhor tomada de decises de negcios. O Visual Studio 2008 possibilita que organizaes de todos os tamanhos criem aplicativos mais seguros, gerenciveis e confiveis que tiram proveito do Windows e do Office. O Visual Studio 2008 se baseia em trs pilares para proporcionar melhor experincia para os programadores: Melhorias na produtividade do desenvolvedor; Gerenciamento do ciclo de vida do aplicativo; e Utilizao das mais recentes tecnologias.

2.4. SQL Server 2008 O Microsoft SQL Server um SGBD - Sistema Gerenciador de Banco de Dados relacional criado pela Microsoft. Com a nova verso o Microsoft SQL Server 2008 fornecida uma plataforma de dados confivel, produtiva e inteligente que permite que voc execute suas aplicaes de misso crtica mais exigentes, reduza o tempo e o custo com o desenvolvimento e o gerenciamento de aplicaes e entregue percepo que se traduz em aes estratgicas em toda sua organizao.O SQL um Banco de dados robusto e usado por sistemas corporativos dos mais diversos portes. Para obter as vantagens das novas oportunidades no dinmico mundo corporativo, as empresas precisam de capacidades para rapidamente criar e implantar solues baseadas em dados. O SQL Server 2008 reduz o tempo e o custo de gerenciamento e de desenvolvimento de aplicaes.

2.5. Visual Basic .NET O Visual Basic.NET uma linguagem de programao totalmente orientada a objetos e com suporte total a UML, criada pela Microsoft e distribuda com o Visual Studio .NET Com ela possvel criar programas modernos orientados a objetos. O Visual Basic .NET um produto extremamente diferente do antigo Visual Basic 6.0, no podendo ser considerada uma verso seguinte. No apenas a maneira de programar foi alterada, mas todo conceito de orientao a objetos trouxe poder para a linguagem. Os desenvolvedores podem criar uma ampla gama de aplicativos Web, mveis, do Windows e do Office.

3. Desenvolvimento A seguir ser descrito a metodologia aplicada para desenvolvimento deste projeto bem como cada uma de suas fases (Processos).

3.1. FDD uma das seis metodologias geis originais, cujos representantes redigiram o Manifesto gil para Desenvolvimento de Software, em 2001. Nessa ocasio, o representante da FDD foi Jon Kern, que trabalhava na TogetherSoft, substituindo Peter Coad. A FDD nasceu num projeto em Cingapura, entre 1997 e 1999, a partir do Mtodo Coad (uma metodologia completa para Anlise, Desenho e Programao Orientados por Objetos, desenvolvida por Peter Coad nas dcadas de 1980 e 1990) e das tcnicas de gerenciamento iterativo, incremental e enxuto de projetos utilizadas por Jeff De Luca, um gerente de projetos australiano. Seu lema "Resultados freqentes, tangveis e funcionais". A primeira descrio oficial dos processos foi publicada no livro "Java Modeling in Color with UML", por Peter Coad, Eric Lefebvre e Jeff De Luca, em 1999. O livro de referncia "A Practical Guide to Feature-Driven Development", por Stephen Palmer e John Mac Felsing, publicado em 2002 pela Prentice-Hall, compondo uma srie editada pelo prprio Peter Coad.

3.1.1. Os Processos A metodologia FDD , classicamente, descrita por cinco processos: - Desenvolver um Modelo Abrangente: pode envolver desenvolvimento de requisitos, anlise orientada por objetos, modelagem lgica de dados e outras tcnicas para entendimento do domnio de negcio em questo. O resultado um modelo de objetos (e/ou de dados) de alto nvel, que guiar a equipe durante os ciclos de construo. - Construir uma Lista de Funcionalidades: decomposio funcional do modelo do domnio, em trs camadas tpicas: reas de negcio, atividades de negcio e passos automatizados da atividade (funcionalidades). O resultado uma hierarquia de funcionalidades que representa o produto a ser construdo (tambm chamado de product backlog, ou lista de espera do produto). - Planejar por Funcionalidade: abrange a estimativa de complexidade e dependncia das funcionalidades, tambm levando em considerao a prioridade e valor para o negcio/cliente. O resultado um plano de desenvolvimento, com os pacotes de trabalho na seqncia apropriada para a construo. - Detalhar por Funcionalidade: j dentro de uma iterao de construo, a equipe detalha os requisitos e outros artefatos para a codificao de cada funcionalidade, incluindo os testes. O projeto para as funcionalidades inspecionado. O resultado o modelo de domnio mais detalhado e os esqueletos de cdigo prontos para serem preenchidos. - Construir por Funcionalidade: cada esqueleto de cdigo preenchido, testado e inspecionado. O resultado um incremento do produto integrado ao repositrio principal de cdigo, com qualidade e potencial para ser usado pelo cliente/usurio.

3.2. Desenvolver um Modelo Abrangente

Para se chegar a um modelo que atendesse o problema de parada de mquina, foi preciso primeiramente identificar que tipo de informaes seriam necessrias para se realizar o controle das paradas. Quais dados deveriam ser imputados no sistema atravs do usurio (colaborador) e como essa ao chegaria aos responsveis por solucionar o problema cadastrado. Assim analisando informaes bsicas em um processo industrial chegou-se s seguinte necessidades: - Salvar o Usurio cadastrador da parada, de tal forma que ento se faz necessrio um Controle de Usurio; - Informar o Produto que est em produo na mquina parada, necessitando um Cadastro de Produto; - Informar a Linha da qual faz parte a mquina parada, necessitando um Cadastro de Linha; - Informar o Cliente referente ao produto em produo, necessitando um cadastro de Clientes; - Informar o Motivo da parada, auxiliando a equipe responsvel/gerencial a tomar medidas de preveno, principalmente na reincidncia do Motivo, necessitando assim um cadastro de Motivo; - Informar a Soluo para a parada da mquina, utilizado aps resolvido o problema e auxiliando tambm na resoluo de paradas futuras, uma vez de posse de um histrico de paradas de mesmo motivo e soluo. Assim, faz-se necessrio um cadastro de Soluo; - Por fim dentre as necessidades fundamentais tm-se a forma como os responsveis devem ser notificados das paradas de mquina. Assim pensando na agilidade que se espera diante de uma linha de produo optou-se pela notificao de duas formas: a) E-mail; b) SMS. Buscando garantir que as paradas sejam solucionadas no menor tempo possvel, e que os devidos responsveis sejam notificados e cobrados, um E-mail ser enviado a cada 30 minutos subindo os nveis hierrquicos dos destinatrios, comeando por Supervisor e seguindo para Coordenador, Gerente e por fim Diretor. Como alguns responsveis podem no ter e-mail ou ainda no estar no momento do alerta de parada em suas devidas estaes de trabalho para acesso ao e-mail, ser utilizado como meio de aviso o SMS para o primeiro nvel hierrquico. Para se realizar este controle de aviso de Mensagens (E-mail / SMS) faz-se necessrio existir, um cadastro de Destinatrio onde ser determinado o possvel E-mail e/ou Celular do mesmo, bem como seu nvel hierrquico, tambm ser necessrio um cadastro de Grupo de Distribuio que ser informado no momento do registro de Parada de Mquina determinando assim as pessoas que sero envolvidas na soluo da parada de mquina.

A partir dos requisitos observados foi possvel montar o Diagrama de Classe abaixo:

Figura 1. Diagrama de Classe do Projeto Jidoka

3.3. Construir uma Lista de Funcionalidades De posse dos requisitos mountou-se um Diagrama de Caso de Uso, conforme exibido abaixo:

Usurio

Logar

*

*

Cadastrar Paradade Mquina

Enviar SMS

Enviar Mensagem

Visualizar Paradasde MquinaCadastradas

Cadastrar Grupo deDistribuio

Atualizar Statusda Parada

de MquinaEnviar E-mail

*

*

*

*

*

*

*

*

uses

uses

extends

extends

Cadastrar Usurio

*

*

Definir Permissode Acesso

*

*

Cadastrar Opo

*

*

Cadastrar Linha

Cadastrar Motivode Parada

*

*

*

*

Redefinir Senha

*

*

Alterar Usurioextends

CadastrarDestinatrio

*

*

Associar Destinatrio

XGrupo de Distribuio

*

*

CadastrarSoluo

*

*

Cadastrar Cliente

CadastrarProduto

Associar Produto X Cliente

*

*

**

*

*

Figura 2. Diagrama de Caso de Uso do Projeto Jidoka

3.3.1. Cadastrar Usurio Usurio com privilgio de Administrador poder cadastrar novos usurios.

3.3.2. Redefinir Senha Usurio poder alterar sua prpria senha.

3.3.3. Cadastrar Opo Usurio com privilgio de Administrador poder cadastrar novas opes (formulrios).

3.3.4. Definir Permisso de Acesso Usurio com privilegio de Administrador definir a permisso de acesso de usurios cadastrados bem como, Inserir, Editar, Excluir e/ou Visualizar.

3.3.5. Logar Usurio pr-cadastrado realizar login no sistema.

3.3.6. Alterar Usurio Poder ser trocado de usurio sem a necessidade de realizar Log Off no Sistema Operacional.

3.3.7. Cadastrar Linha Usurio com o devido acesso cadastrar as Linhas.

3.3.8. Cadastrar Motivo de Parada Usurio com o devido acesso cadastrar os Motivos de Parada.

3.3.9. Cadastrar Soluo Usurio com o devido acesso cadastrar as possveis Solues de Parada.

3.3.10. Cadastrar Grupo de Distribuio Usurio com o devido acesso cadastrar os Grupos de Distribuio de mensagem.

3.3.11. Cadastrar Destinatrio Usurio com o devido acesso cadastrar os Destinatrios que podero ser inseridos nos Grupos de Distribuio de mensagem.

3.3.12. Associar Destinatrio X Grupo de Distribuio Usurio com o devido acesso associar os Destinatrios com seus respectivos Grupos de Distribuio de mensagem.

3.3.13. Cadastrar Cliente Usurio com o devido acesso cadastrar os Clientes.

3.3.14. Cadastrar Produto Usurio com o devido acesso cadastrar os Produtos.

3.3.15. Associar Produto X Cliente Usurio com o devido acesso associar os Produtos com seus respectivos Clientes.

3.3.16. Cadastrar Parada de Mquina

Usurio com o devido acesso registrar as Paradas de Mquina ocorridas.

3.3.17. Atualizar Status da Parada de Mquina Quando uma Parada de Mquina for solucionada um usurio (com o devido acesso) informar que o problema foi resolvido.

3.3.18. Enviar SMS Quando uma Parada de Mquina for registrada o sistema enviar um SMS para alguns Destinatrios de acordo com o Grupo de Distribuio informado.

3.3.19. Enviar E-mail Quando uma Parada de Mquina for registrada o sistema enviar um E-mail para alguns Destinatrios de acordo com o Grupo de Distribuio informado.

3.3.20. Visualizar Paradas de Mquina Cadastradas Usurio com o devido acesso poder visualizar as Paradas de Mquina registradas.

3.4. Planejar por Funcionalidade Baseado no Diagrama de Caso de Uso foi possvel definir as telas e passos a serem seguidos, bem como uma lista de funcionalidades e com datas de previso de concluso de cada uma.

Tabela 1. Lista de Funcionalidades do Projeto Jidoka

3.5. Detalhar por Funcionalidade O sistema foi desenvolvido basicamente sobre duas telas padres para realizao de controle dos cadastros e a prpria para cadastros. Atravs delas a maioria das demais telas foram herdadas tendo todas as mesmas funcionalidades, facilitando para o usurio final, uma vez que o sistema padronizado e agilizando no desenvolvimento do mesmo por parte do desenvolvedor. Dentre estas telas temos a principal que tem por objetivo o registro por parte do operador de cada Parada de Mquina ocorrida na empresa.

3.5.1. Tela Padro de Controle dos Cadastros (Frame) No formulrio Frame de Cadastro realizado todas as atividades de controle dos cadastros, exemplos: Consulta, Navegao, Excluso, ou ainda ativar a Insero e/ou Alterao de registros e por fim Fechar o formulrio.

Figura 3. Tela Padro de Controle dos Cadastros (Frame)

3.5.2. Tela Padro de Cadastro (Frm) No Formulrio de Cadastro onde acionada a transao no Banco de Dados, no mesmo so disponibilizadas funcionalidades de Insero e Atualizao nas tabelas.

Figura 4. Tela Padro de Cadastros (Frm)

3.5.3. Cadastro de Parada (Frame) Esta tela pode ser considerada a principal, pois atravs dela que ser iniciado o processo de registro de problemas ocorridos na empresa no que diz respeito a Paradas de Mquinas.

Figura 5. Tela Cadastro de Parada (Frame)

3.5.4. Cadastro de Parada (Frm) Esta a tela que o operador ir manipular registrando cada Parada de Mquina, juntamente com suas informaes primordiais e complementares e ainda definir sua situao, bem como Solucionada.

Figura 6. Tela Cadastro de Parada (Frm)

3.6. Construir por Funcionalidade Neste momento foi desenvolvido cada detalhe dos requisitos, funcionalidades, codificao dos eventos de transao com o Banco de Dados, mensagens de retorno ao usurio e os envios de alerta via E-mail e/ou SMS.

3.6.1. Tela Padro de Controle dos Cadastros (Frame) Para cada tela (Frame) haver uma Grade (Grid) onde sero exibidos os registros j cadastrados e dependendo da mesma permitir realizar uma filtragem do contedo exibido atravs dos campos Campo filtro: e Pesquisar por:. Atravs do Menu existente na parte superior da tela poder se realizar a navegao entre os registro mostrados no Grid. Ao acionar o boto Novo ser aberta a tela de cadastro referente ao Frame que est aberto permitindo a incluso de novos registros. O boto Abrir utilizado para exibir os dados de um registro pr-selecionado no Grid, onde ser aberta a tela de cadastro referente ao Frame em questo permitindo assim a alterao (atualizao) dos dados contidos em tal registro. O boto excluir permite a Excluso de um registro selecionado no Grid. Boto Atualizar, como nomo se prope far uma atualizao no Grid seja por conta de umaalterao feita em um registro existente ou para atualizar a pesquisa conforme os parmetros/valores informados nos campos Campo filtro: e Pesquisar por: respectivamente. O boto Fechar, faz com que se saia da tela atual e retorne para a principal.

Figura 7. Tela Padro de Controle dos Cadastros (Frame)

3.6.2. Tela Padro de Cadastro (Frm) Como formas para se gerar novos registros nas tabelas do Banco de Dados esta tela trs algumas opes bem como: Salvar (onde o formulrio permanecer aberto), Salvar/Novo (salva os dados preenchidos e abre um formulrio em branco), Salvar/Fechar (salva os dados preenchidos e fecha o formulrio em seguida) e por fim Fechar o formulrio, sai da tela e retorna ao Frame correspondente.

Figura 8. Tela Padro de Cadastros (Frm)

3.6.3. Cadastro de Parada (Frame) Nesta tela no foi desenvolvido a opo de pesquisa, filtragem dos dados e abaixo pode-se observar a relao de registros de Parada de Mquina cadastrados, no caso em questo, 34 registros como mostrado na parte superior esquerda no menu de navegao. Na mesma so mostradas algumas informaes chaves: Produto, Cliente, Linha, Motivo da Parada, Data/Hora Cadastro, Data/Hora Limite e Responsvel. Nesta o boto Excluir desativado por padro uma vez que no se pode excluir Paradas registradas, contudo existe uma opo na tela de cadastro de Parada de Mquina (Frm) onde possvel definir a parada como Cancelado para em casos em que o operador comete um equvoco no momento do cadastro.

Figura 9. Tela Cadastro de Parada (Frame) retornando todos os registros existentes

3.6.4. Cadastro de Parada (Frm) Abaixo exibido momento do incio do cadastro de uma Parada de Mquina, onde algumas informaes j vm preenchidas por padro e outras so desabilitadas por motivo de s serem utilizadas no momento de se alterar a Situao do registro, seja para Solucionado ou Cancelado.

Figura 10. Tela Cadastro de Parada (Frm) no incio do processo de registro de Parada de Mquina

Aqui mostrado um exemplo onde o operador retorna a estao com o Sistema instalado para realizar a atualizao da Situao do registro anteriormente cadastrado, onde ele poder definir como Solucionado, Cancelado ou deixar permanecer como se encontra, ou seja, No solucionado.

Figura 11. Tela Cadastro de Parada (Frm) durante atualizao da Situao do registro de Parada de Mquina

4. Concluso Durante o decorrer do desenvolvimento do projeto assim como ao trmino do mesmo algumas observaes foram levantadas. O projeto tem como alcanar seu objetivo principal que o de possibilitar principalmente ao nvel gerencial de uma empresa coletar informaes relevantes para a tomada de deciso no que diz respeito a reduzir o tempo de parada de suas linhas de produo (Downtime) e por conseqncia aumentar sua produtividade e tambm a qualidade uma vez que ao se ganhar tempo que se desperdiaria em solucionar problemas, os mesmos so identificados com maior agilidade tomando como referncia ocorrncias anteriores semelhantes disponibilizando mais tempo para a equipe de qualidade dentro do processo produtivo e reduzindo ainda o retrabalho. Contudo para o sucesso do projeto sabido que se faz necessrio um trabalho de conscientizao, ou educao da parte dos operadores com relao atividade de registrar as ocorrncias em tempo hbil, para que as equipes responsveis possam ser acionadas para aplicar as devidas aes corretivas no menor tempo possvel.

Outro detalhe atentado est relacionado diretamente com a aplicao, ou melhor, a codificao do sistema. Enquanto se desenvolvia o processo de envio de mensagens via SMS percebeu-se que dependendo do ambiente (empresa) em que se pretenda implantar o projeto, necessrio verificar como se d a administrao da rede interna (Intranet), pois se a mesma trabalha com Proxy preciso realizar uma alterao no cdigo para tratar o mesmo no momento da chamada do Web Service para envio de SMS. Isto foi observado durante testes realizados dentro da Universidade em que se percebeu que no era preciso realizar a mesma tratativa em contrapartida em funo do trfego na rede da Universidade um outro detalhe houve de ser analisado, a lentido no retorno da solicitao no Servidor onde se encontra o Web Service, o que levava a dar erro de Time Out, contudo contornado com uma linha de comando em que torna infinito o tempo de espera por tal retorno. Por fim, ao realizar vrios testes referentes chegada da mensagem via SMS nos celulares dos responsveis constatou-se que para uma determinada operadora de telefonia celular este servio tenderia a se tornar intil em funo da extrema demora para se chegar a mensagem no celular do destinatrio o que levaria empresa caso de fato optasse por trabalho com este recurso necessitasse utilizar somente de celulares de outras operadoras para que o servio fosse garantido de maneira confivel.

5. Referncias Disponvel em: Acesso em 11 mar. 2010. Disponvel em: Acesso em 11 mar.

2010. Disponvel em:

Acesso em 11 mar. 2010.

Disponvel em: Acesso em 15 jul. 2010. Disponvel em: Acesso em 24

jul. 2010. Disponvel em: Acesso em 24

jul. 2010. Disponvel em: Acesso em 24 jul.

2010. Disponvel em: Acesso em 24 jul. 2010.

Disponvel em: Acesso em 24 jul. 2010.

Disponvel em: Acesso em 31 jul. 2010.

Disponvel em: Acesso em 31 jul. 2010.