Neste Tutorial iremos demonstrar como funciona a ferramenta Model Layouts no FlexSim. Esta ferramenta permite que você crie e edite diferentes Layouts para um mesmo modelo. Você pode modificar a posição dos objetos e criar uma nova opção de Layout. Por exemplo você pode salvar um Layout inicial de seu processo e após montar propostas a serem estudadas, como um Layout com diferentes posições, redução de transporte, etc... O Model Layouts permite que você possa fazer isso. modellayouts-example-model.fsm Ferramenta útil para estudar comparativamente os resultados gráficos dos Layouts criados apenas rodando o modelo para cada um dos Layouts, e ou para criar a variável Layout para inclusão das opções de Layouts em um experimento. As informações de Layout são armazenadas em cada um dos objetos individuais. Um nó é adicionado aos atributos de objeto chamados Layouts. Para cada Layout criado, uma cópia das informações espaciais atuais do objeto (posição, tamanho, rotação) é armazenada. Janela Model Layout Esta janela pode ser acessada em: View Menu / Model Layouts Layout List - Exibe a lista de Layouts atuais. Selecione um layout para atualizar imediatamente o modelo desse Layout. Você pode renomear um Layout digitando um novo nome neste campo. Add Layout - Adiciona um novo Layout. Quando você adiciona um Layout, ele salva o Layout atual do modelo. Delete Layout - Remove o Layout selecionado. Set - Opção para atualizar o Layout do modelo selecionado para corresponder ao Layout atual do modelo indicado na lista (Layout List).

Neste Tutorial iremos demonstrar em um exemplo como funciona a biblioteca AStar Navigator no FlexSim. O AStar Navigator, também conhecido como A*, é um algoritmo de busca usado para encontrar um caminho entre pontos, e serve para determinarmos o trajeto pelo qual os executores de tarefas podem se movimentar pelo modelo. Esta biblioteca permite que você crie e defina barreiras físicas para a correta movimentação dos executores de tarefas em seu modelo. Nós iremos usar o seguinte modelo para mostrar como o A* Navigator pode ser usado em um modelo simples. astar-example-model.fsm Crie o A* Navigator Primeiro, um objeto AStarNavigator deve ser adicionado ao modelo. Somente um objeto AStarNavigator faz-se necessário e permitido por modelo. Crie um objeto AStarNavigator ao clicar e arrastar da biblioteca para qualquer posição na superfície de simulação em 3D. Conectando os Membros Neste modelo, existe apenas um objeto executador de tarefa (TaskExecuter), no entanto, nós também queremos incluir o Rack como uma barreira. Faça um conexão com o 'A' entre o AStarNavigator e o operador. Isto pode ser feito mantendo a tecla A pressionada e clicando/arrastando do AStarNavigator para o operador, ou do operador para o AStarNavigator (não importando a ordem ou sequência de onde tem que partir a conexão). Um círculo em azul irá aparecer abaixo do operador. Faça uma conexão com o 'A' entre o AStarNavigator e o Rack. Um retângulo em azul irá aparecer abaixo do Rack. Adicione um Source e um Queue próximo ao operador conforme você pode visualizar em outra imagem mais abaixo. Criando Barreiras (Barriers) Junto com o Rack, vamos também criar um par de barreiras para representar paredes ou obstáculos que o operador não pode caminhar através. Clique no ícone do Divider na biblioteca para entrar no modo de criação. Clique em algum lugar ao lado direito do Queue (buffer) para criar um novo Divider. Clique duas vezes mais próximo dos pontos para mostrar a imagem abaixo para finalizar o Divider. Clique com o botão direito do mouse para sair do modo de criação. Adicione os Processors e um Sink conforme imagens abaixo. Faça a conexão deste o Source até o Sink usando a conexão com “A”. Clique sobre o ícone Barrier na biblioteca para entrar no modo de criação. Clique uma vez onde o canto esquerdo inferior do Barrier estará como mostrado abaixo. Clique novamente no canto direito superior para completar a configuração do Barrier. Clique com o botão direito para sair do modo de criação. Coloque o Barrier abaixo do Rack. Execute o Modelo Você pode agora resetar e executar o modelo para ver como será a performance do operador. Lembre-se, se você fizer qualquer mudança nas suas barreiras, o modelo obrigatoriamente deve ser resetado antes de ser executado novamente. Note que o operador encontrou o menor caminho para movimentar-se por cima e por fora do Divider. Embora exista diversas formas de alterar os caminhos do operador (por exemplo, estender ainda mais o tamanho do Divider), nós iremos modificar o caminho percorrido pelo operador, usando o Preferred Path. Crie Preferred Paths Preferred paths não são caminhos “configuráveis”, em vez disso, dará aos nodes associados com o caminho preferido, um peso maior no algoritmo de busca. Isso vai nos afetar, e puxar o operador para o caminho preferido. Clique sobre o ícone Preferred Path na biblioteca para entrar no modo de criação. Crie os dois seguintes Preferred Paths conforme mostrado na imagem abaixo. Preferred paths são unidirecionais e além do mais precisa ser posicionado no layout na ordem correta. Clique com o botão direito do mouse para sair do modo de criação. Execute o Modelo Resete e execute o modelo. Se o seu operador continuar a movimentar para cima e fora do Divider, você pode ou movimentar o Preferred Path ou alterar o Preferred Path weight na janela de propriedades do objeto AStarNavigator. Os Resultados do seu modelo podem variar deste exemplo conforme você posiciona suas barreiras e objetos, o que pode fazer a diferença no cálculo dos caminhos do operador. AStar Navigator Library O AStar é acessado na Biblioteca principal a esquerda: View Menu / Drag-Drop Library Existem 5 tipos de barreiras usada pelo A* Navigator. Estas barreiras modificam a grade usada no algoritmo de busca. Nota: Uma vez que as barreiras são criadas ou modificadas, o modelo precisa ser Resetado para recalcular o node table. Solid Barrier A mais simples das barreiras, a barreira sólida modifica a grade para remover uma área retangular, prevenindo os membros de viajar e (travel members) se movimentarem dentro da barreira. Divider Dividers desconectam os nodes ao longo de seu caminho, prevenindo os travel members de atravessarem o divider. Dividers podem ser modificados na superfície de simulação 3D ao arrastar o ponto final e intermediário. Qualquer número de pontos pode ser adicionado ao divider. One-Way Divider O One-way divider funciona de forma muito similar ao divider, no entanto, travel members são permitidos se movimentarem através do divider na direção das flechas em verde, neste caso, em direção ao topo da página. O one-way dividers pode ser modificado na superfície de simulação em 3D ao arrastar os pontos finais ou intermediários. Qualquer número de pontos podem ser adicionados em um one-way divider. Preferred Path Embora o preferred path não é uma barreira real, ele funciona da mesma forma que as barreiras fazem para modificar a tabela de nodes do A* Navigator. Em vez de modificar os nodes removendo os seus indicadores de direção, o caminho preferencial dá um peso maior a todos os nós associados com o percurso. Este valor de Path Weight pode ser alterado através da janela de propriedades do A * Navigator. O Path Weight tem de ser maior do que 0 e menor que 1, a fim de funcionar adequadamente. Valores acima ou abaixo deste podem causar resultados não intencionais. Os preferred paths podem ser modificados na visualização em 3D, arrastando os pontos do fim ou do meio. Preferred paths são unidirecionais. Qualquer número de pontos pode ser adicionado a um preferred path.

Nesse exemplo nós vamos construir um modelo que usa listas para relações básicas de roteamento de itens. Os itens serão enviados de três filas para um dos quatro processos. Nós vamos usar uma Lista de itens (item list). As filas irão empurrar os itens para a lista e os processos irão puxar os itens da lista e processa-los. Inicialmente, vamos implementar um simples puxado, mas depois iremos experimentar o puxado com restrições e priorizações. Passo 1. Montar Layout Para esse exemplo, criaremos um novo layout. A Figura 1 mostra quais objetos devem estar presentes nesse layout. Observe que NÃO há ligação entre as filas e os processos. Figura 1- Layout exemplo 2 Passo 2. Configurar source Na janela de propriedades do source, em inter-Arrivaltime coloque exponential (0 ,2.5,0). Figura 2- Inserir inter- arrival time 2.Na aba FLOW, em send to port abra a lista de opções e escolha a opção random port. Figura 3- Sent to port 3.Na aba trigger, adicionar uma Oncreation trigger para configurar o tipo e a cor. OnCreation> Data > Set item type and color Figura 4- Configurar tipo e cor Passo 3. Adicionar lists Para adicionar a lógica é preciso criar um item list. Em Toolbox> > Global list> Item list(Figura 5). Figura 5- Adicionar item list Ao clicar em Item list irá abrir janela de propriedades da lista (Figura 6), por agora apenas feche a aba. A sua lista está nomeada como ItemList1. Figura 6- Janela de propriedades Itemlist Não é necessário definir nenhuma das configurações agora. Apenas feche a janela de propriedades. Passo 4. Configurar queue Para configurar a queue para empurrar os itens para a lista, clique sobre cada uma das filas> Aba Flow> Send to port> abra a lista de opções> Escolha use list> Push to item list. CONFIRA se o o nome da lista corresponde ao nome da lista que você criou. Figura 7- Push to item list OBS: Fazer o Passo 4 para (((TODAS))) as filas Passo 5. Configurar Processos Para fazer com que os processos puxem da lista, nós precisamos configurar cada input de processos para todos os 4 processos. Clique em um dos processos, na aba Flow vá na parte de input, marque a opção pull strategy. Na aba de escolha da estratégia >Use list>Pull from item list. Você pode deixar o campo QUERY em branco. E confira se o nome da lista escolhida é o mesmo da lista que você criou no Passo 3. Figura 8- Estratégia puxada Obs: Não esqueça de fazer o passo 5 para todos os processors. Salve seu modelo como Exemplo 2 e ele está pronto para ser executado. Mas antes de fazer isso vamos dar uma olhada no que está na lista. Para verificar se até aqui as coisas estão funcionando da maneira correta. Vamos fazer um test rápido. Nas propriedades do ItemList1, vá na aba General e clique no botão a esquerda “ Back Orders”, sua lista deve estar parecida com a da Figura 9. Mudando apenas os nomes dos processos de acordo como os seus estão nomeados. Figura 9- Janela de pedidos pendentes A Figura 9 representa que os processos começaram a puxar da lista, mas como não há itens que foram empurrados para a lista, eles estão aguardando para poderem puxar e se tornarem fulfilled(preenchidos). Execute o modelo e você perceberá os itens vão entrar nas filas e serão empurrados para a lista (View entries) fazendo com que os pedidos pendentes sejam atendidos e então começam a ser processados. Quando um item é empurrado para a lista e existe pedidos pendentes o item será imediatamente puxado da lista. Dessa forma o pedido pendente irá se tornar Fulfilled e será removido da lista de pedidos pendentes. Eventualmente, todos os processos irão puxar os itens e dessa forma a lista de pedidos pendentes se tornará vazia, já que todos estão em operação. Então a lista de entradas vai crescendo(Figura 10) até que um dos processos termine o processamento e requisite puxar um item da lista. Figura 10- Entradas na lista aguardando serem puxadas Quando os itens são empurrados para a lista, eles são adicionados no fim da lista. Assim se o sistema puxado não utilizar prioridades como parte da sua tomada de decisão, os itens irão ser puxados como FIFO( first-in-first-out), ou seja, seguindo uma ordem de quem chegou primeiro sai primeiro. O mesmo acontece com os pedidos pendentes pendentes. A primeira máquina que ficar disponível irá puxar o primeiro item que entrar na lista. exemplo2.fsm Experimentos Agora vamos experimentar diferentes configurações das operações puxadas. Cenário 1- Filtrar por tipo de item Vamos considerar que um dos processos pode apenas processar o tipo de item 2. Nós podemos vincular essa lógica na simulação utilizando uma simples Query nesse processo. Clique sobre o processo que deseja restringir a entrada ao tipo 2 de item, na janela de propriedades, vá em FLOW > >Pull strategy >em Query digite a restrição WHERE itemtype == 2 (Figura 11). Figura 11- Adicionar query para tipo de item Salve o modelo como Exemplo2_cenario1. Reset seu modelo e execute. exemplo2-cenario1.fsm Cenário 2- Puxar pelo LIFO Vamos supor que agora queremos que todos os processos puxem seguindo a ordem último a chegar primeiro a sair (LIFO) ao invés do padrão FIFO, o que significa que o item mais recentemente adicionado na lista deve ser o primento a ser puxado da lista. Nós podemos criar essa lógica na simulação, implementando uma simples puxada Query. Abra o arquivo do exemplo 2, e salve como exemplo2_cenario2. Para cada um dos 4 processos faça o seguinte: 1)Clique no processo >vá em FLOW > Pull strategy > em Query digite a restrição ORDER BY age ASC (Figura 12). Figura 12- Lógica LIFO Repita 1) para TODOS os processos. Salve o modelo e coloque para executar. exemplo2-cenario2.fsm Use a ferramenta avançada view entry Nessa ferramenta você pode verificar se o seu modelo está rodando de acordo com a lógica planejada. Por exemplo, se você quiser testar o seu query de order by age asc para você ter certeza de o que você quer antes de implementar no modelo. Você pode usar a ferramenta avançada para fazer isso. Execute o modelo até que tenha um número significativo de itens na lista. Nas propriedades do ItemList1, vá na aba General e clique no botão a esquerda “ View entries”. Pressione botão para mostra as ferramentas avançadas (Figura 13). Figura 13- Ferramentas avançadas view entry Agora teste colocar a Query por ORDER BY age ASC e pressione enter (Figura 14). Figura 14- Itens ordenados por tempo Na Figura 14 você pode notar que os itens na lista estão agora reorganizados com as idades ascendentes. A ordem puxada que usa a query order by age asc, vai puxar do topo dessa lista. No caso o primeiro a ser puxado seria o Queue5/Box~3 com itemtype de 3 e age de 0. 18, o último a entrar na fila.

Neste Tutorial iremos demonstrar como importar um Layout do AutoCad no FlexSim. Desenhos do AutoCAD e outras imagens podem ser usadas como planta baixa para a montagem do modelo de simulação no FlexSim, sendo facilmente importadas usando o Background Drawing Wizard. Isto facilita a construção do modelo de simulação fazendo com que o modelador possa posicionar os objetos de forma rápida e em escala. O Background Drawing Wizard pode ser acessado clicando em: Tools / Visual / Model Background , ou na Biblioteca de Objetos / Visual / Background arrastando o objeto para o plano. O assistente abre uma nova janela, e irá pergunta-lo se você quer importar um desenho CAD ou um arquivo de imagem. Assegure-se que "AutoCAD Drawing" está selecionado e então clique em "Next". A próxima tela irá pedir a você que especifique o caminho do arquivo CAD que você quer usar; busque o arquivo em seu computador e clique em "Open". Veja que você está usando um arquivo .dwg; arquivos .dxf e .dwg podem ser importados para o FlexSim. Clique em "Next" novamente para ir para a próxima tela. Nesta tela você poderá definir detalhes sobre o posicionamento do seu layout no plano de trabalho do FlexSim. Existem três colunas representando os eixos X, Y e Z e três linhas para cada um que correspondem a posição, rotação e tamanho ao longo de cada eixo. Configure a posição para cada eixo em "0" e você verá a posição original do desenho, localizado no canto esquerdo inferior, mostrando exatamente que está no centro do seu modelo. Clique em "Next" para seguir para a próxima tela. Nesta tela você pode customizar qual layers de seu desenho CAD estarão visíveis, e ainda alterar a cor de cada layer. Se você tiver algum recurso no desenho que não é necessário para o modelo de simulação, como por exemplo, uma parede ou uma porta, talvez possa ser uma boa idéia fazer com que estes layers fiquem invisíveis e então o espaço visual não se torne confuso. Clique em "Next" para ir para a tela final. Clique em Finish e pronto! Agora você já pode começar a montar seu modelo utilizando o Layout em AutoCad como planta baixa.

Lembre-se que para o desenvolvimento desse passo a passo, foi utilizado a versão 2017. Update 1, caso você esteja modelando utilizando outra versão algumas alterações podem ser necessários. Nesse exemplo será construído um modelo que usa listas para relações básicas de roteamento de itens. Os itens serão enviados de três filas para um dos quatro processos.Uma lista de itens (item list) será utilizada para resolver esse problema. As filas irão empurrar os itens para a lista e os processos irão puxar os itens da lista e processa-los. De início será construído um modelo puxado simples,e depois um modelo puxado com restrições e priorizações. Passo 1. Montar Layout Para esse exemplo, crie um novo layout. A Figura 1 mostra quais objetos devem ser adicionados Observe que NÃO há ligação entre as filas e os processos. Figura 1- Layout exemplo 2 Passo 2. Configurar source Na janela de propriedades do source, em inter-arrivaltime coloque exponential (0 ,2.5,0). Figura 2- Inserir inter- arrival time 2.Na aba FLOW, em send to port abra a lista de opções e escolha a opção random port. Figura 3- Sent to port 3. Na aba trigger, adicione uma Oncreation trigger para configurar o tipo e a cor. OnCreation> Data > Set item type and color> duniform(1,3). Figura 4- Configurar tipo e cor Passo 3. Adicionar lists Para adicionar a lógica é preciso criar um item list. Em Toolbox> > Global list> Item list(Figura 5). Figura 5- Adicionar item list Ao clicar em Item list irá abrir janela de propriedades da lista (Figura 6), por agora apenas feche a aba. A sua lista deve estar nomeada como ItemList1. Figura 6- Janela de propriedades Itemlist **Não é necessário definir nenhuma das configurações agora. Apenas feche a janela de propriedades.** Passo 4. Configurar queue Para configurar a queue para empurrar os itens para a lista, clique sobre cada uma das filas> Aba Flow> Send to port> abra a lista de opções> Escolha use list> Push to item list. CONFIRA se o o nome da lista corresponde ao nome da lista que você criou. Figura 7- Push to item list **OBS: Faça o Passo 4 para TODAS as filas** Passo 5. Configurar Processos Para fazer com que os processos puxem da lista, configure cada input de processos para todos os 4 processos. Clique em um dos processos, na aba Flow vá na parte de input, marque a opção pull strategy. Na aba de escolha da estratégia(Pull Strategy) >Use list>Pull from item list. Deixe o campo QUERY em branco. E confira se o nome da lista escolhida é o mesmo da lista que você criou no Passo 3. Figura 8- Estratégia puxada **Obs: Faça o Passo 5 para todos os processors.** Faça um test rápido! Reset seu modelo e confira como estão as entradas e saídas da sua lista, para verificar se até aqui as coisas estão funcionando da maneira correta. Nas propriedades do ItemList1, vá na aba General e clique no botão a esquerda “ View Back Orders”. Figura 9- View Back Orders Sua lista deve estar parecida com a da Figura 10. Mudando apenas os nomes dos processos de acordo como os seus estão nomeados. Figura 10- Janela de pedidos pendentes A Figura 10 representa que os processos começaram a puxar da lista, mas como não há itens que foram empurados para a lista, eles estão aguardando para poderem puxar e se tornarem fulfilled(preenchidos). Execute o modelo (Run) e você perceberá os itens entrando nas filas e sendo empurrados para a lista (View entries-Figura 9) fazendo com que os pedidos pendentes sejam atendidos e então começam a ser processados. Quando um item é empurrado para a lista e existe pedidos pendentes o item será imediatamente puxado da lista. Dessa forma o pedido pendente irá se tornar Fulfilled e será removido da lista de pedidos Back Orders. Eventualmente, todos os processos irão puxar os itens e dessa forma a lista de pedidos pendentes se tornará vazia, já que todos estão em operação. Então a lista de entradas vai crescendo(Figura 11) até que um dos processos termine o processamento e requisite puxar um item da lista. Figura 11- Entradas na lista aguardando serem puxadas Quando os itens são empurrados para a lista, eles são adicionados no fim da lista. Assim se o sistema puxado não utilizar prioridades como parte da sua tomada de decisão, os itens irão ser puxados como FIFO( first-in-first-out), ou seja, seguindo a ordem de quem chegou primeiro sai primeiro. O mesmo acontece com os pedidos pendentes, a primeira máquina que fica disponível puxa o primeiro item que está na lista. Salve seu modelo e ele está pronto para ser executado. ex2.fsm Modelos experimentos Para testar diferentes configurações das operações puxadas faça os seguintes cenários. Cenário 1- Filtrar por tipo de item Considere que um dos processos (Processor 1) pode apenas processar o tipo de item 2. Para vincular essa lógica na simulaçao utilize um Query nesse processo. Clique sobre o processo que deseja restringuir a entrada ao tipo 2 de item, na janela de propriedades, vá em FLOW > Pull strategy > em Query digite a restrição WHERE Type == 2 (Figura 12). Figura 12- Adicionar query para tipo de item Salve o modelo como Exemplo2_cenario1. Reset seu modelo e execute. ex2cenario1.fsm Cenário 2- Puxar pelo LIFO Agora todos os processos puxam seguindo a ordem último a chegar primeiro a sair (LIFO) ao invés do padrão FIFO, o que significa que o item mais recentemente adicionado na lista deve ser o primeiro a ser puxado . Crie essa lógica na simulação, implementando um Query. Abra o arquivo do exemplo 2, e salve como exemplo2_cenario2. Para cada um dos 4 processos faça o seguinte: Clique no processo >vá em FLOW > Pull strategy > em Query no adicionar> ORDER BY> AGE (Figura 13). Figura 13- Lógica LIFO Repita o 1) para TODOS os processos. Salve o modelo e coloque para executar. ex2cenario2.fsm

Cycle time per process.fsm When we create simulation models, sometimes we limit ourselves to modeling a process or a part number, in which we have problems. But what happens when we run a complete production plan with different part numbers, which in turn run at different cycle times? This is a way that allows you to run different part numbers in as many different processes as you want, each with its own cycle time. What do we need? 1.- Label on each item that identifies what part number it is. For example • Label: IDpart Value: ABC12 2.-Label on each machine that identifies the process that it runs. For example • Label: Station Value: Processor1 3.- Global table that contains in the columns the different processes that you have in your production line and in the rows the different part numbers that can run in your line. The information contained in this table will refer to the cycle times of each part number in each process. For example: Processor1 Processor2 Processor3 ABC12 20 10 13 BAC21 11 30 20 4.-You must configure the processing time of your processor referring to your global table and placing the following: With this, we will obtain weighted usage statistics for the equipment. Benefits: 1. You can run different part numbers on the same line with their respective cycle time each. 2. More accurate use of equipment and operators. 3. Modifying cycle times in a global table is easier and more controlled than directly in the processes. 4. Calculation of the capacity of your line running a real production plan will be accurate. 5. You can add and remove processes or even modify the flow of your line without affecting the cycle time that processor runs. Since it is referenced by its label to the global table.

Receiving products from the bottled water manufacturing plant using 11 Rial Guide Vehicles (RGVs) for transportation to the Automated Storage and Retrieval System (ASRS), which serves all three production lines. The RGVs' operation works as follows: when products are placed in the receiving buffer with two available positions, the system immediately sends commands to the RGVs to pick up the products from the buffer. The RGVs prioritize picking up the nearest products first. Consequently, the production line located farthest away (Production Line 1) experiences the highest downtime from January to May 2566, with an average downtime of 449.48 minutes. Production Line 2 has an average downtime of 65.12 minutes, while Production Line 3 experiences 76.00 minutes of downtime during the same period. If a production line stops for more than 20 minutes, it requires a complete drainage of the ongoing production process, including scrapping all unfinished goods. This significantly increases the production costs. Consequently, conducting experiments to address this issue becomes complicated, as full-scale production is necessary to identify the causes and implement effective solutions. Thus, stopping production for testing purposes is not a viable approach in this case.