s:

Transcrição

1 GERAÇÃO AUTOMÁTICA DE AUTÔMATOS TEMPORIZADOS PARA DIAGRAMAS DE BLOCOS FUNCIONAIS Leandro Dias da Silva, Luiz Paulo de Assis Barbosa, Kyller Gorgônio, Angelo Perkusich, Antonio Marcus Nogueira Lima Universidade Federal de Alagoas Instituto de Computação Maceió, Alagoas Universidade Federal de Campina Grande Centro de Engenharia Elétrica e Informática Laboratório de Sistemas Embarcados e Computação Pervasiva Campina Grande, Paraíba s: leandro@dee.ufcg.edu.br, luizpaulo@dee.ufcg.edu.br, kyller@dee.ufcg.edu.br, perkusic@dee.ufcg.edu.br, amnlima@dee.ufcg.edu.br Abstract Safety Instrumented Systems (SIS) are designed to prevent accidents, avoid undesirable situations and guarantee the continuous operation of production systems such as oil and gas facilities. In this scenario, it is important to be able to validate the SIS implementation against its specification in order to increase the reliability of the system. In this work a technique to improve the dependability of SIS is introduced. A method to obtain a timed automata from a Function Block Diagram is presented and applied to a case study provided by Petrobras (Brazilian oil company). Keywords Safety Instrumented Systems, FBD, Timed Automata. Resumo Sistemas Instrumentados de Segurança são projetados para prevenir acidentes, evitar situações indesejáveis e garantir a operação contínua de sistemas de produção tais como os de petróleo e gás. Neste cenário é importante poder validar a implementação do SIS contra sua especificação para aumentar a confiabilidade do sistema. Neste trabalho é introduzida uma técnica para melhorar a confiabilidade dos SIS. Um método para obter automaticamente um autômato temporizado a partir de Diagramas de Bloco Funcionais (FBD, do inglês Function Block Diagram) é apresentado e aplicado a um estudo de caso provido pela Petrobras. Palavras-chave Sistemas Instrumentados de Segurança, FBD, Autômatos Temporizados. 1 Introdução Na operação de plantas de processamento de óleo e gás é necessária a utilização de um sistema de segurança para prevenir acidentes, evitar a ocorrência de situações indesejadas e garantir a operação contínua da planta. Para isso, são utilizados os Sistemas Instrumentados de Segurança (SIS). O SIS funciona de forma independente do controle supervisório, e está um nível acima do mesmo na hierarquia de segurança e controle. Um conjunto de sensores e atuadores, mais um Controlador Lógico Programável (CLP) de segurança formam o sistema. Dos sensores vêm as informações que serão processadas pelo código executando no CLP. As saídas produzidas são aplicadas aos atuadores que realizarão as ações de controle. O ciclo de desenvolvimento de um SIS é mostrado na Figura 1. Primeiramente a companhia de óleo gera um conjunto de requisitos na forma de uma matriz de causa e efeito e algum texto adicional explicando coisas que não estão presentes na tabela e detalhando alguns procedimentos que devem ser realizados. A partir desses requisitos um conjunto de diagramas lógicos ISA 5.2 (Ins, 1992) é gerado. Todos esses artefatos juntos constituem a especificação do sistema. Finalmente, uma equipe especializada em automação industrial é encarregada de realizar o desenvolvimento do sistema baseado na especificação. O código é então gerado para ser executado em um CLP. Para validar o código desenvolvido é realizado um Teste de Aceitação de Fábrica (TAF). O TAF é realizado por engenheiros da companhia de óleo da seguinte maneira: as entradas da tabela de causa e efeito são reproduzidas em campo e o comportamento do SIS para essas entradas é então comparado com o comportamento especificado. Se o comportamento corresponde ao especificado o código é aceito, caso contrário, a empresa responsável pelo desenvolvimento do código realiza as correções necessárias. Figura 1: Processo de desenvolvimento do SIS Um aspecto importante do ciclo de desenvolvimento descrito é que a empresa contratante não tem nenhuma garantia formal de que o código recebido corresponde a especificação fornecida. Além disso, no caso da existência de erros o processo de desenvolvimento torna-se bastante lento, pois os erros só são detectados no TAF que é realizado no produto final, ou seja, na última etapa do desenvolvimento. O TAF é um processo

2 que despende muito tempo, geralmente dias ou mesmo semanas, devido as temporizações envolvidas no controle dos processos e a grande quantidade de entradas a serem testadas. Ainda existe a possibilidade de que erros permaneçam ocultos no código mesmo após a realização do TAF. A existência de uma metodologia que auxilie no processo de desenvolvimento, permitindo que os erros sejam detectados ainda durante a fase de desenvolvimento, e que proporcione um meio de realizar a validação do código com uma maior quantidade de testes e em tempo reduzido, será de grande valia no processo de desenvolvimento de um SIS. Baresi utiliza redes de Petri temporizadas de alto nível (HLTPN) para modelar diagramas de blocos funcionais (FBDs) (Baresi et al., 2000). A planta da fábrica é descrita por um conjunto de equações diferenciais, enquanto a lógica de controle é provida através de FBDs. As HLTPN são obtidas com o objetivo de validar o projeto e gerar o código fonte do sistema. O foco principal deste trabalho é na geração automática de autômatos temporizados, a partir de FBDs para realizar testes de conformidade automáticos. Os diagramas ISA 5.2 servem como especificação do controle que deve ser implementado para parte de um SIS presente nas instalações da Petrobras. Os programas em FBD correspondem a implementação do controle descrito nos diagramas. O restante deste trabalho está organizado da seguinte forma. Na Seção 2 os autômatos temporizados são informalmente introduzidos. Na Seção 3 a linguagem FBD é apresentada. Na Seção 4 a metodologia para geração automática dos autômatos é descrita. Na Seção 5 são discutidas as conclusões e sugestões para trabalhos futuros. 2 Autômatos Temporizados Um autômato temporizado é uma máquina de estados finitos estendida com variáveis de relógio que são avaliadas como números reais (Alur e Dill, 1994). Todos os relógios declarados progridem de forma síncrona. Na ferramenta Uppaal os modelos são estendidos através do uso de variáveis inteiras limitadas (Behrmann et al., 2004). Assim como em linguagens de programação, tais variáveis podem ser lidas, escritas e submetidas a operações aritméticas. Um estado do sistema é definido de acordo com as localidades do autômato, as restrições de relógio, e os valores das variáveis discretas. Todo autômato pode executar uma ação separadamente ou sincronamente com outro autômato, atingindo dessa forma um novo estado. Na Figura 2(a) um autômato temporizado que modela o funcionamento de uma lâmpada é mostrado. A lâmpada tem três possíveis estados: desligada, fraco e forte. Cada um desses estados é modelado por uma localidade no autômato, sendo cada localidade representada por um círculo. Se o usuário apertar o botão, gerando o evento press, a lâmpada é acesa. Se o usuário apertar o botão novamente, a lâmpada será desligada. Entretanto, se o usuário apertar o botão duas vezes seguidas, como em um duplo clique no mouse de seu computador, a lâmpada será acesa e ficará mais forte. Note que o estado do autômato é determinado pela localidade ativa, e pelos valores das variáveis envolvidas. No caso o relógio y que é usado para determinar se o usuário apertou o botão duas vezes seguidas (y < 5) ou não (y 5). O modelo do usuário, que nesse caso representa o ambiente em que o sistema é executado, é mostrado na Figura 2(b). O usuário pode pressionar o botão a qualquer instante de tempo ou simplesmente não pressioná-lo. desl y=0 y>=5 fraco (a) Lâmpada press! (b) Usuário y<5 forte Figura 2: Uma lâmpada muito simples Observe que os autômatos das Figuras 2(a) e 2(b) são sincronizados através do evento press que é gerado pelo usuário. O envio de evento é modelado adicionando um ponto de exclamação ao nome do evento (press!) e o recebimento adicionando uma interrogação (). Observe que o envio e recebimento ocorrem de forma síncrona. Em outras palavras, quando o usuário pressiona o botão (press!) a lâmpada imediatamente muda de estado (). Apesar de bastante simples, o exemplo acima introduz a sintaxe e a semântica dos autômatos temporizados. 3 Diagramas de Blocos Funcionais A linguagem gráfica FBD usa blocos funcionais para representar as ações que devem ser realizadas. Esses blocos podem ser escolhidos dentro de um conjunto pré-definido pelo fabricante ou construídos pelo usuário de acordo com sua necessidade. Um bloco funcional possui um conjunto de parâmetros de entrada e saída, um conjunto de variáveis internas e um algoritmo que é executado quando é solicitada a execução do bloco. Esse algoritmo define a relação entre os valores correntes dos parâmetros de entrada, de saída e das variáveis internas. A presença de variáveis internas faz com que o bloco funcional possua um estado associado a cada uma de suas instâncias. Outra característica a ser destacada é que a correspondência entre os valores dos parâmetros de entrada

3 e saída não é unívoca como em uma função, já que os valores das variáveis internas são considerados no cálculo dos parâmetros de saída. Um programa FBD pode ser visto de maneira análoga a um diagrama elétrico, ou seja as conexões mostram o caminho dos sinais entre os blocos que formam a rede. A linguagem FBD é usada geralmente para descrever soluções que envolvem malhas de controle e lógica. O padrão define que o fluxo dos sinais em um FBD ocorre da esquerda para a direita, das saídas de funções ou blocos funcionais (FBs do inglês, Function Blocks) para as entradas de outras funções ou FBs. A negação dos sinais é feita de forma semelhante aos diagramas lógicos, pela presença de um círculo na entrada ou saída dos FBs, ou pelo uso do bloco NOT. O padrão define também uma forma de controlar a execução das funções explicitamente através de um sinal booleano ENO que adquire o valor verdadeiro ao final de uma execução bem sucedida da função. A saída ENO de uma função é ligada na entrada EN da função seguinte, que por sua vez, só executa quando o valor presente em EN for verdadeiro. Os FBDs podem conter caminhos de realimentação e para tratar esses casos o padrão define que o valor do sinal dentro do caminho de realimentação deve ser guardado após o final de uma execução da rede, para ser utilizado como valor de entrada na próxima execução. O padrão define também que a ordem de avaliação dos blocos envolvidos na realimentação seja definida explicitamente, mas o método para se realizar isso não é mencionado. Algumas regras de avaliação para um programa FBD devem ser observadas para garantir a consistência dos dados trocados entre os blocos. Nenhum elemento deve ser avaliado a menos que os valores de todos os sinais conectados às entradas do mesmo estejam disponíveis. A avaliação de um elemento não está completa até que os valores de todas as saídas produzidas pelo elemento tenha sido determinados. A avaliação de uma rede FBD não esta completa até que todas as saídas de todos os elementos tenham sido determinadas. Finalmente, quando existe transferência de dados de uma rede para outra, todos os valores vindos da primeira rede devem ser produzidos pela mesma avaliação da rede. A segunda rede só deve iniciar sua avaliação, após todos os sinais de entrada vindos da primeira rede estarem disponíveis. 4 Extração de Autômatos Temporizados de FBD A metodologia descrita neste trabalho é baseada na metodologia descrita em (de Assis Barbosa et al., 2007) e consiste na especificação de templates para geração automática de automatos temporizados. No caso especifico deste trabalho abordamos a linguagem FBD, enquanto que no trabalho anterior foi desenvolvida a metodologia para ISA 5.2. Ambos modelos são utilizados para geração e execução automática de teste de conformidade utilizando a ferramenta TRON 1. Desta forma, a metodologia consiste em extrair automaticamente automatos temporizados da especificação (ISA 5.2) e da implementação (FBD) e confrontá-los via testes de conformidade para garantir formalmente a conformidade entre eles. Para formar o exemplo de aplicação e como base para o estudo da geração dos autômatos a partir do código FBD, foi escolhida uma parte do controle utilizado em uma unidade de geração de hidrogênio para ser implementada utilizando a linguagem FBD. O diagrama descrevendo o controle escolhido para implementação é mostrado na Figura 3. O programa mostrado na Figura 3 é formado apenas por blocos funcionais pré-definidos para a plataforma alvo. Apenas elementos lógicos, temporizados e células de memória são representados. As conexões lógicas presentes nos diagramas, são representadas por conexões diretas entre os elementos no programa. Não são utilizadas funções matemáticas, blocos definidos pelo usuário, ou variáveis que não sejam do tipo Booleano. No programa a ordem de avaliação dos elementos é determinada explicitamente por um número que é atribuído a cada bloco que faz parte da descrição do programa. As variáveis de entrada e saída são associadas à regiões de memória física. O tempo de execução do programa é configurável e deve corresponder a um valor entre 200ms no mínimo e 500ms no máximo. 4.1 Desenvolvimento do Modelo O conjunto de elementos modelados consiste dos elementos de lógica Booleana (AND e OR), elementos com memória (flip-flops) e elementos temporizados. Uma descrição detalhada do desenvolvimento e do procedimento para geração automática para os modelos para ISA 5.2 pode ser encontrada em (de Assis Barbosa et al., 2007). O modelo para FBD é constituído por quatro tipos de autômatos. Os dois primeiros são modelos do sistema, que descrevem os flip-flops, os elementos temporizados e os elementos lógicos, e modelos do ambiente, que descrevem as entradas físicas. Os dois últimos estão relacionados com o controle da ordem de avaliação dos blocos que formam o programa. Estes autômatos são responsáveis pelo cálculo da convergência individual de cada bloco e da convergência da rede de blocos como um todo. Por motivos de limitação de espaço os autômatos para leitura das variáveis de entrada e para escrita das saídas serão omitidos. Além disso, apenas os modelos de flip-flops e temporizadores DI serão ilustrados e discutidos. 4.2 Detalhamento do Controle de Execução do Modelo O ciclo de varredura do CLP é dividido em três etapas. Leitura dos sensores, execução do código 1

4 Figura 3: Especificação do controle e escrita das variáveis de saídas para os atuadores. Buscando reproduzir esse comportamento, o modelo do ambiente determina os instantes da geração dos novos valores para as variáveis de entrada, o que corresponde ao momento da leitura dos sensores realizada no início de cada ciclo de varredura. Além disso, monitora o tempo de processamento desses valores pela rede de autômatos do modelo, para não exceder o tempo programado. E, ao final do processamento, libera a geração dos eventos de saída, o que corresponde a escrita das variáveis que acionam os atuadores no processo físico. Os valores que são atribuídos às variáveis de entrada são escolhidos não deterministicamente entre os valores verdadeiro e falso, de forma a reproduzir o comportamento mais permissivo possível para o ambiente. Para gerar o modelo do ambiente são necessários quatro templates. Um que modela o ciclo de varredura, um para controlar a ordem na qual as variáveis são atualizadas, um para as variáveis e outro para receber os eventos de saída. O autômato do ciclo de varredura principal, mostrado na Figura 4, tem a função de garantir a ordem de avaliação correta dos blocos, controlar o tempo gasto para execução do modelo do programa e garantir que toda a rede modelada convergiu. Para garantir a ordem de avaliação, para cada ciclo secundário, é criada uma variável que habilita ou não a execução do ciclo. Ainda, para cada ciclo secundário é criada uma variável que indica o término da execução dos autômatos que modelam o bloco associado àquele ciclo. As variáveis que habilitam a execução dos ciclos são denominadas enable scan[blk] onde blk 0, 1, 2, 3... é um índice que identifica o bloco associado àquele ciclo seguindo a ordem de avaliação. O índice zero é utilizado para identificar o ciclo principal e os demais para os ciclos secundários. As variáveis que indicam a convergência dos ciclos são denominadas CN[blk]. update! CN[blk]==true t=0, write_out() Waiting read_in() Executing t<tscan synchro[blk]! CN[blk]==false && t>=0 && t<tscan && enable_scan[blk]==true CN[blk]=control() Figura 4: Autômato do ciclo de varredura principal A cada início de execução do ciclo principal, a variável que habilita a execução do primeiro ciclo secundário seguindo a ordem de avaliação, assume o valor verdadeiro, enquanto às demais variáveis é atribuído o valor falso. A função control() monitora a variável que indica a convergência do primeiro bloco e, de acordo com o valor dessa variável, habilita o próximo ciclo secundário que deve executar. Isso é feito de forma seqüencial para todos os ciclos secundários do modelo. A cada ciclo secundário só é permitido executar uma vez por execução do ciclo principal. A convergência da rede é atingida quando todas as variáveis que indicam as convergências dos ciclos secundários possuírem o valor verdadeiro. Uma vez terminada a execução do programa os valores produzidos são escritos no array out[], que representa o registrador de saída do CLP, pela função write out(). Após isso, é permitido aos autômatos do ambiente executarem, produzindo os novos valores para as variáveis de entrada. Os valores das entradas são guardados no array in[], que modela o registrador de entrada do CLP, e serão copiados para o array f lags[], pela função read in(). O array flags[] guarda os valores das variáveis do modelo durante a execução da rede de autômatos.

5 O autômato do ciclo de varredura secundário, mostrado na Figura 5, possui uma guarda que testa o valor da variável que habilita a sua execução, e o valor da variável que indica a sua convergência. Isso é feito, para garantir que a execução inicia no momento determinado pelo ciclo principal e para evitar que o mesmo bloco avalie duas vezes na mesma execução do programa. A função start() é chamada no momento que o controle é passado para o ciclo secundário. Essa função evita a concorrência de execução entre os ciclos de varredura alterando o valor da variável que habilita a execução do ciclo principal para falso. A função control() calcula a convergência dos elementos que formam o bloco associado ao ciclo secundário. Ao final da execução do ciclo secundário o controle é devolvido ao ciclo principal através da chamada à função release(), que atribui o valor verdadeiro a variável que habilita a execução do ciclo principal. CN[blk]==true release() Waiting synchro[0]? enable_scan[blk]==true && CN[blk]==0 start() Executing synchro[blk]! CN[blk]==false && enable_scan[blk]==true CN[blk]=control() Figura 5: Autômato do ciclo de varredura secundário 4.3 Os Autômatos do Ambiente Para o ambiente temos os templates Scan Cycle, Env Controller, Env Signal e Env Event Receptor. Esses templates são utilizados como base para instanciação dos autômatos que desempenham o controle do modelo, desde a substituição do ambiente físico, até o controle da execução dos autômatos do modelo da implementação a ser testada (IUT, do inglês Implementation Under Test). O autômato do ciclo de varredura, Scan, é instanciado a partir do template Scan Cycle, mostrado na Figura 6. O autômato Scan, é responsável por reproduzir o comportamento do ciclo de varredura do CLP. Ela gera rótulos de sincronização que irão sincronizar com autômatos tanto do ambiente quanto do sistema, controlando o momento em que estes autômatos devem iniciar a execução de suas transições. O ciclo inicia-se pela geração dos valores das entradas, seguido pela execução dos autômatos do sistema e termina com a geração dos rótulos de sincronização de saída. Os rótulos synchro! e end! são utilizados respectivamente para sincronizar a execução e informar o fim da mesma para autômatos dos elementos temporizados do sistema. O rótulo write! sincroniza com o autômato do sistema que gera os rótulos de saída, iniciando essa operação. O rótulo update! CN==true CN=false write! CN==true CN=false, t =0 Writing end! CN==true && t==tscan Waiting start? read_in() synchro! CN=control() Executing t<=tscan synchro! CN==false && t>=0 && t<=tscan CN=control() Figura 6: Template Scan Cycle para o ciclo de varredura update! sincroniza com o autômato responsável pela geração dos novos valores para as variáveis de entrada, iniciando essa operação por parte do ambiente. O rótulo start! sincroniza com o autômato Scan iniciando uma nova execução da rede de autômatos. Os canais, synchro, end e write, permitem a comunicação dos processos do ambiente com os processos da IUT e são, portanto, do tipo observável. Os canais, update e start, permitem a comunicação apenas entre os processos do ambiente e, por isso, são classificados como canais internos do ambiente. Com exceção da transição que sincroniza com o rótulo start! e da transição que inicia a execução dos autômatos do sistema, todas as demais transições do autômato Scan testam em suas guardas a variável de controle CN. Essa variável assume o valor verdadeiro ao final das operações de execução dos autômatos do sistema, habilitando as transições que geram os rótulos end! e write!, e ao final da geração dos rótulos de saída, habilitando a transição que gera o rótulo update!. 4.4 Os Autômatos da IUT Para a IUT temos os seguintes templates: SR, DI, DT, PO, Event Generator. Todas as transições de todos os autômatos da IUT são disparadas em sincronismo com o rótulo synchro!, gerado pelo autômato Scan. Exceto o autômato que gera os eventos de saída que responde ao rótulo write!. Os autômatos do ambiente testam em suas guardas o valor de retorno da função evaluation. Essa função recebe como parâmetro o identificador da variável associada ao autômato, e testa as expressões que determinam que transição deve estar habilitada, para cada um dos autômatos do modelo. Os autômatos utilizados para modelar os flipflops, são instanciados a partir do template SR, mostrado na Figura 7. Para evitar ambigüidade na tomada de decisão quando os sinal de entrada desses elementos forem simultaneamente verdadeiros, é atribuída prioridade a uma das entradas. O tratamento da prioridade dos sinais de entrada para esse elemento é feito nas condições avaliadas pela função evaluation. A condição testada para habilitar a transição de baixa prioridade é formada

6 da seguinte maneira: guarda de baixa prioridade &&!guarda de alta prioridade. Dessa forma a transição de baixa prioridade só estará habilitada quando a expressão de maior prioridade for avaliada com falsa. De acordo com o valor retornado pela função evaluation, uma das transições possíveis é disparada, atualizando o valor da variável de saída do elemento modelado. Se nenhuma das condições de entrada é satisfeita, nenhuma transição é efetuada e o valor da variável de saída retém o último valor nela escrito, o que implementa a característica de memória do elemento. flags[id]=1 evaluation(id)==1 Off evaluation(id)==1 cycles = timer/tscan, cycles-- evaluation(id)==1 flags[id]=0 end? flags[id]=1 cycles == 0 && evaluation(id)==1 cycles > 0 && evaluation(id)==1 cycles-- Figura 8: Template DI On flags[id]=0 Figura 7: Template SR Os autômatos para os elementos temporizados, são instanciados a partir dos templates DI, DT e PO. Por motivo de limitação de espaço apenas o DI é ilustrado na Figura 8. A contagem do tempo é realizada considerando múltiplos do valor atribuído ao ciclo de varredura, ou seja, a menor temporização programada deve ser igual ao tempo de um ciclo de varredura, desta forma é realizada a contagem do número de ciclos equivalente a temporização programada. Isso pode ser feito pois as operações de atualização das variáveis de entrada e escrita das variáveis de saída são realizadas em tempo zero no modelo. Para obter o número de ciclos que devem ser efetuados antes de disparar a transição temporizada, é realizado o seguinte cálculo: cycles = timer/tscan. A variável cycles recebe a parte inteira da divisão do valor programado, timer, pelo tempo do ciclo de varredura, tscan, que é exatamente o número de ciclos desejado. A cada ciclo essa variável é decrementada, no momento em que o seu valor é igual a zero a transição temporizada deve ser disparada. Três localidades estão envolvidas no processo de contagem. Em cada uma delas existe um arco que permite que a contagem seja reiniciada a qualquer momento caso ocorrera uma mudança no valor das entradas do elemento após o início da contagem. As diferenças existentes entre os templates, dizem respeito ao comportamento do elemento modelado. 5 Conclusões Como resultado deste trabalho foi desenvolvida uma metodologia que para melhorar a confiança no funcionamento da implementação do SIS. A metodologia consiste em gerar modelos de autômatos temporizados da especificação, em ISA 5.2, e da implementação, em FBD, para confrontá-los via testes de conformidade. Para demonstrar o uso dessa metodologia foi desenvolvido um estudo de caso a partir de uma especificação fornecida pela Petrobras. Os diagramas utilizados correspondem à parte do controle de uma unidade de geração de hidrogênio da Refinaria Gabriel Passos (REGAP). O código FBD utilizado foi desenvolvido neste trabalho a partir da especificação. Como trabalhos futuros existe a necessidade de melhorar a geração dos testes para eliminar casos semelhantes e realizar o testes em uma planta real da Petrobras. Além disso, está sendo desenvolvida uma extensão deste trabalho para tratar a linguagem Ladder que também é muito utilizada em plantas de produção da Petrobras. Referências Alur, R. e Dill, D. L. (1994). A theory of timed automata, Theoretical Computer Science 126(2): Baresi, L., Mauri, M., Monti, A. e Pezzè, M. (2000). PLCTools: Design, formal validation, and code generation for programmable controllers, Proceedings of the IEEE Conference on System, Man, and Cybernetics, Vol. 4, IEEE Computer Society, Los Alamitos, CA, USA, pp Behrmann, G., David, A. e Larsen, K. G. (2004). A tutorial on uppaal, in M. Bernardo e F. Corradini (eds), Formal Methods for the Design of Real-Time Systems: 4th International School on Formal Methods for the Design of Computer, Communication, and Software Systems, SFM-RT 2004, number 3185 in LNCS, Springer Verlag, pp de Assis Barbosa, L. P., Gorgônio, K., Lima, A. M. N., Perkusich, A. e da Silva, L. D. (2007). On the automatic generation of timed automata models from isa 5.2 diagrams, Proceedings of 12th IEEE Conference on Emerging Technologies and Factory Automation, IEEE, Patras, Greece, pp Ins (1992). Binary Logic Diagrams for Process Operations, ISA (R1992) edn.