INSTITUTO MILITAR DE ENGENHARIA

CARLOS HENRIQUE DA COSTA OLIVEIRA

VERIFICAO DE MODELOS APLICADA AO PROJETO DE SISTEMAS INDUSTRIAIS AUTOMATIZADOS POR CONTROLADORES LGICOS PROGRAMVEIS

Dissertao de Mestrado apresentada ao Curso de Mestrado em Engenharia Eltrica do Instituto Militar de Engenharia, como requisito parcial para obteno do ttulo de Mestre em Cincias em Engenharia Eltrica. Orientador: Antonio Eduardo Carrilho da Cunha - Dr. Eng. Co-orientador: Mario Cesar Mello Massa de Campos Dr. ECP

Rio de Janeiro 2006

c2006 INSTITUTO MILITAR DE ENGENHARIA Praa General Tibrcio, 80-Praia Vermelha Rio de Janeiro-RJ CEP 22290-270 Este exemplar de propriedade do Instituto Militar de Engenharia, que poder inclu-lo em base de dados, armazenar em computador, microlmar ou adotar qualquer forma de arquivamento.

permitida a meno, reproduo parcial ou integral e a transmisso entre bibliotecas deste trabalho, sem modicao de seu texto, em qualquer meio que esteja ou venha a ser xado, para pesquisa acadmica, comentrios e citaes, desde que sem nalidade comercial e que seja feita a referncia bibliogrca completa. Os conceitos expressos neste trabalho so de responsabilidade do(s) autor(es) e do(s) orientador(es).

L48

Oliveira, Carlos Henrique da C. Vericao de Modelos Aplicada ao Projeto de Sistemas Industriais Automatizados por Controladores Lgicos Programveis / Carlos Henrique da Costa Oliveira. - Rio de Janeiro : Instituto Militar de Engenharia, 2006. 108 p.: il, graf., tab. Dissertao (mestrado) - Instituto Engenharia- Rio de Janeiro, 2006. Militar de

1. Controladores Lgicos Programveis - CLP. 2. Sistemas Industriais Automatizados. 3. Verico de Modelos. 4. Automao. 5. Conabilidade. 6. Diagrama de Blocos Funcionais - DBF. I. Ttulo. II. Instituto Militar de Engenharia. CDD 629.895

INSTITUTO MILITAR DE ENGENHARIA

CARLOS HENRIQUE DA COSTA OLIVEIRA

VERIFICAO DE MODELOS APLICADA AO PROJETO DE SISTEMAS INDUSTRIAIS AUTOMATIZADOS POR CONTROLADORES LGICOS PROGRAMVEIS

Dissertao de Mestrado apresentada ao Curso de Mestrado em Engenharia Eltrica do Instituto Militar de Engenharia, como requisito parcial para obteno do ttulo de Mestre em Cincias em Engenharia Eltrica. Orientador: Antonio Eduardo Carrilho da Cunha - Dr. Eng. Co-orientador: Mario Cesar Mello Massa de Campos - Dr. ECP Aprovada em 07 de Agosto de 2006 pela seguinte Banca Examinadora:

Antonio Eduardo Carrilho da Cunha - Dr. Eng. do IME - Presidente

Mario Cesar Mello Massa de Campos - Dr. ECP do CENPES

Joo Carlos dos Santos Basilio - Ph.D. da UFRJ

Paulo Csar Pellanda - Dr. ENSAE do IME

Rio de Janeiro 2006

Aos meus pais, Jos Carlos de Oliveira Delgado e Adlia da Costa Oliveira, dedico esta conquista por serem o tesouro da minha vida.

AGRADECIMENTOS

A Deus. Ao Instituto Militar de Engenharia, especialmente ao Departamentos de Engenharia Eltrica, pela oportunidade de realizar este curso. Aos meus pais Jos Carlos e Adlia, e irmos Adriana, Claudio e Carlos Adriano, aos meus cunhados Amauri e Esmeri e sobrinhas Lorraine, Catarine, Victoria e Lucas que sempre me deram incentivo e motivao ao longo de toda a minha vida e em mais esta etapa de minha formao. Aos meus tio(a)s, v, e primo(a)s por todo o incentivo e carinho. A tia Sandra por todo o apoio. A Denise, tia Vera, Sr Vitor, Fernanda e Marlon, que me acolheram com muito carinho no Rio de Janeiro. Aos meus amigos Cris, Faguinho, Rodrigo, Patrick, Charles, Marcinho, Raul, Pablo e Diogo Couto pela alegria, incentivo e amizade. Ao amigo, orientador e professor Antonio Eduardo Carrilho da Cunha pela pacincia, dedicao, incentivo e cumplicidade como orientador, sem os quais este trabalho no teria se concretizado. Ao amigo, co-orientador e professor Mario Cesar Mello Massa de Campos por acreditar e incentivar o trabalho. Ao Marcelo do CENPES pelo apoio. Aos professores Ades, Pellanda, Medling, Decilio e Pinheiro pelos conselhos, apoio e prossionalismo prestados no decorrer do curso. Aos meus amigos Leonardo Arajo, Diogo, Arthur, Michele, Alessandra, Rogrio por terem entrado na minha vida. Aos amigos Wander, Pinho, Toscano Careca, Ten. Toscano, Ten. Gleison, Leozinho, Luiz Felipe e Gilmar, pelo apoio, bizus e amizade. Aos Professores Envandro Camelo, Hlio Paiva pelas cartas de recomendao para o meu incio no curso de mestrado. Aos meus amigos Monique e Roberto pela fora. A todos que no foram citados mas contriburam de alguma forma para o trabalho. A Coordenao de Aperfeioamento de Pessoal de Nvel Superior - CAPES pelo apoio nanceiro. 5

SUMRIO

LISTA DE ILUSTRAES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

LISTA DE TABELAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 LISTA DE SMBOLOS E ABREVIATURAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 1 1.1 1.2 1.3 1.4 2 2.1 INTRODUO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Motivao e Justicativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Organizao do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 VERIFICAO DE MODELOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Viso Geral da Vericao de Modelos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.1.1 A Necessidade de Mtodos Formais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.1.2 Vericao de Hardware e Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.1.3 O Processo de Vericao de Modelos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.1.4 Lgica Temporal e Vericao de Modelos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.1.5 Algoritmos Simblicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 2.2 Lgicas Temporais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 2.2.1 A Lgica da rvore da Computao CT L . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 2.2.2 CTL e LTL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 2.2.3 Exemplo - Excluso Mtua . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 2.3 2.4 3 3.1 3.2 3.3 3.4 O Vericador de Modelos SMV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Resumo do Captulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 VERIFICAO DE MODELOS APLICADA PROGRAMAO DE CLPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Controladores Lgicos Programveis (CLPs ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Viso Geral da Vericao de Modelos Aplicada Programao de CLPs . . . 37 Um Modelo para os Diagramas de Contatos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Exemplos de Aplicao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

3.4.1 Sistema de Alarme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 3.4.2 Sistema de Manufatura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 6

3.5 4 4.1 4.2

Resumo do Captulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 CONTRIBUIES APLICAO DA VERIFICAO DE MODELOS AO PROJETO DE SISTEMAS AUTOMATIZADOS . . . . . 57 Projeto de Sistemas Automatizados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 Exemplo de um Projeto de Sistema Automatizado . . . . . . . . . . . . . . . . . . . . . . . 59

4.2.1 Descrio Literal das Especicaes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 4.2.2 Matriz de Causa e Efeito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 4.2.3 Fluxograma de Funcionamento e Programa de Aplicao . . . . . . . . . . . . . . . . . 61 4.2.4 Programa em DBF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 4.3 4.4 4.4.1 4.5 Proposta de Vericao de Modelos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 Escrita da Especicao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Escrita de Especicaes a partir da Matriz de Causa e Efeito . . . . . . . . . . . . 63 A Traduo da linguagem DBF em cdigo SMV . . . . . . . . . . . . . . . . . . . . . . . 67

4.4.2 Escrita das Especicaes a partir do Conhecimento do Sistema . . . . . . . . . . . 67 4.5.1 Elementos de Lgica Booleana . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 4.5.2 Elementos de Memria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 4.5.3 Blocos Temporizadores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 4.5.4 Construo Modular do Cdigo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 4.6 4.7 5 5.1 Vericao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 Resumo do Captulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 APLICAO NA AUTOMAO DE UM AQUECEDOR A CHAMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 Automao do Processo de Purga . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 5.1.1 Seqncia de Purga . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 5.1.2 Lista de Entradas e Sadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 5.1.3 Matriz de Causa e Efeito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 5.1.4 Projeto do Programa em DBF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 5.2 5.3 5.4 5.5 Modelagem das Especicaes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 Modelagem do Programa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 Vericao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 Resumo do Captulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 4.6.1 Reprojeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

6 6.1 6.2 6.3 7 8 8.1 8.2 8.3

CONCLUSO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 Contribuies vericao de modelos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 Limitaes da Abordagem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 Perspectivas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 REFERNCIAS BIBLIOGRFICAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 APNDICE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 Manual do Vericador de Modelos Simblicos (Symbolic Model Checking - SMV) verso 2.5.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 Linguagem de Entrada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 Sintaxe e Semntica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

8.3.1 Convenes Lxicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 8.3.2 Expresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 8.3.3 Declarao da ASSIGN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 8.3.4 Declarao SPEC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 8.3.5 Declarao DEFINE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 8.3.6 Mdulos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 8.3.7 Identicadores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 8.3.8 Mdulo main . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

LISTA DE ILUSTRAES FIG.2.1 FIG.2.2 FIG.2.3 FIG.3.1 FIG.3.2 FIG.3.3 FIG.3.4 FIG.3.5 FIG.3.6 FIG.3.7 FIG.3.8 FIG.3.9 (a) Estrutura Kripke. (b) rvore correspondente para estado inicial S0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Operadores bsicos de CTL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Grco de transio de estados global para o problema de excluso mtua de um processo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Fluxo de dados entre o CLP e um sistema a controlar. . . . . . . . . . . . . . . . 36 Ciclo de varredura do CLP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Diagrama de Fluxo de Dados. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 LD e descrio do modelo equivalente. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 Sistema de alarme. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Programa de Controle para o Sistema de Alarme. . . . . . . . . . . . . . . . . . . . 44 Representao do programa de controle do alarme em linguagem de vericao de modelos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Vericao de Modelos para o programa de controle do alarme (contra-exemplo). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 Contra-exemplo da especicao da linha 4 na Figura 3.8. . . . . . . . . . . . . 47 Figura 3.8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 FIG.3.11 Contra-exemplo da especicao da linha 7 na Figura 3.8. . . . . . . . . . . . . 49 FIG.3.12 Analise grca do contra-exemplo da especicao da linha 7 na Figura 3.8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 FIG.3.13 Reprojeto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 FIG.3.14 Planta. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 FIG.3.15 Programa de Controle para o Sistema de Manufatura. . . . . . . . . . . . . . . . . 51 FIG.3.16 Representao do programa de controle da manufatura em linguagem de vericao de modelos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 FIG.3.17 Vericao de Modelos para o programa de controle da manufatura (contra-exemplo). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 FIG.3.18 Analise grca do contra-exemplo da especicao na linha 7 da Figura 3.16. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 FIG.3.19 Projeto com base na anlise do contra-exemplo. . . . . . . . . . . . . . . . . . . . . . 56 FIG.3.20 Resposta da Vericao aps correo do programa. . . . . . . . . . . . . . . . . . 56 9 FIG.3.10 Analise grca do contra-exemplo da especicao da linha 4 na

FIG.4.1 FIG.4.2 FIG.4.3 FIG.4.4 FIG.4.5 FIG.4.6 FIG.4.7 FIG.4.8 FIG.4.9

Mtodo de projeto adotado por Empresas de Automao. . . . . . . . . . . . . 58 Sistema estrela-tringulo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 Matriz de Causa e Efeito do sistema Y . . . . . . . . . . . . . . . . . . . . . . . . . 60 Fluxograma para o sistema estrela-tringulo. Programa em Diagramas de Blocos Funcionais. . . . . . . . . . . . . . . . . . . . . . . . 61 . . . . . . . . . . . . . . . . . . . . . 62

Procedimento atual e proposta de modicao. . . . . . . . . . . . . . . . . . . . . . . 63 Escrita de especicaes CTL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 Blocos lgicos AND, OR e NOT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 Blocos SET/RESET. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

FIG.4.10 Cdigos SET/RESET. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 FIG.4.11 Blocos dos temporizadores DI, DT, PO. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 FIG.4.12 Mquinas de estado correspondente ao cdigo do temporizador DI. . . . . . 70 FIG.4.13 Mquinas de estado correspondente ao cdigo do temporizador DT. . . . . 71 FIG.4.14 Mquinas de estado correspondente ao cdigo do temporizador PO. . . . . 71 FIG.4.15 Cdigos dos temporizadores. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 FIG.4.16 Programa em Diagramas de Blocos Funcionais com as variveis auxiliares. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 FIG.4.17 Traduo do DBF em cdigo SMV. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 FIG.4.18 Resposta da vericao. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 FIG.4.19 Contra-exemplo da especicao na linha 7 da Figura 4.18. . . . . . . . . . . . 76 FIG.4.20 Contra-exemplo da especicao na linha 10 da Figura 4.18. . . . . . . . . . . 77 FIG.4.21 Contra-exemplo da especicao na linha 13 da Figura 4.18. . . . . . . . . . . 78 FIG.4.22 Reprojeto com base no contra-exemplo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 FIG.4.23 Reprojeto na linguagem SMV. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 FIG.5.1 FIG.5.2 FIG.5.3 FIG.5.4 FIG.5.5 FIG.5.6 FIG.8.1 FIG.8.2 FIG.8.3 FIG.8.4 Matriz de Causa e Efeito do sistema Purga. . . . . . . . . . . . . . . . . . . . . . . . . 83 Projeto do sistema Purga. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 Tipos de sinal, segundo a norma ISA 5.2 (ISA, 1992). . . . . . . . . . . . . . . . . 84 Projeto do sistema Purga com insero de variveis auxiliares. . . . . . . . . 88 Modelo do Programa no SMV. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 Resposta da vericao do sistema Purga. . . . . . . . . . . . . . . . . . . . . . . . . . . 90 Listagem de short.smv. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 Expresso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 Programa e expresses reusveis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 Atribuio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 10

LISTA DE TABELAS TAB.3.1 TAB.3.2 TAB.4.1 TAB.4.2 TAB.5.1 TAB.5.2 Simbologia e descrio dos diagramas de contato . . . . . . . . . . . . . . . . . . . . 40 Bobinas do sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 . . . . . . . . . . . . . . . . . . . . . . . . . . 65 Entradas e sadas do sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 Condies para representao das Sadas Variveis de entrada do sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 Variveis de sada do sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

11

LISTA DE SMBOLOS E ABREVIATURAS

ABREVIATURAS CLP IME LD SMV CTL LTL SIPN SFC PN SED TCS DBF BF IL ST SIS MCE P&I MIE MIS OBDD DCS Controlador Lgico Programvel Instituto Militar de Engenharia Diagrama de Contatos Vericador de Modelo Simblico Lgica da rvore da Computao Lgica Temporal Linear Rede de Petri Interpretada a Sinais Diagrama de Funo Sequencial Rede de Petri Sistema a Eventos Discretos Teoria de Controle Supervisrio Diagrama de Blocos de Funes Blocos de Funes Lista de Instrues Texto Estruturado Sistema Instrumentado de Segurana Matriz de Causa e Efeito Diagrama de Processo e Instrumentao Memria Intermediria de Entrada Memria Intermediria de Sada Diagrama de Deciso Binria Ordenado Sistemas de Controle Distribudo

SMBOLOS : tal que existe para todo

12

 aA a /A s |= f s f AB AB AB AB A<B A>B

se, ento se, somente se operador OU operador E operador NO a pertence ao conjunto A a no pertence ao conjunto A equivalente f vlido no estado s f no vlido no estado s A est contido em B B est contido em A A maior ou igual a B A menor ou igual a B A menor que B A maior que B

SIMBOLOGIA PARA ALGORITMOS ! | & := init(x) next(x) > == != < <= > >= operador NO operador OU operador E atribuio operador de inicializao da varivel x operador de prximo estado da varivel x operador implica operador igual operador diferente operador menor que operador menor ou igual que operador maior que operador maior ou igual que

13

RESUMO

A conabilidade um fator fundamental para os Sistemas Industriais Automatizados. Assim, importante que o programa de aplicao do Controlador Lgico Programvel (CLP), responsvel pelo processo, atenda s corretas especicaes para o funcionamento. A no conformidade com as especicaes, seja por implementao errnea de uma lgica ou pela no observao de aspectos da interao do CLP com os equipamentos externos, pode levar a prejuzos materiais, pessoais e ambientais. O objetivo deste trabalho aplicar as tcnicas de vericao de modelos (model checking ) ao projeto de Sistemas Industriais Automatizados baseados em CLPs programados por Diagramas de Blocos Funcionais (DBFs). As contribuies deste trabalho so: Criao de um procedimento de traduo de programas escritos em DBF para a linguagem reconhecida pela ferramenta de vericao SMV usando carimbos, descrever um padro para escrever especicaes na linguagem da Lgica da rvore da Computao CTL e prope uma etapa de reprojeto, com base no contra exemplo.

14

ABSTRACT

Reliability is a basic factor for an industrial automated system. Thus, it is important that the application program running in the Programmable Logic controller (PLC), responsible for the system, follows exactly the safety specications. The nonconformity with the specications, either by an error in the program implementation or by the nonobservation of some aspects of the interleaving logic, may lead to material, personal or environmental damages. The aim of this work is to apply model checking techniques to the project of industrial automated system based on PLCs. Particularly the verication is performed using the software SMV and the program in the PLC is implemented in Functional Block Diagrams (FBDs). The contributions of this work are: a systematic procedure for the translation of the structures in a FBD program into SMV code using templates, and a method to re-project the PLC software by using of counterexamples given in the verication procedures.

15

1 INTRODUO

Este captulo apresenta uma viso geral do trabalho, incluindo uma introduo ao problema tratado, os objetivos traados, a metodologia adotada e um guia de leitura desta dissertao. 1.1 MOTIVAO E JUSTIFICATIVA A conabilidade um fator fundamental para os Sistemas Industriais Automatizados. Assim, importante que o programa de aplicao no Controlador Lgico Programvel (CLP) responsvel pelo processo industrial atenda s corretas especicaes para o seu funcionamento. Uma implementao que fuja do comportamento esperado pode permitir que ocorram falhas, possibilitando a ocorrncia de acidentes e prejuzos de ordem material, pessoal e ambiental. Veja-se, por exemplo, o problema na planta qumica em ALIPERTI (2005) e o problema no projeto das esteiras do aeroporto de Denver em GIBBS (1994). Este trabalho baseado na necessidade real de se utilizarem mtodos formais em sistemas onde falhas so inaceitveis. A vericao de modelos surgiu na cincia da computao na dcada de 60 em torno da crise crnica do software (GIBBS, 1994). Comeou a ser empregada na Engenharia de Automao mais recentemente com a crescente complexidade dos sistemas automatizados. O processo de vericao de modelos consiste basicamente em modelagem, especicao e vericao. A Vericao de Modelos permite fazer a comparao entre as especicaes do Sistema Industrial Automatizado e o programa a ser implementado no CLP. No caso de no conformidade do projeto com as especicaes, a vericao fornece um contraexemplo que ilustra a divergncia. Procedimentos semelhantes foram descritos em MOON (1994), RAUSCH & KROGH (1998) e SMET & ROSSI (2002). Entretanto tais trabalhos tratam apenas de programas escritos em linguagem por diagramas de contato e no tratam da sistematizao do uso da vericao num procedimento de projeto de um Sistema Industrial Automatizado.

16

1.2 OBJETIVOS O objetivo do presente trabalho aplicar a Vericao de Modelos como tcnica auxiliar para o projeto de Sistemas Industriais Automatizados por CLP. Deseja-se garantir principalmente a conabilidade do sistema implementado. Particularmente, neste trabalho, trata-se da programao de CLPs por Diagramas de Blocos Funcionais (DBFs). Este trabalho visa criar um procedimento de traduo do programa de aplicao em DBF para um cdigo aceito pela ferramenta de vericao. Objetiva-se tornar o programa modular, no qual possvel inserir modelos dos equipamentos externos, dos blocos temporizadores e dos blocos de memrias sob a forma de carimbos. Tambm tem como objetivo sistematizar o procedimento de traduo de especicaes em propriedades formais a serem vericadas. 1.3 METODOLOGIA Primeiramente foi feito um estudo dos principais mtodos de validao para sistemas complexos, como: simulao, teste, vericao dedutiva e vericao de modelos, que a adotada no trabalho. Em seguida feito um estudo de Controladores Lgicos Programveis (CLPs) e suas principais linguagens de programao dando uma viso geral do processo de vericao de modelos com exemplos de MOON (1994) e RAUSCH & KROGH (1998). Com base numa generalizao das etapas do projeto de um Sistema Industrial Automatizado por CLPs, propem-se etapas adicionais onde se aplica a vericao de modelos para validar o projeto. Para a execuo da Vericao utilizada a ferramenta SMV (Symbolic Model Verier ), que uma ferramenta acadmica que representa o estadoda-arte em vericao de modelos (CMU, 2000). Com base no contra exemplo, este trabalho prope uma etapa de reprojeto do programa de aplicao. Tais procedimentos so descritos na Seo 4.3. Conseqentemente, o trabalho descreve uma metodologia sistematizada para a vericao de modelos em projetos de sistemas automatizados, criando um procedimento de traduo de programas escritos em Diagramas de Blocos Funcionais (DBF) para a linguagem reconhecida pela ferramenta de vericao SMV. Descreve tambm um padro para escrever especicaes baseadas no conhecimento do sistema e na matriz de causa e efeito na linguagem da Lgica da rvore da Computao CTL. Aps desenvolvida a metodologia, aplica-se a um exemplo real de parte de um Aquecedor a Chama no Captulo 17

5. 1.4 ORGANIZAO DO TRABALHO O Captulo 2 d uma viso geral da vericao de modelos, descrevendo o seu processo. Mostra o sistema de vericao de modelos que MCMILLAN (1993) desenvolveu como parte de sua tese de doutorado, que utilizado neste trabalho. Tambm apresenta o que a lgica da rvore de computao (CTL). O Captulo 3 tem por principal objetivo mostrar como funciona a vericao de programas de CLP usando a vericao de modelos. So utilizados exemplos acadmicos de sistemas de pequeno porte (RAUSCH & KROGH, 1998) e (MOON, 1994) para facilitar o entendimento do processo de vericao. O Captulo 4 tem por objetivo aplicar as tcnicas de vericao de modelos ao projeto de Sistemas Automatizados baseados em CLPs programados por DBF. Foram desenvolvidos padres para a vericao, com base em estruturas lgicas tpicas, como carimbos de blocos de memria e temporizadores. Tambm foram desenvolvidos padres de especicaes para sistemas automatizados, visando a uma futura automatizao do processo de vericao. O Captulo 5 tem por objetivo aplicar as tcnicas de vericao de modelos desenvolvidas a uma parte de um projeto de automao de um Aquecedor a Chama Industrial. O Captulo 6 conclui o trabalho, analisando seu contedo em termos dos objetivos propostos. Tambm neste captulo so resumidas as contribuies tericas realizadas e apresentam-se ainda sugestes para futuros trabalhos.

18

2 VERIFICAO DE MODELOS

Este captulo apresenta o mtodo de vericao de modelos desenvolvido por Clarke e Emerson (CLARKE et al., 1999), que utilizado neste trabalho. 2.1 VISO GERAL DA VERIFICAO DE MODELOS A Vericao de Modelos uma tcnica automtica para validao do projeto de sistemas concorrentes de estados nitos. Foi usada com sucesso na prtica para validar projetos de complexos circuitos seqenciais e protocolos de comunicao (CLARKE et al., 1999). O principal desao da vericao de modelos o tratamento do problema de exploso de espao de estados. Este problema ocorre nos sistemas com muitos componentes que interagem entre si e com sistemas que possuem estruturas de dados que podem assumir muitos valores diferentes. Nesta seo, compara-se a vericao de modelos a outros mtodos formais para validao de projetos de software e hardware. Alm disso, descreve-se como a vericao de modelos usada para validar projetos de sistemas complexos. 2.1.1 A NECESSIDADE DE MTODOS FORMAIS Hoje, sistemas de hardware e software so usados amplamente em aplicaes onde falhas so inaceitveis: comrcio eletrnico, redes de comunicaes telefnicas, estradas de rodagem, sistemas de controle de trfego areo, instrumentos mdicos, entre outras. Freqentemente, escutam-se notcias de incidentes onde alguma falha causada por um erro em um sistema de hardware ou software. Um exemplo recente de tais falhas o foguete Ariane 5, que explodiu em 4 de junho de 1996, mais ou menos quarenta segundos depois que foi lanado (SPARACO, 1996). O comit que investigou o acidente mostrou que este foi causado por um erro no software de um computador que era responsvel por calcular o movimento do foguete. Durante o lanamento, uma exceo ocorreu quando um nmero de ponto utuante de 64-bits foi convertido num inteiro de 16-bits com sinal. Tal converso no era protegida pelo cdigo para manipular excees e fez com que o computador falhasse. O mesmo erro tambm fez com que o computador de backup falhasse. Em conseqncia, dados incorretos da atitude foram transmitidos ao computador de bordo, que causou a destruio do foguete. A equipe que investigou a falha sugeriu que 19

diversas medidas fossem tomadas a m impedir incidentes similares no futuro, incluindo a vericao do software do Ariane 5 (SPARACO, 1996). Por causa do sucesso da Internet e dos sistemas embarcados nos automveis, aeroplanos, e outros sistemas criticamente seguros, a dependncia do correto funcionamento de dispositivos computacionais se torna cada vez maior. De fato, o ritmo da mudana se torna mais acelerado a cada ano. Por causa deste rpido crescimento na tecnologia, importante desenvolver mtodos que aumentem a conana na correo de tais sistemas. 2.1.2 VERIFICAO DE HARDWARE E SOFTWARE Os principais mtodos de validao para sistemas complexos so simulao, teste, vericao dedutiva, e vericao de modelos (CLARKE et al., 1999). Ambos, simulao e teste, envolvem a execuo de experimentos antes de se empregar o sistema. Enquanto se executa a simulao sobre uma abstrao ou modelo do sistema, o teste executado no produto real. No caso de circuitos, a simulao executada no projeto do circuito, enquanto o teste executado no prprio circuito. Em ambos os casos, estes mtodos injetam sinais em determinados pontos no sistema e observam os sinais resultantes em outros pontos. Para o software, a simulao e os testes geralmente envolvem a gerao de determinadas entradas e observao das sadas correspondentes. Estes mtodos podem ser uma maneira econmica para encontrar diversos erros. Entretanto, vericar todas as interaes possveis e falhas potenciais usando simplesmente as tcnicas de simulao e teste raramente possvel. O termo vericao dedutiva se refere normalmente ao uso de axiomas e regras de prova para demonstrar a corretude dos sistemas (CLARKE et al., 1999). No incio da pesquisa envolvendo vericao dedutiva, o foco principal estava em garantir a correo de sistemas crticos. Supunha-se que a importncia do comportamento correto era to grande que o projetista ou perito em vericao (geralmente um matemtico ou um logicista) deveria gastar o tempo que fosse necessrio para vericar o sistema. Inicialmente, tais provas eram construdas inteiramente mo. Com o tempo, os pesquisadores descobriram que ferramentas de software poderiam ser desenvolvidas para forar o uso correto de axiomas e regras de prova. Tais ferramentas poderiam tambm aplicar uma busca sistemtica para sugerir vrias maneiras de se progredir no estgio corrente da prova. A importncia da vericao dedutiva amplamente reconhecida pelos cientistas da computao. A tcnica inuenciou signicativamente a rea de desenvolvimento de 20

softwares (por exemplo, a noo de um invariante ). Entretanto, a vericao dedutiva um processo demorado que pode ser efetuado somente por peritos treinados no raciocnio lgico e que tenham considervel experincia. A prova de um simples protocolo ou circuito pode durar dias ou meses (CLARKE et al., 1999). Conseqentemente, o uso da vericao dedutiva raro. aplicado primordialmente aos sistemas altamente sensveis, tais como protocolos de segurana, onde o investimento de recursos necessrios para garantir a segurana do seu uso so justicveis. importante estar ciente de que algumas tarefas matemticas no podem ser executadas por algoritmos. A teoria da computabilidade (CLARKE et al., 1999) fornece limitaes do que pode ser decidido por um algoritmo. Em particular, mostra-se que no existe um algoritmo que decida se um programa de computador arbitrrio (escrito em alguma linguagem de programao como C ou Pascal) termina. Isto limita imediatamente o que pode ser vericado automaticamente. Mais ainda, a terminao correta de um programa genrico no pode ser vericada automaticamente (CLARKE et al., 1999). Dessa forma, uma grande parte dos sistemas de prova no podem ser completamente automatizados. Uma vantagem da vericao dedutiva que esta pode ser usada para especular sobre sistemas de estados innitos (CLARKE et al., 1999). E esta tarefa pode ser automatizada dentro de certos limites. E ainda, mesmo que a propriedade a ser vericada seja verdadeira, nenhum limite pode ser colocado na quantidade de tempo ou de memria necessria a se encontrar uma soluo. A vericao de modelos (model checking ) uma tcnica para vericar sistemas concorrentes de estados nitos (CLARKE et al., 1999). Um benefcio desta restrio que a vericao pode ser executada automaticamente. O procedimento utiliza normalmente uma busca exaustiva do espao de estados do sistema para determinar se alguma especicao verdadeira ou no. Dados os recursos sucientes, os procedimentos terminaro sempre com uma resposta do tipo sim ou no. Alm disso, pode ser implementada por algoritmos com ecincia considervel, que podem rodar em mquinas potentes (geralmente no em um computador desktop tpico). Embora a restrio aos sistemas de estados nitos possa parecer uma principal desvantagem, a vericao de modelos aplicvel a diversas classes importantes de sistemas. Os controladores de hardware so sistemas de estados nitos, e os mesmos so muitos protocolos de comunicao. Em alguns casos, os sistemas que no so de estados nitos podem ser vericados pelo uso da vericao de modelos em combinao com 21

vrios princpios de abstrao e induo. Em muitos casos, erros podem ser encontrados restringindo as estruturas de dados ilimitadas a instncias especcas que sejam de estados nitos. Por exemplo, programas com las de mensagens ilimitados podem ser tratados por restrio do tamanho das las a um nmero pequeno como dois ou trs. Em virtude da vericao de modelos poder ser feita automaticamente, esta prefervel vericao dedutiva sempre que puder ser aplicada. Entretanto, sempre haver algumas aplicaes crticas em que a prova de teoremas necessria para a vericao completa. Um novo sentido da pesquisa tenta integrar a vericao dedutiva com a vericao de modelos, de modo que pores de estados nitos de sistemas complexos possam ser vericadas automaticamente. (CLARKE et al., 1999) 2.1.3 O PROCESSO DE VERIFICAO DE MODELOS Aplicar a vericao de modelos a um projeto consiste de basicamente trs tarefas (CLARKE et al., 1999): Modelagem: A primeira tarefa converter um projeto em um formalismo aceito por uma ferramenta de vericao de modelos. Em muitos casos, esta simplesmente uma tarefa de compilao. Em outros casos, devido a limitaes em tempo e memria, modelar um projeto requer o uso de abstrao para eliminar detalhes irrelevantes ou sem importncia. Especicao: Antes da vericao, necessrio indicar as propriedades a que o projeto deve satisfazer. A especicao dada geralmente em algum formalismo lgico. Para sistemas de hardware e de software, comum usar a lgica temporal, que pode armar como o comportamento do sistema evolui com o tempo. Um ponto importante na especicao a abrangncia (completeness ). Embora a vericao de modelos fornea subsdios para se certicar de que um modelo satisfaz a uma dada especicao, impossvel determinar se a especicao dada cobre todas as propriedades a que o sistema deve satisfazer. Vericao: A vericao completamente automtica. Entretanto, na prtica, envolve, freqentemente, o auxlio humano. Uma atividade manual a anlise dos resultados da vericao. Caso d um resultado negativo, fornecido ao usurio um trao de erro. O trao de erro trata de um contra-exemplo para a propriedade vericada e se destina a auxiliar o projetista a detectar onde o erro ocorreu. Neste 22

caso, a anlise do trao de erro pode requerer uma modicao no sistema e uma nova aplicao do algoritmo de vericao. Um trao de erro pode tambm resultar de uma modelagem incorreta do sistema ou de uma especicao incorreta, chamada freqentemente de negativo falso (CLARKE et al., 1999). O trao de erro pode tambm ser til para identicar e reparar estes dois problemas. Uma outra possibilidade que a tarefa da vericao no termine normalmente, devido ao tamanho do modelo, nos casos em que este seja demasiadamente grande para a memria do computador. Neste caso, pode ser necessrio refazer a vericao aps modicar alguns dos parmetros do vericador de modelos ou ter-se ajustado o modelo (por exemplo, pelo uso de abstraes adicionais). 2.1.4 LGICA TEMPORAL E VERIFICAO DE MODELOS As lgicas temporais so teis para especicar os sistemas concorrentes, porque descrevem a ordenao temporal dos eventos sem introduzir explicitamente o tempo. Foram desenvolvidas originalmente por lsofos para investigar a maneira como o tempo usado nos argumentos da linguagem natural (HUGUES & CRESWELL, 1977). Embora uma quantidade de lgicas temporais diferentes tenham sido desenvolvidas, a maioria possui um operador como Gf que verdadeiro no presente se f for sempre verdadeiro no futuro (isto , se f for globalmente verdadeiro). Para armar que dois eventos e1 e e2 nunca ocorrem ao mesmo tempo, escreve-se G(e1 e2 ). As lgicas temporais so classicadas freqentemente conforme o tempo, sendo suposto ter em uma estrutura linear ou ramicada. Neste trabalho, o sentido de uma frmula em lgica temporal determinado sempre com respeito a um tipo de grafo de transio de estados, chamado, por razes histricas, de estrutura Kripke (HUGUES & CRESWELL, 1977), conforme mostra a Seo 2.2.1. A introduo de algoritmos de vericao de modelos usando lgica temporal por Clarke e Emerson (CLARKE & EMERSON, 1981) no incio dos anos 80 permitiu a automao do raciocnio em lgica temporal para validao de programas. O algoritmo desenvolvido por Clarke e Emerson para a lgica de tempo ramicado CTL polinomial no tamanho do modelo determinado pelo programa sob considerao e no comprimento de sua especicao em lgica temporal. Mostraram tambm como a imparcialidade (fairness ) poderia ser tratada sem alterar a complexidade do algoritmo. Aproximadamente ao mesmo tempo, Quielle e Sifakis (QUIELLE & SIFAKIS, 1982) produziram um algoritmo de vericao de modelos para um subconjunto da CTL, mas 23

a complexidade no foi analisada. Mais tarde Clarke, Emerson e Sistla (CLARKE et al., 1986) planejaram um algoritmo melhorado linear no produto do comprimento da frmula e do tamanho do grafo de transio de estados. O algoritmo foi implementado no vericador de modelos denominado EMC, que foi distribudo e usado amplamente para vericar diversos sistemas de protocolos de rede e circuitos seqenciais (CLARKE et al., 1999). 2.1.5 ALGORITMOS SIMBLICOS Na implementao original do algoritmo de vericao de modelos de Clarke e Emerson (CLARKE & EMERSON, 1981), as relaes de transio so representadas explicitamente por listas de adjacncia. Para sistemas concorrentes com um pequeno nmero de processos, o nmero dos estados geralmente pequeno, e a abordagem , em geral vivel. Nos sistemas com muitas partes concorrentes entretanto, o nmero de estados no grafo de transio de estados global muito grande para lidar. Em 1987, Ken McMillan, ento um estudante de ps-graduao na Universidade de Carnegie Mellon, descobriu que, usando uma representao simblica para os grafos de transio de estados, sistemas com nmero de estados muito maior poderiam ser vericados (MCMILLAN, 1993). A nova representao simblica foi baseada nos Diagramas de Deciso Binria Ordenados (Ordered Binary Decision Diagrams - OBDDs), (BRYANT & MUSGRAVE, 1998). Os OBDDs fornecem uma forma cannica que freqentemente mais compacta que a forma normal conjuntiva ou disjuntiva (CLARKE et al., 1999). Algoritmos ecientes foram desenvolvidos para manipular frmulas booleanas escritas em OBDDs. Uma vez que a representao simblica captura alguma regularidade no espao de estados de determinados circuitos e protocolos, possvel vericar sistemas com um nmero extremamente grande de estados, muitas ordens maior do que poderia ser tratado pelos algoritmos que explicitam espaos de estados. Usando o algoritmo de vericao de modelos original de CTL de Clarke e Emerson com a nova representao para grafos de transio de estados, tornou-se possvel vericar alguns exemplos com mais de 1020 estados (CLARKE et al., 1999). Desde ento, os vrios renamentos das tcnicas baseadas em OBDD por outros pesquisadores levaram contagem de estados de at mais de 10120 (CLARKE et al., 1999). A representao implcita completamente natural para modelar circuitos seqenciais e protocolos. Cada estado codicado por uma atribuio de valores booleanos ao conjunto de variveis de estado associadas ao circuito ou protocolo. A relao de transio 24

pode conseqentemente ser expressa como uma frmula booleana nos termos de dois conjuntos de variveis: um conjunto que codica o estado de origem e o outro que codica o de destino. Esta frmula , ento, representada por um diagrama binrio de deciso (CLARKE et al., 1999). O algoritmo de vericao de modelos se baseia no clculo de pontos xos dos transformadores de predicado que so obtidos da relao de transio (CLARKE et al., 1999). Os pontos xos so conjuntos de estados que representam as vrias propriedades temporais do sistema concorrente. Nas novas implementaes, tanto os transformadores de predicado como os pontos xos so representados por OBDDs. Assim, possvel evitar que se construa explicitamente o grafo de estados do sistema concorrente. O sistema de vericao de modelos que McMillan desenvolveu como parte de sua tese de doutorado chamado Vericador de Modelos Simblicos (Symbolic Model Verier - SMV) (MCMILLAN, 1993). Baseia-se em uma linguagem para descrever sistemas concorrentes de estados nitos hierrquicos. Os programas na linguagem do SMV podem ser vericados por especicaes expressas em lgica temporal. O vericador de modelos extrai um sistema de transio representado por um OBDD a partir de um programa na linguagem SMV e usa um algoritmo de busca baseado em OBDDs para determinar se o sistema satisfaz especicao. Se o sistema de transio no satisfaz a alguma especicao, o vericador produzir um trao de execuo que mostra porque a especicao falsa. O sistema SMV amplamente distribudo, e um grande nmero de exemplos tem sido vericados com o mesmo. Os exemplos tratados fornecem uma evidncia convincente de que o SMV pode ser usado para eliminar erros em projetos industriais reais (CLARKE et al., 1999). Uma descrio completa da linguagem SMV apresentada no Apndice 8.1 deste trabalho. Um exemplo que ilustra o poder da vericao simblica de modelos a vericao do protocolo de coerncia de cache descrito no padro IEEE Futurebus+ (Padro IEEE 896.1-1991) (CLARKE et al., 1999). O desenvolvimento do protocolo de coerncia de cache Futurebus + data de 1988, e todas as tentativas precedentes de validar o protocolo foram baseadas inteiramente em tcnicas informais. No vero de 1992, pesquisadores da Universidade Carnegie Mellon construram um modelo preciso do protocolo na linguagem SMV e, ento, usaram o SMV para mostrar que o sistema de transio resultante satisfazia uma especicao formal da coerncia cache (CLARKE et al., 1993) e (LONG, 1993). Foram capazes de encontrar uma certa quantidade de erros anteriormente no detectados, bem como erros potenciais no projeto do protocolo. Clarke, Grumberg e Peled referem25

se a esta como sendo a primeira vez que uma ferramenta automtica de vericao utilizada para encontrar erros num padro IEEE (CLARKE et al., 1999). 2.2 LGICAS TEMPORAIS Nesta seo descrita uma lgica para especicar propriedades temporais dos sistemas de transio de estados. A lgica utiliza proposies atmicas e conectivos booleanos tais como a conjuno, a disjuno, e a negao para construir elaboradas expresses que descrevem as propriedades dos estados do sistema. A lgica temporal um formalismo para descrever seqncias de transies entre estados em um sistema reativo. Na lgica temporal considerada, o tempo no mencionado explicitamente, pelo contrrio, uma frmula especica se algum estado eventualmente alcanado, ou que um estado de erro nunca atingido. As propriedades como eventualmente ou nunca so especicadas usando-se operadores temporais (CLARKE et al., 1999). 2.2.1 A LGICA DA RVORE DA COMPUTAO CT L Conceitualmente, as frmulas da lgica da rvore de computao (Computation Tree Logic - CT L ) descrevem propriedades de rvores da computao. Forma-se uma rvore de computao ao se designar um estado de uma estrutura de transio de estados como estado inicial e, ento, desenrola-se a estrutura numa rvore innita com o estado inicial na raiz. A semntica CT L denida com respeito a uma estrutura Kripke (CLARKE et al., 1999). Sejam AP um conjunto de proposies atmicas, M uma estrutura Kripke tripla (S, R, L), onde S o conjunto de estados; R S S a relao de transio, que deve ser total (isto , para todos os estados s S existe um estado s S tal que (s, s ) R ); e L : S 2AP uma funo que etiqueta cada estado (s S ) com um conjunto de proposies atmicas (L(s) AP) verdadeiras nesse estado. Um caminho em M uma innita seqncia de estados, = s0 , s1 , ... tais que, para cada i 0, (si , si+1 ) R. A Figura 2.1 (a) ilustra uma estrutura Kripke e a Figura 2.1 (b) mostra a sua correspondente rvore da computao, com estado inicial s0 (CLARKE et al., 1986). Da Figura 2.1, o conjunto de estados S = {s0 , s1 , s2 }, a relao de transio R = {(s0 , s1 ), (s1 ,s0 ), (s0 , s2 ), (s2 , s1 )}, e os conjuntos de proposies atmicas so AP = {a, b, c}, o conjunto de proposies verdadeiras nos estados P (s0 ) = {a, b}, P (s1 ) = {b, c} e P (s2 ) = {a, c}.

26

S0
, .

S0 S2 S1 S0 S .1 S2 S1 S .2

S1 (a)

. .

. .

S .0

. .

(b)

FIG. 2.1: (a) Estrutura Kripke. (b) rvore correspondente para estado inicial S0 . Em CT L as frmulas so compostas de quanticadores de caminho e operadores temporais. Os quanticadores de caminho so usados para descrever a estrutura de ramicao da rvore de computao. H dois quanticadores de caminho: A (para todos os caminhos de computao - for all computation paths ) e E (para algum caminho de computao - for some computation path ). Estes quanticadores so usados em um estado particular para especicar que todos ou algum dos caminhos que comeam neste estado possuem alguma propriedade. Os operadores temporais descrevem propriedades de um caminho ao longo da rvore. H cinco operadores temporais bsicos: X (prxima vez - next time ) requer que uma propriedade seja vlida no segundo estado do caminho. F (eventualmente ou no futuro - eventually or in the future ) arma que uma propriedade vlida em algum estado do caminho. G (sempre ou globalmente - always or globally ) especica que uma propriedade vlida para todo estado do caminho. U (at - until ) um operador que combina duas propriedades. Dadas as propriedades p1 e p2 , p1 U p2 se houver um estado do caminho onde p2 torna-se vlida, e em cada estado precedente, p1 sempre for vlida. R (liberao - release ) dual ao operador U. Dadas as propriedades p1 e p2 , p1 R p2 , vlida quando p2 vlido ao longo do caminho at e incluindo o primeiro 27

estado onde p1 seja vlido. No se requer que p1 torne-se vlido no caminho. H dois tipos de frmulas em CT L : frmulas de estado (que so verdadeiras em um estado especco) e frmulas de caminho (que so verdadeiras ao longo de um caminho especco). Seja AP o conjunto de nomes de proposio atmicas. A sintaxe de frmulas de estado dada pelas seguintes regras: Se p AP, ento p uma frmula de estado. Se f e g so frmulas de estado, ento f, f g e f g so frmulas de estado. Se f uma frmula de caminho, ento E f e A f so frmulas de estado. Duas regras adicionais so necessrias para especicar a sintaxe de frmulas do caminho: Se f uma frmula de estado, ento f tambm uma frmula de caminho. Se f e g so frmulas de caminho, ento f, f g e f g, X f, F f, G f, f U g, e f R g so frmulas de caminho. A CT L o conjunto das frmulas de estado geradas pelas regras acima. Utiliza-se i para denotar o suxo do caminho que comea no estado si . Se f denotar uma frmula de estado, a notao M,s |= f signica que f vlida no estado s da estrutura kripke M. Similarmente, se f for uma frmula de caminho, M, |= f signica que f vlida ao longo do caminho na estrutura kripke M. Quando a estrutura kripke M estiver subentendida no contexto, ser usualmente omitida. A relao |= denida indutivamente como segue (supe-se que f1 e f2 sejam as frmulas de estado, g1 e g2 sejam frmulas de caminho e que denote um caminho na forma S0 S1 S2 ...): a) M, s |= f1 f1 L(s). b) M, s |= f1 M, s f1 .

c) M, s |= f1 f2 M, s |= f1 ou M, s |= f2 . d) M, s |= f1 f2 M, s |= f1 e M, s |= f2 . e) M, s |= Eg1 h um caminho a partir de s tal que M, |= g1 . f) M, s |= Ag1 para cada caminho que parte de s, M, |= g1 . 28

g) M, |= f1 s o primeiro estado de e M, s |= f1 . h) M, |= g1 M, g1 .

i) M, |= g1 g2 M, |= g1 ou M, |= g2 . j) M, |= g1 g2 M, |= g1 e M, |= g2 . k) M, |= Xg1 M, 1 |= g1 . l) M, |= Fg1 existe um k 0 tal que M, k |= g1 . m) M, |= Gg1 para todo i 0, M, i |= g1 . n) M, |= g1 Ug2 existe um k 0, tal que M, k |= g2 e para todo 0 j < k ,M, j |= g1 . o) M, |= g1 Rg2 para todo j 0, se para cada i < j M, i g1 ento M, j |= g2 .

fcil ver que os operadores , , X, U, e E so sucientes para expressar qualquer frmula CT L CLARKE et al. (1999), pois possvel listar o seguinte: f g (f g ) f Rg (f Ug ) Ff verdadeiroUf Gf Ff A(f ) E(f ) 2.2.2 CTL E LTL Neta seo consideram-se duas sub-lgicas da CT L : uma uma lgica de tempo ramicante e a outra uma lgica de tempo linear. A distino entre as duas est na forma como lidam com a ramicao na rvore de computao subjacente. Na lgica temporal de tempo ramicante, os operadores temporais quanticam sobre os caminhos que so possveis a partir de um dado estado. Na lgica temporal de tempo linear, os operadores so fornecidos descrevendo eventos ao longo de um nico trajeto de computao. A lgica da rvore da computao (CTL) um subconjunto restrito da CT L onde cada um dos operadores temporais X, F, G, U e R deve ser imediatamente precedido 29

por um quanticador de caminho (CLARKE et al., 1999). Mais precisamente, a CTL um subconjunto da CT L que obtida ao se restringir a sintaxe de frmulas de caminho pela seguinte regra: Se f e g forem frmulas de estado, ento X f, F f, G f, f U g, e f R g so frmulas de caminho. A Lgica temporal linear (LTL), consiste das frmulas que tm a forma A f, onde f uma frmula do caminho em que as nicas subfrmulas de estado permitidas so proposies atmicas (CLARKE et al., 1999). Mais precisamente, uma frmula de caminho LTL tal que: Se p AP, ento p uma frmula de caminho. Se f e g so frmulas de caminho, ento f, f g, f g, X f, F f, G f, f U g, e f R g so frmulas de caminho. Pode-se mostrar que as trs lgicas discutidas neste trabalho possuem poderes de expresso diferentes (CLARKE et al., 1999). Por exemplo, no h nenhuma frmula CTL que seja equivalente frmula LTL A(FGp ). Esta frmula expressa a propriedade de que, ao longo de todo caminho, h algum estado a partir do qual p ser sempre vlido. Do mesmo modo, no h nenhuma frmula LTL que seja equivalente uma frmula CTL AG(EFp). A disjuno entre as duas frmulas A(FGp) AG(EFp) uma frmula CT L e no exprimvel em frmulas CTL ou LTL. Todas as especicaes neste trabalho sero escritas na lgica CTL. H dez operadores bsicos de CTL (CLARKE et al., 1999): AX e EX; AF e EF; AG e EG; AU e EU; AR e ER. Cada um dos dez operadores podem ser expressos nos termos de trs operadores EX, EG e EU (CLARKE et al., 1999): 30

 AXf = EX(f ) EFf = E[V erdadeiroUf ] AGf = EF(f ) AFf = EG(f ) A[f Ug ] E[g U(f g )] EGg A[f Rg ] E[f Ug ] E[f Rg ] A[f Ug ] Alguns dos principais operadores so ilustrados na Figura 2.2. Os operadores so mais fceis de compreender em termos da rvore da computao obtida pelo desdobramento do modelo Kripke. Cada rvore da computao possui o n s0 como raiz (CLARKE et al., 1999). Muitos dos mtodos para evitar o problema da exploso de estados baseiam-se no raciocnio computacional ou na abstrao. A lgica que usada tipicamente nestes casos mais restrita e apenas permite quanticadores de caminho universais. A limitao da CTL aos quanticadores de caminho universais chamada de ACT L , e a restrio da CTL aos quanticadores de caminho universais chamada ACTL. A m de evitar quanticadores de caminho existenciais implcitos resultantes do uso da negao, supe-se que as frmulas sejam dadas na forma normal positiva, isto , as negaes so aplicadas apenas s proposies atmicas. Para evitar perda do poder de expresso, tornam-se necessrios os operadores de juno () e disjuno (), bem como ambos os operadores U e de R.

31

M,s0 f
f f

s0

M,s0  f
f f f f

s0
f f f

M,s0  f
f

s0
f

M,s0 f

s0

M,s0  f
f

s0
f

M,s0

EX f

s0
f

FIG. 2.2: Operadores bsicos de CTL. As frmulas AF AGa e AF AXa so exemplos de frmulas ACTL. Essas frmulas no so exprimveis em LTL CLARKE et al. (1999). Porque ACTL um subconjunto de CTL, as lgicas ACTL e LTL so incomparveis. Alm disso, ACT L possui mais poder de expresso que a LTL. As frmulas AG EF a e AG AF a no esto em ACTL. 2.2.3 EXEMPLO - EXCLUSO MTUA Os grafos de transio de estados globais de muitos programas concorrentes podem ser modelados como estruturas Kripke CLARKE et al. (1986). Por exemplo, a Figura 2.3 mostra a estrutura Kripke para uma soluo simples do problema de excluso mtua entre dois processos P1 e P2 . Nesta soluo, cada processo Pi (i = 1ou2) est sempre em uma de trs regies do cdigo: Ni : fora da regio crtica; Ti : esperando para entrar na regio crtica; Ci : dentro da regio crtica.

32

FIG. 2.3: Grco de transio de estados global para o problema de excluso mtua de um processo. Note que somente transies entre regies diferentes do cdigo foram modeladas; os movimentos dentro da mesma regio so considerados irrelevantes neste nvel de abstrao. Alm disso, cada transio devido execuo exata de uma etapa de um processo. fcil ver, neste caso, que AF(C1 ) verdadeiro no estado 1 e que EF(C1 C2 ) falso no estado 0. 2.3 O VERIFICADOR DE MODELOS SMV O SMV uma ferramenta para vericar se sistemas de estados nitos satisfazem a especicaes dadas em CTL. Utiliza o algoritmo simblico de vericao de modelos baseado em OBDDs de McMillan (MCMILLAN, 1993) (CLARKE et al., 1999). Os componentes da linguagem do SMV so usados para descrever sistemas complexos de estados nitos. Algumas das caractersticas mais importantes da linguagem so descritas abaixo. O usurio pode decompor a descrio de um sistema de estados nitos complexo em mdulos. Os mdulos podem ser instanciados diversas vezes, e podem referenciar variveis declaradas em outros mdulos. Os mdulos podem ter parmetros que podem ser componentes de estados, expresses, ou outros mdulos. Os Mdulos do SMV podem ser compostos sincronamente ou por intertravamento. Em uma composio sncrona, um passo na composio corresponde a um passo em cada um dos componentes. No intertravamento, um passo da composio representa um passo dado por apenas um componente. Se a palavra chave process preceder uma instncia de um mdulo, o intertravamento usado, seno a composio sncrona suposta. 33

As transies de estado em um modelo podem ser deterministas ou nodeterministas. O no-determinismo pode reetir um ponto de escolha nas aes do sistema que est sendo modelado, ou pode ser usado para descrever um modelo mais abstrato onde so omitidos determinados detalhes. A habilidade de especicar o nodeterminismo est ausente para muitas linguagens de descrio de hardware, mas crucial ao fazer modelos de alto nvel (CLARKE et al., 1999). As relaes de transio dos mdulos podem ser especicadas explicitamente nos termos de relaes booleanas nos estados estimados atuais e prximos de variveis de estados, ou implicitamente como um conjunto de indicaes de atribuies paralelas. As indicaes de atribuio paralelas denem os valores das variveis no prximo estado em termos de valores no estado atual. No fornecida uma sintaxe ou uma semntica formal para a linguagem do SMV aqui neste captulo, mas pode ser encontrado no manual do SMV (MCMILLAN, 1993) ou no Apndice 8.1. 2.4 RESUMO DO CAPTULO Este captulo mostra basicamente como funciona o mtodo de Vericao de Modelos. No prximo captulo ser mostrado como a vericao de modelos aplicada validao de programas de CLP.

34

3 VERIFICAO DE MODELOS APLICADA PROGRAMAO DE CLPS

Este captulo ilustra a aplicao da vericao de modelos validao de programas de CLP. Os programas em considerao so escritos na linguagem de diagramas de contato. Os exemplos apresentados servem de base para a compreenso de como so elaboradas as especicaes em CTL, e como funciona o mtodo de vericao. 3.1 CONTROLADORES LGICOS PROGRAMVEIS (CLPS ) Um controlador lgico programvel (CLP) um equipamento eletrnico de tecnologia digital que utiliza memria programvel para armazenamento interno de instrues para cumprimento de rotinas especicas, como lgica, seqenciamento, temporizao, contagem e aritmtica, para controlar, por intermdio dos sinais provenientes de mdulos de entradas e sadas, vrios tipos de mquinas ou processos (DIAS, 2005). A Figura 3.1 apresenta um uxo de dados de um CLP e um processo sob seu controle (MOON, 1994). Ao controlar um sistema, um CLP executa repetidamente um ciclo de varredura conforme mostra a Figura 3.2. Um ciclo de varredura tipo consiste em trs etapas: a) Atualizao dos dados da memria intermediria de entrada (MIE) com base nos valores lidos nos mdulos de entrada. b) Execuo sequencial do programa de aplicao do usurio, com alterao da memria de dados. c) Escrita dos valores da memria intermediria de sada (MIS) nos mdulos de sada.

35

FIG. 3.1: Fluxo de dados entre o CLP e um sistema a controlar. Para que o CLP seja um controlador ecaz, o tempo de varredura deve ser menor do que o tempo de durao mais curto de um sinal de entrada ou sada do processo. O tempo de varredura geralmente na escala de milesegundos e depende da velocidade do processador, do tamanho do programa, e do nmero de dispositivos de entrada e de sada (FALCIONE & KROGH, 1993).

FIG. 3.2: Ciclo de varredura do CLP. O padro IEC 61131-3 (IEC, 2003) dene a sintaxe e a semntica de cinco linguagens de programao para CLPs. As quatro primeiras linguagens de programao so: os Diagramas de Contatos, os Diagramas de Blocos Funcionais (que so linguagens grcas), os Textos Estruturados e as Listas de Instrues (que so linguagens textuais). A linguagem de Diagramas de Contato (Ladder Diagram - LD) se baseia na lgica de rels e permite a descrio de funes Booleanas. Na linguagem dos Diagramas de Blocos Funcionais 36

(DBF), a programao feita por intermdio de blocos grcos. A linguagem de Texto Estruturado (Structured Text - ST), prxima ao Pascal, permite sentenas condicionais, seqenciais e laos. A Lista de Instrues (Instruction List - IL) uma linguagem na forma de um cdigo assembler. A quinta linguagem da norma IEC 61131-3 denida para estruturar a organizao interna dos programas de CLP e blocos de funes. Esta linguagem grca, chamada de Cartas de Funes Seqenciais (Sequential Function Charts - SFC), trata de uma extenso das mquinas de estado contendo primitivas para descrever comportamentos seqenciais, paralelismo e sincronicidades. Permite a diviso de um programa de CLP (ou bloco de funes) em um conjunto de etapas e transies interconectadas por arcos direcionados. Cada etapa associada a um conjunto de aes e cada transio associada a um conjunto de condies lgicas. Baseia-se no Grafcet, norma IEC 60848 (IEC, 1999). Um dos objetivos da IEC 61131-3 proporcionar ao projetista de programas de CLP uma ferramenta modular e estruturante para viabilizar a reusabilidade e a qualidade dos programas, especialmente em direo conabilidade segurana (LAMPRIRECOUFFIN et al., 1999). Todavia, a existncia de elementos comuns para todas as linguagens de programao no o bastante para assegurar a qualidade dos programas, e o padro no trata de mtodos ecientes de vericao. 3.2 VISO GERAL DA VERIFICAO DE MODELOS APLICADA PROGRAMAO DE CLPS Encontram-se na literatura algumas abordagens para vericao de programas de CLP, descritas sucintamente a seguir. Em MOON (1994), apresenta-se um mtodo de vericao de programas escritos em diagrama de contatos. Denem-se algumas formas de escrever as especicaes em CTL para os acionamentos tpicos de um CLP. Mostra-se uma forma de modelagem de um programa escrito em diagrama de contatos na forma de um cdigo SMV. Utiliza a ferramenta SMV original (CMU, 2000) para fazer a vericao. Em RAUSCH & KROGH (1998), utiliza-se o formalismo dos sistemas Condio/Evento para representar a planta a controlar pelo CLP. Dessa forma, inclui-se o modelo dos equipamentos externos que interfaceiam com o CLP. Utilizam-se mdulos para descrever os componentes do sistema e do programa do CLP. Em VLKER & KRMER (1999) faz a vericao por prova de teoremas assistida por uma ferramenta de software. As especicaes so escritas em LTL e os programas a vericar descritos em SFCs e DBFs. Em SMET & ROSSI (2002) modela-se uma clula de manufatura onde se testam 90 37

especicaes. Utiliza-se o Cadence SMV (CADENCE, 2002) para fazer a vericao. Expressam-se as propriedades em LTL e CTL. Em XIYING & LITZ (2002) utilizam-se redes de Petri para modelar o sistema. Apresenta-se um procedimento para descrever os sistemas por Redes de Petri Interpretadas a Sinais (SIPN). SONG et al. (2004) faz a vericao de modelos para programas com blocos temporizadores. Trata-se da vericao de propriedades para a automao de usinas nucleares. A Figura 3.3 apresenta uma viso geral do mtodo a ser seguido para se executar a vericao de sistemas automatizados por CLP baseado nas abordagens de MOON (1994) e RAUSCH & KROGH (1998), citadas anteriormente.

Programas em Diagrama de Contatos

Funcionamento do CLP

Equipamentos/sensores/ atuadores/processo

Especificaes de funcionamento

Modelo do prog. em Diagr. de Cont. em execuo no CLP

Modelo do ambiente externo

Modelo do sistema

Propriedades formais

Verificao

Contra-exemplo

Propriedade verdadeira

FIG. 3.3: Diagrama de Fluxo de Dados. Primeiramente obtm-se um modelo do programa de aplicao combinado ao funcionamento do CLP. De forma geral, tratam-se apenas programas escritos em Diagramas de Contatos. As estruturas utilizadas da linguagem de diagrama de contatos so simples, no se encontrando na maioria das abordagens, estruturas complexas do tipo memrias, temporizadores etc. Essa modelagem do programa de aplicao, incluindo sua interpretao pelo hardware do CLP, foi estabelecida por MOON (1994). A vericao feita sobre uma abstrao do programa e no sobre o programa de aplicao propriamente dito. Faz-se uma modelagem da listagem do CLP na linguagem do SMV apenas. Adicionalmente, pode-se ter o modelo do ambiente externo ao CLP: equipamentos, sensores, atuadores e o processo propriamente dito. Isso enriquece o modelo do sistema, restringindo os comportamentos possveis, pois nem todo sinal de entrada pode ocorrer. A 38

modelagem do ambiente externo ao CLP foi estabelecida pela primeira vez por RAUSCH & KROGH (1998). O modelo do programa de aplicao, combinado ao modelo do funcionamento do CLP, e o modelo do ambiente externo so combinados num modelo do sistema a vericar, como mostrado na Figura 3.3. As especicaes de funcionamento podem descrever as seqncias lgicas indesejadas, a lgica de sequencializao ou as propriedades estruturais do sistema. Em funo da descrio das especicaes ou do conhecimento do sistema, feita a construo da propriedade formal, escrita na maioria das vezes em CTL. No se observa na literatura nenhuma tentativa de sistematizao da escrita de especicaes. Em geral a vericao feita utilizando-se diferentes verses da ferramenta SMV. MOON (1994) e RAUSCH & KROGH (1998) desenvolveram os estudos sobre SMV original (CMU, 2000). SMET & ROSSI (2002) utilizam o Cadence SMV (CADENCE, 2002). H, ainda, a ferramenta NuSMV (CAVADA & CIMATTI, 2004). O resultado da vericao indica se o modelo do sistema est em conformidade com as especicaes ou no. Em caso negativo, trs so as hipteses que devem ser levantadas, como indicado pelo tracejado na Figura 3.3. Primeiramente, uma fonte de no conformidade o erro de modelagem do sistema. Neste caso, deve-se renar ou corrigir o modelo do sistema para se fazer uma nova vericao. A segunda hiptese a existncia de um erro do programa de aplicao captado na modelagem. Neste caso, deve-se partir para um reprojeto do programa antes de uma nova vericao. A terceira hiptese corresponde ao dito falso verdadeiro de uma propriedade, onde as especicaes ou esto escritas incorretamente ou expressam requisitos muito restritos para o sistema. Neste caso, a especicao deve ser reescrita para uma nova vericao. 3.3 UM MODELO PARA OS DIAGRAMAS DE CONTATOS Os Diagramas de Contato so uma forma de programao de CLPs por meio de smbolos grcos, representando contatos e bobinas. Os contatos e bobinas correspondem a variveis booleanas armazenadas na memria de dados do CLP. So conectados por ligaes em ramos (rungs ) como num diagrama de lgica a rel. As expresses booleanas calculadas a cada ciclo de varredura do CLP correspondem avaliao lgica seqencial do diagrama de contatos (FABIAN & HELLGREN, 1998). Um contato representado como abaixo, onde se identica um contato, associado varivel booleana A, interna ao CLP, e duas ligaes: uma direita e uma esquerda. 39

A --| |-Os contatos so usados como acesso ao estado de uma varivel interna no clculo de expresses booleanas. Tipicamente encontram-se os contatos indicados na Tabela 3.1 (FABIAN & HELLGREN, 1998). TAB. 3.1: Simbologia e descrio dos diagramas de contato CONTATO Contato normalmente aberto Contato normalmente fechado SMBOLO DESCRIO A O estado da ligao esquerda copiado para a ligao --| |- direita se o estado de A verdadeiro, caso contrrio, o estado da ligao direita falso. A O estado da ligao esquerda copiado para a ligao --|/|- direita se o estado de A falso, caso contrrio, o estado da ligao direita falso.

Uma bobina representada como abaixo, onde identica-se uma bobina associada a uma varivel booleana Q, interna ao controlador, e duas ligaes: uma direita e uma esquerda. Q --( )-As bobinas alteram os estados de suas variveis associadas. A Tabela 3.2 ilustra alguns tipos de bobina (FABIAN & HELLGREN, 1998). TAB. 3.2: Bobinas do sistema BOBINA Bobina normal Bobina negativa SMBOLO Q --( )-Q --(\)-DESCRIO O estado da ligao da esquerda copiado para a varivel Q. A negao do estado da ligao esquerda copiada para a varivel Q.

A converso de um diagrama de contatos para uma descrio de modelo em SMV quase que uma correspondncia direta (MOON, 1994). Os valores de sada das bobinas, direita de cada ramo, dependem da estrutura e dos valores no lado esquerdo do ramo. Cada ramo pode ser convertido em uma descrio de modelo correspondente usando os operadores do SMV ! (NO), & (E), | (OU) e next (prximo estado) (MOON, 1994). 40

A Figura 3.4 mostra um diagrama de contatos (a) e a descrio do modelo equivalente no SMV (b). As barras verticais do diagrama indicam a fonte de potncia, onde a barra da esquerda representa o potencial alto e a barra da direita representa o potencial baixo, enquanto as linhas horizontais, chamadas ramos, indicam, os uxos corrente possveis. A varredura dos ramos de um diagrama de contatos da esquerda superior para a direita. Dependendo do fabricante do CLP, a varredura do diagrama de contatos feita ramo a ramo ou coluna a coluna. Em muitos casos, as duas ordens no fazem nenhuma diferena no comportamento da varredura dos CLPs. Para evitar casos excepcionais, escolhido o modelo do diagrama de contatos fazendo varredura ramo a ramo de cima para baixo (MOON, 1994). A ordem da varredura coluna por coluna pode ser modelada de uma maneira similar (MOON, 1994).
R1 Ramo 1 R3 Ramo 2 R5 Ramo 3 R8 Ramo 4 R9 R11 Ramo 5 R12 R7 Ramo 6 R14 R15 next(R15) := next(R7) & R14; R13 R12 next(R12) := (R11 | R12) & !R13; R10 next(R10) := R8 | R9; R6 R7 next(R7) := R5 & R6; R4 next(R4) := !R3; R2 next(R2) := R1;

(a)

(b)

FIG. 3.4: LD e descrio do modelo equivalente. O ramo 1 do diagrama da Figura 3.4, corresponde a um contato normalmente aberto R1 ligado a uma bobina de sada R2. O valor correspondente da bobina R2 no prximo ciclo de varredura igual ao valor do contato R1 no tempo de varredura atual. Deste modo, se a entrada R1 VERDADEIRA ento R2 VERDADEIRA no prximo ciclo de varredura; seno R2 FALSO no prximo ciclo de varredura. 41

Embora a memria de dados seja atualizada imediatamente enquanto as entradas relacionadas so mudadas, o sinal de sada ocorre depois, uma vez feita a varredura. Para incluir a idia da diferena de tempo entre a entrada e a sada, o operador next usado na descrio de modelos como mostrado no texto do lado direito (b) da Figura 3.4. O ramo 2 representa a lgica booleana (NO) e a descrio de modelos equivalentes mostrada no texto usando o operador !. Os ramos em srie e paralelo de variveis de entrada representam a lgica booleana E e OU, respectivamente, como mostrado nos ramos 3 e 4. Por exemplo, R7 no ramo 3 VERDADEIRO na prxima varredura somente se R5 e R6 so atualmente VERDADEIROS. O ramo 5 mostra um contato de selo, uma estrutura fundamental para todos os elementos armazenados. A bobina R12 torna-se VERDADEIRA (selagem) se o contato de R11 tornar VERDADEIRO, e R12 permanece VERDADEIRA at que o contato R13 se torne VERDADEIRO (liberao). A descrio de modelo equivalente mostrada no texto da Figura 3.4. Observe que R12 mostrado como um contato normalmente aberto no lado direito do texto e uma sada representada pelo operador next no lado esquerdo do texto. Porque R7 no ramo 6 mostrado tambm no ramo 3 como uma sada, o contato R7 j est alterado quando o CLP comea a varredura do ramo 6 (somente na ordem de varredura ramo a ramo de cima para baixo). Assim o valor de R7 no ramo 6 o mesmo que o prximo valor R7 mudado no ramo 3. O R7 no ramo 6 representado como next(R7) em vez de R7, mesmo R7 sendo mostrado no lado esquerdo do ramo. A regra da converso aqui que se a varivel da entrada j tiver aparecido como uma varivel de sada acima do ramo atual, o operador next deve ser adicionado para representar a varivel na descrio de modelos do SMV. Pode-se traduzir um programa em Diagrama de Contatos em um modelo do sistema correspondente para sua vericao usando as regras da converso mostradas na Figura 3.4. 3.4 EXEMPLOS DE APLICAO Nesta seo so apresentados dois exemplos acadmicos que ilustram como feita a vericao em diagramas de contato. Tratam-se de um sistema de alarme fornecido por MOON (1994) e um sistema de manufatura fornecido por RAUSCH & KROGH (1998).

42

3.4.1 SISTEMA DE ALARME Considere um tpico sistema de alarme mostrado na Figura 3.5 (MOON, 1994). O sistema possui duas entradas binrias: um sinal vindo de um contato no campo (d1), a signicar a ocorrncia de uma condio, e o sinal de reconhecimento da condio, por parte do operador (APB) vindo de uma botoeira num painel. Duas sadas binrias: uma sirene (horn ) e uma lmpada de advertncia (lig ). Cada varivel binria assume o valor 1 (VERDADEIRO ) ou 0 (FALSO ). O estado d1 = 1 indica que alguma condio no campo excede um limite permitido, por exemplo, um reator est em uma alta temperatura ou detectada a presso baixa num processo.
Condio no campo (d1) Reconhecimento (APB) Sirene (horn) Lmpada (lig)

Sistema de Alarme
FIG. 3.5: Sistema de alarme.

As especicaes informais do projeto para o diagrama de contatos deste sistema de alarme so as seguintes: Se a condio no campo ocorre (d1 = 1 ), o sistema de alarme faz soar a sirene (horn = 1 ). Nessa condio, quando o operador pressiona a botoeira de reconhecimento (APB = 1 ), o sistema deve desligar a sirene e acender a lmpada de advertncia (lig = 1 ). A lmpada permanece acesa enquanto persistir a condio no campo (d1 = 1 ). Assim que a condio no campo cessar (d1 = 0 ), a lmpada deve ser apagada (lig = 0 ) e o sistema retorna condio inicial de normalidade. Suponha que um engenheiro projete o diagrama de contatos para o sistema de alarme mostrado na Figura 3.6 baseado nas especicaes acima (MOON, 1994). Utiliza-se o mtodo de vericao para certicar-se de que o programa atende a todas as especicaes dadas. Como a primeira etapa da vericao, necessrio modelar o programa de controle. A Figura 3.7 mostra o programa de controle na linguagem de descrio de modelos da ferramenta SMV (MOON, 1994). As linhas 12 a 14 da Figura 3.7 iniciadas por next 43

d1

APB

horn d1

APB

R1

horn
R1

R1

d1

APB

horn

horn
d1 APB R1 d1

lig

lig

FIG. 3.6: Programa de Controle para o Sistema de Alarme. correspondem a cada ramo mostrado na Figura 3.6. Toda vez que ocorre a varredura no CLP, as variveis dependentes, R1, horn e lig, mudam de acordo com as regras de cada ramo. As linhas 9 e 11 correspondem inicializao das variveis internas ao CLP.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

MODULE main VAR d1: boolean; APB : boolean; R1 : boolean; horn : boolean; lig : boolean; ASSIGN init(R1) := 0; init(horn) := 0; init(lig) := 0; next(R1) := ((!d1 & (APB |!horn)) | R1) & ((!horn & !APB) | !d1); next(horn) := ((next(R1) & d1) | horn) & !APB; next(lig) := ((d1 & APB) | lig) & (next(R1) | d1); SPEC SPEC SPEC SPEC SPEC SPEC SPEC AG(APB -> AF !horn) AG(!d1 & !APB -> AX(d1 & !APB -> AF horn)) AG(horn -> !E[!APB U (!horn & !APB)]) AG(!d1 -> AF !lig) AG(d1 & !APB -> AX(d1 & APB -> AF lig)) AG(lig -> !E[d1 U (!lig & d1)]) AG!(horn & lig)

FIG. 3.7: Representao do programa de controle do alarme em linguagem de vericao de modelos. 44

As linhas 16 a 22 da Figura 3.7 mostram as especicaes escritas em CTL referentes descrio do sistema. As trs primeiras (linhas 16 a 18) expressam o comportamento da sirene, as trs seguintes (linha 19 a 21) comportamento da lmpada e a ltima (linha 22) comportamento conjunto da sirene e da lmpada. O resultado da vericao mostrado de forma parcial, na Figura 3.8.
1 2 3 4 5 6 7

--------

specification specification specification specification specification specification specification

AG AG AG AG AG AG AG

(APB -> AF (!horn)) is true (!d1 & !APB -> AX (d1 & !APB -> AF ho... is true (horn -> !E((!APB) U (!horn & !APB))) is true (!d1 -> AF (!lig)) is false (d1 & !APB -> AX (d1 & APB -> AF lig)... is true (lig -> !E(d1 U (!lig & d1))) is true (!(horn & lig)) is false

FIG. 3.8: Vericao de Modelos para o programa de controle do alarme (contra-exemplo). A primeira especicao AG(AP B > AF!horn) faz o vericador de modelos procurar todas as possibilidades de estados no sistema e responder pergunta: se a botoeira for acionada, faz a sirene parar? A resposta do vericador de modelos a esta pergunta VERDADEIRA como mostrado na linha 1 da Figura 3.8. A segunda especicao AG(!d1&!AP B > AX(d1&!AP B > AFhorn)) corresponde a se a botoeira no estiver pressionada e, no prximo instante, o sinal de perigo em d1 muda de 0 para 1, ento a sirene soa. O vericador de modelos responde que este teste VERDADEIRO como mostrado na linha 2 da Figura 3.8. A terceira especicao AG(horn >!E[!AP B U(!horn&!AP B )]) testa o perodo de tempo em que a sirene soa. A segunda parte da expresso CTL !E[!AP B U(!horn&!AP B )], equivalente a A[hornUAP B ], que signica que a sirene permanece VERDADEIRA a menos que APB seja VERDADEIRA. A especicao mostra um caso, em que uma vez 45

a sirene acionada, permanece ligada a menos que a botoeira seja pressionada. A botoeira no pode ser pressionada para sempre. A resposta VERDADEIRA como mostrado na linha 3 da Figura 3.8. Os resultados dos trs testes acima indicam que a sirene se comporta como especicado no enunciado do problema. As trs especicaes seguintes tratam do comportamento da lmpada de advertncia. A expresso CTL AG(!d1 > AF!lig ) signica que a lmpada no acende sem que a condio no campo ocorra. Como visto na Figura 3.8 (linha 4) a resposta FALSA. Isto signica que h um estado em que a lmpada permanece ligada (lig=1 ) quando no h nenhuma condio no campo (d1=0 ). Deve-se seguir o contra-exemplo fornecido pelo SMV e mostrado na Figura 3.9 para encontrar a fonte do erro, o que ilustrado na Figura 3.10. A condio inicial mostra que todas as variveis so zero (VERDADE). A condio no campo (d1 ), a botoeira (APB ) e R1 so mostradas VERDADEIRAS no estado 1.2. A lmpada torna-se VERDADEIRA no estado 1.3 e permanece ligada mesmo que a condio no campo desaparea. Um exemplo o loop dos estados 1.3 ao 1.5. Este contra-exemplo pode sugerir uma modicao no projeto, particularmente na parte da lgica relacionada lmpada. As duas especicaes seguintes para a lmpada (linhas 5 e 6 da Figura 3.8) so anlogas s especicaes correspondentes da sirene.

46

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

-- specification AG (!d1 -> AF (!lig)) is false -- as demonstrated by the following execution sequence state 1.1: d1 = 0 APB = 0 R1 = 0 horn = 0 lig = 0 state 1.2: d1 = 1 APB = 1 R1 = 1 -- loop starts here -state 1.3: d1 = 0 APB = 0 R1 = 0 lig = 1 state 1.4: d1 = 1 APB = 1 R1 = 1 state 1.5: d1 = 0 APB = 0 R1 = 0

FIG. 3.9: Contra-exemplo da especicao da linha 4 na Figura 3.8.

47

Estados d1 APB R1 horn lig

1.1

1.2

1.3

1.4

1.5

Local onde ocorre o problema

FIG. 3.10: Analise grca do contra-exemplo da especicao da linha 4 na Figura 3.8. A especicao AG!(horn&lig ) testa se h alguma situao que a sirene e a lmpada esto ligadas simultaneamente. A resposta FALSA visto que no estado 1.5 da Figura 3.11 a sirene (horn ) e a lmpada (lig ) esto em simultaneidade, conforme ilustra a analise grca na Figura 3.12.

48

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27

-- specification AG (!(horn & lig)) is false -- as demonstrated by the following execution sequence state 1.1: d1 = 0 APB = 0 R1 = 0 horn = 0 lig = 0 state 1.2: d1 = 1 APB = 1 R1 = 1 state 1.3: d1 = 0 APB = 0 R1 = 0 lig = 1 state 1.4: d1 = 1 R1 = 1 state 1.5: d1 = 0 horn = 1

FIG. 3.11: Contra-exemplo da especicao da linha 7 na Figura 3.8.

Estados d1 APB R1 horn lig

1.1

1.2

1.3

1.4

1.5

Local onde ocorre o problema

FIG. 3.12: Analise grca do contra-exemplo da especicao da linha 7 na Figura 3.8. Para que a lmpada funcione corretamente nesta situao, o diagrama de contatos 49

deve ser reprojetado. A Figura 3.10 ilustra uma possvel soluo por remoo de um contato associado a R1 no terceiro ramo do diagrama de contatos. As mesmas especicaes so usadas para vericar o diagrama de contatos reprojetado, e o resultado correto para todos os testes relativos s especicaes mostradas na Figura 3.8, aps reprojeto (Figura 3.13), asseguram ao usurio que o sistema de alarme segue as especicaes dadas. Observa-se que este mtodo no garante qualquer coisa sobre comportamentos no modelados do sistema.

d1

APB

horn d1

APB

R1

horn
R1

R1

d1

APB

horn

horn
d1 APB d1

lig

lig

FIG. 3.13: Reprojeto. 3.4.2 SISTEMA DE MANUFATURA Trata-se de um exemplo fornecido por RAUSCH & KROGH (1998), que consiste de dois rels e de um pisto para mover uma pea (Figura 3.14). parte de um sistema de manufatura onde uma esteira transportadora move uma pea para a posio 1. O pisto move a pea da posio 1 para a posio 2. Um outro pisto (no mostrado) move a pea da posio 2 para outra esteira transportadora. A Figura 3.14 mostra os sinais de sada binrios do controlador c1 e c2, os quais so sinais de entrada planta, e os sinais de entrada binrios do controlador R1on, R2on (= 1 se o rel for acionado), Pbase e Pestendido (= 1 se o pisto estiver nesta posio). O pisto movido por um motor controlado por dois rels. O rel R1 causa o movimento para a diante, e o rel R2, o movimento inverso. A especicao para o sistema da Figura 50

3.14 que se probe que ambos os rels estejam acionados simultaneamente.

Posio 2

Pestendido

Pea
P i s t o

Posio1 Pbase R1on R2on M CLP R1 C1 C2 R2

FIG. 3.14: Planta. O controle realizado usando um CLP, e usada no exemplo a notao de diagramas de contato. A Figura 3.15 mostra o programa no CLP (RAUSCH & KROGH, 1998), onde R1on , R2on so os sinais do sensor dos rels, C1s, C2s so os sinais de comando do controlador, e C1 e C2 so os sinais de sada de comando aos rels. A lgica de controle deixa um comando a um rel para o controlador durante a passagem seqencial completa, desde que o outro rel no esteja acionado, ou no haja nenhum comando que esteja se opondo fora para acionar o outro rel.

FIG. 3.15: Programa de Controle para o Sistema de Manufatura. Em RAUSCH & KROGH (1998), por meio da vericao formal, prova-se que a ex51

ecuo da lgica de controle est incorreta pois em algum momento do ciclo de varredura ambos os rels podem ser acionados ao mesmo tempo. Neste exemplo utilizam-se mdulos para elaborar um modelo SMV para o sistema (RAUSCH & KROGH, 1998). Um mdulo um gabarito para um sistema de transies de estados que usado para modelar mltiplos componentes em um sistema com mltiplas instncias. As instncias dos mdulos podem ser usadas nas denies de outros mdulos, dando a possibilidade para denir modelos hierrquicos de sistemas complexos (CLARKE et al., 1999). Por exemplo, as linhas de 7 a 16 da Figura 3.16 mostram um mdulo que representa um rel genrico para o sistema. Um mdulo denido pela palavra-chave MODULE e um nome seguido por uma lista de variveis de entrada (linha 1 da Figura 3.16). As variveis locais do mdulo so denidas em uma lista que comea com a palavra chave VAR (linha 2). As transies de estados so caracterizadas pelas mudanas nos valores das variveis do mdulo e denidas na indicao de ASSIGN (linhas 10 a 16). As transies podem ser no-deterministas como ilustrado nas linhas 13 e 14. Variveis adicionais podem ser denidas depois da palavra chave DEFINE, no mostrada neste programa. As instncias dos mdulos podem ser usadas para construir outros mdulos. No caso em anlise, um mdulo que representa o sistema completo composto por duas instncias dos mdulos para os dois rels (que usam a mesma denio do mdulo) e um mdulo para o controlador (vide Figura 3.16). Um programa pode ser instanciado mais de uma vez como nas linhas 3 e 4. O mdulo completo referenciado pelo mdulo principal main. Este o mdulo superior na composio hierrquica como mostra as linhas de 1 a 6 da Figura 3.16. O diferencial deste exemplo a necessidade de se modelar o ambiente externo ao CLP, pois a especicao de comportamento consiste em evitar que os rels R1 e R2 estejam acionados ao mesmo tempo. O modelo se d a partir da escrita de diagramas de estados correspondentes ao comportamento desejado para os rels, como mostrado nas linhas 7 a 16 da Figura 3.16. O exemplo ilustra os tipos de circunstncias sutis que podem conduzir a problemas com programas de CLP, devido durao nita do ciclo de varredura. A probabilidade da seqncia de transies indesejadas ocorrer pode ser pequena, mas certamente possvel (veja Figura 3.17). Para melhor visualizao do trao do contra-exemplo apresentada uma anlise grca na Figura 3.18. Na computao da sada C2, h um teste para certicar se a 52

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29

MODULE main VAR r1 : relay(c.C1); r2 : relay(c.C2); c : controller(r1.state,r2.state); SPEC AG (!r1.state | !r2.state) MODULE relay(input) VAR state : boolean; ASSIGN init(state) := 0; next(state) := case !state & input : {1,0}; state & !input : {0,1}; 1: state; esac; MODULE controller(R1on,R2on) VAR C1s : boolean; C2s : boolean; C1 : boolean; C2 : boolean; ASSIGN init(C1s) := 0; init(C2s) := 0; init(C1) := 0; init(C2) := 0; next(C1) := (C1s & (R1on | (!R2on & !C2))); next(C2) := (C2s & (R2on | (!R1on & !next(C1))));

FIG. 3.16: Representao do programa de controle da manufatura em linguagem de vericao de modelos.

53

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33

-- specification AG (!r1.state | !r2.state) is false -- as demonstrated by the following execution sequence state 1.1: r1.state = 0 r2.state = 0 c.C1s = 0 c.C2s = 0 c.C1 = 0 c.C2 = 0 state 1.2: c.C1s = 1 state 1.3: c.C1s = 0 c.C2s = 1 c.C1 = 1 state 1.4: r1.state = 1 c.C2s = 0 c.C1 = 0 c.C2 = 1 state 1.5: r2.state = 1 c.C2 = 0 resources used: processor time: 0 s, BDD nodes allocated: 771 Bytes allocated: 1045224 BDD nodes representing transition relation: 78 + 1

FIG. 3.17: Vericao de Modelos para o programa de controle da manufatura (contra-exemplo).

54

sada C1 est desligada. O contato C1 acionado, entretanto, no ramo precedente, assim C2 poderia estar desligada mesmo que o valor da sada do controlador (como visto pela planta) possa ainda estar ligado. Conseqentemente, o primeiro rel poderia fazer uma transio para acionado e, ao nal de um ciclo de varredura, o sinal C2 poderia ser tambm acionado, colocando a planta em perigo durante a varredura seguinte, uma vez que o rel R2 pode ser acionado em conjunto com R1.
Estados C1 C2 C1s C2s r1.state r2.state
Local onde ocorre o problema

1.1

1.2

1.3

1.4

1.5

FIG. 3.18: Analise grca do contra-exemplo da especicao na linha 7 da Figura 3.16. A soluo para um controlador que evite este erro neste caso, considerar os valores velho e novo de C1 quando for computado o valor novo C2, conforme mostra a Figura 3.19 (RAUSCH & KROGH, 1998). Aps correo com base no contra-exemplo na Figura 3.17 e auxilio da anlise grca na Figura 3.18, a especicao passou a ser verdadeira conforme mostra a Figura 3.20.

55

FIG. 3.19: Projeto com base na anlise do contra-exemplo.

-- specification AG (!r1.state | !r2.state) is true resources used: processor time: 0 s, BDD nodes allocated: 323 Bytes allocated: 1045220 BDD nodes representing transition relation: 107 + 1

1 2 3 4 5 6 7

FIG. 3.20: Resposta da Vericao aps correo do programa.

3.5 RESUMO DO CAPTULO Neste captulo possvel ter uma viso geral de como funciona a vericao de modelos aplicada aos programas de CLP. Os programas so escritos na linguagem de Diagramas de Contato. Porm um dos objetivos da dissertao aplicar a vericao, em programas de CLP escritos na linguagem de Diagrama de Blocos Funcionais (DBF). O prximo captulo trata da vericao aplicada a um sistema automatizado escrito na linguagem DBF. So tratadas, ainda, estruturas mais complexas como memrias e temporizadores.

56

4 CONTRIBUIES APLICAO DA VERIFICAO DE MODELOS AO PROJETO DE SISTEMAS AUTOMATIZADOS

O objetivo deste captulo aplicar as tcnicas de vericao de modelos (model checking ) ao projeto de Sistemas Automatizados baseados em CLPs programados por Diagramas de Blocos Funcionais (DBF). Foram desenvolvidos padres para a vericao, com base em estruturas lgicas tpicas, visando uma futura automatizao do processo. 4.1 PROJETO DE SISTEMAS AUTOMATIZADOS A Figura 4.1 ilustra um modelo muito adotado por empresas de engenharia de automao para o projeto de sistemas automatizados. As etapas de um projeto so divididas em quatro, a saber: elaborao de requisitos, projeto, implementao e teste e validao. Na etapa de elaborao de requisitos as especicaes do sistema so listadas. Alguns documentos tpicos produzidos nesta etapa so: Descritivos literais da automao; Padres de lgica para sequenciamento e intertravamento; Matrizes de Causa e Efeito; Fluxogramas de Funcionamento, e Diagramas de Processo e Instrumentao. Os padres de lgica para sequenciamento seguem a norma ISA 5.2 (Diagramas Lgicos Binrios para Operaes de Processos) (ISA, 1992). Na etapa de projeto, com base nos documentos gerados pela etapa de elaborao de requisitos, a prpria empresa ou uma empresa terceirizada desenvolve o projeto do sistema automatizado. Documentos tpicos gerados nesta fase so: Mapa de Memria do CLP; Lista de Entradas e Sadas, e Listagem do Programa do CLP. 57

A listagem do programa segue o proposto pela norma IEC 61131-3. A maioria dos programas gerados atualmente seguem os diagramas de contato. Para sistemas onde a segurana crtica, nota-se o emprego dos DBFs, que possuem um mapeamento direto aos blocos da norma ISA 5.2. Na fase de implementao, o diagrama desenvolvido implementado no CLP correspondente e montagens eltricas so realizadas. Novamente o processo pode ser terceirizado ou montado pela equipe de campo da contratante, com suporte da equipe que elaborou o projeto.
Elaborao de Requisitos

Projeto

Implementao

Teste e Validao

FIG. 4.1: Mtodo de projeto adotado por Empresas de Automao. Na fase de testes e validao, so executados testes para comissionamento do sistema. Tipicamente, testes de bancada ou os ditos loop-tests (testes feitos com o CLP ligado malha de controle) so realizados. Observa-se que estes testes no exaurem as possibilidades de falha do sistema. Para alguns casos, o limite humano no possibilita a visualizao de certas falhas. Como a conabilidade do sistema garantida apenas pelos testes, problemas no detectados podem causar prejuzos materiais, pessoais e ambientais. Por outro lado, os erros detectados na fase de testes e validao acarretam o retorno s fases anteriores, como ilustrado pelo tracejado na Figura 4.1. O retorno s etapas anteriores corresponde a atrasos indesejveis no cronograma do projeto.

58

4.2 EXEMPLO DE UM PROJETO DE SISTEMA AUTOMATIZADO Para ilustrar o processo, toma-se como exemplo um projeto de uma chave de partida estrela-tringulo (Y-) para um motor trifsico. A nalidade de um sistema Y- em um motor de se reduzir a corrente de partida, ou seja, a corrente de pico no momento da partida. necessrio que o motor seja do tipo de rotor em gaiola de esquilo, e todas as pontas de ligao devem ser externas. A tenso tringulo a mesma da rede (ser nesta tenso que o motor ir trabalhar). A tenso em estrela (tenso de partida do motor) externamente ao motor tambm a mesma da tringulo, sendo menor nas bobinas do motor pelo tipo de ligao nos terminais. 4.2.1 DESCRIO LITERAL DAS ESPECIFICAES A Figura 4.2 mostra o esquema eltrico do sistema estrela-tringulo. O funcionamento do sistema o seguinte: Pressionando a botoeira L, as bobinas dos contactores K1, K3 (ligao em estrela) so alimentadas, comeando a contar o tempo programado; Aps o tempo programado (10s), a alimentao da bobina de K3 cortada, e a bobina de K2 (ligao em tringulo) acionada. As bobinas K1 e K2 so mantidas energizadas; As contactoras K2 e K3 no podem estar acionadas ao mesmo tempo; Pressionando a botoeira D, desliga-se todo o sistema; Implementar a segurana de sobrecorrente com entrada de um contato do rel trmico FT no CLP. As entradas e sadas do sistema esto na Tabela 4.1. 4.2.2 MATRIZ DE CAUSA E EFEITO A Matriz de Causa e Efeito (MCE) trata-se de uma tabela onde se estabelecem as relaes de seqencializao de acionamento do sistema. Na primeira linha da tabela listam-se os sinais que so as causas para os acionamentos, e na primeira coluna listam-se os conseqentes efeitos nos sinais do sistema. A Figura 4.3 ilustra a MCE para o processo em questo. 59

FIG. 4.2: Sistema estrela-tringulo. TAB. 4.1: Entradas e sadas do sistema ENTRADAS Botoeira de liga (boto pulsante) Botoeira de desliga (boto pulsante) Contato trmico SADAS Contactora de acionamento Contactora de acionamento Contactora de acionamento

L D FT K1 K2 K3

K3 desligado

K1 acionado

K3 acionado

EFEITO
Aciona K1 e K3 Desliga K3 Liga K2 Desliga K1, K2 e K3

X X X X X X X X X

FIG. 4.3: Matriz de Causa e Efeito do sistema Y . 60

FT acionado

D acionado

L acionado

CAUSA

T > 10s

4.2.3 FLUXOGRAMA DE FUNCIONAMENTO E PROGRAMA DE APLICAO A lgica de acionamento do programa de aplicao desenvolvido para este sistema demonstrada na forma de um Fluxograma na Figura 4.4.
Incio

L?
S

Aciona K1 e K3
N T>10s? S N

Desliga K1, K2 e K3

D?
S

FT?
S

Desliga K3
N

!K3?
S

D?
S

FT?
S

Aciona K2
N

D?
S

FT?
S

FIG. 4.4: Fluxograma para o sistema estrela-tringulo. Neste trabalho est sendo mostrado o uxograma pois uma das maneiras utilizadas pelas empresas para expressar a lgica de acionamento. Porm o uso do mesmo arriscado para Sistemas Industriais Automatizados, podendo induzir o projetista a inserir erros na execuo do projeto em DBF no CLP. 4.2.4 PROGRAMA EM DBF A Figura 4.5 representa o programa escrito em diagramas de blocos funcionais DBF, projetado por uma empresa de automao. Supe-se que os blocos utilizados so E (AND), OU (OR), memrias e temporizadores com atraso sincronizado (DI). A descrio detalhada do funcionamento dos blocos encontra-se na Seo 4.5 61

FIG. 4.5: Programa em Diagramas de Blocos Funcionais. 4.3 PROPOSTA DE VERIFICAO DE MODELOS Este trabalho tem como proposta inserir um mtodo de vericao nas fases de elaborao de requisitos e projeto do processo ilustrado na Figura 4.1, conforme mostrado na Figura 4.6. Na elaborao de requisitos, prope-se um procedimento no qual faz-se a traduo de especicaes, para especicaes em CTL. J na fase de projeto, os programas escritos em DBF no CLP so traduzidos no cdigo reconhecido pela ferramenta de vericao. O processo se fecha com uma etapa de vericao. O resultado da vericao, quando da obteno de um erro, utilizado para renamento dos requisitos e/ou reprojeto. Com este processo objetiva-se aumentar a conabilidade do sistema e minimizar o atraso no projeto por erros detectados na fase de testes e validao. Nas prximas sees, as etapas do processo de vericao so detalhadas.

62

Refinamento dos requisitos

Elaborao de Requisitos

Especificao em CTL

Verificao

Projeto

Mdulo do prog. do CLP em SMV Re-projeto

Implementao

Teste e Validao

FIG. 4.6: Procedimento atual e proposta de modicao. 4.4 ESCRITA DA ESPECIFICAO O estudo feito para este trabalho mostra que existem duas maneiras de escrever as especicaes CTL para sistemas automatizados. Pode ser feita a partir da matriz de causa e efeito, como apresentado na Seo 4.4.1 e tambm a partir do conhecimento do sistema, como apresentado na Seo 4.4.2. 4.4.1 ESCRITA DE ESPECIFICAES A PARTIR DA MATRIZ DE CAUSA E EFEITO Este desenvolvimento consiste na obteno de especicaes CTL com base na MCE. A Figura 4.7 ilustra a base do procedimento proposto para sistematizao da escrita das especicaes CTL. Nesta gura: V AR representa uma varivel de sada do sistema; CON representa as condies que levam a varivel V AR assumir a condio 1 (equivalente a ON ou VERDADEIRO), denominada condio para verdadeiro; COF F representa as condies que levam a varivel V AR assumir a condio 0 (equivalente a OFF ou FALSO), denominada condio para falso. 63

CON COFF

Lgica

VAR

FIG. 4.7: Escrita de especicaes CTL. Exploram-se as informaes a respeito do acionamento de variveis na MCE para escrita de propriedades CTL. As especicaes podem ser escritas de duas formas diferentes em funo do acionamento e do desligamento da varivel V AR. Para o acionamento da varivel V AR escrevem-se duas especicaes: A primeira especicao :

AG(CON &!COF F > AF(V AR)),

(4.1)

a signicar que sempre que a condio para verdadeiro for vlida e a condio para falso for no vlida (CON &!COF F ) ento, para todos os caminhos no futuro, V AR ser verdadeira. A outra especicao :

AG(!V AR >!E[!CON U(V AR&!CON )]),

(4.2)

a signicar que sempre que V AR passar de falso para verdadeiro, CON deve tambm ser vlida. Isso signica que V AR no passa para verdadeiro por qualquer outra condio que no seja CON . Para o desligamento da varivel V AR escrevem-se tambm duas especicaes: A primeira especicao :

AG(COF F &!CON > AF(!V AR)),

(4.3)

a signicar que sempre que a condio para falso for vlida e a condio para verdadeiro for no vlida (COF F &!CON ) ento, para todos os caminhos no futuro, V AR ser no verdadeira. A outra especicao : 64

AG(V AR >!E[!COF F U(!V AR&!COF F )]),

(4.4)

a signicar que sempre que V AR passar de verdadeiro para falso, COF F deve tambm ser vlida. Isso signica que V AR no passa para falso por qualquer outra condio, a no ser por COF F . Baseado na Tabela 4.1 de entradas e sadas e na Matriz de Causa e Efeito do sistema Y , so mostradas as condies para verdadeiro e falso para as variveis K1, K2 e K3 na Tabela 4.2. TAB. 4.2: Condies para representao das Sadas SADAS Contactora K1 Contactora K2 Contactora K3 CON L (T1 & !K3) (L & !K2) COF F (D|FT) (D|FT) (D|FT|T1)

Para a contactora K1, a condio que a torna verdadeira L e a que a torna falsa D ou FT. J para a contactora K2, a condio que a torna verdadeira T1, varivel binria a signicar que o tempo em tringulo terminou, e !K3, e a que a torna falsa D ou FT. Da mesma forma, para a contactora K3, a condio que a torna verdadeira L e !K2, e a que a torna falsa D ou FT ou T1. De acordo com as especicaes sistematizadas para o acionamento (especicaes 4.1 e 4.2) e desligamento (especicaes 4.3 e 4.4) de variveis de sada, mostram-se as especicaes para o sistema Y levando em conta as condies para verdadeiro e falso descritas para cada uma das contactoras. Substituindo as condies de cada contactora tem-se: As especicaes para o acionamento de K1:

AG(L&!(D|F T ) > AF(K 1))

(4.5)

AG(!K 1 >!E[!LU(K 1&!L)]) Especicaes para o desligamento de K1:

(4.6)

65

AG((D|F T )&!L > AF(!K 1))

(4.7)

AG(K 1 >!E[!(D|F T )U(!K 1&!(D|F T ))]) Especicaes para o acionamento de K2:

(4.8)

AG((T 1&!K 3)&!(D|F T ) > AF(K 2))

(4.9)

AG(!K 2 >!E[!(T 1&!K 3)U(K 2&!(T 1&!K 3))]) Especicaes para o desligamento de K2:

(4.10)

AG((D|F T )&!(T 1&!K 3) > AF(!K 2))

(4.11)

AG(K 2 >!E[!(D|F T )U(!K 2&!(D|F T ))]) Especicaes para o acionamento de K3:

(4.12)

AG((L&!K 2)&!(D|F T |T 1)) > AF(K 3))

(4.13)

AG(!K 3 >!E[!(L&!K 2)U(K 3&!(L&!K 2))]) Especicaes para o desligamento de K3 (4.15) e (4.16).

(4.14)

AG((D|F T |T 1)&!(L&!K 2) > AF(!K 3))

(4.15)

AG(K 3 >!E[!(D|F T |T 1)U(!K 3&!(D|F T |T 1))])

(4.16)

66

4.4.2 ESCRITA DAS ESPECIFICAES A PARTIR DO CONHECIMENTO DO SISTEMA Esta seo apresenta uma outra forma de especicao baseada no conhecimento do sistema, subentendida por especicao estrutural. Um primeiro tipo pode expressar segurana para o sistema, pela expresso AG p, onde apresenta uma situao no qual a propriedade p sempre vlida para o sistema. Para o sistema Y pode-se representar essa especicao na forma: AG!(K 2&K 3) a representar que as sadas K2 e K3 no podem estar acionadas simultaneamente. Esse tipo de especicao expressa informalmente como nada bom/ruim vai acontecer. Dois outros tipos de especicaes estruturais podem ser escritas para uma dada propriedade p : vivacidade, AF p, a signicar que sempre a propriedade p ser verdade no futuro, informalmente expresso como algo bom/ruim vai acontecer, e alcanabilidade, EF
p , a signicar que eventualmente a propriedade p ser verdade no futuro, informalmente

expresso como algo bom/ruim pode acontecer (CLARKE et al., 1999). 4.5 A TRADUO DA LINGUAGEM DBF EM CDIGO SMV Esta seo apresenta um mtodo de traduo de um programa escrito em DBF para o cdigo do SMV. Com objetivo de uma automatizao do mtodo de traduo foram desenvolvidos gabaritos de cdigo SMV para as estruturas tpicas da norma ANSI/ISA 5.2 (ISA, 1992). 4.5.1 ELEMENTOS DE LGICA BOOLEANA A Figura 4.8 mostra os blocos de lgica bsica que so utilizados na elaborao do DBF. Essa gura apresentada em trs colunas as quais representam: A Figura 4.8(a): o bloco lgico E (AND ). A varivel de sada D verdade se somente se todas as variveis de entra A, B e C forem verdade. Na linguagem SMV escreve-se D:= A&B&C; A Figura 4.8(b): o bloco lgico OU (OR ). A varivel de sada D verdade se somente se uma ou mais variveis de entrada A, B ou C forem verdade. Na linguagem do SMV, escreve-se D:= A|B|C; 67

 A Figura 4.8(c): o bloco lgico NO (NOT ). A varivel de sada B existe se somente se a varivel de entrada A for falsa. Na linguagem do SMV, escreve-se B:= !A;

FIG. 4.8: Blocos lgicos AND, OR e NOT.

4.5.2 ELEMENTOS DE MEMRIA A Figura 4.9 mostra os blocos de memria no qual S representa SET e R representa RESET. Na Figura 4.9 (a), a sada lgica C verdade assim que a entrada lgica A seja verdade. C continua a ser verdadeiro, indiferentemente do estado subseqente de A, at que a entrada lgica B seja verdade. C permanece no estado falso indiferentemente do estado subseqente de B, at que A volte a ser verdadeira. A sada lgica D (se usada), verdadeira quando C no for verdadeira, e D falso quando C for verdadeiro. Se as entradas S e R estiverem em simultaneidade, e se deseja que S tenha prioridade sobre R, ento S tem que ser circulado conforme apresentado em (a), e se R tem prioridade sobre S, ento R deve ser circulado conforme (b) da Figura 4.9.

FIG. 4.9: Blocos SET/RESET. A Figura 4.10(a) ilustra o cdigo correspondente aos blocos de memria com prioridade para SET e a Figura 4.10(b) ilustra o bloco com prioridade para RESET. Esse cdigo foi elaborado de acordo com a lgica booleana das memrias correspondentes.

68

FIG. 4.10: Cdigos SET/RESET. 4.5.3 BLOCOS TEMPORIZADORES A Figura 4.11 ilustra os blocos dos temporizadores que podem ser utilizados na elaborao do DBF segundo norma ISA 5.2 (ISA, 1992). Essa gura apresentada em trs colunas as quais representam: Figura 4.11(a): Bloco do Temporizador por atraso no acionamento (Delay Initiation of Output - DI ). A permanncia contnua da entrada lgica A em verdadeiro por um tempo t causa uma sada lgica B verdadeira quando t termina. B volta a falso quando A volta a falso. Figura 4.11(b): Bloco do Temporizador por atraso no desligamento (Delay Termination of Output - DT ). A passagem da entrada lgica A para verdadeiro, faz a sada lgica B torna-se verdadeira imediatamente. B torna-se falsa quando A torna-se falsa e permanecer neste estado por um tempo t. Figura 4.11(c): Bloco do Temporizador de tempo xo (Pulse Output - PO ). A passagem da entrada lgica A para verdadeiro, indiferentemente do estado subseqente, faz sada lgica B tornar-se verdadeira imediatamente. B permanece verdadeira por um tempo t, e ento torna-se falsa. Num modelo de um temporizador que leve em conta o passo-a-passo da contagem, a varivel de contagem do temporizador assume valores discretos que vo de zero ao tempo nal de contagem, numa quantidade dependente do passo de contagem. Numa representao em estado discreto para um temporizador, o nmero de estados seria muito grande, pois estes deveriam corresponder aos valores assumidos pela varivel de contagem. 69

FIG. 4.11: Blocos dos temporizadores DI, DT, PO. Para evitar esta complexidade na modelagem do temporizador. Trabalha-se com uma abstrao, como ilustram as Figuras 4.12, 4.13 e 4.14. Essas guras mostram mquinas de estado correspondentes aos temporizadores. A mquina de estado possui trs estados os quais variam de acordo com o tipo de temporizador utilizado. Os temporizadores DI representado na Figura 4.12 (a) e PO na Figura 4.14 (a) so formados pelos estados parado, contando e terminado. O temporizador DT na Figura 4.13 (a) formado pelos estados parado, contando e alto. Todos os estados e sadas dos temporizadores esto ilustrados nas respectivas guras sob a letra (b). Esses grcos foram utilizados para modelar os temporizadores e foram inspirados em IEC (2003).

FIG. 4.12: Mquinas de estado correspondente ao cdigo do temporizador DI. A Figura 4.15 ilustra os cdigos correspondentes a cada um dos blocos dos temporizadores DI, DT e PO respectivamente, que so traduzidos de forma direta a partir das respectivas mquinas de estado das Figuras 4.12, 4.13 e 4.14.

70

FIG. 4.13: Mquinas de estado correspondente ao cdigo do temporizador DT.

FIG. 4.14: Mquinas de estado correspondente ao cdigo do temporizador PO.

71

FIG. 4.15: Cdigos dos temporizadores. 4.5.4 CONSTRUO MODULAR DO CDIGO O cdigo para vericao no SMV construdo modularmente a partir do programa em DBF por interligao dos carimbos correspondentes aos blocos do diagrama. A Figura 4.16 ilustra as variveis denidas para os blocos do programa na Figura 4.5. So denidas as variveis Q1, Q2, Q3, e Q5 (memrias) e temp (temporizador DI). Uma importante considerao como se processa a varredura do programa. Assume-se que a varredura da esquerda para direita e de cima para baixo dos blocos. Assim, deve-se tomar cuidado na hora de modelar as variveis que voltam em linhas da direita para a esquerda para alimentar os outros blocos.

72

FIG. 4.16: Programa em Diagramas de Blocos Funcionais com as variveis auxiliares. A Figura 4.17 mostra como o processo de modularizao do sistema utilizando os carimbos para a traduo do diagrama da Figura 4.5 em cdigo SMV . Como se pode observar, a seqncia dos mdulos do programa so declarados a partir do mdulo principal main na linha 1, com as variveis de entradas booleanas nas linhas 2 a 5 e a instncia do programa na linha 6. Denem-se as sadas como K1, K2, K3 e T1 nas linhas 7 a 11 do programa. Em seguida, nas linhas de 12 a 13, colocam-se as especicaes do sistema na linguagem CTL. Nas linhas 14 a 19 so implantados os cdigos dos temporizadores e memrias que, para o exemplo, utilizam-se apenas o temporizador DI (mostrado) e as memrias com prioridade para SET e para RESET (no mostrados). A colocao dos blocos de memria, temporizadores e outros no precisa ser necessariamente nessa ordem. Para nalizar, faz-se o mdulo do programa ser vericado, onde se encontra a lgica de seqenciamento nas linhas 20 a 26 de acordo com o programa escrito em DBF na Figura 4.16. Consideram-se as sadas correspondentes aos blocos de memria do projeto como sadas Q1, Q2, Q3, uma sada auxiliar Qs e a sada do temporizador temp. Depois denem-se essas sadas como K1, K2, K3 e T1 nas linhas 27 a 31 do programa principal para facilitar a interpretao da resposta da vericao. importante observar que a sada do bloco do temporizador DI retorna aos blocos de memria Q2 e Q3 na Figura 4.16. Em conseqncia, necessrio no utilizar o next na interligao dos blocos do temporizador nas linhas 23 e 24 da Figura 4.17, pois se pode omitir erros na vericao devido a considerao de que a varredura do CLP se processa 73

da esquerda para a direita do diagrama.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

MODULE main VAR L : boolean; D : boolean; FT : boolean; c : programa_empresa(L,D,FT); DEFINE K1:= c.K1; K2:= c.K2; K3:= c.K3; T1:= c.T1; SPEC AG (L & !(D|FT) -> AF K1) ... MODULE DI(entrada) ... MODULE resetset(entrada_set,entrada_reset) ... MODULE setreset(entrada_set,entrada_reset) ... MODULE programa_empresa(L,D,FT) VAR Q1 : setreset(L,(D|FT)); Q2 : setreset((temp.saida & !next(Q3.saida)),(D|FT)); Q3 : setreset(L,(D|FT) | temp.saida); Qs : setreset(L,(D|FT)); temp : DI(next(Qs.saida)); DEFINE K1:= Q1.saida; K2:= Q2.saida; K3:= Q3.saida; T1:= temp.saida;

FIG. 4.17: Traduo do DBF em cdigo SMV.

4.6 VERIFICAO A vericao uma etapa que informa se o sistema est de acordo com as especicaes ou no, neste caso, informa-se um contra-exemplo. Um contra-exemplo uma seqncia de aes tomadas pelo programa de controle que viola as especicaes. Para as especicaes das linhas 7, 10 e 13 na Figura 4.18, ocorre uma violao do programa projetado (programa_empresa na linha 20 da Figura 4.17) com as especicaes desejadas. A Figura 4.18 mostra o resultado da vericao. As linhas 1 a 6, 8, 9, 11 e 12 mostram que o programa no viola as respectivas especicaes, descrevendo que so verdadeiras. Em conseqncia da violao, o SMV proporciona um contra-exemplo das especicaes que foram falsas, como mostrado nas Figuras 4.19, 4.20 e 4.21. 74

1 2 3 4 5 6 7 8 9 10 11 12 13

--------------

specification specification specification specification specification specification specification specification specification specification specification specification specification

AG AG AG AG AG AG AG AG AG AG AG AG AG

(L & !(D | FT) -> AF K1) is true (!K1 -> !E((!L) U (K1 & !L))) is true ((D | FT) & !L -> AF (!K1)) is true (K1 -> !E((!(D | FT)) U (!K1 & !(D | ... is true (T1 & !K3 & !(D | FT) -> AF K2) is true (!K2 -> !E((T1 & !K3) U (K2 & T1 & !K... is true ((D | FT) & !(T1 & !K3) -> AF (!K2)) is false (K2 -> !E((!(D | FT)) U (!K2 & !(D | ... is true (L & !K2 & !(D | FT | T1) -> AF K3) is true (!K3 -> !E((!(L & !K2)) U (K3 & !(L &... is false ((D | FT | T1) & !L -> AF (!K3)) is true (K3 -> !E((!(D | FT | T1)) U (!K3 & !... is true (!(K2 & K3)) is false

FIG. 4.18: Resposta da vericao.

75

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48

-- specification AG ((D | FT) & !(T1 & !K3) -> AF (!K2)) is false -- as demonstrated by the following execution sequence state 1.1: T1 = 0 K3 = 0 K2 = 0 K1 = 0 L = 0 D = 0 FT = 0 state 1.2: L = 1 state 1.3: K3 = 1 K1 = 1 L = 0 c.temp.estado = contando state 1.4: T1 = 1 state 1.5: K3 = 0 K2 = 1 L = 1 -- loop starts here -state 1.6: K3 = 1 L = 0 FT = 1 state 1.7: T1 = 0 K3 = 0 K1 = 0 L = 1 FT = 0 state 1.8: K3 = 1 K1 = 1 L = 0 c.temp.estado = contando state 1.9: T1 = 1 FT = 1

FIG. 4.19: Contra-exemplo da especicao na linha 7 da Figura 4.18. 76

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41

-- specification AG (!K3 -> !E((!(L & !K2)) U (K3 & !(L &... is false -- as demonstrated by the following execution sequence state 2.1: T1 = 0 K3 = 0 K2 = 0 K1 = 0 L = 0 D = 0 FT = 0 state 2.2: L = 1 -- loop starts here -state 2.3: K3 = 1 K1 = 1 L = 0 state 2.4: T1 = 1 FT = 1 state 2.5: T1 = 0 K3 = 0 K2 = 1 K1 = 0 FT = 0 state 2.6: L = 1 FT = 1 state 2.7: K3 = 1 K2 = 0 K1 = 1 L = 0 FT = 0

FIG. 4.20: Contra-exemplo da especicao na linha 10 da Figura 4.18.

77

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

-- specification AG (!(K2 & K3)) is false -- as demonstrated by the following execution sequence state 3.1: T1 = 0 K3 = 0 K2 = 0 K1 = 0 L = 0 D = 0 FT = 0 state 3.2: L = 1 state 3.3: K3 = 1 K1 = 1 L = 0 state 3.4: T1 = 1 state 3.5: K3 = 0 K2 = 1 L = 1 state 3.6: K3 = 1 L = 0

FIG. 4.21: Contra-exemplo da especicao na linha 13 da Figura 4.18. 4.6.1 REPROJETO Para a especicao da linha 7 da Figura 4.18 o contra-exemplo na Figura 4.19 ilustra um trao de erro do programa. Analisando o contra-exemplo pode-se ver que no estado 1.9 da linha 46 ocorre a proteo de sobrecorrente atravs do rel trmico (FT) e a prioridade para SET no impe o desligamento geral do sistema, ocasionando uma falha. Para a especicao da linha 10 da Figura 4.18, o contra-exemplo na Figura 4.20 mostra que no estado 2.6 na linha 32 o sistema Y e o rel trmico (L = 1 e F T = 1) acionam simultaneamente. O sistema Y continua ativo e a prioridade para o sistema desligar devido proteo do rel trmico. 78

Por m a especicao da linha 13 da Figura 4.18. O contra-exemplo na Figura 4.21 mostra um trao de erro que no estado 3.5, na linha 23, ocorre um erro devido ao religamento do sistema estando K1 e K2 ainda ativos. O religamento do sistema faz com que K3 seja ativado no estado 3.6 na linha 28. Porm, sendo prioridade para SET, K3 ca ativo em simultaneidade com K2. Aps a anlise dos traos de eventos, possvel modicar o programa de aplicao para que estes traos sejam suprimidos, o que corresponde a etapa de reprojeto. A partir dos contra-exemplos identicam-se que a insero dos blocos de memria com prioridade SET violam as especicaes e o correto a prioridade RESET. O sistema reprojetado est na Figura 4.22. A posterior vericao para o reprojeto na Figura 4.23 indicou que todas as especicaes da Figura 4.18 so verdadeiras para o sistema reprojetado.

FIG. 4.22: Reprojeto com base no contra-exemplo.

79

1 2 3 4 5 6 7 8 9 10 11 12

MODULE VAR Q1 : Q2 : Q3 : Qs : temp DEFINE K1:= K2:= K3:= T1:=

programa_reprojeto(L,D,FT) resetset(L,(D|FT)); resetset((temp.saida & !next(Q3.saida)),(D|FT)); resetset(L,(D|FT) | temp.saida); resetset(L,(D|FT)); : DI(next(Qs.saida)); Q1.saida; Q2.saida; Q3.saida; temp.saida;

FIG. 4.23: Reprojeto na linguagem SMV. 4.7 RESUMO DO CAPTULO Este captulo tem como contribuies a criao de um procedimento de traduo de processos escrito em DBF para um cdigo aceito pelo SMV. Tratam-se da sistematizao de padres na traduo da MCE e em especicaes na linguagem CTL e da insero da vericao no projeto de sistemas automatizados escritos na linguagem DBF. Uma vantagem em relao a abordagens semelhantes a busca pela sistematizao dos procedimentos de vericao, visando futuro automatismo do processo.

80

5 APLICAO NA AUTOMAO DE UM AQUECEDOR A CHAMA

Este captulo mostra a aplicao da vericao de modelos ao projeto de automao de um Aquecedor a Chama (API, 1997). Trata-se em particular da automao do processo de purga, etapa da inicializao do aquecedor (API, 1997). Os documentos de projeto analisados na vericao so a descrio literal das especicaes, a matriz de causa e efeito e o programa em DBF, escrito segundo a norma ISA 5.2 (ISA, 1992). 5.1 AUTOMAO DO PROCESSO DE PURGA Nesta seo descreve-se a documentao do projeto da automao do processo de purga de um aquecedor a chama (API, 1997). 5.1.1 SEQNCIA DE PURGA O processo de purga do aquecedor consiste nos seguintes passos: a) Para iniciar a seqncia, o sinal Permisso de Purga deve estar ativo; b) O operador comanda Iniciar Purga; c) A vlvula de vapor deve ser aberta automaticamente, e a indicao Purga em Andamento deve comear a piscar quando a chave de m-de-curso ZSH-XV-VAPOR conrmar a abertura total da vlvula; d) Uma vez que a indicao de Purga em Andamento observada, um temporizador deve ser iniciado, e o tempo de purga deve comear. O tempo de purga deve ser T1; e) Se o operador fecha a vlvula de vapor antes do tempo total de purga ou, se o operador comandar Desistncia de Purga, a seqncia de inicializao deve ser inibida e uma nova purga ser necessria para habilitar qualquer ignio; f) Se qualquer intertravamento que cause o desligamento geral do aquecedor a chama disparado durante a operao de purga, a seqncia de inicializao deve ser abortada e, aps o trmino da operao de purga, a ignio no ser permitida; 81

g) O fechamento da vlvula de vapor aps o tempo de purga ser automtico, e a indicao Permisso para Ignio piscar durante T2. 5.1.2 LISTA DE ENTRADAS E SADAS As Tabelas 5.1 e 5.2 apresentam a correspondncia lgica de entradas e sadas. Considera-se que todas as variveis so binrias, assumindo os valores 0 (equivalente a falso ou o ) e 1 (equivalente a verdadeiro ou on ). TAB. 5.1: Variveis de entrada do sistema Sensores/Sinais de entrada Permisso de Purga Iniciar Purga Chave ZSH-XV-VAPOR Desistncia de Purga Intertravamento para desligamento do purga Varivel perm_purg init_purg fch_xv des_purg sd_purg Correspondncia lgica habilitada = 1 acionado = 1 acionada = 1 acionado = 1 acionado = 1

TAB. 5.2: Variveis de sada do sistema Atuadores/Indicadores Abertura da vlvula de vapor Purga em Andamento Permisso para Ignio Varivel abre_xv indic_purg indic_ignit Correspondncia lgica para abrir = 1 acionado = 1 acionada = 1

5.1.3 MATRIZ DE CAUSA E EFEITO A Figura 5.1 mostra a Matriz de Causa e Efeito para o sistema descrito anteriormente.

82

perm_purg

! des_purg

des_purg

! sd_purg

init_purg

Chave de fim-de-curso ZSH-XVVAPOR fch_xv

sd_purg Intertravamento SD-PURGA

T1

No acontecer Intertravamento SD-PURGA

CAUSA

Sinal de Permisso de Purga

Operador no Comanda Desistncia de Purga

Comando de desistncia de Purga

Comando de Iniciar Purga

EFEITO
Abre vlvula de vapor Indicao de Purga em Andamento Indicao Permisso para Ignio Fecha vlvula de vapor Fim da Indicao de Purga em Andamento Fim da Indicao de Permisso para Ignio abre_xv indic_purg indic_ignit ! abre_xv ! indic_purg ! indic_purg

X X

X X

X X X X X X X X

FIG. 5.1: Matriz de Causa e Efeito do sistema Purga. Na matriz de causa e efeito da Figura 5.1, T1 e T2 so variveis binrias que indicam o trmino dos tempos de purga e ignio respectivamente (T1, T2=1 equivale ao trmino da contagem). 5.1.4 PROJETO DO PROGRAMA EM DBF Na Figura 5.2 est o projeto de automao do sistema Purga do Aquecedor a Chama escrito na linguagem DBF. A interpretao dos smbolos segue a norma ISA 5.2 (ISA, 1992), alguns smbolos adicionais so apresentados na Figura 5.3.

83

Ignio Finalizada

Purga Finalizada

T2

FIG. 5.2: Projeto do sistema Purga.

FIG. 5.3: Tipos de sinal, segundo a norma ISA 5.2 (ISA, 1992). 5.2 MODELAGEM DAS ESPECIFICAES As condies para verdadeiro e falso da varivel abre_xv esto nas equaes abaixo. CON = init_purg COF F = (T 1|des_purg |sd_purg |!perm_purg |indic_ignit) (5.1)

(5.2)

A condio para verdadeiro da varivel abre_xv que o operador comande o incio de purga (init_purg). A condio para falso da varivel abre_xv ou que o tempo de purga 84

termine (T1), ou que o operador comande a desistncia de purga (des_purg), ou que haja um intertravamento para desligamento da purga (sd_purg), ou que a permisso de purga seja desabilitada (!perm_purg), ou que a ignio esteja em andamento (indic_ignit). As condies para verdadeiro e falso da varivel indic_purg esto abaixo: CON = (f ch_xv &abre_xv ) (5.3)

COF F = (des_purg |sd_purg |T 1|!perm_purg |!f ch_xv )

(5.4)

A condio para verdadeiro da varivel indic_purg que a chave de m-de-curso conrme a abertura total da vlvula (fch_xv) e esteja ativo o comando da abertura da vlvula de vapor (abre_xv). A condio para falso da varivel indic_purg ou que exista desistncia de purga (des_purg), ou intertravamento da purga (sd_purg), ou que o tempo de purga termine (T1), ou que no exista permisso de purga (!perm_purg), ou que o operador feche manualmente a vlvula de vapor (!fch_xv). As condies para verdadeiro e falso da varivel indic_ignit so: CON = T 1 (5.5)

COF F = (sd_purg |T 2)

(5.6)

A condio para verdadeiro da varivel indic_ignit que o tempo de purga termine (T1). A condio para falso da varivel indic_ignit ou que exista intertravamento da purga (sd_purg), ou que o tempo de ignio termine (T2). De acordo com as especicaes sistematizadas para o acionamento (especicaes 4.1 e 4.2) e desligamento (especicaes 4.3 e 4.4), desenvolvem-se as especicaes para o sistema. As especicaes de acionamento para abre_xv:

AG((init_purg &!(T 1|des_purg |sd_purg |!perm_purg |indic_ignit) > AF(abre_xv )) (5.7) AG(!abre_xv >!E[!init_purg U(abre_xv &!init_purg )]) 85 (5.8)

 Especicaes de desligamento para abre_xv:

AG((T 1|des_purg |sd_purg |!perm_purg |indic_ignit)&!init_purg > AF(!abre_xv )) (5.9)

AG(abre_xv >!E[!(T 1|des_purg |sd_purg |!perm_purg |indic_ignit)U(!abre_xv & !(T 1|des_purg |sd_purg |!perm_purg |indic_ignit))]) Especicaes de acionamento para indic_purg: (5.10)

AG((f ch_xv &abre_xv )&!(des_purg |sd_purg |T 1|!perm_purg |!f ch_xv ) > AF(indic_purg )) (5.11)

AG(!(indic_purg ) >!E[!(f ch_xv &abre_xv )U(indic_purg &!(f ch_xv &abre_xv ))]) (5.12) Especicaes de desligamento para indic_purg:

AG((des_purg |sd_purg |T 1|!perm_purg |!f ch_xv )&!(f ch_xv &abre_xv ) > AF(!indic_purg )) (5.13)

AG(indic_purg >!E[!(des_purg |sd_purg |T 1|!perm_purg |!f ch_xv )U (!indic_purg &!(des_purg |sd_purg |T 1|!perm_purg |!f ch_xv ))]) Especicaes de acionamento para indic_ignit: (5.14)

AG(T 1&!(sd_purg |T 2) > AF(indic_ignit))

(5.15)

AG(!(indic_ignit) >!E[!T 1U(indic_ignit&!T 1)]) 86

(5.16)

 Especicaes de desligamento para indic_ignit:

AG((sd_purg |T 2)&!T 1 > AF(!indic_ignit))

(5.17)

AG(indic_ignit >!E[!(sd_purg |T 2)U(!indic_ignit&!(sd_purg |T 2))])

(5.18)

Alm das especicaes acima, baseado no conhecimento do sistema, so expressas situaes indesejadas para o projeto (especicaes de segurana). Para o sistema purga foram identicadas trs situaes que no podem ocorrer, listadas abaixo. A especicao na equao 5.19 expressa que no pode ocorrer indicao de Purga em Andamento (indic_purg) com a vlvula de vapor fechada (!fch_xv):

AG!(indic_purg &!f ch_xv )

(5.19)

A especicao na equao 5.20 expressa que no pode ocorrer a no permisso de purga (!perm_purg) seguida do comando de abrir a vlvula de vapor (AX(abre_xv)):

AG!(!perm_purg &AX(abre_xv ))

(5.20)

A especicao na equao 5.21 expressa que no pode estar a purga desabilitada (!(perm_purg)) e, em seguida, ocorrer a indicao de purga em andamento (indic_purg):

AG!(!perm_purg &AX(indic_purg )) 5.3 MODELAGEM DO PROGRAMA

(5.21)

Na Figura 5.4, reproduz-se a Figura 5.2 com insero de variveis auxiliares para modelagem de programa no SMV. A Figura 5.5 representa a modelagem do sistema purga utilizando os carimbos correspondentes aos blocos do diagrama da Figura 5.4. O mdulo principal main composto pelas variveis de entrada booleanas nas linhas 2 a 7, seguida da representao das sadas Q1, Q2, temp1 e temp2 nas linhas 9 a 13, 87

representadas como instncias dos mdulos denidos nas linhas 24 a 27. Depois so representadas as especicaes do sistema, seguidas dos mdulos dos blocos temporizador e memria.

FIG. 5.4: Projeto do sistema Purga com insero de variveis auxiliares.

88

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27

MODULE main VAR perm_purg : boolean; init_purg : boolean; fch_xv : boolean; des_purg : boolean; sd_purg : boolean; Q1 : resetset(init_purg,(Q2.saida|!perm_purg|sd_purg|des_purg)); Q2 : resetset(next(temp1.saida),(sd_purg|temp2.saida)); temp1 : DI(next(Q1.saida) & fch_xv); temp2 : DI(next(Q2.saida)); DEFINE abre_xv:= Q1.saida; indic_purg:= Q1.saida & fch_xv; indic_ignit:= Q2.saida; T1:= temp1.saida; T2:= temp2.saida; SPEC AG !(indic_purg & !fch_xv) ... MODULE DI(entrada) ... MODULE resetset(entrada_set,entrada_reset) ...

FIG. 5.5: Modelo do Programa no SMV. 5.4 VERIFICAO Aps a modularizao do sistema feita a vericao com as especicaes descritas na Seo 5.2. O resultado da vericao mostrado na Figura 5.6. Observa-se que todas as especicaes so verdadeiras. Isso quer dizer que no ocorre uma violao das especicaes por parte do programa de automao da Purga projetado.

89

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

----------------

specification specification specification specification specification specification specification specification specification specification specification specification specification specification specification

AG AG AG AG AG AG AG AG AG AG AG AG AG AG AG

(init_purg & !(T1 | des_purg | sd_pur... (!abre_xv -> !E((!init_purg) U (abre_... ((T1 | des_purg | sd_purg | !perm_pur... (abre_xv -> !E((!(T1 | des_purg | sd_... (fch_xv & abre_xv & !(des_purg | sd_p... (!indic_purg -> !E((!(fch_xv & abre_x... ((des_purg | sd_purg | T1 | !perm_pur... (indic_purg -> !E((!(des_purg | sd_pu... (T1 & !(sd_purg | T2) -> AF indic_ign... (!indic_ignit -> !E((!T1) U (indic_ig... ((sd_purg | T2) & !T1 -> AF (!indic_i... (indic_ignit -> !E((!(sd_purg | T2)) ... (!(indic_purg & !fch_xv)) is true (!(!perm_purg & AX abre_xv)) is true (!(!perm_purg & AX indic_purg)) is true

is is is is is is is is is is is is

true true true true true true true true true true true true

FIG. 5.6: Resposta da vericao do sistema Purga. 5.5 RESUMO DO CAPTULO Este Captulo mostra a importncia da aplicao da vericao de modelos aos Sistemas Industriais Automatizados. Embora o projeto apresentado esteja correto, importante observar que a modularizao e sistematizao proposta no trabalho mostra que o tempo gasto para a validao do projeto pequeno, podendo melhorar com a automatizao da vericao. No foi preciso interromper, parar ou transferir nenhum processo em campo para testar o programa do CLP, ao mesmo tempo que se aumenta a conabilidade inerente ao projeto.

90

6 CONCLUSO

Neste captulo apresentado um resumo, do ponto de vista metodolgico, das contribuies desta dissertao. So descritas as contribuies, assim como as perspectivas para futuros estudos, baseados na experincia adquirida durante o desenvolvimento deste trabalho. 6.1 CONTRIBUIES VERIFICAO DE MODELOS O Captulo 4 apresenta as contribuies deste trabalho para a sistematizao de processos de Sistemas Industriais Automatizados. Inicialmente apresentada uma tcnica de sistematizao na traduo de especicaes escritas a partir da MCE. Este procedimento se baseia em determinar as condies que levam uma varivel de sada a assumir uma condio verdadeira ou falsa. Isso quer dizer, condies de acionamento e desligamento de variveis de sada. Duas maneiras sistematizadas para descrever especicaes de desligamento foram criadas. Uma implica em condies que podem ocorrer para o acionamento ou desligamento das variveis e a outra representa a obrigatoriedade de apenas determinadas condies levarem as variveis de sada a se tornarem falsas ou verdadeiras. Outros tipos sistematizados de especicaes so baseadas no conhecimento do sistema. Estes tipos podem expressar a segurana, a alcanabilidade e a vivacidade do sistema. Mostram sempre o comportamento das variveis de sada. Uma outra contribuio a criao de um mtodo de traduo de sistemas escritos em DBF para o cdigo SMV. Foram desenvolvidos gabaritos de cdigos SMV para estruturas tpicas da Norma ANSI/ISA 5.2. Sistematizou-se o procedimento incluindo desde estruturas lgicas bsicas at estruturas mais complexas, como elementos de memria e blocos temporizadores. Tais blocos possuem correspondentes equivalentes na linguagem DBF denidas na norma para programao de CLP IEC 61131-3 (IEC, 2003). Criou-se tambm um procedimento para a construo modular do cdigo para a vericao no SMV. A vericao dos sistemas Y e Purga, mostraram a ecincia do reprojeto orientado pelo trao de eventos do erro fornecido pelo SMV. Em muitos casos, entretanto, a especicao testada mostrou-se uma propriedade falsa verdadeira, sendo muito restrita 91

para o sistema, obrigando a uma reescrita da mesma. No Captulo 5, demonstra-se a aplicabilidade do mtodo proposto ao se abordar um projeto de automao realista da etapa de purga de um aquecedor a chama. Uma vantagem, em relao a abordagens anteriores, a busca pela sistematizao dos procedimentos de vericao, visando um futuro automatismo do processo. A fase de desenvolvimento do trabalho deu origem a dois artigos, o OLIVEIRA et al. (2006b) apresenta a aplicao da vericao a sistemas instrumentados de segurana e o OLIVEIRA et al. (2006a) a sistematizao dos procedimentos de vericao de modelos aplicada aos sistemas industriais automatizados controlados por CLP. 6.2 LIMITAES DA ABORDAGEM Um problema na vericao de modelos utilizando a ferramenta SMV que, dependendo da quantidade de variveis de entrada para determinadas especicaes, o SMV no mostra o contra-exemplo, apenas descreve que o programa no est de acordo com a especicao. Isso uma falha da ferramenta e pode ser corrigido por uso de outras ferramentas. Para tratamento de sistema de grande porte necessrio que seja feito algum tipo de decomposio estrutural do processo, para que seja tratvel pela ferramenta de vericao. Este ponto ainda est em desenvolvimento na pesquisa da vericao de modelos (CLARKE et al., 1999). O mtodo funcionou bem para sistemas com um temporizador ou onde no h necessidade de vericar o funcionamento paralelo de dois temporizadores distintos. Neste caso, dever-se-ia buscar uma ferramenta de vericao que tratasse do tempo explicitamente, como os autmatos temporizados tratados no HyTech (HENZINGER et al., 1997), CheckMate (CHUTINAN, 1999) ou UPAAL (DAVID & LARSEN, 2004). 6.3 PERSPECTIVAS Com relao aos estudos apresentados neste trabalho, existem alguns pontos que merecem ateno e que representam possibilidades de trabalhos futuros. Os cdigos criados para a representao do programa DBF na linguagem SMV, no foram retirados do cdigo fonte do CLP, mas sim da sua lgica abstrada em mquinas de estado. Portanto, um passo adicional interessante seria uma ferramenta que extrasse o modelo a ser vericado diretamente do programa do CLP. 92

Foi desenvolvido um procedimento de vericao de programas de CLP modular, mas esse procedimento no automatizado. No se tem conhecimento de uma ferramenta computacional para vericao com tal funcionalidade.

93

7 REFERNCIAS BIBLIOGRFICAS

ALIPERTI, J. Gerenciamento de Alarmes: uma Situao Alarmante. Brasil In Tech, (70):1821, Abril 2005. API. Instrumentation and Control Systems for Fired Heaters and Steam Generators. API Recommended Practice 556, Maio 1997. BRYANT, R. E. e MUSGRAVE, G. Panel: User Experience with High Level Formal Verication. Em Design Automation Conference, pg. 327, 1998. CADENCE. Cadence SMV - Symbolic model checker. http://www.kenmcmil.com/, junho 2002. CAVADA, R. e CIMATTI, A. NuSMV version 2.2. nusmv@irst.itc.it, Novembro 2004. CHUTINAN, A. Hybrid System Verication Using Discrete Model Approximations. www.cs.cmu.edu/ webk/checkmate, Novembro 1999. CLARKE, E. M. e EMERSON, E. A. Design and synthesis of synchronization skeletons using branching time temporal logic. Em In Logic of Programs: workshop, Yorktown Heights, NY, Maio 1981. CLARKE, E. M., EMERSON, E. A. e SISTLA, A. P. Automatic verication of nite-state concurrent systems using temporal logic specications. ACM Transactions on Programming Languages and Systems, 8(2):244263, 1986. CLARKE, E. M., GRUMBERG, O., HIRAISHI, H., JHA, S., LONG, D. E., MCMILLAN, K. L. e NESS, L. A. Verication of the Futurebus + cache coherence protocol. Em Claesen, 1993. CLARKE, E. M., GRUMBERG, O. e PELED, D. A. Model Checking. The MIT Press, Cabridge, Massachusetts 02142, 1st edition, 1999. CMU. The SMV system* for SMV: Version 2.5.4. elcheck/smv.html, Novembro 2000. www.cs.cmu.edu/ mod-

DAVID, G. e LARSEN, K. G. A Tutorial on UPPAAL: Formal Methods for the Design of Real-Time Systems. International School on Formal Methods for the Design of Computer, Comunication, and Software Systems, Nevembro 2004. DIAS, C. A. Tcnicas Avanadas de Instrumentao & Controle de Processos Industriais. Editora e Grca ao Livro Tcnico, cad.rj@uol.com.br, 1a edition, 2005. FABIAN, M. e HELLGREN, A. PLC-based Implementation of Supervisory Control for Discrete Event Systems. Em IEEE Conference on Decision and Control, pgs. 1618, Tampa, Florida, USA, Dezembro 1998. 94

FALCIONE, A. e KROGH, B. H. Design Recovery for Relay Ladder Logic. IEEE Transactions on Automatic Control, 13(2):9098, abril 1993. GIBBS, W. W. Softwares Chonic Crisis. Scientic American, pgs. 8695, Setembro 1994. HENZINGER, T. A., HO, P. H. e WONG-TOI, H. HyTech: A Model Checker for Hybrid Systems. Software tools for Technology Transfer, 1997. HUGUES, G. E. e CRESWELL, M. J. Introduction to Modal Logic. Methuen, 1977. IEC. Specication Language GRAFCET for Sequential Function Charts. IEC International Standard 60848, Fevereiro 1999. IEC. Programmable controllersPart3: Programming languages. IEC International Standard 61131 3, Janeiro 2003. ISA. Binary Logic Diagrams for Process Operations ANSI/ISA 5.2. ISA-The Instrumentation, Systems, and Automation Society, Julho 1992. LAMPRIRE-COUFFIN, S., ROSSI, J.-M. e LESSAGE, J. Formal Validation of PLC Programs : A Survey. University Laboratory in Automated Production Research, Julho 1999. LONG, D. E. Model Checking, Abstration, and Compositional Reasoning. Tese (doutorado), Carnegie Mellon University, USA, 1993. MCMILLAN, K. L. Symbolic Model Checking: An Approach to the State Explosion Problem. Tese (doutorado), Carnegie Mellon University, USA, novembro 1993. MOON, I. Modeling Programmable Logic Controllers for Logic Verication. IEEE Transactions on Automatic Control, 14(2):5359, Abril 1994. OLIVEIRA, C. H. C., CUNHA, A. E. C. e CAMPOS, M. C. M. M. Vericao de Modelos Aplicada aos Sistemas Industriais Automatizados por Controladores Lgicos Programveis. CBA Congresso Brasileiro de Automtica, Outubro 2006a. OLIVEIRA, C. H. C., CUNHA, A. E. C. e CAMPOS, M. C. M. M. Vericao Formal de Sistemas de Segurana Instrumentados. INDUSCON Conferncia Internacional de Aplicaes Industriais, Abril 2006b. QUIELLE, J. P. e SIFAKIS, J. Specication and verication of concurrent systems in CESAR. Em ACM International Symposium on Programming, pgs. 337350, 1982. RAUSCH, M. e KROGH, B. Formal Verication of PLC Programs. Em American Control Confernce ACC, pgs. 234238, Philadelphia, Pennsylvania, Junho 1998. SMET, O. e ROSSI, O. Verication of a controller for a exible manufacturing line written in Ladder Diagram via model-checking. Em American Control Confernce ACC, pgs. 810, Anchorage, Maio 2002. 95

SONG, M. J., KOO, S. R. e SEONG, P. H. Development of a Verication Method for Timed Function Blocks Using ESDT and SMV. IEEE International Symposium on High Assurance Systems Engineering (HASE2004), 373(1):285286, Abril 2004. SPARACO, P. Board Faults Ariane 5 Software. Aviation Week & Space Technology, pgs. 3335, Julho 1996. VLKER, N. e KRMER, B. J. Modular Verication of Function Block Based indutrial Control Systems. Em IFAC-IFIP, pgs. 6671, Schlo Dagstuhl, Germany, Junho 1999. XIYING, W. e LITZ, L. Model Checking: Towards Generating a Correct Specication for Logic Contollers. Em American Control Conference - ACC, pgs. 810, Anchorage, AK, Maio 2002.

96

8 APNDICE

97

8.1 MANUAL DO VERIFICADOR DE MODELOS SIMBLICOS (SYMBOLIC MODEL CHECKING - SMV) VERSO 2.5.4 Este documento apresenta um resumo do manual da ferramenta SMV, disponvel em CMU (2000). O SMV uma ferramenta para vericar sistemas de estados nitos contra especicaes escritas na lgica temporal CTL. Este documento descreve a sintaxe e a semntica da linguagem de entrada do SMV, e as funcionalidades do vericador de modelos. Todos os exemplos neste documento esto disponveis na distribuio com o software (CMU, 2000). 8.2 LINGUAGEM DE ENTRADA Considere o programa na linguagem de entra do SMV ilustrado na Figura 8.1 (arquivo short.smv na distribuio).
1 2 3 4 5 6 7 8 9 10 11 12

MODULE main VAR request : boolean; state : {ready,busy}; ASSIGN init(state) := ready; next(state) := case state = ready & request : busy; 1 : {ready,busy}; esac; SPEC AG(request -> AF state = busy)

FIG. 8.1: Listagem de short.smv. O arquivo de entrada descreve ambos o modelo e a especicao. O modelo uma estrutura Kripke, cujo estado denido por uma coleo de variveis de estado, que podem ser booleanas ou escalares. A varivel request (pedido) declarada para ser booleana na Figura 8.1, enquanto a varivel state (estado) um escalar que assume os valores ready (disponvel) ou busy (ocupado). A relao de transio da estrutura Kripke, e seu estado inicial (ou estados), so determinados por uma coleo de atribuies paralelas, que so introduzidas pela palavra ASSIGN. Na Figura 8.1, o valor inicial da varivel state ready. O valor seguinte de state determinado pela expresso na Figura 8.2 O valor de uma expresso case dado pela primeira expresso no lado direito de um : 98

1 2 3 4

case state = ready & request : busy; 1 : {ready,busy}; esac;

FIG. 8.2: Expresso cuja condio no lado esquerdo seja verdadeira. Assim, se state = ready &request for verdadeiro, ento o resultado da expresso case ready, seno, o conjunto {ready,busy}. Quando um conjunto atribudo a uma varivel, o resultado uma escolha no determinista entre os valores disponveis. Assim, se o valor do state no for ready, ou request for falso, o valor de state no estado seguinte pode ser ready ou busy. As escolhas no deterministas so teis para descrever os sistemas que no estejam ainda inteiramente implementados, ou para modelos abstratos de protocolos complexos, onde o valor de algumas variveis de estado no pode ser determinado completamente. Observe que request no est atribudo neste programa. Isto deixa o sistema do SMV livre para escolher qualquer valor para esta varivel, dando-lhe a caracterstica de uma entrada sem restries para o sistema. A especicao do sistema aparece como uma frmula CTL aps a palavra-chave SPEC. O vericador de modelos SMV verica se todos os possveis estados iniciais satisfazem especicao. Na Figura 8.1, a especicao arma que invariavelmente se request for verdade, ento inevitavelmente o valor de state busy. A Figura 8.3 ilustra a denio dos mdulos reusveis e expresses. um modelo de circuito contador binrio de 3 bits. Observe que o mdulo de nome main possui o signicado especial no SMV, na mesma maneira que faz na linguagem de programao C. A ordem de denies no arquivo de entrada no possui especicao de seqencia. Neste exemplo, uma varivel pode tambm ser uma instncia de um mdulo denido pelo usurio. O mdulo neste caso o counter_cell, que instanciado trs vezes, com os nomes bit0, bit1 e bit2. O mdulo-clula do contador possui um parmetro formal carry_in. Na instncia bit0, este parmetro possui valor 1. Na instncia bit1, carry_in dado pelo valor de bit0. carry_out. Esta expresso avaliada no contexto do mdulo principal. Entretanto, uma expresso na forma a.b denota b componente do mdulo a, justo como se o mdulo a fosse uma estrutura de dados em uma linguagem de programao padro. Da, carry_in dentro do mdulo bit1 o carry_out do mdulo bit0. A palavra-chave DEFINE usada para atribuir a expresso value & carry_in para o smbolo carry_out. O efeito da indicao DEFINE poderia ter sido obtido declarando uma varivel e 99

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

MODULE main VAR bit0 : counter_cell (1); bit1 : counter_cell (bit0.carry_out); bit2 : counter_cell (bit1.carry_out); SPEC AG AF bit2.carry_out MODULE counter_cell (carry_in) VAR value : boolean; ASSIGN init (value) := 0; next (value) := value + carry_in DEFINE carry_out := value & carry_in;

mod 2;

FIG. 8.3: Programa e expresses reusveis atribuindo seu valor, como segue:
1 2 3 4

VAR carry_out : boolean; ASSIGN carry_out := value & carry_in

FIG. 8.4: Atribuio Observe que neste caso, o valor atual da varivel atribudo, ao invs do valor seguinte. Os smbolos denidos so s vezes preferveis s variveis, desde que no introduzam uma varivel nova na representao BDD do sistema. Um ponto fraco dos smbolos denidos que no podem ser dados valores no deterministas. 8.3 SINTAXE E SEMNTICA Esta seo descreve a sintaxe e a semntica da linguagem de entrada do SMV. 8.3.1 CONVENES LXICAS Um tomo na sintaxe descrita abaixo pode ser toda a seqncia dos caracteres no conjunto {A-Z, a-z, 0-9,_,-}, desde que comeem com um caracter alfabtico. Todos os caracteres em um nome so signicantes, e maisculas e minsculas so diferenciadas. Os caracteres de espao em branco so o espao, a tabulao e a nova linha. Toda a srie que comea com dois traos (--) e que termina com uma nova linha um comentrio. Um number toda a seqncia de dgitos. Todos os outros smbolos analisados e reconhecidos so includos nas citaes e expresses da sintaxe abaixo. 100

8.3.2 EXPRESSES As expresses so construdas a partir das variveis, constantes, e uma coleo de operadores, inclusive conectivos booleanos, operadores aritmticos inteiros, e expresses case. A sintaxe das expresses como segue: expr :: atom | number | id | "!" expr | expr1 "&" expr2 | expr1 "|" expr2 | expr1 "->" expr2 | expr1 "<->" expr2 | expr1 "=" expr2 | expr1 "!=" expr2 | expr1 "<" expr2 | expr1 ">" expr2 | expr1 "<=" expr2 | expr1 ">=" expr2 | expr1 "+" expr2 | expr1 "-" expr2 | expr1 "*" expr2 | expr1 "/" expr2 | expr1 "mod" expr2 | "next" | set_expr | case_expr "(" id ")" expr2 ;; constante simblica ;; constante numrica ;; identificador varivel ;; lgica no ;; lgica e ;; lgica ou ;; implicao lgica ;; equivalncia lgica ;; igualdade ;; desigualdade ;; menor que ;; maior que ;; menor ou igual que ;; maior ou igual que ;; adio de inteiro ;; subtrao de inteiro ;; multiplicao de inteiro ;; diviso de inteiro ;; resto de inteiro ;; valor seguinte ;; uma expresso set ;; uma expresso de case

Uma id, ou identicador, um smbolo ou expresso que identica um objeto, tal como uma varivel ou um smbolo denido. Uma vez que uma id pode ser um tomo, h uma possvel ambigidade se uma varivel ou um smbolo denido tiverem o mesmo nome que uma constante simblica. Tal ambigidade marcada pelo interpretador como um erro. A expresso next(x) refere-se ao valor do identicador x no prximo estado. A ordem para analisar a precedncia gramatical , de cima para abaixo, 101

*,/ +,mod =,!+,<,>,<=,>= ! & | ->,<-> Operadores de igual precedncia se associam esquerda, como exceo da implicao ->, que se associa direita. Parnteses podem ser usados para agrupar expresses. Uma expresso case possui a sintaxe: case_expr :: "case" expr_a1 ":" expr_b1 ";" expr_a2 ":" expr_b2 ";" ... expr_an ":" expr_bn ";" esac Uma expresso case retorna ao valor da primeira expresso no lado direito, tal que a condio correspondente no lado esquerdo seja verdadeira. Assim, se expr_a1 for verdadeiro, ento o resultado expr_b1. Seno, se expr_a2 for verdadeiro, ento o resultado expr_b2 etc. Se nenhuma das expresses no lado esquerdo for verdadeira, o resultado da expresso case o valor numrico 1. um erro para toda a expresso da esquerda para retornar um valor diferente de 0 ou 1. Uma expresso set possui a sintaxe: dec1 :: "VAR" atom1 ":" type1 atom2 ":" type2 ... O tipo associado a uma declarao varivel pode ser um booleano, um escalar, um mdulo denido pelo usurio, ou um vetor de qualquer um dos anteriores. 102 ";" ";"

8.3.3 DECLARAO DA ASSIGN Uma declarao de atribuio tem a forma: dec1 :: "ASSIGN" dest1 ":=" expr1 ";" dest2 ":=" expr2 ";" ... onde dest1 e dest2 tem a forma: dest :: atom | | "init" "next" "(" atom ")" "(" atom ")"

No lado esquerdo da atribuio, o tomo denota o valor atual de uma varivel, init(atom) denota seu valor inicial, e next(atom) denota seu valor no prximo estado. Para que o programa seja implementvel, deve ser estabelecido uma ordem em que as atribuies podem ser executadas tais que nenhuma varivel seja atribuda depois que seu valor seja referenciado. Este no o caso se houver uma dependncia circular entre as atribuies em qualquer processo dado. Assim, tal circunstncia um erro. Alm do mais, um erro se a uma varivel for atribudo um valor mais de uma vez em em um dado instante. um erro se: a) o valor seguinte ou atual de uma varivel for atribudo mais de uma vez em um processo dado, ou b) o valor inicial de uma varivel for atribudo mais de uma vez no programa, ou c) o valor corrente e valor inicial de uma varivel forem ambos atribudos no programa, ou d) o valor corrente e o valor seguinte de uma varivel forem ambos atribudos no programa. 8.3.4 DECLARAO SPEC A especicao de sistema dada como uma frmula na lgica temporal CTL, introduzida pela palavra chave SPEC. A sintaxe desta declarao : 103

dec1

::

"SPEC"

ctlform

Uma formula CTL tem a sintaxe ctlform :: expr ;; uma expresso booleana | | | | | | | "!" ctlform "&" "|" "->" "<->" ctlform2 ctlform2 ctlform2 ctlform2 ;; no lgico ;; e lgico ;; ou lgico ;; implicao lgica ;; equivalncia lgico ;; quantificador de caminho existencial ;; quantificador de caminho universal ctlform1 ctlform1 ctlform1 ctlform1 "A"

"E" pathform pathform

A sintaxe da frmula de caminho : pathform :: ctlform ctlform ctlform "U" ctlform2 ;; ;; ;; ;; prxima vez eventualmente globalmente at que

"X" "F" "G"

ctlform1

A ordem de precedncia dos operadores (de cima para baixo) E,A,X,F,G,U ! & | ->,<-> Os operadores de precedncia igual se associam esquerda, exceo da implicao ->, que se associa direita. Parnteses podem ser usados para agrupar expresses. um erro uma expresso em uma frmula CTL conter um operador next( ) ou retornar um valor diferente de 0 ou 1. Se houver mais de uma declarao SPEC a especicao a conjuno de todas as declaraes SPEC. Entretanto, cada uma das frmulas SPEC avaliada e os resultados so relatados separadamente, um por um, na ordem das declaraes SPEC no texto do programa. 104

8.3.5 DECLARAO DEFINE A m de fazer descries mais concisas, um smbolo pode ser associado uma expresso geralmente usada. A sintaxe para esta declarao : dec1 :: "DEFINE" atom1 atom2 ... atomn ":=" expr3 ";" ":=" expr1 ":=" expr2 ";" ";"

Quando o identicador que refere-se ao smbolo no lado esquerdo ocorre em uma expresso, est substitudo pela expresso no lado direito. A expresso no lado direito avaliada sempre em seu contexto original. As referncias prvias para smbolos denidos so permitidas, mas denies circulares no so, e o resultado um erro. 8.3.6 MDULOS Um mdulo uma coleo encapsulada de declaraes. Uma vez denido, um mdulo pode ser utilizado tantas vezes quanto necessrio. Os mdulos podem tambm ser parametrizados, de modo que cada instncia de mdulo possa referenciar a diferentes valores dados. Um mdulo pode conter instncias de outros mdulos permitindo que uma hierarquia estrutural seja construda. A sintaxe de um mdulo a seguinte: module :: "MODULE" atom [ "(" atom1 "," atom "," ... atom ")" ] decl1 decl2 ... decl3 O tomo imediatamente seguido da palavra-chave MODULE o nome associado ao mdulo. Os nomes de mdulo so extrados de um espao de nomes distintos dos outros nomes do programa, e da podem haver um conitos entre os nomes das variveis e das denies. A lista opcional dos tomos nos parnteses so os parmetros formais do mdulo. Sempre que estes parmetros ocorrem nas expresses dentro do mdulo, so substitudos pelos parmetros reais que so fornecidos quando o mdulo instanciado. 105

Uma instncia de mdulo criada usando a declarao VAR. Esta declarao fornece um nome para a instncia, e tambm uma lista de parmetros reais, que so atribudos aos parmetros formais na denio do mdulo. Um parmetro real pode ser qualquer expresso legal. um erro ser o nmero de parmetros reais estiver diferente do nmero de parmetros formais. Por exemplo, na seguinte parte do programa: ... VAR a : boolean; b : foo(a) ... MODULE foo(x) ASSIGN x := 1; varivel b atribuda o valor 1. Isto distinge o mecanismo de chamada por referncia de um esquema de chamada por valor. Considere agora o seguinte programa: ... DEFINE a := 0; VAR b : bar(a); ... MODULE bar(x) DEFINE a := 1; y := x; No programa acima, o valor de y 0. Por outro lado, usando um mecanismo de chamada por nome (call-by-name ), o valor de y seria 1, desde que a fosse substitudo por uma expresso para x. Referncias prvias para os nomes dos mdulos so permitidos, mas as referncias circulares no o so, e o resultado um erro.

106

8.3.7 IDENTIFICADORES Um id, ou identicador, uma expresso que referencia a um objeto. Os objetos so instncias dos mdulos, variveis, e smbolos denidos. A sintaxe de um identicador a seguinte: id :: atom | id "." atom | id "[" expr "]" Um tomo identica o objeto com esse nome como denido em uma declarao VAR ou DEFINE. Se a identicar uma instncia de um mdulo, ento a expresso a.b identica o objeto componente nomeado b da instncia a. Isto precisamente anlogo a acessar um componente de um tipo estruturado dado. Note que um parmetro real da instncia de mdulo a pode identicar uma outra instncia de mdulo b, permitindo que a acesse aos componentes de b, como no exemplo seguinte: ... VAR a: foo(b); b : bar(a); ... MODULE DEFINE c := x.p | x.q; MODULE bar(x) VAR p : boolean; q : boolean; Aqui, o valor de c o ou lgico de p e q. Se a identica um vetor, a expresso a[b] identica o elemento b do vetor a. um erro para a expresso b avaliar um nmero fora dos limites subscritos do vetor a, ou um valor simblico. 107 foo(x)

8.3.8 MDULO MAIN A sintaxe de um programa de SMV program :: module1 module2 ... modulen Deve sempre haver um mdulo com nome main com nenhum parmetro formal. O mdulo main o ponto de partida para avaliao por parte do interpretador.

108