CONTROLE DE UMA COLUNA DEBUTANIZADORA SIMULADA UTILIZANDO UM

CONTROLADOR FUZZY EMBARCADO EM UMA REDE FOUNDATION FIELDBUS

ALEXANDRE M. P. P. FILHO*, KENNEDY R. LOPES*, VICTOR L. C. M. DA SILVA*, DANIEL L. MARTINS*, ADRIÃO D. D. NETO*, JORGE D. DE MELO*, LUIZ A. GUEDES*

*Laboratório de Sistemas Inteligentes

Departamento de Engenharia de Computação e Automação

Universidade Federal do Rio Grande do Norte

E-mails: [amppf, kenreurison, victor1706, danlartin, adriao, jdmelo, affonso]@dca.ufrn.br

Abstract The aim of this paper is to develop a fuzzy controller using only standard function blocks from a Foundation Field-bus network to conciliate this technology to the industrial networks paradigm. The controlled plant is a debutanizer column simulated on the software Hysys, obtaining then a hybrid system with real instruments and a simulated plant, where the commu-nication between the controller and the plant is done through a software developed in LabView that communicates with Hysys and with the acquisition system from the real instruments. The control system contains the three basic components of a fuzzy controller: a fuzzificator, a rule base and a defuzzificator.

Keywords Foundation Fieldbus, Intelligent Control, Fuzzy

Resumo O objetivo deste trabalho é desenvolver um controlador fuzzy utilizando apenas blocos funcionais padrões de uma rede industrial Foundation Fieldbus, para conciliar essa tecnologia ao paradigma das redes industriais. A planta a ser controlada consiste de uma coluna debutanizadora simulada no software Hysys, obtendo assim um sistema híbrido com instrumentos reais e uma planta simulada, onde a comunicação entre o controlador e a planta é feita através de um programa feito em LabView que se comunica tanto com o Hysys quanto com as placas de aquisição de dados dos instrumentos reais. O sistema de controle contém os três componentes básicos de um controlador fuzzy: um fuzzificador, uma base de regras e um desfuzzificador.

Palavras-chave Foundation Fieldbus, Controle Inteligente, Fuzzy.

1 Introdução

Com o avanço da tecnologia microeletrônica (F. S. de Lima et al., 2004) foi possível incorporar aos sen-sores de campo um maior poder de processamento de dados, permitindo que estes equipamentos realizem operações mais complexas. Aliado a isso, verifica-se o uso destes equipamentos interconectados em rede, formando as redes industriais. Dentre os tipos de redes existentes, destaca-se o Foundation Fieldbus, que vem sendo cada vez mais usado na indústria, devido a sua padronização, permitindo a interopera-bilidade entre equipamentos, e a sua estrutura modu-lar, que permite o desenvolvimento de diversas fun-cionalidades de acordo com a configuração dos blo-cos funcionais, ou até mesmo com a criação de novos blocos. Essas funcionalidades são baseadas em técni-cas de processamento inteligente de informação, que possuem um vasto potencial de aplicação na área de instrumentação e controle.

A lógica fuzzy tem sido cada vez mais emprega-da em sistemas que utilizam informações provenien-tes de seres humanos para automatizar procedimentos diversos. Esses procedimentos consistem desde me-canismos de tomada de decisão utilizados no merca-do financeiro e sistemas médicos até o controle de processos industriais. Com a utilização da lógica fuzzy, podem ser implementados controladores sim-ples, de baixo custo, de fácil manutenção e que reali-zam operações complexas. O uso desse tipo de con-

trolador é vantajoso principalmente quando o modelo matemático de um processo a ser controlado está sujeito a incertezas.

O objetivo deste trabalho é desenvolver um con-trolador fuzzy utilizando apenas blocos funcionais padrões de uma rede industrial Foundation Fieldbus, para conciliar essa tecnologia ao paradigma das redes industriais.

Em R. C. Uberti et al. (2004), um sistema base-ado em lógica fuzzy foi desenvolvido para sintonizar os parâmetros de um controlador PID instanciado em uma rede Foundation Fieldbus. Porém, nesse caso, o sistema fuzzy executava em um computador, e a sin-tonia era feita através de um servidor OPC. Outros trabalhos desenvolvidos e relacionados ao projeto foram o desenvolvimento de um software em C++ para realizar a comunicação entre o Hysys e a rede Foundation Fieldbus, assim como um programa em LabView com o mesmo propósito; a implementação de controladores PID e neural na rede FF para con-trolar processos em uma planta simulada no Hysys; a implementação de um demultiplexador na rede Foundation Fieldbus para resolver o problema da limitação no número de entradas e saídas das placas de aquisição de dados; e finalmente foi implementado um sistema de detecção de falhas utilizando redes neurais na rede Foundation Fieldbus para detectar falhas nos equipamentos da planta simulada no Hysys.

2 Redes Foundation Fieldbus

A Fieldbus Foundation (F. S. de Lima et al., 2005) é uma organização independente sem fins lucrativos com o propósito de desenvolver e manter um padrão internacional (D. Heffernan et al., 2000) de redes de campo para automação de processos, o Foundation Fieldbus.

A rede Foundation Fieldbus é um sistema de comunicação digital, serial e bidirecional que funcio-na como uma rede local para instrumentos usados em processos e automação industrial, com capacidade para distribuir o controle da aplicação entre os dispo-sitivos, já que os mesmos possuem microprocessado-res e memória com várias funções, como operadores aritméticos e até mesmo controladores PID. Ela tam-bém pode ser interligada a redes Ethernet com o in-tuito de configuração remota dos dispositivos. Uma de suas principais características é a organização da camada de aplicação em blocos, que por ser aberta e completamente especificada permite atingir um dos principais objetivos da fundação, a interoperabilida-de.

Cada bloco funcional pode ser visto como um bloco de software que exerce processamento de si-nais, deixando transparente para o usuário os detalhes internos de implementação. Esse encapsulamento possibilita o desenvolvimento descentralizado e in-dependente de novos blocos funcionais, o que torna simples a tarefa de suprir a rede com novas funciona-lidades. Outra vantagem dessa arquitetura é a possibi-lidade de se interligarem os blocos para que possam ser realizadas funções mais complexas, como o con-trolador fuzzy visto neste trabalho.

3 Controle Fuzzy

Um controlador fuzzy (F. M. U. Araújo, 2004) é um sistema a base de regras, composto de um conjunto de regras de produção do tipo “Se <premissa> Então <ação>” (R. C. Uberti et al., 2004), que definem a-ções de controle com base nas variáveis de estado do sistema. Os valores das variáveis de estado de um sistema são modelados por conjuntos nebulosos e denominados de termos linguísticos (K. M. Passino et al., 1998). Esse tipo de controlador visa descrever numa rotina a experiência humana, intuição e heurís-tica para controlar um processo. Por exemplo, pode-mos ter uma regra com o seguinte formato: “Se <o nível do tanque é muito alto> Então <abrir a válvula ao máximo>”.

Um controlador fuzzy pode ser aplicado em um problema típico de controle direto, que consiste em obter uma lei de controle para que um sistema atinja as especificações desejadas. Para isso, um controla-dor fuzzy precisa possuir em sua estrutura blocos que realizem cálculos de conversão de valores entre do-mínios numéricos e nebulosos.

Os controladores empregando lógica fuzzy (F. M. L. Filho et al., 2002) possuem, de modo geral, três blocos:

Figura 1 - Estrutura típica de um controlador nebuloso

3.1 Conversor para Variáveis Nebulosas (“Fuzzifi-

cador”)

O sinal e(t) é normalmente do tipo numérico. Por outro lado, as regras são expressas em termos da per-tinência ou não destas grandezas a conjuntos nebulo-sos. Assim, é necessário converter e(t) em valores de pertinências para que possa ser realizada a inferência nebulosa. Esse processo é chamado de fuzzificação.

Considere-se que os conjuntos associados a e(t) são A1 = EP (erro pequeno), A2 = EM (erro modera-do) e A3 = EG (erro grande). Da figura abaixo, para os instantes t1, t2 e t3 tem-se:

Figura 2. Valores da função de pertinência para o sinal de erro em diferentes instantes de tempo.

Para e(t1), tem-se, no caso, a partir da Figura an-terior:

( )

=

=∈

72.0

24.0 1

EM

EP

µcomEM

µcomEPte

3.2 Máquina de Inferência Nebulosa (Base de Re-

gras)

A máquina de inferência deve receber as informações sobre e(t) já convertidas em termos associados a va-riáveis linguísticas, especificamente graus de perti-nência a conjuntos nebulosos, e gerar, a partir de uma base de regras fornecidas pelo usuário, uma saída também do tipo linguístico, na forma de funções de pertinência (µU(.)). As pertinências de saída devem ser, posteriormente, convertidas para uma variável numérica u(t), que será o sinal de controle.

Uma forma de se representar o conjunto de re-gras envolvendo apenas uma variável, por exemplo, o erro e(t), é através de tabela do tipo:

e(t)

NG NM Z PM PG

u(t) PG PM Z NM NG

Tabela 1. Apresentação compacta, 5 regras, onde NG = Negativo-Grande, NM = Negativo-Mediano, Z = Quase Zero, PM = Positi-

vo-Moderado e PG = Positivo-Grande

Para ilustrar um mecanismo de inferência, consi-dere-se um caso em que há apenas 2 regras:

Regra 1: Se (e ~ EP) Então (u ~ UP) Regra 2: Se (e ~EG) Então (u ~UG) Onde as funções de pertinência µEP(.), µUP(.),

µEG(.), µUG(.) associadas a Erro-Pequeno, U-Pequeno, Erro-Grande e U-Grande estão ilustrados na Figura 6-7. Para a relação "Se (.) Então (.)" é uti-lizada a regra min de Mamdani e para a relação (Re-gra 1) ou (Regra 2) é utilizada a forma max.

Figura 3. Mecanismo de inferência utilizando o esquema proposto por Mamdani.

3.3 Conversor para Variável Numérica (“Defuzzifi-

cador”)

As regras nebulosas produzem como saída valo-res de pertinência a conjuntos nebulosos. Como, na prática, é necessário um valor bem definido para o sinal de controle, realiza-se uma etapa final chamada de defuzzificação. Esse processo consiste em obter um sinal numérico de controle u(t) a partir dos valo-res das pertinências de saída.

Os processos mais conhecidos de conversão para variáveis numéricas são:

Primeiro Máximo (SOM): Encontra o valor de saída através do ponto em que o grau de pertinência da distribuição da ação de controle atinge o primeiro valor máximo.

Método da Média dos Máximos (MOM): Encon-tra o ponto médio entre os valores que têm o maior grau de pertinência inferido pelas regras.

Método do Centro da Área (COA): O valor de saída é o centro de gravidade da função de distribui-ção de possibilidade da ação de controle.

4 Concepção de um Sistema Fuzzy em Founda-

tion Fieldbus

Para construir o sistema de controle foram exe-cutados alguns passos, descritos a seguir.

4.1 Fuzzificador em Foundation Fieldbus

Para realizar a função de fuzzificação são utilizados blocos funcionais caracterizadores de sinal (blocos CHAR). O bloco Caracterizador de sinal possui duas seções, cada uma com uma saída que é uma função não-linear da entrada respectiva. A função é determi-nada por uma consulta a uma tabela única com as coordenadas x-y de vinte pontos cada. O valor de saída desse bloco é calculado com base na curva formada pela interpolação desses pontos. Assim, se desejarmos que certa entrada esteja relacionada a três conjuntos nebulosos, são necessários três blocos ca-racterizadores para calcular os três valores de perti-nência.

As coordenadas dos blocos caracterizadores pre-cisam ser escolhidas de modo que a interpolação en-tre os vinte pontos forme uma curva o mais próximo possível da curva de pertinência real. Um algoritmo genético desenvolvido em um software matemático foi utilizado para definir vinte pontos para cada curva de pertinência, de forma que o ajuste fosse o melhor possível. A figura 4 é um exemplo de pontos escolhi-dos que garantem uma boa aproximação da curva real. A curva vermelha representa a curva formada pelos pontos, enquanto que a curva azul é a curva real.

Na implementação do algoritmo genético foram utilizadas duas funções de ativação: uma que calcula-va a diferença entre o ponto médio de dois pontos escolhidos e o valor esperado para o respectivo pon-to, a outra função de ativação calculava a integral trapezoidal da curva formada pelos 20 pontos e com-parava com a integral trapezoidal da função esperada.

Figura 4. Gráfico comparando a função ideal e a função com apenas20 pontos.

Uma outra função foi implementada em um software matemático com o objetivo de configurar automaticamente os blocos caracterizadores, definin-do os valores dos seus vinte pontos. Assim, não é necessário modificá-los manualmente, economizando bastante tempo. Para realizar a configuração automá-tica, o programa utiliza as ferramentas disponibiliza-das pelo software para realizar uma conexão OPC com a rede industrial. Desta forma, ao final da exe-cução do algoritmo genético, os pontos escolhidos são instanciados nos blocos funcionais da rede indus-trial.

4.2 Base de Regras em Foundation Fieldbus

A base de regras é constituída de um conjunto de blocos seletores de entrada (blocos ISEL). Esses blo-cos recebem até quatro valores distintos e disponibi-lizam um deles na saída de acordo com um critério de seleção. No sistema desenvolvido, cada bloco ISEL representa uma regra, recebendo como entrada as pertinências calculadas pelos blocos caracterizadores e disponibilizando na saída a pertinência mínima, de acordo com o método de Mamdani. Se duas ou mais regras calculam pertinências de saída relacionadas a um mesmo conjunto nebuloso, um outro bloco ISEL é utilizado para selecionar a maior pertinência, tam-bém de acordo com o método de Mamdani. Assim, o conjunto de blocos ISEL funciona como uma máqui-na de inferência, fornecendo as pertinências de saída necessárias para a desfuzzificação.

4.3 Desfuzzificador em Foundation Fieldbus

Diferentes métodos podem ser utilizados para reali-zar a desfuzzificação. Blocos aritméticos podem ser utilizados para calcular uma média ponderada (J. Jantzen, 1998) das pertinências de saída, como ilustra a figura a seguir, no caso de houverem três pertinên-cias de saída.

Figura 5. Um dos métodos de defuzificação.

Um outro método que pode ser utilizado é o método do primeiro máximo (SOM). Nesse caso, um bloco seletor (ISEL) é usado para selecionar a maior dentre as pertinências de saída. Um bloco caracterizador é então utilizado para gerar o valor desfuzzificado cor-respondente à pertinência de saída escolhida.

5 Resultados Experimentais

Neste trabalho foi desenvolvido um controlador fuzzy implementado com blocos funcionais padrão em ins-trumentos reais de uma rede Foundation Fieldbus, onde tais instrumentos realizavam o controle do nível de um tanque de uma planta debutanizadora simulada no software Hysys, caracterizando assim um ambien-te híbrido (F. S. de Lima et al., 2004), onde a planta simulada tem como objetivo separar os propanos e butanos dos compostos mais pesados utilizando-se de vários controladores. No trabalho realizado foi subs-tituído um controlador PID da simulação, o LIC 102, pelo controlador fuzzy embarcado na rede industrial, onde a variável manipulada para controlar o nível do tanque foi a abertura de uma válvula (VLV-103) li-gada à corrente de saída do tanque. O sistema contro-lado está circulado na figura abaixo.

Figura 6. Esquema da planta simulada.

O controlador possui duas entradas: o erro, ou seja, a diferença entre o nível de referência e o nível atual do tanque, e a variação do erro, ou seja, o erro anterior subtraído do erro atual. Três curvas de perti-nência foram associadas ao erro, representando os conjuntos nebulosos EN (erro negativo), EZ (erro zero) e EP (erro positivo). Duas curvas foram associ-adas à variação do erro, representando os conjuntos nebulosos VN (variação negativa) e VP (variação positiva). Todas as curvas de pertinência são do tipo bell-shape, e foram modeladas com o auxílio de um software matemático.

A porcentagem de abertura da válvula é a única variável de saída do controlador e está associada a quatro curvas de pertinência do tipo impulso, que representam os conjuntos nebulosos AP (abertura pequena), AM (abertura média), AG (abertura gran-de) e AMG (abertura muito grande). Os impulsos estão nos valores 20%, 38.5%, 45% e 70%.

É possível formar seis combinações com as vari-áveis de entrada. Portanto, são necessárias seis regras na base de dados. A tabela abaixo mostra as regras que foram escolhidas para um bom funcionamento do controlador.

EN EZ EP VN AG AM AP VP AMG AM AP

Tabela 2. Base de regras para o controlador

A rede industrial utilizada no laboratório foi con-

figurada de forma a implementar um controlador fuzzy como mostra a figura abaixo.

Figura 7. Esquema do controlador fuzzy na rede FF

O controlador é formado por vários blocos fun-

cionais padrão da rede Foundation Fieldbus, tendo diversas funcionalidades, tais como entrada e saída ou cálculos aritméticos.

Os blocos caracterizadores de 1 a 5 formam a in-terface de fuzzificação, os blocos seletores de 1 a 8 formam a máquina de inferência e os blocos rotula-dos como soma e divisão realizam a desfuzzificação. Os blocos AI recebem correntes elétricas e as conver-tem em valores correspondentes às entradas do con-trolador, enquanto o bloco AO recebe um valor des-

fuzzificado e o converte em uma corrente elétrica que atua no processo simulado.

Para realizar a comunicação entre a planta simu-lada e os instrumentos reais foram utilizadas placas de aquisição de dados. A saída do controlador é en-viada através do bloco funcional AO como um sinal de corrente, que é captado pela placa de aquisição. Em seguida, um programa desenvolvido em LabView realiza um cálculo de conversão para obter o sinal de controle a partir desse sinal de corrente. Nesse caso, o sinal de controle é um valor de porcentagem, que define o valor de abertura da válvula da simulação no Hysys.

Para realizar o caminho inverso, o programa em LabView obtém o valor do nível do tanque controla-do do Hysys, calcula o erro e a variação do erro e usa a placa de aquisição para enviar um sinal de corrente correspondente a esses valores para os blocos funcio-nais AI da rede Foundation Fieldbus. Esses valores são devidamente convertidos para sinais de 4 a 20 mA antes de serem enviados. Uma conversão inversa ocorre nos dispositivos da rede, para que o valor ori-ginal seja obtido.

Durante os testes, a simulação em Hysys é exe-cutada em modo dinâmico e o programa em LabView envia constantemente os valores do erro e da varia-ção do erro para a rede industrial. O erro assume va-lores entre 100 e -100, enquanto que a variação do erro assume valores entre –1.5 e 1.5. O controlador fuzzy na rede industrial, por sua vez, gera um sinal de controle com valores entre 0 e 100%, correspondente à abertura de uma válvula da simulação. Os gráficos abaixo ilustram o desempenho do controlador para níveis de referência de 40 e 80%.

Figura 8. Gráfico do nível do tanque para setpoint de 40 %

Figura 9. Gráfico do nível do tanque para setpoint de 80 %

Observa-se que o controlador obteve um bom desempenho para ambos os níveis de referência, com baixo overshoot e erro de regime aproximadamente nulo.

Para regular o desempenho do controlador, vá-rios aspectos podem ser observados. Uma alternativa é regular as curvas de pertinência de entrada e saída. O método de desfuzzificação utilizado também pode ser alterado. Outro aspecto a ser considerado é a quantidade de regras. Um aumento nessa quantidade pode contribuir beneficamente para o desempenho do controlador. Para isso, devem ser criadas novas cur-vas de pertinência para as variáveis de entrada do sistema.

5 Conclusões

Novos algoritmos inteligentes estão sendo desenvol-vidos para redes industriais Foundation Fieldbus. Estes algoritmos consistem de técnicas para medição indireta de variáveis de processo, detecção de falhas e degradação em sistemas de medição e implementa-ção distribuída de estratégias de controle de proces-sos, via concepção e implementação de sensores de software. Em particular, este trabalho mostrou a via-bilidade da implementação de sistemas fuzzy usando apenas blocos funcionais padrões Foundation Field-bus.

A instanciação de algoritmos inteligentes, como controladores fuzzy, diretamente na rede industrial elimina os gastos adicionais com equipamentos dedi-cados e permite a interoperabilidade entre fabrican-tes, já que são utilizados apenas blocos funcionais padrões. Além disso, um mesmo dispositivo pode ser reconfigurado a qualquer momento para assumir no-vas funcionalidades. Porém, antes de serem efetiva-mente utilizados na indústria, esses algoritmos preci-sam ser testados e validados.

Agradecimentos

Os autores gostariam de agradecer à UFRN pela es-trutura fornecida, à ANP que através do PRH-14 a-

poiou a realização deste projeto, bem como à Petro-brás, à Redic e à Finep pelos recursos disponibiliza-dos para o projeto.

Referências Bibliográficas

F. S. de Lima, D. R. C. Silva, L. A. Guedes, A. D. D. Neto, J. D. Melo (2005). Controle Inteligente para um Tanque Não-linear de 1ª Ordem

Através de Redes Industriais Foundation

Fieldbus Utilizando Blocos Funcionais Padrão. VII Simpósio Brasileiro de Automação Inteligente.

F. S. de Lima, L. A. Guedes, A. L. Maitelli, A. O.

Salazar (2004). Implementação de Controle Avançado em Redes Foundation Fieldbus

Utilizando Blocos Funcionais Padrões. ISA – Sociedade de Instrumentação, Sistemas e Automação, 4º Congresso Internacional de Automação, Sistemas e Instrumentação.

F. M. U. Araújo (2004). Controle Inteligente. Notas

de Aula, UFRN. J. Jantzen (1998). Design Of Fuzzy Controllers.

Technical University of Denmark. F. M. L. Filho, H. L. Gosmann, A. Bauchspiess

(2002). Controle Fuzzy para Sistema de Nível de Líquidos. XIV – Congresso Brasileiro de Automática

F. S. de Lima, L. A. Guedes, A. L. Maitelli, A. O.

Salazar (2004). Hybrid Environment for Tests and Training in Fieldbuses. Anais da VI Conferência Internacional de Aolicações Industriais - Induscon., pp. 1-6, Joinville-SC.

R. C. Uberti, R. C. Santos, A. Plucenio (2004).

Controle Adaptativo Utilizando Múltiplos

Modelos em uma Rede Fieldbus - 2 Congresso Brasileiro de P & D em Petróleo e Gás, 2004, Rio de Janeiro.

K. M. Passino, S. Yurkovich (1998). Fuzzy Control D. Heffernan, D.P. Burton (2000). Proposal for a

Fieldbus Standard to Support EuropeanPower

Line Communications – ISPLC2OOO University of Limerick

EXTRACAO AUTOMATICA DE AUTOMATOS TEMPORIZADOS A PARTIR DEDIAGRAMAS LADDER

Kezia de Vasconcelos Oliveira∗, Kyller Gorgonio∗, Angelo Perkusich∗, Antonio MarcusNogueira Lima∗, Leandro Dias da Silva†

∗Universidade Federal de Campina GrandeCentro de Engenharia Eletrica e Informatica

Laboratorio de Sistemas Embarcados e Computacao PervasivaCampina Grande, Paraıba, Brazil†Universidade Federal de Alagoas

Instituto de ComputacaoMaceio, Alagoas, Brasil

Emails: kezia@dsc.ufcg.edu.br, {kyller, perkusic, amnlima, leandro}@dee.ufcg.edu.br

Abstract— Control systems are used to produce a certain result with minimal or none human supervision.The principal aim of such systems is to ensure that resources are used efficiently and that the desired productquality be achieved. Moreover, for critical systems such as oil and gas plants, it is important to guaranteethe safety and reliability of the operation. Therefore, it is necessary to verify, through use of techniques forverification, whether what is running in the device is in accordance with what was defined in the specificationdocuments. The goal of this work is to present a method that automatically generates the timed automata modelfrom Ladder programs for model-based analysis, in order to increase the confidence in the behavior of criticalcontrol systems.

Keywords— Control Systems, Ladder, Timed Automata.

Resumo— Sistemas de Controle sao sistemas utilizados para produzir um certo resultado com pouca ounenhuma supervisao humana. O principal objetivo destes sistemas e assegurar que os recursos serao utilizadosde forma eficiente e que a qualidade desejada do produto seja alcancada. Alem disto, para sistemas crıticos comoplantas de producao de petroleo e gas e importante garantir a seguranca e a confianca na operacao. Portanto,e necessario verificar, atraves do uso de tecnicas de verificacao, se o que esta executando no dispositivo esta emconformidade com o que foi definido nos documentos de especificacao. O objetivo deste trabalho e apresentar ummetodo que gere automaticamente automatos temporizados a partir de programas Ladder para realizar analisebaseada em modelos com o intuito de aumentar a seguranca e a confianca no funcionamento de sistemas crıticosde controle.

Keywords— Sistemas de Controle, Ladder, Automatos Temporizados.

1 Introduction

A inclusao de novas tecnologias aumentou o nıvelde complexidade dos sistemas de automacao daindustria moderna, trazendo consigo diversos de-safios, tais como o de garantir a confiabilidadede processos e a seguranca tanto de equipamen-tos e instalacoes como de funcionarios (Neveset al., 2007). Os requisitos de confiabilidade e se-guranca ficam mais evidentes em sistemas crıticoscomo plantas de producao de petroleo e gas.

Com o objetivo de superar os desafios men-cionados acima, cada vez mais tecnicas de verifi-cacao estao sendo utilizadas em sistemas de con-trole. Sistemas de controle sao dispositivos combi-nados que gerenciam o comportamento de outrosdispositivos com pouca ou nenhuma supervisaohumana (Capelli, 2006).

Sistemas de controle sao amplamente utiliza-dos nas industrias modernas. Na Figura 1, oprocesso de desenvolvimento adotado para umsistema de controle da compainha Petrobras eilustrado. Primeiramente, a companhia gera umconjunto de requisitos que constitui a especifi-cacao. Uma vez que a especificacao esta com-

pleta, ou seja, esta no formato de diagramas delogica ISA 5.2 (ISA, 1992), o software e desen-volvido segundo uma das linguagens definidas nopadrao IEC 61131-3 (Parr, 2003). Finalmente, oprograma e compilado e executado em um Con-trolador Logico Programavel (CLP) (Parr, 2003).Diante deste cenario podemos observar que a com-panhia nao tem como garantir formalmente que aimplementacao final corresponde a especificacaooriginal.

Especificação ( ISA 5.2)

IEC 61131- 3 CLP ( Código )

Figura 1: Processo de desenvolvimento do sistemade controle

Diante deste contexto, e fundamental verificarse o que e executado no dispositivo esta em con-formidade com o que foi definido nos documentosde especificacao. Uma possibilidade para alcancaristo e realizar analise baseada em modelos. Variastecnicas podem ser usadas para validar a imple-mentacao atraves da especificacao como, por ex-

emplo, simulacao automatica, testes de conformi-dade e verificacao automatica de modelos.

O objetivo deste trabalho e introduzir ummetodo que aumente a confianca e a segurancano funcionamento de sistemas crıticos de controle.Para tanto, automatos temporizados sao geradosa partir da especificacao, Diagramas ISA 5.2, e daimplementacao, Diagramas Ladder. Apos a gera-cao destes automatos, tecnicas de analise citadasanteriormente podem ser aplicadas nos modeloscom a finalidade de validar a corretude do sis-tema. O foco deste trabalho consiste na geracaode modelos de automatos temporizados a partirde programas Ladder.

O restante deste trabalho esta organizado daseguinte forma, Na Secao 2 trabalhos relacionadossao discutidos. Na Secao 3 uma introducao aosCLPs e as possıveis linguagens de programacaopara tais dispositivos sao apresentadas, com en-fase na linguagem Ladder, foco deste trabalho. NaSecao 4 a sintaxe e a sementica de automatos tem-porizados e introduzida. Na Secao 5 um estudode caso e relato e por fim, na Secao 6 sao feitas asconsideracoes finais.

2 Trabalhos Relacionados

Esta secao descreve os principais trabalhos realiza-dos no domınio de verificacao de sistemas de con-trole. Em (Bender et al., 2008), uma metodolo-gia dirigida por modelos e apresentada. Nestametodologia, programas escritos em diagramasLadder (LD) sao modelados e confrontados commetamodelos LD. Estes metamodelos sao tran-formados em redes de Petri que e o formato deentrada da ferramenta Tina, onde esta entradae simulada e verificada usando propriedades re-presentadas em formulas LTL (Linear TemporalLogic).

Em (Rossi and Schnoebelen, 2000) e ilustradocomo programas escritos em Ladder podem sertransformados em estruturas de Kripke, que porsua vez servirao de entrada para o verificador Sim-bolic Model Checking. Em (Canet et al., 2000) emostrado como o comportamento de um programaescrito em IL e transformado em uma estrutura deKripke e, como a verificacao de propriedades, se-gundo a logica temporal LTL podem ser analisada.

Com relacao a automatos temporizados,em (Mader and Wupper, 1999), uma metodolo-gia com enfase em temporizadores, baseada nacriacao de dois modelos de automatos temporiza-dos para aplicacoes para CLPs escritos em IL eapresentada. Em (Zoubek et al., 2003), com ointuito de minimizar a explosao de estados cau-sada pela completa construcao do modelo do pro-grama, o autor propoe um novo modelo que fixaa propriedade e a ser verificada e identifica qualparte do programa e afetada por ela, para que ape-nas essa parte do programa seja transformada emmodelo. Este modelo consiste em um automato

temporizado que servira de entrada para o verifi-cador de modelos Uppaal, onde propriedades es-critas em logica temporal CTL (Computation TreeLogic) sao utilizadas. Em (Wang et al., 2007),sistemas embarcados, como CLPs, sao modeladoscomo automatos temporizados. Estes modelos saosincronizados por passagens de sinais atraves decanais. Seguranca e requisitos com restricoes tem-porais sao validados pela ferramenta Uppaal como uso da logica temporal CTL.

O diferencial do metodo proposto neste tra-balho para os discutidos acima e que ele se propoea aumentar a confianca e a seguranca de progra-mas para CLPs, utilizando testes de conformi-dade ao inves de verificacao automatica de mod-elos ou prova de teoremas como tecnica de verifi-cacao. Pois, um sistema usual pode ter mais demil variaveis, tornando o uso destas tecnicas im-praticaveis, causando o problema conhecido comoexplosao do espaco de estados. Alem disso, enecessario lidar com o tempo de uma forma quan-titativa. Neste trabalho, elementos temporais dalinguagem Ladder sao explicitamente modelados eanalisados em conjunto com a logica Ladder paraum programa completo. Em um trabalho ante-rior, os algoritmos para extracao automatica deautomatos temporizados a partir de Diagramasde Blocos Funcionais (Function Block Diagrams- FBD) (da Silva et al., 2008) foi definido. O focodeste trabalho consiste em extrair, de forma au-tomatica, automatos temporizados a partir de dia-gramas Ladder.

3 Controladores Logico Programaveis ePadrao IEC 61131-3

Controladores logicos programaveis (PLCs) saocomputadores utilizados para executar controle deprocesso. Eles sao amplamente utilizadas em in-dustrias como a manufatura, oleo e gas e quımica.

Programas para CLPs podem ser escritos emuma das cinco linguagens definidas pelo padraoIEC 61131-3 e sao executadas em ciclos compostosde tres etapas, descritas a seguir detalhadamente.Primeiramente, as entradas do sistema sao lidas eos seus valores armazenados na memoria. Depoisdisso, o programa e executado usando os valoresde entrada armazenados, e todos os valores de saı-das computados tambem sao armazenados. Na ul-tima etapa, todas as saıdas sao ativadas com baseem seus valores armazenados na memoria. Estastres etapas compoem o ciclo de varredura de umCLP.

As cinco linguagens de programacao definidapelo padrao IEC 61131-3 sao: Instruction List(IL), Ladder Diagram (Ladder), Structured Text(ST), Function Block Diagram (FBD) e Sequen-tial Function Chart (SFC). O foco deste trabalhoe na linguagem Ladder. Na Tabela 1, os elemen-tos da linguagem Ladder utilizados neste trabalhosao exibidos.

Tabela 1: Elementos da linguagem LadderSımbolo Descricao

InputName Contato Normalmente Aberto:representa uma entrada da logicade controle. O CLP examina o bitespecifico correspondente a estesımbolo e retorna 0 se a o bit e 0 eretorna 1 se o bit e 1.

InputName Contato Normalmente Fechado:representa uma entrada da logicade controle. O CLP examina obit especifico correspondente a estesımbolo e retorna 1 se a o bit e 0 eretorna 0 se o bit e 1.

( ) OutputName

Bobina: representa uma saıda. Eum elemento atuador, o qual eacionado ou desligado pela logicade controle.

TON

IN

PT Q

Temporizador TON ou TMR: rep-resenta um elemento temporizado.Energiza a saıda (Q = 1) depoisde um perıodo de tempo (tempo =PT) quando exite logica 1 na en-trada (IN = 1).

Na Figura 2, um exemplo de um programaLadder e ilustrado. A leitura de um programaLadder e feita da esquerda para direita e decima para baixo. O diagrama lembra uma es-cada (do ingles Ladder), daı a origem do nomeda linguagem e cada linha um degrau (rung). Asvariaveis input1 e input2 sao chamadas de con-tatos normalmente abertos e a variavel output echamada de bobina. As variaveis input1 e input2sao conectadas em paralelo (operacao BooleanaOR). Como existe um temporizador no degrau en-tao, o valor logico de output depende da saıda dotemporizador TON. Portanto, se a operacao logicade entrada do temporizador e verdadeira, input1or input2 = 1, entao o temporizador inicia suaoperacao de contagem; quando este tempo chegarem 20s (valor de PT) output e ativada (valor logico1); caso a operacao logica de entrada seja falsa,input1 or input2 = 0, entao output e desativada(valor logico 0).

( )

input1

input2

output TON

IN Q 20s

Figura 2: Exemplo de um rung de um programaLadder

4 Automatos Temporizados

Automatos temporizados sao maquinas de esta-dos finitos com restricoes de temporizacao asso-ciadas a suas arestas e estados, e tem o objetivo demodelar o comportamento de sistemas de temporeal (Bengtsson and Yi, 2004). As restricoes saoconstruıdas a partir de variaveis de controle detempo, chamadas de relogios. Estes relogios pro-

gridem de forma sıncrona e sao declarados comovalores reais, pois o tempo considerado e contınuo.

Na Figura 3, uma pequena introducao da sin-taxe e semantica dos automatos temporizados naferramenta Uppaal e ilustrada. Nessa Figura, amodelagem de uma torneira como um automatotemporizado e apresenada. Esta torneira pos-sui um acionamento automatico do fluxo de aguaquando as maos a pressionam. O automato pos-sui duas localidades: off, torneira desligada, eon, torneira ligada. As expressoes proximas aosarcos representam guardas, e expressoes do tipoc = 0 representam atualizacao de variaveis. Seo usuario pressionar a torneira (hands == 1),entao o clock, representado por c e inicializado,c = 0, e a torneira e ligada, ou seja, a tran-sicao que leva a localidade off para a localidadeon e disparada. Nesta localidade, podem ocorrerduas situacoes: o usuario pode continuar pressio-nando a torneira (hands == 1), para que ela per-maneca ligada; ou o usuario para de pressionara torneira e quando dois segundos se passarem(hands == 0 && c >= 2) a torneira sera desli-gada, ou seja, a transicao que leva a localidade onpara a localidade off e disparada.

Um automato temporizado e uma tupla L,(l0,C, A, E, I), onde: L e o conjunto de locali-dades; l0 ∈ L e a localidade inicial; C e o conjuntode relogios; A e o conjunto de acoes, co-acoes eacoes internas; E e o conjunto de arestas entre lo-calidades, com acoes, guardas e um conjunto derelogios que serao restaurados, onde E ⊆ L x A xB(C) x 2c x L. B(C) e o conjunto de conjuncoessobre condicoes simples da forma x ./ c ou x-y ./c, onde x, y ∈ C, c ∈ ℵ e ./ ∈ {<, ≤, =, ≥, > };I atribui invariantes as localidades (define o inter-valo de tempo que o sistema pode permanecer emum estado), onde I: L → B(C).

hands == 1 c = 0

hands == 1

hands == 0 && c >= 2

(a) Torneira

hands == 1

hands == 0

(b) Usuario

Figura 3: Funcionamento de uma torneira

5 Estudo de Caso

Para ilustrar o metodo, foi utilizado um exem-plo introduzido em (Parr, 2003), pagina 66. NaFigura 4 e ilustrado um programa Ladder que con-trola a partida de um motor o qual e acionandoe parado com o auxılio dos repectivos botoesStartPB e StopPB. Para que a partida do motorseja realizada um contato auxiliar, denominadode StarterAux, deve esta energizado. Se um errofor cometido, devido a ocorrencia de uma sobre-carga, ou devido uma parada de emergencia ser

pressionada, ou se houver uma falha no abasteci-mento, o sinal do contato auxiliar sera perdido.Este contato nao pode ser verificado ate 1 segundoapos o Starter ter sido energizado, para dar tempopara o contato dar partida. AcceptPB representao acionamento manual de um alarme caso algumproblema aconteca.

Starter

Fault

TON

IN Q 1s

( ) StartPB StopPB

Starter

Starter Fault

StarterAux AcceptPB

( ) Fault

Figura 4: Partida de um motor

Nas Figuras 5, 6, 7, 8 e 9 a modelagem do pro-grama Ladder que controla a partida de um motorcomo uma rede automatos temporizados, segundoo modelo sintatico e semantico da ferramenta Up-paal, e apresentado.

Nas Figuras 5(a), 5(b), 5(c) e 5(d) sao apre-sentadas as modelagens das variaveis de entrada.Cada variavel de entrada e modelada como umautomato de um unico estado com duas tran-sicoes, onde os valores booleanos 0 ou 1 podemser definidos para as variaveis atraves da utilizacaodos canais de sincronizacao reset e set, respecti-vamante. A variavel booleana numEntradaASer-Lida, utilizada como guarda, determina qual vari-avel de entrada esta sendo atualizada. Quando aultima variavel de entrada e atualizada o valor denumEntradaASerLida e inicializado para 1, paraque desta forma, no proximo ciclo de varredura, aatualizacao das variaveis possa ocorrer novamantede forma sequencial. Um fato importante a sermencionado e que variaveis de feedback, ou seja,variaveis que sao utilizadas para armazenar umvalor em um ciclo e lida como uma entrada paraa mesma rede no proximo ciclo, nao sao mode-ladas como automatos temporizados, pois estasservem para armazenar valores decorrentes de al-guma logica de controle de um programa.

Na Figura 6(a) a modelagem utilizada pararealizar a atualizacao, de forma sequencial, dasvariaveis de entrada pode ser visualizada. O auto-mato ilustrado em tal Figura e responsavel porenviar mensagens set! ou reset!, para cada auto-mato que representa uma variavel de entrada, in-formando o valor que deve ser atribuıdo a estavariavel e, para o automato que processa os sinaisde entrada, fazendo com que o valor da variavelnumEntradaASerLida seja incrementado. Esteincremento e realizado pelo automato ilustradona Figura 6(b). Apos todos os valores das vari-aveis de entrada serem atualizados, id == nu-

mEntradas, este automato envia uma mensagemstarter! ao automato que representa o ciclo deexecucao do programa, informando que a exe-cucao da logica do programa pode ser inicializada.O canal update e utilizado para sincronizar esteautomato com o automato que representa o ci-clo de varredura, indicando que um novo ciclode varredura pode ser inicializado e, consequente-mente, uma nova atualizacao de variaveis pode serfeita.

set ? numEntradaASerLida == 1

StartPB = 1

reset ? numEntradaASerLida == 1

StartPB = 0

(a) Entrada StartPB

set ? numEntradaASerLida == 2

StopPB = 1

reset ? numEntradaASerLida == 2

StopPB = 0

(b) Entrada StopPB

set ? numEntradaASerLida == 3

StarterAux = 1

reset ? numEntradaASerLida == 3

StarterAux = 0

(c) Entrada StarterAux

set ? numEntradaASerLida == 4

AcceptPB = 1, numEntradaASerLida = 1

reset ? numEntradaASerLida == 4

AcceptPB = 0, numEntradaASerLida = 1

(d) Entrada AcceptPB

Figura 5: Variaveis de Entrada

set! id < numEntradas

id++

reset! id < numEntradas

id++

start! i d = numEntradas

id = 0

update?

C

(a) Atualização de Variáveis

set ? numEntradaASerLida < numEntradas

numEntradaASerLida ++

reset ? numEntradaASerLida < numEntradas

numEntradaASerLida ++

(b) Processa Sinais Entrada

Figura 6: Processo de atualizacao das variaveis deentrada

Na Figura 7 a modelagem do funciona-mento de um temporizador TON, chamado deTEMPO01 e mostrada. A variavel control1 e ocanal de sincronizacao sync1 fazem a sincroniza-cao deste automato com o automato que re-presenta o ciclo de execucao do programa Lad-der. A funcao inputTimer() corresponde aoconjunto de operacoes logicas que representama entrada (IN) do temporizador. A variavelout TEMPO01 corresponde ao valor logico da

saıda (Q) do temporizador. A variavel numCiclos= PT/tempoVarredura determina a quantidade deciclos necessarias para o temporizador executar.O canal end faz com que cada ciclo de execucaodo temporizador termine.

end? control1 = 0

sync1 ? inputTimer () == 1

numCiclos = PT/ tScan , control1 = 0

sync1 ? inputTimer () == 1 && numCiclos == 0

out_ TEMPO01 = 1, control1 = 1

sync1 ? inputTimer () == 1 && numCiclos > 0 numCiclos - -, control1 = 1

sync1 ? inputTimer () == 1

sync1 ? inputTimer () == 0 numCiclos = 0

sync1 ? inputTimer () == 0

out_ TEMPO01 = 0, control1 = 0

L1 L2 L3

L4 L5

sync1 ? inputTimer () == 0

Figura 7: Modelagem de um temporizador TON

Na Figura 8 a modelagem do ciclo de exe-cucao de um programa Ladder como um auto-mato temporizado e exibida. A ideia utilizadana modelagem consiste em executar degraus se-quencialmente atraves do disparo de transicoesentre localidades distintas que possuam a men-sagem execute?. Esta mensagem e enviada peloautomato que representa o ciclo de varredura eserve para indicar que a logica de controle do de-grau foi executada. A primeira logica de con-trole e executada atraves da funcao value Starter.Esta funcao representa um modelo para criacaode funcoes cuja logica de controle nao contem ele-mentos temporizados, ou seja, esta funcao tem oobjetivo de processar o valor da logica de cont-role referente ao degrau que ela representa. As-sim, a funcao value Starter realiza a operacao lo-gica Starter = ((StartPB or Starter) and (StopPBand !Fault)). A variavel executou e uma var-iavel de controle que tem o objetivo de verificarse todos os degraus do programa Ladder foramexecutados. Apos este passo, o segundo degraue executado onde inicialmente a funcao checaEx-ecucaoTEMPO01() verifica se o modelo que re-presenta o temporizador TON pode ser executadoou nao. Se o temporizador estiver apto a exe-cutar, entao o modelo que representa a execucaodo programa Ladder ira sincronizar com o modeloque representa a execucao do temporizador TON,atraves do canal de sincronizacao sync1. A funcaochecaExecucaoTEMPO01() verifica se o valor dalogica de controle que forma a entrada do tem-porizador e 1, (Starter == 1 && control1 ==0 && out TEMPO01 == 0), ou se o tempo-rizador ja executou e sua entrada passou a serfalsa, ((control1 == 0 && out TEMPO01 ==1 && Starter == 0) || (Starter ==0 && control1 == 0 && numCiclos1 > 0)). Afuncao atualizaSaidaTEMPO01() e utilizada paradesincronizar o modelo do temporizador TON

e o modelo de execucao do programa Ladder,para que o proximo degrau seja executado oupara que o programa Ladder termine sua exe-cucao. Esta funcao verifica se o temporizadorexecutou ((control1 == 1 && Starter ==1) || (Starter == 1 && out TEMPO01 ==1)) ou nao (Starter == 0 && control1 ==0 && out TEMPO01 == 0 && numCiclos1 ==0). Apos a execucao desta funcao, o valor deFault e modificado pela funcao outTEMPO01()que e representada pela seguinte operacao logicaFault = (((out TEMPO01 and !StarterAux) or!AcceptPB) and Fault). A funcao atualizaVari-aveisDeControle() e responsavel por atualizar ovalor de executou para 1 e restaurar o valor davariavel control1 para 0. Quando todos os degrausforem executados uma mensagem end! e enviadaao modelo que representa o temporizador TONinformando que sua execucao nao podem mais serrealizada neste ciclo de varredura.

execute? value_Starter() executou = 0

C update?

end! atualizaVariaveisDeControle ()

sync1 ! checaExecucaoTEMPO01 ()

execute? atualizaSaidaTEMPO01 () outTEMPO01 ()

Figura 8: Ciclo de execucao do programa Ladder

Na Figura 9 e ilustrado o ciclo de varredurade um CLP. Sua modelagem obedece a execucaodas tres etapas que compoem o ciclo de varredura:leitura de variaveis, execucao do programa e atu-alizacao das saıdas. O funcionamento deste auto-mato ocorre da seguinte forma: apos as atual-izacoes das variaveis de entrada serem feitas, oautomato que representa o processo de atualiza-cao das variaveis envia uma mensagem start! aoautomato do ciclo de varredura informando que aexecucao do programa pode ser inicializada. En-tao, a transicao que leva a localidade L1 a local-idade L2 e disparada e o valor da variavel num-RungsExecutados e inicializada. Esta variavel tema finalidade de indicar o total de degraus execu-tados. A segunda etapa do ciclo de varedura eexecutada atraves do envio da mensagem execute!por este automato ao automato que representao ciclo de execucao do programa. Ao passo quecada degrau e executado o valor da variavel num-RungsExecutados e incrementado. Esta etapa deprocessamento nao deve ultrapassar o tempo devarredura (time <= tScan). Este tempo contem-pla a execucao interna necessaria para que cada

degrau do programa seja executado. Quando to-dos os degraus forem executados e o tempo devarredura for atigindo entao os valores das saı-das sao liberadas, o valor de timer e restaurado eum novo ciclo de varredura pode ser realizado. Afuncao checaFimDoCicloVarredura() avalia se to-dos os degraus foram executados (executed == 1 )e, se o temporizador nao esta mais sendo execu-tado (control1 == 0 ).

start ? numRungsExecutados = 0

L1

update! checaFimDoCicloVarredura ()

&& time == tScan time = 0

time <= tScan

execute! numRungsExecutados < numTotalRungs numRungsExecutados ++

L2

C

Figura 9: Ciclo de Varredura

6 Conclusoes e Trabalhos Futuros

Neste trabalho e introduzido um metodo para aextracao automatica de automatos temporizadosa partir de programas Ladder para sistemas decontrole. A principal contribuicao deste trabalhoe fornecer um metodo para aumentar a segurancae a confianca de programas de controle. O metodoproposto e aplicado para gerar automaticamenteautomatos temporizados a partir de documentosde especificacao, Diagramas de Logica ISA 5.2,e implementacao, linguagem Ladder. Portanto,erros na implementacao sao detectados e corrigi-dos antes que o codigo seja enviado para o CLP,obtendo assim um melhor controle da qualidadedo software. Alem disso, a metodologia propostaoculta a complexidade de construcao dos modelose minimiza a interacao entre engenheiros e desen-volvedores.

Agradecimentos

Os autores gostariam de agradecer o apoio finan-ceiro do Conselho Nacional de Pesquisa e Desen-volvimento (CNPq) e Petrobras, que tornou pos-sıvel o desenvolvimento deste trabalho.

Referencias

Bender, D. F., Combemale, B., Cregut1, X.,Farines, J. M., Berthomieu, B. and Verna-dat, F. (2008). Ladder metamodeling andplc program validation through time petrinets, ECMDA-FA ’08: Proceedings of the 4thEuropean conference on Model Driven Archi-tecture, Springer-Verlag, Berlin, Heidelberg,pp. 121–136.

Bengtsson, J. and Yi, W. (2004). Timed au-tomata: Semantics, algorithms and tools,Lectures on Concurrency and Petri Nets1633: 8–22.

Canet, G., Couffin, S., Lesage, J.-J., Petit, A. andSchnoebelen, Ph. (2000). Towards the auto-matic verification of PLC programs writtenin Instruction List, Proceedings of the IEEEInternational Conference on Systems, Manand Cybernetics (SMC 2000), Argos Press,Nashville, Tennessee, USA, pp. 2449–2454.

Capelli, A. (2006). Automacao Industial: controledo movimento e processos contınuos, Erica.

da Silva, L. D., de Assis Barbosa, L. P., Gorgonio,K., Perkusich, A. and Lima, A. M. N. (2008).On the automatic generation of timed au-tomata models from function block diagramsfor safety instrumented systems, 34th AnnualConference of the IEEE Industrial Electron-ics Society (IECON 2008), IEEE IndustrialElectronics Society, Orlando, USA, pp. 291–296.

ISA (1992). Binary Logic Diagrams for ProcessOperations, ISA 5.2-1976 (R1992) edn, ISA -The Instrumentation, Systems, and Automa-tion Society.

Mader, A. and Wupper, H. (1999). Timed au-tomaton models for simple programmablelogic controllers, Proceedings of EuromicroConference on Real-Time Systems, York,UK.

Neves, C., Duarte, L., Viana, N. and Ferreira,V. (2007). Os dez maiores desafios da au-tomacao industrial: as perspectivas para o fu-turo, II Congresso de Pesquisa e Inovacao daRede Norte Nordeste de Educacao Tecnolog-ica, Joao Pessoa, Paraıba, Brasil .

Parr, E. A. (2003). Programmable Controllers Anengineer´s guide, 3nd edn, Newnes.

Rossi, O. and Schnoebelen, Ph. (2000). For-mal modeling of timed function blocks forthe automatic verification of Ladder Diagramprograms, Proceedings of the 4th Interna-tional Conference on Automation of MixedProcesses: Hybrid Dynamic Systems (ADPM2000), Shaker Verlag, Dortmund, Germany,pp. 177–182.

Wang, R., Song, X. and Gu, M. (2007). Mod-elling and verification of program logic con-trollers using timed automata, Software, IET1(4): 127–131.

Zoubek, B., Roussel, J.-M. and Kwiatowska, M.(2003). Towards automatic verification ofladder logic programs, IMACS Multiconfer-ence on Computational Engineering in Sys-tems Applications (CESA) .

IMPLEMENTATION OF PID AUTO-TUNING CONTROLLER USING FPGA AND NIOS II

PROCESSOR

RAPHAEL C. GOMEZ, EDSON A. BATISTA, LUIS HENRIQUE G. CORBELINO, CRISTIANO Q. ANDREA, ALEXANDRE

C. R. DA SILVA, MARCO H. NAKA. ALEXSANDRO M. CARNEIRO.

Laboratory of Control and Automation, Department of Engineering, Dom Bosco Catholic University Av. Tamandaré 6000, 79117-900 Campo Grande, MS, Brazil

E-mails: raphaelceni@gmail.com,edson.ucdb@gmail.com,luis.corbelino@gmail.com, cristiano@batlab.ufms.br, acrsilva@gmail.com, marco.h.naka@gmail.com,

alexsandro.ucdb@gmail.com

Abstract FPGAs devices are becoming faster and cheaper every day. Its fast implementation has been increasing its popular-ity, and modern control studies can be beneficed with its advantages. In this paper is presented a project of an auto tuning PID implemented in FPGA with a NIOS II processor, using Relay Feedback and Ziegler-Nichols methods.

Keywords PID, FPGA, Ziegler-Nichols, Relay Feedback, Auto Tuning.

1 Introduction

Developing more complex and higher precise control systems, reducing time in manufacturing and the improvement of quality have always been the main focus in technological researches

From this point of view, the analysis of closed-loop control systems is essential, because it is possi-ble to design controllers based on the plant’s behav-ior in order to obtain a desired output. The PID con-troller is used to solve that problem. It is well ac-cepted because of its easy implementation and for providing control of different kinds of processes.

PID works with a mechanism of control with a feedback, extensively used in industrial applications in order to minimize the error or eliminate it in sec-ond order systems. Another advantage is the fact that it increases the system’s performance. Nowadays, more than 90% of feedback systems use PID or PI controllers, which can be found at any area where controllers are used (Aström and Hägglund, 2001). Some examples of PID’s applications are: control of robotic arms in automotive industries, temperature control in petrochemical industries, or even pressure control in a production line.

As a result, a great variety of tuning methods has been developed for these controllers. The classic approach of Ziegler-Nichols method with the Relay-Feedback method makes possible to implement an auto-tuning PID controller. Other methods for tuning a PID controller are: Fuzzy, Root Locus, CHR (Chien, Hrones and Resqick, 1952), Cohen-Coon (Cohen and Coon, 1953), Visioli (Visioli, 2001), Ya-Gang (Wang and Cai, 2002) and also the IMC (In-ternal Model Control) method.

The auto-tuning is expected to identify the out-put of the system and automatically find the parame-ters of the controller. The Ziegler-Nichols method is practical and direct while the Relay-Feedback me-thod is utilized to obtain the data that will be used for

the Ziegler-Nichols tuning. It is expected that the results will be more accurate with the combination of both methods.

About the equipments, the PLCs (Programmable Logic Controller) are the most common hardware used as a controller in industry. These devices were developed around 1960 with the aim to replace re-lays in logic control. The PLCs have a closed archi-tecture and the programming is carried out using the language ladder or relay diagrams. Another attractive option to satisfy the needs of industrial control and automation are the programmable logic devices.

The programmable logic devices were devel-oped more than a decade ago and, nowadays, are used in several areas such as, telecommunication, instrumentation and in control. In comparison to an analogical controller, it has some advantages that are essential to obtain the desired result, as better noise immunity owing to its discrete signal (Ruschel 1996), it is easily integrated with other digital sys-tems and it makes possible the implementation of more sophisticated control methods.

The FPGA (Field Programmable Gate Arrays) is a reconfigurable logic device that provides mainly practicality and portability, with low consumption of energy, high speedy of operation and large capacity of data storage.

The FPGA, contrary to TTL technology inte-grated circuits that have a fixed logic, allows the designer to make future modifications. The recon-figurable logic devices are synthesized by means of hardware description. This description can be devel-oped with a standard language, for example, VHDL (VHSIC – Hardware Description Language).

In this paper, it is described the development of the Relay-Feedback and Ziegler-Nichols methods for the PID auto-tuning synthesized in a FPGA from Cyclone family of (Altera) with NIOS II processor.

This paper has the objective to make it easier and faster to develop automation systems using FPGA by developing a template that can be easily

configured for future implementations. This template can be used in systems that already have FPGA de-vices or in future projects that need controllers, where the developer designs the application and uses the PÍD auto-tuning template for the controller.

The paper is organized by the following topics: In section 2 is presented the techniques of auto-tuning for PID, utilizing the Ziegler-Nichols and Relay-Feedback methods. Section 3 shows the con-trol algorithm used in the NIOS II processor and the development of the hardware used to test the tech-nique proposed. Finally, simulations of the con-trolled system in MATLAB and SIMULINK, and the results obtained are presented in section 4.

2 Auto-Tuning PID

The PID is the sum of the proportional, integral and derivative controllers. Considering second order sys-tems, the Proportional (P) controller reduces the time of settlement, but does not eliminate the state error. The Integral (I) controller eliminates the state error, but may make the transitory output worse while the Derivative (D) controller increases the system’s sta-bility, reducing the transitory oscillations, the over-shoot and improving the transitory output but it also amplifies high frequency noise (Nise, 2002).

2.1 PID Tuning

There are different techniques for tuning a PID con-troller. The Ziegler-Nichols method is well known for being the first to propose a simple and objective methodology for PID tuning.

The Ziegler-Nichols method proposes two tech-niques: in the first one, the proportional gain is in-creased until the closed-loop system’s output has a constant period. That way, the ultimate gain Ku and the oscillation period Pu are determined. Any gain greater than Ku makes the systems unstable. The controller’s tuning is obtained in Table 1. The sec-ond technique consists in applying an open-loop test. A step disturbance is generated at the controller’s output, and by the system’s answer to that distur-bance, the delay or dead-time and the variation rate are calculated and used ahead for the controller’s tuning.

In this paper, two methods are utilized. The Re-lay-Feedback proposed by (Aström and Hägglund, 1995) uses relays in a closed-loop system to provoke

controlled oscillations in a determined process and then, to estimate the period Pu, which is approxi-mately the same as the constant period. At last, the ultimate gain Ku is estimated, witch is related to the relay’s output “h” and the plant’s output “a” as seen in Equation (1).

a

hKu

4

In that way, it is possible to obtain a controller using the two methods together.

When using the FPGA, the period Pu is easily obtained by setting a counter on the simulated relay. This can be seen well in the next section.

The Equation (2) corresponds to a PID control-ler.

)1

1()( sTsT

KsC di

p

This controller is supposed to be used in an in-dustrial environment. For this reason, some adjust-ments need to be done. The derivative term can cause some problems on a real system considering that it uses the derivate of the error. That way it can gener-ate some excessive control actions that may com-promise the system. Because of that, instead of using the derivate of the error, it is used the derivate of the system’s output. This can be seen in the next section.

2.2 Auto Tuning

The Auto-tuning PID utilized in this paper is basi-cally a controller which the tuning is done by means of Ziegler-Nichols and Relay-Feedback methods. The hardware used as controller is responsible for analyzing the plant’s output, simulating the Relay-Feedback’s method, then calculate the parameters necessaries as Ku and Pu, then tune the PID control-ler using Ziegler-Nichols. It is relevant to consider that this is an auto-tuning controller, and not an adaptive, which means that if there is any change on the plant, it will not do a new tuning of the control-ler, unless it has been reset. A PID auto-tuning sys-tem with relay feedback is seen in Figure 1.

For implementing the PID into the FPGA device and inserting the logic into the NIOS II processor, it is necessary to obtain an equation that represents a digital PID.

The digital structure of a PID is represented by Equation (3), u(t) is the control signal, e(t) is the

Table 1. Ziegler-Nichols table for PID tuning.

Controller Kc Ti Td

P Ku5,0 - -

PI Ku4,0 Tu8,0 -

PID Ku6,0 Tu5,0 Tu12,0

Figure 1. Scheme of an auto-tuned PID.

(1)

(2)

system’s error, Ts is the system’s time sample and q0, q1 and q2 are related to Kc, Ti and Td according to Equations (4), (5) and (6).

)2(2)1(1)(0)1()( teqteqteqtutu

Ts

Td

Ti

Tskcq

210

Ts

Td

Ti

Tskcq

2

211

Ts

Tdkcq2

The equations for q0, q1 and q2 are found sub-stituting the derivate by the first order difference and using the trapezoidal approximation for an integral.

Instead of using the error for the derivative term, it is used the system’s output to prevent excessive control action. Equation 7 represents the proportional and integral error, and Equation 8 represents the de-rivative error.

)()()( tytyte ref

)()( tyted

Equation 9 represents the new PID equation, or PI+D.

)]}2()1(2)([)1(

)1()({)1()(

tytytyTs

Tdte

Ti

Ts

tytyKctutu

As the prototyping of the proposed system was

synthesized using FPGA, in the next section the hardware and the programming is described.

3 FPGA-NIOS II

FPGA is a reconfigurable logic device which pro-vides a fast prototyping. One advantage in hardware development synthesized in FPGA is the utilization of the NIOS II processor. The applicability of the NIOS II processor favors the development of em-bedded systems to work in the industrial automation sector. In this paper, a hardware was developed in

order to allow the testing of an execution of a PID controller. The system developed in this paper can be used, for example, to control the speed or position of a DC motor.

In Figure 2, it is shown the hardware architec-ture, which includes a 50MHz CLOCK that provides the system with a capacity of making all the opera-tions needed without compromising the controller. An 8bits input and output, which may be reconfig-ured accordantly to the AD and DA available. An 8Mbytes SD-RAM memory, used to store the code responsible and the variables to be computed and a PLL which adjust the 50 MHz CLOCK for the SD-RAM.

3.1 Hardware Configuration

The prototyping was done using the DE2 board from Altera. This board has an EP2C35F672C6, from the CYCLONE II family.

The hardware that will be used is configured us-ing QUARTUS II software.

The hardware developed in this project is com-posed by:

CPU - 50 MHz NIOS II/s processor. SDRAM - 8 Mbytes SDRAM memory. SYS_CLK_TIMER - 1 μs internal timer

module. SYSID - peripheral identification system

module. JTAG_UART - USB communication port. INPUT - 8 bits input. OUTPUT - 8 bits output. The main components are selected and config-

ured at SOPC Builder and then attached to the pe-ripherals in QUARTUS II. With the hardware gener-ated at SOPC Builder and the compilation in Quartus II, the embedded module is ready to receive the op-eration logic. The operation logic is programmed using C/C++ language in NIOS II IDE environment. The configuration of the embedded module can be seen with the respective I/O in Figure 2. The re-sources used to generate the embedded module are presented in Table 2.

3.2 NIOS II processor configuration

The configuration of the embedded NIOS II proces-sor, present in the FPGA is done using the NIOS II IDE software. This software allows designers to pro-gram using C/C++ language. In this paper, a library with functions that allows the automatic generation

Figure 2. Configuration of the embedded module on Quartus II

Table 2. Resources utilized to generate prototyped hardware.

Total logic elements

Dedicated Logic Register

Memory Bit

Total Pins

9% 5% 6% 12%

(3)

(4)

(6)

(5)

(7)

(8)

(9)

of a PID controller was developed. This library was perfectly inserted into the Select Project Template and might serve as base to PID controller’s projects.

The activities programmed into the processor makes the embedded module receive the signal from the 8 bits input, this signal corresponds to the plant’s output. The input can be changed to 16 bits if neces-sary, although for controlling a motor’s speed 8 bits are enough. After receiving the 8 bits signal, this signal is converted to a decimal base. The step is generated in the FPGA device and the error is also calculated internally.

At a first moment, the module works as a relay feedback, providing a step input in the closed-loop system. Secondly, it compares the error, and change the input’s amplitude with a higher or lower value depending on its Setpoint. This effect generates an oscillatory signal with a constant period as seen in

Figure 5. Part of the code responsible for that analy-sis and for setting the counter that determines the period Pu is presented in Figure 3.

The period found is used to find the parameters of the Ziegler-Nichols controller, and tune the con-troller. After tuning the controller, the signal is changed from the comparator to the actual controller. The tuning of the controller using C/C++ with the 8 bits input coming from the AD converter is seen in Figure 4. It can be observed that the processor calcu-lates the parameters q0, q1 and q2, which are the controller’s constants.

4 Simulation and Implementation

The system was modeled and simulated in MATLAB using the tool Simulink, as seen in Figure 1. The plant utilized for simulation is a plant present in (Nascimento Jr. and Yoneyama, 2000) whose answer is known, so that the results can be compared to the expected values. This plant is represented in the Eq-uation (10).

3

10)(

)5,0(

S

eSG

S

Figure 5 corresponds to the plant’s output using relay feedback, which is analyzed for finding the controller’s parameters. The system’s output using auto-tuning can be seen in Figure 6.

For the implementation of the system, it is nec-essary to use two converters, an AD (analogi-cal/digital) and a DA (digital/analogical) converter.

Figure 4. C/C++ code responsible for tuning the controller.

Figure 5. Plant’s output with relay feedback and relay output.

Figure 3. C/C++ code which simulates the relay feedback.

Figure 6. Plant’s output with auto-tuned PID.

(10)

The system implemented is presented in Figure 7, where it is possible to see the complete system, and each component’s function, with the FPGA respon-sible for the major part.

The simulation carried out with the known plant had the objective to calculate the digital PID con-stants q0, q1 and q2. With these parameters calcu-lated, it is necessary to know the previous inputs as seen in Equation (3). The simulation was performed in MATLAB and the parameters calculated in the DE2 board. In that way, it was not necessary to transform the plant into a discrete one. The method presented in this article does not need an equation that corresponds to a plant, it tunes the controller automatically from an unknown plant.

5 Conclusion

The development of the PID auto-tuning controller using FPGA and NIOS II processor helps developers to increase speed in designing industrial systems. That way the developer can concentrate on other things and later use the template of the PID Auto-Tuning, saving time and hardware, because the FPGA can be used for something else at the same time. An example is a robotic arm that uses camera’s images to change an object’s position. The FPGA can do the image processing and the control of the arm position using the PID auto-tuning, without the need of another hardware. The applicability of the results presented in this paper can be utilized as pa-rameters to practical implementations in control and automation industry. The results obtained with the embedded module are approximately the same as the ones obtained in simulation using MATLAB. To make it easier to future applications of the system proposed in this paper, a specific library was devel-oped with the necessary functions to generate the

PID auto-tuning. This library can be made available by the manufacturer in applications that use the NIOS II processor. For the next steps, it is hoped to do some real tests without the knowledge of the plant, where this prototype will be linked to a power circuit, signal converters and to the plant, in order to make the parameters’ control. The tuning will also be done using different methods instead of Ziegler-Nichol to compare the results.

References

Altera Corporation, Nios II Software Developer’s Handbook. Página web <www.altera.com> acessada em 10 de março de 2009, San Jose: Altera Corporation, 2007. pp. 620.

Anthony Cataldo (2005), Low-priced FPGA options set to expand. Electronic Engineering Times Journal, N 1361, PP 38-45, USA.

Åström, K. and Hägglund, T. (1995), PID Controllers: Theory, Design and Tuning, Ed. ISA.

Åström, K. and Hägglund, T. (2001), The Future of PID Control, Control Engineering Practice, Vol.9, No. 107, pp. 1163-1175.

Chien et al. (1952), Chien, Hrones, and Reswick. On the Automatic Control of Generalized Passive Systems. Transactions of the ASME, V. 74, pp. 175-185.

Cohen, G.H. and Coon, G.A. (1953), Theoretical Considerations of Retarded Control. Transactions of the ASME, pp. 827-834.

Deng D., Chen S. and Joos G. (2001), FPGA implementation of PWM pattern generators, Canadian Conference on Electrical and Computer Engineering, V1, pp. 225-230.

Franklin G., Powell J., and Emami-Naeini A. (2002), Feedback control of dynamic systems, Addison-Wesley, 4th ed.

Gordon Hands (2004), Optimised FPGAs vs dedicated DSPs, Electronic Product Design Journal, V 25, N 12, UK.

Nise, N. S. (2002). Engenharia de Sistemas de Controle, 3 Ed, Rio de Janeiro: LTC.

Ogata, K. (1998). Engenharia de Controle Moderno. 3 Ed. Rio de Janeiro: Prentice Hall do Brasil.

Rivera, Morari and Skogestad (1986). Internal Model Control, 4. PID Controler Design, Industrial and Enginering Chemistry Process Design and Development, V. 25, pp. 252-265.

Ruschel, O. T. (1996). Princípios da comunicação digital, EDIPUCRS, Porto Alegre, pp. 12.

Visioli, A. (2001), Optimal Tuning of PID Controllers for Integral and Unstable Processes. IEE Proc.Control Theory Appl., No. 148, pp. 180-184.

Wang, Y.-G, and Cai, W.-J. (2002), Advanced Proportional-Integral-Derivative Tuning for Integrating and Unstable Processes with Gain

Figure 7. Representative scheme of implemented system in FPGA from DE2 Altera.

and Phase Margin Specifications. Ind. Eng. Chem. Res., Vol. 41, pp. 2910-2914.

Chan Y. F., Moallem M. and Wang W. (2004), Efficient Implementation of PID control algorithm using FPGA technology, Proceedings of the 43ed EE Conference on Decision and Control, V5, pp. 4885-4890.

Ziegler, J. and Nichols, N. (1942). Optimum Settings for Automatic Controllers, Transactions of the ASME, No. 1, pp. 759-768.

AN EXTENSION OF THE IEEE 1451.2 STANDARD TO ACT WITH EMBEDDEDCONTROLLERS

Alfranque Amaral da Silva∗, Tomas Victor G. P. de Araujo∗, Antonio Marcus N. Lima∗

∗Universidade Federal de Campina Grande - UFCGCenter for Electrical Engineering and Informatics - CEEI

Department of Electrical Engineering - DEERua Aprıgio Veloso, 882, CEP: 58429-970, Bairro Universitario

Campina Grande, Paraıba, Brazil, Caixa Postal 10053

Emails: alfranque@ee.ufcg.edu.br, tomas@ee.ufcg.edu.br, amnlima@ee.ufcg.edu.br

Abstract— Smart transducers (sensors and actuators), linked to networks have to a growing extent beenused in control systems to execute distributed measurements and performances. In this case, the intelligencepresent in smart transducers or in the network nodes make it possible to process information and to take localdecisions, thus reducing the flow of network data that overloads the network. This paper thereby proposesan extension of the IEEE 1451.2 standard which specifies the STIM (Smart Transducer Interface Module) toenable the integration of embedded controllers within smart transducers themselves, aiming therefore to defineand implement the STIMEC (Smart Transducer Interface Module with Embedded Controllers). For the correctperformance of the STIMEC, changes needed to be proposed to standard IEEE 1451.1 which defines the NCAP(Network Capable Application Processor), resulting in the NCAPEC (Network Capable Application Processorwith Embedded Controllers).

Keywords— Smart transducer, Network Communication, Control Systems Embedded, IEEE 1451 Standard,Distributed Systems.

1 Introduction

A feedback control system consists of an opera-tion which tends to, in the presence of disturbs,reduce the difference between the system outputand an input reference based on this difference(Ogata, 2003). In these systems, the use of trans-ducers (sensors and/or actuators) is indispensablein the interaction of the system for the perfor-mance of measurements and actuations. With theintegration of network interfaces in the transduc-ers, the concept of smart transducer has emerged.They can be defined as a system that is consti-tuted of an analog or digital transducer, a micro-processor and a communication interface (da Silvaet al., 2005a).

Since then, smart transducers, networks andcommunication protocols have come to be devel-oped by several organizations to supply an in-creasing and diversifying demand of applications.However, the fact that transducers are developedfor specific networks restrained their integrationin different network environments. In an attemptto soften this burden, the IEEE came to developand publish a series of free standards to standard-ize smart transducers and the communication in-terfaces to integrate them on network. Thus thefamily of standards IEEE 1451 was born, con-sisting of eight standards, from which the IEEE1451.1 (IEEE, 1999), IEEE 1451.2 (IEEE, 1997),IEEE 1451.3 (IEEE, 2004a), IEEE 1451.4 (IEEE,2004b) have already been published. The IEEE1451.0, IEEE 1451.5, IEEE 1451.6 and the IEEE1451.7 standards have not been published yet(NIS, 2009). Nevertheless, this paper deals solely

with the standards IEEE 1451.1 and IEEE 1451.2.

Smart transducers linked to networks have toa growing extent been used in control systemsto execute distributed measurements and perfor-mances. In this case, the intelligence present inthe smart transducers or in the network nodesmakes it possible to process information and totake local decisions, thus reducing the flow ofthe network data that overloads the network(Johnson, 1997). On the other hand, the intel-ligence distributed in the smart transducers or inthe network nodes provide a promising alternativeto deal appropriately with the inherent complexityof distributed systems. This enables to embedded(Wolf, 2001) control algorithms within the trans-ducer itself, or in the network node where it isconnected. In this respect, this paper proposesand implements the integration of control algo-rithms in the definition of the STIM (Smart Trans-ducer Interface Module), standard IEEE 1451.2(IEEE, 1997), to enable embedding on/off con-trollers, P, PI and PID within the STIM. Forthe correct operation of the STIMEC, changeswere made necessary in the IEEE 1451.1 standardwhich defines the NCAP (Network Capable Appli-cation Processor) (IEEE, 1999). In the NCAP theinterface was redefined to allow the user to definethe reference signal value, type and parameters ofthe controllers via web.

This paper is thus structured as follows. Sec-tion 2 presents the networks in the control en-vironment. In section 3, the IEEE 1451.2 andIEEE 1451.1 standards are presented. In section 4the experimental platform of development is pre-sented. Section 5 presents the controlled process.

Section 6 presents the control system. In the sec-tion 7 the human/machine interface of the NCAPis presented. Finally, in section 8 the final con-siderations are drawn, as well as perspectives forfuture works.

2 Networks in the control environment

Examples of control systems that use networksare found in industrial automation, in smart vehi-cle systems, and in spacecrafts (Chow and Tip-suwan, 2001; Feng-Li Lian and Tilbury, 2001).An illustrative diagram of the kind of environ-ment where smart transducers with embeddedcontrollers are used is showed in Figure 1.

PCControllers

Module with EmbeddedTransducer Interface

Smart

ControllersModule with EmbeddedTransducer Interface

Smart

Process

ControllersModule with EmbeddedTransducer Interface

Smart

Process

...

PC

Process

Intranet/Internet Network

...Server

LAN

Figure 1: LAN (Local Area Network), with smarttransducer modules with embedded controllers in-serted in measurement and/or control process.

In this environment, transducer modules withembedded controllers (STIMEC) are inserted inmeasurement and/or control processes, as illus-trated Figure 1 (in the area delimited by thedashed line). Besides measurements and/or ac-tuations performed by smart transducers, theSTIMEC also have embedded control algorithms.The STIMEC is a promising, technologically vi-able alternative to reduce the implementation costof control systems, frequently implemented withexpansive devices such as PLC’s (ProgrammableLogic Controller). Obviously, the kind of solu-tion proposed in this paper does not contemplateall necessities of existing controls. However, itcontemplates slow dynamic systems, whose exe-cution of implemented control algorithms demandprocessing compatible with their execution time inthe microcontroller.

The smart transducer used in this paper isspecified by the IEEE 1451.2 standard which de-fines the STIM (Smart Transducer Interface Mod-ule). The implementation of the STIM with em-bedded controllers described in this paper will behenceforth called STIMEC (Smart Transducer In-terface Module with Embedded Controllers). Forthe implementation of the STIMEC, it was neces-sary to create new functionalities in the STIM.This was done by defining new functional ad-dresses, expanding the concept from the STIM to

STIMEC.The data arising from or addressed to the

STIMEC can be visualized or defined through aweb interface. This web page is executed in theNCAP (Network Capable Application Processor),IEEE 1451.1 standard (IEEE, 1999). For such, aninterface of the NCAP was redefined to allow theuser to define the reference signal value, type ofcontroller and Kp, Ti, and Td parameters of con-trollers. This new implementation of the NCAPwill be henceforth called NCAPEC (Network Ca-pable Application Processor with Embedded Con-trollers). In this interface, the definition of thecontroller kind, its parameters and the referencesignal value are defined and visualized by users bymeans of a graphic interface (applet), developedin Java and available on the web page.

3 STIMEC

The STIM is specified by the IEEE 1451.2 (IEEE,1997) standard. The digital interface of the STIMis performed through an interface TII (Trans-ducer Independent Interface). In this interface thedata transport from the STIM to the NCAP andvice-versa is performed by the SPI (Serial Periph-eral Interface) (Estl, 2002; da Silva et al., 2005b;Woods et al., 1996). The STIMEC studied in thispaper, however, is an extension of the IEEE 1451.2standard to allow applications of feedback control.

AddressLogic

FunctionalBoundaries

ADC

?

DI/O

DAC

XDCR

XDCR

XDCR

TII

TEDS

CTPC

NCAPEC

NetworkSTIMEC

Figure 2: Context for the Smart Transducer In-terface Module with embedded controller specifi-cation .

In Figure 2 the XDCR block represents a sin-gle transducer. The ADC (Analog to Digital Con-verter), DAC (Digital to Analog Converter), DIO(Digital Input Output), ? (Any other IO device)blocks represent data input/output. The elec-tronic data about the specification and descriptionof the transducer are stored in the TEDS (Trans-ducer Electronic Data Sheets) block. The chan-nel logic selection is specified by the logic addressblock. The NCAPEC block connects the STIMECin any given network. However, the NCAPECnetwork used in this application is the Ethernetnetwork.

The STIMEC follows the specifications ofSTIM, defined by the IEEE 1451.2 standard. For

Table 1: Functionality definition of STIMEC.Add Ch Add Fn Type Cont Par. Cont Function of each channel of STIMEC

8 8 all - Write reference signal value (r) of the controller8 136 all - Read the signal value r

9 9 all∗ - Write habilitating the type of controller9 137 all - Read the type status of habilitated controller10 10 ∗∗ Kp Write parameter Kp

10 138 - Kp Read the value of Kp

11 11 ∗ ∗ ∗ Ti Write parameter Ti

11 139 - Ti Read the value of Ti

12 12 ∗ ∗ ∗∗ Td Write parameter Td

12 140 - Td Read the value of Td∗ value 1 to habilitate On/Off controller, value 2 to habilitate (P) proportional controller, value 3to habilitate (PI) proportional integral controller , value 4 to habilitate (PID) proportional integralderivative controller. ∗∗ to P, PI and PID controllers; ∗ ∗ ∗ to PI and PID controllers and ∗ ∗ ∗∗ toPID controllers.

such, functionalities were added to some chan-nels reserved to future extensions of the standard.An outline of the channel addresses (Add Ch),functional addresses (Add Fn), type of controller(Type Cont), parameters of controllers (Param ofCont) and the function of each channel are shownin Table 1.

3.0.1 Channel Type and Logic Address

The transducers (XDCRs) in the STIMEC areconnected to a microcontroller’s IO ports. Theintelligent transducer is composed by: transducerconnections to the microcontroller; all TEDS func-tionalities; channel logic address and TII ac-cording to the IEEE 1451.2 specification. TheIEEE 1451.2 specifies the general behavior of sixchannel types. A seventh type is used to al-low extensions for the STIMEC. The seven chan-nel types are: sensor, actuator, buffered sensor,data sequence sensor, buffered data sequence sen-sor, event sequence sensor and general transducer(IEEE, 1997). The main difference between thechannels is on the way that the transducer as-sociated to each channel is triggered. The trig-ger could be used for a single channel or for allchannels simultaneously through channel 0. TheSTIMEC supports up to 256 channels.

4 Implemented experimental platform

The NCAPEC hardware is based on the TBM390(TINI - Tiny InterNet Interface - Board Model)(Dal, 2001). The STIMEC hardware uses anADuC832 microcontroller (Ana, 2002). Figure 3shows the platform’s detailed specifications dia-gram, with an ADuC832 and a TBM390. TheTII interface lines specification is shown on Table2.

The TII connection lines and the board pins(ADuC832 and TBM390) are shown on the up-per part of the Figure 3. In the inferior part of

ControledProcess

MonitoringStation

TRIACPulse

NIOE

DCLK

DIN

DOUT

NTRIG

NINT

NACK

DGND

Vcc

SCLOCK

MOSI

MISO

P3.2 (INT0)

NSDET 10 k

SS(P1.5)

GND

P3.0

P5.6

P5.5

P5.4

P3.4

P5.7

P3.1

P5.1

P5.0

POWER

P3.5

COMMON

STIMECNCAPEC

LAN

Commum

ADC0

P3.7

y u

J1−1

J2−8

J7−1,J3−1

J2−6

J2−7

J2−3

J3−3

J3−4

J3−2

J3−5

J1−16

TBM390 SAR Eval Board Rev A3

P3.6

Figure 3: Platform detailed specification diagramof development background.

this Figure the block named Controlled Processshows the input of the plant (u) provided by thepulse of a TRIAC and the output of the plant y

sampled by ADuC832’s AD converter. The dataobtained from the AD by the STIMEC are sentto the NCAPEC through TII interface. The func-tions of each line are shown in Table 2.

5 The Controlled Process - Grains Dryer

A grains drying system is used in agriculture forhumidity control and in the treatment of storedseeds. Its work is based on a hot air flow whichreduce the seeds humidity in function of temper-ature and velocity of air flow. A system that rep-resents a grains dyer was implemented as shownin figure 4, so that the STIMEC controls the out-put air flow temperature. Through a small ven-tilator, cooler air (room temperature) is suckedinto an inner air tube at a constant flow (Araujoet al., 2005).

The air that gets into the tube is heated byan electric resistance with a nominal power of

Table 2: TII line functions.Line FunctionDIN Address and data transport from

NCAP to STIMDOUT Data transport from STIM to

NCAPDCLK Positive-going edge latches data

on both DIN and DOUTNIOE Signals that the data transport

is active and delimits data trans-port framing

NTRIG Performs triggering functionNACK Serves two functions: trigger ac-

knowledge and data transport ac-knowledge

NINT Used by the STIM to request ser-vice from the NCAP

NSDET Used by the NCAP to detect thepresence of a STIM

POWER Nominal 5 V power supplyCOMMON Sinal common or ground

Driver

������������������������

������������������������

����

����������������

��������������������LM35

STIMEC NCAPECIntranet/InternetNetwork

MonitoringStation

Fan

TII

Dry CamaraConditioningSignals

Heating Resistance

Air Tube

Hot Ar Output Cold Ar

Figure 4: Grains dryer linked to the control sys-tem of the STIMEC.

30W (220V ac). The hot air is guided to the dry-ing camera where the temperature is measuredwith an LM35 temperature sensor. The controller,given the hot air flow temperature reading and theestablished reference, will perform the output con-trol calculation so that the electric power renderedto the heating resistance produces zero error.

6 Closed-Loop Control System

In the Figure 5 is showed a block diagram of theclosed-loop control system, whose embedded con-troller inner variables are illustrated: r (set pointor reference), e (control error), u (manipulatedvariable) and y (controlled variable). The em-bedded controller C(s) is programmed in a spe-cific routine designed to perform the system con-trol H(s). For the controller implementation, it isnecessary that the control algorithms routine beincorporated to the firmware of the STIMEC.

+r e u yC(s) H(s)

Figure 5: Control system implementated with in-terns variable.

6.1 Temperature control experiment

The control problem used to demonstrate theSTIMEC concept is the grains dryer hot air flowtemperature control implementation. The tem-perature value change is concomitant with thephase shifting of the TRIAC’s triggering pulse.For synchronism with the electrical grid, a zerocrossing detection circuit generates pulses to themicrocontroller, which identifies the beginningand the end of each semi-cycle. The hot air flowtemperature is informed to the controller throughan LM35 sensor, placed immediately after the airtube shown in Figure 4. A signal conditioningcircuit amplifies the reading voltage produced bythe LM35 so that the temperature limits of thegrains dryer (23 to 83oC) correspond to the A/Dconverter’s reading band (0 to 2.5V ). For a moredetailed discussion of these experiment see the pa-per (da Silva et al., 2008).

The controller’s system must be discretizedfor implementation under the form of differenceequations for the P (1) and PI (2) controllers inthe control routine stored in the STIMEC. Forthe discretization of the system under analysis,Tustin’s approximation was used, with a samplingtime of 20 ms (Astrom and Wittenmark, 1997).

u(z) = 40.4e(z) (1)

u(z) = u(z − 1) + 36.38e(z)− 36.31e(z − 1) (2)

7 NCAPEC Human/Machine Interface

The NCAPEC graphic interface makes the tem-perature measured by LM35 sensor (STIMEC im-plementation) available in a chart form providedby an applet executed in a web browser duringthe data acquisition. The conditioning signal cir-cuit output voltage is sampled via the ADuC832ADC. After the triggering process the converteddata is sent to the NCAPEC using the TII. In theNCAPEC the received data bytes are convertedto temperature measurements using the sensorspecified equivalence relation. The temperatureis shown in a chart form and in a display (Celsiusor Fahrenheit scales) together with the controller’sreference signal graphic.

The temperature (vertical) and time (horizon-tal) scales in the chart could be adjusted by scrollbars. The main TEDS information is shown onthe left side of the graphic interface. The samplerate is adjusted according to the sample numberdefined by the user (up to 60 samples per minute).

Figure 6: Web page graphic interface for the IEEE 1451.1 implementation.

In the interface can be seen: a button to start theexecution of the process; a button to erase thedata stored in the buffers (temperature and refer-ence); a button to finish the application; a buttonto update the type, the parameters and the refer-ence value of the controller; a display to show thevalue of the control error and some of the mainTEDS information. This graphic interface wasoriginally developed by the TINI’s manufacturer(Max, 2002), which was modified for the specifiedpaper tests (Figure 6).

To access the web interface executed in theTBM390, the user needs to type the IP (Inter-net Protocol) on the browser address bar of aPC (Personal Computer) connected to the in-tranet/internet. This interface can be accessedin any place in the world. The graphic signalrepresenting the reference signal of the controlleris a straight line. However, the output signal ofthe system varies around the reference signal withpractically zero error. Observe in Figure 6 thatthe output signal of the plant (y), in red, followsthe set point signal (r) of the controller, in blue.During the first reference step (to the left) thecontrolled y signal follows the set point signal r

controlled by the On/Off controller. During thesecond step (on the right side of the first step) they signal follows the set point signal r controlled

by the P controller. During the third step (rightside of the second step) the y signal follows theset point signal r controlled by the PI controller.This illustrates the functioning of the STIMEC.

A description of the NCAPEC software toachieve the communication between the webserver and web client. In addition, the developedsoftware block and the graphic interface relationsare illustrated, where the information STIMECare showed. More detail over the interface’s soft-ware in (da Silva et al., 2006; da Silva et al., 2008).

8 Conclusions

The STIMEC proposed in this article is an innova-tion of the concept of the STIM, proposed by theIEEE 1451.2 standard, enabling the developmentof embedded control strategies in the STIM. Themain advantage of this kind of system is in the lowprice for the implementation of a control system,the possibility of reconfiguration of the controllerparameters via intranet/internet network, further-more, the possibility of supervision, another kindof high cost system.

For future works the development team in-tends to implement the STIMEC with real timeembedded routines. Another viable work, alreadyimplemented (da Silva et al., 2006), which can

be incorporated in this system, is a Real TimeDatabase Management System. The integrationof these systems would enable the implementationof a simple supervisory system, in which the con-trol system signal data would be kept, stored in adatabase.

Acknowledgments

The authors would like to thank the CNPq,CAPES and PPGEE for the financial support.

References

Ana (2002). ADuC832, MicroConverter, 12-BitADCs and DACs with Embedded 62 kBytesFlash MCU, inc., 2002. edn.

Araujo, T. V. G. P., de S. Filho, C. A., Lima, A.M. N. and Barros, P. R. (2005). Kit de de-senvolvimento para microcontroladores aducaplicado ao ensino de controle e automacao,Cobenge Setembro: 1–12.

Chow, M.-Y. and Tipsuwan, Y. (2001).Network-based control systems: A tutorial,IECON’01: The 27th Annual Conferenceof the IEEE Industrial Electronics Society0-7803-7108-9/01/(C)2001 IEEE: 1593–1602.

da Silva, A. A., Araujo, T. V. G. P. and Lima,A. M. N. (2008). Implementacao de contro-ladores embarcados com supervisao web.

da Silva, A. A., Leite, C. R. M., Perkusich, A.,Perkusich, M. L. B., Lima, A. M. N. andBarros, P. R. (2006). Application of a realtime query language for smart transducernetworks, VII Induscon April: 1–8.

da Silva, A. A., Lima, A. M. N. and Barros,P. R. (2005a). Ambiente para desenvolvi-mento de aplicacoes baseadas em transdu-tores inteligentes: Padroes ieee 1451.2 e ieee1451.1, VII SBAI/II IEEE LARS Setem-bro: 1–8.

da Silva, A. A., Lima, A. M. N. and Barros,P. R. (2005b). Tutorial: Etapas de desen-volvimento de transdutores web utilizandodispositivos embarcados, XXXIII CobengeSetembro: 1–12.

Dal (2001). O TINI Specification and Developer’sGuide, first edn.

Estl, H. (2002). Application Note, SPI interfaceand use in a daisy-chain bus configuration, v1.2 edn, Infineon Technologies.

Feng-Li Lian, J. R. M. and Tilbury, D. M.(2001). Performance evaluation of controlnetworks: Ethernet, controlnet, and de-vicenet, IEEE Control Systems MagazineFebruary 2001: 66–83.

IEEE (1997). Standard for a smart transducer in-terface for sensors and actuators - transducerto micro-processor communication protocolsand transducer eletronic data sheet (teds)formats, IEEE IEEE Std 1451.2-1997: 1–120.

IEEE (1999). Standard for a smart transducer in-terface for sensors and actuators - networkcapable application processor (ncap) infor-mation model, IEEE IEEE Std 1451.1-1999.

IEEE (2004a). Standard for a smart transducerinterface for sensors and actuators - digi-tal communication and transducer electronicdata sheet (teds) formats for distributed mul-tidrop systems, IEEE IEEE Std 1451.3-2003: 1–185.

IEEE (2004b). Standard for a smart transducerinterface for sensors and actuators - mixed-mode communication protocols and trans-ducer electronic data sheet (teds) formats,IEEE IEEE Std 1451.4-2004: 1–439.

Johnson, R. N. (1997). Building plug-and-playnetworked smart transducers, Eletronics De-velopment Corporation October: 1–18.

Max (2002). Application Note 198, NetworkedTemperature Monitoring, 052902 edn.

NIS (2009). IEEE-P1451 Draft Standard forSmart Transducer Interface for Sensors andActuators - http://ieee1451.nist.gov/, aug,2009 edn.

Ogata, K. (2003). Engenharia de Controle Mod-erno. Traducao: Paulo Alvaro Maya; revisaotecnica: Fabrizio Leonardi, quarta edn, Pren-tice Hall, Sao Paulo.

Astrom, K. J. and Wittenmark, B. (1997).Computer-Controlled Systems: Theory andDesign, third edn, Prentice Hall, New Jersey.

Wolf, W. (2001). Computers as Components.Principles of Embedded Computing SystemDesign, MK, San Francisco, CA.

Woods, S. P., Bryzek, J., Chen, S., Cranmer,J., El-Kareh, E. V., Geipel, M., Gen-Kuong,F., Houldsworth, J., LeComte, N., Lee, K.,Mattes, M. F. and Rasmussen, D. E. (1996).Ieee 1451.2 smart transducer interface mod-ule, Proceedings of SENSORS Conference,Philadelphia, PA; 1996 (October 22-24) .

OTIMIZAÇÃO DA SEQÜÊNCIA DE MONTAGEM DE COMPONENTES PARA PROGRAMAÇÃO DE INSERSORAS AUTOMÁTICAS USANDO O MÉTODO DE SUBIDA EM ENCOSTA

ÁLVARO LUIZ M. DE OLIVEIRA

Centro de Tecnologia Eletrônica e da Informação, Universidade Federal do Amazonas

Av. Rodrigo Otávio Jordão Ramos, 3000, Campus Universitário, Setor Norte, Pavilhão Rio Japurá, 69077-000

E-mail:alvaroluizmenezes@ig.com.br

CÍCERO F. F. COSTA FILHO

Centro de Tecnologia Eletrônica e da Informação, Universidade Federal do Amazonas

Av. Rodrigo Otávio Jordão Ramos, 3000, Campus Universitário, Setor Norte, Pavilhão Rio Japurá, 69077-000

E-mail: ccosta@ufam.edu.br

MARLY G. F. COSTA

Centro de Tecnologia Eletrônica e da Informação, Universidade Federal do Amazonas

Av. Rodrigo Otávio Jordão Ramos, 3000, Campus Universitário, Setor Norte, Pavilhão Rio Japurá, 69077-000

E-mail: mcosta@ufam.edu.br

Abstract This work dealt with the problem of optimizing the mounting time of electronic components on printed circuit boards, PCBs. The solution proposed uses the random- restart hill climbing algorithm. Details of the methods application are shown. It is also shown the mathematical modeling of the cost function optimized by the hill climbing method. The performance of the proposed method is compared with the performance of other methods proposed in the literature and one method used by the manufacturer of the printed circuit assembly machines. The results showed the superiority of the proposed method.

Keywords PCB, hill climbing, optimizing.

Resumo Neste trabalho abordou-se o problema de otimização do tempo de montagem de componentes eletrônicos sobre as placas de circuito impresso, PCI. Para resolução desse problema propõe-se a utilização do algoritmo de subida em encosta com reinício aleatório. Mostra-se detalhes da aplicação do método de subida em encosta ao problema em questão e apresenta-se uma modelagem matemática para a função de custo. Nos resultados compara-se o desempenho do método proposto com o desempe-nho de outros métodos propostos na literatura e com o método proposto por fabricantes de equipamentos comerciais de máqui-nas de inserção de máquinas de inserção comerciais. Os resultados obtidos mostram a superioridade do algoritmo proposto fren-te aos métodos comparados.

Palavras-chave PCI, subida em encosta, otimização.

1 Introdução

Na indústria de dispositivos eletrônicos há um crescente anseio por ferramentas capazes de minimi-zar os custos de produção mantendo, no entanto, um aumento de produtividade. Neste cenário encontram-se as máquinas de inserção automática de componen-tes eletrônicos sobre placas de circuito impresso, PCI. Todos os esforços são realizados para o desen-volvimento de algoritmos para o controle dessas máquinas que possibilitem a montagem de todos os componentes sobre a PCI no menor tempo possível, maximizando-se desta forma, a produtividade das mesmas.

Diversos autores abordaram o desenvolvimento de algoritmos dessa natureza na literatura: Ayob et al. (2003), Burke et al. (2001), Carvalho (2007), Ho et al. (2004), Lee et al. (2000).

Os autores Lee et al. (2000), Burke et al. (2001) e Craveiro (2007) utilizaram algoritmo genético para minimizar o tempo de alocação de componentes em PCI. Os dois primeiros empregaram cromossomos que representam as seqüências de inserção de com-ponentes, a distribuição dos rolos dos componentes nos escaninhos dos magazines e as seqüências de ventosas utilizadas no processo de montagem e pro-curaram resolver simultaneamente o problema de otimização desses três níveis. Já em Craveiro (2007) elaborou-se o modelo para um algoritmo genético específico, constituído de duas partes. Na primeira parte foi realizada uma pré-otimização que consistiu em um algoritmo genético destinado a resolver o problema do melhor arranjo de cabeças possível. O resultado desta pré-otimização foi então apresentado ao algoritmo genético principal, para que este resol-vesse o restante do problema, otimizando a seqüência de montagem e de distribuição dos rolos de compo-nentes nos escaninhos do magazine, visando encon-trar o menor tempo de inserção possível.

O trabalho de Ayob et al. (2003) se dispôs a aproveitar o avanço tecnológico representado por um dispositivo alimentador considerado inteligente por ser capaz de identificar as posições sobre os escani-nhos dos tipos de componentes utilizados no proces-so de montagem de componentes SMD sobre PCIs.

Nesse artigo propõe-se a utilização do algoritmo de subida de encosta com reinício aleatório para a otimização do tempo de montagem de componentes em uma máquina da marca JUKI, mas especificamen-te o modelo JUKI-2030, mostrado na figura 1. Pro-põe-se a otimização simultânea dos três níveis de otimização anteriormente referidos. Embora aplicado para otimização do tempo de montagem de compo-nentes na máquina JUKI-2030, o método proposto poderia ter sido empregado para otimização do tem-po de montagem de componentes em outras máqui-nas de inserção de componentes com características semelhantes.

Apresenta-se na seqüência: Conceitos pertinentes a máquinas de inserção de componentes; detalhes do algoritmo de subida em encosta empregado; a mode-lagem matemática da função de custo utilizada e os resultados alcançados em relação ao tempo de mon-tagem, comparando o desempenho do método pro-posto com o desempenho de outros métodos previa-mente publicados na literatura.

2 Máquinas de Montagem de Componentes

Existem diversos fabricantes de máquinas de montagem de componentes eletrônicos. Cada fabri-cante desenvolve diversos modelos que atendem a diferentes necessidades dos clientes. Desta forma, há máquinas que possuem apenas uma cabeça para mon-tagem e outras que possuem múltiplas cabeças. Há também aquelas que possuem um magazine com alimentadores de componentes em formato linear e outras com formato circular. Existem também, mode-los de máquinas nas quais há um dispositivo denomi-nado de Dispositivo de Troca de Ventosas, DTV. Nestes, são encaixadas as ventosas que por sua vez serão encaixadas nas extremidades das cabeças de inserção. Estas ventosas capturam os componentes a serem montados sobre a PCI. Em função do peso e do tamanho do componente, existe uma ventosa es-pecífica. Pode ocorrer de dois componentes diferen-tes usarem o mesmo tipo de ventosa.

Um ciclo de captura-montagem é constituído pela captura de componentes que estão depositados sobre os alimentadores do magazine seguido pela montagem dos mesmos sobre a PCI. O modelo JUKI 2003, mostrado na figura 1, apresenta as seguintes características: O magazine de componentes tem um formato linear e situa-se em ambos os lados da PCI; próximo a PCI encontra-se montado o DTV; tanto o magazine como a placa permanecem fixos, sendo a captura e montagem dos componentes realizadas através de um braço móvel; o número de cabeças de

montagem é igual a 4, sendo o número máximo e mínimo de componentes capturados e montados em um ciclo igual a 1 e 4, respectivamente.

Figura 1.Modelo JUKI-2030.

3 Metodologia

3.1 Algoritmo de Subida de Encosta

O algoritmo de subida em encosta (Russel, 2004) trata-se de um método local de otimização. O empre-go desse método na otimização de um problema pressupõe a definição de um estado para esse pro-blema e a possibilidade de se identificar os vizinhos desse estado. Além disso, para cada estado do pro-blema deve ser possível o cálculo de uma função objetivo ou de uma função de custo. No primeiro caso, o processo de otimização procurará por um valor máximo, enquanto que no segundo caso o pro-cesso de otimização procurará por um valor mínimo. A descrição para o algoritmo de subida em encosta dada a seguir supõe que se esteja trabalhando com uma função de custo. O processo de otimização inici-a-se com um estado inicial definido aleatoriamente, denominado de estado eleito. Calcula-se então o valor da função de custo para esse estado. Em segui-da calcula-se também o valor da função de custo para cada estado na vizinhança do estado eleito. O valor da função de custo do estado eleito é então compara-do com o valor mínimo da função de custo dos seus vizinhos. Se esse valor mínimo for maior ou igual ao valor da função de custo do estado eleito, o processo de otimização termina, sendo o estado eleito o que apresenta um valor ótimo para a função de custo. Caso contrário, escolhe-se o novo estado eleito como sendo aquele com o valor mínimo da função de custo e o processo de otimização continua. O método de otimização descrito anteriormente ocorre em torno de um estado inicial escolhido aleatoriamente e, portan-to trata-se um método local. A partir desse método local pode-se definir o seguinte método global de

otimização: Reinicia-se inúmeras vezes, aleatoria-mente, o estado inicial e anota-se o melhor valor para a função de custo resultante dessas reinicializa-ções. Esse método de otimização global é denomina-do de subida em encosta com reinício aleatório e foi o método utilizado nesse trabalho

3.2 Método Proposto

A função de custo para o modelo de insersora analisado mensurou o tempo total despendido pelas cabeças de inserção durante todos os ciclos de captu-ra-montagem de componentes. Assume-se que, quan-to menor a distância percorrida, menor o tempo ne-cessário para montar uma PCI. A função de custo do problema é definida no item 3.3.

Um estado para o modelo da insersora analisado é definido como a seqüência de montagem dos com-ponentes seguida da seqüência de alimentação dos componentes no magazine. Essa dupla seqüência será chamada doravante de seqüência montagem-alimentação ou estado do problema.

A figura 2 ilustra o fluxograma proposto para minimizar o tempo de montagem dos componentes baseado no algoritmo subida em encosta com reinício aleatório.

O fluxograma começa valorando as variáveis m,

n e t0, as quais representam respectivamente a quan-tidade de vizinhos, a quantidade de reinícios aleató-rios e a distância para a montagem da PCI. Para esse último escolhe-se inicialmente um valor muito alto. Em seguida inicia-se o processo de otimização des-crito anteriormente com a definição aleatória de um estado inicial, ou seja, de uma seqüência de monta-gem-alimentação. Em seguida é definida a seqüência de ventosas necessária para a montagem dos compo-nentes através de um procedimento heurístico que visa: 1) Evitar ao máximo a troca de ventosas através da permuta dos elementos da seqüência de monta-gem, tanto no mesmo ciclo, quanto entre ciclos; 2) Dissociar a seqüência de captura da seqüência de montagem, avaliando a forma mais rápida de capturar os componentes de um ciclo. Depois de realizado este procedimento, o tempo decorrido para a monta-gem será mensurado e comparada com t0. Como no inicio t0 é muito grande, seu valor será substituído pelo novo valor mensurado. Toda vez que o novo tempo mensurado for menor do que t0, seu valor é atualizado. Depois disso, um estado vizinho ao ante-rior será formado a partir da permuta de dois compo-nentes da seqüência de montagem e pela permuta de dois componentes da seqüência de alimentação. O processo será repetido por m vezes. Ao final, um novo estado aleatório será gerado, começando-se tudo novamente. Esse segundo ciclo repete-se por n vezes, quando então o algoritmo será encerrado. No final, o resultado de processo é o menor tempo de montagem, a seqüência de montagem e a respectiva distribuição de componente nos alimentadores.

Este algoritmo mantém as características de ra-pidez e baixo uso de memória. Outra característica importante é a aleatoriedade do algoritmo de subida de encosta utilizado.

Figura 2. Aplicação do método de subida em encosta com reinício aleatório

3.3 Função de custo

A função de custo é definida como o tempo total para capturar e montar todos os componentes da PCI. Na modelagem desenvolvida a seguir, a função de custo é expressa através do parâmetro CT.

3.3.1 Definições

CT: O ciclo de tempo total para capturar e montar todos os

componentes sobre uma PCI;

N: O número de pontos de montagem sobre uma PCI;

Q: O número total de pontos de montagem disponíveis para a

seqüência; onde NQ ≤ ;

K: O número de tipos de componentes (cada alimentador mantém

inúmeras cópias de um tipo de componente em carretel);

G: O número de ventosas usadas pelas cabeças de inserção;

T: O número total de ciclos;

M: O número total de alimentadores-escaninhos, onde M≤K ;

rV : A velocidade média do braço do robô;

pT : O tempo para capturar um componente;

iT : O tempo para montar um componente;

F: A distância entre alimentadores-escaninhos adjacentes;

L: A distância entre ventosas adjacentes;

Usando j para representar o ciclo de montagem atual com

Kj ≤≤≤≤≤≤≤≤1 e usando k para representar a seqüência atual

dentro de um determinado ciclo j , onde Gk ≤≤≤≤≤≤≤≤1 .

Temos que:

yxkjc ,),( : As coordenadas x,y sobre a PCI que terá um

componente na ésimak seqüência do

ésimoj ciclo;

),( kjI : O tempo necessário para o braço viajar e montar um

componente na ésimak seqüência do

ésimoj ciclo;

),( kjP : O tempo necessário para o braço viajar e capturar um

componente na ésimak seqüência do

ésimoj ciclo;

),( kjhp : A ventosa usada para capturar um componente na

ésimak seqüência de captura do ésimoj ciclo de pick&place;

),( kjhb : A ventosa usada para montar um componente na

ésimak seqüência de captura do ésimoj ciclo;

)(is : A distancia do ésimoi escaninho referente a origem dos

alimentadores-escaninhos,

)0(s , onde kis <= ;0)0( ;

),( kjr : A distância do escaninho para a ésimak seqüência de

captura do ésimoj ciclo;

),( kjd : É a distancia Euclidiana percorrida pelo braço do robô

para montar um componente na ésimak seqüência de montagem

do ésimoj ciclo;

),( kjm : É a distância Euclidiana percorrida pelo braço do robô

para capturar um componente na ésimak seqüência de captura do

ésimoj ciclo;

3.3.1 Modelagem matemática da função de custo

∑ ∑ ∑= = =

+=T

j

G

k

G

kkjIkjPCT

1 1 1),(),(min

onde,

);,()/),((),( kjzTVkjmkjP pr ∗+=

);,()/),((),( kjzTVkjdkjI ir ∗+=

sendo que,

),( kjz é a ventosa usada para capturar o componente na

ésimak seqüência do ésimoj ciclo, e

1),( =kjz ; Se há ventosa para capturar ou montar um com-

ponente na ésimak seqüência do ésimoj ciclo;

0),( =kjz ; Em qualquer caso contrário (ex.: Se não há);

Além disso:

∑−

=≤

1

0;),(

G

kGkjz Significa que podemos ter ciclos com no

máximo G componentes, e

====T Q/G se Q%G=0; (resto igual a zero).

====T 1+Q/G se Q%G≠0; (resto diferente de zero).

Nota1:

Nesse trabalho optou-se, neste trabalho, pela medição da distân-

cia em termos da formulação Euclidiana conforme expressões

abaixo:

212

212 )()(),( yyxxkjm −= +− ; (1)

212

212 )()(),( yyxxkjd −= +− ; (2)

Onde x e y são as coordenadas da PCI com translado da origem

da PCI para a origem da máquina de inserção automática. Pois, as

coordenadas da PCI são diferentes das coordenadas de posição

dos braços robóticos e, obviamente, necessita-se de um sistema

de coordenadas com mesma referência.

Continuando:

[ ]∑−

=∗∗=

1

0)(

K

jijgFjis ; Assumindo que os alimentadores

são encaixados em escaninhos adjacentes.

Além disso, se:

1),( =kjbi ; Se o componente do tipo i está presente na

ésimak seqüência de captura do ésimo

j ciclo.

0),( =kjbi ; Em qualquer caso contrário.

Então:

[ ]∑−

=∗=

1

0),()(),(

K

ii kjbiskjr ;

∑−

=∀∀≤

1

0,,1),(

K

ii kjkjb ;

1),( =kjgij ; Se o componente do tipo i está alocado no ali-

mentador que está no escaninho j.

0),( =kjgij ; Em qualquer caso contrário.

{ };)1(,...,2,1,0),( −= Gkjhp ou { };)(,...,2,1 G

e

{ };)1(,...,2,1,0),( −= Gkjhb ou { };)(,...,2,1 G

Finalmente, temos que:

Lkjhkjrkjm px ∗−= ),(),(),( , se 0======== kj ; (Ou

seja, no início, 1º ciclo, 1ª seqüência)

[ ][ ]LGjhGjc

Lkjhkjrkjm

bx

px

*)1,1()1,1(

),(),(),(

−−−−−

−∗−=

se 0,0 ====>>>> kj ; (1ª seqüência de todos os ciclos exceto o 1º

ciclo)

[ ][ ]Lkjhkjh

kjrkjrkjm

pp

x

*))1,(),((

)1,(),(),(

−−

−−−=

se 0>k ; (restante das seqüências dos demais ciclos exceto o

1º ciclo)

Onde:

a) (j-1) é o ciclo anterior; (G-1) é a última seqüência no ciclo j;

(k-1) é a seqüência anterior no ciclo j.

b) A expressão Lkjhp ∗∗∗∗),( é para compensar a posição da

cabeça com a ventosa de captura apropriada para o tipo de com-

ponente a capturar, ou seja, o deslocamento entre as cabeças

dentro do espaço de 1 a G.

e,

yy Gjckjm )1,1(0),( −−−= , se 0,0 => kj (des-

locamento do braço-cabeça do escaninho para a PCI).

0),( =ykjm , em qualquer caso em contrário. (no 1º

ciclo é zero porque não vem da PCI).

[ ][ ]LGjhkjh

LGjrkjckjd

pb

xx

*))1,(),((

)1,(),(),(

−−

−∗−−=,

se 0=k ;

[ ][ ]Lkjhkjh

kjckjckjd

pb

xxx

*))1,(),((

)1,(),(),(

−−

−−−=, se 0>k ;

e,

[ ]yy kjckjd ),(),( = , se 0=k ; (uma vez que a origem dos

y reside no carro de escaninhos)

[ ]yyy kjckjckjd )1,(),(),( −−= , se 0>k ;

Onde: a) c representa coordenada sobre a PCI e r representa coordenada

sobre o carro de escaninhos;

b) Em todos os casos as distâncias são mensuradas da posição

final (para onde o braço se deslocou) subtraída da posição inicial

(onde o braço estava).

Por exemplo: [ ])1,(),(( −− kjhkjh pp informa que o conjun-

to com as cabeças e ventosas se deslocou da posição da seqüência

k-1 para a posição da seqüência k no ciclo j.

c) Os índices x e y associados distâncias ),( kjd e ),( kjm ,

equivalem as coordenadas x e y das equações Euclidianas (1)

e (2) referidas anteriormente.

4 Resultados

Para realizar simulações foi desenvolvido um pro-grama em linguagem Visual C++ executado em um computador com CPU AMD athlon XP1700+ PC, com 1,47GHz de velocidade e 240 MB de RAM. Este programa é configurável para que se possa alte-rar os valores dos parâmetros encontrados no fluxo-grama da figura 2. Sua interface permite obter a me-lhor distância percorrida para a montagem de uma determinada PCI e o tempo de processamento da simulação. Ao invés da distância percorrida o pro-grama permite obter o tempo de montagem, supondo-se uma velocidade média para o deslocamento do braço. Uma interface gráfica está disponível mos-trando valores de distâncias percorridas em cada interação. Ao final do programa pode ser obtida uma listagem com a seqüência final de montagem da PCI que foi encontrada como sendo a melhor solução, ou seja, com a menor distância ou tempo de montagem alcançado.

No inicio no programa são informados os valores dos parâmetros acima mencionados e a lista de com-ponentes a serem montados sobre a PCI. Esta lista é lida de um arquivo texto onde constam: a) O tipo de componente; b) Suas coordenadas sobre a PCI; c) A ventosa utilizada; d) A posição do alimentador de onde se capturará o mesmo.

Os testes realizados visaram avaliar a eficácia do algoritmo proposto PROP, principalmente quanto ao tempo de montagem. Foi realizada uma comparação com as seguintes opções: HLC - programa especiali-zado da máquina de inserção modelada; AG - método de pesquisa que usou algoritmo genético - AG (Cra-veiro, 2005); AM - método de pesquisa que utilizou algoritmo memético (Elidelson, 2007).

A PCI utilizada para teste era constituída por 44 componentes. Esses componentes foram distribuídos ao longo de até 30 alimentadores linearmente posi-cionados a frente da máquina da marca JUKI, modelo 2030.

Como critérios de avaliação foram definidos os seguintes termos: QCG – Quantidade de ciclos gera-dos; QC4Cap – Quantidade de ciclos com quatro capturas simultâneas de componentes; QC3Cap – Quantidade de ciclos com três capturas simultâneas de componentes; QC2Cap – Quantidade de ciclos com duas capturas simultâneas de componentes; QC1Cap – Quantidade de ciclos com uma captura de componente; QTVS – Quantidade de trocas de vento-sas simultâneas; QVATC – Quantidade de visitas ao ATC; TM – Tempo de montagem dos componentes; Tempo de processamento para encontrar as soluções;

TP – Tempo de processamento; TV – Tempo total para trocar todas as ventosas;

Nas tabelas 1 e 2 encontram-se os valores com-parativos para os métodos citados. Ressalta-se que os valores mostrados nessas tabelas são valores reais obtidos na máquina JUKI-2030 utilizando-se as se-qüências de montagem propostas pelos métodos anteriormente citados.

Conforme pode ser observado nas tabelas 1 e 2 o método proposto foi o que apresentou o maior valor para o critério QCG, QCG = 19.

Apesar dos três ciclos a mais do método propos-to, também foi ele quem apresentou melhor resultado para o critério QC3Cap, o que também contribuiu para que o método proposto tivesse o melhor desem-penho quanto a critério TM, conforme pode ser visto na tabela 2.

Os resultados mostram que o método proposto foi superior ao algoritmo da própria máquina em 2,4% em relação ao critério TM. Porém, quando se comparam os valores do critério TP, percebe-se que o método proposto teve um desempenho bastante inferior ao algoritmo da própria máquina, porém ficou no mesmo patamar que o resultado obtido pelo método AG.

Tabela 1.Comparação entre métodos.

Método QCG QC4Cap QC3Cap QC2Cap QC1Cap

HLC 16 3 0 10 6

Prop 19 0 4 2 10

AG 12 0 2 8 0

AM 12 0 0 1 0

Tabela 2. Comparação entre métodos.

Método QTVS QVATC TM TP TV

HLC 1 1 22,91s ~30s 1,98s

Prop 0 0 22,35s ~1500s 0

AG 3 1 29,3s ~1560s -

AM 2 1 29,5s - -

Ao avaliar-se o critério TV, observa-se que o

método proposto não solicitou nenhuma troca de ventosa para montar os 44 componentes.

Apesar de não se dispor dos dados relativos ao critério TV, tanto para o método AG, quanto para o método AM, sabe-se que estes algoritmos apresenta-ram necessidade de troca de ventosas durante a mon-tagem. Tal fato não ocorreu com o método proposto em função de sua otimização privilegiar ciclos com pelo menos um componente.

Foram realizadas ainda várias simulações com o método proposto, além de testes práticos usando-se os 44 componentes. Em alguns desses testes os com-ponentes nos alimentadores foram repetidos (três componentes foram distribuídos em dois alimentado-res distintos). No final, os resultados demonstraram

que a heurística baseada no algoritmo de subida em encosta com reinício aleatório apresentou bons resul-tados quanto ao tempo de montagem.

5 Conclusões

O método proposto foi capaz de quebrar o para-digma de que menos ciclos conduziriam a menores tempos de montagem, pois apesar de ter aumentado número de ciclos, montou os componentes em menor tempo dentre todos os métodos analisados.

Contudo, devido a caráter de aleatoriedade do método, o tempo de processamento até a convergên-cia para uma solução satisfatória é um parâmetro que pode oscilar. Ou seja, pode-se obter convergência tanto com poucas iterações, com a rapidez da ordem de poucos segundos, quanto em um número extre-mamente grande de iterações, elevando o tempo de processamento para muitos minutos, como foi o caso para alcançar os resultados ora resumidos nas tabelas 1 e 2.

Agradecimentos

À Superintendência da Zona Franca de Manaus – SUFRAMA, pelo apoio recebido através dos convê-nios 068/069.Agradeço a UFAM. A Sony Brasil S.A. pela oportunidade de realizar os testes em suas insta-lações.

Referências Bibliográficas

Ayob, M., Kendall, G. Real-time Scheduling for Multi Headed

Placement Machine. Proceeding of the 5th IEEE Interna-

tional Symposium on Assembly and Task Planning, Be-

sançon, France, July 10-11,2003.

Burke, E. K., Cowling, P. I., Keuthen, R. The Printed Circuit

Board Assembly Problem: Heuristics Approach for Multi-

Head Placement Machinery. International Conference on Ar-

tificial Intelligence. 2001.

Carvalho, E. Uso de Algoritmos Meméticos na Utilização de

Seqüências de Montagem de Máquinas SMD. Tese de Mes-

trado, UFAM, 2007.

Craveiro, C. H. Otimização do Posicionamento e da Montagem

Automática de Componentes Eletrônicos Através de um Al-

goritmo Genético. Tese de mestrado, COPPE, UFRJ, 2005.

Ho, W., Ji, P. A Hybrid Genetic Algorithm for Component Se-

quencing and Feeder Arrangement. Journal of Intelligent Al-

gorithm, v.15, pp.307- 315, 2004.

Lee, W., Lee, S., Lee, B., e Lee, Y. A Genetic Optimization

Approach to Operation of a Multi Head Surface Machine.

IEICE Trans.Fundamentals, v. E83-A, n. 9, pp. 1748-1756,

Sep. 2000.

Russel, S. Inteligência Artificial, Editora Campus, 2004.

SimRP - SIMULADOR DE REDES DE PETRI FLEXÍVEL COM GERAÇÃO DE CÓDIGO VHDL

MARCOS MELLO, CARLOS HUMBERTO LLANOS, GUILHERME CARIBÉ DO CARVALHO,

GRACO-ENM, Universidade de Brasília Departamento de Eng. Mecânica, Campus Universitário Darcy Ribeiro, Brasilia, DF., Brasil

E-mails: {melo, llanos, gccarval}@unb.

AbstractThis paper describes a CAD tool for Petri Nets (PNs) based on open source, called SimRP. This CAD tool permits to describe and simulate several PNs namely ordinary, temporal, temporized and interpreted types. Besides this, SimRP pro-vides an option to generate VHDL code (a hardware description language), taking a model of an Interpreted PNs. Additionally, SimRP allows several properties verification and conflicts/deadlocks detection. An important feature of SimRP is its flexibility, since users can describe an ordinary PN and afterwards converts it to another type of network as described here. Thus, users can add certain attributes to an ordinary PN in order to represent and simulate a Temporal, Temporized and Interpreted ones. These attributes are easily added/deleted through a graphical interface. The SimRP was developed in client-server architecture in order to guarantee the best usability/portability. Both system installation and configuration are made on a server. In this case, a SimRP user needs only a browser in his/her workstation. Given that the simulator was developed under GPL license, this pro-vides an unlimited use to all of its resources, including source code, allowing any user to use, modify, and adapt it to their needs without license requires.

Keywords Petri Nets, Simulation, Flexibility, CAD. Resumo este trabalho descreve uma ferramenta de CAD para Redes de Petri (RPs) baseada em código fonte aberto, denomi-nada de SimRP. Esta ferramenta de CAD permite descrever e simular vários tipos de RPs: Ordinárias, Temporais, Temporiza-das e Interpretadas. Além do anterior, o sistema possui a opção de gerar código VHDL (uma linguagem de descrição de hard-ware), a partir de um modelo de uma RP Interpretada. Adicionalmente, o SimRP permite a verificação de várias propriedades e detecção de conflitos. Uma característica importante do SimRP é sua flexibilidade, devido a que o usuário descreve facilmente uma RP Ordinária e a pode converter em outro tipo de RP descritas neste trabalho. Desta maneira, o usuário pode mediante a adição de certos atributos a uma RP Ordinária representar e simular uma rede Temporal, Temporizada ou Interpretada, sobre al-gumas restrições. Estes atributos são facilmente acrescentados ou apagados através de uma interfase gráfica. O SimRP foi de-senvolvido em uma arquitetura cliente/servidor para garantir a sua usabilidade/portabilidade. A instalação e configuração do software são feitos no servidor. Neste caso, o usuário necessita só de um navegador em sua estação de trabalho. Devido a que o simulador foi desenvolvido sobre uma licença GPL, o mesmo fornece um uso ilimitado de todos seus recursos, incluindo seu código fonte, permitindo ao usuário modificá-lo e adaptá-lo a suas necessidades sem precisar de uma licença.

Palavras-chave Redes de Petri, Simulação, Flexibilidade, CAD

1 Introdução

A teoria de RdPs é cada vez mais utilizada, devi-do ao seu simples formalismo matemático e sua capa-cidade de simular problemas complexos. A flexibili-dade do seu modelo possibilita que seus conceitos sejam utilizados por outras áreas do conhecimento, não se limitando às áreas de tecnologia (Moraes et AL, 2001). RdPs podem ser aplicadas para sistemas que podem ser caracterizados como concorrentes, assíncronos, distribuídos, paralelos, não-determinísticos, estocásticos (Murata, 1989). Na área de automação RdPs têm ampla aplicabilidade para modelar os sistemas acionados a Eventos Discretos (SED-Sistemas de Eventos Discretos) (Cassandras, 1999, Uzam et al, 1998), onde é muito importante caracterizar, estudar, simular e/ou verificar o compor-tamento do sistema. Um ponto importante na área de automação é determinar se o sistema está livre de conflitos no processo de execução de alguma tarefa determinada.

Uma propriedade importante das RdPs é sua cla-ra e simples representação gráfica, mediante um grafo composto de lugares, transições e arcos. Aplicações

importantes de RdPs podem ser encontradas em dife-rentes áreas como avaliação de desempenho, protoco-los de comunicação, análise de sistemas distribuídos, bancos de dados distribuídos, programação concorren-te e paralela, sistemas tolerantes a falhas, circuitos assíncronos, sistemas operacionais, projeto de compi-ladores, automação de escritórios, linguagens formais, programação lógica, sistemas de manufatura, entre outras (Murata, 1989, Adamski, 2009).

Este trabalho tem por objetivo a construção de uma ferramenta CAD de descrição e simulação de código aberto baseado na licença GPL, denominada SimRP. Esta ferramenta de CAD é capaz de descrever e simular RdPs dos tipos Ordinária, Interpretada, Temporal e Temporizada. Além do anterior, a ferra-menta possui a opção de gerar código em VHDL (uma linguagem de descrição de hardware) a partir do mo-delo de uma rede de Petri interpretada (Adamski, 2000).

Uma característica importante do SimRP é sua flexibilidade, dado que o usuário pode descrever uma RdPs Ordinária e, posteriormente, implementar a sua conversão para um dos outros tipos de redes objeto deste trabalho. Desta maneira, o usuário pode acres-

centar certos atributos para que uma rede de Petri ordinária passe a representar uma rede de Petri Tem-poral (por exemplo). Estes atributos são facilmente acrescentados por intermédio de uma interface gráfica, que permite editar os atributos de RdPs.

Uma estratégia para garantir a melhor usabilida-de/portabilidade do SimRP foi desenvolvê-lo na arqui-tetura de três camadas, onde toda a instalação e confi-guração do sistema é realizada no servidor. Para sua implementação foi usada a linguagem PHP, a qual permite o desenvolvimento de sistemas orientados à WEB. Neste caso, o usuário do SimRP só precisa ter instalado um browser no seu computador ou estação de trabalho. O simulador foi desenvolvido em licença GPL e possibilitará o uso ilimitado de todos seus re-cursos, inclusive do código fonte, permitindo que outras pessoas utilizem, modifiquem e adaptem a suas necessidades, gratuitamente e sem a exigência de licenças.

Por outro lado, existe na comunidade de sistemas digitais o interesse de desenvolver ferramentas de CAD que permitam a geração automática de descri-ções de sistemas/circuitos para Linguagens de Descri-ção de Hardware como VHDL, Verilog, SystemC (Calazans, 2003), entre outras. Por exemplo, dada uma Rede de Petri Interpretada, que modela um con-trolador para um sistema de manufatura, deseja-se a geração automática da sua descrição numa linguagem como VHDL. Neste caso, a descrição inicial do siste-ma é feita em um modelo formal e de mais alto nível de abstração (como é o caso de Redes de Petri), o qual permite resolver e/ou aliviar os problemas clássicos do projeto de sistemas digitais complexos, tais como a validação e verificação formal dos mesmos.

Na literatura são encontrados diversas ferramen-tas para trabalhar com RdP. Por exemplo, o TimeNET (TimeNet, 2009) é uma ferramenta para a edição, simulação e verificação de Redes de Petri Temporiza-das, desenvolvida em C++, compatível com os siste-mas Operacionais Linux SuSE Linux 7.2 Professional, SunOS 5.7-5.9 (Solaris), Sun workstations e Windows XP. O TimeNet é uma ferramenta de uso livre; foi desenvolvida em 1991 pela Technische Universität Berlin. Entretanto, esta ferramenta é limitada à simu-lação das RdPs Temporizadas, não permitindo a simu-lação de outras taxonomias, não disponibilizando seu código fonte.

A ARP (ARP, 2009) é uma ferramenta para a edi-ção, simulação e verificação de RdPs Ordinárias e temporizadas, desenvolvida na linguagem de progra-mação Pascal é compatível com o sistema operacional Windows com MSDOS. O ARP é uma ferramenta de uso livre (software gratuito). Embora esta ferramenta verifique conflitos fatais somente trabalha como RdP Ordináras e Temporais, e sua interfase é pouco amigá-vel.

O PetriSim (PetriSim, 2009) é uma ferramenta para a edição, simulação e verificação de Redes de Petri Ordinárias e Temporizadas, desenvolvida na linguagem de programação Pascal é compatível com o sistema operacional Windows com MSDOS. O Petri-Sim é uma ferramenta de uso livre (software gratuito),

foi desenvolvida no ano 2004 pela laboratório Univer-sity of Malta. Esta ferramenta verifica conflitos fatais e algumas propriedades da RdP como vivacidade. A ferramenta trabalha segundo definições formais de RdPs. Entanto, esta ferramenta só trabalha como RdPs Ordinárias e Temporizadas.

O Visual Objekt Net ++ (Visual Objekt Net, 2009) é uma ferramenta para edição e simulação de eventos contínuos e discretos utilizando-se Redes de Petri Ordinárias e Temporizadas, desenvolvida na linguagem de Object C++, é compatível com o siste-ma operacional Windows 98 ou superior. Esta ferra-menta é de uso livre e foi desenvolvida pela Ilmenau University of Technology. Esta ferramenta verifica conflitos fatais e possui uma interfase amigável. En-tretanto, esta ferramenta é limitada às taxonomias Ordinaria e Temporizada. Adicionalmente, apresenta problemas com respeito às definições formais da RdPs. Por exemplo, permite a simulação de RdPs Ordinárias sem a definição de uma seqüência de dis-paros, quando um conflito estrutural é encontrado, a mesma escolhe de forma aleatória o caminho a percor-rer.

Todas as ferramentas estudadas não permitem a portabilidade do seu código para vários sistemas ope-racionais e apresentam limitações operacionais para o projetista de sistemas. Adicionalmente, a característica de flexibilidade não é parte importante dos projetos das mesmas.

A seção 2 descreve alguns aspectos teóricos bási-cos sobre RdPs aplicados para a implementação deste trabalho. A seção 3 descreve a estrutura da ferramenta implementada SimRP, com detalhes da suas partes estruturais e funcionais. A seção 4 mostra os resulta-dos obtidos usando o SimRP para vários tipos de pro-blemas. Finalmente, a seção 5 mostra as conclusões do trabalho.

2 Aspectos teóricos de RdPs utilizados

Nesta seção serão descritos os principais conceitos de RdPs utilizados neste trabalho. Outros conceitos im-portantes de RdPs podem ser obtidos na literatura especializada. 2.1 Definição de uma RdP

Segundo Murata, 1989, uma RdP é uma quádru-pla definida por R = [P,T,Pre,Post], onde: • P é um conjunto finito de lugares de tamanho n. • T é um conjunto finito de transições de tamanho

m. • Pre : P × T → N é a aplicação de entrada (lugares

precedentes ou incidência anterior), com N sendo o conjunto dos números naturais. Pre representa os lugares que são precedentes a uma transição (conjunto de arcos de entrada a uma transição). A matriz associada à condição Pre é definida por n linhas (representando lugares) e m colunas (repre-sentado transições).

• Post: P × T → N é a aplicação de saída (lugar seguinte ou incidência posterior). O conjunto Post representa as saídas (representados como ar-cos) de uma transição para lugares da RdP. A ma-triz associada à aplicação Post é definida por n li-nhas (representando lugares) e m colunas (repre-sentado transições).

A RdP definida acima, também é conhecida como RdP Ordinária. Para cada “arco” ou elementos dos conjuntos Pre e Post pode ser atribuído um peso refe-rente ao número de recursos necessários para sensibi-lizar uma transição (Cardoso, 1997 e Fernandes 1999). Outras definições sobre o formalismo de RdPs, tais como “Marcação de uma PdP” podem ser obtidas em Cassandras et al, 2009. 2.2 Taxonomia das redes implementadas

Além das RdP Ordinárias neste trabalho são tratadas as seguintes redes: a) RdPs Interpretadas: Estas se caracterizam por in-

troduzirem variáveis às transições da rede, poden-do com isto representar condições e ações existen-tes no sistema. Tais variáveis podem interagir com o ambiente externo, como por exemplo, sensores (em sistemas de automação e de manufatura) (Car-rasco, 2002). Diferentemente das RdPs ordinárias, que para disparar uma transição basta que a mesma esteja sensibilizada, as redes interpretadas para ter uma transição disparada, tem que estar sensibiliza-das e satisfazer a condição que a elas foi atribuída. Com isto, torna-se possível o disparo de várias transições ao mesmo tempo (Cardoso, 1997). Segundo Cardoso, 1997, interpretar uma RdP im-plica em dar sentido concreto a um modelo mate-mático, a RdPs interpretada estrutura-se em duas partes: • Controle: descreve todos os encadeamentos po-

tenciais de eventos e de atividades, este contro-le é descrito pelas Redes de Petri Ordinárias;

• Dados: é a parte operativa do sistema. Descre-ve ao mesmo tempo as estruturas de dados in-ternas ao sistema e os cálculos que são feitos sobre estes dados, sem especificar em quais instantes eles são realizados.

A RdP descreve apenas a parte de controle do sis-tema. A marcação da rede fornece, portanto, o es-tado do controle. O estado do sistema, estado em que a RdPs interpretada é descrita pela marcação associada ao estado dos dados. Logo: • Estado rede interpretada = marcação + esta-

do dados; • Estado dados = estado variáveis internas +

tempo transcorrido. A figura 1 apresenta o modelamento da estação coletora de petróleo onde são incluídas condições para cada uma das transições.

b) RdPs Temporais: para este modelamento a cada transição é associada um par de datas ( ),

onde e indicam a duração mínima e má-xima correspondente de sensibilização da transi-ção do disparo (Cardoso, 1997), como ilustrado na figura 2. e representam datas refe-rentes a um relógio comum, que representa o tempo absoluto de toda a rede. Pode-se associar um intervalo [a,b] a uma transição para represen-tar uma duração a. Se a transição estiver no tempo

, a mesma irá disparar no tempo + a, caso nesta data continue sensibilizada pela transição. Formalmente uma RdP temporal é definida pelo par , onde:

• N é uma RdPs Ordinária; • é uma função que pa-

ra cada transição t uma duração de sensibili-zação. A duração θ(t) é definida como um in-tervalo fechado racional.

Na figura 2.a a transição t1 só está sensibilizada entre os valores temporais (absolutos) um (1) e dois (2). Neste tipo de rede se assume de maneira implícita que existe um relógio único no sistema que define os momentos em que as transições estarão sensibilizadas. c) RdPs Temporizadas: neste modelo cada transição

associa-se a uma duração a fim que a transição seja disparada, logo quando uma ficha chega a um de-terminado lugar em uma data , ela só deixará o lugar após instantes (Moraes, 2001). Formalmente uma RdPs temporizada é definida por par , onde:

• N é uma RdP ordinária; • é a função de duração de dispa-

ro, que associa a cada transição um número racional positivo que descreve a duração do disparo (Cardoso, 1997).

A figura 2.b apresenta um exemplo de uma RdPs temporizada. Neste caso, em um momento dado (t = τ1) um recurso está disponível em P1, sensibilizando t1. Entretanto, este recurso (ficha) só estará disponível em P2 um tempo θ1 depois. Isto pode ser interpretado como um retardo introduzido por t1 na transferência da ficha de P1 para P2. 2.3 Propriedades das RdP tratadas neste trabalho

a) Rede marcada viva: para definir uma RdP marca-

da viva, será definido primeiro o conceito de tran-sição viva. Uma transição t é viva se puder ser sensibilizada por qualquer marcação M’ obtida por uma seqüência de disparo S. Uma RdPs mar-cada somente poderá ser considerada viva se, e somente se, todas as suas transições forem vivas. Logo, esta propriedade assegura que não haja ne-nhum bloqueio gerado pela estrutura da rede (Llo-rens, 2005).

b) RdP pura: uma RdP é considerada pura se e só se não possui transições neutras; sendo que uma transição neutra não altera o estado da RdP (Si-queira, 2004).

Figura 1 – Modelamento da RdPs Interpretada

(a) RdP Temporal (b) RdP Temporizada Figura 2 - Redes Temporais e Temporizadas

c) RdP reiniciável: uma RdP só poderá ser conside-

rada reiniciável se, e somente se, a partir de qual-quer marcação M da rede, seja possível encontrar uma seqüência de disparos capaz de levar ao esta-do inicial. Esta propriedade é utilizada em redes com comportamentos repetitivos (Cardoso, 1997).

d) Conflitos estruturais: duas transições t1 e t2 estão em conflito estrutural se, e somente se, elas têm ao menos um lugar p de entrada em comum. Isto pode ser compreendido como o caso de um lugar estar fornecendo um mesmo recurso a duas tran-sições (Moraes, 2001).

e) Conflito fatal (“deadlock”): Este problema acon-tece quando uma dada seqüência de disparos, a partir da marcação inicial, conduz a uma situação em que não há qualquer transição sensibilizada (Moraes, 2001).

3. Estrutura da Implementação

O simulador foi desenvolvido na linguagem PHP.

Esta linguagem permite a implementação da arquitetu-ra de três camadas (Fowler, 2000) e não precisa da instalação de nenhum software proprietário para seu funcionamento, diferente da linguagem de programa-ção Java que necessita da instalação de Software (má-

quina virtual Java) para seu funcionamento.O servidor que disponibiliza aplicação pode ser instalado e execu-tado em diversos sistemas operacionais, como por exemplo: Linux, Windows, SUN, AIX, entre outros. Será necessária a instalação do serviço de publicação de página Apache (Apache, 2009) com o módulo de interpretação PHP. Além do anterior, faz necessária a instalação do banco de dados MySQL (MySQL, 2009), devido a que esta linguagem é orientada a ban-cos de dados.

O simulador SimRP está projetado para simular as Redes de Petri Ordinárias, Interpretadas, Tempori-zadas e Temporais e gerar códigos VDHL a partir de descrições de RdPs interpretadas. Também é possível verificar propriedades pertinentes ao modelamento de uma Rede de Petri como Vivacidade, Redes Iniciável e Rede não-pura (vide seção 2), além de descobrir con-flitos estruturais e deadlocs (vide seção 2). O simula-dor somente gera código VHDL das Redes de Petri Interpretadas, devido a sua semelhança às Máquinas de Estados Finitos (FSMs, Cassandras,1999). O trata-mento para as demais taxonomias tratadas neste traba-lho é deixado como sugestão para trabalhos futuros. O desenvolvimento do simulador foi dividido em módu-los, possibilitando o desenvolvimento posterior de módulos adicionais.

3.1 Principais Funcionalidades do Sistema O objetivo do sistema é simular o comportamento

de RdPs para os tipos propostos anteriormente e gerar código VHDL do comportamento de uma Rede de Petri Interpretada. Para que este objetivo fosse alcan-çado, foram implementadas as seguintes funcionalida-des: a) Inserir Rede de Petri: esta funcionalidade é res-

ponsável por definir o modelamento de uma Rede de Petri no sistema, descrevendo seu comporta-mento e atribuindo uma taxonomia quando for o caso.

b) Editar Taxonomia: esta funcionalidade possibilita que seja atribuída uma taxonomia a uma Rede de Petri Ordinária, caso não tenha sido definido no momento do modelamento na funcionalidade In-serir Rede de Petri.

c) Visualizar Rede de Petri: esta funcionalidade permite a visualização do modelamento da rede, e com isto, poder analisar se a mesma não foi mo-delada de modo equivocado.

d) Editar Rede de Petri: esta funcionalidade possibi-lita que uma Rede de Petri, já modelada no siste-ma, possa ser alterada ou apagada.

e) Definir Seqüência de Disparos: esta funcionali-dade permite que seja definida uma seqüência de disparo para uma Rede de Petri Ordinária.

f) Verificar Propriedades: esta funcionalidade pos-sibilita verificar se a Rede de Petri é iniciável, vi-va, não-pura ou se existe a presença de conflitos estruturais e deadlocks.

g) Gerar Código VHDL: esta funcionalidade permite a geração de um código VHDL através do mode-lamento de uma Rede de Petri Interpretada.

h) Simular Rede de Petri: esta funcionalidade possi-bilita acompanhar a simulação de uma RdP mode-lada no sistema de acordo com sua taxonomia. Nesta funcionalidade também é possível verificar a presença de deadlock.

3.2 Algoritmo base para a simulação da RdPs

Para a implementação do SimRP foi necessária a

implementação do algoritmo descrito na figura 3. Este algoritmo serviu de base para a implementação da simulação de todas as RdPs abordadas neste trabalho. O conceito de árvore de alcançabilidade (Mores, 2001) foi usado devido à necessidade de simular passo a passo cada marcação, mantendo o controle da se-qüência de disparo executada para alcançar uma nova marcação. A própria característica da teoria de árvore de alcançabilidade permitem determinar quais e quan-tas vezes cada transição foi disparada. Neste caso a árvore de alcançabilidade é implementada parcialmen-te tendo em conta as pré e pós-condições. O SimRP utiliza-se do banco de dados para armazenar todas as características do modelos RdPs utilizados no SimRP. Isto diminui o desempenho do simulador, contudo permite o armazenamento dos atributos do modelo de uma maneira flexível (característica impor-tante para simular diferentes tipos de RdPs). Utilizan-

do o conceito de Banco de Dados Relacionais (Rama-krishnan, 1998), foi possível implementar a flexibili-dade, no contexto de representar diferentes modelos de RdPs. Isto é possível devido à possibilidade de se associar a um modelo geral uma ou mais característi-cas referentes as RdPs Interpretadas, Temporais ou Temporizadas

Para o desenvolvimento da simulação das RdPs Interpretadas foi utilizado o algoritmo descrito na figura 3, associado a campos que definem as condi-ções associadas às transições. Neste caso, o número de fichas ou recursos de uma certa RdPs é limitada a, no máximo, uma por lugar. Para descrever uma condição, podem-se utilizar os operadores condicionais E, OU e Não. A utilização do Java Script no desenvolvimento do simulador permite que os valores das condições possam ser alterados no momento da simulação.

No caso do desenvolvimento da simulação das RdPs com representação de tempo, foram utilizados os conceitos descritos na seção 2, associado ao algoritmo descrito na figura 3. Neste caso, o Java Script foi utili-zado para garantir a atualização da tela a cada segundo (não foi possível definir um tempo menor, pois não seria possível visualizar as alterações na RdPs).

Para a geração dos códigos VHDL foi utilizado um template de um código VHDL para implementa-ção de máquinas de estados. Para fazer um programa na linguagem VHDL, se fez necessária à criação de campos como: tipo de dados de entrada e saída na definição de uma RdPs interpretada.

3.3 Verificação de propriedades e conflitos no SimRP

As propriedades verificadas no SimRP são: rede

marcada viva , RdP pura, RdP reiniciável. Além do anterior o SimRP detecta conflitos estruturais e fatais (deadlocks). A verificação das propriedades foi desen-volvida utilizando o mesmo algoritmo, onde o simu-lador percorre toda a RdPs e analisa as propriedades descritas anteriormente. Para a verificação da propri-edade rede marcada viva foi utilizado o algoritmo apresentado na figura 3, através do mesmo o simula-dor percorre toda a RdP verificando se todas as mar-cações são acessíveis a partir de uma marcação inicial. Deve-se ter em consideração que a RdP será viva para uma seqüência de disparo S (para o caso de RdP ordi-nárias). Para o caso das outras taxonomias suportadas pelo SimRP esta propriedade é verificada pelo com-portamento da RdP em tempo de simulação. A propriedade RdP Pura foi verificada a partir do algoritmo mostrado na figura 3, que percorre toda a RdP verificando se nenhum lugar tem as matrizes Pre igual Pos (ver definições em Moraes, 2001). A propri-edade RdP Reiniciável foi verificada de maneira similar, percorrendo a RdP e verificando se uma si-mulação retorna a sua marcação inicial. Para a verifi-cação do conflito estrutural, o sistema verifica se al-gum lugar compartilha o mesmo recurso com duas ou mais transições. Para a verificação do deadlock, o sistema verifica se a partir de uma seqüência de dispa-ros e de uma marcação inicial, conduz a uma situação

em que não há qualquer transição sensibilizada (ver seção 2).

Figura 3. - Algoritmo base do simulador

4 Resultados obtidos 4.1 Simulação de RdPs Ordinárias

Para exemplificar a simulação de uma RdPs Or-dinária, é utilizado o exemplo ilustrado na figura 4.

Figura 4. -Modelamento de RdPs Ordinária

Neste exemplo, podemos observar uma rede com

cinco lugares: P1, P2, P3, P4, P5 e com quatro transi-ções: T1, T2, T3 e T4, a marcação inicial desta rede é M = { 1 0 0 0 0 }.

Na figura 5 pode ser observada a simulação desta rede após ter sido modelada no SimRP, para esta si-mulação foi definida a seguinte seqüência de disparo: S = { T1,T2,T3,T4 }. A figura 5.a apresenta a RdPs na sua marcação inicial e a figura 5.b após o primeiro disparo. Pode ser observado que o simulador permite executar uma seqüência de disparo passo a passo (ob-servar o botão para selecionar esta opção), assim como definir a seqüência de disparo (verificar o botão para esta tarefa na figura 5).

4.2 Verificação das Propriedades

Analisando as propriedades referentes ao mode-

lamento da RdPs da figura 4, pode-se observar a exis-tência de um conflito estrutural e fatal (deadlock), como observado na figura 6. Neste caso, a ferramenta permite a deteção de um deadlook como mostrado na mesma figura (em P4).

4.3 Simulação de uma RdPs Temporal

Na figura 7.a pode ser observado o modelamento de uma RdPs Temporal. Pode ser verificada a possibili-dade de inserção e edição de atributos de temporiza-ção para este tipo de rede. Os atributos podem ser editados escolhendo o lugar e apertando o botão “adi-cionar”. Para efeito de edição pode ser usado o botão “apagar”. 4.4 Simulação de uma RdPs Temporizada

Na figura 7.b. podemos observar a simulação de

uma RdPs Temporizada. Pode ser observada a possibi-lidade de se inserir um atributo temporal, a partir da escolha do lugar (P2 no exemplo da figura). Da mes-ma maneira do exemplo da RdP Temporal o editor da ferramenta permite adicionar, alterar e remover os atributos da RdP.

4.5 Exemplo para uma RdP interpretada e a geração

automática de código VHDL

(a) Descrição da RdP da figura 4 (b) Estado do SimRP a partir da execução de uma transição

Figura 5- Simulação da RdPs Ordinária

Figura 6 - Verificação das Propriedades

(a) Rede temporal (b) Rede Temporizada Figura 7 – Simulação de RdPs temporais e temporizadas

Para exemplificar a simulação de uma RdP Inter-

pretada (vide seção 2) e a geração de código VHDL (Calazans, 2003) será utilizado parte de um exemplo extraído de Moraes, 2001. Este exemplo descreve o comportamento de um controlador manual de dois portões automáticos.

Para ilustrar este comportamento, a figura 8.a a-presenta o descrição deste controlador através de uma RdP Ordinária. Para melhor entendimento serão utili-zadas as siglas LD – Chave geral de energia ligada,

LDO – Módulo automático desativado, OEA – Co-mando portão externo abrir, OEF - Comando portão externo fechar, OIA - Comando portão interno abrir, OIF - Comando portão interno fechar, MEA – Motor externo abrindo, MEF - Motor externo fechando, MIA - Motor interno abrindo e MIF Motor externo fechan-do.

(a) Exemplo modelado com RdP Ordinária (b) Exemplo modelado com RdP Interpretada

Figura 8- Exemplo de modelamento de controlador em RdPs (Moraes, 2001)

(a) Modelamento no SimRP (b) Resultados da síntese do código VHDL ge-

rado pelo SimRP Figura 9- Resultados obtidos para o exemplo do controlador

Este mesmo exemplo pode ser simulado utilizan-

do uma RdP Interpretada. A figura 8.b apresenta este exemplo de controlador descrito em uma RdP Inter-pretada. Nesta figura podemos observar que os lugares (OEA, OEF, OIA e OIF) foram associados a uma condição nas transições correspondentes, que no caso deste exemplo será verdadeira se o valor for igual ao valor 1 (vide figura 8.b).

Neste caso, a transição OEA estará sendo habili-tada e o recurso “ficha” será adicionada em MEA, representando o motor do portão externo abrindo. A RdP Interpretada da figura 8.b foi obtida a partir da RdP previamente editada no SimRP. Neste caso, a edição foi realizada eliminando os lugares respectivos e atribuindo as condições (atributos) às transições.

A figura 9 mostra a RdP do exemplo da figura 8, onde primeiro foi editada a RdP ordinária e depois foram acrescentados atributos para gerar a RdP inter-pretada (vide figura 9.a). Pode ser observado o botão para a geração do código VHDL correspondente ao modelo descrito do controlador. Na figura 9.b é mos-trado o resultado da síntese do controlador, a partir do código VHDL gerado pela ferramenta. A síntese foi obtida usando a ferramenta Quartus II (Altera, 2009).

Os resultados da síntese fazem referencia aos re-

cursos alocados no dispositivo alvo do circuito (um FPGA da Altera), o que mostra que o código gerado pelo SimRP e sintetizável.

5 Conclusões

O simulador de RdPs foi desenvolvido com a fi-

nalidade de ser uma ferramenta CAD de descrição e simulação de código aberto. Esta ferramenta de CAD é capaz de descrever e simular redes de Petri do tipo ordinária, interpretada, temporal e temporizada. Além do anterior, a ferramenta possui a opção de gerar có-digo em VHDL (uma linguagem de descrição de hardware) a partir do modelo de uma rede de Petri interpretada (Du, 2009). Para facilitar o uso e não ser restritiva em relação a um determinado sistema opera-cional o simulador foi desenvolvido na arquitetura de três camadas, onde a instalação e configuração do sistema são realizadas no servidor. O acesso à aplica-ção por parte dos clientes é feito através de um brow-ser de internet.

O SimRP alcançou os objetivos propostos quanto à flexibilidade (não observada em outras ferramentas de simulação de RdPs estudadas) e a possibilidade de gerar código VHDL para o caso de descrições de controladores usando RdPs. Para a implementação do SimRP foram tidas em conta as definições formais das RdP dadas na literatura estudada. No processo de estudo de outros simuladores pode ser observado que nem sempre eram seguidas as definições teóricas de RdP. Por exemplo, o Visual Objekt Net++ (que simula RdP ordinárias e Temporais) no caso de se detectar um conflito estrutural o simulador dispara aleatoria-mente uma das transições sensibilizadas.

Os autores não encontraram nenhum simulador com as características de formalismo, flexibilidade e capacidade de converter RdPs para outras definições como é feito do SimRP. Adicionalmente, a possibili-dade de gerar códigos (VHDL, no caso apresentado) permite verificar que este tipo de conceito pode con-verter uma ferramenta de CAD em uma ferramenta CASE. Esta propriedade do SimRP pode ser estendida para gerar descrições em outras linguagens como C ou JAVA.

Referências Bibliográficas

Adamski, M., İ. Koç, B., Gelen, G., Aksebzeci, B. H. Asynchronous implementation of discrete event controllers based on safe automation Petri nets. The International Journal of Advanced Manufac-turing Technology, Springer, 2009, 4 (5-6).pp. 595–612.

Adamski, M., Monteiro JL. From interpreted Petri Net Specification to reprogrammable Logic Controller Design. IEEE International Symposium on Indus-trial Electronics, Puebla, Mexico, 2000. pp. 13-19.

Apache, 2009. http://httpd.apache.org/docs/2.2, aces-sado em março, 2009.

Du, D., Liu, Y., Guo, X., Yamazaki K., and Fu-jishima, M. Study on LD-VHDL conversion for FPGA-based PLC implementation. The Interna-tional Journal of Advanced Manufacturing Tech-nology, Springer, 2009, 40 (11-12), pp. 1181-1190.

ARP.http://www.eng.uerj.br/~ldmm/controle%20de%20processos/manual-pt.html, acessada em 05/06/2009.

Altera. Quartus II, WWW.altera.com. Acessada em março de 2009.

Calazans , Ney Laert Vilar, Alessandro Noriaki Ide, Edson Ifarraguirre, Moreno, Taciano Ares Rodol-fo e Fernando Gehm Moraes, Tutorial e Diretivas para Captura de Projeto, Validação e Prototipação de Módulos de Hardware Descritos em SystemC, Faculdade de Informática – PUCRS, 2003.

Cardoso , J. e R. Valente, Rede de Petri, Editora da UFSC, 1997.

Carrasco, Eliana, Estruturas Generalizadas para Con-troladores Lógicos Modeladas mediante Redes de

Petro. Universidad Nacional de Colombia sede Medellín, 2002.

Cassandras, Chistos G., Stéphane Lafortune, Intro-duction to Discrete Event Systems, Ed. Springer, New York, 1999.

Fowler, Martine e Kendall Scott, UML Essencial, Um breve guia para linguagem-padrão de modelamen-to de objetos, Segunda Edição, Ed. Bookman, Rio de Janeiro, 2000.

Morais, Cícero Couto e Plínio de Lauro Castrucci, Engenharia de Automação Industrial, Editora LTC, Rio de Janeiro, 2001.

Llorens, Marisa e Oliver, Javier, Redes Reconfi-gurables Controladas por Marcado: Redes de Petri con Câmbios Dinámicos Estructurales, UPV e Universidad de Valladolid eUniversidad de Sala-manca, 2005

Murata, Tadau, Petri Nets: Properties, Analysis and Applications, Proceeding of the IEEE, vol. 77, No 4, April 1989.

MySQL, 2009. http://dev.mysql.com/doc/refman/4.1/pt/index.html, acessado em março 2009.

Siqueira, Sérgio Amadeu, Software Livre: a luta pela liberdade do conhecimento, Editora Fundação Perseu Abramo, 2004.

Uzam M., Jones, AH, Discrete event control system design using automation Petri Nets and their Lad-der diagram implementation. The International Journal of Advanced Manufacturing Technology, Springer, 1998, 14 (10), pp. 716-728.

T.Murata, Petri Nets: Properties, Analysis and Appli-cations, Proceedings of the IEEE, 77(4)541-580, April de 1989.

TimeNet. http://pdv.cs.tu-berlin.de/~timenet/, acessa-da em 05/06/2009.

Objekt Net. Manual do Visual Objekt Net ++. , aces-sada em 05/06/2009.

PetriSim. http://staff.um.edu.mt/jskl1/petrisim/htmlman/manual5.html#c42, acessada em 05/06/2009.

Ramakrishnan, R., Database Management Systems. McGraw-Hill. 1998.