Facoltà di Ingegneria
Corso di Studi in Ingegneria Informatica
Robustness Testing di middleware DDS-compliant
tesi di laurea
Robustness Testing di middleware DDS-compliant
Anno Accademico 2010/2011
relatore
Prof. Domenico Cotroneo
correlatore
Ing. Gabriella Carrozza
candidato
Sergio Celentano
Matr. 885/211
Facoltà di Ingegneria
Corso di Studi in Ingegneria Informatica
Robustness Testing di middleware DDS-compliant
Contesto e motivazioni
Sistemi critici
Basati su COTS (Commercial Off-The-Shelf)
Complessi
Large scale
Integrazione di componenti eterogenei
Scenari
ATC
Sistemi navali
Sistemi ferroviari
LCCIs
Facoltà di Ingegneria
Corso di Studi in Ingegneria Informatica
Robustness Testing di middleware DDS-compliant
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
Facoltà di Ingegneria
Corso di Studi in Ingegneria Informatica
Robustness Testing di middleware DDS-compliant
Obiettivi e contributo
COSA
 Definizione di una metodologia per la
valutazione della robustezza in sistemi
middleware COTS based
COME
 Realizzazione di uno strumento automatico
 Generalizzabile
 User friendly
Facoltà di Ingegneria
Corso di Studi in Ingegneria Informatica
Robustness Testing di middleware DDS-compliant
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.
Hardware induced failures
Middleware Robustness testing
le API del middleware sono “bombardate”
con una combinazione di valori validi e non
Facoltà di Ingegneria
Corso di Studi in Ingegneria Informatica
Robustness Testing di middleware DDS-compliant
L’ approccio proposto
1. Analisi delle API del middleware.
2. Definizione del Fault Model e Failure Model.
3. Scelta del workload e dello scenario d’uso
più opportuno per la campagna di test.
4. Design e implementazione di un tool per
l’iniezione automatizzata dei guasti.
5. Esecuzione delle campagne di test.
6. Analisi dei risultati.
Facoltà di Ingegneria
Corso di Studi in Ingegneria Informatica
Robustness Testing di middleware DDS-compliant
Il caso di studio: SWIM BOX & OpenSplice DDS
PrismTech OpenSplice
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





Modello Publisher/Subscriber
Fully DDS-compliant
Tecnologia Data-centric e Real-Time
Discovery automatico dei partecipanti
Qualità del servizio customizzabile
Facoltà di Ingegneria
Corso di Studi in Ingegneria Informatica
Robustness Testing di middleware DDS-compliant
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
Workload
Benchmark Touchstone by PrismTech.
2 differenti scenari:
OLAP DB
locale
distribuito
Injection library
OLAP DB per l’analisi
• dei risultati
OpenSplice
Java API
Fault library
Log file
FINJ Tool
Facoltà di Ingegneria
Corso di Studi in Ingegneria Informatica
Robustness Testing di middleware DDS-compliant
Analisi dinamica
Ogni run si compone dei seguenti
passi:
1.
2.
3.
Selezione del metodo target dalla
“method list”
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 golden run per
sollevare eventuali hidden failures.
Alla fine dell’esperimento il sistema
viene ripristinato.
Facoltà di Ingegneria
Corso di Studi in Ingegneria Informatica
Robustness Testing di middleware DDS-compliant
Scenario
Workload: Benchmark Touchstone by 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.
Transmitter
application_id = 1
write
ThroughputTopic
x 10
read
Receiver
application_id = 2
partition_id = 50
Transmitter
application_id = 1
write
ThroughputTopic
x 10
read
Receiver
application_id = 2
Facoltà di Ingegneria
Corso di Studi in Ingegneria Informatica
Robustness Testing di middleware DDS-compliant
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.
Facoltà di Ingegneria
Corso di Studi in Ingegneria Informatica
Robustness Testing di middleware DDS-compliant
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 nonstatic.
Parametri di tipo primitivo
 L’iniezione del guasto avviene sui soli parametri di tipo primitivo presenti nella
firma del metodo.
Facoltà di Ingegneria
Corso di Studi in Ingegneria Informatica
Robustness Testing di middleware DDS-compliant
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