You are on page 1of 67

Centro Universitário do Sul de Minas – UNIS-MG

Bacharelado em Ciência da Computação

O Software ARENA

Juliano Coelho Miranda

Aimée Piedade Silveira


Cristiane Rodrigues da Silva
Daiana Guimarães Belarmino

Varginha, 2006
2

Centro Universitário do Sul de Minas – UNIS-MG

Bacharelado em Ciência da Computação

O Software ARENA

Projeto de Conclusão de Curso


apresentado ao programa do curso de
Bacharelado em Ciência da Computação do
Centro Universitário do Sul de Minas, como
requisito parcial para a obtenção do título de
Bacharel em Ciência da Computação.

Varginha, 2006
3

FOLHA DE APROVAÇÃO

AIMÉE PIEDADE SILVEIRA


CRISTIANE RODRIGUES DA SILVA
DAIANA GUIMARÃES BELARMINO

O Software ARENA

Monografia apresentada ao curso de Ciência da Computação do Centro Universitário


do Sul de Minas – UNIS/MG, como pré-requisito para obtenção do grau de (bacharel ou
licenciatura) pela Banca Examinadora composta pelos membros:

( ) Aprovado

( ) Reprovado

Data 28/11/2006

_________________________________________________________
Profº. Juliano Coelho Miranda

______________________________________________________
Profº. Fabrício Pelloso Piurcosky

_________________________________________________________
Profº. Alan Souza Prado
4

Dedicamos o presente trabalho


às nossas famílias e amigos que nos apoiaram
mesmo nos momentos em que não pudemos estar presentes.
E a todos aqueles que farão uso dele
como base para outros projetos.
5

Agradecemos em primeiro lugar a Deus


que nos fortaleceu, abençoou e
iluminou. Agradecemos também às
nossas famílias que sempre estiveram
conosco apoiando e ajudando, pois sem
eles não poderíamos estar concluindo
mais essa importante etapa de nossas
vidas. Aos amigos pelo incentivo,
alegria e força, mesmo nos momentos
em que estávamos desanimadas. E ao
professor Juliano Coelho Miranda que
com toda atenção nos orientou.
6

SUMÁRIO

1. INTRODUÇÃO........................................................................................ 11
1.1 Objetivos.........................................................................................................................12
1.1.1 Geral................................................................................................................... 12
1.1.2 Específicos......................................................................................................... 12
1.2 Justificativa.................................................................................................................... 12
2. SIMULAÇÃO.......................................................................................... 14
3. TEORIA DE FILAS................................................................................. 22
4. ARENA................................................................................................... 28
4.1 Histórico do ARENA....................................................................................................... 28
4.2 O Software......................................................................................................................29
4.3 Templates....................................................................................................................... 33
4.4 Funcionalidades do ARENA........................................................................................... 42
4.5 Exemplo 1: Batch........................................................................................................... 43
4.6 Exemplo 2: Pedágio....................................................................................................... 46
5. CONCLUSÃO......................................................................................... 52
5.1 Dificuldades Encontradas............................................................................................... 52
5.2 Trabalhos Futuros.......................................................................................................... 53
6. REFERÊNCIAS BIBLIOGRÁFICAS...................................................... 54
7. APÊNDICES........................................................................................... 56
7.1 Apêndice 1: Exemplo da Costura................................................................................... 56
7.2 Apêndice 2: Exemplo Choose........................................................................................ 61
7.3 Apêndice 3: Relatórios Gerados no Exemplo da Costura.............................................. 67

LISTA DE TABELAS

Tabela 3.1: Variáveis de um Sistema..................................................... 25


Tabela 3.2: Resumo de fórmulas usuais em Teoria de Filas............. 25
7
8

LISTA DE FIGURAS

Figura 2.1: Exemplo de simulação de um pátio de carga..................... 14


Figura 2.2: Demonstração do uso da simulação....................................16
Figura 3.1: Exemplo do funcionamento de uma fila....................... 22
Figura 3.2: Elementos que compõem a fila....................................... 24
Figura 4.1: Interface Principal do Software ARENA.............................29
Figura 4.2: Demonstração dos Blocos......................................... 31
Figura 4.3: Formulário criação da entidade............................ 34
Figura 4.4: Formulário do Bloco Process..................................... 35
Figura 4.5: Configuração do Bloco Decide.......................................... 36
Figura 4.6: Formulário do Bloco Batch.................................................. 37
Figura 4.7: Formulários do Bloco Assign.............................................. 38
Figura 4.8: Formulário do Bloco Pickstation........................................ 39
Figura 4.9: Formulário do Bloco Server............................................. 40
Figura 4.10: Formulário para inserção ou alteração das figuras..........41
Figura 4.11: Configurações do Bloco Inspect........................................ 42
Figura 4.12: Representação do exemplo Batch ................................... 44
Figura 4.13: Bloco Batch e a Fila das Peças.......................................... 45
.................................................................................................................... 46
Figura 4.15: Segundo Bloco Assign........................................................ 46
Figura 4.16: Funcionamento da simulação de um pedágio................ 46
Figura 4.17: Montagem dos Blocos e do Cenário................................. 47
Figura 4.18: Configuração do Bloco Pickstation................................... 48
Figura 4.19: Configuração do Bloco Enter......................................... 49
.................................................................................................................... 49
Figura 4.20: Configuração da Station..................................................... 49
.................................................................................................................... 50
Figura 4.21: Recurso de localização de imagem ..................................50
Figura 4.22: Representação do servidor........................ 50
Figura 4.23: Inserção de uma variável............................. 51
Figura 7.1: Representação do Sistema............................................. 56
Figura 7.2: Localização dos templates na tela inicial do
ARENA....................................................................................................... 57
Figura 7.3: Estação Arrive............................................................... 57
Figura 7.4: Estação Server....................................................................... 58
Figura 7.5: Estação Inspect .............................................................. 59
Figura 7.6: Estação Simulate................................................................... 60
9

Figura 7.7: Server...................................................................................... 60


Figura 7.8: Conexão entre estações........................................................ 61
Figura 7.9: Funcionamento do Exemplo Choose................................... 61
Figura 7.10: Inserção dos dados no Bloco Create................................. 62
Figura 7.11: Inserção dos dados no Bloco Enter................................... 63
Figura 7.12: Inserção dos dados no Bloco Decide................................ 64
Figura 7.13: Inserção dos dados no Bloco Process.. 65
Figura 7.14: Inserção dos dados no Bloco
Assign........................................................................................................ 65
Figura 2.7: Inserção dos dados no Bloco Leave
.................................................................................................................... 66
Figura 2.8: Inserção dos dados no Bloco Dispose............................... 66
10

RESUMO

A simulação é uma técnica a disposição dos profissionais que atuam em


diversas áreas, desde a biologia às áreas das ciências exatas como engenharia.
Baseia-se na construção de um modelo matemático para representar o sistema a ser
avaliado. Simular requer mais do que simplesmente conhecimentos de como usar um
software de simulação, um estudo de simulação é, por sua natureza, um projeto maior.
Como qualquer projeto, há tarefas para serem completadas e recursos que são
exigidos para completá-las. Para um projeto de simulação ser bem sucedido, este tem
que ser planejado com um entendimento das exigências de cada uma das tarefas
envolvidas. Este projeto foi desenvolvido na área de simulação de sistemas, a fim de
apontar os aspectos principais do software ARENA, e sua aplicabilidade nos estudos de
caso. O ARENA é uma ferramenta poderosa e flexível, que permite ao analista criar
modelos de simulação animados, que representem virtualmente qualquer sistema,
como por exemplo, o número necessário de atendentes de um call center ou de um
banco, o tempo de atendimento ou de permanência na fila etc., além de permitir que
sejam criados modelos customizados. Porém, são escassos os materiais que detalhem
o uso desta ferramenta, sendo assim muitos os usuários que não conseguem explorar
todo o potencial do software.
11

1. INTRODUÇÃO

Problemas de dimensionamento ou fluxo podem ocorrer ao efetuar estudos


de planejamento, cuja solução é aparentemente complexa, pois o objetivo do
planejamento é alcançar um funcionamento com custo adequado e usuários satisfeitos.
O estudo destes planejamentos é denominado modelagem de sistemas.
Dentre as técnicas disponíveis para a modelagem de sistemas temos a teoria
de filas, método que aborda o assunto através de fórmulas matemáticas; e a simulação,
que é mais utilizada e permite imitar o funcionamento de um sistema real. Usando o
computador digital a simulação procura montar um modelo que melhor represente o
sistema em estudo (PRADO, 1999).
A partir da década de 80 a simulação passou a explorar o potencial do
computador pessoal e surgiu a chamada simulação visual, ou seja, desenhos em
perspectiva, modelos tridimensionais, fotografia ou outras técnicas de representação
gráfica ou visual que ajude a simular paisagens reais ou projetadas, em diferentes
condições e pontos de vista. Existem hoje inúmeros programas com esta habilidade,
dentre os quais destaca-se o ARENA.
O ARENA foi lançado em 1993 e, possui um conjunto de blocos que são
utilizados para descrever uma aplicação real. Além de permitir a construção de modelos
de simulação o ARENA possui ainda, as seguintes ferramentas: analisador de dados de
entrada, analisador de resultados, visualizador da simulação e execução em lotes
(PRADO, 1999).
Diante da evidência de que os próprios usuários da informática apresentam
dificuldade na utilização do software ARENA, foi proposto desenvolver um projeto
visando esclarecer o uso direcionado desta ferramenta, mostrando cada fase do
processo de simulação (input e output de dados) e também a interpretação dos
resultados parametrizando as configurações necessárias para utilização do software
ARENA em estudos de caso.
12

1.1 Objetivos

1.1.1 Geral

O objetivo do projeto é demonstrar a metodologia, o uso e os resultados da


parametrização do software de simulação ARENA em estudos de caso.

1.1.2 Específicos

• Mostrar cada fase do processo de simulação (input e output de dados);


• Parametrizar as configurações necessárias para utilização do software
ARENA em estudos de caso.

1.2 Justificativa

As possibilidades de simulação podem contribuir para o desenvolvimento de


modelos adequados para raciocínio e compreensão, que sustentem a generalidade de
relações pertinentes e permitam dar significado as expressões matemáticas que são
utilizadas para descrever o comportamento de um sistema. Para isso, é necessário
começar a análise das variáveis didáticas que devem ser consideradas ao incluir o
software de simulação, esta análise a priori é fundamental para logo implantar a
situação. A simulação é interessante porque permite demonstrar um fenômeno em
diferentes pontos de vista, de modo mais simples e direto que a experiência em
laboratório, sendo que as limitações e o caráter não probatório das simulações devem
ser tratados com cuidado. A partir do software de simulação ARENA, é possível
implementar um modelo e avaliá-lo imediatamente, modificando-o a partir dos
desajustes detectados, realizando novas predefinições e voltando a executá-lo até que
o resultado seja satisfatório. A execução recursiva é uma propriedade essencial dos
modelos mentais e está associada ao requisito de funcionalidade dos mesmos. A
realização e desenvolvimento do projeto se deram devido à escassez de material que
13

detalhe de forma clara e objetiva o uso das ferramentas do software de simulação


ARENA, que, por sua vez, é uma ferramenta muito usada pelos profissionais da
informática, engenheiros dentre outros. Porém, o uso e a adequação para seu
manuseio nem sempre é motivo de sucesso, pois a manipulação do seu conteúdo não
é simples e, exige conhecimento para que o resultado final seja satisfatório, já que o
potencial do software é vasto e oferece muitos recursos para simulação.
14

2. SIMULAÇÃO

A simulação trata-se de uma ferramenta de planejamento, disponibilizada


pela área de pesquisa operacional1 que permite a geração de cenários, a partir dos
quais pode-se: orientar o processo de tomada de decisão, proceder análises e
avaliações de sistemas e propor soluções para a melhoria de performance. Sendo que,
todos estes procedimentos podem ter por conotação parâmetros técnicos e, ou,
econômicos (ARAÚJO, 2006).
A simulação permite que você experimente no computador um modelo do seu
sistema num curto espaço de tempo, propiciando a você uma capacidade de tomada de
decisões que é impossível através de qualquer outra tecnologia (HARREL, 2000).
Simulação é o processo de elaborar modelos de sistema real e de conduzir
experimentos, com a finalidade de compreender o comportamento do sistema ou de
avaliar as possíveis estratégias para operação do sistema (SALIBY, 1998).

Figura 2.1: Exemplo de simulação de um pátio de carga


Para Polari (2006), simulação é uma técnica que permite imitar o
funcionamento de um sistema real. Se o modelo dos componentes é correto, você pode
1 Pesquisa Operacional: é a aplicação de métodos científicos para a melhor gestão de sistemas organizados governamentais, comerciais e industriais. Distingue-se da engenharia operacional por enfocar
sistemas nos quais o comportamento humano é importante.
15

determinar com precisão os valores das grandezas importantes para o circuito


previamente determinado. Ou seja, para um circuito com componentes especificados,
você é capaz de dizer com precisão qual será seu desempenho, e qual será seu
comportamento sob variações das condições de operação (temperatura etc.).
Ao longo dos anos o uso de simulação se difundiu para as mais diferentes
áreas de aplicações, causando deste modo um crescimento considerável na
complexidade das simulações bem como no volume de dados gerados e que devem
ser analisados pelos usuários. Com isto, a interpretação dos resultados das simulações
se tornou uma tarefa muito dispendiosa e muitas vezes cansativa e improdutiva. Este
fato deu início às pesquisas visando o desenvolvimento de ferramentas que
permitissem uma melhor compreensão dos dados, através de apresentações mais
eficientes para a análise dos mesmos.
O processo de construção de um modelo de um sistema real e a condução
de experiências com esse modelo, com o objetivo de compreender o comportamento do
sistema e/ou avaliar estratégias para a sua operação, é a definição da Paragon (2006)
para simulação.
Em computação, simulação consiste em empregar técnicas matemáticas em
computadores com o propósito de imitar um processo ou operação do mundo real.
Desta forma, para ser realizada uma simulação, é necessário construir um modelo
computacional que corresponda à situação real que se deseja simular.
São alguns casos clássicos que justificam a simulação:
• Para descrever o comportamento de um sistema: a simulação pode ser
usada para mostrar como um sistema funciona, ao contrário de como
as pessoas acreditam que funcione.
• Quando experimentar é dispendioso: em casos em que uma
experiência real seria onerosa, a simulação pode oferecer bons
resultados sem a necessidade de grandes investimentos.
• Quando fazer testes reais não é adequado: por exemplo, é arriscado
experimentar o sistema de contingência de uma usina nuclear.
A simulação é uma abordagem geral para o estudo de problemas, geralmente
complexos, para os quais não se dispõe de solução analítica. Num contexto mais
16

amplo, a simulação refere-se à construção de modelos de qualquer natureza (físicos,


matemáticos, sistemas produtivos e de distribuição) e simulação de cenários para o
apoio à tomada de decisão. Em termos mais práticos, a simulação consiste na
construção de um modelo de um sistema real (ou ainda por existir) e, através do uso do
computador, possibilitar a realização de experimentos com vários cenários deste
modelo. É uma ferramenta de auxílio na avaliação de sistemas fornecendo uma melhor
compreensão em lugar de gerar simplesmente uma solução. Com o crescimento da
complexidade dos problemas reais e a evolução dos sistemas computacionais, a
simulação aparece como uma ferramenta cada vez mais utilizada nas mais variadas
áreas de conhecimento.

Figura 2.2: Demonstração do uso da simulação

Com os avanços na área de informática, modernos equipamentos e novas


linguagens de programação e de simulação têm permitido empregar a técnica de
simulação nas diversas áreas do conhecimento humano, fatos que têm propiciado:
projetar e analisar sistemas industriais, avaliar performance de hardware e software em
sistemas de computação, analisar desempenho de armas e estratégias militares,
determinar freqüência de pedidos de compra para recomposição de estoques, projetar
17

e administrar sistemas de transportes como: portos e aeroportos, e configurar sistemas


de atendimento em hospitais, supermercados e bancos (ARAÚJO, 2006).
Prado (1999) afirma que os modelos matemáticos de simulação, ou
simplesmente modelos de simulação, podem ser classificados em:
• Estáticos ou Dinâmicos: denominam-se como modelos estáticos os que visam
representar o estado de um sistema em um instante ou que em suas
formulações não se leva em conta a variável tempo, enquanto os modelos
dinâmicos são formulados para representarem as alterações de estado do
sistema ao longo da contagem do tempo de simulação.
• Determinístico ou Estocástico: são modelos determinísticos os que em suas
formulações não fazem uso de variáveis aleatórias, enquanto os estocásticos
podem empregar uma ou mais.
• Discretos ou Contínuos: são modelos discretos aqueles em que o avanço da
contagem de tempo na simulação se dá na forma de incrementos cujos valores
podem ser definidos em função da ocorrência dos eventos ou pela determinação
de um valor fixo, nesses casos só é possível determinar os valores das variáveis
de estado do sistema nos instantes de atualização da contagem de tempo;
enquanto para os modelos contínuos o avanço da contagem de tempo na
simulação dá-se de forma contínua, o que possibilita determinar os valores das
variáveis de estado a qualquer instante.
Para Prado (1999), hoje, a simulação é difundida nos países de primeiro
mundo, em grandes companhias, principalmente nas áreas de produção, manufatura,
armazenamento e transporte. No mercado encontram-se disponíveis diversos
simuladores para aplicações gerais e específicas, tais como: meteorologia, call centers,
treinamento, pilotagem de veículos ou aviões. Mesmo estudos aerodinâmicos, antes
feitos por meio de maquetes, agora podem ser realizados utilizando-se a simulação
dinâmica no computador. Sendo assim, a simulação é a reprodução do funcionamento
de um sistema com o auxílio de um modelo, o que nos permite testar algumas
hipóteses sobre o valor das variáveis controladas. As conclusões obtidas da
comparação com o mundo real são usadas então para melhorar o desempenho do
sistema em estudo.
18

A simulação é um tipo particular de modelo matemático de um sistema.


Desse modo, as implementações de modelos matemáticos de simulação a serem
utilizados em computadores requerem o uso das linguagens de programação como
FORTRAN, C++ , PASCAL ou das linguagens de simulação como SLAM, GPSS,
GASP, SIMSCRIPT, POWERSIM, SIMAN, ARENA, PROMODEL, AUTOMOD,
TAYLOR, EXTEND, etc (BANKS, 1995).
Segundo Pegden (1990), criador do software de simulação ARENA, a
simulação é uma das mais poderosas ferramentas de análise disponíveis para os
responsáveis por projeto e operação de processos complexos ou sistemas. Em um
mundo de crescente competitividade, simulação se tornou uma ferramenta muito
poderosa para planejamento, projeto e controle de sistemas. Não mais renegado ao
posto de “último recurso”, hoje ela é vista como uma metodologia indispensável de
solução de problemas para engenheiros, projetistas e gerentes.
Devido às deficiências próprias dos modelos analíticos, há várias razões
para o uso da simulação, tais como (ARAÚJO, 2006):
• Indisponibilidade de modelos analíticos;
• Complexidade de modelos analíticos;
• Resultados estatísticos de modelos analíticos são insuficientes;
• Modelos analíticos só fornecem médias, não evidenciam a variabilidade e os
extremos;
• Modelos analíticos não podem identificar os “gargalos” de processo ou
recomendar mudanças de projeto;
• Modelos analíticos freqüentemente não fornecem detalhes suficientes nem
podem identificar interações;
• Animação é um melhor método para demonstrar resultados para administração.
Conforme Silva (2002), uma das tarefas mais árduas em simulação está em
determinar se o modelo proposto retrata com fidedignidade o sistema em estudo. Para
o alcance desta meta são recomendadas as observâncias de três preceitos básicos,
que são: verificação, validação e implementação de confiabilidade. Esses preceitos
devem ser observados nas várias fases do desenvolvimento de um modelo, deste
modo, tem-se que:
19

• Verificação: trata-se de um conjunto de ações para certificar se a forma


conceitual adotada na formulação do modelo foi transcrita corretamente ao
utilizar-se das linguagens de programação ou de simulação. Recomenda-se
na condução deste procedimento: usar duas ou mais pessoas; rodar o
programa para um conjunto variado de situações procedendo a análises
dos dados de saída; rastear o programa verificando a execução dos
procedimentos; observar a animação; e comparar os valores gerados pelo
uso de distribuições aos observados em sistemas reais.
• Validação: é uma coletânea de ações utilizadas para analisar se um dado
modelo representa com fidedignidade o sistema em estudo. Podendo este
procedimento ser conduzido em conjunto com a verificação, fato que
imprimirá maior confiabilidade ao modelo. A validação pode ser
categorizada em estatística e subjetiva. A estatística consiste no emprego
de ferramentais como: análise de variância, determinação de intervalo de
confiança, testes de hipótese, ajustamento de curvas, análises de regressão
e análises de séries temporais. Enquanto a subjetiva é recomenda quando
não há possibilidade de proceder incursões exploratórias aprofundadas
sobre o sistema em estudo. Para estes casos, pode ser utilizado, por
exemplo, o Teste de Turing. Este teste consiste na exposição das
informações geradas pelo modelo e às obtidas do sistema real em um
mesmo formato. Posteriormente, submetem-se estas a análise de um grupo
conhecedor do sistema. Caso não haja consenso entre eles, quanto à
definição da origem das informações, é indicativo que o modelo está
validado. Outra forma deste tipo de validação dá-se por análises de
especialistas, os quais procedem ao julgamento do modelo, segundo
lógicas associadas ao sistema em estudo.
• Implementação de confiabilidade: conforme citações em literaturas
especializadas, para a obtenção de modelos validados e confiáveis deve-se
ater aos seguintes preceitos:
1- Desenvolver modelos interativos com os potenciais usuários.
20

Desde modo, deve-se: constatar os termos técnicos usuais, coletar dados


relevantes a serem utilizados no desenvolvimento do modelo, utilizar teorias
existentes relativas o sistema em estudo, analisar outros modelos
desenvolvidos anteriormente e dotar de experiência e intuição na
formulação do modelo.
2- Testar as considerações empíricas utilizadas.
Um dos ferramentais mais poderosos para a condução desse passo é a
realização de análises de sensibilidade. Deste modo, certifica-se como os
resultados da simulação são impactados mediante alterações dos valores
das variáveis de entrada e parâmetros do sistema.
3- Determinar o quanto os dados gerados são representativos.
Este é um dos procedimentos decisivos na validação, o qual consiste na
confrontação das informações geradas pelo modelo com as obtidas do
sistema real. O nível de precisão irá depender dos propósitos de utilização
do modelo. Ressalta-se, que para o emprego da estatística clássica deve-se
seguir as regras de aplicação.
Os resultados da simulação dependem da fidelidade com que o modelo
representa o sistema real - modelos mal formulados fatalmente produzirão resultados
incompatíveis com o objetivo do problema, levando o usuário a tomadas de decisões
totalmente equivocadas. A partir do modelo validado podem ser testadas possíveis
mudanças ou melhorias no sistema antes de realizá-las fisicamente. A simulação
permite também que as pessoas envolvidas em processos de tomada de decisão
aumentem o nível de conhecimento sobre o sistema ou estudem causas de problemas
a partir da análise do funcionamento do mesmo em diferentes condições.
Falhas são resultados de atos precipitados dentro de um estudo de
simulação, atos realizados sem primeiro considerar os passos envolvidos e sem
desenvolver um plano para o procedimento de realização do estudo. A modelagem de
simulação requer boa habilidade analítica, estatística, de comunicação em organização
e em engenharia. O modelador deve entender do sistema analisado e ser hábil para
escolher através do complexo relacionamento de causa e efeito o que determinará a
execução do sistema. Os fundamentos básicos em estatística são necessários para,
21

apropriadamente, se projetar experimentos e, corretamente, analisar e interpretar dados


de entrada e saída. Quando em comunicação com os requisitantes, durante um estudo
de simulação, é também vital assegurar que o modelo proposto seja utilizado e que
todos entendam os objetivos, suposições e resultados do estudo.
Se forem seguidos os passos que foram esboçados, as chances de se
executar um projeto de simulação bem sucedido são muito boas. As razões típicas
pelas quais os projetos de simulação falham é porque deixam de incluir o seguinte:
• Falta de clareza nos objetivos iniciais;
• Falta de envolvimento de pessoas dispostas a obter resultados;
• Orçamento excessivo e restrição de tempo;
• Falta de documentação e de ter um consenso sobre os dados de saídas;
• Inclusão de mais detalhes do que o necessário;
• Inclusão de variáveis que têm pouco ou nenhum impacto sobre o
comportamento do sistema;
• Falha na verificação da validade do modelo;
• Basear decisões sobre uma única corrida de observações;
• Basear decisões sobre média estatística quando a saída é realmente
cíclica;
• Ser muito técnico e detalhado na apresentação dos resultados ao gerente.
Um projeto de simulação tem fases distintas que devem ser entendidas e
seguidas no sentido de que o estudo seja bem sucedido. As exigências/objetivos
estabelecidas para o estudo de simulação devem ser cuidadosamente planejadas com
metas realistas e perspectivas. Os passos para executar um estudo de simulação
incluem: planejar o estudo, definir o sistema, construir o modelo, conduzir os
experimentos, analisar as saídas e apresentar os resultados. Seguindo
sistematicamente estes passos, será possível evitar as armadilhas que freqüentemente
ocorrem quando se realiza um estudo de simulação (INCUBADORA, 2006).
22

3. TEORIA DE FILAS

A Teoria de Filas iniciou-se no princípio do século XX em Copenhague,


Dinamarca, com A.K. Erlang, estudando o problema de redimensionamento de centrais
telefônicas. A partir da 2º Guerra Mundial foi aplicada a outros problemas de filas
(PRADO, 1999).
A Teoria de Filas é um conjunto de teoremas envolvendo cálculos
probabilísticos que explica o comportamento de atendimento a serviços enfileirados (o
que envolve variáveis randômicas).
O estudo de Teoria de Filas trata o fenômeno de aguardar em fila usando
medidas representativas da performance do sistema, tais como comprimento médio da
fila, tempo médio de espera na fila, utilização média do sistema entre outros. Este
estudo faz parte da área de pesquisa operacional e está ligado aos processos
estocásticos. Processo estocástico é aquele no qual as mudanças de estado, ligadas
por leis de probabilidade, sucedem-se em intervalos de tempos determinados ou
aleatórios. O problema das filas de espera está em ajustar adequadamente a taxa de
atendimento do processo à demanda de clientes atendidos numa unidade de tempo
(POLARI, 2006).
Para Costa (2006), a Teoria das Filas tenta através de análises matemáticas
detalhadas encontrar um ponto de equilíbrio que satisfaça o cliente e seja viável
economicamente para o provedor do serviço. Um sistema de filas pode ser descrito
como clientes chegando, esperando pelo serviço, se não forem atendidos
imediatamente, e saindo do sistema após serem atendidos. O termo cliente é usado de
maneira geral e não implica necessariamente num cliente humano.

Figura 3.1: Exemplo do funcionamento de uma fila


23

A Teoria das Filas foi desenvolvida para prover modelos que retratem
previamente o comportamento de um sistema que forneça serviços que possuam
demandas que aumentem aleatoriamente. Existem muitas aplicações respeitáveis da
teoria, a maioria das quais tem sido documentadas na literatura de probabilidade,
pesquisa operacional e engenharia industrial. Alguns exemplos são fluxo de tráfego
(veículos, aeronaves, pessoas, comunicações), escalonamento (pacientes em
hospitais, jobs em máquinas, programas em computadores) e projetos de atendimentos
à serviços (bancos, correios, parques de diversão, restaurantes fast-food).
A abordagem matemática de filas se iniciou em 1908, que contribuiu para o
desenvolvimento científico com o seu trabalho na teoria de tráfego de telefonia
ganhando reconhecimento internacional.
As filas estão presentes no dia-a-dia, mas nem por isso elas são
“simpáticas”. Nos sistemas produtivos também observamos as filas, tais como: uma fila
de caminhões aguardando o carregamento de produtos ou uma fila de pedidos
aguardando o atendimento (ERLANG, 2006).
O sistema de filas é caracterizado por três componentes: processo de
chegada, processo de atendimento e disciplina da fila (LAW, 2000).
São elementos das filas, segundo Prado (1999):
• População: a origem das entidades.
• Entidade: o mesmo que cliente ou transação. É o elemento que está sujeito à
fila (ex.: ordem de trabalho, pessoas, peças em uma linha de montagem).
• Servidor: o mesmo que atendente ou canal de serviço (ex.: torneiro, médico,
telefonista).
• Serviço: ato ou efeito produzido pelo servidor.
De acordo com Prado (1999), são características das filas:
• Clientes e tamanho da população: quando a população é muito grande, ou
seja, infinita em termos práticos, a chegada de um novo cliente a uma fila não
afeta a chegada de clientes subseqüentes. Caso contrário, quando a
população é pequena, este efeito existe e pode ser considerável.
• Processo de chegada: pode-se quantificar o processo de chegada dizendo
que a taxa média é um número de entidades por unidade de tempo. É
24

comum, trabalhar-se com o tempo médio entre chegadas. Assim, o ritmo de


chegada (λ) de 20 clientes por minuto, representam o intervalo médio entre
chegadas (IC) de 3 segundos.
• Processo de atendimento: também pode ser quantificado, à semelhança do
processo de chegada. Assim, resultando no ritmo de atendimento (μ) e tempo
de atendimento (TA).
• Disciplina da fila: refere-se à regra que os servidores escolhem o próximo
cliente a ser atendido. Na prática adota-se: First in First out (primeiro a chegar
primeiro a ser atendido – FIFO), Last in First out (último a chegar primeiro a
ser atendido – LIFO) e Prioridade. Esta última é definida como: a ordem em
que os clientes são atendidos pelo seu prestígio ou com base nas exigências
do serviço.
• Outras características: Número de servidores; Tamanho médio da fila;
Tamanho máximo da fila e Tempo médio de espera na fila.

Figura 3.2: Elementos que compõem a fila

No ARENA as variáveis de um sistema são definidas da seguinte


maneira:
25

Tabela 3.1: Variáveis de um Sistema

Variáveis referentes ao Sistema


Variável Descrição ARENA
TS Tempo Médio de Permanência no Sistema
NS Número Médio de Clientes no Sistema
Variáveis referentes ao Processo de Chegada
λ Ritmo Médio de Chegada
IC Intervalo Médio entre Chegadas Time Between
Por definição: IC = 1 / λ
Variáveis referentes à Fila
TF Tempo Médio de Permanência na Fila Queue Time
NF Número Médio de Clientes na Fila # in Queue
Variáveis referentes ao Processo de Atendimento
TA Tempo Médio de Atendimento ou Serviço Process Time
M Quantidade de Atendentes
NA Número Médio de Clientes que estão sendo atendidos
µ Ritmo Médio de Atendimento de cada atendente
Por definição: TA = 1 / µ

Segue abaixo algumas nomenclaturas:


i = Intensidade de tráfego medido em “Erlang” ou Nº mínimo de atendentes;
n = Tamanho da população;
TFS = Tempo fora do sistema;

A seguir é apresentada a Tabela 3.2 contendo um resumo das fórmulas


usuais.

Tabela 3.2: Resumo de fórmulas usuais em Teoria de Filas


Nome Fórmula

Intervalo entre chegadas IC = 1/λ

Tempo de atendimento TA = 1/µ

Taxa de utilização dos atendentes ρ = λ/ Mµ

Intensidade de tráfego i = | λ/ µ| = | TA / IC |

Relações entre fila, sistema e atendimento NS = NF + NA


NA = λ/ µ
NS = NF + λ/ µ = NF + TA / IC
TS = TF + TA
NA = ρ = λ/ Mµ
26

Fórmulas de J.D.C. Little NF = λ. TF


NS = λ. TS

Ciclo Ciclo = TS + TFS


Ciclo = n / λ

Na maioria dos casos, seis características básicas de processos de filas


fornecem uma descrição adequada de um sistema de filas:
• Padrão de chegada dos clientes: nos processos de filas comuns, os
processos de chegadas são estocásticos, ou seja, desenvolvem-se no tempo
e no espaço conforme leis de probabilidade. Assim, é necessário conhecer a
distribuição de probabilidade descrevendo os tempos entre as sucessivas
chegadas dos clientes (tempos de interchegada). Também é necessário
saber se os clientes podem chegar simultaneamente (chegada batch), e se
assim, qual a distribuição de probabilidade do tamanho do batch.
• Padrão de serviço dos servidores: a maior parte da discussão mencionada
nos padrões de chegada é valida para discussão dos padrões de serviço. A
mais importante é que uma distribuição de probabilidade é necessária para
descrever a seqüência de tempos de serviços dos clientes. Os serviços
também podem ser simples ou batch.
• Disciplina de filas: refere-se a maneira como os clientes são escolhidos para
entrar em serviço após uma fila ser formada. A maioria das disciplinas
comuns que podem ser observadas na vida diária é First-Come-First-Served
(FCFS), ou seja, o primeiro a chegar é o primeiro a ser servido. Entretanto,
existem outras disciplinas, tais como, Last-Come-First-Served (LCFS),
aplicável em sistemas de controle de estoque onde o item mais recente é
mais fácil de ser apanhado, e diversas outras disciplinas baseadas em
esquemas de prioridade. Existem duas situações gerais em disciplinas de
prioridade. No primeiro caso, que é chamado de preemptivo, o cliente com a
mais alta prioridade é permitido entrar em serviço independentemente de
outro cliente com menor prioridade estar sendo servido, de forma que, o
cliente com menor prioridade é interrompido e tem seu trabalho reiniciado
mais tarde. Quando reiniciado, ele pode iniciar do ponto onde parou ou
27

reiniciar todo o processo. Na segunda situação de prioridade, chamado caso


não-preemptivo, os clientes com mais alta prioridade vão para o início da fila,
mas só entram em serviço quando o cliente sendo atendido deixa o sistema,
mesmo que ele tenha uma prioridade baixa.
• Capacidade do sistema: em alguns processos de filas existe uma limitação
física da quantidade de espaço na fila, de modo que, se as filas alcançarem
um certo comprimento, nenhum novo cliente poderá entrar no sistema até
que espaço disponível seja obtido com o atendimento de um cliente e a
conseqüente diminuição do tamanho da fila. Estas situações são referidas
como sistemas de filas finitos, ou seja, existe um limite finito do tamanho
máximo do sistema.
• Número de canais de serviço: quando o número de canais de serviço são
definidos, tipicamente estão sendo determinados o número de estações de
serviços paralelos que podem servir os clientes simultaneamente.
• Número de estágio de serviços: um sistema de filas pode ter um único
estágio de serviço, como no caso da barbearia, ou pode ter vários estágios.
Um sistema de multi-estágio pode ser exemplificado como um procedimento
de exame físico, onde cada paciente passa por diversos exames, tais como:
sangue, vista, urina e etc. Em alguns sistemas multi-estágio reciclagem ou
retorno podem ocorrer. Reciclagem é comum em processos de manufatura,
onde inspeções de controle de qualidade são realizadas sendo que se
alguma peça não se adequa ele deve ser reprocessada.
As seis características de sistemas de filas discutidas nesta seção por Costa
(2006) são suficientemente gerais para descrever um processo sob estudo. Assim,
antes de realizar qualquer análise matemática, é necessário descrever adequadamente
o processo sendo modelado, de forma que, o conhecimento das seis características
básicas é essencial nesta tarefa.
28

4. ARENA

4.1 Histórico do ARENA

Em 1982 foi lançada a primeira versão da linguagem de simulação SIMAN


pela Systems Modelyng Corp. / EUA, inspirada na linguagem GPSS usada em
computadores de grande porte. Inovadora, foi a primeira linguagem específica de
simulação destinada a IBM-PC compatíveis.
Nos anos seguintes, o SIMAN foi aprimorado e também sua interface,
inovando novamente: foi a primeira linguagem de simulação a fazer uso do mouse em
sua interface, em uma época anterior ao Windows2.
Em 1990, foi lançado o pacote CINEMA, que, integrado ao SIMAN permitia
apresentar uma representação animada e em cores do funcionamento do sistema. Foi,
mais uma vez, a primeira interface do tipo para simuladores.
Em 1993, SIMAN e CINEMA foram integrados em um ambiente único de
simulação que unia e potencializava seus recursos, o ARENA. A linguagem SIMAN,
através do ARENA, passou a ser representada em formato gráfico, tornando-se
bastante intuitiva.
Em 1995 foi lançado o ARENA for Windows 95, sendo a primeira ferramenta
de simulação a trabalhar em versão 32 bits. No ano seguinte, com a versão 3.0, passou
a ser a primeira e única até o momento a receber a certificação “Microsoft Windows
Compatible”, integrando a linguagem Visual Basic for Applications (VBA)3, que permite
acessar ou ser acessada por todos os aplicativos do MS Office4 e muitos outros.
Com a compra da Systems Modelyng Corp. pela gigante Rockwell em 2000,
o ARENA recebeu um enorme impulso de desenvolvimento, e novas versões
agregando melhorias são lançadas em intervalos de tempo cada vez mais curtos. O
ARENA passou a fazer parte da suíte RS BIZWARE, que reúne uma solução integrada
2 Windows
3: é um ambiente operacional com recursos gráficos, ou seja, é um programa que gerencia seu computador por meio de ícones e janelas de uma forma muito amigável e fácil de usar. Facilita o uso do
computador.
Visual Basic for Applications (VBA): é uma tecnologia de desenvolvimento de aplicações que permite a integração entre diferentes sistemas e dados.
4 MS Office: é um conjunto de programas de escritório da empresa MicroSoft.
29

e completa para projetar, planejar e gerenciar o chão de fábrica. Assim, o ARENA agora
é parte importante da estratégica de atuação da Rockwell Software, braço de software
da Rockwell, dentro do segmento de Manufacturing Execution System (MES).
Atualmente, o ARENA se encontra na versão 9.0 e trouxe grandes melhorias
em termos de linguagem e interface (PARAGON, 2006).

4.2 O Software

Para Prado (1999), o ARENA é um ambiente gráfico integrado de simulação,


que contém todos os recursos para modelagem de processos, desenho e animação,
análise estatística e análise de resultados. Ele foi considerado por renomados
especialistas em simulação como "O mais inovador software de simulação", por unir os
recursos de uma linguagem de simulação à facilidade de uso de um simulador, em um
ambiente gráfico integrado. A linguagem incorporada ao ARENA é o SIMAN.

Figura 4.1: Interface Principal do Software ARENA

Para simplificar o processo de construção de modelos, o ARENA usa uma


Interface Gráfica para o Usuário (ou Graphical User Interface - GUI), que em muito
automatiza o processo e reduz a necessidade do teclado, pois o mouse é a ferramenta
30

utilizada. Além de permitir a construção de modelos de simulação, o ARENA possui


ainda ferramentas muito úteis, como:
• Analisador de dados de entrada (Input Analyser): permite analisar dados reais
do funcionamento do processo e escolher a melhor distribuição estatística
que se aplica a eles. Esta distribuição pode ser incorporada diretamente ao
modelo;
• Analisador de resultados (Output Analyser): é uma ferramenta com diversos
recursos que permite analisar dados coletados durante a simulação, sendo
que esta análise pode ser gráfica, e tem ainda recursos para efetuar
importantes comparações estatísticas;
• Visualizador da simulação (ARENA Viewer): permite que um modelo,
previamente preparado pelo ARENA, rode em outro computador com o
ARENA Viewer instalado, sem necessidade de chave de proteção;
• Scenario Manager: permite executar um conjunto de simulação na
modalidade batch (em lotes) para, posteriormente, analisá-los.
O ARENA é composto de uma família de softwares, alguns com finalidades
genéricas e outros com finalidades específicas:
• ARENA Standard: é um simulador genérico que permite ao usuário utilizar
inúmeros templates, porém sem a possibilidade de criação de templates
próprios;
• ARENA Professional: é também um simulador genérico que além dos
recursos comuns do Standard, é possível ao usuário criar objetos e agrupá-
los em templates, distribuindo-os de maneira livre dentro da organização ou
ao mercado;
• ARENA Contact Center: é um simulador especial para simulação de centrais
de atendimento;
• ARENA Factory Analyzer: é um simulador específico para estudos de
manufatura. Segue padrão para projetos na área e possui interligação com
ferramentas de MRP e Scheduling;
• ARENA Packaging: é um simulador destinado a linhas de alta velocidade e
grande quantidade de elementos, como engarrafadoras e empacotadoras;
31

• ARENA Realtime: é um simulador capacitado a trocar informações em tempo


real com sensores e controladores externos, para simular e monitorar o
sistema.
O ARENA possui um conjunto de blocos (ou módulos) que são utilizados
para se descrever uma aplicação real (POLARI, 2006).

Figura 4.2: Demonstração dos Blocos

Alguns elementos básicos do ARENA, segundo Bressan (2001):


• Entidades (entity): são os objetos que se movem ao longo do sistema. Podem
ser transações, clientes, equipamentos sendo produzidos.
• Estações (station): as entidades se dirigem às estações para a realização de
serviços. Nas estações, entrarão em filas de espera até serem atendidas.
Server, AdvServer, Enter e Station são estações.
• Recursos (resource): são os elementos necessários à realização de um
serviço. Podem pertencer a uma única estação ou serem utilizados por várias
estações.
32

• Filas (queue): são módulos onde as entidades esperam enquanto aguardam


um recurso.
• Fluxos: são os caminhos percorridos pelas entidades ao longo do sistema. Os
caminhos são definidos através de especificação de rotas, conexões, rótulos,
transportadores e esteiras.
• Painéis de módulos (templates): são arquivos com extensão .tpo que contém
um conjunto de módulos. Common.tpo é o que contém os módulos básicos
que temos utilizado.
• Atributos: são associados às entidades para registrar algum valor específico
da entidade, isto é, acompanham cada entidade individualmente. Por
exemplo, um atributo pode registrar o instante em que a entidade foi criada e
consultando o atributo na saída sabemos o tempo que a entidade ficou no
sistema.
• Variáveis: são variáveis globais cujos valores podem ser utilizados ou
alterados ao longo da simulação. São diferentes de atributos, pois variáveis
podem registrar valores comuns a várias entidades.
• Animação: os elementos do modelo podem ser animados por figuras,
permitindo a visualização durante a simulação.
• Seqüências (sequences): pode-se definir uma rota determinada as entidades
seguirem entidades seguirem através da definição da seqüência. Entidades
pertencentes a seqüências diferentes poderão seguir rotas diferentes a
medida que passam por estações. Cada entidade possui dois atributos
associados e que podem ser verificados:
NS: Nome da seqüência à qual pertence
IS: Nome da estação atual onde está.
• Transportadores (transporters) e Esteiras (conveyors): são módulos que
transportam as entidades de uma estação a outra.
• Depósitos (storage): são lugares de armazenamento de entidades, tais como
peças produzidas.
• Conjuntos (sets): recursos de um mesmo tipo podem ser agrupados em
conjuntos.
33

• Estatísticas: são resultados contabilizados pelo ARENA durante a simulação


e que são apresentados no relatório final.
Counters: contadores de entidades que estão em um determinado
módulo do modelo.
Tallies: Grandezas resultantes de observação tais como tempo
entre duas estações.
Frequencies: distribuição de freqüência de uma determinada
grandeza.
Time-persistent: grandezas que são dependentes do tempo, tais
como tamanho de filas.
Outputs: resultados finais de estatísticas e outros valores coletados.

4.3 Templates

A tecnologia diferencial do ARENA são os templates, ou seja, uma coleção


de objetos/ferramentas de modelagem, que permitem ao usuário, descrever o
comportamento do processo em análise, através de respostas às perguntas pré-
elaboradas de maneira visual e interativa (PARAGON, 2006).
O software ARENA pode utilizar diversos tipos de templates, inclusive
simultaneamente. Os templates usados para a elaboração deste projeto foram: basic
process, advanced transfer e common. Ao iniciar o ARENA são abertos alguns, porém
para abrir os demais é necessário acessar o menu File>Template Pannel>Attach.
A montagem de um modelo com os templates basic process e advanced
transfer aparenta um fluxograma, pois seus blocos possuem formas geométricas. Já a
montagem de um cenário para a simulação desse modelo é feita separadamente,
associando as variáveis ao cenário. A única animação possível dentro desses blocos é
a utilização de figuras que representem o fluxo dos clientes dentro do sistema.
Cada template é formado por diversos blocos, cada qual com sua função. Os
blocos do template basic process são os seguintes: create, dispose, process, decide,
batch e assign. Os blocos enter, leave e pickstation pertencem ao template advanced
34

transfer. E o template common é formado pelos blocos: arrive, depart, server, inspect e
simulate.
O bloco create é utilizado para a inserção dos dados de chegada de clientes
ao sistema. A Figura 4.3 mostra o formulário associado a este bloco.

Figura 4.3: Formulário criação da entidade

No formulário da Figura 4.3, name é o campo que possibilita definir o nome


do bloco que o identificará dentro do sistema. O nome da entidade (cliente) que chega
ao sistema pode ser atribuído através do entity type, esse nome é usado para associá-
lo a uma figura que o represente.
As configurações dos intervalos entre as chegadas (Time Between Arrivals),
são feitas através desse bloco. A forma como ocorrem as chegadas é definida usando
uma das seguintes opções apresentadas dentro de type:
• Random(Expo): chegadas aleatórias seguindo a distribuição exponencial;
• Constant: intervalos constantes de chegadas definidos pelo usuário.
A quantidade de clientes que chegam ao sistema em um determinado
intervalo é especificada em entities per arrival. A quantidade máxima de clientes que
chegam ao sistema é especificada na opção max arrivals, caso possa ser infinito o
número de chegadas basta completar o campo com a palavra infinite.
O final de um processo ou de um sistema pode ser determinado pelo bloco
dispose. Esse bloco possui uma variável que faz a contagem dos clientes que passam
por ele.
Outro bloco pertencente ao template basic process é o bloco process, nele
são feitas parte das configurações referentes ao processo de atendimento. A Figura 4.4
35

é o formulário de dados do bloco process. O primeiro campo de informação requerido é


o nome do bloco e em seguida seu tipo. As opções fornecidas no campo type são:
standard caso seja um processo padrão e submodel.
A parte lógica do processo é definida nesse bloco, para a configuração dessa
parte são fornecidas informações da ação, prioridade e dos recursos desse processo.

Figura 4.4: Formulário do Bloco Process

No campo action são dadas quatro opções, para determinar como será o
tempo (a demora) do cliente dentro do processo, conforme segue:
• Delay: tempo de espera;
• Size Delay: tempo de atendimento;
• Size Delay Release: anula o tempo de atendimento;
• Delay Release: libera o atraso.

O campo priority somente fica disponível se as opções size delay e size


delay release forem selecionadas. As opções de prioridade são: high (prioridade alta),
medium (prioridade média) e low (prioridade baixa).
Da mesma forma o campo resourses fica disponível de acordo com a opção
escolhida no campo action, porém além das opções que habilitam o campo priority a
36

opção delay release também possibilita o preenchimento do campo resourses. As


informações adicionadas a esse campo são: o tipo de recurso utilizado pelo processo, o
nome do recurso e a quantidade.
Os próximos campos a serem preenchidos são referentes ao tempo de
permanência ou atraso, o campo delay type pode ser constante, uniforme, com
distribuição normal ou triangular, ou seguindo uma expressão. Após a escolha da opção
do tipo de atraso os campos variam de acordo com a opção escolhida, mas os
principais campos são: tempo mínimo e máximo de permanência e a unidade de tempo.
Em determinados sistemas acontecem divisões de fluxo, obedecendo algum
critério, para realizar essa divisão é utilizado o bloco decide.

Figura 4.5: Configuração do Bloco Decide

Semelhantemente aos demais blocos, o primeiro campo a ser preenchido é o


nome que o identificará dentro do sistema. Para definir o critério de divisão do fluxo é
selecionada uma opção dentro do campo type, as opções disponíveis são:
• 2-way by Chance: define através de percentagem apenas dois caminhos;
• 2-way by Condition: define através de condição também apenas dois
caminhos, fazendo uso de programação;
• N-way by Chance: esta opção permite mais dois caminhos, definidos
através de percentagem;
• N-way by Condition: permite que mais de dois caminhos sejam escolhidos
através de condições, usando uma programação simples.
37

Dentro do campo conditions são adicionadas as condições que devem ser


obedecidas de acordo com o caminho que o cliente deve seguir. As condições são
estabelecidas de acordo com suas opções: expressão, variável, atributo ou tipo de
entidade, cada uma dessas opções possibilitam um tipo de condição.
Caso seja necessário agrupar as entidades (clientes) de acordo com algum
critério deve ser usado o bloco batch. Esse bloco determina a quantidade de entidades
que deve ser agrupada e a regra que deve ser seguida para agrupar.

Figura 4.6: Formulário do Bloco Batch

O campo type determina o tipo de agrupamento, podendo ser permanente ou


temporário. A quantidade de elementos que devem ser agrupados é escolhida em
batch size. Para marcar o critério de contagem pode ser escolhida uma das opções
dentro do campo save criterion: first (primeiro), last (último), sum (soma) e product
(resultado). O agrupamento pode ou não seguir uma regra, ou seja, no campo rule deve
ser escolhida uma das alternativas: any entity caso deva apenas contar as entidades
que passam por esse bloco e agrupá-las na quantidade escolhida, ou by attribute caso
essa opção seja escolhida abrirá mais um campo para que seja determinado o nome do
atributo (critério) de agrupamento.
O último bloco do template basic process chama-se assign, através dele é
atribuído o nome e o valor inicial de um atributo, variável ou entidade. A Figura 4.7
apresenta o formulário inicial do bloco e o formulário para adicionar as características.
38

Figura 4.7: Formulários do Bloco Assign

Dentro do formulário para adicionar as características (Figura 4.7 –


Assignments) o campo type disponibiliza as opções: variable (variável), attribute
(atributo), entity type (tipo da entidade), entity picture (figura da entidade) e other
(outro). Depois de escolher o tipo deve ser determinado seu nome e o valor que será
atribuído.
A partir daqui serão explicitados os três blocos do template advanced
transfer. O primeiro deles será o bloco enter, esse bloco define a entrada do cliente no
sistema. Esse bloco define o nome do bloco e da estação, sendo que a estação
normalmente possui o mesmo nome do bloco, porém acrescentando .Station. A parte
lógica definida aqui refere-se ao tempo que o cliente passará nesse bloco que pode ser
definido diretamente ou obedecer alguma distribuição, a unidade de tempo que será
contada e o modo que será a alocação.
O bloco leave determina a maneira que será a saída do sistema, se haverá
transferência para fora e qual o tipo de conexão.
O bloco pickstation seleciona um destino para o cliente, de acordo com o que
for predeterminado. A Figura 4.8 representa o formulário que deve ser preenchido para
configuração do bloco pickstation.
39

Figura 4.8: Formulário do Bloco Pickstation

A opção test condition está relacionada com as opções escolhidas dentro de


selection based on (seleção baseada em), as opções dessa parte da seleção são:
quantidade de fila, quantidade de recursos (servidores) ocupados, quantidade de
clientes indo para a estação e expressão; de acordo com essas opções deve ser
determinado se será selecionado como destino o servidor com o máximo ou o mínimo.
Os últimos campos referem-se à transferência entre as estações, o tipo dela e o tempo
que levará.
O último template a ser detalhado é o common, sendo esse simples de
configurar, pois a cada bloco já fica determinado qual deve ser o próximo, e também é o
que mais facilita a montagem do cenário.
O primeiro bloco é o arrive que configura as chegadas dos clientes no
sistema. As chegadas podem possuir intervalos constantes ou obedecer alguma
distribuição. Nesse mesmo bloco deve ser configurado o bloco seguinte e o tempo de
transferência entre eles.
Para configurar as saídas dos clientes do sistema o bloco usado é o depart
que permite a configuração da contagem e dos registros.
Os servidores de um modelo de simulação são representados pelo bloco
server, para cada servidor deve ser inserido um bloco. Através dele são feitas as
40

configurações do servidor e inseridas figuras que o representem de acordo com o


cenário. A Figura 4.9 representa o formulário de configuração do server e a Figura 4.10
a maneira de adicionar ou alterar a figura que o representa.

Figura 4.9: Formulário do Bloco Server

As configurações que devem ser feitas no bloco server correspondem ao


atendimento, os campos que devem ser preenchidos referem-se ao nome do recurso
que será usado no atendimento e o tempo de atendimento, sendo que esse pode ser
constante ou obedecer alguma distribuição. As demais informações requeridas são do
próximo bloco (leave date), nome e tempo gasto na transferência.
41

Figura 4.10: Formulário para inserção ou alteração das figuras

O atendimento pode ser representado por figuras, que demonstrarão os


estados do atendente, ocupado e ocioso. O software ARENA oferece bibliotecas
variadas, que podem ser selecionadas de acordo com o tipo de simulação.
O bloco inspect é usado para representar o servidor que realiza inspeção na
produção, caso o produto passe pela inspeção e seja aprovado deve prosseguir, caso
contrário deve voltar e ser refeito. Essa seleção é feita de acordo com a proporção
escolhida. Os blocos de destino são determinados nesse mesmo bloco como também o
tempo gasto entre eles.
O bloco simulate é usado para determinar o nome da simulação e o seu
tempo de funcionamento. Através desse bloco a entidade (cliente) pode ser associada a
uma figura, que se moverá entre os blocos para dar animação ao cenário.
42

Figura 4.11: Configurações do Bloco Inspect

4.4 Funcionalidades do ARENA

Algumas funcionalidades do ARENA, segundo Paragon (2006) :


• MS Office compatível;
• Conexão direta para Excel5, Power Point6, Access7 e qualquer aplicativo
MS Office compatível, incluindo C++, Visual Basic (VB)8 e Java;
• Inclui tecnologia ActiveX / OLE 3.0 Automation9;
• Inclui VBA, permitindo ao usuário desenvolver rotinas em VB, visando
automatizar tarefas, inserir multimídia, desenvolver ferramentas de
treinamento e muito mais;

5 Excel: é um aplicativo Windows - uma planilha eletrônica - que fornece ferramentas para efetuar cálculos através de fórmulas e funções e para a análise desses dados.
6 Power Point: é um aplicativo completo para a criação de apresentações profissionais de forma rápida e simples, permitindo aos acadêmicos apresentar seminários, monografias, trabalhos em eventos

científicos, palestras e outras apresentações em Datashow. Permite criação de transparências rápidas para dar instruções à uma equipe, slides para uma reunião, folhetos (folders) para dar suporte à
apresentação de trabalhos em eventos e/ou palestras, além de efeitos especiais para apresentações em tela.
7 Access: é um aplicativo e guarda dados em uma ou mas tabelas, criando assim, um banco de dados relacional, com consultas imediatas.
8 Visual Basic (VB): é uma linguagem de programação, que permite a criação de aplicativos para o Ambiente Windows. Através de ferramentas gráficas você desenha seu aplicativo, atribui suas
características e gera seu código de maneira rápida e eficiente.
9 Mais recentemente a Microsoft introduziu outra extensão aos controlos OLE, designada porActiveX. Esta solução possui um conjunto de tecnologias baseadas em controlos OLE que facilitamo
desenvolvimento de aplicações para a Internet. Uma aplicação que é um controlo ActiveX pode ser embebida nas páginas Web ou em qualquer outro contentor de controlos ActiveX.
43

• Wizard/Assistente para ajudar na criação de modelos;


• Input e Output Analyzer, ferramentas auxiliares para tratamento de dados
e análise de resultados;
• Manuais on-line e help com novos recursos;
• Extensa biblioteca de desenhos para serem usados na interface animada;
• Documentação automática da lógica de modelagem;
• Suporta gravação de macros para automação de tarefas.
• Symbol Factory: específico para representação gráfica de diversos
segmentos industriais, como mineração, logística, manufatura, siderurgia,
entre outros.
Funcionamento do modelo na versão RUNTIME do software ARENA, de
instalação gratuita para proprietários da versão comercial. Assim, o modelo de
simulação, juntamente com o ARENA, poderá ser instalado em quantas estações de
trabalho sejam necessárias aos usuários.
Leitura e gravação facilitada em planilhas Excel. A linguagem do ARENA
possui comandos que fazem esta troca de dados sem a necessidade de codificação em
VBA, lendo ou gravando diretamente entre variáveis do modelo e células de dados da
planilha.

4.5 Exemplo 1: Batch

O exemplo Batch, como a tradução do seu nome diz, divide em lotes, ou seja,
os clientes que entram no sistema são divididos em grupos de acordo com algum
critério. Nesse caso específico, divide os blocos que entram de acordo com sua cor,
verde e azul, em grupos de quatro. Essa simulação pode ser usada para demonstrar o
funcionamento de máquinas que fazem seleção de produtos e precisam montar pacotes
com uma determinada quantidade.
Foi criado um exemplo genérico usando dois templates: Basic Process e
Advanced Transfer que não possuem cenário, devido ao seu tipo de aplicabilidade,
44

porém, nesse exemplo, foi feita animação dos clientes para possibilitar a visualização
do fluxo corrente do sistema, além da demonstração da contagem.

Figura 4.12: Representação do exemplo Batch

Para a confecção deste sistema foi necessária a configuração dos


parâmetros dos seguintes blocos: create, decide, assing, batch, dispose (basic
process), enter e leave (advanced trasfer), conforme a Figura 4.12.
O bloco create é simples de ser configurado, nele foram inseridos os dados
de chegada dos clientes ao sistema. Nesse exemplo, os clientes são as peças azuis e
verdes, que chegam ao sistema de forma aleatória obedecendo a distribuição
exponencial.
As peças foram designadas como atributos através do bloco assign, tanto as
verdes quanto as azuis são chamadas de TIPO, porém para diferenciá-las cada uma
recebeu um valor (a azul recebeu 1 e a verde 2).
O primeiro e o segundo bloco leave são utilizados para finalizar a criação das
peças e enviá-las à junção. A junção é iniciada por um bloco enter, apenas para
receber as peças que chegam das duas criações.
45

Figura 4.13: Bloco Batch e a Fila das Peças

O bloco que dá o nome ao exemplo é usado para separar as peças em


grupos de quatro peças de acordo com as cores, essa separação é possível por causa
do atributo de cada peça, ou seja, o TIPO que foi atribuído a cada uma delas. Assim,
vai sendo formada uma fila até que se juntem quatro peças da mesma cor, conforme a
Figura 4.13, enquanto não chegam as quatro peças da mesma cor o bloco não libera a
saída das peças.
Uma imagem foi atribuída para cada peça, mas quando elas são agrupadas
essa imagem deve ser mudada para representar o grupo formado, para isso foram
usados os blocos decide e assign, pois o primeiro seleciona quais são as peças e o
segundo modifica a figura. No bloco decide foi usado o tipo 2-way by Condition, pois
são apenas dois caminhos a seguir e a peça deve seguir um caminho caso o atributo
obedeça a condição e siga outro, caso não obedeça. Para atribuir uma nova figura às
peças dentro do assign ao invés de usar a opção atributo foi usada figura da entidade,
assim quando passa por esse bloco modifica a figura, as Figuras 4.14 e 4.15
demonstram que foi usado o mesmo bloco, porém com configurações diferentes, por
isso a mudança da figura.

Figura 4.14: Primeiro Bloco Assign


46

Figura 4.15: Segundo Bloco Assign

Para finalizar a simulação desse modelo foram usados os blocos leave e


dispose, pois o dispose possui um contador para marcar o número de entidades que
passaram por ele.

4.6 Exemplo 2: Pedágio

O funcionamento de um pedágio pode ser observado através desse modelo


de simulação, porém a partir dele podem ser simulados outros sistemas, apenas
modificando o cenário. Sistemas que utilizam fila única com três servidores podem
utilizar esse modelo, tais como: atendimento de banco e caixas de supermercado, etc.

Figura 4.16: Funcionamento da simulação de um pedágio


47

A Figura 4.16 apresenta o modelo em funcionamento, porém para que seja


implementado é necessária a criação de duas partes, conforme a Figura 4.17, pois na
primeira parte da figura estão os blocos onde fica a programação e onde os dados
foram inseridos, na segunda parte é mostrado o cenário.

Figura 4.17: Montagem dos Blocos e do Cenário

Para a criação da primeira parte desse modelo foram usados os templates


basic process e advanced transfer. A criação das entidades e a entrada delas no
sistema são feitas através dos blocos create e enter, através deles foram especificados
que o nome da entidade é veículo e seus intervalos de chegada são aleatórios
obedecendo a distribuição exponencial.
O bloco pickstation foi usado para determinar a escolha do destino das
entidades, pois como é fila única com três servidores, em cada servidor serão formadas
filas, mas cada cliente que chega vai escolher um servidor de acordo com as filas que
foram formadas, essa é a tarefa do bloco pickstation. Dentro desse bloco foram
adicionados os nomes das estações de destino, suas filas e seus atendentes, para que
no momento em que for criada a animação cada entidade tivesse como destino um dos
servidores, como é mostrado na Figura 4.18.
48

Figura 4.18: Configuração do Bloco Pickstation

O atendimento é formado pelos três servidores, para cada um foram usados


os blocos enter e process, pois o enter recebe os clientes vindos do bloco pickstation e
dá o nome à estação. O bloco process determina o tipo do atendimento, o tempo gasto
e o nome do recurso usado (atendente). Quando o bloco process é inserido ele cria
uma fila (queue), nesse exemplo essa fila será usada dentro do cenário, pois está
associada a cada servidor.
Depois de realizado o atendimento todos os clientes vão para a mesma
saída, usando o bloco leave, onde é determinado o tempo gasto na movimentação.
A saída final do sistema é feita por três blocos: enter, leave e dispose, pois o
enter recebe as entidades vindas do atendimento e o leave e o dispose configuram a
maneira e o tempo gasto para a saída do sistema.
A montagem do cenário e sua animação foram configuradas de maneira que
ela se ligasse aos blocos que contêm a programação. Para essa montagem não são
usados os templates, porém elementos que representem cada bloco e sua função.
A chegada, a princípio, foi configurada através dos blocos create e enter, o
primeiro determinou a criação da entidade veículo, o segundo a maneira e o lugar por
onde o veículo deveria entrar no sistema, portanto no cenário foi inserida uma estação
49

que recebe o nome que foi criado dentro do bloco enter, para que seja representada
dentro da simulação.

Figura 4.19: Configuração do Bloco Enter

Figura 4.20: Configuração da Station

Nas Figuras 4.19 e 4.20 são apresentadas as configurações do bloco enter e


da station, assim é possível visualizar que ambas recebem o mesmo nome e assim
ficam ligadas.
Depois de serem criadas e entrarem no sistema as entidades passam pelo
bloco pickstation, onde será decidido o caminho que elas vão tomar, dentro do cenário
esses caminhos são representados por rotas que fazem a ligação entre a estação de
entrada e as estações de atendimento. Nessas rotas são formadas as filas de cada
servidor, essas filas foram criadas com o bloco process e receberam um nome que as
50

identificam com esse bloco. Assim, o processo de fila representado no cenário foi
configurado através do bloco process.
A representação da estação de atendimento do pedágio foi feita através de
uma figura que foi inserida usando um recurso de localização de imagem, conforme a
Figura 4.21, após a escolha da imagem que represente o servidor ocupado e ocioso, a
imagem pode ser colocada dentro do cenário. Para que o veículo ficasse parado na
estação durante o atendimento foi usado um seize area, que é apenas um ponto de
marcação para segurar a entidade em um lugar determinado durante um tempo,
conforme a Figura 4.22, é o círculo dentro da figura do posto do pedágio.

Figura 4.21: Recurso de localização de imagem

Figura 4.22: Representação do servidor

Da mesma maneira da entrada, na saída foram criadas rotas para ligar as


estações à saída. Para a saída foi inserida uma estação que recebeu o mesmo nome
dado ao último bloco enter que corresponde à entrada da última parte da simulação.
Nesse exemplo, foram inseridas variáveis para efetuar a contagem de
entidades que passam por cada servidor. A inserção de variáveis, conforme mostra a
Figura 4.23, foi feita associando seu nome ao bloco referente a cada estação.
51

Um recurso que foi usado nessa simulação é o relógio, o software ARENA


disponibiliza o relógio, é necessário somente configurar se deve ser analógico ou digital
e a hora que estará marcando no início.

Figura 4.23: Inserção de uma variável

OBS.: No final deste projeto se encontra dois exemplos detalhados, passo a passo, de
estudos de caso utilizados no software ARENA.
52

5. CONCLUSÃO

Percebeu-se que a ferramenta usada neste projeto, o software ARENA, tem


um potencial de simulação bastante avançado e nos proporciona criar grandes e
complexos sistemas oferecendo uma excelente visualização do sistema criado, além de
existir a possibilidade de gerar relatórios de vários tipos como, por exemplo, relatório
com a configuração de tempo que o analista quer rodar o sistema, etc.
No ARENA, que o simulador também tem a possibilidade de determinar
horários que deseja que o sistema rode, a fim de analisar as variações de fluxo em
períodos diferentes.
Porém, este software não é uma aplicação de fácil manuseio, pois para a
configuração do sistema, os caminhos a serem seguidos ficam ocultos entre os vários
tipos de botões. Outra complexidade é com relação à língua que o software é
disponível; Língua Inglesa. A versão utilizada neste projeto é uma versão livre e que é
limitada, não permitindo a “confecção” de sistemas grandes.
Portanto, o software ARENA é uma ferramenta excelente para profissionais
de diversas áreas, desde ciências humanas até exatas, possuindo muitas opções em
seus blocos, o que permite ao analista ser ainda mais ousado nas suas criações, mas
requer um estudo aprofundado sobre o software.

5.1 Dificuldades Encontradas

A grande dificuldade encontrada no desenvolvimento deste projeto, foi a falta


de material para explorar o assunto em estudo. Praticamente todas as referências
bibliográficas têm o conteúdo idêntico, além de não possuírem material com
conhecimento aprofundado.
Portanto, isto fez com que não citássemos nenhum autor em
determinadas partes do projeto, obrigando-nos a aprofundar, “bisbilhotar” nas
configurações do software, logo nos tornarmos as verdadeiras autoras da
parametrização, demonstração, enfim de quase todo o projeto.
53

5.2 Trabalhos Futuros

O desenvolvimento de projetos futuros está bem explícito, pois o software


pesquisado e parametrizado é muito amplo e ainda não foi totalmente explorado neste.
Sendo assim, fica a oportunidade para a procura de muitos outros recursos disponíveis
no software ARENA.
Então, com a conclusão deste projeto abrem-se caminhos para novas
pesquisas, novas parametrizações, além de ser mais uma fonte de referência
bibliográfica, pois foram aqui relatados e explicados alguns requisitos, algumas
demonstrações antes não disponíveis.
54

6. REFERÊNCIAS BIBLIOGRÁFICAS

ARAÚJO, Roberto Manhães de. Simulação. Disponível em: <http://www.see.rj.gov.br>.


Acessado em: 24/08/2006.

BANKS, Jerry; CARSON II, John S.; NELSON, Barry L. Discret-event system simulation.
New Jersey: Prentice-Hall, 1995, 548 p.

BRESSAN Graça. Modelagem e Simulação - ARENA. 2001. Disponível em:


<http://www.larc.usp.br/conteudo/universo/pcs012/arena.pdf>. Acessado em:
10/08/2006.

COSTA, Luciano Cajado. Teoria das Filas. Disponível em:


<www.deinf.ufma.br/~mario/grad/filas/TeoriaFilas_Cajado.pdf>. Acessado em:
10/08/2006.

ERLANG. Disponível em: <http://www.erlang.com.br/index.asp>. Acessado em:


04/08/2006.

HARELL, Ghosh e Bowden. Simulation Using Promodel. New York: McGraw-Hill Higher
Education, 2000.

INCUBADORA. Disponível em: <http://simulacao.incubadora.fapesp.br/portal>.


Acessado em: 24/08/2006.

LAW, Averill M.; KELTON, W. David. Simulation Modeling and Analysis. 3. ed. New
York: McGraw-Hill, 2000. 760 p.

PARAGON. Disponível em: <http://www.paragon.com.br/home/>. Acessado em:


17/08/2006.

PEGDEN, C.D., SHANNON, R.E., SADOWSKI, R.P. Introduction to Simulation Using


SIMAN. New York: McGraw-Hill. 1990. v. 2.

POLARI. Disponível em: <www.lsi.usp.br/pee_labs/PSI2325-Exp3_PolariTrans.pdf>.


Acessado em: 10/08/2006.

PRADO, Darci Santos do. Teoria das Filas e da Simulação. Belo Horizonte: Editora de
Desenvolvimento Gerencial, 1999, 124 p. Série Pesquisa Operacional, v. 2.

PRADO, D. S. Usando o Arena em simulação, Série Pesquisa Operacional. Belo


Horizonte: Editora de Desenvolvimento Gerencial,1999. v. 3.
55

SALIBY, E. Repensando a simulação – A Amostra Descritiva. São Paulo: Editora Atlas,


1998.

SILVA, Luís César. Simulação de Processos. Universidade Estadual do Oeste do


Paraná, 2002. Disponível em: <http://www.unioeste.br/agais/simulacao.html>. Acessado
em 10/08/2006.

Systems Modelling, Manuais do Arena. 1999.


56

7. APÊNDICES

7.1 Apêndice 1: Exemplo da Costura

Neste exemplo é mostrada uma fábrica de roupas, podendo ser usado para
vários tipos de produto, como na produção de equipamentos eletrônicos,
eletrodomésticos dentre outros. O sistema possui um bloco de chegada de clientes, um
servidor que realiza o corte do tecido, um servidor de costura, um bloco de inspeção e
um bloco de saída.

Figura 7.1: Representação do Sistema

No bloco inspeção as roupas passam por um controle de qualidade, se a


roupa estiver perfeita ela vai para o local de saída da produção, mas se estiver com
algum defeito ela volta para o serviço de costura, para que o produto possa ser
consertado e posteriormente ir para a saída. A montagem do sistema foi feito através
do bloco arrive, server, inspect, depart e simulate, pertencentes ao template common.
Para colocar os blocos na área de programação visual do ARENA é preciso
que abra o template localizado a esquerda da tela , clique sobre ele e arraste-o, este
procedimento é valido para os demais blocos de qualquer template.
57

Figura 7.2: Localização dos templates na tela inicial do ARENA

Inicialmente insere-se o bloco arrive e configura-o de acordo com o sistema a


ser seguido, desta forma é marcado a opção Station e posteriormente é dado o nome
para a esta estação de trabalho, outra opção que deve ser fornecida é o campo Time
Between que significa tempo entre as chegadas, após realizar o preenchimento desses
dados vá para a seção “Leave Date” para fornecer dados de saída de cliente, no campo
Station é fornecido o nome da próxima estação de trabalho e a rota a ser feita que
transfere uma entidade para uma estação especifica e para finalizar clique em OK. Os
campos que não foram preenchidos serão utilizados valores default.

Figura 7.3: Estação Arrive


58

No bloco server são preenchidos os dados do servidor como o nome da


station o resource que informa qual o nomeia a figura

2 1
3 1
6
4
7
5

Figura 7.4: Estação Server

1- Station: informa qual é o nome do servidor.


2- Resource: é preenchido com o nome da figura que representa o servidor ,
este campo é preenchido automaticamente , podendo ser alterado pelo
usuário.
3- Capacity Type: referente ao tipo de capacidade que o servidor dispõe.
4- Capacity: capacidade do servidor.
5- Process time: tempo de processo que o servidor realiza sua atividade.
6- Station (Leave Date): fornece o nome da próxima estação.
7- Route time: tempo de deslocamento entre uma estação e outra.

O bloco inspect foi configurado para, mandar o produto final para a saída ou
para o servidor costura, conforme Figura 7.5.
59

Figura 7.5: Estação Inspect

1- Station: e fornecido o nome da estação que o produto irá caso seja


aprovado pela inspeção.
2- Station: é preenchido com o nome da estação que o produto irá se for
reprovado.

A estação depart é configurada para obtenção dos dados de saída e como


as estações anteriores são necessárias que indique o nome do bloco e escolha se os
clientes que irão sair do sistema serão registrados ou não e se forem registrados de
que forma será feita a contagem.
O bloco simulate é responsável pela contagem do tempo do funcionamento
do sistema
60

Figura 7.6: Estação Simulate

Inserção de figuras nas estações

Para colocar figuras nos blocos server, inspect, e simulate dê um duplo


clique em cima da figura conforme a Figura 7.7.

Figura 7.7: Server

Quando clicar sobre a figura irá abrir uma janela para que escolha uma
imagem que se identifique com seu sistema, mas caso as imagens que serão abertas
não forem satisfatórias, há a possibilidade de abrir novos arquivos de figuras, isto é feito
da seguinte forma: clique em open>arquivos de programa>Rockwell
software>Arena7.0. Clique sobre o arquivo determinado pela sua escolha e ele
aparecerá na lista de figuras da janela Resource Picture Placement, então para
configurar a imagem como ocupado, desocupado inativo ou reprovado, clique sobre
uma das formas de estado, em seguida clique sobre a figura escolhida para representar
este estado e clique sobre a seta para a esquerda(<<) desta forma a imagem escolhida
61

representará o servidor quando o estado for ativado. Repita o mesmo procedimento


para todos os estados e todos os outros blocos.
Para conexão entre as estações de trabalho é preciso realizá-la
manualmente através do botão route encontrado na barra Animate transfer.

Figura 7.8: Conexão entre estações

Este procedimento é valido para as demais ferramentas segment, distance e


network.

7.2 Apêndice 2: Exemplo Choose

Este exemplo demonstra o funcionamento de um sistema com três


servidores e fila única. À medida que chegam os clientes o fluxo é dividido entre os três
atendentes proporcionalmente. O sistema criado pode ser usado em diversas
situações, como por exemplo: uma fábrica que possui três máquinas que realizam a
mesma atividade e que atendem a um fluxo contínuo, sendo que, após o
processamento o resultado obtido é despachado e unificado em uma única saída.

Figura 7.9: Funcionamento do Exemplo Choose


62

Foi criado um exemplo genérico usando dois templates: Basic Process e


Advanced Transfer que não possuem cenário, devido ao seu tipo de aplicabilidade,
porém há possibilidade de animação dos clientes para a visualização do fluxo do
sistema, além da demonstração da contagem feita através das variables.
Para a confecção deste sistema foi necessária a configuração dos
parâmetros dos seguintes blocos: create, decide, process, assing, dispose (basic
process), enter e leave (advanced trasfer). A seguir descreve-se a criação passo a
passo deste exemplo
Abra o software ARENA, insira o template Advanced Transfer (file>panel
template>attach>advanced transfer) a paleta do template irá aparecer do lado esquerdo
da tela, então insira o bloco create, para inserí-lo clique com o botão esquerdo do
mouse pressione e arraste-o até a área de visualização. Quando já tiver inserido dê um
duplo clique sobre o bloco para que possa configurá-lo conforme a Figura 7.10.

Figura 7.10: Inserção dos dados no Bloco Create

No formulário da Figura 7.10, o name é o campo que possibilita definir o


nome do bloco que o identificará dentro do sistema. O nome da entidade (cliente) que
chega ao sistema pode ser atribuído através do entity type, esse nome é usado para
associá-lo a uma figura que o represente.
As configurações dos intervalos entre as chegadas (Time Between Arrivals),
são feitas através desse bloco. A forma como ocorrem as chegadas é definida usando
uma das seguintes opções apresentadas dentro de type: Random (Expo): chegadas
aleatórias seguindo a distribuição exponencial; Constant: intervalos constantes de
chegadas definidos pelo usuário.
63

A quantidade de clientes que chegam ao sistema em um determinado


intervalo é especificada em entities per arrival. Esses clientes provêm de uma
população que pode ser finita ou infinita, a especificação se é infinita ou sua quantidade
é feita pela opção max arrivals.
Após as configurações de chegadas, são feitas as configurações das
entradas dos clientes no sistema através do bloco enter. Neste bloco é dado o nome
para a entidade e para o tipo, se houver mais de uma entidade ligada a ele é
necessário programar a seção logic se não deixa os valores deufalt.

Figura 7.11: Inserção dos dados no Bloco Enter

Na estação Decide há a opção type onde é escolhido o tipo de separação a


ser feita para os servidores e logo após uma condição simples, para que o fluxo de
clientes seja distribuído uniformemente a fim de não sobrecarregar o sistema, desta
forma a condição inserida foi a seguinte: na primeira linha da conditions é traduzida: se
soma1 menor que soma2 e soma1 menor que soma3, o cliente irá para o processo da
máquina1. A segunda linha diz: se soma2 menor que soma3 então o cliente irá para a
máquina2 e se não for nenhuma destas opções o cliente segue para a máquina3 para
inserir as condições clique no botão add.
64

Figura 7.12: Inserção dos dados no Bloco Decide

Logo após a inserção dos dados clique no botão Ok, e a configuração estará
pronta conforme figura 7.12.
No bloco Process é configurado o nome do bloco, o tipo de espera e de
atendimento, a prioridade que o cliente terá no sistema, a quantidade dos atendentes
que serão usados na simulação, o tipo de atraso que pode ocorrer no sistema, o tipo da
unidade de tempo, além de determinar a variação mínima e máxima do atraso,
conforme apresenta a Figura 7.13.
65

Figura 7.13: Inserção dos dados no Bloco Process

Através do bloco Assign é atribuído o nome e o valor de um atributo, variável


ou entidade.

Figura 7.14: Inserção dos dados no Bloco Assign

No bloco Leave é configurado o nome da partida, o tipo da alocação, o


tempo de atraso, o tipo da unidade de tempo e o tipo de transferência que é feita para a
saída do sistema.
66

Figura 2.7: Inserção dos dados no Bloco Leave

No bloco Dispose é escolhido ou determinado o nome da saída.

Figura 2.8: Inserção dos dados no Bloco Dispose

Para ligar os blocos que não foram conectados, usa-se a ferramenta

connnect , clique sobre ela e conecte um bloco ao outro através do pontinho preto
localizado na lateral de cada bloco conforme demonstração abaixo:

Para conectar os demais blocos repita o processo. Para finalizar e preciso


“compilar”, então vá até a barra de menu>run>go, após toda a simulação do sistema
67

será um criado o relatório automaticamente, como os dados necessários para a análise


de todo o protótipo.

7.3 Apêndice 3: Relatórios Gerados no Exemplo da Costura

You might also like