Académique Documents
Professionnel Documents
Culture Documents
ARENA
Engenharia Informática
2011/2012
Simulação de Linha de Produção usando a Plataforma
ARENA
Relatório da UC de Projeto
Licenciatura em Engenharia Informática
Escola Superior de Tecnologia e de Gestão
Alexandra Fernandes
Setembro de 2012
iii
iv
A Escola Superior de Tecnologia e Gestão não se responsabiliza pelas opiniões expressas
neste relatório.
v
Certifico que li este relatório e que na minha opinião, é adequado no seu
conteúdo e forma como demonstrador do trabalho desenvolvido no
âmbito da UC de Projecto.
___________________________________________
___________________________________________
Arguente
vii
viii
Agradecimentos
Durante o meu percurso muitos colegas, professores, funcionários do IPB se mostraram disponíveis para me
ajudaram, no entanto existem algumas às quais não posso deixar de agradecer:
Ao Instituto Politécnico de Bragança, em particular à Escola Superior de Tecnologia e Gestão por me ter
recebido e proporcionado excelentes condições de trabalho durante o percurso académico.
Ao Prof. Dr. Paulo Leitão, pelo apoio, disponibilidade e paciência disponibilizados durante a realização do
presente projeto.
À minha família, pela compreensão e carinho disponibilizados, apesar das enumeras horas de ausência,
principalmente nesta fase final.
Ao grupo de trabalho do LCAR, pelo apoio, conhecimento, opinião, amizade e paixão pelo conhecimento
disponibilizados ao longo do meu percurso escolar.
Aos amigos que durante o desenvolvimento do projeto contribuíram com o seu conhecimento, incentivo e
opinião.
ix
x
Resumo
Nas últimas décadas, assistiu-se a um despoletar tecnológico, do qual a indústria fez parte.
Para conseguir acompanhar a evolução tecnológica foi necessário aplicar novas técnicas e
tecnologias, que levem à automatização de toda a plataforma fabril. No entanto, a
automatização só por si não é a solução para todos os problemas, sendo necessário aplicar
métodos que permitam optimizar o funcionamento do sistema.
Neste sentido, a simulação de processos tornou-se numa área de elevado interesse, permitindo
verificar e optimizar sistemas complexos em ambiente virtual. A simulação permite verificar
o funcionamento de sistemas considerando diferentes cenários e assim, ser possível validar
modelos e/ou identificar procedimentos que introduzam melhorias no sistema. De forma a
auxiliar a aplicação de processos de simulação, assim como na posterior análise de resultados
obtidos, existem diversas plataformas de simulação no mercado.
O presente projeto enquadra-se nesta temática, cujo principal objetivo passa pela realização
de um estudo sobre a plataforma de simulação ARENA, e sua posterior utilização para a
modelação e simulação de um sistema de produção de uma linha fabril, produzindo máquinas
de lavar roupa. A simulação do modelo desenvolvido para diferentes cenários permitiu
identificar problemas na linha produtiva e apontar acções que visam uma melhoria de
produtividade da mesma.
xi
xii
Abstract
In this way, the simulation of processes has become a field of considerable interest, allowing
to verify and optimize complex systems in a virtual environment. The simulation allows to
verify the operation of systems considering different scenarios and thus be able to validate
models and/or identify procedures that introduce improvements in the system. In order to
assist the application of simulation processes, as well as in the subsequent analysis of the
achieved results, there are several simulation platforms on the market.
This project addresses this topic, whose main goal is achieved by undertaking a study on the
ARENA simulation platform, and its subsequent use for modeling and simulation of a
production system in a manufacturing line, producing washing machines. The simulation of
the developed model using different scenarios allowed to identify problems in the production
line and to point out actions to be implemented in the line aiming the improvement of its
productivity.
xiii
xiv
Conteúdo
1 Introdução .......................................................................................................................... 1
Capítulo 6 ................................................................................................................................ 35
Capítulo 7 ................................................................................................................................ 47
xv
7.1 Conclusões .................................................................................................................. 47
7.2 Trabalho Futuro .......................................................................................................... 48
16
Lista de Tabelas
xvii
xviii
Lista de Figuras
xix
xx
Lista de Abreviações
xxi
.
xxii
Capítulo 1
1 Introdução
Atualmente a sociedade encontra-se submersa na era digital, onde regularmente se confunde o
virtual com o real. O desenvolvimento de novas tecnologias contribuíram para aumentar,
substancialmente, a qualidade de vida da população e promover a sua longevidade.
Com a finalidade de aumentar os lucros e a sustentabilidade das empresas, a indústria
acompanhou este desenvolvimento procurando automatizar toda a plataforma fabril. Para tal
efeito é necessário recorrer a plataformas de simulação, na medida em que se torna
insustentável e demasiado dispendioso parar uma linha fabril completa, para realizar testes de
otimização dos parâmetros de funcionamento da mesma.
1.1 Contextualização
A história encontra-se repleta de referências sobre simulação. O relato mais antigo é de 500
AC, altura em que o império Romano simulava as suas batalhas com diferentes cenários,
procurando antecipar os seus oponentes e otimizar as estratégias a adotar, perante os
diferentes cenários.
Em 1929 é construído nos EUA (Estados Unidos da América) o primeiro simulador de voo
por Edward Link, denominado de “Link Flight Simulator”.
A verdadeira impulsão da simulação ocorreu perto dos anos 40, devido à segunda guerra
mundial. Ulam, Neumann e Fermi desenvolveram simuladores numéricos de processos em
computadores, ou seja, desenvolveram uma aplicação que permite simular de forma direta
problemas probabilísticos relacionados com o coeficiente de difusão do neutron em
determinados materiais. Este projeto conduziu à construção da bomba atómica e ficou
denominado de projeto Manhattan [Wiki 2012a].
1
Em 1960, Keish Douglas Tocher desenvolveu um programa de simulação cujo objetivo era
simular o funcionamento de uma linha fabril, onde as máquinas alteravam o seu estado
(ocupado, em espera, indisponível e erro). Ao mesmo tempo a IBM desenvolveu o GPSS
(General Purpose Simulation System), desenhado para simulações de teleprocessamento.
O RNCC (Royal Norwegian Computing Center) com o auxílio de Univac, iniciou em 1961 o
programa SIMULA originando a linguagem de programação SIMULA I. Anos mais tarde, em
1963 a RAND CORPORATION desenvolveu o SIMSCRIPT, alternativa ao GPSS baseada
em Fortran [wiki 2012b].
Posteriormente à segunda guerra mundial surgiram as primeiras simulações de guerras em
computadores e sistemas de defesa aérea. Estas apareceram com o objetivo de otimizar a
defesa do país e foram patrocinados pelo Departamento de Defesa Militar dos EUA e pela
NATO (North Atlantic Treaty Organization), tendo contribuído para o aparecimento de
técnicas fundamentais, tal como a POO (Programação Orientada a Objetos). Em 1982
surgiram os primeiros ambientes para simulação em microcomputadores, tais como SIMAN
[PC 95].
Até à atualidade foram dados passos significativos que permitiram tornar os programas de
simulação em plataformas de simulação com elevada capacidade de processamento,
interatividade e facilidade na modelação de problemas complexos e, posteriormente, na sua
análise e otimização.
O Instituto Politécnico de Bragança encontra-se envolvido num projeto europeu que possui
como objetivo criar um novo modelo de produção que integre os processos de controlo de
produção e de qualidade de linhas de produção, utilizando sistemas multi-agentes.
2
uma linha fabril que produz máquinas de lavar roupa. Para o efeito foi necessário estudar as
potencialidades e limitações da referida plataforma de simulação, assim como obter
conhecimentos base de simulação para aplicar posteriormente.
O primeiro capítulo tem como principal objetivo contextualizar e enunciar a problemática que
leva ao desenvolvimento do projeto, assim como a definir os objetivos do mesmo.
3
4
Capítulo 2
2 Simulação de Processos
5
entanto, torna-se verdadeiramente relevante quando é utilizada para estudar sistemas
complexos.
Neste trabalho, considerou-se que a simulação é a reprodução mais fidedigna de uma
operação de um processo do mundo real, ou de um sistema ao longo de um determinado
tempo, num ambiente controlado. Deste modo, será possível compreender o comportamento
do processo do mundo real ou sistema, e determinar um conjunto de soluções ou otimizações
da simulação em questão. Esta tornou-se numa técnica importante para planeamento,
conceção e controlo de sistemas.
A evolução das plataformas de simulação permitiu observar que a simulação é uma área em
constante mudança e de elevada importância. No entanto, como toda a tecnologia, esta possui
vantagens e desvantagens.
6
Possibilita comprimir ou expandir o tempo de simulação possibilitando estudar todos
os fenómenos com um elevado detalhe. Ou seja, pode-se examinar o impacto de uma
alteração no sistema em minutos, e assim dispensar horas a observar as operações
que ocorrem em breves minutos de atividade simulada. Sendo assim, investir num
estudo de simulação é extremamente importante e lucrativo [BJ 98] [PC 95].
Pode ser utilizada para treinar uma equipa de trabalho, sendo que é menos
dispendioso e prejudicial do que a aprendizagem diretamente no sistema real.
Permite realizar testes em cenários que em ambiente real são complicados de ocorrer
ou requerem ambientes perigosos.
7
No entanto, a construção de um modelo de simulação carece de formação específica. Sendo
que a qualidade da análise e da simulação depende da qualidade do modelo e da habilidade do
analista [BJ 98] [PC 95]. Adicionalmente, os resultados da simulação são em alguns casos,
difíceis de interpretar, ou seja, pode-se realizar a simulação duas ou mais vezes e obter
esporadicamente, um ou mais parâmetros fora do intervalo de confiança. Este fato torna
difícil verificar se uma observação realizada durante uma execução da simulação é devido a
uma relação significativa do problema simulado ou se resulta da aleatoriedade do modelo [BJ
98] [PC 95].
A simulação apresenta conceitos base que são necessários para fomentar a compreensão do
sistema real, assim como servirão de auxílio na formulação do modelo computacional.
De seguida, será abordada a nomenclatura utilizada na simulação, sendo de realçar que esta
não é única, no entanto a sua aceitação possui consenso geral.
Em contrapartida aos atributos existem as variáveis, que não estão ligadas a qualquer
entidade, ou seja, encontram-se definidas no sistema. As variáveis são fragmentos de
informação que refletem alguma característica do sistema, sendo possível de serem alteradas
pelas entidades. Podem ainda representar algo que se altere durante a simulação [KD 00].
8
Os recursos representam pessoas ou equipamentos, entre outros, que podem ser consumidos
por uma ou mais entidades, ao mesmo tempo. Normalmente, as entidades competem entre si
pelos recursos. O número de recursos pode diferir ao longo da simulação, e estes possuem
diferentes estados, tais como ocupado, disponível, bloqueado ou erro. Quando uma entidade
apreende o recurso, a entidade continua no sistema por algum tempo, e posteriormente liberta
o recurso. Em contrapartida, quando o consumo do recurso é negado, a entidade aguarda
numa fila ou é desviada para outro recurso [BJ 98] [KD 00].
As listas são utilizadas para representar filas. Normalmente seguem a estrutura FIFO (first in,
first out), ou seja, a primeira entidade a chegar é a primeira a ser processada. No entanto,
pode-se adotar outras estruturas de processamento, tais como LIFO (last in, firts out), ou seja
a última a entrar é a primeira a sair, sendo que o valor de um determinado atributo pode
contribuir para que tal se verifique [BJ 98] [KD 00].
Um conjunto de condições do sistema pode colidir num atraso temporal indeterminado. Tal
acontecimento pode ocorrer quando uma entidade se associa a uma fila de um recurso, sendo
que neste caso, o tempo que a entidade permanece na fila é indeterminado [BJ 98].
Estas ferramentas distinguem-se normalmente devido ao tipo de aplicação que focam. Por
exemplo, existem algumas plataformas de simulação específicas para robótica, como por
exemplo o RobotStudio e o SimTwo, outras para sistemas baseados em agentes evolutivos,
9
como Netlogo, Repast, Swarm e Mason, e outras mais direcionadas para processos
conduzidos por eventos, como ARENA, Delmia, ProcessModel e SIMPROCESS.
Cada uma destas plataformas apresenta características próprias assim como metodologias e
objectivos adequados ao domínio de aplicação. Este facto é ilustrado pela breve descrição que
é feita de seguida a duas plataformas de simulação.
10
e o comportamento são definidos em ficheiros XML, sendo que utiliza linguagem baseada em
XML, como analisador de expressões matemáticas internas para permitir a conceção de robôs
complexos. Neste ambiente, o robô é decomposto num sistema de corpos rígidos e motores,
ao qual se encontram associadas as suas propriedades físicas: forma, massa, inércia, atritos
das superfícies e elasticidades [CP 11].
Este simulador permite simular diferentes tipos de robôs, entre os quais: robôs móveis com
diferentes configurações (diferenciais ou com rodas omnidirecionais), manipuladores,
quadrúpedes, humanoides, dirigíveis (com ou sem hélices para propulsão) [CP 12].
O SimTwo utiliza várias bibliotecas Open Source, entre elas o GLScene, utilizado para
permitir a visualização 3D, o ODE que funciona como o motor de simulação de corpos
rígidos, o Pascal Script, que permite escrever código em pascal e posteriormente compilar, o
SynEdit, que implementa o editor de scripts, o OmniXml que realiza a configuração do
mundo, objetos e robôs da simulação em XML e o RxLib que permite que um conjunto de
componentes, tais como persistência, seja editável [CP 12].
Este simulador possui algumas limitações, entre elas o facto de apenas funcionar no sistema
operativo Windows e a degradação de desempenho com o aumento do número de objetos
utilizados, na medida em que o processamento é realizado de 40ms em 40ms.
Uma vez que o trabalho descrito neste documento aborda um caso de estudo relativo a
processos conduzidos por eventos, foi escolhido o software ARENA que é adequado a este
tipo de sistemas. No capítulo seguinte será realizada uma descrição deste software.
11
12
Capítulo 3
O ARENA® foi projetado para simular sistemas conduzidos por eventos e em particular para
analisar os impactos da introdução de alterações ao sistema real. A figura seguinte ilustra o
ambiente do software ARENA.
13
A grande vantagem do software ARENA®, reside no facto de possuir a facilidade de
utilização em simuladores de alto nível, com a flexibilidade das linguagens de simulação,
tudo isto na mesma interface gráfica. Isto deve-se ao facto de a modelação ser hierárquica,
permitindo a qualquer instante, utilizar a linguagem SIMAN em conjunto com os módulos de
nível mais alto de outro modelo. Se existir necessidade, como em algoritmos de decisão
complexos ou na recolha de dados de uma aplicação externa, podem-se inserir no modelo
pedaços de código em linguagens de programação de alto nível, como Visual Basic, C/C++
ou Java. O Arena possui integração com o Microsoft Office, ou seja, permite a leitura e
escrita de dados do Microsoft Office Excel e Microsoft Office Access [KD 00] [sn 07]. Possui
uma ferramenta adicional o Input Analyser extremamente rica para estudos de pós-otimização
[KD 00] [sn 07].
Em ARENA® as variáveis podem ser vetores ou matrizes, caso se pretenda recorrer a listas
ou tabelas bidimensionais para organizar a informação. Possui dois tipos de variáveis, as
internas e as definidas pelo utilizador. As variáveis internas dizem respeito ao número da fila,
ou ao tempo atual do relógio de simulação, entre outras. As variáveis definidas pelo utilizador
referem-se a variáveis, como a média de tempo de serviço, o tempo de viagem, entre outras
[KD 00] [sn 07].
Bloco/Módulo Funcionalidade
Criar entidades no modelo de simulação e identificar o tipo de entidade.
As entidades são criadas através de um cronograma ou com base no
tempo entre as chegadas.
14
Responsável por permitir a tomada de decisão de processos no sistema.
Contém opções para decidir com base em uma ou mais condições, ou
em uma ou mais probabilidades. As condições podem ser baseadas em
valores de atributos, valores de variáveis, segundo o tipo de entidade, ou
uma expressão.
Possui um mecanismo de agrupamento das entidades envolvidas no
modelo de simulação. A agregação poderá ser permanente ou
temporariamente agrupada. Quando temporária as entidades
posteriormente deverão ser divididas utilizando o módulo Separate.
Bloco/Módulo Funcionalidade
Responsável por “segurar” uma entidade numa fila até se verificar uma
determinada condição. Se a entidade se encontrar a realizar uma
determinada condição, esta deverá permanecer no bloco até a condição
se tornar verdadeira.
15
Retira unidades de um recurso, cuja entidade já foi capturada, ou seja,
permite libertar os recursos individualmente ou dentro de um conjunto.
Bloco/Módulo Funcionalidade
Responsável por informar quando uma entidade entra numa estação.
Possibilita a libertação de dispositivos de transporte, utilizados para
transportar uma entidade.
Permite transferir uma entidade para uma estação ou um módulo. Esta
poderá ser transferida de duas formas, ou para um módulo que define a
estação por referência, ou routing ou transporte, ou através de uma
ligação gráfica até outro módulo.
16
Responsável por definir uma estação, ou conjunto de estações, que
correspondem a uma determinada localização física ou lógica durante o
processamento.
Bloco/Módulo Funcionalidade
17
Liberta as células da entidade do Conveyor.
18
Figura 4 – Publicação de artigos.
Bloco/Módulo Funcionalidade
Configuration module Especifica o layout do centro de contato a ser simulado.
Define os nomes de contatos estudados pelo centro de
Contact module
contato.
Determina os padrões de chegada dos contatos dos nomes de
Pattern module
contato específicos.
Define os agentes do cento de contato. Cada grupo de
agentes é composto por agentes idênticos com base numa
Agent module
descrição genérica. Esta é definita por um período de tempo
de diálogo detalhado, juntamente com uma lista associada.
Define os períodos para os quais os agentes podem ser
Schedule module
atribuídos.
Especifica a recolha das estatísticas e geração dos relatórios
Report module
para os diferentes centros de contato.
Possibilita realizar em tempo real, a animação de estatísticas
Animate module
da simulação.
19
Em conclusão, a utilização do software ARENA permite de uma forma muito intuitiva
construir o modelo e a sua lógica de controlo, através da correta interligação de módulos e a
sua parametrização, além de fornecer uma GUI e saída de resultados que potenciam o
processo de simulação. Esta característica foi determinante para a escolha do ARENA no
presente trabalho.
20
Capítulo 4
4 Caso de Estudo
No presente capítulo, pretende-se descrever a linha de produção considerada como caso de
estudo neste trabalho, com o objetivo de auxiliar na compreensão do processo de produção de
máquinas de lavar roupa. Devido a questões de confidencialidade, a descrição da linha de
produção não será realizada de forma pormenorizada e serão ocultados os nomes reais das
estações e processos de trabalho.
21
Ao longo da linha de produção, todos os processos de manufatura demoram cerca de 29
segundos, expecto as reparações manuais, que ocorrem ao longo da linha de produção, assim
como a estação onde se realizam os testes de controlo de qualidade do produto no final da
linha (Functional Tests).
Figura 6 – Esquema que representa a junção de uma peça ao produto final (Marriage).
De forma análoga, após a peça passar pelo Processo #1.B irá para o Processo #2.B, onde
aguardará a chegada de uma peça proveniente do Processo #4.
Como mencionado anteriormente, num dado instante do processo de fabrico é realizado um
teste de controlo, em Processo #2.A, tal como é ilustrado na Figura 7.
22
Figura 7 – Esquema que representa o Teste de controlo (First Tests).
Pretende-se, com este teste, averiguar a qualidade do produto, ou seja, pretende-se verificar
se o produto possui alguma anomalia nesta fase da produção. Se o produto possuir alguma
anomalia, deverá ser encaminhado para outra estação de trabalho, a estação Processo #3.A,
onde se procederá à reparação do mesmo, na estação Processo #2.A. Esta reparação irá
demorar cerca de 20 minutos. Posteriormente, o produto volta a ser inserido na linha de
produção, para se proceder, novamente, ao mesmo teste de controlo. É importante realizar
este teste outra vez, para garantir que a reparação foi efetuada com sucesso.
Caso o produto não possua nenhuma irregularidade, ele segue o curso natural da linha de
montagem, seguindo para a próxima estação, Processo #4.A.
Na segunda linha de montagem, isto é a Washing Unit line 2A é realizado, de forma análoga,
o procedimento anteriormente descrito.
Durante o processo fabril podem-se observar duas linhas de montagem autónomas, exceto em
dois pontos da planta fabril. Estes pontos pretendem implementar dinamicamente o
reencaminhamento das paletes. Esta situação encontra-se representada na Figura 8.
23
Processo #2'
Processo #1.A Processo #3.A
Processo #2''
Processo #1.B
Neste caso, após o produto ser processado no Processo #1.A, poderá ser manufaturado pelo
Processo #2’ ou pelo Processo #2’’. Analogamente, após o produto passar pelo processo
Processo #1.B deverá passar pelo Processo #2’’ ou pelo Processo #2’’’. Para o Processo #3.A
apenas seguirá o produto oriundo do Processo #2’ ou do Processo #2’’. De forma
semelhante, o Processo #3.B processará as peças provenientes do Processo #2’’ ou do
Processo #2’’.
Desta forma, o Processo #2’’ constitui o elemento chave para reencaminhar paletes entre as
duas linhas de montagem.
O presente bloco, designado por Functional Tests, é um dos casos mais relevantes neste caso
de estudo, na medida em que é onde se realizam os testes finais de qualidade do produto.
Estes testes de qualidade são de elevada importância, visto que é o local onde o produto é
testado exaustivamente, permitindo, à fábrica aferir a qualidade do produto desenvolvido. A
Figura 9 ilustra o processo relativo a esta estação.
24
Figura 9 – Esquema que representa o Teste de Funcionalidade (Functional Tests).
Após o produto ser manufaturado pelo Processo #1.A e de seguida pelo Processo #2.A, chega
ao Processo #3.A, onde é realizado o teste de qualidade ao produto, referido anteriormente.
Este terá a duração de 6 minutos. Se o teste de qualidade for positivo o produto seguirá para o
Processo #5.A. Caso contrário, será processado no Processo #4.A, onde se procederá à sua
reparação, de forma manual, com um valor estimado de 6 minutos. Posteriormente, o produto
será reintroduzido na linha de montagem, para efetuar novamente o teste de qualidade. Caso o
produto volte a ser considerado inapto será encaminhado para a estação de reparação.
25
4.4 Testes de Certificação Avançada
Na reta final de todo o processo fabril, são realizados testes de certificação a um número
reduzido de máquinas de lavar roupa, cerca de 3% do total de produção. O teste de
certificação possui a duração de uma hora e trinta minutos, onde se encontram vinte máquinas
em funcionamento paralelo. Este processo encontra-se ilustrado na Figura 10.
Da análise da Figura 10, pode-se concluir que após o produto passar pelo Processo #1.A ou
pelo Processo #1.B, poderá seguir para o Processo #3.A ou Processo #3.B, respetivamente.
Em contrapartida, cerca de 3% do produto passará pelos testes de certificação (Processo #2),
e posteriormente serão encaminhados para o Processo #3.A ou Processo #3.B, sendo de
caracter preferencial o que se encontrar primeiro disponível.
26
Capítulo 5
27
Figura 12 – Criação de processos no sistema.
Tal como descrito anteriormente, uma situação particular é quando a palete chega a uma
estação, onde é necessário acrescentar uma nova peça à máquina em construção. A lógica de
controlo para esta situação encontra-se ilustrada na Figura 14.
28
A adição de uma nova peça à máquina em construção implica a criação de uma nova entidade
no sistema em causa. A criação de cada entidade será realizada de 29 em 29 segundos, sendo
que a primeira criação da mesma ocorre aos 150 segundos (sendo que anteriormente existe
um número de processos considerável, garante-se assim que apenas é criado o que será
consumido).
Após a criação da nova entidade, esta deverá ser sincronizada com a entidade já existente no
sistema. Para o devido efeito será necessário utilizar o bloco Match. Quando uma entidade
ingressa no bloco Match aguarda numa das filas que este possui, que no presente estudo são
apenas duas, pois a agregação é de dois produtos, até que a outra entidade presente no sistema
compareça na segunda fila, obtendo-se a combinação desejada. Posteriormente, as entidades
serão agrupadas, recorrendo ao bloco Batch. Esta agregação é permanente e a entidade
resultante da agregação segue para o próximo processo fabril.
O bloco Delay é utilizado para simular o tempo de processamento que uma máquina demora a
agregar os dois produtos. A sua utilização encontra-se representada na Figura 15.
29
Figura 16 – Configuração do bloco Decide.
A Figura 17 ilustra a lógica de controlo para a situação em que a palete chega à etapa de
controlo de qualidade, anteriormente designada por First Tests. Mais uma vez, esta é
modelada utilizando o bloco Process com a duração de 29 segundos.
30
Figura 18 – Reencaminhamento Dinâmico.
Após a peça ser manufaturada pelo bloco Process, dispõe de duas opções de progressão na
linha de montagem. Ou seja, ou segue para o processo, denominado de Processo #2’ ou para
o Processo #2’’. De modo a permitir a tomada de decisão dos processos no sistema, utilizou-
se o bloco Decide, sendo que a decisão é baseada numa probabilidade. Uma vez que, o
Processo #2’’ se encontra atualmente desativado, definiu-se para o primeiro Decide uma
probabilidade de ocorrência de 100% deste ser verdadeiro. O mesmo não se verifica no
segundo Decide, visto que a probabilidade de o Processo #2’’ ocorrer é de 0%, pois a peça
deverá ser processada pelo Processo #2’’’.
O Processo #2’’ apenas se encontra ativado, quando um ou dois processos que realizam a
mesma operação (Processo #2’ e Processo #2’’’) se danifiquem, permitindo assim que a
plataforma fabril se encontre permanentemente em produção. Caso o Processo #2’’ se
encontre ativo e realize operações é necessário posteriormente, verificar para qual dos
processos a máquina em produção deverá ir. Como tal, é necessário um terceiro bloco Decide,
permitindo, deste modo decidir para qual dos processos deverá prosseguir a peça. O critério
que será utilizado pelo sistema é o de decisão baseando-se numa probabilidade de 50%,
permitindo assim o balanceamento.
Quando uma entidade chega à estação do Functional Tests depara-se com uma estrutura
hierárquica, tal como ilustrada na Figura 19. Para o devido efeito foi utilizado o bloco
Process, mas com a opção de submodelo.
31
Figura 19 – Functional Tests.
No submodelo existem 18 máquinas aptas para realizar o teste de controlo de qualidade, que
poderão ser ativadas ou não, dependendo do cenário a simular. Segundo dados fornecidos
pela fábrica, atualmente apenas se encontram em trabalho contínuo 6 máquinas, onde o tempo
de processamento é de 6 minutos, sendo estes os valores utilizados para configurar os blocos
Process.
Neste sub-módulo, é possível observar que os blocos Decide foram colocados de forma a
balançar o sistema. As unidades, onde se realiza o teste de controlo, encontram-se modeladas
32
com o bloco Process, nele constam descritos os recursos consumidos e a durabilidade do
teste.
33
34
Capítulo 6
6 Análise de Resultados
O modelo computacional desenvolvido no capítulo anterior, foi testado em diferentes
cenários, de forma a ser possível observar quais as possíveis melhorias que se podem
introduzir na linha de produção que necessitam uma melhoria no seu desempenho. Os
diferentes cenários simulados permitirão compreender o impacto que determinadas estações
de trabalho possuem em toda a plataforma fabril.
A presente simulação foi realizada para um período de 15 dias. Tem como finalidade
identificar os problemas, existentes ao longo da linha de produção de máquinas de lavar
roupa. A Tabela 7 expõe sucintamente os dados do sistema real.
Parâmetros Valor/Unidade
Tempo de processamento normal 29 Segundos
Nº Máquinas em funcionamento (Funtional Testss) 6 Unidades
35
Tempo de processamento (Funtional Tests) 6 Minutos
Nº Máquinas em funcionamento (ZHQ) 20 Unidades
Tempo de Teste ZHQ 1 Hora e 30 Minutos
1ª Reparação Manual 20 Minutos
2ª Reparação Manual 6 Minutos
Após uma análise detalhada aos relatórios gerados pela aplicação, verificou-se que o
problema da presente linha de produção encontra-se na estação Functional Tests, na medida
em que as entidades ficam retidas nesta estação. De notar que apesar de possíveis seis
36
estações, o elevado tempo de inspeção em cada uma delas (quando comparado com o tempo
dos outros processos ao longo da linha) faz desta estação o elemento bottleneck da linha.
O gráfico da Figura 22 representa a relação do número de entidades que frequentaram a
estação Functional Tests da linha de montagem #1, num período de 15 dias. O
comportamento adotado pela segunda linha, na mesma estação, é semelhante.
37
Da análise da tabela 9 constata-se que o tempo que uma máquina tem que esperar para
realizar o teste de controlo de qualidade, é de cerca de 3,4 dias. O valor máximo que uma
entidade já esperou para realizar o teste de controlo é de aproximadamente 10,1 dias. Este
comportamento é pouco rentável e incomportável, uma vez que a realização do presente teste
de controlo de qualidade do produto é extremamente importante e obrigatória, pois permite à
empresa aferir a qualidade do produto.
De seguira, serão abordados diferentes cenários que poderão auxiliar na avaliação do impacto
que a estação Funtional Tests possui na linha de produção.
Parâmetros Valor/Unidade
Tempo de processamento normal 29 Segundos
Nº Máquinas em funcionamento (Funtional Tests) 6 Unidades
Tempo de processamento (Funtional Tests) 5 Minutos
Nº Máquinas em funcionamento (ZHQ) 20 Unidades
Tempo de Teste ZHQ 1 Hora e 30 Minutos
1ª Reparação Manual 20 Minutos
2ªReparação 6 Minutos
Por outro lado, o número de máquinas que se encontram na linha foi reduzido.
38
Tabela 11 – Relação de entidades no sistema com redução do tempo de processamento.
Nº Entidades
Entrada no Sistema 86.364
Saída do Sistema 50.221
Entidades Presas no Sistema 36.143
A Figura 23 representa a relação do número de entidades que passaram pela estação
Functional Tests, da primeira linha de manufatura, num período de 15 dias.
Como se pode observar o tempo de espera de uma entidade diminuiu. No entanto, embora
atenuado continua a existir e a crescer exponencialmente, o que significa que a longo prazo se
torna inexequível.
Figura 23 – Gráfico da 1ª linha da estação Functional Tests com tempo de processamento de 5 minutos.
Na tabela 12, verifica-se que o tempo que uma máquina tem que esperar para realizar o teste
de controlo de qualidade, diminuiu de 3,4 dias para 2,6 dias, ou seja diminuiu
aproximadamente um dia, em cada uma das linhas de produção. Observou-se ainda, uma
diminuição do tempo de espera máximo de uma entidade.
Tabela 12 – Dados da estação Functional Tests com redução do tempo de processamento.
Média Valor Mínimo Valor Máximo
(em dias) (em dias) (em dias)
Tempo de espera de uma entidade
2,587 0,000 9,138
no Functional Tests - 1ª Linha
Tempo de espera de uma entidade
2,582 0,000 9,240
no Functional Tests - 2ª Linha
Tempo que a entidade passa na 2,590 0,0035 9,142
39
estação Functional Tests - 1ª Linha
Tempo que a entidade passa na
2,586 0,0035 9,244
estação Functional Tests - 2ª Linha
Parâmetros Valor/Unidade
Tempo de processamento normal 29 Segundos
Nº Máquinas em funcionamento (Funtional Tests) 8 Unidades
Tempo de processamento (Funtional Tests) 6 Minutos
Nº Máquinas em funcionamento (ZHQ) 20 Unidades
Tempo de Teste ZHQ 1 Hora e 30 Minutos
1ª Reparação Manual 20 Minutos
2ªReparação 6 Minutos
40
Da análise do mesmo, pode-se verificar-se que embora o número de máquinas produzidas
tenha aumentado consideravelmente, o tempo de espera foi atenuado, mas não se encontra
impedido de crescer exponencialmente.
Figura 24 – Gráfico da 1ª linha da estação Functional Tests com alteração do n.º de máquinas para 8.
Da análise dos relatórios gerados pelo simulador pode-se observar que em média uma
entidade continua a esperar cerca de 2,6 dias, sendo que o valor máximo de espera,
documentado pelo software ronda os 5,4 dias, em ambas as linhas de produção.
O tempo que uma entidade permanece, na estação em estudo, é de em média 2,6 dias, sendo
que o maior valor registado pelo software encontra-se em cerca de 5,7 dias.
A tabela 15 expõe os dados referenciados anteriormente, entre outros.
Tabela 15 – Dados da estação Functional Tests com 8 máquinas em execução.
Média Valor Mínimo Valor Máximo
(em dias) (em dias) (em dias)
Tempo de espera de uma entidade no
2,593 0,000 5,409
Functional Tests - 1ª Linha
Tempo de espera de uma entidade no
2,590 0,000 5,463
Functional Tests - 2ª Linha
Tempo que a entidade passa na estação
2,5973 0,0042 5,463
Functional Tests - 1ª Linha
Tempo que a entidade passa na estação
2,5939 0,0042 5,468
Functional Tests - 2ª Linha
Uma vez que, a alteração realizada anteriormente não permitiu a otimização ambicionada para
o problema, mas obteve resultados positivos do ponto de vista do número de máquinas
41
produzidas. Foi considerado um novo cenário que contempla a existência das 18 estações no
functional tests (que existem na linha, mas não se encontram atualmente em funcionamento).
A tabela 16 ilustra o caso referenciado.
Parâmetros Valor/Unidade
Tempo de processamento normal 29 Segundos
Nº Máquinas em funcionamento
18 Unidades
(Funtional Tests)
Tempo de processamento (Funtional Tests) 6 Minutos
Nº Máquinas em funcionamento (ZHQ) 20 Unidades
Tempo de Teste ZHQ 1 Hora e 30 Minutos
1ª Reparação Manual 20 Minutos
2ª Reparação Manual 6 Minutos
A Tabela 17 ilustra os resultados obtidos sendo possível observar uma melhoria significativa
na produtividade da linham a qual agora não apresenta congestionamento.
Tabela 17 – Relação de entidades no sistema com 18 máquinas em execução.
Nº Entidades
Entrada no Sistema 86.364
Saída do Sistema 86.272
Entidades Presas no Sistema 92
O gráfico em baixo (Figura 25) permite observar que o número de entidades a entrarem em
produção é diretamente proporcional ao número de máquinas de lavar roupa produzidas.
Figura 25 – Gráfico da 1ª linha da estação Functional Tests com alteração do n.º de máquinas para 18.
42
Segundo os relatórios gerados pela aplicação, pode-se observar que os tempos de espera de
uma entidade, na estação Functional Tests, são insignificantes. O mesmo se verifica com o
tempo que uma entidade se mantém em teste dentro da presente estação.
Tabela 18 – Dados da estação Functional Tests com 8 máquinas em execução.
Média Valor Mínimo Valor Máximo
(em dias) (em dias) (em dias)
Tempo de espera de uma entidade no
0,0050 0,0003 0,0501
Functional Tests - 1ª Linha
Tempo de espera de uma entidade no
0,0059 0,0003 0,0662
Functional Tests - 2ª Linha
Tempo que a entidade passa na
0,0090 0,0034 0,0542
estação Functional Tests - 1ª Linha
Tempo que a entidade passa na
0,0101 0,0041 0,0700
estação Functional Tests - 2ª Linha
Este cenário de estudo possui, como principal objetivo, analisar o impacto que uma redução
do tempo de execução de cada processo terá na linha de produção. Assim considerou-se uma
diminuição de 29 segundos (valor atual na linha de produção) para 22 segundos, nos vários
processos ao longo da linha. A tabela 19 sintetiza os prossupostos assumidos para a realização
do presente cenário.
Parâmetros Valor/Unidade
Tempo de processamento normal 22 Segundos
Nº Máquinas em funcionamento (Funtional Tests) 6 Unidades
Tempo de processamento (Funtional Tests) 6 Minutos
Nº Máquinas em funcionamento (ZHQ) 20 Unidades
Tempo de Teste ZHQ 1 Hora e 30 Minutos
1ª Reparação Manual 20 Minutos
2ªReparação 6 Minutos
Após a simulação da aplicação desenvolvida, (ver tabela 20) são gerados automaticamente os
relatórios a analisar. Da observação destes, conclui-se que o cenário adotado, ao contrário do
esperado, é muito semelhante à primeira abordagem realizada. Ou seja, verificou-se que a
redução do tempo de processamento nas várias estações ao longo da linha não implica um
aumento de produtividade. Isto é justificado pelo fato de apesar de cada processo ser mais
rápido o congestionamento na estação Functional Tests mantem-se.
Tabela 20 – Relação de entidades no sistema com 22 segundos de tempo de processamento global.
Nº Entidades
Entrada no Sistema 86.368
Saída do Sistema 41.857
Entidades Presas no Sistema 44.511
43
A Figura 26 caracteriza a relação do número de entidades que frequentaram a estação
Functional Tests (primeira linha de produção), num período de 15 dias. Da análise do gráfico
concluísse que o tempo de espera foi reduzido, mas não se encontra extinto, ou seja continua a
crescer exponencialmente.
Figura 26 – Gráfico da 1ª linha da estação Functional Tests com variação do tempo total de
processamento.
Da observação dos relatórios gerados pelo simulador pode-se verificar que em média uma
entidade espera aproximadamente 3,4 dias, para realizar o teste de controlo de qualidade, em
ambas as linhas de montagem. O maior valor registado de espera é de aproximadamente 10
dias. Segundo os valores registados pela aplicação não ocorreu uma diferença significativa em
relação ao sistema real.
Tabela 21 – Dados da estação Functional Tests com 22 segundos de tempo de processamento global.
Média Valor Mínimo Valor Máximo
(em dias) (em dias) (em dias)
Tempo de espera de uma entidade no
3,3929 0.0000 10.1619
Functional Tests - 1ª Linha
Tempo de espera de uma entidade no
3,4030 0.0000 10.1324
Functional Tests - 2ª Linha
Tempo que a entidade passa na
3,3971 0,0042 10,1661
estação Functional Tests - 1ª Linha
Tempo que a entidade passa na
3,4072 0,0042 10,1366
estação Functional Tests - 2ª Linha
44
O presente cenário apenas veio corroborar a conjetura, abordada anteriormente, de que o
principal problema da linha de produção de máquinas de lavar se encontra na estação
Functional Tests. Aconselha-se assim a realização de um estudo de investigação que permita
diminuir a duração do teste de controlo de qualidade e ao mesmo tempo verificar a
possibilidade de aumentar o número de máquinas na execução do referido testem através da
re-activação de estações existentes mas não em funcionamento.
45
46
Capítulo 7
7.1 Conclusões
Do estudo elaborado para a linha de produção de máquinas de lavar roupa, que envolveu a
conceção do modelo e lógica de controlo e a sua simulação em diferentes cenários, diversas
conclusões foram extraídas.
47
Assim, verificou-se que a estação Functional Tests, o elemento congestionados da atual linha
limitando a sua produtividade. A análise da simulação de vários cenários permitiu elaborar
recomendações para a empresa e passam pelo estudar a possibilidade de redução do tempo de
processamento do teste e aumento do número de estações teste.
Num estudo futuro, poderá também incluir-se os custos de cada processo fabril, assim como,
mão-de-obra, recursos materiais, entre outros.
O presente estudo pode ser completado interligando-o a uma base de dados, recebendo dados
on-line, e posteriormente simulando utilizando esses dados. Assim, baseando-se no histórico
de produção será possível simular o que acontecerá com um rigor e exatidão superiores.
48
Referências bibliográficas
[AT 07] Altiok, Tayfur. Simulation Modeling and Analysis with Arena. Elsevier – 2007.
[BA 07] Brandley, Allen. Arena Contact Center. Rockwell Automation – Novembro de 2007.
[BJ 98] Banks, Jerry.Handbook of Simulation – Principles, Methodology, Advances, Applications, and
Practice. JOHN WILEY & SONS, LDA – 1998.
[CJ 98] Costa, J. Almeida. Dicionário da Língua Portuguesa. Porto Editora – 8ª edição, 1998.
[CP 11] Costa, Paulo; Gonçalves, José; Lima, José; Malheiros, Paulo. SimTwo realistic simulator: a
tool for the development and validation of robot software – 2011.
[CP 12] http://paginas.fe.up.pt/~paco/wiki/index.php?n=Main.SimTwo - Agosto 2012.
[KD 00] Kelton, W.David. Simulation with Arena, Third Edition – International Edition. McGraw-Hill
– 2000.
[LA 03] Law, Averill M. Simulation Modeling and Analysis, Third Edition. McGraw-Hill – 2003.
[NL 12] http://ccl.northwestern.edu/netlogo/ - Agosto 2012.
[PC 95] Pegden, C. Dennis. Introduction to Simulation Using SIMAN – Second Edition. McGraw-Hill
– 1995.
[sn 07] Arena® User’s Guide. Rockwell Automation – Novembro de 2007.
[TK 95] Tumay, Kerim. Business Process Simulation. Winter Simulation Conference – 1995.
[Wiki 2012a] http://en.wikipedia.org/wiki/Monte_Carlo_method - Agosto 2012.
[Wiki 2012b] http://en.wikipedia.org/wiki/Simula - Agosto 2012.
49
50
Anexo A
51