Verification of Embedded Software: Problems and Perspectives Andrea Minuto 801040 Barbara De Vido 802663 Analisi e Verifica Programmi A.A.2004/2005.

Presentazione sul tema: "Verification of Embedded Software: Problems and Perspectives Andrea Minuto 801040 Barbara De Vido 802663 Analisi e Verifica Programmi A.A.2004/2005."— Transcript della presentazione:

1 Verification of Embedded Software: Problems and Perspectives Andrea Minuto 801040 Barbara De Vido 802663 Analisi e Verifica Programmi A.A.2004/2005

2 A. Minuto B. De Vido - Analisi e Verifica Programmi A.A.2004/2005 Sommario 1. Introduzione 2. Metodi Formali 3. Sfide nella verifica dell’E.S. 4. Conclusioni 5. Bibliografia

3 A. Minuto B. De Vido - Analisi e Verifica Programmi A.A.2004/2005 1. Introduzione 2. Metodi Formali 3. Sfide nella verifica dell’E.S. 4. Conclusioni 5. Bibliografia

4 A. Minuto B. De Vido - Analisi e Verifica Programmi A.A.2004/2005 1. Introduzione Definizione Embedded Software(E.S.): –Usati in sistemi elettronici a microprocessore progettati appositamente per determinate applicazioni (ad hoc). –Operano in autonomia o connessi ad altri pc. –Funzioni tipicamente di monitoring e controllo. A. Minuto B. De Vido - Analisi e Verifica Programmi A.A.2004/2005

5 1. Introduzione Situazione attuale –Numero e quantità di E.S. in crescita continua –Mantenendo il tasso di crash attuale e moltiplicando per 10 il volume dei software attuali si otterrebbero pc che vanno in crash ogni 3 minuti!! –Inaccettabile per applicazioni Safety-Critical –Tecniche di Verifica (formali e non) devono scalare di conseguenza dato che non sono linearmente proporzionali alla dimensione del SW

6 A. Minuto B. De Vido - Analisi e Verifica Programmi A.A.2004/2005 1. Introduzione Evidenzieremo alcuni problemi ed soluzioni di interpretazioni astratte basate su analisi statiche.

7 A. Minuto B. De Vido - Analisi e Verifica Programmi A.A.2004/2005 1. Introduzione 2. Metodi Formali 3. Sfide nella verifica dell’E.S. 4. Conclusioni 5. Bibliografia

8 A. Minuto B. De Vido - Analisi e Verifica Programmi A.A.2004/2005 2. Metodi Formali Definizione rigorosa tramite formalismo algebrico. Grosso potenziale applicativo. Costo elevato Rallentamento del processo di sviluppo Richiedono cambiamenti nel ciclo di sviluppo Vediamo ora due casi studio…

9 A. Minuto B. De Vido - Analisi e Verifica Programmi A.A.2004/2005 2. Casi studio Driverless Meteor line 14 (Parigi): –B-Method verificato con teoremi interattivi –Attualmente attivo e nessun incidente –Possibili errori in interfacce (non sviluppati in B)

10 A. Minuto B. De Vido - Analisi e Verifica Programmi A.A.2004/2005 2. Casi studio Arian 5: –Causa crash: Spegnimento processore sistema inerziale –Fallimento dovuto ad un eccezione non gestita –Conversione non protetta da fp 64b a int 16b –Origine: Trovato tramite interpretazione astratta su analisi statica Non tutti gli errori posso essere trovati –Solo approssimazioni!

11 A. Minuto B. De Vido - Analisi e Verifica Programmi A.A.2004/2005 2. Model Checking Metodo formale più industrializzato Definizione: –Tecnica algoritmica per controllare che il comportamento di un sistema a stati di transizione sia conforme alle specifiche del comportamento temporale. Caratteristiche –Utilizzato soprattutto dai costruttori HW (Proc.) –Enumerazione esaustiva dello spazio degli stati –Dimensione dello spazio degli stati è esponenziale rispetto alla dimensione del modello

12 A. Minuto B. De Vido - Analisi e Verifica Programmi A.A.2004/2005 2. Model Checking NON PROVA CHE E’CORRETTO Trova i bug che altri metodi informali (testing e simulazione) non trovano. Ancora molto da SVILUPPARE Rimangono necessari per la validazione e la verifica: Debugging Simulations Runtime test

13 A. Minuto B. De Vido - Analisi e Verifica Programmi A.A.2004/2005 1. Introduzione 2. Metodi Formali 3. Sfide nella verifica dell’E.S. 4. Conclusioni 5. Bibliografia

14 A. Minuto B. De Vido - Analisi e Verifica Programmi A.A.2004/2005 1. Modelli software 2. Specifiche 3. Strutture controllo 4. Proprietà numeriche 5. Strutture dati 6. Modularità 7. Timing 8. Proprietà 9. Distribuzione & … 10. User interfaces

15 A. Minuto B. De Vido - Analisi e Verifica Programmi A.A.2004/2005 3.1. Modelli Software Semantiche di linguaggi di programmazione sono Modelli standard Formalizzano l’esecuzione di programma in termini matematici astratti Sono base di analisi e verifica del S.W. Vantaggi –Tools producono automaticamente un modello del programma da verificare

16 A. Minuto B. De Vido - Analisi e Verifica Programmi A.A.2004/2005 3.1. Modelli Software Problemi: –Gli standard cambiano di continuo –I compilatori non implementano strettamente le specifiche degli standard esistenti Comportamenti diversi del programma –Librerie con specifiche NON formali –Tools di verifica non aderenti allo “standard reale”

17 A. Minuto B. De Vido - Analisi e Verifica Programmi A.A.2004/2005 3.1. Far funzionare le astrazioni Nel M.C. il modello è dato  verifica ad esso relativa Preserva solo le caratteristiche selezionate più semplici(approssimazione) Requisiti del design del modello: 1. Un linguaggio per l’implementazione 2. Un linguaggio di verifica per il modello 3. Un linguaggio logico per le specifiche

18 A. Minuto B. De Vido - Analisi e Verifica Programmi A.A.2004/2005 3.1. Far funzionare le astrazioni Utilizzo di astrazione come via di mezzo tra modello concreto e modello “di approssimazione più astratto” Modello concreto finito  funzioni di astrazione e concretizzazione computabili

19 A. Minuto B. De Vido - Analisi e Verifica Programmi A.A.2004/2005 3.1. Astrazione Se modello concreto non finito allora… –Uso di un modello Astratto FINITO –Possibile automazione del design  Prova Soundness: –Metodo deduttivo Prova Astrazione = prova argomento induttivo –Check sul modello astratto Prova Astrazione = prova diretta modello concreto

20 A. Minuto B. De Vido - Analisi e Verifica Programmi A.A.2004/2005 3.1. Astrazione Problema scelta Astrazione: –Beneficio non sempre visibile –Modifica programma  rifare scelta Difficoltà di applicazione su Embedded software che evolve lentamente Studio di previsione sulle modifiche e mantenimento

21 A. Minuto B. De Vido - Analisi e Verifica Programmi A.A.2004/2005 3.1. Astrazioni standard Astrazione fornita come modello finito. –Utente non deve estrarre il modello. –Sceglie solo tra astrazioni predefinite. Analizzatore applicato a infiniti programmi Astrazioni dominio infinito con Widening e Narrowing Necessaria classe di astrazioni “general purpose” Problema: falsi allarmi

22 A. Minuto B. De Vido - Analisi e Verifica Programmi A.A.2004/2005 3.1. Widening/Narrowing Necessarie per domini astratti infiniti che non soddisfano le condizioni catena Accelerano convergenza al punto-fisso Tecniche di approssimazione dinamica (astrazione statica) Astrazioni esprimibili come Widening Assicura l’esistenza della rappresentazione e del modello iniziale

23 A. Minuto B. De Vido - Analisi e Verifica Programmi A.A.2004/2005 3.1. Widening/Narrowing Widening su thresholds=astrazione statica –Poca espressività Widening dinamico  risolve il problema state space explosion nel model checking Modello è esplorato più volte su differenti livelli di astrazioni determinate dinamicamente da widenings

24 A. Minuto B. De Vido - Analisi e Verifica Programmi A.A.2004/2005 3.2. Specifiche Linguaggio di specifica in model check: –Logico temporale –Calcolo punto-fisso Specifica fornita automaticamente o dall’utente per test astratti Entrambi i casi  analisi simili

25 A. Minuto B. De Vido - Analisi e Verifica Programmi A.A.2004/2005 3.3. Strutture di controllo Flat modelling non è adatto a linguaggi funzionali –Struttura dati finita ≠> semantica finita Anche strutture semplici  astrazioni di controllo sono: –Grezze –Utilizzabili solo per proprietà sicure Es: modelli control-flow per “liveness”

26 A. Minuto B. De Vido - Analisi e Verifica Programmi A.A.2004/2005 3.3. Strutture di controllo Astrazione dal basso: –Verifica di una proprietà alla volta –Necessari più modelli (uno per ogni prop.) Astrazione dall’alto: –Verifica safety ma non liveness Futuro embedded software: –Multithreaded programming Richiesta di competenza High level e strumenti di analisi precisi per superare il problema control-flow (race condition,untrapped exception,deadlocks).

27 A. Minuto B. De Vido - Analisi e Verifica Programmi A.A.2004/2005 3.4. Proprietà numeriche Proprietà Interi: –Gestite da astrazioni nei domini infiniti erano non relazionali  poi relazionali Relazionali: –Il numero di valori connessi limitato Staticamente Dinamicamente (widenings molto usato nel model checking) Ancora molto da fare…

28 A. Minuto B. De Vido - Analisi e Verifica Programmi A.A.2004/2005 3.4. Proprietà numeriche Proprietà floating point: –Computaz. fp molto usate con precisione fissa –Incontrollabile perdita di precisione –Errori run-time dovuti alla non validità delle leggi algebriche

29 A. Minuto B. De Vido - Analisi e Verifica Programmi A.A.2004/2005 3.4. Esempio errore Patriot Velocità di crociera: MACH 2 (1522 mph) ( 2450 km/h )

30 A. Minuto B. De Vido - Analisi e Verifica Programmi A.A.2004/2005 3.5. Strutture dati Generalmente ignorate in model checking Quando usata: –Di solito informale… –Su base sintattica… Embedded sw non può ignorare struttura dati, cast e aliases (es.:puntatori…) Astrazioni standard ancora da sviluppare –Es.:Domini ristretti per check over flow No per proprietà liveness

31 A. Minuto B. De Vido - Analisi e Verifica Programmi A.A.2004/2005 3.6. Modularità Modelli del model checking possono seguire la struttura dell’analisi statica. Metodi di composizione: 1. Analisi basata sulla semplificazione 2. Analisi casi peggiori 3. Analisi separata con interfacce 4. Analisi simbolica relazionale

32 A. Minuto B. De Vido - Analisi e Verifica Programmi A.A.2004/2005 3.7. Timing Embedded S.W. devono rispettare vincoli di tempo Costruzione manuale di modelli estremamente difficile se non impossibile –Limiti di pochi microsecondi –Vanno prese in considerazione cache e pipeline di sistema Idem in analisi del programma –semantica a livello assembler –Modello di tempo del processore stesso

33 A. Minuto B. De Vido - Analisi e Verifica Programmi A.A.2004/2005 3.8. Proprietà Di terminazione e Unbound liveness Testare liveness è più difficile che testare safety Facile nei modelli finiti  perché prova liveness = prova stronger safety Difficile per modelli infiniti  uso di funzioni varianti difficili da identificare.

34 A. Minuto B. De Vido - Analisi e Verifica Programmi A.A.2004/2005 3.9. Distribuzione e mobilità Passaggio da controllo centralizzato a controllo distribuito –Cambio radicale di modelli programmazione Es: Shared memory  message passing –Ragionare in termini di insiemi di tracce e non di sequenze di insiemi di stati Astrazioni set-based inadeguate –Evoluzione rapida LAN  WAN

35 A. Minuto B. De Vido - Analisi e Verifica Programmi A.A.2004/2005 3.9. Distribuzione e mobilità Mobilità importante Cambi continui nella topologia di comunicazione Uso di strutture ricorsive unbounded di difficile analisi Verifica delle proprietà difficile

36 A. Minuto B. De Vido - Analisi e Verifica Programmi A.A.2004/2005 3.10. User interfaces Interfacce utenti sono considerate tools. I tools basati su metodi formali rispondono » SI » NO Non sono ancora in grado di rispondere a quesiti incerti

37 A. Minuto B. De Vido - Analisi e Verifica Programmi A.A.2004/2005 1. Introduzione 2. Metodi Formali 3. Sfide nella verifica dell’E.S. 4. Conclusioni 5. Bibliografia

38 A. Minuto B. De Vido - Analisi e Verifica Programmi A.A.2004/2005 4. Conclusioni Verifica formale è essenziale per design di applicazioni safety critical ! La validazione deve evolvere dal debugging alla verifica Il successo dipende dalle scelte di modello/semantica/specifiche considerate: –Hand-made models Sicuro successo Alto costo Legati interpretazione astratta

39 A. Minuto B. De Vido - Analisi e Verifica Programmi A.A.2004/2005 4. Conclusioni –Modelli di specifica applicazione Costruiti da astrazioni automatiche Richiedono modello di reference e teorema di verifica soundness Estremamente costosi –Astrazioni riusabili Rispettano specifiche predefinite e/o definite dall’utente Interpretazione astratta  importante metodo formale per tool automatici di supporto

40 A. Minuto B. De Vido - Analisi e Verifica Programmi A.A.2004/2005 4. Conclusioni Formidabile sfida nel prossimo decennio…

41 A. Minuto B. De Vido - Analisi e Verifica Programmi A.A.2004/2005 5. Bibliografia 1. Introduzione 2. Metodi Formali 3. Sfide nella verifica dell’E.S. 4. Conclusioni 5. Bibliografia

42 A. Minuto B. De Vido - Analisi e Verifica Programmi A.A.2004/2005 5. Reference [0] Verification of Embedded Software: Problems and Perspectives Cousot&Cousot [1] J.A. Abraham. The myth of fault tolerance in complex systems, keynote speech. In The Pacic Rim International Symposium on Dependable Computing, PRDC'99, Hong Kong, CN. IEEE Comp. Soc. Press, 1617 Dec. 1999. http://www.cerc.utexas.edu/~jaa/talks/prdc-1999/. [2] S. Abramsky, D.M. Gabbay, and T.S.E. Maibaum, eds. Semantic Modelling, volume 4 of Handbook of Logic in Computer Science. Clarendon Press, 1995. [3] J.-R. Abrial. The B-Book. Cambridge U. Press, 1996. [4] R. Alur and D.L. Dill. A theory of timed automata. Theoret. Comput. Sci.,126(2):183235, 1994. [5] T. Ball and S.K. Rajamani. Bebop: A symbolic model checker for boolean programs. In K. Havelund, J. Penix, and W. Visser, eds., Proc. 7th SPIN Workshop,Stanford, CA, LNCS 1885, pages 113130. Springer-Verlag, Aug. 30 Sep. 1,2000.

43 A. Minuto B. De Vido - Analisi e Verifica Programmi A.A.2004/2005 5. Reference [6] I. Beer, S. Ben-David, C. Eisner, D. Geist, L. Gluhovsky, T. Heyman, A. Landver, P. Paanah, Y. Rodeh, G. Ronin, and Y. Wolfsthal. RuleBase: Model checking at IBM. In O. Grumberg, editor, Proc. 9th Int. Conf. CAV '97, Haifa, IL, LNCS 1254, pages 480483. Springer-Verlag, 2225 Jul. 1997. [7] A.M. Ben-Amram and N.D. Jones. Computational complexity via programming languages: constant factors do matter. Acta Informat., 37(2):83120, 2000. [8] A. Benveniste, P. Le Guernic, and C. Jacquemot. Synchronous programming with events and relations: the Signal language and its semantics. Sci. Comput. Programming, 16(2):103149, 1991. [9] A. Biere, A. Cimatti, E.M. Clarke, M. Fujita, and Y. Zhu. Symbolic model checking using SAT procedures instead of BDDs. In Proc. 36th Conf. DAC '99, New Orleans, LA, pages 317320. ACM Press, 2125 June 1999. [10] B. Boigelot and P. Godefroid. Symbolic verication of communication protocols with innite state spaces using QDDs (extended abstract). In R. Alur and T.A. Henzinger, eds., Proc. 8th Int. Conf. CAV '96, New Brunswick, NJ, LNCS 1102, pages 112. Springer-Verlag, 31 Jul. 3 Aug. 1996.

44 A. Minuto B. De Vido - Analisi e Verifica Programmi A.A.2004/2005 Fine!! Grazie per l’attenzione!