INTEGRAÇÃO DE PLANEJAMENTO AUTOMÁTICO E SISTEMAS REAIS BASEADOS EM CLP

INTEGRAÇÃO DE PLANEJAMENTO AUTOMÁTICO E SISTEMAS REAIS BASEADOS EM CLP JOSÉ J. P. Z. S. TAVARES 1, JOÃO P. S. FONSECA 1, TIAGO S. VAQUERO 2, JOSÉ R. SILVA 2. 1. Mechatronics Automated Planning Lab, Faculdade de Engenharia Mecânica, Universidade Federal de Uberlândia Av. João naves de Ávila 2121 Uberlândia MG CEP 38400.299 E-mails: jean.tavares@mecanica.ufu.br, jpaulosfonseca@gmail.com 2. Design Lab, Departamento de Engenharia Mecatrônica e de Sistemas Mecânicos, Universidade de São Paulo Av. Prof. Mello Moraes, 2231 Cidade Universitária São Paulo SP CEP 05508-030 E-mail: tiago.vaquero@usp.br, reinaldo@usp.br Abstract Automated planning system has been developed for more than 40 years, however, their practical application in real problems is still restrict and, many times, a challenge. One of the reasons for such restriction relies on language ruptures. On one side, automated planning systems provides a plan with predefined sequences of actions represented in the Planning Domain Def - inition Language (PDDL); on the other side, real systems use equipments as PLC or Programming Logic Controller, which utilize languages as Ladder and centralizes sensor and actuation activities. With the recent development of modern knowledge engineering tools for modeling planning domains, model visualization and plan analysis has been assisted and facilitated. However, the centralization of operations in PLC makes the direct use of automatic generated plans hard. This article evaluates the integra - tion of automated planning techniques and real systems based on PLC. The article presents a practical example of such integra - tion using a didactic testing bench of automated planning. Keywords PLC, Ladder, Didactic Testing Bench, PDDL, Petri Nets Resumo Há quase 40 anos iniciou-se o desenvolvimento de sistemas de planejamento automático, porém, sua aplicação prática ainda é restrita e, muitas vezes, um desafio. Isso se deve ao fato de que as linguagens utilizadas, tanto nas aplicações reais, como nas soluções de sistemas com planejamento automático, apresentam grandes discrepâncias. Enquanto o planejamento automático apresenta um plano com seqüências pré estabelecidas baseadas em ações definidas previamente como se os objetos fossem autônomos em uma linguagem denominada Planning Domain Definition Language (PDDL); os sistemas reais fazem uso de equipamentos do tipo CLP ou Controlador Lógico Programável com linguagem do tipo Ladder e centralizam as operações de sensoriamento e acionamentos. Com o surgimento de ferramentas de modelagem de domínio de planejamento, a visualização do modelo, bem como do resultado dos planos, passou a ser facilitada. Todavia, a centralização das operações em CLPs dificulta a aplicação direta dos planos desenvolvidos. Esse artigo avalia a integração de soluções de planejamento automático e sistemas re - ais e apresenta um exemplo prático baseado em uma bancada didática de planejamento automático. Palavras-chave CLP, Ladder, Bancada Didática, PDDL, Rede de Petri. 1 Introdução Desde os primórdios novas descobertas sempre são vistas com desconfiança e descrédito. Isso ocorre pois transcendem paradigmas aceitos sem questionamento. A automação industrial é resultado de milhares de anos de desenvolvimento da sociedade e, também apresenta essa característica. De acordo com Castrucci e Moraes (2007) os sistemas de controle baseados a eventos atuais fazem uso de uma única seqüência em loop para realizar as operações programadas. Nesse caso, através de um clock pré-definido, o equipamento varre as entradas, executa a lógica interna, para, em fim, atualizar as saídas. O equipamento, inicialmente, centralizava as ligações entre sensores e atuadores. Com o desenvolvimento de novos tipos de comunicação, surgem redes como a Fieldbus, onde os sensores e atuadores são conectados num único barramento, porém, a lógica e processamento continua centralizada. Esse equipamento é denominado Controlador Lógico Programável (CLP). Há a tendência para que atuadores e sensores passem a ser mais autônomos, porém, isso ainda está em desenvolvimento e não foi implementado na prática. Por outro lado, desde 1971 com o surgimento do STRIPS (Filkes et Nilsson, 1971 ), sistemas baseados em lógica são criados para solução de problemas automaticamente. O conceito desses sistemas está na existência de um modelo do sistema real descrevendo as ações e regras de cada objeto que o compõe, um conjunto de entradas (situação inicial) e um estado desejado (situação final). Esse modelo faz uso de algoritmos de busca no modelo definido para encontrar um caminho que parta do conjunto de entradas e atinja o estado desejado. Há diversos quesitos que podem ser considerados para encontrar o plano mais adequado como, por exemplo, o tempo de resposta, custo, e restrições impostas. O que se vê é um grande abismo entre esses desenvolvimentos, o que dificulta que novas tecnologias e abordagens sejam integradas convenientemente. Nesse artigo apresenta-se um estudo de integração da solução de planejadores automáticos em sistemas reais com uso de CLPs. Para tanto, o artigo está estruturado nas seguintes seções. A seção 2 ISSN: 2175-8905 - Vol. X 1226

apresenta os fundamentos do planejamento automático. A ferramenta de modelagem de domínio de planejamento é descrita na seção 3. A seção 4 descreve como se procede a integração dessa ferramenta com CLPs. Um exemplo prático baseado em uma bancada didática de planejamento automático é descrito, seguido das discussões e conclusões. 2 Planejamento Automático O planejamento automático consiste em, dado um estado inicial do sistema, s 0, um estado final, s f, e um conjunto de ações A i, determinar uma seqüência de ações α A i tal que, destas técnicas da Inteligência Artificial a problemas reais entre estes os problemas de manufatura. Problemas reais de grande interesse têm sido abordados com estas técnicas como na logística dos sistemas portuários (Dahal 2003), ou na logística de carga, descarga e tanqueamento de petróleo no porto de São Sebastião (Sette et. al. 2008), ou ainda no roteamento de óleo cru em oleodutos (Li et. al. 2005). É preciso portanto ter um processo de projeto que permita associar o plano gerado pelas técnicas de planejamento a cada um dos sub-processos que substanciam as ações. A Figura 1 a seguir mostra a proposta de processo de projeto apresentada no sistema itsimple (Vaquero et. al. 2007) (Vaquero at. al. 2009). s 0 α 1... s j α j s k... α f s f (1) sendo que, em alguns casos, várias ações poderiam ser aplicadas ao mesmo estado, em paralelo. A resolução de um problema de planejamento pode ser feita on the flow, isto é, na medida que novos estados vão sendo gerados, um sistema inteligente opera no sentido de identificar novas ações; ou resolvendo inteiramente o sistema antes de aplicar o plano (usando planejadores automáticos). É possível pensar em um processo de fabricação na manufatura moderna como uma sucessão de ações independentes iniciadas por um acionamento e cuja finalização pode ser detectada por sensores. Estas ações podem ser realizadas por dispositivos, máquinas de comando numérico, AGV s, esteiras rolantes, robôs manipuladores, etc. Portanto estas ações são programas relativamente complexos, em diferentes linguagens, incluindo-se aí também as linguagens de programação de CLP s. Assim, o seqüenciamento aqui referido pode ser visto como uma integração de diferentes atividades, dispositivos e máquinas, para a obtenção de um processo mais sofisticado. Mesmo que o processo de detecção e acionamento possa também ser feito por CLP s, nota-se que uma linguagem deste nível não é adequada a este tipo de integração. O próprio processo de projeto não é factível em uma linguagem de baixo nível como a linguagem Ladder, ainda que no final do processo, se deseje justamente ter uma forma de acionar automaticamente a entrada destas ações usando um CLP (e detectando a condição de término das ações com sensores). Torna-se assim bastante atraente a possibilidade de se aplicar novas ferramentas de design para sistemas de planejamento e escalonamento neste tipo de integração, com as vantagens em precisão, análise de dependências, adaptabilidade e inserção de um comportamento inteligente no sistema. Até recentemente esta possibilidade era muito remota, dado que os problemas de planejamento automático eram tratados apenas como problemas modelo, sendo extraídos já diretamente em linguagens de especificação formal como a PDDL (Fox 2003). Entretanto, a partir da virada do século, uma discussão passou a dominar a comunidade de planejamento, e que se refere justamente à possibilidade do uso Figura 1: Processo de projeto adotado pelo ambiente itsimple Note-se que nesta proposta um tratamento é feito passando pela eliciação e análise de requisitos, modelagem e análise do modelo, antes mesmo de escolher o planejador adequado para a geração do plano. Uma vez feito o plano, este é analisado para detectar incorreções que podem ser o resultado de omissões e contradições nos requisitos que só podem ser detectados após a elaboração do plano (Vaquero et. al. 2010). Na seção seguinte descreveremos com mais detalhe o sistema itsimple e os recursos que pretendemos utilizar para a aplicação em sistemas de manufatura. 3 O Sistema itsimple O itsimple foi projetado para permitir que usuários tenham um processo de design disciplinado para criar modelos de conhecimento de diferentes domínios de planejamento automático. O processo sugerido e implementado na ferramenta para projetar os modelos de domínios segue uma seqüência de fases (cíclica) herdadas das Engenharias do Conhecimento e Software combinado a experiências adquiridas no design de aplicações de planejamento. O ambiente itsimple incorpora um conjunto de linguagens de representação e teorias capazes de lidar com requisitos e engenharia do conhecimento, associando-os ao ciclo de vida de projeto, conforme mostra a Figura 2. Entre as diversas linguagens de especificação e modelagem, o itsimple propõe a linguagem semi-formal UML (OMG, 2001) (lingua- ISSN: 2175-8905 - Vol. X 1227

gem diagramática bastante conhecida e utilizada na Engenharia de Requisitos e de Software) para estas fases iniciais na construção do modelo do conhecimento do domínio. Redes de Petri clássicas (MU- RATA, 1989) são usadas para verificação dinâmica dos planos, o que já é uma praxe em sistemas de manufatura discreta. Como a comunidade de Planejamento Automático em IA utiliza PDDL como um padrão de representação de domínios e como representação de entrada para os planejadores, o itsimple também integra esta linguagem (até a versão 3.0 da PDDL) no seu processo de projeto. Na versão atual, itsimple pode se comunicar com os principais planejadores disponíveis na literatura. Portanto, o processo de escolha do planejador ainda não é feito de fato e, nesta versão o sistema simplesmente prepara o domínio de aplicação (modelo do chão de fábrica e mais do problema de planejamento) para todos os planejadores incluídos. Em uma versão futura pretende-se eliminar este processo, elegendo somente os planejadores mais apropriados para o problema em questão. 4 Integração com CLPs Para que a seqüência de ações definidas na equação 1 possa ser transmitida a um CLP é necessário que o mesmo tenha uma relação unívoca entre as ações α i e um subconjunto de saídas digitais sd i conectadas atuadores existentes, tal que α i sd j,α i {sd j }, 0<i,j n (2) O CLP deve ser programado para avaliar se o subconjunto de entradas percebido equivale ao conjunto de estados esperado da seqüência. Caso o subconjunto seja equivalente, as pré-condições prec i definidas no projeto estejam atendidas, deverá executar a próxima ação. Após a execução da ação as póscondições proc i devem ser válidas para ir ao estado seguinte e assim sucessivamente até o término do plano. Dessa forma, um subconjunto de entradas digitais ed i conectadas a sensores existentes, devem estar relacionadas com uma pré-condição ou pós-condição existente prec i,proc i. prec i proc i ed j,prec i proc i {ed j }, 0<i,j n (3) Figura 2: Estrutura de representações e linguagens do sistema it- SIMPLE O itsimple é hoje um sistema de domínio público 1. Este sistema participou das três edições da competição International Competition on Knowledge Engineering For Planning and Scheduling (IC- KEPS), ficando em primeiro lugar na terceira edição, realizada em 2009. A ferramenta vem sendo utilizada para estudar, modelar e desenvolver aplicações reais de planejamento como, por exemplo, linha de montagem e pintura dos automóveis da Renault (Nguyen 2003), planejamento de atividades em portos petrolíferos no Brasil, entre outros. Entretanto, para os autores, o desafio maior é não só aplicar estes métodos para automação da manufatura, mas tornar isso um processo educacional, mostrando aos novos engenheiros como fazer a devida associação entre um processo de projeto sound e resultados concretos. Assim, descreveremos nas seções seguintes como associar o método e a própria ferramenta itsimple a uma bancada de laboratório em Automação da Manufatura. 1 itsimple. Disponível em http://code.google.com/p/itsimple/ Se o subconjunto de entradas digitais percebido for distinto das pré e pós-condições definidas, isso significa que o próximo estado não foi alcançado o que determina a necessidade de replanejamento. Vale ressaltar que o itsimple tem informações pertinentes às pré e pós-condições, porém, ainda não a transmite ao gerar um plano, apenas a seqüência de ações. As pré e pós-condição são essenciais para determinar se um determinado estado foi alcançado e se a próxima ação pode ser executada. Os CLPs quando acessados via rede apenas disponibilizam contatos lógicos, e não as entradas e saídas digitais diretamente. Sendo assim, é necessário introduzir uma outra conversão de entradas e saídas digitais em contatos lógicos e esses para ações e pré e pós-condições. O plano deve ser convertido nesses contatos lógicos para avaliar se a seqüência desejada de estados está sendo cumprida. A Figura 3 representa a lógica de interfaceamento entre itsimple e CLPs. O re-planejamento deve ocorrer quando se atinge um subconjunto de estados diferente da seqüência estabelecida no plano. Porém, caso surja um subconjunto de entradas distinto dessa seqüência, o re-planejamento pode requerer um refinamento do modelo. No itsimple o re-planejamento, que completa o ciclo evolutivo de design é feito com o auxilio das ferramentas de pré-análise, onde o modelo do plano e sua relação com o contexto são analisados para checar preferências e o atendimento aos requisitos, e na pós-análise, onde o plano já gerado pelos planejadores é novamente analisado, podendo gerar feedback para a operação de re-planejamento. ISSN: 2175-8905 - Vol. X 1228

Figura 5: Bancada de Planejamento Automático Figura 3. Interface entre itsimple e CLPs 5 Exemplo Prático 5.1 Bancada Didática de Planejamento Automático Foi desenvolvido uma bancada didática que simula o sistema de logística e transporte de um fornecedor para dois distribuidores utilizando um veículo controlado por um CLP da marca Onrom. Cada distribuidor possui uma bomba que serve a diversos clientes e o sistema de planejamento deve definir as entregas do veículo de forma a atender as demandas dos clientes dos distribuidores. O serviço de entregas do veículo é requisitado em função da variação do nível dos atacadistas. A Figura 4 apresenta o esquema do sistema proposto, enquanto a Figura 5 apresenta foto da bancada física construída. 5.2 Modelo da Bancada Didática no itsimple A modelagem começa com o diagrama de casos de uso. A bancada possui dois agentes, veículo (vehicle) e distribuidor (customer). Cada um tem três casos de uso. O veículo pode se mover, carregar (load) e descarregar (unload). O distribuidor pode efetuar uma venda completa (completeorder), ou uma venda parcial (partialorder) e sua complementação (finalorder). A Figura 6 apresenta o diagrama de casos de uso. Figura 6: Diagrama de casos de uso da Bancada Após esse diagrama deve-se elaborar o diagrama de classes. O modelo desenvolvido apresenta as classes referentes conforme a Figura 7. Os atributos e métodos inseridos são necessários para elaborar os diagramas de estado correspondentes. Figura 4: Esquema do sistema proposto Essa bancada possui quatro eletrobombas, um no fornecedor (para abastecer o veículo), outra no veículo (para atender os distribuidores), e mais duas em cada distribuidor para atender a demanda de seus clientes. O veículo possui dois motores 12Vcc para se movimentar. As posições do veículo são monitoradas por sensores fins de curso mecânicos. Tanto o veículo como os distribuidores possuem sensores de nível para monitorar a quantidade de produtos entregue aos distribuidores (pedido fixo entre distribuidores e fornecedor) e quantidade entregue aos clientes. No próximo tópico será descrito como foi modelada a bancada no itsimple. Maiores detalhes sobre essa modelagem se encontra em Tavares e Fonseca (2011). O foco desse artigo é mostrar como o plano se converte para Ladder de forma que CLP possa executar as ações e monitorar as pré e pós condições atingidas. Figura 7: Diagrama de classes da Bancada 5.3 O Problema e o Plano Resultante Os planejadores automáticos trabalham de maneira tal que, dada uma situação inicial e uma situação final que se deseja atingir, um algoritmo varre uma árvore de busca de forma a encontrar a solução que mais se adéque aos requisitos do projeto, que podem ser tempo de processamento, tempo de uma operação, custo de uma operação, etc. As métricas desenvolvidas neste modelo, que podem ser consideradas como custos a minimizar ISSN: 2175-8905 - Vol. X 1229

são transportcost (custo do transporte) e lostcost (custo de perda por não se atender uma demanda completamente). Estas variáveis são definidas como atributos da classe Global e sua representação lógica é dada nos Diagramas de Estados do Veículo e do Atacadista. O problema a ser resolvido é movimentar, carregar e descarregar o veículo v1 de forma a atender a demanda dos clientes dos distribuidores. Inicialmente o distribuidor a1 tem 10% de estoque disponível sendo que o estoque crítico é de 20% e tem 10% de estoque não entregue (abeyant_amount), enquanto o distribuidor a2 tem 30% de estoque disponível e um nível crítico de 20%. As Figuras 8 e 9 mostram o estado inicial e final correspondente a esse problema. Para cada sensor e atuador da bancada foi atribuído variáveis no CLP conforme Tabelas 1 e 2. Tabela 1. Sensibilidade x Entrada CLP Sensibilidade Entrada CLP Fim de Curso 1 (fc1) Entrada Digital 1 (I0.00) Fim de Curso 2 (fc2) Entrada Digital 2 (I0.01) Fim de Curso 3 (fc3) Entrada Digital 3 (I0.03) Sensor de Nível 1 (S1) Entrada Analógica 1 (I1.00) Sensor de Nível 2 (S2) Entrada Analógica 2 (I1.01) Sensor de Nível 3 (S3) Entrada Analógica 3 (I1.02) Tabela 2. Ação x Saída CLP Ação Saída CLP Eletrobomba 1 (B1) Saída Digital 1 (Q1.00) Eletrobomba 2 (B2) Saída Digital 2 (Q1.01) Movimento para esquerda Saída Digital 3 (Q1.02) Movimento para a direita Saída Digital 4 (Q1.03) Os sensores de nível foram conectados às entradas analógicas e armazenados em memórias auxiliares de acordo com a Tabela 3. Tabela 3. Entrada CLP x Memória Auxiliar Entrada CLP Endereço de Memória Auxiliar Entrada Analógica 1 (I1.00) A454 Entrada Analógica 2 (I1.01) A455 Entrada Analógica 3 (I1.02) A456 Figura 8: Situação Inicial Figura 9: Situação Final Utilizou-se o planejador Metric-FF (Hoffmann, 2003) para encontrar a solução desse problema e o plano se encontra abaixo. 0: LOAD V1 F1 LEVEL 5 1: MOVE V1 F1 A2 2: UNLOAD V1 A2 LEVEL 5 3: MOVE V1 A2 F1 4: LOAD V1 F1 LEVEL 7 5: MOVE V1 F1 A1 6: UNLOAD V1 A1 LEVEL 7 7: MOVE V1 A1 F1 8: LOAD V1 F1 LEVEL 4 9: MOVE V1 F1 A2 10: UNLOAD V1 A2 LEVEL 4 11: MOVE V1 A2 F1 5.4 Transformando o Plano em Ladder Esta possível solução faz com que o veículo v1 realize as ações em ordem para levar o sistema da situação inicial à situação objetivo. O plano gerado pode ser visto como uma sequência de ações necessárias, e assim, atingir a solução do problema. Antes disso, os sensores e atuadores devem ser identificados. Para aplicar o plano gerado pelo planejador automático no CLP, tanto os atributos como os operadores de cada classe (representada no Diagrama de Classes) devem estar associados a um conjunto de estados dos sensores e atuadores da Bancada. Por exemplo, a ação move(v1, f1, a2) corresponde ao movimento do veículo para o lado direito, ou seja, saída digital 4 (Q1.03) habilitada. A pré-condição para a habilitação desta saída é o veículo estar no fornecedor, ou seja, fc1 acionado que é o mesmo que entrada digital 1 (I0.00) habilitada. A pós-condição para esta ação é o veículo estacionado sobre o atacadista a2, ou seja, fc3 acionado ou entrada digital 3 (I0.02) habilitada. Atingido a pós-condição a saída digital Q1.03 deverá ser desabilitada. Isto deve ocorrer para todas as ações presentes no plano. Assim, a Tabela 4 representa parte da Tabela De Para necessária para facilitar a interface entre o plano-solução apresentado anteriormente e a Linguagem Ladder utilizada no CLP. As ações do plano-solução são representadas no CLP através dos endereços de memória W10.xx onde xx é o valor dado a ação do plano-solução (Tabela 5). Desse modo, partiu-se de um modelo da bancada, o qual foi utilizado por um planejador automático que gerou um plano a partir dos requisitos apresentados. Este plano foi traduzido para uma linguagem operacional, de modo que, aliada com o mapeamento de entradas e saídas do CLP, foi possível a confecção do diagrama Ladder correspondente ao plano-solução. A Figura 10 ilustra uma parte do diagrama Ladder obtido através da metodologia descrita para este artigo. Neste caso, a ocasião da situação inicial W10.00 (snapshot inicial) habilita o relé W20.00 (Trans0). Este relé marca a transição entre a situação inicial e ISSN: 2175-8905 - Vol. X 1230

a Ação nº 0 (Load v1 f1 level 5). Esta ação está associada diretamente à energização da eletrobomba 1 através da habilitação da saída digital Q1.00. Além disso, a Ação nº 0 está condicionada com a não-habilitação da Transição 1 (entre essa ação e a seguinte). Esta, por sua vez, será habilitada assim que o sensor de nível do reservatório do veículo indicar 50%. Neste momento, a Ação nº 0 é desabilitada e a Ação nº 1, habilitada. Este processo continua até o sistema atingir o snapshot final. Tabela 4 Tabela De Para Parcial Plano Ladder Tabela 5. Ações do Plano e Endereços de Memória do CLP Ação Endereço de Memória do CLP 0 W10.00 1 W10.01 2 W10.02 3 W10.03 4 W10.04 5 W10.05 6 W10.06 7 W10.07 8 W10.08 9 W10.09 10 W10.10 11 W10.11 Figura 10. Diagrama Ladder parcial do domínio Bancada. 6 Discussão e Conclusão Esse artigo apresentou um estudo de integração da solução de planejadores automáticos em sistemas reais com uso de CLPs. Uma bancada didática de planejamento automático foi desenvolvida e modelada através do software itsimple3.0 e o plano apresentado foi transcrito para um CLP da Onrom CJ1M CPU13, para que o mesmo pudesse ser executado. A transferência foi manual e, caso alguma situação inesperada aconteça, isso implicará em replanejamento e nova transferência manual. O CLP trabalha de forma cíclica enquanto os planejadores automáticos atendem uma situação específica. Esse é um trabalho inicial para maior estudo sobre aplicação de sistemas de planejamento automático e replanejamento. Agradecimentos Os autores agradecem a EPUSP, FEMEC, USP, UFU, CNPq, FAPESP e FAPEMIG. Referências Bibliográficas Castrucci, P., Moraes, C. C. de. (2001) Engenharia de Automação Industrial, Editora: Ltc, Edição : 1 / 2001 Dahal, K., S. Galloway, G. Burt, J. McDonald and I. Hopkins (2003). Port system simulation facility with an optimization capability. In: International Journal of Computational Intelligence and Applications, vol. 3, no. 4, pp. 395-410. Fox, M., and D. Long (2003). PDDL2.1: An extension of PDDL for expressing temporal planning domains. In: Journal of Artificial Intelligence Research (JAIR), 20:61 124. Hoffmann, J., S. Edelkamp, R. Englert, F. Liporace, S.Thiébaux and S. Trug. (2004). Towards Real- istic Benchmarks for Planning: the Domains Used in the Classical Part of IPC-4. In: Booklet of the Fourth International Planning Competition, pages 7-14, June. Li, J., L. Wenkai, I. A. Karimi and R. Srinivasan (2005). Robust and Efficient Algorithm for Optimizing Crude Oil Operations, In: American Institute of Chemical Engineers Annual Meeting. Murata, T. (1989). Petri Nets: Properties, Analysis and Applications. IEEE Proceedings, vol. 77, no.0 4, April. Nguyen, A. (2003). Challenge ROADEF 2005: Car Sequencing Problem. Renault, France. Sette, F.M., Vaquero, T.S., Park, S.W., Silva, J.R. (2008). Are Automated Planers up to Solve Real Problems?. Proc. IFAC Conf., Seoul. Tavares, J.J.P.Z.S., Fonseca, J.P.S., (2011). Didatic Test Bench For Automated Planning. In Proc. of 21st Brazilian Congress of Mechanical Engineering, Natal, Brazil. To be presented. Vaquero, T.S., Romero, V., Tonidandel, F., Silva, J.R. (2007). itsimple2.0: an integrated tool for designing planning environments. Proc. of the 17 th. Int. Conf. on Automated Planning and Scheduling, Rhode Island, USA, AAAI Press. Vaquero, T.S., Silva, J.R., Ferreira, M., Tonidandel, F., Beck, J.C., (2009). From Requirements and Analysis to PDDL in itsimple3.0. Proc. Int. Competition in Knowledge Eneginering for Planning and Scheduling (ICKEPS 2009), 54-61. Vaquero, T.S., Silva, J.R., Beck, J.C., (2010). Improving Planning Performance Through Post- Design Analysis. Proc. of 19 th Int. Conf. on Planning and Scheduling, Workshop on Knowledge Engineering for Planning and Scheduling (KEPS), 45-52. ISSN: 2175-8905 - Vol. X 1231