História da Modelagem por Simulação

O desafio

por Stephen D. Roberts (Universidade Estadual da Carolina do Norte) e Dennis Pegden (Simio LLC)

Conforme apresentado na Conferência de Simulação de Inverno de 2017

Durante a última metade do século passado, a simulação avançou como uma ferramenta de escolha para a análise de sistemas operacionais. Os avanços na tecnologia estimularam novos produtos e novos ambientes sem padrões de software ou uniformidade metodológica. Cada nova linguagem ou produto de simulação oferece seu próprio conjunto exclusivo de recursos e capacidades. No entanto, esses produtos de simulação são a evolução da pesquisa, do desenvolvimento e da aplicação. Neste documento, interpretamos o desenvolvimento histórico da modelagem de simulação. Em nossa opinião, a modelagem de simulação é a parte do processo de resolução de problemas de simulação que se concentra no desenvolvimento do modelo. É a interpretação de um problema real de produção (ou serviço) em termos de uma linguagem de simulação capaz de realizar uma simulação desse processo do mundo real. Embora a "interpretação" esteja nos "olhos de quem vê" (ou seja, nós), existem alguns pontos de vista e métodos históricos que influenciam o design do modelo de simulação.

Introdução

Modelos vs. Modelagem

Modelos matemáticos e estatísticos formais de operações foram desenvolvidos ao longo de várias décadas de pesquisa. No entanto, quando um modelo é aplicado além de suas suposições, ele deixa em aberto a questão de sua aplicabilidade e o modelador se depara com a adaptação do modelo ou o desenvolvimento de um novo modelo. A adaptação ou criação de um novo modelo analítico é uma tarefa significativa que desafia as habilidades analíticas do desenvolvedor e pode exigir muito mais tempo e esforço, talvez sem resultados tangíveis.

O valor de um modelo é o seu uso. Como os modelos individuais têm limitações e sua extensão pode ser assustadora, alguns pesquisadores e profissionais preferem um ambiente de modelagem mais flexível. Há muito tempo, a simulação é vista como uma ferramenta de modelagem que tem um ambiente de desenvolvimento muito amplo e não exige sofisticação matemática ou estatística para o desenvolvimento e uso do modelo. Além disso, para aliviar o ônus do desenvolvimento de modelos de simulação, foram desenvolvidas várias linguagens de simulação. Cada linguagem de simulação oferece suas próprias construções de modelagem nas quais um modelo de simulação pode ser construído, simulado e analisado. Embora as linguagens tenham mudado ao longo do tempo, a abordagem de modelagem está intrinsecamente ligada à sua perspectiva de execução de simulação.

Modelagem

O objetivo deste documento é fornecer um histórico personalizado (e, portanto, limitado) da modelagem de simulação, já que ela foi amplamente popularizada por meio da Winter Simulation Conference. O uso da simulação em um contexto de solução de problemas requer várias habilidades:

• Definir o problema corretamente e estabelecer os objetos.
• Usar conceitos de modelagem para abstrair os recursos essenciais do sistema em um modelo.
• Coleta e compilação de dados e entradas para o modelo.
• Converter o modelo em um código legível por computador que seja capaz de simular o sistema.
• Instruir o computador a executar a simulação de forma correta e eficiente em vários cenários.
• Resumir e analisar o resultado da simulação em medidas de desempenho.

Kiviat (1967) foi um dos primeiros a descrever o processo de modelagem e as proficiências necessárias. Um usuário com conhecimento profundo de quase todas as linguagens de programação de uso geral pode oferecer a maioria dessas habilidades. No entanto, o ônus de realizar uma simulação final é formidável, pois o programador precisa fornecer um software para realizar todos os componentes necessários, incluindo geração de números aleatórios, geração de variantes aleatórias, atualização de status e avanço de tempo, coleta e exibição de estatísticas etc. Realizar tudo isso em um único modelo é geralmente proibitivo, e existem linguagens de simulação e bibliotecas de simulação para aliviar o fardo da criação de simulações.

Embora muitas linguagens de simulação tenham surgido e desaparecido, as abordagens fundamentais de simulação são semelhantes. Uma linguagem de simulação executa um modelo do sistema para representar dinamicamente o comportamento do sistema real ao longo do tempo. Isso é feito alterando o valor das variáveis de estado ao longo do tempo simulado. Em geral, as linguagens de simulação podem ser categorizadas em duas grandes famílias: discreta e contínua. As ferramentas discretas modelam sistemas em que o estado do sistema muda em unidades discretas em momentos específicos do evento. As ferramentas contínuas modelam sistemas em que o estado do sistema muda continuamente em partes do tempo. O foco aqui são os sistemas discretos, embora os sistemas contínuos também sejam considerados. Atualmente, a maioria das linguagens de simulação é multimodal e oferece suporte a vários paradigmas de modelagem que geralmente combinam recursos discretos e contínuos.

A solução

Modelagem de visões de mundo

Uma simulação discreta consiste em um conjunto de variáveis de estado e um mecanismo para alterar essas variáveis em momentos de eventos. Uma visão de mundo de modelagem de simulação fornece ao profissional uma estrutura para definir um sistema para atingir os objetivos com detalhes suficientes para que ele possa simular o comportamento do sistema. Diferentemente de ferramentas descritivas estáticas simples, como fluxograma(https://en.wikipedia.org/wiki/Flowchart), Visio(https://en.wikipedia.org/wiki/Microsoft_Visio), IDEF(https://en.wikipedia.org/wiki/IDEF), UML(https://en.wikipedia.org/wiki/Unified_Modeling_Language)etc., uma visão de mundo de modelagem de simulação deve levar em conta com precisão as transições dinâmicas de estado que ocorrem ao longo do tempo. A visão de mundo fornece um conjunto definitivo de regras para avançar no tempo e alterar o estado discreto (ou contínuo) do modelo.

Ao longo dos 60 anos de história da simulação, julgamos que quatro visões de mundo distintas predominam em uso: evento, atividades, processo e objetos (embora outras terminologias e taxonomias tenham sido oferecidas) (consulte Overstreet e Nance 1986). Todas elas foram desenvolvidas pelos pioneiros da simulação na década de 1960 (Gordon 1961; Markowitz et al. 1962; Tocher 1963; Dahl e Nygaard 1966), embora essas visões de mundo tenham sido significativamente refinadas nos últimos 50 anos, as ideias básicas não mudaram. A evolução das ferramentas de modelagem tem se concentrado em alcançar um equilíbrio entre facilidade de uso e flexibilidade. A visão de mundo do evento oferece a maior flexibilidade, mas é mais difícil de usar. A visão de mundo baseada em atividades oferece mais contexto às atividades, mas com algumas restrições na modelagem. A visão de processo é mais fácil de usar, mas ao preço de uma menor flexibilidade de modelagem. A visão de objeto é a mais fácil e mais natural de todas, mas também tem o preço de uma maior complexidade de modelagem. A história do desenvolvimento da linguagem de simulação tem se concentrado em tornar as visões de processo e de objeto mais flexíveis, mantendo a vantagem da facilidade de uso. Ao mesmo tempo, a maioria das linguagens de simulação modernas combina seus métodos de execução (usando processamento de eventos para eventos futuros e varredura de eventos atuais) e emprega representação multimodal (como redes, processos, dinâmicas), de modo que não se enquadram convenientemente em uma taxonomia simples.

Modelagem com eventos

Os eventos são pontos sequenciais no tempo em que o sistema muda de estado. É responsabilidade do modelador garantir que os eventos sejam reconhecidos e que as mudanças de estado ocorram. A decisão sobre os eventos é uma escolha do modelador e nem sempre é óbvia. Essa escolha é regida em parte pelo comportamento do sistema, mas também pela natureza das medidas de desempenho necessárias para a simulação. Decidir sobre os eventos é apenas parte do desafio. Quando um evento ocorre, é necessário mapear a transição do estado atual para o estado sucessor. Além disso, deve haver algum meio de manter e adicionar eventos em série. E a saída apropriada deve ser coletada e exibida.

O ponto central da modelagem com eventos é a função do calendário de eventos futuros (cuja estrutura de dados real evoluiu e pode variar) que mantém todos os eventos futuros. Uma linguagem de simulação de eventos discretos geralmente funciona (1) removendo o próximo evento no calendário de eventos e atualizando o tempo de simulação para esse tempo de evento e (2) executando procedimentos de atualização de estado associados a esse evento.

A lógica de eventos pode ser implementada em qualquer linguagem de programação de uso geral, como Fortran, C++, C#, etc. Entretanto, como várias funções de simulação, como geração de variantes aleatórias e programação de eventos, são comuns à maioria das simulações, o uso de uma biblioteca dessas funções no contexto de uma linguagem de programação facilita muito o desenvolvimento do programa de simulação. Exemplos são o uso do Fortran aumentado pelo GASP (Pritsker e Kiviat 1969) e a programação em linguagem C com o CSIM (Schwetman 1986). Por outro lado, o SIMSCRIPT II.5 (Russell 1983) forneceu sua própria linguagem de programação para aumentar sua biblioteca de simulação. Ele também adicionou recursos básicos para definir entidades, atribuir atributos a entidades e coletar entidades em conjuntos.

As ferramentas de visão de mundo de eventos foram amplamente utilizadas durante os primeiros 20 anos de simulação. Essas ferramentas foram preferidas por muitos porque eram muito flexíveis e podiam ser usadas para modelar com eficiência uma ampla gama de sistemas complexos. Observe que, durante esse período, a eficiência era mais importante porque os computadores tinham menos memória e eram significativamente mais lentos. No entanto, os modelos baseados em eventos geralmente eram difíceis de entender e depurar e exigiam proficiência em programação, o que limitava seu uso geral.

Possivelmente devido à sua generalidade, não há ferramentas amplamente aceitas para modelagem com eventos. Normalmente, os modeladores usam fluxogramas e desenhos informais. Alguns defendem as redes de Petri (Haas 2002) e os fluxogramas de sinais. Um método geral de modelagem visual de eventos discretos são os gráficos de eventos, que foram introduzidos por Schruben (Schruben 1983). Embora o gráfico de eventos seja uma ferramenta valiosa para a compreensão da simulação de eventos discretos, seu uso como veículo de modelagem geral é bastante limitado, e são necessárias várias extensões e aprimoramentos para seu uso geral.

Modelagem com atividades: A abordagem em três fases

A modelagem com foco em eventos tem dominado o desenvolvimento de modelos de simulação em geral na comunidade norte-americana, enquanto uma abordagem ligeiramente diferente da modelagem discreta, chamada de abordagem trifásica, foi iniciada por K. D. Tocher na Inglaterra (consulte Hollocks 2008). Pidd (Pidd 2004) descreve um método relacionado chamado varredura de atividades. As atividades (operações iniciadas por eventos) formam a base das mudanças de estado quando os eventos ocorrem. O método de três fases evoluiu, mas consiste essencialmente em (1) avançar o tempo para o próximo evento (chamado de próximo evento vinculado (dependente do tempo)), (2) processar um ou mais eventos vinculados seguintes e (3) processar todas as outras ações condicionadas à ocorrência dos eventos vinculados. Embora seja necessário um calendário de eventos futuros, também são necessárias listas de eventos vinculados e condicionais. Essas listas de eventos de condições posteriores (dependentes do estado) são reescaneadas até que nenhuma atividade possa ser iniciada.

O ponto central da abordagem de três fases é o uso de uma ferramenta de modelagem conceitual agora chamada de "Diagrama do ciclo de atividades" (originalmente chamado de "gráfico de roda"). Para identificar as atividades em qualquer sistema, é útil identificar primeiro os tipos de entidades que participam das atividades. Por exemplo, podem ser trabalhos e um operador. Os trabalhos chegam, esperam pela máquina e depois saem. O operador configura a máquina e depois a opera. Caso contrário, o operador fica ocioso quando não há trabalhos a serem usinados. A usinagem, a configuração e a chegada são atividades vinculadas, enquanto a espera e a ociosidade são condicionais, dependendo das ações vinculadas. Aqui, o diagrama de ciclo de atividade é usado para identificar os elementos da simulação de três fases.

Modelagem de processos

A modelagem de processos, principalmente na forma do GPSS (Gordon 1961), surgiu paralelamente ao desenvolvimento da modelagem de eventos e atividades. O GPSS, desenvolvido na IBM, era uma ferramenta de modelagem e também uma linguagem de simulação. Ele via o mundo como entidades (chamadas de Transações) que se moviam em um modelo composto de blocos para fins especiais. Cada bloco tinha uma determinada funcionalidade. Há uma correspondência quase que individual entre o diagrama de blocos e o código de simulação. Portanto, o modelo de simulação tem uma interpretação visual e também uma interpretação escrita. Essa correspondência é importante porque o modelador do GPSS pode essencialmente traduzir o modelo visual quase diretamente em um modelo de "declaração" e, em vez da sintaxe da linguagem, uma semântica visual tornou-se o principal meio de modelagem. Essa abordagem significava que o modelador de simulação não precisava ser um programador e, portanto, o GPSS trouxe um grande número de pessoas que tentavam a simulação e que, de outra forma, não participariam. O interesse pelo GPSS foi ainda mais estimulado pelo livro clássico Simulation Using GPSS (Schriber 1974), de Tomas J. Schriber, da Universidade de Michigan, em 1974. Esse livro foi um dos primeiros a argumentar que a modelagem de simulação deveria ser feita de forma estruturada.

Embora o GPSS tenha sido amplamente reconhecido como fácil de aprender e usar, muitas questões foram levantadas sobre sua eficiência de execução. No GPSS, a simulação é executada a partir de duas listas: um calendário de eventos futuros e um calendário de eventos atuais. À medida que as entidades são geradas, elas avançam pelo diagrama de blocos o máximo que podem. Se encontrarem um bloco que possa programar sua partida para um momento posterior, essa entidade será colocada no calendário de eventos futuros. No entanto, se a entidade não puder prosseguir (talvez os recursos não estejam disponíveis), ela será colocada no calendário de eventos atuais. O calendário de eventos atuais é examinado e reanalisado até que não haja mais ações (algo semelhante à varredura de atividades) e, em seguida, o próximo evento é removido do calendário de eventos e o tempo é avançado. Essa varredura do calendário de eventos atuais, juntamente com vários outros problemas, foi a base de uma versão bastante aprimorada do GPSS em 1983, chamada GPSS/H (Henriksen e Crain, 1983), que conseguiu reduzir a execução por um fator de quatro ou mais, incluindo o fato de que o GPSS/H foi compilado enquanto as versões da IBM foram interpretadas.

Inspirada pela ampla aceitação da modelagem de blocos do GPSS, foi desenvolvida uma série de novas linguagens de processo (final da década de 1970 e início da década de 1980), com base em redes de blocos (nós). Entre elas estão o QGERT (Pritsker, 1979) e o SLAM (Pegden e Pritsker, 1979). No início da década de 1980, surgiu o computador pessoal, e o SIMAN (Pegden, 1982) foi uma das primeiras linguagens de simulação a ser executada nessa plataforma. O SIMAN também empregava blocos estilizados para criar um modelo de entidades que fluíam por uma rede de locais de processamento individuais.

As linguagens de modelagem de processos geralmente adotavam o uso do calendário de eventos futuros e do calendário de eventos atuais. No entanto, para reduzir a varredura do calendário de eventos atuais, foram adicionadas eficiências para incorporar um relógio de tempo real no lugar de um relógio de tempo inteiro e eliminar a varredura de entidades e eventos atuais cujo status não mudará (como estar em uma fila atrás de outros). Outros aprimoramentos ocorridos na década de 1980 foram a geração aprimorada de números aleatórios e variantes aleatórias, a redução de variância, o gerenciamento eficiente do calendário e a coleta mais eficiente de estatísticas. Poucos modeladores estavam cientes desses aprimoramentos, pois as linguagens de simulação passaram a ser identificadas mais intimamente com as organizações comerciais que as desenvolveram e mantiveram e consideraram suas operações internas como propriedade intelectual. A relação de um para um entre a linguagem de simulação e a organização comercial continua em grande parte até hoje.

Uma das vantagens importantes da orientação ao processo é que o modelo do processo é definido graficamente na forma de um fluxograma (consulte Fishman 1973). Portanto, o usuário não precisa ser um programador para poder criar um modelo do sistema. Comparando o modelo de processo com a abordagem de evento, a lógica do modelo é muito mais simples de definir e entender/aprender e requer pouca habilidade de programação. No entanto, as linguagens de simulação de processos têm limitações inerentes, pois nem toda situação tem um bloco correspondente na linguagem. Por exemplo, em uma sala de emergência, o paciente pode ser visto como uma entidade que se move pelos blocos de operação, mas há recursos que também se movem e que não são bem modelados por entidades. Eventualmente, um modelador de processos "bate na parede" em termos de representação e precisa encontrar uma representação menos aceitável na linguagem atual ou encontrar outra maneira de adicionar o recurso necessário (geralmente por meio de programação).

Outro avanço conceitual que ocorreu com a modelagem de processos foi a introdução de ferramentas de modelagem hierárquica que apoiaram a ideia de bibliotecas de processos específicos de domínio. O conceito básico é permitir que um usuário defina suas próprias etapas e blocos de processo combinando etapas e blocos de processo existentes. O sistema de modelagem Arena(https://www.arenasimulation.com/), amplamente utilizado, é um bom exemplo desse recurso. Em 1992, Cota e Sargent (Cota e Sargent 1992) acrescentaram a modularização e o encapsulamento de processos, o que resultou posteriormente em Gráficos de Fluxo de Controle Hierárquico, que forneceram representação gráfica (e computação) de modelos de simulação (Sargent 1997). A SLX (Henriksen 1995) é um exemplo de linguagem orientada a processos mais recente, desenvolvida em uma estrutura orientada a objetos.

Modelagem orientada a objetos

Outra visão da modelagem de processos é que um modelo é um conjunto de processos que interagem ou, de forma mais geral, objetos. O Simula (Dahl e Nygaard 1966), desenvolvido na década de 1960, forneceu uma implementação inicial promovendo a ideia de objetos como elementos da simulação e que esses objetos podem incluir ações descritas pela lógica que controla esse objeto e que podem interagir de forma síncrona ou assíncrona com outros objetos (algumas ideias evoluíram da linguagem de inteligência artificial List 2 - (consulte Nygaard e Dahl 1981). Embora tenha sido desenvolvida no início da década de 1960 como uma linguagem de simulação, ela raramente era reconhecida na América do Norte e não era amplamente distribuída nos EUA. Parte do motivo de sua exposição limitada foi o fato de ser uma linguagem de programação de simulação baseada em Algol, portanto, além de oferecer alguns conceitos de simulação muito exclusivos, ela exigia um software/hardware exclusivo (para os EUA). O valor do Simula, em retrospectiva, foi uma contribuição importante para a simulação, mas foi mais amplamente apreciado na comunidade de programação primeiro. Com o crescimento da simulação orientada a objetos, o Simula foi redescoberto como precursor de muitas linguagens de simulação atuais.

A modelagem de simulação orientada a objetos geralmente se divide em dois campos. O primeiro, exemplificado pelo Simula, é que a linguagem de simulação deve conter conceitos orientados a objetos que permitam ao modelador desenvolver programas de simulação sofisticados. Nessa abordagem, conceitos como tipos de dados abstratos, herança, polimorfismo, composição, tipos parametrizados etc. são relevantes porque permitem uma ampla gama de objetos e comportamentos. Os modelos são compactos, eficientes e extensíveis. Em outras palavras, eles são um ambiente melhor para a programação de simulação. Atualmente, os modelos costumam ser criados em C++ ou Java no contexto de pacotes de simulação.

As ideias introduzidas pelo Simula fornecem a base para alguns avanços recentes feitos pelos projetistas de linguagens de simulação para tornar a abordagem orientada a objetos da modelagem fácil de usar e flexível. Embora essas ideias tenham sido introduzidas como conceitos de modelagem de simulação, elas mudaram completamente o projeto e a implementação de ferramentas de programação em geral. As ideias do Simula influenciaram diretamente muitas linguagens de programação posteriores, incluindo Smalltalk, LISP, C++, Java e C#. As ideias orientadas a objetos introduzidas pelo Simula não são apenas o desenvolvimento mais significativo no software de simulação, mas talvez o maior avanço na ciência da computação nos últimos 50 anos.

Além da simulação como um desafio de programação, o outro campo de modelagem de simulação orientada a objetos vê a simulação orientada a objetos como composta de uma ampla gama de objetos predefinidos, cada um com um conjunto de comportamentos considerados relevantes para o controle e o uso dos objetos. Essa orientação de modelagem simplifica o processo de construção de modelos, fornecendo um paradigma de modelagem mais natural e, em muitos casos, mais fácil de usar. Em uma abordagem de modelagem baseada em objetos, criamos nosso modelo colocando objetos de software em nosso modelo que representam os componentes físicos do sistema - por exemplo, um médico, um operador de máquina, uma empilhadeira, um transportador etc. Esses objetos podem ser personalizados com a especificação de valores de propriedade para esse objeto, como tempo de serviço, velocidade de deslocamento etc. Por exemplo, modelamos uma fábrica colocando e descrevendo por meio de propriedades os trabalhadores, as máquinas, as esteiras, os robôs e outros objetos que compõem nossa fábrica. Com a orientação de processo, o modelador descreve as ações que ocorrem no sistema à medida que as entidades se movem pelos processos. Observe que, enquanto as etapas do processo são descritas por verbos (apreender, atrasar, liberar), os objetos são descritos por substantivos (máquina, robô, trabalhador). Na orientação a objetos, o modelador simplesmente descreve os componentes físicos do sistema e os comportamentos e ações desses objetos que já estão incorporados aos objetos. Assim, um objeto trabalhador tem comportamentos predefinidos que permitem que ele interaja com máquinas e outros trabalhadores no modelo.

É difícil imaginar uma maneira mais natural de criar um modelo do que usar uma coleção de componentes de modelagem pré-construídos que imitam os componentes do sistema real. O desafio dessa abordagem é que, se quisermos modelar qualquer coisa no mundo real, precisaremos de uma extensa biblioteca de objetos para poder capturar a enorme diversidade de objetos reais que você pode encontrar. Por exemplo, não é adequado ter um único objeto chamado robô, pois há muitos tipos diferentes de robôs no mundo real. A busca dos desenvolvedores de linguagens de simulação pela criação de uma ferramenta prática de simulação baseada na abordagem de objetos ilustra o desafio de ter flexibilidade e facilidade de uso na mesma ferramenta de modelagem de simulação. Embora a flexibilidade proporcionada pela orientação ao processo ainda a torne uma abordagem amplamente utilizada na modelagem de simulação, um número crescente de produtos de simulação bem-sucedidos foi introduzido nos últimos 20 anos com base na orientação ao objeto. Assim como os segundos 20 anos produziram uma mudança da orientação a eventos para a orientação a processos, os últimos 20 anos viram uma mudança da orientação a processos para a orientação a objetos. As ferramentas mais recentes orientadas a objetos têm um rico conjunto de bibliotecas de objetos que se concentram em áreas de aplicativos específicas, como manufatura, cadeia de suprimentos e saúde. Algumas dessas ferramentas também permitem que os usuários criem e personalizem suas próprias bibliotecas de objetos para áreas de aplicativos específicas. A ideia básica de poder criar objetos personalizados como um conceito formal foi introduzida por OleJohan Dahl e Kristen Nygaard, do Norwegian Computing Center, em Oslo, na década de 1960, no Simula e no Simula 67 (Dahl et al. 1967). O Simula introduziu a noção de classes de comportamento (por exemplo, Server, Worker, Robot) e suas instâncias (objetos, por exemplo, Fred e Drill), como parte de um paradigma de modelagem explícito. Um modelador pode criar uma classe de objeto, como Car, e, em seguida, colocar várias instâncias dessa classe em seu modelo e personalizar o comportamento de cada instância definindo valores de propriedade. Eles também introduziram a noção de subclasses de objetos. Esse conceito poderoso permite que um usuário crie uma nova classe de objeto a partir de uma classe de objeto existente, herdando, substituindo e estendendo o comportamento da classe de objeto. Por exemplo, uma nova classe de objeto chamada Truck pode ser criada a partir da classe de objeto chamada Car, redefinindo alguns comportamentos e adicionando outros novos. A capacidade de criar uma nova classe de objeto começando com uma classe de objeto existente que tenha alguns comportamentos desejados simplifica muito o desenvolvimento de bibliotecas de objetos.

Grande parte do trabalho inovador no design da linguagem de simulação está ocorrendo em ferramentas de simulação orientadas a objetos. Essas ferramentas estão se tornando mais flexíveis, mantendo sua vantagem em termos de facilidade de uso e, portanto, substituindo as ferramentas orientadas a processos. Elas também têm uma vantagem fundamental em termos de animação. No caso das orientações de evento e processo, a adição de animação é um processo de duas etapas, em que o usuário primeiro constrói o modelo lógico e, em seguida, cria a animação como uma etapa separada e, depois, vincula esses dois componentes. Na orientação por objeto, os objetos predefinidos não só vêm com suas propriedades, estados e comportamentos associados, mas também com suas animações 3D associadas. Isso permite que o usuário crie rapidamente a lógica do modelo e a animação em uma única etapa.

Modelagem dinâmica de sistemas

A dinâmica de sistemas é uma abordagem de modelagem desenvolvida no MIT no final da década de 1950 por Jay Forrester (Forrester 1961). É uma forma de simulação contínua, em que as variáveis podem mudar continuamente com o tempo. Às vezes, a dinâmica de sistemas é usada para aproximar sistemas discretos de grande escala (por exemplo, modelagem de populações). Em sua forma geral, a dinâmica de sistemas tem um conjunto de variáveis de estado que são vinculadas dinamicamente a um conjunto de equações diferenciais. Entretanto, para a maioria das aplicações, os modelos consistem em "níveis" e "taxas", em que os níveis são simplesmente variáveis de estado e as taxas são diferenciais de primeira ordem (Sterman 2000). Ao nos limitarmos a essa forma simples, uma ampla gama de problemas de sistemas dinâmicos pode ser modelada. A dinâmica dos sistemas é frequentemente caracterizada por Diagramas de Loop Causal e por Diagramas de Estoque e Fluxo.

Um diagrama de loop causal é um meio visual de exibir a estrutura e o comportamento do sistema. Entretanto, um modelo mais detalhado é sua representação de estoque e fluxo. Um estoque pode ser representado como um tanque que enche e esvazia e mede o nível de uma variável de estado, como o número de pacientes em um pronto-socorro ou o número de pessoas que foram expostas a uma doença. Um fluxo é representado como uma válvula que controla a taxa de alteração de um estoque. Neste exemplo, o fluxo de pacientes para o pronto-socorro pode ser controlado pela extensão do seguro. À medida que o número da população segurada aumenta, a taxa de visitas ao pronto-socorro diminui. Mas tudo isso pode ser atenuado pelo custo que aumenta o número de não segurados, o que, por sua vez, aumenta o uso do pronto-socorro.

Forrester publicou o primeiro e ainda clássico livro da área, intitulado Industrial Dynamics, em 1961 (Forrester, 1961). Um dos modelos de Dinâmica de Sistemas mais conhecidos é um modelo de crescimento da população mundial, que foi popularizado no livro mais vendido de 1972, Limits to Growth (Limites do Crescimento) (Meadows et al. 1972). Esse modelo prevê o crescimento exponencial da população e do capital, com recursos finitos, levando ao colapso econômico em uma ampla variedade de cenários. O modelo original tinha cinco níveis que mediam a população mundial, a industrialização, a poluição, a produção de alimentos e o esgotamento de recursos.

Embora qualquer ferramenta de simulação contínua possa ser usada para simular modelos de Dinâmica de Sistemas, foram desenvolvidas várias ferramentas de modelagem específicas. Por exemplo, (consultehttps://en.wikipedia.org/wiki/Comparison_of_system_dynamics_software). Originalmente, a principal linguagem de simulação para dinâmica de sistemas era o Dynamo (agora em desuso), mas atualmente linguagens como Stella(https://www.iseesystems.com/store/products/stella-architect.aspx) e Vensim(http://vensim.com/) são populares na comunidade de dinâmica de sistemas. Outras linguagens de simulação, como PowerSim(http://www.powersim.com/) e AnyLogic(http://anylogic.com/), têm componentes de dinâmica de sistemas, mas agora oferecem outras combinações com elementos de eventos e processos. Além disso, embora os modelos de dinâmica de sistemas sejam expressos como sistemas contínuos, a maioria dos aplicativos envolve a modelagem de sistemas discretos de grande escala com muitas entidades. Uma alternativa à dinâmica de sistemas para sistemas discretos de grande escala é a modelagem de agentes.

Modelagem baseada em agentes

A modelagem baseada em agentes (ABM) amplia a ideia de objetos para "agentes" cujos atributos têm uma forte associação com o comportamento humano, embora não haja um consenso universal sobre sua definição. Essa tendência de tratar os agentes como pessoas significa que os agentes precisam ter características inteligentes e autônomas e a capacidade de tomar decisões independentes. Embora os agentes possam ser independentes, eles estão situados em um ambiente de outros agentes e, portanto, há regras que regem tanto a tomada de decisão individual quanto a interação com outros agentes. Em geral, a ABM tende a ser aplicada a problemas sociais que refletem o comportamento social, como enxames, rebanhos, seguidores etc. Alguns elementos da ABM também incluem a dinâmica de sistemas.

O conceito básico da Modelagem Baseada em Agentes (consulte North e Macal 2007) é que um sistema é modelado colocando-se agentes no sistema e deixando que o sistema evolua a partir da interação desses agentes. Cada agente é uma entidade autônoma que interage com outras entidades no sistema. O foco está na modelagem do comportamento do agente, em oposição ao comportamento do sistema. Em uma orientação de processo tradicional, as entidades seguem uma sequência de etapas do processo, que são definidas a partir da perspectiva do sistema de cima para baixo. Em contrapartida, a modelagem baseada em agentes define as regras de comportamento local (geralmente simples) de cada entidade a partir de uma perspectiva de baixo para cima. O comportamento do sistema é produzido como o resultado cumulativo da interação dos agentes entre si. Exemplos de aplicativos incluem multidões que se deslocam por uma área, clientes que respondem a lançamentos de novos produtos ou tropas em combate.

A estrutura de transição de estado para os agentes pode ser modelada usando qualquer visão de mundo. A modelagem baseada em agentes geralmente é implementada usando uma ferramenta de simulação orientada a objetos. Portanto, não se trata de uma nova visão de mundo de eventos discretos, mas sim de um grupo de aplicativos que geralmente são modelados com a visão de mundo de objetos. As classes são usadas para definir os estados e comportamentos dos agentes e as instâncias (geralmente em grande número) são colocadas no modelo. Os agentes (objetos) interagem e o estado do sistema evolui com o tempo. Algumas das áreas de aplicação da Modelagem Baseada em Agentes apresentam alguns desafios exclusivos, principalmente quando há um grande número de agentes envolvidos (por exemplo, modelagem da evacuação de torcedores de um estádio).

Para aplicações simples de modelagem baseada em agentes, a estrutura completa orientada a objetos com herança e subclasses às vezes é mais poderosa do que o necessário, e um simples diagrama de estados pode ser adequado para definir o comportamento da classe para cada agente. O conceito de diagrama de estado foi introduzido por Shannon e Weaver (Shannon, 1949) em seu livro The Mathematical Theory of Communication, de 1949. Um diagrama de estado define um conjunto finito de estados em que o agente pode estar, juntamente com as condições de transição que causam uma transição entre um par de estados. Em geral, cada diagrama define o comportamento de um objeto de uma determinada classe e as transições de estado para as instâncias de objeto dessa classe. Embora existam diversas variações diferentes de diagramas de estado em uso, todos eles definem estados como nós e arcos para a transição entre estados. Por exemplo, o diagrama de estado dos agentes pode mostrar como uma população infectada é processada e como as alterações no estado ocorrem ao longo do tempo.

Devido ao aumento da capacidade dos computadores de gerenciar um grande número de agentes, alguns modelos que antes eram feitos como aproximações discretas usando uma abordagem de dinâmica de sistemas agora são mais bem executados usando uma abordagem de modelagem baseada em agentes. Isso permite maior flexibilidade na lógica à custa de um tempo de execução mais longo. Um dos primeiros modelos baseados em agentes foi o Jogo da Vida, desenvolvido por John Conway na década de 1970 (Conway 1970). O Game of Life é um modelo bidimensional que envolve o crescimento celular que evolui usando uma etapa de tempo fixa, em que cada célula tem dois estados, vivo e morto. O estado de uma célula depende do estado dos vizinhos da etapa de tempo anterior. O jogo de Conway demonstrou o conceito básico do surgimento da complexidade a partir de regras simples.

O interesse na modelagem baseada em agentes continuou a crescer e a se diversificar na década de 1990 com o surgimento de várias ferramentas baseadas em agentes, especialmente Swarm(https://en.wikipedia.org/wiki/Swarm_(app)), NetLogo(https://ccl.northwestern.edu/netlogo/), Recursive Porous Agent Simulation Toolkit (Repast)(http://repast.sourceforge.net/repast_3/) e AnyLogic (http://anylogic.com/).

Experiências pessoais em modelagem

Nossas próprias experiências com modelagem de simulação e linguagens de simulação vão desde o final da década de 1970 até hoje. Embora as abordagens de modelagem sejam diferentes e se estendam dos pontos de vista discutidos anteriormente, elas continuam baseadas nas técnicas de eventos e processos com interesses mais recentes em métodos orientados a objetos e perspectivas multiparadigmáticas que descrevemos na próxima seção. Apresentamos observações para suas percepções históricas.

O desenvolvimento do SLAM teve origem em uma aula de simulação ministrada por C. Dennis Pegden durante a primavera de 1978 na Universidade do Alabama em Huntsville (UAH). Embora Pegden tivesse participado de uma aula recente de simulação ministrada por A. Alan B. Pritsker durante seus estudos de pós-graduação em Purdue, seu doutorado e seu foco eram a otimização matemática, portanto, ministrar essa aula de simulação de pós-graduação na UAH foi uma experiência de aprendizado e de alongamento para Pegden. A turma tinha uma dúzia de alunos de pós-graduação em tempo parcial, muitos dos quais usavam a simulação diariamente em seus empregos de tempo integral na NASA e em várias empresas aeroespaciais. Alguns dos alunos já eram usuários experientes do GPSS, SIMSCRIPT e outras ferramentas de simulação. Devido a esse histórico impressionante dos alunos de pós-graduação, Pegden decidiu aproveitar a experiência dos alunos usando o ensino em equipe e se concentrar em uma comparação das abordagens de evento, processo e objeto, além de algoritmos eficientes para a implementação de ferramentas de simulação. Durante essa aula, Pegden aprendeu sobre as diferenças entre as abordagens de eventos, processos e objetos e desenvolveu a ideia de mesclar uma linguagem de modelagem de eventos e processos em uma única estrutura. Como o software GASP IV era de domínio público, Pegden usou o GASP IV como evento e componentes contínuos do SLAM e, em seguida, ampliou essa estrutura para incluir um novo recurso de modelagem de processos. A linguagem SLAM foi desenvolvida paralelamente e como resultado direto do ensino dessa aula.

Na época em que o SLAM foi concluído, a Pritsker and Associates estava comercializando o produto de simulação GASP IV, que foi desenvolvido por Nicholas Hurst como sua tese de doutorado sob a direção de Alan Pritsker. Como o SLAM oferecia todas as funcionalidades do GASP IV, além do recurso adicional de modelagem de processos, ele era um claro aprimoramento do GASP IV. No verão de 1978, Pegden fez uma viagem à Pritsker and Associated e apresentou as vantagens do SLAM, sugerindo que a Pritsker and Associates comercializasse o SLAM no lugar do GASP IV. Chegou-se a um acordo de marketing, juntamente com um acordo de coautoria de um novo livro sobre simulação usando o SLAM. Com o novo livro e o apoio da Pritsker, o SLAM tornou-se rapidamente um sucesso de mercado.

Nos dois anos seguintes, Pegden mudou seu interesse de pesquisa da otimização para a simulação e começou a usar o SLAM para modelar sistemas complexos, percebendo rapidamente que, embora o produto funcionasse bem para muitos problemas de livros didáticos, as limitações dos recursos de modelagem de processos forçavam o usuário a recorrer à visualização de eventos para a maioria das aplicações complexas do mundo real. Portanto, o objetivo original de criar uma ferramenta de simulação que fosse mais fácil de aprender e usar em aplicações reais não estava sendo alcançado em muitas aplicações complexas, especialmente em ambientes de produção. Ficou claro que seria necessária uma linguagem de processo muito mais rica e capaz para atingir esse objetivo, e que eram necessários recursos especiais para atender a algumas aplicações de manufatura. Por isso, a Pegden decidiu começar do zero e desenvolver a linguagem SIMAN.

O desenvolvimento da linguagem SIMAN começou na primavera de 1981. O foco do projeto era expandir a abrangência dos recursos do processo e melhorar a eficiência da execução. No verão de 1981, foi lançado o primeiro IBM PC, que se tornou uma plataforma-alvo para o desenvolvimento do SIMAN, o que aumentou as demandas de eficiência de memória e velocidade de execução. Em agosto de 1981, Pegden tirou um ano sabático na Tektronix Inc., em Portland, Oregon, e se concentrou em tempo integral no desenvolvimento da linguagem SIMAN. Durante esse período, vários processos de fabricação foram modelados com sucesso usando versões beta da linguagem, o que validou a ideia de que o SIMAN proporcionava uma melhoria significativa na capacidade de modelagem de processos. Um livro didático sobre simulação usando o SIMAN também foi escrito durante esse período sabático (Pegden 1982).

No verão de 1982, Pegden entrou em contato com a Pritsker and Associates para perguntar sobre seu possível interesse em comercializar o SIMAN. No entanto, eles estavam investindo muito no SLAM e não expressaram interesse no novo produto SIMAN. Assim, em dezembro de 1982, Dennis e Lisa Pegden criaram a System Modeling Corporation e lançaram a linguagem SIMAN no mercado, com sucesso imediato. Três fatores importantes que impulsionaram seu crescimento inicial no mercado foram: (1) o recurso de modelagem de processos significativamente aprimorado do SIMAN, (2) os recursos voltados para aplicativos de manufatura e (3) a capacidade do SIMAN de ser executado no novo IBM PC. O SIMAN incorporou construções específicas para modelar equipamentos complexos de manuseio de materiais, como AGVs e transportadores. O SIMAN também implementou o conceito de estrutura experimental promovido por Zeigler (Zeigler, 1984) de separar a lógica do modelo da experimentação.

Após a introdução do SIMAN, a Systems Modeling Corporation desenvolveu o sistema de animação Cinema baseado em PC (1985) para oferecer animação em tempo real dos modelos do SIMAN. Isso proporcionou maior realismo do que os sistemas de animação baseados em caracteres existentes e, ao ser executado em paralelo ao modelo SIMAN, proporcionou uma poderosa plataforma interativa de verificação/validação de modelos. Essa foi uma etapa importante para aproveitar o poder da animação na simulação. Como o Microsoft Windows ainda não estava disponível, o Cinema foi desenvolvido usando um sistema de janelas personalizado. Como o PC padrão tinha resolução de apenas 320 por 200, a versão inicial do Cinema exigia uma placa de vídeo e um monitor especiais de terceiros de alta qualidade para fornecer a resolução necessária para produzir uma animação de qualidade. O SIMAN e o Cinema foram combinados para formar o sistema de simulação Arena (1991) e, em seguida, portados para o Microsoft Windows. O Arena introduziu o conceito de processos gráficos para a construção de modelos no lugar de declarações e forneceu uma interface de caixa de diálogo para inserir propriedades. Ele também oferecia suporte para análise de entrada e saída. O Arena tornou-se amplamente popular em aplicativos comerciais e tornou-se o produto de simulação dominante usado pelas universidades para ensinar conceitos de simulação. A popularidade nas universidades foi impulsionada pela flexibilidade de modelagem do SIMAN, pela facilidade de uso da interface gráfica e pelos populares livros didáticos "Simulation with Arena", de W. David Kelton, Randall P. Sadowski, Deborah A. Sadowski e David T. Sturrock. Em 2000, a System Modeling Corporation foi comprada pela Rockwell, que atualmente comercializa e oferece suporte ao produto Arena.

Embora o SIMAN tenha sido um avanço na flexibilidade de modelagem, ainda havia muitos aplicativos complexos que eram difíceis de modelar com a visualização do processo. Um problema que ocorria com frequência era que os recursos (assim como as entidades) no SIMAN não tinham capacidade de tomada de decisão personalizada. Embora as entidades pudessem se apoderar de recursos, os recursos não tinham voz no processo. Em alguns sistemas (por exemplo, na área da saúde), é mais natural que os recursos controlem sua própria lógica. Esse desafio de modelar sistemas que exigem uma lógica de recursos complexa tornou-se o foco do trabalho de Stephen Roberts.

Roberts foi contratado como membro do corpo docente da Universidade de Purdue em 1973 e foi nomeado para o Regenstrief Institute for Health Care, que estava situado dentro das grandes clínicas de saúde gerais e multiespecializadas da Escola de Medicina da Universidade de Indiana, localizada em Indianápolis, Indiana. Em uma análise das características operacionais dessas clínicas durante vários anos, ficou claro que somente a simulação permitia a análise dos componentes complexos e estocásticos dessas instalações. Em Purdue, Alan Pritsker e seus alunos estavam desenvolvendo linguagens de simulação de rede (processo) com base na parte de simulação discreta do GASP IV. Embora essas linguagens enfatizassem o fluxo de entidades por meio de processos, ficou claro que, nos serviços de saúde, o "fluxo de pacientes e afins" era apenas parte do ambiente, e o fluxo de pacientes era severamente limitado por prestadores de serviços de saúde e equipes ocupadas que prestavam serviços em um ambiente dinâmico, em contraste com máquinas e equipamentos que poderiam ser vistos em uma instalação de fabricação. Na verdade, o fluxo era quase sempre limitado por recursos humanos muito ativos que decidiam o que seria feito e isso dependia de vários fatores.

Assim, no final da década de 1970 e no início de 1980, foi desenvolvido no Regenstrief Institute um produto de simulação chamado INSIGHT (antigo INS), que incluía o fluxo de entidades (então chamado de transação), mas era orientado pelas "descrições de trabalho" realizadas pelos vários recursos "humanos" disponíveis. A modelagem empregava uma atividade como um ponto de serviço para entidades e recursos. A atividade especificava o número, o tipo e a combinação de recursos necessários e o tempo de atividade associado, mas as filas lógicas na frente de uma atividade mantinham as entidades até que o serviço pudesse começar. Portanto, os recursos serviam nas atividades, mas serviam às entidades nas filas. As entidades não se moviam para uma atividade, mas esperavam que os recursos as movessem para lá. Os recursos eram identificados individualmente e, opcionalmente, por tipo. Cada recurso era associado a um nó primário em uma árvore de decisão de recursos. Várias árvores de decisão de recursos podem ser definidas. Esse nó primário poderia se referir às filas dentro do modelo e/ou a outros nós primários. Esses nós primários expressavam o método de avaliação das filas associadas e de outros nós por critérios de pesquisa. Por exemplo, o nó de decisão primário de um enfermeiro pode ser primeiro atender à fila de pacientes em salas de exame que precisam de atendimento de um enfermeiro, depois atender à fila de pacientes que aguardam para serem colocados em uma sala de exame e terem seus sinais vitais medidos e, em seguida, executar outro nó de decisão primário que diz para ajudar no registro ou na saída, dependendo do tempo de espera dos indivíduos. Esse processo de decisão pode ser parte de outro processo de decisão ou ser exclusivo de um recurso.

De qualquer forma, o processo de decisão de recursos era dinâmico e dependia muito do estado do sistema. O que fazia o processo de decisão funcionar era o algoritmo de atualização de status usado pela linguagem de simulação. Como os eventos de fim de atividade dominavam todos os outros eventos, sua atualização era fundamental para a modelagem e era chamada de processo de dois estágios. Quando uma atividade era concluída, os recursos eram colocados em um estado de retenção temporário chamado armazenamento em buffer. Nesse ponto, o Estágio 1 enviava a entidade para a rede até que seu progresso fosse interrompido pela necessidade de adquirir recursos, iniciar uma atividade ou sair. Quando o Estágio 1 era concluído, o Estágio 2 era invocado, no qual cada recurso no armazenamento em buffer usava sua árvore de decisão para determinar o que deveria fazer em seguida. Ou ele se ocupava em outra atividade ou ficava ocioso. Havia especificações que permitiam às entidades identificar e reivindicar recursos do armazenamento em buffer e permitir que a atualização de um recurso fizesse com que as entidades iniciassem atividades. Deve-se observar que as entidades podem sofrer atrasos devido a requisitos de sincronização, como coleta ou movimentação remota. Outras prioridades entre os recursos para uso em atividades poderiam produzir preempção ou retomada de atividades.

O desenvolvimento da linguagem de simulação INSIGHT continuou durante a década de 1980 e foi descrito em tutoriais no WSC. Ela nunca obteve sucesso comercial e o Regenstrief Institute suspendeu seu desenvolvimento quando Roberts foi para a North Carolina State University em 1990. Na década de 1990, Roberts, principalmente junto com Jeff Joines, desenvolveu uma linguagem de simulação orientada a objetos em C++ cujos recursos de simulação de processos se assemelhavam ao INSIGHT. Devido ao polimorfismo dos objetos, essa simulação poderia empregar "equipes", bem como recursos individuais e de tipo em um processo de decisão expandido. Além disso, o desenvolvimento mostrou como uma linguagem como a INSIGHT poderia ser expandida e ampliada com recursos verdadeiramente orientados a objetos. No entanto, o uso exigia experiência substancial em programação C++, de modo que sua aceitação foi altamente limitada e o desenvolvimento foi interrompido em uma década. Embora o INSIGHT nunca tenha obtido sucesso comercial, ele destacou a importância de expandir a flexibilidade de modelagem para além dos fluxos de entidades simples, de modo a dar suporte também à modelagem da lógica de recursos complexos.

Depois de ficar afastado do setor de simulação por alguns anos, Pegden foi convidado a dar a palestra Titan na Conferência de Simulação de Inverno de 2005 sobre os rumos futuros da simulação. Essa palestra foi o impulso para que ele passasse algum tempo refletindo sobre o estado da simulação e o que poderia ser feito para melhorar as ferramentas existentes. Isso levou Pegden a desenvolver o conceito de modificar os conceitos básicos orientados a objetos para substituir métodos codificados por processos, mantendo a noção básica de classes, subclasses, herança, polimorfismo, substituição, etc. A motivação para essa ideia foi trazer os benefícios da abordagem orientada a objetos usando processos gráficos, evitando assim a necessidade de habilidades complexas de programação.

Pegden usou esses conceitos desenvolvidos para a palestra Titan para criar o software de simulação Simio, que foi lançado no mercado em 2008. Com o Simio, ficou muito mais fácil para os usuários ampliarem e criarem bibliotecas de objetos sem a necessidade de codificar em uma linguagem orientada a objetos, como C++ ou Java. O Simio também ampliou ainda mais a ideia de um recurso inteligente introduzida pelo INSIGHT. No Simio, os recursos (e entidades) também são objetos que podem responder a solicitações usando sua própria lógica de processo personalizada. Isso facilita muito a modelagem de situações em que a entidade ou o recurso está no controle de seu próprio comportamento.

Outro avanço importante do Simio foi a noção de usar o processo de add-in para que os objetos modifiquem seu comportamento em uma base de instância por instância, sem modificar a definição do objeto. Antes da introdução desse conceito no Simio, o principal método para adicionar lógica personalizada a uma instância de objeto era adicionar eventos codificados personalizados ao objeto. Os processos de add-in foram um avanço significativo porque são mais fáceis de usar e mais eficientes. O poder adicional vem da lógica do processo que pode representar atividades que abrangem o tempo, enquanto um evento codificado é limitado a um instante no tempo.

A evolução do SLAM - SIMAN - Arena - Simio ocorreu em um período de quase 40 anos. Durante esse período, o principal paradigma de modelagem mudou de eventos para processos e para objetos. Com o SLAM, a principal abordagem de modelagem era a de eventos, com processos usados sempre que possível. Com o SIMAN, a abordagem principal de modelagem foi a de processos, com eventos usados quando necessário. Com o Cinema/Arena, a animação tornou-se uma parte central do processo de modelagem e verificação/validação. Com o Simio, a abordagem de modelagem principal é baseada em objetos, com processos usados quando necessário. Essa evolução tornou a simulação mais fácil de usar sem comprometer a flexibilidade da modelagem.

Modelagem multiparadigma

As primeiras abordagens de modelagem de simulação eram reflexos de um único paradigma de simulação, ou seja, evento, atividade, processo e objeto. Na década de 1970, surgiu uma visão de modelagem de paradigma "combinado", permitindo que o usuário selecionasse a abordagem de modelagem que melhor se adaptasse ao problema ou combinasse abordagens de modelagem conforme a situação exigisse. O GASP IV (Pritsker 1974) popularizou a ideia de combinar estruturas discretas e contínuas no mesmo modelo, embora tenha havido esforços anteriores de outros (veja, por exemplo, Tocher e Splaine 1966). Essa estrutura permitiu tanto a modelagem de eventos discretos quanto a modelagem contínua no mesmo modelo de simulação. Ela fornecia eventos de tempo e de estado para que os eventos discretos pudessem afetar as variáveis contínuas e os eventos de tempo pudessem afetar as variáveis discretas. O SLAM (Pegden e Pritsker 1979) avançou a combinação para incluir a modelagem de processos e foi uma das primeiras ferramentas amplamente utilizadas para promover a ideia de misturar abordagens de modelagem alternativas (processos e eventos e contínua) no mesmo modelo. No caso do SLAM, a modelagem de processo/contínua foi usada para a modelagem básica, e os eventos foram usados como "porta dos fundos" para proporcionar maior flexibilidade.

A ideia de usar a simulação em combinação com outras ferramentas analíticas foi empregada informalmente no início da história da simulação. Em 1983, Shanthikumar e Sargent (1983) ofereceram uma definição unificadora de modelos híbridos de simulação/análise. Eles apresentaram quatro classes de modelos híbridos que representam as maneiras pelas quais os modelos analíticos e de simulação podem interagir. Swinerd e McNaught (2012) usaram recentemente uma combinação de uma simulação baseada em agentes com um modelo analítico para criar um caso de simulação híbrida.

As modernas ferramentas de simulação orientadas a objetos também empregam uma abordagem multiparadigma. Essas ferramentas combinam a facilidade e a modelagem rápida proporcionadas pelos objetos com a flexibilidade adicionada pela incorporação de eventos e/ou processos especificados pelo usuário. Por exemplo, um objeto que representa um servidor pode ter pontos selecionados na lógica do objeto em que o usuário pode inserir sua própria lógica de evento ou lógica de processo. Normalmente, a lógica de eventos é incorporada aos objetos usando uma linguagem de programação, como Java ou C++, ou uma linguagem de script especial que pode ser usada no lugar do código. Entretanto, em ambos os casos, a lógica de eventos tem uma restrição importante: o tempo simulado não pode avançar dentro do evento. Isso restringe muito o tipo de lógica que pode ser inserida em uma instância de objeto. Por exemplo, não é possível esperar que um trabalhador fique disponível em um evento, pois isso exigiria que o tempo avançasse. O Simio(https://www.simio.com/index.php) introduziu uma abordagem muito mais avançada que permite aos usuários combinar objetos com processos. Como os processos podem abranger o tempo, eles oferecem ao usuário muito mais poder para ampliar o comportamento de seus objetos. Assim, os processos podem ser incorporados em um objeto para aguardar um tempo ou uma condição específica (por exemplo, Fred está disponível). Essa abordagem combina todo o poder e a flexibilidade dos processos com a facilidade e a capacidade de modelagem rápida dos objetos.

A AnyLogic(http://anylogic.com/) combinou modelagem baseada em agentes, dinâmica de sistemas e modelagem de eventos discretos em uma única ferramenta. Um único modelo AnyLogic pode combinar todas as três abordagens de modelagem para representar o comportamento do sistema.

Além disso, complementando o interesse em multiparadigmas, há um interesse em unificar a modelagem de simulação em uma estrutura ou teoria de simulação específica. Em 1981, Nance (Nance 1981) descreveu as funções fundamentais do tempo e do estado em simulações de eventos discretos que, por fim, levaram à Metodologia Cônica (Overstreet e Nance 1985), que fornece uma estrutura para encapsular os pontos de vista básicos de modelagem de evento, atividade e processo.

A teoria de simulação mais conhecida foi o formalismo proposto pela primeira vez por Zeigler em 1984 (Zeigler 1984), agora conhecido como DEVS (Discrete Event System Specification). Ao longo dos anos, essa teoria foi desenvolvida e aplicada a vários casos (consulte Zeigler e Muzy 2017). O DEVS é uma teoria de sistema formal composta de entradas, estados e saídas em combinação com funções de avanço de tempo para modelar componentes de sistema discretos e contínuos (potencialmente hierárquicos). A abstração fornece uma estrutura que separa a modelagem e a execução da simulação para destacar, por exemplo, a ordenação e a execução potencialmente paralela de eventos. O formalismo DEVS atraiu o interesse mundial e sua formulação abrigou várias extensões e interpretações.

Adotando uma abordagem de teoria de gráficos, Schruben e Yucesan (Schruben e Yücesan 1993) mostram que uma visão de gráfico de eventos da simulação de eventos discretos pode ser usada para criar um ambiente completo e consistente de desenvolvimento de modelos (solução de problemas). Um modelo de gráfico de eventos não é apenas visualmente atraente, mas fornece uma estrutura rigorosa para a criação de modelos (Savage et al. 2005).

Modelagem com animação

Nos primeiros 30 anos de simulação, o resultado era na forma de relatórios textuais. Embora a animação visual da execução da simulação tenha sido prevista já em 1970 (Reitman et al. 1970), a animação foi integrada à simulação comercial na década de 1980. Houve um debate significativo sobre os méritos da animação. Muitas pessoas achavam que a animação era um enfeite que não tinha impacto real sobre o sucesso de um projeto de simulação. Entretanto, a animação agora é vista como um componente essencial de projetos de simulação bem-sucedidos e tem um papel fundamental na expansão dos aplicativos de simulação dentro da empresa. Um dos benefícios significativos da animação é sua capacidade de comunicar o comportamento do modelo a todos os interessados no modelo. Todos, desde o chão de fábrica até o último andar, podem ver o comportamento incorporado ao modelo. A animação deixa claras as suposições da modelagem e é uma ferramenta poderosa para a verificação e a validação do modelo.

Antes da animação, os tomadores de decisão precisavam acreditar que o modelo reproduzia com precisão o comportamento do sistema real no nível adequado de detalhes. Muitas vezes, poderia haver bugs na lógica do modelo, mas não havia uma maneira simples e visual de detectar erros na lógica. Com a animação, o modelo ganha vida e o comportamento fica claramente visível. A animação combinada com depuradores interativos melhorou radicalmente a capacidade de encontrar e corrigir erros lógicos em um modelo. A animação não só ajuda os modeladores a encontrar e corrigir erros não corrigidos na lógica, mas também ajuda a comunicar as suposições simplificadoras planejadas que fazem parte de qualquer modelo. A animação é um componente essencial para estabelecer a confiança nos resultados do modelo.

Um dos primeiros sistemas de animação de simulação foi o produto chamado See Why, desenvolvido no final dos anos 80, que usava animação rudimentar baseada em caracteres. O software de simulação Witness(https://www.lanner.com/technology/witness-simulation-software.html) foi desenvolvido a partir do See Why. O sistema de animação Cinema era um sistema de animação 2D baseado em vetores desenvolvido no mesmo período e era um sistema de animação em tempo real para modelos SIMAN. O sistema de animação Cinema e o sistema de modelagem SIMAN foram então integrados em uma única plataforma para criar o produto Arena, amplamente utilizado. Outro sistema de animação 2D antigo foi o Proof(http://www.wolverinesoftware.com/ProofProducts.htm), desenvolvido por Jimes O. Henriksen da Wolverine Software em 1989.

Nos anos 90, começaram a surgir recursos de animação 3D. Alguns dos primeiros sistemas incluíam o AutoMod (voltado para sistemas de manuseio de materiais) (http://www.appliedmaterials.com/global-services/automationsoftware/automod), o Taylor ED (um precursor do FlexSim(https://www.flexsim.com/)) e o Simple++ (um precursor do PlantSim (https://www.plm.automation.siemens.com/)). O debate sobre animação também se estendeu à necessidade de ter uma animação 3D de alta fidelidade em comparação com a animação 2D. Alguns argumentam que a animação 2D é adequada para obter a maioria dos benefícios da animação e que o esforço extra necessário para a 3D traz retornos decrescentes. Embora uma animação em 3D de maior qualidade não altere o modelo subjacente ou os resultados em comparação com uma animação em 2D, o realismo aprimorado pode ajudar a comunicar os resultados do modelo. Além disso, com os aprimoramentos na animação 3D e a ampla disponibilidade de símbolos 3D, não há mais um preço significativo em termos de tempo ou esforço para criar a animação 3D. Assim, a maioria das ferramentas de simulação modernas oferece um ambiente de animação 3D.

A combinação da estrutura orientada a objetos, de um ambiente de modelagem 3D imersivo e de recursos aprimorados de desenho 3D provou ser uma combinação muito poderosa para trazer a animação 3D para a corrente principal da modelagem de simulação. A maioria das ferramentas de simulação modernas agora oferece 3D como um recurso padrão.

A próxima onda de animação para simulação é o desenvolvimento de ambientes de realidade virtual (VR) completos para a exibição de animações de simulação. Isso permite que o espectador mergulhe no modelo e percorra o sistema em um ambiente de RV que imita o sistema real e talvez interaja com a simulação movendo objetos, redirecionando o tráfego ou alterando a atividade de simulação. Vários sistemas de simulação (por exemplo, Simio, FlexSim, Emulate3D(https://www.demo3d.com/)) já oferecem suporte a ambientes de RV para visualização de animações. Permitir que o usuário interfira na animação é a próxima etapa no desenvolvimento da exibição de RV.

O impacto nos negócios

Comentário

A história da simulação está repleta de dezenas de linguagens e pacotes de simulação, cada um deles com componentes de modelagem exclusivos. Muitos se perderam no mercado de popularidade devido à sua incapacidade de conquistar um público de simulação. Ao contrário da simulação contínua, que se baseia na solução de equações diferenciais, as simulações discretas não têm uma teoria fundamental comum e aceita. Como resultado, a modelagem de simulação reside mais freqüentemente no reino da "arte". Na prática, a arte da simulação exige um conhecimento bastante completo do que pode ser simulado pela ferramenta em uso, em vez de um foco desenfreado no problema que está sendo resolvido. Como resultado, as simulações bem-sucedidas geralmente são o produto de algum interesse comercial apoiado por uma abundância de documentação e ferramentas de aprendizado, tudo dentro da estrutura que promove os benefícios da ferramenta.

A tradução de uma preocupação problemática em uma simulação é amplamente reconhecida como sendo um amálgama dos objetivos de desempenho dos sistemas, dos dados de entrada disponíveis e das habilidades de modelagem do modelador. Existem várias maneiras de lidar com os dados de entrada disponíveis e as diversas medidas de desempenho (consulte Banks et al. 2010; Law 2015). A conceituação do modelo geralmente se baseia em representações gráficas (diagramas de blocos, fluxogramas, diagramas de ciclo de atividades e assim por diante), que geralmente estão associadas a linguagens de simulação específicas, e tem havido pouca discussão sistemática sobre abordagens gerais. Robinson (Robinson 2008a, b) apresenta uma estrutura de modelagem conceitual em duas partes. O significado e os requisitos do modelo conceitual incluem: validade, credibilidade, utilidade e viabilidade. A atividade de modelagem real é vista como consistindo em: entender a situação do problema, determinar a modelagem e os objetivos gerais do projeto, identificar a saída do modelo, identificar as entradas do modelo e determinar o conteúdo do modelo. Juntos, eles fornecem uma estrutura para conceituação, mas ainda não produzem um modelo computacional. A implementação do modelo conceitual ainda deve ser implementada por uma linguagem de simulação ou pacote de simulação acessível ao modelador de simulação.

A função da linguagem de simulação na modelagem de simulação continua interligada. Os esforços para tornar a modelagem mais transparente e visível por meio de técnicas gráficas e de linguagem natural oferecem um potencial considerável para a modelagem de simulação. No entanto, a tecnologia de simulação deve interagir com o armazenamento e a análise de dados de grande porte para realizar seu maior potencial à medida que a tecnologia de computação avança.