Na descrição do modelo, disse que queríamos saber onde estava o gargalo no sistema. Existem várias maneiras de determinar isso. Primeiro, você pode simplesmente examinar o tamanho visual de cada queue. Se um queue no modelo contiver de forma consistente muitos produtos acumulados nele próprio, então isso é uma boa indicação de que as estações de processamento (s) que alimentam estão causando
38 um gargalo no sistema. Na execução deste modelo, você vai notar que o segundo queue, muitas vezes tem um monte de produtos à espera de ser processado, enquanto que o conteúdo do primeiro queue é geralmente de 20 ou menos.
Outra forma de encontrar a localização de um gargalo é examinando as estatísticas do estado de cada um dos processadores. Se os três processadores a montante estão sempre ocupado, enquanto que a estação de testing (processor) estiver inativa, então, é bem provável que o gargalo seja os três processadores iniciais. Por outro lado, se a estação de testing (processor) estiver sempre ocupado, e os processadores a montante estiverem frequentemente ociosos, o gargalo provavelmente estará na estação de testing (na imagem acima, o processador que encontra-se sozinho logo após o segundo queue).
Execute o modelo, pelo menos, para 50 mil unidades de tempo. Então pare o modelo e abra a janela de propriedades do primeiro dos três processadores iniciais.
Clique sobre o objeto processor e no painel Quick Properties a direita de sua tela você consegue visualizar os dados estatísticos do processor.
39 As informações mostram que a estação de processamento estava ocioso em 15% do tempo de simulação, e que estava ocupado em 85 % do tempo, durante a simulação. Feche esta janela e, em seguida, clique duas vezes em cada um dos outros dois processadores para ver suas estatísticas. Eles devem ter um resultado muito próximo do apresentado acima.
Dê um duplo clique na estação de Teste para abrir a janela Properties. Analise as informações estatísticas conforme fizemos para o processor acima. Veja que o tester é o nosso gargalo no sistema, pois está em aproximadamente 98,6% processando as entidades (flowitems) e com tempo médio de permanência das entidades no equipamento de 0.99 unidades de tempo.
40 Agora que descobrimos onde o gargalo está presente, a questão é, o que devemos fazer a respeito? Isto depende de vários fatores de custos versus ganhos, bem como sobre os objetivos futuros da empresa. No futuro, a instalação atual será capaz de empurrar mais produtos através de um ritmo de produção mais rápido? Em nosso modelo, o source produz um produto a cada cinco segundos, em média, enquanto a estação testing envia um produto para o sink uma vez a cada 5 segundos, em média. Este valor médio de 5 segundos para a estação testing (processor) pode ser calculada utilizando o tempo de ciclo de 4 segundos e sua estratégia de envio 80/20. Assim, ao longo do tempo, o total de níveis de capacidade do nosso modelo ficará off. Se a fábrica começar a empurrar mais produtos por esta parte da instalação, isso equivale a uma taxa de chegada superior (um menor tempo de Inter chegada ou inter-arrival time) para o source. Se, não fizermos alterações para a estação testing (processor), o nosso modelo poderia acumular continuamente mais e mais partes, e o conteúdo das filas continuaria a aumentar até que não houvesse mais espaço disponível para acomodar os produtos. Para corrigir isso, vamos ter de adicionar uma segunda estação testing (processor), tendo em vista que encontramos o gargalo.
Outra situação em que pode-se querer adicionar uma outra estação de testing (processor) é se o tamanho da fila da fila do testador (processor) for muito importante para nós. Se é caro para permitir que o tamanho da fila do testador (processor) acumule quantidades elevadas de produtos, então seria inteligente adicionar uma segunda estação de testing (processor) para certificar-se de que o tamanho
41 da fila, bem como o tempo de espera de cada produto na fila, não fique elevado. Vamos olhar para as estatísticas da fila.
Clique em Queue2 para abrir o painel Quick Properties e veja as informações estatísticas do Queue
Continue a executar o modelo, e você verá que estes valores mudam conforme a simulação é executada. Olhe para os valores de conteúdo ou capacidade média e os valores médios do staytime. Staytime refere- se ao tempo que os flowitems (produtos) permaneceram no queue, ou tempo de permanência na fila. Logo no início da simulação, a capacidade ou conteúdo máximo do queue é geralmente baixo, mas, conforme a simulação prossegue, pode atingir valores elevados como 150 ou 200 (Staytime Max). Se um tamanho médio da fila de 150 ou 200 é inaceitável, então pode ser necessário adicionar uma segunda estação testing (processor).
Aleatoriedade
Vamos fazer alguns testes adicionais antes de nós decidirmos por adicionar outra estação testing (processor). Tendo em vista que em média, um produto chega do source a cada 05 segundos, e em média, um produto vai para o sink a cada 5 segundos, porque o queue deveria estar acumulando todos produtos? Os produtos estão deixando o modelo tão rápido quanto eles estão entrando, então, não deveríamos ter acúmulo de produto no sistema.
A razão pelo qual o queue está acumulando é por causa da aleatoriedade do sistema. Sim, em média, o produto chega ou é criado a cada 5 segundos, mas esta taxa de chega obedece uma distribuição exponencial. Para uma distribuição exponencial com um média igual a 5, na maioria do tempo, os produtos irão chegar de fato, a uma taxa superior a 5 segundos. Mas de vez em quando, haverá um longo período de seca, onde não há produtos chegando. No final, se equilibrará com uma média de 5 segundos,
42 e os produtos podem chegar mais rapidamente, e, assim, acumular-se no queue anterior a estação de teste, uma vez que a estação testing é o gargalo.
E se, em sua fábrica, os produtos chegarem a uma taxa mais previsível, ao invés de chegarem por uma taxa que representa uma distribuição exponencial imprevisível? Vamos testar.
• Dê um duplo clique Source para abrir a janela Parameters. Em Inter-Arrival selecione Statistical Distribution. O popup de Statistical Distribution irá aparecer.
• Uma vez configurado resete (Reset) e rode (Run) o modelo novamente.
Se você ainda não tiver a janela de propriedades do Queue2's disponível, abra-a novamente através de um duplo clique sobre o Queue2. Continue rodando o modelo. Você irá notar aqui que o conteúdo de produtos no queue não aumentará muito. Na verdade, não irá passar de 50 ou 60 enquanto antes, eles às vezes poderia chegar até a 150 ou 200. Isto é uma diferença significante causada por simplesmente pela aleatoriedade presente no modelo.
Maior Produtividade
Agora, imagine que a instalação (fábrica), precise aumentar significativamente a taxa de produtividade do sistema em 15%. Isto significaria, aumentar o tempo médio de inter-arrival do source de 5 para 4.25 segundos. Tendo em vista que a estação testing (processor) já encontra-se em 100% de sua utilização, nós teremos que obviamente, adicionar uma segunda estação testing (processor) no sistema. Vamos fazer esta mudança.
• Dê um duplo clique em Source novamente para abrir a janela Properties. Clique no botão para o Inter-Arrivaltime. Mude a média da distribuição normal de 5 para 4.25. Clique em OK na janela Properties do source.
• Agora, iremos criar a segunda estação de teste (processor). Crie outro objeto Processor no modelo e coloque-o Guiaixo de Tester. Nomeie como Tester2.
• Conecte o Queue2 com o Tester2.
• Conecte o Tester2 com Sink e com o Queue1.
43
• Na guia Processor, no painel Process, selecione o texto do campo Process Time. substitua o texto por 4
• Clique em Apply, mas não feche a janela Properties.
• Clique na guia Flow. Guiaixo de Sent To Port selecione a opção By Percentage. Entre com os mesmos parâmetros que você utilizou para o Tester1.
• Adicione a trigger (OnExit) para alterar a cor para black, exatamente como no outro Tester (processor). • Ao terminar de fazer as mudanças, Reset e Run o modelo novamente.