VERIFICAÇÃO DE MODELOS APLICADA AO PROJETO DE SISTEMAS INDUSTRIAIS AUTOMATIZADOS POR CONTROLADORES LÓGICOS PROGRAMÁVEIS

Transcrição

1 INSTITUTO MILITAR DE ENGENHARIA CARLOS HENRIQUE DA COSTA OLIVEIRA VERIFICAÇÃO DE MODELOS APLICADA AO PROJETO DE SISTEMAS INDUSTRIAIS AUTOMATIZADOS POR CONTROLADORES LÓGICOS PROGRAMÁVEIS Dissertação de Mestrado apresentada ao Curso de Mestrado em Engenharia Elétrica do Instituto Militar de Engenharia, como requisito parcial para obtenção do título de Mestre em Ciências em Engenharia Elétrica. Orientador: Antonio Eduardo Carrilho da Cunha - Dr. Eng. Co-orientador: Mario Cesar Mello Massa de Campos - Dr. ECP Rio de Janeiro 2006

2 c2006 INSTITUTO MILITAR DE ENGENHARIA Praça General Tibúrcio, 80-Praia Vermelha Rio de Janeiro-RJ CEP Este exemplar é de propriedade do Instituto Militar de Engenharia, que poderá incluí-lo em base de dados, armazenar em computador, microfilmar ou adotar qualquer forma de arquivamento. É permitida a menção, reprodução parcial ou integral e a transmissão entre bibliotecas deste trabalho, sem modificação de seu texto, em qualquer meio que esteja ou venha a ser fixado, para pesquisa acadêmica, comentários e citações, desde que sem finalidade comercial e que seja feita a referência bibliográfica completa. Os conceitos expressos neste trabalho são de responsabilidade do(s) autor(es) e do(s) orientador(es). L48 Oliveira, Carlos Henrique da C. Verificação de Modelos Aplicada ao Projeto de Sistemas Industriais Automatizados por Controladores Lógicos Programáveis / Carlos Henrique da Costa Oliveira. - Rio de Janeiro : Instituto Militar de Engenharia, p.: il, graf., tab. Dissertação (mestrado) - Instituto Militar de Engenharia- Rio de Janeiro, Controladores Lógicos Programáveis - CLP. 2. Sistemas Industriais Automatizados. 3. Verificção de Modelos. 4. Automação. 5. Confiabilidade. 6. Diagrama de Blocos Funcionais - DBF. I. Título. II. Instituto Militar de Engenharia. CDD

3 INSTITUTO MILITAR DE ENGENHARIA CARLOS HENRIQUE DA COSTA OLIVEIRA VERIFICAÇÃO DE MODELOS APLICADA AO PROJETO DE SISTEMAS INDUSTRIAIS AUTOMATIZADOS POR CONTROLADORES LÓGICOS PROGRAMÁVEIS Dissertação de Mestrado apresentada ao Curso de Mestrado em Engenharia Elétrica do Instituto Militar de Engenharia, como requisito parcial para obtenção do título de Mestre em Ciências em Engenharia Elétrica. 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 João Carlos dos Santos Basilio - Ph.D. da UFRJ Paulo César Pellanda - Dr. ENSAE do IME Rio de Janeiro

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

5 AGRADECIMENTOS A Deus. Ao Instituto Militar de Engenharia, especialmente ao Departamentos de Engenharia Elétrica, pela oportunidade de realizar este curso. Aos meus pais José Carlos e Adélia, e irmãos Adriana, Claudio e Carlos Adriano, aos meus cunhados Amauri e Esmeri e sobrinhas Lorraine, Catarine, Victoria e Lucas que sempre me deram incentivo e motivação ao longo de toda a minha vida e em mais esta etapa de minha formação. 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 paciência, dedicação, incentivo e cumplicidade como orientador, sem os quais este trabalho não 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 profissionalismo prestados no decorrer do curso. Aos meus amigos Leonardo Araújo, Diogo, Arthur, Michele, Alessandra, Rogério 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, Hélio Paiva pelas cartas de recomendação para o meu início no curso de mestrado. Aos meus amigos Monique e Roberto pela força. A todos que não foram citados mas contribuíram de alguma forma para o trabalho. A Coordenação de Aperfeiçoamento de Pessoal de Nível Superior - CAPES pelo apoio financeiro. 5

6 SUMÁRIO LISTA DE ILUSTRAÇÕES LISTA DE TABELAS LISTA DE SÍMBOLOS E ABREVIATURAS INTRODUÇÃO Motivação e Justificativa Objetivos Metodologia Organização do Trabalho VERIFICAÇÃO DE MODELOS Visão Geral da Verificação de Modelos A Necessidade de Métodos Formais Verificação de Hardware e Software O Processo de Verificação de Modelos Lógica Temporal e Verificação de Modelos Algoritmos Simbólicos Lógicas Temporais A Lógica da Árvore da Computação CTL CTL e LTL Exemplo - Exclusão Mútua O Verificador de Modelos SMV Resumo do Capítulo VERIFICAÇÃO DE MODELOS APLICADA À PROGRAMAÇÃO DE CLP S Controladores Lógicos Programáveis (CLP s ) Visão Geral da Verificação de Modelos Aplicada à Programação de CLP s Um Modelo para os Diagramas de Contatos Exemplos de Aplicação Sistema de Alarme Sistema de Manufatura

7 3.5 Resumo do Capítulo CONTRIBUIÇÕES À APLICAÇÃO DA VERIFICAÇÃO DE MO- DELOS AO PROJETO DE SISTEMAS AUTOMATIZADOS Projeto de Sistemas Automatizados Exemplo de um Projeto de Sistema Automatizado Descrição Literal das Especificações Matriz de Causa e Efeito Fluxograma de Funcionamento e Programa de Aplicação Programa em DBF Proposta de Verificação de Modelos Escrita da Especificação Escrita de Especificações a partir da Matriz de Causa e Efeito Escrita das Especificações a partir do Conhecimento do Sistema A Tradução da linguagem DBF em código SMV Elementos de Lógica Booleana Elementos de Memória Blocos Temporizadores Construção Modular do Código Verificação Reprojeto Resumo do Capítulo APLICAÇÃO NA AUTOMAÇÃO DE UM AQUECEDOR A CHAMA Automação do Processo de Purga Seqüência de Purga Lista de Entradas e Saídas Matriz de Causa e Efeito Projeto do Programa em DBF Modelagem das Especificações Modelagem do Programa Verificação Resumo do Capítulo

8 6 CONCLUSÃO Contribuições à verificação de modelos Limitações da Abordagem Perspectivas REFERÊNCIAS BIBLIOGRÁFICAS APÊNDICE Manual do Verificador de Modelos Simbólicos (Symbolic Model Checking - SMV) versão Linguagem de Entrada Sintaxe e Semântica Convenções Léxicas Expressões Declaração da ASSIGN Declaração SPEC Declaração DEFINE Módulos Identificadores Módulo main

9 LISTA DE ILUSTRAÇÕES FIG.2.1 (a) Estrutura Kripke. (b) Árvore correspondente para estado inicial S FIG.2.2 Operadores básicos de CTL FIG.2.3 Gráfico de transição de estados global para o problema de exclusão mútua de um processo FIG.3.1 Fluxo de dados entre o CLP e um sistema a controlar FIG.3.2 Ciclo de varredura do CLP FIG.3.3 Diagrama de Fluxo de Dados FIG.3.4 LD e descrição do modelo equivalente FIG.3.5 Sistema de alarme FIG.3.6 Programa de Controle para o Sistema de Alarme FIG.3.7 Representação do programa de controle do alarme em linguagem de verificação de modelos FIG.3.8 Verificação de Modelos para o programa de controle do alarme (contra-exemplo) FIG.3.9 Contra-exemplo da especificação da linha 4 na Figura FIG.3.10 Analise gráfica do contra-exemplo da especificação da linha 4 na Figura FIG.3.11 Contra-exemplo da especificação da linha 7 na Figura FIG.3.12 Analise gráfica do contra-exemplo da especificação da linha 7 na Figura FIG.3.13 Reprojeto FIG.3.14 Planta FIG.3.15 Programa de Controle para o Sistema de Manufatura FIG.3.16 Representação do programa de controle da manufatura em linguagem de verificação de modelos FIG.3.17 Verificação de Modelos para o programa de controle da manufatura (contra-exemplo) FIG.3.18 Analise gráfica do contra-exemplo da especificação na linha 7 da Figura FIG.3.19 Projeto com base na análise do contra-exemplo FIG.3.20 Resposta da Verificação após correção do programa

10 FIG.4.1 Método de projeto adotado por Empresas de Automação FIG.4.2 Sistema estrela-triângulo FIG.4.3 Matriz de Causa e Efeito do sistema Y FIG.4.4 Fluxograma para o sistema estrela-triângulo FIG.4.5 Programa em Diagramas de Blocos Funcionais FIG.4.6 Procedimento atual e proposta de modificação FIG.4.7 Escrita de especificações CTL FIG.4.8 Blocos lógicos AND, OR e NOT FIG.4.9 Blocos SET/RESET FIG.4.10 Códigos SET/RESET FIG.4.11 Blocos dos temporizadores DI, DT, PO FIG.4.12 Máquinas de estado correspondente ao código do temporizador DI FIG.4.13 Máquinas de estado correspondente ao código do temporizador DT FIG.4.14 Máquinas de estado correspondente ao código do temporizador PO FIG.4.15 Códigos dos temporizadores FIG.4.16 Programa em Diagramas de Blocos Funcionais com as variáveis auxiliares FIG.4.17 Tradução do DBF em código SMV FIG.4.18 Resposta da verificação FIG.4.19 Contra-exemplo da especificação na linha 7 da Figura FIG.4.20 Contra-exemplo da especificação na linha 10 da Figura FIG.4.21 Contra-exemplo da especificação na linha 13 da Figura FIG.4.22 Reprojeto com base no contra-exemplo FIG.4.23 Reprojeto na linguagem SMV FIG.5.1 Matriz de Causa e Efeito do sistema Purga FIG.5.2 Projeto do sistema Purga FIG.5.3 Tipos de sinal, segundo a norma ISA 5.2 (ISA, 1992) FIG.5.4 Projeto do sistema Purga com inserção de variáveis auxiliares FIG.5.5 Modelo do Programa no SMV FIG.5.6 Resposta da verificação do sistema Purga FIG.8.1 Listagem de short.smv FIG.8.2 Expressão FIG.8.3 Programa e expressões reusáveis FIG.8.4 Atribuição

11 LISTA DE TABELAS TAB.3.1 Simbologia e descrição dos diagramas de contato TAB.3.2 Bobinas do sistema TAB.4.1 Entradas e saídas do sistema TAB.4.2 Condições para representação das Saídas TAB.5.1 Variáveis de entrada do sistema TAB.5.2 Variáveis de saída do sistema

12 LISTA DE SÍMBOLOS E ABREVIATURAS ABREVIATURAS CLP - Controlador Lógico Programável IME - Instituto Militar de Engenharia LD - Diagrama de Contatos SMV - Verificador de Modelo Simbólico CTL - Lógica da Árvore da Computação LTL - Lógica Temporal Linear SIPN - Rede de Petri Interpretada a Sinais SFC - Diagrama de Função Sequencial PN - Rede de Petri SED - Sistema a Eventos Discretos TCS - Teoria de Controle Supervisório DBF - Diagrama de Blocos de Funções BF - Blocos de Funções IL - Lista de Instruções ST - Texto Estruturado SIS - Sistema Instrumentado de Segurança MCE - Matriz de Causa e Efeito P&I - Diagrama de Processo e Instrumentação MIE - Memória Intermediária de Entrada MIS - Memória Intermediária de Saída OBDD - Diagrama de Decisão Binária Ordenado DCS - Sistemas de Controle Distribuído SÍMBOLOS : - tal que - existe - para todo 12

13 - se, então - se, somente se - operador OU - operador E - operador NÃO a A - a pertence ao conjunto A a / A - a não pertence ao conjunto A - equivalente s = f - f é válido no estado s s f - f não é válido no estado s A B - A está contido em B A B - B está contido em A A B - A maior ou igual a B A B - A menor ou igual a B A < B - A menor que B A > B - A maior que B SIMBOLOGIA PARA ALGORITMOS! - operador NÃO - operador OU & - operador E := - atribuição init(x) - operador de inicialização da variável x next(x) - operador de próximo estado da variável x > - operador implica == - operador igual! = - operador diferente < - operador menor que <= - operador menor ou igual que > - operador maior que >= - operador maior ou igual que 13

14 RESUMO A confiabilidade é um fator fundamental para os Sistemas Industriais Automatizados. Assim, é importante que o programa de aplicação do Controlador Lógico Programável (CLP), responsável pelo processo, atenda às corretas especificações para o funcionamento. A não conformidade com as especificações, seja por implementação errônea de uma lógica ou pela não observação de aspectos da interação do CLP com os equipamentos externos, pode levar a prejuízos materiais, pessoais e ambientais. O objetivo deste trabalho é aplicar as técnicas de verificação de modelos (model checking) ao projeto de Sistemas Industriais Automatizados baseados em CLPs programados por Diagramas de Blocos Funcionais (DBFs). As contribuições deste trabalho são: Criação de um procedimento de tradução de programas escritos em DBF para a linguagem reconhecida pela ferramenta de verificação SMV usando carimbos, descrever um padrão para escrever especificações na linguagem da Lógica da Árvore da Computação CTL e propõe uma etapa de reprojeto, com base no contra exemplo. 14

15 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 specifications. The nonconformity with the specifications, 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 verification 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 verification procedures. 15

16 1 INTRODUÇÃO Este capítulo apresenta uma visão geral do trabalho, incluindo uma introdução ao problema tratado, os objetivos traçados, a metodologia adotada e um guia de leitura desta dissertação. 1.1 MOTIVAÇÃO E JUSTIFICATIVA A confiabilidade é um fator fundamental para os Sistemas Industriais Automatizados. Assim, é importante que o programa de aplicação no Controlador Lógico Programável (CLP) responsável pelo processo industrial atenda às corretas especificações para o seu funcionamento. Uma implementação que fuja do comportamento esperado pode permitir que ocorram falhas, possibilitando a ocorrência de acidentes e prejuízos de ordem material, pessoal e ambiental. Veja-se, por exemplo, o problema na planta química 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 métodos formais em sistemas onde falhas são inaceitáveis. A verificação de modelos surgiu na ciência da computação na década de 60 em torno da crise crônica do software (GIBBS, 1994). Começou a ser empregada na Engenharia de Automação mais recentemente com a crescente complexidade dos sistemas automatizados. O processo de verificação de modelos consiste basicamente em modelagem, especificação e verificação. A Verificação de Modelos permite fazer a comparação entre as especificações do Sistema Industrial Automatizado e o programa a ser implementado no CLP. No caso de não conformidade do projeto com as especificações, a verificação fornece um contraexemplo que ilustra a divergência. 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 não tratam da sistematização do uso da verificação num procedimento de projeto de um Sistema Industrial Automatizado. 16

17 1.2 OBJETIVOS O objetivo do presente trabalho é aplicar a Verificação de Modelos como técnica auxiliar para o projeto de Sistemas Industriais Automatizados por CLP. Deseja-se garantir principalmente a confiabilidade do sistema implementado. Particularmente, neste trabalho, trata-se da programação de CLPs por Diagramas de Blocos Funcionais (DBFs). Este trabalho visa criar um procedimento de tradução do programa de aplicação em DBF para um código aceito pela ferramenta de verificação. Objetiva-se tornar o programa modular, no qual é possível inserir modelos dos equipamentos externos, dos blocos temporizadores e dos blocos de memórias sob a forma de carimbos. Também tem como objetivo sistematizar o procedimento de tradução de especificações em propriedades formais a serem verificadas. 1.3 METODOLOGIA Primeiramente foi feito um estudo dos principais métodos de validação para sistemas complexos, como: simulação, teste, verificação dedutiva e verificação de modelos, que é a adotada no trabalho. Em seguida é feito um estudo de Controladores Lógicos Programáveis (CLPs) e suas principais linguagens de programação dando uma visão geral do processo de verificação de modelos com exemplos de MOON (1994) e RAUSCH & KROGH (1998). Com base numa generalização das etapas do projeto de um Sistema Industrial Automatizado por CLPs, propõem-se etapas adicionais onde se aplica a verificação de modelos para validar o projeto. Para a execução da Verificação é utilizada a ferramenta SMV (Symbolic Model Verifier), que é uma ferramenta acadêmica que representa o estadoda-arte em verificação de modelos (CMU, 2000). Com base no contra exemplo, este trabalho propõe uma etapa de reprojeto do programa de aplicação. Tais procedimentos são descritos na Seção 4.3. Conseqüentemente, o trabalho descreve uma metodologia sistematizada para a verificação de modelos em projetos de sistemas automatizados, criando um procedimento de tradução de programas escritos em Diagramas de Blocos Funcionais (DBF) para a linguagem reconhecida pela ferramenta de verificação SMV. Descreve também um padrão para escrever especificações baseadas no conhecimento do sistema e na matriz de causa e efeito na linguagem da Lógica da Árvore da Computação CTL. Após desenvolvida a metodologia, aplica-se a um exemplo real de parte de um Aquecedor a Chama no Capítulo 17

18 ORGANIZAÇÃO DO TRABALHO O Capítulo 2 dá uma visão geral da verificação de modelos, descrevendo o seu processo. Mostra o sistema de verificação de modelos que MCMILLAN (1993) desenvolveu como parte de sua tese de doutorado, que é utilizado neste trabalho. Também apresenta o que é a lógica da árvore de computação (CTL). O Capítulo 3 tem por principal objetivo mostrar como funciona a verificação de programas de CLP usando a verificação de modelos. São utilizados exemplos acadêmicos de sistemas de pequeno porte (RAUSCH & KROGH, 1998) e (MOON, 1994) para facilitar o entendimento do processo de verificação. O Capítulo 4 tem por objetivo aplicar as técnicas de verificação de modelos ao projeto de Sistemas Automatizados baseados em CLPs programados por DBF. Foram desenvolvidos padrões para a verificação, com base em estruturas lógicas típicas, como carimbos de blocos de memória e temporizadores. Também foram desenvolvidos padrões de especificações para sistemas automatizados, visando a uma futura automatização do processo de verificação. O Capítulo 5 tem por objetivo aplicar as técnicas de verificação de modelos desenvolvidas a uma parte de um projeto de automação de um Aquecedor a Chama Industrial. O Capítulo 6 conclui o trabalho, analisando seu conteúdo em termos dos objetivos propostos. Também neste capítulo são resumidas as contribuições teóricas realizadas e apresentam-se ainda sugestões para futuros trabalhos. 18

19 2 VERIFICAÇÃO DE MODELOS Este capítulo apresenta o método de verificação de modelos desenvolvido por Clarke e Emerson (CLARKE et al., 1999), que é utilizado neste trabalho. 2.1 VISÃO GERAL DA VERIFICAÇÃO DE MODELOS A Verificação de Modelos é uma técnica automática para validação do projeto de sistemas concorrentes de estados finitos. Foi usada com sucesso na prática para validar projetos de complexos circuitos seqüenciais e protocolos de comunicação (CLARKE et al., 1999). O principal desafio da verificação de modelos é o tratamento do problema de explosão de espaço 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 seção, compara-se a verificação de modelos a outros métodos formais para validação de projetos de software e hardware. Além disso, descreve-se como a verificação de modelos é usada para validar projetos de sistemas complexos A NECESSIDADE DE MÉTODOS FORMAIS Hoje, sistemas de hardware e software são usados amplamente em aplicações onde falhas são inaceitáveis: comércio eletrônico, redes de comunicações telefônicas, estradas de rodagem, sistemas de controle de tráfego aéreo, instrumentos médicos, entre outras. Freqüentemente, escutam-se notícias 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 lançado (SPARACO, 1996). O comitê que investigou o acidente mostrou que este foi causado por um erro no software de um computador que era responsável por calcular o movimento do foguete. Durante o lançamento, uma exceção ocorreu quando um número de ponto flutuante de 64-bits foi convertido num inteiro de 16-bits com sinal. Tal conversão não era protegida pelo código para manipular exceções e fez com que o computador falhasse. O mesmo erro também fez com que o computador de backup falhasse. Em conseqüência, dados incorretos da atitude foram transmitidos ao computador de bordo, que causou a destruição do foguete. A equipe que investigou a falha sugeriu que 19

20 diversas medidas fossem tomadas a fim impedir incidentes similares no futuro, incluindo a verificação do software do Ariane 5 (SPARACO, 1996). Por causa do sucesso da Internet e dos sistemas embarcados nos automóveis, aeroplanos, e outros sistemas criticamente seguros, a dependência do correto funcionamento de dispositivos computacionais se torna cada vez maior. De fato, o ritmo da mudança se torna mais acelerado a cada ano. Por causa deste rápido crescimento na tecnologia, é importante desenvolver métodos que aumentem a confiança na correção de tais sistemas VERIFICAÇÃO DE HARDWARE E SOFTWARE Os principais métodos de validação para sistemas complexos são simulação, teste, verificação dedutiva, e verificação de modelos (CLARKE et al., 1999). Ambos, simulação e teste, envolvem a execução de experimentos antes de se empregar o sistema. Enquanto se executa a simulação sobre uma abstração ou modelo do sistema, o teste é executado no produto real. No caso de circuitos, a simulação é executada no projeto do circuito, enquanto o teste é executado no próprio circuito. Em ambos os casos, estes métodos injetam sinais em determinados pontos no sistema e observam os sinais resultantes em outros pontos. Para o software, a simulação e os testes geralmente envolvem a geração de determinadas entradas e observação das saídas correspondentes. Estes métodos podem ser uma maneira econômica para encontrar diversos erros. Entretanto, verificar todas as interações possíveis e falhas potenciais usando simplesmente as técnicas de simulação e teste é raramente possível. O termo verificação dedutiva se refere normalmente ao uso de axiomas e regras de prova para demonstrar a corretude dos sistemas (CLARKE et al., 1999). No início da pesquisa envolvendo verificação dedutiva, o foco principal estava em garantir a correção de sistemas críticos. Supunha-se que a importância do comportamento correto era tão grande que o projetista ou perito em verificação (geralmente um matemático ou um logicista) deveria gastar o tempo que fosse necessário para verificar o sistema. Inicialmente, tais provas eram construídas inteiramente à mão. Com o tempo, os pesquisadores descobriram que ferramentas de software poderiam ser desenvolvidas para forçar o uso correto de axiomas e regras de prova. Tais ferramentas poderiam também aplicar uma busca sistemática para sugerir várias maneiras de se progredir no estágio corrente da prova. A importância da verificação dedutiva é amplamente reconhecida pelos cientistas da computação. A técnica influenciou significativamente a área de desenvolvimento de 20

21 softwares (por exemplo, a noção de um invariante). Entretanto, a verificação dedutiva é um processo demorado que pode ser efetuado somente por peritos treinados no raciocínio lógico e que tenham considerável experiência. A prova de um simples protocolo ou circuito pode durar dias ou meses (CLARKE et al., 1999). Conseqüentemente, o uso da verificação dedutiva é raro. É aplicado primordialmente aos sistemas altamente sensíveis, tais como protocolos de segurança, onde o investimento de recursos necessários para garantir a segurança do seu uso são justificáveis. É importante estar ciente de que algumas tarefas matemáticas não podem ser executadas por algoritmos. A teoria da computabilidade (CLARKE et al., 1999) fornece limitações do que pode ser decidido por um algoritmo. Em particular, mostra-se que não existe um algoritmo que decida se um programa de computador arbitrário (escrito em alguma linguagem de programação como C ou Pascal) termina. Isto limita imediatamente o que pode ser verificado automaticamente. Mais ainda, a terminação correta de um programa genérico não pode ser verificada automaticamente (CLARKE et al., 1999). Dessa forma, uma grande parte dos sistemas de prova não podem ser completamente automatizados. Uma vantagem da verificação dedutiva é que esta pode ser usada para especular sobre sistemas de estados infinitos (CLARKE et al., 1999). E esta tarefa pode ser automatizada dentro de certos limites. E ainda, mesmo que a propriedade a ser verificada seja verdadeira, nenhum limite pode ser colocado na quantidade de tempo ou de memória necessária a se encontrar uma solução. A verificação de modelos (model checking) é uma técnica para verificar sistemas concorrentes de estados finitos (CLARKE et al., 1999). Um benefício desta restrição é que a verificação pode ser executada automaticamente. O procedimento utiliza normalmente uma busca exaustiva do espaço de estados do sistema para determinar se alguma especificação é verdadeira ou não. Dados os recursos suficientes, os procedimentos terminarão sempre com uma resposta do tipo sim ou não. Além disso, pode ser implementada por algoritmos com eficiência considerável, que podem rodar em máquinas potentes (geralmente não em um computador desktop típico). Embora a restrição aos sistemas de estados finitos possa parecer uma principal desvantagem, a verificação de modelos é aplicável a diversas classes importantes de sistemas. Os controladores de hardware são sistemas de estados finitos, e os mesmos são muitos protocolos de comunicação. Em alguns casos, os sistemas que não são de estados finitos podem ser verificados pelo uso da verificação de modelos em combinação com 21

22 vários princípios de abstração e indução. Em muitos casos, erros podem ser encontrados restringindo as estruturas de dados ilimitadas a instâncias específicas que sejam de estados finitos. Por exemplo, programas com filas de mensagens ilimitados podem ser tratados por restrição do tamanho das filas a um número pequeno como dois ou três. Em virtude da verificação de modelos poder ser feita automaticamente, esta é preferível à verificação dedutiva sempre que puder ser aplicada. Entretanto, sempre haverá algumas aplicações críticas em que a prova de teoremas é necessária para a verificação completa. Um novo sentido da pesquisa tenta integrar a verificação dedutiva com a verificação de modelos, de modo que porções de estados finitos de sistemas complexos possam ser verificadas automaticamente. (CLARKE et al., 1999) O PROCESSO DE VERIFICAÇÃO DE MODELOS Aplicar a verificação de modelos a um projeto consiste de basicamente três tarefas (CLARKE et al., 1999): Modelagem: A primeira tarefa é converter um projeto em um formalismo aceito por uma ferramenta de verificação de modelos. Em muitos casos, esta é simplesmente uma tarefa de compilação. Em outros casos, devido a limitações em tempo e memória, modelar um projeto requer o uso de abstração para eliminar detalhes irrelevantes ou sem importância. Especificação: Antes da verificação, é necessário indicar as propriedades a que o projeto deve satisfazer. A especificação é dada geralmente em algum formalismo lógico. Para sistemas de hardware e de software, é comum usar a lógica temporal, que pode afirmar como o comportamento do sistema evolui com o tempo. Um ponto importante na especificação é a abrangência (completeness). Embora a verificação de modelos forneça subsídios para se certificar de que um modelo satisfaz a uma dada especificação, é impossível determinar se a especificação dada cobre todas as propriedades a que o sistema deve satisfazer. Verificação: A verificação é completamente automática. Entretanto, na prática, envolve, freqüentemente, o auxílio humano. Uma atividade manual é a análise dos resultados da verificação. Caso dê um resultado negativo, é fornecido ao usuário um traço de erro. O traço de erro trata de um contra-exemplo para a propriedade verificada e se destina a auxiliar o projetista a detectar onde o erro ocorreu. Neste 22

23 caso, a análise do traço de erro pode requerer uma modificação no sistema e uma nova aplicação do algoritmo de verificação. Um traço de erro pode também resultar de uma modelagem incorreta do sistema ou de uma especificação incorreta, chamada freqüentemente de negativo falso (CLARKE et al., 1999). O traço de erro pode também ser útil para identificar e reparar estes dois problemas. Uma outra possibilidade é que a tarefa da verificação não termine normalmente, devido ao tamanho do modelo, nos casos em que este seja demasiadamente grande para a memória do computador. Neste caso, pode ser necessário refazer a verificação após modificar alguns dos parâmetros do verificador de modelos ou ter-se ajustado o modelo (por exemplo, pelo uso de abstrações adicionais) LÓGICA TEMPORAL E VERIFICAÇÃO DE MODELOS As lógicas temporais são úteis para especificar os sistemas concorrentes, porque descrevem a ordenação temporal dos eventos sem introduzir explicitamente o tempo. Foram desenvolvidas originalmente por filósofos para investigar a maneira como o tempo é usado nos argumentos da linguagem natural (HUGUES & CRESWELL, 1977). Embora uma quantidade de lógicas 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 afirmar que dois eventos e 1 e e 2 nunca ocorrem ao mesmo tempo, escreve-se G( e 1 e 2 ). As lógicas temporais são classificadas freqüentemente conforme o tempo, sendo suposto ter em uma estrutura linear ou ramificada. Neste trabalho, o sentido de uma fórmula em lógica temporal é determinado sempre com respeito a um tipo de grafo de transição de estados, chamado, por razões históricas, de estrutura Kripke (HUGUES & CRESWELL, 1977), conforme mostra a Seção A introdução de algoritmos de verificação de modelos usando lógica temporal por Clarke e Emerson (CLARKE & EMERSON, 1981) no início dos anos 80 permitiu a automação do raciocínio em lógica temporal para validação de programas. O algoritmo desenvolvido por Clarke e Emerson para a lógica de tempo ramificado CTL é polinomial no tamanho do modelo determinado pelo programa sob consideração e no comprimento de sua especificação em lógica temporal. Mostraram também 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 verificação de modelos para um subconjunto da CTL, mas 23

24 a complexidade não foi analisada. Mais tarde Clarke, Emerson e Sistla (CLARKE et al., 1986) planejaram um algoritmo melhorado linear no produto do comprimento da fórmula e do tamanho do grafo de transição de estados. O algoritmo foi implementado no verificador de modelos denominado EMC, que foi distribuído e usado amplamente para verificar diversos sistemas de protocolos de rede e circuitos seqüenciais (CLARKE et al., 1999) ALGORITMOS SIMBÓLICOS Na implementação original do algoritmo de verificação de modelos de Clarke e Emerson (CLARKE & EMERSON, 1981), as relações de transição são representadas explicitamente por listas de adjacência. Para sistemas concorrentes com um pequeno número de processos, o número dos estados é geralmente pequeno, e a abordagem é, em geral viável. Nos sistemas com muitas partes concorrentes entretanto, o número de estados no grafo de transição de estados global é muito grande para lidar. Em 1987, Ken McMillan, então um estudante de pós-graduação na Universidade de Carnegie Mellon, descobriu que, usando uma representação simbólica para os grafos de transição de estados, sistemas com número de estados muito maior poderiam ser verificados (MCMILLAN, 1993). A nova representação simbólica foi baseada nos Diagramas de Decisão Binária Ordenados (Ordered Binary Decision Diagrams - OBDDs), (BRYANT & MUSGRAVE, 1998). Os OBDDs fornecem uma forma canônica que é freqüentemente mais compacta que a forma normal conjuntiva ou disjuntiva (CLARKE et al., 1999). Algoritmos eficientes foram desenvolvidos para manipular fórmulas booleanas escritas em OBDDs. Uma vez que a representação simbólica captura alguma regularidade no espaço de estados de determinados circuitos e protocolos, é possível verificar sistemas com um número extremamente grande de estados, muitas ordens maior do que poderia ser tratado pelos algoritmos que explicitam espaços de estados. Usando o algoritmo de verificação de modelos original de CTL de Clarke e Emerson com a nova representação para grafos de transição de estados, tornou-se possível verificar alguns exemplos com mais de estados (CLARKE et al., 1999). Desde então, os vários refinamentos das técnicas baseadas em OBDD por outros pesquisadores levaram à contagem de estados de até mais de (CLARKE et al., 1999). A representação implícita é completamente natural para modelar circuitos seqüenciais e protocolos. Cada estado é codificado por uma atribuição de valores booleanos ao conjunto de variáveis de estado associadas ao circuito ou protocolo. A relação de transição 24

25 pode conseqüentemente ser expressa como uma fórmula booleana nos termos de dois conjuntos de variáveis: um conjunto que codifica o estado de origem e o outro que codifica o de destino. Esta fórmula é, então, representada por um diagrama binário de decisão (CLARKE et al., 1999). O algoritmo de verificação de modelos se baseia no cálculo de pontos fixos dos transformadores de predicado que são obtidos da relação de transição (CLARKE et al., 1999). Os pontos fixos são conjuntos de estados que representam as várias propriedades temporais do sistema concorrente. Nas novas implementações, tanto os transformadores de predicado como os pontos fixos são representados por OBDDs. Assim, é possível evitar que se construa explicitamente o grafo de estados do sistema concorrente. O sistema de verificação de modelos que McMillan desenvolveu como parte de sua tese de doutorado é chamado Verificador de Modelos Simbólicos (Symbolic Model Verifier - SMV) (MCMILLAN, 1993). Baseia-se em uma linguagem para descrever sistemas concorrentes de estados finitos hierárquicos. Os programas na linguagem do SMV podem ser verificados por especificações expressas em lógica temporal. O verificador de modelos extrai um sistema de transição 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 à especificação. Se o sistema de transição não satisfaz a alguma especificação, o verificador produzirá um traço de execução que mostra porque a especificação é falsa. O sistema SMV é amplamente distribuído, e um grande número de exemplos tem sido verificados com o mesmo. Os exemplos tratados fornecem uma evidência convincente de que o SMV pode ser usado para eliminar erros em projetos industriais reais (CLARKE et al., 1999). Uma descrição completa da linguagem SMV é apresentada no Apêndice 8.1 deste trabalho. Um exemplo que ilustra o poder da verificação simbólica de modelos é a verificação do protocolo de coerência de cache descrito no padrão IEEE Futurebus+ (Padrão IEEE ) (CLARKE et al., 1999). O desenvolvimento do protocolo de coerência de cache Futurebus+ data de 1988, e todas as tentativas precedentes de validar o protocolo foram baseadas inteiramente em técnicas informais. No verão de 1992, pesquisadores da Universidade Carnegie Mellon construíram um modelo preciso do protocolo na linguagem SMV e, então, usaram o SMV para mostrar que o sistema de transição resultante satisfazia uma especificação formal da coerência cache (CLARKE et al., 1993) e (LONG, 1993). Foram capazes de encontrar uma certa quantidade de erros anteriormente não detectados, bem como erros potenciais no projeto do protocolo. Clarke, Grumberg e Peled referem- 25

26 se a esta como sendo a primeira vez que uma ferramenta automática de verificação é utilizada para encontrar erros num padrão IEEE (CLARKE et al., 1999). 2.2 LÓGICAS TEMPORAIS Nesta seção é descrita uma lógica para especificar propriedades temporais dos sistemas de transição de estados. A lógica utiliza proposições atômicas e conectivos booleanos tais como a conjunção, a disjunção, e a negação para construir elaboradas expressões que descrevem as propriedades dos estados do sistema. A lógica temporal é um formalismo para descrever seqüências de transições entre estados em um sistema reativo. Na lógica temporal considerada, o tempo não é mencionado explicitamente, pelo contrário, uma fórmula especifica se algum estado é eventualmente alcançado, ou que um estado de erro nunca é atingido. As propriedades como eventualmente ou nunca são especificadas usando-se operadores temporais (CLARKE et al., 1999) A LÓGICA DA ÁRVORE DA COMPUTAÇÃO CTL Conceitualmente, as fórmulas da lógica da árvore de computação (Computation Tree Logic - CTL ) descrevem propriedades de árvores da computação. Forma-se uma árvore de computação ao se designar um estado de uma estrutura de transição de estados como estado inicial e, então, desenrola-se a estrutura numa árvore infinita com o estado inicial na raiz. A semântica CTL é definida com respeito a uma estrutura Kripke (CLARKE et al., 1999). Sejam AP um conjunto de proposições atômicas, M é uma estrutura Kripke tripla (S, R, L), onde S é o conjunto de estados; R S S é a relação de transição, que deve ser total (isto é, para todos os estados s S existe um estado s S tal que (s, s ) R); e L : S 2 AP é uma função que etiqueta cada estado (s S) com um conjunto de proposições atômicas (L(s) AP) verdadeiras nesse estado. Um caminho em M é uma infinita seqüência de estados, π = s 0,s 1,... tais que, para cada i 0, (s i,s i+1 ) R. A Figura 2.1 (a) ilustra uma estrutura Kripke e a Figura 2.1 (b) mostra a sua correspondente árvore da computação, com estado inicial s 0 (CLARKE et al., 1986). Da Figura 2.1, o conjunto de estados é S = {s 0,s 1,s 2 }, a relação de transição é R = {(s 0,s 1 ), (s 1,s 0 ), (s 0,s 2 ), (s 2,s 1 )}, e os conjuntos de proposições atômicas são AP = {a,b,c}, o conjunto de proposições verdadeiras nos estados é P(s 0 ) = {a,b}, P(s 1 ) = {b,c} e P(s 2 ) = {a,c}. 26

27 S 0 D S 0 E D S 2 S 1 S 2 E F S 0 S 1 F S 1 (a) S 1 S 2.. (b) S 0. FIG. 2.1: (a) Estrutura Kripke. (b) Árvore correspondente para estado inicial S 0. Em CTL as fórmulas são compostas de quantificadores de caminho e operadores temporais. Os quantificadores de caminho são usados para descrever a estrutura de ramificação da árvore de computação. Há dois quantificadores de caminho: A (para todos os caminhos de computação - for all computation paths) e E (para algum caminho de computação - for some computation path). Estes quantificadores são usados em um estado particular para especificar que todos ou algum dos caminhos que começam neste estado possuem alguma propriedade. Os operadores temporais descrevem propriedades de um caminho ao longo da árvore. Há cinco operadores temporais básicos: X (próxima vez - next time) requer que uma propriedade seja válida no segundo estado do caminho. F (eventualmente ou no futuro - eventually or in the future) afirma que uma propriedade é válida em algum estado do caminho. G (sempre ou globalmente - always or globally) especifica que uma propriedade é válida para todo estado do caminho. U (até - until) é um operador que combina duas propriedades. Dadas as propriedades p 1 e p 2, p 1 U p 2 se houver um estado do caminho onde p 2 torna-se válida, e em cada estado precedente, p 1 sempre for válida. R (liberação - release) é dual ao operador U. Dadas as propriedades p 1 e p 2, p 1 R p 2, é válida quando p 2 é válido ao longo do caminho até e incluindo o primeiro 27

28 estado onde p 1 seja válido. Não se requer que p 1 torne-se válido no caminho. Há dois tipos de fórmulas em CTL : fórmulas de estado (que são verdadeiras em um estado específico) e fórmulas de caminho (que são verdadeiras ao longo de um caminho específico). Seja AP o conjunto de nomes de proposição atômicas. A sintaxe de fórmulas de estado é dada pelas seguintes regras: Se p AP, então p é uma fórmula de estado. Se f e g são fórmulas de estado, então f, f g e f g são fórmulas de estado. Se f é uma fórmula de caminho, então E f e A f são fórmulas de estado. Duas regras adicionais são necessárias para especificar a sintaxe de fórmulas do caminho: Se f é uma fórmula de estado, então f é também uma fórmula de caminho. Se f e g são fórmulas de caminho, então f, f g e f g, X f, F f, G f, f U g, e f R g são fórmulas de caminho. A CTL é o conjunto das fórmulas de estado geradas pelas regras acima. Utiliza-se π i para denotar o sufixo do caminho π que começa no estado s i. Se f denotar uma fórmula de estado, a notação M,s = f significa que f é válida no estado s da estrutura kripke M. Similarmente, se f for uma fórmula de caminho, M,π = f significa que f é válida ao longo do caminho π na estrutura kripke M. Quando a estrutura kripke M estiver subentendida no contexto, será usualmente omitida. A relação = é definida indutivamente como segue (supõe-se que f 1 e f 2 sejam as fórmulas de estado, g 1 e g 2 sejam fórmulas de caminho e que π denote um caminho na forma S 0 S 1 S 2...): a) M,s = f 1 f 1 L(s). b) M,s = f 1 M,s f 1. c) M,s = f 1 f 2 M,s = f 1 ou M,s = f 2. d) M,s = f 1 f 2 M,s = f 1 e M,s = f 2. e) M,s = Eg 1 há um caminho π a partir de s tal que M,π = g 1. f) M,s = Ag 1 para cada caminho π que parte de s, M,π = g 1. 28

29 g) M,π = f 1 s é o primeiro estado de π e M,s = f 1. h) M,π = g 1 M,π g 1. i) M,π = g 1 g 2 M,π = g 1 ou M,π = g 2. j) M,π = g 1 g 2 M,π = g 1 e M,π = g 2. k) M,π = Xg 1 M,π 1 = g 1. l) M,π = Fg 1 existe um k 0 tal que M,π k = g 1. m) M,π = Gg 1 para todo i 0,M,π i = g 1. n) M,π = g 1 Ug 2 existe um k 0, tal que M,π k = g 2 e para todo 0 j < k,m,π j = g 1. o) M,π = g 1 Rg 2 para todo j 0, se para cada i < j M,π i g 1 então M,π j = g 2. É fácil ver que os operadores,,x,u, e E são suficientes para expressar qualquer fórmula CTL CLARKE et al. (1999), pois é possível listar o seguinte: f g ( f g) frg ( fu g) Ff verdadeirouf Gf F f A(f) E( f) CTL E LTL Neta seção consideram-se duas sub-lógicas da CTL : uma é uma lógica de tempo ramificante e a outra é uma lógica de tempo linear. A distinção entre as duas está na forma como lidam com a ramificação na árvore de computação subjacente. Na lógica temporal de tempo ramificante, os operadores temporais quantificam sobre os caminhos que são possíveis a partir de um dado estado. Na lógica temporal de tempo linear, os operadores são fornecidos descrevendo eventos ao longo de um único trajeto de computação. A lógica da árvore da computação (CTL) é um subconjunto restrito da CTL onde cada um dos operadores temporais X, F, G, U e R deve ser imediatamente precedido 29

30 por um quantificador de caminho (CLARKE et al., 1999). Mais precisamente, a CTL é um subconjunto da CTL que é obtida ao se restringir a sintaxe de fórmulas de caminho pela seguinte regra: Se f e g forem fórmulas de estado, então X f, F f, G f, f U g, e f R g são fórmulas de caminho. A Lógica temporal linear (LTL), consiste das fórmulas que têm a forma A f, onde f é uma fórmula do caminho em que as únicas subfórmulas de estado permitidas são proposições atômicas (CLARKE et al., 1999). Mais precisamente, uma fórmula de caminho LTL é tal que: Se p AP, então p é uma fórmula de caminho. Se f e g são fórmulas de caminho, então f, f g, f g, X f, F f, G f, f U g, e f R g são fórmulas de caminho. Pode-se mostrar que as três lógicas discutidas neste trabalho possuem poderes de expressão diferentes (CLARKE et al., 1999). Por exemplo, não há nenhuma fórmula CTL que seja equivalente à fórmula LTL A(FGp). Esta fórmula expressa a propriedade de que, ao longo de todo caminho, há algum estado a partir do qual p será sempre válido. Do mesmo modo, não há nenhuma fórmula LTL que seja equivalente à uma fórmula CTL AG(EFp). A disjunção entre as duas fórmulas A(FGp) AG(EFp) é uma fórmula CTL e não é exprimível em fórmulas CTL ou LTL. Todas as especificações neste trabalho serão escritas na lógica CTL. Há dez operadores básicos 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 três operadores EX, EG e EU (CLARKE et al., 1999): 30