Robustness Testing di middleware DDS-compliant

1. Robustness Testing di middleware DDS-compliant Anno Accademico 2010/2011 tesi di laurea relatore Prof. Domenico Cotroneo correlatore Ing. Gabriella Carrozza candidato Sergio Celentano Matr. 885/211

2. Contesto e motivazioni • Sistemicritici • Basatisu COTS (Commercial Off-The-Shelf) • Complessi • Large scale • Integrazionedicomponentieterogenei • Scenari • ATC • Sistemi navali • Sistemi ferroviari • LCCIs

3. Contesto e motivazioni • “The Right Data in the Right Place at the Right Time” • Affidabilità • Scalabilità • Robustezza • Realtimeliness • Integrazione e complessità minano l’affidabilità complessiva del sistema • Necessità di metodologie e tecniche di dependability assessment • Focus sulla robustezza

4. Obiettivi e contributo • COSA • Definizione di unametodologia per la valutazionedellarobustezza in sistemimiddleware COTS based • COME • Realizzazione di unostrumentoautomatico • Generalizzabile • User friendly

5. Robustezza Un software si dice robusto se opera correttamente anche in presenza di condizioni anomale [IEEE Std 610.12.1990]. • Middleware Robustness threats • configurazione errata • uso improprio di API a livello applicativo • parametri di ritorno restituiti dal S.O. • Hardwareinducedfailures • Middleware Robustnesstesting • le API del middleware sono “bombardate” con una combinazione di valori validi e non

6. L’ approccio proposto • Analisi delle API del middleware. • Definizione del Fault Model e Failure Model. • Scelta del workload e dello scenario d’uso più opportuno per la campagna di test. • Design e implementazione di un tool per l’iniezione automatizzata dei guasti. • Esecuzione delle campagne di test. • Analisi dei risultati.

7. Il caso di studio: SWIM BOX & OpenSplice DDS SWIM-BOX • Sviluppata per consentire la condivisione dei dati in scenari ATC • Interazione tra sistemi “legacy” • Basata su diverse tecnologie per la data distribution • JMS • DDS PrismTech OpenSplice • Modello Publisher/Subscriber • FullyDDS-compliant • Tecnologia Data-centric e Real-Time • Discovery automatico dei partecipanti • Qualità del servizio customizzabile

8. Il tool di FINJ: Java Fault Injection Tool • Agisce da wrapper delle API del middleware • Intercetta le chiamate effettuate dall’applicazione workload ai metodi pubblici del middleware. • Behavioral reflection tramite libreria Javassist. • Architettura basata su pattern per la FINJ • Sottomissione dei guasti completamente automatizzata • Workload rappresentativo • Benchmark Touchstoneby PrismTech. • 2 differenti scenari: • locale • distribuito • OLAP DB per l’analisi • dei risultati

9. Analisi dinamica • Ogni run si compone dei seguenti passi: • Selezione del metodo target dalla “methodlist” • Per ogni parametro in ingresso viene individuato un set di faults, dato il tipo del parametro • Per ogni fault è previsto un esperimento diverso • Dopo ogni esperimento di FINJ è eseguita una goldenrun per sollevare eventuali hiddenfailures. • Alla fine dell’esperimento il sistema viene ripristinato.

10. Scenario Workload: Benchmark Touchstoneby PrismTech per sollecitare le API del middleware. Scenario: un processo Transmitter che invia 10 messaggi ad un processo Receiver. • Testbed locale • Transmitter e Receiver sono modellati come thread in esecuzione sulla stessa macchina. • Testbed distribuito • Transmitter e Receiver sono collocati su due nodi differenti.

11. Campagna dei test, risultati PrismTech OpenSplice Community Edition 4.3 • 14 metodi analizzati • 400 esperimenti effettuati • 2 scenari considerati • Default Qos: consegna messaggi “Best Effort” • Aspetti di rilievo: • Fallimenti modellati con scala CRASH • Comportamento mediamente robusto (eccezione sollevata conforme alle specifiche) • Due fallimenti di tipo “Silent” osservati, uno più grave (messaggi non trasmessi) • Fallimenti “hang” non replicabili • Nessun evento di tipo catastrophic/abort/hindering osservato.

12. PROS & CONS PROS • Automatizzazione • una volta configurato, il tool opera in totale autonomia. • Generalizzabilità • Minimo effort richiesto per il testing su differenti implementazioni dello standard DDS CONS • Metodi statici • Al momento il tool di fault injection intercetta i soli metodi pubblici e non-static. • Parametri di tipo primitivo • L’iniezione del guasto avviene sui soli parametri di tipo primitivo presenti nella firma del metodo.

13. Conclusioni e sviluppi futuri Conclusioni • La metodologia individuata è efficace anche in un contesto complesso come quello dei COTS • I risultati sono valorizzati dalla rappresentatività degli elementi che compongono il caso di studio Sviluppi futuri • Quality of Service • Ampliamento set di parametri in ingresso • Ampliamento set di metodi • Confronto con altri middleware DDS