Um projeto de pesquisa de vários anos focado na transição do design para a produção de uma empresa aeroespacial global e, em particular, em como responder a perguntas relacionadas à produção muito antes do ciclo de design de um programa do que é possível atualmente. Uma dificuldade fundamental é que o tempo e o conhecimento necessários para formular modelos de análise apropriados impedem seu uso rotineiro, especialmente no desenvolvimento de novos programas. O objetivo do projeto era reduzir esses requisitos e, no final de 2014, foi desenvolvida uma metodologia para a geração de análises sob demanda para responder a perguntas rotineiras sobre sistemas de produção. Um projeto piloto foi conduzido em 2015 para demonstrar a eficácia, que uma implementação da metodologia poderia de fato reduzir em pelo menos uma ordem de grandeza o tempo necessário para responder a uma pergunta frequente, de forma repetível, enquanto a especificação dos produtos, seus planos de processo, instalações planejadas e recursos disponíveis mudavam com frequência. Este documento resume a metodologia, a implementação de seu projeto piloto e os resultados preliminares.
Uma empresa aeroespacial global busca aprimorar o projeto de seus sistemas de produção abordando questões importantes no início do ciclo de vida do produto. As ferramentas de CAD (Computer-Aided Design) e CAE (Computer-Aided Engineering) auxiliam os projetistas de produtos, fornecendo a capacidade de avaliar métricas mecânicas, aeroespaciais, térmicas e outros tipos de métricas sobre projetos de produtos candidatos. No entanto, as ferramentas computacionais que auxiliam os projetistas de sistemas de produção com recursos de análise sob demanda são mais limitadas. Portanto, a visão da empresa é aprimorar o suporte de ferramentas para o projeto, o diagnóstico e o aprimoramento contínuo dos sistemas de produção, começando por oferecer aos projetistas a capacidade de avaliar métricas e questões de "capacidade de produção", incluindo
Seja qual for a lista de perguntas, o tema da pesquisa é como respondê-las por meio de um botão, e há vários fatores que dificultam isso. Primeiro, a capacidade de usar um botão requer a formulação e a solução de vários modelos de análise de pesquisa operacional, inclusive modelos estatísticos, de simulação de eventos discretos e de análise de otimização.Os métodos e algoritmos de solução são bem estudados na literatura, mas não é bem estudado como formular um modelo de análise com base em uma descrição de sistema neutra em termos de análise e uma pergunta sobre o sistema de forma automatizada, robusta e reutilizável. Em segundo lugar, durante os estágios iniciais do projeto, a especificação de um produto pode existir apenas em um alto nível de abstração, o que significa que a funcionalidade do botão de pressão deve acomodar quantidades variáveis de detalhes. Em terceiro lugar, embora as informações sobre produtos e processos possam ser rigorosamente capturadas nos sistemas de PLM (Product Lifecycle Management, Gerenciamento do Ciclo de Vida do Produto), as informações sobre recursos e instalações geralmente não o são - o conhecimento sobre produção em muitas empresas costuma ser informal, tácito e transitório. Se a espinha dorsal da arquitetura de uma empresa inclui CAD, PDM (Product Data Management, Gerenciamento de Dados do Produto), MES (Manufacturing Execution Systems, Sistemas de Execução da Manufatura) e MRP (Manufacturing Resource Planning, Planejamento de Recursos de Manufatura), a combinação desses sistemas ainda carece das informações necessárias para responder a muitas perguntas sobre a capacidade de produção, inclusive as listadas acima. Portanto, quando um projetista aperta o botão, ele também deve esperar fornecer informações adicionais, o que levanta a questão de quais são exatamente essas informações, que linguagem e formato elas devem assumir e que flexibilidade existe para seu detalhamento.
Uma analogia para a visão da empresa é aumentar os assistentes pessoais, como a Siri da Apple, a Pesquisa por voz do Google ou a Cortana da Microsoft, com a funcionalidade adicional necessária para responder a perguntas sobre a capacidade de produção dos designs candidatos. Para entender como a funcionalidade necessária difere do que já existe, considere que muitas perguntas feitas aos assistentes pessoais podem ser respondidas por meio de um simples banco de dados ou pesquisa na Web. Também existem exemplos isolados de maquinismos mais avançados, sendo um dos mais populares a computação de instruções de direção. As perguntas sobre como navegar em redes de transporte civilnãocostumam ser respondidas por meio da pesquisa de rotas pré-gravadas em bancos de dados, mas sim pela formulação de uma análise de otimização de fluxo de rede de caminho mais curto, resolvendo-a (talvez usando o algoritmo de Dijkstra com heurística) e fazendo isso em segundos e de forma invisível para o usuário final. Com essa analogia, os fatores listados acima podem ser resumidos em dois desafios: (1) uma generalização e expansão necessárias dos recursos dos assistentes pessoais para formulação e solução de análises e (2) modelagem. É possível responder a perguntas sobre instruções de direção porque os assistentes pessoais já têm conhecimento detalhado das redes de transporte civil. No entanto, eles não têm conhecimento dos produtos, processos, recursos e instalações exclusivos de uma empresa arbitrária e, mesmo que tivessem acesso aos sistemas de informação da empresa, esses sistemas não são completos nem podem funcionar normalmente na função necessária de um ambiente de projeto experimental.
No final de 2014, foi desenvolvida uma metodologia para enfrentar esses desafios e, em particular, o desafio da modelagem. A metodologia permite responder a questões de capacidade de produção por meio da formulação automática de vários tipos diferentes de modelos de análise, mas o projeto piloto concentrou-se exclusivamente na formulação de modelos de simulação de eventos discretos, de acordo com a observação de Nelson de que "a simulação é cada vez mais oúnicométodo capaz de analisar, projetar, avaliar ou controlar os sistemas incertos, complexos e de grande escala nos quais estamos interessados" (Taylor et al. 2013). Um requisito imposto pela empresa é usar ferramentas comerciais prontas para uso (COTS) para modelos de simulação formulados automaticamente, incluindo o Simio e o Tecnomatix Plant Simulation.
Muitos analistas de engenharia tentaram adicionar automação ao seu fluxo de trabalho, seguindo o paradigma de separar a descrição do sistema da análise do sistema, criando descrições do sistema de uma maneira presumivelmente mais fácil e, em seguida, transformando-as automaticamente na semântica e na sintaxe de uma linguagem de análise específica, conforme necessário. Yuan et al. (1993) descrevem um gerador para modelos de simulação em linguagem SIMAN de "sistemas operacionais discretos" que são modelados com uma "rede de operações" e "equações de operação". Son e Wysk (2001) descrevem a criação automática de modelos de simulação na linguagem Arena para responder a perguntas de controle de chão de fábrica, usando uma abstração de rede chamada "gráfico de estado de peça baseado em mensagens" para capturar possíveis roteiros por meio dos recursos de uma loja. Fournier (2011) descreve a criação automática de modelos de simulação em várias linguagens (QUEST, Arena, ProModel, FlexSim) usando o padrão Core Manufacturing Simulation Data (CMSD), e Bergmann et al. (2012) mapeia o CMSD para a linguagem de simulação SLX. Dong e Chen (2001) geram Redes de Petri orientadas a objetos a partir de regras de comportamento da Arquitetura de Sistema Aberto de Manufatura Integrada por Computador (CIMOSA), e Deavours et al. (2002) geram Redes de Atividades Estocásticas (SAN) a partir de formalismos de modelagem compatíveis com a estrutura Mobius. Os geradores de modelos de análise de simulação que inserem modelos de sistema em linguagem SysML são Batarseh et al. (2015) e Kapos et al. (2014), este último gerando modelos executáveis de Especificação de Sistema de Eventos Discretos (DEVS).
Observe a variedade de linguagens de descrição de sistemas nas citações acima. Além de "sistemas operacionais discretos", "gráficos de estado parcial baseados em mensagens", CMSD e outros, há muitas outras linguagens candidatas, desde ideias de pesquisa até padrões adotados. Um padrão OASIS para a troca de dados de planejamento e programação de produção é (OASIS 2011). O resultado do comitê ISO TC 184/SC4 inclui o padrão ISO 10303 para captura legível por máquina e compartilhamento de dados de produtos (Pratt 2001). O AutomationML é um padrão de padrões para troca de dados entre ferramentas de engenharia em uma instalação de produção (Drath et al. 2008). Esses esforços padronizam os esquemas de dados, e também há esforços para padronizar a semântica e as ontologias. Um padrão da OMG que formaliza a semântica do processo de negócios é o Business Process Model and Notation (BPMN) (OMG 2011). Um padrão do Supply Chain Council que formaliza a semântica do gerenciamento da cadeia de suprimentos é o Supply Chain Operations Reference (SCOR) (SCC 2012). As propostas para formalizar a semântica de manufatura incluem a Manufacturing Semantics Ontology (MASON) (Lemaignan et al. 2006) e também Molina e Bell (1999), Cutting-Decelle et al. (2007) e Guerra-Zubiaga e Young (2008).
Tanenbaum (1981) observa: "O bom dos padrões é que você tem muitos para escolher"."Nos primeiros anos do projeto de pesquisa, os autores buscaram uma linguagem de descrição de sistema única e "perfeita" para sistemas de produção (Thiers e McGinnis 2013), agregando várias contribuições citadas e preenchendo lacunas. No entanto, nunca foi desenvolvida uma linguagem que os autores pudessem plausivelmente argumentar que o mundo inteiro deveria usar, por razões que incluem uma tensão fundamental entre o concreto e o abstrato (o primeiro necessário para a acessibilidade do usuário, o segundo necessário para a robustez e a reutilização) e também porque uma linguagem é inexoravelmente moldada pelos casos de uso de seus autores em um determinado momento.Inevitavelmente, tanto os casos de uso quanto o tempo mudam, a linguagem precisa evoluir, os programas de transformação que estão fortemente acoplados à linguagem quebram e o autor precisa manter o código que há muito esqueceu, se é que o autor original pode ser encontrado. O progresso só foi retomado quando finalmente foi aceito que talvez nunca exista uma linguagem de descrição de sistema única e "perfeita" para sistemas de produção, e foi criada uma maneira de acomodar uma infinidade de linguagens de descrição de sistema semelhantes, mas diferentes.
Além de um grande número de opções de linguagem para descrição de sistemas, há também um grande número de opções de linguagem para análise de simulação de eventos discretos - ao contrário do domínio da análise de otimização, que tem uma linguagem canônica "A Mathematical Programming Language" (AMPL) (Fourer et al. 1993), até onde os autores sabem, o domínio da simulação de eventos discretos não tem essa linguagem canônica, e cada opção de linguagem difere de outras opções de linguagem tanto na semântica quanto na sintaxe. Se houver m opções de linguagem de descrição do sistema en opções de linguagem de análise de simulação, resultarãom n permutações de transformações da descrição do sistema para a análise de simulação, o que limita muito o retorno sobre o investimento de escrever e manter cada uma delas. A metodologia descrita neste documento reduzm para1, mas ainda permitemlinguagensdedescriçãodo sistema, acrescentando uma etapa de transformação intermediária que associa livremente cada linguagem a uma linguagem de abstração de ponte de back-end.
Entre os esforços citados na seção 1.1 para gerar automaticamente modelos de simulação, há uma variedade considerável no local onde a "inteligência" de transformação está localizada - ela pode estar a montante na linguagem de descrição do sistema (efetivamente confundindo essa linguagem com a linguagem de análise a jusante), na própria transformação (como nas linguagens e ferramentas de transformação de modelo para modelo de uso geral, incluindo QVT (OMG 2016) e ATL (EMF 2016), ou a jusante na linguagem de análise do sistema (efetivamente confundindo essa linguagem com a linguagem de descrição a montante, a abordagem de fato de muitos fornecedores de ferramentas de simulação COTS). Em alguns casos, os pesquisadores tentam simplificar as transformações escrevendo sua própria linguagem e solucionador de simulação de eventos discretos, como em Biswas e Narahari (2004), Chatfield et al. (2006) e Schonherr e Rose (2009), permitindo a transformação da descrição do sistema em análise de simulação usando mapeamentos diretos de um para um. Na opinião dos autores, desenvolver ferramentas de análise ad-hoc quando ferramentas COTS adequadas estão disponíveis - mesmo que sua linguagem seja inconveniente - não parece ser um caminho sustentável. A metodologia descrita neste documento coloca a maior parte da "inteligência" de transformação nas próprias transformações de modelo para modelo, mas propõe um pequeno passo à frente ao criar modelos de simulação na maior medida possível usando blocos de biblioteca de modelos, que são versões executáveis de elementos de modelos de abstração de ponte.
Uma metodologia é uma coleção de processos, métodos e ferramentas relacionados (Estefan 2008), e o processo na metodologia deste documento é mostrado na Figura 1. Tanto o modelo de sistema na parte superior esquerda quanto o modelo de abstração de ponte na parte superior central são somente de descrição e ambos são, na verdade, compostos por dois níveis diferentes de abstração de modelagem, que podem ser chamados de esquema e dados ou metamodelo e modelo de instância, ou definições de classe e instanciações de objeto na terminologia de software orientado a objetos. A linguagem de descrição do sistema discutida detalhadamente na seção 1.1 é a camada superior do esquema ou metamodelo, e a distinção é importante porque as transformações de modelo para modelo dependem apenas dessa camada e devem funcionar com qualquer modelo de dados ou de instância em conformidade. O metamodelo Bridging Abstraction é uma criação abstrata que captura as semelhanças subjacentes compartilhadas por todos os sistemas de logística de eventos discretos - sistemas de manufatura, cadeias de suprimentos, sistemas de armazenamento e distribuição, sistemas de transporte e logística, sistemas de prestação de serviços de saúde e outros. Uma observação importante é que a maioria dos sistemas estudados em engenharia industrial tem uma estrutura de rede, e a maioria das análises de pesquisa operacional desses sistemas é baseada em redes. O metamodelo de abstração de ponte evoluiu desde sua criação para uma coleção de modelos em camadas, mas a camada original e fundamental é chamada pelos autores de rede de fluxo de tokens, com um trecho mostrado na figura 2.
O Bridging Abstraction Model é introduzido para mediar uma tensão fundamental entre o concreto e o abstrato - um modelo de sistema deve ser tão concreto quanto necessário para a acessibilidade, o Bridging Abstraction Model deve ser tão abstrato quanto possível para a robustez e a reutilização, e a eficácia depende de mapeamentos facilmente criados e mantidos entre os dois. Os mapeamentos são realizados como especificações declarativas de transformações de modelo para modelo, e sua atualização em resposta a modelos de sistema novos ou em evolução deve ser o mais simples e rápida possível. Na terminologia de software, a etapa intermediária adicionada tem o efeito de atenuar o forte acoplamento entre as linguagens de descrição do sistema e as linguagens de análise do sistema, para aliviar os custos quando uma linguagem de descrição do sistema precisa inevitavelmente mudar com os casos de uso e o tempo. Na Figura 1, o acoplamento de segundo estágio entre o modelo de abstração de ponte e o modelo de análise permanecerá rígido, mas o acoplamento de primeiro estágio entre o modelo de sistema e o modelo de abstração de ponte deve ser o mais flexível possível para acomodar modelos de sistema novos ou em evolução. É importante ressaltar que, devido à estabilidade do Bridging Abstraction Model, a tarefa de escrever e manter as transformações de segundo estágio deve ter retorno sobre o investimento suficiente para ser adotada por uma equipe dedicada, em vez de diversos analistas.
Muitas ideias novas são variações de ideias antigas, e o processo da Figura 1 pode ser classificado como tal, um transplante de práticas recomendadas da engenharia de software para a engenharia de sistemas. A novidade da metodologia está em seus métodos e ferramentas que abordam os grandes desafios de pesquisa existentes para que isso funcione na engenharia de sistemas:
Uma ampla discussão sobre os processos, métodos e ferramentas da metodologia pode ser encontrada em Thiers (2014), Sprock e McGinnis (2014) e Sprock (2016). A busca e a experimentação de novos métodos e ferramentas continuam, por exemplo, um método de uso de blocos de biblioteca de modelos que são versões executáveis de elementos de modelos de abstração de ponte, na medida do possível, ao criar modelos de análise em um domínio sem uma linguagem canônica.
PROJETO PILOTO
No final de 2014, a metodologia havia amadurecido no papel, e um projeto piloto foi conduzido em 2015 para demonstrar a eficácia, que uma implementação da metodologia poderia, de fato, reduzir o tempo necessário para responder a uma pergunta frequente em pelo menos uma ordem de grandeza, de forma repetível, enquanto a especificação dos produtos, seus planos de processo, instalações planejadas e recursos disponíveis mudam continuamente. As etapas envolvidas foram:
Etapa 1: Pedir ao usuário que escolha um cenário frequentemente encontrado para o qual a formulação de modelos de simulação de eventos discretos, para responder a uma variedade de perguntas, poderia ser muito útil.O cenário para este projeto envolveu a avaliação da capacidade de fabricação de peças compostas, com a pergunta frequentemente feita: "Qual é o número mínimo de recursos necessários para suportar uma determinada taxa de produção?" O que interessa são os recursos de moldes para layup de compósitos e autoclave, que, para peças aeroespaciais grandes, podem ser muito caros, com longos prazos de fornecimento.
Etapa 2: Para o cenário escolhido, crie uma linguagem de descrição do sistema.Essa etapa requer a captura da semântica neutra em termos de análise que os usuários empregam para falar sobre seus negócios e representá-los nos sistemas de informação. Essa linguagem evoluiu iterativamente durante o projeto-piloto, e seu estado na iteração final é capturado na Figura 3. Observe que esse é um modelo em nível de esquema e não de qualquer instância do sistema de produção - ele serve como uma definição comum para instalações, processos de fabricação, alternativas a eles, estados futuros desejados para eles e muito mais.
A linguagem da figura 3 se qualifica como um metamodelo abstrato para descrever sistemas de produção arbitrários? Certamente não - esse é o esquema de um usuário específico, e um esquema mínimo para um caso de uso específico, que pode diferir sintaticamente e até semanticamente dos esquemas de outros usuários. Os recursos importantes incluem a formação de lotes na autoclave (por volume de peça ou por uma lista específica de tipos e quantidades de peças) e também recursos emparelhados com peças por meio de várias etapas do processo (moldes de laminação compostos desde a pré-laminação até a pós-cura). Essas semânticas também permitem separar as definições de instalações físicas das definições de processos funcionais, pois um componente fundamental da questão da capacidade é que os planos de processos não são executados em um vácuo, mas sim em instalações específicas que executam vários planos de processos simultaneamente e compartilham recursos comuns. A semântica que não está incluída, mas que pode ser importante em outros cenários, inclui trabalhos com prazos, redes de viagens dentro e entre instalações, controle de roteamento de trabalhos e recursos, entre outros. A inovação da metodologia é que os programas geradores de análise são apenas levemente acoplados à linguagem de descrição do sistema na Figura 3, de modo que esses programas podem continuar funcionando enquanto a linguagem evolui (durante o projeto piloto, a linguagem evoluiu em aproximadamente oito iterações com intervalo de um mês). Em outras palavras, a metodologia relaxa o ônus de tornar uma linguagem de descrição do sistema "perfeita" antes de investir em programas geradores de análise que dependem dela.
Etapa 3: Tornar a pergunta precisaEssa etapa deve se tornar supérflua quando for atingido um certo nível de maturidade do suporte da ferramenta, mas é imperativa durante os primeiros projetos-piloto. A tarefa é determinar quais informações o autor da pergunta espera em uma resposta e como extrair ou inferir essas informações do resultado da simulação. Para a pergunta"Qual é o número mínimo de recursos necessários para suportar uma determinada taxa de produção?", suponha que a resposta retornada seja "x ey unidades de recursos dos tipos A e B são as quantidades mínimas necessárias para suportar, em média, 20 aviões por mês". Isso é suficiente ou também são esperados qualificadores de risco, como"x e y unidades de recursos dos tipos A e B produzirão apenas 19 aviões em α% dos meses e apenas 18 aviões em β% dos meses"? Um grande item para desenvolvimento futuro é o retorno de respostas com interpretações, qualificadores de risco e muito mais. A metodologia possibilita uma ferramenta de apoio à decisão, não uma ferramenta de tomada de decisão, porque a tomada de decisão deve refletir uma avaliação humana do risco, que pode ser o eixo x em alguma forma de gráfico de Pareto-fronteira que é retornado como resposta a uma pergunta.
Tornar a pergunta precisa também envolveu um esforço que foi exclusivo do primeiro projeto. Como a maior parte do trabalho era o desenvolvimento de software, foi seguido um paradigma de desenvolvimento em espiral com um período de iteração de cerca de um mês. A pergunta "Qual é o número mínimo de recursos necessários para dar suporte a uma determinada taxa de produção?" tornou-se o ponto alto de uma série de perguntas de marco:
Etapa 4: Mapear o modelo de sistema front-end para o modelo de abstração de ponte back-end, tanto quanto necessário para responder à pergunta. A eficácia da metodologia depende do acoplamento mais frouxo possível entre esses dois modelos, e o mais frouxo que podemos imaginar é uma especificação declarativa de uma transformação de modelo para modelo, cujo exemplo é mostrado na Figura 4.
O XML na figura 4 é uma representação de baixo nível com a qual não se espera que os usuários interajam diretamente - melhorias na usabilidade devem tornar a criação e a atualização de especificações declarativas de transformações de modelo para modelo muito mais fáceis de usar. No início do projeto, os autores imaginaram realizar esses mapeamentos por meio do mecanismo de aplicação de estereótipos UML (Batarseh et al. 2012). No entanto, isso logo se tornou insustentável devido à inflexibilidade - a aplicação de um estereótipo UML define efetivamente uma regra de transformação de um para um, o que restringe o modelo do sistema e o modelo de abstração de ponte a parecerem muito semelhantes e só diferirem efetivamente na sintaxe. Em seguida, os autores consideraram linguagens de transformação de modelo para modelo padronizadas e de uso geral, incluindo QVT ou ATL, mas as especificações de transformação eram bastante prolixas, e logo se percebeu que a incorporação do conhecimento do alvo da transformação permite uma simplificação drástica. Essa simplificação acarreta uma perda de flexibilidade, mas uma flexibilidade que não era necessária, de acordo com a conclusão de Cleenewerck e Kurtev (2007) de que "É melhor abordar o problema da semântica de tradução na engenharia orientada por modelos com uma linguagem de transformação específica do domínio em vez de uma linguagem de uso geral". O trabalho futuro inclui a reconciliação da linguagem de transformação personalizada e específica do domínio com um padrão como o QVT.
Etapa 5: criar modelos de instância e pressionar "go". Para responder a uma pergunta de capacidade de produção, a etapa final requer a descrição rápida do assunto da pergunta - instâncias de produtos, processos, recursos e instalações. O metamodelo da figura 3 é análogo às definições de classes de software que podem gerar um grande número de instanciações de objetos, e essa etapa requer a criação dessas instanciações de objetos. No projeto piloto, isso foi feito em um ambiente tabular e semelhante ao Excel, e um trecho é mostrado na figura 5.
As tabelas e seus esquemas na figura 5 estão em conformidade com o metamodelo da figura 3 - a operação é mapeada para uma tabela e cada atributo é mapeado para uma coluna. As tabelas e o esquema de um modelo de instância são gerados por meio de mapeamento objeto-relacional, e um usuário descreve o assunto da pergunta preenchendo as tabelas. Esse é um ambiente de modelagem que poderia se beneficiar de muitos aprimoramentos de usabilidade; um deles é que as tabelas mostradas aos usuários são efetivamente tabelas de banco de dados relacionais brutas, e a adição de uma camada de visualização permitirá a simplificação, a organização e a ocultação de dados redundantes (por exemplo, tabelas de junção que se seguem a qualquer atributo cujo limite superior de multiplicidade seja > 1). Outro aprimoramento é que, embora as tabelas e colunas sejam mostradas na figura 5 para cada elemento do metamodelo na figura 3, o conhecimento da pergunta do usuário permite a filtragem visual apenas das tabelas e colunas relevantes para responder a essa pergunta. Outro aprimoramento é adicionar a visualização ao modelo de sistema do usuário. À medida que as linhas da tabela são preenchidas, um modelo de abstração de ponte está sendo construído em segundo plano, e a visualização deve ser possível pelo menos para as visualizações de processos e instalações. Os aprimoramentos na usabilidade desse ambiente são essenciais para reduzir ao máximo o tempo e o conhecimento necessários para responder a perguntas rotineiras sobre a capacidade de produção.
Um exemplo de um modelo de simulação de evento discreto e de um experimento que são gerados automaticamente ao pressionar "go" é mostrado na Figura 6.
A transição do projeto para a produção é um processo comercial complexo, e a pesquisa descrita neste artigo apoia esse processo ao permitir que os projetistas avaliem as consequências das decisões de projeto na produção muito antes do ciclo de projeto de um programa do que é possível atualmente. Foi desenvolvida uma metodologia para permitir a resposta imediata a questões de capacidade de produção, e sua novidade é o grau de separação das preocupações - ela separa a descrição do sistema da análise do sistema e, além disso, separa a descrição concreta do sistema front-end da descrição abstrata do back-end. A implementação de um projeto piloto suporta modelos de sistema criados na linguagem Ecore, o conjunto de perguntas enumeradas na seção 3 e a geração de modelos de simulação e experimentos nas linguagens Simio, SimEvents e Tecnomatix Plant Simulation para responder a essas perguntas. A pergunta do projeto piloto dizia respeito ao número de recursos - uma mudança paramétrica - e a implementação também foi demonstrada para acomodar mudanças estruturais, incluindo mudanças nos planos de processo, mudanças nas atribuições de estação de trabalho, refinamento dos tipos de recursos, descrição em níveis de abstração e muito mais. No momento em que este artigo foi escrito, não havia diferença funcional entre as alterações paramétricas e estruturais, pois a implementação regenera totalmente um modelo de simulação para qualquer alteração no modelo de instância, embora isso possa se tornar mais sofisticado no futuro para fins de eficiência.
No final do projeto piloto, a implementação do software de prova de conceito foi implantada no cliente piloto. O cliente estima que, no caso de perguntas rotineiras sobre sistemas de produção, a implementação da metodologia por meio de uma ferramenta pode resultar em uma redução drástica no tempo, no custo e nos requisitos de especialização para usar a simulação e outros tipos de análise para responder a essas perguntas, uma redução de pelo menos uma ordem de magnitude. Essas reduções podem ser economizadas ou gastas para avaliar mais cenários de produção e seus impactos, considerar mais ideias e alternativas de melhoria e explorar mais o espaço de design de um sistema de produção. No entanto, o cliente também observa que são necessários vários aprimoramentos para atingir um Nível de Prontidão Técnica (TRL) avançado e produzir uma ferramenta que os analistas aceitariam em seu trabalho diário. A ferramenta é um ambiente de modelagem e transformação de modelos, e são necessárias melhorias na linguagem e na interface do usuário para a criação de esquemas de descrição do sistema, modelos de instância do sistema em conformidade, transformações para modelos de abstração de ponte e processos automatizados de formulação de análise. Essas melhorias ajudarão a delinear os tipos de perguntas sobre sistemas de produção que são de fato "rotineiras", e esse pode ser um conjunto surpreendentemente generoso.
Espera-se que essa pesquisa possa aumentar o mercado de análises de Pesquisa Operacional. A análise estatística, a simulação de eventos discretos e a análise de otimização podem responder a perguntas extremamente importantes, mas o tempo, o custo e os requisitos de especialização para seu uso no status quo podem ser proibitivos para todas as empresas, exceto as maiores. Há muitos caminhos para trabalhos futuros, sendo que os mais urgentes, na opinião dos autores, são a evolução das descrições de sistemas, desde a estrutura principal até modelos mais maduros, incluindo comportamento e controle, e a compreensão de processos de nível superior, incluindo projeto, diagnóstico e melhoria contínua. Uma compreensão profunda dos sistemas de engenharia industrial, além da capacidade de empregar de forma econômica a análise de pesquisa operacional conforme necessário, são pré-requisitos para tornar o projeto de sistemas de produção tão sofisticado quanto o projeto dos próprios produtos.
A pesquisa aqui relatada foi apoiada pela Georgia Tech por meio da Gwaltney Chair of Manufacturing Systems, por um subsídio da Rockwell-Collins e por projetos de pesquisa financiados pelo United Technologies Research Center e pela Boeing-Georgia Tech Strategic University Partnership.