Método para verificação do PUC#SAT

Método para verificação do PUC#SAT
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 - Present myself / explain about the flip-flop; Read the title; Thanks Prof. Zorzo accepting to evaluate the proposal Rafael Medaglia Orientador: Dr. Eduardo Augusto Bezerra Março

Roteiro Introdução PUC#SAT Model Checking
Ferramentas de Model Checking Trabalhos relacionados Proposta Cronograma Explain that the presentation will be divided in these major topics

Introdução “Satellites form an essential part of telecommunication systems worldwide” Roddy “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 In this introduction besides tying some ideas I hope to give a first glimpse about the research proposal. For that there are a few sentences, or at least part of sentences that do the trick

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 PUC#SAT Introdução Model Checking

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. - Implement in HW the protocol stack Consultative Committee for Space Data Systems (CCSDS) for Telecommand (TC) and Telemetry (TM) - TC and the TM fit into the sub system responsible for the Altitude Control and Data Handling (ACDH) of a spacecraft proposed by INPE to the multi mission platform of the Brazilian Space Program

Diagrama de blocos simplificado do ACDH
PUC#SAT Diagrama de blocos simplificado do ACDH Show where the PUC#SAT connects with the On Board Computer in the Altitude Control and Data Handling diagram

PUC#SAT Implemented CCSDS TC/TM Layers TM layers TC layers
P core (VHDL) IP core RS BCH Packetization layer Segmentation layer Transfer layer The spacecraft receives and sends data to a ground segment. The data received is the Telecommand (TC), that is going to be processed on the spacecraft segment - controlling it remotely The data sent is the telemetry All the TC/TM protocol is going to be implemented in an FPGA Telemetry: Application: Gives to the user a method to investigate physical phenomenon using tools, in the space, to collect and analyze data; System Management: Provide the measurements translations into a set of application data; Packetization: Deliveries from end-to-end the application data; Segmentation: It is an optional layer that prepares big data units to transfer thru a space data channel; Transfer: Provide trustworthy transfer of packages and segments in a Space-Earth communication link; Coding: Protects the frames from problems caused by white noise in the physical communication channel; Physical: Consist of a connection using radio frequency signals between the base segment and the space segment. Telecommand: Application: Allows the user to supervise processes; System Management: Convert users’ directives in transportable data units and manages its delivery and execution; Packetization: Transport data units in an error free mode; Segmentation: Break big data units in smaller pieces; Transfer: Provide trustworthy transfer of data units in a Space-Earth communication link; Coding: Protect the upper layers from errors that might happen during the transmission; Physical: Works as the Telemetry physical layer, as a connection using radio frequency signals between the base segment and the space segment Coding layer

PUC#SAT The spacecraft receives and sends data to a ground segment.
The data received is the Telecommand (TC), that is going to be processed on the spacecraft segment - controlling it remotely The data sent is the telemetry All the TC/TM protocol is going to be implemented in an FPGA Telemetry: Application: Gives to the user a method to investigate physical phenomenon using tools, in the space, to collect and analyze data; System Management: Provide the measurements translations into a set of application data; Packetization: Deliveries from end-to-end the application data; Segmentation: It is an optional layer that prepares big data units to transfer thru a space data channel; Transfer: Provide trustworthy transfer of packages and segments in a Space-Earth communication link; Coding: Protects the frames from problems caused by white noise in the physical communication channel; Physical: Consist of a connection using radio frequency signals between the base segment and the space segment. Telecommand: Application: Allows the user to supervise processes; System Management: Convert users’ directives in transportable data units and manages its delivery and execution; Packetization: Transport data units in an error free mode; Segmentation: Break big data units in smaller pieces; Transfer: Provide trustworthy transfer of data units in a Space-Earth communication link; Coding: Protect the upper layers from errors that might happen during the transmission; Physical: Works as the Telemetry physical layer, as a connection using radio frequency signals between the base segment and the space segment Fluxo de dados para TC Fluxo de dados para TM

Roteiro Model Checking Introdução PUC#SAT

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. Em uma comparação entre CTL e LTL [22] 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.

Roteiro Ferramentas de Model Checking Introdução PUC#SAT
Trabalhos relacionados Proposta Cronograma Explain that the presentation will be divided in these major topics

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

Roteiro Trabalhos relacionados Introdução PUC#SAT Model Checking

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 Proposta Introdução PUC#SAT Model Checking

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

Roteiro Cronograma Introdução PUC#SAT Model Checking

Cronograma Atividade Mar Abr Mai Jun Jul Ago Set Out Nov Dez
Estudar SMV X Revisar documentação do CCSDS Revisar documentação do PUC#SAT Identificar os blocos funcionais Revisar blocos funcionais identificados Definir método para especificação dos requisitos Revisar método definido Delimitar documentos de entrada para o modelo do sistema Delimitar documentos de entrada para propriedades a serem verificadas no sistema Implementar modelo do sistema Revisar implementação do modelo do sistema Implementar propriedades a serem verificadas Executar SMV Analisar resultados Corrigir implementação do modelo e das propriedades Encaminhar contra-exemplos a equipe de projeto Documentar resultados Avaliar se os objetivos do trabalho foram atingidos Criar apresentação para o Seminário de Andamento Seminário de andamento Resolver pendências Revisar resultados documentados Formatar informações geradas na dissertação Preparar apresentação da dissertação Defesa da dissertação

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. 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. 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 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 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 VIS (Verification Interacting with Synthesis)
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) Kronos
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 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 ) [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].

Método para verificação do PUC#SAT

Apresentações semelhantes

Apresentação em tema: "Método para verificação do PUC#SAT"— Transcrição da apresentação:

Apresentações semelhantes

Sobre projeto

Feedback

Login

Autorizar-se através da rede social:

Método para verificação do PUC#SAT

Apresentações semelhantes

Apresentação em tema: "Método para verificação do PUC#SAT"— Transcrição da apresentação:

Apresentações semelhantes

Sobre projeto

Feedback