Desenvolvimento de um sistema de monitoramento de temperatura ...

RAMON LACERDA MARQUES
Desenvolvimento de um sistema de monitoramento de
temperatura para indústria de laticínio
Belo Horizonte
2007

Universidade Federal de Minas Gerais
Escola de Engenharia
RAMON LACERDA MARQUES
Desenvolvimento de um sistema de monitoramento de
temperatura para indústria de laticínio
Monografia apresentada ao Curso de Engenharia de
Controle e Automação da Escola Engenharia da
Universidade Federal de Minas Gerais, como requisito
parcial para a obtenção do título de Bacharel em
Engenharia de Controle e Automação.
Orientador: Carlos Andrey Maia (UFMG)
Supervisor: Alex Sandro Oliveira de Almeida (Ilpisa)
Belo Horizonte
2007

Ramon Lacerda Marques
Desenvolvimento de um sistema de monitoramento de
temperatura para indústria de laticínio
Monografia apresentada ao Curso de Engenharia de Controle e Automação da Escola
Engenharia da Universidade Federal de Minas Gerais, como requisito parcial para a
obtenção do título de Bacharel em Engenharia de Controle e Automação.
BANCA EXAMINORA:
(Carlos Andrey Maia, UFMG)
(Alex Sandro Oliveira de Almeida, Ilpisa)
(Alair Dias Júnior, UFMG)
Belo Horizonte, 22 Junho de 2007

Agradecimentos
Agradeço primeiramente a Deus pela oportunidade única de realizar este trabalho.
Agradeço a meus pais, Wilson e Riulsa, pelo incentivo e motivação em todos os
momentos, e à minha esposa Ana Larissa e minha filha Ana Luísa, pelo total apoio e pela
compreensão nos momentos em que necessitei estar ausente.
Agradeço à empresa Ilpisa, por ter me dado a oportunidade de realizar este trabalho
em sua fábrica e ter cedido o funcionário Alex Sandro Oliveira de Almeida, supervisor técnico
deste trabalho, a quem também agradeço por sua disponibilidade e pronto auxílio durante o
desenvolvimento do projeto.
Gostaria de deixar também o meu agradecimento aos professores Carlos Andrey
Maia, orientador deste trabalho, e Maria Auxiliadora Muanis Persechini, pela orientação
acadêmica durante todo o projeto.

“O saber é o único patrimônio que após dividido entre
n pessoas, ainda lhe resta o todo.”
(Wilson Marques Pereira)

Resumo
O uso da automação no controle da qualidade em processos contínuos tem se
tornado uma necessidade para as indústrias dos mais diversos setores. Na indústria de
laticínios, onde a qualidade do produto final é um diferencial de mercado, não é
diferente. Cada vez mais vê-se o uso de sistemas supervisórios, PLC’s, e IHM’s para
monitorar e controlar os processos produtivos.
Este projeto de conclusão de curso tem como objetivo o desenvolvimento de um
software capaz de realizar o monitoramento da temperatura nos processos de produção
da Ilpisa, indústria de laticínios situada em Itapetinga-BA. O sistema desenvolvido
trabalha em paralelo com o supervisório já existente na fábrica, de maneira a auxiliar o
coordenador de produção a tomar decisões com relação à qualidade dos produtos. Neste
trabalho, estão presentes desde a etapa de especificação do problema e análise de
requisitos, até o desenvolvimento do sistema propriamente dito e sua implantação na
fábrica.
Palavras chave: Desenvolvimento de software, Sistema Supervisório, Sinóptico,
Laticínios, Pasteurização, Automação de laticínios, Controle de qualidade
Abstract
The usage of automation in quality control of continuous processes has become
a necessity for the industries of the most diverse sectors. In dairy industry, where the
final product quality is a market differential, it is not different. The usage of PLCs,
supervisory systems and IHMs is more common to monitor and to control the
productive processes.
This undregraduated project has as objective the development of a software
capable to carry out the monitoring of the temperature in the processes of production of
Ilpisa, a dairy industry situated in Itapetinga-BA. The developed system works in
parallel with the supervisory system already implanted, in way to assist it the
production coordinator to take decisions about the product quality. In this work, it’s
presented since the specification stage of the problem and analysis of requirements,
until the development of the system and his implantation in the plant.
Key-words: Software development, Supervisory System, Synoptic, Dairy, Dairy
industry automation, Quality control

Sumário
Lista de figuras ................................................................................................................... 8
Lista de tabelas ................................................................................................................... 9
Lista de siglas .................................................................................................................... 10
Capítulo 1 Introdução ................................................................................................. 11
1.1. Generalidades do trabalho .............................................................................. 11
1.2. Objetivos do trabalho ..................................................................................... 12
1.3. Apresentação da empresa ............................................................................... 12
1.4. Revisão bibliográfica ...................................................................................... 13
1.4.1. Sistemas de informação ......................................................................... 13
1.4.2. Sistemas de Banco de Dados ................................................................. 14
1.4.3. Trabalhos correlatos .............................................................................. 14
Capítulo 2 Descrição do processo ............................................................................... 16
2.1. Pasteurização .................................................................................................. 17
2.2. Vacina de lactose ............................................................................................ 18
Capítulo 3 Análise de requisitos ................................................................................. 20
3.1. Diagrama de casos de uso ............................................................................... 21
3.1.1. Descrição dos casos de uso .............................................................. 22
3.2. Diagrama de sequência ................................................................................... 26
3.3. Modelagem do banco de dados ...................................................................... 26
3.4. Telas do sistema ............................................................................................. 28
Capítulo 4 Desenvolvimento do sistema .................................................................... 30
4.1. Codificação do banco de dados ...................................................................... 31
4.2. Codificação do software ................................................................................. 31
4.2.1. Autenticação .................................................................................... 31
4.2.2. Configuração .................................................................................... 32
4.2.3. Gráfico de tendência ........................................................................ 32
4.2.4. Monitoramento e geração de alarmes .............................................. 34
4.2.5. Relatórios ......................................................................................... 35
Capítulo 5 Testes e implantação ................................................................................. 37
5.1. Testes .............................................................................................................. 37
6

5.2. Implantação .................................................................................................... 39
Capítulo 6 Conclusões ................................................................................................. 41
Referências bibliográficas ................................................................................................ 43
7

Lista de figuras
Figura 3.1. Diagrama de casos de uso .............................................................................................. 21
Figura 3.2. Diagrama de sequência .................................................................................................. 26
Figura 3.3. Diagrama de Entidade-Relacionamento ......................................................................... 26
Figura 3.4. Tela de login ................................................................................................................... 28
Figura 3.5. Tela de exclusão de usuário ........................................................................................... 28
Figura 3.6. Tela de criação de usuário .............................................................................................. 28
Figura 3.7. Tela de configuração do sistema .................................................................................... 28
Figura 3.8. Janela principal do sistema ............................................................................................ 29
Figura 4.1. Janela de autenticação .................................................................................................... 32
Figura 4.2. Gráfico de tendância ...................................................................................................... 33
Figura 4.3. Tabela de dados .............................................................................................................. 33
Figura 4.4. Check-box de alteração de status do processo ............................................................... 34
Figura 4.5. Tabela de alarmes ........................................................................................................... 34
Figura 4.6. Janela de reconhecimento de alarmes ............................................................................ 35
Figura 4.7. Janela de configuração de relatórios .............................................................................. 36
Figura 6.1. Janela principal .............................................................................................................. 42
8

Lista de tabelas
3.1. Caso de uso: Fazer login ....................................................................................................... 14
3.2. Caso de uso: Fazer logout ..................................................................................................... 14
3.3. Caso de uso: Criar usuário .................................................................................................... 14
3.4. Caso de uso: Excluir usuário ................................................................................................ 15
3.5. Caso de uso: Alterar senha ................................................................................................... 15
3.6. Caso de uso: Cofigurar sistema ............................................................................................ 15
3.7. Caso de uso: Iniciar monitoramento ..................................................................................... 16
3.8. Caso de uso: Parar monitoramento ....................................................................................... 16
3.9. Caso de uso: Criar produto ................................................................................................... 16
3.10. Caso de uso: Excluir produto ................................................................................................ 17
3.11. Caso de uso: Trocar produto ................................................................................................. 17
3.12. Caso de uso: Justificar alarme............................................................................................... 17
3.13. Caso de uso: Visualizar gráfico histórico ............................................................................. 17
3.14. Caso de uso: Gerar relatório de alarmes ............................................................................... 18
5.1. Exemplo de caso de teste ...................................................................................................... 38
5.1. Exemplo de caso de teste com erro ....................................................................................... 39
9

Lista de siglas
PLC Programmable Logic Controller (Controlador Lógico Programável)
IHM Interface Homem-Máquina
SGBD Sistema Gerenciador de Banco de Dados
SQL Structured Query Language (Linguagem de Consulta Estruturada)
UML Unified Modelling Language (Linguagem de Modelagem Unificada)
IDE Integrated Development Enviroment (Ambiente de Desenvolvimento Integrado)
RAD Rapid Application Development (Desenvolvimento de Aplicação Rápido)
10

Capítulo1
INTRODUÇÃO
1.1. Generalidades do trabalho
Atualmente um dos principais objetivos de qualquer processo produtivo é a obtenção de
um produto de melhor qualidade, frente a um mercado cada vez mais exigente e
competitivo. Para tanto, as empresas têm investido cada vez mais em automação e
controle em seus produtos processados; visando um aumento na produtividade e na
melhoria da qualidade. O binômio produtividade e qualidade, antes visto como
antagônico, perde todo esse sentido quando se implanta um sistema de automação, que
nos fornece recursos de monitorar, independente da quantidade, a qualidade de toda
uma produção; bem como localizar e controlar qualquer ponto crítico na linha de
produção que, certamente, iria influenciar na qualidade do produto final.
Dentro deste cenário se inclui a indústria de laticínios que, inserida num mercado
globalizado e competitivo, tem como uma necessidade o controle do seu processo
produtivo visando obter um produto de qualidade diferenciada.
Neste âmbito a automação entra com todo vigor possibilitando à empresa
vislumbrar novas possibilidades para ter um controle efetivamente maior de seus
processos críticos, que podem diretamente ou indiretamente influenciar na qualidade do
seu produto.
Contudo uma das dificuldades para as indústrias é encontrar no mercado sistemas
supervisórios que se adequem à realidade da empresa, fazendo de maneira satisfatória a
interface entre o processo e o operador do sistema de controle.
O desenvolvimento de sistemas de informação específicos possibilita a empresa
ter um software adequado às suas necessidades, flexível, possível de ser expandido e de
fácil uso pelos funcionários da empresa, visto que eles estarão intimamente envolvidos
no processo de produção do sistema.
11

1.2. Objetivos do trabalho
O objetivo principal deste trabalho consiste em elaborar um sistema (software) para
monitorar a temperatura do processo de condensação de leite na fábrica da Ilpisa /
Valedourado, situada em Itapetinga-BA.
O software desenvolvido deverá ser capaz de monitorar a temperatura do processo
a partir de dados obtidos pelo supervisório da planta, gerando alarmes quando o
comportamento da temperatura sair do perfil desejado. O sistema também possibilitara
ao operador criar relatórios de qualidade do produto ao longo da produção.
Além do gráfico da temperatura em tempo real o usuário poderá visualizar dados
históricos do comportamento da temperatura do processo.
O sistema deverá gerenciar o acesso às informações através de senhas de usuário
com níveis de privilégios específicos, de maneira a se ter um maior controle acerca da
operação do sistema e da gestão dos alarmes.
1.3. Apresentação da empresa
A Indústria de Laticínios Palmeira dos Índios S/A (ILPISA), proprietária da marca
VALEDOURADO, é uma indústria de alimentos derivados do leite com sede no
município de Palmeira dos Índios - AL e uma filial situada em Itapetinga – BA, onde
está sendo desenvolvido este projeto. Filial esta que tem uma capacidade de
processamento de 400.000litros/dia, gerando l60 empregos diretos.
Atualmente a ILPISA fabrica mais de 40 produtos diferentes, sendo sua principal
marca a VALEDOURADO, possuindo também a marca DOURADINHO, BOA VIDA,
Além de industrializar e distribui produtos com outras marcas:
• A bebida de frutas TAMPICO, uma das líderes em seu segmento no Brasil e no
mercado norte americano presente em mais de 50 países em todo mundo, com mais de 1
bilhão de litros por ano;
A empresa comercializa seus produtos para todo o território nacional e também
para o exterior.
12

1.4. Revisão bibliográfica
1.4.1. Sistemas de informação
Segundo [Orlandini, 2006], “um dos grandes desafios dos Sistemas de Informação é
assegurar a qualidade e agilidade da informação, imprescindível para as corporações e
seus gestores”.
Sistemas de informação são o conjunto de partes que interagem entre si para
atingir um objetivo ou resultado, que, em informática, é o conjunto de software
hardware e recursos humanos. Ou seja, são todos os sistemas que produzem ou geram
informações para auxiliar nos processos de tomada de decisão, segundo [Otsuka, 2004],
citando [Rezende, 2002].
O uso dos sistemas computadorizados como meio para criar, armazenar e
transferir informações é uma realidade que não deixa dúvidas, e um exemplo claro disso
é a quantidade de sistemas de informação, gerando informações em todos os níveis nas
empresas, auxiliando, como ferramenta imprescindível, aos investidores, em todas as
áreas e atividades, a tomarem decisões, o mais das vezes milionárias, sem falar no
volume de capital que gira eletronicamente ao redor do mundo, em transações
comerciais, que utilizam a Tecnologia de Informação de uma forma mais abrangente,
[Almeida et al., 2006], citando [Cervo et al., 2002].
De acordo com [Almeida et al., 2006], “o propósito de um projeto de sistemas é o
de elaborar o detalhamento das necessidades do sistema novo ou modificado. As suas
dimensões lógicas referem-se ao modo como os vários componentes do SI funcionarão
quando estiverem juntos. O projeto lógico inclui a especificação de dados para saídas e
entradas, processamento, arquivos, banco de dados, telecomunicações, procedimento,
pessoal e equipe e do projeto, além dos projetos de segurança e controle de operação”.
[Almeida, 2006], ainda destaca que o desenvolvimento de um sistema de
informação deve ser planejado e dividido em etapas bem definidas antes do inicio do
seu desenvolvimento. Tais etapas constituem o “ciclo de vida de um sistema de
informação” e incluem:
• A investigação do sistema – para obter um claro entendimento do problema;
• A análise do sistema – que define o que o sistema precisa fazer para resolver o
problema;
13

• O projeto do sistema – que determina exatamente como o sistema funcionara
para atender as necessidades;
• A implementação – que é a aquisição ou criação de vários componentes definidos
no estágio do projeto;
• A manutenção – que pode ser dividida em corretiva e preventiva, e tem como
objetivo fazer os necessários ajustes para o seu perfeito funcionamento;
• A validação – o processo no qual o sistema é aceito e validados os seus objetivos;
• Operação – que consiste na sua utilização pelo usuário.
1.4.2. Sistemas de Banco de Dados
“Um sistema banco de dados nada mais é do que um sistema de armazenamento de
dados baseado em computador; isto é, um sistema cujo objetivo global é registrar e
manter informação. Esta informação pode ser qualquer uma considerada significativa à
organização servida pelo sistema – em outras palavras, qualquer uma necessária ao
processo de decisão da gerência daquela organização”. [DATE, 1986]
Segundo [Rezende, 2004], citando [Korth, 1994] “um banco de dados é uma
coleção de dados inter-relacionados, representando informações sobre um domínio
específico”, ou seja, sempre que for possível agrupar informações que se relacionam e
tratam de um mesmo assunto, posso dizer que tenho um banco de dados”.
Ainda em seu artigo [Rezende, 2004] define um sistema de gerenciamento de
banco de dados (SGBD) como um software que possui recursos capazes de manipular
as informações do banco de dados e interagir com o usuário. Exemplos de SGBDs são:
Oracle, SQL Server, DB2, PostgreSQL, MySQL, entre outros.
Segundo [Date, 1986] um sistema de banco de dados envolve quatro componentes
maiores: dados, hardware, software e usuários.
1.4.3. Trabalhos correlatos
[Yamaguchi et al., 2000] realizou um trabalho com o objetivo de desenvolver um
sistema computacional para monitorar a gestão de um indústria de laticínios, desde a
plataforma de recepção de leite até a venda final do produto, passando por cálculos de
custos de recepção, beneficiamento e envase de leite fluido e da produção de derivados
lácteos.
14

Tanto o trabalho acima citado como este projeto final de curso tem em comum o
desenvolvimento de softwares para auxiliar a indústria de laticínios, porém diferem no
seu objetivo final: este projeto visa desenvolver um sistema de auxílio à tomada de
decisão no que diz respeito à qualidade do produto final, ao contrário do referido artigo
que busca auxiliar na gestão do processo produtivo.
[Molina, 2001], desenvolveu um software em linguagem Delphi para análise de
instalações térmicas, na ocasião para uma turbina a vapor. O programa possui como
variáveis de entrada dados de temperatura e pressão na entrada e na saída da turbina e o
rendimento isentrópico da turbina, a partir das quais eram calculadas e exibidas em
gráficos as variáveis de interesse, tais como: eficiência e consumo de vapor.
[Bilobrovec, 2005], apresenta em seu trabalho um sistema especialista baseado em
Lógica Fuzzy desenvolvido em linguagem Delphi para gerenciamento e manutenção da
qualidade do processo de aeração de grãos em silos, tendo como variáveis de análise a
temperatura e a umidade.
Este último trabalho tem uma grande semelhança com o desenvolvido neste
projeto que é o desenvolvimento de um sistema para acompanhar um processo
produtivo visando controlar a qualidade do produto final. Diferem-se na natureza dos
processos, discreto e contínuo respectivamente, apesar de, em alguns casos, processos
industriais envolvendo grãos serem considerado como contínuos.
[Vieira, 1999], em seu trabalho desenvolveu um protótipo de um sistema de
telepresença permitindo a interação entre um usuário remoto e um robô com capacidade
de decidir entre seguir os comandos do usuário remoto ou tomar uma ação baseado na
leitura que faz do ambiente. Para o desenvolvimento da interface homem-máquina
remota foi utilizada uma linguagem de programação de alto nível (linguagem C).
15

Capítulo 2
DESCRIÇÃO DO PROCESSO
A indústria Ilpisa / Valedourado, instalada na cidade de Itapetinga-BA, tem como
principais produtos o leite condensado, o leite em pó, o creme de leite e o leite UHT.
A planta instalada consiste em um concentrador tubular com coluna descendente da
marca Niro, que já possui toda a instrumentação necessária ao seu bom funcionamento.
Um PLC é responsável pelo controle do concentrador. Em um computador na cabine de
controle tem-se um sistema supervisório que faz toda a função de entrada e saída na planta.
O sistema supervisório foi instalado juntamente com toda a automação da planta e
funciona de maneira satisfatória. Porém este sistema não permite ao operador visualizar
dados históricos do perfil de temperatura da planta, somente um valor instantâneo é
mostrado na tela. O sistema também não gera alarmes de temperatura durante a produção.
O supervisório, a cada minuto, atualiza uma planilha em formato dbf contendo os
dados de temperatura do condensador.
Atualmente o departamento de qualidade avalia a qualidade do produto final da
seguinte forma:
no dia seguinte à produção um funcionário do setor de qualidade visualiza num
gráfico os dados de temperaturas obtidos pelo supervisório utilizando o Microsoft Excel;
tendo o horário da produção ele procura observar se em algum momento do
processo a temperatura do leite ultrapassou os limites inferior e superior, determinando a
qualidade do produto final.
Os principais inconvenientes deste procedimento são:
o atraso de tempo entre a produção e a visualização do gráfico de temperatura pela
coordenação de qualidade.
a impossibilidade de se tomar uma ação corretiva em tempo real, durante a
produção, para evitar perda de matéria-prima e da qualidade no produto final;
16

a ferramenta de gráficos do Microsoft Excel não possui boa definição de pontos,
dificultando a interpretação do gráfico.
A proposta de se desenvolver um software que opere em paralelo com o sistema
supervisório já existente traz como benefícios:
visualização da temperatura em “tempo real”;
geração de alarmes durante o monitoramento;
possibilidade de se tomar ações corretivas no decorrer da produção;
geração de relatórios de produção automáticos;
facilidade de visualização de dados históricos;
controle de acesso ao sistema através de login/senha;
monitoramento da operação da planta.
Os processos a serem monitorados pelo sistema desenvolvido por este projeto
consistem na produção do leite condensado e do leite concentrado.
O leite condensado é o produto que se obtém pela eliminação parcial da água do leite
através do tratamento térmico conhecido por evaporação. Além deste processo, o produto
aumenta sua concentração mediante a adição de sacarose.
Na fabricação do leite condensado têm-se dois processos distintos: a pasteurização e
a vacina de lactose. O primeiro trabalha com temperaturas entre 118 e 120 o C, e a vacina de
lactose entre 25 e 35 o C.
Já o leite concentrado consiste em um pré-produto para a produção do leite em pó e
possui somente o processo de pasteurização, operando com temperaturas entre 90 e 95 o C.
2.1. Pasteurização
A pasteurização consiste em um processo térmico que tem como objetivo principal a
destruição de microorganismos patogênicos associados ao alimento em questão. Um
objetivo secundário é aumentar a vida de prateleira do alimento, reduzindo as taxas de
alterações microbiológicas e enzimáticas. Os produtos pasteurizados podem conter, ainda,
muitos organismos vivos capazes de crescer, o que limita sua vida de prateleira. Assim, a
pasteurização é, muitas vezes, combinada com outros métodos de conservação e muitos
17

produtos pasteurizados são estocados sob refrigeração. [POTTER, 1995]
Existem três tipos de pasteurização:
pasteurização lenta, na qual são utilizadas temperaturas menores durante um
intervalo de tempo maior. Este tipo é melhor para pequenas quantidades de leite. A
temperatura utilizada é de 65˚C durante trinta minutos;
pasteurização rápida, na qual usam-se altas temperaturas durante curtos intervalos
de tempo. É mais utilizada para leite de saquinho, do tipo A, B e C. A temperatura
utilizada é de 75˚C durantes 15 a 20 segundos. Na literatura, freqüentemente encontra-se
este tipo de pasteurização com a denominação HTST (High Temperature and Short Time),
alta temperatura e curto tempo;
pasteurização muito rápida, na qual as temperaturas utilizadas vão de 130˚C a
150˚C, durante três a cinco segundos, este tipo é mais conhecido como UHT (Ultra High
Temperature) ou longa vida.
Os principais benefícios do processo de pasteurização são:
redução quase total da transmissão de doenças;
redução da carga bacteriana do leite;
eliminação de bactérias indesejáveis;
prolongamento da vida de prateleira do leite e seus derivados.
E como principais desvantagens tem-se:
redução e eliminação de bactérias lácteas benéficas (fermentos naturais);
alteração do sabor do leite;
desnaturação de proteínas do leite.
No caso específico da fábrica da Ilpisa, o processo de pasteurização utiliza
temperaturas entre 118 e 120º C, para a produção do leite condensado, e entre 90 e 95º C,
para o leite concentrado.
2.2. Vacina de lactose
Sabe-se que o leite condensado é o produto obtido através da eliminação parcial da água
18

presente no leite. O seu processamento passa por várias etapas como centrifugação,
pasteurização, e uma padronização do teor de gordura; passando então por um evaporador
de vários efeitos (normalmente são de quatro efeitos). É no evaporador que o leite vai
sendo concentrado ao longo das etapas, chegando no final com uma densidade de 1300
Kg/m 3 .
No final do processo, acontece o resfriamento do produto. A água do leite
condensado só pode manter em dissolução a metade da lactose (açúcar do leite), sendo que
a restante precipita-se em forma de cristais que são indesejados no produto final. Em
virtude disso, é preciso controlar a precipitação da lactose, para tal, resfria-se o produto sob
agitação até temperaturas da ordem de 25 a 30 ºC, ao mesmo tempo em que são
adicionados (inoculados) finos cristais de lactose, esta operação é conhecida com o termo
técnico de “Vacina de Lactose”. O papel destes cristais adicionados é favorecer a formação
de pequenos cristais de lactose. Os cristais adicionados (finos) funcionam como uma
“base” a qual induz a formação de cristais diminutos, isso evita que o produto final fique
com o paladar “arenoso”, ou seja, como se estivessem presentes pequenos grãos de areia.
Para que a vacina de lactose seja realizada de maneira adequada é preciso controlar a
temperatura e a quantidade de lactose adicionada, bem como o tamanho dos cristais
adicionados.
lactose.
O leite concentrado, outro produto que será monitorado, não possui vacina de
19

Capítulo 3
ANÁLISE DE REQUISITOS
Inicialmente foi feita uma visita à fábrica da Ilpisa onde foram tomadas algumas
informações acerca do processo de produção, dos problemas enfrentados e dos
resultados esperados para o sistema a ser desenvolvido por este projeto.
A partir daí foi feita uma análise de requisitos buscando especificar cada uma das
funcionalidades do software, chamadas aqui de casos de uso.
A análise de requisitos consiste na identificação e modelagem das funcionalidades
a serem implementadas no software de maneira a atender às necessidades do cliente.
O objetivo deste sistema é conseguir monitorar a temperatura dos processos de
produção da planta em questão. Para tanto a aplicação deverá ser capaz de coletar dados
do sistema supervisório a uma taxa determinada pelo operador, exibir essas medidas em
um gráfico de tendência em “tempo real” e gerar alarmes quando a temperatura sair dos
limites de produção.
Para a análise de requisitos foi utilizada a UML como linguagem de modelagem,
através do software umbrello, um programa gratuito para modelagem UML.
20

3.1. Diagrama de casos de uso
Figura 3.1. Diagrama de casos de uso
No diagrama acima são mostrados os 2 atores do sistema: o operador e o coordenador,
cada um ligado aos seus respectivos casos de uso. Pode-se ver claramente que algumas
ações são comuns aos dois atores e outras são exclusivas do coordenador, que possui
todos os privilégios no sistema.
21

3.1.1. Descrição dos casos de uso
A seguir são mostradas as especificações de cada caso de uso do sistema a ser
implementado.
Nome: Fazer login
Objetivo: Efetuar autenticação para ter acesso ao sistema
Requisitos de usabilidade: O usuário deve ter um usuário/senha cadastrada no sistema
Ator(es): Operador e coordenador
Pré-condição: O software deve estar rodando e não deve haver usuário
logado no sistema
Descrição: Logar-se no sistema por meio de usuário e senha
criptografada
Exceções: Já existe um usuário logado no sistema; usuário e/ou senha
inválidos
Pós-condição; O software está pronto para oferecer ao usuário todas as
funcionalidades a que tem permissão de acesso
Nome: Fazer logout
Tabela 3.1. Caso de uso: Fazer login
Objetivo: Encerrar uma sessão de operação
Requisitos de usabilidade:
Ator(es): Operador e coordenador
Pré-condição: O software deve estar rodando e deve haver um usuário
logado no sistema
Descrição: Deslogar-se do sistema, o que não implica encerrar o
monitoramento do processo, mas apenas uma troca de
usuário
Exceções:
Pós-condição; O software bloqueia todas as funcionalidades de usuários e
aguarda uma nova operação de login
Nome: Criar usuário
Tabela 3.2. Caso de uso: Fazer logout
Objetivo: Criar um novo usuário/senha para login no sistema
Requisitos de usabilidade:
Ator(es): Coordenador
Pré-condição: Um usuário com permissões de coordenador deve estar
logado no sistema
Descrição: O coordenador pode criar um novo usuário/senha para
acesso aos sistemas, com nível de acesso específico
Exceções: Os valores dos campos senha e confirmar senha são
diferentes; algum dos campos do formulário estar vazio; já
existir um usuário com aquele nome no banco de dados
Pós-condição; O usuário é criado na tabela de usuários do banco de dados e
já pode fazer login no sistema
Tabela 3.3. Caso de uso: Criar usuário
22

Nome: Excluir usuário
Objetivo: Excluir um usuário/senha de acesso ao sistema
Requisitos de usabilidade:
Ator(es): Coordenador
Pré-condição: Um usuário com permissões de coordenador deve estar
logado no sistema
Descrição: O coordenador pode excluir um usuário de acesso ao sistema
na tabela de usuários do banco de dados
Exceções:
Pós-condição; O usuário excluído não mais terá acesso ao sistema através
daquele usuário/senha
Nome: Alterar senha
Tabela 3.4. Caso de uso: Excluir usuário
Objetivo: Alterar senha de acesso ao sistema
Requisitos de usabilidade: Um usuário deve ser capaz de alterar sua própria senha
Ator(es): Operador e coordenador
Pré-condição: O usuário deve estar logado.
Descrição: Um usuário logado pode alterar sua própria senha
Excessões: Os valores dos campos senha e confirmar senha são
diferentes; algum dos campos do formulário estar vazio
Pós-condição; A senha de acesso o usuário foi alterada
Tabela 3.5. Caso de uso: Alterar senha
Nome: Configurar o sistema
Objetivo: Definir variáveis de configuração do sistema
Requisitos de usabilidade: O usuário deve ser capaz de reconfigurar o comportamento
do sistema online
Ator(es): Coordenador
Pré-condição: O coordenador deve estar logado
Descrição:
O coordenador pode definir variáveis de configuração do
sistema, tais como: acesso ao banco de dados, taxa de
atualização dos dados (amostragem) e período de
monitoramento do processo ao longo do dia e da semana
Exceções: Definição de dados inválidos do acesso ao banco de dados
tais como: endereço IP, port, nome do banco, usuário e
senha; algum campo em branco de configuração do sistema,
como taxa de amostragem e período de monitoramento
Pós-condição; O sistema redefine as variáveis no arquivo de configuração e
reinicia o processo de monitoramento com os novos
parâmetros
Tabela 3.6. Caso de uso: Configurar sistema
23

Nome: Iniciar monitoramento
Objetivo: Colocar o sistema para acompanhar a temperatura do
processo
Requisitos de usabilidade:
Ator(es): Operador e coordenador
Pré-condição: O software e o supervisório devem estar rodando
Descrição:
Ao iniciar o monitoramento o usuário faz com que o
sistema comece a amostrar os valores da temperatura do
processo e atualizar o gráfico de tendência
Exceções: A comunicação entre o software e o supervisório ou entre o
software e o banco de dados pode falhar
Pós-condição; O usuário poderá acompanhar na tela o gráfico de tendência
da temperatura
Tabela 3.7. Caso de uso: Iniciar monitoramento
Nome: Parar monitoramento
Objetivo: Interromper o monitoramento da temperatura
Requisitos de usabilidade:
Ator(es): Operador e coordenador
Pré-condição: O software deve estar no estado de monitoramento da
temperatura
Descrição:
O usuário poderá interromper o acompanhamento da
temperatura do processo caso seja necessário
Exceções:
Pós-condição; O sistema ficará ocioso até que o monitoramento seja
reiniciado
Tabela 3.8. Caso de uso: Parar monitoramento
Nome: Criar produto
Objetivo: Definir variáveis de configuração de um produto
Requisitos de usabilidade:
Ator(es): Coordenador
Pré-condição: O coordenador deve estar logado
Descrição: O coordenador poderá setar configurações de um novo
produto, tais como: tagname, temperatura de operação e
limites inferior e superior
Exceções: Já existe um produto com aquele tagname
Pós-condição; O sistema estará apto a monitorar a produção daquele
produto
Tabela 3.9. Caso de uso: Criar produto
24

Nome: Excluir produto
Objetivo: Excluir um produto
Requisitos de usabilidade:
Ator(es): Coordenador
Pré-condição: O coordenador deve estar logado
Descrição:
O coordenador pode excluir um produto que não mais
será monitorado ou será modificado
Exceções:
Pós-condição; O produto não mais aparecerá como opção para o operador
Tabela 3.10. Caso de uso: Excluir produto
Nome: Trocar produto
Objetivo: Efetuar a troca do produto em processo
Requisitos de usabilidade:
Ator(es): Operador e coordenador
Pré-condição: O usuário deve estar logado
Descrição:
Exceções:
O usuário poderá trocar o produto a ser monitorado,
alterando assim as configurações do sistema de alarmes
Pós-condição; O sistema de alarmes estará configurado para atender às
especificações daquele produto
Tabela 3.11. Caso de uso: Trocar produto
Nome: Justificar alarme
Objetivo: Reconhecer e justificar um alarme
Requisitos de usabilidade:
Ator(es): Operador e coordenador
Pré-condição: O usuário deve estar logado
Descrição:
O usuário logado deve reconhecer e justificar um valor
de temperatura fora dos limites inferior e superior
Exceções:
Pós-condição; O sistema volta ao seu estado normal de monitoramento
Tabela 3.12. Caso de uso: Justificar alarme
Nome: Visualizar gráfico histórico
Objetivo: Visualizar a perfil de temperatura histórico
Requisitos de usabilidade:
Ator(es): Coordenador
Pré-condição: O coordenador deve estar logado
Descrição:
O coordenador poderá visualizar o gráfico da
Exceções:
temperatura de um dia anterior da produção
Não existir dados no banco de dados para a data selecionada
Pós-condição; O sistema exibirá em outra janela o gráfico da temperatura do
processo
Tabela 3.13. Caso de uso: Visualizar gráfico histórico
25

Nome: Gerar relatório de alarmes
Objetivo:
Requisitos de usabilidade:
Gerar um relatório de alarmes
Ator(es): Coordenador
Pré-condição: O coordenador deve estar logado
Descrição:
O coordenador poderá gerar um relatório de alarmes
ocorridos em um intervalo de tempo
Exceções: Não existir dados no banco de dados para o período
selecionado
Pós-condição; O sistema gerará e exibirá em uma janela o relatório
Tabela 3.14. Caso de uso: Gerar relatório de alarmes
3.2. Diagrama de sequência
Foi elaborado um diagrama de sequência para a rotina de coleta de dados do
supervisório e atualização do gráfico de tendência da temperatura do processo.
Figura 3.2. Diagrama de sequência
Primeiramente o usuário deverá iniciar o monitoramento do processo, a thread
monitor é então criada e esta inicializa um timer com o período de amostragem dos
dados. Atingido o período o timer “acorda” a thread que busca do supervisório a última
medida obtida e insere este valor no gráfico de tendência.
3.3. Modelagem do banco de dados
A partir da análise de requisitos foi modelada a estrutura do banco de dados a ser
implementado. A seguir é mostrado o diagrama de entidade relacionamento do sistema.
26

Figura 3.3. Diagrama de Entidade-Relacionamento
A partir do diagrama mostrado acima pode-se inferir que:
cada produto pode ter um ou mais processos, onde cada processo possui os seus
limites de temperatura de trabalho, e cada processo corresponde a um produto;
cada produto pode ter um ou mais alarmes, e cada alarme refere-se a apenas um
produto;
cada alarme gerado possui um único usuário, e um usuário pode ter vários
alarmes relacionados.
Existem ainda duas tabelas de logs, uma de usuários, responsável por registrar os
acessos dos usuários do sistema, e outra de produto, que registra o início e o término do
monitoramento de cada produto.
27

3.4. Telas do sistema
A seguir são mostrados alguns protótipos das interfaces do sistema.
■
Fig. 3.5. Tela de exclusão de usuário
Caso de uso: Excluir usuário
Fig. 3.7. Telas de configuração do sistema
Caso de uso: Configurar sistema
Fig. 3.4. Tela de login
Caso de uso: Fazer login
Fig. 3.6. Tela de criação de usuário
Caso de uso: Criar usuário
28

A figura mostrada abaixo consiste num screenshot da janela principal do
programa em funcionamento.
Fig. 3.8. Janela principal do sistema
Demonstração do sistema em funcionamento
29

Capítulo 4
DESENVOLVIMENTO DO SISTEMA
Após feita toda a análise de requisitos e a modelagem do sistema, passou-se à etapa de
codificação do software, o desenvolvimento do sistema propriamente dito.
Foi escolhido como sistema gerenciador de banco de dados (SGBD) o MySQL,
dentre outros motivos, por ser uma ferramenta gratuita, de fácil instalação e operação,
de fácil conexão com diversas linguagens estruturadas, como C/C++, delphi, java, php,
etc, e possuir muita documentação disponível no site do fabricante e na internet de
maneira geral.
Optou-se pelo Delphi como linguagem de desenvolvimento do software por ser
uma linguagem estruturada, orientada à eventos e à objetos, de fácil aprendizado, com
bastante documentação de auxílio na internet, com interface gráfica de fácil utilização,
contando com componentes de conexão ao MySQL, etc.
O Delphi é uma IDE da Borland, que segue a filosofia RAD (Rapid Application
Development), que se baseia na facilidade do desenvolvimento de interfaces gráficas
através de componentes.
O Delphi mostrou-se uma linguagem adequada ao desenvolvimento deste
aplicativo por algumas restrições de projeto, tais como:
o software deve funcionar na mesma máquina em que roda o supervisório da
planta;
o software deve rodar em windows, sistema operacional da máquina do
supervisório;
todo o sistema (software+banco de dados) deve rodar numa mesma máquina,
visto não ser possível ligar-se a máquina na rede da empresa;
o sistema deve estar apto a uma migração para uma outra máquina rapidamente.
Foi escolhido o Borland Delphi 6.0 professional, por ser a versão desta IDE de
mais fácil acesso.
30

4.1. Codificação do banco de dados
O banco de dados foi codificado utilizando-se a linguagem SQL (Structured Query
Language) e em seguida implementado no MySQL da máquina de desenvolvimento. O
arquivo contendo o script sql foi armazenado numa pasta de documentação do projeto
para, numa posterior instalação na fábrica ou em outra máquina, ser executado e gerar
toda a estrutura de tabelas do banco de dados, onerando assim o usuário da codificação
repetida do banco.
O fato de o MySQL poder ser baixado gratuitamente da internet e de a estrutura
do banco de dados estar armazenada em um arquivo (script) torna o sistema de fácil e
rápida instalação, caso seja necessário transferir todo um sistema para uma outra
máquina.
4.2. Codificação do software
A etapa seguinte, mais longa, mais importante e por consequência mais delicada,
consistiu em codificar o software modelado até o momento. Todas as interfaces gráficas
(telas) foram desenvolvidas juntamente com o código de acesso e manipulação de
dados.
O primeiro passo foi a instalação da IDE de desenvolvimento e dos componentes
necessários: foi escolhido um componente gratuito para conexão ao banco de dados, o
zeos (www.zeoslib.net), um para entrada de campos numéricos, o num edit. e um
componente para criptografia.
Definiu-se um formato de arquivo texto, chamado config.txt, pra conter as
definições de configuração do sistema, como, por exemplo, informações de acesso ao
banco de dados (IP, port, usuário, senha e nome do banco de dados) e do funcionamento
do sistema, como o período de amostragem dos dados e o caminho (pasta) das planilhas
de dados.
4.2.1. Autenticação
A primeira interface desenvolvida foi a tela de autenticação, que consiste em uma janela
contendo um campo para entrada do login de usuário e um para a senha, além de um
botão OK para fazer o login do usuário.
Ao clicar no botão OK o sistema verifica se todos os campos estão preenchidos,
31

caso não estejam uma exceção é gerada e uma mensagem é exibida para o usuário na
tela. Se todos os campos estão preenchidos o sistema primeiro criptografa a senha
utilizando o MD5 [WEBER, 2006], o algoritmo de criptografia adotado, e então
confirma na tabela de usuários se tal par login/senha está cadastrado no sistema.
Caso os dados estejam corretos todas as funcionalidades do sistema às quais o
usuário tem acesso são habilitadas para o uso.
Figura 4. 1. Janela de autenticação
A janela acima mostra a tela de autenticação do sistema, onde o usuário deverá
fazer login no início da operação do sistema.
4.2.2. Configuração
Em seguida partiu-se para a programação das janelas de configuração do sistema:
configuração de acesso ao banco de dados, período de amostragem e acesso aos dados
do supervisório, e gerenciamento do acesso ao sistema (criação e exclusão de usuários).
Os dados informados pelo usuário nas janelas de configuração do sistema são
atualizados no arquivo de configuração (config.txt) como já foi dito anteriormente.
4.2.3. Gráfico de tendência
O gráfico de tendência da temperatura do processo foi implementado a partir do
componente TeeChart, um componente nativo do Delphi. Algumas modificações de
comportamento em tempo de execução foram introduzias no componente.
A ferramenta permite ao usuário focar o zoom em uma dada região do gráfico
clicando-se o botão esquerdo do mouse e desenhando um retângulo a partir da posição
superior esquerda. Para retornar ao zoom original do gráfico basta fazer um retângulo ao
contrário, partindo agora do canto inferior direito.
No eixo x (horizontal) do gráfico estão os horários das medidas realizadas, e no
eixo y (vertical) o valor da temperatura medida em graus.
São mostrados no gráfico de tendência dois perfis de temperatura, correspondente
32

aos dois processos monitorados, a temperatura de pasteurização (gráfico em vermelho)
e da vacina de lactose (gráfico em azul), como mostrado a seguir:
Figura 4. 2. Gráfico de tendência
Ao lado do gráfico de tendência é exibida uma tabela contendo os valores das
medidas de temperatura para cada um dos processos e o horário em que foi feita a
leitura da medida no PLC.
Figura 4. 3. Tabela de dados
33

4.2.4. Monitoramento e geração de alarmes
O operador poderá iniciar o monitoramento dos processos através de um check-box que
define o status do processo, como mostrado na figura abaixo.
Figura 4. 4. Check-box de alteração de status do processo
Após alterar o status do processo para Em monitoramento o operador deverá
escolher na caixa de seleção Produto, o produto em produção, de maneira a setar os
limites superior e inferior para os processos do produto selecionado.
Para o processo de monitoramento da variável (temperatura) foi criado um timer e
uma thread para sincronizar a operação de coleta dos dados. A cada período de
amostragem o timer seta um evento que “acorda” a thread monitor que coleta na
planilha de dados do dia de produção (arquivo DBF), os valores do timestamp e das
temperaturas dos dois processos monitorados. A seguir a thread plota os novos valores
de temperatura no gráfico de tendência e os inclui na tabela de dados. Este mecanismo é
mostrado no diagrama de sequência em 3.2.
O passo seguinte consiste em chamar-se uma função que analisa esses valores e
define se estão dentro dos limites inferior e superior de cada processo. Caso contrário
um alarme é gerado, preenchendo uma linha da tabela de alarmes não reconhecidos.
Figura 4. 5. Tabelas de alarmes
O operador poderá reconhecer e justificar um alarme da tabela mostrada acima
clicando-se duas vezes sobre uma linha. É então aberta uma janela de reconhecimento
de alarme para o operador, como mostrado a seguir:
34

Figura 4. 6. Janela de reconhecimento de alarmes
Os campos tipo de alarme, usuário e valor medido são do tipo read-only (somente
leitura), ou seja, são preenchidos pelo sistema e não podem ser alterados pelo operador.
Após reconhecido o alarme, a janela é fechada e o alarme sai da tabela de alarmes
não reconhecidos (fonte de cor vermelha) e vai para a tabela de alarmes reconhecidos
(fonte de cor preta).
4.2.5. Relatórios
A última etapa do desenvolvimento consistiu na implementação de uma ferramenta de
relatórios que permitisse ao operador gerar relatórios contendo o gráfico histórico da
temperatura para um dia de produção, e os alarmes gerados num período de produção.
Para isto foi utilizada a ferramenta de relatórios Quick Report, que faz parte do Delphi
6.
É mostrada a seguir a janela de configuração de relatórios.
35

Figura 4. 7. Janela de configuração de relatórios
A figura acima representa a janela de configuração de relatórios, através da qual o
operador poderá definir alguns parâmetros do relatório impresso, tais como o período e
a presença ou não de gráfico.
Os relatórios gerados podem ser diretamente impressos em qualquer impressora
instalada na máquina, ou em rede, e ainda ser salvo como imagem.
36

Capítulo 5
TESTES E IMPLANTAÇÃO
Após o término da etapa de desenvolvimento do sistema foram feitos testes visando
garantir o bom funcionamento do sistema. A técnica escolhida foi o Teste de Caixa
Preta (Black Box). No Teste de Caixa Preta deve-se conhecer as funções que o software
possui e saber se elas operam corretamente, portanto, este teste refere-se aos testes
realizados nas interfaces do software e não se preocupa com sua estrutura lógica interna.
[ROCHA, 2002]
5.1. Testes
Foram elaborados casos de teste para os casos de uso descritos na seção 3.1.1. Cada
caso de teste é composto pelo itens abaixo:
caso de teste: caso de teste participante da ação, que pode ser um caso de uso ou
parte de um caso de uso;
ação: ação a ser executada pelo caso de teste;
interfaces envolvidas: as janelas ou arquivo que participam do teste;
entradas: as entradas a serem fornecidas para o teste. Há duas categorias:
Correta: Entrada com todos os valores certos;
Com erro: Entrada errada para testar a robustez do software.
Saídas esperadas: as saídas esperadas nos casos das entradas perfeita e com
erros;
Saídas obtidas: as saídas que foram exibidas após a realização da ação;
Resultado: indica sucesso, caso a saída apresentada seja igual à saída esperada.
Caso contrário, o resultado faz a descrição do problema apresentado.
Foram criados 12 casos de teste básicos visando testar os casos de uso modelados.
Destes apenas 1 apresentou uma saída diferente da esperada, o que representa um
desempenho de 91,67%. O caso de teste que apresentou problemas foi corrigido e
depois testado novamente, verificando-se a solução do problema.
São mostrados a seguir dois casos de teste, um cujo resultado foi sucesso e outro
37

que apresentou erro:
Caso de teste
Ação
Interfaces envolvidas
Entradas
Saídas esperadas
Saídas obtidas
Resultado
Inicialização do sistema
Inicializar as variáveis de configuração do
sistema
Arquivo texto de parâmetros de
configuração
Correta Arquivo presente
Com erro
Correta
Com erro
Correta
Arquivo ausente
O sistema deve inicializar as variáveis de
acesso ao banco de dados e período de
amostragem
Mensagem de erro informando a
ausência do arquivo
Como esperado
Com erro Como esperado
Sucesso
Tabela 5.1. Exemplo de caso de teste
A tabela acima mostra um caso de teste que consiste na inicialização do sistema.
Para tanto foram elaboradas duas entradas: uma correta, onde o arquivo de parâmetros
de configuração estava presente na pasta do programa, e outra com erro, em que o
arquivo de configuração não foi encontrado. Para ambas as situações o sistema
respondeu da maneira esperada, sendo que na entrada com erro foi exibida uma
mensagem de erro para o usuário informando o problema.
Como forma de testar o funcionamento do sistema na coleta de dados do
supervisório foi utilizada uma tabela em formato DBF extraída do computador da
fábrica, contendo os dados de um dia de produção real.
Um caso de teste foi elaborado com este propósito e é mostrado na tabela a seguir.
38

Caso de teste
Ação
Coleta de dados
Interfaces envolvidas Tela principal
Entradas
Saídas esperadas
Saídas obtidas
Resultado
Correta
Com erro
Correta
Com erro
Correta
Com erro
Coletar dados do arquivo em formato
DBF, plotar as medidas no gráfico de
tendência e na tabela de dados.
Planilha contendo as medidas presente
na pasta.
Ausência do arquivo na pasta.
Medidas plotadas no gráfico de
tendência e na tabela.
Mensagem de erro informando que o
arquivo referente àquele dia de produção
não havia sido encontrado.
Os valores foram plotados no gráfico de
tendência e inseridos na tabela de dados
Foi exibida a mensagem de erro
informando que o arquivo de dados não
havia sido encontrado, mas em seguida,
uma mensagem de erro não tratada do
sistema operacional foi também
mostrada na tela
Falha
Tabela 5.2. Exemplo de caso de teste com problemas
A tabela acima descreve um caso de teste que consiste na rotina de coleta de
dados do supervisório. Foram elaboradas duas entradas, uma correta, na qual a tabela de
dados estava presente na pasta, e outra com erro, onde este arquivo não foi encontrado.
Nesse caso de uso ocorreu uma excessão não tratada pelo programa e o sistema travou.
Em seguida o sistema foi recompilado contando com um tratamento especial para essa
excessão.
5.2. Implantação
Após a fase de testes e corrigidos os erros encontrados, passou-se à etapa de
implantação do sistema na fábrica. Decidiu-se que a aplicação seria instalada na mesma
máquina que roda o supervisório, pois, por motivos de segurança, esta máquina não
encontrava-se ligada à rede da empresa, portando o sistema rodaria localmente.
A máquina da Ilpisa apresentava as condições mínimas necessárias para o bom
funcionamento do sistema: um micro Pentium III 1,8 GHz, com 512mb de memória
RAM, rodando sistema operacional Windows 2000 Server.
39

Primeiramente foi instalado na máquina o banco de dados, o MySQL versão 5.0.
Em seguida foi rodado o script de criação do banco de dados.
Implementado o banco de dados passou-se à cópia dos arquivos da aplicação.
Algumas configurações locais foram necessárias, tais como, o caminho dos arquivos de
dados (planilhas do supervisório), o endereço do banco de dados (local) e algumas
bibliotecas necessárias (dll) não estavam presentes na versão do windows instalada, e
tiveram que ser copiadas.
Toda implantação ocorreu sem maiores problemas e foi feito um start-up no
software, que rodou perfeitamente, coletando os dados e mostrando-os no gráfico de
tendência.
40

Capítulo 6
CONCLUSÕES
Ao final deste projeto foi obtido, como esperado, um sistema de informação capaz de
auxiliar o departamento de qualidade da empresa no acompanhamento dos processos
produtivos em tempo real. Ou seja, o sistema apresenta conformidade com as
especificações iniciais.
Todo este sistema poderia ser desenvolvido dentro do supervisório, porém alguns
fatores foram determinantes na escolha pelo desenvolvimento de um sistema à parte,
tais como:
• A distância física da fábrica, situada no sul da Bahia, a cerca de 1000 km de
Belo Horizonte;
• A necessidade de aprendizado e familiaridade com o sistema supervisório da
Ilpisa, em contrapartida ao já domínio do Delphi.
Durante este trabalho houve grande cooperação por parte dos funcionários da
empresa, o que facilitou significativamente o desenvolvimento do sistema à distância.
A seguir é mostrada uma imagem da tela principal do programa em
funcionamento na fábrica.
41

Fig. 6.10. Janela principal
Como sugestão para trabalhos futuros ficam:
• Operação do sistema em rede, possibilitando maior integração de dados na
empresa;
• Integração do software e do banco de dados com sistemas de gestão da empresa,
proporcionando aos gerentes o acompanhamento do processo em tempo real;
• Desenvolvimento de aplicações WEB para acesso remoto via internet ou intranet
das informações do sistema, o que seria de grande ganho para a empresa visto
que esta possui fábricas espalhadas pelos estados da Bahia e de Alagoas;
• Armazenamento histórico de picos de temperatura, outra variável importante
para a produção de derivados do leite;
• Uso de técnicas de controle estatístico, para produção de cartas de controle
visando obter um maior controle do comportamento da temperatura do processo
e a detecção de fatores influentes no processo.
42

Referências Bibliográficas
[ALMEIDA, 2006] ALMEIDA, Claudio Jose; CHAVES, Daniel Baltazar; CHAVES, Ricardo
Baltazar; GRANATO, Sandro Campos; CARELLI, Flavio Campos; OSORIO, Tito Livio;
GENESTRA, Marcelo. Aspectos Gerais da Aplicação de Sistemas de Informação na Agropecuária.
Revista Eletrônica de Sistemas de Informação, ed. 8, n. 2, 2006.
[BILOBROVEC, 2005] BILOBROVEC, Marcelo. Sistema Especialista em Lógica Fuzzy para o
Controle, Gerenciamento e Manutenção da Qualidade em Processo de Aeração de Grãos. 2005.
Universidade Tecnológica Federal do Paraná.
[CERVO, 2002] CERVO, A.L.; BERVIAN, P.A.. Metodologia Científica. 5 ed. São Paulo:
Prentice Hall (2002).
[DATE, 1986] DATE, C. J. Introdução a Sistemas de Bancos de Dados. Editora Campus. 1986.
[KORTH, 1984] KORTH, H.F. e SILBERSCHATZ, A.. Sistemas de Bancos de Dados. Makron
Books, 2a. edição revisada, 1994.
[MOLINA, 2001] MOLINA, Geraldo Luís Samata. Desenvolvimento de Software para Análise de
Turbinas a Vapor. 2001. Escola Federal de Engenharia de Itajubá.
[ORLANDINI, 2006] ORLANDINI, Leandro. A importância dos sistemas de informação. 2006.
Coluna Administração e Tecnologia, no site www.bonde.com.br. Acesso em 24/02/2007.
[OTSUKA, 2004] Fabiano Yukio Otsuka. Desenvolvimento de um Aplicativo para Gestão de
Eventos Utilizando a Ferramenta de Programação Delphi. Universidade Federal de Lavras. 2004.
[POTTER, 1995] Potter, N. N. e Hotchikiss, J. H. Food Science. 5.ed. New York: Chapman
& Hall, 1995.
[REZENDE, 2002] Denis Alcides Rezende. Engenharia de Software e Sistemas de Informação. Rio
de Janeiro, 2002.
[REZENDE, 2004] REZENDE, Ricardo. Conceitos Fundamentais de Banco de Dados. 2004.
www.sqlmagazine.com.br. Acesso em 30/03/2007.
[ROCHA, 2002] ROCHA, Camila Ribeiro.Estudo do Modelo Incremental para Desenvolvimento
de Software Utilizando o Paradigma de Orientação a Objetos. Universidade Federal de Goiás. 2002.
[VIEIRA, 1999] VIEIRA, Rodrigo de Souza. Protótipo de um Sistema de Monitoramento Remoto
Inteligente. 1999. Universidade Federal de Santa Catarina.
[WEBER, 2006] WEBER, Raul Fernando. Criptografia contemporânea . Universidade Federal do
Rio Grande do Sul. Disponível em:
.
Acesso em 13/04/2007.
43

[YAMAGUCHI et al., 2000] YAMAGUCHI, Luis Carlos Takao; NEVES, Braz dos Santos;
CARNEIRO, Alziro Vasconcelos e NOCELLI, Cristianne Regina. 2000. Uso de Sistema
Informatizado na Gestão de Indústrias de Laticínios. Congresso e Mostra de Agro Informática.
44