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

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

2. Roteiro • Introdução • PUC#SAT • Model Checking • Ferramentas de Model Checking • Trabalhosrelacionados • Proposta • Cronograma

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

4. Sistemas reativos, como protocolos de comunicação, podem aumentar sua confiabilidade usando modelchecking. Edmund Clarke. Existemdiversasferramentas de Model Checking, escolher a maisapropriadanão é umatarefafá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 modelchecking, e identificar as características do projeto que favorecem, ou não, sua adoção. Introdução

5. VerificaçãovsValidação, segundoBoehm: “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 modelcheckingserã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

6. 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. Introdução

7. Roteiro • Introdução • PUC#SAT • Model Checking • Ferramentas de Model Checking • Trabalhosrelacionados • Proposta • Cronograma

8. 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 interoperabilidademelhorada. PUC#SAT

9. Diagrama de blocossimplificado do ACDH PUC#SAT

10. PUC#SAT TM layers TC layers Implemented CCSDS TC/TM Layers Packetization layer P core (VHDL) IP core (VHDL) Segmentation layer IP core (VHDL) IP core (VHDL) Transfer layer IP core (VHDL) IP core (VHDL) Coding layer RS IP core (VHDL) BCH IP core (VHDL)

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 • Trabalhosrelacionados • Proposta • Cronograma

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

14. De acordo com Clarke, model checking é divididaemtrêsfases: 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 (ComputationTreeLogic) 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. Model Checking

15. Roteiro • Introdução • PUC#SAT • Model Checking • Ferramentas de Model Checking • Trabalhosrelacionados • Proposta • Cronograma

16. Promela/Spin SymbolicModelVerifier(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. Ferramentas de Model Checking

17. Roteiro • Introdução • PUC#SAT • Model Checking • Ferramentas de Model Checking • Trabalhosrelacionados • Proposta • Cronograma

18. 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 modelchecking; Tratam das melhorias nos algoritmos, estruturas de dados ou formas de especificação. Trabalhosrelacionados

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

20. Qual é a proposta? Verificar automaticamente parte da implementação do protocolo proposto pelo CCSDS no projeto PUC#SAT; Sugerir um métodoparaadoção de model checking no contextoemquestão. Proposta

21. Como? Adotarumaestratégia de divisão e conquista PUC#SAT divididoemmódulos; Usandoiteraçõesparaalgumaspropriedadespormódulo; Documentandoosachados; Comparandoresultados. 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 modelchecking no contexto em questão. Proposta

22. Porquê? Para proporcionar ganhos em conhecimentos sobre as ferramentas, técnicas e aplicação prática de modelchecking. 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

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

24. Objetivosespecíficos a) Obtenção de uma divisão do sistema adequada para modelchecking; 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. Proposta

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

26. Cronograma

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, 2006. * Toda apresentaçãofoibaseada no descrito / referênciadonaintegra no PEP.

28. Perguntas?

30. Promela/Spin

31. Promela/Spin Promela (PROcessMEtaLAnguage) é 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 (SimplePromelaInterpreter) foi desenvolvido pela Bell Labs e desde 1991 está disponível como um software open source. Model Checker

32. SMV

33. SymbolicModelVerifier (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 deadlocksfreedom, 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). Model Checker

34. Outrasferramentas

35. Outras ferramentas Além das ferramentas brevemente apresentadas, Spin e SMV, existem ferramentas que abordam as atividades de modelchecking por outras perspectivas, utilizando diferentes estruturas de dados e algoritmos para verificação de propriedades. Model Checker

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

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

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

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

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

41. Especificação:CTL vs LTL

42. Pensando em especificação as duas principias linhas são ComputationTreeLogic (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

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

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

45. Trabalhosrelacionados

46. 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] CacheCoherenceProtocol, 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 OrderedBinaryDecisionDiagram (OBDD). Trabalhosrelacionados

47. 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 modelchecking 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. Trabalhosrelacionados

48. 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]. Trabalhosrelacionados

49. Partindo para os artigos que ajudam a estabelecer a história das ferramentas de modelchecking 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. Trabalhosrelacionados

50. Ainda nessa linha de representações alternativas, em Bierre, Cimatti, Clarke, Fujita e Zhu [49], aparece à utilização de SAT-Basedmodels 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. Trabalhosrelacionados