ESTRUTURA DO PROTÓTIPO DO SISTEMA INTELIGENTE DE SIMULAÇÃO



No capítulo anterior, os vários elementos associados ao planejamento e controle operacional de SFM, e suas combinações, foram estudados e testados. Uma série de conclusões sobre seus efeitos foram delineadas. A partir destes estudos, testes e conclusões, um conjunto organizado de conhecimentos foi adquirido. Tais conhecimentos são parte integrante de um agregado maior de informações, regras e procedimentos que. aliados ao bom senso, são utilizados pelos analistas na busca do melhor desempenho operacional possível em SFM.

Neste capitulo, apresentamos a estrutura do protótipo de um sistema inteligente de simulação que constitui-se da integração entre o modelo de simulação com alocação dinâmica de recursos, desenvolvido no capítulo III, e um sistema especialista.

O sistema especialista procura reunir o conhecimento por nós adquirido quando da aplicação do modelo aos vários problemas apresentados no capítulo IV além, de outras informações, regras e procedimentos gerais, tomados da literatura e do contato com profissionais da área.


5.1 Objetivo do Protótipo

O protótipo desenvolvido, tem por objetivo auxiliar o usuário/decisor a buscar um desempenho operacional satisfatório para o SFM sob análise, considerando os seus inúmeros parâmetros e restrições operacionais.

O uso de um modelo de simulação, ou mesmo de outras ferramentas utilizadas na busca de soluções que satisfaçam os objetivos, as metas e as várias restrições, é urna tarefa com um alto grau de dificuldade imposta a qualquer decisor.

Pelo uso do protótipo, o usuário poderá desenvolver uma série de exercícios interativos/investigativos que busquem alcançar o equilíbrio operacional do SFM sobre o qual ele está trabalhando.


5.2 Estrutura do Protótipo

O protótipo é constituído de uma estrutura modular, visando facilitar seu uso. Os módulos, que possuem diferentes características e funções, são acossados por meio de wna interface gráfica, pela ação direta do usuário. A figura 5.1, apresenta a estrutura geral do protótipo. Nela, observamos seus três principais elementos: o Módulo de lnterface Gráfica Usuário/Sistema (GUI), o Módulo de Simulação (MS) e o Módulo de Análise (MA). O primeiro é a interface gráfica que permute ao usuário a interação entre ele e o sistema, com pleno acesso aos dois outros módulos. A ativação, via GUI, do MS, torna possível ao usuário a execução das tarefas associadas a modelagem e simulação de um SFM. A ativação, também via GUI, do MA, permite ao usuário, valendo-se do auxílio do sistema especialista, realizar a análise dos resultados das simulações e a formulação de novas estratégias gerenciais, afim de melhorar o desempenho operacional do SFM.

5.2.1 lnterface Gráfica Usuário-Sistema (GUI)

O usuário tem no módulo de interface gráfica (GUI), o principal meio de acesso aos dois módulos executores de tarefas do protótipo, o MS e o NU. Além desta função básica. é também via GUI, que o usuário executa o processo interativo na busca de um melhor desempenho operacional do SFM. Neste processo, são executadas trocas de informações entre o MS e o MA. A comunicação entre os dois módulos operativos fica transparente ao usuário que, no entanto, permanece no controle de todo o processo via interface gráfica.

A interface gráfica do usuário (GUI), é constituída de um conjunto de objetos gráficos, tais como telas, janelas, menus, botões, etc. através da qual o usuário controla todas as ações executadas pelo protótipo. A tela inicial da interface, apresentada na figura 5.2, permite ao usuário, por meio dos botões, acessar tanto o MS quanto o MA, dando inicio a trabalhos de simulação, análise ou a ambos de forma interativa.

5.2.2 Módulo de Simulação

O modelo de simulação desenvolvido neste trabalho, faz uso do SIMAN [PENGDEN, 1990], uma linguagem de simulação (programação) voltada para este tipo de aplicação.

Linguagens de simulação, assim como algumas linguagens de programação, permitem relativa flexibilidade na abordagem ao problema mas, muitas vezes, são ineficientes na criação de interfaces com o usuário. Esta ineficiência, geralmente não causa grandes transtornos quando usuário e programador são a mesma pessoa. No entanto, quando se trata de diferentes pessoas, a necessidade de interfaces amigáveis é quase que uma obrigação.

A partir desta constatação, desenvolvemos uma interface gráfica voltada ao MS, para que o usuário possa navegar e fazer uso deste com certa facilidade.

O módulo de simulação (MS) deve ser ativado pelo usuário sempre que este desejar executar a simulação de um modelo de SFM ou outras tarefas associadas a uma simulação, como por exemplo, visualizar e/ou trocar parâmetros de todos os elementos constituintes de um SFM, visualizar e/ou trocar parâmetros relativos as regras ou políticas operacionais, visualizar e/ou trocar parâmetros relativos ao cenário sob o qual deseja testar/simular o sistema, salvar os parâmetros em arquivos para utilização futura e, executar a simulação.

Uma vez que o usuário tenha ativado o MS, duas alternativas de ações básicas, como pode ser visto na figura 5.3, podem ser ativadas: a execução da simulação ou a definição de parâmetros, para a posterior execução de uma simulação.

A opção Executar Simulação permite que o usuário execute diretamente do protótipo uma simulação de um modelo de SFM cujos parârnetros tenham sido previamente definidos e salvos em arquivo.

Já a opção Definir Parâmetros da Simulação, leva o usuário as alternativas Mostrar/Alterar Parâmetros ou Salvar Parâmetros. A primeira alternativa, permite que sejam verificados ou alterados os parâmetros relativos aos principais elementos de um modelo de SFM tais como:

· As peças a serem produzidas e todas as suas características, isto é, suas seqüências de operações e respectivos tempos;

· As máquinas do SFM (número de máquinas, operações executáveis, índices de eficiência, os tamanhos de buffer, etc.);

· Os equipamentos de transporte, VAGs e Pallets (números disponíveis, velocidade dos VAGs, etc.);

· As políticas operacionais desejadas ao despacho das peças, dos veículos, etc;

· O cenário sob o qual a fabricação será simulada, caracterizado pelos tipos de peças a serem produzidas, o tamanho do lote e seu mix.

Ao terminar a verificação ou alteração dos parâmetros, o usuário poderá passar a execução direta do modelo ou salvar as alterações em arquivos para posterior utilização.

A figura 5.4 apresenta uma visão geral das possibilidades oferecidas ao usuário/decisor quando este ativa o MS.

5.2.3 Módulo de Análise

A partir da tela inicial do protótipo (ver figura 5.2), o usuário poderá ativar o Módulo de Análise dos Resultados da Simulação (MA). Este módulo, permite três opções básicas, como se pode observar na figura 5.5 que apresenta a tela inicial do NU.

Uma vez nesta janela, a escolha da primeira opção (Atualiza Resultados da Simulação) permite ao usuário atualizar os arquivos com os resultados da última simulação. Desta forma, após uma rodada de simulação, o usuário deve primeiramente atualizar os resultados pois, de outra forma, se optar diretamente pela sua visualização (segunda opção), estará observando os resultados da simulação anterior. Por opção do usuário, esta atualização poderá ser automática após cada simulação.

A escolha da segunda opção (Mostra Resultados da Simulação) permite ao usuário visualizar os resultados de uma simulação. Por exemplo, nos resultados relativos as peças manufaturadas, o analista poderá verificar quantas peças de cada tipo foram produzidas, se as metas de produção foram alcançadas, qual o tempo médio de fluxo destas pelo sistema ou ainda um diagnóstico deste tempo médio, estabelecido de acordo com parâmetros anteriormente definidos. A figura 5.6 ilustra estes resultados.

A terceira opção (Análise dos Resultados da Simulação), conduz o usuário ao principal objetivo do NU, isto é, inicializar o processo de análise dos resultados. Esta opção ativa o SE e toda a estrutura de decisão (ver detalhes no item 5.3), possibilitando ao usuário contar com um auxiliar para a elaboração de análises relativas ao desempenho operacional do SFM.

A figura 5.7 mostra a estrutura geral do módulo de análise e as possibilidades oferecidas
ao analista quando este o ativa.

5.3 O Sistema de Decisão

Nos itens anteriores detalhamos a estrutura do protótipo, descrevendo seus três principais módulos, em especial o ambiente gráfico pelo qual o usuário interage com o sistema.

O objetivo dos tópicos seguintes é descrever os detalhes internos do protótipo, Isto é, os processos que se desencadeiam quando o usuário inicia e dá continuidade a todo um procedimento interativo na busca de um desempenho operacional satisfatório para o SFM sob análise.

Iniciamos detalhando o processo de comunicação entre o MS e o MA, parte integrante do procedimento interativo/investigativo, e concluímos com uma descrição da estrutura de decisão, em especial do sistema especialista.


5.3.1 Comunicação entre o Módulo de Simulação e o Módulo de Análise

Como pode ser visto na figura 5.8, os dois principais módulos do protótipo, o MS e o MA, comunicam-se entre si, tomando possível ao analista a execução automática das simulações e análises, sem precisar estar Saindo ou entrando em diferentes programas computacionais.

Toda a comunicação entre os dois módulos é feita por meio de funções que criam, exportam e importam arquivos, coordenando a troca de dados entre os módulos. Para poder executar uma simulação, o MS deve ser alimentado com todos os parâmetros operacionais necessários.

Uma vez que o modelo de simulação está totalmente parametrizado, ao dar inicio a uma
Simulação, um programa conectado ao modelo busca um arquivo contendo todos os parâmetros. Este arquivo foi previamente construído pelo analista, fazendo uso da interface gráfica do usuário (GUI), e exportado ao MS.

Após o término da simulação, o MS inicia um processo no sentido inverso, isto é, cria outro arquivo de dados, contendo todos os elementos necessários à análise dos resultados, e o envia de volta ao MA. O analista pode então dar início aos processos de análise.

Na figura 5.9, observa-se com mais detalhes, os elementos das duas estruturas.

O desenvolvimento deste tipo protótipo, em especial a construção de interfaces entre seus vários elementos é, geralmente, facilitado pelo uso de técnicas de Programação Orientada a Objeto (POO).

Com este propósito, fizemos uso de uma ferramenta especialmente voltada ao desenvolvimento de sistemas inteligentes com orientação a objeto, o KAPPA PC Development Applications System [INTELLICORP, 1992], para a construção do protótipo.

O KAPPA é uma ferramenta híbrida que permite a representação do conhecimento sob diferentes formas e, vários mecanismos de controle na máquina de ingerência. Além disso, por rodar sob o ambiente operacional Windows 3.1, oferece as mesmas possibilidades de criação de interfaces gráficas com o usuário daquele ambiente. Suas características são apresentadas a seguir, em conjunto com os principais elementos constituintes do sistema de decisão, com suas regras de produção, frames, métodos e funções


5.3.2 A Estrutura de Decisão

A estrutura de decisão do protótipo foi montada de acordo com os elementos, próprios para o desenvolvimento de aplicações, disponíveis no KAPPA. Fizemos intenso uso de estruturas voltadas ao desenvolvimento de sistemas especialistas, conceituadas no capítulo 2, tais como classes, objetos, frames, regras de produção, etc. (ver item 2.6.3. daquele capítulo), as quais são agora revistas, mostrando-se seu emprego.


5.3.2.1 Classes, Objetos, Frames, Slots e Métodos

No KAPPA, à semelhança de outras linguagens de POO (como C++, SmallTalk, ADA, etc.), o sistema é estruturado por meio de classes e objetos, o que permite o uso do conceito de hierarquia, isto é, os atributos pertencentes a um objeto, são herdados pelos seus descendentes (subclasses, instâncias, etc.).

No presente estudo, objetos como máquinas, transportadores, peças, operações, etc., são representados em classes. Cada uma possui um conjunto de atributos paradescrevê-los e qualquer dos seus herdeiros (subclasses ou instâncias), tais como Máq. l, Máq. 2, VAGs, Peça l, etc., também os possuirão. Além disso, alguns destes herdeiros possuem características próprias, que os diferenciam uns dos outros.

A figura 5.10 ilustra parte da estrutura do protótipo, apresentando alguns dos seus objetos na forma de classes e instâncias. Podemos observar, por exemplo, a classe Máquinas e seus descendentes Máq l, Máq 2, Máq 3 e Máq 4. Os últimos são chamados de instâncias, por se encontrarem no último nível desta classe.

Aliado ao conceito de classes, está o conceito de frames (ver item 2.6.3.1, do capítulo 2), elemento típico de sistemas inteligentes orientados a objeto. Os frames são as estruturas nas quais estão definidos os objetos do sistema, bem como a forma e os meios pelos quais eles interagem entre si e com o mundo exterior, por meio do envio de mensagens.

Um frame constitui-se de dois tipos básicos de informações: um conjunto de atributos, também conhecidos como slots, e um conjunto de métodos. Portanto, cada objeto definido no sistema (classes, subclasses e instâncias), possui associado si, dentro de um frame, um conjunto de atributos e um conjunto de métodos associados a estes atributos.

Os atributos são tipicamente um conjunto de características, ou qualidades de cada objeto, através dos quais podemos distingui-los uns dos outros. Já os métodos, são semelhantes a funções ou rotinas, designados a executar ou desencadear uma ação. Estão associados a um ou mais atributos, sendo automaticamente ativados quando ocorre a alteração dos valores destes atributos. Estes dois conjuntos de informações contidas nos frames, caracterizam, de maneira completa, cada objeto do sistema.

Na figura 5.11 podemos observar a classe Máquinas com a lista parcial de seus atributos (slots) e dois métodos pertencentes a esta classe e a seus descendentes.

Nos sistemas desenvolvidos com o KAPPA, os métodos podem ser ativados de três diferentes maneiras:
· por meio de mensagens enviadas por outros método, pertencentes a outros objetos;
· através da alteração do valor de um slot ou atributo ao qual o método esteja atrelado;
· via funções, que também podem enviar mensagens para ativar os métodos.

Uma vez que a metodologia proposta pressupõe um processo interativo, com base na comunicação entre o módulo de simulação e o módulo de análise, a possibilidade do uso de métodos, associados aos atributos dos objetos do sistema, permite automatizar, sobremaneira, este processo de comunicação.

A automatização deste processo, traz consigo urna série de facilidades para o usuário uma vez que inúmeros procedimentos tais como: criação, leitura e atualização de arquivos, análise de resultados, atualização de parâmetros para novas rodadas de simulação, etc., são repetitivos e constantemente realizados.

Um exemplo típico da aplicação de métodos para a automatização de procedimentos, ocorre ao término das rodadas de simulação, durante as interações. Naquele momento, inúmeras variáveis devem ter seus resultados atualizados e avaliados. Dentre estas podemos citar, por exemplo, a taxa média de utilização das máquinas.

O valor final destas taxas é calculado no programa de simulação, atribuído as variáveis correspondentes a cada máquina e transferido ao arquivo de resultados, que será lido pelo modulo de análise. No módulo de análise, a leitura do arquivo de resultados da simulação, atualiza os valores de vários atributos de objetos do sistema.

Por exemplo, a classe Máquinas, que é constituída de quatro instâncias, Maq l, Maq 2, Maq 3 e Maq 4 (ver figura 5.1O), possui um atributo denominado UtilMedMaq. Por força do conceito de hereditariedade, suas quatro instâncias herdam, automaticamente, este atributo. Desta forma, quando ocorre a leitura do arquivo de resultados, os valores do atributo UtilMedMaq, nas quatro instâncias da classe Máquinas, são atualizados, recebendo os valores da taxa média de utilização de cada uma das máquinas do SFM simulado.

Conforme citamos, a alteração ou atualização do valor de um slot ou atributo, pode ativar um ou mais métodos que estejam a ele associados. Na classe das Máquinas e, consequentemente, nos seus decendentes (instâncias), o atributo UtilMedMaq está associado ao método Diag_Util_ Máq. Desta forma, sempre que o Módulo de Análise executa a leitura do arquivo de resultados, com a imediata atualização do atributo UtilMedMaq, uma mensagem é, internamente, disparada, ativando o método Diag_Util-Máq.

Na figura 5.12 observamos o método Diag_Util_Máq que é ativado pela atualização dos valores do atributo UtilMedMaq. Na janela intermediária, é possível ver o atributo Diag_Util_Máq que recebe o resultado da execução do método.

O objetivo deste método, em particular, é diagnosticar a forma de utilização das máquinas, isto é, determinar, segundo critérios preestabelecidos associados aos atributos MínUtilMaq e MaxUtilMaq, se as máquinas estão sendo sub, sobre ou normalmente utilizadas. Os três possíveis resultados para o atributo Diag_Util_Maq podem ser Baixa, Alta e Normal, respectivamente.

Dependendo do resultado deste diagnóstico, outras mensagens, dirigidas a outros
métodos, podem ser enviadas, dando inicio a um processo em cadela, o qual é automático e transparente ao usuário, mas que deixa o sistema sempre atualizado ao fim de cada interação.

A estrutura completa das classes, com seus slots e métodos desenvolvidos no protótipo pode ser vista no Anexo 2, Objetos do Sistema.


5.3.2.2 Regras de Produção

O segundo conjunto de elementos utilizados no desenvolvimento do módulo de análise, é constituído por regras de produção. No KAPPA, existe um ambiente com ferramental completo para o desenvolvimento e emprego de regras de produção. No protótipo utilizamos esta estrutura para desenvolver dois diferentes grupos de regras: o GRDLME (Grupo de Regras para Diagnóstico Local de Máquinas e Equipamentos) e o GRDGME (Grupo de Regras para Diagnóstico Geral de Máquinas e Equipamentos).

No primeiro grupo de regras, incluímos aquelas cujo objetivo principal é o diagnóstico local dos vários grupos de elementos do sistema, tais como, as máquinas, os transportadores, etc.. Assim, se for seu desejo, o analista poderá valer-se destas regras que, em conjunto com alguns métodos, permitem, rapidamente, o diagnóstico do comportamento destes grupos de elementos.

Por exemplo, após cada rodada de simulação, os resultados são automaticamente transferidos ao, alimentando e atualizando, os vários pares de objetos:atributos do sistema. Como vimos anteriormente, tais atualizações geram um conjunto de mensagens endereçadas a vários métodos. Estes, uma vez ativados, realizam alguns cálculos e pequenos diagnósticos 'individuais, isto é, ao nível de cada equipamento. máquina, transportador, tipo de peça fabricada, etc.

Este conjunto de novos fatos, decorrentes de cada nova rodada de simulação, pode então ser confrontado com a base de conhecimentos do sistema especialista, mais precisamente com suas regras de produção e, por meio da máquina de ingerência do sistema, gerar diagnósticos de maior amplitude. Tais diagnósticos podem indicar, por exemplo, gargalos no sistema produtivo e, a partir daí, sugerir ações para evita-los.

No segundo grupo de regras, incluem-se aquelas que tratam da análise global do desempenho do SFM. Esta análise, objetiva o seu balanceamento operacional.

Após definir claramente para o sistema suas preferências em termos dos parâmetros e regras operacionais, o analista pode dar inicio ao processo interativo de simulação e análise. A cada simulação executada, o sistema realiza automaticamente os diagnósticos individuais, utilizando os métodos e algumas das regras do primeiro grupo. Nesta primeira fase não há interferência do usuário. A partir deste ponto porém, por meio deste segundo grupo de regras, o usuário, se assim o desejar, poderá ser auxiliado na análise do comportamento operacional do sistema. O resultado de cada análise, é uma indicação por parte do MA, do tipo de ação que deve ser efetuada para uma melhoria contínua do desempenho do SFM. O SE contido no MA procura levar a convergência do processo.

O encerramento das análises ocorre quando o XU considera que, dentro dos limites e restrições impostas pelas preferências do usuário, não haverá mais possibilidades de melhorias no desempenho do SFM. No capítulo VI, faz-se uma aplicação do protótipo a um dos problemas vistos no capítulo IV, demonstrando sua maneira de operar, utilizando os dois grupos de regras.


5.3.3 O processo de Análise Executado pelo MA

Internamente ao NU, o processo de análise se inicia com uma varredura sobre os resultados da simulação, gerando uma série de diagnósticos que sintetizam o desempenho dos principais elementos do sistema. Estes diagnósticos são realizados automaticamente pelos diversos métodos. Dentre os vários diagnósticos preliminarmente realizados, os principais são:

· Diagnóstico de Utilização das Máquinas;
· Diagnóstico de Utilização dos VAGs;
· Diagnóstico do Tempo Médio do Ciclo de Produção;
· Diagnóstico dos Tempos Médios de Fluxo das Peças;
· Diagnóstico das Filas das Máquinas;
· Diagnóstico de Confiabilidade de Máquinas e Transportadores;
· Diagnóstico de Utilização Relativa das Máquinas, etc..

Os resultados de todos estes diagnósticos, a nível local, individuais para cada uma das máquinas e equipamentos, são então examinados, em conjunto, pelos dois grupos de regras anteriormente citados.

Desta forma, para apontar, por exemplo o Diagnóstico Operacional Global das Máquinas, o MA aciona o GRDLME, combinando os resultados do Diagnóstico de Utilização das máquinas com o Diagnóstico de Filas, gerando o Diagnóstico Operacional Global das máquinas.

Num segundo passo, combina, usando as regras do GRDGME, este Diagnóstico Operacional, com os de Confiabilidade , Utilização Relafiva das Máquinas e o de Tempo de Carga e Descarga, gerando o Diagnóstico Operacional Global das Máquinas. A figura 5.13 sintetiza o caminho percorrido pelo sistema para a obtenção deste diagnóstico global

De maneira semelhante, outros métodos e os conjuntos de regras concluem diagnósticos para os VAGs, Pallets, Peças, etc.. Conforme colocamos anteriormente, muitos destes métodos e regras, são ativados e atuam de forma transparente para o analista, de tal maneira que, no momento que este decidir buscar auxílio do MA para a tarefa final de análise de desempenho do sistema, estes diagnósticos preliminares já foram determinados, estando o sistema pronto para ativar outros conjuntos de regras e métodos.

O principal conjunto de regras associado a esta fase fmal das análises, é denominado de ROTMS (Regras de Otimização do Sistema). São elas que, baseando-se em todos os diagnósticos preliminares e, nas rodadas de simulação já realizadas, determinam se o sistema, operacionalmente, está melhorando ou não, sugerindo modificações após cada análise, na busca da obtenção de melhores resultados numa próxima rodada de simulação. A figura 5.14 apresenta um exemplo deste tipo de regra.

Esta regra, por exemplo, verifica-se se as seguintes afinações são verdadeiras: não existe nenhuma máquina sobre utilizada; a utilização média dos VAGs não excedeu o limite máximo estabelecido; houve melhorias sobre o tempo do ciclo de produção anteriormente obtido; o tamanho dos buffers e o número de pallets utilizados, relacionados com o número de VAGs não ultrapassou a relação ótima calculada.

Uma vez que sejam verdades todas as afinações, a regra diagnostica o sistema e sugere ao usuário uma ação. No caso específico, o Diagnóstico/Ação é :
"Os resultados da simulação mostraram melhoras no desempenho do sistema.
O número de Pallets ainda se encontra abaixo de seu limite máximo em relação ao tamanho dos Buffers e VAGS.
O MA sugere que se volte a simular com um incremento no número de Pallets"

Com base nestes resultados, o usuário pode aceitar a sugestão do sistema e voltar a simular com um incremento do número de pallets ou, realizar outro tipo de modificação de acordo com seu próprio sentimento em relação ao comportamento operacional do sistema.

O conjunto completo das regras utilizadas no protótipo pode ser encontrado no Anexo 3.


5.4 Sumário

Neste capítulo apresentamos a estrutura de um protótipo de sistema computacional voltado para a simulação e análise de SFM. O objetivo deste protótipo é a integração do modelo de simulação desenvolvido no capítulo III e de um módulo inteligente de análise, composto de uma estrutura híbrida, formada por um sistema especialista, com suas regras de produção e por frames, com suas classes, objetos, instâncias e métodos.

Apresentamos, também, a interface gráfica com o usuário (GUI). Esta interface é o meio que permite, tanto a integração de todos os módulos do protótipo, como a facilidade de seu uso pelo usuário.

No capítulo que se segue, apresentaremos um exemplo de utilização prática do protótipo, demonstrando sua utilidade, flexibilidade e facilidade de uso.