Test di software per piattaforme embedded su sistemi virtualizzati open source

Introduzione
Interesse dell’azienda e` risolvere in tutto o in parte queste problematiche.
In particolare, l’azienda ha proposto di analizzare le tecnologie di virtualizza-
zione Open Source esistenti, per valutarne l’effettiva applicabilita` nell’ambito
del testing funzionale di software per piattaforme diverse da quelle in cui
gli sviluppatori lavorano. La virtualizzazione permette infatti di eseguire
macchine virtuali in grado di riprodurre, piu` o meno fedelmente, macchine
reali ; l’idea e` quindi quella di offrire agli sviluppatori, direttamente all’interno
del proprio calcolatore, una piattaforma target virtuale. La scelta di questo
approccio e` stata guidata dal fatto che verrebbero cos`ı risolti o minimizzati
gran parte dei problemi esposti. In particolare, l’utilizzo di macchine virtuali
garantirebbe:
• la possibilita` di replicare la configurazione target nella macchina virtuale
dello sviluppatore, senza per questo ridurre o modificare le funzionalita`
del calcolatore su cui e` abituato a sviluppare;
• la possibilita` di riprodurre, mediante strategie di emulazione, l’hardware
presente sulla piattaforma target (o ancora non disponibile);
• la disponibilita` continuata di una piattaforma target virtuale su cui
effettuare testing;
• la disponibilita` di una o piu` piattaforme target virtuali per sviluppatore;
• l’estrema flessibilita` nel dimensionamento delle risorse della macchina
virtuale.
In particolare, una delle preoccupazioni dell’azienda riguardo il testing
funzionale del software e` rappresentata dall’incognita introdotta dall’utilizzo
di hardware differente nelle piattaforme target e di sviluppo. Tale differenza
si traduce, operativamente, nell’uso di device driver differenti, in grado di
produrre un gap funzionale tra le stesse. Con la proposta di questa tesi e` stato
quindi richiesto di analizzare l’entita` di tale gap, di esplorare le soluzioni di
virtualizzazione per trovarne una in grado di ridurlo, e di fornire concretezza
alla soluzione mediante lo studio di un caso reale.
ix
Introduzione
Il presente documento, che relaziona il lavoro di tirocinio svolto, e` orga-
nizzato secondo il seguente schema.
• Nel Capitolo 1 viene fornita una panoramica del contesto aziendale e
vengono definiti con precisione gli obiettivi e i requisiti del lavoro.
• Nel Capitolo 2 viene effettuato un approfondimento sulle motivazioni
che rendono i driver un layer di astrazione non completamente trasparen-
te rispetto ai dispositivi che gestiscono. Vengono percio` individuate con
precisione le effettive fonti delle problematiche che potrebbero inficiare
alla validita` dei test quando la piattaforma target e di sviluppo sono
diverse.
• Nel Capitolo 3 viene mostrato lo stato dell’arte delle tecniche di
virtualizzazione, e vengono individuate, tra le realizzazioni Open Source
preesistenti, quelle piu` adatte per la soluzione del problema.
• Nel Capitolo 4 viene effettuata l’analisi, la progettazione e lo sviluppo
di un emulatore di device in QEMU; in tale capitolo viene quindi
data concretezza alla possibilita` di utilizzare la virtualizzazione come
soluzione al problema del testing funzionale di software per piattaforme
con hardware differente rispetto a quello della piattaforma di sviluppo.
• Nel Capitolo 5 viene illustrato come la soluzione proposta soddisfa i
requisiti funzionali di alto livello individuati nel Capitolo 1.
• Nel Capitolo 6 viene affrontato uno studio relativo alla stima dello
sforzo (effort) necessario per lo sviluppo di nuovi emulatori di device.
Tale studio e` risultato necessario per fornire all’azienda un’idea delle
risorse necessarie per l’applicazione della soluzione proposta.
• Nel Capitolo 7 vengono analizzati aspetti di alto e basso livello relati-
vamente alle prestazioni delle macchine virtuali; tale studio e` risultato
necessario per mostrare alcuni limiti e confini che esse introducono nel
testing.
x
Introduzione
• Nelle Appendici vengono riportati approfondimenti riguardo alcu-
ne interessanti tecnologie utilizzate, e spunti per ulteriori possibilita`
applicative, nel contesto aziendale, della virtualizzazione.
Nel documento si fara` riferimento a un’ampia bibliografia di letteratu-
ra scientifica, accademica e tecnica. Essa risultera` fondamentale per la
comprensione di molti degli aspetti tecnologici e metodologici affrontati.
xi
Capitolo 1
Contesto di riferimento e
obiettivi
In questo capitolo verra` fornita una panoramica del contesto aziendale,
e verranno dettagliati gli obiettivi del lavoro di ricerca di cui la presente
trattazione e` un resconto.
1.1 L’azienda MBDA
Il lavoro e` stato svolto presso il dipartimento di Software Engineering
Technology (SET) della sede di Roma della societa` MBDA S.p.A.
La MBDA Missile Systems e` un’azienda leader nella realizzazione di sistemi
di difesa; con i suoi prodotti e` in grado di soddisfare l’intera domanda nel
settore. E` una multinazionale sostenuta da tre gruppi, che corrispondono ai
maggiori azionisti: l’inglese BAE SYSTEM, la francese EADS e l’italiana
Finmeccanica (vedi Figure 1.1 e 1.2); in questo modo essa e` la prima societa`
di Difesa Europea pienamente integrata.
L’azienda opera in tutti i maggiori mercati del mondo; il gruppo offre ai
clienti prodotti altamente tecnologici, qualita` e professionalita` nelle tecnologie
chiave, unendo ad esse le soluzioni imprenditoriali delle societa` costituenti.
1
Capitolo 1. Contesto di riferimento e obiettivi
Figura 1.1: struttura dell’azienda MBDA
Figura 1.2: tappe del processo di integrazione di MBDA
2
Capitolo 1. Contesto di riferimento e obiettivi
1.2 La richiesta dell’azienda
Tradizionalmente lo sviluppo del software per sistemi embedded introduce
nuove problematiche nelle fasi di testing. I computer su cui gli sviluppato-
ri lavorano sono, in genere, molto differenti dalla piattaforma target, per
caratteristiche che spaziano nei seguenti fattori:
• architettura (la piattaforma di sviluppo potrebbe essere x86, ma il
target ARM, MIPS, x86 64; potrebbe esserci un diverso byte ordering;
eccetera);
• hardware di I/O (il target consta di dispositivi specializzati che potreb-
bero non avere un corrispettivo nei normali PC, potrebbero essere stati
sviluppati ad hoc dall’azienda, oppure potrebbero semplicemente essere
differenti);
• configurazione (quella del target e` in genere estremamente ritagliata
sulle necessita` operative).
• risorse (il target dispone solitamente di risorse quali RAM e disco fisso
limitate);
I test, per essere significativi, andrebbero quindi sempre effettuati sul
target, e non sui calcolatori in cui effettivamente gli sviluppatori lavorano.
Fattori come il costo e la minore reperibilita` delle piattaforme embedded
introducono tuttavia un problema, quello del bottleneck sul target : molti
sviluppatori, per effettuare un testing adeguato, dovrebbero disporre di molti
target, ma cio` che accade nella realta` e` che di questi ce ne sono solitamente
in quantita` molto limitata. Nel caso migliore, quando uno o piu` target sono
disponibili, resta comunque necessario pianificare delle finestre di tempo da
assegnare ai vari sviluppatori. Tutto questo introduce ovviamente notevoli
rallentamenti nelle fasi di sviluppo del software, come viene evidenziato dallo
schema del processo V-Model riportato in Figura 1.3: la scarsa disponibilita`
di piattaforme su cui effettuare test d’integrazione e di sistema inficerebbe
pesantemente nell’efficacia del processo, essendo il riscontro prodotto dalle
fasi del ramo destro piu` lento e ritardato.
3
Capitolo 1. Contesto di riferimento e obiettivi
Figura 1.3: processo di sviluppo V-Model
Sono in genere possibili strategie di remote-testing e cross-development
([Enc03], [Han07]), che tuttavia richiedono la disponibilita` di almeno un target
e di una connessione tra questo e le piattaforme di sviluppo. In questi casi,
lo sviluppatore effettua il suo lavoro su un certo calcolatore, ma l’esecuzione
dei test avviene, in modo trasparente, sul target. Queste soluzioni non sono
tuttavia compatibili con le esigenze aziendali, in quanto non e` possibile
garantire in modo continuato la presenza del target.
La soluzione a questa problematica, almeno teorica e comunque parziale,
e` quella di effettuare la maggior quantita` possibile di test sulle piattaforme
di sviluppo, prima di procedere inevitabilmente al system testing sul target.
In questo modo il problema del collo di bottiglia viene quantomeno ridotto.
Diventa tuttavia necessario disporre di una metodologia che permetta di
validare la piattaforma di sviluppo rispetto al target, almeno per gli aspetti
necessari al testing che deve essere effettuato.
Interesse dell’azienda MBDA S.p.A. e` studiare queste problematiche ed
elaborare soluzioni al fine di supportare adeguatamente lo sviluppo del soft-
ware per le piattaforme target. In particolare, viene richiesto di analizzare
le tecnologie di virtualizzazione Open Source come strumenti per la risolu-
4
Capitolo 1. Contesto di riferimento e obiettivi
zione delle problematiche esposte, al fine di mettere a disposizione di ogni
sviluppatore una piattaforma target virtuale.
1.3 Piattaforme di riferimento
Nei seguenti paragrafi vengono mostrate alcune delle piattaforme di
riferimento sulle quali l’azienda conduce gli studi di Ricerca e Sviluppo.
1.3.1 Software
Il sistema operativo installato sulle piattaforme di riferimento e` FNM-
Linux (Finmeccanica Linux). Esso e` un’evoluzione della distribuzione Linux
Gentoo, ed e` sviluppato da MBDA con l’obiettivo di disporre di un sistema
operativo perfettamente calibrato sui requisiti aziendali. Quando non diver-
samente indicato, si sono utilizzati il kernel Linux-2.6.24-FNM v2.1 (basato
sul kernel 2.6.24.7 con patchset RT-Preempt) e il portage tree congelato al
periodo di svolgimento del tirocinio (da novembre 2008 a maggio 2009).1 Tali
scelte sono state fatte per esigenze aziendali e per minimizzare problemi di
volatilita` della piattaforma.
1.3.2 Hardware
Le piattaforme hardware di riferimento utilizzate per la presente tesi sono
quelle disponibili nel laboratorio di ricerca presso cui il lavoro e` stato svolto.
Le piattaforme di sviluppo sono normali Personal Computer Intel x86 di
vario tipo. La piattaforma target di riferimento e` una scheda Concurrent
Technologies VP-417, ossia un sistema embedded di tipo SBC (Single Board
Computer) PC-compatibile che integra in un’unica scheda tutti i componenti
necessari, quali scheda madre, processore, memoria, interfacce di I/O (vedi
Figura 1.4). Queste schede sono innestate in un bus di backplane VME, che
permette l’alimentazione e la comunicazione tra piu` schede (vedi Figura 1.5).
1
il portage tree consiste in un archivio strutturato per la gestione dei pacchetti nella
distribuzione Linux Gentoo.
5
Capitolo 1. Contesto di riferimento e obiettivi
Figura 1.4: SBC Concurrent Technologies VP 417
Figura 1.5: chassis VME
6
Capitolo 1. Contesto di riferimento e obiettivi
Nell’Appendice A sono riportate informazioni dettagliate riguardo la
piattaforma target e i dispositivi in essa presenti.
1.4 Scopo della tesi
Scopo del presente lavoro e` l’esplorazione delle potenzialita`, in termini
funzionali e prestazionali, dei sistemi di virtualizzazione Open Source in
relazione al problema del testing del software per la piattaforma target.
Il contesto operativo delineato dall’azienda ha permesso di individuare nei
dispositivi hardware presenti nella piattaforma target, e nei relativi driver, le
principali priorita`. E` stato quindi richiesto uno studio iniziale riguardante
la dependability dei dispositivi, e il funzionamento dei driver del sistema
operativo Linux, per identificare chiaramente le problematiche che questi
introducono quando le piattaforme target e di sviluppo sono diverse.
Le fasi di analisi occorse hanno in seguito permesso di individuare una
possibile soluzione al problema. Tale soluzione consiste nell’emulazione, in
macchine virtuali di un determinato tipo, configurate e installate nelle piat-
taforme di sviluppo, dell’insieme dei dispositivi presenti nella piattaforma
target. Scopo della tesi e` stato quindi fornire uno studio di fattibilita` riguar-
dante la soluzione proposta, avvalorato da esempi concreti e da un’analisi
prestazionale.
1.5 Obiettivi e requisiti del lavoro
La definizione della maggior parte dei requisiti e` stata effettuata all’inizio
del processo di ricerca e sviluppo, secondo la richiesta aziendale. Alcuni di
essi sono tuttavia emersi durante la lunga attivita` di analisi, che ha permesso
una migliore comprensione del dominio del problema.
I requisiti individuati, tutti di alto livello, sono riportati e classificati nei
seguenti paragrafi.
7
Capitolo 1. Contesto di riferimento e obiettivi
1.5.1 Classificazione dei requisiti
I requisiti individuati verranno classificati con il seguente formalismo:
REQ [Categoria][ID]
Le categorie individuate sono le seguenti:
F (Funzionali): requisiti funzionali.
Q (Qualita`): requisiti di qualita`.
D (Documentazione): requisiti di documentazione.
1.5.2 Requisiti
Vengono di seguito riportati i requisiti della soluzione da individuare
per il problema, con l’indicazione dei metodi di qualifica per assicurarne il
soddisfacimento. Tale verifica verra` affrontata nei capitoli finali.
Metodi di qualifica
T (Test): verifica mediante l’utilizzo di un ambiente di test definito.
I (Ispezione): verifica visuale della metodologia, del codice e della docu-
mentazione.
D (Dimostrazione): verifica formale.
Requisiti
REQ F01 : la soluzione deve essere applicabile anche quando la piattaforma
target non e` presente in modo continuato (DI).
REQ F02 : la soluzione deve essere integrabile alla piattaforma di sviluppo
utilizzata dall’azienda (DIT).
8
Capitolo 1. Contesto di riferimento e obiettivi
REQ F03 : la soluzione deve permettere l’esecuzione di sistemi operativi,
kernel e applicativi che girano sulla piattaforma target senza dover
effettuare modifiche agli stessi o alla configurazione della piattaforma
di sviluppo (DT).
REQ Q01 : la soluzione, comprensiva dei moduli software da sviluppare, de-
ve essere integrabile e realizzabile con una quantita` di risorse compatibili
con quelle dell’azienda (T).
REQ Q02 : la soluzione deve garantire prestazioni compatibili con le neces-
sita` di sviluppo del software (T).
REQ Q03 : il sistema di virtualizzazione deve essere Open Source (DI).
REQ Q04 : la soluzione deve poter essere sviluppata internamente all’azien-
da e senza l’intervento di terzi (DI).
REQ Q05 : il sistema di virtualizzazione deve avere prestazioni coerenti con
quelle della piattaforma target (DT).
REQ D01 : deve essere mostrata la criticita` del layer dei dispositivi e dei
driver nel testing del software per la piattaforma target (I).
9