Verificação formal de sistemas instrumentados de segurança na indústria de petróleo e gás natural

AUTOMAC¸ ˜AO E SISTEMAS

Luiz Paulo Enadio dos Reis

VERIFICAC¸ ˜AO FORMAL DE SISTEMAS INSTRUMENTADOS DE SEGURANC¸ A NA IND ´USTRIA DE PETR ´OLEO E G ´AS NATURAL

Florian´opolis 2018

VERIFICAC¸ ˜AO FORMAL DE SISTEMAS INSTRUMENTADOS DE SEGURANC¸ A NA IND ´USTRIA DE PETR ´OLEO E G ´AS NATURAL

Dissertac¸˜ao submetida ao Programa de P´os-Graduac¸˜ao em Engenharia de Automac¸˜ao e Sistemas para a obtenc¸˜ao do Grau de Mestre em Engenharia de Automac¸˜ao e Sistemas.

Orientador: Prof. Dr. Max Hering de Quei-roz

Coorientador: Prof. Dr. Jean-Marie Fari-nes

Florian´opolis 2018

Ficha de identificação da obra elaborada pelo autor,

através do Programa de Geração Automática da Biblioteca Universitária da UFSC.

Reis, Luiz Paulo Enadio

Verificação formal de Sistemas Instrumentados de Segurança na indústria de petróleo e gás natural / Luiz Paulo Enadio Reis ; orientador, Max Hering de Queiroz, coorientador, Jean-Marie Farines, 2018. 140 p.

Dissertação (mestrado) - Universidade Federal de Santa Catarina, Centro Tecnológico, Programa de Pós Graduação em Engenharia de Automação e Sistemas, Florianópolis, 2018.

Inclui referências.

1. Engenharia de Automação e Sistemas. 2. Sistemas Instrumentados de Segurança. 3. verificação formal. 4. model checking. 5. Controlador Lógico Programável. I. Queiroz, Max Hering de. II. Farines, Jean-Marie. III. Universidade Federal de Santa Catarina. Programa de Pós-Graduação em Engenharia de Automação e Sistemas. IV. Título.

em outro plano olha por mim, aos meu amigos em especial ao Tiago e ao Fl´avio que foram minha fam´ılia em Florian´opolis. E dedico es-pecialmente a Ana Carolina.

Inicio meus agradecimentos por Deus, j´a que ele colocou pessoas t˜ao especiais a meu lado, sem as quais certamente n˜ao teria dado conta.

A minha m˜ae Ana Paula, que sempre acreditou em minha capacidade. Isso s´o me fortaleceu e me fez tentar fazer o melhor de mim. Obrigado pelo amor incondicional.

Ao meu pai Luiz Henrique, que mesmo n˜ao estando mais conosco sempre demonstrou um orgulho inexplic´avel por mim, sempre me incentivou a estudar e que hoje deve estar explodindo de alegria com mais esta conquista.

A minha querida noiva, Ana Carolina, por ser t˜ao importante na minha vida. Sempre a meu lado, me pondo para cima e me fazendo acreditar que posso mais que imagino. Devido a seu companheirismo, amizade, paciˆencia, compreens˜ao, apoio, alegria e amor, este trabalho pˆode ser concretizado. Obrigado por ter feito do meu sonho o nosso sonho.

Ao meu irm˜ao, Lucca, meu agradecimento especial, pois, a seu modo, sempre se orgulhou de mim e confiou em meu trabalho. Obrigado pela confianc¸a.

Aos meus av´os Ana Regina, Paulo Enadio , Maria Jos´e e Joaquim Ovi-deo que por toda minha vida sempre foram como verdadeiros pais para mim. Sempre estiveram ao me lado me amando e me apoiando incondicionalmente. Essa conquista tamb´em ´e de vocˆes.

A meus tios, tias, primos e primas, os quais amo gigantescamente e vibraram comigo desde a ingressei na escola at´e a conclus˜ao do mestrado. Vocˆes sempre fizeram “propaganda” positiva a meu respeito e foram a melhor fam´ılia que algu´em pode ter. Obrigado pela forc¸a.

Aos Professores Max e Jean-Marie, que acreditaram em meu poten-cial de uma forma a que eu espero ter sido capaz de corresponder. Sempre dispon´ıveis e dispostos a ajudar, querendo que eu aproveitasse cada segundo dentro do mestrado para absorver algum tipo de conhecimento. Fizeram-me enxergar que existe mais que pesquisadores e resultados por tr´as de uma dissertac¸˜ao. Vocˆes foram e s˜ao referˆencias profissionais e pessoais para meu crescimento. Obrigado por estarem a meu lado e acreditarem tanto em mim.

A meus amigos do mestrado, pelos momentos divididos juntos, espe-cialmente `a Tiago e Fl´avio, que se tornaram minha fam´ılia em Florian´opolis. Obrigado por dividir comigo as ang´ustias e alegrias e ouvirem minhas boba-gens. Foi bom poder contar com vocˆes.

Agradec¸o, tamb´em, `a CAPES e a PETROBRAS pelo apoio financeiro. A Universidade Federal de Santa Catarina e ao Departamento de Automac¸˜ao de Sistemas por abrirem as portas para que eu pudesse realizar este sonho que era a minha dissertac¸˜ao de mestrado. Proporcionaram-me mais que a busca

de conhecimento t´ecnico e cient´ıfico, mas uma lic¸˜ao de vida. Ningu´em vence sozinho. OBRIGADO A TODOS!

sobre aquilo que todo mundo vˆe.

Esta dissertac¸˜ao apresenta um m´etodo automatiz´avel para verificac¸˜ao formal de programas de CLP integrada `a metodologia de desenvolvimento de Siste-mas Instrumentados de Seguranc¸a (SIS) na ind´ustria de petr´oleo e g´as. As especificac¸˜oes de seguranc¸a relacionando os diversos sensores e atuadores de SIS s˜ao padronizadas em Matrizes de Causa e Efeito (MCE), que s˜ao sistematicamente traduzidas em f´ormulas LTL. S˜ao apresentadas regras para traduc¸˜ao do programa de CLP em diagrama Ladder para um modelo formal em linguagem intermedi´aria FIACRE que serve de entrada para realizac¸˜ao de model checkingatrav´es da cadeia de verificac¸˜ao TINA/SELT. A fim de lidar com a complexidade dos modelos formais para SIS reais, apresenta-se um m´etodo baseado em cone de influˆencia para decomposic¸˜ao do processo de model checkinge simplificac¸˜ao dos modelos em FIACRE. Os contraexemplos resultantes s˜ao convertidos em diagramas de sinal ou em comandos para o simulador do CLP, que facilitam a interpretac¸˜ao das falhas identificadas. O m´etodo foi aplicado para verificac¸˜ao de um caso ilustrativo e para partes do c´odigo do SIS de uma plataforma de petr´oleo offshore real. Os resultados mostram que o m´etodo ´e eficaz em detectar, quando existem, incongruˆencias entre as especificac¸˜oes de seguranc¸a e a programac¸˜ao do CLP. Por´em em sistemas com um n´umero elevado de entradas e sa´ıdas uma ´unica etapa de reduc¸˜ao n˜ao ´e suficiente para diminuir a complexidade do sistema, ao ponto do mesmo ser process´avel por computadores comuns. Nestes casos uma segunda etapa de reduc¸˜ao, baseada nas regras LTL, foi criada com intuito de verificar esses casos. Entretanto algumas propriedades n˜ao s˜ao poss´ıveis de serem reduzidas, sendo assim alguns casos a propriedade n˜ao pode ser verificada por este m´etodo.

Palavras-chave: Controlador L´ogico Program´avel; Sistemas Instrumentados de Seguranc¸a; model checking; verificac¸˜ao formal; Matriz de Causa e Efeito; diagrama Ladder.

This work presents an automated method of formal verification PLC programs integrated to Safety Instrumented Systems (SIS) development methodology applied to oil and gas industry. The safety specifications relating inputs and outputs are standardized by Cause and Effect Matrices (CEM), which are translated into LTL formulas. This work presents rules for translating PLC programs in Ladder diagrams to a formal model intermediate language called FIACRE that make the model checking through the TINA/SELT verification chain. To handle the complexity of real SIS formal models, it is presented a method based on cone of influence to breakdown the model checking process and simplify FIACRE models. The resulting counterexamples are converted in signal diagrams or in commands for the PLC simulator to make analysis easier. The method was applied to verify an illustrative PLC code of a real offshore oil platform. The results show that the method is effective in detecting incon-sistencies between the safety specifications and PLC programming. However in systems with a high number of inputs and outputs a single reduction step is not enough to reduce the complexity of the system. Therefore, a second reduction step, based on LTL rules, was created with the purpose of verifying these cases.

Keywords: Programmable logic controller; Safety Instrumented Systems; mo-del checking; formal verification; Cause and Effect Matrix; Ladder Diagram.

Figura 1 Exemplo de camadas de protec¸˜ao adaptado de (SUMMERS, 2003) 30 Figura 2 Separac¸˜ao entre um SIS e o sistema de controle do processo

adaptado de (LUNDTEIGEN; RAUSAND, 2008) . . . 32

Figura 3 Exemplo de um fluxograma de forno industrial (PRATI, 2014) 34 Figura 4 Metodologia de desenvolvimento de um SIS . . . 36

Figura 5 Sequˆencia de estados para f´ormulas ltl b´asicas adaptado de (CLARKE; GRUMBERG; PELED, 1999) . . . 41

Figura 6 M´etodo de verificac¸˜ao formal proposta . . . 43

Figura 7 Etapa de Transformac¸˜ao . . . 44

Figura 8 Bloco de Verificac¸˜ao Formal . . . 45

Figura 9 Estrutura b´asica de um CLP (WEBB; REIS, 1998) . . . 52

Figura 10 Ciclo de execucc¸˜ao de um CLP . . . 52

Figura 11 Contatos e Bobinas do diagrama Ladder (IEC 61131, 2003) . . . . 54

Figura 12 Programa em Diagrama Ladder, contendo contatos, bobinas e blocos funcionais . . . 55

Figura 13 Bloco de votac¸˜ao 2oo3 . . . 56

Figura 14 Arquitetura do programa de CLP em FIACRE proposta por (SOUZA; FARINES; QUEIROZ, 2010) . . . 60

Figura 15 Arquitetura do programa de CLP em FIACRE . . . 61

Figura 16 Component PLC em FIACRE do programa em Ladder, ilustrado na figura 12 . . . 62

Figura 17 Representac¸˜ao do process scan cycle do programa Ladder da figura12 . . . 64

Figura 18 Elementos b´asicos em um rung (SOUZA, 2010) . . . 65

Figura 19 Rung que cont´em a sa´ıda Q 03 representado em FIACRE . . . . 66

Figura 20 Bloco Funcional temporizado em um rung em Ladder . . . 66

Figura 21 Rung que cont´em a sa´ıda Q 01 com bloco de func¸˜ao tempori-zado em FIACRE . . . 67

Figura 22 Bloco Funcional sem temporizac¸˜ao em um rung em Ladder . . 68

Figura 23 Rung que cont´em a sa´ıda Q 04 com bloco de func¸˜ao sem temporizac¸˜ao em FIACRE . . . 68

Figura 24 Comportamento do processo bloco temporizador TON (SOUZA; FARINES; QUEIROZ, 2010) . . . 69

Figura 25 Comportamento do processo bloco temporizador TOF (SOUZA;

FARINES; QUEIROZ, 2010) . . . 71

Figura 26 Sa´ıda Q 04 que apresenta um bloco funcional sem temporizac¸˜ao 72 Figura 27 Estrutura de uma probe Causa e Efeito . . . 76

Figura 28 Contador temporal para entradas temporizadas . . . 80

Figura 29 Cone de Influˆencia . . . 85

Figura 30 Cone de Influˆencia para a sa´ıda Q 02 . . . 90

Figura 31 Segunda etapa de reduc¸˜ao na propriedade safe failure free para a sa´ıda Q 02 . . . 91

Figura 32 Segunda etapa de reduc¸˜ao na propriedade dangerous failure freepara a sa´ıda Q 02 . . . 92

Figura 33 Cadeia de verificac¸˜ao gen´erica (SOUZA, 2010) . . . 92

Figura 34 Processo de traduc¸˜ao do contraexemplo . . . 94

Figura 35 Contraexemplo na forma de diagrama de sinais para a causa Q 02 . . . 95

Figura 36 Contraexemplo na forma de diagrama de sinais para a causa Q 04 . . . 96

Figura 37 Contraexemplo na ferramenta de simulac¸˜ao e teste . . . 97

Figura 38 Erros inseridos no Diagrama Ladder da figura 12 . . . 99

Tabela 1 Exemplo de probe Causa e Efeito . . . 78 Tabela 2 Resultados do exemplo did´atico sem a etapa de reduc¸˜ao por COI . . . 100 Tabela 3 Resultados do exemplo did´atico reduzidos por COI . . . 101 Tabela 4 Resultados das sa´ıdas Q 01, Q 03 e Q 04 reduzidos por COI e por reduc¸˜ao baseada nas propriedades em LTL . . . 101 Tabela 5 dangerous failure freepara a sa´ıda Q 02 reduzida por COI e por reduc¸˜ao baseada nas propriedades em LTL . . . 102 Tabela 6 safe failure free para a sa´ıda Q 02 reduzida por COI e por reduc¸˜ao baseada nas propriedades em LTL . . . 102 Tabela 7 Resultados das 6 MCEs . . . 103 Tabela 8 Resultados da Matriz 7 reduzida por COI e por reduc¸˜ao baseada nas propriedades em LTL . . . 105

BPCS Basic Process Control System CLP Controlador L´ogico Program´avel COI Cone of Influence

CPU Central Processing Unit CTL Computation Tree Logic FBD Function Block Diagram IL Instructions List

IP&G Ind´ustria de Petr´oleo e G´as

LD Ladder Diagram

LTL Linear Temporal Logics MCE Matriz de Causa e Efeito MDE Model Driven Engineering MSS Mecatronic Standard System SFC Sequential Function Chart SIF safety instrumented function SIL safety integrated level

SIS Sistemas Instrumentados de Seguranc¸a ST Structured Text

TAF Factory Acceptance Test

TCTL Temporal Computation Tree Logic TON Timer on-delay

TOF Timer off-delay TPN Temporal Petri Net TTS Time Transition Systems

1 INTRODUC¸ ˜AO . . . 23 1.1 OBJETIVOS . . . 26 1.2 ESTRUTURA DO TRABALHO . . . 27

2 METODOLOGIA DE DESENVOLVIMENTO DE

SISTE-MAS INSTRUMENTADOS DE SEGURANC¸ A NA IND ´USTRIA DE PETR ´OLEO E G ´AS . . . 29 2.1 SISTEMA INSTRUMENTADO DE SEGURANC¸ A . . . 29 2.2 METODOLOGIA DE DESENVOLVIMENTO ATUAL . . . 33 2.3 M ´ETODOS DE VALIDAC¸ ˜AO DE CLP . . . 37 2.3.1 Model Checking e L´ogicas Temporais . . . 38 2.4 M ´ETODO PROPOSTO . . . 41 2.5 TRABALHOS RELACIONADOS . . . 45 3 TRANSFORMAC¸ ˜OES DE MODELO . . . 51 3.1 CONTROLADOR L ´OGICO PROGRAM ´AVEL (CLP) . . . 51 3.2 DIAGRAMA LADDER . . . 53 3.2.1 Elementos b´asicos do Ladder . . . 54 3.2.2 Blocos funcionais . . . 54 3.2.3 Exemplo did´atico . . . 55 3.3 FIACRE . . . 56 3.4 TRANSFORMAC¸ ˜AO DIAGRAMA LADDER PARA FIACRE 60 3.4.1 Modelo do ciclo de execuc¸˜ao . . . 62 3.4.2 Representac¸a˜o dos rungs em FIACRE . . . 64 3.4.3 Blocos de func¸˜ao . . . 68 4 TRANSFORMAC¸ ˜AO DE PROPRIEDADES PARA LTL . . 75 4.1 MATRIZ DE CAUSA EFEITO . . . 75 4.2 TRANSFORMAC¸ ˜AO DAS PROPRIEDADES EXPRESSAS

NA MCE EM REGRAS LTL . . . 77 5 CADEIA DE VERIFICAC¸ ˜AO FORMAL . . . 83 5.1 M ´ETODO DE DECOMPOSIC¸ ˜AO DO MODELO . . . 83 5.1.1 Cone de Influˆencia - COI . . . 83 5.1.2 Reduc¸˜ao baseada nas propriedades em LTL . . . 86 5.2 AMBIENTE DE VERIFICAC¸ ˜AO . . . 91 5.3 APRESENTAC¸ ˜AO DO CONTRAEXEMPLO . . . 94 6 RESULTADOS . . . 99 6.1 RESULTADOS DA VERIFICAC¸ ˜AO FORMAL NO

EXEM-PLO

6.2 RESULTADO DA VERIFICAC¸ ˜AO FORMAL EM APLICAC¸ ˜OES REAIS . . . 102 7 CONCLUS ˜AO . . . 107 REFER ˆENCIAS . . . 111 AP ˆENDICE A -- C ´ODIGO EM FIACRE DO EXEMPLO DID ´ATICO . . . 117 AP ˆENDICE B -- PROPRIEDADES EM LTL EXTRA´IDAS NA MATRIZ CAUSA E EFEITO DA TABELA 1 . . . 121 AP ˆENDICE C -- C ´ODIGO FIACRE DA SA´IDA Q 01 RE-DUZIDO . . . 125 AP ˆENDICE D -- C ´ODIGO EM FIACRE dA MATRIZ CAUSA E EFEITO N ´UMERO 1 . . . 129 AP ˆENDICE E -- C ´ODIGO EM FIACRE dA MATRIZ CAUSA E EFEITO N ´UMERO 6 . . . 135

1 INTRODUC¸ ˜AO

A descoberta do pr´e-sal, anunciada em 2007, ´e fruto de longos anos da evoluc¸˜ao e da especificidade da atividade explorat´oria offshore no Brasil. Os reservat´orios do pr´e-sal est˜ao a 7.000 metros de profundidade em relac¸˜ao ao n´ıvel do mar e mais de 300 quilˆometros da costa, o que revela um contexto repleto de desafios tecnol´ogicos a serem superados. Conforme o Instituto Brasileiro do Petr´oleo, G´as e Biocombust´ıveis (IBP, 2016), os investimentos em ´areas j´a descobertas no pr´e-sal podem chegar a US$ 120 bilh˜oes. Todo este investimento em explorac¸˜ao e pesquisa visa `a identificac¸˜ao das principais caracter´ısticas geol´ogicas das bacias e reservat´orios de petr´oleo, possibili-tando, assim, diferentes e progressivas escalas de produc¸˜ao e, principalmente, o crescente aperfeic¸oamento de requisitos tecnol´ogicos e de infraestrutura. Tendo em vista a complexidade e desafios para explorar esta nova reserva de petr´oleo, seguranc¸a e confiabilidade tornaram-se parˆametros essenciais nos projetos para extrac¸˜ao de petr´oleo e g´as natural. Preocupac¸˜oes acerca de fato-res como seguranc¸a de pessoal, protec¸˜ao das instalac¸˜oes e do meio ambiente tˆem influenciado, de forma cada vez mais significativa, as especificac¸˜oes dos novos processos industriais. As vantagens econˆomicas de um sistema seguro e confi´avel incluem menores perdas de produc¸˜ao, maior qualidade dos produtos, reduc¸˜ao de custos com seguros, reduc¸˜ao dos gastos com manutenc¸˜ao e custos associados.

Haja vista a crescente preocupac¸˜ao com a seguranc¸a dos processos industriais, a norma IEC 61508 (IEC 61508, 1998) padroniza os Sistemas Ins-trumentados de Seguranc¸a (SIS) que configuram em uma camada de protec¸˜ao independente do controle de processos industriais. S˜ao sistemas passivos, com-postos por sensores, atuadores e resolvedores l´ogicos, cuja responsabilidade ´e levar a planta a um estado seguro sempre que for detectada alguma situac¸˜ao de risco no processo (GRUHN; CHEDDIE, 2006). Falhas no funcionamento do SIS podem acarretar acidentes graves com desastres ambientais e morte de pessoas, al´em de preju´ızo financeiro e `a imagem da empresa. Como por exemplo, um SIS respons´avel por assistir a press˜ao dentro de uma torre de fracionamento de petr´oleo. Neste caso, se a press˜ao atingir n´ıveis alarmantes e o SIS, por alguma falha, n˜ao entrar em ac¸˜ao, ocorre uma explos˜ao da torre, causando enorme preju´ızo financeiro e a imagem da empresa e principalmente pondo em risco a vida de trabalhadores.

Antes da popularizac¸˜ao dos microprocessadores, os sistemas de con-trole de processos eram constitu´ıdos por grandes pain´eis de rel´es el´etricos, por´em, a partir da d´ecada de 70 esses sistemas passaram a ser compostos por um hardware especializado que emula a l´ogica de rel´es. Este

hard-24

waredenominado Controlador L´ogico Program´avel (CLP) trouxe maior facili-dade de programac¸˜ao e reprogramac¸˜ao, permitiu tamb´em a possibilifacili-dade de manutenc¸˜ao e reparo por interm´edio de blocos de entrada e sa´ıda modulares, reduziu consideravelmente o tamanho dos sistemas de controle em comparac¸˜ao ao sistema tradicional, possibilita expans˜oes sem grandes alterac¸˜oes no sis-tema e tamb´em por possuir estac¸˜oes de operac¸˜ao com interface mais amig´avel (BOLTON, 2015).

Os CLPs se relacionam com a planta atrav´es de elementos de interface conectados ao meio f´ısico, onde os sensores s˜ao os respons´aveis por suprir o CLP com as informac¸˜oes do processo, os atuadores s˜ao respons´aveis pelas ac¸˜oes do CLP sobre o processo e a tomada de decis˜ao de controle ´e reali-zada por interm´edio da execuc¸˜ao c´ıclica do programa de controle que fica armazenado na mem´oria do CLP. Estes programas podem ser escritos em 5 linguagens distintas, estipuladas pela norma IEC 61131-1. Cada lingua-gem tem suas vantagens e desvantagens, sendo umas mais textuais e outras mais gr´aficas (IEC, 2003). O m´etodo de verificac¸˜ao formal proposto nesta dissertac¸˜ao aprofunda-se na linguagem de programac¸˜ao de CLP que emula a antiga l´ogica de rel´es denominada Ladder; essa linguagem em espec´ıfico ´e detalhada por se tratar da linguagem principal, escolhida pela ind´ustria de petr´oleo e g´as natural para programar os CLPs que controlam os SIS em suas operac¸˜oes. Por´em o m´etodo pode ser expandido e adaptado para as 4 outras linguagens de programac¸˜ao de CLP.

Na Ind´ustria de Petr´oleo e G´as (IP&G), o desenvolvimento de pro-gramas de CLP segue uma metodologia rigorosa, baseada em normas para especificac¸˜ao, implementac¸˜ao e testes de SIS. Estas normas gerais podem ser vistas em (N-1883, 2002) e (N-2595, 2012). Segundo as normas, esta metodolo-gia ´e baseada na criac¸˜ao de um conjunto de documentos organizados em uma ordem espec´ıfica, onde cada documento provˆe informac¸˜oes importantes para o progresso do projeto. Dentre os documentos, pode-se destacar o Teste de Aceitac¸˜ao de F´abrica (TAF), documento este que apresenta de forma textual como os testes devem ser realizados para que o programa de intertravamento implementado no CLP seja aprovado e o documento Matriz de Causa e Efeito que est´a presente nas etapas de desenvolvimento do SIS e ´e respons´avel por representar as especificac¸˜oes de seguranc¸a deste tipo de sistema.

Para se validar um programa de CLP, existem algumas abordagens, destacando entre elas as t´ecnicas de modelagem e simulac¸˜ao, testes de sistemas e verificac¸˜ao formal (GERGELY; COROIU; POPENTIU-VLADICESCU, 2011). Cada m´etodo de validac¸˜ao possui vantagens e desvantagens, sendo assim, a escolha do m´etodo a ser utilizado em cada sistema depende de uma s´erie de fatores, como a complexidade do sistema, disponibilidade de ferramentas de teste, conhecimento dos engenheiros envolvidos na etapa de teste, entre outros.

Na IP&G, a t´ecnica adotada ´e o m´etodo de teste de sistema. M´etodo este que consiste em simular a execuc¸˜ao do programa testando o acionamento de algumas entradas e observando o comportamento das sa´ıdas produzidas pelo sistema. A aceitac¸˜ao ou rejeic¸˜ao das sa´ıdas determina se o programa est´a aprovado ou tem que retornar para etapa de programac¸˜ao para correc¸˜ao de erros. Este tipo de teste n˜ao ´e exaustivo, ou seja, pode ser realizada apenas para uma quantidade limitada de cen´arios. Com o n´umero crescente de vari´aveis de entrada e com a possibilidade do programa ser alterado durante a etapa de programac¸˜ao, o n´umero de cen´arios a serem testados cresce rapidamente.

M´etodos formais de verificac¸˜ao permitem a validac¸˜ao autom´atica do programa de CLP, esse tipo de verificac¸˜ao ´e desenvolvida a partir da mode-lagem matem´atica do sistema e da formalizac¸˜ao dos requisitos (FREY; LITZ, 2000). Os algoritmos de verificac¸˜ao por model-checking se baseiam em busca exaustiva no espac¸o de estados do modelo por inconformidades com os requi-sitos (CLARKE; GRUMBERG; PELED, 1999). Quando erros s˜ao encontrados, os algoritmos geram contraexemplos que podem auxiliar o engenheiro a corrigir o programa. Entretanto m´etodos formais s˜ao pouco utilizados em programas de-senvolvidos em linguagens de alto n´ıvel, tamb´em conhecida como linguagens a n´ıveis de usu´arios. Isso ocorre devido ´a complexidade de transformar progra-mas e especificac¸˜oes escritas em alto n´ıvel em linguagem formal. Tendo em vista este fator, diversos trabalhos prop˜oem soluc¸˜oes para adicionar verificac¸˜ao formal no desenvolvimento de programas para diversas linguagens como ( OLI-VEIRA, 2006), (MOKADEM et al., 2005) e (ZOUBEK; ROUSSEL; KWIATKOWSKA, 2003).

Em (FARINES et al., 2011) e (BERTHOMIEU et al., 2008), o objetivo ´e desenvolver soluc¸˜oes para que desenvolvedores possam realizar a verificac¸˜ao formal, utilizando apenas as linguagens de usu´ario. Nesses trabalhos, o modelo escrito em linguagem de usu´ario passa por sucessivas transformac¸˜oes at´e ser representado por um modelo formal que sirva de entrada para ferramentas de verificac¸˜ao. Esta sequˆencia de transformac¸˜oes, ´e denominada cadeia de verificac¸˜ao formal. No trabalho de (FARINES et al., 2011), a cadeia de verificac¸˜ao inicia com a linguagem intermedi´aria FIACRE. A utilizac¸˜ao dessa linguagem intermedi´aria ´e vantajosa, pois o FIACRE ´e uma linguagem de alto n´ıvel e possui ferramentas autom´aticas que o transformam em uma s´erie de linguagens formais.

Tendo em vista as limitac¸˜oes dos m´etodos de validac¸˜ao de CLP atrav´es de testes, da crescente complexidade dos programas de controle de sistemas de seguranc¸a e da importˆancia do funcionamento sem erros dos SIS. ´E desen-volvido, neste trabalho, um m´etodo de verificac¸˜ao formal para validar os CLPs que controlam os SIS da IP&G a n´ıvel de linguagem de usu´ario. Logo, para realizar a verificac¸˜ao, o programa de seguranc¸a escrito em Ladder passa por

26

uma cadeia de verificac¸˜ao formal at´e ser representado em linguagem formal. A cadeia proposta nesta dissertac¸˜ao, assim como a cadeia proposta por (FARINES et al., 2011), inicia com a transformac¸˜ao da linguagem Ladder para a linguagem intermedi´aria FIACRE.Os SIS que protegem os os sitemas autom´aticos na IP&G s˜ao sistemas de grande complexidade, ou seja, com um grande n´umero de entradas e sa´ıdas. Sendo assim as regras de traduc¸˜ao (Ladder para FIACRE) foram desenvolvidas de maneira a minimizar o m´aximo poss´ıvel o numero de estados na linguagem FIACRE e por conseguinte minimizar o tamanho do modelo formal. Ainda com o intuito de simplificar o modelo formal, foi adicionada `a cadeia de verificac¸˜ao uma etapa de reduc¸˜ao do modelo formal pelo m´etodo de Cone de Influˆencia, est´a t´ecnica analisa todos os elementos quem influenciam na verificac¸˜ao da propriedade e abstrai todos os elementos que n˜ao realizam influˆencia. A pr´oxima etapa da cadeia ´e a transformac¸˜ao do modelo em linguagem intermedi´aria em modelo formal pela ferramenta FRAC (BERTHOMIEU et al., 2008) e a verificac¸˜ao formal ´e feita atrav´es do software open sourceTINA/SELT (BERTHOMIEU; VERNADAT, 2006). As propriedades de seguranc¸a s˜ao escritas em l´ogica temporal do tipo LTL de forma autom´atica a partir da Matriz de Causa e Efeito e o contraexemplo resultante da verificac¸˜ao ´e traduzido para ser apresentado de maneira gr´afica.

1.1 OBJETIVOS

O presente trabalho de mestrado objetiva desenvolver um m´etodo de verificac¸˜ao formal para os programas de CLP que controlam os sistemas instrumentados de seguranc¸a na ind´ustria de petr´oleo e g´as. O m´etodo proposto deve se enquadrar na atual metodologia de desenvolvimento de programas de CLP da IP&G, de forma a ser um complemento `a atual metodologia de simulac¸˜ao e testes.

Aplicar m´etodos formais em sistemas reais apresenta uma s´erie de desafios, como a dificuldade de representar o programa e as propriedades em linguagens formais, a explos˜ao de estados nos modelos formais devido a com-plexidade do sistema, o pouco h´abito de engenheiros projetistas com m´etodos formais, entre outros. Sendo assim, para realizar a verificac¸˜ao formal em n´ıvel de usu´ario de ponta a ponta do processo de verificac¸˜ao o desenvolvimento do m´etodo de verificac¸˜ao formal proposto neste trabalho estabeleceu uma s´erie de objetivos espec´ıficos a serem trabalhados:

• Criar regras de traduc¸˜ao do programa escrito em Diagrama Ladder, para linguagem intermedi´aria FIACRE;

Matriz de Causa e Efeito, em l´ogica temporal do tipo LTL e desenvolver um script que realize esta traduc¸˜ao de forma autom´atica;

• Desenvolver uma t´ecnica de reduc¸˜ao ao programa FIACRE, com intuito de resolver o problema de explos˜ao combinacional no modelo formal; • Apresentar o contraexemplo gerado pelo SELT de forma compreens´ıvel

aos engenheiros projetistas dos SIS;

• Aplicar o m´etodo proposto a exemplos reais da IP&G.

1.2 ESTRUTURA DO TRABALHO

A dissertac¸˜ao est´a dividida em sete cap´ıtulos, que s˜ao descritos a seguir. No Cap´ıtulo 2, ´e realizado, inicialmente, uma breve revis˜ao bibliogr´afica sobre sistemas instrumentados de seguranc¸a e m´etodos de validac¸˜ao de CLP, dando enfoque a model checking e l´ogicas temporais. Ainda no Cap´ıtulo 2, ´e apre-sentada a atual metodologia de desenvolvimento de sistemas instrumentados de seguranc¸a na ind´ustria de petr´oleo e g´as e o m´etodo verificac¸˜ao formal pro-posta nesta dissertac¸˜ao. Finalizando o cap´ıtulo, s˜ao apresentados os trabalhos relacionados.

No Cap´ıtulo 3, ´e apresentada a primeira etapa da cadeia de verificac¸˜ao formal que s˜ao as regras de transformac¸˜ao de Diagrama Ladder para a lingua-gem FIACRE. Tamb´em ´e realizada uma fundamentac¸˜ao te´orica sobre CLPs, Diagrama Ladder e a linguagem intermedi´aria FIACRE. Neste cap´ıtulo, ´e apresentado um exemplo did´atico que ser´a utilizado para ilustrar todas as etapas da cadeia de verificac¸˜ao formal.

No Cap´ıtulo 4, ´e apresentada a segunda etapa da cadeia de verificac¸˜ao formal, inicialmente ´e detalhada o funcionamento da Matriz de Causa e efeito e, posteriormente, as regras de transformac¸˜ao das propriedades expressas na MCE em regras temporais do tipo LTL.

No Cap´ıtulo 5, ´e detalhada a cadeia de verificac¸˜ao FIACRE/TINA/-SELT, em seguida ´e realizado um estudo sobre m´etodos de reduc¸˜ao e s˜ao apresentados os m´etodos de reduc¸˜ao cone de influˆencia e por simplificac¸˜ao da regra LTL , m´etodos esses utilizados nesta dissertac¸˜ao. Ainda neste ca-pitulo, s˜ao explicadas as regras para apresentac¸˜ao do contraexemplo para os engenheiros projetistas de SIS.

No Cap´ıtulo 6, s˜ao apresentados os resultados da aplicac¸˜ao do m´etodo no programa did´atico e nos programas de CLP que controlam os sistemas ins-trumentados de seguranc¸a de uma plataforma offshore real.. Para finalizar, no cap´ıtulo 7, ´e feita uma conclus˜ao e s˜ao apresentadas sugest˜oes para trabalhos futuros.

2 METODOLOGIA DE DESENVOLVIMENTO DE SISTEMAS INSTRUMENTADOS DE SEGURANC¸ A NA IND ´USTRIA DE PETR ´OLEO E G ´AS

Neste cap´ıtulo, inicialmente, s˜ao abordados os conceitos b´asicos sobre sistemas instrumentados de seguranc¸a e m´etodos de validac¸˜ao de CLP, dando um enfoque em m´etodos formais como o model checking. Posteriormente, s˜ao detalhados a atual metodologia de desenvolvimento de programas de CLP pelo IP&G e o m´etodo de verificac¸˜ao formal proposto nesta dissertac¸˜ao que tem como objetivo se adaptar `a metodologia vigente. Finalizando o cap´ıtulo, s˜ao apresentados os trabalhos relacionados a esta dissertac¸˜ao.

2.1 SISTEMA INSTRUMENTADO DE SEGURANC¸ A

Sistema Instrumentado de Seguranc¸a (SIS - Safety Instrumented Sys-tem) ´e uma classe de sistema, padronizado pela norma IEC 615111 (IEC 61511, 2003), utilizado para garantir maior seguranc¸a operacional das unidades, equi-pamentos e funcion´arios de uma ind´ustria. O SIS tem como objetivo evitar uma condic¸˜ao insegura de operac¸˜ao do processo. Para que isto ocorra, esse tipo de sistema pode provocar uma parada no processo, impedir a partida da unidade ou encaminhar o processo a um estado seguro caso n˜ao sejam atendidas as condic¸˜oes limites estabelecidas como seguras para a operac¸˜ao da planta industrial (GRUHN; CHEDDIE, 2006).

Para tornar a produc¸˜ao o mais segura poss´ıvel, na ind´ustria s˜ao utili-zadas diversas camadas de protec¸˜ao para salvaguardar o processo. A t´ecnica denominada LOPA (Layers of Protection Analysis) avalia o risco de acidente da operac¸˜ao e a partir desta analise e define o n´umero de camadas de protec¸˜ao necess´arias, dependendo da complexidade do processo e do potencial de de-sastres quando um cen´ario de excec¸˜ao ´e atingido. Cada camada de protec¸˜ao ´e projetada de maneira independente das outras camadas da planta, tendo como finalidade evitar a ocorrˆencia ou reduzir as consequˆencias de um evento espec´ıfico. Camadas de protec¸˜ao podem ser desde equipamentos e procedi-mentos operacionais a ac¸˜oes planejadas em resposta a condic¸˜oes adversas do processo (SUMMERS, 2003). Na Figura 1, encontram-se ilustrados alguns exem-plos de camadas de protec¸˜ao presentes em diversos processos industriais. As camadas s˜ao apresentadas por ordem de ativac¸˜ao esperada, dada a ocorrˆencia de uma condic¸˜ao de perigo.

Em um processo industrial, a primeira camada de seguranc¸a ´e execu-tada pelo sistema de controle do processo (BPCS - Basic Process Control

30

Figura 1 – Exemplo de camadas de protec¸˜ao adaptado de (SUMMERS, 2003)

System), que objetiva manter as vari´aveis do processo dentro do limite es-tabelecido como ideal para as condic¸˜oes de produc¸˜ao. Caso o controle do processo n˜ao consiga manter estas condic¸˜oes, a pr´oxima camada acionada ´e a de “intervenc¸˜ao do operador”, camada constitu´ıda de alarmes e indicadores que s˜ao utilizados como aux´ılio aos operadores para inform´a-los das condic¸˜oes do processo, para que estes possam intervir diretamente no processo, evitando uma condic¸˜ao perigosa.

Se nenhuma destas camadas for suficiente para controlar a vari´avel pe-rigosa, entra em ac¸˜ao o sistema instrumentado de seguranc¸a, que atua de forma operacional, por exemplo, desligando um motor com problema e ligando outro que tenha a func¸˜ao de redundˆancia, ou simplesmente provocando a parada segura da unidade. O SIS pode tamb´em impedir a partida de equipamentos, se as condic¸˜oes n˜ao forem satisfeitas. At´e a camada do SIS, temos as camadas de prevenc¸˜ao, entretanto quando no processo h´a grandes riscos ambientais e/ou a vida humana, pode(m) haver mais camadas de mitigac¸˜ao de danos. Estas camadas s˜ao camadas de resposta a falha grave, como dispositivos de protec¸˜ao adicional ou at´e mesmo planos para evacuac¸˜ao da planta e em casos extremos da comunidade no entorno da instalac¸˜ao industrial.

O Sistema Instrumentado de Seguranc¸a deve ter prioridade e ser inde-pendente do sistema de controle do processo, ou de qualquer outro sistema da unidade, ele deve agir como uma camada superior, agindo caso nenhuma outra alternativa para o controle das vari´aveis do processo tenha tido sucesso. Esta camada tem total prioridade sobre a ac¸˜ao de operadores ou a ac¸˜ao de qualquer sistema de controle de processo. O objetivo principal do SIS ´e levar o processo para um estado seguro. N˜ao necessariamente o processo deve ser interrompido, ou todos os sistemas devam ser desligados. Embora um sistema de seguranc¸a seja semelhante a um sistema de controle do processo estrutural-mente, estes sistemas s˜ao consideravelmente diferentes. As diferenc¸as residem nos rigorosos requisitos de projeto, manutenc¸˜ao e integridade f´ısica do SIS. Como este sistema atua somente em situac¸˜oes de excec¸˜ao, o mesmo requer um n´ıvel de confiabilidade e diagn´ostico superior ao normalmente solicitado para um BPCS (LUNDTEIGEN; RAUSAND, 2008).

Na figura 2, pode-se observar a separac¸˜ao entre o sistema de seguranc¸a e o sistema de controle. Nela ´e poss´ıvel observar um tanque controlado por um sistema de controle que cont´em um sensor respons´avel por monitorar a vari´avel press˜ao, dois sensores para monitorar a temperatura e uma v´alvula respons´avel por alimentar o tanque. Neste sistema, a abertura da v´alvula ´e controlada a partir das informac¸˜oes obtidas pelos sensores. Na figura tamb´em se observa que o SIS atua em separado do sistema de controle. Nele temos dois sensores que monitoram a press˜ao e um sensor respons´avel por monitorar a temperatura. O SIS recebe informac¸˜ao dos sensores em tempo integral, por´em s´o entra em ac¸˜ao quando uma situac¸˜ao de risco ´e detectada. No caso da figura 2, podemos observar que o sistema de protec¸˜ao possui duas v´alvulas capazes de interromper o abastecimento do tanque; esta redundˆancia ocorre por motivos de seguranc¸a, caso uma v´alvula falhe, existe outra capaz de realizar o mesmo efeito. Este tipo de redundˆancia ´e muito comum em SIS.

Um SIS ´e composto pelo conjunto de uma ou mais func¸˜oes instru-mentadas de seguranc¸a (safety instrumented function - SIF), implantadas em uma unidade de processo. Para cada evento gerador de risco ´e aplicada uma func¸˜ao de seguranc¸a, projetada para reduzir a possibilidade de acidentes a um n´ıvel considerado como aceit´avel, ou seja, para que venha a ser atingida uma probabilidade e estat´ıstica calculada de falha. Para isso, ´e necess´ario identificar os eventos geradores de acidentes e estimar adequadamente o “risco inerente” ao processo (CRUZ-CAMPA; CRUZ-G ´OMEZ, 2010).

O n´ıvel de integridade de seguranc¸a (safety integrated level - SIL), definido na norma IEC 61508 (IEC 61508, 1998) ´e a medida de seguranc¸a esperada de um SIF quando for solicitado. Ou seja, o n´ıvel de confiabilidade necess´ario a ser implementado de forma a reduzir o risco do processo a n´ıveis aceit´aveis. Consequentemente, quanto maior o SIL mais seguros os

32

Figura 2 – Separac¸˜ao entre um SIS e o sistema de controle do processo adaptado de (LUNDTEIGEN; RAUSAND, 2008)

equipamentos utilizados no SIF, em consequˆencia muito mais caros.

Existe duas maneiras de cada SIF falhar, uma delas ´e quando for necess´ario levar o processo a um estado seguro e isto n˜ao acontecer (Dangerous Failure). Como por exemplo, na figura 2, ocorreria uma Dangerous Failure caso a press˜ao no tanque alcanc¸asse valores cr´ıticos e as v´alvulas respons´aveis por interromper a alimentac¸˜ao do tanque n˜ao entrassem em ac¸˜ao, podendo, assim, causar uma explos˜ao no tanque.

A outra falha poss´ıvel ocorre quando o sistema de intertravamento atua sem necessidade (Safe Failure). Podemos exemplificar novamente com o exemplo da figura 2, neste exemplo seria detectado um Safe Failure caso o sistema esteja em condic¸˜oes normais de funcionamento, mas mesmo assim o SIS acionasse as v´alvulas respons´aveis por interromper a alimentac¸˜ao do tanque, parando o sistema sem motivo real para isto. O SIL ´e tabulado considerando apenas a Dangerous Faliure.

Para melhorar sua confiabilidade e disponibilidade, ´e comum a impleme-ntac¸˜ao de um certo n´ıvel de redundˆancia de hardware e/ou software em projeto de SIS. Isso possibilita a determinac¸˜ao de uma soluc¸˜ao que atenda os requisitos operacionais do processo.

A notac¸˜ao MooN (M-out-of-N) ´e utilizada na literatura para denotar as diferentes arquiteturas de redundˆancia existentes. Tais esquemas s˜ao popu-larmente chamados de votac¸˜ao. As votac¸˜oes podem ser aplicadas tanto nos

elementos de entrada do sistema (sensores) quanto nos elementos finais (atua-dores). A votac¸˜ao entre os sensores de entrada s˜ao arquiteturas comumente encontradas em SIS.

Na votac¸˜ao denominada 1oo1, a medic¸˜ao da vari´avel a ser observada ´e realizada apenas por um equipamento sensor. J´a na votac¸˜ao 1oo2, s˜ao utilizados dois sensores para a medic¸˜ao da mesma vari´avel do processo e o atuador entre em ac¸˜ao caso uma condic¸˜ao perigosa seja detectada por qualquer um dos dois sensores. A votac¸˜ao 2oo3 ´e utilizada quando se deseja comparar a medic¸˜ao realizada por trˆes sensores, pois o atuador ´e acionado quando ao menos dois dos trˆes sensores detectam uma condic¸˜ao perigosa. A votac¸˜ao 2oo3 proporciona maior protec¸˜ao contra desligamentos desnecess´arios, decorrentes de falsas indicac¸˜oes de falha por parte dos sensores.

2.2 METODOLOGIA DE DESENVOLVIMENTO ATUAL

A metodologia de desenvolvimento de projetos de automac¸˜ao, atu-almente utilizada em empresas de petr´oleo e g´as, ´e realizada por m´ultiplas equipes que s˜ao respons´aveis pela criac¸˜ao de um conjunto de documentos or-ganizados em uma ordem espec´ıfica, onde cada documento provˆe informac¸˜oes importantes para o progresso do projeto.

Para o melhor entendimento desta metodologia, inicialmente, ser˜ao apresentados os documentos adotados em um projeto de automac¸˜ao na Pe-trobras , assim como as informac¸˜oes contidas em cada um, ressaltando os documentos diretamente relacionados com o desenvolvimento do programa do CLP. De acordo com normas internas da Petrobras (N-1883, 2002) e (N-2595, 2012), os documentos considerados essenciais para criac¸˜ao de um projeto de automac¸˜ao s˜ao:

• Fluxograma de processo: Cont´em uma representac¸˜ao simplificada das malhas de controle, informando a localizac¸˜ao e a vari´avel das v´alvulas de controle, seguranc¸a e al´ıvio. A figura 3 exemplifica um fluxograma de um forno industrial (N-1883, 2002);

• Folhas de dados de processo: Cont´em as informac¸˜oes de correlac¸˜ao e dimensionamento dos instrumentos;

• Matriz de Causa e Efeito: Este documento, detalhado na sec¸˜ao 4.1, mostra o inter-relacionamento entre as entradas e sa´ıdas do sistema, representando as propriedades de seguranc¸a com intuito de diagramar os eventos anormais poss´ıveis de ocorrer durante o funcionamento di´ario da planta. Representa, tamb´em, as ac¸˜oes que devem ser tomadas pelo sistema de seguranc¸a, como tamb´em manobras operacionais espec´ıficas;

34

Figura 3 – Exemplo de um fluxograma de forno industrial (PRATI, 2014)

• Lista de instrumentos preliminar: Fluxograma que cont´em todos os instrumentos presentes na planta com informac¸˜oes sobre sua situac¸˜ao f´ısica (campo, painel, func¸˜ao em sistema digital, etc.);

• Fluxograma de engenharia preliminar: Malhas de controle, explici-tando as func¸˜oes dos instrumentos, sua identificac¸˜ao preliminar e a sua localizac¸˜ao na planta. Pode conter, tamb´em, notas com recomendac¸˜oes e exigˆencias quanto `a instalac¸˜ao e locac¸˜ao de instrumentos na planta; • Memorial descritivo: Documento com informac¸˜oes b´asicas que

permi-tam a completa especificac¸˜ao de equipamentos e instrumentos assim como o sequenciamentos destes na planta;

• Diagrama l´ogico: Documento constru´ıdo conforme definido na ISA 5.1, utilizando ´algebra booleana baseado nos memoriais descritivos para os sistemas de protec¸˜ao, intertravamento e sinalizac¸˜ao e alarme. Este documento representa toda a l´ogica de intertravamento do projeto e pode ser pensado como uma pr´evia do programa final do CLP;

• Arranjo preliminar do painel de controle: Identifica a distribuic¸˜ao dos instrumentos, alarmes, chaves, lˆampadas, espac¸os reservados e demais dispositivos instalados no painel de controle;

• Arquitetura de instrumentac¸˜ao; • Lista de vari´aveis (entradas e sa´ıdas); • Diagramas de controle avanc¸ado;

• Descritivos das malhas de controle avanc¸ado: Deve conter explicac¸˜oes sobre o objetivo e a forma de funcionamento das malhas de controle avanc¸ado, bem como explicitar as equac¸˜oes e parˆametros a serem ajus-tados nas func¸˜oes envolvidas nestas malhas;

• Lista de vari´aveis calculadas.

Dentre os documentos listados, aqueles que est˜ao intimamente relacio-nados `a criac¸˜ao do programa de CLP s˜ao o fluxograma de processos, Matriz de Causa Efeito, memorial descritivo e diagrama l´ogico.

T˜ao importante quanto listar os documentos utilizados na elaborac¸˜ao de um projeto de automac¸˜ao pela IP&G ´e entender como eles se organizam hierar-quicamente. De foma simplificada, o processo de elaborac¸˜ao do programa de CLP se divide em algumas etapas, como se pode observar na figura 4, onde os documentos de uma etapa s˜ao entradas para se elaborar os documentos da etapa seguinte. O primeiro documento a ser desenvolvido ´e o fluxograma de proces-sos, contendo as especificac¸˜oes gerais da planta. Com base nas informac¸˜oes contidas neste documento, s˜ao criados a Matriz de Causa e Efeito (relac¸˜ao entre equipamentos destinados `a seguranc¸a e sinais de sensores que devem ativar ou desativar tais equipamentos) e o memorial descritivo (especificac¸˜oes de equipamentos e sequenciamentos para a planta). A informac¸˜ao conjunta dos dois ´ultimos documentos permite a criac¸˜ao do diagrama L´ogico. Este documento cont´em as l´ogicas de intertravamento contidas no futuro programa de CLP. Sendo assim, a partir deste diagrama ´e realizada a programac¸˜ao do CLP na linguagem Ladder.

Dentre os documentos relacionados com a criac¸˜ao do programa de CLP, existe um documento denominado TAF - Teste de Aceitac¸˜ao de F´abrica. Criado com base nas informac¸˜oes contidas no memorial descritivo e na Matriz de Causa e Efeito, o TAF apresenta em forma textual como os testes devem ser realizados para que o programa de intertravamento seja aprovado.

Ap´os a etapa de programac¸˜ao, a pr´oxima etapa do processo ´e a etapa de teste. Nesta etapa, o CLP programado ´e submetido a um conjunto de situac¸˜oes descritas no teste de aceitac¸˜ao de f´abrica e ´e observada a atuac¸˜ao do CLP sobre elas, caso seja detectado algum erro, o programa retorna para etapa de programac¸˜ao para ser corrigido. O tempo de execuc¸˜ao dos testes ´e proporcional `a quantidade de testes presente no TAF. O CLP aprovado segue para a planta para etapa de instalac¸˜ao.

36

Figura 4 – Metodologia de desenvolvimento de um SIS

Sistemas instrumentados de seguranc¸a s˜ao sistemas dormentes. Para este tipo de sistema a realizac¸˜ao de testes deve ser muito rigorosa e conter uma quantidade minima de teste para que se possa garantir o bom funcionamento do programa. O TAF, apesar de conter uma grande quantidade de teste dis-criminado em seu documento, n˜ao garante a exaustividade de testes. Tendo em vista a n˜ao exaustividade deste tipo de teste, o presente trabalho prop˜oe a criac¸˜ao de um m´etodo de verificac¸˜ao formal que se adeque `a atual metodologia de desenvolvimento de CLP na IP&G, tendo em vista que m´etodos formais s˜ao exaustivos e mais seguros.

2.3 M ´ETODOS DE VALIDAC¸ ˜AO DE CLP

No processo de desenvolvimento de um programa de CLP, a etapa de teste ´e de fundamental importˆancia, pois nesta etapa s˜ao detectados poss´ıveis erros de programac¸˜ao que somente seriam encontrados na partida da planta a ser controlada, causando, assim, problemas e atrasos na etapa de instalac¸˜ao. Ou no pior cen´ario, esse erros s´o se manifestariam em situac¸˜oes de excec¸˜ao, colocando em risco a operac¸˜ao da planta. Na pr´atica, existem v´arios m´etodos para realizar a validac¸˜ao do CLP: revis˜ao por pares, modelagem e simulac¸˜ao, teste e verificac¸˜ao formal.

Pesquisas recentes mostram que cerca de 80% dos programas ainda s˜ao validados por revis˜ao por pares. Esse m´etodo, feito manualmente, significa que a verificac¸˜ao do projeto (ou de parte dele) ´e realizada por uma equipe de especialistas que n˜ao estavam envolvidos na concepc¸˜ao do projeto (GERGELY; COROIU; POPENTIU-VLADICESCU, 2011). Apesar deste ser o m´etodo mais utilizado para validar programas de CLP, por ser totalmente manual e n˜ao exaustivo, ´e o m´etodo mais propenso a ocorrer falhas humanas.

Uma t´ecnica de validac¸˜ao de CLP que vem se popularizando ´e a t´ecnica de modelagem e simulac¸˜ao do sistema. Essa t´ecnica baseia-se na contruc¸˜ao de um modelo que descreve os poss´ıveis comportamentos do sistema. Esse modelo, geralmente, ´e executado em um software (chamado simulador) com in-tuito de determinar o comportamento do sistema com base em v´arios cen´arios. Esse cen´ario pode ser fornecido pelo usu´ario, ou por um software (como um gerador de cen´ario aleat´orio). Geralmente, a simulac¸˜ao ´e usada para uma primeira avaliac¸˜ao r´apida da qualidade de um projeto. ´E menos adequado para a detecc¸˜ao de erros sutis porque, em geral, ´e imposs´ıvel simular todo o cen´ario representativo (GERGELY; COROIU; POPENTIU-VLADICESCU, 2011).

Como visto na sec¸˜ao anterior, a validac¸˜ao de programas de CLP ´e realizada na IP&G por interm´edio de testes. Essa t´ecnica de validac¸˜ao consiste em alimentar o sistema com valores de entrada e observar as sa´ıdas produzidas pelo sistema, realizando, assim, uma an´alise dinˆamica do programa produzido, objetivando a identificac¸˜ao e eliminac¸˜ao de poss´ıveis erros contidos no pro-grama. Por se tratar de uma abordagem muito natural para avaliar o correto funcionamento de um programa, essa t´ecnica ´e muito utilizada na ind´ustria como ´ultima etapa de desenvolvimento de um projeto de automac¸˜ao (PRATI, 2014).

A realizac¸˜ao de testes em um programa de CLP, al´em de ser uma t´ecnica demorada, possui algumas desvantagens como: nunca podem ser considerados exaustivos, necessitar de uma an´alise minuciosa nos resultados para que um erro n˜ao seja interpretado como comportamento correto de programa e o conjunto de testes realizados pode ser parcial e dependente daquele que escolhe

38

a rotina de testes. Em perdas de vidas humanas e desastres ambientais h´a grande preju´ızo financeiro e a imagem de uma empresa. Por conseguinte, para esses sistemas, a validac¸˜ao de programas atrav´es de teste n˜ao ´e o m´etodo mais adequado.

A validac¸˜ao de programas de CLP atrav´es de m´etodos de verificac¸˜ao formal s˜ao mais adequados a sistemas cr´ıticos, pois, al´em de se tratar de um m´etodo exaustivo, a norma IEC 61580 (IEC 61580, 1995) prevˆe a utilizac¸˜ao de m´etodos formais, pois este confere `a verificac¸˜ao de programas de CLP uma base matem´atica para sua execuc¸˜ao. Ou seja, nestes m´etodos ´e criado um modelo representativo do programa como objetivo de garantir que certas propriedades sejam testadas exaustivamente com intuito de validar o programa. Dentre os m´etodos para realizar verificac¸˜ao formal, na subsec¸˜ao seguinte, ser´a abordado o m´etodo de model checking (FREY; LITZ, 2000).

2.3.1 Model Checking e L´ogicas Temporais

Model Checking ´e uma t´ecnica autom´atica de verificac¸˜ao formal de sistemas de estados finitos. Esta t´ecnica explora todos os poss´ıveis cen´arios de execuc¸˜ao de um sistema, de um modo ordenado. Sendo assim, por in-term´edio dessa t´ecnica, ´e poss´ıvel demonstrar que um sistema satisfaz certas propriedades em todos os cen´arios, ela tamb´em tem o potencial de revelar erros que passam despercebidos em emulac¸˜oes, testes e simulac¸˜oes (CLARKE; GRUMBERG; PELED, 1999).

Para realizar a verificac¸˜ao em um programa pelo m´etodo model chec-king, ´e necess´ario seguir algumas etapas (CLARKE; GRUMBERG; PELED, 1999): • Modelagem: Nesta etapa, o programa a ser verificado deve ser modelado em linguagem formal. Existe uma gama de linguagens que podem re-presentar o programa como um modelo formal; a escolha da linguagem utilizada na verificac¸˜ao ´e baseada na linguagem utilizada pela ferra-menta verificadora escolhida. Ainda nesta etapa, deve-se formalizar a propriedade a ser verificada na linguagem de descric¸˜ao de propriedades que a ferramenta verificadora pode interpretar;

• Verificac¸˜ao: Realizar a verificac¸˜ao, executando a ferramenta verificadora com intu´ıdo de averiguar a validade das propriedades sobre o modelo; • An´alise: Quando a propriedade ´e satisfeita, o verificador retorna um

OK. Por´em, se a propriedade falhar, deve-se analisar o contraexemplo para encontrar a origem do erro para, em seguida, fazer as modificac¸˜oes necess´arias no projeto e executar novamente a verificac¸˜ao.

O modelo formal mais utilizado em model checking para representar o sistema a ser verificado ´e o sistema de transic¸˜ao denominado “Estrutura de Kripke”. Uma estrutura de Kripke ´e definida por um conjunto finito de estados e relac¸˜oes de transic¸˜ao entre estados. Dado um conjunto finito de propriedades associadas ao modelo, ´e poss´ıvel definir, para cada um dos estados, um subconjunto das propriedades que sejam verdadeiras naquele estado. Essas propriedades s˜ao denominadas proposic¸˜oes atˆomicas e definem cada um dos estados de maneira ´unica, j´a que dois estados diferentes n˜ao podem obedecer a exatamente o mesmo conjunto de proposic¸˜oes atˆomicas (BROWNE; CLARKE; GR ¨UMBERG, 1988).

O model checking possui duas vantagens claras em relac¸˜ao aos m´etodos tradicionais. Em primeiro, o processo ´e totalmente automatizado. Em segundo, quando uma determinada propriedade ´e detectada falsa, a ferramenta gera, automaticamente, um contraexemplo que indica o caminho que o verificador realizou para alcanc¸ar o estado onde a propriedade n˜ao ´e satisfeita; este contraexemplo auxilia o engenheiro projetista a encontrar o erro e realizar as modificac¸˜oes necess´arias no programa.

Um dos principais problemas do model checking ´e a explos˜ao de es-tados. Esse problema ocorre quando o espac¸o de estados do sistema possui um tamanho maior do que ´e poss´ıvel representar com a mem´oria dispon´ıvel no sistema computacional respons´avel por realizar a verificac¸˜ao. Existem v´arias alternativas que podem ser utilizadas para contornar o problema, dentre elas os m´etodos de reduc¸˜ao. Esses m´etodos aplicam uma sequˆencia de regras determinadas com o objetivo abstrair do modelo formal todas os estados e transic¸˜oes irrelevantes a propriedade verificada (CLARKE et al., 2000).

Dentre as linguagens de descric¸˜ao de propriedades existente, a represen-tac¸˜ao por interm´edio de l´ogica temporal ´e um formalismo adequado para representar propriedades para sistemas de transic¸˜oes. A l´ogica temporal ´e uma extens˜ao da l´ogica proposicional ou l´ogica de predicado, adicionando operadores que permitem se referir ao comportamento infinito desses sistemas. As l´ogicas temporais disp˜oem de uma notac¸˜ao axiom´atica e precisa para expressar propriedades sobre relac¸˜oes entre estados em uma execuc¸˜ao.

A representac¸˜ao do tempo em l´ogica temporal pode ser tanto linear quanto ramificada. Na pr´atica, isso significa que quando representado linear-mente, a cada momento no tempo existe somente um momento sucessor. Por outro lado, quando representado de maneira ramificada, cada momento possui uma ramificac¸˜ao onde o tempo pode se dividir em percursos alternativos. A l´ogica temporal CTL (Computation Tree Logic) (CLARKE; EMERSON; SISTLA, 1986) adota a abordagem ramificada, enquanto que a l´ogica LTL (Linear Tem-poral Logics) (PNUELI, 1977) adota a perspectiva linear. Nesse trabalho, as propriedades foram descritas em l´ogica LTL para realizar o model checking,

40

portanto essa linguagem ter´a destaque.

A l´ogica temporal linear (LTL) ´e um complemento da l´ogica tradi-cional com modalidades referindo-se ao tempo. O LTL assume o tempo como uma sequencia de execuc¸˜ao de um sistema onde cada poss´ıvel cami-nho de computac¸˜ao ´e considerado separadamente, raciocinando sobre uma ´unica sequencia de execuc¸˜ao. Ao inv´es de ser interpretado sobre ´arvores de computac¸˜ao, as f´ormulas LTL s˜ao interpretadas com respeito a caminhos indi-viduais de computac¸˜ao. Em outras palavras, a l´ogica temporal linear expressa propriedades sobre uma sequencia linear de execuc¸˜ao do sistema (PNUELI, 1977).

Apesar do termo “temporal”, neste tipo de l´ogica o tempo n˜ao ´e repre-sentado de forma expl´ıcita, ele ´e reprerepre-sentado de forma impl´ıcita, permitindo somente a especificac¸˜ao da ordem relativa entre eventos. Na pr´atica, as l´ogicas temporais n˜ao suportam de nenhum modo se referir ao tempo preciso de acontecimento dos eventos . As l´ogicas temporais permitem especificar a or-dem na qual determinadas proposic¸˜oes atˆomicas s˜ao verdadeiras durante uma execuc¸˜ao, ou afirmar que certas proposic¸˜oes s˜ao verdadeiras com frequˆencia infinita em uma (ou todas) execuc¸˜oes do sistema (MARQUES, ).

A estrutura de uma propriedade descrita com f´ormula LTL ´e definida por: Combinac¸˜ao de preposic¸˜oes atˆomicas, constantes (verdadeiro ou falso), conectores booleanos e operadores temporais.

As proposic¸˜oes atˆomicas fazem afirmac¸˜oes sobre os estados, onde cada proposic¸˜ao ´e uma relac¸˜ao elementar e cada estado possui um valor verda-deiro bem definido. Os conectores booleanos s˜ao: conjunc¸˜ao (∧), disjunc¸˜ao (∨), negac¸˜ao (¬), implicac¸˜ao (→) e dupla implicac¸˜ao (↔). Os operadores temporais s˜ao os respons´aveis por construir express˜oes representativas ao sequenciamento dos estados ao longo de uma execuc¸˜ao. Os operadores tem-porais presentes no LTL e representados na figura 5 s˜ao (considerando p e q como proposic¸˜oes atˆomicas):

• NEXT ( ): _p(define que p ´e v´alido no pr´oximo estado);

• FUTURE (♦): ♦p(define que p ´e eventualmente v´alido no futuro ou no

estado atual);

• GLOBALLY (): p(define que p ´e v´alido sempre);

Figura 5 – Sequˆencia de estados para f´ormulas ltl b´asicas adaptado de (CLARKE; GRUMBERG; PELED, 1999)

2.4 M ´ETODO PROPOSTO

Na sec¸˜ao 2.2, foi apresentada a atual metodologia de desenvolvimento e validac¸˜ao de programas de CLP adotada pela IP&G. Tendo em vista que o m´etodo corrente n˜ao ´e exaustivo, este trabalho apresenta um nova m´etodo para validac¸˜ao baseada em m´etodos formais. Nesta sec¸˜ao, o m´etodo ser´a explicada a partir de uma vis˜ao geral e, nos cap´ıtulos seguintes, os passos envolvidos neste m´etodo ser˜ao detalhados.

O m´etodo proposto nesta dissertac¸˜ao tem, como prop´osito, integrar-se `a metodologia de projetos vigentes nas ind´ustrias petrol´ıferas, adicionando uma fase de verificac¸˜ao anterior `a etapa de simulac¸˜ao e teste. A etapa de teste na planta por interm´edio do documento TAF (teste de aceitac¸˜ao de f´abrica) n˜ao ´e exaustiva, ´e muito demorada e depende puramente da expertise dos engenheiros projetistas. Desta maneira, a adic¸˜ao de uma etapa anterior de verificac¸˜ao baseada em m´etodos formais se faz importante, pois com ela, erros importantes s˜ao verificados exaustivamente de forma autom´atica e r´apida; logo, erros s˜ao descobertos precocemente.

A introduc¸˜ao de uma nova fase a uma metodologia j´a consolidada apresenta uma s´erie de desafios, como a aceitac¸˜ao dos engenheiros projetistas e mudanc¸as de h´abitos antigos. Desta forma, para facilitar a integrac¸˜ao, o m´etodo proposto utiliza como entrada da etapa de verificac¸˜ao documentos j´a existentes no projeto de um programa de CLP, n˜ao aumentando, assim, o

42

tempo de projeto. O m´etodo ´e automatiz´avel e apresenta os resultados de formal facilmente entend´ıvel.

Como mostrado anteriormente, a metodologia atual, de desenvolvi-mento e velidac¸˜ao de programas de CLP, segue a ordem de desenvolvidesenvolvi-mento demonstrada na figura 4. o m´etodo de verificac¸˜ao formal proposto nesta dissertac¸˜ao ´e uma adic¸˜ao ao atual m´etodo e encontra-se ilustrada na regi˜ao selecionada da figura 6. Ele adiciona uma cadeia de verificac¸˜ao formal `a metodologia vigente e o m´etodo de verificac¸˜ao escolhido ´e o model checking.

Para realizar o model checking, ´e necess´ario que o c´odigo em linguagem Ladder seja traduzido para um modelo formal de semˆantica conhecida e as propriedades sejam descritas por f´ormulas de l´ogica temporal. O c´odigo e as propriedades de seguranc¸a expressas na Matriz de Causa e Efeito passam por uma etapa de transformac¸˜ao, onde s˜ao transformados em Sistema de Transic¸˜ao Temporizada -TTS e l´ogica temporal do tipo LTL respectivamente.

Com o programa e as propriedades representadas por modelos formais, a pr´oxima etapa da cadeia ´e a etapa de verificac¸˜ao formal, onde nos softwares TINA/SELT (BERTHOMIEU; VERNADAT, 2006) ´e realizado o model checking. Erros encontrados s˜ao apresentados atrav´es de um contraexemplo na forma de um diagrama temporal, que auxilia o programador na detecc¸˜ao do erro e que tamb´em serve de entrada para o simulador implementado na etapa de testes.

A traduc¸˜ao do c´odigo para um modelo formal ´e uma etapa complicada, pois ´e dif´ıcil associar a variac¸˜ao de uma entrada com uma mudanc¸a de esta-dos no modelo formal. Tendo em vista este problema, no m´etodo proposto o processo de model checking acontece por interm´edio de uma “cadeia de verificac¸˜ao formal”, ou seja, uma sequˆencia de transformac¸˜oes e ferramentas necess´arias para realizar o processo de verificac¸˜ao formal em linguagem de usu´ario. A primeira etapa desta cadeia ´e a etapa de transformac¸˜ao ilustrada na figura 7; nela, os programas em linguagens de usu´arios sofrem sucessivas transformac¸˜oes para serem escritos em linguagens formais.

O primeiro passo da etapa de transformac¸˜ao ´e a traduc¸˜ao do c´odigo Lad-der em modelo formal. Foi definida a utilizac¸˜ao da linguagem intermedi´aria FIACRE (BERTHOMIEU et al., 2008). A utilizac¸˜ao desta linguagem ´e vanta-josa, pois a mesma ´e de alto n´ıvel, capaz de representar tanto os aspectos comportamentais quanto os aspectos temporais de um sistema e possui ferra-mentas autom´aticas que o transformam em uma s´erie de linguagens formais. A linguagem FIACRE foi desenvolvida no ˆambito de projetos relacionados

`a engenharia dirigida a modelos. Ela foi arquitetada, objetivando ser uma linguagem intermedi´aria formal entre linguagens de modelagem de alto n´ıvel e ferramentas de verificac¸˜ao que trabalham com linguagens baseadas em formalismos matem´aticos (autˆomatos, redes de Petri, sistemas de transic¸˜ao temporizados).

Figura 6 – M´etodo de verificac¸˜ao formal proposta

Para evitar falhas no processo de transformac¸˜ao, o programa em Ladder ´e traduzido para FIACRE, seguindo uma s´erie de regras (Ladder-Fiacre) expli-cadas ano cap´ıtulo 3. O arquivo traduzido que representa o comportamento do programa Ladder em linguagem intermedi´aria ´e chamado de FIACRE comportamento.

O pr´oximo passo na etapa de transformac¸˜ao ´e a transformac¸˜ao das propriedades de seguranc¸as expressas na Matriz de Causa e Efeito em l´ogica temporal do tipo LTL. Para realizar a verificac¸˜ao ao n´ıvel de usu´ario, foi criado um script que traduz de forma autom´atica para l´ogica temporal as propriedades escritas no editor de Matriz de Causa e Efeito. As regras de traduc¸˜ao MCE-FIACRE s˜ao apresentadas no cap´ıtulo 4.

44

Figura 7 – Etapa de Transformac¸˜ao

Sistemas Instrumentados de Seguranc¸a s˜ao sistemas grandes, contendo centenas de entradas e sa´ıdas. Portanto, para evitar explos˜ao combinacional no modelo formal, foi adicionada `a cadeia de verificac¸˜ao formal na etapa de transformac¸˜ao um m´etodo para reduzir o programa. O m´etodo de reduc¸˜ao escolhido, apresentado detalhadamente no cap´ıtulo 5, ´e o m´etodo cone de influˆencia (CLARKE; GRUMBERG; PELED, 1999). Sua principal ideia ´e identificar qual parte do modelo ´e relevante para o model checking. As partes desne-cess´arias do modelo podem ser abstra´ıdas sem afetar o resultado. A abstrac¸˜ao agrupa eventos e estados n˜ao observ´aveis, para a propriedade verificadas, e as retira do programa. Isso pode ajudar a lidar com o problema de explos˜ao combinacional de estados no modelo formal.

Para realizar este m´etodo, foi decidido que as sa´ıdas do programa Ladder ser˜ao verificadas individualmente, ou seja, para cada sa´ıda da Matriz de Causa e Efeito ser´a gerado um c´odigo FIACRE distinto, contendo as entradas, blocos de func¸˜ao, contadores temporais e propriedades relevantes para cada sa´ıda. As informac¸˜oes que n˜ao s˜ao relevantes para sa´ıda a ser verificada s˜ao abstra´ıdas sem afetar o resultado da verificac¸˜ao. Ap´os a etapa de reduc¸˜ao, temos um ´unico arquivo denominado FIACRE reduzido, que cont´em tanto o modelo quanto as propriedades reduzidas.

O c´odigo reduzido ´e transformado de forma autom´atica pelo compilador FRAC em Sistema de Transic¸˜ao Temporizada -TTS e na l´ogica LTL. Ap´os estas transformac¸˜oes, o TTS ´e transformado pelo programa TINA em uma estrutura de Kripke (BIERE et al., 1999). Este grafo com as propriedades formuladas em LTL encaminham-se para o verificador SELT, que pertence ao ambiente TINA (BERTHOMIEU; VERNADAT, 2006). Caso as propriedades n˜ao sejam satisfeitas, o sistema retorna um contraexemplo. A figura 8 ilustra o bloco de verificac¸˜ao formal.

O contraexemplo tem como func¸˜ao ajudar o programador a encontrar o erro no programa Ladder, mostrando o caminho que o sistema levou at´e chegar

Figura 8 – Bloco de Verificac¸˜ao Formal

a um estado de erro. Por´em, o contraexemplo fornecido pelo SELT ´e de dif´ıcil entendimento para programadores que n˜ao est˜ao acostumados a trabalhar com m´etodos formais devido `a complexidade de se associar `as alterac¸˜oes de valores das vari´aveis do c´odigo Ladder com as transic¸˜oes de estado do modelo formal. Para manter a sa´ıda do processo de verificac¸˜ao em n´ıvel de usu´ario, ´e criada na cadeia de verificac¸˜ao formal uma etapa que transforma o contraexemplo fornecido pelo SELT em um contraexemplo compreens´ıvel para o usu´ario. Para isso foi programado um filtro que retira todas as informac¸˜oes desnecess´arias do contraexemplo e, posteriormente, organiza em sequˆencia as entradas para o simulador de CLP. O contraexemplo tamb´em ´e apresentado na forma de diagrama de sinais digitais que facilita o entendimento do erro pelo programador. A etapa de verificac¸˜ao formal ´e detalhada no cap´ıtulo 5.

Ap´os a correc¸˜ao dos erros encontrados, a nova vers˜ao do c´odigo Lad-der ´e submetida novamente `a verificac¸˜ao. Caso nenhum erro seja detectado (nenhum contraexemplo gerado), ent˜ao as propriedades s˜ao todas satisfeitas e o programa segue para as etapas subsequentes do projeto.

2.5 TRABALHOS RELACIONADOS

Na literatura, h´a v´arios trabalhos com o objetivo de modelar e aplicar verificac¸˜ao formal em programas de CLP. Estes trabalhos diferem pela lin-guagem de CLP utilizada para programar os sistemas, pelas especificac¸˜oes aceitas e pelas ferramentas utilizadas para realizar a verificac¸˜ao formal e sua aplicac¸˜ao.

Em (MOKADEM et al., 2005) ´e aplicado model checking no programa de CLP escrito em Ladder que controla a estac¸˜ao 2 da plataforma MSS (Me-catronic Standard System)do Bosch Group. Esse m´etodo formal ´e utilizado com intuito de verificar requisitos de seguranc¸a e de tempo da plataforma.

46

Com intuito de representar as propriedades temporais do sistema, o programa Ladder ´e modelado como autˆomatos temporizados e as f´ormulas gerais s˜ao escritas em TCTL, l´ogica esta que ´e uma extens˜ao da l´ogica CTL utilizada em sistemas de tempo real, pois estende os operadores temporais, permitindo um tratamento temporal quantitativo. Com o sistema modelado e as regras defi-nidas, realiza-se o model checking com a ferramenta UPPAAL desenvolvida para sistemas de tempo real (LARSEN; PETTERSSON; YI, 1997). Para reduzir o n´umero de estados e o tempo de verificac¸˜ao, os autˆomatos temporizados foram constru´ıdos como programas multitarefas, realizando, desta forma, a verificac¸˜ao com tempos inferiores a 1 minuto.

Autˆomatos temporizados e UPAAL tamb´em s˜ao usados para validac¸˜ao de blocos de func¸˜ao de seguranc¸a em (SOLIMAN; FREY, 2009). Neste trabalho, os autˆomatos temporizados representam os blocos de func¸˜ao de seguranc¸a, constru´ıdos em Ladder a partir das especificac¸˜oes semi-formais. Ou seja, as regras para modelagem dos blocos de func¸˜ao em um modelo formal s˜ao apresentadas de forma sistem´atica, entretanto ela se apresenta em uma lingua-gem mais precisa que a lingualingua-gem informal, por´em n˜ao apresenta o grau de formalismo exigido para as linguagens formais. As regras de validac¸˜ao para este bloco s˜ao escritas em l´ogica temporal LTL e CTL. Para validar o m´etodo, o programa ´e submetido a uma etapa de simulac¸˜ao e teste e os resultados dos m´etodos de verificac¸˜ao s˜ao comparados.

A vantagem de se utilizar autˆomatos temporizados como modelo de alto n´ıvel ´e a possibilidade de se garantir por construc¸˜ao que o c´odigo gerado respeite as propriedades desej´aveis e verificadas para o programa de CLP. A desvantagem desse m´etodo ´e a necessidade do usu´ario ter conhecimento de autˆomatos temporizados, al´em de que a construc¸˜ao de modelos complexos nesse formalismo ´e bastante trabalhosa e de dif´ıcil manutenc¸˜ao. Tendo em vista este problema (ZOUBEK; ROUSSEL; KWIATKOWSKA, 2003), tamb´em utiliza autˆomatos temporizados e UPAAL para verificar propriedades temporais de programas Ladder que controlam processos industriais automatizados, por´em ele cria um algor´ıtimo que permite a traduc¸˜ao autom´atica do programa em Diagrama Ladder para autˆomatos temporizados e as propriedades tamb´em s˜ao escritas em l´ogica temporal LTL e CTL.

Para realizar model checking em programas de CLP escrito em Ladder, com propriedades escritas em l´ogica temporal LTL e CTL e com a ferramenta Cadence SMV. O trabalho de (ROSSI; SCHNOEBELEN, 2000) adota autˆomatos

simples como a semˆantica formal para representar programas Ladder. A utilizac¸˜ao de autˆomatos simples em detrimento dos autˆomatos temporizados confere ao modelo uma simplificac¸˜ao computacional extramente significativa, entretanto este modelo ´e aplic´avel a um n´umero restrito de programas que se enquadram em uma s´erie de restric¸˜oes.

Em (MADER et al., 2001), os programas de CLP que controlam os proces-sos do tipo batelada passam pelo processo de verificac¸˜ao formal pelo m´etodo model cheking. Para realizar a verificac¸˜ao, o programa que representa um processo ´e modelado com a linguagem Promela. A linguagem Promela ´e uma linguagem de alto n´ıvel, baseado na sintaxe da linguagem C e comumente uti-lizada para descrever sistema concorrente, pois permite a criac¸˜ao de modelos dinˆamicos, descreve protocolos de comunicac¸˜ao via canais de mensagens e utiliza processos que se comunicam atrav´es de vari´aveis compartilhadas e/ou mensagens s´ıncronas ou ass´ıncronas. A modelagem do programa no modelo formal ´e realizada de forma incremental, usando um formalismo l´ogico em tempo real. Isto ´e feito atrav´es do fortalecimento sistem´atico da premissa de uma implicac¸˜ao cuja conclus˜ao representa o comportamento exigido da planta. A validac¸˜ao do modelo ´e realizada com a ajuda do model-checker SPIN, que ´e uma ferramenta de an´alise de programas descritos em PROMELA que se destina a verificac¸˜ao formal de sistemas concorrentes e utiliza Linear Temporal Logic (LTL) como linguagem de especificac¸˜ao de propriedades. A definic¸˜ao das propriedades ´e feita, utilizando a prova de teorema PVS (OWRE et al., 1996).

Os programas de CLP apesentados em (GOURCUFF; SMET; FAURE, 2008) e em (DARVAS et al., 2014) realizam o controle de sistemas cr´ıticos e s˜ao progra-mados em ST. No Primeiro trabalho, o programa ´e modelado em sistema geral de transic¸˜ao. No segundo trabalho, os programas respons´aveis pelo sistema de seguranc¸a do acelerador de part´ıculas CERN s˜ao transformados em autˆomatos. Em ambos, as propriedades conhecidas do sistemas foram expressas em l´ogica booleana e posteriormente traduzidas em CTL e LTL para realizar o model chekingpelo software NuSVM. Nestes trabalhos, por trabalharem com siste-mas grandes, houve o problema de explos˜ao combinat´oria de estados. Tendo em vista este fato, estes trabalhos implementaram t´ecnicas de reduc¸˜ao em seus modelos. A t´ecnica escolhida por ambos foi a t´ecnica do cone de influˆencia. A principal ideia desta t´ecnica ´e identificar qual parte do modelo ´e relevante para a avaliac¸˜ao do requisito dado. As partes desnecess´arias do modelo podem ser abstra´ıdas sem afetar o resultado. A abstrac¸˜ao agrupa eventos e estados n˜ao observ´aveis, para a propriedade verificadas, e as retira do programa. Au-xiliando assim o problema de explos˜ao combinacional de estados no modelo formal.

Trabalhando com SIS da IP&G e utilizando como base o sistema industrial automatizado por CLPs que controla um aquecedor de chamas, (OLIVEIRA, 2006) define uma metodologia sistematizada para a verificac¸˜ao de modelos, criando um procedimento de traduc¸˜ao de programas escritos em Diagramas de Blocos Funcionais (DBF) para a linguagem reconhecida pela ferramenta de verificac¸˜ao SMV. Descreve, tamb´em, um padr˜ao para escrever especificac¸˜oes baseadas no conhecimento do sistema e na Matriz de Causa e