A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

Pontifícia Universidade Católica do Rio Grande do Sul Faculdade de Informática Programa de Pós-Graduação em Ciência da Computação Método para verificação.

Apresentações semelhantes


Apresentação em tema: "Pontifícia Universidade Católica do Rio Grande do Sul Faculdade de Informática Programa de Pós-Graduação em Ciência da Computação Método para verificação."— Transcrição da apresentação:

1 Pontifícia Universidade Católica do Rio Grande do Sul Faculdade de Informática Programa de Pós-Graduação em Ciência da Computação Método para verificação do PUC#SAT Rafael Medaglia Orientador: Dr. Eduardo Augusto Bezerra Março

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

3 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

4 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.

5 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.

6 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.

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

8 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 e interoperabilidade melhorada.

9 PUC#SAT Diagrama de blocos simplificado do ACDH

10 PUC#SAT TC layers TM layers Implemented 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

11 PUC#SAT Fluxo de dados para TC Fluxo de dados para TM

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

13 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.

14 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.

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

16 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.

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

18 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.

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

20 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.

21 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.

22 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.

23 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.

24 Proposta Objetivos específicos a) 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.

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

26 AtividadeMarAbrMaiJunJulAgoSetOutNovDez Estudar SMVXX Revisar documentação do CCSDS XX X Revisar documentação do PUC#SAT X X XX 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 XX 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 XXX Revisar implementação do modelo do sistema X Implementar propriedades a serem verificadas XXXX XXXXX Executar SMV XXX XXXXX Analisar resultados XX XXXXX Corrigir implementação do modelo e das propriedades XX XXXX Encaminhar contra-exemplos a equipe de projeto X XX Documentar resultados XXXXXXXXXX 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 XX Revisar resultados documentados XX Formatar informações geradas na dissertação XXXX Preparar apresentação da dissertação XX Defesa da dissertação X

27 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, * Toda apresentação foi baseada no descrito / referênciado na integra no PEP.

28 Perguntas?

29

30 Promela/Spin

31 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.

32 SMV

33 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).

34 Outras ferramentas

35 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.

36 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.

37 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.

38 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.

39 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 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.

40 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.

41 Especificação: CTL vs LTL

42 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.

43 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.

44 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.

45 Trabalhos relacionados

46 Clarke, Grumberg, Hiraishi, Jha, Long, McMillan e Ness [35] definem a implementação de um modelo formal para o Futurebus + standard (IEEE Standard ) [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).

47 Trabalhos relacionados 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.

48 Trabalhos relacionados 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].

49 Trabalhos relacionados 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.

50 Trabalhos relacionados 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.

51 Trabalhos relacionados 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 Laboratorys Software Technology Initiative (STI) em propriedades de demanda concorrente de um software de controle de missões de um satélite.

52 Trabalhos relacionados 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].

53 Trabalhos relacionados 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].


Carregar ppt "Pontifícia Universidade Católica do Rio Grande do Sul Faculdade de Informática Programa de Pós-Graduação em Ciência da Computação Método para verificação."

Apresentações semelhantes


Anúncios Google