Relatório
da disciplina IA009 – EC5 –
SNTool – 09/12/2002
Fábio
Guilherme Ronzelli Murback – RA 020658
E-mail:
murback@uol.com.br ou murback@pucpcaldas.br
Simular um processo organizacional utilizando a
ferramenta SNTool.
Tentou-se simular, utilizando um modelo simples, a
cadeia de suprimentos de uma indústria fabricante de bancos de madeira.
A
árvore de montagem do banco e apresentado na figura 1. O processo de fabricação
do banco consiste em encaixar os três pés no assento. Por motivo de
simplificação foram desconsiderados os problemas mecânicos deste tipo de
montagem.
Figura 1: Árvore de montagem do banco
Foi considerado apenas um fornecedor para os
elementos do banco (pés e assento). O fornecedor (classe Fornecedor) entrega os componentes (classe MateriaPrima)
diretamente no estoque de matéria-prima (place p2). O produtor (classe Produtor)
busca o material no estoque e produz bancos (classe ProdutoAcabado)
que são armazenados no estoque de produto acabado (place
p3). O consumidor (classe Consumidor) retira os bancos desejados diretamente do estoque de
produto acabado (figura 2). Para o exercício concentrou-se no problema do
atendimento do consumidor, ou a quantidade de vezes que ele procura pelo
produto no estoque e não encontra.
Retirando diretamente o produto do estoque de produto
acabado o consumidor precisa verificar a quantidade disponível para
abastecê-lo. Se a quantidade necessária não estiver disponível o consumidor não
deve retirar os produtos.
O processo descrito acima é apresentado a seguir
(figura 2).
Figura 2: Cadeia de suprimentos de uma
indústria de montagem de bancos.
O modelo simulará condições ideais de fornecimento
e abastecimento de mercado: tudo que entra é transformado em produto acabado.
Neste momento não era interessante simular condições reais devido a complexidade de relações e a quantidade de variáveis
envolvidas. Perdas na transformação de matéria-prima em
produto acabado, não entrega pelo fornecedor, tempos de pedido,
alterações de preço, entre outras são alguns exemplos das variáveis que estão
envolvidas nos processos de compra e armazenamento de materiais. Assim, para
aprender a utilizar e observar o potencial do SNTool uma única variável acredito ser suficiente.
Para fim de simulação deseja-se adicionar e retirar
o número de fornecedores e de consumidores para observar as condições de
atendimento.
O modelo simulará as condições de não atendimento
através do incremento de dois estados (s1 e s2) na classe Consumidor. S1 será incrementado toda vez que um teste verificasse a
não existência de objetos no estoque de ProdutoAcabado
(ProdutoAcabado f = read_in();).
S2 será incrementado toda vez que
uma solicitação de cliente for realizada para pegar um produto no estoque.
A razão entre os dois é o índice de não atendimento.
Em Administração de Materiais este indicador é
chamado, também, de nível de serviço e indica o quão eficaz foi o estoque para
atender à solicitações dos usuários. Este indicador,
juntamente com acurácia, giro e cobertura são
utilizado com freqüência para medir o desempenho e tomados como referência para
o trabalho de redução de estoques. Não custa dizer que reduzir estoques é
minimizar o capital alocado desnecessariamente.
A figura 3 apresenta o modelo da fábrica de bancos
construído no SNTool.
Figura 3: Modelo da fábrica de bancos construído no SNTool.
Vale lembrar que após o modelo
funcionando a inserção de mais consumidores e fornecedores seria bastante
simples e interessante para observação.
Na figura 4 é apresentado a tela do SNTool Debugger
para a simulação com um Fornecedor e um Cliente.
Figura 4: Simulação do modelo de não atendimento para
um fornecedor e um cliente.
A seguir
é apresentado uma descrição do trabalho e problemas encontrados durante a
implementação do modelo “fábrica de bancos” no SNTool.
O modelo foi construído passo-a-passo.
O primeiro passo foi a relação entre Fornecedor e
Produtor:
O Fornecedor abastecia normalmente o estoque de
matéria-prima, num esquema de parceria, contratualmente ajustado, onde a entrada do fornecedor diretamente nos estoques do Produtor é
plenamente justificado. Este tipo de relacionamento pode caracterizar Just-in-time, ou simplesmente um sistema de reposição de
estoques denominado modelo de reposição periódica, no qual o intervalo de
reposição é constante. Neste caso admitimos, também, que o lote entregue também
é constante.
A seguir foi construído o restante do modelo,
inserindo os places de estoque de produtos acabados e
de consumidor. A partir deste momento, observou-se
alguns problemas:
·
Sem nenhuma
outra função acrescentada a classe Consumidor e
certificada a construção do modelo da rede correta (verificado através da
ferramenta Validate e de extensa e exaustiva análise)
o SNTool Debugger travava
após inserir 101 objetos no estoque de matéria prima. O erro apresentado foi
transcrito a seguir.
0 ERROR [Thread-3] (Engine.java:564:run) - caught internal exception in main loop (current state = STATE_RUNNING)
ontool.engine.EngineException: Number of
combinations exceded the maximum amount specified. Increase the size.
at ontool.engine.Place.createCombsForFunction(Place.java:226)
at ontool.engine.Place.createCombs(Place.java:278)
at ontool.engine.Place.createActions(Place.java:330)
at ontool.engine.Engine.genActions(Engine.java:308)
at ontool.engine.Engine.performIteration(Engine.java:417)
at ontool.engine.Engine.performRUNNING(Engine.java:398)
at ontool.engine.Engine.run(Engine.java:525)
at java.lang.Thread.run(Thread.java:536)
java.lang.NullPointerException
at
ontool.app.debugger.DebuggerFrame$2.run(DebuggerFrame.java:468)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:178)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:448)
at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:197)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:150)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:144)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:136)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:99)
Este problema foi eliminado inserindo um “destroy();” no classe Produtor. A
seguir foram inseridos os mesmos procedimentos para a classe
Produtor e Consumidor com a finalidade de testar o fluxo da rede. Deste
lado da rede , haveria um fluxo de objetos tipo ProtudoAcabado, que seria enviado para o estoque de produto
acabado. Assim, foi implementado no Produtor o código para a criação de objetos
do tipo ProdutoAcabado e no
Consumidor foi implementado um “destroy();” para
manter o fluxo.
O teste desta situação foi positivo, não havendo nenhum
problema. Até este momento, apenas um sensor havia sido introduzido na classe
Produtor para testar a inicialização e a contagem
visando a inserção de apenas 1 ProdutoAcabado
a cada inserção de 4 de MateriaPrima.
A seguir foi implementado um teste para implementar a
situação de 4->1: ((a-(4*(a/4))) == 3), onde a
variável “a” é recebe o valor lido do sensor, incrementado a cada iteração.
Como não haveria objeto a ser excluído do estoque de ProdutoAcabado, então foi implementado um teste na
classe Consumidor para verificar a porta de entrada antes de aplicar o método “destroy();
Deste momento em diante o sistema não mais funcionou. Ao
longo das tentativas efetuadas, constatei que a linha “put_out1(new ProdutoAcabado(0));”
não consegue ser executada dentro de um if.
A
seguir é apresentado o código que acreditava-se
funcionar do modelo no SNToll para implementar o
modelo “fábrica de bancos”.
a. Classe Fornecedor:
Init
setMaxFireCount(10);
f1.perform
put_out1(new MateriaPrima(0));
f1.match
setBid(1);
b. Classe Produtor
Init
setMaxFireCount(10);
//
inicializaçao para disponibilizar o viewer
put_s1(new MateriaPrima(0));
f1.perform
// contabiliza a chegada de materia-prima
read_s1().inc();
int a = read_s1().getValue();
get_in1().destroy();
// entende que a materia-prima que chegou
//
e consumida a proporcao de 3
pes e um um assento
if ((a-(4*(a/4)))==3)
{
put_out1(new
ProdutoAcabado(0)); // coloca um banco no estoque de
produto acabado
}
f1.match
setBid(Math.random());
access_in1(Action.CONSUMPTION);
c. Classe Consumidor
Init
setMaxFireCount(10);
//
inicializa para o viewer
put_s1(new ProdutoAcabado(0));
put_s2(new ProdutoAcabado(0));
f1.perform
ProdutoAcabado pa = read_in1();
// verificad se existe
produto disponivel no estoque de pa
if (pa == null)
{
read_s2().inc();
// se nao contabiliza nao
atendimento
}
else
{
read_s1().inc();
//se sim contabiliza atendimento e
get_in1().destroy(); //retira
o produto do estoque
}
f1.match
setBid(Math.random());
access_in1(Action.CONSUMPTION);
Apesar de não ter conseguido obter os resultados desejados
com a análise do modelo “fábrica de bancos”, o tempo de dedicação tentando
encontrar soluções para os problemas apresentados deram ao estudante uma visão
mais ampla das possibilidades da ferramenta.
Esperava-se obter índices de não atendimento ao
consumidor variando ao longo do tempo, apresentados nos viewers
do Debugger do SNTool,
que seriam observados e transportados para uma planilha para verificação.
Para fins de simulação pretendia-se variar o número
de fornecedores e consumidores para verificar os limites de não atendimento, o
que não foi possível devido aos problemas enfrentados. Entretanto, a
verificação da tabela 1 seria executada:
fornecedores |
consumidores |
valor de s1 |
valor de s2 |
Nível de não atendimento
(s1/s2) |
1 |
1 |
|
|
|
1 |
2 |
|
|
|
... |
... |
|
|
|
fi |
ci |
|
|
|
Tabela 1: Planilha de
condições de simulação.
Na figura 5 é apresentada a tela de simulação para
um protótipo com três Consumidores. Lembrando que esta tela não correspondem ao
código acima, mas sim, para o exemplo onde foi forçado um nível de não
atendimento de 20% diretamente na Classe Consumidor.
Figura 5: Exemplo da simulação do SNTool para um modelo com um
fornecedor e três consumidores, com nível de atendimento de 20%