pontifícia universidade católica do rio grande do sul faculdade de informática programa de...

Pontifícia Universidade Católica do Rio Grande do SulFaculdade de Informática

Programa de Pós-Graduação em Ciência da Computação

Método para verificaçãodo PUC#SAT

Rafael Medaglia

Orientador:Dr. Eduardo Augusto

Bezerra

Março - 2009

Roteiro

• Introdução• PUC#SAT• Model Checking• Ferramentas de Model Checking• Trabalhos relacionados• Proposta• Cronograma

Introdução

• “Satellites form an essential part of telecommunication systems worldwide” Roddy 2006

• “Software quality is something everyone wants… and users insist that software work consistently and be reliable” Lewis 2000

• “Analysis estimates that more than 80% of all current innovations within vehicles are based on distributed electronic systems. Critical to the functionality and application domain of such systems is the underlying communication network” Leen e Heffernan 2006

Introdução

• Sistemas reativos, como protocolos de comunicação, podem aumentar sua confiabilidade usando model checking. Edmund Clarke.

• Existem diversas ferramentas de Model Checking, escolher a mais apropriada não é uma tarefa fácil.

• Sendo o projeto PUC#SAT (4) é focado na implementação de um protocolo de comunicação Terra-Espaço.

• O trabalho aqui proposto visa avaliar a aplicação das técnicas de model checking, e identificar as características do projeto que favorecem, ou não, sua adoção.

Introdução

• Verificação vs Validação, segundo Boehm:− “Estamos construindo certo o produto?” -

Verificação− “Estamos construindo o produto certo?” -

Validação• O protocolo em questão é uma sugestão do

CCSDS e amplamente adotado por diversas agências.

• As propriedades verificadas através da utilização da ferramenta de model checking serão baseadas nas características definidas para determinar complacência com o protocolo em questão.

• A forma de utilização da ferramenta e o modo como o sistema vai ser modelado, visando garantir as características desejadas, serão definidos no decorrer do trabalho.

Introdução

• Uma importante motivação para a presente proposta é a possibilidade de colaboração com o programa espacial brasileiro, que possui iniciativas apontando para a verificação formal como mais uma ferramenta de garantia da qualidade dos sistemas desenvolvidos. Mais especificamente, espera-se definir um método a ser utilizado em trabalhos futuros para verificação formal de sistemas com características e requisitos similares ao PUC#SAT.

Roteiro

• Introdução

• PUC#SAT• Model Checking• Ferramentas de Model Checking• Trabalhos relacionados• Proposta• Cronograma

PUC#SAT

• PUC#SAT como um todo,−Consultative Committee for

Data Systems (CCSDS);−Telecommand (TC) e

Telemetry (TM);− INPE - Attitude Control

and Data Handling (ACDH);−Reduzir tempo e custos

por um melhor re-uso einteroperabilidade melhorada.

PUC#SAT

Diagrama de blocos simplificado do ACDH

PUC#SAT

TC layers TM layersImplemented

CCSDS TC/TM Layers

P core(VHDL)

IP core(VHDL)

IP core(VHDL)

IP core(VHDL)

RS IP core(VHDL)

BCH IP core(VHDL)

IP core(VHDL)

IP core(VHDL)

Packetization layer

Segmentation layer

Transfer layer

Coding layer

PUC#SAT

Fluxo de dados para TC Fluxo de dados para TM

Roteiro

• Introdução

• PUC#SAT

• Model Checking• Ferramentas de Model Checking• Trabalhos relacionados• Proposta• Cronograma

Model Checking

• Model checking é uma técnica que teve como base um método formal;

• Permite a verificação automática de propriedades específicas de sistemas concorrentes;

• Especialmente útil para sistemas reativos, caracterizados por continuamente receberem estímulos e responderem rapidamente;

• Usa como entrada para execução o modelo do sistema e as propriedades que o sistema deve satisfazer. Verifica o modelo do sistema buscando por estados que não respeitem as propriedades informadas.

Model Checking

• De acordo com Clarke, model checking é dividida em três fases:− 1ª Modelagem: Consiste em converter o design

em um formalismo. As restrições do sistema determinam o grau de abstração;

− 2ª Especificação: Define as propriedades que serão verificadas. As duas principais lógicas utilizadas são CTL (Computation Tree Logic) e LTL (Linear Temporal Logic) com seus quantificadores e operadores temporais;

− 3ª Verificação: A verificação pode ser totalmente automática. No caso de alguma das propriedades, definidas na especificação, não ser confirmada, a ferramenta provê um contra-exemplo para auxiliar na identificação da origem do problema.

Roteiro

• Introdução

• PUC#SAT• Model Checking

• Ferramentas de Model Checking• Trabalhos relacionados• Proposta• Cronograma

Ferramentas de Model Checking

• Promela/Spin• Symbolic Model Verifier (SMV)• Outras ferramentas

− Verisoft, VIS, RAVEN, TLV, UPPAAL, HyTech entre outras.

• Cada projeto possui características que influenciam na adoção de uma determinada ferramenta.

Roteiro

• Introdução

• PUC#SAT• Model Checking• Ferramentas de Model Checking

• Trabalhos relacionados• Proposta• Cronograma

Trabalhos relacionados

• Diversos artigos foram pesquisados até se chegar a uma definição do trabalho aqui proposto.

• Os artigos que tiveram maior influência estão divididos em três principais categorias:− Os que apresentam o método para definição do sistema e

suas propriedades;− Expõe casos de sucesso na adoção das técnicas de model

checking;− Tratam das melhorias nos algoritmos, estruturas de dados

ou formas de especificação.

Roteiro

• Introdução

• PUC#SAT• Model Checking• Ferramentas de Model Checking• Trabalhos relacionados

• Proposta• Cronograma

Proposta

• Qual é a proposta?

− Verificar automaticamente parte da implementação do protocolo proposto pelo CCSDS no projeto PUC#SAT;

− Sugerir um método para adoção de model checking no contexto em questão.

Proposta

• Como?

− Adotar uma estratégia de divisão e conquista• PUC#SAT dividido em módulos;• Usando iterações para algumas propriedades por

módulo;• Documentando os achados;• Comparando resultados.

− O critério de saída é ter uma melhor visão sobre o método adotado para ter resultados aceitáveis no uso de técnicas de model checking no contexto em questão.

Proposta

• Por quê?

− Para proporcionar ganhos em conhecimentos sobre as ferramentas, técnicas e aplicação prática de model checking.

− Os resultados podem servir:• de referência para a modelagem de outras partes do

PUC#SAT;• para projetos com requisitos similares.• sugerir pontos de melhoramento para o projeto PUC#SAT

ficar mais complacente com o protocolo proposto pelo CCSDS, baseado nos resultados obtidos com o SMV.

Proposta

• Objetivo

− Verificar que foram respeitadas algumas das propriedades necessárias para se considerar o projeto PUC#SAT complacente com o protocolo de comunicação proposto pelo CCSDS. Este estudo de caso vai servir para observar um método que possa ser adotado para atingir tal finalidade.

Proposta

Objetivos específicosa) Obtenção de uma divisão do sistema adequada

para model checking;b) Disponibilizar para o projeto PUC#SAT uma

especificação dos requisitos e modelo do sistema;c) Execução das seguintes atividades para um

determinado bloco:• Delimitação dos documentos que irão servir de entrada

para o modelo e para as propriedades;• Criação do modelo• Definição das propriedades que serão verificadas;• Análise dos resultados;• Encaminhamento dos contra-exemplos considerados

válidos para equipe do projeto.d) Compilação das práticas adotadas para a

verificação automatizada.

Roteiro

• Introdução

• PUC#SAT• Model Checking• Ferramentas de Model Checking• Trabalhos relacionados• Proposta

• Cronograma

CronogramaAtividade Mar Abr Mai Jun Jul Ago Set Out Nov Dez

Estudar SMV X X

Revisar documentação do CCSDS X X X

Revisar documentação do PUC#SAT X X X X

Identificar os blocos funcionais X

Revisar blocos funcionais identificados X

Definir método para especificação dos requisitos X

Revisar método definido X X X X X

Delimitar documentos de entrada para o modelo do sistema X

Delimitar documentos de entrada para propriedades a serem verificadas no sistema X

Implementar modelo do sistema X X X

Revisar implementação do modelo do sistema X

Implementar propriedades a serem verificadas X X X X X X X X X

Executar SMV X X X X X X X X

Analisar resultados X X X X X X X

Corrigir implementação do modelo e das propriedades X X X X X X

Encaminhar contra-exemplos a equipe de projeto X X X

Documentar resultados X X X X X X X X X X

Avaliar se os objetivos do trabalho foram atingidos X X

Criar apresentação para o Seminário de Andamento X

Seminário de andamento X

Resolver pendências X X

Revisar resultados documentados X X

Formatar informações geradas na dissertação X X X X

Preparar apresentação da dissertação X X

Defesa da dissertação X

Referências• Leen, G.. Heffernan, D.. Modeling and

Verification of a Time-triggered Networking Protocol. Networking, International Conference on Systems and International Conference on Mobile Communications and Learning Technologies, 2006.

* Toda apresentação foi baseada no descrito / referênciado na integra no PEP.

Perguntas?

Promela/Spin

Model Checker

• Promela/Spin• Promela (PROcess MEta LAnguage) é uma

linguagem não determinística usada para construir representações em alto nível (modelos) de sistemas distribuídos. Permite abstração dos detalhes de implementação e foco na sincronização entre processos. O objetivo é a criação de modelos que permitam a utilização do Spin.

• O Spin (Simple Promela Interpreter) foi desenvolvido pela Bell Labs e desde 1991 está disponível como um software open source.

Model Checker

• Symbolic Model Verifier (SMV)• O SMV é uma ferramenta utilizada para

verificar que máquina de estados finitas (FSMs) satisfazem uma especificação definida em CTL.

• De acordo com McMillan, o SMV utiliza uma linguagem que permite a descrição de máquinas de Mealy (sincronas) ou redes (assíncronas) e a sintaxe para propriedades temporais, como deadlocks freedom, fairness, safety e liveness é concisa uma vez que CLT permite isso.

• Para verificar se uma determinada propriedade foi satisfeita é utilizado o algoritmo de Ordered Binary Decision Diagram (OBDD).

Outras ferramentas

Model Checker

• Outras ferramentas• Além das ferramentas brevemente

apresentadas, Spin e SMV, existem ferramentas que abordam as atividades de model checking por outras perspectivas, utilizando diferentes estruturas de dados e algoritmos para verificação de propriedades.

Model Checker

• VeriSoft

− Developed at the Bell Labs, to systematically explore the state space of a system, maps each systems’ process to a Unix process, using an external process – the scheduler. The scheduler is responsible for controlling the operations between processes.

• VIS (Verification Interacting with Synthesis)

− Developed conjunctly by the University of California at Berkeley, the University of Colorado at Boulder, and the University of Texas, Austin. It can read BLIF_MV files, so Verilog inputs are easily handled.

Model Checker

• RAVEN (Real-time Analysis and Verification Environment)

− Currently under development by the Formal Methods Group of the University of Tübingen, the systems are described in an extension of FSM, including timed transitions – referred by them as I/O Interval structure. As the other model checker tools, counterexample is generated in case some property is violated, it uses CCTL (clocked computation tree logic). RAVEN has three algorithms, allowing the system to be analyzed quantitatively, according to the user selection.

Model Checker

• TLV (Temporal Logic Verifier)

− Based on SMV, it accepts as input SMV and SPL languages. The major difference between TLV and SMV is that all proofs are performed interactively in TLV, using procedures written in a language called TLV-Basic.

• Kronos

− Has as one of its major objectives to be integrated in the design environments of real-time systems. It uses timed automata and timed temporal logics. Its specification framework allows logical – as timed temporal logic (TCTL) formulas, and behavioral – timed automata.

Model Checker

• UPPAAL

− Created in 1995 by a collaborative work between the Aalborg University and the Uppsala University. The current version UPPAAL 4.0 was released in May 2006. The two original design guidelines were efficiency and ease-of-use, while the version 4.0 focuses in applicability and performance. UPPAAL counts with a graphic interface, automatic compilation from graphic to textual definition, several syntactical checks and, of course, the generation of counterexamples when needed.

Model Checker

• HyTech

− This model checking tool latest version, previously based on symbolic algebra tool Mathematica, and built on formula manipulation now uses geometric algorithms, providing an input language easier to use, more portable code, and better performance.

− Once model checking has been expanded to real-time systems and to hybrid systems (real-time systems that interact with the physical world) they are modeled as timed automata and linear hybrid automata, respectively, so for formal analysis the use of symbolic modeling is required due to its infinite state space.

Especificação:

CTL vs LTL

Model Checking

• Pensando em especificação as duas principias linhas são Computation Tree Logic (CTL) e Linear Temporal Logic (LTL), ambas são amplamente discutidas e possuem exemplos de sintaxe e semântica em Clarke e Grumberg e Katoen e Christel.

• De acordo com Clarke e Grumberg [3], utilizando CTL é possível representar que um determinado estado é alcançado eventualmente ou nunca, ainda que sem menções explícitas ao tempo, apenas através do uso de operadores temporais na fórmula. CTL usa estruturas de Kripke com um estado inicial indicado e estados subseqüentes explorados infinitamente. A LTL é um subconjunto da CTL, no qual o operador temporal precisa ser imediatamente precedido por um quantificador.

Model Checking

• Os quantificadores de caminho são:− A – For all;− E – For some.

• Entre os operadores temporais básicos podemos listar os seguintes:− X – Next time;− F – Eventually;− G – Always;− U – Until;− R – Release.

Model Checking

• Em uma comparação entre CTL e LTL algumas características se destacam:− Questões de expressividade entre CTL e LTL não

podem ser comparadas facilmente, existem propriedades que apenas uma ou outra consegue expressar;

− Os algoritmos são significativamente diferentes, assim sendo os resultados podem variar significativamente em tempo de execução e complexidade computacional;

− Noções de fairness facilmente endereçadas em LTL demandam técnicas especiais em CTL.


• Clarke, Grumberg, Hiraishi, Jha, Long, McMillan e Ness [35] definem a implementação de um modelo formal para o Futurebus + standard (IEEE Standard 896.1-1991) [43] Cache Coherence Protocol, e através da utilização do SMV [21], erros e ambigüidades foram identificados. Consequentemente um modelo corrigindo os erros e as ambigüidades foi o resultado do projeto.

• Outro caso de sucesso pode ser visto em Tsuchiya, Nagano, Paidi e Kikuno [44], onde o SMV é utilizado para provar que algoritmos self-stabilizing, ou seja, independente de seu estado inicial eles convergem para estados seguros, podem ser representados por Ordered Binary Decision Diagram (OBDD).


• Em Chandra, Godefroid e Palm [26], a biblioteca de processamento de ligações, que é executada em centenas de estações, foi avaliada usando VeriSoft. O uso das técnicas de model checking resultou na identificação de problemas que os testes tradicionais não identificaram, além disso, aumentaram a confiança da equipe de desenvolvimento nas versões geradas durante o ciclo de vida do projeto.


• Também em Godefroid, Hanmer e Jagadeesan [45] e [46] é possível ver outros casos onde a ferramenta VeriSoft obteve sucesso, permitindo a equipe responsável pela verificação encontrar situações que, de acordo com o artigo, seriam virtualmente impossíveis usando um laboratório de testes convencional [45].


• Partindo para os artigos que ajudam a estabelecer a história das ferramentas de model checking temos Burch, Clarke, McMillan, Dill e Hwang [47] e Clarke, Grumberg e Long [48] onde o foco é no número de estados e como a representação simbólica, invés da explicita, permite um conjunto maior de estados [47]. É uma avaliação de performance, porem o foco é em melhoramentos na representação [47][48] dos estados.


• Ainda nessa linha de representações alternativas, em Bierre, Cimatti, Clarke, Fujita e Zhu [49], aparece à utilização de SAT-Based models em substituição dos BBD-Based. Ainda que existam prós e contras, o artigo auxilia a compreender as diferenças e estabelecer critérios para decidir quando usar qual modelo.


• Outro aspecto que aparece nos artigos é a necessidade de ferramentas de model checking para domínios específicos serem mais efetivas, Robby, Dwyer e Hatcliff [50] propõem um framework extensível e personalizável chamado Bogor. Este framework permite suporte direto para modelar designs e implementações orientadas a objetos. Bogor foi planejado para ser utilizado na Lockheed Martin Advanced Technology Laboratory’s Software Technology Initiative (STI) em propriedades de demanda concorrente de um software de controle de missões de um satélite.


• Entre os estudos que visavam facilitar o processo de model checking através da automação de partes do trabalho podemos citar Ogata, Nakano, Nakamura e Futatsugi [51], onde o tradutor chamado Chocolat/SMV usando como entrada uma especificação CafeOBJ gera uma especificação para o SMV. Outras ferramentas que geram os modelos diretamente do VHDL ou das máquinas de estados para o Promela (Spin) foram investigadas (FSM2SPIN, MODEX) [24], porém os primeiros resultados não foram de acordo com a qualidade esperada [7].

• Outros artigos relacionados a model checking que serviram de forma indireta na definição dos objetivos deste trabalho, bem como para melhor compreender o assunto podem ser encontrados em [52][53][54][55][56].


• Outros artigos relacionados a model checking que serviram de forma indireta na definição dos objetivos deste trabalho, bem como para melhor compreender o assunto podem ser encontrados em [52][53][54][55][56].

pontifícia universidade católica do rio grande do sul faculdade de informática programa de...

Documents